#ubuntu-devel 2005-05-16
<hunger> Is there a reason why g++ still depends on the 3.3 compiler?
* hunger thinks it would be nice to have that at 4.0 now that that is available.
<ska-fan> Is there a friendly user channel, btw?
<ska-fan> recommending #ubuntu is like a spit in the face :)
<|QuaD-> ska-fan: #ubuntu
<Nafallo> lol!
* hunger spits in ska-fan's face by suggesting #ubuntu.
<Nafallo> ska-fan: why isn't #ubuntu friendly?
<hunger> ska-fan: Actually I fleed here myself;-)
<Nafallo> hunger: kernel? :-)
<hunger> Nafallo: kernel what?
<Nafallo> hunger: the kernel is compiled with gcc-3.3
<ska-fan> Nafallo: It's full of annoying persons that flood and do other evil stuff.
<Nafallo> hmm
<ska-fan> I haven't got a single useful answer in #ubuntu yet
* Nafallo read that to fast ;-)
<hunger> Nafallo: Shouldn't be... gcc is at version 4 for a while now.
<Nafallo> ska-fan: ohh.
<hunger> Nafallo: g++ is the only thing left at 3.3 for now.
<LinuxJones> ska-fan, with what ?
<hunger> ska-fan: I actually just found the channel too noisy...
<ska-fan> LinuxJones: ?
<LinuxJones> ska-fan, you didn't get an answer to what questions ?
<ska-fan> LinuxJones: I don't remember the questions
* ska-fan invites to #ubuntu-friendly
<Nafallo> hunger: probably the ToolchainTransition isn't done yet :-)
<Nafallo> hunger: http://udu.wiki.ubuntu.com/ToolchainRoadmap
<hunger> Nafallo: Ah! The hidden wiki again;-)
* ska-fan considers #ubuntu-friendly a failed experiment
<thully> hi - well, I finished making my changes to RestrictedFormats wiki... the hoary-extras source won't be good for gstreamer until tomorrow...
<thully> someone mentioned earlier looking into MP2 ripping support, since it's compatible with many MP3 devices - this sounds interesting...
<giskard> hi, one of yours users sent me a mail about a nvu bug (i'm the debian maintainer) saying me (also) that yours "reportbug" on amd64 is buggy  
<giskard> for more info
<giskard> look here : http://pastebin.com/281046
<thully> Earlier here, we were discussing MP2 ripping support as a possible alternative to MP3.. turns out the iPod doesn't support it (which makes it not-that-useful)
<crimsun> mp2 is fairly dubious as an alternative anyhow
<crimsun> it'd be more fruitful to consider musepack (I have prelim packages), but ogg vorbis is really the better choice
<thully> I don't find a format which doesn't work on 90% of players that play digital music files as a really ideal choice... but with the patent situation it may be the best available
<thully> what is musepack, btw?
<crimsun> www.musepack.net
<thully> what's it's advantages over other encoders?
<crimsun> it's the fastest
<crimsun> it's either GPLed or BSDed, depending on which component, so it's DFSG-free
<crimsun> there's a gst plugin
<JanC> AFAIK musepack has problems with patents ?
<crimsun> JanC: no, it used to, but all the code is free now
<thully> From the looks of it, though, it's a format less supported than ogg (as in portable devices etc)
<crimsun> oh definitely, thully.
<crimsun> the only format that's supported en masse is mpeg 1 layer 3
<JanC> the XviD code is also free, but it's still covered by patents...
<thully> yes - I was pretty much wondering if there was another format with no patent encumbrance that works with most MP3 players (other than .wav, or course)
<crimsun> JanC: yes, but the basis of musepack is not patent-encumbered
<JanC> it's based on MPEG1/2, just like "MP3" ?
<thully> however, I don't see the real point of musepack when even ogg has far more support than it
<womble> thully: Not from my research, no.
<crimsun> it had roots in mpeg1/2, but the current code bears no resemblance to them
<JanC> "resemblance of the code" is not important for patents  ;)
<crimsun> JanC: but it's not even based on mpeg1/2 anymore.
<JanC> then it's not compatible with earlier versions?
<JanC> that would be stupid...
<crimsun> there was a break in the versions some time ago
<JanC> but maybe those patents expired together with most of the MPEG 1/2 patents
<thully> I guess most people will be using lame from multiverse to rip music for a while...
<crimsun> not if they use the default Sound Juicer :)
<thully> well - chances are they will try to load those files to their iPod and find they don't work, so they will end up setting up LAME...
<crimsun> sure. Or they might be inclined to use jHymn or something as I do
<thully> yes - but that is only for iTunes store music
<crimsun> indeed. Unfortunately there is no holy grail
<bob2> lifeless: email jurij@wooyd.org
<bob2> lifeless: with your ssh key
<lifeless> done
<tseng> 73% of visitors to my site use firefox
<tseng> the next 8% use mozilla
<tseng> pretty rock.
<|QuaD-_> tseng: what does epiphany come up as?
<tseng> |QuaD-_: mozilla probably. are you a regular visitor to my blog?
<|QuaD-_> tseng: i think i have visited it a few times
<tseng> i dont see any epiphany specific group
<tseng> Camino is last at .1%
<|QuaD-_> i just started using epiphany though, so i wouldn't show up as epiphany
<tseng> i see
<|QuaD-_> i was just curious
<tseng> 3.6% is unknown, could be there
<|QuaD-_> i am looking to see if i can change the browser tag in epiphany
<|QuaD-_> who knows
<|QuaD-_> 61.8% on my site use firefox
<|QuaD-_> 35.9% use ie
<tseng> oh man
<tseng> i only have 5.7% ie :P
<|QuaD-_> i don't even know who views my site
<|QuaD-_> i don't have any content on it
<|QuaD-_> ohh, probably my family, cuz i have a gallery on it
<|QuaD-_> tseng: what type of hosting service you use (like a vds, your own server...)
<tseng> my own server
<tseng> but im beta testing linode.com's xen service
<tseng> which I will be subscribing to as soon as its out of beta
<tseng> their current service is based on uml
<|QuaD-_> tseng: is it in a server farm or your house?
<tseng> my server is colocated, yes
<|QuaD-_> tseng: i want a linode, i kinda thought it was a rip off though
<tseng> its not a rip off at all
<tseng> they house, maintain, and power and connect you to a very nice network
<|QuaD-_> tseng: for $50 i can get a dedicated server
<tseng> you cant buy your own box and colocate it for < $50
<tseng> |QuaD-_: yes, you can.
<|QuaD-_> tseng: if i colocate with 2 people, thats cheaper
<tseng> will you be getting console access?
<|QuaD-_> tseng: no idea, haven't really looked into it
<tseng> and dead-easy distro installs over the web
<|QuaD-_> the shared plan i have now isn't up for 2 months
<tseng> the win for linode is the management as much as the box itself
<tseng> sure you can buy a box from anyone
<|QuaD-_> tseng: yeah, but you get soo little space and bandwith for the price they charge
<|QuaD-_> i was looking at the $20/month plan
<tseng> ive used 2% of my 50gb this month
<tseng> thats after i got family guy and a cd from bittorrent
<tseng> anyway, if its not right for you, great
<tseng> im just a huge fan :)
<|QuaD-_> i use about 30gb a month
<|QuaD-_> tseng: if i got like 5gb space and 100 gb bandwith for the linode 64 plan, i would probably do it
<tseng> 100gb? where are you getting that much I wonder
<tseng> for $20/month
<tseng> i dont know anywhere you can get a psuedo dedicated system for $20
<|QuaD-_> right now, i have shared hosting for $3.95 a month, 150 gb bandwith 5 gb space
<|QuaD-_> tseng: yeah, thats why i don't if vds is for me
<tseng> shared = ftp to a directory?
<|QuaD-_> cpanel account, i hate it, except its sooo cheap, and i am broke
<tseng> well.. im rich :P
<tseng> relative to my situation anyway
<|QuaD-_> haha
<|QuaD-_> tseng: you are running ubuntu on your xen linode/
<|QuaD-_> ?
<tseng> |QuaD-_: yes
<tseng> right now they have a warty image, very easy to upgrade to hoary
<|QuaD-_> tseng: what mailserver?
<tseng> postfix
<|QuaD-_> no experience with hula/
<|QuaD-_> ?
<tseng> i have hula on there also just for kicks
<tseng> but the admin sucks majorly atm
<|QuaD-_> how does it work?
<tseng> oh and my pet peeve
<|QuaD-_> really? i heard it was supposed to be soo simple
<tseng> my other server has an A record
<tseng> and no MX
<tseng> guess what, hula wont send mail to it
<|QuaD-_> haha
<tseng> i think even Qmail will fall back to the A record
<|QuaD-_> is that something they are fixing?
<tseng> ive not gotten involved with upstream at all
<tseng> enough to track with all the mono and gtk# stuff
<|QuaD-_> ohh
<|QuaD-_> so how much ram is the linode you are using?
<tseng> i think he bumped the beta to 128
<|QuaD-_> how do distros run in 64 mb?
<tseng> my friend runs gentoo on it, spent alot of time parring things down with uclibc and all that
<|QuaD-_> i don't follwo
<|QuaD-_> *follow
<tseng> debian i am thinking would be pretty alright if you tamed apache
<tseng> to not spawn a zillion threads
<|QuaD-_> ohhh
<tseng> postfix is very resource friendly
<tseng> by design
<|QuaD-_> i am hoping wherever i live next year, will have fios, and i won't have to worry, and i can host my own server
<|QuaD-_> without any of that colocation buisness
<tseng> we just got that in west chester
<tseng> but i dont think theyll run it to my appt
<tseng> i need the 30gb service injected directly into my vein
<|QuaD-_> i will be living in NYC next year, so i hope i get decent servie
<|QuaD-_> *service
<|QuaD-_> tseng: are the specs for xen linodes going to be the same as for uml ones? (prices and what you get)
<tseng> no idea
<tseng> the hosts look like quad xeons, or maybe dual with ht
<|QuaD-_>  tseng: ok, how did you get hookedu p as a betatesters?
<tseng> |QuaD-_: it was an invite deally
<|QuaD-_> figured that much
<|QuaD-_> i also don't know if i have the knowledge to truely secure a system
<tseng> changes are neither does your current provider :/
<|QuaD-_> tseng: probably, thats why i don't host anything critical on it
<|QuaD-_> tseng: thanks for the info, feels better to get it from someoen who has nothign to gain by telling me
<tseng> rock on.
<tseng> you might actually want something cheap for the time being, makes sense
<|QuaD-_> i don't recall if i told you what i pay, but there is nothing that compare to it, i just hate hte lack of control
<tseng> i have a burning desire to control my own box
<tseng> w/o messing with owning it and colocating anymore
<|QuaD-_> thats my biggest problem
<tseng> that sucks too
<tseng> esp if you dont get a remote console
<|QuaD-_> remote console is what allows you to install isos?
<tseng> no, they have prebuilt disk images
<tseng> you just pick one
<|QuaD-_> oh, yeah, thats nice
<tseng> yeah they have a bunch of distros
<|QuaD-_> there is only one distro for me :)
<tseng> :D
<|QuaD-_> tseng: now you are going to make me waste my money!
<tseng> hey you can cancel later if you dont love it
<tseng> and get some chinsy ftp only access to some black hole
<|QuaD-_> tseng: yeah, i am not worried about loving it
<tseng> for $10/month
<tseng> or whatever
<|QuaD-_> 3.95 :)
<|QuaD-_> which is why i have such a hard time leaving it
<|QuaD-_> eventually, my 1 oss project that i am working on will be hosted on it
<|QuaD-_> but i don't suspect it will get too much traffic
<tseng> my blog gets ~700 unique vistors a month so far, and barely uses any bandwidth
<tseng> are you on jabber and can hit me up? im starting to feel bad about hijacking the chan
<|QuaD-_> tseng: i don't use jabber.... aim?
<tseng> sure
<jnc> look out, he's got a vertical bar!
* lamont grumbles about the size of the ubuntu bugzilla submission  page
<jnc> erg.... libgtkhtml20 missing
<mpt> jnc: Just reimplement it from scratch
<jnc> heh
<jnc> i found it actually in universe
<jnc> it's going to be an officially supported package, looks like... so there's some transitional fooby 
<jnc> it's missing on the mirror i was using
<jnc> very strange
<mpt> jnc: What does it need to be officially supported for?
<jnc> mpt: i don't know, i just spotted it in breezy with one of those official looking icons next to it under a new name, libgtkhtml2-0
<jnc> that's perhaps something very different
<jnc> gnucash relies on libgtkhtml
<mpt> ah
<mpt> and on a whole pile of other stuff I don't have installed
<jnc> it's great for expense
<mpt> Interesting that I had nothing else installed that required bonobo
<jdub> jnc: different versions - most importantly, gnome 1.x vs. gnome 2.x
<jdub> jnc: gnucash is thusly unsupportable
<jnc> ah
<tseng> there is a similar mono app
<tseng> what was that called
<tseng> kurush
<jdub> and another one martin sevoir is working on
<tseng> does it look nice?
<jdub> divifund
<jdub> http://www.divifund.com/
* mpt installs random crack
<tseng> mmm crack
<jdub> we should totally have that in ubuntu
<tseng> we should, how are the depends
<mpt> "The Import tab is still present but inoperable, providing a tantalizing glimpse of the future!"
<tseng> a pygtk
* mpt &heart; open-source marketing
* jdub mails martin
<tseng> this was one of Tim's lowest rated items
<fabbione> morning
<tseng> hiya
<jdub> tseng: ah, but it rated at all :)
<tseng> D+
<tseng> iirc
<tseng> thats generous
<jdub> (small business finance is way more important that personal finance, but this would be good to have nevertheless)
<tseng> small business would be more like what we talked about with crossover
<tseng> at least for a few years
<tseng> freelance hackers arent interested in doing an oss quicken
<tseng> there's no itch
<jdub> martin had an itch - thus divifund :)
<tseng> its a start.
<rnz> is there any plan to implement initng to speed up the boot process in breezy? I can find anything in the wiki. http://jw.dyndns.org/initng/
<jdub> rnz: udu.wiki.ubuntu.com/FasterBoot
<jdub> initng and friends aren't on the agenda at all right now
* fabbione starts digging into cogito
<blueyed> mit welchem dpkg-reconfigure sucht man nochmal die zu installierende keymap aus?
<blueyed> ah.. console-data
<svenl> Mmm, is the fact that mplayer-g4 doesn't ship a mplayer binary a feature or a bug ? 
<svenl> Me guesses it is a bug.
* Amaranth goes to bed
<svenl> fabbione: you there ?
<svenl> fabbione: i want to speak to you about mplayer on ppc.
<Zomb> is there an ubuntu port of debmirror?
<bob2> is there anything to port?
<bob2> I use debmirror to maintain my local Ubuntu mirror
<pitti> Hey folks
<ogra> hi pitti 
<pitti> Hey ogra
<seb128> pitti !!
<ogra> hey seb128 
<seb128> hi
<seb128> pitti: quick hal question for you :)
<pitti> seb128: timeout *hehe*
<pitti> seb128: seriously, what's up?
<seb128> pitti: a friend has an usb key with a fat partition, hal mounts /dev/sdb and /dev/sdb1 for it ... any idea of why it could want to mount /dev/sdb ?
<seb128> that makes 2 icons on the desktop which is ugly
<ogra> seb128, do you know if there is a list if dbus in/output strings for evo (i'm just starting to port evonotify to dbus and pygtk)
<pitti> seb128: I bet he formatted the raw device (without a partition) once
<pitti> seb128: that happened to me, too; unless you properly restore an MBR and the partition table, the hal detection still sees the original fs signatures in the reserved blocks
<seb128> pitti: where is this information? I mean "fdisk -l" displays one partition
<seb128> hum, k
<pitti> seb128: yeah, the fs detection is still buggy
<seb128> k, thanks
<pitti> seb128: probably it would be a good idea to ignore the raw device as a volume if there are partitions
<seb128> yeah
<pitti> seb128: can you ask him to file a bug?
<seb128> done :p
<pitti> seb128: thanks, I'll care about that at some day :-)
<seb128> np, thank you :)
<ska-fan> pitti: Where are the pgsql rpms now? p.u.o/~pitti doesn't work
<ogra> pitti, oh, you provide rpms ?
<ska-fan> s/rpms/debs/
<ogra> heh
<ska-fan> old habit
<seb128> pitti: the guys says the key has never been formated, it shipped like this, already with one partition fat formatted 
<pitti> seb128: hmm, odd; maybe he can dd the first few MBs, gzip them and send them to me?
<pitti> ska-fan: hmm, not?
<pitti> ska-fan: http://people.ubuntu.com/~pitti/psql/  -> everything's there?
<seb128> pitti: dd if=/dev/sdb of=file ?
<pitti> ska-fan: however, p-common is a bit outdated, you should use the Debian experimental version
<pitti> seb128: ... bs=1k count=2048
<pitti> seb128: that will give me the first 2 MB
<seb128> cool, thanks
<pitti> seb128: btw, I'm currently naming my photos, will upload them soon
<seb128> cool
<Nafallo> morning all
<pitti> Hey Nafallo
<ogra> has anybody an idea know why /usr/bin/fakeroot-sysv doesnt work for me ? its obviously the default alternative and just gets stuck silently... /usr/bin/fakeroot-tcp works...
<azeem_> I would have an explanation if you ran GNU/Hurd...
<ogra> azeem_, hmm, probably fabio named the kernel package wrong :)
<azeem_> fakeroot always used to be fakeroot-sysv, FWIW
<ogra> yeah, but i dont get why it stopped to work in breezy
<azeem_> Clint didn't like your new release name, perhaps
<ogra> heh
<pitti> seb128, ogra, doko: http://people.ubuntu.com/~pitti/Sydney-2005/
<seb128> cool
<ogra> yeah
<ogra> pitti, put it on the list: http://www.ubuntulinux.org/wiki/UbuntuDownUnder
<pitti> ogra: it's only our vac, not the conference
<pitti> ogra: but I can put it there anyway
<ogra> hmm.
* ogra wont put the holiday pics there
<ogra> good point
<pitti> anyway, later! have to go now
<seb128> pitti: http://people.ubuntu.com/~seb128/usb_key, the 2M file for the usb key
<seb128> I'll fill a bug with it
<seb128> have a good afternoon pitti :)
<pitti> you too
<HiddenWolf> seb128, ping
<seb128> HiddenWolf: ?
<Nafallo> hehe
<Nafallo> 127_Animals ;-)
<Nafallo> isn't that devils?
<HiddenWolf> seb128, I'm getting rather annoyed at gnome-panel, but I'm not sure how to fix it or how to report a bug about it
<HiddenWolf> I've got a hoary with default settings for the window-list applet, and the tabs seem to 'jump around' a lot, whenever I open or close a window or the title in one of the tabs changes
<HiddenWolf> IE, topic change in xchat, or another song starting in rhythmbox, the tabs do a little shuffle
<kent> HiddenWolf, If im not mistaken, Nafallo had a problem like that yesterday. Perhaps you can talk with him aswell about it to sort it out? 
<HiddenWolf> kent, happen to know when he's on, usually?
<Nafallo> .
<Nafallo> :-)
<HiddenWolf> ah, convenient. :)
<Nafallo> I really can't figure out what we can do about it though.
<Nafallo> seems the problem is all windows in the list must have the same size.
<Nafallo> atleast that's a start on the problem ;-)
<HiddenWolf> It just results in a very eye-catching bit of jumpiness, unfortunatly
<seb128> I've not noticed that
<seb128> but upstream is the right place for this
<Nafallo> seb128: could it be x86_64 specific? :-)
<seb128> there is several bugs open about the windows list applet and the algos for the size/placements of the windows
<seb128> no
<HiddenWolf> nafallo, running x86 here, so no
<Nafallo> oki
<seb128> what do you do to get the "jumping" ?
<seb128> trying right now
<seb128> change songs with rhythmbox doesn't change anything else than the title
<seb128> song
<seb128> another son...
<HiddenWolf> switch between networks in xchat is one
<Nafallo> seb128: I take some screenshoots :-)
<HiddenWolf> I'm connected to my game's clan server, and freenode, jumping from one channel to the other does it
<Nafallo> seb128: http://www.magicalforest.se/~nafallo/tmp/
<HiddenWolf> Rhythmbox does if if you have 2 windows open, and jump from a short songname to a long one and back
<HiddenWolf> more than 2, and I guess the tab min/max sizes kick in.
<seb128> Nafallo: what do you do with this usb_key?
<Nafallo> seb128: that's because of the extra " / #ubuntu-devel (+n)" for xchat's title.
<Nafallo> seb128: only downloaded :-)
<seb128> yeah, but intend to fix it ? :)
<Nafallo> seb128: I'll have a look atleast :-). I'll atleast learn something from every experience :-).
<seb128> k, it does that too here for xchat
<HiddenWolf> seb128, I get it too when jumping from #ubuntu to #ubuntu-devel
<Nafallo> seb128: and you don't get annoyed? ;-)
<HiddenWolf> with 3 windows open.
<seb128> I don't use the list this way
<seb128> I've a fixed min/max size
<seb128> and it doesn't do that with my config
<seb128> I've the same min/max size
<seb128> so the entries always take the same size which is "fixed sized/number of entries"
<HiddenWolf> here it's at 50/4096
<seb128> I know
<seb128> that's not my config :p
<HiddenWolf> but afaik, it's default
<HiddenWolf> and default jumpiness is ugly. :P
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=155870
<seb128> I don't care
<seb128> feel free to send a patch anyway :)
<Nafallo> seb128: hehe. now you sound like a developer ;-)
<seb128> http://bugzilla.gnome.org/show_bug.cgi?id=125023 too
<Nafallo> I've set it to 1000/100 in the meantime :-)
<HiddenWolf> gnome bugzilla is confusing, lol
<Nafallo> ehm 1000
<Nafallo> 1000/1000
<Nafallo> damn enter!
<HiddenWolf> seb128, is there something in gnome that can force an application to start up to notification area and not show its window, or must every application have a setting for that?
<seb128> app
<HiddenWolf> Hm. I'll go file a few bugs then. 
<seb128> HiddenWolf: on what?
<HiddenWolf> seb128, upstream rythmbox/gaim
<HiddenWolf> I have them opening automaticly in my session, but I don't want to see them come up every time.
<ska-fan> it's an application bug.
<ska-fan> gossip does that right.
<HiddenWolf> ugh, wtf is wrong with firefox
<HiddenWolf> I can't type without bringing up the finder.
<HiddenWolf> can anyone here confirm something silly in rhythmbox for me?
<HiddenWolf> it won't sort by play count decending for me if I have selected an album/artist. It will do it right when i've selected all/all in browser
<HiddenWolf> playcount ascending only... :S
<zyga> hello
<zyga> did anyone see the lates firefox exploit?
<tseng> zyga: THOM IS A SLACKER
<tseng> erm
<tseng> yes.
<thom> tseng: screw you hippy :P it's uploaded for hoary already
<thom> all 8 exploits
<thom> kthxbye
<tseng> thom: <3 !
<thom> ;-)
<zyga> tseng: err? :-)
<zyga> thom: is it patched?
<zyga> thom: or is it 'uploaded with those 8 exploits'?
<tseng> with them fixed
<zyga> really?
<zyga> wow amazing :-)
<Nafallo> hehe
<Zomb> bob2: nothing to port? it does not work!
<Zomb> Failed to download some Package, Sources, Contents or release files!
<Zomb> must be confused with bzip2 compression
<Zomb> hm, no, looks like missing gpg verification caused that
<thully> what is "MOM is awake" supposed to mean?  It sounds kind of funny...
<tseng> merge-o-matic
<thully> funny...
<thully> has anybody looked into making default font changes in the next release?  I have a few ideas for this...
<thully> Mostly, making fonts smaller (as Firefox's default fonts, for instance, are HUGE on my laptop)
<bluefoxicy> ok so how come on my laptop I hibernate and it comes back fine
<bluefoxicy> but on my desktop I hibrenate and booting actually boots?
<bluefoxicy> suspend to swap, but then boot instead of resume?  :(
<azeem_> wrong kernel command-line?
<bluefoxicy> the kernel command line on my laptop doesn't have a resume=
<thully> bluefoxicy: did you upgrade your desktop from Warty?
<bluefoxicy> the kernel bitches, but grabs it anyway
<bluefoxicy> thully:  yeah I think.
<thully> if so, read the Hoary release notes - you have to fix something for suspend-to-disk to work
<bluefoxicy> for the record that should NOT matter.
<bluefoxicy> where are these release notes?
<azeem_> first hit on google
<bluefoxicy> thanks.
<bluefoxicy> ah
<bluefoxicy> "If a user clicks anywhere on a specially crafted page, this code will automatically create and execute a malicious batch/exe file."  <-- In other news, Microsoft would like to help, and will be issuing patches some time in June of 2007
<bluefoxicy> oh, is there an emergency shell hack in the initrd btw?
<bluefoxicy> so that I can get into my amd64 system without the . . .oh.
<bluefoxicy> nevermind, there's no way to get to the sata module andload it from the initrd :/
<bluefoxicy> well.  LiveCD time.
<thom> bluefoxicy: uh, just load the rescue option from grub
<bluefoxicy> thom:  the initrd was built on a pata hard drive
<bluefoxicy> so the kernel can't find the sata
<bluefoxicy> there's no module for it and it panics trying to load the root fs, inable to find /dev/sda7
<thom> woot; new bootchart doesn't use top and iostat anymore
<jiyuu0> if [ `cat file | grep something` == "" ] ; then
<jiyuu0> i'm gettin this error
<jiyuu0> test.sh: line 1: [: too many arguments
<jiyuu0> any idea?
<tfheen> you probably want to do if [ "$(grep something file)" = "" ] 
<tfheen> == is a bashism
<tfheen> cat file | grep something is better written as grep something file.
<Clint> and you probably want -z instead of = ""
<tfheen> and you need to use "" if it expands into more than one word.
* jiyuu0 tryin
<jiyuu0> thanks all :)
<tfheen> also, I find $(command) more readable than `command` and it's easier nestable.
<Clint> but really you should just use the return code of grep
<thom> is there any way to get nm to show the version of a symbol?
<ska-fan> Which package do I need to install for man 2 stat?
<thom> manpages-dev
<Lathiat> tseng: humm, trying to run various windows.forms programs i get an erro from gdi about unsupported image formats, is there something i need to install? [it worked on an svn build so uh i have nfi] 
<tseng> our libgdiplus is old
<tseng> for one.
<tseng> i dont touch winforms myself
<tseng> last i tried gdiplus from alioth it ftbfs
<tseng> its at the bottom of my list
<Lathiat> ah ok
<dholbach> hai
<seb128> daniel :))
<dholbach> sbastien! :-)
<dholbach> mako: hey, any plans on a specific time for the CC on tuesday?
<mako> dholbach: good point
<dholbach> yes :-)
<mako> i'm been hacking all weekend on my paper on ubuntu for linuxtag
<ogra> hey, in case anyone is interested in this: http://www.divifund.com/
<ogra> www.grawert.net/divifund_0.62-0ubuntu1_all.deb
<dholbach> because i'd be very sorry, if somebody of the folks that attended last time wouldn't be member, when they miss this one
<dholbach> mako: i don't blame you :-)
<mako> dholbach: people that attended last time don't need to attend again
<mako> ogra: is it any good?
<dholbach> magnon: ok
<ogra> mako, at least it works 
<mako> ogra: that's not really good enough :)
<ogra> its not gnucash
<mako> hmm
<mako> gnucash is pretty good.. but it's also kind of gtk1
<ogra> yep
<ogra> that thing is clean pygtk
<dholbach> and it's broken every other day
<ogra> so easy to extend
<dholbach> ogra: put it on MOTUNewPackages and i give it a spin
<ogra> dholbach, i'll do...
<dholbach> i think reviewing will be the MOTU thing i have to jump in next
<dholbach> the lists are pretty full
<tseng> hi dholbach 
<dholbach> hey tseng 
<tseng> ogra: working f-spot hopefully tmw
<ogra> yay
<dholbach> mako: if you know a time, please tell me, and i'll tell the MOTU guys, change in on wiki/Calendar, #ubuntu-meeting and wiki/CCAgenda
<mako> dholbach: give me a second
<dholbach> sure
<opi> !seen smurfix
<opi> no seen option, it seems :-)
<ska-fan> ogra: you packaged?
<ogra> ska-fan, divifund ? 
<ska-fan> yes
<ogra> yop
<ska-fan> rm:   `/usr/share/divifund/*.py': No such file or directory
<ska-fan> with dpkg -i divifund...deb
<ogra> argh
<ogra> ok
<ska-fan> this is hoary
<ogra> its a packaging error
<ska-fan> ogra: ping me if you want me to test a new version :)
<opi> ska-fan: are you a true ska fan? :-)
<ska-fan> opi: not really, I just like No Doubt
<ska-fan> They are not so ska any more
<opi> ska-fan: No Doubt was a ska band ;p
<opi> ska-fan: but that's offtopic :-)
<ska-fan> Hmm, strange bug
<ogra> ska-fan, package updated
<ogra> (same name/version)
<du3-cc> hi ppls
<du3-cc> r u developing an own version usplash?
<tseng> how do you mean, our own version
<tseng> afaik ubuntu is the only group persuing something called usplash
<du3-cc> the original one is now called splashy.. thats why i asked..
<thom> no, the original one is the one we wrote in oxford a year ago
<du3-cc> hmm
<cartman> wonder usplash will work with custom kernels?
<du3-cc> if its really userspace.. then it have to..
<du3-cc> but why the renaming..
<du3-cc> is there an ubuntu project for that?
<cartman> http://www.ubuntulinux.org/wiki/USplash maybe
<Lathiat> the only problem with working with custom kernels will be framebuffer support, as long as it has that its fine.
<thom> http://udu.wiki.ubuntu.com/USplash 
<cartman> Lathiat: ah I compile in framebuffer support
<cartman> only problem with Ubuntu kernel is that it has no logo
<cartman> I miss cute penguin
<Lathiat> i hate that stupid penguin. :)
<cartman> bah :=
<cartman> :)
<Lathiat> its a hack anyway
<Lathiat> if you switch vts it goes away and then sometimes you get weird issues with that
<cartman> I don't touch VTs unless its gone by itself :)
<ska-fan> ogra: Works (that is installs and runs now) but it seems veeery unfinished
<ogra> ska-fan, it computes the numbers and exports to gnumeric...thats a start :) i just want it in universe, if there is a source package and someting to demo-run, people are more likely encouraged to work on someting ;)
#ubuntu-devel 2005-05-17
<cartel_> hey all 
<cartel_> where is the list of all work that needs to be done for breezy
<tseng> cartel_: hm on udu.wiki.ubuntu.com
<tseng> cartel_: MOTUTodo on the main wiki
<cartel_> thx
<toresbe> Hmmm
<toresbe> Ubuntu needs a cool GUI filesystem/partition manager
<tseng> that came up a bit at UDU
<toresbe> seems like a fun thing to write
* toresbe gets off his arse and does a series of things he should've done long time ago
<toresbe> I have already cleaned my desk
<toresbe> ...sort of
<diamond> elmo: hey. can you tell me when the community council meeting is on at on the 10th? the wiki page just has ???? in for time...
<mdz> toresbe: take a look at gparted
* toresbe would like to make some useability improvements
<mdz> toresbe: in that case, please also look at http://udu.wiki.ubuntu.com/GraphicalPartitioningTool :-)
<toresbe> Are we concidering using gparted in the installer?
<mdz> it is more or less decided that it will be used to provide an 'advanced partitioning' mode in UbuntuExpress
<toresbe> okay
<cartel_> UbuntuExpress?
<toresbe> is there a streamlined process to resize the Windows partition?
<toresbe> http://udu.wiki.ubuntu.com/UbuntuExpress
<toresbe> does the installer even give the user an idea of what a partition even is?
<mdz> toresbe: http://udu.wiki.ubuntu.com/InstallerSimpleResize
<jsgotangco> morning
<tseng> hi.
<jdub> "Ubuntu's kernel enables SATA ATAPI support, which Jeff Garzik tells me is a bad naughty thing of them to do since it's not ready yet."
<jdub> fabbione: ^ ;-)
<jsgotangco> morning jdub :)
<jdub> morning
<Lathiat> heheh
<tseng> hi jdub 
<tseng> get naughty!
<jiyuu0> any idea?
<jiyuu0> Error loading internal Browser!
<jiyuu0> No more handles (java.lang.UnsatisfiedLinkError: /opt/rssowl_linux_1_1_bin/libswt-mozilla-gtk-3127.so: libxpcom.so: cannot open shared object file: No such file or directory)
<Burgundavia> can I close as not a bug?
<Burgundavia> nev mind, done
<jdub> morning mdz 
<stuNNed> oh ok so NM(Network Manager) is the correct approach, cool, should we see NM upgraded in Hoary or just in Breezy?
<bob2> hoary isn't going to get random feature updates
<bob2> especially highly disruptive ones
<stuNNed> ok thanks bob2 
<whiprush> bob2!
<bob2> aloha
<fabbione> morning
<bob2> you broke your daily blog promise!
<jsgotangco> whiprush, hey long time no see
<whiprush> I've been sick. :(
<jsgotangco> waaa
<jsgotangco> a lot of people have been sick since UDU
<daniels> indeed
<womble> Ubuntuitis...
<whiprush> I was awesome though, only worked 2 days last week.
<whiprush> I have a -2 balance of sick days now
<schweeb> bastard tried blaming it on me.
<infinity> I'd love to know who to blame.
<infinity> I'm almost over the UDUFlu though.
<whiprush> i wonder if it was sladen
<whiprush> he was pretty sick
<whiprush> and he stayed in my room
<fabbione> infinity: you too??
<fabbione> infinity: blame gtk!
<womble> I think it came in from LCA -- there were a few people a bit crook after that (myself included) that didn't go to UDU
<whiprush> hhmm, I didn't know everyone else was sick
<whiprush> I thought it was just me
<jsgotangco> hmmm some got it worse
<daniels> yeah, it spread throughout LCA and then UDU
<daniels> the thing is, though, it started with Ubuntu people
<daniels> spread to mainly Ubuntu people at LCA
<infinity> Joy.  Well, find me the source, and I'll send them a lovely letterbomb.
<daniels> so UDU just made that so much worse
<jsgotangco> fabbione, you ok now?
<whiprush> yeah seriously
<daniels> infinity: flubuntu
<infinity> I've been hacking up phlegm for the last week.
<daniels> infinity: i got it off thom
<daniels> infinity: i was pretty sick at lca, and i'm still hacking up phlegm to this day
<toresbe> heh
<bob2> me too
<fabbione> jsgotangco: still coughing a lot
<bob2> so we can blame thom now?
<infinity> Blaming thom does seem to be the status quo.
<jsgotangco> heh
<whiprush> I can go along with this
<whiprush> gargling salt water and nyquil have kept me sort of normal
<infinity> I've never met anyone on NyQuil that I'd call "normal".
<infinity> "loopy", perhaps.
<whiprush> it passes the time
<jsgotangco> whiprush, time to get to work on those specs tee hee
<whiprush> heh yeah
<jdub> pants off whiprush 
<jdub> hope you're feeling better
<jdub> seems everyone got it
<whiprush> pants very much on
<whiprush> with sheets
<whiprush> and pillows
<fabbione> it must have been the keysign party..
<fabbione> let's blame mako!
<whiprush> and the thermostat cranked up to as high as it goes
<Burgundavia> jdub, sorry to bug you, but I need to move the docteam portal forward, and I was wondering who I need to contact
<infinity> daniels : You may be interested to know that, despite their reputation for shooting every{one,thing} on sight, the Victoria Police are really quite nice.
<daniels> infinity: ...
<infinity> daniels : I had to get them to fingerprint me for a criminal records check.  The Queensland Police were going to charge me 100 bucks for the privilege, the Victorian Police did it for free.
<daniels> infinity: they arrest you for immigration violation?
<daniels> oh, sweet
<jsgotangco> whoa
<jdub> Burgundavia: i don't have any idea what you're talking about, unfortunately
* Burgundavia grumbles in frustration
<Burgundavia> jsgotangco, did you not corral a dev at UDU about this
<daniels> infinity: you'll be pleased to know that Jarrod is now working on extracting gold from a whole bunch of teeth
<jsgotangco> Burgundavia, no i didn't i thought the portal was already requested
* Burgundavia grumbles further
<Burgundavia> jdub, can you join #ubuntu-doc quickly?
<infinity> daniels : <blink>
<jsgotangco> whiprush, nice blog summary heh
<whiprush> i got more pics
<jsgotangco> where?
<whiprush> not up yet
<jsgotangco> ok
<whiprush> I got a good one of luis thrusting his pelvis at the camera
<whiprush> it's totally horrible
<daniels> heh
<dholbach> morning
<jsgotangco> dholbach, hey
<bob2> 'morning
<dholbach> hey jsgotangco, bob2 :-)
<dholbach> mako, Kamion, elmo: could you please agree on a date and time for the CommunityCouncil - i fear it will be a bit late to say to everybody "it will be tomorrow"
<bob2> jesus christ the ctrl-u binding in firefox is annoying
<mdz> jdub: morning
<Lathiat> whats it bound to?
<bob2> "display source for this page"
<dholbach> hey mdz 
<bob2> instead of "delete this line of text"
<mdz> dholbach: hi
<fabbione> hey mdz
<TheMuso> Is anybody around that was at the accessibility roadmap BOF at Udu?
<TheMuso> I have a couple of questions to ask about the spec.
<jsgotangco> JaneW, hey!
<JaneW> hi jsgotangco ;)
<ajmitch_> hi
<fabbione> hey JaneW 
<dholbach> morning JaneW!
<JaneW> morning, morning
* JaneW 's car wouldn't start this morning
<JaneW> has to figure out how to fix it - I have a 09:30 meeting... ack
<jsgotangco> you can try pouring redbull in the engine but...
<JaneW> bendex is stuck, so can't even push-start it.... : (
<JaneW> jsgotangco: ;)
<tfheen> hi JaneW
<dholbach> JaneW: you have a HUGE fan club ;-)
<dholbach> morning tfheen :-)
<tfheen> hi daniel :)
<daniels> tfheen: hey dude
<Lathiat> its tfheen 
<daniels> dholbach: yo
<dholbach> hey daniel
<dennis__> who chose to take out python out of the openoffice package :-)
<daniels> oh man, breezy kickoff meeting is at 5am
<Lathiat> daniels: 3am here!
* tfheen waves some more then goes to get breakfast
<dholbach> dennis__: it must have been a very sensible person... shipping ones own python gives me the collywobbles
<dennis__> dholback, well there is an easy way to just use the existing python, but that would mean we'd have to pass an extra compilation flag 
<dennis__> to the python compile
<dennis__> it's like -use-shared or something like that
<dholbach> dennis__: sorry for flaming... i'm absolutely no expert on openoffice
<dennis__> oh, it's cool
<dennis__> hmm, i'm just not happy with the way it is right now, we should either compile python with the shared option or we should leave python in OO
<dennis__> who maintains oo?
<mako> dholbach: hey dude, not everyone has been online.. lets do it at the standard time.. 1600UTC tuesday
<mako> dholbach: one last time :)
<dholbach> mako: perfect
<mako> dholbach: i wanted to move the new times, but we can wait until two weeks from taht to confirm it
<mako> i'll send out a letter 24h before announcing it
<mako> i.e., tomorrow
<dholbach> erm?
<ajmitch_> mm, 4AM, got to be good
<dholbach> no CC meeting tomorrow then?
<mako> dholbach: oh right.. tomorrow for YOU
<mako> dholbach: day after tomorrow for me :)
<dennis__> dholbach, should i submit a bug report for that?
<mako> dholbach: it still sunday night here
<Lathiat> eek
<Lathiat> its 2pm monday here
<mako> Lathiat: y'know.. timezones
<dholbach> mako: alright: Tue 10 May 16:00 UTC then?
<Lathiat> yarr
<mako> dholbach: yes.. where are you changing it?
<fabbione> hey guys
<dholbach> dennis__: doko and haggai did, afaik
<fabbione> we are trying to vote for a kernel release name
<dholbach> mako: #ubuntu-meeting, CommunityCouncilAgenda and wiki/Calendar
<Simira> morning, fabbione 
<fabbione> if you have some cool ideas, you are welcome to join #ubuntu-kernel
<fabbione> hey Simira 
<dholbach> mako: excusez-moi
<mako> it's fine :)
<mako> i'm gonna have to clean up the agenda tomorrow
<jsgotangco> jeeezz 19:00 UTC that's 3am here
<fabbione> mako: are we starting again from 16:00 UTC or is that the unchangable time?
<dholbach> fabbione: last meeting at static-16:00-utc
<Lathiat> 16:00 is midnight here
<Lathiat> not tha ti care
<Lathiat> whats this for anyway?
<fabbione> dholbach: ok thanks..
<jsgotangco> Community council
<Lathiat> ah
<jsgotangco> 16:00 isn't so bad its midnight
<dholbach> mako: changed the times
<jsgotangco> but the breezy meeting its 3am argghh
<Lathiat> jsgotangco: where do you live?
<Lathiat> same timezone as me. :)
<jsgotangco> Lathiat, Manila
<mako> dholbach: dholbach cool, thanks
<Lathiat> wheres that?
<Lathiat> im perth, western aust
<mako> jsgotangco: we'll switch to better times for hte next meetings
<jsgotangco> Lathiat, Manila, Philippines same timezone as Perth
<Lathiat> yarr
<Lathiat> bali too i think
<Lathiat> and tiapai ior something
<Lathiat> taipei?
<jsgotangco> taipei, HK, malaysia, singapore, china, brunei i think
<dennis__> libpython (which is what you get  when you compile python with --enable-shared) isn't anywhere in a seperate package, eh?
<dholbach> every python2.x-dev has it
<dholbach> erm... drop the "-dev"
<dennis__> yea, i just found it with locate, i'm trying to follow these instructions but they have it all ind different places
<dennis__> thanks though :-)
<dholbach> dennis__: de rien... :-)
<dennis__> the thing is i'm trying to assemble some instructions that can be executed for people who want to use open office's python plugin but i've never done anything like it before
<dholbach> sounds like we need a OOo team :-)
<dennis__> i would even be on it, i'm planing to do a lot of work with oo in the near future
<dennis__> i want to write some plugins and stuff
<dholbach> starting a team might be the best first step
<dholbach> hey pitti 
<fabbione> hey pitti
<pitti> Morning everybody
<dennis__> dholbach, is that all the buearocratic stuff behind it ;-)
<fabbione> pitti: should we spend sometime on hotplug?
<fabbione> so that i can push the new kenrel in?
<dholbach> dennis__: don't think so... but you have to be a bit in a pioneer atmosphere
<dholbach> dennis__: i wrote a small Team Howto on the wiki
<dennis__> dholbach, how likely is it that people would actually join me?
<pitti> fabbione: yeah, would be nice to make it working soon
<dennis__> because i myself know way to little about package maintainance to do all that
<pitti> fabbione: here the problem is that sd_mod is not loaded automatically
<fabbione> pitti: yeah.. should we focus a couple of hours on it?
<pitti> yeah, in some minutes?
<fabbione> pitti: let's make it 20?
<pitti> ack
<dholbach> dennis__: it depends on you, i guess you'd have to be patient in the early days of the team
<fabbione> roger that
<dholbach> dennis__: i suggest you talk to doko and haggai before
<dennis__> where are the LD_LIBRARY_PATH and PYTHONPATH defined?
<pitti> fabbione: btw, your flu is better now?
<pitti> fabbione: or, rather, worse, and you are better? :-)
<dennis__> dholbach, are theey in here?
<fabbione> pitti: i am still coughing a lot..
<fabbione> pitti: but i will manage
<dholbach> dennis__: they normally are, dunno if they're awake yet
<dennis__> you guys are all in europe huh
<fabbione> dennis__: no.. but EU is awake now
<dholbach> dennis__: haggai and doko are
<dennis__> ok ok
<dennis__> it's almost midnight here
<fabbione> bbl
<dholbach> i'm off to uni - see you later
<dholbach> dennis__: good luck
<pitti> infinity: here?
<infinity> pitti : Yes, but not overly coherent.  I'm trying to do things I know even retarded monkeys can do, for fear of screwing up if I try to do anything that requires brainpower.
<infinity> pitti : In other words, The Flu still owns my soul.
<dennis__> dholbach, ha uni sounds german, where is that howto
<dennis__> i can't find it
<pitti> infinity: uh, that's bad to hear
<infinity> Less bad for you than for me, I suspect. :)
<dholbach> dennis__: http://wiki.ubuntu.com/MOTUTeamHowto
<ajmitch_> hi jbailey 
<pitti> Hi jbailey 
<jbailey> Heya Andrew, Martin, everyone. =)
<fabbione> hey jbailey 
<tfheen> Jeff :)
<dholbach> bye
<fabbione> pitti: ok i started some debugging
<fabbione> apparently hotplug is not calling the scsi agent at all
<crimsun> that would explain why a lot of people can't mount their usb "sticks"
<pitti> Hi astharot 
<pitti> Hey npmccallum 
<pitti> npmccallum: I mailed you about pmount
<npmccallum> pitti: yeah, I just got it
<npmccallum> I was thinking it may be cool to have a pmount page with patches for the various apps... I've isolated patches for eject, gnome-vfs, etc that could go on there
<fabbione> pitti: i think i found the problem
<fabbione> pitti: but i don't understand why it was not triggered with the old hotplug
<pitti> fabbione: I get " no runnable /etc/hotplug/module.agent is installed"
<pitti> fabbione: btw, it works with the sid version
<npmccallum> pitti: I'm going to bed, i'll email you tomorrow
<fabbione> pitti: ah...
<fabbione> there is no module.agent!
<pitti> fabbione: right, but that error message is from the sid versino
<pitti> fabbione: so it's probably harmless (you can probably add a module agent to do nonstandard things)
<pitti> fabbione: I think I know where the error is
<pitti> fabbione: /etc/hotplug/hotplug.functions -> sid does not use grepmap
<fabbione> pitti: if i run scsi.agent manually, it errors out
<pitti> fabbione: at least that's a significant difference
<fabbione> hmm interesting
<pitti> hmm, breezy version without grepmap still does not work
<fabbione> i think the problem is hidden in scsi.rc/scsi.agent
<fabbione> or better.. scsi.agent
<fabbione> pitti: we need to look at usb.*
<pitti> fabbione: btw, the diff between sid and breezy looks phearphully
<pitti> fabbione: maybe this should be cleaned up, and our changes should be reapplied manually
<pitti> Hallo mvo
<mvo> hey pitti 
<mvo> morning all
<jsgotangco> hey
<fabbione> pitti: it is really weird
<fabbione> pitti: the scsi.* is never called
* pitti has a crazy idea and tries that
<pitti> fabbione: HAHAHA, got it
<fabbione> pitti: what was?
<pitti> fabbione: look in /etc/hotplug/scsi.agent
<pitti> fabbione: in the "case "$TYPE" in"... block, do s/MODULE/MODULES/
<pitti> fabbione: then unplug and replug your USB stick
<pitti> fabbione: it does:
<pitti>     0)          TYPE=disk ; MODULE=sd_mod ;;
<pitti> ...
<pitti> but
<pitti>     for MODULE in $MODULES; do
<pitti> (later)
<fabbione> yes i can see that
<fabbione> hmmmm
<pitti> fabbione: indeed
<fabbione> so why was it working in hoary?
<pitti> fabbione: I just took a look at the diff between sid and breezy
<pitti> --- sid/etc/hotplug/scsi.agent  2005-04-07 18:37:22.000000000 +0200
<pitti> +++ breezy/etc/hotplug/scsi.agent       2005-04-15 15:39:48.000000000 +0200
<pitti> @@ -12,6 +12,12 @@
<pitti> @@ -34,15 +40,15 @@
<pitti>      read TYPE < $TYPE_ATTR
<pitti>      case "$TYPE" in
<pitti>      # 2.5.51 style attributes; <scsi/scsi.h> TYPE_* constants
<pitti> -    0)         TYPE=disk ;     MODULES=sd_mod ;;
<pitti> +    0)         TYPE=disk ; MODULE=sd_mod ;;
<pitti>      # FIXME some tapes use 'osst' not 'st'
<pitti> -    1)         TYPE=tape ;     MODULES=st ;;
<pitti> +    1)         TYPE=tape ; MODULE=st ;;
<pitti> fabbione: it seems that the name was changed in a later sid version, but the merging used the old name
<fabbione> ah ok
<fabbione> pitti: are you going to upload?
<pitti> fabbione: besides, the diff is really messy
<pitti> fabbione: I'd rather like to clean up the diff altogether
<pitti> fabbione: yes, I can do that
<fabbione> pitti: ok.. otherwise i can do it...
<fabbione> up to you
<pitti> fabbione: the current state will make further merges just harder
<fabbione> you know how much workload you have
<fabbione> make sense
<pitti> fabbione: my workload is at 110%, as ever :-)
<fabbione> pitti: ehhe same here
<pitti> fabbione: btw, it seems that the only real diff is the grepmap addition and LSB
<fabbione> pitti: i suggest we upload a simply fixed hotplug for today
<fabbione> so i can unleash the kernel
<pitti> fabbione: and clean up later?
<fabbione> and we can cleanup later
<pitti> okay, would work for me
<fabbione> yes
<pitti> fabbione: I want to see the new crack :-)
<pitti> fabbione: btw, is there a bug for this?
<fabbione> pitti: yes....
<fabbione> i just can't remember the number
<fabbione> but it was assigned either to udev or hotplug
<pitti> fabbione: #9913?
<pitti> fabbione: maybe also #10034
<fabbione> specially so close to release, changing a build-dep of a core package such as X
<fabbione> iops
<fabbione> pitti: checking now
<fabbione> pitti: 9913 for sure
<seb128> pitti: speaking about new crack, dbus/hal ... waiting on daniels ?
<pitti> fabbione: I ask the submitter of the other one anyway
<pitti> seb128: yes, still; now I even need dbus 0.33 for hal 0.5.1
<pitti> btw, good idea... daniels, here?
<fabbione> pitti: looks about right for 10034
<fabbione> pitti: ok.. tested here.. the fix works
<pitti> thanks
<pitti> fabbione: bah, that is soooo wrong; upstream uses MODULE (and no loop), then one patch in debian/patches changes the loop variable without changing the assignments, and another patch (which I did not yet find) finally corrects the assignments in Debian 
<pitti> that package is a mess...
<fabbione> pitti: no! really???
<fabbione> ;)
* p0m waves to Treenaks
<jeld> hello all
<seb128> elmo: evince (it Build-Depends on libdjvulibre-dev which is universe atm), seahorse from exp, file-roller exp syncs please
<seb128> dholbach: !!
<dholbach> re
<dholbach> hey seb128 :-)
<jeld> how can I specify which compiler to use when building a deb? Should I patch the Makefile.in or can I somehow tell debian/rules which one to use?
<pitti> fabbione: fixing the patch would have made the package even messier, so I couldn't resist from cleaning up the package now; but I'm almost done :-)
<pitti> Hi dholbach 
<jeld> or is this a wrong channel to ask?
<dholbach> hey pitti, koke! :-)
<fabbione> pitti: eheh eok...
<fabbione> pitti: i still need to find the kernel release name
<fabbione> and i am done with this amount of crack
<koke> hi all!
<pitti> fabbione: the debdiff between Debian and Ubuntu looks reasonable now
<fabbione> pitti: any suggestion?
<pitti> fabbione: Carnivore Carrot *hehe*
<fabbione> ahhaha
<fabbione> something that explain that is pure crack
<dholbach> jeld: can't you fix it to compile with the current compiler?
<pitti> fabbione: Kracky Kernel
<dholbach> pitti: "Krack" is reserved for KDE :-)
<pitti> oh, right
<fabbione> KDE Kernel?
<fabbione> :)
<jeld> dholbach, probably not, the build system is rather complicated and it needs g++-4.0
<pitti> fabbione: OHOT, a meat eating carrot is crack enough...
<pitti> OTOH, even
<fabbione> i want to reserve the vegetables for hoary
<fabbione> :)
<dholbach> jeld: i suggest you wait for tonight's meeting - we'll discuss the proceedings of the C++ transition as well
<jeld> dholbach, :)
<hunger> dholbach: Is that a IRC meeting or something internal?
<jeld> dholbach, trying to get wxWidgets/wxPython 2.6.0 packages to build
<dholbach> #ubuntu-meeting as announced on the mailing list
<dholbach> http://wiki.ubuntu.com/Calendar
<hunger> dholbach: Oh, so I need to get onto the MLs as well...
* hunger grins.
<dholbach> hunger: what ever you think you need :-)
<dholbach> jeld: nice, so you'll be the new maintainer for it? :-)
<jeld> dholbach, hopefully not, the package is complicated as hell and I am rather new to the whole package building scenery :)
<dholbach> jeld: i can tell - i built it 3-4 times :-)
<ogra> hi all
<jeld> dholbach, the 2.6.0 version?
<Treenaks> morning ogra 
<dholbach> jeld: no... don't remember which one :-)
<dholbach> hey ogra 
<dholbach> hey Treenaks 
<Treenaks> hi dholbach 
<pitti> Hi ogra 
<jeld> dholbach, OK, gotta catch some sleep, (5AM here) see you around, thanx for the help. BTW, will there be a meeting summary posted somewhere?
<dholbach> jeld: i suppose so, at least irclogs will be on  http://people.ubuntu.com/~fabbione/irclogs
<jeld> dholbach, cool
<fabbione> something is really wrong with perl
<dholbach> jeld: sleep tight
<dholbach> fabbione: tell us something new :-)
<fabbione> dholbach: no no.. i mean with the packing....
<dholbach> ah... ok
<astharot> ciao
<fabbione> oh cute!
<pitti> fabbione: Accepted hotplug 0.0.20040329-22ubuntu2 (source)
<fabbione> perl is FTBFS on all arches other than sparc
<fabbione> that makes sparc buildd not being able to install build-essential
<fabbione> hence the mess
<fabbione> pitti: yup... i saw the message :)
* fabbione summons doko
<dholbach> poor doko
<seb128_> elmo: evolution-webcal sync please
<hunger> Could someone please update lvm2 to depend on libdevmapper1.01? Thanks!
<Riddell> elmo: would you be able to set up a subversion archive on novo for kubuntu?
<fabbione> hunger: does it break anything for you?
<hunger> fabbione: Nope, but it is the only reason to have libdevmapper1.00 on the system.
<hunger> fabbione: I'll write a low prio bugreport.
<fabbione> hunger: there is no rush.. it will happen automatically
<Burgundavia> there is some really odd stuff happening with 1.00
<fabbione> Burgundavia: such as?
<fabbione> if so, please open bugs....
<hunger> fabbione: I guess there is a reason why someone made a bugfix release though. And since lvm is somewhat critical for me I'd like to have those.
<Burgundavia> fabbione, not being built for breezy? Is that part of the changeover?
<fabbione> Burgundavia: eh????
<Burgundavia> not conflicting and thus being removed
<Kamion> hunger: in case nobody answered, the reason g++ isn't 4.0 yet is that switching to 4.0 involves a complicated transition. We'll be doing it, but it's not something you "just do".
<Burgundavia> fabbione, it is not in the breezy repos
<Burgundavia> fabbione, and it did built, it is just not there
<hunger> Kamion: Thanks for the info.
<fabbione> Burgundavia: lvm is in the breezy repo.. otherwise i won't even be able to boot this workstation
<Kamion> hunger: I wouldn't bother filing an lvm2 bug; it's already been updated but didn't build
<Burgundavia> fabbione, libdevmapper1.00 is not the repo though
<hunger> Kamion: Somebody pointed me to the plan on gcc 4.0 migration.
<fabbione> no because it has been obsoleted by 1.01
<fabbione> or whatever version
<Burgundavia> fabbione, but 1.01 doesn't conflict with 1.00, so it is not being removed
<fabbione> Burgundavia: it doesn't need to conflict...
<Kamion> http://people.ubuntu.com/~lamont/buildLogs/l/lvm2/2.01.04-5/lvm2_2.01.04-5_20050505-2204-i386-failed
<hunger> fabbione: ... which can not get uninstalled ...
<Kamion> hmm
<Burgundavia> fabbione, but it being left as a locally installed package
<fabbione> Kamion: it probably needs a kick back
<hunger> fabbione: ... and thus has its start/stop scripts still around, so this is very noticable:-)
<fabbione> Kamion: jb fixed libdevmapper and as a consequence we need lvm to be kicked
<Kamion> libdevmapper1.00 has *init scripts*? in what universe?
<fabbione> Burgundavia: dude.. there is really nothing bad in it. It is a few days transition.. live with that...
<fabbione> otherwise run hoary
<hunger> Kamion: Only in ubuntu...
<Kamion> my god
<Burgundavia> fabbione, am not concerned
<Kamion> hunger: incorrect
<fabbione> Kamion: eh???
<hunger> Kamion: Never saw that before...
<Burgundavia> fabbione, just wondering
<fabbione> it's lvm2 that has init scripts
<Kamion> hunger: it's unchanged from Debian to Ubuntu
<Kamion> fabbione: apparently not
<fabbione> Burgundavia: there is nothing to be worried about
* fabbione scratches his head
<Kamion> -rwxr-xr-x root/root      1303 2005-02-20 15:56:19 ./etc/init.d/libdevmapper1.01
<Burgundavia> fabbione, didn't think so
<fabbione> oh god
<Kamion> at least it's got a versioned name :-) it looks pretty harmless anyway
<fabbione> Kamion: ahaha
<chmj> hahaha
<hunger> Kamion: It is.
<Kamion> is what?
<chmj> doko, ping 
<hunger> Kamion: it is not critical.
<Kamion> oh, right
<Kamion> elmo: hm, would it make sense for me to move the report-only britney run to rookery?
<Kamion> elmo: then (a) we have less code running on jackass (b) it's easier for me to control exactly what gets output from the britney run (c) we don't have this strange "run in one place, mirror to another" thing
<elmo> Kamion: um, I guess.  main problem with that is that rookery is only updated 4 times a day or so
<elmo> I could update it more often but then we get into locking/needing-triggered issues, not to mention the increased load on either jackass or syncproxy
<ogra> oh, elmo
<Kamion> hmm, ok, that would be an issue
<ogra> elmo, could you push gtk-sharp out of dep-wait.... (with furry gloves) to have it built on amd64 now that mono is there ?
<Kamion> elmo: in that case could I just have s/hoary/breezy/ on line 78 of /srv/ftp.no-name-yet.com/testing/britney please?
<Kamion> I might do a universe-only britney run on rookery at some point - it's probably ok for that only to be updated four times a day
<elmo> Kamion: sure, that's probably a good plan, all the other stuff you mentioned is god
<elmo> good too
<elmo> but I definitely want a britney I can AYTY like mad close to release time
<fabbione> hey elmo
<fabbione> elmo: i am not sure you read the messages from bugzilla, but i was asking for info on the nosmp/noapci bug you filed a while ago....
<elmo> kamdion: done
<fabbione> elmo: when you have time, can you kindly check it again?
<elmo> fabbione: yes, sorry, I keep forgetting that.  to reproduce, I really need to do it on one of the machines with less than ideal remote management capabilites.  I'll do it next time in London (which'll be this week)
<Kamion> elmo: ta
<fabbione> elmo: i know.. that's why i didn't rush.. i just noticed your comments on the fact that it happened at the DC and that you lost the message in bugzilla noise... hence the local ping ;)
<fabbione> elmo: just let me know when you are there, so we can take a look at it together
<elmo> fabbione: k, cool
* mjg59 gets flamed by Eugenia on Osnews
<Burgundavia> mjg59, is that news?
<Treenaks> mjg59: \o/
<Burgundavia> mjg59, what about this time?
<elmo> ogra: err..
<ogra> elmo, ?
<elmo> ogra: it's not in dep-wait, it's in P-a-s
<ogra> P-a-s ?
<elmo> Packages-arch-specific
<mjg59> Laptop support
<ogra> whoops..
<elmo> ogra: is it urgent?  if not, could you mail lamont?  he can deal with it
<ogra> elmo, i'll do, its not urgent...
<infinity> elmo : Does Ubuntu sync Debian's P-a-s?
<elmo> infinity: yes
<elmo> fairly manually, but yes
<infinity> Ahh, and oh.
<elmo> Debian's p-a-s has some trigger happy committers, so I like to eyeball the diff before applying them
<seb128> elmo: hey. Did you read my sync request or should I repeat now? :)
<elmo> seb128: I think I did them all
<seb128> cool, thanks
<seb128> atk1.0 from exp too
<Riddell> elmo: would you be able to set up a subversion archive on novo for kubuntu?
<seb128> "breezy upload"? what kind of change is that?
<elmo> Riddell: yeah, if you want?
<Riddell> elmo: yes please
<Riddell> seb128: an upload to breezy, what else would you like it to say?
<seb128> is that any change, or you just reupload the same version from anywhere else ? :)
<Riddell> no changes
<Kamion> elmo: hmm, still didn't work
<Kamion> elmo: please insert 'mkdir ${a}' at line 79 of britney
<fabbione> where is doko?????
<Kamion> elmo: er actually mkdir -p ${a}, I guess
<elmo> Kamion: done
<elmo> and rerun, looks happier
<Kamion> elmo: you will need that to be mkdir -p or it'll fail on the next run
<Kamion> (since the script is set -e and mkdir exits on already-exists)
<Kamion> s/exits/errors/
<elmo> details
<elmo> (fixed)
<Kamion> mirrored
<fabbione> elmo: can you bless 2.6.12 please?
<Kamion> yep, looks good now, thanks
<Kamion> http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html <- get fixing people
<fabbione> Kamion: neat.. can you get sparc there too?
<Kamion> mdz would not like that
<Kamion> that'll go in the universe-only run, I imagine
<Kamion> or the main+universe run, whatever
<fabbione> uh? i am not sure i understand... i am not asking for universe :)
<fabbione> Kamion: but ok.. i trust your judgement :)
<fabbione> or create a separate page for the unofficial arches?
<fabbione> Binaries from ndiswrapper 1.1-4 cannot be installed:
<fabbione> this will disappear with the new kernel
* TheMuso can't see a problem with rhythmbox of the same version mentioned on the page.
<TheMuso> Installs and removes fine here.
<Kamion> fabbione: mdz explicitly asked me not to include ia64
<Kamion> fabbione: I imagine sparc is in precisely the same boat
<fabbione> Kamion: i understand.. can we get a similar report for unofficial arches?
<Kamion> fabbione: yes, I will (eventually) do a britney run over main+universe for all architectures
<Kamion> as I said above
<fabbione> Kamion: i would really like to see only main as a start
<fabbione> otherwise it gets confusing
<fabbione> specially because i don't have all of universe builded
<Kamion> maybe I'll do multiple runs then; whatever
<Kamion> the details aren't important to me
<fabbione> Kamion: sure.. i don't need the same frequencies as the main arches
<fabbione> if the load can be an issue, just make it once every N runs for the main arches...
<fabbione> i really don't mind
<Kamion> it's on my to-do list
<fabbione> even if it would have shown some interesting things...
<fabbione> Kamion: thanks :)
<fabbione> like perl did build on sparc (killing the buildd) but didn't on all the other arches ;)
<svenl> mmm, is growisofs supposed to be working out of the box on DVD-R and powerbooks ? 
<svenl> sven@tael:~/archive$ growisofs -Z /dev/hdc=archive.iso
<svenl> Executing 'builtin_dd if=archive.iso of=/dev/hdc obs=32k seek=0'
<svenl> :-[ PERFORM OPC failed with SK=3h/ASC=73h/ACQ=03h] : Input/output error
<svenl> This sounds like the infamous DVD burning bug which has plagued us since 2.6.8 :/
<fabbione> Kamion: do you have d-i upload in the queue for today?
<Kamion> fabbione: not at the moment
<elmo> fabbione: what's with the -1.1 version?
<fabbione> elmo: eh... 
<Kamion> elmo: actually, speaking of, the first d-i byhand for breezy would be good to have
<fabbione>   * IMPORTANT! Debian version change meaning to:
<fabbione>     <upstream-version>-<abinumber>.<debversion> so that this release will look
<fabbione>     like: 2.6.11.91-1.1.
<fabbione> elmo: that's an outcome of specs
<elmo> eww
<elmo> it looks like an NMU
<Kamion> oh, you're going to want me to switch the installer to 2.6.11 ...
<fabbione> but it's not...
<fabbione> Kamion: no!
<fabbione> not yet
<Kamion> ok
<fabbione> i was going to ask if you could remove the need of usb-modules for sparc, but since 2.6.12 is doomed on sparc anyway, there is no point in spending time on d-i
<fabbione> i will rather prefer to create the appropriate udeb
<fabbione> Kamion: we will switch d-i to use 2.6.12 in the short future.. i have 2.6.12rc4 to get out first
<fabbione> that is also supposed to fix all the ppc sleep/wakeup problems
<seb128> elmo: evince doesn't build due to djvulibre/universe, that's going to be autofixed ?
<doko> good morning all
<dholbach> hey doko
<fabbione> doko: hey dude
<fabbione> doko: perl 5.8.6-6 :)
<ogra> hey doko 
<doko> fabbione: we do have 5.8.6?
<fabbione> doko: the last upload you did...
<fabbione> it is FTBFS on all arches != sparc
<fabbione> and without _all.deb (from i386) you just killed the sparc buildd in its daily dist-upgrade :)
<doko> 5.8.4-8, what did you drink last night?
<fabbione> yeah 5.8.4
<fabbione> that one
<doko> ok, I'll look.
<fabbione> thanks
<fabbione> it fails on a test..
<doko> dholbach: what's that about OOo and python?
<doko> chmj: pong
<elmo> seb128: hum.
<seb128> what?
<elmo> tseng: ?
* fabbione -> food
<dholbach> doko: dennis__ wanted to add some OO.o-python-plugin-crack and i sent him to you and haggai
<pitti> elmo: gimp-print sync, please
<elmo> pitti: can you once over dvjulibre for promotion to main?
* pitti 's tongue breaks while trying to pronounce this
<pitti> elmo: sure
<seb128> pitti: djvulibre 
<elmo> tnx
<pitti> elmo: I'm not sure whether djvulibre-plugin actually works with FireFox and orig.tar.gz has debian/ files; but otherwise, security & bug history and packaging is fine for me
<elmo> pitti: thanks
<elmo> seb128: done
<seb128> elmo, pitti: thanks
<fabbione> elmo: is there any problem with katie mails? i didn't get any Accepted message for the kernel
<elmo> I haven't processed it yet
<fabbione> ah ok
<elmo> To: fabbione@ubuntu.com (Fabio M. Di Nitto)
<elmo> tho that probably broke exim
<elmo> er, postfix, whatevs
<fabbione> meh.. i didn't change anything in the way i build the source...
<elmo> May  9 10:45:48 fiordland postfix/smtp[12348] : 0DA08B6800C: to=<fabbione@fabbione.net>, orig_to=<fabbione@ubuntu.com>, relay=smtp.fabbione.net[212.242.141.114] ,
<elmo>  delay=0, status=sent (250 Ok: queued as 64AC043A3)
<fabbione> danke
<elmo> never mind, that doesn't break it.. AFAICS, the NEW message got sent fine
<fabbione> yes.. i got the NEW
<dholbach> bbl
<fabbione> elmo: once you are it... you can kill linux-source-2.6.11
<Amaranth> Who is Johan Svedberg?
<Lathiat> your worst nightmare
<Lathiat> (read: i have no idea and am being a useless git)
<tseng> elmo: hm i think i said beagle was good to clear new now, we held it back for hoary
<elmo> tseng: can you fix the copyright file, pls?
<tseng> sure.
<elmo> if it's not a license in base-files, it needs to be included in full in the copyright file
<tseng> alright.
<Amaranth> Well, whoever it is they're awesome
<Amaranth> blam! 1.8.0 just got released today and it's already in universe
<tseng> that was me.
<Amaranth> oh, that's the debian maintainer?
<tseng> yes
* Amaranth hugs tseng 
<Amaranth> btw, did you figure out the tomboy icon stuff?
<tseng> no I went on to other things
<Amaranth> ah
<Amaranth> if i knew more about packaging and C# i'd work on a patch
<tseng> ill get back to it at some point
<tseng> i wish upstream would loose the lame tintin icon
<zul> you dont like tintin?!?
<tseng> *hate* tintin
<zul> omfg
<tseng> besides being undistributable
<zul> i love tintin
<HrdwrBoB> haha tintin
<zul> first comic book i had
<tseng> elmo: done.
<zul> well maybe second...asterix is the first ones
<fabbione> elmo: can you please make a breezy chroot on halley and make breezy the default chroot on davis?
<seb128> daniels: new dbus for soon?
<daniels> seb128: in the morning, need to go to bed now for breezy kickoff meeting
<seb128> k
<seb128> just trying to plan for gnome-vfs
<daniels> indeed, will do that now.  night all.
<daniels> sure :)
<seb128> 'night daniels 
<jdub> morning
<ogra> hey jdub
<seb128> jdub: you have a broken timezone again :)
<jdub> i always say good morning ;)
<seb128> oh, k
<seb128> morning so :)
<marty> someone in #ubuntu has a broken sound card detection on LiveCD - this locks up gnome when it loads - how do you prevent gnome from requireing esound when it loads
<ogra> jdub, boring sunday afternoon packaging: http://www.grawert.net/divifund_0.62-0ubuntu1_all.deb
<seb128> what's this ?
<ogra> http://www.divifund.com/http://www.divifund.com/
<ogra> oops
<ogra> http://www.divifund.com/
<jdub> ogra: oh dude, great stuff! :)
<ogra> :)
<jdub> universe, universe! :)
<ogra> yeah
<seb128> have you tried grisbi ? :)
<jdub> seb128: it has more bugs than paris! ;)
* jdub admits, he has not tried it ;)
<seb128> roh 
* seb128 slaps jdub :p
<ogra> heh
<jdub> ah, it was great to see you all again
<jdub> all in my own city :-)
<ogra> yeah, it was totally great :)
<jdub> let's do it again next week!
<ogra> yeah, but lets extend the weekends by two days then... for the traveling
<jdub> thom: how's networkmanager doing atm?
<jdub> (upstream that is, not necessarily in ubuntu)
<jdub> oh hey
<jdub> a dbus daemon that controls dhclient instead of internalised crack
<jdub> excellent
<Nafallo> hehe, my gf and I look at pictures from Mataro.
<ogra> oh, seb128 did you see, serpentine has a new releas, so its not dead :)
<Amaranth> jdub: what's that?
<Nafallo> she sees mako and says: Oh! So tasty.
<Nafallo> :-)
<ogra> heh
<ogra> dont let her hold his passport ;)
<thom> yeah, i need to package dhcpdbd
<Nafallo> ogra: lol
<jdub> Amaranth: a change in the NM infrastructure
<seb128> ogra: I've uploaded it to universe
<seb128> ogra: but it doesn't work for me
<ogra> oh ?
<jdub> thom: hrm, discussion about bluetooth support in NM too
<thom> yes, not much of a discussion, it ended up "screw you hippies i'm doing my own thing"
<jdub> ah, vpn support too
* ogra whispers pppoe
<thom> vpn support is old news
<jdub> geez the 'hatters are smoking the dbus crack *hard*
<thom> ogra: not in NM; it's totally out of scope
<jdub> thom: reading the list in reverse for the first time in ages :)
<ogra> thom, i know....
<ogra> thom, thats why i was mumbling silently in my nonexistent beard ;
<thom> ogra: *g*
<thom> i really need to do something sensible with doc-base
<ogra> seb128, i think you missed my question yesterday, i'm switching evonotify to dbus and python, do you know of a list of evo dbus messages anywhere ?
<lamont> ogra: what all mono packages should have amd64 added to them?  There are several
<seb128> ogra: no idea
<ogra> lamont, yep, snice 1.1.6 we have full mono love on amd64 :)
<lamont> gtk-sharp lasso mcs mod-mono mono blam f-spot libgdiplus monodevelop muine prj2make-sharp
<lamont> ogra: sorry, s/what all/which/
<seb128> ogra: maybe you can look on http://people.ubuntu.com/~seb128/em-panel-applet_0.2.orig.tar.gz, that's the stuff sent on the upstream mailing list to display a notify icon when they get a dbus message
<ogra> i think f-spot and monodevelop have to wait, but the rest runs fine here (with locally compiled deps)
<ogra> seb128, thanks, looking at it
<seb128> np
<Amaranth> Don't you need monodevelop 0.7 if you want to run it on the 1.1.x versions?
* ogra really wants a sane mail notification in breezy
<zul> heh...not going to happen :)
<seb128> ?
<seb128> why?
<ogra> Amaranth, might be.. i just tried to testcompile everything mono related on amd64 this weekend... these two failed
<seb128> why not uploading for non amd64? :)
<lamont> ogra: done
<ogra> yay
<lamont> elmo: feel free to move to 1.564
<elmo> tseng: don't you need to update the build-depends to include amd64?
* ogra grr's at network manager
<jdub> fabbione: rock!
<ogra> BEAGLE !!
<thom> ogra: which one are you trying?
<ogra> thom, from p.u.c
<thom> don't
<thom> i should delete those packages for the time being
<ogra> thom, it doesnt like that my pcmcia card neither provides vendor_id nor product_id
<ogra> thom, are there others already ?
<mjg59> ogra: Uh. How does your card not produce those?
<mjg59> ogra: Without them, the pcmcia system can't bind a driver to it
<ogra> mjg59, dunno... i geuu its my cipset...
<ogra> guess even
<mjg59> No...
<mjg59> Is this PCMCIA or Cardbus?
<thom> ogra: not yet, no
<ogra> mjg59, HAL says cardbus
<mjg59> ogra: And lspci doesn't give it product or vendor ids?
<ogra> mjg59, 2.6.12 is the first kernel that even shows them in HAL ..... with hoary i only have the cardbus but not the cards
* mjg59 blames hal
<mjg59> cardbus devices just appear as PCI
<ogra> yep, i see the controller
<mjg59> hotplug couldn't have loaded a driver without there device/vendor ids
<ogra> but not the two cards in there 
<mjg59> Then they're not cardbus
<mjg59> (It's still hal's fault)
<ogra> one is a ide controller (cardreader) it automounts just fine...
<mjg59> Does the card have a lumpy gold ridge at the top of the connector?
<ogra> but doesnt show up anywhere :)
<mjg59> Or is it flat and silver?
<ogra> flat and silver i think
<mjg59> That's PCMCIA, not Cardbus
<ogra> (cant look at the connector without unplugging my net)
<mjg59> You've got a cardbus bridge with PCMCIA cards in (which is perfectly normal)
<ogra> ok
<mjg59> HAL's probably just being inadequate
<ogra> lets see what 0.5.1 will say...
<ogra> (i think its ready before wednesday)
<jdub> fabbione: oh dude, so much goodness in this changelog
<jdub> fabbione: inotify still off by default?
<jdub> *so* *much* *goodness*
<zul> jdub: nope
* ogra yays for JaneW joining the kernel team
<jdub> oh, hey zul 
<jdub> zul: rocking!
<zul> yep...havent had any problems with inotify...yet :)
<elmo> ogra: pardon?
<ogra> elmo, nearly :) * Welcome to JaneW as our new name release manager that kindly offered
<ogra>    volunteer to find nuts names for our kernel.
<ogra> fabbione, is ndiswrapper compiled with amd64 support this time ?
<jdub> subversion depends on libruby...
<jdub> via libswig
<elmo> jdub: we lost the fight against ruby a while ago
<elmo> s/while/long while/
* jdub removes svn ;-)
* ogra downloads the new beagle source to play with on amd64
<JaneW> did someone call me?
<jdub> JaneW: your ears are burning? :)
<JaneW> yes
* JaneW sees reference
<JaneW> yes
* JaneW is good at locating nuts
<jdub> you found us :-)
<chmj> O.O
<ogra> yeah
<ogra> meh, beagle doesnt compile....
<ogra> tseng, is the mono-mint dependency still needed anywhere ?
<Amaranth> I wonder if that manno.name repo has source
<jdub> http://lists.ubuntu.com/archives/breezy-changes/2005-May/004333.html
<jdub> ^ rapture
<tritium> good morning!
<Amaranth> jdub: yay!
<Amaranth> jdub: so we'll get getting 2.6.12 kernels in breezy soon?
<jdub> as soon as they build
<Amaranth> yay!
<Amaranth> do they have inotify? :)
<pitti> yes
<seb128> does that crash when gamin starts ? :p
<jdub> read through the whole changelog dude
<jdub> so much love
<jdub> seb128: no ;-)
<seb128> nice :)
<Amaranth> oh, there's a changelog
<elmo> seb128: have you decided what to do about gtk2-engines-industrial?
* jdub is waiting for evince to build
<elmo> I'm reluctant to remove the old binary
<seb128> jdub: pool/main/e/evince/evince_0.3.0-2_i386.deb
<seb128> jdub: you don't use i386 ?
* jdub rides apt-get update harder
<seb128> elmo: not yet, I think I'll make gtk-engines2 build it again
<elmo> ok
<jdub> libdjvulibre1 <- wtf?
<seb128> jdub: evince has "djvu" support now
* jdub has no idea what that is :)
* seb128 neither
<jdub> heh
<chmj> heh 
<elmo> it's some funky image format
<seb128> just read the discription for libdjvulibre1
<jdub> seb128: yeah, highly enlightening (not!)
<ogra> hmmm, beagled didnt crash yet....
<Treenaks> ogra: wow
<ogra> Treenaks, its strange, i'm not used to that :)
<seb128> jdub: oh, the lib description is bong
* ogra watches the indexing...
<seb128> jdub: read for libdjvulibre-dev
<elmo> haha
<elmo> there's something very wrong about seb128 using jdub-isms
<ogra> heh
<seb128> elmo: jdub-isms is like mao, you have to guess how it works :)
<jdub> seb128: aha!
<jdub> seb128: hahahaha
<jdub> oh man
<jdub> dude
<jdub> wow
<seb128> ;)
<jdub> new evince is *very* impressive
<seb128> right
<seb128> the continuous mode rocks
<jdub> and it's fast again
<elmo> does evince do everything xpdf does now?
<seb128> elmo: yep
<elmo> I notice xpdf is scheduled for demotion to universe
<jdub> whoa
<seb128> evince is impressive
<jdub> needs some scaled scrollbar loving though for long documents
<Treenaks> seb128: yeah, it's amazingly fast
* ogra beagles wildly....
<jdub> elmo: xpdf will be DEAD AS A DOORNAIL
<seb128> hehe
<ogra> jdub, but, but... the beautiful interface.... i could theme it with a xft hack :)
* pitti does echo "alias xpdf=evince" >> .bashrc
<seb128> pitti: works fine for you too now ? :)
* jdub spanks ogra very hard!
<ogra> heh
<pitti> seb128: no idea, didn't try it ye
<pitti> tr
<jdub> seb128: we should change the seeds now
<seb128> jdub: that's already changed for weeks
<Amaranth> DjVu looks cool
<elmo> jdub: dude, don't make me bring out the esound kitten compactor quote
<seb128> rofl
<Amaranth> haha, evince credits are messed up
<Amaranth> written by many, documented by no so many
<Amaranth> err, not
<jdub> elmo: that was very sad :|
<jdub> elmo: but polypaudio has a new maintainer
<pitti> seb128: hmm, can we automatically teach ffox to use evince instead of xpdf when you click on a PDF?
<jdub> who has fixed scadloads of the really bad bugs
<jdub> and lives fairly nearby, so i can hassle him very easily :)
<seb128> pitti: that's a question for thom, I don't touch to firefox :)
<pitti> oh, right
<Lathiat> jdub: who?
<jdub> pitti: we need firefox/gnome-vfs mime integration patches, or we need to do some mailcap/gnome-vfs mime synchronisation (which we should do anyway)
<jdub> Lathiat: erik
<pitti> seb128: it still takes minutes to compute previews, but at least now evince remains responsive
<seb128> cool
<pitti> seb128: I greatly miss the space key, there is no way to scroll through the whole document page-wise
<pitti> seb128: otherwise it looks fine
<seb128> page down
<seb128> does that, no ?
<pitti> no
<pitti> seb128: page down displays the next page, not the next unseen part of the current page
<seb128> it does here, or I don't understand what you try to do
<seb128> oh, right
<pitti> seb128: at full zoom I can only see the upper half of a page
<pitti> seb128: pretty much all unix programs support the space key which shows the next unseen screenful
<seb128> probably easy to fix, no doubt that will be fixed
<pitti> seb128: but that shouldn't be too hard to add
<seb128> I'll take care of getting that done :)
<pitti> exactly :-)
<pitti> you rock
<seb128> thanks ;)
<pitti> seb128: btw, "pmount /dev/sda2" works now
<pitti> seb128: the exciting part: this partition is encrypted :-)
<seb128> oh cool
* seb128 wants the new utopia crack
<fabbione> ogra: no ndis for amd64 yet
<jdub> mmm, new utopia crack
<ogra> fabbione, why ? 
<jdub> pitti: migrated to latest dbus api?
<fabbione> ogra: source problems...
<pitti> jdub: for pmount-hal, yes
<ogra> ah, ok
<pitti> jdub: also for g-v-m 
<fabbione> ogra: hadn't the time to figure out the best way to handle it yet.
<jdub> noice
<pitti> jdub: but not yet for gnome-vfs
<ogra> fabbione, ok..
<fabbione> ogra: unfortunatly ndis creates files at build time
<fabbione> ogra: that the kernel make system can't do yet
<fabbione> so i need to pre-generate them
<fabbione> and either i generate amd64 or i386
<ogra> fabbione, i think its only for broadcom so far.... so its not really urgent....
<fabbione> humpf.. only 18K of changelog?
<fabbione> next time i have to be more anal
<zul> nooooooo..
<ogra> the new blam crashes on amd64 ... :(
<Amaranth> ogra: tell tseng 
<elmo> anyone here care about cyrus-sasl or linc?
<Kamion> elmo: thanks for the byhands
<elmo> Kamion: np, sorry it took so long
* ogra wonders what happened to libvte-common
<Kamion> no worries
<ogra> seb128, ?? ^^^
<chmj> jdub, ping 
<seb128> ogra: context?
* ogra wonders what happened to libvte-common
<seb128> ogra: contaxt?
<seb128> context even
<seb128> ie: arch? what's wrong with it?
<ogra> seb128, http://archive.ubuntu.com/ubuntu/pool/main/v/vte/
<ogra> seb128, its missing
<seb128> it's not
<ogra> but libvte4 and libvte-dev built fine
<ogra> seb128, there is no  libvte-common_0.11.13-2ubuntu1
<seb128> that's a question for elmo or lamont 
<seb128> yeah, but on i386 that's fine :p
<ogra> amd64 needs it for gtt-sharp it seems
<ogra> gtk-sharp even
<seb128> elmo, lamont: the arch: all packages come from the first arch to build ?
<seb128> or from i3
<seb128> i386 even
<Kamion> i386
<seb128> k, so that's it
<seb128> thanks Kamion 
<elmo> seb128: from i386
<seb128> just wait on a i386 build :)
<elmo> (iz in queue/accepted)
<seb128> hum
<seb128> vte i386 is built since this morning
<seb128> cool, thanks elmo 
<elmo> oh, meh, cron.daily broke
<fabbione> elmo: amen!
<tritium> jdub, can I bug you for that url to the financial software you gave yesterday when gnucash was mentioned?
<tseng|work> divifund
<tseng|work> ogra has debs
<tritium> tseng|work, ah, thanks
<tseng|work> you can be his first tester
<ogra> tritium, www.grawert.net/divifund_0.62-0ubuntu1_all.deb
<tritium> ogra, thanks, I'll check it out
<abelli> fabbione: ce sei?
<abelli> hello everybody
<fabbione> no
<fabbione> i am heading off for a little while
<fabbione> i will be around this evening
<abelli> fabbione: ah ok, have a good afternoon then ..
<abelli> that sparc is 32 bit ..grrr.
<elmo> cron.daily should unblock now, with any luck
<JaneW> bye all, see you at the Breezy meeting later
<ogra> bye JaneW 
<Amaranth> that's 5 1/2 hours from now, right?
<Lathiat> yeah
<tseng|work> seb128: just fyi im working on a gst-plugins-multiverse0.8 package with faac, faad and lame. ill give you a chance to look at it before uploading
<seb128> tseng|work: rock ;)
<Lathiat> i spy with my little eye
<Lathiat> beagle and new kernel uploads
<tseng|work> beagle is ftbfs until i get home
<tseng|work> im a tool.
<Lathiat> well
<Lathiat> getting there
<Lathiat> thats what counts. :)
<Lathiat> is there a mailing list that can tell me when packages build and get accepted into the archives?
<tseng|work> mm kernel has new ipw2200 drivers
<Lathiat> woo
<Lathiat> mine keep crashing
<tseng|work> nope just breezy-changes
<Lathiat> when i shut my lid
<tseng|work> and ~/lamont
<Lathiat> i.e. interrupt issues with xset dpms force off
<tseng|work> BUT
<Lathiat> and its annoying
<tseng|work> we got packages.ubuntu.com to link to the buildLogs
<tseng|work> you can go that way
<Lathiat> cool thanks
<tseng|work> once its built it should be in archive w/i 30 minutes or so
<seb128> or apt-get update && apt-get dist-upgrade
<seb128> so you see what arrives for your box :)
<Lathiat> seb128: but that wouldnt pick up say the kernel upgrade going in
<Lathiat> seb128: and i do that like.. far too often. :>
<Lathiat> i feel like im addicted to updates or something. :>
<seb128> perhaps you should find some stuff to do out of polling for upgrades ? :p
<seb128> what about some bug triage .. :)
<ogra>  yeah
<Lathiat> bleh
<Lathiat> i have a hard enough time getting myself to hack on things i hacking on. :P)
<tseng|work> ah so we have inotify .23 in breezy
<tseng|work> I can test gamin tonight too.
* ogra cries ... beagled crashed...
<tseng|work> there are logs in ~/.beagle btw
<tseng|work> #dashboard/gimpnet is pretty helpful
<tseng|work> trow, joe, or dsd
<ogra> hmm, i guess its a dbus thing.... 05-05-09 16.50.02.18 12759 IndexH DEBUG: Couldn't acquire d-bus service 'com.novell.BeagleIndexHelper'
<tseng|work> oh, yes
<tseng|work> thats a regular problem, d-bus cant handle the sheer load of beagle
<ogra> we are still running the hoary version... lets wait until daniels ships the new one
<tseng|work> they are moving to serialized xml over a socket instead
<tseng|work> in the next release
<ogra> sounds cool
<Lathiat> i guess d-bus needs some work
<tseng|work> well, beagled is like a d-bus stress test
<ogra> yep
<Lathiat> and someone was talking about a d-bus filesystem. :)
<tseng|work> hah!
<tseng|work> thats crack.
<Lathiat> it solved the problem they were trying to solve
<Lathiat> sortof.. :)
<Amaranth> I was about to say that's a solution in search of a problem.
<Lathiat> basically threading was an issue
<Lathiat> so talking to a daemon with d-bus
<Lathiat> win
<Lathiat> heh
<tseng|work> d-bus is good for small unimportant stuff like evolution new mail notification, or muine now playing info
<Lathiat> desktop notifications
<Lathiat> i think is suitable
<tseng|work> yes.
<Lathiat> and im using it for avai
<Lathiat> avahi
<tseng|work> thats what its meant for anyway, low bandwidth event  notification
<Lathiat> yarr
<Lathiat> not 30M/s file transfers :)
<tseng|work> not being a huge bus for beagle to send all its stuff over
<tseng|work> yeah
<ogra> uuuhh
<ogra> why does seahorse depend on gedit
<tseng|work> it has a plugin
<tseng|work> for editing gpg files or somesuch
<ogra> ah...
<tseng|work> hey i get a crasher on blam now same place as you
<tseng|work> something about gdk-x11
<ogra> yep
<Lathiat> amd64?
<ogra> yep
<ogra> (here at least)
<tseng|work> x86
<tseng|work> its a missing dep
<tseng|work> gdk-x11-2.0 i dont know wtf package its in
<ogra> apt-file search gdk-x11-2.0 ;)
<seb128> libgtk2.0-0 has gdk too
<ogra> and ia32-libs-gtk on amd64
<tseng|work> ok
<tseng|work> it might be an issue of missing symlink
<ogra> which version does it look for ? 
<tseng|work> its not versioned there
<tseng|work> and there is no .config
<tseng|work> so we'll see if this fixes it
<tseng|work> yes
<tseng|work> ogra: try installing libgtk2.0-dev
<ogra> its already here...
<tseng|work> something in the build-dep is providing a symlink to what it wants, we just need to redirect it
* tseng|work adds to list
<tseng|work> pitti: sorry i havent gotten to any of the security stuff yet.
<pitti> tseng|work: no worries; however, would you prefer any other method of sending those mails? are you sub'ed to full-disclosure and/or bugtraq?
<ogra> smurfix !
<tseng|work> pitti: nope, but I could be
<tseng|work> pitti: if they all say [security]  and are from you.. i can just use procmail
* smurfix waves in the general direction of everybody else
* pitti waves back to smurfix
<tseng|work> its useful for me to get the digest stuff if you are already doing it anyway
<smurfix> back from Sydney this morning *yawn*
<tseng|work> if not, i can join the lists
<pitti> tseng|work: okay, then I will configure a mutt macro "send this mail as [security]  to tseng" :-)
<tseng|work> sweet, thanks :D
<pitti> tseng|work: or a special email address? would be easier...
<tseng|work> hm I could set one up
<tseng|work> ill mail you with it tonight
<pitti> thanks
<pitti> tseng|work: probably a mailing list would be better anyway, so astharot and Nafallo could subscribe, too
<pitti> jdub: still here?
<Nafallo> pitti: security-review-announcement? ;-)
<tseng|work> hm that would work nicely for me
<tseng|work> security-digest
<Nafallo> tseng|work: I vote for your suggestion ;-)
<pitti> tseng|work, Nafallo: for my sake we could just abuse security-review, but that might piss of the other subscribers and is against this list's intention
<pitti> Nafallo, tseng|work: ubuntu-universe-security@lists....
<tseng|work> actually i put it in the same folder right now anyway
<tseng|work> heh.
<tseng|work> any list is fine with me
<tseng|work> just tell me where to sign :)
<pitti> okay, I mail you guys
<Nafallo> same here, any list :-). I just use procmail to put it where I want it :-)
<Nafallo> pitti: kewl :-).
<Nafallo> *sigh*
<Nafallo> why does it have to start raining when I have to go out?
<Nafallo> bad karma?
<thom> water is good for you
<Nafallo> thom: but I'm already grown to the size I want? :-P
<Nafallo> well, I'm out...
* Kamion ponders switching d-i to initramfs and seeing what breaks
<thom> elmo: please sync mozilla-locale-ptbr
<elmo> thodone
<thom> thanks
<elmo> thom: done.  even
<littlepaul> hi mako jdub 
<elmo> Kamion: ?
<Kamion> elmo: ?
<elmo> mind if I upgrade little to hoary?
<Kamion> elmo: go ahead
<Kamion> let me know when you're done, I was just about to start building the first breezy CDs :)
<Kamion> (so now's as good a time as any)
<mako> littlepaul: hey
<littlepaul> may i ask u something? it concerns our german forum - it totally crashed. 
<littlepaul> we read about an offer to use webspace on ubuntuforums. Who could we contact?
<Lathiat> is the kickoff meeting in #ubuntu-meeting?
<thom> yes
<Lathiat> tx
<elmo> AIEE
<elmo> have ssh (pre-split) on hold.  upgrade to new openssh*.  remove old ssh.  wave bye bye to sshd
<elmo> [not that that's necessarily a bug, just... aiee] 
<Kamion> more liable-to-work procedure is: upgrade to new openssh*; upgrade to new ssh; remove ssh
<Kamion> does little have RM?
<Sturmkind> hello
<elmo> only the bad kind
<elmo> (i.e. IBM)
<elmo> I didn't log out thankfully, only very nearly
<Kamion> ah, ok. I was more wondering whether it was the working kind
<elmo> it works.  but it's almost less painful to drive to London
<elmo> Kamion: anyway, all done
<pitti> dilinger: here?
<pitti> anybody who knows where to get documentation for libdevmapper?
<Kamion> elmo: great, thanks
<Kamion> elmo: (kernel upgrade coming later, I imagine?)
<elmo> Kamion: yes, later this week
<dilinger> pitti: yea
<elmo> strangely enough you haven't managed to trigger the BIO leak
<dilinger> pitti: what kind of dm docs?
<dilinger> (most people don't use dm directly..)
<pitti> dilinger: I'd like to have the API documentation of libdevmapper
<dilinger> ioctl api?
<dilinger> or just the header file api?
<pitti> dilinger: actually just to see whether it is easier than parsing the output of programs
<dilinger> hm
<dilinger> i'm not aware of any docs for that
<Kamion> elmo: the what?
<pitti> dilinger: I'd like to have something like "dmsetup table"
<pitti> dilinger: okay, thanks; google doesn't find any, either
<dilinger> pitti: if there were, sources.redhat.com/dm/ would be the place to start looking
<elmo> kamion: there's a kernel level memory leak in block io code in warty's kernel
<Kamion> yum
<elmo> yeah, not so much :p
<fabbione> uh funny...
<fabbione> it's probably the bd-claim patch...
<pitti> ogra: btw, did you see the Hoary article in c't? it wasn't that bad
<ogra> oh, no
* ogra doesnt read ct
<pitti> yeah, we got a 1.5 page review :-)
<pitti> criticism: non-l18ned Kubuntu and horrible partitioning (as we already know)
<ogra> Linux-Distribution: Ubuntu 5.04 fr Menschen, S. 80 
<pitti> good: fast and slick, automagic everywhere, free
<ogra> *g*
<mvo> pitti: nice!
<ogra> sad, its not online
<astharot> ciao
<Kamion> elmo: Failed to fetch file:/srv/cdimage.no-name-yet.com/ftp/dists/breezy/Release  Unable to find expected entry  restricted/debian-installer/binary-powerpc/Packages in Meta-index file (malformed Release file?)
<Kamion> elmo: I think apt got a bit stricter - unfortunately I do need stuff from that suite
<elmo> gar
<elmo> the ziyi thing?
<Kamion> yeah
<Kamion> you could hardcode it harder :-)
<elmo> sock
<elmo> hey, ziyi isn't my fault
<Kamion> yeah, I know
<elmo> okay, I'll look at that next
<elmo> hoary upgrades were getting boring anyways
<Kamion> everybody blames me for d-i around here though ;)
<Kamion> so we can blame you for all of katie
<Kamion> thanks
<Kamion> elmo: could I also have g++, python-dev, libapt-pkg-dev temporarily on little? I need to rebuild britney against new libraries
<elmo> done
<dholbach> re
<pitti> Hey dholbach 
<eruin> http://archive.ubuntu.com/ubuntu/dists/breezy/main/binary-i386/Packages.g< <- Wrong md5sum
<Kamion> elmo: thanks, rebuilt
<trygvebw> Hi
<trygvebw> I'm in a group creating a Linux distribution based on Ubuntu, and i'm wondering if there's anything i should know about branding or anything else?
<Kamion> http://udu.wiki.ubuntu.com/BrandingForDerivatives
<mxpxpod> jbailey: ping
<Kamion> (note we haven't implemented most of that spec yet ...)
<trygvebw> ok
<trygvebw> I'll take a look at it :)
<trygvebw> So i should do what's in the "Tasks that need to be done for every derivative" section?
<Kamion> for now you'll need to do a good deal more if you want total ground-up branding
<Kamion> because we haven't done the other bits yet
<trygvebw> ah, ok :)
<trygvebw> Anything else i should know?
<aj> trygvebw: do you mean "what should i do to avoid stepping on ubuntu's toes?" or "how can i get my distro's name everywhere instead of "ubuntu"?"
<trygvebw> more: "how can i get my distro's name everywhere instead of "ubuntu"?" :)
<jbailey> mxpxpod: Here
<mxpxpod> jbailey: does hotplug take a long time to start up on your ppc machine?
<Kamion> hmm. do we care if the installer stops saying "Ubuntu 5.10 (Breezy Badger)" and starts saying just "Ubuntu 5.10"?
<trygvebw> And i'm also wondering if it's possible to remove Ubuntu-Installer from the LiveCD? We're developing our own GTK installer to be run from the LiveCD session.
<Kamion> 'cos I can't get the former out of lsb_release easily
<elmo> lsb doesn't have a 'codename' field?
<Kamion> elmo: yes, but it's set to "breezy"
<jbailey> mxpxpod: I haven't got easy access to my ppc machine right at the moment.  Takes forever on my i386 laptop, though.
<Kamion> trygvebw: the installer is used to bring up the live CD session
<mxpxpod> jbailey: strange... my brother's i386 desktop flies thru hotplug
<trygvebw> Kamion, well, i was wondering if it was possible to remove it... and replace it with something else maybe?
<aj> Kamion: you can't/don't want to add a field to Release for it?
<Kamion> trygvebw: our plans to develop a GTK installer that runs from the live CD session involve *more* integration with the normal installer, not less
<trygvebw> ah
<trygvebw> Well, does that matter for me?
<jbailey> mxpxpod: Yeah, I'm guessing there's something subtle in some configurations.  Lately i've only been powering off my laptop when the battery dies on me, so I haven't worried about it.
<Kamion> trygvebw: it seems unwise, but you can certainly try; you'll have to write your own code that brings up the live CD session
<trygvebw> Kamion, ok :) 
<jbailey> I'll probably look at it when I have time.  Since my machine used to be a sid box, I can't even promise that it's an Ubuntu bug and not something I broke on my own.
<Kamion> trygvebw: it's possible in the sense that anything's possible
<trygvebw> Is there any technical details anywhere on how it brings up the LiveCD?
<mxpxpod> jbailey: I'm thinking about re-installing ubuntu on my ppc machine to see if that makes a difference
<Kamion> aj: it's awkward to get at Release in that particular place
<Kamion> trygvebw: apt-get source casper ;-)
<trygvebw> Kamion, ok :)
<trygvebw> thanks :)
<Kamion> trygvebw: it's written as an installer component
<trygvebw> ok
<hunger> Could someone please regenerate breezy/universe/Package.gz on archive.ubuntu.com?
<Kamion> hunger: it's regenerated every half an hour ...
<hunger> It's md5 is wrong.
<Kamion> probably in the middle of mirroring
<Kamion> although that seems a long shot at :26
<hunger> Hmmm... maybe my partition is borked:-(
<Kamion> aj: dunno, I guess it might be useful there for other reasons; Long-Codename?
<fabbione> gpg: signature packet without timestamp
<fabbione> gpg: buffer shorter than subpacket
<hunger> I guess I'll have to wait for 30min.
<fabbione> does anybody remember what was the value to increase to avoid this problem?
<trygvebw> Is there anything in the wiki about Casper? Couldn't find anything.
<Kamion> trygvebw: http://www.ubuntulinux.org/wiki/LiveCDDesign has some oldish stuff
<trygvebw> ok thanks :)
<aj> Kamion: yeah, something like that. does Full-Codename sound any better? i guess Display-Codename: just sucks
<Kamion> and http://www.ubuntulinux.org/wiki/LiveCD for its goals
<trygvebw> ok :)
<Kamion> aj: mm, either seems to work. if you go too far down the display-* road you end up in i18n hell
<aj> Kamion: yeah, Long- just sounds clunky, but so do all the others
<Kamion> Decodename:
<Kamion> :-)
<trygvebw> So what *exactly* is "Casper": The system that brings up the LiveCD? What does it consist of?
<Kamion> casper is the code that mounts, prepares, and enters the live CD filesystem image
<elmo> ogra: dude
<trygvebw> ok :)
<elmo> ogra: please don't do uploads to trigger builds
<trygvebw> Is the init scripts a part of Casper?
<pitti> thom: please ping me as soon as you return
<ogra> elmo, ok... so i have to get on your nerves everytime ?
<elmo> ogra: me or lamont
<Kamion> trygvebw: no, the whole point of casper was to reduce the amount of duplication of effort between the regular system and the live CD
<ogra> ok
<Kamion> trygvebw: we just build an image out of the regular system
<Kamion> which has the init scripts and such
<trygvebw> ok :)
<trygvebw> Is hardware detection a part of Casper?
<Kamion> no, that's a part of the installer
<trygvebw> ok
<Kamion> we explicitly wanted to use the same code for both, so that the live CD was a good test of whether your hardware could handle a normal installation
<trygvebw> ok :)
<pitti> lamont: heeeeeeelp
<lamont> pitti: yes?
<seb128> Mithrandir: around?
<svenl> Kamion: to test the live CD on pegasos, i only need to generate the mkvmlinuz kernel for it, right ? Since it doesn't use yaboot later on it should work out of the box ?
<rubenv> are there any places where I could ask legal questions, i'd rather not litter the mailing lists any more, it's about the APSL2
<Kamion> svenl: yeah, I imagine so
<doko> lamont: something wrong with the buildd's? See http://people.ubuntu.com/~lamont/buildLogs/g/gcc-3.4/3.4.3ds1-13ubuntu2/gcc-3.4_3.4.3ds1-13ubuntu2_20050509-1807-amd64-failed
<lamont> doko: ignore yellow
<pitti> doko: something similar happened to the mozilla security upload - random segfaults
<lamont> pitti: but only seen on yellow...
<doko> lamont: same on powerpc
<lamont> doko: so fix it. :-)
<dholbach> elmo: do you know if herve was already added to the keyring?
* lamont ducks
<svenl> I will try then.
<svenl> Kamion: would it be ok if i repacked the livecd with a pegasos kernel included ? The same going for the normal installer CD ? 
<Kamion> I don't imagine it would break anything, although you might need to be careful about size
<svenl> Or even include the LiveCD in the new installer DVD i am preparing.
<Kamion> you could base that on the combined install/live DVD that already exists
<svenl> i have 2GB left on it.
<svenl> Oh, you have something such ? Where ? 
<svenl> i currently ship a preinstalled image.
<Kamion> http://cdimage.ubuntu.com/releases/hoary/release/ (BitTorrent only)
<elmo> dholbach: no, I'll do that in a  bit
<doko> lamont: if you get the buildds working again, please reschedule perl.
<dholbach> elmo: ok thanks
<Kamion> (I should move that to releases.ubuntu.com really)
<Amaranth> buildds don't work?
<lamont> doko: I have a theory about perl... requeued
<ogra> Amaranth, according to the buildlogs they do
<doko> lamont: me as well. what is your's?
<svenl> Kamion: are they available in ppc, or in multi-arch ? 
<lamont> Amaranth: there is _one_ buildd that is throwing random segv's, removed from the rotation until it gets a good checkup.  otherwise, life is going well.
<Kamion> svenl: all architectures
<svenl> Cool.
<Kamion> svenl: no multiple-architecture stuff yet
<Kamion> (so one for each)
<lamont> doko: that test looks like it kinda wants 'localhost' to resolve, I'm betting.
<svenl> Kamion: oh.
<svenl> Kamion: can i order those per snail mail too or something ? 
<Kamion> doing multiple-architecture images in debian-cd hurts my brain
<Kamion> svenl: I think we're doing them on a "you pay the cost of media and shipping" basis
<lamont> Kamion: the real question is whether or not all 3 architectures could co-exist on the same media
<Kamion> but I could be wrong
<lamont> medium, even
<Kamion> lamont: even if they can, I'm not convinced that it's viable to have debian-cd assemble such an image
<lamont> Kamion: but it would be _kewl_. :-)
<Kamion> it's just too far out of its design parameters
<lamont> certainly
<Kamion> I want to rewrite the thing anyway, but ;)
<lamont> *wimp*
<Kamion> (in my CFT)
<mxpxpod> lamont: I'm sure they'd all be able to fit on a dvd :)
<aj> hrm
<Kamion> mxpxpod: that's not actually clear
<lamont> mxpxpod: with the livecd bits, I don't believe so
<aj> lamont: i met someone who claims to be you, but i still don't believe it
<lamont> aj: feh
<lamont> aj: wrong personality?
<Kamion> mxpxpod: not a single-sided single-layer one anyway
<mxpxpod> Kamion: ah, ok
<jbailey> lamont: Perhaps he saw you dressed in a shirt and tie.
<aj> lamont: it's a worse brainfsck that james troup being hugged and tickled by a six year old
<lamont> Kamion: having said that, I do have a dvd image that, with a little bit of work and knowledge, can be booted live on an i386 box, and act as a netinst server for all 3 architectures....
<doko> jbailey: do you have l-k-h and/or amd64-libs-dev fix for 9211?
<jbailey> doko: Ah, hadn't gone through that stuff yet.  I though it was all sorted out last week.
<jbailey> doko: (I was not really online on the weekend at all)
<jbailey> doko: I prefer the idea of just doing another pass for i386 glibc for x86-64, though.
<doko> jabailey: yes, I noticed ...
<lamont> aj: and it was nice to meet you, too...
<aj> lamont: oh, it was definitely nice to meet you; just confusing :)
<lamont> aj: sorry for the confusion, I think
<aj> lamont: my poor preconceived notions :~(
<Amaranth> http://archive.ubuntu.com/ubuntu/dists/breezy/main/binary-i386/Packages.gz: MD5Sum mismatch <--is this a mirroring thing or a "something's broken" thing?
<thoreauputic> Amaranth: people on Hoary are seeing something similar
<thoreauputic> Amaranth: i think the repos have a bit of a problem
<Amaranth> thoreauputic: In #ubuntu I only see a GPG error, which is a mirroring thing
<thoreauputic> Amaranth: ah OK - sorry I actually made the mistake of thinking I was in #ubuntu
<elmo> hum
<aj> elmo: breezy/Release file seems not to have updated for 1h25-ish
<elmo> yeah, I'm looking
<elmo> it's almost like cron.daily's are overlapping or something, but there should be locking to prevent that
<Amaranth> now synaptic thinks everything on my system is from a local install :)
<elmo> sigh, auckland really can't keep up by itself
<Amaranth> auckland? isn't that a city?
<lamont> Amaranth: antartic species, iirc
<herve> hi
<herve> seb128, ping
<bluefoxicy> qemu 0.7 is out and I'm trying to repair my amd64 installation without booting into it.
<doko> thom: do you need/want to build mozilla and firefox on amd64? else, I'll break g++-3.4 on amd64 now ...
<seb128> herve: pong
<thom> doko: hrm? it builds with 4.0 as well, so as long as i have *a* compiler, that's fine
<dholbach> seb128: kindly upload his dia-fixes :-)
<herve> seb128, I have a fixed dia, eager to upload... until I found out it's now in main :-)
<seb128> ah ah
<seb128> url ?
<herve> http://deb.oursours.net/motu/pending/
<bluefoxicy> are the 4.0 builds using -fssa?
<herve> yes, that's quite funny when you think about it :-)
<seb128> you guys should have a motu archive :)
<bluefoxicy> I heard static single assignment WORKS in 4.0 now
<dholbach> seb128: and @ubuntu.com email adresses ;-)
<seb128> dholbach: right ;)
<herve> I would choose unlucky-motu@ubuntu.com
* dholbach comforts herve a bit
<elmo> hmm.
<elmo> Kamion: any array's (?) coming up?
* elmo eyes one of the cdimage machines greedily
<Kamion> elmo: once I can actually get CDs built, I'm hoping Colony 1 will follow soon after
<elmo> giggle, colony
<seb128> herve: around?
<herve> almost
<herve> I can hear
<herve> but on the telephone
<jammcq> anybody know if the date has been set for the next Ubuntu developer meeting?  I heard it would be a short time after the Breezy release, which I'm guessing is around Oct 6th
<trygvebw> wasn't that UDU?
<trygvebw> ahh, the next one
<jammcq> yeah
<jammcq> I was at UDU, and i'd like to be at the next one
<jammcq> but i've got someone wanting me to be somewhere Oct 24th, and i'm wondering if that will conflict
<Kamion> jammcq: hasn't been set yet
<Kamion> AFAIK
<jammcq> hmm, thanks
<seb128> herve: any way to fix your changelog to mention the bugs or the patches for the bunch of patches you list?
<elmo> BREEZY KICK OFF MEETING in 8 minutes, YOU SLACKERS.
<bluefoxicy> wt. . .
<herve> seb128, I filed the bugs afterwards
<seb128> herve: ?
<bluefoxicy> ok, who controls firefox and what do I have to do to get them to stab linspire in the face
<seb128> herve: you have written all the patches, or grabbed them from the CVS, bugzilla, dunno ?
<bluefoxicy> I just first today heard of Linspire and went to their site, because we have linspire next to Windows now at best buy
<bluefoxicy> and I already have an account, am already logged in, and am logged in under my proper e-mail address.
<herve> seb128, I just grabbed them from the cvs and made dpatch versions
<bluefoxicy> . . . why can they get this information out of my machine?
<bluefoxicy> I didn't enter anything in anywhere.
<abarbaccia> hey all - i'm wonder how I can become more involed with ubuntu and development
<dholbach> abarbaccia: hi, what would you like to do?
<abarbaccia> dholbach, depends what you need to me to do - im working on my computer engineering degree at Penn State and I can program decently - i'm a fast learner and watned to hlep with the development
<dholbach> abarbaccia: #ubuntu-motu is a good place to start but at the moment we have a meeting in #ubuntu-meeting
<Kamion> we're having a kickoff meeting for the next release cycle now in #ubuntu-meeting; if you want to lurk there, that would be a reasonable way to get up to speed with what we're in the middle of
<dholbach> abarbaccia: i really appreciate your wish to get involved, so if you drop into #ubuntu-motu or drop me a line (dh@mailempfang.de) we can discuss whatever you'd like to change :-)
<seb128> herve: the changelog is not really good, it doesn't mention the name of the patch you have used neither than the patches come from the CVS
<seb128> do you want to fix that?
<herve> seb128, wai
<herve> t
<herve> seb128, I'll fix it, I want this version rocking, I'll find a model in changes.breezy
<herve> seb128, no need to bump the revision I guess?
<seb128> no
<seb128> BTW not sure that's worth the efforts
<seb128> I mean you have probably take some time to review the patch, etc
<Kamion> I wouldn't upload a new version just to fix the changelog - do it for subsequent uploads though
<seb128> the version is not uploaded
<seb128> I'm just reviewing it :)
<Kamion> ah
<herve> seb128, the locale issue is important to me, since I lost a month trying to find why my eps files were screwed up
<herve> the other ones are the cherry on the cake, yes
<herve> er no, no the gcc 4.0 fix
<seb128> yeah, but on a devel branch I just do a CVS snapshot for my part
<seb128> much faster
<seb128> than grabber 6-7 patches
<seb128> s/grabber/grabbing/
<herve> I'm not confident enough decisions such as "forking" the debian package
<seb128> you have to search for the patch, make dpatch, document the changes, and to drop them for the next version
<herve> just providing help to the existing one
<seb128> that's not forking
<seb128> that's using a new upstream version
<seb128> you are almost doing that with all the patch
<seb128> that's just extra work over doing a CVS snapshot
<seb128> just my opinion BTW
<herve> your opinion is sure important
<herve> I learn from it
<herve> and my mistakes :()
<herve> (not intended smiley)
<seb128> that's not a mistake, doing proper package with patches is important
<seb128> especially near of a freeze or a new version
<seb128> but atm if the CVS fixes a bunch of bug, that's easier and faster to package it
<seb128> I'm going to do this for gnome-vfs rather than backporting the changes for the new dbus
<doko> lamont: please fix the amd64 buildd, this doesn't look very nice: buildd http://people.ubuntu.com/~lamont/buildLogs/g/gcc-3.4/3.4.3ds1-13ubuntu3/
<herve> I'll consider it for the next one
<lamont> doko: is it on yellow, or elsewhere?
<doko> lamont: king
<lamont> right..  amd64 buildd's all killed until the archive is fixed.
<lamont> doko: that'll fix the logfile proliferation
<cartman> W: GPG error: http://archive.ubuntu.com breezy Release: The following signatures were invalid: BADSIG 40976EAF437D05B5 Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>
<cartman> wtf?
<crimsun> archive is broken, being fixed.
<cartman> oh ok. not safe to dist-upgrade now?
<herve> seb128, the references to gnome's bugzilla are worth keeping?
<cartman> or can I ignore the warning?
<herve> you could also say hello :-)
<crimsun> cartman: not safe when you can't access 3/4 of the repo ;)
<cartman> crimsun: lol ok
<cartman> crimsun: thanks for info
<thom> fabbione: any reason why v3 process accounting isn't on in the kernel by default?
<seb128> herve: not really, mention the patch names and the fact they come from the CVS, so that's clear they are to drop for the next version
<fabbione> thom: no that i know of .. probably we just didn't enable it...
<thom> please can you? :-)
<fabbione> thom: sure..
<fabbione> do you remember the kernel option?
<thom> thanks
<thom> CONFIG_BSD_PROCESS_ACCT_V3
<lamont> doko: (it's an archive issue, not a buildd issue)
<fabbione> thom: done.. it will be in with 2.6.11.92-1.1
<thom> merci bien
<thom> (i need it for maximum chicken^Wbootchart)
<fabbione> thom: no problem
<Nafallo> zul: what's the road for rt2400 && rt2500 || rt2x00?
<zul> Nafallo: working on it
<Nafallo> zul: tell me if you need anything :-). I want to help if I can :-).
<fabbione> thom: it will take me a couple of days to get this kernel in
<fabbione> thom: ppc is a FTBFS
<zul> Nafallo: sure
<elmo> ARGH
* elmo beats bash maintainers severely
* dholbach hands elmo something heavy
<elmo> bash broke cron.daily, kthxbye
<elmo> doko: what did 'trap -' turn into in hoary bash?
<thom> fabbione: no rush
<thom> elmo: uh? ewww
<fabbione> thom: i am already test building on i386
<fabbione> <thom> fabbione: no rush
<fabbione> <fabbione> thom: i am already test building on i386
<seb128> elmo: any idea on where is pyxdg 0.10? I've uploaded it this morning and no sign from the buildd atm
<Kamion> elmo: can you just do 'trap'?
<elmo> pyxdg_0.10-0ubuntu1_source.changes
<elmo> REJECT
<elmo> Rejected: Uploads to hoary are not accepted.
<elmo> and seb128@d.o again, instead of u.c
<Kamion> or 'trap - [some list of signals] '
<seb128> elmo: arg, thanks
<Kamion> hm, no, 'trap' with no arguments definitely isn't what you want
<doko> elmo: trap '' 0
<doko> ehh, trap - ? or cd - ?
<elmo> doko: 'trap -'
<elmo> it worked with warty's bash, errors with hoary
<doko> elmo: yes, insert '' as the action argument: trap '' -
<elmo> ok
<herve> seb128, here's what it gives: http://deb.oursours.net/motu/changelog
<herve> seb128, I took the occasion to reduce the patches name
<seb128> herve: nice :)
<herve> you should have tell -:)
<elmo> -su: trap: -: invalid signal specification
<elmo> doko: ?
* Kamion thought - was an action not a condition
<seb128> herve: you have an updated package or I should use this changelog with the previous one (or you have renamed some patches?) 
<herve> seb128, I'll prepare a source-only package and upload it
<seb128> thanks
<herve> I launched a build but it's ok, I just had to test the renamed patches and it passed
<herve> seb128, you just need the diff.gz and dsc?
<seb128> correct
<herve> I signed them but what's the point :-)
<elmo> hmm, trap - 0 seems to work fine
<doko> hmm, but do you want to reset for the 0 signal?
<herve> seb128, uploaded
<seb128> k
<elmo> doko: yes, the top of the script has 'trap cleanup 0'
<elmo> so I assume 'trap -' is meant to undo that
<elmo> tho looking at 'help' for previous versions of bash that's not obvious
<thom> seb128: sabayon packages? SWEET!
<elmo> in fact, it seems to do absolutely nothing in previous versions of bash.  
<elmo> rock on.
<seb128> thom: yep, I've tackled the 2 blockers bug with upstream this afternoon
<doko> elmo: yes, then trap - 0 sounds ok
<seb128> I'll upload after meeting or tomorrow
<thom> hey sivan
<pitti> trulux: please discuss non-meeting stuff here
<pitti> trulux: in #u-m we have an agenda
<trulux> pitti: I know, just waiting until the end. I've been having some issues around and they stopped me from being able to finish the spec
<pitti> trulux: in the near future we two should sit together and update the specification
<trulux> pitti: right, I made that RFC for making u-h one which is basically a replacement of Proactive Security one
<trulux> pitti: btw, desktop integration is important, I've started a gnome applet for SELInux
<pitti> cool
<trulux> pitti: among trying to port red hat's config. tools
<trulux> just need some help, I'm not a real python hacker (yet)
<trulux> sivang: what's up?
<sivang> trulux: fine, just got back from work, exchusted trying to catch up last bits from Brezy kickoff
<trulux> sivang: haha, I'm just finishing the spec for Ubuntu Hardened
<sivang> trulux: privilges of people without a day job ;-)
<trulux> sivang: haha, no, privileges of students ;P
<trulux> tseng: http://bugs.gentoo.org/show_bug.cgi?id=92033
<trulux> tseng: ;)
<sivang> trulux: the same :-)
<trulux> sivang: yep :)
<pitti> tim1: however, gstreamer has a terrible performance
<seb128> tseng|work: sync issues with gstreamer?
<trulux> pitti: how was the thing on gcc-3.4 ssp packages?
<tseng|work> seb128: yes?
<tseng|work> timing I mean
<seb128> tseng|work: do you still have them? BBB has been doing rocking work on this upstream, and I've talked with a gstreamer guy today who has read the udu wiki, they think that gstreamer is as good as xine and better than mplayer on than plan
<pitti> trulux: later, please, after the meeting
<trukulo> pitti: do you know this ? http://bugs.gentoo.org/show_bug.cgi?id=90626
<tim1> pitti: agree, but instead of putting much work in the xine library we should just include gstreamer by default and a full xine in universe
<tseng|work> seb128: i still have mp3s that dont even play on playbin
<seb128> tseng|work: so if you have sync issues please open a bug with the format, etc
<trukulo> it's a bug on gzip, not published yet
<tseng|work> seb128: but now muine has its own gtimer code
<seb128> tseng|work: don't play != sync
<tseng|work> so I dont get them
<tseng|work> video sync is bad iirc, but i stopped using gst for video
<tseng|work> ill try and find some, sure
<trulux> pitti: OK, no probs
<seb128> tseng|work: is or was? If that's bad upstream would be happy to fix, but we need to fill bugs for that
<seb128> they are not aware of such issue
<tseng|work> I guess it was, i stopped using it
<seb128> k, if you give a try again let me/upstream know, thanks
<tseng|work> np
<tseng|work> ill check out my non-playing stuff
<seb128> BBB is working full time on gstreamer, and is happy usually to get bugs about things not working
<Amaranth> I sent BBB some m4a files that were playing too fast and not playing at all. He fixed the first issue and is looking in on the second one.
<tseng|work> cool
<Amaranth> So just send him the file that messes up.
<tseng|work> he helped me fix that last issue with playbin in hoary
<thom_> lamont: but hacks are right down your street! ;-)
<lamont> thom_: feh
<dilinger> but not up his alley?
<GheRivero> res
<seb128> herve: dia uploaded
<herve> seb128, thanks
<seb128> thank you for the package :)
* dennis__ just started a OOo Motu
<dennis__> now, do i need to do something official besides creating a wiki page?
<tseng|work> well you need to either become a MOTU
<tseng|work> or find someone to work with you
<herve> dennis__, what do you mean?
<herve> tseng, OOo is not in the universe anyway
<dholbach> an OO.o team
<dennis__> dholbach, hey what's up
<fabbione> infinity: /j #ubuntu-kernel
* dennis__ blaims dholbach for everything he might have done wrong :-P
<dholbach> dennis__: thanks for that
<dholbach> dennis__: we're in a meeting atm, but as i told you: you'll want to talk to doko and haggai for OO.o fun
<dennis__> dholbach, ok i hope i bump into them here some time, or is there a better way to contact them?
<tseng|work> ajmitch_: can you do universe security?
<tseng|work> im going to go soon
<dholbach> dennis__: IRC should be fine
<dholbach> tim1: malone :-)
<pitti> tim1: please use malone for universe bugs, and bz for main
<tim1> ok, unfortunately malone or launchpad in general is in a pretty alpha-stage right now
<tim1> e.g. when i want to comment a bug it just says: Error in input
<thom> tim1: report bugs in malone, too! ... 
<hunger> tim1: Add your grievances to the MaloneUniverseWishList page in the wiki.
<infinity> "Make it work" doesn't seem wishlist.
<dholbach> "meeting with Malone crew: 12 May 20:00 UTC" :-)
<tim1> hunger: my wishes are already in there
<thom> tim1: i just pinged one of the malone devs, not sure he's around currently though
<hunger> infinity: I just want to get him to add stuff so that I do not have to feel responsible for about 90% of the stuff on that page;-)
<lamont> doko: I think all the buildd's are back to doing what they're supposed to, instead of just complaining about things.
<tim1> i think when launchpad is stable it will really boost the productivity of the whole ubuntu project, it's (planned) features are really great
<tim1> so I'm just gonna file a bug that filing bugs doesn't work ;)
<doko> lamont: thanks
<thom> tim1:  < BjornT> thom: it's fixed, just waiting to be rolled out. next rollout is tomorrow, i think
<tim1> thom: great news, thanks
<seb128> tim1: when you get the error you can try again
<seb128> it works from this dialog
<tritium> thom, I've got an iPaq 38xx with familiar on it now.  I'd be happy to test stuff on PDASupport
<thom> ogra: what needs to happen for the gui on PMC short of "upload gnome-power"?
<thom> current cvs is pretty close to having the ui we talked about
<ogra> thom, ok
<Burgundavia> thom, I currently have  a tungsten E an extremely common recent palm model
<ogra> thom, HAL 0.5 should be available
<thom> ogra: yes, lots of stuff is waiting on new dbus/hal love
<ogra> yep...
<ogra> else i'm probably fine with the ui... 
<seb128> which is waiting on daniels for new dbus
<tim1> seb128: doesn't work for me, tried to add a comment here: https://launchpad.ubuntu.com/malone/bugs/566
<seb128> tim1: you get the error you mentionned before and it deletes the message, but from the error page you can comment
<seb128> by clicking 2 times
<dholbach> tim1: you have logged in and set a preferred mail adress?
<seb128> you just have to enter the comment again on this page
<daniels> i have an ipaq; can't remember which model off the top of my head
<kent> sorry if this is OT, but out of interest, how many people are hired to work on ubuntu? that is, how many get paid for it?
<tim1> seb128: ok you were right, thanks
<seb128> np
<Kamion> kent: I think the current Canonical distro team count is 17
<kent> Kamion, thanks.  Its a kind of dumb question realy, but its fun to know :)
* Burgundavia needs to bookmark the build logs
<Burgundavia> where are they again?
<crimsun> people.ubuntu.com/~lamont/buildLogs/
<dholbach> http://people.ubuntu.com/~lamont/buildLogs/byDate/today.html
<lamont> Burgundavia: there's even a link from ~lamont now
<Burgundavia> ah, cool
<Burgundavia> I will bookmark those now
<anto9us> Hi everyone, I'm looking into pre-installing ubuntu on machines for sale. Can someone point me in the right direction for looking into what issues, particularly legal, are involved?
<jbailey> anto9us: http://www.ubuntulinux.org/ubuntu/TrademarkPolicy/document_view is a good place to start.
<jbailey> anto9us: Aside from that, we'd love it if you pre-installed the system.  Canonical can also do escalation support arrangements, and with the breezy release it'll become much easier to do branding customisations.
<jbailey> anto9us: There are a number of OEM-style improvements going in during this release cycle.
<anto9us> jbailey: thanks :)
* daniels goes back to bed.
<anto9us> jbailey: what do you mean by branding customisations?
<seb128> daniels: you were supposed to package dbus now, weren't you? :)
* seb128 runs
<jbailey> anto9us: Ubuntu is designed to be branded with custom logos and whatnot.
<jbailey> anto9us: So you can change out the gdm login screen, default theme, background, gnome splash.
<daniels> seb128: i'm supposed to finish dealing with the new mono stuff after I wake up again :P
<jbailey> anto9us: Sort of like how IBM or whatnot might ship you a windows CD where the bootup splash screen includes both the IBM and Microsoft logo.
<seb128> daniels: start with dbus, thanks :)
<daniels> seb128: the new mono stuff ... for dbus
<daniels> bearing in mind that dbus has libdbus-cil :P
<seb128> oh, right
<anto9us> jbailey: sounds excellent :)
<seb128> yeah
<daniels> anyway, be back in a couple of hours
<seb128> 'night :)
<hunger> mkinitrd has libdevmapper hardcoded to version 1.00 :-(
<hunger> So you can no longer install kernel images in breezy (libdevmapper is version 1.01 there).
<infinity> hunger : It'll get fixed.
<hunger> infinity: The script is really ugly... close to a generated configure script;-)
<Kamion> good way to solicit help, that
<Riddell> mdz: could you look at approving knetworkconf in hoary-updates?
<haggai> dennis__: hmm I see you say OOo pyuno isn't working properly; it was working before the last package update if you set LD_LIBRARY_PATH
<haggai> dennis__: yup, it does work in hoary.  What did you test?
<dholbach> good night
#ubuntu-devel 2005-05-18
<ogra> night dholbach 
<infinity> elmo : Please sync powerpc-utils from unstable.
<infinity> elmo : I had Michael merge our changes.
<elmo> infinity: don
<elmo> e
<infinity> Danke.
<dennis__> haggai what do you mean
<dennis__> haggai which version are you testing, openoffice2 or 1? and how are you starting it
<haggai> dennis__: OOo2 - OOo1 doesn't have pyuno support
<dennis__> haggai it does since 1.1
<haggai> dennis__: it's not compatible with the python in ubuntu
<dennis__> haggai anyways i'm trying to get 2 working anyways
<haggai> dennis__: LD_LIBRARY_PATH=/usr/lib/openoffice2/program python program.py
<dennis__> SystemError: Error during bootstrapping uno (RuntimeException):pyuno: couldn't instantiate invocation service
<dennis__> that's a new error message
<dennis__> let me check on that
<haggai> dennis__: the example scripts in openoffice.org load without error
<dennis__> haggai where are they located
<haggai> dennis__: /usr/lib/openoffice2/share/Scripts/python
<dennis__> haggai, that is because the scripts don't even import uno
<haggai> dennis__: I did test it with scripts that did something; maybe something got broken in the 1.9.79 update (which I wasn't involved in)
<dennis__> hmm
<dennis__> do you know what python version it's compiled against?
<haggai> system python
<haggai> so 2.4
<dennis__> could it be that you did it while we were still using 2.3?
<haggai> no
<haggai> but OOo2 was a fast moving target with packaging changing every milestone; it woudn't surprise me if something broke
<haggai> I was having to change all sorts in the packaging when I was tracking milestones
<dennis__> yea it's still very new
<dennis__> let me just purge everything and then see if that does it
<haggai> dennis__: hmm it is definately broken
<haggai> dennis__: the test script I used to test at the time (which did import uno) doesn't work any more
<haggai> oh, python-uno isn't installed
<dennis__> ;-)
* haggai apt-gets
<haggai> SystemError: Error during bootstrapping uno (RuntimeException):pyuno: couldn't instantiate invocation service
<dennis__> ok
<haggai> now I have the same as you
<dennis__> so it's not just me
<haggai> no, seems to have broken
<dennis__> i think it's a matter of compiling libuno against python
<dennis__> but i don't know how to do that
<haggai> you mean libpyuno?
<haggai> I did already do all that and the fact the package exists should mean it is still happening
<haggai> my guess is that something changed in the implementation that needs a different file layout or pyunorc
<haggai> it's a little odd that pyunorc only has the 2 lines in it
<haggai> do you have a stock 1.9.79 install anywhere?
<dennis__> nope 
<haggai> when I did the original packaging that pyuno had several other lines in it
<dennis__> i'm still waiting for my install to finish
<dennis__> so i can see 
<haggai> I have a .78 - I'll try copying the lines from there
<dennis__> the [bootstrap]  line is missing
<dennis__> that might be why it doesn't bootstrap
<haggai> no
<haggai> aah
<haggai> but if you add all the extras it works
<haggai> [Bootstrap] 
<haggai> PYUNO_SHARED_PACKAGES=${$ORIGIN/bootstraprc:BaseInstallation}/share/uno_packages/cache
<dennis__> all what extras?
<haggai> PYUNO_USER_PACKAGES=${$ORIGIN/bootstraprc:UserInstallation}/user/uno_packages/cache
<haggai> UNO_TYPES=$ORIGIN/types.rdb ?$PYUNO_SHARED_PACKAGES/types.rdb ?$PYUNO_USER_PACKAGES/types.rdb
<haggai> UNO_SERVICES=?$PYUNO_USER_PACKAGES/services.rdb ?$PYUNO_SHARED_PACKAGES/services.rdb $ORIGIN/services.rdb
<haggai> the packaging scripts just add the PYTHONHOME/PATH to the bottom of the script created by the upstream install so I guess something went wrong or was changed during the upstream build
<dennis__> yea
<dennis__> so what shall we do, bug report?
<haggai> yes, to make sure it doesn't get forgotten
<haggai> we could hack the packaging script to add the missing lines as a workaround for now
<haggai> but really it needs investigating what changed/broke upstream
<dennis__> yea
<dennis__> what's ubuntus bug page?
<zul> bugzilla.ubuntulinux.org
<dennis__> i'm pretty new to this
<dennis__> should i leave the priority at normal or should i say it's a blocker?
<mdz> Riddell: can you send me a debdiff?
<haggai> well I suppose it's a blocker for python-uno
<haggai> um, that would be major severity I think
* lamont hugs the kubuntu guys
<lamont> although... there are some confused kubuntu users out there...
* lamont just clarified the ubuntu/kubuntu relationship for the IT guy at the kids school...
<dennis__> https://bugzilla.ubuntu.com/show_bug.cgi?id=10569
<lamont> "I don't think kubuntu will be around much longer now that ubuntu has KDE in main."
<lamont> well, _I_ thought it was funny, anyway.
<elmo> *choke*
<lamont> (the kids school was going to be using SUSE or some such, is now running kubuntu)
<lamont> elmo: I think it's an issue of messages, or some such.
<doko> elmo, lamont: would it be possible to stop uploads to breezy for 2 or 3 days, besides those done for the CXX ABI transition?
<elmo> doko: why do you need that?
<doko> elmo: if we don't do that, packages may be linked against libs against libstdc++5, which may break them
<elmo> eh, I guess
<elmo> anywya, sure it's possible.  what did you want. no builds, or just source uploads by your key?
<doko> what's easier for you? of course I want to have the packages I upload built as well. Note that maybe a bunch of people will do the uploads. And maybe some MOTU's as well.
<elmo> uh, well we need someway to distinguish them? but I can do whatever, either is fairly easy
<tseng> thats a bit disruptive..
<tseng> meh.
<doko> elmo: or we can just stop the autosync and hope that all people only upload non CXX stuff 
<elmo> doko: that's utterly trivial, sure
<elmo> doko: basically, I can do pretty much whatever you want, so decide what you want, get mdz to sign off on it, and let me know
<elmo> I'm going to crash, it's been far too long a day.  night all
<ajmitch_> night elmo 
<ogra> night elmo 
<doko> night
<mdz> doko: if you can generate a list of packages that should not be uploaded, we can add a check
<doko> mdz, elmo: yes, I can do this. but we need to stop the autosync as well, because it may add new packages, which are not on the list
<infinity> elmo : re: powerpc-utils, you got the wrong version.  Can I get -15, not -14? :)
<ogra> meh
<mdz> doko: ok
* lamont finally gets a working script to send out his key sigs from UDU.  *incoming*
<lamont> infinity: you aroudn?
<som> the meeting log was very informative, if not very exciting
<robertj> glad to see seb128 got tasked with specing a bounty for places integration
<infinity> lamont : I think so.
<AndyFitz> jdub: got your e-mail. will send it through when i get back later tonight
<AndyFitz> anyone else notice FC4 now uses clearlooks ?  we're too trendy.
* lamont wanders off for a while
<daniels> man, I'd forgotten the joy of mirroring new upstream versions of OOo
<daniels> elmo: please sync render 0.9-1 and xrender 0.9.0-1 from debian
<bob2> hah
<bob2> OOo was like 10% of my mirror pulse yesterday
<daniels> i'm *still* catching up on breezy
<daniels> pulsed right before I left for LCA
<jsgotangco> morning
<daniels> pulsed when I got back on, well, Sunday ...
<cartel_> daniels: where are you working these days? canonical?
<daniels> cartel_: yeah
<cartel_> shot :)
<cartel_> good moneys?
<daniels> it pays the bills ;)
<cartel_> so does my job
<cartel_> it just doesnt give me anything else
<jsgotangco> heh
<cartel_> so canonical hired you to look after Xorg?
<daniels> basically; i do other things as well, but xorg is my main responsibility (i take care of linux-restricted-modules, sort of de facto maintain half of ppp*, now some printing stuff, et al)
<cartel_> heh, i remember you doing the prerelease packages for xfree 4.2 and then having branden throw all your work out the window ;)
<cartel_> im doing lots of stuff, building an end-to-end network for 1000 users (with ubuntu frontend), lots of work with xen virtualisation, clustering, and ldap
<cartel_> its a bit annoying working in 6 weeks on a solution that pays your salary 20 times over
<cartel_> and then having your boss offer you a pay rise of $7k in the next 6 months
<cartel_> they want to take out life insurance on me
<cartel_> yet they pay me peanuts
<cartel_> time to take a walk methinks
<cartel_> daniels: how much linux work experience did you have on your cv before you got hired by canonical?
<daniels> heh, d'oh
<daniels> looks like fun though
<daniels> ~4 years
<cartel_> so 4 years on the shop floor in a company?
<daniels> i think this is getting wildly off-topic for #ubuntu-devel, but no
<cartel_> ahh
<cartel_> see i have 7 years but only 2 years on the shop floor
<jsgotangco> (most of it is talent and part of it is luck i guess)
* jsgotangco goes back to lurk the chan
<zul> cartel_: er at least ou are working
<cartel_> zul: working to keep my boss in the lifestyle he is accustomed to yes...
<zul> cartel: my point is that you have a job and you are better off than most people right now
<zul> probably better...but anyways its ot
<cartel_> zul: working on a bottom rung salary amid cries of "we cant afford to pay you guys more, increase your billable and we will talk" when they are driving 90 and 120k cars and extending their houses and getting married...
<jsgotangco> zul is right
<cartel_> when the it support personell at some of our clients earn more than i do
<zul> cartel_: ok lets change jobs then..
<cartel_> i have a job but no job satisfaction
<zul> you can have mine
<cartel_> zul: what do you do?
<zul> im an unemployed contractor
<cartel_> zul: freelancer?
<zul> kind of..
<daniels> tseng: uhm, so when's mono moving into main?
<jsgotangco> whiprush, that blog entry is crack heh
<wasabi> hmm. hdparm won't enable dma on my dvd drive. =/
<fabbione> morning
<wasabi> okay why is CONFIG_IDEDMA_ONLYDISK enabled by default?
<wasabi> sort of makes dvd players useless!
<jdub> because it's the only reliable setting atm
<wasabi> shouldn't hdparm script be smarter instead?
<jdub> better to have users manually turn it on than have a whole bunch of systems simply not work (or worse, break)
<wasabi> I mean, this is hard to manually set. I am recompilling my kernel for the first time in months. =/
<wasabi> and that makes me sad
<jdub> it is not hard to manually set
<wasabi> how? hdparm refuses to do so.
<wasabi> "operation not permitted"
<stuNNed> -/win 2
<stuNNed> oops sorry
<jdub> so what are you doing?
<wasabi> trying to enable dma on my dvd drive.
<wasabi> wasabi@kyoto:/usr/src/linux-source-2.6.10$ sudo hdparm -d1 /dev/hda
<wasabi> ...
<wasabi>  HDIO_SET_DMA failed: Operation not permitted
<jdub> i can certainly do it on mine, perhaps there is good reason why it refuses to do so on yours
<wasabi> perhaps, except it used to work great. =/
<tritium> wasabi, it your dvd really /dev/hda?
<daniels> works on my amd64 with .11
<wasabi> Yeah.
<wasabi> i have all SATA devices except my dvd
<tritium> just double-checking
<wasabi> I'm kinda mad about this. =/
<wasabi> Friend came over so we could watch firefly, and now he has to leave. =(
<crimsun> does dmesg report anything about the ide controller?
<wasabi> Not when I do hdparm
<crimsun> from normal usage, rather
<wasabi> not a whole lot that i can find
<crimsun> you could try unloading then reloading ide_cd if there are errors
<wasabi> Yeah, DriveReady SeekComplete Error
<jsgotangco> brb
<Burgundavia> who is working on the bluetooth stuff?
<Echylo> I guess that wat thom
<Echylo> was* 
<Echylo> Burgundavia ^
<Burgundavia> ok
<dholbach> good morning
<jsgotangco> dholbach, hey
<dholbach> jsgotangco: jerome, how are you?
<jsgotangco> dholbach, im doing fine ive been busy playing around with docs and just finished the log from the breezy kick off meeting too bad i wasn't there its 3am when it happened
<dholbach> how long did the reading take you? :-)
<jsgotangco> yes PDASupport needs love when we did that BOF it was only me and pitti and we didnt have PDAs in the first place
<jsgotangco> probably an hour heh
<dholbach> wow... fast reader then :-)
<ajmitch_> hey jerome
<jsgotangco> ajmitch_, hey hows it going i miss the sydney weather its so humid in manila at the moment heh
<ajmitch_> heh
<ajmitch_> it's a bit colder than sydney here
<jsgotangco> i can imagine
<pitti> Good morning
<daniels> pitti: morning dude!  bad news: we can't stop dbus being restarted.
<dholbach> hey pitti, daniels 
<daniels> pitti: because we need to move out of the dbus-1 package, it's going to get stopped when dbus-1 gets removed, and started again when dbus gets installed.
<daniels> dholbach: yo
<pitti> daniels: hum, and hal?
<pitti> daniels: it's okay to restart dbus, but not hal
<pitti> daniels: darn, the old hal init script should have a dbus version check
<pitti> Hi dholbach 
<pitti> dani
<pitti> daniels: another thing is that we now need dbus 0.33
<daniels> pitti: yes, I have 0.33 locally :)
<daniels> i need to go back to looking after my little sister in a second, but I think the 0.33 packages are now OK
<pitti> daniels: cool :-)
<pitti> daniels: so any idea about the transition?
<daniels> pitti: we upload everything to a staging area and check it, then dump it all on breezy in one big hit
<pitti> daniels: yeah, sounds good
<pitti> daniels: your usual place on people?
<pitti> daniels: then I update my stuff on my people page, too, today
<daniels> pitti: yours on ~pitti/utopia would probably make sense, but yeah, i'll put 0.33 on ~daniels today
<pitti> daniels: I need to update to hal 0.5.1 (I have it locally, but can't compile it)
<pitti> daniels: so if there is no way to do the transition in dbus (don't call the /etc/dbus/event.d/* scripts on upgrade), then we have to do that somehow in hal?
<pitti> daniels: but since other dbus services will break, too, isn't there a way to disable event.d/* calling on upgrade?
<pitti> daniels: okay, just put the packages up, then I think about it again
<pitti> lamont: still here by any chance?
<tim1> good morning
<tim1> is there any specific reason that beagle is listed as successful in the buildlogs but is not in the repos?
<daniels> pitti: i dunno how we do it perfectly
<daniels> pitti: maybe invoke-rc.d dbus-1 restart, when we upgrade to 0.5.1 :P
<pitti> daniels: that's done anyway
<daniels> oh, cool
<pitti> daniels: that's what I mean, we must just not start the event.d/* scripts in the preinst
<pitti> daniels: s/pre/post/
<pitti> daniels: i. e. at the point when the new dbus is already installed, but the new hal isn't yet
<daniels> hmmm
<pitti> daniels: a really, REALLY crude hack:
<pitti> postinst:
<pitti> if dpkg --compare-versions blabla; then
<pitti>   #DEBHELPER
<pitti> fi
<daniels> but we're not upgrading
<daniels> we're uninstalling dbus-1, and installing a new package called dbus
<pitti> uh
<pitti> daniels: will the configuration files remain in /etc/dbus-1/?
<daniels> yeah
<pitti> *phew*
<daniels> and the init script will remain /etc/init.d/dbus-1
<daniels> so we're safe there
<pitti> daniels: I'll think about it when I have all the packages
<dholbach> hey mvo 
<doko> morning all
<dholbach> hey doko
<jsgotangco> hi doko 
<haggai> morning
<mvo> hey dholbach, morning doko, morning all :)
<chmj> morning 
<ajmitch_> hi mvo :)
<jsgotangco> mvo, hey
* mvo waves to ajmitch_ and jsgotangco 
<pitti> Hi doko
<dholbach> hey haggai :-)
<haggai> dholbach: hi :)
<dholbach> hey seb128!
<seb128> daniel!!! ;)
<pitti> Hi seb128 
<seb128> hey pitti 
<mvo> hey seb128 
<seb128> hi mvo
<Lathiat> hmm still no 2.6.12 or beagle in the archives, bleh.
<Lathiat> deprived!
<fabbione> Lathiat: the kernel had a small issue building on i386
<jsgotangco> heh
<Treenaks> Lathiat: spoiled, more likely
<Lathiat> fabbione: ah, bugger
<fabbione> that is reproducible only in a very specific case
<Lathiat> fabbione: hahaha dont you love those
<fabbione> and that i didn't catch because my setup is SANE :)
<Lathiat> heh, whats the problem?
<Treenaks> fabbione: the buildd setup isn't? ;)
<fabbione> Lathiat: building the documentation requires openjade to download a .dtd from the network
<fabbione> Treenaks: they are more restricted
<fabbione> missing that files, the kernel fails to build the documentation
<Treenaks> fabbione: sounds reasonable
<fabbione> in any case i have 2.6.11.92 almost ready
<Lathiat> fabbione: oh, right
<fabbione> so i might as well get that one out
<fabbione> instead of spending time fixing an obsolete 91
<fabbione> :)
<jdub> fabbione: everyone was thoroughly turned on by the changelog, i'm sure they're itching for it ;)
<fabbione> jdub: i am building 92 right now :)
<fabbione> i just got the ppc fix for the FTBFS
<fabbione> + we have squashfs in .92 :)
<fabbione> so let see how much we can break ;)
<jdub> fabbione: rad ;)
<Lathiat> squashfs?
<fabbione> Lathiat: livecd stuff
<jbailey> fabbione: I did notice that I had recently done some upgrades that was causing a long pause after hotplug, and a long pause while loading gnome that went away with the 2.6.11 kernel.
<jbailey> fabbione: I haven't cared enough to look why.
<Lathiat> fabbione: ah cool
<fabbione> jbailey: probably they are related to inotify and gamin
<fabbione> jbailey: you should test with the new kernel and new gamin from breezy
<fabbione> skip 2.6.11
<fabbione> it's crap
<jbailey> fabbione: I update as quick as I can on my boxes to make sure that there aren't crazy glibc or initrd breakages creeping in.
<|QuaD-_> what exactly is gamin?
<Lathiat> |QuaD-_: file change monitor daemon
<|QuaD-_> Lathiat: what does it do though?
<Lathiat> |QuaD-_: monitors changes to files and directories
<jbailey> |QuaD-_: "apt-cache show gamin" is your friend =)
<Lathiat> |QuaD-_: and notifies programs
<Lathiat> |QuaD-_: (who request it)
<jbailey> Hmm, actualy.
<jbailey> That description kinda sucks.
* Lathiat grins at jbailey 
* jbailey pokes jdub 
<Lathiat> jbailey: fixed my headers issues yet? :)
<|QuaD-_> Lathiat: so thats how things like dashboard/beagle update when you save things?
<Lathiat> |QuaD-_: yeh
<Lathiat> altho beagle uses inotify directly
<jbailey> Lathiat: Nope, today was the meeting, klibc, some biarch bits and getting my email working again.
<Lathiat> rather than gamin
<|QuaD-_> jbailey: "Gamin is a file and directory monitoring system defined to be a
<|QuaD-_>  subset of the FAM (File Alteration Monitor) system."
<Lathiat> jbailey: ;) its ok im just hassling. :)
<jbailey> Lathiat: Tomorrow will be support related things, my next hack day will be Wednesday.
<|QuaD-_> Lathiat: thought thats what inotify was for. is inotify going to take the place of gamin?
<fabbione> jbailey: what happened to cdbs sync?
<Lathiat> |QuaD-_: no, gamin uses inotify as a backend
<fabbione> we still have a few pkgs dep-waiting for it
<jbailey> fabbione: No idea.  I should poke elmo about those again.  There's 4 or 5 waiting on him.
<Lathiat> |QuaD-_: using gamin means you can do file  notifications portably, when various systems are or are not supprotign whatever method
<Lathiat> its also probably ore convenient API to use
<Lathiat> and also breaks. :)
<fabbione> jbailey: was it a straight sync from debian?
<jbailey> fabbione: Yes.
<|QuaD-_> Lathiat: ok, so gamin is just a frontend for inotify?
<Lathiat> |QuaD-_: no
<jbailey> fabbione: Are you able to do those
<jbailey> ?
<|QuaD-_> Lathiat: ok that makes more sense
<fabbione> elmo: can you please sync cdbs from debian. ok to override
<fabbione> jbailey: no, but i can ping elmo again when he wakes up :)
<Lathiat> |QuaD-_: its a frotend to dnotify, inotify, manual stat()ing, etc -- altho yes essentially, it is
<jbailey> fabbione: Ah lovely.  It's possible a victim of timezone skew.
<ajmitch_> jbailey!
<fabbione> jbailey: probably
<jbailey> ajmitch_: Heya Andrew
<ajmitch_> hi
<|QuaD-_> Lathiat: i thought dnotify was being replaced?
<astharot> ciao
<Lathiat> |QuaD-_: yes, with inotify
<Lathiat> |QuaD-_: but if inotify isnt available, it will use dnotify()
<Lathiat> err
<Lathiat> no ()
<|QuaD-_> Lathiat: the pieces are all coming together now :)
<jdub> yo jbailey 
<dholbach> jdub: hey jeff, what do you think about ubuntu-motu@ now?
<dholbach> :-)
<jbailey> jdub: Just poking you over the terse long description of gamin. =)
<ajmitch_> jdub: many MOTUs will be eternally in your debt
<Lathiat> we have an ubuntu-motu now?
<Lathiat> woo
<dholbach> Lathiat: not yet, this is what the conversation is about :-)
<Lathiat> oh
<thom> g'morning
<Burgundavia> thom, read p.g.o this morning?
<dholbach> hey thom 
<jsgotangco> thom, hey
<fabbione> hey thom
<mvo> mdz: ping?
<dholbach> brb
<thom> Burgundavia: j5's post, or something else?
<Burgundavia> thom, that one
<\sh> morning
<thom> Burgundavia: too long term for us, but it may be interesting
<thom> morning \sh
<Burgundavia> thom, just figured you might want to know
<thom> thankee
<Burgundavia> thom, np
<thom> fabbione: the network card that was having grief was a marvel (ie, sk98lin); it was losing and regaining link every 10 minutes or so
<fabbione> thom: amen
<fabbione> that driver is problematic
<fabbione> the update from marvel will never make upstream
<thom> oh joy
<fabbione> and the update is like a 1.5MB patch
<fabbione> that will never make it trough my (in)sanity check
<thom> well, i think not having working networking is a bit of a problem ;-)
<fabbione> i know....
<fabbione> buy better hardware :)
<fabbione> but there is a bug filed
<thom> heh
<fabbione> mainly we need to check the driver licence
<fabbione> if you want to give it a shot
<fabbione> i can probably add it for 2.6.11.92-1.2
<fabbione> 1.1 is going out in a very short time
<thom> sure; can you url me?
<fabbione> 6142 is the bug 
<fabbione> the url to the driver is at comment #23
<thom> right; I'll have a look (note that this problem is a regression from 2.6.10 for me - ie it's not the same bug as 6142; the hoary kernel works perfectly)
<dholbach> fabbione: did you make lots of changes to the new kernel image since the one on people.u.c/~fabbione?
<fabbione> yes
<dholbach> good, because it seems to work better on amd64 for me
<dholbach> no funny crashes every 30m :-)
* dholbach hugs the kernel team
<Lathiat> hehe
<jsgotangco> i gotta upload my photos
<fabbione> elmo: can you please update gcc-3.4 on davis breezy chroot?
<doko> elmo: please could you sync autogen from unstable? the current version breaks the gcc-4.0 build
<elmo> fabbione: done
<elmo> doko: already done
<fabbione> elmo: thanks
<fabbione> elmo: aslo the cdbs sync please.. ok to override
<elmo> fabbione: also already done
<fabbione> elmo: you rock!
<Burgundavia> seb128_, ping
<seb128_> ?
<Burgundavia> https://launchpad.ubuntu.com/malone/bugs/579
<Burgundavia> it seems malone won't let me comment on the bug
<dholbach> Burgundavia: you're logged in and have a preferred email set?
<Burgundavia> dholbach, yes
<dholbach> hrmm
<seb128_> you comment and get a message?
<Burgundavia> yep
<seb128_> you need to enter the comment again from this window
<seb128_> that's a known bug
<seb128_> should be fixed today
<Burgundavia> ah
<Keybuk> Debian Installer <installer@ftp-master.debian.org>
<Keybuk> From: Debian Installer <installer@ftp-master.debian.org>
<Keybuk> Subject: 	mozilla-thunderbird-locale-fr_1.0.dfsg-2ubuntu1_source.changes REJECTED
<Keybuk> Rejected: Unknown distribution `breezy'.
<Keybuk> oops :p
<Keybuk> who did that? :p
<elmo> hahaha
<dholbach> :-D
<elmo> TOUR GUIDE, COME ON DOWN
<Burgundavia> seb128_, thanks, done
<Nafallo> hi all
<pitti> Hi Nafallo
<seb128> anybody here gets A/V sync issues with the current gstreamer packages?
<pitti> seb128: playing video with gstreamer does not really work on my box at all :-(
<seb128> that has been mentionned during the VideoRoadmap BOF, but according to upstream that should work fine now and they would be happy to get bugs if people still get suchs issues
<jbailey> seb128: How recent a gstreamer are you thinking?
<jbailey> seb128: The stuff in Hoary had sync issues for me.
<seb128> jbailey: there is no changes since hoary
<seb128> DVD is a special case
<thom> Keybuk: yes yes. i've already mailed aurelin and apologised
<seb128> do you have sync issues on what kind of files?
<jbailey> seb128: Ah, dvd was the only thing I was looking at.
<seb128> k, so that's known
<Keybuk> thom: cool :)  just checking
<Keybuk> didn't know whether you got a copy of it or not
<seb128> bbr
<thom> no, i realised as soon as i'd done it :-)
<thom> fabbione: new inotify out, with abi/api borkage :-)
<fabbione> thom: meh.. 
<daniels> thom: to complement dbus
<fabbione> thom: are you sure you don't want to join the kernel team.. you are so incredibly fast
<Lathiat> api and abi breakage seems to be the flavour of the month
<fabbione> elmo: are you upgrading the whole breezy chroot on davis?
<fabbione>  fakeroot: command not found
<thom> fabbione: hahah; i'm reading that mail from mdz currently
<fabbione> there.. fakeroot is bak
<lifeless> hmm, lots of seeking on a new ppc install
<fabbione> back
<lifeless> (cdrom seeking)
<lifeless> Kamion: ping
<elmo> fabbione: err, yes, sorry
<fabbione> elmo: no problem dude :)
* fabbione goes for food
<Kamion> lifeless: pong
<lifeless> how do you switch vty's on the hoary ppc install cd ?
<Kamion> lifeless: I've done just about everything I can about seeking without totally upending the install; I won't be wasting any more time on it
<Kamion> lifeless: one of: cmd-f2; cmd-fn-f2; alt-f2; alt-fn-f2
<Kamion> pressed in that order
<Kamion> depends on the keymap unfortunately
<lifeless> omg
<lifeless> alt-fn-f2 in that order
<lifeless> could we get doco on that in the intro text ?
<Kamion> no because it *depends on the keymap*
<Kamion> which sucks, yes
<lifeless> Kamion: as in 'list them all'
<lifeless> exactly what you told me is all I needed
<Kamion> I'd rather see vaguely consistent keymaps first
<Kamion> probably fits better in the installation manual
<bob2> it'd be saner to disable fn-first if at all possible
<Kamion> any idea how to do that in the installer? (no pbbuttonsd or whatever)
<Kamion>                         ADBBuffer[3]  &= 0xfe;
<Kamion>                         ADBBuffer[3]  |= (config & KEYBOARD_FNTOP) ? 0x01 : 0x00;
<Kamion>                         adb_write_reg (fd, ADBBuffer, n, dev, 1);
<Kamion> hmm
<Kamion> nice shell-friendly interface :-P
<bob2> hehe
<Kamion> well, feel free to file a bug against, er, probably kbd-chooser for that; I do agree it would be nice to set fkeysfirst
<willis> beagle has been in breezy's source package list for 12 hours now, i was just wondering when it would end up in breezy's binary package list and could be downloaded and installed?
<elmo> chmj: please close the linc bug, it's been removed from debian and ubuntu
<lifeless> mmm
<lifeless> new install, my mouse doesn't work :p
<chmj> elmo: that saves me a huge panic
<elmo> lifeless: is it a new new powerbook?
<lifeless> yes
<lifeless> spanking
<tseng> daniels: hopefully sometime this week.. getting everything sorted on amd64
<elmo> lifeless: yeah, they changed the trackpad pretty fundamentally, it's not going to work with hoary's kernel :(
<lifeless> groan. breezy works ?
<elmo> I've seen people working on it, 2.6.12 or so might support it, I'm not sure
<daniels> tseng: cool.  i sort of merged mono support into 0.33.
<tseng> daniels: rock
<daniels> lifeless: still not really working at this stage; it's sort of i-can't-believe-it's-not-usb-hid.  thanks apple.
<lifeless> elmo: oh well. spare 10 GB parition.
<lifeless> daniels: neato.
<daniels> tseng: not so much 'rock', because it means I can't upload new dbus until it's done.  get cracking. :P
<lifeless> so time to see if parted f*cked the hfs+ partition
<willis> just wondering, i noticed that both, linux-image-2.6.12 and beagle built succesfuly in the logs, but they haven't ended up in the any repositories except for breezy source
<lifeless> ok, hfs+ still happy. yay
<pitti> willis: linux failed on i386
<fabbione> there is a new version building right now
<fabbione> be patience
<thom> fabbione: i'm tempted to add the skge driver and try that
<willis> pitti, ah yes thanks
<fabbione> thom: if you can test it, that would for sure help
<daniels> pitti: p.u.c/~daniels/dbus/
<pitti> daniels: rock, thanks
<daniels> pitti: any time
<abelli> ciao
<abelli> fabbione: u here?
<fabbione> abelli: yes
<lifeless> Kamion: whats your ubuntu email address ?
<Amaranth> colin.watson@ubuntu.com ?
<lifeless> well kamion and colin both bounced.
<lifeless> so I'm checking this time to be sure
<Amaranth> well, if that one bounces you'll know it isn't right :)
<elmo> cjwatson@ is his short alias
<fabbione> lifeless: cjwatson@
<lifeless> Amaranth: thanks. 
<Kamion> yes, cjwatson or colin.watson, neither colin nor kamion will work
<Amaranth> is the amd64 buildd still messed up?
<Kamion> lifeless: not quite sure what the e-mail is about though :)
<elmo> Amaranth: please stop doing that
<lifeless> Kamion: parted asked me to email some random due
<lifeless> *dude*
<elmo> lamont was quite clear yesterday, that _one_ isolated buildd had issues and that it's been taken out of rotation
<Amaranth> oh :P
<Amaranth> I wasn't here for that part, just going by what I saw in #ubuntu-motu
<elmo> Amaranth: dude, he was talking _to you_
<Amaranth> he was?
<elmo> yes.
<Amaranth> err, i don't remember that
<Kamion> lifeless: oh, I see that now but had never looked at that code before
<Amaranth> oh well
<Kamion> but thanks for the mail
<elmo> 18:48 < lamont> Amaranth: there is _one_ buildd that is throwing random segv's, removed from the rotation until it gets a good checkup.  otherwise, life is goin
<elmo> g well.
* Amaranth needs more coffee
<Amaranth> sorry
<jsgotangco> bye bye
<Kamion> -rwxr-xr-x  1 root root 14621 2004-04-18 18:15 /bin/lsb_release
<Kamion> a *shell script*. Jesus, whatever happened to writing small code
<ajmitch_> hi seb
<mvirkkil> Has anyone seen evolution causing the hd to stall? Doing an 'ls' will not work. I get messages like 'pio timeout' and 'dma write failed'.
<mvirkkil> I don't understand how evolution could be causing it, but it only happens after I've used evolution.
<dholbach> sounds rather like kernel/hardware's fault?
<Amaranth> yeah, i'd say it's the hard drive
<tseng> daniels: right now its looking like there are regressions in dh_clideps, alot of mono depends are busted
<daniels> tseng: awesome
<tseng> yeah it might be a bit longer
<seb128> elmo: can you ban python-gtk2 from the archive, we have renamed it to pygtk
<dholbach> seb128: there are a lot of packages depending on it still
<dholbach> seb128: 37
<seb128> dholbach: ??
<seb128> dholbach: you didn't get it
<dholbach> ok :-)
<seb128> apt-cache showsrc python-gtk2
<dholbach> yesyes :-))
<dholbach> i was already worried ;-)
<seb128> you really think I want to kick pygtk out of the distro??
<dholbach> seb128: if you have a lousy day, i could imagine so :-)
<seb128> you should take some sleep dude :)
* Amaranth would die :/
<seb128> ah ah
* pitti curses at his crappy internet connection, brb
<pitti> seb128: do you know anything about upstream's status of transitioning to dbus 0.33 and hal 0.5?
<pitti> seb128: I mean for gnome-vfs and the like
<seb128> GNOME is fine
<seb128> FC4 uses dbus 0.33 and hal 0.5
<seb128> so they have the corresponding patches for GNOME
<dholbach> seb128 is too well informed about RH :-)
<seb128> the gnomevfs changes are already upstream
<pitti> seb128: so if daniels and me upload the new crack in the next days, you could make gvfs work again relatively quickly?
<seb128> dholbach: I went to the UbuntuAndUpstream BOF :)
<seb128> pitti: I'm ready for the switch
<dholbach> hahaaaha :-)
<pitti> cool
<daniels> tseng: mono in main pls
<dholbach> seb128: i got lost in FindingPackages :-)
<dholbach> daniels: he drove to work
<pitti> seb128: now I'm breaking my head about providing a clean upgrade transition, when we have it we are ready to go
<seb128> pitti: I talk with upstream yesterday, gnome-vfs CVS is fine, just need to do a CVS package
<seb128> pitti: upstream is running breezy, with your packages from 3 weeks ago and gnome-vfs CVS 
<Zomb> tseng:  feel free to join #debian-mono if you have something to contribute
<dholbach> Zomb: he drove to work
<daniels> pitti: if all you guys are waiting on is dbus, I'll throw libdbus-cil out for the time being and sort the mono component out later
<pitti> daniels: I just upgraded to your packages (breaking my whole packaging system with --force-depends all over the place)
<pitti> daniels: now I'm compiling hal 0.5.1
<daniels> yeah, I can't install anything anymore
<daniels> apt showers me in hate
<pitti> daniels: it would be easier if dbus would at least Provide: dbus-1 for a transition period
<pitti> daniels: alternatively we need an emtpy transition package
<daniels> um
<daniels> the only dbus-1 depends would be autogenerated
<pitti> it isn't nice, though
<daniels> i.e. files linked against libdbus-1.so.0 that would break anyway
<pitti> daniels: okay, we can also collect all packages depending on dbus-1 and recompile them in one shot
<daniels> that's the one
<Amaranth> hmm, not too many in that list
<Amaranth> or does rdepends only show the packages i have installed?
<Lathiat> oyes
<Lathiat> only those you have installed
<daniels> er, rdepends is an apt-cache thing
<daniels> it shows everything
<Lathiat> oh
<Lathiat> my bad
<pitti> daniels: uh, apt-get -f install is ... interesting
<Kamion> elmo: any news on that ziyi fix? can I help?
<Lathiat> pitti: interesting?
<pitti> Lathiat: it basically wants to remove all of gnome
<Lathiat> heh
<Lathiat> what do you have broken
<elmo> Kamion: meh.  sorry, forgot.  really doing
<daniels> pitti: yeah
<pitti> Lathiat: upgraded to daniel's dbus pacakges :)
<mvo> the fixer has interessting ideas somestimes :)
<Lathiat> haha
<Kamion> elmo: np, thanks
<pitti> mvo: in fact it's the only way to return to a consistent state (unless you teach apt to downgrade and change packages)
<Kamion> have to kick up new d-i to get working framebuffer anyway
<mvirkkil> dholbach, Amaranth: Yeah, I figured that hd failure was the most likely problem, but I cannot reproduce it with any kind of stresstesting/usage besides opening evolution. 
<mvirkkil> dholbach, Amaranth: Oh, well. I guess I should make backups and start looking for a new hd since there is no other logical explanation to the problem.
<Amaranth> pop it in another computer and mount it read only
<dholbach> mvirkkil: i'm no expert on this... sorry :-/
<seb128> pitti: it probably wants to drop gnomevfs?
<mvirkkil> How usable is breezy at the moment? 
<pitti> seb128: it wants to drop gnome
<pitti> mvirkkil: works reasonable for me (apart from local breakage)
<mvirkkil> For development that is (ie how far is the gcc transition)?
<seb128> pitti: yeah, I've understood that, just figuring why ... that's probably due to lib like gnomevfs
<pitti> yeah
<seb128> where are you package guys? so I can break everything too and fix gnome :)
<Kamion> mvirkkil: C++ transition hasn't happened yet
<thom> seb128: epiphany needs a minor patch to build with new dbus; i filed an upstream bug about it (#301153)
<mvirkkil> Kamion: Does an eta exist?
<seb128> thom: rock, thanks
<dholbach> Kamion: the complete-complete-complete c++ transition will take *some* time, we have to touch some hundred packages for it, but breezy itself will be usable still
<Kamion> mvirkkil: over the next few days for main, I believe
<Kamion> dholbach: sure
<Kamion> dholbach: I was around the last time it happened in Debian, I know the ropes :)
<mvirkkil> dholbach: Ok. Then I'll upgrade to breezy, since the new kernel supports my tv-out card :-)
<dholbach> Kamion, mvirkkil: it will be SO MUCH fun, i can feel it already :-)
<mvirkkil> dholbach: And I'm working on my own little version of usplash
<Kamion> you guys have a strange concept of fun ;)
<daniels> yeah, the 1.02 transition was awesome
<dholbach> Kamion: ... says the debian-installer guy :-))))
<mvirkkil> Kamion: You are the d-i guy?
<Kamion> mvirkkil: yes
<Kamion> well, the one in Ubuntu, anyway
<mvirkkil> Kamion: Cool. I've been playing around with bogl quite a bit, and I was wondering if theree is any interest in trying to prettify the widgets?
<mvirkkil> Kamion: Or is it a moot point withthe new graphical installer?
<Kamion> we aren't targetting cdebconf/gtk for breezy, see http://udu.wiki.ubuntu.com/GraphicalInstaller
<Kamion> so sure
<ogra> yay
<mvirkkil> Kamion: But the target is running the graphical installer off of the live cd?
<Kamion> mvirkkil: it'll be custom pygtk widgets, the startup process will still be bogl/newt
<mvirkkil> Kamion: Ok. Nice to know.
<Kamion> and the regular non-live-CD installer will still be fully supported
<mvirkkil> Kamion: Yes, but once the live-cd supports installation, 90% will use that.
<pitti> daniels: why does libdbus-1-1 conflict to dbus-1? is this really necessary?
<Kamion> that's a moot point, but I don't really feel like arguing the toos
<Kamion> toss
<daniels> pitti: sure
<daniels> pitti: dbus-1 provided the dbus binaries as well as the library
<Kamion> I suspect that people installing 90% of machines (i.e. big deployments) will continue to use the regular installer, even if 90% of *people* use the live CD-based one
<Kamion> :-)
<pitti> daniels: yeah, but I thought dbus-1 provides SONAME 0, whereas libdbus-1-1 provides SONAME 1?
<daniels> pitti: SONAME 0 and binaries
<Mitario> hi everyone
<daniels> pitti: and the 'dbus' package now provides the binaries
<pitti> daniels: libdbus-1-1 provides binaries?
<mvirkkil> Kamion: When you put it that way.. I trust your judgement. I'll probably try looking in to bogl's widget a bit during next week.
<daniels> so that would only be useful for old dbus-1, new libdbus-1-1
<daniels> which would be a situation that's kind of hard to engineer :)
<pitti> hm, ok
<Kamion> mvirkkil: what sort of changes are you thinking of?
<pitti> daniels: I downgraded to hoary versions and now I try to convince apt to install the new crack
<daniels> pitti: mmm, I can sort of see that
<mvirkkil> Kamion: No changes in functionality. Just making the progressbar and pushbuttons a bit prettier.
<Kamion> 'k
<daniels> pitti: but you still couldn't dist-upgrade in any case
<elmo> (disabling cron.daily & cron.unchecked)
<pitti> daniels: I collect a list of packages which need to be upgraded
<daniels> pitti: apt-cache rdepends dbus-1 dbus-qt-1 dbus-glib-1?
<elmo> Kamion: could you use your jackass supah powahs to check out the new breezy/Releases and see if that works for you?
<seb128> elmo: have you read about python-gtk2?
<elmo> seb128: yes, I've excluded it from further syncs
<elmo> I'll remove the source in a bit.  and eds1.2 too
<seb128> thanks
<Kamion> elmo: looks good, thanks
<elmo> k, cron.daily/unchecked re-enabled. full speed, MAXIMUM CHICKEN, ahead!
* thom goes back to the moz-ff-locales-all merge of death
<thom> Keybuk: any progress with moz-ffox -> ffox MOM love? :-)
<Keybuk> thom: we blacklisted it, so no merges or syncs will happen for either
<Keybuk> that's about as much progress as you can expect :p
<Keybuk> elmo's sync stuff needs to understand mappings before mom can
* thom -> train -> birmingham -> hanging keybuk by his toenails from the bullring
<daniels> thom: yeah, i pity you.  i mean, syncs are hard, but now you have to do the syncs in debian, too!
<seb128> Keybuk: speaking about merge, atm we don't get sync bugs for experimental?
<thom> daniels: that made no sense
<daniels> thom: well, you have been uploading to ftp-amster
<Keybuk> seb128: that's right
<Keybuk> actually, I think you do?
* Keybuk can't remember
<thom> oh, right. it was an attempt at humour. sorry i missed out on that stunning joke
<Keybuk> they go in Bugzilla, no?
<elmo> no, you won't
<elmo> at least not unless mom developed her own smarts
<elmo> my sync stuff doesn't remember where stuff came from last
<seb128> Keybuk: I don't think so, I don't get bug for GNOME 2.10 afaik
<elmo> since we're going to be using it for another 6 months, I should probably fix that
<Keybuk> seb128: oh, sorry
<Keybuk> experimental != universe
<Keybuk> my brain is entirely fried today
<seb128> ;)
<Keybuk> that's right
<zul> hey
<Keybuk> mom only knows about unstable
<seb128> maybe that would be a good idea to teach it about experimental too?
<Amaranth> what is mom? :)
<thom> elmo: can you do mappings while you're at it too, please ;-)
<Keybuk> maybe
<Keybuk> you can add that to the bottom of my copious todo list :p
<Keybuk> should be able to have it ready for you by windy or gusty
<seb128> bah, why am I trying to get extra bugs
<Kamion> Amaranth: merge-o-matic
<seb128> I already have enough :p
<pitti> seb128: I think we need you for the transition
<aj> "windy weasel" ?
<aj> what an awesome release name
<seb128> pitti: <seb128> where are you package guys? so I can break everything too and fix gnome :)
<seb128> pitti: was half an hour ago :)
<elmo> WTF
<seb128> pitti: ie: gimme the crack and I fix my part
<Kamion> hmm, I probably shouldn't even bother trying to build CDs this week, should I?
<elmo> why isn't svn diff in alpha order?
<Keybuk> breezy all installed today, I was quite shocked
<Kamion> elmo: never understood that
<Kamion> Keybuk: considering the state of http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html, that surprises me
<pitti> seb128: with the packages in http://people.ubuntu.com/~daniels/dbus/ and http://people.ubuntu.com/~pitti/utopia/, could you put upgraded packages into p.u.c./~seb128/dbus/ ?
<pitti> seb128: gnome-vfs2, nautilus-cd-burner, totem, gnome-media, evolution
<pitti> seb128: there are some more packages affected, but above will do for testing
<pitti> seb128: (rest: update-notifier, epiphany-browser, bluez-pin, bluez-utils, screem)
<daniels> oh dear
<daniels> 4466     May 10 bugzilla-daemon (   0) [Bug 10589]   New: render: new changes from Debian require merging
<seb128> pitti: epiphany-browser has a patch from thom
<pitti> seb128: ah, I misunderstood "where are you package guys" -> I'm right at home :-)
<pitti> seb128: "packages, guys" would have made it clear :-)
<seb128> yeah, sorry
<seb128> s/you/your/ too
<seb128> pitti: I just grab something to eat and start working on that, should take ~2 hours I think 
<seb128> for the list you gave
<pitti> cool
<Kamion> elmo: promoting lshw-common to main would deal with most of the ubuntu-standard uninstallability, I think
<elmo> what the heck is lshw-common anyways? it's not even arch: all
<Kamion> looks like it's meant to be
<Kamion> I'll file a bug
<Kamion> I think its point was to be common between lshw and lshw-gtk
<elmo> Kamion: promoted
<Kamion> ... and bug filed. thanks
<thom> Keybuk: also, MoM probably ought to check hoary-updates/hoary-security to see if there's a later package in there?
<Keybuk> what's MoM got to do with hoary?
<thom> ok, not MoM; but you get the point i was trying to make?
<Keybuk> nda?
<Keybuk> yeah, probably
<Lathiat> what is Mom?
<thom> Lathiat: read scrollback
<dholbach> merge-o-matic
<Keybuk> actually, nda runs against breezy too
<dholbach> read the bugzilla bugs resolved as UNIVERSE and you get an idea
<thom> n/m; it's a usecase that doesn't really apply
<dholbach> see you later guys
<Keybuk> maybe it should check unstable for packages that were supposed to go into breezy? :p
<thom> assuming anyone manages that i think we have bigger problems than merges :p
<doko> keybuk: can we stop the merge-reminders for packages depending on python* for some time? we should do these when etch does the python transition
<Keybuk> no
<Keybuk> or, perhaps, "patches welcome" :p
<pitti> mvo: using the packages in http://people.ubuntu.com/~daniels/dbus/, could you please prepare a new update-notifier for the new dbus?
<mvo> pitti: yes
<pitti> mvo: cool, thanks
<pitti> mvo: it's a new API, so this probably requires some porting efforts
<mvo> pitti: the url is not apt-able?
<pitti> mvo: I already did the porting for pmount, so if you need some hints, just ping me :)
<mvo> pitti: will do, thanks :)
<pitti> mvo: no, you can't install the packages with apt
<pitti> mvo: dpkg -i --force-depends :-/
<mvo> *ick*
<pitti> mvo, seb128: oh, and before: sudo dpkg -P --force-depends dbus-1 dbus-1-doc dbus-glib-1
<pitti> mvo: as I said, that's very rough, that's why we need to upload all packages in one shot
<pitti> mvo: you can install the new hal if you want/need it for u-m from http://people.ubuntu.com/~pitti/utopia/
<pitti> u-n even
<eruin> is there inotify support in the current breezy kernel?
<Amaranth> eruin: there will be
<kamstrup> Will it be enabled?
<kamstrup> -- at boot i mean.
<eruin> I'm checking out linux-source 2.6.12 atm
* Amaranth is not a dev
<Amaranth> eruin: That's 2.6.12rc2, iirc
<eruin> and loving the fact that beagle is in breez ;)
<eruin> 2.6.11.91 they say
<Amaranth> yeah, it's rc2 or rc3
<fabbione> 92 is out
<kamstrup> Too bad I can't use Beagle :( My /home is on an XFS
<fabbione> just wait for the buildd
* eruin runs for changelog
<fabbione> that is rc4
<Amaranth> fabbione: hot
<Amaranth> p.u.c uses GMT, right?
<kamstrup> I've heard Beagle-talk in many distros by now, but nobody seems to be addressing the fact that it requires xattr
<kamstrup> what's up with that?
<Treenaks> kamstrup: suse 9.3 does
<fabbione> we have xattr enabled
<fabbione> on all FS that actually supports it
<kamstrup> Yes, for ext3/2 partitions right?
<fabbione> also for all the others that have xattr
<fabbione> it's not only ext2/3
<Amaranth> kamstrup: Why the heck are you using XFS? :)
<kamstrup> I started using XFS way back when nobody was talking xattr
<daniels> hm, I thought XFS supported xattr if you compiled it right
<kamstrup> I'm quite sure it doesn't
<seb128> pitti: /usr/sbin/hald: unrecognized option `--drop-privileges'
<pitti> seb128: known upgrade problem
<seb128> k
<pitti> seb128: should work anyway
<kamstrup> wait... maybe it did once, but it was dropped because it was buggy... :S
<daniels> yes, yes it does
<daniels> http://www.ussg.iu.edu/hypermail/linux/kernel/0203.3/att-0298/01-xattr-2.4.19-pre4.patch
<daniels> that was against 2.4.19
<kamstrup> I thought right :)
<kamstrup> daniels: - and I wonder how you came up with an obscure link like that so fast :)
<daniels> kamstrup: google
<kamstrup> Maybe I should go back to 2.4.19 when Breezy hits the road?
<kamstrup> Oh... I've heard about that :)
<daniels> well, I assume it got merged in somewhere along the way
<Amaranth> php says xattr is supported on xfs :)
<thom> xfs supports xattr by defaqult, it's just built in
<thom> no options required
<daniels> right
<kamstrup> Oh...
<kamstrup> I was just skimming "make menuconfig" and couldn't find any xattr for XFS/JFS/ReiserFS, that explains that partially
<Amaranth> *boggle*
<Amaranth> wait, xattrs are file metadata?
<kamstrup> Yes. Kinda
<Amaranth> extendable, customizable, file metadata?
<Amaranth> meaning, no limits to keys and such
* Amaranth falls over
<kamstrup> "Extended attributes are name:value pairs associated with inodes by the kernel or by users" 
<kamstrup> -- from menuconfig
<Amaranth> when did this get sneaked in and why isn't anyone making a big deal out of it?
<kamstrup> I dunno...
<kamstrup> I read on the lkml that Linus thinks it is a hack :)
<Amaranth> pfft
<kamstrup> What about resier4 in the kernel? Suse has that too right?
<Amaranth> that'd be nice :)
<thom> suse are welcome to it
<daniels> xattrs have been in there for about a bajillion years
<kamstrup> and that is a lot of years
<Amaranth> maybe no one is making a fuss because no one calls it metadata :)
<zul> bleah...reiser4
<Treenaks> ricerfs
<thom> eraserfs
<kamstrup> Hehe metadata is taboo and nobody knows what xattr is, so everythings is a ok
<kamstrup> In this spirit why not redub "bugs" as "pandas"? Nobody can blame a panda. It is cute and is a threatened species.
<kamstrup> "Fedora Core is full of pandas"
* daniels rails against mplayer.
<Amaranth> kamstrup: But then developers couldn't squash pandas and no one would like Fedora. ;)
<kamstrup> Amaranth: I see.
<kamstrup> geiserfs
<kamstrup> -- explodes every day at 12 o clock :)
<Treenaks> kamstrup: kaiserfs ?
<Amaranth> ok, ok, so it sucks right now
<Amaranth> it's a good idea tough
<Amaranth> err, though
<kamstrup> Treenaks: One file-system to rule them all. 
<kamstrup> I heard that reiser4 needs defragging like ye olde fat-fs's... Is that correct?
<Amaranth> it's designed so it doesn't need defragged
<Amaranth> or something like that, the buzzwords went over my head
<kamstrup> But I heard it did anyway
<lamont> ah, partimage.  sigh
<eruin> this all sounds like quake
<Amaranth> i think it does a mini-defrag on file save
<kamstrup> To be more specific: Performance should be amazing at first, but after a while it should decrease steadily...
<eruin> I wonder why best doesnt turn up anything but im conversations and stuff like that
<kamstrup> eruin: last time I tried best it couldn't find anything but pdfs
<Amaranth> it's still indexing
<eruin> it doesn't like turning up with anything but im conversations and emails here... it seems to despise files
<eruin> allow me to eruin@lorien:~ $ export BEAGLE_EXERCISE_THE_DOG=1
<kamstrup> Hehe... I had it exactly the other way around... It was back in 0.0.7 or sumtin, me tinks
<Amaranth> eruin: You need to restart beagled after you do that.
<eruin> Amaranth: I've done so ;)
<Amaranth> eruin: And it'll probably kill your computer. :P
<eruin> didn't seem to have an effect
<eruin> atleast
<eruin> it's not using any cpu
<eruin> :P
<kamstrup> Will there be Python Cairo bindings in Breezy? (they kick as - but cvs doesn't work atm)
<daniels> kamstrup: when they make it into a released tarball, yeah
<daniels> i'm not comfortable with tracking cvs until carl gets bored with breaking the api every other day
<mvo> ping jdub 
<jdub> yo mvo 
<jdub> mvo: hrm, wandering off for a bit - perhaps mail me? :)
<mvo> jdub: what do you think about michiel gui suggestion http://blogs.gnome.org/michiels
<mvo> jdub: oh, ok. no problem :)
<jdub> mvo: excellent changes :-)
<jdub> mvo: (just caught me ;)
<hunger> The 686-smp kernel does not seem to robust... two crashes since I switched to it this morning:-(
<eruin> fabbione: any way to enable inotify in the 2.6.12 kernel give in ubuntu-devel@, or even in the stock breezy kernel?
<fabbione> eruin: inotify is enable in 2.6.11.91 and .92
<fabbione> by default
<eruin> cheers ;)
<fabbione> there is no stock breezy kernel
<fabbione> the breezy kernel will be 2.6.12
<fabbione> when it will be final
<fabbione> and so on...
<eruin> ah, thanks for clearing that up :)
* ogra cries about the broken mono....
* Treenaks gives ogra some candy
<ogra> Treenaks, thanks, perfect timing for the fresh coffee ;)
<mvo> pitti: I ported update-manager, but I'm unable to test it because it looks like gnome-volume-manager is not doing anything anymore. puting in a cd has no effect. is this a know problem? or am I just missing something :)?
<thom> seb128: can you have a look at #9097?
<seb128> sure I can
<thom> ta
<seb128> thom: I've asked for a bt with the -dbg 
<ogra> <-- bath
<pitti> mvo: did you upgrade to my gvm at p.u.c/~pitti/utopia/?
<mvo> pitti: yes
<pitti> mvo: does it still run? if not, you might need to start it manually in a shell
<mvo> pitti: I just restarted it, no effect. I also restarted dbus ... anymore I need to do?
<pitti> mvo: did you upgrade hal?
<mvo> pitti: yes
<pitti> mvo: what does gvm say when you insert the CD?
<mvo> pitti: nothing
<pitti> grumpf
<pitti> mvo: can you email me a lshal before and after inserting the cd?
<seb128> pitti: I've updated packages for gnome-vfs gnome-media nautilus-cd-burner epiphany-browser
<pitti> seb128: you rock
<pitti> seb128: can you put them on people?
<seb128> k
<seb128> I'm working on evo which ftbfs for different reason
<seb128> I blame Mithrandir who brokes pkg-config
<xuzo> lshw-common is not instable from a debootstraped breezy, should report this has a bug?
<seb128> I'll already upload the other stuff on pu.c
<pitti> seb128: does the new hal work for you?
<Kamion> xuzo: it was in universe; already fixed
<xuzo> Kamion, should be in main?
<Kamion> xuzo: yes
<xuzo> s/should/shold not/
<Kamion> xuzo: may not have hit your mirror yet
<xuzo> oh, ok
<seb128> pitti: putting an audio CD starts the CD player and lshal works fine
<seb128> pitti: I've not tried out of this
<pitti> mvo: ^ fix your system :-)
<seb128> I had to restart gnome-volume-manager
<doko> lamont: no need to try the glibc build. it currently FTBFS
<Kamion> http://cdimage.ubuntu.com/daily/current/report.html
<seb128> it crashed some time after the update
<Kamion> ^-- hitlist
<seb128> with an useless bt ...
<pitti> seb128: yes, I did not yet port the reconnect patch
<pitti> seb128: such big patches are a PITA to port, but upstream simply does not accept patches
<seb128> not sure
<pitti> seb128: at some point gvm just needs to be rewritten from scratch...
<seb128> I would say 'upstream is not reactive'
<seb128> jdub, mdz: should I put sabayon on ship?
<Kamion> lamont: any reason lvm2's taking so long to build on powerpc?
<seb128> pitti: crappy design?
<lamont> doko: ok.  holler when then
<pitti> seb128: debian/patches is bigger than upstream source
<pitti> seb128: and yes, the code is a mess
<seb128> utch
<lamont> Kamion: because I'm a muppet???  given back. thanks
<Kamion> ta
<Kamion> it was in state Building so I wasn't sure
<luis_> tseng: BTW, any chance you'll build a muine-plugins package at some point?
<luis_> (now that the tray icon is a plugin, I'm desirous of the plugins :)
* mvo updated udev and hal love me a bit more now
<seb128> luis_: we have fixed the sabayon hang and some other issues and I've uploaded the package like 1 hour ago 
<luis_> seb128: rock!
<luis_> seb128: I will experiment with it within 24 hours; rest of today is sort of busy for me
<seb128> works fine here, but feedbacks are welcome when the package is available
<luis_> definitely
<seb128> k, thanks
<luis_> is there a tool to allow you to load settings yet? the webpage seems to suggest 'no'
<lamont> Kamion: worse yet - building with a log file... :-)
<Lathiat> can you make dupload upload a binary?
<wasabi_> so i was thinking more about my .apt file idea.
<Kamion> lamont: ?
<pitti> Lathiat: yes, it uploads everything that it is in the changes file
<wasabi_> this technically would work for rpm based distros too.
<wasabi_> which is pretty compelling.
<pitti> Lathiat: however, we don't do binary uploads in Ubuntu
<Kamion> mdz: could you remove little:cdimage/,,new-pristine* ?
<wasabi_> (people might use it)
<Lathiat> pitti: no
<Lathiat> pitti: but when uploading to my personal webspace
<Lathiat> i'd like to send the i386 build with the source
<lamont> Kamion: building-with-a-log ==> failed.  although in this case, it was a non-auto dep-wait
<pitti> Lathiat: build without -S (i. e. use the default), then this will be a source+binary build
<lamont> that I managed to delete/not receive, some how
<Lathiat> pitti: right
<Kamion> lamont: ah, ok
<Lathiat> thanks
<Kamion> breezy powerpc CD overflowed
<Kamion> by about 40MB
<mvo> pitti: thanks, hal+update-manager love each other again now
<lamont> Kamion: woot!
<pitti> mvo: rock
<jdub> Kamion: it's going to be even funnier when we start shifing goals into main :-)
<Kamion> CD 1 filled with 606583310 bytes ... (limit was 614046105)
<Kamion> that limit could be increased a bit though
<jdub> seb128: supported, methinks
<Kamion> jdub: I don't care about main, I care about ship. :)
<lamont> Kamion: at some point, shipseed is gonna have to take one for the team, though.
<jdub> Kamion: ship's getting bigger?
<Kamion> jdub: I never said it was
<lamont> doko: libggi is ICE
<jdub> Kamion: if you said it was, i wouldn't have asked...
<lamont> doko: er, that was libggi_1:2.0.5-1ubuntu2, since superseded
<Kamion> jdub: not to my knowledge
<jdub> Kamion: (my point being, goals are going to move into ship and desktop - that's going to be funny this release)
<lamont> doko: er, nm.  libgii != libggi.  libggi is ICE
<Kamion> jdub: we get to ditch languages then, fundamentally
<Kamion> though ppc64 kernel will help a bit
<seb128> luis_: I've documented the file format to load profiles, you have to edit that manually atm
<seb128> README.Debian has an example
<luis_> ah, great, thanks
<seb128> np
<seb128> jdub: can you modify the seed you feel right? the package name is "sabayon" ;)
<Lathiat> heh
<ogra> seb128, GettingRidOfTheDesktop ?? i thought that was a joke from your side : http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<seb128> ogra: that's a joke
<ogra> heh
<seb128> ogra: probably JaneW who doesn't know :)
<ogra> yes, thats what i thought
<JaneW> huh?
<JaneW> hehee
<seb128> JaneW: "GettingRidOfTheDesktop" is a joke based on "CommandLineDisintegration" aka "GettingRidOfTheCommandLine" from daniel :)
<JaneW> sorry some of those things I thought were inside jokes, but I was afraid of leaving off anything NB
<JaneW> *nod*
* JaneW remember s a meeting which was being scribed by a 100% non-technical person
<JaneW> we were trying to improve a big enterprise Windows product
<JaneW> someone chirped lets rewrite it in Unix
<JaneW> and it was minuted as an action
<JaneW> ;)
<ogra> heh
<seb128> rofl
<seb128> pitti: http://people.ubuntu.com/~seb128/dbus/
<seb128> pitti: I've a workaround for evolution, building atm
<mvo> pitti: new hal/dbus update-notifier: http://people.ubuntu.com/~mvo/update-notifier
<pitti> that's like Christmas...
<seb128> pitti: we are ready for upload so? :)
<pitti> seb128: no :-(
<seb128> why?
<pitti> seb128: let me test the crack before, and we still need to find a good hal transition
<pitti> seb128: you saw that bug
<seb128> yeah
<jdub> how on earth did keno make it into supported?
<jdub> er
<jdub> kino
<pitti> seb128: cool, with all those packages it looks like the update could actually work now
* pitti kisses apt
<pitti> seb128: damn, the update goes flawlessly, but nothing depends on dbus, so dbus does not get installed
<seb128> pitti: hal doesn't require dbus?
<pitti> seb128: something has to depend on dbus, for my sake that is hal
<seb128> agreed
<pitti> seb128: before, dbus-1 contained the library and the daemon, thus it was a shlibs-depend
<pitti> seb128: now libdbus-1-1 does not contain the daemon any more, so we need an explicit dependency
<pitti> hal makes sense
<seb128> right
<pitti> seb128: now I have to downgrade all of this stuff again *sigh*
<seb128> yep, let's poke the hal maintainer ;)
* seb128 pokes pitti 
<pitti> ouch
* pitti falls back onto hal and breaks it
<pitti> Hi astharot 
<astharot> ciao
<ogra> pitti, nooo
<pitti> astharot: 2:45 to go :-)
<astharot> ciao pitti
<astharot> 2:45 ?!?!
<astharot> are you crazy?
<pitti> hours
<astharot> it's 17:17
<pitti> oops, no
<pitti> 0:45
<astharot> 0:45
<astharot> !
<pitti> argh, already sooo late..
<astharot> hrehehe
<astharot> pvt
<astharot> query me
* ogra hands pitti named "special HalGlue"
<ogra> the tube ^
* pitti applies generously
<Mitario> re
<mvo> wb Mitario :)
<mdz> mvo: pong
<pitti> Morning mdz 
<lamont> Mithrandir: you around?
* lamont kicks fakeroot
<lamont> CC="gcc-3.4" kinda requires a build-dep on gcc-3.4
<zyga> thanks for fixing powernowd :-)
<pitti> seb128: hmm, so where are my shiny desktop and Computer place icons?
<pitti> seb128: so far I don't even see my CD-ROMs in Computer, do you?
<jordi> pitti: gtk bug
<pitti> jordi: of course
<seb128> pitti: my computer place has 1 floppy, 2 CD, 1 mounted partition and / which seems right 
<pitti> seb128: ah, I didn't restart my session after upgrade, i. e. the old g-vfs-daemon was probably running
<pitti> seb128: next time I try to relogin
<seb128> killall gnome-vfs-daemon nautilus 
<pitti> seb128: I'm currently downgrading again (I wrote a script for that ...)
<seb128> should do the trick
<seb128> k
<pitti> oh right, thanks
<mdz> Kamion: removed
<Kamion> mdz: which?
<mdz> Kamion: ,,new-pristine
<Kamion> oh right, thanks
<mdz> Kamion: I don't see any other requests from you for me to remove something
<Kamion> there weren't AFAIK, I'd just forgotten what I'd asked. :-)
<mdz> and good morning :-)
<thom> morning mdz
<mvo> good morning mdz 
<Nafallo> morning mdz :-)
<Kamion> good morning mr. zimmerman </chorus>
<Nafallo> *s*
<pitti> seb128, mvo: it's a hell of an upgrade, but it works!
<Kamion> I kept being freaked out this morning by reading repeated citations in a friend's PhD thesis of one "M. Zimmermann"
<seb128> pitti: why it's a hell?
<pitti> seb128, mvo: it's just the cosmetical error about that hal error message
<pitti> seb128: it removes, adds, shifts packages all over the place
<pitti> seb128: but apt figures it out
<seb128> k, fine
<seb128> I'm away for ~1h
<pitti> and I get shiny icons :-)
<pitti> seb128: we should upload tomorrow morning, when daniels is here
<seb128> you can start with dbus/hal, I'll follow
<pitti> mvo: ^ 
<seb128> k
* pitti looks for daniel's changes files
<pitti> seb128: oh, there is a signed changes
<mvo> mdz: I have two small patches in apt--mvo--0 for review and merge. I also would like to upload a new version into debian/experimental (can I /msg you about it)?
<mvo> pitti: k
<pitti> seb128: so in theory we could upload
<mvo> pitti: what time (roughly)?
<seb128> pitti: there is no hurry, do what you feel right :)
<pitti> mvo: it's not that important, apt will hold back updates which break things
<mdz> mvo: ok
<mdz> mvo: (or #d-d)
* seb128 bbl
<willis> what timezone are the build computers in?
<Kamion> willis: London time
<thom> gmt+1
<willis> Kamion, oh cool thanks, that's where i am, makes it easy
<lamont> elmo: please migrate libopts25 and libopts25-dev to main, so that autogen can install, and gcc-4.0 will build.  kthxbye
<elmo> done
* lamont kicks gcc-4.0
* ogra joins lamont and kicks mono on amd64
<pitti> ogra: but lamont's kick was probably a give-back :-)
<Lathiat> haha
<ogra> pitti, mine was a real hard kick.... my foot hurts :)
<pitti> ogra: how can you hard-kick software?
<pitti> ogra: I thought the very definition of software was that kicking it doesn't hurt?
<Lathiat> hmm interesting bug in epiphany
<Lathiat> on ubuntu wiki edit
<Lathiat> the text in the editbox is off about 2 characters to the left of the outline
<Lathiat> so is the scrollbar
<ogra> pitti, depends how hard you kick it...
<ogra> pitti, but i suspect i'll only deform it further.... it wont bring me the missing binarys
<lamont> ogra: just remember, mono is a disease that is very tiresome, and hard to get over.
<lamont> requires much bedrest
<ogra> hmm.... then i'm probably the wrong person for it :)
<lamont> heh
<lamont> mono == mononucleosis
<ogra> heh
<ogra> i'm alredy getting dizzy by all these dll's
<lamont> hrm... gcc-4.0 pingpong.
* lamont waits for cron.daily to run
<dilinger> hm.  malone didn't like that bug followup
<jordi> jordi@nubol:~/cvs/gnome/2.10/gnome-mud$ make dist
<jordi> make: *** No rule to make target `intltool-modules/XML/Parser/Style/OrigTree.pm', needed by `distdir'.  Stop.
<jordi> does anyone know what this is about?
<pitti> trulux: here?
<pitti> trulux: if so, please join the CC to apply for membership
<hunger> Who fixed powernowd?
<dholbach> zmore /usr/share/doc/powernowd/changelog.Debian.gz
<Nafallo> Baby: hi :-)
<hunger> Could someone apply the patch attached to bug #10457 to powernowd's init-script, please?
<Baby> hi Nafallo!! :)
<hunger> thom: You got that bug assigned to:-)
<trulux> pitti: just came back from class, sure
<lamont> seb128: sabayon missing build-deps
<lamont> specifically libxml-parser-perl
<seb128> lamont: k
<Nafallo> jdub: u-c-april isn't in breezy?
* mvo goes to play some hockey now
<mxpxpod> how would I get hotplug to overwrite the configs I have in /etc when installing it?
<tim_> anyone know if there is a e17-ubuntu in the works? I saw a mention that there was talk of it in an interview with mark shuttleworth (think thta was the name)....sry if this isn't the right channel to ask
<seb128> is there a e17?
<tim_> its still in development
<tim_> but i'm using it....and its damn sexy
<dredg> seb128: due out after duke nukem forever
<tim_> i've been using it for a few months now, development goes at a pretty incredible rate and its pretty stable, i have yet to have it crash on me
<ogra> tim_, put it on the UniverseCandidates wiki page... if soeone wants to package i he will grab it there
* ogra grrs at his keyboard
<ogra> if someone wants to package it he will grab it there
<mxpxpod> or, actually, how would I get dpkg to ask me if I want to overwrite the /etc stuff when I install hotplug?
<cartman> anyone investigating tar failures on all arches? Looks like a gcc4 problem
<tim_> ogra, should I put it there if its still in heavy development? It would require that it be maintained and updated rather frequently
<Kamion> mxpxpod: look at dpkg's --force-conf{new,old,def,miss} options in dpkg --force-help
<ogra> tim_, then we could have a snapsot in universe or something
<tim_> ogra, alrighty cool...thx for the help :)
<mxpxpod> Kamion: also, how do I download the .debs using apt-get if I already have the newest version of hotplug?
<dredg> apt-get install hotplug=version.number
<Mithrandir> seb128: pong
<Mithrandir> lamont: pong
<seb128> Mithrandir: about the pkg-config issue we spoke some days ago
* lamont tries to remember what he was going to pester Mithrandir about.
<seb128> Mithrandir: that's ftbfsing some GNOME stuff which is getting annoying
<tseng|work> ogra: whats up
<Mithrandir> seb128: yeah, sorry I haven't fixed it.  I'll look at it on my flight in about 30 minutes.
<Amaranth> hey, what's this notification thing i got after booting with 2.6.12?
<seb128> Mithrandir: k, thanks. If you don't have time to fix maybe you could consider changing back pkg-config time to figure what's wrong?
<ogra> tseng|work, trulux was looking for sponsors in the CC meeting, i thought you could say something about his work... but its over now
<Mithrandir> seb128: yeah, but I'm rather going to fix it the right way around. :)
<mxpxpod> Kamion: hmm, --force-confdef didn't prompt me
<seb128> cool
<Kamion> mxpxpod: "force dpkg to accept defaults" - so no, it won't
<mxpxpod> Kamion: do I have to have a debconf option set for it to say "There's a different config file... what would you like to do?"
<Kamion> dpkg does not use debconf
<Kamion> I don't believe you can force it to give you the conflict resolution dialog for every file (even if there's no conflict)
<mxpxpod> hmm
<Kamion> but the --force-conf* options are usually sufficient to fix up problems
<mxpxpod> well, hotplug takes forever to start up during boot, and on my brother's i386 machine it flies
<Kamion> --force-confnew is probably the biggest hammer
<mxpxpod> will it save files that conflict with the .dpkg-old extension?
<Kamion> I'd have to check the source. I believe so, but take a backup if you're worried
<seb128> elmo: glabels sync please
<elmo> seb128: done
<seb128> thanks
<Mirv> regarding the yesterday's breezy kickoff, was there any discussion about input methods for various languages?
<jbailey> Mirv: Nope.
<jbailey> Basically the bofs from UDU were split into high, medium, and low priority.
<Mirv> jbailey: are there any ubuntu people looking into eg. freedesktop's scim/uim etc.?
<jbailey> Mirv: We got through the high and medium priorities.
<Mirv> jbailey: ok
<jbailey> Mirv: Your best bet is to do a search of udu.wiki.ubuntu.com
<jbailey> Mirv: If you can find a spec there, there's probably some people interested in it.
<jbailey> Mirv: If not, you can try creating a spec, but it may be hard to get resources for it for breezy - the amount that everyone is trying to get done for Breezy is a bit staggering. =)
<Mirv> jbailey: will do, would be logical to be on ubuntu's "in all languages" roadmap
<mxpxpod> hrmmm
<mxpxpod> strange.... hotplug still takes forever to start up
<Kamion> mxpxpod: do you have grepmap installed?
<Mirv> jbailey: yes, I gather :) will have to see about it, my employer is also interested in these things and I might even have work time devoted to ubuntu at some point
<mxpxpod> Kamion: no
<Kamion> mxpxpod: rectify that. :-)
<wasabi_> jbailey, does Java have a schedule other than "as soon as wasabi does it?"
<mxpxpod> Kamion: I'm guessing that will help?
<jbailey> wasabi_: What we talked about in the bof was that it needed to wait until the C++ transition was done so that all of gcj/gij lined up right.
<wasabi_> k
<Kamion> mxpxpod: grepmap's purpose in life is to speed up hotplug
<mxpxpod> oooh
<wasabi_> I'm cool with that. I'm barely moving on it... but trying to push the important things into Debian.
<jbailey> wasabi_: Are you aiming for Sarge?
<wasabi_> Ha.
<mxpxpod> Kamion: ooooooh!! much better!!
<jbailey> wasabi_: Okay.  I was beginning to think that you were nuts. =)
<wasabi_> I could care less about sarge at this point.
<wasabi_> couldn't?
<Kamion> mxpxpod: good good. it should've been installed by default, unless you were upgrading from very old pre-warty ...
<mxpxpod> Kamion: that's what I did
<mxpxpod> Kamion: ubuntu-desktop should depend on it, though
<Kamion> "couldn't care less", ignoring the Americanism :-)
<wasabi_> jbailey, I posted a patch to debian-java for java-common for the wrapper script jvm selection idea.
<wasabi_> So we'll benefit from that automatically.
<Kamion> mxpxpod: ubuntu-base depends on it
<Kamion> ubuntu-minimal in breezy
<mxpxpod> whoa
<mxpxpod> what's evms, ethtool, and lvm?
<jbailey> wasabi_: Nice.
<wasabi_> evms and lvm are godly. that's all i know.
<jbailey> wasabi_: Andres did some amazing magic on cdbs2 through udu.
<jbailey> wasabi_: It might be interesting to take a detour and make sure that it's up to speed for the Java stuff.
<Kamion> evms/lvm => advanced/less-advanced logical volume management stuff. ethtool => figure out whether network interfaces are active.
<wasabi_> I haven't even looked at it.
<mxpxpod> ah, ok
<mxpxpod> thanks Kamion 
<wasabi_> lvm isn't exactly less advanced than evms. ;)
<wasabi_> In fact, the best use of both is together. ;)
<jbailey> wasabi_: Right, I'm just thinking of a way to lower packaging costs.
<Kamion> wasabi_: mm, couldn't think of a better way to describe the distinction :)
<Kamion> evms is the mad weird shit. :-)
<jbailey> Mirv: That's cool if you can devote paid time.  My last job was like that, where I was allowed to work on Debian.  
<wasabi_> Actually I think evms built in stuff is sucky.
<Kamion> at least if you look at evmsgui ...
<wasabi_> But using the EVMS object model to admin md + LVM is unbelievable.
<wasabi_> The gui needs work.
<jbailey> Kamion: I was loving evmsgui up until the moment it ate my partition table.  ah well.
<wasabi_> But, it's really slick.
<Lathiat> jbailey: heheh
<Kamion> the GUI is incomprehensible :)
<mxpxpod> which package sets up /etc/network/interfaces?
<Kamion> mxpxpod: netcfg does it in the installer
<jbailey> Kamion: With the gui I setup my first lvm volumes.  I hadn't managed to work my way through d-i enough to do it.
<mxpxpod> Kamion: ah, ok
<mxpxpod> alright, thanks for the help! gotta get back to work
<jbailey> sladen: You 'dere?
<sladen> jbailey: I'm here
<jbailey> sladen: Hey - was just looking over the intergrated Lights Out (iLO) stuff for HP Proliant servers, and wondering how bootsplash would wind up interacting with it.
<jbailey> sladen: I know that youtalked about serial console, but I don't know if iLO came up at all.
<dilinger> i'm curious how the iLO stuff works
<sladen> jbailey: 
<jbailey> dilinger: 
<jbailey> bah
<sladen> dilinger: video card with a network port on it
<Treenaks> what is iLO 
<jbailey> dilinger: I can probably get access to a system with iLO for testing when I'm back home.
<Treenaks> ah ok
<sladen> jbailey: I have them in some of my boxes as a last resort reboot.  They also allow access to the BIOS 
<dilinger> sladen: so it contains an onboard tcp stack and some type of daemon that you connect to and get something like serial output?
<sladen> dilinger: yup, it's a telnet interface
<sladen> expose of utter lack of security here: http://www.paul.sladen.org/lights-out/riloe.html
<sladen> jbailey: mmm.  really for anyone using serial BIOS / lights-out you want to come up in a text-mode
<dholbach> jdub: ping
<sladen> jbailey: otherwise it has to start spitting bitmaps back if the card goes into a graphics mode (and they don't work too well in that mode)
<mdz> fabbione: 2.6.11.92-1.1 works on my laptop
<jbailey> sladen: Right.  I'm guessing that you can probably detect a serial port in use.  I was curious if you could detect iLO in use.
<sladen> jbailey: nope.  It's a "normal" PCI video card
<jbailey> Ugh
<sladen> jbailey: I did ping bdale a couple of years ago about whether there might be specs around.  His reason seemed to be that HP designed their own stuff but Compaq outsourced everything so that chances of tracking stuff down was slim
<sladen> jbailey: in fact, even has a S3 Virge chip on it
<sladen> it would be good to handle serial-bios installations out-of-the-box.
<jbailey> Probably no way to detect it at that point, though.
<sladen> they tend to run with a serial-redirect up until the point the OS gets loaded and then you have to pass grub/kernel the normal console= magic if you want to see anything after that point
<jbailey> Ah?  Hmm
<sladen> jbailey: I'd suggest just not enabling it on server installs.  
<luis_> seb128: ?
<seb128> luis_: what?
<sladen> jbailey: graphic foo, that is.  The domain of those wanting iLO/serial and the domain of those not wanting X installed probably overlap fairly well
<luis_> seb128: no README.debian in /usr/share/doc/sabayon/
<seb128> arg
<jbailey> sladen: I'm not convinced of that overlap from talking to the NT admins I know who are scared of moving to a text based system.
<wasabi_> i heard NT!
<sladen> jbailey: oh.  great, MSCE compatibility mode
<dilinger> sladen: neat.  my sunfire 280 has some modem stuff on it that's supposed to allow you to dial up into the machine when it's powered off, but i've never played w/ it
<dilinger> batteries on the card, too
<wasabi_> my dell's have those too.
<wasabi_> pretty nifty
<sladen> dilinger: LOM.
<jbailey> sladen: No, these are generally companies that are too cheap to hire an MCSE and insist on just maintaining their systems themselves, since it's almost (but not quite) easy enough.
<sladen> wasabi_: the dell offerings pale in comparision to the real Sun LOM+PROM
<dilinger> yep
<jbailey> sladen: The upshot to that is that as an IT consultant I generally made alot of money off of those clients. =)
<jbailey> sladen: Amazing just how badly they can screw up a system...
<sladen> jbailey: I charge people 3x if I find they used 'su' or 'sudo su' at any point
<jbailey> sladen: Part of my dream is for SELinux/LDAP systems where a user can have the rights to create and delete user accounts and touch nothing else.  But we'd be bankrupting IT consultants all over the world at the same time. =)
<dilinger> hah
<Treenaks> jbailey: your point being? :)
<dilinger> java?
<dilinger> they use java?
<wasabi_> jbailey, what's special about that?
<jbailey> Treenaks: Our biggest supporters will not be the ones who will find themselves out of work after implementing Linux. =)
<jbailey> Treenaks: We shouldn't go out of our way to cripple systems, but it's something I generally have in mind.
<jbailey> Treenaks: I know a couple consultants who resist implenting Linux for that reason.  It's only now where customers are demanding it that they're putting the systems in.
<jbailey> Treenaks: Windows on the desktop tends to keep them in business though.
<Kamion> sladen: I'm hesitant to have server installs diverge from normal ones beyond purely package selection
<wasabi_> I find that windows tco on the server is actually lower for me. =)
<Kamion> sladen: we could avoid installing the usplash package on server installations, though
<Kamion> sladen: (although it's fiddly)
<jbailey> Kamion: If you're disabling bootsplash, X should really not start either.  It's the same problem in both cases.
<dilinger> jbailey: what?!  how are you supposed to admin a server w/out point and click?
<dilinger> :)
<wasabi_> WIth remote point + click.
<wasabi_> =)
<Kamion> jbailey: actually, maybe it's not so fiddly, we probably don't want usplash there on first boot - so just put it in desktop
<sladen> wasabi_: if you're finding TCO cheaper elsewhere, that sounds like a bug!  What can we do to solve that situation?  :-)
<wasabi_> sladen, exactly my viewpoint.
<sladen> Kamion: rememeber this all gets a pain to do with initrd and shipping pre-built ones
<wasabi_> Ubuntu is really knocking down the things I've found time consuming about linux one after another though.
<Kamion> sladen: meh
<wasabi_> sladen, http://www.ubuntulinux.org/wiki/DomainAuthenticationUtility
<Kamion> sladen: I am going to have SCREAMING NIGHTMARES if server initrd != normal initrd. I think usplash will have to be able to disable itself in some circumstances.
<sladen> wasabi_: what's next on the hit list and is it on ...  groovy, excellent
<Kamion> can it just look for the 'splash' boot option?
<dilinger> Kamion: hopefully they'll be initramfs's ;)
<Kamion> dilinger: even so :)
<jbailey> Kamion: The idea is a modular initrd.  usplash should just lie down on one of the hooks.
<jbailey> Kamion: It's not crazier than if evms/lvm/busybox gets tossed in.
<wasabi_> I am really fond of launchd (i realize the license stuff, what I mean is I like the design)
<sladen> Kamion: kernel commandline is the approach I'm most happy with
<sladen> jbailey: how much work would it be to get grub loading the concatrenated cpio's for initramfs?
<jbailey> Kamion: If it's part of ubuntu-desktop, it just wouldn't get installed on a server setting.  Add desktop later, and next initrd assembly would include it.
<jbailey> sladen: dilinger guessed less than an hour's work, but the degenerate case still needs to be supported for people running other grubs, (dual boot), or non-ia32
<Kamion> jbailey: that would imply regenerating the initrd at the end of the desktop install
<jbailey> Kamion: For it to be deterministic, yeah.
<jbailey> Kamion: Otherwise the behaviour would randomly change with the next kernel update.
<jbailey> Hmm. or.
<Kamion> needs to be in its final state at the end of the installation
<jbailey> I phear the idea of 'reassemble the currently running initrd'
<jbailey> Well, I was thinking that if a script existed that just said 'reassemble the initrd', usplash could call it in postinst.
<jbailey> And anything touching the initrd could do that.
<sladen> jb	that would be soo, soo, soo, good
<jbailey> sladen: Except the idea of breaking the currently bootable system.
<sladen> er yes.
<sladen> this is where the idea of system-wide rollback would be really good
<stockh0lm> elmo: ?
<jbailey> Hard to do if 6 things touch the initrd in an upgrade cycle.
<jbailey> Or do you just mean a general known working snapshot?
<sladen> jbailey: I quite fancy the idea of always keeping about a 'rescue' kernel and initrd
<sladen> jbailey: and that's the initrd that should probably include busybox et al
<dholbach> good night everyone
<Nafallo> dholbach: night :-)
<sladen> jbailey: and roll any future 'rescue' mode functionality from the livecd into that initrd so that the user has a sort of abstracted recovery console that can cope with any situation except a toasted MBR
<jbailey> Hmm, I also wonder if there's a way of reasonably looking for a rescue keyword and having some things that go into initramfs saying clearly 'don't run me in rescue mode'.  usplash seems a likely candidate there.
<jbailey> I'm not sure there are enough others to be worth it.
<Kamion> sladen: difficult to manage
<Kamion> (automatically)
<jbailey> There just shouldn't be that much fluff in the initramfs where you wouldn't just want to break to a console as soon as you can and do it by hand.
<Kamion> it's so much better when the installer sets the whole thing up and then you don't have to touch it until an upgrade
<sladen> jbailey: there's the 'alternate' and 'normal' boot lines in the grub/menu.lst.  splash and the console=XXX will only be in the 'normal' line and not in the alternate/recovery one
<sladen> jbailey: haven't looked at the yaboot case
<sladen> NeedAPowerPC
<Kamion> we don't set up a recovery option for yaboot at the moment, and its UI makes it kind of unpleasant to do so
<ozamosi> How do I contact persons who are involved in projects decidet at UDU?
<Amaranth> ozamosi: They should be listed as a first or second on the spec, go to their pages on the wiki
<sladen> ozamosi: typ e their name followed by a colon ';:' ;-)
<ozamosi> Amaranth, um.. yes. But what if there are no emails or anything?
<Amaranth> Then someone didn't do their job...
<Amaranth> Who are you looking for?
<ozamosi> Colin Applegate
<ozamosi> or really anybody involved in the lightdesktop-project
<Amaranth> GetRidOfTheDesktop? :)
<jammcq> ozamosi: do you mean the Thin client stuff?
<ozamosi> No, the lightweight-desktop
* jammcq doesn't remember seeing that one at udu
<Amaranth> would anyone get mad if i started to file bug reports on apps whose dialogs don't center on parent? :)
<ozamosi> whoever made that beagle-package should make it depend on mono...
<luis_> ozamosi: poke tseng
<mdz> Riddell: ping
<Riddell> mdz: hi
<Nafallo> zul: ping?
<zul> Nafallo: ping
<zul> doh..pong
<Nafallo> zul: heh :-)
<Nafallo> zul: it's rt2500 and rt2400 now? :-)
<zul> yep
<zul> from cvs
<Nafallo> zul: damn! I just install the kernel-headers ;-). thanx anyway, and... I love ya! :-D
<zul> thanks
<lewiz> Can anybody tell me what version of inotify the kernel in breezy uses?
<zul> 0.23
<lewiz> Great.
<Nafallo> zul: time for reboot then... see you soon hopefully :-).
<Nafallo> yay! I don't need to compile drivers anymore :-)
<zul> cool
<Nafallo> zul: swsusp error in the beginning though.
<zul> its a 2.6.12rc4 kernel
<Nafallo> zul: I'm not supposed to have resume= on the kernel command line?
<Nafallo> ahh, oki
<zul> Nafallo: not sure i dont have a laptop
<Nafallo> zul: oki. jbailey's stuff, right? :-)
<kent> Nafallo, how are things in Breezy-world?  :)
<jbailey> Nafallo: What's that?
<Nafallo> jbailey: shall I remove resume= from my kernel command lines? running breezy now.
<Nafallo> kent: unbelievable :-)
<Nafallo> kent: firefox has better font and the new kernel has my wlan driver :-).
<Nafallo> jbailey: I get an error about swsusp while booting. I don't hibernate often ;-).
<kent> Nafallo, did you run into any problems while upgrading?
<Nafallo> kent: nope, not that I can remember. i.e. if their were, they were really small ;)
<ajmitch_> hi all
<pitti> Hey ajmitch_ 
#ubuntu-devel 2005-05-19
<doko> jbailey: did you have a chance to look at the glibc build failure?
<jbailey> doko: I haven't.  I'm going to try to setup a chroot here later to see if I can figure out if gcc's being called with something weird.
<jbailey> (or if it is, in fact, missing unwind support for some reason)
<doko> jbailey: ok, I'm going to ignore this issue for now, I will just build no biarch compilers until this problem is solved
<jbailey> doko: BTW, did you remove the biarch compiler from amd64 too?
<doko> no, should I?
<jbailey> No, lamont just asked me about a problem building the biarch glibc on amd64, I wondered if you had removed it.
<jbailey> If you had, it would've saved me digging out a config.log for that too.
<lamont> jbailey: fakeroot
<lamont> or is that fakeroot's build trying to use the gcc-4.0 biarch glibc and failing?
<jbailey> Oh, I get it.
<jbailey> I thought you were building glibc. =)
<mx|gone> jbailey: did you see kamion's message to me earlier about hotplug running slow?
<jbailey> gimme a sec, hopefully I can check that one quickly.
<jbailey> mx|gone: The one where he told you to install grepmap?
<mxpxpod> jbailey: yeah
<jbailey> mxpxpod: Nope. =)
* jbailey hides.
<mxpxpod> jbailey: :P
* mxpxpod finds jbailey and smacks him
<mxpxpod> anyway, just making sure you saw that so you can install it on your i386 laptop
<mxpxpod> gotta get home to the wife
<mxpxpod> talk to you later
<mdz> grepmap has been part of the standard install for ages
<Nafallo> ehm, tomboy want me to install -dev. should it do that?
<jdub> Nafallo: yeah
<jbailey> mdz: It's probably folks moving from Debian to Ubuntu who didn't install ubuntu-base
<Nafallo> jdub: oki. btw, I didn't thought I was in this channel ;-). morning to you :-).
<tseng> Nafallo: buh?
<tseng> did ogra add -dev stuff
<jdub> tseng: yeah - stuck with it for some things
<Nafallo> tseng: must be tomboys deps that deps...
<ogra> tseng, nope...
<Nafallo> libdbus-cil deps dbus-glib-1-dev for example...
<Nafallo> I commented to quick. it's all dbus stuff that deps.
<ogra> ogra@honk:~/tomboy-0.3.2 $ apt-cache depends tomboy
<ogra> tomboy
<ogra>   Hngt ab: libdbus-cil
<ogra>   Hngt ab: libgnome-cil
<ogra>   Hngt ab: libglib-cil
<ogra>   Hngt ab: libgtk-cil
<ogra> yep
* robertj comes in crying after reading planet.gnome
<robertj> " I was planning on broadcasting available shared backgrounds through the Zeroconf protocol so that other people could view them and subscribe to my background images"
<robertj> bwahaha
<ogra> WTF
<ogra> # monodis - temporary wrapper script for .libs/monodis
<ogra> # Generated by ltmain.sh - GNU libtool 1.5.2 (1.1220.2.60 2004/01/25 12:25:08)
<ogra> #
<ogra> # The monodis program cannot be directly executed until all the libtool
<ogra> # libraries that it depends on are installed.
<ogra> #
<ogra> # This wrapper script should never be moved out of the build directory.
<ogra> # If it is, it will not operate correctly.
<ogra> how the hell did that end up in the package.... in /usr/bin
<ogra> tseng ^^^^^^^^^
<tseng> it was used in dh_netdeps
<tseng> and worked fine
<ogra> but thats a build wrapper if i get it right
<tseng> oh uh
<tseng> wow
<ogra> so instead of the actual binary the build wrapper is istalled in the package...
<tseng> yes
<tseng> do you see the binary?
<ogra> nope
<ogra> its nonexistent
<jdub> *blink*
* ajmitch_ waits for mono source to download
<ogra> aha
<ogra> found it in the build tree...
<tseng> yeah
<ogra> so it gets built but the wrapper is never run
<ogra> or better... is broken somewhere internally
<ogra> HA 
<ogra> !
<ogra> -lpthread 
<tseng> does this wrapper even matter outside the build tree?
<ogra> there it is...
<ogra> its for relinking... 
<tseng> and failts on amd on pthread?
<ogra> i would guess so
<tseng> i have the wrapper installed also
<tseng> something is more wrong than that
<ogra> hmm
<tseng> the wrong thing is being installed in any case
<tseng> mono-utils.install:debian/tmp/usr/bin/monodis
<ogra> hmm
<tseng> rules:	dh_install -i -Xbin/mono -Xbin/monodiet -Xbin/monodis -Xbin/monograph -Xbin/pedump -Xbin/jay
<tseng> why both?
<ogra> good question
<ogra> i didnt add that
<tseng> its from meebey
<tseng> bbiaf im doing a build
<tseng> to look at the finished tree
<tseng> so
<tseng> brandon@lappy:~/work/debian/mono-1.1.7$ file ./mono/dis/monodis
<tseng> ./mono/dis/monodis: Bourne shell script text executable
<tseng> brandon@lappy:~/work/debian/mono-1.1.7$ file ./mono/dis/.libs/monodis
<tseng> ./mono/dis/.libs/monodis: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped
<tseng> brandon@lappy:~/work/debian/mono-1.1.7$ mono/dis/.libs/monodis  --version
<tseng> monodis -- Mono Common Intermediate Language Dissassembler
<tseng> we need to install that instead
<tseng> i wonder at what point the other one gets to /usr/bin
<ogra> i'm just doing a testbuild
<ajmitch_> it's usual for libtool scripts to be around, but not after a make install
<ajmitch_> still compiling here..
<daniels> tseng: right -- debian/tmp/usr/bin/monodis should be fine
<daniels> mono/dis/monodis is not what you want; libtool should DTRT in this case
<daniels> mono/dis/monodis exists so libtool can set up the right paths and stuff so you can run it in-tree
<tseng> yes
<tseng> but that file is winding up in /usr/bin
<tseng> and installed in lieu of the real deal
<tseng> mono/dis/Makefile is a bit fishy I think
<daniels> so debian/tmp/usr/bin/monodis is just the script?
<tseng> yes
<daniels> wack
<tseng> totally
<ogra> the binary is in /usr/bin/.libs/monodis
<daniels> if you put the Makefile.am up somewhere, I can check it out
<ogra> err mono/dis/.libs/monodis
<tseng> http://tseng.ath.cx/Makefile.am is mono/dis/Makefile.am
<tseng> bin_PROGRAMS = monodis < doesnt smell right to me
<tseng> since im assuming that goes with the one in cwd
<tseng> with no reference to .libs
<daniels> actually, that one's fine
<daniels> probably a busted autotools setup when all the files were generated
<tseng> buh
<tseng> do we want to just do a mono-utils.install bit?
<tseng> rm it in rules
<ogra> sounds saner
<tseng> install the right one in .install
<tseng> wtf not :P
<ogra> i think the libtool script has a meaning... :P
<tseng> in the build process
<tseng> not in the deb
<ogra> but as a quick workaround ...
<tseng> ok ill go to dinner, and if you dont come up with something else
<tseng> ill do it like I said
<tseng> cya soon :)
<ogra> ok... its nearly 2am here... i think i'll leave it to you for now :)
<tseng> k, rock on
<ogra> yeah
<jdub> zounds! 2.6.12! :-)
<crimsun> thankfully there won't be l-r-m, and it's in universe! ;)
<daniels> tseng: bin_PROGRAMS should install the right thing to $(bindir)/foo
<daniels> if it doesn't, that's a bug
<tseng> yeah dude but the program isnt in the directory
<tseng> its below it in .libs
<daniels> try running autoreconf -v --install --force with a halfway sane build environment (sensible versions of automake and libtool, recommend 1.8 and 5.r respectively)
<daniels> sure, so that's a problem with the build env :)
* jdub reboots laptop to 2.6.12
<Amaranth> hey, what's this new notification thing?
<Amaranth> i got it when i upgraded to 2.6.12
<tseng> the what now?
<Amaranth> is it a replacement for sending emails to root?
<jdub> yes
<Amaranth> neat
<Amaranth> does it require extra code or does sending an email to root@localhost do it?
<lamont> off to fire training, back in ~4 hours
<tseng> daniels: eh, the binary is in the same place
<daniels> tseng: hm?
<tseng> monodis
<tseng> after retooling
<tseng> still wrong
<daniels> blegh
<daniels> bug Keybuk when he comes back around
<tseng> might try BenM
<jcole> hey guys, i've been using debian for a few years and have had "deb http://snapshot.debian.net/archive pool gcm" (gnome clipboard manager, similar to klipper) in my sources.list forever with no problems whatsoever... it also works fine in ubuntu warty/hoary/breezy... try it out (apt-get install gcm) and tell me what you think
<tseng> please put it on UniverseCandidates page on the wiki
<jcole> i think debian didn't like the way it was designed since it didn't hook into X, but hell, it works
<jcole> tseng: ok
<ajmitch_> it was removed from debian at some point?
<jcole> ajmitch_: ya, because it "polled" the clipboard instead of "hooking" into it
<jcole> ajmitch_: what's funny is klipper does the same
* ajmitch_ finds the removal request
<tritium> gcm is listed here: http://www.ubuntulinux.org/wiki/DesktopSeedProposals
<jcole> tritium: great!
<tritium> jcole, yeah, I just remembered having seen it there, but I'd still do as tseng says :)
<jcole> tritium: ok
<tseng> it cant much be in desktop if we dont even have a package
<jblack> Hiya. Any motus present? 
<mdz> jblack: perhaps try #ubuntu-motu
<jblack> (grin) Seems that there's a lot of #ubuntus, and I'm always in the wrong one. :) 
<jsgotangco> morning!
<ajmitch_> hey jerome
<jsgotangco> hey
<bluefoxicy> http://rafb.net/paste/results/a7pdC914.html
<Lathiat> man, #Ubuntu is such a time suck.
<bob2> yes
<bluefoxicy> i want something visually like the above
<bluefoxicy> in fact I started writing it and my head exploded because I had about a billion security concerns, though I'm quickly figuring out the basics
<Lathiat> bob2: sigh, it just pisses me off all the bad advice that floats around and i end up in there for hours, heh.
<bob2> I know the feeling
<Lathiat> i need to augment the faq
<bob2> the clueless leading the...
<Lathiat> and then keep a list of URLs for common questions
<Lathiat> sick of typing out instructions for shit like adding unvierse
<Lathiat> universe
<ajmitch_> afternoon
<bob2> aloha
<ajmitch_> Lathiat: so long as you don't encourge b*ckp*rts
<ajmitch_> bob2: how goes the pit?
<Lathiat> ajmitch_: heh
<Lathiat> b*ckp*rts and ubuntug*u*de are teh sux
<bob2> ajmitch_: we prefer to call it "canberra"!
<bob2> ajmitch_: but it's getting cold
<Lathiat> heh canberra
<Lathiat> was there a few weeks ago
<bob2> ajmitch_: how goes ye olde nz?
<ajmitch_> colder than canberra
<bob2> Lathiat: I hear we had some sort of linux conference here??
<ajmitch_> and nearly as boring
<bob2> harsh!
<jsgotangco> nz is boring?
<Lathiat> bob2: yeh :)
* jsgotangco used to consider moving to nz a few years ago
<ajmitch_> dunedin isn't too bad when there's students around
<jsgotangco> i guess otago u can be boring during the vacation
<ajmitch_> yep
<Lathiat> blah
<Lathiat> ubuntulinux.org/wiki/RestrictedFormats lists backports
<Lathiat> well, its extras
<Lathiat> close enough
<ajmitch_> yes, that was changed only a couple of days ago..
<Lathiat> ugh
<Lathiat> now i dont have the urls for the other crap to give someone
* Lathiat stabs backports
<jsgotangco> anyone familiar how yelp works with scrollkeeper?
<Lathiat> ugh, someone pay me to sit in #ubuntu all day so i can not stop
<jsgotangco> heh
<Burgundavia> Lathiat, hoary-extras is better than marilliat, trust me
<bob2> where's pitti when I want to whinge about about g-v-m not working
<Lathiat> hiding
<zul> er...asleep maybe
<Lathiat> synaptic could really do witha  roll-back option
<bob2> not possible
<lifeless> bob2: erm. possible. not trivial
<jdub> Lathiat: or, even better:
<jdub> http://people.ubuntu.com/~jdub/screenshots/synaptic-remove-all-packages-dialogue.jpg
<Lathiat> hahaha
<bob2> lifeless: wellm not within synaptic
<Lathiat> well, more to the point
<Lathiat> you install some packages
<Lathiat> that install stuff
<Lathiat> be nice to be able to uninstall stuff and the shit it pulled in
<fabbione> morning
<lu|away> jdub: best dialog ever
<bob2> the en_AU translation team needs to get on to synaptic
<mdz> bob2: aren't you the en_AU translation team?
<bob2> not since the bazaar incident.
<Lathiat> Burgundavia: hoary-extras is not better than marillat
<Lathiat> their media stuff doesnt even work
* Lathiat sigh
<jsgotangco> is that so
<jsgotangco> hmm
<fabbione> doko: gcc-3.4 is still FTBFS on sparc. same libvtest3 error as last time
<dholbach> morning
<jsgotangco> dholbach, hey
<dholbach> hey jsgotangco 
<dholbach> good morning, JaneW 
<JaneW> morning dholbach 
* JaneW goes to get coffee while mail d/ls
* ajmitch_ returns
<pitti> morning
<KaiL_> early one
<mdz> pitti: morning
<pitti> Dc mef
<fabbione> hey pitti
<pitti> Hi mdz
<fabbione> hey mdz
<dholbach> morning pitti, mdz, fabbione :-)
<fabbione> hi dholbach 
<daniels> morning *
* pitti swapped Dvorak and Qwertz...
<fabbione> hey dani
<dholbach> hey daniels :-)
* fabbione keeps fighting with ext3 resize
<daniels> mdz: you're UTC-7 now?
<pitti> daniels!
<mdz> daniels: yes
<daniels> pitti: yo dude :)
<pitti> daniels: yesterday we collected all the bits and pieces for the Utopia transition
<daniels> mdz: is that with or without daylight savings?
<pitti> daniels: it's a bumpy upgrade, and we still have this (rather cosmetical) hal error, but it generally works
<daniels> pitti: awesome!  so are you only waiting on dbus?
<daniels> pitti: well, that's what breezy's for
<pitti> daniels: actually yes
<daniels> if anyone's actually using it, serves them right
<KaiL_> fabbione: who needs partitions? 1 disk, 1 filesystem ;)
<pitti> daniels: after you upload, I do pmount/gvm/hal, and seb does the gnomeish things
<pitti> daniels: mvo prepared a new update-notifier
<daniels> pitti: ok, I'll prepare 0.33-0ubuntu1 without mono and we'll go fromthere
<daniels> cool
<daniels> pitti: i'll just go grab a drink, 'cause my uplink is saturated; give it about half an hour?
<pitti> daniels: oh, wasn't there already a -cil?
<pitti> daniels: of course, no hurry. 
<daniels> pitti: yeah, but mono's in universe still
<pitti> ah, right
<pitti> thom: here?
<fabbione> mdz: InstallerVolumeManagement updated.
<daniels> pitti: so every upstream release I'd have to hand-roll a tarball with some autoconf/automake stuff I hacked up, it was pretty nasty
<fabbione> mdz: do we also need to update the status in breezygoals?
<pitti> daniels: urgs
<pitti> daniels: however, why can't dbus-cil not stay in universe for a while?
<pitti> daniels: ah, for the build-depends, nevermind
<daniels> pitti: yeah, all its b-ds need to come into main
<daniels> doesn't matter, mono is apparently pretty broken right now anyway
<mdz> daniels: we are on daylight time now
<mdz> without is -8
<daniels> mdz: ah, righto.
<KaiL_> fabbione: are there plans for integrating "external" GPLed drivers like rt2500 into linux-image? Or some "linux-free-modules"?
<fabbione> KaiL_: nothing to do with partitions
<fabbione> KaiL_: it has been done already in breezy
<fabbione> please check the changelog
<KaiL_> I'll do as soon as packages.u.c awakes *g*
<jdub> fabbione: i'
<jdub> fabbione: i'm running 2.6.12 on my laptop now :)
<Lathiat> me too as of just then
<fabbione> jdub: neat.. does it work?
<Lathiat> works great
<jdub> fabbione: it does :-)
<fabbione> eheh
<Lathiat> i wonder if gamin is using inotify
<fabbione> no it doesn't
<jdub> Lathiat: nup
<jdub> Lathiat: going to do an upload tonight
<fabbione> gamin inotify backend is utterly broken
<fabbione> jdub: no please!
<KaiL_> oh, .12 packages
<Lathiat> yeh i just thought i saw someone mention something about a cvs version
<fabbione> it has been disabled for a reason
* KaiL_ will try soon
<jdub> fabbione: yeah, i disabled it :-)
<fabbione> no i did
<Lathiat> i also have beagle love
<jdub> fabbione: but there is work being done in cvs which will help
<fabbione> jdub: can you please wait a few days?
<fabbione> because there is another inotify kernel patch that needs to go in
<jdub> sure, i'll wait for that ;)
<fabbione> and i don't want to fight with extra debugging problems
<fabbione> because userland and kernel do not match
<cartman> http://people.ubuntu.com/~lamont/buildLogs/t/tar/1.15.1-1/ <-- looks like a gcc4 problem. anyone?
<KaiL_> daniels: about the mouse issues: I have an Logitech MX510 here and are trying to get it working - at least the sidebuttons are done
<KaiL_> that mouse behaves a bit silly, as some buttons send 2 events
<fabbione> cartman: mostlikely 
<cartman> new tar is ueber cool,someone fix it please *g*
<lamont> cartel_: sounds about right.
* lamont sleeps
<Lathiat> yay beagle works
<Lathiat> sees gaim, blam, files, evolution mail
<fabbione> night lamont
<dholbach> bye lamont 
<pitti> night lamont 
<Lathiat> http://bur.st/~lathiat/beagle.png
<Treenaks> Lathiat: no porn? :)
<daniels> KaiL_: cool
<Lathiat> "the other fruits of my pleasures..." heh
<Lathiat> anyone watch the last novell brainshare keynote?
<Lathiat> nat is a laugh
<KaiL_> and whoever did: powernowd works again, even as it still doesn't like my Sempron ;)
<Lathiat> yeh
<HrdwrBoB> powernowd whinges about my opterons because I'm too lazy to change it
<HrdwrBoB> I just stuck the module in /etc/modules
<KaiL_> also some "This processor "AMD Sempron(tm) Processor 3100+" is known _not_ to support power-saving."?
<HrdwrBoB> yeah
<KaiL_> somebody should give the upstream author some K8 ;)
* KaiL_ tries 2.6.12
<Treenaks> Kamion: final?
<Treenaks> uh
<Treenaks> kail
<Treenaks> so THAT's whay tab didn't work..
<fabbione> no.. it's not final
<fabbione> it's rc4
<bob2> a sempron isn't a k8
<eruin> hmm, I wonder how much hacking would be involved to get beagle to play with gaim
<eruin> err, gmail
<Lathiat> damn
<Lathiat> thats alot of mozilla issues
<pitti> Lathiat: indeed :-/
<Lathiat> go mozilla
* pitti tries 2.6.12, brb
<fabbione> YAY
<fabbione>  /dev/mapper/bla-bla    34G  408M   33G   2% /
<toresbe> fabbione: uh... yay!
<Treenaks> only 34G? :P
<fabbione> you all suck :P
<fabbione> that's really not the point of it ;)
<zyga> pitti: hey
<zyga> pitti: does it work okay for you?
<pitti> fabbione: 2.6.12 boots, sound, network, usb, hotplug, gvfs, and even the update-notifier thingy work
<fabbione> pitti: rocking
<pitti> zyga: yes, pretty fine; at least it doesn't break horribly
<pitti> fabbione: you rock :-)
<fabbione> what is gvfs?
<pitti> fabbione: I'll try powerpc later tpday
<zyga> pitti: do you have any ati/nvidia card that could use properiarity drivers?
<pitti> today, even
<KaiL> result from the update: nothing changed, neigher negative nor positive (means ACPI S1/S3 still broken)
<jdub> fabbione: short for gnome-vfs?
<pitti> zyga: I have, but I can't use nvidia-glx with 2.6.12
<pitti> fabbione: right, gnome-vfs
<fabbione> jdub: ahhhh that's not a kernel module :)
<jdub> fabbione: thankfully not! :)
<Lathiat> i jsut installed the drivers from nvidia
<Lathiat> since my suspend works on the latest anyway
<Lathiat> as opposed to the older packaged ones
<zyga> pitti: why not? it's not compatible that bad?
<KaiL> pitti: you need a "linux-restricted-modules-2.6.12-1-386" :))
<fabbione> there is no l-r-m for 2.6.12
<fabbione> and there will be none until 2.6.12 is final
<fabbione> and in main
<ajmitch_> evening charles
<chmj> erm, morning ajmitch_ 
<ajmitch_> :)
<dholbach> bye guys!
<jsgotangco> bye
<fabbione> bbl
<bob2> GO GO GO GO
<daniels> Lathiat: uhm, you do know that we have the latest nvidia drivers, right?
<Lathiat> daniels: we do?
<Lathiat> i hadnt noticed
<Lathiat> not on 2.6.12 anyway :)
<daniels> yeah, we have 1.0.7174
<Lathiat> ah cool
<daniels> nah, no l-r-m for .12 yet
<Lathiat> didnt see the udpate
<daniels> we've had it since before hoary final
<Lathiat> really?
<jsgotangco> yeah
<Lathiat> humm
<jsgotangco> restricted
<daniels> dbus 0.33-0ubuntu1 uploaded; go nuts
<Lathiat> how did i miss that
<Lathiat> daniels: is that goign to break my beagle? :P
<daniels> lathi	badly
* Lathiat turns off his update cron script
<Lathiat> what about hal and udev? :)
<daniels> it'll stay broken until mono a) gets fixed, and b) gets put into main
<daniels> it'll break hal, udev, pmount, gnome-volume-manager, chunks of nautilus
<daniels> epiphany
<daniels> anything that uses dbus is now broken
<daniels> have fun!
<Lathiat> well next version of beagle doesnt use dbus anyway
<Lathiat> who looks after hal and stuff?
<Lathiat> cus i heard they are updated
<daniels> pitti looks after hal; he and seb128 already have the transition (including hal 0.5.x) well in hand
<pitti> Lathiat: I will upload pmount, hal, g-v-m shortly
<Lathiat> pitti: cool.
<pitti> GO UTOPIA GO!
* pitti uploads his crack
<seb128> I will upload the gnome stuff then
* mvo uploads too
<Lathiat> what does epiphany use d-bus for?
<Treenaks> Lathiat: beagle.xpi?
<Lathiat> oh right
<Lathiat> i want that
<seb128> Lathiat: network magic
<seb128> Lathiat: it can talk with networkmanager
<jsgotangco> pitti, PDA Support just became High Priority
<pitti> argh
* pitti hides
<jsgotangco> gyaahh
<Treenaks> jsgotangco: pda support! \o/
<pitti> that's a f**ing brain dump, why that?
* Treenaks pokes his palm
<\sh> gna
<\sh> morning btw
<jsgotangco> mdz edited the wiki
<jsgotangco> The following page has been changed by MattZimmerman:
<jsgotangco> http://udu.wiki.ubuntu.com/PDASupport
<jsgotangco> The comment on the change is:
<jsgotangco> high priority
<Lathiat> the comment on multisync is wrong...
<Lathiat> my version is workign fine with multisync
<Lathiat> *evolution
<ajmitch_> pitti: they think you're not working enough yet? :)
<Lathiat> it was fixed at some point
<pitti> ajmitch_: I don't even have a PDA (I have a notebook...), so I'm not going to lead that anyway :-)
<Lathiat> i have an ipaq and palm V and can test stuff against palm, ppc2002, opie, gpe
<Lathiat> and have multisync syncing to my phoen via BT too
<jsgotangco> i have a broken ppc and a very old usr palm
<Lathiat> getting the pocketpc stuff to work is a bit of an ass tho
<Lathiat> (synce)
<ajmitch_> hi mjg59 
<jsgotangco> i think for PDA support to move we have to focus on certain devices
<jsgotangco> instead of trying to run them all
<Lathiat> yeh
<Lathiat> palms are pocketpc are common
<Lathiat> which covers most major stuff anyway....
<Lathiat> theres also the zaurus/opie stuff
<jsgotangco> palms are a given since it has major support
<jsgotangco> but the zaurus stuff is ewww
<Lathiat> i foudn the palm stuff didnt work very well
* jsgotangco used to have a zaurus
<Lathiat> the opie/zaurus multisync is totally broken
<Lathiat> the gpe sync kinda works
<Lathiat> (gpe is a linux/GTK based palm environment for ipaqs)
<jsgotangco> whatever happened to kitchensync
<Lathiat> that exists
<Lathiat> its a kde thing..
<Lathiat> i think
<jsgotangco> it had promise before when i was active in oz
* Lathiat installs it to play
<jsgotangco> but i made the biggest mistake of trading my zaurus for an ipaq
<daniels> unfortunately my ipaq is totally unsupported by linux
<Lathiat> daniels: yeh, shame
<Lathiat> i have a 3870 which is totally supported
<Lathiat> sound, bluetooth, everything
<Lathiat> they even got SD cards working now
<jsgotangco> how much do those things cost at the moment
<Lathiat> i was under the impression that was legally dubios
<jdub> "iPaq linux: Because battery life is just as bad as battery hens."
<Lathiat> i dont find that...
<jsgotangco> its strange i just read somewhere that pda sales are increasing again
<jsgotangco> (the ones with wireless though)
<daniels> jdub: haha
<jsgotangco> poor hens
<bob2> wish my battery lasted longer
<KaiL> and the next :)
<fabbione> Kamion: you awake yet?
<Kamion> fabbione: yes
<fabbione> Kamion: i started looking at InstallerVolumeManagement
<fabbione> Kamion: i was searching for partman-auto-lvm.. is it in the archive at all?
<fabbione> or is it part of another package?
<Kamion> I added it to the installer seed yesterday or thereabouts
<Kamion> it's a package by itself
<Kamion> hm, although it isn't in universe
<Kamion> oh, nobody ever uploaded it to Debian
<Kamion> I'll take care of that
<fabbione> eheh ok
<fabbione> i would also like a review/comments on the first bits of the investigation
<fabbione> Kamion: ^^
<fabbione> if you have time of course
<Kamion> fabbione: thanks, looks good. the initrd solution is scaaaary :)
<fabbione> Kamion: it is so simple you won't believe :)
<Kamion> fabbione: how about offline resize on ext3/lvm?
<fabbione> Kamion: we can't put offline /
<fabbione> that's the whole point of the initrd / reboot thingy
<Kamion> yes I know not /
<Kamion> but say a separate /home
<fabbione> doing it at initrd level will keep / offline
<fabbione> we still have the problem that we might not be able to umount /home
<Kamion> nod
<fabbione> specially due to our sudo policy
<fabbione> user logs in -> sudo resize /home
<fabbione> bam
<fabbione> i think a general offline solution is the best
<fabbione> and the safest
<Lathiat> i find it deeply amusing that linux supports my ipaq hardware better than pocketpc
<ajmitch_> what issues have you had with online resizing?
<fabbione> ajmitch_: it's not supported for all FS
<fabbione> and it is dangerous on some of them
<jsgotangco> Lathiat, gpe/opie?
<ajmitch_> I've used it successfully on ext3/LVM
<fabbione> ajmitch_: with / ?
<Lathiat> jsgotangco: gpe
<Kamion> "ext2online is not portable"
<Kamion> portable to what?
<ajmitch_> no, another partition
<fabbione> Kamion: PPC ?
<Lathiat> among otehr things, the bluetooth works and doesnt crash all the time, and my exexternal keyboard just works (tm)
<fabbione> Kamion: it assume a series of things that makes the list of possible point of failures scary
<Kamion> 'k
<ajmitch_> at least ext2resize 1.1.17 had some bad endian/64-bit bugs
<ajmitch_> but that one didn't work with current kernels anyway
<fabbione> you need to "mangle" ext2 to add a special inode, that requires patched kernel, patched e2fsck and other stuff
<ajmitch_> right
<fabbione> i really don't want to take that direction
<jsgotangco> wow gpe has evolved
<Lathiat> jsgotangco: yeh gpe is kicking ss
<Lathiat> i can even scan bluetooth
<Lathiat> and tell it to connect to the network interface on my laptop
<Lathiat> just by clicking on it
<Lathiat> and it works much nicer, and has multisync support
<Lathiat> its totally rocking
<Lathiat> (altho the multisync support doesnt seem to do calendar yet)
<jsgotangco> wtf
<Lathiat> that coudl just be broken multisync with evo2
<Lathiat> (altho evo2 in multisync syncs with my phone fine)
<fabbione> guys, these stuff looks more or less #ubuntu stuff
<fabbione> please let's try to stay on topic
<jsgotangco> sorry
<Lathiat> i was only really mentioning because someone mentioned pda support was a breezy goal, shrug, sorry
<Mithrandir> seb128: I didn't finish the pkg-config fix last night, sorry.  I think I'll just upload a new package with --enable-indirect-deps and let it be until I have time to fix it properly.
<seb128> k, thanks
<fabbione> daniels: dbus changelog is scary!
<fabbione> we also have the issue that mono is not really portable yet.. but that's a per arch problem
* eruin hugs 2.6.12
<daniels> fabbione: yeah, dbus has been freaky shit
<fabbione> there is something in the breezy boot process that is really wrong
<fabbione> it keeps trying to run portmap 2/3 times + it doesn't wait for dhcp to get the ip
<sladen> fabbione: what is it?
<fabbione> = mess
<fabbione> sladen: i am not sure yet
<fabbione> i installed hoary and upgraded to breezy (right this morning)
<fabbione> so it's all fresh and clean
<sladen> is portmap being started from inetd?
<fabbione> it shouldn't
<fabbione> no it's not
<fabbione> and there is a really scary message from init.d/network
<fabbione> that it can't map reliably eth0
<fabbione> but there is only THAT net interface on the box
<fabbione> OH I SEE
<fabbione> mountnfs.sh
<fabbione> crap
<Treenaks> yay! ipv6 works again with 2.6.12!
* Treenaks gives fabbione some beer
<jsgotangco> brb
<fabbione> Treenaks: ????
<fabbione> i am using it with .10 tooo
<Lathiat> as do i
<Treenaks> fabbione: I think it's an ipw2200 bug
<Treenaks> fabbione: it worked for a while, then I got a new prefix, and suddenly it stopped working -- but only on that machine
<Treenaks> fabbione: (the dmesg was full of "duplicate address" messages)
<fabbione> Treenaks: ah wifi.. yeah there are some issues 
<Treenaks> anyway, it works now.. or it seems to work at least
<fabbione> i have problems with my AP + ipv6 + mac filtering
<Lathiat> i had duplicate address messages with ipv4 from the ipw2200 driver all the time, is that related?
<fabbione> but i know it is an AP problem
<Treenaks> I have some ASUS AP
<Treenaks> running linux
<Lathiat> cant see i tnow so 
<fabbione> i use Cisco
<fabbione> i don't get the duplicate address.. that can be a misconfiguration on your net
<Lathiat> the duplicate address thing happened anywhere on any network with no duplicates
<Lathiat> didnt affect it or anything
<Lathiat> im interested to see if the new driver stops crashing out on me
<fabbione> sladen: the problem seems to be that the network services (like nfs/portmap) try to start too early, before the dhcp got an ip address
<Lathiat> every so often the old version died when i shut my lid or left it over night
<fabbione> so adding a sleep in the network init script helps
<fabbione> but that's clearly not the clean solution
<zyga> 
<Lathiat> fabbione: they run in parallel?
<Lathiat> or is dhcp now being backgrounded?
<fabbione> Lathiat: dhcp forks in background afaik
<Lathiat> oh rad
<Lathiat> didnt use to do that and it annoyed me
<fabbione> it's not rad if it breaks the boot
<Lathiat> well, no
<Lathiat> its not
<Lathiat> altho isnt it a bit broken that portmap needs the interface to be up?
<Lathiat> what happens if the interface goes down and back up or a new module is loaded with a cardbus card?
<fabbione> Lathiat: it's a network service.. 
<fabbione> it relies on network...
<Lathiat> or do you mean when actually mounting nfs?
<fabbione> if a new dev is added it behavs at it should..
<fabbione> mounting nfs
<Lathiat> oh right, i thought you meant just starting portmap.
<Lathiat> i guess the optimum solution would be getting dhclient to do somethign when it finishes working or failing and spinning on that in mountnfs
<Lathiat> or calling out to mountnfs when the interfaces are all up
<fabbione> i am thinking what the best solution would be
<fabbione> mountnfs is tricky..
<fabbione> you might have /home or /usr on nfs
<Lathiat> it sucks a bit cus you might need /usr or /home or something on nfs
<Lathiat> yeh, exactly
<infinity> Is it really sane to be forking dhclient and praying?
<infinity> A whole host of init scripts after that could be relying on a real network being present.
<infinity> Creating a spinlock as a stopgap is silly.
<fabbione> infinity: including ntpdate
<fabbione> AHHHHHH
<infinity> Yes.
<Lathiat> speaking of that, i think ntpdate needs to timeout faster
<fabbione> no
<fabbione> it's not network fault
<fabbione> it's hotplug too slow in loading the eth module
<Lathiat> oh
<zyga> ignoring the licensing issues for a moment, could launchd help to solve your problem?
<infinity> Ahh, that's a different bug altogether.
<pitti> we desperately need the dev.d and dependency-based init system, it seems
<Lathiat> yeh that would rock
<infinity> I used to get that way back when with pcmcia-cs and a pcmcia card.
<Lathiat> zyga: launchd is broader than just bootup
<zyga> Lathiat: I know but it has dependency stuff, does it not/
<fabbione> well not everybody has 15 usb devices connected to his machine :)
<Lathiat> zyga: it does, so does initng
<infinity> pitti : Our current init system is already dependency-based, except when people fork things we like. :)
* zyga for one welcomes our new xml based config overlords
<infinity> (like backgrounding hotplug operations or pcmcia-cs detection)
<pitti> infinity: huh?
<infinity> pitti : Our current init is dependency-based, just happens to also be serial.
<pitti> infinity: I still have sysvinit...
<infinity> pitti : If it wasn't, we wouldn't bother with the cute numbers.
<infinity> It's just not intuitively dependency-based.
<pitti> infinity: I don't mean "arrange the init script in a sane order"
<infinity> (Yes, I know what you meant)
<pitti> infinity: ah, ok :-)
<infinity> I think the real win will be converting 95% of our init scripts to dev.d scripts, and scrapping init for most of that stuff.
<infinity> Many/most things run from init shouldn't be in a dev.d world.
<jdub> hrm, mozilla still in main
<infinity> Yes.  Check its reverse build-deps.
<fabbione> it looks more like that hotplug has been changed for some network related things
<jdub> mmm, just looking - disgusting
<infinity> jdub : If you can shove it out in a sane fashion, you'll be my hero.
<Kamion> we explicitly agreed to keep it in main
<Burgundavia> shoot me for not being a dev, but wouldn't it be better to split out the gecko engine, so that yelp,etc. could depend on that, and not a browser?
<jdub> Burgundavia: sure, please send your request to the mozilla foundation
<Burgundavia> jdub, right
<jdub> (hint: they have absolutely no corporate interest in doing it whatsoever, as it's against their stated aims with firefox and the 'mozilla platform')
<Burgundavia> that I figured
<jdub> Kamion: i thought we agreed to take it out as soon as viable (but not for hoary)
<Burgundavia> what are there stated aims for firefox?
<Burgundavia> and how does splitting out a renderer conflict with them?
<jdub> a) it's work b) firefox is their flagship product
<Burgundavia> true
<jdub> Kamion: oh, nss
<ogra> heya
* Mithrandir twaps lamont
<ajmitch_> hi ogra 
<zyga> hmm didn't conqueror rip gecko out some time ago?
<Mithrandir> lamont: you didn't ever _try_ building nmap with DEB_BUILD_OPTIONS="debug nostrip", did you?
<jdub> zyga: no
<Burgundavia> zyga, konq is khtml
<jdub> zyga: it just made an equivalent of gtkmozembed
<jdub> zyga: built on top of the mozilla-qt port
<zyga> I know but there was some info a while ago that devs managed to put gecko in conqueror and (in some way allow to use khtml or gecko, choosing at compile time)
<zyga> http://developers.slashdot.org/article.pl?sid=04/09/11/2119249&tid=154&tid=121&tid=8
<zyga> voila
<Lathiat> slashdot, the source of all accurate knowledge
<zyga> ;] 
<ogra> jdub, where is the fridge ? ubuntu-users is full of people that try to start a "spreadfirefox" page for ubuntu... some already started...
<zyga> so it the news fraud/incorrect or did they really do it?
<jdub> zyga: see what i said above
<jdub> ogra: hrm, i should reply to that
<ogra> yep
<ogra> collect the forces :)
<jdub> hrm, haven't read u-u for a bit :|
<\sh> ogra: install s9y and u have it ;)
<\sh> or drupal ;)
<ogra> bah, drupal
<\sh> ogra: spreadfirefox is running drupal ;)
<jdub> it's fairly likely that the fridge will be a drupal site
<\sh> jdub: thats sad :(
<jdub> why?
<Treenaks> jdub: it's not python
<mvo> ping thom 
<jdub> there's no reasonable python equivalent that has the featureset or extensibility without writing a fair chunk of code
<Treenaks> good point
<\sh> jdub: the philosophy behind drupal is not what u want. check kdedeveloper.org (sp?) it's also running drupal...and it's quite weired...cause it doesn't make any differences between static content, dynamic content, blog content and stuff. well, in the end, it's just like phpnuke or postnuke..but this shouldn't be. 
<\sh> zope with plone, as a different point of start, will be too slow for the masses, it shows up right now on ubuntulinux.com
<Lathiat> i dont think anything could be quite as horrid as phpnuke
<jdub> \sh: there are good and bad drupal sites...
<infinity> Hey elmo.
<elmo> hi infinity 
<\sh> jdub: i'm not talking about the appearences of drupal sites..the system itself is "buggy".
<Burgundavia> jdub, see also http://www.ubuntuforums.org/showthread.php?t=14810&highlight=spreadubuntu
<Burgundavia> jdub, and http://www.ubuntuforums.org/showthread.php?t=32639&highlight=spreadubuntu
<infinity> elmo : Can I get powerpc-utils synced again, this time the version I wanted (must have been in incoming before or something)... -15
<infinity> elmo : You have a bug in BZ about it, which I'll just close for you.
<infinity> (wasn't sure when you'd be around)
<jdub> \sh: i've used it in the past - it's not terrible
<\sh> jdub: what "thefridge" wants is a fast and furious CMS, which is easy to maintain, the administrational tasks to a low task of work
<\sh> jdub: i hacked the code a bit, last year :)
<\sh> jdub: and the CMS should have different apps running for different tasks under one "control panel"
<jdub> sure, and right now, drupal seems to be the right choice
<ogra> argl....
<\sh> jdub: if this CMS should be a "php" application at all, we should check out the following: what do u want: e.g. news pages, interview pages, user content.
* ogra sees a new upcoming spatial vs browser discussion in -users *yawn*
<Lathiat> heh
<Lathiat> that just wont go away
<ajmitch_> yet another?
<infinity> If you're writing anything from the ground up, please avoid PHP.  Please.
<Lathiat> i feel dirty because i use browser mode
<jdub> if we keep doing stupid things, it'll never go away :-)
<ogra> yeah
<\sh> news pages are likely blog alike, interview pages are more like FAQ systems...one question, several answers etc. there are some systems, which are "normally" standalone webapps, but can be combined into one good cms.
<\sh> inif
<fabbione> ogra, amu: ping?
<ogra> infinity, you _dont_ like php ?
<ogra> fabbione, pong :)
<infinity> ogra : Are you surprised?
<\sh> infinity: no...no new rewrite of what is already there ;)
<Treenaks> ogra: you DO?
<ogra> infinity, not really :)
<ogra> Treenaks, nah....
<fabbione> ogra: clusterfs :)
<ogra> yep
<fabbione> feel lucky today?
<ogra> fabbione, i'll need to set up some machines first....
<fabbione> ogra: upgrading to breezy kernel and installing a couple of packages is enough
<fabbione> + a spare partition
<fabbione> on one of the machines
* ogra is just sorting his office for a new job he starts on monday ;)
<fabbione> eheh
<\sh> ogra: homeoffice work? 
<ogra> fabbione, ok, that should be possible.... 
<ogra> \sh, yep, a bit :)
<fabbione> ogra: ping me when you are ready
<ogra> oki
<fabbione> and i will drive you trough the first steps
<\sh> jdub: check out http://www.opencms.org
<\sh> it's java, ok i don't like java, but it looks promising
<ogra> oh, has anybody seen this ? http://www.symphonyos.com/desktop.html
<jsgotangco> ogra, hi
<ogra> hi jsgotangco 
<jsgotangco> it looks nice
<ogra> yep...
<Zomb> ogra: fear competition
<ogra> nah, competition is good, dont fear it ;)
<jsgotangco> corner applets are not that clearly defined though
<zyga> graphics is cute
<zyga> so where's the .torrent?
<Burgundavia> not even out of alpha yet
<zyga> the dev says they have limited bandwidth, is the .torrent not a perfect solution for that?
<zyga> anyway it does look nice
<zyga> not another osx/windows ripoff
<zyga> it is pretty unique ;)
<Burgundavia> there are some cool ideas there
<Burgundavia> I really don't know how usable it would be
<zyga> corner apps are cool :)
<zyga> Burgundavia: think new users and kids 
<Burgundavia> those desklet things better not be clickable
<Burgundavia> zyga, for kids yes
<zyga> Burgundavia: kids = future
<jsgotangco> if that's the future count me out
<zyga> jsgotangco: kids are the future, would you rather put windows on their boxes instead?
<fabbione> yayayaya... Kamion: shrink (ext2/3) works fine too
<Kamion> w00t. offline only, I assume?
<Burgundavia> it looks very pretty, but as I said, I don't know how usable the whole system is for anyone
<zyga> I did like one other thing too, devs mentioned they target low end boxes - that's very good nowdays
<fabbione> Kamion: yes
<stockh0lm> huhu!
<stockh0lm> mdz: awake, still?
<tseng> stockh0lm: its quite early there
<tseng> stockh0lm: 2am iirc
<Kamion> 3:15am
* fabbione -> food
<pitti> seb128: now I uploaded all the crack necessary to pmount an encrypted device :-) g-v-m support is on the way
<seb128> elmo: around?
* chmj -> lunch 
<thom> mvo, pitti: pong
<seb128> I've just read the pmout mail on changes :)
<pitti> Hey thom 
<seb128> hey thom 
<thom> pitti: what's this about breaking your firefox?
<thom> good morning
<pitti> thom: actually I wanted to ask you about errors in the USN
<ogra> morning TheMuso 
<ogra> morning Thom
<ogra> grr
<pitti> thom: but I already released the stuff this morning (I wanted to get this out ASAP)
<mvo> morning Thom
<ajmitch_> hi mvo 
<thom> pitti: errors?
<pitti> ogra: set completion_amount = 0
<pitti> thom: spelingg errors, bad English expressions, and the like
<thom> i didn't notice any last night
<pitti> okay, thanks for looking
<Kamion> there was the unfortunate "Ubuntu 5.04 (Warty Warthog)" thing ;)
<pitti> uuuh
* pitti corrects the web site at least
<jsgotangco> bye bye guys
<ajmitch_> bye jsgotangco 
<jordi> Kamion: ouch :)
<ismail> daniels: http://lists.freedesktop.org/archives/xorg/2005-May/007758.html time for an X.org update? :)
<ajmitch_> jordi!
<mvo> hey ajmitch_ 
<jordi> ajmitch!
<ajmitch_> jordi: feeling a bit more alive now?
* mvo waves to jordi 
<jordi> ajmitch_: yeah :)
<jordi> not dr death anymore
<jordi> but I still cough and have horrible stuff inside of me :)
<pitti> seb128: btw, do you know of upstream efforts to convert gvfs from gamin to inotify?
<pitti> (or, rather, offer an additional inotify backend)
<seb128> no move atm
<seb128> one of gnomevfs guy is tempted to do it, but alex (the main maintainer) wants to wait on an API stabilisation first
<tseng> pitti: there is work in cvs to get an actually working gamin inotify backend
<seb128> gamin is crap
<seb128> basically
<seb128> that's why it would be nice to have gvfs using inotify directly
<tseng> hm sure.
<Lathiat> or make gamin not suck
<sladen> fabbione: it needs so way of hooking.  eg.  call me back to add an interface.  call me back when one disappears.  then they could be brought up on localhost and the hooks called again when something changes.  thom?
<dholbach> re
<mvo> wb dholbach 
<zyga> mvo: hey, how are you?
<mvo> hey zyga, fine. how are you? 
<zyga> mvo: fine, perfect time to hack :-)
<mvo> zyga: what are you hacking on right now?
<zyga> mvo: old stuff, libintl 
<zyga> mvo: I plan to finish it this time
<jdub> seb128: you going to tell DV that gamin is crap? :-)
<ajmitch_> mvo: what are your plans on the finding packages spec now? :)
<mvo> ajmitch_: that's a tough questions :)
<ajmitch_> hehe
<seb128> jdub: no, just pushing gicmo to use directly inotify ;)
<mvo> ajmitch_: I need to squeeze it somewhere, I have a lot of things to work on right now
<dholbach> mvo: just create more myths around it :-)
<seb128> no need to push in fact, after spending some hour to track issues with gamin he really want to use it
<seb128> dholbach: daniel!!
<dholbach> hey sbastien!!! :-)
<seb128> how was your conf?
* mvo runs
<jdub> seb128: not sure inotify will scale with a large number of clients
<seb128> jdub: you mean it's not there yet?
<ajmitch_> mvo: that's understandable :)
<dholbach> seb128: boring - the other guys didnt get their laptop sorted, so i had to talk "into the air" - i had my fun :-)
<seb128> cool :)
<jdub> seb128: last i spoke to rml about using inotify directly, he said it was not intended to be used individually by many processes on the system at once - i'll check with him again to see if that's true now
<seb128> jdub: k, thanks
<seb128> jdub: but gamin or gnome-vfs I don't get the difference
<mvo> pitti: is there already a mapping between language pack packages and the supported language names? can I use the "Language: " entry in the description?
<seb128> I mean some part need to set the monitors
<jdub> seb128: unless the gnome-vfs module runs as a separate process (like smb), that means every running process will have its own inotify connection
<pitti> mvo: the mapping is in langpack-o-matic
<seb128> mvo: any way to get something associated to deb files, so when you click on a deb from nautilus you can install it?
<seb128> jdub: right
<pitti> mvo: I originally got it from miscfiles (it contains a mapping) and tweaked it a bit
<\sh> mvo: u had a look over the stuff I mentioned yesterday concerning update-manager?
<mvo> seb128: it's debian bug #47379, there is some work being done on it. we could use gdeb, but I consider it ugly(tm)
<mvo> \sh: I haven't looked at your example code yet
<mvo> pitti: can you send it to me please? so that I get a idea about it?
<seb128> mvo: yeah, I don't like gdeb neither, that's why I'm asking
<pitti> mvo: rookery:/srv/language-packs.ubuntu.com/langpack-o-matic/tools/languages
<pitti> mvo: shall I export it through HTTP so that you always have an uptodate mapping?
<mvo> pitti: might be nice, but I assume it does not change that often?
<pitti> mvo: http://people.ubuntu.com/~pitti/languages
<mvo> pitti: thanks
<pitti> mvo: well, not that often, but it may happen
<pitti> mvo: that's a symlink
<ajmitch_> elmo: request for sync of drpython, ubuntu patches not needed now
<ajmitch_> from sid, that is
<elmo> ajmitch_: done
<seb128> elmo: I guess than dbus is waiting in NEW?
<elmo> yah
<ajmitch_> thanks
<dholbach> sabdfl: hi mark!
<sabdfl> any reason all my man pages might have disappeared?
<sabdfl> hey daniel
<sabdfl> slinky% man pilot-xfer                                /usr/share/doc/pilot-link
<sabdfl> No manual entry for pilot-xfer
<sabdfl> See 'man 7 undocumented' for help when manual pages are not available.
<sabdfl> seems like they're all gone on holiday
<jordi> hey sabdfl!
<jordi> did the bottle make it safely to London?
<dholbach> all? does   man bash   work?
<sabdfl> hey jordi - how's the paella down there?
<sabdfl> dholbach: all
<jordi> sabdfl: WAY BETTER than in Castell :)
<sabdfl> jordi: lucky beach bum
<dholbach> anything in  /usr/share/man/man1 ?
<ajmitch_> hi sabdfl 
<sabdfl> hey ajmitch_
<dholbach> sabdfl: is there _anything_  in  /usr/share/man/man1 ?
<sabdfl> dholbach: tons of man files
<Kamion> sabdfl: if the physical man page is there, mail me the output of 'man -d pilot-xfer'
<Kamion> i.e. if /usr/share/man/man1/pilot-xfer.1.gz is there
<sabdfl> ah...
<sabdfl> MANPATH=/man:/usr/man:/usr/lang/man:/usr/local/man
<sabdfl> wonder how that happened
<Kamion> wow
<sabdfl> i just switched to zsh, maybe it got lost in translation
<Kamion> MANPATH should generally be unset
<Kamion> man figures it out from $PATH
<dholbach> bbl
<Lathiat> i like zsh
<Lathiat> tab completion is far better than bashs'
<sabdfl> ok, i copied the example zshrc to ~/.zshrc and missed that
<sabdfl> now, if we had HCT I could just fetch it and make a patch very easily :-)
<sabdfl> Keybuk: ^^ (hint)
<Kamion> but you're not bitter at all
<Lathiat> http://bur.st/~lathiat/zshrc might be usefull
<ajmitch_> 403
<Lathiat> fixed
<Keybuk> sabdfl: if you stopped asking stub to reset the dogfood database, it might have been imported by now :p
<sabdfl> Keybuk: is man in the current set of known branches (from the old info files)? if not, could you add the upstream and steer it through? I'll use this as my tutorial on hct
<Keybuk> man?  as in man-db/groff ?
<Kamion> man-db's on arch.ubuntu.com
<Kamion> though I haven't looked it over yet
<Keybuk> yeah, I think that one's already imported
<Kamion> what do you need to change in man-db though?
<seb128> elmo: libgsf sync please
<elmo> seb128: done
<seb128> thanks
<sabdfl> Kamion: i'll see if i can use HCT to produce a nice patch to improve the example zshrc that doesn't nuke man on ubuntu
<Kamion> sabdfl: yeah, but that's zsh, not man-db
<Kamion> man-db doesn't ship an example zshrc
<daniels> ismyeah, I'm still tossing up what to do
<seb128> elmo: libdbus-glib-1-dev is universe which breaks the hal 0.5 build, can you fix that please? :)
<daniels> bah, not even here
<seb128> elmo: and we will probably get the same issue for hal then
<Keybuk> zsh is one of the "tricky" ones; the Debian maintainer has already arch'd it
<Keybuk> but without any cvs history
<sabdfl> Kamion: ermm... true
<sabdfl> Keybuk: is the debian arch repo being used for anything other than the debian package?
<sabdfl> in other words, has it become the official upstream way-to-do-arch?
<Keybuk> no idea
<fabbione> hey sabdfl 
<Keybuk> I don't think so
<\sh> g'afternoon sabdfl 
<Keybuk> I'm pretty sure zsh is in CVS upstream
<sabdfl> http://www.zsh.org/mla/workers/2005/msg00000.html
<Kamion> can we do stuff like syncing file-ids on import with an existing third-party repository like Clint's?
<sabdfl> seem's like he's at least trying to do the right thing
<Keybuk> that's the Debian maintainer
<Kamion> or does that get evil?
<sabdfl> Kamion: not yet, arch doesn't support it, baz-ng has a spec that both will implement
<Kamion> 'k
<sabdfl> where it gets very hairy is i'm guessing we may find quite a few "i've imported this as base-0" folks around the next for almost any upstream
<Kamion> mm
<sabdfl> so in general, we'll try to do a perfect from-start import and use that
<elmo> seb128: dbus done, I'll do hal as it appears on anastacia's radar
<sabdfl> if someone has done it properly, and plans to continue syncing reliably, we can tag off them
<stockh0lm> who here works on the internals for the edubuntu stuff?
<seb128> elmo: thanks
<elmo> mvo: done (ages ago, sorry)
<seb128> elmo: the hal buildd will retry the build, or you have kicked it?
<pitti> it should have been in dep-wait so far, shouldn't it?
<seb128> pitti: dunno, when it fail because package is universe, that's still dep-wait?
<elmo> seb128: it should retry automatically
<seb128> k
<seb128> cool
<mvo> elmo: noticed already, thanks :)
* pitti curses at autofuck tools
<pitti> seb128: do you know what I have to do after "aclocal: configure.in: 65: macro `AM_PATH_GTK' not found in library"?
<Mithrandir> pitti: install libgtk-dev?
<Kamion> jdub: bugzilla doesn't seem to let me set an UNCONFIRMED bug to NEEDINFO
<Kamion> #10539
<Mithrandir> sorry, libgtk2.0-dev or whatever it's called
<Kamion> do I have to set it to NEW first?
<pitti> Mithrandir: I already have libgtk2.0-dev, of course
<jdub> Kamion: shouldn't, but i really have no idea - works for me in other installs
<seb128> pitti: what package is that?
<pitti> seb128: I try to merge mtr
<seb128> pitti: that comes from /usr/share/aclocal/gtk-2.0.m4
<Mithrandir> pitti: change it to AM_PATH_GTK_2_0, it seems.
<pitti> seb128: it requires a configure.in change, which requires an automake run, which requires aclocal, and the latter two break
<seb128> ie: libgtk2.0-dev
<pitti> seb128: ok, then I try libgtk1.2-dev
<seb128> pitti: running autoconf is not enough?
<Kamion> yeah, UNCONFIRMED -> NEW -> NEEDINFO works. bleh.
<pitti> seb128: well, somehow I have to make sure that automake is not invoked automatically at build
<pitti> seb128: so lamont added AM_MAINTAINER_MODE
<pitti> which requires automake
<seb128> Kamion: yeah, I'm complaining about UNCONFIRMED to whatever broken for a month now ...
<seb128> Kamion: maybe kiko will have a look
<pitti> seb128: just touch configure in debian/rules doesn't help
<jdub> Kamion: hrm, this must've been what mdz was asking kiko about the other day
<Kamion> ah, maybe, I wasn't paying attention to that
<pitti> seb128: libgtk1.2-dev helped, thanks; now I only get a bazillion autoheader warnings, but let's see whether it works
<Kamion> heh, an amusing effect of the file sorting we do on CD images is that bugs look misleadingly deterministic
<Kamion> for example it's very common for installs to fail on bsdutils due to bad burns, and I think that happens to coincide with some particular position on the image
<Kamion> on the disk, I mean
<Kamion> and you don't see it before then because all the udebs loaded before that point are physically closer to the centre of the disk
<jdub> Kamion: yeah, that's spookily weird
<Treenaks> maybe the bsdutils package contains some pattern of bytes thats "Hard" to encode?
<Treenaks> (8-to-14 bit encoding)
<Kamion> seems extraordinarily unlikely that that would have been consistently preserved in a compressed .deb since warty
<sladen> arethere actually any pakcages that begin with 'a' or is bsdutils the first deb on the CD?
<pitti> acpi*
<pitti> apt
<pitti> anacron, adduser, probably more
<Treenaks> http://www.usbyte.com/common/compact_disk_4.htm
<Lathiat> so i have java at 635 mamoery, mono at 34.55 and vmware at 106.15, woot.
<Kamion> debootstrap installs base-files, base-passwd, and bash before bsdutils
<Lathiat> bah, now vmware has eaten my shfit key again
<Kamion> and there are plenty of udebs before that
<Lathiat> yeh bsdutils always gets eaten on my bad cds, its freaky
<Kamion> oops, I need to teach archive-copier about the standard seed
<Nafallo> morning all
<mvo> hey Mitario 
<Mitario> hi
<pitti> seb128: I think it is time to revisit #2134 (always eject devices instead of just unmounting them); this should be safe with the new hal
<pitti> seb128: do you know whether upstream does anything about it? if not, we might just throw the simple patch at the people and see how it works out (it works perfectly for me with eject)
<seb128> reading the bug
<seb128> upstream has changed this for nautilus 2.10:
<seb128>         * src/file-manager/nautilus-directory-view-ui.xml:
<seb128>         Allow eject on unmounted devices
<pitti> cool
<pitti> seb128: it's certainly not fixed in 2.9.90 as you claim in comment #8
<pitti> uh, wait
<pitti> we don't have this version
<pitti> oh, we have
<seb128> 2.9.90 has the changelog entry
<seb128>         * libgnomevfs/gnome-vfs-volume-ops.c: (mount_unmount_thread),
<seb128>         (mount_unmount_operation), (gnome_vfs_volume_unmount),
<seb128>         (gnome_vfs_volume_eject), (gnome_vfs_drive_mount),
<seb128>         (gnome_vfs_drive_eject):
<seb128>         allow eject of unmounted volumes.
* pitti is confused
<pitti> seb128: yes, but still I can't eject my USB stick
<pitti> seb128: iPod probably doesn't work either
<seb128> so that's a bug :)
<seb128> what does it say?
<seb128> oh, you mean directly?
<pitti> seb128: and instead of presenting the user two options, it should just always ejct
<seb128> I mean the purpose of the patch is to allow to eject stuff non-mounted from computer:///
<pitti> seb128: I think it does not make sense to have two options
<pitti> ah
<seb128> ie: CD drives listed by fstab
<pitti> seb128: that doesn't work for us then (with pmount)
<seb128> nop
<pitti> seb128: ah, I see, I have "mount" and "eject" for CD-ROMs
<seb128> that's it
<pitti> so what do you think about unifying this to eject in general?
<pitti> so that it works with iPods, USB sticks, and the like?
<seb128> is there any case we are stucked?
<seb128> ie: I want the device unmounted and not ejected?
<pitti> well, #1891 kept us from applying the patch so far
<pitti> but that is no issue any more with the new hal
<seb128> because you put a CD, g-v-m mounts it
<seb128> ou eject it ... no way to get it unmount and not ejected from the UI
<pitti> that's already the case
<pitti> CD-ROMs should maybe have two options
<pitti> but not USB devices
<seb128> right
<seb128> switching to eject seems ok with me
<pitti> the simple s/FALSE/TRUE/ patch?
<seb128> that's worth trying imho
<pitti> yeah, agreed
<pitti> okay, I patch (unless you want to)
<seb128> go for it
* JaneW clears throat
<JaneW> excuse me
<lifeless> wow
* lifeless offers a mentos
<JaneW> why has NO ONE updated the status of their Breezy Goal on http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals ??
<pitti> seb128: argh, the new gvfs source is not yet in the archve
<pitti> JaneW: I didn't yet get to actually starting with my tasks :-/
<Nafallo> pitti: thanks for cryptsetup. I'm about to play with my USB-key now :-)
<JaneW> pitti: still status indicators start at drafting, and go all the way through to implemented
<pitti> Nafallo: g-v-m integration is still missing, but pmount works now :-)
<JaneW> plus there are pretty colours that go with each status - it's FUN!
<Nafallo> pitti: yea, I saw. you have been busy ;-).
<pitti> seb128: is the package on p.u.c the one you uploaded?
<Nafallo> JaneW: *s* reminds me of Windows XP :-P.
<Nafallo> JaneW: hi btw :-)
<JaneW> groan
<JaneW> Hi Nafallo
<pitti> seb128: oops, no source there...
<Simira> mornin folks
<pitti> seb128: okay, I wait until it is there
<Nafallo> Simira: hi there :-)
* Kamion does a few of his goals
<Simira> hi Nafallo 
<jdub> yo Simira 
<Kamion> JaneW: I assume "pending" is stuff like "drafting done but implementation not yet started"
<Simira> morning jdub. Or good night, maybe?
<jdub> Simira: how is ubuntu-no going?
<Kamion> the "completed" / "tested" / "implemented" ordering seems odd? what's the difference between "completed" and "implemented"?
<jdub> Simira: always good morning for me :-)
<JaneW> Kamion: code completed, fully tested, and actually IN production
<JaneW> doesn;t it make sense like that?
<jdub> JaneW: needs an AWTY state
<Simira> jdub: we're coming along. A handful of translators are set in business, and we've had some other interested people. I just have to learn how to run a LoCo ;p 
<JaneW> We can change if necessary
<jdub> Simira: ;-)
<JaneW> AWTY? er... always wear tight y-fronts?
<pitti> JaneW: problem with pending is that it appears before deferred and before WIP
<Simira> jdub: I'm having a few ideas for activities after the summer holidays. I suppose it's difficult to gather people in summertime, besides I'm planning to pick up some ideas on Debconf
<Treenaks> Simira: running a LoCo is easy.. for the Dutch part at least
<Nafallo> would it be any helpful at all for my to clean up the mplayermess or are we about to get that in debian to sync soon?
<JaneW> pending means spec comleted and it's pending action (i.e. about to start)
<Treenaks> Simira: they all go their own way, and do what they like.. and sometimes we drink beer :)
<JaneW> deferred can happen anytime, if it gets shelves as a 'not now' item.
<Mithrandir> Treenaks: aka "herding cats"?
<Simira> Treenaks: sounds nice. We got to get that too. It's just that we got a good deal of young people. I intend to contact the lugs soon as well.
<Treenaks> Mithrandir: uh, a bit
<Kamion> JaneW: just seems kind of strange considering that full testing normally involves putting it into "production" in breezy - the only step beyond that is releasing breezy :-)
<Treenaks> Simira: afaik, we don't really have lugs here
<Kamion> JaneW: pending> ok, that's what I thought, thanks
<seb128> pitti: http://archive.ubuntu.com/ubuntu/pool/main/g/gnome-vfs2/
<seb128> pitti: it's here
<Simira> Treenaks: we have 6-7 of them, I don't know how active they are though. I guess half of them are somewhat active.
<pitti> seb128: just saw it, thanks
<seb128> pitti: ups, no .orig, I've messed up ... if you want to fix it :p
<pitti> seb128: I just apt-get source'd
<JaneW> Kamion: I am happy to change it. I am used to someone saying something is COMPLETED, it then goes to QA for testing and then only get's implemented, or an awful made up word that was used 'productionalised'
<pitti> seb128: oh right, it's native
<jdub> JaneW: "are we there yet" ;-)
<pitti> seb128: where is the orig?
<JaneW> jdub: OIC!
<Simira> :D
<JaneW> jdub: glad you don;t always wear tight y-fronts then ;)
<Kamion> JaneW: mm, yeah, I think our process needs to be a bit different there, but happy to wait to see if mdz feels the same way
<Simira> Kamion: can I sign up for ubuntu-member stuff for the next meeting now?
<seb128> pitti: mv gnome-vfs2-2.10.0cvs..../debian . && tar czf .....orig.tar.gz gnome-vfs2....
<jdub> not really a y-front fan, myself
<mdke> Simira, you definitely can
<seb128> pitti: ie: I've not changed anything out of debian/, so the dir without debian/ is the CVS
<mdke> Simira, just add your name and make a page
<Kamion> Simira: sure, link to your wiki page on CommunityCouncilAgenda and make sure your wiki page has detail about the things you've been doing for Ubuntu
<pitti> seb128: alright, I fix it
<JaneW> Kamion: ok I'll run my thinking past mdz, and see what he thinks.
<seb128> thanks
<Kamion> Simira: actually if you could create a new section with people to be considered at the next meeting, that would help avoid confusion with the people we just did
<JaneW> jdub: good, they are not the sexiest things on earth, that's for sure... thought some of the designer ones aren't bad..... *slaps self*
<Lathiat> how does one get a login for wiki.launchpad.canonical.com ?
<Kamion> Lathiat: it's private to LP developers at the moment
<Lathiat> oh, ok
<Lathiat> just annoying its linked off half of the udu wiki pages :)
<Kamion> yeah, I know
* mdke nods
<JaneW> Lathiat: yes we had a debate about that - sorry
<Lathiat> well i've done my whinging, if someone remembers let me knwo when its "fixed" :)
<mdke> i think in some cases material has been incorporated into the udu specs
<Lathiat> yeh but theres quite a few where it just links to the spec there and not much else
<Simira> Kamion: done
<mdke> guess we just have to trust them to incorporate it when its ready
<Simira> Kamion, mdke: The wiki page is made already. :)
<Kamion> thanks
<pitti> aaaargh
<pitti> JaneW: indeed, when editing the BreeyGoals page, ffox crashes
<pitti> thoooooom
<jdub> pitti: iz gtk boog
* pitti tries mozilla
<JaneW> pitti: huh really?
<pitti> JaneW: yeah, I selected the pending thing from your bar, and tried to paste it into a cell, then booom (twice so far)
* seb128 kicks jdub 
<trulux> oops
<Nafallo> time for schoolwork :-(
<Nafallo> bbl
<trulux> I'm getting this with a new USB Mouse which is working well in my Ubuntu box: hub 3-0:1.0: Cannot enable port 1.  Maybe the USB cable is bad?
<trulux> hah
<trulux> hey pitti 
<JaneW> pitti: weird, I removed all flash installations and mine has been fine... I got the colour codes from GIMP Image editor...
<pitti> Hi trulux 
<pitti> JaneW: mozilla works fine for me
<JaneW> pitti: any idea what could becausing it? Other than XP-like colours ;)
<trulux> pitti: howya? btw, do you know on the USB mouse/hid problem?
<pitti> JaneW: no idea, that's a question for our mozilla maintainer *duck*
<pitti> trulux: no?
<JaneW> heh
<trulux> pitti: just if you have experienced it
<pitti> JaneW: indeed, I have the flash plugin installed
<JaneW> pitti: hmmm
<pitti> trulux: I have a usb mouse, works fine
* JaneW sees colours on the Breexy page - thanks guys :)
<trulux> pitti: never seen that?
<JaneW> Breezy even
<pitti> trulux: "that" == ?
<Lathiat> trulux: could be bad mouse, bad cable, bad usb port or drivers fighting over usb1/usb2
<ogra> bad karma...
<Lathiat> heh
<trulux> Lathiat: possibly the drivers issue, what do you think that would be best to do? (the mouse works, but it doesn't right now :D)
<trulux> pitti: no worries, will check a few things
<pitti> seb128: btw, would it be possible somehow to add gnome-volume-manager to the gnome-session? that would eliminate the need for the buggy reconnection patch
<Lathiat> trulux: try it on another machine, tyr another usb device on the same port
<pitti> brb
<trulux> Lathiat: works
<pitti> seb128: package is uploaded, let's see what breaks :-)
<seb128> cool
<seb128> maybe a buildd will try to build this one :p
<JaneW> whiprush: ping
<mjg59> Kamion: Around?
<Kamion> mjg59: yeah
<Lathiat> hrm the fixed bug where natuilus keeps rethumbnailing changing video files has regressed
<mjg59> Kamion: www.codon.org.uk/~mjg59/tmp/hp.tar.bz2 has three packages - how easy would it be to build a Hoary CD image containing them and all their dependencies, and have them installed by default?
<Kamion> mjg59: for me to do it, or for you? :-)
<mjg59> Kamion: Well, with working apt authentication, so probably for you :)
<mvo> Kamion: I have a patch to "unauthenticate" cdroms again btw
* lamont watches stuff pile up behind hal
<Kamion> mjg59: 'k, I'll do that
<mjg59> Kamion: Ah, also the syslinux command line needs "reboot=b" adding to it
<mjg59> Kamion: Hang on, I'll send you a mail
<Kamion> mjg59: on boot from CD, or first boot into installed system, or both?
<mjg59> On boot from CD
<Kamion> that's straightforward
<Kamion> but yeah, send mail so I don't lose it :)
<mjg59> Oh, cock, except the video switching stuff is playing up now
<Kamion> i386 only, right?
<whiprush> JaneW: pong!
<mjg59> Kamion: Yeah
<ogra> whiprush, nice blog entry  :)
<whiprush> heh
<mjg59> Kamion: Sorry, I've just found that there's still a problem with the video change stuff - I'll let you know once it's sorted
<\sh> ogra: url pls need to adjust m 
<\sh> my aggregator ;)
<ogra> \sh, http://www.whiprush.org/
<chmj> whiprush, holly potatos
<Kamion> mjg59: no problem
<\sh> i should make an "unofficial ubuntu planet" for all the others who r not on planet.ubuntu.com ;)
<ogra> The Fridge !
<Treenaks> Teh Firgde!
<seb128> elmo: around?
<ogra> aww
<Lathiat> THE! FRIDGE!
<Lathiat> haha
<\sh> where is it?
<Lathiat> check your kitchen
<ogra> \sh, nonexistent yet
<\sh> ogra: why do u scare me then? i'm shivering all over ;)
<ogra> but here is a picture of it: http://udu.wiki.ubuntu.com/TheFridge
<\sh> ogra: yeah..have it in my bookmarks already ;)
<ogra> \sh, whiprush and jdub are the guys to get in contact with, if you want to help
<\sh> ogra: remember the discussion this afternoon?
* dilinger laughs
<ogra> this afternoon ? nope...
<dilinger>  "Slashdot for Ubuntu"
<ogra> yeah
<\sh> ogra: about drupal for thefridge?
<ogra> ah, yeah
<ogra> i remember now
<ogra> didnt know it was about the fridge....
<jdub> dilinger: ugh, no :-)
<\sh> i should finish my BYOPS project ;)
<\sh> time time time i need time
<\sh> coffee 
<dilinger> jdub: it's in the spec ;p
<lamont> .libs/gsf-input-bonobo.o(.text+0x3c): In function `gib_synch_shared_ptr':: undefined reference to `CORBA_exception_init'
* lamont wonders idly if libgsf is seb128 's or not
<ogra> lamont, mono ?
<ogra> err..
<ogra> nm
* lamont shrugs
<lamont> like I actually read the package descriptions before I bug seb128??? :-)
<ogra> (gsf-sharp is the mono thing...)
<ogra> heh
<seb128> lamont: yep, I've asked the sync
<seb128> lamont: ftbfs?
<lamont> 1.12.0-1 is FTBFS
<seb128> bah
<seb128> still pkg-config crap
<seb128> same as file-roller
<seb128> and other stuff
<lamont> a collection of undefined refs, all with "CORBA_" in the symbol name
<seb128> that's going to be fixed soon
<lamont> ok.
<lamont> I'll have bunch of stuff to give back once you tell me to 
<seb128> right, I've a list
<seb128> all the stuff apt wants to downgrade here :p
<seb128> anyway I'm away for ~1h, bbl
<lamont> heh
<lamont> have fun
<pitti> bye guys, cu tomorrow
<Kamion> hmm, I think I'm going to drop power3 from the powerpc CDs
<Kamion> they're overflowing, and that's a good candidate for dropping
<Kamion> after that, I look at languages ...
<^rob^> Kamion: do you know if there is any util to automate dealing with thee CUDA chip on PowerPC?
<Kamion> no idea
<Kamion> I have my cdimage hat on here, not my powerpc hat :)
<^rob^> BreezyGoals has a powermanagement gui task right?
<mjg59> ^rob^: Yes
<^rob^> would that be the place for it?
<^rob^> I guess GnomePower  probably
<mjg59> CUDA = ?
<^rob^> mjg59: it's the chip that controls the low-level clock, power management, etc on G4s and above
<^rob^> http://lists.terrasoftsolutions.com/pipermail/yellowdog-general/2004-August/015191.html
* mvo is away for ~1-2h, bbl
<ajmitch_> bye mvo 
<mdz> jdub: no, the thing I was asking kiko about was the status box on the enter_bug page
<mjg59> ^rob^: Ugh. I think that's excessively specialised for the default power management setup.
<^rob^> mjg: well "Restart automatically after power failure" has to live in userland on PowerPC
<Kamion> um ... no it isn't G4 and above
<^rob^> Kamion: at least, earlier as well?
<Kamion> This includes many m68k based Macs (Color Classic, Mac TV,
<Kamion>           Performa 475, Performa 520, Performa 550, Performa 575,
<Kamion>           Performa 588, Quadra 605, Quadra 630, Quadra/Centris 660AV, and
<Kamion>           Quadra 840AV), most OldWorld PowerMacs, the first generation iMacs,
<Kamion>           the Blue&White G3 and the "Yikes" G4 (PCI Graphics).  All later
<Kamion>           models should use CONFIG_ADB_PMU instead.
<Kamion> only one G4 model
<^rob^> hrmm
<Kamion> and only two of those models are supported by us at all at the moment
<^rob^> wowzers
<mjg59> ^rob^: There's an argument for it to be configurable, but I don't think that it follows that it should be in user-level GUI setup
<^rob^> mjg59: can that be set from OF?
<mjg59> The CUDA stuff? No, it looks like it needs to be done under Linux
<^rob^> but what replaced CUDA in the newer stufF?
<mjg59> I've no idea
<Kamion> PMU
<^rob^> ahh
<^rob^> (sorry, I ment to google CONFIG_ADB_PMU but got a phone call and my brain out the window ;)
<koke> hey, I have a patch for lintian
<koke> should I upload or contact to mvo?
<koke> http://www.amedias.org/~koke/patches/lintian_add-breezy-as-valid-distribution.diff
<koke> it's quite simple :D
<Kamion> koke: yep, go ahead and upload that
<koke> ok
<astharot> ciao
<Kamion> koke: might want to check linda as well in case it hasn't been done yet
<Kamion> yay for NIH
<hussam> anybody here using breezy, I have a question
<hussam> I want to install dbus-1-utils from breezy, but it requires libdbus-1-1
<hussam> if I try to install libdbus-1-1, it says it has to remove everything including gdm
<hussam> any thoughts?
<Kamion> dbus is in the middle of a transition in breezy right now
<Kamion> if you want it to work, don't use breezy :-)
<^rob^> mjg59: do you know of any utils at all for setting pmu options?
<mjg59> No, I don't own any hardware with PMU capabilities
<Kamion> pmu> pbbuttonsd is supported
* lamont back in a while - errands
<hussam> Kamion: will the dependencies be uploaded later?
<Kamion> hussam: it's in progress.
<Amaranth> could someone in #ubuntu's access list op me again?
<Amaranth> seems i'm the only one active
<Amaranth> nevermind :)
<koke> Kamion: it seems linda is ok
<mdke> did anything come of the "community members get ops" idea?
<mdke> Amaranth, ^
<Amaranth> mdke: i missed the meeting
<Kamion> it's supposed to happen AFAIK, hasn't been implemented yet
<mdke> damn
<mdke> i clicking something in xchat which has ruined the window
<mdke> Be RiGhT bAcK
<Amaranth> wtf was that?
<Kamion> eek
* Kamion hits a weird corner case in germinate
<Kamion> if it helps one understand the code, is drinking on the job a bad thing? :-)
<Amaranth> hehe
<Amaranth> was the original author drunk when he wrote it?
<Treenaks> Kamion: well, if crack is allowed.. ;)
<Kamion> Amaranth: I think any possible answer to that would be slandering Keybuk
<Mithrandir> Kamion: it's not called "drinking on the job", it's called "protecting the brain cells from permanent damage"
<diamond> seb128: sorry 'bout filing a duplicate bug. my search of bugzilla didn't show up anything, musta given bad terms
<seb128> diamond: np
<seb128> that happens to everybody ;)
<sm> by god you're right Mithrandir
<Keybuk> Kamion: which bit doesn't make sense?
<Kamion> Keybuk: I just hit a nightmarish corner case in the bit that checks kernel-version: for udebs, which propagated its way out to stuff like reverseDepends() (which I've never had to look at much before)
<Kamion> Keybuk: in fairness, though, about 75% of the code involved was code I wrote, and I've worked it out now :-)
<Keybuk> if it's any consolation, most of it doesn't make sense to me anymore either ;)
<Kamion> di_kernel_versions was always a nasty hack - I just had to make it per-seed rather than global
<Kamion> not surprised
<Kamion> (since now I want to have a different set of valid Kernel-Version: headers depending on which seed you're coming from)
<Keybuk> I wasn't drunk when I wrote it, however it is a pretty good example of genetic engineering by human hands
<Keybuk> I pretty much randomly added and removed code until it gave the right output with the right input
<Keybuk> there were one or two bits which were clearly broken, yet worked
<Kamion> ... and I adopted exactly the same approach without consulting with you on it
<Keybuk> so I just left it like that
<Keybuk> well, you know what they say
<Kamion> you're not thinking of the "great minds" half of the proverb, I'm betting. :)
<dholbach> re
<Keybuk> no, I was going for the "fools seldom differ" bit
<Kamion> ok, well that worked, with the exception of a few spurious diffs to 'provides'
<Echylo> hah
<Kamion> and I have no plans to try to figure out what those are about
<Keybuk> it's trying to communicate
<Keybuk> perhaps germinate is becoming some kind of oracle
<Kamion> "help, I'm stuck in a Python script and I can't get out"?
<Keybuk> like when it was continually trying to put KDE in main, it was just predicting the future
<Kamion> oh, yuck, I think I might need to teach the Germinator about supported, actually
<Kamion> (as opposed to the germinate main() wrapper)
<fabbione> doko: are you kidding me?
<fabbione> another gcc-3.* upload?
<fabbione> doko: is that supposed to fix the libvtest3 thing?
<doko> fabbione: last one, bringing g77-3.4 to the default
<doko> fabbione: no, my test build is still running
<fabbione> doko: ok...
<fabbione> that means at least another upload :/
<fabbione> did you see the log file, didn't you?
<doko> the one for sparc ?
<fabbione> yes
<doko> yes, I did see it
<codestring> hi
<bluefoxicy> I need to stop writing shit on wikis.
<bluefoxicy> whenever I comment I actually have to make a whole section for my comments
<bluefoxicy> because I leave like 80 pages of comments.
<doko> elmo, mdz: I've put a list of source packages to freeze (when we start) at chinstrap:~doko/cxxapps-20050511.log
<fabbione> doko: when do you plan to switch ?
<doko> we'll discuss it in some minutes (18:00 UTC) on #ubuntu-toolchain, later then with the MOTUs
<fabbione> doko: ah ok
<fabbione> doko: can you kindly let me know when that will happen?
<fabbione> i think i will need to stop the sparc buildd to switch defaults manually
<fabbione> and restart after packages will be blocked
<doko> yes, will do
<fabbione> thanks
<doko> btw, see https://www.ubuntulinux.org/wiki/BreezyToolchainTransition
<doko> could you check an xorg rebuild, when all build deps are there?
<fabbione> doko: sure.. i will as soon as it's ready
<fabbione> doko: so during the transtion all the rebuild will be done in background?
<fabbione> or will it happen smoothly?
<doko> what do you mean with "background"?
<fabbione> i read that uploads will be closed
<fabbione> or closed only for c++
<fabbione> ?
<doko> but only for new sources and a list of packages found in the wiki. exactly
<fabbione> ok and these packages will be uploaded and accepted manually during the transition?
<fabbione> or will they be rebuilt in "background" and uploaded all at once in the archive?
<doko> as I did understand elmo, they should be accepted, but do not go to the buildd's
<doko> maybe we can have an exception list, or drop packages from the list during the "freeze"
<doko> fabbione: btw, the 3.4 build installs fine on sparc ... (at least when built on unstable)
<fabbione> doko: you broke it on ubuntu :(
<doko> that _is_ the ubuntu package
<fabbione> did you try the old version? or only the new one?
<doko> 3.4.3ds1-13ubuntu1
<mjg59> Why does the beagle package have no useful dependencies?
<fabbione> doko: that one fails here
<fabbione> doko: can you bootstrap a breezy chroot on that machine?
<fabbione> i need to go away pretty soon
<doko> fabbione: yes, if I find some time ...
<fabbione> ok
<Amaranth> mjg59: sh_clilibs is broken or something
<Amaranth> mjg59: I can't remember the details.
<Amaranth> err, cillibs?
<mjg59> Ah
<mjg59> It doesn't even depend on mono, which isn't a great start :)
* #ubuntu-devel  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
<luis_> mako: hey, do you know if there is anyone (outside of RH) formally stockpiling patents for Free Software?
<Riddell> mdz: I've uploaded a new knetworkconf which just fixes the current one
<mdz> Riddell: excellent, thanks.  can you send me a mail to remind me about it?  I'm in a meeting
<Riddell> sure
* mjg59 gets errors about gnome-sharp not being able to be loaded
<sladen> luis_: Eben was talking about it at LCA.  Probably the person to ask
<Amaranth> mjg59: get libgnome-cil
<mako> luis_: unless you count the companies that are setting them asside for use in free software projects, i don't think so
<sladen> luis_: Raph (of Ghostscript fame) has several
<mako> luis_: i think the SFLC may be interested in getting a few
<mako> luis_: i will meet with eben tomorrow.. i can ask
<ogra> mjg59, mono is totally broken hatm... i'll have it in shape till the weekend i hope
* Amaranth wants to get a patent on typing with one hand
<Amaranth> someone got a patent for swinging sideways on a swing, so i figure i have a shot
<ogra> mjg59, you can install the beagle build deps, that helps
<luis_> mako: please do... nothing serious, but I read a sci-fi short story recently where the main character donates all his patents to a Free Intellect Foundation, and realized that AFAIK that couldn't really happen in real life
<luis_> which seemed a shame
<mako> luis_: you could donate them to pubpat
<mako> luis_: they do the patent commons stuff
<mako> luis_: i'm not sure how many people have given patents to them... but you could
<mako> they'd take them
<luis_> huh
<luis_> cool
<luis_> now I just have to have an original thought ;)
<bluefoxicy> http://udu.wiki.ubuntu.com/OEMRescue  Have you ever worked in a computer repair facility?
<bluefoxicy> "I have a virus" "Erase your whole hard drive and reinstall Windows"
<bluefoxicy> "My OS won't boot" "Erase your whole hard drive and reinstall Windows"
<bluefoxicy> "I have spyware and spysweeper didn't remove it" "Erase your whole hard drive and reinstall Windows"
<bluefoxicy> I can go on and on with this for several hours if you'd like.
<mako> luis_: nah, dude, it's overrated
<mako> luis_: i don't actually believe in them
<mako> luis_: but that's another conversation
<bluefoxicy> In a Unix system it's ALWAYS possible to either A) repair the system (erase it and only it and reinstall, don't hurt the users' data); or B) Repair or erase a certain damaged configuration in a certain user's profile to get an application working again
<bluefoxicy> it NEVER requires a complete hard disk erasure.
<bluefoxicy> So why is there shit in the  Breezy 
<bluefoxicy> roadmap that encourages erasing all data and reinstalling without even attempting to actually FIX whatever problem occurs when we can do MUCH better?
<luis_> mako: heh
<luis_> mako: should have put quotes around 'original' :)
<bluefoxicy> Is this one of those "oh well we're minorly better than MS so we don't have to actually do anything right" things that people come up with
<evarlast> bluefoxicy: i agree with you, given enough time to do your steps A or B above, but those are often time consuming and time costs lots of $$$, so the MS approach is often cheaper.
<mjg59> bluefoxicy: Have you actually read the rationale?
<\sh> _AND_ you have to make a difference between a server and a workstation. normal users don't have a separate home partition 
<bluefoxicy> evarlast:  separate /home directory.  System's broke, dump the system back to /, user's config and files stay fine.  User configuration is broke, wipe user's home directory.  Important data can be stored in say /home/shared (chmod 01777 /home/shared here) by the user for a "backup".  More complex things can be handled as time progresses.
<evarlast> bluefoxicy: you are already WAY past a level that my Mom can understand.
<bluefoxicy> mjg59: "OEMs will want to provide a way for users to return an installed system to a pristine state. This is mainly to reduce support costs as they can ask the user to just return the system to its shipped state and restore data from backup."  == "encourage bad practices and lack of data availability" (data availability == security; having to back up everything when your system is broken is not data availability, especi
<bluefoxicy> ally if you don't happen to have a dvd burner to burn most of your massive 80 gigabyte / partition to)
<Kamion> bluefoxicy: it's not about whether *we* want to do things right, it's about whether OEMs we want to persuade to base their stuff on Ubuntu are going to want this anyway; if we don't implement it, they will
<bluefoxicy> evarlast:  Yes and the beauty of it is she just has to hit "rescue" or "Fix this user" or "An application won't start:  Web Browser"
<bluefoxicy> Kamion:  OEMs count on people to be sheep.
<Kamion> and I'd appreciate it if your contributions to this channel were less abusive
<bluefoxicy> well after watching several people lose important data for no apparent reason and running for over a year and a half having damaged my system, what, 20 or 30 times and having to reinstall and not having said problems, I feel that such utter crap is abusive to the user base.
<Kamion> I don't think OEMRescue precludes a separate /home
<\sh> bluefoxicy: even in datacenters is much cheaper to have the data separated and the system is easy to reinstall
<Kamion> and it would be pretty trivial for an OEM to set things up that way
<evarlast> bluefoxicy: sounds nice, but often time a "system" is messed up as far as an end user is concerned, but really it junk in ~/ causing the problems, a nasty ~/.gnome entry or the like.  I think there is good reason to do both.
<bluefoxicy> evarlast: I've considered that already.  The only real obstacle is labeling and grouping individual problems in such a way that a user can figure out what his problem is, and having fixes for the most common cases.
<\sh> bluefoxicy: but on a "private housewifes" laptop, you can forget about separating partionions....and if you check installations of windows xp from OEMs you will see the same afford 
<bluefoxicy> Kamion:  yeah but a separate home in itself doesn't allow the case of a broken ~/ to be fixed with a quick system restore.
<Kamion> bluefoxicy: that's a pretty trivial matter for the rescue application
<bluefoxicy> \sh:  I know, I've erased enough peoples' schoolwork and movies and pictures and games and important data due to windows xp being on a 200 gigabyte C:
<Kamion> you could easily have a button that goes rm -rf ~/.[^.] * or equivalent
<bluefoxicy> oy
<bluefoxicy> anyway
<Kamion> or whatever
<Kamion> the point of OEMRescue is flexibility
<Kamion> it's providing a base on which OEMs can select whatever options they want to provide
<Kamion> s/on/from/
<bluefoxicy> yeah, the presentation on the wiki indicates as much flexibility as the compaq system restore CDs
<\sh> bluefoxicy: well...I'm not talking about obsolete data..I'm talking about data which is important to have to be backuped
<Kamion> I'm not familiar with the Compaq CDs, so I can't tell what that means
<bluefoxicy> Kamion:  put the CD in, press F11, hit Y, it erases your partition table, recreates it, formats shit, and starts dumping files on the drive.  One execution path possible.
<\sh> kamion: put the cd in, format everything, install image, ready for use again ==> data loss
<Kamion> bear in mind that the wiki notes were written in a spare three-quarters-of-an-hour while being hurried to go and do other stuff
<Kamion> so levelling vitriol at them is not productive :-)
<bluefoxicy> Kamion:  donaldson?
<Kamion> huh?
<bluefoxicy> vitriol
<Kamion> you are making no sense
<bluefoxicy> nvm
<Kamion> I'll bear your comments in mind, but it would be nice if I didn't have to wade through so much flamage in future :)
<bluefoxicy> I flame when I'm flamingly angry
<Kamion> well your flaming makes the people you want to convince flamingly angry, so it's not really useful
<Kamion> take a deep breath and count to ten. :-)
<mjg59> Anyone here running on a Dell laptop?
<\sh> or write a wiki page, where you can correct the objections of the OEMrescue ;)
<sabdfl> bluefoxicy: could you send me that code of conduct url again please? ;-)
<bluefoxicy> sabdfl:  I can't remember
<Kamion> \sh: comments at the end of that page as he did are fine, certainly
<\sh> Kamion: this way or the other :)
<sabdfl> bluefoxicy: clearly ;-)
<mjg59> Ah, Dell hotkeys seem to be keycodes. Good.
<\sh> mjg59: is there no kbd profile for dell laptops?
<mjg59> \sh: No idea
<\sh> mjg59: check xorgconfig or something...there should be one
<mjg59> Oh, urgh. No, we don't really want to do it through X.
<mjg59> The Right Way(tm) is to have the hotkeys bound to the standard input keys
<\sh> mjg59: for hp/compaq nc6000 i'm using compaq armada layout and only kde can use the special keycodes ;)
<mjg59> \sh: The 61x0 and 62x0 work fine, as long as you set the keycodes first
<\sh> like mute/unmute inc/dec volume
<\sh> mjg59: via Xmodmap?
<mjg59> No, setkeycodes
<\sh> oh ok
<Kamion> I've split out OEMRescue on BreezyGoals and marked it Drafting, so I remember to go back to it
<mjg59> \sh: See include/linux/input.h
<mjg59> \sh: Basically, the problem is that there are standard keycodes for all of this, but we don't have standard scancodes
<mjg59> So on a per-machine basis, we need to bind the scancodes to the keycodes
<\sh> understand
<\sh> mjg59: possibility to have it automated?
<mjg59> Based on DMI information, possibly
<mjg59> But at some stage, we still need to write a big table of key/scancode mappings
<mjg59> Ooh, at least Dell seem to be consistent
<\sh> hmmm...someone read about novells security solution apparmor?
<mdz> seb128: around?
<kiko> ah, the joy of 5000 channels
<mdz> kiko: you aren't fooling anyone; you're in all of 4 channels
<seb128> yep
<mdz> kiko: I desperately want to have all bugs come in as UNCONFIRMED by default
<mdz> even if the user is REALLY SURE that their problem doesn't need to be confirmed
<kiko> even for colin, mdz and seb128?
<seb128> and I want to get UNCONFIRMED to WHATEVER working
<kiko> just remove editbugs from everybody. that's the trivial solution.
<mdz> kiko: I don't want to make it harder
<mdz> and I don't want it to have side effects
<mdz> like making it impossible to change bugs
<kiko> if the user doesn't have editbugs, he can't post NEW bugs.
<kiko> ah.
<mdz> can't we just hide the form element?
<kiko> mdz, have you followed up on NEW bug-filers and asked them if they changed the option manually?
<mdz> kiko: no
<mdz> but I have tested that new bugs default to UNCONFIRMED if I don't touch anything
<seb128> mdz: I don't really get what we win with UNCONFIRMED
<mdz> it seems likely that the user sees the form field, and says "of course it is not unconfirme,d I have confirmed it myself" and they change it
<mdz> seb128: it lets us mark real bugs, to separate them from the huge volume of noise
<kiko> seb128, it will also allow the massive community QA effort ogra is going to lead do this work for us. 
<seb128> mdz: hum, right, that allows us to have bug confirmed but not assigned
<kiko> (did I say massive? I meant EARTH-SHAKING)
<seb128> ;))
<mdz> ALL-ENCOMPASSING
<kiko> (only managers type in caps)
<kiko> and top-post.
<kiko> mdz, it's trivial to hide the form element.
<mdz> sshh, there are top-posters in the channel
<mdz> kiko: I think that's the solution with the least tradeoffs at this point
<kiko> mdz, okay, I'll send you a patch.
<seb128> you rock kiko 
<kiko> and one to fix seb128's probem
<seb128> rock rock rock :)
<mdz> that would be awesome
<seb128> kiko: and when that's done, can you fix malone for me too please ? :)
<kiko> okay. let me get down to it. in 1:15 we should talk to ogra about the QA, be around
<kiko> seb128, the sab doesn't let me :-(
<seb128> ;(
<mdz> seb128: that is BradB and bjornT's job
<seb128> mdz: yeah, was just joking
<kiko> I wasn't 
* Kamion fixes most of germinate and cravenly works around the remaining problem in the seeds
* ogra comforts kiko a bit
<seb128> mdz: I've pinged BradB with some issues already, the current malone is scaring
<Kamion> I think powerpc should fit now, just about; new images building
* kiko gets bugzilla running on his box
<mdz> seb128: perhaps kiko should be CCed on those mails
<mdz> seb128: I hear he needs more mail
<kiko> yes, please CC me
<seb128> mdz, kiko: ok :)
<kiko> seb128, do you know if Date::Format is packaged in ubuntu?
<kiko> seb128, answering that gets you patches faster
<seb128> libdate-simple-perl - a simple date object for Perl ?
<elmo> usr/share/man/man3/Date::Format.3pm.gz                      perl/libtimedate-perl
<seb128> I picked the wrong one :p
<seb128> elmo wins :(
<elmo> FLAWLESS VICTORY
<bluefoxicy> ok perhaps it's time I quit my job and open my own business so I'll have more free time to actually write software instead of do 10 minute mock-ups
<kiko> seb128, elmo, what do we need to do to update the description of that package to include Date::Format in it?
<seb128> kiko: send a bug to the Debian BTS ?
<kiko> seb128, hmmm. okay. don't imagine you could do it for me? :)
* kiko blackmails seb128 
<seb128> kiko: I could
<seb128> I'll not :p
* seb128 runs
<kiko> bah
<kiko> the issue is that: 
<seb128> k, I'll 
<kiko>  - Date::Format is required by Bugzilla and a few other major packages
<kiko>   - Finding it is currently difficult because it doesn't show up in the description for the package
* kiko installs 10th package to get bugzilla running
<seb128> kiko: apt-get install bugzilla?
<kiko> seb128, I could do that, I guess, but I imagine your version is more recent than the 2.16/17 that's packaged.
<kiko> (so dependencies have changed)
<seb128> kiko: you will get a list of package it wants to install
<seb128> then you can "apt-get install <list of package>"
<kiko> I know
<kiko> <kiko> seb128, I could do that, I guess, but I imagine your version is more recent than the 2.16/17 that's packaged.
<kiko> <kiko> (so dependencies have changed)
<seb128> and not look where is Date::Format 
<seb128> ups
<kiko> yeah, that would have worked for date:;format, good point. still, I think fixing the description is correct.
<seb128> 2.18 is the universe version
<seb128> I don't expect a big depends change to 2.19
<kiko> yeah, updated a week ago, wasn't it?
<seb128> agreed for the description
<seb128> oh right, fresh sync from debian yep
<kiko> neat
<Kamion> night all
<kiko> hmm
<kiko> somebody tell me
<kiko> how do I do mysql administration on ubuntu?
<evarlast> kiko: not a -devel question, try #ubuntu - also just install mysql and run 'mysql' maybe as root - for gui type administration try installing phpmyadmin.
<dholbach> poor kiko :-)
<kiko> heh
<kiko> I don't think we use root as the mysql superuser, but IMBW.
<sladen> mjg59: should that table include wifi
<chmj> hey sladen
<kiko> heya sladen 
<kiko> how did sydney treat you?
<kiko> to good falafel no doubt.
<sladen> hello chmj and kiko.
<sladen> kiko: I was all well and happy but it sounds like various other people left with a flu...  Melbourne was a bit boring aside from the LUG :-)
<kiko> oh @#!@#!@#
<kiko> who would know. 
<kiko> pitti!
<kiko> no pitti.
<kiko> mdz, who can give me fast mysql support?
<sladen> jbailey: java is being talked about in #ubuntu-meeting
<mdz> kiko: as in, quickly answer questions about mysql, or provide you with a high-performance mysql setup?
<kiko> the former
<mdz> kiko: I can
<kiko> I want to know who the mysql superuser is on ubuntu
<mdz> phone
<mdz> kiko: root
<mdz> no password by default
<kiko> no password?
<kiko> ah.
<kiko> thanks.
<jbailey> sladen: Thanks, which meeting is it?
<bluefoxicy> breh
<bluefoxicy> who has amd64 and wtf do I use to play video on it
<bluefoxicy> because totem-gstreamer is absolute trash (as in laggy, out of sync, freezes often) and xine won't work on amd64 due to segfaults probably caused by the xine team expecting R 
<bluefoxicy> R==X personality from x86
<bluefoxicy> oh yay mplayer works (after complaining about missing ttf files)
<mjg59> Anyone here and running on a Dell laptop?
<elmo> FATAL:  XX000: failed to initialize lc_messages to ""
<elmo> LOCATION:  InitializeGUCOptions, guc.c:1867
<elmo> anyone seen that with postgres?
<Mithrandir> bluefoxicy: I'm using mplayer.
<dholbach> totem works fine on amd64 for me
<ogra> for me too
<bluefoxicy> dholbach:  try playing an mpeg
<dholbach> i did
<bluefoxicy> it'll constantly change how long it is, ie it'll start a 3 minute video and it'll then say it's 30 minutes, then 4 seconds, then 2 months long, then an hour, then 10 minutes. . . 
<bluefoxicy> try seeking through that
<bluefoxicy> and if you manage to seek around mor ethan 3 times it freezes.
<bluefoxicy> been like that since warty, persists through reinstalls, reproducible on the laptop and the desktop.
<bluefoxicy> and i had to install gstreamer0.8-ffmpeg to get movies to play at all.
<mirak> hi
<kiko> mdz, patch #1 sent
<kiko> seb128, interesting. I have a question for you.
<kiko> are you here?
<kiko> ogra, is it time?
<ogra> ah
<ogra> heh
<kiko> where are mdz, dholbach and seb128?
<dholbach> here
<ogra> dholbach, is here
<dholbach> i thought we'd meet in #ubuntu-conspiracy :-)
<ogra> mdz ? seb128 ?
<kiko> ogra, let's give them 5 minutes.
<ogra> yep
<kiko> if 5 minutes are up I'll ring matt, and you could ring seb
<seb128> ogra, kiko: what ?
<ogra> oki
<ogra> seb128, meeting
<ogra> seb128, QA
<seb128> about?
<kiko> seb128, about the end of the world, imminent, unless mdz shows up.
<seb128> meetings marathon?
<dholbach> yes
<ogra> yep
<dholbach> feels like UDU
<\sh> again?
<ogra> hehe
<\sh> qa is interessting..had some thoughts about it ;)
<seb128> dholbach: no, worst, at this time we were playing mao :p
<seb128> or sleeping
<seb128> depending on the TZ consideration
<kiko> seb128, meanwhile, I have a question to ask you.
<dholbach> or having VB :-)
* ogra looks at gworldclock
<kiko> NEEDINFO.
<kiko> seb128, that's not an "open" state is it?
<seb128> kiko: yes it is
<kiko> why?
<\sh> ogra: again in #u-m?
<kiko> UPSTREAM too?
<ogra> seb128, 6:04 ? i was never up at this time... thats when dholbach awoke ;)
<seb128> kiko: dunno how you consider open/close
<seb128> kiko: but I consider NEEDINFO as a open bug waiting on informations
<kiko> hmmmm.
<lamont> kiko: if you declare it fixed, or not-a-bug, it's closed.  otherwise it's open (aka not fixed...)
<seb128> kiko: ie, that's not a CLOSED option
<kiko> lamont, seb128: and UPSTREAM the same?
<seb128> yep
<mdz> kiko: here
<seb128> UPSTREAM is really open
<mdz> was on the phone
<seb128> that's "the bug is an upstream issue"
<lamont> kiko: yes
<kiko> mdz, oh, I double-rang you then.
<luis_> NEEDINFO should mean 'I cannot fix this without more information', which is effectively closed- think of 'open' as 'fixable' and 'closed' as 'no longer fixable'
<kiko> yeah
<kiko> luis_, do you have a custom hack in process_bug.cgi to handle UNCONFIRMED and NEEDINFO/UPSTREAM?
<doko> elmo, mdz: is it possible to remove/add packages from the list of frozen packages during the CXX transition?
<mdz> doko: I don't see why not
<luis_> obviousy it is different from actually fixed, but IMHO it is closer to closed than open
<seb128> not really
<seb128> they stay in the scope
<luis_> kiko: I think so, but honestly I don't recall- it has been a while since I looked at where that hack was
<mdz> kiko: so what's the agenda here?
<luis_> no
<dholbach> if you don't get what the reporter is trying to tell you, it will be NEEDINFO as well?
<kiko> anyway
<kiko> let's stop this discussion and start another
<kiko> I'll sort it out.
<luis_> they should never be NEEDINFOd if you can fix it with the information available
<kiko> -----------------------------------------------
<kiko> QA meeting starts here
<kiko> -----------------------------------------------
<doko> mdz, elmo: the current plan is to have the freeze next Monday/Tuesday, depending on when elmo can set it in effect
<kiko> so ogra, sabdfl mdz and I have a plan for QA in the short term
<seb128> luis_: NEEDINFO is to let a chance to provide informations before closing
<mdz> kiko: we can use #ubuntu-meeting
<kiko> hmm, you had suggested -devel, but sure
<mdz> if it's too noisy in here
<ogra> yeah, lets do that
<mdz> luis_: ->#ubuntu-meeting
<luis_> ooh, I'm invited :)
<lamont> elmo: looks like ps2eps needs to migrate to main (for gsl)
<lamont> elmo: and libevent-dev (for nfs-utils) and jikes-classpath (for gettext)
<Kamion> elmo: ... and lsb-{core,cxx,graphics} for lsb
<lamont> there will be a momentary disturbance in the force while I bzip2 all the log files
<dholbach> haha... lamont: you're great! :-)
<lamont> dholbach: for extra credit, tell me how  to have firefox automatically bunzip the data when it arrives.
<lamont> rather than wanting to invoke archive manger or whatever
<ogra> hmm, it did that once...
<lamont> there are some .bz2 files there now, I'm just bziping everything to avoid the rsync pollution that would cause elmo to kill me
<dholbach> lamont: doesnt it depend on the webserver configuration?
<lamont> well, since we don't want the server uncompressing them.....
<dholbach> but some crazy mime-type/whatever stuff? *shrug* no idea, sorry
<\sh> dholbach: you can do two things: 1. webserver sending the right mime-type and you have the right mapping, or you advise the browser/desktop gui ;) to map .bz2 with bunzip 
<\sh> second method must do the bunzip in a tmp dir and remove it afterwards
* lamont ponders, and decides that humans don't need to see the .bz2 at the end of the filename for the old logs.
<\sh> lamont: why not doing a transparent bunziping on the webserver? like the gzip method
<lamont> \sh: I suppose we could,  but the reason everyone wanted them was for bandwidth savings, and you don't get those.
<lamont> and (2) it would require a server change...
<lamont> config change
<\sh> lamont: nono...transparent gziping is a feature of the webserver and webclient...the webserver sends it as .gz and the browser tries to gunzip it
<lamont> ah, coolness
<\sh> lamont: i think there is also a bzip2 module for apache...but i think most of the webclients are not using this, but most of them can use transparant gunzip
<lamont> \sh: that's kinda unfortunate.
<lamont> bz2 is much nicer for the disk...  and we were getting kinda full
<\sh> lamont: i don't have a testbed right now for it, but lemme check tomorrow if I can get it to work on apache2 and firefox
<lamont> would be coo
<lamont> l
<uniq> the module for apache doesn't read .gz files from disk (afaik). it compresses the served files on the fly.
<\sh> uniq: you can gzip them also on disk...
<\sh> uniq: if you have gunziped files, it will gzip them, and if you have gzipped files, it will send them directly
<uniq> ok.
<\sh> uniq: problem is the client, if he can do gunzip on the fly it's ok...but then u have those nasty IEs ;)
<\sh> some versions are working, some not
<lamont> \sh: for this instance, I really only care about firefox... :-)
<\sh> lamont: well :) this is fine with me...at lycos we didn't have the choice ;)
<bluefoxicy> another detriment to gstreamer/totem
<bluefoxicy> sometimes closing totem after 20 minutes of it having finished a video will cause totem to not close
<bluefoxicy> but rather rapidly fill memory
<bluefoxicy> until your system grinds to a halt for about 10 minutes and the OOM killer catches up enough to kill totem.
<uniq> \sh: looks like apache2 only supports content encoding. mod_gzip has been converted to mod_deflate with less features.. http://tinyurl.com/a8pxt
<allee> mjg59: ping?  LaptopTesting|Hardware
<\sh> uniq: the orig mod_gzip should do this...we had it runnin on apache 1.3 ... i will check it tomorrow
<uniq> it's running on 1.3.. but not 2 :)
<uniq> I use it on 1.3 myself.
<\sh> uniq: there should be a (real) mod_gzip version for 2.x
<\sh> http://www.ehyperspace.com/apache/mod_gzip
<uniq> 404
<\sh> wow
<\sh> *headshaking*
<lamont> no one should be running 1.3 anymore
<lamont> well, except for my competitors...
<kiko> I run 1.3
<\sh> i switched to 2.x
<\sh> but this incident i have to check..mod_gzip not working anymore..:(
<doko> Kamion: maybe it's better to build a CD before Monday/Tuesday, when we start the CXX transition ...
* lamont notes that buildLogs is offline for a while (compressing log files takes a while...)
<lamont> up to 'f' (albeit with some random stuff later in the alphabet done...)
#ubuntu-devel 2005-05-20
* mvo goes to bed now
<lamont> 'h'
<lamont> g'night mvo
<mvo> night lamont 
<dholbach> good night
<kiko> night daniel
<dholbach> bye kiko
<lamont> night dholbach 
<dholbach> bye lamont 
<doko> elmo, mdz: for an announcement of the C++ transition to ubuntu-devel, please could you confirm that we can freeze C++ apps and new source packages on Monday?
<elmo> define freeze?
<kiko> place in a temperature below 0C
<elmo> POP THE TRUNK
<tseng> mjg59: well, i threatened to kick the next person to complain about mono deps in the face.. i guess thats you :D
<ogra> heh
<tseng> mjg59: monodis is broken so dh_clideps doesnt work
<ogra> tseng, no its not !
<ogra> :)
<tseng> you fixed?
<ogra> fixed...
<tseng> nice
<ogra> testbuild just finished
<tseng> you rock
<elmo> doko: (seriously)
<tseng> now we get to rebuild *
<ogra> yep..
<ogra> and look that dh_clideps has -d everywhere....
<tseng> jeez its 80F outside
<doko> freeze: no new source packages enter, no source package from a given list is uploaded
<doko> elmo: ^^^
<tseng> doko: that pretty well sucks do we get to finish with mono first?
<elmo> doko: by any one?
<ogra> tseng, c++
<tseng> i know what its about
<tseng> oh well
<ogra> tseng, mono desnt need new c++ source 
<doko> tseng: does mono depend on c++?
<tseng> oh so its not blacklisted
<tseng> i see
<tseng> the other day i thought you meant freeze on everything.
<doko> tseng: calm down ;-)
<ogra> tseng, mainly KDE :-P
<tseng> doko: heh im tired of getting 50 messages a day bitching about mono-app-X being broken
<doko> tseng: with the time you get used to it
<tseng> heh
<ogra> thats the price you pay for the Maintainer: field ;)
<tseng> people should grok the breezy field
<doko> elmo: well, we may want to allow some people to allow manual upload and only disallow new source packages being synced from unstable?
* Burgundavia hugs tseng for the great mono love
<schweeb> mako: ping
<mdke> schweeb, is it about CC? i was hustling him earlier and he said he was writing a paper for a conference
<schweeb> yea
<schweeb> it is
<mdke> he sounded busy
<schweeb> not entirely uncommon for him
<mdke> ya
<mdke> good double negative understatement
<mdke> ;)
<sladen> double plus good
<schweeb> got approved for membership at last meeting, and was wondering if there was anything else I needed to do... sent him a signed CoC back a while ago, but wanna know if he wants me to sign again for membership
<tseng> schweeb: double check with mako 
<schweeb> tseng: which is why I pinged mako, bish
<tseng> i missed that
<tseng> bish
<mdz> doko: if elmo says it can be technically impleented in time, I have on problem instituting it on Monday
<doko> s/on/no/ ?
<mdke> schweeb, i'm thinking a mail will do the trick
<doko> mdz: s/on/no/ ?
<eruin> (from udu wiki/FileManagerImprovement) "[...]  and the difficult choice between "Pictures", "Photos" and "Graphics"."  <-- isn't Pictures the obvious catch-all?
<Burgundavia> eruin, not really
<mdz> doko: yes
<Burgundavia> eruin, something I create in inkscape is not a picture
<eruin> Burgundavia: well, fair enough, but to a casual desktop user? I myself would use graphics (and I do)
<Burgundavia> eruin, what about Images?
<eruin> that's a nice one
<eruin> ;)
* mpt remembers some newspaper columnist whining about computery people using the word "images" all the time
<schweeb> mdke: that's an undesirable amount of work, since I don't have my mail client set up currently :P
<mdke> schweeb, *grins*
<mdke> priv msg then ;)
<Burgundavia> mpt, what did they suggest?
<mpt> pictures, iirc
<Burgundavia> dictionary.com says "# A visual representation or image painted, drawn, photographed, or otherwise rendered on a flat surface."
<mpt> Quite possibly the sort of people who create non-picture graphics are the sort of people willing and able to create their own folders
<eruin> that's indeed along the lines I was thinking, too
* lamont goes to celebrate the youngest ubuntu tester turning 10.
<lamont> back later
<sladen> mdz: is LiveCD/tools supposed to be empty?
<mdz> sladen: what is LiveCD/tools?
<mdz> oh, do you mean the /tools directory on the CD?
<Unfrgiven> morning all
<mdz> that's empty on both live and install
<mdz> a debian-cd artifact, presumably
<Unfrgiven> anyone else having problems with the new version of ndiswrapper?
<mdz> I think that's where rawrite and such live
<Unfrgiven> the modules won't load
<mdz> Unfrgiven: #ubuntu, please
<Unfrgiven> mdz: this is a breezy issue for a new upload.
<mdz> Unfrgiven: please?
<Unfrgiven> mdz: isn't it better discussed here?
<lamont-away> mdz: no build log updates for a couple 3 more hours...
<Burgundavia> Unfrgiven, things are broken in breezy, file a bug unless you have a fix
<mdz> lamont-away: what happened?
<lamont-away> offline so I can bzip2 everything
<eruin> has there been any recent discussion based around font hinting and similar stuff? (ie the fact that fonts turn up uneccessarily cripsy on alot of systems)
<mdz> eruin: FontHandling would be the place to look
<eruin> cheers
<lamont-away> they're still getting saved (now bzipped), but turning on the rsync now would be bad for my health, next time elmo caught up with me.
<lamont-away> up to 'k' on the compression side of things... :-(
<mdz> also, thully complains about it from time to time
<Unfrgiven> Burgundavia: well id like to write a fix but i need some more info as to what is wrong. this worked yesterday until the i got the latest breezy crack in the evening. but ok, i guess ill go to #ubuntu.
<tseng> thully complains about alot of things
<mdz> lamont-away: so this is bzip2ing all build logs?
<tseng> but refuses to learn anything.
<mdz> lamont-away: does firefox know how to un-bzip2 them on the fly for viewing/
<mdz> ?
<lamont-away> mdz: I'll have my laptop with me, if the need really arises.  otherwise, they should be done before I sleep
<lamont-away> mdz: yes.
<mdz> ok
<lamont-away> and no
<schweeb> tseng: I noticed as much
<mdz> oh
<mdz> wouldn't it be better to use gzip instead, then?
<lamont-away> yes we're bziping them all, no ffox is clueless
<mdz> it would also be a lot faster
<lamont-away> less disk savings that way - text files get pretty extreme with bzip.
<sladen> mdz: yup, the README in that directory says it contains rawrite, but there nothing in there
<lamont-away> someone was going to see how hard it was to get apache and ffox happy
<mdz> sladen: seems worth a low-severity bug report for Kamion
<lamont-away> mdz: worst case, I'll switch to using gzip once I get the master and p.u.c copy back in sync.
<lamont-away> then old will be bz2, but current will be .gz
<lamont-away> anyway, getting dragged out the door to the party
<sladen> mdz: what's kamion's email for bugzilla, I've just wiped the fabulous page out by getting it wrong
<mdz> sladen: cjwatson
<mako> schweeb: hey dude
<mako> schweeb: lemme check
<bob2> whiprush: people were sick before paul arrived in australia
<whiprush> yeah but he's a convenience scapegoat.
<whiprush> plus he was in my room so he's an easy target.
<jordi> who is paul?
<jordi> did he infect me?
<ogra> jordi, yes
<jordi> ffs
<lifeless> short guy, wide shoulders, foldaway bikeh
<ogra> jordi, we sat upstairs on the armchairs in the corridor and he coughed all the time...
<ogra> (we = you, me, him)
<jordi> nod
<jordi> fun
<jordi> so it wasn silbs after all!
<ogra> heh
<jordi> wasn't
<zul> heh...maybe you all got bubonic plague
<infinity> zul : Felt like it.
<zul> more sunlight will do you good infinity 
<whiprush> jdub: ping
<dilinger> heh
<dilinger> the 'x' key just fell off my laptop keyboard
<dilinger> soon there will be none left
<zul> you should stop looking at triple-x sites then
<tseng> zul: http://tseng.ath.cx/photos/index.php?galerie=udu&snimek=91 < he's not kidding
<zul> hehe
<dilinger> mm.. mentos
<infinity> dilinger's laptop helps make mine feel less inadequate, therefor it's a wonderful thing.
<dilinger> much like ripped jeans, one day keyboards w/ half the keys lost will be fashionable.  just you wait.
<infinity> Uh huh.
<jdub> whiprush: pong
<whiprush> got some time to talk fridge?
<tseng> whiprush: ill tell you something about fridge. if you dont get your moldy crap out of there..
<whiprush> hands off the beer in the fridge, kid.
<tseng> (i dont drink beer, remember)
<whiprush> :(
<mdz> daniels: is there a bug open somewhere already for "it'd be nice to have a desktop tool to change the default mode for X"? (cf. #10173)
<daniels> mdz: not really.  we all sort of agreed that it would kick arse if we had something similar to redhat-config-display, in oxford, but that never eventuated
<jdub> whiprush: sho'!
<whiprush> So I was thinking of trying out different stuff to get an idea of what we want to use. But elmo flinched everytime we mentioned something php based.
<jdub> heh
<whiprush> So I'm going to play with this newsbruiser thing for a bit.
<jdub> whiprush: i've started putting it together with drupal - it won't be a problem
<whiprush> and start "practicing" what entries would look like
<jdub> newsbruiser is just a blog hosting tool
<whiprush> ok.
<jdub> hrm
<jdub> actually
<whiprush> ok well if you have something setup, when it's ready give me a little sandbox and I can start playing around with entries.
<jdub> wait a sec, i'll set it up so you can play with my devel version at home
<whiprush> then I was thinking we could do like #ubuntu-fridge and have all the people interested (the guy that bought spreadubuntu.com for example), then we could start brainstorming what works and what doesn't, etc.
<whiprush> and start breaking stuff
<whiprush> then we could run it like that for a week or so, see how it feels/works, and go from there.
<ajmitch_> whiprush: as long as you put some decent stuff in the fridge for us
<jdub> so i was thinking about other funny fridge things that inspired the idea
<jdub> do you guys remember the fridge in ghostbusters?
<ajmitch_> vaguely
<whiprush> my needly little brain has been plotting fridge-content all day.
<jdub> ajmitch_: watch ghostbusters again, and watch out for the fridge ;)
<spiv> jdub: "Do you actually eat this stuff?" ;)
<jdub> :-)
<whiprush> My fridge inspiration comes from The Naked Gun.
<whiprush> When the girl goes through his fridge, and gets some chinese out ... "Didn't this place go out of business like 3 years ago?"
<jdub> ha ha
<jdub> so we totally need a page of crazy fridge references ;)
<jlje> whiprush: yeah, great line, saw that movie just a few days ago
<whiprush> How do you know if there is a reindeer in your refrigerator? The hoof prints in the butter!
<whiprush> http://www.nashken.com/cartoons/techniks/refrigerator-blue.gif
<whiprush> these puns are going to get out of control in the future. I'm telling you now.
<Lathiat> whiprush: haha
<bob2> oh man, at this hotel in sydney they had a fridge with blue leds inside it
<jdub> we should have a fridge gallery
<dilinger> bob2: they weren't VA style, were they?  stare directly at them and lose your eyesight for an hour?
<bob2> haha
<jdub> whoa
<jdub> XIP on its way to 2.6
<jdub> (article in lwn)
<bob2> what's the least crap small-business accounting thing in ubuntu?
<HrdwrBoB> gnumeric
<HrdwrBoB> :(
<Amaranth> I've found a new favorite word: fuckyouness
<Amaranth> divifund?
<bluefoxicy> tseng:  your @g.o addy still works?
<bluefoxicy> ok pop quiz, what's the best address to contact tseng at?
<bob2> the one he posts to ubuntu-devel with, presumably
<bluefoxicy> hold it I have to read one of the google results whose description starts with "Brandon hale states 'last night I stayed up all night...'"
<HrdwrBoB> divifund is a personal finance, not business finance
<Burgundavia> bob2, quasar, but I don't no if it is packaged for Debian/Ubuntu
<daniels> daniels@catsby:~/canonical/freetype% apt-get source freetype2
<daniels> [...] 
<daniels> dpkg-source: extracting freetype1 in freetype1-1.4pre.20030402
<daniels> daniels@catsby:~/canonical/freetype% apt-get source freetype
<daniels> [...] 
<daniels> dpkg-source: extracting freetype in freetype-2.1.7
<daniels> work that one out.
<Amaranth> o_O
<Amaranth> That's a little...off.
<bluefoxicy> a little bass ackwards
<daniels> oh god
<daniels> freetype2 has an I Can't Believe It's Not DBS build system
<womble> daniels: Shouldn't that be "I Can't Understand DBS So I'll Reinvent It" ?
<womble> Hmm...
* womble goes off to ITP icudbssiri
<lamont> daniels: but did freetype2 capture all the stupidity that is encapsulated in dbs?
<daniels> lamont: it embraced it and extended it
<lamont> just reading scrollback...  the source layout is, um, interesting
<wasabi> Who works on update-manager?
<daniels> mvo, IIRC
<fabbione> morning
<lamont> wasabi: mvo sounds right
* lamont back in a while - log files almost done processing... sigh
<minghua> Hi, I am setting up a breezy chroot
<minghua> It seems the version of build-essential is still 10.1ubuntu1
<minghua> So I have to wait for build-essential 11 to enter archive (or sync to mirror), right?
<fabbione> mdz: what is the proper way to update status of the specs? right now i am adding info after each point that gets implemented/tested/whatever.. but should we create a separate section for implementation status or is it ok?
<fabbione> an example is ClusterFilesystem and InstallerVolumeManager
<fabbione> Management even
* wasabi hacking up update-manager
<|QuaD-_> dist-upgrade on breezy wants to remove update-manager :)
<derek> on the laptopTeam page it pointed here
<derek> has there been any development/success in getting sound to work with dell latitude series laptops and dell port replicators?
<derek> sound works fine for me on the laptop, but when plugged into the replicator the sound outbound on replicator doesnt work
<derek> if i plug back in laptop it works fine
<derek> usb and other port replicating items appear to work fine
<Treenaks> gnome-volume-manager has a missing build-dep on bzip2
<Lathiat> why the hell does g-v-m need bzip2 to build?
<Treenaks> it contains the original source in a .tar.bz2
<Treenaks> pretty common really
<Treenaks> also check http://people.ubuntu.com/~lamont/buildLogs/g/gnome-volume-manager/1.3.1-0ubuntu1/gnome-volume-manager_1.3.1-0ubuntu1_20050511-2119-i386-failed.bz2
<bob2> ew
<Lathiat> Treenaks: ohh right
<Lathiat> thats not so bad
<Treenaks> I rebuilt it myself now -- with the right deps -- and it works fine
<g14> I found an issue with fast-user-switch-applet and esd
<concept10> g14: what apps do you work on?
<g14> concept10, When changing users with the fast-user-switch-applet, esd is already running as the first person
<g14> concept10, so sound does not whatsoever for the second user. I believe ajmitch_ is working on fusa for ubuntu
<g14> concept10, http://ignore-your.tv/fusa/
<concept10> alright, checking it out
<g14> concept10, thanks. There are debs available from http://ankur.ath.cx/ubuntu/fast-user-switch-applet/
<concept10> g14: 
<g14> concept10, yes?
<concept10> g14: oops sorry, anyway - im trying to bring some of the redhat tools over to ubuntu as posted on the ubuntu goals, but Im not too familiar with ubuntu/debian, but I almost have one of the requested tools working
<g14> concept10, All of the system-config stuff? That would be awesome
<g14> concept10, what do you have almost working?
<concept10> yeah, I been primarily a fedora and red hat user but I like ubuntu, I have it installed on one of my development box
<concept10> system-config-services
<g14> concept10, I've used redhat since redhat 5 when it used gnome with enlightenment as the wm *shudders*
<g14> just started using ubuntu a few months ago
<concept10> I lost my internet connection earlier
<g14> And love it
<g14> thats fine
<concept10> so you are familar with all of the system-config tools? I would like to get them working in one wrapper
<g14> I am familar with most all of them
<g14> Even the obscure ones like system-config-netboot
<g14> concept10, Why one wrapper? They should be seperate packages
<concept10> You think so?
<g14> Why would I want an apache configuration tool on my dns server?
<g14> theoraticly
<concept10> Im not talking about wrapping all, just some tools that relate
<g14> Like what?
<concept10> I have no plan yet
<concept10> I just think that system-config tools should be in one wrapper. Kind of like mandrivas tools, but not as noobish as mandrake
<mdz> fabbione: it is fine to update the existing status column in the table
<g14> Concept yast is the all in one admin tool
<jsgotangco> hello
<concept10> yast2 is gpl'd now, how do you like it?
<g14> concept10, They have a yast4debian project, but its not very mature
<g14> I like the very similar gui and tui interfaces
<concept10> g14: http://udu.wiki.ubuntu.com/GraphicalConfigTools
<g14> brb
<concept10> me too.....
<infinity> mdz : Would anyone (you?) scream loudly if I suggested adding "smbfs" to the desktop seed?
<Lathiat> but all applicatiosn should support gnomevfs!
<g14> Great idea, add gnome-vfs support to cp and mv </troll>
<Lathiat> gnomevfs-cp !
<g14> No, just submit the patches to gnu
<g14> RMS would have a heartattack
<jsgotangco> ogra hey
<doko> morning all
<fabbione> hi doko
<fabbione> specially for the fun of trying :P
<fabbione> ops
<ajmitch_> hi doko, fabbione 
<fabbione> elmo, thom: can you please install xmlto on halley/hoary chroot?
<fabbione> (or see if you can bootstrap a breezy chroot)
<cartman> anyone knows if its possible to provide non-nptl setup for amd64 machines in breezy ?
<mdz> infinity: I'd say that it should probably be discussed on the mailing list first
<bob2> cartman: chroot
<fabbione> cartman: i doubt...
<bob2> I'm almost ceetain amd64 has never supported linuxthreads
<fabbione> you will need old glibc
<cartman> bob2: without that I mean native 64bit one
<bob2> Mithrandir: does amd64 support linuxthreads at all?
<cartman> ah
<lifeless> minghua: AIUI yes
<cartman> http://www.mathworks.com/support/solutions/data/1-QVND8.html?solution=1-QVND8 <-- why I ask
<lifeless> bob2: erm, inversion - I meant no.
<fabbione> elmo, thom: can you also please update binutils on concordia/breezy chroot?
<fabbione> meh
<fabbione> elmo, thom: xmlto on davis/breezy chroot please :)
<minghua> lifeless: thanks
<lifeless> minghua: uhm sorry dude, I was answer bob2. my fingers fouled
<minghua> lifeless: Err, okay. :-)
<fabbione> doko: can you /j #ubuntu-kernel please
<pitti> Morning
<doko> morning pitti
<doko> does the wiki on ubuntu has a page documenting the moin wiki format?
<pitti> Hi jsgotangco 
<jsgotangco> pitti hey
<Mithrandir> bob2: no.
<Mithrandir> bob2: it's nptl only
<Mithrandir> bob2: at least in Debian and Ubuntu, I don't know about RH and SuSE.
<cc> Mithrandir: fedora/rh is nptl only. no more linuxthreads (if that was the Q)
<Mithrandir> cc: Thanks.  (And yes, that was the question.)
<fabbione> elmo/thom: can you pleae install 2.6.12 build-deps on davis/breezy-ppc64 chroot?
<fabbione> doko: i guess it is still not safe to build the kernel with gcc4, right?
<zyga> hello
<zyga> symphonyos has a torrent if anyone is interested in having a look
<Burgundavia> zyga, oh?
<Burgundavia> zyga, live or install?
<zyga> Burgundavia: live I presume
<zyga> want a link?
<Burgundavia> sure
<zyga> (it's darn fast torrent)
<zyga> http://www.symphonyos.com/torrents/btdownload.php?type=torrent&file=symphonyos-alpha-070.iso.torrent&PHPSESSID=c899b35b8b1e8f1d52ee872ae14b2d8c
<zyga> http://www.symphonyos.com/trademarks.html (policy they ask everyone who downloads to read)
<doko> fabbione: I never tried ...
<zyga> Burgundavia: it's possible to install it to disk but It's a live cd
<Burgundavia> zyga, cool, thanks
<jsgotangco> hmm
<Kamion> morning
<Kamion> doko: HelpOnEditing
<fabbione> morning Kamion
* Kamion removes language-pack-it from powerpc ... sorry fabbione
<fabbione> YAY
<fabbione> Kamion: go for it!
<fabbione> i am all high up to remove -it- .it langpacks
<Kamion> ... not the reaction I expected
<doko> Kamion: hmm, couldn't find something to escape a '] '
<doko> Kamion: so you're building a CD before Monday?
<Kamion> doko: hope so
<Kamion> few more things to sort out today
<fabbione> Kamion: did you have time to upload partman-lvm-auto?
<doko> seb128: is the naming scheme for gnome library packages (appending -#) upstream, or a Debian thing?
<seb128> debian
<fabbione> who feels very very lucky today?
<fabbione> (and has an amd64 handy?)
* toresbe ! 
<zyga> fabbione: hmmm
<zyga> fabbione: how lucky exactly?
<fabbione> zyga: a lot :)
<zyga> fabbione: what are you going to test?
<fabbione> amd64 kernel compiled with gcc-4.0
<fabbione> it might boot, it might not
<fabbione> it can eat your system or not
<fabbione> no idea
<Kamion> fabbione: not yet
<fabbione> Kamion: ok thanks
<Kamion> fabbione: might leave it 'til after Colony 1, haven't decided yet
<zyga> fabbione: just give me a package
<fabbione> Kamion: is the source in SVN? i just want to start to look at it. not to push it hard in the archive
<fabbione> zyga: http://people.ubuntu.com/~fabbione/
<fabbione> zyga: there is only one image there
<Kamion> fabbione: svn://svn.debian.org/d-i/trunk/packages/partman/partman-lvm-auto/
<fabbione> be sure to have another kernel installed to recover.. in case
<fabbione> Kamion: thanks
<Kamion> er, or not
<Kamion> fabbione: svn://svn.debian.org/d-i/trunk/packages/partman/partman-auto-lvm/
<fabbione> ehhe
<Kamion> seb128: any chance of a gst-plugins0.8 built against libflac7?
<seb128> Kamion: sure, I'll have a look now
<zyga> fabbione: fetching
<Kamion> ta
<pitti> elmo: imagemagick sync, please
<fabbione> Kamion: i did an attempt to debootstrap breezy.buildd on sparc and i got a few missing stuff around.. http://people.ubuntu.com/~fabbione/deboot.diff
<fabbione> Kamion: in details: required adds gcc-4.0-base and base adds: cpp-4.0 and gcc-4.0
<bob2> does Fedora still use kudzu?
<fabbione> Kamion: + the specific sparc stuff
<zyga> fabbione: test in 3 minutes
<Kamion> fabbione: thanks, I'll upload
<fabbione> Kamion: it's tested only on sparc tho
<fabbione> but i thing the gcc-4 changes are ok on other arches too
<zyga> reboot
<fabbione> Kamion: some good news on #u-k.. we can start dropping some ppc images as soon as i get the ppc64 versions
<Kamion> fabbione: actually, go ahead and upload that debootstrap - there are no other changes I need to do so no point in me pulling down your diff
<fabbione> down to 4 images :)
<zyga> fabbione: seems to work fine
<Kamion> fabbione: we'll just need powerpc and ppc64, I'd expect?
<Kamion> er, plus -smp
<fabbione> zyga: can you please run it for a while?
<zyga> fabbione: sure
<zyga> No pro!@#@$^%#
<fabbione> Kamion: we agreed with svenl/benh: ppc32 -> powerpc{,-smp}, pseries-smp and iseries-smp
<zyga> ;-)
<fabbione> Kamion: benh sais there is no point in UP kenrel for the others
<Kamion> fabbione: 'k, sounds sensible
<Kamion> so I guess I build d-i from powerpc and pseries-smp
<fabbione> and iseries :(
<Kamion> (there isn't complete iseries-smp support in d-i yet)
<fabbione> iseries won't boot with pseries kernels apparently
<zyga> fabbione: It's probably my imagination but it seemed to boot slightly faster than the previous 2.6.10
<fabbione> zyga: it might...
<Treenaks> it has timing info in the kernel log messages now
<zyga> fabbione: less stuff to do or gcc-4 really optimized things?
<fabbione> no idea
<fabbione> zyga: without benchmarks there is no real "faster/slower" than 
<Kamion> fabbione: somebody sent a couple of iseries patches to debian-boot@ ages back, and I think most of them got applied, but AFAIK the job wasn't finished
<fabbione> Kamion: no rush.. i need to get the changes in the kernel first
<Kamion> I'm not going to spend significant amounts of my time worrying about it :)
<Kamion> fabbione: will pseries-smp boot on G5s?
<Kamion> if so, that seems like kind of a misleading name
<fabbione> Kamion: ENOCLUE.. that's what svenl/benh are telling me
<Kamion> it must do, powerpc won't
<fabbione> i tend to trust what benh says
<fabbione> (even via svenl ;))
<Kamion> could you ask them about that? I feel uncomfortable having to tell G5 users to boot a pseries kernel :)
<fabbione> sorry svenl.. couldn't resist :P
<fabbione> Kamion: svenl says it does
<infinity> You could just go for purely generic names, like Debian's HPPA kernels.
<infinity> (2.6.12-32{,-smp}, 2.6.12-64{,-smp})
<elmo> pitti: nothing to sync
<elmo> fabbione: mostly done, except breezy-ppc64, which err, seems to be broken
<pitti> elmo: oh, already done, thanks
<fabbione> elmo: thanks
<elmo> pitti: eh, manually?
<seb128> I've several packages ftbfsing with a "/usr/bin/ld: cannot find -lstdc++" error
<pitti> elmo: no, I mean, obviously somebody asked faster than me
<seb128> anybody feeling to give me a hand on how to track what's wrong?
<elmo> pitti: ah, ok
<seb128> I've no clue on how to fix that :/
<seb128> the packages have not changed, so that's due to a toolchain or pkg-config or something change
<Kamion> infinity: the purely generic names are actually kind of a pain - given a package name, you can't figure out what architecture it's for easily - and you might well end up with totally different packages for different architectures but with the same name
<seb128> sound-juicer is an example of such package
<Mithrandir> seb128: pkg-config doesn't touch any of that.  It should be automatically detected based on whether you're compiling with g++ or gcc, I think?
<mvo> elmo: sync libogg please (our changes are in now)
<seb128> Mithrandir: that's c++ code build with gcc apparently
<elmo> mvo: done
<seb128> Mithrandir: and that used to work ... any idea on how to fix it?
<Mithrandir> seb128: not really, no.  Wave some magic wand or drag doko in to fix it.
<seb128> doko: ping? :)
<\sh> seb128: libstdc++ is on your system? 
<seb128> sure
<\sh> for which version? 
<seb128> the Build-Depends are correct
<fabbione> Kamion: ok, what do you prefer to have as name schema?
<infinity> Kamion : Erm.  But with any package in Debian, you can't determine the arch from the name (only the filename)... Why are kernels meant to be special in this case? :)
<seb128> \sh: libstdc++.so.5.0.7  libstdc++.so.6.0.4
<seb128> \sh: ie libstdc++5 and libstdc++6
<seb128> ---------
<seb128> but I'm pretty sure that's due to a gcc4 change
<infinity> seb128 : The problem is you're using "gcc -lstdc++" which is a) wrong, and b) won't work when gcc and g++ are mismatched (as they currently are in breezy, 4.0 versus 3.3)
<doko> seb128: yes, infinity is right
<infinity> seb128 : It should magically start working again after the c++ transition, but that's not really "fixed".
<seb128> k, I've a bunch of GNOME packages doing this 
<\sh> gtkmm stuff? ,-)
<seb128> what should be do to solve the properly?
<seb128> no
<seb128> gst-plugins0.8 by example
<doko> seb128: link with g++
<infinity> seb128 : If they're pure C applications linking with C++ libs, link with g++.
<infinity> seb128 : If they're pure C linking with something that accidentally pulled in a C++ dep earlier up the chain, fix the thing earlier on. :)
<infinity> seb128 : If it's C++, build with g++.
<seb128> sound-juicer is a C app
<seb128> try to figure what pulls the cpp part
<doko> seb128: and depends on which lib?
<infinity> seb128 : Remove the -lstdc++ and see what breaks.  It will fail to link if it thinks it needs it.
<infinity> seb128 : Might also make hunting down the source a bit faster. :)
<doko> seb128: yes, listed on http://www.ubuntulinux.org/wiki/CxxApplicationList
<doko> seb128: certainly libmusicbrainz4 and liborbit2
<seb128_> hum, dsl IP change
<seb128_> <doko> seb128: and depends on which lib?
<zyga> hmm
<seb128_> if you said something after that please repeat :)
<seb128_> liborbit2 is not cpp afaik
<zyga> when did 'places' menu got 'bookmarks' item?
<seb128_> 2.10
<infinity> seb128_ : Start randomly removing all the manually-insertedf "-lstdc++" from your packages, and see which ones break and why.
<doko> seb128_: look at http://www.ubuntulinux.org/wiki/CxxLibraryList for the list of libraries
<infinity> seb128_ : There's no change of a broken build, things will just fail to link if they need it.
<infinity> s/change/chance/
<zyga> seb128_: I've noticed it today, it was not there for a long time after installing 2.10
<seb128_> zyga: no, it's here since 2.10
<infinity> mysql has this bug too, but upstream's solution is perverse.
<zyga> seb128_: strange, maybe it depends on number of items in my bookmarks
<Kamion> infinity: kernels are different because we're talking radically different configs here - it's rare for "32-bit or 64-bit" to be the only significant difference, e.g. in the case of powerpc there are two 64-bit kernels, so calling it -64 would just be confusing
<Kamion> fabbione: I don't have a clear preference, that's why I was asking to ask benh if he was sure about the pseries name for something that boots on G5 :)
<infinity> Kamion : But one shold be the "generic 64 bit kernel" (for G5, RS/6000, pSeries), and the other is a specialty.
<infinity> Kamion : Nothing wrong with calling the other "-64-iseries" or just "-iseries", since only people with an iSeries machine will be looking for it.
<elmo> doko: breezy-ppc64 is FUBAR - do you have the debs handy so I can reinstall?
<Kamion> infinity: the -64 just makes my brain hurt, that's all - ppc64 and ppc64-iseries would be good though
<Kamion> or -ppc64 and -iseries
<infinity> Kamion : Fair enough.
<seb128_> src/Makefile:MUSICBRAINZ_LIBS = -lmusicbrainz -lstdc++ -lm
<seb128_> k, that's due to that lib
<seb128_> thanks infinity & doko 
<infinity> Great, and why is THAT one linked with stdc++?
<infinity> (Keep digging!_
<Kamion> ooh, powerpc CD fits
<doko> elmo: on davis:~doko/gcc/install and p.u.c:~jbailey/glibc (the latter I don't know exactly)
<elmo> ah, well it's glibc's that's screwed
<infinity> Kamion : But only in English... With the new desktop called "bash"?
<elmo> I'll wait for jbailey to be around before trying to repair it
<infinity> Kamion : And your choice of 400 kernels?
<koke> is there any documentation about dm snapshots in any place?? I can't find it :(
<seb128_> infinity: 
<seb128_> <ross> as i'm a fool
<seb128_> <ross> and it works for me
<seb128_> <ross> stupid breezy
<Kamion> infinity: heh
<Kamion> infinity: we're down one kernel and one language on hoary
<infinity> doko : If we hold off on the transition for another week, we could find and fix all these bugs.. (they'll go underground again as soon as gcc/g++ match)
<seb128_> infinity: at this point I understand the bug, but I'm not sure on how to fix it ;)
<doko> infinity: you only find these, if you recompile all apps, you can't garantee this for the next week
<infinity> seb128_ : Either stop linking something with stdc++ if it doesn't need it (you'll be able to tell if it does, the linker will cry), or link with g++ instead of gcc.
<seb128_> I need the second option
<doko> it's a nice to have, but we really don't need it.
<infinity> seb128_ : Or, if you're lazy, wait for the g++ transition, which will hide your bug again.
<seb128_> linking with g++ would mean to modify the autotools files and run the autotools?
<doko> seb128_: but file a bug report to Debian ...
<infinity> Quite possibly.
<seb128_> doko: how will that help? :)
<seb128_> doko: I prefer to bug upstream directly
<seb128_> since that's an upstream issue
<doko> yep, that's better
<infinity> I like MySQL's solution to this bug.  "Stop building our C++ apps with g++, and use CXX=gcc instead, we don't want to link stdc++ anyway"
<infinity> Scary, but true.  It's in the upstream README.
<bob2> wow
<infinity> (That gets around an issue where later in the build, a C app links in one of the previously-compiled C++ objects, which is linked with stdc++)
<jsgotangco> hey JaneW_ 
<seb128_> infinity: gstreamer upstreams blame libtool
<Kamion> infinity: I've worked on a different project that deliberately didn't use stdc++ for C++ code, similarly
<Kamion> we linked with libsupc++ to get basic language stuff
<infinity> Kamion : Oh, after I wrapped my head around it, what MySQL said made some modicum of sense.  It still hurt to read it, initially.
<JaneW_> hi jsgotangco 
<Kamion> in this case it was a C++ program dating from c. 1994 when the standard library really wasn't remotely standard or deployed
<infinity> They write specifically to avoid dependencies on stdc++.
<Kamion> well, it was "standard"
<Kamion> so we had our own library
<Kamion> and given the random suckiness of libstdc++ on a lot of platforms, yeah, it did make sense
<bob2> is it less crap on other arches nowadays?
<infinity> I don't know if the people who've been avoiding it all this time can be bothered to go test if it's okay now.
<bob2> hah
<Kamion> platforms, not arches. e.g. HP-UX 11
<infinity> If their current solution works, why break it?
<bob2> ahh
<Mithrandir> infinity: that's the attitude which brought us libtool. :P
<infinity> Mithrandir : Oh, I know.
<Lathiat> hahaha
<Kamion> yeah, plus the libraries that get written in such environments tend to be fairly performance-critical, and with a totally different API - this wasn't a reimplementation of libstdc++, it was a fundamentally different library, so swapping in libstdc++ isn't really an option for such people :)
<Kamion> hence why libsupc++ came into being
<seb128> Kamion: the gst-plugins0.8 rebuild with the new flac can wait a week or not? it ftbfs due to this cpp/gcc/libstdc issue atm
<Kamion> seb128: I can't build working CDs without it
<Kamion> so ideally not
<seb128> bah, somebody needs to help me so
<seb128> I understand the issue, but gst-plugins0.8 is a big piece and I've no clue on how to fix that
<seb128> forcing it to use gcc-3.3 for the moment?
<jdub> UBUNTU: NOT AS THICK AS WINDOWS
<\sh> what?
<jsgotangco> ?
<Seveas> lol jdub :)
<Kamion> seb128: if it's the easiest way ...
* zyga just booted symphonyos
<seb128> Kamion: k, I'll fix a way or an another
<seb128> graaah, not my day
<Kamion> yeah, sorry :/
<seb128> Mithrandir: are you going to fix pkg-config soon?
<Kamion> hm, wonder what's up with gnome-themes
<seb128> I've a couple of another ftbfs due to that
<seb128> Kamion: what about this one? :)
<Kamion> seb128: missing gtk2-engines-{crux,lighthouseblue} by the looks of things
<seb128> Kamion: I guess that's not right time to roll a CD, what about the dbus transition? I guess than some package are not updated yet?
<Kamion> seb128: no time is very good - but I really want to get one out before the C++ transition starts, otherwise I get screwed for a week
<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> 
<Kamion> a few things still need to be updated for the dbus transition, yeah
<seb128> oh, no, your issue is crux and lighthouseblue
<Kamion> I'm working my way through the uninstallables list
<seb128> hum
<seb128> sound-juicer needs an update too, and is bitten by this gcc/libstdc stuff too
<seb128> I'll fix that
<Treenaks> gnome-volume-manager has (had?) build-dep problems (bzip2)
<elmo> seb128: btw, gnome-vfs isn't waiting on me for me, right?
<seb128> elmo: what about gnome-vfs? 
<elmo> it's uninstallable atm, on at least 2 architectures
<Mithrandir> seb128: uploaded.
<elmo> due to dbus, I think
<Mithrandir> seb128: sorry for taking so long :/
<jdub> seb128: did you kill gtk2-engines-dev?
<Kamion> I think some builds just need to be retried for dbus
<Kamion> epiphany-browser looks like one of those
<seb128> jdub: yep
<jdub> seb128: heh - going to patch gnome-themes to ignore it? :)
<seb128> jdub: the only file here was a stupid useless .pc file
<seb128> jdub: already done, no?
<seb128> Josselin did that for Debian, and I've merged changes
<jdub> cool
<jdub> stupid, stupid idiocy ;)
<Kamion> dilinger: what's the right thing to do with ndiswrapper-utils' dependency on ndiswrapper-modules-1.1 for Ubuntu? I thought our default kernel included the ndiswrapper module
<KaiL_> Kamion: 2.6.10 contains the 1.0 modules, 2.6.12 the 1.1 modules
<fabbione> Kamion: i did add the Provides from the kernel...
<Kamion> KaiL_: point is that ndiswrapper-utils is uninstallable on Ubuntu at the moment
<Kamion> fabbione: ah
<fabbione> Kamion: but that's with 2.6.12
<Kamion> so it'll probably get fixed when we switch the CDs to 2.6.12
<Kamion> fine, it's only ship
<fabbione> Provides: linux, linux-image, linux-image-2.6, ndiswrapper-modules-1.1
<fabbione> yup
<fabbione> i want to wait for 12 final before switching
<Kamion> bit nasty for packages to depend on the kernel package though
<fabbione> that should happen pretty soon
<Kamion> people compile their own kernels (even still ...)
<KaiL_> any better idea? ndiswrapper-utils 1.1 is useless with the 1.0 modules, so..
<Kamion> it's pretty normal for packages not to depend on kernel interfaces
<Kamion> and to error at run-time if necessary
<Kamion> (although obviously tolerating both old and new interfaces is much better)
<seb128> elmo: hum, sorry, gnome-vfs2 you mean? What the error?
<seb128> elmo: according to http://people.ubuntu.com/~lamont/buildLogs/g/gnome-vfs2/2.10.1cvs20050510-0ubuntu2/ it builds fine
<seb128> what archis?
<elmo> seb128: uh, never mind sorry.  clearly I'm on crack - or it got fixed since I last tried 2 cron.dailies ago
<seb128> elmo: k
<doko> seb128: is the naming scheme for gnome library packages (appending -#) upstream, or a Debian thing?
<seb128> I've already replied this morning
<seb128> debian
<seb128> ;)
<seb128> why?
<mvo> elmo: sharutils sync please (override ok)
<elmo> mvo: done
<mvo> elmo: thanks
<Kamion> seb128: gst-plugins0.8 seemed to build fine for me in a current breezy chroot? (powerpc)
<seb128> weird
<seb128> it "/usr/bin/ld: cannot find -lstdc++" on my box
<Kamion> thought I'd give it a go to see if I could fix the problems, but there weren't any :-)
<Kamion> mind you that's "current" with respect to my mirror, which may be a day or so out
<seb128> I don't think this is due to a change this week
<seb128> lemme try again
<seb128> anyway I've a package just built using gcc-3.3
<thom> AARGH CDBS I HATE YOU
<thom> -e "s/@cdbs@/cdbs (>= 0.4.23-1.1), debhelper (>= 4.1.0), quilt, patchutils, cdbs (>= 0.4.27-1)/g" ; i mean, WHY?
<pitti> what the hell... ?
<seb128> thom: why not? :)
<thom> seb128: cdbs dep twice?
<thom> (and generating control files is just blaaaargh anyway)
<seb128> oh, that would be a bug :)
<seb128> I thought you were complaining about the @cdbs@ magic
<thom> well, i am. but mostly the bug ;-)
<seb128> complain to jbailey :p
<seb128> Kamion: 
<seb128>  cc -shared  .libs/libgsttrm_la-gsttrm.o  -L/usr/lib -pthread /usr/lib/libgstreamer-0.8.so -lmusicbrainz -lstdc++ -lm  -Wl,--export-dynamic -Wl,-soname -Wl,libgsttrm.so -Wl,-version-script -Wl,.libs/libgsttrm.ver -o .libs/libgsttrm.so
<seb128> /usr/bin/ld: cannot find -lstdc++
<seb128> collect2: ld returned 1 exit status
<seb128> -lmusicbrainz again
<seb128> dunno why you don't get the issue
<pitti> seb128: maybe you need libstdc++6-dev?
<seb128> pitti: no, already discussed with doko and infinity 
<seb128> pitti: that's C code and app using gcc to link cpp code instead of g++
<Lathiat> can i get apt to explain to me why installing the new dbus causes vlc to be removed?
<seb128> which doesn't work when gcc and g++ version are differents
<seb128> Lathiat: because it depends on the old one?
<Lathiat> well it doesnt, thats the thing
<seb128> Depends: aalib1 (>= 1.2), dbus-1 (>= 0.23.4),
<seb128> here
<Lathiat> oh, it does?
<seb128> sure
<Lathiat> i am blind.
<seb128> apt-cache show vlc
<pitti> apt-cache rdepends dbus-1
<pitti> -> everything that still needs to be fixed
<Lathiat> yarr
<pitti> xterminal, vlc, gpe-contacts, screem, kdebase-kio-plugins, bluez-utils, bluez-pin
<Lathiat> skype uses dbus?
<Lathiat> wtf
<Lathiat> theres all this crack that seems to use dbus i didnt know about
<tseng> hm and skype is binary only right?
<Lathiat> yeh
<Lathiat> sucks to be skype :)
<jsgotangco> yeah
<tseng> thats pretty suck
<jsgotangco> hah
<tseng> way to never work against a users dbus
<Lathiat> i just wonder wtf it uses it for
<Lathiat> i also wonder what vlc uses it for
<zyga> Lathiat: for pluggable micrpohones and headsets
<zyga> Lathiat: it's somewhere on the skype website
<Lathiat> hotplug emits events?
<zyga> Lathiat: also look for skype files in /etc/hal-stuff
<pitti> Lathiat: that's one of it's basic purposes
<pitti> Lathiat: hal picks them up from hotplug and distributes them over dbus
<zyga> Lathiat: /etc/dbus-stuff
<Lathiat> ah ok
<zyga> anyway this suxx, I use skype all the time :/
<Lathiat> :\
<Lathiat> thats what you get for using closed source crap thats better than existing open source solutions. ;)
<zyga> Lathiat: that's for properiarity user catalogs in instant message networks
<zyga> Lathiat: but you are right too, skype is superior technically to anything else ATM
<Lathiat> unfortunately
<Lathiat> its not like enough to do it doesnt exist
<zyga> maybe we could get them to recompile their package
<Lathiat> just no ones put it together
<Treenaks> zyga: if they only opened up the protocol
<zyga> Treenaks: I think they don't want to do that for a very good reason
<zyga> Treenaks: skype relies on fair clients that act as proxies
<Treenaks> zyga: so? bittorrent too
<zyga> Treenaks: once skype clones appear people could just turn the proxying off
<zyga> Treenaks: yes but then the quality of skype goes down rapidily
<Lathiat> so they just need to make the network not let them make calls if they aren tproxying
<zyga> also there is the issue of properiarity codecs they licensed
<KaiL_> who updates the update-notifier? (...wonderful sentence...)
<jsgotangco> bye bye
<Lathiat> bittorrnet has issues with leachers
<mvo> KaiL_: that's me
<Lathiat> unfortunately
<zyga> KaiL_: mvo 
<Treenaks> KaiL_: "Et tu, synaptic" ?
<zyga> mvo: hello :)
<jsgotangco> heh
<Lathiat> however the community has meant that most trackers ban clients that have features that work against the network
<mvo> hey zyga, hey Treenaks 
<jsgotangco> hey mvo, bye mvo
<Treenaks> hi mvo 
<Kamion> seb128: odd that I don't, oh well
<zyga> Lathiat: well... then I guess the people who built kazaa just don't want you to look at their things :/
<seb128> Kamion: I've uploaded the version using gcc-3.3
<zyga> mvo: are you planning an update to update-manager anytime soon?
<Kamion> seb128: thanks, that's great
<mvo> zyga: michiel has some gui ideas, available at http://blogs.gnome.org/nb.cgi/view/michiels/2005/05/10/0
<mvo> zyga: and it will support dist-upgrades
* Kamion gets bored and writes a baztag that tags to $ARCHIVE/$CATEGORY--releases--<version I give it>, so that I don't have to type it out all the time
<zyga> mvo: interesting, I look forward to it
<KaiL_> could somebody explain the relations between splashy and usplash?
<sladen> KaiL_: usplash is set of ideas/specification for what is required.  'splashy' is somebody program based on some of those ideas, but not all of them.
<\sh> mvo: hmmm...
<KaiL_> sladen: ah
<\sh> mvo: we should see, that the gnome-frontend and the kde-frontend will behave the same :)
<KaiL_> \sh: then start hacking
* KaiL_ hides
<mvo> \sh: oh yes
<\sh> KaiL_: hehe :)
<\sh> KaiL_: first of all, the backend has to be done :)
<mvo> \sh: a lot is going on in the python-apt--mvo branch of this work
<\sh> mvo: updated today ;)
<mvo> \sh: :)
<\sh> look at this one: http://ardour.org/ really amazing application
<mvo> Kamion: where is the code for the d-i language-selector available? I would like to have a look at it
<Kamion> mvo: localechooser package
<zyga> mvo: I'll mail you the translation if you don't mind
<mvo> Kamion: thanks
<mvo> zyga: plesae do that, thanks :)
<\sh> so..everybody in NRW, Germany will have EPG data for the new tv.gusto tv channel in a couple of minutes ,-)
<Lathiat> epg?
<KaiL_> i thought tv.gusto is for the usefull 30min/day of tv.nrw?
<\sh> KaiL_: no :) it's a 24 hour service in ish plus tv :)
<KaiL_> ...or 30min/week? :)
<KaiL_> do you work somewhere there?
<\sh> Lathiat: Electronic Programm Guide ;)
<\sh> KaiL_: jupp...working for ish in kerpen
* mvo goes for lunch
<\sh> bon appetite :)
<KaiL_> EPG = information what this channel planned to show 1 week ago :)
<\sh> but this is the consumer description ;) the technical term is "EIT p/f" and "EIT schedule" ... EIT== Event Information Table :) now u got a shot excourse of Digital TV..:) thx ;)
<\sh> s/shot/short/
<seb128> pitti: dbus issues are for you or daniels?
<pitti> daniels
<seb128> k
<seb128> to assign #10649 
<pitti> dhcpd    29602  0.0  0.2   2768  1544 ?        Ss   12:46   0:00 /usr/sbin/dhcpd3 -q eth1 -pf /var/run/dhcp3-server/dhcpd.pid
<pitti> cool, another root process less
<Kamion> is g-v-m in the process of being fixed (to be installable)?
<pitti> erm, it should be installable?
<pitti> Kamion: what breaks?
<zyga> seb128: do you maintain gtranslator/
<KaiL_> pitti: dbus, what else?
<Kamion> pitti: no idea, just looking at http://cdimage.ubuntu.com/daily/current/report.html
<pitti> Kamion: oh, that's old; the new version is 1.3.1
<pitti> Kamion: will probably be fixed tomorrow when it uses updated binaries
<pitti> Kamion: I uploaded the crack yesterday around noon
<Kamion> er, that's today's build
<pitti> $ apt-cache show gnome-volume-manager | grep ^Version
<pitti> Version: 1.3.1-0ubuntu1
<Kamion> 1.3.1 failed to build
<Kamion> http://people.ubuntu.com/~lamont/buildLogs/g/gnome-volume-manager/1.3.1-0ubuntu1/
<pitti> uh, thanks for pointing me out...
<Kamion> tar: bzip2: Cannot exec: No such file or directory
<Kamion> looks like a missing build-dep
<pitti> tar -C build-tree  -xjf gnome-volume-manager-1.3.1.tar.bz2
<pitti> tar: bzip2: Cannot exec: No such file or directory
<pitti> hmmm
<pitti> WTF?
<Kamion> you have to build-dep on bzip2
<Kamion> it's not build-essential
<seb128> zyga: not really, why?
<pitti> aah
<zyga> seb128: there's one very nasty bug in it 
<zyga> seb128: I don't want to send it via bugzilla, rather fix it myself
<seb128> ie? hoary or breezy?
<zyga> seb128: breezy
<seb128> why not using malone?
<KaiL_> http://cdimage.ubuntu.com/daily/current/report.html << does such a page exist for kubuntu too?
<zyga> seb128: n-plurals is truncated (only one line is read)
<zyga> seb128: malone?
<Kamion> KaiL_: http://cdimage.ubuntu.com/kubuntu/daily/current/report.html, but I haven't started building Kubuntu breezy CDs yet
<seb128> zyga: the bug tracker for universe
<seb128> launchap.ubuntu.com/malone
<Kamion> "daily" currently means "whenever Kamion runs cron.daily" - I haven't turned the autobuilds back on yet
<seb128> oh, gstranslator is main
<seb128> use bugzilla then
<Kamion> KaiL_: http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html is probably more useful
<zyga> seb128: I was wondering wether you'd apply a pach to debian patches stuff it this is easy enough for me to fix
<seb128> zyga: I would send the patch to the Debian maintainer and sync with the fixed package from Debian
<zyga> seb128: fine enough for me :)
<tseng> pitti: my email.. want me to build that and test it today?
<tseng> pitti: we use ethereal alot at work.
<pitti> tseng: which one? ethereal?
<tseng> yes
<Lathiat> what for, ooc?
<seb128> zyga: debian has 1.1.6, is that fixed with this version?
<pitti> tseng: if you want to, would be nice. ethereal is used a lot, but it has lots and lots of holes
<seb128> elmo: gstranslator sync please
<tseng> pitti: redhat built the new version, i was going to do the same
<ajmitch_> pitti: yes, I noticed it didn't build here..
<tseng> pitti: since its universe
<pitti> tseng: new upstream version? well, for my sake...
<zyga> seb128: checking
<pitti> tseng: it's probably safer than backporting 25 patches
<ajmitch_> tseng: you've tried building it?
<tseng> ajmitch_: i plan to at work
<tseng> there are some user visible changes
<ajmitch_> tseng: right, I found it failed building packet-smb.c, I ust added it to my todo list to look at
<tseng> I see
<zyga> seb128: seems to... I'll do more tests though
<tseng> we have it on fc3 from -updates
<tseng> and on gentoo
<ajmitch_> tseng: I suspect it just needs to link against the right lib, let me check
<zyga> seb128: no it's still broken
<zyga> seb128: easliy reproducible 
<seb128> jordi: around?
<seb128> zyga: jordi is the Debian maintainer, he probably wants the patch for the Debian package/sarge
<zyga> seb128: ok
<seb128> zyga: and if the package is updated for Debian the fix will be grabbed by sync
<seb128> is your patch only somewhere?
<zyga> seb128: I'm working on the patch ATM
<seb128> k
<ajmitch_> tseng: is just bug in source, I think
<tseng> ok time to go to work
<sabdfl> daniels: ping
<ajmitch_> tseng: ok, patched & building
<tseng> ajmitch_: erm, ok cool
* zyga cannot help to wonder how does glib string mess manage to work at all
<KaiL_> fabbione: http://www.derkeiler.com/Mailing-Lists/securityfocus/bugtraq/2005-05/0131.html
<KaiL_> ...even as I guess you were faster, as always *g*
<pitti> KaiL_: we are already working on it
<KaiL_> what did I say? :)
<ajmitch_> pitti: yay, looks like my ethereal patch lets it compile, at least :)
<seb128> lamont: please kick the file-roller build (and the other builds with a such issue, pkg-config is fixed now)
<elmo> seb128: from where?  can't see anything newer in experimental or debian
<seb128> elmo: we have 1.1.5-1ubuntu1 and debian 1.1.6 ?
<elmo> gtranslator |    1.1.6-1 |        breezy | source, ia64
<seb128> hum
<seb128> sorry, I've looked on i386 only
<elmo> np
* seb128 goes to the build logs
<seb128> thanks
<seb128> grrr, .bz2 logs sucks
<pitti> seb128: yeah, indeed
<pitti> Kamion: g-v-m built successfully now, thanks for pointing out
<seb128> lamont: kick gstranslator too please
* fabbione reminds seb that he can ssh and bzcat/grep on people directly
<doko> lamont: ^^^ ;-) everybody cried for compressed logs, now everybody screams ;)
<seb128> I never asked for compressed logs
<seb128> it used to work fine
<pitti> doko: that's just a firefox bug :-/
<seb128> pitti: epiphany has the same so, if that matters ;)
<seb128> fabbione: yeah, right, but I prefer the browser option
<Kamion> pitti: good, thanks
<Kamion> sabdfl: daniels just phoned me (unrelatedly), sounds like he's at an installfest or similar
<sabdfl> Kamion: multo obligato
<Lathiat> slug meeting probably?
<Lathiat> or
<Lathiat> melbourne style
<Lathiat> i forget what their lug is called
<Kamion> whatever it was it was noisy
<jordi> seb128: yeah?
<jordi> zyga: please send the patch to the BTS, I'll upload.
<seb128> jordi: that's it, thanks :)
<doko> jbailey: just broke a chroot upgrading from hoary to breezy: relocation error in libc-686
<ajmitch_> Lathiat: luv or mlug
<Lathiat> luv, thas the one
<zyga> jordi: BTW?
<Lathiat> is there an mlug too?
<zyga> jordi: BTS?
<seb128> debian bug tracker
<zyga> jordi: I'm testing the results ATM, seems to work okay
<ajmitch_> Lathiat: yeah, I've been to mlug but not luv meetings
<Lathiat> ah
<Lathiat> ive only ever heard of luv
<koke> mvo: you around?
<koke> I have a (maybe stupid) idea for update-manager
<jordi> BTS = debian bug tracker
<jordi> or just mail it to me, whatever, if you don't want to use the bts
<mvo> koke: yes, I'm around. please tell me your idea
<koke> ok, do you think it's interesting to have the repositories list in the server??
<koke> the descriptions I mean
<zyga> jordi: I'm still tracking one issue
<jordi> ok
<zyga> jordi: I'll notify you as soon as I'm sure it's safe
<jordi> what bugs are you fixing=?
<zyga> jordi: try editing a .po where plural-forms spans multiple lines
<zyga> jordi: gtranslator will only take the first one
<mvo> koke: so that it's easy to add mirrors and stuff?
<jordi> nod
<koke> yep
<jordi> zyga: this is fixed in HEAD, but HEAD depends on an unreleased gettext
<zyga> jordi: ah then I'm doing useless stuff
<zyga> jordi: what's new in gettext?
<koke> mvo: or maybe "experimental"/temporary repositories
<jordi> zyga: libgettextpo or whatever the name is
<zyga> jordi: po parser probably/
<jordi> zyga: no, you're fixing it for 1.1.x, which is nice
<jordi> zyga: yeah
<zyga> jordi: good then
<koke> mvirkkil: like people.u.c/~foobar/packages/gcc-5.0 :P
<zyga> jordi: my fix works already but something is still wrong with parsing plural messages
<koke> ops, missed completion :)
<zyga> mvo: IDEA: add special mask for p.u.c/~name/ and mark them as ubuntu people repositories
<mvo> koke: no problem, happens to me all the time :) 
<zyga> mvo: add a list of well known names (in separate package probably) to further beautify the GUI
<mvo> zyga: that sounds interessting, also the p.u.c archives are usually short-living, mostly they are test repos that are merged into the main archive
<zyga> mvo: I'm sure alot ubuntu devels have some of those archives in their sources.list
<koke> mvo: maybe some description in the Release file, would be nice
<zyga> mvo: I'm not sure they use update-manager though ;] 
<koke> buuut, only trust the description if the release is well signed and trusted
<mvo> koke: some way of a central repository directory would be interessting, also with our _huge_ universe/multiverse it's less important nowdays I think. wasabi had a nice idea about a special ".apt" file that can add repositories easly
<mvo> koke: description in the release file sounds good, we already support it in theory, but it's not used yet IIRC
<koke> mvo: I mean, something in the Release file would be nice, but I could put in my own repos a "Ubuntu security updates"
<thom> elmo: can you thump cogito out of new when you get a chance?
<koke> that is why I was telling about the signatures
<mvo> koke: agreed
<seb128> Keybuk: is hct ready to be used? I would like to play with it to repackage gdm
<Keybuk> "repackage" ?
<seb128> it's a diff.gz crap and I want to switch to cdbs with proper patches
<jdub> seb128: woo! :)
<seb128> Josselin did the work once for Debian
<jdub> GO GO GO!
<jdub> GO YOU BIG RED FIRE ENGINE!
<Keybuk> it's not quite ready to be used for that yet
<seb128> I've started yesterday, and after having like 10 dirs and doing diffs all over the place I figured than hct is what I want to do the patches
* fabbione takes away the pipe from jdub 
<seb128> :(
<Keybuk> possibly
<Keybuk> it'd certainly help
<Amaranth> morning
* Keybuk will just check whether gdm got imported before the database schema got changed :)
<Keybuk> not yet :(  should be soon
<seb128> "soon" beeing 1 day/week/month/.. ? :)
<Keybuk> this week
<Keybuk> 1-2 days
<Keybuk> I hope
<seb128> k, cool
<seb128> let me know when it's ready ;)
<Keybuk> well, I can resume imports when that rsync over there <-- finishes
<Keybuk> and they'll run until Mark "exercises his inner woman" again
<KaiL_> eeks, why does apt-get now think it can remove kdebase, after update-notifier got updated?
<Keybuk> so it's just a matter of when gdm gets imported
<seb128> ok
<jordi> seb128: dude
<Treenaks> KaiL_: it got smart :P
<seb128> KaiL_: because some KDE stuff need to be update to the new dbus?
<mvirkkil> koke: Huh?
<KaiL_> seb128: but update-notifier kept it to wait, why not the kde packages?
<koke> mvirkkil: <koke> ops, missed completion :)
<seb128> KaiL_: no clue from the description
<mvirkkil> koke: :) ok.
<seb128> depending of the packages list, etc
<jordi> KaiL_: maybe update-notifier got a clue :)
* mvo giggles
<KaiL_> is there some "keep installed"-flag?
<seb128> jordi: what?
<Kamion> KaiL_: you stand a better chance of that with aptitude
<Kamion> apt-get is a debugging tool :-P
<KaiL_> or stay with apt-get upgrade
<KaiL_> noit dist-upgrade
<KaiL_> but stily funny
<KaiL_> still funny...
<Kamion> busybox-cvs (20040623-1) unstable; urgency=low
<Kamion>   * New CVS version.
<Kamion>     - Support 64 bit arithmetic. (closes: #251302)
<Kamion> $ usr/bin/expr 100000000000 + 200000000000
<Kamion> -2
<Kamion> sigh
<Kamion> and for that matter $((...)) can't do it either
<Kamion> $ echo $((100000000000000000000+20000000000000000))
<Kamion> 4294967294
<Amaranth> $ python -c "print 100000000000 + 200000000000"
<Amaranth> 300000000000
<KaiL_> echo $((100000000000000000000+20000000000000000))
<KaiL_> 7786279631452241920
<KaiL_> lol
<KaiL_> (the other 2 work here)
<Kamion> neither of those are useful in busybox, kthxbye
<Amaranth> $ python -c "print 100000000000000000000+20000000000000000"
<Amaranth> 100020000000000000000
<Amaranth> *cough*
<zyga> Amaranth: bah! ;] 
<zyga> did anyone notice that rhythmbox hangs when it starts in 'small' mode?
<Amaranth> nope, never use small mode
<Amaranth> i did notice that it started playing my evanescence songs twice in a row when i had it on random
<Treenaks> it has one?
<seb128> works fine here
<koke> Amaranth: I think I've suffered that too
<koke> maybe even with Evanescence songs only!! :)
<Amaranth> rhythmbox has good taste
<ogra> lamont ? (or elmo)
<ajmitch_> hi ogra 
<ogra> hi ajmitch_ 
<elmo> ogra: sup
<ogra> W: Couldn't stat source package list http://jackass.ubuntu.com breezy/universe Packages (/home/buildd/build-breezy/chroot-breezy/var/lib/apt/lists/jackass.ubuntu.com_dists_breezy_universe_binary-amd64_Packages) - stat (2 No such file or directory)
<ogra> W: You may want to run apt-get update to correct these problems
<ogra> elmo, from the latest mono build log...
<elmo> uh.. I'm going to defer to lamont on that one
<ogra> ok
<Lathiat> delegation at its best
<ogra> hehe
<ogra> Lathiat, some call it "standing on the sholders of giants" ;)
<Lathiat> :)
<ajmitch_> ethereal uploaded, hopefully it didn't take too long & timeout
<thom> hrm, i really ought to create a build partition that isn't on s/w raid
<Mithrandir> thom: ramfs! :)
<thom> Mithrandir: not so useful for firefox or the kernel, i suspect
<Mithrandir> you've got an amd64, just get mark to buy you 10G of RAM.
<ogra> hehe
<lamont> ogra: grumble
<thom> heh
<thom> i can just imagine that PO
<ogra> lamont, sorry *shrug*
* ajmitch_ sees it on the changes list, time for sleep then :)
<lamont> Mithrandir: so what were you trying to debug in nmap anyway?
<Mithrandir> lamont: nmap -oO 127.0.0.1 crashes on amd64
<lamont> Mithrandir: that's not very nice of it.
<Mithrandir> or -ofoo for stat.
<Mithrandir> uhm, s/stat/that/
<ogra> hmm
<ogra> fuser /dev/dsp /dev/sound/dsp /dev/snd/pcmC0D0c /dev/snd/pcmC0D0p /dev/snd/pcmC0D1c /dev/snd/pcmC0D1p /dev/snd/pcmC1D0c /dev/snd/pcmC1D0p /dev/audio
<ogra> my processlist is full of that and nautilus is stuck ....
<lamont> kids->school
<pitti> Kamion: to properly deroot dhclient3, I have to change /sbin/ifup to put the pid file into /var/run/dhcp3-client instead of /var/run. Given that I add proper package conflicts, do you see any problem with that?
<pitti> Kamion: alternatively, I could rewrite the pid/db file creation to happen earlier and chown them
<Kamion> pitti: no, as long as you make sure /var/run/dhcp3-client exists at startup rather than shipping it in the package (since /var/run might be on a tmpfs)
<Kamion> pitti: oh, ifup, erm
<Kamion> shouldn't ifup be client-independent?
<pitti> Kamion: it calls dhclient3 with paths for the pid and lease file
<pitti> dhclient3 -pf /var/run/dhclient.eth0.pid -lf /var/run/dhclient.eth0.leases eth0
<zyga> bah!
<zyga> gtranslator is crappy :/
<pitti> Kamion: well, the second alternative is probably safer for now, even if more code runs as root
<zyga> it's a miracle it works :P
<zyga> parsing wise
<Kamion> pitti: oh, I see
<Kamion> pitti: either, I guess, I don't have a strong opinion
<pitti> Kamion: above command is constructed in /sbin/ifup
* zyga goes home
<zyga> bbl
<fabbione> elmo: can you please update hoary/davis chroot?
<elmo> updating
<fabbione> elmo: amen.. here is another one: concordia$ dchroot -c hoary-i386 -> No directory, logging in with HOME=/
<fabbione> thanks
<elmo> oh, yeah, I disabled that.. while doing something.. probably creating breezy-i386
<fabbione> oh ok
<elmo> fixed
<fabbione> thanks
<fabbione> is it updated?
<fabbione> i need build-dep linux-source-2.6.10 on that one
<elmo> fabbione: updated 
<fabbione> thanks
<elmo> fabbione: davis done too
<fabbione> thanks
<lamont> elmo: would it make sense to crontab an apt-get update in the chroots on the porting machines?  (so that apt-get source tends to be close to current...)
<elmo> probably yes
<elmo> RTed
<diamond> elmo: hey. you may remember a mail from me about heanet offering official ubuntu mirroring...
<elmo> diamond: yeah
<diamond> elmo: would that be of any interest to you?
<elmo> diamond: yes, definitely, sorry I've not replied yet
<diamond> elmo: no problems, i know it was a very busy time for ye, to say the least
<diamond> elmo: anyway, thought i'd just remind you, so my work here is done, unless you have stuff you want to ask me
<elmo> diamond: thanks for the prod, I'll talk to the heanet guys in the next day or two
<diamond> elmo: cool -)
<JaneW> daily reminder: please update the statuses of the Breezy Goals you are responsible in http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals
<JaneW> I'll have to keep nagging until they are all done...
<JaneW> ;)
<Simira> hi folks
<Simira> I can take some responsibility, but I don't have any BreezyGoals to update...
<Kamion> lamont: how much of http://cdimage.ubuntu.com/daily/current/report.html is give-back city?
* lamont looks
<lamont>   libhal-dev: Depends: libhal1 (= 0.5.1-0ubuntu1) but it is not going to be installed
<lamont>               Depends: libdbus-1-dev but it is not going to be installed
<lamont> nautilus-cd-burner, that is
<lamont> Kamion: well, the mass-giveback I did yesterday didn't clear them....
<Kamion> hmph
<Kamion> worth a try
<lamont> lsb is it's own little problem.
<lamont> main Depends: universe
<lamont>   lsb: Depends: lsb-core but it is not installable
<lamont>        Depends: lsb-graphics but it is not installable
<lamont>        Depends: lsb-cxx but it is not installable
<Kamion> yeah, I asked elmo to promote those last night
<lamont> Kamion: let me figure out what's up with hal/dbus installability - that's most of those.
* lamont disappears into the chroots
* Kamion implements half of InstallerSimpleResize
<Kamion> it remains to be seen whether that was the easy half
<lamont> grumble
<lamont> Kamion: you mean 'little' half vs 'big' half?
<lamont> lets see how those do
<seb128> lamont: dunno if you read what I said before, but you can kick file-roller and similar ftbfs with symboles issues
<doko> hmm, for the C++ transition, we currently have a conflict of the new library package with the old library package. wondering, if we should have a "replaces" line as well?
<lamont> seb128: hadn't read that before - just gave back a boatload of fails-to-install-build-deps packages
<seb128> lamont: please kick gtranslator too, ftbfs due to the aspell b0rkage
<diamond> seb128: once again, i filed a duplicate bug report, 'cept this time it was at least in a different bugzilla. doh.
<lamont> kicked everything with 'undefined reference to' in the log
<Kamion> lamont: yeah. I've done the bit that goes through figuring out how much free space there is and, failing that, which partitions can be resized; now I have to do the actual resizing (and kick off the autopartitioner, but that *is* trivial)
<seb128> diamond: ah ah, which one? :)
* Kamion -> shopping for lunch
<diamond> seb128: the gnome-utils screenshot bug, with multi-monitor setups
<seb128> oh, right
* lamont grumbles about the loose definition of 'kick', gives gtranslator back
<lamont> seb128: is libgii one of yours?
<lamont> (it has a 'g' in the name, you see..... :-)
<seb128> not than I know
<lamont> ok. nm
<lamont> seb128: libwnck_2.10.0-1ubuntu1: non-PIC in shared lib.
<lamont> /usr/bin/ld: /usr/X11R6/lib/libXRes.a(XRes.o): relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC
<seb128> rahhh
<lamont> --> missing build-dep??
<seb128> I don't think so, I've just added the Build-Depends on libres-dev
<seb128> because some feature was not activated without it
<seb128> libxres even
* lamont thought their should be a libXRes.so somewhere...
<lamont> usr/X11R6/lib/libXRes.so                                    libdevel/libxres-dev
<fabbione> there is
<lamont> is wnck bug
<fabbione> doko: i just started building gcc-3.4 again in a brand new clean breezy chroot...
<lamont> gnome-volume-manager_1.3.1-0ubuntu1: missing build-dep bzip2
<fabbione> lamont: btw, i fixed debootstrap breezy.buildd
<fabbione> or atleast now it can bootstrap
<lamont> fabbione: ok.  it'll need love again next week
<fabbione> lamont: when the trasition will start?
<fabbione> yeah i could guess for the g++-4.0
<lamont> fabbione: I'd fixed the copy in buildd-config, but was stalling hoping that Kamion would beat me to it in debootstrap
<fabbione> eheheh
<lamont> yeah.  I believe that's planning to happen next week
<fabbione> yeah i heard that.. i was more interested in a day
<fabbione> since monday i won't be around
<fabbione> and i am 100% sure it will start monday
<lamont> monday was what I'd heard
<lamont> see #ubuntu-toolchain
<lamont> :-)
* fabbione siiiighs
* lamont hacks on tar
<fabbione> i guess i will need to stop the sparcbuildd on a crontab base
<jdub> lamont: #ubuntu-toolchain? seriously?!
<lamont> jdub: yeah, it exists.
<fabbione> lamont: or do you think you can do that sunday night before going to sleep?
<lamont> fabbione: you could atjob the crontab change...
<lamont> jdub: it's even logged
<fabbione> eheh
<jnc> evolution is in process to be updated, for breezy i presume
<doko> jdub: #ubuntu-love wasn't appropriate
<doko> Kamion, fabbione, elmo, whoever knows: for the C++ transition, we currently have a conflict of the new library package with the old library package. wondering, if we should have a "replaces" line as well?
* lamont beats against the wall with reportbug
<lamont> jnc: it and everything else
<jnc> ;)
<pitti> doko: actually it shouldn't be necessary AFAICS; new libraries should be pulled in as dependencies
<Kamion> pitti: the conflicts are very much necessary
<pitti> Kamion: yeah, of course, I talk about the Replaces:
<Kamion> doko: I'd use both conflicts and replaces I think
<pitti> doko: you will recompile all applications which use the new library, riight?
<sabdfl> Keybuk: xft done
<Kamion> it's true that dependencies will generally pull in the new library, but replaces will provide an extra hint to the packaging system which one it should pick
* lamont wanders off for a little bit
<Kamion> otherwise I can imagine the packaging system deciding to hold back the applications rather than install the new library
<doko> Kamion: ok
<jdub> heh, cogito sync :)
<pitti> well, you can't have old and new apps installed side by side anyway, since the old apps will not work with the new library (in this sense, a Replaces: is semantically wrong)
* ogra cries
<ogra> mono is so bad to me
<pitti> oh, sorry, that was bogus, nevermind
<pitti> doko: yeah, Kamion is right (of course, as always :) )
<fabbione> pitti:      - Remove system user dhcpd on purge.
<fabbione> i don't really like that
<pitti> hm, we do that with all system users so far
<pitti> fabbione: why not? it doesn't leave any files behind
<fabbione> is the config still owned by root or by dhcpd user?
<pitti> fabbione: by root
<pitti> fabbione: dhcpd only owns the lease file, which is purged
<fabbione> pitti: ok...
<pitti> fabbione: I think it makes sense to have the conffile owned by root
<pitti> (by default, at least)
<fabbione> i was only worried of UID reuse
<fabbione> yeps
* jdub wants to shift to breezy on his server so he can test gfs :-)
<fabbione> jdub: wait for the next kernel...
<fabbione> and that i can upload the userland tools :)
<fabbione> otherwise there is really not much you can test
<fabbione> other than a single node cluster
<Nafallo> fabbione: thanx btw. you managed to pull all my hardware to work out of the box with 2.6.12 :-).
<fabbione> Nafallo: cool
<jdub> fabbione: single node clusters are so boring ;)
<fabbione> jdub: do you have more than one server at home? :)
<fabbione> i did test here with a 2 and a 3 nodes cluster
<fabbione> it works pretty well.. used aoe to distribute the block device
<fabbione> and gfs on top
<fabbione> with dlm locking method
* pitti becomes confused about all those TLA
<fabbione> gulm did hang with the old code.. i need to check with the new one
<jdub> fabbione: not really, but i can set up junk machines in the cluster
<fabbione> that would be good :)
<jdub> fabbione: GFS can handle multiple arches in the cluster, can't it?
<fabbione> jdub: yup
<jdub> what's aoe?
<fabbione> ATA over Ethernet
<jdub> oh right
<jdub> very nice
<Nafallo> Age Of Empires ;-)
<fabbione> it's another network block device system
<ogra> fabbione, btw, my workstation is ready for clusterfs...
<jdub> yeah, i've been meaning to try it
<fabbione> ogra: rocking
<jdub> nice that it works with gfs
<fabbione> jdub: you can use aoe/nbd/gnbd
<fabbione> any of them is fine
<jdub> do you think that should be our recommended setup?
<fabbione> jdub: it depends a lot from the hw they have
<fabbione> some clusters are all connected via fiber to a SAN
<fabbione> and they don't need any of the network block devices at all
<jdub> yeha
<fabbione> they only need GFS + dlm
<fabbione> jdub: i think it will be more fun to make a contest out of it :)
<jdub> ha ha
<fabbione> like build the biggest ubuntu cluster and you win a dinner with Mark
<fabbione> or something like that :)
<jdub> that's an awesome idea
<jdub> and good messaging for ubuntu as a server
<fabbione> exactly
<jdub> want me to announce? :)
<fabbione> or "Win a dinner with Fabio's wife!"
<fabbione> after we have the tools in place
<fabbione> not right now
<jdub> i will make sure your email address is prominent for people who need help setting it up :-) ;-) ;-)
<fabbione> it's too early
<jdub> yeah
<jdub> just checking that you're not kidding :-)
<jdub> i think it's a brill idea
<fabbione> i said a dinner with Mark or my wife :)
<fabbione> not with me :P
<fabbione> but i mean.. ask Mark..
<jdub> fabbione: oh, next kernel will have new inotify too, right?
<fabbione> jdub: this kernel has inotify on by default already
<jdub> fabbione: we don't need to ask mark anymore, we have claire. she owns his calendar. :-)
<diamond> fabbione: clarify. dinner with {mark,your wife}, or, {dinner with mark,your wife} ? -)
<jdub> fabbione: mmm, but you asked me to wait on gamin for the new inotify
<fabbione> diamond: the former.. :)
<diamond> fabbione: ok. just checking -)
<fabbione> jdub: yes.. i am going to update with the new idiotify patch soon
<jdub> fabbione: seb is going to be doing it anyway :)
<jdub> ha ha
<fabbione> whatever...
<jdub> inotify == good
<jdub> gamin == hmm :)
<fabbione> if i get bugged  i will forward the bugs to you
<zyga> re
<fabbione> no matter what :)
<ogra> so lets write some replacement :)
<zyga> another firefox :)
<jdub> fabbione: seb dude, seb :)
<fabbione> no no
<fabbione> you jeff..
<fabbione> you
* Nafallo states he won't be needing bash.org while he has #ubuntu-devel ;-)
<fabbione> Nafallo: i think T-Bone has something like 2/300 entries just from #ubuntu-kernel
<Nafallo> *s*
<Nafallo> hmm, the real breezy work (NM, Xen and stuff) starts after the CxxTransition I guess? :-)
<ogra> Nafallo, depends
<ogra> Nafallo, for example, i'm fighting with mono since last friday, this isnt affected by the transition...
<Nafallo> ogra: ahh, true. :-)
<ogra> hmm, btw, where is T-Bone, hvent seen him since before udu in here.... did he give up ?
<fabbione> ogra: no idea...
<Nafallo> ogra: anyway. Feels like the trasition have to be top prio next week, atleast for MOTU :-).
<ogra> Nafallo, yes, thats true....
* ogra wonders if the T of MOTU should be renamed to "Transitioning"
<jdub> ha ha
<Nafallo> ogra: hehe, atleast that week ;-)
* zyga gets back to gtranslator's parser crap
<jdub> ogra: you should ask doko for one of his perl scripts
* jdub glares at NORTY DOKO!
<zyga> wake me up when we have ff patched please :)
<mdke> http://pastebin.ca/11588 <-- does anyone know what this error might mean when editing the ubuntu wiki?
<doko> jdub: which packages do you take? ;-)
* jdub ducks doko's bullet :)
<ogra> jdub, we already decided to point everyone to him :) just scripting where we can abuse doko is lame ;)
<thom> zyga: firefox patched for what?
<zyga> thom: you know, 1.0.4 and stuff
<zyga> thom: don't tell me we already have that
<zyga> ;] 
<thom> oh right. well, patches are embargoed until the 18th :P
<zyga> thom: really, why?
<thom> 1.0.4 will hit breezy when i get time
<thom> wish i knew
<zyga> thom: I'm confused, embargo or lack of time?
<thom> zyga: the *patches* are embargoed, 1.0.4 is out
<thom> so, if you care about hoary, you can't have updates until the patches are unembargoed
<jay> Kamion: is it possible to access the section of the installer afterwards where it adds a new user?
<thom> if you're on breezy, you get 1.0.4 when i have time to do it
<zyga> thom: patches for breezy version of firefox?
<zyga> thom: ah
<zyga> thom: I was thinking about breezy
<zyga> thom: then it's crystal clear - thanks
<zyga> :-)
<mdke> http://pastebin.ca/11588 <-- who can i ask about this?
<thom> mdke: context would be nice
<mdke> thom, it occurs when trying to save a wiki page
<thom> mdke: i'd poke Henrik Nilsen Omma <henrik@canonical.com>
<mdke> ok
<ogra> mdke, and file a bug ?
<mdke> ogra, *grins*
<mdke> website bugs don't get assigned
<ogra> oh, not anymore ?
<mdke> https://bugzilla.ubuntu.com/buglist.cgi?query_format=specific&order=bugs.resolution%2C+relevance+desc&bug_status=__open__&product=Websites&content=
<mdke> ogra, but its hardly big priority due to the wiki changing over and all
<mdke> so i'll just try poking
<ogra> yep
<Lathiat> what are we changing to?
<mdke> MoinMoin
<Lathiat> ah cool
<mjg59> thom: They've released 1.0.4 but the patches are still embargoed?
<mjg59> Are they fucked in the head, or something?
<fabbione> mjg59: probably there are so many changes in such a big amount of messy code that it is impossible to discern what is what
<thom> mjg59: meh, most likely
<fabbione> the other possibility is another vendor-sec fucks up
<thom> mjg59: i suspect they have a suite release to do soon and want to embargo till then
<mjg59> With the assumption being that Johhny Badman won't be able to pull out the vulnerability from the diff?
<mjg59> Actually, in the Firefox case that's probably true...
<lamont> Kamion: want to rerun your uninstallable report?
<jdub> yo cc
<Kamion> jay: dpkg-reconfigure passwd
<Kamion> lamont: it runs on jackass as katie ...
<lamont> Kamion: ah.  daily? or as part of cron.daily?
<Kamion> lamont: though I can re-run the cdimage one by doing a new CD build, if everything's in the archive
<Kamion> lamont: the one on people is done from cron.daily, and mirrored hourly at :15
<jay> Kamion: it asks about shadow passwords, root password, etc.  i'm just looking to prompt the user to add a new acct and password as in the installer
<thom> mjg59: yeah :/
<Kamion> jay: there's no generic way to do that
<jay> Kamion: oh ok.  thanks
<Kamion> jay: there's 'dpkg-reconfigure -fhigh passwd', which will ask fewer questions; but if there's already a non-system user there, it won't ask
<Kamion> jay: I'd suggest using adduser (in text mode) or one of the gnome-system-tools (in GNOME) instead
<jay> Kamion: ya i started whipping up my own thing with whiptail but then realized what i was doing was recreating what the installer asked so i thought there might be a way to access it using debconf
<pitti> dhcp3-client derooting, there you go
<mdz> morning
<thom> morning matt
<fabbione> hey mdz
<daniels> morning mdz
<bluefoxicy> pitti:  hi
<pitti> Hi bluefoxicy, how are you
<bluefoxicy> pitti:  do you have numbers for ES' ASLR?
<pitti> numbers? no
<pitti> what about?
<bluefoxicy> pitti:  I'm just doing a comparison on the UDU, http://udu.wiki.ubuntu.com/PaXvExecShield linked to from http://udu.wiki.ubuntu.com/ProactiveSecurityRoadmap
<pitti> ah
<bluefoxicy> it doesn't matter much
<Kamion> lamont: CD rebuild happening now, will be a bit
<bluefoxicy> I'm not all that concerned over the level of ASLR, more over those last points on each
<pitti> bluefoxicy: ah, I didn't yet read that section, trulux added it
<bluefoxicy> re ES security policy is determined and enforced by the program, and is equal to or less than the security defined by the policy of the administrator (i.e. the administrator can force weaker, but not force stronger); whereas PaX policy is determined by the administrator and enforced by the kernel, and is equal to or greater than the policy defined by the administrator (the program follows the policy or crashes)
<koke> launchpad is dead??
<koke> oops
<jnc> replaced by darkwingduck
<dilinger> too bad disney would probably come after people for using that, it would be a great name for a piece of software
<hunger> Anyone got a working init script for the new dbus?
* hunger can no longer log into his box since dbus is never started.
<seb128> lamont: will gnome-media be retried by amd64's buildd?
<seb128> or does it need to be pushed?
<koke> hey, why are build logs bzipped now?
<seb128> smallers
<lamont> koke: because they're smaller that way
<koke> this is the obvious reason :)
<koke> but then, I'd love to be able to see them directly on firefox
<seb128> now we have to teach browsers to open bz2
<thom> lamont: can you make it so that they only get zipped after a week, or something?
<koke> seb128: that's the point
<lamont> thom: painful
<lamont> since you're actually looking at a mirror of the actual log archive...
<thom> lamont: come on! surely you if anyone can kludge it!
<thom> ;-)
<lamont> thom: actually, the mirroring needs some love sometime soon anyway...
<mjg59> Acer have /far/ too many bloody laptops on the market
<mjg59> I bet they're all different, too
<Kamion> hmm, the installer isn't giving me correct default hostnames from DHCP any more
<lamont> mjg59: you mean diff models, or that they customize each unit as it leaves the manufacturing line?
<lamont> thom: the mirror script is just an rsync across the entire buildLogs tree...  Just had to bump it to running every 20 min, since they were overlapping, and testing the locking code ...
<Nafallo> mjg59: btw, hotkeys like email should just work? or is it that I should be able to tell gnome to use that button/keycode?
* lamont waits for his find to finish
<lamont> Nafallo: you have to tell gnome
<lamont> system->preferences->keyboard shortcutws
<lamont> s/w//
<Nafallo> lamont: oki, I should s/\?/Y/ then :-)
<hunger> dbus upgrade is seriously borked!
<lamont> Nafallo: although that's really a #ubuntu question
<mjg59> Nafallo: At the moment, hotkeys are unlikely to do much by default. We'd like to improve that so they work by default on at least some machines
<zyga> mjg59: is there any progam that can easily check what key has been pressed?
<Nafallo> lamont: just verified my understanding of the wikipage :-).
<zyga> mjg59: like punching all the funny stuff manufacturer put on my laptop shell?
<mjg59> zyga: I'm not quite sure what you mean
<Nafallo> mjg59: ohh, oki. but it's "yes" if you can tell gnome what to do, right? :-)
<mdz> pitti: yay dhcp
<pitti> mdz: hehe, another one bites the dust :-)
<mjg59> Nafallo: No, we only consider them supported if they work by default
<zyga> mjg59: something that will say: keycode 0xFOOBAR after pressing 'email' button
<mjg59> zyga: xev
<zyga> mjg59: thanks
<lamont> thom: 262000 inodes for rsync to look at.  every run.  ew.
<mdz> pitti: is init next? ;-)
<mjg59> zyga: Alternatively, on the console, showkeys
<Nafallo> mjg59: oki :-). I'll go to turn that questionmark into a "No" then ;-)
<lamont> mdz: xorg :-0)
<Kamion> mjg59: how's the HP packaging stuff going?
<mdz> init runs on more systems than xorg
<mjg59> Kamion: Mm? It should be sorted.
<Kamion> mjg59: didn't you say yesterday that the tarball you sent me was buggy?
<mjg59> Ah, sorry, I emailed you once it was working
<lamont> Nafallo: you go into keyboard short cuts and hit the stupid button after telling it what you want it to do.
<lamont> is trivial
<pitti> mdz: yeah, I thought about "sed -i 's/root/noob/' /etc/passwd", then we do all remaining root programs in one shot :-/
<mdz> "buggy" and "completed" are not necessarily mutually exclusive ;-)
<mjg59> lamont: The number that gives us isn't very useful
<Kamion> mjg59: oh, ok. deconfused
<Nafallo> lamont: I know. I've done that since warty :-).
<zyga> mjg59: cool, all my extra keys are recognized
<Nafallo> lamont: I was asking because of LaptopTestingHardware
<lamont> mjg59: it's useful enough for gnome...
<mjg59> lamont: We want them to work without manual configuration
<mjg59> Which means knowing what the scancode produced is
<lamont> mjg59: ah, that requires some work, yes.
<zyga> mjg59: any page where I can report laptop model and keycodes?
<mjg59> zyga: Not really - what sort of laptop is it?
<zyga> mjg59: gericom blockbuster
<zyga> mjg59: maybe I could start such a page?
<pitti> mdz: I think inetd has to go next (throw out, not deroot)
<mjg59> zyga: Sure, that would be helpful
<sladen> zyga: 'showkey' under the console
<pitti> argh, btw:
<pitti> seb128: root     10129  0.0  0.3   5536  2628 ?        S    09:18   0:00 /usr/lib/gconf2/gconfd-2 16
<pitti> seb128: ^ what the hell is this?
<mjg59> zyga: Including the output from dmidecode would be useful
<seb128> pitti: gconfd-2 ? :)
<seb128> pitti: don't start GNOME as root
<zyga> mjg59: checking
<mdz> pitti: hmm, I thought we had removed it already
<pitti> seb128: I certainly didn't
<mdz> Kamion: is netkit-inetd in minimal intentionally?
<pitti> mdz: it's on ProactiveSecurityRoadmap so far
<zyga> mjg59: easy enough but that will clutter any wiki page
<mdz> Kamion: perhaps that pre-dated the netbase change
<seb128> pitti: bah, we have some GNOME apps running as root, like update-manager?
<seb128> and using gconf
* lamont takes pity on his kids and takes them their lunches.  back in a while
<Kamion> mdz: no, I just forgot to do the "The following packages should be moved from base to supported:" part of PackageSelection
<hunger> Does the "icon appearing on desktop on attaching usb HD" work again?
<mdz> g-v-m still likes to crash during upgrades (of dbus?)
<mdz> Kamion: I'm going to go ahead and move it then
<hunger> I'm asking since it does not here.
<Kamion> mdz: ok
<mjg59> zyga: Ok, just email me for now
<pitti> mdz: yes, the current gvm does not yet have the reconnection patch
<seb128> mdz: on dbus restarts
<pitti> mdz: I still need to backport it
<pitti> s/back/forward/
<Kamion> has sufficient of MailRoadmap happened for the other three (mailx, postfix, postfix-tls) to move?
<Nafallo> hunger: works for me :-)
<Kamion> hm, they already have
<hunger> mdz: Just did the dbus upgrade... it forgot to install dbus in place of dbus-1 and I could no longer log in:-(
<lamont> Kamion: uh, I thought I did that already.
<pitti> mdz: inetd> http://udu.wiki.ubuntu.com/InetdUsage actually boils down to: remove dependency from netbase, and fix tftpd-hpa to not use inetd by default (or depend on it)
<zyga> how can I reset my password for wiki?
<Kamion> lamont: you did, I'm just being spethul
<hunger> Nafallo: Worked with hoary, broken ever since.
<lamont> Kamion: seeds--breezy--0--patch-111
<lamont> s/1$//
<Keybuk> whoah
<zyga> mjg59: email, please?
* Keybuk discovers that zsh extended globs work for rsync
<lamont> Kamion: and postfix-tls is _gone_, not moved... :-)
<lamont> Keybuk: is that because zsh is doing the globing?
<Keybuk> I guess that's an extension of the fact it ssh's in and runs rsync using your shell
<mjg59> zyga: mjg59@codon.org.uk
<Nafallo> hunger: hmm, usbkey works on breezy. dunno if that's a significant diffrence.
<Keybuk> lamont: I did them in a remote bit
<lamont> ah, ok
<Keybuk> (rsync -avz syndicate:Desktop/*(/) .)
<hunger> Nafallo: Damn... maybe this is a kubuntu issue though.
* lamont really goes on the lunch run
<zyga> mjg59: mail away
<jordi> zyga: how are you doing?
<zyga> jordi: fixing another bug
<zyga> jordi: I'm re writing the parser basically - it's not large so It should take about an hour 
<zyga> jordi: I was wondering how to diff this thing
<zyga> jordi: I got my source via apt-get
<jordi> zyga: unpack another tree and diff -Nuar
<jordi> be careful not to let dpkg-source kill your working tree
<jordi> rename it to gtranslatior-1.1.6.precioussss
<Nafallo> hehe
<zyga> jordi: right, good idea
<Simira> hi Nafallo 
<Nafallo> Simira: hi there :-).
<bluefoxicy> kids suck
* bluefoxicy vows never to have kids
<Keybuk> rsync: connection unexpectedly closed (0 bytes received so far) [sender] 
<Keybuk> rsync error: error in rsync protocol data stream (code 12) at io.c(359)
<Keybuk> ...man... that's almost tla-like in its usefulness
<Nafallo> hehe
* pitti -> food
<Keybuk> (translation: rsync not installed on remote machine)
<zyga> mjg59: https://www.ubuntulinux.org/wiki/LaptopKeycodes
<JaneW> bluefoxicy: and are you pleased about that? ;)
<zyga> JaneW: bluefoxicy is just kidding, he loves kids
<zyga> ;-)
<JaneW> zyga: just stirring ;)
<Simira> one doesn't need to have ones own, right... let the others take care of that mini-human business... 
<koke> pitti: do you know if there is any plan on translating security announces??
<koke> oh, I see "-> food" :)
<koke> have to go now
<zyga> koke: interesting 
<zyga> koke: update manager could take them into account
<Lathiat> that would be rad
<koke> zyga: I think thats another different thing (of course interesting too)
<koke> sorry, I'm late
<koke> bye
<Kamion> nggg. netcfg hasn't changed since hoary; I don't understand why its DNS hostname guessing has stopped working
<JaneW> Simira: *LOL* ok well I have taken care of it for most of you then ;)
<Kamion> has getaddrinfo() forgotten how to return canonical names?
<dholbach> hey
<Simira> JaneW: you've got a whole bunch?
<JaneW> Simira: well actually it's 2, but sometimes that feels like a LOT! ;)
<zyga> JaneW: gzip them together to two chairs, it will feel more like 1.62 
<Simira> zyga: you couldn't have gotten a too in that sentence too, could you?
<Lathiat> we are sold out of too's
<zyga> Simira: I'm doing my best but this is a difficult language you know
<zyga> :-)
<JaneW> zyga: good idea
<JaneW> although they are pasted to the TV right now anyway ...
<Simira> zyga: what's your main lang?
<Simira> JaneW: how old?
<zyga> Simira: Polish
<JaneW> 3 & 5
<JaneW> both boys
<Simira> oh dear. You've got your hands full, then...
<JaneW> Actually they are getting easier already
<thom> JaneW: they'll get worse again :-)
<JaneW> although the hammering sound I just heard is concerning ;)
<Simira> yes, as long as they play with each other. To the older one gets "too old" for that "childish stuff"
<JaneW> thom: oh yay.
<thom> JaneW: well, if my brother and i are any yardstick, anyway
<zyga> Simira: he obviously need a bigger gameboy :)
<JaneW> heh
<zyga> needs
<Simira> JaneW: I don't envy you the next 20 years for a second....
<JaneW> thom: well you don't look like a yardstick, but I haven;t met your brother...
<thom> JaneW: hahaha
<JaneW> Simira: your time will come I am sure ;)
<Nafallo> ey! 23, 25. they should be out by then I guess? ;-)
<JaneW> out as in *out*?
<JaneW> or out pof the house?
<Simira> JaneW: hope not. I'll stick to the four-legged kind of creatures to take care of
<Simira> Nafallo: what's that got to do with it? :p
<JaneW> pof=of
<thom> well, we're 25 and 20 and neither of lives at home any more, but we started liking each other again by the time i was about 16 so we may well be atypical :-0
<Nafallo> Simira: hmm, true. my mother still calls one a day or so, and I moved 18 months ago or something...
<Simira> Nafallo: they're trouble until they're fifty. Just less when turning 25 and might get a girlfriend to keep'em.
<Simira> thom: I think that's normal
* JaneW must go.
<JaneW> Have a good evening everyone
<Simira> evnin' JaneW 
<zyga> being 23 and still living with my parents I guess I clasify as 'geek in the basement' :-)
<Simira> Nafallo: I've been out for 5 years, I'm still my mothers daughter. She's gotta throw me a wedding next year anyway
<Nafallo> JaneW: see you JaneW :-).
<thom> night jane
<JaneW> don;t forget to update your Breezy Goals!
<Simira> :D
<JaneW> *hint* *hint*
<Nafallo> Simira: yea? kewl!! is that a breezy+1 goal then? :-)
<Simira> Nafallo: no, we're not marrying until... uhm... a nonamed release yet. Wedded widgets? or something...
<Nafallo> *s*
<Simira> anyway, I'm into some windows gaming now...
<Simira> bbl
* mvo goes to play hockey now
<dholbach> have fun, mvirkkil 
<dholbach> mvo
<dholbach> :-)
<pitti> seb128: ?
<seb128> pitti: yep?
<mvo> thanks dholbach 
<pitti> seb128: epiphany is still vulnerable against homograph attacks; am I right that it only needs a recompile to use the new ffox?
<seb128> pitti: I don't think so, when have you updated ffox?
<seb128> pitti: epiphany has been rebuilt yesterday for dbus transition
<pitti> seb128: I mean for Warty
<seb128> oh, I've not tried
<seb128> but that depends on firefox yep
<seb128> have you tried without rebuilding?
<pitti> seb128: okay; we didn't fix warty yet, but once we do, we should fix epiphany as well
<pitti> seb128: in any case, hoary should be fixed?
<pitti> seb128: (http://www.shmoo.com/idn/)
<pitti> seb128: I'll try without rebuilding before
<dholbach> lamont: could you make vlc rebuild? to make it happy dbus-wise?
<pitti> dholbach: are you sure that it doesn't need a patch for the new API?
* dholbach pipes innocently and has another look
<dholbach> lamont: forget it, there are other plans for vlc :-)
<torkel> dholbach: bluez* and screem too maybe?
<dholbach> torkel: they need patches for sure
<seb128> pitti: k
<jdub> too many mono uploads ;)
<seb128> cool, they sell a "linux CD" with an hoary DVD and 20 nices pages of descriptions of the apps/screenshots (gnome-app-install, synaptic, desktop, ...)/config/... 
<torkel> dholbach: probably, and besides there is a newer version available upstream (for screem)
<ogra> jdub, :(
<dholbach> torkel: i tried them :-)
<ogra> jdub, these packages are just crazy....
<torkel> dholbach: ah :-)
<ogra> jdub, debhelper and cdbs mixed up all over the place... and currently i'm only trying to get all binarys built on all arches....
<doko> lamont: htmldoc doesn't contain any binary ... (1.8.23-1.3) please could rebuild/check ?
<Nafallo> what package break screem? I can't afford that right now.
<dholbach> dbus
<Nafallo> dholbach: thanx. I hold back then :-).
<pitti> Kamion: do you have an idea how to test (at the shell) whether a given locale is actually available in the system?
<pitti> Kamion: grepping for it in $(locale -a) doesn't really work because of "UTF-8" vs. "utf8"
<pitti> (of course this could be special cased, but it might fail for other encodings as well)
<lamont> doko: which architecture>?
<doko> i386
<hunger> pitti: Can't you use sed to strip the utf8 or unify them to a common spelling?
<pitti> hunger: of course I can s/UTF-8/utf8/, but will that always work?
<pitti> hunger: maybe there is a more robust method
<lamont> doko: broken Makefile... why do people think ignoring errors is a good thing, I wonder...
<lamont> elmo around>?
<hunger> pitti: You can always compare case insensitive.
<pitti> hunger: "mind the dash"
<doko> lamont: but works on the debian buildd's ...
<pitti> hunger: it seems that I need a small C wrapper to call setlocale() and check whether it returns non-NULL
<lamont> doko: was gcc-4.0 being borked on that buildd
<lamont> doko: the error was that gcc-4.0 couldn't exec one of the stages
<doko> lamont: reupload?
<lamont> already done
<lamont>  htmldoc_1.8.23-1.3build1 uploaded about :14
<cartman> lamont: thanks for new util-linux
<lamont> cartman: but does it fix the problem???
<cartman> lamont: dist-upgrading now but won't be sure until next reboot
<cartman> just showing my appreciation of you guys' fast bug fixes :)
<dato> pitti: well, if you want only shell (i.e., want to avoid the wrapper if possible), you could do:
<dato> if env LC_ALL="$whatever" locale 2>&1 >/dev/null | grep -q .; then echo Not valid; fi
<pitti> dato: oh, right, that error message is printed to stderr
<dato> &nod;
<pitti> dato: if [ "$(locale 2>&1 >/dev/null)" ] ; then echo invalid locale; fi
<pitti> dato: works fine, thanks
<dato> ok
<Keybuk> The Application "gnome-help" has quit unexpectedly.
<Keybuk> That's ok ... it started unexpectedly too
<Amaranth> Keybuk: Wanna see something funny?
<Keybuk> sure
<Amaranth> Keybuk: Open gedit and hit F1 a dozen times really fast
<Keybuk> and what does that do?
<Keybuk> other than give you 12 help windows?
<Amaranth> opens and crashes gnome-help a dozen times
<Keybuk> doesn't crash it for me
<Keybuk> usually yelp crashes because you close it before it's finished loading
<Amaranth> maybe you have to do it more than a dozen
<Amaranth> i know i did it ~50 times
<Amaranth> then all crashed
<seb128> what would somebody do that?
<Keybuk> leaning on the key?
<Amaranth> yeah
<Amaranth> people were talking about how to make it only open once because of what happens when you do that
<Amaranth> so i had to see what happened :)
<Keybuk> really?  personally I'd rather they fixed the bug that made it crash :)
<Amaranth> that'd be nice too but if you don't get 50 help windows open you don't have to worry about it
<jnc> Amaranth: that's like if you never launch a space shuttle
<jnc> never have to worry about it blowing up
<Amaranth> ;)
* jnc looks anxious
<jnc> i wish evolution would hurry up and get built for the new dbus improvements 
<dholbach> it did
<dholbach> some 5-6 hours ago
<jnc> oooh
* jnc pokes blinky bloopy buttons
<Treenaks> dholbach: then I wish beagle would get the new updates ;)
<dholbach> Treenaks: beagle needs more serious fixes
<dholbach> :-)
<Treenaks> dholbach: uh yes, but WHEN!?!
<Treenaks> dholbach: I NEED MY CRACK! :P
<dholbach> Treenaks: help in the UniverseCxxTransition - enough crack
<dholbach> :-)
<Treenaks> dholbach: explain how I get a sane breezy pbuilder tree then ;)
<dholbach> Treenaks: fabbione fixed debootstrap
<dholbach> apart from that you could just upgrade an existing hoary one
<ogra> Treenaks, speed up the builds and extend the day by some hours, then i'll be able to give you beagle crack in a blink
<dholbach> it's on wiki.ubuntu.com/PbuilderHowto
<Treenaks> ogra: oh cool, I'll see to that ;)
<Treenaks> dholbach: s/hoary/breezy/, I presume?
<jnc> hm how would i go about tracking new developments in breezy?
<dholbach> in the /etc/pbuilder/apt.config/source.list, yees
<dholbach> jnc read the breezy-changes mailing list, maybe
<ogra> Treenaks, i hope during the weekend i have the majority of mono stuff ready and building clean on amd64...
<jnc> 10-4
<dholbach> Treenaks: it's the last bit on the wiki page
<ogra> ...(which applys to the other arches as well indeed...but i focus on amd64)
<Treenaks> dholbach: doh.. OK, upgrading now
<doko> lamont: htmldoc doesn't have a binary yet
<doko> i386
<mdz> jamesh: do you have access to a powerpc system?
<lamont> doko: you're right... please fix htmldoc and upload
<lamont> Compiling ../htmldoc/htmldoc.cxx...
<lamont> gcc-4.0.gcc-opt: installation problem, cannot exec 'cc1plus': No such file or directory
<lamont> make[2] : *** [../htmldoc/htmldoc.o]  Error 1
<lamont> doko: specifically, gcc-4.0 can't build c++ code when g++-4.0 isn't installed...
<jbailey> I'd love to see us force -xc whenever gcc{-#.##}
<lamont> sounds good to me....
<jbailey> That way the parser would puke on it directly.
* lamont wonders how many more ftbfs things we'd get....
<lamont> elmo: can we have breezy-test?  or should I just turn it on?  mdz?
<jbailey> lamont: No more than now - they're all dying from elf symbol mismatches around the libstdc++ abi change.
<lamont> ah, true
<lamont> and doko's gonna make that even more fun next week, or will that fix it?
<jbailey> Well, fix like a bandaid over an oozing wound, but sure. ;)
<doko> heh, have 30 library packages converted, will do the rest for main tomorrow
<lamont> doko: thoughts on forcing -xc on gcc runs?
<doko> lamont, jbailey, you mean -x c ?
<lamont> ueaj
<lamont> yeah, even
<doko> hmm, what does this break?
<lamont> it clarifies things like the error that htmldoc has
<lamont> specifically, it's using gcc to compile c++ code, which currently fails (the 4.0 g++ compiler isn't there yet...)
<jbailey> doko: Anything that assumes that gcc can compile a c++ ap.
<lamont> (since it can't right now...)
<jbailey> lamont: right. =)
<doko> lamont: yes, let's do that then
<ogra> hunger, dont you want to join #ubuntu-meeting ? you made a lot of comments about malone
<dholbach> seb128: would you join #ubuntu-meeting for the malone meeting?
<seb128> THANKS
<seb128> I've forgotten
<jnc> is malone the name of the next release after breezy?
<lamont> malone is the bug tracking system
<lamont> the release following breezy is..... breezy+1
<jnc> thanks inifinity joe
<jnc> err you're name's not joe is it
* jnc :o/
<sladen> win 21
* lamont fetches kids
<lamont> sladen: stop swearing. :-)
<Riddell> mdz: are you going to let knetworkconf through?
<mdz> Riddell: yes
#ubuntu-devel 2005-05-21
<mdz> infinity: would smbfs add any other new packages to standard?
<melodie> does apt-authentication exist for Multiverse and Universe packages exist ? if yes where to find auth. keys  plse ?
<crimsun> yes, same key used for main restricted
<melodie> wao!
<melodie> fantastic!
<melodie> but not for other repositories I suppose ?
<melodie> such as.. backports ? :)
<melodie> crimsun: this detail is not written in the docs on the wiki  :)
<crimsun> melodie: backports is not at all associated with the official Ubuntu repositories
<melodie> ok
<melodie> what about adding the info you just gave me ?
<melodie> I come from here right now:
<melodie> http://www.ubuntulinux.org/wiki/DanielTChen
<melodie> https://www.ubuntulinux.org/wiki/AptAuthenticationInstructionsForHoary
<melodie> who is autorized to add modif and so on ? :)
<crimsun> anyone with a wiki acct may
<melodie> 'acct' ? (I'm a french newbee :)  )
<crimsun> (account)
<melodie> ok!
<melodie> if someone wants to add in there that the authentication key registered in Synaptic are also Ok for Universe and Multiverse it might be a good thing
<melodie> no ?
<JanC> melodie : everyone can get an account  :-)
<JanC> so everyone can change
<JanC> or add more info
<melodie> JanC: I understand, but
<melodie> I read on the wiki that crimsun belongs to this one devel team... Universe
<melodie> then I am just a newbie
<melodie> then if he tells me the key is valid
<crimsun> melodie: that fact is not at all connected with who may modify the page
<melodie> and ?
<crimsun> melodie: I only wrote AptAuthenticationInstructionsForHoary because it became a FAQ. Other people have contributed to the page and have modified it.
<melodie> ok, then I question inverse way: where is it indicated officially about the key being valid for these three repositories ? :)
<crimsun> melodie: it's not, but neither universe nor multiverse are supported by Ubuntu.
<melodie> yes
<crimsun> feel free to add the clarification yourself :)
<melodie> then how come 
<melodie> "yes, same key used for main restricted"
<melodie> crimsun: I am a serious person
<JanC> crimsun : I think she means maybe you should use other keys ?
<melodie> and wouldn't affirm something I am not absolutely sure 
<JanC> or at least expected that ?
<melodie> JanC: I mean: do we need to add keys and if not why ?
<crimsun> melodie: I'm sure there was a reason to use the same key for all three repos. mdz/elmo can clarify.
<melodie> and if yes where and how ?
<JanC> at the moment the keys are the same, so adding this info to the wiki is okay
<melodie> ok
<melodie> are there somewhere archives where I could find confirmation ? that's for a doc I help about
<melodie> because I'm a very interested newbie full with questions and want to give sure answers :)
<melodie> I looked in many pages in Google
<melodie> and didn't find anything appropriate 
<melodie> that's why I came here :)
<dholbach> that's maybe because lots of documentation hasnt been written
<crimsun> melodie: currently you'll need to ask mdz, jdub, or elmo. Please note also the output of ,,sudo apt-key list''.
<dholbach> or mvo
<crimsun> yes
<melodie> crimsun: ok
<melodie> thanks to all :)
<JanC> melodie, I found out that the keys are the same by trying it  ;-)
<melodie> JanC: did you dl something ? :)
<melodie> crimsun: now I know where are these keys in my files :))
<dholbach> sleep tight everyone
<melodie> thanks, same to you
<JanC> yes, since I use Ubuntu for some months  :)
<melodie> did you sometimes get reject authentication messages ?
<melodie> or better said: fail auth...
<lamont> melodie/crimsun: the signature is on $DISTRO/Release, which has the md5 and sha1 sums for each of the Packages, Sources, etc files in each of the components in the release.
<lamont> hence you don't get to choose a diff key for different components (main,restricted,etc), since there's only one file to sign
<melodie> lamont: ok thanks
<melodie> good night  :)
<pitti> night everybody
<Unfrgiven> hi all
<Unfrgiven> who apart from fabbione are on the kernel team? i've found some issues with the 2.6.12 kernel image that i wanted to report
<mdke> you could file bugs in bugzilla
<thom> Unfrgiven: file bugs, please
<Unfrgiven> mdke: yeah i can do that. i just wanted to have a quick chat and ask some questions... but i guess i can file the bug first
<mdke> Unfrgiven, bugs are easier for people to remember :)
<Unfrgiven> mdke: fair pojint :)
<Unfrgiven> s/pojint/point
<mtbeedee> hola
* daniels STARES at his inbox.
<daniels> 4528 ND  May 12 Juanita Lara    (   0) Finally a Patch that works!... gamin
<daniels> no patch can make that thing work
<mtbeedee> what thing?
<thom> hahahaha
<zul> evilness
<thom> AHAHAHAHA
* thom falls off his chair laughing
<thom> it's definitely time for sleep
<daniels> night dude (if you are in fact going to bed)
<thom> yes
<thom> i
<thom> am
<thom> dammit
<zul> then go dammit
<thom> rock on: http://kerneltrap.org/node/5103
* thom is gona now
<lamont> right.  time to go get beaten up for a bit.
<Nafallo> hmm, how the hell did the clock turn almost 3?
<Nafallo> I was to sleep early I thought.
<Nafallo> well, goodnight :-P
<jnc> yay, evo working again in breezy / amd64
<CarlK> does anyone care that the matrix screen saver"
<CarlK> er
<CarlK> does anyone care that the "matrix screen saver" says KNOPPIX.RU at one point?
<robitaille> CarlK,   it does?  I used that screensaver for a while, but I never noticed.
<jsgotangco> me neither
<robitaille> interestingly if you check that web site (knoppix.ru), there is a picture of sadfl  on the main page (in the middle of that long front page)
<schweeb> it's subliminal sabdfl promotion
<MrKeuner> hi, bittorrent tracker is down.
<greg> hi guys i did a doggy reinstall of ubuntu over a debian i kept the /home partitoin form debian its all working fine excpept that i would like to import the users from debian to ubuntu witch files should i copy ? i have a ssaved of my debian etc
<MrKeuner> /etc/passwd and /etc/shadow and home directories with correct user:group infos
<jsgotangco> hah
<Burgundavia> greg, that kind of question belongs in #ubuntu
<greg> ha ok
<greg> thks !
<MrKeuner> that bittorrent which is down is the one at torrent.ubuntu.com
<jdub> hrm, anyone have tim morris's email?
<jsgotangco> the guy who did the lightning bof?
<robitaille> jdub,  I think it is  tjlmorris@gmail.com (according to http://www.ubuntulinux.org/wiki/WinningTheDesktop)
<jdub> hey robitaille!
<jdub> dude!
<jdub> :-)
<jdub> thanks :)
<robitaille> np
<jdub> robitaille: i didn't realise you hung out on irc ;)
<fabbione> morning
* wasabi has implemented his .apt file support
<wasabi> sorta kinda
* Lathiat waits for the uproar
<jdub> mdz: somehow missed your email about -changes, doing now
<mdz> jdub: thanks
<jamesh> mdz: you were asking me earlier if I had access to PPC?
<jamesh> mdz: I don't.
* lamont sleeps
<fabbione> night lamont
<jsgotangco> bye lamont 
* wasabi double clicks on a .apt file
* wasabi watches software install.
<jsgotangco> oohhhh
<daniels> elmo: please sync xft
<wasabi> Huh. So how can you make a .desktop file use gksudo AND pass an argument?
<Lathiat> you have to put the command and arguments in quotes i think
<wasabi> thought %u had to be at the end.
<wasabi> wchih kinda makes that hard
<wasabi> yeah that basically doesn't work
<wasabi> great.
<wasabi> gues gksudo really needs a -- arg
<daniels> elmo: please sync rpm
<daniels> elmo: please sync vorbis-tools
<wasabi> gksudo needs a --desktop option.
<daniels> elmo: please sync tcl8.4
<Lathiat> elmo needs an irc script to sync things for him
* jdub can't believe elmo accepts sync requests via irc :)
<Lathiat> heh
<lifeless> the 'I can't believe its not elmo' script
<Unfrgiven> fabbione: ping?
<fabbione> pong
<Unfrgiven> im having some issues with the 2.6.12-1 image
<Unfrgiven> namely ndiswrapper
<Unfrgiven> i logged a bug. was it a known issue to you?
<fabbione> bug number?
<Unfrgiven> fabbione: ill just fetch it
<Unfrgiven> 10670
<tritium> daniels, I'm off to bed...
<Unfrgiven> on the ndiswrapper forums, other people have reported the same problem
<Unfrgiven> so basically its an upstream problem
<Unfrgiven> im going to give the release candidate of the next version of ndiswrapper a shot. if you want, i can let you know if it works
<fabbione> dude
<fabbione> that's all other than a critical bug
<fabbione> you are reporting a bug on a non-supported kernel and it is ok
<fabbione> but only one external feature is broken
<fabbione> that's at the best a normal
<Unfrgiven> apologies... i treated is as a failure of a network device
<Unfrgiven> one that works fine in the previous kernel release
<daniels> tritium: ok, night dude
<fabbione> it will matter after the kernel will be final and in main
<fabbione> that will be treated as regression
<fabbione> right now it is not
<Unfrgiven> ok sorry about that... im learning more all the time :)
<fabbione> critical is when it eats your computer
<Unfrgiven> haha ok :)
<tritium> daniels, night.  I think crimsun is in there now, so you're not the only active op
<fabbione> Unfrgiven: please add an url to the upstream discussion/reports
<fabbione> that will help us to track it
<Unfrgiven> ok ill do that
<Unfrgiven> how do you feel about pulling in the release candidate for the next version of ndiswrapper
<daniels> tritium: yeah, we should be alright; cheers
<fabbione> Unfrgiven: only if it is worth the trouble, since it needs also a userland update
<fabbione> otherwise it is pointless
<fabbione> and i really don't have the time to worry about userland too
<Unfrgiven> fabbione: if i build and install the latest ndiswrapper module. when i modprobe, will it pick up the one in /lib/modules or will it get the one from initrd?
<fabbione> ndis is not in the initrd
<fabbione> you can build the module, replace the one in /lib/modules...
<fabbione> depmod -a
<fabbione> and modprobe it
<fabbione> that should do
<daniels> GNAARR SEB
<Unfrgiven> fabbione: excellent. thanks. i'll give this a shot when i get home from work and let you know how it goes.
<Unfrgiven> fabbione: thanks again for your help
<fabbione> np
<Unfrgiven> fabbione: oh and by the way i also wanted to say that you're doing an awesome job with the kernel! 2.6.12 is the first kernel that has supported suspend to disk & mem on my laptop
<Unfrgiven> breezy is gonna rock!
<fabbione> Unfrgiven: well thanks upstream and the other guys :)
<fabbione> i am only doing the packaging ;)
<fabbione> but be aware that until 2.6.12 is final from upstream we are going to break some random stuff here and there
<fabbione> to pull in some new features
<Unfrgiven> fabbione: yeah them too :)
<Unfrgiven> fabbione: yep i realise. what surprises me is that the kernel autoinstall magic in the menu.lst puts the new kernel as default boot... thats a bit scary
<fabbione> if you ask for crack.. you get it :)
<Unfrgiven> fabbione: one thing that pisses me off about the kernel image autoinstall, is that it blows away my "vga=840" append... can i make it a permanent change?
<fabbione> Unfrgiven: if you add it between the lines marked as DO NOT MODIFY.. well you asked for it :)
<fabbione> i need to check how to do that...
<fabbione> i don't usually add custom stuff
<Unfrgiven> framebuffer stuff is very useful though... especially for seeing all the messages during bootup
<fabbione> that's not what i questioned :)
<Unfrgiven> and lots of people need to put stuff like noapic, etc.
<fabbione> i will check on that.. 
<fabbione> i need to go offline for 20 minutes or so
<fabbione> bbl
<jsgotangco> ogra, hey!
<`anthony> btw - I've got the CPU scaling working on my dell 5150 laptop (uses a P4M). I needed to manually modprobe speedstep_ich.
<fabbione> `anthony: i think you need to bug thom on powernowd
<Unfrgiven> `anthony: i have the exact same laptop. i had to do the same.
<fabbione> daniels: ping?
<daniels> pong
<fabbione> daniels: i need help to setup xorg on this machine: http://www.big-boys.com/pictures/picture1023.html
<jdub> ha ha
<daniels> fabbione: you're on your own :P
<fabbione> daniels: the 4th monitor from the left side is only 99Hz instead of 100Hz and glxgear is only 293287328732 fps !
<daniels> fabbione: don't use nvidia, then :P
<fabbione> ehhee
<bob2> that's a pretty bad benchmark result fro mglxgears
<daniels> hm
<daniels> breezy is still too boring
<daniels> i wonder if I should drop the /usr/X11R6 -> /usr transition on it tonight
<daniels> or, at least, the start of it
<jdub> m0dular!!!
<fabbione> daniels: i think it would be wise to let Kamion to deliver the first CD
<froud> African Greetings, have not been here for awhile. For breezy, if anyone is developing new apps that will need docs for packaging, please can they let me know. Thanks
<fabbione> Cluster 1 :)
<daniels> does it run on clusters?
<fabbione> no.. Cluster of Badgers 
<daniels> heh
<fabbione> but yeah we will soon be able to offer clustering
<jsgotangco> "What Geeks Do When Their Bored"
<daniels> ARGH
<fabbione> BADGER BADGER BADGER :)
<daniels> i wish people would stop reporting #7878
<daniels> that thing does need a hoary-update though
<fabbione> daniels: does X build with gcc-4.0 btw?
<daniels> fabbione: don't think so; gotta pull some fixes from HEAD for that
<fabbione> afair we don't have C++ stuff, do we?
<bob2> has anyone else done the "compile a whole distro with gcc 4.0" thing yet?
<daniels> fabbione: BUARRRR WRONG
<daniels> fabbione: libglu
* fabbione sighs
<daniels> bob2: iirc fc4t2 did that
<daniels> fabbione: so we get the fun of transitioning that
<daniels> fabbione: and I get the fun of doing dbus, again :P
<fabbione> daniels: about dbus.. are you going to enable the mono stuff?
<fabbione> if so can you be careful on what arches are you going to push it?
<daniels> fabbione: yeah, once mono is in main
<fabbione> sparc mono still doesn't build
<daniels> fabbione: ... no mono on sparc?
<fabbione> i need to look at it
<fabbione> last build didn't go
<daniels> sigh
<daniels> well, it won't happen till mono hits main anyway
<fabbione> ok
<fabbione> god.. the BreezyGoalPage starts to be impossible to edit
<fabbione> ETOOMANYTAGSCOLOR
<JaneW> fabbione: well lets aim to set them all to green... ;)
<fabbione> JaneW: it's just a mess to edit from the web
<froud> fabbione: docteam will take docbook and has svn if you want more stability
<JaneW> fabbione: agreed, I wish the edit page would be more tabular
<jsgotangco> JaneW, PDASupport now HighPriority as edited by mdz
<fabbione> JaneW: can you please send out a request to everybody to update the kernel field so that we can snapshot and remove it from the webpage?
<JaneW> jsgotangco: done
<JaneW> fabbione: sure
<fabbione> thanks
<fabbione> or add a dependency on LinuxKernelRoadMap would work too
<fabbione> i just need to have a list of things that will affect it
<fabbione> either way it works
<JaneW> fabbione: which do you think people are more likely to actually do? I am thinking the tables is nice and visible, and relatively easy to update quickly...
<fabbione> JaneW: right.. let's update the table and later i will move the list to LinuxKernelRoadMap
<fabbione> Unfrgiven: the thing you are searching for is called kopt in /boot/grub/menu.lst
<`anthony> fabbione: Ok. Will log a bug.
<fabbione> `anthony: thanks
<`anthony> fabbione: Is it best to log a single bug per non-working thing, or one mega-bug?
<`anthony> e.g. battery monitoring doesn't work, that sorta thing.
<fabbione> `anthony: one bug per problem
<fabbione> it's easier to keep track of the bug status
<`anthony> fabbione: no probs. ta.
<fabbione> np
<pitti> Morning
<fabbione> morning pitti
<Unfrgiven> fabbione: thanks
<ivoks> firefox has issue in ubuntu
<bob2>  /topic
<ivoks> but this is development issue :)
<jsgotangco> you can file a bug
<ivoks> i will now
<doko> good morning
<pitti> Hi doko
<jsgotangco> pitti, doko hi
<pitti> Hi mvo 
<mvo> hey pitti 
<mvo> morning all
<jsgotangco> hey
<pitti> tseng: somebody wanted to update ethereal for -security, was that you?
<mvo> ping doko
<Kamion> pitti: locale stuff> I'd have produced a cut-down one-liner version of /usr/sbin/validlocale, myself
<Kamion> pitti: (validlocale is in base-config - which is awkward - and is *nearly* what you want, but not entirely)
<pitti> Kamion: in the meantime I found a shell-only solution
<doko> mvo: pong
<pitti> Kamion: if [ "$(locale 2>&1 >/dev/null)" ] ; then echo invalid locale; fi
<Kamion> mm, I was dubious about capturing stderr rather than having something that looked only at return codes
<pitti> Kamion: yeah, I already finished my testlocale.c at that point, too :-)
<Kamion> you should be able to do it in perl in a lot less code :)
<pitti> Kamion: yeah, in the new architecture I have perl, but yesterday I fixed that bug in the Sarge version
<Kamion> if ! perl -MPOSIX -e 'exit(setlocale(LC_ALL, "") ? 0 : 1)' 2>/dev/null; then echo invalid locale; fi
<Lathiat> sheesh, people complkainign cus they didnt get their shipit cds 2 weeks after they ordered them
<jdub> people seem to think it's like amazone
<Lathiat> yeh i guess
<cartman> heh
<cartman> its 2-3 months and still no Warty cds here ;)
<Treenaks> cartman: #define here
<cartman> Treenaks: well I got ADSL now so its not important but here == Turkiye
<Treenaks> cartman: strange
<cartman> well page said they shipped it to the guys who will ship it to me
<cartman> :/
<jdub> cartman: you probably ordered them after the switch to hoary only mode :)
<cartman> jdub: hehe nay :)
<cartman> international posting is not perfect so its expected anyway :/
<cartman> people tend to steal and do other stuff
<cartman> but Microsoft Germany sent my Windows 2000 sp4 cds correctly, lol ;)
<pitti> mvo: btw, in your language selector, how did you name the two colums?
<pitti> mvo: "Desktop translation" and "Content creation"?
<mvo> pitti: they are named "Translation" and "Input", but's it done with glade, so it can be easily changed
<pitti> mvo: okay, that sounds fine, and short enough 
<mvo> pitti: I just took it from your mock-up (or was it sebs?) :) I will probably add a label with some (short) text at the top of the dialog 
<pitti> mvo: yeah, a bubble help would be cool
<pitti> or some label, even better
<mvo> pitti: tooltips are not support in the gtktreeview, this caused me some annoyance already :/ 
<pitti> mvo: oh, an explanatory label is certainly fine
<mvo> pitti: the label is the cheap way to work around that
<pitti> mvo: it's also more obvious
<mvo> pitti: yes
<jsgotangco> mdz, hello
<mvo> jsgotangco: mdz is probably sleeping now
<jsgotangco> yeah i just remembered
<Burgundavia> is 2:20 for him, just like me
<jsgotangco> hah and you're still awake and just starting up
<Burgundavia> mdz has a job, I don't
<JaneW> also mdz is on leave now :P
<bob2> so no calling him to tell him you have gtk bugs
<bob2> that what seb is for
* Burgundavia started a bug with "seb don't shoot me for this one"
* seb128 slaps bob2 
<bob2> :-)
<Lathiat> haha
<seb128> yeah, some people keep filling bugs to ask a fork of the upstream UI
<seb128> that's not going to happen
<seb128> we don't want to fork packages from upstream
<JaneW> anyone have a working e-mail address for Colin Applegate? (edubuntu)
<Mithrandir> JaneW: colin.a@gmail.com, apparently.
<JaneW> hmmm, just used that one '
<JaneW> Delivery to the following recipient failed permanently'
<Mithrandir> it's the only UID on his GPG key.
<Mithrandir> JaneW: try askin Jeffrey Elkner (jeff@elkner.net), one of the people whom he was at UDU together with?
<JaneW> Mithrandir: I'll do that thanks.
<jsgotangco> Jeff is colin's teacher i believe
<JaneW> has anyone been able to open the link to keybuk's UDU photos?
<Burgundavia> JaneW, link?
<Treenaks> where?
<jsgotangco> keybuk nope still waiting
<JaneW> http://www.netsplit.com/travel/2005/australia/
* JaneW gets a '500 server error'
<Burgundavia> JaneW, I just got through
<JaneW> hmm...
<jsgotangco> ohhh now were in
<JaneW> :( *sulk*
<JaneW> ooh looks like we have blast off...
<Burgundavia> took as age thought
<jsgotangco> oohh Keybuk did the bridge climb
<Burgundavia> ah crap, I need a #ubuntu op
<Burgundavia> nev mind
<JaneW> man he did everything!
<jsgotangco> JaneW, he's loaded heh
* JaneW *mutters* and *curses*
<jdub> hrm, can anyone tell what keybuk is using for his album?
<jdub> will have to ask next time he's around
<bob2> custom stuff, of course
* JaneW 's biggest problem was not getting a chance to leave the confines of the prison ^h^h^h^h^h^h hotel... and then there was the it' flipping exensive in Australia problem...
<mjg59> Australia is expensive? Wow.
<Burgundavia> for someone from za, yes
* mjg59 must visit ZA :)
* Burgundavia hasn't been in 10 years
<jsgotangco> well au is expensive for me too
<Treenaks> mjg59: next ubuntu conf?
<Treenaks> :)
<JaneW> mjg59: yes ZA is cheap for most ppl
<Burgundavia> uk is freaking expensive for everybody
<JaneW> Burgundavia: YES
<Burgundavia> the measly canuck dollar didn't go very far
<JaneW> whereas Thailand is cheap for everybody, and virtually free for some...
<jsgotangco> everything is expensive for me :(
* jsgotangco curses local exchange rates
<Treenaks> jsgotangco: from where?
<mjg59> Tollef never understands it when we talk about places being expensive
<jsgotangco> Treenaks, Philippines
<Treenaks> mjg59: that must mean Norway is expensive as hell
<jsgotangco> heh
<mjg59> Treenaks: Oh, yes. Very.
<JaneW> jsgotangco: cool lets go there next! :))
<Mithrandir> mjg59: the UK has virtually free beer
<Treenaks> mjg59: I know the UK is expensive.. but most countries aren't (Netherlands)
<Burgundavia> where is the next dev conference?
<jsgotangco> probably somewhere in south america or europe
<mjg59> Norway is ridiculously expensive compared to the UK
<Mithrandir> Treenaks: .nl isn't that cheap, really.
<Treenaks> Mithrandir: for me it is
* jsgotangco hopes he doesn't end up eating cup noodles on the next trip
<Simira> mjg59: you think? I don't think so, actually.
<Simira> mjg59: some daily food are maybe a little cheaper, due to the EU-rules
<ajmitch_> jsgotangco: you'd just need to save up a bit
<mjg59> Simira: Based on my experience, yes
* jsgotangco will start eating crumbs then
<jdub> pitti: you seem busy :(
<pitti> jdub: always, why? :-)
<mjg59> Conferences in Norway always cost me more than elsewhere...
<Mithrandir> mjg59: eating out is usually expensive in .no, for instance.  That's one of the things you end up doing when at conferences.
<jdub> pitti: lots of yucky USN action
<Simira> mjg59: ok, I wouldn't know. And I don't drink much beer :p
<pitti> oh, yes...
<pitti> jdub: right now I'm processing the flood of universe security updates from astharot; I will be glad if he can upload himself :)
<jdub> heh :-)
<astharot> ;)
<Treenaks> Mithrandir: for that reason we should try The Netherlands ;) it's not noticably more expensive than Mataro was (eating out/beer-wise)
* Simira is totally in for a conference in Holland!
<seb128> elmo: gwget2 sync please
<Simira> Mithrandir: if we're going to Holland, we're definitely doing a week, or at least a weekend extra!
<Mithrandir> Simira: oh, any particular reason?
<Simira> Mithrandir: I like it there. I spent a week there in -98, and I want to go there again. There are a lot of nice places to see. But the flowerpark you'll have to do on your own, if you want to go there. It's boring.
<Mithrandir> heh
<Treenaks> flowers are very boring..
<Mithrandir> flowers are very nice.
<Treenaks> I work next to the Amsterdam Flower Market.. they get boring
<Simira> Mithrandir: sure, but a large park of tulips are sort of boring after 10 minutes...
<Mithrandir> Simira: they're not very talkative, no..
<Burgundavia> pitti, seen that messy bug with ff1.0.4?
<pitti> Burgundavia: yeah, but the patches are not yet public
<Simira> Mithrandir: we kan go to the bathing place at where we lived last time. It's so cool! I don't remember the name now, though...
<pitti> (which is stupid, but we can't help it)
<jsgotangco> tulips!
<jsgotangco> windmills!
<jsgotangco> heh
<Treenaks> jsgotangco: drugs!
<jsgotangco> hah
<Treenaks> (to finish the stereotype)
<jsgotangco> thats too subtle
<jsgotangco> shrooms!
<elmo> seb128: done
<Treenaks> Simira: bathing place?
<Treenaks> Simira: you mean Noordwijk or Katwijk or something (a coastal town)?
<seb128> elmo: thanks
<Simira> Treenaks: we lived at this camping place/hut rental place which had a indoor pools and stuff, looked like a tropical forest. :p Half an hours drive west of Zwolle, iirc,,,
<seb128> JaneW: is there any explanations for the indicators for BreezyGoals ... ie, what is "Pending"? Pending what? how is that different of WIP?
<Treenaks> Simira: oh.. my family comes from that area :)
<seb128> and "TBC"?
<Mithrandir> Seveas: pending implementation, afaik.
<seb128> Mithrandir: I guess that's for me ... how is that different of WIP?
<Mithrandir> seb128: no idea.  Prod JaneW for a legend, I guess.
<fabbione> Mithrandir: you are the procmail expert, aren't you? :)=
<jdub> Mithrandir: WE DEMAND THAT YOU ANSWER!
<seb128> that's what I was doing :)
<JaneW> seb128: oh dear I think I am confussing ppl, I'll put some explaining text in the page
<jsgotangco> To Be Continued? 
* jsgotangco hides
<Simira> Treenaks: if you have an url for me to a decent country-map, I'll try to find the place.
<JaneW> seb128: but pending means specs done, and activity is about to start...
<seb128> JaneW: confussing ppl? how so? :)
<Mithrandir> fabbione: given that I don't even use procmail, I doubt it.
<seb128> JaneW: k
<seb128> thanks
<seb128> JaneW: and TBC?
<Mithrandir> to be completed
<Simira> Mithrandir: oh, they have a dolphin-park!
<fabbione> Mithrandir: oh ok :)
<Mithrandir> Simira: dolphins are nice.
<seb128> k, thanks
<JaneW> seb128: that was just the default, before you guys update it, literally means 'to be completed'
* seb128 updates now
<JaneW> THANKS!
<Simira> Mithrandir: I think they have penguins as well ;) At least sea lions and lots of other stuff
<seb128> JaneW: k, so the TBC need to be changed ... what I wanted to know, thanks :)
<JaneW> (notice my excitement and happiness?) :)
<Mithrandir> Simira: I've been there, I think.
<Treenaks> Simira: Harderwijk
<dholbach> hellas
<Simira> Mithrandir: That's unfear! When? I wanted to show it to you!
<Mithrandir> Simira: ten-ish years ago.
<pitti> Moin daniels 
<pitti> Moin dholbach , I meant
<jsgotangco> bye folks have  a great weekend (me going out of town)
<dholbach> hey pitti
<Kamion> hmmm, adding local packages to the desktop task in the CD builder is non-trivial at the moment
<ajmitch_> hi dholbach 
* Kamion perpetrates an egregious hack
<dholbach> hey ajmitch_ :-)
* fabbione -> food
<jdub> mdz: ping
<Burgundavia> jdub, is 3am here
<Burgundavia> jdub, also "JaneW also mdz is on leave now :P"
<Mithrandir> Burgundavia: that just means he'll be working during the night instead of during both day and night. :P
<Burgundavia> lol
<Lathiat> where can i find hct?
<pitti> Lathiat: Keybuk promised to package it soon
<Lathiat> can i even get the source or?
<pitti> Lathiat: I don't think so, not right now
<Lathiat> ok
<Lathiat> damn all these closed projects
<pitti> it will be open source once it actually works 
<pitti> but they don't want to release alpha software
<Lathiat> yeh im just griping additioanlly about  the fact i cant get to launchpad yet the specs are there and linked off all the UDU pages. :)
<Lathiat> (but i understand)
<Lathiat> geez jdub is right, these people do think shipit is amazon
<Burgundavia> Lathiat, maybe shipit needs to be more clear that it might take a while
<Lathiat> im pretty sure it does
<Burgundavia> some people are morons
<Lathiat> yeh well
<Lathiat> such is life unfortunately
<Burgundavia> have you seen the breezy forum?
<Burgundavia> all the new package requests
<Lathiat> interesting.. i ended up with 3 warty shipments and only 2 were logged on the shipit database
<Lathiat> i only ordered 2 anyway, a 3rd shipment just ended up at my door one morning. :)
<Burgundavia> warty is still useful
<Lathiat> but i was happy i needed more anyway
<Kamion> Burgundavia: what a bizarre place to put new package requests
<Burgundavia> Kamion, new defaults mostly
* Lathiat looks at the breezy forum
<Burgundavia> and most of it is already being done or has been rejected as total crack
<Lathiat> ugh
<Lathiat> everyone whinging about breezy
<Lathiat> NO SHIT POEPLE
<Kamion> Burgundavia: nevertheless - why put requests somewhere developers generally don't pay much attention to?
<Burgundavia> no idea
<Burgundavia> Kamion, should I summarize for -devel? is that useful?
<Kamion> not if it's total crack :)
<Burgundavia> let me see if I can dig the useful bits out, stuff that hasn't been discussed
<Lathiat> ubuntuforums is kinda like #ubuntu
<Burgundavia> yep
<Lathiat> blind leading the blind most of the time
<Burgundavia> lots of noise
<Burgundavia> Kamion, can you comment on this? 2. disable (!) the auto-testing of apt-repositories during the installation. it causes system-freezes with a lot of routers during the install process. 4.10 didn't have this feature and was painless to install. 5.04 was, sorry to say so, a catasptrophe in this respect. no newbie will be able to overcome this obstacle!!!
* JaneW has added a 'nag of the day (tm)' section to the Breezy Goals page ;)
<Burgundavia> in fact that whole comment --> http://www.ubuntuforums.org/showpost.php?p=142696&postcount=15
<Kamion> Burgundavia: known bug
<JaneW> brace yourselves
<Burgundavia> Kamion, and the 1st comment on that comment?
<pitti> bah, bloody gtk bug freezed my X
<Kamion> Burgundavia: bogus
<seb128> pitti: don't blame gtk
<Burgundavia> Kamion, figured, but I thought I would ask
<Burgundavia> Kamion, thanks
<Kamion> Burgundavia: the claim about 4.10 makes no sense; 5.04 has not changed in this regard
<Kamion> Burgundavia: comment #2 is bug #8265
<Burgundavia> ok
<doko> is there a way to lock a wiki package for editing?
<doko> s/package/page
<seb128> doko: when you start editing it the wiki locks the page for some time
<seb128> doko: and the lock is updated when you "preview" your changes
<seb128> ie: if you edit for some time do some previews during the edition
<ogra> doko, you could write a scrip that constantly reloads the preview page, that would lock it permanently then ;)
<ogra> script even
<doko> hmm, not very convinced ...
<dholbach> see you later
<Kamion> mjg59: will you be able to test an HP CD image this afternoon?
<pitti> mvo: btw, did you ask for a dbus reconnection patch?
<Kamion> mjg59: I just had to add a few features to cdimage to allow adding more packages to the desktop seed, but it should all be good now
<Kamion> mjg59: except - fuck. gnome-bluetooth, i810switch, and irda-utils are in hoary/universe. that's going to be fun
<mjg59> Kamion: Blurgh. Probably not this afternoon, but I can manage this evening
<Kamion> mjg59: ok
<Kamion> mjg59: so far, I've built all the .debs, branched the seeds and debian-cd, given up on hacking germinate, hacked cdimage instead
<mjg59> Heh :)
<mjg59> Kamion: Actually, scratch that, no group meeting today so I can do a test
<Kamion> mjg59: ok, cool. I'm doing a breezy CD image build first to make sure I haven't broken cdimage
<Kamion> I'm just going to shove those packages from universe into the local archive by hand
<Kamion> don't tell anyone
<mjg59> Haha
<chmj> hehehe
<Kamion> and of course gnome-bluetooth has a bazillion dependencies
<Kamion> madison-lite `dpkg -f gnome-bluetooth_0.5.1-1ubuntu7_i386.deb Depends | sed 's/, /\n/g' | cut -d' ' -f1` | grep hoary/universe
<pitti> Kamion: speaking of madison, do you know a tool similar to madison which inspects /var/lib/apt/lists instead of a full mirror?
<Mithrandir> pitti: madison-lite?
<Kamion> mjg59: complete list of packages from universe appears to be: gnome-bluetooth i810switch irda-utils libbtctl1 libgnomebt0 libopenobex-1.0-0 python2.4-libbtctl
<Kamion> pitti: apt-cache madison
<pitti> Mithrandir: I thought it requires a mirror?
<Mithrandir> pitti: just the Packages files.
<pitti> Kamion: cooool, thanks
<Kamion> seb128: reping, re gnome-themes installability?
<mjg59> Kamion: Ok, sounds about right
<seb128> Kamion: pong. What's wrong with it exactly?
<seb128> Kamion: you spoke about gtk2-engines-crux IIRC, which is universe?
<Kamion> seb128: it's not installable, same as last time I asked
<Kamion> does it just need packages to be promoted from universe?
<seb128> yep
<Kamion> ah, thanks, that wasn't clear to me yesterday
<Kamion> elmo: please promote gtk2-engines-{crux,lighthouseblue} to main
<mvo> pitti: if you have the dbus-reconnect patch ported, please send it to me by mail
<pitti> mvo: it just started to work three minutes ago :-)
<mvo> pitti: :)
<pitti> mvo: and now it even works all(most) of the time, unlike Hoary's patch, which failed for longer restarts
<Kamion> nggg
<Kamion> elmo: would it be possible to fix warty and hoary's Release files in the same way you did for breezy (adding restricted/debian-installer/...)? I'm trying to build hoary-plus-a-bit CD images fairly urgently, and can't due to apt complaining that those bits are missing from Release
<pitti> mvo: http://bugzilla.gnome.org/attachment.cgi?id=46393&action=view
<seb128> pitti: what bug is that?
<elmo> Kamion: err, do i really have to?
<pitti> seb128: http://bugzilla.gnome.org/show_bug.cgi?id=170894
<seb128> elmo: I can change gnome-themes if you prefer
<elmo> kamion: we've managed to avoid modifying a stable release after release so far?
<elmo> seb128: not the promotions
<pitti> seb128: g-v-m reconnection after dbus restart; I believe something similar is also required for gvfs
<seb128> elmo: oh, k
<seb128> pitti: yeah, I know the context, I was asking the number so I can ping upstream to get a comment on it :)
<Kamion> elmo: alternatively, you could make apt stop caring about it?
<Kamion> Failed to fetch file:/srv/cdimage.no-name-yet.com/ftp/dists/hoary/Release  Unable to find expected entry  restricted/debian-installer/binary-i386/Packages in Meta-index file (malformed Release file?)
<pitti> seb128: erm, that _is_ upstream, isn't it?
<Kamion> that looks pretty fatal
<pitti> seb128: after I restart dbus, I don't get the desktop/menu/mount applet magic any more
<seb128> pitti: yeah, but even upstream, pinging on IRC to get comment on bugzilla is useful :)
<pitti> seb128: killall nautilus g-v-d doesn't help
<pitti> seb128: it works again after logout/login
<pef> hello
<seb128> pitti: seems to be a gamin issue
<Kamion> elmo: I'd be happy with a workaround, but I have no idea what a workaround would look like
<pitti> seb128: okay, nice. it would be nice to eventually get all those crappy patches upstream, it's a mess
<seb128> pitti: this magic is gamin
<pitti> seb128: erm, gam_server listens to dbus???
<seb128> pitti: no, but menu changes, etc are file monitors
<seb128> I don't get which dbus impact on this
<pitti> seb128: so what do I have to kill to get it back? :-)
<seb128> pitti: try gam_server gnome-vfs-daemon nautilus? 
<pitti> already did that
<seb128> with gam_server?
<elmo> Kamion: s/you/mvo/? :P
<pitti> seb128: yes
<seb128> pitti: so no idea :(
<pef> how can I help to fix the packages marked as "new changes from Debian require merging" in bugzilla ?
<Kamion> elmo: I think it happens whenever you try to do "apt-get update" with restricted/debian-installer in sources.list, so pretty fundamental
<Kamion> pef: do you *really* want to? :-) It's very tedious work
<Kamion> pef: all the instructions are in the bug reports
<pef> Kamion: the patch applied without error
<Kamion> pef: often patches apply without errors but need further attention - but unless you can upload to main, there's not much more you can do at that point
<Kamion> pef: I suppose you could follow up to the bug saying so, but remember that much of that kind of work is already taken care of automatically for us
<koke> is there any way to get the source for a wiki page without being logged in??
<Kamion> koke: append /src to the URL, I think
<pef> Kamion: ok, thank you for the infos ;)
<elmo> kamion: how about I downgrade apt on little? :P
<koke> Kamion: great! thanks
<Kamion> pef: (the tool that generates those bugs tries its best to do the merge automatically; its results need to be reviewed for sanity)
<Kamion> elmo: fine with me for now, but I would like to revisit this later
<mvo> Kamion: what bit of apt need attention? (sorry, was away for lunch)
<elmo> Kamion: do you need python-apt?
<pef> Kamion: I will wait to have more experience
<Kamion> mvo: I think apt's being correct actually :-)
<elmo> being correct-for-the-sake-of-it's not helpful if it breaks with stable releases
<Kamion> elmo: I don't *think* so
<Kamion> (python-apt)
* JaneW 's Activity Report:  http://www.dilbert.com/comics/dilbert/archive/dilbert-20050424.html
<Kamion> mvo: the issue is that apt refuses to download the Packages file for the restricted/debian-installer component in hoary because it's not mentioned in dists/hoary/Release
<Kamion> mvo: is there any option I can pass to make it not care?
<elmo> Kamion: germinate?
<Kamion> bleh, of course, so it does
<mvo> Kamion: no, but we could make it part of --allow-unauthentticated
<Kamion> mvo: I think that would be good
<mvo> Kamion: what is the easiest way to reproduce the bug
<jordi> mvo: dude?
<jordi> mvo: what's with this synaptic-kde desktop file that appeared in Dbian?
<Kamion> mvo: echo 'deb http://archive.ubuntu.com/ubuntu hoary restricted/debian-installer' > /tmp/sources.list; apt-get -o Dir::Etc::SourceList=/tmp/sources.list update
<mvo> Kamion: thanks
<mvo> jordi: gnome 2.8 does not support "OnlyShowIn=KDE" :(
<elmo> Kamion: I've changed warty + hoary for now, but I'd like to revert it at some stage, assuming we can fix apt on little
<jordi> mvo: ugh. Maybe you can move away the file temporarily for Debian.
* ogra GRRRs at the mono packages ....
<Treenaks> ogra: you made them
* Lathiat comforts ogra
<ogra> why the hell do they have the manpages in 3 locations ?
<jordi> I wish we had backported that to 2.8
<ogra> Treenaks, i didnt
<ogra> Treenaks, i just fix them
<Treenaks> ogra: hm, ok
<jordi> mvo: is it ok that it doesn't call gksu anyway?
<ogra> Treenaks, its just a horrible mix of debhelper , cdbs and native installing by makefile for the manpages.... they are originally packaged by the debian mono team
<trulux> heya!
<trulux> hey ajmitch_ 
* jordi rofls at that dilbert url
<ajmitch_> hello trulux 
<pitti> Hi trulux 
<trulux> hey pitti 
<trulux> pitti: I'm ready to work on everything again, gonna get a new TFT this afternoon
<pitti> neat
<trulux> ajmitch_: what's up? ;)
<Treenaks> Seveas: make up your mind ;)
<ajmitch_> trulux: a little busy, and I'm off to bed now
<pitti> trulux: the kernel patch for /tmp races would be nice and should be easy; and maybe you can update the SELinux packages to breezy?
<trulux> pitti: going to fix somre symbol-related stuff for the Breezy kernel security framework
<trulux> pitti: sure, one thing:
<trulux> ajmitch_: OK, sleep well. if you have sometime later to send me the fixed pam packages, it would rock (well, you rocked the house already, just that we need to update the packages ;) )
<trulux> pitti: http://pearls.tuxedo-es.org/patches/security/kern-security-1.patch
<pitti> trulux: ROCK
<mvo> jordi: the kde-version of the desktop file does not use gksu but X-KDE-SubstituteUID
<Seveas> Treenaks, hm?
<trulux> pitti: I will fix some things on it and implement some randomization stuff
<pitti> trulux: please keep the patches apart
<pitti> trulux: is it possible to have one patch for your general framework, one for /tmp, one for randomization, etc?
<pitti> trulux: this way it is easier to manager and also it might be easier to include upstream
<trulux> pitti: right, split up is easy.
<trulux> pitti: I'll get over it
<pitti> trulux: did you talk with upstream about this "framework" approach?
<pitti> trulux: it makes much sense, but maybe upstream wants it a bit different
<pitti> trulux: would be nice to get this adopted 
<trulux> pitti: not really, they now on http://pearls.tuxedo-es.org/vsecurity/ which is a better candidate
<trulux> pitti: LSM-based, runtime configuration by sysfs (no more sysctl ****), etc
<Treenaks> Seveas: join/quit/join/quit
<trulux> pitti: I've been making it compliant to 2.6.11 and added quite a bit features to it, some are still not ready, but it works well
<pitti> trulux: btw, we are going with 2.6.12
<pitti> trulux: let's say on monday or tuesday we two could actually build an ubuntu kernel with these patches
<pitti> trulux: is that fine for you?
<trulux> pitti: sure
<trulux> pitti: the point on vsec is that we have no portability issues
<trulux> pitti: you may want to test it
<trulux> pitti: but we'll work out the generic sec. framework first
<pitti> trulux: vsec?
<trulux> pitti: http://pearls.tuxedo-es.org/vsecurity/
<pitti> ah, neat
<trulux> pitti: did you have a look at the spec. pdf?
<Nafallo> pitti: you want two diffs if the version haven't changed in warty?
<Nafallo> pitti: (UniverseSecurity) :-)
<pitti> hm?
<pitti> Nafallo: you mean Warty and Hoary have the same version?
<Nafallo> pitti: yepp.
<pitti> Nafallo: yeah, for now we dodged this by incrementing the hoary version by 0.1 (no other changes, just a new changelog entry)
<Nafallo> pitti: do we really need to? shouldn't we just target them at {warty,hoary}-security with the same version number?
<Nafallo> if the user dist-upgrade to hoary he will install the same package again otherwise.
<Nafallo> pitti: for some context; libcdaudio, CAN-2005-0706 :-)
<pitti> Nafallo: elmo doesn't want multi-release uploads
<Nafallo> pitti: oki, I'm sure he has some reasons. it just can't follow the logic with that :-).
* Nafallo goes to prepare the packages *
<zyga> hello everyone :)
<zyga> sunny day :)
<Nafallo> zyga: indeed :-)
<Kamion> elmo: thanks, and acknowledged
<Nafallo> Baby: hi there! :-)
<Baby> hi Nafallo :))
<Mitario> hi everyone
* Nafallo goes out with the rabbit, bbl
<Mithrandir> have fun
<bluefoxicy> So
<bluefoxicy> is this worth an Ubuntu Security Notice
* pitti urgently feels the need to finish for weekend :-)
<bluefoxicy> that Intel processors with HyperThreading are vulnerable to an information disclosure bug that would allow an attacker to ie steal an RSA key while the key plaintext was in memory during a decryption algorithm?
<bluefoxicy> in processor design, not in the design of the OS kernel.
<pitti> bluefoxicy: ah, that one. We know about it, update is in the works
<bluefoxicy> pitti:  :)
<pitti> bluefoxicy: kernel patch (which disables HT for now) is ready, some guys are testing it
<pitti> bluefoxicy: expect an USN at Tuesday
<whiprush> jdub: ok, if you're going to give people "a beer from the fridge" then we need a cool beer bottle.
<whiprush> with like, fridge written on it.
<bluefoxicy> pitti:  "USN #2-42:  Intel is filled with morons, buy AMD"  :)
<jdub> whiprush: dude, who wrote that?
<jdub> whiprush: it was not me :)
<pitti> seb128: any idea how a gnome package generally could produce a POT file?
<pitti> seb128: g-v-m doesn't do it, so while I'm at changing it...
<Lathiat> bluefoxicy: haha
<pitti> seb128: (a lot of other packages don't either)
<Lathiat> pitti: is that patch optional?
<pitti> Lathiat: HT off by default to be safe
<pitti> Lathiat: you can certainly enable it again using a kernel parameter
<seb128> pitti: "cd po; make update-po" ?
<Lathiat> but can you turn it on without compiling..
<Lathiat> oh right
<Lathiat> pitti: cool.
<seb128> pitti: or "cd po; make <translation-domaine>.po"
<bluefoxicy> Lathiat:  doesn't AMD have dual-cores AMD64 now?  :)  The statement was quite feasible
<pitti> seb128: ah, I'll try the second, the first one regenerates all po files, I don't want that
<seb128> pitti: ups, .pot I mean for the second
<Lathiat> bluefoxicy: yeh they wont be out till q4 tho
<Lathiat> i hear the xbox 360 has a tri-core 3.2GHz powerpc :\
<bluefoxicy> cool
<pitti> seb128: any idea how to teach that to cdbs gnome.mk in a generic way?
<Lathiat> 10 points to the first person to get macosx running on it
<bluefoxicy> Lathiat:  any socket 756 d/cs?
<pitti> seb128: otherwise we have to change a shitload of packages to generate pot files
<bluefoxicy> err, socket 754
<pitti> seb128: po/$ make <domain>.pot works, thanks
<Lathiat> bluefoxicy: its drop-in apparently
<bluefoxicy> Lathiat:  drop-in for an FX socket 939 or an athlon 64 socket 754 though
<seb128> pitti: probably grab GETTEXT_PACKAGE value from configure and do the make
<Lathiat> bluefoxicy: unsure
<Lathiat> probably 939
<pitti> seb128: yeah, that's the idea; maybe we can add it to gnome.mk
<pitti> seb128: I'll try that first
<seb128> pitti: implementing to cdbs should be easy, poke jbailey about it :)
<pitti> oh, right ... delegate :-)
<bluefoxicy> jailbait what
<seb128> I mean he knows how cdbs work, probably a 10min job for him
<seb128> not need to start reading the code :)
<pitti> seb128: actually, gnome.mk doesn't look very scary
<seb128> right too
<pitti> seb128: I try to do a patch for gnome.mk, then you can try it on your packages, if it works, we ask jbailey to integrate it
<seb128> rock
<pitti> seb128: cdbs has a weird build system, I tried to patch it once, but failed horribly
<seb128> yeah
<seb128> cdbs2 should be nicer :)
<pitti> seb128: how many of the gnome pkgs would we cover if we patched cdbs to do the POT stuff?
<pitti> (50%? 90%?)
<seb128> 90%
<pitti> cool, that helps a lot
<seb128> pitti: k. I'm away for ~1h, if you need something let me know, I'll catch up then
<pitti> seb128: I will be away in 70 minutes :-) so enjoy your weekend
<seb128> thanks, you too!
<^rob^> seb128: when you spec out the places integration, do you think you might mention picking up the appropriate right click entries so that users can right click to eject disks and the like?
<Lathiat> yeh thatd be nice, atm the easiest way to eject a cd is to use the diskmounter applet
<pitti> carlos: here?
<carlos> pitti, yes
<pitti> carlos: do you have a list of all source packages which don't have a pot file?
<carlos> nohar, I don't have that list
<carlos>  s/nohar/no/
<carlos> pitti, but I have the information
<carlos> it's a matter of parse the mail logs
<pitti> carlos: is it possible somehow to generate this automatically for every day?
<pitti> and publish it on some webpage
<pitti> carlos: I'd like to modify gnome.mk (cdbs), which should at least catch all gnome pacakges
<carlos> hmm
<pitti> carlos: but we need a way to keep track of which packages are still affected
<carlos> I could try to improve the output of the log so we can parse it from procmail...
<carlos> pitti, could you do the procmail part?
<pitti> carlos: I can help you with that, sure
<carlos> so I send you a copy of the mail
<carlos> with the tags you need there so you can ignore the other crap output
<pitti> carlos: where do these mails come from?
<carlos> pitti, from ubuntu's servers
<pitti> carlos: OTOH, I could probably be faster if I just look at the tarballs
<pitti> carlos: I already have a script which compiles a list of the recent tarballs and does stuff with them
<carlos> pitti, then it's the same
<pitti> carlos: should be easy to generate the list
<pitti> carlos: okay, thanks anyway
<carlos> pitti, np, ping me if you need help
<pitti> okay, I'll do
* pitti stares at gnome.mk
<Nafallo> Mithrandir: we had :-)
* Nafallo should have brought the camera...
<jordi> mvo: aha, that's cool
<pitti> bye everybody, have a nice weekend
<seb128> nice WE pitti
<seb128> ^rob^: there is a bug upstream about this
<seb128> jordi: what's cool?
<Kamion> elmo: reping, about the gtk2-engines-{crux,lighthouseblue} promotions - are those problematic?
<Kamion> $ telnet cdimage.ubuntu.com 80
<Kamion> Trying 82.211.81.176...
<Kamion> telnet: Unable to connect to remote host: Connection refused
<ogra> whoops
<Lathiat> omg someone broke teh intarweb
<Kamion> yes thank you
<luis_> I can't get to cdimage either, FWIW; I was actually just going to look and see if there are breezy liveCDs and ask if there is an ETA for those.
<Lathiat> starting early luis
<Lathiat> rather than a last minute rush :)
<Lathiat> luis_: i doubt it, theres still a few issues with the install cd too 
<luis_> Lathiat: indeed
<luis_> want to play with latest bits + sabayon
<Lathiat> cool
<luis_> which I'd assume installs on the older CD
<luis_> but I've been too lazy to try that yet ;)
<Kamion> luis_: there are no breezy live CDs yet, no; I've been concentrating on the install CD, and ubuntu-desktop isn't installable yet which makes producing live CDs a non-starter anyway
<Kamion> I suspect the first test release will be install-CD-only
<luis_> OK
<luis_> I'll just play with upgrading a hoary liveCD to get the test bits I need
<Kamion> that should mostly work, yeah
<jbailey> JaneW: There?
<tarvid> 6 desktop installs with general good results
<tarvid> i want to try a server next
<tarvid> any hints on where to start?
<Lathiat> type 'server' at the cd boot prompt
<^rob^>  /join #apache
<^rob^> doh!
<tarvid> any refs on where to go next?
<Lathiat> tarvid: just install like normal
<Lathiat> and you gate a barebones system basically
<tarvid> apache mysql php postfix freeradius ssh ftp courier is the usual stuff
<tarvid> ubuntuguide has a lot of specific advice on servers, looking for a general treatment
<Lathiat> ugh ubuntuguide
<tarvid> why ugh?
<Lathiat> it has a habbit of recommending bad things
<tarvid> ah!
<tarvid> is there a list of good things from a server perspective?
<Lathiat> generally people just need what they want
<dredg> that really depends on what you want your server to do
<Lathiat> i guess some 'better' recommended programs would be good
<Lathiat> i mean i use apache2 for web, proftpd for web (altho im looking at moving to vsftpd), postfix for mail, dovecot for pop3/imap
<Nafallo> vsftpd rock! :-)
* Nafallo only uses main on his server ;-)
<dredg> ftp should be done away with.
<Lathiat> yeh i hear good things about vsftpd
<Lathiat> so im going to look at it
<Lathiat> ive just used proftpd for a long time and it seems to work well
<tarvid> i host 150 web sites - telling people to use sftp is fine - forcing them is not
<Lathiat> yeh
<Lathiat> Nafallo: unfrotuantely php4-mysql is in universe
<tarvid> i am not sure how to choose between versions, currently mysql 4.0.x is working better for me than 4.1.x
<Nafallo> Lathiat: php4-pgsql isn't ;-)
<Kamion> often if there are two versions of something in the distribution it's because it's not clear which is better yet
<Lathiat> Nafallo: heh
<Kamion> the later one might be experimental, say
* Nafallo actually switched from mysql to postgresql because of that.
<Nafallo> postgresql rocks! :-)
<Lathiat> yeh that one doesnt work so well for customers either tho
<tarvid> exactly
<tarvid> also want to replace a nat box
<koke> is there any known issue with libpng in breezy??
<Lathiat> koke: someone mentioned something earlier
<Lathiat> no idea of its accuracy
<jbailey> koke: Have you looked in bugzilla? =)
<Lathiat> jbailey: have you fixed my headers bug? =)
<dilinger> jbailey: have you stared into the abyss that is cdbs2?
<jbailey> Lathiat: I haven't done the lkh upload yet.
<jbailey> dilinger: Is it an abyss now? =(
<koke> jbailey: I only see 9800
<Lathiat> jbailey: excuses!
<dilinger> jbailey: heh, i'm trying to keep it from becoming that..
<Lathiat> cdbs is the shit
<jbailey> dilinger: Oh good. =)
<jbailey> dilinger: I'll be back home next week.  Far easier to hack there.
* jbailey was looking fondly at 15" amd64 laptops again yesterday...  *sigh*
<Lathiat> heh
<dilinger> sounds like the sort of thing that would run very very hot
<luis_> jbailey: getting your tubes tied is more reliable and less likely to induce a hernia
<ogra> jbailey, dont do it now.... there is a mobile version of the amd64 underway...
<zyga> dilinger: not really
<ogra> dilinger, t does ;)
<luis_> jbailey: or did you actually want a laptop and not sterilization?
<ogra> at least mine here
<jbailey> dilinger: I have a p3 900 without frequency scaling, I can't see if being hotter than this...
<jbailey> luis_: *lol*
<Lathiat> i had a p3 266 up until 4 months ago
<ogra> jbailey, mine is constantly at 50 degree 
<Lathiat> it was hotter than my 2ghz pentium-m
<jbailey> luis_: Is sterilisation from laptops usually permanent?  I thought it was just like...
<dilinger> jbailey: yea, my celeron 600 used to burn my legs.  my 1.3ghz centrino's been really nice
<ogra> jbailey, if i compile something it raises to 70-80
<jbailey> wait a sec, this is starting to sound like #debian-devel, sorry. =)
<Lathiat> my cpu sits at ~50
<Lathiat> but its not that hot on your laptop unless your running at 2ghz and doing stuff 
<luis_> my fault :)
<tarvid> thanks for your help, i have a million more questions but i will go do a server install and come back
<dilinger> jbailey: i could post some SA links to make up for ari's lack of presence here, if you like ;)
<ogra> Lathiat, ~50 at 800Mhz
<Lathiat> well mines ~50 at 600mhz
<Lathiat> but itl stay around 50 at 2ghz if your not doing anything
<ogra> Lathiat, 70-80 @ > 800MHz
<jbailey> Where do you measure the temperature?
<Lathiat> ogra: mmm :\
<ogra> jbailey, /proc/acpi/thermal_zone/THRC/temperature
<jbailey> ah, internal temp, not surface temperature.  That's better. =)
<Lathiat> yeh my temps are internal
<Lathiat> my graphics card sits on 70
<Lathiat> 85 when doing 3d stuff
<ogra> jbailey, i wrote a little trayicon showing it constantly...
<Lathiat> (nvidia)
<KaiL> Lathiat: 6800?
<Lathiat> 5200
<ogra> at 90 nmy laptop shuts down.... if i compile big stuff i have a cooling hairdryer handy ;)
<KaiL> uh
<Lathiat> ogra: haha
<KaiL> how far does it go down in 2D?
<Lathiat> what temperature?
<ogra> Lathiat, seriously... :(
<KaiL> yes
<Lathiat> normal use it sits at 70
<Lathiat> 73 atm
<KaiL> that's a lot..
<Lathiat> it doesnt feel that hot underneath
<Lathiat> but i mean the fans only going at like 1000rpm
<Lathiat> its definatley *warm* underneath tho
<jbailey> It's something to think about when I'm looking at the laptop, though.  As long as it can keep itself cool, I rarely use it on my lap.
<KaiL> that should be above 30W then, wow!
<Lathiat> yeh my laptop is harldy ever on my lap
<jbailey> But it's nice to have a box that I can wander around with and work in the kitchen, or watch a movie from bed.
<Lathiat> but when it is, its not an issue
<Lathiat> bed is a slight issue
<Lathiat> cus the blanket cuddles it
<Lathiat> block fans, holds heat
<jbailey> But at UDU, I did wind up carrying it around on one arm.
<jbailey> Lathiat: Yeah, I did that once.  All bad. =)
<Lathiat> heh
<Lathiat> but my laptop has vents on top
<Lathiat> which is nice
<jbailey> Have an end table now.
<Lathiat> (as well as the bottom)
<Lathiat> so if its blocked
<Lathiat> its not cut off
<Lathiat> sucks if you block the back exit tho
<Lathiat> whats nice about my laptop
<Lathiat> is that i can control the fan speed
<Lathiat> off, low, high
<Lathiat> so even if it thinks its fin
<Lathiat> i can force it up high to keep it cooler
<mako> ion3 in hoary sucks quite a bit
<mako> i should fix this
<mako> in breezy
<ogra> mako, whats wrong with it ?
<mako> ogra: loads of bugs that have been fixed in upstream.. some rather important features just don't work
<ogra> oh
<mako> to move a window, you tag it
<mako> first, and then attach it
<mako> and you can't tag windows :)
<mako> rather a problem
<ogra> ouch
<mako> and the version in debian unstable FTBFS from breezy apparently
<mako> it's rather experimental so i'd been building my own packages since early on and hadn't noticed it was so dire
<ogra> mako, put them in universe ;)
<dilinger> mako: on the subway yesterday, i recalled your blog entry about your passport.  i completely forgot about that during the keysigning, and now i can't remember whether i actually looked at your passport or not :)
<mako> ogra: it's in universe.. 
<mako> ogra: oh, you mean mine.. 
<ogra> yeah !
<mako> ogra: well, i'd like to find out why the new versions FTBFS first
<mako> ogra: i'd prefer not to fork the debian package if possible.. so i don't have to keep maintaining this
<ogra> probably norbert built in a lsb_version check against ubuntu ;)
<mako> it's a xinerama/xorg issue
<ogra> mako, but beware of norbert if you touch his package ;)
<ogra> i already had the fun...
<mako> it'll hit debian eventually
<ogra> if xorg gets in, yes
<mako> ogra: it's not an if, it's a when
<ogra> heh, yep
<mako> ogra: debian is not going to use xfree forever
<ogra> hmm, not even with the new dpl ?
<mako> especially not with the new dpl
<mako> they may not use our packages
<mako> i'm sure fabbione can speak to wahtever the latest plans are
<Kamion> they are currently in the middle of auditing our packages and are likely to base stuff on them, AFAIK
<mako> Kamion: that's great new.. last i heard it was a little up in the air
<Kamion> well, this is just what I picked up from browsing debian-x
<Kamion> so it may be total rubbish, but it looked promising to me :)
<mako> so i got a new laptop
<mako> but it powers off by itself
<mako> apparently when the load is high
<mako> so i underclocked it
<Lathiat> ouch
<mako> now, BOTH of my computers are underclocked
<mako> unfortunately, i couldn't seem to find anything between 400mhz and max
<mako> :)
<Lathiat> :\
<Kamion> elmo: please sync autopartkit 1.08 from unstable; OK to overwrite Ubuntu changes
<ogra> mako, what kind of laptop ?
<mako> ogra: thinkpad x21
<mako> the acpi is completely borked too
<mako> if i boot with acpi on, the network card doesn't work
<ogra> mako, ah, ok, i thought some big amd64 thing
<mako> eben moglen gave it to me :)
<ogra> mako, there are special ibm acpi drivers...
<mako> i gave him a pile of ubuntu cds
<Kamion> mjg59: well, the CD installs fine. cdimage's web server seems to be dead, but try ftp://cdimage.ubuntu.com/cdimage/custom/20050513/
<mako> yeah, i know.. i played with a little bit unsuccessfully.. i've been trying to get consumed on this and then have to work all weekend :)
<Kamion> mjg59: it should also rsync very well against a hoary image, if you have one handy
<Kamion> (rsync://cdimage.ubuntu.com/cdimage/custom/20050513/)
<madduck> would german-speaking developers who read iX (p. 20 in 6/2005) care to take a look at http://madduck.net/~madduck/scratch/ix-debian-ubuntu.msg ?
<mako> madduck: what is ix?
<mako> ogra: ^^
<ogra> mako, reading already
<ogra> mako, heard of heise ( german news site)
<madduck> mako: germany's professional it magazine
<ogra> they are the publisher
<mako> ah, ok. cool
<madduck> ogra: patches appreciated. :)
<ogra> madduck, argh, you mentioned backports...
<madduck> ogra: not good? why not?
<ogra> because backports break your upgradeability.... dont have a QA review of several months and generally are evil...
<jcole> hi guys
<jcole> i've asked this before
<madduck> ogra: i have not had any problem, but i am not set on mentioning it, so if you think i should take it out...
<amu> madduck: backports arn't secu updated and activly maintained, except this nice text 
<ogra> madduck, and backports are in no way official (in fact we are not very happy about it)
<madduck> we == ubuntu?
<jcole> i'd like to know how to do an ubuntu net-install (like debian installer/fedora kickstart/suse yast/etc.)
<ogra> yep
<madduck> jcole: FAI
<ogra> jcole, kickstart is integrated in ubuntu
<madduck> jcole: there was a post on the fai users list about how to do it with hoary
<\sh> madduck: cool writing
<madduck> ogra: well, tough. :) i bet there are also some out there who are not too happy with ubuntu.
<madduck> <tongue in cheek>
<ogra> jcole, in the installer as well as the gui tool
<madduck> \sh: thanks.
<ogra> madduck, might be, but we dont go and break their systems ;)
<\sh> madduck: its one of the first professional opinion to this debian cs.
<\sh> vs. ubuntu crap
<madduck> \sh, ogra: tarzeau in #debian-devel said that I am not making enough of a difference between d and u users.
<\sh> hmm..what difference?
<madduck> \sh: http://debianbook.info -- if you want 605 pages of more non-polemic objective stuff. :)
<\sh> debian u smokes gras and ubuntu users dope?
<madduck> \sh: yeah, my point.
<\sh> madduck: well, i read ians article about it...
<madduck> let's share! you get some of my weed, i take some of your dope. :)
<madduck> ians article?
<\sh> ian murdock 
<madduck> about my book? or what?
<\sh> no
<\sh> w8
<madduck> (what a shame)
<madduck> :)
<madduck> he *did* get chapter 1's quote, that bastard.
<\sh> http://ianmurdock.com/archives/000244.html
<ogra> madduck, you should also mention that we only survive through the fact that debian developers merge our changes, so we dont have to maintain every small fix and that we bring a huge testing community to the debian world
<\sh> http://ianmurdock.com/archives/000258.html
<madduck> ogra: don't i say that? so versuchen wir stets, den Abstand zwischen den
<madduck> beiden Distribution klein zu halten, denn dann verringert sich der
<madduck> Wartungsaufwand auf beiden Seiten -- vor allem aber fr die Ubuntu
<madduck> Entwickler.
<madduck> (sorry)
<koke> jdub: my face is not showing at planet ubuntu, but it's in the heads/ dir
<ogra> madduck, right...
<ogra> madduck, but that doesnt show that both sides win here... 
<mxpxpod> is there a rescue mode in ubuntu?
<madduck> does debian win?
<madduck> ogra: (serious question)
<ogra> madduck, sure, they have a millon (or two, or ten) more testers for the software they offer... and probably the luck to get a fix from us if we touched the source
<ogra> so both sides win indeed
<\sh> madduck: no, when they go on with their arrogant mentality 
<\sh> (sometimes)
<madduck> \sh: "they" don't have a mentality.
<madduck> \sh: some have and they speak too loudly.
<madduck> i am all interested in making the best of debian+ubuntu
<\sh> madduck: but this is debian...a mass of silence and a couple of loudspeakers
<madduck> \sh: yeah, and a place where you aren't supposed to take anything for granted, nor react to everything, no matter how loud.
<ogra> madduck, additionally i just was told debian seriously thinks about ubuntus xorg packages, so this might be an obvious win if it gets reality
<madduck> ogra: yes. certainly.
<madduck> "Demnach arbeiten Ubuntu Entwickler aktiv an Debian mit"
<mako> 20:08 < madduck> i am all interested in making the best of debian+ubuntu
<mako> amen
<mako> :)
<\sh> madduck: 2001 I was at the cebit as personal for redhat...we had debian visitors they asked us if redhat wanted to use the debian installer
<ogra> madduck, that wouldnt convince ian ;)
<madduck> mako: couldn't we form a committee who's purpose is to ensure we all get along? like 5+5 people
<mako> madduck: we will.. but in a broader sense
<madduck> ogra: ian ios a thick head
<mako> will bring in other distros
<\sh> madduck: the chief of engineering at this time said "definitly not" and they started to moan and spitting out some "not understandable" words ;)
<mako> i've already written up the proposals.. should announce in a week or so
<ogra> madduck, sure... but still, he has a lot of fans
<mako> madduck: i'm happy to send you the stuff if you're interested
<madduck> oh man, why not just solve small problems first before trying to cure world hunger?
<madduck> mako: please do.
<mako> madduck: killer
<madduck> ogra: he is the reason we are speaking with each other right now. :)
<mako> madduck: you gonna be in hel?
<madduck> mako: sure thing.
<ogra> madduck, because afterwards you have more time for the small stuff ;) raises the quality ;)
<mxpxpod> is there a way to keep gdm from running when I boot into ubuntu?
<mako> madduck: cool.. should have a session there.. the organizers are really dragging their feed on this though
<madduck> mako: K.I.S.S.
<madduck> i think it's dumb to try to make this so official before producing any results.
<mxpxpod> I screwed up my xorg.conf and gdm freezes when it starts
<\sh> mako: u want to bring gentoo in?? beware of the "100 emails for us and we will give a mini-mac as a gift to u" links...pls ;)
<madduck> mako: for instance, doko and I are going to work on pkg-zope and I think we are going to set a good example of how to better work together.
<ogra> madduck, the text is fine ( i would have written it more radically, but its good)
<madduck> at least if it works out the way I have in mind. :)
<madduck> ogra: if you have concrete suggestions, I would be happy to consider them.
<mako> \sh: debian derivers
<\sh> ogra: radical is nothing for ix
<ogra> madduck, no, its ok like it is, i already made my statements :)
<madduck> \sh: if mako brings gentoo in, i am going to lynch him when we go transsiberia together. :)
<\sh> madduck: hahhahah
<ogra> \sh, in a radical way as i would talk to IT managers ;)
* \sh is checking his clothes 
<mako> i'm not going to try to solve the world's problems.. just the debian derivers :)
<\sh> ogra: hmmm....
<ogra> YAY
<mako> madduck: i think maybe we're talking about different sets of problems
<mako> madduck: you'll see
<madduck> mako: just try to solve ubuntu+debian for now. the other will (have to) follow.
<\sh> ogra: i've missed u the time when I p*ssed off chris van hoven ;)
<ogra> mono built on all arches :)
<mako> madduck: but i'd love criticism.. certainly it's little things that will make or break it
<madduck> mako: ok. looking forward.
<madduck> mako: well, my inbox is waiting in vain.
<ogra> \sh, pissing off is not good.... politics need stratgy ;)
<ogra> strategy even
<\sh> mako: so u talk at least also about progeny?
<mako> \sh: yes
<\sh> ogra: he wanted to tell me how i have to do my job...
<madduck> ogra: pissing all over the place is a strategy
<mvo> hey madduck, nice writing, I like it
<mako> madduck: i'm gonna send it unedited.. go nuts
<madduck> mako: weeeeeeeeeeeeeehaaaaaa
<madduck> mvo: thanks!
<madduck> mako: deadline?
<ogra> madduck, but i doubt you'll win by pissing ;)
<madduck> ogra: wanna find out?
<ogra> madduck, i already did... it cured me :)
* \sh nods
<madduck> you pissed all over the place to cure you?
<ogra> LOL
<jcole> has anyone here ever used FAI
<\sh> madduck: no the others were p*ssing all over the place.
<madduck> bukake party!
<\sh> madduck: at last right now 
<jcole> (per madduck recommendation)
<madduck> jcole: it rulez
<\sh> ok...lets have a look to the list
<\sh> ogra: in the end: peter has ubuntu on his laptop ;)
<\sh> ogra: so u left at least one good thing for him ;) 
<jcole> i'm getting an "yuck, FAI" response
<ogra> \sh, he had warty already, i gave it to him on my hiring interview ;)
<mako> madduck: no deadline
<mako> madduck: if you've got ideas, it would be cool to send them this weekend as i'll probably be hacking on this stuff then
<madduck> mako: ok.
<\sh> ogra: but he's not satisfied with gnome, i told him: sudo apt-get install kubuntu-desktop ;)
<madduck> will do.
<madduck> jcole: by whom?
<ogra> jcole, we look for testers for hsprangs packages to get them into universe fo the next release
<madduck> jcole: check out the wiki
<ogra> jcole, would you mind to use them and write a two line comment on the functionallity ?
<ogra> http://wiki.ubuntu.com/MOTUToReview
<jcole> some of the developers that deploy different linux distros to people here at my company... they have a web interface that creates a small iso (for debian/suse/redhat/fedora/vmware esx server(rh7.3)/etc.) that will net-install
<madduck> mako: s/deian/debian/ and more comments later
<madduck> jcole: fai has a learning curve and i bet they didn't make it up there.
<madduck> jcole: do you use cfengine?
<jcole> ogra: ya, i'm reading this right now, and it seems pretty advanced and flexible -  http://www.informatik.uni-koeln.de/fai/fai-guide.html/
<madduck> and/or do they know what cfengine is?
<madduck> jcole: and *simple*
<madduck> jcole: and it has a great mailing list
<madduck> and #fai
<ogra> jcole, i'm sure hsprang would be very happy to have finally a review
<madduck> hsprang?
<jcole> madduck: Henning Sprang
<madduck> you guys review each other?
<ogra> madduck, yep
<ogra> madduck, for universe
<madduck> so you review him and then send him out to space?
<madduck> :)
<madduck> i must go work now.
<ogra> madduck, yeah
<jcole> madduck: cfengine? i'll ask
<madduck> jcole: i bet they don't know it. :)
<\sh> cfengine?
<\sh> nice tool :)
<\sh> if u know what u do, u can break 500 servers in 1 second ;)
<mvo> madduck: to work? now? it friday evening, that's the time for leisure :)
<madduck> my gf gets here tomorrow. i have to make smart use of my time. :)
<mvo> madduck: good point :)
<wasabi_> mvo, I made a patch to update-manager that implements my idea.
<wasabi_> pgp keys and all.
<wasabi_> It's really sucky code, my first real python program. ;)
<wasabi_> But it works!
<Lathiat> go sucky code
<Lathiat> at least it'l be indented correctly
<wasabi_> haha
<Lathiat> ;)
<wasabi_> And when I say it works, i mean "in principal". There doesn't seem to be anyway to have a .desktop file pass a file name argument when using gksudo
<Lathiat> .. how so?
<Lathiat> ugh dselect got updated?
<Lathiat> that still exits?
<mvo> wasabi_: did you send it to me?
<mvo> wasabi_: I'm happy to look at it, thanks for your idea and the code :)
<blueyed> Which is the component where the gnome user manager is in (where you create/change user accounts)? It's buggy with amd64...
<ogra> blueyed, gnome-system-tools
<wasabi_> no, i didn't send it.
<wasabi_> Im gonna clean it up some tonight.
<wasabi_> Where is the svn/cvs repos at?
<wasabi_> so I can make a proper patch against head or whatever
* Lathiat braves an attempt to live without bluetooth and tomboy for a while
<ogra> Lathiat, till monday most of mono will be done... mono itself should be clean with the last upload
<Lathiat> still needs to go into main
<Lathiat> before we get dbus-cil love
<ogra> s/most of mono/most of the mono apps/
<Lathiat> (so im told)
<Lathiat> is anyone fixing bluez?
<Lathiat> if not i might take a look
<ogra> dbus-cil should be in the current new dbus...
<ogra> which is in main
<Lathiat> ogra: yeh but mono isnt
<ogra> yep, true
<Lathiat> and you cant build a source package in main
<Lathiat> and drop stuff in universe
<ogra> it will move next eek
<ogra> week
<Lathiat> (cus dbus-cil is now in the dbus source package rather than split)
<ogra> i know
<ogra> i think we move mono and gtk-sharp on monday and the rest of the apps during the week, as the dependencys come in
<Lathiat> Setting up dbus (0.33-0ubuntu1) ...
<Lathiat> Installing new version of config file /etc/init.d/dbus-1 ...
<Lathiat> Installing new version of config file /etc/dbus-1/session.conf ...
<Lathiat>  * Starting system message bus:                                          [ ok ] 
<Lathiat>  * Starting Hardware abstraction layer:
<Lathiat> /usr/sbin/hald: unrecognized option `--drop-privileges'
<Lathiat> hmmm
<mvo> wasabi_: update-manager is in gnome cvs
<ogra> yeah, the last hal didnt build
<KaiL> Lathiat: did you ever play manually in /etc/default/hal?
<blueyed> ogra: Thanks. I filed it (https://bugzilla.ubuntu.com/show_bug.cgi?id=10742). I think this is very bad.. the user in #ubuntu has probably to re-install.
<Lathiat> KaiL: nope, never
<KaiL> Lathiat: then we have a bug :(
<Lathiat> also i get a '/bin/sh: no: command not found' in the gnome-volume-manager errorlog after mounting a removable drive (and the drive is mounted but doesntshow up in places etc)
<Lathiat> is taht known?
<KaiL> coz in that file sits this "--drop-privileges"
<Lathiat> the automount stuff sems borked anyway
<Kamion> Lathiat: that's characteristic of a missing build-dependency, usually
<Lathiat> even when it mounts the usbdisk it thinks its a scsidisk and not a usbdisk like it used to anyway
<ogra> Lathiat, as i said, pittis latest package ftbfs
<Lathiat> ogra: oh right
<Lathiat> ogra: missed that
<Kamion> blueyed: the user should use the recovery boot option, with which they'll be able to reset their password by typing 'passwd <username>'
<ogra> blueyed, let him boot in recovery mode.... 
<blueyed> too late.. it got off.. :/
<blueyed> s/it/he/
<wasabi_> mvo, what would be the best way to raise this issue to the parties that matter? I see this as being a reasonable goal for breezy after people talk about it.
<Lathiat> s/talk/argue
<Kamion> Lathiat: dselect is still part of the dpkg source package; it was updated along with the rest of dpkg
<Lathiat> Kamion: ahh
<wasabi_> mvo, the apt security implications are probably not something I can handle.
<Lathiat> i think the last time i used dselect was installing potato
<Kamion> Keybuk wants to split it out of the source, I know; I occasionally volunteer to maintain it when he talks about that and I've had too much to drink
<ogra> Kamion, you want to keep it alive ?
<Kamion> ogra: yes; I use it almost every day.
<ogra> wow, you got masochistic tendencys ?
<ogra> didnt know that :)
<Lathiat> heh
<mvo> wasabi_: creating some text on the wiki (in the packagemanagement page)
<Kamion> I like my upgrades to work, so I use dselect. ;-)
<ogra> :)
* Lathiat uh
<ogra> mine work too... just with apt :)
<mvo> wasabi_: I think matt likes the idea too and we want to be able to install stuff over the web
<wasabi_> Trying to come up with a good GPG key acceptance dialog.
<zyga> wasabi_: BSOD, people are afraid of those
<wasabi_> ?
<zyga> wasabi_: at least they'll notice
<zyga> wasabi_: my mom is either 1) too afraid to click something she does not understand, 2) clicks something away when window shape is similar
<zyga> similar to something she recognizes
<wasabi_> Yeah. Well. Until somebody can come up with another paradigm, we're stuck with this.
<wasabi_> And I've been thinking hard and haven't figured it out.
<zyga> wasabi_: BSOD - blue screen of death ;-] 
<wasabi_> Any ideas?
<zyga> wasabi_: talking head, that would atract attention :-)
<\sh> does anybody worked with libglade recently?
<Lathiat> \sh: yeh whats up
<wasabi_> I realize this is almost exactly like MS's active X thing. =/
<wasabi_> I just can't come up with a more reasonable way to go about it.
<zyga> wasabi_: in some way - yes
<zyga> wasabi_: probably because there is none
<wasabi_> People want to be able to install software over the web... so they have to be able to.
<\sh> Lathiat: did u see any problems with current libglade gtk apps in breezy? 
<wasabi_> And some dialog has to ask if they're sure if they want to.
<wasabi_> And that's it.
<mvo> \sh: I work with libglade a lot
<zyga> wasabi_: people will install trash this way 
<wasabi_> I know. =(
<Lathiat> wasabi_: its really no different to downloading an installer
<zyga> wasabi_: people are not sure
<zyga> wasabi_: developers who can read the code are sure
<Lathiat> \sh: well alot of applications use it, and i havent seen anything break
<zyga> wasabi_: think middle ages, where only few people could read
<\sh> Lathiat: do me a favour, and try tagtool
<wasabi_> I'd bet we haven't hit the problem yet because malicious people don't target us, and we don't have a user base. =/
<wasabi_> And installing packages is hard.
<Lathiat> \sh: just install the package?
<\sh> Lathiat: in hoary it's ok...on breezy it broke
<\sh> Lathiat: 
<\sh> yeapp
<ogra> wasabi_, we dont have a userbase ?
<zyga> wasabi_: those who could not had no opinion of their own, no knowledge (generalizing here)
<wasabi_> ogra, that is targetting by ISV's, no.
<Lathiat> seems to have an issue finding the signal handler
<Lathiat> i.e. its using autoconnect
<Lathiat> that could possibly eb somethign to do with gcc4, or tagtool is just broken
<\sh> Lathiat: lemme look
<\sh> Lathiat: i think gcc4
<Lathiat> (cus it uses some of the glib module introspetion to do the autoconnect)
<zyga> wasabi_: when we have a userbase of 10% (apt-based systems in general) it will be too late to fix something security wise
<Lathiat> nfi how that works or how gcc4 woudl affect it
<\sh> jupp glade_xml_signal_autoconnect
<Lathiat> (i can tell from the errors tahts whats causing the issue0
<wasabi_> zyga, again, if you can offer a better solution. ;)
<wasabi_> I mean, I *CAN* offer a better solution... we just can't do it yet.
<wasabi_> Every package installed by this remote thing should run in a protected space, perhaps with SELinux.
<zyga> wasabi_: there is no protected space
<\sh> Lathiat: so i have to search for a workaround....:(
<wasabi_> my point exactly.
<zyga> wasabi_: you are fooling yourself in a way
<zyga> wasabi_: the protected space will *have* to be breached
<wasabi_> How so?
<zyga> wasabi_: unless the app is totally self contained
<wasabi_> Worked for Java. ;)
<zyga> wasabi_: and users will simply click 'yes I want to let this app access my files'
<Lathiat> \sh: fix glade :P
<zyga> wasabi_: didn't you see java crapware?
<zyga> wasabi_: just download and run will all priviledges (pretty images show how joe sixpack can do this)
<\sh> Lathiat: no ways ;) i hate gtk stuff ;)
<jbailey> wasabi_: Is this a proposal for a security manager implementation?
<wasabi_> No.
<\sh> Lathiat: but i'm the last who touched tagtool
<wasabi_> It's just a wandering conversation.
<Lathiat> well im going to bed, night all
<jbailey> Oh good.  SELinux for SecurityManager would be... interesting.
<wasabi_> Yeah.
<jbailey> Probably be a bitch to audit.
<wasabi_> Well, I've got a draft proposal for that idea someplace too. ;0
<wasabi_> Apple is actually doing it in OS X
<zyga> wasabi_: can't you write a java app that will remove all files in your home dir?
<zyga> wasabi_: you can!
<wasabi_> zyga, not if you don't give the user the ability to run it.
<Lathiat> sure but afaik with sun etc it isnt allowed to in a browser
<wasabi_> except in the sandbox.
<zyga> wasabi_: and when the java security stuff will ask you wether to allow this app to access the file system 
<zyga> wasabi_: you might click no
<wasabi_> zyga, only if signed by a trusted signature.
<Lathiat> however the current gcj firefox plugin does
<zyga> wasabi_: but will anyone else?
<wasabi_> Hey the idea isn't about to defeat every possible entry point.
<wasabi_> The idea is to make a user relatively sure he's safe by default when running remote software.
<MrKeuner> hi, did ubuntu quit maintaining bittorrent tracker service?
<zyga> wasabi_: trusted signature? 
<zyga> wasabi_: like signed activex? 
<wasabi_> zyga, code signing. The basis of the Java security manager.
<zyga> wasabi_: trusted = centralized trust?
<wasabi_> Depends what you mean by centralized.
<zyga> wasabi_: forget about centralized
<zyga> wasabi_: I just cannot understand how will this ever work
<wasabi_> centralized where anybody is free the be the center.
<zyga> wasabi_: let's say I have app XYZ and I want it to be trusted
<wasabi_> zyga, okay, lets take a simple scenario. A user wants to run... hmm. A little game he received from email.
<zyga> wasabi_: okay
<zyga> wasabi_: he has only a binary image
<zyga> wasabi_: now what?
<wasabi_> So he opens hte game from his email client. The email client launches the process, but before it launches it it takes to our security manager and applies a profile to the process.
<wasabi_> profile: "LaunchedFromEmail"
<wasabi_> Which says "can create 1 X window"
<herve> hi
<wasabi_> And "can open outbound connections > 1024"
<zyga> wasabi_: go on
<wasabi_> That sounds like a reasonable default "LaunchedFromEmail" profile.
<wasabi_> Obviously it needs tweaking.
<herve> seb128, did you try something on verbiste or can I try my hands on it?
<zyga> wasabi_: can access file system?
<wasabi_> no.
<wasabi_> Well, maybe /tmp/$pid
<zyga> wasabi_: bzzz bad game
<wasabi_> why?
<seb128> herve: I've assigned the bug to me for a reason, I've a patch on my disk
<zyga> wasabi_: scores? 
<wasabi_> zyga, it's an internet game
<wasabi_> scores are stored remotely.
<zyga> wasabi_: upgrades [levels/sounds]  from the web
<zyga> wasabi_: okay
<seb128> herve: I've already said that to a motu this week, don't remember who...
<herve> seb128, that's what I thouht :)-
<zyga> wasabi_: fair enough
<zyga> wasabi_: what if it's a panorama picture maker
<wasabi_> The program runs. If the program attempts to access something outside of the profile, the security manager raises a signal to dbus saying "profile 1234 attempted to access this protected resource".
<wasabi_> The security manager sleeps the program and waits for an answer.
<zyga> wasabi_: answer from whom?
<wasabi_> afk brb
<wasabi_> The dbus thing would probably notify some user process, which would display some sort of dialog
<wasabi_> "Program blah has attempted to do foo, this is not allowed."
<zyga> wasabi_: and ther you go
<wasabi_> The choice about weither to have a "allow" button is optional.
<zyga> wasabi_: THE USER IS NOT CAPABLE OF ANSWERING THAT QUESTION
<wasabi_> what question? :0
<zyga> wasabi_: sorry for caps but I really mean it
<wasabi_> I didn't put a question
<wasabi_> I said the program can't do it.
<wasabi_> All dependent on the launch profile.
<zyga> wasabi_: if you don't allow the user to permit things he will just dump the app
<wasabi_> For a program launched from email, i'd imagine you'd not want to allow that, in an office.
<wasabi_> Maybe on a home system you would.
<wasabi_> This needs to be configurable.
<herve> seb128, I would probably be the only one in #u-m caring about verbiste :-)
<herve> seb128, but I don't remember about the patch, sorry then
<wasabi_> zyga, depends.
<zyga> wasabi_: and the big-bad-company will find a way to make malware that will go around that security
<wasabi_> zyga, if the app is non malicious, then it was designed with this in mind.
<wasabi_> If the app is malicious, and the user dumps it, great. ;)
<zyga> wasabi_: okay - my example
<wasabi_> For my office network, I would not want anybody to launch anything from email.
<wasabi_> That's my choice as an admin.
<zyga> wasabi_: panorama picture maker
<zyga> wasabi_: my mom got this over the email
<zyga> wasabi_: she clicks but learns (by some dialog and apps talking behind the sceens) that the program needs to access her files
<zyga> wasabi_: should she be able to allow this or not?
<wasabi_> Sure. She should be able to allow it to access files in ~ that are not prefixed with .
<wasabi_> But not anything else.
<wasabi_> I'm talking very fine grained here. ;0
<zyga> wasabi_: this is already exploitable 
<zyga> wasabi_: first of all my mom will probably be confused (she has no idea about any . files)
<wasabi_> eh?
<wasabi_> You just assumed for some reason that you mom saw some message talking about . files.
<wasabi_> I'm not sure where you got that.
<zyga> wasabi_: and the app will be free to write 'sorry' to each and every writable file
<zyga> wasabi_: okay so mom could click a button 'allow limited access'
<wasabi_> Why did you assume that button is present?
<wasabi_> listen, I realize there are a billion ways around this.
<wasabi_> You don't have to convince me about that.
<zyga> wasabi_: good :-)
<wasabi_> I already admitted that up above.
<zyga> wasabi_: so what are we left with?
<wasabi_> The default cause that a user can run a non malicious program by default.
<wasabi_> But is still given the chance to preventa  malicious program.
<zyga> wasabi_: gigantic audit over anything? (system calls for example?)
<wasabi_> GIVEN THE CHANCE
<trulux> heya
<trulux> pitti not here :(
<trulux> I have good news for him :)
<trulux> tseng: ping
<wasabi_> This is a tool.
<trulux> tseng|work: ping
<wasabi_> It's not a prevent all exploit magic wand.
<wasabi_> On top of that, it'd be a REALLY GOOD tool for an office situation.
<wasabi_> It might be less good for a home user.
<zyga> wasabi_: it could stop one vector of attack (like email)
<zyga> wasabi_: for an office situtation? /home <- non executable, nothing gets installed
<wasabi_> In my office I'd want to let people run the obvious: things which didn't need to access their docs. Maybe things that could read only.
<wasabi_> And display 1 or 2 windows.
<wasabi_> You know, those flash.exe videos idiots send around.
<zyga> wasabi_: for home situtation... really no idea
<wasabi_> It is an idea.
<wasabi_> I am in a home istuation. Most of my friends are.
<zyga> wasabi_: (I'm still getting .ppt videos ... )
<wasabi_> And we are capable of using a tool like this to audit our programs.
<zyga> wasabi_: the home situation is most crucial
<wasabi_> Sure, we're not my mom.
<wasabi_> But we are a certain population.
<zyga> wasabi_: because that's how zombie nets and user attitude is generated
* mvo is away for bit
<wasabi_> What about YOU?
<wasabi_> Would you appreciate this tool?
<zyga> wasabi_: hard to say
<zyga> wasabi_: I am biased (spelling?)
<wasabi_> I'd set mine to prompt on everything and I wouldn't be afraid to run anything from the internet.
<wasabi_> That's a massive use right there, for me.
<zyga> wasabi_: if it's not open source and generaly recognized I'm wary
<wasabi_> Right now, I wouldn't ever run a program from the internet.
<wasabi_> Liket hose flash apps.
<zyga> wasabi_: I would - this kind of stuff is not perfect 
<zyga> wasabi_: unless it would really really audit everything down to system calls and memory overusage
<wasabi_> That's the goal.
<wasabi_> Basically what SELinux provides, no?
<zyga> wasabi_: but then it would be a monster to maintain and monster for performance IMHO
<wasabi_> Just with a dbus callout interface of some sort.
<zyga> wasabi_: maybe I'm out of the loop
<zyga> wasabi_: but I though selinux did a fair bit less than that
<wasabi_> zyga, I would not find it neccassary to use for software distributed by Ubuntu.
<zyga> wasabi_: I should update myself on that topic
<zyga> wasabi_: because we trust ubuntu
<wasabi_> Exactly.
<wasabi_> And I'm not too worried about performance issues on flash.exe
<wasabi_> So, it's not much of a concern.
<zyga> wasabi_: I would really hate the day when linux will have to run antivirus for daily stuff 
<wasabi_> Its a simple fact that we WILL.
<wasabi_> When we have a user base of sufficient size.
<wasabi_> There's nothing preventing it.
<zyga> wasabi_: then we'll say 'bah, no more' and start hacking gnu/hurd and Z windows 
<wasabi_> pssh.
<zyga> wasabi_: and banish those 'linuz' folks and their problems ;-)
<zyga> hehe
<zyga> wasabi_: virtual boxes, totally separated from the main system would convice mew
<zyga> wasabi_: maybe the next generation of CPUs that will get new instructions important for virtualizing stuff will help
<zyga> wasabi_: BTW, did you hear of libsandbox?
<wasabi_> virutal boxes are just a poor mans way of accomplishing it
<elmo> Kamion/seb128: done gtk2-blah, sorry for the delay
<seb128> thanks
<Kamion> elmo: np, thanks
<wasabi_> no
<zyga> wasabi_: google for 'DAG sandbox'
<zyga> wasabi_: it's a small library
<zyga> wasabi_: written by that guy to test .rpm installs
<zyga> wasabi_: basically it allows you to audit most file operations
<wasabi_> just a preload thing
<zyga> wasabi_: yes
<zyga> wasabi_: easy to go around of course
<wasabi_> if it was used widly for what we were talking about, people would just work around it
<zyga> wasabi_: but the idea is neat
<zyga> wasabi_: chroot for app X to run
<zyga> wasabi_: and system provided user interface and tools to transfer files from one zone to the other
<wasabi_> I can also see this sandbox thing being used in other creative ways too.
<zyga> wasabi_: same thing for networks and user displays and lots of other things
<wasabi_> Like, imagine if Evolution's mail display widget was in a seperate process.
<zyga> wasabi_: it was used to see wether PREFIX stuff worked
<wasabi_> and this process was locked down to do nothing except communicate with the host process and draw to a predefined X window
<zyga> whether [spelling] 
<wasabi_> might reduce the impact of a html rendering vuln of some sort
<wasabi_> same with a browser.
<zyga> wasabi_: hmm, how?
<zyga> wasabi_: the process can: break, hug resources, do nothing
<zyga> wasabi_: what can the same process do without that constraint?
<wasabi_> huh?
<zyga> wasabi_: what else?
<wasabi_> you just listed 3 very minor thing
<wasabi_> at least he process can't "open a smtp engine and serve spam"
<wasabi_> or "overwrite all my files"
<zyga> wasabi_: hmm?
<zyga> wasabi_: I thought you were talking about html display widget
<wasabi_> I am.
<zyga> wasabi_: I hope we never have to get them from the net from random corporations :>
<wasabi_> Think of all the complex logic involved in parsing HTML and CSS and MarkupOfTheDay.
<wasabi_> There are probavly buffer overflows in there waiting to happen.
<zyga> wasabi_: true
<zyga> wasabi_: hmm
<wasabi_> If all they could do was compromise a little window in a mail client, and nothing else.
<wasabi_> Well, that's a bonus.
<zyga> wasabi_: I'm not afraid of buffer overflows actually
<wasabi_> well, then consider javascript in a browser.
<zyga> wasabi_: with all the stuff going on recently It's become virtually impossible to hack stuff this way (or so I believe)
<zyga> correct me if I'm wrong please
<zyga> and besides: safe languages can provide stuff like this if you want to be totally sure
<wasabi_> that's great.
<zyga> wasabi_: like java for example
<wasabi_> you get everyone to rewrite all their apps in a safe language. ;)
<zyga> wasabi_: no, but critical systems could be reimplemented (just thinking)
<wasabi_> well what's critical?
<wasabi_> 5 years ago a browser wasn't critical.
<wasabi_> now it's hte most critical thing there is
<zyga> wasabi_: especially since parsing is already available in just about any language
<zyga> wasabi_: true
<zyga> wasabi_: browser is really critical nowdays
<trulux> hey tritium 
<tritium> hey trulux
<zyga> wasabi_: trully I don't think that java-browser will have wide user base ;-)
<wasabi_> it doesn't and never will
<zyga> wasabi_: loook it's started, I can almost see the window now
<wasabi_> exactly
<zyga> wasabi_: bah, back to the topic
<zyga> wasabi_: all those stack smashing and random offset loading anti bufer overflow things
<zyga> wasabi_: how exploitable is that ATM?
<wasabi_> no clue
<zyga> wasabi_: so no conclusion 
<tseng|work> pitti I built latest ethereal from breezy on hoary.. works nicely
<tseng|work> pitti: what is the right place to upload it for review?
<seb128> he's not here
<tseng|work> k.
<seb128> you probably should mail him
<seb128> not sure on how much he IRC during the WE
<tseng|work> yes
<MrKeuner> did ubuntu quit maintaining bittorrent tracker service? it is not working since yesterday
<elmo> the machine had some hardware problems - I've just re-enabled it, pls try again
<trulux> anyone here wants to review the UBuntu Hardened new spec. before I commit it to CVS and the like?
<MrKeuner> elmo thank you it is working now
<blueyed> elmo: I cannot find peers with a fresh bittorrent install. Azureus on another machine can find a few (through Scrape perhaps?). Can you please check the server(s) again?
<trulux> mako: ping
* lamont_r goes to fetch kids, back in an hour or so
<mako> trulux: yessir
<trulux> mako: I've got the spec. finished and some kernel sutff, just I'm unable to get logged into the OFTC machine to rsync and so on
<trulux> mako: do you want to look over it before I announce it?
<mako> trulux: better to have mdz and ajmitch_ look it over if they haven't yet
<mako> and what do you mean by announce it? call for comments?
<trulux> mako: yes, send note to mailing list
<blueyed> yeah.. bad..
<blueyed> ups.
<mako> trulux: if it needs to be looked at right now, i can't do it.. if you can wait a bit, i'll get time in a minute
<trulux> mako: sure
<trulux> mako: I'll wait
<tseng> trulux: ?
<trulux> tseng: the new spec...
<tseng> did you post it to the u-h mailing list?
<trulux> tseng: not yet, I'm asking for people who want to review it before I do that
<trulux> tseng: I thought you might be interested
<tseng> is it as long as the last writeup? i dont have alot of extra time
<trulux> tseng: just 8 pages but not long
<tseng> oh man
<trulux> tseng: it's a spec., it's the point where we decide over the project future, taking it as little wiki page is senseless if we want to achieve our goals
<trulux> btw, I've taken most of the things of the wiki page into the spec
* tseng nods
<trulux> at least those under my competency
<trulux> tseng: I hope you'll like it
<trulux> tseng: capable for DCC?
<tseng> sometimes
<trulux> tseng: let's check :)
<trulux> tseng: done!
<trulux> tseng: my crack of the day won't be available yet, andromeda (OFTC machine hosting pearls.tuxedo-es.org and the like) died today due to harddisk failure
<trulux> tseng: the box is at Germany, so, I suspect pappy- has something to say about it!!
* trulux grins
<tseng> uh
* tseng regexs out "*pappy-*
<trulux> tseng: hehe. he disappeared, no joke. just says hi from times to times but I doubt I feel OK seeing a hacker like pappy- falling down that hard way
<trulux> tseng: or he is working on a world domination project
<trulux> tseng: anyways, we (Hardened Debian/UH) work much better now without him, though he was a great fellow when we were working together on libssp and the other stuff
<diego> hi all. i'm interested in developing the Graphical Config Tools as listed on http://udu.wiki.ubuntu.com/GraphicalConfigTools?highlight=%28BreezyGoal%29 . i'm busy now but i can definitely get this done (with python+gtk+glade) sometime in the next few weeks. who should i talk to? the only thing i would need help with is just a security audit on the password change tool
<trulux> I still think on why he got mad, it was in just one week, all things messed up. that's not reliable even for me (if I'm the mostly a unstable kid) :)
<tseng> OT dude
<trulux> tseng: right, let's forget it
<trulux> tseng: bbl, dinner
<LinuxJones> can someone come to #ubuntu there is a spammer/racist idiot please :(
<Kamion> elmo: could you promote the various bits of ttf-indic-fonts? (sorry, I've no idea how anastacia output looks at the moment and whether direct requests for each thing are needed)
<diego> hm..should i have asked that in #ubuntu-love? didn't know it existed
<thom> LinuxJones: who?
<LinuxJones> thom, slak
<LinuxJones> thom, ty
<thom> np
<Kamion> seb128: in case you hadn't noticed, gnome-libs FTBFS on powerpc
* Kamion -> bed
<diego> will someone tell me what i need to do to get involved with this goal?
<seb128> not notice, I'll have a look tomorrow, thanks
<Kamion> diego: probably better to send mail to ubuntu-devel@lists.ubuntu.com
<Kamion> (than asking here)
<diego> Kamion: well the wiki has People, Contributers, and Interested listed...what do those mean?
<Kamion> diego: what they say; they were just put together from the names that came up at the breezy kickoff meeting
<Kamion> diego: don't worry about those for now
<Kamion> diego: however it looks like you should talk to ogra
<diego> ogra?
<tseng> not here
<Kamion> he's on IRC but I don't know if he's still around
<diego> ok...what does he do?
<elmo> Kamion: done
<Kamion> thanks
<Kamion> diego: he's listed as the person to contact about GraphicalConfigTools
<diego> Kamion: well ok :) thanks
#ubuntu-devel 2005-05-22
<seb128> elmo: libgnomecups sync please
<elmo> seb128: odne
<KaiL> elmo: amu told me to assign this to you: https://bugzilla.ubuntu.com/show_bug.cgi?id=10738 - he was only a bit late ;)
<seb128> elmo: thanks
<jcole> anyone here ever used acidrip in breezy?
<jcole> i think the ubuntu mplayer/mencoder is too old 
<jcole> i'll use the non-ubuntu...
<blahrus> jcole: installing now whats the issue?
<jcole> blahrus: i tried to rip a dvd with acidrip on ubuntu breezy
<jcole> blahrus: it doesn't work with ubuntu mplayer/mencoder so i installed the non-ubuntu one instead... works fine
* mvo goes to bed now
<ogra> diego, ?
<trulux> tseng: I've exhausted my IQ quota for today, but got the tmp races thing and others in the security framework I refer within the spec
<trulux> tseng: will upload when pearls.t-e.o comes again online
<trulux> tseng: I still think we may want to have a look at vSecurity
<tseng> ok..
<tseng> at the stuff prior to vsecurity
<trulux> tseng: it's much less intrusive and much more portable
<trulux> tseng: ok
<trulux> tseng: on vsec, I dunno why you don't like it
<trulux> anyways, see you tomorrow
<trulux> need some resting here
<trulux> too many time this week without sleeping
<trulux> too much
<trulux> argh
<trulux> IQ exhausted :)
<trulux> god night
<trulux> good night
<tsume> :) kde is broken
<tsume>  /var/cache/apt/archives/kdelibs-data_4%3a3.4.0-0ubuntu4_all.deb conflicts with knetworkconf :(
<KaiL> you use breezy, you are silly
<tsume> KaiL: yes, I use breezy :)
<ogra> heh
<ogra> use gnome the ext weeks then ;)
<ogra> next even
<tsume> gnome sucks at restriction policies
<KaiL> http://moba.linuxfaqs.de/kdelibs-debug2.sh << and there's the update-script
<KaiL> eh, fix-script
<ogra> you cant fix what is to come
<tsume> KaiL: hehe, you are prepared
<ogra> at least on tuesday KDE will brea heavily
<tsume> brea?
<ogra> break even
<KaiL> +k
<tsume> oh.. well damn
<tsume> I need my beautiful kde
<ogra> but we need g++4 ;)
<KaiL> ogra: why do you thing gnome will survice that? :)
<ogra> KaiL, gnome == C , KDE == C++
<tsume> oh, a question to everyone who has a digital camera. Is your camera good, and do you have example pictures
<KaiL> I guess, there will be enough C++ somewhere behind
<ogra> KaiL, not in gnome ;)
<tsume> ogra: I've used kde on freebsd going from g++295 to g++33, I know what happens :)
<KaiL> ogra: maybe X-Server?
<KaiL> or dbus?
<ogra> tsume, yep :) i survived the C++ transition in debian once ;)
<tsume> hehe
<tsume> ogra: its fun :)
<ogra> KaiL, dbus is already compiled with gcc4
<daniels> hold on
<ogra> daniels, not ?
<daniels> if dbus is already compiled with gcc4, then libdbus-qt-1-1 has already transitioned
<daniels> sweet
<ogra> oh, nope
<ogra> on tuesday then
<daniels> ahr
<ogra> we start on tuesday
<KaiL> btw. who has stolen libdbus-qt-1-1 from main, daniels? ;:)
<ogra> daniels, is dbus-sharp already enabled ? 
<KaiL> ..it's build-depend for kdebase...
<ajmitch_> looks like I'll have to sto pusing kde apps for awhile :)
<ogra> i'd like to pull mono t main on monday
<KaiL> who knows a non-kde mail app, which can use kmails mailfolders? :)
<ajmitch_> ogra: so any fixes we make to mono packages will be pushed through you (or someone else willing)?
<jdub> coming to you LIVE from the linux australia stand at the education expo!
<ogra> yeah
<ajmitch_> hey jdub 
<ogra> hey jdub 
<tseng> hi dubster
<ajmitch_> ogra: a good reason to get main upload rights then ;)
<ogra> ajmitch_, looks like
<KaiL> hi jdub then ;)
<tseng> jdub: did you catch my luis photo going around the net?
<jdub> the one with the spooky stare?
<tseng> yes
<ogra> hehe
<jdub> it was rad ;)
<tseng> the photoshop job is great
<jdub> so i was thining
<jdub> thinking
<ajmitch_> jdub: I'm sure the look was because of the other guy in the photo
<tseng> some guy made it a mug shot
<jdub> we should zombify him
<ogra> lol
<jdub> and put "BUUUUUUUUGS!" as the caption
* tsume should work on a kbeagle
<tsume> I mean.. pyBeagle
<ogra> py sounds good
<ajmitch_> I think there was a python port of lucene underway?
<tsume> its better than bloating up a computer just for one application
<daniels> ogra: nope, it's disabled while mono's still in universe
<daniels> ogra: as soon as it goes into main, I'll enable it
<ogra> daniels, as i said, its ready... monday should be the date..
<tsume> brb
<ogra> hmm, do i need a TB decision for that ? 
* ogra yays at tseng for a succsessfull gtk-sharp build
<tseng> yay!
<daniels> ogra: cool
<whiprush> evening gents.
<tseng> whiprush: welcome to mono night
<whiprush> excellent
<tseng> ogra: hm waiting for x86 :P
<tseng> ogra: im dying to do f-spot
<ogra> heh
<ogra> i'm dying to see it
<tseng> i wonder if it just lost the log
<ajmitch_> hey whiprush 
<ogra> i see all three here
<ajmitch_> tseng: what else is waiting that can be worked on?
<tseng> ajmitch_: i have it covered.. BenM built me a bunch of stuff from known-good svn that you wont have
<tseng> is there cxx stuff you could fix? :P
<ajmitch_> sure, I'll leave mono alone :P
<tseng> gr
<tseng> how is that crap getting in there
<tseng> ogra: hm no f-spot log from amd64, it says arch any
<tseng> ogra: it was trying to build at one point, maybe blacklisted
<jdub> this is GREAT
<jdub> everyone loves ubuntu
<jdub> :-)
<Predius> Hey, I'm in #ubuntu-love. =D
<zul> jdub: are you at a conference?
<daniels> zul: education expo
<zul> ah cool
<Burgundavia> jdub, what prompted that little statement?
<Predius> Who doesn't?
<jdub> zul: at an enducation expo
<jdub> zul: doing lots of ubuntu pimping :)
<Predius> Where is that?
<jdub> Predius: sydney, australia
<Predius> The Ubuntu convention was in Melbourne, right?
<daniels> nope, that was in Sydney too
<Predius> Ah.
<Predius> Nice.
<whiprush> this expo have a web page?
<whiprush> jdub: take pics!
<Lathiat> jdub: woo
<bod> is http://arch.ubuntu.com/apt@arch.ubuntu.com/ now the canonical tree for apt?
<bod> is cvs.d.o/deity kept in sync?  dead?
<mpt> hi ajmitch_
<ajmitch_> hi mpt 
<daniels> frig
<daniels> new l-k-h makes xorg ftbfs
<Lathiat> fixes my problems. :)
<aj> anyone know approximately how many MOTU people there are?
<tritium> aj, join us in #ubuntu-motu
<daniels> morning mdz
<Burgundavia> is 2 am here
<daniels> ahr
<torkel> a really early morning then :-)
<mvo> hey mdz!
<Burgundavia> lol
<ajmitch_> hi mdz, mvo, et al
<Burgundavia> mvo, you are going to hate me
<Burgundavia> mvo, check you inbox
<mvo> Burgundavia: oh, that was you? well ....
<Lathiat> what did you do Burgundavia :)
* mvo got ~15 new bugs today
<Burgundavia> filed about a dozen UI fix bus
<Burgundavia> bugs even
<mvo> Burgundavia: no, just the oposite, thanks for this :)
<Burgundavia> mpt did have a hand
<Burgundavia> mvo, there are bigger and deeper issues to be looked at, but mpt and I agreed that a bug report isn't the best place for it
<mpt> yeah, they can't really be split into bug-sized pieces
<mvo> mpt, Burgundavia: what would that issues be?
<mvo> (the deeper ones)
<Burgundavia> a general UI redesign, to more user-centric
<mpt> mvo: The overall navigation
<mvo> if it's not too much work for you I would be interessted in hearing about the ideas in some more detail. python-apt becomes more mature and it might be a good tool to play with new gui ideas
<mpt> excellent
<Burgundavia> cool
<mpt> I'll write up a spec for it
<ajmitch_> mvo: how's the python-apt work going?
<Burgundavia> mvo, are we talking dumping synaptic altogether?
<mvo> Burgundavia: it's a stable and mature tool, I don't think it needs to be dumped. but having a different branch writen in python as a testbed for ideas
<Burgundavia> ok, cool
<mpt> Synaptic 1.0, perhaps :-)
<|QuaD-_> is it ok to dist-upgrade breezy? it wants to remove a bunch of dbus and hal libraries, but upgrades others
<|QuaD-_> The following packages will be REMOVED:
<|QuaD-_>   dbus-1 dbus-1-dev dbus-glib-1 dbus-glib-1-dev libdbus-cil libhal-storage0
* mpt was going to say "Synaptic 2.0", then realized it wasn't at 1.0 yet
<|QuaD-_>   libhal0 libnautilus-burn0 python2.3-dbus tomboy
<Burgundavia> |QuaD-_, dbus is in major flux, and this is not the place for such discussion
<Burgundavia> mpt, I will kick around some ideas for the repos dialog, and post to -devel
<|QuaD-_> Burgundavia: ok
<mvo> mpt, Burgundavia : :) I'll have to leave for today now, but maybe we can talk about it another day?
<mpt> sure
<Burgundavia> mvo, np
<mvo> thanks
<daniels> |QuaD-_: don't worry about that
<daniels> |QuaD-_: libdbus-1-1, dbus, libdbus-1-dev, libdbus-glib-1-1, libdbus-glib-1-dev, libhal-storage1, libhal1, libnautilus-burn1, and python2.4-dbus all get installed
<daniels> the only breakage is libdbus-cil and tomboy, which will get fixed up later
<|QuaD-_> daniels: so if i don't care about tomboy or libdbus-cil i am safe?
<Kamion> d'oh, I just missed mvo
<Kamion> doko: you around? a query about isdnutils in ship
<doko> Kamion: yes
<Kamion> doko: so isdnutils is a metapackage that pulls in lots of stuff, including things like an answering machine server
<Kamion> doko: in my view not all of it is necessary for ship, and I'm trying to trim out unnecessary things to make stuff fit on powerpc
<daniels> |QuaD-_: correct
<doko> Kamion: yes, I tried to remove it, but ... 
<Kamion> doko: would just ipppd do the job, or should we have isdnlog and/or isdnutils-xtools too?
<doko> isdnutils-base should be kept, and ipppd, maybe isdnlog
<doko> yes, isdnutils-xtools would be nice too
<Kamion> isdnutils-base will be pulled in by the dependency from ipppd
<doko> fine
<Kamion> hm, isdnlog is half a meg
<doko> drop it
<Kamion> ok, I'll make it ipppd and isdnutils-xtools
<Kamion> since the latter's small and looks useful
<Kamion> but if I kill isdnvbox{client,server} then I can get tcl8.3 off the CD too :)
<Kamion> thanks
<doko> yes, sounds good
<Riddell> Kamion: none of the kubuntu torrents seem to be working
<Kamion> Riddell: are any of the Ubuntu ones working?
<Kamion> torrent.u.c was broken recently
<Riddell> Kamion: ubuntu doesn't seem to be working either
<Kamion> thom: can you help with checking out what's up with the torrents?
<thom> Kamion: i have to catch a train
<thom> bbl
<thom> Kamion: i'll look when i get home tonight
<Kamion> thanks
* Nafallo == the_geek
<doko> Kamion: any reason, why libgtkmm2.0-doc is in main?
<DanielN> hi
<DanielN> can someone tell me how to set up an repositorie on ubuntu?
<DanielN> or just how I build the Packages.gz ?
<Riddell> dpkg-scanpackages . /dev/null > Packages && gzip -f Packages
<DanielN> yes.. read that in a debian hwoto
<DanielN> but I can't find any package called dpkg-scanpackages
<Riddell> packages.ubuntu.com should turn it up
<Lathiat> its in the dpkg-dev package
<DanielN> ah thanks!
<Riddell> devscripts should bring it and lots of other useful things in
<DanielN> ok
<Kamion> doko: at one point, libgtkmm2.0-1c102 was probably in main, so we brought the doc package with it
<doko> but it didn't leave, so the source is still in main, but not the libs
<pitti> Hi
<Kamion> doko: I've removed it
<doko> hi pitti
<doko> Kamion: thanks. do you build a CD before Monday?
<Kamion> doko: I just built one, but powerpc is still oversized
<Kamion> by, like, 1 MB :P
* Kamion removes language-pack-pl and tries again
<Riddell> how can I make a dpatch?
<doko> Riddell: dpatch-edit-patch
<tseng> lamont: are gecko-sharp or f-spot affected by any kind of arch blacklist? dont appear to be building everywhere expected
<zyga> Kamion: why -pl ;-) ?
<Kamion> zyga: next on the list
<Kamion> they're roughly ordered by population I think
<zyga> Kamion: I see
<zyga> Kamion: BTW why is ppc iso so big?
<Kamion> zyga: more kernels
<Kamion> I've left language-pack-pl on i386 and amd64, and naturally it's first on the list to be added back if we have space
<zyga> Kamion: ah, lots of Gn cpus
<Kamion> zyga: erm, sort of
<Kamion> G3 and G4 can use the same kernel; G5 is incompatible
<Kamion> G5 and the IBM POWER4 chips can use the same kernel
<ogra> Kamion, whom do i ask for a seedchange for mono, its ready to go to main now (mono, gtk-sharp and gecko-sharp), would benice to have it in before the next dbus upload
<Kamion> IBM POWER3 needs a different kernel again, which used to be on the powerpc CDs, but I took that off
<Kamion> ogra: can you get pitti to have a look over it for security/supportability? (I'm sure he'll love me for this)
<Kamion> if it hasn't been looked over already
<ogra> hehe
<zyga> Kamion: interesting, are power3 chips common? how different are they to g3?
<ogra> Kamion, ok
<pitti> Kamion: gulp
<Kamion> zyga: not all that common any more, and totally different
<tseng> did we agree to gecko-sharp?
<pitti> Kamion: no, I didn't yet look at it, will do soon
<Kamion> zyga: do not make the mistake of confusing POWERn and Gn :-)
<ogra> tseng, does it build on all arches ?
<Kamion> the numbering schemes are unrelated
<tseng> not currently, see my ping to lamont a few lines up
<ogra> oh, ok, so not gecko-sharp yet
<tseng> right.
<Kamion> ogra: once it's ready, ask me
<Kamion> s/ready/been checked/
<ogra> Kamion, ok
<ajmitch_> it'll be good to see it in main
* zyga learns new things every day :)
<ogra> dbus will be happier
<Kamion> I'm away for most of today though, starting about now. *wave*
<ogra> ciao Kamion 
<ogra> enjoy
<ajmitch_> bye Kamion 
<Nafallo> Kamion: bye :-)
<daniels> Kamion: enjoy
<Nafallo> daniels: have you done anything to xine yet or is it working again for other reasons? :-)
<bluefoxicy> daniels:  When is ubuntu going to integrate LookingGlass :D
<bluefoxicy> tseng:  hey, did you get my e-mail?
<tseng> bluefoxicy: yes, im not sure what i was supposed to get out of it
<daniels> Nafallo: *cough*
<daniels> bluefoxicy: sometime around never
<Nafallo> daniels: and how shall I interpret that? ;-)
<daniels> Nafallo: look!  a diversion!
<bluefoxicy> tseng:  You said you might show up at baltolug a couple months ago but for various reasons nothing happened (I forgot my laptop one month, my presentation the next), wanted to know if you were still interested in coming
<tseng> bluefoxicy: i moved months ago
<tseng> so no.
<bluefoxicy> so that's a no
<bluefoxicy> ok
<Nafallo> daniels: hehe, oki :-).
<bluefoxicy> tseng:  plan B.  Teach me everything about SELinux in the next hour.
<bluefoxicy> :)
<bluefoxicy> daniels:  I was kidding, though lookingglass is neat
<daniels> all the technology is there
<daniels> just write a composite manager that intercepts events with xevie and translates them accordingly
<bluefoxicy> yeah
<bluefoxicy> daniels:  Or I could instead have something that zooms out and shows a bunch of small rectangular prisms from a top-down view, click one, it zooms in to show rows of rectangular prisms with windows displayed on them, you navigate with mouse gestures through and can get to any in about 5 seconds, click it, pick the facade (mouse gestures), and you got a desktop
<bluefoxicy> daniels:  a la Hackers  >:D  ("GIMME A SYSTEM'S VIEW!")
<daniels> ... which would be a composite manager that intercepts events with xevie and translates them accordingly
<bluefoxicy> yeah same thing
<bluefoxicy> just with a lot more eyes-boggling and a better chance of eventually pissing the user off
* Nafallo believe his touchpad have been cleaned by his girlfriend again.
<Nafallo> I can't bloody control the damn thing.
<bluefoxicy> Nafallo:  Fire your girlfriend and hire a new secretary who can follow instructions?
<Lathiat> my touchpad has started tapping too much :\
<Lathiat> i think im going to turn taps off
<bluefoxicy> ohwell I gotta get ready for class and work
<bluefoxicy> i'm out for the day
<Nafallo> bluefoxicy: well, the instructions ain't the problem. it's the lack of them.
<bluefoxicy> Nafallo:  I keep my equipment away from girls
<Nafallo> bluefoxicy: you don't have a geekgirl then ;-)
<bluefoxicy> Nafallo:  I have good physical security
<bluefoxicy> if any girls come near my room my four dogs will rape their ankles
<bluefoxicy> (damn chihuahuas)
<Nafallo> bluefoxicy: hmm, I can sence you don't have a girlfriend ;-)
<bluefoxicy> obviously not
<bluefoxicy> tee
<bluefoxicy> when I move out of my parents' house, I'm gonna put a sign on my bedroom door that says "no girls allowed"
<bluefoxicy> i'm also going to have like a million pillows, and build a fort out of them
<azeem> oops, and I thought I was in #debian-women for a second
<Lathiat> haha
<zyga> bluefoxicy: -devel you see, no pillows allowed
<azeem> damn IRC channels lying close to each other on tabs
<bluefoxicy> haha
<ajmitch_> hi azeem :)
<bluefoxicy> zyga:  yes, no pillows allowed; you guys aren't allowed to sleep, get back to work.
<azeem> hi Andrew
<ogra> hey azeem 
<zyga> bluefoxicy: sleep - yes, fortify - no
<azeem> ogra: hey
<zyga> bluefoxicy: join #freeciv-devel and propose new 'fortify with pillows' command for girl unit ;-)
<bluefoxicy> XD
<Nafallo> bluefoxicy: fortify is a -hardened thing ;-)
* Nafallo sings: I got the power!
<zyga> oh boy soon we'll need -devel-devel-devel to do real work ;] 
* Nafallo tries to go to -devel-devel :-=
<Nafallo> hmm, lonely :-P
<zyga> Nafallo: nah, -devel-devel was so non-bork-bork-borkesque
* mode/#ubuntu-devel [+o daniels]  by ChanServ
<elmo> [upload.ubuntu.com's going down for 10 mins or so] 
<pitti> Hi seb128 
<ajmitch_> hi pitti, seb128 
<seb128> hey pitti 
<seb128> morning everybody 
<pitti> "Morning" ??? -> ETIMEZONE :-)
<seb128> ah ah
<seb128> so, who is bugzilla master and could give me admin rights? elmo?
<ajmitch_> night all :)
<ska-fan> Can I update only certain packages from the development series?
<Treenaks> ska-fan: you don't want that
<Treenaks> ska-fan: why would you want that?
<ska-fan> Treenaks: I want the new evince
<Treenaks> ska-fan: just wait for breezy :)
<ska-fan> When breezy comes out I'm gonna be in Novosibirsk for a year
<ska-fan> I'm going in 3 months
<ska-fan> I'm probably not going to be able to download much data there
<seb128> grab it from Debian
<seb128> new breezy one will require the new libc
<seb128> the unstable one should work
<ska-fan> THe good thing is that when I return I can go to straight to breezy+1 
<ska-fan> GNOME 2.16
<Treenaks> not Gnome 3? :)
<ska-fan> That would be even cooler, but I doubt that.
<mjg59> Kamion: Thanks, that CD image looks good
<mjg59> Just need to check the modem, and I'll be good to go
<seb128> elmo: around?
<elmo> seb128: kind of
<seb128> du you know who I should ask to get bugzilla admin rights?
<seb128> I would like to fix all the gnome stuff where the bugs go to debzilla by default
<seb128> better to do that myself than bothering somebody
<mjg59> Kamion: Ok, looks good
<DanielN> Are there any possibilities to set up an apt repository without root access? (only webspace)
<Lathiat> yes...
<elmo> seb128: thom definitely has admin rights, AFAIK.  mdz might also.  I'm afraid I don't, I only have root and mysql root and I don't know bugzilla well, so unless it's urgent, I'd prefer if you ask thom
<seb128> elmo: not urgent at all, I'll ask thom, thanks
<DanielN> and which Lathiat ?
<Lathiat> DanielN: eh?
<Lathiat> DanielN: oh how?
<Lathiat> i dunno theres various tool sfor setting up repositories
<Lathiat> none of them need root
<Lathiat> (what you want to use depends on what your doing, setting up a mirror, an archive fo your custom packages, etc)
<DanielN> We are setting up a Backport server
<Lathiat> for your personal use?
<DanielN> no for www.ubuntuusers.de
<Lathiat> backports of what?
<ogra> gah
<DanielN> we'll see that ;)
<Lathiat> (im just trying to ascertain fi your mirroring backports.ubuntuforums.org, because they are evil)
<DanielN> err, no. we won't mirroring them :)
<ogra> what do you want to backport? and _why_ do you want to backport
<ogra> ?
<DanielN> we simply made packages
<DanielN> or will make some ;)
<ogra> will you offer regulary security updates ? will you care for the QA of the packages and do some monts of testing before you offer them ?
<DanielN> err
<ogra> will you be able not to break all users upgradeability like the other backports do with insane versioning ?
<ogra> sorry, but i'm really not a friend of backports (like nobody here)
<DanielN> I don't wan't to discuss about such things, cause I can't say much about this thing yet.. My question was just if it's possible to set up an apt repository without any shell access
<ogra> nope, not without shell access
<ogra> (you asked about root access)
<DanielN> sorry ;)
<DanielN> so no way to put an archive on regular webspace?
<ogra> you'll need at least user shell access, but that should work fine
<DanielN> ok thanks
<DanielN> that helps
<ska-fan> Lathiat: why are they evil?
<Lathiat> ska-fan: They break upgradability and are done by untrusted people among other things
<ogra> ska-fan, read my list above.... that are only some of the problems...
<_d4vid> play Akon - Lonely.mp3
<ogra> ska-fan, they dont get proper QA testing etc...
<Lathiat> and their target audience is new people
<Lathiat> who'll get scared off my broken things
<ogra> lots of the packages are packaged very broken ad break other things, overwrite files from other packages etc
<ska-fan> That certainly scares off
<DanielN> ..
<ogra> just building a checkinstall or alien package simply isnt enough...
<azeem> synaptic_0.56+revertedto+officialhoary+0.55+cvs20050406-1~5.04ubp1_i386.deb
<azeem> wow
<ogra> AAAAAARGH
<ogra> wat the hell makes them backport such a essential package, these guys are more crazy then i thought
<Lathiat> jeebus
<Lathiat> someone shoot them
<Lathiat> ubuntuforums.org is hosted by !canonical right?
<ogra> yep
<Lathiat> sigh
<Lathiat> ubuntuforums is akin to #ubuntu
<Lathiat> except i spend time in #Ubuntu i dont bother with the forums
<azeem> is their devel forum still being gated to ubuntu-devel?
<ogra> yep
<Lathiat> thats evil
<ogra> and there is a part that is linked to ubuntu-users as well
<Lathiat> twisted
<Lathiat> can we shoot them?
<Lathiat> oblitrate them from the gene pool?
<ogra> not with the CoC ...
<ogra> we're not allowed :)
<Lathiat> i havent signed it yet, i could do it as an outsider
<Lathiat> some kinda conspiracy
<ogra> heh
<Unfrgiven> seb128: ping?
<seb128> ?
<seb128> why people never say what they want
<Unfrgiven> seb128: hi. you reviewed my fast-user-switch-applet and i had some questions regarding your comments
<seb128> hey
<seb128> sure
<seb128> thanks for packaging it :)
<Unfrgiven> what does this mean? "control.ac specify a requirement on gtk 2.6, the Build-Depends should reflect that"
<Unfrgiven> seb128: np :) im just trying to fix it up so that it will satisfy your review :)
<Lathiat> at a guess that means it depends on gtk2.6 but the build-dep doesnt depend on gtk2.6
<ogra> Unfrgiven, you should add a build dependency on the devel libs of gtk 2.6
<Unfrgiven> Lathiat: oh....
<seb128> grep GTK fast-user-switch-applet-0.2.2/configure.ac 
<seb128> GTK_REQUIRED_VERSION=2.6.0
<seb128> 
<seb128> require gtk 2.6
<seb128> so update the build-deps according to that
<seb128> neither panel 2.0 or glade2 2.0 will force gtk2.6
<Unfrgiven> ah right. oh i'll add a build-depends on on libgtk2.0-dev
<Unfrgiven> seb128: and also according to your comments, it says that having gnome.mk in a cdbs rules, means that you don't need to include autotools.mk? is this correct?
<seb128> Unfrgiven: pick one, I don't get why you use autotools.mk
<Unfrgiven> well the cdbs documentation said that you need autotools and debhelper by default... and to add gnome.mk if its a gnome package... so i followed that
<seb128> what documentation?
<seb128> anyway you don't need to autotools.mk line
<Unfrgiven> the documentation used to be here https://wiki.duckcorp.org/DebianPackagingTutorial_2fCDBS
<Unfrgiven> the site seems down at the moment
<Sturmkind> hello again
<Unfrgiven> seb128: but ok, ill drop the autotools :)
<seb128> Unfrgiven: the website works from here
<seb128> oh, the wikipage is not here, k
<seb128> https://wiki.duckcorp.org/DebianPackagingTutorial/CDBS
<Unfrgiven> yep thats the one
<seb128> look the first example
<seb128> # Note that this class inherits from autotools.mk and docbookxml.mk,
<seb128> # so you don't need to include those too.
<seb128> include /usr/share/cdbs/1/class/gnome.mk
<seb128> 
<seb128> anyway that's just a detail, doesn't matter too much :)
<Unfrgiven> seb128: yeah i guess im just going blind :)
<seb128> bah, no, that's just a little detail point, don't worry ;)
<Unfrgiven> seb128: i've updated the package as per your review... i also added a depend on gksu as per dholbach's suggestion.
<Unfrgiven> seb128: could you re-review it?
<Lathiat> shouldnt you be using gksudo rather than gksu
<seb128> Lathiat: gksu: /usr/bin/gksudo
<Unfrgiven> seb128: i'm not able to access the wiki right not to update the MOTUNewPacakges page... you can get the package from http://ankur.ath.cx/ubuntu
<Lathiat> seb128: oh
<seb128> Lathiat: that's gksu
<Lathiat> seb128: my bad
<Lathiat> yeh si the wiki dead?
<seb128> Unfrgiven: sure
<Lathiat> are they doing the migration or something?
<Unfrgiven> seb128: so gksu is right?
<seb128> yep
<Lathiat> Unfrgiven: yes, dont pay attention to me im an idiot. :)
<Unfrgiven> Lathiat: I'm sure you arent that bad :)
<Lathiat> i'm not ;)
<Unfrgiven> is there a good gnome based util to compare two directories?
<Lathiat> Unfrgiven: for comparing what exactly?
<Lathiat> theres 'meld'
<pitti> gnome-terminal diff -Nur :-)
<Lathiat> which is like a tool for merging source code differences
<Lathiat> and shows file differences etc
<Lathiat> pitti: :)
<pitti> (sorry, SCNR)
<zyga> Lathiat: frankly... piti is right
<zyga> Lathiat: what more do you need?
<Lathiat> zyga: it depends what your doing...
<Lathiat> zyga: have you ever used meld?
<zyga> Lathiat: no
<Unfrgiven> well in this particular case, im trying to see the differences between two versions of ndiswrapper.... 
<Unfrgiven> the new version is broken for me :(
<seb128> Unfrgiven: no need to Depends on gksu, g-s-t already does that
<Lathiat> meld is ncie because it shows directory structure difference and then can open up files and look at their differences with side by side source and things spitting out showing what was added, removed, etc
<Lathiat> and then lets you push changes back and forward
<Lathiat> it also has an svn view
<Lathiat> makes merging changes itno trees fast
<zyga> Lathiat: like vimdiff but for whole trees
<Lathiat> im sure you can do it with emacs or something to
<Lathiat> zyga: and that
<seb128> Unfrgiven: and why do you have a fast-user-switch-applet-0.2.2.tar.gz.cdbs-config_list ?
<Lathiat> the most usefull feature is that you can see the whole tree layout
<zyga> Lathiat: something like mc's virtual filesystem for .patch
<Lathiat> and the files that differ
<Lathiat> zyga: well it doesnst do patches
<Lathiat> i dont think
<Unfrgiven> seb128: oh... ok i'll fix that. how can i see these sorts of dependency trees? is there a nice tool to dump it for me?
<Unfrgiven> seb128: where do i have that file?
<seb128> ls fast-user-switch-applet-0.2.2/
<seb128> debian  fast-user-switch-applet-0.2.2.tar.gz  fast-user-switch-applet-0.2.2.tar.gz.cdbs-config_lis
<Unfrgiven> seb128: found it... its an error
<seb128> k
<seb128> out of this the package seems to be ok
<Unfrgiven> seb128: how does one determine redundant dependencies?
<Unfrgiven> seb128: e.g. the gksu from g-s-t
<Lathiat> i hate speedstep
<Lathiat> powernowd hasno dont scale option
<Lathiat> and when i kill it, sometimes speedstep decides just to drop down to 600 anyway and get stuck on it
<seb128> Unfrgiven: knowing of the packages
<Unfrgiven> seb128: ah so that comes with experience :)
<seb128> Unfrgiven: the Depends is not really wrong ... but what uses gksu? Does f-u-s-a uses gksudo?
<Unfrgiven> seb128: i didnt think so but dholbach said it would be a good idea
<Unfrgiven> Lathiat: couldn't us change its min and max limits to suit?
<Lathiat> it doesnt have limits :)
<Unfrgiven> Lathiat: s/us/you/
<ogra> Lathiat, sure
<Lathiat> not last check
<Lathiat> maybe it does
<Lathiat> oh, so it does
<Lathiat> it still gets stuck when powernowd is running anyway
<Unfrgiven> :)
<ogra> Lathiat, in /etc/init.d/powernowd
<Lathiat> i think the speedstep driver is buggy
<ogra> Lathiat, look for OPTIONS=
<seb128> Unfrgiven: gksudo is for the applet or for user-admin?
<Unfrgiven> which driver are you using?
<Lathiat> centrino
<ogra> man powernowd shows you the possible options
<Lathiat> yeh just looked
<Lathiat> i forgot about those
<CarlK> anyone here care that http://www.ubuntulinux.org is not responding? 
<Lathiat> still means i have to change it when i actually go on battery
<Lathiat> it should have an option to not scale on AC, i started to hack it in once
<Unfrgiven> seb128: user-admin?
<seb128> Unfrgiven: what uses "gksudo"? why do you depends on it? for a reason.. no ?
<Unfrgiven> seb128: to be honest i see no reason to require it. dholbach said that it would be a good idea.
<seb128> k
<seb128> you have an option to configure the users
<seb128> that's why you Depends on g-s-t
<seb128> and that's this option which uses gksudo I think
<Unfrgiven> seb128: ah i see. gotcha.
<seb128> so this tools is user-admin
<Unfrgiven> seb128: but since g-s-t depends on gksu, i shouldn't need it in the depends anyways
<seb128> which use gksudo
<seb128> right
<seb128> my point is than the part using gksudo has to Depends on it
<seb128> and that's not f-u-s-a
<Unfrgiven> seb128: yep understood
<seb128> hum
<seb128> I've just looked on the package
<seb128> debian/rules:DEB_CONFIGURE_EXTRA_FLAGS := --with-gdm-config="/etc/gdm/gdm.conf" --with-gdm-setup="gksudo gdmsetup" --with-users-admin="gksudo users-admin"
<seb128> keep it this way so ;)
<Unfrgiven> seb128: yep :)
<seb128> package is good imho
<Unfrgiven> seb128: anyways i've updated the package again and its up for review
<seb128> let's wait for daniel and upload it
<Unfrgiven> seb128: yep cool. thanks for your help
<seb128> Unfrgiven: np
<Unfrgiven> Lathiat: meld looks quite good!
<Lathiat> i like it
<Unfrgiven> anyways, im going to head off to bed 
<Unfrgiven> gnite all
<lamont> tseng: %f-spot: i386 powerpc s390
<ogra> lamont, s390 ???
<lamont> gecko-sharp isn't blocked
<lamont> ogra: yeah
<ogra> heh
<ogra> lamont, hmm, the source package says arch: any
<lamont> yeah, well, PaS says otherwise. :-)
<lamont> PaS wins. :-)
<ogra> where does it get this info ? anywhere from the source package ?
<lamont> no.
* lamont goes to find a URL for th efile
* ogra has f-spot running on amd64 since this morning .... even if its still unstable, its already working
<lamont> http://cvs.debian.org/srcdep/Packages-arch-specific?cvsroot=dak
<ogra> hmm, thats simply wrong... and i doubt there is any mono for s390 yet
<ogra> s/mono/working mono/
<opi> hi guys
<zyga> opi: hey
<opi> zyga: are you aware of a command that would query package list with a respository?
<opi> zyga: something like --get-selected but with main/ universe
<zyga> opi: hmm, not really, what are you trying to do?
<opi> zyga: helpful script :P
<zyga> opi: like installing stuff that less legal than main and universe?
<opi> zyga: no, testing what's in universe
<zyga> opi: ah
<zyga> opi: I cannot help you on this, sorry
<opi> OK
<opi> I'm looking around ;-)
<GheRivero> res
* zyga is using meld and is pretty amazed
<Lathiat> zyga: :)
<Lathiat> the svn view is particularly usefull
<zyga> Lathiat: I never used svn
<Lathiat> ah ok
<zyga> Lathiat: I'm moving from cvs to arch
<Lathiat> yeh i use baz
<zyga> arch is pretty amazing too
<Lathiat> its nice
<zyga> tla?
<Lathiat> nah, baz is much nicer
<zyga> ah
<zyga> should I learn baz instead of tla?
<Lathiat> imho
<zyga> (this suxx, 3 revolutions on one day?)
<Lathiat> haha
<zyga> are they compatible?
<Lathiat> yeh
<tsume> theres a bug in nautilus :(
<Lathiat> altho if you want a baz arhive to be totally compatible with tla i think you hae to pass --tla to make-archive
<Lathiat> but you can read and work with tla archives fine
<zyga> great
<Lathiat> and with --tla they can read baz archives too
<Lathiat> the commands to baz are a little more sane
<Lathiat> and they implemented url support to most stuff
<zyga> so I can finish moving my current archives to tla and then start reading about baz
<Lathiat> among other things
<Lathiat> seems to be nice
<Lathiat> jamesh posted a comparison between cvs, svn and baz recently
<Lathiat> might be worth a read
<Nafallo> hi all!
<Lathiat> (comparison of commands and how to acheive atasks with each)
<zyga> Currently I'm dumping my cvs logs and such 
<Lathiat> not like a comparison of the systems as such
<zyga> because these logs in particular are of little value
<zyga> Lathiat: cvs and svn don't meet the distributed requirement
<Lathiat> zyga: right, but if you know cvs, reading his examples may help you grasp the basic concepts if you havent already
<Lathiat> and perhaps shwo you how its different from tla if ouve got that sorted
<zyga> Lathiat: I more less already know/undestand tla
<zyga> Lathiat: didn't dig into hairy features too much but the most critical and fundamental stuff is there
<Lathiat> http://www.advogato.org/person/jamesh/diary.html?start=196 if your interesting
<zyga> checking
<Lathiat> http://www.advogato.org/person/jamesh/diary.html?start=197 <- some more info on distributed dvelopment
<zyga> more reading, thanks :)
<zyga> meld is awsome in it's visual side
<zyga> I can easily see what's changed with little effort
<Lathiat> bah i got up to do something and now the latest enterprise episode is done so i want to watch that and will keep me up for another 45 minutes and its 1:30am. :)
<zyga> and ... what is best, resolve conflicts 
<zyga> Lathiat: hehe
<zyga> Lathiat: I'm still pulling mine 
<zyga> horrible crawl
<zyga> btfnet got killed
<tsume> gah!
<tsume> the idiots
<Lathiat> yeh
<Lathiat> i sourced it somewhere else
<Lathiat> its so stupid i cant watch thsi on tv here for at least 1-2 years so like
<Lathiat> its their fault im "pirating" the tv show
<Lathiat> i understand movies, i dont download movies
<zyga> I dont really feel like a pirate
<Nafallo> it's not killed yet is it?
<zyga> *AA crap is getting terible recently
<Lathiat> haggai: as in btefnet or enterprise?
<Lathiat> this is the last episode of enterprise im about to watch
<Lathiat> sadly
<zyga> Lathiat: both are gone now
<Lathiat> zyga: indeed
<Lathiat> btefnet will apparently come back
<Nafallo> the IRC-channel says it's just idling til they have a grip on the situation?
<Lathiat> it seems like the person who owned the domain and ran the website did a runner
<Lathiat> you'll note btefnet.com is now asking for donations
<Lathiat> but if you read the irc channel topic, is says its not them, please do not donate
<zyga> hmm
<zyga> seems like the domain is gone from dsn now
* Nafallo is glad he has other sites ;-)
<zyga> darn I need farster torrent
<zyga> I feel like modem days are back
<Lathiat> zyga: for 21 or 22
<zyga> Lathiat: both
<zyga> Lathiat: I hot 29% of 22 going at 1.2KB/s
<zyga> got even
<Lathiat> woo
<zyga> usually my gf pull stuff from IRC ;-)
* zyga goes back to melding code :>
* Nafallo goes to make some food
<Nafallo> Baby: :-)
<DanielN> Does someone know if the Apache Software License is GPL compatible ?
<Baby> hi Nafallo :))
<zyga> DanielN: hmm, was not that something that caused problems for perl or python some time ago?
<DanielN> don't know
<zyga> DanielN: AFAIR there were some license issues but I'm not really sure
<zyga> DanielN: there is a site that explains each license in details
<DanielN> I know.. at gnu.org I think
<zyga> DanielN: something like that
<DanielN> but I think it must be compatible since apache is in main section
<zyga> DanielN: I'd check if I were you
<DanielN> :>
<zyga> which revison system does gnome use?
<ska-fan_> cvs
<ska-fan_> with discussion going on atm
* zyga hopes they go to tla/baz
<Nafallo> baz.gnome.org :-)
<Nafallo> ... should be a good name indeed :-)
<zyga> foo.bar.ba.....
<zyga> nah ;] 
<zyga> arch.gnome.org sounds okay
<zyga> hmm
<zyga> http://arch.ubuntu.com/vim@products.ubuntu.com/=meta-info/signed-archive
<zyga> is this okay?
<wasabi> hmm.
<wasabi> my .apt thing is going to need to manipulate pinning
<srbaker> so what are my choices for audio players besides rhythmbox and muine?  any good gnome ones that i'm missing here?
<ska-fan> There's totem, but muine is really the best
<ska-fan> and there's jamboree
<Nafallo> beep
<srbaker> i can only get muine to do album and song, i can't get it to do "shuffle everything"
<ska-fan> load everything in the playlist and shuffle it
<ska-fan> but muine is probably not meant for shuffle everything
<srbaker> muine has some cool features.
<ska-fan> I still miss a good way to make sure that my files have correct meta data.
<srbaker> i like quod libet or whatever for tag editing.  that's cool
<ska-fan> Easytag is mind-blowingly complex to use.
<srbaker> ex falso is a little resource heavy
<srbaker> erm.  ex falso.  quod libet is a little resource heavy.
<ska-fan> srbaker: thanks for that tip!
<ska-fan> not in ubuntu it seems though.
<srbaker> ska-fan, you can run it directly from the source tarball :)
<ska-fan> grep
<ska-fan> great
<ska-fan> srbaker: I was looking for that kind of app for two years, thanks again :)
<srbaker> np, it's pretty awesome :)
<mdke> what burning app is shipping with breezy?
<Nafallo> mdke: dunno yet.
<Nafallo> mdke: or... nautilus-burner for data :-)
<mdke> Nafallo, cool thanks
<mdke> is there likely to be one? for audio burning and such
<Nafallo> mdke: serpentine would be me bet.
<Nafallo> s/me/my/
<mdke> haven't tried that one
<mdke> good name
<Nafallo> JaneW: hi dear :-)
<Nafallo> JaneW: hmm, there :-). but dear would be fine to ;-).
<JaneW> hehehe hello
<mdke> mako, here?
<JaneW> anyone know how to change text colour on a wiki? (moin moin?)
<mdke> is the site down? i can't connect
<Riddell> mdke: I was just about to poke elmo on the subject
<Riddell> kubuntu server down too
<mdke> let us both poke him
<JaneW> elmo everything in the data centre's going to disappear for 2-3 minutes...
<mdke> ah
<mdke> yes udu down too
<JaneW> luckilly my change was saved first...
<mdke> JaneW, http://moinmoin.wikiwikiweb.de/HelpOnFormatting on your previous question
<elmo> it's back
<mdke> yay
<elmo> janew: it's a wiki, you don't lose your changes if the website goes away temporarily
<elmo> (the changes are in your browser only, until you hit save changes)
<mdke> JaneW, pretty unlikely colours will work on the ubuntulinux.org/wiki tho
<JaneW> mdke: oic, thanks
<JaneW> mdke: I think I was looking there, got stuck in the 'parser' section
<mdke> *grins*
<elmo> ok, so now launchpad + authentication to the wiki / main website is going away for 10-15 mins.  sorry for the inconvenience
<JaneW> elmo: you pest!
<JaneW> ;)
<mako> mdke: hey dude
<elmo> JaneW: don't make me demonstrate my leet cross-continent menthos throwing skillz
* JaneW *giggles*
<JaneW> I dare you...
* JaneW must go - got a book to finish
<JaneW> night
* Riddell wanders off to get some methos while waiting for the data centre to re-appear
<JaneW> Riddell: don't do it!!!
<JaneW> you're stronger than that... resist the temptation.
<Riddell> mentos 
<Riddell> mmm, minty
<JaneW> NOooooooo!
* JaneW shakes head... another one lost
<Riddell> really should have stolen more of these at the end of the conference, I've almost run out
* JaneW still has some
<JaneW> been rationing them severely though
<mdke> oh hi mako
<JaneW> ok cheers
<mdke> mako, get my emails?
<mako> mdke: i'm not caught up on canonical email today
<mdke> oh right ok np
<mako> or any other email actually
<mdke> *laughs*
<mdke> just about that gpg business
<zyga> what's withe the mentos?
#ubuntu-devel 2006-05-15
<dAndy> if one were interested in learning how to build debs, is there some place someone could go to learn?
<lifeless> ubuntu-motu
<mdke> dAndy: also System/Help/System Documentation/Packaging Guide
<dAndy> mdke: just found that, should have started with the computer rather than the interweb, thanks
<mdke> dAndy: :)
<mdke> anyone around who knows how I can find out which fonts are used for various languages?
<Keybuk> *mumble* Pango *mumble*
* mdke types pango into a terminal
<Keybuk> I know that it decides, in co-operation with fontconfig and Xft which font can provide the right glyph on a character-by-character basis
<Keybuk> if you open Character Map, and select the font you "want", you get the same selections
<Keybuk> so if I select Arial in that, the glyphs that Arial can provide change, the ones it doesn't don't
<mdke> ah, yeah character map is very helpful, thanks
<Keybuk> and if you right-click a glyph, it tells you what font it used
<mdke> yep
<Keybuk> so I can right-click the Stargate symbol () with Arial selected, and see it came from Code2000
<mdke> so all I need to match is the right script to the language
<mdke> which I'm sure google is capable of helping with.
<Surak> Does someone know about any koreans using ubuntu? 
<Surak> I mean, a korean group?
<LaserJock> there isn't a LoCo team for Korea?
<tseng> mdz: dont mean to bother, but wanted to be sure you got my uvf mails
<Surak> LaserJock: I'm testing ubiquity. It seems to stuck when you select your language as korean.
<tseng> mdz: i have been switching mail servers
<mdz> tseng: I did, I've just been swamped
<Keybuk> mdz: btw, is that retchmail sync yours?
<sabdfl> Surak: ubuntu-ko@lists.ubuntu.com
<sabdfl> Surak: https://wiki.ubuntu.com/Atie
<sabdfl> Surak: https://wiki.ubuntu.com/KoreanTeam
<sabdfl> particularly the latter one
<ajmitch> morning all
<sabdfl> night all
<Surak> thanks sabdfl. I found that the ubiquity bug happens with other languages also
<Surak> they are farsi, macedonian and korean
<sabdfl> Surak: ok, could you file a bug on that for Kamion?
<mdz> Keybuk: nope, I noticed it there when I went to test
<mdz> Keybuk: I seem to recall a retchmail sync request or UVF discussion somewhere though
<Surak> sabdfl: done: bug #43907 - complete with debug output and every languages tested.
<Ubugtu> Malone bug 43907 in ubiquity "Language between "Euskaraz" and "Suomeski" doesn't work." [Normal,Unconfirmed]  http://launchpad.net/bugs/43907
<Keybuk> mdz: aye, nobody on the team has touched the bug though
<Keybuk> and nobody can remember doing it
<Keybuk> it could have been cprov testing something, I guess
<Keybuk> I'll get rid of it if it's not yours then
* Keybuk heads for dinner
<bddebian> Howdy peoples
<Surak> hello bddebian
<bddebian> Hello Surak
<sladen> elmo: yup, bug #35080, should have been closed with xkeyboard-config (0.8-5)
<Ubugtu> Malone bug 35080 in xkeyboard-config "Numlock key doesn't work on IBM t42" [Major,Fix released]  http://launchpad.net/bugs/35080
<Surak> does someone know what's the bug for the missing gtk theme in today's dapper live?
<tseng> mdz: thanks for looking, i hope you sneak a break in sometime
<bddebian> Heya Burgundavia
<Burgundavia> salut bddebian
<BenM> hey, has there ever been any talk of using prelink in ubuntu
<BenM> am looking for some content for the next round of blogging
<elmo> sladen: uh, don't think it has been then - I had the same problem today on an X41 with a docking station
<sladen> elmo: do you still have access to it (eg, is it in the office?)
<elmo> sladen: yeah (not right now tho, it being 1am and all)
<sladen> BenM: you /can/ use prelinking (apt-get install prelink).  It's unlikely to become a default...
<BenM> right
<BenM> but what are the reasons behind not being a default
<sladen> BenM: all the libraries in Ubuntu occupy more than 4GB of address space and you have to rebuild them all every time you upgrade anything
<BenM> there's an option to account for that
* BenM points out that both mac and fedora deal with the updating issue
<BenM> also, if you are out of date, it's not "bad"
<BenM> anyways, do you happen to have a pointer to any talk about this
<sladen> elmo: okay, I'll ping you in the morning and get you to do  xmodmap -pke | grep Num
<elmo> sladen: cool, thanks
* BenM would rather write a blog "i'm not sure why fedora prelinks and ubuntu doesn't"
<BenM> rather not
<Burgundavia> BenM: those kinds of blogs are usually misinterpreted and taken very badly
<BenM> exactly
<sladen> BenM: Keybuk did various timings;  I think one of the factors may have been that the percentage of the start-up time the prelinking provided turned out to be so small compared with the start-up time
<BenM> yes
<BenM> it does have memory benefits though
<BenM> because it reduces the # pages touched
<sladen> BenM: try: http://www.google.com/search?q=prelink+scott+remnant
<BenM> thanks
<BenM> i'm feeling good about ubuntu perf though
<BenM> now that there's icon cache, in proc applets
<imbrandon> anyone here tried the new qt4 designer ? or using it? for some reason i'm not getting any widgets 
<imbrandon> wondering if its just me or a bug in our packages
<Keybuk> prelink is a red herring
<Burgundavia> imbrandon: you might have better luck in #kubuntu-devel
<Keybuk> I'm going to start a webpage ... "Things that Keybuk says are pointless"
<Keybuk> #1 can be prelink
<Keybuk> and #2 can be initng
<Keybuk> :p
<Burgundavia> Keybuk: what about that preload thingy that behdad did for soc for fedora last year?
<Keybuk> the what the who did for where?
<Keybuk> oh
<Keybuk> that's something else *entirely*
<Keybuk> that's like our "readahead" package
<Keybuk> but for the user's desktop too
<Burgundavia> ah, ok
<Keybuk> prelink is when you futz around with shared libraries so that their symbols are already relocated when they're loaded
<Keybuk> saving you from relocating every symbol on load of the application
<Keybuk> it's an efficient way to massively increase your memory usage without any appreciable benefit in application startup time compared to an optimisation of the symbol table (which we do)
<BenM> s/increase/decrease
<Keybuk> increase
<BenM> my measurements show decrease
<Keybuk> *sigh*
<Keybuk> what do I know about shared libraries, anyway? :)
<BenM> probably more than me
<BenM> :-)
<Keybuk> with prelinking a library has to be loaded in exactly the same place every single time
<Keybuk> as soon as you need to move the library's address, you lose the benefit
<BenM> right
<Keybuk> that means you have to analyse every application on the disk
<Keybuk> and then ensure that every single application that could load a library loads it in the same place
<Keybuk> which means you also have to move all the other libraries around as well
<Keybuk> so a library has a fixed load address and space in memory every single time it's loaded
<BenM> so, you have to do work every time you upgrade
<BenM> to keep the benefit
<Keybuk> so a typical application will actually use libraries spread out over, say, 250MB of memory
<BenM> ok
<Keybuk> where if it could just load the library wherever it likes and relocate the symbols (the default) the libraries may only be spread into 10MB of memory
<Keybuk> because they can just be loaded sequentially
<BenM> but that's virtual memory
<Keybuk> rather than spread wide
<BenM> most desktop apps
<BenM> probably don't need 2 gb of unfragmented address space
<Keybuk> it's virtual memory, yes; but the mapping between virtual and physical memory is closer than you may think for speed reasons
<BenM> ok
<BenM> i don't know that much about the hardware level
<Keybuk> while it's good "on paper", in practice it actually causes more memory usage
<Keybuk> and remember, every time you disconnect virtual and physical memory, you have to futz in the processor, which actually slows things down again
<BenM> might there be a small set of libraries that would be worth prelinking
<BenM> say, the libgnomeui stack or something
<Keybuk> prelinking also assumes that ALL symbols are relocated when the application starts
<Keybuk> not to mention that you have to calculate each relocation individually, and can't just do one for the library and work the rest out from there
<Keybuk> when in reality, only those really critical symbols are relocated first time AND most of them can be calculated trivially
<Keybuk> and the rest are just done whenever the function is first called, and the relocation cost is lost in the general idleness of the CPY
<Keybuk> uh, CPU
<Keybuk> it also assumes that libraries can be magically summoned into memory, and that most of the time is actually lost to relocation
<Keybuk> while that's probably true for libc, and the gnome stack, which are nearly always in memory
<Keybuk> anything else (I always pick on OpenOffice) needs to be hauled off disk
<Keybuk> which involves I/O
<Keybuk> which gives you plenty of free time while you wait for the disk to get around to it
<Keybuk> given all of that, it actually turns out that there's benefit to arranging the symbol table a little more efficiently (so symbols hash better, and are easier to find) 
<Keybuk> because the majority of relocation time is spent in strcmp
<Keybuk> we've done that since the beginning, iirc
<BenM> ok
<Keybuk> and Ubuntu consistently gets comments that it's one of the "snappiest and fastest" distributions
<BenM> so, one of the things i'm interested in
<Keybuk> even compared to prelink-crazy ones
<BenM> is removing the extra writable memory
<Keybuk> which extra writable?
<BenM> for example, prelinking seems to help with gstreamer
<Keybuk> the symbol table?
<BenM> no, with stuff in .data
<Keybuk> .data is initialised global data in code
<Keybuk> it's not really that worrysome?
<BenM> that needs relocation
<BenM> like a table of pointers to char*s
<BenM> some apps like lots of these
<BenM> we need to fix them
<BenM> but prelinking seems to act as a nice stopgap measure
<BenM> because it pre-relocates
<Keybuk> I can't think of many examples off-hand that do that
<BenM> there are *LOTS*
<Keybuk> remember not to confuse char * with char[]  :)
<BenM> try looking at the smaps for mixer_applet
<BenM> specifically, gstreamer
<BenM> all of the plugins
<BenM> have TONS of tables in .data
<Keybuk> are the tables intended to be modified?
<BenM> many of which seem to get made dirty memory
<BenM> no, they are const
<BenM> but have pointers
<Keybuk> then they should be declared const
<BenM> and so need relocation
<Keybuk> and then they get put in .text
<BenM> that doesn't matter
<BenM> if you have const char** x = {"a","b","c"...}
<BenM> it's still trouble
<BenM> i know you can do tricks
<Keybuk> and then you just relocate the .text section, and remember to perform a relative relocation the first time the pointer is asked for
<BenM> but not everyone does
<Keybuk> gcc takes care of all this
<Keybuk> or just buy an AMD64 :p
<BenM> dunno, from what i can tell, it's an actual issue
<Keybuk> of course, large amounts of .text or .data in a shared library is generally naughty
<Keybuk> so you have a point there
<BenM> yes, i know
<BenM> but, fixing it
<BenM> is a major undertaking
<Keybuk> do you have an example of a source file that does that, btw?
<BenM> look at libxvidcore.so
<BenM> i don't know the source files
<BenM> it has 668 kb of writable mappings
<BenM> 140 kb of them are dirty for me
<BenM> this is loaded by mixer_applet2
<BenM> for god only knows what reason
<Keybuk> hmm
<Keybuk> I don't see 668KB 
<Keybuk> .data is only 37KB
<Keybuk> .bss is 434KB though :)
<Keybuk> that may be an AMD64 different
<BenM> yes
<BenM> the bss is nasty
<Keybuk> hmm, .bss is 470KB on i386
<BenM> luckily, not all of it is used
<Keybuk> .data is actually much smaller
<Keybuk> only 912 bytes
<BenM> mmm, .data here is small
<BenM> why the hell is there such a big mapping
<Keybuk> the .got is small too
<BenM> can you run http://www.contrib.andrew.cmu.edu/~bmaurer/memory/smem.pl
<BenM> pass the pid of mixer_applet2
<Keybuk> what does that actually do?
<BenM> reads /proc/PID/smaps
<BenM> in a friendly way
<Keybuk> like pmap does? :)
<BenM> pmap doesn't give me data about how many pages are dirty
<Keybuk> true
<BenM> that's the data i really want :-)
<BenM> btw, there's a column in pmap for it
<Keybuk> I just tend to read the actual /proc files
<BenM> the smaps are sorta verbose
<BenM> not really a table
<Keybuk> anyway, let's look at this
<Keybuk> which map for you is 668KB ?
<Keybuk> eww, 4MB heap just for a volume control ... I hate GNOME programmers, they're so damned sloppy
<BenM> dude
<BenM> it gets worse
<BenM> they load the WHOLE FUCKING GSTREAMER PLATFORM
<Keybuk> *shrug* nothing wrong with that
<Keybuk> gstreamer's bound to get loaded by something
<Keybuk> chances are if you've got a volume control, you're going to use it
<Keybuk> ie. going to play something
<BenM> yes, but the per-app cost is rather hi
<BenM> volume control is in the default distro
<Keybuk> meh, I have no problem with audio libraries being "preloaded" :p
<BenM> hahahaha
<Keybuk> not on a modern desktop, anyway
<BenM> seriously, does every desktop need libxvidcore loaded
<Keybuk> there could be some improvement to when plugins are actually loaded
<Keybuk> I imagine that's somewhere down their todo list after getting decent coverage
<BenM> anyways, the important thing is the per-app private memory costs
<Keybuk> indeed
<Keybuk> btw, it's refreshing to talk to someone who already knows the difference between private and shared memory
<Keybuk> most of the people who bitch about memory usage forget about shared
<BenM> i know
<BenM> i want g-s-m to give good numbers
<BenM> with smaps
<Keybuk> hell, half of them think the X server really does use 1024MB of memory
<BenM> we have the data
<BenM> i filed a bug for this
<Keybuk> I still can't find this map of yours though, which is it?
<BenM> 	Bug 43677 
<Ubugtu> Malone bug 43677 in gnome-system-monitor "Meaningful default memory stats" [Normal,Unconfirmed]  http://launchpad.net/bugs/43677
<BenM> http://pastebin.com/708667
<BenM> also, note how loading 50 million plugins
<BenM> also costs 4kb of private memory each
<Keybuk> I don't see the 668KB there
<Keybuk> 4KB is a standard overhead for every shared library
<BenM> that was vmsize
<BenM> i know
<Keybuk> wouldn't worry about it :)
<BenM> but 50*4kb
<BenM> adds up
<BenM> does the volume manager need libgstvideoflip.so
<BenM> #
<BenM>      260 kb        0 kb      256 kb
<BenM> #
<BenM>      668 kb        0 kb      140 kb   /usr/lib/libxvidcore.so.4.1
<BenM> #
<BenM>      964 kb        0 kb       72 kb   /usr/lib/libvorbisenc.so.2.0.2
<BenM> #
<BenM>       72 kb        0 kb       72 kb   /usr/lib/liboil-0.3.so.0.1.0
<BenM> #
<BenM>       64 kb        0 kb       64 kb
<BenM> note how the ones that are annon are *probably* .bss
<BenM> i could track down who's responsible
<Keybuk> that's 0 kb dirty for me
<Keybuk> it's also 0kb dirty in your own paste
<sladen> isn't .bss allocated on demand-write?
<BenM> dirty is 3rd column
<BenM> sladen, yes
<BenM> however, some of the libs write it
<BenM> on demand
<Keybuk>      668 kb       40 kb        0 kb   /usr/lib/libxvidcore.so.4.1
<BenM> wtf
<Keybuk> ^ line 295 of your own paste
<BenM> oh
<BenM> that's shared
<BenM> you want the top one
<BenM> those are private mappings
<Keybuk> interestingly, my mixer applet doesn't seem to map in xvidcore
<Keybuk> can you pastebin me your smaps file?
<BenM> sure
<Keybuk> also pastebin me "objdump -x /usr/lib/libxvidcore.so.4.1"
<BenM> http://pastebin.com/708671
<BenM> http://pastebin.com/708673
<Keybuk> hmm
<Keybuk> can't really tell what the dirtyness is
<Keybuk> as you say, probably a lot of stuff in .bss that shouldn't be
<BenM> yeah
<BenM> it's a pretty nasty setup
<BenM> really, we should get the mixer applet not to load the whole gstreamer framework
<Keybuk> the fact it's 668KB isn't interesting
<Keybuk> that's just the linker being lazy
<Keybuk> or get the gstreamer framework to load itself piecemeal as needs be
<BenM> yes
<BenM> both would be good
<BenM> if you have totem with encoding X movie
<BenM> you don't need encodings Y Z
<Keybuk> interestingly, a quick glance over the source; I don't see any bss
<Keybuk> they actually seem to be quite careful to declare things static const
<Keybuk> so either gcc is playing silly buggers, or they've missed one big one
<BenM> yeah
<Keybuk> hmm, nah, won't be gcc ... it's dirty
<Keybuk> oh, found it
<Keybuk> lazy colourspace initialisation
<Keybuk> rather than hard-code the table, they build it at runtime
<Keybuk> cute
<BenM> ya
<BenM> very
<BenM> especially since it's not so lazy
* Keybuk would have done that at compile time
<BenM> they load it on startup
<BenM> i'd be OK if they did it first movie that was played
<mjg59> Anyone have a machine using ata_piix handy?
* BenM gets food
<Keybuk> BenM: that kind of thing is bad
<Keybuk> but const/static tables of strings are ok
<Keybuk> because they're not implemented how you think
<Keybuk> (though the author really should learn to use char[]  not char*)
<Keybuk> I assume you have read Drepper's DSO howto?
<robertj> has having ctl+alt+delete open the task manager been discussed?
<Keybuk> robertj: what would be the point?
<Keybuk> why do you want the task manager?
<robertj> Keybuk: well ctl+alt+delte doesn't appear to do anything and windows users might expect it be there...so why not?
<zul> ick
<Keybuk> *shrug* windows users might expect that any five key presses should crash their computer
<Keybuk> but we don't do that
<Keybuk> I ask again, why do you need a task manager?
<Keybuk> (at this point, I'll point out GNOME doesn't *have* a task manager :p)
<robertj> hrmm I always thought there was a nice xkill gui
<Keybuk> *shrug*
<robertj> and the answer is you don't really want a task manager you want to make things die
<Keybuk> if you need to kill an application, click the little "[X] " on it
<robertj> Keybuk: ahh, but full-screen games don't always have nice X's
<Keybuk> full screen games also tend to steal any and all keyboard presses and shortcuts
<Keybuk> e.g. Alt+F4
<robertj> Keybuk: and there is no facility for reserving certain keystrokes?
<Keybuk> dunno
<Keybuk> I must admit that the only thing I had to hand that can go fullscreen (evince) responded just fine to Alt+F4
<Keybuk> so maybe that would work for your game-that-keeps-hanging too
<Keybuk> if we can reserve keystrokes, I would argue that is the keystroke we should reserve
<Keybuk> anyway, bedtime
<robertj> Keybuk: nighty
<sladen> mjg59: this R52 has both ata_piix and ahci loaded
<mjg59> sladen: Which one is being used?
<sladen> ata_piix               11012  11
<sladen> ahci                   17668  0
<mjg59> sladen: Could you stick lspci -vxxx up somewhere?
<sladen> mjg59: http://www.paul.sladen.org/ubuntu/upload/thinkpad-r52-ahci-lspci_-vxxx.txt
<sladen> mjg59: btw, this machine won't boot if a PCMCIA-ide device is inserted on boot
<mjg59> Urgh. Why?
<sladen> mjg59: the cardbus controller is before the SATA controller in the PCI tree.  It hangs at 'Configure LVM devices'
<infinity> Because the devices get reordered, and root goes away?
<mjg59> But it's a SATA machine...
<mjg59> (or, at least, libata)
<sladen> yes, root is on /dev/sda and the pcmcia-ide is  /dev/hdX
<mjg59> sladen: What if you boot without usplash?
<sladen> mjg59: oh I get lots of debug spew and  hda timeout:  I think
<sladen> lemme check
<mjg59> sladen: So the LVM autoconf breaks PCMCIA IDE devices?
<sladen> mjg59: "Configuring RAID..." hangs until you do Ctrl-C
<mjg59> sladen: Doing what?
<sladen> and then "Configuring LVM" stops the machine booting any further
<sladen> mjg59: "Doing what" ?
<mjg59> No output while it's in that state?
<sladen> without usplash;  "Setting up RAID" can be Ctrl-C'ed past.  "Setting up LVM Groups" can be SysRq-e 'd past.  Which gives me a working desktop (but not virtual console logins of course)
<sladen> mjg59: lots and lots of  "[4294721.098000]  hda: lost interrupt
<sladen> [4294971.098000]  hda: lost interrupt
<sladen> [4294971.098000]   hda1
<sladen> [4294971.098000]   hda:<4>hda: lost interrupt
<sladen> ah, I think it's failing to read the partition table because of lost interuppts and hence blocking and not making any progress
<mjg59> Right
<sladen> now, this doesn't occur if the ide card is inserted after boot
<sladen> cat /dev/hda  hangs that process
<sladen> with it sitting in an Uninterruptible Sleep
<fabbione> morning
<bddebian> Hello fabbione
<bddebian> Gnight peopleses
<pitti> Good morning
<ajmitch> morning pitti 
<fabbione> morning
<pitti> hi ajmitch 
<jdub> infinity: know about the libdevmapper dupe?
<infinity> "dupe"?
<infinity> You mean the SONAME bump that was just introduced?
<jdub> yeah, and there are still packages that depend on libdevmapper1.01
<infinity> I would assume so, since the new one was only just uploaded. :)
<fabbione> infinity: as yesterday
<fabbione> there shouldn't be many anyway
<jdub> just two on my server
<infinity> 6 packages.
<infinity> Oh, make that 5.
<infinity> dmraid, cryptsetup, multipath-tools, lilo, eject
<infinity> (LVM has already been uploaded, just isn't built yet)
<fabbione> infinity: i take multipath.tools
<lifeless> does evms not directly depend ?
<infinity> lifeless: Evidently not.
<lifeless> cool
<lifeless> (I'm just checking cause I don't want my boot broken again ;))
<infinity> What I'd like to know is why my dep-waits aren't getting cleared by LP anymore.
<infinity> What broke on the last rollout?  *sigh*
<dholbach> good morning
<jsgotangco> good morning dholbach 
<dholbach> jsgotangco: hey jerome
<fabbione> infinity: multipath-tools done
<dholbach> infinity: how is the test-rebuild machinery going?
<infinity> Going and gone.  I'm bugfixing and filing at the end of the week, then trying again on all arches this time. :)
<infinity> (Fabio did a really fast Sparc run that was more than enough to keep me busy for a while)
<thom> now those are two words i never thought i'd see together
<Mithrandir> thom: Fabio and fast or fast and sparc? ;-P
* Mithrandir runs away from Fabio
<thom> i couldn't possibly comment
<fabbione> eheh
<fabbione> thom: it took me 36 hours flat to rebuild all of dapper on the T2000 :)
<fabbione> thom: screw your opterons
<infinity> thom: Sun went and gave him some rather... Beefy hardware.
<fabbione> infinity: it's not even top class
<infinity> I understand it's rather loud, and is probably causing him testicular cancer, so I'll get the last laugh.
* ajmitch sighs
<ajmitch> if only I had a decent net connection for those T2000s
<fabbione> i can live with testicular cancer.. but i can't suffer the noise
<fabbione> infinity: when do you plan to do another round of dapper-autotest?
<fabbione> (ans yes please include sparc)
<infinity> fabbione: Beginning of next week sounds good to me.
<fabbione> infinity: i will be vacation...
<fabbione> holidays
<fabbione> no work
<fabbione> relax
<fabbione> enjoy
<infinity> It'll be main-only, so your test was probably the only universe test we'll have time to do (unless a community person steps up to do universe again)
<infinity> fabbione: Hey, I don't need you to be around when I do it. :)
<fabbione> infinity: well i can re-run universe again if you want me to
<Mithrandir> infinity: will that interfere with releasing flight-8 next week?
<infinity> fabbione: Unless you want to give me access to your beast to do another universe run.
<infinity> Mithrandir: Flight-8 scheduled for next Friday, I assume?  (ie: on 10 days or so)
<infinity> Mithrandir: If so, we shouldn't step on each others' toes in any irritating ways.
<fabbione> infinity: i am not happy to power everything on while i am away because the UPS battery is dead (replacement on the way) and it starts to complain after some hours of work
<infinity> s/on 10/in 10/
<infinity> fabbione: Ahh, fair enough.  Well, if you want to do another universe run "whenever", I'm sure MOTU would appreciate having access to the logs.
* ajmitch can probably arrange a test rebuild of universe, it might get done by release day :)
<Mithrandir> infinity: yeah, since I'm gone on Wednesday due to people wandering around in the streets waving flags and dressed in national costumes, dresses and suits, Thursday won't be good.
<fabbione> infinity: if i get the battery before friday (unlikely) i will give you access and you can play while i am away
<infinity> fabbione: My hands will be full fixing main, so I can't do much there (but I also don't want you to go out of your way either... Only do it if it's "easy")
<fabbione> infinity: running the buildds here is dead easy.. the problem is the power to the rack atm
<fabbione> infinity: that's the only thing that concerns me since i am traveling away
<infinity> Do you need me to ship you some uranium?
<fabbione> infinity: specially because the SUN need access to the SAN to manage that load
<fabbione> infinity: that would do thanks :)
<fabbione> and the cache batteries for the SAN cache are dead.. so even a small spike might make the entire system unuseable
<fabbione> and trash the disks
<infinity> ajmitch: I'll see about seperating main from universe from he logs of the last run, so I can publish the universe logs for you guys.
<ajmitch> infinity: that would be great, thanks
<infinity> ajmitch: It's pretty much entirely slipped my mind due to my TODO list growing faster than an erection on a 12 year old.
<fabbione> ahaha
<infinity> (Unfortunately, my TODO doesn't exhibit other symptoms to extend the metaphor, since it would then have finished 5 seconds after growing..)
<ajmitch> that's an interesting metaphor :)
<pitti> slomo: yay, two vulns in avahi which were fixed in 0.6.10; one of them is remote code execution
<slomo> pitti: uh oh... ok, i'll get it updated (or the fixes backported) asap
<pitti> slomo: oh, would you? thanks a million
<pitti> slomo: the new version should be fine as long as it only fixes bugs (I didn't check)
<pitti> slomo: http://0pointer.de/cgi-bin/viewcvs.cgi/*checkout*/trunk/docs/NEWS?root=avahi is the changelog
<fabbione> zakame: ping?
<slomo> pitti: i know... i followed the development ;) but i remember a soname bump somewhere... let me check
<pitti> slomo: oh, it's said to be compatible to older versions
<infinity> ajmitch: If I just publish the logs as a big MBOX, can you deal with that?  They're sitting in an IMAP folder right now.
<pitti> slomo: in that case we shuold backport, but let's hope the 0.6.x branch is stable :)
<ajmitch> sure, I sort through most of everything else that way
<pitti> slomo: CVE-2006-2288 is the DoS, CVE-2006-2289 the buffer overflow (for the changelog)
<infinity> ajmitch: Okay, cool.  Can you poke me and remind me again if I don't do it in a day or two?
<infinity> ajmitch: release crunch is making me a scatter-brain, so reminders are good.
<ajmitch> yep
<sivang> morning all
<pitti> sivang: hey Mr. ubuntu-dev, good morning! :)
<ajmitch> hi sivang 
* infinity offlines all the buildds for maintenance.
<infinity> If nothing builds in the next 30 mins... Cope! ;)
<slomo> pitti: ok, no soname bumps :) i'll update, ask for a UVF exception and upload later today or tomorrow :)
* sivang hugs pitti , ajmitch 
<sivang> pitti: hey there :)
<slomo> hi sivang :) so everything went fine yesterday? congrats :)
<sivang> slomo: indeed, thank you :)
<slomo> pitti: avahi updated... now i only need the uvf exception approved and can upload then... but i have to leave now for some hours, i'll upload when i'm back :) bbl
<dholbach> mvo: happy hug day - I think bug 43747 is a dup of one of yours, but I couldn't find it
<Ubugtu> Malone bug 43747 in gnome-control-center "proxy configuration is confusing" [Wishlist,Confirmed]  http://launchpad.net/bugs/43747
<mvo> dholbach: let me have a look
<mvo> dholbach: well, not really. the difference is that if he uses gksu, he will have a correct proxy
<mvo> dholbach: I think his suggestions to add something like "per-user proxy configuation" (or something like this) is the most sensible
<dholbach> mvo: ok, then you can tell him that's it's a design decision :-)
<mvo> dholbach: I can comment on the bug, but its not a descion descision :)
<dholbach> mvo: you can tell them it is :-p
<dholbach> can some kernel and laptop experts join #ubuntu-bugs?
<dholbach> and everybody else is welcome to join too!
<dholbach> it's the hug day! and if you want to get your bugs triaged - this is the time :-)
<jsgotangco> ohhh
<dholbach> and if you want to have (i'm not going to say who used that term) some 'minions' around you - this it the time to help people to triage bugs better :-)
<infinity> Sounds like a sfllaw term to me. :)
* mvo giggles
* dholbach doesn't comment
<infinity> Not commenting is just as incriminating. :)
<Treenaks> dholbach: Are there X experts in -bugs? :)
<Treenaks> dholbach: (or will there be, tonight)?
<fabbione> Treenaks: me?
<fabbione> oh tonight.. no
<infinity> Okay, I just did some buildd mangling and then a mass-give-back.
<infinity> If any of you have a build/fix that MUST GET THROUGH RIGHT NOW, ARGH, then poke me and I can push your build to the top of the queue.
<Znarl> We are preforming network testing in the data centre for the next hour.  This may result in a small amount of connectivity problems to the data centre.
<freeflying> pitti: ping
<pitti> hi freeflying 
<freeflying> pitti: some issue about kde-i18n-zhtw, many pos of zhtw not in lanuage-pack-kde-zh
<caleb-> pitti: language-pack-kde-zh has only 3 pos for zh_TW(Taiwan)
<caleb-> pitti: and language-pack-kde-z has no option for Traditional Chinese...
<caleb-> pitti: However, it is ok in Debian.
<pitti> caleb-: I don't understand, Debian does not have language packs
<Mithrandir> TheMuso: can you check if 39472 and 39473 are fixed and if so, close them?
<caleb-> pitti: Debian kde 3.5.2 has those pos for zh_TW.
<caleb-> pitti: but ubuntu has only zh_CN.
<pitti> caleb-: language-pack-zh-base has 78 PO files for zh_TW
<pitti> ah, KDE
<pitti> caleb-: language-pack-kde-zh-base: 313 PO files -- that seems fine?
<pitti> caleb-: ah, you didn't look into -base, I suppose; l-p-kde-zh only has updates (and should actually be empty in dapper)
<yzcie> language-pack-zh-base in Breezy has only 3 PO files for zh_TW...
<pitti> yzcie: these are only updates from Rosetta; it seems that translators just touched these three for Breezy
<yzcie> pitti, so how can i get the other po files for zh_TW ?
<caleb-> pitti: those pos are zh_CN only, not zh_TW...
<caleb-> pitti: Debian has zh_TW pos.
<pitti> yzcie: as I said, they are in language-pack-kde-zh-base
<caleb-> pitti: http://packages.ubuntu.com/cgi-bin/search_contents.pl?searchmode=filelist&word=language-pack-kde-zh-base&version=dapper&arch=all&page=1&number=all # pos in language-pack-kde-zh-base
<yzcie> pitti: language-pack-kde-zh-base-20051011/data/zh_TW/LC_MESSAGES/ has only 3 po files.
<pitti> yzcie: that's the breezy version
<pitti> yzcie: the dapper version has plenty
<pitti> caleb-: this page seems out of date; just look in the debs on http://archive.ubuntu.com/ubuntu/pool/main/l/language-pack-kde-zh-base/, dapper has plenty of zh_TW files
<infinity> Can someone who knows something about what/when/where/why we automount certain detected Windows partitions look at this bug and reassin it?  https://launchpad.net/distros/ubuntu/+source/evms/+bug/41020
<infinity> (It's obviously not an evms bug and was misfired by the submitter)
<tepsipakki> uh, is there a way to unduplicate a bug?
<infinity> tepsipakki: Dupe it with a blank entry.
<pitti> caleb-: KDE was also imported into Rosetta a few days ago, breezy will get the applicable ones in the next update as well
<tepsipakki> infinity: hah, that did it, thanks
<ivoks> infinity: will there be another series of uploads from debian sid for universe packages?
<caleb-> pitti: Mmmm, the deb looks ok. Thank you!
<Mithrandir> infinity: I'm not allowed to look at that bug
<infinity> ivoks: Only those that are requested as UVF exceptions by MOTU.  We're not doing any mass imports until edgy opens.
<infinity> Oh, for the...
<infinity> Mithrandir: The submitter marked it "private", not wonder no one's triaged it.
* infinity unprivates it.
<infinity> Mithrandir: Try now.
<yzcie> pitti: thank you :)
<infinity> Mithrandir: I suspect it's a bogus bug anyway, but I have no idea what automounting magic we do, or if it could indeed fail, so whatever. :)
<ivoks> infinity: ok, then i guess mine will get uploaded :) thanks
<Mithrandir> infinity: debian-installer is the piece which sets it up automatically.  He's probably unselected it in the UI.
<infinity> Mithrandir: Care to tell him that in a comment on a reassign? :)
<Mithrandir> infinity: willdo
* infinity smacks the user for marking it "private".
<infinity> Given that evms probably doesn't even have any default subscribers, I suspect the only people who can even see the bug are LP admins, and I'm only one of those for comical reasons best not discussed.
<Mithrandir> we should trick Corry into subscribing to it, since he's upstream.
<Mithrandir> and he's even commented on a bug in lp.
<Znarl> Network testing has finished.  
<Treenaks> keyweed_: 
<fabbione> Znarl: danke
<lifeless> infinity: that should be a bug
<infinity> lifeless: Do you have any clue what's up with https://launchpad.net/distros/ubuntu/+source/evms/+bug/38924 ?
<Ubugtu> Malone bug 38924 in evms "breezy->dapper: My lvm devices have disappeared" [Normal,Unconfirmed]  
<zakame> hi all
<zakame> fabbione: pong :)
<fabbione> zakame: hey dude
<fabbione> zakame: i am preparing some work for you
<fabbione> zakame: do you have time to discuss about it?
<zakame> fabbione: ooh! :D I was just about to ask you about that :D
<zakame> sure
<fabbione> zakame: ok
<fabbione> let's take this to /msg
<zakame> ok
<jsgotangco> hmm hrmmm
* infinity knocks off some evms bugs and heads out for dinner.
<infinity> dholbach: I expect hugs when I get back.  LOTS OF THEM.
<StevenK> Heh
* dholbach hugs infinity!
* dholbach triple-hugs infinity!
<StevenK> Hrm. I think I managed to close a bug today too.
<dholbach> StevenK: join the party in #ubuntu-bugs! :)
<infinity> StevenK: What's the matter?  Jealous? :)
* dholbach hugs StevenK! :-)
<StevenK> infinity: Duh! :-)
<infinity> Mithrandir: Make syck build on amd64, and I'll love you forever (and dholbach will hug you!)
<dholbach> Mithrandir: Yeah!
<Mithrandir> infinity: I'm looking at it, but ended up accidentially gdb-ing emacs instead of syck. :-P
* sladen cluster-hugs infinity 
<infinity> Mithrandir: I often get the two confused myself.
<pitti> Diziet: is your parallel printer automatically detected in gnome-cups-add (if not yet configured)?
<jsgotangco> hey sabdfl 
<sabdfl> moin moin
<Diziet> pitti: I don't know, it's upstairs connected to the house server atm.  Would you like me to try it ?  Can I connect it with dapper booted and run gnome-cups-manager ?
<pitti> Diziet: that would rock
<pitti> Diziet: i. e. the printer must not yet be configured in cups
<pitti> Diziet: we have many reports that parallel printers work in principle, but gnome-cups-add does not show them in the 'automatically detected' list
<pitti> Diziet: I have some things I'd like to try and check out, but I don't have a parallel printer
<pitti> Diziet: do you have IRC upstairs?
<dholbach> hey sabdfl - happy hug day!
<dholbach> pitti: do you know if the millions-of-floppy-devices bug was fixed already?
<pitti> dholbach: in dapper? I'm not aware of any grave problems
<pitti> dholbach: and ENOFLOPPY here :/
<pitti> dholbach: in breezy they mostly resulted from the pmount bug which was fixed in b-updates ages ago
<Diziet> pitti: I'm just downstairs again, looking for a spare parallel cable.
<zul> hey sabdfl 
<dholbach> pitti: from #ubuntu-bugs
<dholbach> <JustinLynn> anyone know why I might be seeing multiple non-existant floppy disk drives?
<dholbach> <JustinLynn> ^in nautilus
<pitti> dholbach: ah, that one
<pitti> dholbach: I joined #u-b
<Diziet> NB this printer is very old.  1988?
<pitti> Diziet: hm, then it might not yet auto-identify itself yet; dmesg should have a line with parport0 with the printer name if it already advertises itself
<Diziet> I think I have another one which is somewhat newer.
<Diziet> Let me try with this one first.
<Diziet> [4294686.868000]  parport: PnPBIOS parport detected.
<Diziet> [4294686.868000]  parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,ECP,DMA] 
<Diziet> But no printer name.
<Diziet> gnome-cups-manager doesn't show it.
<zakame> hi all! happy hug day! :D
<fabbione> Diziet: that's normal kernel logging for detecting the parport, nothing new about it
<fabbione> Diziet: there is no probing of what is connected after the parport
<Diziet> Let me try with this less prehistoric printer I found under a pile of dust.
<Diziet> fabbione: pitti seemed to think that there was a way for the printer to report its name and that this would show in dmesg (if the printer supported it).
<pitti> Diziet: yes, it's a protocol called ISO-1284 or so; and it apparently worked fine in breezy
<fabbione> Diziet: i have never seen it.. the kernel doesn't drive the printer (not on parport)
<pitti> Diziet: I heard a report that modprobing the 'ppdev' module fixed it; maybe you can try that?
<Diziet> I have a breezy install on this machine too, so I could try that.
<Diziet> OK, sure.
<pitti> I still don't know whether this is a cups or a kernel regression
<Diziet> Err, have you looked at the code in CUPS ?  Is it using ppdev to speak to the printer directly ?
<pitti> Diziet: also, does 'lpinfo -v' show a parallel printer (unnamed) at all?
<Diziet> Not AFAICT.  I know it's plugged in because the printer got reset during the bootup.,
<pitti> Diziet: hm, 'lp' module is loaded?
<Diziet> modprobe lp fixed the output from lpinfo -v
<Diziet> direct parallel:/dev/lp0
<pitti> ah, that's it
<Diziet> And various similar.
<pitti> Diziet: the missing lp module was a bug recently fixed in ubiquity
<pitti> Diziet: so you seem to have the same problem - printer is detected, but without a name
<pitti> Diziet: so, it would be interesting to see now whether it works with a breezy kernel
<Diziet> Yes, this dapper install was last updated some time last week I think.
<Diziet> Let me reboot into breezy.
<Diziet> Do you have any info about which printers we would expect to support this protocol ?  The one I'm trying now is an Epson Stylus 800+.
<Diziet> Previously a Star LC10 colour.
<pitti> Diziet: no, unfortunately not, but from what I can tell, pretty much all resonably modern ones should do
<Diziet> Some would argue that `reasonably modern' doesn't cover any parallel port printer :-).
<pitti> Diziet: 'modern' in the domain of parallel printers :)
<Diziet> OK, this one has loaded lp properly.
<pitti> lp module is a different bug, but that's the easy one and sorted
<pitti> Diziet: does dmesg | grep parport reveal the printer name now?
<Diziet> No.
<Diziet> And gnome-cups-manager doesn't seem to see it.
<Diziet> I think this is my newest printer.
<pitti> ok, then it seems your printer can't advertise itself
<pitti> Diziet: thank you for the time for checking
<Diziet> There's the LJ6 upstairs but I don't want to carry it down.
<Diziet> Sure.
<fabbione> Diziet: what if you just try to print?
<fabbione> does that work?
<Diziet> fabbione: I'm pretty sure it would.
<pitti> fabbione: printing works (in the bug reports), you just have to manually configure the printer
<Diziet> I mean, if I echo things to /dev/lp.
<Diziet> The alleged bug is lack of autodetection.
<Diziet> This breezy has about four test printers set up from various earlier experiments but I don't think that should make any difference.
<pitti> Diziet: g-cups-add only shows printers that are not yet configured
<Diziet> pitti: None of these were on the parallel port.
<Diziet> And none of them were the same kind of printer as these two I just tried.
<Kinnison> dholbach: How is the new g-p-m holding up for you?
<dholbach> Kinnison: looks very good
<dholbach> Kinnison: you made the world a better place - remind me of giving out drinks in Paris! :-)
* Kinnison doesn't think he'll be in paris. Not sure yet
<lifeless> infinity: possibly
<fabbione> mjg59, sladen: ping?
<Seveas> Kinnison, should we kidnap you to make sure you come to paris?
<Kinnison> Seveas: I'll be busy working on soyuz again by the time the paris conference happens
<Kinnison> Seveas: and with moving house, I can't really afford to take time off to attend as a holiday
<Seveas> ah, well too bad 
<ogra> yes, it is
* Treenaks will be moving house as well, so I might not be able to come either
<Kinnison> Treenaks: good luck :-)
* ogra also moves house, but nontheless will come
<Kinnison> ogra: You kinda have to :-)
<ogra> Kinnison, and my moving stretches over several months :)
<Kinnison> :-)
<Mithrandir> seb128: is there a way to add an applet to a panel using the CLI?
<giftnudel> <Mithrandir> seb128: is there a way to add an applet to a panel using the CLI?
<giftnudel> seb128_ ^^
<seb128_> Mithrandir: no
<Mithrandir> seb128_: ok. :-/
<seb128_> maybe after the SoC of this year ....
<Mithrandir> it'd be nice to have, since I want to do that in my "restore setup after install" script.
<ogra> you could do horrible ugly fiddling in the users .gnome2/panel2.d/default/launchers/ with a .desktop file but i'm sure thats not suggested at all 
<ogra> and might have strange sideeffects
<seb128_> changing user datas that way it not a good idea imho
<ogra> yep
<seb128_> and changing the panel config require to change some gconf keys too
<ogra> thats what i thought, thus the sentence about the sideeffects :) 
<ogra> its surely the wrong way, but its *a* way
<janimo> slomo: hi, do you have any pending uploads for abiword?
<janimo> it will need a rebuild these days and if you already have something queued no need to do that explicitely.If not ok, just wanted to know
<nomed> hi all , hi janimo 
<janimo> nomed: hi
<janimo> nomed: have you and jmak talked about the default gtkrc?
<janimo> he sent me one but has not reference to your icon theme stuff
<nomed> janimo, talking yes
<nomed> janimo, that'll be just one echo :)
<janimo> it's better for you two to make a theme you both agree upon before I upload
<nomed> janimo, yep
<janimo> yes, but I prefer someone else do that echo ;)
<nomed> i like the blue one ..
<nomed> but the menu text is black
<janimo> so I just take it and upload it and not mess with it more
<nomed> janimo, ok :)
<janimo> let's discuss this in the meeting today if you are there
<nomed> i'll be
<janimo> ok 1:30 hours from now
<nomed> dholbach, around ?
<ogra> nomed, he's lunching
<kgoetz> sivang: bug reports are always good when your starting imo
<nomed> ok .. thanks ogra 
<sivang> kgoetz: yes, there's one I don't understand why happens, unless that user doesn't have a cdrom at all - malone #43941
<Ubugtu> Malone bug 43941 in hubackup "KeyError: 'storage.cdrom.cdr'" [Normal,Unconfirmed]  http://launchpad.net/bugs/43941
<sivang> kgoetz: do you happen to have a system without a cdrom at all you might be able to try it out on?
<dholbach> nomed: yes
<kgoetz> sivang: i can build one. testing ubuntu bugs is a saner thing then it was goin to be used for (LFS)
<nomed> hi dholbach 
<dholbach> hello
<nomed> did u still get any decision about tangerine and "tango-apps" pkge ?
<dholbach> nomed: andreasn wrote to the mailing list - i want to have the discussion over there
<nomed> dholbach, me too ..
<dholbach> nomed: and i'd be happy if you and the xubuntu guys would join in there
<nomed> i wrote a mail to the mail list ..
<nomed> i answered you
<nomed> me and andreasn discussed already this ..
<nomed> and we are fine with both solutions ..
<nomed> now i guess it depends on pkger :)
<dholbach> maybe janimo and Gloubiboulga should have a look too
* janimo reads scrollback
<dholbach> after that we should go and prepare a list of stuff that needs to be replaced
<dholbach> janimo: it's a thread on ubuntu-art about tango and tangerine
<nomed> janimo, i paste the link to the mail
<dholbach> thanks guys
<sivang> kgoetz: hmm, building one just for that? :-) no need, we better find someone to do so, maybe the original bug reporter. I don't want you to over bother you with stuff like that as you have better things to finish before :) and you're feedback has already been helpful.
<dholbach> i'll be off to my pizza and follow up on the mailing list
<janimo> dholbach: enjoy
<kgoetz> sivang: it's a bit of a novelty box (scsi gear inside), i don't use it a lot, so any use is good
<dholbach> janimo: merci
<nomed> https://lists.ubuntu.com/archives/ubuntu-art/2006-May/001247.html
* ogra throws envoius looks to janimo 
<ogra> exxample-content, eh ? 
<janimo> ogra, :)
* ogra would love to have that 10MB free :)
<janimo> some are broken since theer are no default handlers for them in xubutu
<janimo> but some are not
<janimo> ogra, I think the language support packs for the top 10 languages will fit as well
<ogra> pfft
<ogra> i'm happy if i can keep english :)
<janimo> unless I'll need to add gnome libs for some apps :(
<kgoetz> sivang: are you interested in having it tested on xfce or just Gnome?
<sivang> kgoetz: sure thing, where ever it runs :)
<kgoetz> ok :)
<kgoetz> sivang: hubackup is dapper only?
<sivang> kgoetz: targetted for it, but backporting should be fairly easy.  
<kgoetz> I'm just wondering what cd to use to install *tries to find a cdrw*
<sivang> kgoetz: well, if you can use dapper, then do, installing it on previous releases woudl require a bit of control file tweaking and a rebuild
<mjg59> fabbione: Hi
<fabbione> mjg59: hi.. 
<fabbione> mjg59: i saw you and paul giving love to i810 and via...
<fabbione> i was wondering what is the status of the 2 drivers
<fabbione> they both have quite a bunch of bugs open
<mjg59> fabbione: I don't have any modern via hardware. I just uploaded a couple of fixes
<fabbione> mjg59: ok
<mjg59> I believe that via is roughly up to date with upstream in terms of hardware support, but I haven't touched some of the other code
<Mithrandir> hmm, we seem to need a d-i upload
<zul> heylo
<kagou> hi
<kgoetz> hi
<pvanhoof> https://launchpad.net/products/network-manager/+filebug
<pvanhoof> I can't file a bug here
<pvanhoof> yet there's a packaging problem
<pvanhoof> not an upstream problem, afaik (if I look at the code0
<pvanhoof> May 10 14:59:19 localhost dhcdbd: Failed to initialise D-Bus service.
<pvanhoof> May 10 14:59:42 localhost dhcdbd: dbus_svc_init: dbus_bus_request_name failed: org.freedesktop.DBus.Error.AccessDenied Connection ":1.5" is not allowed to own the service "com.redhat.dhcp" due to security policies in the configuration file
<pvanhoof> May 10 14:59:43 localhost dhcdbd: Failed to initialise D-Bus service.
<pvanhoof> where do I submit this bug?
<pvanhoof> reboot for retry, please let me know when I' m back
<ogra> https://launchpad.net/distros/ubuntu/+source/network-manager/+filebug
<ogra> pvanhoof, ^^^
<pvanhoof> ok
<ogra> dont file against a product, file against a package in a distro ;)
<pvanhoof> ogra, you still have the paste url?
<pvanhoof> I just rebooted, forgot to keep a ptr
<ogra> which one ? 
<pvanhoof> didn't I put it here?
<pvanhoof> oh
<pvanhoof> hoping at #gnome-hackers they still have it :)
<ogra> ah, you mean https://launchpad.net/products/network-manager/+filebug ?
<pvanhoof> http://paste.ubuntu-nl.org/13751
<pvanhoof> no, that one :)
<ogra> oh, ah, a pastebot url you mean
<pvanhoof> https://launchpad.net/distros/ubuntu/+source/network-manager/+bug/44009
<Ubugtu> Malone bug 44009 in network-manager "When installing NetworkManager, things don't work" [Normal,Unconfirmed]  
<seb128> Kinnison: around?
<Kinnison> seb128: yep
<Kinnison> seb128: Just got back from lunch, what can I do for you?
<seb128> Kinnison: https://launchpad.net/bugs/43872
<Ubugtu> Malone bug 43872 in gnome-session "Logout dialog signals gdm to perform p-m actions" [Critical,Confirmed]  
<Kinnison> seb128: yep, seen it, what can I do for you?
<seb128> Kinnison: do you have some code handy than we can copy to get the capabilities from gpm?
<Kinnison> Not really
<Kinnison> give me a sec to check g-p-m's codebase
<seb128> because I don't think any of desktop team members known anything about gpm
<Kinnison> It's all dbusness
<seb128> grumpf
<seb128> gnome-session doesn't use dbus atm
<Kinnison> It's fairly easy stuff
<Kinnison> let me see if I can find a useful example for you
<seb128> thank you
<Kinnison> aha, grab the source for gpm and look at src/gpm-prefs.c
<Kinnison> the method gpm_dbus_method_bool might be helpful for you
<Kinnison> If you need more from me, just yell
<seb128> ok, thank you :)
<ogra> g-p-m should really have something like gnome-screensaver-command to circumvent dbus where needed
<infinity> Riddell: kdebase is FTBFS all over.  plsfixkthx.
<bddebian> Morning peoples
<kgoetz> hi bddebian: 
<kgoetz> ;) you cant escape
<bddebian> Hello kgoetz
<bddebian> What do I need to escape from?
<kgoetz> me ;D. (i'd be trying to escape form me)
<bddebian> Heh :-)
<kgoetz> :)
<ivoks> ogra: or not suspend computer if wget lasts longer than "Put computer to sleep..." :)
<Mithrandir> Kamion: if you can do a d-i upload when you get on top of things, that'd be wonderful.
<elmo> Kamion: how safe is ubiquity manual partitioning atm?
<elmo> (and what's a big <!> mean next to a partition?)
<Kamion> Mithrandir: ok, I thought I'd already bumped it to the new ABI
<Kamion> elmo: should be ok provided you're using at least 0.99.76
<elmo> hmm, I'm on flight-7
<Kamion> elmo: in gparted?
<elmo> yah
<Mithrandir> Kamion: at least this morning's daily was a bit bumpy due to it.
<Kamion> er, don't recall offhand, might be either currently-mounted or detected-errors
<ogra> elmo, i usually do manuall partitioning in my tests, worked reliable here the last 3 or 4 isos i tested
<Kamion> pre-0.99.76 sometimes formatted partitions despite you not telling it to
<elmo> Kamion: !
<ogra> ah, i always format them all
<elmo> and I'm using 0.99.74.  SWEET
<ogra> so this didnt happen to me yet
<Kamion> elmo: upgrade ubiquity* first
<Kamion> it'll tell you if it's going to do that in the confirmation message, mind you, it won't just do it silently
<Kamion> so not as bad as it could've been
<elmo> cute, ubiquity is stateful
<elmo> Kamion: can I flush the pending operations in gparted?
<lmanul> Kinnison: ping ?
<Kinnison> lmanul: pong
<lmanul> Hi, I'm the guy for the logout dialog :)
<Kinnison> Hello
<lmanul> Kinnison: seb128 forwarded me your advice about g-p-m and dbus
<lmanul> This works for testing whether the hardware can sleep/hibernate
* Kinnison nods
<lmanul> What about actually hibernating/sleeping ?
<Kamion> elmo: only by going forward, I think
<Kamion> we sort of ran out of space for stuff on that page
<lmanul> Kinnison: For the moment, clicking on Sleep for example runs gdm_set_logout_action (GDM_LOGOUT_ACTION_SUSPEND);
<lmanul> but this should be done through dbus/g-p-m as well, right ?
<Kinnison> lmanul: Essentially you make the suspend call over dbus and it'll suspend there and then
<ogra> lmanul, what about taking the g-p-m tray applet, ripping off the gui and adding commandline options to it for suspend/hibernate ... you could just call it as g-p-m-command --suspend then
<ogra> Kinnison, ^^
<Kinnison> ogra: It really should signal the g-p-m over dbus
<ogra> (might be easier than to have to add dbus to gnome-session)
<Kinnison> It needs it to query anyway
<tepsipakki> could libpam-krb5_1.2.0-3 be synced from debian? it fixes many bugs in 1.2.0-1 
<elmo> should ubiquity maybe disable the screensaver?
<ogra> elmo, yes, it should send pokes on a regular base to gnome-screensaver
<lmanul> Well, actually we're preparing to add dbus deps into gnome-session, yeah :)
<lmanul> Kinnison: hmm, I'm not familiar with dbus, is there a single-line function for this ?
<lmanul> (like in gpm-power.c or so ?)
<ogra> elmo, it isnt integrated with xscreensaver though
<Kinnison> lmanul: I'm just looking
<lmanul> Kinnison: Thanks a lot :)
<Kamion> elmo: it does
<Kamion> ogra: yes it is
<elmo> Kamion: doesn't seem to?
<ogra> Kamion, ah, k
<Kamion> espresso (0.99.55) dapper; urgency=low
<Kamion>   * GTK frontend:
<Kamion>     - Add support for disabling xscreensaver as well as gnome-screensaver
<Kamion>       (thanks, Daniele Favara; closes: Malone #40095).
<elmo> I just had the screensaver kick in on me while it was creating partitions
<Ubugtu> Malone bug 40095 in ubiquity "from poke_gnome_screensaver to turn_off_screensaver" [Normal,Fix released]  http://launchpad.net/bugs/40095
<lmanul> Kinnison: this is quite critical, and I'm a bit lost in the g-p-m code :)
<Kamion> elmo: hmm, never seen that, bug me
<Kamion> could be that the main ubiquity process is blocked talking to gparted at the time
<ogra> argh
<Kinnison> lmanul: right, you see the dbus_g_proxy_call
<ogra> you switched to --deactivate ? 
<Kamion> and thus can't poke g-s-
<Kamion> s
<Kinnison> lamont: if you call that with proxy,"Suspend",&error,G_TYPE_INVALID,G_TYPE_INVALID then it should work
<Kinnison> lmanul: ^^
* Kinnison kicks his fingers
<Kamion> ogra: only for xscreensaver-command which doesn't have --disable
<lmanul> Kinnison: Great ! That's all I need, thanks a lot :)
<Kinnison> lamont: sorry, bad tab completion
<Kinnison> lamont: test it obviously :-)
<Kamion> --disable was just a typo
<Kinnison> lmanul: ^^
<Kinnison> lamont: sorry
* Kinnison cries
<ogra> Kamion, it will stay deactivated if you kill ubiquity then
<Kamion> ogra: not according to the xscreensaver-command documentation
<ogra> hmm, right
<Kamion> xscreensaver-command --deactivate is equivalent to gnome-screensaver-command --poke
<elmo> Kamion: #44108
<elmo> or #44018 even, dyslexia rules ko
<ogra> bug 44108
<ogra> :P
<ogra> bug 44018
<Ubugtu> Malone bug 44018 in ubiquity "screensaver kicked in while ubiquity was creating partitions" [Normal,Unconfirmed]  http://launchpad.net/bugs/44018
<ogra> elmo, would be nice to note which screensaver daemon that was :)
<Kamion> ogra: irrelevant
<elmo> ogra: I've no idea - it's a flight 7 live CD
<Kamion> it's almost certainly a ubiquity problem
<ogra> ah,k 
<Lathiat> hey guys - has there been any discussion on putting the removable devices in side a submenu of places?
<elmo> hmm, sweet
<elmo> "Error 22" from grub
<Lathiat> grumble, RB crashes importing my music, i attach strace and it just freezes instead
<lmanul> Kinnison: can the above method work for "Halt" and "Reboot" as well ?
<Kinnison> lmanul: Erm, No, Suspend and Hibernate only
<lmanul> Kinnison: Ok, thanks
<Kinnison> Oh hang on
<Kinnison> There's 'Shutdown' too, but no Reboot
<lmanul> Shutdown ? Ok, so I guess I should handle Reboot with GDM
<Kinnison> I assume because g-p-m having a reboot action would be a bit bonkers
<elmo> Kamion: hmm, any idea about this error 22 stuff?  I assume that means the grub on /dev/hda is pointing at the wrong place?
<Treenaks> error 22, does that mean it can't find stage1.5/stage2?
<elmo> 22 : No such partition
<elmo>      This error is returned if a partition is requested in the device
<elmo>      part of a device- or full file name which isn't on the selected
<elmo>      disk.
<elmo> this is a linux laptop, I'm reinstalling with ubiquity (but with a different hard drive layout), I have a feeling it saw grub was installed and didn't reinstall it taking into account the new partition layout
<Kamion> ubiquity always tries to reinstall grub
<Kamion> it might have crashed before doing that though; crashes in install.py aren't always noticed currently, unfortunately
<Kamion> /var/log/installer/syslog should record the crash if so
<elmo> in the new root FS?
<Kamion> yes
<elmo> I don't have a /var/log/installer in there
<elmo> shall I try the install again and not reboot this time?
<Kamion> definitely crashed then, it copies the log as nearly the last thing it does
<Kamion> yes please
<Kamion> I'll try to fix it to notice install.py crashes properly
<Kamion> (been on my list for a while, there are associated bugs already)
<Kamion> Mithrandir: do you have any unpushed casper changes? I have some stuff to blat in your direction
<lmanul> Kinnison: I have a last question (sorry for bothering again) : what is this DBUS_BUS_SESSION thing ? It is not #defined anywhere in the g-p-m code ?...
<Kinnison> lmanul: it's a define from the dbus headers which indicates a connection to the session bus rather than the system bus
<lmanul> Kinnison: Ah ok, so by linking to the dbus libs it should be all right. Thanks again :)
<Kinnison> no problem
<elmo> 2:0.99+1.0pre7try2+cvs20060117-0ubuntu7
<elmo> best version number EVAR
<thom> damn, someone's beaten my firefox effort
<ogra> sounds suspicious like mplayer :)
<pitti> -revertedto... is still missing
<ogra> we're not final yet ;)
<mvo> -forrealthistime is my favorite
<ogra> that comes after -revertedto
<ogra> :)
<mvo> Version: 0.14.3+seriouslythistime-0ubuntu3
<ogra> 0.14.3+try1andtry2-seriouslythistime-damnedrevertedto0.14.2-forrealthistime-0ubuntu3 
<ogra> :)
<jsgotangco> heh
<jsgotangco> i just crack up whenever i see that bug report
<elmo> Kamion: oh, shiny
<elmo> /bin/hw-detect: line 733: /usr/lib/prebaseconfig.d/30hw-detect: No such file or directory
<mvo> ogra: haha
<ogra> you could put an -iknowisuck- anywhere as well :)
<Kamion> elmo: meh
<mvo> ogra: we have no versions with "suck" or any other swearswords I can think of 
<ogra> ah, well, it would probably violate the CoC, but if it say it about myself that might be compliant 
<ogra> but you surely would know you suck if you produce *such* version numbers :)
<Kamion> elmo: I'll fix, no need for a bug
<elmo> Kamion: ok - is there anything else I need to do to finish the install, beyond chrooting into the new root fs and installing grub properly?
<Kamion> elmo: yes, it won't yet have removed packages that don't belong on the installed system, and it won't yet have copied log files
<elmo> ah, I might just download an install CD and give that a try then
<Kamion> elmo: might be easier to edit /bin/hw-detect, change the prebaseconfig= line to prebaseconfig=/dev/null, and retry
<elmo> ah, ok
<Kamion> sorry about that, my fault while integrating hw-detect
<elmo> Kamion: no prob
<Kamion> elmo: fixed in my branch now
<elmo> Kamion: cool - seemed to work all the way through this time
<Kamion> bonus
<Riddell> Kamion: installing from yesterdays live CD I get a grub error 15 when booting, using both kde and gtk frontend
<ogra> Riddell, really ? my tests with yesterdays CD were all fine 
<Kamion> Riddell: you know where Malone is :-) I need /var/log/installer/syslog
<Kamion> if you don't have that file, then you probably ran into the same thing elmo did
<Mithrandir> Kamion: no, no unpushed casper changes.
<carlospc> Hello, i'm experiencing problems in breezy with intel 945 chipset, does anybody knows if there is any unofficial backport of 2.6.15 kernel version for breezy?
<HiddenWolf> carlospc: no there is not, and there won't be
<zul> carlospc: you might want to try dapper
<carlospc> but do you think that it can be done? i mean, take the dapper kernel and backport it to breezy, i know that it's a very hard issue and many others components has a strong dependency with the 2.6.12
<zul> no
<carlospc> well, it's not for me... it's for a Ubuntu derivate
<carlospc> (breezy, in this case)
<carlospc> Guadalinex
<carlospc> We are experiencing too many problems with this chipset
<Kamion> carlospc: it's really painfully difficult and inadvisable; the kernel<->udev interaction has changed and that requires changes in many other places
<ogra> but you'd have to backport half the world 
<HiddenWolf> udev/hotplug madness
<ogra> yeah
<Kamion> nobody's done it as far as I know, and TBH we'd probably rather they didn't, because it would complicate upgrading from whatever they produced to dapper
<Riddell> pitti: where can I find your language pack size script?
<pitti> Riddell: http://people.ubuntu.com/~pitti/bzr/langpack-o-matic/langpacksize
<Riddell> thanks
<siretart> does ubuntu dpkg do something strange wrt diversions?
<siretart> consider a diversion like this: 'diversion of /etc/conf.foo to /etc/conf.foo.distrib'. if /etc/conf.foo exists, and on installation of foo, it places a /etc/conf.foo, why does dpkg give me a conffile prompt? this does not seem to happen in debian
<Mithrandir> don't divert conffiles.
<siretart> well, fai seem to do that. and it seems to work in debian, and now their complaining that it doesn't in ubuntu
<ogra> fai
<ogra> ...
<siretart> ogra: ?
<ogra> you know i'm not a fan :)
<siretart> s/their/they're/
<siretart> ogra: I think you mentioned cfengine, but I didn't know of fai
<siretart> Mithrandir: do you think a replaces could help here?
<ogra> and, doesnt fai heavily use cfengine ? 
<Mithrandir> siretart: I think not diverting conffiles would be a good start.
<siretart> I mean the Replaces: field in debian/control
<Mithrandir> siretart: read 10.7.4 in debian policy.
* siretart looks
<Mithrandir> and no, I wouldn't use replaces.
<siretart> Mithrandir: in this case, fai-nfsroots needs to 'own' /etc/dhcp3/dhclient-script. they are therefore using dpkg-divert on that file
<Mithrandir> siretart: *shrug*; I'm telling you that it's a bad idea and won't work reliably.
<siretart> I get the idea why it is a bad idea now, and I think I'll do something very hackish in oder do fix that
<siretart> I'm wondering why it happens to work in debian, though
<ogra> siretart, a proper way would be to do it similar to ltsp and source a conf.d dir or something
<siretart> ogra: for configuring dhcp3-client?
<ogra> we check for existance of /etc/ltsp/dhcpd.conf in the dhcp server initscript
<ogra> i guess you can do similar things to dhcp-client, yes
<siretart> hm
<ogra> but not at this stage in the release :)
<siretart> right
<\sh> guys...I have a real problem :) chroot and amd64 people could help me :)
<\sh> i386 boot kernel, amd64 chroot (including amd64 kernel installed now how do i get the "real architechture" and not the kernel uname output? 
<Kamion> linux32 chroot /blah
<Kamion> oh, er, booting an i386 kernel and chrooting *into* an amd64 system? that won't work at all, I assume you mean the other way round
<\sh> Kamion: no..it works :) I only need to know the real architecture (amd64) 
<\sh> Kamion: and not the kernel uname
<Kamion> AFAIK there is no way to run 64-bit binaries when running an i386 kernel
<ogra> you could try dpkg --print-architecture in the chroot ... dunno if that reports amd64 but i'd suspect to
<ogra> which still doesnt mean you can run the binaries, Kamion is right 
<\sh> ogra: and that's the problem :) the chroot != debian 
<mjg59> \sh: How is the shell supposed to run on a 32-bit kernel?
<Kamion> I think you must be mistaken about either your kernel or the chroot
<\sh> oh I'm doomed
<\sh> my colleague provided me really with the wrong chroot
<\sh> *censored* all work is useless....:(
<seb128> Kinnison: is there an easy way to know from my desktop without coding if sleep and hibernate are supported by the box?
<bddebian> xsim's build env is a piece of *censored* :)
<seb128> Kinnison: to know if the gnome-session patch is doing the right thing
<Kinnison> seb128: click on the g-p-m icon and see what's offered?
<seb128> Kinnison: I don't have an icon, but I'm on a desktop ...
<ogra> wasnt there a hal method ? is that already in our hal =
<ogra> ?
<Kinnison> seb128: Open power preferences, choose "always dispay icon" and then click on it
<seb128> Kinnison: great, thank you
* seb128 hugs Kinnison
<Kinnison> No problem
* Kinnison hugs seb
<seb128> sorry for the stupid questions, but I'm new to that g-p-m and I'm busy enough to not want to spend hours on it if not required :)
<Kinnison> dholbach: Looks like I'll be in Paris as a soyuz representative
<Kinnison> seb128: that's okay, I'm happy to help
<kgoetz> i was wondering if the update tool (Breezy-> dapper) was going to remove backports from peoples lists before trying to upgrade? it occurred to me it might not be a healthy thing for the upgrade for them to be in place.
<Kinnison> seb128: I'm sure I've asked my fair share of stupid questions in the past :-)
<seb128> hehe
<thom> Kinnison: does that mean you have to spend the entire time in a space suit?
* dholbach high-fives Kinnison
<Kinnison> thom: No, in a vomit chair
* Kinnison hugs dholbach 
* ogra hugs Kinnison 
<ogra> yippie :)
<Kamion> Mithrandir: you sure you have no unpushed changes? I see "casper (1.50) UNRELEASED", but casper 1.50 is in the archive
<Kamion> Mithrandir: .bzr/parent is http://people.ubuntu.com/~tfheen/bzr/casper/trunk
<Kamion> perhaps uncommitted changes
<BenC> dholbach: ping
<dholbach> BenC: pong
<BenC> dholbach: you were helping me with my ppc/evo crash, right?
<dholbach> i tried :)
<BenC> I've got it narrowed down to a single email with a single line change in the email to reproduce it
<dholbach> oh?
<dholbach> which one is that?
<BenC> it's a message marked as spam
<BenC> I have a filter for X-Spam-Status: yes match, and if I add/remove that line in _this_ email, it crashes/doesn't crash (it crashes when the line is present)
<dholbach> urg
<BenC> it's odd because a lot of messages have this line, but it's something with this complete message
<dholbach> can you send me both?
<BenC> sure
<dholbach> I'll talk to the guys in #evolution and show them.
<BenC> sent
<dholbach> thanks
<Mithrandir> Kamion: hmm, then I do, but none apart from that.  I'll find my laptop and push.
<BenC> dholbach: I'm installing the dbg stuff again, and source so I can try to do something about this...it's really cramped my workflow :)
<Mithrandir> Kamion: ok, I was lying.  Pushed.
<dholbach> BenC: you forwarded them to me? or bounced them?
<dholbach> BenC: I got the same spam message two times - maybe that's the one
<BenC> forwarded
<dholbach> ok
<dholbach> BenC: so just to understand you right: once you remove "X-Spam-Status: yes" it works for you on ppc again?
<BenC> yes
<dholbach> ok
<BenC> my test involved deleting the email completely from evo, editing that file, importing it, and running the "Apply Filters" command on it
<BenC> just to make sure there wasn't any cache issues or such
<dholbach> BenC: I forwarded the issue to gnome bug 341282 and pinged the upstream guys about it
<Ubugtu> Gnome bug 341282 in Mailer "PowerPC crash on filtering X-Spam-Status" [Normal,Unconfirmed]  http://bugzilla.gnome.org/show_bug.cgi?id=341282
<BenC> dholbach: it's actually crashing in camel_utf8_getc(), FYI
<BenC> called from line 430 in camel_search_header_match()
<BenC> specifically, line 60 in camel_utf8_getc()
<BenC> r = *p++;
<dholbach> BenC: thanks for looking into that - you're not even scared of evolution code! :-)
<BenC> I used to work on glibc, nothing scares me any more :)
<dholbach> Looks like it, yeah :-)
* dholbach hugs BenC
<Keybuk> bah, glibc is easy
<bddebian> BenC: :-)
<bddebian> glibc is easy?
* bddebian is definetly in the wrong crowd
<zul> BenC: you arent afraid of clowns?
<Diziet> glibc is mad but at least you know what it's supposed to do.
<BenC> glibc is only crazy because of the mounds of versioned symbols that have grown into it
<Keybuk> like Ian says, if you're ever in doubt about glibc, just pick up the C standard and you know what you're doing
<Keybuk> and in general, the routines are small and simple
<BenC> sometimes you never know if you are fixing the right function, even though it's named the same thing
<Keybuk> BenC: yay compatibility
<azeem> its build system is scary though, but maybe that is because it was written by the gmake author
<BenC> but yeah, the end result is easy to find :)
<bddebian> I'd like to re-do the glibc stuff for Hurd but it scares the crap out of me :-)
<BenC> probably the scariest thing about glibc is Uli :)
<ogra> thats a function ? 
<BenC> yeah, but you're never sure what data to pass to it, or what it will return
<ogra> heh
<azeem> bddebian: well, the Hurd specific parts *are* scary
<bddebian> azeem: Aye :-)
<BenC> printf(Uli("Cool patch that fixes things"));
<bddebian> Plus, you know my current skillset :-(
<BenC> "You are a dumb ass"
<bddebian> hehe
<bddebian> Thanks BenC.  How'd you know? :-)
<BenC> hehe
<BenC> dholbach: this camel_utf8_getc() function is super loaded with compiler optimizations, I'm wondering if it is getting miscompiled
<BenC> I'm going to try dumbing it down and see if that fixes it
<BenC> hmm...74 packags for evo-data-server build-deps...screw it, it's in the name of bug fixing
<lamont> Kinnison: manual dyslexia issues, eh?
<Kinnison> lamont: aye, lam<TAB> rather than lma<TAB>
<pitti> mdz: can you please take a look at https://launchpad.net/distros/ubuntu/+source/ipsec-tools/+bug/40386 ?
<Ubugtu> Malone bug 40386 in ipsec-tools "Please upgrade to 0.6.5" [Normal,Fix committed]  
<lamont> Kinnison: I do admit to frequently doing <letter><letter><TAB>
* Kinnison nods
<mdz> pitti: can you email me?  in the middle of a meeting and 3 conversations atm
<pitti> mdz: Sure
<nomed> dholbach, there is a new path commited in icon-naming-utils cvs ..
<nomed> that'll add support for xfce, dobey told me that he'll not release yet a new version
<dholbach> nomed: if it's terribly urgent we should have a bug about that
<nomed> dholbach, it's terribly urgent 
<dholbach> nomed: please file a bug and point to the change
<dholbach> nomed: it makes more sense to have the info in one place
<angystardust> Hi guys!
<angystardust> BenC: what about the state of sky2 module? It needs much much love
<angystardust> there are about 10 open bugs in malone (maybe dups)
<BenC> angystardust: malone says that I commited an update yesterday to sky2
<BenC> if there are any dupes, please merge them to the report that I set at "Fix Committed"
<Tonio_> pitti: ping ?
<pitti> hi Tonio_ 
<nomed> dholbach, bug #44053 done
<Ubugtu> Malone bug 44053 in icon-naming-utils "legacy-icon-mapping.xml: Add some links for XFCE" [Critical,Unconfirmed]  http://launchpad.net/bugs/44053
<Tonio_> pitti: hey :)
<dholbach> nomed: thanks
<Tonio_> pitti: we have a little issue with language-packs in kde
<Tonio_> pitti: several languages are still 50% english, since there was a problem with kdelibs 2 weeks ago
<Tonio_> pitti: when are new languages packs planned for ?
<Tonio_> pitti: Riddell confirmed me new languages-packs would resolve the issue
<angystardust> BenC: ok i'll do that...but i'm not sure that the patches you merged will fix up things
<BenC> angystardust: If 2.6.16 works, then the patches I applied should work
<BenC> angystardust: if 2.6.16 doesn't work, then there's not much I can do
<pitti> Tonio_: yep, I'll build new ones for dapper soon
<pitti> Tonio_: this week still, in any case
<Tonio_> pitti: nice, that would help finding issues in translations :)
<Tonio_> pitti: thanks
<angystardust> BenC: many users report that 2.6.16 and even 2.6.17-rc3 don't work
<BenC> angystardust: then I'm not sure I can do anything to fix the problem
<pitti> carlos: what do you think about new langpacks tomorrow or Friday? any chance for further convergence?
<carlos> pitti: Friday would be better
<carlos> I need to do a new review that will be fixed between today and tomorrow
<pitti> carlos: great, so it shall be Friday then :)
<carlos> yeah ;-)
<angystardust> BenC: if it doesn't take a lot of stress, you can sync with Stephen Shemminger's netdev git tree which include some important patches 
<secondhand_budda> Hi. can anyone help me with a small edubuntu dapper mysql problem? 
<HiddenWolf> secondhand_budda: ask in #ubuntu or #edubuntu
<BenC> angystardust: last I looked at that version it did not compile in our tree without major backporting of other unrelated patches
<BenC> I'd have to recheck that
<secondhand_budda> I was referred here - to speak to infinity by ogra, but infinity's away...
<angystardust> <a href="http://mail-archive.com/netdev%40vger.kernel.org/msg12133.html">http://mail-archive.com/netdev%40vger.kernel.org/msg12133.html</a>
<ogra> secondhand_budda, he's in .au, he might be sleeping
<secondhand_budda> probably :)
<angystardust> it's stricly related to #38865
<secondhand_budda> ok will try later thx
<angystardust> there are too many laptops around which have that (damned) ethernet controller
<angystardust> BenC: thank you
<BenC> dholbach: Kick ass!
<BenC> dholbach: Removing the inline/register constructs for that function stopped the crash
<BenC> dholbach: I think this can be blamed squarely on gcc
<dholbach> oh - WOW!
* enyc waves at BenC
<dholbach> BenC: Can you show what you changed?
<BenC> dholbach: I'll send you a patch that should be included for dapper until we can get gcc fixed in edgy
<BenC> will only affect ppc
<dholbach> WOW
* dholbach hugs BenC!
* desrt smiles at dholbach's enthusiasm
* sivang joys at kernel bug squashing
<angystardust> j
<desrt> ?
<mxpxpod> BenC: with the sync to git for bcm43xx, does it now work with wpasupplicant?
<desrt> mxpxpod; it's been working fantastic for me solid
<mxpxpod> desrt: so, n-m works?
<BenC> mxpxpod: it now doesn't work for me at all
<BenC> current -22 should work
<mxpxpod> sweet
<mxpxpod> I'll have to try it tonight
<mxpxpod> and just in time for dojo developer day this weekend :)
<BenC> dholbach: I'm going to file this as a critical bug on evo-d-s and attach the patch, to make sure it gets into dapper
<BenC> hmm, this may be the first bug I've ever filed in launchpad/malone
<dholbach> BenC: cool - assign it to me and I'll look at it
<HiddenWolf> BenC: well, nobody will complain, just close more than you open, ok? ;)
<bddebian> hehe
<BenC> dholbach: bug #44061
<Ubugtu> Malone bug 44061 in evolution-data-server "Crash in camel on PowerPC, gcc regression" [Critical,Confirmed]  http://launchpad.net/bugs/44061
<dholbach> BenC: cool - thanks! I'll apply it and hope to hear back from ppc people - I'll attach it upstream in any way
<BenC> might want to alert doko
* BenC happily uses evo on his ppc again
<HiddenWolf> since when do people happily use evo?
<sivang> HiddenWolf: heh, they have just leanred to cope with it :)
<Treenaks> HiddenWolf: in a masochistic kind of way
<BenC> HiddenWolf: since I don't have to use it over ssh -X :)
<HiddenWolf> BenC: laughing out loud
<Treenaks> BenC: ah, you look at it from the Lourdes-perspective: There's always someone who has it worse than me
<sivang> BenC: that explains your joy :)(
<HiddenWolf> BenC: does evo even cope with the amount of mail you get?
<BenC> HiddenWolf: mostly
<HiddenWolf> BenC: I had time to go to the bathroom when it processed my 20-odd new mails just now...
<BenC> it's me that has a hard time coping with it
<BenC> HiddenWolf: odd, doesn't take that long for me
<mdke> was it a number two or a number one?
<Treenaks> HiddenWolf: I get hundreds of mails a day using evo. no problems for me..
<mdke> perhaps that is an inappropriate question
<HiddenWolf> mdke:  ;)
<HiddenWolf> Treenaks: I guess it's choking on one of my filters or something.
<mdke> works fine here too. except threading, which is ballsed up
<BenC> threading seems to be doing fine for me
<BenC> much better than it used to be
<desrt> BenC; have there been changes to the io scheduler between dapper and breezy?
<BenC> desrt: depends, I think -server is using a different io scheduler
<desrt> BenC; the latency of small io requests while big sequential operations are occuring has gone through the roof
<mdke> BenC: I've got thread problems. I can't expand and collapse using keyboard shortcuts, collapse all threads doesn't work, and it doesn't focus on the thread when I expand it
<BenC> all of them are enabled, so you can choose with a boot option
<desrt> BenC; desktop.  i've tried antic and cfq.
<BenC> desrt: perhaps it's more to do with preempt and/or HZ=1000
<desrt> BenC; like if i'm copying a big file between two drives then typing ':wq' in vi with a small file open is a 15 second affair
<tseng> isnt there a sysctl for the scheduler now
<tseng> trying to figure what -server has
<desrt> tseng; deadline, i think
<BenC> desrt: odd, I haven't noticed that, but I have heard something similar from one other person
<tseng> desrt: good, thats what i do manually anyway
<thom> meh? really
<desrt> tseng; and you change the scheduler on a per-device basis with a /sys/block/___/ file
<desrt> it's queue/scheduler or something
<tseng> oh yeah
<thom> deadline's fine for webservers, but anything else really ought to be CFQ IME
<BenC> desrt: could just be the driver for your disk
<desrt> BenC; hum.
<desrt> i wonder if maybe it's submitting an excessive amount of tagged requests
<tseng> $ cat /sys/block/sda/queue/scheduler 
<tseng> noop [anticipatory]  deadline cfq 
<tseng> the default is AS
<tseng> for everyone it seems
<desrt> deadline on -server, i think
<tseng> that was -server
<desrt> anyway... bear with me here
<BenC> I thought fabio has changed the -server scheduler
<desrt> if the disk driver had like 100 tagged io requests issued it would take a long time for them to come back
<desrt> and they'd all have to come back before the drive started servicing the small task for the other process
<BenC> desrt: yeah, the queue could just be too damned big
<desrt> and nothing the io scheduler could do would change that
<desrt> or maybe the drive has its own elevator built in and is trying to group the similar requests too agressively
<desrt> hmm!  lots to think about
<desrt> i'm using ata_piix on an ICH5 mainboard, btw
<desrt> with western digital 16MB cache drives
<desrt> two of these -- WD2500JD-00H
<BenC> were you using ata_piix in breezy?
<desrt> ya.  i'd imagine so
<Kamion> BenC: uli> yeah, I still remember the glibc bug I filed that was exposed by something in tar, which he blew off on the basis that if it were a problem the tar maintainer would have told him about it
<desrt> ICH5 doesn't support AHCI
<Kamion> BenC: so Paul forwarded my mail back to Uli as a bug report, and he fixed it then ;-)
<BenC> Kamion: sounds all too familiar :)
<desrt> heh
<desrt> desrt@moonpix:~$ dd if=/dev/zero of=big bs=1G count=4
<desrt> with this running vi locks up
<desrt> 100% reproduceable for like 15-30 seconds
<desrt> music playing is quite fine though
<zyga> hey everyone
<zyga> I've found a pecuilar USB flash disk that doesn't work under linux
<Keybuk> zyga: sudo udevmonitor -e, plug it in, paste the modalias line
<zyga> any hints on where to give the information about it?
<zyga> Keybuk: ay
<bddebian> Malone?
<zyga> Keybuk: the strange thing about that device it that it appears to be two USB devices
<desrt> BenC; any chance at all this could be caused by having no swap?
<Keybuk> ok, pastebin me the entire output of that command then
<zyga> MODALIAS=usb:v13FEp1A21d0100dc00dsc00dp00ic08isc06ip50
<zyga> MODALIAS=usb:v13FEp1A21d0100dc00dsc00dp00ic08isc06ip50
<zyga> the modalias line was there twice
<BenC> desrt: very very likely
<zyga> udev sees the stick and assigns two devices sda and sdb
<desrt> BenC; that's odd....
<zyga> both fail with 'no medium' on any operation
<BenC> BenC; From what I hear, swap is almost a requirement, even on large mem systems
<BenC> s/BenC/desrt/
<desrt> hmm.
<desrt> ok.  lemme try making some.
<zyga> the thing worked on windows, also two devices, one has a small partition with some exe file, other had 99% of disk capacity
<Keybuk> zyga: likely a kernel bug then
<desrt> BenC; no improvement
<zyga> I'll file at malone
<Keybuk> zyga: attach both the entire udevmonitor output and /var/log/dmesg
<zyga> okay
<desrt> oo.  having swap makes my music skip, though :)
<BenC> desrt: maybe not, I can reproduce it here on my ppc
<desrt> oh man.  i gotta reboot
* desrt just rm'd his swap file :)
<desrt> swapoff needs a 'turn off all swap' option :p
<Keybuk> swapoff -a
<Keybuk> ?
<zyga> bah
<zyga> does launchpad have a hidden kernel product somewhere?
<zyga> I cannot find anything sensible to file a bug at
<Keybuk> http://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+filebug
<zyga> thanks
<desrt> Keybuk; that just disables all the swap listed in the fstab
<desrt> Keybuk; and it doesn't work if the filename listed there no longer exists on the fs
<Keybuk> it says it disables all swaps listed in /proc/swaps
<desrt> hmm.  it didn't work, in any case
<desrt> it would still need access to the file that i unlinked from the directory tree
<desrt> no way to take the name in /proc/swaps and turn it into a device:inode pair
<Kamion> Mithrandir: please merge/upload http://people.ubuntu.com/~cjwatson/bzr/casper/ubiquity/
<zyga> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/44072
<Ubugtu> Malone bug 44072 in linux-source-2.6.15 "USB storage device is detected as two separate devices" [Normal,Unconfirmed]  
<zyga> done, thanks
<Kamion> Mithrandir: fixes debconf memory use and one-and-a-half ubiquity bug
<Kamion> s
<desrt> benc; https://launchpad.net/bugs/43484 btw
<Ubugtu> Malone bug 43484 in linux-source-2.6.15 "poor disk performance during heavy io" [Normal,Unconfirmed]  
<BenC> desrt: thanks
<andrei> Is asking a SoC-related question offtopic?
<_ion> Is asking about asking a SoC-related question offtopic?
<bddebian> Is lyx broken, replaced etc?
<LaserJock> bddebian: it shouldn't be
<desrt> _ion; are you an applicant?
<_ion> desrt: No.
<desrt> then probably not :)
<bddebian> LaserJock: Well as I said, there is no lyx in lyx
<andrei> desrt, I am 
<mdz> mvo: any luck with my update-notifier problem?  am I the only one affected?
<zyga> that device makes the kernel unstable 
<mvo> mdz: it seems to be, at least I don't have any more reports about this particular one yet. but I havent looked at your latest debug info closely yet 
<zyga> hey mvo
<mvo> hello zyga
<zyga> any bug you need to get confirmed? :)
<mvo> how is it going?
<zyga> good
<mvo> zyga: bugs that affect mdz are the worst ;) - this particular problem is about update-notifer not remembering about already seen notifications and showing them offer and over again
<zyga> we're fixing our new house
<zyga> it'll take lots of lots of money :/
<zyga> it was in worse condition than we orignally thought
<zyga> mvo: maybe permissions problem?
<zyga> .update-notifier owned by root?
<_ion> mvo: I posted some patches to bug #31433
<Ubugtu> Malone bug 31433 in notification-daemon "notify bubble has text across screens" [Normal,Confirmed]  http://launchpad.net/bugs/31433
<mvo> _ion: thanks, I have a look
<mvo> zyga: how is your wife/gf doing?
<zyga> fine, thanks :)
<zyga> she's looking after the building process
<zyga> I keep being at work alot :/
<zyga> on the bright side we bought 300m of cat5e cable today :)
<zyga> we'll have a possibility to make the house our way :)
* Kinnison heads off for the night, ciau
<mvo> zyga: heh .) 
<zyga> oh
<zyga> do you want a free itanium 1 daughterboard for dual CPUs?
<zyga> I accidentally got an item off ebay that I don't need (I want itanium 2 mobo)
<zyga> shipping to poland is way more pricey than shipping to de (especially from de)
<zyga> I'll save money by giving it to you :)
<zyga> mvo: ?
<mvo> zyga: sorry, phonecall
<zyga> k
<mvo> zyga: not sure I can make something with it, maybe someone in the community can? but thanks for that great offer .)
<zyga> anyway, anyone from de that could use it can get it for free
<zyga> http://cgi.ebay.pl/ws/eBayISAPI.dll?ViewItem&item=6876062120&rd=1&sspagename=STRK%3AMEWN%3AIT&rd=1 
<zyga> free for all :)
<Mithrandir> Kamion: thanks, willdo.
<doko> BenC: about 44061, could you check wuth gcc-4.1?
<dholbach> apropos 44061, gnome bug 341282 just got a comment from one of the upstream guys
<Ubugtu> Gnome bug 341282 in Mailer "PowerPC crash on filtering X-Spam-Status" [Critical,Unconfirmed]  http://bugzilla.gnome.org/show_bug.cgi?id=341282
<ogra> what did he write ? "get an intel mac" ?
<thesaltydog> #ubuntu-motu
<Evaso2> Hi guys there is a gui way for configure pptp in ubuntu? Because actually: n-m in ubuntu doesn't has vpn plugins packages and kvpnc version in ubuntu is quite buggy 
<Evaso2> (dapper)
<mjr> anyone know off the top of their head where to stick extra commands to be run at boot on the Live CD image? /etc/init.d/bootmisc.sh didn't cut it
<_ion> Just guessing, but would /etc/rc.local do it?
<mjr> No such thing. I think the init stuff is done outside the actual root, mayhaps
<Keybuk> which Live CD?
<Keybuk> the current Live CD definitely has /etc/rc.local
<mjr> breezy
<desrt> mjr; just make a new initscript and tie it into /etc/rcS.d or rc2.d
<desrt> mjr; depending on where exactly you'd like it to run
<mjr> well, bootmisc.sh _is_ run through rcS.d
<jcole> with flashplugin-nonfree crapping out in both sarge and dapper, has anyone considered adding gnash as an alternative?
<mjr> but well, perhaps only rc2 stuff is done out of the main root
<mjr> (just guessing)
<jcole> on top of it, macromedia not wanting to release an 8 version for linux
<mdke> jcole: works here
<jcole> gnash is supposed to be flashplugin-nonfree 7 compliant
<mdke> i mean, flashplugin-nonfree works here
<jcole> mdke: sound doesn't work for me... do you have version 8?
<jcole> mdke: i've got bug 29760
<Ubugtu> Malone bug 29760 in flash-player "Sound does not work properly in Flash in firefox" [Normal,Confirmed]  http://launchpad.net/bugs/29760
<mdke> jcole: I wouldn't notice the absence of sound
<jcole> mdke: videos are being done via flash on the net these days
<jcole> mdke: google video for one does all their stuff flash video
<jcole> mdke: now websites are requiring version 8
<_ion> I never open the flash versions at google video, i always download the original files. The quality is better.
<mdke> jcole: i don't use google video once, but the totem plugin has always worked
<mdke> s/once/much
<jcole> mdke: that's an example
<mdke> well, you said "all their stuff"
<jcole> mdke: my corporate videos are done via flash 8 video
<Keybuk> every time I close 10 bugs, I like to think I've got us 1% of the way towards fixing them all
<jcole> mdke: which i also cannot access
<Keybuk> it's the only way I stay sane
<Keybuk> :p
<thom> Keybuk: "stay"
<jcole> mdke: i installed firefox 1.5 in wine with flash 8 to be able to watch them
<Keybuk> uh 0.1% even
<mdke> Keybuk: :) isn't it 0.1%
* mdke nods, watches Keybug go insane
<Keybuk> thom: I'm dealing with the nm bug list right now
<Keybuk> so I blame you entirely
<thom> heh, thought you might
<jcole> macromedia just released a version 9 of flash, still no linux version
<jcole> "linux users don't understand the complexities involved in porting flashplayer 8 to linux"
* thom grumbles at the ancient sqlobject in dapper
<Keybuk> they've still never released a non-i386 Linux version either
<jcole> Keybuk: ya, flash is probably written in assembly
<mjr> the complexities probably have something to do with the DRM Flash 8 sports
<zyga> hmm
<jcole> Keybuk: that's my guess... but they do have a ppc version
<zyga> flash is ported to a wide array of arches
<zyga> just properiarity and non-free ports
<crimsun> thom: does 0.7.0-1 from Sid resolve critical bugs?
<zyga> I've got one at work even :P
<jcole> zyga: no 64 bit either
<jcole> gnash looks pretty promising
<Keybuk> jcole: doubt it
<Keybuk> more likely it's just bad MFC C++
<zyga> jcole: I'm pretty sure that the code we have could work on 64bits
<zyga> I don't know if it's from macromedia though
<thom> crimsun: nah, just features. and i imagine the launchpad folk would have collective heart failure if we changed it on them this late in dapper
<crimsun> thom: ok.
<dholbach> ok fellas, I'm off for tonight
<Keybuk> I thought Launchpad used custom sqlobject code anyway
<thom> dholbach: night mate
<Keybuk> and had a complete copy of it in its source
<thom> Keybuk: *shrug* wouldn't surprise me
<Kamion> hmm, I think this is the first time I've actually used sed's h and x commands
<dholbach> thom: night thom - I miss London's record shops already :)
* Kamion tends to resort to bigger languages once he starts needing those
<thom> dholbach: heh, unsurprising :-)
<dholbach> thom: I just can't seem to find the stuff I need in Berlin and in Online shops :)
<dholbach> thom: oh well - I'll come back soon enough, I guess ;)(
<dholbach> see you!
<thom> dholbach: tried www.juno.co.uk?
<thom> see ya mate
<dholbach> *bookmark*
* dholbach hugs thom
<doko> mvo: ping
<mvo> doko: pong
* zyga could ask again
<zyga> anyone from .de want a free itanium mobo part?
<sladen> zyga: I don't know how useful just the daughtboard would be;  you might be better ebaying it, or emailing the debian hardware recycling project
<zyga> sladen: I just ebay'ed it in :)
<zyga> hmm
<zyga> I'll google the latter
<sladen> zyga: http://www.debian.org/donations#equipment_donations
<zyga> thanks
<sfllaw> Does Ubuntu not use modules.conf any more?
<Keybuk> sfllaw: not in aaaaaaaages
<sfllaw> I'm old, aren't I?
<Keybuk> in fact
<sfllaw> What's the substitute?
<Keybuk> I'm probably correct in saying Ubuntu has *never* used modules.conf
<Keybuk> as that's a configuration file for modutils
<Keybuk> which is the toolset for 2.4 kernel
<Keybuk> :p
<Keybuk> files in /etc/modprobe.d
<Keybuk> though I should probably ask why you're interested, as much of the use for modules.conf isn't covered by that
<Keybuk> e.g. "adding a char-major-blah to auto-load a module when the device is touched" is bogus, and should be rethought as "the module wasn't loaded automatically in the first place"
<sfllaw> The simple case of finding out which arguments are attached to a module being loaded.
<Keybuk> ah right
<sfllaw> modprobe.d files specify default args, right?
<Keybuk> then yes, files in /etc/modprobe.d
<sfllaw> Brilliant.
<Keybuk> generally speaking, if the bug is asking for one of those to always exist, then I actually go and fix the damned driver
<Keybuk> the only few cases where I haven't are usually because it was "too hard"
<sfllaw> Bug #43738
<Ubugtu> Malone bug 43738 in linux-source-2.6.15 "No sound" [Normal,Needs info]  http://launchpad.net/bugs/43738
<sfllaw> It's suspicious because snd claims that it's being passed an Unknown parameter 'device_mode'
<Keybuk> aye, makes it sound like he has "options snd device_mode=" in /etc/modprobe.conf or /etc/modprobe.d/*
<Keybuk> usually a good trick is to ask for:
<Keybuk> modprobe -n -v --first-time snd
<Keybuk> or whatever he tried to prove
<Keybuk> that will show you the options passed to insmod :)
<sfllaw> Ah.
<sfllaw> Well, that says "Module snd already in kernel." on my box...
<Keybuk> it would :)
<sfllaw> But I suppose since he can't load it.
<Keybuk> on his, it won't
<sfllaw> :)
<sfllaw> He could also have something in /boot/grub/menu.lst, eh?
<Keybuk> not sure, I have a vague remembering that kernel command-line options aren't relevant for modules
<sfllaw> Hmm.
<Keybuk> I remember Ben compiling something ide-related into the kernel to get it to recognise the common command-line option
<Keybuk> (it was expecting it as a module parameter otherwise)
<Keybuk> heh @ bug 41134
<Ubugtu> Malone bug 41134 in network-manager "Does not store WPA-Enterprise password in keyring" [Unknown,Unknown]  http://launchpad.net/bugs/41134
<Keybuk> dieman: do you think you could avoid your VACATION AUTO-RESPONDER from doing that <g>
<sfllaw> Heh.
<sfllaw> Keybuk: Thanks.
<Keybuk> woo, I have NM bugs down from 90 to just 35
<Keybuk> 0.3% !
<bddebian> w00t
<thom> Keybuk: resolving things at random is cheating ;-)
<Keybuk> thom: I'm not, I've actually been doing it properly
<Keybuk> and filing upstream too
<zul> later
<Keybuk> man, I'd forgotten how hard extracting patches from CVS was
<thom> you may diss having global revisions in svn, but it's so much better than the alternative
<Keybuk> I think I prefer the bzr method
<Keybuk> global revision per branch
<Keybuk> without SVN's "lump everything in one repository"
<Keybuk> cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome rdiff -u -D "Thu Apr 20 20:39:50 2006 UTC" -D "Thu Apr 20 20:49:50 2006 UTC" NetworkManager
<Keybuk> ^ that's just wrong
<sfllaw> Keybuk: I used to use cvsps.
<sfllaw> Keybuk: You may find it less painful.
<sfllaw> Albeit awfully slow.
<thom> Keybuk: nod (to prefering bzr)
<mjg59> Mithrandir: How do I kill framebuffer in the livecd startup?
<mjg59> Oh, I need to drop it from usplash as well
<Mithrandir> mjg59: remove splash from the command line?
<mjg59> Mithrandir: Doesn't seem to be adequate
<Mithrandir> mjg59: casper doesn't touch the framebuffer, iirc.
<mjg59> Ok, let me try that again
<Keybuk> well, blow me, it actually builds
* Keybuk uploads it
<highvoltage> sfllaw: ping
<mjg59> Mithrandir: Something seems to load it even if I don't pass splash
<Keybuk> which framebuffer driver?
<Keybuk> they should be all blacklisted
<Keybuk> unless a new one has snuck in
<mjg59> vga16
<sfllaw> highvoltage: Pong.
<mjg59> So it's not udev
<Keybuk> hmm, no such module :)
<mjg59> Keybuk: The module is vga16fb
<mjg59> It's autoloaded by usplash
<sladen> vga16fb
<highvoltage> sfllaw: hi there. remember to create the LP dial-up team, following last night's TB discussion ;)
<Keybuk> right
<mjg59> But seemingly also by something else, unless usplash is b0rked
<sfllaw> highvoltage: It's on my todo list.
<sfllaw> Near the top.
<highvoltage> sfllaw: great. goodnight!
<sfllaw> Because the list is getting mighty long.
<sfllaw> highvoltage: Night!
<Mithrandir> mjg59: weird; I'm fairly sure casper doesn't touch the framebuffer.
<mjg59> Mithrandir: Hm
<highvoltage> mine is quite long too, but i have an entry that says 'bug sfllaw about lp team' :)
<Mithrandir> mjg59: I can't find "framebuffer" or "vga" in the entire source tree.
<sfllaw> highvoltage: Sweet!
<highvoltage> :p
<mjg59> Mithrandir: Right
<carlos> pitti: hi, around?
<pitti> carlos: should I better run fast?
* Kamion boggles at "PC Answers" having a five-page feature on Ubuntu
<Kamion> PCA is a UK magazine, last I checked with a strong Windows bias
<Kamion> although one of the better Windows mags
<Kamion> feature> and shipping breezy on their cover DVD
<carlos> pitti: https://wiki.ubuntu.com/MissingPotFiles
<carlos> pitti: I updated it
<carlos> pitti: there you have a list of domains I don't know where they come
<carlos> pitti: others that you have and you should not have in your packages
<mdke> Znarl: thanks for the wiki! does henrik have access to the wiki theme stuff too, as well as the static webspace? We need to do some theme and config tweaking
<pitti> carlos: ah, nice
<carlos> pitti: and the list from Riddell should also be ignored
<pitti> carlos: the ones assigned to you are pending review in Rosetta, and are fine in the packages?
<carlos> pitti: there I have also the list of translations domains that I need either import manually or check if should not be on language packs
<pitti> tseng: beagle is pending upload; does it need an UVF exception approval or so?
<carlos> pitti: tomorrow export should have all translation domains fixed except for the ones I listed on the wiki
<pitti> carlos: ok, I'll take a look at the list tomorrow and sort out some bogus ones ('test' is a good candidate)
<carlos> pitti: cool, thanks
<carlos> I will try to have all domains sorted tomorrow to get a full export on Friday, or at least most of them
<carlos> night !!
<mjg59> Mithrandir: Oh, damn, I know what's up. It'll be starting imacfb.
<Runix>  i need help
<Runix>  i must to delete from menu item "recent document"
<mdke> Runix: #ubuntu
<Runix> i did
<mdke> Runix: that's the best we can do, for irc, I'm afraid
<mdke> keep trying
<mdke> otherwise, forums/mailing lists might help
<Runix> i don't speak english very well
<mdke> Runix: what's your language?
<Runix> i'm italia
<mdke> Runix: prova #ubuntu-it
<Runix> italian people not intelligent
<Runix> they like to joke
<Runix> not to help
<mdke> I'll help you, let's move there
<Runix> if i write
<Runix>  i must to delete from menu item "recent document"
<Runix> they reply 
<Runix> use xfce
<mdke> Runix: let's talk in private message
<Runix> i did
<mdke> Runix: with me?
<Runix> yes
<mdke> are you registered?
<Runix> (0.02.22) Runix: si
<Runix> (0.02.38) Runix: ho provato
<Runix> (0.02.46) Runix: ma tutte risposte a cazzo
<Runix> (0.03.05) Runix: se dico come togliere la voce documenti recenti da gnome
<Runix> (0.03.12) Runix: mi dicono prova xfce
<Runix> (0.03.15) Runix: oppre
<Runix> (0.03.28) Runix: clicca su elimina file recenti
<Runix> i'm not
<mdke> omg. Runix, join #ubuntu-it and we'll talk. Enough here.
<Runix> i did
<Runix> they don't help me
<crimsun> pitti: if you're willing and have time, I've spun two trivial alsa* bugfix debdiffs. One is at http://sh.nu/~crimsun/alsa-lib_1.0.10-2ubuntu4.debdiff, and the other is attached to bug 31784.
<Ubugtu> Malone bug 31784 in alsa-utils "'VIA DXS' elements must be unmuted by default for audible volume on newer Via hardware" [Normal,In progress]  http://launchpad.net/bugs/31784
#ubuntu-devel 2006-05-16
<mdke> Runix: join it *again* and *I* will talk to you
<Runix> ok
<Runix> i understand now
<zul> heylo
<mjg59> crimsun: You saw the bug about vanishing mute LEDs?
<crimsun> mjg59: a new one? No.
<mjg59> crimsun: I Cc:ed you earlier
<crimsun> gah, pulling up MUA now
<mjg59> Looks like a subvendor id that we had locally but never went upstream
<crimsun> mjg59: see it, reading now
<mjg59> crimsun: Thanks
<crimsun> mjg59: ok, thanks for that heads-up. #44066 (nc8230) should have different ids, since I applied a fix for #41015 that touches the nc8220.
<pitti> crimsun: great! added to my todo list, will do tomorrow
<crimsun> pitti: awesome, thank you very much
* mjg59 defaults unknown ATI cards to vesa
<mjg59> Hurrah, etc.
<ogra> heh
* ogra waits for the "argh my 2D screensavers slow down my system to zero" bugs
<sabdfl> mjg59: cool!
<mjg59> ogra: The ati driver wouldn't drive them anyway
<ogra> oh, ok, then it makes sense
<ogra> i thought you switched because the driver wasnt detecting radeon vs ati 
<mdz> mjg59: using the IDs from the driver itself?  what was the delta like vs. discover-data?
<mjg59> I just added all the hardware supported by the driver to the list
<mjg59> mdz: 5 entries in the driver that weren't in discover-data
<Burgwork> mjg59, what is the difference betweeen the ati and the radeon driver?
<mjg59> Burgwork: ati is a meta-driver that loads the appropriate real driver
<mdz> the trouble is that discover-data always needs updating to keep up with the driver
<Burgwork> mjg59, ah, ok
<mjg59> mdz: Post-dapper we'll probably be able to drive them again and can revert it
<mjg59> But it doesn't look like we'll have support in time
<mjg59> (for dapper)
<mdz> mjg59: I don't suppose they're in a convenient table we could use to autogenerate the discover db
<mdz> (or something better)
<mjg59> mdz: Not really, no
<tseng> infinity: I *think* beagle needs dep-wait cleared when my last upload goes into the queue
<sladen> the i810 driver is just a bunch of #define's for the PCI-IDs it supports
<Burgwork> sladen, that sounds ugly
<mjg59> It's the same for all of them
<Burgwork> isn't x a mess of ifdefs?
<mjg59> Right now, in-X detection is a matter of loading every driver until you hit one that doesn't refuse to stick
<mdz> tseng: I think that's supposed to be fully automatic these days
<tseng> mdz: oh, thats clever
<tseng> mdz: i was never quite sure which ones require manual intervention.. launchpad says "manual depwait"
<tseng> mdz: did you sneak in a break yet? :)
<mdz> tseng: yes, confusing terminology in this case
<mdz> tseng: I replied to your emails
<ogra> mjg59, having all such data in hal one day would so rock ... dexconf would only need some hal calls 
<desrt> ogra; bah.  try having it in-kernel
<tseng> mdz: I meant from the release circus
<Burgwork> desrt, why are graphics and input drivers not in kernel?
<desrt> ogra; pci device id of your vidcard causes the whole udev magic machine to load the right module which exposes a common interface
<ogra> desrt, why ? its valuable data for hal you can use it ijn other areas as well
<desrt> Burgwork; history :)
<ogra> i.e. imagine hal knows you have two monitors and a xinerama capable HW :)
<Burgwork> desrt, in kernel would require dual license or solaris/bsd/other unix to write their own drivers, no?
<desrt> oh license bah
<desrt> fglrx is in kernel and i'm fairly sure it's under somewhat more-gpl-incompat terms than X
<ogra> fglrx is in kernel ??
<desrt> but ya..  you hit on a big issue
<desrt> having X drivers in X itself enables X to go between different OS kernels and take drivers with it
<ogra> its a module, no ? 
<mdz> tseng: that break comes on June 2nd
<desrt> ogra; the drm parts are a kernel module
<ogra> desrt, still not "in kernel" ...
<desrt> ogra; not using it as an example of a video module so much as a piece of non-gpl code that gets linked to the kernel
<Burgwork> mdz, no, on june everybody just gets flung off and has to pick themselves up and get back on again
<mdz> tseng: unless you could the 13 or so hours on airplanes between now and then
<mdz> s/could/count/
<desrt> ogra; my example involves loading of modules... like fglrx
<ogra> desrt, yes, but it sounded like there would be monolithic parts compiled into the kernel
<ogra> as you said it
<desrt> oh.  no.
<ogra> :)
<Chipzz> anyone noticing power-manager brokeness?
<Chipzz> I have power-manager set to do nothing when closing the lid, but it tries to suspend nevertheless :/
<desrt> do you have a powerpc?
<Chipzz> which is *bad* in my case, since suspend to ram causes X to break very badly (X just goes in a never-ending loop of crashing on resume)
<Chipzz> no, laptop
<Chipzz> i386
* desrt shrugs, then
<Chipzz> pretty standard stuff actually
<Chipzz> intel 915 display controller, *82801* for all the rest (except ethernet, which is working fine)
<mjg59> Kamion: So I think I've figured out why the installer has problems with the BIOS emulation stuff on the mactels
<mjg59> Kamion: parted is using the EFI partition table, rather than touching the MBR one that also exists
<Keybuk> https://wiki.launchpad.canonical.com/SoyuzCatchUp
<Keybuk> ^ useful
<mdz> mjg59: how did you end up with two partition tables?
<mjg59> mdz: It's the way boot-camp works
<mdz> ah, of course
<Kinnison> mjg59: Do you still have that GPRS card, and would it be possible for me to borrow it this w/e?
<darius_> do you have a gprs card working in ubuntu?? :)
<jono> hi all
<jono> I need to run a CVS version of gstreamer - is it possible to run this alongside my existing gstreamer? I know this is really for #gstreamer, but its rather silent in there
<theCore> jono: I'm wandering, why do you need a CVS version of gst?
<jono> theCore: I need to make use of recent bugfixes for hacking on Jokosher
<theCore> jono: ah, ok
<jono> any idea if I can run it alongside my current gst?
<mdke> jono: you could try #ubuntu if no one helps here
<jono> ok thanks
<alp> any thoughts on https://launchpad.net/distros/ubuntu/+spec/reboot-halt-notification ?
<mjg59> Kinnison: Yes and sure
* #ubuntu-devel  [freenode-info]  help freenode weed out clonebots, please register your IRC nick and auto-identify: http://freenode.net/faq.shtml#nicksetup
<infinity> Keybuk: With a few minor exceptions where ubiquity may reconfigre a package, it shouldn't be configuring anything, but just copying stuff verbatim from the livefs.
<Keybuk> that's what I thought by looking at the code
<Keybuk> so this needs an ickle patch to make /var/run and /var/lock on the root fs before mounting /var ;o)
<crimsun> infinity: is there a rejected alsa-tools_1.0.10-1ubuntu1 in the upload queue?
<Keybuk> do you mean is there an alsa-tools in the rejected queue? :)
<crimsun> Keybuk: err, yes
<Keybuk> not that I can see
<Keybuk> isn't in any queue
<crimsun> ok, so my uploads are being rejected once again.
<Keybuk> I'm not sure where automatically-rejected uploads ends up
<Keybuk> did you get a mail?
<crimsun> none at all
<Keybuk> where did you upload to?
<crimsun> ubuntu universe
<crimsun> dput ubuntu lalala_source.changes
<Keybuk> got the changes file?
<crimsun> http://sh.nu/~crimsun/uploads/alsa-tools_1.0.10-1ubuntu1_source.changes
<Keybuk> and you definitely uploaded via ftp to upload.ubuntu.com into / ?
* Keybuk doesn't know dput
<crimsun> I definitely did.
<crimsun> I'll ping cprov in #launchpad tomorrow
<Keybuk> it's not in any queue I can see, anyway; that doesn't mean it's not automatically rejected
<Keybuk> I _could_ stick it through the queue manually and see what error I get <g>
<crimsun> It's probably some amalgamation of the email-address-doesn't-match-preferred_address deal
* Keybuk tries something very dodgy that may not even work
<elmo> Keybuk: eh, have you checked failed?
<Keybuk> elmo: I don't have access to that, do I?
<elmo> you have lp_archive, you have access to evarything
<elmo> ./failed/upload-20060511-025657-004458/alsa-tools_1.0.10-1ubuntu1_source.changes
<Keybuk> how do I see failed?
<bddebian> w00t, go Keybuk
<Keybuk> elmo: where's that?
<elmo> Keybuk: I just do 'find /srv/launchpad.net/ubuntu-queue/ -name blah.changes'
<Keybuk> ah
<Keybuk> does it log the reason anywhere?
<elmo> no, that'd be useful
<Keybuk> heh
<elmo> the most common eason is wrong distro, but that's not the case here
<elmo> it's signed by a key that's in ubuntu-dev  too
<elmo> 02:02:04 DEBUG   UploadError made it out of .process() -> http://librarian.launchpad.net/2562322/eni8hMxxfUh1MStvmnZowPafK7f.txt (GPG verification of alsa-tools_1.0.10-1ubuntu1_source.changes failed: No public key)
<elmo> Keybuk: /var/mail/lp_archive should be your next step, apparently
<elmo> crimsun: did your key expire at any point?
<elmo> crimsun: in any event, I suggest you file a bug on 'qprocd' about it, and quote that DEUBG line, mention that you're in ubuntu-dev etc. 
<Keybuk> having the lp pubring.gpg somewhere would be useful
<crimsun> elmo: ok, thanks.
<crimsun> elmo: no, it hasn't expired (and won't til late June)
<elmo> Keybuk: it fetches on demand, I think
<lifeless> it will do
<lifeless> IIRC its using the lp gpg infrastructure
<Keybuk> yeah it is
<lifeless> which means the keyring is in the database, and the keys are cached on the appserver for the lifetime of the process only
* Keybuk hasn't figured out where the database can opener is uyet
<Keybuk> there must be some combination of host and username that lp_archive can run psql with, and see the real db
<Keybuk> even if just readonly
<Keybuk> oh, and guess what, it's the first thing that popped into my head
<Keybuk> lifeless: ok, the fingerprint is recorded in the database ... where does it look for the public keys?
<lifeless> keyserver.ubuntu.com
<bddebian> Heya lifeless
<lifeless> hey bddebian 
<Keybuk> quest scott% gpg --keyserver keyserver.ubuntu.com --recv-key 1FE80436CA130121E49B77DB7BD1B015C88ABDA3
<Keybuk> gpg: requesting key C88ABDA3 from hkp server keyserver.ubuntu.com
<Keybuk> gpg: key C88ABDA3: "Daniel T. Chen (new) <crimsun@fungus.sh.nu>" 6 new signatures
<Keybuk> hmm
<Keybuk> there's a public key there too
<bddebian> Oh, speaking of which.  I just reset my key not to expire.  Do I need to send up to keyserver.ubuntu.com?
<zakame> hi all
<lifeless> send it to subkeys.pgp.net
<bddebian> Thx lifeless
<elmo> send it to keyserver.ubuntu.com
<elmo> it's part of the global keyserver network
<elmo> it'll propogate to subkeys et. al. automatically
* bddebian wonders if elmo is actually talking to him
<elmo> uh
<elmo> R. [  51: Ubuntu Installer    ]  Accepted alsa-tools 1.0.10-1ubuntu1 (source)
<Keybuk> that might have been me <g>
<Keybuk> and it may not have gone exxxactly right
* Keybuk is still new at this
<crimsun> (it definitely wasn't me, though I did ask bddebian to upload since mine failed)
<Keybuk> it made vague sense, that given it was a gpg key failure, stuffing it back in incoming might just work the second time
<bddebian> Aye but you told me to wait so I haven't done it :-)
<Keybuk> I checked it over and it was "ok"
<Keybuk> but obviously sync-queue/incoming isn't quite "incoming"
<Keybuk> now I know that <g>
<Keybuk> out of interest, is there an actual incoming that you can get at on drescher?
<Keybuk> s'ok found out how I'd attempt it next time <g>
<zakame> fabbabbione: around?
<zakame> gaah, dialup lag :'(
<bddebian> zakame: So fix that :)
<zakame> if I could, yes
<zakame> however, I'm quite fortunate that I get around 5Kb of download rate even under a 14.4....
<bddebian> Yeah not bad
<fabbione> morning
<Keybuk> infinity: nv driver works now
<Keybuk> but is kinda sucky, not good speedwise and no DRI/GLX
<infinity> Keybuk: Yeah, it's known to be not fantastic, but OTOH, it's stable, and generally "works".
<Keybuk> "binary nasty" seems to work much better
<infinity> Keybuk: Yeah, it's known to be not fantastic, but OTOH, it's stable, and generally "works".
<infinity> In your case, though, with a shiny SLI rig, the binary driver's probably the "right" one.
<Keybuk> in all of my experience, the nv driver is shoddy and unreliable and it's the nvidia one that's stable and generallt works
<Keybuk> *shrugs*
<Keybuk> (II) Primary Device is: PCI 01:00:0
<Keybuk> (WW) NV: No matching Device section for instance (BusID PCI:2:0:0) found
<Keybuk> (--) Chipset GeForce 7800 GTX found
<Keybuk> heh
<Keybuk> I guess nv doesn't "do" SLI then
<infinity> No, it doesn't.
<infinity> There'd be no point anyway, since it doesn't do DRI either.
<Keybuk> it doesn't even seem to do PCIe
<infinity> I can't imagine that SLI drastically improves your 2D rendering experience. :)
<Keybuk> the nv log doesn't mention PCIe at all
<Keybuk> the nvidia one at least has a comforting message about using PCIe
<infinity> Heh.
<Keybuk> using PCI to talk to a graphics card seems plain dumb
<Keybuk> no wonder the window was painting across the screen when I dragged it <g>
<infinity> The 2D drawing in nvidia is really quite well accelerated too.
<infinity> I really wish they'd give back to the open source driver a bit more. :/
<infinity> nvidia's binary drivers beat the pants off ati's shoddy offering.
<infinity> (fglrx is crap... Seriously... Horrible)
* desrt would dispute this statement but was recently driven to buy an nvidia card by ati's general crappiness
<desrt> oddly, my ati problems had nothing to do with linux
<Keybuk> yeah, I had a run of bad ATI cards
<Keybuk> the last one wouldn't give any monitor info
<Keybuk> one before that blew up, one before that died, etc.
<infinity> I've been an nvidia fanboy for ages (Since my first Riva128, actually), but that doesn't prevent me from whining about their closed-source binary-only ARGH.
<desrt> this one would randomly (~20%) decide that my monitor was on the SVGA port when turned on (and drive output there instead of my DVI port)
<desrt> for values of "turned on" == power on, reboot, just before loading grub, whenever switching between console and X, etc, etc...
<infinity> And if you want to use only free drivers, radeons are much better supported.
<infinity> Anyone have any objections to me transitioning all over universe to libmysqlclient15 to avoid whacky segfaults when mixing main/universe packages in the same memory space?
<infinity> s/all over/all of/
<infinity> (And so I can drop libmysqlclient-lgpl and mysql-dfsg_4.0 from the archive)
<fabbione> infinity: i am ok with it..
<pitti> Good morning
<Keybuk> morning berpitti
<zyga> hello
<zyga> I'd like to report/debug network manager issue: I have a laptop with a built-in wired and pcmcia wifi card, network manager sees only the wired card. I am using foss bcm34xx drivers, what should I do to get NM to notice it?
<zyga> (the card obviously works)
<Keybuk> file a bug upstream, attaching output of NetworkManager --no-daemon
<Keybuk> though I've heard numerous reports that it sees it just fine
<infinity> zyga: Also, make sure the card IS working (do ifconfig and iwconfig see it, etc?)
<zyga> infinity: I'm talking over wifi now :)
<zyga> infinity: all tools see it, including network-admin
<infinity> zyga: Oh, then it's an Ubuntu feature you're banging your head against, probably.
<infinity> zyga: Try removing the config for the card from /etc/network/interfaces and restarting NM.
<zyga> checking
<zyga> infinity: for both cards or just the wifi?
<infinity> Well, if NM is seeing the wired card, make the wireless card looks similar. :)
<infinity> (I suspect the wired is "auto eth0\niface eth0 inet dhcp")
<zyga> works :D
<Keybuk> oh, that's a good point
* Keybuk forgot about that :)
<zyga> wow 
<zyga> quite nice :D
<zyga> :>
<Keybuk> what is?
<zyga> thanks
<zyga> I have commented out everything except for lo
<zyga> I'll attach a wired cable now
<zyga> this stuff rocks
<infinity> When it works, it's pretty cool, yeah.
<infinity> When it doesn't, it makes you want to apply a fork to your eye.
<infinity> (I have several forks in my eyes at this point)
<Keybuk> it makes me want to apply a fork to DanW and RML's eyes
<thom> Keybuk: well, you have experience with the former part of that sentence i'm sure...
<Keybuk> other Dan
<Keybuk> Dan Williams != Dan Winship
<thom> ah well
<thom> there goes that joke then ;-)
<pitti> hi zyga
<pitti> zyga: hey again :)
<zyga> pitti: hey :)
<zyga> I just got network manager working on my laptop and it's a true joy to use :>
<pitti> zyga: cool
<Treenaks> Too bad it uses gnome-keyring-manager, which asks for my OLD password to store stuff in the keyring
<pitti> zyga: yesterday you asked me about wireless on my desktop, but then you disappeared - do you still have a question?
<Treenaks> And password changing for gnome-keyring seems impossible
<zyga> pitti: yeah, does the ibook wifi (broadcom AFAIR) card work on dapper?
<infinity> Treenaks: Install gnome-keyring-manager
<pitti> zyga: yes, it does (the airport extreme)
<zyga> pitti: did you have to do anything to get the firmware?
<Treenaks> infinity: why isn't it standard functionality?
<pitti> zyga: yes, use bcm43xx-fwcutter to grab it from MacOS or the driver CD
<infinity> Treenaks: Because keyring-manager sucks.
<infinity> Treenaks: AFAICT, you'll still need to delete your default keyring and recreate it to change the passphrase.
<zyga> right, I used third-party apt repo to get that (i know it's not legal)
<Treenaks> infinity: hm.. great..
<Kinnison> Morning all
<fabbione> morning Kinnison 
<Kinnison> Hi fabbione
* Kinnison grumbles about being woken at 07:45 by the skip delivery
<infinity> Kinnison: You'll get over it... :)
<Kinnison> infinity: I'm sure I will, s'just that I was up until all hours (about 2am) packing boxes
<Kinnison> since I can't pack during work hours
* Kinnison looks at the floor-to-ceiling pile of boxes marked DVDs CDs and Books
<Keybuk> that's what I shall put on my limited edition t-shirts
<infinity> Time for a book burning party?
<Keybuk> "NOT A CORE HOUR ACTIVITY"
<Kinnison> Keybuk: perfect
<dholbach> good morning
<Kinnison> hi daniel
<netstar> LP upgrade?
<dholbach> Hey Daniel!
* ..[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 | Flight-7 released
<Kinnison> netstar: that was yesterday
<netstar> :)
<netstar> Does anyone know how to log in and adminstrate cups via the web interface, lppasswd does not work and ipp config is broken, cups reports unauthorized attempts to resume the printer, is their a known issue or something?
<netstar> *there
<mdz> development team meeting in 6 minutes
<Kamion> mjg59: I still think bootcamp might be too horrible to actually use properly
<Kamion> Keybuk: how do /var/run and /var/lock get created in the normal installer then?
<Kamion> Keybuk: sync-queue/incoming/ er kind of ignores GPG signatures. :)
<Keybuk> Kamion: by initscripts postinst script
<Keybuk> (probably should be base-files, but that's largely irrelevant)
<Keybuk> I perpared a "hacky" quick fix
<Keybuk> http://people.ubuntu.com/~scott/bzr/ubiquity/
<Keybuk> (damn, that's hard to spell :p)
<Keybuk> it also fixes another bug -- that ubiquiuiuiuty doesn't write /etc/iftab the same as netcfg
<mjg59> Kamion: It may be more practical than the alternative
<infinity> Keybuk: Err, the directories are created by a postinst?... Why not just ship them in a .deb?
<Keybuk> infinity: because the directories need to be created on the root filesystem
<Keybuk> not on whatever filesystem happens to be mounted on /var :)
<Keybuk> so there's a bit of bind-mount-magic
<Keybuk> otherwise one can't mount /var/run or /var/lock until after you've mounted /var
<infinity> Keybuk: But nothing should need either until /var exists anyway.. No?
<Keybuk> no
<Keybuk> the point of /var/run and /var/lock is that they're writable places for the entire boot
<Keybuk> /var isn't mounted until reasonably late
<infinity> This was never a problem before all this hackery began..
<Keybuk> certainly well after things like udev, ifupdown, dhclient, ntpdate, etc. are running
<infinity> I never had anythig that wanted to write to /var/run before /var was mounted.
<Keybuk> it wasn't a problem until we started relying on udev
<infinity> Oh, I see.  Ick.
* Mithrandir wonders when we should stop tweaking cupsd.conf.  It's getting annoying to get conffile prompts about it each and every day.
<Keybuk> once you rely on udev, you need a tmpfs for pid files
<Keybuk> otherwise there's a bit of a chicken and egg problem
<Keybuk> if udev is creating /dev nodes and starting services, then it can't start services until after the device node for any filesystem they need has been created
<Keybuk> the two options to fix it were
<Keybuk> a) two partial udevplugs during boot, one to deal with important nodes and then one after filesystems are mounted and checked to actually start things
<Keybuk> b) just make /var/run a tmpfs
<Keybuk> a has the obvious problem you can't have an NFS /usr ;)
<infinity> Yeah, I see the issue now.  It's just all rather icky. :)
<Keybuk> actually, I think it's somewhat elegant
<Keybuk> having a tmpfs for pid files makes sense
<Keybuk> as you never need them after reboot *anyway*
<Keybuk> and we've since been able to use /var/run as a "transient" directory
<infinity> Oh, no, having it as a tmpfs makes sense.  It's the bindmount moving trickery that's icky.
<Keybuk> it solved the ifup-using-/etc bug, for example
<Keybuk> oh, yah, that bit was icky
<Keybuk> but it's only done once, at install time
<looksaus> hi all, I'm a bit hesitant to interrupt you in what must be _very_ busy days, but...
<looksaus> I think I might have reported a major ppc bug in gecko based browsersalmost four weeks ago, and I'm not certain it got the attention needed
<looksaus> I have confirmation from at least one other powerpc users
<looksaus> https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067
<Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Unconfirmed]  
<looksaus> it basicly makes the major desktop component unusable, so looks quite serious to me...
<looksaus> oh sorry, people just telling me most of you are in a meeting
<pitti> crimsun: I did your alsa-{lib,utils} uploads, thanks
<seb128> grrrr that "QuickStart.." guy crossposting on a zillion on lists every mail he sent
<ogra> yep :(
<sfllaw> He thinks he's helping, too.
<sfllaw> You sorta don't want to crush his enthusiasm.
<Treenaks> He's basically removing whitespace from XML files, right?
<seb128> he's not doing anything useful
<sfllaw> Treenaks: Yes.
<Kamion> Keybuk: I think I might prefer to do it in partman while it's mounting filesystems
<Kamion> less hacky
<ogra> he's deleting xml files with rm -rf in his script 
<seb128> sfllaw: he claims that his schemas change speed-up applications but schemas are only used at installation
<Keybuk> Kamion: yeah, that might be more appropriate; I wasn't sure I was up for touching partman closely
<sfllaw> Parsing text files takes almost no time.
<Keybuk> but was sure you'd prefer a solution available, whether you chose it or not
<Treenaks> seb128: he's probably seeing disk-cached startup instead of non-cached startup
<Keybuk> you want the iftab change though :)
<Kamion> Keybuk: nod, just merging that now
<seb128> right
<seb128> Treenaks: likley
<seb128> but I would appreciate him not trying to push stuff to user than can break their gconf database but playing with the .xml
<pitti> Keybuk: would it be considered evil if cupsys' init script would load 'lp' and 'ppdev' modules?
<Keybuk> pitti: not especially evil, no
<pitti> Keybuk: I get thousands of bugs due to a missing lp module, and ppdev fixes parallel printer autodetection
<AlinuxOS> carlos, hello amigo, question: will Kubuntu (KDE) imported into rosetta ?
<carlos> AlinuxOS: it's already there
<Riddell> carlos: I should do an announcement to the KDE translators
<pitti> Riddell: new langpacks are scheduled for tomorrow, btw
<carlos> Riddell: I'm should do the global announcement for Dapper, don't worry
<carlos>  s/I'm/I/
<Riddell> pitti: cool, that should please lots of people
<carlos> pitti: could we do it weekly automatically?
<persia> pitti: I noticed you have targeted the 2 CDROM issue for dapper.  Do you have a test case, or could I help collect necessary data?
<carlos> I think you said is possible but that you need some extra scripts
<AlinuxOS> carlos, is there Kubuntu page ?
<pitti> carlos: not fully automatically, but I can do automatic builds, so I only need to grab and test them, and upload if appropriate
<pitti> persia: currently I don't even understand the bug yet, but it shouldn't be hard to fix once I do; helping with explaining the issue in detail would be highly appreciated
<carlos> AlinuxOS: no, sorry, is all together with other Ubuntu packages
<pitti> persia: it just seems worth to be fixed in dapper
<AlinuxOS> https://launchpad.net/distros here I mean
<AlinuxOS> sh
<carlos> AlinuxOS: we will improve it to split packages per context, like GNOME, KDE, XFCE and base
<carlos> AlinuxOS: https://launchpad.net/distros/ubuntu/dapper/+translations
<AlinuxOS> ah so the is no kubuntu refference at the moment. I understand now.
<carlos> AlinuxOS: right, KUbuntu uses Ubuntu's archive
<AlinuxOS> I understand.. :)
<AlinuxOS> so you will separate them right ?
<AlinuxOS> in near future.
<Riddell> AlinuxOS: what language will you be translating into?
<persia> pitti: OK.  I'll try to describe it again differently in the bug, in the hopes of providing an explanation.  Feel free to ping me if you have questions.
<pitti> persia: thanks; a detailed description of the devices, fstab, and steps how to get the bug would rock
<AlinuxOS> https://launchpad.net/distros/ubuntu/dapper/+lang/ka Riddell at the moment I'm Georgian GNOME Translators team coordinator/translator and Ubuntu Team translator/administrator and great Ubuntu Distribution User :)
<AlinuxOS> Ubuntu Lover/User/Translator :)
<pitti> mdz: btw, wrt your meeting question, my dapper-6.06 bug list is now up to date
<AlinuxOS> carlos, when will you sepparate GNOME/KDE in Dapper distribution ?
<carlos> AlinuxOS: I don't have it scheduled yet
<AlinuxOS> carlos, ok :)
<carlos> but when it's done will be done for all releases
<carlos> at the same time
<Riddell> I don't know if that's a good idea, would probably mean less translations for Kubuntu
<AlinuxOS> great
<AlinuxOS> so there is no decided package list for future Dapper CD ?
<ogra> carlos, could you think about making separate kdeedu langpacks for edgy ? it would help edubuntu a lot in case we cant drop kdeedu then
<AlinuxOS> Riddell, why ?
<Riddell> ogra: langpacks are done by pitti
<carlos> ogra: that's a question for pitti
<ogra> ah, k
<ogra> i'll keep it for paris then :)
<pitti> ogra: yes, let's discuss that there
<Riddell> AlinuxOS: I wonder if ubuntu users would then not bother to translate kubuntu packages
<pitti> ogra: we can certainly find a good solution
<ogra> yep
<carlos> Riddell: we are not going to split the packages outside Ubuntu, we are going to classify them
<AlinuxOS> I was asked some days ago, there was some group of person that wanted to translate Kubuntus specific packages.
<ogra> well, the best one would be to be able to drop the kde stuff :)
<carlos> Riddell: so you can see if a package is a GNOME, KDE, XFCE, or system package
<carlos> and concentrate on the set of packages you are insterested
<AlinuxOS> Riddell, if you want the truh :) Sadly in georgia there is more KDE/Kubuntu users than GNOME users :) (It our specific situation)
<AlinuxOS> don't know for other teams :)
<Treenaks> Most of our stuff gets translated upstream (Dutch)
<AlinuxOS> so I'm sure that there will be more Kubuntu translators then Ubuntu/GNOME translators.
<Riddell> excellent :)
<AlinuxOS> carlos, a question: is it possible to translate Ubuntu Live Espresso installer into Georgian ?
<AlinuxOS> and if it possible, how?
<Riddell> AlinuxOS: yes, espresso is called ubiquity now
<AlinuxOS> great
<carlos> AlinuxOS: translate the debian installer
<carlos> AlinuxOS: the translations are integrated there
<AlinuxOS> https://launchpad.net/distros/ubuntu/dapper/+source/k3b/+pots/k3b/ka/+translate is there K3b package ? 
<carlos> AlinuxOS: https://launchpad.net/distros/ubuntu/dapper/+source/debian-installer/+pots/debian-installer
<carlos> AlinuxOS: yes, there is
<AlinuxOS> carlos, our georgian bitmap/monotype font is under construcion... our team will test them in the near future (days I hope)
<AlinuxOS> so I would like to start importing into our page..
<AlinuxOS> ah ok
<AlinuxOS> carlos, and how about k3b, I have ka.po file rady :) 
<AlinuxOS> https://launchpad.net/products/?text=ubiquity Riddell can't find ubiquity, maybe it's not imported at the moment?
<carlos> AlinuxOS: upload it and the next language pack build will get it
<carlos> AlinuxOS: it's a distro package
<AlinuxOS> carlos, allredy done
<carlos> that's a search form for packages
<Keybuk> fabbione: my sister got a kitten a couple of weeks ago
<Keybuk> ...the dog ate it yesterday
<Riddell> AlinuxOS: ignore me, as carlos says it's debian-installer that needs translated, ubiquity uses the strings from that
<ogra> Keybuk, huh ? 
<carlos> AlinuxOS: https://launchpad.net/distros/ubuntu/dapper/+search?text=ubiquity
<ogra> what kind of evil dog do you have ? 
<fabbione> Keybuk: ehhe
<Keybuk> ogra: not me, my dog is fluffy
<ogra> heh
<Keybuk> her dog is quite rough though
<ogra> but thats really evil 
<AlinuxOS> carlos, can't fint translations page :) sorry 
<Kamion> https://launchpad.net/distros/ubuntu/dapper/+source/debian-installer/+pots/debian-installer
<Kamion> as carlos said earlier
<mdke> Znarl: thanks for the wiki! does henrik have access to the wiki theme stuff too, as well as the static webspace? We need to do some theme and config tweaking
<AlinuxOS> Kamion, ah so to have ubiquity translated, firs we must translate debisn-installer
<AlinuxOS> and ubiquity automatically shows debian-installe's strings right ?
<carlos> AlinuxOS: sort of, yes
<AlinuxOS> ok
<Kamion> AlinuxOS: I manually import them, but yes
<AlinuxOS> :) as I see there is no ubiquity translations :) so it's debian-installer :)
<AlinuxOS> ok
<AlinuxOS> guys thank you :) must run
<AlinuxOS> seeya!
<AlinuxOS> carlos, pitti Riddell Kamion thank you :)
<AlinuxOS> thank you all! :)
<carlos> AlinuxOS: you are welcome
<Znarl> mdke : Yes, Henrik does have access.
<mdke> Znarl: manifique
<mdke> Znarl: thanks a lot, really appreciate your work on that
<klugez> renice lets normal users to give processes negative values in dapper
<klugez> http://pastebin.com/711061
<klugez> people on an IRC channel just found it out
<klugez> as far as i know, nobody has filed a bug about it yet
<Keybuk> kooky
<Keybuk> paperboy scott% renice -10 $$
<Keybuk> renice: 16238: setpriority: Permission denied
<Keybuk> quest scott% renice -10 $$
<Keybuk> 15413: old priority 0, new priority -10
<Keybuk> iz BenC bug
<pitti> Keybuk: paperboy is breezy?
<Keybuk> pitti: yeah
<pitti> urgh, works here as well
<doko_> mdz: bug 25978: does your comment "we should sync" imply an agreement to update from 2.7.5 to 2.7.6?
<Ubugtu> Malone bug 25978 in antlr "antlr-2.7.5/examples/java/unicode.IDENTs/ShowString.java fails DFSG #1" [Unknown,Fix released]  http://launchpad.net/bugs/25978
<Kinnison> FYI, stracing it, it seems setpriority(PRIO_PROCESS,$PID,-val) seems to "succeed" but set it to +30
<Kinnison> most odd
<Keybuk> it does set it to -10
<Kinnison> pitti: shall we chat about the atconsole bit in about 10 minutes? I need to grab something for breakfast
<Kinnison> getpriority(PRIO_PROCESS, 22163)        = 10
<Kinnison> setpriority(PRIO_PROCESS, 22163, -10)   = 0
<Kinnison> getpriority(PRIO_PROCESS, 22163)        = 30
<mdz> doko_: if it does't break reverse build-deps, yes
<Keybuk> quest scott% ps -p 15493 -l
<Keybuk> F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
<Keybuk> 0 S  1000 15493 12775  0  66 -10 -  5634 -      pts/3    00:00:00 zsh
<pitti> Kinnison: (how did you do that bold text?) yes, sure
<doko_> ok
<Kinnison> pitti: in irssi-text, surround things with ctrl+B
<Kinnison> pitti: like this :-)
<pitti> hello world!
<Kinnison> indeed
<pitti> wow, works in xchat, too
<seb128> mdz: about bug #31775
<Ubugtu> Malone bug 31775 in Ubuntu "Ubuntu should have better links to support options" [Wishlist,Confirmed]  http://launchpad.net/bugs/31775
<Kinnison> It has the advantage that it works with spaces, where *foo* doesn't I think
<Keybuk>                                 if (p->uid == who) {
<Keybuk>                                         niceval = 20 - task_nice(p);
<Keybuk> that's why you get 30
<Keybuk> the kernel totally doesn't expect user processes to have negative numbers ;)
<Keybuk> so it's set to -10, the kernel just doesn't cope with returning that <g>
<seb128> mdz: that's the change we discussed during UI sprint, could you or mark or anybody decide on that so it can be applied? We still lack URIs to point to and exact wording ...
<mdke> Kinnison: I'm still seeing the dreaded bug #33072 (or at least the symtoms)
<Ubugtu> Malone bug 33072 in gnome-power-manager "Pulling AC plug suspends computer" [Unknown,Unknown]  http://launchpad.net/bugs/33072
<Keybuk> anyone got a Debian box on 2.6.15 ?
<Mithrandir> Keybuk: yes, why?
<pitti> Keybuk: will 2.6.16.11 do as well? (my server)
<Kamion> Keybuk: 2.6.16 but not 2.6.15
<Keybuk> see if it works on those
<Kinnison> mdke: Have you recorded a gnome-power-manager --no-daemon --verbose trace of the latest version exhibiting the bug?
<Keybuk> narrows down Kernel vs. Ubuntu bug
<Kamion> <cjwatson@cairhien ~>$ renice -10 $$
<Kamion> renice: 12313: setpriority: Permission denied
<mdke> Kinnison: no, I will try.
<pitti> (2.6.16.14 on mine)
<Kamion> <cjwatson@cairhien ~>$ uname -a
<Kamion> Linux cairhien 2.6.16-1-powerpc #2 Tue Apr 25 15:16:02 CEST 2006 ppc GNU/Linux
<pitti> Keybuk: renice -10 $$ fails on 2.6.16.14 upstream
<Mithrandir> Linux aine.err.no 2.6.15-1-powerpc #2 Mon Mar 6 12:39:17 CET 2006 ppc GNU/Linux
<Mithrandir> : tfheen@aine ~ > sudo renice -10 $$
<Mithrandir> Password:
<Mithrandir> 22501: old priority 0, new priority -10
<Kamion> Mithrandir: not as root
<pitti> Mithrandir: I think he wanted to know as normal user
<Keybuk> Mithrandir: normal user :p
<Mithrandir> : tfheen@aine ~ > renice -10 $$
<Mithrandir> renice: 22501: setpriority: Ikke tilgang
<Mithrandir> (permission denied)
<mdke> Kinnison: it doesn't seem to be reproducable every time any more. I'll keep trying
<pitti> so, upstream seems to be fine and it's an ubuntu kernel bug
<Kinnison> mdke: Remember, we think it's to do with lid status confusion, so you may have to play about with that too.
<Keybuk> Mithrandir: that's non-Ubuntu 2.6.15 ?
<Kinnison> mdke: don't worry about making a big logfile, I can grep it when it comes time
<Keybuk> pitti: yeah, just about to compare the setpriority() functions
<Mithrandir> Keybuk: that's debian 2.6.15, whatever's in testing.
<Mithrandir> Keybuk: 2.6.15-8, it seems
<Keybuk> ok
<Keybuk> so we have exactly the same implementation as 2.6.16.15
<mjg59> I blame pam
<Keybuk> mjg59: why pam?
<mjg59> minimum niceness is an rlimit
<mjg59> (judging by can_nice in kernel/sched.c)
<mdz> seb128: I thought it was final; if not, please email Mark
<seb128> mdz: what was final? The current implementation or the bug description?
<mdz> seb128: the current menu and hyperlinks
<seb128> ok, I'll mail mark then
<mdz> thanks
<seb128> and there is probably one extra item to add still according to the mail you forwarded to me
<mjg59> So something's setting rlim[RLIMIT_NICE]  inappropriately
<Mithrandir> mjg59: ulimit -e on Debian and Ubuntu returns different values, so I agree with you
<Mithrandir> (0 and unlimited)
<mdke> Kinnison: well so far I can't reproduce it at all :-( will keep trying
<mjg59> http://ubuntustudio.com/wiki/index.php/Devel:Rlimits-Aware_PAM
<mjg59> I blame the music people :p
* Kamion wonders if it's due to the addition of those real-time limits
<Kamion> yeah
<Kamion> I applied that patch though, it *seemed* right
<Kamion> well, with modifications to be more-right
<mjg59> Where does the default get set?
* Kamion guesses that the range handling is wrong
<Keybuk> indeed, RLIMIT_NICE is RLIM_INFINITY
<mjg59> My suspicion is that it ends up as unlimited if not explicitly set?
<Kamion> perhaps, although shouldn't the kernel have a sane default?
<Kamion> unless pam's setting it to unlimited
<mjg59> The kernel seems to set it to 0 (include/asm-generic/resource.h)
<mjg59> Hm. I can't see anywhere where pam /could/ set it to unlimited, though
<Keybuk> isn't "0" actually -20
<mjg59> Keybuk: No
<Keybuk> oh, no, 0 would be 20
<mjg59> Well, 19
<mjg59>             limit_value = 19 - limit_value;
<Keybuk> mjg59: the kernel tends to do 20 - value
<Keybuk> though doesn't seem to on that
* Keybuk boggles his way through can_nice
<mjg59> Keybuk: From the userspace point of view, it's -20 to +19
<Keybuk> yeah, from kernel pov it's 1 to 40 isn't it?
<mjg59> Yes
<Kamion> pam sets all limits to RLIM_INFINITY by default
<Kamion> (init_limits)
<mjg59> Kamion: Doh. Right.
<mjg59> That'll be the problem, then.
<Kamion> though only if getrlimit() returns -1
<Kamion> (so why is getrlimit() returning -1 if the kernel sets a default?)
<mjg59> Kamion: Unsure
<Kamion> would be nice to see an strace of pam_limits in action
<Kamion> init_limits has a few manual overrides anyway (core, stack); if that's the problem it's simple to add to them
<pitti> Kamion: wrt. bug 14597, my current plan is to add all gimp-help-* but the -en one to the language-support-* packages, so that we can fix the bug at least for all non-English speakers; do you think it would be appropriate to change the seeds to not add l-support-en to the CD (and only seed a subset instead)?
<Ubugtu> Malone bug 14597 in gimp "Gimp help files are not installed by default" [Wishlist,Confirmed]  http://launchpad.net/bugs/14597
<Keybuk> hmm
<Keybuk> I read init_limits the other way
<Keybuk> I read it as setting to RLIM_INFINITY if it's NOT already -1
<Kamion> er, yeah, good point
<Keybuk>         int r = getrlimit(i, &pl->limits[i] .limit);
<Keybuk>         if (r == -1) {
<Kamion> I think I need breakfast, coffee, and *then* pam hacking
<Keybuk>         } else {
<Keybuk>             pl->limits[i] .limit.rlim_cur = RLIM_INFINITY;
<mjg59> strace doesn't know about RLIMIT_NICE, but:
<mjg59> 22400 getrlimit(0xd /* RLIMIT_??? */, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
<Keybuk> this kind of hacking is the best coffee :)
<mjg59> 22400 getrlimit(0xe /* RLIMIT_??? */, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
<Kamion> nice is 13
<Kamion> er, 0xd
<mdke> I'm quite curious about these "speed up Ubuntu" emails, does anyone know why 2 copies of each mail are arriving to the various mailing lists included?
<mjg59> So getrlimit returns 0 and it gets set to RLIM_INFINITY?
<Keybuk> that's just setting up data structures
<Keybuk> where does it setrlimit ?
<mjg59> 22400 setrlimit(0xd /* RLIMIT_??? */, {rlim_cur=RLIM_INFINITY, rlim_max=RLIM_INFINITY}) = 0
<Keybuk> oh, it does them all in setup_limits
<mjg59> Blatantly PAM
<mjg59> Yay I win
<Kamion> is it just me or is pam also using the 2.6.12 (broken) off-by-one semantics for nice?
<Keybuk> mjg59: as a reward, you get to fix it :p
<fabbione> infinity: new evdev is in and should fix the FTBFS at least on ia64..
<mjg59> lamont: Entirely possible
<Kamion> I don't mind fixing it up
<mjg59> Erm
<Keybuk> Kamion: yes
<mjg59> Kamion: Entirely possible
<Keybuk> klugez: thanks, btw
<klugez> Keybuk: no problem
<pitti> doko_: what about openoffice.org-help-lt? IIRC that was the one I recently dropped from l-support-lt, right? it appears in anastacia, should it be demoted/removed/?
<Keybuk> that's the help thingy I was on about in the meeting
<doko_> pitti: once -l10n builds again, that can be removed
<pitti> doko_: ah, ok
<seb128> Keybuk: you do initscripts? Somebody on #ubuntu-bugs was pointing bug #32455 which has a patch ...
<Ubugtu> Malone bug 32455 in initscripts "Mount points including spaces are not umounted at shutdown" [Normal,Unconfirmed]  http://launchpad.net/bugs/32455
<zakame> hi all
<Kamion> it's probably a broken fstab; you have to encode spaces as %040 or something in fstab
<zakame> infinity: ping
<Kamion> though maybe not
<ogra> wuld it be possible that we can get the ooo2 uninstallables from the daily CD reports ? to please my tidiness ?
<seb128> Kamion: the bug description uses "\040", isn't that correct?
<Kamion> seb128: yeah, sorry, I made my comment before reading the bug, ignore me
<seb128> np ;)
<Keybuk> grr
<Keybuk> why does Malone do that?
<Keybuk> there's NO SUCH PACKAGE as initscripts
<Keybuk> yet, there the bug is, failed against it
<Keybuk> "initscripts" source package in ubuntu:
<Keybuk> There is no current release for this source package in Ubuntu
<Keybuk> wow
<Keybuk> there's a whole little collection of bugs filed against it too
<ogra> https://launchpad.net/distros/ubuntu/+source/initscripts/+bugs i see them
<Kamion> it's a binary package not a source
<seb128> Keybuk: that's the "accept binary package as source package" issue which is a known one
<Keybuk> eww
<Keybuk> those should all be filed against sysvinit
<seb128> right
<ogra> Kamion, then its shouldnt have bugs under the above url :)
<Keybuk> and then they would have appeared in my bug list
<pitti> mjg59: I assume there's little to no hope for our dbus-foreground patch?
<seb128> Keybuk: https://launchpad.net/products/malone/+bug/37866
<Ubugtu> Malone bug 37866 in malone "+editstatus should not accept binary package as source package" [Normal,Confirmed]  
<ogra> ah
<Kamion> ogra: that's precisely Keybuk's complaint, if you read ...
<ogra> yep
<Keybuk> seb128: that patch worries me
<Keybuk> why isn't the same patch being applied to mountall and mountnfs, etc.
<seb128> iegary: question for you :)
<seb128> Keybuk: you have a point
<Keybuk> I'll have to look at those bugs later, there's a few there with patches that need thought
* Keybuk wonders what other "binary packages" he needs to subscribe to
<Keybuk> *sigh*
<iegary> Keybuk: it should, I guess :) If you're happy with the format of the umount patch, I'll do something similar for the other init scripts too
<Keybuk> iegary: I'll have to read it, and decide
<Keybuk> the fact it doesn't do anything like that now suggests the documentation is wrong
<iegary> Keybuk: well until udev started to decide mount point naming, there weren't very many mount points with spaces
<Keybuk> iegary: udev has nothing to do with mount point naming
<Mithrandir> mdz: re bug 43687; do you have a suggested mountpoint?  I'm a bit worried that a user exploring the system will end up going in there and fiddling and thereby cause great confusion.
<Ubugtu> Malone bug 43687 in casper "Should make unionfs COW filesystem visible from userspace" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/43687
<Keybuk> and there's no reason to name moint points of removable disks in /etc/fstab
<ivoks> right, hal does that
<Keybuk> right
<Keybuk> so why put them in /etc/fstab?
<iegary> they're in /etc/mtab
<Keybuk> so?
<Keybuk> there's lots of things in /etc/mtab that aren't in /etc/fstab
<ivoks> mtab stands for "mounted filesystems"
<mjg59> pitti: ?
<Keybuk> /dev, /dev/shm, /var/run, /var/lock, /lib/modules/$(uname -r)/volatile
<Keybuk> mtab stands for "why is this file still here? why hasn't it gone away yet?"
<ivoks> :)
<Kamion> Keybuk: I think the point is that the umount script is handling entries with spaces in /etc/mtab wrongly
<Keybuk> ahh
<Kamion> fstab was an incorrect distraction
<Keybuk> I'm reading the bug wrong
<iegary> if we could use "umount -a" it'd all be fine, but we try to keep certain filesystems mounted, so have to parse mtab manually
<Keybuk> yeah, got it now
* Keybuk isn't awake anymore
<Keybuk> the implementation of the patch is kinda icky though
<Keybuk> especially relying on bash
<iegary> Keybuk: the first patch works in dash, but it's equally messy :)
<nomed> hi all
<nomed> i'm not sure if this is a bug ...
<nomed> anyway if i try to install latest lvm2 on a chrooted dapper .. where the host is a sarge i get an error
<nomed> it seems the preinst script uses uname -r
<Keybuk> iegary: the same kind of patch does need to be applied to anything parsing fstab too (which there's a lot of)
<Mithrandir> Keybuk: why aren't people just using getfsent? :-)
<Keybuk> Mithrandir: from shell? :p
<Mithrandir> Keybuk: well, point.
<iegary> Keybuk: okay if you're happy with the format (read -r, sed using multiple -e expressions) then I'll do the patches
<Keybuk> actually, there's an idea here
<iegary> Keybuk: awk would have been handier, but didn't want to add extra dependencies
<Keybuk> a getfsent tool would do the job
<Kamion> a little helper binary to do the unmounting might be appropriate
<Kamion> snap
<Keybuk> likewise getmntent
<infinity> nomed: Doesn't seem buggy to me..
<Keybuk> I would prefer that infinitely to munging stuff with sed, and the numerous backslash behaviours hidden therein
<nomed> infinity, but the previous was working ..
<pitti> mjg59: I mean bug 37181; Kinnison and I just discussed that, we'll do some ugly, but non-intrusive workaround now
<Ubugtu> Malone bug 37181 in dbus "at_console does not adapt to console changes" [Major,Confirmed]  http://launchpad.net/bugs/37181
<infinity> nomed: Why do you need lvm2 in your chroot anyway?
<nomed> i'll diff the preinst script .. of that one
<Keybuk> infinity: logical chroots!
<nomed> infinity, i need it while building my livecd for ex ..
<nomed> but yes .. it's not common i understand
<infinity> nomed: Then you might just want to bite the bullet and install a kernel >= 2.6.12 in the base system.
<pitti> mjg59: i. e. we'll add a 'check-foreground-console' suid root program to libpam-foreground and directly query that in g-{p,v}-m
<infinity> nomed: Lots of packages check kernel versions on installation, it's just unfortunate that this one is biting you today.
* Keybuk wonders how many times this has been tripped on little :p
<mdz> Mithrandir: how about having it on /cow but only if a boot option is specified?  that would be the least risk
<nomed> infinity, ok
<Keybuk> mdz: only if we also have a /gate
<infinity> Keybuk: little (not lithium) doesn't install stuff in chroots.
<infinity> s/not/now/
<nomed> i'd like to check why the previous version was not giving me such problem
<ogra> nomed, a liveCD for ex ? like in /usr/bin/ex ??
<Mithrandir> mdz: that'd work.  I've been toying with ideas like /media/.cow or /casper/cow, but those aren't very pretty, imo.
<infinity> nomed: Because the previous version probably didn't have the kernel version check, and your kernel is << 2.6.12
* Keybuk heads for the shower
<nomed> infinity, that's sure .. :)
<nomed> last question ...
<nomed> i's just like to understand this better ..
<nomed> why udev doesn't check the kernel in such way ?
<nomed> i guess it needs a kver >= 2.6.12 too ..
<infinity> Keybuk: Yeah, why doesn't it? :)
<Keybuk> nomed: because it works with < 2.6.12
<Kamion> klugez: ok, pam 0.79-3ubuntu13 uploaded, correcting the broken nice rlimits; upgrade should be available in about two hours
<Kamion> klugez: thanks again for the report
<Keybuk> well
<Keybuk> I say "works"
<Keybuk> assuming your 2.6.12 initramfs didn't get blown apart
<Keybuk> then the userland fails nicely
<Keybuk>         # We need the uevent support introduced in 2.6.15, bail out if we
<Keybuk>         # don't have it and fall back to a static /dev
<Keybuk>         if [ ! -f /sys/class/mem/null/uevent ] ; then
<Keybuk> so I check whether the kernel has true support, rather than just its version number
<fabbione> infinity: how is the new evdev doing?
<nomed> Keybuk, k thanks
<nomed> thank you all
<Keybuk> the fact that the initramfs gets blown apart is infinity's fault, and he sucks and STILL hasn't fixed it
<klugez> Kamion: wow, that was fast :)
<infinity> fabbione: Not building yet.
<fabbione> infinity: ok 
<infinity> Keybuk: Thpt.
<Keybuk> infinity: now, stop masturbating, and get to work!
<infinity> Keybuk: I'm in the process of fixing several dozen "initramfs blows up on major upgrades" bugs here.  I blame jbailey.
<Keybuk> infinity: I like the ones where you get just enough of an initramfs to print an error message
<Keybuk> but not enough to give you a shell
<infinity> Yeah, those are special.
<Keybuk> wouldn't it be great if rather than having one initramfs, we just had a whole selection of them
<Keybuk> and the boot loader just picked up every little cpio file and joined them all together
<Mithrandir> Keybuk: grub supports it.
<Keybuk> I know :)
<Keybuk> yaboot doesn't though, right?
<Keybuk> then again, yaboot doesn't seem to support booting :)
<Mithrandir> I think yaboot supports booting as an optional extra feature or something.  grub2 should work fine, though.
<carlos> Riddell: hi, I just updated https://wiki.ubuntu.com/MissingPotFiles with more KDE translations domains that lacks the .pot file 
<carlos> Riddell: I think is ok to ignore all those, but If you could check it, that would be really good
<Riddell> carlos: ok, will do
<carlos> Riddell: thank you
<infinity> Keybuk: And with that option, we'd still have to worry about what sort of breakage we're introducing and how.
<infinity> Keybuk: We'd still have the "udev + wrong_kernel = kaboom" problem, regardless of whether the initramfs was modular or monolithic.
<Keybuk> udev-2.6.15-22
<Keybuk> lvm2-2.6.15-22
<Keybuk> easy
<Keybuk> :p
* Keybuk really gets in the shower ...
<Keybuk> ... before he gets killed
<Kamion> Mithrandir: in some theoretical universe where booting isn't an optional feature for grub2 that requires a small scheme program
<Mithrandir> phone
<Treenaks> Kamion: grub2 == emacs?!
<Kamion> scheme is a bit too wussy for emacs
<ogra> Treenaks, the scheme interpreter is only a wrapper for the real lang grub2 is written in, LOGO ! :)
<Keybuk> LEFT 90
<Keybuk> FORWARD 10
<Keybuk> RIGHT 90
<Keybuk> BACKWARD 40
<Keybuk> BOOT
<ogra> yeah
<ogra> and a little turtle icon on the screen while booting ;)
<jsgotangco> logo lol
<Seveas> will edgy have grub2 or is that too evil for even edgy? 
<Kamion> Keybuk: HOKEY-COKEY
<ogra> Seveas, spec it in paris (if you come)
<Seveas> ogra, grub2 scares me
<Seveas> and whether I come to paris depends on sponsoring ;)
<ogra> it can do netbooting, i'd have some ltsp usecases for it :)
<Keybuk> Du machst das hokey cokey und du drehst dich herum, Das ist die ganze sache.
<ogra> hehe
<Kinnison> Ja!
<ogra> yay, perfect germam
<ogra> pitti, does your ibook have a headphone detection in the soundcard ? i just noted that mie seems to have stopped to work
<ogra> *mine
<pitti> ogra: it started to work again with latest kernel
<pitti> but yes, it was broken for a while
<ogra> ah, ok, i probably should get these 300 pending updates :)
<ogra> thanks
<Mithrandir> so, if I switch to tty1 and back, display 1 complains about out of range.  If I do the same, but start usplash first, it works fine.
<looksaus> I'm a bit hesitant to bug you with this one while you people are so busy, but...
* Mithrandir boggles over the nvidia driver
<ogra> Mithrandir, for me it once took 2mins until the console was shown ... its still delayed but only some secs now
<Mithrandir> ogra: that's not a problem for me.
<looksaus> https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067
<Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Unconfirmed]  
<looksaus> I found at least one more person who has this bug
<looksaus> (reported 2006/04/18)
<ogra> Mithrandir, my laptop flatpanel wouldnt show out of range messages
<looksaus> it might be a real showstopper
<ogra> it just stays dark
<looksaus> ogra, pitti , you mention you have ibooks too...
<pitti> well, one :)
<ogra> yes, but see above, i'm heavily outdated
<pitti> looksaus: WFM
<looksaus> WFM == ?
<ogra> works for me :)
<pitti> looksaus: although I didn't upgrade my ibook for a week, too
<pitti> looksaus: I'll do that soon and check
<looksaus> pitti, is there any more information I could give?
<looksaus> or tests I could do?
<infinity> pitti: The bug log claims it's been going on since Flight-3... You'd know if you had the problem.
<ogra> i didnt
<pitti> looksaus: ^ ok, then it definitively doesn't affect me
<infinity> looksaus: Have you tested moving .mozilla out of the way completely and trying with a clean profile?
<looksaus> yes
<pitti> I have flight-7 installed
<looksaus> strange thing, and perhaps most useful is that it seems to be quite deep
<infinity> THat would only be useful if I knew what you meant. :)
<looksaus> epiphany is unstable too, but there the (same?) problem turns up
<looksaus> only after some time
<looksaus> while in firefox, it's really a matter of seconds, as confirmed by Leonardo Pistone
<infinity> But it never crashes, just hangs?
<looksaus> that's correct, see the bug report
<infinity> I saw it, I'm confirming.
<infinity> So, have you tried to strace it to see what it's doing during that hang?
<infinity> Or attach gdb to the process to see precisely where it's hung?
<looksaus> no, I'm sorry, maybe I should do that
<infinity> Given that none of us can reproduce it (if we could, we'd have yelled rather loudly at iwj about it already), any diagnostic info yo ucan find would be great.
<looksaus> I'm unfamiliar with these tools; is there an easy explanation of how to use them?
<looksaus> (for this specific problem)
<infinity> The manpages are good. :)
<looksaus> I know about what they're supposed to do, but I also know they're quite broad tools
<infinity> Otherwise, I'd suspect some people in #ubuntu-bugs (preferably ones that aren't meant to be leaving right now) might be able to help you generate some debugging info.
<looksaus> will just $gdb firefox get me something useful
<ogra> http://wiki.ubuntu.com/HelpingWithBugs is also helpful
<infinity> No, it won't, since firefox is a shell script.
<fabbione> looksaus: firefox --debugger gdb
<looksaus> fabbione, thx
<fabbione> assuming you installed the dbg version of firefox
<looksaus> ok
<fabbione> otherwise it's a useful as running selinux
<sladen> 000
<looksaus> installing the -dbg version
<joelbryan> $gdb firefox-bin, I guess
<Mithrandir> break=casper-boomt != break=casper-bottom
<Mithrandir> I'm not sure how that came about.
<infinity> boomt!
<ogra> heh
<ogra> nice typo
<looksaus> fabbione, joelbryan , I used https://wiki.ubuntu.com/DebuggingFirefox
<looksaus> but firefox doesn't seem to start
<looksaus> just gdb...
<looksaus> I tried to follow these instructions to the letter, with more or less an idea of what they should do...
<looksaus> any hints welcome...
<ogra> typing run in the gdb prompt might be helpful :)
<looksaus> sorry, me very unexperienced at this
<Mithrandir> so, just doing rm -rf on the underlying file system does confuse unionfs
<ogra> thats evil
<Mithrandir> doing that to unionfs?  I agree
<ogra> also that unionfs doesnt pick it up
<fabbione> Keybuk: do you have any idea what a vbi device is?? something related to v4l.. but i have never seen it before
<looksaus> #40067
<looksaus> oops
<nomed> Mithrandir, "ls -l /proc/1/" is it correct for you?
<ogra> fabbione, thats for digital TV
<nomed> on a livefs ...
<looksaus> https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067/+index
<Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Unconfirmed]  
<looksaus> attached gdb output
<Mithrandir> fabbione: http://www.thedirks.org/v4l2/v4l2dsi.htm
<fabbione> ogra: ok thanks...
<Mithrandir> nomed: ECONTEXT
<looksaus> ogra, this looks like very little output, did I do this right?
<fabbione> Mithrandir: danke...
<fabbione> now i wonder why i don't have one
<fabbione> of that device
<ogra> looksaus, if it crashed you need to type bt to get a backtrace
<looksaus> ogra, sorry if I need so much hand holding, thx for your help
<ogra> fabbione, you usually get your EPG data through that device 
<mvo> Kamion: what should the debconf frontends (kde,gnome) do when cancel is pressed (or closed by the wm)? just return with zero exit status? or  non-zero exit status because the debconf transaction was not completed? 
<fabbione> ogra: i have a simple TV tuner.. i just don't understand why the device is not there.. or if it needs to be there at all
<ogra> (not sure if it was used in the pre digi aera already)
<nomed> Mithrandir, if i'm not wrong /proc/1/exe is a links to unionfs branch init
<nomed> and i do not know if there are other links like this ..
<nomed> that's the only one i've seen ..
<mvo> Kamion: I ask because some people are interessted in using a debconf note as a sort of "license display and agreement" screen
<Mithrandir> nomed: I can tell you in about ten minutes, I need to redo the live cd a bit.
<mjg59> mvo: I think some people should be hunted down and "encouraged" not to do that
<ogra> fabbione, ogra@edubuntu:~$ ls -l /dev/vbi0
<ogra> crw-rw----  1 root video 81, 224 2006-05-07 14:24 /dev/vbi0
<ogra> fabbione, if you need tests or something
<ogra> (but thats breezy currently)
<fabbione> ogra: no thanks.. i am only trying to understand if it is something i am supposed to have or not
<mvo> mjg59: I'm with with that if that is the "official" position of the debconf team, I just wanted to have it clarified
<fabbione> ogra: upgrade to dapper and see if it is still there...
* mvo thinks of way how people could be "encouraged" 
<ogra> fabbione, at least its available in breezy on my cheapo wintv pci
<ogra> will do
<mjg59> mvo: Who wants to do that?
<fabbione> ogra: mine is a cheap wintv too.. that's why
* ogra tries a dapper live
<mjg59> You can't realistically use debconf stuff for license agreements, since (a) it may be run non-interactively, and (b) it only requires the admin to agree, not any of the users
<Mithrandir> Riddell: does the patch in 
<Mithrandir> Riddell: http://librarian.launchpad.net/2544675/disable_update_notifier.diff make sense?
<Mithrandir> or, is correct for kubuntu or something
<mvo> mjg59: right, especially the non-interactive case is a big problem with that approach
<Riddell> Mithrandir: looks good to me
<looksaus> ogra, this better:
<looksaus> https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067/+index ?
<Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Unconfirmed]  
<mdz> Mithrandir,infinity: Colin and I just had an idea about l-r-m on the live CD, that it could be disabled when booting in safe mode
<Kamion> mvo: back up, I think
<mdz> since that's a natural fallback for the user to try if it doesn't work
<hile> Hi, I have a small script to detect serial port's UART for udev, could it make it to dapper udev package?
<elmo> mjg59: the non-interactive case is trivial, you just refuse to install
<Kamion> mvo: at any rate you should get non-zero back from db_go, not that I've tested this
<elmo> mjg59: the admin vs. users thing is more of a problem, but I've talked to vendors who were happy with debconf for agreement even with that caveat
<Kamion> mvo: although I never ever want to see anything that does this in main or universe
<looksaus> ogra, sorry, have to go, will be back
<looksaus> thx for your help!
<elmo> (but I do generally agree, prompting when you run the program is better when possible and it makes sense)
<mvo> Kamion: ah, nice, I'll test this. In the source of the gnome/kde frontend it just seems to exit (without any special exit code)
<hile> it goes to /lib/udev/serial_uart, http://ner.dy.fi/serial_uart - not linked anywhere, but if UART is needed you could use IMPORT{program}="serial_uart %p" fro rules
<zul> heylo
<mvo> Kamion: its for a multiverse package (that I'm not working on myself I may add :P)
<hile> of course uart reallyshould be available in sysfs, but that requires kernel patch AFAIK so it's the slow route
<Kamion> Mithrandir,infinity: (safe mode is 'xforcevesa' on cmdline at the moment, although that can be changed)
<Kamion> mvo: hmm, I think the confmodule will probably get SIGPIPEd then
<hile> I'll file a bug against udev anyway, just wanted to ask if the script has slightest change to make it into dapper
<mvo> elmo: right
<Kamion> mvo: either that or read will fail and it'll hopefully fall over due to 'set -e'
<Mithrandir> mdz: hmm, but often it'll start X well enough and then just fail randomly in ubiquity somewhere, won't it?
<Kamion> Mithrandir: yeah, it's just a convenient place to put the boot option
<Mithrandir> Kamion: I don't think I wouldn've connected the dots for "system works for a while, then falls over" and "safe mode".
<Kamion> mdz: do we still have time to add stuff to the CD sleeve? I'm guessing not ...
<TheMuso> 
<mdz> Kamion: no
<Kamion> thought not, shame
<infinity> mdz: Sounds reasonable to me.
<Kamion> mvo: normally a question like this ought to be boolean, so you should have yes/no buttons
<Kamion> (aside from yes/no being poor UI in general, but we don't have a mechanism to change that at the moment; maybe in future)
<infinity> Mithrandir: I dunno.. "it breaks" pretty much always leads to "look for something less broken", and "safe mode" sounds like it could work.
<Mithrandir> infinity: maybe.  It does say "safe graphics" at the moment, though, so we might want to change it to just "safe mode"
<mvo> Kamion: gnome renders it as a checkbox with a "help" button next to it
<mdz> Mithrandir: yes, I suggested that
<Mithrandir> Kinnison: how can I tell a system that it shouldn't show the hibernate option?
<Kinnison> Mithrandir: In what sense?
<Mithrandir> Kinnison: bug 23882
<Ubugtu> Malone bug 23882 in casper "Hibernate option should be suppressed on the live CD" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/23882
<Mithrandir> Kinnison: we won't have a hibernatable live cd for dapper, so it would be nice to not show the option
<seb128> could be stop that "GNOME Desktop, Settings and Metacity Optimization" guy? maybe unsubscribing him from the lists or something?
<ogra> yeah
<ogra> pretty please
<seb128> there is no proof his scripts do anything
<Kamion> mvo: oh, sigh, the gnome frontend isn't so great sometimes :-/
<Kinnison> Well, for g-p-m (and thus soon the logout dialog) do gconftool-2 --set --type bool /apps/gnome-power-manager/can_hibernate false
<Kinnison> Mithrandir: ^^
<ogra> the crossposting is most annoying
<Mithrandir> Kinnison: ok, thanks.
<seb128> and he's pushing users to try non-tested stuff that could damage their config
<ogra> yep
<seb128> for no win
<Kamion> Mithrandir: I can change the text, sure, though I'll have to check up with translators
<Kinnison> Mithrandir: or the appropriate rule for doing that as root if you need to do it during prep
<AlinuxSOS> hello Dear people, what is the name of Espresso Live Installer in ubuntu ?
<seb128> Kinnison: oh, there can_... keys? Now I know how to try properly the session dialog :)
<infinity> AlinuxSOS: Ubiquity.
<Kinnison> Mithrandir: gconftool-2 --direct --config-source xml:readwrite:/var/lib/gconf/defaults --set --type bool /apps/gnome-power-manager/can_hibernate false
<Kamion> Mithrandir: would you mind taking a look at oem-config and trying to fix it up a little bit for dapper? I've had very little time to look at it this release, and it's bitrotted a bit
<Kinnison> Mithrandir: that would work as root (pre desktop boot)
<seb128> Kinnison: I was wondering how to test the suspend since my box doesn't do it according to g-p-m :)
<AlinuxSOS> I'll start translating debian-installer to get Georgian language in Espresso too :)
<Kinnison> seb128: :-)
<Mithrandir> Kinnison: I call gconf-tool as the user already so I'll just copy that.
<AlinuxSOS> infinity, thank you pal :)
<Kinnison> Mithrandir: okies
<Mithrandir> Kinnison: is --direct quicker?
<Kinnison> Mithrandir: No
<Kamion> AlinuxSOS: espresso no longer exists; it was only ever called that in Ubuntu, and it's been renamed in Ubuntu now
<Kinnison> Mithrandir: It just can be done to adjust the defaults before the desktop boots for the first time
<Kinnison> Mithrandir: I use it in the postinst to enable suspend if the machine is whitelisted
<Kamion> AlinuxSOS: so get used to talking about ubiquity instead :)
<AlinuxSOS> Kamion, ok Ubiquity :)
<AlinuxSOS> what's the meaning of Ubiquity :)
<Mithrandir> Kinnison: 'k, thanks a lot.
<Kamion> Mithrandir: I think the worst bit in oem-config is probably the way that the first run of localechooser fails
<AlinuxSOS> As Espresso Caffe lover :) I loved that name :)
<Kinnison> Mithrandir: no problem
<Mithrandir> Kamion: I'll just finish my casper bugfixing bonanza, but after that, sure.
<Kamion> AlinuxSOS: it's an English word meaning "the state of being everywhere", which is pretty much what we want Ubuntu to be; furthermore it has some similarity to the name "Ubuntu", which is something Mark wanted
<AlinuxSOS> ;)
<AlinuxSOS> ok I like Mark's desition
<AlinuxSOS> so let's georgianizeit :)
<ogra> fabbione, my dapper liveCD has a /dev/vbi0 as well
<Kamion> the name shouldn't be (or need to be) translated; it isn't presented to users
* Mithrandir tries StR on the live cd.
<AlinuxSOS> Kamion, no I mean the rest :)
<Mithrandir> Kinnison: hmm, should I possibly just forcefully reconfigure g-p-m to make it see if the machine can StR too?
<Kamion> Mithrandir: thanks, much appreciated
<Kinnison> Mithrandir: Sure, you can do that
<Kinnison> Mithrandir: providing it's before the desktop starts
<Mithrandir> Kinnison: it's from the initramfs.
<Kinnison> Mithrandir: otherwise there's the risk of the user's gconf blocking the backend
<Mithrandir> so, StR didn't work too well on my amd64 at least.  I guess I'll look at that another time.
<infinity> Keybuk: I just subscribed you to bug 43470 ... Could you have a look?
<Ubugtu> Malone bug 43470 in mozilla-thunderbird "Package includes empty /tmp with wrong permissions" [Major,Confirmed]  http://launchpad.net/bugs/43470
<seb128> Kinnison: can_suspend does nothing
<HiddenWolf> seb128: why don't you point that guy at gnome-performance list? :)
<seb128> Kinnison: the notify area icon doesn't list suspend action even if I use it
<HiddenWolf> seb128: I would, but not subscribed right now.
<Mithrandir> seb128: twiddling it worked for me just on the live cd now.
<seb128> Mithrandir: maybe because you box can do suspend?
<seb128> I'm on a desktop atm ... :)
<sivang> Keybuk: recall that SoC I sent you a link to ? would you mind discussing this a bit with pygi ? maybe you could toss an idea what could make this SoC worthee..
<Mithrandir> seb128: this is on my amd64 desktop
<seb128> Mithrandir: hum ...
<pygi> hi Scott
<seb128> so, can we stop that guy who try to push broken scripts to users by some way?
<seb128> if somebody breaks his gconf base by playing with it they will likely to have to reinstall their box
<HiddenWolf> seb128: he'll just move it to the forums or the wiki when he's told to bugger off from -devel. 
<Kinnison> seb128: if hal doesn't think you can suspend it may not turn on
<seb128> Kinnison: k, that's probably the case, works fine on my laptop
* Riddell wonders why cvs is still in ship
<seb128> Kinnison: if new gnome-session works fine on it I'll upload rsn :)
<Kinnison> Rock on
<Kinnison> seb128: you're a star
<seb128> thanks to lmanul too who worked on that too ;)
<seb128> and thank you for the tips making that easier ;)
<Riddell> Kamion: powerpc in today's kubuntu/daily-live is 701MB but doesn't get an oversized warning, do that mean it's OK?
<jordi> Kamion: hey
<jordi> Kamion: how are you doing with the ubuntu book?
<Mithrandir> Riddell: you might want to tell me if and how I should disable hibernation on the kubuntu cds too.
<Riddell> we don't like people hibernating their live CDs?
<Mithrandir> Riddell: it's not supported yet; there's no usable UI for getting back to your session
<Riddell> Mithrandir: "dcop kded kded unloadModule klaptopdaemon"
<Riddell> although that'll only work after kde is running
<Mithrandir> Riddell: well, so a bit too early to do from the initramfs. :-)
<Riddell> rm /usr/share/services/kded/klaptopdaemon.desktop  will work too
<azeem> there used to be a wiki page with laptop support status in the past, is there one for dapper?
<azeem> or, asking differently, is there a known status for the T60?
<Mithrandir> Riddell: klaptopdaemon is only useful for hibernation, not StR or other laptop tasks?
<Treenaks> azeem: still the same place: LaptopTestingTeam
<azeem> Treenaks: thanks
<Riddell> Mithrandir: StR?
<Mithrandir> Riddell: suspend to ram.
<sladen> azeem: http://wiki.ubuntu.com/LaptopTestingTeam
<Mithrandir> Riddell: there's no reason for that not to work on the live cd.
<azeem> ok, so a coworker now got a T60 and installed Kubuntu on it.  Should I tell him to add to that page, or is somebody else keeping an eye on that model?
<Riddell> I see, in that case this should do it  sed -i s/EnableHibernate=true/EnableHibernate=false/ /usr/share/kubuntu-default-settings/kde-profile/default/share/config/kcmlaptoprc
<sladen> does kalptopdaemon do anything else useful like making other useful lapyopy things work?
<infinity> azeem: The more info the better, by all means, ask him to contribute.
<azeem> ok
<infinity> azeem: We'd all like to see good out-of-the-box support with the T60 and X60, but few of us have managed to get our hands on one yet.
<sladen> azeem: more eyes the better;  yes, please ask him to add his details to the top in additional and then fire away with testing the latest status
<infinity> (I'm waiting for a tax return before I can justify my purchase)
<Riddell> Mithrandir: ^^
<Mithrandir> Riddell: ok, thanks.
<sladen> azeem: like infinity says, the hardware is fairly rare and hard to get hold off, so more testing and reports the better
<Mithrandir> mm, 80 character long file names
<mjg59> azeem: Breezy is not likely to work that well. Dapper will be somewhat better.
<mjg59> But all sorts of stuff is still likely to be broken
<infinity> Mithrandir: Were trying to break the line into smaller chunks and gave up? :)
<Mithrandir> infinity: I was slightly puzzled at the repeated "share" and what "default" does in there, but I don't think I'll fight that windmill today.
<Kinnison> lunchtastic, back later
<azeem> mjg59: he installed dapper
<infinity> Also, why am I getting 2 of every list mail?
<mjg59> azeem: Ok, cool
<azeem> fglrx seems to work, the default X configuration with the ati driver didn't apparently
<mjg59> infinity: It's ones which are Cced to -users
<mjg59> azeem: Yeah. Blame ATI.
<azeem> we do :)
<infinity> mjg59: Yeah, but I'm filtering both into different folders, so this is bizarre that I'm seeing two in the -devel folder.
<infinity> Oh, and another in -users.
<infinity> So, I'm getting 3.  Rock.
<mjg59> infinity: I know. I'm getting the same problem
<infinity> I blame jdub.
<infinity> Or Mithrandir.
<Treenaks> azeem: anything like bug 20283?
<Ubugtu> Malone bug 20283 in xserver-xorg-driver-ati "[fgl v5000]  really bad sync" [Normal,Needs info]  http://launchpad.net/bugs/20283
<azeem> Treenaks: I think it's another chip, and I have to ask him about how exactly X.org failed
<mjg59> The ati driver doesn't support the newer chips
* Treenaks shakes his fist at video card manufacturers
<mjg59> Treenaks: Argh, that still isn't fixed?
<Treenaks> mjg59: no
<mjg59> Treenaks: Have you had a chance to test radeontool?
<mjg59> (and the registers I suggested)
<highvoltage> Treenaks: join RMS against ATI!
<mjg59> Nvidia's just as bad. Get Intel hardware if you're getting a laptop...
<azeem> the thinkwiki talks about installing an SMP kernel for the Core Duo, but AFAICT the regular kernel now suppors SMP as well, right?
<Treenaks> highvoltage: I think nvidia is worse, as the 'ati' driver does 3D just fine on my older cards (and the 'nv' driver doesn't even try)
<mjg59> azeem: The -386 one doesn't, no
<azeem> ah, ok
<azeem> makes sens
<azeem> e
<mjg59> Just install linux-image-686
<azeem> yeah, he got told to install linux-686-smp which nowadays doesn't seem to do anything else
<Treenaks> mjg59: I've tried, but I'm scared of breaking stuff by poking those registers
<Kamion> Riddell: depends whose megabytes you're counting
<mjg59> Treenaks: Just setting them to the values used in fglrx won't damage the hardware
<mjg59> The screen may look disturbing, but you can't damage LCDs by doing this
<Kamion> Riddell: the limit for our pressed CDs is 736051200 bytes; the limit for 700MB CD-ROMs according to Wikipedia is 737280000
<highvoltage> MiB is millions of bytes, and MB is that 1024x1024x1024 thing, iirc
<Kamion> Riddell: current Kubuntu daily-live powerpc is 735129600
<Kamion> jordi: about half-way through; I've spotted a few errors but I like the general style and approach
<infinity> azeem: s/linux-image-686/linux-686/ to get LRM as well (which he'll almost certainly want so he can install fglrx to drive the shiny new Radeon in there)
<_ion> highvoltage: MiB is 2^30 B, MB is either 10^9 B or 2^30 B depending of the context.
<azeem> infinity: linux-686-smp depends on -restricted, so that's fine
<Riddell> Kamion: ok, nice
<Kamion> highvoltage: yeah, but it's actually a bit over 700MiB
<infinity> azeem: yeah, but mjg59 said linux-image-686, hence my correction.
<infinity> azeem: linux-686-smp is just a transitional package to get linux-686 anyway.
<azeem> yeah, I thought so
<Kamion> 80mins approximates to 703.1MiB
<infinity> Or, rather, it should be, but appears to depend on the next level down.  That should be fixed, perhaps.
<highvoltage> _ion: aah, thanks :)
<mjg59> Treenaks: If you could give that a go at some point in the pretty immediate future, we can try to work out what's wrong
<stub> Launchpad will be going down in 30 minutes for a regular code update. Estimated down time will be 15 minutes. Wikis will be in read only mode during this period.
<Treenaks> mjg59: OK
<AlinuxSOS>  debian-installer-utils can you explane me shortly what utility have this package ?
<AlinuxSOS> and if it needs translation ?
<bddebian> Hello devels
<`6og> gday
<Kamion> AlinuxSOS: yes, it has some strings that need to be translated; it's various miscellaneous installer utilities
<AlinuxSOS> Kamion, why some string ?
<Kamion> apt-get source debian-installer-utils if you're interested. I'd rather not end up answering similar questions for every one of the 50+ installer packages :)
<Kamion> the debian-installer translation file is in rough order of importance; please just translate as much as you feel you can
<AlinuxSOS> Kamion, :)
<AlinuxSOS> ok understood :) I'll translate 100% both
<AlinuxSOS> to be secure :D
<AlinuxSOS> now importing from Lauchpad.
<AlinuxSOS> Kamion, in debian-installer-utils there is only 10 string :D
<AlinuxSOS> great :D
<ogra> ARGH !!!
<ogra> can please someone unsubscribe that crossposting guy from the mailing lists !!!!
<ogra> he posted again to 5 lists
<jsgotangco> yeah
<jsgotangco> i'm getting pissed too
<ogra> and gives bad advise on -users attaching scripts that potentially break your system 
* bddebian supposes he better request deps for libkwiki-perl
<zul> ogra: the welcome center crap?
<ogra> yeah
<pitti> Kinnison: I ported g-v-m to check-fg-console, works great!
<ogra> after he posted tons of crappy gconf things 
<zul> ogra: ok idea bad approach
<ogra> i dont care about the idea at all, its just annoying to have such horrible multiML posts
<zul> true..
<ogra> and he was told to stop it plenty of times
<ogra> ask seb128 
<AlinuxSOS> so once done debian-installer, we need a terminal font right ?
<AlinuxSOS> monospaced bitmap font.
<jsgotangco> he's trying to catch the eye of people, albeit in a twisted way, hopefully unintentional
<ogra> he's also not reacting on warnings from seb128 that his stuff might break user setups in a way they have to reinstall worst case
<ogra> thats pretty odd
<seb128> and he has no numbers to argue on his "speedup"
<ogra> yep
<Treenaks> arnieboy#2?
<ogra> Treenaks, nah, arnieboy does that intentional, this guy just doesnt get it i suspect
<jsgotangco> he is a local here, but have not met him personally, but he hangs out in our loco channel sometimes, i'll give him some advice when he comes
<bddebian> Who wants to give me some advice? :-)
<jsgotangco> bddebian: outlander!
<bddebian> jsgotangco: Welcome Traveler
<siretart> sladen: regarding this segfaulting xair bug: it happens to me on plain i810
<ogra> bddebian, first you need to crosspost to at least 5 lists, then WE'LL GIVE YOU ADVISE ! har har
<bddebian> ogra: :-)
<siretart> sladen: I wanted to reopen that bug but exactly in that sec lp gives me 503 :(
<bddebian> Yeah it died on my before I could get my bug list for the day too :-)
<bddebian> siretart: Hey good, could you take a look at xcircuit on REVU then? :-)  I'm about to request a UVFe for it.
* ..[topic/#ubuntu-devel:ogra] : 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 | Flight-7 released | LP down for 15 min
* ..[topic/#ubuntu-devel:ogra] : 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 | Flight-7 released | LP down for 15 min
<ogra> oops sorry for the double <enter>
<Kinnison> pitti: rock on
<siretart> bddebian: I have a horrible backlog of unchecked UVFs currently :( - I won't do any promises
<bddebian> :-)
<AlinuxSOS> To get "Georgian" listed at first boot of Ubuntu CD, Georgian team must translate debian-installer debian-installer-utils... something other ?
<AlinuxSOS> I'll import them into rosetta.
<sladen> siretart: are you sure it's not one of the /other/ bugs that is i810 dieing if you're seeing it?
* ..[topic/#ubuntu-devel:ogra] : 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 | Flight-7 released
<ogra> LP is back
<bddebian> Aye
<bddebian> Already giving others more work ;-)
<zakame> hi all
<zakame> coolness
<siretart> sladen: I'm not sure yet if it is i810 thats dying for me. I'm currently not at home, will be there in a few hours
<jdub> mjg59: ping
<Mithrandir> doko_: any chance you could take a look at 3919?  You've been touching that lately.
<AlinuxSOS> can I get somewhere ubiquity-s screenshots ?
<bddebian> Oh, I like the new binary package hint on LP :-)
<Keybuk> I don't
<Keybuk> it annoys the frak out of me
<bddebian> :-(
<Keybuk> unless there's a newer new binary package hint
<mjg59> jdub: Hi
<nomed> Mithrandir, sorry .. i've been AFK for a while ..
* ogra doesnt even see a binary package hint
<nomed> did u check that proc issue ?
<ogra> where is that ? 
<ol> aha, just who I'm looking for...
<ol> nomed: come to talk about debian/ubuntu xapian packaging
<ol> sorry it's taken me a while...
<Mithrandir> nomed: it points to /rofs/sbin/init, which is correct.
<nomed> Mithrandir, yes ..
<nomed> but i was reading such links ..
<nomed> not pointing to /unionfs/root
<nomed> may cause problems with apps like mono
<nomed> i can't explain exactly the reason ..
<nomed> as i've never used it ..
<nomed> but ubuntu uses mono ..
<Mithrandir> nomed: why should that be a problem for mono?
<tseng> (what?)
<nomed> Mithrandir, it was a discussion on unionfs mail list
<nomed> i have to admit i didn't get it really .. 
<tseng> yeah I have no idea what you are talking about
<nomed> but some ppl that uses mono have had problems related to such links
<nomed> tseng, i try to find the link ..
<tseng> mono isnt even on the livecd, if thats what you are talking about
<nomed> if you 're involved in mono ..
<nomed> i'd like to understand better such "issue"
<nomed> tseng, k
<tseng> I am not sure why you are here telling us about an issue that you cant even explain
<tseng> but I'd be happy to have a look
<nomed> tseng, just because i asked to Mithrandir if that link was fine as it is
<nomed> and because if such links on an unionfs mount point may cause problems in general ..
<tseng> ok.
<nomed> as it differers from a normal installed system
<tseng> is there a confirmed bug?
<nomed> tseng, try to find that link ..
<Mithrandir> nomed: I don't see why it would cause any kind of problem
<highvoltage> Keybuk: real clever marking #36599 as duplicate of #1 :)
<bddebian> tseng!! :-)
<tseng> bddebian: hi
<nomed> Mithrandir, i don't see it too ..
<nomed> anyway here is the link ..
<nomed> http://www.fsl.cs.sunysb.edu/pipermail/unionfs/2005-December/001474.html
<nomed> Mithrandir, that's why i'm asking :)
<Keybuk> highvoltage: I couldn't think of any other bug number to do it to
<Keybuk> admittedly I had 1 thru 36599 to choose from
<Keybuk> but hey, look at the time I did it
<Keybuk> a bit later on, it made more sense to mark it as a duplicate of the malone bug that was causing me to need it to mark it as a duplicate of *something* in the first place :)
<highvoltage> hmmm... it was 8:38 my time, so your local time would have been... 7:38
<nomed> ol, may you join #xubuntu ?
<ol> nomed: sure
* ol leaves here too...
<Mithrandir> nomed: I'm not sure why mono should care, though I do see the point of s-s-d, but well, not many people upgrade their live cds and have daemons on them.
<pitti> ogra: do you use fuse in edubuntu?
<ogra> pitti, not by default, but the localdev ltsp stuff does, so users need it
<pitti> ogra: there are two issues (bug 32843 and bug 5774) which are apparently fixed by 2.5.x
<Ubugtu> Malone bug 32843 in fuse "warning: unknown option - wrong library version?" [Normal,Unconfirmed]  http://launchpad.net/bugs/32843
<Ubugtu> Malone bug 5774 in fuse "uninstalling fuse-utils removes group 'fuse' then tries to use it" [Normal,Confirmed]  http://launchpad.net/bugs/5774
<pitti> ogra: the first bug claims that 2.4 doesn't work at all for us; do you have any problems with it?
<ogra> i dont use it, localdev was postponed to eft
<ogra> and none of my edubuntu users use it either currently 
<pitti> ogra: in main, only linux-ntfs build-deps on it to build ntfsprogs
<ogra> ltsp will depend on it in eft in any case 
<pitti> ogra: ok, so it wouldn't disrupt you if I requrested an UVF exception?
<pitti> ogra: I'll try out fuse myself now and check if 2.5 works any better/worse
<ogra> and if users want to set up localdev in ltsp now, they should get a working fuse
<ogra> so yes, UVF exception would be nice 
<Mithrandir> I might actually want fuse in desktop for eft, jfyi.
<Diziet> Do we have a tool to take two directory trees that are supposed to be identically laid out, and 1. check to see whether they have any overlapping leaf nodes and then 2. merge them into one directory ?
<pitti> Mithrandir: yes, right now I'm mainly concerned about what I could potentially break
<ogra> Diziet, baobab ? 
<pitti> ogra: wow, there's a tool for anything :)
<ogra> heh
<ogra> dunno if it does merging though
<ogra> but its good for comparing
<Diziet> Err, no, a tool, not an application.
<Diziet> I don't want it to have a UI :-).
<ogra> arent applications just big tools ?
<doko> Mithrandir: the "every time is adding a hyperlink" thing could be fixed after building the amd64 packages with today's i386 upload
<doko> I never could reproduce the crashes
<Mithrandir> doko: ok.  :-/
<Diziet> Hrm.  Well, I could (for 1.) sed the output of find -print0 and then feed it to grep -F and (for 2.) use cp.
<infinity> Diziet: tree foo > foo.out ; tree bar > bar.out ; comm -3 foo.out bar.out
<Keybuk> comm -3 <(tree foo) <(tree bar)
<infinity> Diziet: For merging, "cp -a foo/* bar/" will happily merge one to the other.
<bddebian> Heya infinity
<Diziet> infinity: That (the rune with comm) would work except if the filenames contain newlines.
<Diziet> And you don't want tree, you want find.
<Diziet> Err, I think.
<pitti> Keybuk: I just installed fuse-utils which brought an udev rules file. How can I poke udev to run it?
<pitti> Keybuk: (it's supposed to create /dev/fuse)
<ogra> modprobe fuse ?` 
<infinity> Diziet: Filenames with newlines scare me. :)
<pitti> ogra: well, that apparently didn't obey the udev rule...
<Diziet> Yes, me too, but they exist - in packages - nowadays :-/.
<pitti> ogra: anyway, the dev is there now, thanks
<infinity> In packages?
<Keybuk> pitti: udevplug
<infinity> Ones we can't remove from the archive?
<Diziet> Apparently.  I remember seeing someone make dpkg not break in that case.
<Keybuk> pitti: ideally just udevplug <sysfs path of fude>
<infinity> Diziet: Making dpkg not break in that theoretical case is a far cry from "Debian or Ubuntu ship packages with files containing newlines"
<Diziet> (Although come to think of it I don't remember whether that patch ever made it into anyone's distro.)
<infinity> Diziet: I'd be inclined to FILE BUGS IN UPPERCASE on packages that actually did...
<ogra> and uppercase halps ? 
<ogra> *helps
<pitti> Keybuk: hm, neither 'udevplug /sys/module/fuse' nor 'udevplug module/fuse' seems to work; but thanks, I'll play with it
<Diziet> infinity: Well, if you reckon that's our policy then the answer is indeed easy :-).
<giftnudel> you get attention, may be not the one you like, but you get some
<Keybuk> pitti: what's the udev rule?
<infinity> ogra: I find it's helpful to let people know when they've really pissed you off (like, enough that you'd buy a plane ticket just to slap them)
<pitti> KERNEL=="fuse", GROUP="fuse"
<pitti> Keybuk: ^
<Keybuk> that's just a permissions rule
<pitti> Keybuk: but it's still root:root
<Keybuk> right
<Keybuk> quest scott% sudo modprobe fuse
<Keybuk> UDEV  [1147360209.916922]  add@/class/misc/fuse
<pitti> I can chown it by hand, but if I'm working at the package anyway, I can as well fix that
<Keybuk> DEVNAME=/dev/fuse
<Keybuk> that works
<Keybuk> oh
<Keybuk> no, sorry
<Keybuk> yes, that works
<pitti> yes, the device is created properly, but it's root:root
<pitti> $ getent group fuse
<pitti> fuse:x:119:martin
<pitti> and the group should be fine
<Keybuk> ok
<Keybuk> that's a little odd
<infinity> Diziet: I can't immediately find a Policy reference to newlines in filenames not being allowed, but no Policy reference doesn't make it any less stupid, IMO.
<infinity> Diziet: I'd be surprised if you found one, and doubly-surprised if any maintainer argued with a bug being filed against their package for shipping such an abomination.
<Keybuk> oh
<Keybuk> what created the fuse group?
* pitti only saw this case in attempts to fool backup scripts and similar vulnerability exploits
<pitti> Keybuk: the fuse-utils postinst
<Keybuk> pitti: right :)
<Keybuk> so the group didn't exist when udev started
<Diziet> infinity: Fair enough :-).
<pitti> Keybuk: yes
<Keybuk> so getgrent will have cached the old file
<Keybuk> quest scott# echo 'KERNEL=="fuse", GROUP="scanner"' > /etc/udev/rules.d/41-fuse.rules
<pitti> Keybuk: I think rebooting might even fix it, I just wondered if it was possible to make it work OOTB
<Keybuk> quest scott# udevplug /class/misc/fuse 
<Keybuk> quest scott# ls -l /dev/fuse
<Keybuk> crw-rw---- 1 root scanner 10, 229 2006-05-11 16:11 /dev/fuse
<pitti> cool
<pitti> ok, so it'll work after a reboot
<Keybuk> (yay, UNIX)
<pitti> Keybuk: blunt workaround: chgrp fuse /dev/fuse in postinst :) 
<pitti> (and a modprobe before that)
<Keybuk> right
<Keybuk> modprobe or udevplug
<pitti> Keybuk: ok, thanks, mate
<Keybuk> in case the module was already loaded
<Keybuk> given it comes with the kernel, not fuse-utils
<pitti> yep
<Keybuk> actually, you don't need the udevplug -- just modprobe
<pitti> Keybuk: anyway, this 'create a new group for a future device' use case seems to be interesting beyond fuse
<Keybuk> pitti: no way around it other than killing udev
<Keybuk> and if you do that, you have to do a new udevplug
<pitti> ok, better not then :)
<Keybuk> so 3 minute postinst <g>
<Keybuk> you could ask jbailey to make glibc suck less
<pitti> $ sshfs piware.de:home/martin server
<pitti> slick :)
<ogra> yeah
<ogra> fuse is cool
<pitti> the directory entry is even cooler
<ogra> now tunnel it through ssh ;)
<Kamion> Mithrandir: isn't 42574 an install CD bug, not a desktop CD bug?
<pitti> ?---------   ? ?      ?          ?                ? server
<Kamion> Mithrandir: so not ubiquity?
<Keybuk> oh, I wonder
<pitti> ogra: meh? sshfs *is* ssh, isn't it?
<Keybuk> pitti: could you try invoke-rc.d udev reload
<ogra> err, oops, sorry, indeed
* ogra blushes
<Keybuk> and see whether you can udevplug /class/misc/fuse now
<pitti> Keybuk: ok, I chgrp the file back
<Mithrandir> Kamion: indeed, I'm blind and probably silly because it was filed against casper.
<pitti> bah, telephone, brb
<Mithrandir> Kamion: fixed
<Kamion> ta
<pitti> Keybuk: uh:
<pitti> $ sudo invoke-rc.d udev reload
<pitti>  * Reloading kernel event manager... No /sbin/udevd found running; none killed.
<pitti>                                                                                                                                                                              [fail] 
<pitti> invoke-rc.d: initscript udev, action "reload" failed.
<\sh> BenC: ping 
<ogra> pitti, ouch
<pitti> Keybuk: udevd is running, though
<pitti> root      2238  0.0  0.1  11004  1300 ?        S<s  08:31   0:02 /sbin/udevd --daemon
<Keybuk> bah, just -HUP it
<\sh> or does anybody have problems building a kernel package from linux-source-2.6.15_2.6.15-22.34 with make-kpkg?
<Keybuk> yay crappy s-s-d
* Mithrandir wanders off to make some food and such.
<pitti> Keybuk: yep, that worked
<pitti> Keybuk: create group, HUPing udevd, modprobe, udevplug
<Keybuk> pitti: wasn't getgrent that cached it, udev converted it to an id when it parsed the file
<Keybuk> and it parses the file when it's written to disk
<pitti> (final udevplug is not necessary)
<carlos> doko: hi, around?
<doko> carlos: yes
<Keybuk> pitti: right, the modprobe will do the trick
<Keybuk> hmm, actually
<Keybuk> no, you want the udevplug
<Keybuk> just in case they already had the fuse module loaded, and the device with the wrong group
<pitti> so, I want both
<Keybuk> I'd do modprobe --first-time fuse 2>/dev/null || udevplug /class/misc/fuse
<Kamion> damn, sshfs is scary
<Keybuk> ie. modprobe it, or tickle it again
<pitti> Kamion: right now it just doesn't work at all for me
<pitti> Kamion: might be due to bug 32843
<Ubugtu> Malone bug 32843 in fuse "warning: unknown option - wrong library version?" [Normal,Unconfirmed]  http://launchpad.net/bugs/32843
<ogra> Kamion, hey, dont say that, you scare me ... i'll have to handle it in eft
<pitti> ogra: bah, sshfs seems to work neither with the current dapper nor with the sid fuse
<ogra> pitti, the 2.4 or 2.5 one ? 
<pitti> ogra: both
<ogra> bah
<pitti> fuseiso seems to work
<ogra> iirc ltspfs doesnt use sshfs currently 
<ogra> only plain fuse stuff
<pitti> ogra: ah, now it works. PEBKAC
<ogra> :)
<ogra> ogra@edubuntu:~$ apt-cache show ltspfs|grep Depends
<ogra> Depends: libc6 (>= 2.3.4-1), libfuse2
<ogra> yep, doesnt use ssh yet
<pitti> sshfs is pretty cool, though :)
<ogra> yep
<ogra> i was planning to base our ltspfs implementation on it
<pitti> ogra: maybe you should check with Kamion what exactly scares him before. Usually he has good reasons :)
<pitti> wb seb128 
<Kamion> pitti: oh, not bad scary
<ogra> pitti, right, thats what paris is for ;)
<seb128> re pitti
<Kamion> I haven't looked into the code
<seb128> pitti: new gnome-vfs patch, I just uploaded:
<Kamion> just "that's so useful it's got to be evil"
<ogra> pitti, i'll tie him to the chair in my ltspfs BOFs :)
<seb128>  gnome-vfs2 (2.14.1-0ubuntu3) dapper; urgency=low
<pitti> Kamion: :)
<seb128>  .
<seb128>    * debian/patches/96_from_cvs_only_non_automounted_listed.patch:
<seb128>      - patch from CVS, list only drives which don't do automount,
<seb128>        use storage.media_check_enabled hal property for that
<seb128>        (Ubuntu: #33451, #41740)
<seb128> pitti: should fix the "list unmount usb key and double click on it doesn't work"
<seb128> unmounted
<pitti> seb128: hm, that means usb sticks etc. won't be displayed any more?
<seb128> pitti: the drives no, the volumes still are
<pitti> aaah
<pitti> cool!
* pitti hugs seb128
<seb128> :)
* seb128 hugs pitti
<pitti> Keybuk: do you want bugs for sync requests nowadays, or just an IRC ping?
* pitti uploaded a new pmount to debian incoming
<ogra> Keybuk does syncs ? 
<Kamion> https://launchpad.net/people/ubuntu-archive
<Kamion> pitti: bugs are generally best, that way any of ubuntu-archive can do them
<pitti> ok, alright
<pitti> Keybuk: should I use invoke-rc.d udev reload and rely on you fixing it, or use kill -HUP?
<pitti> Keybuk: weird, start-stop-daemon --stop --signal 1 --exec /usr/sbin/acpid works just fine, but /sbin/udevd doesn't
<pitti> ls -l /proc/`pidof udevd`/exe is just right
<Keybuk> pitti: means that udevd has been restarted
<Keybuk> sorry
<Keybuk> upgraded and NOT restarted
<Keybuk> which is normal
<Keybuk> udev doesn't restart itself on ugprade
<Keybuk> ancient s-s-d bug
<pitti> ah, ok
<pitti> might be, I didn't reboot after today's dist-upgrade yet
* pitti notices that it still doesn't work after /etc/init.d/udev restart
<Keybuk> restart doesn't reload :)
<Keybuk> restart runs udevplug again
<Keybuk> reload sends a HUP
<Keybuk> stop/start breaks your machine
<pitti> Keybuk: ok, I'll declare that as a corner case and just use reload then :)
<pitti> (in the fuse-utils init script)
<Keybuk> aye
<Keybuk> right, me off now
<Kinnison> night bukky
<Kinnison> see you in a week
<bddebian> bukky?  heh
<seb128> what component is likely to blame for a "keyboard and touchpad are broken when waking up from suspend"
<seb128> the box still runs, ssh to it works fine and pressing the power button open the session dialog
<crimsun> pitti: thanks! (RE: alsa* uploads)
<pitti> crimsun: my pleasure
<seb128> hum
<seb128> kernel: [4295478.518000]  i8042: failed to resume active multiplexor, mouse won't work.
<seb128> [4295487.758000]  psmouse.c: TouchPad at isa0060/serio3/input0 lost sync at byte 1
<mjg59> seb128: Kernel
<pitti> crimsun: have you ever thought about applying for main upload privs, btw? :)
<seb128> mjg59: is there a standard wiki page or something on "how to make an useful bug for that"?
<bddebian> +1 crimsun :-)
<crimsun> pitti: later, yes
<mjg59> seb128: Not really, no
<elmo> zul: ?
<zul> elmo: yes
<elmo> zul: that ifenslave upload was a manual upload, not a sync?
<zul> yes..
<elmo> zul: shouldn't the version have 'ubuntu' in it, then?
<zul> ah crap...my apologies..
<bddebian> WTF? Does this mean I need to do a -sa?
<bddebian> Unable to validate xdm_1.0.1.orig.tar.gz from xdm_1.0.1-6ubuntu1.dsc: File xdm_1.0.1.orig.tar.gz mentioned in the changes has a checksum mismatch. 66dc783285b834c50239f861b517684c != c07839b690caacc3bbfa4b7737683606
<Petaris_lab> janimo: I hear you are the person to see for xfce issues?
<janimo> Petaris_lab: yes
<janimo> Petaris_lab: if they are ubuntu/xfce issues
<Petaris_lab> janimo: I'm running xfce on an ltsp server, but logins don't work sometimes
<janimo> Petaris_lab: I have no experiece with ltsp at all
<Petaris_lab> the actual login is accepted according to /var/log/auth.log
<janimo> login using ldm?
<Petaris_lab> gdm
<Petaris_lab> but it just kicks me back to gdm again
<Petaris_lab> after a few times it finally goes
<ogra> Petaris_lab, how dos gdm come into your client environment ?
<ogra> you said it wasnt tweaked
<bddebian> elmo: Any idea what I'm doing wrong with xdm?  My second upload with orig.tar.gz include was rejected too?
<bddebian> SHA1 sum of uploaded file does not match extant file in archive
<ogra> janimo, it looks like something from the session script tries to access the DISPLAY variable before its set, youre simply to fast for ssh :)
<elmo> bddebian: you can't overwrite orig.tar.gz's
<Petaris_lab> ogra: isn't that what the clients are using?
<elmo> make the orig.tar.gz match or change the upstream version number
<bddebian> shite
<ogra> Petaris_lab, nope, gdm doesnt offer ssh tunneling 
<bddebian> elmo: How do I make the checksums match?
<janimo> ogra, no idea what it can be, but for etch I'll try to make startup much slower to cope with such situations
<ogra> bddebian, use the rigth orig.tar.gz :)
<pitti> bddebian: download the current orig.tar.gz and use that
<bddebian> W@#$#@$%234
<ogra> janimo, could you point Petaris_lab to the right script, so he can experiment with sleep values or something to slow it down a bit
<janimo> Petaris_lab: the script is /etc/xdg/xfce4/xinitrc
<janimo> that's what gdm calls
<Petaris_lab> janimo: ok
<ogra> hmm, is that also what /etc/X11/Xsession calls ? 
<Petaris_lab> I will play with it a bit
<janimo> but some of the stuff is done by the xfce4-session executable not from the sctipt
<Petaris_lab> hrm
<Petaris_lab> ogra: can display be set bofore login?
<Petaris_lab> *before
<ogra> DISPLAY is set by ssh
<Petaris_lab> hrm
<ogra> *during* login
<janimo> Petaris_lab: ogra, well /usr/bin/startxfce4 so indirectlu the scriptI mentioned
<ogra> ok
<Petaris_lab> if that is the case then a client that has been up for a while shouldn't have the issue
<Petaris_lab> yet it does
<ogra> ???
<Petaris_lab> or is the ssh session not started until login/
<ogra> i dont understand what you mean with "a client that has been up for a while" ?
<Petaris_lab> a client that has been started but sitting at the login screen
<ogra> the login is running ssh -X user@server /etc/X11/XSession
<Petaris_lab> ahh
<ogra> if you are not logged in DISPLAY is set to the client 
<Petaris_lab> ok
<ogra> if you are logged in DISPLAY is set by ssh
<Petaris_lab> so a sleep should do the trick
<ogra> setting it happens during the login process
<Petaris_lab> I will try setting a 5 second sleep in the script and see what happens
<ogra> just a guess by the .xsession_errors you showed
<Petaris_lab> hrm
<Petaris_lab> I wonder where I should set this
<bddebian> Ah, that did it, thx elmo, ogra, pitti
<Petaris_lab> that still didn't fix it
<Petaris_lab> well, out of time for the momment
<Petaris_lab> later
<doko> dholbach: ping
<dholbach> doko: pong
<elmo> is there any particular reason we don't install smartmontools by default?  it doesn't run a daemon by default
<_ion> Which reminds me how cool it would be if notification-daemon told the user about SMART failures.
<_ion> I.e. "Hi! Your HDD is about to die. Please backup your stuff. HAND"
<elmo> there's a spec for that
<elmo> and someone even started (maybe finished) work on the software to do it too
<elmo> but even making smartctl available would be a nice easy first step
<_ion> It's even in main, there would be no need to promote it.
<Seveas> fabbione, ping
<_ion> Maybe file a bug against ubuntu-standard?
<fabbione> Seveas: pong?
<_ion> s/standard/meta/
<Seveas> fabbione, mind a quick pm?
<fabbione> Seveas: no
<slomo_> hrm... gnome doesn't recognize my cdrom driver anymore, cryptsetup doesn't work with latest devmapper... are these known bugs?
<zyga> hello
<fabbione> night guys
<zul> c ya fabbione 
<jcole> d-i	pkgsel/install-pattern	string	~t^ubuntu-standard$|~t^ubuntu-desktop$
<jcole> when preseeding, can i simply modify that?
<zyga> is there any plan to make a UVF exception for vim7?
<_ion> zyga: I hope so. :-)
<zyga> I'll check malone
<jcole> i tried something simple like this to install xubuntu and it didn't work...
<jcole> d-i	pkgsel/install-pattern	string	~t^ubuntu-standard$|~t^xubuntu-desktop$
<ubijtsa> jcole: you can..
<ubijtsa> if the package that you try to install exists in the available repositories
<jcole> ubijtsa: is there some "other seed" i need to update?
<ubijtsa> jcole: you can specify in the preseed repositories to use, and I am not sure there is a xubuntu-desktop meta-package is the basic one..
<ubijtsa> jcole: you can disect the xubuntu install ISO and see what they specify..
<Kamion> jcole: xubuntu-desktop exists, your preseed seems right
<Kamion> oh, not Task: xubuntu-desktop though
<zyga> #44269
<zyga> malone 44269
<Ubugtu> Malone bug 44269 in vim "UVF exception  to include vim 7 in dapper" [Normal,Unconfirmed]  http://launchpad.net/bugs/44269
<Kamion> um, change ~t^xubuntu-desktop$ to ~n^xubuntu-desktop$ for now and it should work
<Kamion> i.e. install the metapackage rather than the probably nonexistent task
<Kamion> I'll try to track down getting that task added
<ubijtsa> Kamion: will a Task be added at some point ?
<ubijtsa> beat me to it :)
<Kamion> ubijtsa: 21:41 < Kamion> I'll try to track down getting that task added
<ubijtsa> *lol*
<jcole> Kamion: ah
<HiddenWolf> Mithrandir: ping
<jcole> Kamion: after some googling, i'm told it uses "aptitude syntax" but i couldn't find anything about that ~t in the man pages... do you have a reference url?
<Kamion> jcole: install aptitude-doc-en and it's in /usr/share/doc/aptitude/html/en/ch02s03.html
<jcole> Kamion: oh, ic... not in man pages, thanks
<nawty> howdy :) 
<Kamion> urgh
<zyga> hmm
* Kamion finds the hardcoded file in soyuz that appears to control extraoverrides that hasn't been updated since February
<zyga> I have just found a rejected bug report that did not include UVF anywhere, about vim 7
<Kamion> somebody give me something that's been removed from desktop since then
<jcole> Kamion: that's perfect
<Kamion> ah, xchat-gnome, that'll do
<Kamion> override.dapper.extra.main:xchat-gnome  Task    edubuntu-desktop, ubuntu-desktop
<Kamion> KINNISON
<Kamion> sigh, netboot installs are basically broken - they'll install totally the wrong things. sorry. I'll chase this down with the soyuz folks tomorrow.
<looksaus> hi all, I'm trying to document https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067 better
<Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Unconfirmed]  
<looksaus> because it could be a real showstopper for quite a few powerpc users
<looksaus> is the backtrace information good enough? is there anything I can do to make it any better?
<looksaus> I really have no idea if it says anything useful
<slomo_> infinity: please give-back gst-plugins-base0.10 on hppa
<lool> hi there, does someone have an idea why there's a depmod -a in the init of the initrd instead of doign the depmod -a at mkinitramfs time?
<lool> here's the full story, with a custom kernel, I see loads of error messages from modules.dep not being found *prior* to init (I inserted an echo at the first line of init), it seems to me udev is triggerred before depmod -a is called
<zul> heylo
<Burgwork> sabdfl, you around?
<sabdfl> Burgwork: yep
<Burgwork> sabdfl, I have been doing a lot of thinking about the website. One key requirement for any webmaster, for me, would be ability to lead a webteam of volunteers like myself
<Burgwork> sabdfl, as I would love to work on the content, but currently there are a few barriers in place
<sabdfl> Burgwork: barriers?
<Burgwork> sabdfl, lack of good forum to discuss, plus henrik having no time
<Burgwork> sabdfl, by forum, I mean, mailing list
<sabdfl> Burgwork: it's a full time job, and we haven't had a full time person there till now
<sabdfl> well - we still don't - but we're hiring :-)
<Burgwork> sabdfl, saldy, I have no python skills. Are you looking for marketing/sales people as well?
<sladen> lool: it maybe to do with the selection of available modules in the initramfs being different, and possibly having had extra modules appended.  you could ping jbailey about the initramfs intrincses
* tseng recommends Burgwork with enthusiasm
<sabdfl> Burgwork: yes
<neuralis> Burgwork: you can pick up python in 2-3 days with any prior programming experience.
<sabdfl> but this is not a #u-devel topic
<Burgwork> neuralis, fail down the 2nd point as well
<Burgwork> sabdfl, yes
* Kamion decides it might be best not to leave {ubuntu,kubuntu,edubuntu}-live broken overnight
<looksaus> I'm sorry to bug you people about this at such a busy moment, but...
<looksaus> on 2006/04/18, I reported https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067
<Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Unconfirmed]  
<looksaus> I did hardware tests to confirm it was not an unlikely problem with my machine
<looksaus> I found another dapper ppc user to confirm the problem
<looksaus> and today, with some help from this channel, I think I managed to do more or less of a backtrace
<looksaus> can anyone here confirm that https://launchpad.net/distros/ubuntu/+source/firefox/+bug/40067
<Ubugtu> Malone bug 40067 in firefox "firefox freezes after a few secs on ppc" [Normal,Unconfirmed]  
<looksaus> contains good enough backtrace information?
<mdke> looksaus: it's been reproduced by someone on the bug, you can mark it as confirmed, I think
<looksaus> is there a way I can help to make it better?
<looksaus> mdke, I'm just being careful
<looksaus> I don't want to come over as arrogant
<mdke> I'll confirm it
#ubuntu-devel 2006-05-17
<mdke> there you are.
<looksaus> to me, it feels as a critical bug, but I really don't want to step on developer responsibilities
<looksaus> mdke, thx
<looksaus> mdke, do you know enough about gdb backtraces and stuff to say if this was all I could do?
<mdke> fraid not
<looksaus> I mean, all information I could assemble?
<mdke> I don't know. Hopefully a firefox maintainer will get back to you
<looksaus> in the situation as it is, I really can't say Ubuntu is ready on powerpc
<looksaus> did I just give the definition of "critical bug"?
<looksaus> just to make clear: I really really appreciate any and all of the great work being delivered on dapper and on free software in general!
<looksaus> I'm just getting a bit worried
<AlinuxOS> when I want create my coc.txt.asc to sign Code Of Conduct, I got errors :/
<AlinuxOS> gpg --clearsign coc.txt
<AlinuxOS> gpg: no default secret key: secret key not available
<AlinuxOS> gpg: coc.txt: clearsign failed: secret key not available
<AlinuxOS> ?
<looksaus> AlinuxOS, and you're sure you have one?
<mdke> AlinuxOS: you need #ubuntu or #gnupg
<AlinuxOS> looksaus, no I dont' know :)
<AlinuxOS> oops my fault :)
<AlinuxOS> it's devel..
<AlinuxOS> too much windows open :D
<looksaus> :)
<AlinuxOS> mmm
<AlinuxOS> sekret key :D
<AlinuxOS> looolz
<AlinuxOS> boh
<AlinuxOS> I was thinking that sign COC is simple :)
<looksaus> AlinuxOS, it _IS_ about as simple as it can be
<mdke> AlinuxOS: http://wiki.ubuntu-it.org/GnuGpg (but don't continue the discussion in -devel pls)
<looksaus> but let me help you with it on the right channel
<AlinuxOS> looksaus, :)
<AlinuxOS> thank you
<AlinuxOS> mdke, of coure :)
<siretart> yay. bzrtools for bzr 0.8! :)
<mdz> Kamion: broken how?
<HiddenWolf> Mithrandir: obviously, a day after I told you I couldn't reproduce bug 32102, I can. I captured another screenshot, but since it is just a minor graphical glitch, I'm not sure if I should reopen if it's hard to trigger for you or another developer.
<Ubugtu> Malone bug 32102 in libnotify "popups positioned on top of the panel" [Normal,Rejected]  http://launchpad.net/bugs/32102
<lifeless> fabbione: around ?
* luisv wonders why he thought #ubuntu would be helpful
<lifeless> heh
<luisv> so, uh, yeah- anyone here seeing busted gconf in latest dapper?
<bddebian> Howdy folks
<mdz> mjg59: around?
<mjg59> mdz: Hi
<mdz> mjg59: I tried to swap in new artwork for usplash and it defeated me
<mdz> usplash: bogl-vga16.c:437: bogl_vga16_put: Assertion `yy + pixmap->height <= bogl_yres\' failed
<mdz> even though the images have exactly the same dimensions
<mdz> I even diffed the pngtobogl output
<mdz> what did I miss?
<mjg59> mdz: Erm. You're sure it was 640x400?
<mdz> mjg59: struct bogl_pixmap pixmap_usplash_artwork = {
<mdz>   640,          /* Width. */
<mdz>   400,          /* Height. */
<mdz>   16,           /* Number of colors. */
<mdz>   -1,           /* Transparent color. */
<mdz>   usplash_artwork_palette,      /* Palette. */
<mdz>   usplash_artwork_data, /* Data. */
<mdz> };
<mjg59> Hrm.
<mjg59> What are yy and bogl_yres?
<mjg59> Nothing springs to mind, so...
<mdz> ok, I thought maybe there was a secret incantation needed when changing the image
<mdz> I'll debug
<mjg59> Not that I can recall
<mdz> added debug to the function and it works with that binary
<mdz> ...
<mjg59> Ha
<mjg59> Broken build system didn't include the new graphic?
<mdz> the graphic only goes in the .so, right?
<mjg59> Hm. Yes, I think so
<mjg59> That was Jeff's code
<mdz> I don't see why one binary would work and not the other
<mdz> ha
<mdz> -rwxr-xr-x 1 root staff 694425 2005-08-04 17:43 /usr/local/sbin/usplash
<mdz> August 2005 comes back to haunt me
<lifeless> muhaha
<bddebian> Heya lifeless
<bddebian> lifeless: Oh, did that xclip hack work OK? :-)
<lifeless> bddebian: dunno, haven't updated for a couple of days.
<lifeless> I'll do so today
<bddebian> NP
<jsgotangco> good morning
<ajmitch> hi jsgotangco 
<jcole> check this out, e17 on a handheld -> http://www.rasterman.com/files/eem.avi
<bddebian> Heya jsgotangco
<jcole> fyi, gpe is not complete and very very old in debian/ubuntu -> https://wiki.ubuntu.com/EmbeddedUbuntu
<jcole> xfce and e17 should be added to that spec
<jcole> they are both up to date
<kmr> hello. is launchpad the proper place to submit a bug report (and patch) for dapper?
<neuralis> kmr: yes.
<kmr> neuralis: thanks. I posted the bug (but not the patch) to debian 110 days ago. but, I'd like to see the fix in dapper if possible. appreciate the info
<bddebian> kmr: What package?
<kmr> imagemagick. debian bug #349264
<Ubugtu> Debian bug 349264 in imagemagick "Subject: Assertion failure if get ICC profile with PerlMagick" [Important,Open]  http://bugs.debian.org/349264
<kmr> right. submitting a 3-line patch to launchpad line
<kmr> er, now
<jcole> since the gpe guys are fully dedicated to the familiar distro, it's very unlikely that gpe embedded ubuntu would happen
<bddebian> Hmm main package, I can't touch it :-(
<jcole> e17 embedded ubuntu is though :)
<kmr> posted. Well, I have a fixed version in my local apt repository for breezy, but thought it'd be nice to not have to maintain that for dapper
<ajmitch> kmr: if you could post the patch as an attachment (see on left), and change the version to 6:6.2.4.5-0.6ubuntu1 with distro dapper, it'd be great
<ajmitch> pasting patches inline tends to destroy them a bit in malone
<kmr> ajmitch: sure, I can do that. can/should I edit the previous report or just create a new report?
<ajmitch> edit bug #44307
<Ubugtu> Malone bug 44307 in imagemagick "Assertion failure processing ICC profiles with perlmagick" [Normal,Unconfirmed]  http://launchpad.net/bugs/44307
<kmr> okay, thanks for the tips. first time using launchpad
<ajmitch> no problem, thanks for the patch
<bddebian> Why can't you click on the headers to sort in LP anymore? :-(
<jcole> btw, not important but will ubuntu dapper have grub themes like kubuntu dapper?
<jcole> there's a kubuntu-grub-splashimages
<tritium> that's nice new artwork on shutdown, but I still had the old artwork on startup
* desrt watches a regression introduced by a new (uvf-broken) version of a package that is not technically a bug in the package
<ajmitch> desrt: explain
<bddebian> desrt: What package?
<desrt> gajim 0.9 -> 0.10
<desrt> increased standards compliance == wonky behaviour with commonly-deployed non-compliant server implementations
<ajmitch> how is it a regression but not a bug?
<desrt> in the same way that most metacity "regressions" aren't bugs in metacity but, rather, other apps :)
<ajmitch> heh
<desrt> (but result directly from metacity getting more hardcore with the standards)
<desrt> anyway.  it's totally awesome
<desrt> every time someone approves me to add them to my list i get a limitless stream of 'Approved!' dialogs
<desrt> they come up like 2-3 per second.. i can't click OK fast enough
<tritium> how can usplash be using different artwork on startup and shutdown?  It should be the same .so file that contains it...
<desrt> tritium; because the startup one comes from the initramfs image
<desrt> tritium; you need to rebuild it (dpkg-reconfigure your kernel image) in order to copy the .so in
<tritium> desrt: ah, thanks!  :)
<tritium> That did it, desrt!
<fabbione> morning guys
<fabbione> lifeless: i am now
<ajmitch> hey fabbione 
<fabbione> hi ajmitch 
<lifeless> fabbione: mailed ya
<Burgundavia> salut ajmitch
<ajmitch> hi Burgundavia 
<Burgundavia> ajmitch: what a major dilemma. Right as canonical hiring, I am starting to enjoy my job
<ajmitch> heh
<ajmitch> and it's just bad timing for me as well ;)
<Burgundavia> ajmitch: why so?
<ajmitch> busy at uni
<Burgundavia> ah
<ajmitch> just applied for google's SoC
<ajmitch> so I should at least be busy working on edgy
<Burgundavia> I suspect that canonical will be hiring in the future as well, so it is not a major issue
<ajmitch> possibly
<desrt> ajmitch; i want to do a universe upload.  how can i do it?
<ajmitch> patch to an existing package?
<desrt> ya
<ajmitch> easiest way is to stick a debdiff on malone for one of us to look over & upload
<desrt> ok.  how does that work?
<ajmitch> debdiff package1.dsc package2.dsc > patch.debdiff
<desrt> neat.
<ajmitch> fairly useful
<desrt> does that include a signature on the new one?
<ajmitch> nope
<ajmitch> since one of the universe uploaders has to sign for the upload to be accepted
<desrt> true
<desrt> something i've wondered about for a bit
<desrt> does it matter if the signature on the package doesn't match the changelog?
<crimsun> best practice or technically? If the latter, the key used to sign dsc and changes needs to be in the upload keyring for that component, that's all.
<desrt> it seems that i should mark my uploads as desrt@ubuntu but my public key doesn't have a UID for this email and i've nobody close to me to sign it
<desrt> (but desrt@desrt.ca is very well signed)
<desrt> ajmitch; do you have a few mins?
<ajmitch> yeah
<desrt> k.  see /msg
<pitti> Good morning
<desrt> good morning
* pitti hugs desrt 
* desrt is hugged and hugs back
<desrt> i just learned dch -i and debdiff :D
<desrt> you guys have some nice toys
<desrt> will you be at guadec, pitti?
<pitti> desrt: I didn't plan that at all yet - will you?
<desrt> ya.
* desrt got sponsored :D
<crimsun> congrats, desrt 
<desrt> it's only a country or two over from you.. you should consider it
<crimsun> 'morning pitti 
<desrt> crimsun; thx.
<pitti> hi crimsun 
<pitti> desrt: yes, I'll look for the date etc. and try to come
<desrt> it's the last week of june
<pitti> crap
<pitti> desrt: that's already our conference
<pitti> or, maybe it's the week directly after that
<desrt> where is the ubuntu one?
<pitti> yes, indeed, that fits
<pitti> UFK is June 19 to 24
<pitti> so I'll already be in the right country
<desrt> no
<desrt> guadec is spain
<pitti> desrt: oh, ok; some more country hopping then
<desrt> UFK isn't nearly as well advertised as UBZ or UDU
<desrt> planned to be smaller?
* netjoined: irc.freenode.net -> zelazny.freenode.net
<infinity> desrt: It's just a developer's summit, not a "whole company and community showing up for 2 weeks" thing.
<infinity> desrt: We're just getting together to quickly map out edgy, then going home again.
<ajmitch> no love days or community brainstorming
<ajmitch> specs preferably written out beforehand 
<infinity> And roadmap/milestones directly decided by the people who will be implementing them (in general).
<infinity> So, this s meant to be our "fun, break the world, do whatever blingful things we think are neat" release.
<desrt> ya.  i like that idea.
<alex_joni> g'morning.. anyone familiar with debuild on the kernel source ?
<lool> sladen: (thanks)
* alex_joni needs a pointer for building a new d-i kernel & modules
<Mithrandir> HiddenWolf: re bug 32102; if you can give me instructions on how to reproduce it, please do.
<Ubugtu> Malone bug 32102 in libnotify "popups positioned on top of the panel" [Normal,Rejected]  http://launchpad.net/bugs/32102
<_ion> Eww. Does somebody actually like the new usplash artwork? The colors are horrible (i sincerely thought the that was some kind of a palette bug, until i looked at the PNG file in the source package), and the picture has been scaled down without interpolation.
<_ion> The previous artwork was really nice.
<_ion> http://johan.kiviniemi.name/pictures/usplash/
<Seveas> _ion, since when do we have that bootsplash?
<_ion> seveas: Since i dist-upgraded a few minutes ago.
<Seveas> hmm, ok, maybe I should reboot my machine 
<jsgotangco> that that looks really nasty
<HiddenWolf> Mithrandir: I'm using xchat-gnome, I had treenaks babbling to me while I was working on another virtual desktop, each time he said something the popup was slightly misalligned over the panel.
<Treenaks> _babbling_? :)
<ivoks> :)
<HiddenWolf> Treenaks: ;)
* HiddenWolf hugs Treenaks
* Treenaks pokes the notification popups
<Treenaks> Learn to use Xinerama!
* Treenaks had a 'There are new packages' spread out over 2 monitors
<giftnudel> well, nautilus needs to learn it too ...
<HiddenWolf> Treenaks: well, that is just modern :)
<giftnudel> Treenaks: is your wallpaper also spread across two monitors?
<Treenaks> giftnudel: I have no wallpaper, but yes, the plain brown background is spread over 2 monitors ;)
<_ion> https://launchpad.net/distros/ubuntu/+source/usplash/+bug/44339
<Ubugtu> Malone bug 44339 in usplash "Regression in usplash artwork" [Normal,Unconfirmed]  
<giftnudel> Treenaks: could you try real quick, just to have a confirmation?
<Treenaks> giftnudel: it spreads one image over 2 screens
<giftnudel> thanks
<pitti> hey kagou 
<kagou> hi pitti 
<freeflying> pitti: hi
<pitti> hi freeflying!
<freeflying> pitti: any problem with language-support-zh
<freeflying> pitti: I just do a fresh install with today's i386-install-cd, and select language support packages, but some like scim-pinyin wasn't installed
<pitti> freeflying: hm, l-support-zh depends on it
<pitti> freeflying: did you install with network? or, rather, do you have l-support-zh installed in the first place?
<freeflying> pitti: ya, install with internet accessable
<freeflying> and choose l-s-zh as default
<pitti> dreb
<pitti> oops, EFOCUS
<pitti> freeflying: so, l-s-zh wasn't installed?
<freeflying> l-s-zh was installed, but some depends packages wern't
<sladen> tritium: one of the .so's for usplash is coming from the initramfs (bootup) and one from the main root partition (shutdown).  You need to  sudo update-initramfs -u `uanrm -r`
<sladen> uname -r
<pitti> freeflying: uh? that's just weird... dpkg -l language-support-zh says 'ii' in first column?
<freeflying> pitti: sure
<pitti> freeflying: and scim-pinyin isn't? it's a strict dependency
<pitti> 'apt-get -f install' will install it?
<freeflying> pitti: I see , haven't try with -f , just installed them 
<pitti> freeflying: apt-get install -f will fix up packages to fulfil dependencies, and so on
<pitti> hey carlos
<carlos> hi
<pitti> freeflying: anyway, that's just plain wrong and weird. can you please file a bug about that?
<freeflying> pitti: I see, but this issue is wired
<pitti> carlos: langpacks today?
<freeflying> pitti: I don't know if I can reproduce it, so I poke you here :)
<pitti> freeflying: that's mainly an installer thing, I can only tell you how it shuold be
<pitti> freeflying: what does 'apt-get install -f' want to install? (don't do it, just look at the package list)
<freeflying> pitti: oeky,then I'd file a bug on which one?
<pitti> freeflying: ubiquity or debian-installer, depending on whether you used live or install CD
<pitti> freeflying: however, *does* apt-get install -f work? what does it want to do?
<freeflying> pitti: sorry, I'd use scim-pinyin, so just install thenm with" sudo  apt-get install scim-pinyin "
<pitti> oh, I see
<carlos> pitti: yeah ;-)
<carlos> we are still missing some translation domains
<alex_joni> does anyone have pointers about documentation for debian-installer ? mainly building a new kernel for it
<carlos> pitti: but GNOME, KDE and XFCE are in already
<freeflying> pitti: got it ,because l-s-zh depedns on gimp-help-zh-cn, but gimp-help-zh-cn is unavaliable now
<pitti> freeflying: ah, yes, it's on http://people.ubuntu.com/~cjwatson/anastacia.txt
<pitti> freeflying: so don't bother filing a bug, it'll be sorted out soon
<Kamion> mdz: I merged ubiquity-ubuntu-doc into ubiquity-ubuntu-artwork, so *-live needed to stop depending on the former
<Chipzz> mvo: hi :)
<mvo> hey Chipzz
<alex_joni> chiciudeand: Chiciudean Dan: mi-o scris alina
<alex_joni> dana2linda: si?
<alex_joni> sorry... wrong channel
<\sh> moins
<ajmitch> hi
<pitti> hi \sh 
<\sh> hey pitty
<pitti> Kamion: can you approve/deny UI freeze breakages, or only mdz? (since he'll be off to Mexico)
<jsgotangco> brb
<Kamion> pitti: I don't know, actually, I guess I can. The main rule for UI freeze breakages is to talk to the doc team, though
<pitti> Kamion: ok, I cc'ed them in the bug report; I'll wait for their answer then first
<infinity> Kamion: <poke>
<infinity> Kamion: Your PAM upload appears to have broken on Sparc (and only sparc).  Want to blame yourself, or someone else (glibc, perhaps)?
<Kamion> infinity: stinks of glibc to me, I must say; RLIMIT_NICE is meant to be defined now
<Kamion> so how come 0.79-3ubuntu12 built?
<infinity> Elifiknow, but I'm looking at glibc right now.
<Kamion> oh, huh
<Kamion> everywhere else in pam_limits.c does #ifdef RLIMIT_NICE, that bit doesn't
<infinity> Oh, the previous patch was in an ifdef..
<infinity> Yes indeed. :)
<Kamion> so it's my fault, but suggests that glibc is buggy too
<infinity> But, before you fix that, I should fix sparc's glibc.
<Kamion> you want to do it in that order?
<Kamion> I guess so, so that we get RLIMIT_NICE support in pam on sparc.
<infinity> I'd prefer to, since I can then rebuild the "broken" pam against the fixed glibc.
<infinity> And if that works, then you can fix the ifdefs. :)
<Kamion> I've got a fixed package prepared, any time you like
<infinity> Curious.
* infinity digs deeper.
<infinity> Kamion: Okay, spotted.  The patch patches the wrong file.
* infinity claps.
<pitti> infinity: thanks for the pmount sync, that fixes another 2 bugs on my dapper milestone bug page
* seb128 hugs pitti for fixing dapper milestoned bugs again :)
<infinity> I don't love jbailey anymore.
<pitti> I crunched my list from 13 to 8 since yesterday
<richips> Hi
<richips> I'm having some troubles compiling QT applications in KDevelop
<richips> so I wanna know... what pakages and libs do I need to make, build and so on successfully with kdevelop?
<Riddell> richips: that's a user questions.  but sudo apt-get build-dep kdelibs will get you most things
<richips> thnks... sorry for  posting here my question... just a confussion
<infinity> Riddell: Can you comment on that qt4-x11 sync request (specifically, does the Debian package contain ALL our patches, including the HPPA patch?)
<infinity> Kamion: Uploaded.  I'll poke you once it's round-tripped and I've had a chance to retry PAM on sparc.
<Kamion> siretart: if nobody's said so already, could you please subscribe ubuntu-archive (and assign to nobody, if you just want to get it off your plate) rather than assigning ubuntu-archive to bugs?
<Tetralet> Kamion: I'm the main Traditional Chinese translator of debian-installer.
<Tetralet> Kamion: The Tradition Chinese translation of debian-installer was update yesterday.
<Tetralet> Kamion: Please check if Ubuntu were uptodate. Thanks
<Kamion> Tetralet: we're well past upstream version freeze; it is extremely difficult for me to update now
<Kamion> it's difficult manual work for 50-odd languages
<Tetralet> Kamion: I got it. Thanks anyway.
<Kamion> I can update individual strings if you point me to important changes
<Kamion> (I'm assuming you're talking about the translation in d-i svn, by the way)
<ajmitch> Kamion: how disruptive would an e2fsprogs upload be right now? it's not not building in dapper, but a simple fix
<Riddell> infinity: hmm, no, I quite missed that
* ajmitch assumes it'd be problem, as the package works just the same now :)
<infinity> ajmitch: "it's not not building"?
<ajmitch> infinity: small typo
<infinity> ajmitch: Which bug are we looking at?
<infinity> Oh, 36925?
<ajmitch> yep, just a simple doc problem
<infinity> If your fix works, and touches nothing else, by all means make it go.
* ajmitch wasn't sure if flight 8 was imminent or not
<infinity> No, it's next week.
<ajmitch> ah right
<dholbach> If somebody can get tango-icon-theme-common out of NEW soon, that'd be nice, as it needs main approval, promoting to main and seeding soon :-)   (it's a mere split-off of tangerine and we are upstream)
* janimo goes to seed that in xubuntu
<janimo> dholbach: or is it depended upon by tango already?
<dholbach> janimo: no
<dholbach> it still sits in NEW and it will need seeding (once it's approved, etc)
<dholbach> I don't want to make it dependant
<janimo> dholbach: although you can seed it I think ,as it won't cause errors till it's not there
<janimo> will just be ignored from what I saw so far
<dholbach> i'll wait for it :)
<janimo> or maybe only if it's in universe nor sure
<janimo> dholbach: I guess you did not have a chance to take a look at the new gnumeric patch?
<infinity> dholbach: I'll process it after this cron.daily, since I have some other stuff to do as well.
<infinity> dholbach: heading to main, I assume?
<dholbach> infinity: yes.
* janimo is glad install CD gained back the 60Mb it lost with the temporary abiword-plugin gnome deps
<dholbach> infinity: it's a split off of tangerine, so tango people (as xubuntu) can use it too
<dholbach> infinity: I'm not so fond of binary patching tango-icon-theme, because stuff is not in upstream yet :)
<janimo> dholbach: thanks for this package btw :)
<infinity> dholbach: Kay, it's just a split of stuff that's already in main?
<dholbach> janimo: it was less work than I expected and greatly due andreasn's good work.
<infinity> dholbach: If it'll be depended on by stuff in main, there's no reason to seed it.
<dholbach> infinity: yes, in a new source package.
<janimo> I think nomed will be a lot more relaxed :)
<dholbach> infinity: no, I don't want to make packages depend on it, I'll rather seed it.
<infinity> dholbach: So, tangerine-icon-theme won't actually need it?
* dholbach hugs infinity - thanks dude.
<infinity> dholbach: From "it's split from tangerine", I assumed it would. :)
<dholbach> infinity: no, but we want to have it in as well.
<infinity> Kay, check.
<janimo> dholbach: ^^ the gnumeric patch
<infinity> dholbach: If files moved from tangerine to tango, should there not be a versiones Replaces on the binary package?
<dholbach> infinity: no, they moved from /usr/share/icons/Tangerine to /usr/share/icons/Tango and I doublechecked for duplications of tango-icon-theme stuff - we should be fine.
<dholbach> janimo: i'll look into it later today - promise.
<infinity> Okay, cool.
<janimo> dholbach: ok, thanks.
<dholbach> janimo: are there any plans for xubuntu netboot images? a friend of mine asked me
<Kamion> dholbach: there's a soyuz problem blocking xubuntu netboot at present
<Kamion> I'm going to chase it up today
<Kamion> in any case it wouldn't be separate images, you'd just pass some magic arguments to the standard ones
<dholbach> ahhh nice
<janimo> dholbach: I have only a vague idea what netboot images are :). Did not even know ubuntu/kubuntu had those
<janimo> very small iso which takes most of the stuff from the net?
<Kamion> yes
<janimo> like <10M ?
<dholbach> you get it via dhcp/tftp
<Kamion> http://archive.ubuntu.com/ubuntu/dists/dapper/main/installer-i386/current/images/netboot/
<Kamion> you can either use dhcp/tftp or there's an ISO
<janimo> I think I tried the usrelinux netboot image over a year ago, I think it was 4 or 5 Megs
<Kamion> the ISO image is 7.5MB
<janimo> oh nice and small
<Kamion> it's just the core of the installer and enough bits to get more of itself from the net
<janimo> is this useful for customized installs or what?
<janimo> since it needs bandwidth it seems
<phanatic> is it difficult to rebuild the live cd images to include other langpacks?
<janimo> phanatic: it probably does not help you but the xubuntu live includes quite a lot of them including hungarian
<janimo> or will starting tomorrow
<phanatic> janimo: that's great news :) i was just testing the dapper flight7, but it is in bad shape, because it doesn't ship hungarian langpacks (which i can understand of course)
<janimo> phanatic: yes, ubuntu and kubuntu are full so no support pack besides English fits
<janimo> actually not langpacks, lang support pack
<janimo> langpacks have translations for most apps, support has firefox/thunderbird/openoffice and spellcheckers
<janimo> and the support packs are huge (>10M) because of the OOo help and l10n
<phanatic> janimo: but it looks a bit interesting, because some of the gnome strings are translated (i think they are from upstream)
<janimo> phanatic: yes, because langpack is installed probably
<siretart> Kamion: Oh, okay. will do so in future. sorry for unconvinience
<janimo> which package is responsible of creating xorg.conf during install?
<phanatic> janimo: thanks for the info
<janimo> phanatic: szivesen
<phanatic> janimo: :)
<phanatic> janimo: so you speak hungarian?
<phanatic> s/so/do
<janimo> I guess I have no choice, since I am hungarian
<Kamion> siretart: thanks, no problem
<Kamion> janimo: yes, needs bandwidth, is useful for customised installs and particularly automatic installs, e.g. where you want to automatically install packages that aren't on the CD
<phanatic> janimo: wow, i didn't know it, really :) to tell the truth i was a bit suspicious because you're from kolozsvar... ;)
<Kamion> janimo: xorg.conf> xserver-xorg (source package name "xorg")
<janimo> Kamion: than is a separate xubuntu really warranted? as that mini image can become any of the derivatives
<Kamion> janimo: that's exactly what I said to dholbach above
<Kamion> janimo: 12:24 < Kamion> in any case it wouldn't be separate images, you'd just pass some magic arguments to the standard ones
<janimo> Kamion: ok
<phanatic> another question: fglrx isn't installed by default, so every widescreen laptop with ati cards fail to start x. is that because of licensing issues?
<mjg59> phanatic: "Every widescreen laptop with ati cards fails to start x" isn't accurate
<Treenaks> my (mjg59: other ;)) widescreen laptop starts X fine, in 1280x800
<phanatic> mjg59: sorry, most of them...
<mjg59> phanatic: No, that's not true either
<mjg59> fglrx isn't installed by default because we're unable to support it in any sensible way
<phanatic> mjg59: what's the truth then? x700 (which is quite an old one now) fails
<mjg59> phanatic: Without knowing more about the machine in question, it's hard to know
<Treenaks> phanatic: my x700 works fine, except for some sync issues that are being worked on
<mjg59> Treenaks: Would be worked on faster if you'd do those tests :p :)
<Treenaks> mjg59: yeah I know
<Treenaks> mjg59: but tests Depends: time
<mjg59> Sure
<phanatic> Treenaks: interesting... mine has just failed to start (flight7) saying no screens found. after installing fglrx, it worked fine
<mjg59> phanatic: Could you put up lspci output somewhere? The x700 should be supported fine
<phanatic> mjg59: of course, moment please
<mjg59> lspci -n, that is
<phanatic> mjg59: i ran an lspci -v: http://paste.ubuntu-nl.org/13831
<phanatic> mjg59: http://paste.ubuntu-nl.org/13832 (lspci -n as requested)
<Treenaks> phanatic: mine is 1002:5653 as well
<phanatic> Treenaks: i don't know what could be wrong then...
<Treenaks> phanatic: what's your panel resolution? could you paste the auto-generated /etc/X11/xorg.conf on pastebin?
<phanatic> i'm logged in to my installed system now, but i can do if it's neccessary. all i can say is that when i just changed "ati" to "fglrx", everything was fine. screen resolution is 1280x800
<mjg59> phanatic: In that case, could you please file a bug against xserver-xorg-driver-ati with the /var/log/Xorg.0.log file generated when starting with the ati driver?
<fabbione> hmmm
<fabbione> phanatic: how did you install your machine?
<fabbione> phanatic: from a livecd?
<fabbione> (missed the backlog)
<phanatic> fabbione: no, i just tried the flight7 desktop cd. my current system was dist-upgraded from breezy back in december :)
<fabbione> phanatic: ok.
<phanatic> mjg59: ok, i'll do it then
<fabbione> phanatic: please add all the relevant bits..
<fabbione> including the autogenerated config and logs
<phanatic> fabbione: do i need to add lspci output as well?
<fabbione> yes please
<fabbione> collect all the info in one place is good
<fabbione> and it will save people time to find them around again
<phanatic> ok, i reboot now...
<pitti> Kamion: re gui freeze break in bug 8023, doc team is fine with it
<Ubugtu> Malone bug 8023 in gnome-cups-manager "unable to change printer name" [Unknown,Unconfirmed]  http://launchpad.net/bugs/8023
<Kamion> pitti: fine by me, then
<pitti> great, thanks
<phanatic> hi
<phanatic> i'm in the live system now. i have Xorg.0.log, xorg.conf, lspci -n, lspci -v. what else would be useful?
<mjg59> phanatic: That should be fine for now
<phanatic> mjg59: ok, then i'll file the bug and attach these
<mjg59> phanatic: Thanks. Once you file it, could you let me know the bug number?
<phanatic> mjg59: sure
<ogra> seb128, did anything change wrt /usr/share/gconf/defaults/ ? seems my custom settings arent picked up at all in my new artwork package
<seb128> ogra: nop
<ogra> hmm, ok, then the mistake must be on my side 
* ogra goes digging
<seb128> ogra: no gconf upload since 21st of March
<phanatic> mjg59: bug 44370
<Ubugtu> Malone bug 44370 in xserver-xorg-driver-ati "X doesn't start with ati driver (Flight 7, X700, WS)" [Normal,Unconfirmed]  http://launchpad.net/bugs/44370
<ogra> seb128, thanks 
<seb128> np
<ogra> i think i found the error :)
<mjg59> (WW) ATI:  PCI Mach64 in slot 3:0:0 could not be detected!
* mjg59 boggles
<phanatic> mjg59: what does that mean?
<mjg59> It means the driver thinks your card is from ~1998
<phanatic> quite interesting :)
<ogra> ooh
<ogra> seb128, any idea why evo just ate ~/.evolution/mail/local/Ubuntu\ Users.sbd on my disk ? the other Ubuntu Users files are all there, but since a minute evo complains about "file not found"
<mjg59> Oh my god the ATI probing routine is full of crack
<ogra> dholbach, ^^^ ideas ? 
<phanatic> mjg59: i hope you can fix it
<mjg59> phanatic: So do I
<seb128> ogra: no :/
<ogra> i was suspecting to be out of diskspace, but there are still 10M
<ogra> and the folder shows fine in evo, its just the .sbd file missing 
<ogra> is there a way to regenerate that ? 
<ogra> (i fear to loos the whole folder if i close evo now)
<phanatic> Kamion: ping
<Kamion> phanatic: hi
<phanatic> Kamion: how are the translation for ubiquity handled? in other words, how can i tranlate it?
<Kamion> phanatic: https://launchpad.net/distros/ubuntu/dapper/+source/debian-installer/+pots/debian-installer
<Kamion> (if I remembered that URL correctly)
<Kamion> I pick them up occasionally from there
<zul> heylo
<phanatic> Kamion: the translation for d-i (hungarian) is almost 100% (only timezones missing), but there are still english phrases in it (e.g. the bottom of the window: step + the buttons)
<phanatic> Kamion: the partitioning part is also full english, tho gparted is again 100% translated
<Kamion> phanatic: "Step N of M" is known-untranslatable, sorry
<Kamion> buttons are done in GTK IIRC, and probably depend on having the right language pack installed
<Kamion> which bit of the partitioner? describe the screen
<phanatic> the whole... moment, i'll paste some screenshots
<phanatic> Kamion: http://lomonosov.sze.hu/~phanatic/dapper-flight7/dapper-flight7-hu-install6part.png
<phanatic> (this shows that there could be some unicode issues as well)
<phanatic> Kamion: http://lomonosov.sze.hu/~phanatic/dapper-flight7/dapper-flight7-hu-install6.png
<Kamion> phanatic: the Unicode breakage is fixed in current daily builds
<phanatic> Kamion: i'm happy to hear that
<Kamion> phanatic: ok, the gparted one is probably just a missing language pack; I'm afraid there isn't much I can do about that for dapper, although if somebody builds a customised live CD with language-pack-hu and language-pack-gnome-hu added, it should work fine
<Kamion> phanatic: the second one means that I need to import some new translations into partman-auto; I'll look at that, thanks
<Kamion> oh, no, it doesn't
<phanatic> Kamion: thanks for having a look
<Kamion> "How do you want to partition the disk?" is fixed in current dailies
<Kamion> "New partition size:" is odd, that one *is* translated, must be a ubiquity bug, I'll loo
<Kamion> k
<phanatic> i heard something about a live cd customization howto. is it already available? or will it be?
<phanatic> Kamion: thanks again
<Kamion> there's one on the wiki but it doesn't cover dapper yet
<phanatic> i hope it will be updated before release, so we can come out with our localized live cd asap
<Kamion> oh, no, "How do you want to partition the disk?" wasn't fixed; fixed now
<phanatic> Kamion: cool
<jono> hey all
<tseng> hi jono 
<jjesse> hiya jono
<jono> hey, hows it going ?
<jjesse> good 
<jono> just in the process of finalising the LRL06 schedule at which sabdfl is making an appearance
<Treenaks> jono: again? :)
<jono> Treenaks: yep :)
<jono> Treenaks: 99% of the speaker list is complete on our side, just confirmed a MS guy too
<lifeless> mvo: around ?
<mvo> lifeless: yes
<lifeless> hi
<lifeless> apt-python, does it have some way to get the list of files a package has in it ? If not, want a patch for one ?
<mvo> lifeless: it has one, check /usr/share/doc/python-apt/examples/deb_inspect.py 
<mvo> lifeless: is that enough? or will you need more?
<lifeless> mvo: looks good enough
<ogra> hmm, now evo died completely
<phanatic> ogra: evo rip :(
<bddebian> Heya peoples
<_ion> Hi
<bddebian> Hello _ion
<farruinn> How should I voice a feature request for edgy eft? Malone? Mailing list?
<Treenaks> malone
<Treenaks> or actually
<Treenaks> launchpad ;)
<farruinn> So... not a bug report?
<HiddenWolf> Treenaks: specification
<farruinn> aha, thanks :)
<infinity> Riddell: Thanks for handling the QT4 thing.
<zakame> hi all
<_jdong_> can a kernel guy take a look at #43281 for me, please?
<_jdong_> it's a relatively straightforward fix, but I don't want it to be too late for Dapper inclusion...
<_jdong_> it's an issue that affects a great majority of Core Duos and even quite a few Pentium M's
<_jdong_> (malone 43281, that is)
<Ubugtu> Malone bug 43281 in linux-source-2.6.15 "Core Duo / Pentium M high pitched buzzing noise: CONFIG_HZ workaround" [Normal,Unconfirmed]  http://launchpad.net/bugs/43281
<Mithrandir> pitti: how would you feel about an UVF for mailman?  It's kinda big in lines of changed stuff, but most is docs and upstream sucking in patches and such.  I guess it'd make your job a tad easier?
<pitti> Mithrandir: I'd be happy about it if you are fine with the new version
<Coyctecm> nice splashscreen, i just noticed :)
<Mithrandir> pitti: I'd need to read through the 340k diff, but since 50% or so is .mo file diffs, it shouldn't take that long.
<_ion> coyctecm: Bug #44339 :-)
<Ubugtu> Malone bug 44339 in usplash "Regression in usplash artwork" [Normal,Confirmed]  http://launchpad.net/bugs/44339
<bddebian> Eeks
<pitti> Mithrandir: thank you
<Coyctecm> :)
* _ion doesn't understand where (or rather why) that "Affects: gnome-screensaver, Status: Rejected" line came from to that bug.
<infinity> mjg59: Ahh well, so much for us wanting a "non-glowing, non-antialiased" logo...
<ogra> _ion, https://launchpad.net/distros/ubuntu/+source/usplash/+bug/44339/+activity
<Ubugtu> Malone bug 44339 in usplash "Regression in usplash artwork" [Normal,Confirmed]  
<mvo> can some native speaker please have a look at http://paste.ubuntu-nl.org/13841 ? its the mesage you get when you upgrade from breezy-dapper and some of your apps moved from main to universe
<_ion> "that have been moved" maybe? (/me is not a native speaker )
<_ion> Btw, any news about the notification-daemon xinerama patches? Are they going to be included?
<mvo> _ion: thanks, changed
<_ion> Maybe the title should contain the word "officially"?
<mjg59> infinity: Part of the problem is that the scaling to 640x400 has been done badly
<mjg59> Scanlines have just been dropped
<mvo> thanks agan, new version for the text: http://paste.ubuntu-nl.org/13843 (native speakers, please have a look)
<zakame> fabbione: ping
<fabbione> zakame: pong, but i am in holidays
<zakame> fabbione: ooh, soory about that :) just to let you know I'm done with making the list you requested for the x11proto packages (I think )
<fabbione> zakame: ok, cool, go ahead with the libs, server -> drivers  and apps :)
<fabbione> proto are just the beginning
<fabbione> :D
<zakame> I'm doing the libs now, as we were struck here by a typhoon recently
<zakame> thanks :)
<fabbione> zakame: sure.. that's fine.. once you are done mail it 
<fabbione> i will look when i am back
<fabbione> this is all work preparation for edgy
<fabbione> so there is no real point in you committing suicide now in dapper
<zakame> ooh! :D hehe, indeed :)
<HiddenWolf> mvo: I'm not a native speaker, but that text doesn't look right to me, somehow
<HiddenWolf> mvo: "some software", we're talking about the entire release going EOL, right?
<mvo> HiddenWolf: thanks, I upaded it again http://paste.ubuntu-nl.org/13849
<HiddenWolf> mvo: when do users see this text?
<zakame> hmm would it be possible to get apt 0.6.44 into dapper, or is it too late? it features pdiff support, among other things :)
<Kamion> zakame: way too late, imho
<Kamion> new features in the packaging system belong a little earlier than three weeks before release
<bddebian> Bah, where's your sense of adventure? :-)
<Kamion> especially ones that we could not use anyway because our archive does not currently support them
<zakame> awww :( I see 
<ogra> bddebian, especially for a 5year LTS release ;)
<bddebian> hehe
<Kamion> bddebian: lost just before feature freeze
<zakame> edgy would rock extra special then :)
<ogra> edgy will rock extra special then 
<bddebian> Kamion: :-)
<lifeless> mvo: what does apt_inst's message 'TypeError: argument 1 must be file, not instance' mean ? I've just given it a urlopened file.
<zakame> ogra: :-)
<Kamion> lifeless: it has a habit of wanting real file objects unfortunately
<lifeless> oh. meep
<Kamion> usual workaround is to dump out a temporary file
<lifeless> that means spooling entire debs down.. ah well. roger wilco
<bddebian> lifeless: Ever get a chance to try xclip?
<lifeless> bddebian: not yet sorry
<bddebian> NP
<lifeless> bddebian: install it yourself :)
<bddebian> I have but I don't know squat about it :-)
<lifeless> bddebian: its trivial to test - cat foo | xclip, goto any X program and paste
<mvo> lifeless: what Kamion says, sorry. not sure it is easily fixable because of the way the python<->c++ wrapper is written
<lifeless> mvo: ok, no problem.
<bddebian> OK
<reconcilliation> I want to thank the Ubuntu developers for the outstanding work. The work  not only furthers Ubuntu and its sisters but the GNU/*nux community as a whole.  
<bddebian> lifeless: Hmm, it doesn't paste into kate.  Should it?
<bddebian> Hmm, or gedit
<LaserJock> reconcilliation: I bet they appreciate that a whole lot. They certainly have put a lot of effort into it
<lifeless> bddebian: yes it should
<lifeless> middle-click paste, not ctrl-c
<lifeless> erm
<lifeless> ctrl-v
<bddebian> Oh sweet, that worked, thx
<zakame> hmm xpaste
<lifeless> xclip
<reconcilliation> Laser: Its the little things - like the transparent that panel icons. Its shows that they really want this thing to work. Its motivated the little bug hunters and kernel patchers like me.
<Kamion> Riddell: IMHO "exit" to quit on qtparted's stdin is wrong - it's much more fail-safe to cope with stdin going away, and that removes the need for a separate "exit" command
<Kamion> you have to cope with stdin going away *anyway* otherwise qtparted carries on if the installer crashes hard in some way
<lifeless> mvo: where do you want bug reports on apt-python ?
<lifeless> (sections.get(foo, None) complains, it shouldn't)
<mvo> lifeless: I don't really mind, bugs.debian.org is fine, launchpad too
<lifeless> lp will do then :)
<Kamion> lifeless: (it's python-apt, FWIW)
<Riddell> Kamion: I'm still looking at getting that working
<Kamion> Riddell: ok, thanks
<lifeless> Kamion: sorry, got a broken meme somewhere
<lifeless> night all
<pitti> Riddell, seb128, carlos: deb http://people.ubuntu.com/~pitti/langpacks/daily/ ./   <- new stuff, testing appreciated
<carlos> pitti: will try to do it this weekend, thank you!
<pitti> carlos: oh, I wanted to upload them still today
<carlos> pitti: I'm a bit busy atm....
<pitti> ok, nevermind
* Riddell tests
<seb128> pitti: trying now
<sfllaw> Does fstab support commas in its type field?
<sfllaw> Bug 44233
<Ubugtu> Malone bug 44233 in util-linux "mount udf dvd fails, possible wrong fstab entry" [Normal,Unconfirmed]  http://launchpad.net/bugs/44233
<pitti> sfllaw: yes
<sfllaw> Neat.  Thanks.
<pitti> sfllaw: things like 'udf,iso9660' are quite common
<seb128> pitti: 
<seb128> < /usr/share/locale-langpack/fr/LC_MESSAGES/debhelper.mo
<seb128> < /usr/share/locale-langpack/fr/LC_MESSAGES/debianutils.mo
<seb128> < /usr/share/locale-langpack/fr_FR/LC_MESSAGES/pmount.mo
<seb128> is that normal ?
<pitti> seb128: the first two are, I removed some cruft
<pitti> but pmount???
<pitti> seb128: for -de, pmount is in the new debs, but not in the old
<seb128> it's from language-pack-fr-base_6.06+20060511_all.deb 
<tseng> pitti: is beagle .pot all good now?
<pitti> tseng: will look in a minute
<seb128> hum
<seb128> pitti: it was to fr_FR and fr, the first one got dropped, no worry
<pitti> aah
<seb128> $ dpkg -L language-pack-fr-base | grep pmount
<seb128> /usr/share/locale-langpack/fr/LC_MESSAGES/pmount.mo
<seb128> /usr/share/locale-langpack/fr_FR/LC_MESSAGES/pmount.mo
<tseng> pitti: danke sehr
<pitti> seb128: right, I removed some country spedific translations from pmount
<seb128> good
<seb128> < /usr/share/locale-langpack/fr/LC_MESSAGES/fakeroot.mo
<seb128> < /usr/share/locale-langpack/fr/LC_MESSAGES/ivman.mo
<seb128> too
<seb128> probably normals too
<seb128> gnome package has that:
<seb128> < /usr/share/locale-langpack/fr/LC_MESSAGES/dasher.mo
<seb128> > /usr/share/locale-langpack/fr/LC_MESSAGES/workrave.mo
<seb128> 
<pitti> for me, dasher was added, workrave removed
<seb128> is the dasher.mo dropping normal?
<pitti> hm, so it's exactly the other way round for me
<pitti> oh, no
<seb128> weird
<pitti> silly me, I used debdiff in wrong direction
<pitti> so, adding workrave is good
<pitti> seb128: and dasher is in universe, so it was removed
<seb128> rock
* seb128 installs then
<pitti> seb128: thanks for the review
* pitti is content with German debdiffs, too
<seb128> np
<pitti> carlos: can you please mark 'mesa' as not to be exported into langpacks?
<pitti> carlos: oh, hmm, that might have come from my tarball actually
<pitti> carlos: yes, indeed; ignore me, please
<Riddell> pitti: that doesn't seem to fix the missing kde strings
<Riddell> pitti: can you get me the french version of kdelibs.po?
<carlos> pitti: ;-)
<pitti> Riddell: http://people.ubuntu.com/~pitti/tmp/kdelibs.po
<carlos> Riddell: Rosetta is exporting kdelibs.po files...
<seb128> pitti: update works great, fix minor issues I noticed over the desktop (strings not translated mainly) :)
<pitti> yay
<Riddell> carlos: something is going missing though.  it's probably my fault, I need to check
<carlos> seb128: is it a regression?
<carlos> Riddell: https://launchpad.net/distros/ubuntu/dapper/+source/kdelibs/+pots/kdelibs
<seb128> carlos: what?
<seb128> carlos: I just said the update works great
<carlos> oh, sorry, this update adds new translations
<carlos> I misread your text :-P
<carlos> Riddell: that's what Rosetta has atm
<seb128> np ;)
<seb128> carlos: do we have a way to upload upstream .po saying to overwritte rosetta changes?
<Riddell> carlos: does rosetta import the .pot files each time I upload a package?
<carlos> seb128: yes, upload it without setting the 'published' flag
<carlos> Riddell: yes, it's done automatically
<seb128> carlos: k, I'm thinking to do that for the whole GNOME for the french translations...is that a good idea? :)
<carlos> seb128: that will give karma to the GNOME translators and I guess you should agree it with the other team members
<carlos> seb128: other than that, I suppose is ok
<seb128> carlos: right, but we have enough "rosetta lower level of translations" complain upstream and to the Ubuntu list
<seb128> that will probably make people happy for dapper
<carlos> seb128: take into account that if the .po files you are going to upload has untranslated strings and Rosetta has translations for them, with that use case, you will disable those translations too (will remain as suggestions, but you will leave them empty(
<seb128> carlos: why?
<carlos> seb128: you should then start removing permissions from people to keep bad translations out of Ubuntu...
<Diziet> mvo: ping
<seb128> carlos: and if the upstream po doesn't contain those strings at all?
<Diziet> mvo: I tried that updated Thai patch and it makes it segfault on startup so I think I'll leave it out.
<seb128> carlos: easy to say :)
<carlos> seb128: because we cannot know if you decided to remove it or not, if it's an upstream upload, we keep it, if is not an upstream (published) upload, we do exactly the same as what we do if you use the web form
<carlos> seb128: an easy workaround is to remove the msgid without translations, that will not touch the current translations in Rosetta
<carlos> seb128: this last phrase is the answer to your last question
<carlos> if it's not there, the translation is not touched
<carlos> seb128: yeah, I know it's easy to say, but the problem is that people see Ubuntu's translation teams like usual translation teams and they are QA translation teams
<seb128> k, thank you
<carlos> you don't need to belong to the team to contribute translations
<seb128> carlos: the issue is that they don't do only QA
<seb128> carlos: is gedit .po is to 60% it's likely to be completed to rosetta first because GNOME guys wait for string freeze usually
<seb128> carlos: and then work is duplicated because we have no easy way to send those 40% to upstream
<carlos> you can download the .po file and send it...
<carlos> but yes, I agree that we need better procedures for that use case
<seb128> carlos: diff of .po is ugly, having a page listing what is different between upstream and rosetta with boxes 'use upstream translation' would be nice
<carlos> seb128: danilo developed a diff script that knows about gettext format
<carlos> I want to integrate it into Rosetta
<seb128> cool
<Riddell> hmm, the po download function from rosetta seems very slow
<pitti> tseng: yep, pot file is built now
<pitti> Riddell: did you see any regression in the current packages, or just not enough improvement?
<Riddell> pitti: not regressions, just doesn't fix the problem of missing strings
<pitti> Riddell: are they missing in the POT perhaps?
<pitti> Riddell: so, would you say they are good to upload?
<Riddell> pitti: that's what i'm trying to find out, but rosetta seems not to be sending me the e-mail so I can download the .pot
<Riddell> pitti: sure, fine to upload
<pitti> Riddell: that'll take ~ 5 minutes
<pygi> Riddell, it takes time to get the mail
<pitti> Riddell: see my u-d-a mail, the COTD debs might help to verify when it's fixed
<Riddell> right, got it
<Riddell> carlos: this is interetsing, the kdelibs.pot file that rosetta sent me is empty
<carlos> Riddell: yes, that's a know bug....
<carlos> Riddell: get a .po file, you will get the same information + some translations
<Riddell> carlos: #~ is a fuzzy string yes?
<bddebian> If a package is priority required, it shouldn't need a dependency right?
<carlos> Riddell: no, it's a string that is not in the .pot file anymore (it's called obsolete)
<Kamion> bddebian: it might still need a dependency; you get to leave out dependencies if it's also "Essential: yes"
<bddebian> Hmm
<bddebian> lsb-base is required but not essential :-(
<Kamion> right, you have to depend on it - most dependencies on lsb-base need to be versioned anyway
<bddebian> OK
<bddebian> Thx
<Riddell> carlos: so for some reason all my missing strings are marked as obsolete then
<jordi> Kamion: how are syncs going? are they being processed?
<Kamion> jordi: yes
<jordi> ok, I was wondering about bug 41678
<Ubugtu> Malone bug 41678 in ispellcat "Please sync with Debian unstable" [Normal,Unconfirmed]  http://launchpad.net/bugs/41678
<Riddell> carlos, pitti: is there a way to find the .pot file that is being passed from the buildd to rosetta?
<phanatic> pitti: could you possibly build hungarian (hu) langpacks too?
<pitti> Riddell: yes
<Kamion> jordi: seems to be happily in the queue, we'll try to clear it soon. for a while there was a soyuz problem blocking syncs and it may have been stuck behind that
<Riddell> pitti: could you get me the kdelibs.pot that's being passed to rosetta?
<pitti> Riddell: first, you check the path of the translation tarball at http://people.ubuntu.com/~pitti/langpacks/dload-strippedtar.txt
<mvo> for a progress string, is it "about %s remaining" or "About %s remaining" (assuming %s is "5min")
<mvo> ?
<jordi> Kamion: there's this one too https://launchpad.net/distros/ubuntu/+source/nano/+bug/29732
<Ubugtu> Malone bug 29732 in nano "nano: cannot save in "crontab -e" if backup is enabled" [Normal,Confirmed]  
<pitti> Riddell: and then you grab it from http://people.ubuntu.com/~lamont/translations/
<jordi> which is fixed in Debian, via a dpatch
<Kamion> jordi: if that's a sync request, ubuntu-archive needs to be subscribed to it
<jordi> but debian has a newer upstream version
<jordi> so that'd need a backport
<Kamion> if it's a UVF request, subscribe ubuntu-release and get somebody in ubuntu-core-dev to do the backport
<jordi> I don't know if I'll have the time to write my own in time for dapper
<bddebian> It needs a UVF exception as we only have ispellcat 4.x?
<bddebian>  0.4-6 to be exact
<Riddell> pitti: that says it's Ignoring kdelibs
<Kamion> oh, if it's just a "backport this patch" request, you don't need to subscribe ubuntu-release
<jordi> but I'm pretty confident the new version is good
<jordi> Kamion: I'm asking :)
<pitti> Riddell: yes, for the buildd import, since it only contains pot and no PO files
<pitti> Riddell: http://people.ubuntu.com/~pitti/tmp/kdelibs.pot
<Kamion> jordi: I don't have time personally, but you could ask around
<jordi> can be backported, but the new version has proved rock solid for weeks
<jordi> nod
<Kamion> jordi: oh, right, please make that clear in the bug and subscribe ubuntu-release to it
<jordi> Kamion: do you think a uvf exception would make it, being nano?
<jordi> (rock solid in unstable/etch, that is)
<jordi> Kamion: right.
<Kamion> jordi: depends, might do, it's as much work to answer your question as it is to process the exception request in the first place :)
<Kamion> bddebian: not really, see the text of the bug report
<jordi> :)
<Riddell> pitti: so it'll still import the .pot files?
<jordi> Kamion: I'll subscribe/explain
<bddebian> Kamion: I did but it's still a version jump is it not?
<pitti> Riddell: yes; 'ignored' just means that I don't try to import that tarball, but Rosetta will
<Riddell> pitti: ok, thanks
<tseng> pitti: ok, it doesnt get installed it all
<tseng> pitti: i guess it doesnt matter
<pitti> Riddell: ("I" -> my 'Rosetta emulation' scripts that build a Rosetta-like translation tarball from buildd data)
<robertj> robertj@l3ktr0n:~/cvs/krb5-1.4.3/debian$ /usr/sbin/kadmind
<robertj> kadmind: Permission denied while initializing, aborting
<Riddell> carlos: that imported kdelibs.pot contains the strings, but the exported .po from rosetta has them marked as obsolete
<robertj> hrmm...I think kadmind may be bork
* bddebian crawls back into his hole
<Riddell> carlos: maybe the extra header in that .pot file is confusing rosetta?  it's made by doing cat kde.pot >> kdelibs.pot
<Kamion> bddebian: consider a UVF exception granted by me if you want to be picky about it :-) dictionaries are pretty safe
<Kamion> but thanks for being picky, never does any harm at this stage
<robertj> or alternatively when run with sudo kadmind: No such file or directory while initializing, aborting
<carlos> Riddell: phone...
<robertj> bug #44402
<Ubugtu> Malone bug 44402 in krb5 "krb5-admin-server fails during install" [Normal,Unconfirmed]  http://launchpad.net/bugs/44402
<bddebian> Kamion: NP, I can't touch it anyway since it's main.
<Kamion> so it is
<bddebian> Maybe I'll have to shoot for main :-)
<Kamion> ooh, pretty gtk-cancel stock icon
<_ion> Anyone using xinerama? Please help test a xinerama patch for notification-daemon, a patched package is available at http://johan.kiviniemi.name/ubuntu/dists/dapper/notification-daemon/ . See also bug #31433.
<Ubugtu> Malone bug 31433 in notification-daemon "notify bubble has text across screens" [Normal,Confirmed]  http://launchpad.net/bugs/31433
<_ion> s/help //
<mvo> Kamion:  for a progress string, is it "about %s remaining" or "About %s remaining" (assuming %s is "5 minutes")  the correct english term?
<Kamion> mvo: that depends on the context
<mvo> Kamion: as a string in a progressbar (no other text in it)
<Kamion> mvo: I'd use title case then, "About ..."
<mvo> ok, thanks. a trailing "." as well?
<Kamion> "About %s remaining" and substituting in "5 minutes" doesn't sound very localisable though
<Kamion> mvo: I'd say either a trailing ellipsis or nothing
<mvo> yeah, I'm fixing this just now, its how apt historically worked
<mvo> ellipsis == "." ?
<Kamion> although some might disagree with me; I forget whether the GNOME HIG has anything to say about it
<Kamion> no, ellipsis == "..."
<Kamion> "." is "full stop" in en_GB or "period" in en_US
<mvo> Kamion: thanks. I think I go without the ellipsis then
<carlos> Riddell: yes, latest import failed
<carlos> Riddell: check the .pot file with msgfmt -v -c -o /dev/null kdelibs.pot
<carlos> Riddell: if it fails, you need to fix it and upload it again
<carlos> Riddell: if it works, you found a bug
<Riddell> carlos: it fails
<Riddell> carlos: is there a good way to merge two .pot files?
<carlos> Riddell: msgcat
<Riddell> carlos: ok, I use that and now your msgfmt checking command gives me...
<Riddell> msgfmt: kdelibs.pot: some header fields still have the initial default value
<Riddell> msgfmt: kdelibs.pot: warning: PO file header fuzzy
<Riddell>                      warning: older versions of msgfmt will give an error on this
<Riddell> msgfmt: found 1 fatal error
<carlos> Riddell: that's ok
<Riddell> if you say so
<carlos> yes, a .pot file is not supposed to be compiled ;-)
<carlos> without fixing some header values
<carlos> but that allows us to check the syntax of the file
<Riddell> carlos: if I upload this fix can you tell me if it imports correctly
<carlos> Riddell: yes
<yogi> Riddell:Mornin'. Question: I have a shell script on the desktop which changed from its usual icon to one which shows the text preview w/a mere shadow of the former icon superimposed (and hard ts to see).  Is this the 'new icon' or is there something amiss?
<Riddell> yogi: we turned on previews on kdesktop recently
<yogi> Okay... that explains it, I guess.  Took me by surprise. lol.  Thanks.
<yogi> Riddell:Think the kmail filters will be working by release date?? (Hope, hope ;-))
<Riddell> yogi: I agree
<yogi> Riddell: One last observation: I went to konq's View | Previews & cannot seem to turn the desktop proview off.  Where *is* it, please?
<Riddell> somewhere in kcontrol
<Riddell> or probably right click on desktop->Configure
<yogi> Riddell: lol Okay... I'll look around.  Thanks. :-)
<yogi> Riddell: It's too well hidden. lol.  Oh well.  Have a great weekend!
<Diziet> Dammit, how do I get an error message out of this absurd program ?
<Diziet> `Failed' is not an error message!
<Kamion> That rather depends on the program :-)
<yogi> Riddell: Found it. Whew.
<Mithrandir> Diziet: UTSL or strace usually works.
<Kamion> carlos: I'm nearly ready to declare ubiquity's strings final for dapper (they've been nearly final for a while, but I had to make a few last-minute changes)
<Kamion> carlos: would you be able to do another debian-installer import later tonight?
<Kamion> carlos: also, I'd like to get ubiquity's po/ubiquity.pot into Rosetta, so that people can translate the .desktop files; is there anything special I need to do for that?
<Diziet> Mithrandir: Unfortunately the S is huge and of course I've tried strace.
<Diziet> The strace is huge and unenlightening too.
<Diziet> (firefox's automatic plugin installation is what I'm trying to debug.)
<Kamion> oh, been there done that, good luck
<Diziet> (Not that we want people to use it but I'd rather it actually worked.)
<carlos> Kamion: yes, I can do it, when will it be available?
<carlos> Kamion: about ubiquity, I will remove the block we have for it
<Surak> hello all.
<carlos> Kamion: I guess it's already generated on build time, right?
<Kamion> carlos: I have to wait for rookery's mirror to pulse; probably six hours or so, so I'd understand if you wanted to wait for tomorrow morning :)
<Kamion> carlos: please keep ubiquity's debian/po/templates.pot blocked, it's just po/ubiquity.pot I want separately translated
<carlos> Kamion: yeah, tomorrow morning would be better...
<carlos> :-)
<Kamion> if that's possible
<Kamion> carlos: po/ubiquity.pot is part of the source tarball
<carlos> Kamion: and I guess you regenerate it on build time, right?, we should do it to be sure we have latest version of the strings
<Kamion> carlos: I'm not sure, at the moment; it's buried somewhere in automake. If not, I'll sort that out in edgy I think - there are only two strings and they won't change before dapper
<carlos> ok
<Surak> the xorg's postinst script uses debconf to determine which video module is used by that specific hardware. it's something like db_get xserver-xorg/config/device/driver . Does someone know where is this table stored? 
<Kamion> it probably does regenerate them, looking at the Makefile.in.in
<Kamion> s/them/it/
<carlos> Kamion: check with martin if you need help there
<Kamion> will do
<Surak> I got a shipment of 800 motherboards where breezy ati's driver fails. I would like to generate a cd which use the fglrx driver instead of ati. So I need to change that debconf table...
<Kamion> it just stores it in debconf, the debconf database isn't the source
<Kamion> xserver-xorg.config is responsible for working out the default driver
<Kamion> (no, I don't know exactly how; it's in code)
<Surak> yes, it calls the db_get function, isn't it?
<Kamion> yes, but not relevantly
<lucas> any chance those ATI problems will be solved before dapper release ?
<lucas> I'm running into some of them too
<Surak> Kamion: xserver-xorg.config get this answer from debconf. But I have no idea how debconf figures it out
<Kamion> Surak: there's a big table in discover1-data which maps PCI IDs to (among other things) X servers
<Kamion> Surak: no, it *does not* get that answer from debconf
<Surak> ok
<Kamion> debconf has nothing to do with figuring out X servers; it's a generic framework for asking questions and remembering the answers
<Kamion> you probably want to change discover1-data
<Surak> found it. Thanks, that's exactly what I was looking for
<Kamion> but it's possible you'll need to change code in xserver-xorg.config too to add fglrx to the driver list; I'm honestly not sure whether that will be needed
<Kamion> hopefully not
<Surak> the file is /usr/share/discover/pci.lst . Thanks!
<Kamion> np
<Kamion> it's the one thing we still use discover for ...
<Surak> I didn't need to change xserver-xorg.config. Changing the pci.lst was enough. Now I need to build the live cd using the fglrx :-)
<Mithrandir> Surak: what are you trying to do?
<Kamion> Mithrandir: 18:44 < Surak> I got a shipment of 800 motherboards where breezy ati's driver fails. I would like to generate a cd which use the fglrx driver instead of ati. So I need to change that debconf table...
<Surak> Mithrandir: there are some machines where breezy won't start X with the provided drivers
<Mithrandir> Surak: not even if you force it to vesa?
<Surak> in this ati case, no
<Mithrandir> ok
<Surak> I had 1000 motherboards with some sort of unichrome video chip. For that one I compiled the unichrome driver and put it on the x's tree, and everything went fine.
<lamont> pitti: ping
<_ion> mvo: I updated the notification-daemon xinerama patches once more.
<mvo> _ion: thanks, what bugnumber is that?
<_ion> https://launchpad.net/distros/ubuntu/+source/notification-daemon/+bug/31433
<Ubugtu> Malone bug 31433 in notification-daemon "notify bubble has text across screens" [Normal,Confirmed]  
<ivoks> pitti: thanks for rosetta daily :)
<_ion> mvo: I have been running libnotify/tests/test-xy-stress for quite a while now, and i don't see any more bugs.
<pitti> hi lamont
<pitti> ivoks: my pleasure :)
<mvo> _ion: nice, thanks
<ivoks> mvo: hi, i guess you got my mail? :)
<mvo> ivoks: not, I'm drowning a bit currently :/ what was the subject?
<ivoks> mvo: gnome-cups-manager
<mvo> ivoks: I did, yes. haven't managed to look at it yet :( but will do this evening, promised
<mvo> otherwise, keep naging me :)
* mvo has a hard time keeping up
<jsgotangco> hey mvo
<mvo> hello jsgotangco! 
<ivoks> mvo: nag :) (next nag in 5 minutes) :)
<ivoks> mvo: take your time, no rush with this...
<kagou> hey ploum 
<ploum> hey kagou :-)
* Diziet gets the firefox out of the door.  Phew.
<Burgwork> Diziet, would you life be easier if we shipped Epiphany and not FF?
<thom> Burgwork: what are you planning to build epiphany with?
<Kamion> Burgwork: leading question
<Burgwork> thom, I guess I would be saying "would xulrunner be easier to maintain than firefox"
<Burgwork> Kamion, indeed, it is
<_ion> xulrunner 
<Kamion> you're not supposed to admit to asking leading questions, you're supposed to not do it :-P
<Burgwork> lol
<mdke> Amaranth: here?
<thom> Burgwork: maybe when xulrunner is considerably more mature this might be a useful question
* Kamion wonders if Burgwork's life would be easier if Burgwork had a million more dollars
<jsgotangco> Burgwork: Yelp
<mdke> all questions are leading
<_ion> A million dollars would make one's life a lot more difficult.
* _ion is happy he doesn't have so much money.
<ivoks> _ion: when you get it, please send it to me :)
<_ion> ivoks: Ok, will do. ;-)
<Kamion> my point is that asking the person who spends all day wrestling with firefox if his life would be easier if he didn't have to do that is a poor measure of just about anything
<Burgwork> Kamion, ok, fair enough. I guess I should of asked who xulrunner would be to maintain, as compared to firefox
<Burgwork> s/who/how
<Amaranth> mdke: yep
<mdke> Amaranth: you write alacarte right?
* jsgotangco trusts in the lawyer in this channel
<Amaranth> yep
<mdke> cool.
<mdke> Amaranth: a string in the help box contains the word "fd.o", any chance of expanding it so that people can understand what it means?
<Amaranth> freedesktop.org?
<Kamion> Burgwork: fair enough
<mdke> Amaranth: right
<HiddenWolf> :)
<Amaranth> mdke: please file a bug report so i'll remember
<mdke> Amaranth: I can do yeah. But we'll need it quick because there is not much time left for translations
<Amaranth> hrm
<Amaranth> you can upload to main?
<mdke> not me
<Amaranth> i need dholbach
<mdke> everyone needs a dholbach
<dholbach> yeah :)
<dholbach> Amaranth: How can I be of your assistance?
<HiddenWolf> dholbach: clone yourself, and we can all have you? :)
<Amaranth> dholbach: i'm going to make up a small patch to change fd.o to freedesktop.org in alacarte's about dialog
<Amaranth> need you to upload
<dholbach> Amaranth: ok, point me to the patch then
<Amaranth> give me a minute to make it :P
<mdke> Amaranth: rock, thanks. I'll do the string chance announcement for the translators
<Amaranth> all my existing translations just became worthless :P
<mdke> it's only one string though
<Amaranth> dholbach: http://dev.realistanew.com/change_about_dialog.diff
<dholbach> rock on
<mdke> Kamion: got a moment?
<dholbach> Amaranth: done
<Amaranth> cool
<Amaranth> mdke: enjoy
<mdke> Amaranth: dholbach, thanks a lot.
<Amaranth> my first string break since october
<Kamion> mdke: not right now, but tell me what's up and I'll get back to you when I do
<mdke> Kamion: fine thanks
<mdke> Kamion: to get the translations for ubuntu-docs, I download them from rosetta and convert them to xml, then daniel uploads them. As such, they're covered by NonLanguagePackTranslationDeadline, which is next Tuesday. I don't have time to do the downloading and converting exercise during next week, and I'd like to give the translators as much time as possible to get things finished. Do you think I could do it friday/saturday of next week? Or must I do i
<carlos> Kamion: the ubiquity .pot file is now imported
<carlos> Kamion: and include a Spanish translation as a present
<carlos> ;-)
<Kamion> mdke: that's fine - the deadline is primarily to make translators aware that that's how long they've got
<Kamion> (dinner not *quite* ready yet, as it turns out ...)
<mdke> Kamion: thanks a lot
<Kamion> carlos: cool, thanks a lot. How come the existing pt_BR.po doesn't show up? (Maybe you imported 0.99.78 rather than >= 0.99.79 ...)
<carlos> Kamion: any existing translation could take some extra time to be imported
<carlos> first time, we import the .pot file and then we automatically import other .po files
<Kamion> ok, fair enough
<dholbach> have a nice weekend
<wasabi__> Sure wish more people promoted using GCJ/ClassPath vs Sun's JRE.
<nix4me> i have posted bug 43303 and so far noone has confirmed it. Its still set as needs info.  I believe this bug should be confimed and set to priority HIGH because it is certainly a show stopper for the upcoming release. It involves the inability for Ubuntu to share a printer have Windows computers print to it.  I have spent alot of time on troubleshooting and posting information and there are several people who have agreed thus far. I hav
<nix4me> e also been unable to find a workaround. Any help would be greatly appreciated.
<Ubugtu> Malone bug 43303 in cupsys "cupsys can no longer share a printer to windows" [Normal,Needs info]  http://launchpad.net/bugs/43303
<pitti> nix4me: right, I'll mangle the bug a bit; I still don't now the reason, but I agree that it should be fixed for dapper
<nix4me> i would gradly help, but ive done all i can do. Ive tried everything
<pitti> nix4me: milestoned and bumped priority
<nix4me> ok thanks
<nix4me> hopefully we get a fix before my wife needs to print
<nix4me> :)
<pitti> nix4me: still, I don't have any windows machine around here, it'll take me some time to fix this, so help is greatly appreciated
<pitti> nix4me: maybe you can ask upstream already? right now you now more about the bug than I do
<pitti> http://www.cups.org/str.php
<nix4me> i can try
<pitti> nix4me: that would be great
<nix4me> will they look in launchpad if i leave the bug #?
<pitti> nix4me: yes, you should give them an URL to the launchpad bug
<pitti> nix4me: but still, please include the relevant information in the STR
<pitti> like log output, your setup, etc.
<nix4me> ok, ill give it a shot
* pitti hugs nix4me 
<ivoks> pitti: isn't that samba bug?
<pitti> ivoks: no, I think not
<pitti> ivoks: the samba bug is the other way round
<ivoks> pitti: oh, i tought this is something else
<pitti> ivoks: nix4me's one is for printing from a windows machine to a cups server
<pitti> ivoks: the samba bug breaks printing from a cups client to a SMB printer
<ivoks> pitti: yeah, i know (i tought this is that bug)
<nix4me> nope
<ivoks> well... i have windows print to my cups (over IPP)
<ivoks> 1.1.99
<nix4me> oh yeah?
<nix4me> ive been trying for days
<pitti> ivoks: does it still work with 1.2.0-0ubuntu2? (or whatever is current in dapper)
<ivoks> let me test 1.2, i can do it in few minutes
<nix4me> that would be great
<nix4me> maybe i have a setting horked that ive overlooked
<pitti> nix4me: there are too many duplicates of that bug to make me believe in a configuration problem
<pitti> something about printing raw binary streams seems seriously broken
<pitti> printing PostScript etc. seems to be just fine
<pitti> just not binary blobs (as windows clients will do since they usually have the printer driver on the client)
<nix4me> well i agree, but it wouldnt surprise me.  I had this working on my debian 'etch' machine but i had a different probelm, the access log was getting hammered 2 timers per 5 seconds
<pitti> nix4me: that's a different bug, it was solved in dapper, and I also fixed it in Debian experimental
<ivoks> grrr... we have another bug in cups
<ivoks> - no default printer by default :)
<pitti> nix4me: that was gnome-cups-icon polling cups every other second, and the default logging settings made it appear in the logs
<pygi> ivoks: fix it :P
<pitti> ivoks: *sigh*
<pitti> pygi++ :)
<ivoks> ok :)
<pygi> ivoks: thanks :)
<nix4me> i just cant understand why mine wont print
<seb128> pitti: what are you doing on your IRC a friday evening? :)
<pitti> seb128: my gf is tired and just fell asleep, so I do some PostgreSQL hacking
<seb128> ah, k ;)
<pitti> seb128: but, same question to you :)
<seb128> I went to the swimming pool but slightly too late for them, so I took a shower and I'm hanging on the computer now ;)
<ivoks> oh.. error
<ivoks> hm
<ivoks> Missing printer-uri or job-uri attribute!
<nix4me> yes
<nix4me> and i also get
<nix4me> Print-Job client-error-document-format-not-supported
<pitti> ^ that's the 'unable to print binary raw streams' part I mentioned
<pitti> (I think)
<ivoks> lprng anyone? :)
<tritium> sladen: yep, thanks
<ivoks> funny
<ivoks> debug2 shows nothing wrong
<crimsun> pitti: would you please queue http://sh.nu/~crimsun/alsa-utils_1.0.10-1ubuntu13.debdiff?
<pitti> crimsun: done
<crimsun> pitti: thank you :)
<pitti> [queued, not uploaded] 
<crimsun> right
<pitti> crimsun: uploaded, thanks
<crimsun> pitti: you rock :)
<pitti> well, I didn't do much, you fixed the bug! :)
<nix4me> do i still need to file an upstream bug?
<nix4me> on cups
<nix4me> or did ivoks get it fixed?
<pitti> nix4me: did you solve the problem?
<nix4me> nope
<ivoks> nix4me: i won't work on it today...
<ivoks> nix4me: if you have time, try compiling cups without ubuntu patches
<nix4me> ill try
<pitti> good night everyone
<\sh> night pitti sleep well
<crimsun> 'night pitti 
<nix4me> pitti, you think the experimental debian cupsys might work for me?
<\sh> and moins btw :)
<ivoks> pitti: night
<nix4me> ok, night
<pitti> nix4me: it has similar patches, and I don't believe it's due to the derooting (which is the only major difference to debian)
<pygi> night pitti 
<pitti> nix4me: you can try pure upstream if you want (it won't find any PPD files, though)
<pitti> anyway, g'night
#ubuntu-devel 2006-05-18
<Riddell> Kamion: kde ubiquity is good to merge if you're awake
<ryanpg> hi all... I've searched launchpad and found nothing related to an issue I'm seeing: no EXA support with dapper FOSS ati driver and xorg
<ryanpg> radeon m9 chipset
<ryanpg> should I file a bug or check upstream?
<Burgwork> ryanpg, file a bug at the vary least
<Burgwork> s/vary/very
<ryanpg> Burgwork, in launchpad I'm guessing?
<Burgwork> ryanpg, yep
<ryanpg> k
<ryanpg> ty
<mdke> jdub: around?
<jono_> hey
<LinuxJones> hi jono
<jdong> Riddell: will you be upgrading your Ubiquity branch to knits soon?
<Riddell> jdong: knits?
<jdong> Riddell: new bzr 0.8's repository format. faster, fewer total files, takes less space, and makes network fetching a bearable process again :)
<Riddell> jdong: are other ubiquity repositories using that?
<jdong> Riddell: not sure; it's a viscious cycle until everyone switches though :)
<jdong> maybe try to work together with other ubiquity developers to make the switch?
<jdong> bzr.dev switched over to knits quite literally days after it was marked stable
<zul> heylo
<jdong> knits are such a great improvement that there's little reason to use weaves anymore... bzr upgrade magically converts weave repositories to knits
<bddebian> Heya peoples
<jdub> hrm, attempting to find some info about mvo's dist-upgrader - can't see anything obvious on ubuntu-devel
<jdub> can't see packages on his people space
<crimsun> I think what you want is: gksudo "update-manager -d"
<jdub> oh
<crimsun> at least according to http://people.ubuntu.com/~mvo/dist-upgrader/screenshots/dist-upgrader-01.png
<jdub> it's integrated and shit :)
<crimsun> (pulled from a factoid in #ubuntu)
<jdub> thanks :-)
<crimsun> np
* jdub subjects pia to the upgrade ;-)
<crimsun> woo
<ispiked> should I be in here or somewhere else to ask about launchpad?
<ispiked> or rather, Malone.
<bddebian> Depends on the issue but probably #launchpad
<ispiked> anywho, I want to find a bug with "screen" in its summary. how do I do this. "search" seems to jsut search entire bugs.
<ispiked> bugzilla has a far superior search feature, I must say.
<ispiked> maybe I'll just file it and hope someone dupes it to a currently open bug. :)
<bddebian> ispiked: I find 1087 bugs with "screen" in them.  What are you looking for?
<ispiked> bddebian: I resolved it. 
<bddebian> Oh OK, great
<ispiked> yep.
<bddebian> Kamion: Any chance you are here?
<truz24> Are there an oss programs to calculate PI?
<truz24> out to N digits...
<neuralis> truz24: please ask on #ubuntu; this is the wrong channel.
<truz24> I apologize.
<jsgotangco> good morning
<bddebian> Heya jsgotangco
<jsgotangco> hey bddebian good weekend to you!
<bddebian> jsgotangco: You too, thanks
<YokoZar> Hey, I seem to not have a .diff.gz for my package, is there a way to generate one?
<bddebian> YokoZar: Is it a new package?
<YokoZar> Not really, but I updated it in a funny way
<YokoZar> Using dch -v
<YokoZar> I suppose I could just try running uupdate, letting it error out at the diff part, and then copying the /debian directory, right?
<YokoZar> Actually, I suppose I could just try and generate a new diff
<YokoZar> Using diff...
<bddebian> Damn, I need doko
<bddebian> YokoZar: What exactly are you trying to do?
<YokoZar> bddebian: I'm trying to uupdate a package with a new upstream release, but uupdate can't find the diff for the package since somehow I don't have one
<YokoZar> I built the package with -sa before
<YokoZar> So I think there would be no content in the diff anyway
<bddebian> Where did you get the package from?
<YokoZar> These are the Wine packages I make
<mxpxpod> desrt: ping
<lifeless> Kamion: art thou here ?
<jdub> Kamion: unlikely ping?
<jdub> how big is our base install now? (as in debian base packages, not ubuntu-* meta foo)
<infinity> I don't have figures for base, but I can clean up my build chroots and give figures for those.
<lifeless> right, one archive sucker written
<lifeless> infinity: wheres the best place to get a list of all the distribution/component/arch triples we've shipped ?
<infinity> Divine it from the archive layout, or trust the LP database to be accurate.
<lifeless> huh, interesting bit of trivial - across all arches, all of breezy and dapper excluding proposed, there are 91K unique binaries
<infinity> jdub: :
<infinity> 136M    woody
<infinity> 209M    warty
<infinity> 217M    sarge
<infinity> 218M    hoary
<infinity> 259M    etch
<infinity> 269M    sid
<infinity> 270M    breezy
<infinity> 295M    dapper
<infinity> jdub: Not sure how accurate that is (I may have some stray cruft in those chroots I didn't find when cleaning), but it's likely close.
<LaserJock> can anybody confirm that dselect is used in the installer?
<infinity> jdub: Those are buildd chroots, so that's just Essential+Build-Essential
<jdub> infinity: thanks
<infinity> For the record, though I've since deleted it, potato was under 100MB...
<infinity> I think it's time for us to start slimming again.
* infinity starts a "putting the base system on a diet" spec for Paris...
<Mithrandir> LaserJock: it's not.
<LaserJock> Mithrandir: not in the text installer?
<Mithrandir> LaserJock: no, it gives you aptitude, not dselect.
<jsgotangco> dselect is not used at all right?
<infinity> I use dselect all the tim!
<infinity> s/tim/time/
<infinity> But no, the installer doesn't use it anymore.
<infinity> Hasn't for a long time.
<jsgotangco> even upstream right?
<infinity> sarge's installer may still give the option to pop you into one or the other, I don't recall.
<Mithrandir> upstream as in Debian?  They do the same as us there, iirc.
<infinity> Etch should be all aptitude, all the time.
<Mithrandir> yeah, sarge gives you the option, but I think it went away with base-config.
<jsgotangco> thanks, im actually the one who asked LaserJock first because im doing a small article
<infinity> OTOH, dselect still rocks out with its (censored) out, in certain situations.
<infinity> So, I'm still madly in love with it for unsnaring ugly upgrade scenarios.
<jsgotangco> i needed to make sure because in the back of my mind i know its aptitude at work
<jsgotangco> seems to be quite flexible
<lifeless> hmm, language packages seem somewhat weird
<lifeless> E:Cannot find chunk data.tar.gz
<lifeless> lamont: btw, *how* many getTranslations process do you expect on rookery ?
<_ion> /summon keybuk
<_ion> I built uqm 0.5 and vim 7 from debian for dapper, in case anyone's interested. http://johan.kiviniemi.name/ubuntu/
<crimsun> using Debian experimental's source packages?
<_ion> For vim, yes.
<crimsun> cool
<_ion> seveas: I updated to falcon 0.11. Seems like it works when i have the following directory structure: pool/dapper/falcon.ini, pool/vim/, pool/dapper/vim  ../vim, but it doesn't work if there's no pool/vim/ and pool/dapper/vim/ is a directory, not a symlink. Is that intentional?
<Seveas> no
<Seveas> what is the problem/error?
<Seveas> btw: you need 0.11.1
<Seveas> there was a bug in 0.11 that could have caused this
<_ion> % bzr pull
<_ion> Using saved location: http://www.kaarsemaker.net/files/Software/falcon/
<_ion> 0 revision(s) pulled.
<Seveas> ok, then you have the latest 
<_ion> Well, it says 0.11, not 0.11.1
<Seveas> hmm, forgot to bump the version number in conf.py.in
<Seveas> but that's no big deal
<Seveas> what is the problem you face? 'does not work' is not really descriptive 
<_ion> http://johan.kiviniemi.name/tmp/falcon-update-dirs.log
<_ion> http://johan.kiviniemi.name/tmp/falcon-update-symlinks.log
<Seveas> interesting
<Seveas> could you try with falcon --verbose
<Seveas> and could you give me the ls -l of pool/dapper/
<_ion>     sections = [ dir for dir in os.listdir(os.path.join(falcon.conf.basedir,'pool', r))
<_ion>                  if os.path.isdir(os.path.join(falcon.conf.basedir,'pool',dir)) ] 
<_ion> Shouldn't that be os.listdir(os.path.join(falcon.conf.basedir,'pool', dir, r)?
<Seveas> no
<Seveas> r == release
<_ion> Whoops.
<Seveas> (fwiw: it works fine for me with both symlinks and dirs
<Seveas> )
<_ion> What i was supposed to say: shouldn't that be os.path.isdir(os.path.join(falcon.conf.basedir,'pool',r,dir))?
<Seveas> hmmm
<Seveas> that sounds correct
<Seveas> but then again: why does it work for me 
<Seveas> ah, because I am using links and dirs with the same name
<Seveas> fix pushed to bzr
<pygi> Seveas, heh :)
<Seveas> thanks!
<_ion> :-)
<_ion> It works now. 
<_ion> seveas: Hm. It seems like the update action doesn't recreate the HTML files anymore.
<_ion> 'falcon update html' does what just 'falcon update' used to do.
<_ion> http://johan.kiviniemi.name/ubuntu/dists/dapper/w32codecs/
<Coyctecm> _ion from finland? :)
<_ion> coyctecm: Yep.
<Coyctecm> _ion: nice :) me too :)
<Kamion> lifeless: language packs use data.tar.bz2
<lifeless> Kamion: thanks :). Bug #44493
<Ubugtu> Malone bug 44493 in python-apt "apt_inst.debExtract is unhelpful for packages with data.tar.bz2" [Normal,Unconfirmed]  http://launchpad.net/bugs/44493
<Kamion> Riddell: thanks, will merge. I'll move to knits as soon as I've upgraded my development box to a version of bzr capable of using them :) oh, and probably need to make sure rookery is updated too
<Kamion> jdong: ^--
<ajmitch> morning Kamion 
<Kamion> morning
<lifeless> rookery is at 0.7pre
<lifeless> definately needs some luvin
<Kamion> my push script relies on ssh rookery bzr revert, which I'm assuming requires a knit-capable bzr
<Kamion> I'll file an RT request to upgrade that
<lifeless> you can install bzr in your home dir in the interim
<Kamion> faff
<lifeless> faff ?
<Kamion> fiddly effort with little gain
<lifeless> righto
<Kamion> I've filed the RT request, by the time I care I expect it'll be done
<_ion> seveas: From the changelog i noticed that it's intentional that update doesn't create the HTML files. That's fine, but falcon --help shouldn't lie. :-)
<roico> why was filight 7, which is "alpha", released after beta2?
<Kamion> roico: because the effort of releasing a beta (with extra QA) is considerable, but we wanted to get another test release out there
<Kamion> with slightly less effort involved on the part of the release and core dev teams
<Kamion> there'll be a flight 8 too
<Kamion> we've done something similar with every previous Ubuntu release; it's just that we used to call it "preview" rather than "beta"
<roico> ummm ok... =\
<roico> will there be beta 3?
<Kamion> probably not
<Kamion> flight 8, release candidate, release
<Kamion> I expect
<Kamion> woo, task overrides in the archive fixed
* Kamion crosses off another todo item
<lifeless> :)
<Kamion> and xubuntu tasks are there now too
<Kamion> Riddell,Mithrandir: OK, I hope you guys are using bzr 0.8, since I'm upgrading ubiquity to knits now :-)
<Mithrandir> Kamion: I'm running dapper on all boxes I use for development, so yes.
<Kamion> good
<Riddell> Kamion: anything special I need to do to convert?
<Kamion> Riddell: 'bzr upgrade', I believe
<Kamion> <cjwatson@cairhien ~/src/ubuntu/ubiquity/ubiquity>$ du -s .bzr.backup
<Kamion> 34744   .bzr.backup
<Kamion> <cjwatson@cairhien ~/src/ubuntu/ubiquity/ubiquity>$ du -s .bzr
<Kamion> 24736   .bzr
<Kamion> not bad
<mdke> jdub: if you pick this up, can you change the details for my blog on planet? thx
<crazy_penguin> sorry dor intruding. i want to say only this. Thank you guys for this excellent distro and for your hard work. :) Thank You!
<crazy_penguin> dor=for
<ompaul_isfair> wats dor=for?
<crazy_penguin> i was misstyping
<crazy_penguin> sorry
<ompaul_isnotfair> ah ok 
<crazy_penguin>  it was for this: "sorry dor intruding. i want to say only this. Thank you guys for this excellent distro and for your hard work. :) Thank You!"
<ompaul_isnotfair> everybody is sleeping?
<ompaul_isnotfair> yeah the best distro around
<ompaul_isnotfair> i was wondering who can i give you people a helping hand?
<ompaul_isnotfair> i am into website design and administration
<jsgotangco> ompaul_isnotfair: http://www.ubuntu.com/community/participate
<ompaul_isnotfair> thanks jsgotangco
<ompaul_isnotfair> hi pygi
<pygi> hi ompaul_isnotfair
<pygi> whats up_
<pygi> ?
<ompaul_isnotfair> nothing am getting bored
<pygi> ompaul_isnotfair, nice :)
<ompaul_isnotfair> not much chatting around here
<ompaul_isnotfair> whats up on your side?
<pygi> currently some C#/Mono hacking
<pygi> (Diva thingy)
<ompaul_isnotfair> u must be a real geek
<pygi> lol
<ompaul_isnotfair> are u into ruby?
<ompaul_isnotfair> am trying to learn that
<pygi> no, I never tried it, and never will
<ompaul_isnotfair> why?
<pygi> just because :)
<pygi> No need to learn 9999999 amount of languages
<ompaul_isnotfair> yeah i guess so
<ompaul_isnotfair> are u into python?
<_ion> Ruby rules.
<pygi> indeed, but you should rather get someone else to learn you python right now :P
<pygi> _ion, yea, yea, whatever :P
<_ion> I used to think python rules, but then i learned ruby and saw how much python really sucks. :-)
<ompaul_isnotfair> hehe flamewars! i luv em
<pygi> no flamewar needed
<pygi> heh] 
<ompaul_isnotfair> wat about lisp?
<pygi> this is offtopic for this channel
<jsgotangco> please chekc topic
<ompaul_isnotfair> the geeks love it.. dunno why
<ompaul_isnotfair> ok
<pygi> jsgotangco, nice, thanks :)
<ompaul_isnotfair> where are u from pygi?
<pygi> that is offtopic 
<pygi> for this channel
<ompaul_isnotfair> sorry
<ompaul_isnotfair> who decides when to release drapper? shuttleworth?
<pygi> hurg? It will be released next month, 1 day
<pygi> that is for #ubuntu
<ompaul_isnotfair> yeah but am banned there
<pygi> no wonder :P
<ompaul_isnotfair> even #ubuntu-offtopic
<ompaul_isnotfair> u think am trolling right now?
<thoreauputic> ompaul_isnotfair: you stole a nick - that's not on anywhere
<mdke> ompaul_isnotfair: not trolling, but the developers tend to like this channel to be kept clean, because they read the log. It's best to chat in another channel
<ompaul_isnotfair> i know but since no one was chatting i thought i was not disturbing sorry
<mdke> ompaul_isnotfair: no problem at all, don't worry
<ompaul_isnotfair> mdke : any suggestions ?
<mdke> ompaul_isnotfair: what about?
<ompaul_isnotfair> mdke : another channel to chat
<mdke> ompaul_isnotfair: #ubuntu or #ubuntu-offtopic are the ubuntu related channels which you should try. If you're banned, try and talk to an operator to resolve it
<ompaul_isnotfair> mdke : its no use .. he won't listen.. dats why i was protesting.. anyway i'll find out
<ompaul_isnotfair> mdke : appologises for disturbing u people
<mdke> ompaul_isnotfair: ok, np
<ompaul_isnotfair> u are doing a great job
<sladen> ompaul_isnotfair: 2006-06-01
<ompaul_isnotfair> :) can't wait
<bddebian> Morning
<pygi> mornin to you bddebian 
<bddebian> Hello pygi
<pygi> wb JaneW 
<lifeless> mvo: around ?
<mdz> morning folks
<mvo> lifeless: sort of, what can I do?
<ogra> mdz, oh, so you found network connectivity ? or did you stay at home ? 
<doko> network connectivity is slow, but seems to work; at least in the morning if nobody is awake
<ogra> isnt it 9am there ? 
* ogra would guess there are people awake at this time 
<Evaso2> please take care of this bug  6017 on launchpad seem solved upstream but i dosen't know if the maintainer is still active in ubuntu
<Ubugtu> Malone bug 6017 in foo2zjs "Update to latest package to make HP LaserJet 1020 work" [Normal,In progress]  http://launchpad.net/bugs/6017
<Evaso2> this issue doesn't let to print with hp 1020 on ubuntu breezy and dapper
<doko> infinity: is this the second OOo build on i386?
<bddebian> doko: Did you see Bug #35196?
<Ubugtu> Malone bug 35196 in eclipse "Rebuild against firefox" [Normal,In progress]  http://launchpad.net/bugs/35196
<doko> bddebian: stay away, it doesn't work. you can easily test this by building with firefox and then trying to use the help
<bddebian> doko: OK, thanks.  Sorry to subscribe you to that
<doko> hopefully will be fixed in edgy with xulrunner
<bddebian> OK, should I reject that one then?
<doko> no, why? it's at least a wishlist request
<bddebian> doko: OK
<sladen> ogra: do you not sure dpatch for gnome-screensaver?
<ogra> its cdbs
<infinity> doko: Yes, it failed with... Wait for it... A SIGABRT... Same as the OOo-l10n builds previously did.
<sladen> ogra: where are the broken out diffs?
<sladen> ogra: a lot of the hacks from the straight Debian version aren't being built, but I can't find any reference to what was changed
<ogra> sladen, gnome-screensaver-2.14.1/debian/patches/
<ogra> err, hacks are not gnome-screensaver
<sladen> ogra: g-screensaver is just using the hacks from /usr/lib/xscreensaver ?
<ogra> they are xscreensaver and there is no patch system in it anymore
<sladen> ogra: which are built from the 'xscreensaver' package;  debian version was 4.23-4, but that's no longer in the debian archive to diff against
<ogra> i once added dpatch and debian complained very loudly that we shouldnt just change theor packages
<ogra> so it switched it back with the beginning of dapper
<sladen> ogra: $developer_developer needs smacking over the head with a sledgehammer
<ogra> heh
<sladen> $debian_developer
<doko> infinity: nice :-/
<ogra> but to be honest, there are not much changes to the hacks themselves 
<sladen> aside from that, I think it would be best to use some sort of dpatch system;  maintain and rebasing is hell otherwise
<infinity> doko: If this fails again, I'll do a manual build for you and keep the broken bits.
<ogra> most changes i did this release are made to control, rules and the default settings
<ogra> yep, agreed
<infinity> doko: Since it failed much earlier than OOo-l10n, it might be a bit less painful to reproduce (failed in ~6 hours)
<sladen> ogra: probably being at the moment I can't make a diff of what has changed between the Debian and current Ubuntu version before it's not possible to get hold of the Ubuntu version it was based off
<sladen> s/probably/problem/
<ogra> especially since our package differs completely from debians now
<sladen> ogra: do you have any of  4.23-4 left on your hard-drive?
<infinity> sladen: Grab the old Debian version from snapshot.debian.net to diff against.
<infinity> sladen: Much easier than guessing.
<ogra> sladen, will look
<ogra> might be its in my other office on the desktop machine i havent here
<ogra> i usually keep the sourcepackages around anywhere
<infinity> http://snapshot.debian.net/archive/2006/01/13/debian/pool/main/x/xscreensaver/
* infinity goes back to bed.
<sladen> infinity: just found it.  thanks for the reminder/pointer
<sladen> ogra: okay found it;  it's as simple as most of them being moved to 'xscreensaver-data-gl'
<ogra> nope
<ogra> there are also -data-extras and data-gl-extras
<ogra> there are nore moved into the -extras packages (universe) the non-extra ones contein the set we ship since warty 
<ogra> s/nore/more/
<ogra> also have a look at the gnome-screensaver-helper dir in xss's debian dir, that contains the files used by g-s-s
<mxpxpod> desrt: ping
<desrt> mxpxpod; pong
<mxpxpod> desrt: you have ae working with nm?
<desrt> mxpxpod; no.
<desrt> mxpxpod; i found a bug in nm that broke it on powerpc but i believe there are still others
<mxpxpod> hrmm
<mxpxpod> ok
<desrt> mxpxpod; so i gave up and switched to using wpa-supplicant manually
<mxpxpod> aha
<mxpxpod> and that works?
<desrt> ya
<mxpxpod> sweet
<desrt> works very nicely
<Chipzz> hrrrm sorry for the off-topic-ness, but does anyone know of a program that does the same as "bigecho" onder dos, or a font/option to figlet to have it output fixed-width charachter?
<mxpxpod> desrt: how do you invoke wpa_supplicant?
<desrt> mxpxpod; you have to write a config file for it...
<desrt> lemme post my stuff
<mxpxpod> suckage
<mxpxpod> ok, thanks
<Treenaks> desrt: you can do that through /etc/network/interfaces though
<Treenaks> desrt: (afaik?0
<ogra> erm, AE works here out of the box with NM
<ogra> (iBook G4)
<desrt> http://desrt.mcmaster.ca/random/wpa/
<desrt> mxpxpod; that's the conf file and the script i use (does wpa + dhclient)
<mxpxpod> thanks
<mxpxpod> ogra: how'd you get that working?
<ogra> mxpxpod, installing my firmware and select my network
<ogra> nothing more
<mxpxpod> strange...
<ogra> but i'm not using wpa at all
<mxpxpod> ogra: yeah, mine doesn't even work without wpa or wep
<mxpxpod> desrt: does that config work with wep?
<ogra> (in fact i dont know *anybody* presonally using wpy=)
<ogra> *wpa
<desrt> mxpxpod; well
<desrt> mxpxpod; assuming you put in actual ssid's and passkeys, yes :)
<mxpxpod> desrt: :)
<desrt> mxpxpod; those two networks are my home and work networks
<desrt> mxpxpod; it autodetects and connects to whichever one
<mxpxpod> desrt: and how about non-encrypted networks?
<desrt> mxpxpod; uhm... i don't know how to connect to non-wpa networks :)
<mxpxpod> heh
<desrt> mxpxpod; if you find out, plz let me know :)
<mxpxpod> will do
<mxpxpod> hmm, so that *sort of* worked
<mxpxpod> ae with nm for unencrypted
* ogra waves from the same setup
<ogra> it sometimes needs a little push (second attempt) to get the dhcp negotiation done in time
<kapputu> Hi guys
<kapputu> anyone looking for a deck hand?
<mxpxpod> ogra: the signal kept coming and going, and I know for a fact that this is a strong signal
<kapputu> mxpxpod: aliens?
<kapputu> :-)
<ogra> oh, right
<mxpxpod> kapputu: hmm...
<mxpxpod> kapputu: you may be on to something
<ogra> mxpxpod, i forgot to mention the signal meter of the NM applet doesnt work at all for me here
<kapputu> mxpxpod: or I'm on something 
<ogra> but thats a known missing feature in the softmac implementation afaik
<mxpxpod> ogra: nice
<jdong_> is there any VCS branch for linux-restricted-modules?
<_ion> The concept of Frank Schoep's "minimalistic" usplash theme in bug #44339 is really excellent IMO.
<Ubugtu> Malone bug 44339 in usplash "Regression in usplash artwork" [Normal,Confirmed]  http://launchpad.net/bugs/44339
<infinity> _ion: Yes, but not happening for dapper.  Not sure how many times this needs to be said.
<infinity> _ion: We currently rely on the fact that usplash has text output (we even use it for prompting on the LiveCD), so it's not changing in the next 3 weeks.
<infinity> jdong_: No, I don't maintain it in any VCS... What's in the archive is what's current.
<infinity> jdong_: What do you need to know?
<jdong_> infinity: nothing really; I'm just maintaining a customized kernel extremely similar to the Ubuntu kernel, and I was just getting l-r-m for it
<infinity> jdong_: Ahh.  Well, I could import it into git at some point, but there's not much point, since it doesn't change as rapidly or drastically as the kernel itself does.
<infinity> jdong_: It's probably trivial to just track uploads and debdiff occasionally when you're stumped. :)
<jdong_> infinity: I don't really have a preference either way; I'm currently bzr'ing it just for easier merging for my branches
<jdong_> it's fine the way it is
* infinity nods.
<jdong_> infinity: what are the redistribution restrictions on l-r-m?
<_ion> infinity: One idea comes to mind: setting priorities to all the log_*_msgs and printing only the ones higher than a certain priority. If log_end_msg is called with a non-zero parameter, the previous log_begin_msg should be printed no matter the priority. For backward compability it could be set using an env var, for example 'LOG_PRIO=normal log_begin_msg "Starting foobar daemon"' would be equivalent to not setting LOG_PRIO at all, and the prompting ...
<_ion> ... on the Live-CD could be done using 'LOG_PRIO=important log_action_msg "You have ten seconds to run before your computer self-destructs"'. 
<infinity> jdong_: You'll have to check debian/copyright.  I don't recall all the horrible licenses off-hand.
<desrt> ogra; word.
<infinity> _ion: Currently, our init scripts are aiming for LSB compliance.  That would have us forking from standard yet again for no real benefit.
<infinity> _ion: Anyhow, using usplash for prompting can and will be changed AFTER RELEASE.  Nothing like this will be changed in dapper.  We have real bugs to fix that don't cater to people's offesne at the aesthetics of a screen they see for 20 seconds every few days when they choose to reboot.
<desrt> who is responsible for the new splash screen?
<sladen> infinity: I hope the screen does get fixed.  It's the first thing people see of Ubuntu.
<desrt> it's pretty
<infinity> sladen: It'll likely change again, but not to something without text.
<infinity> sladen: (Which is what _ion is advocating)
<infinity> sladen: It'll get replaces with something with a correct aspect ratio and colours that don't make my eyes bleed, I suspect.  S'about it.
<_ion> Well, was. :-)
<infinity> sladen: There's a nice one submitted to the bug report mentioned above.
<sladen> infinity: that's what I'm advocating, yes
<mdke> it's really fuzzy the image too
* desrt doesn't understand the 'no text on bootup' thing
<mdke> badly defined edges and so forth
<mdke> dunno if that can be fixed or not
<sladen> infinity: and failing anything else, a revery would fix the situation
<sladen> revery
<sladen> revert
<desrt> even if you completely _do not_ understand what the text means it's still nice to have something to tell an expert about when your computer locks in the middle of boot
<Burgundavia> desrt: if you make it simple to show the text, there is no reason to show it
<sladen> desrt / Burgundavia: dapper +1
<infinity> Burgundavia: I kinda like the "ooh, my computer is doing cool computer stuff" effect, even if I don't understand it.
<_ion> desrt: Well, "no unnecessary text on bootup". E.g. error messages (that obviously should be printed) would be more distinguishable if there weren't any redundant lines.
<infinity> But I realise I'm in a minority here, and will bow to the "no text by default crowd" for Edgy, I'm sure.
<desrt> _ion; lockups don't give error messages
<_ion> desrt: If the computer locks up, then you'd boot without splash or switch to a virtual console before the lockup to see what's going on.
<desrt> _ion; but with a continuous "i'm doing this, i'm doing that, ..." output you can guess where the lockup is around
<sladen> I think the "fail" text could do with being changed to the same colours as success
<sladen> or even "ok" on success and "(null)" on fail
<desrt> too scary?
<desrt> i say, make it blinking bright red and change the text to read "YOUR COMPUTER WILL EXPLODE"
<desrt> Couldn't connect to the net to sync with the timeserver... YOUR COMPUTER WILL EXPLODE!
<desrt> etc
<_ion> :-D
<_ion> Hmm. There seems to be a xvidcap source package, but no binary package. https://launchpad.net/distros/ubuntu/+source/xvidcap
<infinity> _ion: Because it's in dep-wait on a package that doesn't exist? (libavcodec1-dev)
<infinity> _ion: An upload to change that build-dep to libavcodec-dev might make it happy.
<_ion> I'm just testing whether it builds with libavcodec-dev.
<pygi> hi rajasun 
<pygi> gah, sorry :P
<pygi> hi raphink 
<raphink> hi pygi
<pygi> how are you? :)
<raphink> I'm good thanks
<raphink> you?
<pygi> good as well :)
<raphink> good :)
<_ion> Hm. Building xvidcap dies with a bunch of lines like xvidcap-mngutil.o: In function `mng_write_sig':/home/ion/src/xvidcap/xvidcap-1.1.3/src/mngutil.c:49: undefined reference to `png_write_data'
<infinity> Sounds like it wants a -lpng but doesn't have one (if I had to guess)
<_ion> infinity: Nope, that's not the problem.
<_ion> % grep -c png_write_data /usr/lib/libpng.{a,so}
<_ion> /usr/lib/libpng.a:3
<_ion> /usr/lib/libpng.so:0
<_ion> I'm very tired now, but maybe i'll try to fix that tomorrow.
<infinity> png.h:PNG_EXTERN void png_write_data PNGARG((png_structp png_ptr, png_bytep data,
<infinity> It's definitely missing a -lpng
<_ion> No, it isn't. :-)
<infinity> In other news, why do they redefine png_write_data (and others) in mngutil.c?
<infinity> Ugly.
<_ion> Ugly indeed.
<_ion> Also the compilation of every single .c file in xvidcap seems to throw a bunch of warnings. :-)
<infinity> Shocker.
<infinity> I've looked at exactly one file (mngutil.c), and it made me want to vomit, so I'm stopping.
<_ion> :-)
#ubuntu-devel 2006-05-19
<bddebian> infinity: Still here?
<bddebian> ANyone know what bpftopcf was/is?
<crimsun> is that a typo for bdftopcf?
<infinity> bddebian: It's an X font converter to convert from, oddly enough, bdf format to pcf format.
<bddebian> Sorry, I meant bdftopcf
<bddebian> Ah, it's it's own package now.. Hmm
<infinity> "it's its"
<bddebian> Whatever :-)
<infinity> </nazi>
<bddebian> Hah, take that you fscking bug!
<bddebian> Thx gents
<tepsipakki> shouldn't "ubuntu members" get a @ubuntu.com address?
<pygi> tepsipakki, this is not channel for this
<tepsipakki> oh?
<tepsipakki> which one is?
<mdke> well, there isn't one
<mdke> tepsipakki: they do get one
<tepsipakki> mdke: so, where do I get mine?-)
<mdke> tepsipakki: it is tepsipakki@ubuntu.com
<tepsipakki> hmm
<tepsipakki> ok, that looks way cool ;)
<tepsipakki> if it works
* bddebian 's hasn't worked for over a year
<mdke> bddebian: sure?
<bddebian> Yep
<mdke> bddebian: so you didn't get that mail I just sent you?
<tepsipakki> mdke: ok, works ;)
<tepsipakki> my sieve-receipts suck
<bddebian> mdke: Hey, who fixed that?
<mdke> bddebian: magic elmo 
<bddebian> Coolio, he told me he wasn't going to do it
<mdke> although to be fair, if it was broken a year ago, it's likely to have been fixed quite a long time ago
<tepsipakki> is the irc-nickname only address that works?
<bddebian> I was getting bounces like 2 weeks ago
<infinity> I assume it's the LP username that is used to map.
<infinity> But I could be wrong.
<tepsipakki> ok, my bad then
<mdke> yeah, it's on LP username
<mdke> and it goes to your preferred LP email address
<mdke> so *don't* set that to your ubuntu address
<tepsipakki> (_why_ did I standardize on this silly nick..)
<tepsipakki> ;)
<mdke> tepsipakki: if you change your LP username, it should work after that, although I dunno how long it will take to sync up
<tepsipakki> ok, I'll see
<infinity> timo.aaltonen may work as well, I'm not sure if elmo did full name mapping automagically though.
<mdke> I don't think so
<mdke> that's just for you guys
<infinity> Yeah, we're full name by default, short nick is optional.
<infinity> Guess that somewhat avoids namespace clashes to do you guys the opposite.
<bddebian> tepsipakki: How do you think I feel about doing Ubuntu work with a bddebian nick??  Hell I have have a domain name with it :-(
<bddebian> elmo: Thanks
<_ion> :-)
<infinity> bddebian: Ubuntu's still Debian under the hood.  No shame in advertising that.
<tepsipakki> anyway, I thought it would need some special trickery to get the address, but now it seems so simple
<bddebian> I know that but it's still a stupid nick :-)
<bddebian> It just stuck
* tseng sets nick bddebian to barry
<infinity> bdfreese would work just as well.
<infinity> No one's stopping you from changing it. :)
<bddebian> I'm lazy :-)
<tepsipakki> I'd just set 'tja'
<tepsipakki> maybe..
<mdke> heh
<tepsipakki> 'tja' is like 'hmmmm' in german
<tepsipakki> or was it swedish
<tepsipakki> offtopic anyway..
<bddebian> How did my .changes get rejected but .dsc and .diff.tar.gz were accepted?  Did I F something up?
<tepsipakki> bddebian: your nick is just fine ;)
<tepsipakki> bddebian: and your domain..
<mdke> mako: not around are you by any chance?
<mdke> mako: wanted to chase up on Listiquette. Lemme know when you have a moment
<lifeless> I have a replaces: question. If I have a package foo_1-1_i386, then decide to move the arch generic stuff out into foo-doc_1-2_all, I use replaces: foo to tell dpkg to transfer ownership of the files.. and upload foo_1-2_i386 without the doc files
<lifeless> what happens if a user installs foo-doc_1-2_all and then tries to install foo_1-1_i386 ?
<tseng> dpkg will allow that
<tseng> but apt-get upgrade will go back to -2
<tseng> dist-upgrade
<lifeless> would it not error ?  foo-doc_1-2_all and foo_1-1_i386 have the same files
<tseng> oh sorry I didnt read completely
<tseng> only the second line
<lifeless> heh
* imbrandon pokes everyone 
<imbrandon> someone got a sec to help me figure out where to look to track down this bug, i can reporduce the bug like clockwork but i have no idea WHY its doing it or what logs / messages to look in to help someon fix it
<imbrandon> hell not even sure what to report it under in launchpad.net
<imbrandon> i dunno what to call it but if you install ( dont even have to use it ) smbfs , hald take a LONG time to start when booting ( like 2 or 3 minutes ) [ this is on upto date dapper , clean fresh install , install smbfs hangs on boot , uninstall it everything is smooth ] 
<imbrandon> not sure what hal ( hardware abstraction layer ) has to do with smbfs and i dont knokw where to look in the logs to be more helpfull but someone could tell me i would be happy to ( the reason i say hal is becouse thats what message it hangs on while booting for like 2 or 3 minutes )
<imbrandon> * message on usplash 
<neuralis> imbrandon: you've confirmed that this goes away when you uninstall smbfs?
<kgoetz> sivang: ping?
<metatag> !seen sabdfl
<kgoetz> metatag: why do you want sabdfl?
<metatag> kgoetz : nothing important just to thank him :) 
<kgoetz> metatag: :) 
<kgoetz> mmm. done that ... once :)
<metatag> kgoetz : really?
<kgoetz> metatag: i got to talk to him at lca2k6
<metatag> kgoetz : oh kewl,, he's friendly?
<kgoetz> yeh
<sivang> kgoetz: pong
<metatag> sivang : ping ?
<sivang> morning sundayers :)
<sivang> metatag: pong
<metatag> sivang : ping
<sivang> metatag: erm, I already said I'm there. Anything you wanted?
<metatag> sivang : ohh pong means you are here .. kewl stuff
<sivang> hey kgoetz , how's it going?
<metatag> kgoetz : ping
<\sh> moins
<sivang> moin moin \sh :-)
<kgoetz> sivang: pong (sorry, was away)
<sivang> kgoetz: np
<kgoetz> I'm trying to remember why i pinged you :$
<kgoetz> it was to do with HUB somehow
<sivang> kgoetz: well, take your time :)
<kgoetz> ta ;)
<kgoetz> hi pitti
* mdke sighs at the endless usplash emails
<Kamion> lifeless: nowadays, dpkg checks replaces in both directions, so when you install foo it'll notice that the installed foo-doc replaces it and will suppress file overwrite errors.
<lifeless> Kamion: sweet
<lifeless> Kamion: so I can ignore that class of bug ?
<lifeless> or is it useful to report anyway ?
<Kamion> what bug?
<Kamion> if foo-doc replaces foo, that discharges its obligation
<Kamion> lifeless: hmm, I sort of see where you're coming from, but I wouldn't start by describing it as a bug :)
<Kamion> lifeless: if the current version of foo in the archive no longer contains those files, all is well, there is no bug, be happy
<lifeless> Kamion: latent problem that can occur on users machines
<Kamion> lifeless: no latent problem exists
<lifeless> Kamion: hmm, the thing is that foo_1.1 might be published in dapper
<Kamion> lifeless: if the current version of foo in the archive still contains those files, then that's sort of a bug, because either they should be removed or foo and foo-doc should conflict
<lifeless> and the better 1.2 in edgy
<Coyctecm> is vim 7 coming for dapper?
<Kamion> lifeless: but it's best not to be too trigger-happy about that; it might be about to be uploaded
<Kamion> lifeless: clearly you need to keep track of what's in what release
<lifeless> Kamion: sure, this is just analysis infrastructure
<_ion> coyctecm: No, but it's available from my repo at http://hassers.fi/ubuntu/
<Coyctecm> _ion: great, thanks :)
<lifeless> Kamion: the question of what to do with the output will need tuning. I'm inclined to describe more issues rather than less, because its easier to filter such things rather than invent them.
<Kamion> lifeless: you have to be very careful what you report, because people *will* mindlessly act on your output without understanding the issues
<lifeless> Kamion: but I'm happy in this case to go 'dpkg will do the right thing', so no problem.
<Kamion> so I think it's actually quite important to describe exactly the right set of issues :)
<Kamion> adding replaces/conflicts can cause problems; it isn't harmless
<lifeless> Kamion: good point. So, I'll start with as much info as possible in the system, and no output. Then start adding output where it is a clear case that its right
<Coyctecm> _ion: too bad it's x86. Well I'll make amd64 package :)
<Kamion> lifeless: yeah, having it all recorded where we can go and look it up would be fantastic, and then bug reporting can be built gradually on top of that
<pitti> hi kgoetz 
<kgoetz> hi
<lifeless> Kamion: yup
<lifeless> Kamion: so back to that point, is that case a useful one to have recorded-but-not-output ?
<lifeless> Kamion: do you know of a python interpreter for the conflicts/replaces etc language ?
<lifeless> Kamion: are there documents somewhere about the problems adding replaces and conflicts can cause ?
<Kamion> lifeless: since dpkg will (now) never display an error in that case, I'm not sure it's useful to record, but I haven't thought about it much
<Kamion> lifeless: not offhand
<lifeless> k
<Kamion> lifeless: I don't know if it's documented, but off the top of my head (a) you might create conflicts/pre-depends loops which the package manager can't resolve (b) adding conflicts vastly complicates upgrades because in some cases you have to temporarily remove packages from the system
<Kamion> lifeless: (c) adding replaces suppresses error handling and therefore shouldn't be done unnecessarily because it might hide errors
<Kamion> (that indicate real problems as opposed to just a file moving)
<Kamion> Riddell: Thanks, I've merged your ubiquity branch. Could you add annotations for the bugs you've closed? It looks like there should be a few ...
<lifeless> Kamion: ok. So having something that checks for such loops would be useful as a post-process for this (a). (b) sounds hairy :(. And for (c) - is using replaces when splitting a packae into two usual ?
<Burgundavia_> Kamion, do you have any idea on when better searching is going to land in Malone? I just filed a bug you marked as dup because I didn't the bleedin dup
<Kamion> lifeless: (b) is why conflicts are bad and hopefully eventually many of their uses will be replaced by Breaks
<Kamion> lifeless: (c) yes
<Kamion> Burgundavia_: no, not offhand - in general I don't mind duplicates though, what I do mind is people wrongly marking duplicates ;-)
<lifeless> hmm, I dont see breaks in policy ?
<Kamion> lifeless: it's not, it doesn't exist yet
<lifeless> ah
<Kamion> it's been designed but never yet implemented; breaks is to conflicts as depends is to pre-depends
<lifeless> so the core of what I'm doing is detecting concurrently installable packages with the same filename
<lifeless> so it should be usable directly for breaks too
<Kamion> Burgundavia_: (in fact, while I appreciate the help, I'd generally prefer that people didn't try to mark ubiquity crashes as duplicates at all - I can handle the load and it takes me longer to try to make sure that people have done it right than to just do it myself)
<Kamion> lifeless: breaks would generally be used for higher-level problems than file conflicts
<Kamion> that aren't automatically detectable in general
<lifeless> Kamion: sure. I can see that
<Kamion> nowadays, replaces should be used for "file moved", and conflicts should be used for "these two packages have the same file"; there should be no need for additional fields to express those
<Burgundavia_> Kamion, ok, no problem
<nomed> Kamion, will ubiquity be themeable for dapper release?
<Kamion> nomed: not beyond gtk theming, no
<Kamion> I have massively more urgent things to worry about than that :)
<nomed> Kamion, yep i see :)
<nomed> i just wanted to know if xubuntu should start thinking on an ubiquity theme .. in this case i guess it'll be edgy stuff
<nomed> thanks
<ivoks> pitti: we have a patch for g-c-m :)
<Kamion> nomed: why would you want to theme ubiquity anyway?
<nomed> Kaloz, xubuntu header for ex ..
<Kamion> nomed: by design it doesn't mention Ubuntu anywhere
<nomed> with xubuntu logo and colors 
<Kamion> so I don't see why it would need to be themed to mention Xubuntu
<nomed> Kamion, yes 
<nomed> Kamion, because i see for ex kubuntu uses an header
<Kamion> yes, I think that's a bug :P
<nomed> with kubuntu logo
<nomed> ehehe
<ogra> Kamion++
<ogra> :)
<Kamion> it makes it harder for others to take the installer and use it for rebranded versions of the distribution
<nomed> and when i checked guadalinex source i've seen is easly themeable
<Kamion> Riddell: ^--
<nomed> but i do not know how much guadalinex code is still there
<Kamion> it's better to remove the need for theming
<Kamion> imo
<Kamion> there is some guadalinex code still there, but there's not a lot of point checking guadalinex source to try to figure out what ubiquity is like nowadays - it will only lead to confusion
<nomed> Kamion, i checked Guadalinex source before then ubiquity ..
<nomed> not now :)
<Kamion> note that its themeability was based around the distro name according to lsb-release output
<Kamion> and lsb-release says the same thing for Ubuntu and Xubuntu
<nomed> yep
<Kamion> (intentionally)
<ogra> imho it would be nice to have a "derivative" field in there
<Kamion> ogra: it's not possible with distros that share an archive
<ogra> Kamion, hmm, right :/
<ogra> but some things would be a lot easier if you have a central place of distinction
<Kamion> fork the archive, you can do what you like (and cope with behaviour changes in applications that suddenly think you're Slackware, etc.)
<Kamion> for anything else, I think BrandingForDerivatives is really the best way to go
<Kamion> (i.e. neutralisation)
<sivang> has anyone seen jbailey ?
<\sh> last time at the ubuntu booth at linuxtag, why? ;)
<sivang> \sh: hehe, I meant, on IRC :-)
<hunger> How can I restore the behavior of / CLOSE_LESSIONS in /etc/login.defs?
<hunger> and why was it removed?
<Tonio_> hi
<sivang> can anybody think what Mario Meyer could have wanted from me?
<sivang> He looked for me during the weekend and I was away..
<mdke> sivang: you'll have to mail him and see
<sivang> mdke: I guess, so, youy have any idea what his time zone?
<mdke> brazil
<mdke> although hopefully his email gets delivered 24 hours
<sivang> mdke: you happeb to have his email address handy?
<mdke> sivang: launchpad does
<sivang> mdke: sure, /me searches
<sivang> mdke: are you going to paris?
<mdke> sivang: no, i don't think so
<phanatic> Kamion: ping
<bddebian> Howdy folks
<pygi> hey bddebian 
<bddebian> Hello pygi
<sivang> glatzor: ping
<glatzor> pong sivang
<sivang> glatzor: I LOVE your new design
<sivang> glatzor: I want to move forward with it :)
<glatzor> sivang: I added some details yesterday. thanks.
<sivang> glatzor: it would make life easier for users, and eventually, if you check latest bug list for hubackup, you'd see it could cater for features required from smooth operations by some of the bug repots
<sivang> glatzor: ah! I didn't see them yet, I'll have top check this evening
<sivang> glatzor: btw, are you going to paris?
<glatzor> sivang: that is an open question :)
<glatzor> I want to apply fo ubuntu membership on tuesday
<sivang> glatzor: I see , I did not get any emails about sponserships, so I guess this is left for us to co-ordiante, a HUB GUI sprint :-)
<sivang> or we'd just resort to ekiga :p
<glatzor> you life next to or in paris?
<sivang> glatzor: not at all, I am in .IL 
<glatzor> right. :)
<glatzor> that is quite a distance :)
<sivang> indeed :)
<sivang> I'm out of the continent :p
<glatzor> sivang: I am on vacations in June for four weeks. And normally it rains in Germany at this time :/
<sivang> glatzor: still raining? I would hope it gets better and warmer 
<glatzor> so quite much time and space for open source stuff.
<sivang> Indeed.
<glatzor> we had two nice weeks but now it is raining for days
<sivang> I might pay a visit to .de during this time, I'll keep you posted if I can come and visit.
<sivang> (planning to be an EU during summer or so)
<glatzor> pay a visit to munich! it is worth a trip
<glatzor> israel takes part in the football wm?
<sivang> ofcourse!, but also I must visit ogra in the Eifels (or at least this is how I think this region is called)
<sivang> glatzor: I think so, yes :)
<sivang> this is the linke right? - https://wiki.ubuntu.com/HomeUserBackup/UI
<glatzor> right
<glatzor> i am unsure about the large file stuff. perhaps this requires a further option in the profile
<glatzor> and I don't have got any idea yet how to handle patterns
<glatzor> but I think that I have to get familiar with dao before
<sivang> dao ?
<glatzor> dar :)
<sivang> ah :)
<sivang> way way cool program, though there are some limitations through the cmd line basic program, that's why I will be exploring writing python bindings to make stuff like files exclusion and inclusion more roust that what is currently used
<sivang> if you check it, you'll see that every file excluded is passed like this to the dar progam:
<glatzor> I asked mvo and it is possible to add hal hooks for backup cdroms/dvds. so that the restore tool would be started automatically.
<sivang> -X "*.mp3"
<sivang> which causes problems, when you have *.MP3 file on your hard drive
<sivang> (case sensitivity results in it being backed up)
<glatzor> but he wasn't very pleased with this approach. I have to get into details with mvo.
<sivang> glatzor: you think we should provide hal hooks for that? I would be happy if we could  just detect hardware devices and medium plug ins/outs as a start.
<sivang> glatzor: currently I only know what was availabel at program startup
<sivang> which is bad
<glatzor> michael did this for the dapper update cdroms
<sivang> glatzor: anyways, your new design would allow stuff like https://launchpad.net/distros/ubuntu/+source/hubackup/+bug/43926
<Ubugtu> Malone bug 43926 in hubackup "Allow Backup To Custom Path" [Wishlist,Unconfirmed]  
<sivang> glatzor: to be easily integrated inside
<sivang> glatzor: which I did not know how to allow in the old GUI :-)
<sivang> glatzor: this also https://launchpad.net/distros/ubuntu/+source/hubackup/+bug/43927 , could be addressed using the modifiable exclusion / inclusion templates.
<Ubugtu> Malone bug 43927 in hubackup "Backing up other folders besides home" [Wishlist,Unconfirmed]  
<sivang> and this , just as well
<sivang> https://launchpad.net/distros/ubuntu/+source/hubackup/+bug/43928
<Ubugtu> Malone bug 43928 in hubackup "To Improve Include/exclude media" [Wishlist,Unconfirmed]  
<glatzor> sivang: I subscribed myself to the hubackup bugs to get a better picture of the users' needs
<sivang> glatzor: cool, so you already got all those old a dn new reports? seen malone #44341 ?
<Ubugtu> Malone bug 44341 in hubackup "User interface doesn't follow the GNOME HIG" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/44341
<sivang> fd
<sivang> problem is, people file bugs both on the product and the source pkg, I need to track them both :)
<sivang> https://launchpad.net/products/hubackup/+bugs
<hunger> How can I restore the behavior of / CLOSE_LESSIONS in /etc/login.defs? Why was that removed anyway?
<glatzor> i cannot subcripe to the prduct bugs
<sivang> glatzor: hmm, I wonder if I can
<dsas> glatzor: That's the same for any product I think. Not sure whether or not it's a LP bug.
<glatzor> sivang: perhaps you as owner can add further bug contacts
<sivang> glatzor: let me try
<sivang> glatzor: what you're launchpad name so I can add you?
<glatzor> glatzor :)
<sivang> ah, cool :)
<sivang> what does it mean in germen btw?
<dsas> is the hubackup in the repos supposed to be in a working order?
<dsas> oh sorry, seems it's not a hubackup specific problem I'm having :)
<glatzor> "glatze" is a head without any hair like mine one :) and the ending -or has no meaning.
<glatzor> -or makes it sound more dangerous :)
<glatzor> sivang: so pumped up my karma :)
<sivang> dsas: what's the issue?
<sivang> glatzor: hehe
<sivang> glatzor: cannot add someone else as a bug contact as it seems in the product
<sivang> argh
<zyga> hey guys
<bddebian> Hello zyga
<kgoetz> hi
<glatzor> hi zyga
<glatzor> sivang: :/
<zyga> hey
<zyga> why the sad face?
<glatzor> zyga: i would like to subscripe myself to the bugs of sivang's product :/
<glatzor> but we cannot find such an option in launchpad
<kgoetz> glatzor: all of them?
<glatzor> zyga: and i had a bycile accident last night
* glatzor now features a contusion of the iliac crest and the lumbar portion of the spine
<glatzor> kgoetz: I want to get notified of all bug changes of hubackup 
* zyga doesn't know medical english well enough but it sounds serious
<kgoetz> glatzor your bug contact, sint that all you need?
<glatzor> yes, it hurts :/
<kgoetz> glatzor: i don't know much medicalish, but what i do know is that's not pretty :(
<glatzor> kgoetz: but we are actually two bug contacts :)
<glatzor> sivang: we could create a team
<glatzor> backupers
<kgoetz> glatzor: i was looking for that option as well (contact)
<sivang> glatzor: oh my god ! is anybody taking care of you injuierd like this?
<sivang> yes, I could crate a team like hub-devels or something
<sivang> glatzor: I'm also interested to see how we can make this a complete backup solution for ubuntu, so when you'll have a set of HUB's cds togther with an Ubuiguity CD, you could restore your system no fuss.
<kgoetz> sivang: cool idea
<glatzor> sivang: you are already part of the new team :)
<glatzor> kgoetz: zyga: want to join, too?
<zyga> glatzor: yes
<kgoetz> yes please glatzor
<sivang> glatzor: kgoetz alrady heped me alot with bug reporting and testing :)
* sivang goes to see how to create a team.
<sivang> kgoetz: re the team or complete backup solution ? :)
<glatzor> sivang: you are too late: https://launchpad.net/people/backupers
<kgoetz> sivang: both :)
<sivang> glatzor: hehe, you're quicker then I am with LP , but I am at work, so it doesn't count :p
<kgoetz> hehe
<sivang> glatzor: okay, now set up the team as the bug contact for both the product and the source pkg
<sivang> ?
<glatzor> sivang: that is still your job. 
<glatzor> sivang: you are the owner of hubackup
<glatzor> hi kgoetz, you live on the other side of the planet, right?
<sivang> glatzor, kgoetz : we'd need to make sure there is no effort duplication, or OTOH to see if there are better solution then dar to create thecomplete disaster recovery tool - if we have to record partitioninformation, might as well uise a tool that dumps , compresses and slices partitions images rather then file system level backup. but then we might loose the excludion funciontality
<sivang> so many things to check..:)
<kgoetz> glatzor: from the sound of it yes
<glatzor> whoa, the new team spans the whole world :)
<sivang> glatzor: can you please also empower me a bit on the backupers team? :)
<sivang> glatzor: hehe
<kgoetz> glatzor: that must be one of the fastest global spreads ever :)
<sivang> glatzor: done. team is not the bug contact for product
<glatzor> sivang: i think that we should concentrate on the user data. setting up a system backup is a complete differnet task
<glatzor> sivang: you are already admin
<sivang> glatzor: I was thinking along the lines of current scheme, as extending to backing up other stuff then /hjome is trivial in the file system level
<glatzor> we just need an icon from lapo
<sivang> indeed :)
<sivang> glatzor: and we would only require something to record partitions so we would be able to recreate them in case of complete wipe out of HD
<glatzor> sivang: someone suggested a complete system backup tool on the wiki page. one moment
<kgoetz> sivang: fdisk -l > file ? :)
<glatzor> https://wiki.ubuntu.com/MondoMindi
* sivang fails to find how to set up a team as a bug contact for hubackup's package
<sivang> glatzor: I once exp[eriment with MondoMindi, it has TONS of dependencies
<sivang> glatzor: but it seems nice nonetheless
<glatzor> https://launchpad.net/products/hubackup/+bugcontact
<sivang> glatzor: this if for the product, I alredy set it up. But what about the source pkg?
<sivang> https://launchpad.net/distros/ubuntu/dapper/+source/hubackup/+bugs
<glatzor> already done
<glatzor> https://launchpad.net/distros/ubuntu/+source/hubackup/+subscribe
<sivang> ah, sub the team to the source pacakg bugs :)
<sivang> cool
<sivang> glatzor: thank you!
<glatzor> no problem
<sivang> now we can get rocking ;-)
* glatzor prefers to sit motionless in his chair at the moment
<sivang> hehe, I was just saying this. it's sunday after all in most modern countries :)
<kgoetz> you are so far behind :P
* sivang nods
<kgoetz> it's been monday for nearly an hour here!
<glatzor> sivang: do you have any contact to Aigars Mahinovs, the creator of sbackup?
<sivang> glatzor: We discussed a bit, but when me and Ian evaluate it, it looked more then uncomplete for general consumption and had many bugs, together with very un discoverable progress indication.
<glatzor> it seems to be stalled fro quite some monthes
<looksaus> I have a question about express shipments of Dapper
<sivang> glatzor: we also knew we don't want to have a re-implementation of an archive format, as this has been already implemented several times by different parties, and to a very good extent.
<looksaus> where should I ask that?
<glatzor> puh looksaus, no idea.
<mdke> looksaus: you should mail the information address on the shipit page
<looksaus> mdke, no more direct source?
<mdke> looksaus: email is pretty direct
<looksaus> mdke, thx
<mdke> np
<glatzor> sivang: I have to leave. so bye
<sivang> glatzor: laters, see you
<Riddell> manfred: hi
<manfred> hi folks, I'd like to know why my smb shares don't get mounted after my latest dapper upgrades and why hald hangs on bootup as long as there are smbmounts in fstab
<manfred> I put the mount command now in rc.local but I'm still curious
<bddebian> manfred: Anything in the logs?
<manfred> bddebian: hang on
<mdke> manfred: sounds like a bug. It's quite common, have a look in the bug tracker
<manfred> well in syslog I can't find anything helpful
<manfred> I can only tell that on bootup when message for hald starting appears that it hangs for about a minute or so
<manfred> then it carries on and when started the smb shares are not mounted
<manfred> that used to work fine  before
<mdke> manfred: please continue in the bug tracker. I'm sure you'll find a bug open on it already
<manfred> mdke: ok
<manfred> If you look on launchpad it rather looks like samba was still in an alpha developement state :-)
<manfred> So no wonder I got problems
<looksaus> manfred, smb printing is broken for the moment, but the rest should be more or less ok
<manfred> But my problem is not described there. Anyway I was actually trying to find out whether this should be considered a bug or a new security feature of some sort
<manfred> But your reactions let me think about filing a bug report
<manfred> looksaus: btw, I havent got my kubuntu installation to print on any network printer at all for ages.
<manfred> no matter what I did
<manfred> That means I have to boot win xp to print my mails at work
<manfred> they are sneering at me :-(
<manfred> The laugh is always on the loser, so to say :-)
<mdke> manfred: convert the print server to cups
<lamont> lifeless: I only see 20 of them right now...
<sladen> manfred: if it doens't work, please file a bug.  much more productive way to get it solved
<Harti> #37774
<Harti> https://launchpad.net/distros/ubuntu/+source/libsdl1.2/+bug/37774
<Ubugtu> Malone bug 37774 in libsdl1.2 "sound delay 0,5-1s" [Normal,Confirmed]  
<sivang> night all
<pygi> night sivang 
<ProN00b> why is evolution the default email client on ubuntu, and not tunderbird, i mean the default browser is firefox and not epiphany too
<azeem> ProN00b: your reasoning is strange, surely this decision should be done on  a case-by-case basis (and you could argue the other way round just as well)
<ProN00b> well, i see it like this
<ProN00b> the reason for firefox is that it is more popular and alot of windows users use it now too
<ProN00b> then theres epiphany which is surely built on top of gnome and everyhthing so it should be perfect for a gnome desktop
<ProN00b> now there is thunderbird which is avaiable for windows too, and alot of windows users use it
<ProN00b> then there is that strange evolution thing which is coded on top of gnome
<azeem> evolution is available for windows, too, AFAIK
<ProN00b> now, why evolution and not epiphany
<azeem> though not as readily available as thunderbird
<mdke> azeem: this guy has flamed in here many times, don't get drawn in
<ProN00b> yeah, you can compile most linux apps on windows
<ProN00b> just that i haven't ever heard of evolution
<mjg59> ProN00b: This discussion is off-topic here.
<mdke> ProN00b: you can go to #ubuntu-offtopic to continue, if you wish
<seb128> ProN00b: epiphany requires firefox to work, there is no point to install an extra browser
<seb128> ProN00b: that's not true with evolution, we are not forced to install thunderbird anyway
<seb128> ProN00b: and there is a spec for next cycle to use epiphany as default browser (it'll use xulrunner instead of firefox) but it might not be accepted ...
<ProN00b> seb128, epiphany should depend on the mozilla libs not on firefox itself, does it ?
<Keybuk> didn't we decide that we wanted Epiphany, and that it was _better_
<Keybuk> but that we couldn't get away with not shipping Firefox as the default?
* Keybuk tries to recall through the distant fog
<seb128> Keybuk: I don't think epiphany was better, it was lacking some feature and had some issues, it's getting much better now
<ProN00b> and you SHOULDN'T get away with not shipping firefox as the default
<seb128> ProN00b: the lib are not splitted atm
<seb128> ProN00b: that's what xulrunner is, proper libs to use
<pygi> ProN00b, stop arguing
<seb128> ProN00b: anyway that's offtopic for that chan as said before
<seb128> ProN00b: you are free to install an another software if you don't like the default one
<pygi> you have no right to tell what will be shipped and what will not
<ProN00b> seb128, you mean mozilla has its own libs, firefox has and so on ?
<tritium> From the point of view of enterprise support, evolution works nicely with exchange servers, whereas thunderbird does not.
<ProN00b> pygi, but i can flame in my suggestions, i mean thats what the internet is for
<seb128> ProN00b: I don't understand your question, and no that chan is not a place to flame
<pygi> ProN00b, you can also get banned
<Keybuk> ProN00b: http://www.ubuntu.com/community/conduct
<mdke> seb128: hiya. Did you have a go at the epiphany homepage localisation at all?
<seb128> mdke: hey, no, too busy for that :/
<mdke> seb128: fair enough. maybe you can delegate it to someone :)
* pygi wonders what needs to be done
<seb128> there is no "lock" on the work
<seb128> patches are always welcome ;)
<seb128> if any contributor wants to step he can ...
<mdke> sure, maybe i'll file a bug and so someone tracking the bugs can see if they know how to do it
<seb128> better to update the Desktop/TODO wiki page
<mdke> ah, good idea
<seb128> I doubt anybody will go read the thousands of desktop bugs we have
<seb128> I'm asking on #ubuntu-desktop atm
<pygi> seb128, what needs fixing if I may ask?
<seb128> <seb128> ploum: made the startup page being locale Dependant
<seb128> <seb128> dependant
<seb128> <seb128> like file:///some/path/page-%l.html
<seb128> <seb128> where %l is the locale
<seb128> <seb128> and fallback to C if the page doesn't exist
<pygi> ah
<seb128> pygi: interest to hack on that?
<pygi> ugh, not at this moment :-/
<pygi> sorry
<seb128> k
<seb128> np
<seb128> it was in case :)
<pygi> :)
<Keybuk> hmm
<Keybuk> did anyone think to remove /var/log/* from the LiveCD image?
<sladen> mjg59: okay, does hal need teaching about SBTN , or is that a "standard" key?
<sladen> Keybuk: what does it contain, the lots from building the CD?
<mjg59> sladen: That's standard
<Keybuk> yeah, just noticed it had a complete /var/log/dpkg.log :)
<Keybuk> which, of course, ends up on the Ubiquity installed image
<sladen> mjg59: oooh, goodie
<sladen> Keybuk: yer might want to file a bug report :)
<Keybuk> *shrug* it was quite handy actually
<_ion> keybuk: Btw, what does your quit message mean? :-)
<Keybuk> _ion: "Enough of this crap"
<_ion> Hehe.
<Keybuk> ya know what I *really* want for my birthday?
<Keybuk> An option to man(1) that says "look in either section 2 or 3, because I don't know which one it's in and I just don't want you to show me the damned unix command version"
<_ion> Hehe, true that. :-)
<_ion> In that situation, i usually run man -a foo and then press q when the section 1 page is shown. :-)
<Keybuk> mdz: greetings
<Keybuk> how's the Tequila?
<mdz> tequilicious
<Keybuk> you don't get jet lag to mx, do you?
<sabdfl> you get tequila lag, though
<tritium> mdz: you're in Mexico?  /me faces South and waves...
<LaserJock> tritium: lol, /me faces South and waves to tritium and mdz ;-)
* _ion faces to the third planet from Sol and waves.
<mdz> Keybuk: it's only 2 hours time difference to here
<mdz> tritium: indeed, for DebConf
<Keybuk> mdz: yeah, figured it was something like that
<mdz> 3.5 hour flight, easy as pie
<mdz> very comfortable shrubbery in this country
<coz_> sorry to bother you guys
<coz_> th current daper udates removed the keyboard shortcut option for logout
<coz_> what is the terminal command to bring up logout dialog UI
<Keybuk> coz_: sadly there isn't one
<coz_> Keybuk, none? they removed theoptio in the keyboard shortcuts so wouln'tthere also be a command for it? out of curiosity?
<Keybuk> there's a keyboard short cut
<Keybuk> it's the logout button on your keyboard if you have one
<Keybuk> if not, go System -> Prefs -> Keybd Shorts and set one
<Keybuk> it's the second one down in the list
<coz_> Keybuk, the keyboard shortcut was rmved in he upates
<mdz> coz_: pressing the power button should bring up that dialog
<Keybuk> mdz: neat!
<coz_> OK guys let me rpeat this, the current dapper updates have removed logout options in keyboards shortcuts
<mdz> coz_: everything will be OK
<coz_> there has to be a command becasue a panel applet button for logout existys ans rings up the UI
<coz_> I understand I was jst curious what the terminal cammand wold be
<coz_> mdz, not worried just curious
<coz_>  thannks gys
<mdz> gnome-control-center hasn't been changed since the last time I upgraded, and I can still set a shortcut
<coz_> mdz I just did current dapper updates the keyboards shorcut menu has most definately been changed
<coz_> mdz and the logout option has been removed
<coz_> just t let you guys know I am not being grumpy here
<Keybuk> no
<Keybuk> coz_: is right
<Keybuk> that option is actually missing from the latest update
<coz_> I was just curious about the terminal command to bring up the UI
<Keybuk> it's there on my laptop, but not on my desktop (which has been upgraded and restarted about an hour ago)
<coz_> there is a logout button applet for the panel so threfore  command also
<coz_> Since there is a panel button for it that works there must also be a terminal command for it as well
<coz_> a short cut HAS to call on something, 
<coz_> Keybuk, thanks for seeing the problem
<coz_> well I will keep asking ans searching for the terminal command to call the logout dialog UI thanks for your time hope they put the keyboard shorcut back in but if not I will find the commnd thanks again guys
<mdz> hate to disappoint, but it looks intentional
<_ion> Wow, this _is_ cool. I didn't know the power button brings up the logout dialog.
<mdz> Keybuk: are you reporting the bug?  I could be wrong
<Keybuk> mdz: I'm not convinced it's a bug, given the power button displays the dialog :)
<Keybuk> I suspect it's removed, because you can't push the power button when prompted for a keyboard accelerator :p
<LaserJock> Keybuk: what if somebody doesn't have a power button? ;-)
<_ion> Or ACPI support :-)
<mdz> Keybuk: the power buttons on our laptops don't seem to trigger the dialog though
#ubuntu-devel 2006-05-20
<seb128> bug #32126
<Ubugtu> Malone bug 32126 in control-center "sleep shortcut belongs to gnome-power-manager" [Normal,Fix released]  http://launchpad.net/bugs/32126
<seb128> that has been changed with that upload
<seb128> control-center (1:2.14.1-0ubuntu8)
<mjg59> mdz: Ah, the preference appears to have vanished from g-p-m
<mdz> seb128: right, log out seems different from sleep and hibernate though
<mjg59> mdz: The power button gets passed through on wakeup
<mjg59> So if it's bound, you get the logout dialog on resume occasionally
<mdz> the shortcut can be disabled by default, then, but I see no reason not to allow a binding to be set if the user wants one
<mjg59> Seems reasonable
<seb128> mdz: right, I don't know why dholbach changed that one
<seb128> I'll fix it
<mdz> seb128: thank you
<seb128> np
<jdub> mdz: have fun in mexico :-)
* jdub disappears to jo'burg
<mdke> jdub: nooooo
<mdke> jdub: tell me you have 30 seconds to update planet for me before going jet-setting
<mdke> rats
<mdke> jdub is the hardest man to get hold of in the entire world
<jcole> why are the backgrounds in dapper labeled as "warty" backgrounds?
<jcole>  /usr/share/backgrounds/warty-final-ubuntu.png
<mdke> jcole: mine says Ubuntu Dapper Beta on it
<jcole> sorry, s/labeled/named
<mdke> probably because if you keep the same filename you don't have to change anything
<jcole> mdke: lol, right
<mdke> best file a bug if you don't like it
<robertj> is there an easy way to dpkg-buildpackage debug?
<robertj> I see --debug was lamented as missing in 2001 but never found it's way in apparently
<crimsun> mdz_: ping
<mdz_> crimsun: pong
<crimsun> mdz_: RE: ALC861 recording: Is it currently broken in 2.6.15-22.34? There's a one-line diff between our patch_realtek.c and upstream alsa-driver 1.0.11
<crimsun> (I'll go ahead and submit that one, but I want to check the status)
<mdz> crimsun: I think the test was done with beta 2; has it been updated since then?
<crimsun> hmm, beta 2? No, no updates to it since beta 2.
<crimsun> although the missing line is pretty substantial
<mdz> I don't have more information but could get you in touch with the person who ran the test
<mdz> he said it was known fixed in 1.0.11
<crimsun> sure, is there a bug report or forum post?
<mdz> crimsun: just an email
<crimsun> mdz: please forward it to me
<Keybuk> madduck: the sex change didn't go so well?
<_ion> In case anyone's interested, i packaged the cpp-omnicomplete script from vim.org: http://hassers.fi/ubuntu/dists/dapper/vim/
<robertj> krb5-admin-server seems like it will always fail on first install because you need to run a script in one of it's deps by hand...am I missing something?
<Keybuk> I read that as cpp-omlette
<robertj> actually nevermind, that package actually contains krb5_newrealm...
<robertj> so you need to install the package & run that script before the package will properly install
<madduck> Keybuk: it's not so much the sex change, but being biella for a while was awesome!
<Keybuk> I can imagine
<ajmitch> morning all
<Keybuk> is the Fedora Project wiki down for anyone else?
<robertj> Keybuk: looks fine here
<Keybuk> hmm
<Keybuk> http://fedoraproject.org/wiki/FCNewInit
<Keybuk> is just timing out for me
<robertj> not for me
<Keybuk> weird
<HrdwrBoB> wfm
<HrdwrBoB> was a bit slow though
<Keybuk> hmm, google cache is doing the same
<Keybuk> might be an image/ad issue?
<robertj> don't see any images except for the fedora logo & a repeating background
<Keybuk> weird
<robertj> and the background might even be css if they are funky
<jcole> where is the usplash image?
<Keybuk> View Source works, just Firefox not displaying it
<Keybuk> jcole: /usr/lib/usplash/usplash-artwork.so
<jcole>  /usr/lib/usplash/usplash-default.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), stripped
<jcole> not opening that in gimp anytime soon, lol
<Keybuk> indeed
<mjg59> jcole: The modifiable image is in the source package
<mjg59> It's saved as raw code to make it easier to display it on boot
<Keybuk> mjg59: yeah, PNG decoders are so huge
<Keybuk> mjg59: I was feeling a little evil yesterday, and was experimenting how much smaller the binary got if it didn't even use dlopen/dlsym
<mjg59> Keybuk: Adding PNG decoding to usplash is effort :p
<crazy_penguin> bye. Good night
<mjg59> It didn't use dlopen originally - that was to make it easier for derivatives to change the artwork
<Keybuk> ahh
<Keybuk> I had a cunning plan :p
<Keybuk> replacing dlopen with a DT_NEEDED on the artwork .so <g>
<Keybuk> so the symbols are just there
<mjg59> Bad man
<Keybuk> your point? :p
<jcole> mjg59: rle?
<mjg59> jcole: Nope
<mjg59> It's just a raw dump of what ends up in the framebuffer
<Keybuk> which, of course, is the one true image format
<sladen> jcole: the initramfs is compressed
* robertj really likes the logo-only Apple splash
<Keybuk> robertj: EDGY!
* Keybuk gets the big hammer out
<robertj> Keybuk: hehe ;)
<sladen> robertj: you can have it in, so, like, 3 weeks
<Keybuk> I'm so changing the edgy artwork, on opening day, so something REALLY crap
<Keybuk> like "edgy eft" written in MS Paint
<Keybuk> just to "encourage" the artwork guys from day #1
<sladen> Keybuk: and if you rewrite bogl not to use  PutPixel(x,y,c) for every operation, it'll be faster too
<_ion> :-)
<robertj> Keybuk: you should change it to "c:\" in terminal-green
* _ion is happy with the new old usplash artwork.
<mjg59> Keybuk: I put that in Dapper and someone reverted it :(((
<Keybuk> sladen: I had actually thought of using a blit paint of part of the image to do the progress bar
<Keybuk> mjg59: heh, I reckon it's the only way to encourage them
<jcole> i have to do this magic to remaster the boot image on the debian/ubuntu install cd:
<jcole> convert -resize 639x320 -colors 14 myorig.png mynew.png; pngtopnm mynew.png > splash.pnm; ppmtolss16 "#000000=0" "#ffffff=7" < splash.pnm > splash.rle
<Keybuk> otherwise we'll just have the same story over again
<sladen> Keybuk: I think it still uses PutPixel()...
<Keybuk> just about releasing, and "oh, can you fundamentally change the artwork"
<sladen> Keybuk: because it "has" to check the plane for each pixel
<jcole> you guys should have done a contest thing with the artwork
<mjg59> It might always be easier to do the progress bar the other way
<mjg59> Draw a nice picture in the pixmap, and draw a black bar on top of it
<sladen> jcole: yes, yes, encourge them, yes, but, yes, *for edgy*
<Keybuk> mjg59: that's basically what I was thinking
<Keybuk> or, if possible, just have to pixmaps
<mjg59> Oh, except that would lead to tearing
<Keybuk> one for the light progress bar, one for the dark
<Keybuk> and gradually replace one with the other
<mjg59> vga16 is hard, let's go shopping
<Keybuk> heh
<Keybuk> or just replace the whole thing with something that uses just two colours and looks damned sexy
<robertj> splash with symbol only could be very striking... -> http://www.atwmusic.com/22475.gif
<Keybuk> a single white pixel black and white outline of the ubuntu logo, and a white progress bar in a single white pixel box
<mjg59> I remember getting the boot text stuff working in Helsinki airport
<_ion> robertj: :-D
<mjg59> Keybuk: The Vista releases so far have been b&w art
<mjg59> It'll shift to colour for the final release, but it looks pretty sharp now
<robertj> mjg: is that anywhere on the net? apples is http://www.magiclinux.org/people/lovewilliam/Bootsplash/Apple.jpg
<Keybuk> mjg59: I know, I've been playing
<mjg59> robertj: Somewhere, yeah. Not sure where, though
<Keybuk> http://www.geekswithblogs.com/images/www_geekswithblogs_com/storageman/2287/o_booting.JPG
<robertj> looks like XP to me
<mjg59> Sleep is irritatingly fast on Macs
<tritium> doesn't the windows bootsplash fade in from black?
<Keybuk> mjg59: we should make our own hardware
* sladen made a brand new one I was going to set as default which was basically a set of palette squares and then grid rules along the top and sides with pixel counts to *ensure* that it was overidden
<Keybuk> tritium: not that I'm aware, no
<lifeless> Keybuk: gmorning
<Keybuk> sladen: heh, where? :p
<Keybuk> lifeless: morning
<sladen> tritium: yes, it does.  Even my original usplash code did that :)
<tritium> Keybuk: no?  I'll double check...
<Keybuk> sladen: "edgy test card", would look great
<tritium> sladen: cool :)
<robertj> mjg59: how much of that is trickery with bringing up the old framebuffer while no one is at home behind the scenes?
<Keybuk> if only we could make it play the BBC Schools theme while it started
<sladen> tritium: a 1 second fade makes it look so sexy
<lifeless> Keybuk: question for you, is there a python interpreter for the conflicts/replaces language ?
<tritium> I agree, sladen 
<sladen> Keybuk: yup, looked like a testcard!
<mjg59> robertj: Mm?
<Keybuk> lifeless: there is not
<lifeless> Keybuk: thanks
* lifeless makes a note to write one
<Keybuk> well
<mjg59> robertj: Oh, right. No, the fact that they have limited hardware means they don't have to bother
<Keybuk> there may be one in SMART :p
<sladen> Keybuk: channel 4 schools theme was better!
<lifeless> perhaps, but it didn't seem accessible
<Keybuk> if we had just one kind of hardware, and access to the guys who wrote it, we could have fantastic hardware support
<robertj> mjg59: when I wake up my ibook in OS X the image from lid close is still there and there is hardware cursor but it's still in lala land
<lifeless> the logic was too twined in with the globale cache
<Keybuk> sladen: I have an RM of that
<mjg59> robertj: Oh, right. This is an Intel one
<lifeless> though I will check again ;)
<robertj> is that gone on the pros?
<mjg59> Well, it doesn't happen on the imacs
<mjg59> I haven't played with an mbp
<mjg59> I really need to test how well it supports power management on random Intel machines
<_ion> The Ubuntu splash would look more professional if every word had a trademark symbol after it.
<Keybuk> http://www.netsplit.com/tmp/ITVon4_Clock.rm
<Keybuk> sladen: ^
<Keybuk> _ion: I'm often surprised the Janes haven't required us to start doing that yet
<jcole> http://www.glatozen.org/wallpaper/wallpaper.php?variable=ubuntu
<tritium> mjg59: please don't tell me intel iMacs will be supported before G5 iMacs :(
<mjg59> tritium: What's up with G5 imacs?
<mjg59> I don't have any, so it's hard for me to do anything
<Keybuk> one of my original ideas for the boot splash was that the Ubuntu logo should spin
<tritium> mjg59: fan control problems, apparently patched in 2.6.16
<Keybuk> then we realised just how bad the Ubuntu logo looks in just about any other position
<mjg59> tritium: Can you find the patch?
<tritium> mjg59: I'll look, yes
<mjg59> Keybuk: I'm really not big on animated boot screens
<Keybuk> mjg59: aye, they tend to defeat the object
<sladen> Keybuk: I'm so going to patch usplash to poll for /dev/dsp being created and then cat that theme into it
<Keybuk> the screen is there because it takes a long time to boot
<robertj> btw, has anyone else pitched a fit about wrong password handling in gksu?
<Keybuk> sladen: heh, I had evil plans to use upstart to bring alsa up really early and do it
<mjg59> Gnome starts *astonishingly* fast from a warm cache now
<robertj> it's a rather scary error for some poor user trying to do security updates
<mjg59> The splash vanishes at about the same time as the theme starts
<sladen> robertj: gksu message?
<Keybuk> mjg59: can we warm the cache easily?
<mjg59> The seeking really kills us right now
<robertj> sladen: Failed to run /usr/sbin/synaptic --upgrade-mode --non-interactive --hide-main-window
<robertj> Wrong password.
<sladen> maybe the splash should stay around until the menubar has actually loaded
<mjg59> Keybuk: We could find out what files it's reading and do magic to ensure that they're in a linear block of the disk...
<mjg59> Other than that, nothing springs to mind
<mjg59> But just log out and then try logging in again
<sladen> robertj: what is causing this and is there a bug #
<mjg59> Most effective if you log in, log out and then log in
<Keybuk> would doing readahead on the files help?
<robertj> sladen: give a wrong password to the upgrade notifier
<robertj> or just about anything
<mjg59> Keybuk: Not sure. We'd need to check the file access patterns.
<_ion> Would readahead help? IIRC the package contains a program that sorts /etc/readahead/given_list in the order files are physically in.
<robertj> sladen: I've filed it upstream some time ago with no response
<Keybuk> just run readahead-watch, then log in
<_ion> Whoops, i didn't notice keybuk mentioning that already. :-)
<sladen> _ion: the key is avoiding seeks, not just avoiding the order.  It's better read 100MB in a single pull than read 20MB in 5 seeks
<Keybuk> and damn, I was having a bad day when I wrote that manpage :p
<mjg59> Keybuk: Excellent. Thanks for volunteering!
<mjg59> I'm going to spend the week playing with bacteria instead...
<sladen> this C4 schools theme is catchy
<sladen> I'm going to have it on repeat for the next week
<Keybuk> it brings back memories, doesn't it
<sladen> sitting cross legged on a hard carpet and watching sex-education films on a TV that was about 8 foot off the ground while the girls were all plaiting the hair of one in front and boys were all sniggering
<sladen> Breeding: for fun and profit
* robertj should get the Human Animal on DVD
<_ion> For anyone puzzled about the strange unit: 8 feet = 2.4384 m according to units(1)
<_ion> :-)
<Keybuk> what's the opposite of "instant", in the length-of-time sense?
<mjr> eternity?
<HrdwrBoB> never
<Keybuk> no, I mean if an event happens in less than the smallest measure of time, it's "instant"
<Keybuk> what if an event takes a period of time?
<lifeless> duration
<lifeless> period
<lifeless> range
<lifeless> molecule ('its not atomic')
<robertj> Keybuk: temporal?
<_ion> t>t_{instant}
<robertj> Keybuk: why do you ask?
<Keybuk> robertj: trying to describe something in a document, and can't quite get the right word
<robertj> pastebin for context?
<Keybuk> trying to work out whether I can rewrite this bit
<Keybuk> usually I figure if it's hard to describe, it's hard to implement
<lifeless> eggauah: delta
<lifeless> meh
<lifeless> Keybuk: delta
<_ion> Describe it in pseudo code instead of plain English. :-)
<sladen> you're right.  that wrong-password thing is a bit scary
<Keybuk> the system being switched on is an instant event
<Keybuk> as is the lid button being pushed
<Keybuk> etc.
<Keybuk> a network card being present is a BLANK event
<Keybuk> (it has a particular length and life, and implies that the event stops)
<_ion> Are you sure you want to call it an event?
<Keybuk> I don't have to use the word event, no
<sladen> is that "a state"
<Keybuk> though I'd like to use the same word to describe both
<sladen> the state being that the NIC is present
<lifeless> Keybuk: PCI cards offer a term
<mjr> indeed
<lifeless> 'Edge' and 'Level'
<sladen> the event is that transition (which occurs at an instant) when the state changes
<mjr> "persistent" is a word you might be looking for
<mjr> but yes, rather a state than an event
<lifeless> Keybuk: lid button is an edge trigger, card being present is a level trigger
<Keybuk> and if you wanted a light on while the lid button was held down, that's a level trigger?
<sladen> isn't English a funky language
<_ion> Hey, if English was good enough for Jesus, it should be good enough for us.
<sladen> PraiseTheLord
<lifeless> Keybuk: yes
<robertj> Keybuk: I might ask if you could get away with BLANK == ""
<robertj> although then your a would have to be an an, so that won't work
<robertj> sladen: should I file a bug on gksu in launchpad?
<coz_> hello all i was here earlier about the logout dialog UI and the shortcut  glad it was fixed so soon also the command to invoke the dialog UI is "gnome-seesion-save --kill" for thoses that said there was no command
<coz_> thanks again whoever made the fix
<coz_> now the UI is off center of the screen is there a conf file that this can be adjusted with
<coz_> have to go
<jcole> are there plans for a grub splash?
<crimsun> jcole: do you mean /usr/share/pixmaps/grub/ubuntu-artwork.xpm.gz ? :)
<jcole> crimsun: ah, i must have to do an ln -s ...update-grub
<jcole> crimsun: why isn't it enable by default?
<Burgundavia> jcole, it breaks on some machines
<jcole> Burgundavia: ah, gotcha... how does sushi and redhat get way with it?
<crimsun> jcole: the rationale is explained in the changelog
<jcole> crimsun: ok
<crimsun> 0.2.28-{2,3}
<jcole> Burgundavia: the ubuntu install cd has a bootsplash
<jcole> splash.rle
<infinity> That's not grub.
<lifeless> auxesis: dude
<lifeless> infinity: what neon do you want baz updated to ?
<auxesis> hey lifeless :)
<infinity> lifeless: 25.
* lifeless cant face using baz for this, apt-gets instead
<lifeless> garh
<lifeless> infinity: ping
<lifeless> neon 25 is *more* broken, not less
<lifeless> infinity: its broken enough that fixing means 'write own uri escape routine'.
<lifeless> infinity: specifically:
<lifeless> Breakpoint 1, escape_location (location=0x808974d "cached:/foo") at /home/robertc/source/bazaar-1.4.2/src/baz/libarch/pfs.c:539
<lifeless> 539       if (ne_uri_parse (location, &parsed_uri) != 0)
<lifeless> (gdb) print parsed_uri
<lifeless> $1 = {scheme = 0x0, host = 0x809e008 "cached", port = 0, path = 0x809e018 "/foo", authinfo = 0x0}
<lifeless> scheme should be cached: here, and path /foo - because its an unknown scheme the opaque rules should kick in
<lifeless> sorry, neon24 needs to stay :(
<infinity> Hrm, that parse looks correct to me.
<lifeless> infinity: ?!
<infinity> "scp foo myhost:/bar" the scheme is unknown/NULL, the host is myhost, the path is /bar
<lifeless> scp does not use uris
<infinity> No, but that's an invalid URI, no matter how you slice it.
<lifeless> no its not
<infinity> As a URI, it would have to have more slashes.
<lifeless> no
<infinity> (Or fewer, a la mailto:)
<lifeless> right. if its not hierarchical, then its opaque 
<infinity> So, do bzr and svn work around this change in some way, or did they never use a foo:/bar scheme anywhere to start with (which seems broken to me anyway, but whatever)?
<lifeless> bzr does not use neon
<infinity> Oh, right.
<lifeless> dont know about svn. 
<infinity> I suspect SVN never had a need to use such schemes in the first place.
<lifeless> 1.2.3 in std66 is the relevant bit, FWIW
<lifeless> I suspect ne_uri_parse does what it does to let the caller apply heuristics
<lifeless> 'it looked like a host, so use whatever your UI considers the default scheme'
<infinity> Well, yes, like I said, it looked correct to me.
<infinity> I would have considered the other behaviour buggy.
<lifeless> you are clearly not a URI/HTTP Nazi
<lifeless> :)
<infinity> PHP agrees with you, which almost certainly makes you wrong. :)
<lifeless> argh!
<infinity> (base)adconrad@cthulhu:~$ php -r 'print_r(parse_url("cached:/foo"));'
<infinity> Array
<infinity> (
<infinity>     [scheme]  => cached
<infinity>     [path]  => /foo
<infinity> )
<lifeless> yup
<lifeless> that is correct.
<infinity> See, if you're on the same side as PHP, there's something wrong with you.
<lifeless> the caller then can go 'if scheme not in recognised_schemes maybe theres no host' etc
<lifeless> its definately the double // that triggers it in neon
<lifeless>  print parsed_uri
<lifeless> $1 = {scheme = 0x809e008 "cached", host = 0x809e028 "foo", port = 0, path = 0x809e018 "/", authinfo = 0x0}
<lifeless> cached://foo was the input
<infinity> Yes, well no arguing that that's clearly correct.
<lifeless> right
<lifeless> if they got that wrong, it would be 'bad'
<lifeless> heres an example from std66 though
<lifeless>          foo://example.com:8042/over/there?name=ferret#nose
<lifeless>          \_/   \______________/\_________/ \_________/ \__/
<lifeless>           |           |            |            |        |
<lifeless>        scheme     authority       path        query   fragment
<lifeless>           |   _____________________|__
<lifeless>          / \ /                        \
<lifeless>          urn:example:animal:ferret:nose
<lifeless> note that *everything* after the urn: is considered path
<lifeless> and WOW neon fucks that over
<lifeless> Breakpoint 1, escape_location (location=0x8089a41 "urn:foo:bar") at /home/robertc/source/bazaar-1.4.2/src/baz/libarch/pfs.c:539
<lifeless> 539       if (ne_uri_parse (location, &parsed_uri) != 0)
<lifeless> (gdb) print parsed_uri 
<lifeless> $1 = {scheme = 0x0, host = 0x809e018 "urn", port = 0, path = 0x809e008 "/", authinfo = 0x0}
<infinity> Neat. :)
<infinity> Alright, I can keep neon24 in.  I'd be pretty happy if you filed bugs (with wonderful explanations and charts) to neon upstream to get this sorted once and for all in neon26, though. :/
<lifeless> I'll see what I can do 
<lifeless> got to go do plane tickets now though
<lifeless> tchau
<lifeless> oh, and for the canonical word ...
<lifeless> If a URI does not contain an authority component, then the path cannot begin with two slash characters ("//")
<lifeless> quote, unquote
<lifeless> cached:/bar - no authority, and does not start with two slashes :)
* lifeless is gone
<infinity> But does it say anything about starting the path with one slash?
<infinity> (I'd expect a NULL authority to actually appear as such, like in the case of file:///foo)
<Chipzz> slomo__: can you close bug 42594 please?
<Ubugtu> Malone bug 42594 in dbus "/etc/X11/Xsession.d/75dbus-1-utils_dbus-launch is not needed" [Normal,Unconfirmed]  http://launchpad.net/bugs/42594
<pitti> Good morning
<desrt> good morning
<pitti> hi desrt 
<ajmitch> hi pitti, desrt 
<desrt> ajmitch; thanks again for the debianising help.  my changes got uploaded the next morning :)
<ajmitch> great :)
<hendry> anyone aware of this "invalid tar magic" debootstrap error message?
<lunitik> Hello... something care to clear something up... Ubuntu ships proprietary drivers via restricted package 'linux-restricted-modules' by default (active during install) correct?
<lunitik> s/something/someone/
<hendry> lunitik: yes. or they have unclear licenses
* pitti hugs ajmitch 
<Burgundavia> lunitik, yes, they do. In restricted modules is a bunch of non-free software stuff
<Burgundavia> lunitik, are you referring to the whole koroaa mess?
<lunitik> Burgundavia: nope... someone in #suse is trying to argue with me  :/
<dholbach> good morning
<pygi> mornin' dholbach 
<dholbach> hey pygi
<pygi> whats up dholbach ? :)
<janimo> dholbach: morning
<pitti> dholbach: I just asked myself which penguintv version won - your's or zul's (they are both accepted on d-changes)
<dholbach> hey janimo
<dholbach> pitti: zul's - then one that had an uninstallable depends :-p
<dholbach> I assigned the bug to him
<desrt> i love how sunday night is morning for y'all
<Kaloz> any idea why does mc trash bash_history this way http://pastebin.com/718295?
<Kaloz> okay, found it.. it's a clean install, and now .bashrc has ignoredups
<Kaloz> it should be ignoreboth :p
<sivang> morning all
<pygi> mornin' sivang 
<pygi> talk to you later :)
<pitti> Riddell: do you still get the 'request entity too large' bug with 1.2.0?
<ivoks> mvo: ping
<mdke> guys. what is this sun-java5 package that has appeared?
<ubijtsa2> jre 1.5 on a guess
<ivoks> mdke: changelog says it's upgrade of 1.4
<Burgundavia> ivoks, I think they mean the blackdown 1.4 packages and I think they are referring to the style of packaging
<ivoks> Burgundavia: i didn't read it to carefully :)
<Burgundavia> hmm, no hits for DJL, distributed java license, distribution java license or desktop java license
<mdke> what I really meant was, how can this appear 15 days before the release without any warning to the doc team?
<mvo> ivoks: hello
<ivoks> mvo: hi
<janimo> mdke, thanks for the xubuntu guide translation call
<ivoks> mvo: does the patch i sent you back looks ok?
<mdke> janimo: np.
<Burgundavia> mdke, "Java development is expected to get a boost on Linux at the JavaOne conference, with partnerships anticipated for including the Java Runtime Environment with Linux distributions, Sun officials said."
<ivoks> mvo: the one you sent me introduced lots of unwanted side effects :/
<Burgundavia> JavaOne starts today, so I suspect that is why
<mdke> Burgundavia: well Sun officials didn't notify the ubuntu docteam either
<mvo> ivoks: yes, I'm building test-debs right now
<Burgundavia> mdke, don't know that they have to :)
<ivoks> mvo: ok
<mvo> ivoks: glade messed it up apparently :/
<mdke> Burgundavia: they don't.
<ivoks> mvo: fwiw, i'm using that patch for couple of days and looks ok :)
<seb128> mdke: hi
<seb128> mdke: is the "disks-admin" feature described by the documentation?
<mvo> ivoks: cool :) 
<seb128> mdke: that stuff is really bugged and we are thinking to not build it for dapper ... would that be an issue for the documentation ?
<mdke> seb128: yes, it would :)
<seb128> graa
<ivoks> seb128: bad timing :)
<seb128> mdke: should I reassign to you all the bugs we get about it then ? :p
<mdke> seb128: see System/Help/System Documentation/Ubuntu Desktop Guide/Configuring the System/Partitions and Booting
<mdke> seb128: no thanks. But it is only described for quite basic tasks
<seb128> yeah, but the tool is really bugged
<seb128> it doesn't modify fstab
<mdke> yes, we haven't used it for where that is necessary
<seb128> widgets don't adapt themself with most of locales and buttons are displayed out of the window
<Burgundavia> seb128, minor english nitpick s/bugged/buggy
<mdke> see section 4.2.2, and compare with 4.2.3
<seb128> it doesn't list partitions correctly for many people
<ivoks> seb128: i noticed it has problems with lvm partitions
<seb128> Burgundavia: right, you already told me that, I'll get it right next time ;)
<mdke> seb128: well, modifying the documentation isn't really an option because our translators are unlikely to get it updated in the 16 or so hours that remain before translation freeze
<mdke> but if it's absolutely necessary, I suppose we can try it
<seb128> mdke: dropping parts should not impact on documentation, does it?
<mdke> seb128: parts?
<seb128> if we drop disks-admin that's not some addition
<seb128> ie: nothing new to translate
<ivoks> seb128: it changes line numbering, doesn't it?
<mdke> seb128: right, but we will need to use something else in the documentation for that particular task
<ivoks> if we drop it from documentation
<mdke> so whatever we add will need to be translated
<seb128> k, so we will let it
<seb128> suck
<seb128> there is no other tool to describe for the task anyway
<mdke> yeah, there is mount
<seb128> right
<seb128> anyway I though it would no break any freeze
<seb128> but it you want to document some other way in case we drop it, we will let it
<mdke> erm...
<mdke> we will change it IF you are going to drop it
<seb128> right
<mdke> so tell me
<seb128> but I don't want to force you to change so we will keep it
<seb128> mdke: BTW, "16 or so hours that remain before translation freeze"?
<seb128> mdke: I though the freeze was  for the 18th?
<mdke> oh yeah, my bad
<mdke> that might help
<desrt> seb128; get a chance to try reducing the number of rows of dots on the handles?
<seb128> desrt: got your mail but I didn't do that much work saturday,sunday, I'll try that
<desrt> cool
<seb128> desrt: nobody complained and I'm not sure it's worth break UI freeze and make enemies to the documentation team
<desrt> that counts as part of UI freeze?
<desrt> crikey
<seb128> I would think so
<seb128> that change the looks of the default panel
<seb128> if I got your description correctly
<desrt> true enough
<seb128> though it's really minor
<desrt> it still looks unprofessional, i guess
<seb128> I don't think anyway would really care of the screenshot difference
* desrt imagines someone blogging "50 things wrong with dapper"
<desrt> and #1: the screenshots have the wrong number of dots!!
<mdke> seb128: listen, you are the only person who has seen all the bugs of the app, and now you know the impact on documentation. You should make the decision based on those: I can change the document today and notify the translators, if you think it's worth it.
<seb128> mdke: k, will discuss it with other desktop team people and will let you know soon
<seb128> mdke: we got a list of duplicates of "doesn't list my partitions correctly" and I'm not comfortable with what could happen if you try doing changes on a disk not correctly detected like that
<janimo> seb128: does ubuntu/gnome install some custom or modified defaults.list files for mime-handler associations?
<seb128> mdke: not to mention the UI doesn't looking right with most of non-english locales and the tools not editing fstab
<seb128> janimo: /etc/gnome/default.list
<seb128> janimo: /etc/gnome/defaults.list
<janimo> I'd like to figure out how to make some xubuntu specific ones (i.e jpg open with gqview not gimp)
<seb128> janimo: no way
<janimo> seb128: do I need to do a similar one and add XDG_DATA_DIR in xfce xinitrc script?
<mdke> seb128: right. Can you send me the decision by email? That way I will definitely pick it up
<seb128> janimo: hum, I'm not sure that would work
<seb128> janimo: all the .desktop are installed to /usr/share/applications and you want to use it
<seb128> mdke: sure, thank you
<janimo> seb128: yes the desktops are there
<seb128> mdke: would you mind if we change the panel handles looking a bit for dapper?
<janimo> but the default associations are in 3 directories now
<seb128> janimo: so you can't use an another directory
<janimo> and they can be override in ~/.local 
<seb128> janimo: ah? we use "/usr/share/applications/defaults.list -> /etc/gnome/defaults.list"
<mdke> seb128: what do you mean by handles?
<janimo> ah it's  link? did not see that
<seb128> mdke: the grip of the windows' list and the notification area
<seb128> mdke: 
<seb128> "engine/src/ubuntulooks_draw.c:1652:   num_bars    = 8;
<seb128> This is how many rows of 'dots' get drawn for the handle of applets on
<seb128> the panel.  I think this looks much better as 5 or 6.  At 8 the dots
<seb128> take up the entire panel and look like they're too crowded.  5/6 centre
<seb128> in the panel and look nicer."
<janimo> seb128: but those are cascading I assume, so thunar (for instance) can be made to read another one which overrides /usr/share/app
<mdke> seb128: sure, we don't use screenshots much
<janimo> and falls back to it for not found associations
<janimo> the spec is not too clear on this from what UI read
<seb128> mdke: that would slightly modify the panel look but I'm not sure anybody cares really of a such detail
* mdke nods
<seb128> janimo: sure, I though you were using gnome-vfs for that
<janimo> seb128: no, does not affect gnome behaviour in any way
<seb128> I'm sure your changes will not affect GNOME, don't worry ;)
<seb128> I just though you were using gnome-vfs to get the mimemagic etc
<janimo> seb128: so you know some standard trick other than adding XDG_DATA dirs in some session init script
<janimo> seb128: heh ;) , no thinar has it's own mime library
<seb128> if you are your implementation feel free to use a siliar defaults.list for xfce and hack yours package to use that one
<janimo> since gtk/glib does not provide such a basic mime functionality
<seb128> janimo: XDG_DATA will not work, you will stop having the /usr/share/applications/*.desktop listed I think
* Mithrandir wonders why running openbox --replace from a terminal seems to give him working shortcuts, while running it from the deskbar applet doesn't.
<mdke> seb128: oh we'll need to change section 4.3.7.1 (under Hardware) for disks-admin too. FYI
<janimo> seb128: I'll see what I can do
<seb128> janimo: hack your code to look to an another location for defaults.list I would say
<seb128> janimo: that's what Debian did for GNOME
<seb128> so they don't conflict with KDE for that
<ogra> janimo, there are people having problems with xfce session on logout in ltsp, seems xfce doesnt detect that you are not physically at the console and offers shutdown and reboot to terminal users
<ogra> (gnome-session detects that and only offers logout/switch user/lock screen)
<desrt> ogra; a lot of the xscreensavers assume that they won't be drawn over top of
<desrt> ogra; and, therefore, don't handle expose events
<desrt> ogra; they just draw.....
<desrt> ogra; so if you gdk_window_show the X window that they're drawing onto the flicker that that causes really messes up the display
<ogra> desrt, dont worry, i'll add the patch 
<janimo> ogra, thanks I'll try to see what it is
<desrt> ogra; awesome.  thx :)
<janimo> ogra, although xfce4-session just uses HAL to shutdown/reboot so the dialog may be there but inactive?
<ogra> desrt, LP has a 5min delay in mail processing, i answered without seeing the next twop comments, it was only a first debugging hint to ask to run it without g-s-s
<ogra> sorry for the confusion
<janimo> ogra, do you have a link to the posts or doem more details?
<desrt> ogra; ahh.  ok.  sorry if my reply came across as a bit hostile, then :)
<janimo> unless they;re using breezy
<dholbach> janimo: you can seed tango-icon-theme-common now (and gnumeric-gtk too)
<janimo> dholbach: seeded a while ago, will need to recreate xubuntu dsktop though. Thanks :)
<ogra> janimo, not really, Petraris is a frequent guest in #edubuntu and trying a xfce setuo on ltsp currently, i think he already talked to you about other stuff
<dholbach> janimo: ok
<janimo> ogra: yes the nick sounds familiar
<ogra> janimo, i'll talk to him to contact you
<janimo> ogra: thanks. either me personally or a bug in LP against xfce4-session is ok
<ogra> yep
<ogra> janimo, there must be code in gnome-session to detect that, so you likely cna just copy it
<ogra> *can
<janimo> ok, I am not sure yet what the symptoms are but once that;s clear I'll see how to solve it
<freeflying> pitti: ping
<pitti> hi freeflying 
<freeflying> pitti: sorry for bother, would you mind join #ubuntu-tw
<freeflying> pitti: guys of ubuntu-tw have problems with i18n wanna comunicate with you 
<Kamion> janimo: xubuntu tasks in the archive exist now, so netboot installs should work
<pitti> freeflying: I'm in
<freeflying> pitti: thx
<caleb-> carlos: Is there some script to upload A LOT OF po-files?
<caleb-> caleb-: pitti saird that we may ask you...:P
<carlos> caleb-: what do you mean by 'A LOT OF po-files' ?
<caleb-> s/saird/said/
<carlos> for a single language?
<freeflying> pitti: seems you fogot add zh l-s in your daily repos :)
<caleb-> carlos: ubuntu-tw has 300 pos waited to be upload.
<caleb-> carlos: but we just know hot to upload one after one...
<carlos> caleb-: hmmm no, I don't think we have such script
<carlos> that's something doable
<pitti> freeflying: I changed the scripts to build all languages this morning; check after today's cron job (around 1600 UTC)
<caleb-> carlos: so...we still must upload one and one and one...?
<freeflying> pitti: great, thx
<carlos> caleb-: yes :-(
<carlos> caleb-: you should not wait so much time to upload them...
<caleb-> carlos: ok, we will find more people to upload...
<carlos> caleb-: what I did in the past
<carlos> is with curl simulate the submits
<caleb-> carlos: :P KDE users at Taiwan is not very active in translation...
<carlos> but the upload form has changed since the time I wrote that curl script and I don't have it around anymore
<carlos> caleb-: you could do something like that
<ajmitch> Kamion: could you look at python2.3-{xml,imaging} in NEW? I need them for zope2.8 & related packages
<carlos> caleb-: hmm if it's KDE... I think we could do something.....
<caleb-> carlos: if there has some new way to upload pos, you may tell freeflying instead. I have to leave in 10 minutes...
<caleb-> carlos: Thank you. :-)
<carlos> caleb-: hmm, no, sorry, we cannot do anything yet. The trick will not work with distributions, just with products, sorry...
<Kamion> ajmitch: I'm in the middle of something that requires my full concentration at the moment, but I'll do it when I'm finished
<ajmitch> alright, thanks
<carlos> Kamion: upps, sorry, I forgot your update request... I'm going to do it now
<dholbach> who is a bit familiar with gawk and could check some patches that iegary sent?
<Kamion> mdke: I'm planning to change the Ubiquity icon, per bug 41472; any objections?
<Ubugtu> Malone bug 41472 in ubiquity "icon not descriptive" [Normal,Needs info]  http://launchpad.net/bugs/41472
<Kamion> to http://www.tuxresources.org/antonio/Documentos/ubuntu-express-install/express-vetor.svg
<ogra> hmm, branded ? 
<Kamion> ogra: yes, but no more than the existing one
<ogra> i would imagine a CD instead of the logo might work better 
<Kamion> contributions welcome; I can't draw
<ogra> the logo isnt as prominent in the crurrent icon, its rather swallowed a bit by the background
<jsgotangco> it seems to work on my eyes though
<jsgotangco> "put ubuntu into this HD"
<mdke> Kamion: nope
<jsgotangco> or computer hrmmm
<ogra> jsgotangco, and what about edubuntu and xubuntu ? 
<Kamion> may be a matter of my eyes, looks pretty prominent in the existing icon to me
<ogra> a neutral icon needs no rebranding ;)
<Kamion> I'm not objecting, but *you* need to talk to the artwork guys about that
<ogra> yep understood
<Kamion> in the meantime I honestly don't think that this change makes anything worse
<ogra> nope, i didnt say it does :)
<ogra> but i never even noticed the logo in the current icon, while this one directly jumped in my face, i just noted the difference
<Kamion> what were you using to view the new icon?
<ogra> firefox
<Kamion> I think it might be different if you have it on the desktop, with transparency etc.
<ogra> hmm
<dholbach> elmo: it seems that you're quite familiar with gawk - would you mind, if I subscribe you to the bugs with patches to get your input?
<ogra> the arrow is half transparent, that looks very odd on the edubuntu default wallpaper
<slomo> ogra: any news with dia 0.95?
<dholbach> hey slomo!
<Kamion> carlos: thanks
<slomo> hi dholbach :)
<seb128> Kamion: I'm trying a daily CD, ubiquity default to "Brussels" if you pick french as language ... is a that a known issue? What sort of data do you need for that?
<Kamion> seb128: known and filed, I don't think I need any further information, thanks
<Kamion> seb128: bug 43914
<Ubugtu> Malone bug 43914 in ubiquity "city selection (step 3) fails in some languages" [Normal,Confirmed]  http://launchpad.net/bugs/43914
<seb128> Kamion: ok, thank you
<Toadstool> hi here! dholbach, as you're the one who took care of lintian 1.23.13, do you have time to review the latest debdiff attached to bug 36505?
<Ubugtu> Malone bug 36505 in lintian "Ubuntu Lintian shouldn't do the nmu checks" [Wishlist,In progress]  http://launchpad.net/bugs/36505
<dholbach> Toadstool: not at the moment - but somebody else should be up to the job too
<Toadstool> ok
<Toadstool> anybody else? :)
<Kamion> ajmitch: done, source uploads anyway
<ajmitch> thanks
* Mithrandir wonders why a install seems to probe the cd drive about once a second.
<ogra> Mithrandir, what happened about the announced flight8 prep on friday ? 
<pitti> Mithrandir: you mean during the install, or in the running system?
<pitti> Mithrandir: (in a running system, that's hal probing CD-ROMs for media changes)
<Mithrandir> pitti: in the running system.
<janimo> ogra: F8 is for this next Friday no?
<Mithrandir> pitti: why does it do it when there's a cd mounted already?
<ogra> janimo, as i understood it it was last fri ...
<pitti> Mithrandir: because it's too dumb to look at the mount status
<janimo> no, biweekly I think
<Mithrandir> ogra: it's going to be sent out tomorrow or wednesday, as I said in the meeting.
<ogra> Mithrandir, oh, then janimo is right and i mixed up the weeks ?
<Mithrandir> ogra: I have no idea what dates you were thinking of, but flight 8 is going to be released on friday, freeze begins thursday morning.
<ogra> Mithrandir, your weekly status said we'll prepare for flight8 on friday :)
* _ion hopes his xinerama patch in bug #31433 gets to the package in time.
<Ubugtu> Malone bug 31433 in notification-daemon "notify bubble has text across screens" [Normal,Confirmed]  http://launchpad.net/bugs/31433
<ogra> so i misunderstood that we'll start preparing for it on friday and not we'll have it on friday :)
<Mithrandir> nah, last Friday would have been too soon.
<_ion> mvo: Any news re: notification-daemon + xinerama? :-)
<ogra> yep, but at least i got edubuntu nearly in shape over the weekend through that :)
<_ion> mvo: Sorry for bugging you all the time, i'm sure you're very busy.
<zul> heylo
<_ion> highlow
<Riddell> pitti: are the language packs at http://people.ubuntu.com/~pitti/langpacks/daily/ actually updated?  the version number on them suggests they are still from last thursday
<pitti> Riddell: oh, hm, they are updated, but the version number is wrong
<pitti> Riddell: I'll fix that, thanks
<simira> seb128: remember the gnome panel crashing - bug?
<pitti> Riddell: did you see my printer question from this morning?
<_ion> I posted about notification-daemon+xinerama to the forums: http://ubuntuforums.org/showthread.php?t=176775
<pitti> carlos: may it be the case that the latest dapper tarball is from Thursday? the timestamp.txt still says May 11th
<pitti> Riddell: ^ that's the root cause for the wrong version number
<mvo> _ion: thanks, I have a look today, keep nagging me if not 
<carlos> pitti: could be
<carlos> pitti: we had some problems with the mirror db
<carlos> pitti: yes, latest one was done on Thursday...
<carlos> :-(
<Riddell> pitti: I did then I forgot about it, let me try new cupsys now
<pitti> Riddell: I tried the command mentioned in the bug report, and it works for me (but I don't have that printer)
<pitti> BenC: Hi! Do you think you can apply all the outstanding vulns in the dapper kernel by Thursday? (the freeze)
<BenC> pitti: I think I already have, but I'll check the list to make sure
<pitti> BenC: ah, great; can you please add the CVEs?
<tseng> morn pitti 
<pitti> BenC: there's also a bunch of new issues in SCTP, I'll mail you the stuff
<pitti> tseng: hey hey
<BenC> pitti: ok
<Mithrandir> hmm, is there a way to send ctrl-alt-f1 or similar to a guest in vmware?
<Riddell> pitti: yes, printing seems to work now without complaint
<pitti> Riddell: cool, thanks for confirming
<sladen> Mithrandir: change the vmware hotkey to something other than ctrl-alt
<sladen> Mithrandir: or do  chvt 1
<Mithrandir> sladen: I fixed it by using ctrl-alt-shift-f1 since the kernel reacts to that too.
<h3sp4wn> Is there anyway to see the code which generates the cdimages on the build servers - I have been messing about adding packages to the squashfs and rebuilding the live-cd they work but always seem to run slower than the actual live cd's - or any documentation about the squashfs (and the way its built)
<Mithrandir> h3sp4wn: the squashfs is just built with mksquashfs and no fancy parameters.
<h3sp4wn> Mithrandir: Thanks for the response - at least now I know that I am just messing something up along the way
<Mithrandir> h3sp4wn: but you should always measure speed, not count on "feels slower"
<h3sp4wn> Mithrandir: It boots alot slower (minutes as apposed to seconds) - I will investigate thanks again
<Kamion> h3sp4wn: our normal live CDs boot in minutes for me
<Mithrandir> Kamion: bug 40328, do you have any idea about that?  It seems to work correctly for me..
<Ubugtu> Malone bug 40328 in oem-config "OEM install created user has wrong $PATH" [Normal,Confirmed]  http://launchpad.net/bugs/40328
<h3sp4wn> Kamion: I am using xubuntu which boots pretty quick from the official one but alot slower from mine
<Kamion> h3sp4wn: ah
<Kamion> Mithrandir: no clue, unless it was some kind of transient problem in user-setup (I know that's a cop-out answer)
<Kamion> sounds like PATH in /etc/environment wasn't being picked up by pam actually
<Kamion> or indeed .bashrc or anywhere else ...
<Mithrandir> Kamion: well, according to pitti /etc/environment didn't include PATH
<Mithrandir> mgalvin: hi, do you think there's need for a flight 8 page?  I'm aiming at releasing it on Friday.
<jsgotangco> w00t
<Kamion> unless libpam-modules failed to configure properly, maybe
<mgalvin> Mithrandir: i think so... there has been a bunch of artwork improvements and such that can help fill a page... i will create the flight 8 page by then
<sivang> re people
<mgalvin> Mithrandir: thanks for the advance notice :)
<Mithrandir> mgalvin: thanks a lot!
<mgalvin> np
<Kamion> Mithrandir: hmm, your oem-config fixes look dubious
<Kamion> Mithrandir: you moved the child widgets around, but you moved the <property name="position"> elements
<Kamion> as well
<Kamion> which override order in the glade file
<Kamion> at least in user-setup
<Mithrandir> Kamion: they looked correct in glade here.
<Kamion> ok, maybe I'm confused
<Mithrandir> Kamion: I did the change using emacs and not glade, so I might have fucked it up, but I did look at it in glade.
<carlos> Riddell: hi, around?
<Riddell> carlos: yes
<carlos> Riddell: why do we have kde-i18n-de 3.5.1 instead of 3.5.2 like other language tarballs?
<Riddell> that's a very good question
<Riddell> it's not in dapper-changes, it must have slipped somewhere along my way to making the kde-i18n packages, I'll fix that today
<carlos> Riddell: do you have an easy way to check any other language pack that has that problem?
<Riddell> carlos: did kdelibs.pot get imported into rosetta?
<carlos> oh, I forgot to check it.., just a second...
* Riddell runs  apt-cache search kde-i18n | awk '{print $1}' | xargs apt-cache show  | grep Version
<carlos> Riddell: the one we have imported was generated on 12th May
<carlos> Riddell: you will need to print the package name ;-)
<Riddell> all fine apart from kde-i18n-hsb which isn't released with kde 3.5
<carlos> Riddell: seems like German and something else are outdated
<carlos> Version: 4:3.4.3-0ubuntu2
<carlos> oh
<carlos> ok
<Mithrandir> Kamion: hmm, have we removed the test phase from oem-config?
<iwj> seb128: mdke sent me a mail about epiphany and DapperFirefoxStartPageTranslation; he says you wanted a new symlink.  Can I have a quick word just to check I understand properly ?
<seb128> iwj: hi, ah right
<iwj> So I'm guessing that the reason you want this link is that you've got some thing where the homepage is ..../index-$LOCALE.html and it falls back to that with LOCALE=C ?
<seb128> iwj: we want to set the startup page to "/usr/share/ubuntu-artwork/home/locales/index-%l.html" where "%l" is the locale
<iwj> *snap* :-)
<seb128> iwj: correct
<seb128> is that fine to have an index-C.html then? :)
<iwj> Right.  So you just need that one extra link from the name that epiphany falls back to, to point to the alternatives-provided en_US page.
<Kamion> Mithrandir: yeah - since oem-config now brings you to a normal desktop until you run oem-config-prepare by hand, it's easy to pick hwdb-client from the menus
<iwj> Sorry to be double-checking like this but this link farm is rapidly growing confusing :-).
<robertj> Frank Schoep's minimal usplash is very nice looking, although I fear the text really can't go yet as he wishes :(
<seb128> iwj: no problem, we just need an index-C.html pointing to whatever is the standard default 
<janimo> is /usplash_fifo supposed to stick around even after boot? It interferes with tab-completion for /usr :)
<iwj> Right.
<iwj> I'm just trying to think which package this should be in.
<iwj> I think the answer is epiphany.
<iwj> ff is another possibility if you think others might need it too.
<iwj> Oh, no, hold on, I'm not thinking clearly.   .../home/locales  isn't actually a directory, it's an alternatives link.
<seb128> iwj: whatever ships the startup pages seems a good candidate no?
<iwj> So you need one in each provided alternative.
<Mithrandir> Kamion: ok, thanks.
<seb128> iwj: what startup page does firefox use?
<iwj> I _think_ I can do this by furtling the script in ubuntu-docs.
<iwj> seb128: /usr/share/ubuntu-artwork/home/index.html as the fallback; /usr/share/ubuntu-artwork/home/locales/index-$LOCALE.html for locale-specific pages.
<iwj> But LOCALE != C
<seb128> iwj: epiphany has no such feature yet, but the startup page is a gconf key so it's easy to have some code replacing %l by the locale and falling back to something
<iwj> Right.
<seb128> iwj: C as fallback looks sort of right to me
<seb128> (if we want the patch accepted upstream)
<seb128> but if that's easier for you we can fallback on -en_US.html
<iwj> There is no -en_US.html either.
<iwj> (Actually, en_US might be in the translateable list so it might be a symlink to the fallback page.)
<seb128> just "index.html"? that would make impossible to have a generic case
<seb128> I mean index-%l.html
<iwj> Have you read DapperFirefoxStartPageTranslation ?  It's all a bit mad.
<iwj> And epiphany definitely seems saner.  Anyway I think I understand your requirement now.
<iwj> I'll just wait for mdke to get back to me about his new locales.
<iwj> mdke: ping
<seb128> no I didn't read that page (yet)
<seb128> ok
<seb128> if you can give me any locale to fallback that will do it, I've a preference for "C" though which would allow to make a patch upstreameable
<iwj> Yes, C is fine.
<iwj> Err, so you'll have it look for index-%l.html and if that's ENOENT use index-C.html ?
<iwj> Or do you need to build in a list of which locales have pages ?
<seb128> iwj: I'll look if index-<locale>.html exists, and if that's not the case fallback to index-C.html
<iwj> Excellent./
<iwj> seb128: I've updated DapperFirefoxStartPageTranslation to document this new plan.
<seb128> iwj: thank you
<Diziet> I think we should get a formal freeze exception or at least some kind of discussion.  mdz complained about DFSPT that it hadn't been sufficiently approved.
<seb128> fine with me
<iwj> Oops, I'm confused.  Typing into two clients.
<mdke> iwj: yeah
<iwj> mdke: Can you email me a list of the locales to add, then ?
<iwj> mdke: You've just mentioned `ku' so far.  You suggested there were others ?
<dholbach> janimo: I'm going to upload icon-naming-utils with a patch to build symlinks for xfce too
<dholbach> janimo: if you're in a hurry you can rebuild tang*-icon-theme* (once it has built)
<janimo> dholbach: cool, tahnks
<Coyctecm> why amd64 bootsplash is different from x86 o_O
<Coyctecm> well it's not anymore :P
<Coyctecm> why change it back to that old brown...
<Coyctecm> :(
<zakame> hi all
<carlos> pitti: hi, could you execute your script again?
<carlos> pitti: seems like the tarball was ready after your script started...
<carlos> pitti: thank you
<mvo> Kamion: can you please NEW app-install-data-commercial?
<jcole> udev: Conflicts: hotplug which is a virtual package
<ozamosi> Does anyone here knows if Shipit for Dapper really will have the proposed pay-for-faster-delivery-feature?
<pitti> carlos: I can do that, sure
<ploum> arf, no more man pages for C 
<tseng> ploum: manpages-dev?
<ploum> tseng: exactly what I was looking for, thanks :-)
<ozamosi> (or where I should ask)
<Kamion> mvo: where should it live? (component)
<Kamion> ozamosi: #launchpad (for the software) or info@shipit.ubuntu.com (for policy)
<mvo> Kamion: in main please, its just a split-out of the desktop files from app-install-data
<mvo> Kamion: to make post-release updates very simple (and small)
<ozamosi> Kamion: thanks!
<Kamion> mvo: ok, you're responsible for seeding it
<Kamion> source accepted
<kagou> hi
<pitti> hi kagou 
<kagou> hi pitti 
<mvo> Kamion: thanks! it will be a dependency of gnome-app-install 
<siretart> Kamion: while you are at NEW, can you please have a look at fai-kernels as well? 
<siretart> Kamion: they are just installation kernels needed by 'fai'
<Kamion> what does fai need that can't be handled by the standard kernel?
<Kamion> additional kernels are a greater security/support burden
<Kamion> ajmitch: python2.3-imaging-sane  Depends: python2.3-imaging (= 1.1.5-4ubuntu2), python (>= 2.4), python (<< 3), python2.3, libc6 (>= 2.3.4-1), libsane (>= 1.0.11-3)
<mvo> Kamion: IIRC it has no security implications because the kernel is only used to bootstrap the system for new installs, then the "normal" kernel is installed
<zyga> hello 
<siretart> Kamion: they need a option for nfsroot. and they are special, because the build process creates a new kernel image using make-kpkg, which gets included in the binary dep
<Kamion> ajmitch: seems a bit odd
<siretart> deb, that is
<siretart> Kamion: they are only for booting the nfsroot. and every installation is inherently insecure and only sesible in trusted environments
<Kamion> well, support too, in case of bugs
<siretart> Kamion: I talked to thomas lange, fai main author about this
<siretart> they get rebuilt on every upload
<Kamion> not every upload of our normal kernel source
<siretart> it is 'just' a small package with special kernel config, but uses the package 'linux-source-2.6.15'
<siretart> and it it universe after all
<Kamion> oh, I see, that's a bit better
<siretart> fai doesn't make too much sense without it
<siretart> so either we include it, or we cut fai out altogether
<Kamion> for edgy, this should be integrated into the linux-source-2.6.* package directly if possible as an extra flavour, the same way we did for d-i kernels
<Kamion> with that (strong) reservation, I've accepted the source
<siretart> this would need some coordination with the fai team because of the way it is used in fai, but I'll talk to them about that
<siretart> the thing is this: fai expects the binary debian package at some place
<Kamion> thanks
<siretart> which gets extracted into an nfsroot
<siretart> thank you for accepting!
<Kamion> sure, we could deliver that from linux-source-2.6.blah though
<siretart> ok. I'll talk to the kernel team for edgy
<Kamion> cheers
<jcole> i just did a fresh netinstall and it didn't install the full system (no X, no ubuntu-desktop, etc.)... when i do an "apt-get update && apt-get install ubuntu-desktop" i get "udev: Conflicts: hotplug which is a virtual package"... any ideas?
<siretart> I wasn't aware that fai is in that bad state, I'll try to get it prettier for edgy
<Kamion> jcole: how long ago?
<Kamion> network installs were broken until recently due to bogus Task headers in the archive
<jcole> Kamion: last night... i just let it do it's thing last night and went to bed
<Kamion> from some mirror, or from archive.ubuntu.com?
<jcole> Kamion: an internal mirror
<Kamion> and dapper or something else?
<jcole> Kamion: ya, dapper
<Kamion> did you have universe enabled during install?
<jcole> Kamion: i'll point at an official mirror and see if that helps
<Kamion> nothing in main Provides: hotplug
<jcole> Kamion: yes i do
<Kamion> murasaki in universe Provides: hotplug but that's it
<jcole> murasaki?
* jcole looks
<tseng> its for kernel 2.4
<Kamion> if you've never heard of it, I doubt you have it installed
<Kamion> anyway, the archive fix happened over the weekend, so your mirror might not have it yet
<Kamion> the Task headers had been last updated in February - could cause apt some pretty significant confusion
<jcole> weird...
<jcole> root@jcubuntu:~# apt-get remove hotplug
<jcole> Note, selecting murasaki instead of hotplug
<jcole> Package murasaki is not installed, so not removed
<infinity> (base)adconrad@cthulhu:~$ apt-cache show murasaki | grep ^Provides
<infinity> Provides: hotplug
<infinity> I assume you didn't actually HAVE "hotplug" installed, and apt got royally confused.
<Kamion> you didn't have hotplug installed, so apt is trying to be helpful and remove what it thought you meant to remove
<Kamion> well, "helpful"
<jcole> what the heck is providing hotplug? -> "udev: Conflicts: hotplug which is a virtual package"
<zyga> anyone interested in aptitude sigsegv, reproducible
<mjg59_> jcole: udev performs the role of hotplug nowadays
<jcole> mjg59_: maybe it's conflicting with itself somehow?
<Kamion> no, your apt database is just broken
<Kamion> probably due to installing from a very confused mirror
<Kamion> 'apt-get -f install' may help to fix it up a bit
<jcole> Kamion: tried that... doesn't find anything... i'll point to an official mirror and see what happens
<zyga> checking
<infinity> jcole: Is this a custy old install?  If so, "dpkg --forget-old-unavail" works wonders for cleaning up junk that seems to randomly upset apt's problem resolver.
<mdke> iwj: I'll have to do some searching in my email to find others, if there are any. I'll let you know
<iwj> mdke: OK.  Can you let me know ASAP please ?  Otherwise I should do the thing for epiphany now and tag you on later.
<jcole> btw guys, i noticed lots of people slapping in external repos (especially nerim.net) and not pinning to breezy/dapper... do you think it would be a good idea to have default installs with a pinned /etc/apt/preferences file?
<mdke> iwj: can you do epiphany and -ku now? I can always do any others later myself, if I find some
<sladen> jcole: interesting suggestion.  It might well be---or at a least a commented out example of a pinned config
<iwj> mdke: Sure.
<Kamion> Mithrandir: are you using my oem-config baz repository at all? I'm about to convert it to bzr
<mdke> iwj: thanks a lot
<mdke> seb128: re your email, Jane is going to send you the details for the Help menu, I think
<seb128> mdke: ok, cool
<seb128> mdke: I just figured that need to be sorted so sent a mail to get some comments on what to do
<seb128> mdke: feel free to forward to or Cc Jane if you think she should get it ;)
<mdke> seb128: yeah agreed.
<jcole> sladen: i'm thinking about making pinning default for my company's ubuntu net-installs... should work well for those that try to get clever by mixing the debian/nerim repos... what do you think?
<Mithrandir> Kamion: no, since I didn't know about it.
<sladen> jcole: do it and put up a spec with your experiences from doing that... actually have done it and garnered the expereience would be useful
<Kamion> Mithrandir: http://people.ubuntu.com/~cjwatson/bzr/oem-config/mainline/ then
<jcole>  hmm, "apt-get install ubuntu-standard ubuntu-desktop" worked.... but 'aptitude install "~t^ubuntu-standard$|~t^ubuntu-desktop$"' OR 'aptitude install "~n^ubuntu-standard$|~n^ubuntu-desktop$"' give that hotplug conflict error
<jcole> does aptitude have a separate package cache from apt-get? or, does aptitude also install suggests/recommends?
<mvo> jcole: it also install recommends by default
<mdke> sabdfl: erm, your email of just now is completely different to what you said last week, and what Jane just sent me, which I agree with
<mvo> jcole: and it has a different problemResolver (but in practise that should not matter that much)
<mdke> sabdfl: http://pastebin.com/719045
<iwj> seb128: http://www.chiark.greenend.org.uk/~ian/d/ubuntu-docs_6.05.3_all.deb.  Not in dapper yet but this'll help you prepare your epiphany upload.  Let me know whether it seems good to you and get back to me if I've done it wrong.
<_ion> Aptitude also remembers which packages were requested to be installed by the user, and which were installed because of dependencies.
<_ion> That pretty much removes the need to use deborphaner. That is if you only use aptitude.
<jcole> mvo: hmm... for the netinstalls, maybe i  should jsut blank out the pkgsel/install-pattern seed, and have a base-config/late_command post script call apt-get install instead
<seb128> iwj: 404
<iwj> Oh, it seems my uplink is a bit lagged and the file is big.  It's still uploading.
<mvo> jcole: aptitude has a option "--without-recommends" that may help
<seb128> iwj: ok
<jcole> mvo: that's it... 'aptitude install "~n^ubuntu-standard$|~n^ubuntu-desktop$" --without-recommends' works
<Kamion> jcole: base-config/late_command is dead, you need to use preseed/late_command now (and prefix chroot /target)
<Kamion> your mirror is *still* broken though :)
<jcole> Kamion: well, i'm pointing to archive.ubuntu.com now
<Kamion> fresh install from there?
<jcole> Kamion: not fresh yet
<Kamion> I'm not saying that's definitely your problem or that archive.u.c is definitely correct now, but I'd like to see the results of a fresh install from archive.u.c
<jcole> can --without-recommends be added to pkgsel/install-pattern?
<jcole> ...i wonder how many packages i would "lose" though
<ploum> Once I modified  some code that come from apt-get source, how can I make patch against the original package ?
<Kamion> jcole: the code that processes pkgsel/install-pattern already uses --without-recommends.
<iwj> seb128: It's there now.
<jcole> Kamion: ok, i must have a really borked install, that used the wrong task database for install... time to do fresh :)
<seb128> iwj: package looks fine to me, thank you
<iwj> seb128: Good.  I'll rebuild *-{docs,artwork} tomorrow and diff them and pass them to you as well.
<iwj> Don't upload the new epiphany until the new *-{docs,artwork} are in.
<seb128> iwj: right
<jcole> Kamion: regarding late_command, is there also a d-i debconf late_command for when after the system has rebooted and installed all packages? i would like to run a post script that calls binaries not available in the d-i install environment
<Kamion> jcole: chroot /target run_stuff
<Kamion> jcole: in preseed/late_command
<Kamion> jcole: there's no longer anything for when the system's rebooted, but chrooting is practically always sufficient
<jcole> Kamion: interesting
<iwj> Must go now or I'll be late.
<jcole> Kamion: so, something like preseed/late_command = cp /postinstall.sh /target/; chroot /target /bin/sh /postinstall.sh
<Kamion> jcole: where are you going to get your /postinstall.sh from?
<Kamion> jcole: seems a bit baroque, I'd just dump the commands into preseed/late_command chroot /target sh -c '...' directly, but yeah, that'd work if you arrange to get postinstall.sh from somewhere
<jcole> Kamion: i've inserted it into the initrd with preseed.cfg :)
<Kamion> ok
<Kamion> although preferably stick it in /target/tmp/ so it gets cleaned out on reboot
<jcole> Kamion: thanks again for your help
<Kamion> np
<bluefoxicy> meh where is pitti
<bluefoxicy> Huys what is Dapper+1 called
<pygi> edgy eft, but its not for this channel
<tseng> Edgey Eft
* bluefoxicy thinks someone missed a BreezyGoal........
<pygi> #ubuntu+1
* bluefoxicy nods and corrects an old Wiki page.
<bluefoxicy> Hey tseng.
<tseng> hi
<Kamion> bluefoxicy: he's gone off for the evening
<bluefoxicy> Kamion:  Ah, I was wondering if there were any solid plans for https://wiki.ubuntu.com/UbuntuDownUnder/BOFs/ProactiveSecurityRoadmap
<Kamion> I'd suggest mailing him
<bluefoxicy> I guess I'll try back.. another day.  Finals are tomorrow so.. hm?
<bluefoxicy> Got an e-mail addy?
<bluefoxicy> actually thunderbird might know already.
<Kamion> or it's spread all over ubuntu-devel@, dapper-changes@, ubuntu-devel-announce@, ...
<bluefoxicy> yeah, I got it.  I'll speak with him and see if this is going anywhere any time soon.
<bluefoxicy> tseng:  what are you up to these days?  Still chasing kernel bugs?
<tseng> bluefoxicy: no sir, I let BenC build my kernel for me
<bluefoxicy> Got tired of putting 3-4 more security updates in 2.6 every day huh
<bluefoxicy> alright, well, I'm out.  Later.
<Usiu> Hi
<Usiu> How to build ubuntu packages with pbuilder on debian?
<Usiu> any quick guide?
<zyga> Usiu: there is a guide on the wiki
<zyga> check it out
<LaserJock> Usiu: you might check out the chroot and pbuilder sections of http://doc.ubuntu.com/ubuntu/packagingguide/C/index.html too
<Usiu> Ok..
<sladen> dholbach: regarding bug #44856, did the new tangerine g-p-m icons are http://daniel.holba.ch/ubuntu/ic/#battery-charged actually go in?
<Ubugtu> Malone bug 44856 in gnome-power-manager "I always have the old icons..." [Normal,Needs info]  http://launchpad.net/bugs/44856
<dholbach> sladen: gpm doesnt do icon theme look up
<dholbach> sladen: from what i've gathered it does since 2.15.x
<sladen> dholbach: "icon theme look up" ?
<sladen> dholbach: is this some gettext() style-y overide mechanism?
<dholbach> sladen: yes - looking icons up considering the icon theme the user set
<sladen> dholbach: so the theme is providing possible overrides for icons that are otherwise already in the g-p-m package as part of the normal distribution
<dholbach> if the code doesn't use hardcoded pixmaps, but icon theme look up, some gtk functions are used to look up 1) the pixmap in the right size in the users theme, 2) the theme's fallbacks in order, 3) in /usr/share/icons/hicolor
<sladen> dholbach: groovy.  thanks, ta
<dholbach> de rien
* sladen makes a swift exit before any more bugs come in
<_ion> The following packages have unmet dependencies:
<_ion>   gnome-app-install: Depends: app-install-data-commercial but it is not installable
<seb128> _ion: http://launchpad.net
<seb128> _ion: but for that one better to wait probably
<seb128> the package is new and probably needs to be processed 
<_ion> Ok.
<_ion> mvo: Btw, have you had the chance to look at bug #31433 yet?
<Ubugtu> Malone bug 31433 in notification-daemon "notify bubble has text across screens" [Normal,Confirmed]  http://launchpad.net/bugs/31433
<mvo> _ion: slomo__ will take care of it :)
<mvo> _ion: (see #ubuntu-desktop)
<_ion> mvo: Hm, ok. :-) I was bugging you because your name is in the "Assigned To" field.
<seb128> _ion: you can also assume that installability issues are known
<seb128> _ion: and that chan is not an place to report bugs anyway ;)
<mvo> _ion: no worries, we get it fixed :)
<_ion> seb128: Well, i didn't really consider the action of pasting those lines to be the bug report. I pasted them to get some (any) feedback, which i got. :-)
<seb128> _ion: right, but still, that's not the right place to get feedback on an user issue :)
<nekohayo> hmmm... gnome-app-install has a missing dependency (gnome-app-install-commercial), I'd just like to make sure somebody is aware of this
<crimsun> it's not missing; it hasn't been NEWed yet.
<nekohayo> as it blocks from installing ubuntu desktop
<nekohayo> ah I see ok
<Burgwork> crimsun, not so keen on the word commercial there
<Kamion> I've accepted app-install-data-commercial now
<Kamion> Burgwork: you should talk to mvo (who's actually responsible for it) rather than a random person who happened to mention it on IRC :-)
<Burgwork> Kamion, yes, I should. It was more a random comment to spur random discussion that a complaint. It is a slow day at work
* sivang can't wait to test :)
<Kamion> "proprietary" would be more accurate, I agree
<Burgwork> and commercial is one of those weasel words that means too much
* mdke likes it
<mdke> it means something you pay for, I guess. is that what the package is?
<Kamion> it has no real content at the moment, you'll need to ask mvo what the planned contents are
<Kamion> it's there so that it can be added to later without invasive changes
<sivang> mdke: mostly IIRC it contains data of how/where to fetch packages of prop. software.
<Burgwork> mdke, http://www.gnu.org/philosophy/words-to-avoid.html#Commercial
<mdke> Burgwork: that's made me like it even more :) anyhow, it's in my job description
<sivang> mdke: what is it that you do ?
<mdke> Burgwork: anyway that pages kinda confirms. Commercial means non-free-as-in-beer
<Kamion> it's true, merely proprietary stuff can go in multiverse provided that we have permission to distribute
<Burgwork> mdke, but commercial is clearly meant for non-free stuff
<Kamion> commercial in this classification means stuff you have to pay for
<mdke> Burgwork: to me it means stuff you have to pay for
<mdke> it can be free-as-in-freedom
<Kamion> Burgwork: no, my understanding is that it's for stuff that can't go in the Ubuntu repositories because you have to pay for it
<Burgwork> ah, ok
<Kamion> but that's just my understanding, again talk to mvo to make sure
<lifeless> its for third party stuff basically
#ubuntu-devel 2006-05-21
<sladen> so is for Linspire-warez type stuff;  or things (eg. Oracle) where you can probably get the program but have to pay to use it
<sladen> a la, very expensive shareware
<sivang> sladen: some of it is going to be distributed for free, although closed ;-)
<sivang> (closed source, that is)
<mdke> then commercial is _definitely_ the wrong word
<pygi> mdke, lets rather argue what bug we are to fix next :)
<sladen> sivang: in wish case multiverse would be correct?
<mdke> pygi: I'm better at arguing about words than fixing bugs, sadly
<mdke> unless you have any documentation bugs
<pygi> documentation bugs are also nice :-P lets go hunt them down :P
<sivang> sladen: I believe so, closely reselmbling stuff on restricted-modules
<sivang> sladen: btw, oracle now have XE (express edition) which is also for free, but closed.
<sladen> and which comes with Ubuntu instructions... 
<tseng> are they working on certifying ubuntu/oracle?
<_ion> I agree with mdke.
<sladen> I guess the difference is possibly the level of support that will be available from Canonical for it
<sladen> in which case it'll be needing to go somewhere other than *verse
<sivang> sladen: indeed. many have already blogged about it even
<dholbach> good night fellas
<sivang> night dholbach 
<dholbach> night sivang
<_ion> Hi keybuk
<Keybuk> heyhey
<ajmitch> morning
<wasabi__> Bah. Am I the only one SAD that Sun's Java is in Multiverse?
<HiddenWolf> wasabi: not at all, your feelings are shared by some. :)
<HiddenWolf> wasabi: just not those that prefer convenience over freedom. 
<wasabi__> Naw. Even then.
<wasabi__> Kaffe/GCJ/Classpath are quite good contenders for most of the "big" Java apps people keep requesting.
<wasabi__> azureus, eclipse, etc.
<wasabi__> tomcat.
<HiddenWolf> wasabi: unfortuntunatly in this day and age, freedom is not highly valued
<HiddenWolf> even in these circles
<Burgwork> HiddenWolf, freedom is still valued. Ubuntu is not installing it by defaut
<HiddenWolf> Burgwork: I had a user in -nl claiming that, well, ubuntu suited his taste, and it was fun, and easy and different, but he just couldn't care about this "free software" thing, nor understand why people might.
<HiddenWolf> Burgwork: that sucked. :)
<Burgwork> HiddenWolf, the great jdub has "they came for the quality and stayed for the freedom"
<Burgwork> remember the long now
<HiddenWolf> Burgwork: I sure hope so. :)
<sivang> hey Keybuk , also in Mexico ?
<Keybuk> sivang: nope
<sivang> ah, then just switched your day and night times? :)
<Keybuk> my day/night times are variable at the best of times
<lifeless> there gmt, and zulu, and keybuk
<sivang> lifeless: lol
<Keybuk> hmm
<Keybuk> I need chocolate and ice cream
<sivang> anyway, it's way after my bed time here.
<sivang> laters
<wasabi__> Anybody still interesting in an ARM port?
<wftl> Hello all. Can anyone confirm (or deny) whether xchat is part of Dapper?
<wftl> It was there, now it's not, and my latest update seems to have reinstalled it.
<crimsun> xchat-gnome is in main; xchat is in universe
<Keybuk>      xchat | 2.6.1-0ubuntu2 | dapper/universe | source, amd64, hppa, i386, ia64, powerpc, sparc
<FunnyLookinHat> all I know is that dapper tried to install some pice of crap gnome-xchat or something
<Keybuk> xchat-gnome | 0.11-0ubuntu5 |        dapper | source, amd64, i386, ia64, powerpc, sparc
<FunnyLookinHat> xchat-gnome is the sux0r.
<wftl> Well, I guess that answers that [ insert appropriate smiley here ] 
<Keybuk> lamont: xchat-gnome hasn't built on hppa :p
<wftl> Thanks, all.
<lamont> Keybuk: but did it fail, or just not get there yet?
<Keybuk> chroot fuckage
<Keybuk> Errors were encountered while processing:
<Keybuk>  /home/buildd/build-194542-91420/chroot-autobuild/var/cache/apt/archives/x11-common_7.0.0-0ubuntu43_hppa.deb
<Keybuk> E: Sub-process /usr/bin/dpkg returned an error code (1)
<Keybuk> dpkg: error processing /home/buildd/build-194542-91420/chroot-autobuild/var/cache/apt/archives/x11-common_7.0.0-0ubuntu43_hppa.deb (--unpack):
<Keybuk>  subprocess pre-installation script killed by signal (Segmentation fault)
<lifeless> score
<lamont> Keybuk: yeah - said buildd needs to be whacked upside the head... will poke infinity
<jcole> are all arches now available on the primary mirrors?
<Riddell> Kamion: kde ubiquity good to merge when you can
<lamont> jcole: no
<lamont> well, depending on what you mean by that questions
<lamont> s/s$//
* lamont takes it to the other channel
<bddebian> Howdy
<zul> hey
<bddebian> Heya zul
<bddebian> Thanks for uploading that
<zul> no probs
<jcole> man, this is weird
<jcole> i sat here and watched this damn thing netinstall an entire ubuntu, now it's removing everything it just installed... wtf?
<jcole> removing file-roller, removing gedit, etc.
<jcole> ---> http://jcole.org/removing.png
<jcole> netinstall
<whiprush> jdub: ping
<jsgotangco> whiprush: !
<whiprush> hi jerome
<jsgotangco> what's up dude? i just watch the pistons get creamed
<jsgotangco> s/watch/watched
<whiprush> harsh
<whiprush> jsgotangco: how are things in your hemisphere? bringing the wealth of ubuntu as usual?
<jsgotangco> ive been busy at work, but preparing as part of the organizers for a local conference as well in august
<jsgotangco> i'll be at paris too if things go as planned
<whiprush> I think the ubuntu release party/flickr thing this year will be totally bomb.
<ajmitch> hey jsgotangco, whiprush 
<whiprush> hey aj
<jsgotangco> hey ajmitch 
<bddebian> bomb as in "da bomb" or bomb as in "bombed in the box office" :-)
<whiprush> da bomb dude.
<bddebian> :-)
<whiprush> always da bomb.
<whiprush> jsgotangco: I am making the dapperreleaseparty page now.
<whiprush> time to light this candle.
<bddebian> SHouldn't that be "time to light this fuse" ;-)
<whiprush> https://wiki.ubuntu.com/DapperReleaseParty
<whiprush> there we go guys.
<jsgotangco> woo hooo
<jsgotangco> whiprush: dupe, there's DapperReleaseParties page too
<whiprush> jsgotangco: ouch, how out of touch I am.
<pitti> Good morning
<jsgotangco> good morning pitti 
<Keybuk> morning
<pygi> mornin'
<ajmitch> hi
<pitti> hi jsgotangco, moin Keybuk 
<pitti> ajmitch: hello!
<siretart> morning
<siretart> pitti: ping
<pitti> hey siretart
<siretart> huhu pitti 
<siretart> pitti: could you please have a short look at http://librarian.launchpad.net/2652545/buildlog_ubuntu-dapper-i386.fai-kernels_1.10.3ubuntu1_FAILEDTOBUILD.txt.gz
<siretart> pitti: it ftbfs because of a strange error of pkgstriptranslations
<siretart> I have no clue what it is talking about: pkgstriptranslations: inconsistent /CurrentlyBuilding file, Package: value is fai-kernels (should be kernel-source-2.6.15.6-ubuntu1-fai-kernels)
<pitti> ouch, that sounds like a buildd bug
* pitti looks
<siretart> to whom should I talk about this problem?
<pitti> siretart: erm, wait - the real source package name is fai-kernels?
<siretart> yes
<pitti> siretart: does it build a source package within a source package? I. e. tries to call dpkg-buildpackage within the build process?
<siretart> pitti: yes. it distributes a binary package made with make-kpkg in the binary package
<pitti> siretart: ah, that explains it
<siretart> that's what the build is basically doing
<pitti> siretart: please do 'export NO_PKG_MANGLE=1' before building sub-packages
<dholbach> good morning
<siretart> pitti: at the top of debian/rules, I assume?
<siretart> morning dholbach!
<pygi> mornin' dholbach 
<infinity> siretart: Not for the whole package, only for the sub-package build.
<pitti> siretart: well, preferably just for the sub-build
<pitti> hi infinity 
<infinity> siretart: (Though, if your package has no translations anyway, it probably doesn't make a difference)
<siretart> infinity: the sub package build is started via make-kpkg!
<infinity> siretart: So, "NO_PKG_MANGLE=1 make-kpkg blah blah"
<siretart>         make-kpkg --rootcmd fakeroot --append-to-version -fai-kernels --revision $(REVISION) kernel-image
<pitti> infinity: it might make one once pkgmangler also does Maintainer field tricks, right?
<siretart> allright. will do
<siretart> what part of the build gets influenced by NO_PKG_MANGLE
<dholbach> hey siretart, hey pygi
<siretart> and why doesn't this happen on my local machine?
<sivang> morning all
<infinity> pitti: True, though I expect I'll want to make the "search for debian/changelog" a bit more robust so we can mangle the maintainer field in sub-packages too..
<infinity> pitti: Especially for cases like this one.
<pitti> siretart: you don't have pkgstriptranslations installed
<pitti> siretart: and you don't have the buildd black magic with the /CurrentlyBuilding file
<siretart> ok. so like I assumed: there IS black magic going on there.. :)
<infinity> It's not so much black magic as "oh god, get it off me, eww" hackery.
<siretart> aah, and this NO_PKG_MANGLE shortcircuts pkgstripstramslations for the inner build, no?
<infinity> Right.
<infinity> name "NO_PKG_MANGLE" instead of "NO_PKG_STRIP" for the eventual case where we expect this thing to do more mangling.
<infinity> Though, perhaps we might want one variable for each, now that I think about it.
<infinity> Feh.
* infinity shrugs.
<infinity> Hacks upon hacks make the baby jesus cry.
<siretart> :)
<dholbach> hey infinity
<infinity> Bonjour, Monsieur Holbach.
<infinity> pitti: Any urge to take a quick look at bug #44267 for me?
<Ubugtu> Malone bug 44267 in evms "Can't create EVMS volumes with 'n' in the name" [Normal,Unconfirmed]  http://launchpad.net/bugs/44267
<pitti> wow, that looks funny
<pitti> not that I *ever* had used evms...
<dholbach> infinity: Comment a va?
<infinity> pitti: No, but you applied the evil GTK2 patch, which may be the cause here (different hotkey handling, maybe?)
<infinity> dholbach: Comme ci, comme ca.  Vous?
<pitti> ah, right
<pitti> infinity: well, since we're stuck with gtk1.2 in main anyway, I can as well revert it
<pitti> (seems like the safest option right now?)
<dholbach> infinity: Merci beaucoup, a va bien, je suis un peut fatigu
<robitaille> it's nice to see some french around here :)
<infinity> pitti: Assuming that's the cause of the bug, yeah.  I didn't investigate it much, was just going through evms bugs as part my initramfs triage.
<dholbach> robitaille: #ubuntu-desktop replaced #ubuntuf-fr
<dholbach> robitaille: :-p
<Mithrandir> robitaille: I should just start speaking norwegian in here and hope people'll understand too, I guess.
<dholbach> Mithrandir: fire away! :)
<Mithrandir> pitti: I can give it a shot, if you'd like.
<Mithrandir> dholbach: ok, da begynner jeg  snakke norsk. :-)
<pitti> Mithrandir: that'd be nice! I'm just trying to reproduce it
<dholbach> Mithrandir: Mach ruhig weiter - ich glaub ich versteh etwas. :-p
<pitti> Mithrandir: for me it stops at the 'c', but same effect
<Mithrandir> dholbach: jeg forstr tysk snn halvgreit, s det gr fint. :-)
<dholbach> Ok, I stop understanding :-)
<Mithrandir> dholbach: "I understand German decent-ish, so that's ok". :-)
<dholbach> haha :)
<infinity> There's a norsk word for "decent-ish"? :)
<Mithrandir> infinity: half-decent, actually, but yes.
<Keybuk> dholbach: bore da, shwd ych chi bore 'ma?
<pitti> infinity: shall I care for the tbird 1.5.0.2 update?
<Mithrandir> infinity: we tend to just slam words together to make new words.
<infinity> pitti: I've half rescued it from my old drive.  It seems mostly good to go.
<infinity> pitti: I just want to fix up the branding before Thursday, s'all.
<Mithrandir> pitti: ok, evms bug reproduced.
<pitti> infinity: oh, cool
<infinity> pitti: (And am prioritising rescuing/rewriting initramfs changes first, so mdz doesn't kill me)
<infinity> I don't like death.
<pitti> understandable :)
<Keybuk> infinity: yeah, whatever happened to that? :p
<hendry> i just installed kubuntu from scratch and the time/date is wrong
<hendry> i chose the correct timezone
<infinity> hendry: Hardware clock in localtime instead of UTC?
<infinity> hendry: I think Kamion just uploaded some fixes for that.
<Keybuk> mdz: you're not supposed to come onto IRC drunk
<pitti> hi mdz 
<desrt> Keybuk; interesting usplash release....
<mdz> Keybuk: my client automatically reconnects when I get near a network
<Keybuk> desrt: which one?  I didn't do anything interesting
<Keybuk> I just put the image back to the old one until we get a better new one
<desrt> refering mostly to the rationale behind the release
<Keybuk> oh, heh, I was grumpy :0
<desrt> :)
<Keybuk> you try spending an entire weekend explaining that "640x400 in 4:3 aspect ratio" does not mean "do it in 640x480 then rescale it"
<desrt> where's his proposed screen?
<hendry> infinity: `hwclock` reads 01:20 KST
<Keybuk> we don't have on at the moment
<desrt> ah.  it sounded like he sent you one
<hendry> infinity: which is wrong. wrong for utc and locatime
<Keybuk> oh, I got several in my inbox, they're all ... unsuitable
<desrt> what's the deal with the text thing anyway?
<Keybuk> "text thing" ?
<desrt> why is it that it absolutely must stay for dapper?
<desrt> (i was trying to defend this point to a friend, but realised that i don't really have any solid reasons to defend it)
<Keybuk> because we rely on it being there for a few things
<Keybuk> e.g. "you can now eject the live cd" :p
<infinity> desrt: At this point, there's no point in defending it at all, except to say "that's the way it is, we're hard freezing in 2 days for release candidates, cope"
<desrt> 2 days holy crap
<infinity> desrt: Yes, we could run around changing things that rely on it as-is, but we have real bugs to fix.
<Keybuk> I thought it was 3 days
<desrt> "we have real bugs to fix" is a very valid excuse at this point in the release
<infinity> Keybuk: Depends on your timezone.
<Keybuk> infinity: fair point
<Keybuk> though I wouldn't like to hazard a guess with my timezone
<Mithrandir> Keybuk: hmm?  Casper displays that message on a text console if you don't run usplash.
<ivoks> pitti: would it be to late to create mozilla-firefox-locale-hr?
<pitti> ivoks: no, if you have a working xpi, I can add it
<Keybuk> Mithrandir: right, the proposal is to run usplash and comment out the text code though
<ivoks> pitti: ok, thanx
<pitti> ivoks: oh dear, I *just* uploaded a new orig.tar.gz for m-f-locale-all :/
<infinity> Mithrandir: Right, but it doesn't magically display it if you're running a usplash with no text output. :)
<Keybuk> so casper would be displaying the message on a console hidden by a usplash that's just displaying pretty graphics
<Mithrandir> Keybuk: oh, that'll break spectacularly.
<ivoks> pitti: i saw :)
<Keybuk>  Source and binary promotions to main
<Keybuk>  ------------------------------------
<Keybuk>  o bzr: bzr
<Keybuk>    [Reverse-Depends: Dapper ship seed] 
<Keybuk> heh
<pitti> finally :)
<pitti> oh, in ship?
* Keybuk sees no MIR
<desrt> Keybuk; do you vendorpatch vim _at all_?
<Keybuk> desrt: do I personally?
<desrt> for ubuntu
<Mithrandir> Keybuk: do we need one?
<infinity> I suspect it's quite heavily patched.
<Keybuk> I wouldn't like to hazard a guess about Ubuntu, except "probably"
<Keybuk> it's got like 1,000 patches in its source tree
<Keybuk> Mithrandir: *shrug* dunno
<Keybuk> mdz: do we? :p
<desrt> oh.  i though you packaged it
<desrt> nm
<Keybuk> desrt: I'm an emacs man!
<pitti> it's a pretty pathologic case - in-house project and we all use it anyway  
<desrt> uh.  you're guilty :p
<desrt> source is last-changed by you and you own the launchpad product :p
<infinity> desrt: Yes, vim is heavily patched.
<infinity> (base)adconrad@cthulhu:~/vim/vim-6.4$ ls -1 patches/ | wc -l
<infinity> 54
<Keybuk> desrt: I own lots of launchpad products by virtue that I was once in the team that registered products in launchpad
<Mithrandir> most of the vim patches are grabbed from upstream, iirc.
<desrt> here's a nice new patch https://launchpad.net/distros/ubuntu/+source/vim/+bug/44431
<Ubugtu> Malone bug 44431 in vim "vim autoindent + :set bs=0 + ctrl+u is broken" [Normal,Unconfirmed]  
<Keybuk> Kamion: what do you think?  do we need an MIR for bzr, bzrtools, celementtree, paramiko ?
<pitti> Keybuk: I just think this stuff does not really belong into ship...
<Mithrandir> pitti: where would you put it, then?
<pitti> well, supported
* infinity is fine with ship or supported, nothing higher.
<pitti> but putting it onto the CDs would just be a waste of space...
<infinity> Will it blow out the CDs that much if it's in ship?
<Mithrandir> pitti: If I were to argue, I'd say desktop since we want to ship a development environment in -desktop already.
<pitti> Mithrandir: we don't, we don't even have gcc
<Mithrandir> we have python-* though
<Mithrandir> (and bzr is more useful than, say, bicyclerepair
<infinity> pitti: We ship a python devel environment.  Have you not been here for the last 300 flamewars? :)
<Mithrandir> )
<pygi> :-P
<pitti> infinity: we ship python modules, but does that already count as DE?
<infinity> pitti: It does when nothing depends on them.
<infinity> pitti: We're clearly shipping them so people can program against them, not because anything in -desktop needs them.
* Keybuk decides to ignore bzr for a while ;)
<pitti> ok, it would add less than 1 MB, but still...
* pitti decides to not care enough to start a serious discussion and shuts up
<Keybuk> nobody proposed bzrk
<janimo> seb128: hi, are you planning evince 0.5.3 for dapper?
<seb128> janimo: I didn't even know there was a 0.5.3
<seb128> janimo: I'm just starting working, didn't read my mails from the night yet
<desrt> if anyone cares to ack my vim patch i'd be happy to roll the new version of the package....
<dholbach> Keybuk: does it work again?
<Keybuk> dholbach: apparently
<dholbach> ROCK ON
<janimo> seb128: ok, so there is a release :). If you plan it for dapper I'll update the gtk patch too, that's why I asked
<seb128> janimo: I'll upload if that's a GNOME 2.14.n material
* dholbach hugs Keybuk
<seb128> janimo: GNOME 2.15.2 due this week so will need to check what they did
<Keybuk> dholbach: hug ddaa, not me
<Keybuk> he maintains it these days
<janimo> seb128: don;t know what evince's relationship with gnome 2.14
<dholbach> ah, I didn't know
<janimo> they dep on gtk 2.8 now 
<janimo> seb128: anyway I'll just wait and see what you do
<seb128> janimo: that is not an issue
<desrt> bedtime.  nite everyone.
<seb128> desrt: I just uploaded a new ubuntulooks, number of dots for panel grip has been set to 6
<seb128> desrt: 'night
<desrt> seb128; oo.  sexy :)
* desrt out.
<pygi> seb128, I'll need to talk to you later about google calendar Evo plugin
<seb128> pygi: if you want
<seb128> janimo: looks GNOME 2.15 material that evince
<janimo> seb128: ok then
<seb128> janimo: "    * GOption port and po/LINGUAS work" that might require intltool 0.35 for po/LINGUAS work
<dholbach> might be the same for gnome-mag
* dholbach tries
<Keybuk> http://antwrp.gsfc.nasa.gov/apod/image/0605/iss2_sts114_big.jpg
<Keybuk> ^ that is damned pretty
<seb128> dholbach: if you do an update make sure than .po are shipped and .mo installed
<dholbach> seb128: yep
<janimo> seb128: configure: error: Your intltool is too old.  You need intltool 0.35.0 or later. You're right ;)
<dholbach> seb128: looks good.
<Treenaks> Keybuk: 'gloomy outlook: the revenge'?
<Mithrandir> pitti: ok, evms bug fixed and uploaded.
<pitti> Mithrandir: rock!
<Mithrandir> pitti: not putting GDK_MOD1_MASK when adding accellerators is a bad idea. :-P
<pitti> lol
<pitti> Mithrandir: that was a bug in the gtk2 patch?
<Mithrandir> yup
<Mithrandir> http://err.no/patches/evms_gtk2_dont_grab_random_keys.diff is the patch
<Mithrandir> also, s/accellerator/accelerator/
<dholbach> TheMuso: gnome-mag is still not happy with xtest/xdamage/xfixes on nvidia (orwherever the problem is)
<TheMuso> dholbach: Right. I haven't tried it again recently.
<dholbach> TheMuso: seems like stuff for edgy to explore :)
<TheMuso> And as I don't have any nvidia hardware, it makes it a little difficult for me to try and reproduce.
<dholbach> I was able to reproduce on ati as well.
<Keybuk> dholbach: gnome-mag not installed by default?
<TheMuso> dholbach: Well there is the new magnifier being discussed on ubuntu-accessibility@
<TheMuso> hmmm.
<TheMuso> I must try it again.
<dholbach> Keybuk: It is, it's just not in the menu.
<TheMuso> Keybuk: gnome-mag is supposed to work with XDamage/XFixes libraries for smoother rendering, but dholbach seems to have problems using it with them enabled.
<dholbach> Keybuk: you can enable it in gnome-at-properties
<Keybuk> dholbach: I couldn't find a binary by pressing tab :)
<dholbach> Keybuk: /usr/bin/magnifier :)
<Keybuk> that just sits there doing nothing
<dholbach> you might have to restart session with a11y enabled
<TheMuso> Magnifier is a back-end for other front-end apps, like gnopernicus.
<Keybuk> meh
<Keybuk> will play with that later then
<Keybuk> even if just to confirm it doesn't work on nvidia
<dholbach> Keybuk: I didn't enable the xtest/xdamage/xfixes stuff in the current build because of that brekage
<Keybuk> infinity is going to break nvidia anyway
<Keybuk> if he gets around to it ;)
<infinity> Hey now.
<infinity> I don't plan to break anything.
<thom> you never /plan/ to, mate ;-)
<Keybuk> Well, what you plan and what takes place ain't ever exactly been similar. 
<infinity> Keybuk: Pot, kettle.
<Kamion> Keybuk: I don't think bzr really needs one (since it's Canonical-produced software), but I'd like pitti to look over bzrtools, celementtree, paramiko for sanity
<Keybuk> pitti: could you look over those, then
<pitti> yep, added to my todo list
<TheMuso> dholbach: I am going to rebuild with the patch included and see what happens on the 4 machines I have here... Three are ATI, one is a matrox.
<dholbach> TheMuso: ok, uploaded gnome-mag 0.12.5
<TheMuso> dholbach: You're a champ. Thanks heaps.
<dholbach> TheMuso: thanks  :-)
* Mithrandir hugs dholbach 
<dholbach> TheMuso: let's see how orca works with it
* dholbach hugs Mithrandir back
<mdke> presumably it's known that getting an ip address with dhcp isn't updating /etc/resolv.conf? I've just realised that this is the cause of all my problems
<infinity> mdke: It does for me..
<infinity> mdke: Do you have the (vile) "resolvconf" package installed?
<mdke> infinity: it's marked as "un"
<Keybuk> I'm so going to change the resolvconf description to "Install this package to break your computer"
* infinity ponders what else could break dhclient's resolv.conf handling.
<mdke> i talked my brother through dist-upgrading to dapper from a default breezy install over the phone, and he had this problem
<mdke> and I just noticed it on my computer this morning
<Keybuk> infinity: dhclient's resolv.conf handling is ultra-brittle
<Keybuk> being done in a complicated shell script that's a conffile
<Keybuk> for example
<mdke> do you want a bug report?
* infinity looks at his shell and realises he's successfully managed to confuse himself.
<infinity> Oh, POSIX, why do you mock me?
<JaneW> JaneW SoC mentors: I will try to mail later (but our mail is down again here...) please can you look at finalising the application review, ranking and make your selections for mentoring by COB tomorrow (wed 17 May).
<ajmitch> JaneW: a few hundred applications for you to read through? :)
<JaneW> ajmitch: 240 or so...
<ajmitch> not so bad
<pygi> ajmitch, I've done that already :P 3 times :)
<JaneW> ajmitch: this year the mentors get to make the selections :P
<ajmitch> wonderful 
<JaneW> Mentors: see this ML thread for more info on timings and selection requirements http://groups.google.com/group/Summer-Administrators-2006/browse_frm/thread/74d7f5262a3cb013/05d64e764e7872a1#05d64e764e7872a1
<jsgotangco> ack
<mdke> infinity: are you *sure* it's updating resolv.conf? you don't just have your old one?
<jsgotangco> heh great im not on the list
<infinity> mdke: I can verfiy that pretty quickly.
<mdke> infinity: thanks
<ajmitch> infinity: have you got the results of the universe autobuild test you did?
<infinity> ajmitch: Will you be around for a few hours to bug me again?
<ajmitch> yep
<pygi> pitti, poke?
<infinity> mdke: Confirmed, it's updating just fine.
<pitti> pygi: *eek*
<pygi> pitti, does your pmount works on bsd systems as well? I am interested in using that for Gnomebaker
<mdke> infinity: so what can I do to help with my problem? as I say, i saw it on a new dist-upgrade yesterday
<infinity> mdke: You can bug pitti incessantly about it, since he LOVES the dhcp3 package!
<infinity> pitti: Isn't that right? :)
* pitti is at phone, lagged
<sivang> oh, the right excuse :p
<pitti> re
<pitti> pygi: so, pmount-hal needs hal, obviously
<pitti> pygi: if you don't use pmount-hal, just pmount, then you still need a /sys directory, which probably doesn't exist in BSD
<pygi> well, ok, if I have hal :)
<pitti> mdke: hm?
* pygi isnt very fammiliar with bsd :(
<pitti> infinity: go away
<infinity> :)
<infinity> mdke: You should probably file a bug.  The contents of /etc/dhcp3/{dhclient.conf,dhclient-script} may be helpful, as well as "ls -l /etc/resolv.conf"
<mdke> pitti: i'll file a bug, no worries
<mdke> infinity: thanks
<infinity> mdke: Not sure what else, really.
<pitti> mdke: I'm sub'ed to dhcp3, I'll see it
<mdke> pitti: i bet you have one already, lemme look
* infinity goes back to bending his brain around broken shell.
<infinity> mdke: Lots of bugs have come and gone relating to resolv.conf breakage.  I wouldn't assume yours is a duplicate unless someone describes the EXACT problem (ie: with enough detail for you to solve it too)
<mdke> alright, I'll file a separate one
<mdke> :)
<mdke> ah shit
<mdke> I can't reproduce it from the console, looks like it might be gst
<mdke> meh, /me goes to investigate a bit better
<infinity> I WIN!
<infinity> (Okay, I'll shut up now)
<pygi> infinity, what you won this time? :P
<infinity> pygi: A raging and epic battle with jbailey's shell. :)
<pygi> infinity, o joy :)
<Treenaks> infinity: Stories will be told of this for centuries to come!
<Keybuk> rofl
<Keybuk> leave jbailey's shell alone
<Keybuk> it's lovely
<Keybuk> if you hold it up to your ear, you can hear the sweet sounds of POSIX coming out
<infinity> It is rather, actually.
<infinity> But when you're hacking at a particularly twisty bit you've never read before, sometimes your eyes bleed just a little.
<infinity> At least it's not his make. ;)
<Keybuk> that's shell for you
<Keybuk> does make really run "sh -c ..." for every single line?
<infinity> What else would it do?
<Keybuk> dunno
<Keybuk> that just seems inefficient
<infinity> Well, it runs $(SHELL) -c, but yeah.
<infinity> Or is it $(SH)?... Whatever.  The one that it runs is what it runs! :)
<Mithrandir> it's SHELL
<infinity> I suppose if shell startup time were so horrible that people cared, they'd implement some crazy shelld or something.
<Kamion> Keybuk: no, it doesn't
<zakame> hi all
<Keybuk> Kamion: what does it do?
<infinity> Kamion: Then it's magic? :)
<Kamion> if the command is "sufficiently simple" then it invokes it directly
<infinity> So, no shell expansion, and no builtins?
<infinity> Or something equally strange?
<Kamion> I'm pretty sure this is true anyway - let me dig up the reference
<infinity> That seems rather error-prone, unless someone stays on top of what should and shouldn't be passed to a real shell.
<Keybuk> 10012 pts/6    S+     0:00      \_ make test
<infinity> (Since you expect every line to end up passed to SHELL)
<Keybuk> 10013 pts/6    R+     0:00          \_ ps fax
<Keybuk> no interim there
<Mithrandir> infinity: builtins should work just the same as the real commands, shan't they?
<Keybuk> 10033 pts/6    S+     0:00      \_ make test
<Keybuk> 10034 pts/6    S+     0:00          \_ /bin/sh -c true && ps `echo fax`
<Keybuk> 10036 pts/6    R+     0:00              \_ ps fax
<Keybuk> heh
<Keybuk> Kamion appears to be correct
<infinity> Mithrandir: Well, in theory, but if you want the "real thing", you would generally use a path, if you want the builtin, you don't use a path and expect SHELL to do it for you.
<infinity> But, I suppose in the case of a makefile that point is more or less moot.
<infinity> You wouldn't pull the same shell tricks in make that you would in shell itself.  I hope.
<infinity> (Not when you have make tricks instead!)
<Mithrandir> infinity: unless you're jbailey? :-)
<infinity> No, jbailey's make is very shell-free, for the most part.
<Keybuk> I wonder what's more evil
<infinity> That's why people who don't know make find it unreadable.
<Keybuk> sh -c "many lines of shell"
<Keybuk> or
<Keybuk> sh /dev/fd/X ... and write the lines one by one
<infinity> (Compare to, say, the apache2 debian/rules, which is just a shell script cleverly disguised asa makefile)
<Kamion> When it is time to execute commands to update a target, they are
<Kamion> executed by invoking a new subshell for each command line.  (In
<Kamion> practice, `make' may take shortcuts that do not affect the results.)
<Kamion> that's the only hint I've found in 'info make' so far
<Mithrandir> Keybuk: sh <<EOF is nice, IMO.
<Kamion> I'm sure I read about it in some documentation a while back though
<Keybuk> Mithrandir: isn't "<<EOF" parsed by a shell? :p
<Kamion> I believe if you have metacharacters in there then make will give up and punt to a shell
<Mithrandir> Keybuk: oh, you were wondering about more evil.  I answered the "less evil" part.
<Keybuk> just mulling possibilities from a C exec() POV... if you have some shell you want run
<Keybuk> is it better to pass it in with -c, or to play /dev/fd tricks
* Mithrandir wonders about bug 34126.  Is ctrl+alt really supposed to give you level 3 shift?
<Ubugtu> Malone bug 34126 in xkeyboard-config "Ctrl-Alt expected to work like AltGr?" [Minor,Confirmed]  http://launchpad.net/bugs/34126
<Kamion> I prefer -c to avoid the extra file descriptor
<Keybuk> Kamion: though that way you could end up with a few hundred lines of shell in ps output
<sivang> Mithrandir: we support IA64 fully , right?
<pitti> carlos: hi! btw, fully automatic langpack generation with latest tarball worked just fine yesterday :)
<Mithrandir> sivang: no, it's a port, not a core arch.
<Mithrandir> (or whatever the term is)
<carlos> pitti: cool
<pitti> Mithrandir: SCC? (Second class citizen)
<Mithrandir> pitti: thanks.
<infinity> Oh, neat.  One of my bugfixes has the cute side-effect of making mkinitramfs no longer complain about "circular dependencies" based on moon phase, but rather only when one actually exists.
<infinity> Bugfixes for free, for the win.
<infinity> pitti: We use "port", not "SCC". :)
<infinity> pitti: We frown on "SCC", cause it's not terribly friendly, apparently.
<Keybuk> "SPECIAL ARCHITECTURE"
<pitti> infinity: speaking of 'treated with less care': did you see the failed quagga build on hppa for breezy-security?
<pitti> infinity: it fails with 'epstopdf: command not found', very strange...
<Keybuk> pitti: probably needs "Depends: tetex-bin" ? :p;
<infinity> Erm, yeah.  I just got there.
<Keybuk> uh, Build-Depends
<infinity> That makes no sense, given that it builds on the other arches...
<pitti> Keybuk: that's already there
<Keybuk> magic document regenerating
<Keybuk> oh, yeah, it is
<infinity> Oh, feh.
<Keybuk> the hppa chroot was broken earlier
<Keybuk> cf. xchat-gnome not being built
<infinity> pitti: That chroot appears to be dirty.  I'm betting a previous build exploded it.
<infinity> Keybuk: Different chroot, different buildd, different network. :)
<infinity> Keybuk: xchat-gnome wasn't chroot breakage, it was kernel breakage causing package removal to go south.
<Keybuk> bah :p
<infinity> Keybuk: But chroots in the LP world are rm -rf'd after builds.
<infinity> pitti: Let me poke castilla with a stick and see what's up with that chroot.
<pitti> infinity: do they actually get rm-rf'ed? or is there something more efficient like unionfs?
<infinity> pitti: The fact that tetex-bin was already in the chroot is a bit red flashing warning that something's wrong. :)
<Keybuk> pitti: tar xf, chroot, rm -rf
<infinity> pitti: They actually get rm -rf'd... Who needs efficiency when we have horsepower?
<Chipzz> infinity: heh
<Keybuk> (believe it or not, I actually knew that, I just forgot)
<pitti> right, hard disks are indestructible anyway
<Chipzz> infinity: and what about disk wear?
<infinity> Chipzz: Disks are cheap.
<infinity> Chipzz: Very.
<Keybuk> sysadmins are easily bored
<Chipzz> you still need to actually go there and replace them
<Keybuk> if they don't have things to do, they get destructive
<Mithrandir> Chipzz: they're still very cheap.
<Kamion> Chipzz: we know.
<infinity> Chipzz: unionfs, on the other hand, is SKETCHY AS FUCK.
<infinity> So, y'know.  I'll take broken disks.
<Mithrandir> infinity: unionfs is 
<Keybuk> yeah, bit of luck we're not relying on unionfs for anything critical
<Keybuk> like the cds we'll be shipping
<Kamion> LIKE OUR INSTALLER
<infinity> Keybuk: Shh. :)
<infinity> Mithrandir: Whatever character that was, my terminal didn't like it.
<Mithrandir> Keybuk: don't upset the live cds.
<Mithrandir> infinity: U+2764 HEAVY BLACK HEART
<infinity> Mithrandir: If it's the inicode character for a pile of poo, I agree.
<infinity> s/inicode/unicode/
<pitti> it's rendered quite nicely here
<pitti> so at least the fonts should be there
<Keybuk> 
<infinity> pitti: I'm running irssi on a woody machine.  I suspect that's causing some issues. :)
<Keybuk> that's the unicode character for poo
<Keybuk> well, U+1434 CANADIAN SYLLABICS POO
<pitti> that's just a '1434' with a box around
<infinity> Canadian poo, no less.
<Keybuk> pitti: aww, you mean you can't see the cute Unicode Stargate symbol (  ) either? :p
<pitti> no :(
<Keybuk> you need Code2000
<sivang> 
<sivang> s
* pitti finally grabs some breakfast, bbl
<sivang> Mithrandir: okay , cool, so that means we do not officially support it.
<MrFaber> hi all
<Keybuk> hmm, breakfast
<Keybuk> there's an idea
* Keybuk also goes to eat breakfast
<MrFaber> I have problems with the blkid dev library in Dapper. I can't compile util-linux because it didn't find the lib while it is installed. What could be the problem?
<Chipzz> infinity: anyway, installing/removing stuff from a chroot /should/ be a null operation
<infinity> Sure, but it isn't.  We all know how it could "ideally" work.
<Kamion> Chipzz: it's not that uncommon for postrm scripts to fail and the buildd admin to have to go rescue the chroot by hand
<Kamion> rm -rf is a lot more reliable, albeit less efficient in a number of way
<Chipzz> Kamion: yeah I know :S
<Chipzz> Kamion: but don't we have all kinds of scripts to test the quality of packages?
<Kamion> sure, but we don't want our build process to be dependent on those
<Kamion> particularly since the build process is necessary to deploy fixes to the exact same problems that might break the build process in the old model
<Chipzz> one thing that does pop to mind is testing on a seperate chroot and comparing results before/after; which you'ld only have to do for one architecture
<Kamion> doing this is good and useful, but it shouldn't block our build process
<Mithrandir> Chipzz: no, you'd need to do it for all arches and test upgrades and stuff.  There's a tool, piuparts which does this.
<infinity> pitti: Two hppa security builds rescued; thanks for the heads-up.
<infinity> Keybuk: You have a lock on udev, or do you mind me uploading it in the next 10 minutes?
<Mithrandir> dholbach: isn't https://launchpad.net/products/shared-mime and https://launchpad.net/products/shared-mime-info the same project?
<Mithrandir> +s
<Mithrandir> s/isn't/aren't/
<dholbach> Mithrandir: hum
<dholbach> looks like :-/
<dholbach> i'll ask, what can be done
<pitti> infinity: great
<seb128> dholbach: nothing
<seb128> dholbach: we have several similar cases and the reply was the same
* mvo is away for lunch
<sladen> mjg59_: regarding #37555, got any thoughts on  "Dim brightness when idle" -> brightness change = KEY_PRESS -> no longer idle so no screensaver loop
<mjg59_> sladen: Fixed
<mjg59_> Oh, hm. Possibly not entirely fixed.
<mjg59_> Ought to be, though
<sladen> mjg59_: how so?
<mjg59_> I uploaded a gnome-screensaver that doesn't unlock itself on brightness key events
<HiddenWolf> mjg59_: might you repeat that trick for volume keys? :)
<mjg59_> Might be worthwhile
<Keybuk> infinity: nope, no lock
<mjg59_> Though it also needs fixing not to unlock when the lid is closed
<sladen> how is the lid closing generating a keypress?
<sladen> if hal performed the brightness changes and hal also did the brightness polling, then it would know when not to generate keypresses
<mjg59_> sladen: It's not
<mjg59_> sladen: Also, hal doesn't (and shouldn't) do the brightness changing
<sladen>  /usr/share/hal/scripts/hal-system-lcd-set-brightness ?
<mjg59_> Or, rather, it performs the actual change, but it's not responsible for making the decision to change
<sladen> it could effectively "lock" around the change and prevent keypresses being generated.  Anyway not for dapper, lets ignore it
<Kamion> Riddell: merged, btw
<Riddell> Kamion: cool, thanks
<Treenaks> jdub: if you need a replacement for your orange suit, look here: http://www.praxis.nl/upload/8ee016010b1da17d06013f4.jpg
<Mithrandir> jordi: spanish keyboards are pc102/105, not pc101/104, right?
<jordi> right
<Mithrandir> thanks.  I wonder why xkb-c thinks they should be pc104, then
<Mithrandir> jordi: actually, can you reproduce https://launchpad.net/distros/ubuntu/+source/xkeyboard-config/+bug/43428 ?  I can't.
<Ubugtu> Malone bug 43428 in xkeyboard-config "Can't enter characters <> with Spanish keyboard layout" [Normal,Unconfirmed]  
<jordi> hmm, can't test this right now at office
<jordi> I can from home, probably when I go back tonight
<Kamion> Mithrandir: could you look at and merge http://people.ubuntu.com/~cjwatson/bzr/casper/preseed/ ? I'd like to support command-line preseeding in dapper so that we can possibly work around ubiquity problems using it.
<Mithrandir> jordi: thanks, will you remember or should I send you a mail or something?
<jordi> can you mail me?
<jordi> that works best :P
<Mithrandir> jordi: sure.  jordi@u.c?
<jordi> yup
<Mithrandir> Kamion: you removed the preseeding of d-i/locale and kbd-chooser/method because nothing look at it, or?
<Kamion> Mithrandir: no, because in my branch they're now handled by 24preseed along with all other command-line preseed variables
<Kamion> 19keyboard still preseeds debian-installer/keymap because that's a special case
<Mithrandir> Kamion: ah, bzr diff doesn't show new files
<Kamion> 24preseed isn't a new file
<pitti> Mithrandir: uh? since when?
<Kamion> === modified file 'casper-bottom/14locales'
<Kamion> === modified file 'casper-bottom/19keyboard'
<Kamion> === modified file 'casper-bottom/24preseed'
<Kamion> === modified file 'debian/changelog'
<pitti> Mithrandir: works here (bzr diff showing new files)
<Mithrandir> pitti: sorry, my fault.
<Mithrandir> Kamion: hmm, it's not new.  I wonder why I thought it was.
<Kamion> want to pastebin the diff you've got so I can make sure it's right?
<Mithrandir> http://paste.ubuntu-nl.org/14113
<Kamion> yep, that's right
<Kamion> debian-installer/locale and kbd-chooser/method should be handled by the */* case in 24preseed
<Mithrandir> indeed.
<Kamion> the main case I'm thinking of is that it would be useful for people to be able to boot with clock-setup/utc=false
<Mithrandir> this actually means I can clean up a bit of casper code, but I don't think I'll do that at this point in the cycle.
<Kamion> because ubiquity probably won't have UI for that now for dapper
<Mithrandir> ok, releasing 1.53 now, at least once bzr decides to finish pushing.
<Kamion> it may be the placebo effect, but knits do seem rather faster to push
<Mithrandir> does it upgrade to knits automagically?
<Kamion> no, 'bzr upgrade' does it
<Kamion> haven't tried them with sftp push yet
<pitti> mvo: ping
<mvo> pitti: pong
<pitti> mvo: can you please take a look at bug 44973?
<Ubugtu> Malone bug 44973 in langpack-locales "dpkg-reconfigure locales is not automized?" [Normal,Unconfirmed]  http://launchpad.net/bugs/44973
<pitti> mvo: (sorry, the bug title is totally wrong)
<pitti> mvo: it's about stalling synaptics with non-debconf postinst questions
<pitti> mvo: I believe this question (time zone) comes from libc6, not locales, right?
<pitti> mvo: which would make it a dup of bug 30815
<Ubugtu> Malone bug 30815 in glibc "Please debconfify timezone questions" [Wishlist,Unconfirmed]  http://launchpad.net/bugs/30815
<Mithrandir> 30815 should be rejected.
<mvo> Mithrandir: why?
<pitti> Mithrandir: why? asking questions on the command line in postinst scripts is just wrong
<pitti> it breaks GUIs like synaptic as well
<mvo> pitti: tzconfig is in both libc6 and locales postinst for some reason
<Mithrandir> pitti: debconf might not work when libc isn't configured yet.
<mvo> Mithrandir: the it should be done in the locales package or something. asking this king of question in a postinst is really not good
<Kamion> actually, while that's true for some other things debconf depends on, libc6 is depended on by essential packages and therefore must work even when unconfigured
<Kamion> the problem is more that when libc6 is configured, debconf might not even be there (bootstrapping), so it needs to have fallback code for that case
<mvo> pitti: synaptic will auto-expand after ~120sec without activity on the terminal, but that is far from optimal
<pitti> mvo: at least it's good enough as a last resort
<Kamion> fixing it is incredibly invasive for dapper; I think we have to stick with the current code for now
* pitti agrees
<Kamion> editing libc6.postinst 16 days before release isn't my idea of fun :)
<mvo> AFAIK it is not triggered for everyone, I have seens this only very rarely
* mvo upgrades his locale package 
<janimo> pitti, hi are you still doing main inclusion reviews for dapper?
<pitti> janimo: nobody urged me to recently
<janimo> pitti, ok can you please take a look at xfburn and the xfce screenshot plugin when you have time? thanks
<pitti> ok
<janimo> dholbach: hi, you mentioned yesterday something about rebuilding tango for xfce icons. Is that still a valid task to do?
* pitti -> lunch
<dholbach> janimo: tango-icon-theme could do with a rebuild - i uploaded newer version of the rest of the stuff
<janimo> dholbach: so just a reupload basically? I did not touch that package yet so dunno 
<dholbach> janimo: yes - you can do that, if you like
<janimo> dholbach: ok ,wil ldo now
<dholbach> super
<dholbach> if you debdiff the old and the resulting new package you will see which symlinks were added for xfce goodness
<sladen> mjg59_: http://forums.gentoo.org/viewtopic-t-462556-highlight-x60s.html regarding suspend on the X60*
<janimo> dholbach: ok, thanks.
<mjg59_> sladen: I believe we have all the code in those patches
* Kamion discovers a way to trim 26.6 MB off all our powerpc live CDs
<Kamion> whoops, cp -a != mv
<infinity> Kamion: Close enough...
<pitti> Kamion: I guess cp -al won't work on iso9660?
<pitti> 26 MB? /me hugs Kamion
<pitti> Kamion: if you have some minutes later today, could you please take a look at bug 14597? I'll do the necessary seed changes myself, but I'd appreciate your opinion
<Ubugtu> Malone bug 14597 in gimp "English Gimp help files are not installed by default" [Wishlist,Needs info]  http://launchpad.net/bugs/14597
<Kamion> pitti: it didn't need to be in both places
<Kamion> pitti: we would have to put the relevant pieces from l-s-en in desktop, or they wouldn't get installed
<Kamion> which then makes them difficult to uninstall
<pitti> Kamion: yes, 'and instead seed a subset of the current dependencies'
<Mithrandir> seb128: any idea what would be a useful place to find users with french keyboards and macs?  #ubuntu-fr?
<Kamion> pitti: you didn't say *where* to seed them :)
<pitti> Kamion: hm, I see
<Mithrandir> seb128: and are people ok with speaking English in there?
<Kamion> what packages would need to be added to desktop?
<pitti> Kamion: desktop and live, I guess
<Kamion> no need to add something to live if it's already in desktop
<pitti> Kamion: the firefox and OO.o translation/help; my gut says that we can drop thunderbird-locale-en-gb from the cd
<janimo> mvo: does the language-support pack be present for setting a specific locale using the language chooser?
<janimo> are sleected translations + firefox-lo not enough?
<Kamion> oh, yes, thunderbird itself is no longer on the CD
<janimo> I am thinking how to put more translations on the CD but if possible have more ffox/tbird translations and not necessarily OOo ones
<Kamion> pitti: that doesn't sound too bad, although I just know it will generate complaints
<pitti> Kamion: I know, it's about choosing which kind of complaints we want to get :/
<pitti> missing translations or uninstallable packages
<pitti> I'm fine with leaving it like it is for dapper and reconsidering for edgy, though, given the short time to release
<Kamion> I'll talk to mdz when I next see him around
<pitti> Kamion: he's CCed to the bug as well, so he'll notice
<pitti> alright, thanks for your input!
<mvo> janimo: I don't quite understand the question, sorry
<janimo> mvo, if I want to set the deafult language do I need the whole support pack for it?
<janimo> or can it swicth only the exisitng translations
<janimo> .mo files and firefox etc
<janimo> without downaloding from the net that is
<mvo> janimo: no, the language-pack-$lang should be enough for that, basicly it checks locales -a
<pitti> mvo: if you have some minutes, shall we talk about g-cups-mgr?
<pitti> mvo: s/if/when/, just ping me
<janimo> mvo, so if I want as many firefox translations on the CD can I explictely seed them with no afferent support pack to bring them in and they'll work? that's would be nice
<janimo> since the support packs are >10Mb usually
<janimo> because of OO help and l10n
<janimo> and for the livecd I consider firefox/tbird more important to be translated
<pitti> dholbach: if tangerine-icon-theme-common is a mere splitout, it doesn't need a separate approval
<mvo> pitti: now is good
<pitti> dholbach: I'll take a quick look at the package anyway, though
<dholbach> pitti: it's in main already - i though it went through your hands
<pitti> mvo: ok, great
<dholbach> pitti: seems it bypassed you :)
<pitti> dholbach: I have an unapproved report in the queue, but nevermind; I'll complain if I find sth
<mvo> janimo: yeah, it should work
* dholbach hugs pitti
<janimo> mvo, thanks
* pitti hugs dholbach back
<mvo> pitti: it seems that we need to modify the current patch to not hide stuff that can't be used but make it insensitive
<mvo> but other than that I think it should be good
<mvo> we could even add a tooltip
<pitti> mvo: I'll take a look at it, it's on people?
<mvo> pitti: yes, http://people.ubuntu.com/~mvo/test/gnome-cups-manager 
<mvo> pitti: I can do the required modifications, we could even add a tooltip explaining why something was disabled
<pitti> mvo: that would rock
<infinity> dholbach: I punted it directly to main when I NEWed it, specificall because you said it was a split from other main stuff.
<dholbach> infinity: yeah - and thanks for that!
<dholbach> infinity: how do we go about universe libmysqlclient*?
<mvo> pitti: but I guess you want to give it some testing first?
<pitti> mvo: I'll test it now, but the critical work is done by the cups scripts anyway
<infinity> dholbach: change libmysqlclient* build-deps to libmysqlclient15-dev, upload.
<dholbach> infinity: do you want me to file bugs for the motu crew?
<infinity> dholbach: Not much more to it than that.  The APIs have always been painfully backward compatible.
* mvo nogs
* mvo nods
<pitti> mvo: so we just need to make sure that they get called appropriately
<dholbach> infinity: nice
<dholbach> i'll do that later
* pitti nogs mvo back :)
<infinity> dholbach: If I do it, it'll be next week, if MOTU can do it sooner, let 'em attack it.
<dholbach> ok
<ajmitch> dholbach: filing bugs will give us something to look at 
<pitti> infinity: tbird! php! samba print brekage! :)
<infinity> pitti: I take it you just read -changes and decided it was time for me to context switch? :)
<pitti> infinity: oh, actually not, I read mails ten minutes ago the last time (uh, I'm a slacker)
<pitti> infinity: and, it was just my usual bitching, nevermind :)
<infinity> pitti: I think samba will be the next one up, then tbird.  PHP may be post-RC, since it's the least important of the bunch (PHP "security" is a joke, and if the new upstream doesn't make it, we'll get over it)
<carlos> Riddell: hi, is there any easy fix for this from your side? https://launchpad.net/products/rosetta/+bug/38472
<Ubugtu> Malone bug 38472 in amarok "Korean instead of Kurdish imported into Rosetta" [Normal,Unconfirmed]  
<pitti> mvo: oioioi - I start g-c-m and I immediately get the 'will open port, the sky is falling' question dialog
<carlos> Riddell: or at least is there planned an upload with the 1.4 beta release?
<pitti> mvo: ...twice
<pitti> mvo: also, browsing_status returns 0 (i. e. disabled, not customized), but 'Detect LAN printers' is disabled in the menu
<pitti> mvo: ah, I think I might know what's going on - I enabled sharing, but disabled browsing. apparently, enabling sharing also enables browsing in g-c-m and disables the browsing option
<pitti> mvo: however, it should not be disabled if browsing is off
<pitti> mvo: actually, the two options are entirely independent from each other, so I'm not sure they should influence each other in the GUI
<mvo> pitti: that you get that twice looks like a bug :/ I got the mail from ivoks that they should be dependant
<mvo> no idea about it, I suspected something in the scripts
<pitti> mvo: well, if you enable sharing, enabling browsing make sense of course
<pitti> mvo: (for that reason 'Detect LAN printers' should be renamed to 'Detect and advertise LAN printers'
<pitti> mvo: it's already a bug that I get the question immediately after starting g-c-m
<pitti> mvo: I think we should keep it simple for now and keep it orthogonal
<mvo> even better
<pitti> mvo: i. e. I need to enable sharing to allow my flatmate to print, but windows doesn't speak cups browsing anyway, so I don't need to enable that
<Treenaks> pitti: it does understand IPP printing, just not browsing
<pitti> Treenaks: right, that's what I said :)
<Treenaks> pitti: just clarifying :)
<pitti> although cups browsing is just love and magic :)
<pitti> (one of the few things that actually work really well :) )
<pitti> infinity: wow, impressive list of initramfs fixes
<Riddell> carlos: I don't plan to upload 1.4 to dapper, I could delete the translation from the package though
<infinity> pitti: Given that I had to rewrite all of them today?  Yeah.
<infinity> pitti: Otherwise, not really.  There were more before the crash.
<carlos> Riddell: if you don't need to upload another version before dapper release, that's not needed
<pitti> mvo: so are you fine with making these changes? that would rock
<carlos> Riddell: so don't do an specific upload to fix it, but if you do another fix on that package, please, do it
<mvo> pitti: yeah, very much so. I like it a lot when things get simpler
<pitti> dholbach: lol @ t-i-theme-common debian/copyright: "It was downloaded from my harddisk."
<pitti> dholbach: I'm sure debian-legal would find that very funny :)
<_ion> pitti: :-)
<raphink> lol
<dholbach> pitti: I'll replace those with the bzr branches in the next upload :)
<raphink> pitti: got to talk to you today
<raphink> :)
<dholbach> and to be honest, I copied that from Ross  Burton's sound-juicer :)
<raphink> hi dholbach, mvo && pitti btw :)
<pitti> dholbach: there's certainly any upstream source for all these graphics?
<pitti> hi raphink 
<dholbach> pitti: in an bzr branch
<raphink> pitti: I'd like to ask you some questions about translations
<pitti> raphink: go ahead (I might lag a bit since I'm doing other things, but I'll answer)
<raphink> ok
<zul> heylo
<pitti> hi zul 
<raphink> pitti: how do you deal with desktop files that are translated with desktop.in + po ?
<raphink> pitti: these required an export form rosetta back to the package + rebuild
<raphink> and langpacks won't translate them
<pitti> raphink: not any more in dapper :)
<raphink> pitti: ?
<raphink> pitti: how so?
<pitti> raphink: https://wiki.ubuntu.com/LangpacksDesktopfiles
<raphink> well I'll take an example
<raphink> language-selector has been translated in many languages
<raphink> including the desktop file
<raphink> from the po
<pitti> raphink: gnome-menus & co do use gettext now to translate .desktop, .server, and .directory files
<raphink> yet the desktop file that is shipped in the end stil has only few languages
<pitti> raphink: right, we do not merge the rosetta translations back into the .desktop file, but they are used through direct gettext invocation
<raphink> pitti: not in KDE then
<mhz> iwj: ping
<pitti> raphink: https://wiki.ubuntu.com/LangpacksDesktopfilesKDE, not yet implemented :(
<raphink> argh
<raphink> is someone working on it?
<raphink> we need that for dapper
<pitti> raphink: for these you need to update the package's po files and reupload
<raphink> otherwise we'll gonna have most menu entries in english
<pitti> raphink: no chance to implement that for dapper
<raphink> pitti: so we have to export the pos from rosettta
<pitti> raphink: uploading packages with updated PO files is fine, but not implementing that spec
<raphink> and rebuild
<Riddell> raphink: I didn't have time to do it for dapper
<raphink> Riddell: ok
<raphink> then we have to do the export from rosetta + rebuild thingy
<Riddell> most .desktop files are translated upstream, at least in KDE
<raphink> for adept, language-selector, etc.
<raphink> we should create a wiki page listing all the packages that need this
<raphink> so it can be done before release
<raphink> I don't want to ship dapper in french with english menus
<raphink> when people have worked hard to have all the desktop translated on rosetta
<raphink> this would be too bad
<raphink> pitti: I've tried this technique with language-selector
<raphink> but funnily enough it didn't rebuild the desktop files when I built the package
<pitti> raphink: right; I don't see a problem with manual uploads, that's what we did in earlier releases, too
<raphink> I had to run intltool manually before building
<pitti> raphink: hm, then it doesn't use intltool-merge, or at least not in the right way
<raphink> well the makefile contains
<pitti> raphink: usually you have an untranslated .desktop.in and run intltool-merge
<raphink> %.desktop: %.desktop.in
<raphink>         intltool-merge -d ../po $< $@
<raphink> there's no %.desktop.in rule though
<pitti> that should already be present
<raphink> yes
<raphink> it is
<pitti> it's the 'source' file
<raphink> should that work?
<pitti> actually yes
<raphink> hmm it doesn't
<raphink> when I run intltool-merge manually it works
<raphink> but not when I build
<pitti> taht's a package bug then
<_ion> Maybe nothing in the Makefile depends on the .desktop files.
<raphink> maybe it's a problem with rules
<pitti> raphink: does the package already ship a .desktop file?
<raphink> well it ships this one
<pitti> raphink: if so, and its date is newer than the desktop.in file, the rule will never be executed
<raphink> but then the desktop file should be rebuilt
<raphink> ah right
<raphink> pitti: ic
<raphink> so actually the desktop file should be cleaned in rules, right?
<pitti> raphink: it looks wrong to ship a .desktop file in the upstream orig.tar.gz, and even more so in the diff.gz
<raphink> or there should be clean rule in the Makefile
<raphink> there's no orig.tar.gz
<raphink> ;)
<pitti> raphink: right, clean it in debian/rules clean
<raphink> it's a native debian package
<pitti> ah
<pitti> raphink: remove it from the package and reupload
<raphink> so I could well do it in the Makefile
<raphink> ok
<raphink> well i'll remove from the pakage and rebuild locally
<pitti> yes, fixing the distclean rule would be nice as well
<raphink> to test first ;)
<mvo> pitti: how does enable_sharing detects if the cupds.conf was changed? I try to test my changes right now
<pitti> raphink: so, fixing that and updating the po files warrants an upload :)
<raphink> ok
<pitti> mvo: it calls sharing_status, which in turn does a few checks on the config files
* neuralis pokes mako
<pitti> mvo: i. e. to make it return with 2 (customized), just remove/comment out the respective include directive in cupsd.conf
<raphink> pitti: so should I fix it in the Makefile or in debian/rules in your opinion?
<pitti> raphink: fixing in Makefile (clean rule) sounds better to me
<raphink> ok
<raphink> :)
<raphink> I'll do that
<raphink> :)
<pitti> debian/rules should just fix errors in upstream's build system, but if we can fix the latter, so much the better
<mako> neuralis: hey there
<mako> neuralis: CC meeting going, or about to
<raphink> yes pitti
<raphink> I'll try that
<mvo> pitti: I uploaded a new version (ubuntu7.2) to people
<pitti> mvo: yay, I'll try that
<mvo> pitti: I'm building amd64 debs just now
<raphink> :s
<pitti> mvo: I'm already building locally here, don't worry
<mvo> pitti: ok
<Kagou> hi
<pitti> mvo: now, that works just marvellous here
<pitti> hi Kagou 
<pitti> mvo: if you are at it, maybe you can also change the 'Detect LAN printers' string to 'Detect/Advertise'?
<pitti> also, maybe some native English speaker has a better suggestion?
<Kagou> hi pitti :) did you seen the normal/minor/high/minor bug on cups ;)
<pitti> Kagou: yes, a mess :/
<pitti> Kagou: I hope that it'll be solved soon, that bug sucks
<pitti> Kagou: what, is it minor again?
<Kagou> pitti, yes
<pitti> grrr
<Kagou> cups dev consider that users have to use postcript driver on windows client instead of printers drivers
<pitti> but as long as windows doesn't come with proper ps drivers, that won't happen
<pitti> (I really hate windows for not doing that, but we can't help that)
<Kagou> indeed
<pitti> allowing my flatmates to print to my printer from their XP boxes is a real adventure
<pitti> ("Oh, where the heck did I toss the CD shipped with the printer?", given that I never bother to waste just even a look at accompanying CDs)
<Kagou> :)
<pitti> mdke: ping?
<mvo> pitti: right, will do
<pitti> mvo: let's ask mdke for ui freeze breakage
<mvo> pitti: string is changed
<ajmitch> infinity: could you send those build logs to myself or the motu list please?
<pitti> janimo: . o O { looking at the packaging of xfce stuff is a real joy! }
<janimo> pitti,I wonder  you really mean it (cdbs) or not mean it (svn snapshot ugliness) ;)
<janimo> I hope xfce.mk though :)
<pitti> janimo: no, that was sincere, I refered to packaging. reading these very small, clean, and consistent diff.gz's is nice
<ajmitch> infinity: that is, if they weren't on that fujitsu drive. 
<janimo> pitti, phew. Indeed cdbs rules for xfce as I found during dapper
<pitti> ajmitch: I wonder what 'Fujitsu' really means :)
<ajmitch> pitti: it makes me wonder.. :)
* janimo meant rules as a verb above
<pitti> "Who is General Failure? And why the hell is he reading my hard disk?"
<sivang> ha ha ha
* sivang rotfls
* ajmitch doesn't want to think about the death rattle coming from his western digital drive at the moment
* pitti pats his daily automatic network bacup
<pitti> backup, too
<sivang> pitti: over the hosting company, ofcourse :)
<ajmitch> I recently switched to other drives, in a RAID setup :)
<pitti> yes, 800 km should be enough
<pitti> if there's an event that kills both my server and my home, I have other things to worry about
<pitti> or none at all any more
<sivang> pitti: indeed :)
<ajmitch> heh
<ajmitch> time for sleep, night all
<jsgotangco> night ajmitch
<sivang> night ajmitch 
<ogra> pitti, you mean like a big magnetic storm that overcasts germany
<pitti> ogra: that'll throw us back to stone age anyway :)
<pitti> janimo: can you please quickly explain to me how xfce4-mount-plugin works?
<janimo> pitti, I think it only shows what's in fstab
<pitti> janimo: does it use gksudo, or only mounts fstab user drives?
<janimo> pitti, not used it much I admit
<pitti> janimo: so, no setuid magic?
<janimo> oh, none of that I am almost sure
* janimo checks
<ogra> pitti, arent we there yet anyway ? i mean silicon is some kind of stone ;)
<pitti> I don't see a postinst, and no suid programs in the .deb
<janimo> pitti, no suid binary
<pitti> janimo: right, indeed; so I assume it can only handle fstab stuff
<janimo> I _think_ it's just a big graphical way of showing free space on various partoitions
<janimo> yes
<pitti> janimo: btw, does xfce handle usb hard disks and the like?
<pitti> + This plugin for Xfce displays a list of the various devices available, giving
<pitti> + the opportunity to mount/umount them.
<janimo> pitti, thunar talks to HAL so modulo bugs it should
<pitti> janimo: our hal can't mount drives, I disabled that
<janimo> pitti, ok. Feel free to set this plugin aside for now, I'll ping if I review it more thorougly. I just saw it is not setuid so supposed it cannot do harm
<pitti> janimo: so, it might be useless enough to not put it in main, maybe
<janimo> pitti, oh then thunar cannot either
<janimo> pitti, agreed.
<pitti> janimo: I'm fine with the plugin security-wise, I just question how useful it is
<janimo> screenshooter is the nice one which may be in main as users need it not just mount point aware geeks :)
<janimo> pitti, yeah I don;t think it's of much use, but looks nice. At a click you see the space occupied and all mounpoints.  A df GUI :)
<pitti> ok, that's nice
<pitti> well, and even an fstab mount interface is at least good for CD-ROMs
<janimo> like the disks tool in g-s-t somewhat
<pitti> janimo: xfburn works reasonably for you?
<janimo> pitti, well if no security concern and it's not much trouble, please allow it in main then
<janimo> pitti, yep, better than graveman
<pitti> janimo: yes, I approved all the plugins, xfburn is the last xfce one
<janimo> but only for the ismple tasks it is advertised for
<janimo> I just burn .isos with it and it did not crash unlike graveman
<janimo> no bugs at all upstream, people seem content and silent about it
<janimo> although complain about lack of some features (audiocd,dvd etc)
<pitti> janimo: reload the queue :)
<pitti> janimo: s/queue/page and look at the queue/
* janimo hugs pitti
<janimo> thanks
<pitti> no problem
<seb128> Mithrandir: french keyboard and mac? maybe you can ping hub when he's around. I think that probably most people on #ubuntu-fr doesn't speak english
<iwj> mhz: pong
<Mithrandir> seb128: 'k
<seb128> Mithrandir: other way look on launchpad bugs about that, there is a french guy who is active on the topic, you can probably drop him some comments or mails about it
<seb128> he would probably be happy to help sorting that
<pitti> Keybuk, Kamion: bzrtools is fine for me packaging-wise (but not really necessary to have in main IMHO); celementtree has no reverse dependencies, but is fine; paramiko is fine
<Kamion> pitti: bzrtools is kind of nice for push at least
<Kamion> although you can rsync, sure
<Kamion> oh, bzr shelve
<pitti> Kagou: I sent another plea to http://www.cups.org/str.php?L1667
<Kamion> how can we not have that :-)
<pitti> heh, true
<pitti> and it's tiny
<mvo> pitti: can you please have a look at bug #42002
<Ubugtu> Malone bug 42002 in language-support-ko "Korean fonts are so ugly." [Normal,Confirmed]  http://launchpad.net/bugs/42002
<Kamion> dunno, it probably belongs in supported rather than ship anyway
<mhz> iwj: I have translated a firefox index page, read your wiki page about it..but I understood like 5% of it, sorry. Any other way we could just implement my version of index page (into spanish, Chile)
<pitti> mvo: oh, so we should throw ttf-baekmuk out of *-desktop and replace it with ttf-allee?
<Kagou> pitti, totally agree with your comment. I don't know how mike can considere that's a minor bug when we see users comments/reactions.
<mvo> pitti: maybe we should just add it
<pitti> mvo: I replied to the bug
<mvo> pitti: thanks
<pitti> mvo: should be fine, but I want a confirmation of what we need to do, and which package is better
<mvo> pitti: ok
<CarlFK> /jion #ubuntu-kernel
<CarlFK> huh?
<CarlFK> \join #ubuntu-kernel
<thom> that doesn't work either :-)
<ivoks> pitti: ping
<ivoks> pitti: just a quick note; upstream cups doesn't have a bug with windows IPP printing
<ivoks> pitti: only cups packages...
<ivoks> i'll take a look at it today
<mdke> pitti: hi
<pitti> mdke: I think I already asked you some time ago, but would you and the doc-team be fine with adding an "Enable printer sharing" menu item to gnome-cups-manager?
<Tetralet> Kamion: ping
<pitti> mdke: and renaming "Detect LAN printers" to "Detect/Advertise LAN printers"?
<mdke> pitti: sure, np
<pitti> mdke: great
<pitti> mvo: ^ :)
<mdke> our docs on printing are woefully small. dunno about upstream's
<pitti> mvo: so, if Kamion is fine with it as well, let's do it ASAP
<janimo> pitti, I was wondering why g-c-m has two patches which could be one for the gksudo line changing?
<Kamion> Tetralet: hi
<Tetralet> Kamion: There is a serious bug in Debian-Installer Traditional Chinese translation.
<Kamion> pitti: fine by me if the doc team is and if translations can be updated
<pitti> janimo: probably just aggregated cruft over time
<pitti> Kamion: yes, uses PO files and gettext
<iwj> mhz: Err, mdke usually handles that side of it.  I don't know exactly what has to happen to the translated page to get it into the right places.
<janimo> pitti, ok. Just as the different diff and patch suffixes in the pathes dir :)
<Tetralet> Kamion: It is the patch: http://debian.luna.com.tw/debian-installer-zh_TW.diff
<pitti> Kamion: and the previous string was already ubuntu specific
<mdke> mhyeah, send it to me by email
<Kamion> pitti: did it have any existing translations?
<pitti> I need to run out for a bit, back in ~ 1.5 hours
<iwj> mhz: What's the locale for this ?  Does firefox already have a separate language setup (aka xpi) for that locale ?
<mdke> iwj: he's not in the chan
<pitti> Kamion: German (from me), I'll check the others
<mdke> just realised when my tab complete didn't work
<iwj> Oh, so he isn't.
<mdke> i'll mail him
<iwj> Thanks.
<Kamion> Tetralet: OK; has that fix been committed upstream?
<Tetralet> Kamion: yes
<mdke> iwj: looks like there is no ff localisation for it anyhow
<Kamion> Tetralet: ok, I'll upload that now. Can you explain the seriousness of it to me?
<iwj> mdke: Ahm.
<Tetralet> Kamion: An mis-translation. s/password/user's fullname/g
<Kamion> heh, ok
<iwj> I don't think I want to be inventing the xpi-less ff localisation thing in m-f-l-all at this stage.
<Kamion> uploaded, thanks
<mdke> iwj: heh
<Tetralet> Kamion: thanks!!
<ogra> seb128, what did change in the last gnome-session upload ? seems the power management behavior changed: https://lists.ubuntu.com/archives/edubuntu-devel/2006-May/001409.html
<seb128> ogra: using gnome-power-manager instead of gdm
<ogra> seems its not covered by the test if a user is logged in locally or remotely
<seb128> there never was a test or a case for that
<seb128> is was asking to gdm before
<seb128> now it's asking to gnome-power-manager
<ogra> meh, so its a g-p-m bug ?
* Kamion promotes celementtree, paramiko, bzr to main
<Mithrandir> Kamion: not bzrtools too?
<Kamion> oh yeah, that too
<seb128> ogra: where does the dbus session bus is running
<kgoetz> hi all. are Scot james rembrant or seveas about?
<ogra> seb128, on the server indeed, as everything
<Mithrandir> kgoetz: Scott's Keybuk 
<kgoetz> Mithrandir: thanks. Keybuk ping
<seb128> ogra: here you go
<seb128> ogra: it uses the dbus bus to ask the actions available and to do them
<ogra> bah
<kgoetz> Mithrandir: is there a good time to find him? i need to ask about some readahead data i got for him
<Mithrandir> kgoetz: he's probably around; he logs off when he's not here.
<Mithrandir> kgoetz: or drop him a mail.
<kgoetz> Mithrandir: hm. thanks. i'll attach teh data to the bug and hope hes ok with it in a tar (theres half a dozen files). ty
<ogra> mjg59_, any chance g-p-m could check if LTSP_CLIENT is set in the environment, to not allow client users to hibernate the server ?
<dieman> rock
<dieman> my boss got the funding worked out so I can come to the next summit
<Mithrandir> dieman: next as in Paris?
<dieman> yah
<Mithrandir> nice
<dieman> yah
<dieman> i try to get to a conf/meeting/etc at least once every two years
* Kamion finishes moving cdimage to bzr
<Kamion> http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ FWIW
<Kamion> yay no more insane permissions conflicts
* ogra bzr gets
<infinity> Kamion: \o/
<infinity> Kamion: How painful was the conversion?  lamont and I still need to move the buildd stuff from baz.
<Kamion> straightforward - 'bzr baz-import-branch cdimage colin.watson@canonical.com--2005/cdimage--mainline--0
<Kamion> '
<infinity> Oh, cool.
<Kamion> the difficult bit was the subsidiary branches based off baz imports
<Kamion> but use bzr/bzrtools 0.8 and you'll be fine
<janimo> do you know btw if the supermirror already uses bzr instead of baz?
<infinity> I expect we won't care much about insane branch history and such anyway.  One trunk should be good enough.
<Kamion> just import them all in turn
<Kamion> into the same target directory
<Kamion> baz-import-branch should connect them up if you do that
* thom [hearts]  bzr shelve
* dholbach hands thom a 
<jsgotangco> lol
<jsgotangco> that's so hello kitty-ish
<KaiL> mjg59_, for the Laptop-Whitelist: Asus M2N.. where to find the $model?
<kgoetz> omg. whos behind the live cd installer? it Just Worked like a charm! thats amazing
<Kamion> kgoetz: thanks, glad it worked :)
<kgoetz> Kamion: its awsome :)
<KaiL> mjg59_, I guess "system.product"? That's "M2N 1.0"
<dieman> shoot
<dieman> the hotel just ran out of rooms
<dieman> it looks
<seb128> mdke: around ?
<sladen> KaiL: can you file that against:  https://launchpad.net/bugs/44781  where you'll also find the pointers
<Ubugtu> Malone bug 44781 in acpi-support "Suspend works on Laptop XYZ (white-list requests)" [Normal,Confirmed]  
<mdke> seb128: yes
<sladen> ogra: hahhaa.  Does suspend work aswell aswell on the server from an LTSP client.
<ogra> sladen, https://lists.ubuntu.com/archives/edubuntu-devel/2006-May/001409.html
<sladen> ogra: I think it might be easier to just change pmi to check and reply False to  pmi query ...
<ogra> hmm, does pmi have the user env during that query ? 
<kgoetz> i had no luck asking on -bugs, so i'm trying here: where should i file a bug on no en_AU dictionaries on a clean install?
<sladen> ogra: mmm, probably.  No reason why it shouldn't, I don't think
<sladen> ogra: is it just hiding the Hibernate option, or do you want to actually stop it happening.  If the later, then you're going to have to do it in pmi anyway, other somebody can just grab a terminal and do   LTSP_CLIENT='' pmi action hibernate
<ogra> hmm
<janimo> ogra: did you talk to ltsp/xfce guy since yesterday?
<ogra> nope
<janimo> ogra: I'll try to talk to him then, thanks
<ogra> janimo, but seb128 just told me that gnome-session is querying gdm to get the info if it should show shutdown options, i guess xfce-session should just steal the code there
<seb128> ogra: not, it's using gnome-power-manager now I said
<ogra> seb128, even for shutdown/reboot ? 
<ogra> janimo, so grab the code before that change then ;)
<janimo> seb128: so what is it asking  whether is remote/local login or more generally if it's allowed or not to reboot
<seb128> halt
<seb128> not reboot
<ogra> (unless you use g-p-m in xubuntu)
<janimo> unfortunately no g-p-m in xubuntu
<seb128> janimo: who is asking that?
<seb128> ah
<seb128> halt_supported      = gdm_supports_logout_action (GDM_LOGOUT_ACTION_SHUTDOWN);
<seb128> reboot_supported    = gdm_supports_logout_action (GDM_LOGOUT_ACTION_REBOOT);
<seb128> there is a bug here ;)
<ogra> seb128, ltsp users have a similar prob to the abve with xubuntu, the logout dialog shows shutdown/reboot by default and they can stop the server
<seb128> because the action is gpm_dbus_interaction ("Shutdown");
<janimo> ogra: although xfce has a kioisk feature by which the admin can just say no shutdown/reboot
<seb128> ogra: xubuntu uses gnome-session?
<janimo> in a RC file. it may be a simpler solution
<ogra> seb128, nope, xfce-session
<janimo> seb128: heh no :)
<seb128> so nothing to do with that
<Kamion> kgoetz: language-support-en, probably
<ogra> seb128, but xfce-session is missing the feature gnome-session has ;)
<seb128> sure, it's supposed to be less powerfull since it's without GNOME :p
<ogra> seb128, so my proposal was to grab the gdm querying code from there to make xfce session behave like gnome-session
<janimo> ogra,seb128 let's start again because it's getting confusing:
<janimo> 1)gnome-session asks gdm whether user can shutdown.true or false?
<ogra> it used to, yes
<janimo> true or false? :)
<seb128> it still does apparently, but that's a bug
<ogra> that did change recently, so you need to look at older code
<seb128> halt_supported      = gdm_supports_logout_action (GDM_LOGOUT_ACTION_SHUTDOWN);
<seb128> I supposed it should be changed to something like
<seb128> suspend_supported   = gpm_dbus_interaction ("CanSuspend");
<seb128> supposing that g-p-m has a CanHalt
<ogra> janimo, so you need the code from gnome-session seb128 posted above
<janimo> ogra, anyway xfce kiosk settings can be used and they are selfcontained only depend on xfce4-session running
<ogra> <seb128> halt_supported      = gdm_supports_logout_action (GDM_LOGOUT_ACTION_SHUTDOWN);
<ogra> <seb128> reboot_supported    = gdm_supports_logout_action (GDM_LOGOUT_ACTION_REBOOT);
<janimo> ogra: what if your man does not run gdm?
<ogra> you get no response then i guess
<infinity> Does all this magic use libpam-foreground these days?... If so, I'd think that LTSP clients shouldn't be soncidered "foreground" users.
<sladen> infinity: yup.
<seb128> you don't have reboot or shutdown options without gdm
<infinity> considered, too.
<ogra> infinity, since its used through g-p-m ...
<seb128> speaking about pam
<seb128> who does pam here? I've a bug for him
<sladen> infinity: they're getting their priviliges from somewhere...
<Kamion> seb128: that depends, I occasionally do
<seb128> bug #41923
<Ubugtu> Malone bug 41923 in gdm "Wrong password accepted in login window" [Unknown,Rejected]  http://launchpad.net/bugs/41923
<Kamion> but only really insofar as it affects ssh
<infinity> seb128: jbailey's working on a PAM upload right now.
<seb128> basically that's "correct_passwork<non-utf-8-char>" is accepted
<seb128> password
<seb128> according to gdm upstream that's a pam issue and not a gdm one
<seb128> but I'm not sure on how to figure if that's really pam
<ogra> seb128, does the new gdm-ssh handler use ssh -X for connections like we do in ltsp ? 
<seb128> ogra: "ssh -A -X -T -n "$TARGETHOST" /etc/X11/Xsession"
<seb128> ogra: it does that
<ogra> cool 1!!
<ogra> being able to set -C would be needed additionally, but then we can switch ltsp to gdm in egdy, yay !
<janimo> seb128: on first login froom gdm is the Default session being used instead of /usr/share/xsessions/gnome.desktop?
<seb128> ] $ grep DefaultSession /etc/gdm/gdm.conf
<seb128> DefaultSession=default.desktop
<seb128> janimo: correct
<janimo> yup
<seb128> why?
<janimo> seb128: the same happens for xfce,
<janimo> and I want to be sure the xfce.desktop is started first
<janimo> since it startx xscreensaver and other bits, while default does not
<janimo> only after user explcitely selects that entry in the gdm login screen
<janimo> otherwise it's a fallback to x-session-manager which calls barebone xfce4-session
<janimo> seb128: so is gnome.desktop set to default or only if a user choses it?
<ogra> so just set it in your gdm-cdd.conf ;)
<ogra> thast what its for
<seb128> janimo: default.desktop is the default
<janimo> ogra: I know but want to make sure there's no cleaner way
<janimo> as gnome does not set it but still runs fine
<janimo> seb128: yes, but it still starts gnome in a default ubuntu install no?
<seb128> gnome.desktop is used if you pick gnome
<seb128> right, you don't expect it to start xfce on Ubuntu by default?
<janimo> is it not different if run from default or from gnome.desktop? I am only interested in stock instal, first login
<seb128> what else would you start by default on Ubuntu
<seb128> I think I don't get the question
<janimo> seb128: so, on a stock ubuntu/gnome install, first login:
<janimo> user just enters user/pass and is taken to gnome
<janimo> default.desktop was used not gnome.desktop right?
<seb128> no, it's taken to xfce
<janimo> seb128: stock ubuntu/gnome install as I said
<seb128> I've no idea
<seb128> GNOME is started
<janimo> no xfce in the picture
<seb128> I didn't try to figure how
<seb128> janimo: that was irony
<seb128> asking if GNOME is started by default on Ubuntu seems a joke
<seb128> I should have replied "no, windows XP is started" ;)
<seb128> it would have been clear that way :p
<janimo> seb128: oh boy
<ogra> :)
<janimo> I was explciit since you said you dont;understand the question
<seb128> yeah, I got it now
<janimo> so plainly. On a default ubuntu.gnome install how is a gnome.desktop session diffenent from a default.desktop one
<seb128> <seb128> I didn't try to figure how
<janimo> because default.desktop in xubuntu is different from xfce.desktop. The former only starts the session manager, the latter a bash script which does other stuff as well
<janimo> seb128: ok. thanks
<seb128> np
<seb128> I don't get what you are doing
<seb128> ship a gdm-cdd.conf
<ogra> seb128, he wants to override the defaul
<ogra> t
<seb128> and use DefaultSession=xfce.desktop
<ogra> exactly
<seb128> default.desktop should not be shipped by xubuntu
<seb128> it's shipped by gdm
<seb128> that's a builtin session
<seb128> which is supposed to do what your box default too
<seb128> (ie: like a startx)
<seb128> if you want xfce, why not using xfce.desktop?
<infinity> seb128: Just tested here with a very (very) barebones PAM C client.  Doesn't exhibit the broken behaviour GDM does.
<infinity> seb128: I expect GDM is stripping chars or something equally vile.
<seb128> infinity: hum, k
<seb128> infinity: thank you, I'll have a look on what gdm does exactly (but latter)
<infinity> seb128: For reference, "poppassd" is about the slimmest PAM client I can think of off the top of my head, without writing an even smaller (and more useless) one.
<seb128> infinity: ok, thank you
<infinity> seb128: Other than the printing of response banners, it's just a PAM I/O client.  Useful for testing (you can just run it on the command line, no need to telnet to it)
<janimo> seb128: of course not shipping default.desktop but modifying the entry in gdm-cdd.conf to Default=xfce4.desktop
<janimo> Since if I leave the default even if it startx xfce-session it's not quite the same.
<janimo> s/startx/starts/
<seb128> what does it do if you "start"?
<dappered> i'm installing flight 6 onto a laptop now and as part of the process resizing a 60g partition. resize2fs has been running for around an hour now and although the HDD LED is on, i'm starting to think that it's failed. the process isn't sleeping however: 11919 ? R 1:44 resize2fs /dev/hda1 44992M. is this a known problem with the partitioner?
<jsgotangco> goodnight
<Kamion> dappered: it's a known problem that it doesn't give feedback
<janimo> seb128: not sure I understand? what does it do if I just leave the default session?
<janimo> it starts xfce4-session and that's all since it falls back to it via x-session-manager
<Kamion> dappered: but on a partition that size on a slow laptop disk, it's possible that it is in fact still running
<dappered> Kamion: hehe right ok. if you suggest that an hour running isn't unreasonable, i'll be patient.
<dieman> heh suck
<Kamion> you can 'strace -p 11919' to check
<Kamion> ctrl-c when you're bored
<dappered> sure ok.
<dieman> i can't be in the same hotel now, they ran out of rooms -- luckily theres a hotel about .5 mi away
<Kamion> I'm not sure I'd go so far as to say it isn't unreasonable :)
<seb128> janimo: forget about that, I think I just don't get what is your issue with using xfce4.desktop ;)
<seb128> or why you ask about default.desktop is xfce4.desktop works fine
<dappered> Kamion: that's looking positive, it's still active.
<ogra> seb128, he thinks the way through gdm-cdd.conf is uncler
<janimo> seb128: because xfce4.desktop must be explicitly selected by the user.
<ogra> *unclean
<janimo> the default is default.desktop but it does not start all that xfce4.desktop starts
<dappered> i realise this is also a boring topic, but are the fglrx drivers known to work in dapper on a 2.6.16* kernel?
<janimo> so even if it loooks like 'ok, xfce is started', some things are not (xscreensaver)
<seb128> janimo: just set DefaultSession=xfce4.desktop to gdm-cdd.conf
<janimo> seb128: yes, thats' what I did
<seb128> ok, so we are all good ;)
<ogra> :)
<janimo> except we still don;'t know how gnome gets away with just using default, and if default works why is there a need for gnome.desktop :)
<janimo> but that;s your problem I guess ;)
<seb128> starting gnome == running gnome-session basically
<seb128> gnome-session doesn't everything for you
<seb128> does everything
<janimo> seb128: right
<seb128> an default.desktop leads to have gnome-session started
<seb128> which works just fine ;)
<janimo> whereas startxfce4 is a shell wrapper around xfce4-session and other bits and is preferred over bare xfce4-session
<janimo> so ok 
<janimo> ok we're all fine then and only a bit confused :)
<ogra> but thats a bug in xfce-session then
<infinity> dappered: We're not shipping a 2.6.16 kernel, so "I don't know".
<seb128> janimo: looks like ;)
<janimo> ogra: nope, why hardcode xscreensaver starting in xfce4-session? it's better to have a startxfce4 script
<ogra> if it would behave like gnome-session, all were fine ;)
<infinity> dappered: That's also not a particularly relevant question for here.
<dappered> infinity: right, cheers.
<janimo> startxfce4 sets xmodmap, xresources etc
<janimo> which I _think_ gnome session just calls from C
<seb128> exact
<wasabi__> Hey. So. Anybody still interesting in an ARM port?
<infinity> wasabi__: Yes, though not necessarily RIGHT NOW. :)
<wasabi__> I'm going to start compiling some packages for ARM, and see if I can get ubuntu running on my n770.
<ogra> wasabi__, if you make it fit on my ipaq :)
<dappered> wasabi__: would be a bit of a squeeze on an n770 ;)
<wasabi__> Guess I'll just set up my own repository and start doing binary uploads.
<wasabi__> dappered: Going to LVM it to my MMC.
<wasabi__> Or split the partitions.
<dappered> wasabi__: nice.. i'd love to see an ARM port personally.
<infinity> wasabi__: It was meant to happen for dapper, IIRC, but it would seem not all the pieces fell into place.
<wasabi__> Yeah. Little demand, too.
<infinity> wasabi__: Which irritates me to no end, as I was looking forward to having some fast ARM gear in the DC.
* ogra still waits for someone to do a mips port to get his old indigo2 running ubuntu :)
<wasabi__> So, you've done this before I assume. Is qemu a resonable path to take?
<wasabi__> With nfsroot, etc.
<wasabi__> Or should I try to cross compile .debs
<wasabi__> I'm fond of the qemu route because I don't have to do much work. ;)
<infinity> wasabi__: I'd just bootstrap it from debian/arm.
<wasabi__> Yeah, that's hte plan.
<wasabi__> My ARM device is too slow to compile on, though.
<infinity> (Which is precisely what we'd do if we were doing an "official" port)
<infinity> What's in the N770?
<wasabi__> 133mhz omap I believe.
<infinity> Oh, ouch.
<wasabi__> And 64 mb of ram.
<ogra> wasabi__, the guys from handhelds.org used to use a distcc cluster on a bunch of ipaqs 
<wasabi__> Heh.
<wasabi__> ogra: HAHAHA
<infinity> I was going to say I'd consider anything >= a 200MHz StrongARM to be more than enough beef to bootstrap a port.
<wasabi__> Well, qemu might  well suffice.
<ogra> so just get a handfull of n770s  ;)
<wasabi__> Haven't gotten into it yet though.
<wasabi__> I did get a kernel booted in it.
<sladen> wasabi__: 250Mhz chip in the 770
<wasabi__> So, my dual core HT 4ghz p4 + qemu may well work. :0
<wasabi__> 250?
<wasabi__> hmm
<infinity> That's enough oomph for native building, IMO.
<infinity> The 64MB of RAM will be a bit harsh for C++ stuff, but should be fine for C.
<infinity> (Who wants QT/KDE anyway?)
<wasabi__> Heh.
<wasabi__> Under Features it lists "java"
<wasabi__> wonder what that means
<wasabi__> (proc/cpuinfo)
<dappered> ubuntu on this would be a bit of a lark: http://linuxdevices.com/articles/AT9112527929.html
<dappered> lovely little ARM9 machine, and cheap 2.
<ogra> wasabi__, well, thats needed for the openoffice port ;)
<wasabi__> I wouldn't want to run OO on this.
<wasabi__> abiword runs fine though
<ogra> heh
<ogra> i wasnt serious
<wasabi__> Heh.
<sladen> wasabi__: the Netbook/LX project built a complete desktop of Abiword/Gnumeric/Email/Firefox... all rebranded and fitted into 64MB of flash
<wasabi__> Wow.
<wasabi__> Yeah, the n770 has installs for abiword and gnumeric already. They run fine.
<sladen> wasabi__: unfortunately I killed the screen on mine just before the Sydney conference
<wasabi__> I'm just tired of the underlying distro.
<wasabi__> Files in weird places. Can't just install stuff in /
<dappered> sladen: that's what's needed to compete with M$'s office on WinCE.
<sladen> dappered: go and find <wookey> on IRC for more details
<dappered> sladen: cheers
<sladen> that aside, it still boots and I can SSH to it as a 400Mhz + 256MB RAM ARM machine
<iwj> seb128: That ubuntu-docs is in dapper now (well, as soon as it builds) and I'm following up with new {edu,k,x}ubuntu-*.
<seb128> iwj: ah, nice
<dappered> out bbl
<ogra> iwj, ?
<iwj> ogra: To support epiphany for DapperFirefoxStartPageTranslaction (and to add the `ku' locale).
<ogra> iwj, ah, zhanks
<iwj> seb128: Those should be there shortly.  Can you check that all 3 alternatives work with your new epiphany before you upload it ?
<seb128> iwj: I'll do that and let you know
<iwj> Right, thanks.
<iwj> The packages are ubuntu-docs 6.05.3, edubuntu-artwork 0.1.0-24, kubuntu-docs 6.06-7, xubuntu-docs 6.05.2.
<iwj> Err, so that's four alternatives, sorry.
<Burgwork> wasabi__, take a peak at the maemo roadmap. They are planning full support for package management for 2.0
<wasabi__> Sure. Still would rather just run Ubuntu.
<infinity> mjg59_: hal is FTBFS all over.  Your patch doesn't apply.
<mjg59_> infinity: Crap. It damn well did here.
* mjg59_ shoots cdbs
<infinity> mjg59_: You probably had it applied in the diff.gz, so the patch system can't apply it again.
<infinity> (At a guess)
* wasabi__ shoots NFS.
<wasabi__> I have completely forgotten how to set this up.
<mjg59_> infinity: Not with this build-system...
<mjg59_> Crap. cdbs-edit-patch being dumb.
<wasabi__> mount: RPC: Program not registered     
* wasabi__ kicks the tires.
<ogra> wasabi__, portmap
<wasabi__> I know. It's running. Looks fine.
<wasabi__> Doesn't have -i 127.0.0.1
<wasabi__> Yeah, I'm off to a good start so far.
<mvo> Mithrandir: is there a way to detect if casper is runing (or if the app is runing under casper)?
<desrt> portmap's -i option is excessively brain damaged
<ogra> desrt, it was necessary when we shipped with fam
<desrt> right.. but instead of -i it should have like --localhost-only
<desrt> since that's the only way that it's even vaguely useful
<ogra> you probably want to bind portmap to eth2 or something 
<desrt> (multiple -i options do not work and binding to an external interface prevents hosts on the local machine from working)
<desrt> s/hosts/clients/
<desrt> anyway.. it has tcpwrappers which lets me do a vague approximation of what i was aiming for :)
<ogra> i could imagine people running an ltsp server would like to bind portmap only to the thin client interface
<desrt> ya.  i say.
<desrt> no love :(
<ogra> and not open it for the rest of the world
<desrt> for nfs, right?
<desrt> anyway.. that's the entire point.  it won't work
<desrt> if you use -i to bind to an internal interface then the nfs/mountd servers can't register themselves because portmap then refuses to accept connections from 127.0.0.1
<ogra> hmm, i actually never tried that
<desrt> ogra; i tried it and, as a result, developed my negative opinion about the -i option :)
<ogra> its nothing to change now, but i'll put on my edgy totdo to look into it :)
<desrt> it's gonna be pretty tough
<wasabi__> Anyways. What's wrong with my RPC? :)
<desrt> if you bind to all interfaces or only a single interface then you only have a single socke
<ogra> changing a commandline option of portmap ? 
<wasabi__> The error makes me think portmap isn't listening on *.*
<desrt> if you bind to 2 interfaces then you have 2 separate sockets
<desrt> the entire mainloop of the program needs to change to deal with the 2 separate listeners (since i'm fairly sure it's probably fairly special because of only having to deal with 1)
<desrt> wasabi__; you removed the -i option and restarted?
<wasabi__> Yup
<desrt> wasabi__; did you restart all your portmap-using servers?
<wasabi__> Believe so. nfs-common, nfs-kernel-server
<desrt> check netstat -an | grep 111
<desrt> see if portmap is really *.*
<wasabi__> tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN
<desrt> er.. *.111 actually
<desrt> did you setup tcpwrappers?
<wasabi__> Well, I made sure it wasn't set up.
<ogra> or firewall rules :)
<wasabi__> no firewall
<desrt> modify /etc/hosts.allow
<desrt> and put
<wasabi__> I put ALL: ALL in it
<desrt> portmap: 1.2.3.
<desrt> or whatever
* desrt raises eyebrow
<wasabi__> local lan, private network.
<desrt> did you restart tcpd
<desrt> (chuckle)
<wasabi__> heh. don't even have such a thing.
<desrt> well, you do.
<desrt> tcpd is what takes care of authenticating against hosts.{allow,deny}
<desrt> it's just really poorly named which causes people to think that it's a server or something
<desrt> on the networks/security course i just took there was a question "give an example of a server that doesn't listen on tcp or udp." and the answer in the answer key was "tcpd".  oi.
<_ion> "the" answer?
<_ion> That has, like, a million answers. :-)
<Keybuk> ok, so bad things happen if one runs usplash from within X
<mjg59_> Yes
<ogra> lol
<mjg59_> Don't do that
<_ion> :-)
<Keybuk> I found the best way to play was to ssh in from another box, and then just run it there
<Rotund> Can someone here explain to me what app-install-data-commercial is going to be for (or hasn't there been an official announcement yet?)
<Rotund> will it be for the certified software?
<Mithrandir> mvo: not really, why?
<mvo> Mithrandir: language-selector checks if you have all the required bits installed for fully working language support (i.e. firefox translations etc). this should not be done on the live-cd
<Keybuk> so "don't run usplash within X" also means "don't run usplash while X is in the foreground"
<mvo> Mithrandir: I hacked around it by checking if it is started as the LiveCD user
<Mithrandir> mvo: ew.  Can't I rather set a gconf key or something?
<Mithrandir> mvo: I absolutely prefer to keep all the hacks to make a live cd behave as a live cd in casper and not in random other chunks of code.
<mvo> Mithrandir: it runs as root, a environment would be good I guess. or a commandline option "--with-verify", then the desktop file would have to be rewriten
<Mithrandir> mvo: sed-ing .desktop files is fine with me.
<iwj> I think the verb from sed is sed, which you can then conjugate as `sedding', `seddery', etc.
<ogra> seduction ? :)
<Keybuk> sedomy
<dholbach> seddery sounds like celery to me
<AlinuxOS> pitti?
<iwj> *crunch*
<Keybuk> dholbach: that would kinda work
<Mithrandir> sed(1)ing, not sed(1)ding.
<Keybuk> you know how it supposedly takes more calories to eat celery than are actually present in it
<Mithrandir> I could also just celerise the .desktop file.
<Keybuk> well it takes more time to figure out a sed script to do want you want than it would actually take to do it yourself
* dholbach add something about "lack of sleep" to the channel's topic
<dholbach> Keybuk: haha - that's like "somebody thought he'd solve a problem with regular expressions, now he had two problems."
<LinuxJones> After every upgrade of dbus or hal on Dapper the system needs a restart. What's up with that ?
<mdke_> LinuxJones: define "needs"
<AlinuxOS> mdke_, ping
<mdke_> AlinuxOS: uh, yeh
<Keybuk> LinuxJones: dbus sucks, let's go shopping!
<AlinuxOS> mdke_, I've got a translation page for you... 
<mdke_> AlinuxOS: mdke@ubuntu.com
<AlinuxOS> In which format must sen you ?
<Keybuk> (it needs you to log out, then restart the system bus, then log in again -- it's easier just to say "restart")
<AlinuxOS> ok I'll do it.
<AlinuxOS> just revision it again :)
<LinuxJones> mdke_: the update noitifier indicates the system needs a restart.
<mdke_> LinuxJones: ah. That's because the services need to be restarted before the update is complete.
<Keybuk> . o O { and GNOME people want init to use dbus ... "hi, you've made an ever-so-tiny-minor-update to your system; REBOOT OR DIE!" }
<_ion> Next up: making Linux handle internal message-passing using dbus.
<mdke_> well, it's "reboot or don't get the upgrades until you do"
<LinuxJones> mdke_: can't that be done as part of the upgrade process ?
<mdke_> sounds quite sensible to me
<mvo> Mithrandir: I added a "-n" option to language-selector that would be required now on the livecd
<Burgwork> Keybuk, why exactly do the dbus people make us restart again
<Burgwork> ?
<iwj> Keybuk: Freaky, but we knew they were all insane.
<Keybuk> Burgwork: because no application can handle the bus going away
<mdke_> AlinuxOS: what's your locale again?
<wasabi__> Why doesn't somebody fix that?
<Keybuk> they invented this shiny IPC system, and then forgot that the proxy can vanish
<Keybuk> wasabi: I don't think they realise it's broken
<Mithrandir> mvo: ok, I'll play with this on Thursday.
<wasabi__> Well, antoher thought is that dbus could be restarted.
<wasabi__> But it's existing instance could stay.
<netstar> Any ubuntu cups gurus eagerly seeking another bug(s)?
<AlinuxOS> mdke_, my locale is ka_GE.UTF-8
<Keybuk> wasabi: then you'd have apps being unable to communicate, because some are on the old bus and some are on the new
<wasabi__> Ahh.
<AlinuxOS> mdke_, Georgin (ka)
<wasabi__> Have the new bus talk to the old. ;)
<wasabi__> Not seriously suggesting that. ;0
<tseng> netstar: they might look at them, if you open a bug on launchpad.net
<mdke_> AlinuxOS: ah good.
<wasabi__> This is one of the major reasons windows requires so many reboots though.
<wasabi__> It should have some thought on whether we can prevent it.
<wasabi__> ie COM components.
<AlinuxOS> mdke_, last editing and then I'll send it to you.
<mdke_> iwj: did you do that -docs upload already?
<iwj> mdke: Yes.
<mdke_> iwj: cool, thanks
<mdke_> is there a clever way that I can get apt to give me a debdiff for the last update of a package?
<mvo> Mithrandir: thanks, I added you to #37568
<AlinuxOS> mdke_, done
<mdke_> AlinuxOS: I've replied.
<AlinuxOS> mdke_, ok I'll check.
<mdke_> AlinuxOS: continue by email pls
<_ion> linux-restricted-modules-2.6.15 (2.6.15.10-1) dapper; urgency=low
<_ion>   * Add madwifi-ng support
<_ion> So madwifi-ng was added after all?
<mjg59_> Yes
<mjg59_> _ion: Only for cards that aren't supported by madwifi
<_ion> Ok.
<siretart> mjg59_: is it possible to force madwifi-ng over madwifi? if yes, how?
<mjg59_> siretart: Blacklist madwifi, load madwifi-ng, echo foo >/sys/bus/pci/drivers/whatever/new_id
<mjg59_> Unsupported, you're on your own, etc
<siretart> mjg59_: sure. thanks!
<bddebian> Howdy
<imbrandon> heya
<bddebian> Hi imbrandon
<j^> does ubuntu work on the new macbooks(Intel GMA 950)?
<Seveas> sort-of
<Seveas> requiers some hackery
<HiddenWolf> Seveas: damn, I was going to spend my holiday-money on one. :)
<j^> i guess wifi will be the problem again
<imbrandon> j^ : http://modular.math.washington.edu/macbook/  <-- a little about the hackery involved
<j^> imbrandon thats the macbookpro not the macbook
<imbrandon> should be the same , still efi bios
<j^> booting is not the issue, its drivers for wifi, graphic card and suspend i am worried about
<mjg59_> wifi should work
<mjg59_> graphics will work under bootcamp, should be working under efi soon
<mjg59_> suspend is possible with bootcamp, you're currently screwed under efi
<mjg59_> If you want a small and light dual-core laptop to run Linux on, don't buy a macbook right now
<j^> whats the alternative? X60?
<thom> mjg59_: has anyone played with x60(s)?
<mjg59_> thom: Mark's got one
<mjg59_> Everything works except suspend, which may work with the next kernel
<mjg59_> If not, I'm going to have to go down there and steal his until it works
<thom> ah, should've guessed
<mjg59_> Uh.
<mjg59_> The new Sun license still seems to prohibit us from distributing any other Java implementation with it.
* _ion doesn't know whether to laugh or cry.
<mjg59_> "                             you do not combine, configure or distribute the Software to run in conjunction with any
<mjg59_> additional software that implements the same or similar functionality or APIs as the Software;
<mjg59_> "
<Burgwork> mjg59_, the faq appears to say that they are only trying to prevent jre/gcj hybrid type things
<_ion> According to https://launchpad.net/distros/ubuntu/+source/notification-daemon/0.3.4-0ubuntu6 that version has been successfully built and published, but http://packages.ubuntu.com/dapper/x11/notification-daemon says the version is still 0.3.4-0ubuntu5. I'd like to know what causes this delay.
<AlinuxOS> mdke, done.
<AlinuxOS> if something wrong, I'm here.
<crimsun> _ion: packages.u.c doesn't sync every hour.
<LaserJock> mjg59_: still no drivers for the x1600 for intel iMacs?
<mjg59_> LaserJock: Free ones? No.
<LaserJock> mjg59_: is there proprietary one that can be installed?
<mjg59_> If you use the bios emulation mode, yes
<LaserJock> hmm
<mdke> AlinuxOS: pvt
<ispiked> iwj: ping
<ispiked> if anyone else who hacks on firefox is here speak up. :)
<mdke> ispiked: only ian does, i think. Is it a problem that can be dealt with by a bug report? he's good with bugmail
<ispiked> mdke: well, it's sort of urgent. basically, some guy is compiling firefox and getting an error, and I want to ask him about it (since he made the patch that's causing the error).
<mdke> ispiked: if he doesn't reply here, then email him.
<ispiked> mdke: ok. this guy is trying to compile patched dapper sources on breezy, so I don't know how much luck he's going to have. :P
<mdke> ah
<wasabi__> Cool. Gota Debian/ARM booted in qemu.
<wasabi__> Now to start bootstrapping Ubuntu.
<wasabi__> There a nice good binary apt repository manager someplace? Used to use dinstall-mini.
<wasabi__> Still good? There any better replacements?
<pygi> wasabi, urgh, #ubuntu please
<wasabi__> I dunno. Porting Ubuntu to ARM sounds like a pretty good topic for this chan. ;)
<pygi> argh, indeed :)
<Kamion> wow, somebody translated ubiquity into Occitan
<pygi> Kamion, :)
<Kamion> I love it when people translate stuff of mine into languages I've never even heard of before
<ogra> where does one speak Occitan ?
<Kamion> Occitania ;-)
<ogra> hehe
<pygi> go figure :-P
<mdke> Kamion: have you got a scots translation yet?
<Kamion> seriously - it's a region of southern France, some speakers also in Italy and Spain
<Kamion> mdke: no
<mdke> it's all about scots
<ogra> http://en.wikipedia.org/wiki/Occitan :)
<mdke> ooh, or maori
<ogra> mdke, they speak maori in scottland ? 
* mdke nods
<tepsipakki> mjg59_: sun will release the source code for java, lets see what the license will be then ;)
<tepsipakki> "It's not a question of whether we'll open source Java, now the question is how," Schwartz told delegates in his opening keynote at the tradeshow.
<Kamion> ogra: no :-)
<pygi> hey pitti 
<mdke> so now java isn't a secret anymore, can someone reply to my mail and we can change the guides?
<mdke> I'm not sure how it all works
<ogra> mdke, not much changed, java has a new name and more recent version but is still in multiverse 
<ogra> s/mane/packagename/
<mjg59_> The source to java is already publically available
<mdke> ogra: so what is the right package to install for just a browser plugin?
<ogra> sun-java5-plugin
<mjr> tepsipakki, pretty much the same's been in the air for years and years. And sure, we can get at Java's source. If we sell our souls.
<metatag> mjg59_, yeah but for R&D stuffs only
<ogra> i'm sure it pulls in all necessary deps
<mdke> ogra: ok, and what's the difference between sun-java5-jre and sun-j2re1.5 
<ogra> mdke, thats a doko question
<Riddell> mdke: what's the problem with i18ning kubuntu docs?
<mdke> ogra: right, that's why I emailed
<Riddell> I can't the e-mail you sent me
<AlinuxOS> pitti, ping
<pitti> hi pygi, hey AlinuxOS 
<tepsipakki> mjg59_: yep, we'll see when the words materialize
<tepsipakki> _if_ they materialize
<AlinuxOS> pitti, I saw your reply to https://launchpad.net/bugs/30671, how much time we have to manage new fonts?
<Ubugtu> Malone bug 30671 in language-pack-ka "ttf-bpg-georgian are GPL ttf fonts for language-pack-ka and GNOME interface." [Normal,Needs info]  
<pitti> AlinuxOS: not so much, I'm afraid
<pitti> AlinuxOS: basically, everything that isn't ready by the end of this week will have a very hard time
<Kamion> by Thursday, really, given that the Canonical distro team members are all on holiday on Friday to rest up for the release push
* Keybuk figures to have a large bug push tomorrow, and then lose Thursday to meetings and final fixings of anything I remember
<Keybuk> David's got Friday off as well, so we're going to go do stuff :)
<ogra> Kamion, there is still a weekend after friday :)
<Keybuk> ogra: tsk, the point of the holiday is to rest before embarking on cd testing madness
<Kamion> some of you may be masochists, but I intend to take the full long weekend's rest
<wasabi__> Ya'll have any recommendations on a archive management tool?
<wasabi__> dinstall-mini?
<pitti> I'll finally catch up with some paperwork and my tax declaration, it's long overdue
<ogra> Kamion, i'd love to ...
* Kamion doesn't, sorry, I just use apt-ftparchive by hand when I need to
<Keybuk> heh, I don't know about rest; I have a wedding to attend on Saturday
<Keybuk> well, a "civil partnership"
<Seveas> wasabi, I'd recommend falcon. But I am biased since I wrote that ;)
<wasabi__> Good enough reason as any to be biased.
<wasabi__> Not in the repositories?
<pygi> Seveas, hehe :)
<Seveas> not yet
<ogra> Keybuk, your own ? (since everybody seems to marry secretly nowadays)
<wasabi__> Is it feature complete? :)
<wasabi__> Before I embark down this road.
<pygi> yup :-P
<Keybuk> ogra: heh, no, not my own
<ogra> :)
<Seveas> wasabi__, yes it is
<Keybuk> in fact, David's comment when we were invited was "don't get any ideas" :)
<ogra> haha
<wasabi__> link?
<Seveas> kaarsemaker.net/software
<ogra> Keybuk, he should talk to my GF she actually *is* getting ideas recently
<Seveas> (example instance: http://seveas.ubuntuinux.nl
<wasabi__> Supports an incoming directory, etc?
<Seveas> no
<Seveas> those are things I didn't want :0
<wasabi__> Heh.
<wasabi__> dinstall-mini it is then. ;)
<Seveas> if you want that: mini-dinstall is quite good iirc
<Seveas> I hate fiddling with incoming/
<_ion> Falcon is really easy to use. I hope it gets support for multiple architectures soon. :-)
<Seveas> _ion, give me a mac or amd64 and I'll have a reason to build it 
<_ion> seveas: :-)
* pygi hands over mac mini to Seveas 
<ogra> Riddell, do you have the ltsp packages in ship on kubuntu ? 
<Riddell> ltsp-server-standalone and ltsp-client seem to be there
<ogra> please add ldm as well (only ~80k) it was a dependency of ltsp-client before but that changed to ldm|gdm|x-display-manager ... since gdm is already on the CD ltsp builds fail to install ldm then
<ogra> you can merge rev 655 from the ubuntu seeds once the push is done ....
<ogra> can only be a matter of hours :)
<ogra> yay paramiko
<mdke> ogra: it's all about getting married
<mdke> (reading scrollback)
<ogra> mdke, heh, yeah
<jcole> where did xnest go
<ogra> ogra@edubuntu:/mnt/devel/bazaar/dapper$ apt-cache madison xnest
<ogra>      xnest | 1:1.0.2-0ubuntu10 | http://archive.ubuntu.com dapper/main Packages
<ogra> where it always was ?
<jcole> no icon anymore in gnome
<ogra> not in alacarte ?
<jcole> "Login in Nested Window"
<ogra> new apps dont show up by default anymore
<ogra> you need to enable them
<Amaranth> no, that's not it
<Amaranth> unless that's a very recent change
<Amaranth> some apps are installed but hidden because most people have no use for them
<ogra> wasnt that part of the menu simplification spec ?
<ogra> yeah, right, not all new apps then 
<ogra> i didnt install any yet that showed up by default
<jcole> "killall gnome-panel" made it show up under System Tools
<mdke> ouch
<wasabi__> Cool. Debian/ARM booted in qemu.
<wasabi__> And now the porting effort begins!
<jcole> wasabi__: embedded ubuntu?
<wasabi__> Well, no. Just an ARM port.
<wasabi__> Making it small is a distinct effort. ;)
<wasabi__> But having it booting on the device is a first step to that.
<zul> heylo
<wasabi__> Woh. this sid install is using DiffIndex
<wasabi__> This new stuff?
<dholbach> good night
#ubuntu-devel 2007-05-14
<glick> hello
<Hobbsee> HI EVERYONE!!!
<Hobbsee> bah.  no one alive
<pygi> Hobbsee, lies
<pygi> and it's 3:54 AM, you can't expect anyone sane to be awake
<Hobbsee> pygi: woot!  a person!
<Hobbsee> yes
<Hobbsee> depends on the timezone
<pygi> how are you? :)
<Hobbsee> oh, spanish time
* Hobbsee isn ton that anymore.
<pygi> not spanish :P Croatia :p
<Hobbsee> well, i just got home, after 36 hours of travel
<pygi> nice :)
<Hobbsee> yep
<pygi> Hobbsee, you must be tired
<pygi> heh
<Hobbsee> pygi: not too bad - slept a lot of frankfurt --> singapore, and singapore --> sydney
<pygi> oh. well, I wasn't of that luck to sleep :P
<Hobbsee> :P
* Hobbsee is little, therefore can sleep on planes
<pygi> ^_^
<Hobbsee> "dear carrier pidgeons, please dont go on strike, kthxbye"
* pygi sends pidgeons to Hobbsee :)
<Hobbsee> lol
<pygi> Hobbsee, did they eat you?
<Hobbsee> pygi: dont think so
<pygi> ehm, why not? :(
* pygi is sad now
* pygi sends turtles to Hobbsee 
* Hobbsee eats the turtles
* pygi sends whales
<Amaranth> pygi: you were in sevilla?
<Amaranth> i guess i didn't do a good job of putting a face to an irc nick there
<pygi> Amaranth, I wasn't
<pygi> why would I be there? I know nothing, so couldn't help with anything
<pygi> :)
<Amaranth> why would i be there? ;)
<pygi> Amaranth, you should answer that
<Amaranth> bling? :)
<pygi> no idea, as I said ... I know nothing :p
<jobezone> Hi, how can I close a bug I submitted in launchapd?
<jobezone> Can't seem to find any option.
<tonyyarusso> jobezone: Near the top, click the package affected, and you'll get a dropdown list of options.
<jobezone> thanks, just did it
<glick> hello
<glick> i was wondering if there was a more seemless and easy/transparent way to integrate encryption into ubuntu
<Treenaks> glick: there is a way.. it's not an easy one generally though (yet..)
<Treenaks> glick: it will automount + ask for a passphrase for LUKS disks
<Treenaks> glick: (so if you have an encrypted USB pen or something, with a LUKS bit on it, it will work)
<glick> Treenaks, i also mean network communication
<Treenaks> glick: SSL/TLS stuff? server or client side?
<glick> i.e. automatically encrypt outgoing email, decrypt incommnig emails, encrypt web communications
<Treenaks> ah
<Treenaks> the default email client (evolution) supports both S/MIME and GnuPG (PGP) signing and encrypting
<glick> i know it supports it
<Treenaks> and of course SMTP/POP/IMAP over SSL/TLS
<glick> but most people dont use it
<Treenaks> it's all just a question of putting the right ticks in the right boxes :)
<glick> we should try to make encryption main stream
<Treenaks> I agree, but you can't force people to buy S/MIME certs (and no, Cacert is not good enough: Outlook will complain)
<Treenaks> (until cacert is available by default in default windows installs)
<glick> do you think it would be possible to encrypt all web traffic?
<Treenaks> not unless all sites go https instead of http
<glick> damn governments
<Treenaks> glick: not just them... most sites are plain http, not https
<Treenaks> also for server performance reasons, of course
<glick> right
* Treenaks pokes iwj's net connection
<ajmitch> finally back home
<Treenaks> ajmitch: wb :)
<Treenaks> ajmitch: had a good flight?
<ajmitch> long but uneventful
<ajmitch> and gladly not full, so I had some room to move
<ajmitch> best of all, my suitcase was even on the right plane this time :)
<Treenaks> wow :) for a change ;)
* Treenaks saw an A380 land/taxi at Seville airport
<ajmitch> impressive?
<Treenaks> That's quite the beast
<ajmitch> did you get some photos of it?
<Treenaks> ajmitch: a bunch, didn't get them off my camera yet
<ajmitch> good work
<Treenaks> apparently, it just came back from a nearby airforce base, where they've been testing the noise output
<Treenaks> anyway, off to work for me, sleep well :)
<ajmitch> bye :)
* ajmitch still feels like he's moving, which isn't good when sitting still :)
<Amaranth> ajmitch: dude, you're lucky
<Amaranth> my suitcase was on the flight after me and got wet somehow
<Amaranth> so the TSA "we went through your shit" tag soaked ink into my clothes
<fabbione> morning
<pitti> Good morning
* ..[topic/#ubuntu-devel:pitti] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Gutsy open, go ape!
<Mithrandir> morning, pitti
<pitti> Hey Mithrandir, got home in one piece?
<Mithrandir> yes, but the airline lost my luggage.
<Mithrandir> again.
<pitti> erk
<StevenK> Mithrandir: Nice.
<Mithrandir> indeed.
<Mithrandir> so I get to sort out that mess today, I guess
<StevenK> Mithrandir: Next time you book say, "I'm going to Boston, but I'd like you to send my luggage to Australia."
<StevenK> 'We don't do that, sir.' "Why not? You did it last time!"
<Mithrandir> heh
<Mithrandir> I'm not sure if it's actually misrouted, I believe it's just delayed.
<StevenK> Amaranth had that problem, his luggage was on the flight after.
* Lathiat laughs @ StevenK 
<fabbione> Mithrandir: yeah same here.. delayed in Madrid.. it?s on its way here now
<StevenK> I wouldn't wish that fun on anyone, though.
* StevenK has a flashback to Mako at the UDS in Mountain View.
<Lathiat> what happened there?
<StevenK> If I recall correctly, his luggage was delayed by two days when he arrived.
<Mithrandir> StevenK: I arrived in SVQ on Friday and got my luggage on Monday (or was it Tuesday?)
<StevenK> That's a quality airline. Quality with a K, that is.
<Mithrandir> you mean they run KDE on all their systems?
* Mithrandir hides.
<Mithrandir> I'd rather blame the airports, the airline itself probably didn't touch the luggage.
<StevenK> That's a poiint.
<StevenK> s/ii/i/
<Mithrandir> hiya Daniel
* StevenK idly notes he doesn't care that Mithrandir bashes KDE.
<dholbach> good morning
<dholbach> hey Tollef
<Mithrandir> StevenK: shame Hobbsee isn't around to be trolled.
<StevenK> Heh
<StevenK> I must admit it's fun trolling Hobbsee about KDE.
<Mithrandir> except in person when she tries to poke holes in my ribs.
<StevenK> Mithrandir: Same.
<mario> hi folks
<dholbach> mjg59: can you make me a member of the ~motu team?
<dholbach> mjg59: it seems there are no administrators for the team and somehow ~ubuntu-dev is not member of the team
<Mithrandir> doko: what is your plan wrt fixing the hunspell breakage?  Just get ooo recompiled?
<doko> Mithrandir: I doubt it will sucessfully build at the moment; didn't plan any updates this week
<Mithrandir> ok
<persia> Mithrandir: Please give-back jackbeat and prokyon3 on sparc.
<Mithrandir> persia: given-back
<persia> Mithrandir: Thank you.
<asac> any idea how the upgrade path from dapper to gutsy+1 will look like? Does it make sense to keep transition packages
<asac> ?
<DBO> ping BenC 
<dholbach> asac: yes, but mvo knows more about that - he does update tests regularly - although I don't know if it's dapper->gutsy+1 or ->gutsy+2 that we will need to support
<Mithrandir> asac: talk to mvo about it.
<asac> mvo: ^^^
<Mithrandir> dholbach: current plan is gutsy+1 is the next LTS
<dholbach> alright
<mario> dholbach, ^_^
<dholbach> mario: hm?
<mvo> asac: keeping transitional packages is a good idea. we can work around missing ones quite easily with update-manager, but in general it makes our live easier
<mario> just hi :p
<dholbach> ah - I didn't know "^_^" meant "hi"
<asac> mvo: so how about mozilla transition ... it was dropped for feisty ... now a replacement will reappear?
<dholbach> hi mario
<DBO> dholbach, PM ok?
<dholbach> DBO: sure
<mvo> asac: you mean that the mozilla suite was removed entirely?
<seb128> hey mvo
<asac> exactly
<mvo> hey seb128
<asac> mvo: will the upgrade be a "one-big-step" thing ... or will upgrade manager do a multi-step upgrade under the hoods?
<mvo> asac: well, we could add some code into the "quirks" handler that transition them automatically to firefix and thunderbird. how important do you consider this?
<mvo> asac: its a "one-big-thing" step currently, also we could change this. but so far there was no need for changing it
<asac> mvo: ok ... i will think a bit. but i think we just want the mozilla -> seamonkey/iceape migration.
<mvo> asac: ok, you don't have to do it with transitional package, if you give me details I can do it inside the release-upgrader and we add it to the manual-upgrades release notes
<asac> mvo: ok fine.
<mvo> asac: could you file a bug about it so that I do not  forget it :) ?
<asac> mvo: against what package?
<mvo> asac: update-manager please
<asac> k
<asac> mvo: product or ubuntu source?
<seb128> mvo: speaking about transition, do you want to do the gaim to pidgin one to update-manager?
<mvo> seb128: what scope is it? would all we need be a single gaim transitional package?
<seb128> mvo: gaim being renamed to pidgin and plugin packages as well
<seb128> mvo: is that something that requires update-manager magic or the provides, conflicts, replaces are enough?
<asac> mvo: 114587
<mvo> asac: thanks!
<mvo> seb128: the general rule is that if apt understands it, u-m will understand it too. it just has some additional hinting features for difficult situations
<seb128> mvo: k, so it should be ok
<pitti> doko: do you have an idea about http://librarian.launchpad.net/7592538/buildlog_ubuntu-gutsy-amd64.texlive-bin_2007-7ubuntu1_FAILEDTOBUILD.txt.gz ? This didn't happen with previous versions
<pochu> cjwatson: are you happy with me doing the base-files merge? :)
<doko> pitti: not seen before. just amd64?
<pitti> doko: yes
<pitti> doko: we can try a give-back, maybe transient glitch with binutils or so?
<doko> pitti: well, maybe wait until my binutils upload is in the archive
<pitti> doko: ok
<dharrigan> Mithrandir: Hi. Did you perhaps get a chance to look over the email from dholbach re: licensing?
<pitti> mvo: can you take a look at https://wiki.ubuntu.com/IncreaseHardwareDatabaseParticipation?action=diff&rev2=12&rev1=11 ?
<mvo> pitti: sure
<mvo> pitti: ok, that sounds good
<Mithrandir> dharrigan: no, sorry, I've been busy at UDS.  I'll try to get to it today.
<dharrigan> Mithrandir: ta :)
<mvo> pitti: are you working on this right now? if not, I will add the code, it seems straightforward
<pitti> mvo: no, I'm not; I'm currently busy with spec writing
<pitti> mvo: thanks!
<mvo> pitti: *cough* I need to go back to spec writing too, but this looks like a good excuse to stop it for ~30min
<pitti> :)
<PriceChild> Hey asac, could you give me your forums name or profile page? I can't find it :)
<gnomefreak> PriceChild: his LP page?
<asac> asac
<asac> PriceChild: ^^^ ??
* Hobbsee waves
<asac> PriceChild: http://ubuntuforums.org/member.php?u=177366
<PriceChild> aha got you asac... dunno why I didn't pick that up earlier... thanks :)
<asac> PriceChild: thanks!!!
<Treenaks> Hobbsee: hi!
<Treenaks> Hobbsee: you made it ;)
<Hobbsee> heya Treenaks!
<Hobbsee> Treenaks: yeah, eventually!
<Treenaks> good :)
<Hobbsee> 36 hours of transit
<Hobbsee> 4 planes, 3 trains, and one car trip.
<Treenaks> Hobbsee: ouch..
<Treenaks> 1 taxi ride, 2 planes, 1 bus = 5.5 hours of fun
<Hobbsee> heh
<Hobbsee> oh i forgot about the taxi
<Treenaks> so now you're very tired, and very jetlagged! ;)
<Hobbsee> i slept for a bit earlier
<Hobbsee> didnt think i was *too* jetlagged though
* Treenaks is getting the plague :(
* Mithrandir isn't too badly jetlagged either.
<ion_> Me neither.
<Treenaks> or me
<ion_> Perhaps its because i have resided in the same country.
<ogra> hmm, does anybody hav a clue where /usr/lib/initramfs-tools/bin/busybox comes from ? there is no travce in the initramfs-tools source package ...
<StevenK> ogra: Is it static?
<ogra> yes
<ogra> but there is no code in the source that builds it or something
<Mithrandir> : tfheen@thosu ~ > apt-file search /usr/lib/initramfs-tools/bin/busybox
<Mithrandir> busybox-initramfs: usr/lib/initramfs-tools/bin/busybox
<ogra> ogra@laptop:~/initramfs-tools-0.85eubuntu10$ LANG=C dpkg -l /usr/lib/initramfs-tools/bin/busybox
<ogra> No packages found matching /usr/lib/initramfs-tools/bin/busybox.
<ogra> intresting
<StevenK> % dpkg -S /usr/lib/initramfs-tools/bin/busybox
<StevenK> busybox-initramfs: /usr/lib/initramfs-tools/bin/busybox
<Mithrandir> what's interesting about that, apart from you using -l instead of -S ? :-P
<StevenK> It's because you can't drive dpkg.
* StevenK high fives Mithrandir
<ogra> gah ...
* ogra goes to find more caffeine
<highvoltage> caffeine++
<ogra> highvoltage, i wonder if thats our problem here ... i think jim uses a dynamically linked version in ltsp 4.2 
<highvoltage> ogra: dynamically linked version of busybox, or those directories that are linked on boot time?
* ogra guesses ours is linked against klibc ... and checks the source ...
<highvoltage> ah, busybox.
<mario> hi folks
<pitti> asac: is it just me, or did the firefox icon (as I have it in my panel) disapper in the last week for everyone?
<Mithrandir> pitti: it's there for me
<pitti> I just have that generic 'X' icon for it
<pitti> hm, ok; /me fixes it manually
<mario> pitti, !
<asac> pitti: hmmm ... haven't heard of a bug
<asac> pitti: what was missing for you?
<pitti> asac: the starter in the panel didn't have an icon any more
<asac> ok
<pitti> asac: I fixed it now, but .config/autostart/firefox.desktop didn't change; no idea where those icons are defined
<asac> interesting
<ogra> https://blueprints.launchpad.net/ubuntu/+spec/ltspfs-virtual-hal-devices would be ready for review
<pitti> smurf: btw, will you still do reviews?
<seb128> ogra: new gnome-power-manager available (2.19
<seb128> pitti: the panel launchers are not autostart desktops, they are stored to .gnome2/panel2.d/default/launchers
<StevenK> Hrm, I need to actually get a clue about my spec.
<ogra> seb128, thanks
<pitti> seb128: heh, they are named 'bar', 'eek', 'foo', 'foo' for me
<StevenK> pitti: Would you mind casting an eye over it and telling me what you think?
<seb128> pitti: yeah, that's normal ;)
<pitti> StevenK: which spec?
<StevenK> pitti: https://blueprints.launchpad.net/ubuntu/+spec/about-ubuntu-revisited
<StevenK> pitti: Be gentle. :-)
<pitti> StevenK: hm, it's not possible to merge those new information into the existing yelp page?
<pitti> StevenK: TBH I'd rather not mess with the Desktop team's stuff; they are better suited for input about that
<StevenK> pitti: Well, I was mainly looking for a "it looks sane to have other people look at it" :-)
<pitti> StevenK: implementation should outline the, well, implementation: whether it's a standalone GTK app, or a yelp page, etc.
<pitti> StevenK: and it should have a stanza about merging the current page
<StevenK> pitti: That's the hard part - Kubuntu being QT, and Ubuntu, Edubuntu and Xubuntu being GTK.
<pitti> yeah, you won't get around writing differnet UIs unless you have a UI agnostic solution like a web page
<pitti> and I'm not entirely sure about the use cases/rationale
<StevenK> I don't mind writing different UIs, personally. A web page also can't display informtion about the machine itself.
<pitti> after all, the gentoo use case knows uname probably, for bug reporting we have apport automatically collect that info, sysadmins will prefer to ssh into the box and check lsb_release, etc.
<pitti> static web page> right
<StevenK> To be honest, the use cases were taken from the original specification.
<pitti> seb128: if you have a minute, I'd welcome your feedback about https://wiki.ubuntu.com/ApportCrashDuplicates
<pitti> seb128: I hope I got it reasonably robust, but you have more experience in that, I think
<Hobbsee> hiya pitti 
<pitti> hey Hobbsee! you made it back!
<Treenaks> pitti: You're still speccing? :)
<Hobbsee> pitti: eventually, yes.
<Hobbsee> pitti: 36 hours, a taxi, 4 and a bit plane flights, 3 trains, and a car later.
<pitti> Treenaks: 'still'? I only finished three specs today, that will cost me the better part of the week :)
<StevenK> Hobbsee: I'm reminded of Planes, Trains and Automobiles, and you didn't have to put up with John Candy.
<Hobbsee> StevenK: heh
<Treenaks> StevenK: you don't know that last part :P
<StevenK> Treenaks: Hah
<seb128> pitti: will look in a bit
<sharms> spacey: I just read the comments on your blog, it seems you have the same trouble I do with people leaving comments that are total retards
<spacey> sharms: hehe, indeed:)
<spacey> my anti-spam plugin is not hard enough
<sharms> I am developing a theory, in which no matter how well you describe a point, no matter how it is addressed, these people will still comment
<mjg59> sharms: Not appropriate here
<sharms> mjg59: gotcha
<spacey> :)
<ogra> mjg59, do we have a valid tech reason to not include 915resolution in main ? 
<mjg59> Yes. It's horrible.
<mjg59> And -intel will be stable enough for gutsy.
<ogra> well, i wont be able to make the classmatepc work without it it seems
<mjg59> Then use -intel.
<mjg59> Or get Intel to ship a working mode in their bios
<mjg59> Using 915resolution effectively guarantees that any external video output won't work
<mjg59> Because it does nothing to reprogram the timings
<ogra> xserver-xorg-video-intel you mean ?
<mjg59> Yes
<ogra> ah, k 
<mjg59> Or i810-modesetting
<ogra> why isnt xorg selecting that one by default ? can we fix that ?
<Mithrandir> ogra: because we are still early in the development cycle.
<mjg59> Because it's a regression on a lot of hardware currently supported by i810
<ogra> aha
<mjg59> Though that'll be fixed soon
<ogra> hmm
<ogra> good :)
<mjg59> i830 support is being added now
<pitti> Mithrandir: can we please try a give-back for texlive-bin on amd64? new binutils are in the archive
<Mithrandir> pitti: backgegeben
<pitti> :)
* pitti arghs at javacc which FTBFSed on the buildd but works fine in a pbuilder
<pitti> Mithrandir: can you please kick javacc as well?
<Mithrandir> pitti: backgegibt
<persia> Mithrandir: Please give-back sooperlooper on sparc and drscheme on powerpc.
* pitti hugs Mithrandir 
<geser> Mithrandir: could you reject decoratortools from the NEW queue? it is needed for turbogears 1.0.2.2 but Debian undid the upstream change requiring it as a seperate module and I want to file a sync request for the Debian package
<Mithrandir> geser: rejected
<Mithrandir> persia: given-back.
<persia> Mithrandir: Thank you.
<pochu> ogra: also, -intel is still in universe
<ogra> well, if thats a sane package we'll get it to main 
<mjg59> ogra: You'll want to talk to Bryce about the plans for that
<ogra> mjg59, seen my /mgs ?
<ogra> *msg
<pochu> ogra: IMHO it's really sane, I've been using for more than a month, and it works fine
<ogra> great
<mjg59> ogra: Ah, I'm not identified
<ogra> oh, k 
<ogra> right, your cloak isnt set i should have noticed
<mjg59> I don't have a cloak
<ogra> oh, i thought ubuntu members are auto cloaked ...
<mjg59> Really? I'd hope not.
<Hobbsee> ogra: only if they ask
<ogra> ah, k
<bddebian> Heya
<pochu> pitti: if you have a moment, can you please take a look at bug #103688? It's for a sru
<ubotu> Launchpad bug 103688 in liferea "liferea crashes - ** ERROR **: file itemlist.c: line 172 (itemlist_load): assertion failed: (NULL != itemSet)" [Medium,Unconfirmed]  https://launchpad.net/bugs/103688
<pochu> pitti: it's a one-line-change, so it shouldn't be a lot of time :)
<pitti> pochu: hm, does that really affect so many users?
<seb128> BenC: you want to patch pidgin, gaim is deprecated
<BenC> seb128: ah, ok
<BenC> seb128: thanks
<seb128> np
<BenC> elmo: Unable to find a source package for pidgin
<BenC> s/elmo/E:/
<ion_> benc: /set completion_auto off :-)
<BenC> ion_: that's no fun. Then I wont  be able to bug elmo by accident :)
<ion_> :-)
<bddebian> heh
<ion_> You could always patch dpkg to say elmo: instead of E:.
<pochu> pitti: I think so: open liferea, go to a folder, and go to another folder :)
<pochu> and since it's one line...
<pitti> pochu: hm, so not just a corner case then; we only have two bugs about that
<pitti> pochu: approved, I updated the bug
<pochu> pitti: maybe people doesn't use folders? :)
<pochu> pitti: cool, thanks!
<seb128> BenC: 
<seb128> $ apt-cache madison pidgin
<seb128>     pidgin | 1:2.0.0+dfsg.1-3ubuntu1 | http://archive.ubuntu.com gutsy/main Packages
<seb128>     pidgin | 1:2.0.0+dfsg.1-3ubuntu1 | http://archive.ubuntu.com gutsy/universe Sources
<randomwalker> hi, how do i go about getting a deb accepted in the ubuntu repos? is this the right place to ask?
<pochu> randomwalker: I think #ubuntu-motu would be better
<randomwalker> pochu: thanks
<seb128> siretart: the new totem requires xine-lib 1.1.7, do you plan to update it this week?
<siretart> seb128: did you mean perhaps xine-lib 1.1.6?
<seb128> no
<seb128> $ grep XINE configure.in 
<seb128> XINE_REQS=1.1.7
<siretart> seb128: if yes, I already uploaded it one or two weeks ago, but it FTBFS because of ffmpeg missing
<siretart> seb128: 1.1.7 is not released yet. do you want me to upload a development snapshot?
<seb128> 	* configure.in: Up the required xine-lib version, to get the
<seb128> 	xine-lib fix at
<seb128> 	http://hg.debian.org/hg/xine-lib/xine-lib?cmd=changeset;node=2b182beaba68;style=gitweb
<seb128> hum
<seb128> I'll just drop the requirement then
<seb128> and talk to totem upstream about it
<siretart> the fix seems pretty sane to me
<siretart> I can include that patch in the 1.1.6 package
<seb128> that would be nice
<siretart> I make myself a note
<seb128> cool
<siretart> I need to update xine-ui as well.. argh
<siretart> seb128: note that xine-lib 1.1.6 is not built in gutsy. if you need it quick, just reupload with dropped build-deps and comment out the line in debian rules containing '--with-external-ffmpeg'
<ogra> dholbach, ltsp-build-client has a default list of package it installs in the chroot ... since thats free to be tewaked by and admin to his/her liking i try to avoid package deps from ltsp-client ... in case of the cursor theme thats not true i think but there might be packages ...
<dholbach> ogra: ok, if you want, you can change your cursor.theme to inherit from Industrial,Human
<dholbach> ogra: that way it should fall back to one of them
<dholbach> (if found)
<ogra> i think thats what i do already ... 
<ogra> for ldm
<dholbach> then I don't know what else I should take care of for you
<ogra> in ltsp we dont do that for all packages
<ogra> EARLY_PACKAGES="xserver-xorg libgl1-mesa-glx libgl1-mesa-dri libglu1-mesa xfonts-base xbase-clients xutils xkb-data xterm ltsp-client d
<ogra> iscover1 laptop-detect xresprobe pulseaudio pulseaudio-esound-compat inputattach usplash ldm ltspfsd human-cursors-theme usplash-theme-ubuntu"
<ogra> an admin is free to use a different value for EARLY_PACKAGES
<ogra> thast why we dont have deps in place there 
<dholbach> ogra: are you saying you still want human-cursors-theme in main?
<ogra> i can try to make the default lis a recommends
<ogra> no
<ogra> i say you wouldnt have found it with rdepends
<dholbach> ok
<ogra> since EARLY_PACKAGES isnt in any dependency tree 
<dholbach> right
<ogra> i'l add the defaults to be a recommends or suggests of ltsp-client for gutsy so you can see what its in EARLY_PACKAGES without reading the source
<dholbach> ok
<ogra> i remember we had that prob before ... so lets get it solved now :)
<dholbach> pitti: do I need a MIR for industrial-cursors-theme? (it just contains cursors - we want to drop human-cursors-theme)
<pitti> dholbach: I'll take a look at the package before promoting it
<dholbach> pitti: ok, take your time
<bryce> keescook: you abouts?
<keescook> bryce: yawp, catching up on some email.  sup?
<bryce> I was thinking about working on merging a few of the xserver video drivers, and was curious about plans for finishing up the xserver merge
<dholbach> seb128: doing gthumb
<seb128> dholbach: cool, I'm doing nautilus
<Simira> hmm...
<Simira> dholbach: how's your Dutch?
<Hobbsee> Simira!!!
<Simira> hi Hobbsee, home already?
<dholbach> Simira: barely existant
<Simira> dholbach: ok, nm then :)
<Hobbsee> Simira: yeah, after 36 hours of travel, 4 and a bit planes, 3 trains, 1 taxi, and 1 car.
<Simira> and a bit???
<Simira> where was the parted plane?
<Hobbsee> Simira: we taxi'd out to the runway, then they decided that we really shouldnt take off, and took us back
<Simira> right
<Hobbsee> ground power to the plane died.
<Hobbsee> Simira: although, there was major fog in sydney when we were originally supposed to get in - so we may have been ended up shoved to melbourne instead, had we gottne thru
<keescook> bryce: well, I need someone to look at the debian/rules differences (seb128?) but beyond that, I think it's a simple case of dropping the patch timo mentioned, building it and testing it on a gutsy install
<bryce> keescook: ok, let me know when you want to tackle those things, and how I can help
<seb128> bryce, keescook: I'm happy to look at the xserver merge if you want, that will be for tomorrow though, I've to run in like 10 minutes
<keescook> seb128: I'll put together some specific questions about it and email you.
<keescook> bryce: let's walk through it later today (say maybe around 1pm?)
<seb128> keescook: ok
* keescook hugs seb128
* seb128 hugs keescook
<racarr> .win goto 17
<racarr> err. Sorry about that.
<bryce> keescook: sounds great!
<bryce> I'm going to get started on the video driver DaD merges; a bunch look real simple
<keescook> bryce: cool.  now that MoM is working again, you might want to look there too.  I'm not sure which gets run more frequently (merges.ubuntu.com)
<Mithrandir> mom runs every hour
<bryce> ok
<bryce> will DaD be going away then?
<keescook> bryce: not sure.
<Hobbsee> bryce: you''d have to ask those who wrote it
<keescook> hiya zul!  any chance you can look at the xen-3.0 merge?  I only touched it last because of the security update I stuffed into it.  :)
<zul> keescook: yep Im in the middle of it now gutsy is going to have 3.1
<keescook> cool
<ogra> woot, according to MOM debian is ahead of us with gnome package versions ? wow ... i think thats the first time since ubuntu exists ... 
* ogra goes to fix that and packages the new upstream versions
<pitti> asac: enigmail (in NEW) does not C/R/P: mozilla-thunderbird-enigmail
<pitti> asac: can they actually be installed side by side?
<asac> pitti: let me look
<asac> pitti: looks like a bug
<pitti> asac: I leave it in NEW until it's fixed, ok?
<asac> sure first thing in the morning
<asac> thanks
<mjg59> Hm. What's up with gucharmap?
<mjg59> It's blocking any gnome builds
<Mithrandir> mjg59: give me an example of a blocked build?
<mjg59> Mithrandir: gnome-applets
<dholbach> libgucharmap6-dev -> libgucharmap-dev?
<Kmos> pitti: check your mail
<geser> have someone an idea why libembperl-perl fails to build on the i386 and amd64 buildds (but builds fine in an amd64 pbuilder)?
<Mithrandir> because apache 1 is broken, it seem
<Mithrandir> +s
<geser> does the buildd use an other apache package than my pbuilder?
<geser> it builds on the other arch buildds
<ogra> pitti, ??
* pitti waves to ogra
<ogra>      - debian/dhcp3-server.init.d: Allow LTSP to override default configuration
<ogra>        in /etc/ltsp/dhcpd.conf.
<ogra> ??
<ogra> is that adopted by debian ? 
<pitti> ogra: certainly not?
<ogra> no idea
<ogra> i just looked into your changelog 
<pitti> ogra: it's in 'remaining changes'
<ogra> oh, thats meant to be a dash, not a minus ? 
<pitti> yes, it's just a normal list
<ogra> ok
<ogra> i read it as minus ... the plusses in there confused me, sorry
<pitti> no worries; it's just a standard changelog enumeration order, *, then -, then +
<ogra> yep
<micahcowan> Would anybody like to sponsor a gawk patch? bug 58256.
<ubotu> Launchpad bug 58256 in gawk "length() memory error " [Undecided,In progress]  https://launchpad.net/bugs/58256
<shaya> so did the libnspr4 upgrade break everything that uses it? :)
<xst> Does anyone know the status of bug #108288?
<ubotu> Launchpad bug 108288 in linux-source-2.6.20 "Audio is played in "slow motion"" [Medium,Confirmed]  https://launchpad.net/bugs/108288
<pochu> xst: looks like confirmed :p
<xst> pochu: Yes, I can see that. But besides that, are there any progress?
<pochu> xst: just kidding :) Looking at the bug report, I'd say there isn't
<pitti> Riddell: I just removed pmount from the kubuntu desktop seed FYI
<Riddell> pitti: ok
<pitti> Riddell: do you plan a kdelibs upload in the next time to remove it? or shall I upload it or file a bu?
<pitti> bug, even
<Riddell> pitti: go ahead, I'm on holiday this week
<freezone> hi
* rgl waves
<pygi> 4
<bryce> keescook: btw, if/when you want to talk xserver, I'm ready
<keescook> bryce: okay, let me finish up my pptp testing, one sec
<bryce> keescook: I found with the video drivers that they're depending on xserver 1.3 now
* keescook nods
#ubuntu-devel 2007-05-15
<alex_mayorga> hi
<alex_mayorga> I've read the topic already, but wonder if someone more experienced could help me determine if this http://ubuntuforums.org/showthread.php?t=4744 has been somehow reintroduced into the code base
<alex_mayorga> thanks in advance
<conn> mjg59, re: bug #103366, have you had success connecting to a wpa network with your zd1211-based card? 
<ubotu> Launchpad bug 103366 in linux-source-2.6.20 "NetworkManager cannot connect to WPA network at first boot" [Critical,In progress]  https://launchpad.net/bugs/103366
<mjg59> I don't have a wpa network
<conn> mjg59, my apologies, I meant bug #103768, has the proposed fix cleared up the association problems for you?
<ubotu> Launchpad bug 103768 in linux-source-2.6.20 "softmac and network-manager cite unreconcilable differences" [Critical,Fix released]  https://launchpad.net/bugs/103768
<mjg59> It's not in a released kernel yet
<mjg59> As far as I know?
<conn> Tim Gardner posted a proposed fix there
<mjg59> Yes
<conn> you're right, it's not released yet, I'm curious if there's be any changes... the fixed module still causes problems with WPA
<conn> *there'll
<conn> mjg59, see here: http://www.linuxwireless.org/en/users/Drivers/zd1211rw#head-dfa194ef8747529a0c18b3efae51430abd3fb34f
<conn> it's possible there's a problem with debian/ubuntu scripts in conjunction to driver-specific quirks
<mjg59> The issue I had was nothing to do with that
<mjg59> softmac simply wasn't sending association events
<conn> I know, I unmarked my bug as a duplicate, I was just trying to see if there's any overlap regarding my bug and yours
<conn> mjg59, point three of that link could explain the problems on your system (dhclient scripts causing disassociations)
<mjg59> conn: No, the problem on my system was softmac not sending association events
<conn> alright, thanks
<keescook> asac: hmm... I can't run "firefox -ProfileManager" when firefox is already running.  this is new.  :)
<keescook> asac: nevermind, I have run into bug 39559 (which seemed to go away during feisty...)
<ubotu> Launchpad bug 39559 in firefox "Cannot have two profiles (-P switch) opened simultaneously." [Low,Confirmed]  https://launchpad.net/bugs/39559
<fabbione> morning
<cjsoftuk_> I found a bug in ncpfs, where do I report it?
<tonyyarusso> !bugs | cjsoftuk_ 
<ubotu> cjsoftuk_: If you find a bug in Ubuntu or any of its derivatives, please file a bug report at: http://bugs.ubuntu.com/ IRC is not a good medium to report bugs and this channel is for development coordination.
<cjsoftuk_> tonyyarusso: Thought so, I did that already, just wondering if there was anywhere else
<pitti> Good morning
<Mithrandir> hiya Martin
* Starting logfile irclogs/ubuntu-devel.log
* #ubuntu-devel  [freenode-info]  channel trolls and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<dholbach> good morning
<pitti> ah, so gaim renamed itself to pidgin over night
<dholbach> pitti: that happened weeks ago - though not in our archive :)
* Mithrandir ponders upgrading his workstation to gutsy.
<pitti> I did so a few days ago; upgrade needed several apt-get -f install steps, but final result works fine
<Mithrandir> update-manager -c -d ended up being quite unhappy
<Mithrandir> morning Seb
<Mithrandir> texlive is entirely too large.
<seb128> hey Mithrandir
<pitti> Mithrandir: you should definitively uninstall tetex-extra before the upgrade
<Mithrandir> pitti: I failed to do so
<pitti> Mithrandir: the transitional package pulls in a lot of stuff you probably won't need
<Mithrandir> oh well
* dholbach purged a lot of tetex/texlive stuff *after* the upgrade
<Mithrandir> bandwidth is cheap
* seb128 didn't have enough space on /usr to do the upgrade
* dholbach hugs seb128
* seb128 hugs dholbach
* pitti strangles Mithrandir with his 3 GB/week quota
* Mithrandir ponders making /usr a symlink to / and see what breaks.
<Mithrandir> I think I'll do that with my next system
<StevenK> pitti: 12 Gb a month? Ugh.
<StevenK> Mithrandir: Ouch.
<Mithrandir> StevenK: why?  It should work just fine
<StevenK> Mithrandir: I was thinking of how to actually migrate.
<pitti> StevenK: well, it's actually bearable as long as I stay with only one arch and use jigdo etc. :)
<pitti> StevenK: but I ordered DSL now (again, 3rd attempt)
<Mithrandir> mv /usr/* / ; mv /usr/bin/* /bin ; mv /usr/lib/* /lib ; mv /usr/sbin/* /sbin should be about it.
<StevenK> pitti: Heh. What link are you on now?
<geser> are there any plans to upgrade python-support in gutsy to 0.6.4? A package I'd like to sync needs it.
<StevenK> Mithrandir: But some of my machines have a small / and a /usr that is roughly triple the size.
<Mithrandir> StevenK: oh, I stopped splitting out /usr years ago
<Mithrandir> it just doesn't make sense, IMO
<StevenK> Old habits die hard.
<Mithrandir> /var on a separate partition however, is something I practice on servers and such
<StevenK> I was pondering looking at the python-support merge.
<geser> StevenK: looks like an easy one (only depends and conflicts which need to be adjusted)
<StevenK> geser: There's more than that.
<geser> what did I miss?
<StevenK> egg-info. 
<StevenK> It means that a bunch of packages will FTBFS without changes.
<geser> is it really a problem this early in the dev cycle?
<StevenK> It still needs to be considered.
<geser> I guess more and more debian packages will rely on the egg renaming done by python-support
<Mithrandir> geser: too much breakage early just means lots of pain later in the cycle, so it's worth trying to avoid big problems at this point too.
<geser> so the solution would be to disable the egg renaming in python-support for now until people had time to fix their packages?
<StevenK> That may not be an option.
<StevenK> I've been vaguely pondering it.
<Mithrandir> hm, I wonder what my luggage was doing in belgrade
<fabbione> Mithrandir: decided to have an extra few days of vacation? :)
<geser> have you an idea how to solve it that packages relying on the feature get it and that it doesn't break existing ones?
<highvoltage> Mithrandir: heh!
<fabbione> mine arrived yesterday
<StevenK> geser: What if the behaviour conflicts?
<smurf> Mithrandir: That's not that bad a detour. My father once flew home from Boston via Amsterdam to Germany, while his luggage ended up in Damascus.
<geser> StevenK: I've currently no idea how to solve it. Currently I see only breaking old or new packages.
<elkbuntu> Mithrandir, did you lose your luggage *again*?
<Mithrandir> elkbuntu: no, the _airline_ lost my baggage again.
<elkbuntu> heheheh
<Mithrandir> or airport or whatever.
* elkbuntu hugs Mithrandir
* Mithrandir hugs elkbuntu back
<StevenK> elkbuntu: How were your flights?
<Mithrandir> I'm slightly jealous of it.. got to see Belgrade, but I didn't.
<StevenK> Heh
<elkbuntu> StevenK, up until singapore, they were fine. Then the singapore airport couldnt power the plane for some reason, and wouldnt let the plane power itself up, so we were delayed 3:15
<StevenK> Mithrandir: It probably got to see the tarmac at Belgrade.
<StevenK> elkbuntu: Yeah, I heard about that.
<Mithrandir> StevenK: true dat.
<smurf> elkbuntu: fun. :-/ How did they resolve the stalemate?
<StevenK> Which passenger backed up the car and provided jumper cables?
<elkbuntu> smurf, by removing us from the plane for several hours while they fixed the problem
<elkbuntu> while waiting we failed to convince some microsoft employee to jump ship
<smurf> Ah, the "well theoretically the plane might blow up if several OTHER things which never go wrong also go wrong" gambit.
<smurf> It's almost as bad as the "well you could conceivably have hidden some explosives n that yogurt you've already half eaten" stupidity they've now started to impose in Europe too. :-(
<StevenK> smurf: Can you expand on that? I haven't heard about that at all.
<Mithrandir> next time, I'm going to try to bring a bottle of frozen water with me
<smurf> StevenK: That's the "no fucking liquids whatsoever allowed" rule. You may have heard about it.
<StevenK> Oh yes, that one.
<elkbuntu> smurf, i look forward to the day when humans are too liquidy to fly. that will be interesting to watch unfold ;)
<elkbuntu> ZOMG YOUR BLOOD MIGHT BE EXPLOSIVE!
<StevenK> Heh
<ajmitch> oh, elkbuntu is back :)
<StevenK> Heh
<elkbuntu> ajmitch, at least partially
<Mithrandir> shame the Bruce Schneier movie plot contest is over, I'm sure elkbuntu could have written some excellent bits for it.
<StevenK> elkbuntu: I have a crass comment, but I'll refrain.
<elkbuntu> StevenK, yes dear, i think you will.
<StevenK> elkbuntu: Make me. :-P
<ajmitch> elkbuntu: part of you still in spain?
<elkbuntu> ajmitch, no, my soul is still partially in frankfurt where i was unable to buy cigarettes because i was going to be going via singapore, and partially at sydney airport where they told me i bought too many smokes in singapore and had to hand em over. if hobbsee wasnt travelling with me, i'd have lost the lot
<ajmitch> oh dear
* ajmitch had a nice, uneventful trip home
<elkbuntu> because if you bring too many in... they tax you the entire lot
<StevenK> elkbuntu: Yup. Isn't tax fun?
<Mithrandir> not that way here, though
<elkbuntu> StevenK, even with the carton and a bit i got to keep via hobbsee, it's still cheaper than if i had have bought here
<StevenK> elkbuntu: How much cheaper?
<elkbuntu> about $50
<StevenK> Nice.
<StevenK> Given $50 doesn't buy a full cartoon here, that's impressive.
<elkbuntu> yeah
<ajmitch> just how much did you try & bring in?
<elkbuntu> ajmitch, 4 : i thought it was 2cartons/person, and hobbsee was going to help me stock up, then we saw a sign like 10 mtrs from customs saying it was 200cigs max (1ctn)
<elkbuntu> so we dumped it all with me, and she got to take a carton and a 'concession' (because i'd already opened a carton in singapore)
<smurf> elkbuntu: try quitting :-P
<elkbuntu> smurf, noooooooO!
<elkbuntu> you really dont want me any more insane than i already am
<smurf> elkbuntu: Who cares about your sanity? ;-)
<elkbuntu> smurf, well, me for one...
<Mithrandir> elkbuntu: you hang around us. :-P
<ajmitch> on irc, noone knows you're insane
<smurf> elkbuntu: I could think of worse problems. Like, for instance, lung cancer.
<elkbuntu> ajmitch, then things like summits and conferences happen ;)
<ajmitch> elkbuntu: where insanity is the normal state?
<ajmitch> hello Hobbsee 
<elkbuntu> you're right, i should aim for liver cancer or something?
<Mithrandir> ello obbse
<ajmitch> nah, we just try for general liver failure
<Mithrandir> +e
<elkbuntu> Hobbsee, sorry i didnt msg you. i kinda died yesterday.
* Mithrandir wonders if the appropriate thing for elkbuntu would then be raise dead or holy water.
<elkbuntu> Mithrandir, no, 20hrs of sleep
<Hobbsee> hi ajmitch 
<Hobbsee> elkbuntu!!!
<Hobbsee> hiya Mithrandir 
<elkbuntu> Hobbsee!!
<ajmitch> elkbuntu: but you only had a short trip, right?
<Hobbsee> elkbuntu: not suprising - so did i
<Hobbsee> elkbuntu: when did you get in?
<elkbuntu> ajmitch, no...
<elkbuntu> Hobbsee, 1.20 the plane landed in albury
<Hobbsee> elkbuntu: heh, nice
<ajmitch> am?
<elkbuntu> ajmitch, pm
<ajmitch> and you're complaining?
<Treenaks> ajmitch: you had to swim? :)
<\sh> mvo, ping could you enlighten my mind how to tell update-notifier to just restart one app/daemon after upgrade?
* ajmitch left a few hours before you & got home at 5pm yesterday
<elkbuntu> where did your flights b0rk?
<ajmitch> just lots of sitting around
<elkbuntu> musta been
<ajmitch> all my flights were on time, but the time in airports added up
<mvo> \sh: if you don't want to do it in postinst, there is https://wiki.ubuntu.com/InteractiveUpgradeHooks
<mvo> \sh: it can run scripts, but it can not run them automatically
<elkbuntu> yeah. airport time is better than plane time though
<\sh> mvo, I was thinking about something like restart-app hook, with the name of the app in a file which has to be read from a file somewhere...
<ajmitch> elkbuntu: though drinking a guiness in heathrow on an empty stomach can be fun
<dholbach> doko: we're having trouble with the python-{gtk,gnome}* merges - do you know of anything that would break the python-dbg stuff?
<Hobbsee> elkbuntu: right
<elkbuntu> especially better than an hour and a half waiting for singapore to power up a plane, and hence without airconditioning, only to be shuffled off the plane to wait more time in a crowded lounge
<ajmitch> elkbuntu: a bit nasty
<elkbuntu> singapore's humidity is pure evil
<doko> dholbach: not that I know; build errors?
<dholbach> doko: even using the old debian/rules resulted in   python-dbg -c 'import ...'    not working
<mvo> \sh: that is a interessting idea. currently only FF seems to need it, what app is your use-case?
<\sh> mvo, wine ;)
<\sh> mvo, mdz is the cause of it ,-) https://bugs.launchpad.net/ubuntu/+source/wine/+bug/95178
<ubotu> Launchpad bug 95178 in wine "Should use notify-reboot-required or similar" [Undecided,Unconfirmed]  
* Mithrandir wonders where all his CA certificates in firefox went
* Hobbsee ate them.
<asac> Mithrandir: since when are they gone?
<Mithrandir> asac: I just dist-upgraded this machine to gutsy.
<mvo> \sh: for now, you could just reuse the firefox notification, we can think of something more elaborated
<Mithrandir> it has run feisty until now.
<asac> hmm
<ajmitch> asac: happened to me too, I just haven't filed a bug yet
<ajmitch> and this was running gutsy before I left for uds
<asac> Mithrandir: what are the sizes of your .db files in your profile
<\sh> mvo, cool...so I have to install just a file e.g. wineserver-restart-required.update-notifier in /usr/share/wine and everything is ok, right?
<asac> Mithrandir: e.g. cert8.db
<\sh> and oh wonder, wine compiles with stack-protection
<ajmitch> asac: cert8.db is 98k here
<dholbach> mdz: good morning - do you think you could make ubuntu-dev a member of motu? atm I can't commit to motu branches in LP
<asac> ajmitch: but still no certs in there?
<dholbach> mdz: or offer mentoring for motu
<ajmitch> asac: it's complaining about "Could not verify this certificate for unknown reasons"
<mvo> \sh: just install a file in /var/lib/update-notifier/user.d/ that follow the format described on the wiki (best is probably to just copy the ff one for now)
<asac> ajmitch: when doing what? visiting site? Do you still see your certs in security manager?
<ajmitch> asac: I get the standard "Unable to verify..." when hitting an SSL-enabled site
<doko> dholbach: do you test in the package directory, or in some other dir?
<ajmitch> & there are few certs in the certificate manager
<dholbach> doko: in another dir
<Mithrandir> asac: -rw------- 1 tfheen tfheen 64K 2007-05-15 10:20 cert8.db
<Mithrandir> asac: my byhand-installed CAs are there just fine
<asac> Mithrandir: just build-in ones gone? ... same for you ajmitch ?
<Tonio_> hi ;)
<Mithrandir> asac: yes
<ajmitch> asac: it appears that way
<\sh> mvo, in /var/lib/update-notifier/user.d is no such file..it's in /usr/share/firefox
<\sh> mvo, speaking of feisty (newly installed)
<mvo> \sh: it will copy it in its postinst if it sees a runing FF
<\sh> mvo, ah :) ok...now I get it :)
<doko> dholbach: please make the current packaging available
<dholbach> for others the .so files were not renamed to _d.so
<mvo> \sh: great :)
<\sh> mvo, thx for the explanation...now I can fix at least 2 bugs of wine ;)
<dholbach> doko: ajmitch had problems with those merges too
<dholbach> doko: but yeah, let me upload an example
<asac> mvo: unfortunately that notify mechanism is not good enough :) ... i got several reports that notification appeared after firefox crashed.
<asac> mvo: dunno if we can do something about it except waiting for all firefox stopped before replacing bits
<mvo> asac: what would be the best option? show the notification early? or skip it after FF crashed (the later could be done with the "DisplayIf" key in the hookfile, it can run any shell command)
<\sh> btw..in gutsies firefox, there is no .postinst file anymore...but changelog tells me it should be there
<asac> mvo: honestly I don't know. probably we want the latter, but its all far from perfect
<mvo> asac: right. best would be if it didn't crash at all :)
<asac> hehe ... you get it ;)
<\sh> who removed firefox.postinst from the package?
<dholbach> can we get telepathy-mission-control and telepathy-glib through NEW? :-)
<seb128> dholbach: let me look at them
<dholbach> seb128: source NEW via Debian NEW
<dholbach> (dunno if you do them)
<seb128> yes, I can do them
<dholbach> knowing the other telepathy packages, I guess they're all lgpl2.1 only
<seb128> they have been accepted to Debian so they should be ok
<jdub> Mithrandir: ping
<seb128> I'll have a look anyway
<asac> \sh: guess it was left behind when migrating to new package layout ... enqueued in TODO.
<Mithrandir> jdub: what's up, crazy australian?
<\sh> asac, ok...just thought I'm more blind as I'm already ;)
<jdub> Mithrandir: i noticed you're most obviously associated with the ubuntu mobile foo (as per blueprint assignments); are you leading the technical effort within canonical?
<Mithrandir> jdub: yes
<ajmitch> lucky chap
<jdub> Mithrandir: ok, you need to be on mobile-devel-list (mail.gnome.org)
<Mithrandir> jdub: I subscribed on Thursday or so
<jdub> great
<crimsun> this may be out of left field, but does anyone happen to know which model Dell keybuk has?
<crimsun> (need to comment the patch I'm sending upstream)
* dholbach hugs seb128
* seb128 hugs dholbach
<dholbach> doko: dget http://daniel.holba.ch/temp/gnome-python-extras_2.14.3-1ubuntu1.dsc
<Mithrandir> jdub: you might want to hang out in #ubuntu-mobile too
<Mithrandir> asac: is there anything more I can provide you with in order for you to be able to debug the problem?
<asac> Mithrandir: i can't reproduce ... still trying
<ajmitch> asac: all I had to do was upgrade firefox, watch it crash & certs were gone when I restored the session 
<Mithrandir> I quit it by hand
<Mithrandir> this is on amd64, but I would be surprised if it was arch-specific.
<asac> i am on amd64 as well
* ajmitch also, fwiw
<asac> Mithrandir: you quit after upgrade?
<Mithrandir> asac: before.
<asac> Mithrandir: please backup your profile (so we can at least reproduce the broken state) ... then can you look if starting in feisty chroot makes a difference?
<Mithrandir> I don't have a feisty chroot here, but I could bootstrap one, of course.
<Mithrandir> interestingly enough, this affects epiphany too
<asac> hmm
<mdz> mvo,\sh: ideally, wine would provide a kill-wineserver or such, which we could run
<asac> Mithrandir: i guess it would be really worth a try to start with feisty firefox again ... just to see if some .db file got corrupted or if the problem is somewhere else.
<Mithrandir> asac: just firefox or a full installation?
<asac> Mithrandir: to be safe use a chroot
<Mithrandir> same with a clean profile, btw.
<asac> really?
<asac> thats really interesting
<asac> let me see
<asac> Mithrandir: so you use clean profile and get cert warning on launchpad?
<Mithrandir> asac: correct.
<asac> Mithrandir: i don't get that .... what libnss libs are installed (dpkg -l libnss*) ?
<Mithrandir> ii  libnss3-0d                 3.11.5-3                   Network Security Service libraries
<asac> Mithrandir: hmm ... try install libnss3-dev
<Mithrandir> asac: same problem (with epiphany)
<ajmitch> asac: can't reproduce on the laptop here (x86)
<asac> Mithrandir: ok i can reproduce something similar if i move away the link /usr/lib/firefox/libnssckbi.so ... does it exist for you and point to valid target?
<Mithrandir> zsh: no matches found: /usr/lib/firefox/libnss*
<asac> ups
<asac> Mithrandir: please create by hand
<asac> /usr/lib/firefox/libnssckbi.so -> ../nss/libnssckbi.so
<Mithrandir> there's one in /usr/lib/nss
<asac> yeah right ... firefox one should point to it
<ajmitch> asac: should it be a symlink or a file?
<Mithrandir> asac: much better.
<asac> Mithrandir: what package version do you have?
<Mithrandir> asac: of what? :-P
<asac> firefox
<asac> ;)
<Mithrandir> ii  firefox                    2.0.0.3+3-0ubuntu3         lightweight web browser based on Mozilla
<Mithrandir> ii  epiphany-browser           2.19.2-0ubuntu1            Intuitive GNOME web browser
<Mithrandir> the symlink fixed epiphany too
<asac> yeah safe bet
* ajmitch has both libnss3 & libnss3-0d installed on the laptop, so /usr/lib/firefox/libnssckbi.so is a file owned by libnss3
<asac> ouch
<ajmitch> yep
<asac> ajmitch: ok thanks for the hint. Guess we need a conflict
<Mithrandir> that wouldn't fix it for me, though. :-P
<asac> Mithrandir: i guess libnss3 was still there when installing firefox ... but was removed afterwards. Otherwise I can't tell why the symlink is not created
<asac> any idea?
<asac> its installed by debhelper in firefox.links
<Mithrandir> no, it's not.
<Mithrandir> hm
<asac> (gutsy)asac@hector:/tmp/firefox-2.0.0.3+3$ grep nss debian/firefox.links 
<asac> usr/lib/nss/libnssckbi.so usr/lib/firefox/libnssckbi.so
<asac> (gutsy)asac@hector:/tmp/firefox-2.0.0.3+3$ dpkg -L firefox | grep libnss
<asac> /usr/lib/firefox/libnssckbi.so
<Mithrandir> it is, but something nukes it
<asac> as i said ... try reinstalling firefox ... should help
<asac> when the file exists during install link will just not be created
<ajmitch> "dpkg -L firefox |grep libnss" shows me nothing
<asac> ajmitch: please reinstall firefox and see if that helps
<Mithrandir> I suspect libnss3 replaces firefox.
<ajmitch> right, symlink is in place after the reinstall
<asac> ok ... i hate to add conflicts on libnss3 for firefox, but i don't see any other option. ideas?
<triceratops> Does anyone know how many GByte disk space it will need for apt mirror Dapper, Feisty and Gutsy?
<triceratops> s/apt mirror/apt-mirror/
<tepsipakki> triceratops: 70GB for x86
<triceratops> tepsipakki: I just had a first look to man apt-mirror and it says it will fetch x86 and the 64bit archs, am I wrong here?
<pochu> triceratops: you should consider mirror edgy too, since upgrades from dapper to feisty are only supported with dapper>edgy>feisty
<tepsipakki> triceratops: you can configure it
<triceratops> pochu: oops mixed dapper and egdy, its the lts i'm interested in
<triceratops> tepsipakki: so 70GB for x86 binary (no src deb's)
<tepsipakki> triceratops: no, all of it
<tepsipakki> besides, it will get bigger during gusty development
<tepsipakki> uh, gutsy
<triceratops> tepsipakki: I'm asking because I#m looking for a solution for a guy who has no internet connection, very common in developing countries...
<triceratops> tepsipakki: So my idea is to sent him a full set of cd's to set up a full mirror as a starting point.
<StevenK> triceratops: That could be like 100 CDs?
<tepsipakki> dropping deb-src lines should save some
<StevenK> My mirror for Edgy, Feisty and Gutsy for i386 and amd64 is 45Gb.
<tepsipakki> also, that has -updates, -backports, installer..
<triceratops> StevenK: Your'e right, what just makes me think of sending a hd instead..
<Lutin> Mithrandir: could you let cinepaint ~proposed2 go into feisty-proposed so I can test it ?
<socrano> where do i find a good "kubuntu alternate install cd" .iso (i.e. with the md5sum matching 5c19803a2a34996e68be96a279371b5d)? i downloaded it from five different mirrors and i got different md5sums! is this a known issue?
<socrano> even http://releases.ubuntu.com/kubuntu/feisty/ (which i considered most official and probably the source server) has a broken copy!
<sn0> socrano how are you downloading it? sounds like its getting corrupted on download
<sn0> http://cdimage.ubuntu.com/kubuntu/daily/current/feisty-alternate-i386.iso | 5c19803a2a34996e68be96a279371b5d *feisty-alternate-i386.iso
<socrano> sn0: ftp, http, then rsync, rsync, and rsync again (on many mirrors)
<sn0> maybe try a different method of downloading, wget or another browser just incase
<sn0> ahh strange 
<sn0> isp problems? have you tried from another ip
<socrano> sn0: wow, does the "/daily/" in the path express what it means?
<socrano> sn0: yeah, i used some proxies too
<socrano> sn0: i tried everything
<socrano> sn0: but i will try your mirror too
<sn0> socrano daily was the link for the daily/daily-live images before feisty was released on the 17th~
<socrano> sn0: it looks quite official too :)
<sn0> ill try downloading on a server here quickly to see, but during iso testing there were no such problems found
<StevenK> sn0: 19th.
<sn0> StevenK yea, the alternate image candidate was from the 17th, sorry for confusion
<socrano> sn0: http://releases.ubuntu.com/kubuntu/feisty/kubuntu-7.04-alternate-i386.iso gives me d19ac271796c2956014e6f68f80c8d2b
<sn0> trying now on the first link socrano , 2 ticks
<sn0> 5c19803a2a34996e68be96a279371b5d  feisty-alternate-i386.iso
<sn0> says md5sum
<sn0> second image downloading now, be done in a min
<sn0> if you want to talk in pm work away socrano , im not sure there is the place for these comments
<sn0> socrano and the 2nd link gives me: 5c19803a2a34996e68be96a279371b5d  kubuntu-7.04-alternate-i386.iso
<pitti> hmm, no spec for grumpy yet? /me creates one
<carlos> mvo: hi
<mvo> hey carl
<mvo> hey carlos
<carlos> mvo: could you take a look to https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/47280 ?
<ubotu> Launchpad bug 47280 in rosetta "Please add en_NZ "English (New Zealand)" to preferred languages list" [Medium,Needs info]  
<carlos> mvo: could you confirm/deny the comment about language-selector not doing the right thing with en_NZ?
<mvo> carlos: I have a look
<carlos> mvo: thank you
<pitti> cjwatson: do you still remember 57_allow_bus_virtual.patch in hal? I didn't find any reference to this upstream, and it does not apply to current gutsy's hal at all; what was that for?
<mjg59> Some input devices appeared to send stuff from BUS_VIRTUAL
<pitti> there is no "BUS_" at all any more
<carlospc> ts
<cjwatson> pochu: if you're in ubuntu-core-dev, sure; if not, it tends to be just as easy for a core-dev to do the merge as to review somebody else's merge, so I can do it
<cjwatson> pitti: that was for uinput devices brought up using mouseemu
<Hobbsee> hi cjwatson 
<cjwatson> hi
<cjwatson> finally caught up on this channel, ish
<cjwatson> pitti: include/linux/input.h still has BUS_VIRTUAL
<pitti> cjwatson: do you still have the equipment to verify that gutsy's hal DTRT onw?
<cjwatson> pitti: yes, once I get round to upgrading
<cjwatson> I have two such pieces of equipment in fact
<cjwatson> pitti: or you could install mouseemu
<cjwatson> oh, no, it was the power button, not mouseemu in general. OK, I only have one such piece of equipment then
<pitti> cjwatson: ah, can do; if it works, all is well?
<cjwatson> no, you need a system with a power button on the keyboard
<cjwatson> then (re)start mouseemu after gnome-power-manager starts
<cjwatson> then test whether the power button activates g-p-m
<pitti> hm, my iBook has a power button
<\sh> keescook, ping...the binfmt thingy you included in wine, does work on the cli but in nautilus not...I wonder if we should give wine a desktop file again and triggering the execution of .exe files.
<keescook> \sh: allowing wine stuff to get run without a +x bit is dangerous.  :(  I think nautilus needs to be patched to attempt to run +x files.
<keescook> it seems to do it correctly for elf only.
<\sh> keescook, well, I set the exe file to 755 and it works correctly on cli....but not with nautilus...
<keescook> \sh: right.  that's why I think it's a bug with nautilus.
<keescook> if you do the same with an ELF +x file, it works fine.
<davmor2> Query on Ubuntu-hwdb  Could this not be a first time install request.  That is to say after installation could it not popup a message similar to the restricted drivers manager,  that ask the user to take a couple of minutes to fill in the hwdb?
<\sh> keescook, and I have this bug report about it...so should we say: behaviour is correct, because nautilus is broken regarding running dos exe files?
<pitti> so it always checks MIME type apparently
<pitti> davmor2: feisty doesn't give such a notification
<pitti> davmor2: we disabled it for various reasons
* pitti waves to keescook 
* keescook hugs pitti
<davmor2> pitti:  Sorry I'm thinking for gutsy
<\sh> keescook / pitti: question is, should I bring back the .desktop file for mime type, as long as this bug is in nautilus?
<keescook> \sh: we need to involve the gnome upstream, I think.  I have a sense that it makes exceptions for ELF rather than +x files.
<pitti> \sh: I advise against it; it opens a large attack vector
<pitti> \sh: the other day we got a security@ubuntu.com mail that Ubuntu executes Windows virii
<pitti> (yes, wine is that good)
<pitti> and the strict 'save download stuff non-executable' vs. 'only run executable stuff' prevents accidental execution
<jsgotangco> heh
<\sh> pitti, I know...but should we then remove the binfmt as well? just because chmod 755 <exefile> ; ./exefile starts like a charm?
<pitti> which is a good thing to maintain, and a life saver at times
<iwj> seb128: Did you write up what came out of the disk full workshop anywhere ?
<pochu> cjwatson: that's good enough :) I want it since I'm packaging an app whose documentation is licensed under the GFDL, and I'm linking to it under /usr/share/common-licenses :)
<keescook> \sh: only +x files should be runnable (and adding a .desktop file for an exec format avoids that check)
<pitti> \sh: no, I think we should fix nautilus; I guess it isn't that hard
<ion_> http://winehq.com/  Compatible Application Database  Viruses
<\sh> ok..so I'll document it in the report and forget about that for now :)
<pitti> \sh: if there is a bug about that, please assign it to nautilus and perhaps milestone it
<seb128> iwj: I dumped the notes on https://wiki.ubuntu.com/BootLoginWithFullFilesystem
<pitti> so that final gutsy will actually work with wine
<\sh> k
<\sh> pitti / keescook : thx for your answers :)
<pitti> \sh: thanks for bearing with us *hug*
<keescook> :)
<pitti> \sh: the report about Windows viruses scared the hell out of me TBH
<\sh> pitti, well, all bug reports about wine are scaring the sh*t out of me ... I just had a nice discussion about wine @#winehq ... "I'll make wine brown/blue for ubuntu/kubuntu" "if you do that, I'll kick you out of the wine-network" ,)
<iwj> seb128: Ah, thanks.  For some reason my search for `Full' didn't find it.
<\sh> pitti, the last comment wasn't a joke, really
* iwj sets the url in LP.
<seb128> iwj: no problem, sorry I forgot to update the LP spec
<iwj> seb128: You say in the spec "Display a dialog on login explaining that the user needs to free some space and then restart his session".
<iwj> But we saw one of these.  Is it just the case that we need to improve the wording ?
<seb128> iwj: the window was a xterm with message printed to it, having a small GTK dialog would be nicer and that's not a lot of work
<iwj> seb128: I've fleshed the spec out a bit.  Let me know what you think.
<cjwatson> pochu: blink, Debian added the GFDL to common-licenses?
<elmo> cjwatson: yes
<cjwatson> wow
<seb128> iwj: looks good to me
<iwj> I'll set it to pending approval.
<seb128> good
<iwj> Hrm, I seem to have used the word `wossname' in UdevLvmMdadmEvmsAgain
<iwj> Results 1 - 10 of about 171,000 for evms documentation   Did you mean: emacs documentation
<Keybuk> that's a harsh suggestion
<Keybuk> though I'm not sure whether it's harsher on evms or emacs
<pochu> cjwatson: they did, as you can see in Debian #356447
<ubotu> Debian bug 356447 in base-files "/usr/share/common-licences: please add GFDL" [Wishlist,Open]  http://bugs.debian.org/356447
<cjwatson> pochu: have you actually read the bug you're citing? ;-)
<pochu> cjwatson: sorry, it's not correct
<pochu> cjwatson: see http://packages.debian.org/changelogs/pool/main/b/base-files/base-files_4.0.0/changelog
<pochu> cjwatson: and the other day, that bug was marked as "fix released" :)
<pochu> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=420599
<ubotu> Debian bug 420599 in base-files "please include GFDL in /usr/share/common-licenses (it's in policy" [Wishlist,Closed]  
<ogra> BenC, could you produce an additional -ltsp kernel based on that config for me ? http://www.mcquillansystems.com/config-2.6.20.9-ltsp-1
<ogra> i mean as a package we can use
<pochu> That was the right bug, sorry :)
<BenC> ogra: Only if you update it to 2.6.22-3 :)
<BenC> there's a lot of config changes between .20 and .22, I wouldn't know what to guess for ltsp for a lot of it
<ogra> i'll talk to jim then ...
<ogra> jammcq, we'll need a .22 config ... 
<jammcq> yeah, is .22 out yet?
<BenC> Anyone know if the cloop kernel module we have is actually used anywhere?
<BenC> jammcq: .22-rc1
<ogra> BenC, i'm fine maintaining the config ... how are custom packages handled, does the kernel team take that or do i have to take that as well ?
<ogra> i.e. how does the -lowlatency thing work 
<ogra> does ubuntustudio care for it ? 
<BenC> ogra: -rt and -xen are built as debian/binary-custom.d/ targets
<ogra> ok
<BenC> I send all bugs against those packages to the respective team
<ogra> but are built anyway on every kernel package build
<BenC> so I can do the same for ltsp
<ogra> ok
<ogra> thats fine
<BenC> need to let me know which architectures you want to build for, and supply a .config for each one
<ogra> ppc and i386 for now
<ogra> jammcq, do we want amd64 ?
<ogra> s/want/need/
<jammcq> hmm, dunno
<BenC> you can check debian/binary-custom.d/ in our git tree, and copy what we've done for xen/rt
<BenC> you'll have an empty diff file
<ogra> i actually had *one* user usig amd64 clients
<BenC> what all is changed for ltsp kernel?
<BenC> is it just reduction of modules, because I'm not sure we can justify an entire build just to build less modules
<ogra> BenC, no idea, but apparenly jims kernel reaches even the initramfs twice as fast as ours
<BenC> I'd be interested to know how, because our base kernel doesn't have much built into it :)
<ogra> if we're through the initramfs the 4.2 users already have the login screen
<ogra> yeah
<jammcq> BenC: yeah, it really doesn't make sense to me either.  but with ltsp-4.2, we can be at a login screen in 41 secs on this particular hardware. whereas with ubuntu, it's more like 94 secs
<pochu> cjwatson: that should close Bug #27924
<ubotu> Launchpad bug 27924 in base-files "include common documentation licenses" [Wishlist,Unconfirmed]  https://launchpad.net/bugs/27924
<cjwatson> I just saw the same thing, yes
<ogra> i got our ltsp down to boot in 1:30 on the e2300 by dropping the X detection (sadly i cant drop udev), while jims does it in 40secs
<BenC> really, how long is it before initramfs is started?
<BenC> I mean it should be just 1-3 seconds depending on hw
<ogra> jammcq, lets do more measuring with break=top/bottom
<ogra> that should give us initramfs timing
<jammcq> ogra: can you give that a try?
<ogra> will do
<jammcq> tanks
<BenC> jammcq, ogra: get back to me with configs, preferably to kernel-team@lists.ubuntu.com so we can review it...
<ogra> to bad i have to stopwatch :P now that the differences will be smaller
<ogra> BenC, oki
<cjwatson> pochu: uploaded, thanks
<keescook> the Debian maintainer of samba is looking for a contact for discussing merging of the ubuntu packaging deltas.  who would be the best person for them to talk to?  I was email since I touched samba last.  :)
<pochu> cjwatson: thanks to you :)
<Burgundavia> keescook: ajmitch might be a good person
<Hobbsee> keescook: or mvo
<keescook> Hobbsee, Burgundavia: okay, thanks.
<Hobbsee> you were the last to touch it
<\sh> jono, are you the whole week at linuxtag?
<luisbg> jono, lucky dude
<jono> \sh: yep
<jono> luisbg: being at LinuxTag all week?
<\sh> jono, cool...let's have some beer then ;)
<jono> \sh: got it :)
<luisbg> jono, I wish... UDS seamed short for me, need more :P
<racarr> I think we would have all been zombies if it had lasted much longer.
<jono> hehe
<luisbg> racarr, happy zombies, heh
<jono> I am pretty shattered
<luisbg> even though watching jono dance the last night, made me a creepy zombie
<jono> luisbg: haha
<jono> luisbg: was a fun night
<luisbg> jono, yeahh, you and juanje ruled the place, and the rest of us got girls
<luisbg> can't ask for anything else
<Hobbsee> heh
<jono> heh
<luisbg> luckily enough my room mate joejaxx, had left for his airplane at 4am
<\sh> jono had kwwii in his arms...that was just enough for me to lol ;)
<luisbg> \sh, LOL!
<luisbg> are there pics of that?
<jono> I hope not
<jono> :P
<iwj> Keybuk: Did you want to cast an eye over https://wiki.ubuntu.com/UdevLvmMdadmEvmsAgain ?  I've set it to Review.
<sladen> does anyone have non-IRC contact details for Corey Burger
<iwj> "Corey Burger" <corey.burger@gmail.com>
<Keybuk> iwj: thanks, has everyone else in the bof (kees, etc.?) cast their eye over it as well?
<Hobbsee> then again, we wouldnt be surprised if jono managed to do ohter crazy things.
<iwj> Says my mailbox, quoted from the headers of a post to u-d-a.
<iwj> Keybuk: No.
<pitti> sladen: https://launchpad.net/~corey.burger has an email
<Keybuk> iwj: that would be worthwhile, to make sure bases and concerns are covered
<keescook> Keybuk: reading now...
<luisbg> sladen, when is the second video of UDS coming out? is it coming with kino insults too?
<racarr> Hobbsee: Like Elk a Buntu.
<Hobbsee> exactly
<iwj> Keybuk: Right.
<Hobbsee> racarr: well, i never found jono in our hotel room, so i dont *think* anything like that happened
<Keybuk> one should leverage ones co-workers wherever possible ;)
<jono> Hobbsee: heh
<jono> Hobbsee: certainly not
<jono> :)
<iwj> We didn't make a list of people in the bof, but definitely Kees and Fabio seem like they ought to have opinions.
<Hobbsee> unless they were in jono's room, of course :P
<racarr> Jonos refrigerator was broken and...
<sladen> luisbg: as soon as I find my wallet or some cash etc.
<sladen> pitti: yeah, phone number type thing
<keescook> Keybuk, iwj: so, the "make utils build nodes" solution is the decided direction again?  Also, I don't see any mention of building some kind of simple test case harness.
<keescook> I think at least having a base set of tests could be used to have a common reference if people encounter races
<Keybuk> it's certainly one valid direction
<Keybuk> I think it's worth having a kernel person look at the "fix the damned kernel" direction as well
<keescook> as the BoF closed, it sounded like the patch-the-kernel direction was "final" solution?
<keescook> also, the mention of a system-wide scan lock file worries me, since the notes from the BoF basically said "a global lock was tried and didn't work"
<Keybuk> there's two weeks available for research into which is best before the spec is approved
<Keybuk> (since the approved spec should arguably document all valid approaches discussed, including the udevsend one, and explain why they were rejected and why the favoured solution was chosen - backed up by evidence)
<iwj> keescook: The global lock doesn't work because the device node creation was threaded back and forth through udev, meaning that you had to run different things at the same time with the lock held.
<iwj> Tests are no good for races because the very nature of races is that they come and go.
<micahcowan> cjwatson, thanks for uploading the gawk fix :)
<cjwatson> micahcowan: you're welcome, sorry it took so long
<cjwatson> I'm looking into getting a kernel person to investigate this
<cjwatson> this> udev lvm/mdadm/evms/blah
<iwj> Keybuk: I don't think the kernel is buggy.  How is it buggy for it to report udev events for the snapshot-origin device that lvm makes ?  It's not.  But we don't want to run vol_id on it.
<keescook> iwj: race conditions can have tests written for them; it's just a matter of understanding where the race is and getting a wedge into it to expand the race.  I'm not saying it's easy, but I'm suggesting that having _any_ set of test cases is better than none, since then everyone discussing a problem has a common frame of reference.
<cjwatson> even if it turns out not to be a kernel issue, this set of userspace code is one that we'd like to have the kernel team take on, medium-term
<iwj> keescook: Well, yes, that might be worth it if we had (a) a clear idea of what the races are and (b) weren't proposing to upend the design.
<cjwatson> since they interact so much
<Keybuk> iwj: it's arguably a kernel wishlist bug for it to support not reporting
<iwj> cjwatson: I want to reduce that interaction, to some extend.
<iwj> s/end/ent/
<Keybuk> and since we have the source code to the kernel, it's an equally valid place to fix the bug as in udev or lvm or devmapper, etc.
<Keybuk> if it turns out that fixing it in the kernel has extra benefits than userspace, it shouldn't be dismissed as an option out of hand
<Keybuk> (likewise, it may turn out to have particular downsides)
<iwj> Well, my well-known position is that it's crazy kernel philosophy from upstream that has broken all of this stuff and I'd like to avoid depending any more on kernel stuff than is necessary.  AIUI upstream kernel opinion is to put things in userspace too if possible.
<iwj> Using the kernel as a complicated stateful IPC facility seems wrong.
<iwj> Anyway, for synthetic devices only the tool which is creating and managing the device knows whether and when it ought to be scanned so it ought to be in control of that scanning.  This means that all of the kernel events for those devices are not really interesting.
<cjwatson> iwj: independently of that, the bottom level of userspace is an area where I think it's appropriate for the kernel team to get involved.
<iwj> cjwatson: Oh, absolutely.
<iwj> I think Kyle was in the bof and might want to take an interest.
<Keybuk> iwj: since the kernel *is* providing the state facility for devmapper devices, I'm not sure that one can simply dismiss the option of using it to add an extra state variable out of hand
<Keybuk> and I would really like to see it have at least the minimum investigation and noted in the spec
<Keybuk> if it's rejected after consideration, that's fine
<tkamppeter> pitti, hi
<pitti> hey tkamppeter 
<tkamppeter> pitti, you have been in Sevilla?
<adilson> tkamppeter: Grande Till! :) Here's Adilson, ex-Conectiva, now Canonical ;)
<tkamppeter> oi, adilson, como vai?
<pitti> tkamppeter: yes, I have been
<tkamppeter> Everyone goes from other distros to Ubuntu.
<tkamppeter> pitti, was there much talk about printing?
<tkamppeter> Did someone ask for me?
<pitti> tkamppeter: not really, except for a rough idea how to create a print server OOTB for the server project
<pitti> and a quick discussion with Jani about system-config-printer
<tkamppeter> Yes, I have seen the latter in the event schedules and in the Blueprint I have seen that your conclusion was to mark it obsolete.
<tkamppeter> So printerdrake will (I hope) be the solution for Gutsy?
<pitti> well, Jani did apparently
<pitti> situation hasn't changed, we need someone to port it to Ubuntu and work on the UI
<iwj> Keybuk: Does `Alternative approach - Publication list stored in kernel' at the bottom of the wiki page describe the kind of idea you had in mind ?
<pitti> s-c-printer's UI needs work as well, but at least it already works in Ubuntu
<tkamppeter> And will the GUI replacement for printerdrake now really happen? This was what blocked printerdrake and dependent features.
<pitti> it won't magically happen :) do you want to adopt that?
<Keybuk> iwj: only if it documents why the alternative approach was rejected, explaining why the suggested approach is better
<tkamppeter> What about this "mpt" who is mentioned on https://blueprints.launchpad.net/ubuntu/+spec/printerdrake
<pitti> tkamppeter: he can design a UI, but not implement it, nor do the initial porting
<pitti> well, if we have a live CD with a working printerdrake, we do not need to port the current version to Ubuntu (which is difficult because of exactly those parts we want to get rid of anyway)
<iwj> Keybuk: Err, since this is your alternative approach rather than mine, I was asking you whether I had captured your proposal.
<tkamppeter> So we need someone who does the GTK programming? I did not really program GTK stuff. The main window of printerdrake is copied from userdrake, and in gnome-cups-manager I only replaced text.
<cjwatson> tkamppeter: we can't target printerdrake for gutsy unless there is a realistic prospect of the necessary dependencies being done
<Keybuk> iwj: no.  I suspect it may be easier for me to document my alternative approach in the spec, and leave it up to the drafter/assignee to decide on one before it is approved
<Keybuk> iwj: it's also worth documenting the udevsend approach as well (send synthetic uevents) and why that was rejected
<Keybuk> since that was a useful piece of insight it would be helpful to have written down, so future generations of ubuntu developers don't have to discover it for theirselves
<Keybuk> meh, themselves
<pitti> seb128: FYI, I just wrote https://wiki.ubuntu.com/CrashReporting, I hope I got it alright now
<seb128> pitti: looking
* seb128 kicks xchat-gnome
<seb128> should strip the "," after an url ;)
* dholbach hugs seb128
<pochu> seb128: irssi ftw :)
* pitti pats xchat for doing that right :)
* seb128 hugs dholbach
<tkamppeter> pitti, has the crash retracing been shut down? I tried to retrace bug 114637, but the retracer does nothing else then removing the tag and never posts the retrace.
<ubotu> Launchpad bug 114637 in gs-esp "[apport]  gs-esp crashed with SIGSEGV" [Undecided,Needs info]  https://launchpad.net/bugs/114637
<pitti> tkamppeter: if it removed the tag, it's running; let me look into the log
<seb128> pitti: shouldn't the anonymous point be part of the design? 
<pitti> seb128: hm, you really want people to file anonymous bugs?
<pitti> seb128: AFAIR we didn't talk about that point, but I'm happy to discuss it now
<seb128> pitti: no, I was saying it should be moved to "Design" section rather than "Rational"
<pitti> ah, I see
<iwj> Keybuk: Right.
<pitti> tkamppeter: aah: report file does not contain required fields: CoreDump Package ExecutablePath
<pitti> tkamppeter: presumably this was sent as a 'reduced' crash report without core dump
<pitti> tkamppeter: that's fixed in gutsy btw, it won't offer that option if the stack trace is useless
<seb128> pitti: why "Create Launchpad users which control access to the bug, split by main/restricted and universe/multiverse."
<seb128> pitti: can't we use ubuntu-core-dev and ubuntu-dev?
<tkamppeter> So there were some options in the reporting wizard to reduce the report which made it unusable?
<tkamppeter> So should I reject it? What should I ask the user to do when this crash occurs again?
<pitti> seb128: anonymous> hmm, I can move it there, but the text gives a rationale about using Malone
<pitti> seb128: no, that would cause all team members to get email for all crashes
<seb128> pitti: k, I'm not spec approver, it just looked weird to have implementation details there
<pitti> tkamppeter: rejecting is fine; if it happens again, apport will file a new bug anyway
<pitti> tkamppeter: so don't hesitate to reject useless crash bugs
<pitti> seb128: ok; if it confuses you, I'll move it
<seb128> pitti: k, that's what I asked during the BOF outside, any reason ubuntu-core-dev can't browse private bugs?
<pitti> seb128: primarily a Launchpad design issue, AFAICS
<seb128> pitti: your way looks like a good workaround but I think ubuntu-core-dev should be allow to browse any private bug which is no !security
<seb128> k
<pitti> seb128: I tend to agree; well, with that spec this is essentially what happens
<seb128> the specs looks fine to me
<pitti> seb128: I just updated it to move the reasons to design
<seb128> I would prefer having ubuntu-core-dev and ubuntu-dev able to read their respective set of bugs
<seb128> but the group way would work fine
<seb128> and doesn't make use block on launchpad change
<seb128> s/use/us
* pitti taps foot, waiting for editmoin to actually finish uploading
<pitti> ah, now
<pitti> seb128: ok, thanks for review; so I move this to pending approval
* pitti hugs seb128
* seb128 hugs pitti back
<robertj> https://blueprints.launchpad.net/ubuntu/+spec/simplesamba would benefit by having a drafter assigned to it, is there some process by which people are assigned as drafters or is it possible for specs to die awaiting a drafter?
<pitti> robertj: not a defined one; if you are interested in it, just update the spec and mail ubuntu-devel@ about it if you want to work on it
<Hobbsee> any idea what time libraries usually open?
<robertj> pitti: well I wrote the initial draft, so I don't know that I have anything more to add
<pitti> robertj: ah, I see; could you please clean it up a little? the current 'design' section is actually 'implementation', and there should be a design section which describes the changes at a more abstract English level, together with some rationale
<pitti> robertj: but feel free to set yourself as a drafter, you wrote it after all
<pitti> robertj: I would also appreciate some more detail in the use cases: 'log in' -> from where to where, which OS, etc/
<pitti> s_/_?_
<luisbg> hello ompaul 
<robertj> pitti: will do, I'll update it now
<ompaul> luisbg, hi there
<luisbg> ompaul, thanks for the reply
<luisbg> to the mail a few days back
<ompaul> np
<luisbg> ompaul, how was your trip back?
<ompaul> good - we may be a bit ot for here :)
<ompaul> ubugflu kicked in today
<Treenaks> ompaul: same for me
<Treenaks> ompaul: I blame the aussies, they didn't get it
<Treenaks> ompaul: which means they must be the source :)
<ompaul> Treenaks, no they were just in a clean upstream
<ompaul> Treenaks, iirc its all jono's fault :)
<ompaul> or was that the ducks
<Treenaks> ompaul: duck flu? mmmh
<Hobbsee> mmm...ducks
<ompaul> a duck flu over the cuckoos nest?
<Treenaks> Hobbsee: oh no, you're a duck lover too now?
<Hobbsee> Treenaks: nah.  just the ducks are good for giving you the plauge.
<Hobbsee> *plague
<Treenaks> Hobbsee: isn't it very late @ your timezone?
<Hobbsee> Treenaks: yes.
<Treenaks> (or _very_ early?)
<Hobbsee> Treenaks: almost 5am
<Treenaks> Hobbsee: ugh..
<Hobbsee> Treenaks: rather.
<geser> Hobbsee: are you still living on europe time?
<Hobbsee> geser: sort of.  mostly.
* Hobbsee should really just move to europe.
<Mithrandir> Hobbsee: you should!
<Treenaks> yes!
<Hobbsee> Mithrandir: i wish!
<Mithrandir> Hobbsee: just finish that pesky university and move here
<Hobbsee> unfortunately, i dont have the resources to do it, and i've only done 1/2 of my degree.  and it's a little hard to take up at another uni in another country
<Hobbsee> hehe
<gnomefreak> pitti is apport purposely not giving the coredump on crashes?
<iwj> Keybuk: I've added a paragraph at the bottom about why udevsend was wrong and why it made the udevd code big too.  If you'd like to write up your alternative approach I'd be happy to pass it around to kernel types and generally write up why we adopt it or not.
<pitti> gnomefreak: you mean writing a core file to cwd?
<pitti> gnomefreak: it should work if you set your ulimit appropriately
<gnomefreak> to the crash file
<pitti> gnomefreak: oh, it definitively should appear there (unless it's a Python crash)
<gnomefreak> mine is leaving off coredump and the traces
<gnomefreak> it was a listen.py crash
<pitti> weird; in feisty or gutsy?
<gnomefreak> both
<pochu> gnomefreak: feisty is python :)
<pitti> ah, as I said, no coredump necessary for Python crashes
<pochu> err, listen is python
<pitti> pochu: I'm still pondering that equation
<pitti> ah, heh :)
<gnomefreak> pochu: yeah i got that. nothing else has crashed yet so i cant tell if its just that
<pitti> pochu: http://uncyclopedia.org/wiki/Ubuntu -> '# eplacing everything written in C with a Python alternative, examples include GCC (Gnome Cheesecake Compiler)'
<bddebian> Heya
<pochu> pitti: lol :)
<Keybuk> pitti: that reminds me, I still own ubuntucult.org
<pochu> hi bddebian!
<bddebian> Hello pochu
<robertj> pitti: what metapackage do you depend on if you want to be in all the -desktops?
<pochu> robertj: ubuntu-desktop?
<robertj> pochu: yes, is there one that ubuntu-desktop and kubuntu-desktop and xubuntu-desktop depend on but server does not?
<gnomefreak> ubuntu-minimal iirc
<Mithrandir> robertj: no
<robertj> pitti: ok https://wiki.ubuntu.com/SimpleSambaIntegrationSpec has been revised
<cjwatson> robertj: packages that should be in all the -desktop metapackages should be added to the Ubuntu desktop seed and then that change should be 'bzr merge'd to all the others
<ajmitch> morning
<joejaxx> Good Morning ajmitch 
<zul> morning ajmitch 
<Hobbsee> hi ajmitch 
<ajmitch> keescook: I got that forwarded email about samba, were you planning to merge 3.0.25?
<keescook> ajmitch: I hadn't done 3.0.25, just the debian/ubuntu merge.  I'm actually doing some security updates for it too.
<ajmitch> ok, from what I saw 3.0.25 got fixes for 3 CVEs just in time for release :)
<keescook> perfect, yeah.  those are the ones I'm building atm.
<ajmitch> keescook: I'll look over what samba changes we carry & try & talk to the debian guys about it later
* ajmitch hadn't touched it for a little while
<keescook> ajmitch: very cool.
<ompaul> Treenaks, mind if I pm?
<Hobbsee> ompaul: he bites.
<ompaul> Hobbsee, naa 
* ompaul waves at pkl_ 
<pkl_> ompaul: hello
<BenC> elmo: Build-dependencies for linux-restricted-modules-2.6.20 could not be satisfied.
<BenC> s/elmo/E/
<ion_> :-D
<BenC> anyway to get apt to be a little more verbose about what it can't satisfy this?
<BenC> ion_: :P
<ion_> Hmm. I commented the main repo out from sources.list and tried sudo apt-get build-dep linux-restricted-modules-2.6.20;
<ion_> E: Package libqt3-mt-dev has no installation candidate
<ion_> E: Failed to satisfy Build-Depends dependency for linux-restricted-modules-2.6.20: libqt3-mt-dev
<jovans> will be ext4 integ. in gutsy?
<mjg59> No
<mjg59> It's not usefully stable yet
<jovans> hm
<jovans> and reiser4 no hope to come in the future
<mjg59> When it's mainline, we'll support it
<jovans> but ext4 sure?
<mjg59> ext4 currently gets you relatively little over ext3 unless you're talking about multi-terrabyte filesystems
<jovans> but the performance is much better on ext4 than on ext3 and the fastest was reiser4
<jovans> http://www.linuxinsight.com/first_benchmarks_of_the_ext4_file_system.html
#ubuntu-devel 2007-05-16
<jovans> reiser4, which has the best performance in some tests
<mjg59> ...
<mjg59> The biggest gap there is 1.5MB
<mjg59> Or less than 3%
<mjg59> Note that most of those graphs don't start at 0
<bhale> faster is nice if you dont care about integrity of your files
<jovans> yes but for first impressions
<jovans> i am using feisty with reiserfs i think it's v3
<mjg59> jovans: The current recommendations for Linux filesystems are to use xfs if you need very large filesystems, and otherwise to use ext3
<jovans> ok
<jovans> and jfs not recommanded?
<mjg59> I've discussed this with filesystem developers, and they agree that ext4 is not appropriate for use yet unless you're developing it
<mjg59> jfs has some management tools that you may find useful, but otherwise I don't think there's an especially good reason to choose it
<jovans> ok
<jovans> than you
<jovans> for ur comments
<jovans> ;)
<poningru> I had a question
<poningru> when the ubuntu installed dells go out
<poningru> are canonical's servers ready to handle the load/bandwidth?
<psusi> BenC: ping
<BenC> psusi: yo
<psusi> BenC: hey... I was looking at our devmapper package today and it seems that we diverged from debian some time ago... I think you were the last one to modify it, so I was wondering if you could shed some light on the reasons for diverging
<psusi> I'm wondering if we can't sync with the new debian version
<psusi> and what the process for that is
<BenC> err, I can't remember
<BenC> psusi: merges.ubuntu.com is a good place to start
<psusi> oh yea, another question I had was, why does the version of the package start with 2:?
<Amaranth> someone messed up with versioning previously
<psusi> don't think I've seen a version with a : in it before
<Amaranth> or did a downgrade
<psusi> ohh
<Amaranth> lots of packages have that
<Amaranth> can't remember the name of it now :P
<psusi> so like... it was 1.2.3 and so to downgrade back to 1.2.1 you had to prefix it with a 2: to make it higher?
<BenC> psusi: X: is an epoch version, the X: part doesn't show, but it gives it newer version than anything with > X, and no X
<Amaranth> 1:1.2.1 is newer than 1.2.2
<Amaranth> well, sorts higher
<psusi> hrm... why would mom not be able to generate a diff3 merge of a file?  showing it as C*?
<psusi> hrm... so our package lets udev create the devnode, but in debian they don't?
<BenC> psusi: dm/lvm/mdadm/udev is scary stuff, run while you still can
<ajmitch> scary stuff labelled with 'here be dragons'
<psusi> lol
<psusi> too late... I'm already involved with it because of dmraid
<psusi> which is the most scary branch of that family
* Amaranth makes a note to not upgrade udev
<psusi> would also be nice if the mirror dm target were documented somewhere
<psusi> I was trying to figure it out from the kernel sources today because it looks like dmraid passes it a sync or nosync option, but afaics the kernel supports no such options
<psusi> I'm used to using tortoiseSVN on windows to do three way merges... how can you do a three way merge in linux?
<tepsipakki> good morning
<tepsipakki> who is wearing the archive admin hat today?
<pitti> Good morning
<Fujitsu> Hi pitti.
<\sh> moins...
<Mithrandir> hiya pitti
<\sh> pitti, can you read https://bugs.launchpad.net/bugs/91636 and comment on it...now it's going into a "move between two packages" report, and I don't want to argue with the people...can you, as our security "officer", comment on the topic "why whine shouldn't deliver a .desktop"  
<ubotu> Launchpad bug 91636 in wine "Mimetype error: *.exe => the filename indicates "executable", while the contents indicated "DOS/Windows executable"" [Undecided,Confirmed]  
<\sh> s/whine/wine/
<Treenaks> \sh: well, some .exes are mono executables, right?
<pitti> \sh: "whine" was right :-P yes, will do
<\sh> pitti, thx :)
<\sh> Treenaks, tbh, I don't have any clue how mono apps are started...but reading /usr/bin/tomboy I can see, that those exes are started via "exec mono tomboy.exe" e.g.
<pitti> \sh: hmm, this doesn't look at all related to our discussion yesterday?
<pitti> \sh: mono has a binfmt-misc entry as well
<\sh> pitti, the thing is, indeed, that +x .exe files can be started via cli, but not via nautilus...kees removed the .desktop file from whine in favour of binfmt...
<\sh> and I think because of security...so re-adding the .desktop gives us the possibility to start .exe files via nautilus, but gives you the same pain as before
<Fujitsu> Why won't Nautilus execute them now?
<pitti> \sh: hm, it looks as if it only gives a confirmation question? the bug doesn't speak about not being able to run them?
<pitti> (or does it?)
<Treenaks> because nautilus is horribly broken atm (at least, for me :)
<\sh> pitti, your "virus bug" is https://bugs.launchpad.net/ubuntu/+source/wine/+bug/85338
<ubotu> Launchpad bug 85338 in wine "Security - single click trojan risk" [High,Fix released]  
<\sh> pitti, I can't run them...(feisty)
<\sh> Cannot open /home/shermann/windows/wrar362d.exe: No application suitable for automatic installation is available for handling this kind of file.
<Treenaks> Fujitsu: when I try to open a remote share, it dies, when I try to kill, it'll SIG11 all over itself until I kill -9 it... and restarting doesn't fix it
<pitti> \sh: hm, so this is another bug in nautilus then, or the associated MIME types
<ajmitch> hey pitti 
<pitti> hi ajmitch 
<slomo> should be a bug in shared-mime-info then
<pitti> \sh: ah, that's not the message that is described in the bug
<\sh> pitti, I think it's still dapper/edgy they are talking about
<pitti> ah, I see
<\sh> but regarding the talks from yesterday on #winehq, we have to protect the users from wine, just because it's in pre-alpha state (remembering the words of an upstream dev) ;)
<Fujitsu> Is it ever likely to be in a non-prealpha state?
<\sh> Fujitsu, they said, wine is nothing for "john user" 
<Fujitsu> Which is why we should follow the advice of ubuntuforums' users and install it by default, don't you think?
* Fujitsu runs away, terribly fast.
<\sh> Fujitsu, tbh, I don't read the webforums, just because I love my life as it is, and I don't want to bang my head on my desk, everytime I read "install wine by default" or "use automatix and your pain is going away"
<Lathiat> we should preinstall windows programs
<Lathiat> Ubuntu 7.04 bundled with Microsoft Office 2007
<Lathiat> [ Buy now ] 
<Fujitsu> Lathiat: Right.
<\sh> but anyways...I'm right now totally confused what to do...I would prefer the "learning through pain" method...
<Fujitsu> \sh: The automatix crap has fortunately almost vanished.
<dholbach> good morning
<\sh> moins dharrigan 
<\sh> aeh dholbach 
<dholbach> hey \sh
<\sh> dholbach, do I see you at linuxtag? :)
<Mithrandir> Fujitsu: and it'll become even less useful with the new update-manager fixes. :-)
<dholbach> \sh: yep :)
<Fujitsu> Mithrandir: What's happening now?
<Mithrandir> Fujitsu: the plan is to tell the user "you have used software which we know are going to cause severe problems when upgrading, sorry, we can't upgrade this system, please reinstall".
<Fujitsu> Oh, good.
<\sh> dholbach, cool :) btw..congrats to your vote :)
<dholbach> thanks \sh :)
<Fujitsu> Wow, impressive Yes:No ratio that you have there, dholbach.
<dholbach> I was very happy with it too
<Mithrandir> hiya elkbuntu 
<elkbuntu> hiya
<elkbuntu> hadnt realised i was logged in under the alt nick :-/
<dholbach> doko: ajmitch is also having trouble doing the pygojbect and pygtk merges - do you know of any changes that might have broken py-dbg?
<dholbach> http://pastebin.ca/490767
<ajmitch> the files appear to be there & in the right place, but I'm getting things like ^^
<doko> dholbach, ajmitch: which package does have pyexpat? is the pyexpat-dbg package installed?
<ajmitch> python2.5-dbg
<bryyce> seb128: btw, found a quirky but irritating bug when switching workspaces - kde apps start flashing on the window list (bug 114923)
<ubotu> Launchpad bug 114923 in gnome-panel "window list highlights kde apps when switching workspaces" [Undecided,Unconfirmed]  https://launchpad.net/bugs/114923
<seb128> bryyce: that's a duplicate ;)
<seb128> bug #78511
<ubotu> Launchpad bug 78511 in libwnck "Gnome-panel flashing for kde apps on workspace change" [Low,Confirmed]  https://launchpad.net/bugs/78511
<bryyce> ahh, I hadn't spotted that one
<seb128> not easy to know
<bryyce> yup, that's definitely it.  cool
<seb128> the workspaces, tasks list, etc are often libwnck
<seb128> I've marked it duplicate
<bryyce> yeah, wasn't really even sure what to search on
<doko> ajmitch: python2.5-dbg doesn't install in site-packages
<ajmitch> hm right
<ajmitch> so I have /usr/lib/python2.5/lib-dynload/pyexpat.so and /usr/lib/python2.5/site-packages/_xmlplus/parsers/pyexpat.so
<ajmitch> first is owned by python2.5, the other by python-xml
<doko> so you should have a b-d on python-xml-dbg as well
<doko> ?
<doko> or build-conflict with python-xml?
<ajmitch> this was built in pbuilder, so probably the former
<ajmitch> though after installing p-x-dbg, I now get further interesting errors
<ajmitch> like ImportError: /usr/lib/python2.5/site-packages/apt_pkg.so: undefined symbol: Py_InitModule4_64
<ajmitch> why it'd even look at apt_pkg is beyond me
<doko> is python-apt-dbg installed?
<ajmitch> I just installed it, and I'm down to the single error
<ajmitch> ImportError: /var/lib/python-support/python2.5/gtk-2.0/gobject/_gobject_d.so: undefined symbol: Py_InitModule4_64
* ajmitch goes to recompile python-gobject for fun
<bryyce> Mithrandir, would you mind bumping a post of mine in the moderation queue?  I posted a note about the xserver 1.3 upload but hadn't become a member of the list yet, so it's hung up.
<Mithrandir> bryyce: the list = ubuntu-devel or some other list?
<bryyce> yes right
<Burgundavia> bryyce: -devel or -devel-discuss?
<bryyce> ubuntu-devel
<Burgundavia> I can clear the latter but the former is somebody else
<Treenaks> bryyce: I'd like to see a (test) version of the xserver-xorg-video-ati with http://gitweb.freedesktop.org/?p=xorg/driver/xf86-video-ati.git;a=commit;h=3828237200fc16d4d32664fb8358950c213d4897 applied -- I think it might fix bug 20283 (finally..)
<ubotu> Launchpad bug 20283 in xserver-xorg-video-ati "[X700]  Really bad sync on HP NW8240" [Medium,Confirmed]  https://launchpad.net/bugs/20283
<Mithrandir> hm, the password isn't what I've saved in my browser.
<StevenK> doko: Do you mind if I borrow/steal some of your merges, like ntp or libidl?
<Mithrandir> bryyce: sorry, I thought my password for the ubuntu-devel moderation queue was correct, but apparently it's not.
<bryyce> Treenaks: unfortunately fglrx is horribly broken with xserver 1.3 presently
<Treenaks> bryyce: that's why it's a patch for radeon/ati
<bryyce> Treenaks: oh ok, I'll take a look at it
<bryyce> is there a LP bug for this?
<Treenaks> bryyce: yes, 20283 (as stated above)
<bryyce> Mithrandir: ok no prob, guess I'll wait for mdz
<bryyce> Treenaks, oh right, you did.  Okay my brain is mush, I'm going to bed.
<Treenaks> bryyce: ok :)
<Tonio_> hi :)
<mneptok> Tonio_: 'lu!
<doko> StevenK: please go ahead!
<ajmitch> ok, no change on rebuild
<ajmitch> hey mneptok 
<mneptok> hey hey
<mneptok> waznoo ajmitch?
<StevenK> doko: Thanks!
<dholbach> gpocentek: will we get the new goffice/gnumeric? :-)
<ajmitch> mneptok: fighting packages :)
<mneptok> ajmitch: i said "new" ;)
<StevenK> Mithrandir: Got a sec so I bounce an idea off of you?
<Mithrandir> StevenK: shoot
<StevenK> Mithrandir: xbitmaps is listed as a manual merge - I've done it, considering the only benefit I can see makes the patch on patches.u.c fall to nearly nothing, do you think it's worth it?
<Mithrandir> EPARSE; I'm not sure what you're asking.
<StevenK> Mithrandir: Sorry, I ought to be clearer.
<StevenK> Mithrandir: Okay, so xbitmaps is listed as a manual merge. I've done it, but the only benefit I can see is it makes the patch on patches.u.c to be very small. Do you think it's worthwhile to upload it?
<tepsipakki> xbitmaps is one of 23 xorg packages of which we have a different tarball
<Mithrandir> ah
<StevenK> Yes. The tarball is different, but contains the same files.
<Mithrandir> I don't see why it wouldn't be, if you've already spent the effort.
* StevenK nods.
<jdub> seb128: dude, i am so happy to hear that a whole trilogy of hollywood films will be made about your life!
<dholbach> jdub: link? :)
<seb128> jdub: what?
<jdub> http://www.smh.com.au/news/film/ah-ah-ah/2007/05/15/1178995158803.html
<seb128> ah ah ah ;)
<dholbach> hahaha :-)
<Chipzz> jdub: is there a way to see older entries that scrolled of planet (gnome)?
* seb128 hugs jdub
<jdub> Chipzz: no, but you can search for them with the custom google search thingy
<jdub> seb128: :-)
<Chipzz> jdub?
<gpocentek> dholbach: of course! ;)
<dholbach> gpocentek: rock and roll
<dholbach> gracias
<dholbach> doko: do you know of any plans to have the pydbg changes in Debian too?
<doko> dholbach: they already are
<doko> still needs to be announced
<dholbach> doko: oh? so it's "just a matter of bringing our changes into debian too"?
<slomo> and waiting ages until all million NEW packages are processed ;)
<doko> dholbach: exactly
<dholbach> that's good news
<dholbach> the merges are somewhat painful if we'd have to do them every now and then
<fierycleric> hi, how can i build a package with different configure flags?
<gnomefreak> fierycleric: #ubuntu-motu might be better place to ask but alot of packages (all ive ever dealt with) has the config options in the debian/rules file
<fierycleric> thanks ive RTFM now and found what i was looking for :) .... whats #ubuntu-motu  for?
<gnomefreak> the place to ask questions getting help with packaging
<fierycleric> i am there... .:)
<elmo> I thought like, any laptop in the world, ever - worked with vesa?
<Mithrandir> there's a bug in the VESA driver in feisty which makes it fall over on some machines, like some ATI machines.
<Mithrandir> iirc
<elmo> Mithrandir: yeah, that's what I'm seeing
<elmo> and for bonus points the wired network doesn't seem to work either - this is just wintastic
<TheMuso> Mithrandir: Ok to do your ccid merge for universe?
<Mithrandir> TheMuso: please.
<tepsipakki> the bug is in the server
<tepsipakki> how can I find out if other packages build-dep on a package? grep-dctrl seems cryptic, even the examples don't work
<Mithrandir> checkrdepends can do it
<Mithrandir> unsure if that's packaged
<elmo> apt-rdepends works and is packaged
<tepsipakki> thanks, I'll try that
<Gman> hey jono
<jono> hey
<jono> hows things Gman?
<jono> Gman: you over at GUADEC?
<Gman> yeah
<Gman> hopefully
<jono> Gman: good stuff :)
<Gman> should be a whole bunch of fun
<tepsipakki> E: Reverse build-dependencies are not supported
<tepsipakki> hmh
<StevenK> Yes, you can't ask "What packages Build-Depend on this one"
<pitti> tepsipakki: what do you need? I can look it up in the DC
<tepsipakki> pitti: I need to find out what packages build-dep on xutils/xlibs-dev/xbase-clients
<seb128> tepsipakki: use grep-dctrl
<tepsipakki> seb128: I tried ;)
<siretart> tepsipakki: alias revbuilddeb='grep-dctrl -F Build-Depends -s Package $1 -n /var/lib/apt/lists/*_Sources'
<pitti> tepsipakki: I copied the script to http://people.ubuntu.com/~pitti/scripts/checkrdepends
<tepsipakki> siretart: ah, that could work
<tepsipakki> pitti: thanks
<pitti> tepsipakki: see /query, but may be best to run that script yourself
<seb128> tepsipakki: http://people.ubuntu.com/~ubuntu-archive/germinate-output/gutsy/rdepends/xorg/xutils also
<tepsipakki> seb128: whow
<tepsipakki> -h
<seb128> tepsipakki: "* Reverse Build-Depends:" is likely what you want
<tepsipakki> seb128: that's right, bookmark added
<tepsipakki> ok, all those that have reverse build-deps on xlibs-dev also depend on the correct package (like "libx11-dev | xlibs-dev"), so I think xlibs-dev can be dropped.
<tepsipakki> same for reverse depends
<pitti> tepsipakki: right, checkrdepends doesn't handle alternatives
<pitti> tepsipakki: but not all
<pitti> tepsipakki: I just ran melanie -n -R (from dak) which does respect alternatives
<pitti> tepsipakki: http://paste.stgraber.org/906
<pitti> tepsipakki: the hppa ones can be ignored, it's hopelessly out of date anyway
<pitti> tepsipakki: this check was on feisty though, so the build deps might be fixed in gutsy
<tepsipakki> ok, germinate only lists main, right?
<pitti> I'm not sure, but probable
<pitti> e. g. kmplayer still b-deps on xlibs-dev without alternative
<tepsipakki> yeah.. there are a lot of them.. I'll check those
<pitti> tepsipakki: only ~ 10, would be easy to fix them if you want to get rid of it
<pitti> merging them with Debian might help, too
<tepsipakki> I'll see what can be done
<pygi> hi hi folks
<tepsipakki> grrr
<tepsipakki> bbdate merge was sloppy
<tepsipakki> meaning that the changes to build-deps were dropped. I'll fix that
<tepsipakki> ok, wmacpiload/wmbatteries/wmfortune/xqbiff/xreverse/squeak-vm have all been removed from debian, I guess
<tepsipakki> so they should be removed from ubuntu too, right?
<ogra> no !!!
<StevenK> Heh
<tepsipakki> :)
<ogra> not squeak at least
<ogra> we're maintaining our own package here
<tepsipakki> ogra: ok, in that case I'll update it
<StevenK> Oh yes, I can picture xqbiff having, ohhh, no users at all!
<ogra> tepsipakki, the edubuntu team will take care of it ..
<pygi> tepsipakki, debian folks sometimes (read: often) can do weird things
* StevenK glances at pygi
<pygi> StevenK, yes? ^^
<tepsipakki> ogra: ok, could you adjust the build-deps so it doesn't dep on xlibs-dev?
<bintut> hello all..  anyone here from the ubuntu embedded team?
<StevenK> pygi: I'm a DD, as are a bunch of people here. :-)
<pygi> StevenK, my statement still stands :)
<StevenK> I wasn't disagreeing. :-)
<dholbach> bintut: ubuntu mobile team?
<pygi> StevenK, good, good :)
<bintut> dholbach: i don't know the right name of the team.. i just read the announcement of developing ubuntu for embedded/mobile edition
<dholbach> bintut: try #ubuntu-mobile
<bintut> dholbach: ok.. thanks..
<dholbach> anytime
<ogra> tepsipakki, nopted
<tepsipakki> filed a bug about the removal of those (apart from dear squeak-vm ;)
<ogra> *noteed
<ogra> argh
<ogra> *noted
<tepsipakki> heh
<pitti> tepsipakki: will take care of that on Friday
<tepsipakki> pitti: good
<pitti> doko: what do you think of cow-trading merges? I currently have zope3; can I leave that to you and do some of yours? (like belocs-locales-bin and coreutils)
<doko> pitti: sure
<pitti> ok, grabbing those then
<farion> i have successfully have compiled the linux-source-2.6.22 package, but how can i add the sources of linux-ubuntu-modules-2.6.22?
<robertj> what do you think of some kind of custom add-on for the wiki that provided some way for people to designate sections as being version specific and let people set a session variable to designate what version they wanted to see
<robertj> "This page contains information about a specific version of Ubuntu. Please select which version of the page you wish to see. <select />"
<doko> pitti: should / can we promote db4.5 to main?
<doko> pitti: what was the rationale to drop libdb-dev as b-d in curl?
<pitti> doko: certainly
<pitti> doko: I'd just appreciate if we could drop an older version at some point
<doko> pitti: lets get rid of all but db4.5
<pitti> db4.2 is only used by cyrus-sasl2, libintl-perl, openldap2{,.3}
<doko> cyrus could be problematic
<pitti> 6 reverse build deps for db4.3
<pitti> anything that uses on-disk transactions is problematic
<pitti> I guess that should affect a few packages
<pitti> and 12 r-build-deps for 4.4
<pgquiles> I am trying to package a library using debhelper but I am doing something is wrong. dpkg-buildpackage -rfakeroot installs files fine in debian/tmp/usr/lib and debian/tmp/usr/share, but then they are not copied to mylib/usr/lib, mylib/usr/share, mylib-dev/usr/lib and mylib-dev/usr/share. I am following http://ubuntuforums.org/showthread.php?t=51003
<pitti> pgquiles: that's #ubuntu-motu stuff; however, you are probably missing debian/mylib-dev.install
<pochu> pgquiles: #ubuntu-motu is a better place to ask about packaging :)
<pitti> pgquiles: man dh_install(1)
<pitti> keescook: do you still remember how to workaround the coreutils local FTBFS with '../../src/dircolors: no SHELL environment variable, and no shell type option given'?
<pgquiles> thank you, joining #ubuntu-motu
<keescook> pitti: agh, I don't sorry.
<keescook> (how did you know I was awake?!)  :)
<pitti> keescook: I didn't, it was just IRC-queueing :)
<pitti> good mornign
<keescook> mornin'.  dogs got me up early; thought I'd do some email and then catch breakfast.  :)
<keescook> afair, building in chroot worked
<Markus2> As https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/88901 is my first bug fixing for Ubuntu, please allow me to ask if I need to do something else: Inform a developer, provide additional information? I'm not sure if the patch is enough?
<ubotu> Launchpad bug 88901 in pidgin "[apport]  gaim-url-handler crashed with Error in __call__()" [Medium,Fix committed]  
<seb128> Markus2: it's too much change to be accepted
<seb128> Markus2: your patch change most of the file
<seb128> a fix for this bug should be like 1 line
<Markus2> Seb128: So the bugs stays open? You can't change the problem with one line, as the whole file was buggy with gaim Beta6. I don't get it.
<Markus2> Seb128: So the bugs stays open? You can't change the problem with one line, as the whole file was buggy with gaim Beta6. I don't get it. I would be happy if you provide additional information, so I can avoid wasting time when trying to fix the next bug.
<pygi> seb128, tbh if bug affects a lot of users, we *should* fix it
<seb128> Markus2: gutsy has pidgin 2.0.0 which fixes the bug if I understand correctly
<pitti> seb128: hm, most of the patch is just removing the backup file, the rest doesn't actually look that scary?
<Markus2> Gutsy of course. So Feisty won't see a fix?
<seb128> pitti: that doesn't look like a high importance bug to me, if we start to fix such ones we will get 100 desktop SRU during the feisty cycle
<seb128> Markus2: the bug is not too important, I don't think it's worth a SRU, no
<Markus2> pitti: It's my first patch, sorry if I did something wrong. Hints are highly appreciated
<pitti> ooh, we are talking about an SRU here? right, no way then
<seb128> pitti: nothing wrong, that just doesn't look like a stable update candidate to me
<Markus2> Sorry to be dumb, what's a SRU?
<pitti> Markus2: I thought it was about fixing gutsy, since the bug is still marked open for it
<pochu> !sru | Markus2 
<ubotu> Markus2: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates for main and restricted, while https://wiki.ubuntu.com/MOTU/SRU is for universe and multiverse.
<pitti> seb128: 'stable release update'
<seb128> pitti: gaim has been replaced by pidgin
<seb128> pitti: that's for Markus2
<seb128> pitti: I've not looked how to deal with the some hundred bugs yet
<pitti> seb128: so the bug should just be close then, I figure?
<seb128> pitti: yes, reassigned to pidgin and marked fixed
<seb128> it's on pidgin
<seb128> just need to be closed then
<seb128> doing that
<seb128> Markus2: nothing wrong, you just sent a patch for a bug already fixed to gutsy
<seb128> Markus2: and we do backport fix to stable only when the bug is really important or annoying lot of users which is not the case of this one
<Markus2> Well, thanks Sebastien for taking the time to look into it. I still don't understand the issue fully as I can't see any side-effects with fixing the totally useless gaim-url-handler now. But I respect that you for sure have good reasons to handle like you do. I'm still in the learning process. I'm just a bit disappointed when every single Wiki-Page encourages you to provide help and then the whole work was just useless. So I will concentrate
<seb128> Markus2: it was not useless, but you worked on something already fixed
<seb128> Markus2: we use pidgin instead of gaim now
<seb128> Markus2: and it's fixed to pidgin
<Markus2> I do understand that issue for gutsy. Still, the bug exists in Feisty. I did understand that part of your message. And: If I work on something without a chance to get into feisty and fixed in gutsy, then it *is* wasted time :-)
<seb128> Markus2: we could discuss doing a feisty upload, but read https://wiki.ubuntu.com/StableReleaseUpdates for some background on stable updates (they require qa team work, regression testing, etc)
<seb128> Markus2: next time maybe ask if the bug is a candidate for a stable update before starting on it, that one has no feisty task open
<sharms> Markus2: if you find a bug like that, and want to help (we want you to help!) the best thing to do is hang out in #ubuntu-motu and ask before working on it
<sharms> Markus2: generally someone there will know about it and if it still needs to be fixed
<seb128> Markus2: we can't spend qa time to test regression for every bug
<Markus2> Thanks everyone for taking the time to explain me some rules I wasn't aware off. SEE YOU.
<bddebian> Heya
<tkamppeter> I have a question about replacing an obsolete package by a new package:
<tkamppeter> The obsolete package is gs-esp and its replacement is the already existing gs-gpl
<tkamppeter> Is it correct when I let the gs-gpl have
<tkamppeter> Confilcts: gs-esp (<< 8.60)
<tkamppeter> Replaces: gs-esp (<< 8.60)
<tkamppeter> Provides: gs-esp
<tkamppeter> and I let the gs-gpl source package make a transitional package named gs-esp which depends on gs-gpl
<tkamppeter> Is this correct?
<bddebian> tkamppeter: Sounds right but I'm no expert on the matter
<tkamppeter> Especially I also woul like to know how the upload will work, as gs-gpl will ship the (transitional) binary package gs-esp and the gs-esp which is still in the archives will also ship a binary package named gs-esp.
<pitti> tkamppeter: that sounds fine
<pitti> tkamppeter: right, there will be two gs-esp packages in the archive (built by different sources), the highest version will win
<pitti> tkamppeter: so you need to make sure that the transitional gs-esp has a higher version than the current gs-esp
<pitti> tkamppeter: with the versions in the archive that's already the case
<bddebian> Is there any reason to keep gs-esp in the archive?
<pitti> tkamppeter: ^ if gs-esp will disappear upstream and is not needed any more, I'd remove it
<tkamppeter> pitti, gs-esp and gs-afpl can be removed. gs-esp is not provided upstream any more and gs-afpl is the same as gs-gpl now.
<tkamppeter> pitti, I have added appropriate lines in the control file and transitional packages to automatically uninstall all packages of gs-esp, gs-afpl, gs-aladdin, gs wheninstalling gs-gpl.
<tkamppeter> pitti, gs-gpl will be the only Ghostscript then, as it is the newest Ghostscript and it provides full functionality.
<Burgundavia> is there any reason to have the license name in the package then?
<Burgundavia> why not just call it gs?
<tkamppeter> Burgundavia, perhaps we better wait for Debian what they do with the package names.
<Burgundavia> that is probably sane
<tkamppeter> pitti, so after my testing I will make the new gs-gpl available for you to upload. With this upload gs-esp and gs-afpl can be removed.
<xst> Since upgrading to feisty I have no sound. How can I see if there is any progress in bug #108288?
<ubotu> Launchpad bug 108288 in linux-source-2.6.20 "Audio is played in "slow motion"" [Medium,Confirmed]  https://launchpad.net/bugs/108288
<pitti> tkamppeter: great, thanks
<Burgundavia> xst: by checking the bug
<Hobbsee> morning all!
* Hobbsee wonders why no one is here....
* pitti hugs Hobbsee 
* Hobbsee hugs pitti :D
<seb128> hey Hobbsee
<Hobbsee> heya seb128!
<Amaranth> hey Hobbsee (late)
<Burgundavia> hey Hobbsee
<Hobbsee> hiya Amaranth, Burgundavia :)
<Amaranth> ooh, xchat-gnome does a little ding now
<Amaranth> i ditched pulseaudio, it was causing too many wakeups
<Burgundavia> playing with that powertop thingy?
<Amaranth> yeah
<Amaranth> it's sad though
<Amaranth> Wakeups-from-idle per second :  839.8 
* Hobbsee hasnt tried, eyt...
<Burgundavia> not yet on gutsy, need the tickless kernel
<Amaranth> things i hate:
<Amaranth>   36.7% (161.6)       <interrupt> : uhci_hcd:usb4, nvidia 
<Amaranth>   11.4% (50.2)       <interrupt> : uhci_hcd:usb3, yenta, ipw3945 
<Amaranth>   10.6% (46.8)       <interrupt> : HDA Intel 
<Burgundavia> interesting to see the numbers on a warty install
<Ng> Amaranth: woah, that's a pretty good score
<Ng> I thought my 300 or so were bad ;)
<Amaranth> Ng: what do you get 300 from?
<Amaranth> ipw3945 and nvidia kick me out of C3
<Ng> Amaranth: thinkpad x40. feisty install I booted with a gutsy kernel to test powertop with
<Amaranth> oh, you get 300 total?
<Amaranth> while running X?
<Amaranth> s/X/GNOME desktop/
<Ng> yes, while running my regular setup
* Amaranth cries
<Ng> but that has wifi and stuff, so it's expected to wake up. also I didn't put in any of the patches
<Amaranth> if i stop X and hit the kill switch on my wireless i get down to ~80
<Ng> I didn't apply any patches, so I didn't get to keithp levels, but with init, bash and some kernel modules it was idling about 35 and spending >90% of the time in C4
<Ng> interestingly though, that didn't drop the power usage more than a W or two
<Amaranth> i don't even get power usage reports
<Amaranth> i'm guessing things calling schedule_timeout (process_timeout) or do_nanosleep should be smacked about
<er1> does someone knows how can I redefine my default g++ compiler?
<er1> I want to change it from g++-4.0 to g++-3.3
<er1> I have both compilers installed.
<er1> right now in the /usr/bin directory I have: g++ -> g++4.0
<Pici> er1: relink /usr/bin/g++ to whichever version you want to use
<geser> mdz: the last log for xmms2 contains only "/bin/sh: Syntax error: "(" unexpected" as reason but no info about the called command (which it did in the last logs). Do you have an idea how to get this info back?
<mdz> geser: no, I don't
<mdz> sounds like changes to the shell on the buildds; I vaguely recall hearing something about that
<Hobbsee> hiya mdz - you made it back OK then?
<mdz> Hobbsee: I did, thank you.  and you as well?
<Hobbsee> mdz: sort of
<Hobbsee> :)
<Hobbsee> mdz: took 36 hours, 4 and a bit planes, 3 trains, 1 car, and 1 taxi.
<Hobbsee> mdz: now you can see why i was whining the last night when we started playing Mao :P
<mdz> that's a long way, even for .au
<mdz> that's about as long as it took rtg to get home
<Hobbsee> it should have only been about 32
<Hobbsee> rtg?
<Hobbsee> elkbuntu and ajmitch's were slightly longer again
<Hobbsee> mdz: you've got to remember though - au just *is* a long way away.
<mdz> rtg is a kernel developers who lives in Montana
<Hobbsee> ahh
<Hobbsee> and i'm almost over the jetlag - woo!  :P
<racarr> Didn't you just sleep from 3 PM to 3 AM?
<Hobbsee> yes
<Hobbsee> but that's better than the 6am to 6pm from the day before
<racarr> Fair enough.
<truz_`24> where is linux/config.h?
<Hobbsee> hah.  now the horrible truth about the smokes comes out...
<ajmitch> morning
<sharms> hey
<Hobbsee> hi ajmitch!
<pata_sis_prob> good evening 
<pata_sis_prob> i got a problem with the pata_sis module on a fresh ubuntu 7.04 installation
<pata_sis_prob> could somebody please explain how i can solve this problem by chrooting the system from a live-cd and compiling the kernel with the necessary patch?
<sharms> apokryphos: I don't believe ATI ever said they are releasing their drivers open source.  That enterprise linux blog was commenting about the same things Chris Blizzard was, and I think they just over eagerly paraphrased things
* apokryphos looks
<sharms> I believe they said "we are committed to fixing our problems with open source", not "we will open source our drivers"
<sharms> and from my correspondence with AMD, they are developing another closed source rewrite of fglrx, which can only be obtained through NDA at this point
<apokryphos> hm, still sounds hard for a huge room of people to misinterpret
<sharms> I trust chris blizzard over enterprise linux blog though
<bhale> I trust them to show us
<bhale> throwing speculation all over the internet isnt helping anyone
<sharms> bhale: no I just posted a possibly derogatory blog entry about AMD and how they should open source the drivers, so I was just clarifying that as far as I know they didn't commit to releasing any source
<sharms> but if I am wrong, I would take the entry down, just checking to make sure I got my end straight
<apokryphos> hm, Blizzard doesn't seem to explicitly state that they didn't say that
<mjr> incidentally, it does seem to me too that people are reading too much into what ATI actually said
<apokryphos> now, if only these talks were online 8)
<mjr> so putting on pressure to do what people think they said is good :] 
<sharms> ha, new blog entry: "Redhat open source your talks with the ATI guy!"
<apokryphos> sharms: either way, especially with the hype about it atm, calling for a boycott of amd is definitely jumping the gun (at this point) ;-)
<mjg59> Could we not have this discussion here, please?
<apokryphos> sure
<mjg59> Ta
<mjg59> -offtopic might be a better choice
<mjr> sharms, incidentally, url to the blog?
<sharms> mjr: http://www.sharms.org/blog
#ubuntu-devel 2007-05-17
<Keybuk> I do so hate it when I have no X server ... :-(
<crimsun> got bitten by -intel and xorg-server 1.3, too?
<Keybuk> yup
<mjg59> -intel isn't ready for <915 yet
<mjg59> Though I don't think that's Scott's problem
<Keybuk> I think the lack of an updated -intel driver is likely my problem
<mjg59> Also a possibility
<mjg59> Did -i810 get updated?
<Keybuk> no, neither did
<Keybuk> installing the Debian -intel package seems to fix it
<Keybuk> yay simple solutions, brb
<Keybuk> someone renamed gaim?!
<kylem> Keybuk, gaim renamed gaim...
* Keybuk tries to remember what telepathy client kikidonk recommended
<Lathiat__> gossip ?
<Keybuk> no, it was supposed to be better than gossip
<Lathiat__> ah right
<Keybuk> ie. not suck
<Keybuk> since I can't make gossip login to jabber
<Lathiat__> well it might one of: gossip, landell, cohoba, gnomeui, empathy, banter
<Keybuk> empathy sounds right
* ajmitch probably shouldn't update X on the laptop then
<Keybuk> http://www.flickr.com/photos/daviderosa/491277662/
<Keybuk> ^ wow, elmo has a twin brother
<Hobbsee> hi all
<Treenaks> morning
<Hobbsee> :)
<Mithrandir> morning, Hobbsee 
<Hobbsee> Mithrandir!
* Hobbsee stomps on Mithrandir's feet in greeting.
* Hobbsee runs away
<stgraber> Mithrandir: I don't remember, was it you who took some notes for the isotesting tracker BoF ?
<Mithrandir> stgraber: hm, I don't think I did it, no.  I could check, can you remind me tomorrow?  (I'm not really here today, it being a public holiday and all)
<stgraber> Mithrandir: ok :)
<Hobbsee> Mithrandir: so, if it's a holiday, why are you on irc?
<stgraber> well, it's for me as well :)
<Hobbsee> which holiday?
<Mithrandir> constitution day and ascension day.
<Hobbsee> right
<Treenaks> morning jono
<jono> hey
<Hobbsee> oh no, it's master duck bacon.
<Treenaks> Hobbsee: 'duck bacon', how would that work?
<Hobbsee> Treenaks: master bacon, lover of ducks
<Treenaks> Hobbsee: ah :)
<Spads> turducken
<Fujitsu> Spads: Sure.
<Spads> Jono Turducken.
<Fujitsu> Um, whatever you say.
<Hobbsee> hiya Spads 
<Spads> howdy, Hobbsee 
<Hobbsee> :)
<_StefanS_> hi there
<_StefanS_> any plans for including networkmanager 0.6.5 in gutsy?
<Treenaks> is it in Debian?
<_StefanS_> uhm dont know where to check ?
<Treenaks> packages.debian.org?
<_StefanS_> uhm, let me check
<Treenaks> debian unstable has 0.6.4
<_StefanS_> hmm nope..
<Treenaks> _StefanS_: has 0.6.5 been released?
<bart> hello everyone
<_StefanS_> Treenaks: uhm well, dont know :) - all I know is that the svn has 0.6.5 with leap support in it
<Treenaks> _StefanS_: leap?
<_StefanS_> Treenaks: wireless leap
<_StefanS_> Treenaks: cisco's peap implementation
<_StefanS_> Treenaks: used very broadly
<Treenaks> _StefanS_: never heard of it :)
<_StefanS_> Treenaks: I know the gnome-applet for network manager does support it in the latest version
<_StefanS_> Treenaks: I was going to add support for it in knetworkmanager
<_StefanS_> Treenaks: but then i stumbled upon the !=0.6.5 ;)
<Treenaks> _StefanS_: It's been released since 20-04.. so I guess it's just a matter of time
<_StefanS_> Treenaks: do you think it will make it for gutsy? cant remember the debian freeze date
<Treenaks> though I've heard a lot of people complain about the 'wifi-centric' approach n-m is taking.. completely ignoring things they don't like (pppoe, bluetooth networking)
<_StefanS_> Treenaks: well isn't that the common nominator in gnome stuff ? (no pun intended)
<_StefanS_> sad really.
<Treenaks> _StefanS_: it's not because of the gnome thing... it's really just the upstream authors of n-m
<_StefanS_> Treenaks: oh wait, my mistake. It is the freedesktop ppl that is maintaining it 
<_StefanS_> Treenaks: sorry.
<_StefanS_> nevertheless they should broaden themselves a bit.
<Treenaks> yeah, I agree completely
<_StefanS_> hmm well, I might package that 0.6.5 to begin with, it seems like I wont get far without n-m support for LEAP
<_StefanS_> gui works though ;)
<_StefanS_> Treenaks: thanks for the help
<vciaglia> hi, is there Mozilla-Composer on amd64 ?
<gnomefreak> vciaglia: for gutsy?
<vciaglia> gnomefreak: no, feisty
<gnomefreak> vciaglia: nope
<gnomefreak> vciaglia: gutsy will have it named iceape
<vciaglia> oh, ok
<vciaglia> thank you
<gnomefreak> yw
<gnomefreak> vciaglia: iirc mozilla-suite was removed from feisty and nothing replaced it. and seamonkey/iceape replaces that and has composer with it
<sn0> is gutsy going to have iceweasel/icedove a la debian ?
<gnomefreak> sn0: no firefox and thunderbird
<gnomefreak> iceape is the only thing we (mozilla-team) took from debian
<sn0> i had heard canonical/ubuntu had made a deal with mozilla over the copyright thing recently
<sn0> and the reason for that and not the weasel/dove gnomefreak ?
<sn0> just so i know :)
<gnomefreak> yes
<sn0> okay :-)
<gnomefreak> we agreed to the license afaik there might have been some dealing in there but im not sure about that all i know is we agreed to it
* sn0 sits pretty waiting for icedove 2 in sid
<gnomefreak> sn0: its being worked on and uploaded today ( i believe for sid.)
<gnomefreak> the maintainer stated that an hour or 2 ago
<sn0> gnomefreak brilliant , i have had the packages.qa.debian.org open for a while now, is there somewhere else that incoming is listed?
<gnomefreak> sn0: not sure, maybe ftp.debian.org?
<sn0> (also waiting patiently on pidgin-otr for i386)
<Fujitsu> incoming.debian.org, sn0 :P
<sn0> ah thanks Fujitsu 
<sn0> even better than packages.qa :)
<gnomefreak> ty Fujitsu 
<gnomefreak> packages.debian.org seems a bit old as debian has iceape 1.1.1-3 and it still shows 1.1.1-2 as newest
<sn0> it seems experimental does not yet have the newer one, or any
<Fujitsu> That's always out of date.
<gnomefreak> sn0: i just assked about icedove if its for sid
<sn0> oh pidgin-otr is in unstable now
<sn0> with i386
<sn0> and sid it seems :D
<sn0> err unstable/experimental
<Tonio__> hi 
<Tonio__> I would have a question (needed for a doc)
<Tonio__> how is the apt periodic work handled ? 
<Tonio__> for example how is the daily "update" performed ? is there a daemon running or so ?
<mdz> Tonio__: via /etc/cron.daily/apt
<Tonio__> mdz: thanks
* shirish looks for jani
<timmay> Is there anyone here working with the Lexmark driver dev kit? I would like to help on getting the X6100 series working.
<evand> Does anyone know if the recordings from the UDS VOIP lines are available?
<shawarma> evand: try in #canonical-sysadmin 
<Ng> evand: they aren't yet, but they should be soon. It'll be announced too.
<evand> Thanks shawarma and Ng
<zul> Ng: eta?
<Mithrandir> iwj: you going to be around daytime tomorrow?  I'd like to run my dpkg-architecture change for lpia by you so you can bop me over the head if it's too crackful.
<iwj> Mithrandir: Sure.
<Mithrandir> great, thanks.
<Mithrandir> iwj: just prodding you on IRC works or should we set a time?
<iwj> Catch me after 1000Z and I should be around with a not wholly unreasonable response time.
<Mithrandir> ok, good.
<iwj> Before then I might not yet be caffeinated :-).
<timmay> Is there anyone here working with the Lexmark driver dev kit? I would like to help on getting the X6100 series working.
<hunger> gutsy has broken keyboard in X since I upgraded X:-( AltGR does no longer work.
<tkamppeter> timmay, I do most of the printing stuff in Ubuntu and I am also leading the OpenPrinting project. Unfortunately, I did not do anything with the Lexmark DDK.
<timmay> tkamppeter: Does/will the OpenPrinting project support that Lexmark printer?
<freezone> after years of positive experiences with debian and all kinds of tests with other distributions i am deeply impressed by Ubuntu Feisty. that is all advantages of debian enhanced by usability at a very mature state.
<freezone> fantastic job of all you guys
<sladen> yah:  http://www.linuxpowertop.org/powertop.php
<jsgotangco> that's a nice tool
<pochu> It's in the new queue now :)
<jsgotangco> wow!
<pochu> bug 114417
<ubotu> Launchpad bug 114417 in Ubuntu "Please sync powertop from Debian unstable" [Wishlist,Fix committed]  https://launchpad.net/bugs/114417
<pochu> hopefully it'll be available here soon :)
<seb128> no need to open sync bugs for new packages in Debian
<Arador> I was reading a good article about it just now at http://www.linux.com/article.pl?sid=07/05/16/1742204
<seb128> they are synced automatically
<pochu> seb128: ok, will remember it :)
<Hobbsee> morning all
<tkamppeter_> timmay, see also this link about making Lexmarks work: http://ubuntuforums.org/archive/index.php/t-83456.html
<freezone> is there a better channel than #ubuntu for support questions?
<Burgundavia> no
<Burgundavia> why do you ask?
<freezone> well
<freezone> example: i have a problem to mount my cam. some dude suggests to use gthumb which imports pictures from existing filesystems. thats kind of pointless
<Burgundavia> freezone: have you tried the users mailing list, the forums or a local team?
<freezone> yeah
<freezone> there is a hint in some asian language that directs to a special link with a driver 
<geser> freeflying: are you sure you can mount your cam? afaik not all cams appear as usb-storage
<freezone> but i am unsure if i need to build a driver manually if the chipset is obviously detected
* Treenaks feels dirty.. I had to hexedit fglrx to make it work
<robertj> has there been any discussion about versioning community docs per-release?
<Burgundavia> in what sense?
<robertj> Burgundavia: so that you don't have separate subsections for each version of Ubuntu
<Burgundavia> on the wiki?
<robertj> yes
<Burgundavia> do you have a sane suggestion of making it easy?
<robertj> Burgundavia: Possibly
<Burgundavia> shall we move to -doc?
<robertj> sure, didn't know there was one :)
<psusi> iwj: ping
<iwj> Hi.
<iwj> If you told me a bit more about what you wanted to talk about then I would be able to provide a more useful reply right away.
<iwj> Content-free pings are a bit useless really.
<pochu> iwj: that looks like a retarded script :)
<Hobbsee> there is a script for it
<pochu> Hobbsee: yep, but it doesn't have a "wait 300" :)
<iwj> It's not a script.  But if I had one I might put `wait 300' in it just to make sure the contentless-pinger had to hang around pointlessly some more :-).
<sladen> psusi: ^^ping
<mako> elmo: http://mako.cc/copyrighteous/20070517-00
<elmo> :(
<mako> elmo: just the messanger dude
<psusi> sladen: pong
<psusi> iwj: howdy... I see that you modified devmapper to allow udev to create the dev nodes... I was wondering if you sent those changes upstream?
<iwj> psusi: No, and we're going to revert them.
<iwj> So lucky upstream :-).
<psusi> we are?  why?
<psusi> I'm working right now on merging that package with debian's newer version
<psusi> I'm wondering how I should merge the changelog... keep ours and add a line that says I merged with debian's changes, or just insert all of our changes into theirs?
<Hobbsee> hmmm.  breakage
<psusi> i.e. should it show 1.0ubuntu0, 1.0ubuntu1, 1.1, 1.1ubuntu0: merged
<psusi> debian has added 2 new entries to the changelog... we have like 8.... should I just take our 8 and add a new one saying I merged with debian, or should I actually add the two new entries from debian?
<Hobbsee> psusi: seen the merge-o-matic?
<iwj> psusi: Please don't merge that libdevmapper udev device node stuff.
<sladen> psusi: take the copy that debian has, put that in Ubuntu.  If you add some patches aswell then document those in the changelog
<iwj> Or rather, leave it in our version if you like.
<iwj> Sorry, for a moment I thought you were talking about merging our changes into a Debian package, but you mean to make a package for gutsy.
<iwj> For the moment that should have all of our changes.
<psusi> Hobbsee: sort of
<iwj> psusi: For the spec about reverting part of the udev thing and generally doing it differently, see https://wiki.ubuntu.com/UdevLvmMdadmEvmsAgain.
<iwj> But I have to go away now and have dinner and things.
<psusi> iwj: huh?  I'm merging the new upstream version with ours... keeping our changes
<iwj> Right.
<iwj> Good, that's fine.  Carry on :-).
<iwj> I just misunderstood you.
<iwj> Good luck.
<psusi> sladen: no, we aalready have diverged from debian, and now I am trying to merge with debians' new version
<Hobbsee> oh dammit, i'll need a sponsor for this.
<iwj> psusi: You don't need to worry about that spec but it's FYI if you want it.
<psusi> cool
* iwj goes, really.  Goodnight everyone.
<psusi> thanks
<psusi> now, we forked from debian in 1.08... since then we have had several ubuntu versions
<psusi> debian since then has had 2 new versions and is currently on 1.18...
<psusi> so the question is, when I merge the changelog... should it show 1.08, 1.08ubuntu0, 1.08ubuntu1... then 1.12, 1.18, 1.18ubuntu0: I merged here?
<seb128> mr_pouit: "   * Repack orig tarball to remove upstream debian directory.", that doesn't make sense
<seb128> mr_pouit: the changes can go to the diff.gz
* robertj files +bug/115295
* robertj files <*ahem*> bug #115295
<ubotu> Launchpad bug 115295 in app-install-data-commercial "vmware-server package has broken pam settings that won't let you log in" [Undecided,Unconfirmed]  https://launchpad.net/bugs/115295
<mr_pouit> 21:10 < seb128> mr_pouit: the changes can go to the diff.gz << and generate an ugly one :(
<seb128> mr_pouit: and?
<seb128> who read the .diff.gz anyway?
<seb128> better to use the upstream tarball as orig
<seb128> so we don't conflict with Debian when we try to sync because we have different tarballs
<mr_pouit> I do the same change in debian
<seb128> it's extra work
<seb128> and the md5sum doesn't match upstream
<seb128> don't
<mr_pouit> my sponsor preferred that I remove the upstream debian/ dir that having a huge diff.gz, so :/
<seb128> who is he?
<seb128> you should talk to upstream and tell them to not ship the debian dir with the tarball
<mr_pouit> yes
<mr_pouit> 21:13 < seb128> and the md5sum doesn't match upstream <<< then why repack the orig tarball to add a missing license rather than patching? that's a similar issue
<seb128> mr_pouit: yes, there is case were you need to repack it
<seb128> mr_pouit: changing the debian dir is not one of those
<cjwatson> the reason we ask people to repack the .orig.tar.gz for missing licences is so that the .orig.tar.gz is legal to distribute in isolation
<mr_pouit> ok
<cjwatson> (personally I think it's overkill, but I understand why some archive admins prefer to ask for it)
<Hobbsee> morning, cjwatson 
<cjwatson> evening
<seb128> mr_pouit: who is your Debian sponsor?
* Hobbsee wishes the shoestring link to australia wasnt so crap.
<mr_pouit> seb128: for this package it was daniel baumann
<mr_pouit> seb128: but I changed since (but haven't updated this package since)
<seb128> k, I was just curious, I would have pinged him on IRC if he was somebody I know ;)
<mr_pouit> ok ^^
<seb128> anyway, no big deal, I just wanted to mention that you don't need to make a new tarball only to drop the upstream debian dir
<mr_pouit> ok
* Hobbsee taps fingers.
* Hobbsee needs a faster machine.
<psusi> wtf?
* psusi adjusts his glasses
<Hobbsee> psusi: ?
<Chipzz> seb128: ok, this is really disturbing
<Chipzz> seb128: I just upgraded gnumeric (and related goffice libraries), and my panel crashed
<seb128> Chipzz: why is that disturbing?
<Chipzz> seb128: these were the only packages involved: gnumeric-common libgoffice-0-3 libgoffice-0-common libgsf-gnome-1-114
<Chipzz> (and gnumeric)
<Chipzz> seb128: because gnumeric wasn't running, and gnome-panel isn't linked to any of these libraries
<Chipzz> which means that upgrading totally unrelated stuff can crash the panel?
<pochu> Chipzz: bug 85776
<ubotu> Launchpad bug 85776 in gnome-panel "[apport]  gnome-panel crashed with SIGSEGV on package installation, valgrind log required" [High,Confirmed]  https://launchpad.net/bugs/85776
<pochu> seb128: if you didn't know, it's still present in gutsy ;)
<Chipzz> the panel crashing would be understandable (I'm not saying acceptable, just understable), if the panel was in any way related to these packages at all
<pochu> I've tried to get it crashing under valgrind, but seems it only crashes without it :/
<seb128> pochu: we had no sign of it been fixed, that's why the bug is not closed ;)
<pochu> :)
<seb128> nobody managed to get a valgrind log though
<seb128> so it's of no real use :/
<Chipzz> only thing I can imagine is overwriting of the icons causing this
<Chipzz> errr
<Chipzz> .desktop files
<seb128> I ran gnome-panel for some time under valgrind and we fixed the bugs I spotted
<seb128> but my panel don't crash often
<pochu> seb128: I've just installed more than 100 packages with valgrind, without a crash :/
<seb128> might be due to some setting I'm not using
<seb128> Chipzz: I think it's icon cache related
<pochu> seb128: it does here ~ twice a week
<seb128> but without a valgrind log
<seb128> pochu: maybe you could run the panel under valgrind for a week ;)
<seb128> we need a log to get it fixed
<pochu> seb128: does it restart somehow when I do "gnome-session-remove gnome-panel && valgrind blablabla gnome-panel"?
<pochu> seb128: I'll run it until we fix it, but I turn off the laptop on the night ;)
<seb128> what do you mean, restart?
<seb128> if you use gnome-session-remove you stop it
<seb128> and then run it under valgrind
<pochu> will try to get it
<seb128> thank you
<pochu> some time ago I installed kubuntu-desktop, edubuntu-desktop and xubuntu-desktop to get it, without a crash!! :/
<pochu> hehe :)
<seb128> I ran the panel under valgrind a lot before feisty
<seb128> I got some invalid read to the icon cache code which have been fixed to GTK+
<seb128> but looks like that was not enough
<pochu> if the panel doesn't crash, the logs are useless?
<seb128> no
<seb128> look if there is some Invalid read to them
<seb128> and not to ld code
<seb128> valgrind list invalid usages
<pochu> argh, I've removed my last log :)
<seb128> they don't always lead to a crash
<pochu> will check with next one :)
<Hobbsee> curious question - what will happen if i upload something to ubuntu with a debian version?
<siretart> Hobbsee: you will be treated with a large stick
<Hobbsee> siretart: yay.  anything else?
<siretart> Hobbsee: I asked tollef this question. Technically, your upload will be accepted
<Hobbsee> right.
<seb128> Hobbsee: what do you mean by "version"? number?
<seb128> it'll be accept
<Hobbsee> seb128: yes
<zul> Hobbsee: anything else? you will be beaten with it
<psusi> hrm.... I'm trying to compare my merged package .diff.gz with the interdiff I ran against the old ubuntu package vs the common base to make sure I didn't leave out any of the ubuntu specific changes from the merge
<seb128> Hobbsee: we do use -1 for some ubuntu specific packages
<Hobbsee> seb128: i'ts not a native package
<Hobbsee> but of course, yes.
<psusi> but if I interdiff the new .diff.gz with the old interdiff, interdiff fails with a failed hunk message if I give it -p1, but works without the -p1, but it thinks everything is new since the first directory name is different
<seb128> using the ubuntu<n> versioning just make it easy to know when a package has been changed for Ubuntu
<psusi> what gives?  why would interdif fail?
<seb128> and not conflict with Debian
<Hobbsee> seb128: i've got something that i'm planning to get uploaded to debian, but would prefer to get it uploaded to gutsy first to check it doenst break the entire universe
<Hobbsee> debian being debian, and all that...
<seb128> Hobbsee: upload with 0ubuntu1
<psusi> I'd say so since it will probably take 2 years to get it uploaded to debian ;)
<Hobbsee> seb128: the package is the same - it'll be synced in future. 
<seb128> then upload to debian with -1
<seb128> and ask a sync
<seb128> that's what we do for GNOME packages when we upload faster
<cjwatson> yes, if you're uploading to Ubuntu first please use -0ubuntu1
<seb128> we use 0ubuntu1
<seb128> and ask a sync when Debian has the -1
<Hobbsee> mmmm...dammit
* Hobbsee was hoping to shortcut.
<seb128> Hobbsee: what does it shortcut?
<Hobbsee> (and only need 2 lots of sponsoring, instead of 3)
<cjwatson> the versions in both places by definition can't be the same
<seb128> you don't need 3
<cjwatson> since you need a different distribution line in debian/changelog
<seb128> you need 2 and a sync
<Hobbsee> seb128: sync requires a sponsor, too.
<cjwatson> there's no Ubuntu->Debian sync procedure to allow working around that
<psusi> hrm... wonder if I should try to refactor devmapper while I'm at it to use dpatch
<Hobbsee> oh yeah, there's a thought.  it *would* get rejected with unstable
<seb128> Hobbsee: well, getting sync approval is fast enough, just ping me and say they are the same package and I'll sync it ;)
<Hobbsee> hehe
<seb128> yes, that's why I asked if you spoke about version number only
<Hobbsee> seb128: sorry, didnt realise what you were asking, i'd forgottne about unstable.  it's still pre-6am here.
<seb128> sync are easy
<seb128> upload to gutsy with 0ubuntu1
<seb128> get -1 to Debian
<seb128> and let me know when you need the sync
<Hobbsee> right
<Hobbsee> oh fricking hell
* Hobbsee cant type a passphrase *again*
<seb128> you should be sleeping at pre-6am ;)
<Hobbsee> seb128: true.  jetlag and all
<Hobbsee> err....
* Hobbsee pokes imbrandon with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<imbrandon> ... ?
<Hobbsee> imbrandon: you didnt happen to change the buntudot account passwords, did you?
<Hobbsee> (ssh)
<imbrandon> err no i dident know anyone was still using that space, the domain exires this month so i was gonna let it go
<imbrandon> hrm
<Hobbsee> right, okay
<Hobbsee> no problem
* Hobbsee has other places, too
<imbrandon> 2 choices, you can use your shell on aurora 
<imbrandon> or i can renew buntutudot
<imbrandon> upto you :)
<Hobbsee> imbrandon: nah, it's cool
<imbrandon> rember you have a shell on all the buildd'd too :)
<imbrandon> s/'d/'s/g
<Hobbsee> this is true.  i was meaning the webspace.
<imbrandon> ahh i can put webspace on the buildd for you , only take me a minute
<imbrandon> one sec
<Hobbsee> imbrandon: seriously, dont worry - i've got other places too.
<Hobbsee> i was just going to use that as it was faster.
<Hobbsee> (and not australian)
<imbrandon> Hobbsee, too late , already dont , restarting apache now, one sec
<imbrandon> lol
<Hobbsee> oh well.  yay, more webspace :)
<Hobbsee> if you've got it done, of course i'm going to use it :P
<imbrandon> Hobbsee, ok http://hobbsee.ubuntuwire.com points to ~/public on aurora
<imbrandon> all setup and ready
<imbrandon> see all personalized domain and all
<Hobbsee> imbrandon: great, thanks :)
<imbrandon> :)
<Hobbsee> woo :)
<imbrandon> hels to have a buddy server admin , shhhh
<imbrandon> helps*
<Hobbsee> hehe, of course.
<Hobbsee> friends in high places are always good.
<imbrandon> btw since dreamhost couldent handle the dugg ubuntustudio.org , guess where it is now :)
<imbrandon> heheh
<imbrandon> imbrandon > dreamhost
<Hobbsee> haha
<imbrandon> anyhow /me is off for a nap
<Hobbsee> night imbrandon 
<Burgundavia> imbrandon: did us.org take down all fo dreamhost?
<imbrandon> Burgundavia, pretty much, then they shutdown the site saying they couldent handle it and wanted 230$ a month for a dedicated server
<Burgundavia> ouch
<imbrandon> so i said i would host it, i put it on the same box as imbrandon.com and only sitting at a 0.45 load avg
<Burgundavia> I assume it is headed for the dc then?
<imbrandon> yea its at my DC right now , I work in one of the largest DC's in the USA
<Burgundavia> the advantages of the ubuntu community
<psusi> sladen: ping
<imbrandon> Burgundavia, some vanity pics of my work .... http://www.imbrandon.com/misc/gsi/
<imbrandon> :)
<flithm> hey everyone, sorry if this is the wrong place to ask... I'm trying to find out what it takes to get a new package into the offical (contrib) package tree?  Can anyone point me in the right direction?
<Burgundavia> shin
<Burgundavia> shiny, rather
<imbrandon> flithm, REVU and http://wiki.ubuntu.com/MOTU are good places to start
<Burgundavia> flithm: #ubuntu-motu is the correct place for that
<imbrandon> and #ubuntu-motu
<imbrandon> yea
<imbrandon> hehe
<flithm> thanks guys... sorry for the OT
<Burgundavia> no worries
<imbrandon> np
<Burgundavia> I am in a hostel in Madrid watching Kill Bill 1
<Burgundavia> surrounded by a large number of Vancouverites
<Burgundavia> the world is a very wierd place
<imbrandon> heh , i just got off a 12 hour shift, about to hit the sack after a shower
<imbrandon> hehe
<adilson> Burgundavia: I hope it's not dubbed :)
<Burgundavia> nah, english dvd
<psusi> well, I think I've managed to merge devmapper
<psusi> now I create a bug report and upload the debdiff then subscrube... which group was it for sponsorship?
<Amaranth> isn't there an ubuntu-archive group?
<seb128> Amaranth: ubuntu-archive is not a sponsor team
<Hobbsee> Amaranth: should be.  else where do the syncs get subscribed to
<Hobbsee> ah
<pochu> Hobbsee: go to sleep! :)
<Hobbsee> pochu: why?  it's almost 7am.
<Amaranth> seb128: oh, it's for syncs, backports, and SRU requests then?
<seb128> ubuntu-main-sponsors and ubuntu-universe-sponsors are doing sponsoring
<pochu> Hobbsee: and you haven't sleep in all the night?
<seb128> Amaranth: right, archive admin work ;)
<Hobbsee> pochu: i woke up around 3am
<Amaranth> heh
<psusi> I have merged devmapper with the new deb version
<pochu> hehe :)
<Amaranth> i ended up staying up 24 hours by the time i got off work and then only slept 5 hours
<pochu> Hobbsee: jetlag! :p
<Amaranth> stupid timezones :P
<seb128> psusi: subscribe ubuntu-main-sponsors
<Hobbsee> pochu: yeah.  it's seriously evil.  i didnt expect it to be this bad.
<Burgundavia> Hobbsee: your first time overseas?
<Hobbsee> Burgundavia: second.  but in ages, yes.
* desrt chuckles
<Burgundavia> right
<Burgundavia> jetlag doesn't get any easier
<desrt> australia/europe is quite bad.
<Hobbsee> hiya desrt 
<desrt> hello
<Hobbsee> i would have expected it to be better
<seb128> hey desrt
<desrt> bonjour
<desrt> :)
<Burgundavia> hey desrt
<seb128> I usually handle jetlag quite fine
<Hobbsee> seeing as there was no jetlag, well, almost none, going into spain
<desrt> good day, sir
<Burgundavia> east to west is easier
<Burgundavia> for some reason
<seb128> it takes me one day either way
<seb128> just have to sleep in the plane or wait a bit longer to go to bed
* desrt gets annoyed at nstx and considers a rewrite
<desrt> jetlag for me coming home from europe is fantastic
<desrt> i like it a lot
<desrt> since it means that at about midnight i'm _dog_ tired
<desrt> and i wake up at 9am the next morning
<seb128> "normal cycle" ;)
<desrt> europe is like tough love to put my sleep cycle back on track :)
<desrt> has anyone (outside of selinux or whatever) invited a better practise for daemons that ought to have access to nothing than setuid() nobody?
<desrt> (or various per-daemon accounts)
<desrt> *invented
<desrt> ideally, there should be some eject() syscall or something that completely unplugs the calling process from the filesystem and any per-user privileges that it would have (like kill(2))
<Mithrandir> chroot-ing into an empty directory often helps.
<desrt> any open(), socket(), bind() or anything fails
<Mithrandir> then setuid-ing to some nobody-user.
<desrt> (but accept() still succeeds)
<cjwatson> desrt: the Hurd has id sets so you can have the empty set of ids ;-)
<cjwatson> (IIRC anyway)
<desrt> cjwatson; when do we get our Hurd port? :)
<cjwatson> some point after it works ..
* Mithrandir ^5s cjwatson 
<desrt> nstxd is hard-wired to port 53.  silly.
<Mithrandir> use iodine.
<Mithrandir> much less crackful
<desrt> no package.
<Mithrandir> make one. :-)
<desrt> what is better about it?
<Mithrandir> I just haven't been arsed so far.
<Mithrandir> it works on !i386
<desrt> that doesn't concern me :)
<Mithrandir> and it doesn't make grown up developers cry and be scared to go to sleep.
<desrt> that does and has been concerning me :)
<desrt> iodine is a clever name.
<Mithrandir> it is
<sladen> psusi: if you ping, leave a useful message, cya?
<psusi> sladen: you pinged me earlier, never got together
<sladen> psusi: ah that was pointing out to you iwj's note about leaving a useful message with a ping.  (which iwj has not prefixed with your nick)
<psusi> ohh ;)
<psusi> rofl
<psusi> wow that is weird
<psusi> while I was merging changes with debian in the devmapper package, I happened to fix a high priority bug in passing without realizing it
<shaya> any chance gutsy will get a kernel fully compatible w/ powertop?
<mjg59> shaya: It has one
<shaya> ah it does, dist-upgrade just wasnt pulling it in as not depended on
<psusi> hrm... normally when I fix something I just upload the debdiff against the last version to the bug report... but in this case, I'm mering with a new upstream version, so I need to upload the new .orig, .dsc, and .diff.gz right?
<Hobbsee> psusi: preferably, yes
<shaya> mjg59: so are the suggestions of powertop going to be applied?
<shaya> for instance CONFIG_SND_AC97_POWER_SAVE
<mjg59> shaya: I'm planning on looking into that one
<shaya> I'm trying to figure out what's using so much usb on my t42p
<shaya> I knew bluetooth used it (disabled that) and that helped a bit, but can't figure out the rest
<Hobbsee> bah.  can someone please sync powertop so i can continue being lazy?
<shaya> hobbsee: its like 2 minutes to svn checkout ; make
<Hobbsee> shaya: but there's a package for debian, and it's nto in gutsy yet.
<shaya> is powernowd of any use today? (i.e. from the powertop page it seemed the kernel might do the speed scaling itself?)
<shaya> hmm, xorg is weird, can rmmod psmouse while its running
<shaya> mouse stops working
<shaya> modprobe it back in, mouse works agian
<psusi> so I should subscribe ubuntu-archive to a bug report for a debian merge request that I have completed?
<Hobbsee> psusi: no, you should subscribe ubuntu-{universe,main}-sponsors
<shaya> hmm, that was interesting
<shaya> just rmmod asus_acpi on my t42p
<shaya> oopsed
#ubuntu-devel 2007-05-18
<Hobbsee> anyone good with sparc's?
<Hobbsee> dh_testdir
<Hobbsee> rm -f client/buttons.h
<Hobbsee> cd client && sh -e create-buttons.sh
<Hobbsee> Bus error
<Hobbsee> make: *** [config.status]  Error 138
<Hobbsee> from http://librarian.launchpad.net/7689549/buildlog_ubuntu-gutsy-sparc.kde-style-polyester_1.0.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<TheMuso> Hobbsee: You have access to sparky do you not?
<TheMuso> On ubuntuwire?
<Hobbsee> TheMuso: i probably do, yes
<TheMuso> Test build it on that, and see what happens, and if things break, you can have a play.
<Hobbsee> hadnt thought of that.  was hoping someone might know offhand.
<freezone> is the current 2.6.20 kernel in Feisty bult with gcc 3.4 or 4.1?
<crimsun> Linux version 2.6.20-15-generic (root@palmer) (gcc version 4.1.2 (Ubuntu 4.1.2-0ubuntu4)) #2 SMP Sun Apr 15 07:36:31 UTC 2007
<freezone> oh, me silly 
<freezone> hm. i am still not able to build the vmware kernel module
<dholbach> good morning
<tepsipakki> bryce: I can do the xutils commits on git.d.o
<tepsipakki> xutils-dev, that is
<truz_`24> Is there a guide to compile kernel modules?
<truz_`24> All kernel module guides i read fail in ubuntu.
<mjg59> truz_`24: This isn't a support channel - #ubuntu is a better place to ask this
<truz_`24> k, thx mjg59
<bryce> tepsipakki: that'd be great
<Treenaks> seb128: what's the best way to get that nautilus trace/dump for you?
<seb128> Treenaks: Backtrace
<cjwatson> bryce: ok, neat
<seb128> ups
<seb128> https://wiki.ubuntu.com/Backtrace
<Treenaks> seb128: I've found the bug
<Treenaks> seb128: it's font related...
<seb128> ah
<Treenaks> (I have "size 7" fonts, because of my incredibly high DPI and wish to have small fonts)
* Treenaks files
<seb128> Treenaks: you mean it doesn't happen with size 10?
<Treenaks> seb128: exactly (size 8 even)
<seb128> looks like a pango bug
<Treenaks> 0x8185888 2007/05/18 07:20:41.2815 (GLog): eel_pango_font_description_get_largest_fitting_font_size: assertion `maximum_acceptable_font_size > minimum_acceptable_font_size' failed
<Treenaks> 0x8185888 2007/05/18 07:20:41.2968 (GLog): shape engine failure, expect ugly output. the offending font is 'DejaVu Sans Bold 0'
<Treenaks> that's what I get in my nautilus-debug-log.txt
<ogra> hmm, is there any way to delay the root mounting of the initramfs without rebuilding it (a kernel option or something) ?
<ogra> seems i have a race condition in mounting /root from a usb device
<ogra> does casper not wait for udevsettle ? 
<alex-weej> seb128: ping
<cjwatson> casper (1.88) UNRELEASED; urgency=low
<cjwatson>   * Add default values for root_persistence, home_persistence,
<cjwatson>     root_snapshot_label, and home_snapshot_label, and parse the persistent
<cjwatson>     command-line option, which went missing in the last merge from Debian.
<cjwatson>     This goes some way towards LP #84591 but doesn't quite fix it for me
<ubotu> Launchpad bug 84591 in casper "feisty 20070210/herd5 persistent mode doesn't work" [Undecided,Confirmed]  https://launchpad.net/bugs/84591
<cjwatson>     since the USB stick inexplicably doesn't appear until a little too late.
<seb128> alex-weej: content-less ping = no pong
<cjwatson>  -- Colin Watson <cjwatson@ubuntu.com>  Tue, 10 Apr 2007 17:35:57 +0100
<cjwatson> ogra: ^-- I couldn't figure out how to fix that
<cjwatson> it does call udevsettle
<ogra> does it wait for it to return as well ?
<cjwatson> yes
<ogra> hmm, very starnge
<cjwatson> indeed
<ogra> *strange
<cjwatson> I beat my head against it for a while but gave up
<cjwatson> ogra: BTW, I forgot to give your PCMCIA card back - is your address in Offices the right one to post it to?
<ogra> it would be great to have that optional ... in ltsp having udevsettle return immediately would be helpful 
<ogra> cjwatson, just bring it to the next meeting :) no need to bother about sending it around
<cjwatson> I like to keep accounts current where I can
<cjwatson> ogra: why call udevsettle at all if you don't want to wait for it?
<ogra> really its not worth the effort, i dont need it
<cjwatson> the point of udevsettle is to wait for it to complete ...
<ogra> well, its called in the udev initscript
<ogra> i'm still considering how evil it is to add an option to skip the wait
<ogra> on thin cliaents i have all modules loaded from initramfs and all devices i need to bring up X and sound are there the rest of udev is only helpful for local devices etc ...
<ogra> so not having the boot wait on it would speed up a lot ...
<cjwatson> you could divert udevsettle temporarily if you really don't need it ...
<ogra> during boot you mean ... hmm, that sounds intresting
<ogra> i'll see if i can find some testers for that
<ogra> on the e2300 (200Mhz) client i have here, the udev step eats about 40sec boottime
* ogra wonders if he should seriously write a patch for bug 48212
<ubotu> Launchpad bug 48212 in ltsp "ltsp's dhcpd fails after server is hibernated" [Wishlist,Confirmed]  https://launchpad.net/bugs/48212
<ogra> i wonder if thats really a common case
<floam> where is the most conclusive documentation on generating installable feisty LiveCDs? I'm doing a project for NASA and we are removing all of the branding, as well as some other custom things.
<floam> I am assuming you guys have scripts that do the bulk of the work
<cjwatson> at the moment, https://help.ubuntu.com/community/LiveCDCustomization/6%2e06 is about the best we have
<cjwatson> but we do have scripts that do it from scratch - for one reason and another they haven't been released up to now, but we should be making them publicly available RSN (I just need to sync up with infinity to get hold of the most recent production changes)
<cjwatson> that's the live filesystem builder portion; the bit that actually builds the ISO is http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ and the extra bits in configs/devel after checking that out
<cjwatson> anyway, for just removing the branding a customisation job might actually be easiest, per the wiki documentation above
<cjwatson> unless you already have a full package archive with the branding removed
<floam> well, I'm hacking up various artwork packages and packages with string changes and just giving them bumped version numbers, which probably isn't the best way to do it
<floam> I should probably make separate packages and make new metapackages
<floam> or something
<floam> not many changes, besides the rebranding and adding some stuff that's going to be used on the flight systems
<floam> cjwatson: so LiveCDCustomization/6.06 is indeed applicable to 7.04?
<floam> I saw that earlier today, but decided not to bother because of the version
#ubuntu-devel 2007-05-19
<Dabian> Hi, I hope I am in the right channel!?
<Dabian> Here is the situation:
<Dabian> I found that some of the files in xemacs21-base-support is required to be in another directory when you jde with GNU Emacs snapshot.  What is the proper way to fix this?  (A new package?  Adding the files to another package?  Simply let JDE and other packages that depend on these files depend on xemacs21-base and then copy the files, or modify the source to find the stuff in that directory?)
<Dabian> Hmm .. did you get all of that, or was I cut off?
<Dabian> I guess I could simply fix my own system and forget all about this .. but I like Ubuntu, and don't mind it to be even better. :)
<Dabian> I could paste tons of info here .. but I'd rather let you ask questions so I supply the needed information.
<Dabian> OK, I'll try in #Ubuntu or something.
<tormod> Dabian: please file a bug and supply all the information there.
<Dabian> tormod: Which package?  jde?
<Dabian> tormod: I wonder if there is a proper maintainer for that package .. there used not to be.
<Dabian> (At least for debian .. dunno about ubuntu, actually)
<tormod> Dabian: apt-cache show jde -> MOTU
<Dabian> !MOTU
<ubotu> motu is short for Masters of the Universe. The brave souls who maintain the packages in the Universe section of Ubuntu. See  http://wiki.ubuntu.com/MOTU
<Dabian> Thanks for the help.  I'll try to file a usefull bugreport, as soon as I find out how.
<Dabian> OK .. I filed a bug report.  Thanks:
<Dabian> https://bugs.launchpad.net/ubuntu/+source/jde/+bug/115527
<ubotu> Launchpad bug 115527 in jde "Compile from menu fails if you don't use xemacs" [Undecided,Unconfirmed]  
<Dabian> (I hope the bugreport is somewhat decent and helpfull)
<Murmex> Hi?
<Murmex> A few weeks ago I filled my first bug and I've just fixed it.
<Murmex> So following the Bugs/HowToFix, I'm looking for a developer to review my patch
<bryce> how do you attach image files to wiki.ubuntu.com?
<Murmex> bug 110865
<ubotu> Launchpad bug 110865 in hal "GNOME mounter rejects needed mount option" [Undecided,Confirmed]  https://launchpad.net/bugs/110865
<bryce> nevermind, I figured it out
* Hobbsee wishes for l-r-m for this kernel...
<Hobbsee> hey all
<ajmitch> hi
<Hobbsee> hi ajmitch 
<Hobbsee> wow, someone updated requestsync!
<Hobbsee> cjwatson_: ping
<Hobbsee> (not terribly time critical)
<mjg59> Hobbsee: I'd hope not, it's 5AM here :p
<Hobbsee> mjg59: 5am's a great time.  prior to today, i'd been getting up at 3am all week.
<mjg59> Yes, but you're jetlagged
<Hobbsee> this is true.  or was.
<mjg59> Of course, I've been jetlagged for a month or so
<Hobbsee> hehe
<mjg59> Only two more months and I'll be back in PDT, so it's almost not worth fixing it
<Hobbsee> heh
<Hobbsee> where are you now?
<Hobbsee> cjwatson_: okay, dont mind me, someone's used funky versioning
<mjg59> Cambridge
<mjg59> But I visited the US and haven't really got back on track
<Hobbsee> ahhh
<Hobbsee> tepsipakki: ping?
<Hobbsee_> suspend works, hibernate dies
<Hobbsee_> mjg59: well done!
<mjg59> Hobbsee: Is that progress?
<Hobbsee> mjg59: kinda.  i seem to recall that suspend was slightly buggered last time
<mjg59> What hardware is this?
<Hobbsee> mjg59: still, my hibernate dies every release, except for one, may have been dapper, but usually for a different reason
<Hobbsee> dell 6400
<Hobbsee> mjg59: (not sure which bit of hardware description you want)
<Hobbsee> gutsy it appears to shutdown, instead of hibernating, when one tells it to hibernate - and dump loads of stuff on to the screen while it does about USB....go figure
<Hobbsee> mjg59: 
<Hobbsee> May 19 14:36:27 LongPointyStick kernel: [  141.460000]  BUG: at /build/buildd/linux-source-2.6.22-2.6.22/include/linux/slub_def.h:89 kmalloc
<Hobbsee> _index()
<Hobbsee> worth reporting, or at least giving you a syslog?
<tritium> Hobbsee: please make my overscan problems go away... :)
<Hobbsee> tritium: good luck with htat.  i've done my upload count today...
<tritium> Hobbsee: it's only on my mythtv box connected to my TV
<tritium> Can't see the menu on top, or the panel on the bottom
<Mithrandir> hi Hobbsee 
<Hobbsee> Mithrandir!!!
<tepsipakki> Hobbsee: pong!
<Hobbsee> tepsipakki: that intel merge in universe that's listed as me - did you want to do it, as you've done most of the changes?
<tepsipakki> I could
<tepsipakki> hoped that there was a new patch release by upstream by now..
<tepsipakki> kylem told me that we will still keep -i810
<tepsipakki> but I'd like to know why it's considered too risky to dump ti
<tepsipakki> it
<Hobbsee> tepsipakki: right, OK.
* Hobbsee can go on happily ignoring it, then
<Mithrandir> tepsipakki: because it doesn't work on all hardware, iirc.
<tepsipakki> it has some issues with i830 IIRC, yes
<tepsipakki> ok, keep it for now but hopefully -intel is mature enough later in the cycle to dump -i810
<anibal> lionel, ping
<anibal> geser, ping
<geser> anibal: pong
<geser> Mithrandir: can you please look what happened to the vpnc upload to feisty-proposed which got accepted yesterday? it doesn't show up anywhere
<lionel> anibal: pon
<lionel> pong
<anibal> geser, lionel: I'm synchronizing pidentd with ubuntu
<anibal> geser, lionel: look at http://patches.ubuntu.com/p/pidentd/pidentd_3.0.19.ds1-1ubuntu1.patch
<anibal> geser, lionel: why " | inet-superserver"?
<lionel> "openbsd-inetd | inet-superserver" is what Debian use as a dependency for an inet-superver
<lionel> anibal: not sure to understand well your question
<anibal> inet-superserver is not a debian package
<lionel> it is a virtual package for server whichs provides an inet server
<lionel> $ apt-cache show openbsd-inetd | grep Provides
<lionel> Provides: inet-superserver, netkit-inetd
<anibal> I cannot find inet-superserver listed at http://www.debian.org/doc/packaging-manuals/virtual-package-names-list.txt
<lionel> there is an inetD-superver, but do not know more...
<lionel> the only thing I know is that inet-superver is used...
<anibal> geser, I suggest to drop " | inet-superserver" and reintroduce it later if we need it, what's your opinion about that?
<anibal> lionel, what's your opinion about dropping " | inet-superserver"?
<lionel> I'am clearly against
<lionel> as all the inetd package I can find "Provides inet-superserver"
<anibal> lionel, you're right, I did a test here to confirm what you said
<anibal> lionel, geser: thanks
<lionel> np, you're welcome
<Kmos> you can do merges her e?
<Kmos> her e?
<Kmos> ...
<Kmos> here..
<Kmos> any core-dev here to review a merge ?
<Kmos> and upload it
<geser> Kmos: it's weekend so you will don't find many core-devs before monday here and as k3b is a KDE package you might also want to look in #kubuntu-devel
<Kmos> :)
<Kmos> geser: ok
<minghua> freeflying: would you please have a look at bug 88179?
<ubotu> Launchpad bug 88179 in scim "[apport]  scim-launcher crashed with SIGSEGV in QTextCodec::fromUnicode()" [Medium,Confirmed]  https://launchpad.net/bugs/88179
<minghua> freeflying: it's KDE related and has 20 duplicates now
<minghua> freeflying: I have no idea what's wrong, so can you or other Kubuntu people give it some love?
<freeflying> minghua: I've suffered  it before, but can't reproduce now
<minghua> freeflying: can you ask other Kubuntu people?
<freeflying> minghua: sure
<minghua> freeflying: thanks
<freeflying> minghua: welcome
<pochu> Hobbsee: looks like -intel is broken due to the new xserver 1.3. Can you do your merge for it? :)
<Hobbsee> pochu: tepsipakki was looking into it, being the main changer
<pochu> Hobbsee: ok, cool :)
<freezone> i was reading an interview with Marc Shuttleworth in a linux magazine. he mentioned that IRC is the prefered communication method. do people like Marc Shuttleworth chat on Freenode?
<minghua> freezone: yes, he is around sometimes, although not exactly "chatting", I think
<freezone> lets say i feel like the chosen one who has 2-3 questions for Marc Shuttleworth, is there a way to contact him successfully?
<minghua> freezone: I am not sure, but I think email is a better option
<minghua> freezone: his first name is Mark by the way
<freezone> oh
<stgraber> freezone: btw, he's currently on this channel :)
* freezone blushes hard
<stijn_pol> some help please: checking for X... no    You need to supply the path to the X headers and libraries...
<stgraber> stijn_pol: Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) (topic ^)
<stijn_pol> woops
<stijn_pol> sorry
<stijn_pol> what is the right channel? ubuntu-motu?
<freezone> stijn_pol, tip: you need the package "xorg-dev"
<freezone> and support channel is #ubuntu i think
<freezone> but that channel is so huge it could need a split into specialized channels
* stgraber didn't join #ubuntu for ages, way too much traffic on it
<freezone> yeah
<ssam> is Bug #109204 suitable for an SRU?
<ubotu> Launchpad bug 109204 in gnumeric "Gnumeric strange colors (purple charts) on bigendian" [Undecided,Unconfirmed]  https://launchpad.net/bugs/109204
<gregshallard> hello
<stijn_pol> should I really try in #ubuntu for questions about packaging, building deb's...?
<ssam> stijn_pol, someone in #ubuntu-motu might be able to help
<freezone> stijn_pol, no. you asked something about compiling. that is trivial support questions i think
<stijn_pol> my fault, I should have mentioned I was trying around with pbuilder
<freezone> yeah, but "how do i find a missing library" is quite basic knowledge 
<stijn_pol> ok thanks
<gregshallard> hey, 
<gregshallard> Do you guys know what support is like for the Audigy 2 ZS Video Editor...?
<ssam> gregshallard, this room is for developer discussion, try #ubuntu
<gregshallard> How about developing drivers....
<Chipzz> gregshallard: if there's an ongoing effort, yes
<Chipzz> if you're asking to develop a driver, definite no
<gregshallard> where would I be able to find out about it?
<Chipzz> there most likely isn't
<Chipzz> ubuntu developers mostly package and/or patch software
<gregshallard> k
<Chipzz> or write software specific to ubuntu
<Chipzz> and software == desktop software mostly
<gregshallard> Where would the best place to look for support?
<freezone> the linux kernel mailing list might be a place to start
<gregshallard> Ok then, thanks for that.
<Chipzz> you might also try #ubuntu-kernel
<gregshallard> Ill have a look.
<gregshallard> Its fun having such specific hardware
<Chipzz> but AFAIK (I may be mistaken though) my best guess is that the people there rather decide on which (existing) patches to include in the ubuntu packages, rather than write big patches themselves
<Chipzz> you can also try the forums
<gregshallard> thanks cya rounjd.
<perlmonkey> hi guys
<perlmonkey> why does Ubuntu seem to have so many security vunerabilities on it's packages?
<Chipzz> it does?
<freezone> perlmonkey, are you trying to cause a flame war?
<perlmonkey> well the latest USN update on Ubuntu website shows over 400 vunerabilities 
<perlmonkey> freezone: no just trying to get a feel for Ubuntu's security and stability as I'm thinking about installing it 
<pochu> perlmonkey: aren't they fixed? ;)
<freezone> perlmonkey, if you are somebody who looks at the security history of a software to decide if that software is secure or not, then you wont have much choices on what to install
<Chipzz> perlmonkey: first, I'ld doubt these numbers reflect concurrent issues, if they're right at all. My guess would be that is the whole history. second, ubuntu has a vast amount of software
<freezone> the important part is the number of open bugs that are classified as "high priority"
<perlmonkey> so these vuneralities are inherient in the software and nothing to do with Ubuntu?
<Chipzz> perlmonkey: I think "windows" has a whole lot more issues if you're counting them the same way
<Chipzz> that is, including all software that was ever written for windows
<perlmonkey> well I come from Debian background (been running it for 10 years nearly), I'm not a fan of Windows
<freezone> that is leading in the wrong direction if you want to measure quality
<freezone> perlmonkey, and in 10 years of using debian you did not learn how to measure quality?
<Chipzz> perlmonkey: every single one of those issues has a 99.99% chance of having been an issue in debian too...
<Fujitsu> Chipzz: Somewhat more than that, I'd say.
<Chipzz> Fujitsu: well, there IS software ubuntu packages which debian doesn't ;)
<perlmonkey> true
<Fujitsu> Not that much.
<freezone> perlmonkey, after 10 years of using debian i assume that you know how bugs are classified and how security related problems are dealt with?
<Chipzz> Fujitsu: which is why 100% - 99.99% is only 0.01% ;;)
<Chipzz> perlmonkey: also, the chances of you having all ubuntu packages installed that were ever affected by a security issue is nil
<perlmonkey> it's good the vunerabilities are being dealt with by Ubuntu so quickly
<minghua> Fujitsu: not possible.  There are ~500 vulnerabilities, it's either 100% or 99.8% :-)
<perlmonkey> Debian is rather slow in that respect
<Chipzz> minghua: I was just pulling numbers out of my **** to make a point ;)P
<freezone> the point is not that a software package like bind has a long list of security related problems and that distributions that use such a package are to be blamed for that. quality assurance is a much more complex topic than looking at a few numbers.
<freezone> and a person who uses open source software for a few years could know about that
<ssam> perlmonkey, ubuntu has a no open ports by default (apart from dns dhcp and avahi)
<BenC> Can someone process NEW linux-source-2.6.22-5 for me please?
<BenC> have things in dep-wait for it (lum/lrm)
<hile> Anyone heard about gutsy X server crashes after latest xserver-xorg upgrade? I get a Plain Old core dump with i810/intel drivers, just thought if this is known problems or should I report it
<pochu> hile: xserver-xorg-video-intel from universe?
<hile> might be
<pochu> hile: yeah, it's broken, it needs I rebuild, I think
<pochu> hile: tepsipakki is working on it :)
<pochu> hile: we're going to sync/merge 2.0 from Debian
<hile> ok, just rebuild, let's see after I get new pkg then. 
<hile> tepsipakki, when you do the rebuild, inform me about the new pkg if you want a tester for it
<hile> I thought so, no reason to make a bug for such issue, gutsy is devel version anyway :)
<kylem> BenC, i can do it in  a bit
<kylem> once i finish cooking bfast.
<kylem> ;_)
<BenC> kylem: I keep forgetting you passed the archive training course :)
<Mithrandir> geser: I can't see any vpnc upload that got accepted
<geser> https://bugs.launchpad.net/ubuntu/+source/vpnc/+bug/93413 last comment
<ubotu> Launchpad bug 93413 in vpnc "vpnc dead peer detection disconnects immediately" [Medium,Needs info]  
<geser> pitti accepted it
<Mithrandir> geser: doesn't look like he actually accepted it
<geser> that would explain it
<Mithrandir> at least there's vpnc in the queue on https://launchpad.net/ubuntu/feisty/+queue?queue_state=1&queue_text=
<geser> so should I ask him on monday to proper accept it?
<Mithrandir> yes, or get me to do it on monday.
<geser> ok, thanks for looking
<Mithrandir> it's saturday evening here now and I don't really feel like pulling out my work gear to fix it, sorry.
<geser> np
<geser> enjoy the rest of the weekend
<Mithrandir> thanks. :-)
<ondra_> hi
<ondra_> I have a question - I created a package for debian and it is in debian unstable now. If I want to get it to ubuntu as well - is ubuntu syncing with debian unstable, or with debian testing?
<lfittl> ondra_, unstable
<ondra_> lfittl, thanks. do you know how often is it syncing? the package is python-sympy, it is in debian-unstable for about 4 days only, but I thougt that the sync is happening like once a day or so.
<lfittl> ondra_, this one: https://launchpad.net/ubuntu/+source/sympy ? :)
<ondra_> yeah, like that. I am new to ubuntu, thanks. :)
<lfittl> no problem :)
<_StefanS_> hi there
<_StefanS_> I stumbled upon the following line of code in network manager: "caps |= NM_802_11_CAP_KEY_MGMT_802_1X;", what does that |= mean ?
<_StefanS_> never seen that before :)
<lfittl> _StefanS_, I guess thats the same as "caps = caps | NM_802_11_CAP_KEY_MGMT_802_1X;"
<_StefanS_> lfittl: so if the variable 'caps' is empty it takes that defined
<_StefanS_> lfittl: NM_* 
<_StefanS_> well that was a wierd sentence :D
<_StefanS_> I mean, its like a ? : , right?
<geser> that's a binary OR
<lfittl> _StefanS_, exactly
<_StefanS_> :) goody, thanks
<_StefanS_> just had to ask :)
<lfittl> _StefanS_, but its not like ? :, it is a simple binary OR, as geser said (but it does what you want, if caps is empty it takes the NM_ define)
<_StefanS_> ok, I was trying to add support for LEAP in the knetworkmanager, and got kinda confused looking at that line since I need to mimic the key_mgmt like it is in the gnome applet
<lfittl> _StefanS_, ah, nice work, good luck on that stuff :)
<_StefanS_> lfittl: oh thanks :) - I managed to crash my knetworkmanager instance just now, but thats all part of the fun :)
<_StefanS_> lfittl: I might bug you guys at a later time perhaps
<lfittl> _StefanS_, feel free to do that, but I don't know the network manager code, and also have no main upload rights, sorry ;)
<_StefanS_> thats ok, I think I will submit the stuff to upstream, and have it in before the import freeze anyways :)
<lfittl> :)
* _StefanS_ crosses fingers
* Starting logfile irclogs/ubuntu-devel.log
(etteyafed_/#ubuntu-devel) Any thoughts on upgrading to abiword 2.5.0 or 2.5.2 ahead of debian?
(Hobbsee/#ubuntu-devel) fabbione!
<fabbione> Hobbsee: !
* fabbione needs to have a few words with his ISP
<Hobbsee> :)
<Hobbsee> oh?
* etteyafed_ is sorry for the silly idea
<fabbione> Hobbsee: they managed to upgrade badly my adsl while i was away
<Hobbsee> fabbione: fun....
<fabbione> hence everything screwed up
<Hobbsee> ahhh
* etteyafed_ now sees that upgrading to dev version is stupid, even though we do it with compiz ;)
* Treenaks is happy to _work_ at his isp :)
<EnolaGay> hi all
<Treenaks> (if I my stuff breaks, I get to kick my colleagues, or myself)
<EnolaGay> I have tried to retrace a xorg crash (sudo apport-retrace _usr_bin_Xorg.0.crash) but always got this error: "report file does not contain required fields: CoreDump Package ExecutablePath"
<pochu> EnolaGay: a "cat _usr_bin_Xorg.0.crash" might help
<EnolaGay> pochu: looks fine
<pochu> at least it did for me with a listen crash
<EnolaGay> pochu ExecutablePath: /usr/bin/Xorg
<EnolaGay> is correct afaik
<micahcowan> Does the kernel package not use a patching system?
<micahcowan> If I wish to prepare a debdiff, do I just modify the source directly, alter the changelog, and go?
<pochu> EnolaGay: then report a bug against apport in lp :) I'll confirm it ;)
<EnolaGay> pochu: ok
<EnolaGay> pochu: Is there another possibility to get a dump from this report?
<EnolaGay> and btw. no apport gui tells me from the crash but this could be a general problem when xorg crashes
<EnolaGay> maybe because the file is only accessible by root
<EnolaGay> pochu: There is alread a bug report. https://bugs.launchpad.net/ubuntu/+source/apport/+bug/95396
<ubotu> Launchpad bug 95396 in apport "[feisty]  Apport-retrace can not retrace a local crash report." [Undecided,Fix released]  
<pochu> EnolaGay: fix released?
<EnolaGay> I know, but not for me :)
<EnolaGay> So I should create a new one?
<pochu> EnolaGay: or use -R, as the report says
<EnolaGay> ok
<EnolaGay> seem to work but wasn't mention in manpage
<pochu> EnolaGay: file a bug :p
<EnolaGay> Great, I have to restart since I am using a different xorg driver
<EnolaGay> pochu: Thanks for your help.
<EnolaGay> cu
<EnolaGay> pochu: Now apport-retrace crashes :)
<EnolaGay> After downloading the files. It seems not to be able to install them. Don't know.
<EnolaGay> It looks like I need another PC to use gdb to create a core dump.
<EnolaGay> pochu: http://pastebin.ca/497513 the apport-retrace crash report if you are interested
<pochu> EnolaGay: report the Traceback to launchpad :)
#ubuntu-devel 2007-05-20
<EnolaGay> pochu: Make a new bug report?
<pochu> EnolaGay: yep
<EnolaGay> :)
<acm> Hi, I would like to know what is planned for enabling 3d effects in gutsy? many people in #ubuntu-de have problems to enable them especially ati user.
<EnolaGay> pochu: I wonder why apport-gtk doesn't pop up because of this crash. Should I upload the report as an attachment?
<EnolaGay> acm: I think it is a driver problem but at least Radeons have an working 3d open source driver afaik.
<pochu> EnolaGay: it won't hurt :)
<EnolaGay> pochu: finally https://bugs.launchpad.net/ubuntu/+source/apport/+bug/115681 :)
<ubotu> Launchpad bug 115681 in apport "apport-retrace crashes after downloading dbgsyms for a xorg crash" [Undecided,Unconfirmed]  
<acm> EnolaGay: Yes I agree with that driver problem. But for me the radeon driver doesnt work on my thinkpad. There should be an automated workaround for fglrx driver, because the driver works with xgl. the configuration is more complicated.
<EnolaGay> acm: Ask AMD ;) I don't know, I am no dev.
<lfittl> acm, automated workaround is not possible, as XGL is a completely different x server that is not supported in Ubuntu
<EnolaGay> acm: Btw why a 3D Desktop. It looks not bad but is has no real advantages imho and at the moment some disadvantages like not working vnc and problems with playing movies.
<sn0> EnolaGay why not ? :}
<sn0> the option is there, you can disable certain functions if you deem them not useful
<EnolaGay> And it crashes for me more often.
<sn0> having everything rendered by the gpu has its advantages
<EnolaGay> sn0: Do you know something about the energy consumption?
<sn0> well crashes are common + it is early days yet
<sn0> you can compare it to running a 3d game really EnolaGay 
<pochu> EnolaGay, acm: it's planned: https://blueprints.launchpad.net/ubuntu/+spec/composite-by-default
<sn0> but i find my card runs cooler with beryl/compiz running than at full peak in a 3d game
<EnolaGay> Hm, that wouldn't be good for laptops.
<sn0> obviously uses more than no acceleration
<sn0> going by intels power tool they released it seems certain apps can cause more power drain/causing the cpu to wake up
<sn0> so there is a lot to be done
<EnolaGay> sn0: Do you know if the fixes are released in gutsy?
<Hobbsee> probably not yet
<sn0> the intel tool is a seperate download, not sure about plans for gutsy
<Hobbsee> UDS was only a week ago, gutsy hasnt been open terribly long
<EnolaGay> sn0: It sounds great but I doubt if it let the laptop run three hours longer.
<pochu> EnolaGay: gutsy still have same compiz (0.3.6)
<EnolaGay> sn0: I know I mean the fixes of intel and other devs.
<sn0> EnolaGay fyi http://www.linuxpowertop.org/powertop.php
<sn0> that has nothing to do with gpu / composite acceleration mind
<EnolaGay> I know. I don't ask for composite it is just if the program and kernel patches of Intel are integrated in Gutsy?
<sn0> https://blueprints.launchpad.net/ubuntu/+spec/powertop-support :)
<EnolaGay> cool
<pochu> EnolaGay: sudo apt-get install powertop ;)
<Hobbsee> pochu: doesnt seem to be there at all, yet
<Hobbsee> sn0: that's not written by a developer
<pochu> Hobbsee: it's already been synced, though
<Hobbsee> and has no developer input on it
<Hobbsee> pochu: exactly.  i'm wondering where it is
<EnolaGay> Funny is that one of the biggest energy consumer in Linux versus Windows are the Intel WLAN drivers. They consumes much more than under win. I know that they have a patch for ip2100 and a workaround for 3xxx but there are other cards and I think it is not as good until now.
<pochu> Hobbsee: I've installed it from Debian :)
<sn0> Hobbsee there is nothing official on it yea, its early days yet 
* Hobbsee wishes for more updates
* sn0 has become patient in waiting
<Hobbsee> pochu: what was the package name?  even my madison-lite isnt finding it.
* Hobbsee should break some more.
<sn0> ahd i see it is paying off, icedove2 for sid is almost here for i386 :] 
<pochu> Hobbsee: powertop
<Hobbsee> pochu: ahhh.  it's failed to build.
<bhale> Hobbsee: your madison is busted :)
<EnolaGay> Powertop doesn't help until Kernel 2.6.21 afaik
<bhale>   powertop |      1.1-3 | http://archive.ubuntu.com gutsy/universe Sources
<Hobbsee> or si under a different name
<Hobbsee> bhale: yeah, found that much.  the binaries are good, though
<EnolaGay> ok, gutsy has a 21 kernel
<pochu> Hobbsee: it's built fine: http://librarian.launchpad.net/7703469/powertop_1.1-3_i386.deb
<Hobbsee> bhale: ah, i'tll be in binary NEW
<pochu> no, it's been approved :)
<Hobbsee> whcih is why my apt-cache isnt finding it.
<bhale> Hobbsee: yes ma'am
* bhale ducks
<Hobbsee> :P
<Hobbsee> pochu: approved when, and for what?
<pochu> powertop. It's not in NEW. cjwatson processed it
<Hobbsee> hmmm
<pochu> Hobbsee: https://launchpad.net/ubuntu/+source/powertop/1.1-3
<desrt> hello birdies
<Hobbsee> http://archive.ubuntu.com/ubuntu/pool/universe/p/powertop/
<EnolaGay> Ok, thanks for help and good night.
<Hobbsee> pochu: i realise that.  but the binaries are not in the archive yet, which makes me think that it's gone thru source NEW, but not binary NEW.  or that soyuz has eaten it.
<Hobbsee> unless they've changed procedure
<acm> EnolaGay: I think so too, but many other people like to have 3d desktop enabled. maybe only to show their friends that are using windows ;)
<bhale> Hobbsee: fyi https://launchpad.net/ubuntu/gutsy/+queue
<pochu> Hobbsee: bug 114417
<pochu> I don't know why the binaries aren't in archive.u.c
<Hobbsee> bhale: ah, thanks.
<bhale> because they are in NEW
<ubotu> Launchpad bug 114417 in Ubuntu "Please sync powertop from Debian unstable" [Wishlist,Fix released]  https://launchpad.net/bugs/114417
* desrt installed feisty on his breezy-running quad-core powerpc G5 workstation at school yesterday
<bhale> can we please move on or offtopic this?
* Hobbsee lost that bookmark
<pochu> bhale: Processed through NEW. For future reference, you don't need to file bugs for syncs of new packages from Debian before the Debian import freeze.
* desrt was shocked at the difference
<Hobbsee> pochu: there are 2 NEW's.  it's only gone thru the first one.
<bhale> pochu: sorry?
<Hobbsee> <end>
<desrt> Hobbsee; heh. you wish.
<pochu> </end>
<pochu> :)
<Hobbsee> :P
<Kmos> Hobbsee: can you upload from merges ?
<bhale> pochu: the only sync bug i filed was for evo-sharp, which had local ubuntu changes and would not have synced.. i falsely believed that it work work, recently added EDS "too new" check and failed.
<Hobbsee> Kmos: upload *from* merges?
<bhale> pochu: not sure what else you are talking about
<Kmos> Hobbsee: http://merges.ubuntu.com/k/k3b/
<Kmos> k3b v1.0.1 is there
<Hobbsee> Kmos: ie, do the merge
<Hobbsee> yes i could.
<Kmos> Hobbsee: plz do it :)
<Kmos> for gutsy.. and it would be nice to see it on feisty backport soon
<Hobbsee> however, if you look at the report, you'll see that it's not merged cleanly.
<Hobbsee> Kmos: why dont you?
* Hobbsee has been merging other things.
<pochu> bhale: I was taking about powertop, which was already proccesed trough new. Sorry if you weren't talking about it, it seems I misunderstood you :)
<Kmos> Hobbsee: i can't do that.. i'm not a ubuntu member
<Hobbsee> you dont need to be
<Hobbsee> you'd need to be in core dev to upload anyway
<bhale> pochu: ok, maybe i can clear this up for you...
<Hobbsee> that's why there are sponsorships
<bhale> pochu: see https://launchpad.net/ubuntu/gutsy/+queue?queue_state=0&queue_text=powertop
<Kmos> Hobbsee: i'm not a core-dev too hehe
<bhale> pochu: there is NEW for new sources, and NEW for new binary names
<bhale> pochu: if you have a brand new source (powertop), it hits both, it is in the later state
<bhale> pochu: it is not 'cleared' really
* Kmos is installing Feisty on his laptop ACER 5633WLMi :)
<Hobbsee> Kmos: i havent done so, mainly because i didnt touch it last, and i'd need a sponsor - which is often hard to find on a weekend.
<pochu> bhale: so it has been processed trough NEW source, but not from NEW binary?
<pochu> That makes sense :)
<Hobbsee> pochu: exactly
<bhale> pochu: yes.
<pochu> ok :)
<Kmos> Hobbsee: ok.. yeah, weekend it's hard for that
<bhale> pochu: for example, the name of evolution-sharp binary has changed, so it is stuck in binary new
<pochu> Anyway, the binary is there at launchpad ;)
<pochu> bhale: ok :) I think I understand the process now :)
<pochu> thanks a lot :-)
<bhale> np :)
<pochu> Wakeups-from-idle per second :  331.6 
<pochu> it should be under 3, so I'm 100x :/
<pochu> luckily I'm plugged to the AC :)
* Hobbsee ponders....breakfast, or do a merge / fix breakage...
<bhale> weird, my #1 interupt is uhci_hcd (usb)
<bhale> nothing usb is plugged in
<lathiat_> nothing internally usb, liek bluetooth on laptops, etc?
<bhale> hm, bluetooth
<bhale> but nothing should be using it
<lathiat_> be interesting to see if its that driver causing it
<acm> where can I see current state of a blueprint? Do I have to mail the drafter?
<pochu> acm: look at the status in the blueprint
<pochu> e.g. started, beta available, blocked...
<acm> pochu: drafting is the current state. I think there should be something to code, but I dont know which package etc. Btw. Iam new at doing some work to ubuntu and Iam looking for an project to contribute to.
<acm> but drafting means there isnt any code yet right?
<bhale> lathiat_: it was bluetooth. which is probably sucking its own power besides
<bddebian> Heya
<Hobbsee> hi all
<jsgotangco> hey Hobbsee
<Hobbsee> spam!!!
<jsgotangco> gah!
<fabbione> OMG she is around!
* fabbione hides
<Hobbsee> indeed!
* Hobbsee hunts fabbione 
<Hobbsee> fabbione: are you scared yet?
<fabbione> Hobbsee: hmmm no
<Hobbsee> fabbione: oh.  you should be, 'im sure.
<fabbione> :)
<fabbione> i am too tired to even be awake
<fabbione> nevermind scared
<Hobbsee> lol
<ajmorris_> how close are we to getting ntlm_auth 3.0.25?
<ajmitch> ajmorris_: if you mean the one from samba, real soon (in gutsy)
<ajmorris_> ajmitch, kk, cool, i am using gutsy
<nuu> morning
<Hobbsee> hi all
<pitti> hi Hobbsee 
<Hobbsee> pitti!
<nuu> hi Hobbsee, pitti
<pitti> hey nuu
<Hobbsee> heya nuu 
<nuu> pitti, you're the hal developer, aren't you :)
<pitti> nuu: well, I package it
<nuu> ah, great, been looking for you
<nuu> i've a doubt concerning hal and policy directories
<nuu> do you have a minute ?
<pitti> I think so, just ask
<nuu> https://answers.launchpad.net/ubuntu/+source/hal/+question/6836
<nuu> in two words, my kubuntu feisty ignores .fdi policies under /etc/hal/fdi/policy, while it picks that policy under /usr/share/hal/fdi/policy/10osvendor
<nuu> and i'm trying to understand whether this is by design or not, since it works under /etc/hal/fdi/policy on debian
<pitti> nuu: hm, it doesn't evaluate /etc/hal/fdi/policy/preferences.fdi ?
<nuu> preferences.fdi is all commented out
<pitti> nuu: it's certainly not by design, we don't touch the policy parser in Ubuntu compared to Debian
<nuu> incidentally that commented out preferences.fdi is the only file under the whole /etc/hal dir tree
<nuu> which made me wonder what the purpose of the dir is, but i know next to nothing about hal's directory structure in the first place
<nuu> which in turn led me to confusion, posting that question on launchpad, and bothering you :)
<pitti> nuu: it's not used at all in the distro, so noone else checked this so far, I figure
<nuu> i see pitti, so theoretically one could merely symlink /etc/hal to /usr/share/hal and problem solved
<nuu> because i figure that if ntfs-config uses /etc/hal, who knows who else uses it
<ajmitch> hi pitti 
<Hobbsee> hi ajmitch 
<pitti> nuu: I closed the answer request with 'please file a bug'
<pitti> hi ajmitch 
<ajmitch> & hi Hobbsee 
<nuu> alright pitti, thanks for your time
<Fujitsu> pitti: Was my rationale for renaming sixpack good enough?
<pitti> Fujitsu: yes, it was; thnaks
<Fujitsu> Thanks.
<Hobbsee> ajmitch: so, exactly what am i supposed to say on the ML?
<nuu> pitti: bug filed, thanks for the responsiveness
<pitti> nuu: thanks to you
<ajmitch> Hobbsee: knowing that you actually mean to go for core dev would be a start
<Hobbsee> ajmitch: right.
<Hobbsee> ajmitch: which would of course be helpful if i knew what i had to do to get it.
<ajmitch> it would, wouldn't it?
<ajmitch> TB meeting is in a couple of days
<ajmitch> we'll find out then
<macneib> hello everyone.  I just read about Ubuntu on embedded systems.  Is there anywhere i can go to read up on this?
<Hobbsee> ajmitch: right.
<Hobbsee> ajmitch: 6am meetings.  dammit.
<pochu> macneib: https://wiki.ubuntu.com/MobileAndEmbedded
<ajmitch> caffeine is good
<bhale> hi
<macneib> thanks pochu
<ajmitch> hello bhale 
<Hobbsee> ajmitch: it's not that good
<pochu> Hobbsee: with your jetlag that shouldn't be a problem ;)
<pochu> macneib: np
<Hobbsee> pochu: that's going away.  now i'm just plain exhausted all the time
<ajmitch> Hobbsee: ah, into the fun part of jetlag
<Hobbsee> yep
<ajmitch> I wish some of these complaints on the forums could be filed as actual bugs
<Hobbsee> fix bugs, dont waste time on the forums.
<Hobbsee> far more useful
<bhale> i wish i wasnt at the end of a ~600 package NEW queue
<Hobbsee> at the end of?
<bhale> most recent, not that it is fifo
<ajmitch> Hobbsee: I was just doing some merging
<Hobbsee> bhale: ohh, right. yes
<Hobbsee> ajmitch: good man.
<ajmitch> with a few tricks with debdiff & filterdiff, it's quite easy to patch things into the newer version without MoM
<Hobbsee> likely, true
<Hobbsee> but MOM makes it easier :P
<ajmitch> in many cases, not all
<ajmitch> besides, I wanted to review each change for samba separately
<Hobbsee> ahhh
<ajmitch> not sure if I should upload it yet, or grab the patches from the 3.0.25 svn branch that are needed
* ajmitch should sleep now & upload the lot in the morning, when people are alive
* Hobbsee plays dead
<Kmos> ajmitch: http://merges.ubuntu.com/k/k3b/ -> you've time to take a look at k3b v1.0.1 and upload it ?
<ajmitch> see the bit about sleeping now :)
<Kmos> :(
<ajmitch> you prepared a merged package?
<Hobbsee> Kmos: and the fact that the merge is there in no way means that it's done
<Hobbsee> ajmitch: no he hasnt, he's hoping someone will do the merge for him
<ajmitch> ah, that's very different
<Hobbsee> (we had this discussion this morning)
<ajmitch> there are a large number of conflicts there
<Kmos> persia has done the diff
<ajmitch> night all
<Hobbsee> night ajmitch 
<Ng>  /win 160
<Ng> gah
<Spads> that's a *lot* of windows.
<pochu> Ng: 160? :)
<Hobbsee> Spads: i saw some 3**'s at UDS
<Ng> I wait for screen to crash to clean them up ;)
<Ng> and that hasn't happened since sometime last year ;)
<Spads> huh
<Spads> I tend to /wc rather agressively so I can Alt-# and Alt-[qwertyuio] 
<Spads> but usually I alt-A 
<Hobbsee> heh
<thom> Spads: i have more _channels_ than that!
<Hobbsee> the 3** users were using a lot of /win goto foo
<Hobbsee> thom: yes, but you're crazy.
<thom> Hobbsee: hrm, this is a definite possibility
<thom> but bitlbee doesn't exactly help, either :-)
<Hobbsee> heh
<bhale> hi thom 
<thom> hey dude!
<Treenaks> so.. does anyone have working battery monitoring support for their bluetooth mice? :)
<Treenaks> Apparently, my mouse does report battery state.. but I haven't found a way to retrieve it yet ;)
<cy_`> hello
<cy_`> which tool does modify the xorg.conf when booting ? :/ nobody in #ubuntu could help me.. sorry for asking in here..
<Mithrandir> none
<cy_`> thats wierd.
<cy_`> because i copied an image of ubuntu installation to a disk, adjustet grub and everything.. and clearly the Driver in the xorg.conf was fglrx .. after a first boot of the system the Driver was changed to vesa :?
<Mithrandir> well, there's nothing there which changes it, unless you're booting a live cd.
<cy_`> nope.. booting a installed system i copied over using a tar file .. 
<cy_`> now i changed it back manually, rebooted and it didnt change.
<cy_`> ehw, this is strange :?
<cy_`> it changes the Xkblayout, the Resolution and the Driver.. does that sound familiar anyhow :/
<cy_`> ?
<desrt> hello hackers.
<bhale> hi desrt 
<desrt> what's an easy way to find out if my stdout is the linux virtual console driver?
<desrt> (and not, for example, a serial console)
<Treenaks> desrt: uh.. _why_?
<Treenaks> (why isn't isatty() enough? + termcap?)
<desrt> i'm thinking about doing some sort of vc-only ioctl and checking if it fails :)
<desrt> Treenaks; in the case of serial console we don't know TERM
<desrt> (yet)
<Treenaks> desrt: uh.. what are you writing?
<desrt> https://blueprints.launchpad.net/ubuntu/+spec/friendly-recovery
<Treenaks> desrt: can't you ask HAL?
<desrt> from single user mode?  i suspect not.
<Treenaks> desrt: if the device has capability: serial it's a serial port :)
<Treenaks> desrt: and it's another dependency, which you don't want, I understand
<desrt> let me be more specific: i have a fd.  what syscalls and/or libc functionality can i use to determine if it's the linux virtual console driver?
<Treenaks> desrt: I think the ioctl thing is your best bet
<desrt> how hacky :p
* desrt makes some tea
<thesaltydog> which is the daemon name for apport?
<dsas> thesaltydog: As far as I remember apport isn't a daemon, it's a program called by the kernel when an app crashes
<thesaltydog> dsas, ok, so there is nothing running on background in the services list?
<dsas> thesaltydog: Not as far as I remember.
<thesaltydog> thanks
<wereHamster> can I see the output when you folks build the wine package? Or even the config.log file?
<wereHamster> I'd like to see how exactly you configure the wine package..
<ThunderStruck> were grab the source with apt-get source wine and look in rules file for config options (unless there is a differnet file that holds them for wine
<ThunderStruck> wereHamster, ^^^
<geser> wereHamster: http://librarian.launchpad.net/7705044/buildlog_ubuntu-gutsy-i386.wine_0.9.37-0ubuntu2_FULLYBUILT.txt.gz is the log from the last i386 build
<wereHamster> I don't run ubuntu, that's the problem ;)
<ThunderStruck> unless ofcourse someone has it handy ;)
<elpargo> hi I notice http://packages.ubuntu.com/ is down. anyone knows if this was scheduled?
* Starting logfile irclogs/ubuntu-devel.log
<tormod> #ubuntu-ch
* tormod has some issues with xchat-gnome not keeping up :)
<phoenix24> tormod: what's the problem ?
<tormod> phoenix24: just that it pops up windows and dialogs when I am typing in commands, therefore my little "message" came up as above in this channel!
<Nafallo> hi everyone :-)
<pochu> hey Nafallo!
<calc> doko_: hello
* Starting logfile irclogs/ubuntu-devel.log
* calc wonders why doko never called him
#ubuntu-devel 2008-05-12
<pwnguin> is this an appropriate channel to discuss free/nonfree inclusion of documentation?
<pwnguin> bug #32042 is about openGL documentation
<ubottu> Launchpad bug 32042 in mesa "OpenGL subroutine man pages missing" [Low,Confirmed] https://launchpad.net/bugs/32042
<LaserJock> pwnguin: what did you want to discuss?
<pwnguin> well, I'd like to see the bug fixed
<pwnguin> but i haven't seen anything representing a decision. they're technically non free as is, because of a requirement to notify SGI if you are made aware of an IP claim by a third party
<pwnguin> does ubuntu regularly NOT tell copyright holders when sued?
<ScottK> It doesn't matter really.
<ScottK> pwnguin: The best solution is to make a separate -doc package and put it in Multiverse.
<pwnguin> the only developer comment in that bug is that it cannot be distributed =/
<pwnguin> ScottK: if mesa is in main, wouldn't it be restricted?
<ScottK> If it can't be distributed, then it can't go in at all.
<ScottK> Restricted has some very special things that go in it.  I'd expect it's in multiverse if at all.
<pwnguin> as far as my lay interpretation of the troublesome clause goes, it's not a restriction per se on distribution
<pwnguin> just an additional burden
<fta> stgraber, would you accept this: http://www.sofaraway.org/ubuntu/tmp/pastebinit-01-ubuntu.patch ? and this (on top) http://www.sofaraway.org/ubuntu/tmp/pastebinit-02-mozilla.patch ?
<awen_> would it be appropriate to subscribe ubuntu-main-sponsors for a patch like bug 200750 ? ... or should i rather try contacting the last uploader of the package instead
<ubottu> Launchpad bug 200750 in inkscape "Add python-uniconvertor to Recommends and patch inkscape (for Corel Draw formats support)" [Medium,Confirmed] https://launchpad.net/bugs/200750
<ScottK> awen_: Don't we still need python-uniconverter in Ubuntu first?
<ScottK> awen_: Then generic answer though is subscribe ums.
<awen_> ScottK: it got included a few days ago
<ScottK> awen_: Launchpad doesn't seem to know about it that I can find.
<awen_> ScottK: https://launchpad.net/ubuntu/+source/python-uniconvertor
<ScottK> I see LP search functions are working as well as usual.
<ScottK> IIRC bryce is involved in inkscape and might be good to ask too.
<awen_> okay, thanks ... i've subscribed ums anyway though
<awen_> bryce: if you are involved in inkscape and have a minute, please have a look at the above
<TheMuso> /c/c
<slangasek> ScottK: right, well, I guess I'll roll back hal and see what that gets me for starters
<emgent> morning
<tseliot> ï»¿emgent: morning
<emgent> heya tseliot
<emgent> :)
<Riddell> pitti, doko: four MIRs needed for KDE 4 when you have time
<stgraber> fta: Both patches look good, are those done for the current version in Ubuntu or the version we have in bzr ?
<emgent> Riddell: heya
<Riddell> hi emgent
<Riddell> it's another european holiday today? they just had one!
 * TheMuso is wondering why -devel is so quiet.
<Riddell> Whit Monday apparantly, guess they're all in church
<Ng> they?
<Ng> are we not european now? ;)
<Riddell> not so you'd notice by the different numbers of bank holidays :)
<Spads> The UK is in Africa, clearly.
<\sh> at least it's such a nice day for doing merges and drinking some beer at home ,-)
<TheMuso> Hrm. Is it just me, or is launchpad taking a while to respond to http requests?
<\sh> TheMuso: here too...at least launchpadlibrarian
<TheMuso> \sh: Yeah thats what I'm trying to access as well.
<\sh> TheMuso: it's doomed ;)
<TheMuso> \sh: heh I just managed to get the diff I wanted, so I'm fine for now.
<\sh> TheMuso: fun,..me too :)
<pochu> not a holiday in Spain :(
<hwilde>    Device Boot      Start         End      Blocks   Id  System
<hwilde> /dev/sdb1               1       19458   156289848+  42  SFS
<hwilde> what is filesystem SFS ?  it won't mount with ntfs
<cjwatson> SFS is partition type (hex) 42
<cjwatson> doesn't necessarily correspond to the filesystem actually on that partition
<cjwatson> use 'sudo vol_id --type /dev/sdb1' to find that out
<hwilde> "/dev/sdb1: unknown volume type"
<hwilde> I guess that's their fault for letting windows merge their partitions
<hwilde> who knows what that did
<hwilde> cjwatson, do you know Simon
<hwilde> Tatham
<\sh> sabdfl: nice post about "The Art of Release"
<cjwatson> hwilde: yes, why?
<hwilde> because putty freakin rules
<hwilde> chiark++
<cjwatson> putty is indeed superb, that's why I maintain its Debian package ;-)
<\sh> sabdfl: but one thing you forgot: "How do we get other software vendors like adobe to test and release and support their enterprise software for Ubuntu LTS versions"...I do think as an example of Adobe Flash Media Server...
<hwilde> cjwatson, any way to control the display font tho?  it's too big
<cjwatson> hwilde: sure, -fn, or ctrl-rightclick -> Change Settings -> Window -> Fonts -> Change...
<hwilde> cjwatson, I mean in the putty window itself.  before you connect
<hwilde> I have the profile set for the terminal windows
<hwilde> it's like 14pt font size
<cjwatson> that's just whatever GTK's defaults are - however, ability to configure this consistently with the rest of the system should improve once the GTK2 port of putty finally lands, which should be fairly soon
<cjwatson> (assuming this is Linux putty rather than Windows putty; I don't know much about the latter)
<hwilde> ooo gtk2
<hwilde> gtk-theme-switch seems to do it :)
<fta> stgraber, against ubuntu, there was no Vcs-Bzr in debian/control
<fta> stgraber, I have a small fix too: http://www.sofaraway.org/ubuntu/tmp/pastebinit-03-fix.patch
<stgraber> fta: https://code.launchpad.net/~pastebinit-developers/pastebinit/trunk
<TheMuso> c
<TheMuso> ugh
<\sh> TheMuso: ugh?!
<TheMuso> \sh: Meant for my mutt window.
<\sh> TheMuso: doesn't mutt make "whee" instead of "Ugh"? ;)
<TheMuso> \sh: heh
<fta_> stgraber, if you prefer, i can branch that and you'll just have to merge
<stgraber> fta_: yes, that or a patch based on the current bzr revision would rock. I don't have a lot of time to spend on pastebinit but I plan to push a new version in Ubuntu for Intrepid if David or someone else don't send it to Debian before
<fta_> ok, i'll do that then
<sabdfl> \sh: yes, we have some work to do in getting the ISV's to embrace our release cycle
<sabdfl> though LTS's are a pretty obvious target for them
<\sh> sabdfl: yes...even that adobe is not playing nice with rhel in general...anyways..this is really what's missing for serious "non webserver mass rollouts of ubuntu" ;)
<maswan> \sh: There is alot of other enterprisy software/hardware that I'd like to see support for over anything from adobe, but then I'm not doing much consumer-related stuff. :)
<hwilde> how about visio :)
<maswan> hwilde: what's that?
<hunger> Could somebody push the perl stuff that is still build against the old perl version into the build queue again, please?
<hwilde> that's the only proprietary thing I haven't been able to hack yet.
<hwilde> like flowcharts and stuff.  (think dia)
<\sh> hwilde: visio is just nice with the Datacenter Planning Plugin ;)
<hwilde> \sh, gimme
<cjwatson> hunger: if it's already built successfully, it needs a developer to reupload (with build1 versioning, or incrementing the number after ubuntu if it's modified)
<cjwatson> we don't have a way to do that automatically
<maswan> hwilde: ok, never used it. I'd just like vendor support for ubuntu connected to tape libraries, etc
<hwilde> maswan, now that dell is offering preinstalled we will see an increase in vendor support
<hunger> hwilde: Try kivio. It works ok, even though it does not have too many stencils.
<maswan> hwilde: they are doing that in the server space now?
<\sh> maswan: yes, there are more software/hardware things to support...but right now, those FLV streaming stuff is the way to go...and seeing that ISVs who are supporting their software for RHEL or SLES only it's depressing me..because most of the software runs just fine on debian/ubuntu..but you are stuck with support from the ISVs when running on non-supported OS..and OS doesn't mean "Linux in General" but "RHEL" or "SLES" and not "LTS" ;)
<\sh> hwilde: dell is not pushing ubuntu on servers...not right now, it's sad...I would like to see e.g. HP or IBM to push their hardware (especially blade stuff) with ubuntu..because it just works
<hwilde> maswan, scheduled to announce Q1 next year  http://www.linux-watch.com/news/NS4557593896.html  http://www.theregister.co.uk/2007/11/16/dell_ubuntu_servers/
<maswan> \sh: I know, I know.
<fta> stgraber, done: https://code.edge.launchpad.net/~fta/pastebinit/trunk  Please review and pull :)
<\sh> maswan: btw...did you already had hands on the new areca sata raid crack?
<maswan> \sh: I just see a different set of software/hardware section, and adobe is very far from anything I run or want to run. :)
<\sh> maswan: well, of course, oracle is the other needed ISV who needs to be switched to Ubuntu ;)
<hwilde> but then ubuntu is going to be bogged down with all their overhead
<hwilde> i'm glad there is no oracle
<maswan> \sh: nah, just get all ibm's stuff and I'll be happy, TSM, DB2, hw support, GPFS, etc. :)
<\sh> maswan: hmmm? ibm hs20 blades are running just fine on Ubuntu ;)
<\sh> well it's old...
<\sh> maswan: but I can assure, that IBM is testing their HW also on ubuntu and debian...at least that is what a friend is doing here in germany
<andrew___> So far as I can tell, vinagre can't do IPv6, but vino requires it in order to do local VNC connections.  If this is a bug, which package should I report it in?
<\sh> andrew___: vinagre
<andrew___> Thanks, will do.
<\sh> but I wonder what's the difference between ipv4 and ipv6 despite the difference between 32 and 64bit addresses.
<andrew___> The difference in what sense?
<cjwatson> err, significant; there are books on the subject
<hwilde> vino does not require v6 for local connex, I do it all the time
<andrew___> hwilde: Strange - can you confirm that `netstat --inet -lpn` includes vino in it?
<\sh> cjwatson: hmm..not in that case..I thought glibc gives you a nice compat mode for connecting to ipv4 or ipv6 addresses
<cjwatson> \sh: to some extent, but it's not entirely trivial
<\sh> cjwatson: oh joy...at least on the application level we shouldn't make the change more difficult ;)
<cjwatson> it can't be made a complete drop-in replacement
<hwilde> andrew___, wow it is using v6 !  I didn't even realize I had it enabled
<hwilde> andrew___, tcp6       0      0 *:5900                  *:*                     LISTEN     5461/vino-server
<hwilde> tcp6       0      0 mpro:5900               mpro:38308              ESTABLISHED5461/vino-server
<andrew___> :)
<andrew___> You might want to look at ip6tables then - it's probably not firewalled.
<hwilde> eh
<hwilde> i'm not scurred
<andrew___> iptables is IPv4 only.  If you've got IPv6 enabled, you need to use ip6tables to firewall your IPv6 connections.
<\sh> cjwatson: I'm damned...not only I have to take care about the routers and kernels but also on the apps....not only damned, I'm somewhat doomed...
<hwilde> or I could just not care
<andrew___> More relevantly though, which VNC client are you on?
<andrew___> Fair enough.
<hwilde> andrew___, I just typed vncviewer
<cjwatson> \sh: it might be a novel idea to read up on it before panicking
<hwilde> novel idea to read up on it    lol nice pun
<andrew___> Ah, okay.  So it's still a bug in vinagre.
<andrew___> Thanks.
<cjwatson> hwilde: unintentional :)
<hwilde> I was going to say, it's a bit early for that :)
<\sh> cjwatson: we are doing some migration tests...so I'm not panicking...but I have to extend our tests
<\sh> regarding some non standard aps
<\sh> apps even
<ScottK> \sh: You have upstream IPv6 connectivity?
<\sh> ScottK: we are playing with ipv6 connectivity...but for production stuff, no
<ScottK> OK.
<ScottK> \sh: Yes.  You'll need to test all the apps in an IPv6 environment.  It's not at all transparent.
<\sh> ScottK: there are some other issues I have to take care about first...e.g. php crc32 implementation ;)
<cjwatson> \sh: IPv6 has been in a chicken-and-egg situation for a long time; it hasn't been worth ISPs' time as long as OS vendors don't support it well (and as long customers aren't asking for it), and it hasn't been worth OS vendors' time to support it as long as ISPs don't
<cjwatson> so I'm all for the deadlock being broken
<cjwatson> but yes, as ScottK says it isn't a trivial migration by any stretch of the imagination
<ScottK> Just teaching an app I'm upstream for to do IPv6 CIDR matches was enough pain for me for a while.
<\sh> cjwatson: I know...when I started to play with ipv6 <-> ipv4 tunnel ISPs...it went bad...but tbh, it's time to get ipv6 out of the kindergarden
<\sh> ScottK: oh well, just explain people ipv4 cidr..it makes them stupid again...people think only in classes :(
<sebner> \sh: well, it's also time to get 64bit out of the kindergarden -.-
<maswan> \sh: yes, but for some things "supported" is rather important. not just "works".
<\sh> sebner: tell MS ... that's why we have to fight with win32 on x86_64 still
<sebner> \sh: it isn't that a big step but there will always be people that are complaining that app xy isn't working. /me ist just happy hat nexuiz is running on amd64 =)
<\sh> maswan: when I read about the last ripe ipv6 meeting and googles attack on it, I wonder when we accomplish the change from 32 to 64...we all know changes are difficult and painful...
<\sh> sebner: regarding developers, 32bit vs. 64bit is a big step..many devs are not knowing the difference between (pointer)(int) and (pointer)(long) on 32 and 64bit archs....even today...
<wgrant> \sh: This is why we have cluebats.
<cjwatson> \sh: BTW, IPv6 addresses are 128-bit, not 32-bit
<\sh> cjwatson: not 64
<cjwatson> err ... "not 64-bit"
<cjwatson> yes
<\sh> yeah.../me has a beer too much in his system ;)
<\sh> no coincidence...but "one bit too many" ;)
 * \sh should go and prepare the asparagus
<\sh> Can't use string ("2/8") as a HASH ref while "strict refs" in use at debian/file-actions.pl line 40, <JL> line 23. oh joy
<maswan> cjwatson: we have been doing ipv6 testing here at ACC, and as of the last 2-3 years or so base OS support has been there, and the last 1-2 years have had "most" application support working too.
<cjwatson> maswan: yeah, it's just been gradual rather than a strongly-coordinated effort
<cjwatson> (with all due respect to people like fabbione who've been pushing for it for a long time)
<cjwatson> and I rather suspect that network-manager doesn't have great IPv6 support ...
<maswan> cjwatson: the thing that worries me is that the 2011 date is getting closer and they aren't pushing it back to "5-10 years from now".
<wgrant> NM works fine with stateless autoconfig, but not sure about other kinds.
<cjwatson> that's the address exhaustion time?
<maswan> cjwatson: yeah
 * wgrant doesn't know of any consumer .au ISPs that provide native v6 :(
<Ng> +projected
<cjwatson> my ISP is still going LA LA LA NO URGENCY
<TheMuso> a/c
<wgrant> cjwatson: They all are.
<\sh> cjwatson: I'm more concerned about the routers (say juniper, cisco to name the big guns)...you could come over some problems with ipv4 tunnels regarding testing/fixing time .. but even our routers are not behaving with ipv6
<maswan> wgrant: last time I checked, static setup was a pain. we haven't tried it on hardy though, the hack in network/interfaces with pre-up and up-hooks to disable autoconf was working
<wgrant> cjwatson: It's ridiculous.
<maswan> Ng: well, yeah. I'm just worried because we're getting close and the projections aren't getting (significantly) pushed back.
<ScottK> Lack of IPv6 just means they can charge more for IPv4 addresses.  I'm not sure why an ISP would invest money to avoid that.
<wgrant> ScottK: That's a good point.
<\sh> ScottK: because ripe e.g. as european ip registry has a policy to not pay for ip addresses...at least when I was member of ripe
<ScottK> So your ISP gives you unlimited static IPs for no extra cost?
<maswan> ScottK: Well, when procurement of connectivity for organisations include "ipv6 connectivity" as a requirement
<\sh> ScottK: setup fee is ok...but not for the ips
<Ng> maswan: there are a bunch of really huge ipv4 allocations that are extremely old and unnecessary, which could be reclaimed
<Ng> I think HP have 3 /8s, two of which are from aquisitions
<ScottK> maswan: As an organizatin, why would I want to raise my contract cost to get that?
<ScottK> Ng: Yes, but even reclamations don't help a huge amount in the long run.
<\sh> ScottK: for my new rootserver I have 8ip network for free...and more then that, I'll have to pay a setup fee ...well, it's a different wording, but fulfills ripes rules
<Ng> ScottK: the almost universal lack of adoption suggests that ipv6 doesn't either
<maswan> Ng: Technically they can be reclaimed, can they legally?
<\sh> Ng: Daimler Benz has one or two /8 too... and they don't need it
<andrew___> My concern is that this could become another Y2K media event - "experts say the Internet will crack asunder on June 2, 2011 at 8:34 GMT, releasing Shub-Internet from its 30 year sleep".
<Ng> \sh: exactly, and there are a bunch of others
<maswan> Ng: It seems more likely to create a market where you can buy/sell adresses..
<cjwatson> ScottK: some organisations seem pretty keen on getting Mobile IPv6 in place; the US DoD seems to be one such
<ScottK> cjwatson: Yes.  US DoD is a major exception and they're big enough to get it done.
<Ng> maswan: how? I can't sell my ADSL's IP to you, it's assigned to my ISP by RIPE
<maswan> Ng: No, you can't currently. But RIPE can't revoke that assignment either, so your ISP has it forever, unless they choose to return it..
<ScottK> cjwatson: US DoD also has a large IP multicast deployment in place.  I don't know of anyone else who's pulled that off yet either.
<\sh> maswan: ripe can revoke
<\sh> maswan: they did it once even for a /16 for my old company
<ScottK> maswan: There is a reclamation process, but it's slow and painful.  We'll probably run out before a significant fraction of the theoretically doable reclamations could be done.
<\sh> maswan: but "names do count"
<maswan> \sh: Ah, so there is a process. Could it work if your company had said "no" and kept announcing them?
<cjwatson> ScottK: they're also driving a certain amount of the hardware and software fixes, which is the only way the chicken-and-egg problem is going to get resolved
<\sh> maswan: as I said, "names do count" ... so if you have a name like "Daimler"..they won't start revoking
<maswan> \sh: or "deutsche telekom" for that matter..
<persia> ScottK: Quite a few of the multinational financial institutions have large IP multicast, often with negotiated multi-network transfer.
<ScottK> cjwatson: Yes.  This is true, but I think getting the hardware/software working is a necessary, but not sufficient condition for getting deployment.
<ScottK> persia: Oh.  I did not know that.  Thanks.
<cjwatson> ScottK: agreed
<maswan> ScottK: The likely outcome of v4 exhaustion I think is a trading model and layer upon layer of NAT. With some growing v6 adoption over time, just because it becomse less painful.
<cjwatson> layer upon layer of NAT> and stuff becoming less and less reliable as a result, but since we've all been trained to go "oh, whatever, restart connection" ...
<andrew___> Is there any data yet on how good Vista's IPv6 is in the real world?
<maswan> andrew___: AFAIK, it "just works" on the client at least.
<maswan> andrew___: much like ubuntu since dapper
<maswan> (or possibly earlier)
<andrew___> That's good, at least.
<\sh> maswan: yepp....but they can claim to be a ISP
<\sh> maswan: I wonder if DTAG or DAIMLER or AS701/AS702 are paying more then just the normal ripe fee
<\sh> (ok AS701 is ARIN)
 * \sh is an old fart regarding AS numbers
<\sh> hmm..AS702 is now verizon...in former times, as701 and as702 were uu.net america, uu.net europe
<TheMuso> /c/c
<andrew___> cjwatson: is this a good time to ask my SSH question?
<\sh> andrew___: why do you not fire away?
<andrew___> Because... I might be wrong :s
<\sh> andrew___: we have hobbsee to tell someone who is wrong or not ,-)
<andrew___> Hehe.
<cjwatson> andrew___: sure
 * Hobbsee loosk in
<andrew___> If I allow an untrusted user to log in to my machine, who can't forward local, remote or X connections, and is given a specific command instead of a shell, what security problems do I need to be thinking about?
<Hobbsee> \sh: who am i telling who's wrong?
 * \sh waves to LPS aeh Hobbsee 
<cjwatson> andrew___: make sure you've set all the no-* listed in sshd(8)
<cjwatson> andrew___: but otherwise that can be made secure providing that you're certain there's no way to cause the command in question to do anything unexpected given arbitrary input
<cjwatson> people have set up anonymous CVS servers that way, for instance
<cjwatson> (who don't trust pserver)
<\sh> who's in charge for running MoM to be up2date?
<andrew___> The plan is that the command do some initial negotiation, then listen on port 5900 (to forward a VNC session back to the client's computer) or /var/run/screen/.../some-unix-socket (to forward a screen back)
<andrew___> Where the unix socket in question is decided by the program, with no input from SSH.
<cjwatson> what happens if that port is already in use?
<andrew___> VNC servers normally use 590*.  I think some use 5901 for X :1, 5902 for X :2, etc.
<andrew___> I suppose I could do that transparently to SSH as well.
<cjwatson> you'd have to return the port number then
<andrew___> I was thinking I'd pipe it all through SSH's standard input/output, and the client would redirect it to the relevant port/socket on the client.
<andrew___> (Which could even be IPv6, going back to the earlier discussion)
<andrew___> I suggest that because I'm not aware of any other mechanism to only allow an SSH client to forward a specified port.
<tmmoyer> is there any documentation on how to build udebs for the installer? I know how to build a traditional package for a running system, but I need to add a package to the installer and haven't seen anything on building udebs
<TheMuso> tmmoyer: You could have a look at how existing udebs are packaged.
<tmmoyer> okay
<evand> tmmoyer: This may also be of help: http://meetings-archive.debian.net/pub/debian-meetings/2006/debconf6/slides/Debian_installer_workshop-Frans_Pop/paper/index.html#id2535340
<ScottK> \sh: I think the plan is to work on it during UDS (MoM).
<tmmoyer> evand: yes I just found that when I expanded my search to include debian as well thank you for the help
<\sh> ScottK: -ETOOLATE ... let's run mom as it was...and try to merge mom with dad on a different server?
<cjwatson> \sh: MoM is running, it's just having trouble getting a consistent archive because the archive is loaded
<andrew___> cjwatson: on the other hand, I see I'm wrong about that :).  How much information do people actually need to share in order to be reasonably confident that they've transmitted the correct RSA key?  Would the cksum/md5sum be any use?
<cjwatson> andrew___: err, sorry, now I'm lacking context. Why would people be transmitting RSA keys?
<\sh> cjwatson: well the last update was on the 7th...and all the syncs and merges were not recognized...if it's because of leningradskaya...ok ;)
<andrew___> cjwatson: If you want to log in with a public key (RSA keys being shorter than DSA keys, therefore quicker to check), and want to confirm over the phone that you've got the correct key.
<cjwatson> andrew___: use the fingerprint; I've had people reading those out over the phone and it's fine
<andrew___> Thanks, that's enough to keep me going for a while :)
<andrew___> I expect I'll be back at some point with a blueprint to annoy people with.
 * \sh is off now.....guests are in da house....african party now ;)
<emgent> re
<andrew___> cjwatson: actually no, I'm not explaining myself right.  If client and server have never connected before, you need a safe way of transmitting the client's public key to the server, and I'm thinking of doing a password-based login, sending the public key, then logging out and back in again with the public key.  I'm worried about a situation where Mallory intercepts the SSH connection from the client, logs in to the serv
<andrew___> er, and sends her own public key, allowing her to do an MITM attack on the later session.
<andrew___> Would confirming the server's RSA fingerprint guard against that?
<cjwatson> the purpose of the host key check is to guard against man-in-the-middle attacks
<cjwatson> so yes, it would; a middle-man attacker would be unable to forge the server's host key
<andrew___> Okay, good.  Thanks again.
<cjwatson> how are you transmitting the passwords around?
<andrew___> Telephone.
<cjwatson> ok
<cjwatson> you have to bootstrap trust somehow :)
<andrew___> Yeah :)
<Dane2> Hello, all.  I've been trying to cross-compile asterisk (compiling i386 binary using amd64 distro) using pbuilder/dh_make/debuild, but I keep getting the following error after the compile completes, and it's about to make a binary package: "build_tools/mkpkgconfig: 34: cannot create /usr/lib/pkgconfig/asterisk.pc: Permission denied"
<Dane2> any ideas?
<Dane2> I've asked on the #asterisk channel, and they said it's a distro specific thing, so I'm trying here.  :-)
<jdavies> Dane2: I think #ubuntu-motu may be a better place :-)
<Dane2> ok.  Thanks.
<emgent> heya people
<johanbr> If I wanted to get a patch into ubuntu to run various cron tasks (locate etc) less often than daily, what would be the recommended way of doing that? Debconf question at low priority?
<cjwatson> johanbr: debconf isn't a very good interface for that sort of choice, really - you'd end up typing crontab entries into it as a string, which would be awful. Why not just edit /etc/crontab? It's a conffile and so your edits will be preserved - that's the supported way to change this.
<cjwatson> also, mixing debconf and conffiles is bad, so in order to offer debconf configuration it would have to stop being a conffile for everyone else, which would introduce a lot of complexity - probably too much for a low-priority tweakable.
<johanbr> cjwatson: I see, thanks. But with editing crontab, changing the interval of only a few daily tasks seems to be complicated.
<johanbr> But on closer inspection, none of the /etc/cron.daily jobs seem to necessarily need to be run daily, at least for me. So I may just do that. Thank you.
<emgent> heya sabdfl
<emgent> :)
<cjwatson> johanbr: yes, if you needed that you'd need to split cron.daily up somehow. run-parts has a --regex option that might help.
<arekm> hello, how do you separate own commits from upstream one in git://kernel.ubuntu.com/ubuntu/ubuntu-gutsy.git repo?
<kirkland> cjwatson: I see that you were the last person to merge/upload yaboot-installer.  i merged for intrepid, in case you want to review and upload.
<cjwatson> kirkland: thanks - can you send me mail to remind me?
<cjwatson> I probably won't get to it tonight, but can certainly review
<kirkland> cjwatson: you bet, will do.  it's no rush.  i'll leave in my home dir on chinstrap.
<andrew___> reportbug-ng is Debian-specific - it doesn't check for bugs filed with Ubuntu.  Is that a bug or a reason to remove the package altogether?  If the latter, who do I talk to about it?
<beuno> andrew___, maybe some ubuntu users want to check for debian bugs?
<geser> or use it to file bugs in Debian
<andrew___> So you reckon I should file a bug saying that it should warn more clearly about not being a useful Ubuntu tool?
<beuno> andrew___, nope, I think it's fine as-is
<ScottK> andrew___: Reportbug has been patched not to report to Debian by default.  Same magic should be done to reportbug-ng if it isn't already.
<beuno> ScottK, really?   what does it do then?
<andrew___> ScottK: Either it's not, or the magic went wrong with the bug I filed :)
<ScottK> By default it sends mail to ubuntu-users or something reasonably useless.  You have to tell it specifically you want to report to Debian.
<ScottK> andrew___: Then it needs to be fixed up like reportbug.
<beuno> hrm  :/
<ScottK> Unfortunately LP doesn't expose sufficient API to actually allow reportbug to be modified to do something useful in Ubuntu.
<andrew___> I'll have a poke about and complain that -ng is insufficiently crippled.
<ScottK> Just make sure you complain to Ubuntu, not Debian '-)
<andrew___> I don't suppose I can report bugs against some test package that blackholes the report?
<andrew___> :p
<andrew___> (So I can do a test and describe the reportbug UI)
<ScottK> You can control what happens to the mail via your local MTA is the best thing I can offer.
<andrew___> Yeah, good plan.
<cjwatson> andrew___: (noted smiley, but) afraid not; bugs against unknown packages in bugs.debian.org typically end up in my inbox so I'd be unhappy about that plan ...
<cjwatson> though there is a debbugs-test pseudopackage, but it's really more for debbugs developers to test, rather than a general-access sandbox
<andrew___> Fair enough, I'll disable anything that looks like it could talk SMTP before I play around with it.
<ScottK> andrew___: It wasn't you that reported a bug against skype in Debian recently is it?
<andrew___> No, Vinagre.
<ScottK> OK.  At least it's a package that's in Debian.
<pochu> andrew___: that's bug 175508. No worries for the Vinagre bug :-)
<ubottu> Launchpad bug 175508 in reportbug-ng "reportbug-ng reports bugs to Debian instead of Ubuntu" [High,Triaged] https://launchpad.net/bugs/175508
<andrew___> Thanks :)
<andrew___> I was halfway through writing a thing with suggested fixes - is that still useful?
<pochu> andrew___: I'll probably look at changing it to ubuntu-users@l.u.c unless you have a better proposal, so yes, that will be useful
<pochu> good night
#ubuntu-devel 2008-05-13
<haisam> hi guys
<andrew___> Hi.
<haisam> I have a small technical problem is that the right place to ask ?
<andrew___> Depends how small and how technical - #ubuntu might be better.
<haisam> it's small :)
<andrew___> Well ask away, and we'll continue in private if necessary :)
<haisam> I can't play rhythmbox and Totem simultaneously
<haisam> that mutes my sound
<haisam> same with firefox and totem
<haisam> in brief can't use sound for one application
<haisam> more than one application *
<andrew___> But when you stop trying to use the second application, sound comes back?
<haisam> yeah
<haisam> when I close the other application
<andrew___> Is this in Hardy?
<haisam> yeah
<haisam> 8.04 LTS
<andrew___> At a guess, that's probably got something to do with the new audio system (PulseAudio), but that's way outside anything I can help with.
<haisam> mmm
<haisam> I guessed so
<andrew___> #ubuntu might know more.
<haisam> but when I disabled it it didn't help
<haisam> anyway thx
<andrew___> Sure, sorry I couldn't be more help.
<haisam> thx
<Bodsda> sorry for coming here for a support type question but         dpkg-reconfigure xserver-xorg         used to be able to configure video displays and devices, it no longer does that,.,. is there a new command for this or how can i reconfigure my display drivers when i cannot use a gui session?
<RAOF> You should be _always_ able to use a GUI session.
<Bodsda> RAOF, what about when my display drivers are 'missing' and i dont know the package name to set them nor can i connect to the internet to download anything -- is there another command for reconfiguring display?
<RAOF> If you can't, it means that the vesa driver is broken on your system.
<Bodsda> RAOF, so what would i do then -- besides reinstall?
<RAOF> I'm not quite sure what your question is.  Or, rather, I'm not sure that the conditions in your question ever trigger.
<Bodsda> ok il rephrase
<Bodsda> RAOF, in Gutsy when i ran         dpkg-reconfigure -phigh xserver-xorg        i could reconfigure my display settings things like drivers and screen res, in Hardy this is not available with the same command,. is there another command that does the same thing or how can i make the command do what it did in Gutsy?
<RAOF> Right.  The answers there are 'no' and 'no', respectively.
<Bodsda> RAOF, why was the command changed?
<RAOF> Because X no longer needs that configuration.  Most of the time.
<RAOF> And writing _wrong_ information in xorg.conf is bad :)
<RAOF> The only time you should need to specify a driver is in the restricted-drivers case, since these don't seem to hook into X's autodetect.
<Bodsda> RAOF, and what should i do if i need to reconfigure my display settings and i dont know what conf files to look in nor do i have a useable gui session (because there is loads of lines accross my screen & my screen is overlapping itself 5 times)
<RAOF> Bodsda: You can delete /etc/X11/xorg.conf :)
<RAOF> Bodsda: Or, better, move it out of the way.
<Bodsda> RAOF, how does that help?
<ScottK> Another option is to reboot and pick the recover option.  It's got a try to fix X option.
<RAOF> So, that makes X do it's funky autodetection thang, which should work.  If it doesn't, it's going to be a driver bug.
<RAOF> ScottK: Which uses VESA, right?
<Bodsda> ok so the nifty little tool to fix screen probs has been deleted -- why? and is it at all possible to get it back?
<ScottK> RAOF: I'm not sure.  So far everytime I broke my xorg (and I did it a bunch patching displayconfig) it got me back to working.
<RAOF> Why? A: Because it no longer fixes screen problems.  Not possible to get it back, at least easily.
<RAOF> You'd have to look at the pre-Xorg-1.4 packages and merge the old debconf information with the new packages.
<Bodsda> why would it no longer fix screen probs ?? it choose drivers and screen res
<RAOF> Both of which can be accurately autodetected.
<ScottK> Bodsda: X changed the way it deals with stuff a lot recently.  A lot of tools just don't work anymore.
<Bodsda> ScottK, can we expect a similar tool in the future?
<RAOF> Probably not, since the goal is to make such a tool unnecessary.
<ScottK> Bodsda: I'm not sure what tool you're talking about.  If you want to fix a broken X config do the reboot to the recover option and pick the fix X choice.
<Bodsda> ok, thankyou both -- ScottK doesnt the recover mode just give u a prompt?
<ScottK> Bodsda: No.  It gives you choices and you can fix X and then reboot normally.
<Bodsda> ScottK, ok cheers -- il let the guys in #ubuntu know --  cheers
<fabbione> hmmm perl still broken?
<dholbach> good morning
<pitti> Good morning
<dholbach> hi pitti
 * pitti hugs dholbach
<ion_> Hi
<fabbione> hi pitti
<pitti> Padre!
<pitti> fabbione: Rocking the penguin cluster? :-)
<fabbione> pitti: indeed :) getting ready for a new release today
<StevenK> TheMuso: Hardy kernel?
<TheMuso> StevenK: Only just upgraded this box to hardy.
<StevenK> TheMuso: Ahh
<geser> good morning
<pitti> fabbione: oh, FC9 o'clock?
<fabbione> pitti: there was an announce, but no.. it's not related to f9
<fabbione> pitti: i am preparing 2.99.01 (that will eventually be 3.0) for f10
<fabbione> but you might have noticed that the build-deps for 2.99.01 are already in intrepid :=)))
<mathiaz> seb128: hello :)
<seb128> lut mathiaz
<mathiaz> seb128: re bug 228061 - I guess this is a duplicate of a nautilus bug - which bug number should I use ?
<ubottu> Launchpad bug 228061 in samba "Samba doesn't display the shared stuffs" [Undecided,Incomplete] https://launchpad.net/bugs/228061
<mathiaz> seb128: or should I just reassign it to the nautilus package ?
<seb128> mathiaz: bug #207072
<ubottu> Launchpad bug 207072 in nautilus "nautilus does not display samba shares for machines inside an ADS network." [Undecided,Invalid] https://launchpad.net/bugs/207072
<mathiaz> seb128: great - thanks
<seb128> you are welcome
<pitti> hey seb128
<seb128> hello pitti
<mrec> hi, how can I get a package included in Ubuntu?
<mrec> tvtime with audio support might be a good candidate, as well as my em28xx drivers (compiled for 32/64bit ontop of the lum modules, including firmware)
<Chipzz> I think #ubuntu-motu may be a good start
<mathiaz> mrec: ^^ + https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<Chipzz> though I'm not sure about the dirver
<Chipzz> *driver
<Chipzz> driver possibly should go into -restricted-drivers
<mrec> I think it's better to keep the drivers out of the linux-ubuntu-modules package since I'll update it more frequently
<Chipzz> which wouldn't be a seperate package per se
<mrec> it's completly opensource and supported by the manufacturer
<Chipzz> well even then; I'm not sure what the policy is on shipping drivers in seperate packages as opposed to in the big package
<mathiaz> mrec: if you wanna take the path to maintain out of tree kernel modules, have a look at the virtualbox-ose-* packages
<mathiaz> mrec: I'd suggest you to get your driver included in lum - it will be much easier to maintain and things won't break whenever there is a new kernel published.
<mrec> mathiaz: the only thing is that there will be weekly updates again
<mrec> I'm working at the driver and application side to provide best possible support for those devices (while not affecting/(breaking) other things)
<mathiaz> mrec: make sure you push them in the lum git tree
<Chipzz> mrec: I'm thinking, updating your driver frequently may not be a good idea anyway; well, at least not for stable releases
<Chipzz> and for the development cycle, new kernels get pushed often enough
<Chipzz> though maybe not as much as you want
<mathiaz> mrec: the problem is that if you maintain your driver out of the tree, whenever there is a new kernel published things will break
<mrec> mathiaz: I thought about that too the package could have a direct dependency to the lum package version, so upgrading the lum package would remove the driver
<Chipzz> at least not for stable releases >> it simply will not happen for stable releases
<mrec> I already have a Ubuntu build system for it
<mathiaz> mrec: for ex, if you install virtualbox-ose-modules-*, which are in universe, you have to wait for the virtualbox-ose-* maintainer to uploader a new version of the vbox-ose-modules- when a new kernel is published.
<mrec> I'm aware of something like that yes
<mathiaz> mrec: so it's easier to get your module in the lum tree.
<mathiaz> mrec: your module will be part of the standard kernel upload.
<Chipzz> mrec: uhm, first of all, you would need to manually track the lum version. and second, how is it any good for the user (who may depend on your driver) that it gets removed when stuff breaks?
<mrec> mathiaz: ok, well sounds like a reasonable way to go
<mrec> Chipzz: the module overall has no dependency on something else it just adds stuff
<mathiaz> mrec: if you still wanna maintained your own kernel-modules packages, you should have a look at the virtualbox-ose package.
<mrec> I think the way you propose is fine
<mrec> I could still provide packages on the webserver for those who want to test the bloody edge work
<Chipzz> mrec: btw, one more thing... doing weekly updates will make bugtracking hell I think
<mrec> Chipzz: it doesn't, it usually adds support for newer devices and newer chipdrivers
<geser> pitti: Hi, is it ok to ask for give-backs to get to build order right or is some huge give-back planned?
<pitti> geser: sure, just tell me; I guess infinity will do some more mass-givebacks, but it doesn't hurt to do some more coordinated ones manually
<pitti> hi sjoerd
<geser> pitti: do we need the cpio-win32 binary deb? it makes currently cpio depwait on mingw32 (universe)
<sjoerd> pitti: morning :)
<Riddell> pitti: KDE 4 MIRs available when you're able
<pitti> geser: erk, does that come from cpio proper? no, we certainly don't want that in main
<pitti> Riddell: ok, thanks
<geser> pitti: cpio builds cpio and cpio-win32. according to the description cpio-win32 is used in the win32-loader of D-I
<soren> ogra: I have a few questions about ltsp server, if you have a minute?
<ogra> sure
<soren> ogra: I see that the standalone package depends on dhcp3-server.
<ogra> right
<soren> I'm curious about how you handle configuration file changes in there.
<ogra> see dhcpd's initscript ;)
<soren> I suppose ltsp fiddles around with it to offer kernel images to clients.
<soren> Oh, ok.
<soren> Oh.
<soren> Hah.
<ogra> we have an override file so we dont touch existing configs
<soren> So installing ltsp effectively disables any currently running dhcp server?
<ogra> if an admin wants to use his existing file he just a) deletes ours or b) only installs ltsp-server
<soren> Is the user notified about this when installing ltsp-server-standalone?
<ogra> -standalone assumes you want ltsp to handle everything
<ogra> ltsp-server is freely adjustable in all directions
<ogra> well, only by the package description, we dont notify separately
<ogra> soren, if you have any better sugestion how to handle the situation, i'm all open for a beer in prague to discuss it over ;)
<soren> ogra: :)
<soren> ogra: I'm really just working on something that'll need to do almost the same thing, so I was just looking for inspiration as to how to handle this.
<soren> ogra: ...but let's have beer anyway :)
<ogra> soren, we do a similar thing with syslog, if you need such overrides as well, we should consider generalizing on a /etc/overrides dir or so
<ogra> currently its bound to /etc/ltsp and the files in there
<soren> ogra: Yup.
<soren> pitti: re: https://bugs.edge.launchpad.net/ubuntu/+source/ifenslave-2.6/+bug/223759.. Can't we just copy over ifenslave-2.6 from hardy-updates to intrepid?
<ubottu> Launchpad bug 223759 in ifenslave-2.6 "ifupdown integration broken" [Medium,In progress]
<pitti> soren: no
<pitti> soren: we need a different version, since we have a different toolchain
<soren> Er.. Yeah, but if this bug had been fixed before hardy released, the packages would have just been copied to intrepid anyway. We don't rebuild every package because we update the tool chain?
<pitti> soren: right, but we still usually do it
<pitti> can't hurt to test it properly in intrepid
<soren> *shrug* Ok.
 * pitti finishes testing of virt-manager and copies to -updates
<pitti> ^ same case, btw, should be uploaded to intrepid
<soren> pitti: Not entirely the same case. intrepid will have a new upstream version, too. But yeah, it's in my list :)
<geser> has someone some time to sponsor bug #229877?
<ubottu> Launchpad bug 229877 in cpio "[intrepid] cpio build-depends on mingw32" [Undecided,New] https://launchpad.net/bugs/229877
<ogra> Keybuk, why is ltsp showing up on MOM but ldm isnt ? debian added an epoch to the ldm versioning, could that cause MOM to ignore it ?
<dholbach> ogra: it's on http://merges.ubuntu.com/main-manual.html
<ogra> oh, i only looked at main.html, thanks dholbach
<Keybuk> ogra: no common base version between the two
<ogra> well, just different versioning, the code i pretty much the same .... (in the new ltsp wold each distro decides on its own how to call the tarballs :/ )
<ogra> s/i/is
<ogra> tkamppeter, a big "thank you" from my mother ! (i brought her a new printer this weekend and she was massively impressed that she could intsall it herself (well or that it installed itself on its own rather :) ))
<jordi> does anyone here use vnc4server loaded in xorg.conf and get X crashes as soon as a client connects?
<jordi> in hardy
<geser> pitti: a first batch for give-back: antlr axis hsqldb jakarta-log4j javacc jcommon-serializer jsch libbsf-java libcommons-collections3-java libcommons-lang-java libformula liblayout libloader libjaxp1.3-java libjakarta-poi-java librepository libpgjava liboro-java libmx4j-java libxerces2-java libxml-commons-resolver1.1-java libxml-java mysql-connector-java sacjava libxalan2-java
<ogra> pitti, you have to use "sudo hal-disable-polling --enable-polling --device /dev/scd0" if something diabled cdrom polling (i.e. powertop has such an option) couldnt we make that command a wee bit more intuitive in its naming ?
<ogra> :)
<pitti> geser: hm, wierd, I get 403 forbidden on those now; yay LP rollout
<pitti> ah, seems my stored cookie was invalidated
<pitti> darn, how do I get one back now, with Firefox 3?
<pitti> ogra: anything you have to type on the CLI is unintuitive...
<pitti> ogra: the UI you used to switch it off should also allow you to switch it back on
<ogra> pitti, true, but calling a command disable-foo with such a switch seems weird
<geser> pitti: http://people.ubuntu.com/~kees/scripts/cookies-sql2txt
<pitti> geser: \o/
<pitti> hm, still forbidden
<pitti> geser: no luck; I cannot even do it in the web ui
<pitti> I'm still in lp-buildd-admins, but I don't even see the 'retry build' option any more :/
<pitti> cprov: ^ any idea?
<emgent> heya
<tkamppeter> ogra, great to hear this positive feedback. Which printer model did you give to her?
<ogra> a HP photosmart 53xx (forgot the exact namimg, sorry)
<tkamppeter> ogra, this one is really completely supported. Connected to USB it sets up by iteslf and you can print and scan (if it has a scanner) immediately. If you were running Windows it would take you hours to get HP's CDs installed and you would need to reboot.
<ogra> yeah, indeed i slightly ceated by buying a HP since i know its well supported :) but it was very impressing :)
<wgrant> I had the painful experience of installing an HP PSC .* on a Windows box last week. Could they really make it any worse/
<cprov> pitti: what's the problem ?  you use to be allowed to retry any builds and now you are not ?
<pitti> cprov: right
<cprov> pitti: even l.n not in edge.l.n ?
<pitti> cprov: let me try
<pitti> cprov: ah, lp.net still works
<pitti> geser: ok, disabled redirection and gave back your packages
<geser> pitti: thanks
<pitti> soren: FYI, (LP #223759) does not work; you have to use LP: #; so please close the ifenslave bug manually
<ubottu> Launchpad bug 223759 in ifenslave-2.6 "ifupdown integration broken" [Medium,In progress] https://launchpad.net/bugs/223759
<soren> pitti: Ah, yes. Force of habit. I remove the colon on purpose when doing merges (to not try to close the bugs /again/), but this time that was clearly wrong. Thanks for catching that.
<pitti> soren: btw, IIRC LP does not try to close the bugs again, that was fixed
<soren> pitti: Ah, lovely.
<ogra> LP will make us all jobless some day
<pitti> soren: (I do the same, though)
<ogra> *g*
<jordi> cjwatson: omg
<cjwatson> jordi: ?
<jordi> cjwatson: remember my partman-auto-raid troubles?
<cjwatson> sort of :)
<jordi> I was composing a detailed email to you and Simon
<jordi> I thought it was very suspicious that the only error message I got was "No root partition defined", invariably of what I tried, and no debug messages
<jordi> well, partman-auto-raid is in universe in Ubuntu
<cjwatson> aha
<cjwatson> yes, stuff in universe won't get used ...
<jordi> yeah, it's not even in the CD
<jordi> now, I've tried so many things that I don't know what's the correct config :)
<jordi> cjwatson: *sigh*, the basic expert_recipe works
<jordi> I'll try the more elaborate setup now. I can't understand why -raid isn't in main though
<cjwatson> never got reviewed and promoted ...
<jordi> cjwatson: what can I do to get this reviewed and promoted?
<cjwatson> jordi: could you mail ubuntu-devel@ about it?
<jordi> sure thing
<jordi> from your partman-auto knowledge, do you think creating a "/ on raid1, two independent swaps and /srv/backup on ext3 on a single PATA disk" would be problematic?
<jordi> +layout
<fabbione> SCORE!!!!! WOWOWOWOOWOW
<fabbione> Subject: [SECURITY] [DSA 1571-1] New openssl packages fix predictable random number generator
<Tm_T> :)
<cjwatson> aware, work in progress
<fabbione> cjwatson: yeah i know...
<stgraber> fabbione: scary title isn't it ? :)
<virtuald> <random theobsd rant />
<ScottK> Recovery looks to be a bit painful.
<lool> So we will have to regenerate all our SSH keys?
<fabbione> not all of them no
<lool> Only DSAs?
<siretart> what ubuntu releases of openssl are affected?
<lool> siretart: >= 0.9.8c-1 I think
<fabbione> siretart: wait for the USN
<siretart> lool: which would mean all later and including dapper :/
<lool> This would translate to anything post dapper if I understand correctly
<siretart> err, s/dapper/feisty/
<ogra> siretart, hey, i dont see you on the UDS attendees list, you dont come this time ?
<siretart> ogra: oh, I do!
<siretart> ogra: is that on launchpad?
<ogra> yeah
<ogra> great to hear :)
<siretart> ogra: thanks for notice, fixed :)
<\sh> pitti: I filed a new sync request for phpgroupware, where your sync script was not able to sync it last time...could you check if it does now succeed? (bug #229942)
<ubottu> Launchpad bug 229942 in phpgroupware "Please sync phpgroupware 1:0.9.16.012+dfsg-4 (universe) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/229942
<pitti> \sh: yes, I'll have a look next time
<tjaalton> ok, so the openssl bug is quite severe.. does it really mean that every key used on a buggy system should be changed? even if not generated there?
<ogra> check the keys with the tool :)
<ogra> (ssh-vulnkey that is)
<jdong> tjaalton: quite severe is an understatement.
<tjaalton> :/
<jdong> tjaalton: all we need now is for GPG to be compromised and the galaxy will implode.
<thom> um.
<thom> openssh-server template parse error: Template #4 in /tmp/openssh-server.template.326872 has a duplicate field "template" with new value "ssh/vulnerable_host_keys". Probably two templates are not properly separated by a lone newline.
<thom> (gutsy)
<tjaalton> jdong: actually I was asked about the possibility
<Hobbsee> ogra: ssh-vulnkey?
<ogra> Hobbsee, yes
<kees> Hobbsee: see http://www.ubuntu.com/usn/usn-612-2 for details
<cjwatson> thom: gutsy> argh
<cjwatson> jdstrand: ^--
<jdstrand> meh
<ogra> kees, hmm, it would be clever if the first page of the USN somehow indicated there is a second one i guess
<tjaalton> ogra: I know the hostkeys are fine, since they are generated on a rhel cluster during installation, but the debian report said that all keys used during authentication are compromised..
<pitti> TheMuso, imbrandon, jdong: any chance somebody could approve my fakechroot SRU? (bug 228534)
<ubottu> Launchpad bug 228534 in fakechroot "Does not wrap *at() functions which makes fakechroot fail badly with Hardy" [High,In progress] https://launchpad.net/bugs/228534
<ogra> kees, if you dont guess that by url ...
<cjwatson> tjaalton: all *DSA* keys
<cjwatson> tjaalton: RSA keys are only broken if generated on a buggy system
<kees> ogra: it isn't explicit, you're right, but the 612-1 url is in the top header
<tjaalton> cjwatson: argh
<kees> cjwatson: the non-default DSA breakage requires traffic capture and additional computational expense to crack, though?
<jdong> pitti: sorry, lemme take a look; been scrambling the morning with the SSL fun
<cjwatson> kees: correct, though perhaps not actually all that much additional computational expense (maybe)
<pitti> jdong: it's not utterly urgent, but it's sitting there for a week or so
<cjwatson> the DSA one is not fully analysed yet, we just know that there is a weakness there
<Hobbsee> ogra: which package is it in?
<jdong> pitti: you've got it :)
<pitti> jdong: wow, that was fast. thanks :)
<Hobbsee> ahhh, more upgrades here now.
<ogra> Hobbsee, openssh-server
<Hobbsee> which probably means i have to regenerate again.  sigh.
<Hobbsee> wait, no.
<jdong> Hobbsee: the upgrade is apparently just Ubuntu sauce...
<jdong> Hobbsee: i.e. regen vulnerable hostkeys on postinst, reject authenication from users with weak keys
<cjwatson> thom: feisty and hardy are fine, for the record
<cjwatson> jdong: Debian too
<jdong> cjwatson: oh. what's the scope then?
<cjwatson> jdong: err, sorry, not sure exactly what you're asking?
<cjwatson> scope of what?
<jdong> cjwatson: USN 612
<jdong> cjwatson: I thought feisty and hardy are affected?
<cjwatson> oh, you misunderstood me
<jdong> cjwatson: sorry, seems like I did :)
<thom> jdong: cjwatson was responding to my comment that the gutsy packages are bust
<cjwatson> thom was pointing out a problem with the upgrades in gutsy-security
<jdong> OH
<jdong> ok
<cjwatson> I noted that feisty-security and hardy-security don't have that upgrade problem
<jdong> cjwatson: thansk for the clarification.
<no0tic> I confirm what thom said
<cjwatson> yep, we're working on it with all possible speed
<tjaalton> cjwatson: so all DSA keys used (!) on a buggy system should be changed, not just those that were generated there?
<cjwatson> tjaalton: it's a somewhat arguable case as yet; for complete safety, yes
<cjwatson> compromising a DSA key used on a buggy system requires capturing a network trace, and it's not clear yet whether user keys are susceptible except by a malicious sshd
<cjwatson> me? I've regenerated my DSA key
<jdong> erring on the side of caution seems prudent when dealing with these matters :)
<tjaalton> ok, maybe it's time to write an announcement for 20000 students :P
<jdong> haha
<maswan> ugh. I'm happy that almost all our servers are still on dapper. :)
<jsgotangco> heh
<maswan> also, kerberos meaning no ssh key auth. :)
<jdong> maswan: yeah kerberos is saving my life right now
<jdong> my campus server keys don't need any additional work atm
<jdong> but on my personal system I need to regenerate some IMAPS/HTTPS certs later today :)
<tjaalton> we are still fighting whether to use MIT or AD or both
<maswan> tjaalton: heimdal! :)
<tjaalton> maswan: that too :)
<tjaalton> maswan: we actually have MIT already set up, but it's "unofficial"
<jdong> use MIT </unbiased joking opinion> ;-)
<tjaalton> and no trust between MIT <-> AD
<jcastro> http://www.pastebin.ca/1016979
<jcastro> anyone seeing that with the ssh update?
<Ng> jcastro: gutsy?
<jcastro> yeah
<Ng> a new version is being prepared for gutsy
<jcastro> (not my machine, just got asked by someone who did this)
<jcastro> ok
<jcastro> thanks
<Mithrandir> ssh update?  You mean openssl or do you actually mean ssh?
<cjwatson> Mithrandir: ssh
<cjwatson> jcastro: known, in progress
<Mithrandir> maswan: heimdal seems to be linked with openssl here.  Are you sure it's safe?
<maswan> Mithrandir: no, it's likely broken just like mit kerberos. our kdcs etc are on dapper. :)
<Mithrandir> ah, ok
<Volans> Hi all, I have a problem with the update of openssh-server on Gutsy 64bit. I know that you are working on it, if I can help with some test feel free to ask me (output of apt-get -f install: http://pastebin.ubuntu.com/11878/)
<cjwatson> Volans: known, we're on it
<jcastro> Volans: I just asked the same question, it's being worked on
<cjwatson> (you're number four ...)
<emgent> hehehe :D
<cjwatson> the fix is in the works
<Volans> ok, better! :) just in case we can help you with some test
<l3on> Hi all :)
<kirkland> cjwatson: the ideal output of a "fixed" system when running "sudo ssh-vulnkey -a" is an exit code of 0?
<cjwatson> no, the opposite
<cjwatson> the exit code semantics are a bit tricky I'm afraid
<cjwatson> but ssh-vulnkey exits 0 if it finds at least one vulnerable key
<kirkland> cjwatson: interesting, okay.  output of "Not blacklisted" is optimal?
<cjwatson> yes
<cjwatson> "Unknown (no blacklist information)" means it's a key type/length for which we don't have a blacklist
<cjwatson> "COMPROMISED" means regenerate the bugger now
<sdh> anybody help me out with this related error please?
<sdh> https://www.uptime.org.uk/tmp/apt.txt
<kirkland> cjwatson: yup
<kirkland> cjwatson: thanks.
<sdh> looks like a package problem
<cjwatson> sdh: we're on it
<Volans> sdh: have you gutsy?
<sdh> cjwatson: ah, it's known about?
<sdh> Volans: yep, server
<cjwatson> yes, this is gutsy only
<thom> cjwatson: worth topic'ing?
<sdh> i just update/upgraded to fix the ssl nightmare :)
<sdh> s/fix/help start to fix/ :)
<Volans> they are working on it, only Gutsy have this update problem on openssh-server due to the USN-612-1 fix
<sdh> ok, cool, thanks
<cjwatson> it's a single sodding blank line *sigh*
<sdh> i'll hold off and keep an eye on here... then update/upgrade later
<cjwatson> gutsy-security is fixed
<Volans> thanks cjwatson :)
<cjwatson> thom,no0tic,jcastro,Volans,sdh: ^--
<jcastro> cjwatson: thanks, I'll let people know
<sdh> thanks
<no0tic> thanks
<stgraber> thanks
<Volans> cjwatson: just updated all worked fine
<thom> ta
<cjwatson> great
<Pici> thanks, /me informs #ubuntu
<stgraber> openssh upgraded correctly
<stgraber> but not openvpn
<stgraber> openvpn: Depends: openssl-blacklist which is a virtual package.
<[reed]> kees, jdstrand, cjwatson: ping... looks like the openssl/openssh packages are wrong
<geser> pitti: please give-back: libapache-htpasswd-perl libcrypt-hcesha-perl libcrypt-openssl-dsa-perl libhtml-fromtext-perl libgnome-java
<[reed]> so, this was the "fix" Debian made in 2006
<[reed]> http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c
<[reed]> and this was the back out 5 days ago:
<[reed]> http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&view=diff&r1=300&r2=299&p1=openssl/trunk/crypto/rand/md_rand.c&p2=/openssl/trunk/crypto/rand/md_rand.c
<[reed]> I see a problem!
<cjwatson> [reed]: nah
<[reed]> why not? PURIFY isn't used for compiling
<cjwatson> [reed]: the first change to rand/md_rand.c was wrong - that was in 0.9.8b-1
<[reed]> that code is still compiled
<[reed]> cjwatson: that code is still there
<cjwatson> [reed]: the PURIFY bit does not matter
<cjwatson> ok, sorry, I thought you were asking about the filename difference, but in any case
<cjwatson> [reed]: no, it's fine - one of those two diffs was acceptable, one was incorrect
<cody-somerville> Would this vulnerability affect a red hat server if I used Ubuntu to generate the key?
<cjwatson> cody-somerville: yes
<pitti> geser: done
<[reed]> cjwatson: why wasn't the entire change backed out?
<cjwatson> because it didn't need to be
<[reed]> looking at ssleay_rand_bytes() in Debian's svn repo, that other change is still there
<[reed]> #ifndef PURIFY
<[reed]> #if 0 /* Don't add uninitialised data. */
<[reed]> 		MD_Update(&m,buf,j); /* purify complains */
<[reed]> #endif
<[reed]> #endif
<jcastro> 3333333333333333333333333333333333333333333333333333333333333[A
<jcastro> oops, sorry
<jdong> jcastro: you sure held that right arrow key for a convincing period of time ;-)
<cjwatson> [reed]: yes. we know. but that's ok.
<[reed]> cjwatson: well, it doesn't make me feel very safe
<cjwatson> [reed]: "buf" is something completely different there than in the other chunk.
<[reed]> yeah
<jcastro> jdong: the new package apparently doesn't fix ssh lag. :)
<[reed]> well
<[reed]> it's still a wrong change that Debian should have never made
<cjwatson> [reed]: in the other chunk, buf is actual real initialised data
<cjwatson> I don't dispute that
<[reed]> so it doesn't make sense why somebody doesn't back it out now and submit new packages just to appease everybody that there isn't still some remnants left
<[reed]> because when an openssl team member is pointing it out on his blog, I worry
<cjwatson> [reed]: because there was actually a reason for the other bit - it made it more difficult to use automated tools to assure the correctness of other software that used openssl
<cjwatson> I have read the blog entry in question, yes
<[reed]> cjwatson: sure, that's what the PURIFY define is for
<[reed]> you can define it if you want
<cjwatson> let me explain
<[reed]> instead of commenting out the code
<cjwatson> (or you could go and read the original bug log!)
<cjwatson> but if you don't want to read the original log, the reason why -DPURIFY wasn't used was that that would have to be applied to the non-debug build as well, otherwise the utility of the -dbg build just being separated symbols so that you can use it to investigate core dumps produced by the regular build would be lost
<cjwatson> now, I'm not sure why PURIFY wasn't used across the board, because I haven't looked at what else it does to openssl
<cjwatson> but if you have questions there you should address them to the Debian maintainer
<cjwatson> divergence between Debian and Ubuntu here is unlikely to be helpful, and we've taken quite a lot of care to coordinate here
<[reed]> I read http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516, which doesn't mention PURIFY
<[reed]> which bug # is this you're speaking of?
<ubottu> Debian bug 363516 in openssl "valgrind-clean the RNG" [Wishlist,Closed]
<cjwatson> that's the one
<cjwatson> it discusses it, even if not by name
<cjwatson> as it happens, it looks like the only thing PURIFY does now is to compile out that code which is commented out
<cjwatson> so what we have now is equivalent to (and uglier than) building with -DPURIFY
<[reed]> ok, so, why did this take 5 days (at least) to go public?
<cjwatson> because we needed to take care to get mitigation measures in place
<[reed]> such as what?
<[reed]> the script?
<cjwatson> I do not wish to give people information on how to write an exploit just at the moment, I'm afraid
<[reed]> dowkd.pl
<cjwatson> dowkd.pl was written by a member of the Debian security team; I wrote ssh-vulnkey
<[reed]> cjwatson: well, I think you should at least mention somewhere publicly why Debian/Ubuntu/etc. didn't back out the entire bad change
<cjwatson> but the aim of both was the same; help people to lock down use of compromised ssh keys as soon as possible
<cjwatson> I think you should address your concern to the Debian developer who made the change
<cjwatson> (as I said above0
<cjwatson> )
<[reed]> ok
<cjwatson> we have put a good deal of time into assisting with the job of mitigating this, but ultimately it is more valuable to Ubuntu not to diverge from Debian on critical issues such as this so that at least we share problems
<cjwatson> we certainly aren't going to make the essentially cosmetic change of switching to using -DPURIFY
<[reed]> do you recommend regenerating all keys made since the bad change was live, or just ones that are vulnerable?
<cjwatson> now, personally, I think that would be the correct change to make
<cjwatson> but it should be made in Debian
<Chipzz> how does this affect ubuntu? http://www.debian.org/security/2008/dsa-1571
<cjwatson> http://www.ubuntu.com/usn/usn-612-2 has detailed instructions
<Chipzz> (OpenSSL vulnerability)
<cjwatson> Chipzz: please see the corresponding Ubuntu security updates
<jdong> Chipzz: USN 612-2
<Chipzz> maybe best to put a warning in the topic?
<cjwatson> [reed]: five days ago, we also didn't know the scope of the problem (e.g. whether it affected session keys), and needed time to investigate before the storm broke
<cjwatson> five days is not an especially long embargo period for this sort of thing; in fact it was shorter than would have really been convenient to get everything ready
<[reed]> I agree
<[reed]> and my other question and regenerating keys?
* cjwatson changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | 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
<sdh> hmm, i guess this affects https keys too?
<[reed]> s/and/about/
<sdh> as generated using openssl for apache
<cjwatson> sdh: yes
<sdh> that's unfortunate, given that people pay to get them signed
<cjwatson> [reed]: for 2048-bit RSA keys or 1024-bit DSA keys, we have blacklists of compromised keys, and you can refer to those
<cjwatson> [reed]: for other keys, I would advise regenerating unless you are confident that they were generated on non-vulnerable systems
<cjwatson> sdh: yes
<[reed]> k
<[reed]> thanks
<winjer> we've regenerated our server keys using the new ssl, and they're being reported as weak by the tool
<winjer> any idea what's going on there?
<cjwatson> winjer: which keys, which tool?
<winjer> dowkd.pl, server host keys
<cjwatson> I did not write dowkd.pl and can't support it; try ssh-vulnkey?
<cjwatson> what does it say?
<winjer> "weak key"
<winjer> i'll keep digging
<cjwatson> ssh-vulnkey doesn't say "weak key" :-)
<winjer> oh sorry
<stgraber> cjwatson: is the openvpn security update supposed to work with gutsy ?
<cjwatson> stgraber: I believe so, though I haven't looked at it ... what's wrong?
<stgraber> The following packages have unmet dependencies: openvpn: Depends: openssl-blacklist which is a virtual package.
<cjwatson> openssl-blacklist may be in NEW or something
<cjwatson> I'll check it out
<cjwatson> yes, it is
<sdh> good time to be a CA :)
<norsetto> can someone please give back wsjt?
<psusi> I do not understand the purpose of the watershed wrapper used by udev... could anyone explain?
<cjwatson> https://wiki.ubuntu.com/UdevLvm was where it was introduced
<psusi> I just read that ;)
<psusi> not getting it for some reason
<psusi> it says if 100 events come in, it will run the command at least twice, but probably not 100 times...
<Mithrandir> psusi: in some cases, you have a process which takes a long while to finish and it holds a lock, but it's stateless and you just need it to run after a certain event.
<psusi> if there are 100 events, then shouldn't the command be run 100 times?
<psusi> OHH
<cjwatson> no, because one run of the program is sufficient to clear all pending events
<Mithrandir> not necessarily.
<cjwatson> but what happens if an event arrives after the program started?
<psusi> right... since you are telling it to scan ALL devices, if 12 devices come in, you don't need 12 scans
<cjwatson> that's what watershed is for
<psusi> just 1 scan after the last device
<Mithrandir> psusi: correct.
<psusi> why isn't lvm told only to scan the device which has arrived though?
<cjwatson> in lvm's case, it may take several block devices to build up a full volume
<cjwatson> basically it's a race fix IIRC
<psusi> yea... but if you vol_id them as they come in, and you identify which volume they are a part of, then you can tell lvm exactly which devices have been identified as part of that volume so it can scan them and activate that volume
<psusi> without disturbing any unrelated devices
<sdh> cjwatson: is there a ssh-vulnkey equivalent for generic SSL keys ?
<sdh> not sure im making sense
<cjwatson> sdh: it's not possible for all keys
<sdh> the sort of key that openssl spits out for use in apache
<Mithrandir> psusi: theoretically, there's nothing wrong with that approach, apart from the fact that lvm doesn't work that way, I believe.
<cjwatson> sdh: but I believe one is either done or in progress for some simple cases, in one of the other security updates
<sdh> cjwatson: thanks
<psusi> is the output of the scripts run by udev logged anywhere?  I'm trying to figure out why this server won't activate the root raid at boot
<Keybuk> psusi: not normally
<psusi> Keybuk: is there a switch or boot parameter you can throw to make it?
<Keybuk> psusi: no
<psusi> ;(
<Keybuk> not to mention that syslog starts a long time after udev anyway
<psusi> I was thinking just redirect to /var/udev.log instead of /dev/null ;)
<Keybuk> udev.log is something else
<Keybuk> it logs udevmonitor output
<psusi> it's a shame that you no longer see the output of mdadm on the boot screen
<RainCT> uhm.. I can't install libssl0.9.8_0.9.8g-4ubuntu3.1_i386.deb
<cjwatson> RainCT: what is the problem?
<RainCT> dpkg-deb (subprocÃ©s): llegida curta en buffer_copy (s'ha produÃ¯t un error en escriure al conducte en la cÃ²pia)
<RainCT> dpkg-deb: el subprocÃ©s paste retornÃ  el codi d'eixida d'error 2
<RainCT> cjwatson: translated that would be +/-: short read in buffer_copy (there was an error writing to the copy conduct)
<cjwatson> "failed to write to pipe in copy" in fact
<cjwatson> that's usually transient, or possibly out of disk space
<cjwatson> check that you have enough free disk space? otherwise try again
<cjwatson> but basically that's internal in dpkg, and not usually a problem with the package
<cjwatson> unless there are other nearby errors which are more specific
<RainCT> what can it be beside disk space (/ has 2.2GB free)
<ogra> with /var on the same partition ?
<RainCT> yes
<RainCT>  /usr is in a different partition though, and has 12 GB free
<RainCT> (yeh, I know I should repartition ^^)
<cjwatson> would need an strace of dpkg really to see what's actually going wrong
<cjwatson> errno 2 is no such file or directory
<cjwatson> very weird
<cjwatson> is anyone else seeing this problem?
<cjwatson> RainCT: and could you put the entire output from dpkg somewhere?
 * ogra had proper upgrades everywhere
 * RainCT is trying with aptitude full-upgrade, hadn't noticed the new packages are already in the repos
<cjwatson> RainCT: could you provide the full output, before you lose it?
<RainCT> cjwatson: sure, but there's not much more
<RainCT> cjwatson: http://paste.ubuntu.com/11906/plain/
<cjwatson> out of interest, does the directory /usr/lib/i586 exist?
<RainCT> cjwatson: yes, it contains the files libcrypto.so.0.9.8 and  libssl.so.0.9.8
<cjwatson> very strange
<ogra> oh, same here
<cjwatson> of course you're doing a downgrade
<cjwatson> which is not a great plan
<cjwatson> so, while I can't imagine why, it could be something to do with that
<ogra> whats the reason for that special dir ?
<ogra> seems very libssl specific
 * stgraber wonders why one of his 3 routers don't seem to accept the new OpenVPN key ... all three are dd-wrt with the exact same custom firmware :( let's wait and see if things improve by themselves :)
<geser> isn't that dir used by packages with cpu-optimsation?
<cjwatson> geser is correct
<cjwatson> it is not openssl-specific, AFAIK; the linker looks at it
<stgraber> ogra: btw, I guess italc is also concerned by the SSL thing no ?
<ogra> stgraber, for sure :(
<stgraber> ok, one more thing to add to the long list of keys to rebuild ...
<ogra> ah, debian bug #139783 explains the dir thing apparently
<ubottu> Debian bug 139783 in openssl "openssl: debian version very slow" [Important,Closed] http://bugs.debian.org/139783
<l3on> Hi, is it solved open-ssh problem in gutsy release?
<cjwatson> l3on: in gutsy-security, yes
<l3on> someone said me that it was impossible install it forum security, apt returns an error
<l3on> is it right?
<cjwatson> l3on: that's fixed now
<l3on> ok, tnx cjwatson
<andrew___> cjwatson: what should I do if one of my public keys is listed as "COMPROMISED"?  Is there a page that goes into more details about this stuff?
<cjwatson> andrew___: http://www.ubuntu.com/usn/usn-612-2
<andrew___> But no special action beyond that?
<stgraber> andrew___: revoke and generate a new one, that's basically it
<awalton__> did launchpad autoreap the bad keys?
<cjwatson> awalton__: not so much of the "auto", but I gather action has been taken there
<andrew___> Fair enough - FWIW, the use of upper case lead me to assume there was something extra to be doing with that.  If anyone else is as jumpy as me, you might want to consider putting it in the man page/downcasing the message.
<awalton__> cjwatson, all I needed to know. just wanted to know if it was going to take care of it or if I would have to.
<awalton__> cjwatson, thanks.
<cody-somerville> Does this mean I'm okay? Unknown (no blacklist information): <key stuff here> /home/cody-somerville/.ssh/id_rsa.pub ?
<ScottK> cody-somerville: As I understand it, that's a don't know response.
<andrew___> In anticipation of more panicky people, is there somewhere good to put together a FAQ?
 * ScottK redid all his keys before the new SSH packages hit, so doesn't actually know.
<stgraber> cody-somerville: yep, that's ok
<cjwatson> andrew___: COMPROMISED absolutely deserves to be upper-case
<cjwatson> andrew___: any such key must be regenerated
<stgraber> cody-somerville: COMPROMISED: 2048 isn't
<cjwatson> andrew___: http://www.ubuntu.com/usn/usn-612-2 is meant to be the FAQ, pretty much ...?
<cjwatson> cody-somerville: that means there's no blacklist for that key type/size combination; you'll have to figure out from things like key generation time whether that key is vulnerable
<andrew___> Well, there's already two Qs not explicitly A'd.  For panicky people, I don't mind putting in a bit of time to repeat the answer for peace of mind.
<cjwatson> andrew___: it wouldn't hurt, but I'm exhausted and not able to set one up
<cjwatson> however, I'd rather there not be a semi-official FAQ filled with possible misinformation
<cjwatson> can this wait until tomorrow?
<andrew___> If you'd rather I not do it, sure.
<cjwatson> well, I'd rather the person that does it have authoritative information
<andrew___> Fair enough.  In the mean-time, the standing advice is to regenerate your keys if there's any doubt, and not to do anything else?
<cjwatson> yes
<andrew___> Okay, thanks.
<cjwatson> for paid-for SSL keys, I would understand people not wanting to regenerate them frivolously, but for SSH keys there's really little reason not to regenerate them if in doubt
<cody-somerville> gah,  almost all my keys are compromised :(
<LaserJock> ssh keys are rather cheap, at least compared to signed gpg keys
<Keybuk> gpg keys are cheap :)
<cjwatson> gpg, fortunately, is not affected
<andrew___> I'll pass that on if anyone asks, with the appropriate I'm-not-worthy's :)
<cjwatson> andrew___: I didn't mean to imply unworthiness, BTW, I'm just very conscious of how Chinese whispers tends to work
<Keybuk> gpg --gen-key ... "lamont, sign my key" ... "gpg --send-key" - et voila, new gpg key and back in the well-connected set ;)
<RainCT> cjwatson: (the debs from the repos worked)
<Mithrandir> Keybuk: except when nine-tenths of the WoT is gone.
<lamont> Keybuk: heh
<Keybuk> Mithrandir: FIRESALE!
<Mithrandir> since nearly all of them (well, except lamont) has DSA keys. :-P
<stgraber> Keybuk: hmm, and if lamont's key would also be compromised ? :)
<philsnow> cjwatson: i had never heard that term ('chinese whispers') until one of the latest episodes of dr who
<Keybuk> stgraber: then o/~ with just a handful of men / we'll start / we'll start all over again
<Keybuk> <fx: guitar solo>
<andrew___> cjwatson: Yeah I completely agree.  I've no problem admitting I'm not a security professional, it's just a fact that needs to be passed on because of the aforementioned whispers.
 * jdong is still unfamiliar with the term :)
<andrew___> Chinese Whispers it's a game schoolchildren play, where they each whisper a message to the next.
<jdong> are any non-mozilla browsers affected?
<jdong> andrew___: is it like telephone?
<andrew___> I don't know, I've not played that game :s
<jdong> andrew___: n whispers to n+1, at the end the message is garbled?
<andrew___> Yeah, that's the one.
<LaserJock> I thought that was called Telephone
<jdong> andrew___: ok so I guess I only know the politically castrated terminology then ;-)
<jdong> LaserJock: ^^ :)
 * andrew___ becomes old
<LaserJock> I guess maybe the Chinese were whispering before the telephone was invented
<cody-somerville> cjwatson, Should I put something on the fridge?
<jdong> cody-somerville: yeah stock up on milk, we're running low
<cjwatson> cody-somerville: if you do, please refer to the USN
 * cody-somerville nods.
<cjwatson> cody-somerville: we may be updating the web copy of the USN with more information
<ogra> cjwatson, hmm, looks to me like that broken pipe dpkg error occurs if something tries to overwrite conflicting files, there was just a mail to ubuntu-de with the same error where a third party package claimed an already owned file
<cody-somerville> Posted to the fridge.
<[reed]> cjwatson: does ssh-vulnkey have a blacklist for 2048 keys?
<LaserJock> cjwatson: the USN has no information on regenerating system keys, is there anything special that has to be done for that?
<[reed]> 2048 bit keys, that is
<geser> [reed]: look into /etc/ssh/
<cjwatson> [reed]: RSA 2048-bit, yes (DSA is only valid for 1024-bit, technically)
<cjwatson> LaserJock: vulnerable 2048-bit RSA and 1024-bit DSA keys will be regenerated automatically if necessary
<[reed]> cjwatson: true, but that change to ssh-keygen for DSA is fairly recent!
<[reed]> so, I'm seeing conflicting results
<cjwatson> LaserJock: though not other keys; they're just ssh-keygen with empty password though
<cjwatson> slangasek: ^--
<[reed]> between ssh-vulnkey and dowkd.pl
<cjwatson> [reed]: 1024-bit DSA has never been valid, FYI; the standard prohibits it
<[reed]> cjwatson: you mean 2048
<[reed]> I hope
<[reed]> :p
<cjwatson> [reed]: err, yes, I do
<cjwatson> I mean any more than 1024 bits
<[reed]> true, but for a long time, ssh-keygen would allow people to make >1024 bit keys
<cjwatson> sure
<cjwatson> [reed]: you're welcome to mail me about it; I'm going to do other things now
<cjwatson> or file a bug report
<slangasek> cjwatson: ack
<[reed]> so, I'm finding it weird that ssh-vulnkey is warning about them while dowkd.pl is checking them and passing them
<[reed]> :/
<LaserJock> cjwatson: ok, I just noticed that on one of my machines the openssh-server upgrade regerated the system keys, but on the other it didn't. Should I assume if it didn't regenerate I'm ok?
<cjwatson> [reed]: I need output from both in order to help
<cjwatson> LaserJock: ssh-vulnkey will tell you the status of the host keys
<[reed]> cjwatson: what's your e-mail address?
<LaserJock> cjwatson: k, I guess I'll just go with that. I was just going to regenerate them all anyway.
<winjer> dowkd.pl gives loads of false positives, and some false negatives too i think
<cjwatson> [reed]: cjwatson@ubuntu.com
<[reed]> cjwatson: which do you personally recommend? high-number of bits RSA key or a 1024-bit DSA key?
<cjwatson> for high-security single-use keys, I use 4096-bit RSA keys
<cjwatson> for routine use I normally use 2048-bit RSA, although I may change that
<[reed]> and why RSA over DSA?
<cjwatson> I don't think DSA is fundamentally broken though - it just happens to be weak in the presence of a weak RNG
<cjwatson> ^- only reason
<[reed]> k
<cjwatson> I don't think use of DSA is insecure in general, at the moment
<cjwatson> but at the moment I think ssh-keygen's default of 2048-bit RSA is fairly reasonable
<[reed]> the DSA vs. RSA debate is almost as bad as the vi vs. emacs debate
<[reed]> :/
<psusi> is it as silly as the MD5 hash collision "attack"?
<cjwatson> psusi: is what as silly?
<psusi> the DSA/RSA debate you were talking about
<cjwatson> err, apples and oranges? I'm not sure debates and cryptanalysis are comparable
<psusi> the "debate" is whether MD5 is "broken"
<psusi> because you can carefully craft two documents that differ but give the same hash.... still can't create a second document with the same hash as an existing one ( that you didn't carefully create )
<cjwatson> psusi: it is broken in one sense, but not in another sense
<cjwatson> (the debate is no doubt by people who don't understand a lot of crypto)
<cjwatson> psusi: the collision attack is real, but as you observe it is not as bad as it could be; the name for the second case is a second-preimage attack
<cjwatson> psusi: however, a demonstration of a collision attack is good evidence that a second-preimage attack is not all that far off, so there's no grounds for complacency either
<k0p> hi all
<cjwatson> psusi: similarly, the flaw in DSA in the presence of a weak RNG is real; grounds for not being too complacent, but not grounds for panic - except in the case of an advisory such as this
<zul> I updated an apache2 to hardy-proposed but didnt get an email back can someone check on it?
<andrew___> RainCT: do you actually use reportbug-ng to send bugs to Debian?
<seb128> jwendell: <mneptok> for those with GNOME access and personal keys they no longer trust, please update your system, re-generate keys, and send mail to accounts@gnome.org with the subject "replace Debian/Ubuntu key"
<seb128> jwendell: replying there since that was mentioned on the ubuntu chans ;-)
<jwendell> seb128, thanks
<seb128> you are welcome
<jwendell> seb128, should I attach my id_rsa.pub file?
<seb128> mneptok: ^
<jwendell> will do..
<seb128> jwendell: I guess so, id_rsa.pub or id_dsa.pub anyway
<jdong> jwendell: also send a copy of id_dsa and $500 to paypal jdong@ubuntu.com
<jdong> ;-)
<jwendell> jdong, ah, you're not the guy who found out the issue...
<RainCT> andrew___: no :P
<jdong> jwendell: nah, I'm not nearly close to that skill level and I will likely not make it up there
<andrew___> RainCT: Good, then you won't freak out about suggestions for having it removed :)
<jwendell> we should take that money from the guy who patched ssh in the first place
<jdong> jwendell: so much for the idea of code policing pedantic warnings in the first place :)
<RainCT> andrew___: I still disagree with removing the option to use it to send bugs to Debian, though
<jwendell> what make debian devs think they should patch upstream code in the first place?
<andrew___> RainCT: if it stays in, I agree.  I just don't think it should be the default.
<jdong> jwendell: they saw a valgrind "memory leak" and figured it's a good idea to patch it.
<RainCT> andrew___: yeh, I don't mind wheter it's the default or not :)
<jwendell> this is a good moment to rethink about patching upstream code at all...
<andrew___> seb128: presumably accounts@gnome.org requires that all e-mail be PGP-signed?  (Sorry if that's a silly question)
<jwendell> andrew___, nope
<andrew___> So what's to stop me from saying I'm Miguel de Icaza and handing over my id_rsa.pub?
<jdong> andrew___: your mail client is not Novell/Ximian evolution.
<jdong> </joke>
<jwendell> hehe
<jwendell> jdong, you're so funny today :P
<jdong> lol
<andrew___> Also, I'm guessing he speaks better Spanish than me :p
<slangasek> zul: you would have not gotten an email because the publisher was down in deference to the openssl security updates; you should have gotten an email by this point, I think?
<zul> slangasek: ok thanks
 * mneptok waits for jwendell to answer e-mail
<RainCT> good night
<Riddell> evand: how come d-i asks if the time is set to UTC but ubiquity doesn't?
<Keybuk> Riddell: u6y doesn't ask silly questions
<Riddell> neither should d-i
<Keybuk> d-i can get away with asking any that it likes ;)
<Riddell> who has powers to close specs that people have randomly created?  e.g. https://blueprints.launchpad.net/ubuntu/+spec/kmilo-controls-kmix-selected-sound-card
<Keybuk> more correctly
<Keybuk> u6y knows whether or not you have a windows partition
<Keybuk> so can make an intelligent judgement as to what your system clock should be
<Keybuk> d-i doesn't have that knowledge in the right place, so has to ask
<Riddell> ah, clever old ubiquity
<Keybuk> and since it assumes a more expert user, it's safe to do so
#ubuntu-devel 2008-05-14
 * ScottK would just like to be able to say I want UTC after confessing to living in North America.
<cjwatson> Keybuk: not true, d-i has the same knowledge - purely a matter of being able to get away with more questions
<cjwatson> it's unfortunately not as silly a question as you might like it to be
<cjwatson> once again sanity meets the real world
<Keybuk> well, yes
<Keybuk> u6y can assume things about the world
<cjwatson> [reed]: FYI Ben Laurie (one of openssl upstream) has confirmed that it's OK to leave the second MD_Update call commented out (comment 38 on his blog post that IIRC you referred to earlier)
<Keybuk> d-i is for experts
<[reed]> cjwatson: yep, I saw. Thanks!
<cjwatson> but it is not correct to say that d-i doesn't know whether you have a Windows partition
<[reed]> cjwatson: will you be at UDS?
<cjwatson> it does
<cjwatson> [reed]: yep
<[reed]> cjwatson: ah, ok. I'll see you there then.
<[reed]> :)
<Keybuk> cjwatson: noted
<slangasek> well yes, d-i by all rights should be able to figure out whether your clock is UTC or not, for all but a narrow band of users, by also comparing it to ntp; but the implementation is lacking currently :)
<Keybuk> cjwatson: late night debugging?
<cjwatson> sleep failure
<Keybuk> I've just learned that Upstart crashes on the openvz variant of our kernel
<Keybuk> due to an idiotic patch in the openvz set that un-POSIXes mmap() behaviour
<Keybuk> that was fun to debug
<Keybuk> oh yes
<StevenK> Keybuk: But you aren't bitter in the slightest? :-)
<Keybuk> I'm very bitter
<Keybuk> but that's unrelated ;)
<StevenK> Yes, I was being ironic :-)
<Keybuk> cjwatson: I often find that after a few failures to sleep, I get to sleep fine
<Keybuk> and then fail to resume
<Keybuk> :)
<cjwatson> heh
<cjwatson> * Keybuk is now known as Linux
<evand> haha
<dholbach> good morning
<ion_> Hi
<dholbach> hi ion_
<ion_> What's up?
<dholbach> I'm just waking up :-)
<ion_> I managed to "fix" my sleep cycle by skipping one night's sleep with the third try. :-)
<dholbach> wow
<fabbione> morning guys
 * fabbione gets ready to release cluster 2.99.01
<pitti> Good morning
 * bryce waves
<ion_> Hi
<pitti> james_w: any luck with PK?
<james_w> didn't get a chance to play with it yesterday, sorry.
<pitti> james_w: no need to be, I was just curious
<ion_> PK?
<james_w> ion_: PolicyKit
<james_w> or PackageKit I suppose now, but the conversation works for either :-)
<slangasek> Phenyl Kit-onuria
<\sh> whoever is to blame for the ssl crap...this guy gives me really a hell of a day start
<desrt_> ya.  that's a fun one to wake up to.... ugh.
<pitti> tkamppeter_: "- Forth generation of Foomatic
<pitti> tkamppeter_: nice typo!
<\sh> desrt, yeah...means to upgrade a lot of hardy installs for me now...which are all freezed :( anyways...tests were done already yesterday night...so it's only work
<desrt> this is some scary stuff
 * desrt is upgrading servers like crazy
<desrt> all of my keys seem to be in the 'compromised' list :(
<pitti> desrt: hah, I had only two, but I updated them all anyway (ssl and ssh)
 * desrt has ssh keys scattered all over the freakin' place :/
<Mithrandir> this is when I'm happy my primary SSH key those days is an RSA key living on a smart card.
<pitti> the more intense fun was to explain all users on my server why I ripped their SSH keys and how to rebuild them
<desrt> hmm
<desrt> dapper hasn't gotten updated packages yet, it seems
<RAOF> Dapper doesn't need them, right?
<RAOF> It's pre-breakage.
<pitti> desrt: not affected
<desrt> it needs it for the blacklisting of keys generated by borked users, though
<\sh> oh hooray...
<\sh> soren, ifenslave-2.6 update won't break my systems using it, right? ,)
<desrt> or atleast needs ssh-vulnkey so that i can know which keys are affected....
<pitti> kees, jdstrand: ^ is a dapper version of the -blacklist packages planned?
<cjwatson> yes, it is
<cjwatson> I just haven't quite got around to doing a dapper backport of the openssh stuff
<YokoZar> pitti: could you please push this to -updates now that it's been tested?  https://bugs.launchpad.net/bugs/224042
<ubottu> Launchpad bug 224042 in wine "Wine 64 bit does not depend on lib32nss-mdns package; dns lookups broken" [Medium,Confirmed]
<desrt> so if something is in the 'compromised' list does that mean that somewhere someone has a copy of my private key?
<desrt> like, that key was actually generated....
<Mithrandir> desrt: it was generated from a list of 64k possible keys.
<desrt> that's really really bad, eh?
<Mithrandir> (* key length, etc, but still)
<slangasek> which means that, yes, multiple someones have a copy of your private key
<pitti> desrt: no, it's really really, REALLY bad
<winjer> yes
<winjer> it's terrifying
<desrt> i hate cryptography
<Mithrandir> crypto is good.
<winjer> rm /home/*/.ssh/authorized_keys
<jamesh> desrt: it means that your key can log you into more systems than you know
<desrt> you read all of these textbooks about how secure it is
<desrt> and then something like this happens
<jamesh> which makes it more useful
<pitti> desrt: mathematically it is
<Mithrandir> jamesh: I guess that's one way to look at it..
<desrt> pitti; nod.  someone always screws up the implementation, though :p
<pitti> desrt: implementation adds about 20 new dimensions to the model which can't be covered by maths :/
<Mithrandir> desrt: most of the textbooks I've read about it is how hard it is to get it right and how the devil is in the (implementation) details.
<pitti> it also adds a new meaning to "open"ssh, "open"vpn, "open"ssl, etc. -- now even more open!
 * desrt can't even imagine how something like this goes unnoticed
<jamesh> alternatively, you can use a special authorized_keys file with 64k entries that removes the need to exchange keys to get secure logins
<desrt> pitti; srsly.
<pitti> desrt: well, 64K is still more keys than you'd just spot by comparing fingerprints occasionally
<desrt> jamesh; i guess that won't work after the upgrade
<\sh> desrt, security is overrated ,->
<desrt> jamesh; just another way ubuntu is working to restrict my options
<Mithrandir> desrt: people don't do code reviews.  This is quite bad, especially on security-sensitive software.
<jamesh> I would have thought the openssl developers would want to keep their code in a state where you can run memory debuggers on it though.
<cjwatson> desrt: it did get noticed ... eventually
<liw> desrt, debian and ubuntu both have about a _billion_ lines of source code, and potentially every one of those lines is a security problem... it's easy to miss things (but the beauty of free software is that it's also _possible_ to find things before the bad guys)
<jamesh> I mean, memory errors in that code aren't particularly good for security either ...
 * desrt finds an odd id_rsa.keystore file that didn't used to get created
<cjwatson> seahorse, I suspect ...
<desrt> tricky.
 * desrt nukes everyone's authorized_keys files
<soren> \sh: You would have to have taken very special care to make it so.
<soren> \sh: In other words: I can't imagine it would break anything, no.
<\sh> soren, thx...I just wanted to be sure, that it doesn't try to "restart" any of the bondings...which could lead to unforseen experiences ;)
<soren> \sh: No, it doesn't do anything like that in the maintainer scripts.
<dholbach> bryce: does bug 226156 look OK to you?
<ubottu> Launchpad bug 226156 in libxfont "After update in intrepid branch Xorg " [High,Confirmed] https://launchpad.net/bugs/226156
<dholbach> I mean the patch in there - it'd be nice to get it in, so intrepid X would work :)
<bryce> dholbach: looking
<bryce> dholbach: the patch looks fine, but I'm curious how it fixes the issue
<dholbach> bryce: unfortunately sistpoty is not around to ask the question
<dholbach> doko, slangasek: ^ do you have an idea about why the patch in bug 226156 would fix the issue?
<ubottu> Launchpad bug 226156 in libxfont "After update in intrepid branch Xorg " [High,Confirmed] https://launchpad.net/bugs/226156
<slangasek> dholbach: looking
<bryce> dholbach: so it looks like it's being built with LDFLAGS="-Wl,-Bsymbolic-functions", and setting to LDFLAGS="" makes it work
<slangasek> dholbach: ah, cripes
<slangasek> right, this is being done to override -Wl,-Bsymbolic-functions
<dholbach> I'm happy with whatever fixes X in intrepid, so I don't have to keep the old libxfont1 :)
<bryce> I'm not familiar enough with linker options - what do those two do?
<ogra> asac, i think there are only one or two FF extensions and the idea of willow-ng is actually been to make them obsolete by using a bayesian spam filter on system level for web content filtering ... giving willo the opportunity to force FF into a proxy setting and unprivileged  user cant change is more intresting than extensions here imho (and extension would be a fine additional thing probably though)
<ogra> s/and/an/
<slangasek> bryce: -Wl,-Bsymbolic-functions is a single option; its purpose is to optimize the start-time symbol resolution at the expense of some "correctness", by causing any references to symbols available within the lib itself to be bound at build time
<bryce> slangasek: ah; is it a new addition?  is there risk in turning it off?
<slangasek> bryce: there's no risk at all in turning it off, AFAIK it's entirely a performance thing
<asac> ogra: well. i think that users would love a complete solution that is easy to setup and use
<dholbach> slangasek: could it be a binutils bug?
<asac> ogra: not only for schools, but also for parents i guess. not sure where i hit my ethical barrier though ;)
<slangasek> dholbach: ... unlikely
<slangasek> this option only affects the linker stage
<ogra> asac, right, willowng is designed to run as a localhost service as well as a network wide content filter
<ogra> depending on your setup
<maswan> hm, no new openssh for dapper with the blacklisting etc?
<asac> ogra: how is willowng managed?
<asac> ogra: do we need a frontend?
<ogra> its a bayesian filter as well as a white/blacklist tool for domains l
<ogra> the backend lstes on a port like any other proxy
<cjwatson> maswan: on the list, just wasn't as urgent
<ogra> *listens
<maswan> cjwatson: thanks, and good.
<asac> ogra: btw, the general config mechanism should have improved in ffox 3/xul 1.9 ... you should be able to specify your own file in /etc/ now
<ogra> the frontend communicates through dbus to the backend, there are gtk and web frntends
<asac> ogra: if its bayesian ... how well does it work? how much cycles does it need?
<asac> how much training do we need? can we provide default data for profiles?
<\sh> hmmm..does anyone know if a wintv (haupauge) DVB-T USB Stick (Nova T Lite) works on linux? ;)
<ogra> asac, i have to look deeper into the code, but we'll have the author at UDS ;)
<ogra> asac, Amaranth wrote it as SoC
<bryce> dholbach: ok the patch sounds fine to me - do you want to go ahead and upload it?
<dholbach> bryce: ok, can do
<Amaranth> it's a neat idea, just needs someone to actually do it :)
<ogra> Amaranth, thats my plan for intrepid :)
<Amaranth> I setup the basic design for how to do it and a bit of a proof-of-concept for the code and no one ever finished it :/
<asac> ogra: wrote what? willowng?
<asac> ok
<ogra> asac, right
<Amaranth> python makes the proxy part really easy
 * \sh 's doomed again...new version of this dvb-t stick which is not supported by kernel :(
<RAOF> Hah!  DVB + USB = pain!
<\sh> RAOF, usb id: :7050 works ;) but I have , you guess, 7070;)
<RAOF> See?  Pain. :P
<\sh> RAOF, I'll fix my pain...want to see the EM during work on my linux...so it has to work somehow
<RAOF> Hax0r the USB id into the driver!
<\sh> RAOF, yes..this evening when I have to time to play with the joys of kernel hacking ;->
<RAOF> Or, for more reasonable suggestions, linuxtv.org.
<RAOF> If you're lucky, you just need to add that USB id to the list of things the driver will drive.
<RAOF> But the linuxtv drivers are often ahead of the mainline drivers.
<RAOF> Actually, when I say 'often', I mean 'always', since the mainline drivers are merged from a linuxtv hg tree every now and then
<\sh> RAOF, yeah found it...needs some tweaking ;)
<RAOF> The driver, or the linuxtv mercurial tree?
<dholbach> bryce: uploaded
<YokoZar> Is lzma the default compression format in intrepid yet?
<slangasek> no, nor will it be
<liw> slangasek, why? performance reasons?
<Amaranth> it only makes sense for a few packages
<slangasek> yes - lzma's space savings only outweigh the performance issues for the largest of packages
<Amaranth> otherwise the performance loss is not worth it
<Amaranth> performance and memory
<YokoZar> Is lzma really more efficient percentage-wise the larger packages get?
<YokoZar> I would think it depended on the kind of data in the package
<cjwatson> YokoZar: it does depend on the kind of data, but tends to be correlated with size
<YokoZar> I guess a related question is how lzma varies in terms decompression speed too.  If the poorly compressed packages still decompress quicker, then it's not so bad
<cjwatson> YokoZar: its main problem is substantial memory use on decompression
<cjwatson> YokoZar: so very slow on smaller-RAM machines
<pwnguin> interesting
<pwnguin> cjwatson: what about adopting an rsync-able compression?
 * cjwatson <- not a dpkg developer
<ion_> That probably would be helpful with zsync as well.
<cjwatson> well, not really
<pwnguin> from what i've read, you can modify gzip for something like 3 percent
<pwnguin> 3 percent bigger archives and it's suddenly rsyncable
<pwnguin> but yea, lzma uses a lot of memory / history
<pwnguin> not something you'd be happy about on say an nslu2
<pitti> doko: gcc-defaults hardy-proposed upload does not have a bug# in the changelog; can you please add it and upload again?
<doko> mehh, there is no bug report, I can't close the soyuz bug ...
<dholbach> geser: could it be that libgnome2-canvas-perl libgnome2-perl libgnome2-vfs-perl libnet-dbus-perl still need rebuilds?
<pitti> doko: "I can't close the soyuz bug"?
<slangasek> you can open a gcc-defaults/Ubuntu task for the soyuz bug
<doko> pitti: https://bugs.edge.launchpad.net/soyuz/+bug/227184
<ubottu> Launchpad bug 227184 in soyuz "Upload processor must reject duplicated binary uploads" [High,In progress]
<cprov> doko: err, why would you want to close the soyuz task of the bug ? the fix is not yet merged in RF ;)
<pitti> doko: please forgive my ignorance, but what does it have to do with the gcc-defaults dependency fix?
<slangasek> pitti: it's only because of the soyuz bug that the current gcc-defaults package was accepted at all
<pitti> ah
<doko> pitti: please reject, will upload with a bug number
<pitti> doko: done already, thank you!
<cprov> pitti: right, in 1.2.5 builds generating binaries already known (published) will become failed-to-upload and the uploader will receive a build-failure-notification.
<geser> dholbach: Hi, might be. I didn't check them all yet. I looked yesterday at the *-perl FTBFS and started looking what needs to be done to resolve them.
<dholbach> geser: good work! :)
<soren> I thought bzip2'ed orig.tar's were kosher now?
<sdh> openvpn vulnkey stuff in hardy but not gutsy yet... right?
<sdh> erk
<sdh> if your openvpn key is vulnerable, it doesn't survive dist-upgrade and you can't get it up again
<sdh> which could be bad if you rely on your openvpn link
<siretart> http://www.ubuntu.com/usn/usn-612-4 seems broken
<soren> siretart: How so?
<siretart> ah. fixed now
<tkamppeter> pitti, hi
<emgent> http://thc.emanuele-gentili.com/~emgent/Pitti.jpg
<emgent> pitti palace in Florence (italy) :)
<james_w> when openssl restarts does it open a temporary connection on another port? https://lists.ubuntu.com/archives/ubuntu-uk/2008-May/012957.html
<pitti> emgent: heh; believe it or not, I was there already :)
<ion_> :-)
<pitti> emgent: hm, actually that was the real Pallazzo Pitti
<emgent> pitti: ehehe yes
<sdh> ugh..... lost openvpn boxes during upgrade :(
<emgent> pitti: http://it.wikipedia.org/wiki/Palazzo_Pitti
<emgent> :)
<tkamppeter> pitti, I have a problem: I have uploaded 14 Brother driver packages. 13 got accepted and 1 rejected. The rejected one is brother-cups-wrapper-common_1.0.0-10-0ubuntu4 and the error message in the notification mail is "Not permitted to upload to the RELEASE pocket in a series in the 'CURRENT' state.". What is broken in that package?
<soren> You tried to upload it to hardy instead of intrepid.
<soren> tkamppeter: ^
<pitti> tkamppeter: what soren said
<tkamppeter> pitti, soren, thanks. Then Saivann forgott to switch the changelog entry of this one package to intrepid.
<tkamppeter> pitti, I have corrected the debian/changelog now and re-uploaded the package. So it should arrive soon.
<tkamppeter> pitti, soren, thanks. The package got accepted.
<soren> tkamppeter: You're welcome.
<doko> munckfish: you should be able to use the system gcc to build the kernel, no need to use ppu-gcc
<munckfish> doko: hi
<munckfish> yes I've been doing that on my PS3
<munckfish> but I think a couple of other folks have been trying to cross compile on x86 (or whatever)
<munckfish> do you mean this is even possible with standard GCC on x86?
<munckfish> doko: I have to go out shortly will you be around later? There's a couple of things I need to ask you.
<munckfish> either that or I can mail you
<doko> sure
<doko> I'm online
<munckfish> ok speak later then
<geser> dholbach: 3 new debdiffs on bug #230016 to sponsor
<ubottu> Launchpad bug 230016 in libtemplate-perl "[intrepid] Rebuild with perl 5.10" [Undecided,Fix released] https://launchpad.net/bugs/230016
<dholbach> geser: uploaded
<geser> dholbach: thanks
<elpargo> hi, I was wondering if someone cared when FF3 was introduced to break people's firebug by making official the exact version of FF3 beta that broke firebug.
<cjwatson> elpargo: seems more important to fix it ...
<cjwatson> looks like a new version of Firebug fixes it? e.g. http://blog.slaven.net.au/archives/2008/03/11/new-version-of-firebug-works-in-firefox-3-beta/
<elpargo> cjwatson, sry but I don't agree. that's why it's still in beta so the plugins will catch up.
<cjwatson> elpargo: you don't agree that we should fix it?
<cjwatson> (e.g. by incorporating newer versions of the plugins that support Firefox 3)
<elpargo> cjwatson, yes the irony is that firebug 1.1b12 works in FF3b4 but not in FF3b5+ and b5 is what ubuntu packaged.
<cjwatson> elpargo: we knew that we were going to have to be shipping a beta; as a result we will be putting effort into filing off the rough edges there for 8.04.1
<geser> elpargo: I've here firebug 1.2~b21+svn573-0ubuntu1 and it works with FF3b5
<cjwatson> the version geser quotes is what's in hardy
<ion_> How about when Firefox 3 final is released and there is a number of extensions that are still not ported to it. Should a distribution delay switching the default browser even then?
<elpargo> cjwatson, actually I think it's a burocratic thing as if it didn't had ff3 you wouldn't be able to put it in in at least 6 months.
<cjwatson> elpargo: you are not being particularly helpful
<elpargo> geser, according to firebug people 1.2 is alpha, that's even worst.
<elpargo> worse*
<cjwatson> elpargo: switching from firefox 2 to 3 in a stable release was clearly completely unacceptable, not because of "bureaucracy" but because it would break people's expectations of a stable system
<elpargo> cjwatson, well I just don't like to get broken software.
<cjwatson> so we had to do so during the development cycle
<elpargo> cjwatson, yea that's why I think it was rushed in. causing issues like this one.
<elpargo> I also see a weird thing with flash + ff3 which I can't really reproduce.
<cjwatson> elpargo: the alternative was for security support for Firefox 2 to lapse very probably in the middle of the 8.04 stable maintenance period, forcing us to upgrade to Firefox 3 anyway
<cjwatson> elpargo: we did actually think about this
<cjwatson> Firefox security support has been a problem in this regard in the past, hence our unusual handling of it
<frandavid100> hiya
<elpargo> I see. I guess it's my fault for upgrading.
<cjwatson> I didn't say that
<frandavid100> Can you guys take a look at that ML message? https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-May/004207.html
<cjwatson> but please be patient while we are caught between a rock and a hard place and do our best
<elpargo> I did notice there is still a package for FF2, I guess I'm going to install that. Just wondering if it will crash with FF3 or should I deinstall this one first?
<cjwatson> they ought to be coinstallable
<elpargo> cjwatson, I know I said it. I normally don't upgrade after at least 2 months of the thing being out to get the .1 or .2
<frandavid100> The reply was that there is no need for a separate /home because ubuntu installs now recognise and preserve the existing /home. but how does it work?
<cjwatson> frandavid100: I'll reply to the mail you sent me
<frandavid100> hi cjwatson
<cjwatson> frandavid100: it works by removing all the bits of the filesystem that will actually cause problems for installation
<cjwatson> file by file
<frandavid100> I opened a thread at ubuntuforums and everybody seems pretty confused about that
<cjwatson> so /usr gets removed, for example, but not /home
<frandavid100> so it actually deletes everything but /home?
<frandavid100> oh that's cool
<cjwatson> that's not quite what I said :)
<frandavid100> hm
<cjwatson> it won't delete things like /data that it doesn't recognise either
<cjwatson> it deletes only the things it knows about, and which are likely to conflict
<cjwatson> the details are at https://wiki.ubuntu.com/UbiquityPreserveHome
<frandavid100> I'll take a look
<elpargo> frandavid100, what you are suggesting is to create a home partition with 1 click?
<cjwatson> elpargo: please read the whole thread first ...
<frandavid100> elpargo: basically yeah
<frandavid100> but there seems to be no need for it
<frandavid100> I really am not very computer literate, so I couldn't say which solution is better
<elpargo> I totally agree with you that's the recommended way to install linux. although making it automagic is very complex.
<frandavid100> you mean, technically? or complex to the user?
<elpargo> technically.
<cjwatson> elpargo: technically, that is not the recommended way (although use of the passive voice makes that confusing; who's doing the recommending? In this case I mean recommended by me :-) )
<elpargo> becuase it depends a lot on the use case. for example you have a university computer which has 100's of users then you need a huge /home. On the other hand you could have a tester computer that has a tons of packages installed. in both cases the optimal solution is opposite therefore which is the best?
<cjwatson> elpargo: the reason is that a separate /home is a decision you have to commit to right at the start, precisely when you have the least knowledge of what sizes to choose, and changing that decision afterwards is extremely painful with current tools
<cjwatson> I'm not interested in making the automatic defaults handle the case that's going to have a dedicated and knowledgeable system administrator involved; they can look after themselves
<frandavid100> you both seem to agree on that
<cjwatson> the point is that the whole system is much simpler when everything is on one file system
<cjwatson> that involves no difficult up-front decisions and no later painful changes
<frandavid100> cjwatson: in what cases can additional folders, not listed in the specification you linked, be created?
<cjwatson> and the only problem with it is that preserving /home on reinstall is hard: so we fixed that
<cjwatson> frandavid100: manually; it's pretty common for people to e.g. create /data or /space or whatever random name and dump stuff there, e.g. for shared files among lots of users
<cjwatson> and really there'd be no justification for removing that since it won't conflict with anything
<frandavid100> I think I get it
<elpargo> cjwatson, that is the case for a desktop computer yes.
<cjwatson> elpargo: right, which is what the defaults are aimed at
<frandavid100> so there would be no junk automatically created by the system, without me knowing it's there right?
<elpargo> also you are suggesting that I only have ubuntu and you are also suggesting that I'll stick with ubuntu forever.
<cjwatson> just about everyone else will be less scared of partitioning
<frandavid100> not unless I created it myself
<cjwatson> elpargo: no, I'm really not
<cjwatson> elpargo: if you are multi-booting different Linux distributions, you can look after yourself with partitioning, and are unlikely to want to use the defaults anyway
<frandavid100> that's right... my proposal was intended for that use case anyway
<elpargo> cjwatson, then how do you pretend to run multiple linuxes with home in the same partition as linux?
<cjwatson> elpargo: I don't. If you want to run multiple Linux distributions, partition manually.
<wgrant> Are we waiting for 8.04.1 to fix -server ISOs for the SSH key issue?
<cjwatson> elpargo: I don't think it's necessary or appropriate for the defaults to handle that rare case.
<elpargo> cjwatson, well if you see the screeshots frandavid100 posted it's yet another option.
<cjwatson> elpargo: which will confuse regular users who don't need it into thinking it's a good idea for them.
<cjwatson> the only people who need this are the type of people who are quite capable of going straight into the manual partitioner and setting things up the way they like it.
<cjwatson> and that's fine, that's what the manual partitioner's for
<elpargo> OR which will make regular users think hey that's not such a bad idea, and hey look how easy can I set it up.
 * ogra thinks the migration assistant was already the right idea ... just needs more love and attention
<frandavid100> cjwatson: one last question: I guess it works either by telling the installer to use the whole drive, AND by using a specific partition?
<cjwatson> elpargo: but I actively don't want that, because then in a year's time they'll run into the hard fact that resizing partitions is a pain.
<elpargo> cjwatson, sry but I don't agree. I know many people that understand the concept but are scared of gparted.
<Hobbsee> cjwatson: any luck on getting IS to drop postmaster@, etc yet?
<cjwatson> elpargo: the installer doesn't use gparted
<cjwatson> Hobbsee: not yet
<cjwatson> frandavid100: yes
<frandavid100> cool
<frandavid100> you got me convinced then
<frandavid100> thanks :)
<elpargo> cjwatson, don't take it literally you know what I wanted to say.
<frandavid100> gotta go for lunch, bye guys
<frandavid100> have a nice day
<Hobbsee> cjwatson: 720 mails in the moderation queue.  ouch.
<cjwatson> elpargo: no, I didn't. I consider the installer's current partitioner an improvement over gparted (at least for the installation case) in a number of ways and so I felt the distinction was relevant.
<cjwatson> frandavid100: oh, wait, one moment
<cjwatson> frandavid100: no, if you tell it to use the whole drive, that's basically equivalent to deleting all the partitions and starting from scratch
<cjwatson> (this could probably do with being better-documented)
<cjwatson> frandavid100: this is if you say "mount this file system as / please"
<cjwatson> ... this existing file system
 * Hobbsee wonders if it's worth clearing it out
<ion_> "Adding an option to the autopartitioner to enable all this functionality. Needs to meet the requirements: swap, ext3." How about people using swapfiles? Or no swap at all, e.g. on a box with solid-state "disk" and plenty of RAM.
<elpargo> cjwatson, yea that's true it's better at installing. although I prefer cfdisk :)
<cjwatson> swap files> open bug about it, I'd like it to happen but it involves some work
<cjwatson> (not as easy as it might sound)
<cjwatson> no swap> manual partitioning
<ion_> Does picking manual partitioning still allow you install over an existing partition?
<ion_> over the contents of, that is.
<cjwatson> yes, in fact that's really the only way you can do it
<ion_> Alright
<ion_> For someone with enough Linux-fu to use swapfiles in the first place, doing a reinstallation preserving home and then making it use a swapfile isn't a problem.
<elpargo> since we are in the subject it will be nice to convert the ntfs partition into reisers for some vendor lockin.
<frandavid100> cjwatson: good thing I read that last message before leaving haha
<cjwatson> frandavid100: I sent mail just in case
<frandavid100> thanks
<cjwatson> elpargo: *blink*
<frandavid100> but that makes it seriously less useful doesn't it
<cjwatson> I hope that's a joke ...
<cjwatson> frandavid100: well, if you say use entire disk, that kind of suggests wiping everything out
<frandavid100> gotta go
<cjwatson> frandavid100: but it's true that it would be useful for autopartitioning to be able to use existing partitions rather than deleting and reconstructing them
<frandavid100> catch ou later
<elpargo> lol yes cjwatson it was a joke
<lool> Hmm each time I remove/add my swap, Priority decreases in /proc/swaps... curious
<cjwatson> improved documentation on the autopartitioning menu would help here
<elpargo> yea that's scary.
<lool> I guess it's meant to have different swaps have decreasing priorities when all are inserted at once, but the counter is reused
<elpargo> and ff3 hangs....
<elpargo> damn it even needed a -9
<dholbach> elpargo: best to file a bug with the information listed on https://wiki.ubuntu.com/MozillaTeam/Bugs
<elpargo> well the problem is that you specifically say not to post a problem with my profile.
<elpargo> dholbach, ^
<dholbach> elpargo: it helps to figure out a way of reproduging the issue
<elpargo> cjwatson, we'll even with ff2 I can't get firebug running. it's giving out an exception now.
<elpargo> dholbach, thing is that firefox issues are 99% the plugins. it's a pain really and the only way I really know to fix it is not to run the beta version.
<dholbach> elpargo: in that case file a bug on the plugin
<cjwatson> we *have* to get the plugins working; going back to firefox-2 is *not* going to be an option for the lifetime of 8.04
<elpargo> dholbach, yes but that means finding out which one is failing.
<dholbach> elpargo: I fear that's the only way to come to clear idea of what the problem is
<elpargo> cjwatson, yes I agree with that but that is what testing teams should do.
<elpargo> dholbach, that the sys upgrade forced me to go to ff3 and now I can't run firebug.
<dholbach> elpargo: please provide the information listed on the wiki page and the mozilla team will look into the issue
<elpargo> dholbach, since the plugin is part of my profile the bug will be descarted.
<ogra> elpargo, how do you test something that doesnt exist ?
<ogra> if ff3 is final and the plugins get updated in 8.04.1 all the plugin packages in ubuntu will surely be tested to work with the ff version in 8.04.1
<elpargo> ogra, what are you talking about? the bug report?
<ogra> "<elpargo> cjwatson, yes I agree with that but that is what testing teams should do."
<elpargo> ogra, exactly my point ff3 is not final, so it shouldn't go in.
<cjwatson> I have answered that
<ogra> cjwatson, i was just pointing to what i was referring to
<cjwatson> it was an unpleasant trade-off between one problem you're seeing right now and one problem that you would have seen later if we hadn't taken this route
<ogra> oh, you didnt mean me :)
<cjwatson> I didn't, no
<elpargo> ogra, there is a testing team, that's why people install ubuntu+1
<cjwatson> it's not fair to say that the decision is wrong due to these problems you're seeing now (which are very real) while ignoring the problems that you would have encountered otherwise
<ogra> elpargo, but no software to test beyond what exists atm
<elpargo> cjwatson, I disagree by the time FF3 is out of beta, most mayor plugins will be updated.
<cjwatson> elpargo: normally that is true, but we were in an unfortunate bind and we decided that this is the best solution. I must ask you to stop endlessly rehashing it now.
<cjwatson> I have answered your questions about why we did it and been as patient as I could
<cjwatson> because I recognise that you are encountering real problems
<cjwatson> but, despite the problems, I still feel the alternative would have been worse
<elpargo> cjwatson, your the ones going at it again. the thing i said (which seems to be forgotten) was that even with the ff2 package the firebug plugin isn't working.
<cjwatson> we have time to update plugins in 8.04.1
<cjwatson> elpargo: "<elpargo> ogra, exactly my point ff3 is not final, so it shouldn't go in."
<cjwatson> that was belabouring a point I had already addressed at some considerable length
<elpargo> cjwatson, the fact that you replied with an unsatisfactory answer doesn't means I shall accept it. On the other hand ogra asked so I replied to him.
<ogra> elpargo, i didnt ask about ff3 inclusion since i agree with the decision taken
<cjwatson> elpargo: you may find it unsatisfactory, but nevertheless it is reality and furthermore is in the past. There is no point in you continuing to harangue #ubuntu-devel about it now because the decision has been taken and thoroughly committed to
<ogra> i was questioning your statement about testing
<cjwatson> elpargo: if you are willing to assist us with good-quality bug reports, then we can help you
<elpargo> cjwatson, and I'm not. I'm trying to ask now why the ff2 is failing with the install.
<cjwatson> the first step is to file a bug with the text of the exception
<elpargo> and I'm asking here because here is where that was suggested to me.
<cjwatson> (and note that our primary firefox maintainer isn't here today)
<cjwatson> and we're asking you to use the bug tracking system
<elpargo> cjwatson, don't you think that the bug needs to be confirmed before?
<cjwatson> that way, it can be properly dealt with; bugs filed on IRC have a very high chance of being lost, particularly when the relevant maintainer is busy trying to repair his laptop
<elpargo> no need for bureaucracy
<cjwatson> I haven't noticed bugs typically being confirmed *before* being filed
<ogra> heh
<cjwatson> it is not bureaucracy; it is the simplest way to ensure that your bug is actually remembered about, rather than dropped on the floor
<cjwatson> if you will not take advice on this, we can't help you
<cjwatson> in practice as a software developer it is completely impossible to remember about all bugs that somebody mentioned on IRC when you weren't even around
<elpargo> cjwatson, IMO the last resource to solving a problem is to file a bug. the thing I hate the most about bug reports is when the issue could be solved by just asking in IRC or a mailing list.
<cjwatson> it certainly can't be answered at present because you haven't provided any details of the problem
<cjwatson> you've just said it throws an exception
<ogra> elpargo, and how should we know whats on your screen ?
<cjwatson> a bug report is the most convenient way to record that data so that everyone can see
<Hobbsee> ogra: become psycopathic.
<cjwatson> most bug reports, fortunately, are filed without pages of discussion on #ubuntu-devel first, otherwise it would be impossible for us to get anything done
<elpargo> ogra, nice statement really.
<elpargo> I'm going to find out on my own since noone here wants to help how to reproduce the issue so I'll file you a precious bug.
<ogra> thanks :)
 * Hobbsee notes that none talking are firefox developers, either.
<elpargo> but please note you will close as won't fix it as the link suggest that things that work with an empty profile will be closed.
<elpargo> without not with
<cjwatson> I don't think you are in a position to tell us what we will do with a properly-filed bug with full instructions on reproducing it
<cjwatson> of course, if you can't give full instructions on reproducing it, that would be a practical problem, but I'm sure with a bit of effort you can construct that (e.g. "you need to install this extension first").
<cjwatson> this is a channel for coordination among Ubuntu developers, not for helping people reproduce bugs. Generally we like to help people out when they're cooperative, but it isn't usually any fun to help hostile people
<liw> http://www.debuggingrules.com/ -- that book can be quite handy
<cjwatson> and it's entirely true that issues with Firefox 3 are a very major problem with 8.04 at the moment; I'd go so far as to say one of the top three problems
<cjwatson> which is why we'd like to work with people who report problems, so that we can make sure that we've caught as much as possible
<cjwatson> but we need you to work with us too, rather than arguing at every turn
<Hobbsee> woot!  one non-spam mail!
<geser> dholbach: 4 new debdiffs on bug #230016 to sponsor and can you also sponsor bug #230246?
<ubottu> Launchpad bug 230016 in libtemplate-perl "[intrepid] Rebuild with perl 5.10" [Undecided,Fix released] https://launchpad.net/bugs/230016
<ubottu> Launchpad bug 230246 in hevea "[intrepid] Rebuild for ocaml 3.10.0 -> 3.10.1 transition" [Undecided,New] https://launchpad.net/bugs/230246
<Hobbsee> hmm, a few ubuntu-related, non-spam mails.
<dholbach> geser: can do
<geser> thanks
<emgent> heya people
<geser> Hobbsee: can I ask you for some give-backs?
<Hobbsee> geser: yes, if they're in one line, without commas.
<geser> Hobbsee: libnet-openid-consumer-perl libnet-openid-server-perl libmail-dkim-perl libmail-box-perl libkwiki-perl libkwiki-cache-perl libmail-verify-perl libdevel-lexalias-perl libexpect-simple-perl libdevel-gdb-perl libemail-valid-perl libgstreamer-perl libnet-dns-async-perl libnet-jabber-loudmouth-perl libnet-rblclient-perl libnet-socks-perl libnet-sip-perl libpoe-component-client-dns-perl
<geser> libpoe-api-peek-perl libpoe-perl
<ln-> that's two lines
<dholbach> geser: done
<dholbach> geser: thanks a lot for taking care of it
 * Hobbsee O.O @ lp
<ogra> openoffice@lp ?
<dholbach> geser: could it be that libgnome2-canvas-perl and libgnome2-perl are still unhappy?
<geser> dholbach: yes, but they need a fixed libgtk2-perl first
<dholbach> OK
 * dholbach hugs super-geser
<Hobbsee> geser: launchpad's broken buildd.py
<elpargo> cjwatson, contrary to your believe I am working with you if not I wouldn't be here in the first place.
<geser> Hobbsee: try de-activating the redirection to edge
<Hobbsee> geser: done, the script still goes to edge anyway.
<elpargo> Now the reason I said the bug will be ruled out is because your own guidelines say that if it's a profile issue it will be ignored.
<geser> hmm, pitti somehow managed yesterday to process my give-backs
<elpargo> which by the way I just confirmed it was, and now I lost my profile because firefox is kind enough to store a ton of complex data structures in it's .files and finding the error there is harder than just redoing all the config.
<pitti> Hobbsee: no, it didn't break the script; we just lost our super-powahs on edge
<Hobbsee> pitti: pity.
<pitti> Hobbsee: right, disable edge redirection, regenerate cookie, then it'll work
<Hobbsee> pitti: well, which does break the script, because it makes it not work.
<Hobbsee> pitti: how do i regenerate the cookie?
<pitti> cookies-sql2txt .mozilla/firefox/*/cookies.sqlite launchpad.net > .lpcookie
<pitti> Hobbsee: with http://people.ubuntu.com/~kees/scripts/cookies-sql2txt
 * pitti hugs kees
<asac> elpargo: there is no general rule or guideline that says that we ignore profile issues.
<elpargo> <dholbach> elpargo: best to file a bug with the information listed on https://wiki.ubuntu.com/MozillaTeam/Bugs
<elpargo> "Problems with corrupt profiles are not handled in bug reports: if your problem went away with a new profile, please do not report the problem as a bug."
<hwilde> elpargo, there is a difference between borked user profiles, and application . files
<elpargo> hwilde, for firefox?
<hwilde> elpargo, did you file the bug report yet ?
<elpargo> why will I if getting rid of the .mozilla/firefox dir fixed it.
<asac> elpargo: well ... in fact it means that we cannot deal with profile bugs that we cannot reproduce
<asac> elpargo: if there is a bug in firefox that corrupts profiles that can be reproduced we certainly want to hear about it.
<Hobbsee> hum.  now i've broken it
<elpargo> asac, but that's circular logic..
<geser> Hobbsee: still fighting with LP about the give-backs?
<Hobbsee> geser: yes
<Hobbsee> ahh, looks like that's fixed it.
<Hobbsee> dunno what was originally in cookies.txt though
<geser> should I ask pitti instead?
<Hobbsee> no, it's working now
<geser> good and thanks
<sistpoty|work> oh asac: for bug #229009, I'll fix up the css of revu soon... if that makes the table drawn correctly in ff3, are you still interested in this bug? (ff2 of gutsy here at work does render it correctly even though the css seems broken)
<ubottu> Launchpad bug 229009 in revu "doesn't render http://revu.ubuntuwire.com/details.py?package=gbemol correctly" [High,Confirmed] https://launchpad.net/bugs/229009
<Hobbsee> geser: all done
<asac> elpargo: feel free to help on bugs in #ubuntu-mozillateam and help us to address profile issues better by triaging those bugs - we certainly are open for innovation :)
<asac> sistpoty|work: not sure. did you report it as broken website in Firefox Help menu?
<asac> sistpoty|work: i think that would be a good start
<sistpoty|work> asac: no... well, problem is that this page is dynamic, so I guess I'll make a static copy first... but I'll do that once I'm home :)
<asac> kk
<munckfish> doko: you there?
<doko> munckfish: yes
<munckfish> doko: could you explain what you meant earlier about not needing ppu-gcc - in what context don't we need it?
<munckfish> I've been using standard gcc for everything on PS3 so far
<munckfish> I think these guys that reported that bug may have been trying to cross compile to powerpc from x86
<munckfish> Also, next question - you're the maintainer on a bunch of power/cell related packages have you got time to continue that or would you like the PS3 Port Team
<munckfish> to take over responsibility for those
<munckfish> ?
<munckfish> The list I've compiled so far is here: https://wiki.ubuntu.com/UbuntuPS3/Packages
<munckfish> could you let me know if there are any I've missed?
<munckfish> Thanks
<doko> munckfish: these packages are obsolete in intrepid; if you do want to take care of those in hardy, that would be fine
<munckfish> obsolete?
<munckfish> in what way?
<munckfish> can everything they achieve be achieved using something else now?
<emgent> norsetto: o/
<norsetto> emgent: 0/
<munckfish> doko: in what way are they obsolete? Can the features they provide be achieved with other packages now?
<doko> munckfish: it's built from gcc-4.3 and binutils, plus we have a newlib package
<arthur-> hi
<munckfish> doko: so what about the spu stuff?
<munckfish> doko: do surely we still need to bag that stuff from the SDK right?
<doko> munckfish: maybe ask arthur- what is planned, but what do you mean by "stuff from the SDK"?
<munckfish> doko: ok. I've not spent much time understanding what is needed in the way of a toolchain for the PS3, cause I've been battling with Xorg and Kernel probs so far
<munckfish> I am aware of IBMs SDK/toolchain for the Cell, I presumed these packages you created related to that
<arthur-> munckfish: binutils-spu + g{cc,++,fortran}-spu + newlib-spu ?
<munckfish> I noticed the upstream URL was Barcelona Supercomputer project
<munckfish> arthur-: yep exactly
<arthur-> doko: since intrepid are the spu packages sync from sid?
<doko> arthur-: yes, merged
<arthur-> cool
<arthur-> munckfish: then what is the problem? something does not work?
<doko> arthur-: we need to build gcc-4.3-spu without the hardening and the ssp-as-default patches. so either we have to copy the src dir for the build (and unapply these patches), or build from a separate source
<munckfish> arthur-: 2 things - first there is a bug raised about ppu-gcc not being able to compile the kernel. Second now my attention has turned to these packages I am about to find out if they need to be updated to a new upstream version
<munckfish> arthur-: LP 180319
<ubottu> Launchpad bug 180319 in cell-gcc "ipc/compat.c:468: internal compiler error: in copyprop_hardreg_forward_1, at regrename.c:1592" [Undecided,Confirmed] https://launchpad.net/bugs/180319
<munckfish> arthur-: also this is how far I got finding out about these packages https://wiki.ubuntu.com/UbuntuPS3/Packages
<arthur-> munckfish: there is no ppu support in debian sid, and for spu it has been merged in main gcc-4.3 and binutils packages
<arthur-> I don't think ppu is upstream as spu, have to check
<arthur-> munckfish: are you sure you need ppu at all for the kernel?
<ogra> wow, lots of new abbreviations floating around here today :)
<doko> munckfish: ppu is just an alias
<_lemsx1_> why was the security update for openssl (0.9.8g-4ubuntu3.1) uploaded with "urgency=low" and now "high"?
<_lemsx1_> s/now/not/g
<_lemsx1_> the same fix on the debian package is set to "high" (as I think it should)
<james_w> urgency has no meaning in Ubuntu so it makes no difference.
<arthur-> doko: there is no possibility to update the patch to have no effect for spu targets?
<_lemsx1_> james_w: ok
<doko> arthur-: it will get more ugly
<munckfish> arthur-: no I know I can compile for the ppu from PS3 using normal gcc. I didn't know if it was needed for cross-compiling to ppu from other platforms.
<arthur-> doko: shouldn't we build spu packages on i386 and amd64 as well and remove old cell-* packages?
<arthur-> (once fixed for gcc-4.3)
<doko> arthur-: sure, the old cell packages should be removed in intrepid once the other packages are working. if you do want to provide the cross toolchain, then it would make more sense to build that from separate source, b-d on gcc-4.3-source. at least that's what we want for the other cross builds as well
<munckfish> doko: what's "b-d"?
<doko> build-depend
<munckfish> ok
<munckfish> arthur-, doko: ok so am I understanding this correct - PPU is just a powerpc arch so to cross-build for that just need to pass -mppc or similar right?
<munckfish> but, for spe we need to have a patch in gcc or a special build of gcc?
<munckfish> so we don't need IBM's sdk nor the one from Barcelona Uni, we just need the patch they contributed upstream in order to compile for SPEs?
<doko> munckfish: you need two compilers, the native for the ppu (just a normal recent gcc), and a cross build targeting the spu units
<munckfish> Ok, that's what I now understand.
<munckfish> Therefore to move forward from here - normal gcc is fine
<munckfish> we just need to create a cross build for spe
<munckfish> what about the ppu-sysroot thing with all the cross libs we still need that right?
<munckfish> for linking
<munckfish> I am prepared to do whatever work is necessary here.
<munckfish> I am not afraid to learn knew things quickly. But I am not a core/motu would you guys be able to offer some sponsorship for uploads etc?
<munckfish> arthur-, doko ^ ?
<arthur-> munckfish: I'm not a core/motu
<munckfish> ok, so I am in similar company :)
<doko> munckfish: the spu cross build is already there (install an intrepid chroot), the ppu-sysroot is not needed, unless you want to have cross build dev environment
<munckfish> ok fine
<doko> arthur-, munckfish: time to become one
<doko> dholbach: new victims ^^^ ;-p
<munckfish> doko: would love to
<dholbach> :-)
<arthur-> doko: me?
<doko> arthur-: why not?
<munckfish> I know there is a process for that - just hadn't bothered to read it yet cause I was concerned to get actual stuff happening. c - j - watson and the xorg team have been sponsoring uploads for me so far
<doko> munckfish: it may be a good time at the beginning of the release cycle
<munckfish> doko: ok I'll look into it
<munckfish> th
<munckfish> thx
<arthur-> doko: I will be able to do toolchain uploads in Ubuntu then?
<doko> arthur-: when build from separate sources, yes, but first you have to become a motu
 * Seeker`` would like to do motu stuff at some point
<juliank> Keybuk: Update on Bug #228226?
<ubottu> Launchpad bug 228226 in readahead-list "Please merge readahead-list 1:1.20060421.1016-3 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/228226
<Keybuk> juliank: your quoting of policy doesn't actually answer your question ;)
<Keybuk> well, doesn't absolve you from making an unnecessary change
<desrt> Keybuk; the change was necessary!  it was causing valgrind warnings!
<Keybuk> desrt: this isn't #debian-devel ?
<desrt> Keybuk; what?  where am i?
 * desrt rubs his eyes
<juliank> Keybuk: The question was why it was changed. You said 'so S01mountkernfs.sh will always be run before S01readahead.' - the answer is: "The two-digit number mm is used to determine the order in which to run the scripts" - therefore it has to be S02 and not S01, as it needs a script from S01
<Keybuk> juliank: no
<Keybuk> policy doesn't say ONLY the two-digit number
<Keybuk> it just says that the two digit number is used (along with other things)
<juliank> Keybuk: OK, it was the wrong reason. The real reason is that debians mountkernfs is S02 (there is only S01glibc.sh in Debian)
<juliank> Keybuk: Ubuntu does not need this change, but I see no reason why it could not be merged.
<Keybuk> because it would change our boot order
<juliank> Keybuk: The only other script in S02 is hostname.sh
<Keybuk> which will also run before it
<Keybuk> you're not going to justify to me any change to the boot ordering ;)
<Keybuk> it's a deliberate different in Ubuntu
<Keybuk> it should not be dropped
<CarlFK> cjwatson: just hit #22301 with hardy - want to look at my box before i do the workaround?
<CarlFK> bug ï»¿#22301 "Install -- Raid setup cannot see all of my RAID partitions"
<CarlFK> Bug #22301
<ubottu> Launchpad bug 22301 in partman-md "Install -- Raid setup cannot see all of my RAID partitions" [Medium,Confirmed] https://launchpad.net/bugs/22301
<Mirv> cjwatson: bug 144741 is btw waiting for input on who should do what to get the new partitioning strings into Rosetta for translation. those that were supposed to be translated for 8.04.1.
<ubottu> Launchpad bug 144741 in ubiquity "Untranslated strings in manual partitioning window" [Medium,Fix released] https://launchpad.net/bugs/144741
<Keybuk> lots of timeouts from LP today
<Keybuk> soren: do you know much about openvz?
<\sh> doko: if you can remember your changes to ruby1.9 ... do we need them still in 1.9.0.1
<\sh> ?
<juliank> Switching to aufs as the default filesystem to workaround the disabled unionfs?
<soren> Keybuk: Not really.
<soren> Keybuk: I know that upstream handles the kernel side of things themselves (mostly). I don't know if that's a useful for you in any way?
<Keybuk> we build -openvz kernels
<Keybuk> from our git tree
<soren> Yes.
<soren> Based on a patch from them.
<Keybuk> which would be nice, if they didn't cause an assertion error in Upstart ;)
<soren> Ah.
<soren> What's the problem?
<Keybuk> openvz for no readily apparent reason change the behaviour of mmap() for zero length files
<soren> Keybuk: That's.. unfortunate.
<soren> I can't imagine why.
<Keybuk> and since vi tends to make zero length swap files while you're editing jobs, you end up with no system l;)
<soren> Erk..
<Keybuk> the upstream kernel changes the behaviour of mmap() quite a while back
<Keybuk> to match POSIX
<Keybuk> I can't imagine why openvz have to revert that change for compatibility when the ordinary kernel doesn't
<soren> Keybuk: Nor can I.
<soren> Keybuk: BenC is the one who's been in contact with the OpenVZ guys. I've not really been involved at all.
<Keybuk> yes, well, getting in touch with the kernel team is sometimes like talking to god
<Keybuk> you're on your knees, chatting away, but no evidence of anyone on the other end :p
<soren> :)
<soren> Is it urgent right now?
<Keybuk> sorry, that was harsh
<Keybuk> religious people do have sometimes compelling arguments for god's existance
<soren> I think I have the e-mail for the OpenVZ contact somewhere, but I'm a bit tied up right now.
<soren> I've met the kernel team. They exist, too.
<soren> s/, too//
<soren> I have to run for half an hour..
<wasabi> Keybuk: no they don't.
<wasabi> =)
<e-gandalf> asac: ping
<asac> e-gandalf: hi
<e-gandalf> hi asac
<e-gandalf> so, I'll join you from Mon till Wed
<e-gandalf> if you want to use me in relation to any specific Mozilla topic, please let me know
<asac> e-gandalf: cool.
<e-gandalf> my email is zbraniecki@mozilla.com
<e-gandalf> in particular, I'm working on a series of localization related tools, and would love to meet launchpad people :)
<asac> ill write something up and search for you on monday. thanks!
<e-gandalf> sure
<cr3> how can I determine a release is LTS programmatically? dapper use to display "LTS" in the output of lsb_release -a, but not hardy
<[reed]> e-gandalf: #ubuntu-mozillateam
<sdh_> http://metasploit.com/users/hdm/tools/debian-openssl/
<slangasek> sdh: you're aware that Linux pid_t is an 'int', which is a 32-bit type rather than a 16-bit type?
<sdh> slangasek: i can read typedefs, yes
<slangasek> sdh: oh; I gather you're not actually the author of that page?
<sdh> slangasek: i am not HD Moore, no
<slangasek> ok then :)
<sdh> slangasek: :P
<sdh> slangasek: afaik, there is somewhere a "max procid" which effectively makes it 16 bits
<sdh> a cursory grep hasn't shown me where
<sdh> slangasek: similarly, even though it's a (signed) int, process ids are positive
<sdh> etc...
<sdh> but like i say, i am just a messenger :)
<lucas> kernel.pid_max = 32768 is probably what you are looking for
<sdh> thanks :)
<sdh> a sysctl, i assume?
<lucas> yes
<sdh> thanks
<slangasek> right, I'm well aware of the actual limitations, I just supposed I might've been talking to the author of that page and might be able to send him on a wild goose chase for a bit ;)
<sdh> ;>
<lucas> ah :)
<cjwatson> Mirv: jtv is the man who can sort that out, I think
<theunixgeek> ï»¿please, ubuntu devs, fix the copypaste bug!!! :(
<ion_> Launchpad ID?
<theunixgeek> what?
<Nafallo> copypaste?
<ogra> Nafallo, !!!!
<ogra> Nafallo, just saw the news today
<theunixgeek> Nafallo: yes
 * ogra hugs Nafallo 
<Nafallo> ogra: thanks :-)
<ion_> news?
<theunixgeek> Nafallo: in fedora, mac os x, and windows *, you can copy, close an app, and then paste elsewhere. not in ubuntu.
<Nafallo> theunixgeek: let me try that.
<Nafallo> nafallo@wizard:~$ test
<Nafallo> theunixgeek: I can :-)
<Seeker`> pasting works for me
<theunixgeek> :S
<theunixgeek> weird
<theunixgeek> like, type something in gedit, close, and paste in firefox
<theunixgeek> default install
<Seeker`> I just typed "pasting works for me" in gedit, closed it, and pasted it in here
<theunixgeek> weird
<theunixgeek> I'll be back in 1/2 hour
<theunixgeek> bye
<bryce> ogasawara_: bug #228399 turns out to be a kernel panic.  Not sure it's triaged correctly for kernel stuff though - you might want to take a look
<ubottu> Launchpad bug 228399 in xserver-xorg-video-intel "Closing lid results in kernel panic" [Undecided,Invalid] https://launchpad.net/bugs/228399
<bryce> ogasawara_: the user's situation is a bit crackful - he restored a full system backup onto different hardware.  So don't know how viable it is for solving, but I'll let you judge.
#ubuntu-devel 2008-05-15
<jdong> bryce: sounds reasonable to me (shut up, wgrant and Hobbsee :P)... it's not like the installer writes any stateful info about the hardware
<wgrant> !jdong
<ubottu> <Hobbsee> jdong: yes, but you're FULL OF CRACK!
<Nafallo> hehe
<Nafallo> that's almost harsh :-P
<macd> Has anyone had troubles with sshd after upgrade, newly generated keys from updated ssh/ssl gives errors when trying to auth via key on ssh, http://pastie.caboo.se/197206
<slangasek> macd: I haven't seen this.  What version of Ubuntu are you running?
<macd> in this case, my workstation is 8.04, 2 sshd's 7.10/8.04 both doing it
<macd> I've tried removing/purging ssh things, and then deleteing all my keys, reinstalling ssh stuff, then regenerating my keys, still no go
<macd> slangasek, ^ above (sorry forgot to prefix)
<sdh> "If it works, edit the .ssh/authorized_keys file from your home directory. You will probably notice that you have a new line or an unappropriate character in your file. Each key on this file must be on one line only."
<sdh> (from http://www.webprodevelopment.com/BrightLight/2006/01/09/fixing-a-sshd-error/)
<slangasek> macd: does ssh -v give you any more useful information on the client side?
<macd> sdh, thanks for the suggestion, but I figured that one out a long time ago ;P
<sdh> macd: oh well :P
<macd> slangasek, OpenSSH_4.7p1 Debian-8ubuntu1.2, OpenSSL 0.9.8g 19 Oct 2007 client/ OpenSSH_4.3p2 Debian-8ubuntu1.4, OpenSSL 0.9.8c 05 Sep 2006 server
<macd> ohh, haha, not versions, verbosity
<macd> slangasek, http://pastie.caboo.se/197224
<slangasek> macd: hmm, ok
<slangasek> will try to reproduce here
<macd> sure thing, need any other output, or a bug on LP opened
<slangasek> I suggest going ahead with opening a bug on LP regardless
<macd> slangasek, I just tried using the key on my workstation to ssh to a bsd box, works fine....
<slangasek> macd: and there's no doubt that the key you're using is newly-generated using a non-vulnerable version of openssh?
<macd> slangasek, no doubt at all
<macd> slangasek, Im a bit short on time at the moment, but I'll file a bug and subscribe you to it, whats your LP
<slangasek> macd: 'vorlon'
<macd> seen that one a few times, reminds me of babyln5
<macd> slangasek, thanks, and take it easy
<pitti> Good morning
<dholbach> good morning
<dholbach> did somebody ever encounter thunderbird not listing a mail folder (main view, filter view) even if it shows it as "subscribed to"? any advice?
<dholbach> hum, it works after clicking and unclicking "show only subscribed folders" - nevermind
<cjwatson> macd: I'm going to need output from 'sshd -ddd' on the server side to diagnose that bug. That is, you have to run 'sudo /etc/init.d/ssh stop', then bring up sshd in debugging mode with 'sudo /usr/sbin/sshd -ddd' (yes, you need the full path there), connect to it once, then 'sudo /etc/init.d/ssh start'
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<fabbione> hi guys
<fabbione> you guys at UDS yet?
<tkamppeter> pitti, I will be in Prag from Saturady on, with my wife and her parents, Sunday evening I move into the conference hotel.
<tkamppeter> pitti, are you already in Prag?
<pitti> fabbione: not yet, this evening
<pitti> tkamppeter: ^
<fabbione> pitti: ok :)
<tkamppeter> pitti, so you will visit Prag at first, too?
<pitti> tkamppeter: no, only on Sunday; FOSSCamp will happen on Friday/Saturday
<tkamppeter> I have prepared two blueprints: https://blueprints.launchpad.net/ubuntu/+spec/pdf-as-standard-print-job-format and https://blueprints.edge.launchpad.net/ubuntu/+spec/applications-printing
<tkamppeter> ubotu, tell something about the blueprints ...
<tkamppeter> I would like to get some desktop application developers onto these BoFs, who should I subscribe?
<pitti> tkamppeter: did you propose it for the conf already?
<tkamppeter> pitti, yes, by "Propose for meeting agenda" in the menu on the left.
<pitti> ok
<tkamppeter> pitti, https://blueprints.edge.launchpad.net/ubuntu/+spec/applications-printing was not reported by me, but I would change the title, is there a way to do this?
<pitti> tkamppeter: the title yes, but not the ID (IIRC)
<tkamppeter> "Edit title and summary" appears only for the blueprints I have reported by myself. Is this a bug in PL?
<tkamppeter> s/PL/LP/
<pitti> ah, that might be a precaution against vandalism
<tkamppeter> pitti, you are probably root on the server and can vi it to "Common Printing Dialog".
<pitti> heh, no, I'm not :)
<tkamppeter> pitti, but you are core-dev
<pitti> I still can't change it, though
<pwnguin> is there a calendar of UDS yet?
<[reed]> is there a channel for UDS?
<cjwatson> tkamppeter: an extraordinarily small number of people have root on the Launchpad database server, and vi doesn't work well on postgresql databases
<cjwatson> tkamppeter: I've changed the title for you
<cjwatson> (members of ubuntu-drivers can do that)
<tkamppeter> cjwatson, thank you very much. The old title was really franglish.
<Mithrandir> cjwatson: would it make sense to make it possible to disable DSA auth completely (sshd)?
<cjwatson> yes, somebody filed a Debian bug report for that
<pitti> Riddell, Hobbsee: can you please ask for appropriate automounting debugging procuedures in bug 205081? It works under Gnome, and I don't know the debugging for KDE
<ubottu> Launchpad bug 205081 in ntfs-3g "ntfs-3g will mount as root only, breaks mounting as user" [Undecided,In progress] https://launchpad.net/bugs/205081
<emgent> morning
<emgent> dholbach: heya, some problem with iproute sync and nis merge?
<emgent> norsetto: o/
<norsetto> emgent: <>/
<Hobbsee> pitti: i don't use kde, sorry
<pitti> argh, where the heck do I find AM_CHECK_PYTHON_HEADERS ?
<pitti> autoreconf stumbles over this, and it's not at all obvious where to find it
<pitti> doko: ^ any idea?
<pitti> (trying to fix the b0rked python-gobject merge)
<pochu> ah
<pochu> pitti: I was looking at it
<pitti> I so much hate, hate, hate, hate autoconf
<pochu> pitti: I've asked seb and that patch isn't needed anymore, we can change it with the last one from http://bugzilla.gnome.org/show_bug.cgi?id=481569 which fixes the bug instead of disabling the feature
<ubottu> Gnome bug 481569 in gtk "Calling gobject.threads_init() causes a lot of wakeups" [Normal,Reopened]
<pitti> pochu: oh, cool, so we can drop this 61_dont_use_setwakeupfd.patch?
<pochu> yes
<pitti> pochu: that would be good, since its purpose is undocumented, no bug#, etc.
<pitti> rocking
<pochu> and the autoreconf issues would be http://bugzilla.gnome.org/show_bug.cgi?id=471528, http://bugzilla.gnome.org/show_bug.cgi?id=471559, and probably others
<ubottu> Gnome bug 471528 in general "m4 macros needed to rebuild configure aren't shipped with 2.13.x" [Minor,Unconfirmed]
<pitti> ah, thanks
<pitti> pochu: well, with dropping the patch I don't need to rebuild them any more
<pochu> exactly :-)
<pochu> I wonder how Joss got to rebuild it, though...
<lool> pitti: BTW, I think I discussed it with you and seb128 to include the updated python-gobject patch in hardy-updates
<lool> pitti: You're still ok with this?
<pitti> lool: I don't think I was involved in that discussion
<lool> Ok; well basically that wakeupfd stuff was broken in pygobject and we disabled it before hardy
<pitti> right, that's the patch I just ripped out for intrepid
<lool> But it causes wakeups in powertop for python apps such as deskbar applet
<pitti> python-gobject uploaded now, for the record, it actually builds now; this should unbreak the world FTBFSing
<lool> But you pulled the updated wakeupfd patch?
<pochu> cool
<pochu> hey lool
<pitti> lool: no, I just dropped it, as pochu said
<lool> I don't think it was tarball released
<pitti> lool: we can still apply it in a followup upload if we need
<pitti> but I'd really like to get this fixed in intrepid soon, it causes a hell of a lot of FTBFS and uninstallability ATM
<pitti> (that's why I attacked it now in the first place)
<lool> Ok, I thought we had a patch for this support but actually it was tarball releasedin the old broken version in 2.14;1
<lool> What we want is the final implementation
<pochu> pitti: could you retry exaile libbeagle anjuta (or add to your to-retry list :)
<lool> pitti: So you uploaded ubuntu3?
<pitti> lool: 2.14.1-4+ubu1, yes
<pitti> (no remaining changes any more
<pitti> pochu: kicked
<pochu> thank you
<mitsuhiko> hi all
<mitsuhiko> why is ssh-vulnkey not available for dapper?
<pitti> mitsuhiko: it will eventually
<mitsuhiko> that's good news
<pitti> pochu: btw, feel free to upload bug 208097
<ubottu> Launchpad bug 208097 in python-aptsources "FTBFS in Hardy due to python-distutils-extra changes" [Medium,Fix released] https://launchpad.net/bugs/208097
<pitti> pochu: and maybe poke someone from ~motu-sru to ack it (Hobbsee, TheMuso, etc.)
<pochu> ok, on it
<pochu> What do people think about removing reportbug(-ng) from the archive? bug 175508
<ubottu> Launchpad bug 175508 in reportbug-ng "reportbug-ng reports bugs to Debian instead of Ubuntu" [High,Triaged] https://launchpad.net/bugs/175508
<LimCore> hi cjwatson
<LimCore> cjwatson: can we append a warning to the installer related to openssh,  that explains that the SERVERS that accept weak keys are still vulnerable and that users should consider that?
<LimCore> becuse users dont ralize this usually
<kagou> do anyone have an idea to which package should I assign Bug #230694 ?
<ubottu> Launchpad bug 230694 in ubuntu "DVD mounted and played by wrong user" [Medium,New] https://launchpad.net/bugs/230694
<lool> pitti: Hmm if you remove the patch completely, we get the borken setwakeupfd support again
<lool> I'm preparing a Debian upload with the updated fix
<lool> doko: Hmm will we get signal.set_wakeup_fd from 2.5.2-2ubuntu2 in Debian too?
<pitti> lool: thanks
<siretart> any reason to not publish openssl-blacklist in dapper-security?
<lool> Blah, I hang python2.5 when rebuilding pygobject in hardy
<lool> lalala .........*** glibc detected *** /usr/bin/python2.5: malloc(): memory corruption: 0x0000000000a39480 ***
<lool> Looks like it could be amd64-ish
<lool> doko: pygobject was uploaded the 9th of April in hardy and python2.5 the 8th and the 16th; I wonder whether it could be a 2.5.2-2ubuntu4 regression
<mvirkkil> What time does FOSSCamp start tomorrow?
<pitti> mvirkkil: 10 am, IIRC
<Hobbsee> argh.
<Hobbsee> 18 / 3 != 9
<Hobbsee> did someone steal my brain?
<pitti> Hobbsee: 5.99999993843 last time I checked :)
<Hobbsee> :P
 * realist gives back hobbsee-brain.deb
<realist> pitti: FPU bug?
<lool> doko: There's an insane amount of valgrind errors (even when only looking at access after free errors); I guess it's a wrong memory allocation function being used: do you have any tip on chasing such issues?
<mvirkkil> pitti: Thanks. Couldn't find it anywhere on the FOSSCamp page.
<Hobbsee> realist: ah, thanks.
<juliank> doko: I really need Bug #220241 to be fixed. Running applets is (if it works) slow and the applet at java.com does not even work. (but worked with IcedTea 7 in gutsy)
<ubottu> Launchpad bug 220241 in icedtea-gcjwebplugin "Test applet at java.com fails to run" [Undecided,New] https://launchpad.net/bugs/220241
<emgent> heya people
<juliank> doko: Somehow it works now. But why?
<candrews> Question about the openssl vulnerability: why does openssl not use /dev/urandom for entropy on Linux? Why does it need anything other than /dev/urandom?
<pochu> pitti: can you retry them again? when you did it python-gtk2 was still uninstallable due to python-gobject, but I've checked now on a chroot and they are installable with the update
<pochu> exaile libbeagle anjuta
<pitti> pochu: right, doing
<pitti> done
<pochu> thanks again :)
* mdz changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | 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 | #ubuntu-devel-summit for U
* mdz changed the topic of #ubuntu-devel to: Regenerate your SSH keys! http://www.ubuntu.com/usn/usn-612-2 | 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
<mdz> ETOPICFULL
<\sh> ./ctcp * sound attention_regen_ssh-keys_now.wav
<emgent> :D
<Hobbsee> fricking oo.
<Hobbsee> stop crashing!
<doko> lool: is this needed?
<lool> doko: Well the valgrind backtraces don't end up in the python modules I'm testing
<lool> doko: http://people.ubuntu.com/~lool/pygtk-testactionsubclass.log
<lool> doko: I guess these issues weren't present in the previous python2.5 as pygtk built against it for hardy
<lool> doko: The tests causing glibc assertions are doing some gc.collect() and the changes you did to python2.5 seem to affect the gc; are these patches safe, could they expose bugs in other moduels?
<doko> lool: which tests fail, are these tests using ctypes?
<lool> doko: I'm not sure; there's "ctypes" usage in codegen/defsgen.py, but I don't see any in generated code
<doko> hmm
<lool> doko: If you simply rebuild pygtk locally, you should get the bug
<doko> lool: I already had the wakeup stuff backported, just didn't upload
<lool> doko: Oh, well I spent time today doing it too; too bad
<lool> doko: I committed the patches to the Debian tree, but I can't test them under hardy due to this unrelated FTBFS
<doko> Apr 30 ...
<lool> ?
<lool> You mean you had prepared pygobject and pygtk back Apr 30?
<lool> Or do you mean you told me so at that date?
<doko> do python2.5
<lool> You included it in hardy already
<lool> I don't understand what you say
<mrec> hi it seems like that mplayer fires up dbus to open and hold the video nodes open .. this has a terrible sideeffect for hybrid devices which provide multiple nodes. When the analog video node is held open it's impossible to open eg the DVB or radio part of a analog TV/dvb/radio device
<mrec> the dbus extension seems to be an ubuntu specific patch
<mrec> (at least for mplayer)
<doko> <lool> doko: Hmm will we get signal.set_wakeup_fd from 2.5.2-2ubuntu2 in Debian too?
<doko> this was my answer
<pecisk> hi people, how firefox translation from Launchpad gets into distribution? It is converted when issuing update for particular translation?
<mrec> http://ubuntuforums.org/showthread.php?t=652941
<mrec> does anyone know more about this?
<mrec> I don't think it's mplayer mplayer accesses dbus yes but only for the screensaver thing
<needbeer> http://www.dasdeutschlandspiel.de/index.php?page=beg.php&id=4410
<needbeer> http://www.dasdeutschlandspiel.de/index.php?page=beg.php&id=4410
<violinappren> hi all, i'm trying build the source package of synergy and i get "/usr/bin/fakeroot: 166: debian/rules: Permission denied" ... more at http://pastebin.ubuntu.com/12261/
<stdin> violinappren: is debian/rules set executable?
<liw> violinappren, "chmod +x debian/rules" should fix that; when apt-get unpacks the source code, it shoudl do that, I don't know why it didn't
<liw> more specifically, dpkg-source should do it
<liw> maybe the clean rule in debian/rules does something funny
<violinappren> i did chmod +x on it and then ran "dpkg-buildpackage -rfakeroot -uc -b" and it still gives the same error .. "ls -al debian/rules" says it's -rwxr-xr-x
<needbeer> http://www.dasdeutschlandspiel.de/index.php?page=beg.php&id=4410
<stdin> needbeer: stop spamming
<liw> violinappren, I can't reproduce the problem on hardy
<needbeer> i already got 7 klines today on several networks, only a shotgun could stop me spamming :D
<stdin> needbeer: ask an you shell receive
<liw> violinappren, I can't reproduce the problem on hardy
<liw> violinappren, do you have all build dependencies installed? "apt-get build-dep synergy" takes care of that
<violinappren_> umm, i tried again in my home directory (rather than my "playground" partition) and it works (!)
<stdin> violinappren_: same filesystem type?
<violinappren_> yes i used ext3 allover the place
<stdin> check the mount options, there is a noexec flag that cam be set iirc
<violinappren_> mount says "/dev/sda3 on /media/sda3 type ext3 (rw,noexec,nosuid,nodev)"
<liw> a-ha!
<stdin> there you go then "noexec" will stop things from being executed even if set +x
<violinappren_> aaaah
<Ng> noexec is overrated
<violinappren_> it must be a default in hardy since i never manaually set it!
<stdin> check in your /etc/fstab
<liw> it is set for automatically mounted volumes (ref. /media)
<liw> by gnome-mount, that is
<violinappren_> fstab has "/dev/sda3 /media/sda3 auto nouser,atime,auto,rw,nodev,noexec,nosuid 0 0"
<violinappren_> (i added the mount points during a clean kubuntu hardy install)
<stdin> unmount, take out the "noexec," and mount
<liw> or don't build packages on that filesystem, of course -- the noexec might be there for a reason
<lool> doko: Ok; are you interested in looking in the python2.5 memory corruption issue?
<liw> (i.e., first figure out the reason)
<doko> lool: please recheck with the recent python2.5 upload first, I'm travelling tomorrow, and I'm offline now
<violinappren_> well it's a personal machine, not a work one, so no "policies" with noexec
<lool> doko: the intrepid one?
<lool> Or the hardy one?
<doko> lool: intrepid, hardy should be ok for ctypes
<doko> lool: you do use hardy-proposed, do you?
<lool> doko: No, I don't; I've seen an upload from you in proposed, but it seemed unrelated
<lool> doko: I'm pulling python2.5{,-dev,-minimal} from proposed
<violinappren_> anyway, thanks guys/gals for your help
<lool> doko: Same bug
<lool> *** glibc detected *** python: free(): invalid next size (fast): 0x0000000000b297b0 ***
<lool> I'm debootstrapping intrepid, but I don't have much hope
<lool> doko: Under intrepid, same thing http://paste.ubuntu.com/12270/
<lool> Well hardy's kernel
<norsetto> looks like debian new is chocked
<lool> norsetto: ?
<norsetto> lool: is it normal for so many packages to be sitting there for weeks?
<lool> Yes
<lool> norsetto: these are old graphes, but it's still being processed in batch http://heracles.corsac.net/~corsac/debian/new/
<norsetto> lool: amazing
<macd> cjwatson, ping
<emgent> norsetto: o/
<fbond> Hi, there seems to be some confusion regarding xorg.conf in 8.04.  Is it possible to force X.org to use a particular display driver, even if auto-detection suggests otherwise?  What is the best way to do this?
<slangasek> fbond: all the previously supported xorg.conf options can still be used, to their usual effect; we just don't use them by default because autodetection now gives correct results in the vast majority of cases
<fbond> slangasek: Am I incorrect, then, in thinking that I ought to be able to add a `Driver ...' line to the "Device" section and have that force the display driver?
<tjaalton> fbond: correct
<fbond> Of course you know that I'm asking because it's not working for me.
<fbond> The log file indicates that the vesa driver is being used.
<fbond> If the requested driver does not load, will the vesa driver be used instead?
<tjaalton> if the xserver fails to start, yes
<fbond> Hm.  It seems to do this silently; no warnings or anything.  Makes debugging a bit confusing if you come from the Old Way where the server doesn't start at all when the driver didn't pan out.
<tjaalton> there's a bug about that
<fbond> Oh, is there?  I couldn't find anything, and wasn't sure if I just didn't understand X.org anymore.
<fbond> tjaalton: Do you have a bug #?
<tjaalton> bug 148122 seems to be the one
<ubottu> Launchpad bug 148122 in xorg "bulletproof-x hiding real problems" [Wishlist,Triaged] https://launchpad.net/bugs/148122
<tjaalton> boarding time, finally ->
<fbond> tjaalton: No, this is a different situation.  I'm not getting the graphical configuration utility at all.  X starts normally, just with the wrong driver.
<tseliot> ï»¿fbond: that's because no driver is specified in the Device section of your xorg.conf
<tseliot> ï»¿ï»¿fbond: maybe Xorg's automatic detection didn't work as it should
<fbond> tseliot: I *did* specify a driver.  That's why I'm bothered.
<tseliot> ï»¿fbond: can I see your xorg.conf and your /var/log/Xorg.0.log (use pastebin, please)?
<fbond> tseliot: one sec.
<tseliot> ï»¿fbond: oh and I would be glad if you could post the output of this command too sudo updatedb && locate xorg.conf
<fbond> tseliot: I think I see what's going on that is confusing me.
<fbond> The machine in question was already being tested by someone else.
<fbond> When I got to it, he had already seen the "low-graphics mode" dialog.
<fbond> I edited the xorg.conf and then restarted the X server by pressing Ctl-Alt-Bkspc
<fbond> However, it seems that restarting the bulletproof X server via C-A-B does not cause the configuration to be re-read.  I'm beginning to understand that the bulletproof X server is a separate server with a separate configuration.
<fbond> Thus, it appeared that my configuration wasn't being read.
<fbond> Does this sound right?
<fbond> Now, I was eventually able to get to a log file with the openchrome output, and found the problem there.  I had to restart gdm to trigger the configuration to be re-read.
<tseliot> ï»¿fbond: yes, that's what I was going to suggest
<fbond> I wonder if some more documentation might be helpful to advanced users trying to fiddle with things.
<tseliot> fbond: bryce knows more about this
<tseliot> and you can have a look at this page: https://wiki.ubuntu.com/X
<tseliot> I've got to go now. Bye
<fbond> tseliot: thanks
<dmb> is this openssl bug going to require the creating of Ubuntu 8.04.1 lts?
<liw> 8.04.1 was going to be created anyway
<geser> pitti: Hi, I've seen that apache2 got uploaded to hardy-proposed. As apache2-mpm-itk has a very strict dependency on apache2.2-common it needs a rebuild for every apache2 upload. Does this somehow influence the SRU of apache2?
 * slangasek shakes his fist at itk
<slangasek> geser: would be great if someone could prepare an itk upload then; I'll be happy to push it through alongside apache2
<geser> slangasek: would this weekend be early enough?
<slangasek> geser: I imagine so
<emgent> heya
<emgent> heya sabdfl :)
<sabdfl> howdy all
<ion_> Hi
<Kaleo> hi sabdfl
<Nafallo> hey :-)
<emgent> Nafallo: :)
<johanbr> Hmm. The UDS wiki page still says "More details about remote participation will be announced closer to the time. ".
<stgraber> johanbr: they have till Monday :)
<xivulon> slangasek, would you mind clarify the first bullet in #226622? I am not too knowledgeable on versioning conventions
#ubuntu-devel 2008-05-16
 * hwilde needs help with ssh port forwarding unsolved mystery if anybody has the curiousity gene
<slangasek> xivulon: bug #226622> you can't have two packages uploaded with the same version number; 1.7 is already in intrepid, the hardy-proposed upload needs to have a different version number
<ubottu> Launchpad bug 226622 in initramfs-tools "Wubi has unclear error message on NTFS dirty flag" [Medium,Confirmed] https://launchpad.net/bugs/226622
<slangasek> xivulon: the practical reason for this is that you can only have one binary package with a given filename in the package pool, and the filenames are already taken by the intrepid uploads, which are built in a different environment
<twb> What's the primary HTTP URL for the ISOs?  (I know not to use it, I just want to put it in a comment.)
<twb> I'd work it out myself but neither the "enhanced" download page nor the mirror list seem to cite the authoritative URL
<twb> Oh, here we go: http://releases.ubuntu.com/8.04/
<twb> Hidden under "bittorrent".
<emgent> heya warp10
<warp10> hey emgent
<Mirv> btw, hopefully going to see some of you for the first time at Praha :)
<tjaalton> Mirv: \o/
<pitti> hello
<tseliot> pitti: hi :-)
<pitti> geser: right, so we should do a rebuild for -itk alongside it
<danshearer1> hello all
<soren> o/
<danshearer1> I just chucked some notes together about the session on replication of data across WANS
<danshearer1> http://shearer.org/WANFileReplication
<danshearer1> starting after a short break (thanks for a good OpenLDAP talk, Howard.)
<StevenK> Yay Freenode
<StevenK> Hrm. Has anyone hit up Freenode staff about a mask?
 * pitti looks at https://bugs.edge.launchpad.net/malone/+bug/231023 .. W?T?F?
<ubottu> Launchpad bug 231023 in malone "on status change, show new status in Subject:" [Undecided,New]
<pitti> assertion error in xargs?
<pitti> erm, http://launchpadlibrarian.net/14556419/buildlog_ubuntu-intrepid-i386.at_3.1.10.1ubuntu2_CHROOTWAIT.txt.gz of course
<pitti> infinity: ^ did you ever see that before?
<danshearer1> hey again... having a discussion here about a Japanese project for pre-optimising blocks on an ISO image
<danshearer1> basically treat ISOs as a tape, which makes livecds boot faster:
<danshearer1> http://www.alpha.co.jp/biz/rdg/ac-knoppix/index_en.html
<danshearer1> It's called LCAT
<soren> Can anyone give me a good reason *not* to add --rsyncable to the call to gzip in dpkg-deb?
<broonie> The only problem with --rsyncable is that it makes things a little bigger.
<StevenK> pitti: Ow.
<pitti> soren: might make the alternates overflow again
<soren> ah.
<soren> The man page says that it generally doesn't incur more overhead than about 1%, but I guess that's more than enough to be a problem for the alternates.
<pitti> that would still mean 7 MB
<Hobbsee> StevenK: i hit Ng up about hitting Spads up about a mask.  no idea what happened after that.
<pitti> soren: I'd actually like to see it the other way round, switch the default format to lzma
<pitti> *that* will buy us a lot
<pitti> both for CDs and for users having to download less
<Hobbsee> yeah, they didn't.
<Hobbsee> Spads: any ETA?
<Spads> Hobbsee: only just got the message, sorry.  Been slinging cable all day
<Hobbsee> Spads: ah, fun.
<Hobbsee> oh, i even have an existing mail
<Hobbsee> Spads: mailed.
<mgunes> Hobbsee, you're attending UDS?
<Hobbsee> mgunes: nope.
<Hobbsee> mgunes: was far too inactive - and causing trouble.
<\sh> oh...is there already some mail addr to apply for voip accounts?
<Hobbsee> \sh: doubt it, if htey've been cabling only today
<stgraber> VOIP isn't installed yet here
<stgraber> probably only for UDS, so on Monday
<\sh> Hobbsee, I thought more of workflow :)
<\sh> StevenK, are you working on xmms2 merge? there are some merges which are in need of this new release
 * Hobbsee thought someone else was - a contributor
<Ng> there should be a wiki page before UDS starts with the details for participation
<Ng> registration is usually done via IRC rather than email
<\sh> Hobbsee, xmms2?
<Hobbsee> i thought so
<StevenK> \sh: Someone else already asked me
<\sh> StevenK, well...what was the outcome? you do , or this someone? :)
<StevenK> I don't care.
<StevenK> \sh: Fight it out with him, I don't want to touch xmms2
<\sh> StevenK, name?
<\sh> StevenK, /me neither...but it blocks..if we can find a crazy guy to touch it...much better
<\sh> -EKILLMOM
<\sh> is it possible to rerun mom to recreate correct merged changelogs for intrepid...*darn*
<kirkland> pitti: reminder, please sync ecryptfs-utils 45-1 into intrepid ( http://packages.qa.debian.org/e/ecryptfs-utils/news/20080516T063203Z.html )
<pitti> kirkland: I just did a 'sync all' run, ecryptfs was amongst it
<kirkland> pitti: outstanding, thanks!
 * cody-somerville is in Prague. :)
<nxvl> cody-somerville: have you just arrive?
 * cody-somerville nods.
<nxvl> cody-somerville: are you alredy at the hotel?
<cody-somerville> My hotel, yes.
<cody-somerville> I'm staying at Panorama for two nights and then moving to Towers
<nxvl> oh, you are not staying at the Corintia towers?
<nxvl> oh
<nxvl> ok
<nxvl> but come on and join us at fosscamp
<cody-somerville> I shall. I just need to shower.
<nxvl> been there
<cody-somerville> I've been travelling since yesterday morning.
<nxvl> your trip was longer than mine?
<nxvl> where are you comming from?
<cody-somerville> Canada
<cody-somerville> I went Fredericton, NB, Canada -> Toronto, ON, Canada -
<nxvl> oh ok
<cody-somerville> > Heathrow, London -> Prague
<nxvl> long trip
<cody-somerville> Didn't help that I had to reroute in Toronto
<nxvl> yup
<cody-somerville> They didn't give me enough time to transfer in Heathrow originally so I had to reroute through Air Canada to get there earlier so that I could arrive at a decent time today.
<cody-somerville> And then my last two jumps were initially on standby so I was worried I'd have to sleep in the airport, haha.
<cody-somerville> but overall, not too bad.
<pochu> is it possible to install an encrypted system from the alternate cd using manual partitioning (and not the entire disk) ?
<pitti> pochu: yes, it is; you just set the usage of the partition to 'encryption'
<pitti> pochu: (optionally with LVM, as you prefer)
<pochu> pitti: ah, thank you, found it!
<pitti> pochu: then you'll get another 'virtual' partition which you then configure normally
<emgent> morning
<kees> fta_: hi! asac said you ran into some issues with fortify-source.  what problems did you see?
<fta> kees, multiple crashes in firefox 3 and xul 1.9
<kees> fta: verrry interesting.  do you have the output from it?
<fta> kees, mostly in realpath()
<kees> whoa
<fta> kees, something like this: http://paste.ubuntu.com/12452/
<kees> fta: hah, that looks like a real bug in xulrunner.  :P
<emgent> kees: o/
<fta> kees, i've tried to fix that while i was packaging songbird
<kees> fta: cool.  I doubt it's a security issue, but probably an unnoticed memory corruption.
<fta> kees, but the fixes didn't make sense to me.
<kees> fta: heh.  do you have an example patches?
<fta> kees, http://paste.ubuntu.com/12455/
<fta> kees, this patch fixed at least 2 crashes in realpath but it's weird
<kees> fta: haha.  cute.  yeah, that patch just makes a larger path name.  I'll poke at it.
<fta> kees, i know, that's why it's weird. MAXPATHLEN = 1024 but the path returned by realpath() was no more than 380 bytes
<kees> weird.
<fta> kees, i suspected a bug in libc
<kees> that's certainly possible.
<fta> kees, then i gave up and moved to CPPFLAGS=-U_FORTIFY_SOURCE
<kees> fta: yup.  can you please add details about this exception to the end of the CompilerFlags wiki page?  I want to track any packages that disable flags.
<fta> kees, sure. i want to revisit that eventually. if you're attending uds, maybe we can further discuss that there
<kees> cool, sure.
<kees> (i'll be there)
<sistpoty|work> kees: are you also interested in exceptions for LDFLAGS? (as libxfont1 doesn't work with -Bsymbolic-functions, still trying to track down why though)
<fta> we had to drop -Bsymbolic-functions at some point in xulrunner-1.9 too (in hardy), when mozilla moved libjemalloc from shared to static
<kees> sistpoty|work: I'm personally not, but it's certainly a good thing to track.  since -Bsymbolic-functions is a dpkg default, we might want to add it to that CompilerFlags wiki too
<sistpoty|work> kees: (I've already filed a bug about it against libxfont1, listing my findings so far...) ok, will add it to the wiki page as well (once I'm home, since I don't have my credentials here)
<kees> cool, thanks
<rausb0> what is the reason for ubuntu klogd not reading from /proc/kmsg directly?
<ogra> rausb0, security ... you would have to run the daemon as root
<rausb0> ogra: ah, i see
<_MMA_> ï»¿Would any recent have killed CUPS printing?
<_MMA_> gah. Wrong window
<rausb0> ogra: so only the dd process runs as root and passes the kmsg data to klogd through the named pipe
<ogra> right
<ogra> and the klod daemon runs as user klog
<ogra> *klogd
<rausb0> yeah
<pochu> pitti, cjwatson: d-i has hanged at the same point twice... if I set a partition to encryption, then go to configure encrypted partitions, set the passphrase, and when it comes back to the partitions, if I go to that partition (to modify it) again, it says changes can't be done to a configured encrypted partition. I go back and it hangs. What would be the right package for that bug, d-i?
<evand> pochu: partman-crypto
<pochu> evand: thank you
<evand> you're welcome
<pochu> evand: hmm, it offers two options, "go back" and "continue", continue works, but go back hangs
 * pochu reports it at lp
<evand> pochu: Please add /var/log/partman and /var/log/syslog as attachments
<pochu> evand: how could I do that? I guess if I reboot the logs will be lost... and I don't have ssh access to the installer, do I?
<evand> if you can back up, there's a save install logs option
<evand> from the main menu
<pochu> evand: bug 231100
<ubottu> Launchpad bug 231100 in partman-crypto "Installer hangs when trying to modify a configured encrypted partition" [Undecided,New] https://launchpad.net/bugs/231100
<pochu> evand: looking at that logs option, let's see if I can find it
<pochu> evand: "save debug logs", right?
<evand> correct
<pochu> evand: done
<pochu> it was easier than what I thought :)
<evand> heh, fantastic
<pitti> TheMuso, Hobbsee: can I get your ack on bug 214959? it is the SRU for bug 224599 (which has an impressive 238 dups)
<ubottu> Launchpad bug 214959 in libuser "system-config-samba.py fails to start due to missing /etc/libuser.conf in Hardy" [Medium,In progress] https://launchpad.net/bugs/214959
<ubottu> Launchpad bug 224599 in system-config-samba "system-config-samba.py crashed with SystemError in __init__()" [Medium,Confirmed] https://launchpad.net/bugs/224599
<pitti> TheMuso, Hobbsee, sistpoty|work: is ~moru-sru still actually ack'ing SRUs, or did I miss a change in procedure? I didn't see any acks in bugs recenlty (there are a few pending SRUs for quite a while)
<sistpoty|work> pitti: I guess they should, maybe LaserJock can confirm it? (that motu-sru ack's SRU's)
<sistpoty|work> oh, there he's off again
<sistpoty|work> jdong, imbrandon: ^^
<ScottK> pitti: I've certainly asked them to ack things I'm working on.
<pitti> ok, thanks
<norsetto> sistpoty|work: are you replacing laserjock in motu-sru?
<sistpoty|work> norsetto: no
<pitti> I feel slightly uncomfortable with not waiting for an ack, although for a case like this it would really be unanimous to do it, I guess (trivial and obvious patch, >200 dups)
<norsetto> sistpoty|work: hmmm, I wouldn't mind if you were
<pitti> I think I'll just accept it to -proposed now and take the bullets for it later
<sistpoty|work> norsetto: hm... let's do a call on the ubuntu-motu mailing list, shall we?
<norsetto> sistpoty|work: as long as you volunteer :-)
<sistpoty|work> norsetto: damn, I hoped I could escape with that *g*
<LucidFox> pitti, now that f-spot 0.4.3.1-0ubuntu1 has been uploaded to intrepid, what will happen to bug #226117?
<ubottu> Launchpad bug 226117 in f-spot "Please merge f-spot 0.4.3.1-1 from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/226117
<pitti> LucidFox: that should still happen
<LucidFox> ah
<pitti> LucidFox: I just copied it to be in sync with hardy-updates (SRU policy)
<pitti> LucidFox: merging should still happen
<pochu> evand: I've just installed Ubuntu and hardy-security isn't enabled. Isn't it supposed to be enabled by default?
<seb128> pochu: how did you install? sure security should be enabled
<pochu> seb128: d-i, manual partitioning, ext3, no encryption, 1 partition for / and one for swap in a disk which has winxp installed
<pochu> hardy-updates is enabled though. I'm also surprised -updates is and -security isn't
<seb128> no idea if that's a known issue
<pochu> if d-i is the right package to look for, doesn't look like
<pochu> ah
<pochu> I have "#Line commented out by installer because it failed to verify:"
<pochu> and then the hardy-security lines
<pochu> that's weird
<pochu> I didn't have networking during the installation
<pochu> but it shouldn't matter, as there's just one main security server, isn't there?
<jdavies> pochu: did you install while s.u.c was down?
<seb128> ok, time to call it a day
<pochu> jdavies: I've just installed it, but I didn't have networking during the install
<jdavies> pochu: that might explain it ;-)
<pochu> oh well, but that could leave many users without security support just because they didn't have networking during the installation
<pochu> it didn't disabled hardy or hardy-updates either way :-)
<k0p> hi all.
<k0p> I'm searching for a package mantainer of Ubuntu. Someone around there?
<ScottK> Yes.  What package?  Most Ubuntu packages are team maintained.
<danshearer> OpenSSL as light relief:  http://imgs.xkcd.com/comics/security_holes.png  :-)
<k0p> ScottK, well I'm working on a project. We release a stable release soon. And I make a Ubuntu 8.04 Package for testing. It works fine. But we would like that our package can be in Ubuntu repositories..
<k0p> I would like make a contact to help me with it.
<ScottK> k0p: For 8.04 it is to late.  We are working on 8.10 now.  The best channel for that discussion in #ubuntu-motu.  That's where new packages are handled.
<k0p> ScottK, yeah, I know that is late for 8.04
<k0p> well
<k0p> I make this package for the release we have package for 8.04
<ScottK> If it's in 8.10, then it can (presumably) be backported to 8.04 and be available in hardy-backports.
<k0p> But I intend make a package for new version
<k0p> the next release of ubuntu is out on 10th august, right?
<ScottK> No. In October.  The version is Year.Month
<Laney> k0p: End of October is when 8.10 is released.
<k0p> oh okay. Sorry I don't know about it.
<Pici> (200)8.10
<k0p> thanks a lof by information. I'll to the other channel. Thanks for the suggestion.
<ScottK> k0p: https://wiki.ubuntu.com/IntrepidReleaseSchedule
<k0p> ScottK, thanks.
<k0p> thanks for all. And sorry for something. :)
<ScottK> It's no problem at all.
<fta> kees, I've added cvs to the list of problems (cvs suffers from "%n in writable segment detected")
<sistpoty> fta: oh, I hope I didn't interfere with you editing the wiki (as I just added libxfont1)
<fta> simira, you did, but i managed ;)
<sistpoty> bryce: seems like I found the "bug" for libxfont1 not working with -Bsymbolic-functions...
<gnomefreak> tjaalton: bug 212648 well i have an ATI same symptoms same outcome same website, could this be any drivers installed by envy or is it not related to envy at all?
<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
<bryce> sistpoty: oh?
<sistpoty> bryce: if you look at src/stubs, there are a number of functions defined as weak, which contain only dummy implemenations (and hence are meant to be override by binaries/libraries using them)
<sistpoty> bryce: which matches quite good with the last comment on bug #230460
<ubottu> Launchpad bug 230460 in libxfont "xorg fails to start if linked with -Bsymbolic-functions" [Undecided,Confirmed] https://launchpad.net/bugs/230460
<gnomefreak> ah and i was gonna ask about libxfont1 next week :)
<sistpoty> bryce: so I guess it's not a bug, but rather done by design
<sistpoty> (however I'll leave that for you to decide ;))
<bryce> hmm, ok thanks for the info
<sistpoty> no problem ;)
<tseliot> ï»¿gnomefreak: what's the problem with Envy?
<gnomefreak> tseliot: im not sure if its envy at all
<gnomefreak> tseliot: the bug report is filed against l-r-m-envy
<gnomefreak> its the nvidia crash X bug
<gnomefreak> i found one with ATI im wondering by name of bug now is it envy
<tseliot> ï»¿gnomefreak: it affects the packages which envyng uses since they are based on the lrm
<gnomefreak> other wise im not sure why summary has envy in it
<gnomefreak> so it could be the same bug?
<tseliot> ï»¿gnomefreak: no one has reported the same problem with an ATI card yet (AFAIK)
 * gnomefreak just knew of 8xxx nvidia-new drivers anything lower than 8xxx you wont see it
<gnomefreak> tseliot: i have one
<tseliot> ï»¿gnomefreak: what model?
<gnomefreak> same site same crash without crash report it looks the same but for this you really cant get much of a crash report
<gnomefreak> tseliot: he says its a X600
<gnomefreak> Radeon
<gnomefreak> tseliot: bug 227274
<ubottu> Launchpad bug 227274 in firefox "X session crash when I visit a page with firefox" [Undecided,Triaged] https://launchpad.net/bugs/227274
<gnomefreak> call it a hunch but im 99% sure same bug
<emgent> heya people
<tseliot> gnomefreak: this is weird. The packages which contain the ATI driver do not touch libwfb.so
<tseliot> ï»¿emgent: hi
<gnomefreak> tseliot: that makes me wonder now too but i do know that link doesnt crash FF but crashes X
<emgent> tseliot: o/
<gnomefreak> tseliot: well thats why i asked for the extra info maybe hes using upstream drivers or wrong drivers?
<tseliot> ï»¿gnomefreak: what if there's an upstream bug we're not aware of? Did you have a look at ATI's bugzilla?
<tseliot> ï»¿gnomefreak: the NVIDIA cards which use libwfb are Geforce 8xxx and it's not a coincidence that such cards are affected by that bug while older models are not
<tseliot> ï»¿gnomefre1k: did you get my previous messages?
<tseliot> ï»¿gnomefreak: furthermore (back to the ATI driver) version 8.3 has problems with scrolling in Firefox (which hogs the CPU). This is solved in version 8.4
<gnomefre1k> tseliot: ok is this GFX?
<tseliot> ï»¿gnomefre1k: GFX?
<gnomefre1k> GFX in Firefox causes slow scrolling AFAIK
<gnomefre1k> tseliot: you want this bug?
<gnomefre1k> since its not mozilla related?
<tseliot> ï»¿gnomefre1k: yes, sure
<tseliot> ï»¿gnomefre1k: if the new driver solves the problem then we can close the bugreport
 * sistpoty should have known better, to not report a stupid bug (#231195)
<gnomefreak> tseliot: ok ill assign you to it thanks. i have more mozilla issues than we can handle atm :)
<tseliot> ï»¿gnomefreak: ok then ;)
 * norsetto would like to meet the libmyhello upstream one day ....
<sistpoty> heh
 * sistpoty won't admit, that he is only ~ 250 km away from Prague :P
<kees> cjwatson: what in the world... your upload of openssh-blacklist went into NEW on debian?!
<sistpoty> bryce: sorry, seems like a false alarm to libxfont1... my current tests seem to prove that a weak symbol will still be able to get overridden, even if -Bsymbolic-functions is used
<sistpoty> kees: maybe you have more knowledge on this?
<kees> sistpoty: I don't know about that area, I'm afraid.  perhaps doko has more details?
<bryce> sistpoty: ok
<macd> On gutsy sshd, when a user logs out, its leaving a stale session, is anyone else experiencing this, (only started a after the second sshd update)
<sistpoty> oh, I'm stupid... I forgot to add -Wl, to the gcc call (which will call ld). strange enough gcc doesn't complain
<sistpoty> bryce: ok, weak symbols are affected too, so what I initially wrote is still true ;)
#ubuntu-devel 2008-05-17
<ceekay> I know this isn't strcitly development-related, but it's in the topic and i get no response in #ubuntu so I'll ask here http://www.ubuntu.com/usn/usn-612-1 says that for 7.04 to get libssl0.9.8 version 0.9.8c-4ubuntu0.3 ... however packages.ubuntu.com and my nearest mirror lists 0.9.8c-4ubuntu0.2 as being the latest available... is ...ubuntu0.3 still in the works?
<crimsun> ceekay: no, it's already available.
<ceekay> just a mirror sync thing or something?
<crimsun> ceekay: yes
<crimsun> libssl0.9.8 | 0.9.8c-4ubuntu0.3 | feisty-security | amd64, i386, powerpc
<crimsun> libssl0.9.8 | 0.9.8c-4ubuntu0.3 | feisty-updates | amd64, i386, powerpc
<crimsun> so, you can either pull from archive.ubuntu.com or from security.ubuntu.com
<crimsun> (sorry, I reversed that, respectively)
<crimsun> as long as you have "Important security updates" ticked/checked in the Updates tab of System> Administration> Software Sources, you should be set.
<ceekay> cool thx... just wanted to verify that it was actually available
<ceekay> my repositories are set to a local mirror at work that probably just syncs nightly
<Hobbsee> pitti: i'm no -sru'er....
<lamont`> hrm... how do I tell network mangler to keep doing it's thing even when I'm not logged in, I wonder?
<johanbr> lamont: for versions older than 0.7 I think the answer is "you don't".
<ScottK> lamont: By not logging out AFAIK.
<lamont> I see.
<lamont> does 0.7 play well with hardy, I wonder?
<ScottK> Dunno
<johanbr> Not without tweaking: http://permalink.gmane.org/gmane.linux.network.networkmanager.devel/9654
<andrew_sayers> Should I be filing wishlist bugs when I stumble over things where IPv6 is less well supported than v4?
<andrew_sayers> (e.g. netcat6 not in main, libsocket6-perl not in main)
<pitti> Hobbsee: ah, ok; seems I mixed that up
<pitti> Good morning
<YokoZar> pitti: uh oh
<geser> good morning pitti
<kirkland> pitti: seems my build had a problem, http://launchpadlibrarian.net/14558108/buildlog_ubuntu-intrepid-i386.ecryptfs-utils_45-1_CHROOTWAIT.txt.gz
<geser> kirkland: looks like the buildds are broken right now :(
<pitti> kirkland: that hit me as well yesterday; NFC, unfortunately
<TheMuso> pitti: Ok ACKEd, will process the rest when I'm down stairs.
<pitti> TheMuso: thanks
<Mithrandir> pitti: why does pg_config --libs output lots of stuff like -lz?  They should be pulled in by having libpgport linked to it, should they not?
<pitti> Mithrandir: hm, good point; can you please file a bug about it? (in Debian preferably)
<pitti> Mithrandir: (sorry, EBUSY ATM)
<Mithrandir> pitti: np, and will do
<kirkland> pitti: geser: okay, thanks.  i thought this might be pervasive, but mentioned it just in case
<Keybuk> stupid question of the day:
<Keybuk> I always what terminals to start at 60px across
<Keybuk> how?
<RAOF> s/what/want/?
<StevenK> And 60 pixels?
<Keybuk> RAOF: yes
<andrew_sayers> Not 60 characters?
<RAOF> The Stupidly Configurable window managers will do this; Compiz is one, and I think you'll find the 'window rules' plugin is where you can specify this behaviour.
<Keybuk> RAOF: I can't find a way
<andrew_sayers> Most terminals take a --geometry attribute - the man page for the terminal will tell you more.
<pitti> Keybuk: session management is *supposed* to do that, and it worked just fine until gutsy; too bad that hardy broke it (might be a gnome-terminal bug, though, it works for other apps)
<RAOF> Keybuk: Advanced ... -> Window Rules -> Size rules -> New should allow you to specify that you want your gnome-terminals to be 60px wide.
<Nafallo> Keybuk: devilspie
<pitti> RAOF: I don't seem to be able to find an 'Advanced' thing in g-t; where is it?
<Keybuk> RAOF: not 60px wide, as in not use the left-most 60px of the screen
<Keybuk> Nafallo: doesn't seem to have a rule for "first terminal on an otherwise empty workspace" ?
<Nafallo> Keybuk: ah. only the first one... not every.
<andrew_sayers> Keybuk: I'm a but rusty with my geometry, but I think you want something like --geometry 60x?+0+0
<andrew_sayers> (Where "?" is the height of your screen)
<Keybuk> yeah you can do something like that
<Keybuk> but that's annoying
<pitti> no, rather +60+0
<pitti> + is the offset, AxB the size
 * Ng wonders why keybuk wants that, although the only hack I can think of right now would force all windows on all workspaces to start at +60 ;/
<RAOF> Hm.  You can set the place plugin to manually start terminals at +60+0.
<RAOF> But that's going to start _all_ terminals at the same place.
<Ng> depending on how you arrange your terminals, you could go for a terminal program which keeps them all in one window and just have that window start at +60 :D
<Keybuk> Ng: because with the size of the terminals, I can fit two on the screen
<Keybuk> with 60px either side
<Keybuk> which looks nice and balanced
<Ng> ah
<Ng> are you determined to keep 80x24? I rather like having 4 120x35 terms :)
<RAOF> You could get compiz's put plugin to bind a key to "move this terminal to +60+0"; that's the best I can think of.
<andrew_sayers> Keybuk: you might want to consider using screen, and splitting the screen into regions.
<TheMuso> pitti: Ok I think I have got all of the ones that remained.
<emgent> heya
<Hobbsee> pitti: mp
<Hobbsee> pitti: ping-a-ling
<jdstrand> kees: what do you think of:
<jdstrand> $ sudo ufw limit ssh/tcp
<jdstrand> limit is an 'allow' but with rate limiting
<jdstrand> (I'm still not here)
<jdstrand> s/is an/just like/
<lucas> where's the source code behind http://patches.ubuntu.com/?
<Amaranth> lucas: Someone else runs that. *shrug*
<mvo> lucas: Scott will know
<pitti> TheMuso: thanks for the SRU acks; can you please take a look at bug 175536 as well?
<ubottu> Launchpad bug 175536 in audacious "[Hardy, patch] audacious does not use pulseaudio by default" [High,Fix committed] https://launchpad.net/bugs/175536
<TheMuso> pitti: I'm on it.
<Hobbsee> pitti: tis borken :(
<Hobbsee> pitti: https://launchpad.net/bugs/231236
<ubottu> Launchpad bug 231236 in totem-pl-parser "libtotem-plparser10 Will not install." [Critical,Triaged]
<pitti> TheMuso: thanks
<pitti> Hobbsee: oh argh, thanks for pointing out
<Hobbsee> pitti: may be worth adding to the doc, or something, not to do that.
<pitti> Hobbsee: we can't update evo yet; I guess we need to do a direct -updates upload with a rebuild
<Hobbsee> pitti: presumably, yeah.
<Keybuk> lucas: http://launchpad.net/merge-o-matic
<seb128> Hobbsee: rebuild uploaded to hardy-updates now, thanks for mentionning
<Hobbsee> seb128: thanks
<seb128> Hobbsee: it's not as easy as migrating all the rdepends, evolution-data-server is still buggy and not ready to migrate to updates
<Hobbsee> seb128: which means it all isn't, or you should do as you're doing now, with the rebuild, just in case.
<Hobbsee> (unless you have some easy way of seeing if all the deps get satisfied, with it in -updates.
<seb128> right, it was an oversight
<Hobbsee> yes, same as last time :)
<StevenK> I wonder if I can brutalise quilt to add a patch only on one arch
<azeem> series.$arch
<StevenK> Sweet
<azeem> StevenK: glibc does that on Debian at least, AFAIK
<azeem> least*
<kirkland> cjwatson: I would like to talk to you about the automatically generated/updated repository of ubuntu manpages and such.  Would you like to do this offline/in-the-halls, in a fosscamp session, or next week during UDS?
<marmadeoli> Como eu posso ajudar no desenvolvimento de algum pacote ubuntu? (How can I help to develop any ubuntu package?)
<mpt> Keybuk, what's the meaning of blue, pink, and white?
<Keybuk> mpt: ?
<mpt> cody-somerville: reported as bug 231403
<ubottu> Launchpad bug 231403 in malone "Can't easily list bug reports I need to follow up on" [Undecided,New] https://launchpad.net/bugs/231403
<mpt> Keybuk, in the UDS schedule
<cody-somerville> mpt, thanks.
<Riddell> there's a UDS schedule?
<tseliot> Riddell: I'm not sure about this but have a look at this link: http://bazaar.launchpad.net/~ubuntu-drivers/uds-intrepid/trunk/files
<Riddell> was hoping for something more readable :)
<tseliot> ï»¿Riddell: me too... :-(
<munckfish> that's got to be the ultimate techy web UI no? :D
<munckfish> all in XML
<munckfish> all in source control
<tseliot> XML is the global language. It will soon replace the English language too (which is deprecated) ;)
<pitti> <answer type="agreement" value="no" />
<cody-somerville> Thats not even the latest
<tseliot> ï»¿pitti: hehehe
<McRib> I am just curious about the status of Bug #228044.  I submitted it a few days ago and it's listed as being fixed in -proposed, but I can't install it.
<ubottu> Launchpad bug 228044 in mplayerplug-in "In Hardy, mozilla-mplayer depends on firefox-3.0 - does not accept firefox-2" [Medium,Confirmed] https://launchpad.net/bugs/228044
<crimsun> what do you mean by "can't install it"?  Are the maintainer scripts failing?  Also, you want to migrate this discussion to #ubuntu-motu.
<McRib> crimsun: What I mean is that it still depends on firefox-3.0... does not accept firefox-2
<crimsun> McRib: dpkg -l mozilla-mplayer|grep ^ii
<crimsun> McRib: and please, this belongs in -motu
<McRib> crimsun: Alright, I'll take it there... I was referred here first, though.
<bud32> Hi, once Ubuntu 8.04 installed, there was some file left with GID 999 throughout the file system. I fixed it with "sudo find / -nogroup -exec chgrp root {} \;"
<hwilde> so how compromised are the keys really
<hwilde> true randomness is not theoretically achievable by state machines
<hwilde> so how can the new algorithm be that much better than the old one?
<jdong> hwilde: err, very compromised.
<jdong> hwilde: metasploit has a 10MB tarball of id_rsa's that you can use to log into any affected machine.
<jdong> reportedly it took 3 hours to generate
<Chipzz> hwilde: there's only 32.000 something keys now
<jdong> if you ran ssh-keygen for 15 minutes you'd probably end up with a bunch of duplicate private keys :)
<hwilde> and the new algorithm is better how
<jdong> hwilde: the old one forgot to seed the random number generator.
<hwilde> holy shit
<jdong> hwilde: rather, it seeded ONLY by the PID of the ssh-keygen generator.
<jdong> hwilde: which makes your key one of 32,767 predictable sequences :)
<jdong> yeah.
<jdong> that was my reaction waking up that morning
<hwilde> that can't be true...
<hwilde> the internet would not still be up
<jdong> hwilde: I wish it weren't.
 * hwilde wonders how many rejected login attemps my servers allow 
<jdong> hwilde: but alas, you can try the metasploit proof of concept with a VM.... it works shockingly well
<hwilde> and what exactly does it mean when ssh-vulnkey says COMPROMISED
<desrt> hwilde; it means that someone else _definitely_ has a copy of your private key
<jdong> hwilde: that means your key is DEFINITELY in http://sugar.metasploit.com/debian_ssh_rsa_2048_x86.tar.bz2
<jdong> ;-)
<jdong> lol
 * Chipzz wonders why this wasn't embargo'd for longer
<jdong> Chipzz: not sure that would've been any more helpful.
<Chipzz> jdong: well, when the embargo was lifted there only was an openssl update
<Chipzz> no openssh update yet
<Chipzz> I had to do a lot of manual key regeneration
<Chipzz> this left a whole lot of people who didn't know how to regenerate their keys vulnerable for a couple of hours/a day
<Chipzz> s/keys vulnerable/vulnerable keys/
<jdong> ssh and ssl services were completely disabled on my system the moment I read the advisory, until I could figure out what was necessary
<jdong> definitely the first few hours were not well handled in terms of publishing the security update informatively.
<Chipzz> jdong: yes, on your system maybe. but there are a lot of less knowledgable people out there
<jdong> even the DSA pointed to a dead link
<jdong> Chipzz: I'm agreeing with you here...
<Chipzz> it should have been as simple as apt-get install openssh-server
<Chipzz> which it wasn't at first
<Chipzz> also
<Chipzz> there wouldn't have been an excuse to have a metasploit "plugin" then
<Chipzz> since you could easily check just running apt-get install openssh-server
<ipkaf> hi
<Mez> cjwatson, ping. Im using ssh-vulnkey, and its showing me some entries that i cant find in files anywhere, but seem suspicious
<Mez> any idea how to find out what files they're coming from?
<StevenK> strace? :-P
<gnomefreak> Mez: it doesnt give you something like /home/gnomefreak/.ssh/id_rsa.pub
<Mez> nope. was giving me root@domain.i.dont.know
<Mez> (replacing domain.i.dont.know
<Mez> as the comment
<Mez> appears it was my host keys as generated somwhere else
<Mez> which I've now re-generated anyways
<gnomefreak> Mez: ah
#ubuntu-devel 2008-05-18
<bud32> Hi :) ï»¿what means "intelfb: cannot reserve FB region" ? This message appears on system boot. I have a custom config for this kernel. I saw the code... drivers/video/intelfb/intelfbdrv.c:568, does cleanup() then return means that the intelfb is not actually used / completely initialized? I tried without the driver, but I couldn't use tty's.
<atrus> at some point I used to be able to put a script into /etc/acpi/resume.d (in particular 99-xrandr.sh), and have it run when I resume from suspend, but now that doesn't seem to happen. Has that behavior changed, or am I doing something wrong?
<J-Unit> atrus: yeah it's now /etc/pm.d/suspend.d or somethig of that sort
<atrus> J-Unit: hmm. /etc/pm.d has nothing but 3 empty subdirectories.
<J-Unit> atrus: yeah.... I wish I remember the correct format off the top of my head
<J-Unit> but currently I'm on a RHEL box and can't check
<J-Unit> ubuntu land is suffering a power outage ;-)
<atrus> heh. well, it gives me something else to google for anyways :)
<J-Unit> it's the standard pm-utils script format
<J-Unit> list the contents of pm-utils
<J-Unit> and in /usr/share you should see similar formatted scripts
<J-Unit>  the /etc/ location is simply a supplement to those
<TheInfinity> blaxun1st
<bain> Good morning.
<bain> Is there currently any plans for an integrated user desktop backup application ?
<persia_ume>  What would it backup up?  To what media?  On what conditions?  There are several tools to facilitate this, with different answers to those questions available.
<bain> persia_ume: I'm talking about an easy way to backup your desktop to usb to migrate a desktop to another machine ? medium would likely be usb since it's portable. I'm really thinking of something aimed at a newby ubuntu user
<persia_ume> bain: Hmmm...  I suspect you're looking for something based on sbackup or hubackup, but I'm not sure.
<jscinoz_> Is it planned to migrate to Grub2 at some point?
<jscinoz_> as the default bootloader
 * pitti takes a stab at the xargs b0rkage in intrepid
<stgraber> pitti: where are you ? :) I don't see you at the 3rd floor (or you are behind me)
<pitti> stgraber: I'm in my room; is there wifi still?
<stgraber> yep
<stgraber> I guess we are like 20 here using the fosscamp wifi, it's still really fast and working just fine
<pitti> coming down then
<pitti> StevenK: I shouldn't have said it so loud ... http://launchpadlibrarian.net/14584191/buildlog_ubuntu-intrepid-i386.findutils_4.4.0-2ubuntu2_CHROOTWAIT.txt.gz
<pitti> infinity: so, my new upload of findutils to fix the xargs b0rkage doesn't build, because it fails with that very xargs crash; that requires some manual building, I figure?
<pitti> lamont: ^
<kahrytan> What is being done to prevent what happened with SSH keys  in debian/ubuntu to never happen again?
<jdavies> !libsslbug > kahrytan
<pitti> kahrytan: that's one of the bad things in the world, you can only defend against catastrophes that already happened; but there are infinitely many more ways to break something
<pitti> kahrytan: but this certainly helped to raise awareness and caution a lot
<kahrytan> Was that package only managed by 1 person?
<pitti> two at the moment
<kahrytan> At the time of issue?
<RAOF> tjaalton: You were the person interested in putting nouveau into experimental, right?  I'm currently playing around with module-assistant-ing the drm modules, which may make that easier/possible.
<kahrytan> This just proves that two or more people needs to over see code before it comes mainstream.
<tjaalton> RAOF: right, it was discussed recently on debian-x@
<RAOF> tjaalton: Ah.  I'm obviously not subscribed to that; is there a one line summary?
<tjaalton> RAOF: "hard" :)
<tjaalton> to maintain, at least
<RAOF> Right.  Because you sometimes need new snapshots of libdrm for new snapshots of nouveau.
<tjaalton> yep..
<RAOF> And you want to keep reasonably current with nouveau, so...
<RAOF> Well, after I've tested this, it'll be possible to point debian people at my source packages, at least.
<tjaalton> there really ought to be a new libdrm release soon, since X 7.4 basically can't release without it
<RAOF> Oh, DRI2.
<tjaalton> right
<tjaalton> unless they demote it as experimental
<kahrytan> pitti,  The funny thing about this.. this was one my parents worest fears about linux. What is stopping coders from putting backdoors/security holes in code?
<pitti> kahrytan: that's not a linux specific problem
<RAOF> tjaalton: By 'they', you mean Debian-X?  Or upstream?
<kahrytan> pitti,  but it's easier to do for a hacker in oss.
<soren> kahrytan: Err? Why?
<pitti> kahrytan: there was one such case in Debian that I faintly remember, and it was discovered pretty fast and the code got a big audit
<ivoks> kahrytan: how? other hackers could check source
<kahrytan> pitti,  Yet, ths ssh one didnt get discovered for awhile
<ivoks> kahrytan: that's much easier to do in closed source; no one but you could check the source
<tjaalton> RAOF: upstream
<pitti> kahrytan: no, you can't "just do" it, you need to earn credibility and permissions first
<soren> kahrytan: If there's a backdoor in a closed source product, noone will discover it. In free software, eventually someone will discover it.
<ivoks> kahrytan: do you know how many of those are in closed source world? :)
<RAOF> tjaalton: That would suck.  DRI2 brings world peace.  It'd be nice to have in Intrepid :)
<kahrytan> ivoks,  How many people work for close source developer?
<ivoks> kahrytan: a lot less than on open source
<virtuald> were the other vulns in that dsa from debian or wideopenbsd?
<kahrytan> I just know if this happens again, it will hurt OSS more then anyone realizes.
<tjaalton> RAOF: yeah..
<ivoks> kahrytan: it might seem like that, yes... but you have to wonder... are you sure this kind of thing never happend anywhere else?
<pitti> kahrytan: I'm undecided on that; on the one hand it proves transparency, on the other hand you always lose a big chunk of trust on those
<ivoks> we aren't silent about our problems, closed source vendor are
<kahrytan> ivoks,  On the one hand,  It didnt take long to fix it.  M$ would have waited til patch Tues.
<ivoks> kahrytan: MS wouldn't patch that at all
<pitti> closed source devs aren't invincible against making stupid errors either, we are all just humans
<ivoks> at least, not the way we did
<kahrytan> They would patch it but not tell anyone
<virtuald> how do you define aren't silent?
<pitti> under that assumption, the OS/CS quality wrt. to those incidents doesn't make much of a difference
<virtuald> In addition to this critical change, two other vulnerabilities have been fixed in the openssl package which were originally scheduled for release with the next etch point release: OpenSSL's DTLS (Datagram TLS, basically "SSL over UDP") implementation did not actually implement the DTLS specification, but a potentially much weaker protocol, and contained a vulnerability permitting arbitrary code execution (CVE-2007-4995). A side channel attack i
<ivoks> kahrytan: yes, and leave vul. key to work
<kahrytan> ivoks, I hope Debian community something from this.
<ivoks> virtuald: we exposed the problem, made a patch and made those vul. keys unusable
<kahrytan> *learned something
<ivoks> ms would probably do all of that, except making vul keys unusable
<ivoks> cause that would produce a lot bad publicity
<ivoks> ...a lof of bad...
<pitti> ivoks: that's pure speculation, though
<kahrytan> How is Ibex progressing?
<ivoks> pitti: of course...
<virtuald> :>
<ivoks> kahrytan: smart people learn while they live...
<kahrytan> ivoks,  and the idiot people ...?
<ivoks> kahrytan: stop learning when they finish their school
<kahrytan> ivoks,   Smart people learn while they live, avg people forget what they learned, and idiot people dont bother to learn.
<kahrytan> but i dont mean it
<ivoks> pitti: anyway... i found out where the problem was with pgsql; pebkac :/
<kahrytan> Has anyone bother to make Ubuntu Installer import existing preferences on an existing install?
<tjaalton> kahrytan: debconf-get-selections --installer > foo
<kahrytan> Thats nice. Now does Ubuntu installer do it automatically?
<ivoks> this, of course, isn't support channel
<pitti>  kahrytan: we also have this "migration assistant" in the installer which keeps some settings (or the partitioner keeping your /home dir)
<kahrytan> ivoks,  just showing some feature seeds. :-P
<ivoks> pitti: right, it can even import your windows settings :)
<kahrytan> pitti,  You mean the migration assistant for windows prefs?
<kahrytan> The same assistant that failed to work in Ubuntu 8.04?
<ivoks> kahrytan: file a bug
<pitti> kahrytan: it also imports Firefox/Pidgin from Linux installs
<pitti> but I haven't used it much, I just keep my /home forever
<kahrytan> It's supposed to do that import from prev installs?
<pitti> you can tell it to
<kahrytan> Wouldnt know how to.
<kahrytan> I just thought no one tried to add it since either of install screens asked about it.
<evand> It's not shown if it cannot do anything, such as when you're overwriting the partition in question.
<evand> err, the partition that you would be importing from.
<Samsemilia> ,seen mvo
<Samsemilia> !seen mvo
<ubottu> Factoid seen mvo not found
<Hobbsee>  /msg seenserv seen mvo...
<Keybuk> Preparing to replace debconf 1.5.20 (using .../debconf_1.5.21_all.deb) ...
<Keybuk> xargs: xargs.c:443: main: Assertion `bc_ctl.arg_max <= (131072-2048)' failed.
<Keybuk> EPIC.
<Keybuk> FAIL.
<TheMuso> eh
<lamont> pitti: that or an upload that builds without needing xargs...
<pitti> lamont: that's hard, since debconf is already in the chroot, and it fails to upgrade; there's no way how to fix it with dropping build deps
<pitti> lamont: I guess one would need to download the chroot, hit debconf over the head to install properly, save it, and upload it back?
<lamont> pitti: ew
<amitk> Keybuk: https://edge.launchpad.net/~kernel-ppa/+archive
<Keybuk> amitk: ah, thanks
 * Keybuk kills the heater
<infinity> pitti: Probably, yeah.
<dondelelcaro> hey; is there a UDS specific channel?
<KristianL> yeah, #ubuntu-devel-summit
<dondelelcaro> ah, thanks
<emgent`UDS> heya
<pitti> hey emgent
<emgent> hey pitti :)
<emgent> fosscamp AP r0cks!
#ubuntu-devel 2009-05-11
<kees> Keybuk: MoM is marking changelogs as jaunty instead of karmic
<Keal> i found a severe glitch in ubuntu for athlon64xp cpu machines
<Keal> the same glitch is in windows xp
<Keal> mass storage devices with a boot partition on them lose power via usb 2.0 as soon as the kernel loads
<Keal> causing the kernel to halt loading
<lifeless> Keal: you should start by filing a bug
<geiseri_> is there a way to force apt to redownload all of the currently installed packages?
<geiseri_> apt-get -d install $(dpkg --get-selections | awk '{print $1}') seems to not do it
<StevenK> apt-get -d --reinstall ?
<geiseri_> oh /me tries that
<geofft> Something like rm -r /var/cache/apt; aptitude -d install '~i'?
<geiseri_> it seems the apt-get -d --reinstall is doing the trick... i just need to create a local repo of a currently installed system.  it seems apt-move needs a fully populated /var/cache/apt/archives folder though
<directhex> Keal, that would be an issue related to a specific motherboard chipset, not the CPU
<Anon> roll call
<Anon> where can I get a copy of the libdvdcss library?
<Anon> i can't seem to find the LINUX version with a google search
<Hobbsee> !libdvdcss
<ubottu> For multimedia issues, this page has useful information: https://help.ubuntu.com/community/RestrictedFormats - See also https://help.ubuntu.com/9.04/musicvideophotos/C/video.html - But please use free formats if you can: https://help.ubuntu.com/community/FreeFormats
<Anon> un erstood
<Anon> >understood
<Anon> stupid keyboard
<Hobbsee> there's a script that will install it for you, too
<Hobbsee> in libdvdread4.  However, i think that page will tell you more
<Hobbsee> oh, it points directly to medibuntu now
<Anon> hobbsee, thanks for the tip on the libdvdcss
<Hobbsee> Anon: you're welcome
<Anon> i guess I'll see you guys later.
<Anon> and thanks for giving version 9.04 the ability to use my sprint wireless air card
<Hobbsee> :)
<Anon> now i can finally get rid of windows
<Anon> later
<pace_t_zulu> can someone point me to some documentation regarding install time package detection with dpkg/apt?
<lifeless> pace_t_zulu: what do you mean
<pace_t_zulu> i am working on a fix for https://bugs.launchpad.net/ubuntu/+source/matplotlib/+bug/301007
<ubottu> Ubuntu bug 301007 in matplotlib "python-matplotlib: missing package dependency (python-tk)" [Undecided,Confirmed]
<pace_t_zulu> !ubottu
<ubottu> Hi! I'm #ubuntu-devel's favorite infobot, you can search my brain yourself at http://ubottu.com/factoids.cgi - Usage info: http://wiki.ubuntu.com/UbuntuBots
<lifeless> pace_t_zulu: it looks like there is a fix as far as packaging is concerned
<geofft> pace_t_zulu: why not try: import Tkinter, except: try: import ...?
<lifeless> pace_t_zulu: to do an auto backend, you don't need package detection - that would be slow. Instead just try importing the various python modules
<lifeless> try:
<lifeless> e.g.
<lifeless>     import tkbackend
<pace_t_zulu> are you referring to this fix? http://launchpadlibrarian.net/26327836/matplotlib_0.98.5.2-1ubuntu4.debdiff
<lifeless>     return tkbackend
<lifeless> except ImportError:
<lifeless>     pass
<lifeless> try:
<lifeless>     import gtkbackend
<lifeless>       return gtkbackend
<lifeless> except ImportError:
<lifeless>     pass
<lifeless> etc
<geofft> right, what he said, but in fewer words. :) do it at runtime, not install time, because packages can change later
<geofft> and check for the python packages, not debian packages. What if I easy_install something?
<pace_t_zulu> lifeless thank you
<ScottK> geofft: If you easy_install something, the Debian packaging system can't help you.
<geofft> sure... that's an argument to do this check outside of the Debian packaging system :)
<geofft> for example, I can easy_install something into ~. I can't do that to a Debian package
<geofft> the point is that dpkg -l python-tk is not the same as try: import Tkinter, and the latter is what you actually care about
<ScottK> Sure.
<pace_t_zulu> this is a UX problem i am trying to address... i agree that a backend fix is optimal
<ScottK> pace_t_zulu: If you're trying to fix a Debian package, use the Debian packaging system.  Just add it as a depends.
<pace_t_zulu> ScottK: it is already a depend
<ScottK> Then it's not missing.  I don't understand.
 * ScottK goes to read the actual bug and not just the title.
<pace_t_zulu> ScottK: problem is that the python-tk depend is ORed with python-gtk2 which is available on ubuntu systems
<geofft> Er, can't you add a patch to it to do the try/import test if /etc/matplotlibrc doesn't exist?
<pace_t_zulu> but the default backend is set to python-tk
<geofft> (and not install an /etc/matplotlibrc)
<pace_t_zulu> so the python-tk should have an exclusive depend
<pace_t_zulu> for a quick fix... but i agree that a more optimal fix should be implemented next
<lifeless> its been quick fixed
<pace_t_zulu> lifeless: it has not
<lifeless> the quick fix for ubuntu is incompatible with a quick fix for kubuntu is incompatible with a quick fix xubuntu
<ScottK> OK.  I read the bug.  I understand it now.
<pace_t_zulu> python-tk is not installed with python-matplotlib
<lifeless> because they all want a different backend
<pace_t_zulu> lifeless: exactly
<lifeless> so it has been quick fixed. You can't quick fix it any more. Do the real fix.
<pace_t_zulu> there are a lot of different ideas about how to be fixed
<lifeless> its probably about as much time as has been spent discussing it here to do it.
<pace_t_zulu> lifeless: that debdiff that i provided has not been accepted
<pace_t_zulu> lifeless: i'm fine with that... do you think it should be implement at the backend?
<calc> ok so i don't know if i am the moron or if doko 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,Fix released] https://launchpad.net/bugs/373911
<calc> he's telling me to use openjdk for building OOo which I already do (except for ia64 which was due to openjdk bugs) so I close the bug after telling him as much... he reopens the bug AGAIN telling me the same thing without addressing the fact that I already told him I am using openjdk
<calc> so either i am having a severe reading comprehension issue or he is, lol
<lifeless> pace_t_zulu: an auto backend was proposed; and the bug seems to claim there is an upstream bug for that already
<calc> doko: ping... you are confusing the hell out of me wrt 373911
<pace_t_zulu> lifeless: i still think that short term an ubuntu4 should be created that depends 'python-tk' and ubuntu5 can do the proper fix
 * calc bbl
<lifeless> pace_t_zulu: have you had much luck convincing people of that?
<pitti> Good morning
<ScottK> Good morning pitti.
<pitti> dtchen: right, I was following along; let's revert the patch, unless you find a better solution; thank you!
<pitti> ScottK: hey, how are you? had a nice weekend?
<ScottK> pitti: Not bad.  It was Mother's Day here on Sunday, so that was a big day at our house.
<ScottK> I worked 6PM to 2AM last week and I'm still trying to get my clock re-adjusted (thus am up at ~2am).
<pitti> here, too
<pitti> ScottK: ugh, recently came from Europe or so? :-)
<ScottK> pitti: No, just had some testing I was involved with and that was the only time we could get all the necessary facilities.
<dholbach> good morning
 * pitti hugs dholbach
<pitti> Keybuk: good morning
 * dholbach hugs pitti back
<pitti> Keybuk: would you mind doing a git update in udev-extra ubuntu branch? I uploaded usbutils 0.82 yesterday (new build dep) and committed running the build tests (I added one to upstream git yesterday)
<iulian> TheMuso: Hi.  The policykit merge was already done.  I've also included a patch which would have allowed a SRU to go ahead.  See bug #372599.
<ubottu> Launchpad bug 372599 in policykit "Merge policykit 0.9-3" [Wishlist,Confirmed] https://launchpad.net/bugs/372599
<iulian> Having that said, would you like to take care of that SRU as well, please?
 * iulian wonders what he should do with that bug.
<TheMuso> iulian: hrm I don't remember seeing any policykit bugs.
<iulian> Set its status to Fix released or Invalid?
<TheMuso> for merging
 * TheMuso checks again
<TheMuso> iulian: sorry, I totally and utterly missed it. I'll deal with that bug.
<iulian> TheMuso: No problem, thanks!
<pitti> asac: I was going to propose udev-extras for main today, to switch keymap handling from hal to it
<pitti> asac: that will bring the modem prober to main as well
<pitti> asac: I wondered, how could n-m use the modem prober in jaunty with udev-extras still being in universe? did it copy the code?
<pitti> asac: ah, apparently so; could we try using the ones from udev-extras in karmic soon?
<dholbach> robert_ancell: good work on the gcalctool merge/update
<robert_ancell> dholbach: cheers
<lool> Hi all
<pitti> hey lool, good morning!
<lool> Hey pitti!
<didrocks> hey everybody :)
<didrocks> doko: around?
<djsiegel_> hey didrocks
<didrocks> hello djsiegel_
<tkamppeter> pitti, hi
<pitti> hi takm
<pitti> hi tkamppeter
<tkamppeter> pitti: Can you upload CUPS to Debian and Ubuntu? I have done a one-line patch to fix three bugs. This one will also be an SRU.
<pitti> tkamppeter: will do
<tkamppeter> pitti, is the last SRU of CUPS already in -updates
<pitti> tkamppeter: see "rmadison cups", it is
<pitti> tkamppeter: you forgot to bzr add the new patch; please do, commit, and push
<tkamppeter> pitti, done
<lifeless> TheMuso: patch sent off
<TheMuso> lifeless: thanks
<pitti> tkamppeter: the ps2write patch doesn't look like an appropriate SRU
<pitti> tkamppeter: if you change the gs backend, that has a high regression potential, doesn't it?
<lool> Is this a good time to upgrade to karmic?  Anything I should be careful with or hold back?
<lool> (/me returns from holidays and wants to jump into karmic)
<pitti> lool: works pretty well; UXA might be a bit unstable if you enable it, but it's not by default
<tkamppeter> pitti, perhaps we let it go into Karmic and wait for a month to see whether it causes any bug reports. If it does not cause bug reports there, we SRU it? WDYT?
<pitti> tkamppeter: it would help certainly, but switching the entire implementation is still regression prone
<pitti> tkamppeter: if there's a focused workaround for the particular affected driver/printer model, this would be more appropriate
<tkamppeter> pitti, bug 361772 has the foomatic-db-engine SRU as workaround, the Ricoh PPDs I will soon update on OpenPrinting, so this bug is not a problem. bug 369503 shows that the PostScript of pswrite is not compatible with a proprietary Canon driver, at least for  some PDF files. We can provide tha alternative pdftops to the individual users here, bug 362186 shows that the PostScript of pswrite is incompatible with the PostScript interpreter
<tkamppeter> of some HP printers, we could tell the users to use PCL-XL mode here.
<ubottu> Launchpad bug 361772 in foomatic-db-engine "black squares appearing instead of some letters when printing" [Undecided,In progress] https://launchpad.net/bugs/361772
<ubottu> Launchpad bug 369503 in cups "Evince and Firefox fails to print but OpenOffice prints normaly in Jaunty" [Undecided,Triaged] https://launchpad.net/bugs/369503
<tkamppeter> pitt WDYT?
<ubottu> Launchpad bug 362186 in cups "Spurious lines on print outs" [Medium,Triaged] https://launchpad.net/bugs/362186
 * ogra sees lots and lots of users that haed probs with their manually edited menu.lst, didnt know what to do when update-manager/debconf asked and ended up with only the old .lst file that just boots their intrepid kernel ... 
<ogra> i wonder if we should have a spec about a way to improve that, seems ucf in that case is a bit strictr
<ogra> *strict
<ogra> (or rather "not userfriendly enough")
<pitti> tkamppeter: Is that something they can influence, by picking another driver?
<cjwatson> ogra: last time this came up, Steve reckoned the current situation was pretty close to the best we could do given grub's shoddy update-grub design, and that switching to grub2 was a better long-term approach
<cjwatson> we might not be that far off the latter
<ogra> ah, if thats a possibility even better, i just notice that about 10% of the upgrade probs i see on IRC or in lists are menu.lst related ... people often get advised to edit the kernel lines directly so there are many where the question comes up
<ogra> (or even tools that edit the file the wrong way)
<tkamppeter> pitti, for the incompatibility of HP's PS interpreter with pswrite output they could switch to the pxlmono driver. Currently, this does not happen automatically, but I also do not know which HP printers have the problem (LJ 1320 and LJ 4050 have the problem according to bug report, my LJ 3390 and LJ P3005 do not have the problem).
<pitti> Keybuk: hal with libblkd uploaded, FYI; so the only remaining thing is redhat-cluster
<asac> pitti: sorry, NM does not use the modem prober from udev-extras. it ships its own modem-prober; so at best remove it from udev-extras for the time being
<pitti> asac: oh, that's not just a copy?
<asac> pitti: no. the udev-extras thing was an experiment afaik
<tkamppeter> pitti, for the incompatibility with the Canon driver one will need the ps2write device.
<pitti> asac: if it should permanently live in n-m, then we should remove it from udev-extras completely IMHO
<lifeless> TheMuso: please read my patch; if you're happy with it we could just land it in karmic ;)
<pitti> asac: (and I agree that it would make sense to keep it in NM)
<TheMuso> lifeless: will have a look in a bit.
<asac> pitti: i will check with Dan, for now i would think it should be removed ... it might do harm
<asac> by probing some modem ports its not supposed to probe etc.
<pitti> asac: thanks; indeed it should just be probed once, and the code should just live in one place
<lifeless> TheMuso: thanks
<directhex> hm, i wish i didn't need to restart my printer every print
<pitti> tkamppeter: hm, current cups test suite hangs on "Waiting for jobs to complete..."
<pitti> tkamppeter: that worked in the previous upload
<TheMuso> lifeless: that looks ok to me. I've not had a lot to do with the isw code so I don't know it that well, so if it works for users with older signatures, and newer signatures, thats fine. I have ICH8 here, and can try your patch as part of dmraid for reading a pair of disks I can use for testing, but will do that tomorrow.
<lifeless> TheMuso: cool
<lifeless> TheMuso: I can't see how I would have broken older disks :)
<TheMuso> lifeless: Neither can I, but it doesn't hurt to test.
 * TheMuso doesn't use dmraid at all, but ensures he has spare disks available for testing. :)
<TheMuso> use as in use full-time.
<lifeless> cool
<lifeless> thanks
<pitti> tkamppeter: can you please try to build current cups on current karmic? test suite fails pretty badly (and hangs in sid)
<lool> directhex: Congrats on MOTY!
<lool> *MOTU
<tkamppeter> pitti, strange, as botth changes which I did after your 1.3.10 update seem to be harmless, or can perhaps one of them have torn down the tests? I could build the whole thing on Jaunty.
<pitti> tkamppeter: could also be newer ghostscript in karmic/sid, etc>?
 * TheMuso sighs. Even though mdadm 3 will have support for isw metadata, it won't support others, which means a combination os dmraid and mdadm will have to be used.
<tkamppeter> pitti, I did not replace Ghostscript by something newer after Jaunty. Did there come a new Ghostscript from Debian?
<pitti> tkamppeter: no, apparently not
<StevenK> TheMuso: Does that at least solve the reconstruction problem?
<TheMuso> StevenK: For isw it will.
<TheMuso> StevenK: as it is now, only isw can be reconstructed with dmraid and even then I'm not sure how thats supposed to work.
<lifeless> TheMuso: Score!
<lifeless> TheMuso: have you looked at the 2.4 isw kernel module?
<lifeless> *fun*
<TheMuso> lifeless: yeah
<TheMuso> lifeless: no
<\sh> moins
<ogra> could someone rescore python-apt on armel ?
<ogra> as well as nautilus-share
<ogra> and totem
 * StevenK waits for ogra to ask for *
<ogra> heh
<ogra> these three for now, just checking what breaks openoffice
<ogra> seems thats the last one holding up livecd-rootfs on armel
<\sh> ogra: when do you have time to visit KA? we need to celebrate :)
<ogra> \sh, probably on my way back from barcelona
<Hobbsee> ogra: trying to
<ogra> (going by car, should be easy to drop by in KA)
 * ogra hugs Hobbsee 
<\sh> ogra: please do :) just tell me when that is :) I need to plan my life a bit different now :)
<pitti> tkamppeter: hah, I get a lot of gs segfaults in kern.log indeed
<StevenK> \sh: Next 18 years: raise child; After that: everything else
<ogra> \sh, oh, yeah, congrats btw :D
<Hobbsee> right.  What magic runes do I have to do to make launchpad happy this time?
<\sh> StevenK: oh well...raising child and taking care of family ==> prio 1 :) then work and universe and then the rest :)
<\sh> ogra: thx :)
<StevenK> Hobbsee: You need to sacrafice a rubber chicken on the stroke of 9pm with a silver handled knife
<Hobbsee> StevenK: heh.  Seems like it
<lifeless> Hobbsee: what is it unhappy with
<Hobbsee> Rescoring https://launchpad.net/ubuntu/+source/nautilus-share/0.7.2-5/+build/989902 (armel).
<Hobbsee> Unable to request rescore on armel.
<Hobbsee> lifeless: ^
<Hobbsee> i've regenerated my LP cookie
<lifeless> cprov: ^
 * ogra guesses there was not enough sugar in the cookie ... LP likes it sweet :)
<StevenK> Estimated build start:  2009-05-12
<StevenK> Heh
<cprov> Hobbsee: apparently I am, what's the value you want to set ?
<ogra> hight++
<Hobbsee> ah, damn
<ogra> *high even
<Hobbsee> the syntax has changed - it needed to be ~/.lpcookie.txt now, not just ~/.lpcookie, which was what my logs had
<Hobbsee> lifeless, cprov: sorry for the noise
<cprov> Hobbsee: np
<Hobbsee> ogra: all tweaked
<ogra> thanks a lot
<Hobbsee> y/w
 * Hobbsee adds the new version to her ~/UsefulCommands
<tkamppeter> pitti, I have also many gs segfaults. Which gs drivers is the CUPS test suite using?
<pitti> tkamppeter: I don't know by heart
<ogra> seb128, do you plan to switch RB from libnautilus-burn to brasero in karmic ? (it currently ftbfs on armel because of the nautilus dep)
<seb128> no opinion on the topic
<seb128> but it should not be an issue right now
<seb128> what is the issue exactly?
<tkamppeter> pitti, there is a queue using rastertohp in the test suite, so the cups device of GS is crashing.
<ogra> The following packages have unmet dependencies:
<ogra>   libnautilus-burn-dev: Depends: libeel2-dev but it is not installable
<ogra> seb128, ^^
<ogra> from http://launchpadlibrarian.net/26525134/buildlog_ubuntu-karmic-armel.rhythmbox_0.12.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> did nautilus-cd-burner ftbfsed too?
<ogra> (yes i know its eel's fault, but i was curious)
<seb128> no it's not
<seb128> that's a deprecated lib and it's not used nowadays
<ogra> oh
<seb128> it has been cleaned in karmic
<seb128> I expect your issue is that nautilus-cd-burner didn't build on armel
<seb128> it did 8 hours ago in fact
<ogra> i see no further trace of nautilus on http://qa.ubuntuwire.com/ftbfs/ ... but havent checked all nautilus builds yet, nautilus-share was clearly sitting and not even built yet, not sure about the other nautilus packages, just going through them
<seb128> ogra: did you apt-get update?
<seb128> ogra: should be fixed since 6 hours ago or so
<ogra> on the buildd ?
<seb128> https://edge.launchpad.net/ubuntu/+source/nautilus-cd-burner/2.25.3-0ubuntu2/+build/978020
<ogra> ah, k, so a give back will fix it
<seb128> it should
<ogra> good, thanks
<seb128> you're welcome
<ogra> :)
<tkamppeter> pitti: For me also the pdftops filter segfaults, but this is the filter written in C which comes from CUPS 1.3.10.
<Keybuk> cjwatson: a build failure is baffling me
<Keybuk> cjwatson: it honestly looks like dpkg hasn't applied the full diff.gz
<pitti> Keybuk: Keybuk: would you mind doing a git update in udev-extra ubuntu branch? I uploaded usbutils 0.82 yesterday (new build dep) and committed running the build tests (I added one to upstream git yesterday)
<Keybuk> ooh, your stuff got merged?
<Keybuk> 3044c4e ok?
<pitti> Keybuk: I committed it myself with Kay's approval
<pitti> Keybuk: 3044c4e ack
<pitti> Keybuk: also, asac said that we should not install the modem prober for now, since it's already in NM
<pitti> Keybuk: unless you want to do that, I can work on it later
<Keybuk> modem-probe is empty now, no?
<pitti> oh right, that was modem-modeswitch
<ogra> hrm, no mvo today ?
<pitti> ogra: holiday
<pitti> Keybuk: ok, thanks
<ogra> gah
<Keybuk> ogra: holiday this week
 * pitti -> physiotherapy and lunch, back in ~ 1 hour
 * ogra wonders whom to poke for python-apt then :/
<cjwatson> Keybuk: oh?
<Keybuk> cjwatson: looks like the diff.gz was corrupted
<cjwatson> odd that it didn't bail if so
<cjwatson> or was it corrupted such that that was justifiable?
<Keybuk> I think that things were just missing from it
<Keybuk> dpkg-source--
<Keybuk> since they're clearly in my working directory as changes ;)
<Keybuk> regenerated it and it looks ok now
<james_w> jdstrand, kirkland: syncbugbot failed for me too. Regenerating my lpcookie fixed it though
<cjwatson> james_w: there's an RT request open for diffstat
<james_w> cjwatson: cool, thanks
<pitti> asac: okay, so the modem prober went away in udev-extras; modem-modeswitch is still left; do you know whether that should/will move to nm as well?
<pitti> Keybuk: whoops, missed new gperf build dep; I'll upload a new version
<pitti> Keybuk: hm, can you please bzr push udev-extras?
<asac> pitti: will check on that. a bunch of drivers already do the modeswitch automatically afaik. so maybe this wont be needed at all.
<pitti> asac: cool
<pitti> asac: do you know whether the modem prober makes all those hal-info FDIs obsolete already?
<pitti> asac: I wonder what's missing in order to drop them
<Keybuk> pitti: weird "these branches have diverged" <g>
<pitti> Keybuk: did you pull first? I added a test suite call to debian/rules
<Keybuk> ahh
<Keybuk> I did pull
<Keybuk> but of course, bzr pulled from the wrong place
<asac> pitti: in theory it makes them obsolete ... however, we still use them to tie-break if the modem prober is unsure
<Keybuk> so said everything was fine
<pitti> Keybuk: I told you in the morning, but I guess you weren't sufficiently caffeinated yet or so :)
<Keybuk> pitti: I don't read IRC scrollback
<asac> pitti: you are looking in removing hal-info completely? or just the 10-modem.fdi?
<pitti> asac: eventually it needs to go away completely
<pitti> but of course we should remove stuff part by part, once we know that it can go
<Keybuk> pitti: ok, pushed
<asac> pitti: i think we cannot remove 10-modem.fdi upstream ... we still need SRUs for hardy/intrepid for a while i guess
<pitti> asac: yes, but we shoudl eventually stop shipping them in karmic
<pitti> ./configure --without-modem or so
<tkamppeter> pitti, I have looked into the error_log of the test suite of CUPS. pdftops segfaults in job 4.
<pitti> Keybuk: what do you do after a git import to get configure etc.? Just run autogen.sh in the ubuntu tree? or a make dist upstream, and untar into your package tree?
<asac> pitti: i will verify what exactly we are still using hal for ... i think there are some corner cases where having the fdi helps NM to tie-break, but that could be obsolete as we improved the modem prober considerably in the last few 0.7.1 commits - stay tune
<pitti> asac: yeah, I wondered whether we should disable them early and ask for regression testing
<Keybuk> pitti: autoreconf -i
<pitti> Keybuk: great, will do that
<Keybuk> usually bzr clean-tree first
<pitti> already done
<TheMuso> pitti: if you're talking about hal deprecation, pulseaudio still relies on it somewhat heavily, and upstream doesn't appear to be moving away from it just yet.
<pitti> Keybuk: why not do that in debian/rules then, in build/ ?
<pitti> TheMuso: right, I know; X.org input needs work as well
<pitti> TheMuso: I guess there is a fair chance that we have to ship hal by default in karmic, but I'd like to see as many parts as possible migrated early
<pitti> to minimize the structural changes in the lazy lizzard (LTS)
<TheMuso> Ok, I'll see what upstream plans on doing.
<Keybuk> pitti: I don't like putting that kind of thing in debian/rules
<pitti> ooh, we can have orig.tar.bz2 now?
<Keybuk> since it means you're uploading something that you haven't actually tested the build of
<asac> pitti: http://paste.ubuntu.com/169518/
<asac> pitti: so removing hal would make all modems get deferred initialization ... looked at code, and i think it should be fine.
<pitti> asac: it looks like only d) is the remaining concern then?
<asac> pitti: in any case. i think we shouldnt remove 10-modem.fdi
<asac> modemmanager uses hal atm and we want to experiment with that (hopefully moving it to udev as well)
<pitti> Keybuk: it doesn't like me when building in build/: make[4]: *** No rule to make target `keymaps/*', needed by `all-am'.  Stop.
<asac> pitti: yeah. i checked ... d) shouldnt be a concern from what i see. its actually the right thing. however, if we could keep 10-modem.fdi until we have ported modemmanager to udev that would be precious
<Keybuk> pitti: keymaps/* doesn't look like a valid taget?
<pitti> asac: sure
<Keybuk> pitti: you can't use wildcards like that ;)
<asac> ok i will tell you once we have made progress
<pitti> Keybuk: keymap/Makefile.am has udevkeymap_DATA = keymaps/*
<Keybuk> pitti: exactly, you can't use wildcards in make like that
<Keybuk> that means a file *called* keymaps/*
<pitti> Keybuk: $(shell ls keymaps/*) then?
<Keybuk> pitti: Automake will forbid it
<Keybuk> pitti: just list them
<Keybuk> 27.3 Why doesn't Automake support wildcards?
<Keybuk> Developers are lazy.
<pitti> that's stupid
<Keybuk> (and then with sensible rationale)
<Keybuk> read that info page
<pitti> having to explicitly list all files in a subdir?
<Keybuk> pitti: then you'll end up accidentally distributing keymap~
<pitti> that reminds me why I ripped out the automake stuff from human-icon-theme and friends
<Keybuk> keymap.orig
<Keybuk> keymap.rej
<Keybuk> etc.
<pitti> meh
<Keybuk> the usual rationale is "since you have to 'bzr add' the new file, you should also add it to Makefile.am as the same reflex"
<tkamppeter> pitti, if you run "filter/pdftops 1 1 1 1 "" test/testfile.pdf" from within the CUPS source directory (after compiling) you get a segfault in pdftops.
<pitti> Keybuk: glob -> explicit list committed to trunk
<pitti> Keybuk: and gperf build dep committed as well; could I ask you for another git pull?
<Keybuk> pitti: pulled, merged, pushed
<pitti> Keybuk: thanks
<directhex> yay james_w
<directhex> \o/
<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 or if there is anything I can do better (more details in the bug report etc)?
<sveinung__> By the way: How long should a package be in Karmic before I can suggest a sru to jaunty?
<cjwatson> i/wg 169
<cjwatson> (sorry)
<mnemo> sveinung__: which bugs is it?
<pitti> tkamppeter: is that due to one of our patches? I know that it didn't happen in 1.3.10-1
<sveinung__> pitti: bug 345706
<ubottu> Launchpad bug 345706 in packagekit "CMake can't find QPackageKit by default" [Undecided,Triaged] https://launchpad.net/bugs/345706
<pitti> sveinung__: you probably meant "mnemo"?
<sveinung__> pitti: mnemo?
<pitti> sveinung__: "mnemo| sveinung__: which bugs is it?" and you pinged me
<sveinung__> aah
<sveinung__> pitti: sorry about that
<pitti> sveinung__: np :)
<sveinung__> mnemo: bug 345706
<ubottu> Launchpad bug 345706 in packagekit "CMake can't find QPackageKit by default" [Undecided,Triaged] https://launchpad.net/bugs/345706
<mnemo> sveinung__: i think you should just preapre the sru debdiff, fixup the bug according to the SRU guidelines and subscribe the SRU team so they can give you feedback on what they feel is necessary (and whether this bug is suitable for SRU)... I assume you have read: https://wiki.ubuntu.com/StableReleaseUpdates#When etc right? im not part of that team but to me a dev tools bug seems non-critical? isnt most of the dev work done on karmic anyway? im no
<pitti> Keybuk: *sigh* I committed another build fix to trunk, sorry; but this is the last one, it really works now
<Keybuk> pitti: pulled, merged, pushed
 * pitti hugs Keybuk
<sveinung__> mnemo: the fix is not in Karmic yet. Point 1 of the procedure say that it should be there first. So was if I should fix anything in the report to get it into Karmic I was wondering now. :)
<pitti> seems that "bzr-git" is really called "Keybuk"
<Chipzz> sveinung__: I think that what mnemo means is, SRUs happen occasionally rather than often.
<Chipzz> not just everything gets SRU'd; there needs to be a very good reason to make an SRU
<pitti> asac: I would be grateful if you could process bug 374844, since I wrote it, and it affects you most (with n-m)
<ubottu> Launchpad bug 374844 in udev-extras "Please move to main" [Undecided,New] https://launchpad.net/bugs/374844
<TheMuso> pitti: Lennart's plan is to drop hal support in the Fedora 12 timeframe. Without seeing their release schedule I am not sure what this is yet, but I do know they release later than us.
<pitti> asac: if possible, I'd like to get it into alpha-1, but if you are swamped, it's not that urgent
<asac> pitti: will do
<asac> will review today
<MacSlow> bryce, hey there
<ogra> seb128, oh, intresting now RB failed at a different point on armel ... seems it doesnt install libgnome2-dev, is there a build-dep missing somewhere ?
<TheMuso> 6/c
<ogra> Package libgnome-2.0 was not found in the pkg-config search path.
<ogra> Perhaps you should add the directory containing `libgnome-2.0.pc'
<directhex> ogra, missing comma perhaps?
<ogra> ... Package 'libgnome-2.0', required by 'GNOME Media Profiles', not found ...
<ogra> directhex, hmm, only on armel ?
<directhex> ogra, okay, it just hates you then
<ogra> oh, wait, i'm blind, it failed everywhere :P
<ogra> hrm, apart from i386
<ogra> now thats intresting :)
<seb128> ogra: it probably didn't pick the fixed gnome-media
<directhex> ogra, link to build log?
<seb128> https://edge.launchpad.net/ubuntu/+source/gnome-media/2.26.0-0ubuntu4
<seb128> indeed
<seb128> didn't build on armel
<ogra> ah
<lool> Hmm there's a weird issue in krb5
<seb128> https://edge.launchpad.net/ubuntu/+source/gnome-media/2.27.1-0ubuntu1 built now
<seb128> so a retry will do
<ogra> heh
<lool> It picked a bunch of deps on a bunch of arches
<lool> Depends: libkrb5-3 (= 1.7dfsg~beta1-4), libkadm5srv6 (= 1.7dfsg~beta1-4), comerr-dev, libk5crypto3 (= 1.7dfsg~beta1-4), libgssapi-krb5-2 (= 1.7dfsg~beta1-4), libgssrpc4 (= 1.7dfsg~beta1-4)
<lool> (that's lpia for instance)
 * ogra spends his day with RB retries, funny :)
<lool> on amd64 it's just:
<lool> Depends: libkrb53 (= 1.6.dfsg.4~beta1-5ubuntu2), libkadm55 (= 1.6.dfsg.4~beta1-5ubuntu2), comerr-dev
<directhex> ogra, well, you could score up the build of https://launchpad.net/ubuntu/karmic/+source/banshee/1.4.3-4 on arm ;)
<ogra> i'm not intrested in banshee atm :) .... A1 is my whole focus
<sveinung__> Chipzz: ok. My main consern was to get it into the development version. Any bug in my bugreport that reduses the chance for an upload to Karmic?
<lool> Ah no, I'm just stupidly looking at jaunty versus karmic
<lool> So it's just some bogus NEW
<seb128> james_w: ok, let's try there maybe then ;-)
<james_w> :-)
<lool> pitti: libkadm5srv6 is in universe, but libkrb5-dev depends on it (and is in main)
<ogra> lool, yeah there werte component issues the last week with karmic, might be another fallout of that
<lool> Oh it's not your day at all
<lool> slangasek, Riddell: libkadm5srv6 is in universe, but libkrb5-dev (in main) depends on it
<ogra> (things ended up in the wrong place after syncs or some such)
<seb128> does anybody knows if the original copyright holder has to be listed when translating code in an another languages?
<seb128> some people have been copying the tomboy code in c++, doing a line by line translation
<seb128> should the tomboy copyright holders still be listed?
<seb128> elmo: ^ do you know?
<lool> slangasek, Riddell: and libgssrpc4 as well
<lool> seb128: Yes, they do
<lool> seb128: It's really a derivative work
<directhex> seb128, my understanding is it's a very sticky situation, since it pretty much defines "derived work" - best practice should be "just include it, to remove ambiguity" IMHO
<lool> seb128: There was an LWN article on this case BTW :)
<seb128> lool: I should perhaps read LWN regularly ;-)
<lool> http://lwn.net/Articles/331187/
<seb128> directhex: right, it would be nicer for sure, we were wondering if that's a reason to not accept the upload though
<Riddell> seb128: new glib recently?
<seb128> Riddell: not yet, but coming soon, why?
<directhex> seb128, that's up to the archive admi... oh, right.
<lool> directhex: There's no doubt that automatically or manually translating code at this scale between languages is a derivative work  :)
<Riddell> seb128: actually, never mind
<Riddell> lool: one sec
<tkamppeter> pitti, I have investigated the GS segfault now, "ps2write" is not able to render test/testfile.pdf
<tkamppeter> gs -q -dNOPAUSE -dBATCH -dSAFER -sDEVICE=ps2write -sOUTPUTFILE=%stdout -dLanguageLevel=2  ../build-area/cups-1.3.10/test/testfile.pdf > x
<tkamppeter> segfaults.
 * ogra tickles lamont 
<pitti> tkamppeter: hah, that's what I meant with "high regression potential" :-)
<pitti> tkamppeter: do you think that's easily fixable, or should we rollback the patch for now?
<tkamppeter> pitti, when I return to pswrite the file gets correctly rendered. Seems that I have to work with the GS developers to get a correctly working PS output device. Seems that PS generation must be done by other for at least a year before we can take the software.
<pitti> tkamppeter: it seems that we keep switching backends (poppler, ghostscript, ps -> pdf), and this often leads to replacing old and understood bugs with new and untriaged bugs :-(
<Riddell> lool: done
<tkamppeter> Yes, finding that one filter solves one bug causes always another bug.
<Riddell> let me know if anything else needs fixing for that, it's breaking all the KDE builds too (and slangasek is on holiday)
<tkamppeter> pitti, GS developers are tending to switch to ps2write as standard PS output device. So perhaps we should support them by 1. reporting this bug, and 2. in Karmic stay with ps2write to collect more bug reports and so to tell GS developers what to fix.
<tkamppeter> pitti, if we get close to Karmic release and GS developers did not fix the reported bugs we go back to pswrite.
<pitti> tkamppeter: but if the test suite fails, we can't even build the package
<tkamppeter> pitti, the most important is to report all bugs upstream.
<pitti> and I'm reluctant to upload a known regression into debian sid, too
<directhex> seb128, at any rate, i absolutely cannot give advice on that particular decision for political reasons, just offer personal opinions. IANAL, YMMV, IDDQD
<tkamppeter> pitti, perhaps we can temporarily replace the test/testfile.pdf until GS developers fix this bug.
<pitti> tkamppeter: that would work for me
<pitti> tkamppeter: but I would like to see the test suite pass with some real pdf file
<pitti> tkamppeter: why not back out the patch entirely until it's fixed in gs?
<elmo> seb128: yes, they should
<lool> Riddell: Ok; will tell you if anything else shows up; how long does it take to be able to kick rebuilds?
<lool> Riddell: Will you mass give back?
<Riddell> lool: next publisher run, should be within the half hour I guess
<Riddell> lool: no I'm not a buildd admin
<ogra> elmo, pkern notified me that the new gobby version in karmic might have incompatibilities with the former gobby server (just a heads up in case we have karmic users at UDS)
<james_w> ogra: it's a new binary package name
<ogra> james_w, yes
<james_w> so they can just use the old one
<ogra> indeed
<ogra> still the new one is protocol incompatible he said but has undo :)
<lool> Riddell: ok thanks
<seb128> elmo: thanks
<pitti> james_w, jdstrand, seb128: did any of you run sync-source -a and flushed without NOMAILS=-M?
<james_w> pitti: ah, me, sorry
<pitti> james_w: NP, just a reminder
<seb128> pitti: not today, but when I that previous time it didn't email the list
<pitti> I saw that several times already, and wanted to send a reminder
<james_w> pitti: I'll remember for next time
<james_w> thanks
<seb128> pitti: I think NOMAILS is not required nowadays
<seb128> pitti: it seems that when you don't specify a -b login it doesn't email
<pitti> seb128: apparently it is, look at karmic-changes@ ?
<seb128> pitti: those are manual syncs
<pitti> seb128: sync-source.py -a doesn't use -b AFAIK
<pitti> oh really, that many?
<pitti> james_w: ^
<pitti> for manual syncs it's fine of course
<seb128> I've only 39 emails listed
<pitti> but over the weekend I got a bunch of like 80
<james_w> I did none over the weekend
<seb128> and I've the equivalent account in the ubuntu-archive list
<james_w> it was a long list of requests today though
<pitti> james_w: ok, sorry for the noise then
<james_w> good reminder though :-)
<seb128> I'm pretty sure that the list doesn't get mailed if you don't -b, I tried to figure why my syncs where not listed the other day
<seb128> and I figured that only -b ones are showing there
<james_w> yeah, they were all manual
<pitti> kees, asac: could either of you please process bug 369185 and bug 369191? they are an alpha-1 blocker
<ubottu> Launchpad bug 369185 in devicekit "include into main" [Undecided,New] https://launchpad.net/bugs/369185
<ubottu> Launchpad bug 369191 in devicekit-power "include into main" [Undecided,New] https://launchpad.net/bugs/369191
<pitti> (since g-p-m needs it now)
<tkamppeter> pitti, so I will take it out and report a bug to GS. Should I simply do another commit removing it or can you roll back the BZR to remove it?
<pitti> tkamppeter: just disable it in patches/00list and remove it from the changelog
<mterry> How do you leave comments or bug links in m-o-m?
<tkamppeter> pitti, seems that pdftops filters have still to mature. I would like to go Ghostscript as they seem to get forward more quickly with color management and they support files with more than one paper size ...
<asac> mterry: i think m-o-m is just read-only
<asac> what are you trying to do?
<mterry> asac: See https://merges.ubuntu.com/universe.html on the right side
<mterry> asac: Seems some people have noted that something is claimed or left a link to the bug for it
<asac> interesting ;)
<Keybuk> pitti: random non-udev-extras related question for you, as a security head
<Keybuk> why are people regenerating their gpg keys?
<Keybuk> I thought the problem was SHA-1, not DSA?
<Keybuk> you can use SHA-2 with DSA no?
<pitti> Keybuk: TBH I haven't even followed that incident, I just noticed people on planet.d.o and other places going crazy
<Keybuk> of course, more amusingly, isn't SHA-1 somewhat fundamental to git's operatio
<Keybuk> where changing from SHA-1 to something else is a "burn the archive"-level operation?
<broonie> It's not a realistic attack yet; for git you've got the added thing that since it's a SCM any replacement plaintext needs to be buildable source code too.
<tkamppeter> pitti, done. Now a CUPS build is not urgent any more, so if you have more important to do ...
<pitti> tkamppeter: ok, understood; yes, I have another pending patch from Martin-Eric, so I'll do an upload later then
<pitti> tkamppeter: thanks for having looked into that!
<Keybuk> broonie: which is what confuses me
<Keybuk> since surely for Debian, any replacement plaintext needs to be a valid changes file as well
<Keybuk> so why the OMG-level panic
<broonie> Keybuk: It's basically people overreacting, plus the idea that it'd be better to transition now rather than when it's an emergancy.
<cjwatson> Keybuk: nobody's saying "panic" AFAICS
<cjwatson> lots of people are producing lots of noise but I don't think it's panic
<Keybuk> cjwatson: "The general consensus is that we should be "moving in an orderly fashion toward the theater exits,"" is not exactly calling for calm
<directhex> it is compared to ARGH ARGH ALL PASSWORDS EVER COMPROMISED RUN FOR THE HILLS
<cjwatson> Keybuk: see Schneier's post on the subject; it's "walk, don't run"
<directhex> or "oh, oops, openssl is meant to have entropy isn't it"
<cjwatson> Keybuk: DSA keys can in theory use non-SHA-1 hashes, although (a) the original specification calls for SHA-1 (b) it's set at key generation time so if you want to change it you have to regenerate the key anyway *shrug*
<cjwatson> Schneier: http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
<cjwatson> Keybuk: and yes, of course collision weakness is not the same as a second-preimage attack, let alone a practical attack on real protocols where of course you need collisions to take a specified form; but it's a good early-warning sign
<Keybuk> but didn't one come up years ago anyway?
<Keybuk> about the time Debian started added SHA-256 to things?
<cjwatson> Keybuk: one thing most people miss is that collisions in hash functions are actually not all that much different from the original message, so I'm not sure the "real-protocol" defence is quite as strong as it looks
<cjwatson> Keybuk: this one is orders of magnitude better
<broonie> cjwatson: Well, you can issue new prefernces later on but ATM it's not possible to remove SHA-1 since the spec iwll insert it by default.
<cjwatson> broonie: I mean for the key itself
<cjwatson> the DSA key length is a function of the hash you choose at the start
<Keybuk> cjwatson: shouldn't the proper key ordering be gnupg defaults rather than requiring everyone to update, if it's a real problem?
<cjwatson> Keybuk: specifically, this one appears to be in the "$20K machine to crack in eminently practical time" range
<cjwatson> well, for "crack" => "find collision"
<geofft> broder
<geofft> gah, my client sucks. Ignore me.
<d1b> cjwatson: how much of that message can be modified ?
<cjwatson> Keybuk: the gnupg people are indeed in the process of changing the defaults
<cjwatson> d1b: which message?
<d1b> a potential message.
<cjwatson> how long is a piece of string?
<d1b> 4 yarns
<directhex> cjwatson, 18 inches
<d1b> i take it then that it is not currently know how effective the attack is then.
<d1b>  / how similiarthe collision version would be.
<cjwatson> taking a practical example, signed .changes files contain descriptions of the packages and of the changes made in that upload; lots of room for manoeuvre there
<cjwatson> d1b: do you know the difference between collision and second-preimage?
<d1b> cjwatson: no.
<cjwatson> this is a demonstration of collision weakness: in other words, the ease of constructing two messages from scratch with the same SHA-1 hash has been demonstrated to be on the order of 2%2
<cjwatson> err, "on the order of 2^52"
<cjwatson> an attack on a real cryptosystem would involve a second-preimage attack: in other words, constructing another message with a given SHA-1 hash
<cjwatson> collision resistance and second-preimage resistance are not the same, and this is about the former, not the latter. *However*, once collision resistance goes, it usually turns out that second-preimage resistance is not far behind
<cjwatson> so nobody is alleging a practical attack on real cryptosystems yet; what they are saying is that this is an alarm signal that sensible people would do well to pay attention to before the real alarms go off
<cjwatson> so yes, it is a bit silly for everyone to panic and change their keys over. On the other hand it takes a while to reestablish a web of trust and it probably makes sense to do that sooner rather than later.
<d1b> cjwatson: i don't follow how the second preimage is "not far behind"
<jdstrand> slangasek: re launchpad api> yes, I suppose that is true. I haven't looked at it too closely, but I assumed it was saving the info somewhere like a cookie that could be copied over.
<james_w> if it is possible to find a collision in reasonable time, then it is likely to be able to find a second preimage also in reasonable time
<cjwatson> d1b: e.g. http://eprint.iacr.org/2004/304.pdf
<tkamppeter> pitti, http://bugs.ghostscript.com/show_bug.cgi?id=690475
<jdstrand> slangasek: though, everyone is claiming just regenerating the lpcookie file should do it, so I guess I'll try... (odd that it works at home and not on cocoplum, but *shrug*)
<ubottu> bugs.ghostscript.com bug 690475 in PS Writer ""ps2write" segfaults on PDF file of CUPS test suite" [Major,Unconfirmed]
<pitti> tkamppeter: feel free to add that reference to the dpatch header
<cjwatson> briefly, as I understand it: if you can construct messages that collide, and then come up with a method for composing them, that forms part of a toolkit for attempting second-preimage attacks
<d1b> what about the recent development on prime numbers, does this affect the situation ?
<cjwatson> Keybuk: on SHA-1 and git: http://kitenet.net/~joey/blog/entry/sha-1/
<pitti> calc: ok, seems that all those -openoffice.org libs weren't as bad as I thought; it's by and large just package renamings
<cjwatson> d1b: which recent development is that?
<pitti> calc: so, sorry for freaking out a bit
<Keybuk> cjwatson: if collisions can be made relatively similar enough such that they satisfy a changes parser
<Keybuk> surely one can write colliding source that differs only in areas such as buffer bounds numbers?
<cjwatson> Keybuk: YM for git?
<Keybuk> you might not be able to sneak a web server into the code
<Keybuk> but you might be able to sneak in enough of a gap to use as your own backdoor
<Keybuk> cjwatson: indeed
<cjwatson> Keybuk: theoretically, yes. Nobody's yet demonstrated it but that means that now is the time to prepare rather than leaving it until it's too late
<Keybuk> I'd extend joey's example
<Keybuk> you commit the bad code to your git repo
<Keybuk> but you send the good patch to LKML
<Keybuk> with a note that you pull from the bad repo to get it
<Keybuk> people will review the good patch, but pull the bad patch
<Keybuk> the SHA-1 will match, so nobody knows what happened
<cjwatson> righ
<cjwatson> t
<tkamppeter> pitti, done
<calc> pitti: ok
<pitti> calc: I'm done with the bug now; they all need gcj->default-jdk conversion, and there are two FTBFS, but otherwise look alright
<calc> pitti: ok
<pitti> calc: I cleaned up the old packages while I was at it
<pitti> so duplication is basically null
<calc> ok
<pitti> asac: yay, thanks
<pitti> asac: I'll go ahead and disable keymaps in hal then, and add udev-extras to the standard platform seed
<pitti> Keybuk: ^ any objection?
<Keybuk> none
 * Keybuk does a little dance
<pitti> cool
<pitti> Keybuk: gvfs migration to devkit-disks is in our PPA, and g-p-m is converted in karmic
<pitti> so by now we dropped a fair bit of HALness
<Keybuk> why in the PPA? :p
<Keybuk> it'd be nice to get X moved from HAL to libudev
<pitti> Keybuk: the packages took a while to get built in karmic, only got them on the weekend
<Keybuk> that's probably one of the last pieces, no?
<Keybuk> evand was overjoyed that he could use devkit-disks for usb-creator
<pitti> and the gvfs-devkit thing has some major regressions still
<pitti> Keybuk: we still have pulseaudio, X.org input, pm-utils quirks at least
 * evand hugs pitti
<pitti> the former two are in the works, AFAIUI
<pitti> but I didn't see any discussion about suspend quirks
<tkamppeter> pitti, what about the SRU for foomatic-db-engine on bug 373371 and bug 361772?
<ubottu> Launchpad bug 373371 in foomatic-db-engine "Installation of Kyocera Mita FS-1020D failes with error: There was an error during the CUPS operation: 'server-error-internal-error'" [Medium,Fix released] https://launchpad.net/bugs/373371
<ubottu> Launchpad bug 361772 in foomatic-db-engine "black squares appearing instead of some letters when printing" [Undecided,In progress] https://launchpad.net/bugs/361772
<pitti> tkamppeter: I'll get to them, don't worry
<pitti> kirkland: please update screen's recommends: to screen-profiles
<pitti> kirkland: I'll move byobu to main and remove screen-profiles from karmic
<kirkland> pitti: i did
<kirkland> pitti: uploaded that this morning
<pitti> kirkland: ah, then I guess it just didn't build yet; thans
<ion_> pitti: Would it be possible to put all the devkit changes under a specific repository component in your PPA, so users could select the amount of potential breakage theyâre happy with? :-)
<kirkland> pitti: https://edge.launchpad.net/ubuntu/karmic/+source/screen/4.0.3-11ubuntu6
<pitti> ion_: it's in the ubuntu-desktop PPA, and it's just gvfs
<pitti> ion_: the rest is already in karmic
<pitti> ion_: also, there's nothing else worthwhile in u-desktop PPA ATM
<ion_> pitti: I see. I was thinking of stuff that may appear in the PPA in the future, though.
<seb128> the gvfs bits should lande to karmic soon since they have commited to upstream git now
<pitti> seb128: it still breaks the libgphoto backend
<pitti> and two smaller ones (cdda and another one I forgot)
<seb128> in which way?
<pitti> I'd miss libgphoto, though
<pitti> seb128: it doesn't build
<seb128> weird
<pitti> haven't spend much time on that yet
<seb128> I doubt FC11 will ship without that backend so they must have fixed it
<seb128> or do we need a newer libgphoto?
<pitti> seb128: might just be PEBCAK
<pitti> I'll get to it
<seb128> I can do a git build for the fun of it if you want
<seb128> and let you know if that builds here
<pitti> seb128: I built it from David's gvfs branch back then
<pitti> seb128: if it costs you nothing, sure :)
<geiseri_> hi, i am having problems with setting up custom partition recipes in the preseed file.  The partition looks right, but for some reason the installer is complaining that there is no root filesystem defined
<seb128> pitti: it's in gnome git now, I will give it a try
<pitti> perhaps they did some further fixes in the meantime
<pitti> seb128: I'll merge libgphoto now, we need to do that anyway
<geiseri_> did i miss a step? or is some more examples of how this works?
<seb128> pitti: ok thanks
<pitti> Keybuk: I guess you wouldn't hurt me if I merged libgphoto?
<pitti> (it's assigned to you ATM)
<cjwatson> geiseri_: need to see preseed file plus syslog
<cjwatson> geiseri_: this happens when something goes wrong in applying the partitioning recipe
<cjwatson> geiseri_: am I misremembering or did we not already discuss this last week or so?
<geiseri_> cjwatson: we discussed setting up the package sets, that i solved over the weekend with apt-move... this week is setting up the partition and im good to go :)
<geiseri_> let me bring up pastebin and ill get you the preeseed recipie
<kees> pitti: re: devicekit.  can you tell me quickly how it interfaces with the system?  aiui, hal listens for udev events, and rules pattern matches, adds stuff to the dbus tree, and sometimes runs helper scripts.  is that the same for DK?
<pitti> kees: DK itself is significantly simpler; it just provides a d-bus interface to the udev db
<pitti> kees: it doesn't store anything, nor read files etc.
<kees> pitti: ah, much nicer.  :)
<pitti> kees: it's all in the MIR
<Keybuk> pitti: I would not
<kees> yup, just read it now, and wanted to clarify.
<pitti> kees: DK itself will go away entirely at some point, but for now we need it
<cjwatson> this dpkg-vendor thing is nice
<kees> since the recent dbus and udev security glitches, I'm suspicious of anything near them.  ;)
<cjwatson> you can test 'dpkg-vendor --derives-from Ubuntu' or 'dpkg-vendor --is Debian' or that kind of thing
<kees> cjwatson: ooh, neato
<cjwatson> and (as of base-files 5.0.0ubuntu2, just uploaded) it knows that Ubuntu is a derivative of Debian
<geiseri_> cjwatson: http://rafb.net/p/GRfG7p20.html here is the section of the preseed file
 * geiseri_ is still trying to get syslog from qemu
<cjwatson> well, even before that, I see two syntax errors there
<geiseri_> cjwatson: oh good :\
<cjwatson> options/errors{errors=remount-ro} options/data{data=writeback}
<cjwatson> you need spaces inside the {} (so "options/errors{ errors=remount-ro } options/data{ data=writeback }")
<cjwatson> yes, the syntax is a bit strange
<geiseri_> ah, okay
<cjwatson> I don't know whether that's the problem here
<cjwatson> I'm also not sure partman actually supports options files like that but anyway :-)
<geiseri_> oh
 * geiseri_ can do some sedfu on the fstab as a post install if needed
<kees> pitti: is it possible for devicekit to use PR_SET_SECCOMP?  (see man prctl)  or does it need access to open() ?
<cjwatson> geiseri_: *probably* shouldn't matter for this purpose
<pitti> kees: I guess it open()s quite often through libdbus, but I have to check; perhaps you can ask that in the MIR bug? (busy ATM, sorry)
<pitti> kees: PR_SET_SECCOMP> interesting, I didn't know that one
<kees> pitti: well, I've approved it, but it's more of a curiosity.
<pitti> ah, thansk
<kees> pitti: yeah, just learned about it myself, which is why I've been posing that question to every service I can think of.  :)
<cjwatson> geiseri_: oh and delete your preseeding of partman-auto/init_automatically_partition
<kees> pitti: the answers tend to be "no".  :P
<geiseri_> cjwatson: okay
<cjwatson> probably irrelevant here but it is definitely confusing to have automatic partitioning preseeding and then also ask for manual partitioning at the same time ...
<pitti> kees: it might work, though, if it opens netlink and dbus sockets and then keeps them open
<pitti> kees: please post it anyway, I'll keep the mail to investigate
<geiseri_> ah, okay... i apologize i am still a bit fuzzzy on some of the parts so i am guessing
<geiseri_> cjwatson: im going to try the install run again with those changes...
<geiseri_> cjwatson: im assuming a single syntax error can cause the entire thing to abort?
<cjwatson> I'm happy to look at the syslog before that
<cjwatson> and it would probably be better if I looked at the syslog before that, since it may be none of these things
<cjwatson> it's possible
<cjwatson> error reporting isn't always quite brilliant, as you're discovering
<geiseri_> well syslog said nothing but starting partitioner
<geiseri_> is there a way to crank up the debug level?
<cjwatson> DEBCONF_DEBUG=developer can help
<cjwatson> as a boot parameter
<geiseri_> ah, okay
 * geiseri_ tries that too
<cjwatson> don't expect to be able to read it yourself though; it's best to pass the result to an installer developer
<geiseri_> :D with pleasure
<cjwatson> definitely needs to be read in conjunction with the code
<geiseri_> cjwatson: okay its booting up in qemu now, should have a syslog here in a minute or two...
<geiseri_> cjwatson: qemu is not a speed demon here
<ogra> The following packages have unmet dependencies:
<ogra>   udev: Breaks: dmsetup (<= 2:1.02.27-4ubuntu5) but 2:1.02.27-4ubuntu5 is installed
<ogra> E: Unmet dependencies. Try using -f.
 * ogra grumbles at Keybuk 
<kees> pitti: oh, btw, can I hand the sudo merge over to you?  I touched it late in the cycle, but am not too familiar with the standard ubuntu changes.
<pitti> kees: okay
<geiseri_> cjwatson: okay i am back at the error point.... what might be the best way to get the syslog off of here?
<pitti> kees: in exchange for sudo, would you mind looking at devicekit-power as well?
<kees> pitti: already done (and approved)  :)  (so, yes)
 * pitti hugs kees, thanks
<kees> :):)
<geiseri_> cjwatson: im doing something wrong here because its not even touching the partition table...
<ikonia> would it be appropriate to ask about the setup for how ssh/ssh-agent is intergrated into gnome for ubuntu, I can't find anything design related to it and I think there may have been a change between 8.10 and 9.04 ?
<pitti> kees: what would chroot()ing gain? just robustness against stupid programming errors?
<kees> pitti: yeah.  just random thoughts.
<kees> pitti: if it's easy to do, it's an easy benefit.  if it's not easy, ignore the idea.
<Keybuk> ogra: ?
<Keybuk> you're grumbling at me for saving your system from not booting?
<ogra> Keybuk, i dont care ... my livefs build chokes on it now
<ogra> (on armel)
<geiseri_> cjwatson: okay this i _think_ is the problem:  GETAGET full-disk description \n 10 full-disk doesn't exist... full-disk is the entry i put in my script
<geiseri_> could it be that i am still missing some information to cause it to use my recipe?
<maxb> byobu!?
<maxb> That seems possibly more weird than alsdorf!
<mterry> asac: woah!  To leave comments in m-o-m, you just enter text in an invisible text box in the comment column, press enter, and it updates.  Neat.
<ogra> whats wrong with alsdorf ? its an existing german village :)
<asac> mterry: omg
<mterry> Fancy
<maxb> Renaming screen-profiles to byobu seems a bit incongruous considering alsdorf got renamed to notify-osd :-)
<ogra> well, you surely avoid naming conflicts :)
<ScottK> Between byobu and ayatana, there may well be a random word generator involved.
<maxb> Feels that way :-)
<maxb> Perhaps they're naming projects using pwgen :-)
<pitti> ScottK: or Mark learning Japanese
<ScottK> Could be.
<mterry> asac: Added comment in wiki (UbuntuDevelopment/Merging) about it; it's useful but not discoverable
<cjwatson> geiseri_: go back to the main menu and select "Save debug logs"
<cjwatson> geiseri_: or, if you prefer, switch to tty2, 'anna-install openssh-client-udeb', and use scp
<geiseri_> oh i like scp, let me try that
<maco> pitti: gjiten doesnt recognize ayatana as a japanese word
<geiseri_> cjwatson: May 11 16:21:30 debconf: --> SET partman-auto/disk      /dev/sda \n May 11 16:21:30 debconf: <-- 10 partman-auto/disk doesn't exist
<geiseri_> this looks telling
<geiseri_> but fdisk sees it as /dev/sda
<cjwatson> geiseri_: I really can't deal with fragments of the syslog like this; I need the whole thing
<cjwatson> geiseri_: I think it's likely that you're misreading normal behaviour
<cjwatson> it's normal for questions not to exist when they're initially preseeded
<geiseri_> cjwatson: okay, sorry, give me a minute, as rfab.net is choking on it....
<cjwatson> geiseri_: paste.ubuntu.com?
<geiseri_> ah, i was using the kde one
<geiseri_> cjwatson: http://paste.ubuntu.com:80/169797/
<geiseri_> cjwatson: that is the entire syslog
<cjwatson> geiseri_: this syslog doesn't match the preseed file you gave me earlier; it says you set partman-auto/method to "manual" (which is wrong) instead of the correct "regular"
<geiseri_> oh i used the wrong file... sorry :(  one sec
<geiseri_> i have too many copies of these damn files rolling around
<geiseri_> cjwatson: okay, here is the preseed code again (http://paste.ubuntu.com:80/169827/) if i run this it keeps creating a root partition but also a swap partition, that i dont want...
<geiseri_> but other than that it keeps going correctly
<cjwatson> geiseri_: can I have the syslog again?
<cjwatson> (preferably with DEBCONF_DEBUG=developer if you have it)
<geiseri_> okay, let me spin up the vm with that flag in the boot line...
<geiseri_> cjwatson: here is the mess: http://paste.ubuntu.com:80/169834/ for the preseed file i posted.
<geiseri_> cjwatson: its almost correct save for the problem that its adding swap when i dont want it too do so
<cjwatson> "Expert recipe too large (523837440 > 2147); skipping"
<cjwatson> so it isn't using your recipe because it declares that it needs 523 TB of disk space and you only have 2 GB
<geiseri_> doh
 * geiseri_ must have calculated the offset wrong...
<cjwatson> geiseri_: remember that the first field is a minimum
<cjwatson> surely you can just make it relatively small and let partman automatically grow it
<cjwatson> and the sizes are in megabytes
<geiseri_> okay, that makes a few things make sense :)
<geiseri_> will it make sure its the size of the base install?
<cjwatson> TheMuso: are you likely to have a brltty merge available soon? I ask because it's one of the packages that still require libicu38 rather than libicu40, and those two packages are each very big
<geiseri_> my ideal is that it creates 1 partition the entire size of the disk...
<cjwatson> geiseri_: no, but if you only have one partition in your recipe it will use the whole disk for it anyway
<geiseri_> k
<cjwatson> I don't think partman actually *can* leave free space right now :-) It'll give up if you try to force it to do so
<cjwatson> (this is a bug ...)
<geiseri_> okay, i can live with that constraint
<geiseri_> cjwatson: okay that worked, but now it asks me if i want to keep going without swap space..... can i look in the syslog to see what d-i field that is?
<geiseri_> afaik it should be partman-basicfilesystem/no_swap boolean true?
<ion_> keybuk: libdbus-1-3 1.2.14-2ubuntu3 causes hal to hang on startup. I didnât get around to testing whether other dbus programs have problems as well. Installing libdbus-1-3/jaunty made the system work again. Is this known, or should i investigate more and report at launchpad?
<Keybuk> ion_: probably a bug ;)
<ion_> No kidding :-)
 * Keybuk has had it installed for ages without encountering it though
<ion_> I guess iâll investigate further.
<Keybuk> almost certainly the timeout patches
<Keybuk> dunno whether davidz has code in HAL to expect them that he hasn't tested
<Keybuk> (using INT_MAX was his original idea)
<Keybuk> indeed, I can see two instances of that in the source
<Keybuk> so it's likely david has pre-empted a timeout-less D-Bus without testing ;)
<Keybuk> ion_: I'd wager it's blocking inside hald_runner_run_sync() ?
<geiseri_> cjwatson: sweet everything seems to be working now!
<geiseri_> cjwatson: thanks a ton for your help
<cjwatson> geiseri_: yes, partman-basicfilesystem/no_swap is correct. Glad it works for you now
<Keybuk> ion_: can you think of an example of another HAL service?
<ion_> keybuk: What do you mean?
<Keybuk> ion_: other than HAL that is hanging?
<ion_> keybuk: Ah. I didnât get to investigating the issue yet. As soon as i do, iâll try various dbus services.
<Keybuk> HAL seems to get to the main loop for me
<Keybuk> but then simply doesn't accept connections
<Keybuk> empathy/telepathy seem to work
<chrisccoulson> hey mbiebl - you there?
<chrisccoulson> kees - good spot on the vala MIR - thanks
<chrisccoulson> i just noticed from the latest build log that one of the tests does fail
<kees> chrisccoulson: cool
<chrisccoulson> i'll take a look at sorting that over the next few days. might need some help though, although i suppose i could start by looking at some other packages with test suites
<calc> pitti: i have all of the packages except pentaho fixed and uploaded
<hyperair> does anyone know why the kernel method of suspend/hibernate is preferred over uswsusp?
<hyperair> it seems to me that the kernel method is considerably slower than uswsusp.
<pace_t_zulu> I have a question regarding PPA in Launchpad... is this the right place to ask it?
<maxb> pace_t_zulu: #launchpad or #ubuntu-motu
<Keybuk> hyperair: probably because it works
<hyperair> Keybuk: don't both "just work"?
<DarkRavin> can anybody tell me why everytime i click on places and click on pictures and it opens my music player
<seb128> because you associated the player with directories
<DarkRavin> how do i fix it
<seb128> what ubuntu version do you use?
<DarkRavin> the new one i just upgraded but it started from the first time i installed 8.xx
<Keybuk> ion_: I assume it was only libdbus that you needed to change?
<ion_> keybuk: Yep
<DarkRavin> where do i find nautilus properties
<ubuntuwin> ciao raga
<DarkRavin> why does my folders say root is owner
<ubuntuwin> ciao DktrKranz
<DarkRavin> it wont let me make changes because of it
<ubuntuwin> come faccio a firmare un pacchetto generato con debuild -S -sa?
<ubuntuwin> la firma l'ho creata con gpg
<mbiebl> chrisccoulson: hi
<Keybuk> ubuntuwin: you will be unlikely to get an answer here unless you ask the question in English, also note that this is not a support channel so you may wish to try #ubuntu or #ubuntu-it
<mbiebl> chrisccoulson: you pinged an hour ago?
<ubuntuwin> how can I sign a packet generated with 'debuild -S -sa'?
<ubuntuwin> i've made a key with gpg
<chrisccoulson> mbiebl - hi. i'm currently looking at packaging a snapshot of tracker from git master in karmic at the moment
<mbiebl> oh, is master usable already?
<chrisccoulson> they've changed the library versioning in 0.7.x, and i was just wondering if you plan to change some of the package names in debian when you do the 0.7.0 update
<mbiebl> I tried a week ago, and it crashed immediately
<Keybuk> ubuntuwin: "debsign"
<chrisccoulson> i've been told master is sort of useable, but it doesn't matter too much at this stage. i'd like to try and get it in quite early, to avoid some of the issues we had with 0.6.9x (where we introduced it within the last few weeks of the jaunty cycle)
<chrisccoulson> mbiebl - the libraries in tracker are now versioned similar to gtk
<mbiebl> chrisccoulson: Yeah, I think of renaming the library packages to match the soname
<chrisccoulson> i was going to rename libtracker-gtk0 to libtracker-gtk0.7-0
<chrisccoulson> is that what you were thinking?
<chrisccoulson> the library so files are now libtracker-gtk-0.7.so.0.0.0 as opposed to libtracker-gtk.so.0.0.0 i think
<mbiebl> I would have used libtrackerclient-0.7-0 and libtracker-gtk-0.7-0, as that is the scheme we use in dbus(-glib)
<mbiebl> but libtracker-gtk0.7-0 would be ok too.
<chrisccoulson> mbiebl - that makes sense too
<LLStarks> pitti. you here? hal is in real bad shape on karmic right now.
<mbiebl> It's mostly a matter of personal preference
<chrisccoulson> i only suggested libtracker-gtk0.7-0 as that is how the gtk packages are named
<chrisccoulson> it's up to you then. i'd like to name them the way you intend to do it in debian
<chrisccoulson> LLStarks - pitti is finished for the evening i think
<chrisccoulson> what's wrong with hal?
<mbiebl> I prefer the additional dash as, but have no strong opinion either way
<LLStarks> prevents boots and hal initialization on karmic
<LLStarks> with latest 2 updates
<chrisccoulson> mbiebl - i can add the dash - that's no problem.
<ion_> chrisccoulson: Install libdbus-1-3 from jaunty to get a working system while waiting for the fix.
<LLStarks> it's a huge break
<chrisccoulson> mbiebl - it won't get updated for another week or so as it is currently blocked on promoting another package in to main, but i'll use that time to get the package ready anyway
<mbiebl> chrisccoulson: I'm wondering if we should also version the -dev packages.
<chrisccoulson> i was going to do that in the same way - libtracker-gtk-0.7-dev i think
<mbiebl> Apparently the API will be completely different, so packages will need sourceful changes.
<mnemo> my karmic computer just broke as well.... hal failed to install and now it won't boot anymore... when I run "netroot" and try to reinstall hal it says it can find .../run/dbus/system_bus_socket something
<mbiebl> chrisccoulson: yeah, sounds ok
<Keybuk> mnemo: well, if you will run karmic
<mnemo> yea I know its not a problem, I just wanted to let you know in case you want to block the update or so
<ion_> llstarks, mnemo: See my previous message.
<Keybuk> mnemo: it's karmic, we don't block updates there
<mnemo> ah ok
<mnemo> ion_: oh.. thanks
<chrisccoulson> mbiebl - i'm not too worried about API change - there's currently no other packages in the archive that depend on the tracker libraries
 * Keybuk has already tracked down the HAL bug
<chrisccoulson> actually, totem-plugins depends on libtrackerclient
<ion_> keybuk: Cool
<Keybuk> just haven't figured out whether it's HAL misbehaving or D-Bus
<mbiebl> chrisccoulson: don't you also build nautilus with tracker support on ubuntu?
<Keybuk> HAL is asking for an infinite timeout, and the new D-Bus gives it that
<chrisccoulson> i didn't even know there was a HAL bug. should i try and reboot to find out? ;)
<LLStarks> ion thx
<Keybuk> what I'm not sure about is why this method call never completes as a result
<chrisccoulson> mbiebl - we disabled the tracker support in nautilus
<Keybuk> iz probably bug
<mnemo> seems libdbus-1-3 was already installed on my system and install hal still wont work.. anyone got any other ideas for working around it?
<LordKow> yay thank you libvolumeid is gone forever
<chrisccoulson> users expect the nautilus search to just look at filenames, and the tracker results confused a lot of users
<Keybuk> mnemo: you need the libdbus-1-3 from jaunty, not from karmic
<Keybuk> LordKow: well....  kiiiinda
<mnemo> ah ok
<Keybuk> LordKow: libblkid now mostly consists of libvolume-id's old code
<Keybuk> LordKow: so it's not so much dead as moved into a different body
<mbiebl> chrisccoulson: I've played around with tracker 0.7 some time ago
<mbiebl> Maybe you can use the debian/ I sent you as a starting point
<Keybuk> mnemo: it's the -0ubuntu3 that seems to be specifically upsetting HAL
<chrisccoulson> mbiebl - thanks. the transfer hasn't started yet though. not sure if that's an issue with my router or not
<Keybuk> ironically this is because the HAL author wrote the code expecting the behaviour that the patches in D-Bus 0ubuntu3 finally, years later, provide
<mbiebl> chrisccoulson: I'll send you an email...
<chrisccoulson> mbiebl - thanks:)
<mbiebl> chrisccoulson: stupid gmail. It rejects the tarball because it contains a executable (debian/rules)...
<chrisccoulson> that's a pain. i didn't realise gmail was that clever
<mbiebl> chrisccoulson: do you have another email addy?
<chrisccoulson> i have my work e-mail address bug i'm pretty sure that will reject it too. the filters on that are failry strict
<mbiebl> ok, I'll just chmod -x and retar it then
<chrisccoulson> thanks:)
<chrisccoulson> if it were a few weeks ago i'd still have a server here i could just let you ssh in to
<lool> kees: How many rebuilds are there for FORTIFY?  I'm a bit worried that the buildds are already lagging and we need to build /something/ for A1  :)
<mbiebl> chrisccoulson: email should be out
<chrisccoulson> mbiebl - thanks. i'll take a look at that over the next day or so
<kees> lool: it was just a short list.  I personally rebuilt them all in about 45 minutes.
<lool> Ok, fine then
<kees> lool: "zip" would mark the end of them.
<kees> lool: though "zip" is not a no-change rebuild.
<hyperair> does anyone know where i can find (if any) usplash api documentation? i'm referring to the C documentation, not usplash_write's interface.
<maxb> Speaking of usplash, is it dying with a "general protection" message for anyone else on Karmic?
<doko> kees: wow! xfonts-75dpi did gain fortify defaults!
<lool> Yeah, the chars have a small square drawn around each glyph
<Keybuk> ion_: basically it looks like the pending call for the pm-is-supported runner never "completes"
<Keybuk> it doesn't help that whenever I compile this, the line numbers don't match up in gdb
<kees> doko: yeah, my ELF-finder glitched on a few
<ion_> keybuk: Heh
<Keybuk> ion_: I'm going to assume there's a bug in D-Bus causing this
<Keybuk> since HAL appears to be basically correct
<Keybuk> it uses INT_MAX because it doesn't mind how long the runner takes
<Keybuk> so in this case, INT_MAX should mean "forever"
<Keybuk> and that's when it hangs
<Keybuk> oh...
<Keybuk> this may be one of those "the patch keybuk uploaded wasn't the patch keybuk tested" issues
<Keybuk> yawp
<Keybuk> the patch I put into the package is not the patch in git
<Keybuk> and is not the one I've been testing for the best part of the year
<Keybuk> la la la
<seb128_> Keybuk: btw do you plan to ever review the patch on bug #258491?
<ubottu> Launchpad bug 258491 in libtool "link_all_deplibs=no patch no longer working well" [Medium,Confirmed] https://launchpad.net/bugs/258491
<seb128_> Keybuk: would be nice to get it off the sponsoring list either way, ie apply or unsubscribe the team and add a comment
<Keybuk> it's a complex path
<Keybuk> I've been on/off testing/reviewing it for ages
<walters> Keybuk: you shipping the timeout stuff now?
<Keybuk> walters: yes
<Keybuk> walters: I was going to nag you about whether I could just commit to to trunk ;)
<walters> Keybuk: i think it's probably right, rereading the thread again
<Keybuk> walters: it's still the client's choice, after all - the default timeout is still low
<walters> Keybuk: are there no changes since the patches attached in bugzilla?
<Keybuk> you have to give very large numbers, or INT_MAX, as a timeout
<Keybuk> walters: there's one change to the first one
<walters> Keybuk: can you attach then and say what changed?
<Keybuk> which ironically is the very bug hit today - I applied the patches from the ML not the patches that worked <g>
<Keybuk> walters: which bug# was it?
<walters> Keybuk: http://bugs.freedesktop.org/show_bug.cgi?id=16841
<ubottu> Freedesktop bug 16841 in core "Patches to allow NULL timeout for pending call" [Normal,Assigned]
<Keybuk> ah yes
<Keybuk> I'll reattach the first one
<walters> cool
<walters> Keybuk: did you have any thoughts on testing?  we should have at least one test call where we pass INT_MAX, and maybe just timeout after 5 seconds or something for the test suite
<walters> Keybuk: so there's at least some exercise of the code path
<Keybuk> walters: that seems reasonable
<dazjorz> So this is the place to talk about huge breakage in karmic if it's not already known?
<dazjorz> :)
<Keybuk> no
<dazjorz> #ubuntu+1 doesn't seem like the place, too
<dazjorz> or is it?
<Keybuk> #ubuntu+1 may be appropriate
<ienorand> dazjorz: it is, hal issues?
<Keybuk> this is the place to talk about the patches you're writing to fix the huge breakage you found ;)
<dazjorz> well
<dazjorz> I don't have patches, but I do have solutions
<dazjorz> does that do? :)
<dazjorz> ienorand: not only that
<Keybuk> it depends on your solution
<dazjorz> also KDE package breakage
<dazjorz> kde-icons-oxygen: trying to overwrite `/usr/share/icons/oxygen/16x16/status/meeting-organizer.png', which is also in package libkdepim4
<Keybuk> if your solution is "zomg! karmic is broken! go back to jaunty versions" then no, that's not really helpful
<Keybuk> dazjorz: file a bug?
<dazjorz> only that one isn't that easy - earlier, kdelibs5 would conflict with libplasma-dev, uninstalling libplasma-dev fixed it, but kdelibs5 doesn't Conflict with libplasma-dev
<dazjorz> I filed that, and a fix was committed; weird that the original maintainer didn't even know
<Keybuk> not especially
<Keybuk> our maintainers test things more often than not :p
<dazjorz> Keybuk: don't worry, any solutions I will bring up won't be braindead
<Riddell> "would conflict...doesn't conflict" I don't follow
<dazjorz> conflict without a capital c: conflict in theory
<dazjorz> Conflict with a capital c: have that package as a conflicting package in debian/contro
<dazjorz> l
<dazjorz> or, conflict in practice, actually
<ion_> Iâd call ubuntu-minimalâs postinst calling rm -fr / âhuge breakageâ. Itâs a development version. A package here and another there is expected to break every once in a while. :-)
<dazjorz> Keybuk: the thing about bugreporting things like kde-icons-oxygen conflicting with libkdepim4 is
<dazjorz> Keybuk: it's so *obvious* the new package won't install, the maintainer *must* already know :/
<dazjorz> so why bother to file a bug anyway
<Keybuk> dazjorz: hah
<Keybuk> the maintainer clearly doesn't know
<Keybuk> otherwise they wouldn't have uploaded it in the first place
<dazjorz> maybe it wasn't uploaded at the same time, or something
<dazjorz> I mean
<Keybuk> file a bug anyway
<dazjorz> maybe it was uploaded, then the other package uploaded at the same time, causing both maintainers to think everything was OK, when in fact it wasn't
<dazjorz> okay, will do
<Keybuk> at the very least, it gives the QA team something to do
 * dazjorz wonders why apport didn't pop up with "Package foo failed to install!" yet, usually it does that
<dazjorz> https://bugs.launchpad.net/ubuntu/+source/oxygen-icons/+bug/374348
<ubottu> Ubuntu bug 374348 in oxygen-icons "package oxygen-icons failed to install" [Undecided,Invalid]
<dazjorz> Yeah, yeah. The rest of KDE needs upgraded to KDE 4.3 beta. At this point bug reports would be counterproductive.
<dazjorz> ooh, updating to 4.2.85, that makes sense, the 4.3 beta
<Keybuk> well, it is karmic
<dazjorz> yep - we just need to wait until the upload of kde 4.3 is done, I guess
<TheMuso> cjwatson: oh right. I hadn't seen that pop up. I'll make it top priority for this morning.
<dazjorz> [00000496] alsa audio output error: cannot write: Broken pipe    # another sign of the HAL problems, isn't it?
<dazjorz> by the way: is there a way to get apt to completely ignore the current breakage of the system, and still do what I ask it to do? I read the manpage, tried some options, but it's still begging me to run -f
<TheMuso> cjwatson: actually there is no merge available, but I can do a rebuild to use the newer library.
<directhex> evand1, ping
<cjwatson> TheMuso: oh, right, I misread rmadison's output or else I'd have just done a simple rebuild myself - sorry to bother you about that
<TheMuso> cjwatson: np
* Keybuk changed the topic of #ubuntu-devel to: Archive: open for development! | dbus 1.2.14-2ubuntu4 fixes HAL not starting in karmic | 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
<dazjorz> Keybuk: is there a deb yet? :)
<dazjorz> it's not on packages.ubuntu.com, anyway
<ajmitch> packages.ubuntu.com is often a little out of date
<Keybuk> no, and we can't stop for ice cream
<dazjorz> any sources link ?
<dazjorz> http://packages.ubuntu.com/source/karmic/dbus still shows -2ubuntu3, and modifying the download URL doesn't work, it doesn't seem to be on the mirrors yet
<Keybuk> shees
<Keybuk> do they not teach patience these days?
<Keybuk> the upload process takes between one and three hours
<Keybuk> after which sources, and if you're lucky, binaries will appear
<Keybuk> after that, mirrors update whenever they feel like it
<Keybuk> in practice, within an hour or so
<dazjorz> I just figured if there was an URL to get the new .diff.gz and .dsc, you'd be the one to know
<dazjorz> or, anyone else in this channel, for that matter
<directhex> has someone done something funny with apache2 on lpia/armel? i got a ftbfs for mod-mono
<cjwatson> if it's not on Launchpad then it isn't sufficiently published yet for there to be any such URL
<Keybuk> /home/scott/work/drive-by/dbus_1.2.14-2ubuntu4.dsc
<Keybuk> that's the URL I have ;)
 * dazjorz ssh scott@that-machine
<cjwatson> actually though you just aren't looking in the right places. start at https://launchpad.net/ubuntu/+source/dbus
<ajmitch> Keybuk: fwiw, LP is showing build failures for -2ubuntu4 so far, failing to apply the patch
<maxb> All of the buildds except lpia are a bit backlogged at the moment anyway
<Keybuk> ajmitch: really?
<Keybuk> that's vexing
<dazjorz> cjwatson: right... thanks
<directhex> Keybuk, computers are vexatious.
<ajmitch> Keybuk: at least on lpia, i386 is still sitting on currently building
 * dazjorz remembers that
<Keybuk> typically it's the patch that adds the tests ;)
<TheMuso> hrm i386 FTBFs as well.
<dazjorz> patches fine here
<Keybuk> hah
<Keybuk> I bet it's complaining about .gitignore
<cjwatson> looks like it
<Keybuk> *sigh*
 * TheMuso chuckles
<Keybuk> my life would be so much easier if the bzr developers were killed in a freak unit testing accident
#ubuntu-devel 2009-05-12
* Keybuk changed the topic of #ubuntu-devel to: Archive: open for development! | dbus 1.2.14-2ubuntu5
<Keybuk> and I've tested these ones
<Keybuk> not just tested something I thought I uploaded
<Keybuk> or even tested the build from the package directory
<Keybuk> this time I made the source package
<Keybuk> then unpacked it somewhere else
<Keybuk> and built debs out of it
<lifeless> Keybuk: ?
<Keybuk> then installed those
<Keybuk> and then started HAL
<Keybuk> lifeless: having to do everything simultaneously in git and bzr causes me great pain
<lifeless> Keybuk: latest bzr-git can push to git quite well
<Keybuk> wing-commander scott% apt-cache show bzr-git
<Keybuk> W: Unable to locate package bzr-git
<Keybuk> E: No packages found
<Keybuk> lifeless: FAIL
<Keybuk> and, honestly, that doesn't help
<Keybuk> no matter how good bzr-git gets, it'll go wrong and do strange things on a roughly daily basis
<Keybuk> so I'll still need to know and use git directly anyway
<Keybuk> so I may as well use git, since then I don't have to double-check for doofusness after every command
* cjwatson changed the topic of #ubuntu-devel to: Archive: open for development! | dbus 1.2.14-2ubuntu5 fixes HAL not starting in karmic | 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
<Keybuk> oops ;)
<Keybuk> * karmic i386   Successfully built  (ACCEPTED)
<Keybuk> \O/
 * Keybuk goes to bed before he can do any more damage
<chrisccoulson> ogra - you there?
<cody-somerville> Is there a channel where debian developers hang out?
<ajmitch> #debian-devel on oftc
<TheMuso> lifeless: you know, if its hpa related, having that handy as opposed to users having to twiddle modprobe options seems more sane.
<TheMuso> In any case, will test your patch this morning after email processing.
<cody-somerville> ajmitch, Is there an easy way to determine a DD's IRC nick?
<james_w> cody-somerville: db.debian.org has some
<lifeless> TheMuso: indeed
<lifeless> TheMuso: I wonder if there is a libhpa
<TheMuso> lifeless: Not that I know of.
<lifeless> google agrees
<TheMuso> Yeah, I just searched myself.
<Guest75430> helll
<Guest75430> o
<doko> directhex: contentless pong
<lifeless> TheMuso: you might want to forward my mail to ataraid; as the list moderator seems not to be moderating in a timely manner
<TheMuso> lifeless: ok will do. BTW it seems there is an implicit declaration of ISW_10_CONFIGOFFSET. Not sure whether you meant ISW_CONFIGOFFSET instead?
<lifeless> TheMuso: no, its a new define
<TheMuso> lifeless: ok well the patch you linked to in your mail doesn't define it
<TheMuso> the build fails with that being pointed to...
<lifeless> wtf where did my header go
<lifeless> grab the source package from my ppa
<TheMuso> ok thanks
<williamd> are you guys really advanced programmers?
<lifeless> it varies
<lifeless> TheMuso: quilt fail. no idea why
<lifeless> 1.0.0.rc15/lib/format/ataraid/isw.h is internally patched
<TheMuso> lifeless: I also see that some of your patch is directly in the .diff.gz. :)
<TheMuso> yep
<lifeless> TheMuso: I'm just attaching a fixed version
<TheMuso> lifeless: ok, but I've manually fixed here anyway.
<lifeless> TheMuso: sure, I've attached new diff.gz and dsc anyhow
<TheMuso> ok
<maxb> What is the current publisher cron schedule?
<cjwatson> maxb: 03 * * * * LPCONFIG=ftpmaster /srv/launchpad.net/codelines/current/cronscripts/publishing/cron.publish-ftpmaster security
<cjwatson> maxb: hasn't changed in years, FWIW
<willintel> check out my name
<cjwatson> willintel: this isn't a chat channel
<willintel> no
<willintel> if it is then I am the op
<lifeless> willintel: this channel is for development of Ubuntu; if you are here for that great. If you are here for some other reason, perhaps a different channel would suit you better.
<cody-somerville> Anyhows
<cody-somerville> james_w, Figured out that problem :)
<cody-somerville> james_w, *.files instead of *.install
<lifeless> cody-somerville: what was the issue?
<cody-somerville> lifeless, Nothing was getting installed into the binary packages
<lifeless> you were calling dh_install?
<cody-somerville> Yup
<lifeless> thats...odd
<cody-somerville> dh_install likes <pkg-name>.install files instead of <pkg-name>.files
<cjwatson> .files was for the older dh_movefiles command
 * cody-somerville nods.
<cjwatson> which had the defect that it wasn't idempotent
<willintel> cool
<TheMuso> woops didn't mean to do that
<willintel> I am learning to take user input and integrate it into my programming
<lifeless> cody-somerville: oh, you had *.files rather than *.install?
<lifeless> cody-somerville: I read your statement as 'I moved to *.files and it worked'
<lifeless> cody-somerville: which is why I was puzzled
<cody-somerville> lifeless, ah :]
<lifeless> TheMuso: so, did it work ?
<TheMuso> lifeless: works fine for me for ICH9.
<lifeless> cool
<willintel> is there a way to make IRC chat go through the console?
<directhex> that's a #ubuntu question
<willintel> directthex
<willintel> that is harsh
<willintel> noone else is talking
<TheMuso> woo! esound syncable from Debian after quite a while with Ubuntu changes. :)
<TheMuso> lifeless: ok, will push your patch to Debian first. I can make an Ubuntu upload for karmic if you really want it now, otherwise it will come accross with the next sync I do from Debian.
<calc> can i get someone to approve liblayout-openoffice.org its NEW
<slangasek> doko: yuck, ppl wants xpdf in main; why exactly do we need ppl?  its description doesn't seem like something gcj should need...
<lifeless> TheMuso: thats fine; I'm on jaunty anyhow
<lifeless> TheMuso: if you want to wait for tomorrow, I'll add bounds checking to the patch
<TheMuso> lifeless: Ok. I do think there are grounds to SRU this for jaunty, so will likely do that as well./
<TheMuso> lifeless: Sure, I can wait, thanks.
<pitti> Good morning
<pitti> calc: wow, nice!
<pitti> ugh, hal broken? was working fine for me yesterday, but I didn't have the new d-bus yet
<dholbach> good morning
<pitti> Keybuk: hm, the new udev removes cryptsetup dmsetup mdadm
<pitti> that'll break the server CDs seriously
 * pitti moans at http://people.ubuntu.com/~ubuntu-archive/testing/karmic_probs.html
<pitti> yesterday night's uploads broke a lot :(
<ajmitch> pitti: there are a few more broken packages than just those, too
 * ajmitch spotted 1 or 3 that failed to build because of dependencies at the time, but not on all archs
* pitti changed the topic of #ubuntu-devel to: Archive: soft freeze for Alpha-1 | 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
<ajmitch> pitti: darn, so I can't upload some merges now? :)
<TheMuso> /c/c
<pitti> ajmitch: if they don't render packages uninstallable, it's fine
<ajmitch> pitti: just apache2 & squid, apr-util will need a giveback on i386 before apache2 can build though
<ajmitch> apart from that the packages appear to work on amd64
<pitti> ajmitch: well, just don't break it :)
<ajmitch> I'll try hard not too :)
<dholbach> didrocks: that could fix the problem: https://bugs.edge.launchpad.net/ubuntu/+source/cdbs/+bug/374892
<ubottu> Ubuntu bug 374892 in cdbs "Use correct root path when converting dist- to site- in arch packages" [Undecided,New]
<dholbach> doko, pitti: ^ does this look sensible to you?
<didrocks> ok then, let me read ;)
<didrocks> I think that pitti can confirm, he saw me suffering on it :)
<dholbach> if the patch works, please sponsor it
<dholbach> I need to take the dog for a walk now :)
<didrocks> ok, see you later dholbach (You won't in Paris: it's raining ;))
<dholbach> didrocks: it's beautiful here
<dholbach> sun is shining :)
<didrocks> lucky you :)
<pitti> didrocks: does it work for you? I can't tell if it's sensible by just looking at the patch, I'd need to look what the current variable means exactly, etc.
<pitti> calc: erm, hang on
<pitti> calc: if I promote the lib*openoffice packages now, won't that pull openjdk onto the CDs?
<pitti> calc: I'm afraid we can't do that right now, CDs are already oversized by a dozen MB, and we need to release alpha-1 in two days
<pitti> calc: also, OO.o is largely uninstallable right now
<pitti> calc: ah no, I guess our installed gcj will satisfy java2-runtime-headless
<pitti> calc: so, ignore me
<directhex> TheMuso, why is anything to do with esound a cause for celebration? o_o
<pitti> directhex: its removal would be
<directhex> pitti, how about the only copy of the source being shot into the sun?
<pitti> *chuckle*
<seb128> can we do the same for banshee? ;-)
<directhex> seb128, no, it's in git. hard to track down the last copy of the source
 * pitti steps back from the flamewar gauntlet
<seb128> ;-)
<seb128> I just start being annoyed by people trying to fanboy banshee on random not good arguments
<seb128> ie CD space win for example
 * pitti hugs RB
<lifeless> RB needs to learn gio now that places doesn't use gvfs
<lifeless> or whatever disconnect is going on there
<didrocks> pitti: it may be related. Compiling the previous revision today make it available to pyshared too. Let me test the patch.
<directhex> lifeless, i thought they fixed that recently
<lifeless> directhex: perhaps; not in jaunty which is my production DE
<directhex> seb128, i think said win disappears anyway once you add missing things like "docs". but it's interesting that there's no visible net loss. thanks to dropping two recommends to suggests in 1.4.3-4
<seb128> right, which means it's not really an argument in this discussion
<Amaranth> it's still not better, just bad differently :P
<seb128> right, that will be discussed at UDS again but there is no clear winner imho
<TheMuso> directhex: Its not really, but we  have carried changes for it in Ubuntu since hoary.
<seb128> banshee looks a bit nicer but they are both feature equivalent mostly and do the work
<seb128> rhythmbox having the advantage to not be using a vm and being in a language most GNOME people having been using ;-)
<liw> my audible bell keeps coming back (probably after suspend or reboot), I mean the thing that sounds when, say, I press down arrow on the last line in a gedit window; where is that setting stored? can't find it in gconf
<Amaranth> rhythmbox having the disadvantage that it's not going to get any new features unless it finds new developers
<TheMuso> liw: system prefs, sound, you can turn off the system bell.
<Amaranth> I don't care either way, just throwing that out there
<liw> TheMuso, yes, and that I have done, and that's what keeps getting ignored
<TheMuso> liw: Interesting.
<liw> TheMuso, so I'm asking where that setting is stored
<seb128> liw: is it ignored at login or only after suspend?
 * pitti blinks and looks twice when binary NEWing "inteltool"
<TheMuso> liw: gconf
<liw> seb128, I don't know yet
<liw> TheMuso, where?
<TheMuso> liw: can't remember the key off hand.
<liw> TheMuso, I just said I looked for it in gconf...
<seb128> liw: look for audible_bell in gconf-editor
<seb128> liw: in key name, that's wm key
<TheMuso> And its a metacity flag
<directhex> seb128, what did you decide for gnote in the end, btw?
<seb128> Amaranth: the question is to know if we need new features in rhythmbox
<liw> seb128, hmm, I already searched for "bell", but since I'm not currently using metacity...
<seb128> directhex: I was not the one reviewing it but I think it's not going to be accepted until the copyright are correct
<liw> but that setting seems to work, let me try suspendnig
<seb128> liw: neither compiz?
<directhex> seb128, i see.
<liw> bah, now I can't seem to reproduce this at all, so it's not a systematic problem
<liw> when it happened, gnome-sound-properties did show the alert bell as being disabled, but gedit happily beeped anyway
<liw> I'll debug further when it happens again
<directhex> i should work on my TODO rather than playing with sgt-puzzles
<liw> seb128, I seem to be running compiz (bug only because metacity broke focus handling for new windows)
<seb128> liw: ok, so the compiz audible_bell key should be working
<amitk> pitti: are you able to resolved bug 369850 with the information now provided?
<ubottu> Launchpad bug 369850 in linux "Cannot set up parallel port printer on Ubuntu 9.04" [High,Confirmed] https://launchpad.net/bugs/369850
<amitk> *resolve
<pitti> amitk: didn't have time to look at it yet, sorry; but it's in my mailbox
<amitk> pitti: I'm assigning it to you. It should also be against udev rather than the kernel
<pitti> amitk: if it's a kernel problem, I'll assign it back
<pitti> thanks
<pitti> amitk: do you know why linux-meta still points at l-r-m 2.6.28?
<pitti> amitk: could we have a -meta upload for -5?
<amitk> smb: could you do the meta upload? ^
<smb> amitk, I check it
<smb> amitk, Are you sure about the -5?
<amitk> smb: in what way?
<smb> because the abi is -11 for Jaunty (2.6.28)
<smb> -5 could be karmic (2.6.30)
<amitk> smb: we are talking karmic here
<pitti> smb: right, karmic
<smb> Ah, ok. Then I know where to look
<pitti> smb: linux-meta still points to linux -2 and jaunty's lrm
<pitti> smb: I just NEWed linux -5 on amd64, i386 was already done
<smb> pitti, Ok, I check an upload meta for karmic
<seb128> TheMuso: are you sure esound can be synced?
<pitti> smb: hm, I just noticed that we don't even have an lrm 2.6.30 for karmic
<pitti> smb: would lrm 2.6.28 even work with linux 2.6.30?
<pitti> anyway, d-i uses -5 now, so we need to have linux-meta use -5 as well, to get some sort of installability on the CDs
<TheMuso> seb128: From the changelog and build checks I did, I think so. Is there something you're concerned with?
<smb> pitti, Err, I think tim wants to get rid of it if possible
<slangasek> pitti: eew? why are we getting a kernel ABI change so close to the alpha? :(
<seb128> TheMuso: when I looked at it, the most recent upload ld_preload change was not in debian
<smb> pitti, but we would have to update meta to remove lrm...
<pitti> slangasek: it didn't actually make the situation worse
<smb> slangasek, that was because of this build failure and because /me did want to make sure the abi checker does not freak on the uploaded kernel, which was to be quick
<pitti> smb: indeed, "linux" just pulls in "linux-image" now, not "lrm"
<pitti> smb: ok, so you'll upload a linux-meta without any lrm dependencies?
<pitti> against -5?
<smb> pitti, ok, so at least that seems to be right. Yes, give me a few mins
<pitti> smb: interesting that we can get rid of lrm entirely; certainly makes things easier
<ajmitch> pitti: uploading a merged apache will drag in binary packages from universe, I take it that's not a problem since they're just ones split from a source in main?
<smb> pitti, That is still in the try. Tim started a broadcom dkms package
<pitti> ajmitch: can you stall that until Friday perhaps?
<ajmitch> pitti: sure
<pitti> ajmitch: it still requires MIR bugs, archive admin work, publisher runs to settle everything, etc.
<pitti> ajmitch: not a problem, but introduces delays
<pitti> smb: rock
<ajmitch> ok, good thing I checked :)
<pitti> smb: so for alpha-1 we won't have "wl" then?
<smb> It might be. Unfortunately I am not that deep into it
<apw> hrm ... not sure i thought the point was to have special dkms packages for anything which was needed
<smb> So wl would come from a dkms
<TheMuso> seb128: Right. Debian have something similar, their reason being that only esddsp uses libesddsp.so, so may as well put it in esound-clients.
<seb128> TheMuso: ok, I was just checking because I noticed that change was not there and it was not obvious their change was equivalent
<seb128> TheMuso: thanks for checking
<TheMuso> seb128: NP
<ogra> Keybuk, when do you think the udev chain will be fixed again ?
<ogra> we need to build images and udev breraks the world since yesterday
<lool> Keybuk: lpia livefs builds are currently failing with "udev: Breaks: dmsetup (<= 2:1.02.27-4ubuntu5) but 2:1.02.27-4ubuntu5 is installed"
<ogra> armel as well
<ogra> and i would expect the others too
<ogra> since nobody touched any of the vol_id using packages yet
<lool> Keybuk: Will you upload the packages which udev now Breaks, or could you explain how to change them for the new udev?
<cjwatson> sigh, I bet removing the vol_id binary broke the installer
<Keybuk> ogra, lool: devmapper and lvm2 got merged together in Debian
<Keybuk> so that's a complex merge that will take time
<lool> Keybuk: Should we revert the udev changes for a1?
<Keybuk> lool: no
<ogra> Keybuk, hmm, any chance for us to build A1 images then ?
<lool> Keybuk: Can we defer the complex merge and just go through the transition with the packages we have in karmic ATM?
<Keybuk> lool: yes, if you want to test them, the patches are in my PPA
 * Keybuk still stands by his opinion that doing an Alpha before DIF is silly
<ogra> still there is a freeze starting today, you are on the TB, feel free to change policy
<cjwatson> so you'll put forward that opinion by uploading breakage during the freeze announced by the release manager?
<Keybuk> cjwatson: I didn't upload any breakage during the freeze
<ogra> no, you did it some hours before the freeze
<Keybuk> no
<Keybuk> I did it some WEEK before the freeze
<Keybuk> or was it even TWO WEEKS
<Keybuk> ?
<lool> Keybuk: mdadm udev devmapper initramfs-tools, anything else?
<Keybuk> lool: only mdadm, devmapper and lvm2 need fixes right now
<Keybuk> I'd planned to do an upload this morning of those three
<lool> initramfs-tools mentions a similar change
<Keybuk> lool: how do you mean?
<lool> "  * Replace all instances of vol_id with blkid, and depend on util-linux" but I'm fine with trusting you on that if it works
<Keybuk> does your karmic system boot?
<lool> I'm running jaunty ATM
<ogra> how do we know ?
<cjwatson> Keybuk: ah
<ogra> we cant build images for karmic to even test
<cjwatson> (timeframe)
<Keybuk> ogra: by running it like good developers?
<lool> I started dist-upgrading some hosts, but had too much things in progress on my desktop to do it there yesterday; it seems it wouldn't have booted...
 * lool <= back from holidays since yesterday, didn't have a chance to try karmic out directly yet
<cjwatson> so, making the installer work again will need fixes for at least base-installer partman-crypto partman-target silo-installer util-linux
<ogra> flash-kernel-installer
<Keybuk> cjwatson: util-linux?
<cjwatson> yeah, looking at adding the blkid binary to a udeb
<Keybuk> oh, I thought I included that in the udeb
<Keybuk> ohh, no, there is no util-linux udeb is there
<Keybuk> would it work to put it in the existing libblkid1-udeb ?
 * ogra wonders why livecd-rootfs only breaks on udev since the last upload if the udev chnage was weeks ago ...
<ogra> ah, because nothing could build probably because of linux-libc6-dev
<cjwatson> Keybuk: I think it would, yeah, just looking at that now
<ogra> Keybuk, my apology then ... it only manifested hours before the freeze due to a different bug, though an announcement mail last week or so would have been nice
<Keybuk> ogra: I sent mails to ubuntu-devel about the change months ago
<Keybuk> and included packages in my PPA for people to test
<StevenK> linux-libc-dev, rather than linux-libc6-dev?
<ogra> StevenK, indeed
<cjwatson> Keybuk: just want to check which bits are in d-i's equivalent of Essential
<Keybuk> cjwatson: np
<cjwatson> Keybuk: would you object to me creating a util-linux-udeb for this? I think that might be clearer and save having to track e.g. libblkid soname changes in d-i
<Keybuk> I think that would be sane
<Keybuk> we probably need to put fsck in that too? :p
<cjwatson> Keybuk: I'm not actually sure that the installer uses fsck directly; e2fsprogs-udeb only ever contained e2fsck
<cjwatson> the installer knows the filesystem type, so ...
<Keybuk> ah
<Keybuk> fair enough :)
<cjwatson> I'll check, though
<lool> http://conflictchecker.ubuntu.com/possible-conflicts/ misses jaunty and karmic; where are bugs filed for this host?
<lool> RT ticket?
<cjwatson> lool: talk to mvo directly, I think; but he's on vacation this week
<cjwatson> I wouldn't use RT for this, it's not IS-owned
<lool> Indeed; will drop him an email
<cjwatson> lool: lifeless can write to it too
<lool> Ah will forward to him then
<cody-somerville> Are perl and python handled in a similar fashion with regards to bytecode management?
<Keybuk> no
<cjwatson> we don't store byte-compiled versions of perl code at all
<cody-somerville> Ah
<cody-somerville> How are perl modules maintained in comparison to python?
<cjwatson> there's a detailed Perl policy in the (debian|ubuntu)-policy packages
<cjwatson> (it's the same in both)
<cody-somerville> I want to do something similar for Pike.
<smb> pitti, linux-meta for karmic uploaded
<pitti> smb: danke sehr
<smb> pitti, keine ursache
<pitti> doko: meh, ppl was promoted without an MIR, and b-deps on xpdf-utils
<pitti> doko: can you please fix it to build against poppler-utils?
<doko> pitti: no, poppler-utils provides xpdf-utils. cjwatson told me that this is a missing feature in the component checker
<pitti> doko: ah, ok
<Keybuk> super1.c: In function 'update_super1':
<Keybuk> super1.c:617: error: dereferencing type-punned pointer will break strict-aliasing rules
<Keybuk> :-O
<Keybuk> oh, I'm so not going near *that* build failure
<ogra> vol_id="$(PATH="/lib/udev:$PATH" vol_id -u "$rootfs")"
<ogra> Keybuk, do i still need to set the path in the above if i switch to blkid ?
<ogra> (thats in a udeb)
<Keybuk> ogra: blkid is in /sbin
<ogra> great :)
<cjwatson> ogra: I'm adding a block-attr wrapper to make it easier to get patches into Debian
<cjwatson> ogra: which udeb is that?
<ogra> flash-kernel-installer
<Keybuk> blkid -o value -s UUID /dev/sda1
<Keybuk> would be a direct equivalent of that command
<cjwatson> yep, I arranged for  block-attr --uuid /dev/sda1  to work
<ogra> well, if colin adds a wrapper i'll wait for that
<ogra> ah, cool
<cjwatson> (sorry for the wrapper, I only just got uuid mounting into Debian and want to relish being in sync there for a bit ;-) )
<Keybuk> a wrapper seems sane to me
<hyperair> kees: got a moment? (regarding usplash's behaviour)
<ogra> cjwatson, i assume that works in both, ubiwuity and d-i
<cjwatson> ogra: I can just add flash-kernel to the list of installer packages I'm changing en masse, if you like
<ogra> *ubiquity
<cjwatson> ogra: yes
<cjwatson> though thanks for reminding me :)
<ogra> oh, feel free to do it, yes
<Keybuk> worryingly, I know what a type-punned pointer is, and why it would break strict-aliasing rules
<pitti> Keybuk: misaligned quantum flux regulator?
<Keybuk> pitti: indeed, causing a reversal in the polarity of the neutron flow
<pitti> that should so much go into ubuntu-policy
<pitti> Keybuk: (I'm not even trying to think about polarity of neutrons..)
<pitti> but in 300 years they probably will have found one
 * directhex reverses pitti's shield polarity
 * pitti sends a Polaron beam to directhex
 * directhex uses the picard manoeuvre 
<directhex> oh for the love of... the bottom row of gpg fingerprint printouts is cut off. stupid printer
<Keybuk> directhex: the picard manoeuvre? doesn't your shirt fit properly?
<directhex> Keybuk, no :|
<directhex> stupid last-ditch clothes. waiting for new washing machine to be delivered at some point before UDS
<ogra> really depends on the percentage of spandex, no ?
<ogra> but i think he doesnt mean the shirt stretching :)
<ogra> http://memory-alpha.org/en/wiki/Picard_Maneuver
<Keybuk> I did mean the shirt stretching ;)
<ogra> indeed *g*
<directhex> ogra, i'm glad someone else was enoguh of a nerd to admit to knowing what said manoeuvre is
<ogra> directhex, well, its a bit embarrasing that i know both meanings :)
<NCommander> Keybuk, +1 on Star Trek production trivial
 * NCommander also knows both :-/
<directhex> i *knew* both, but had forgotten the shirt one
<Keybuk> worse still, I know that one of the characters in the newest movie tugs his shirt down in homage
<ogra> you have seen it already ?
<Keybuk> yes
<NCommander> It was good IMHO
<directhex> i have not seen any movies. i'm booked solid until june. and even then i have a conference in hamburg
<evand> directhex: pong
 * ogra curses to be german ... we always have to wait until the dubbing is done before movies hit the cinema
<Riddell> I hope this vital conversation is going to result in a fixed udev :)
<ogra> heh
<NCommander> +1 Riddell
<ogra> Riddell, udev is fine ... just the rest of the world refuses to work
<directhex> evand, erm..... oh, i know! i was gonna give you links to the (seemingly active) upstream bug reports surrounding banshee a11y
<directhex> erm, hang on...
<evand> oh, good deal
<Keybuk> Riddell: hmm?
<Keybuk> I uploaded all the fixed packages before ogra even asked about it this morning
<NCommander> ogra, BTW, care to sponsor lp:~mcasadevall/python-apt/karmic-armel-workaround ?
<Riddell> good good :)
<ogra> NCommander, sure, let me take a look
<Keybuk> https://edge.launchpad.net/ubuntu/karmic/+source/devmapper/2:1.02.27-4ubuntu6
<Keybuk> just missed a publisher window, that's all
<directhex> <sshaw> http://bugzilla.gnome.org/show_bug.cgi?id=533030
<directhex> <sshaw> https://bugzilla.novell.com/show_bug.cgi?id=476836
<ubottu> Gnome bug 533030 in User Interface "Banshee inaccessible" [Normal,New]
<ubottu> bugzilla.novell.com bug 476836 in gtk-sharp "atk ObjectFactory has static virtual methods and is not usable" [Normal,Needinfo]
<directhex> evand, a banshee bug and a gtk# bug respectively
<directhex> evand, banshee upstream has hinted that they want to resolve it for 1.6 milestone
<pitti> dendrobates: do you guys still want to support redhat-cluster?
<pitti> Keybuk: ^
<evand> Any idea when that is planned for?
<pitti> dendrobates: it needs to be converted from libvolume-id to libblkid, since the former is gone
<ogra> NCommander, can you please make sure to use a valid email address in your changelog entries ?
<NCommander> ogra, I didn't use a valid email?
<NCommander> ... argh
<NCommander> when I reran dch it must have changed it
<NCommander> bah
<ogra> please fix and push
<Riddell> pitti: what was the kubuntu install issue you saw?  was it okular?
<NCommander> ogra, repushed
<pitti> Riddell: haven't tracked it down yet; http://people.ubuntu.com/~ubuntu-archive/testing/karmic_probs.html
<Keybuk> NCommander: I liked the implied death of Archer's silly dog ;)
<NCommander> Keybuk, what implied death?
<Keybuk> NCommander: Scotty said he tested his transporter theories on "Admiral Archer's Prize Beagle" :p
<ogra> NCommander, hmm, why did you change urgency ?
<NCommander> ogra, it was urgency=critical before
<ogra> python-apt (0.7.10.3ubuntu1) karmic; urgency=low
<ogra>   * merged from debian, remaining changes:
<ogra> not here
<NCommander> python-apt (0.7.10.3ubuntu2) karmic; urgency=critical
<NCommander> O_o?
<cody-somerville> Why does it even matter?
<ogra> well, its a unnecessary change
<Keybuk> it's also entirely pointless
<Keybuk> since urgency is unused
<ogra> true
<NCommander> Keybuk, actually it affects build score
<cody-somerville> Actually, it does make a difference on the build score
<Keybuk> so NCommander can put whatever he likes in there
<james_w> I heard a whisper that it is used for something
<Keybuk> it does?
<james_w> according to soyuz folks
<NCommander> Keybuk, yeah, a critical upload will be scored higher by default then a high one
<ogra> Keybuk, but since we upload a really ugly workaround to just make the package build only for A1 i wouldnt like to make more changes than necessary to the existing one
<NCommander> (its not a huge difference AFAIK)
<Keybuk> ogra: it's the changelog, I don't see that it makes any difference
<cjwatson> while it does affect build score, the difference is pretty tiny
<ogra> i think dch will carry it over, no ?
<ogra> into all future versions ... until someone changes it back
<cody-somerville> who uses dch? :P
<Keybuk> _o/
 * ogra too
<pitti> cody-somerville: how can you _not_ use it?
<directhex> pitti, manual copypasta!
<NCommander> _o/
<ogra> directhex, and using a claculator to compute the new timestamp ? :)
<directhex> how do i override dch's values though? i could do with setting UNRELEASED rather than karmic in most cases
<cjwatson> DEBCHANGE_RELEASE_HEURISTIC=changelog in ~/.devscripts
<directhex> neato!
 * ogra uploads ...
<ogra> NCommander, can you take care that the change goes into any bzr branches it needs to be once mvo is back ?
<directhex> cjwatson, this might be a silly question, but if dch is parsing .devscripts anyway, why does it not parse things like DEBEMAIL from there?
<cjwatson> dunno
<cjwatson> maybe because you need to set DEBEMAIL in the environment anyway for other tools
<lifeless> TheMuso: I think upstream is awol
<TheMuso> lifeless: Do you mean lack of response, or weird response?
<pitti> cjwatson: util-linux-udeb NEWed, FYI
<cjwatson> oh, thanks, I was just about to ask
<cjwatson> did you put it in main?
<pitti> yes
<pitti> I though that was the point
<cjwatson> it was indeed, just checking
<lifeless> TheMuso: lack of response, I was looking at the http://thread.gmane.org/gmane.linux.kernel.device-mapper.devel/7235 thread re: alt_size from the kernel
<TheMuso> lifeless: right
<lifeless> TheMuso: which is a better way of finding out the hpa size
<TheMuso> yep
<pitti> smb: I'll reject the linux-meta upload; can you please do it again and rename the binaries from *-jaunty-* to *-karmic-*?
<pitti> smb: the linux-backports-modules-jaunty-* stuff, in particular
<Riddell> pitti: that should be fixes uploaded for all the kde uninstallables, except kdeadmin, kdemultimedia and kdesdk which are just victims of a 0 build score
<pitti> Riddell: ah, thanks
<pitti> Riddell: let me rescore those
<Riddell> pitti: were you looking at openoffice.org-kde ?
<pitti> Riddell: no, it's not mentinoed as being uninstallable, what do yo mean?
<pitti> Riddell: oh, the binary, sorry
<pitti> Riddell: OO.o is uninstallable all over the place, I'm afraid
<Riddell> pitti: karmic_probs says it is, it seems not to be built any more
<Riddell> calc: what have you done with openoffice.org-kde?
<pitti> Riddell: there are currently new builds going on, I hope they'll fix that
<pitti> indeed, -kde is gone from Binary: list; calc?
<pitti>    * debian/control.in, debian/control.kde.in, debian/rules:
<pitti>      - disable -kde and -kab as they're for KDE3 (closes: #523899). Improve
<pitti>        BUILD_KDE conditional
<pitti> ^ from Debian changelog
<pitti> Riddell: did we change that for KDE4?
<Riddell> pitti: no we kept the kde 3 stuff since the kde 4 patches don't work
<pitti> Riddell: okay; calc, can you please revert that then?
<pitti> Riddell: is that a CD installability blocker?
<doko> calc: did you test the ooo-l10n build? it fails at least in the jaunty ppa, so we could save some time on the buildds
<Riddell> pitti: openoffice.org-kde is only a kubuntu-desktop receommends so it should be fine without it
<ogra> pitti, are we actually concerned about installability ?
<pitti> ogra: sure we are, for alpha-1
<pitti> that's the point of it
 * ogra thought we only care for bootability 
<Riddell> ogra: it does help for alphas
<ogra> well, i remember releases where we didnt care much for A1 ... just to have something booting
<lool> Keybuk: So initramfs-tools seems to be required
<lool> update-initramfs: Generating /boot/initrd.img-2.6.30-2-lpia
<lool> cpio: ./lib/udev/vol_id: Cannot stat: No such file or directory
<lool> Keybuk: That's when building a livefs for MID on lpia
<Keybuk> lool: that could be a hook
<Keybuk> grep -r vol_id /usr/share/initramfs-tools
<Keybuk> wing-commander scott% grep -r vol_id /usr/share/initramfs-tools
<Keybuk> zsh: exit 1     grep -r vol_id /usr/share/initramfs-tools
 * Keybuk has nothing in there
<lool> chroot-livecd/usr/share/initramfs-tools/hooks/casper
<lool> chroot-livecd/usr/share/initramfs-tools/scripts/casper-helpers
<lool> chroot-livecd/usr/share/initramfs-tools/scripts/casper-bottom/13swap
<lool> Indeed, it's casper
<lifeless> TheMuso: do you know what is meant to trigger dmraid-activate ?
<TheMuso> lifeless: a udev rule.
<pitti> StevenK: would you like to do some NBS cleanup, so that we can better see the real issues?
<lifeless> TheMuso: hmmm
<pitti> smb: linux-meta> you should also update Vcs-Git: for ubuntu-karmic-meta.git
<lifeless> TheMuso: there is a bug open, that I'm seeing too, that one has to dmraid -a -y on boot
<StevenK> pitti: I will have a look
<lool> Keybuk: Could you look into porting it?  It's not A1 critical anymore though as apparently the kernels lack aufs/unionfs support IIUC
<pitti> StevenK: cheers
<TheMuso> lifeless: Right.
<TheMuso> I'd have to put a fresh install onto a dmraid array. *sigh*
<TheMuso> even then I think I won't have a problem.
<TheMuso> And, I have to get ready for bed, gotta get up early for a teleconference.
<Keybuk> lool: rofl - that makes the milestone just a little trickier than usual, doesn't it
<lifeless> yeah, not asking you to look into it
<lifeless> just gathering data to fix it myself
<pitti> cjwatson: retrying/rescoring d-i, -5 udebs are in the archive now
<cjwatson> pitti: I have to reupload anyway
<pitti> cjwatson: oh, ok; not doing then
<pitti> cjwatson: ah, for vol_id?
<cjwatson> lool: live CDs won't happen for alpha 1
<cjwatson> pitti: yes
<lool> Keybuk: I'd still be interested in getting the livefs into shape for armel/desktop+alternate, lpia/mid+alternate, and i386/unr
<lool> cjwatson: Yes, understood
<cjwatson> I'll take care of casper
<pitti> StevenK: kernel -4 can go then, it was never used by -meta or d-i
<smb> pitti, Argh, didn't verify that. Tahnks, will do
<Keybuk> cjwatson: I was just finishing doing that
<smb> pitti, Argh, didn't verify that. Tahnks, will do
<cjwatson> Keybuk: oh, ok
<StevenK> pitti: Okay, cool
<soren> Can anyone think of a reason why /proc not being mounted could cause a binary's rpath not be used?
<lool> If you don't have /proc you don't have hwcaps and it might select different binaries based on hwcaps; no other ideas from me :)
<ogra> is there any particular reason why we dont have aufs/unionfs in the kernel ?
<smb> pitti, I will have to upload a new version then, right?
<pitti> smb: yes, please
<Keybuk> ogra: they've been refused merge, and don't apply to the current version, and are unmaintained or abandoned
<ogra> sigh
<smb> pitti, underway
<cjwatson> ogra: and the alternatives are non-rsyncable
<cjwatson> (as far as we can tell)
<ogra> so why are we doing an alpha at all ?
 * soren coughs
<ogra> we should just skip it until thats solved
 * soren mumbles something about the server
<cjwatson> we've shipped alpha 1 milestones with only alternate/server CDs before; it's almost normal in fact :)
<ogra> yeah yeah ...  we should indeed do a server A1 soren  :P
 * soren tips his hat at ogra
<ogra> :)
<ogra> The following packages have unmet dependencies:
<ogra>   dmsetup: Depends: util-linux (>= 2.15-1) but 2.15~rc2-1ubuntu1 is installed
<ogra> hrm
<soren> lool: Hmm.. Yeah, maybe dl.so bails out because it can't resolve hwcaps. That would be a bug, though. *ponder*
<lool> soren: You could diff straces
<Keybuk> util-linux | 2.15-1ubuntu1 |        karmic | amd64, i386, ia64, lpia, powerpc, sparc
<Keybuk> util-linux | 2.15-1ubuntu2 |        karmic | source
<Keybuk> util-linux | 2.15~rc2-1ubuntu1 |        karmic | armel, hppa
 * ogra twiddles thumbs ... 
<Keybuk> ogra: armel build issue?
<lool> soren: There are some debug flags as well, especially for hwcaps
<ogra> Keybuk, yeah, likely slow buildd ... just looking
 * cjwatson grumbles at having to wait for the debian-installer-utils code import
<lool> soren: I noted some in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/343602
<ubottu> Ubuntu bug 343602 in linux "NEON and THUMBEE hwcaps" [High,Fix released]
<ogra> Keybuk, both built fine ... might just be the publisher
<soren> lool: I already diffed straces. I didn't feel much smarter afterwards. I'll give it another go, though.
<lool> soren: You would see auxv for hwcaps in straces
<soren> lool: Thanks for the pointer.
<cjwatson> util-linux/armel seems to be publishing right now
<ogra> ah, thanks
<StevenK> pitti: I suppose -2- can die on ARM too?
<pitti> StevenK: hm, isn't that -ports?
<StevenK> No, armel is built under linux
<pitti> StevenK: I guess so, then
<StevenK> Hm, and -2-lpia and -2-server ...
<NCommander> cjwatson, is there a possibility we can get the crontabs on cdimage changed so ports architectures are building against karmic vs. jaunty?
<StevenK> pitti: I suppose 2.6.28-11 LRM and such can die?
<pitti> StevenK: yeah, it's totally not functional any more anyway
<pitti> StevenK: perhaps leave the source package for now, just in case the kernel team reconsiders dropping lrm
<pitti> but the binaries can go
<StevenK> pitti: Oh, I'm only NBS'ing binaries
<cjwatson> cdimage@antimony:~$ crontab -l | grep jaunty
<cjwatson> cdimage@antimony:~$
<cjwatson> NCommander: ^-
<cjwatson> NCommander: the ports architectures are *already* building against karmic
<cjwatson> (and the distribution isn't in the crontab anyway)
<StevenK> For Hardy Ubuntu it is ...
<NCommander> The daily-live still says jaunty
 * StevenK hides from cjwatson 
<cjwatson> NCommander: (a) artifact of carrying over old images (b) already cleaned up this morning
<cjwatson> http://cdimage.ubuntu.com/ports/daily-live/current/ is currently essentially empty because all the karmic images failed to build
<NCommander> cjwatson, ah, then thank you :-)
 * NCommander will look at whats causing those failures later when I have time :-/
<cjwatson> now, there does still seem to be something wrong, because there are no livefs build logs for ports
<cjwatson> infinity: ^- do you know what's up with livefs buildds other than amd64 and i386? they don't seem to be producing build logs
<cjwatson> infinity: (weddell, royal, concordia, manoao)
<StevenK> cjwatson: When I tried to build MID on concordia, it said it couldn't build for karmic
<StevenK> pitti: Since we aren't using 2.6.28, I guess linux-backports-modules-2.6.28 source and binary can die
<smb> pitti, uploaded
<pitti> StevenK: yes, we have https://edge.launchpad.net/ubuntu/+source/linux-backports-modules-2.6.30 now
<pitti> smb: thanks
<StevenK> pitti: Okay, cool
<pitti> darn, buildds are OO.o'ed
<ogra> lol
<ogra> oo.o'ed
<Hobbsee> blame calc.
<ScottK> I'm sure doko has something gcc'ish he could upload to complete the picture.
<StevenK> And binutils
<ogra> and java
<StevenK> Oh yeah, let's just completly scorched earth the mirrors
<directhex> and mon... oh, wait, that's just a 40 minute build
<directhex> ;)
<fta> doko, kees: is gcc more strict in karmic? i'm hitting some "dereferencing type-punned pointer" type of errors that were fine in jaunty
<Keybuk> gcc tends to always get more strict
<Keybuk> clearly you're not paying strict attention to aliasing rules with all your irresponsible type-punning ;)
<cjwatson> StevenK: right, there was definitely a point where BuildLiveCD hadn't been updated, but I thought elmo said he'd done that
<elmo> I did
<fta> Keybuk, not my code ;) https://edge.launchpad.net/~chromium-daily/+archive/ppa
<Keybuk> type-punning is accessing one object type through a cast to another
<Keybuk> e.g. char * foo = "abcd";  *((int *)foo);
<Keybuk> or union { char *s; int i; } a; a.s = "abcd"; return &a.i;
<fta> Keybuk, i know, i'm used to deal with that in my own code but i'm using -pedantic -Werror since day 1.
<Keybuk> it's ok, as long as you don't do the last bits - ie. break the aliase
<Keybuk> it must always be an "int pointer to a char object" or "int member of a union with a char object"
<Keybuk> you can't make it just "an int pointer"
<fta> i just wanted to know if the differences in "strictness" are documented somewhere. Can't find that strict aliasing thing in https://wiki.ubuntu.com/CompilerFlags
<Keybuk> doubtful
<Keybuk> it's a side-effect of the optimiser, like most warnings
<Keybuk> it means that gcc got better at optimising something
<Keybuk> as a side-effect, it's more strict
<fta> ok, thanks
<Keybuk> sometimes, of course, it just gets things flat wrong ;)
<ogra> calc, what is mpi-default-dev ? seems openoffice misses it on all arches but x86/amd64
<StevenK> pitti: NBS cleaned, I binary removed around 160 packages
<StevenK> And 1 source
 * ogra wonders why python-apt is still not published for armel
<ogra> i see lpia on ports, but thats it
<cjwatson> there's been a scilab sync sitting in the syncs directory on cocoplum since yesterday. Does any archive admin want to own up to owning it?
 * james_w looks a Jamie
<james_w> https://bugs.edge.launchpad.net/ubuntu/+source/scilab/+bug/374839
<ubottu> Ubuntu bug 374839 in scilab "Sync scilab 5.1.1-4 (universe) from Debian unstable (main)." [Wishlist,Fix released]
<james_w> at Jamie
 * RainCT wonders whether the source code for the Ubuntu One server is/will be free
<jdstrand> cjwatson, james_w: ah, that was me. sorry...
<cjwatson> directhex: how come I don't see the uninstallability mentioned in bug 375365 on http://people.ubuntu.com/~ubuntu-archive/testing/karmic_probs.html or http://people.ubuntu.com/~ubuntu-archive/testing-ports/karmic_probs.html? Am I missing something?
<ubottu> Launchpad bug 375365 in gnome-desktop-sharp2 "gnome-desktop-sharp2 rebuild required" [Undecided,New] https://launchpad.net/bugs/375365
<cjwatson> directhex: oh, is it uninstallability in universe?
<ScottK> RainCT: It's somewhat off topic here in any case.
<lool> We need mpi-defaults/mpi-default-dev promoted to main for boost1.37
<lool> boost1.37 currently dep-waits on mpi-default-dev
<lool> givent that mpi-default-dev is a trivial debian/ only package, I think it's safe to promote it
<ogra> i wonder why it doesnt cause issues on i386 and amd64 though
<ogra> we should see the same there, no ?
<soren> lool: re rpath without  /proc> it seems to become very annoyed that it can't readlink /proc/self/exe.
<lool> ah
<calc> is libltdl7-dev removed on ia64 yet?
<calc> i got a failure from unixodbc-dev not being installable and previously it was because the real package still existed in the archive
<lool> ogra: boost1.37 was in universe when it built on i386
<ogra> ah and moved later
<lool> It was promoted after its build, but without promoting its bdep
<ogra> ok, that makes sense
<ogra> i was starting to doubt my sanity
<ion_> Ah, all better. sudo perl -i -pwe 's/lcddefault/lcdlegacy\000/g' /usr/lib/gnome-settings-daemon-2.0/libxsettings.so
<lool> How can I check who promoted boost1.37 to tell him about mpi-defaults?
<lool> It was 5 days ago
<seb128> ion_: what is that your are trying to solve there?
<ion_> seb128: gnome-settings-daemon overrides my /etc/X11/Xresources/sharp-fonts which contains Xft.lcdfilter:  lcdlegacy
<directhex> cjwatson, yes, it is
<directhex> cjwatson, it's in libgnomeprint2.18-cil, and the metapackage in universe which pulls it in - no other rdeps afaik
<pitti> smb: something went wrong, it still builds *-jaunty-*; take 2?
<smb> pitti, is it really the git-vcs line you mean?
<pitti> smb: no, the binary package names
<smb> pitti, Well then we nee a take2 as I only changed the git-vcs (which I understood was the problem)
<lool> pitti: Mind promoting mpi-defaults and mpi-default-dev to main?  I added it to #372756
<pitti> lool: done
<lool> pitti: thanks
 * ogra hugs pitti 
<lool> that should allow us to get oo.o building
<ogra> lool, boost already given back ...
<pitti> unfortunately just one minute after the publisher started :(
<calc> can someone kill the openoffice.org-l10n 1:3.1.0-1ubuntu1 build?
<pitti> lool: hm, oo.o has been building for 5 hours already?
<pitti> elmo, infinity, lamont: ^ can any of you please kill openoffice.org-l10n build?
<ogra> pitti, the armel qeue is full anyway
<calc> just the -l10n build not any of the others
<ogra> pitti, its all about arm :)
<pitti> ogra: OO.o and arm sound weird in one sentence
<lool> pitti: Not on armel
<lool> :)
<calc> i found a bug in it too late and having to upload a 1ubuntu2 to resolve it
<ogra> pitti, runs fine on my board here :)
<calc> stupid --fail-missing argument in merge from debian :-\
<ogra> pitti, face the future ;)
<pitti> calc: unfortunately only sysadmins can kill builds
<pitti> calc: please upload it already
<calc> pitti: its being uploaded already but it takes me about 20-25m
<pitti> calc: ah, nice
<lool> ogra: I don't think boost had to be given back; anyway, it's done now
<ogra> lool, it was manualdepwait
<lool> On mpi-default-dev, which is fine
<ogra> we didnt have 1.37 on armel yet
<lool> But it would have appeared after the promotion
<ogra> boost1.37 which has never built on armel ? how ?
<lool> Because of mpi-default-dev which was missing
<smb> pitti, here you go. take2 (or .4). This time I found no more traces of jaunty in there.
<ogra> lool, you mean the manualdepwait would have lifted itself after promotion ?
<lool> I believe so
<ogra> ah
<ogra> sorry, i'm slow today
<pitti> smb: cheers
<ogra> lool, (not to slow to with the python-apt race against you though :P)
<lool> Nor to slow to do give backs  :-)
<ogra> ok, at least it looks like thats the last remaining bit missing to get a livefs ...
<ogra> http://paste.ubuntu.com/170614/
<lool> Yeah, but oo.o needs 36 hours to build on armel  :-(
<ogra> yep ...
<calc> looks like armel still hasn't caught from last weeks linux-libc-dev mass giveback
<calc> erm - caught up
<calc> along with hppa, ia64, sparc
<lool> calc: Yes, I asked infinity to see whether we could add some buildds on Monday; he was trying to bring up a spare one
<calc> lool: ah
<directhex> ehm..... calc, can you check something for me?
<calc> directhex: whats up?
<directhex> calc, does http://www2.apebox.org/data/cv.doc crash OOo for you? it does for me on jaunty. which is weird given that's where i just saved it
<calc> directhex: yea boom, file a bug report and attach that file
<calc> directhex: and note that i checked it on jaunty already as well and saw it blew up :)
<directhex> i wish my test file didn't have my cell number & home address. nevermind
 * calc won't be doing as much triage this cycle due to working on other things :-\
<calc> directhex: hmm if you have a way to reproduce it and strip out that info that is fine too
<directhex> calc, shall i get a non-ubuntu person to test, possibly leading to an upstream bug instead of downstream?
<calc> directhex: i can do that here will just take a minute... for it to be upstream pretty much you need a windows person to test since nearly all (non-Fedora) linux use go-oo
<calc> i have vm's with various OOo versions installed
<directhex> o_o
<directhex> that's dedication!
<calc> the only way we can upstream any bugs...
<directhex> oh, hold on, i have windows on my laptop!
<calc> otherwise they just close the bugs without looking
<directhex> i wnoder how oracle feel about an OOo Foundation...
<calc> directhex: no idea yet
<calc> if it doesn't happen by OOoCon I'm sure there will be many people asking
<calc> blows up official 3.0.1
<calc> directhex: so yea just submit it directly to upstream
<calc> directhex: mention it was tested on 3.0.1 to blow up
<calc> i haven't upgraded my vm's to 3.1.0 yet need to do that soon
<directhex> bang
<directhex> calc, blows up on windows.
<calc> directhex: if you happen to have 3.1.0 to test on that would be best, otherwise make sure to note which version you tested with that it crashed
<calc> directhex: and if at all possible don't mention ubuntu at all :)
<calc> sometimes they see ubuntu and close the bug without reading anything else at all, i saw an xp user mention it also seemed to happen on ubuntu and they immediately closed his bug telling him to use the official version (which is what he was doing on XP)
<directhex> calc, aren't healthy relationships with upstream wonderful? <3
<calc> heh :)
<directhex> yeah, 301 windows blows up
<directhex> that's as official as they come
<calc> i'm testing a beta of 3.1.0 now that i already had installed, if i can manage to get the doc file
<calc> seems this vm doesn't like to use the network
<calc> hmm seems your server is a bit buggy
<calc> it gave me a squid error
<directhex> my webhost sucks
<directhex> i'd welcome better suggestions
<calc> it works now
<calc> testing with 3.1.0m7
<calc> crashes it too
<calc> so mention you verified it crashed on 3.1.0 m7 also (that is a beta from about a month ago)
<calc> pitti: does the buildd system automatically kill a build if it sees a newer one available?
<pitti> calc: no, unfortunately not
<calc> pitti: ok
<pitti> calc: and the webui function to kill one isn't implemented, so I pinged the admins
<calc> pitti: the old ooo-l10n still needs killing and the new one is uploaded now
<ScriptRipper> i have a question about python install dirs
<ScriptRipper> i do under ubuntu 9.04 in python use the setuptools
<ScriptRipper> python setup.py install --prefix=/usr/src/packages/BUILD/debian/tmp/usr installs on any debian or ubuntu version
<ScriptRipper> the packages correctly.
<ScriptRipper> but not in ubuntu 9.04
<ScriptRipper> is this an issue known?
<directhex> calc, there we go, issue #101831
<ScottK> ScriptRipper: See https://wiki.ubuntu.com/Python2.6And3.0
<calc> directhex: great :)
<cjwatson> ScriptRipper: also see bug 362570
<ubottu> Launchpad bug 362570 in python2.6 "Python distutils installs into 'site-packages' instead of 'dist-packages' when a prefix is set" [Wishlist,Confirmed] https://launchpad.net/bugs/362570
<ScriptRipper> oh god no
<ogra> seb128, my evo on jaunty just committed suicide ... now its not coming up anymore at all :/
<cjwatson> ScriptRipper: simple fix for you is probably to use --root=/usr/src/packages/BUILD/debian/tmp instead
<seb128> ogra: that's not a very useful bug description
<ScriptRipper> so i drop prefix or do i use in addition --root ?
<ogra> i know :(
<ScriptRipper> i will try
<seb128> ogra: you could start by saying if it hangs or crash, what error you get, etc
<ogra> seb128, it silently crashed, when i restarted it it didnt show any folders, now after a reboot i see it in the processlist but no UI is coming up
<seb128> evolution --force-shutdown
<seb128> evolution
<seb128> is there any error on the command line?
<ogra> did that before the reboot ...
<ogra> one sec
<ogra> my disk is very active
<cjwatson> ScriptRipper: drop --prefix. I think you may also need --install-layout=deb
<ogra> ogra@osiris:~$ evolution
<ogra> ** (evolution:4201): DEBUG: mailto URL command: evolution %s
<ogra> ** (evolution:4201): DEBUG: mailto URL program: evolution
<seb128> that's normal
<ogra> nothing else ... and the disk starts spinning
<ogra> no UI though
<seb128> are you sure it's not on an another workspace?
<seb128> it's not listed in the tasks list?
<ogra> nope, not on any other workspace
<seb128> do you get the same issue if you start --component=calendar?
<ogra> hmm, cant ctrl-C it ...
<ogra> yes, seems like it has the same issue
<ogra> disk is spinning endlessly, no UI
<seb128> try starting it in gdb and get a stacktrace?
<ogra> load average of my system just bumped to 4
<seb128> it seems to be very busy
<ogra> yes
<ogra> disk IO like mad
<seb128> it could be rebuilding the mailbox indexes but it usually displays an UI before doing that
<ogra> it doesnt seem to take any CPU or RAM
<ogra> according to htop
<ogra> oh, there it is !
 * ogra switches to email
<ogra> no folders :/
<ogra> "Loading ..."
<ScriptRipper> how do i then install?
<ScriptRipper>  dh_install --sourcedir=`pwd`/debian/tmp --fail-missing
<ScriptRipper> cjwatson: --root= seemed to have helped
<ogra> statusbar says its reading the folders in ~/.evolution/mail/local/ ... and local#Inbox/ubuntu-users ...
<ogra> no content though
<ogra> seb128, geez, its back !
<ogra> now that took a while
 * ogra would still love to know why it crashed in the first place though
<seb128> ogra: not sure perhaps io issue?
<ogra> hmm, i wouldnt know why though
<ogra> i sadly missed when it crashed exactly
<ogra> since i had a terminal in fullscreen
<NCommander> cjwatson, on ubuntu-cdimage, what generates the Ubuntu-$series task files. I think there is some script to convert germinate output, but I can't find it anywhere (I have a mostly working ubuntu-cdimage setup, and I can generate discs that are bootable, but I have yet to be able to make a disc thats installable since I can't figure out how to get the full set of packages on it :-/)
<cjwatson> NCommander: can you give me the exact path of the files you want produced?
<NCommander> cjwatson, I believe on antimony its /srv/cdimage.ubuntu.com/tasks/Ubuntu-$distro, but I'm not 100% sure. Its essentially a file with every package that needs to be on the alternate CD including udebs
<cjwatson> yeah, there are several such files, that's why I'm asking
<NCommander> cjwatson, I figured as much, ubuntu-cdimage is a fun beast :-)
<cjwatson> NCommander: there are no files named just the way you're asking, but I think you're looking for germinate-to-tasks
<NCommander> I don't see that in any package, or in the tools folder of u-cdimage
<ogra> hmm
<ogra> infinity, help !   CC      arch/arm/boot/compressed/misc.o
<ogra>   LD      arch/arm/boot/compressed/vmlinux
<ogra> Segmentation fault
<ogra> make[4]: *** [arch/arm/boot/compressed/vmlinux] Error 139
<ogra> make[3]: *** [arch/arm/boot/compressed/vmlinux] Error 2
<ogra> http://launchpadlibrarian.net/26601421/buildlog_ubuntu-karmic-armel.linux_2.6.30-5.6_FAILEDTOBUILD.txt.gz
<NCommander> ogra, woo, binutils exploded :-/
<ogra> binutils ?
<NCommander> ld is apart of binutils
<NCommander> Unless you think its something else that segfaulted
<cjwatson> NCommander: ... tools directory? you're looking at debian-cd, which is only one part of ubuntu-cdimage
<cjwatson> NCommander: code.launchpad.net/~cjwatson/ubuntu-cdimage/mainline
<NCommander> cjwatson, thanks
<ogra> well, it might as well be make
<ogra> or something completely different
 * NCommander guess someone needs to run a build on 127.0.0.1 :-/
<amitk> slangasek: I would appreciate feedback on bug 184216. Is the fix to palo acceptable or does linux-libc-dev need to be tweaked?
<ubottu> Launchpad bug 184216 in palo "FTBFS in latest archive rebuild test" [High,Fix released] https://launchpad.net/bugs/184216
<doko> TheMuso, amitk: if you plan a linux-ports upload before the alpha, please fix #375509
<RainCT> Hm.. Am I missing something or binary packages glade-3 and glade-gnome-3 can be removed? They are NBS which only depend upon themselves
<ScriptRipper> cjwatson. what you told me did not completely help, sorry.
<ScriptRipper> cjwatson: how do i do this working also on debian then?
<ScriptRipper> it seems without --install-layout=deb switch binaries are then packaged somewhere else.
<ScriptRipper> but this switch does not exist in debian
<cjwatson> ScriptRipper: --install-layout=deb should work on Debian too ("work" in the sense of "do nothing"). Beyond that, sorry, I don't know; you have a few pointers now and I'm afraid you'll have to figure the rest out for yourself
<calc> cjwatson: is seed format some sort of wiki format?
<ScriptRipper> cjwatson: --install-layout=deb gives an error under debian
 * calc is looking at the mobile.jaunty bzr checkout and most of the files seem to be some sort of wiki format
<cjwatson> ScriptRipper: I'd have to do some reading of the distutils documentation to remember, and I'm doing other things at the moment that are demanding most of my concentration
<ScriptRipper> sure
<cjwatson> calc: it's descended from a wiki format, yes. See the germinate(1) manual page
<calc> cjwatson: ok thanks
<ScriptRipper> tnx so far, cjwatson
<micahg> Is this the place to discuss versions of packages in main?
<sbeattie> calc: is there a replacement for openoffice.org-headless in jaunty?
<calc> sbeattie: no it went away
<cjwatson> micahg: might be, depends on the question :-)
<micahg> user wants to know if php5 5.3 will make it into Karmic
<micahg> I was wondering what the policy of pre-release PHP versions is
<micahg> question 70902 in launchpad
<micahg> hmm, ,guess the bot doesn't do questions
<micahg> cjwatson: is this the place for my question ^^^^?
<ScottK> micahg: For php, #ubuntu-server is probably better.
<micahg> ok, thanks ScottK
<infinity> ogra: Certainly looks like a binutils segv to me.
<ogra> infinity, yeah
<infinity> ogra: I'm willing to believe in cosmic rays and other coincidences though, and give it a second try.
<infinity> ogra: If it fails again, you get to go bug-hunting! ;)
<infinity> ogra: (or blame doko)
<ogra> i'm starting a build on my babbage now
<infinity> ogra: Ahh, kay.  We'll wait and see if that links before we retry on the buildds, then/
<ogra> well, the buildds are surely faster
<ogra> and i wont stay up all night to watch the build fail ... expect earliest feedback tomorrow
<ogra> i literally just started the build now
<pitti> elmo, infinity, lamont: build killed by Ng, unping
<kees> fta: i'm not surprised gcc got more strict, but that warning isn't from any of the compiler hardening bits I turned on.
<fta> kees, it's not really a new warning as it's there since gcc3 but apparently, -Wstrict-aliasing now covers more cases, which is always good. I reported the problem upstream already (as i don't want to drop -Werror)
<cjwatson> directhex: sorry if I'm being thick, but libgnomeprint2.18-cil seems to be installable to me. What exactly is the problem?
<cjwatson> (as in, 'chdist apt-get karmic-i386 update && chdist apt-get karmic-i386 install lbgnomeprint2.18-cil' seems happy)
<greg-g> hmm, I can't view all of the tracks on the big schedule for UDS: http://summit.ubuntu.com/uds-karmic/2009-05-25/  on my screen I can only see up til the second Mobile room. Can't scroll.
<Pici> Theres a scroll bar on the bottom of the page
<greg-g> Pici: not in my Firefox
 * ogra suggests to not use an eee700 for the schedule :)
<greg-g> ogra: it is my 12.1" laptop ;)
<ion_> Can't you scroll with the arrow keys?
<greg-g> ion_: nope.
<steveire> Hey. I'm creating a string template system which will be an upstream dependancy for KJots and several other KDE apps. I want to make sure it's a good citizen in the packagers world. Can I ask stupid questions about that sort of stuff here?
<greg-g> I could scroll by dragging my mouse (to highlight text) but then I got the edge and Fx crashed
<greg-g> s/got the/got to the/
<greg-g> might be intermittent, in a meeting, will figure it out, just seeing if I was the only one.
<Riddell> steveire: go ahead
<pitti> Riddell: do you want kdesvn in main? (it's in c-m)
<steveire> Sorry, I shouldn't ask to ask I guess. Firstly, when do I bump the .so number of the library? When the vtable, but not the interface changes?
<Riddell> pitti: c-m?
<pitti> component-mismatches
<steveire> Also, the system is plugin based and ships with 3 plugin libraries. Should they have the same .so number as the 'core' library, or should they vary independantly.
<lamont> so how do I teach the gimp that I really really don't want it to come up full screen and on top everytime it launches?
<lamont> and how do I teach gnome developers to quit telling their apps to do that
<ogra> lamont, for a) i'd recommend devilspie (or the equivalent for compiz)
<ogra> b) will require a lot diplomacy i assume :)
<cjwatson> steveire: the SONAME field in your library should change any time binaries dynamically linked against the old library will break with the new library
<Riddell> pitti: universe is fine
<lamont> ogra: metacity, actually... no compiz turned on
<pitti> Riddell: hm, I wonder what pulls it in
<ogra> then devilspie should be fine to manipulate windows
<cjwatson> steveire: does anything outside your system need to link with the plugin libraries?
<Riddell> pitti: seems to be kdesdk   control: kdesdk-kio-plugins (>= ${source:Version}) | kdesvn-kio-plugins,
<Riddell> pitti: but that's an alternative dependency so should be fine to demote
<lamont> ogra: and firefox is in there too... it seems to like to grab focus when it finishes rendering the page, never mind that I've seen that, iconified firefox and gone on to other things... ZOMFG we're done rendering we better deiconify and be on top NAO
<pitti> Riddell: it's not in main
<pitti> Riddell: c-m just wants it to be in main
<lamont> </vent>
<Riddell> pitti: kdesdk-kio-plugins and kdesdk are in main
<ogra> lamont, http://foosel.org/linux/devilspie
<Riddell> steveire: plugins shipped with an app in KDE tend to be unversioned and in /usr/lib/kde4
<steveire> cjwatson: I don't think anything else needs to link against the plugins. I think they're loaded dynamically by the QtPlugin system. The details are a little fuzzy to me.
<steveire> Riddell: So if the plugins are unversioned, what happens if the phonon xine plugin gets backward incompatible changes?
<ogra> infinity, oh, my babbage was fast ! got the segfault here too
<ogra> infinity, so no need to retry on the buildds until doko has a fix for binutils
<Riddell> steveire: incompatible with what?  libphonon is the interface
<Riddell> steveire: phonon-backend-xine has a strict dependency on the version of libphonon, it needs to be recompiled for new phonons
<steveire> Yes, good point. Plugins are hidden behind the interface, so no problem, right.
<steveire> The other thing is header files. If I make a constructor of a public class take a SomeClass instead of an OtherClass in v0.2, you'll just make libgrantlee0.2-dev conflict with libgrantlee0.1-dev, right?
<steveire> So plugins don't need an so number at all, right?
<steveire> What if one app uses libgrantlee0.1, and another uses libgrantlee0.2, and the plugin interface changed in between. the plugins from v0.1 don't work with 0.2 and vice-versa.
<DarkCAMV> Hello, can somebody help with a trouble on wubi?
<DarkCAMV> look, I'm using Vista, and when I try to install ubuntu with wubi, it starts, but close without any advice, and ubuntu does not appear on boot list
<infinity> ogra: Alright, good to know.
<pitti> smb_tp: hm, http://people.ubuntu.com/~ubuntu-archive/testing/karmic_probs.html still has a lot of uninstallability for linux
<steveire> Anyone else have thoughts on my plugin issue?
<steveire> pitti: Hi. I think we met at lfcs.
<pitti> hey steveire
<rtg> smb_tp: ?
<smb_tp> <pitti> smb_tp: hm, http://people.ubuntu.com/~ubuntu-archive/testing/karmic_probs.html still has a lot of uninstallability for linux
<smb_tp> rtg, Do you know what might be the problem?
<rtg> smb_tp: LBM should be up to -5 by now
<rtg> and what is LRM doing in the Karmic archive?
<pitti> cprov, infinity, lamont: hm, any idea why palmer builds PPA packages? (eglibc from doko's PPA ATM)
<smb_tp> rtg, maybe not yet removed? or moved over from jaunty
<rtg> smb_tp: it should be removed
<smb_tp> rtg, LBM, Sorry, yeah. I uploaded only the kernel yesterday
<rtg> smb_tp: I uploaded LBM this AM (I think)
<pitti> linux-backports-modules-karmic-generic depends: linux-backports-modules-2.6.30-5-generic which doesn't exist
<rtg> pitti: i386/amd64 are ACCEPTED
<maxb> I'd assumed that certain key developers had special non-virtual PPAs to allow them to test-build on all architectures, no?
<pitti> rtg: ah, just NEWed? okay
<pitti> maxb: for i386?
<maxb> well, the builds go to the official build cluster rather than the normal PPA one
<rtg> smb_tp: the LBM issue should correct itself shortly. pitti - please remove the LRM package (for now)
<maxb> doko's eglibc is also building on sparc and armel right now
<smb_tp> rtg, Ah, ok. Thanks
<pitti> rtg: we removed the old binaries
<pitti> rtg: any idea why the i386 linux-generic/linux isn't installable?
<rtg> pitti: for which package? LRM?
<pitti> rtg: no, linux-meta
<rtg> pitti: I think because LBM in the archive is still the -2 ABI, whereas linux-meta wants -5
<pitti> rtg: but linux-image shouldn't pull in lbm surely?
<pitti> also, it works on amd64
<rtg> pitti: hmm, thats not what your web page says. it references both arches.
<pitti> rtg: ah, it was updated 10 minutes ago
<pitti> was still looking at the previous version
<directhex> cjwatson, your mirror needs cleaning up. the problem package is libart2.24-cil which is NBS in karmic (it was incorrectly ABI bumped from 2.0)
<pitti> rtg: just lbm now, so that should be good; I removed l-r-m binaries; thanks!
<directhex> cjwatson, try installing libgnomeprint2.18-cil and libgnomepanel2.24-cil at the same time
<cjwatson> directhex: "my mirror" is archive.ubuntu.com ;-)
<cjwatson> OK, thanks
<pitti> lool: mpi-defaults wasn't as trivial as you thought; it pulls in openmpi and lam, both of which we certainly don't want to support in main
<cjwatson> directhex: ah, yes, I see it. Dinner now, will sponsor later
<directhex> cjwatson, thanks :)
<pitti> Riddell: kdepim-dev depends libplasma-dev, but that package doesn't exist
<pitti> Riddell: I'm not actually sure why kdepim itself isn't installable, it seems to work here (amd64)
<pitti> Riddell: ah, you fixed pim-dev already, nevermind
<pitti> so that just needs publishing
<pitti> cprov, infinity, lamont: crested/amd64 is also building eglibc (PPA) now, thus effectively blocking much needed buildd power for hours
<linkz0r> hi
<linkz0r> can autotools generate makefiles that works on toolchains other than gcc-like ones?
<linkz0r> or can it work with compilers other than gcc?
<slangasek> amitk: https://bugs.launchpad.net/ubuntu/+source/palo/+bug/184216/comments/9
<ubottu> Launchpad bug 184216 in palo "FTBFS in latest archive rebuild test" [High,Fix released]
<slangasek> amitk: headers published to userspace should be usable; this is still a bug in linux-libc-dev
<calc> the seed desktop-common is what is in desktop that isn't specific to a particular desktop (eg gnome/kde/xfce)?
<cjwatson> linkz0r: autotools' overriding goal is portability, so I'd be astonished if it were restricted to just gcc. It certainly checks for other compilers
<cjwatson> or rather, it checks for gcc rather than assuming it
<linkz0r> hmm so how should i go on using other compilers?
<linkz0r> what do i need to add to support cl for example?
<Riddell> calc: it's what should be on both the ubuntu desktop and kubuntu disks
<calc> Riddell: ok
<calc> Riddell: i saw that unr pulled desktop-common so i guess it builds its desktop on top of that instead of ubuntu/kubuntu specifically
<Riddell> yes, unr has its own desktop seed
<tdapple> why do the gnome dev channels seem dead?
<tdapple> no traffic i mean
<calc> tdapple: on irc.gnome.org ?
<tdapple> calc, yes
<calc> tdapple: oh, probably just a lot of people idling
<tdapple> lots of people signed on...they just seem to be less chatty than kde folks i guess
<tdapple> KDE channels are like a social club
<cjwatson> linkz0r: cl?
<cjwatson> oh, Windows
<cjwatson> linkz0r: autoconf already seems to check for cl.exe
<cjwatson> linkz0r: it's one of the things looked for by AC_PROG_CC and AC_PROG_CXX
<cjwatson> linkz0r: so why not just try it and see if it works? :-)
<linkz0r> cjwatson: checking right now :)
<steveire> cjwatson: Is there any more information I can give you re https://bugs.launchpad.net/ubuntu/+source/parted/+bug/366282
<ubottu> Launchpad bug 366282 in parted "Install partitioner does not detect existing partition table" [Undecided,Incomplete]
<steveire> Or anything else I can do?
<cjwatson> steveire: oh, sorry, I've been remiss in not dealing with that, just been swamped with jaunty bringup - I'll try to look at it first thing tomorrow, or else remind me in European working hours
<cjwatson> s/jaunty/karmic/ of course
<steveire> Cheers.
<pitti> bdmurray: wrt your stock reply for hal-info patches, I'm upstream and commit patches directly there; so no need to ask bug reporters to forward it
<bdmurray> pitti: which standard response is that?
<pitti> bdmurray: https://bugs.edge.launchpad.net/ubuntu/+source/hal-info/+bug/355520/comments/2
<ubottu> Launchpad bug 355520 in hal-info "Philips SA52XX not recognized as a portable audio player " [Medium,Fix committed]
<bdmurray> pitti: I think that was a one off but noted
<pitti> bdmurray: ah, I saw the same response in the previous bug that I just committed
<pitti> bug 356019
<ubottu> Launchpad bug 356019 in hal-info "30-keymap-lenovo.fdi patch for X200 Tablet" [Medium,Fix committed] https://launchpad.net/bugs/356019
<bdmurray> pitti: other than flagging them as patch should anything else be done to bring them to your attention
<pitti> bdmurray: "triaged" is really good
<pitti> they stand out
<ScottK> Of course that's a restricted status.
<bdmurray> pitti: okay, a 2 off response then
<pitti> bdmurray: heh, ok; I thought you had some clever scripts which do that
<bdmurray> pitti: not for that one
<pitti> kirkland: do you want to keep byobu-extras in main? if so, please seed it somewhere
<kirkland> pitti: yes, please
<kirkland> pitti: okay, will do
<cody-somerville> Does Linux have the fchroot syscall?
<dtchen> not that i'm aware.
<jjohansen> no it doesn't
<torkiano> hello all, only curious; is necessary a special requisite to attende to uds ? is a open meeting?
<jpds> torkiano: Open. You just have to get there.
<pitti> calc: was the removal of openoffice.org-kde more like a merge accident? should we put it back?
<calc> hold on, running to meet UPS
<calc> pitti: so apparently the kde folks in Debian want it gone or something to that effect
<calc> pitti: not sure what we want to do long term, it sounds like Debian is attempting to drop KDE3 libraries
<calc> but that might be wrong
<ScottK> calc: Yes,  Debian KDE people are being more agressive about dumping KDE3 stuff.
<pitti> calc: that's what the changelog said anyway
<pitti> but Riddell said Kubuntu still wants it, AFAIUI?
<calc> pitti: are we planning on keeping KDE3 around after Debian drops it?
<ScottK> I'm reasonably certain we still want it until the KDE4 version is usable.
<calc> pitti: well for jaunty anyway yea
 * pitti takes that as "karmic"
<pitti> calc: I don't know, that's a q for the kubuntu folks
<calc> ScottK: afaik no one is working on kde4 support for OOo
<calc> pitti: ok
<calc> Riddell: ping
<ScottK> calc: Yes.  It's a problem.
<pitti> anyway, I'm about to fall off my chair; good night, see you tomorrow!
<calc> wow official Ubuntu box tape, heh
<dtchen> 'night pitti
<nixternal> ScottK and calc: speaking of OOo KDE4, there was a request, I think from Riddell actually, for someone to help doing the work...I looked into it but quickly received one hell of a head ache...so ScottK if it is something that is needed, which it is, we need to get people working on it...this would be a perfect opportunity for Kubuntu to really contribute back
<ScottK> nixternal: I agree.
 * nixternal looks at it again
<nixternal> this time with a 12-pack :p
<nixternal> of course this -> http://kde.openoffice.org/ <- doesn't help much
<ScottK> I think SuSE was working on it last, but I'm not sure.
<nixternal> not working on it, just sponsoring it last time I asked
<nixternal> I tried to get a hold of the original person on the project, it was impossible
<slangasek> pitti: could you have a look at the fdi file and instructions I provided in https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/360795/comments/17, and tell me if I've done something obviously wrong?
<ubottu> Launchpad bug 360795 in gnome-power-manager "Strange LCD brightness up function implementation on the Acer Aspire 5720" [Undecided,Confirmed]
<calc> the last person to work on KDE stuff for OOo was kendy at Novell
<calc> he still works on OOo but was too busy at least the last time I asked about the KDE4 stuff
<nixternal> groovy, thanks calc for that
<Riddell> pong calc
<seb128> lamont: could you have a look to the patch in bug #348990?
<ubottu> Launchpad bug 348990 in postfix "Deinstallation doesn't delete all files" [Low,Confirmed] https://launchpad.net/bugs/348990
<seb128> mathiaz: hi, could you review bug #365390?
<ubottu> Launchpad bug 365390 in dovecot "postfix: invalid value for smtpd_tls_mandatory_ciphers in main.cf" [Undecided,Confirmed] https://launchpad.net/bugs/365390
<mathiaz> seb128: sure
<seb128> mathiaz: thanks
<seb128> mathiaz: #371829 has been updated since your comment too if you want to re review this one
<seb128> mathiaz: and bug #372358
<ubottu> Launchpad bug 372358 in openvpn "Please merge openvpn 2.1~rc15-1 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/372358
<mathiaz> seb128: right - I'll have a look at these too.
<seb128> mathiaz: thanks
<mathiaz> seb128: are you clearing up the sponsorship queue?
<seb128> I'm trying to clean a bit the sponsoring list before having dholbach exploding ;-)
<seb128> mathiaz: yes, it's over a screen long for main again so trying to get it back under control
<seb128> mathiaz: sorry for the pings if you watch it regularly but I know that some people don't and they don't notice things waiting there
<seb128> so it's just a gentle reminder ;-)
<mathiaz> seb128: ok
<lamont> seb128: will do
<seb128> lamont: thanks
<lamont> I also need to package the lastest postfix version
<lamont> seb128: though I expect you want that after alpha - the patch before?
<seb128> lamont: I don't really care before or after alpha, I just try to clean the sponsoring list
<seb128> lamont: having a postfix upload should not impact on the cds since it's not installed by default
<lamont> cool
#ubuntu-devel 2009-05-13
<maxb> Is there a discussion anywhere of how the change of keymap support away from hal to udev-extras is supposed to work?
<maxb> (I find that my keymap has spuriously reverted to US layout in current karmic)
<DarkRavin> ok i need help i installed the supybot and now i cant find it can someone help
<britton> Has anyone noticed that the daily UNR build link is broken?
<britton> http://cdimage.ubuntu.com/ubuntu-netbook-remix/daily-live/current/jaunty-netbook-remix-i386.img
<StevenK> That's because Jaunty is released
<StevenK> And because the dailies are broken ...
<britton> What image is suggested for UNR users? The Download link on the UNR maing page points to the broken link.
<britton> https://wiki.ubuntu.com/UNR#Downloading%20the%20Image
<britton> I'll update the link if someone can point me to an alternative to the daily builds.
<StevenK> britton: The dailies for Karmic should start appearing soon, but the link to UNR 9.04 is on http://www.ubuntu.com/getubuntu/download-netbook
<britton> Thanks StevenK. I've updated the page referencing the broken daily builds with this link.
<britton> https://wiki.ubuntu.com/UNR#preview
<StevenK> britton: I'll talk to a few people to get that page updated to reference Karmic properly, too. Thanks!
<bryce> launchpad is giving me a "Cannot find your account" warning starting today.  However it otherwise appears to be working ok.
 * calc beats ooo-l10n with a big stick
 * calc wishes he had a fast enough system to actually build that pos instead of usually just uploading and praying it works
 * calc is going to have to upload it again but this time not until after he has done a full build how ever many hours that ends up taking :-\
<TheMuso> calc: Does it take longer than OO itself?
<calc> TheMuso: yea
<TheMuso> ...ouch.
<calc> TheMuso: ooo-l10n builds all of ooo then does langpack stuff on top of that
<calc> FAIL :-\
<TheMuso> Thats... painful.
<calc> and unfortunately it doesn't fail until the install stage now
<calc> and iirc the install stage can't be rerun due to how debian mangles it
<TheMuso> Riiight.
<calc> so i can't just keep rerunning debian/rules install until i fix all the bugs :\
<calc> and these bugs also would not occur if we didn't have it split into a separate source for the l10n stuff :\
<TheMuso> Yep.
 * calc isn't sure if having it split actually helps anything, it does seem to cause a lot of pain though
<TheMuso> I don't envy you.
<doko> it would help if the merge of the launchpad translations would be worked on
<calc> we talked about that a while back afaict we have no way to even send lp translations back to upstream, which aiui we can do for other things on lp?
<calc> if that is true we probably shouldn't be hosting translations for OOo until that works
 * calc isn't sure if we could even do that anyway due to the licensing issues involved
<doko> and that hinders ubuntu to merge these in the  l10n package? no.
<calc> well it was on the list of things we should we do for OOo l10n support in the email i got a while back
<calc> at 20% time i barely have time to do an OOo build and still be within time constraints
 * calc has been spending way more than 20% the past couple weeks
<calc> of course that isn't to say other people can't fix those issues :)
<calc> doko: i don't see how you can manage to get all your foundations work done within 20% time either, heh
<ScottK> calc: In the Kubuntu team we've discussed we might give better translation support to our users if we avoided LP hosted translations entirely.
<calc> ScottK: yea
<pitti> Good morning
<nixternal> good morning to you sir
<ajmitch> hi pitti
<pitti> calc: meh, oo.o-l10n FTBFSed with "no space left on device"
<ajmitch> ouch
<nixternal> build oo.o in the cloud!
<ttx> nixternal :)
<ajmitch> nixternal: you'd need a mortgage to pay for the build time
<StevenK> Ouch!
<geofft> ... how much space was originally left on device?
<nixternal> hehe
<pitti> calc: trying again on vernadsky
<pitti> meh, another ten hours of uninstallability
<pitti> but at least the alternates should be buildable now
<dholbach> good morning
<nixternal> good morning
<nixternal> why does everyone wake up when I am going to bed? you all need to get on a different routine already!
<jussi01> nixternal: because you are weird...? :D
<nixternal> that has nothing to do with you all waking up when I go to bed :p
<geser> good morning
<geser> nixternal: why are you working when everyone else is sleeping? :)
<pitti> hey geser
<geser> Hi pitti
<nixternal> geser: because I am dedicated :)
<nixternal> which means meeting in like 8 hours right dholbach?
<nixternal> not 7 hours, hoping you figured out the time changes :p
<dholbach> nixternal: sounds good to me
 * nixternal kicks kde svn in the pants - hurry up already!
<nixternal> geser: the truth to me working while everyone is sleeping, is because kde svn :p
<pitti> soren: kvm performance in karmic for the d-i text mode is horrible -- did it change the defautl emulated graphics hardware?
<pitti> sommer: in jaunty I noticed that only the default crappy graphics hardware worked well, all the "better" ones had utter performance problems
<soren> pitti: Not as far as I know.
<pitti> soren: ^ (sorry, sommer)
<soren> pitti: Frankly, I think they've all sucked all the time.
<pitti> well, the default worked well except for UNR
<pitti> now you can see every single character block being updated
<soren> :(
<pitti> (apart from kernel I/O performance becoming worse and worse from intrepid to karmic as well *sigh*)
<maxb> pitti: The most recent hal upload makes my XKB layout fall back to "us" - how is this supposed to be configured in the new world of udev-extras?
<pitti> maxb: not yet, X.org first needs to learn how to talk to udev
<maxb> ah. might want to releasenote that for alpha 1 then :-)
<pitti> well, or fix
<pitti> maxb: can you please open a bug about it? first time I hear about it
<pitti> let's debug it ther then
<pitti> maxb: got some minutes for tracking this down?
<maxb> Which package should it be on? I don't really understand how the current hal<->xorg magic works, just that it used and to and doesn't any more - let alone how things are supposed to work now?
<pitti> maxb: hal, please
<maxb> I can spare some time now yes, if that's good?
<pitti> maxb: I think I'm 80% sure that I know how to fix it
<pitti> maxb: yes, please
<pitti> we can still fix it for the alpha
<maxb> It seems someone has beaten me to reporting it:
<maxb> https://bugs.launchpad.net/ubuntu/+source/hal/+bug/375618
<ubottu> Ubuntu bug 375618 in hal "does not pass xkb* settings to xorg server" [Undecided,New]
<seb128> pitti: weird that you didn't get the keyboard issue, Keybuk mentioned it yesterday as a gnome-keyring issue and it did the same on my desktop there, I expect it happens for everybody
<pitti> seb128: well, I'm _using_ US
<pitti> so I never noticed, sorry
<seb128> ah right
<seb128> we should force the platform team to use non english locales and keyboards ;-)
 * TheMuso would like that if there was an .au layout.
<TheMuso> Or if I could use dvorak.
<StevenK> Gah, I was about to say "for want of a .au layout"
 * StevenK glares at TheMuso 
<pitti> seb128: I'm using de_DE.UTF-8 with langpacks, but using a non-US keyboard layout for a programmer is a royal pain :/
<TheMuso> lol
<seb128> pitti: I was just jocking don't worry, in any case many people have the bug if you need testing or details
<pitti> let's use bug 375618 then
<ubottu> Launchpad bug 375618 in hal "does not pass xkb* settings to xorg server" [Undecided,New] https://launchpad.net/bugs/375618
<pitti> maxb, seb128: I attached a test FDI to the bug, could you please test?
<maxb> It appears to hardcode "us"... is that really supposed to make my layout be "gb" ?
<pitti> it sets the evdev property
<pitti> 10-x11-keymap.fdi should set the real one later on
<pitti>         <match key="input.xkb.layout" exists="true">
<pitti>             <append key="info.callouts.add" type="strlist">debian-setup-keyboard</append>
<pitti> that didn't get triggered any more
<maxb> ok, restarting X...
<seb128> pitti: no change
<maxb> ditto
<pitti> can you please attach your lshal output to the bug?
<pitti> (you did restart hal, didn't you?)
<maxb> (even after a full reboot just to be sure)
<pitti> ah, crap, my bad
<seb128> I did reboot
<pitti> xorg >> x11
<seb128> $ lshal | grep layout  input.xkb.layout = 'us'  (string)
<pitti> sorry
<pitti> seb128, maxb: can you please rename the file to "10-keymap.fdi"?
<maxb> That works :-)
<pitti> okay
<pitti> now please delete that file again, it was just a test
<maxb> Do you want lshal still, if so before or after deleting?
<pitti> maxb: not necessary
<pitti> I'm preparing a better solution
<pitti> I just needed you to try this as a first test to rule out the hal-setup-keymap callout
<seb128> pitti: that works now
<lool> pitti: Hmm indeed, the packaging of mpi-defaults was trivial, but not its deps -- on some arches -- sorry about that
<pitti> seb128, maxb: ok, can you please try https://bugs.edge.launchpad.net/ubuntu/karmic/+source/hal/+bug/375618/comments/7 now? this is a better solution
<ubottu> Ubuntu bug 375618 in hal "does not pass xkb* settings to xorg server" [Undecided,New]
<pitti> lool: I uploaded a new boost without MPI for now
<seb128> pitti: is there a way better than rebooting every time, I just restarted all my applications
<pitti> seb128: restart hal and gdmflexiserver -l should work
<lool> pitti: I think mpi-defaults can build without the heavy bdeps since it builds without them on some arches; perhaps we could simply avoid them on all arches
<pitti> since that starts a new x
<seb128> ok
<pitti> lool: yeah, I didn't feel like really tracking down this last night; if you see a better solution, please go ahead
<seb128> pitti: that one doesn't work
<maxb> pitti: Oh! It's working here
<seb128> wait
<pitti> maxb: yay
<lool> pitti: That's good enough for A1 and I don't want to touch it before A1 :)
<pitti> lool: right, I meant after A1 :)
<pitti> seb128: if it doesn't work, can you please attach lshal to the bug?
<seb128> pitti: sorry that works, this command line didn't have a sudo cookie and was waiting for my password
<pitti> heh
<pitti> seb128: glad to hear this
<pitti> seb128, maxb: many thanks for your time
<seb128> thank you for the quick fixing
 * seb128 hugs pitti
<pitti> and sorry for messing this up
 * pitti uploads
<seb128> karmic would be boring without some bugs ;-)
<maxb> Hey, it's pre-A1, I'd be shocked if nothing broke
 * directhex uploads some bugs to make seb128 feel better
<pitti> that's true, karmic is far too stable for my taste :)
<directhex> pitti, mono 2.4 packaging is due soon, which should break a few things. it'll shuffle packages on the CD at least, which will hopefully break something
<davmor2> pitti: if it cheers you up upgrading a couple of days okay hal wouldn't restart :)
<davmor2> s/okay/ago
<pitti> davmor2: yeah, I heard about that one, but that was Scott's fault :)
<davmor2> pitti: and if you going to break something might aswell break it good right :D
<pitti> just enable KMS and UXA, that should be enough breakage
 * pitti has used that for about a week now
<pitti> nicely breaks suspend
<pitti> at least with my external monitor
<tjaalton> pitti: did you break the X hal callout script? :)
<tjaalton> at least it's not run anymore
<pitti> tjaalton: just uploaded a fix
<tjaalton> pitti: oh cool
<pitti> tjaalton: bug 375618
<ubottu> Launchpad bug 375618 in hal "does not pass xkb* settings to xorg server" [High,Fix released] https://launchpad.net/bugs/375618
<tjaalton> yeah, read the changelog
<pitti> soren: also, in karmic kvm I just get 800x600; do you get the same?
<TheMuso> c/c
<soren> pitti: I don't test desktop stuff much, to be honest.
<doko> tjaalton: any idea why xvfb fails in the openjdk-6 build on sparc?
<tjaalton> doko: not offhand, although it sounds familiar
<pARAd0X85> hi
<pARAd0X85> where can we find the source for evtest ?
<tjaalton> pARAd0X85: apt-get source joystick
<tjaalton> utils/evdev.c
<tjaalton> or http://people.freedesktop.org/~whot/evtest
<pARAd0X85> tjaalton, thanks
<lool> What's the proper way to put translation bugs on the radar of translators?
<LordKow> lool: i think the triager is supposed to subscribe the proper translation team for that package
<seb128> lool: I usually assign to language-pack-gnome-<locale> and ubuntu-l10n-<locale>
<dpm> lool: alternatively, if it is a general i18n issue, it can be commented on ubuntu-translators, tagged as i18n or listed there -> https://wiki.ubuntu.com/TranslatingUbuntu/Issues
<lool> It's an issue specific to Spain's Spanish versus South-American Spanish variants
<lool> I sub-ed ubuntu-l10n-es and will reassign; thanks!
<lool> (375457 was the bug)
<seb128> bug #375457
<ubottu> Launchpad bug 375457 in language-pack-gnome-es "Incorrect translation in South-American Spanish for Video folder" [Medium,New] https://launchpad.net/bugs/375457
<taavikko> does apport-collect provide the same information as ubuntu-bug? with the distinction that collect csan can be used to add info on a already existing bug.
<pitti> taavikko: pretty much, yes
<taavikko> thanks pitti.
<Keybuk> pitti: you're running with DRI2/GEM/KMS/UXA right?
<pitti> Keybuk: yes
<Keybuk> pitti: what did you do to turn that on?
<taavikko> also, does this work correctly: apport-collect `pidof process` bugnumber ?
<pitti> taavikko: apport-collect doesn't work with pids, sorry (that would be pointless)
<pitti> Keybuk: Option "AccelMethod" "UXA" -> UXA/GEM
<pitti> Keybuk: $ cat /etc/modprobe.d/i915-kms.conf
<pitti> options i915 modeset=1
<taavikko> ok, confusion sets in :)
<pitti> Keybuk: see https://wiki.ubuntu.com/X/KernelModeSetting
<davmor2> pitti: does it make a difference?
<pitti> davmor2: you can switch between X and VT in no time with no flicker
<pitti> and the text consoles are awesomely big (160x50 for me)
<pitti> davmor2: oh, and did I mention that it breaks suspend for me with external monitor? :-)
<directhex> calc, "Closed, fixed in OOo 3.1 final release."
<Keybuk> pitti: a little bit of video corruption on resume, but otherwise works
<Keybuk> suspend/resume is *FAST* with this
<pitti> Keybuk: haven't tested suspend with internal screen yet
<pitti> I guess I'll start searchign workarounds for suspend problems on Sunday, when packing my stuff for allhands/uds
<Keybuk> are you at somehands?
<pitti> Keybuk: yes
<pitti> Keybuk: I'm not sure how many hands I need to bring, though
<Keybuk> ah
 * Keybuk is not Special
<ogra> pitti, the name indicates "more than one" :)
<pitti> ogra: I think I can just about provide that
<ogra> heh
<dholbach> so how's alpha-1 looking?
<pitti> dholbach: we're about this -><- close to producing alternates which will actually give a reasonable isntall
<ogra> apart from armel :(
<quadrispro-acer1> hi guys! what is the policy for the packages sync'd from debian-multimedia?
<cjwatson> ogra: is somebody working on that kernel build failure?
<ogra> cjwatson, yes, trying a build with the former binutils here atm
<cjwatson> quadrispro-acer1: happy to resync from there on request (~ubuntu-archive subscribed to bug), anything more complicated I'm not sure
<quadrispro-acer1> cjwatson: ok, and what about NEW packages?
<ogra> i just did one with V=1 on the make command but that didnt get me very far apart from showing the actual cmd and ending with a segfault again
<quadrispro-acer1> I uploaded a couple of pkgs to REVU, probably it's unnecessary but I don't know...
<cjwatson> quadrispro-acer1: revu probably isn't very useful. file a bug and subscribe ubuntu-archive and we'll have a look
<quadrispro-acer1> ah, ok
<quadrispro-acer1> thanks cjwatson
<soren> Our notifications system uses D-BUS, right?
<soren> Exclusively?
<pitti> soren: communication between the application and notify-osd happens over the session d-bus, yes
<soren> pitti: Thanks.
 * soren ponders dbus-over-ssh
<Keybuk> soren: the whole D-Bus when you're running a remote X program problem has never really been solved
 * ogra would pay soren a box of beer 
<ogra> and you would get a trophy from the ltsp guys :)
<soren> It really shouldn't be that hard, should it?
<Keybuk> it isn't hard at all
<ogra> Keybuk, there is gabrial, but its odd
<Keybuk> it's just manically insecure
<ogra> *gabriel
<soren> Start a listening unix socket on the server, and just put whatever comes in into the client's dbus server.
<Keybuk> as long as the remote machine is the same architecture, of course :p
<Keybuk> soren: you don't even need to do that
<Keybuk> just make your desktop D-Bus session listen on TCP
<Keybuk> and tunnel that over ssh to the remote end, adjusting the DBUS_SESSION_BUS_ADDRESS envvar
<ogra> http://www.eldemonionegro.com/wordpress/archivos/2008/05/22/howto-to-intercomunicate-processes-in-differentremote-machines-through-dbus
<Keybuk> that'd work too
<Keybuk> but then you'll hit a problem if the machines are different ;)
<Keybuk> D-Bus kinda assumes the same byte sizes and endianness
<Keybuk> much more interesting would be a way to mesh bus daemons together
<Keybuk> so you could run a dbus-daemon on the remote machine
<ogra> ltsp is looking into this since years and we havent found a safe answer yet ...
<soren> Keybuk: I see. Would it be possible to translate that or can you define arbitrary data types?
<Keybuk> and have that and the dbus-daemon on the local intercommunicate
<Keybuk> of course, then you still hit the activation problem
<Keybuk> if Rhythmbox on the remote machine makes a method call that would activate a service
<Keybuk> on which machine do you activate the service?
<Keybuk> soren: the D-Bus data types are a fixed part of the specification
<soren> Keybuk: So it should totally be translatable by a proxy of some sort.
<ogra> as Keybuk mentioned, thats not the main prob, the merging of the daemons is
<ogra> and the priorization where to do what
<Keybuk> for example, a client may activate a service and expect some non-dbus-bound communication as a result
<Keybuk> the most trivial example being DeviceKit or HAL
<ogra> right, thats the main focus of ltsp
<Keybuk> if rhythmbox asks to mount something, it probably expects that mount to happen locally
<pitti> stgraber: how do I change http://iso.qa.ubuntu.com/qatracker/ to not say "candidate images for the Ubuntu 9.04 release" any more?
<Keybuk> ie. on the remote end
<Keybuk> not on the server end
<ogra> with network forwarding to the actual desktoip session so it can access it
<Keybuk> a lot of the problem with ltsp is you actually want to mount on the server, but then somehow make that mount also available on the remote/client
<ogra> no, the other way round
<Keybuk> no
<Keybuk> the way round *I* said
<ogra> the HW is always on the client
<Keybuk> remember that in the X architecture, the server is the machine the user is sitting on
<Keybuk> and the client is the machine the application is running on
<ogra> if i plug my ipod into the client i want a message to go to the server
<Keybuk> you plug your ipod into the server ;)
<ogra> and i want gvfs to initiate a network mount of the client HW to the desktop session
<ogra> why would i go to the server room to do that ?
<Keybuk> ogra: either you're being deliberately stupid, or deliberately confusing
<Keybuk> please stop
<ogra> oh, i missed your referral to X above ... thats not how we handle ltsp :)
<Keybuk> X is the key component here
<Keybuk> so we use its terminology
<ogra> well ... if you use XDMCP which we dont
<ogra> since ltsp5 exists
<Keybuk> and since we're also talking about D-Bus, and its terminology happens to fit, then we can continue to use its terminology
<Keybuk> the Server is the machine that the user sits on
<Keybuk> the Client is the machine that the application runs from
<Keybuk> the Server has the X Server and the D-Bus Bus Daemon (ie. server)
<Keybuk> the Client has the X Client (application) and the D-Bus Client
<Keybuk> the user sits at the Server
<Keybuk> the user plugs their iPod into the Server
<Keybuk> which is the machine also running the HAL Daemon (ie. server), etc.
<pitti> stgraber: unping; it was too obvious :)
<ogra> right, if you plug in your ipod, hald now needs to send a dbus message to the client that triggers an ltspfs mount of the ipod so it appears in the desktop sessiojn
<Keybuk> exactly
<ogra> we were largely saying the same, you just used ancient terminology :)
<Keybuk> I use the *correct* terminology
<Keybuk> so the problem is never really that D-Bus isn't tunneled from the Client to the Server then they are on different machines
<Keybuk> the problem is that it's not as simple as tunnelling it at all!
<calc> pitti: ok if it fails again (i think it probably will, sigh) i know how to fix it this time, i had to run a full ooo-l10n build at home which takes over 8hr to see what was going on, it failed then i think i fixed it and have to run it for another 8 hours (gar)
<Keybuk> if a remote client needs filesystem access to something on the server, you need to have special multi-seat software broker that
<Keybuk> (true for any device access, in fact - e.g. mtp)
<calc> pitti: but i won't be uploading it again until i am certain it builds for me
<pitti> calc: okay; we found a workaround for now, to make the alternates installable without -l10n
<pitti> brb
<calc> pitti: ok
<Keybuk> much more fun ensues when you talk about power management <g>
<ogra> well, and the tunnel wouldnt be any problem we have already various ssh tunnels established on ltsp
<calc> pitti: apparently the install target was reworked between 3.0 and 3.1 and i managed to miss it somehow
<Keybuk> if the client and server both have batteries
<Keybuk> which battery should you show on the panel?
<Keybuk> should it matter whether the battery applet is on the same machine as the server or the client?
<calc> pitti: which causes build failures due to ooo-l10n being split out as a separate source
 * calc will be glad when we can get rid of that mess
<ogra> well, i would show both, the prob here is how to distinguish them visually
<ogra> i want to know when my thin client runs out of battery as much as i want to know if the machine running the desktop session dies soon
<Keybuk> but if the battery on one of them runs out
<Keybuk> you need a policy that is multi-seat aware
<Keybuk> it's all good fun :p
<ogra> in case of batteries, both of them are equally important ... but batteries are definately not the typical HW :)
<Keybuk> this is why the whole "D-Bus over SSH" problem has never been "solved" upstream
<Keybuk> it's a much more difficult problem than it first appears
<ogra> yeah
<ogra> htough its not actually a dbus problem but rather the on top apps like hal/devkit
<ogra> in case of a std. ltsp setup you can simply ignore the system daemon on one side
<ogra> since all you want is diredct interaction with the thin client HW through the dbus connection
<ogra> if i click shutdown in fusa i want that to power down my thin client, if i use a mic on a thin client i want that to be forwarded to the desktop session, real access to the ltsp server HW is rarely needed
<soren> Keybuk: You clearly thought much more than I did :) All I really wanted to do was to be able to run notify-send on my server and have it magically pop up on my laptop.
<Keybuk> but if the desktop session machine is shutdown, or power goes out, etc. you need the thin-client machines to be notified
<soren> :)
<ogra> yeah
<Keybuk> if a removable device is plugged into the desktop session machine, or a CD, etc. you probably want to be able to access that from thin-clients logged in as an administrator
<ogra> but i can do that with mounting it under /mnt ... thats really a corner case
<ogra> i agree about the power down though
<Keybuk> to solve things properly, you never leave a corner case undusted
<ogra> right, but it wouldnt be in my main focus ... rather something lower on the TO=DO
<ogra> *TODO
<ogra> indeed its convenient ...
<ogra> but not a must have
<ogra> though if you add polkit to the picture that really gets messy :)
<ogra> and consolekit
<hyperair> anyone here dealing with gnome-system-tools?
<hyperair> bug #214720
<ubottu> Launchpad bug 214720 in nautilus-share "Cannot set LAN name without console" [Wishlist,Confirmed] https://launchpad.net/bugs/214720
<seb128> hyperair: nautilus-share != gst
<hyperair> seb128: yes i know.
<hyperair> seb128: i'm about to reassign the bug to gst
<seb128> and "no"
<seb128> nobody is working on it either upstream or in ubuntu
<hyperair> seb128: because simply put, nautilus-share is not meant to have any settings further than just configuring usershares
<mercidia> hi, do you know where i could get help on app development using uinput driver?
<hyperair> seb128: you mean gst is not being developed upstream or in ubuntu?
<seb128> indeed
<seb128> or rather nobody is working onit
<seb128> on it
<hyperair> seb128: but the functionality is there, just hidden from view.
<seb128> it's a GNOME software still but without an active team working on it
<hyperair> i see.
<hyperair> it would be awesome if this could be made to integrate with samba's usershares though
<Keybuk> ok, this is just the worlds most insane gcc syntax
<Keybuk>  do {
<Keybuk>      __label__ enomem;
<Keybuk>      /* code that might goto enomem */
<Keybuk>  enomem: __attribute__ ((unused));
<Keybuk>  } while (0);
<pitti> Keybuk: suspend with KMS> wow!
<pitti> I mean WOOOWW!
<pitti> bryce: that's awesome
<Keybuk> pitti: one of the WHOLE POINTS of KMS is that is makes the whole suspend/resume milarky easier, isn't it? :p
<pitti> Keybuk: now I just want that working with my external monitor, too, isntead of staying black :)
<lool> I guess usb-creator can't create USB images from alternate CDs, can it?
<ion_> keybuk: What's the purpose of that code?
<cjwatson> lool: should be able to
<lool> Cool, thanks
<Keybuk> ion_: C99/GCC equivalent of "break from outer loop"
<Keybuk> ion_: the __attribute__ ((unused)) is there because this is generated code - so I don't know whether the code in the loop is actually going to use this facility
<Keybuk> I found it odd that the attribute goes on the label itself, not the __label__ pre-declaration/localising
<Keybuk> and that you need the ";" on the end of the label ;)
<ion_> :-)
<cjwatson> you've needed ";" on the end of labels at the end of blocks for a little while now - that strictness was added in gcc 3.something IIRC
<cjwatson> or at any rate several releases ago
<cjwatson> I remember tbm filing a bunch of bugs about it
<Keybuk> yeah
<Keybuk> though since that's the primary use of local labels, you'd've thought they wouldn't care about them
<cjwatson> I assume the grammar says that label comes before a statement
<Keybuk> though I guess it makes local-labels-combined-with-statement-expressions nice ;)
<cjwatson> *my* primary use of local labels is: out: do_cleanup_work(); }
<cjwatson> common idiom in the kernel too
<Keybuk> ({ __label__ gotit; int ret; /* something complicated */ gotit: ret; })
<Keybuk> cjwatson: do you mean local labels, or just labels?
<cjwatson> oh, what's a local label?
<Keybuk> local labels are labels with block scope
<cjwatson> block-local or what?
<cjwatson> ah, didn't know about those, ok
<Keybuk> things to fix if we ever got to drop backwards compatibility for C/POSIX/etc.
<Keybuk> the fact that somebody couldn't spell "signalled"
<ogra> cjwatson, since you expressed interest before ... bug 375991 is about the segfault
<ubottu> Launchpad bug 375991 in binutils "ld segfaults building a kernel image on armel" [Undecided,New] https://launchpad.net/bugs/375991
<joaopinto> where can I find the latest definition for a debian control file format ? The debian policy manual documentation referes format 1.5, .changes files generated on jaunty use format 1.8
<directhex> yay, dell's new 10" laptop has ditched poulsbo
<cjwatson> joaopinto: the .changes format is not the same as the control file format
<cjwatson> joaopinto: the Debian policy manual (or I suppose here the Ubuntu policy manual, but there are no significant changes to the control file format in that) is authoritative
<joaopinto> cjwatson, I am reading the .changes description, it links to http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Format for the Format field
<joaopinto> the ubuntu policy manual mentions the same 1.5 version
<cjwatson> policy probably shouldn't claim those are in sync; they aren't necessarily
<cjwatson> .changes format 1.6 was roughly dawn-of-time (May 1999) and I'm not sure what it did; .changes 1.7 added Changed-By and adjusted Maintainer to be the actual maintainer rather than the changer; .changes 1.8 added SHA1 and SHA256 checksums
<joaopinto> I am writing a class to work with debian control files, and I want to be sure it can be sone with a single generic class able to cope with .dsc and .changes
<cjwatson> joaopinto: the syntax is the same; the semantics differ
<cjwatson> you'll have to have variations on that class to cope with the different semantics *anyway*
<cjwatson> you should probably just read dpkg-genchanges etc.
<liw> "Sorry, there was a problem connecting to the Launchpad server." -- I keep getting this today, did I miss a Launchpad maint announcement?
<Keybuk> it's been doing that for the past few weeks
<Keybuk> I think they've reduced the timeout for page returns in an attempt to improve performance
<liw> ok
<Keybuk> (ie. if they reduce the timeout, then they get the errors so know what to fix)
<jdong> wouldn't it be even more effective if they just served an ErrorDocument to everyone anyway? *ducks*
<liw> they've certainly improved the time from "click" to "annoyed", but I'm willing to suffer that if they'll make it better in the end
<jdong> well IMO "reducing the timeout and resorting to error" still doesn't sound like a necessary solution to the problem.
<ogra> jdong, and use the DB servers as backporter machines instead ?
<jdong> surely they can time render response and quietly generate alerts without messing with the userbase, right?
<Keybuk> jdong: it only effects edge
<jdong> ah
<liw> I'm not using edge
<Keybuk> oh
<Keybuk> maybe it doesn't then ;)
<jdong> :)
<seb128> the performance thing is only edge I think
<apw> i think there is a general bug with some of the backends, does the page work when you reload each time?
<seb128> other issues should be signaled on #launchpad so they can look at the bug
<jdong> it seems to work for me after 1-2 reloads.
<liw> apw, reload's worked every time I've tried, but it's only been a handful of times today
<apw> worth mentioning on #luaunchpads, but if it oops the first time, and works the second it is likely the ongoing 'backend broke' bug which is still being chased
<jdong> alright, I'll holler the next time I come across it again
<jelmer> liw: hi
<jelmer> liw: are you by any chance aware of HTML-pretty printers for python coverage output?
<liw> jelmer, greetings and salutations!
<liw> jelmer, I have never even heard of them; I mainly use coverage.py via python-coverage-test-runner which calls me names if my test suite is not 100%
<liw> (well, 100% minus the parts I've explicitly marked outside coverage testing)
<tjaalton> ogra: hey, where did you get the evtouch 0.8.8 tarball? upstream homepage doesn't have it
<ogra> it should
<jelmer> liw: ah, I probably should give that a try too :-)
<tjaalton> ogra: oh right, wrong page
<jelmer> liw: Thanks, I'll keep looking
<ogra> tjaalton, yeah al always fall into that trap too :)
<ogra> s/al/i/
<liw> jelmer, have you tried the -r and -m options to coverage.py (or python-coverage)? depending on what you want to do
<tjaalton> ogra: it'll probably be corrected now :)
<ogra> tjaalton, hopefully :) btw Bug 317094 has quite a lot of data now ... we'll need to get that in ;)
<ubottu> Launchpad bug 317094 in xf86-input-evtouch "evtouch meta bug to collect lshal info" [Undecided,Confirmed] https://launchpad.net/bugs/317094
<tjaalton> ogra: also, I noticed that evdev failing to calibrate was a bug
<ogra> tjaalton, we'll have a session about it again at uds ... tseliot is working on something wrt xinput and we should merge efforts
<tjaalton> ogra: ok, good
<jelmer> liw: yep
<tseliot> ogra, tjaalton: yes, and it's almost complete, at least as regards touchpads
<jelmer> liw: for Samba we currently generate HTML reports for our C and Perl code coverage in our buildfarm, I'd like to do the same for Python which is why I'm looking for HTML specifically
<ogra> right, touchscreens are a bit different, but we should be able to share the backend server
<Keybuk> depends on the touchscreen, of course
<Keybuk> some show up as wacom tablets ;)
<ogra> thats not qa touchscreen then :)
<Keybuk> qa?
<ogra> since it needs an additional device
<ogra> s/qa/a/
<Keybuk> it is a touchscreen though
<ogra> you can tap it with your finger ?
<Keybuk> it's just a dual-mode one
<ogra> ah
<Keybuk> yes, in Windows at least anyway - Linux you can only use the stylus
<ogra> yeah, thats a bad one
<ogra> but i guess it has two /dev/input/event files you could use
<Keybuk> not sure
<ogra> so you could attach two different drivers and make both modes work
<ogra> just getting calibration consistent might be painful :)
<Keybuk> I appear to have foolishly overwritten the USB key with the only filesystem this can boot from
<ogra> well, bring it next week and we can take a look :)
<Keybuk> :-)
<Keybuk> that's the hardest part about Allhands/UDS
<Keybuk> deciding which hardware to pack
<tjaalton> ogra: so, looking at the bug it seems that the kernel lists wrong capabilities, so either it should be fixed in the kernel or by a udev quirk?
<tjaalton> I see input.touchpad/input.mouse for the models listed on that bug
<ogra> Keybuk, come by train or car ;)
<ogra> tjaalton, yes and the current driver changes that with the .fdi file
<ogra> tjaalton, the thing is that many of the evtouch devices dont have any special kernel drivers ... they are just USB HID devices, not sure you can generally apply patches on a kernel level for them ...
<ogra> i surely know usbtouchscrees fails for 90%
<ogra> *usbtouchscreen
<tjaalton> it just _seems_ systematic
<tjaalton> ie. like a bug
<ogra> depends :) ... we should make sure to have some kernel guys in the room at UDS :)
<Keybuk> ogra: I thought the kernel ev layer had quirks
<ogra> but that requires the HW to tell it the right thing, no ?
<Keybuk> indeed, drivers/input/touchscreen is *full* of quirks
<tjaalton> so that's the place to hide them ;)
<Keybuk> ogra: if the hardware lies, how do you quirk it in userspace?
<Keybuk> it's no harder to quirk in the kernel than in userspace, in fact, it's often easier since the kernel already has tables of them
<ogra> Keybuk, currently through an .fdi file
<Keybuk> ogra: what does the fdi match on?
<ogra> name model etc
<ogra> i'd like to overcome the whole tabel thing if possible though
<ogra> *table
<Keybuk> there you go then
<Keybuk> the kernel can quirk that
<JordiGH> I was under the impression that for making a package for Ubuntu, making the package for Debian would suffice. Is there a case when Ubuntu doesn't just automatically grab Debian packages?
<ogra> only some corner cases
<JordiGH> Like what? This is for a family of packages (Octave) currently in Ubuntu's universe.
<JordiGH> (iirc)
<directhex> assuming there's no release freeze?
<ScottK> JordiGH: We do have those generally.
<JordiGH> directhex: Yeah, assuming the package will eventually trickle down into Ubuntu. I don't care if Debian gets the package first in its unstable branch.
<ogra> JordiGH, ltsp for example uses the same upstream but different packaging
<ogra> so we dont sync that but collaborate on the upstream code across the distros
<directhex> JordiGH, the typical block is "package has been modified in ubuntu" which requires manual intervention
<JordiGH> directhex: So I should be cool with packages currently in Universe, right? That's untainted Debian?
<directhex> JordiGH, which seems to be the case here
<JordiGH> Okay, good.
<directhex> JordiGH, check the changelog for the package in universe, which has been modified in some way - if none of the changes are relevant any more, file a sync request, and it'll be pulled in "untainted" as you say
<JordiGH> Uhm, "unmodified". I don't *really* want to say that Ubuntu "taints" packages. ;-)
<directhex> looks like 2 patches, suitesparse_3.2.0_fix.dpatch and 51_fix_desktop_entry.dpatch
<directhex> as per http://changelogs.ubuntu.com/changelogs/pool/universe/o/octave3.0/octave3.0_3.0.1-6ubuntu2/changelog
<JordiGH> Yeah, this is for a new package for Octave.
<JordiGH> I wonder if those patches have been pushed back to Debian...
<cjwatson> Larhzu: squashfs, yes
<cjwatson> (from #ubuntu-meeting:)
<cjwatson> 16:29 <Larhzu> liw mentioned something about compressing live-CD with LZMA and keeping small changes rsyncable. Is the live-CD compressed with Squashfs or are there normal compressed .deb files or what?
<cjwatson> Larhzu: well, mostly squashfs; there are some .debs on there too, but it's the squashfs component that gets independently compressed
<directhex> if not, then in the general case, administer spankings - however, sometimes there are policy differences which force some patches between distros. sometimes it's possible to convince a DD to include ubuntuisms directly in the debian debian/rules file
<cjwatson> Larhzu: however, that's only right now
<cjwatson> Larhzu: one of the reasons we're looking at lzma for this is that the squashfs/unionfs approach is problematic right now
<Larhzu> cjwatson: Squashfs compresses data in blocks of 64 KiB to 1 MiB. I don't know much more about Squashfs myself. For rsyncability, you want to make sure that unchanged data gets put into same blocks. It's mostly a Squashfs issue, not LZMA or XZ.
<cjwatson> Larhzu: unionfs and aufs are both looking pretty shaky upstream and it's rather difficult to get them working with a current kernel
<cjwatson> Larhzu: so we're looking at Fedora's approach, which involves device-mapper and so the source read-only filesystem has to be a more normal filesystem, e.g. ext3
<cjwatson> (sorry, I should probably have just said that up-front rather than being confusing about squashfs)
<cjwatson> Larhzu: we tried lzmaing an ext3 filesystem with a tiny change (small change to /etc/issue or something) and rsync reckoned that the resulting compressed image had absolutely nothing in common with the original
<Larhzu> cjwatson: How do you use LZMA with ext3? Compress the whole file system image at once?
<liw> cjwatson, so if I understand correctly: we are looking at completely dropping squashfs and replacing that with an ext3 image that gets lzma compressed?
<cjwatson> Larhzu: yes
<cjwatson> liw: it's one of the possibilities
<cjwatson> I'm actually looking at something different right now since it isn't looking terribly viable
<cjwatson> but you asked :-)
<Larhzu> Do you plan to uncompress the whole image to RAM before using it, or uncompressing on the fly when stuff is needed from it?
<cjwatson> Larhzu: TBH I'm not sure :-) this was just an experimental thing
<cjwatson> none of this is near the "do you plan" status
<ogra> phew ...
<cjwatson> it's "we're playing around with stuff to figure out what could replace squashfs/aufs"
<ogra> but squashfs is upstream now, no ?
<ogra> is there any reason to move away from it ?
<cjwatson> ogra: unionfs/aufs aren't
<cjwatson> that's the problem
<cjwatson> squashfs being upstream is great
<ogra> right, but you only look into replacing the union parts for now ...
<ogra> ?
<cjwatson> yes
<Larhzu> If you make a 500 MiB compressed ext3 image which has to be uncompressed to RAM first, you need many gigabytes of RAM and booting will take 15 minutes.
<ogra> good
<cjwatson> hmm, I wonder if I have been maligning clicfs
<cjwatson> it seems to split the image into blocks and lzma each block separately
<Larhzu> That's what Squashfs does.
<cjwatson> Larhzu: ^- would that approach be likely to be rsyncable, then?
<cjwatson> (as a guess, I'm not holding you to it ...)
<Larhzu> It's a Squashfs issue, you need to make sure that when recreating a Squashfs image, non-changed parts get into same compressed blocks.
<cjwatson> we don't have this issue with squashfs
<cjwatson> indeed, what we're trying to avoid is a *regression* from our current squashfs setup
<Larhzu> Oh sorry
<cjwatson> sorry, I was very confusing in my description above
<Larhzu> So ext3 splitted in small pieces, each piece compressed separately, then make the uncompressed image available to ext3 driver via device mapper decompressor or something?
<Larhzu> I'm still quite unsure if I'm following at all.
<cjwatson> so, right now, we have squashfs+aufs, and this is all lovely and rsyncable, although perhaps not as small as it could be (though small enough)
<cjwatson> aufs is having serious problems getting accepted upstream, and there's nothing available for 2.6.30 that we know of, so we're forced to look into alternatives
<cjwatson> one possible alternative is something along the lines of the approach taken by Fedora: make an ext3 filesystem, compress it *somehow* (I'd assume block-by-block), and layer a writable piece on top of that using device-mapper
<Larhzu> Does the device mapper hack make it writable too by keeping changed blocks in RAM or storing them to hard disk?
<cjwatson> now, we actually used to do something like this with cloop, but found that it tended not to be all that rsyncable, and this was a major problem for our developers; we managed to make it somewhat rsyncable by keeping the old uncompressed directory around from build to build but this was very inconvenient
<cjwatson> RAM
<cjwatson> or USB stick if you're booting from that
<cjwatson> at least, I think that's how we'd do it in Ubuntu; I don't know the specifics of the Fedora approach
<Larhzu> With my minimal understanding about file systems, Squashfs + something make it writable sounds much better, since Squashfs will very probably handle the decompression better (at least faster).
<cjwatson> OK. Our problem right now is that most of the candidates for "something" just evaporated. That's not your problem though, I suppose :-)
<Larhzu> If you modify an ext3 image, there will probably be changed blocks in many places. With Squashfs, that's probably not so big problem.
<cjwatson> Hmm, right.
<cjwatson> I'm looking into unionfs-fuse at the moment, which shows some promise of being a candidate for "something", although writing may end up being rather slow due to having to bounce through userspace
<ogra> cjwatson, dod you know that nbd has a COW mode ?
<Larhzu> Making such an ext3 image rsyncable would probably give bigger size than Squashfs.
<ogra> *did
<cjwatson> ogra: no - that's block-level though, isn't it?
<ogra> i know the debian ltsp guys played with it
<ogra> using a squashfs image
<cjwatson> Larhzu: thanks, that's very useful information
<ogra> no idea, i havend dug deep into it
<ogra> i just know it works and i used loopback nbd setups before ... its not beautiful but works
<Keybuk> cjwatson: except we can't use squashfs
<cjwatson> right, nbd is block-level
<cjwatson> ogra: the problem with anything block-level is that it means that the target device has to be the same filesystem type as the source device
<Larhzu> cjwatson: I have written XZ Embedded for Linux, which is XZ decompressor with LZMA2 and BCJ filters. That should be useful for Squashfs, so there could be LZMA-based (more correctly, XZ and its LZMA2 -based) Squashfs in vanilla Linux some day. I haven't posted about it to LKML yet, but there was some minimal discussion on linux-embedded.
<ogra> cjwatson, hmm, i know they used ext3 rw images alongside squashfs ro images
<cjwatson> ogra: interesting - google finds no reference to it and the documentation isn't exactly clear, but if you can dig up something concrete I'd be interested in looking at it
<ogra> but indeed its ugly and you need a running loopback device at least for it
<cjwatson> Larhzu: if we find a workable union implementation, we might well end up using that once it gets into mainline and assuming that it's reasonably rsyncable
<Larhzu> cjwatson: About making compressed ext3 image rsyncable, there's one easy way, which is possible because the image size is fixed: Just compress the data in blocks of a few megabytes. That way most blocks won't change.
<cjwatson> mainlininess has been one of the traditional blockers there - our kernel team would far prefer to avoid out-of-tree drivers where they can (and aufs has been a headache for them)
<Larhzu> cjwatson: It's Squashfs whose rsyncability matters with Squashfs + something. And I understood you didn't have rsyncability issues with Squashfs.
<Keybuk> Larhzu: how do you specify the block size to lzma?
 * vagrantc waves to ogra 
<ogra> cjwatson, vagrantc played with nbd COW on debian ltsp
<cjwatson> Larhzu: ok, I think we'd need to experiment to find out whether that would work well in an environment where the source filesystem is built from scratch on every build :-)
<Larhzu> Keybuk: Current you don't. There will be such option in xz (the command line tool from XZ Utils), it's needed for multithreading. I haven't implemented it yet.
<ogra> vagrantc, we are looking for a poissibility to replace aufs/unionfs in ubuntu with a COW method
<cjwatson> I think one problem we had is that things like packages being unpacked in different orders resulted in stuff moving around a lot on the filesystem - essentially spuriously but it broke rsyncability
<cjwatson> mksquashfs has a -sort option that lets us avoid that class of problem
<ogra> vagrantc, and i remembered you played with that possibility on ltsp ... you did use a squashfs with ext3 writable bits, right ?
<vagrantc> ogra: NBD's cow support? or something else?
<vagrantc> ogra: i've used all manner of combinations :)
<sabdfl> hi folks, is there a coontact address for SRU discussions? have a question in my inbox from sebastian hilbert re gnumed
<ogra> vagrantc, well, cjwatson looks into unionfs via fuse ... i just remembered you did something through nbd
<vagrantc> ogra: i've used ext2/ext3 with aufs
<vagrantc> ogra: no squashfs at all
<ogra> what did you use for your readonly nbd images ?
<vagrantc> ogra: ext[23]
<ogra> oh, ok
<ogra> then i was likely misremembering
<vagrantc> ogra: i also looked at using server-side cow files, but there's a few bugs that prevented it from working
<ogra> i thought it was squashfs with a writable ext2/3 alongside
<cjwatson> sabdfl: it's very sparsely used but we do have an ubuntu-release list - perhaps send it there, but realistically it might be a good idea to CC the individual members of the ubuntu-sru team since I'm not sure how everyone's mail filters handle that list
<ogra> sabdfl, does https://wiki.ubuntu.com/StableReleaseUpdates help you ?
<vagrantc> ogra: as NBD supports cow files, but it isn't flexible about where it writes the temporary cow files.
<ogra> right, but thats could be fixed/patched
<cjwatson> sabdfl: normally we're working with bug reports (as the wiki page ogra cites discusses) and in that case it's easy just to subscribe the ubuntu-sru team
<vagrantc> ogra: sure. i reported bugs in the debian BTS
<sabdfl> ok, i'll advise sebastian accordingly
<sabdfl> thanks!
<cjwatson> sabdfl: actually, gnumed's probably in universe - so the motu-sru team should be subscribed instead
<cjwatson> sorry, forgot about that
<ogra> vagrantc, we're looking actively for something to replace aufs/unionfs on the livecds ...
<sabdfl> looking forward to UDS (and AllHands beforehand after somehands ;-))
<cjwatson> handhands
<vagrantc> ogra: ah, then NBD support wouldn't help much.
<cjwatson> wavehands
<ogra> sabdfl, dont forget to wash your hands between them :)
<ogra> vagrantc, yeah, if it cant do squash alongside with tmpfs it wouldnt ... i thought about a local loopback nbd setup
<ogra> with enabled COW in tmpfs
<cjwatson> nbd would have to operate at the filesystem layer in order to make that work
<ogra> yes
<cjwatson> but it operates at the block layer, as far as I know
<cjwatson> kind of a big change :-)
<ogra> well, apparently i misremembered what vagrantc was doing
<vagrantc> ogra: the main NBD bug that's a blocker for LTSP using NBD's built-in cow support is: http://bugs.debian.org/470963
<ogra> vagrantc, seems trivial
<Larhzu> cjwatson: I hope things become a little bit clearer now. Like I wrote in the forum post, there probably will be rsyncability option in xz some day, but it won't be there soon. I cannot promise to add block-size option very soon either; my primary worry with this subject is to get XZ Utils 5.0.0 finally out.
<vagrantc> ogra: but it would be bizzarre to use on a CD :)
<ogra> vagrantc, yeah, that was what i said initially :) but it could work around the problem
<Keybuk> Larhzu: what's the difference between XZ and LZMA?
<Larhzu> cjwatson: If there's something else, just ask. I'll idle here a few hours. Later just PM or visit #tukaani.
<ogra> vagrantc, i used nbd loopback before, its very convenient if you want userspace loop mounting of image files ... you can run nbd-server as a user and dont need access to /dev/loopX
<Larhzu> Keybuk: The .lzma format is becoming legacy, same with LZMA Utils. XZ Utils and .xz format support LZMA2 (fixes some issues of LZMA, practically no compression ratio changes) and other algorithms (filters). .xz also has proper magic bytes and integrity checks which .lzma lacks.
<ogra> vagrantc, thanks for coming over though ...
<Larhzu> Keybuk: .xz also has an index of independently compressed blocks, which makes it possible to do limited random access reading.
<cjwatson> Larhzu: right, thanks a lot for your clarifications; I don't think there's any rush from the lzma point of view, as we're likely to need at least a stopgap measure that exists today, so we'll keep researching
<ogra> vagrantc, if we really dont find a pretty alternative in ubuntu i might invest some hours into fixing the nbd side for ltsp
<Larhzu> Keybuk: The .lzma format was meant to be replaced in 2006 already, but things progressed very slowly.
<vagrantc> ogra: using a writeable filesystem (ext3) for the nbd.img file means you can mount the loopback image and tweak the chroot just like in the "good" old days of NFS. :)
<vagrantc> ogra: i didn't notice a significant speed improvement using nbd + squashfs vs. nbd + ext[23]
<ogra> vagrantc, yeah, and we could finally get back to doing the same thing on both distros :)
<vagrantc> heh.
<ogra> no, the speed improvement is NFS vs nbd+squashfs
<vagrantc> ogra: debian's got support for all the various incarnations.
<ogra> and i dont think the squashfs ever played a significant role
<vagrantc> ogra: right, but you pretty much get the same speed improvement by using NBD + *fs
<ogra> right
<ogra> its the nfs overhead that slows down
<ion_> ogra: Would any of this be helpful for LTSP? http://kernelnewbies.org/Linux_2_6_30#head-d2d7e82afe6019227c8d6f661608550a2ca917f1
<ogra> ion_, well, we would have used iscsi if it would have looked sane :) but indeed its a possibility
<ion_> I meant POHMELFS
<ion_> I didn't really take a good look at it, just noticed the phrase âbeats NFS by a big margin in most, if not all, operationsâ
<ogra> that sound intresting but would have to prove it works on low power HW
<ogra> "...with a local writeback cache of data and metadata, which greatly speeds up every IO operation..."
<ogra> that sounds ram hungry to me
<ion_> True
<ogra> but would be worth a test for sure if someone finds the time to do an initramfs hook for ltsp
<kees> Keybuk: what are you saying in the whiteboard status for security-karmic-apport-abort ?  will apport actually run sanely if upstart aborts?
<Keybuk> kees: well, I think right now, apport doesn't run at all
<Keybuk> from what Martin was saying
<kees> Keybuk: well, I meant from a technical perspective.  can apport execute if pid 1 has died?
<Keybuk> pid 1 doesn't die
<Keybuk> but it does generate a core file
<kees> Keybuk: apport ignores ABRT, but this would seek to change that in the case of assert() failures
<kees> okay, if the kernel attempts to launch apport, then it should work okay
<Keybuk> kees: right, thus my "figlet ++"
<Keybuk> if apport could catch SIGABRT and file bugs - that would be a big win for me
 * apw wonders if there are any main-sponsors about to look at a hibernate related upload on bug #350491, avoids potential corruption due to failed hibernate resume on kernel update
<ubottu> Launchpad bug 350491 in linux "hibernation should be disallowed from the desktop when the installed kernel does not match the running kernel" [High,In progress] https://launchpad.net/bugs/350491
<kees> Keybuk: yeah, though there are a lot of gotchas, though, which is why I scheduled the UDS thingy
<kees> Keybuk: can you come to that discussion if you're not already sub'd to it?
<Keybuk> kees: I didn't think the discussion was even scheduled
<Keybuk> no, it is, I just can't find it ;)
<kees> heh
 * kees hopes pitti doesn't mind me making him a drafter on it.  :)
<rickspencer3> lol
<Keybuk> kees: actually, it would be an interesting experiment to see how the kernel deals with apport
<Keybuk> whether it lets apport continue before doing the PANIC or not
<kees> Keybuk: right, that was what I was curious about.
<Keybuk> I have a note that I thought the kernel ran apport as part of the process of dumping core
<Keybuk> so the parent didn't get to wait() on the child until apport had done
<Keybuk> since it needs to know for WCOREDUMP()
<Keybuk> but I should check that
<Keybuk> kees -> the abort() handler discussion conflicts with the upstart tutorial :-(
<kees> Keybuk: just subscribe yourself and re-shuffle!
<Keybuk> I'm not touching the schedule ;)
<kees> dang it
<kees> ah well
<Keybuk> dendrobates will have to reorganise <g>
<dendrobates> AAAAAAAHHHHHHHHHHHHHHHHHHHH
<pitti> Keybuk: drafter on what?
<rtg> doko: do you think the ARM binutils fix will help the kernel FTBS https://edge.launchpad.net/ubuntu/+source/linux/2.6.30-5.6/+build/998876/+files/buildlog_ubuntu-karmic-armel.linux_2.6.30-5.6_FAILEDTOBUILD.txt.gz ?
<dendrobates> I sugest dividing Keybuk into two idenically sized pieces.
<ogra> rtg, yes
<rtg> ok, I'll restart it
<doko> rtg: yes
<doko> rtg: it's not yet built
<Keybuk> dendrobates, pitti, kees: I don't _really_ need to be there - other than to say I'd like apport to catch Upstart's abort() calls ;)
<rtg> doko: oh, I might have jumped the gun
<rtg> though, it should be behine binutils in the build queue (I hope)
<doko> rtg: just set the score to 1 for now
<rtg> doko: hmm, easier said then done.
<cjwatson> rtg: retries are automatically set to 0
<cjwatson> of course that doesn't guarantee that a publisher run will happen between binutils building and linux building
<rtg> as long as the armel build takes, I'm sure an hour will elapse between
<cjwatson> maybe
<kees> pitti: security-karmic-apport-abort blueprint
<kees> Keybuk: okay cool
<kees> pitti: now, with URL: https://blueprints.edge.launchpad.net/ubuntu/+spec/security-karmic-apport-abort
<pitti> kees: ah, that sounds fine
<kees> cool
<doko> rtg: rescored to 1. needs the rescore once binutils is in the archive
<rtg> doko: thanks
<Keybuk> kees: it *looks* like the kernel waits for apport to finish ;)
<kees> neato
<kees> Keybuk: how do you call abort currently?  via assert() or only as abort()?
<kees> Keybuk: the primary trouble with handling abort() is that there is no one place that applications report errors before calling abort(), excepting through assert() and the internal *_chk() aborts.
<pitti> bryce: I added a snippet about UXA/KMS testing to https://wiki.ubuntu.com/KarmicKoala/TechnicalOverview; would you mind proofreading?
<pitti> bryce: also, https://wiki.ubuntu.com/X/KernelModeSetting still mentions the xorg-edgers PPA for karmic; I'll delete that, since 2.7.0 is in karmic proper
<bryce> ok
<pitti> bryce: or would you rather not have these mentioned in the tech notes?
<bryce> wow, people are amazingly ungrateful on that X freeze bug
<d1b> bryce: it is their gui
<bryce> pitti: it's fine to mention x-updates on the technical overview
<pitti> bryce: isn't x-updates for jaunty?
<pitti> bryce: I mean the karmic alpha-1 release notes (call for testing)
<bryce> pitti: oh karmic
<pitti> bryce: ungrateful> yes, only to freak out in joy when testing 2.7.1 :)
<d1b> pitti: is it that much better / fixed?
<bryce> pitti: yes this text looks good
<pitti> d1b: I can only parrot what they said in the bug report; karmic has 2.7.0 still, running that
<pitti> I have a number of problems with it (glitches and suspend), looking forward to trying 2.7.1
<d1b> pitti: intel on ubuntu .. since 8.04 has had problems on my laptop :(
<d1b> what about fglrx in jaunty... is that getting fixed soon...
<pitti> bryce: what's driving me crazy is that people keep posting UXA and other unrelated feedback to it
<Keybuk> kees: only as abort()
<Keybuk> #define nih_assert(expr) \
<Keybuk>         if (! NIH_LIKELY(expr)) { \
<Keybuk>                 nih_fatal ("%s:%d: Assertion failed in %s: %s", \
<Keybuk>                            __FILE__, __LINE__, __FUNCTION__, #expr); \
<Keybuk>                 abort (); \
<Keybuk>         }
<kees> Keybuk: ah, but you call nih_fatal() first.  what does that do?
<kees> Keybuk: a lot of applications will do stuff like  fprintf(stderr,"Zomg: pwnd\n"); abort();
<bryce> pitti: yeah I know
<kees> Keybuk: so we'd be toying with ways to capture that stderr line.
<Keybuk> kees: logs to kmsg
<Keybuk> (ie. it ends up in dmesg)
<bryce> pitti: ok so I count 1 comment on bug 359392 that indicates it fixes problems, and 5 that complain but don't seem to have tested
<ubottu> Launchpad bug 359392 in compiz "[i965] X freezes starting on April 3rd" [Undecided,In progress] https://launchpad.net/bugs/359392
<pitti> bryce: from what I saw, there seem to be people with the proposed packages who still experience freezes, and some for whom it works
<pitti> I think by and large it greatly reduces the freezes
<pitti> so the -intel part isn't any worse than the jaunty final one
<kees> Keybuk: I wish there was an "abort with message" function.  closest seems to be assert()... which isn't really.  bleh.
<kees> Keybuk: but still, catching abort() would be nice.
<bryce> pitti: sometimes I wish there was a minimum karma requirement before you can comment onto someone's bug other than your own
<bryce> pitti: I think that would help cut down on the drive-by-ranting ;-)
<pitti> heh, yes
<pitti> bryce: and rants would decrease your karma
<bryce> I got excited when I saw launchpadlib added a "hide comment" feature, but then I found it is only available to launchpad admins
<mrooney> oh yeah, if you could vote up or down comments and the points there affected that users karma, haha
<ogra> become one !
<d1b> bryce: well the admins have to have something to make the site useable ^^
<bryce> d1b: are you a launchpad admin?
<d1b> veloc1tybrno way.
<d1b> bryce:  no way *
<d1b> i just have a hate of the launchpad interface
<geiseri> cjwatson: ping?
<bryce> d1b: ah so you were just ranting, gotcha
<mneptok> d1b: well, with such insightful and productive input as yours, i see no reason it should not improve.
<d1b> bryce: yes, well i prefer drawing attention to it. + there are things they can fix easily + they  are working on it i know
<d1b> mneptok: yes i know. i have some helpful comments / filed bugs already thank you.
<bryce> first, I think this is the wrong channel to draw attention to it
<geiseri> cjwatson: i have a problem (someday i will just say hi and ask how your day was), i added an extra component to my install CD with extra packages. The component is called custom, but i keep seeing the following error: "Invalid Release file: no entry for custom/binary-i386/Packages"  but i see the file there.
<bryce> second, I know sometimes people think that voicing complaints about something will motivate people to work to fixing it, but actually the reverse can often be the case.
<geiseri> cjwatson: and from what i can tell the md5sums match from the Release file and the actual packages file.
<bryce> anyway, nuff said
<ogra> .oO( third: ranting at someone about something unrelated who just complained about unrelated rants on his bugs will surely help )
<ogra> :P
<mneptok> OGRA SUX PLZ FIX KTHXBAI
<ogra> YEAH, ALL YOU SLACKERS !
<ogra> :)
 * d1b suggests vim + wiki editing and runs
<geiseri> any one else an expert at the ubuntu/debian installer and making a custom CD?
<ogra> geiseri, #ubuntu-installer probably :)
<LordKow> i have a problem: karmic is not broken and boots just fine... what package should i submit the bug report under? :-) perhaps gcc so we can build against 4.5 and break something/everything ? :-)
#ubuntu-devel 2009-05-14
<dholbach> good morning
<pitti> Good morning
<pitti> LordKow: try enabling UXA and KMS :)
<StevenK> Hey pitti!
<tjaalton> pitti: well, FUSA isn't working properly here :)
<pitti> tjaalton: at least something! :-) what's wrong with it?
<tjaalton> it doesn't present the options to shutdown/suspend etc
<tjaalton> those work from the gdm login screen
<pitti> interesting
<tjaalton> also, seems like FUSA is making Xorg eat the cpu
<tjaalton> since removing it from the session and logging back in makes that go away
<Amaranth> KMS = 100% brightness :/
<MmikeNekud> What is the difference between Xserver and Xorg? I believed that Ubuntu 9.04 uses Xorg 7.4, now I'm reading it's using Xserver 1.6. What is Xserver 1.6?
<highvoltage> Xorg is an x server
<highvoltage> xfree86 is another one, now mostly obsolete
<MmikeNekud> highvoltage, i know about xfree86, but, that's in version 4.something.... I have no idea what is Xserver 1.6
<MmikeNekud> i tought that xserver is 'type' of sofware... xorg is xserver ,xfree is xserver.... (much like mysql is rdbms, postgres is rdbms)
<cjwatson> MmikeNekud: "Xserver" is a name for a particular (important) component released by the X.org Foundation (actually, they normally call it xorg-server but both names are in use colloquially); see e.g. http://www.x.org/wiki/Releases/7.4
<cjwatson> MmikeNekud: the name "X.org" or "Xorg" is sometimes used to refer to the whole suite of software released as various modules by the X.org Foundation
<MmikeNekud> cjwatson, so, xserrver 1.6 is one of the xorg 7.4 components?
<maco> cjwatson, is it that xserver means a spec to which xorg and xfree86 conform?
<maco> since xorg replaces xfree86 as the default xserver in a lot of distros
<cjwatson> MmikeNekud: actually, no, X11R7.4 included xorg-server 1.5.1 (as you would see if you'd gone to the wiki page I quoted above); Ubuntu 7.04 went a bit ahead of X11R7.4 for the server
<cjwatson> maco: err, "spec" is putting it a bit strongly. Obviously both XFree86 and X.org need to include an X server or they'd be a bit pointless.
<maco> cjwatson, is there some sort of API or something?
<cjwatson> there's a wire protocol, yes
<cjwatson> XFree86 was monolithic - the server wasn't released separately, X was just one giant lump
<seb128> StevenK: hey, will you do syncs today?
<MmikeNekud> cjwatson, yes, i see that now.... Ok, thnx, you clarified quite a bit for me here.... :) I'm trying to set up my friends laptop, he has FireGL 5200, and that one doesn't seem to be working with ubuntu :(
<cjwatson> so it's only with X.org that the server has started having independent versioning
<StevenK> seb128: I was thinking about it :-P
<seb128> StevenK: that would be nice, would clean the sponsoring and merge lists ;-)
<directhex> splitting xorg from one big fatty fat fat into actually distinct parts was one of the headline items that differentiated xorg 7.0 from xorg 6.9's xfree86-like build system
<StevenK> And it moved to autofoo
<directhex> everyone loves autofoo
<directhex> it's like cotton candy for the soul
<Chipzz> cjwatson: I was reading yesterdays backlog, and I wonder what mksquashfs -sort actually does/how it works
<Chipzz> do you keep a list of filenames or block numbers?
<cjwatson> pitti: how do I stop the retracer from marking installer bugs as duplicates of bug 260001 when they aren't? they just happen to have the same backtrace because the backtrace isn't detailed enough. Can I change the bug description to stop it doing that?
<ubottu> Launchpad bug 260001 in ubiquity "ubiquity crashed with InstallStepError in configure_bootloader()" [Undecided,New] https://launchpad.net/bugs/260001
<cjwatson> Chipzz: actually currently we give an empty file to mksquashfs -sort while building our live CDs :-)
<cjwatson> (which is largely by accident, but)
<Chipzz> cjwatson: but that doesn't actually explain what that option does :)
<cjwatson> Chipzz: read the source, you know as much as I
<cjwatson> or the manual page
<Chipzz> I was just going to say, I'm too lazy to install a package just for reading the man-page ;)
<Chipzz> but anyway
<Chipzz> what I was thinking
<Chipzz> would something along these lines help for ext3:
<Chipzz> find /temporary/path | sort | cpio -pumdv /path/to/loop/ext3
<Chipzz> which would copy the files to the ext3 images in some sort of sorted fashion
<pitti> cjwatson: I could delete that one from the dup db, but the next time such a report comes in, it would be auto-dup'ed again
<Chipzz> also, something you may want to consider may be fragmentation of the image - in which case ext4 extents could help?
<pitti> cjwatson: I can do a quick cowboy-hack to not dup to 260001, if that helps
<pitti> cjwatson: fixing that properly will require some deeper thinking
<Chipzz> cjwatson: anyway, just some idle braindumps I got when reading that backlog; you probably thought of those already, but just trying to contribute some ideas ;)
<cjwatson> pitti: would changing the bug description make any difference, or does it look at the original description or some cache?
<pitti> cjwatson: no, just bug numbers and stack traces
<cjwatson> Chipzz: we used to do that sort of thing but it was hopelessly awkward to maintain and we don't want to go back to it
<pitti> and package names
<cjwatson> pitti: ah. In that case, yes, I'd appreciate it if you could blacklist 260001 from auto-duplication
<cjwatson> the traceback just says "installing the bootloader failed for some reason"
<pitti> cjwatson: done
<cjwatson> thanks!
<cjwatson> (oh god, now I'm going to have to go through the 66 dups - oh well)
<pitti> cjwatson: well, untested, but worst that can happen is that it crashes now, and then I'll fix it
<pitti> cjwatson: sorry
<pitti> cjwatson: but I guess without auto-duplication you also had to go through them
<cjwatson> yeah
<cjwatson> not your fault :)
<directhex> hm. it seems i still suck at Closes:
<lifeless> cjwatson: the installer again?
<cjwatson> lifeless: ?
<lifeless> cjwatson: bug duplication detection [human and bot]
<lifeless> cjwatson: we have similar issues in bzr where users think things are the same, that aren't, fairly regularly
<cjwatson> lifeless: in this case it's essentially because the traceback is too general
<cjwatson> I can't really blame them, you have to look into the syslog to stell
<cjwatson> tell
<lifeless> I wonder if we could hack the backtrace to be more useful
<cjwatson> clearly, but not retrospectively for old versions of the installer burned onto physical media
<lifeless> of course :)
<cjwatson> though it does irritate me when users deliberately report duplicates of their own bugs - but not much to be done about that
<seb128> slangasek: hi, you know about samba and pam, could you have a look to bug #375569 and reassign where it would make sense?
<ubottu> Launchpad bug 375569 in gnome-screensaver "gnome-screensaver failure - can't access samba password database - not running as root " [Undecided,New] https://launchpad.net/bugs/375569
<pitti> TheMuso: is anyone testing the ubuntustudio alpha-1 images?
<pitti> seb128: FYI, slangasek is on holiday this week
<seb128> pitti: oh right ;-)
<slangasek> pitti, seb128: doesn't mean I'm not queuing it, though :)
<seb128> slangasek: thanks
<slangasek> probably a not-a-bug, in any case
<pitti> slangasek: hush, back to gardening! :-)
<pitti> oh well, would ba fairly dark outside, I figure
<slangasek> yeah, it rained all day today too :P
<ogra> good gardeners can mow their lawn in the dark !
<slangasek> I don't claim to be a good gardener
<slangasek> :)
<pitti> ogra: to the great amusement of their neighbours
<ogra> yeah
<ogra> mine use to start around six on a good day :/
<ogra> (AM)
<smb> cjwatson, Ok, so the thing for the kernel package post-installation would be to only claim /vmlinux if the version is more recent that the current. So this relates to the kernel with the higest version number and not to the one which happened to be installed last
<cjwatson> smb: it's not especially clear to me what should happen if you previously had 2.6.28-6-386 installed and then install 2.6.28-11-generic
<smb> Right, that was the reason that lead me to that timestamp idea. From purely looking at the installation viewpoint I deducted -u should always update all initrds that have been touched during that round of installation.
<cjwatson> no, that isn't true
<apw> what is the criteria for a rebuild
<cjwatson> update-initramfs -u means "update the most current initramfs", which may be because one of the userspace packages that form part of the initramfs has been updated, not just because the kernel has been updated
<cjwatson> apw: what sort of rebuild?
<apw> sorry for an initramfs rebuilt, it seems that update-initramfs -u is run whenever any possible contents are change
<apw> i presume we don't rebuild all kernels as that could break your old ones
<smb> And the whole problem arises because when the kernel installation itself builds an initrd, udev was somehow in an inconsistent state, so all builds done between that are broken and when udev finally gets into the correctly configured state, it will only update the mos recently build initrd
<smb> apw, that would be my thinking
<apw> cjwatson, how do the delayed triggers work for other things
<persia> There's several factors involved though.
<apw> it almost sounds like we should rebuild kernels at the end of things
<apw> rebuild _initrds_ at the end
<persia> If I install something *other* than a kernel that affects initramfs, I'd expect I'd want all my initramfs's updated.
<cjwatson> apw: please see the docs for dpkg triggers
<cjwatson> it's a lot quicker than me reciting them
<apw> persia, should that update be broken though then we would break _all_ your kernels, bad
<apw> cjwatson, thanks for the pointer
<cjwatson> persia: we've always said that we should only update the most current one, in order to increase the likelihood of having something older you can boot into if things go wrong
<cjwatson> I have no interest in changing that
<smb> persia, But in theory you could have a shared /boot and have older kernels there. Which you do not want to touch
<cjwatson> but I do think we should update the most current one *for each kernel flavour*
<apw> cjwatson, i think that is very reasonable to do
<persia> cjwatson, Hrm.  I was unaware of that, but it does explain some behaviour I encountered in the past.
 * apw thinks he has a box with that situation
<smb> apw, So we have to make sure update-initramfs can get the most recent kernel version
<cjwatson> apw: largely we do build initramfses at the end, but not for the kernel - there's no way to pass data to triggers, so the trigger can only say "update most current initramfses"
<cjwatson> look, I can fix the update-initramfs thing
<cjwatson> I know exactly what the problem is there
<cjwatson> what I don't know is how to deal with the *other* problem Steve identified
<smb> cjwatson, Ok, and I fix up the other thing
<cjwatson> the kernel postinst unconditionally claims the /vmlinuz symlink
<cjwatson> smb: how? it's not at all clear what the correct semantics are
<apw> what does the vmlinuz link officially even mean
<cjwatson> it's the default thing you boot into
<smb> cjwatson, Ok, to me it sounded as that link always is set to the most recently *installed* kernel
<cjwatson> smb: it is, right now; it is not clear that this is correct
<apw> does anything use it at all?
<cjwatson> apw: update-grub
<smb> cjwatson, You actually boot into the kernel defined in grub. I don't think /vmlinz has any meaning to that
<cjwatson> smb: update-grub is smarter than you think it is
<cjwatson> or at any rate is supposed to be :-)
<smb> cjwatson, Maybe smarter than I fear it is .:)
<cjwatson> also there are still people using lilo for various reasons and I'm pretty certain that lilo.conf refers to /vmlinuz
<smb> cjwatson, So that is the "saved" magic?
<cjwatson> (legitimate reasons; the installer still defaults to lilo in some circumstances)
<apw> so our behaviour currently is to say that the latest kernel is your default kerenl
<smb> apw, If I parse unconditionally claiming correctly it set the link whenever you install a kernel... But maybe not...
<cjwatson> well, how about looking at it this way for something that's *obviously* wrong
<cjwatson> let's say you have both 2.6.28-10-generic and 2.6.28-11-generic installed, and for whatever reason (let's say filesystem corruption) you decide to reinstall the 2.6.28-10-generic package
<cjwatson> right now, it's my belief that doing that will change /vmlinuz to point to 2.6.28-10-generic when it was previously 2.6.28-11-generic
<cjwatson> can we agree that this is wrong?
<smb> cjwatson, I would agree
<apw> if the user has no other way to change the default, that might be a reasonable way to say i want this one to be the default
<cjwatson> they have other ways
<apw> if they have a way to select it is wrong
<apw> so we should only update the link if the kernel is 'newer' in some sense
<cjwatson> now, what should happen if they have 2.6.28-6-386 installed and then install 2.6.28-11-generic?
<cjwatson> those ABI versions aren't comparable
<cjwatson> and, while we generally prefer -generic, the user might have a reason to use -386
<cjwatson> (substitute -server if you prefer)
<apw> i would tend to say stay at the latest of the current flavour
<apw> and if the users wants to change they can use the changer
<cjwatson> let's say that they have both the linux-386 and the linux-generic metapackages installed, so if they keep upgrading, right now the link flip-flops over time
<cjwatson> I think I agree, mostly, that it should stay pinned to a flavour, with one exception
<smb> Right, so the post install would have to look at the current current flavour adn only update if newer.
<apw> for that reason i think we should only move the link to a later version of the current flavor
<cjwatson> if you *remove* a kernel, it needs to switch that link to a different flavour if there are none left of the current flavour
<cjwatson> but really the exact rules need to be written down in policy style
<apw> cjwatson, good point ... and yes we should document them somewhere
<apw> smb, you gonna do that.  cjwatson do we have a place for that kind of thing?
<apw> if not we should make a KernelTeam/Policy thing and put it there
<cjwatson> a big comment in the postinst would be fine, or a wiki page
<cjwatson> probably ought to be commented in the postinst anyway
<smb> Probably remove would dec the abi version as long as there is one with the same flavour and go to generic or anything left if not
<pitti> can anyone please test the current Kubuntu alternates? it becomes urgent now
<apw> stay in flavour if at all possible
<smb> apw, Maybe we get togehter later to think of that
<cjwatson> I don't think I'd mind it being essentially random if you remove a kernel, as long as it says on stdout what it's doing
<apw> smb, sure.  i think the rules are pretty sensible and implementing them sounds relativly straight forward
<apw> i think some awk magic can work it out
<smb> apw, Yes, I think the hardest part is to think of all the cases
<smb> and what should be the sensible approch there
<smb> pitti, I could do a bit but only start in around an hour?
<smb> pitti, something special to have tested?
<pitti> smb: just whether they install in general
<pitti> smb: the previous 5 didn't
<pitti> smb: if you can get through a standard "entire disk" VM install and can login and get a desktop, that's enough
<smb> pitti, ok, so kubuntu alternate in general or 64 or 32 specifically
<pitti> smb: we need to test both
<smb> pitti, Ok, let me start getting the immages
<smb> pitti, rsyncing, I'l do the installs when I am back
<pitti> smb: thanks
<cjwatson> smb,apw: If you haven't already, I'd recommend familiarising yourself with the chapter of the Ubuntu policy manual that describes the valid state transitions for packages
<apw> cjwatson, ok thanks
<cjwatson> smb,apw: it's something like "how maintainer scripts are called"
<smb> cjwatson, Good idea. Thanks
<persia> http://women.debian.org/wiki/English/MaintainerScripts has some nice graphs for the simpler cases.
<TheMuso> pitti: I tried testing them today but the RT kernel we are using + new karmic bits + desktop are all a little wacked out, so since nobody else has done anything at this point, I am enclined to say that we'll skip alpha 1.
<pitti> TheMuso: okay, understood
<pitti> ogra: did anyone test the edubuntu addon alpha-1 CDs?
<ogra> pitti, no idea
<ogra> pitti, i havent touched edubuntu since hardy
<pitti> ogra: want me to release edubuntu alpha-1 CDs?
<pitti> oh, who is the primary contact nowadays?
<ogra> LaserJock is the last guy taking care from a technical side
<ogra> probably highvoltage too
<pitti> highvoltage: did you happen to test the edubuntu alpha-1 addons?
<ogra> i guess if nobody tested it wont do harm to skip A1
<pitti> *nod*
<fta> doko, hi, any plan to add binutils-gold to karmic?
<doko> fta: yes, should be reenabled
 * ogra thought thats still experimental
<doko> that's why we remove it before the releases
<ogra> ah
<fta> ok, thanks
<fta> i want to start experimenting with it on some big packages
<ogra> cjwatson, did you notice that upstream is two versions ahead wrt unionfs-fuse ?
<highvoltage> pitti: I agree with ogra that it's probably safe to skip A1, but if it won't be too late I'll be happy to test it tonight
<cjwatson> ogra: no, but not exactly top of my agenda right now
<dholbach> Packaging Training session in #ubuntu-classroom now!
<cjwatson> ogra: (don't get me wrong, thanks, just doing a lot of stuff right now)
<ogra> cjwatson, yeah, i just noticed there were two upstream releases, one of tehm with a cryptic message wrt com filesystems
<ogra> 0.22
<ogra> - Fix a bug reported by Jens Hoelldampf <jens@hoelldampf.net>, in 0.21 cow
<ogra>   didn't work for pathes.
<ogra> s/com/cow/
<cjwatson> ogra: at the moment I think it might be easiest to identify the problem I can see right now, and make decisions based on that
<cjwatson> but right now I'm looking through grub-installer bugs and worrying about my allhands talk, so ...
<ogra> yep, i just noted that there are a bunch of upstream commits in their mercurial that arent released and that we are two releases behind, i simply thought i'd give you a heads up about that fact no need for any action here :)
<smb> pitti, Kubuntu alternate i386 installed. My favourite testcase (playing mp3 with amarok) fails. No codecs installation offered.
<Riddell> smb: thanks.  audio may well not work at all that's not unexpected
<smb> Riddell, actually it makes sound. :)
<smb> amd64 next
<Riddell> smb: when does it make sound?
<smb> Riddell, Login and logout (just before jockey crashes on logout. heh)
<Riddell> ok, that's good
<PecisDarbs> hi people, is there any plans to replace or extend gnome-bluetooth functionality with blueman? It has integration with NM .7 so it is possible to use Bluebooth modems as mobile broandband connections
<pitti> smb: thanks; if you got this far, it's about as much as we can expect for a1
<smb> pitti, Yeah, its not too bad. amd64 is about to reboot after installation
<smb> pitti, Riddell, Ok amd64: basic installation ok, too
<pitti> smb: cheers!
<Riddell> smb: mouse working?
<smb> Riddell, yep
<Riddell> better than I get :)
<smb> Riddell, All "old" hw. Ps/2 mouse and keyboard
<directhex> is there a formal way to request that someone not act like an arse by treating launchpad bugs like youtube comments?
<lool> kirkland: Didn't try it out, but I see that /usr/bin/ecryptfs-setup-swap uses vol_id and it was dropped; you might have to move to blkid instead
 * lool goes filing a bug
<lool> 376486
<kirkland> lool: ah, good catch, thanks.
<kirkland> lool: any chance you can file a bug to keep that from getting lost?
<seb128> kirkland: I think he did * lool goes filing a bug <lool> 376486
<diverse_izzue__> i'm doing my first steps with packaging and am trying to cook up my own tracker 0.6.94 package, starting from the jaunty 0.6.93 package. turns out the patch 99_autotools.patch needs to be updated - how do I do that?
<seb128> diverse_izzue__: you can move the patch out of the way, cdbs-edit-patch 99_autotools.patch; autoreconf; remove cache dir; exit
<lool> kirkland: like seb128 said :)
<kirkland> lool: seb128: gotcha, thanks!
* pitti changed the topic of #ubuntu-devel to: Archive: Open for development | Karmic alpha 1 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
<pitti> voila
<diverse_izzue__> seb128: by "moving the patch out of the way" you mean delete the patch file and remove the according line from the file "series"?
<seb128> oh, that's a quilt package?
<seb128> diverse_izzue__: try #ubuntu-motu for packaging questions
<diverse_izzue__> seb128: sorry, thanks.
<\sh> oh nice...I hope my new bl7000c equipment arrives in time to test karmic on it :)
<bddebian> doko: You around by any chance?  Do you know what is up with the Debian Java team?
<ScottK> bddebian: persia or ttx would be good people to ask about that.  They just finished a team meeting in #uubntu-meeting.
<ScottK> bddebian: Nevermind.  I misread which distro's team you asked about.
<bddebian> ScottK: Is Persia on an ubuntu-java team?
<persia> (and the highlighted person is in #debian-java anyway)
<persia> bddebian, Yes.  I run the meetings.
<bddebian> No one ever responds in #debian-java :)
 * hyperair would love to see eclipse updated.
 * bddebian would love to see Java removed.. ;-P
 * bddebian hides
 * hyperair brandishes a knife
 * ScottK reminds hyperair he has to clean up the mess after, so consider carefully.
 * persia points hyperair at https://blueprints.launchpad.net/ubuntu/+spec/foundations-karmic-eclipse-update
<doko> bddebian: I'm not the nanny of debian-java ... so I just see what you seem to see.
<ScottK> doko: Is Python 2.6 coming to unstable anytime soon?
<doko> persia: hot air (or call it it hyperair)
<doko> ScottK: wrong channel
<ScottK> Well it would help us with pushing stuff back and getting syncs if the Python 2.6 bugs went from wishlist to RC
<bddebian> doko: I didn't mean to imply that you were I'm just trying to find a warm body that will respond. :)  Response from Arnaud was that he is too busy and Michael Koch seems MIA :(
<hyperair> pah. hot air indeed
<hyperair> lol
<doko> soon, but not real soon
<ScottK> OK
<bddebian> doko: BTW, any chance of updating python2.4/2.5 libdb to 4.6 or 4.7?
<doko> bddebian: yes, I couldn't contact Michael for some months
<hyperair> persia: i've seen that before. unfortunately, 5 minutes after staring at eclipse's packaging, i decided against trying my luck
<ScottK> bddebian: I'm going to guess that comes with 2.6
<doko> bddebian: not really. will get rid of 2.4 hopefully soonish (ScottK: not real soonish)
 * ScottK did some fixing of Eclipse back in the Feisty timeframe (IIRC).  Learned better.
<hyperair> persia: also the debian-java guys have 3.3 in svn last i checked. for some reason, it's sitting there rotting away without anyone to tend for it.
<mterry> asac: How usable are the packages in the mozilla daily build team ppa?
<bddebian> ScottK: Sure but I'm trying to RM: any libdb < 4.6
<bddebian> hyperair: Most of the debian-java packages seem to be bitrotting :(
<hyperair> bddebian: indeed. what happened to them? have they all died or something?
<hyperair> them meaning the members of that team
<asac> mterry: in general they are very much usable
<bddebian> I'm trying to find that out.  As I said Arnaud is busy and Michael Koch is missing, the rest, I have no idea.
<persia> The set of people who are 1) active, 2) DD, and 3) have access to pkg-java SVN has become small.
<asac> mterry: firefox-3.5 is mostly frozen upstream, so you only get baked patches there
<bddebian> I'm tempted to NMU jamvm without jikes but I hate to do that
<asac> mterry: i run firefox-3.6 trunk and even there i usually dont get issues - probably because all extensions are incompatible/disabled ;)
<mterry> asac: Heh, OK.  Thanks
<hyperair> asac: haven't you heard of nightly tester tools? =P
<asac> hyperair: heh. i am quite happy without extensions ;)
<bddebian> persia: So hurry up and get your DD and join the team.. ;-P
 * persia waffles harder
<bddebian> heh
<rtg> cjwatson: I added a section to https://wiki.ubuntu.com/KernelTeam/Specs/KarmicKernelFlavours regarding unsupported architectures. Feel free to add your thoughts.
<davmor2> bryce: I couldn't get an R500 chipset in the end :(  So I had to go with an R600 chipset instead.  I'm having massive issues with it in Karmic.  I'm assuming it is trying to use the highest setting of the card rather than the highest setting of the monitor if I set it to safe graphics it works round this but  the system seems to be working at double speed including the internal clock in 4 minutes it had done 7.  Other
<cjwatson> rtg: thanks
<rtg> np
<al-maisan> how do I figure out which component a package belongs to?
<ScottK> al-maisan: rmadison packagename will tell you (if it doesn't specify it's in Main)
<al-maisan> ScottK: great, thanks!
<cjwatson> al-maisan: I believe it's also in the Soyuz UI ;-)
<al-maisan> cjwatson :)
<cjwatson> https://launchpad.net/ubuntu/karmic/+source/man-db "Component: main" for example
<cjwatson> or https://launchpad.net/ubuntu/karmic/+source/man-db/2.5.5-1build1 which is what you can get to from the main source-package page also shows that
<ScottK> I don't think you can get binary specific component that way though.
<cjwatson> ScottK: you can. e.g. https://launchpad.net/ubuntu/karmic/i386/linux-rt has a Component column
<al-maisan> cjwatson: thanks for the pointer but command line tools are typically much handier.
<cjwatson> it's just very cumbersome to find because the links aren't very good
<cjwatson> al-maisan: well, personally I couldn't agree more, just thought somebody used to Launchpad might prefer the web UI ;-)
<cjwatson> but certainly I always use rmadison myself - unfortunately it doesn't handle ports yet
<cjwatson> I think we have all the pieces in the LP API necessary to write lpmadison now mind you ...
<al-maisan> I am an "old dog", love the command line :)
<ScottK> cjwatson: Thanks.  I didn't know about that one.
<NCommander> cjwatson, when using ubuntu-cdimage, is there an easy way to replace the ubuntu-keyring package in main to include a new ubuntu-keyring package on the fly? (I tried putting one in the LOCALDEBS folder, and it ends up on the CD, but not in the dists)
<Unggnu> hi all
<Unggnu> Is LVM and cryptsetup support planned for the Karmic desktop installer?
<Unggnu> Fedora 11 has this already while I guess the changes couldn't be adapted so easily or are the installer projects compatible?
<Chipzz> you can use the alternate installer if you want LVM
<Unggnu> Chipzz: it is even possible with the desktop if you install the lvm2 package but it is no real option imho
<Unggnu> At least LVM should be possible because it is becoming more and more important. Afaik the Alternate uses LVM per default.
 * pitti does an autosync run and gives the buildds something to do
<calc> doko: thanks for fixing ooo-l10n, I'm not sure what happened to break my merge :\
<asac> cjwatson: doing a full archive rebuild on PPAs?
<asac> i386      12969 builds waiting in queue
<asac> https://edge.launchpad.net/builders/
<asac> or is that huge number a bug?
<ion_> So many PPA builders, as opposed to official archive builders? Iâd have expected the PPA load to be lower than the main archive load.
<Wrongdevice> hello
<asac> ion_: archive builders is real hardware, while ppa builders are VM instances afaik
<ion_> Ah
<Wrongdevice> Ubuntu 9.10 Alpha 1 was compiled with -fgraphite Cflag ???
<ilyast91> hi
<ion_> That was quick.
<Wrongdevice> so the silence means NO
<ion_> If you say so.
<Wrongdevice> bah
<cjwatson> NCommander: there's a local directory that should work, see bin/update-local-indices; haven't used it in production since pre-warty though so it might have bitrotted, but that would be the place to start
<cjwatson> asac: yes, testing out a new LP feature
<NCommander> cjwatson, yeah, that's what I tried. The debs ended up on the CD, but not in the main Packages file, so debootstrap self-destructs since the normal keyring package goes MIA :-/
<cjwatson> NCommander: right, certainly not claiming it works, just that you can probably debug it into existence from there ... it's where I'd start
<cjwatson> it may put things into dists/karmic/local/ or some such which might not work for debootstrap
<cjwatson> I honestly forget, it's been nearly five years :)
<NCommander> cjwatson, well, its ... weird :-/
<NCommander> cjwatson, I'll provide a branch for merging once I get it fixed; its handy for building unofficial images for ports :-)
<pitti> anyone with a ThinkPad or Sony Vaio or Asus laptop here?
 * ion_ 
<ion_> Thinkpad T23
<NCommander> cjwatson, Sony VAIO VGN-660N
<NCommander> er
<NCommander> pitti,
<pitti> ion_: does this show one device for you:
<pitti> udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='ThinkPad Extra Buttons'
<pitti> NCommander: does this show one device for you:
<pitti> udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='Sony Vaio Keys'
<ion_> pitti: It prints /sys/devices/virtual/input/input7
<pitti> running as user should work
<pitti> ion_: cool; does this directory have a 'dev'?
<ion_> pitti: capabilities  event7  id  modalias  name  phys  power  subsystem  uevent  uniq
<pitti> ion_: aha, I want the event7/ sub dir then, I guess
<mcasadevall> pitti, /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:3b/SNY6001:00/input/input5
<mcasadevall> pitti, the media keys on this laptop work on and off depending on the phase of the moon
<ion_> pitti: Ah, it has the dev. dev  device  power  subsystem  uevent
<pitti> mcasadevall: I suppose that dir has an "event5" subdir, and that has a "dev"?
<mcasadevall> pitti, huh?
<pitti> mcasadevall: ls /sys/devices/LNXSYSTM:00/device:00/PNP0A08:00/device:3b/SNY6001:00/input/input5/event5/dev
<pitti> mcasadevall: does that exist?
<mcasadevall> pitti, yes
<pitti> mcasadevall: cool, thanks
<pitti> ion_: thanks as well
<ion_> np
<pitti> mcasadevall, ion_: do you get the same output with this unified command:
<pitti> udevadm trigger --verbose --dry-run --subsystem-match=input --attr-match=name='*Extra Buttons|Sony Vaio Keys'
 * pitti tries to write a debugging tool to make debugging and fixing wrong keymaps much much easier
<ion_> pitti: '*Extra Buttons|Sony Vaio Keys' doesnât print anything, '*Extra Buttons' prints the path.
<mcasadevall> pitti, no output
<mcasadevall> pitti, that being said, I only have working brightness, no sound, but that might be because my sound setup is funny, or because I'm running Xfce :-)
<pitti> ok, need to check them separately then
<ion_> pitti: If itâs a plain fnmatch(), | wonât work.
<pitti> ion_: | works in udev rules, but apparently not here
<ion_> Ok
<pitti> mcasadevall, ion_: could you now please try to run http://people.ubuntu.com/~pitti/tmp/keymap-debug ?
<pitti> ion_: for you it should say "input/event7"
<pitti> mcasadevall: for you it should say "input/event5"
<NCommander> pitti, I got input/event3 back
<pitti> and probably another one which is your real keyboard
<pitti> NCommander: can you pastebin sh -ex output?
<mcasadevall> pitti, http://paste.ubuntu.com/172528/
<ion_> pitti: evdev=$m/input* fails, i.e. it seems to behave as if evdev="$m/input*". Iâll edit the script to make it work and post a revised version for you.
<pitti> ion_: already done and uploaded
<ion_> Ok
<pitti> mcasadevall: please get the current one
<pitti> ah, crap
<pitti> updated again
<mcasadevall> input/event3
<mcasadevall> device path not found
<pitti> mcasadevall: right, please download again
<mcasadevall> pitti, I did, same output
<pitti> *sigh*
<pitti> I need a sh -ex then, I'm afraid
<mcasadevall> pitti, I just rmed the script by accident and now get a 404
<mcasadevall> pitti, er, no wait, I fail
<ion_> pitti: Iâll just do the necessary changes and post the script, as i have a system to test with. :-P
<pitti> ion_: thanks
<pitti> ion_: seems the `ls $m/input*` trick doesn't work, hmm
<mcasadevall> pitti, http://paste.ubuntu.com/172531/
<pitti> ion_: it does work, was just error on my faking
<pitti> mcasadevall: ah, that's because I suck
<pitti> mcasadevall: updated and uploaded
<pitti> I want event*, not input*
<pitti> it works for me now
<ion_> AT keyboard: input/event4 module: input/event7 module: input/event4
<pitti> ion_: that sounds right
<Pretto> people, i need some help, i must install ubuntu from network t0 400 computers, but my client need that a custom theme must be applied and custom packages, is there a semple on how to do that just using preseed?
<Pretto> sample*
<pitti> ion_: for the second module I'm sure that I uploaded my "fake" match
<pitti> ion_: uploaded again, should be perfect now
<mcasadevall> Pici,
<mcasadevall> er pitti
<mcasadevall> AT keyboard: input/event3
<mcasadevall> module: input/event5
<pitti> mcasadevall: splendid
<pitti> mcasadevall: thanks muchly
<pitti> <rough voice>I know where your keyboard is! MUHAHAHAHA!
<mcasadevall> pitti, now if you can solve my trackpad from randomly disconnecting
<ion_> pitti: Yeah, AT keyboard: input/event4, module: input/event7
<pitti> ion_: splendid, thanks
<pitti> mcasadevall: not from here :/
<superm1> pitti, does my memory serve me right that you made a v4l-dvb dkmsified package at some point?
<pitti> superm1: yes, http://martinpitt.wordpress.com/2008/06/10/packaged-dvb-t-drivers-for-ubuntu-804/
<superm1> pitti, awesome.  someone on ~mythbuntu might use it as a basis to do some weekly v4l-dvb builds
<pitti> yay
<ion_> pretto: Iâd use an image of a plain Ubuntu installation with something like puppet or chef installed, and let that tool handle the rest of the customization/configuration.
<pitti> I'd love to see that picked up by someone who maintains it
<superm1> pitti, yeah it would still live on a PPA and what not when it was done, and hopefully low maintenance :)
<pitti> ok, TTFN; see you tomorrow!
<Pretto> ion_, but later i can install it using network install?
<ion_> pretto: Using such a tool, you can later do any changes on any or all of the computers arbitrarily. The clients periodically pull configuration rules from a server.
<Pretto> ion_, the main problem is doing manual installation to 400 computers
<ion_> Create a single filesystem image of a freshly installed system with such a client installed, and replicate the image to the computers.
<ion_> But this is offtopic for this channel. :-)
<Pretto> ion_, where can i find further information about on how to do that ?
<mcasadevall> pitti, I'll give you my laptop at UDS to fix ;-)
<rtg> Karmic on an xps1330 appears to work until you try to start a shell. it appears and disappears very quickly. any ideas?
<ScottK> Type quickly?
<rtg> Screally, really fast
<rtg> ScottK ^^
<rtg> gui apps seem to work OK
<ScottK> rtg: Sorry.  Sarcasm is the only help I have to offer.
<rtg> SCottK: s'alright. you get what you pay for :)
<persia> rtg, Can you start a shell with a different terminal emulator, or on console?
<rtg> persia: console works
<persia> rtg, Then try a different terminal emulator, or a different default shell.  One of those is likely buggy.
<rtg> persia: this is an upgrade from Jaunty. do you suppose I've some cruft in my .bashrc ?
<persia> Possibly.  You'd know better than I.
<rtg> persia: I'll futz around and see what I can figure out
<persia> rtg, Good luck :)
<rtg> persia: its not my primary laptop, so I've time.
<persia> My experience with things that fail is that there's usually another app that works.
<persia> (which helps to diagnose the bug)
<jdstrand> doko: hi! so I am doing the libpng merge and found this in the changelog: debian/rules: Work around missing definition of ECHO. I don't have a bug reference and google didn't help me. what is it for? the package builds fine without it on amd64
<jdstrand> doko: nm, I found it in the upstream changes
<cjwatson> rtg: there might be a hint in .xsession-errors
<rtg> cjwatson: its booting. I'll have a look
<cjwatson> rtg: failing that, I think I'd (carefully) strace -f the gnome-panel process and see what it's doing
<rtg> cjwatson: no joy, also changed from 2d to 3d nvidia. how do I (carefully) strace -f the gnome-panel process?
<cjwatson> rtg: ps x | grep gnome-panel, find pid, strace -f -o gnome.panel.trace -s 1024 -p <pid>
<cjwatson> ctrl-c the strace when you're done with it or else your desktop will probably run like a drain
<rtg> cjwatson: nothing too interesting there. lots of process attach/detached
<Ampelbein> hi guys. is it safe to assume the following: if file /etc/inittab exists -> sysv-rc, directory /etc/event.d exists -> upstart ?
<ion_> Nope. sysvrc scripts can and will be used even without sysvinit, and in a newer version of Upstart, /etc/event.d has been renamed as something else.
<geofft> my upstart has code to parse /etc/inittab
<Ampelbein> ion_: thanks.
<ion_> geofft: Probably not Upstart itself, but Upstart job(s).
<Ampelbein> the point is that i want to make a package (daemontools-run in this case) working on sysv as well as on upstart.
<pace_t_zulu> asac: you here?
<asac> pace_t_zulu: kinda late ... whats up?
<pace_t_zulu> asac: trying to build chromium following your instructions
<pace_t_zulu> not working... will pastebin
<ion_> pace: Thereâs a PPA with daily chromium builds.
<pace_t_zulu> asac: http://pastebin.ubuntu.com/172643/
<pace_t_zulu> ion_: i am trying to build myself... i have the PPA set up already... thanks
<maxb> pace_t_zulu: Taking a known working build as a starting point would still make sense, though, no?
<pace_t_zulu> maxb: you mean apt-get source ?
<maxb> Well, I mean getting the source from the chromium daily PPA.
<maxb> I wouldn't add a source to sources.list just to run apt-get source
<Riddell> where's the UDS timetable again?
<james_w> http://summit.ubuntu.com
<pace_t_zulu> maxb: could you please provide a command to get a PPA source?
<Riddell> thanks james_w
<dtchen> maxb: triaged your audio issue (sorry about the duplicated responses, perhaps due to gmail queueing)
<asac> pace_t_zulu: ../upstream/chromium-browser.svn
<asac> does that dir exist?
<pace_t_zulu> asac: no
<asac> pace_t_zulu: then you need to get a full svn tree first
<pace_t_zulu> asac: should the full tree be ../upstream relative to chromium-browser?
<asac> pace_t_zulu: so basically do the upstream way ... and then refer to that directory as LOCAL_BRANCH
<maxb> dtchen: Thanks. I would be at home testing it were I not currently fixing a bike puncture in order to get home :-)
<pace_t_zulu> asac: thank you for clearing that up
<asac> pace_t_zulu: hmm. could also be that you dont need the gclient sync thing, but just a full svn checkout
<pace_t_zulu> the instructions are not very clear... i would be happy to help with that once i am successful building it myself
<asac> fta_: ^^ ... is that LOCAL_BRANCH the full trunk?
<asac> pace_t_zulu: you can definitly follow the upstream way to build it for now
<asac> the packaging needs some clarification i agree
<fta_> ?
<pace_t_zulu> asac: i really would like to help
<asac> fta: getorig-source LOCAL_BRANCH=../.....svn
<fta> yep
<asac> fta: is that a full trunk? or src/ ?
<fta> what is not clear about the packaging?
<asac> fta: how to get ../upstream/chromium-browser.svn
<fta> it's all what needed to build the full thing, depot_tools, chromium and the 3rd party libs
<fta> just ./debian/rules get-orig-source LOCAL_BRANCH=../whatever
<asac> fta: so in particular: is whatever = http://src.chromium.org/svn/trunk or http://src.chromium.org/svn/trunk/src
<fta> you will have both a tarball and the full svn tree in ../whatever
<asac> only question i have what full svn tree means ;)
<pace_t_zulu> should the ./debian directory be in the folder that contains the source? or the folder that contains the folder that contains the source
<pace_t_zulu> ?
<asac> pace_t_zulu: wait a second ;)
<pace_t_zulu> asac: i am bootstrapping from a source tarball
<fta> asac, it's trunk + what is needed by gclient
<asac> pace_t_zulu: then you dont need to run get-orig-source
<fta> so you end up with http://paste.ubuntu.com/172653/
<pace_t_zulu> asac: i bootstrap from the a source tarball then gclient sync
<asac> fta: so just trunk. ok
<fta> not really, but close
<asac> fta: yeah its trunk minus something
<asac> fta: so if LOCAL_BRANCH does not yet exist will get-orig-source create it?
<pace_t_zulu> fta: where is debian in the tree?
<fta> asac, it's trunk + all src/DEPS for linux + tools
<fta> yes, if the value of LOCAL_BRANCH does not exist, it's created, otherwise, it's updated
<pace_t_zulu> fta: basically what you would get from a source tarball + tools
<asac> fta: ok so LOCAL_BRANCH is created
<asac> pace_t_zulu: that command shoujld then work
<asac> for me it starts to pull stuff from svn
<asac> just ensure that you have the ../upstream directory
<asac> and its empty
<asac> pace_t_zulu: dont do anything with the tarball you want to bootstrap from
<fta> the initial idea of LOCAL_BRANCH is to prevent the daily 3GB checkout for the daily ppa
<asac> fta: yeah i understand that. wasnt sure if one needed to bootstrap that manually
<fta> nope
<fta> as long as you have the permission to write there, the script will work
<asac> pace_t_zulu: so its just because you have no ../upstream directory
<pace_t_zulu> so you need a ../upstream directory relative to the debian directory?
<fta> you can point LOCAL_BRANCH to anything, relative or absolute, it doesn't matter
<asac> pace_t_zulu: i updated the instructions to include this nit
<pace_t_zulu> asac: thank you
<pace_t_zulu> fta and asac: is there anything i can do to contribute?
<pace_t_zulu> asac: should the 'upstream' directory be in the 'chromium-browser' directory?
<asac> pace_t_zulu: no everywhere, but not there
<asac> pace_t_zulu: ok also added how to actually build the package
<pace_t_zulu> asac: thank you... i would still like to help in any way possible
#ubuntu-devel 2009-05-15
<asac> pace_t_zulu: stripping down the third_party libs/source that are required in the source tree is a continuous task i would say
<asac> pace_t_zulu: there might be some third party sources that could be packaged (e.g. skia for instance)
<asac> fta: do you know how stable skia is abi/api wise?
<fta> i don't think it is, it's very chromium oriented
<pace_t_zulu> asac: http://skia.googlecode.com ... make a skia.deb or libskia.deb ?
<asac> hmm. then i dont see why they dont fix the skia font api to allow proper on-demand fallback through fontconfig
<fta> and chromium is now pulling skia from trunk
<fta> same for v8 and webkit
<asac> from how the bug read they seemed to rather not change skia
<asac> fta: yeah. but trunk doesnt necessarily mean that the ABI/API is unstable
<asac> but i see what you mean.
<fta> asac, they are evolving in parallel. so we'll have to bump them at the same pace. like ff and xul
<pace_t_zulu> asac: i suppose their modifications to webkit make it unreasonable to depend on libwebkit
<pace_t_zulu> ?
<asac> fta: yeah. but skia is also used by gears
<asac> so i thought there was potential
<fta> gears is small in comparison
<asac> yes, still needs reduction :)
<fta> pace_t_zulu, upstream said chromium will never work with libwebkit
<ion_> Why is that?
<pace_t_zulu> fta: *never*?
<fta> tricky. their copy of webkit is built with chromium specific flags, and it needs the chromium sources to build
<pace_t_zulu> fta: i know they wanted to push their webkit modifications upstream...
<fta> they did, for the most part
<pace_t_zulu> fta: i understand why it wouldn't right now... but *never* seems quite absolute
<fta> to be more accurate, when i asked how far it was from building with a system webkit, they said "pretty far. We'll never work with something like webkitgtk."
<fta> if you look at the code, it's easy to understand why
<pace_t_zulu> fta: fair enough
<fta> i want as many system libs as possible since day 1, but it's not the priority upstream, they want feature parity with windows 1st
<pace_t_zulu> fta: understandable... i'm with you on system libs
<fta> i worked last year to move about 12 libs to system libs, but it was creating so many regressions in the testsuite that i decided to fallback
<fta> most of our libs are sort of "not good enough"
<fta> our libjpeg for example, far too old
<fta> we lack about 10 years of patches and optimizations
<pace_t_zulu> fta: why would we have such an old libjpeg?
<fta> i introduced the -testsuite package to easily spot regressions when moving libs to system libs, but the testsuite needs some love
<fta> pace_t_zulu, because upstream is dead
<asac> fta: do we know where they too the libjpeg from?
<fta> yes, from mozilla
<asac> fta: maybe they copied firefox libjpeg which seems to be a fork
<asac> yeah
<fta> mozilla should be the new upstream, the jpeg consortium died 10y+ ago
<asac> right
<pace_t_zulu> what if we package a 'libjpeg-mozilla' ?
<asac> so we might wnat to consider that
<pace_t_zulu> or something like that
<fta> asac, i asked mconnor, he liked the idea
<pace_t_zulu> how does wegkitgtk get away with using libjpeg?
<asac> well. for that i would at least like to know someone who can explain to me what changes were done :)
<asac> but even in mozilla tree most changes are so long ago that its hard to find out
<pace_t_zulu> fta and asac: did you guys see my blueprint for giving chromium a "Human" theme?
<fta> i tried to split the patches between moz trunk and the last known upstream jpeg, got like 110 commits since the "free the lizard" day (when the netscape code was freed), plus a giga commit before that
<fta> chromium is not yet "themable"
<asac> right. we looked at that at some point. i stopped looking at patches when there were commits without even a bug referenced
<pace_t_zulu> does mozilla have a libjpeg or has it become too much embedded in the mozilla codebase?
<fta> they have their own version, but it's easy to split
<fta> i wanted a clean patch stack on top of our lib, it turned out to be almost impossible
<pace_t_zulu> fta: what if we were to try to split it and create a libjpeg-mozilla ? whatever the name may be
<fta> it only makes sense if it replaces our lib
<pace_t_zulu> or is that undesirable... i suppose patching our libjpeg is what you are looking for
<pace_t_zulu> fta: right...
<pace_t_zulu> fta: i assume our libjpeg comes from Debian... correct?
<fta> yes
<pace_t_zulu> asac: i know you are on the firefox team... would it be useful to build firefox against a patched libjpeg?
<fta> one experiment could be to package from the mozilla sources and see if it creates regressions in gnome
<fta> we used to build firefox with system jpeg, until it started to crash when printing
<fta> and it was also much slower as we don't have the mmx/sse/sse2 optimization mozilla have
<fta> so i guess the whole desktop could benefit from that
<pace_t_zulu> fta is this something that is doable before karmic is released?
<asac> i think its worth to look at that during UDS
<lifeless> TheMuso: btw I'm done on the isw bug
<lifeless> TheMuso: nothing further to do at this point pending that kernel patch and upstream waking up
<fta> pace_t_zulu, everything is doable, depending on how much time you can spend on this ;)
<pace_t_zulu> asac how long would it take to pull libjpeg from the mozilla codebase?
<pace_t_zulu> fta, like i said... i am very interested in contributing...
<pace_t_zulu> fta, i am also a fast learner
<fta> to pull libjpeg from the mozilla, hm, 1 sec ?
<fta> well, with hg, more, you have to clone the full trunk
<pace_t_zulu> !hg
<ubottu> Sorry, I don't know anything about hg
<asac> i think its technically easy
<asac> the problem is more of figuring what we really want
<fta> http://hg.mozilla.org/mozilla-central/file/38d50cc03a72/jpeg/MOZCHANGES :(
<TheMuso> lifeless: right
<fta> "????/??/??  -- Lots of undocumented changes. :("
<fta> asac, eh.. a fast libjpeg creating no regression? :)
<pace_t_zulu> fta ftw
<pace_t_zulu> the discussion has fallen silent
<asac> i think there is a consent that this is a good idea and that we will look at UDS at this
<fta> asac, is mconnor coming?
<asac> not that i know ;)
<pace_t_zulu> i would love to go to UDS
<pace_t_zulu> maybe next one
<pace_t_zulu> asac: http://pastebin.ubuntu.com/172669/
<asac> you need to install a package called bzr-builddeb
<pace_t_zulu> asac, thank you
<pace_t_zulu> shouldn't that be in ubuntu-dev-tools?
<pace_t_zulu> hmmm....
<pace_t_zulu> the builddeb is checking out a new copy of chromium
<pace_t_zulu> seems as if fewer commands are needed
<pace_t_zulu> i'm learning here... i'll figure out why it is going through these steps
<asac> pace_t_zulu: i think we should move that discussion to #ubuntu-motu ;)
<pace_t_zulu> asac and ftw: thank you for being patient w/ me
<asac> pace_t_zulu: you didnt place the tarball in the right dir
<lamont> hrm.. someone correct me if I'm wrong... when I say 'extract' to sound juicer, it's not supposed to immediately terminate, right??? :-(
<lamont> in jaunty
<lamont> where does it drop logging/watever?
<lifeless> valgrind sound-juicer
<lifeless> :)
<lamont> strace comes to mind as more appropriate... this is totally immediate
<lifeless> yeah
<lamont> --- SIGSEGV (Segmentation fault) @ 0 (0) ---
<lifeless> you're thinking 'deliberately quit
<lifeless> I'm thinking 'fail
<lifeless> and.. I win :)
<lamont> no, I wasn't thinking deliberately quit
<lamont> seb128 wouldn't do that to me
<pace_t_zulu> so asac... i'm not seeing a libjpeg in the firefox source
<pace_t_zulu> asac: would libjpeg need to be checked out directly from mozilla?
<pace_t_zulu> asac: i suppose i need to learn mercurial now :)
<lamont> lifeless: never try to extrack with a blank title
<lifeless> lamont: fun
<lifeless> lamont: This is why writing a desktop environment in C is a good idea
<lamont> well the alternative is to have it perform like it's interpreted. :-p
<lamont> brb
<Sarvatt> is the gcc atom patch going to be permanently dropped now then? :(
<quentusrex> I think I've found a memory issue with Xorg
<quentusrex> Xorg is currently taking up 1.8GB or residential ram on my box that has 4 GB of ram.
<Chipzz> quentusrex: 1) this is not the right channel to report bugs; 2) there is #ubuntu-x (or ubuntux, dunnow off-hand) and 3) are you sure it actually takes up that much? what top reports is not the amount of memory it actually uses
<Chipzz> that being said, please move to #ubuntu-x
<dholbach> good morning
<lifeless> hmmm, must fix dmraid udev rules
<lifeless> 'dmraid -ay' in console on every boot isn't pretty
<TheMuso> lifeless: I'd be interested in why either dmraid-activate is not being run, or a log of dmraid-activate with -x itself.
<lifeless> TheMuso: have you seen other like issues before?
<lifeless> TheMuso: if so point me at bugs and I'll just fix this
<lifeless> dmraid-activate is in the initramfs
<TheMuso> lifeless: yes, and no I haven't seen issues like this so far as I have determined.
<TheMuso> lifeless: no hurry, just whenever you can get a log of dmraid-activate running in the initramfs
<TheMuso> ./c
<lifeless> ok
<lifeless> 358255 may be related
<lifeless> though I'm not using lvm its possible the root cause isn't an interaction
<lifeless> (filing a bug to track my case)
<lifeless> TheMuso: Is there anything more I need to do, or you'll land it in karmic?
<TheMuso> lifeless: to fix that problem? I will land it in karmic first, and if needed, can SRU for jaunty.
<lifeless> as long as dmraid isn't altered in jaunty I don't care if you do/don't
<lifeless> but if it gets changed, I'd really like the patch in, so that it doesn't regress :)
<TheMuso> Ok.
<lifeless> how do you log output from a initramfs ?
<TheMuso> What I'd do, is modify dmraid-activate to log a file output to /dev/.initramfs/filename and set -x
<lifeless> thanks
<pitti> Good morning
<lifeless> hi pitti
<pitti> 05/15/09 02:40:02: checking #376771 for duplicate
<pitti> DEBUG: blacklisted from auto-duplication 260001
<pitti> cjwatson: ^ seems to work
<dholbach> can someone please get ibus-table-extraphrase out of binary new?
<saravanan> hi
<dholbach> ara: you rock! :)
<ara> dholbach: :)
<c_korn> '%WN?hzJ9".pzG3MRPpkD
<c_korn> oops, this was my passphrase :P
<dholbach> c_korn: it very much looked like one :)
<pitti> c_korn: very good one, though; too bad it got busted now
<pitti> must have taken a week to learn it
<dholbach> can an ubuntu-archive member please get ibus-table-extraphrase out of binary new? :-)
<pitti> dholbach: done
 * dholbach hugs pitti
<dholbach> that'll make reviewing, building and testing the other ibus-* packages on REVU a bit easier :)
<tkamppeter> pitti, hi
<tkamppeter> pitti, I have uploaded the SRU for bug 376732 now.
<ubottu> Launchpad bug 376732 in foomatic-filters "Hardy foomatic-rip PageSetup is broken, fails LSB tests" [Undecided,Fix released] https://launchpad.net/bugs/376732
<pitti> tkamppeter: I had some questions in the bug report
<tkamppeter> pitti: I have answered in the bug report. It is really a regression against Hardy and the patch to fix it is MUCH smaller than the diff attached to the original LSB bug report.
<pitti> bryce: if you have scripts which evaluate HalComputerInfo from apport-generated bugs, you need to adapt them; I ripped out hal from apport now and replaced it with udev db/log. Please let me know if you need any help with that
<bryce> pitti: I don't actually interpret HalComputerInfo in particular, but that's good to know
<pitti> bryce: ok; I checked the source_xorg.py hook, and it shouldl still be okay; I'll run a few tests, just to be sure
<bryce> pitti: I've been thinking it would be nifty to have some stock python code that reads/writes a data "structure" from the bug description that provides basic hardware/software version information
<pitti> bryce: you know that there's code to convert a LP bug report back into an apport.Report dictionary?
<pitti> bryce: would that help?
<bryce> something like,  "foobar: 1.2.3\nbarfoo: 3.2.1" etc.
<bryce> maybe; I'll have to take a look
<pitti> phone, brb
<pitti> bryce: so you would say "report = download(12345)"
<pitti> bryce: and then could access report['Package'], report['Uname'], report['UdevDb'] etc.
<pitti> bryce: the download call is about two or three lines of code
<bryce> pitti: I think what I'm thinking of is a touch orthogonal
<bryce> pitti: I'm thinking more along the lines of a plain and simple set of "key: value" pairs in the bug description
<bryce> that can be loaded, modified, and saved back into the bug
<pitti> bryce: don't we have that already?
<pitti> not the 'save back' of course
<bryce> pitti: well that's the magic; it builds on what is already there
<bryce> justs adds a more read/write aspect to it
<bryce> which allows us to "accumulate knowledge" as the bug progresses
<pitti> right now, crashdb.update() for launchpad only attaches new comments
<pitti> but it should be possible to make it change the description
<bryce> what we don't have right now is an API for doing this
<bryce> but it ought to be pretty trivial.
<pitti> bryce: I think I have a rough idea about it; let's talk about it in Barcelona, shall we?
<bryce> pitti: sounds good
<bryce> pitti: won't have to wait long :-)
<directhex> i think i've lost my euros again. i should put them somewhere safe
<lool> pitti: Can apport be reenabled now?  ISTR some work is ongoing for soyuz support of ddebs
<pitti> lool: that's pretty independent of soyuz
<seb128> please don't reopen apport now, we will be flooded by crash bugs, it's early in the cycle, after uds rather
<pitti> it's primarily a matter when we start wanting to open the floodgates
<lool> Waiting is fine for me; I'll just turn it on where I need it
<seb128> pitti: the gvfs gdu monitor crash every time I start gedit on my desktop btw, did you get the same issue?
<seb128> I noticed yesterday because I enabled apport to take screenshots
<pitti> seb128: I have apport enabled, too
<pitti> gedit starts fine here
<seb128> pitti: gedit starts fine but I get a gdu crash after that
<pitti> hm, I don't
<seb128> pitti: https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/376145
<ubottu> Ubuntu bug 376145 in gvfs "gvfs-gdu-volume-monitor crashed with SIGSEGV in gdu_pool_get_presentables()" [Medium,Triaged]
<lool> Can I get apport to run with a SIGABRT?
<seb128> no
<seb128> there is a spec about that I think
 * pitti is on the phone
<lool> Ah I can't run strace under valgrind
<lool> I guess both use ptrace
<seb128> lool: https://blueprints.edge.launchpad.net/ubuntu/+spec/security-karmic-apport-abort
<cjwatson> I wouldn't have thought valgrind used ptrace - it's more like an emulator
<lool> seb128: thanks
<lool> cjwatson: Me neither; it's the only reason I could think of for its non-transparency
<lool> Actually "valgrind strace ls" works fine
<lool> So I get permission denied under valgrind + strace and not under strace
<tjaalton> pitti: hal ships 10-x11-input.fdi, but so does evdev in debian. maybe we should take the one from evdev instead?
<pitti> tjaalton: is that in upstream evdev? (since it's in upstream hal)
<pitti> I wouldn't mind removing it from hal upstream
<pitti> tjaalton: OTOH, xorg's -evdev should better be converted to not use hal at all any more :)
<pitti> Keybuk: apart from /var/log/udev and an udev db dump, can you think of anything else an udev-extra apport hook should collect?
<Keybuk> pitti: could we get a udev hook to do that at the same time? :p
<pitti> Keybuk: hm, perhaps we should add that hook to udev itself, and  udev-extra just ships a symlink to it
<Keybuk> dmesg/kern.log is often helpful
<pitti> Keybuk: snap :)
<pitti> Keybuk: attach_hardware() does that, too
<pitti> Keybuk: in fact, attach_hardware() already has all of that
<pitti> cpuinfo, cmdline, lsusb, lspci, DMI, udev db, udev log, dmesg
<Keybuk> yeah, that bunch
<pitti> Keybuk: will do that then
<tjaalton> pitti: actually not from upstream, debian added it. well, I don't mind keeping status quo for now
<pitti> tjaalton: since I hope all of this will disappear very soon, I don't particularly mind either :)
<tjaalton> pitti: you can hope, but upstream has no plans beyond hal :/
<pitti> tjaalton: do you happen to know if there's some upstream movement to move away from hal towards asking udev for input devices?
<pitti> hm, is that a lot of code?
<tjaalton> pitti: the server already supports dbus
<pitti> I can't imagine xorg would have been infested by lots of hal specific code
<Keybuk> pitti: the cabal certainly spoke to keith at it in SF
<Keybuk> he was keen
<Keybuk> especially since the libudev socket filtering stuff allows it to only receive input subsystem events
<seb128> lool: btw where have you seen ongoing soyuz ddeb work?
<pitti> Keybuk: attaching the file names in /etc/udev/rules.d/ might also be interesting?
<Keybuk> pitti: possibly, though in practice everything in that directory is user-generated
<pitti> Keybuk: exactly
<Keybuk> in general, it's better to get udevadm test results as they're more revealing
<pitti> we might check for weird local customizations
<Keybuk> but sure
<pitti> Keybuk: that needs a devpath, though?
<tjaalton> pitti: it's 660 lines, so not that much ;)
<lesshaste> hi all
<pitti> Keybuk: is there some general command we could put into the hook for that?
<cjwatson> seb128,lool: https://bugs.launchpad.net/soyuz/+bug/285205
<ubottu> Ubuntu bug 285205 in soyuz "Soyuz needs to be able to process and publish ddebs" [Medium,Fix committed]
<pitti> !
<pitti> *bounce*
<cjwatson> I was about to ask whether anyone had been coordinating with pitti - guess not ;-)
<pitti> cjwatson: well, we discussed how the system needs to look like about a year ago
<cjwatson> I meant for deployment
<pitti> not so far
<seb128> excellent
<seb128> I didn't know they were actively working on it now
<Keybuk> pitti: only if you have a devpath that's broken
<lesshaste> is it well known that if you install adobe-flashplugin with gnash already installed mozilla just silently ignores it?
<lesshaste> s/mozilla/firefox
<lesshaste> it's quite an annoying feature
<seb128> firefox let you choose which one to use
<lesshaste> seb128:  no it completely ignores it.. i.e. it doesn't show up in about:plugins
<seb128> what ubuntu version do you use?
<lesshaste> hardy
<seb128> ok, that's a new feature, it was not in hardy
<seb128> it's there in jaunty
<lesshaste> ah I see
<lesshaste> maybe this counts as a bug?
<lesshaste> it certainly confused me for about an hour
<seb128> it does count as a bug but that's not likely to change in hardy
<lesshaste> cough.. lts.. cough :)
<pitti> Keybuk: check out https://bugs.staging.launchpad.net/ubuntu/+source/udev/+bug/376248
<ubottu> Ubuntu bug 376248 in teeworlds "Ubuntu 9.04 has an obsolete version of teeworlds" [Undecided,New]
<lesshaste> shall I report it?
<pitti> Keybuk: (ubuntu-bug udev)
<seb128> lesshaste: no
<seb128> lesshaste: lts means security support, not that every new feature will be added to the lts
<pitti> Keybuk: CustomUdevRuleFiles will only appear if there are actually files besides 70-persistent-* and README
<seb128> lesshaste: the firefox code to let you choose what plugin to use is probably non trivial and will not be considered as a stable update candidate
<seb128> lesshaste: and it's easy to workaround, uninstall the one you don't want to get used
<Keybuk> pitti: perfect
<Keybuk> pitti: odd errors in CurrentDmesg.txt
<pitti> Keybuk: whoopsie, good catch
<pitti> Keybuk: ugh, I have some serious trouble building an udev source package
<pitti> complains all the way about test/sys/
<tjaalton> pitti: you wanted to know if the hotkeys ceased working? The battery/suspend keys don't work on my thinkpad X61, although it could be that what should be listening to those is busted
<pitti> Keybuk: I pushed my apport hook, but i got to leave for ~ 1 hour; I'll wrestle with it later, unless you beat me to it
<pitti> tjaalton: ok, later, need to leave, sorry
<tjaalton> pitti: heh, ok
<Keybuk> pitti: -i'(^|/)(\.bzr|\.gitignore|test)($|/)' :p
<jazzdog> hi
<jazzdog> i have fixed a lot of warnings in the sniffit package. this should fix this bug: https://bugs.launchpad.net/ubuntu/+source/sniffit/+bug/107180
<ubottu> Ubuntu bug 107180 in sniffit "Segmentation Fault" [Undecided,Invalid]
<jazzdog> how can i help the community with this? :)
<Keybuk> jazzdog: https://wiki.ubuntu.com/DeveloperGuide/Sponsorship
<jazzdog> Keybuk: thanks. could you please explain the 1st and 4th point under "attach your work" and the difference between them? sorry I'm new to ubuntu, coming from slackware
<Keybuk> jazzdog: if you're looking to get involved, try #ubuntu-motu
<lifeless> TheMuso: what are the parameters to run dmraid-activate with ? I happen to have needed to reboot...
<TheMuso> lifeless: Probably the best way to get a log is to modify the file, adding set -x and dumping to a log file in /dev/.initramfs, regenerating the initramfs and rebootingv.
<lifeless> TheMuso: yeah, I will
<lifeless> TheMuso: the reboot was hardware :P
<lifeless> TheMuso: but as I had it at the prompt I thought I'd ask
<TheMuso> lifeless: ah ok.
<TheMuso> best bet to see whats going on at a glance is to run sh -x /sbin/dmraid-activate sda or dmraid-activate sdb
<TheMuso> sorry dmraid-activate /dev/sda/b
<TheMuso> so either drive
<lifeless> yah
<lifeless> I tried that
<lifeless> dmraid-activate /dev/sda
<lifeless> dmraid-activate /dev/sdb
<lifeless> no output, no activation
<TheMuso> and nothing?
<TheMuso> cdid you run with sh -x?
<TheMuso> s/cdid/did/
<lifeless> no didn't think to run it that way
<TheMuso> right
<Keybuk> cjwatson: have you ever seen make utterly fail to traverse deps?
<cjwatson> Keybuk: not in a way I ever proved to be make's fault :-)
<cjwatson> usually turned out to be me misunderstanding some abstruse feature of GNU make
<Keybuk> I think it's bzr's fault
<Keybuk> shelve has done weird things to my timestamps
<lool> Ok so my strace/valgrind issues were: setuid/setgid executable can't be run by valgrind; strace was crashing in jaunty, I filed bug #376858, but the karmic version fixes this
<ubottu> Launchpad bug 376858 in strace "strace: malloc(): memory corruption (fast): 0x00000000026452c0" [Undecided,Fix released] https://launchpad.net/bugs/376858
<lool> Otherwise it's perfectly fine to run python or strace under valgrind
<cjwatson> lool: I was going to suggest set-id problems earlier, but you gave ls as your example so I decided not to bother ...
<cjwatson> I don't suppose that a similar set-id-handling trick to the one mentioned in strace(1) works with valgrind?
<lool> cjwatson: having an alternate suid valgrind?  (there's also the -u flag, but didn't see the corresponding valgrind flag)    I guess I can try out
<cjwatson> that's what I meant, yes
<lool> cjwatson: It didn't work to run valgrind suid root
<lool> Albeit interestingly I didn't get the warning
<lool> that said, I'm not running the suid root program directly, but via pyhton
<Riddell> pitti: we have a couple of non-trivial SRU requests
<Riddell> pitti: firstly plasma-widget-network-manager is broken in many ways in jaunty which is quite a big problem for people
<Riddell> we have a new version which fixes a lot of scenarios but it's a new snapshot and not a simple patch
<directhex> who should i poke if a link on summit.ubuntu.com is 404ing?
<Hobbsee> directhex: Keybuk, usually
<pitti> Keybuk: ah, thanks for the magic :)
<directhex> Keybuk, the link for "Xorg: Driver Selection for nvidia hardware" points to +spec/driver-selection-for-nvidia-hardware instead of the correct +spec/desktop-karmic-xorg-driver-selection-for-nvidia-hardware/
<pitti> Riddell: my primary requirement is "does it cause regressions"
<pitti> Riddell: so if not a lot is working with the current version, and it's a major regression wrt. intrepid, it sounds feasible
<pitti> how intrusive are the chnages?
<pitti> just 100 individual bug fixes or a complete rewrite?
<Riddell> pitti: 100 bug fixes
<Riddell> beta quality vs alpha
<Riddell> we've been testing it quite a bit and havn't heard of any regressions
<pitti> Riddell: sounds like we should let it mature in -proposed for a while then
<Riddell> yes
<Riddell> pitti: the other SRU is KDE 4.2.3
<Riddell> which has also been tested in PPAs and seems  to have no problems
<directhex> the whole thing?
<pitti> Riddell: that sounds quite a bit more ambitious, and much harder to test for regressions..
<Riddell> nothing we have done before for intrepid
<Riddell> directhex: sure why not, if  upstream make bugfix releases it seems impolite not to use them
<pitti> yeah, unfortunately we were pretty lax with intrepid SRUs because that was so broken in the first place
<pitti> but jaunty itself should be much better?
<directhex> Riddell, it's never been 100% clear to me the attitude towards bugfix releases versus bug fix patches
<pitti> they just bind a lot of work and cause instability, so we shouldn't do them too liberally
<pitti> can we at least limit it to individual components were people filed actual bugs against?
<Riddell> ok, maybe ScottK will want to argue the case more or knows of paticular packages which have important fixes
 * ScottK looks up.
<ScottK> pitti: I would argue that our experimentation in Intrepid showed that we we can reasonably reliably deliver KDE point releases without regression.  Equally it shows that users benifit from the update (I certainly did).  I think that if we can repeat the process for Jaunty it would be of benifit to the users.
<ScottK> pitti: I also think that we should minimize proliferation of of unofficial repositories and deliver this via the Ubuntu archive.
<pitti> ScottK: that's a knockout argument
<pitti> because it applies to all packages
<pitti> and kind of defeats the purpose of a stable release
<pitti> we had that major exception in intrepid because it was particularly bad when released, but jaunty wasn't
<ScottK> I can also see this being a case where you might want the tech board to decide.
<pitti> and if we keep concentrating on fixing stables instead of fixing development releases, we invest in the wrong direction
<ScottK> I do think the benifit from from 4.1.4 was less than 4.1.3.
<pitti> we stretched the SRU policy a lot in intrepid, but we can't maintain this forever
<ScottK> I think it might be reasonable just to deliver the first update and not the 2nd.
<pitti> ScottK: of course you are welcome to challenge this on the TB, of course I'll comply to a TB decisisuionm
<ScottK> pitti: I'd rather not have it be a challenge against what you say, I was hoping more we could come up with something you could support.
<ScottK> TB specifically is the authority to grant microversion update exceptions.
<directhex> compromise: ubuntu-backports ?
<lool> Is there no special provision for point updates to KDE sources like there is for GNOME packages?
<Riddell> we want backports for new KDE versions
<ScottK> So if Intrepid was an experiment, then we get official approval before doing it in Jaunty (or not).
<ScottK> directhex: That would be my plan B, but as Riddell says has other complications.
<Riddell> lool: what special privision does gnome have?
<ScottK> lool: There is not (I think we should get one).
<pitti> ScottK: it's not "against me", it's "against SRU policy"
<ScottK> pitti: OK.
<pitti> it's not like I'd arbitrarily decide that :)
<pitti> lool: we don't update GNOME packages either
<lool> I thought GNOME had special exception to not have a too heavy SRU process just after release
<pitti> lool: that only applied to hardy
<pitti> a decision by TB
<lool> Hmm ok, for some reason I thought it was permanent, nevermind then
<pitti> and we really, really, REALLY need to stop throwing so much time at stables
<ScottK> Riddell: How about jaunty-backports for now and then ask TB to add KDE to https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
<pitti> we do not have enough development power for that, and users don't appreciate installing 100 MB of updates every day either
<lool> The thing is that we don't get enough QA and we push a lot of changes until the last minute, I'm in a bad position to criticize this as I had to do so myself to reach some goals in previous releases
<ScottK> pitti: For the KDE updates it isn't a manpower issue.  We will package them.  The only question is where do we deliver them.
<Riddell> ScottK: can do although if they don't approve Gnome I doubt they'll approve KDE
<ScottK> Did Gnome ever ask?
<lool> When I say QA above, I mean community testing; I think QA works well on some key stacks, but not on the less used packages  :-/
<ScottK> Riddell: I wouldn't have dared ask for KDE in the KDE3 timeframe as they did not do bugfix only releases.  I think in 4.1/4.2 they have shown discipline about it.
<pitti> ScottK: you also need to test them heavily, and the bigger the updates get, the harder it is to ensure that it doesn't have major regressions
<pitti> and there's also the user inconvenience of downloading tons of updates
<ScottK> pitti: This is true, but I think we've shown we can do the testing.
<ScottK> We also have a lot of user demand for the updates.
<seb128> lool: the issue is that stable is what most users are using
<lool> seb128: Yeah
<pitti> ScottK: right, but it still binds manpower
<ScottK> 4.2 is a lot better than 4.1, but it's not nearly as stable as KDE3 yet.
<seb128> I had the discussion this week with pitti about GNOME stable updates
<pitti> some people demand updates all the time, but *shrug8
<lool> seb128: But we have a really large window where people are encouraged to upgrade to shake out bugs
<ScottK> pitti: Yes, but we are going to do the work anyway.
<pitti> ScottK: see, and that's what I'd like to see stopped :)
<ScottK> In this case we've already done it, so it's a sunk cost in any case.
<lool> seb128: Usually, from beta to final I am always too busy to take new stuff on my plate, such as new bugs discovered by people upgrading
<seb128> lool: I consider jaunty as a good version and worth stabilizing it a bit, especially where karmic shape to be a bumpy one
<seb128> lool: I expect lot of people will want to stay on jaunty over karmic
<ScottK> Oh dear.
<lool> seb128: Makes sense
<ScottK> seb128: Hopefully not Intel video users.
<ScottK> I hope that gets better.
<seb128> I'm not interested in trolls
<ScottK> seb128: I'm not trollilng.  The Intel video experience on Jaunty is sub par and saying so is just stating facts.
<Hobbsee> is karmic any better yet, though?
<pitti> ScottK: agreed
<pitti> Hobbsee: it will be differently broken
<seb128> it's not an issue problem and not something ubuntu has total control on
<Hobbsee> pitti: well, yeah, I guess that's normal :)
<seb128> issue -> easy
<pitti> Hobbsee: intel, I mean, with all the new UXA/KMS stuff
<ScottK> seb128: I wasn't laying blame.  I was hoping next time it would be better.
<seb128> hey Hobbsee, long time that I didn't talk to you, how are you?
<Hobbsee> pitti: that's true.
<pitti> yeah, intel wise jaunty was quite a dent :(
 * directhex thinks calm & beer should be liberally issued
<seb128> I expect that karmic will not be a good luser version
<tjaalton> ScottK: it can't get any worse ;)
<Hobbsee> seb128: heya!  I'm doing OK.  Not really active, focussing mainly on uni work, to get it finished.  Done at the end of the year, into the big wide world - woot!
<Hobbsee> tjaalton: sure it can.  Hardy I could'nt play video most of the time ;)
<Hobbsee> tjaalton: intrepid plays video.
<Hobbsee> er, wait.  s/hardy/intrepid; s/intrepid/jaunty/
<tjaalton> Hobbsee: lucky you :)
<Hobbsee> tjaalton: oh, indeed.  I just didn't watch any movies on this laptop for 6 months or so ;)
<jazzdog> comeon, everything plays video if one builds mplayer himself :)
<Hobbsee> jazzdog: actually, the only thing that would work for me was xine-ui ;)
<Hobbsee> which was...interesting
<ScottK> pitti and Riddell: Did we reach some resolution on a path forward?
<pitti> ScottK: I'd really like you to reconsider and focus efforts on karmic, but as I said, if you think you want an exception, you should feel free to ask the TB
<ScottK> pitti: OK.  Thanks.
<Riddell> I'm pretty sure the kubuntu team will always want to make backports, they're very popular (at least we get a lot of complains from being late with 4.3 beta)
<ScottK> Riddell: ?  Backports and then think about it (backports won't conflict until 4.3.0 so we have some time)
<Riddell> ScottK: yeah go for  it
 * Riddell out for a bit
<Hobbsee> Riddell: not to mention they've routinely made backports on kubuntu.org, too
<Hobbsee> or at least, back when I ran it
<directhex> Hobbsee, exciting career plans yet?
<Keybuk> directhex: poke rickspencer or pitti ;)
<Hobbsee> directhex: none yet.  Hoping to get bites when I've finished the degree, or close to it.
 * directhex redistributes buck
<ScottK> Hobbsee: That's a good point (re kubuntu.org).
<ogra> cjwatson, poke ... http://ports.ubuntu.com/ubuntu-ports/pool/universe/l/linux/ seems all linux packages for armel landed in universe again
<cjwatson> ogra: OK, I'll have a look, thanks
<ogra> thanks for looking
<cjwatson> ogra: should be fixed for the next relevant publisher run (visible a bit over 1.5 hours from now)
<ogra> cjwatson, thanks a lot
<soren> I see this is accepted for UDS, but I can't see it on the schedule anywhere? https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-karmic-swapfile
<cjwatson> soren: we took it off as it's already been discussed twice and just needs time to implement
<soren> cjwatson: Alright. Thanks.
<pitti> what the heck went wrong with the PPAs?
<pitti> amd64      6010 builds waiting in queue
<pitti> i386      11538 builds waiting in queue
<pitti> if that isn't a DoS, what is?
<directhex> 11539 builds is.
<directhex> 11538 is merely popularity
<directhex> cjwatson/test-rebuild-20090513
<directhex> that answer your question?
<pitti> ah, I see
<pitti> *phew*
<pitti> I thought something was going crazy and reuploaded infinitely or so
<directhex> i can do that if you want
<sistpoty|work> oh, pitti: did your copying from jaunty-updates forward to karmic somehow confuse MoM? faumachine is now listed in universe-manual despite an identical tarball?
<sistpoty|work> (not that it matters in regards to faumachine, but maybe other packages are affected as well)
<pitti> sistpoty|work: hm, entirely possible, I don't know
<pitti> but we have done that for a long time already
 * apw looks for a main-sponsor to upload a grub change to karmic/jaunty, on bug #376879
<ubottu> Launchpad bug 376879 in grub2 "grub2 installer modifies grub 0.97 menu.lst incorrectly and fails to chainload grub2" [Medium,In progress] https://launchpad.net/bugs/376879
 * seb128 points apw to ubuntu-main-sponsors on launchpad to subscribe to the bug
<apw> seb128, t'is done
<seb128> apw: ok something will look at it while doing sponsoring I guess
<pitti> oh, argh
<pitti> lool: you uploaded sqlite-3 to -updates instead of -proposed, and I failed to spot that
<lool> pitti: Crap; sorry
<lool> I really am not in a good shape today
<pitti> I removed the package again
<lool> pitti: Thanks
<lool> pitti: Do you have the .Dsc?  I had removed it since it was accepted
<lool> otherwise I'll rebuild it
<pitti> lool: please reupload
<pitti> lool: yes, you can grab it from launchpad
<lool> In "Done"?
<pitti> https://edge.launchpad.net/ubuntu/+source/sqlite3/3.6.10-1ubuntu0.1
<lool> Thanks
<pitti> I set the build score to -1 and will reject any binaries that still make it
<lool> pitti: I'm upload a .2 built with -v to include both versions
<pitti> lool: just rename it .2
<pitti> lool: but your's is fine as well
<pitti> as you like
<lool> pitti: uploaded and
<lool> sorry not accepted yet
<lool> I need a break, bbl
<pitti> I guess they'll just fail to upload, but I'll watch it anyway
<lool> pitti:  subject: [ubuntu/jaunty-proposed] sqlite3 3.6.10-1ubuntu0.2 (Waiting for
<pitti> lool: accepted
<cjwatson> apw: your kexec-tools patches all look fine, thanks (and sorry for the delay); the only change I'm making is that the upload target in debian/changelog for jaunty needs to be "jaunty-proposed"
<apw> cjwatson, doh thanks
<cjwatson> trivial to fix at sponsorship time though :)
<apw> i get caught by that automatic installation of the current distro a lot
<apw> i need to change ti to YOUARESTUPID or something by default
<apw> .. it is all a learning expierence.  one day i'll get one right first time
<cjwatson> apw: by dch -i?
<cjwatson> or dch -r?
<apw> yeah it puts in your local distro release by default (dch -i)
<cjwatson> if you put DEBCHANGE_RELEASE_HEURISTIC=changelog in ~/.devscripts then dch -i will put UNRELEASED in there instead; that said, dch -r will still use the current release (but you could set it by hand as an alternative)
<apw> yeah that would be fine, as it goes nice and RED in there to tell me i've not set it if its UNRELEASED
<apw> cjwatson, perfect thanks
<lool> Do people like the dch -r defaulting to Ubuntu dev under Ubuntu?
<lool> I keep mixing the Debian and Ubuntu behaviors because I work on Ubuntu packages from Debian and vice-versa
<lool> Usually Debian's dch -r does what I want; Ubuntu's is wrong half of the time
<seb128> I almost never use dch -r, I usually use -i or -v new_version
 * ScottK would like a dch -rd or something like that to get unstable
<cjwatson> I use dch -r all the time and like its behaviour
<cjwatson> when I'm working on Debian packages I do so in a Debian chroot, since I need to do binary uploads anyway
<ScottK> I find dch -r works well for me for Ubuntu
<cjwatson> StevenK: can you or one of your team merge libhildon? I'd have no idea where to start
<pitti> lool, ScottK: -d exists, it's called -U
<Keybuk> hmm
<ScottK> pitti: Thanks.
<Keybuk> kernel panic on boot, at exactly the same time, thunder rolls outside
<geser> where is your Igor?
<doko> please could somebody process binutils in NEW (binutils-gold -> universe)
<Awsoonn> Thank you seb128
<lool> pitti: That's just for the version number, right?  jaunty is set unconditionally
<lool> (well unless -Dfoo is used)
<pitti> ah, right
<pitti> -Dunstable would be the target
<seb128> Awsoonn: you're welcome, thanks for the work on the bug
<cjwatson> asac: I've synced wpasupplicant into karmic, since Kel incorporated my patches; you might care
 * asac *nods*
<ebroder> Anyone from motu-sru who could provide an opinion on bug #371581?
<ubottu> Launchpad bug 371581 in erlang "erlang-base conflicts with old erlang-doc-html" [Undecided,New] https://launchpad.net/bugs/371581
<ion_> Anyone feel like uploading command-not-found with the patch from LP #377065, or should i just wait for mvo? :-)
<ubottu> Launchpad bug 377065 in command-not-found "zsh_command_not_found should use the pre*_functions arrays instead of overwriting the singular preexec/precmd functions" [Undecided,New] https://launchpad.net/bugs/377065
<directhex> how would i define which files should be uploaded by apport in the event of an app dying?
<ion_> directhex: /usr/share/apport/package-hooks
<directhex> i should look into what would be needed for apport to get triggered by Managed exceptions in mono apps
<ajmitch> directhex: I remember looking at that awhile ago, back then we discussed havign a small patch to the mono runtime to dump out the right info
<directhex> ajmitch, i'll ask miguel what he thinks
#ubuntu-devel 2009-05-16
<billisnice> 9.04 trying to set up a network printer on window xp machine.  When I get to browse on samba the print routine just disappears...
<billisnice> It worked fine with 8.04 same puters
<billisnice> i am in devel
<billisnice> i will go to ubuntu
<calc> do the current karmic desktop disks work ok?
<calc> as in todays?
<calc> bryce: ping
<calc> bryce: is there a problem with the jaunty intel driver having mild video corruption issues like with drawing fonts... having trash on them, etc
 * calc is going to see how karmic does
<ScottK> calc: Did you try UXA or "MigrationHeuristic" "greedy"?
<calc> ScottK: no, it did seem to work for a long time without issues but now its starting to look weird
<calc> its not slow but actual graphical corruption
<calc> and i'm not doing 3d
<ScottK> I had that (particularly bad in Qt apps, which sucks for me) and both those solutions helped it.
<ScottK> UXA was unstable for me, so I settled on "MigrationHeuristic" "greedy"
<calc> ok
 * calc wonders why it used to work fine but now seems to be happening all the time
<calc> ScottK: you'll be at UDS right?
<ScottK> Dunno.  Computers are weird.  I've got one bug that never used to happen to me that started happening several times a day once someone told me about it.
<ScottK> calc: yes.
<calc> great :)
<mdl-unit> Now this is snazzy/funny.  I'm running Karmic in virtualbox, with the guest using compiz while the host is unable to due to the i965 bug
<cjwatson> calc: don't bother with desktop CDs yet - there's no union filesystem available in karmic so they aren't going to work even a little bit. Use the alternates if you need to install
<Unggnu> hi all
<Unggnu> Do you have any influence on the partner repository? The Flash player for Hardy has still the old version with the security problems while Jaunty and Intrepid not
<cjwatson> Unggnu: the only difference between the version of Flash in hardy and jaunty in the partner repository seems to be a dependency change ...
<cjwatson> adobe-flashplugin | 10.0.22.87-2 | hardy/partner | source, i386, lpia
<cjwatson> adobe-flashplugin | 10.0.22.87-2intrepid1 | intrepid/partner | source, i386, lpia
<Unggnu> cjwatson: hm, I was looking under http://archive.canonical.com/pool/partner/a/adobe-flashplugin/
<cjwatson> actually there's no obvious difference in those packages at all
<cjwatson> I ran debdiff and the only difference is the changelog
<Unggnu> The problem is that Hardy ships with Flash 9 which has problems with Pulse. But if you upgrade it manually you miss the security updates
<cjwatson> Unggnu: I don't think that pool is properly garbage-collected
<Unggnu> cjwatson: Great I thought only 10.0.15.3-1 was for hardy
<cjwatson> so there are still old versions lying around - but if you use apt you'll get 10.0.22.87-2
<Unggnu> thx
<Unggnu> This should fix the security problem
<cjwatson> Unggnu: in general, people on this channel don't have influence over the contents of partner, though (I can inspect it, but that's all)
<cjwatson> Unggnu: the person listed at the top of the changelog (Brian Thomason) is probably the best contact
<Unggnu> Sure but it would be great if Flash for Hardy could be upgraded between the desktop support time of three years.
<Unggnu> thx
<cjwatson> but it has been
<OuZo> Hi, I am trying to compile mpi-ruby. Apparently ubuntu re-names libruby to somthing else. here is my build error paste: http://rafb.net/p/dTptn847.html
<OuZo> in scr/Makefile the LDFLAGS look like this:
<OuZo> http://rafb.net/p/RK11gw23.html
<Keybuk> curious
<Keybuk> all my maintainer scripts in /var/lib/dpkg/info vanished
<ion_> Huh
<hyperair> could someone look at bug #361372?
<ubottu> Launchpad bug 361372 in pidgin "With Pidgin 2.5.5, when logging in to MSN it always pops up multiple windows that say "Friendly name changes too rapidly"." [Low,Confirmed] https://launchpad.net/bugs/361372
<hyperair> debdiff attached.
<hyperair> needs sponsoring.
<calc> how do i erase a gpt label from a disk?
<calc> i erased the first 100MB+ and it still shows up
<calc> ah there is a backup copy at the end of the disk
 * calc is now running karmic and restoring his data :)
#ubuntu-devel 2009-05-17
<wip> hi, is there any change in permission for polling hid device in jaunty?
<wip> even with root i cannot poll any hid device with jaunty
<wip> still trying to use my wacom with jaunty... xinput -list = "Wacom Graphire2 4x5"	id=12	[XExtensionKeyboard]
<wip> [XExtensionKeyboard] that is not right...
<wip> how to change Wacom from XExtensionKeyboard to XExtensionPointer?
 * wip desesperate
<wip> oups..
<ebroder> Why did dh_pycentral start removing symlinked files on upgrades?
<ebroder> It's causing problems for me with the upgrade process in the python-xen-3.3 package because the python-xen-3.3 modules go away before the prerm of xen-utils-3.3 is called, and xen-utils-3.3 needs those modules in place
<ebroder> Wait...since xen-utils-3.3 depends on python-xen-3.3, shouldn't xen-utils prerm get called before python-xen's?
<Amaranth> ebroder: for what?
<ebroder> Huh?
<ebroder> Oh - for stopping xend
<ebroder> Shouldn't all of a package's dependencies still be fully installed when its prerm runs?
<ebroder> Or are they only guaranteed to be unpacked?
<StevenK> Hmmm. Check Debian Policy
<ebroder> Yeah - it definitely seems like the prerm for python-xen-3.3 is being run before the prerm for xen-utils-3.3, in spite of the fact that xen-utils-3.3 depends on python-xen-3.3: http://paste.ubuntu.com/174036/
<ebroder> That's incredibly irritating
<MelisU> Hello, what is the exec key for the directory the file is in?  Like evince %f is for file .. but which key is the dir?
<persia> MelisU, http://standards.freedesktop.org/desktop-entry-spec/latest/ar01s06.html
<MelisU> persia: Yeah I already found that, but which one is for the dir??
<persia> I don't think there is one.  Best to use %f (or %F), and have the application sort it out.
<geser> anyone around who could please give-back findlib? thanks
<Hobbsee> geser: done
<sladen> since the release, at every boot up, 'update-manager' is popping up with three open windows.
<lamont> who knows d-i well?
<persia> lamont, I've read a fair bit of the code, but I can't say I know it well.  What's the question?
<lamont> well, it took me a minute to remember that the netboot initrd gets one -server... I want a netboot ubuntu-desktop...  so what do I need to abuse to fix that?
<persia> Select the ubuntu-desktop task and dselect all the server tasks in tasksel when netbooting?
<persia> You can preseed tasksel, but I don't understand the intricacies of that.
<lamont> persia: that would be the specific question, I  fear
<lamont> though I might have that figured out well enough now
<calc> fsck on a 750gb ext3 usb drive takes a very long time
<sebner> calc: ext4 ext4 ext4 \o/
<ebroder> Does it actually help fsck time?
<ion_> The ext3 performance improvements in 2.6.30 are nice, btw. Not that it affects fsck, though.
<jdong> ebroder: yeah, as long as a significant part of the drive is unused ;-)
<ebroder> That's like saying that my computer is really fast when I'm not running any programs :-P
<jdong> indeed :)
<d1b> ion_: what kind of a performance do they provide?
<d1b> (increase)
<sebner> ion_: I'd stick to ext4
<ion_> d1b: http://kernelnewbies.org/Linux_2_6_30#head-329ba44b44a7f58c98ae22b8f2730418cdd6630d
<jdong> lol by "performance" you mean set data=writeback default? :P
<ion_> jdong: Fixing the issues the change would otherwise have caused (as well as the ext4 issue), and *then* changing the mode.
<jdong> well specifically what did they do to address the potential out-of-order hazards?
<jdong> all I see is fsync-on-rename hacks and such
<jdong> and GRR ath9k, screw you. please stop trying 	tx bitrate:	324.0 MBit/s MCS 28 40Mhz
<d1b> btw any one know how to set the country code for wifi ?
<jdong> d1b: iw reg set...
<jdong> linuxwireless has more info on doing it
<jdong> http://linuxwireless.org/en/developers/Regulatory/CRDA
<d1b> it would be nice if a google turned that up ...
<d1b> couldn't find it before
<d1b>  / not in the iwconfig man page to try iw
<jdong> yeah it's a bit unintuitive
<jdong> and google has a lot of blind-leading-the-blind when it comes to this subject :(
<d1b> + does it default to us ... it should be international
<jdong> I'm not sure what it "defaults" per se to... I think udev rules are supposed to handle locality
<d1b> jdong: what areas are available can't find it / the short names
<d1b> other than us
<calc> d1b: aiui it is supposed to ask the AP
 * calc isn't sure how that works
<d1b> calc: oh. thats fair enough but i know there is said network on channel 13.
<d1b> can't see it.
<jdong> http://wireless.kernel.org/en/developers/Regulatory
<jdong> specifically, http://git.kernel.org/?p=linux/kernel/git/linville/wireless-regdb.git;a=blob;f=db.txt;hb=HEAD
<d1b> k
<olmari> Would there be any possibility to have "server" as type-in selection in mini.iso installation? (is this correct channel to suggest)
<wip> how to change this: "Wacom Graphire2 4x5 cursor"	id=10	[XExtensionKeyboard] to [XEntensionPointer]. my wacom is not a keyboard
<wip> i saw today an update of xserver-xorg-input-synaptics but still no luck with my wacom
<ion_> wip: When you report the bug, please share the link, iâll want to subscribe.
<wip> ion_: will do but i need to be sure it's not just me
<ion_> It might be related to the HALâudev/DeviceKit migration, but dunno really.
<ion_> Or perhaps itâs a bug in the evdev Xorg driver.
<wip> ion_: yes i think it's because of the new way of talking to the device (HAL)
<ripps> Can someone help me with a debuild script of mine, I'm trying to get debuild to ignore several debian.* backup directories that keep for backports. I already use "debuild -i\.git|.hg|.svn|.bzr/" to ignore various vcs directories
<sladen> ripps: can't you just append them to the .-i list
<olmari> Would there be any possibility to have "server" as type-in selection in mini.iso installation? (is this correct channel to suggest)
<Turl1> hi
<Turl1> how can I copy a script in debian/scripts/foo to usr/bin ?
#ubuntu-devel 2010-05-17
<nemo> Hm. I think you guys maybe have something broken in your tab complete...
<nemo>  svn diff sk.bash: [: too many arguments
<nemo> sk.txt  sk.zip
<nemo> (that was me hitting tab on sk. )
<nemo> on a similar front, super annoying that mplayer startofogvfile<tab> does not tab complete - like it doesn't recognise *.ogv
<ScottK> nemo: File bugs.  An IRC channel is not a very good bug tracker.
<TheMuso> crimsun: Sounds good.
<psusi> cjwatson, think you can review my fix for the dmraid regression and upload it as an SRU once some other users successfully test it?  see bug #568050 and the linked bzr branch
<ubottu> Launchpad bug 568050 in parted "Ubuntu 10.04 can't create partition on fakeraid" [High,In progress] https://launchpad.net/bugs/568050
<nemo> ScottK: heh. actual bug tracker isn't a very good bug tracker either. but fine.
<ScottK> nemo: It tends to be a bit more peristent than IRC backscrolls though.
<\sh> moins
<pitti> Good morning
<\sh> moins pitti
<dholbach> good morning
<mvo> hey dholbach
<dholbach> hey mvo
<didrocks> hey dholbach, good morning mvo
<dholbach> salut didrocks
<mvo> hey didrocks!
<AnAnt> Hello
<AnAnt> regarding this bug LP 580944
<ubottu> Launchpad bug 580944 in sl-modem "package sl-modem-daemon 2.9.11~20100303-2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 127" [Undecided,New] https://launchpad.net/bugs/580944
<AnAnt> it is obvious that the /etc/default/sl-modem-daemon (ie. a conf file) has been damaged or tampered with severely, anyways it caused the package state to be not be fully installed
<AnAnt> what's the optimum solution: shall I attach to the user the default conf file & tell him to put it there ? or is there  a way to reinstall the package (& overwriting the conf files)
<AnAnt> mvo: ping ^
<mvo> AnAnt: it would be interessting to know the state of the file
<mvo> AnAnt: so attaching it is a good idea
<AnAnt> mvo: state of the file ?
<AnAnt> mvo: the file is attached
<mvo> AnAnt: oh, ok. let me actually look at the bugreport then
<AnAnt> mvo: that's why I said it was either damaged, or someone severely tampered it
<mvo> AnAnt: indeed, that looks like file system corruption
<mvo> AnAnt: I guess best is removing it and reinstalling with "dpkg -i --force-confmiss /var/cache/apt/archives/sl-modem-daemon_<tab>"
<mvo> AnAnt: or purge/reinstall with apt-get
<AnAnt> mvo: do you think and can be purged ?
<AnAnt> mvo: or even removed ?
<AnAnt> I've seen packages that go into a real bad state that you can neither remove nor upgrade !
<AnAnt> unless I have to remove some prerm for example
<mvo> AnAnt: that is (unfortunately) true, but happens not that often, in this casse it may work, but I have not looked at the orther scripts of the pkg
<AnAnt> mvo: ok
<AnAnt> thanks
<AnAnt> bye
<stgraber> Keybuk: could you have a look at bug 581527 when you have a minute ? the attached patch should hoppefuly make the life of some OpenVZ users a bit easier as well as fix some other cases I don't know about ;)
<ubottu> Launchpad bug 581527 in udev "udev segfaults in udev_monitor_enable_receiving when netlink doesn't work" [Undecided,New] https://launchpad.net/bugs/581527
<Keybuk> the patch is still wrong
<Keybuk> udev cannot function without the netlink socket
<stgraber> yes, I know that, I just don't think "cannot function" means it should segfault ...
<stgraber> in a VZ environment we don't have any kind of device anyway, so we really don't need udev to work, we just need it to not make the software crash because it segfaults ...
<Keybuk> I'd be happy if your patch made it an assertion error
<stgraber> as I mentioned in the bug report, I really don't know much about udev's code and so don't have a clue about its error codes, so if you know what that function should return when it doesn't get a valid structure as parameter, I'll be happy to change the patch
<Keybuk> if you pass invalid data to functions, that's always a programming error, thus an assertion error
<stgraber> Keybuk: ok, I'm looking at moving it to making an assertion error. Just wondering why it's not the case for all the other functions in that file that simply "return NULL" when udev_monitor is NULL, any idea ?
<Keybuk> no idea, you'd have to talk to upstream
<Keybuk> they may have a different opinion
<cjwatson> Keybuk: so, casey's MoM lock is still held following the reboot a while back - can I remove it so that the cron job proceeds, or are you operating it manually?
<Keybuk> cjwatson: I thought you were operating it ;)
<cjwatson> nope
<jml> hello
<cjwatson> I asked if I could remove the lock a few days ago, but I guess it got lost in UDSery and I didn't see an answer, so I stayed clear but forgot to re-ask on the train or whatever
<cjwatson> Keybuk: I'm going to take that as a yes, and have removed the lock now
<Keybuk> sorry, was on the phone
<Keybuk> yes, it's ok for you to drive :p
<cjwatson> ah ok
<cjwatson> I don't want to drive, I just want to let cron drive. :-)
<cjwatson> .oO( maybe mom should be an upstart service to avoid all this stale lock guff )
<Keybuk> heh
<cjwatson> I suppose that's a sane thing to have in upstart-cron, run once an hour unless it's running already
<cjwatson> though doesn't really cover running it by hand
<Keybuk> indeed
<Keybuk> "start mom"
<JFo> cjwatson, I have a bug that you will probably be interested in: bug 578742
<ubottu> Launchpad bug 578742 in linux "Btrfs device balancing does not work" [Undecided,New] https://launchpad.net/bugs/578742
<JFo> I apologize in advance :-)
<cjwatson> JFo: not too bothered yet, assuming that it can be forwarded upstream and fixed in maverick; at this point, given the lack of userspace support, I only care about problems that would make it difficult for us to implement that support
<cwillu_at_work> JFo, anything less than an rc of 2.6.34 is considered obsolete and basically dangerous to use by #btrfs :p
<JFo> oh indeed
<JFo> my concern is, how to address this with the reporter. Plus my boss (pgraner) told me to punt to cjwatson :-)
<cjwatson> JFo: um, I don't see how it's anything much to do with me.  I have many of the tasks to implement userspace support in maverick, but kernel support for btrfs is not my problem
<JFo> heh
<JFo> no problem
<JFo> my desire is to respond that it is unsupported
<cwillu_at_work> a dkms package + more recent btrfs userspace would make upstream happier with us :p
<JFo> so that is the plan
<cjwatson> JFo: that would be inappropriate
<JFo> and yet, that is what I am told from both sides
<JFo> well *currently* unsupported
<cjwatson> JFo: the correct way to deal with it would be to test whether it's fixed in a more recent release; if it is, it can be closed as Fix Released in maverick; if it isn't, it should be forwarded upstream
<cjwatson> just closing it as "unsupported in lucid" deprives us of a source of problem reports, surely
<cjwatson> it cannot be the case that all possible bugs people might file on lucid's btrfs are automatically fixed in maverick's
<cwillu_at_work> cjwatson, a dkms build of the latest or running 2.6.34 would suffice for that;  upstream thinks it's saner to use a dkms build though
<cjwatson> cwillu_at_work: sure, my point is it should be actually tested before closing it
<cwillu_at_work> fair enough;  a ppa with up-to-date modules would be useful
<cwillu_at_work> there's lots of issues with btrfs in 2.6.32 though, somewhat fewer in 2.6.33;  bug reports from those versions shouldn't be upstreamed until they've been tested with more recent versions imo is all I'm saying
<cjwatson> JFo: to clarify, saying it's unsupported is fine, but not in itself a reason to close the bug since after all we do ship it, and the reason we ship it is to collect early feedback so automatically discarding that feedback is a bit odd
<cjwatson> (I think the fact that people have to go through contortions to get their system to boot with a btrfs / is a fairly clear indication that it's unsupported in lucid)
<cwillu_at_work> JFo, you should mention on that bug that running btrfs on rootfs is actively dangerous;  there's a dpkg bug that isn't fixed in lucid that hurts _really_ bad with btrfs
<cwillu_at_work> /var/lib/dpkg/info corruption specifically
<cwillu_at_work> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=575891
<cjwatson> cwillu_at_work: lies, that's fixed in lucid :)
<ubottu> Debian bug 575891 in dpkg "dpkg makes wrong assumption about readdir() and lose metadata files with btrfs" [Important,Fixed]
<cwillu_at_work> cjwatson, it is?  I missed that commit then :p
<cjwatson> cwillu_at_work: dpkg 1.15.5.6ubuntu4
<cwillu_at_work> ah, goodie
<cwillu_at_work> I've been bind mounting my /boot onto /var/lib/dpkg for a while because of that :)
<cwillu_at_work> in related non-news, I'm trying to get btrfs to build as a dkms module, but I keep tripping on a permission error during dkms build
<cwillu_at_work> ah, got it;  symlinked to the root of the tree instead of fs/btrfs
<lool> stgraber: Hey
<lool> stgraber: I just wanted to tell you your UDS demo was awesome
<popey> ooo yes, I agree lool !
<ScottK> JFo: Bug #496093 looks like it's in need of some serious triage/sorting out how many problems are really in one bug.  It's one of the two bugs the release team is subscribed to that is still getting piles of new comments.
<ubottu> Launchpad bug 496093 in linux "[lucid] rt2860 frequently fails to connect to mixed mode WPA/WPA2 secured wireless networks" [Medium,Triaged] https://launchpad.net/bugs/496093
<JFo> ugh, thanks for the pointer ScottK
<ScottK> JFo: Enjoy.
<ScottK> ;-)
<JFo> heh
<imbrandon> yea i'm actualy bit by that bug on my other laptop ( or a variant of ) [ rt2870 ]
<imbrandon> i was just reading it too
<cjwatson> mdke: could https://help.ubuntu.com/9.10/installation-guide/ be updated to the version in karmic-proposed, which is actually distinct from jaunty?
<cjwatson> or, well, meaningfully distinct in terms of version numbers and such
<akgraner> kenvandine, oops :-(  sorry about that  - did the bliptv title have it that way - I think that is where we pulled the titles from
<kenvandine> :)
 * kenvandine looks
<kenvandine> akgraner, yup... it's wrong there
<kenvandine> akgraner, can you fix it there?
<akgraner> kenvandine, I'll email them.. and let ya know
<akgraner> :-)
<kenvandine> thx :)
<akgraner> kenvandine, popey is going to change it
<akgraner> :-)
<akgraner> kenvandine, I hope you badge was right as they even took pics of the badges :-)
<kenvandine> hehe... it was
<popey> sorry for not spotting that on the day
<akgraner> thanks for catching that
<kenvandine> no worries
<popey> have changed and triggered resync to youtube
<kenvandine> awesome
<shtylman> who would I talk to about getting kde imported into launchpad? (likewise for qt)
<Riddell> shtylman: james_w ?
<Riddell> if you're talking about code
<shtylman> yea... code indeed
<psusi> cjwatson: so you are going to SRU the libparted fix for the 10.04.1 respin? :)
<james_w> hi shtylman
<Riddell> I expect most of our packages do have code branches in launchpad, some like kdebase don't but that should be fixable
<shtylman> james_w: howdy
<cjwatson> psusi: it has my attention now at least
<Riddell> if you're talking about svn imports, that's more complex
<psusi> cjwatson: looks like another user reported it worked for them...
<james_w> shtylman: what can I help you with?
<shtylman> james_w: to bring you up to speed, the current plan is to be able to do qt and kde daily builds when launchpad supports it
<shtylman> james_w: this means that we need to make sure we have all the nessesary kde svn code in launchpad bzr (as I understand it)
<cjwatson> psusi: I'm still catching up after UDS, I don't expect to decide today
<psusi> k
<shtylman> I haven't the first clue on the proper way to import that or layout the bzr branches ... so I seek guidance :)
<Riddell> note that Qt is in Git
<james_w> shtylman: that's correct. I'm not really the person to talk to about that, you want someone on the launchpad-code team.
<james_w> shtylman: there is documentation at https://help.launchpad.net/Code/Imports, and you can find people on #launchpad that should be able to help
<shtylman> james_w: thanks
<james_w> shtylman: let me know if you don't get anywhere
<shtylman> k
<psusi> Keybuk: wait, what's this about udev not creating dev nodes anymore, but devtmpfs instead?  yet another kernel fs to auto create dev nodes?  I thought that was one of the reasons udev was made, to get away from devfs and move the dev node creation to user space?
<Keybuk> that was *last year* :p
<Keybuk> now udev doesn't create device nodes
<pitti> psusi: well, the original objection was about the kernel defining names and permissions, not so much the actual mknod(), AFAIR
<Keybuk> quest scott% cat /etc/issue.net
<psusi> so it's back to a new devfs like kernel fs?  ack...
<Keybuk> Ubuntu 10.04 LTS
<Keybuk> quest scott% mount | grep "on /dev"
<Keybuk> none on /dev type devtmpfs (rw,mode=0755)
<Keybuk> pitti: which is also ironic, since now we make the kernel define the names and don't let you change them in userspace ;-)
<cjwatson> it's not really as much like devfs as all that
<maco> Keybuk: does the kernel just go in cycles about how to handle this stuff?
<pitti> Keybuk: but we still control permissions and symlinks
<Keybuk> pitti: right
<pitti> which the original devfs didn't
<cjwatson> the problems with devfs were (a) it had its own special and unique snowflake naming scheme (b) it introduced a huge pile of new kernel infrastructure just for itself (c) it didn't allow any userspace control at all
<psusi> so wait... you can no longer use a udev rule to persistently name a given disk /dev/sda even if the kernel detects it in a different order?
<cjwatson> devtmpfs doesn't suffer from these problems
<pitti> psusi: you can do arbitrary symlinks, but not rename the "master" node
<Keybuk> psusi: correct, you can only use a udev rule to persistently add a symlink to the disk with the name that is memorable to you
<maco> psusi: yay for UUIDs?
<Keybuk> /dev/porn -> /dev/sdXY  where the XY is whatever it is this boot
<psusi> that seems like a big step backwards?
<pitti> psusi: NB that even without devtmpfs current udev does not support renaming any more :)
<Keybuk> not really
<pitti> but symlinks are really just as good
<Keybuk> allowing renaming of device nodes caused huge numbers of problems and gained nothing
<psusi> it did?
<Keybuk> symlinks work perfectly for "personal names"
<Keybuk> psusi: yes, for example, swap /dev/sda and /dev/sdb atomically ;-)
<psusi> hrm... I suppose
<psusi> why need to do it atomically?  just have udev create them with the correct name in the first place
<Keybuk> and there's benefit to having a "master node" whose name matches the standard at all times
<Keybuk> and whose name matches the sysfs object too
<Keybuk> renaming sda to sdb would not rename /sys/devices/.../sd
<Keybuk> renaming sda to sdb would not rename /sys/devices/.../sda
<psusi> hrm... true... I have been getting annoyed lately running that script to parse the ureadahead output and it gets confused because the kernel name listed is dm-5,  but there is no /dev/dm-5
<Keybuk> see, Symlinks 1 - Renames 0
<Keybuk> ;P
<psusi> good point ;)
<psusi> now... I still see an issue with the naming of dm nodes
<Keybuk> we're hoping that the devmapper kernel-side will start putting NAME= into its uevents
<Keybuk> err, DEVNAME= sorry
<psusi> if the native kernel name is dm-1 for the partition on dm-0... does that mean that devtmpfs will create dm-1, then udev will see that it is a partition and make a link for dm-0p1 to point to it?
<Keybuk> if that's the desired behaviour, that makes sense
<Keybuk> dm0
<Keybuk> dm1 -> dm0p1
<Keybuk> dm2 -> dm0p2
<Keybuk> dm3
<Keybuk> dm4 -> dm3p1
<Keybuk> doesn't seem terrible
<Keybuk> except I got my arrows the wrong way around :)
<psusi> personally I don't like the p in there, but can live with it... but really it seems cumbersome to map dm-1 to dm-0p1 rather than just partition dm-0... seems the kernel side really needs to just support partitions like md now does
<Keybuk> that would be better, I agree
<Keybuk> biab
<pitti> why am I suddenly spammed with millions of merge proposals? is that just me?
<james_w> pitti: I think it might be due to being in ~techboard. Does the mail say why?
<pitti> not really
<pitti> james_w: but I've been in TB for a long time, and this only started this week
<pitti> or perhaps last week with a new LP rollout, and I just ignored them
<james_w> pitti: ah, rollout
<james_w> LP now sends mail on merge proposals via teams, it used to just be direct subscriptions
<james_w> I've been trying for ages to restructure things so that ubuntu-dev would catch merge proposal mail, but it's slow going
<james_w> I'll go ping the losas
<pitti> james_w: thanks
<cr3> is there a way to have network interfaces consistently appear as eth0, eth1, etc. based on mac address?
<jpds> cr3: Yes.
<cjwatson> cr3: /etc/udev/rules.d/70-persistent-net.rules
<cr3> cjwatson: awesome! has this been around for long?
<cjwatson> quite a few releases, yes
<cjwatson> definitely at least hardy but I think rather longer
<bigcx2> hey all
<bigcx2> not sure if this is the proper outlet for this
<bigcx2> but
<bigcx2> does anybody know how to create a keyboard binding/shortcut without X running?
<bigcx2> like in a virtual console?
<arand> bigcx2: It's #ubuntu for support.
<bigcx2> arand: figured, didn't really feel like my message getting lost in the 1600+ people trying to get support in there
<cr3> what's the file under /proc, I think, which can be used to reset the buffer cache?
<cjwatson> cr3: /proc/sys/vm/drop_caches
<cr3> I think it's /proc/sys/vm/drop_caches, I wonder if I simply need to echo 0 in there... trying it out...
<pochu> cr3: yes
<ion> proc(5). echo 3.
<cr3> pochu: I was running top which showed something like: 84456k buffers. after running echo 0 | sudo tee -a /proc/sys/vm/drop_caches, the value didn't change significantly
<cr3> ion: awesome, thanks!
<psusi> echo 1 drops file cache, 2 drops dentry cache, 3 drops both
<apw> can anyone tell me how the 'Supported:' information gets into apt-cache showpkg output?
<cjwatson> apw: talk to mvo
<slangasek> apw: and as of last week, there's a bug that shows all -updates packages as 'unsupported'
<apw> slangasek, ahh i have new kernel packages with no line at all, likely related
<bdrung> nxvl:
<bdrung> ping
<Damascene> I couldn't find solang in ubuntu repo
<Damascene> it should be there so one can test it
<bdrung> Damascene: it was removed in debian and in ubuntu afterwards
<Damascene> do you know why?
<kklimonda> Damascene: it got removed from lucid due to buggy nature and depending on deprecated libraries. no one has stepped in to help with updating it (neither then nor now). it also got removed from debian (probably the same reason)
<Damascene> because some one thought it is a port of f-spot?
<bdrung> kklimonda: i saw one bug report with an updated package
<kklimonda> Damascene: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=547506
<ubottu> Debian bug 547506 in ftp.debian.org "RM: solang -- ROM; buggy, depends on deprecated libraries" [Normal,Open]
<bdrung> https://launchpad.net/bugs/512097
<ubottu> Ubuntu bug 512097 in solang "[needs-packaging] Solang 0.4.1" [Wishlist,New]
<Damascene> I see
<Damascene> thanks
<Damascene> mlterm is now in version 3. it will be included in the next release or some on should ask for that?
<kklimonda> solang 0.4 has one interesting feature - they have replaced their database with the tracker backend
<kklimonda> on the other hand shotwell is written in Vala - also nice interesting technology.. choice, choices ;)
<kklimonda> Damascene: what has been decided at UDS?
<nxvl> bdrung: pong
<Damascene> kklimonda, I don't know
<Damascene> who knows?
<Damascene> nxvl, how come no one knows about keyrx
<bdrung> nxvl: bug #581167 - should i remove "(Canonical)" from your name? a complaining gpg is a configuration problem.
<ubottu> Launchpad bug 581167 in openssl "Please merge openssl 0.9.8n-1 into ubuntu" [Undecided,Confirmed] https://launchpad.net/bugs/581167
<bdrung> nxvl: the .pc directory came from the debian branch and it's probably a bug of the importer
<nxvl> bdrung: if you want to, the problem is that my gpg key is exactly like that, if not present it won't recognize my gpg key, but since i'm not signing + uploading, i don't really mind
<nxvl> bdrung: i just have it like this in my DEBFULLNAME for when i do universe
<bdrung> nxvl: most commands allow to set the key (i set DEBSIGN_KEYID in /etc/devscripts.conf)
<nxvl> huh
<nxvl> interesting
<nxvl> will take a look at that then
<nxvl> :D
<nxvl> thanks for the tip
<kklimonda> Damascene: I think it was dpm who has asked you to raise this issue at the UDS and he may be a good person to ask anyway
<bdrung> i have two keys and want to force the correct one (and it's easier for sponsoring)
<nxvl> Damascene: about what?
<Damascene> nxvl, about the ubuntu should provide update packages bug
<nxvl> ohh
<Damascene> seem like keryx do the job
<Damascene> it should get some support form ubuntu
<nxvl> Damascene: will take a look at it later
<Damascene> ok
<nxvl> Damascene: ohh, gui, i'm not maintaining that
<nxvl> Damascene: ping mvo about this
<Damascene> ok
<bdrung> nxvl: configure changes the patched Makefile?
<Damascene> Bug 572776
<ubottu> Launchpad bug 572776 in ubuntu "Ubuntu should provide update packages for download and use for offline users" [Undecided,New] https://launchpad.net/bugs/572776
<Damascene> just for reference
<nxvl> bdrung: not as far as i remember, or we patched that aswell
<nxvl> mdeslaur: ^^
<nxvl> mdeslaur: is about openssl
<bdrung> nxvl: "Those can't be striped out, please see changelog entry for 0.9.8k-7ubuntu2 and 0.9.8k-7ubuntu3 for more information"
<mdeslaur> bdrung: hmm...the pc directory was present because the patches are currently _applied_ in the source tree
<bdrung> nxvl: Configure and util/perlpath.pl are modified directly. so there should be no problem in putting these changes into patches.
<nxvl> bdrung: actually, is source format 3.0, so those are quilt patches anyway
<nxvl> let me find the wiki
<bdrung> nxvl: yes, but i want to avoid debian/patches/debian-changes-0.9.8n-1ubuntu1
<nxvl> bdrung: configure was an issue too, because it didn't clean or something, mdeslaur knows more about the issue since he fixed it last time
<nxvl> an please get in touch with him since he had some plans for this upload aswell, or something
<bdrung> mdeslaur: ping
<mdeslaur> bdrung: yeah
<bdrung> mdeslaur: i was talking with nxvl about openssl
<mdeslaur> bdrung: are you reviewing it?
<bdrung> mdeslaur: the new package has "direct" changes and are put into debian/patches/debian-changes-0.9.8n-1ubuntu1 due to dpkg-source 3.0 (quilt).
<bdrung> mdeslaur: yes
<mdeslaur> hmm...I'm not sure how that will work with source 3.0
<bdrung> it would be nice to have debian-changes-0.9.8n-1ubuntu1 reverted back to proper patches
<mdeslaur> bdrung: maybe the FTBFS issue is resolved now that the package has been migrated to 3.0
<bdrung> it should work with 3.0
<mdeslaur> bdrung: someone will need to test it with proper patches to see if it will build on all archs
<bdrung> mdeslaur: it's just an issue of building twice
<mdeslaur> bdrung: right, the patches wouldn't un-apply cleanly before, so the build would fail
<bdrung> yes, but 3.0 (quilt) does not unapply the patch
<bdrung> Damascene: i use apt-mirror to mirror the complete archive. then i transport this on an hdd to the networkless computer
<Damascene> do you want some one to download the whole ubutnu repo?
<bdrung> Damascene: i must admit that this is an overkill for just having the updates ;)
<Damascene> keryx seems fine but I've not tested it yet
<Damascene> I mean not so much testing
<Damascene> but having the packages from ubuntu would be fine too
<bdrung> nxvl: the package has many lintian error and warnings
<nxvl> ok, just unsubscribe -sponsors and i will take a closer look after work
<nxvl> and please add that infor to the bug report
<nxvl> i assume plane-merging isn't as good as it sounded :P
<bdrung> nxvl: i think it's better to work with debian to resolve the lintian errors
<bdrung> nxvl: the clean target isn't clean
<nxvl> mdeslaur, kees, jdstrand: next cicle i won't touch openssl, enough headache for 2 releases!
<nxvl> :D
<micahg> should the libgs8 patch be taking an extra 1.5MB?
<Daenyth> Will pbuilder run easily on a non-ubuntu host?
<Daenyth> Right not I build in an ubuntu vm on arch linux host, but that's rather slow. chroot would be much nicer
<Daenyth> is that easily set up?
<pochu> !pbuilder | Daenyth
<ubottu> Daenyth: pbuilder is a system to easily build packages in a clean chroot environment. To get started with PBuilder, see http://wiki.ubuntu.com/PbuilderHowto
<Daenyth> pochu: those instructions assume you are running on ubuntu
<pochu> Daenyth: what's your host?
<Daenyth> arch linux
<pochu> it works. I dunno about arch linux instructions or success stories there though
<Daenyth> I mean, if it's been known to work on at least *some* non-ubuntu systems, I can wing it from there
<Daenyth> I just wanted to know if pbuilder will break if not run on ubuntu
<Daenyth> I can't imagine it needs to know *that* much about the host system...
<ScottK> It will run on Debian.  Not sure about anywhere else.
<joaopinto> there were some pbuilder packages on arch, check google :P
<Daenyth> I'll look into that
<joaopinto> there is debootstrap, according to google
<Daenyth> well yeah
<joaopinto> chroot/debootstrap should be sufficient to install a debian base system
<Daenyth> hrm
<Daenyth> yes true
<cwillu_at_work> joaopinto, debootstrap has a specific target for pbuilder in fact :p
<smoser> can someone clarify ?
<smoser> grub 1.98-1ubuntu6 is grub 2
<smoser> right?
<ScottK> smoser: It is.
<smoser> yeah, i see that now 'apt-cache show grub2 | grep Version'
<smoser> just confusing. thanks though.
<shtylman> anyone have any git-buildpackage experience? ... is it possible to build without cleaning? it seems to want to clean all the time
<shtylman> does bzr buildpackage have a noclean mode?
<slangasek> shtylman: bzr-buildpackage doesn't clean, it just exports (which will ignore files in the working directory that bzr doesn't know about).  If you want to skip the redundant clean afterwards, you would run 'bzr bd -- -nc'
<slangasek> (to tell debuild not to call debian/rules clean)
<shtylman> slangasek: thanks
 * ScottK gives kees a hug.
<shtylman> if I have a project that builds with scons... is there something (env var or whatnot) that I can put in the debian/rules file to basically pass the -j flag onto scons when dpkg-buildpackage runs it?
<xnox> shtylman, dh supports scons
<xnox> %:
<xnox>        dh --parallel $@
<shtylman> um... I don't follow :/
<xnox> this will pass -j flag to scons configure / build if DEB_BUILD_OPTIONS=parallel=X
<xnox> is set
<shtylman> sorry for my newbieness :)
<xnox> shtylman, read
<xnox> $ man debhelper
<xnox> $ man dh_auto_configure
<shtylman> k
<xnox> $ man dh_auto_build
<xnox> =)
 * shtylman goes to read
<micahg> tkamppeter: should the libgs8 update take an extra 1.5MB?
<tkamppeter> micahg, which libgs8 update? The recent SRU?
<micahg> tkamppeter: yes
<shtylman> xnox: were you implying that it would automatically pass that to the build system? or that I need to make sure the rules file must have something special beyond running scons in the build-stamp target (which is what happens right now)
<xnox> shtylman, dh $@ will automagically handle parallel, strip, optimize options for you. Beyond the two line snippet you shouldn't need anything else =)
<shtylman> xnox: gotcha... but from my memory of makefiles %: is a catch all ... why would I want to use that specifically?
<shtylman> right now, the rules file has a build target that calls scons itself
<shtylman> is that wrong?
<xnox> shtylman, you can do that =)
<ScottK> It's not wrong, but it may make it harder than it has to be.
<xnox> and yes %: is catch all
<xnox> but that's the beauty of it
<xnox> read
<xnox> $ man dh
<shtylman> heh
<xnox> dh build
<shtylman> I think my rules file is not including debhelper... which is part of the problem :)
<xnox> runs configure, build, test (with policy complaint options for most of buildsystems)
<xnox> dh binary (makes sure the software is build installed and all dh_* scripts are run in correct order)
<xnox> dh clean (does buildsystem clean and cleans all stamps & etc)
<tkamppeter> micahg, this is strange, the patch cannot generate another 1.5MB of code. Perhaps a build server problem.
<micahg> tkamppeter: .deb files seem to be the same size
<xnox> shtylman, bzr branch lp:~dmitrij.ledkov/+junk/dh-style
<xnox> shtylman, this branch has presentation about dh & 5 samples on how to use it =)
<shtylman> xnox: nice :)
<tkamppeter> micahg, where is the difference then? The /usr/lib/libgs.so.8.71 file?
<micahg> tkamppeter: I'm pulling them down now to check
<micahg> tkamppeter: yes, I'll pastebin
<micahg> tkamppeter: http://pastebin.com/eLvvw7Sr
<micahg> tkamppeter: BTW, I'm on amd64
<tkamppeter> micahg, unfortunately, I cannot help here, best is you ask a gcc expert.
<micahg> tkamppeter: k, thanks
<joaopinto> anyone experienced in converting OSS to PA client applications ?
<pochu> joaopinto: maybe ask on #pulseaudio ?
<joaopinto> good point :P
#ubuntu-devel 2010-05-18
<what_if> Need a bit of help getting started... want to work on the "system restore/rollback functionality" requests in ubuntu brainstorm. Where do I start? Where is code hosted, etc.
<kklimonda> well, all code is store on launchpad
<kees> ScottK: heh, thanks.
<crimsun> some people just don't get it, eh?
<psusi> anyone around know initramfs-tools well?  I'd like to interface with it to create an alternate initramfs that has defrag built into it to perform boot time defrag of the root fs
<nxvl> does anyknow knows how to create a patch with dpkgsrc 3.0?
<RAOF> nxvl: You mean 3.0 (quilt)?
<psusi> doesn't that just mean it uses quilt?
<nxvl> yup
<nxvl> psusi: oh no, it does a lot of fancy stuff
<psusi> export QUILT_PATCHES=debian/patches ; quilt new my-patch ; quilt add somefile ; edit somefile ; quilt refresh
<RAOF> Yeah.  It's actually just quilt.
<psusi> and you might want to quilt push -a before the new if you want your patch to be applied after all the existing ones
<arand> If I want to debug fsck failing with an error when user cancels the check, what would I do? Is this backtrace useless?: http://pastebin.com/MZkMc1UN (I lack all kinds of gdb-foo).
<psusi> what's to debug?  if they canceled the check, that is an error
<nxvl> oh, ok thanks!
<arand> psusi: So "fsck.ext4: Inode bitmap not loaded while setting block group checksum info" exit code 8. Is correct behaviour for fsck on user cancelling the check?
<psusi> arand, no, that's fsck finding an error with the fs, not being canceled
<psusi> wait, no...
<arand> psusi: But there are no errors in the filesystem, if fsck runs through okay.
<arand> Error is _only_ seen when it is cancelled.
<psusi> sounds like an assertion failure triggered by the sigint... search the code for that string
<psusi> sounds like the canceling tries to do some cleanup in the SIGINT handler, and part of that cleanup is trying to write out the inode allocation bitmap, which an assertion check makes sure is actually loaded first and it isn't
<psusi> it may not be loaded either because it has not been loaded yet at the time of the SIGINT, or because that block group's inode allocation bitmap is uninitialized
<shtylman> ccheney: there is no UbuntuLucid config in go-oo trunk... is that normal? what do you use to build?
<arand> psusi: https://bugs.edge.launchpad.net/bugs/582035 is the bug, I think at least 80% of what you're saying is over my head :/ So please put a comment if you've got some good theories :)
<ubottu> Ubuntu bug 582035 in e2fsprogs "User cancel of fsck gives: "fsck.ext4: Inode bitmap not loaded while setting block group checksum"" [Undecided,Confirmed]
<psusi> arand, first thing I'd do is search the source code for the string "Inode bitmap not loaded while"
<arand> psusi: I'm on it.
<psusi> arand, my guess is you will find an assert() with that string in it and that assertion is failing because of a race condition in which the inode allocation bitmap is not loaded yet, but should be eventually... and that could be a little tricky to fix
<psusi> but I have a feeling that probably it is not loaded because that block group's inode table is uninitialized in the first place.. meaning there are no inodes used in that block group so the allocation table is not actually valid and a flag says it is unused, assume it's all empty
<psusi> fixing that should be as simple as putting in a check for the uninitialized flag in the code trying to flush the allocation bitmap and bail out of it is set
<arand> psusi: I feel like I should probably take the backlog here and paste it to the bug or something, because I have absolutely zero knowledge when it comes to FSs... Here's what I dug up in the source (again, I have no idea what is relevant...): http://pastebin.ubuntu.com/435281/
<ccheney> shtylman: ah i hadn't synced up trunk yet from 3-2 branch
<psusi> arand, good time to learn ;)
<arand> Hmm, if only things were that simple... :)
<arand> psusi: Hmm, well staring at this code gives me nothing.. :(   Would you mind (and do you think it would be useful?), if I pasted the backlog of our talk here to the bug?
<psusi> I don't mind, no... and sure it could be useful
<arand> Ok, will do then.
<TheMuso> crimsun: Do you know why we have ac97 related patches in alsa-driver even though they don't get applied?
<Chipzz>  ~.
<crimsun> TheMuso: which, the via ones?
<crimsun> TheMuso: add_onda_a69g_ac97_support.patch was backported from upstream, so it isn't applied in lucid's. add_suspend_quirk_hp_nc6220_nw8240.patch and refix_lp_68659_by_disabling_dxs_for_0x1458a002.patch are both mine and need to be pushed.
<TheMuso> crimsun: Right, I worked it out.
<TheMuso> crimsun: thanks
<loneowais> hey everyone... does anyone know how to get my appindicator into the messaging menu?... Python-Api ?
<dholbach> good morning
<pitti> Good morning
<loneowais> Is storing passwords in dekstopcouch ok?... can i encrypt them? how?
<RAOF> loneowais: You probably want gnome-keyring, which does a bunch of heavy lifting to make password storing work well.
<loneowais> RAOF: that's what i thought.. but couch syncs with ubutnu-one
<RAOF> loneowais: So a solution would be to make gnome-keyring store the keyring in desktopcouch :)
<loneowais> RAOF: that would be nice...for all the ubuntu apps
<loneowais> :-)
<RAOF> loneowais: It *would* be nice to have all my passwords sync'd across to all my computers, but not in a way that stores them in plaintext on a internet server!
<loneowais> RAOF: right.
<tjaalton> tkamppeter_: hi, I've got the symptoms of bug 420490 but due to just restarting the cups server
<ubottu> Launchpad bug 420490 in cups "CUPS update from 1.3.x to 1.4.x: Cache gets corrupted and leads to error 'client-error-document-format-not-supported'" [Undecided,Fix released] https://launchpad.net/bugs/420490
<tjaalton> so no upgrades in between
<tjaalton> need to remove /var/cache/cups/*.ipp and restart it to make printing work again
<tjaalton> and this is only on lucid, the same ppd/queues work fine on hardy/jaunty
<mdke> cjohnston: sure
<mdke> cjohnston: sorry, wrong nick
<mdke> cjwatson: sure
<jussi> poor cjohnston...
<[Crono]> hi all
<[Crono]> good morning
<coz_> hey guys... for several years now ubuntu has this bug that when booting  it drops to busybox  because of my scsi drives.. and many of the bug reports I have seen  give a  solution  of add a rediculous rootdelay-40 to grub... << on lucid I can drop that to rootdelay=35...is there possibly any other solution?  this does not happen with any other distribution
<pitti> cody-somerville, mr_pouit, cjwatson: how does xubuntu manage to install the non-preferred gdm dependencies (xfce4-session and xfwm4) first, before gdm pulls it in? the seed order doesn't seem to make any difference?
<pitti> "pulls it in" -> "pulls in half of GNOME
<hyperair> persia: could you add me to ubutnu-sponsors please?
<hyperair> ubuntu*
<persia> hyperair: Sure.
<hyperair> persia: thanks.
<pecisk> hi people, does i386 version of netbook edition has same fallback mechanism when dealing with non-accelerated graphics using Enlightment libs?
<RAOF> pecisk: Yes
<pecisk> RAOF, great, thanks for answer :)
<dholbach> persia: should https://wiki.ubuntu.com/UbuntuDevelopers and https://wiki.ubuntu.com/DeveloperMembershipBoard/ApplicationProcess list package sets?
<dholbach> I think they should to avoid confusion
<persia> dholbach: Probably.  More generally, they likely need a revamp to reflect the practices developed over the past few months, rather than the initial ideas.
<dholbach> good
<persia> dholbach: Where it gets tricky is that some packagesets aren't defined in very clear terms.
<dholbach> still should the use-case for developers be pretty simple: take a look at the list, decide which upload rights you need, apply for them :)
<persia> Or rather, not defined in easily-discoverable terms.
<dholbach> right
<persia> I think that's entirely the wrong use-case.
<jml> james_w, were notes taken for "Review and Planning for Distributed Development"? I can't find the gobby doc.
<persia> I think that someone ought work with some team(s), and have the team suggest that the person join that development team.
<persia> anyone just randomly looking at the list is very likely to be disappointed with the decision of the board.
<dholbach> persia: that somebody needs upload rights for a certain set of packages does not mean that they didn't work with that team
<dholbach> but anyway, we're splitting hairs
<dholbach> I just wanted to write a blog post about which permissions reorg changes have been implemented and noticed it wasn't mentioned as clearly as I thought
<persia> It's all implemented, but the documentation is a bit spotty, in part because the various social definitions haven't been finalised.
<dholbach> ok
<cjwatson> pitti: we normally install by task
<persia> For the short-term, it's probably best to indicate that folks ought know what sort of upload rights they want: if it's in a (short) list, they ought talk with the developers concerned.  if not, they ought talk to the DMB, who may be able to arrange that they can do what they need.
<pitti> cjwatson: ah, and there the seed order matters?
<cjwatson> pitti: seed order itself should not matter, but germinate "plants" anything that is explicitly seeded before trying to resolve broken dependencies
<pitti> cjwatson: ah, thanks
<cjwatson> once you get down into resolving dependencies, it's (IIRC) depth-first, but the very top level is more like breadth-first
<james_w> jml: there were notes
<jml> james_w: where can I find them?
<james_w> weren't some gobby documents lost though?
<jml> james_w: that's what I heard. all of the other gobby docs that I care about managed to survive though.
<james_w> jml: I can't see it either
 * jml checks IRC logs...
<jml> frustratingly, the gobby doc name isn't mentioned.
<dholbach> mako, mdke: are you guys going to be in the CC meeting in 10m?
<jml> james_w: I've just put a note on the whiteboard for the spec calling for notes. Anything else I should do?
<cjwatson> gobby is supposed to be backed by bzr on the server side; ask IS if they can hunt around
<jml> cjwatson: wil do. thanks.
<pitti> does anyone know what actually uses /usr/share/i18n/charmaps/* ?
<cjwatson> pitti: localedef
<pitti> cjwatson: ah, thanks
<soren> Do we really use anything other than UTF-8 in there by default?
<pitti> soren: not by default
<pitti> soren: but the charmaps compress nicely into 3.1 MB, so I'd like to teach localedef to get along with gzipped ones
<soren> That's an easy 14 MB save on a minimal install.
<soren> pitti: Ah, yeah, that's good too.
<Riddell> lamont: how come you didn't use a -0ubuntu1 version number for gcc-opt?
<lamont> Riddell: prolly because I didn't upload it to debian
<lamont> then again, it was more of a dump-n-run than anything I care to ever support again
<lamont> dead upstream, there are parts of ubuntu that may choose to use that as a start of an idea for something, but otherwise, I expect that to be the last upload of gcc-opt ever
<Riddell> you're not selling it to me :)
<lamont> cjwatson asked me to put it somewhere.  universe was the decided target....
<Riddell> accepted
<lamont> ta
<cjwatson> cking,NCommander,superm1: I don't suppose any of you have notes from foundations-m-btrfs-support?
<cjwatson> (or anyone else)
<cjwatson> oubiwann_: ^-
<NCommander> cjwatson: don't think so :-/
<jml> oubiwann_, hello. I just discovered the gobby doc for https://blueprints.edge.launchpad.net/ubuntu/+spec/foundations-m-cycle-review
<jml> oubiwann_, in the "Lessons learned" section, there's "launchpad bugs situation really needs to be addressed for Foundations"
<jml> but no more information.
<cjwatson> jml: I think where that's coming from is that some of our team are drowning in bugmail to the extent that they find it difficult to get actual work done
<cjwatson> I don't think it's specifically Foundations though
<jml> cjwatson, tbh, I didn't get many other people complaining about too much email.
<jml> cjwatson, but there are many other possible reasons for that
<cjwatson> Keybuk in particular had this problem towards the end of the cycle
<cody-somerville> cjwatson, do you have any plans to merge base-installer any time soon?
<cjwatson> cody-somerville: at some point in the merge window, sure
<jml> cjwatson, thanks.
<jml> cjwatson, the bugs team is working on improving the too much email situation -- I'll make sure that we talk to Keybuk as a part of that.
<cjwatson> thanks
<jml> cjwatson, was there anything else LP-related in the 10.04 review session?
<cking> cjwatson, no notes from foundations-m-btrfs-support :-(
<cody-somerville> cjwatson, live-installer in debian has made a change thats dependent on a newer version of base-installer (ie. adding a new waypoint for a script in newer base-installer). I was thinking of removing the waypoint and modifying the dependency to require a version less then the version of base-installer the change occurred in so that re-adding the waypoint won't be forgotten about. Does this sound sane to you?
<cjwatson> jml: I don't have it paged in at the moment, but if I think of anything I'll let you know ... most of the discussion wasn't about LP though
<cjwatson> cking: thanks anyway
<jml> cjwatson, thanks.
<cjwatson> cody-somerville: not really, why not just be a little bit patient?  I'll be merging base-installer in the not too distant future
<cody-somerville> cjwatson, because I already merged live-installer and so it currently does not work. Frans Pop didn't modify the deps to indicate the newer version of base-installer was needed.
<cjwatson> cody-somerville: *shrug* the merge cycle is always like this.  please don't create more work by working around it
<cjwatson> better to simply wait; it won't be that long
<cody-somerville> cjwatson, patching live-installer's deps to say it requires the newer base-installer would be correct though, eh?
<cjwatson> cody-somerville: we don't usually bother that much with versioned dependencies in d-i, since nothing processes them at run-time
<cjwatson> their only practical use is to control transitions to Debian testing
<cjwatson> so they'll often get removed after a period of time to reduce size
<cjwatson> honestly, I wouldn't bother if I were you
<cody-somerville> alright. thanks for the advice. I appreciate it. :)
<mathiaz> seb128: hi!
<mathiaz> seb128: what is ~/.gconfd/saved_state used for?
<chrisccoulson> mathiaz, that file logs listeners, so that they can be restored if gconfd restarts
<mathiaz> chrisccoulson: ok - so there is no point in putting this file under version control
<chrisccoulson> mathiaz, no, i wouldn't bother doing that
<mathiaz> chrisccoulson: great - thanks!
<jcastro> whom do I talk to about making sure a package is blacklisted from being merged from debian?
<james_w> jcastro: you can file a bug and subscribe ubuntu-archive
<jcastro> ok
<james_w> it won't prevent it, but stop it being listed by merges.ubuntu.com and the like
<jcastro> james_w: on the specific package?
<james_w> yeah
<bladernr_> Hey, I have a question... how difficult would it be to get a couple more sample files included in /usr/share/example-content?
<bladernr_> I see most standard doctypes included as samples, but no pdfs
<kklimonda> bladernr_: we are limited by the amount of the free space on live cd
<cjwatson> including extra small files wouldn't be much of an issue
<bladernr_> cjwatson:  I was just thinking about including a .pdf, seems that directory has pretty much all common doc types, except for pdf
<xnox> If my merge proposal is marked "Needs Fixing" should I just push new revision & comment that I've fixed the issues. Or shall I click "resubmit" merge proposal?
<bladernr_> right now, we're discussing (in QA) just including sample files inside the checkbox package instead, I was just interested in using example-content since it's already there, so no need to duplicate data
<cjwatson> file a bug report, and discuss with whoever uploaded it last :)
<james_w> xnox: if it's a small change then just comment and change it to "Needs Review". If you took a completely different approach then you can "Resubmit".
<xnox> ok thanks james_w
<pitti> Riddell: ah, you're doing syncs ATM?
<Riddell> pitti: I am yes
<pitti> kees, jdstrand: I prepared new psql packages for all stables and set up bug 582299 to track the progress; should I do anything further now?
<ubottu> Launchpad bug 582299 in jaunty-backports "New upstream microreleases: 8.4.4, 8.3.11, 8.1.21" [Undecided,In progress] https://launchpad.net/bugs/582299
<kees> pitti: if it's related to security, we'd need the debdiffs for us to upload.
<pitti> kees: oh, not just the source packages?
<pitti> kees: I put them all (including source.changes) to my people page
<pitti> kees: it's a new orig.tar.gz, so if you want I can put an interdiff there?
<kees> pitti: ah, yes, if you've got everything with source.changes, we can use that.
<kees> no need for interdiff
<pitti> kees: yep, all tested in their respective chroots, etc.
<kees> excellent
<pitti> kees: but I don't think I am actually allowed to upload to security-proposed, am I?
<persia> pitti: I can't find the relevant wiki page just now, but somewhere around feisty, nomenclature was introduced to derivatives distinguishing "flavours", "remixes", and "derivatives": the first being entirely built as part of Ubuntu, the second being small unofficial changes or modifications (often used for LoCo releases, etc.), and the third being projects like Mint.  There's some fairly precise restrictions imposed on the level of variation to
<persia>  qualify for each name.  If you are very curious, I'll try harder to find the wiki page tomorrow.
<Keybuk> popey: videos from UDS are still being encoded and going up, right?
<pitti> persia: ah, thanks for the heads-up!
<pitti> persia: makes sense indeed
<popey> Keybuk: i have requested some as the video crew didnt have time to do them all, asked if we could crowdsource the editing etc
<Keybuk> popey: ah, I see; so there was a cut-off whereby if they didn't get it encoded during UDS, they didn't do it at all?
<popey> i think so, yes
<popey> elmo was the interface to the video people
<elmo> no
<persia> Note also there are official flavours (e.g. xubuntu) and unofficial flavours (e.g. sabily): the difference being that we're all supposed to care if we break the official ones (although it's nice to not break the unofficial ones)
<slangasek> pitti, persia: right; I'm not sure if I ever read the wiki page, but I've intuitively tried to avoid referring to flavors as "derivatives" because the term implies they're secondary to Ubuntu desktop
<elmo> what happened was, we asked the team leads to pick "the same number of sessions as Dallas" as that's what was budgeted for, and they helpfully picked 2x that amount
<elmo> the as-yet-unedited stuff is being edited atm, and will go up when we get it.  we'll likely stop at the original 20-30 limit though, and if you guys want to 'crowdsource' the rest, that's obviously up to you
<Keybuk> is there a way to know which sessions will be done and which won't?
<Keybuk> just curious myself; i've found watching the videos back of my discussions very useful, especially in the wake of gobbygate
<Keybuk> (not to mention very unnerving, my voice is much squeakier in real life than it sounds in my head - and apparently I can't stop moving)
<elmo> Keybuk: i'm meant to be getting a list, I'll check on that
<Chipzz> Keybuk: I got the same issue with my voice
<Keybuk> elmo: thanks
<popey> thanks for clarifying elmo
<superm1> cjwatson, , sorry, no i don't.
<kees> pitti: no, so really that bug needs ubuntu-security-sponsors sub'd to it.  I'll do that.
<cyphermox> is it just me or now the trick of init=/bin/sh passed to the kernel no longer works for going straight to a shell? right now all I get is a system that stops after 'running /scripts/init-bottom'. what would be the new way of doing this?
<joaopinto> cyphermox, it works for me on lucid, using /sbin/sulogin
<cyphermox> ah, thanks, didn't think of that
<dmart> kees: hi, were you just editing arm-m-missing-security-features?  I think some of our changes may have crossed over...
<kees> dmart: I was, yes.  sorry if I clobbered something...
 * kees checks
<kees> dmart: hrm, I can't find a whiteboard history.  what changes did you make?
<kees> dmart: ah-ha, I see it in email now...
<dmart> kees: I think you undeleted some stuff on the whiteboard (it's duplicated on the wiki), and refined some of the actions.  I had a couple of actions, but they disappeared
<dmart> (not that I mind my actions disappearing ;))
<kees> dmart: hehe, no problem; I've extracted them from the email I just got on the update.
<kees> dmart: how does it look now?
 * dmart looks...
<dmart> That looks OK.  I added the ": TODO" for each
<kees> dmart: ah, yes.  thanks!
<dmart> Should we include testing here too?  The spec template mentions test cases, and the sensible thing is probably for each assignee to come up with appropriate tests to make sure their features are working.
<dmart> Probably x86 already has tests we can reuse for most of these.
<kees> dmart: we can include it, but it's really "done" already.  I have a full test suite for each of those features.
<kees> dmart: it's just a matter of removing the "if armel, XFAIL" checks.
<dmart> OK, great :)  I'll tweak the wiki to indicate this
<kees> dmart: cool.  I'll add a todo for me to adjust and run the testsuite
<dmart> ok, sounds good
<dmart> thanks
<YokoZar> How do files installed into /usr/lib/python2.6/dist-packages end up there?  It looks like the packages say to install to /usr/lib/python2.6/site-packages
<RoAk> YokoZar, python 2.6 has to install in dist-packages and not in site-packages
<YokoZar> RoAk: that makes sense, but I dont' get how the packages are being moved.  Is it a maintainer script somewhere?  Eg: dpkg -S /usr/lib/python2.6/dist-packages/AptUrl  returns unknown, and looking at the apturl-common package it's supposed to install into /usr/lib/python2.6/site-packages
<RoAk> YokoZar, I guess either python-central or python-support is doing that
<RoAk> YokoZar, man dh_pycentral explains it
<YokoZar> RoAk: thank you!
<RoAk> np :)
<smoser> looking for some help regarding debian/watch / uscan
<smoser> at http://s3.amazonaws.com/ec2-downloads/ i want to watch for ec2-ami-tools-\d+\.\d+\-\d+.zip
<smoser> but since there is no html to parse, i'm lost for how to tell uscan that
<ccheney> smoser: perhaps email the devscripts devel team (see packages.qa.d.o) they might have to extend uscan to work with xml if it doesn't already work
<smoser> yeah.. i'd guess its a big edge case
<Pici> 50
<ccheney> smoser: if its standard anyway, i'm not sure how xml pages like that are intended to work
<smoser> yeah, i dont think there is any standard there.
<smoser> realistically, they announce it somewhere else. they just dont
<mdeslaur> mvo: I've added you to tasks in security-m-support-status and security-m-easier-security-updates blueprints. Feel free to reassign/complain/etc... :)
<mdeslaur> seb128: I have some work items that I need to assign to someone...see the security-m-authentication-spoofing blueprint. Do you know who I should assign them to?
<ccheney> smoser: i'm not sure but debian/rules get-orig-source may be what you want instead
<ccheney> smoser: you can do anything you need inside that to grab the source, but its not uscan :-\
<smoser> ccheney, thanks. i'll take a look.  i'm really hoping for the benefits of a watch file
<seb128> mdeslaur, which items are those?
<smoser> more than just downloading the original source , but i was unaware of get-orig-source rule
<mdeslaur> seb128: it's to add the aboutme picture to the policykit and gksu password dialogs, and to make sure a random picture gets selected when a new user is created.
<seb128> hum, patches are welcome? ;-)
<seb128> mdeslaur, you want those to be assigned to somebody in the desktop team rather?
<mdeslaur> seb128: uhm...yes? :)
<seb128> mdeslaur, I'm not sure we want to sign up for extra work but I can check
<mdeslaur> seb128: ok, thanks...let me know
<pitti> Riddell: when you accept SRUs, can you please use sru-accept.py? (Please see https://wiki.ubuntu.com/StableReleaseUpdates#Reviewing%20procedure%20and%20tools)
<ccheney> pitti: did you see my email from earlier?
<pitti> ccheney: yes, I responsed to your IRC ping this morning
<pitti> ccheney: I'm afraid the only thing that'll help is a rebuild, since the last build was longer than 7 days ago
<ccheney> pitti: oh ok, seems my irc client ate it
<seb128> mdeslaur, do you guy use work items for your specs?
<ccheney> pitti: ok well i will be doing a proposed upload in a week or two once final 3.2.1 comes out, i think it will be fine until then
<mdeslaur> seb128: yes, we do
<micahg> pitti: out of curiosity are there any plans to get apport into Debian
<pitti> ccheney: right
<seb128> mdeslaur, ok, security-m-private-directory, the [actions] are wanted in that format? or should they be moved to items?
<pitti> micahg: haven't heard of any; I don't think I'll have time to maintain everything there, it'd be a huuuge effort
<pitti> micahg: (unless they want to use Launchpad for the crash reports and retracing, but even that will take a fair amount of work)
<seb128> mdeslaur, sorry I asked after reading the email and there was not the whiteboard start there so I didn't notice you had work items on the spec too
<mdeslaur> seb128: ah, ok :)
<micahg> pitti: ok, we were wondering because if we increase the # of hooks, it would be good to push the hooks to Debian, but not all DM/DD will take since they;re useless in Debian ATM
<micahg> pitti: but that's ok, thanks for the info
<pitti> micahg: FYI, in udisks I do this: http://git.debian.org/?p=pkg-utopia/udisks.git;a=commitdiff;h=a9ddc5bb660a4f53c2533c8e154159dfcdd94519
<micahg> pitti: that's perfect, would you mind if I added that to the docs once they are created?
<pitti> micahg: alternatively, I'm not oppposed to having hooks for popular packages, where the hook is the only diff to debian, in apport-symptoms package
<pitti> micahg: heh, of course not :)
<micahg> pitti: great, thanks, I'll keep the apport-symptoms thing in mnd as well
<micahg> *mind
<micahg> pitti: is there a reason why you use lsb_release vs dpkg-vendor?
<pitti> micahg: yes, this is the first time I hear about dpkg-vendor :)
<micahg> pitti: ah, ok, I learned about it a couple months ago while doing a merge from Debian
<pitti> dpkg-vendor --is Ubuntu, nice
<pitti> micahg: this avoids the extra b-dep
<micahg> pitti: ah, cool
<fabrice_sp> pitti, may I have your opinion on bug #561958?
<ubottu> Launchpad bug 561958 in calibre "calibre-mount-helper missing" [Undecided,Confirmed] https://launchpad.net/bugs/561958
<pitti> fabrice_sp: ah, I deliberately don't install this bit; it's crackful
<pitti> it would need to use udisks or something
<fabrice_sp> I see your comment in debian/rules, but without it, some readers are not recongnized
<pitti> fabrice_sp: hm, will have a look later on; those readers are non-usb mass storage?
<fabrice_sp> I think so, but I can check (mine is recognised as USB)
<fabrice_sp> yeah: it seems that they are non-usb mass storage, so that would explain why without this program it does not work (nothing to mount)
<mvo> mdeslaur: thanks, I noticed that - the amount of [mvo] in it is a bit disproportional to the amount of other names ;) but I will see what I can do, some of it should be really straightforward
<mdeslaur> mvo: I didn't know who it should be assigned to, as I mentioned, feel free to reassign or to tell me what you can't/don't want to do
<mdeslaur> mvo: btw, you're second in line for the cloning machine, right behind pitti
<mvo> mdeslaur: heh :)
<seb128> mdeslaur, hey again
<seb128> mdeslaur, we don't have ressources for those this cycle
<seb128> mdeslaur, if anybody want to work on that patches are welcome otherwise I guess it's not going to happen this cycle
<seb128> mdeslaur, you can assign those to our team but it's likely we will not get to those
<seb128> mdeslaur, otherwise your team might maybe try to work on those?
<mdeslaur> seb128: okay, thanks
<mdeslaur> seb128: we'll see what we can do
<seb128> thanks
<micahg> mdeslaur: I'd be happy to take care of the firefox packaging for installation if there's an example somewhere else
<mdeslaur> micahg: ok, thanks
<cody-somerville> Does it take awhile for requestsync to see new versions of a package in Debian?
<cody-somerville> It thinks the version of a particular package is 17 when I'm looking at the accept message for version 18.
<Laney> when was it uploaded?
<cody-somerville> a few hours ago
<Laney> probably takes longer than that for LP to learn about it
<Laney> have a look at lp/debian/+source/package
<Laney> however, if rmadison -u debian knows about it then requestsync from trunk will save you
<cody-somerville> superm1, is the i8k module supported on vostro series laptops?
<wgrant> Laney, cody-somerville: The Debian archive has been broken for a couple of weeks now, so the LP import is out of date.
<wgrant> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577759
<ubottu> Debian bug 577759 in ftp.debian.org "kde-l10n has incomplete and contradictory checksum information in experimental" [Serious,Open]
<cody-somerville> ewww
<wgrant> (this breaks debmirror for unstable)
#ubuntu-devel 2010-05-19
<crimsun> classvoid: other channel, please.
<psusi> woohoo... sped up e2defrag by 25-50%!
<hyperair> there's an e2defrag?
<psusi> yea... the old defrag package.. was written by linus, ted tso, and remmy card in the 90s... debian and ubuntu dropped the package 2 years ago because it had not been maintained for like a decade... I rescued it and have been updating it to work on ext4 and combining it with ureadahead to speed up boots
<psusi> it has a super sexy ncurses gui ;)
<psusi> was cool as hell when I used it the first time on slackware in 95 ;)
<hyperair> ooh that's cool.
<hyperair> but isn't there an e4defrag around already?
<psusi> they are working on it.... who knows when it will be usable... but it's for doing online defrag... so far they are just trying to get it to defragment files, does not defrag free spcae or try to relocate files to better places
<psusi> basically it just copies a file and hopes it is less fragmented than the original, then replaces the original with the copy
<psusi> e2defrag is an offline defragmenter... works on the raw block device when it is not mounted, and totally reorganizes the fs, packing all blocks as far left as possible, and 100% in order... and really, really, really tries to only move any given block once
<psusi> it also can take a list of files to prioritize and pack first... like those read by ureadahead
<hyperair> ah i see. that's interesting
<hyperair> cool =p
<hyperair> now if that would work with lvm + cryptsetup, even cooler
<psusi> I'm using lvm and my test volume on the old first gen 36 gig 10krm wd raptor raid0 array boots in 13 seconds with my changes to ureadahead and a good defragging
<TheMuso> ooo nice.
<hyperair> ooh
<hyperair> but it needs unmounting, making it only feasible during initrd stage..
<psusi> took the boot time on my new laptop from 35 to 30 seconds... it's only a 1.3 ghz celeron, so it spends most of its boot time cpu bound.. the ureadahad part now only takes 4-5 seconds
<psusi> aye... which is why I'd like to get initramfstools to build an alternative initrd and add it to the grub boot menu
<psusi> so you can choose from the grub menu to do a defrag boot
<psusi> when I defragged the laptop I just had grub pass the break parameter to make the initrd stop so I could manually mount the root fs, copy the defragger to the root tmpfs, umount it, then defrag it, and reboot
<psusi> the ncurses interface didn't work but I've figured out what needs to be included for that... just need to automate it now with initramfs-tools
<hyperair> cool
<hyperair> i look forward to testing it =p
<hyperair> i wonder if btrfs would also have a defragging option..
<arand_> psusi: Cheers for the help with looking at the fsck error before, it seems like Ts'o fixed up e2fsprogs within 30mins or so :) , And released a new version which is already in debian :D
<psusi> ohh, wow.. you mean he looked at my comments and jumped right on it?  was my guess basically right?
<xnox> arand_, =)))))) will it appear on lwn.net as a follow-up?
<psusi> now if only he would implement my idea to fix fsck's handling of finding inodes from previous incarnations of the fs by checking if the ctime is < fs creation time and ignoring them if it is ;)
<arand_> psusi: Again, I have no idea :) but this is the commit: http://pastebin.ubuntu.com/435904/
<psusi> arand_, well, glad it's fixed ;)
<psusi> ok... pushed my local e2defrag changes up to lp and I think it's about ready for another release, and some sponsorship to upload to the universe archive for maverick... well, there might be one more thing I can do to improve performance first...
<superm1> cody-somerville, not really sure, what interface does it use?
<superm1> i'm guessing it doesn't
<cody-somerville> it sorta works but sometimes causes X to crash or my music applications to freeze up. sometimes it'll give me -1 value instead of correct temp as well for example. Sometimes it also takes two attempts to modprobe it.
<imbrandon> superm1: gotta few minutes this evening ( or early morning depending on your sleep schedule ) , lol
<imbrandon> for a /query
<\sh> moins
<\sh> does anybody know where keybuk hide his slides of his talk "the plumbing layer" from Tursday Plenary last week ?
<dholbach> good morning
<pitti> Good morning
<ajmitch> morning pitti
<pitti> hey ajmitch, how are you?
<ajmitch> good, how are you?
<ajmitch> recovered from UDS? :)
<sabdfl> morning all
<pitti> ajmitch: yes, wasn't that much to recover from; no jetlag this time
<pitti> hey sabdfl, good morning
<Usama> pitti, may I ask about the mlterm issue
<pitti> Usama: you can ask in the channel, sure (probably not me personally since I don't know about mlterm)
<Usama> https://bugs.launchpad.net/bugs/562130
<ubottu> Ubuntu bug 562130 in language-selector "Selecting an RTL language should install RTL capable terminal emulator" [Low,Triaged]
<Usama> it needs main inclusion request but many people (not RTL users) don
<Usama> ... don't seem to like the idea
<pitti> Usama: you can file one if you have a good reason for it to be in main
<Usama> I don't want it to be in main but people are saying that it's necessary to have it in main if it will be installed when selecting RTL language
<pitti> Usama: right, it could be hooked into language-selector
<pitti> Usama: then the main question is if there is someone who will maintain it
<Usama> some one already have built version 3 packages
<Usama> would it be enough if some one build new versions and update it?
<pitti> Usama: well, the point is there needs to be someone who will continuously test and look after it
<pitti> and upload fixes if it breaks, or if there's a new version
<pitti> this is not an one-off task
<pitti> we can probably sync from Debian most of the time, so it's not a lot of work
<pitti> Usama: debian has 3.0.0, FYI
<pitti> so this will be autosynced into maverick anyway
 * pitti does an autosync run, he needs the new postgresql
<Usama> some one said that debian do install it by default for the Hebrew language but I couldn't check if it's true
<Usama> could you help with that. it might support my case
<pitti> I don't know, but I'm not sure that Debian even has magic like this
<ct529> hi everybody. I have upgraded to 10.04. I have nvidia quadro 1600 m. I tested the graphic drivers thoroughly, both os and proprietary. There are problems and conflicts on libgl and lbglx, between mesa and the driver. I believe they need to be fixed.
<dim> Hola!
<RAOF> ct529: How did you install the drivers?  Sadly, those problems are essentially unfixable, although we have systems in place to make it as little trouble as possible.
<dim> Hey I'm interested in finding some resources for doing some more basic linux dev stuff
<dim> like right now im thinking I should make a program that manually interprets /dev/input/mouse0 or something
<dim> but im not really sure where to start, should I just make a python program read from that device?
<RAOF> You could certainly do that.
<dim> RAOF, alrighty then
<dim> is this the right place for those kinds of questions?
<dim> or an acceptable place at least
<RAOF> Not really, no :)
<RAOF> âDevelopment of Ubuntu (not support, not app development)â
<dim> hm, alright
<ct529> RAOF: I made a thorough test, by trying all the possible combinations in all possible orders.
<dim> well I'm also in #ubuntu-app-devel
<RAOF> That's probably a better place.
<ct529> RAOF: I do realise you are right, it is a problem difficult to fix.
<ct529> RAOF: I think there is actually a chain of problems.
<RAOF> Well, actually it's a problem *impossible* for us to fix; we don't have access to the source.
<RAOF> It should work well as long as you use the the jockey tool - SystemâAdministrationâHardware Drivers under Ubuntu.  Somewhere else for Kubuntu.
<ct529> RAOF: well, you have access to the mesa and the os driver source I believe.
<ct529> RAOF: and the proprietary driver installs a clear set of files, so it is potentially possible to fix it.
<ct529> RAOF: but I am not saying it is practically possible.
<ct529> RAOF: but I would like to look into it, if you do not mind.
<RAOF> The proprietary driver replaces parts of X with its own code, that doesn't work with the non-proprietary drivers.
<RAOF> You're welcome to look into it if you like.  I don't think it will be productive.
<RAOF> Anywayâ¦ dinner.
<ct529> RAOF: it does not work well, even using the jockey tool.
<chrisccoulson> could someone please reject the gnome-screensaver SRU that i uploaded to lucid-proposed?
<chrisccoulson> i'm just talking to a user and it doesn't completely fix one of the bugs it's meant to fix
<pitti> chrisccoulson: *flush*
<chrisccoulson> pitti - thanks :)
<vandenoever>  /usr/lib/pkgconfig/libsoup-2.4.pc has the wrong version number
<vandenoever> (in karmic)
<lool> james_w: Heya, it seems the package import issue I mentionned yesterday affects a bunch of packages, rendering merges quite unpractical
<james_w> lool: which issue was that?
<lool> james_w: Some packages were not imported on LP
<lool> james_w: Sorry, that was two days ago, not yesterday
<james_w> lool: the LP mirror of Debian isn't up to date?
<lool> james_w: Yes, I think that's what you mentionned
<ajmitch> it's been that way for a month or more
<james_w> right, there's not a lot I can do about that, the issue is apparently on the Debian side
<lool> That's a problem for bzr merges
<lool> james_w: Ouch, I think I know what you mean
<lool> Is it mirroring experimental?
<james_w> yeah
<lool> My debmirrors have been failing since a month+ due to a bug in apt
<ajmitch> I think it's mirroring in general now
<lool> james_w: How can I check whether it's mirroring?
<ajmitch> there's a new apt-ftparchive for lenny, ftpmasters just need to install it afaik
<StevenK> Or DSA
<james_w> lool: you can check individual packages to see if they are up to date
<james_w> I don't know if there is a status page
<james_w> ...or you could ask StevenK :-)
<StevenK> The Debian mirror for LP is also failing to update due to the same error
<lool> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577759
<ajmitch> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577759 is tracking the progress on that side
<ubottu> Debian bug 577759 in ftp.debian.org "kde-l10n has incomplete and contradictory checksum information in experimental" [Serious,Open]
<lool> stable has 0.7.20.2+lenny1 and proposed-updates lenny2
<ajmitch> StevenK: poke a few people please :)
<StevenK> ajmitch: I did, at UDS.
<ajmitch> maybe not enough beer was used
<StevenK> I'm not about to fly to Germany and sit on Ganeff's lap until he fixes i
<ajmitch> heh
<lool> ajmitch, james_w, StevenK: I've mailed DSA and Ftpmasters to point at the update, requesting to install it
<StevenK> lool: With an RT ticket?
<Riddell> vandenoever: Version: 2.28.1  that's wrong?
<lool> StevenK: No
<vandenoever> Riddell: actually, my mistake, it's correct, i was confused with 2.2
<Omahn> I would like to fix a simple bug in vsftpd that currently has a version of 2.2.2-3ubuntu6, should my debdiff with the fix be versioned 2.2.2-3ubuntu7 or 2.2.2-3ubuntu6-1 or something else?
<raphink> Omahn:  2.2.2-3ubuntu6-1 is not a valid version number
<raphink> ubuntu7 is good
<Omahn> raphink: Great, thanks.
<gartral> who's bloody idea was it to release empathy without a window title that says empathy? i see 25 people a day in #ubuntu asking "what's the name of this chat application in ubuntu?"
<Usama> this is the first time I notice that :)
<Usama> there is the about button I guess
<pitti> Help->About says it quite clearly, though, as well as the app menu
<gartral> i did it twich today cause it has such an obscure frigging name
<chrisccoulson> pitti - i reuploaded gnome-screensaver if you have time for some SRU review later ;)
<apw> pitti, i am about to get expired out of work-items-hackers, seems its not something i can fix myself ... could you
<pitti> apw: done 10 mins ago, and fixed the option for self-renewal
<apw> pitti, thanks :)
<pitti> yw :)
<pitti> I don't want to loose my best contributor!
<apw> pitti, we have a bunch of blueprints over on another project, which have some WIs for people on my team.  am wondering if that is something we can cope with
<pitti> apw: ubuntnu-arm?
<apw> yeah
<pitti> apw: yesterday I implemented support for project WIs
<pitti> apw: you mean like this? http://people.canonical.com/~pitti/workitems/ubuntu-arm/
<pitti> :)
<apw> yeah like that :)
<apw> will the ones for people on my team blead over or is it separate
<pitti> apw: if you have WIs assigned there, they should appear
<apw> awsome
<pitti> we don't do the per-team thing for projects
<pitti> well, at least the configuration for it doesn't do
<pitti> (we potentially could)
<pitti> it's just "all"
<apw> yeah, for now that likely is plenty for over there
<apw> and if the items bleed to my charts, rocking is all i can say
<pitti> apw: btw, you don't happen to have a recent lucid.db laying around somewhere?
<pitti> (cf my platform mail about destroying it by accident)
 * apw looks around, i think i renamed it to current.db and it got zapped by maverick
<pitti> darn
<pitti> the current workitems/lucid/ stuff has the #WIs all correct, but the history (and charts) are gone
<pitti> I now know how it happened at least
<apw> pitti, i have this
<apw> -rw-r--r-- 1 apw apw 6907904 2010-01-27 10:42 lucid.db
<apw> which isn't very new
<pitti> hm, very old
<pitti> apw: ok, thanks for checkign
<apw> i'll have a little look around, my cron job was collecting it for the longest time
<fabbione> Keybuk: the more I read 94065, the less I udnerstand why they are duplicated
<fabbione> Keybuk: maybe there is implementation overlap
<apw> pitti, i assume your one got broken: http://people.canonical.com/~pitti/workitems/lucid/lucid.db
<fabbione> Keybuk: but what I understad in 94065 is that they want the equivalent of removing rcX.d/ symlinks
<pitti> apw: right
<fabbione> Keybuk: mind to explain why are they the same?
<pitti> hey fabbione
<fabbione> hi pitti
<Keybuk> fabbione: 94065 is a wishlist for "disabling a job", which is exactly what your bug was
 * pitti lunch &
<fabbione> Keybuk: we are asking 2 different things... even if it can be achieved by similar code :)
<fabbione> otherwise why would I bother to file a bug? :)
<Keybuk> maybe I didn't read your bug hard enough, what were you asking for?
<fabbione> Keybuk: from boot options.. they are asking as normal maintainance thingy.. similar to symlink handling for old rcX.d/
<fabbione> Keybuk: the concept might be similar in terms of internal implementation (AFAICT anyway)
<fabbione> Keybuk: but the user interface looks different to me
<fabbione> Keybuk: anyway.. as long as you can give it a thought.. then if it's referenced by bug A or B... matters not
<Keybuk> yeah, yours is somewhat of an overlap of 94065 and 389113,
<Keybuk> I understand what you're asking for - "don't start this service in single-user mode" kind of thing
<Keybuk> it's certainly on the roadmap ;)  just doesn't quite map onto the existing bug#s
<fabbione> hmm i wasn't presented 389113... need to read that
<fabbione> no, even if i am booting into 2 or 3 or 5
<fabbione> don't start this service at boot. <- full stop :)
<Keybuk> right, 389113 covers being able to put things like "noapache" on the kernel command-line
<fabbione> then optionally, you can say at this runlevel
<Keybuk> and having upstart disable that job
<fabbione> yeah something like that
<fabbione> i didn't see it in the list
<fabbione> noapache sounds scary :)
<fabbione> ok well.. good to know I am not the only one with crazy idea
<fabbione> +s
<Keybuk> :-)
<fabbione> tho I admit, in a cluster enviroment it is extremely useful
 * fabbione will go for the workaround in the meantime
<cjwatson> pitti: I have: -rw-r--r-- 1 cjwatson cjwatson 34606080 2010-04-10 01:18 lucid.db
<apw> i have gotten a new machine which was installed from a usb stick, installed and rebooted normally.  did an update and grub updated and it popped a gconf popup for grub which asked me to select grub install location, i ignored it and hit forward, then realised what it was
<cjwatson> cody-somerville: I've merged base-installer now
<apw> 1) back was not possible, and 2) having gone forward i ended up unbootable. booting from the USB i oddly get booted from the disk now, but grub-install works but does not make me bootable
<cjwatson> apw: a number of people have reported that; what I really need is a recipe for reproducing the previous state, since by the time people report it they've typically lost the information I need
<apw> that i can believe
<apw> i am suspicious that the trigger here is that the disk has moved from sda to sdb when i have the usb stick in
<apw> hrm.  i simply cannot get grub-install to install a boot block
<jussi> join #ubuntu-artwork
<cjwatson> pitti: I've put that lucid.db in my home directory on lillypilly, in case it's useful
<jussi> argh
<apw> it says it has, but ... it does not boot afterwards
<cjwatson> apw: it's supposed to use /dev/disk/by-id/ paths
<cjwatson> but 'sudo grub-install /dev/sdwhatever' should work ...
<apw> now that i've broken it its not happy about fixing itself for sure
<apw> that says it works, but the machine does not become bootable as a result
<apw> gah
<tjaalton> cjwatson: are you planning to migrate console-setup to keyboard-configuration for maverick?
<cjwatson> then I suppose it's actualy booting from wqsomewhere else
<cjwatson> tjaalton: probably
<cjwatson> sigh, lag
<cjwatson> tjaalton: it's on the "really nasty merges" list
<tjaalton> cjwatson: heh, ok
<apw> cjwatson, when i did the original install, it booted just fine so it used to be able to do it ... that was an official release CD image on stick
<tjaalton> that one has to go right ;)
<apw> cjwatson, ok this is perverse.  if i have the stick inserted it boots from the hard drive ... as if grub seconadary is coming from there
<apw> cjwatson, can i ask grub where it loaded itself from?
<cjwatson> apw: do you have a /boot/grub/device.map?
<cjwatson> is it wrong?
<cjwatson> "boots from the hard drive" - there are a bunch of things that might mean, you mean it loaded the kernel from the hard drive with a root= pointing there?
<ogra_cmpc> cjwatson, https://wiki.ubuntu.com/Specs/M/ARMPreinstalledSDCardImages mind to take a glance if i miss anything obvious ?
<apw> cjwatson, the machine does not boot from the USB without manual intervention
<ogra_cmpc> (not urgent)
<apw> but if i don't ask it to then the mahcine loads with the OS from the real drive when the USB stick is present, not when it is not
<apw> when the stick is present the harddrive moved to (hd1)
<cjwatson> ogra_cmpc: I don't have it all in my head, but it seems to match roughly what we discussed
<apw> so i suspect the /boot/grub/device.map will be wrong
<cjwatson> apw: if /boot/grub/device.map is there at all, I suggest removing it
<ogra_cmpc> cjwatson, great, thanks
<cjwatson> modern grub can work without it and frankly is better off without it
<cjwatson> we're deprecating the (hd1)-style names
<apw> cjwatson, not there anyhow ... hrm
<cjwatson> silly question, are you sure that bios boot order is correct?
<cjwatson> try running grub-install with 'sh -x' and send me the output
<apw> heh new machine, seemed to boot windows before it was zapped, will check
<apw> ok it does fall back to usb it seems after hard drive, so if its not on the hard drive at all it would do something, why the usb stick then confusingly boots the real disk ... i don't know ... though doesn't the CD have syslinx?  and i end up with grub
<apw> so perhaps the usb stick got wacked with grub
<cjwatson> I'm not sure I'm following
<cjwatson> running grub-install on the USB stick should render it self-contained, assuming that the /boot/grub/grub.cfg on the USB stick is vaguely sane
<apw> if we assume that the reason it boots with the stick installed is that the fallback order is disk/something/something/USB disk
<cjwatson> and of course assuming that the BIOS is actually booting it
<apw> then i'd expect to see the syslinux, as i get grub i assume one of the two spindles have grub
<cjwatson> I don't follow where the musing about isolinux is coming from
<pitti> cjwatson: thank you!
<apw> the USB stick should be untouched, and thus have syslinux, but i am now suspicuus the install has wacked it with grub
<cjwatson> you've been repeatedly running grub-install on things
<cjwatson> oh, I see
<cjwatson> I thought you *wanted* to boot from the USB stick
<apw> yep, to be sure it happened then would require a scratch install i cannot now be sure it was me
<apw> no i want my real disk to boot :)
<cjwatson> Marjo reported a pretty similar bug during the release sprint
<cjwatson> so I know that USB installs sometimes get the grub target wrong
<apw> yeah its mentioning hd1, which the spinning disk is right nwo
<cjwatson> forget about hd1
<apw> (in the sh -x output)
<cjwatson> that naming is (a) unhelpful (b) unused
<cjwatson> can I see the output?
<apw> working on it
<apw> http://pastebin.com/YQpPrTdT
<Keybuk> cjwatson: are we doing a team meeting today?
<cjwatson> ok, so the hd1 stuff there is definitely a red herring - with a single-disk biosdisk configuration, it doesn't even end up in any configuration file
<cjwatson> Keybuk: a quick one, no need for activity reports though since we've all been at UDS :)
<cjwatson> I'll send a mail in a moment
<apw> cjwatson, can i tell if grub is in the boot block trivially ?
<apw> cjwatson, ok i think i have it sorted ... i had to make the linux root disk a boot partition in fdisk
<cjwatson> apw: you can compare it with /boot/grub/boot.img; there'll be some differences for variable bytes and the partition table and such
<cjwatson> grub doesn't care about active partitions, but maybe your BIOS does
<apw> cjwatson, yeah i suspect the latter
<apw> i am going to double check and confirm
<cjwatson> I know of some BIOSes that refuse to boot from a disk unless it has an active partition
<cjwatson> the installer is supposed to deal with that already though
<apw> that is exactly the symptom i am suspecting, and the installer did not do that
<cjwatson> well, if the installer was confused about which the boot disk was supposed to be (which is borne out by your comments above), then it wouldn't have known that it needed to take care to give it an active partition
<cjwatson> so this is probably just all part of the same bug, which is the one Marjo saw
<cjwatson> if I can manage to put together a test case in KVM, I want to try to fix that one for 10.04.1
<apw> ok confirmed, removing the active flag has broken boot
<Laney> :q
<apw> so i think this is as you say a combination of known issues
<cjwatson> right.  useful to have confirmed that there are still BIOSes with that property, though :-)
<cjwatson> the last definite sighting I had of that was seb128's laptop a few years back
<apw> cjwatson, this looks to be an efi bios underneath too
<apw> so it may become more common not less
<cjwatson> but of course once it was fixed in the installer we stopped caring much
<cjwatson> lovely
<apw> i has a ticky to switch modes, i am somewhat scared of trying it
<cjwatson> guess I'd better get that patch sorted out and pushed to Debian at some point
<apw> cjwatson, this machine also has the lovel M-P from the screen switch button
<cjwatson> M-P?
<apw> meta/windows-p
<apw> Super_L down, P down, P up, Super_L up ... from pressing the output screen select button
<cjwatson> ah
<apw> cjwatson, i recon we should just give up and map that key to the monitors applet
<txwikinger> Riddell: what needs updating in debootstrap?
<Riddell> txwikinger: turns out it already supports maverick so nothing needs updating
<Riddell> unless you want to do the merge with the current Debian version
<cjwatson> please don't
<cjwatson> a merge there is a waste of time - I'll do a new upstream release and then we can just sync
<G> sorry asked a few minutes ago in -motu but I think here is more the right place, anyone able to take a look at https://bugs.launchpad.net/ubuntu/lucid/+source/libvirt/+bug/571093 to me it looks like a udev bug and I think some udev trained eyes might be a good idea :)
<ubottu> Ubuntu bug 571093 in libvirt "multipath + libvirtd eats away more memory over time" [Medium,Confirmed]
<G> it's getting triggered by udev calls and udev is all over the valgrind output
<seb128> cjwatson, slangasek, jdong: do you plan to do some SRU review soon? since pitti is on rotation SRU seems to be stucked a bit...
<seb128> would be nice to get those moving at least to get fixes in the LTS
<cody-somerville> cjwatson, thanks! :)
<cjwatson> seb128: yikes, suppose I'd better
<seb128> cjwatson, thanks!
<apw> pitti, this dbg image reaping issue, can i confim that this filename is in the right form: linux-image-2.6.34-2-generic-dbgsym_2.6.34-2.9_amd64.ddeb
<apw> pitti, we are getting pounded about them going missing
<jcastro> Keybuk: are you planning on proposing to give a talk at debconf?
<pitti> apw: that seems right; I suppose it's due to the old -image-debug hack that I placed on the ddeb machine
<pitti> apw: I reverted it now
<pitti> oh, hang on, we still need it for older releases
<apw> yeah old releases still use the old form
<pitti> apw: ok, I extended the hack, should cover both forms now
<apw> pitti, thanks ... you are the man
<pitti> let's hope that it works now
<pitti> http://ddebs.ubuntu.com/pool/main/l/linux/ -> seems that's missing -22 :(
<apw> yep, thats how we noticed that it wasn't working
<pitti> apw: can you watch this for a bit with the maverick ones?
<apw> yeah will be watching for a while
<pitti> the hack should have kept the lucid -22 ones
<pitti> unless -22 used -dbgsym already?
<apw> lucid also uses the new form
<pitti> i. e. did you change the name in updates?
<pitti> aah
<pitti> ok, that explains it
<apw> good thanks, will write it up and close the bug out
<amikrop> Hello, how can I run JVM source?
<amikrop> What do I need to install?
<joaopinto> amikrop, the support channel is #ubuntu
<amikrop> ok thanks
<cjwatson> seb128: there's no bug in the changelog for librsvg - how do we track verification in that case?
<pitti> cjwatson: I usually reject those and ask to reupload with a bug #
<cjwatson> oh, wait, I just found a bug number buried in there
<cjwatson> hard to see amid the list of upstream bugs
<pitti> cjwatson: you don't use queuediff? that opens the bugs automatically
<cjwatson> no, my net connection is slow
<pitti> ah, it's a new upstream version
<cjwatson> I don't want to have to download all the files
<pitti> if it's the same upstream version, that'll only download the diff.gzs and use interdiff
<cjwatson> because it can take ages for me, my habit is not to use it
<nigelb> pitti: is there a problem with the nondefault gconf value reporting via apport?
<pitti> nigelb: define "a problem"?
<nigelb> someone was writing a hook and he noticed that its reporting a lot more values that its supposed to be and most of them were normal
<pitti> nigelb: not known to me
<nigelb> pitti: I'll ask him to log a bug with exact details against apport
<apw> cjwatson, ok confirmed that doing an install on this machine breaks the USB stick, grub ends up on it instead
<juliank> mvo: Just want to inform you that software-center is 2.0.3debian1 in maverick (has been synced automatically). This means a bit of Ubuntu branding is currently missing in debian/control package description.
<juliank> Apart from the description change, you can merge anything else though, so this is not a large issue.
<pitti> so much for stealing Debian's version numbers for ubuntu..
<mvo> juliank: thanks, I know about this, but maverick is so fresh that it does not matter that much yet
<mvo> juliank: I did merge most (all?) in trunk/ - thanks for this
<ogra> just make sure that never happens with initramfs-tools ... that will be painful :)
<Keybuk> jcastro: I've proposed a BoF
<Keybuk> jcastro: I think
<Keybuk> jcastro: the Debconf registration/papers/etc. system makes canonicaladmin look like the work of a web genius
<jcastro> Keybuk: ok, you might want to doublecheck, the deadline is past but they told me it's a "soft" deadline
<jcastro> Keybuk: it's like a more obsfucated version of summit!
<Keybuk> if I click "Own Events" on the left, I see
<Keybuk> "Upstart in Debian", event state: undecided
<ScottK> jcastro should volunteer to help since he's so experienced at this stuff.
<jcastro> Keybuk: ok then you're all set
<jcastro> (just doublechecking)
<apw> pitti, gah didn't realise you had moved the db ... doh ... no wonder my pages are stale
<pitti> apw: only after lucid
<pitti> from workitems/ to workitems/lucid/
<apw> well and * into maverick
<pitti> right
<apw> which they weren't last week :)
<pitti> I announced that today
<pitti> and they were moved today
<apw> yeah i'd been waiting on a dx-blueprint appearing ... and it didn't :)
<seb128> cjwatson, sorry about the changelog not being clear, you don't have the .changes available for review to get those listed easily?
<cjwatson> seb128: yeah, I do, was just being a bit dense, sorry
<cjwatson> it's been a while since I did serious SRU processing
<seb128> cjwatson, np, thanks for reviewing those sru!
<juliank> mvo: Could you merge lp:~juliank/software-center/jak
<mvo> juliank: sure, merging now
<jibel> asac_, hey, could you please have a look at bug 429841
<ubottu> Launchpad bug 429841 in flashplugin-nonfree (Ubuntu) "broken packaging: package flashplugin-nonfree failed to install/upgrade: (breaks upgrade)" [Critical,Confirmed] https://launchpad.net/bugs/429841
<jibel> asac_,  it was introduced with fp-installer 10.0.22.87ubuntu2 in jaunty and breaks the upgrade from lts to lts
<mvo> juliank: hm, actually using deb822 is kind of nice as it iirc works with gzip files too. or can TagFile() do that nowdays?
<juliank> mvo: Then ignore this revision, but add a dependency on python-debian.
<mvo> juliank: good point! thanks
<chrisccoulson> jibel - it should probably be me who looks at that ;)
<asac_> chrisccoulson: take care. that package is a mess ;) ... lots of upgrade paths need to be tested before uploading something
<asac_> also partly its owned by security team etc.
<asac_> but yeah. you are the right person ;)
<chrisccoulson> asac_ - ok, no worries
<chrisccoulson> yeah, i'll take a look at that in a bit
<jibel> chrisccoulson, as long as someone can look at it, that's perfect. Many thanks. asac_ sorry for pinging.
 * mvo waves to jibel
 * jibel waves back
<didrocks> cjwatson: thanks for netbook-launcher approval
<chrisccoulson> thanks for gnome-screensaver approval too :)
<pwnguin> pitti: is LP #582946 a dupe?
<ubottu> Launchpad bug 582946 in gvfs (Ubuntu) "package gvfs 1.6.1-0ubuntu1 failed to install/upgrade: corrupted filesystem tarfile - corrupted package archive" [Undecided,New] https://launchpad.net/bugs/582946
<seb128> pwnguin, it's not-gvfs-bug in any case
<seb128> pwnguin, seems a file corruption, either locally or wrong download
<rickspencer3> seb128, I
<rickspencer3> m not sure who should own the touch one
<seb128> rickspencer3, did you mean to reply on this channel?
<rickspencer3> nope
<qense> robbiew: MaverickReleaseSchedule says our current focus should be A-2, but shouldn't that be A-1, as the first alpha hasn't even been released yet?
<pwnguin> seb128: crazy
<pwnguin> downloading from lp via wget worked
<robbiew> qense: no, as the iterations are more focused at how we plan the work for the release. So we scope out enough work for the 1st iteration, which ends at Alpha 2.  Then we look at what's remaining and what others may have discovered they need and scope out additional work for the next iteration, which ends on Alpha 3
<robbiew> the iterations allow us to be a bit more agile in our approach to the release, instead of setting in stone everything we will do upfront
<qense> robbiew: ah. The first Alpha release is just to get people to install it? ;)
<qense> It's got a label, lets install it!
<robbiew> and see if the damn iso builds :P
<qense> Those things are useful to know. :)
<robbiew> indeed
<qense> robbiew: OK, thank you for your answer. Sounds like a good way to manage the cycle.
<robbiew> np...and I admith it's confusing though...maybe I should just call them "Iteration 1", "Iteration 2", etc
<qense> yeah
<qense> Although the current names to tell when the iteration ends.
<kees> pitti: hi! can you reset the canonical-security workitem history?  I'd like the burndown line to start with today's view of the blueprints (as of 5 minutes ago) since now we're finally done filling in the initial work items.
<robbiew> qense: yeah, true
<ccheney> bug 582980, I would appreciate a check to see if the patch I made looks sane for an update for Lucid SRU, its needed for OOo to save to cifs mounts properly
<ubottu> Launchpad bug 582980 in coreutils (Ubuntu) "stat does not know about cifs" [High,Fix committed] https://launchpad.net/bugs/582980
<jdstrand> pitti: fyi, I've got the psql updates now. I will build in ubuntu-security-proposed as mentioned in the bug
<psusi> anybody know of a C library that implements a binary tree data structure?  like std::map<> or something?
<soren> psusi: glib?
<psusi> soren: gimme something I can man? ;)
<soren> psusi: hm?
<Pici> grep the manpages for that? then select one?
<psusi> the name of a function or something I can look up in man
<psusi> for what is the question?
<Pici> Ignore me if this doesn't make any sense.
<juliank> psusi: http://library.gnome.org/devel/glib/unstable/glib-Balanced-Binary-Trees.html
<soren> psusi: http://library.gnome.org/devel/glib/2.24/glib-Balanced-Binary-Trees.html [+]
<psusi> oh, I don't want to bring in all of gtk ;)
<soren> psusi: glib is separate.
<psusi> hrm..
<juliank> glib is small (smaller than libstdc++), about 800k on my system (although the package is larger as it includes gio-2.0 and others as well)
<psusi> this might do the trick then... once I figure out how to use it... right now e2defrag keeps a forward and reverse translation map for disk blocks, but they are just arrays... so one entry per disk block... so you need 671 mb of ram just for the translation maps on a 320 gig drive... I need to rework it to use a more efficient data structure ;)
<psusi> I'm confused... what is g_tree_insert() going to do with key and value pointers?  when it doesn't know anything about what they point to?
<psusi> how is it going to copy a new value into the tree without at least knowing what its length is?
<psusi> and how is g_tree_replace() any different than g_tree_insert()?  insert says it sets the value if the key already exists
<psusi> hrm... ok, I think I see... internally the tree only stores a pair of opaque pointers, the key and the value... so I just have to allocate my own object and pass the gtree functions pointers to the key and value members of that object...
<psusi> that's a bit disappointing... would be faster to have the object itself stored in the tree
<SEJeff> As if richard didn't hate ubuntu enough already: https://bugzilla.gnome.org/show_bug.cgi?id=618952
<ubottu> Gnome bug 618952 in gnome-power-manager "Leak in gnome-power-manager on Ubuntu 10.04" [Minor,Resolved: notgnome]
<xnox> slomo, are you building webm gstreamer packages in ppa:gstreamer-team/ppa ?
<slomo> xnox: yes
<xnox> slomo, awesome =) can't wait to test them ;-)
<slomo> xnox: already there for lucid, i don't plan to upload them for karmic
<xnox> slomo, i've upgraded to maverick already.... =) should be fine though ;-)
<slomo> xnox: then you'll get the packages when they're in debian :P
<xnox> well I'll just play my odds and install lucid packages without rebuilding ;-) and see what happens
<slomo> xnox: should work just fine :) you need gst-plugins-{base,good,bad} and libvpx
<xnox> slomo, kk
<xnox> slomo, and I need to wait for i386 build to finish =(
<ion> Woot, WebM sounds promising.
<ion> Considering all the major browser vendors are behind it.
<ion> Crap. I forgot about IE. :-P
<xnox> ion, Microsoft issued a statement IE9 will support h.264 out of the box and WebM if plugin is installed... The better news is that loads of hardware manufacturers are behind it & Adobe as well. Apple is missing though so far?!
<ion> http://x264dev.multimedia.cx/?p=377 though
<xnox> ion, yeah I read that. But i don't care. Google gives the patent liceses for VP8 for free to everyone. So if anyone sues, they will have to deal with google and 30+ leading software and hardware companies.
<xnox> ion, i don't care that x264 is better. I need to buy a patent license to use it =)
<xnox> the question is will blueray switch to VP8 or not......
<psusi> so I'm trying out this glib btree and it seems glib.h is trying to include glibconfig.h, which does not exist... why idea why?
 * psusi wonders what an include file is doing in /usr/lib
<slangasek> psusi: you need to use 'pkg-config glib-2.0 --cflags'
<psusi> what's pkg-config?  I just had to add the -I flag, but header files should be in /usr/include not /usr/lib shouldn't they?
<slangasek> 1) being in /usr/include doesn't guarantee you can properly include all the dependencies without having to add a bunch of things to cflags; 2) glibconfig.h is split out because it's auto-generated and machine-specific.
<slangasek> (I don't think that's sufficient reason to put it in /usr/lib, really, but given 1) you're already doing it wrong wrt portability if you're hard-coding -I options)
<psusi> hrm.... I'll have to look into this pkg-config then... but for now I'm fiddling with GTree to create a double binary tree indexed extent list for the block relocation map ;)
<slangasek> pkg-config is a dependency of libglib2.0-dev.  You shouldn't have to look far.
<temugen> k
<temugen> hey, this isn't my vim window...
#ubuntu-devel 2010-05-20
<nigelb> pitti: this is the trouble with apport I was talking about yesterday malone bug 583109
<ubottu> Launchpad bug 583109 in Apport "attach_gconf collects default settings instead of non-default" [Undecided,New] https://launchpad.net/bugs/583109
<bluefoxicy> so, besides a license that basically says "Do whatever the fuck you want to," there is also a license that requires you to be dead to use the software.
<bluefoxicy> I swear you just can't make this shit up.
<G> bluefoxicy: what requires you to be dead to use?
<m4t> is there a way, either through session or system dbus, to get mouse/kb idle for an x session?
<m4t> i downloaded like 600MB of xmlto dependencies to compile gnome-screensaver docs, but the listed GetSessionIdleTime doesn't seem to exist
<m4t> maybe i want consolekit's GetSystemIdleSinceHint?
<dholbach> good morning
<ddecator> didrocks: ping
<didrocks> ddecator: yes?
<ddecator> didrocks: hey, i was just wondering if the apport hook mentioned in bug 579548 is something you guys would really like, and if you'd be willing to have me write one for you
<ubottu> Launchpad bug 579548 in clutter-1.0 (Ubuntu) "Add apport hook for lspci" [Undecided,New] https://launchpad.net/bugs/579548
<didrocks> ddecator: yeah, the hardware stuff is the first step. TBH, I'm not sure about additional info that can be relevant, maybe glxinfo will be good?
<didrocks> ddecator: if you can do it, that would be awesome :)
<ddecator> didrocks: yah, i'm just starting to learn how to write hooks, but that one seems simple enough. if you can just let me know what info exactly you would like it to grab, i can work on getting it setup tomorrow and attach it to the report for you guys to review :)
<didrocks> ddecator: sweet, you can maybe also have some look at clutter forums to see what's people are asking for too. That can be a good hint about what to include in the report
<ddecator> didrocks: sure thing, i'll look into that tomorrow (2:14am here right now, haha)
<didrocks> ddecator: take some rest ^^ In any case, I won't really have time to review it before next week :)
<ddecator> didrocks: good deal, thanks for getting back to me :)
<didrocks> ddecator: you're welcome. Thanks for tackling that! Just ping me when you need some help
<pitti> Good morning
<ddecator> morning pitti
<pitti> jdstrand: thanks
<pitti> kees: ok, can do; I thought about globally resetting it tomorrow, but I can do those individually as well
<RAOF> ddecator, didrocks: If you need any help you probably want to look at the X apport hooks, which already collect that information.
<ddecator> RAOF: thanks for the tip
<mb4_> morning
<mb4_> can i ask questions about packaging here?
<pitti> kees: updated db, charts should update in 30 mins
<pitti> mb4_: yes
<juliank> mvo: Do you have any plans to move to update-manager 0.200 for maverick? Having to mostly independently developed series of update-manager does not look like a good thing.
 * cjwatson wraps his head around the dpkg merge
<mvo> juliank: it was on the agenda for last cycle already, but time was/is a issue
<dholbach> juliank: I just had a look over it, it seems like the version in Debian needs to still merge a lot
<juliank> mvo: OK.
<juliank> dholbach: Yeah, I know that there are large differences in some parts.
<mvo> juliank: btw, did you notice that I merged the "unbranded-icons" branch into trunk? that is probably useful for the debian packages of s-c
<juliank> mvo: I currently use the standard package management icons (system-software-install) and I may stay with 2.0.X for squeeze to have the same as lucid, unless someone asks me to ship the same release as maverick.
<mvo> juliank: ok, sounds good. trunk/ is in a lot of churn currently, so staying with 2.0.x is a good choice
<mvo> turnk is also pretty exciting, but that is a different matter :)
<juliank> mvo: I will merge the 2.1 stuff into a debian-next branch once you released it.
<mvo> ok
<juliank> mvo: You forgot to merge the changes for debian/control, BTW; including the one to only conflict with gnome-app-install (<< 1) [without the version, it breaks the upgrade path]. I also reformatted a bit there, since tabs and spaces where mixed in trunk.
<juliank> (And without merge information, merging it back becomes increasingly complicated)
<mvo> juliank: ok, I fix that
<jdstrand> pitti: fyi, still waiting on sparc and powerpc (est start time, 3 and 4 hours respectively)
<mvo> juliank: I added a unbranded desktop file now too, so with the icons and the desktop file its just the .ui file that needs some work
<juliank> mvo: OK.
<juliank> tseliot: Is there a branch for x-kit somewhere?
<mvo> juliank: if you cherry pick r789,790 then that should make the branding easier, I moved code into the Distro class where it belongs
<dmart> Has anyone been having trouble with NFS servers running on lucid?
<dmart> I'm finding that when a client executes fcntl(... F_SETLKW ...) in an NFS chroot, it hangs for minutes at a time
<dmart> normal file assess works OK though, and lockd processes are present on client and server
<dmart> The server lockd is stuck in disk sleep state the whole time, but since it's a kernel process this is possibly normal.
<pitti> jdstrand: please let me know if you need build score bumping, etc.
<jdstrand> pitti: I think it would probably be a good idea (at least for hardy). redhat released today. if we plan on it being in -proposed for a week, then it doesn't matter. if we want to release today, it would probably be good
<jdstrand> pitti: I am testing the i386 and amd64 binaries this morning
<dmart> slangasek: Have you seen rpc.statd failing to launch on lucid?  It looks like this may be the cause of my problem (see scrollback)
<tseliot> juliank: it's here: https://launchpad.net/xorgparser why are asking?
<juliank> tseliot: Debian packaging. The branch contains a debian/ directory for 0.4.2, but code from 0.4.2.2 though.
<tseliot> juliank: right, it shouldn't contain a debian directory. The tarball doesn't contain it
<juliank> tseliot: The package is native, so from my point of view something went really wrong then.
<tseliot> juliank: ?
<tseliot> juliank: what's wrong with having a native package? x-kit is not in debian
<juliank> tseliot: The package is a native package with one tarball and the version 0.4.2.2; although it should be 0.4.2.2-1 and using a .diff.gz on the upstream tarball (which despite your statement above, also contains the debian/ directory)
<juliank> or 0.4.2.2-0ubuntu1
<tseliot> juliank: only 0.4.2.2 contains the debian directory and it was mistake
<tseliot> the other tarballs don't have it
<juliank> tseliot: Well, but the package should then still be not native, since you have two different tarballs with the same version. A native package is only for the case where the upstream tarball is equal to the package; that's not the case here.
<juliank> If you do upstream releases without a debian/ directory, your package must not be native.
<juliank> The tarballs even complete the .bzr directory!!!
<juliank> s/complete/contains/
<tseliot> yes, I've noticed that (in the launchpad page)
<jdstrand> pitti: not sure if you rescored yet, but hardy is currently scheduled to 1-3 hours, so maybe not worth it
<tseliot> juliank: but yes, good point, I can replace the upstream tarball and correct the version
<juliank> tseliot: Never replace an existing tarball, it will break the assumptions of your users.
<tseliot> juliank: the one in the launchpad page
<juliank> tseliot: Your upstream users.
<juliank> tseliot: You don't work with Python very much, right? (My points being: non-PEP8 function names (myFunc instead of my_func), comparisons to None using == instead of 'is', classes not derived from object ['class MyClass:' should be 'class MyClass(object):')
<tseliot> juliank: I wrote that code some time ago, now I have different habits. I used to adopt the QT coding style but now it's no longer the case.
<tseliot> and I don't want to break the api
<ScottK> It's not rare to see PyQt code that follows Qt conventions instead of Pythonic ones.
<juliank> ScottK: We're talking about simple Python code, not Qt related.
<ScottK> Ah, sorry.  Poor assumption on my part.
<tseliot> juliank: may I ask the purpose of your code review?
<tseliot> just curious
<juliank> tseliot: Well, I just want to understand it, to consider how to go on with packaging jockey for Debian (which needs python-xkit). I can either package it standalone as in Ubuntu or merge X-Kit into jockey and not expose the API at all.
<juliank> It's just the question of whether I want to support it generally or only for jockey-internal use.
<tseliot> juliank: ok
<dmart> Keybuk: hi there, do you have a moment for a quick upstart question?
<dmart> Keybuk: never mind, looks my issue is already tracked here: https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/581941
<ubottu> Ubuntu bug 581941 in nfs-utils (Ubuntu) "statd does not start automatically when needed nor can be forced to start on boot" [Undecided,Incomplete]
<nigelb> pitti: got a min?
<pitti> nigelb: what's up?
<nigelb> remember I was talking to you about some trouble with nondefault gconf values?
<nigelb> here's the bug, bug 583109
<ubottu> Launchpad bug 583109 in Apport "attach_gconf collects default settings instead of non-default" [Medium,In progress] https://launchpad.net/bugs/583109
<pitti> nigelb: yep, saw it an assigned to me
<nigelb> pitti: ok, so you're faster ;)
<nigelb> shall we proceed as usal with the hook and let this bug be fixed in apport?
<nigelb> i.e. not wait for this to be fixed for the hook
<apw> does anyone know if we have any 'first boot' processing which occurs after a karmic to lucid upgrade but not after a scratch install of lucid ?
<pitti> nigelb: yes, I think so; it's independent from the hook
<nigelb> pitti: ok, tks :)
<cjwatson> apw: not unless individual packages implement it
<cjwatson> apw: (postinst scripts can tell whether they're being upgraded or fresh-installed)
<juliank> Launchpad always times out ....
<smoser> persia, or cjwatson or dmb member.
<smoser> trying to add my feed to planet ubuntu
<smoser> i can't write to lp:~planet-ubuntu/config/main planet-ubuntu
<cjwatson> that's not a dmb thing ...
<smoser> well, dmb approved me
<cjwatson> well, wait, were you given per-package upload rights?
<cjwatson> I may have forgotten to add you to ~ubuntu-dev
<smoser> yeah, i was granted ppu
<smoser> i searched that list and didn't find myself, but didn't know if i would have been in a sub group
<cjwatson> right, I'll sort that out now, thanks for the note
<smoser> thank you cjwatson
<cjwatson> smoser: should work for you now
<smoser> cjwatson, it does. thanks.
<nigelb> stefanlsd: ping
<slangasek> dmart: there are various race conditions with statd startup in lucid, currently.  Do you have /var on a separate partition?
<dmart> slangasek: I don't think /var is on a separate partition, but is may be experiencing the race problems you refer to: see https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/581941
<ubottu> Ubuntu bug 581941 in nfs-utils (Ubuntu) "statd does not start automatically when needed nor can be forced to start on boot" [Undecided,Incomplete]
<slangasek> dmart: right - in that case that's the known fallout from the preceding portmap startup change; discussed in bug #525154, though that's now something of a catch-all bug for statd startup issues
<ubottu> Launchpad bug 525154 in nfs-utils (Ubuntu) "mountall for /var races with rpc.statd" [Undecided,Triaged] https://launchpad.net/bugs/525154
<dmart> I guess I can work round this one manually for now
<slangasek> dmart: setting statd to 'start on local-filesystems' probably fixes it for you, if you're not on nfsroot
<slangasek> I've just been slow to make that change in lucid because the code is touchy and I haven't had a solid block of time to think all the way through it
<dmart> OK, I'll try it.  The box in question is a server; my main problem is huge timeout delays when clients do locking calls
<slangasek> well, /separately/, there's a race condition with nfs-kernel-server startup because it's not converted to upstart yet
<doko> cjwatson: about the cpuname change: I think it's the correct fix. the triplet is used to be passed to configure, and it should be the correct one.  it easier to grep the rules files for wrong conditionals.
<cjwatson> doko: is there any way to get this merged to Debian in advance of Debian switching gcc's defaults?
<cjwatson> e.g. can we add that cputable line as a separate line?
<cjwatson> (in dpkg)
<doko> but: currently we are using the triplet names as multiarch names (as for multilib). maybe this really should be changed to architecture names, maybe the linux names extended to something like i386-linux
<doko> cjwatson: afaik this a table lookup, with the arch as index. don't know how this should work
<cjwatson> well, I guess I can play with it
<cjwatson> I care because this is one of the two remaining unforwarded changes in dpkg - tantalisingly close to being able to sync it
<hunger> Is maverick going to use gcc 4.5 or 4.4? What was decided at UDS?
<Aquina> I read nothing about that in UWN and slo no statement about this in the video casts so far.
<Aquina> I gess 4.5 is possible however.
<hunger> Aquina: Thanks. I only found a mail from pitti (pre-UDS) stating that the default toolchain is still set to 4.4 at that time since gcc version was a UDS decission.
<cjwatson> right.  new dpkg heading for maverick.  hold on to your hats.
 * ogra grabs the rope
<ion> Any hope dpkg-multiarch will make it into maverick? Anyone working on it?
<cjwatson> ion: slangasek has been making noises about working on it this cycle
<ion> Nice
<cody-somerville> ugh, getting kubuntu blueprint changes for some reason
<Riddell> probably because kubuntu-dev is the assignee and ubuntu-core-dev is a member of that
<tremolux> rickspencer3: I have more data for the bug report btw
<rickspencer3> nice
<rickspencer3> tremolux, I'd like us to know what is going on so that if we see that problem again, folks know what's up and how to work around it
<tremolux> rickspencer3: unfortunately, it's a weird error
<tremolux> rickspencer3: yes, we need a report, I'll write it and add what I found out
<rickspencer3> something about auth or keys or something?
<tremolux> rickspencer3: yes, something seemed wrong there
<tremolux> rickspencer3: plz try to find out what happened to the ppa if you can
<rickspencer3> he deleted it
<tremolux> rickspencer3: oh, bummer
<rickspencer3> he said he added it a long time ago, and the keys were misbehaving or something
<rickspencer3> he's in #quickly if you want to chat to him directly
<tremolux> rickspencer3: that sounds like what the problem then, yeah
<rickspencer3> tremolux, but I would like software-center to handle the problem if it's at all likely to happen again to others
<tremolux> rickspencer3: agreed
<rickspencer3> of course if it's a rare circumstance, prioritize appropriately
<tremolux> rickspencer3: should be very rare, yep
<rickspencer3> in that case, meh
<rickspencer3> it's not like there was data loss or crashes, etc...
<tremolux> rickspencer3: I'll log it, it's important to keep track of
<rickspencer3> k
<rickspencer3> thanks
<nucc1> hi i'm a novice programmer, i'm trying to track down an Evolution bug, can anyone help me interpret this error message? its only 3 lines. http://pastie.org/969603
<cjwatson> the first two lines are probably irrelevant, and the third means that the program attempted an invalid memory access
<cjwatson> http://en.wikipedia.org/wiki/Segmentation_fault
<cjwatson> you'll need to use further tools to find out why: evolution may have its own debugging options to emit more verbose output, or else use tools such as strace, gdb, or valgrind
<nucc1> thanks, i'll look into using a debugger. evolution doesn't seem to have any option for getting more verbose debug output
<cjwatson> nucc1: #ubuntu-desktop may have more detailed experience here
<nucc1> ok. trying to use gdb right now
<tekknokrat> Hi, I need a workaround for /usr/share/python/python.mk for backporting trac-0.11.7 for hardy
<tekknokrat> Is this the right place to ask?
<Drakeson> would someone please remove the extra space between "]" and "<" (in "...] </default>") from line 121 of /usr/share/gconf/schemas/control-center.schemas, in package capplets-data ?  every upgrade keeps nagging about not being able to parse that.
<Aquina> I would check the package in Launchpad and report it there.
<nucc1> cjwatson, gdb says the segfault comes from libgtkhtml-editor
<Drakeson> cjwatson: upgrade evolution
<Drakeson> oops!
<Drakeson> nucc1: upgrade the evolution package.
<nucc1> Drakeson, i think im uptodate. trying to check if i somehow ended up with an odd version of libgtkhtml
<Drakeson> nucc1: what is the version of evolution that you have? older than 2.30.1.2-1ubuntu2 ?
<nucc1> i'm using 2.28.3, ubuntu lucid default
<Drakeson> are you on maverick?
<ScottK> Most people won't be at this point.
<ogra_cmpc> one would hope so
<Drakeson> sorry, that was meant for nucc1
<Drakeson> nucc1: are you on maverick?
<Drakeson> nucc1: are you on maverick?
<nucc1> i'm on lucid. trying to trace random evolution crashes.
<nucc1> looks like i had libgtkhtml-editor 3.30 as opposed to 3.29 that ships with lucid
<Drakeson> a few days ago evolution got broken (gtkhtml-editor got upgraded, but evolution was blocked because evolution-exchange was holding it back). thought that might be your problem ...
<nucc1> thanks, i must have entered the wrong channel. i was thinking that 'ubuntu-devel' means 'ubuntu developers'
<nucc1> now i realise it means 'development version'
<ogra_cmpc> well the development version i swhat the ubuntu developers develop :)
<ogra_cmpc> so you are actually right here ...
<ogra_cmpc> for your particular evo prob #ubuntu-desktop would be the better channel though
<nucc1> ogra_cmpc, but that usually means they are working on the current development version, whereas i'm interested in something to do with current stable :)
<nucc1> yea, i've been told. just stayed here cos of the inertia
<ogra_cmpc> we're also intrested in breakage in the recently released version in case its severe
<ogra_cmpc> if you find a bad enough bug in the stable relese there is always the possibility for a stable release update to fix it
<nucc1> ah, yes, i'll stay on it. if i find it's worth escalating, i'll find out how and do it
<Sarvatt> darn, llvm-dev isn't installable in maverick at the moment :( depends on oprofile which isn't installable because - Depends: binutils (< 2.20.2) but 2.20.51.20100518-1ubuntu1 is to be installed
<cjwatson> doko: ^- can Sarvatt's problem be fixed by a simple rebuild?
<ccheney> pitti: i noticed some users can't seem to get apport-collect to work for openoffice.org it is complaining the package 'openoffice.org' isn't installed but that is just the source package name (and a generally non-installed binary meta package)
<pitti> ccheney: right, it works against binary packages; otherwise it cannot collect information about the binary package, since it doesn't know which one
<ccheney> pitti: it appears for some unknown reason to me that the binary package hint for openoffice.org packages is usually the openoffice.org meta package instead of something like openoffice.org-common or -core that is always installed, do you know how that ends up getting added to the bug report?
<ccheney> pitti: and i am assuming the line "Binary package hint: openoffice.org" is what apport-collect looks at to see what to lookup?
<pitti> ccheney: I actually don't know what this "binary package hint" is or where it comes from; apport doesn't use it
<ccheney> pitti: oh ok, so how does it determine the binary package name when launchpad only knows about source package names?
<ccheney> pitti: is there some file to modify to do the proper mappings?
<pitti> ccheney: you mean for retracing? It's in the "Package:" field of the apport data
<pitti> i. e. the one you report the bug against
<ccheney> pitti: er no when someone files a bad lp bug and i tell them run eg: apport-collect bugnumber
<ccheney> pitti: for several people so far it has returned that they don't have the openoffice.org (meta) package installed, which is generally never installed
<pitti> ccheney: ah, for this we need an apport hook which also covers source packages
<pitti> ccheney: it tries to collect information about the binary package of the same name, but if that doesn't exists (or rather, isn't installed), it's simply not collected
<pitti> ccheney: then it only collects the info from the source_<srcpackagename>.py hook
<ccheney> pitti: if i don't want to do anything special other than get the normal apport reported info what would i do to fix it for that?
<pitti> ccheney: for apport-collect? or for bug filing?
<ccheney> pitti: for apport-collect i suppose, the bug filing probably should be fixed to but isn't as urgent
<pitti> ccheney: hm, does OO.o have a package hook? I don't have one here
<ccheney> pitti: no it doesn't have a package hook, i was just wanting them to add the standard apport info that all packages get via apport-collect to an old bug filed without apport
<ccheney> pitti: there isn't too much that i would need in a hook, maybe what video driver they are using, but the standard info is usually all i ever need
<pitti> ccheney: you could ask people to run apport-collect -p openoffice.org-draw 12345, for example
<pitti> i. e. against the application that they actually have a problem with
<ccheney> ah ok so the -p is still useful, i thought it was deprecated and not actually used anymore
<pitti> for apport-collect it's still useful
<pitti> it's not necessary any more for ubuntu-bug
<ccheney> oh ok
<ccheney> pitti: thanks for the help
<pitti> you're welcome
<hendry> i'm deploying a commericial binary package on Ubuntu and I'm wondering how I should create a shortcut on the user's desktop. Any advice here?
<juliank> hendry: According to the topic, you should ask in #ubuntu-app-devel. But anyway, you should not create stuff on the desktop.
<juliank> Which is impossible on installation time anyway, since installation is run as root; and not as the normal user who wants to run the application
<Sarvatt> cjwatson: changing the oprofile Build-Depends: to binutils (>= 2.20.51.20100518-1ubuntu1) and rebuilding certainly seems to work so far as to letting llvm-dev install at least :D
#ubuntu-devel 2010-05-21
<ccheney> anyone know of a cli tool that can inspect pdfs for what fonts are inside, etc. i remember there being one but can't remember what it is called
<psusi> seriously, what the hell is gcc smoking?   warning: function declaration isnât a prototype... a prototype is EXACTLY what a function declaration is...
<temugen> 1
<temugen> psusi: What was the actual problem?
<temugen> that's not all that uncommon for gcc error messages :P
<psusi> the problem is that it's complaining about yes being true ;)
<psusi> well, DUHHHHHH ;)
<temugen> ah, just a warning message. nice.
<psusi> yes, but it's warning me about water being wet
<psusi> and saying that it ISN'T wet, when of course it is
<xnox> I've had a similar thing and it went away when i did define POSIX
<xnox> (long time ago can't remember exact semantics but it was with gcc4.5 snapshot)
<SmSpillaz> didrocks: ping
<nigelb> SmSpillaz: It may take a bit for him to respond.  He's somewhere in EU
<RAOF> He usually turns up ~3 hours from now.
<Kaleo> nigelb: he is in France actually
<nigelb> yea, fits the 'somewhere in eu' ;)
<Kaleo> :)
<SmSpillaz> nigelb: ah right
<SmSpillaz> well, I'll be around during EU working hours then
<SmSpillaz> half of our developers are in the EU :p
<ekoontz> anyone worked with graphviz?
<hunger> Which gcc version will maverick use? I read this was going to get decided at UDS but did not find any updates yet.
<pitti> Good morning
<hunger> morning!
<RAOF> hunger: I believe the answer is 4.5, but don't quote me on that.
<RAOF> Morning, pitti!
<hunger> RAOF: Thanks. cpp is still depending on 4.4 though, so maybe not. I'll wait and see.
<pitti> hey RAOF, how are you?
<RAOF> Thankful that it's the weekend ):
<RAOF> :)
<RAOF> I've not *quite* managed to recover from UDS yet.  The weekend will allow this.
<pitti> RAOF: still jetlagged
<pitti> ?
<RAOF> No, just a bit sick.
<RAOF> The cold weather here hasn't helped much :/
<didrocks> SmSpillaz: yes? (can you please provide the question in the hilight instead of just "ping"?) thanks :)
<SmSpillaz> didrocks: oh ok, sorry (ping pong, then talk is the way I'm used to :p)
<didrocks> SmSpillaz: no pb, what's up? :)
<SmSpillaz> didrocks: anyways, question was: in src/window.vala:toggle_window_picker () (for unity) do you think we can put instead of a debug message, something like the vala Xlib bindings equavilent of XInternAtom ("_UNITY_TOGGLE_EXPOSE", true); and XChangeWindowProperty (display, rootwindow, atom, l[1] = false/true) or something of the like?
<SmSpillaz> that way other window managers like compiz and kwin can just read that property through a plugin (like we do for kde already) and toggle the expose mode for people who use compiz with unity
<SmSpillaz> I can write a patch if you want
<didrocks> SmSpillaz: not sure if toggle_window_picker doesn't do other checks that the Xlib call doesn't have. In any case, you should ping njpatel next week (he isn't there this week) about it
<didrocks> SmSpillaz: think also that mutter is used to render the whole unity environment (upanel and launcher), not sure how you want to do that with other WM
<SmSpillaz> didrocks: it doesn't
<SmSpillaz> didrocks: I'm not particularly sure how it works, but I can use compiz with the unity shell
<didrocks> SmSpillaz: hum, so, you have mutter launch, rendering unity by the libunity mutter plugin, and then run compiz in it? tricky :)
<SmSpillaz> afaict (from a quick code once-over) is that the mutter plugin and the unity shell both import libunity and the mutter Unity.global_shell.toggle_window_picker method overload the one in libunity which was originally in window.vala
<SmSpillaz> oh and also afaict by testing, I think unity-launcher automatically launches mutter, but you can kill mutter and launch compiz
<didrocks> SmSpillaz: ok, I didn't have the time to check that part, only the big picture, if it works this way, that's great ;)
<didrocks> SmSpillaz: but again, njpatel is the man to ping about that
<SmSpillaz> didrocks: ok - hopefully njpatel will be good with patches to add that atom set/unset so it can work with other wm's :)
<didrocks> SmSpillaz: if he does that, I'll update the packaging too :)
<nigelb> pitti: how to get the output of 'lspci -k | grep -A2 VGA' with command_output.  most of what I try is failing :(
<ddecator> didrocks: so far i'm getting glxinfo, dkms status (displays details on graphics driver, thought it might help), and nigel and i are trying to find a way to reduce the lspci -k output to just the video card. anything else you can think of off-hand that might be helpful for clutter?
<didrocks> ddecator: I think that's already a lot in addition to attach_hardwaredinfo() (not sure about the spelling). We will see later if we need other info
<ddecator> didrocks: i actually took off attach_hardware because i thought it might be overkill, but i can add it back in if you want
<didrocks> ddecator: I think it's still good if you can add the specific commands first.
<RAOF> ddecator: report['PciDisplay'] = pci_devices(PCI_DISPLAY)
<ddecator> RAOF: yah, wasn't sure if that would be useful or not, but i'll add that as well
<nigelb> RAOF: ah, forgot about that one ;)
<RAOF> ddecator: That's how to get just the lspci info for the display :)
<ddecator> oh, does it? o.o
<RAOF>  /usr/share/apport/package-hooks/xserver-xorg-core.py - it contains all of that stuff, just waiting for you :)
<ddecator> RAOF: ah, perfect, thanks :)
<ddecator> RAOF: yah, that's what i've been looking at, but didn't know what pci_devices gave as output :p
<AnAnt> Hello, is notify-osd going to be dropped in meerkat ?
<RAOF> ddecator: That's why you use âubuntu-bug xorgâ to file a test bug on staging :)
<ddecator> RAOF: yah, probably should, i've just been using that to file bugs to test my hooks on staging :p
<pitti> nigelb: command_output does not take a shell command, just a normal argv
<pitti> nigelb: you can run ['sh', '-c', 'lspci -k | grep -A2 VGA'] if you want, or do the searching in python
<nigelb> pitti: hm, ok. ah, searching in python should be better :)
<nigelb> Thank You!
<pitti> np :)
<Daviey> ping slangasek, Riddell, Hobbsee, pitti, mdz, Keybuk, cjwatson, kees, jdstrand, lool, pgraner: Letting you know of an upload to hardy-proposed fails verification: bug #455873.
<ubottu> Launchpad bug 455873 in apache2 (Ubuntu Hardy) "mod proxy causes duplicate query strings when nocanon option is used" [Medium,Fix committed] https://launchpad.net/bugs/455873
<AnAnt> Hello ?
<mdz> Daviey: acknowledged, looking
<cjwatson> hm, the documentation in StableReleaseUpdates seems overkill to me
<cjwatson> I don't think we need to be alerted about regressions that are only in -proposed, not -updates
<cjwatson> I wonder if this is wiki drift due to refactoring - I don't remember that it used to say that
<mdz> cjwatson: I remember it saying that, and thinking it was a bit conservative. I think the rationale had to do with encouraging lots more people to run -proposed, and therefore taking regressions more seriously
<cjwatson> that said, this is not a regression specific to hardy-proposed - the diff doesn't mention dpkg-statoverride anywhere
<cjwatson> nor does it touch maintainer scripts at all
 * Daviey is still wetting himself :)
<cjwatson> in fact the hardy -> hardy-proposed diff doesn't mention statoverride either
<cjwatson> looks like that code should be cut -d' ' -f3
<cjwatson> from the looks of it, it only affects people who've manually set statoverrides
<cjwatson> maverick is unaffected
 * cjwatson bisect
<cjwatson> s
<cjwatson> fixed by removal of the broken code in karmic (specifically, Debian package version 2.2.12-1, Debian svn r995).  However, the code in question is for upgrades from apache 2.0 -> 2.2, and dapper had 2.0, so we need to fix it rather than remove it.
<cjwatson> therefore I suggest a new -proposed upload adding -d' ' after cut.
 * cjwatson goes to summarise in the bug
<Daviey> cjwatson: thanks
<soren> t/away
<soren> Whoops :)
<cjwatson> I've also reset the SRU bug in question to verification-needed, based on my analysis
<cjwatson> Daviey: thanks for raising this quickly
<Daviey> cjwatson: np.. I'm glad i can relax a bit :).  Are you suggesting it could just be a case of adding a ->-d' '<- ?
<cjwatson> yes
<cjwatson> cut splits fields on tabs by default, but dpkg-statoverride outputs fields separated by spaces
<cjwatson> the code was apparently never tested (so I feel relatively safe in saying it's rare, but we should still fix it)
<Daviey> cjwatson: wilco, thanks.
<pitti> cjwatson: so, xorg-server depends on video-all | video-6, the latter is provided by all video drivers; if I seed e. g. -fbdev explicitly, -fbdev should get the corresponding Task: header and due to how task selection works (as discussed yesterday), video-all should not get installed
<pitti> cjwatson: did I understand this correctly?
<cjwatson> pitti: I would expect so
<pitti> ok, thanks; then I know why it's not working (Task: header is missing)
<geser> could a core-dev please give-back "gir-repository". It FTBFS because it couldn't detect libsoup (the logs doesn't mention why) but it build fine in my pbuilder now (and libsoup got detected). Thanks.
<pitti> geser: doing, thanks
<pitti> geser: ah, failed to upload, it needs gir1.0-gtk-2.0_0.6.5-6_i386.deb removed
<lifeless> ev: hey, curious why you need to shut slaves down
<ev> lifeless: thanks for the quick response.  My master plan is roughly: https://wiki.ubuntu.com/FoundationsTeam/Specs/SharingTestingInfrastructure#Implementation
<pitti> geser: seems we're still ahead of debian there; http://launchpadlibrarian.net/44773564/gir-repository_0.6.5-5ubuntu1_0.6.5-5ubuntu2.diff.gz needs to be reapplied apparently
<lifeless> \o/ code I wrote :P
<geser> pitti: saw it, will prepare it for upload.
<pitti> geser: cheers!
<ev> lifeless: I'm debating if that's really necessary, and if I can get away with just leaving the live environment running and carefully cleaning up after each run of the installer.
<lifeless> by live environment, you mean the pxe boot ?
<ev> indeed
<lifeless> so a couple of thoughts
<lifeless> have a look at my platform node labeller plugin
<Redache> .1
<lifeless> 'platformlabeler' in plugins/
<ev> will do
<lifeless> you could tie the jobs to the builds inside the PXE environment with alabel
<lifeless> using a plugin like platformlabeler to set an appropriate label when the slave comes up
<lifeless> and if you listen to jobs *finishing*, removing the label after the test on it.
<lifeless> or perhaps more simply, just reboot the darn slave to the ready-to-start mode after the job running on the pxe-booted mode completes.
<lifeless> though you'd want to test/time that finely to make sure another job didn't start - I kind of like the idea of removing the label before another job can be scheduled.
<lifeless> there are a lot of parallels with this and a cloud environment too, except that you don't want to run arbitrary tests on a node, just the latest sikuli stuff
<lifeless> possibly worth sketching it out on the list - kohusake is very smart and knows the scope of hudson really well (apologies if you did this on the -user list -> I'm not on that one)
<ev> the problem I've had with labels is that they're a "select one from this set" operation rather than a "give me everything", the latter of which I'd prefer for the ability to run across multiple machines in the datacenter to find hardware specific issues
<ev> that is, I haven't found a way to target a job to a label and have it run on every slave in that label
<ev> noted on elaborating more on what I'm trying to do on the list, and no, I didn't post to -user first.
<lifeless> matrix build
<lifeless> theres also a dude posted to the list in the last week about running a job on every element of a label
<ev> oh cool, I'll dig that up
<lifeless> but definitely check out the matrix build plugin if you haven't
<lifeless> it may not be -quite- what you want, but its close - and his change is probably right on the money
<ev> I have -- when I selected the label it only went to the first node.  Looking on the list showed a mail confirming that behavior as by design, but I've long since lost the URL.
<lifeless> I wish I'd gotten to your session @ UDS :)
<ev> lifeless: indeed, you're experience with this would've been quite helpful.  Still, this a massive hand and is putting me on a much better track than the head smashing I was doing last night.  Thanks!
<lifeless> if you can't find that guy I'm mentioning, ping me via email and I
<lifeless> 'll hunt it up monday
<ev> will do
<lifeless> worst case we write a little tweak to the matrix build plugin to do 'for each'
<lifeless> rather than 'first of'
<lifeless> that would be oh, 1 hour or so, including getting it upstream.
<ev> cool!  I'm definitely liking how willing upstream is to accept such changes.
<lifeless> have I mentioned how much I like SSD's ?
<ev> heh
<lifeless> svn on an SSD is almost not painful.
<TerminX> hm, software-center package is missing dep on python-debian
<geser> could a core-dev please give back: neon27 libgdata libgnomeprintui. Thanks.
<micahg> persia: ping
 * persia prefers contentful pints
<persia> pings too :)
<geser> nice typo
<micahg> persia: heh, could you approve my mail to devel-permissions?  just saw that it never hit the list
<persia> I don't believe I'm a listadmin for that list.  I'll double check.
<cjwatson> I can
<cjwatson> (done)0
<persia> Thanks cjwatson
<micahg> cjwatson: thanks
<micahg> I hope it's not too late :(
<pitti> cjwatson: will you ping me when I shall flush the work items for foundations? we'll flush it for desktop now, and did for security yesterday
<jdstrand> pitti: hey, what is your plan with psql? is it on us to publish or do you want it to sit in -proposed?
<pitti> jdstrand: I'm fine with getting it published; no upstream regression reports so far, and we both tested with p-common
<jdstrand> pitti: I verified it in qrt (and therefore the postgreql-common testsuite)
<jdstrand> pitti: cool, thanks
<pitti> thanks to you
<jdstrand> :)
<cjwatson> pitti: yes - we're getting there but still more to do (I'm on my 5th spec of 5, if I'm counting properly)
<pitti> cjwatson: ok, just give the word
<geser> does somebody know if new package in Debian got already synced to maverick?
<cjwatson> not across the board, sorry
<Daviey> geser: you can use rmadison to check.. rmadison $PACKAGE, will check ubuntu version; rmadison -uqa $PACKAGE will check debian's
<didrocks> pitti: I'm still unsure, do we do manual sync with your script or should we open a bug?
<Laney> there was a thread on -devel
<pitti> didrocks: so am I; I have used my script for years without problems, but you should still be cautious
<Laney> but no AAs have replied as of yet
<pitti> Benjamin Drung has a greatly improved version now
<didrocks> pitti: I've used it some times too, but not sure about the "policy", ok, let's use it so :)
<didrocks> thanks
<pitti> in essence, it produces the same output as the LP one
<pitti> but it doesn't check e. g. the blacklist
<geser> Daviey: "new" as in not yet in maverick at all. so either the script to import NEW source packages from Debian didn't get run either yet or some other reason why the package did got synced to maverick yet.
<pitti> geser: probably the former
<didrocks> pitti: oh ok, I guess we know ourself if it's blacklisted or not if we keep our packages :)
<Daviey> Is the blacklist somewhere we can query?
<geser> didrocks: or we ask bdrung politely to add support for the sync-blacklist
<geser> Daviey: http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<Daviey> ooo
<pitti> the blacklist is mostly interesting for autosyncs, but it might help to avoid accidents
<didrocks> geser: sure, is bdrung's version packaged somewhere? I don't see it
<pitti> it's in bzr so far
<geser> didrocks: lp:ubuntu-dev-tools only at the moment
<cjwatson> while I haven't got round to doing it en masse yet (which is always a pain to start off with because we have to make sure we aren't reintroducing things that were removed but accidentally not blacklisted), I'm happy to sync new packages on request
<didrocks> geser: ok, thanks :)
<cjwatson> Laney: are you looking for this pile of haskell stuff to be synced, perchance?
<geser> cjwatson: through bugs as usual?
<cjwatson> geser: just tell me on irc
<Laney> cjwatson: What pile of stuff? autosync candidates?
<cjwatson> autosyncs are already happening
<Laney> Dunno what you're referring to
<cjwatson> I mean new source that isn't yet in Ubuntu
<cjwatson> but that's in Debian unstable
<Laney> not especially, as long as it happens at some point
<Laney> if I get blocked I'll let you know though
<cjwatson> $ new-source | grep haskell | xargs
<cjwatson> haskell-bzlib haskell-cautious-file haskell-data-accessor haskell-datetime haskell-deepseq haskell-event-list haskell-explicit-exception haskell-fastcgi haskell-feed haskell-filemanip haskell-filestore haskell-ghc-mtl haskell-harp haskell-haxr haskell-hint haskell-hjavascript haskell-hscurses haskell-hstringtemplate haskell-hxt haskell-llvm haskell-markov-chain haskell-maybet haskell-midi haskell-mmap0.4 ...
<cjwatson> ... haskell-monoid-transformer haskell-network-bytestring haskell-non-negative haskell-platform haskell-qio haskell-recaptcha haskell-sdl haskell-sdl-gfx haskell-sdl-image haskell-sdl-mixer haskell-sdl-ttf haskell-sha haskell-split haskell-tar haskell-text haskell-transformers haskell-type-level haskell-url haskell-utility-ht
<cjwatson> guess I can lob that in now, doesn't look like any of it's been in Ubuntu before
<Laney> shouldn't have
<Laney> been
 * Laney kicks brain
<geser> could a core-dev please give back: neon27 libgdata libgnomeprintui. Thanks.
<seb128> geser, doing
<cjwatson> geser: done
<seb128> too late :p
<seb128> cjwatson, thanks ;-)
 * cjwatson looks at the output of "m `new-source`" and once again defers most of this to another day :-/
<cjwatson> ("which of these new packages from unstable has been in Ubuntu before?)
<cjwatson> "
<Laney> can't you tally with the removals log? (is there such a thing?)
<cjwatson> could an archive admin other than me process dpkg in NEW?
<cjwatson> Laney: yes, but the above is a lot quicker to run :-)
<cjwatson> there's no single removals log but removals go in the publication history for each package in LP
<seb128> cjwatson, looking
<Laney> right, that would be some LP API fun then
<seb128> cjwatson, being curious there but how come you have a libdpkg.a but no libdpkg.so?
<seb128> seems unusual
<seb128> is the .a useful for something?
<cjwatson> seb128: at the moment it's a volatile API, but it's exposed as a static library for now to start getting a feel for how people want to use it
<cjwatson> seb128: once it's stable it'll become a .so
<seb128> cjwatson, ok, thanks, binaries newed now
<cjwatson> and hopefully eventually it'll be usable by frontends like apt
<cjwatson> thanks
<qense> Kubuntu people: <http://www.canonical.com/logos> still shows the old Kubuntu logo.
<Riddell> qense: I've notified the web master
<qense> Riddell: OK, thanks!
<bgupta> Is there any plans to patch mysql for the following advisory: http://www.vupen.com/english/advisories/2010/1137 looks fairly serious to the point that remote unauthenticated folks can exploit..
<bgupta> also is this the right channel to ask about such things?
<arand> bgupta: Report a bug if it doesn't already exist, mark as security issue, refer to the CVE, look for a fix to SRU...
<arand> bgupta: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures?action=show&redirect=SecurityUpdateProcedures is a good reference.
<SpamapS> bgupta: http://www.vupen.com/english/advisories/2010/1192
<SpamapS> oops
<bgupta> nice.
<SpamapS> wrong url. ;)
<bgupta> no worries
<kees> doko: hm, glibc jaunty armel ftbfs due to extra _passed_ tests, I think.  should I adjust the expected test results, or what do you think?  https://launchpad.net/ubuntu/+source/glibc/2.9-4ubuntu6.1/+build/1198390
<doko> kees: no
<doko> Encountered regressions that don't match expected failures:
<doko> test-fenv.out, Error 1
<kees> doko: hmpf, I wonder what changed in armel between ubuntu6 and ubuntu6.1.  the actual patch in -updates is minimal.
<ogra_cmpc> the buildds
<doko> if you don't succeed, blame the buildds ;)
<smoser> james_w, thank you for suggesting editmoin.  it improves working with wiki
<james_w> cool
<subway24> My name is Jim Colensworth and my 13 year old son Brandon is obsessed with Linux, i mean REALLY obsessed. he just got the new version of ubuntu and he is shouting out loud about how good it runs, even though we are not well off, our family prays to bill gates, he is our family's idol. my wife loves him almost as much as she loves me! so how do i get my son to stop using linux?
<subway24> i like microsoft, but im using my sons computer for this
<SpamapS> subway24: You should just yell at him and take linux away.
<subway24> but we do not like to discipline him
 * SpamapS secretly hopes the kid decides to move in with a reasonable uncle or something
<subway24> his uncle is in prison
<SpamapS> hmm... prison or parents who like windows.. which one is worse... tough call
<subway24> lol
<subway24> seriously, what should we do
<subway24> i need help
<charlie-tca> switch the whole family to ubuntu, quickly as possible
<subway24> but my wife is in love with bill gates! we all want to know how to make money like he does, so we buy windows products
<charlie-tca> doesn't matter
<charlie-tca> You can still throw the money away on windows products
<subway24> but its a good use for the money
<subway24> hes screaming at me now!!!! i took his linux away\
<mneptok> subway24: your conversation is offtopic for this channel. please use #ubuntu-offtopic, and trolling there is not welcome.
<kees> pitti: wait, why aren't we just fixing the kernel for lucid with bug 539467?
<ubottu> Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/539467)
<SpamapS> so I found this awful upstream that only publishes .src.rpms for their releases.. but its fairly easy to extract the tarball inside... is there a way to write a watch file that can look for a .src.rpm and run alien --to-tgz on it?
<SpamapS> even better... they haven't even bothered to modify their COPYING file properly..
<SpamapS>     <program>  Copyright (C) <year>  <name of author>
<tsimpson> SpamapS: not really, you'd need to create a rule in debian/rules, your best option is to bug the upstream not to do evil
<SpamapS> tsimpson: ah that makes sense. I think I'll take door #2. :)
<olvs> is there a ubuntu hardware/performance cannel?
<olvs> channel
<janeNarak> hello, i'm customize install cd, i'm add extra package  phpmyadmin and cacti, but dbconfig cannot connect mysql-server, because mysql-server not running. how to add phpmyadmin, cacti in customize install cdrom?
<rahulattuluri> Hi Im a computer science student and a ubuntu user as of know I wish to develop ubuntu.I would like to have one mentor to guide me can any one guide me??
<arand> rahulattuluri: https://wiki.ubuntu.com/MOTU/Mentoring/Contributor I'm not sure how much of it still applies though... :/
<rahulattuluri> arand,Thanks
<asac> hmm. one question: what type of script is ok for the upstart .conf script part?
<asac> is there a way to say which shell to use?
<smoser> asac, there is not. /bin/sh with '-e' is used.
<asac> hmm
<smoser> it is somewhat easily worked around if you wanted to do something else though:
<smoser> exec /usr/bin/perl <<EOF
<smoser> # perl here
<smoser> EOF
<asac> heh
<asac> does it escape/evaluate anything in the script block?
<asac> or is it all put unmodified in there?
<smoser> i believe the man page discusses that
<asac> which manpage? the ones i am looking at are not really content ful ;)
<smoser> man 5 init
<smoser> exec gets escaped
<smoser> script does not
<asac> kk
<ogra_cmpc> asac, or try man Keybuk :)
<asac> any idea if i could spawn exec two processes and upstart still tracks them (not sure what tracking for upstart means though)
<asac> two processes from one .conf ;)
<ogra_cmpc> asac, if you use respawn the respawn applies to the whole script part afaik
<asac> ogra_cmpc: thats what i am not sure about ... what happens if i spawn some process, then exec another ;)?
<ogra_cmpc> hmm ...
<ogra_cmpc> if you do it inside one script piece i wuld expect upstart to care for both
<ogra_cmpc> i guess its something to test out
<ogra_cmpc> or man Keybuk as i said before :)
<nxvl> i remember there was a send2debian script, is that correct or am i missremembering?
<nxvl> i remember soren did it
<micahg> nxvl: submittodebian?
<nxvl> micahg: that one, thanks you!
<ccheney> someone sent me a crash file instead of using apport to report it, what do you use to process the crash reports directly?
<Daviey> ccheney: Have you tried double clicking it?
<ccheney> it appears to be base64 encoded but base64 doesn't seem to like it
<ccheney> Daviey, oh not yet, heh
<Daviey> :)
<ccheney> cool it turns it into a proper apport crash report :)
<Daviey> ccheney: \o/
<ccheney> Daviey, thanks for the tip, i wonder why it didn't prompt the user to do that automatically
<Daviey> ccheney: you can use apport to do it on the command line, but double clicking is easier to remember :)
<ccheney> yea
#ubuntu-devel 2010-05-22
<ForgeAus> I know its not strictly a devel question but can someone help me fix my wubi boot?
<nigelb> ForgeAus: can you try asking in #ubuntu? that is the support channel
<ForgeAus> been there done that lol :)
<nigelb> hm, in that case forums would be your best bet
<ForgeAus> yeah, I guess.. .I might try my luck back in #ubuntu some other time , when diff people are there
<jdong> hmm is it the case that the Lucid DVD is missing the Install Server and Install EC options now?
 * jdong is on a slow net connection, or otherwise would find out first-hand
<ogra_cmpc> lamont, how much swap do we have on clementine ?
<lamont> ogra_cmpc: prolly 20GB, maybe as little as 10
<ogra_cmpc> ah, great
<lamont> or rather, did. all the pegatroids are dead-n-gone
<ogra_cmpc> well, the replacement then
<lamont> 20 maybe 30GB
<lamont> it's a 250GB drive... so I was generous
<ogra_cmpc> i was just playing with genext2fs and it needs to allocate the actual image size in ram/swap first
<lamont> ew
<ogra_cmpc> 20G are totally fine
<ogra_cmpc> rolling an image on my babbage2.5 took 35min and needed ~1.5G of ram/swap
<lamont> ok.
<lamont> anyrate, off to my saturday
<ogra_cmpc> thats not much worse than mksquashfs i think
<ogra_cmpc> yeah, thanks for the answer, didnt expect one today at all :)
<lamont> /dev/sda2                               partition       30708236        5564   -1
<lamont> so, 30.
<lamont> acorn, btw.
<ogra_cmpc> sweet
<ogra_cmpc> root@babbage2:~# ls -lh testimg.ext2.*
<ogra_cmpc> -rw-r--r-- 1 ogra ogra 441M 2010-05-22 11:52 testimg.ext2.bz2
<ogra_cmpc> -rw-r--r-- 1 root root 1.4G 2010-05-22 12:10 testimg.ext2.orig
<ogra_cmpc> heh, bzip compresses better than squashfs
<lamont> but doesn't provide random access to the contents
<ogra_cmpc> (the squashfs image is usually above 500M)
<ogra_cmpc> we dont need access, it will be a preinstalled image with oem-config on first boot and the HW specific bits will be set up by a casper like tool
<ogra_cmpc> it just needs to be merged into a two partition image (frist one vfat for uboot, second the content of the ext2 we get from livecd-rootfs) ... in the end the whole thing will be bzipped
<ogra_cmpc> i was just worried to end up with 2G images ... but 450M looks really good
<jml> I installed chromium in belgium, and now the "google search from address bar" thing searches google.be and gives me answers in Flemish.
<jml> uninstalling then reinstalling fixes.
<qense> strange
<Drakeson> Could you please try and see if emacs23 works (since yesterday)?
<shtylman> ccheney: what distro do you build ooo with? UbuntuLucid is not in the default distro configs...
#ubuntu-devel 2010-05-23
<machina> for merges, do we have to keep ALL the old ubuntu changelog entries?
<ion> Why not? Itâs nice to have the accurate history.
<machina> well, I'm trying to merge 1 ubuntu patch with a new upstream version of sensors-applet in debian, and it seems to me that we should only keep the most relevant changes...
<machina> plus the diff would be bigger...
<machina> if that's a valid excuse?
<machina> i guess not :P
<micahg> machina: have you tried grab-merge in ubuntu-dev-tools?  It merges the changelog for you
<machina> hmm i haven't, but I'll look into it. I'm using quilt patches, so I hope it won't treat the merged changelog as a brand new file
<machina> micahg: thanks for the help!
<micahg> machina: np
<ccheney> shtylman: oh i think i must not have sync over the updates from ooo-build-3-2 to head, i will have to go through and find what i forgot to apply to head and 3-2-1 after it branched :-\
<ccheney> shtylman: i'll try to get that done tomorrow
<shtylman> ccheney: k... no problem :) I will look for that when it hits
<H2OyJaBoN> hi!
<test__> hi
<test__> where do i get the paper sketch version of ubiquity ?
<mefiX> hey guys! does anybody over here know, why emacs23 with gtk is not working under ubuntu 10.04?
<mefiX> emacs looks like this: http://twitpic.com/1qazg7 changing the gtk-theme as described in some bug reports doesn't help. compiling without otf/xft support works, but then no fancy fonts are available.
<micahg> any gcc experts to look into why a binary was 1.5MB larger on an SRU update?
<russellgee> YokoZar: Can i have your opinion on something
<russellgee> lp #488981
<ubottu> Launchpad bug 488981 in wine (Debian) "use wine-pulse for wine-packages" [Undecided,New] https://launchpad.net/bugs/488981
<Redache> .5
<YokoZar> russellgee: not gonna happen, we're going to use Maarten Lankhorst's openal audio layer instead (which is almost complete for wine1.2)
<russellgee> YokoZar: Ahh ok, any improvement from the current situation is welcomed. Thanks :)
<russellgee> YokoZar: I just read your blog on the issue, that clears everything up.
<YokoZar> thanks
<micahg> YokoZar: apparently the static still exists in the wine1.2 rc
<YokoZar> micahg: Yes the openal bits haven't been fully merged yet
<micahg> YokoZar: ah, ok, I guess I have to wait for the final release then?
<YokoZar> micahg: we'll probably do like 2 months of rc's every week
<YokoZar> so yes
#ubuntu-devel 2011-05-16
<pitti> Good morning
<ajmitch> morning pitti
 * pitti starts upgrade to oneiric and holds breath
<didrocks> good morning
<nigelb> bonjour didrocks :)
<didrocks> hey nigelb ;)
<dholbach> good morning
<didrocks> good morning dholbach
<dholbach> hey didrocks
 * pitti hugs dholbach
 * nigelb waves to pitti
<cjwatson> now that UDS is over, could an MIR team member have a look at bug 780591, please?  it's blocking all kinds of things
<ubottu> Launchpad bug 780591 in libencode-locale-perl (Ubuntu) "[MIR] libencode-locale-perl" [High,New] https://launchpad.net/bugs/780591
<seb128> didrocks, ^ you seem to be the only mir guy around, could you have a look to unblock that maybe? if you are busy we can probably wait a few hours for mterry to be there
<didrocks> seb128: was just opening the launchpad page :)
<didrocks> cjwatson: on it now
<seb128> didrocks, thanks
<cjwatson> didrocks: thanks
<DasEi> paste
<DasEi> sry, wrong tab
<siretart> could some archive admin please process libav from binary NEW? it will cause a library transition that I would like have completed at least for main before the first alpha releaseâ¦
<StevenK> siretart: Looking.
 * cjwatson syncs ibus-table-chinese into main to replace several previous ibus-table-* packages
<StevenK> siretart: Done.
<debfx> does raptor2 need a MIR to get into main? raptor is already in main
<cjwatson> if it's a matter of switching out one for the other and raptor2 is indeed just a newer version of raptor, that doesn't require an MIR, but raptor doesn't seem to be due for demotion yet
<cjwatson> also, raptor2 build-depends on yajl; unless that's just split-out code, that needs an MIR
<debfx> raptor can probably be demoted once the packages waiting on raptor2 are built
<cjwatson> OK, well if you get an MIR through for yajl we can then sort out the rest
<siretart> StevenK: ty!
<ion> :-D http://security.goatse.fr/compiz-denial-of-service-vulnerability
<Take> Good day
<Take> Hopefully I'm on the right channel, I'm building an custom lucid installation cd and I haven't found an tool which would include upgrades and go trough depencies automatically
<Take> I tought that Simple-CDD would do the trick, but I can't figure out how to use it with ubuntu repositories
<Take> So, should Simple-CDD do the trick or is there some other tool for ubuntu to maintain packages & download necessary files from the offical repository
<hychen> kan/wi2
<cjwatson> ogra_: (or anyone else ARMish) Debian has started to remove maemo/hildon packages from unstable.  Should we follow suit?
<cjwatson> http://lists.alioth.debian.org/pipermail/pkg-maemo-maintainers/2011-February/001059.html
<StevenK> I would sorely love to.
<maxb> If the same update has been SRUed for maverick and is now to be SRUed for lucid, do I just clear the verification-done tag and restart the process?
<maxb> On the same bug, that is
<ev> do we know when the audio recordings from the sessions will start to land, and where? Incidentally, the old http://uds.ubuntu.com/audio/uds-m is broken.
<smb> slangasek, So the oneiric version of ifenslave is an improvement. I added my comments to bug 714904. What would be the next steps? Is it enough to add nominations to the report?
<ubottu> Launchpad bug 714904 in ifenslave-2.6 (Ubuntu) "/etc/network/if-up.d/ifenslave is missing (installed under if-pre-up.d)" [High,Fix released] https://launchpad.net/bugs/714904
<stgraber> smoser: hey! for foundations-o-weblive-integration, can I give you a generic workitem to investigate the work needed for x2go web browser integration ?
<stgraber> smoser: I assigned it to you for now (last work item at https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-weblive-integration). Feel free to move it to the "Unassigned" list or re-assign to someone else.
<tkamppeter> pitti, hi
<pitti> hey tkamppeter, how are you?
<tkamppeter> pitti, fine. Did you do the annotations for the s-c-p session?
<pitti> tkamppeter: I haven't been in that one
<tkamppeter> pitti, sorry, where do I find the session notes in general?
<pitti> tkamppeter: ideally they were copied to the whiteboard; if not, check the etherpad
<pitti> tkamppeter: find the session on http://summit.ubuntu.com
<pitti> tkamppeter: there is a small icon on the top left in the session box which links to the pad
<tkamppeter> pitti, thanks.
<tkamppeter> pitti, I have also done a session about color management for Ubuntu. This has no drafter yet and it is something where the work items get distributed over several people of the Desktop team. Who should take the drafter roll there.
<pitti> tkamppeter: at this point I think you are the person who knows about it most
<sladen> tkamppeter: you should probably own the colourd session;  but I was in it and can add some input if you want
<smoser> stgraber, thats fine.
<micahg> is there an archive admin around that can copy chromium from the ubuntu-security-proposed PPA to $RELEASE-proposed?
<slangasek> smb: unless the workflow has changed significantly, no one is looking at release-nominated bugs; so good that you've pinged me here.  Nominations accepted.  Do you want to prepare SRU uploads?
<smb> slangasek, might be good training I guess...
<tkamppeter> sladen, it would be great if you could help me on this Blueprint. I have added the notes now.
<smb> slangasek, Naively I would take the current natty/maverick source slap in the new code while preserving the changelog where I add some comment about pulling in a new version...
<slangasek> smb: the changelog should be based on the one for the package in natty/maverick and documenting what's being changed to fix this bug
<slangasek> smb: since maverick and natty include the same version of the package, you'll want to pay attention to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update%20the%20packaging
<smb> slangasek, Ok, thanks. Not sure there is but the changes include documentation/examples changes the not directly are part of this bug report. Would I need to open en extra bug for that or are those kind of changes ok without a bug reference?
<slangasek> smb: I would not expect those changes to be included in an SRU upload - only the changes directly related to fixing the bug
<smb> ok, makes sense
<bigon> seb128: could you have a look at https://bugs.launchpad.net/ubuntu/+source/telepathy-logger/+bug/745803 ?
<ubottu> Ubuntu bug 745803 in telepathy-logger (Ubuntu) "telepathy logger uses 100% CPU" [High,Fix committed]
<seb128> what about it?
<bigon> damm I post my comment in double
<bigon> seb128: well see https://bugs.launchpad.net/ubuntu/+source/telepathy-logger/+bug/745803/comments/17 and /20 /o\
<ubottu> Ubuntu bug 745803 in telepathy-logger (Ubuntu) "telepathy logger uses 100% CPU" [High,Fix committed]
<seb128> bigon, seems somebody is on it
<bigon> ah right
<tkamppeter> pitti, still there?
<pitti> tkamppeter: will be back in ~ 30 mins
<dholbach> pitti, good work on fixing the -no bug!
<smb> slangasek, argh, so the latest ifenslave package has also a fix for two bugs in preinst to forget to check "$2"=="" and to look at if-up/down.d/wireless-tools instead of ifenslave. Lucky that a) those are not in the ifenslave package, so there is no checksum and b) there is a third bug that the package name is ifenslave-2.6 not ifenslave anyway. Since all of that is not related to the bug I skip that, and will file a debian bug
<slangasek> smb: sounds good :)
<apw> slangasek, these changes to linux-libc-dev for multi-arch, did we test the result at all ?
<apw> someone last week mentioned that video for linux packages were breaking, to do with kernel headers, can anyone point me in the right direction
<apw> to a bug or a person :)
<cjwatson> apw: v4l1 was dropped and packages need to cope - it might just be that?
<cjwatson> perhaps your interlocutor didn't realise it was deliberate
<apw> heh that is entirly possible
<cjwatson> if it's v4l2, that would be a different matter
<apw> cjwatson, do we have a definatiive ftbs list
<cjwatson> http://qa.ubuntuwire.com/ftbfs/
<ev> mdz: Is this what you were referring to when you said there may already be a tech board decision on recording success/failure: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-August/000601.html
<mdz> ev, no, that's not the bit I was thinking of. thanks for the reminder, i'll dig it up
<ev> mdz: thanks
<slangasek> apw: right - linux-libc-dev multiarch was tested, from the rest of your comments it sounds like you're probably running into the v4l1 deprecation issue instead
<apw> slangasek, sounds good thanks
<micahg> slangasek: can you please copy chromium-browser from the ubuntu-security-proposed PPA to $RELEASE-proposed for lucid, maverick, and natty and apply overrides to put the binaries/source in universe?
<slangasek> micahg: you have the command handy for that?
<micahg> slangasek: I'll check
<mdz> ev, I'm not having much luck finding it. I don't think it was a tech board decision or meeting, just a technical discussion about the installer and whether it was a good idea to try to capture information from successful installs
<ev> okay
<mdz> it was years ago, and maybe not helpful enough to warrant a lengthy search
<ev> thanks just the same
<ev> I've already started drafting the mail to ubuntu-devel, so I'll have that out for tomorrow.
<micahg> slangasek: can you give this a sanity look, I've never prepared this before: http://pastebin.ubuntu.com/608521/
<htorque> hello, everyone! can you tell me, how long it will take for this fix to go into -updates: https://launchpad.net/ubuntu/+source/pygobject/2.28.3-1ubuntu1.1 ?
<micahg> htorque: should be sometime this week, there's usually a backlog after UDS
<htorque> micahg: thanks, that's good. i just don't want to advise someone to enable -proposed.
<smb> slangasek, I have copied proposed ifenslave packages to chinstrap:~smb/4review for review and sponsoring in case things look ok to you. Install fresh/upgrade (just not from that very old version) tested on 64bit builds for Maverick and Natty
<slangasek> micahg: copied
<slangasek> smb: chinstrap> very much not best practice for sponsorship :)  Could you please push a debdiff to the bug report?
<slangasek> smb: debdiff howto: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff#Method
<smb> slangasek, Sorry just got distracted on other channel. I would have done debdiff with debdiff, but I look at that page
<slangasek> smb: right, if you're already familiar with the 'debdiff' command, then there's nothing new and interesting there ;)
<smb> slangasek, We just normally did that for kernel packages for the sponsor to be just able to copy and sign
<micahg> slangasek: thanks!
<slangasek> micahg: n/p
<slangasek> smb: that makes sense for kernels for various reasons, but kernels are a special case
<smb> slangasek, Agreed, just happen to fall easily back to the "bad" habits. ;)
<slangasek> :)
<kotique> how much is this devel channel devel?
<kotique> i'd like to disable any graphical setting on grub2. ANY
<kotique> want a plain text line with bootstring prompt
<slangasek> that seems like a user support question rather than a development question
<kotique> yeah
<kotique> grub2 wiki is dead, second link points to ubuntu's grub tutorial
<slangasek> wgrant: should I assign https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-lp-archive-access-update to someone with LP mojo?
<kotique> thx anywayz
<smb> slangasek, debdiffs attached to bug 714904
<ubottu> Launchpad bug 714904 in ifenslave-2.6 (Ubuntu Natty) "/etc/network/if-up.d/ifenslave is missing (installed under if-pre-up.d)" [High,Triaged] https://launchpad.net/bugs/714904
<slangasek> smb: thanks! :)
<smb> Dammit, those replies seem to come nearly at the same time I press enter.. ;)
<bcurtiswx> Natty SRU request for Telepathy-logger https://code.launchpad.net/~bcurtiswx/ubuntu/natty/telepathy-logger/lp_745803_fix/+merge/60964
<bcurtiswx> Thanks :)
<stgraber> bcurtiswx: hmm, your changelog entry says "Add series file" but the diff doesn't touch debian/series and instead modifies debian/patches/git_eat_cpu.patch
<bcurtiswx> stgraber, yeah i just noticed that.. im fixing that as we type :)
<bcurtiswx> forgot the bzr add .. doh
<slangasek> huh, where did the summit etherpad go
<bcurtiswx> stgraber, thanks and I have fixed the problem :)
<geser> cjwatson: is MoM having issues again? main.html    09-May-2011 00:41 362K
<stgraber> bcurtiswx: as it's an SRU, you want ubuntu1.2 instead of ubuntu2 and you need to target it to natty-proposed instead of natty
<bcurtiswx> stgraber, ah this i didn't know.  Thanks for that info
<bcurtiswx> stgraber, done :)
<maco> to get onto http://reports.qa.ubuntu.com/reports/sponsoring/ with a merge proposal... do you subscribe sponsors to the bug or the proposal?
<maco> oh hey akk joined. tell her the answer too
<stgraber> bcurtiswx: version number is good but debian/changelog still says "natty" instead of "natty-proposed" :)
<bcurtiswx> stgraber, hahaha im such a fool..
<bcurtiswx> stgraber, <crosses fingers> this time
<micahg> maco: akk merge proposals against the UDD branch (lp:ubuntu/foo) are automatically added, for bugs, you subscribe ubuntu-sponsors
<micahg> geser: yeah, I was going to ping cjwatson about it tomorrow, figured at least give him a day to catch up
<maco> micahg: thanks
<stgraber> bcurtiswx: looks good
<bcurtiswx> stgraber, thanks :)
<stgraber> I'll upload in a few minutes
<vish> micahg: isnt the default for merges "ubuntu-branches" (or has that changed now?)
<micahg> vish: that's the long form
<maco> long form?
<stgraber> bcurtiswx: uploaded to -proposed (you now have to wait for someone to accept it in -proposed, then test it and give feedback in the bug report, if succesful it'll be copied to -updates)
<maco> i have been surprised at the speed of -proposed testing lately!
<bcurtiswx> stgraber, much appreciated :)
<micahg> maco: as opposed to using the lp:ubuntu shortcuts, you can specify the full path, lp:~ubuntu-branches/ubuntu/package/suite/branch-name
<maco> the SRUs i did on release day had fix-verified within like 2 hours of being uploaded to proposed
<stgraber> yep, SRUs go through a lot faster than they used to. Seems like we have more testers closely following what hits -proposed (also, the delay to get stuff into -proposed seems to be a lot shorter than it used to be)
<maco> thats because they read the SRU checklist in teh bug *after* upload now
<maco> instead of *wait for people to read stuff*  *wait for sponsor to upload* *wait for thing to be accepted*
<maco> reading got rolled into accepting and now they cant really forget to accept after reading
<vish> micahg: i meant, the reviewer is set to "Ubuntu branches" by default... just tried with a branch lp:~vish/ubuntu/... and if i dont specify a reviewer it sets "~ubuntu-branches" as the reviewer
<micahg> vish: ok?
<vish> but i think those might show up in the sponsor list as well..
<micahg> vish: right
<maco> vish: im guessing micah means that the sponsors webpage looks for that
<vish> ah!
<maco> akk: your fix is now showing up there
<akk> Yay!
<maco> akk: for future reference, on SRU's it should be natty-proposed instead of just natty
<broder> i think the sponsors page looks for any mp against any branch owned by ~ubuntu-branches, but i don't remember
<akk> maco: sorry, noted for future reference
<akk> though I think it chose that by default when I ran bzr lp-open -- at what point should I have specified it?
<broder> vish, maco: ah, yeah - the queue looks for merges where a review was requested by any of ~ubuntu-branches, ~ubuntu-sponsors, ~ubuntu-dev, or ~ubuntu-core-dev
<akk> oh, in the bzr push path?
<maco> akk: at the dch -i step, the top line in debian/changelog has the package version number and release name
<vish> broder: yay, cool! thx! i always wondered why -branches and used to change it to -sponsors.. :)
<broder> vish: there are other reasons to change it to sponsors-  in particular, it means that people on sponsors can properly reject merges, which they can't do for -branches
<broder> (they can just change the status, which is mostly an ugly work around for not being able to claim the review)
 * vish nods..
<maco> broder: what does "Review type: _____" mean?
<broder> maco: i think the intent is to indicate if, say, you're only doing a "design" review or something like that, but in practice i just always leave it blank
<cjwatson> geser: thanks, I'll have a look
<cjwatson> ValueError: process failed 9: dpkg-source -x libtrace3_3.0.10-1.dsc /srv/patches.ubuntu.com/unpacked/libt/libtrace3/3.0.10-1
<cjwatson> dpkg-source: error: none of the filenames in ---/+++ are relative in diff `libtrace3-3.0.10/debian/patches/fix-shlib-depends' (line 6)
<cjwatson> *blink* that's a rather special quilt patch
<cjwatson> current dpkg can cope though
<cjwatson> geser: hacked around for now; next run should hopefully do better
<geser> thanks
<micahg> thanks cjwatson
<geser> does MoM also process packages that are unchanged in Ubuntu?
<cjwatson> (I stuck a dpkg-source wrapper script into the front of $PATH which points to an unpacked current dpkg)
<cjwatson> geser: it shouldn't normally, no
<cjwatson> at least not non-trivially
<broder> stgraber: it looks like caff is misencoding your name, fwiw
<stgraber> broder: as long as the signature is fine, I don't really care :) I'm used to seeing encoding issues with my name ;)
<broder> fair enough :)
#ubuntu-devel 2011-05-17
<pitti> Good morning
<slangasek> cjwatson: the debconf source points at a bzr branch with rich history that's been out of date since maverick; do you want me to fix that up when merging from unstable, or should I instead drop the Vcs-Bzr field?
<pitti> poolie: meh, "bzr get" deprecated? is there some way or amount of beer that I could convince you to keep it?
<dholbach> good morning
<pitti> poolie: we have convenient shorter aliases for a lot of other stuff like "mu" or "up", can we keep "get" as an alias?
<StevenK> bzr br ?
<pitti> poolie: after so many years it's just on everyone's fingers, not to mention in documentation
<didrocks> good morning
<ok2cqr> Hi, I would like to rebuild existing package from devel version of Ubuntu to Lucit. I downloaded source package, extracted it, made changes and now I want to pack it again.
<ok2cqr> But the package is signed by someone and I can't build it even when I have my own gpg signature.
<ok2cqr> Could you help me please how to re-sign the package with my signature?
<broder> ok2cqr: sounds like you might be looking for the backportpackage script in ubuntu-dev-tools
<ok2cqr> broder, I already have ubuntu-dev-tools installed but didn't have this script. I use ubuntu 10.04
<dholbach> @pilot in
* udevbot_ 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: dholbach
<dholbach> broder, chrisccoulson: do you have any idea where we're going with the "sleep" branches (upower, indicator-session, g-p-m)?
<dholbach> jdstrand, are you on bug 723830?
<ubottu> Launchpad bug 723830 in seamonkey (Ubuntu) "seamonkey-2.0-bin assert failure: *** buffer overflow detected ***: /usr/lib/seamonkey-2.0.11/seamonkey-2.0-bin terminated" [Medium,Confirmed] https://launchpad.net/bugs/723830
<dholbach> barry, mvo: do you think https://code.launchpad.net/~hodgestar/software-properties/configurable-key-server/+merge/57406 can go into oneiric?
<dholbach> cjwatson, james_w: can somebody of you mark https://code.launchpad.net/~barry/ubuntu/natty/winpdb/bug-761131/+merge/57787 as irrelevant?
<ubottu> Ubuntu bug 57787 in partman-base (Ubuntu) "Obscure scary warning in installer." [Low,Triaged]
<mvo> thanks dholbach, looking
 * dholbach hugs mvo
<dholbach> rbelem, ScottK, do you think https://code.launchpad.net/~rbelem/ubuntu/natty/kubuntu-mobile-default-settings/plasma-mobile-patches/+merge/58018 is SRU material or is it something we should just get into oneiric?
<dholbach> james_w, cjwatson: can you also please mark https://code.launchpad.net/~benoitg/ubuntu/natty/libofx/libofx.new-upstream-fix-661809-629996/+merge/58207 as irrelevant?
<dholbach> chrisccoulson, micahg, does the patch in bug 766559 look alright to you?
<ubottu> Launchpad bug 766559 in icedtea-web (Ubuntu) "Forcing installation of firefox" [Undecided,Confirmed] https://launchpad.net/bugs/766559
<dholbach> james_w, cjwatson: can you also please mark lp:~hrw/ubuntu/natty/armel-cross-toolchain-base/1.63 and lp:~hrw/ubuntu/natty/gcc-4.4-armel-cross/1.40 as irrrelevant for natty?
<ohsix> bug 57787
<ubottu> Launchpad bug 57787 in partman-base (Ubuntu) "Obscure scary warning in installer." [Low,Triaged] https://launchpad.net/bugs/57787
<cjwatson> dholbach: I've done the first two.  For the last one, please add some kind of commentary to the merge requests explaining why
<dholbach> cjwatson, hrw said that it's OK to just get them into oneiric, but yeah, let me add it
<dholbach> done
<mdke> pitti: hiya
<pitti> hey mdke
<cjwatson> slangasek: so I think something complicated went wrong with the upstream branch import; if you want to fix that all up, I certainly wouldn't object, but if that isn't straightforward (I don't remember it being so) then feel free to drop Vcs-Bzr
<mdke> pitti: is that you looking at the gnome-user-docs uploads?
<pitti> yes
<pitti> had to reject maverick due to a version number conflict, see my bug followup
<mdke> pitti: ah, I haven't got that email yet, will wait for that. Thanks for looking at them though
<cjwatson> dholbach: OK, rejected
<mdke> pitti: I guess the existing versions in lucid and maverick also have the same version number though? (because the lucid package was copied over to maverick)
<dholbach> thanks cjwatson
<pitti> mdke: the lucid SRU worked fine
<mdke> pitti: if I use ~ubuntu2.1 as the version number, will that cause problems for people upgrading from lucid to maverick?
<mdke> (because lucid users will already have ~ubuntu3)
<pitti> mdke: ah, right; use 3.1 then
<mdke> pitti: cool, thanks
<mdke> pitti: uploaded. Thanks again for your help
<poolie> pitti: sorry; we could re-add 'bzr'
<poolie> i mean 'bzr br'
<pitti> slangasek: I forwarded your libxklavier patch to https://bugs.freedesktop.org/show_bug.cgi?id=37278, but I only gave a vague description as I didn't see the build failures myself; there might be some further request for info there
<ubottu> Freedesktop bug 37278 in General "Don't substitute other library's CFLAGS/LDFLAGS into pkg-config file" [Normal,New]
<cjwatson> zul: could you merge apache2, which will include rebuilding it against openssl 1.0.0?
<seb128> cjwatson, hey, do you plan to do a syncs round today?
<dholbach> cjwatson, james_w: can you please mark https://code.launchpad.net/~menesis/ubuntu/natty/wsgi-intercept/natty/+merge/58498 as irrelevant? it was superseded by https://code.launchpad.net/~menesis/ubuntu/natty/wsgi-intercept/natty/+merge/61212
<cjwatson> seb128: it's in progress
<seb128> cjwatson, thanks
<cjwatson> seb128: (or do you mean manual syncs?)
<seb128> cjwatson, both... ;-)
<cjwatson> autosyncs are in progress - I do plan to get to manual syncs though
<seb128> excellent, thanks
<cjwatson> dholbach: done
<dholbach> cjwatson, thanks!
<cjwatson> slangasek: could you merge wget?  it's part of the openssl 1.0.0 transition
<slangasek> pitti: thanks for the forward!  If in doubt, pkg-config upstream (i.e., Tollef) will be happy to explain
<slangasek> cjwatson: ack, queuing
<slangasek> queuing and going to bed, that is :)
<dholbach> Daviey, do you think it's worth getting https://code.launchpad.net/~abone/ubuntu/natty/procps/fix-for-753124/+merge/58905 into natty still?
<dholbach> (seems like -10ubuntu2 didn't solve the problem)
<Daviey> dholbach, looking
<Daviey> dholbach, Not entirely sure TBH... it does look kinda large... I'm missing what the impact of it is TBH.
<dholbach> Daviey, it looks like a cleanup of the patches because in 10ubuntu2 the patch was not really applied
<dholbach> Daviey, at least that's what I got from the description of the merge proposal
<Daviey> dholbach, yeah, that makes sense - but i missed if it meet SRU criteria.
<Daviey> dholbach, I have a call now - but will delve deeper after this.
<dholbach> Daviey, maybe just get it into oneiric then
<dholbach> Daviey, thanks muchly
<Daviey> no worries.
<dholbach> cjwatson, can you also mark this one as merged https://code.launchpad.net/~xaba/ubuntu/natty/pytrainer/bug-760885/+merge/58908? seems it got into natty-proposed and -updates already
<ubottu> Ubuntu bug 58908 in gnome-cups-manager (Ubuntu) "HP PSC 2110 printer PJL ENTER LANGUAGE=PCL3GUI (dup-of: 55828)" [Undecided,Invalid]
<ubottu> Ubuntu bug 55828 in cupsys (Ubuntu) "PJL output from 1.2.2 client over IPP" [Medium,Fix released]
<cjwatson> dholbach: the new revision mentioned at the end of the comment thread too?
<dholbach> cjwatson, hum, looks like not - I'll follow up on the merge proposal
<dholbach> cjwatson, oh no, it's included - it's just not documented in d/changelog
<lifeless> dholbach: oh hai; I've been meaning to let you know - we recently fixed searching for bugs w/ patches in lp
<lifeless> dholbach: which I believe was something important to you :)
<dholbach> lifeless, oh nice - what exactly did you change?
<lifeless> added an index
<lifeless> so that it works in non geologic time
<dholbach> do you still have a bug number for that somewhere?
<cjwatson> dholbach: generally, if you could add a comment to the merge before asking me, that would be good - I'd like to be able to operate mostly on autopilot for this kind of thing rather than needing to review
<dholbach> I'd like to understand it a bit better :)
<cjwatson> it won't scale otherwise
<dholbach> cjwatson, will do - that's entirely reasonable
<dholbach> thanks
<cjwatson> (well it obviously doesn't scale particularly well as it is, but ...)
<cjwatson> I'll just dump in the IRC conversation for this one
<dholbach> cjwatson, added a comment
<dholbach> and let's hope it's fixed soon :)
<cjwatson> done
<dholbach> thanks
<mpt> mvo, good morning, who do you think should be Approver for <https://blueprints.launchpad.net/ubuntu/+spec/foundations-software-maturity-ratings>?
<cjwatson> mdeslaur: you're touched-it-last for isc-dhcp - are you likely to have time to merge it?
<ScottK> dholbach: Seems SRu worthy
<nigelb> ev: I welcome the collection of ubiquity success/failure, if you need help building the public-facing website, I could possible pitch in and help
<dholbach> mdke, mako: CC meeting?
<ev> nigelb: wonderful. If you could post your support to the mailing list post, I'd greatly appreciate it, as it will otherwise get lost here
<nigelb> ev: sure, will do :)
<ev> @pilot in
* udevbot_ 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: dholbach, ev
<nigelb> ev: done :)
<ev> thanks
<barry> dholbach, mvo: any thoughts on the software-propoerties merge proposal?  is it worth looking at ~hodgestar's update?
<barry> lifeless: ping
<mdeslaur> cjwatson: are you offering to do it?
<seb128> could somebody from the security team review bug #782972
<seb128> ?
<ubottu> Launchpad bug 782972 in seed (Ubuntu) "[mir] seed" [Undecided,Incomplete] https://launchpad.net/bugs/782972
<seb128> some of the GNOME3 components are depwaiting on it
<cjwatson> stgraber: bug 778655 - looks like the new version is in Debian now?
<ubottu> Launchpad bug 778655 in lilo (Ubuntu) "Will need to Sync lilo 1:23.2-1 (main) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/778655
<cjwatson> mdeslaur: only if necessary - I'm drowning in library transitions
<mdeslaur> cjwatson: I'll try and get to it this week
<mvo> hey apachelogger - nice work on the dbusworker branch for software-properties! how do you feel about it? is it ready for merging?
<apachelogger> mvo: did I make that one? ^^
<cjwatson> mdeslaur: *nod*, thanks
<apachelogger> ah yeah
<apachelogger> mvo: needs some work & QA I think
<mdeslaur> seb128: I'll get kees to take a look when he arrives
<apachelogger> mvo: do you want it for oneiric?
<seb128> mdeslaur, thanks!
<seb128> mdeslaur, no real hurry but we are eager to get those GNOME3 bits to build ;-)
<seb128> (eog and gedit are the ones waiting on it)
<mdeslaur> seb128: argh! I need gedit! :)
<seb128> hehe
<mdeslaur> of course, now I'm wondering why an image viewer and a text editor need a _javascript library_...where's the world going to? :)
<mvo> apachelogger: that would rock, I would love to get the gtk version to no longer run as root
<seb128> mdeslaur, they need libpeas which is used for loading python and js code and use seed for js
<seb128> mdeslaur, in practice I don't think any .js code is in the archive or loaded but the loader is there
<apachelogger> mvo: I'll try to find someone to finish the work, though apparently my supply of python minions is a bit compromised ^^
<mdeslaur> seb128: I see...thanks
<seb128> yw
<mvo> apachelogger: haha, ok - I will also try to squeeze in a bit of time to help out
<mvo> barry: I check the diff out now
<barry> mvo: cool.  i did make a slew of comments in the mp, but haven't looked to see if he addressed them
<apachelogger> mvo: I might have found someone, if he has time ... I'll report back once I know more
<mvo> great, thanks apachelogger
<dholbach> barry, mvo: I'll leave that to you 2 :)
<debfx> pitti: I have added support for .svgz files to dh_scour. the patch is on bug #781810. could you have a look at it?
<ubottu> Launchpad bug 781810 in scour (Ubuntu) "dh_scour: optimize .svgz files" [Undecided,New] https://launchpad.net/bugs/781810
<broder> dholbach: the sleep/upower branches should have been rejected. i think at this point they might be caught in the SRU/branch re-targeting bug
<mpt> mvo, hi, did you see my question about who should be the Approver for <https://blueprints.launchpad.net/ubuntu/+spec/foundations-software-maturity-ratings>? (sorry I dropped off for a bit)
<pitti> debfx: oh, thanks! will do ASAP
<dholbach> broder, ok - can you add some kind of justification/explanation to the bug report?
<dholbach> err merge proposal
<broder> at least one of the patches already has an explanation from me as to why i don't think it should be merged
<dholbach> then Colin or James can reject it :)
<mvo> mpt: I'm happy to be the approver (if I'm not the assigne), otherwise probably slangasek
<dholbach> @pilot out
* udevbot_ 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: ev
<dholbach> I'll continue piloting later on
<dholbach> now it's lunch time
<mpt> mvo, ok, made slangasek the Approver and you the Assignee :-)
<lifeless> barry: hi?
<barry> lifeless: hi.  this page times out for me all the time.  thought you might be able to blacklist it or something?   (i think you asked me about this?) https://bugs.launchpad.net/ubuntu/+bugs?field.tag=python27
<lifeless> barry: sadly no, its really sick.
<lifeless> dholbach: bug 618392
<ubottu> Launchpad bug 618392 in Launchpad itself "Distribution:+patches slow 10% of requests timing out" [Critical,Fix released] https://launchpad.net/bugs/618392
<barry> lifeless: ah well.  it was worth a shot :)
<lifeless> night
<dholbach> thanks lifeless
<mpt> mvo, is it intended that the UI for <https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-update-manager-btrfs> is entirely in Grub? What if someone doesn't use Grub?
<cjwatson> mpt,mvo: I thought the agreement in that session was to put any non-trivial UI in the real system, specifically not in the boot loader
<mpt> cjwatson, ah, I see "GUI tool for selecting old snapshots (needs input from mpt what it looks like/where it should go)" in the session notes but not in the work items
<cjwatson> although I think "because trying to do the UI in the boot loader would suck" is probably a better objection than "what if someone doesn't use GRUB" in the case of btrfs :-)
<mvo> mpt: for oneiric we probably just go with a text ui in friendly-recovery
<mpt> mvo, what's friendly-recovery and how does one run it?
<cjwatson> it's the text menu you get if you select recovery mode from the boot menu
<mvo> mpt: its in the grub menu, the "recovery" option. its a small text UI to help recovery from various aspects of breakage
<rbelem> dholbach, ScottK, i think that patch was applyed already
<zul> cjwatson: yep im just waiting for apr as well
<cjwatson> zul: OK, I synced that a little while ago so it shouldn't be too long - thanks
<zul> cjwatson: np
 * pitti suspects cjwatson's upload karma can only be measured in powers of ten these days
<micahg> dholbach: I should talk to chrisccoulson about that, I think there might have been a better solution
<cjwatson> heh :)
<cjwatson> pitti: I still only have about a quarter of your karma though
<cjwatson> where does it all come from?  language packs?
<cjwatson> or are you just awesome?
<mpt> mvo, ok, it's up to you whether you add a work item for me to design something there
<pitti> cjwatson: I think it still misattributes langpack uploads to me
<pitti> cjwatson: presumably because it identifies the langpack-builders GPG key as being an alter ego of me (which it kind of is)
<pitti> I filed a bug about it ages ago
<cjwatson> ah yes
<mvo> mpt: ok, I think for now it should be fine the text ui will be pretty borning
 * Sweetshark is getting close to a real work environment: a) local git mirror -> check b) local tarball mirror -> check c) local CI builder for master -> running d) local CI builder for release branch -> tbd ...
<andyrock> hi, i've a problem in transition from gtk2 to gtk3. Is it the right place for asking support?
<ScottK> andyrock: No.  Support is in #ubuntu.
<mpt> mvo: Sorry to keep bugging you. :-) Does <https://blueprints.launchpad.net/ubuntu/+spec/foundations-o-apt-mirror-method> require any design work for the "UI support [in] software-properties"?
<jamespage> doko: are you looking at bug 779174? just noticed your comment...
<mvo> mpt: yes, some UI selement that essentially says "pick the best one automatically"
<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
<doko> jamespage: yes
<highvoltage> a bit off-topic, but the awesome scale makes it worth while posting here:
<highvoltage> http://linux.slashdot.org/story/11/05/17/0242244/Boot-Linux-In-Your-Browser
<jamespage> doko: so is the fix for that issue likely to be in openjdk?
<doko> jamespage: yes, see my last comment for a work around
<stgraber> cjwatson: it was on my post-UDS todolist. I'll have a look now. Thanks for the reminder.
<jamespage> doko: right-oh; I'll stop digging....
<doko> the main issue is that we'll see such breakage will probably occur with other multiarch conversions too
<jamespage> doko: I suspect so
<axp2> highvoltage: that's quite cool, probably has some interesting applications when it is more developed too
<stgraber> cjwatson: bug updated
<mvo> highvoltage: I have to say that I'm blown away by how fast it is
<Satoris> Installing the Gnome 3 PPA makes my machine (or actually VirtualBox install) fail to boot. Is this a known issue?
<highvoltage> mvo: yes, me too!
<jamespage> hey - can anyone help me understand why I can find libjibx1.2-java in Debian but not in Ubuntu?  I can find a launchpad page in the Ubuntu project but its completely empty...
<cjwatson> jamespage: it's in the list of new packages that haven't been processed yet.  I take it you want it?
<jamespage> cjwatson: ultimately yes but it can wait; causing a FTBFS elsewhere at the mo
<jamespage> cjwatson: thanks for looking :-)
<cjwatson> jamespage: ah, yes, I see why we didn't process it - is this supposed to be replacing libjibx1.1-java, currently in main?
<jamespage> cjwatson: hmmm - not sure - I'll take a look
<cjwatson> (which also ships a libjibx-java binary)
<cjwatson> E: libjibx-java is in main but its source (libjibx1.2-java) is not.
<cjwatson> this is overridable, but preferably under instructions by somebody who knows about the packages in question
<sconklin> cjwatson: do you have anything to add to https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/747090 ? I'm about to respin the Natty stable update and will be reverting some patches, not sure whether this should be among them
<ubottu> Ubuntu bug 747090 in Ubuntu Translations "wrong return address sometimes pushed for INT in kvm (not qemu)" [Low,Triaged]
<cjwatson> sconklin: I'll test it now - I couldn't do it at UDS because my ISO images were on the external disk for which I'd forgotten the power adapter
<sconklin> cjwatson: thanks!
<jdstrand> dholbach: I am not actively working on 723830 (I don't think I have the necessary expertise to ack the patch). I was just trying to make sure it was still a problem
<matttbe> Hello,
<matttbe> It seems that Cairo-Dock BZR branches on Ubuntu (lp:ubuntu/cairo-dock & lp:ubuntu/cairo-dock-plug-ins) are not up to date (and broken?).
<matttbe> What can I do and/or who can I contact?
<matttbe> Note that this bug has already been reported: https://bugs.launchpad.net/udd/+bug/704694
<ubottu> Ubuntu bug 704694 in Ubuntu Distributed Development "import has failed with cairo-dock-plug-ins" [High,Confirmed]
<matttbe> I can see the problem there: http://package-import.ubuntu.com/status/#analysis
<matttbe> but I don't know what can I do to resolve this problem
<cjwatson> sconklin: verified now, so please keep that patch :-)
<sconklin> cjwatson: great, thanks! I hate pulling them
<cjwatson> (a whole half-hour before the Brad-stated deadline)
<sconklin> pitti: I have a question about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/735171 - you wrote "Marking as verification-failed, but as this is not a regression, this doesn't block -updates migration.", does that mean that you don't think the patch should be reverted?
<ubottu> Ubuntu bug 735171 in linux (Ubuntu Natty) "driver ath9k is too slow or not responding" [Undecided,Fix committed]
<pitti> sconklin: if you are about to upload a followup kernel, then I'm fine with reverting it (it's safer, of course)
<pitti> sconklin: it just means that if would have been the only problem, it wouldn't block -updates migration
<sconklin> pitti: ok, thanks there is also this one which needs to be reverted, best I can tell - https://bugs.launchpad.net/ubuntu/+source/bluez/+bug/700292
<ubottu> Ubuntu bug 700292 in bluez (Ubuntu Natty) "Bluetooth keyboard after natty upgrade not working" [Undecided,New]
<pitti> sconklin: *nod*
<mvo> pitti: if you have a moment, could you please check the natty-proposed queue? there is a software-center 4.0.2 there, one is old, one from a couple of minutes ago, the old one can be rejected now. would be nice to get the new one reviewed because for new installs the review stats are currently not showing
<qchn> Coi
<pitti> mvo: there is just one software-center there
<pitti> mvo: https://launchpad.net/ubuntu/natty/+queue?queue_state=1
<cdbs> mvo: Looks like the new one superseeded the old one... ?
<qchn> 22.  #kapy          â16:19:50  cdbs | mvo: Looks like the new one superseeded the old one... ?                                                                                                      â bantu
<qchn> Whoops, sorry.
<qchn> emberassing.
<mvo> pitti: oh, how odd. but in any case the new one is the right one :)
<micahg> matttbe: the bug is sufficient to have someone look at it, the lack of branch update doesn't block further uploads
<qchn> Does anyone know how to decrypt luks over the network and start this script with initramfs?
<pitti> mvo: you didn't mean the aptdaemon which is in the queue? there's already an unverified aptdaemon in -proposed, I wanted to get that to -updates first
<pitti> or you reupload with -v, if it's urgent
<mvo> pitti: thanks, aptdaemon is not super urgent, fix is pretty small etc, but it should be fine to wait
<dholbach> rbelem, you're right
<dholbach> cjwatson, james_w: can one of you please mark https://code.launchpad.net/~rbelem/ubuntu/natty/kubuntu-mobile-default-settings/plasma-mobile-patches/+merge/58018 as merged?
<broder> cjwatson or james_w: could you also reject https://code.launchpad.net/~psusi/ubuntu/natty/upower/sleep/+merge/54093 https://code.launchpad.net/~psusi/ubuntu/natty/indicator-session/sleep/+merge/54094 and https://code.launchpad.net/~psusi/ubuntu/natty/gnome-power-manager/sleep/+merge/54095 ?
<james_w> broder, https://code.launchpad.net/~psusi/ubuntu/natty/indicator-session/sleep/+merge/54094 was approved, why reject it?
<broder> james_w the 3 merges are tied together. it's only correct if the other two are accepted, and they weren't
<james_w> ok
<broder> thanks
<dholbach> @pilot in
* udevbot_ 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: ev, dholbach
<broder> are there any examples on how to migrate a sysv script that uses /etc/default to upstart? i.e. in terms of migrating the /etc/default settings
<broder> (i'm trying to evaluate https://code.launchpad.net/~vanvugt/ubuntu/oneiric/mediatomb/fix-212441/+merge/60574 . i'm not particularly fond of the approach, but not sure if there's a better example i can point the submitter at)
<micahg> broder: that /etc/default change should happen in Debian, not Ubuntu
<broder> micahg: huh? he's trying to convert the package to upstart, and Keybuk says that upstart jobs shouldn't use /etc/default
<micahg> broder: ugh
<micahg> broder: do we normally carry a similar diff for other packages with upstart?
<broder> honestly, i have no idea. but i think it could be a good idea in this particular case, since they're running into a race condition from networking devices not being up
<micahg> broder: also, since there is upstart in Debian, just not the default, I'd like to try to get that into Debian first
<broder> hmm...i bet that debian's not interested in Keybuk's belief that upstart jobs shouldn't use /etc/default...
<broder> also, the policy to ship config jobs for multiple init systems isn't finalized, is it?
<micahg> broder: not yet, but that can be worked around in debian/rules
<broder> eww :)
<matttbe> micahg: thank you :) . But if I want to propose a new version, I've to create a debdiff, join some files, etc. instead of simply launch bzr merge-upstream...
<apw> cjwatson, do we have oneiric dailies yet ?
<ogra_> lol
<mdeslaur> slangasek: any objections to me killing the hurd compatibility patch in pam security updates?
<ogra_> apw, we're (well, currently colin is)  switching the live builder tool, that will take a bit i guess
<matttbe> james_w: Hello and sorry to ping you but is it possible to repair Cairo-Dock bzr branches? (lp:ubuntu/cairo-dock & lp:ubuntu/cairo-dock-plug-ins). My bug report has been marked as duplicated of this one: LP: #494481
<apw> ogra_, oh ok, hrm
<james_w> matttbe, hi, that's probably possible to fix
<matttbe> james_w: great! and can I do something?
<james_w> matttbe, http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/cairo-dock/oneiric/revision/23 <- what did you do to create that revision?
<poolie> ev: that's a great concept regardless of the various difficulties
<matttbe> james_w, yes I guess I forgot to use bzr merge-upstream for this one...
<james_w> matttbe, I'm not sure what the best way to recover from this is
<james_w> matttbe, an easy one is to uncommit your revisions back to the last-good one, and have the importer take care of the new versions
<james_w> that obviously loses your history
<matttbe> james_w: I'm sorry but at this time I though I had to use uscan as before
<rbelem> dholbach, :-)
<james_w> the other solution is to decide where to put that missing tag, but as merge-upstream wasn't used there isn't a "correct" place to put it
<matttbe> james_w: but I prefer to lose this history and use the branch. but yes, if we can simply add these missing tags, it's better
<matttbe> james_w: note that if I add a upstream tag, the bzr merge-upstream command remove the debian directory. But it's not a problem if it removes this folder only this time
<matttbe> james_w: this is what I said there: https://bugs.launchpad.net/udd/+bug/758032
<ubottu> Ubuntu bug 758032 in Ubuntu Distributed Development "Tags are wrong in lp:ubuntu/cairo-dock" [Undecided,Incomplete]
<broder> micahg: it looks like there are already a handful of packages in universe that ship upstart, though i suspect that most/all of them are ubuntu-native and not merged from debian
<ev> poolie: thanks!
<slangasek> mdeslaur: ah, I suppose not... :)
<mdeslaur> slangasek: unless you're willing to rewrite it before I publish :)
<mdeslaur> slangasek: I also gather you'd rather not turn off pam_env on user home directories?
<slangasek> mdeslaur: is the security bug *in* the hurd patch, or is it just caught in the crossfire?  i.e., is another fix needed for Debian unstable?
<slangasek> mdeslaur: turn off pam_env> it's not a behavior change I'd like in a security update, but we could change the default to not check user environment files going forward, to match upstream
<mdeslaur> slangasek: ok, that's what I was going to do
<mdeslaur> slangasek: the hurd patch is caught in the crossfire...the following commits have moved around all the privilege dropping code: http://paste.ubuntu.com/609063/
<mdeslaur> slangasek: half of those commits went in after 1.1.2, so debian unstable needs them also
<slangasek> ok
<mdeslaur> slangasek: I'll let you know once I've done natty which ones are missing in unstable
<broder> SpamapS: ping? what was the end result of the /etc/default discussion you had on ubuntu-devel a few months back? have you actually used that code anywhere yet?
<slangasek> mdeslaur: thanks
<broder> (no rush - feel free to wait until the end of your meeting)
<SpamapS> broder: definitely not, there was no end result.. we kind of deferred the discussion. At UDS we all suggested that we actually measure the impact of sourcing default files before we abandon them completely.
<SpamapS> s/we all/somebody/
<dholbach> @pilot out
* udevbot_ 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: ev
<micahg> broder: so in light of what SpamapS said, I'd rather not make such a divergent change unless there's a decision
<broder> SpamapS: ok. i can certainly make an argument that with ureadahead, there shouldn't actually be any sort of additional disk hit, which i think means that the /etc/default things is purely a philosophical and stylistic discussion
<broder> but yeah, i think keeping the /etc/default file for now is fine
<SpamapS> broder: certainly for new things that we create, use env .. but for sanity in syncing w/ debian, probably easier to just keep sourcing the default file.
<bakarat> been an ubuntu user since dapper (if memory serves) and i just gotta say: so far (not been using it for very yet though), unity kicks ass
<bakarat> great job!
<hv> so, what's the deal with gnome-settings-daemon?
<hv> it segfaults :(
<seb128> hv, what distro version?
<hv> oneiric
<hv> apparently it has an issue with libgnomekbd7, as far as I can guess.
<seb128> hv, don't use oneiric yet ;-)
<seb128> but otherwise there is a known issue in the indicator code I think, check with rodrigo on #ubuntu-desktop maybe if you can
<hv> heh, someone has to use it before release ;)
<hv> ok, thanks.
<seb128> well right now it's rather "it's broken and has no theme and we know about it"
<seb128> it needs work, we don't really lack feedback, we basically know quite some things are broken ;-)
<hv> but is it in the indicator? the segfault I get relates to xkb, xklavier, and libgnomekbd7.
<seb128> hv, could be another one, the new libgnomekbd just landed today
<seb128> hv, get a stacktrace if you can that would be useful
<hv> well, the stacktrace (not mine, someone else's with similar issue) is already on launchpad.
<seb128> hv, can you give the bug number?
<hv> #649809, see comment #191 (3rd from the end)
<hv> https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/649809
<ubottu> Ubuntu bug 649809 in gnome-settings-daemon (Ubuntu Natty) "the session settings manager can try starting before the login screen one exits" [Medium,In progress]
<hv> I suspect the latest comments are not exactly aligned with the title. maybe they need their own new bug report.
<seb128> right, that should go to a new bug report
<cr3> hi folks, what might cause someone upgrading from maverick to natty to have files under /usr/lib/python2.6/dist-packages/project.. but not /usr/lib/python2.7/dist-packages/project...?
<tumbleweed> cr3: the package may (incorrectly or correctly) say that only supports 2.6 or <= 2.6. Or it may just need to be rebuilt (if it uses dh_python2)
<tumbleweed> cr3: which package?
<stgraber> slangasek: hey, I'm preparing a test setup for IPv6 so I can easily test it in Oneiric. I currently have the following networks setup (http://paste.ubuntu.com/609117/), anything I'm missing in there?
<cr3> tumbleweed: checkbox
<cr3> tumbleweed: XS-Python-Version: current, is that sensible?
<slangasek> stgraber: I don't understand the shorthand.  What does each line represent?  A machine, a network interface?
<tumbleweed> cr3: we try not to use that if possible, as that'll only build for one version, not all supported versions
<stgraber> slangasek: each line is a bridge on my laptop to be used with libvirt. I have a single VM that's plugged on all of them and doing the dhcpv4/dhcpv6/radvd depending on what's supposed to be on the bridge
<slangasek> stgraber: we probably need more test cases that are explicitly related to broken IPv6 - e.g., ipv6 advertised but no packets getting routed; ipv6 advertised but DNS server misbehaves when asked; that sort of thing
<slangasek> stgraber: aha, got it
<mpoirier> slangasek: aside from barry, who else can I ask a phyton question ?
<stgraber> ah, interesting, I guess I can simulate the "broken network" relatively easily by writting a few scripts for my "router" VM, so one can simulate these qite easily
<slangasek> stgraber: some of these cases require different static configurations of the VM, how do you plan to do this with only one VM?
<slangasek> mpoirier: the channel is dense with python expertise, you could just ask the question here :)
<stgraber> I currently have a bunch of .xml files for libvirt creating all of these bridges, will have the same for the router VM + at least documentation on how to setup the router so someone can easily replicate the setup
<slangasek> (electrons : electric fields :: python : pythic field?)
<slangasek> stgraber: but don't the static configs require changes to the *client* VM, not just the router VM?
<tumbleweed> cr3: aah. it uses python-central. That shouldn't require a rebuild, it should just support whataver the current default python version is (pyversions -d). BTW: We are trying to get rid of python-central and replace it with dh_python2.
<stgraber> slangasek: yep, the idea is to have a test network. The client part will have to be done with one VM being moved from a bridge to another and reinstalled/reconfigured depending on the configuration (at least for the static cases)
<slangasek> ok
<stgraber> slangasek: or have one VM per bridge (if you have enough resources)
<cr3> tumbleweed: I could migrate to dh_python2 for oneiric. for natty, I suspect this is not the only package relying on python-central, is there something I should sru to improve user experience of people upgrading?
<tumbleweed> cr3: no need to do anything for natty. Indeed it's not the only package. There's a goal to convert all the packages on the CD for oneiric (there was a UDS discussion). All python-central packages in debian will already have bugs filed against them, encouraging micration.
<cr3> tumbleweed: by the way, if python-central "shouldn't require a rebuild", I'm not sure I understand why the package is failing to import some of its dynamic modules. very strange...
<tumbleweed> cr3: trying a dist-upgrade from maverick -> natty with it installed...
<cr3> tumbleweed: thanks!
<tumbleweed> cr3: checkbox is importable for me in python2.7 after the upgrade
<cr3> tumbleweed: can you try running this: for py in `pyversions -s`; do echo $py; echo '__import__("checkbox_gtk.gtk_interface", None, None, [""])' | $py; done
<tumbleweed> cr3: aah, I was looking at checkbox not checkbox-gtk. Of course we don't expect it to be importable in 2.6
<cr3> tumbleweed: so, if the python executable points to python2.6 for some reason, hell might break loose, right?
<tumbleweed> cr3: but that wouldn't happen unless the user breaks their own system. The python package tells python-central to rebuild those symlink farms when the default python version changes
<mterry> Does anyone know much about -Bsymbolic-functions?  It's causing the libpeas test suite to fail, but not entirely sure why yet
<cr3> tumbleweed: heh, not always easy to troubleshoot what people do on their systems :)
<tumbleweed> the usual hint for something like this is the appearence of /usr/local somewhere in their traceback
<keks-n> sup
<keks-n> Guys, I have some problems with uploading to ppa
<keks-n> dput says "Successfully uploaded packages.", but I cann't see my package in the build queue
<stgraber> keks-n: as it's a PPA and not the main archive, you probably want #launchpad
<broder> keks-n: #launchpad is a better place to ask about ppa issues, but it takes a few minutes for packages to migrate from uploading into the build queue
<keks-n> thanks
<hallyn_> kirkland: jjohansen: regarding http://summit.ubuntu.com/uds-o/meeting/server-o-ecryptfs-testsuite/, the first block is about ecryptfs enhancements.  Should I write those up as actions in the ecryptfs-testsuite blueprint, or do you want to put it somewhere else?
<jjohansen> hallyn_: I am fine with in the blueprint
<hallyn_> jjohansen: ok, will put them there, thanks
<maco> just saw unity in action for the first time. the user and i were both confused. why is there what looks like a "zoom" icon (magnifying glass with + sign) that opens up the application list?
 * vish points maco in the direction of #ayatana
<rootuser23> looking for a command so i can send mails trough ubuntu's terminal pls
#ubuntu-devel 2011-05-18
<Keybuk> isn't natty's git-core package missing a dpkg pre-depends for mainthelper?
<cjwatson> Keybuk: where does it use it?  I'm not seeing that
<Keybuk> preinst
<Keybuk> https://gist.github.com/c5e2da31a7db46b46243
<Keybuk> (installing natty git-core on lucid)
<broder> what's sensitive about apport bugs from kernel panics? the core dump?
<cjwatson> Keybuk: oh, git, not git-core
<cjwatson> Keybuk: yes, that looks like a bug to me as you describe
<Keybuk> would you like me to file the bug?
<cjwatson> yes please
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=618708
<ubottu> Debian bug 618708 in git "git: needs versioned depends on dpkg" [Normal,Fixed]
<cjwatson> so fixed (albeit IMO oddly) in oneiric, but could use an SRU.  I don't see why we couldn't just add the Pre-Depends in an SRU, personally.
<cjwatson> though I suppose that would be more inconvenient for the use case you described than the solution adopted in oneiric
<cjwatson> so maybe a direct backport would be better
<Keybuk> yeah, this was just a "clearly needs the p-d, but I should backport"
<cjwatson> broder: I expect that the core dump could contain all sorts of random sensitive things from whatever you happened to be doing ...
 * cjwatson crashes, not that way
<bcurtiswx> all you quilt experts, when i'm in a bzr bd-do and i'm using quilt to fix patch issues, when i'm done what do I do to make sure my changes are sabed ?
<bcurtiswx> saved*
<RAOF> quilt refresh for each changed patch (before you pop).
<pitti> Good morning
<sladen> you're up early pitti
<pitti> sladen: yeah, my wife gets up at 6 for work, so I'm doing the same
<slangasek> my wife gets up at 5 for work, I try not to still be up when she does :-P
<pitti> I could sleep longer as well, but then I'd still work for a long time when she's already back home
<pitti> so I try to synchronize better
<pitti> slangasek: at least you could say good morning :)
<slangasek> yeah, but it would be better if I were actually doing what you do :)
<didrocks> good morning
<dholbach> good morning
<Laney> hiya
<dholbach> ev, we made quite a bit of progress on http://reqorts.qa.ubuntu.com/reports/sponsoring-stats/ yesterday it seems :)
<dholbach> there's still quite a bit of clean up to do though
<ev> dholbach: that was surely mostly you - I got largely bogged down in phone calls and firefighting yesterday :-/
<ev> @pilot out
* udevbot_ 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:
<ev> pitti, mdz, cjwatson, other tech board people: could someone let my post through to the mailing list?
<pitti> will do
<ev> thanks!
<pitti> the "ÎÎ½ÏÎ¿ÏÎ¯ÏÏÎ·ÎºÎ±Î½ ÏÎ± Î³Î¿Î½Î¯Î´Î¹Î± ÏÎ·Ï ÎºÎ±ÏÎ¬Î¸Î»Î¹ÏÎ·Ï" one, right? :-)
<ev> hah, but of course
<pitti> ev: done
<ev> thanks!
<cjwatson> mdeslaur: stealing the fuse merge - I need it to unblock grub2 builds
<cjwatson> (sorry, only occurred to me that you were TIL after I'd already committed to lp:ubuntu/fuse ...)
<mpt> ev, https://blueprints.launchpad.net/ubuntu/+spec/crash-tracker
<maxb> Hello ~ubuntu-sru people. bug 707075 has been used once to carry a bzr SRU into maverick. Now we're doing a related SRU into lucid. Can someone verify that I've done things appropriately such that 707075 is showing as needing attention in whatver way ~ubuntu-sru tracks bugs needing their attention?
<ubottu> Launchpad bug 707075 in bzr (Ubuntu Lucid) "[sru] lp-propose fails with a 404 error" [Undecided,New] https://launchpad.net/bugs/707075
<ev> thanks mpt
<brendand> mvo - can you remind me how to use a specified Glade .ui file in when running update-manager?
<brendand> mvo - i think you told me before, but i forget
<brendand> mvo - heh, i found it in scrollback. it's ok
<mvo> brendand: ok, sorry for the delay, was away for lunch
<GunnarHj> Hi all, any backporter available to approve a fix of bug 778869 in lucid-backports and maverick-backports?
<ubottu> Launchpad bug 778869 in language-selector (Ubuntu Natty) "[natty] fontconfig-voodoo -a does not work in Japanese locales" [Undecided,In progress] https://launchpad.net/bugs/778869
<micahg> GunnarHj: still has to be in natty first :)
<GunnarHj> micahg: It is, isn't it?
<micahg> GunnarHj: only saw it in oneiric ATM
<GunnarHj> micahg: https://code.launchpad.net/~ubuntu-core-dev/language-selector/natty Don't know why it hasn't showed up in natty-proposed yet (will ask somebody to look at it), but for the purpose of approving the backports you can consider it to be in Natty, right?
<micahg> GunnarHj: no, the idea is that on upgrade, people not lose backport functionality
<micahg> and -proposed isn't on by default
<micahg> s/backport/backported/
<lool> cjwatson: Oy; would you mind binary NEW-ing python-linaro-image-tools?  it replaces python-linaro-media-create and python-hwpack
<GunnarHj> micahg: Aha, that does make sense. But in this case it is not about new functionality, but a fix of a regression due to previously backported changes (because of them the fontconfig feature is partly broken for Japanese and Korean users). So, for that reason, shouldn't it be more important to backport the fix asap than waiting til it reaches natty-updates?
<micahg> GunnarHj: well, I'll leave that for broder or ScottK to decide since bug fixes in -backports is slightly unusual
<GunnarHj> micahg: Ok. As usual, the backports I'm involved in are special cases. :) Do you contact any of them, or should I?
<micahg> GunnarHj: they were highlighted with my comment and will respond when available
<GunnarHj> micahg: Right. Thanks!
<micahg> GunnarHj: thank you for helping to improve the archive :)
<GunnarHj> micahg: Yeah, I don't want people to encounter problems because of something I missed...
<pitti> ah, Lennart proposed systemd as GNOME dependency -- we had that coming, I guess
<Chipzz> pitti: didn't I complain about that a couple of weeks ago?
<Chipzz> "told you so" :S
<pitti> Chipzz: no surprise -- it was extensively discussed a few months ago at plumber's, and I also threw that into the discussion
<Chipzz> hrmyeah
<Chipzz> I think I'll refrain from expressing my feelings about Lennart since that would probably violate a lot of the CoC
<Chipzz> anyway, I hope the gnome ppl have the common sense to reject his proposal
<pitti> Chipzz: why should they reject it?
<pitti> from upstream's POV it would make sense to share code instead of duplicating it in gnome-session
<pitti> and we ourselves talked about using upstart's new per-user jobs for session handling
<Chipzz> because the init daemon is not part of gnome, neither should it be
<pitti> Chipzz: architecturally, gnome-session and init have a lot in common
<Chipzz> yes, but by forcing systemd down every distributions throat you're also causing a lot of unwanted side-effects
<Chipzz> this doesn't affect just gnome, now does it?
<pitti> it'll certainly make it harder for non-Linux platforms or non-systemd ones, yes
<pitti> but to be fair that road has been taken years ago with the move away from hal to udev/udisks/upower
<Chipzz> doesn't mean we should go further down that road
<pitti> except for that we were on the winning side (and even worked on that migration ourselves heavily)
<pitti> Chipzz: certainly not
<Chipzz> UNIX != Linux
<ScottK> micahg: Since there's already a backport, I think bug fixing it while the SRU is in progress is fine.
<ScottK> It is a bit of a special case.
<pitti> ScottK: my understanding is that all the followup -backport uploads we had just kept up with -security and -updates, and don't by themselves introduce new "backported features", so they ought to have an implicit approval?
<ScottK> pitti: I'm not entirely comfortable with implicit approval, but certainly if the change is SRUable, I'm willing to accept that as good enough for backports.
<seb128> pitti, the email from lennart is sort of a follow up of UDS discussions, we asked desrt to make sure that if GNOME was to use systemd features the depends wouldn't be added without a public discussion which is what is happening
<pitti> seb128: yes, that's how I understand it
<seb128> pitti, desrt wants to use XDG_RUNTIME_DIR for dconf at least
<pitti> and we can certainly use the dbus backend helpers
<pitti> they shouldn't conflict with anything else
<seb128> pitti, I especially pointed to desrt that the systemd depends will be an issue for ie debian-bsd
<pitti> and sooner or later we'll have the source at least in universe anyway
<seb128> so GNOME should be clear if they decide to screw non linux systems and non systemd distros
<pitti> ScottK: SRUable> I meant in the stronger sense, applying patches which were already SRUed or USNed
<pitti> seb128: non-linux> cf. dependency on udev and friends
<ScottK> Yes
<ScottK> That's fine.
<Chipzz> also tbh IMO there's things to be said about this starting to reek a lot like vendor lock-in
<pitti> GunnarHj: ^ so, it's just a sponsoring issue, not approval
<seb128> pitti, well still the discussion is an opportunity for those who have issues with the depends to argue it should stay optional
<pitti> seb128: oh, perhaps I got misunderstood -- I'm totally in favor of having this discussion on desktop-devel@
<ScottK> pitti: I just added a comment in the bug where I said I was in favor, but it should be tested in the target environment.
<ScottK> e.g. lucid/maverick
<pitti> *nod*
<micahg> ScottK: I thought another round of testing was required before accepting those backports for security/SRU fixes
<micahg> oops
<micahg> nm
<ScottK> micahg: Agreed.  It should be tested since we don't have the barrier of -proposed before it hits end users.
<micahg> ScottK: I missed that you already said that :)
<ScottK> No problem.
<ogra_> cjwatson, do you have a spec for the live-helper stuff ? NCommander asked me to add a dependency for some of our specs
<cjwatson> ogra_: NCommander has the details already
<ogra_> that doesnt help my specs :)
<cjwatson> I guess each one of your team is going to ask me in turn? ;-)
<ogra_> he said you could only give him old info
<ogra_> (a natty spec or so)
<cjwatson> sure, it's in other-foundations-n-cd-build-speed, but that's still open and there's no reason you can't depend on it
<ogra_> if thats the right one i'll use it indeed
<ogra_> good, sorry for bothering
<cjwatson> it was discussed this UDS but I can't remember in what session
<ogra_> (i understood him that aou were planning to have a more recent one, else i wouldnt have asked)
<ogra_> *you
<ogra_> communication flaw apparently
<cjwatson> the only difference would be that the new spec would be *-o-* - the action item would be the same
<cjwatson> so it shouldn't make a difference from your POV
<ogra_> yeah
<jamespage> cjwatson: re the discussion we had re libjibx1.2-java and it absence from the archive yesterday;
<jamespage> cjwatson: I've looked at the deps and it would have caused potential issues with the current version of eucalyptus
<jamespage> cjwatson: I've resolved that issue (and tested with the other rdep in universe - freemind); so I think that it would be OK to allow libjibx1.2-java into universe.
<cjwatson> what's "it" here?
<jamespage> sorry - it = the libjibx-java provided by libjibx1.2-java
<cjwatson> ok
<jamespage> the two versions are not forwards or backwards compatible hence why they have been packaged separately.
<cjwatson> but both eucalyptus and freemind will now be OK with the newer version?
<jamespage> no - they use the libjibx1.1-java package so won't go near the new version
<GunnarHj> ScottK, pitti, micahg: Added a comment about tests of the backports proposals to bug 778869. They were tested in Lucid respective Maverick.
<ubottu> Launchpad bug 778869 in language-selector (Ubuntu Natty) "[natty] fontconfig-voodoo -a does not work in Japanese locales" [Undecided,In progress] https://launchpad.net/bugs/778869
<cjwatson> jamespage: ah, you only just uploaded that eucalyptus change
<ScottK> GunnarHj: Then it's just a matter of sponsoring then.
<jamespage> cjwatson: yes - last 10 minutes or so (zul did it for me)
<cjwatson> jamespage: let me wait for that to hit the archive, then, so that the tools don't need to be overridden
<GunnarHj> ScottK: Ok, thanks.
<jamespage> cjwatson: great
<dholbach> ScottK, I took the liberty of copying the work items of the backports spec into the blueprint whiteboard
<ScottK> dholbach: Thanks.
<dholbach> (just trying to get an idea how bad my workload is going to be this cycle ;-))
<ScottK> dholbach: Looking at your bottlenecks spec, "open backport requests" could look at three things potentially: Requested, not tested (New/Incomplete), Tested not approved (Confirmed/Triaged), Approved not done (In Progress).
<dholbach> ScottK, thanks for letting me know - I'm happy to track all of them - for now I'll just copy the information to my notes, so I don't forget
<dholbach> I'm sure I'll get back to you once I start working on it :)
<ScottK> OK.
<dholbach> thanks
<broder> ScottK: are you using Incomplete for "needs testing"?
<ScottK> broder: I use it for "I looked at it and it's not ready", which usually amounts to needs testing.
<micahg> ScottK: on the subject of backports, if backports were to open after feature freeze, would the barrier for entry be the same as normal backports?
<ScottK> micahg: Except for the must be in the development release first part, I'd imagine yes.
<Laney> modulo "available in the development release"
<Laney> Does NEW work for -backports?
<micahg> ScottK: k, that's what I was hoping for :)
<ScottK> Yes.
<ScottK> (re New)
<ScottK> This whole concept would have to be reviewed/approved by the tech board before we could do it.
<sabdfl> i have a call at 1800 so won't deliay
<maco> ooh i wonder if we'll hit 100,000 open bugs by the end of oneiric
 * cjwatson wonders if that will happen before or after armel builds catch up
<lool> slangasek: Oy; https://launchpadlibrarian.net/70129102/buildlog_ubuntu-lucid-i386.qemu-linaro_0.14.50-2011.04-1-0ubuntu1~ppa10.04.1_BUILDING.txt.gz (qemu-linaro lucid backport in linaro-maintainers/tools PPA) shows Pre-Depends: dpkg >= 1.15.7.2 for qemu-kvm-extras-static, but that dpkg isn't available in lucid; do you know what's happening there?
<cjwatson> lool: linaro-image-tools> looking
<cjwatson> sorry for the delay
<Laney> 10 hours, not bad
<slangasek> lool: not offhand, but let me check my marvelous bzr history
<lool> cjwatson: thanks!
<cjwatson> lool: wouldn't a Conflicts/Replaces be helpful to guide people's apt instances towards knowing to install this package instead?
<slangasek> lool: that's for dpkg-maintscript-helper support; sorry, I didn't think to look at if that version was in lucid when doing the ppa upload, I guess that explains some of the behavior that's been reported to me
<cjwatson> I guess the dependency from linaro-image-tools should do that
<lool> cjwatson: there's a breaks/replaces
<slangasek> lool: it's effectively a transition package anyway, so I'm not sure it's worth hacking around?
<lool>  Breaks: qemu-kvm-extras-static (<< 0.13.50-2011.02-0~rc1-0ubuntu1)
<lool>  Replaces: qemu-kvm-extras-static (<< 0.13.50-2011.02-0~rc1-0ubuntu1)
<lool> cjwatson: in qemu-user-static
<lool> cjwatson: oh sorry, mixing two conversations
<lool> cjwatson: I guess it could; technically the other packages aren't broken
<lool> cjwatson: I am happy to add them
<cjwatson> yeah, up to you I guess, at any rate not a reject matter
<cjwatson> lool: accepted
<lool> cjwatson: thanks for the review
<lool> slangasek: well apparently this confuses apt for lucid users
<poolie> could someone please review this bzr MRE SRU for me? https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/707075
<ubottu> Ubuntu bug 707075 in bzr (Ubuntu Lucid) "[sru] lp-propose fails with a 404 error" [Undecided,New]
<lool> slangasek: But it looked like a bug somewhere; is this pre-depends in the packaging?  I thought it was generated by some tool we should fix, or perhaps the result of copying binaries between archives
<slangasek> lool: no, it's in the packaging - it's the required pre-dependency if you're going to use dpkg-maintscript-helper, which didn't exist before that
<lool> slangasek: aha
<cjwatson> though it isn't necessarily in the packaging - if you use debhelper >= 8.1.0 and debian/package.maintscript, dh_installdeb will add that Pre-Depends
<cjwatson> as long as you remembered to add Pre-Depends: ${misc:Pre-Depends} that is
<lool> slangasek: I told this user to use apt-get install qemu-user-static qemu-kvm-extras-static-; I guess we could revert this pre-depends in lucid
<cjwatson> I mean, not necessarily in the packaging for all packages
<lool> hmm that might indeed be a good way to use the same source but not generate that pre-depends in the lucid build
<cjwatson> well, no
<cjwatson> not unless you make debhelper emit a load of manual code for it anyway
<cjwatson> TBH I think it's better in such cases to revert to the previous method, and hold our noses until lucid stops mattering
<cjwatson> or revert in a custom backport
<cjwatson> speaking of NEW, if somebody could have a look at grub2, that would be good - the package reorganisation is already through Debian NEW
<slangasek> lool: reverting the pre-depends would make the preinst fail :)
<micahg> doko: should openjdk-7 be taking 8 days on armel for oneiric?
<ScottK> barry: As a compromise on Bug 784662, would you be able to build and test the oneiric package on natty so we can just put it in natty-backports?  Testing doesn't need to be more than 'it runs'.
<ubottu> Launchpad bug 784662 in winpdb (Ubuntu) "winpdb doesn't work with python2.7" [Undecided,Won't fix] https://launchpad.net/bugs/784662
<micahg> ScottK: has 2 rdepends as well
<ScottK> micahg: Right.  I guess it depends on how broken it is at the moment.
<doko> micahg: yes
<doko> still progresses
<micahg> doko: ok, thanks
<maxb> Are there any ~ubuntu-sru members around who could confirm that bug 707075 is visible as something needing attention in due course?
<ubottu> Launchpad bug 707075 in bzr (Ubuntu Lucid) "[sru] lp-propose fails with a 404 error" [Undecided,New] https://launchpad.net/bugs/707075
<lool> slangasek: Something like that http://paste.ubuntu.com/609602/ ?
<slangasek> lool: I expect there are corresponding updates to the postinst and postrm required
<lool> slangasek: yup
<lool> http://paste.ubuntu.com/609605/
<lool> just copied the preinst file
<lool> Ah I forgot to remove the actual pre-depends
<slangasek> lool: well, I don't think rm_conffile as such is what you want in each of the maintainer scripts... dpkg-maintscript-helper behavior is more subtle than that
<slangasek> lool: so it might be that a single call to rm_conffile in one of the scripts is sufficient - we just need to make sure we aren't trying to call nonexistent dpkg-maintscript-helper from the others
<lool> Ok; looks like I should actually read the dpkg-maintscript-helper man page
<cjwatson> certainly shouldn't be the exact same code in all three
<lool> it was the same dpkg-maintscript-helper calls, so disabling my brain I just copied the rm_conffile snippet, but that's indeed not a good idea
<slangasek> it's the same call, but d-m-h is far too clever and knows which maintscript it's called from :)
<lool> yup
<lool> slangasek: BTW why not do that from the qemu-user-static package?
<slangasek> because that's not the package that owned the conffile
<lool> but isn't there the chance that the version with the maintainer snippets never gets installed?
<slangasek> if the user is doing something other than a plain upgrade, yes
<slangasek> s/upgrade/dist-&/
<lool> so a non-purged package would leave the file on disk, and it's effect woudl continue
<lool> slangasek: Apparently you can remove conffiles from other packages with dpkg-maintscript-helper; it seems that might be a better way to ensure it goes away?
<slangasek> it would be a more comprehensive way
<lool> I think I would do it only in qemu-user-static.preinst and qemu-kvm-extras-static.preinst; it seems to be enough
<slangasek> if you're doing it in qemu-user-static, you don't need it in qemu-kvm-extras-static at all
<slangasek> because the one depends on the other
<lool> right
<lool> alright, uploaded
<mdeslaur> andreserl: mind if I merge virtinst?
<broder> mdeslaur: does the test case in bug #336932 work for your compiz/screensaver stuff?
<ubottu> Launchpad bug 336932 in compiz (Ubuntu) "New windows cause panels to be raised above fullscreen applications (e.g. screensaver)" [Low,Triaged] https://launchpad.net/bugs/336932
<mdeslaur> broder: uhm...probably
 * sebner hugs broder 
 * broder waves at sebner :)
<sebner> broder: it was a real pleasure to talk to you! :)
<mdeslaur> broder: I know people see update manager when it pops up
<broder> mdeslaur: at mit we ran into issues with the graphical zephyr client, but that's a little harder to setup and test with :)
<mdeslaur> broder: sorry, I haven't had time to identify real testcases that I've personally tried yet
<poolie> SpamapS: hi, could you have a look at an SRU for me?
<mterry> kees, does my latest comment in https://bugs.launchpad.net/ubuntu/+source/seed/+bug/782972 make sense?
<ubottu> Ubuntu bug 782972 in seed (Ubuntu) "[mir] seed" [Undecided,In progress]
<mterry> kees, oh you just commented!  i missed it
<kees> hehe :)
<poolie> specifically https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/707075
<ubottu> Ubuntu bug 707075 in bzr (Ubuntu Lucid) "[sru] lp-propose fails with a 404 error" [Undecided,New]
<sconklin> pitti: still around?
<SpamapS> poolie: sure, which one?
<andreserl> mdeslaur, sure go ahead :)
<SpamapS> poolie: lucid bzr ?
<mdeslaur> andreserl: cool, thanks
<poolie> yes please
<SpamapS> poolie: ahh, this may take a bit.. big diff. ;)
<sconklin> SpamapS: are you able to copy a package from our ppa to -proposed?
<SpamapS> sconklin: have not had any progress on that yet I'm afraid. :-/
<SpamapS> pitti: ping, this is a reminder.. we need to do that archive training.
<sconklin> jdstrand: are you able to copy a package from our ppa to -proposed?
<poolie> SpamapS: it has a microrelease exception so
<poolie> well, i'm not saying don't read the diff, but i just wanted you to be aware of it
<poolie> which diff url are you looking at?
<SpamapS> poolie: right I am just looking to make sure the diff is actually the diff from 2.1.1 to 2.1.4
<SpamapS> Not going to try and grok all 11 bugs fixed. :)
<jdstrand> sconklin: I've not talked to pitti yet, though I did review the process. I will send an email to kernel-sru today so we can get this unblocked for you. if this is blocking testing, I would recommend you have the testers get the packages (that you want copied to -proposed) directly from your PPA today
<poolie> thanks SpamapS
<SpamapS> poolie: looks good! accepting.. :)
<sconklin> jdstrand: I don't think it's blocking testing. Stefan would know but he's also left for the day. Before he left he asked me to make sure it got copied to -proposed asap
<sconklin> It was still building when he had to leave
<poolie> great! thanks
 * SpamapS sits and watches as sru-accept.py spams all the subscribers
<SpamapS> poolie: speaking of new versions of bzr.. how do I get 2.4 on my natty system?
<poolie> SpamapS: ppa:bzr/ppa or ppa:bzr/proposed or ppa:bzr/daily
<poolie> from least to most excitng
<poolie> that is a new record (low) for sru latency, which is just so good
<SpamapS> poolie: micro release exceptions have definite benefits for pushing things into the stable release quickly. :)
<poolie> yeah, and we're getting a better idea how to do them smoothly
<poolie> and i think it's good for ubuntu too to have projects maintain these branches rather than be trying to pick branches out
<poolie> assuming it's sufficiently stable
<SpamapS> poolie: +1 , stable, responsive upstreams == happy ubuntu users
<geser> anyone familiar with autotools have a minute to help me figure out why pidgin FTBFS after a autoreconf during build?
 * sebner waves at geser
<geser> Hi sebner
<geser> any libtool expert around?
<slangasek> if I say yes, am I going to have to look at libtool? :)
<geser> slangasek: probably, I'm trying to understand why pidgin FTBFS in oneiric (https://launchpadlibrarian.net/71695867/buildlog_ubuntu-oneiric-amd64.pidgin_1%3A2.7.11-1ubuntu3_FAILEDTOBUILD.txt.gz)
<geser> as one of the Ubuntu patches touches configure.ac, autoreconf is run during the build
<geser> but I don't understand why it FTBFS after that
<hallyn_afk> all right, having some toolchain trouble i think.  When I pull-lp-source seabios natty;  cd seabios-0.6.1.2;  debian/rules build  i get the error:
<hallyn_afk> https://wiki.ubuntu.com/ServerTeam/Roadmap/OneiricPlanning/UDSBudapest
<geser> it seems to be a libtool issue as after downgrading libtool to the version in natty, pidgin builds again fine
<hallyn> I get that whether I"m build in natty or lucid, in fact
<geser> hallyn: you sure you pasted the right url?
<hallyn> uh, that's not it
<hallyn> :)
<hallyn> out/romlayout16.lds:695 cannot move location counter backwards (from 000000000000c9fa to 000000000000c9e0)
<hallyn> that would be it
 * hallyn curses xchat for using different clipboard from terminal
<slangasek> geser: I think I agree that this is a libtool issue; libgnt.la is clearly being built immediately beforehand
<hallyn> hm, i've tried this in schroots, containers, and on the host.  but lemme just push it to a ppa just to be 100% sure there's a toolchain regression, not a local weirdness
<slangasek> geser: can you reproduce this with the Debian libtool and raise a bug on the Debian package?  I don't think there's anyone with deep knowledge of the libtool code who will dig into this on the Ubuntu side
<geser> slangasek: when I compare the build/finch/libgnt directory from a build with libtool from oneiric I can only see a Makefile and gnt.pc, while in the same directory with libtool from natty there are also *.lo files and libgnt.la
<slangasek> wow
<geser> slangasek: can try, just downloading the libtool deb from Debian unstable and use this?
<slangasek> oh wait
<slangasek> oh, no, don't wait
<slangasek> geser: yes, exactly
<geser> slangasek: also calling "make libgnt.la" in build/finch/libgnt (with libtool from oneiric) doesn't show any error (exit code 0) but still no files there (perhaps somewhere else but I couldn't find them)
<slangasek> nope, should be created in that dir
<slangasek> anything output in .libs?
 * sebner hugs slangasek 
<sebner> slangasek: Just wanted to say that it was a real pleasure to talk to you!
 * slangasek hugs sebner
<slangasek> likewise :)
<geser> slangasek: same error with libtool 2.4-2 from Debian unstable
<slangasek> geser: cool, then Q_ can probably help
<slangasek> geser: btw, maybe it's useful to test without --silent, to see what commands libtool is trying to run (if any)
<geser> slangasek: see http://paste.ubuntu.com/609721/ for all files I've in that dir and the output of "make libgnt.la"
<slangasek> geser: what happens if you try to run one of those libtool --mode=compile commands without the --silent?
<geser> slangasek: http://paste.ubuntu.com/609725/ after modifying the Makefile and removing the --silent
<slangasek> heh
<hallyn> Yes, I get the exact same thing building for ppa:   https://launchpadlibrarian.net/71969868/buildlog_ubuntu-natty-i386.seabios_0.6.1.2-0ubuntu1_FAILEDTOBUILD.txt.gz
<hallyn> this is the exact same package as is currently in natty archive.
<hallyn> kees: ^ is there some change in build flags that you know of htat woudl cause this?
<kees> hallyn: nothing that I know about. how odd!
<hallyn> kees: ok, thanks.  feh, i guess i might have to go read though and try ot actually understand it :)
<hallyn> the weirdest thing is that it also now fails under lucid (the same way) to build
<hallyn> so presumably it's some change which then got SRUd!
<slangasek> geser: you said autoreconf was called during the build?
<slangasek> I don't see that in a build log here
<slangasek> in fact, I think that's the source of the problem - the generated libtool script is DOA
<slangasek> probably because of mismatched ltmain.sh and autoconf macros
<geser> slangasek: autoreconf was the wrong summary, there is a automake and autoconf between the the two configure runs in the log
<slangasek> right
<slangasek> you're missing libtoolize :)
<slangasek> so, an explicit autoreconf should fix this
<slangasek> (not a libtool bug then)
<hallyn> kees: feh!   https://bugs.launchpad.net/ubuntu/+source/seabios/+bug/756044
<ubottu> Ubuntu bug 756044 in seabios (Ubuntu) "seabios version 0.6.1.2-0ubuntu1 failed to build on i386" [High,New]
<slangasek> geser: an explicit autoreconf fixes it here
<geser> slangasek: thanks, running libtoolize fixed it (just tried it inside my pbuilder). Is using dh-autoreconf in debian/rules the right packaging fix (and filing the issue upstream)?
<slangasek> dh_autoreconf is probably reasonable here, yse
<slangasek> yes
<slangasek> I'm not sure if there's anything here that should be filed upstream
<geser> not?
<slangasek> geser: well, the upstream rules seem to be working in the standard automake way
<geser> why does it only happen when we modify configure.ac which triggers the regeneration? without that patch which modifies configure.ac it builds fine (with libtool 2.4 from oneiric)
<slangasek> because only modifying the autotools source files triggers a build-time invocation of autotools
<geser> why does the build with the old files and libtool 2.4 installed work while it fails with the regenerated?
<ohsix> hyperair: any chance at #651931 in natty? i've got other crashers for click before paint if you're interested as well
<slangasek> geser: because running automake && autoconf pulls in new versions of the libtool macros from the system directory, which don't match the ltmain.sh in the source tree
<geser> and why shouldn't configure call libtoolize when it regnerates the files? as missing to call libtoolize seems to cause problems if the libtool version changed
<slangasek> perhaps it should - but I don't think that's something that pidgin upstream is going to fix, the build glue all comes from automake
<geser> ok
<geser> then I just use dh-autoreconf and be done with it?
<slangasek> or file a bug against *automake* upstream, if you wish :)
<geser> nah, I'm happy to not have to file a bug somewhere :)
#ubuntu-devel 2011-05-19
<Keybuk> directhex: HAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHAHA
<directhex> Keybuk: :)
<directhex> Keybuk: see? your time with ubuntu can still be a source of great lulz!
<Keybuk> I know, right
<Keybuk> the funny thing is that I don't actually like Mono
<ion> Whatâs the funny?
<Keybuk> ion: because I was chairing the TB meeting the week the Mono debate came up, it's my name on the TB's position statement
<ion> I mean, what made you laugh
<directhex> Keybuk: i made this point when the rumour mill first started up, over such an innocently trolling tweet
 * micahg wonders why DIF is so early this cycle
<Keybuk> which means Boycott Novell think I'm Ubuntu's chief Monoista or something
<Keybuk> ion: http://bit.ly/kB3NcO
<ajmitch> it's amusing that they'd bite at something that obvious
<ion> Thanks
<directhex> Keybuk: i'd need to not be in gameos to check my irc logs, but i think it was along the lines of "keybuk doesn't actually like mono, he just hates douchebags"
<ion> heh
<Keybuk> <monodev> people have even weirder names. probably in this local or family or culture, it means something good	
<ion> Upstart 2 will be written in C#!
<Keybuk> anyway, I like to fuck with them
<Keybuk> because they are exceptionally nasty people
<directhex> Keybuk: anyway, how's the googletron treating you?
<RAOF> I especially like âtrojarinâ :)
<Keybuk> directhex: free food, free gym, free bowling alley, what's not to like?
<directhex> Keybuk: i can't imagine actively wanting to live in yankland :/
<Keybuk> the weather is better, the scenery is prettier, the people are friendlier, ...
<broder> directhex: california is most definitely not yankland :-P
<directhex> broder: last time i was in the US i was in CA, and... bleh
<directhex> perhaps i just have a knack for being in crap parts of the US when i visit
<directhex> although san antonio was nice enough, certainly compared to fremont
<broder> you were in fremont?
<broder> yeah, it's hard to say if that counts
<Keybuk> Fremont is pretty ghetto
<directhex> SGIUG meeting
<ion> The last time i was in the US i was in Gitmo. Didnât like it much, although the waterboarding was cool.
<Keybuk> heh, waterboarding does sound like a fun surf-related activity, doesn't it?
<directhex> it's a few years since i've been to cuba. it was certainly sunny
<ion> Speaking of which, my keyboard has this between the arrow keys and the pageup/pagedown/â¦ block: http://heh.fi/tmp/extreme_sports
<Keybuk> at least your keyboard *has* a pageup/down keys
<Keybuk> vaguely related
<Keybuk> does anyone how whether Spatula is Christian?
<Keybuk> ie. is he likely to be raptured?
<directhex> raptored?
<micahg> any archive admins around that can pocket copy from -proposed?
<bryce> jcastro, if you want to see the change to the xorg package hook deployed, you can test and give feedback @ #778758; else it'll be live in a few weeks or however long sru's take these days
<micahg> siretart: will you be doing a new libav merge soon?
<micahg> siretart: actually, nm, it won't fix my issue in any case I think
<ohsix> hm are the 404 changelogs going to be fixed?
<ohsix> input has been acting weird since the last update that included some xorg stuff, but i haven't been able to fetch the changelog yet
<broder> ohsix: changelogs are always accessible through launchpad and the source
<ohsix> can you give ne a prototypical example for xserver-xorg or the xorg package?
<jcastro> bryce: so from looking at the branch you just have the option of "Yes."?
<ohsix> most changelogs do work from aptitude; some tend to never do though
<ohsix> maybe they're packages in -proposed
<ohsix> but they worked in mav
<broder> https://launchpad.net/ubuntu/natty/+source/xorg/1:7.6+4ubuntu3.1
<broder> ohsix: or you can just apt-get source the package and look in debian/changelog
<ohsix> hm thats probably untenable, on metered internets; any idea why it's broken for some packages in aptitude now? maybe the multiarch name mangling?
<ScottK> SpamapS: I'd appreciate it if you could go ahead and accept the SRU for Bug #755608.  It's got a major negative effect on people using Kubuntu and VPNs and I'd like to get it in proposed before everyone who's got the problem and is vaguely connected to Ubuntu development has the fix from my PPA and doesn't care about SRU verification.
<ubottu> Launchpad bug 755608 in ntrack (Ubuntu Natty) "Ntrack dead loop in function get_nl_link_by_index " [High,In progress] https://launchpad.net/bugs/755608
<broder> ohsix: it should have nothing to do with multiarch mangling
<broder> but i don't know anything other than that
<ohsix> ok thanks
<ohsix> it'd be great if it worked again
<pitti> Good morning
<pitti> sconklin, SpamapS, jdstrand: I'll reply with the instructions
<pitti> lool: ah, seems you registered https://launchpad.net/pkgbinarymangler -- can you please disable upstream bug reports in LP for this project? having them as Ubuntu bugs is enough, as it's a native package
<lool> pitti: pkgbinarymangler's config says bugs are tracked "somewhere else"
<lool> I see no bugs on https://bugs.launchpad.net/pkgbinarymangler
<lool> pitti: so perhaps someone else just changed that, or I don't see what to change
<pitti> lool: I just closed the upstream one in bug 783565 and moved it to null
<ubottu> Launchpad bug 783565 in pkgbinarymangler (Ubuntu) "Please consider stripping translations of X-GNOME-* extension keys" [Medium,In progress] https://launchpad.net/bugs/783565
<pitti> lool: but anyway, not that important
<dholbach> good morning
<lool> pitti: This looks like a lp bug then
<pitti> hey dholbach, guten Morgen
<dholbach> hey pitti
<lool> pitti: NULL has bug tracking disabled as well; it seems you can't prevent bugs from going to projects which disabled the bug tracker
<pitti> lool: ah, the intent is probably that you'd use those for linking to external bug trackers
<pitti> lool: so for this we probably shouldn't have a project in the first place
<lool> that's a way to kill it indeed
<lool> pitti: but we need one for lp:pkgbinarymangler to work
<lool> pitti: I don't mind either way (keeping it with some ghost bugs or demoving it and using the UDD branch)
<lool> s/demoving/removing
<pitti> ah, that was the reason for it?
<pitti> WFM
<mdke> pitti: hi. Any idea why the gnome-user-docs SRU that was accepted and built in maverick-proposed yesterday has not appeared on archive.ubuntu.com? The source package seems to be there. Sorry always to pick on you with my questions
<pitti> mdke: ah, it's probably in binNEW, as it added new translations; I already binNEWed lucid yesterday, but not maverick
<pitti> mdke: accepted, will be on archive.u.c. in an hour
<mdke> pitti: magic, thanks. Obviously the translations won't be picked up until the next language packs I guess
 * mdke looks to see when they are
<mdke> mid-June, cool
<pitti> mdke: no, language-selector should pick them up, I think?
<pitti> ah, no, we strip them out and put them into the langpacks
<mdke> right
<didrocks> good morning
<apw> does anyone happen to know which process during x setup makes the .ICEauthority file ?
<apw> @pilot in
* udevbot_ 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: apw
<Satoris> Building Evince git head works fine in 32 bit natty, but fails on 64 because it links to both GTK+ 2 and 3. Any ideas on how to fix this?
<pitti> Satoris: are you sure that this is platform specific? sounds like a bug in evince's makefiles
<Satoris> pitti: could be, I have no idea. How do I find out?
<pitti> it's just weird that it's architecture specific
<pitti> Satoris: it's much more likely that on your 64 bit system you have both 2.0 and 3.0 -dev packages installed, and on your 32 bit system just one, or something similar
<pitti> so I wanted to ensure you test with identical build dependencies
<ohsix> apw: gnome-session from the looks of it, or whatever the session manager is
<apw> ohsix, ahh there it is ... thans
<seb128> what gnome-session?
<ohsix> er maybe libice does
<ohsix> i was just grepping :]
<Satoris> pitti: found out the issue, thanks.
<seb128> ohsix, what is the issue?
<ohsix> no idea, he just asked
<pitti> seb128: apw | does anyone happen to know which process during x setup makes the .ICEauthority file ?
<seb128> pitti, thanks
<seb128> yeah it's likely gnome-session
<apw> seb128, i've found it thanks ... it is indeed gnome-session
<apw> i am getting and error (of my own making on it)
<maswan> pitti: hm. where's the prefered support channel for your postgresql 9 ppa, blog entry, email, /query?
<pitti> maswan: /query will do fine
<pitti> maswan: are you going to ask why libpq is at 9.1? :-)
<pitti> seems that people spam me with that question a lot these days
<maswan> pitti: no, why pg_upgradecluster fails hard :)
<pitti> that's more interesting indeed; which version are you upgrading to?
<maswan> 8.4 on lucid
<pitti> maswan: debian bug 627227 probably
<ubottu> Debian bug 627227 in postgresql-common "postgres-common: pg_upgradecluster fails with ERROR: function replace(..." [Normal,Open] http://bugs.debian.org/627227
<pitti> ?
<maswan> pitti: yeah, it looks like it
<pitti> maswan: I'll try to fix it today
<maswan> pitti: I get more error messages though, starting with ERROR:  could not access file "$libdir/tablefunc": No such file or directory
<maswan> pitti: maybe I should update that bug or so with the full error paste, or would that annoy debian purists?
<pitti> maswan: wouldn't annoy me at least, and I'm the maintainer
<maswan> pitti: would it be helpful?
<pitti> can't hurt
<maswan> ok, adding it
<pitti> thanks
<geser> pitti: I'm only using the Debian squeeze backport of postgresql-9.0, but did you already update the versions in the README.Debian? Not that people follow it blindly and drop their 8.4 clusters
<pitti> geser: well, I'd expect a certain amount of thinking there :) but I'm happy to generalize it to not say a particular version
<pitti> but it says that it's only an example
<flower>  could it be true that if you backport from meerkat to lucid and let meerkat stand in you changelog file, the system asks for a partial distro upgrade?
<pitti> it's not related to the changelog; presumably the new backport version grew a new dependency
<ohsix> hm what's the story with powertop, is oneiric going to see a bump to 1.97? and what stopped it from happening with natty
<amitk> ohsix: if you're doing work on getting powertop in, could you get it from tip instead?
<amitk> it has fixes to make it run on ARM
<ohsix> hm
 * amitk is not sure what is currently packaged in debian
<pitti> maswan: fixed p-common uploaded to sid; uploading backports for lucid/maverick/natty to PPA now
 * sebner hugs pitti :)
 * pitti hugs back sebner
<cdbs> cjwatson: All default CD packages in Oneiric are installable now, time to fire up daily builds? :)
<pitti> cdbs: yeehaw!
<cdbs> pitti: Thanks to you, geser, seb128 and cjwatson for keeping the archive consistent
<pitti> we are still breaking gnome, but trying hard to not break it too hard/long
<Laney> aw, that's no fun
<doko> pitti: ping on bug #784029
<ubottu> Launchpad bug 784029 in gcc-4.6 (Ubuntu) "Lack of g++-dbsym" [Undecided,New] https://launchpad.net/bugs/784029
<cjwatson> cdbs: oh, yeah, I was thinking of doing that soon - I was kind of hoping to switch to live-build first, but that'll probably take too long
<cjwatson> need to check on all the dailies that weren't released with natty first though, and maybe take archive copies
 * sebner hugs cjwatson :D
<cjwatson> :)
<jdstrand> pitti: re kernel-sru> thanks!
<ScottK> pitti: I'd appreciate it if we could get the fix for Bug #755608 into natty-proposed.  It's hitting quite a number of people pretty hard.
<ubottu> Launchpad bug 755608 in ntrack (Ubuntu Natty) "Ntrack dead loop in function get_nl_link_by_index " [High,In progress] https://launchpad.net/bugs/755608
<siretart> micahg: what is the issue?
<siretart> micahg: and yes, I intend to upload 0.7_beta2 RSN
<ScottK> micahg: I was wondering if you might have a look at this thread https://lists.ubuntu.com/archives/kubuntu-users/2011-May/054073.html and see if you have any ideas about this problem or suggest someone better to look into it?
<pitti> ScottK: will do now
<ScottK> Thanks.
<pitti> doko: I'll have a look
 * sebner hugs ScottK too :D
<sebner> ScottK: we'll definitely meet again, maybe not in orlando but someday. I'm looking forward to it
 * ScottK too
<ScottK> asac: I'd appreciate it if you could have a look at the patch in Bug #785119 soonish.
<ubottu> Launchpad bug 785119 in ntrack "ntrack can get into endless poll loop if no backend modules found" [Undecided,New] https://launchpad.net/bugs/785119
<asac> added to list
<ScottK> Thanks.
<broder> sebner: i'm going to be disappointed with you if you don't make it to orlando, so work harder :-P
<sebner> rofl
 * sebner hides
<apw> doko, are we expecting any compilers in the next couple of days?  we are likely uploading a kernle tommorrow
<doko> apw: just the ones currently building
<stgraber> mdeslaur: hey! I just noticed that usb-creator in Oneiric has a lower version number than the one in Natty. Is there a reason you didn't upload your security upload to Oneiric too?
<apw> doko, thanks, i'll try and avoid them till they finish :)
<cjwatson> stgraber: I can copy it ...
<stgraber> cjwatson: would be great
<broder> hmm...does strcpy's buffer overrun detection tend to have false positives?
<apachelogger> tkamppeter: pingy, is the call to com.redhat.NewPrinterNotification something ubuntu specific or something worthwhile to implement in upstream KDE?
<broder> (i'm trying to evaluate the patch on bug #723830)
<ubottu> Launchpad bug 723830 in seamonkey (Ubuntu) "seamonkey-2.0-bin assert failure: *** buffer overflow detected ***: /usr/lib/seamonkey-2.0.11/seamonkey-2.0-bin terminated" [Medium,Confirmed] https://launchpad.net/bugs/723830
<mdeslaur> stgraber: ev had a commit to go in his bzr tree, I was waiting for him to commit it
<cjwatson> mdeslaur: I'm generally happy to just batch-copy everything non-divergent from -updates to the next development series along
<cjwatson> mdeslaur: and assume that somebody will take care of merging any bzr branches etc.
<mdeslaur> cjwatson: so I would ask an AA to do that?
<cjwatson> yes - I'm in the process of doing it now
<mdeslaur> cjwatson: ok, cool. thanks
<micahg> ScottK: ISTR an old bug like that
<sabdfl> hi
<hrw> pitti: I found reason of bug 784029 - but is in pkg-create-dbgsym
<ubottu> Launchpad bug 784029 in pkg-create-dbgsym (Ubuntu) "Lack of g++-dbsym" [Undecided,In progress] https://launchpad.net/bugs/784029
<hrw> s/but/bug
<pitti> hrw: oh, you did? I just added a simple test case (dhtest++1), but that works
<hrw> pitti: in_line() function uses egrep and fails if $pkg argument consists + character
<pitti> hrw: right, that was my first suspicion -- but shoudln't that fail on dhtest++1 as well?
<pitti> hrw: I got distracted by some other stuff, but I'll continue to look into this
<hrw> pitti: fails for me
<hrw> dhtest++1 I mean
<hrw> http://paste.ubuntu.com/610143/
<pitti> ah, it might magically work with just one package name
<pitti> hrw: I'll write a more appropriate test case
<pitti> .. in a bit, need to run out to supermarket
<hrw> no problem
<RoAkSoAx>  /win 16
<lool> pitti, hrw: Issue seems to be the grep in "in_list" in pkg-create-dbgsym/dh_strip
<lool> echo "g++4.6" | egrep -q "(^|[[:space:]])g++4.6(\$|[[:space:]])" fails
<hrw> 17:47 < hrw> pitti: in_line() function uses egrep and fails if $pkg argument consists + character
<lool> in_list()
<hrw> s/in_line/in_list ;D
<pitti> lool, hrw: I already had the fix, but as my first initial test case wasn't reproducing, I postponed it
<hrw> ok
<hrw> fine for me - you know the problem, will solve it and I will get g++-4.6-dbgsym package
<hrw> on 26 March 2010 g++-4.4-dbgsym package got created so maybe you can check how it was done at that time
<hrw> pkg-create-dbgsym (0.41) lucid; urgency=low
<hrw> you added in_list in this version
<hrw> it was fix for bug 566602
<ubottu> Launchpad bug 566602 in pkg-create-dbgsym (Ubuntu) "does not build libglib2.0-0-dbgsym" [High,Fix released] https://launchpad.net/bugs/566602
<hrw> bzr rev 174
<hrw> anyway time for me to take care of nonwork related stuff
<hrw> have a nice rest of day
<apw> @pilot out
* udevbot_ 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:
<nigelb> persia: welcome back to IRC ;)
<persia> nigelb, Thanks!
<apw> persia, does that mean some normality is returning ?
<persia> apw, Yes, indeed.
<micahg> welcome back persia
<maco> persia: you're back! *hug*
<persia> Although, honestly speaking, my infrastructure setup time causes a lag between apparent normality and connetion monitoring
<pitti> ev: FYI, I just re-merged lp:~pitti/usb-creator/pygi to trunk (just saw  your new upload)
<ev> yay
<ev> thanks
<pitti> ev: any chance to merge this soon, that it stops getting out of date? or do you want to wait on something else?
<ev> oh
<ev> I thought you meant you merged it into trunk
<ev> yes, I'll do a merge now
<pitti> well, technically I can commit myself, of course, but I wondered whether you'd prefer to review it
<ev> I'll have a quick look over
<ev> just to put another set of eyes on it
<pitti> thanks
<tkamppeter> apachelogger, this is used at least in Fedora/Red Hat, Ubuntu, and Mandriva (distros which use system-config-printer). The D-Bus signal is sent by the Plug'n'Print part of s-c-p (udev-configure-printer, udev-add-printer, both in /lib/udev/) and received by the s-c-p applet.
<pitti> hrw, lool: ah, got my failing test case at last; it only hits builds which use dh_strip -p..., so my initial attempt failed
<pitti> as usualy, 30 minutes for test case, 30 seconds for the fix, but I'm anal about having this stuff covered
<jdstrand> hallyn: hey, so I started looking at your libvirt merge
<jdstrand> hallyn: first off, you will want to use '-v<last version in ubuntu>' when building your source package
<jdstrand> hallyn: more importantly, it seems that attaching of physical devices has changed/is broken
<hallyn> jdstrand: i'm certain i did
<hallyn> hm
<jdstrand> hallyn: the changes file only lists the changes for 0.9.1-1ubuntu1, so not sure what happened there
<jdstrand> hallyn: I looked upstream and there is a lot of stuff on 'phyp' cleanups and bug fixes, etc
<hallyn> <grimace>
<jdstrand> hallyn: here is the xml that fails:
<jdstrand> <disk type='block'> <driver name='phy'/> <source dev='%s'/> <target dev='sdb'/>
<jdstrand> </disk>
<hallyn> jdstrand: there's a qa test that does that?
<hallyn> If so, can we open a debian bug for it?
<jdstrand> where '%s' is the name of some file created with 'dd if=/dev/zero of=<foo> bs=1M count=64'
<jdstrand> hallyn: yes-- test_guest_aa_attach_detach_physical()
<jdstrand> "attach-device (physical)"
<jdstrand> hallyn: there were other failures-- save/restore that I am not worried about (nested qemu issue)
<jdstrand> hallyn: and then test_CVE_2010_2239(). I need to investigate that
<hallyn> hm, i thought i tested save/restore on the vostro
<jdstrand> hallyn: save/restore certainly works, what doesn't work is nested virtualization with save/restore where the nested vm is qemu (iirc)
<hallyn> interesting
<hallyn> for a sec i thought you meant nested on amd
<jdstrand> no
<jdstrand> kvm for the guest that is running test-libvirt.py. test-libvirt.py runs a qemu guest
<pitti> kees, jdstrand: releasing karmic linux-ec2, smb confirmed testing
<pitti> to -updates and -security
<jdstrand> hallyn: that didn't work right on natty either, fwiw
<pitti> not sure whether you want to release an USN for this, as it's past EOL
<hallyn> jdstrand: it should work in natty-proposed
<jdstrand> hallyn: you have a patch for that?
<hallyn> jdstrand: (the mishandling of int in kvm.ko stopped restore from working)
<jdstrand> ah, a kernel update
<jdstrand> hallyn: is that in oneiric already?
<hallyn> i'm not seeing anything in libvirt git tree for phys
<hallyn> should be in o, yes
<hallyn> (i haven't checked, but was told it was)
<jdstrand> $ cat /proc/version_signature
<jdstrand> Ubuntu 2.6.39-2.8-generic 2.6.39-rc7
<jdstrand> still busted there ^
<jdstrand> might be a different issue
<jdstrand> istr finding a bug on it, but I can't locate it right now
<hallyn> sigh, yup
<hallyn> that's with libvirt 0.8 ?
<jdstrand> pitti: thanks, I'll let kees handle it
<jdstrand> hallyn: no, the new 0.9.1
<hallyn> oh, ok
<jdstrand> I can tell you it was busted with natty and 0.8 that is in release
<hallyn> i suppose i need a debian box to test its libvirt on
<apachelogger> tkamppeter: ah, sounds like something we should implement in upstream KDE then, thanks :)
<hallyn> or, maybe better to test with daily build
<jdstrand> hallyn: regarding phys, I looked in http://libvirt.org/news.html-- tons on phyp (I'm assuming those are the relevant changes)
<tkamppeter> apachelogger, this would be great, best would be if both KDE and GNOME ship with a printing applet and the applets being compatible to each other.
<tkamppeter> apachelogger, GNOME 3 comes with its own printing applet, but I do not know anything about its D-Bus interface.
<hallyn> jdstrand: (wouldn't those be ones which are in th epackage?
<hallyn> I see one phyp 'avoid a crash' post-0.9.1 in git changelog
<jdstrand> hallyn: yes, presumaly they are in the package, and something is wrong cause I get:
<jdstrand> error: Failed to attach device from /tmp/tmpSMveEB/device.xml
<jdstrand> error: internal error unsupported driver name 'phy' for disk '/tmp/tmpSMveEB/device_disk.img'
<hallyn> i'll look into it, thanks
<jdstrand> hallyn: it might be an intentional change-- I don't know, but the test is there cause iirc euca and openstack attach physical devices
<jdstrand> hallyn: and this could break them
<apachelogger> tkamppeter: if the interfaces were specified somewhere that would probably help with that
<jdstrand> hallyn: it is conceivable the restore/save failures are test suite failures-- please ignore those for the time being
<jdstrand> hallyn: I'll look at that and the CVE test
<pitti> ev: cheers
<hallyn> jdstrand: cool, thanks.  i can trivially reproduce the phys one here  :)
 * jdstrand nods
<hallyn> btw, no need to smack me, i'm realizing i should've run the qatests, i'll smack myself
<pitti> ev: thanks
<ev> sure thing
<tkamppeter> apachelogger, signals sent by CUPS should be no problem. They are defined in CUPS and the applets have to follow. The problems are signals from the printer setup tool and other utilities.
<apachelogger> tkamppeter: yeah... though if they signals are all dbus signals it should be easy enough to introspect the existing ones and come up with a cross-desktopy spec (maybe also outside the com.redhat namespace ;))
<tkamppeter> apachelogger, do you know how Plug'n'Print works in Kubuntu?
<apachelogger> tkamppeter: you mean how well?
<tkamppeter> In Ubuntu the system-config-printer-udev is installed which provides everything.
<apachelogger> we have that too, Riddell wrote a KDE clone of system-config-printer
<tkamppeter> apachelogger, how and how well.
<apachelogger> it only misses the newPrinterNotification it seems
<apachelogger> other than that plug'n'print works fine
<tkamppeter> apachelogger, so the printers get set up if there is an exact driver match and no notification appears?
<apachelogger> yep
<jono> pitti, hey, just a quick FYI - I just reviewed https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-default-apps-unity-integration/ with Jorge, but you are the Approver and I inadvertently approved it - let me know if you are not happy with the approval, and we can adjust it
<jono> I will be expecting jcastro to ensure the assignments here get completed
<tkamppeter> This would once mean that users do not get aware of the automatic process and even worse if there is no exact driver match (for example if a driver is only available for auto-download from the internet) the printer setup tool does not pop up for interactive setup and so the printer stays without queue silently.
<tkamppeter> apachelogger, ^^ so catching newPrinterNotification is very important.
<apachelogger> eww
<tkamppeter> apachelogger, does Kubuntu do automatic printer driver download with Jockey?
<apachelogger> tkamppeter: I have not the slightest idea, JontheEchidna does jockey stuff
<apachelogger> JontheEchidna: pingy pinlingy
<JontheEchidna> pong
<tkamppeter> JontheEchidna, does Kubuntu do automatic printer driver download with Jockey?
<JontheEchidna> hmm, dunno. I've never seen it but I've never needed it
<JontheEchidna> it should work, in theory
<JontheEchidna> jockey has some nice backend/frontend separation
<JontheEchidna> and the kde frontend should implement all the necessary bits
<tkamppeter> JontheEchidna, can you run the command
<tkamppeter> system-config-printer --setup-printer='file:/tmp/printout' --devid='MFG:Epson;MDL:EP-702A;'
<tkamppeter> on your Kubuntu system?
<JontheEchidna> hmm, I don't have that executable, it's part of the gnome package
<tkamppeter> JontheEchidna, one minute please ...
<tkamppeter> JontheEchidna, replace "system-config-printer" by the KDEish executable of system-config-printer.
<JontheEchidna> it's not an executable, but a plugin for KDE's System Settings app
<JontheEchidna> http://i.imgur.com/v3q2G.png
<tkamppeter> JontheEchidna, can you do something like
<tkamppeter> cd /usr/share/system-config-printer
<tkamppeter> python newprinter.py --setup-printer='file:/tmp/printout' --devid='MFG:Epson;MDL:EP-702A;'
<tkamppeter> JontheEchidna, I hope the debug modes for pretending that a given printer got detected are somehow implemented in the KDE incarnation of s-c-p.
<JontheEchidna> !find newprinter.py
<ubottu> File newprinter.py found in system-config-printer-gnome
<tkamppeter> JontheEchidna, you need to call the file where this functionality ended up for KDE.
<JontheEchidna> I don't really know much about that
<tkamppeter> Riddell, ping
<Keybuk> pitti: I don't think that replacing TCL with Vala really helps :-/
<pitti> Keybuk: why not?
<pitti> it's about as fast as C, and avoids a runtime dependency
<Keybuk> err, it adds a massive amount of runtime dependency
<pitti> ?
<Keybuk> libgobject, libgee, libgio, etc.
<pitti> but we ship those anyway
<Keybuk> you do
<pitti> janimo's port uses gee and gio?
<Keybuk> we don't
<pitti> if you don't import anything, it should just depend on glib
<Keybuk> glib is large
<pitti> anyway, I don't personally mind what it's written in, as long as it's not something which requires a new runtime
<Keybuk> yeah, agree
<Keybuk> for us, glib is effectively a new runtime too
<pitti> Keybuk: upstream mentioned python, that would be too big for you as well then, I guess?
<Keybuk> it's not clear to me why the dispatcher is needed at all, since all it does is run the C program
<Keybuk> right, we don't have Python
<Keybuk> and that would be considered both a size problem and security problem, just like TCL
<pitti> wow, you want usb 3G support, but don't have glib?
<pitti> what kind of environment is that, OOI?
<Keybuk> Chromium OS
<pitti> sabdfl: TB meeting now?
<sabdfl> pitti: en route
<kees> 550 Changes file must be signed with a valid GPG signature: Verification failed 3 times: ["(7, 9, u'No public key')", "(7, 9, u'No public key')", "(7, 9, u'No public key')"] : Permission denied.
<kees> anyone else seeing this on oneiric uploads?
<pitti> kees: sometimes, but the upload works anyway if you use dput
<kees> that error is from dput. :(
<slangasek> kees: yes, the error is spurious - the upload succeeded anyway
<kees> slangasek: oh, how ... odd
<slangasek> yep
<slangasek> the bug is filed against lp somewhere
<kees> that's kind of alarming... can I upload stuff that doesn't pass signature tests too? >_>
<slangasek> you can upload it, yes; it won't get accepted into the archive
<slangasek> this is basically a new LP feature intended to check the signatures at upload time in order to give more immediate feedback in case of a problem
<slangasek> it doesn't work right because the upload queue sometimes has the wrong keyring :)
<kees> "wrong"? my key hasn't changed in months now...
<kees> but okay, fair. early rejection is not an indication of later rejection. sounds good
<james_w> I think wrong == empty
<maco> kees: this is why i uploaded the same 0-day sru for natty 3 times :P
<davmor2> james_w: your beer glass is wrong.........yeah I can see how that would work
<kees> maco: hah, d'oh
<nigelb> fta: ping, around?
<ScottK> kees and slangasek: As I understand the error it's not that LP has the wrong key but that it's lost contact with the keyserver so it has no keys at all.
<geser> doesn't it also happen when a tmp directory goes missing?
<geser> bug 757248
<ubottu> Launchpad bug 757248 in Launchpad itself "poppy-sftp's signature checking relies on long-term survival of a directory in /tmp" [Critical,Fix committed] https://launchpad.net/bugs/757248
<ScottK> Nice.  OK.  That too.
<cnd> ScottK, do you know where the "canonical" (not the company) source for the qt4-x11 packaging lives?
<cnd> I've proposed my patch in the past, but it felt like I was doing it wrong by branching lp:ubuntu/qt4-x11 and proposing a merge request
<ScottK> cnd: https://code.launchpad.net/~kubuntu-packagers/qt/ubuntu
<cnd> ScottK, thanks!
<cnd> so I should propose merge requests to merge into that branch?
<ScottK> Yes and probably ping someone on #kubuntu-devel.
<sebner> persia: contentless ping (email reminder) :)
<cnd> ScottK, ok, will do
<persia> sebner, heh.
<sebner> persia: :D but don't worry, you can take your time
<virhilo> hello
<virhilo> the "-L/lib/x86_64-linux-gnu -L/usr/lib64 -L/usr/lib/x86_64-linux-gnu" directories are not in library path by default, i think they should be, or there shuld be symlinks from /usr/lib/x86_64-linux-gnu/libjpeg.so to /usr/lib
<virhilo> should i create bug on it?
<virhilo> the middle(-L/usr/lib64) one is problbly in library path i just coppied too much:)
<slangasek> virhilo: what do you mean, "by default"?  They are certainly part of the library path in natty and oneiric for both gcc and binutils
#ubuntu-devel 2011-05-20
<virhilo> slangasek: nope, in naty 64 i have to export them any time when compiling somehting
<slangasek> compiling how?
<virhilo> by ./configure and make:)
<slangasek> yes, but using what compiler?
<slangasek> this all works fine with the default gcc compiler in natty
<virhilo> slangasek: gcc
<slangasek> well, I can't reproduce the problem you're describing
<virhilo> slangasek: it was not able to fiund libpng zlib and few others
<virhilo> slangasek: try compiling python 2.7 for example:)
<slangasek> ah - that has nothing to do with gcc
<virhilo> or pil for python
<virhilo> slangasek: it uses gcc
<slangasek> no, that's an issue with python 2.7's library detection
<doko> virhilo: which python version?
<virhilo> 2.7
<virhilo> slangasek: ahhh...
<slangasek> the upstream library detection code inspects the filesystem directly; a 'gcc -lpng' or 'gcc -ljpeg' works just fine
<virhilo> slangasek: so i should report bugs for them?:)
<virhilo> doko: Python 2.7.1 (r271:86832 to be exact:)
<slangasek> this has been discussed upstream already, and mentioned in barry's post to ubuntu-devel here: https://lists.ubuntu.com/archives/ubuntu-devel/2011-April/033049.html
<doko> virhilo: try to build from the current branch
<virhilo> doko: you mean directly form hg from default branch?
<doko> virhilo: from the 2.7 branch, or rebuild the oneiric package on natty
 * virhilo trying
<virhilo> clonning slow:P
<virhilo> doko: works:) awesome
<lfaraone> Would having update-manager source its mirror lists from the web be a useful feature to implement?
<lfaraone> I noticed that in Lucid, several mirrors don't even exist anymore. (washdc-linux.com was squatted)
<ohsix> i thought it did already
<ohsix> the mirror chooser tries to connect to all of them just the same; to see if they work and how fast/close they are, so bad ones won't hurt much
<lfaraone> ohsix: /usr/share/update-manager/mirrors.cfg is where the mirror list is sourced from.
<ohsix> ok
<lfaraone> ohsix: the mirror picker does do a download test, but people manually picking will choose bad mirrors sometimes.
<persia> lfaraone, I believe there was a discussion at UDS about an entirely new and better way to select mirrors.  I may be mistaken, but I'd encourage you to review the specification list just in case (unless someone gives you a good answer sooner)
<micahg> @pilot in
* udevbot_ 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: micahg
<pitti> Good morning
<ajmitch> morning pitti
<micahg> hi pitti , I'm looking at bug 775900 for SRU, I think the idea is to upload the version in oneiric to natty, I was thinking of just adding a changelog entry on top with the version 2.0.0-0ubuntu0.1, WDYT?
<ubottu> Launchpad bug 775900 in lyx (Ubuntu Natty) "[SRU] Sync lyx 2.0.0-1 (universe) from Debian unstable (main)" [Medium,In progress] https://launchpad.net/bugs/775900
<pitti> micahg: if it's actually a backport, why not 2.0.0-1~lucid1?
<pitti> but I don't mind much either way
<micahg> pitti: ah, yeah, it's for an SRU
<pitti> right, but technically it's still a backport
<pitti> no need to set X-Ubuntu-Maintainer etc.
<micahg> pitti: hmm, I just compared a debdiff of the archive versions and it doesn't exactly match the debdiff in the bug...
<pitti> micahg: diff that causes problems? I. e. new dependency, major changes, etc? or just autoconf noise?
<micahg> pitti: idk, supposedly he diff'd the same versions I did
<micahg> I'm going to use the version in oneiric since it's more authoritative one, since the bug suggests that was the goal
<pitti> micahg: sounds fine
<pitti> hm, what's up with the publishing -- evolution 3.0 was built 10 hours ago, and http://archive.ubuntu.com/ubuntu/ still has 2.32
<pitti> it's not in NEW
<lifeless> pitti: see #is
<pitti> lifeless: I'm there now
<pitti> ah, known issues
<pitti> thanks
<micahg> pitti: is it possible to use the auto backporter or should I just upload with -sd -v and the extra changelog?
<pitti> micahg: I think upload it manually, that's easier; just append a new changelog and use -v -sa
<pitti> erm, -v -sd, sorry
<micahg> pitti: k
<dholbach> good morning
<micahg> @pilot out
* udevbot_ 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:
 * dholbach hugs micahg
 * micahg hugs dholbach 
<pitti> doko: good morning
<cjwatson> lfaraone: https://launchpad.net/ubuntu/+spec/foundations-o-apt-mirror-method
<doko>  o debian-archive-keyring: debian-archive-keyring
<doko>    [Reverse-Recommends: debootstrap]
<doko> cjwatson: ^^^ you're an uploader, what to do?
<doko> Sweetshark, pitti: could you have a look at the hyphen* component mismatches?
<doko> pitti: same for ttf-sil-nuosusil
<RAOF> cjwatson: I'd appreciate a review of http://tinyurl.com/3sm2rlv with respect to bug #742683 if you've got time.
<ubottu> Launchpad bug 742683 in xkeyboard-config (Ubuntu Oneiric) "on upgrade, keyboard config changed to use deadkeys" [Medium,Triaged] https://launchpad.net/bugs/742683
<lool> Hey
<lool> I'm puzzled that seabios 0.6.2-0ubuntu1 was built in oneiric and accepted, isn't in NEW, yet doesn't show up in rmadison's output or in the archive
<lool> Launchpad thinks it was published 10 hours ago
<lool> ah I see in backlog that we have some publishing issues
<pitti> lool: #is says ETA in about an ohur
<pitti> hour, too
<lool> yup
<lool> hmmm 133 packages to satisfy tomboy bdeps, ouch
<cjwatson> doko: ignore that entry in c-m, I'll do something about it in debootstrap
<Sweetshark> doko: will do
<hrw> pitti: thx for fix
<cjwatson> RAOF: yes, I think that's fine.  You could simplify by using sed -i
<cjwatson> well, fine as in terrifying
<RAOF> cjwatson: Heh.  I'm following the idiom of console-setup there.  Yes, moderately terrifying.
<cjwatson> doko: adjusted in Debian to be sensitive to the host distribution; next autosync will take care of it
<doko> thanks!
<doko> cjwatson: any idea about fast-tracking bug #785607 and bug #785609 ?
<ubottu> Launchpad bug 785607 in libswitch-perl (Ubuntu) "[MIR] new perl-modules recommendations" [Undecided,New] https://launchpad.net/bugs/785607
<ubottu> Launchpad bug 785609 in libversion-perl (Ubuntu) "[MIR] new libmodule-build-perl (build-) dependencies" [Undecided,New] https://launchpad.net/bugs/785609
<cjwatson> doko: well, I'm not on the MIR team, but lib*-perl packages rarely seem problematic
<hrw> pitti: pkg-create-dbgsym works great for g++ now
<pitti> nice!
 * hrw -> breakfast
<ev> pitti: I wasn't able to attend the networking session at UDS. Is network-manager 0.9 (instead of, say, conman) the way forward?
<ev> the specification seems to indicate so, but I wanted to confirm: https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-desktop-network-enhancements
<ev> as I'll be using the dbus api in ubiquity to construct a wireless connection page
<pitti> ev: that's my impression anyway, also after talking with cyphermox
<ev> great
<ev> that makes me a happy bunny
<pitti> ev: I don't know of a plan to switch to connman by default in oneiric
<ev> good deal
<pitti> . o O { after all, this stuff works.. }
<ev> indeed
<ev> this wasn't something I heard recently, I just recall conversations a release or two ago about eventually moving to conman
<ev> and wanted to be sure that wasn't still on the cards
<pitti> might have been a temporary fashion
<pitti> but I don't know much about connman TBH
<pitti> if NM moved to system-wide connections by default, it'd do everything I want from it :)
<ev> I suspect it was exactly that
<pitti> it does suppor them, it just defaults to by-user
<cjwatson> freeflying: can libofetion be synced from Debian?  It's in the OpenSSL 1.0.0 transition list
<freeflying> cjwatson: that would be great
<cjwatson> freeflying: have you checked that there are no outstanding Ubuntu changes?  if so, file a sync request?
<cjwatson> ScottK: could you merge boost1.46 from Debian?  It would fix the libtorrent-rasterbar build failure
<freeflying> cjwatson: will do it
<cjwatson> thanks!
<kenws> Hi there, I'd like to rebuild the firefox deb with an additional compiler flag. From looking at the files in the debian directoy it seems that debian/mozconfig would be the appropriate one, correct? Another option might be to just set the C[XX]FLAGS in debian/rules. Any suggestions are appreciated.
<kenws> hm, setting DEB_CFLAGS_APPEND might be another way...
<ScottK> cjwatson: I'll try to have a look at it a bit later today.
<cjwatson> thanks
<ScottK> SSD is handy when working on boost.
<slangasek> also, opium
<ScottK> That too.
<hallyn_afk> pitti: I've sent a new source package to the libcap2 debian maintainer in the hopes that he'll push it and we can sync (to fix an open bug in both debian and ubuntu).  Is there any problem with waiting and syncing, as opposed to pushing it to oneiric myself?
<ramvi> Is there an apt configuration which tells Ubuntu to choose package-ubuntu packages instead of debian packages?
<ScottK> ramvi: The only way to do this is not have Debian repositories in your sources.list.  This is also highly recommended as Ubuntu makes no attempt at all to maintain binary compatibility with Debian.
<broder> ev, pitti: I asked cyphermox about connman at one point during UDS. He said that it was still a pretty good ways from having feature parity with NM
<cjwatson> doko: http://orangesquash.org.uk/~laney/transitions/ocaml.html - could you update llvm-2.7 and llvm-2.8?  I tried to do a trivial rebuild of llvm-2.7 but it failed
<cyphermox> broder: ev: those who want to use connman can already do so by installing connman/indicator-network and it works okay for simple requirements (wifi, wired, etc)
<broder> cyphermox: Right, but we won't be switching to it by default anytime soon
<doko> cjwatson: how urgent is this? would rather try to move to llvm-2.9
<cjwatson> doko: I suppose that depends on how urgent it is that libllvm-ocaml-{2.7,2.8}-dev are uninstallable
<cjwatson> doko: I'd like to complete at least one of the four transitions I'm looking at this month, though ;-)
<doko> hmm, it's a leaf package
<doko> really need to work on some blueprint stuff
<ev> broder: yeah, I'm quite happy with n-m.
<cjwatson> it's certainly not today-urgent, I just don't really want it to be my problem as I'm not familiar with those packages
<cjwatson> it might just be a matter of adding <stddef.h>
<ogra_> can someone from the sru team reject https://launchpad.net/bugs/721147 ? i need to re-upload (accidentially catched the wrong patch)
<ubottu> Ubuntu bug 721147 in flash-kernel (Ubuntu) "flash-kernel subarch check fails with Linaro OMAP kernels" [Undecided,Fix committed]
<ogra_> err
<ogra_> https://launchpad.net/ubuntu/natty/+source/flash-kernel/2.28ubuntu20 i meant
<hyperair> kirkland: pin
<hyperair> g
<apw> doko, you got any idea how much longer the arm builds are likely to take of gcc ?  wondering when to come back and check :)
<hrw> apw: give it 8-10h
<apw> hrw, 8-10 more!  blimey
<apw> its been going some 24 already
<ScottK> cjwatson: boost1.46 uploaded.
 * ScottK will upload boost-mpi-source1.46 here in a bit.
<cjwatson> thanks
<bryce> any archive admin feel like nuking nvidia-graphics-driver-180 from the archive?  (LP: #756197)
<slangasek> I'm all about nuking packages
<bryce> :-)
<GunnarHj> cjwatson: Hi Colin, any chance that you can review/sponsor a very small im-switch merge + upload to natty-proposed? It's a regression thing, and the proposed change is important to input method users, so the natty-proposed part is kind of urgent. https://code.launchpad.net/~gunnarhj/ubuntu/oneiric/im-switch/lp-663776/+merge/61683
<cjwatson> GunnarHj: sure, looking
<cjwatson> GunnarHj: perhaps change xinput.d/default as well?  (maybe only in oneiric, since it's a conffile so might prompt merges)
<GunnarHj> cjwatson: The reason I didn't include it is that that is just a description of how it used to be, and not part of the actual code.
<cjwatson> you don't think it's effectively documentation?
<cjwatson> hmm, I suppose not really
<GunnarHj> cjwatson: I'm not sure. Happy to change default also if you really want me to.
<cjwatson> GunnarHj: I honestly think this is a bit bizarre though
<cjwatson> LC_CTYPE = character type => obvious choice for input method handling
<cjwatson> LC_MESSAGES = translation selection => nothing to do with input methods
<cjwatson> are you sure the real bug isn't in language selector for failing to set the right set of locale elements?
<GunnarHj> cjwatson: I thought of that; and maybe it is (and/or GDM). But changing the set of env. variable in l-s and gdm is a bigger thing. Could we possibly consider this a hack that is good enough for now, and reconsider l-s + gdm later on (and maybe reverse the hack)?
<cjwatson> GunnarHj: sure, as long as that's borne in mind and recorded somewhere
<GunnarHj> cjwatson: Promise I'll file a bug about it. :)
<cjwatson> thanks
<cjwatson> GunnarHj: uploading to oneiric - I'll do a natty-proposed upload in your name too, if that's OK?
<GunnarHj> cjwatson: Of course it's ok. Thanks!
<cjwatson> GunnarHj: done and done
<GunnarHj> cjwatson: Great, thanks a bunch! Going to write that bug report...
<mterry> doko, perl MIRs done.  phew!
<mterry> doko, I do love doing perl MIRs though.  All the packaging is the same and up to date, all have tests, all pretty simple
<doko> mterry: thanks! promoted
<doko> apw: it's now in the archive (because I forgot to re-enable the testsuite)
<hallyn> jdstrand: so the libvirt folks say phy was never supposed to work for qemu, it's only valid for xen domains.
<hallyn> Daviey: ^  jdstrand was saying this might mess up eucalyptus, that they use 'driver name='phys'' for their xml
<hallyn> so, shall i add a patch to allow phy for one cycle, or will that just make upstreams be lazy and not fix it?
<cjwatson> james_w: does it really make sense for the importer to continue to run on obsolete series (or at any rate to continue to raise MPs for divergences)?
<james_w> cjwatson, is this related to rxtx?
<jdstrand> hallyn: interesting
<cjwatson> james_w: I've deleted the mails now, but I've been seeing a bunch of MPs for edgy/feisty/gutsy; yes, I think rxtx sounds familiar
<SpamapS> pitti: pign, whenever you have a moment.. I have a few people waiting on the squid SRU for lucid.. thanks. :)
<SpamapS> hah..pign.. latin for "mispelled ping"
<james_w> cjwatson, right. I think that the collisions could still happen on old series. They will only be raised if there are new uploads. There are bugs that are causing false positives now though, I think we should fix those and get a robust and useful service
<andyrock> hi all :)
<andyrock> is Sebastien Bacher here?
<chrisccoulson> andyrock, no, i think he's finished for the week now
<andyrock> his nickname is seb128?
<jdstrand> cjwatson: hi! is there any policy for adjust $HOME/lintian on cocoplum?
<jdstrand> s/adjust/adjusting/
<andyrock> chrisccoulson, his nickname is seb128?
<chrisccoulson> andyrock, yes
<andyrock> chrisccoulson, thanks! is here someone else who is in charge of gtk3 packaging?
<chrisccoulson> andyrock, well, the desktop team :)
<chrisccoulson> you'd probably be better off asking whatever question you have in #ubuntu-desktop
<andyrock> ok thanks!
<Daviey> hallyn, Argh!  I think that is a question that really needs upstream comment.
<hallyn> davidcalle: which upstream?
<hallyn> davidcalle: sorry, not you :)
<hallyn> Daviey: which upstream?
<Daviey> hallyn, A question for euca, to see how they would react losing the phy0 interface
<Daviey> If it's no longer supported by libvirt, i'm loathed to carry support for it if there are other options.
<hallyn> they claim it was never supported :)
<hallyn> but documentation online made it seem that way imo, so just pulling the rug out wasn't nice
<Daviey> okay, if upstream break an unsupported interface :)
<Daviey> (upstream libvirt in that context)
<ohsix> whats involved in getting something in the contrib repo? (like java and skype is)
<hallyn> of course ideally i'd first make sure they do use it,
<hallyn> but i can't look at the source code iiuc
<maco> ohsix: psst "partners" repo
<maco> actually, partner, singular, now i think about it
<ohsix> yea that
<ohsix> vmware breaks all the time and it'd be cool if it was in there
<maco> ohsix: http://www.canonical.com/about-canonical/partnerships
<maco> given the name, i think that'd be the page
<ohsix> okie dokie
<maco> Parallels used to be in there
<maco> oh, still are a partner...
<maco> hmm, VMWare is listed as a partner already
<maco> but that just may be about them supporting VMWare running on ubuntu
<broder> ohsix: vmware breaks because they're not keeping up with kernel changes fast enough
<ohsix> ya i know
<broder> and that's not really connected to whether or not vmware is in the partner repo
<maco> yeah, thats pretty much it
<broder> they'd just want to put it in until they fixed it
<maco> 7.1.4 supports 10.10 now that 11.04 is out! oh goody!
<broder> i thought 7.1.3 had the requisite patches...
<maco> yeah it ran fine but was unsupported
<maco> only 10.04 was supported
<broder> anyway, i thought 7.1.4 had the patches to build on 11.04
<broder> oh, nope - i'm still patching to get it to work
<maco> there were patches to make it build with 11.04's kernel since like january
<ohsix> hm
<maco> it didnt work with 11.04's GTK though
<ohsix> maybe a package that'd build the modules that it needed :[
<ohsix> there used to be a package that did that but they were way too old and they started removing some of them
<broder> maco: wait...really? ...because i have 7.1.4 working on 11.04 using the system gtk
<maco> 7.1.4 was released a few weeks before 11.04 came out, finally including patches to work with the new GTK and the kernel, so it'll run on 11.04, but it's not *supported*
<broder> ah, ok
<maco> up through the end of march, you had to find the right thread on the vmware forums telling you what to do with ldd to make it go
<ohsix> hm
<ohsix> it's just a drag; it's one or the other when you're testing alphas/betas
<ohsix> they should have a place in the installer that can apply patches before it builds the thing, and patches semi-easily available
<ohsix> thanks for the info about 7.1.4, going to try it out
<ohsix> it'd be cool to have something like googleearth-package for vmware too; maybe it could be patched there
<ohsix> hm iy certainly couldn't work the same, vmware has the bundles behind a login gate; blah
<cjwatson> jdstrand: it's probably worth attempting to bring it up to date with current lintian at some point, but make sure to keep a backup copy ...
<jdstrand> cjwatson: ack-- for now I just added oneiric, but noted
#ubuntu-devel 2011-05-21
<bluefoxicy>  1531 root      20   0  350m 166m  11m R   85  4.5   0:27.97 update-apt-xapi
<bluefoxicy> what is this process
<cjwatson> update-apt-xapian-index
<bluefoxicy> cjwatson:  it eats a LOT of CPU, for reasons I'm not sure of.
<lucidfox> bluefoxicy, I also ran into that problem
<lucidfox> with update-apt-xapian-index hogging CPU
<ohsix> slow drive / lots of files? it's ran periodically and niced; it will use some cpu to do its work
<lucidfox> "Some" CPU? More like 99%
<lucidfox> not on this computer, on my work one
<lucidfox> Also, what's with the build failures?
<lucidfox> actually, wait
<lucidfox> hrm
<lucidfox> https://launchpadlibrarian.net/72114285/buildlog_ubuntu-oneiric-i386.steadyflow_0.1.6-0ubuntu1_FAILEDTOBUILD.txt.gz
<lucidfox> any idea why this is failing?
<lucidfox> The following packages have unmet dependencies:
<lucidfox>  libnotify4-dev : Depends: libnotify4 (= 0.7.2-0ubuntu2) but it is not going to be installed
<lucidfox> oh right, libnotify4 was removed from oneiric while the package was in NEW? o_O
<ohsix> lucidfox: run it manually and see what it's doing
<ohsix> if it isn't i/o bound i don't see why it wouldn't use the cpu available
<lucidfox> Well, I fixed it already. It failed because libnotify4-dev was not completely removed from oneiric yet, and the buildd never even considered libnotify-dev
<lucidfox> I've removed libnotify4-dev and left only libnotify-dev
<ohsix> interesting
<lucidfox> ...oh what now... dput is not accepting my signature
<lucidfox> Huh, but it did upload
<lucidfox> dput complained on .changes about "verification failed 3 times (no public key)", but then I received a mail saying the package did get accepted
<Laney> launchpad bug
<pitti> hallyn: libcap2> getting it through autosyncs is deal IMHO
<pitti> broder: ah, thanks for confirming; that was my impression, too
<pitti> SpamapS: ok, will do a round of SRU
<cjwatson> doko_: may I merge eina?
<doko_> cjwatson: sure, merge anything you can't resist =)
<cjwatson> heh, just trying to reduce the FTBFS list a bit
<apw> anyone else seeing issues with uploads to ubuntu ?
<cjwatson> apw: if it's just verification-failed messages, ignore them
<cjwatson> it's a known LP bug
<cjwatson> your upload was successful
<cjwatson> (I checked)
<apw> cjwatson, ahh thanks
<cjwatson> oh, for goodness' sake - eina is failing a test of some silly joke function
<cjwatson> and doesn't fail on the porter box
<bluefoxicy> does Cool'n'Quiet work in Ubuntu?
<bluefoxicy> I heard you need powernow-k8 loaded in the kernel
<bluefoxicy> which is compiled in
<hv> is appmenu not working properly at the moment (oneiric)?
<bluefoxicy> yay
<bluefoxicy> my 31 line bash script to monitor my CPU temperature works!
<bluefoxicy> now if my computer is at risk of overheating, it'll send SIGSTOP to a bunch of stuff and then wait for it to cool down.
<ion> How about fixing the cooling instead? :-)
<bluefoxicy> ion:  I tried that, too :)
<bluefoxicy> i suggested also that maybe a small daemon that throttles back the system in interesting ways when the threat of overheating is present would be useful, and people were vehemently against the idea of software fixing a hardware problem
<ion> I should do that for my laptop. The thermal grease probably needs reapplying.
<bluefoxicy> The discussion kind of broke down after I recommended to the entire mailing list to remove everything tied to "fsck" since the real solution is to fix your disk/power source
<bluefoxicy> there's also that silly checksum thing in the kernel, that checks if dirty blocks are corrupted (due to bad RAM) before writing them back to disk; again, the real solution is to replace the faulty RAM ...
<bcurtiswx> i have a 32 bit build machine, is there any way to get it to build a 64 bit debian pacakge ?
<penguin42> I don't see why you can't cross build it
<bcurtiswx> so how do I do that exactly?
<slangasek> it's quite non-trivial today
<bcurtiswx> slangasek, hmm, is there a wiki page I should be referencing?
<penguin42> bcurtiswx: http://wiki.debian.org/BuildingCrossCompilers is one
<penguin42> bcurtiswx: Then there are various bits of magic to actually build the packages - none of them are particularly pretty
<penguin42> bcurtiswx: xdeb/xapt is the one I've used
<penguin42> bcurtiswx: And it doesn't work for all packages
<bcurtiswx> penguin42, OK thanks for the links/help :)
<penguin42> bcurtiswx: Good luck
<slangasek> in theory, an x86_64-linux-gnu-gcc wrapper that simply calls 'gcc -m64 "$@"' would be sufficient, provided that gcc-multilib is installed
<cjwatson> FWIW xdeb and xapt are entirely separate projects
<slangasek> but actually getting the 64-bit dependencies where you need them requires something like xdeb at the moment, yes
<penguin42> yeh? Oh i'd assumed xapt used xdeb
<directhex> do they work?
<penguin42> directhex: Depends on their mood
<bcurtiswx> i thought maybe pbuilder had a special way to create a 64bit build env
<cjwatson> no, both xdeb and xapt use dpkg-cross, but they have different philosophies
<cjwatson> ultimately, we hope both will be replaced by stage<whatever> multiarch
<slangasek> bcurtiswx: the only 64bit build env you can create with pbuilder per se is a *native* 64-bit env; if your machine (or your kernel) is 32-bit, that won't be usable
<directhex> you can do 64-bit kernels on 32-bit debian. but afaik not on ubuntu
<bcurtiswx> slangasek, yeah that makes sense.  Was worth a thought at least
<cjwatson> though, I mean, it's basically the same idea, grab all the dependencies, cross them, install them, build
<penguin42> cjwatson: I don't think I'd succeeded in getting xdeb to fetch dependencies for me
<cjwatson> xdeb tries to do more work for sequences of builds and is more willing to apply heuristics to get there
<slangasek> directhex: well, you can in that you can cross-install an amd64 kernel on your system using multiarch ;P
<cjwatson> it worked for me when I wrote it, but it's been a while since I did any work on it :-)
<cjwatson> it's wookey's problem nowadays
<bcurtiswx> information overload here :) hehe, i appreciate the help tho :)
<penguin42> bcurtiswx: What was the package out of interest?
<bcurtiswx> penguin42, i've rebased seahorse 3.0.0 with debian, it built and I wanted to test it on my 64 bit machine.. i was hoping there was a "fairly easy" way to cross build, but my laptops quite powerful and i'll just build it on here :)
<bcurtiswx> i don't have upload, so i wanted to really verify this package was built well before i went requesting a merge
<penguin42> oh I wouldn't give that a good chance of crossbuilding
<penguin42> but I'm a pessimist
<bcurtiswx> haha, hence my building on my 64 bit laptop
<cjwatson> bcurtiswx: you can use a PPA too, if you like
<bcurtiswx> cjwatson, yup, i have empathy 3.1 on that for interested parties to test, and if i didn't have the immediate availability to this laptop i would
<lfaraone> cjwatson: so in https://launchpad.net/ubuntu/+spec/foundations-o-apt-mirror-method, we'd just use mirror:// rather than having a mirror picker?
<cjwatson> lfaraone: yes
 * bcurtiswx waves to lfaraone
<cjwatson> or at least rather than requiring a mirror picker - we're not out to destroy people's choice, just to make things work better without everyone having to choose
<lfaraone> cjwatson: but would software-properties still have a static list, or would it source its list of mirrors from the mirror method?
<cjwatson> I would hope that it wouldn't matter any more
<cjwatson> but you'll have to ask mvo, I don't know the details of software-properties
<cjwatson> I'm mostly involved in that spec to ensure that the installer is synced up
 * penguin42 hopes it requires a signed reply to the list of mirrors
<lfaraone> penguin42: why would that matter?
<lfaraone> penguin42: if I can MITM the mirror list, I can MITM whichever mirror you select anyway.
<penguin42> yeh I guess so
<lfaraone> that's why we have http://wiki.debian.org/SecureApt
<cjwatson> I suspect, without having asked, that mvo is no great fan of having to keep a static list of mirrors; but we don't have a specific work item for replacing it
<highvoltage> jbicha: congrats on the membership! I thought you were one already :)
<lfaraone> hey bcurtiswx
<lfaraone> cjwatson: hmm. well, I could do that, I guess. If the mirror:// list was defined somewhere, I could just add a hook to software-properties to poll it whenever you go to change the mirror.
<jbicha> highvoltage: thank you, I should have applied sooner
#ubuntu-devel 2011-05-22
<guest345345> Does anyone know if it's possible to use the indicator/notify-osd APIs with the seed JavaScript engine yet?
<guest345345> Or can someone point me to the most relevant mailing list?
<ohsix> does seed have ctypes? you could cheat ;]
<RAOF> craigbarnes: libindicate* has gobject-introspection data, doesn't it?  I'm pretty sure seed can load any introspectable library.
 * persia notes that one can also do amd64 builds on an i386 install using qemu, but that this is painfully slow, and ought be avoided unless one has a very good reason.
<bluefoxicy> what in the friggin hell
 * bluefoxicy burns launchpad down
<bluefoxicy> ?no-redirect okay.
<maco> bdrung_: sorry about that. i woke up this morning and realised i needed to double-check that branch
<bdrung_> np
<shadeslayer> doko_: around?
<shadeslayer> doko_: just wanted to confirm if the toolkit is broken, someone told me you uploaded a gcc build, and i can't seem to build a package ( http://paste.ubuntu.com/611482/ << Build log (
<geser> shadeslayer: is your used mirror uptodate? gcc-4.6 build on all architectures successfully
<leex> hi
<highvoltage> hi leex
<leex> I am currently trying to install ubuntu 11.04 on my machine, but it fails with the rather generic error message: A step failed. Select and Install Software. What should I do? How can I see which package fails? Btw. I am using cryptsetup to decrypt my disks before entering the partitioner. this error happens with both the alternate amd64 daily and alternate amd64 "stable" iso. any hint on how to fix it would be welcome
<highvoltage> perhaps that question is better suited for #ubuntu, you can also get help there on filing bugs, if required
<leex> highvoltage: hmm, I posted my question there like 4 times the last 2 days on got no (let me put it nicely: helping) reply
<holstein> leex: you can try #ubuntu-beginners if #ubuntu is too busy... this is just not that kind of support channel
<leex> holstein: k
<leex> I will, sorry for bothering u guys
<holstein> no worries
<highvoltage> leex: I haven't used it myself, but I'm told that askubuntu.com is fast and very helpful
<leex> bb
<slangasek> bryce, tjaalton: any reason against merging libx11 and friends from unstable?  I think this should be orthogonal to the X server decision for oneiric, but X has surprised me before :)
<djustice> question, a binutils change/update was just pushed, how can i see which repo it was changed in? and how can i see the reason/actual change? besides apt-get source binutils -> debian/changelog i mean..
<persia> How do you mean "which repo"?
<djustice> no problems, just curious about the information's whereabouts.
<djustice> eg, was it pushed as a security change or a normal update?
<Ampelbein> djustice: do you mean something like 'aptitude changelog <packagename>'?
<persia> There are more specific resources for more specific questions, but I'd suggest you look at https://launchpad.net/ubuntu/+source/binutils
<persia> You'll find there all recent uploads into Ubuntu, with details available including changelogs, diffs, etc.
<djustice> Ampelbein: close.. but not exactly what i want. i want to "kompare previous_binutils_debsrc new_bintutils_debsrc" basically..
<djustice> persia: ha! awesome. thanks!
<persia> Or rather, all uploads into Launchpad: seems that it shows unrecent ones, and untrusted ones.
<djustice> haha the 'which repo' was paradigm shift from pacman/cpkg :) the ordered/stacked repo style.
<tjaalton> slangasek: no, go ahead. and, tbh, you could drop the silly delta :)
<slangasek> tjaalton: hum, there are users of that "silly delta" who are likely to reintroduce it if it were dropped, anyway.  Have these changes been forwarded to Debian / upstream and rejected?
<tjaalton> slangasek: yep, rejected
<slangasek> well, feel free to drop that in the next upload, then; there's still a delta in any case right now due to multiarch
<tjaalton> but we can deal with that later, keep it there for now
<tjaalton> right
#ubuntu-devel 2012-05-14
<pp7> how are video file thumbnails generated in ubuntu? sometimes they are generated, sometimes they are not for me
<dobey> pp7: by the totem-video-thumbnailer program usually, which is included in the totem package
<ScottK> pitti (or whoever else might be around to fix it): libboost-graph1.49-dev needs to be in Main to support the transition from 1.46 to 1.49.
<infinity> ScottK: I don't see it on component-mismatches.
<ScottK> That's because it'll cause an FTBFS if we use it now.
<ScottK> Promote it and then we can drop 1.46.
<infinity> ScottK: Any of the other binaries need promoting?
<ScottK> Is all of 1.49 in Universe?
<infinity> (locale, math, random, signals, system, thread, timer, wave, filesystem, date-time, chrono..)
<ScottK> That was the one I was told about?
<infinity> Yeah, it's all in universe right now.
<infinity> Well, not all.  But lots of it. :P
<ScottK> That's the only one needed for kdepimlibs.
<infinity> How about I just promote the whole mess, and let them fall out in c-m later if that's correct.
<ScottK> sounds good to me.
<infinity> Done.
<ScottK> Thanks.
<pp7> dobey, thx
<pp7> dobey, any idea where the thumbnails are stored?
<dholbach> good morning
<pp7> good night
<soren> win 21
<dholbach> soren, win! :)
<nigelb> heh
<soren> dholbach: Not just win. Win 21. Pay attention :)
<dholbach> soren is full of win
<nigelb> win full of 21s.
<hrw> hi
<hrw> srcpackage1 provides binary1, binary2, binary3. Now I want to create srcpackage2 which will provide binary1 while new upload of srcpackage1 will not provide it anymore. what is proper procedure for it?
<hrw> new srcpackage1 can be uploaded and published before srcpackage2 as they do not require/conflict each other
<cjwatson> broder: how about having the tool strip off the backport suffix and then do 'pull-lp-source -d PACKAGE BASEVERSION'?  that seems like it should be easy
<cjwatson> hrw: as long as binary1's version monotonically increases all the way through, just do it - no need for anything special
<hrw> cjwatson: thanks
<cjwatson> hrw: I'd suggest uploading srcpackage2 first, probably, but it's not mandatory
<hrw> ok
<glatzor> cjwatson, pitti  hello collin martin. I have seen that you, Collin, already worked on a python3 port of python-software-properties. We have got a circular dependency here: the gtk part requires aptdaemon gtk3 widgets. So I prepared a small upload which would just provide a python3-software-properties (required by aptdaemon) to upload a python3 based aptdaemon
<glatzor> cjwatson, pitti the branch is located here: lp:~glatzor/software-properties/python3
<glatzor> pitti, furthermore python3 aptdaemon would require that the plugins (e.g. of language-selector get ported too). A small problem here is packagekit (the packagekit.enums is used by aptdaemon and plugins): it seems quite difficult to get it ported to python3. So I decided to ship the enums as aptdemon.pkenums in the aptdaemon package temporarily
<cjwatson> glatzor: just one l in my name :-)  OK, I'm not at work today, I'll check tomorrow if pitti hasn't ...
<glatzor> cjwatson, thanks colin :)
<cjwatson> I hadn't realised that aptdaemon depended on s-p
<glatzor> cjwatson, It is actually only a very small part: the apt key interface. so have a nice day.
<vibhav> Ampelbein: ping
<jgtimmer> hello, I'm wondering what I need to do to get a package from debian-unstable into Quantal ?
<melodie> hi jgtimmer I am in a wonder about that Quantal. What is it ?
<melodie> (stupid question I know)
<melodie> you could bring your package to your ppa, so it will be rebuild for Ubuntu ? then you could add your ppa to your sources.list ?
<vibhav> jgtimmer: Which package?
<vibhav> jgtimmer: Do you mean the Ubuntu Archives for Quantal ?
<jgtimmer> vibhav: yes, I would like to have it in the official ubuntu repositories
<jgtimmer> environment-modules
<jgtimmer> http://packages.debian.org/unstable/main/environment-modules
<gaspa> you should 'just wait', imho.
<vibhav> jgtimmer: Let me take a look
<Laney> yes, it'll come in automatically
<vibhav> jgtimmer: ^
<jgtimmer> ok
<jgtimmer> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=583484
<ubottu> Debian bug 583484 in wnpp "ITP: modules -- provides for the dynamic modification of a user's environment" [Wishlist,Fixed]
<melodie> hi, I would also like to ask a question : how could I get a sponsor to be interested in openbox-menu, which is a very performing program. I have learned to package for Debian and for Ubuntu, just for the purpose of getting it to be adopted officially. I would also want to learn how to package a set of additional files which can be used along with it.K
<melodie> I have followed all recommended steps so far too.
<jgtimmer> it's only in unstable since 3rd of may, I tought it was there for over a year and never made it into ubuntu. My bad. Thank you everyone
<melodie> now I get bunches of mails from the debian-mentors ml
<melodie> it is here and here : http://mentors.debian.net/package/openbox-menu  https://launchpad.net/~meets/+archive/ppa
<jgtimmer> melodie: Quantal is the codename for the next ubuntu release
<vibhav> melodie: YOu can get it into your PPA if you want?
<jgtimmer> I want it in official ubuntu since I'm develloping a program that depends on it, and it's inculsion would make it a lot easier for people using it.
<jgtimmer> just clarifying...
<vibhav> ah
<melodie> jgtimmer, thanks !
<melodie> vibhav, yes, I have done that last night, it's here : https://launchpad.net/~meets/+archive/ppa
<melodie> and also here :  http://mentors.debian.net/package/openbox-menu
<melodie> vibhav, and I have not yet found a doc which explains clearly how to package configuration files provided as addons
<melodie> ?
<cjwatson> jgtimmer: it'll land in quantal in about three or four days (we agreed at UDS last week to restart syncing straight from unstable, but at the moment we're syncing from testing and there's a compiler fix I want to see land before I switch over)
<jono> seb128, quick q: this GNOME remix flavor, this is a community project, right?
<jono> now an official Canonical release
<jono> jbicha, are you working on the GNOME remix?
<jbicha> jono: good morning! yes
<jono> jbicha, hey!
<jono> jbicha, are you leading that project?
<jbicha> I believe I am
<jono> jbicha, ok cool, so this is a community project and not something Canonical staff are working on?
<jbicha> it's not an official Canonical project, there's a bit of overlap as we're using many of the same packages Canonical's Desktop Team works on, but it's a community project like the other desktop flavors
<jono> jbicha, gotcha, awesome
<jono> thanks
<jbicha> I'm definitely hoping the community can help with the ISO testing as that seems the most time-consuming part
<vibhav> nigelb: ping
<nigelb> vibhav: pong
<melodie> I would like to join a project around Openbox, and I wonder if someone here is interested in using Openbox ? Either alone or with DM's else than Lxde ?
<nannes> hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii
<nannes> I need to kill someone of you... any volounter?
<maco> !ops
<micahg> !ohmy | nannes
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<highvoltage> so in LP blueprints, it says that "workitems_text: The milestone 'quantal-beta-1' is not valid for the target 'ubuntu'."
<ubottu> nannes: 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.
<highvoltage> but it's happy with quantal-alpha-1
<highvoltage> am I doing something wrong?
<nannes> ehy ehy I'm joking!
<nannes> I have a serious question :D
<nannes> it was just to have attention :P
<maco> highvoltage: might be just quantal-beta?
<highvoltage> maco: I tried that, but it didn't work either
<maco> highvoltage: maybe no dash between beta and 1?
<highvoltage> tried that, too :)
<lamont> !justask
<ubottu> Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) See also !patience
<micahg> highvoltage: https://launchpad.net/ubuntu/quantal/
<highvoltage> maco: ah, it's "ubuntu-12.04-beta-1"
<highvoltage> I guess it changes to version number at beta time.
<highvoltage> thanks, micahg
 * micahg hopes quantal's version isn't 12.04
<micahg> hmm, why does armhf show as unofficial for quantal...
<micahg> infinity: ^^
<nannes> I have to install ubuntu on 30 PCs of a network. So I'll use network installation. The issue is: I have an already-configured ubuntu-box by which I made an image .img. I need to install *that* image to the others PCs cause it's been already set correctly!!
<nannes> How can I do that?
<highvoltage> (12.10, even :) )
<lamont> nannes: that's a question for #ubuntu... this channel is for discussing 12.10 development
<nannes> they said me to come here :/
<lamont> interesting
<nannes> not them, but from #ubuntu-it chan
<lamont> ah. yeah, #ubuntu is the right channel for non-development questions about released versions of ubuntu
<mneptok> nannes: that kind of attention-grabbing is most unwelcome.
<nannes> ok sorry
<mneptok> nannes: any repeat behavior, or even anything close to the line at this point, will be met with the banhammer. clear?
<nannes> what is a banhammer?
<mneptok> nannes: you will be banned from any #ubuntu* channels in which you repeat such behavior. you will not be able to speak, join or otherwise participate.
<nannes> oh
<Laney> erm
<Laney> can we lower the temperature a bit?
<seb128> jono, hey, yes what jbicha said, we will mostly help by making sure we keep it's easy to turn off the Unity integration bits when possible but the image itself will be community built and maintained
<jono> thanks seb128
<seb128> yw
<seb128> jono, I've been careful in the wrapup to say it was a community effort so hopefully nobody took it the wrong way
<melodie> nannes, have you had a look at UDPCast ?
<nannes> uhm no..
<nannes> they're telling me to use clonezilla
<nannes> (on #ubuntu)
<cousteau> is bug 984878 already fixed?  its status is "GTK+: fix released; gtk+3.0: fix commited; Precise: in progress"
<ubottu> Launchpad bug 984878 in gtk+3.0 (Ubuntu Precise) "Add annotation button missing" [Low,In progress] https://launchpad.net/bugs/984878
<melodie> well udpcast is different I think because it is supposed to copy to several machines at same time. I leave to you to look at the udpcast page on the we
<melodie> on the web
<cousteau> I don't know what does "in progress" exactly mean
<Guest62023> ciao
<Guest62023> !list
<ubottu> Guest62023: No warez here! This is not a file sharing channel (or network); read the channel topic. If you're looking for information about me, type Â« /msg ubottu !bot Â». If you're looking for a channel, see Â« /msg ubottu !alis Â».
<nannes> ok!
<melodie> nannes, would you know where I could find some devs interested in a openbox desktop project ?
<melodie> I need help for several things such as how to package files (not program, but addon files)
<nannes> melodie: hmmmm what kind of project?
<melodie> I have done openbox versions of a distro during these last years and I have a good recipe for it, so I would like to do the same at Ubuntu now.
<melodie> I started to cook : learned to make a debian package and sent to mentors and last night to ppa too
<melodie> a program which allows to have fresh menus all the time, along with configuration files (this I have to do) which can be installed once and tweaked later
<melodie> I mean can be used as is and tweaked also if the user whishes to do so
<melodie> it allows having a the equivalent of a full desktop using openbox with a few additional programs
<melodie> and not the hard way, the easy way.
<melodie> any idea ?
<nannes> Dunno if I'm understanding completely (i'm not english), so: you just did a customization of openbox to make it simpler and with some programs which you consider useful, and now you wanna make this compatible with ubuntu by making a deb installation package?
<melodie> nannes, I have used this program for several years, have gathered relevant config files, adapted them for Ubuntu and Debian, did a package for Debian : is at debian-mentors now, and a package for Ubuntu : is on a ppa now, and I look for someone who will teach me how to do a package out of the configuration files. and also a few more details such as how to add post-install messages.
<melodie> this is what I need most, and more if there is interest for a Ubuntu Openbox remix project.
<nannes> hmmmmm sorry I dunno exactly... I'd ask openbox community if were you
<melodie> nannes, now that you say... probably.
<nannes> or also, ask big dev communities online, make your project and people will come
<nannes> google code, github, sourceforge
<melodie> nannes, I can do that indeed; I am still astonished to see that none can tell me about a howto somewhere which will let me know how to do a simple package with config files ? no need to compile, just package and indicate in which directories it goes and...
<nannes> aaaaaaaaaah you just need that?? xD
<melodie> and post install message howto.
<nannes> I thought it was a compiling problem XD
<melodie> nannes, yes, that can help me go further
<nannes> so I can do it, too! Or better, I can link you a good guide to do that. It's about Bash-scripting
<mneptok> melodie: https://wiki.ubuntu.com/PackagingGuide/Complete
<melodie> argh ! bash scripting !
<seb128> you can try http://pkgme.net/README.html
<melodie> mneptok, thanks. I hope there is a howto for files too in that guide.
<melodie> seb128, thank you
<seb128> yw
<mneptok> melodie: if there is not, it is only because that guide references the Debian Packaging Guidelines for such info. i'm not sure, as i have not read all those docs. but they should be complete, either self-contained or referentially.
<melodie> I keep the links, will read the pages ASAP and will come back ask help if there are some things I don't understand.
<melodie> nannes, what about your guide ? never know it could be another one ?
<nannes> uhm it's a bit different, it's not a real "package"
<nannes> follow their guides ^
<melodie> nannes, ok. thanks
<melodie> I have downloaded both pages.
<nannes> Prego! :D
<melodie> :-)
 * nannes goes to study the modern novel -.-
<melodie> bye
<SpamapS> hey everybody.. you know, 12.04 is so awesome.. I was thinking.. we should do another release... perhaps around October? Who's in!?
<nannes> lol..
<nannes> SpamapS: I think there will be the october release like every year...
<SpamapS> nannes: *fantastic* idea
<SpamapS> perhaps we should just release Ubuntu every 6 months. :)
<nannes> oh god, no. It's just too pain ever 8months, don't increase the pain
<bazhang> !ot > nannes
<ubottu> nannes, please see my private message
<highvoltage> hwh @ SpamapS
<highvoltage> (heh, even)
<nannes> bazhang: maybe that message should be sent to SpamapS, too! why only me?
<bazhang> nannes, lets keep chit chat elsewhere. thanks.
<arges> bryceh, hello! was wondering if there is a good basic ubuntu X benchmark for 2d/3d ? I was going to use glxgears and gtkperf... but wanted to check if there was something else that would be helpful.
<bryceh> arges, oh stay away from glxgears
<arges> bryceh, : ) ok what do you recommend? just something simple
<bryceh> arges, what I generally recommend is snag some 3D game and run it with fps display turned on
<arges> ok.
<bryceh> arges, if you're looking to use it in an automated testing framework thingee, check out the phoronix test suite; they have collected run scripts for various games
<arges> bryceh, ok... i think i just need a measuring stick to see... well this performance really is *bad* at more of  quantitative than qualitative level
 * bryceh nods
<arges> and the use case is more of regular desktop usage than games
<arges> thanks
<bryceh> arges, I don't know offhand if any of the unity code supports fps display but if so that might give you a more accurate measure
<arges> yea. need to find out if this is on lucid or precise too...
<bryceh> however the nice thing with games is they generally exercise a fairly broad range of GL operations so the measures tend to be more realistic and actually do have some relevance even for desktop compositing
<directhex> there's a compiz plugin for FPS
<arges> bryceh, yea rending some low poly gears probably isn't the best indicator of performance : )
<arges> directhex, ok that's good to know.
<AlanBell> it is the benchmark plugin, then super+F12 to display it
<AlanBell> not massively useful as compiz doesn't go faster than it needs to
<dobey> pp7: thumbnails are stored according to the thumbnail spec. which i think puts them in .thumbnails
<dobey> err, ~/.thumbnails
<pp7> mmm thx for the late reply :) :)
<pp7> but i dont see the thumbnails that i expect there
<melodie> hello
<highvoltage> hello melodie
<melodie> hello highvoltage :)
<melodie> this nick is nice
<dobey> pp7: well if it's not making the thumbnails, they won't show up there :)
<dobey> pp7: depending on the format, it might not be able to thumbnail them
<pp7> dobey, i just want all of my video thumbnails to show
<pp7> dobey, sometimes even the same format works and sometimes doesn't
<dobey> barry: ping. :)
<barry> dobey: pong!
<dobey> barry: is there a wiki page with what control/rules/etc needs exactly to build something for python3 and python2 both?
<barry> dobey: there is indeed! http://wiki.debian.org/Python/LibraryStyleGuide
<dobey> nice, thanks!
<dobey> barry: hrmm, it seems to only list the X-Python3-Version bit as part of the source package info in the control. :-/
<barry> dobey: right.  what are you looking for?
<dobey> barry: presumably there is a minimal python3 version to depend on that supports dh_python3, like there is for python2
<dobey> would be nice to document what it is exactly :)
<barry> dobey: i think that field's intended to indicate the minimum python version that the upstream package is compatible with.  in general i'm lazy and don't care about anything < 3.2, so i just set it to >= 3.2.
<dobey> barry: right, but i'd expect it to talk about Build-Depends(-Indep) as well at some point
<barry> dobey: probably worth it, but it's not come up before.  it's a wiki of course so feel free to add it :)
<dobey> it's also apparently an immutable page, and i don't have an account, which i'd rather not create anyway :)
<dobey> ah well
<barry> dobey: if you have suggestions for better info, feel free to email them to me and i'll update the page
<dobey> and apparently i need to port yet more deps first (yay dependency hell)
<barry> ;)
<dobey> well, as a start, it might be good to fold in some info from http://wiki.debian.org/Python/TransitionToDHPython2 or at least link to it. currently there's a link to http://wiki.debian.org/Python/dh_python2 which doesn't exist, though :)
<barry> dobey: thanks, fixed
<dobey> why do i always pick the annoying/hard things to do?!
<dobey> python-testtools has a build-depends on python-fixtures. python-fixtures has a build-depends on python-testtools
<barry> yay for circular dependencies!
<dobey> and testtools needs twisted for some tests
<dobey> yay!
<dobey> :(
<infinity> I assume python-fixtures build-deps on python-testtools for a testsuite, so upload python-fixtures without the build-dep and the suite disabled, then python-testtools, then python-fixtures with the suite enabled.
<infinity> If that guess is incorrect, then... Have fun. ;)
<infinity> (If it really does end up needing a manual bootstrap, let me know, but I suspect it can be done cleverly like the above)
<dobey> well, would be nice to just get rid of circular deps
<infinity> They exist all over, for that sort of reason.
<dobey> sure, but doesn't mean they should :)
<infinity> If my wild guess is correct, I'd argue that the circular build-dep absolutely should exist.
<infinity> You can use DEB_STAGE to make it a non-issue for bootstrap builds, but "not running a testsuite to avoid a circular dep" would be silly.
<dobey> infinity: the only way i would agree that such a dep *should* exist, is when both pieces are part of the same source. otherwise, i'd say if your tests depend on something which depends on you, your tests are just broken anyway. :)
<infinity> dobey: That position gets harder and harder to defend when you're testing things like make, shell interpreters, compilers...
<infinity> dobey: Ultimately, you have to account for that fact that test harnesses need to be made out of, well.  Something.
<dobey> i don't think it's hard to defend at all :) though i do agree there are special cases where it can be more complex, such as with a compiler that eventually gets rewritten into the language it compiles. but random libraries don't really fit into that corner case :)
<infinity> dobey: Well, unless you insist that python testsuites not be written in python, there's a fair chance that, eventually, there will be a circular dep, unless the testsuite also uses nothing outside of python core.
 * infinity shrugs.
<Bluefoxicy> what
<Bluefoxicy> I installed Japanese language support and there is no Japanese input in Precise?
 * Bluefoxicy goes looking through synaptic for the relevant anthy packages :|
<Bluefoxicy> ok it's already installed, then ...
<dobey> oh i am doing something i apparently don't actually need to do exactly.
<dobey> lifeless: do you know why we're maintaining changes to python-testtools source in ubuntu?
<lifeless> dobey: no idea why; we shouldn't be :)
<dobey> lifeless: care to update it to 0.9.15 in debian and sync it over to quantal? :)
<lifeless> dobey: I'm going to hand it over to the python maint team in debian
<dobey> ah ok
<lifeless> dobey: what patches are we carrying ?
<dobey> lifeless: no patches, but maybe a watch file or couple of things.
<lifeless> oh, so just a different package? Presumably someone updated it post freeze or something
<lifeless> anything important or can we just splay over it
<dobey> i don't know if any of it's important or not, but i suspect not
<dobey> lifeless: and the debian one has python3 support
<dobey> also looks like debian one has a watch file
<dobey> doesn't look like debian package is running tests right now, while ubuntu seems to be, but i think we can fix that later, and just replace with the debian version for now
<dobey> though updating to the new release would be good as well :)
#ubuntu-devel 2012-05-15
 * semiosis is back.
 * semiosis is away.  please leave a /msg
 * semiosis is away.  please leave a /msg
 * semiosis is away.  please leave a /msg
<Tm_T> semiosis: could you turn that off please?
<semiosis> yes i did already, very sorry about the malfunction!
<semiosis> :(
<Tm_T> np (:
<malkauns_> in 12.04 why do i have this window shadow glitch? http://i.imgur.com/7bTMK.png
<JonEdney> I kinda like it
<malkauns_> it may look nice there but trust me it gets annoying
<JonEdney> I can imagine.  You may want to check out #ubuntu, it's active right now - been kinda dead in here.
<malkauns_> heh
<dobey> also, #ubuntu is where to go for general help, not here :)
<EvilResistance> mhm
<pitti> Good morning
 * slangasek waves
<nigelb> Guten morgen pitti
<highvoltage> perl: warning: Setting locale failed.
<highvoltage> perl: warning: Please check that your locale settings:
<highvoltage> 	LANGUAGE = (unset),
<highvoltage> 	LC_ALL = (unset),
<highvoltage> 	LANG = "en_ZA.UTF-8"
<highvoltage>     are supported and installed on your system.
<highvoltage> perl: warning: Falling back to the standard locale ("C").
<highvoltage>  ________
<highvoltage> < pitti! >
<highvoltage>  --------
<highvoltage>         \   ^__^
<highvoltage>          \  (oo)\_______
<highvoltage>             (__)\       )\/\
<highvoltage>                 ||----w |
<highvoltage>                 ||     ||
<highvoltage> (oops)
<pitti> that's during dist-upgrade?
<highvoltage> I think my container just isn't set up properly (I think I just need to install some langpacks)
<pitti> at least a locale
<stgraber> highvoltage: is that on Ubuntu (the container)?
<stgraber> highvoltage: if so, you might be hit by a remaining apparmor glitch where for some reason /usr/lib/locale/local-archive can't be generated from within the container
<stgraber> highvoltage: copying it from the outside to /var/lib/lxc/<container>/rootfs/usr/lib/locale/locale-archive will "fix" it
<RAOF> Good morning pitti :)
<stgraber> jjohansen: I think I forgot to poke you about that one. I thought it was fixed a while ago but apparently it wasn't. localegen can't generate it and apparmor doesn't log any reject, so a bit tricky to figure out
<pitti> hey RAOF, how are you?
<RAOF> Home! :)
<nigelb> RAOF: How many hours did it take this time? :D
<RAOF> Good.  I slept well, and woke :)
<nigelb> (didn't you have fun returning back from the sprint?)
<RAOF> nigelb: In terms of flight time, not much - just only 19ish hours.  In terms of door-to-door time, somewhat worse due to the 6hr layover in Melbourne.  But I got to have a shower and change my clothes there, so that was good.
<RAOF> Yeah, lots of fun getting back from the sprint!
<RAOF> Nothing like that this time :)
<nigelb> Heh
<micahg> any SRU team members around?
 * micahg looks for infinity or SpamapS
<micahg> pitti: can I get a pre-SRU ACK please on bug 939863 (we'd like to roll it into a security update to save on the churn), it's a textual change
<ubottu> Launchpad bug 939863 in libav (Ubuntu Precise) "Warning message from ffmpeg program needs update" [Low,In progress] https://launchpad.net/bugs/939863
<pitti> micahg: that's http://anonscm.debian.org/gitweb/?p=pkg-multimedia/libav.git;a=blob;f=debian/patches/04-ffmpeg-warning-change.patch;h=0472d450a743ff0b3918c80e91da16d4c4b35d2b;hb=HEAD ?
<pitti> what difference does it make? the old and new texts by and large say the same?
<micahg> pitti: yeah, it's less inflammatory WRT the libav/ffmpeg split
<pitti> heh, ok
<pitti> seems fine to me, it's not translated anyway
<micahg> ok, thanks
<micahg> I'll upload to quantal tomorrow as my jet engine laptop keeps shutting off when I build it
<sladen> make -j1
<micahg> yeah, I suppose I could disable parallel
<micahg> infinity: SpamapS: unping
<mitya57> mvo: done, see bug 999501 (and it's now linked to the merge request)
<ubottu> Launchpad bug 999501 in app-install-data-ubuntu (Ubuntu) "[SRU] Please fix description for unity-mail" [Undecided,New] https://launchpad.net/bugs/999501
<mitya57> mvo: can you please add a precise target?
<dholbach> good morning
<mvo> mitya57: thanks, I add the precise target now
<dholbach> am I right in thinking that  dh with=python2  won't work as intended? :)
<dholbach> (I'm asking because I'd like to update python-django{,-south} in quantal)
<pitti> dholbach: you mean "dh --with=python2"?
<dholbach> yes
<dholbach> pitti, yes :-)
<dholbach> I believe it is misspelt in Debian's python-django-south and I'd forward the patch if necessary
<elky> Am I correct in thinking that bug #997891 just needs to be reviewed by the SRU team now?
<ubottu> Launchpad bug 997891 in sphinx (Ubuntu Quantal) "sometimes cannot build pdfs for de, sl, pt, es, nl, pl, or it locales" [Undecided,Confirmed] https://launchpad.net/bugs/997891
<cjwatson> dholbach: I'd be surprised if that didn't just fail hard with "dh: Unknown sequence with=python2"
<geser> elky: only as a 2nd step. First it needs to get uploaded (sponsored) by someone and then the SRU teams reviews it from the upload queue.
<elky> geser, well i can't do any kind of uploading, who should I poke? :)
<geser> elky: the bug is in the sponsoring queue, I assume the queue should start processing soon again as all the patch pilots are back from UDS
<elky> ok cool :)
<StevenK> s/back/recovered/
 * elky hides from StevenK
<StevenK> Muahaha
<elky> eep!
<geser> elky: don't hide from StevenK but hunt him instead to sponsor your bug
<elky> ooh, good idea
 * StevenK glares at elky.
<elky> wasn't my idea!
<StevenK> elky: Do you have a debdiff?
<elky> I seem to recall you several times trying to get me to do this stuff. You should be over the moon with happiness!
<StevenK> elky: Haha
<elky> StevenK, it's attached to the bug
<StevenK> elky: Catalyst!?
<elky> I don't live in your country anymore.
<StevenK> elky: Yes. This is a *bug*.
<elky> Sydney nearly killed me
<StevenK> :-(
<jsimmons> Hay, anyone know how I can get ubuntu to use libGL.so from fglrx instead of mesa's
<elky> StevenK, it's perfectly fine if you telecommute. the other commute is less fine.
<jsimmons> if I remove the mesa libraries, it cannot then find libGL at all, although it shows up fine in ldconfig. I guess that there's something broken in my setup such that ld can't find the library?
<elky> StevenK, did you find the debdiff yet? :P
<StevenK> elky: I'm building a source package.
<StevenK> elky: Don't make me come over there.
<elky> Would that work?
<elky> aww, we made him feel ignored :(
<StevenK> elky: My first upload to quantal done.
<elky> Now the precise one? :P
<vibhav> Is it fine to SRU new upstream relleases?
<dholbach> cjwatson, it doesn't seem to fail when using '--with=python2'
<StevenK> elky: Yes, yes.
<elky> vibhav, https://wiki.ubuntu.com/StableReleaseUpdates?action=show&redirect=SRU#New_upstream_microreleases
<vibhav> thanks
<elky> StevenK, so if I pestered enough, would you bring Sarah? :P
<StevenK> elky: Likely
<elky> woo!
<StevenK> Haha
 * elky sits here poking StevenK in the ribs.
<StevenK> That will not make me upload quicker.
<vibhav> heh
<cjwatson> dholbach: well, --with=python2 is the correct spelling, so that's not surprising :-)
<dholbach> oh?
<cjwatson> You asked about with=python2
<dholbach> but "--with python2" works too
<cjwatson> --with python2 is fine as well
<dholbach> ok, then we're good
<dholbach> thanks cjwatson :)
<dholbach> then doko once corrected me for nothing :)
<StevenK> elky: precise-proposed also uploaded.l
<elky> :D
<StevenK> s/l$//
 * elky hugs StevenK
<cjwatson> normal getopt_long style semantics
<StevenK> elky: My bill is in the mail. :-P
<elky> I'll send you pineapple lumps?
<StevenK> How about beer?
<elky> Would that make it through customs?
<StevenK> I don't see why not.
<elky> kiwis on one side, aussies on the other?
<StevenK> elky: Did you get the two e-mails from the uploadprocessor?
<elky> not yet, gmail might be lagging
<elky> oh wait, they would have gone to my catalyst address... sec
<StevenK> Ha ha
<elky> or not?
<elky> maybe greylisting
<StevenK> I can't check *that*, sadly.
<elky> yeah, it's not a terribly long one, but it is there
<StevenK> I thought people came to the conclusion that greylisting is now pointless.
<pitti> oh, is it?
<elky> the janitor hit the bug, so i guess that's something
 * pitti still uses it on his servers
<elky> it cuts out a fair bit still
<elky> and in all fairness, one less is worth it.
<StevenK> I get about 1 spam a day through my filters.
<StevenK> Mostly none
<elky> still no mails :(
<doctorpepper> hi guys !!!
<doctorpepper> is anyone from the libdbusmenu/appmenu  in here ?
<dholbach> doctorpepper, it might help if you just ask whatever specific question you have - if nobody replies, you could try #ubuntu-desktop as well
<apw> anyone seen reports of network manager dropping valid network connections, likely at about the dhcp refresh time intervals?
<doctorpepper> dholbach:  actually  i am hitting a bug
<elky> he's asking you to describe it.
<dholbach> doctorpepper, I'm not a libdbusmenu/appsmenu expert, but you could for example mention which bug (maybe bug number) it is, and say that you're up for providing more information, etc.
<elky> StevenK, seems like I'm not getting the mails
<doctorpepper> when  running gtk3  apps on kde  with the appmenu  applet on the top pannel   the menu are exported to the appmenu applet  but  also visible and functionnal on the  application window
<StevenK> elky: I can forward them if you wish.
<elky> StevenK, please do :)
<doctorpepper> for instance  i have this problem with gedit  but dont have it with gimp-2.8 or inkscape
<dholbach> doctorpepper, ok - if nobody answers here, I'd suggest filing a bug report (https://help.ubuntu.com/community/ReportingBugs) and adding all the information you have - you could also try raising it in #ubuntu-desktop - in any case a bug report will be helpful
<cjwatson> infinity: do you know anything about the eglibc/armhf build failure?
<cjwatson> gcc-4.6 -fno-stack-protector -U_FORTIFY_SOURCE -march=armv5t -mfloat-abi=soft ../ports/sysdeps/unix/sysv/linux/arm/sysdep.S -c -isystem /build/buildd/eglibc-2.15/debian/include  -I../include -I/build/buildd/eglibc-2.15/build-tree/armhf-armel/csu -I/build/buildd/eglibc-2.15/build-tree/armhf-armel -I../ports/sysdeps/arm/elf -I../ports/sysdeps/unix/sysv/linux/arm/eabi/nptl -I../ports/sysdeps/unix/sysv/linux/arm/eabi ...
<cjwatson> ... -I../ports/sysdeps/unix/sysv/linux/arm/nptl -I../ports/sysdeps/unix/sysv/linux/arm -I../ports/sysdeps/unix/sysv/linux -I../nptl/sysdeps/unix/sysv/linux -I../nptl/sysdeps/pthread -I../sysdeps/pthread -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../ports/sysdeps/unix/sysv -I../nptl/sysdeps/unix/sysv -I../sysdeps/unix/sysv ...
<cjwatson> ... -I../ports/sysdeps/unix/arm -I../ports/sysdeps/unix -I../nptl/sysdeps/unix -I../sysdeps/unix -I../sysdeps/posix -I../ports/sysdeps/arm/eabi -I../ports/sysdeps/arm/fpu -I../ports/sysdeps/arm/nptl -I../ports/sysdeps/arm -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I../ports -I../nptl  -I.. -I../libio -I. -nostdinc ...
<cjwatson> ... -isystem /usr/lib/gcc/arm-linux-gnueabihf/4.6/include -isystem /usr/lib/gcc/arm-linux-gnueabihf/4.6/include-fixed -isystem /build/buildd/eglibc-2.15/debian/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h       -DHAVE_INITFINI -DASSEMBLER  -I/build/buildd/eglibc-2.15/build-tree/armhf-armel/csu/. -pipe -O2 -fstrict-aliasing -g  -Wa,--noexecstack   -o ...
<cjwatson> ... /build/buildd/eglibc-2.15/build-tree/armhf-armel/csu/sysdep.o -MD -MP -MF /build/buildd/eglibc-2.15/build-tree/armhf-armel/csu/sysdep.o.dt -MT /build/buildd/eglibc-2.15/build-tree/armhf-armel/csu/sysdep.o
<cjwatson> {standard input}: Assembler messages:
<cjwatson> {standard input}:302: Error: lo register required -- `add pc,r3,#(0xffff0fc0-0xffff0fff)'
<cjwatson> oops, sorry, that was longer than I expected!
 * nigelb blinks
<elky> is this where we point and laugh?
<mlankhorst> why do I get this error when trying pbuilder-dist on precise?
<mlankhorst> distro_info.DistroDataOutdated: Distribution data outdated.
<mlankhorst> I'm guessing it's lacking quantal data, but why does it have to be a fatal error ._.
<cjwatson> mlankhorst: upgrade to the most current available distro-info-data
<cjwatson> (you're not the first person to point out the awkward error handling; it's been looked at)
<mlankhorst> hm, didn't have -updates enabled
<hrw> ok, did first uploads to quantal.
<hrw> should I contact someone about my binutils-{armel,armhf}-cross packages which went into NEW or just wait for them to be processed?
<geser> wait (unless it's really urgent)
<hrw> geser: it is not so will just wait
 * mterry is rocking out to dholbach's Flashing Lights mix
 * dholbach hugs mterry :-)
<dholbach> mterry, I'm glad you like it - it's what kept me from falling into bed too early yesterday :)
 * highvoltage loaded the link but the flash applet didn't want to play the actual track :'(
<mterry> dholbach, heh.  :)  It's good!
<dholbach> highvoltage, really? that's weird
<highvoltage> dholbach: ah just figured it out, what I thought was the flash applet was just javascript, and the actual flash was blocked by flashblock, got it playing now :)
<pitti> urgh, just filed bug 999711 -- we're getting dangerously close to bug 1e6!
<ubottu> Launchpad bug 999711 in pygobject (Ubuntu Precise) "pygobject 3.2.2 stable update" [Undecided,New] https://launchpad.net/bugs/999711
<ubottu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
 * pitti wonders what kind of bug mpt will file this time
<highvoltage> thanks dholbach, that's really relaxing.
<cjwatson> yofel: I gather you're working on KDE SC 4.8.3 packaging, and ScottK suggested I should talk to you about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672553.  I've reached the point where this and some archive admin are the only things blocking me uploading a Python 3 port of ubiquity to quantal; would it be OK if I uploaded that patch in advance of Debian?  That is, are the package names OK, or would they need to be ...
<ubottu> Debian bug 672553 in pykde4 "pykde4: Add Python 3 support" [Wishlist,Open]
<cjwatson> ... python3-pykde4* instead (I noticed the Qt bindings are named differently between Python 2 and 3)?
<yofel> looking
<mterry> chrisccoulson, I'm scheduled to patch pilot this thursday.  You are scheduled next thursday.  I'm looking to switch, if you're interested
<seb128> mterry, just do your shift today if you have time? there is no desktoper on schedule
<mterry> seb128, well, I'm trying not to do it this week at all
<seb128> mterry, oh ok, I guess just move it, there is no strict need to find somebody to swap with
<seb128> mterry, I might do some sponsoring on thursday, I skipped my turn during UDS
<mterry> seb128, you're so blase!
<seb128> lol
 * mterry wishes blueprints didn't spam everyone all the time
<mterry> I feel like I'm standing over the shoulder of someone as they update a blueprint
<cjwatson> wg 38
<cjwatson> doh
 * mneptok has an odd moment of synchronicity
<mneptok> mterry: earlier i *almost* said "cjwatson: i just read Proust's _Remembrance Of Things Past_. it was awesome! want me to paste it?"
<mneptok> mterry: if you want a *painful* blow-by-blow account of every small detail, those are the books for you.
<yofel> cjwatson: not sure there either, but looking at the debian python policy the naming convention seems to result in python3-pykde4. So I would go with that
<mterry> mneptok, :)
<infinity> cjwatson: I haven't had a chance to dig into it yet, but something's emitting v7 instructions, and then having a sad.  I'm still trying to kick a nasty flu here.
<ogra_> infinity, welcome to the club
<ogra_> though my flu turned out to be a pneumonia
<highvoltage> ogra_: still have it? you should really be resting.
 * ogra_ just spent a horrid night with his chest wrapped in pepper patches ...
<ogra_> it waqs like sleeping (or rather not sleeping) in hellfire
<alo21> hi all
<alo21> after pbuilder-dist <release> build ../<package>_<version>.dsc , I cannot find my .deb file
<ogra_> highvoltage, well, the fever is down and i am getting bored .... cant do much physical stuff but typing works :)
<alo21> why?
<highvoltage> hey alo21, #ubuntu-packaging and #ubuntu-motu might be a better place for that
<alo21> highvoltage: thanks
<ogra_> dholbach, hmm, i got a membership renewal mail for ubuntu-sponsors ... do i need to renew that individually ? i though ubuntu-dev would be automatically a member of it
<ogra_> (or ubuntu-core-dev at least)
<dholbach> it isn't and I can't remember the reasoning for it in the beginning
<infinity> Because sponsorship is a voluntary thing.
<infinity> If there was a group that was an intersection of ~canoical and ~ubuntu-core-dev, maybe you could make them all members of ~ubuntu-sponsors, but we can't force all community devs to be sponsors if they don't want to.
<ogra_> why not ?
<xnox> slangasek: you are merging faster than I can create merge proposals ;-)
<maco> even if you're in the team, it's still up to you whether you ever DO actually get around to sponsoring anything at all
<ogra_> the tech board could define that as a requirement for core-dev members
<infinity> Because that's not how "voluntary" works. :P
<ogra_> if the rules for that team are like that ...
<infinity> ogra_: Retroactively defining what core-dev means might not go over well.
<ogra_> no, not retroactively indeed
<ogra_> i always thought it was a part of core-dev to be a sponsor
<infinity> Nope.
<maco> i always had the impression that being one did kind of imply you were up for mentorship type stuff
<infinity> And now you know. ;)
<ogra_> heh, yeah
<highvoltage> maco: well, I guess someone wouldn't sign up for something with that much responsibility without being willing to take the responsibilities that comes with it :)
<Laney> I don't really see being a member of ~ubuntu-sponsors as giving me any additional responsibilities
<maco> if a core dev said no to being directly asked to sponsor something, i'd expect some justification either of the "it's wrong" "i'm working on another package" or "oh god, grub? don't ask me!  ask cjwatson!!!" variety
<Laney> It's just that I wouldn't be able to remove sponsors from bugs if I weren't.
<infinity> maco: Being able to upload and being willing to review and sponsor uploads for others don't seem to be immediately related, even if most of us do both.
<infinity> (And I imagine some people would rather not have the nagging bug mails if they prefer to never sponsor)
 * infinity shrugs.
<maco> i got nagging bugmail from being on the sponsors team?
<maco> i dont remember that
<infinity> I have no strong opinions, given that I'm a member of both teams, and most of us are, but I see no point in redefining it now.
<maco> but then i did get a ton of bugmail already from taht summer i triaged a few hundred bugs...
<SpamapS> ugh, its almost unbelievable how badly borked lp:ubuntu/juju is..
 * SpamapS gives up trying to fix it with bzr rename
 * ogra_ notes that juju means something like "magic"
<ogra_> SpamapS, swing your wand !
<Laney> push --force (overwrite?) it if you have a better packaging branch
<SpamapS> Laney: I'm told that will forever preclude the package importer from working
<Laney> isn't that what you want?
<SpamapS> no, I want to be able to work in harmony w/ the importer
<yofel> cjwatson: otherwise the patch looks fine to me, as I need to upload pykde 4.8.3 I can add your patch with right names and upload it today
<SpamapS> I'm happy to "own" it and push to it most of the time, but if somebody does an upload for some other reason.. I need the importer to record it there, or I'll revert something
<SpamapS> Laney: and really, UDD is supposed to work *for* us, not against us.
<SpamapS> It worked fine when I was the only one pushing
<Laney> well, you can have distributed development without the package importer
<SpamapS> but then the importer did something vile and now I can't merge-upstream
<Laney> you'd just have to be on top of not missing non-UDD uploads
<Laney> which I agree could be annoying
<SpamapS> I've reported a bug in bzr at this point, but its really confusing and I'm just done w/ it.. :-/
<SpamapS> The response was to try and "let it do that" and then fix w/ renames
<SpamapS> but I already tried it and got a few of the renames wrong.. (80+ files get moved to $dir.moved)
<SpamapS> Which I don't understand at all. I should be able to just import the upstream source and have that be the "source of truth"
<cjwatson> mneptok: smartass :)
<slangasek> xnox: you can still create a merge proposal for the precise branch, if you like ;)
<cjwatson> yofel: ok, python3-pykde4 is fine by me.  will you sync that into quantal as well?
<cjwatson> infinity: ah, so this is just a side-effect of the known compiler problem?
<xnox> slangasek: I did now.... =) I guess I will experience SRU process first-handedly now.
<slangasek> xnox: :)  Speaking of which, can you please update the bug description with the needful from https://wiki.ubuntu.com/StableReleaseUpdates#Procedure ?  (At minimum, the [Test Case] section)
<cjwatson> SpamapS: the UDD people can normally reset branches that have got into funny states such that the importer can work with them again; IIRC maxb specialises in this kind of thing
<xnox> slangasek: ok.
<SpamapS> cjwatson: right I want the other way. I want to reset the branch such that *I* can work with it. The importer is quite happy.
<yofel> cjwatson: for now I'll upload to quantal as I need 4.8.3 in there now. Later I'll coordinate with ScottK for debian.
<cjwatson> yofel: ok, sounds good
<SpamapS> cjwatson: it seems to me that there is a disconnect between whatever the importer does and what merge-upstream expects
<SpamapS> does the importer use import-dsc?
<xnox> ev: I have put two workitems on the https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-wubi-publishing
<xnox> not sure if anything else needs to happen on that one.
<cjwatson> SpamapS: the importer uses import-dsc
<cjwatson> or something built around the same libraries, anyway
<ev> xnox: why wouldn't we just upload to main?
<xnox> ev: because I do not want windows cross-compilers in main.
<cjwatson> SpamapS: but that doesn't automatically mean it works with merge-upstream, because import-dsc will synthesise file-ids from scratch whereas merge-upstream will make them match the upstream branch
<xnox> or any other random packages.
<slangasek> what's wrong with having a windows cross-compiler in main?
<ev> xnox: why?
<ev> indeed
<ev> plus archive reorg
<cjwatson> I can think of at least one delta against Debian we could drop by having a Windows cross-compiler in main
<slangasek> note that there are other cases where we're carrying a delta from Debian in order to keep mingw out of main... I think it's worth revisiting this
 * slangasek nods
<xnox> ok.
<cjwatson> SpamapS: if I were you, I would explore the following path: (a) do it all with merge-upstream (b) push over auto-imported branch (c) get the UDD people to reset things so that the importer starts from that point
<xnox> but we will still want PPA to have wubi daily builds =)
<xnox> if the build is good enough, we can upload it to main.
<cjwatson> SpamapS: there is not likely to be any sensible way to get things working with merge-upstream starting from an auto-import with different file-ids
<SpamapS> cjwatson: whats confusing is that I was using merge-upstream, then let just one auto import work, and the auto import is what broke things
<cjwatson> Yes
<SpamapS> cjwatson: so I guess the moral of the story is never let the importer do new upstreams
<cjwatson> Yes
<cjwatson> Not if you expect to use merge-upstream again, anyway
<cjwatson> We basically need https://wiki.ubuntu.com/DistributedDevelopment/Specification#Phase_5:_Current_upstream_in_Bazaar before that will work
<SpamapS> le sigh. Ok well I can at least move forward with something other than "pretend UDD is dead" now
<SpamapS> cjwatson: I would expect merge-usptream to handle the upstream code the same way import-dsc does though
<SpamapS> cjwatson: like, this even breaks w/ merge-upstream of a tarball
<cjwatson> Sure
<cjwatson> merge-upstream doesn't know the right file-ids if you merge from a tarball
<cjwatson> This all essentially flows from bzr having strong rename handling
<cjwatson> Even if two files have the same name, they aren't the same file as far as bzr is concerned (especially for merging) unless they have the same file-id
<SpamapS> makes sense.. I would have thought though that it would just take the entire corpus of the dir, and just do deletes/adds.. not try to do renames
<SpamapS> and by it, I mean merge-upstream and import-dsc
<cjwatson> Adds don't work unless it knows what file-ids to use
<cjwatson> What's probably happening is that it's added whatever new files are in the new release with different file-ids, so the next merge considers them to be contents conflicts - i.e. a file with different history but the same name
<SpamapS> so what I really want is for bzr to just take the upstream source, as-is, and not *ever* conflict it. I say "I want this tarball" and it should just take that tarball and insert it by name, not file id.
<cjwatson> No such thing in bzr
<cjwatson> Every file has a file-id, it's an intrinsic part of the model
<SpamapS> Sure, I see why it works that way, and I'm wanting a way around it. ;)
<cjwatson> If you have a bunch of conflicts and just want to take the other side of them, you can use 'bzr resolve --take-other' (or --take-this, as appropriate) to speed things up
<SpamapS> I'll at least try that..
<cjwatson> Best done in a throwaway branch for testing
<SpamapS> but these are rename conflicts where the whole source dir gets renamed to src.moved
<SpamapS> and then as you suggest, the new files are in src ..
<cjwatson> Which is probably because the directories were added with different file-ids
<cjwatson> You can see this sort of thing with 'bzr ls --show-ids'
<cjwatson> And/or 'bzr st --show-ids'
<SpamapS> I get why it works that way. What I don't get is why there's no "just start over with this tarball"
<cjwatson> Um
<cjwatson> Sure, you can start over, but that's not enough for you; you need it to correspond to the ancestry of the branch you're merging from
<cjwatson> That information isn't in a tarball
<SpamapS> I actually don't need that
<SpamapS> I mean, I don't think I do
<cjwatson> Youo do
<cjwatson> If you didn't, we wouldn't be having this conversation
<SpamapS> I don't merge in other branches.. I just want the upstream source.. always as-is.
<cjwatson> You're using merge-upstream, yes?
<SpamapS> yeah
<cjwatson> From a branch or a tarball?
<SpamapS> I've tried both.. it actually doesn't matter to me.
<SpamapS> I like using the branch, because it gives me the bzr### revnos automatically
<cjwatson> Then you do need the ancestry
<SpamapS> but thats like, 1 step I can do myself with bzr export
<cjwatson> In the branch case, you need the ancestry to match the branch you're going to be merging from in the future
<cjwatson> In the tarball case, the thing is that when you do a merge from something unversioned (.dsc, tarball), bzr has to just make up file-ids, and (AFAIK) it won't do that the same way every time because newly-generated file-ids include timestamps
<SpamapS> ok so really what it sounds like to me is, if you use merge-upstream, you can't let the importer do imports anymore
<cjwatson> So successive import-dsc and then merge-upstream from tarball won't match
<dupondje> could somebody look @ https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/937522 please? Would like to get it closed :) to many spam getting in it
<cjwatson> You can let it do them for non-new-upstream-release uploads
<slangasek> xnox: foundations-q-btrfs-requirements> could you please copy the pad contents rather than pointing to the pad from the whiteboard?  I don't think we should rely on the pad being persistent over the long term
<xnox> slangasek: ok.
<Laney> and the pad isn't completely public
<cjwatson> You can let it do them otherwise too, but you're going to have to overwrite it and get admin help to reset state
<cjwatson> The "some people use bzr, some people upload directly" model was only meant to be a transitional mechanism, not so much something people rely on forever
<maco> cjwatson: i have the impression a bunch of those uploading directly are waving their canes and telling those using bzr to get off their lawn
<AlanBell> the other reason to copy pad contents to blueprints is that work items won't be harvested from the pads
<maco> cjwatson: also that thing with quilt and evil
<slangasek> well, workitems are supposed to go in a separate section now
<SpamapS> cjwatson: indeed. I see the problem. I think the answer then, is to roll back to before the importer got involved.. and commit those locally.. push --overwrite.. reset state.. and then never let the importer do its thing again
<slangasek> maco: "that thing with quilt and evil" - you'll have to be more specific ;P
<slangasek> SpamapS: +1
<SpamapS> cjwatson: or rather, never let the importer do an upstream again. ;)
<maco> slangasek: ive complained about quilt+bzr=evil and .pc dir and such on the mailing list quite enough :P
<slangasek> SpamapS: not bothering to fix the importer after you push --overwrite would also seem to have this effect ;)
<SpamapS> heh.. true
<maco> slangasek: i know the dev guide has a very convoluted workaround for it available, i just think it's convoluted
<maco> (and of course depends whether the last person just ditched the .pc dir or what)
<maco> (which just adds more convoluted)
<slangasek> xnox: grub2 SRU uploaded
<xnox> slangasek: ok, I better update the bug then.
<bdmurray> pitti: at UDS you'd mentioned something about line numbers only appearing in tracebacks that end in Import errors.  Is that right?
<SpamapS> hrm, why are we suggesting pbuilder and not sbuild? http://developer.ubuntu.com/packaging/html/packaging-new-software.html
<Daviey> SpamapS: those that wrote the document favoured it i think.. that is how these things work :)
<Daviey> i'm sure dholbach would welcome patches :)
<SpamapS> Yeah this document is really confusing
<SpamapS> it never mentions 'bzr add' for instance
<SpamapS> I'm trying to see how we suggest people start out with UDD
<dholbach> SpamapS, Daviey: thanks for your interest in it (although it's not only me who'd welcome patches) - at our session at UDS barry said he'd look over the packaging guide bugs tagged with 'udd' and set the importance of them
<dholbach> I hope that on the udd and u-devel mailing lists we can get some folks interested in having a look over them
<xnox> I wonder if we should revisit https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-dpkg-xz given that debian uses xz by default for udebs now and the discussions are hot about switching xz by default in debian.
<dholbach> because I agree that some of the bits ARE confusing
<SpamapS> well like its not clear how to start out a packaging branch
<cjwatson> xnox: my feeling there is that we have the basic support in place and it's not a current priority for us, but if Debian does it then we'll follow naturally
<SpamapS> I think the steps involve tagging the first commit with an upstream-xxx tag..
<cjwatson> it helps that we don't need to worry about lucid upgrades any more
<asomething> SpamapS,  'bzr dh-make' handles a lot of the initial tagging/importing/adding of files, but it could be clearer.
<SpamapS> *OH*
<SpamapS> my eyes did not see 'bzr dh-make'
<alo21> hi all
<SpamapS> they saw 'dh-make'
<SpamapS> asomething: thats helpful. Did not see that!
<xnox> cjohnston: ok.
<alo21> How could I know if I had installed my personal pakage?
<xnox> cjwatson: ok.
<alo21> package*
<xnox> cjohnston: sorry, tab-completion fail.
<cjwatson> xnox: (I do think that getting the basic support in place for precise was important, of course)
<asomething> anyone around that can get merge proposals originally targeted against precise that are uploaded to quantal out of the sponsorship queue?
<asomething> https://code.launchpad.net/~kroq-gar78/ubuntu/precise/meep/fix-990137/+merge/103959
<asomething> https://code.launchpad.net/~kroq-gar78/ubuntu/precise/emesene/fix-984504/+merge/103967
<asomething> james_w, ^^
<SpamapS> Ok so I think I give up trying to get rid of all the package importer badness in lp:ubuntu/juju .. but what I have found I can do is just quickly create a new upstream package and import-dsc ...
<SpamapS> so merge-upstream is dead to me.. but import-dsc works reasonably well
<SpamapS> which makes me wonder if merge-upstream couldn't have the same sort of mode of operation as import-dsc if I ask it nicely
<james_w> asomething, I rejected them. If that was wrong let me know
<asomething> james_w, "merged" might have been better. either way they're out of the queue. Thanks!
<asomething> reject just sounds so harsh, but they aren't really merged...
<barry> dobey: ping
<dobey> barry: hi
<barry> dobey: hi.  i'm working on the merge from debian for twisted.  i think we might be able to drop both ubuntu specific patches, but wanted to check with you first.
<barry> dobey: afaic, 00_gi_gtk3reactor.patch is already fix released in 12.0 and 01_posix_wakeups.patch looks like it's already been applied upstream too
<barry> dobey: sure would be nice to just resync w/debian here
<barry> (they carry only tap2deb.py patch)
<dobey> barry: the reactor patch is definitely not in 12.0
<dobey> barry: it *is* in upstream trunk though
<barry> dobey: okay.  our patch does not apply cleanly to 12.0
<barry> dobey: i'll try to fix that though, if it's still the appropriate thing to do
<cousteau> http://packages.ubuntu.com only shows packages in quantal
<dobey> barry: hrmm, ok
<cousteau> actually the page looks mostly broken now
<barry> dobey: let me put something together and have you do a sanity check
<dobey> barry: that's odd.
<dobey> barry: ok, sure.
<cousteau> http://packages.ubuntu.com/search?suite=default&section=all&arch=any&searchon=names&keywords=linux  -  "You have searched for packages that names contain linux in all suites, all sections, and all architectures. Sorry, your search gave no results"
<cousteau> either ubuntu has stopped supporting linux, or there's a bug on the page
<cousteau> (I think it's the second)
<geser> cousteau: please talk to Rhonda in #ubuntu-motu about it, she takes care of packages.ubuntu.com
<cousteau> ok
<cousteau> er...  ok, kinda done
<barry> dobey: lp:~barry/ubuntu/quantal/twisted/20120515-sid-merge
<barry> dobey: builds fine locally
<dobey> barry: k, i'll look at the diff and ping you back
<barry> dobey: cool
<dobey> barry: looks reasonable. thanks!
<barry> dobey: awesome, thanks.  i'll upload it
<highvoltage> hmm, we seem to have the wrong blueprints associated on http://status.ubuntu.com/ubuntu-quantal/edubuntu-dev.html - where do we fix that?
<stgraber> highvoltage: that's actually right. That page lists all the blueprints related to members of edubuntu-dev and I'm in edubuntu-dev and the assignee of these blueprints
<highvoltage> ok
<highvoltage> It's a bit confusing though :)
<stgraber> highvoltage: I fixed the Edubuntu blueprint so that it's targeted for quantal, that should make it show up with the next run
<highvoltage> ok great
<alo21> hi all
<alo21> to fixing bug... should I use Quantal or not?
<dobey> alo21: to fix what bug?
<alo21> dobey: about amule
<highvoltage> alo21: I recommend you ask on #ubuntu-motu, that package is in universe. see also: https://wiki.ubuntu.com/Bugs/HowToFix
<alo21> dobey: I need this package libreadline5-dev, but it does not exist
<dobey> alo21: depends on the bug i guess.
<alo21> dobey: may be
<dobey> alo21: given libreadline6 is in precise, i doubt quantal has an *older* version of readline :)
<alo21> strange
<dobey> alo21: and it shouldn't depend on a specific so-version to compile against. sounds like an upstream problem to me
<micahg> dobey: alo21: the readline issue has to do with licensing and both 5 and 6 are available 5 is gplv2, 6 is gplv3 I think
<slangasek> there's meant to be a different virtual package to use if that's what you care about - libreadline-gplv2-dev vs. libreadline-dev
<micahg> right
<micahg> well,  neither is virtual, libreadline-gplv2-dev is the dev package,  libreadline-dev just depends on the latest gplv3 versioned package
<micahg> *is the dev package for libreadline5
<slangasek> right - s/virtual/logical/ maybe
<mterry> cjwatson, I see you made a whole bunch of python3 patches to update-manager.  Rock on!  :)  Is that finished then?  (I had a work item to do that work, but can assign to you or take it over)
<barry> mterry: i think he's not quite done, but definitely is rocking on it :)
<mterry> barry, cool
<mterry> cjwatson, well, I assigned task to you.  If you'd prefer to fob it off, let me know!  :)
<melodie> HI
<melodie> uh ? sorry
<melodie> hi
<dobey> barry: do you know a way to cleanly skip tests (ie, actually skip rather than raise an error), that works in python 2.6 as well as 2.7 and 3.x, with plain python unittest (./setup.py test)? :)
<jtaylor> I don't think that works with 2.6
<jtaylor> without unittest2 backport
<roaksoax> /win/win 13
<jtaylor> or some monkeypatching
<roaksoax> bah
<barry> dobey: jtaylor's right.  @unittest.skip() is new in 2.7
<jtaylor> yes
<dobey> jtaylor: well even in 2.7 it doesn't seem to do a clean skip, it just raises an exception named SkipTest :(
<jtaylor> hm nose may have skips
<jtaylor> but no known failurs I think
<barry> dobey: i suppose whatever runner you're using has to know about them
<dobey> barry: i'm using test_suite='foo' in setuptools setup()
<dobey> barry: so ./setup.py test
<barry> dobey: hmm, that should work afaik
<barry> (in 2.7 & 3.2)
<dobey> it behaves the same as if any other exception were raised :(
<dobey> at least, in 2.7 on precise
<dobey> can't run under 3.x yet
<dobey> maybe i should just leave this code running tests with trial
<dobey> though i guess i will need to make these test suites that don't use trial, still use subunit, to get parseable output for jenkins or something. :-/
<dobey> oh well, will figure it out later i guess
<jtaylor> just use nose with xunit
<jtaylor> ipython uses that for their shining panda instance
<jtaylor> dobey: ^
<infinity> cjwatson: I'm not willing to commit to claiming I know what the exact problem is, but it certainly seems related.
<SpamapS> jdstrand: Hey, can you take a look at the comment I just added to bug #986892 and tell me if I'm on the right track there?
<ubottu> Launchpad bug 986892 in apparmor (Ubuntu) "mysql-server postrm breaks apparmor profile for later versions on purge" [Undecided,Triaged] https://launchpad.net/bugs/986892
#ubuntu-devel 2012-05-16
<malkauns_> why do flash video's on 12.04 sometimes play fast?
<wgrant> stgraber: Well done.[6~
<stgraber> thanks wgrant :)
<wgrant> Aw
<highvoltage> http://jonathancarter.org/2012/05/16/launchpad-net-bug-1-000-000/ ;)
<wgrant> sinzui closed it.
<ajmitch> how mean
<highvoltage> yes!
<highvoltage> (unless he fixed it)
<ajmitch> but good timing at getting that bug, stgraber ;)
<TheMuso> Awesome work, that woudl have had to be very tight timing to get that number.
<lifeless> they used a conspiracy
<lifeless> myself, I'd have used an API script.
<highvoltage> lifeless: yeah that would be clever. why didn't we think of that!? ;)
<stgraber> ;)
<micahg> ScottK: any reason why a boost-mpi-source upload never happened with the boost1.49 upload?
<micahg> ScottK: ah, I see, it's all in boost-defaults now...meh, this needs more digging
<micahg> ScottK: no, I think my question is still valid :)
<ScottK> micahg: Because I couldn't get it to build at the time and then I forgot about it.
<micahg> ScottK: ok, I was just looking at the boost transition list, libboost-all-dev is uninstallable due to a missing boost parallel package
<superm1> siretart: curious, what's the fix you ended up coming up with for the FTBFS you talked about in http://goo.gl/KDK9o ?  mythtv is hitting the same thing in precise after it's most recent ffmpeg resync: http://goo.gl/v7dc6
<kInOzAwA> lol ScottK  from webchat?
<siretart> superm1: well, that irclog explains it at about 20:00
<siretart> superm1: btw, is there someone investing some efford to avoid the internal ffmpeg copy in the mythtv package?
<ScottK> micahg: I'll try to pick up work on it, but it'll be a few days.
<micahg> ScottK: sure, no rush :), plenty to do
<pitti> Good morning
<pitti> bdmurray: more precisely, line numbers will appear in frames which would otherwise just be <module>, i. e. not in any function or method
<pitti> bdmurray: this mostly happens for ImportErrors, but can also happen in global initialization code
<pitti> slangasek: I heard some rumours that we'll switch from ConsoleKit to logind; wouldn't that solve foundations-q-xdg-runtime-dir along?
<TheMuso> I heard same rumours.
<xnox> stgraber: congrats on bug 1kk!
<ubottu> Launchpad bug 1 in Ubuntu "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<xnox> bug 1000000
<ubottu> Launchpad bug 1000000 in Edubuntu "For every bug on Launchpad, 67 iPads are sold" [Wishlist,Triaged] https://launchpad.net/bugs/1000000
<pitti> ogasawara, apw: FYI, binNEWed -2.5
<apw> pitti, thanks
<pitti> apw: remember the other day when we talked about the kernel team uploading copying kernels themselves?
<pitti> err, s/uploading copying/copyring proposed/
<pitti> typing is hard! I should replace my ubuflu with a tea perhaps
<pitti> apw: there is an opportunity to try now, if you want to
<apw> pitti, didn't we decide you would have to handle the component missmatches anyhow?  though of course i will try it to check it works :)
<pitti> apw: yes, archive admins still need to accept the uploads from unapproved and also fix the overrides
<pitti> but it's one step
 * apw will have a look now
<pitti> it doesn't help much still, but I'm mostly curious whether you need ~u-archive power to run that script or upload privs for that package
<pitti> apw: i. e. I mostly want to figure out this ^, it won't help much to reduce teh SRU workload
<pitti> phone, bbl
<pitti> apw: so, if you could do bzr checkout lp:ubuntu-archive-tools ?
<apw> pitti, np doing now
<apw> pitti, ok have that
<pitti> apw: can you please run copy-proposed-kernel.py natty linux-ti-omap4
<apw> pitti, i read the output as positive in general
<apw> pitti, chinstrap:~apw/typescript for the transcript
<apw> pitti, appears to be at the unapproved queue indicated in the output
<pitti> ah, so that worked? nice
<apw> pitti, i think so from what i can see, indeed
<pitti> apw: yes, archive admins still need to accept the uploads from unapproved and also fix the overrides
<pitti> WTF?
<pitti> that's not at all what I typed
<pitti> apw: there it is: https://launchpad.net/ubuntu/natty/+queue?queue_state=1
<pitti> ah, clicking middle button to paste the URL somehow seems to have triggered some cursor up event or so
<apw> nice :/
<apw> pitti, so does it make sense to get our people to do this phase of the push
<dupondje> could somebody look @ https://bugs.launchpad.net/ubuntu/+source/remmina/+bug/937522 please? Would like to get it closed :)
<ubottu> Launchpad bug 937522 in remmina (Ubuntu) "rdp clipboard sync doesn't work anymore." [Undecided,Confirmed]
<pitti> apw: can you also try the -updates/-security moving?
<pitti> apw: sru-release -s natty linux-ti-omap4
<apw> pitti, now ?
<pitti> apw: as I said, I was mostly curious about permissions here; if you want, you or even the bot are welcome to run that
<pitti> apw: er, sorry
<pitti> apw: sru-release -s oneiric linux-ti-omap4
<pitti> bug 985999 is ready for releasing
<ubottu> Launchpad bug 985999 in linux-ti-omap4 (Ubuntu) "linux-ti-omap4: 3.0.0-1209.21 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/985999
<pitti> apw: it would just fail with natty, as there is no -proposed ti-omap anyway
<apw> pitti, looks to have worked: https://launchpad.net/ubuntu/oneiric/+queue?queue_state=1
<pitti> great
<pitti> so the copying actually uses upload privs, not ~ubuntu-archive; that's only required for actually accepting the copies
<pitti> apw: thanks for trying
<apw> pitti, no problem.  i quite like at least us copying into -proposed as that indicated someone with upload privs asked for it
<pitti> apw: so in theory you could do bug 990103 as well
<ubottu> Launchpad bug 990103 in Kernel SRU Workflow "linux: 2.6.32-41.89 -proposed tracker" [Undecided,In progress] https://launchpad.net/bugs/990103
<pitti> apw: actually, that one is more interesting; perhaps that's something the bot could do for us
<pitti> apw: it takes some time for me to figure out the set of packages (including lbm, the various metas for the different releases, etc.) and whether or not to copy to security as well
<pitti> and determining the set of packages seems automatable
<pitti> (if that is an actual word, anyway)
<apw> pitti, yeah for sure the bot knows which are in the package set for that release, as it asks us to make lbm etc when appropriate
<pitti> apw: so in this case it's just "linux", but with API breaks it's more
<apw> pitti, so you'd like it to simply copy them when its ready and let the approved queue be your 'queue'
<pitti> ports-meta for lucid, linux-ubuntu-modules for hardy, etc.
<pitti> apw: yes, that'd be nice
<pitti> apw: the copying is fast, and by itself does not change anything
<pitti> they can easily be rejected, re-done, etc.
<apw> pitti, i can get brad to think about that no problem.  that sounds appropriate then i think
<pitti> apw: in some time we'll have a launchpadlib API to do queue accepting, and will hopefully have bug 993120 fixed
<ubottu> Launchpad bug 993120 in Launchpad itself "Copy from PPA with binaries evades NEW and puts new packages into universe" [High,Triaged] https://launchpad.net/bugs/993120
<pitti> then the bot could do the whole process for copying into -proposed and fixing the overrides
<pitti> -> less monkey button pressing from our side, and faster turnaround
<pitti> -> more time for beer!
<apw> pitti, yeah, and presumably more AAs would be comfortable doing kernels as it would be easier
<pitti> yes, cocoplum access is a severe limitation
<apw> pitti, ok will get brad to think about the right way to get that doing the right thing.  it should at least generate the commands and put them in the bug :)
<pitti> apw: it could just use them; the gut of copy-proposed-kernel is essentially one copyPackage() launchpadlib call
<pitti> apw: the rest is setup which the bot presumably already has anyway
<pitti> ubuntu.getArchive(name='primary').copyPackage(from_archive=kernel_ppa,
<pitti>         include_binaries=True, source_name=pkg, to_series=release,
<pitti>         to_pocket='proposed', version=version)
<apw> pitti, yeah i am sure it could do it assuming its joined to LP with creds of someone with upload rights, but we may want to make it happen with deliberate action from an uploader so we have accountability
<pitti> apw: wouldn't you still have accountability from the person who flipped the "copy to proposed" task to confirmed? that's in the activity log
 * apw wonders who will get named on the email when the copy completes now
<pitti> and even if that gets done accidentally, we can just reject the queue copies
<pitti> the accepts for -updates/-security should always be manual I think
<pitti> but -proposed cries for automating
<apw> pitti, yeah we'd know who for sure, but likely anyone in the world can flick that so we might not want it to happen without thought, but thats a separate issue
<pitti> ah, true that
<apw> pitti, yeah for sure ... anything we can do to make it easier.  i would cirtainy agree that whatever happens it should be telling the poor sucker who does it exactly what characters to type so you don't have to work out the package sets etc.  thats just makework
<pitti> apw: right, http://people.canonical.com/~ubuntu-archive/pending-sru.html (at the bottom) gives us copy-paste commands for -proposed
<apw> pitti, and the logical first step is that, getting it to dump the two commands you showed me stylee with the appropriate packages into the bug and getting the stable people to run them
<pitti> but not for -updates/-security, it's not clever enough for that; but the kernel bug bot is
<pitti> apw: I agree
<apw> yeah, and we definatly can do that, and most likely can make one of those pages with all the pending ones in one place too
<apw> brad loves scripting web pages :)
<pitti> dear LP; please stop timing out when I try to set that task to "fix released" the tenth time
<apw> pitti, the most annoying feature
<pitti> apw: oh, look! -changes@ now has your name for the kernels, not mine
<pitti> so far it seemed that I was responsible for doing all these uploads :)
<pitti> apw: presumably I can remove the linux-backports-modules-3.2.0 source and binaries?
<pitti> apw: (from quantal)
<xnox> is there a consensus on replacing Vcs-* fields with XS-Debian-Vcs-* ?
<apw> pitti, yes lbm makes no sense for the old version
<cjwatson> apw,pitti: you could even check whether it's an uploader who set things to Confirmed and then use archive.copyPackage(sponsored=that_uploader)
<cjwatson> which is a reasonable on-behalf-of kind of interface
<apw> yeah that makes sense
<cjwatson> (or whatever way you want to trigger that)
<pitti> cjwatson: for sorting out http://people.canonical.com/~ubuntu-archive/component-mismatches.svg and generally reducing the packages in main I'd need to make some adjustments to the DVD seed
<pitti> cjwatson: but I wondered, given that we'll drop the DVD/USB image anyway and just have one image, should I perhaps remove it altogether?
<seb128> what is setting the /tmp permissions? bug #999526 is an user who has tmp permissions which are wrongly set (and they keep being wrongly set at every reboot), not sure where to direct him
<ubottu> Launchpad bug 999526 in lightdm (Ubuntu) "Cannot login from lightdm, /tmp is not writable" [Low,New] https://launchpad.net/bugs/999526
<pitti> cjwatson: AFAIK we are only using the "usb" seed now, and "dvd" is dead already
<cjwatson> pitti: I think so, but just hard-dropping it would probably cause stuff to fall out of main that shouldn't
<cjwatson> (at a guess; haven't looked much)
<pitti> cjwatson: we'll see in c-m and could then re-seed some bits that seem important
<pitti> I don't think it makes much sense to file some 20 MIRs for texlive packages which we don't really actively maintain anyway
<pitti> cjwatson: http://paste.ubuntu.com/990399/ -> DVD removal (keeping the "usb" one for now)
<cjwatson> The texlive-* stuff isn't in build-dep chains anyway?
<pitti> some binaries are
<pitti> but e. g. not texlive-fonts-extra
<pitti> texlive-lang-{german,cyrillic} have one reverse build dep each
<cjwatson> looks fine as far as it goes, but I think it would be worth an A/B germinate run first
<pitti> and texlive-extra has a few
<pitti> cjwatson: okay, I'll do that
<mdeslaur> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<hrw> hmm. I do not like dpkg-cross more and more
<jdstrand> SpamapS: I'll take a look
<HFSPLUS> Katy perry baby, i know your hurting right now after that prick russel brand broke your heart, now all i ask is to give me a chance to prove that i love you. Honey i am nothing like russel brand, and i love you and i will never break your heart katy
<HFSPLUS> !ops
<HFSPLUS> Katy perry baby, i know your hurting right now after that prick russel brand broke your heart, now all i ask is to give me a chance to prove that i love you. Honey i am nothing like russel brand, and i love you and i will never break your heart katy
<melodie> hi,
<melodie> I have seen at this page : http://www.ubuntu.com/community/report-problem that it is not so obvious for me to find where I should put a wish. I use "mozilla-sunbird" currently and I would like to ask for it to be packaged and made available in Ubuntu. https://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/releases/1.0b1/ this version, and the locales for it too. It is not available at Debian either for now, only the plugin for opensync is t
<melodie> here :
<melodie> http://packages.debian.org/sid/opensync-plugin-sunbird
<melodie> my question is where should I go to bring it as a wish ?
<geser> melodie: https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages, 2nd paragraph of "Requesting a new package for Ubuntu"
<cjwatson> you can file wishlist bugs on just Ubuntu (without a package) with the needs-packaging tag to ask for new packages; however, note that sunbird used to be in Ubuntu and was removed
<cjwatson> bug 571134
<ubottu> Launchpad bug 571134 in stumbleupon (Ubuntu) "Please remove source and binaries from archive" [Undecided,Fix released] https://launchpad.net/bugs/571134
<cjwatson> and https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel
<melodie> geser, cjwatson I look at your links
<cjwatson> so making it actually work with new thunderbird versions would be a fairly important piece, and ensuring that it has good maintenance going forward - Mozilla extensions aren't something that can be just dropped into the archive and largely forgotten about, AIUI
<cjwatson> (note I don't actually know anything about sunbird directly)
<pitti> cjwatson: got back to this now; so I have germinate output for "with-dvd" and "without-dvd", but diffing the dirs is rather useless as I get tons of random diffs like http://paste.ubuntu.com/990622/
<melodie> cjwatson, I don't use thunderbird. I use sunbird as standalone application. I cannot switch to Ubuntu without my usual tools. :/
<pitti> cjwatson: do you have a tool to better compare those, or should I post-process the files to only show the package names?
<melodie> I have had my appointments and todo notes in it for years
<elky> melodie, as i understand it, sunbird can be run standalone as a portable app
<elky> http://portableapps.com/apps/office/sunbird_portable
<melodie> elky, a portable app ? and why not have the standalone version in the distribution ? In another distribution I use it works fine
<cjwatson> melodie: I don't know anything more about this, so no good explaining to me why you need it :)
<cjwatson> pitti: I usually run it through cut -d' ' -f1 or similar
<melodie> cjwatson, ok thank you
<pitti> cjwatson: ok
<cjwatson> pitti: actually, tail -n +3 | head -n -2 | cut -d' ' -f1
<cjwatson> one of these days I should do a more machine-readable output mode
<melodie> elky, portable sunbird is for windows. I don't use windows. brrr !
<melodie> :)
<elky> melodie, i believe they work fine on wine. they did the last time I played with them
<elky> where they = portable apps
<pitti> cjwatson: http://people.canonical.com/~pitti/tmp/diff/ are the nonempty diffs between the germinate outputs with (-) and without (+) the dvd seeds
<pitti> cjwatson: I guess all.sources.diff is the interesting one?
<melodie> elky, I might have found a better turn around. at debian-mentors someone just told me in Debian (sid and other versions) there is "iceowl" which does that. http://packages.debian.org/sid/iceowl so I will go to package request as for it...
<melodie> elky, wine is something I prefer not to use. I have tried a few times and it was disapointing with "one time it works, the other it claims a dll is missing.. " and such.
<elky> melodie, well when you make the wishlist bug like cjwatson suggested, you can mention that :)
<elky> mention iceowl, I mean.
<cjwatson> pitti: yep, or http://people.canonical.com/~pitti/tmp/diff/all+extra.diff if you want a list by binaries
<cjwatson> elky,melodie: iceowl is explicitly sync-blacklisted in Ubuntu - we prefer the Mozilla names
<melodie> elky, I'll have to try it to see if I can use it with my db
<pitti> cjwatson: so we'll certainly want to seed the nvidia/fglrx drivers and a few -doc packages, but can happily drop some of the libs
<cjwatson> pitti: IIRC bittornado is used in the DC to operate torrent.ubuntu.com
<melodie> cjwatson, then what wish could I post ?
<pitti> and keep diveintopython and virt-manager/virtinst, too
<pitti> and xchat-gnome
<pitti> cjwatson: so I'll add those to the "supported" seeds in exchange
<elky> cjwatson, i wasn't suggesting it be syncd, rather as a datapoint
<pitti> cjwatson: or supported-desktop-extra for xchat-gnome and similar desktopish packages
<cjwatson> pitti: right, I'd just come to similar conclusions on the list to keep
<elky> but it's past pumpkin o clock so I'm going to head off. good luck melodie
<cjwatson> melodie: the wishlist should be for sunbird (though I'd be surprised if there isn't one filed already; I'm not sure), not for a straight copy of iceowl
<pitti> cjwatson: I'd add stuff like autoconf-doc to the platform seed "supported-development-common" instead to desktop; sounds ok?
<pitti> it already has autoconf, autotools-dev and the like
<cjwatson> pitti: yep
<cjwatson> it's only needed that way when the documentation is in a separate source package
<melodie> cjwatson, I am looking at the pages you pointed me to, then I will seek the page for wish lists at Ubuntu and ask for a standalone sunbird package. I still have to find where they put the locales
<geser> would it be possible/allowed that the nvidia source package also build library packages like the Debian package?
<pitti> cjwatson: all, committed; thanks for your help!
<pitti> s/,//
<geser> pitti, cjwatson: do you know if it's allowed that a source package from restricted builds lib-packages in multiverse/restricted (not sure which component would be the correct one for them)?
<pitti> geser: I dont see why not
<geser> I wasn't sure if there are any restrictions for source packages in restricted what they can build
<cjwatson> geser: yes, that's permitted; the rule is basically that source packages must be at least as far out as their binaries
<cjwatson> where  main < restricted < multiverse  and  main < universe < multiverse
<cjwatson> well, though a source package in main building binaries in restricted/multiverse would be kind of odd, although I think we might have had a reason for that once ...
<cjwatson> some kind of dependency closure problem I guess
<geser> tseliot: Hi, would it be possible to build the same set of library packages from nvidia-graphics-drivers like in Debian? There are some package in multiverse depwaiting on them, so we either build those library packages too or remove those source packages as it's impossible to build them in Ubuntu
<tseliot> geser: what library packages?
<geser> tseliot: libcuda1, libopencl1 (provided by nvidia-libopencl1 in Debian).
<cjwatson> There's also a new nvidia-support source package showing up for auto-sync, which I've been holding off on ...
<geser> nvidia-cuda-toolkit depwaits on libcuda1 and viennacl depwaits on libopencl1, not sure if there are more needed, didn't check in detail yet
<tseliot> geser: I think there were a few problems with the packaging of nvidia-cuda-toolkit anyway. I'll have another look at it though
<tseliot> cjwatson: I'm wondering what nvidia-support is and whether we really need it
<cjwatson> Dunno, I haven't looked.  The autosyncer just shows me everything, I try not to care too deeply about it all :)
<cjwatson> But it's often better to sync up to avoid later dependency trouble
<cjwatson> (in general)
<HFSPLUS> Katy perry baby, i know your hurting right now after that prick russel brand broke your heart, now all i ask is to give me a chance to prove that i love you. Honey i am nothing like russel brand, and i love you and i will never break your heart katy
<pitti> !ops
<xnox> cjwatson: are you triggering sync from debian manually, or are they done continiously?
<ubottu> Help! Channel emergency! mneptok, Hobbsee, cjwatson, mdz, lamont, Keybuk, or thom!
<pitti> well, emergency is a bit much
<pitti> thanks cjwatson
<mlankhorst> thank you
<pitti> but this guy keeps saying that
<pitti> argh, now he's privmsging
<mlankhorst> get a network admin and get him glined from freenode..
<cjwatson> probably a case for freenode staff, yeah
<mlankhorst> for harassment
<pitti> nice, http://people.canonical.com/~ubuntu-archive/component-mismatches.svg looks a little less crazy now
<cjwatson> xnox: I plan to get at least some of it fully automated this cycle by way of a bot account; for now it's a script I run daily
<xnox> cjwatson: ok. thanks.
<tseliot> cjwatson: I'll have a look at that package too then, just in case..
<cjwatson> last cycle we got it from a script that ran daily and routinely broke part-way through and had to be re-run from the start, to a script that runs straight through and has rather more sensible feedback
<cjwatson> so still improvement :)
<melodie> cjwatson, I will have to give up, mozilla has announced it as being the last release : https://www.mozilla.org/projects/calendar/sunbird . I feel so sorry, such a good program ! :-(
<cjwatson> melodie: well, at least xul-ext-lightning is in the archive (although I know you said you don't use thunderbird)
<cjwatson> but perhaps better than nothing
<melodie> /o\
<xnox> melodie: i use xul-ext-lightning.... seems ok.
<melodie> xnox, with thunderbird : right ?
<melodie> it's not standalone ?
<xnox> yes.
<xnox> but you do not need any email accounts in thunderbird, if you just want calendars.
<melodie> I think it is very sad. I love standalone apps particularly when it leaves choice and freedom to use any other component.
<melodie> xnox, no you just need  the megabytes just for calendar, which sunbird does so well.
<melodie> I find it incredible that no one has been interested to continue it
<cjwatson> broder,Laney: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/revision/430
<mneptok> melodie: https://en.wikipedia.org/wiki/Mozilla_sunbird
<mneptok> melodie: especially this pertinent bit: "Development of Sunbird was ended with release 1.0 beta 1 to focus on development of Mozilla Lightning."
<mneptok> melodie: IOW, Sunbird is abandonware. at least by Mozilla.
<melodie> it is still free software
<melodie> and a good one
<melodie> mneptok, do you know a program having for name "animal" ?
<tseliot> cjwatson: as I thought, we don't need nvidia-support, however there's a file I can definitely reuse for a work item I was assigned. Thanks!
<mneptok> melodie: no. and really, that's a bit outside the scope of development of Ubuntu. probably better asked in another channel.
<melodie> mneptok, I don't talk of "animal" by hazard : it is a very very old console game, which is in Ubuntu. In fact I think Ubuntu might be the only place where I can still find it.
<melodie> really fun !
<melodie> I am filling a bug to ask a package for the last sunbird available. :)
<mneptok> melodie: this channel is for development issues only. please stay on topic so that busy devs can maximize mental bandwidth.
<melodie> mneptok, ok, thanks for your answers.
 * mneptok bows
<herton> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton, mdeslaur
<slangasek> pitti: well, foundations-q-xdg-runtime-dir was to discuss if we had requirements that differ from those in the Fedora implementation; and switching to logind is certainly just a rumor, jodh will be investigating whether logind is a suitable solution as-is or how many changes it needs to integrate with upstart
<pitti> slangasek: ah, thanks
<Sweetshark> Who takes care about the mysql C++ connectors? Will we have a 1.0.6 or higher api of that in quantal (for whatever that means?)
<micahg> Sweetshark: we already have 1.1.0
<micahg> (and have since oneiric)
<Sweetshark> micahg: interesting, my configure script says different (on precise still)
<micahg> Sweetshark: and since you have the only reverse dependency, that's you who cares about it I guess :)
<melodie> bye
<micahg> looks properly reflected in the soname as well
<pitti> micahg: you TIL gimp; do you plan to merge it, or want to leave that to desktop team?
<SpamapS> jdstrand: also I think apparmor FTBFS on quantal right now
<jdstrand> yeah, need to look into that
<arges> congratulations! https://bugs.launchpad.net/launchpad/+bug/100000 : )
<ubottu> Launchpad bug 100000 in Launchpad itself "There are still too many bug reports" [Undecided,Invalid]
<mvo> cjwatson: are you ok with me uploading https://code.launchpad.net/~glatzor/software-properties/python3/+merge/105755 ? its a 2to3 based approach to port software-properties but it would unblock a aptdaemon py3 build
<micahg> pitti: orly?  yeah, I can do it, was waiting for gegl which I thought was in NEW
<micahg> pitti: unless the desktop team wants to do it or it needs to be done before the weekend that is
<cjwatson> mvo: For now, yes, though I'd rather revert that and avoid relying on 2to3 long-term
<cjwatson> (once we're unblocked)
<mvo> cjwatson: agreed
<seb128> cjwatson, hey, with the one image discussion is there any plan to drop alternates,udeb over time?
<cjwatson> seb128: alternates yes, udebs not currently; netboot installation is still valuable to many of our users
<seb128> cjwatson, ok, does netboot use gtk (I get I will not get away with that but looking if,how I could drop multibuilds from gtk)
<cjwatson> seb128: we do currently build a netboot GTK image, though there is also a text one
<cjwatson> seb128: most of that's synced from Debian on the GTK side AFAIK though
<seb128> cjwatson, I'm trying to get gtk build time down, the multiple build is costing a lot on buildd time and local build time for those who want to work on gtk
<cjwatson> Does it actually require multiple passes?  Different configure flags / dependencies / something?
<seb128> cjwatson, different configure flags yes
<cjwatson> Perhaps it might be more economic to figure out how to do it in a single pass
<seb128> cjwatson, in fact the udeb build is mostly disabling x11 options, I wonder if that's still needed
<seb128> 			--disable-xcomposite \
<seb128> 			--disable-xdamage \
<seb128> 			--disable-xfixes \
<seb128> 			--disable-xrandr
<cjwatson> It might just be a matter of building udebs for xcomposite/xdamage/xfixes/xrandr
<seb128> ok, thanks
<cjwatson> Which ought to be fairly trivial given current X packaging
<seb128> I will try to check with mbiebl what he thinks
<cjwatson> Not sure whether introspection would require anything extra
<seb128> that's the other one yes, though those don't impact the lib so I'm not sure the flag is needed
<seb128> like those are extra files but we could just not install them in the udeb
<cjwatson> Yeah, I wondered about that
<seb128> cjwatson, thanks, I will check on the Debian side if we could get udeb for the x libs and merge shared and udeb in one build for gtk
<cjwatson> libxfixes already has a udeb; the others don't
<mdeslaur> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: herton
<seb128> is anyone here having an opinion on static builds? Debian dropped the GTK static build recently (which is great, I was just thinking about going forward and do that for Ubuntu) and I was wondering if that's the sort of change that should be discussed on -devel or announced
<seb128> or if we can consider it's fine and we will get bug reports anyway if some users still rely on it
<infinity> seb128: In theory, static builds are a convenience to our users who want to link their own binaries statically for some reason or other.  In practice, most people who do static linking of complex stacks seem to build their own in-house anyway, so they have tighter control over versions.
<infinity> seb128: Still, seems odd that Debian's dropped it...
<seb128> infinity, ok, in practice also the cost in build time,dev time - benefit is not good also
<seb128> infinity, why?
<infinity> seb128: Well, cause we've traditionally provided static copies of most libraries, that's all.  Is there sometihng that makes GTK special in this regard?
<seb128> infinity, the new generation of maintainers are less conservative about keeping stuff that almost nobody use and that cost us work it seems, which is good ;-)
<seb128> infinity, out of the gtk maintainers who have enough to spend time waiting for gtk to build and fixing the static build because upstream doesn't care about it, not really
<seb128> infinity, it just seems it costs over what it brings back
<infinity> seb128: I have no real opinion either way.  As you say, you'll get bug reports if users care.
<infinity> seb128: But, if it turns out they do, I'd push to turn it back in in Debian, rather than carrying the burden entirely in Ubuntu.
<seb128> infinity, right
<seb128> well I take that as a "let's try it in q"
<infinity> seb128: *nod*
<seb128> I guess Debian will hit unhappy users before us in any case if that happens
<infinity> seb128: "Upstream doesn't care about the static build" sounds like a pretty valid argument.
<seb128> I'm not even sure you can correctly use static built gtk nowadays with the dynamic image loaders and im methods
<seb128> infinity, thanks, you convinced me it was ok to drop it ;-)
<infinity> seb128: Hey, don't pin this on me. ;)
<seb128> infinity, too late for that ;-)
<seb128> the changelog already has your name
<infinity> ...
<seb128> ;-)
<infinity> I knew there was a reason I didn't trust the French.
<lamont> infinity: isn't canadian like french?
<infinity> lamont: Only when I'm eating poutine.
<lamont> heh
<Sweetshark> lamont, infinity: were do you guys live by the way? I need a rather exact location ....
 * infinity raises his eyebrow.
<Sweetshark> I have this work item to get more fs-space on the libreoffice-ppa build, and having an exact location makes threading you with ICBM-strikes more believable!
<infinity> Sweetshark: For the build itself, or the PPA?
<Sweetshark> the filesystem on which we are building
<infinity> Sweetshark: If the build is eating the disk on the virtual builders, there's not a lot we can do about that, short of upgrading all the virtual builders physically.
<infinity> Sweet mother of... 28G to build libreoffice?
<infinity> That's insane.
<Sweetshark> infinity: right -- I know its quite a bit of work, but thats what we need. Who do I escalate that too?
<Sweetshark> infinity: well, we could get rid of l10n or the stacktraces or running the tests to make it a bit smaller.
<infinity> Sweetshark: RT ticket.  It means upgrading all the enablement/ppa shared hadrware, which could be a bit of an uphill battle.  If the only people uploading to that PPA are Canonical employees (and if you don't upload frequently), the path of least resistance might be making it devirt, so it builds on the distro buildds.
<Sweetshark> infinity: our you get me the ressources to make libreoffice understand gettext directly ...
<cjwatson> Devirt does mean there's contention between you and release-team and the like around release times, though.
<infinity> ^
<cjwatson> Or even if there's a lot of other distro upload activity.
<cjwatson> Is 28G really particularly difficult in terms of FS space?  I'd have thought it'd be more a matter of raising a threshold somewhere.
<Sweetshark> infinity: that was another option I was considering: building in proposed and copying over to the ppa -- that doesnt work on backports though.
<infinity> If he goes devirt, but x86-only, it probably ends up better as far as resource contention.
<infinity> cjwatson: Most of the PPA buildds have 72G disks, laid out in a pretty specific way.  AFAIR, it's a question of physical upgrades to make this problem go away.
<cjwatson> Grumble.  My phone has very nearly that much free.
<infinity> (Plus, that 28G is sbuild's estimate, which can be low, if it peaks earlier and then deletes things)
<infinity> Sweetshark: Building in proposed and copying to a PPA?  That sounds rather backward. :P
<Sweetshark> infinity: well ...
<infinity> Sweetshark: But if these PPA uploads are actually meant to land in a release (ie: they're not just "test builds"), then I'd be sold on the devirt option.  All arches on, ddebs on, and have AAs copy things around.
<infinity> (Not saying IS shouldn't solve the PPA disk space issues some day too, but if you're the only user this really impacts, I'm guessing it'll be pretty low on their priority list, and we should look for clever interim solutions)
<Sweetshark> infinity: by now the ppa should have only rather stable stuff. If im doing real "test builds" I do them on personal ppa *cough* now ...
<infinity> Sweetshark: So, the PPA in question is staging for distro uploads?  Much like the kernel-sru PPA?
<Sweetshark> infinity: yes, pretty much.
<infinity> Sweetshark: Okay.  And who has upload rights to it?
<Sweetshark> infinity: ricotz, doko, me and penalvch. penalvch will never upload there.
<hyperair> oh hey we have 7-digit bug numbers now
<xnox> infinity: Sweetshark: didn't like desktop track wanted to run daily libreoffice builds & run the full test-suite, just for the sake or running the full testsuite?
 * xnox is pretty sure he heard that during roundup @ UDS.
<xnox> if it actually is daily libreoffice builds hitting the ppa, across all stable releases (like chromium ppa's) then potentially it will be a bigger FS resource problem.
<infinity> xnox: Ick.
<infinity> xnox: I recall something about libreoffice CI, I'm hoping it's not an all stable releases, nor daily.
 * infinity doesn't like his odds of backporting x32 support in glibc, when he realises that H.J. Lu is still committing to master, as recently as 5 minutes ago...
<infinity> Guess I can backburner that work item until a liiiiitle bit later in the cycle.
<infinity> cjwatson: ^-- FYI
<Sweetshark> jasoncwarner_: just a headsup, thursday is a bank holiday in germany, so if there is something to 1:1 about drop me a line
 * micahg doesn't like the idea of an all arch devirt PPA for libreoffice, most of these builds probably won't be pushed into a release anyways (latest stable libreoffice for older stable Ubuntu releases)
<rbasak> Do we know if either d-i or mkfs runs an ssd trim at partition format time? I'll file a wishlist bug unless someone tells me it does.
<rbasak> NCommander: ^^
<infinity> micahg: Yeah, the backport ones should probably be in a virtualised PPA, I agree.  Solving that problem for them is a bit more effort, though.
<pitti> micahg: gegl should be current now, I binNEWed pretty much everything today
<micahg> pitti: thanks, will take a look over the weekend, still catching up on a bit of a backlog
<micahg> pitti: can you promote the new gegl binaries to main (library and dev package, libgegl-0.2-0, libgegl-dev)?
 * micahg guesses libgegl-doc should be in main as well
<cjwatson> infinity: heh, makes sense, it was hardly the most urgent on your list anyway
<cjwatson> rbasak: d-i doesn't, but I would be inclined to say that that shouldn't be d-i's problem.  mkfs or kernel.
<rbasak> ok, thanks. does d-i call mkfs or mkfs.$type? It would be nice to have it in mkfs rather than each backend
<cjwatson> IIRC mkfs.$type, and in some cases parted (but that needs to go away anyway)
<rbasak> so if I file a bug against each mkfs.$type, I'll get told that it should be in mkfs, right? :)
<bryceh> bdmurray, looking at bugs filed against python-support...  it looks like that package recompiles all installed .py scripts to .pyc as part of its installation.  So if you happen to have a buggy python script installed, it causes a package failure bug to be filed against python-support
<bryceh> bdmurray, I think those bugs should be filed against their respective packages instead
<bryceh> and possibly python-support itself should not fail in such a case, but just flag the error.
<rbasak> next question: what tells debootstrap that it should ?configure base-passwd before base-files? I've got it going the wrong way around at the moment so it breaks. The issue is with my hacked mirror where I've regenerated the Packages and Release files, so I know I'm doing something wrong there, but don't see how my Packages is different.
<slangasek> bryceh: we can reduce these bug reports to "please stop using python-support, you should be using dh_python2 instead"
<bryceh> slangasek, I notice it got demoted to universe in precise; I take it that it's deprecated?
<slangasek> bryceh: with prejudice
<bryceh> yep http://wiki.debian.org/Python/TransitionToDHPython2
<slangasek> in fact, it should've been in universe before precise
<slangasek> huh, apparently it wasn't - well, it is now and good riddance ;)
<bryceh> slangasek, ok thanks.  Yeah the package builds in oneiric with python-support, but not precise
<cjwatson> rbasak: mkfs - dunno
<cjwatson> rbasak: er, not somewhere where I can easily look right now, but I thought the order there was hardcoded
<rbasak> cjwatson: if you've got time: http://paste.ubuntu.com/991309/
<cjwatson> rbasak: give me an hour or two, dinner here
<rbasak> cjwatson: thanks! For later: I've got a partial debmirror (quantal main/restricted only) and that works fine. I'm taking a copy and manipulating some unrelated packages (currently just adding a kernel) and using apt-ftparchive to regenerate/sign Packages and Release, and that breaks
<seb128> does anyone knows if build-arch: rules target (source using cdbs) sould work fine in the current version?
<cjwatson> seb128: pretty sure build-arch is fine, but you should have a build target depending on build-arch anyway ...
<seb128> cjwatson, I'm trying to figure why the current Debian gtk version fails to build on precise
<seb128> the rules has
<seb128>  build-arch: $(call dh_subst_files,$(DEB_ARCH_PACKAGES))
<seb128> dh_subst_files = $(patsubst %.in,%,$(wildcard $(addprefix debian/, $(addsuffix *.in, $(1)))))
<seb128> debian/%: debian/%.in
<seb128> ...
<seb128> basically
<seb128> but seems like that rules is never called when doing a build
<seb128> there is no build target depending directly on build-arch in the rules (but maybe cdbs or something does it in Debian)
<cjwatson> seb128: maybe you should add one; I don't know cdbs.  does it build on quantal?
<cjwatson> rbasak: ah, I knew a very faint bell was ringing somewhere; Debian #643659
<ubottu> Debian bug 643659 in cdebootstrap "Missing Depends: base-passwd" [Normal,Open] http://bugs.debian.org/643659
<cjwatson> rbasak: so I think debootstrap should be changed to make that ordering more explicit, although it's interesting that this is I think the first clear report I've heard of this happening with debootstrap
<cjwatson> rbasak: I would certainly suggest sorting your Packages file if that works around it
<cjwatson> mterry: yes, I'm happy to finish my update-manager pye port - thanks
<cjwatson> *py3
<mterry> cjwatson, hi!  OK
<cjwatson> need to fight with relative imports some more, test with new aptdaemon, figure out what's up with option parsing translation
<cjwatson> feels fairly close
<JontheEchidna> I've got a weird problem involving apt, gcc 4.7 and c++11, and I'm not sure if it's an apt or gcc bug.
<JontheEchidna> Basically, if you compile this: http://paste.ubuntu.com/991354/ with gcc 4.7/c++11 (http://paste.ubuntu.com/991357/) the example prints "error".
<JontheEchidna> If you compile with gcc 4.7 without the c++11 cflag, or compile the example with gcc 4.6 with the c++11 flag, everything's fine.
<JontheEchidna> The relevant class is in apt-pkg/contrib/error.* relative to apt source's root directory
<JontheEchidna> basically, a freshly constructed instance of apt's GlobalError class shouldn't have its member PendingMessage boolean flag set, but for whatever reason it is.
<JontheEchidna> but only when an application using the class is compiled with c++11 support in gcc 4.7
<herton> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<YokoZar> hey launchpad passed a million bugs today
<Resistance> old news, that happened early this morning (over 18 hours ago)
<slangasek> yesterday ;)
<Resistance> yep
<Resistance> about 00:00 locally at my location thoug h:P
<slangasek> YokoZar: hey, had a question for you on ia32-libs dependencies
<micahg> well, technically UTC today :)
<YokoZar> slangasek: ghosts of the past?
<slangasek> YokoZar: yeah ;) ia32-libs-mulitiarch depends on gstreamer0.10-fluendo-mp3 - why was this needed?
<YokoZar> slangasek: it was needed for wine codecs long ago (at least that's why I put them in ia32-libs) but wine enumerates its dependencies explicitly now
<slangasek> ok.  it causes problems when you try to install a different 64-bit package that implements gstreamer0.10-fluendo-mp3, because apt isn't quite smart enough with the replaces
<slangasek> or maybe I mean the conflicts
<YokoZar> hmm, interesting
<slangasek> so I think we should drop that particular dep
<YokoZar> Sure.  Who's using ia32-libs-multiarch these days though?
<YokoZar> (wine isn't, proudly)
<YokoZar> I mean, you could probably drop more deps
<YokoZar> or even the whole package :D
<tumbleweed> YokoZar: seems only boinc is (and probably a bunch of 3rd-party stuff)
<slangasek> YokoZar: well, it's already there in precise, and it's in precise that it's causing problems
<slangasek> so this is looking like an SRU
<YokoZar> slangasek: ahh ok, yes, SRU removing that dep for sure then
<slangasek> I have already wondered about removing it from quantal
<slangasek> but I'm in no hurry
<micahg> tumbleweed: a few other things as well :)
<tumbleweed> micahg: hrm, reverse-depends is lying to me, then
<micahg> tumbleweed: nope, you forgot about the transitional ia32-libs package :)
<tumbleweed> aah
<infinity> micahg: Yeah, but only boinc seems to use that...
<micahg> ah, run time deps, yes
<infinity> micahg: Things that build-dep on ia32-libs are just plain broken anyway...
<micahg> right
<infinity> Someone should have noticed that and fixed/removed them.
<YokoZar> slangasek: At the moment you can make an amd64 package depend on 32-bit libraries by just depping on ia32-libs-multiarch, if we remove it then we may hypothetically force a package to make an i386-only subpackage for their 64/32 app just to get the dependencies right
 * micahg senses another thing to clean up in quantal
<YokoZar> slangasek: (mostly thinking of 3rd party junk here)
<micahg> infinity: we ran out of time :)
<infinity> micahg: Happens, yeah.
<slangasek> YokoZar: well, yes, but we *want* to force those packages to be split that way :)
<slangasek> we don't want redundant 32-bit binaries masquerading as amd64 packages
<YokoZar> slangasek: even like a 3rd party binary-only package?
<micahg> well, if Debian makes their release goal of killing ia32-libs, then upstreams will kinda have to :)
<slangasek> YokoZar: yes
<YokoZar> slangasek: actually, that's a nice way of forcing them to setup apt repos :D
<slangasek> cf. discussions at UDS re "You should be distributing archives, not .debs" :)
<slangasek> ;)
<YokoZar> All right, I'm all for it then
<YokoZar> slangasek: relatedly, any possible movement on ".apt" format or similar, ie how to distribute these archives?
<infinity> YokoZar: Like, a signed tarball of an archive, insyead of just hosting the files?
<infinity> instead, too..
<slangasek> infinity: rather, a standard file for distributing metadata about an apt source to allow it to be auto-configured
<YokoZar> infinity: no I mean a standard way of adding a repo by parsing a file (and maybe installing a package)
<slangasek> YokoZar: and yes, that was one of the two areas of improvement discussed in the UDS session that we think we'll want to tackle this cycle
<infinity> Ahh.
<YokoZar> slangasek: it's nice to see my 3rd-party-apt spec get revived from its 6 year old grave when I first proposed it at UDS-Boston :D
<slangasek> heh
<mbiebl> slangasek: hi
<slangasek> mbiebl: heya
<mbiebl> slangasek: is there a way to tell mountall to timeout waiting for a device to show up?
<slangasek> hmm, not really
<slangasek> what would you want it to do after timing out?
<mbiebl> my use case is this: I have several amazon  EC2 instances
<mbiebl> where /var/log is on a attache EBS volume
<mbiebl> if that EBS volume is not attached, the boot hangs at that point
<mbiebl> nobootwait doesn't quite work as I want, as then it can happen that services are started before /var/log is mounted
<slangasek> right
<mbiebl> (when the EBS volume is attached)
<slangasek> so you want the boot to continue with or without /var/log if it's not found?
<mbiebl> this is on lucid, btw
<mbiebl> I want it to continue
<bdmurray> that sounds kind of like bug 610869
<ubottu> Launchpad bug 610869 in mountall (Ubuntu) "mountall ignores nofail mount option" [High,Triaged] https://launchpad.net/bugs/610869
<slangasek> I would do a job like this: http://paste.ubuntu.com/991493/
<slangasek> mbiebl: ^^
<slangasek> but of course that sets a global timeout which may or may not be what you want
<mbiebl> right, I basically just want to say that /var/log is not critical
<mbiebl> but still have the correct ordering in the usual case
<slangasek> yeah
<slangasek> seems like the bug bdmurray points to is related
<slangasek> but we really would need to be able to set a per-filesystem timeout option in /etc/fstab to do what you want
<mbiebl> that would be ideal, yes
<slangasek> or maybe nobootwait semantics should just be changed to include a centrally-configured timeout
<slangasek> then you could use nobootwait and get the right behavior
<slangasek> hmm
<slangasek> mbiebl: I think this warrants a bug report against mountall; could you file one?
<slangasek> (unlikely that any fixes will get backported to lucid though, sorry - but we could do something for precise)
<mbiebl> sure, np
<mbiebl> just waiting for the point release before upgrading
<slangasek> ah, then perhaps we should fix it for the point release ;)
<mbiebl> will file a bug tomorrow
<mbiebl> thanks for you input
<slangasek> ok, cheers
<slangasek> er, hmm
<slangasek> mountall does have a --dev-wait-time option ;)
<slangasek> mbiebl: hah, looks like this may already be implemented with a 'timeout' fstab option
<slangasek> I think mountall needs a better manpage :P
<mbiebl> yeah
<mbiebl> I've grepped the man pages for keywords like that
<slangasek> or rather this needs to be added to the fstab manpage, which does document all the /other/ mountall extensions
<mbiebl> slangasek: I've checked mount, mountall and fstab :-)
<mbiebl> the mountall man page is rather *short* :-)
<slangasek> so there's a default timeout of 30 seconds; overridable with an argument to mountall; and a 'timeout' fstab option
<mbiebl> hm, if the default is 30 seconds, then I wonder why the boot blocks indefinitely
<slangasek> the timeout *only* applies to filesystems marked 'timeout'
<mbiebl> ah
<mbiebl> will try that tomorrow
<slangasek> ok - let me know how it turns out :)
<mbiebl> slangasek: ok, this seems to require a newer mountall. The lucid version doesn't understand the timeout option yet
<slangasek> ah, interesting
<slangasek> I didn't realize there were new features added post-lucid
<slangasek> but ok
#ubuntu-devel 2012-05-17
<zul> can someone review python-jsonschema its been sitting in new for a while now and its needed for glance
<geofft> Someone mentioned at UDS there's a way to tag patches as forwarded (or not or notneeded) to Debian, separately from forwarded upstream. I don't see this immediately in the packaging guide or in DEP-3, what's the syntax?
<tumbleweed> geofft: Bug-Debian: ...
<geofft> I see the Bug-Debian etc. field. I guess that's usable for the same thing
<tumbleweed> the debian bug is the appropriate place to forward the patch, so if you are mentioning the bug, you shuold forward the patch there too.
<geofft> Hrm. I would have interpreted Bug-Debian as "this fixes this Debian bug", not as "the pull request for this patch is this Debian bug", but there's not a huge difference
<tumbleweed> Debian doesn't have pull requests
<geofft> i.e. if you have a wishlist feature request that doesn't solve an existing bug. I guess you should go file a wishlist bug, yeah
<tumbleweed> (unless the packaging is in a non-alioth-hosted VCS somewhere that does)
<geofft> The one thing that Bug-Debian doesn't provide is a "not needed" option
<tumbleweed> then you are going to mention that it's ubuntu-specific in the Description and have a Fowarded: not-needed, anyway
<tumbleweed> the way you forward a patch to debian is by opening a bug, with a patch...
<geofft> oh, and I see that the implicit value for Forwarded is conditional on the Bug field.
<geofft> okay, I can see that way of thinking
<geofft> well, you could have Ubuntu-specific patches that should get forwarded upstream, e.g. if Ubuntu has some random person's patchset and Debian doesn't
<tumbleweed> fair enough, but that's non-ideal in the first place :)
<geofft> first example that comes to mind is a patch to overlayfs; Debian doesn't need it forwarded but upstream does
<geofft> (the kernel is special, admittedly, but you can imagine it happening elsewhere)
<infinity> If it's suitable for upstream, it's suitable for Debian (except in the case of software that just isn't *in* Debian, which renders the above conversation moot).
<infinity> If it's not suitable for other downstreams, it's not suitable for upstream.
<geofft> I think the other suboptimality might be that you could use Bug-Debian to say "this fixes this Debian bug, but I didn't actually make a comment on the Debian bug saying as much"
<geofft> but then you're just being a jerk.
<broder> we mostly enforce that socially
<geofft> yeah, fair enough, I'm convinced that Bug-Debian is what I actually care about and the exceptions are sufficiently rare
<tumbleweed> barry: yay (re launchpadlib py3k porting INPROGRESS)
<broder> and we're getting queue control!
<tumbleweed> orly? I missed that
<cjwatson> broder: I'm only working on upload permissions so far
<cjwatson> But it's a start
<cjwatson> Haven't quite figured out how it works when people have queue admin for only part of a queue; no doubt I'll get there ...
<broder> tumbleweed: i just saw cjwatson mark the relevant bug as in progress :)
<cjwatson> broder: bug 648611 (kind of mistitled) is the bug for the queue admin side of it
<ubottu> Launchpad bug 648611 in Launchpad itself "ubuntu-sru either have too much or too little permission as queue admins" [High,Triaged] https://launchpad.net/bugs/648611
<broder> oh, hmm
<broder> i wonder why i decided that bug #914779 was exciting
<ubottu> Launchpad bug 914779 in Launchpad itself "Pocket maintainers cannot always upload to their pocket" [Low,In progress] https://launchpad.net/bugs/914779
<broder> i guess that's for ubuntu-backporters should be able to upload to all of -backports?
<broder> kind of stopped caring once i got core-dev :-P
<cjwatson> Ye
<cjwatson> s
<cjwatson> And other such things; ultimately it should let us get rid of the hardcoding of ubuntu-security in LP
<cjwatson> Though that requires a bit more considerably more complicated work
<cjwatson> Anyway, the DB column is the same for upload and queue admin, I just didn't want to try to do both in the same branch
<psusi> cjwatson, is there *any* part of ubuntu you don't work on? ;)
<superm1> siretart: oh i must have missed that further in the log, i'll re-read the rest.  as for the internal copy of ffmpeg, they have some code they have forked for now that their delta doesn't make sense upstream but they need internally when used with DVB of sorts
<superm1> so while it is possible to link to a system ffmpeg it will certainly break
<elky> StevenK, woot
<janimo> cjwatson, hi, is there a clean way in grub-mkconfig snippets to modify an existing line in an already generated part of the config file - to remove a boot cmdline argument to be precise?
<janimo> to be even more precise the vthandoff=7 part should be deactivated in a custom build and currently a grub-mkconfig hook is sedding the grub.cfg.new file but that does not always work
<Kalidarn> does anyone know if a feature like https://www.youtube.com/watch?feature=player_detailpage&v=TRIyqLrwXVY#t=4s is planned?
<Kalidarn> (ie dragging to the corner to get the window to lock to 1/4th of the screen)
<htorque> Kalidarn: that's already doable with compiz (grid plugin)
<Kalidarn> oh awesome, last time i used ubuntu you could only do 1/2 a screen like in windows 7.
<htorque> Kalidarn: download the compizconfig-settings-manager and change the resize actions in the grid plugin: http://img.xrmb2.net/images/271735.png
<Kalidarn> ah, thankyou very much.
<htorque> np :)
<SpamapS> Kalidarn: be *careful*
<SpamapS> Kalidarn: ccsm can really break unity
<Kalidarn> fair enough, i'll know what caused it to break if it does.
<Kalidarn> mm, i wonder hwo 11/close
<Kalidarn> oops
 * apw just did an install and at the end it says 'downloading langpacks' and later 'installing langpacks' but if i look its actually also installing libreoffice en-toto, is that expected
<cjwatson> apw: suspect you might find that's an upgrade
<cjwatson> janimo: in general, no - the text has already been generated but there's no guarantee that it's been flushed
<cjwatson> janimo: if you don't mind changing gfxpayload as well, you could just emit 'set linux_gfx_mode=text' perhaps
<cjwatson> jquery-ui-themes wins the prize for today's silliest binary package names.
<cjwatson> I: jquery-ui-themes -> libjs-jquery-ui-theme-hot-sneaks_1.8.18+dfsg-1.
<cjwatson> I: jquery-ui-themes -> libjs-jquery-ui-theme-le-frog_1.8.18+dfsg-1.
<cjwatson> I: jquery-ui-themes -> libjs-jquery-ui-theme-swanky-purse_1.8.18+dfsg-1.
<janimo> cjwatson, would set linux_gfx_mode=text imply a non-graphics splash?
<cjwatson> janimo: No, just a text-mode handover from GRUB to the kernel
<janimo> cjwatson, would this make the change to vthandoff  unnecessary?
<janimo> I think the issue with vthandoff was it caused black screen with a poulsbo-like driver
<janimo> tseliot, ^ ?
<cjwatson> janimo: 'set linux_gfx_mode=text' has two effects: it causes 'set gfxpayload=text' rather than 'set gfxpayload=keep', and it drops vt.handoff=7
<cjwatson> It'd be great if somebody in the MIR team could review jbigkit (bug 993304); it's blocking a few things now.
<ubottu> Launchpad bug 993304 in jbigkit (Ubuntu) "[MIR] jbigkit" [Undecided,New] https://launchpad.net/bugs/993304
<apw> cyphermox, hey ... i have a pile of machine on my local lan which keep disconnnecting and reconnecting to the network (its an ipv4/ipv6 dual stack), the first thing i see is NM saying device state change to failed due to ip-config-unavailable; am wondering if you have any advice as to how to debug
<tseliot> janimo, cjwatson: it's the gfxpayload=text part that I'm trying to avoid
<cjwatson> tseliot: so just emitting 'set linux_gfx_mode=text' is probably what you want to do
<tseliot> cjwatson: well I would need 'set linux_gfx_mode=keep' but how would you suggest that I do it?
<cjwatson> Oh, sorry, misunderstood
<cjwatson> =keep will leave you with vt.handoff=7 by default
<cjwatson> I assume you're trying really really hard to avoid modifying /etc/grub.d/10_linux directly, since that's easier than this hackery
<cjwatson> But you *could* perhaps redefine the gfxmode function in a later grub-mkconfig hook
<janimo> yes, probably that's the easiest
<cjwatson> To just something like
<cjwatson> function gfxmode {
<cjwatson>         set gfxpayload="$1"
<cjwatson> }
<cjwatson> pitti: Am I right in thinking that ~lp_queue/manual-queue/ was only ever used for langpack uploads, and that we no longer do them that way?
<cjwatson> There was a rejected set of langpack uploads in there from something like 2007, which I removed, and nothing else in evidence
<geser> "/usr/include/i386-linux-gnu/bits/string3.h:103:1: error: inlining failed in call to always_inline 'strcpy': function not inlinable" is this an error in the package itself? or somewhere else? and how to fix it?
<geser> https://launchpadlibrarian.net/104397135/buildlog_ubuntu-quantal-i386.libcitadel_8.05-1_FAILEDTOBUILD.txt.gz is the build log
<cyphermox> apw: i'll have a patch for you to test in a few minutes
<tseliot> cjwatson: where would I call that function from?
<tseliot> gfxmode
<cjwatson> tseliot: You don't need to, the fragments generated by 10_linux do so
<tseliot> cjwatson: but wouldn't I still get vt.handoff=7 this way?
<cjwatson> tseliot: Not if you redefined gfxmode to not set vt_handoff to anything
<tseliot> cjwatson: ok, I get it now. Thanks
<janimo> cjwatson, but redefine it in a hook prior to 10_linux so it takes precendence?
<roaksoax> is merges.ubuntu.com being fully deprecated now?
<cjwatson> roaksoax: Not at all!
<cjwatson> roaksoax: It's just having hardware trouble which I've been trying to work through with IS.  It looks as though it'll need a replacement machine.
<roaksoax> cjwatson: ah! I see now. I was just wondering why the lists were outdated! But thanks for the clarification! :)
<geser> roaksoax: not that I know of, I know that is has (had?) hardware issues
<geser> cjwatson: would it be possible to add a note about it on the MoM frontpage till it got fixed?
<slangasek> cjwatson: would it be more straightforward to move merges to the cloud somehow?
<xnox> slangasek: we need persistent storage for the results, but the cloud can do the merge attempts.
<slangasek> right
 * xnox cloud tends to have holes in the floor, which make valuable files drop off the cloud.
<mdeslaur> slangasek, cjwatson: merges needs to be a trusted machine, since some people rely on the tarball that is generated. Else, we need to throw the tarball away and just keep the report.
<slangasek> mdeslaur: I didn't mean /that/ cloud ;)
<xnox> if rossetta is emailing me about errors in translation templates from a recent package I uploaded.... do i have to deal with them?
<slangasek> xnox: generally no - they're usually upstream issues that you don't need to do anything about
<mdeslaur> slangasek: just making sure :)
<slangasek> xnox: if you *touched* the translations and are now getting errors, you should worry about it :)
<cjwatson> geser: good idea; done
<xnox> slangasek: On 2012-05-17 07:33z (2 hours 55 minutes ago), you uploaded a file with
<xnox> Catalan (ca) translations for grub in Ubuntu Precise package "grub2" to
<xnox> Launchpad
<Laney> Does mom download all sources from D + U?
<cjwatson> slangasek: the main difficulty, aside from sheer awkward size, is that merges needs to keep a lot of source packages around which are no longer in any current archive to serve as base revisions; not to mention archived patches and the like
 * xnox somehow thinks catalan speaking users just might use sudo over the next 5 years.
<cjwatson> xnox: I think that one is ignorable
<slangasek> xnox: yeah... maybe that's cjwatson's problem? :) (grub2)
<slangasek> cjwatson: right
<cjwatson> there are a few things that Rosetta more or less legitimately whines about that I haven't bothered fixing because it involves liaising with upstream translators and it didn't look that important; and I think possibly also some cases where it was just being pedantic
 * xnox notes down "if in daubt, `maybe that's cjwatson's problem?`"
<cjwatson> Laney: only given series in each, but yes
<cjwatson> xnox: ...
 * xnox rips the paper apart.
 * Laney saw something about block storage somewhere â¦
<cjwatson> yeah, it might be doable now that canonistack does block storage, but I'm not about to move an important production service to it until others have shaken out the bugs first :)
 * slangasek nods :)
<Laney> I was thinking as an interim until the hardware is acquired
<xnox> msgfmt didn't give any error...
<cjwatson> Laney: given its apparent I/O problems, I'm not sure I could transfer the current state to the cloud without IS help anyway
 * xnox is ignoring that translation file
<cjwatson> MoM isn't desperately cloudy right now; it could be, but if it were actually going to take advantage of the cloud properly it would need to be refactored rather a lot
<cjwatson> not to say that wouldn't be a good idea
<Laney> cjwatson: Can it not recreate its own state? Or do you think that would be too network heavy?
 * Laney would be willing to give the current code a spin
<cjwatson> It needs to have its pool available for base revisions
<cjwatson> In general it cannot recreate its own state entirely from scratch
<Laney> ah, so it can't use snapshots / LP to download old stuff
<Bluefoxicy> so I was thinking about hibernation
<Bluefoxicy> I'm not sure how the kernel does it.  :|
<cjwatson> Not at the moment, and it's possible not everything is available on either; I've certainly seen cases in the past where casey was the only thing I could find that had managed to retain something
<Laney> I can believe that it wouldn't get 100% coverage
<cjwatson> I don't know exactly what the problem is, but doing a full run causes it to reboot, so I have no confidence that I could rsync off the data; but I gather the problem is more likely to be RAM or RAID controller or something, not the disks themselves
<cjwatson> So I'd rather wait for IS and continue to hassle them :)
<Bluefoxicy> for a rough outline my thinking is:  1)  Prepare the system (flush all buffers, finish fetching I/O from hardware, etc); 2) Stop scheduling all user applications; 3) Flush all buffers and page cache; 4) Remount read-only everything except the target for /hiberfile; 5) Flush all application RAM to /hiberfile (through LZO or LZ4); 6) extend /hiberfile to hold kernel RAM; 7) RO-mount the file system; 8) Flush kernel memory to /hiberfile
<Bluefoxicy> that's probably completely different from what the kernel actually does :|
<Bluefoxicy> although I think being able to flush to a dynamically created hibernation file and (OPTIONALLY--good for 32GB RAM and slow hard disk, not so good for SSD or SCSI-RAID etc) compressing the data as it's written out would be useful
 * Bluefoxicy rambles about nothing interesting
<xnox> Bluefoxicy: what are you trying to achive?
<Bluefoxicy> xnox:  I think it'd be nice to be able to hibernate without a swap partition, or with a swap partition that currently has too much swapped onto it to take on all of RAM
<highvoltage> uwin 41
<Bluefoxicy> xnox:  This is already possible--you can hibernate to a swap file; but more interesting would be swapping to a dynamically created file (i.e. not a swap file), and the potential applications for compressing the hibernation file may be interesting (compression may be slower than just writing to disk; then again disk may be too small to hold 5-10 gigs of hibernation data)
<Bluefoxicy> I think on MY system compressing would be slower than writing straight, because I have an SSD with a SandForce chipset that compresses data on-the-fly to improve throughput anyway--compressing stuff before writing it to disk actually slows my disk access
<xnox> Bluefoxicy: i always have swap as twice my RAM, exactly because of failing to swap. Usual and rude answer is "you should be using LVM and just extend your swap partition".
<xnox> I don't have fancy drives.
<xnox> I do have full disk encryption with LUKS
<xnox> good luck, sounds like a reasonable cause.
<Bluefoxicy> xnox:  I just use zram
<Bluefoxicy> (by the way, don't ever load the zcache module:  it doesn't actually do anything--as I understand it should work compiled it, but does not work as a module--and it completely destroys the kernel's ability to manage page cache)
<xnox> nice ! =)
 * xnox goes to blog 'how to load zcache module to make your ubuntu run faster'
<Bluefoxicy> http://article.gmane.org/gmane.linux.ubuntu.devel.discuss/13766 <-- this is me
 * xnox wait a second!
<Bluefoxicy> haha
<xnox> maybe i should read -discuss....
<Bluefoxicy> seriously, when I had zcache loaded my kernel kept purging cache down to like 150MB and then struggling with all the extra disk access, with a gig of free RAM sitting around :P
<Bluefoxicy> things got very slow
<slangasek> tremolux: hi, are you guys by chance able to marshall some SRU testing resources for this software-center update?
<slangasek> tremolux: it's a very large delta with a lot of different bugs, and per the SRU process we should be trying to get validation for each of them; I fear this SRU may stall without a concerted effort to validate, which would be unfortunate given that it fixes a lot of top crashers
<barry> cjwatson: \o/
<cjwatson> we'll see if it works for other people ;)
<barry> :)
<ev> cyphermox: once we have this connectivity check thing in place, what are your thoughts on me backporting it to 12.04? GNetworkMonitor is causing me lots of pain.
<cyphermox> ev: this fills me with fear
<ev> haha
<ev> oh dear
<cyphermox> ev: connectivity checking has already been included functionally, it's just not enabled by default
<cyphermox> especially for something that will go poll a website, I much rather doing this only in quantal
<ev> okay
<ev> I might drop it anyway. libcurl will still fail, so we wont actually lose the report.
<tremolux> slangasek: hey! yes, I was going to give it another day or two to wait for other folks to verify, then I was going to go through any remaining ones myself so that we don't delay past the initial window
<tremolux> slangasek: I think we can marshall the esteemed davmor2 to help as well
<slangasek> tremolux: hurrah :)
<tremolux> slangasek: :D
 * tremolux is dying for USC to no longer have the top crasher on errors.ubuntu.com  ;)
<micahg> mdeslaur: did lintian build for you yesterday?
<cjwatson> mdz,pitti,kees,stgraber,soren: just found mail in the TB moderation queue about a catch-up with the CC in their meeting starting in 25 minutes ... can any of you attend?  I might be able to be at part of it but possibly not all, so it would depend where we are in the agenda
<cjwatson> also the TB has been fairly quiet lately so not sure I have much to say :)
<stgraber> cjwatson: I won't be able to make it, at least not the first half hour or so
<Bluefoxicy> anyone know where the script is for the liveCD boot system?
<Bluefoxicy> I want a peek at it
<Bluefoxicy> particularly the part that mounts the /cow
<cjwatson> casper
<Bluefoxicy> (which right now is just tmpfs)
<cjwatson> specifically you probably want scripts/casper there
<Bluefoxicy> k
<mdz> cjwatson, I can
 * Bluefoxicy apt-get src casper
<Bluefoxicy> cjwatson:  trivia #2:  why 'casper'?
<cjwatson> mdz: thanks - I'll try to sit in if I can
<cjwatson> Bluefoxicy: I blame mdz :)
<Bluefoxicy> it's not really analagous to Norton Ghost or anything
<cjwatson> it was a friendly ghost reference, because it did weird magic
<cjwatson> I think
<Bluefoxicy> ah
<mdz> more or less
<Bluefoxicy> and Sardra would have been less appropriate because Sardra is an a-hole
<Bluefoxicy> (A wizard did it)
<mdz> cjwatson, the fridge calendar disagrees with the email :-/
<cjwatson> is that a WoW reference?  in that case, not to mention that ~nobody had heard of Sardra when casper was written
<cjwatson> mdz: imagine my surprise
<Bluefoxicy> cjwatson:  8 bit theater, a running gag is that a certain small boy is repeatedly subjected to horrible, horrible things as consequence of everything the main characters do
<mdz> perhaps the CC meeting would be a good place to propose abolishing all forms of scheduling except one
<Bluefoxicy> so he becomes the most powerful wizard in existence, returns to the beginning of the universe, and attempts to become god by commanding it and remaking the universe WITHOUT those guys
<Bluefoxicy> this fails so he just takes to doing horrible things to them
<barry> cjwatson: btw, you should post to u-d@ about the ubiquity port :)
<mdeslaur> micahg: lintian?
<cjwatson> barry: oh yeah
<barry> cjwatson: feel free to make it a veiled call for volunteers <wink>
<infinity> cjwatson: Yes, please, include a diffstat and make sure we all feel appropriately inadequate! ;)
<micahg> mdeslaur: yes, you sponsored it :)
<mdeslaur> micahg: oh, is that one of the syncs? no idea
 * broder perks up at mention of lintian
<micahg> mdeslaur: umm, it didn't build :)
<mdeslaur> micahg: oh well
<infinity> micahg: Did you happen to retry it already?
<micahg> infinity: failed locally as well :)
<infinity> micahg: Same ENOSPC failures?
<infinity> Oh, wait.
<infinity> *cough*
<mdeslaur> micahg: would be nice if we'd get build failure emails
<micahg> mdeslaur: there's a bug for that (syncs don't send build failure e-mails)
<mdeslaur> micahg: how's it failing?
<micahg> Bug #902114
<ubottu> Launchpad bug 902114 in Launchpad itself "When sponsoring using copyPackage, the sponsored person is not sent email from Soyuz" [Low,Triaged] https://launchpad.net/bugs/902114
<micahg> mdeslaur: one of the tests is failing
<Laney> I think you mean bug #862251
<ubottu> Launchpad bug 862251 in Launchpad itself "Sync requester doesn't receive build failure emails" [High,Triaged] https://launchpad.net/bugs/862251
<mdeslaur> micahg: that bug is for the sponsored person to get the email
<infinity> Actually looked more like fakeroot failing.
 * infinity waits for it to fail again.
<Laney> does the sponsor get the FTBFS mail for normal uploads?
<micahg> Laney: yes, that's the bug I was looking for
<micahg> infinity: yeah, I think you're right
<micahg> mdeslaur: just a reminder to test build before sponsoring :)
<mdeslaur> micahg: yeah, I'll definitely keep away from sponsoring next time :)
<infinity> Actually, there are a ton of failures in the test suite...
<infinity> *sigh*
<micahg> this seems to be a common recurrence with lintian every release
<infinity> Well, if I'm reading the changelog correctly, this one might have dropped Ubuntu support and forced us to modify it anyway, unless the maintainer was kind enough to include an Ubuntu-specific DB for his new generic derivatives handling.
 * infinity hasn't grabbed the source yet to see.
<broder> wait, huh?
<broder> the stuff niels did was ubuntu friendly
<mdeslaur> micahg, infinity: sorry about that, I didn't usually test build syncs before, but I'll be more careful
<broder> (i.e. the purpose of that code was so that we no longer threw tags about original-maintainer)
<infinity>     + [NT] Remove Ubuntu specific handling of distribution names.
<infinity>       Instead replace it with a more generalized one that derivatives
<infinity>       can reuse by extending vendor specific data files.
<broder> right
<broder> and the data files are in there
<infinity> broder: I'm not implying that those changes are unfriendly, just that they require ubuntu-specific files to be there, and I didn't check to see if they are, or if we're expected to tack them on.
<broder> lintian.uw.o is currently running with something ~2 commits older than the release
<infinity> broder: Ahh, kay.
<broder> so lintian itself works, even if the test suite doesnt'
<infinity> The hardening failures in the testsuite seem pretty obvious (the baseline expectation is just plain wrong for Ubuntu compilers).
<infinity> Other failures looked a bit more confusing.
<broder> can you pastebin a log?
<infinity> The build's still running.
<infinity> When it's done, it'll be in the "pastebin" called the "launchpad librarian", referenced from https://launchpad.net/ubuntu/+source/lintian/2.5.7/+build/3493637 :P
<broder> heh
<micahg> mdeslaur: thanks, at this point of the cycle, I think it's more about encouraging good practices than the actual failure as we'd probably have gotten it next week some time
<cjwatson> mdz: well, now I'm completely confused, since there's been no activity in -meeting either at the fridge time (which also == the usual obvious UK DST misinterpretation of the mail) or the mailed time
<mdeslaur> micahg: I didn't think building locally when syncing was a good practice. Would help if this was documented somewhere.
<mdz> cjwatson, indeed. I just sent an email
<mdz> I wonder if they were expecting a response and canceled it when they didn't receive one
<micahg> mdeslaur: hmm, okay, /me wonders where syncing is documented at this point
<cjwatson> SyncingAndMerging hopefully
<cjwatson> Hm, maybe not, memory like a thing with holes in
<Bluefoxicy> mkfs.ext2 is valid from casper?
<Bluefoxicy> or is that not in $PATH at that time?
<melodie> hi
<mdeslaur> micahg: ah, here's the docs: https://wiki.ubuntu.com/SyncRequestProcess
<zul> Can an archive admin review  python-jsonschema please?
<mdeslaur> micahg: I'll add info about a local build to the wiki
<micahg> mdeslaur: it's already implied, but a test build of some sort should really be done, thanks
<mdeslaur> micahg: implied by what?
 * micahg is reluctant to say required and isn't sure why
<micahg> Sometimes the sponsor requires a build log of the Debian package compiled in the Ubuntu release as proof that the new Debian version still compiles in Ubuntu.
<micahg> that implies a requirement of still building in ubuntu to be sync'd
<cjwatson> Bluefoxicy: easy test: boot with break=casper-bottom, and you get a shell so you can look
 * Laney thought it was accepted best practice to test build all uploads (sponsored or not)
<Bluefoxicy> cjwatson:  nice
<mdeslaur> Laney: well, I do test build uploads, but I wasn't test building syncs
<micahg> Laney: only for certain people :)
<Laney> not all people follow best practice :P
<micahg> true
 * infinity admits that he doesn't always test-build syncs, but does watch to make sure they don't fail.
<geser> mdeslaur: any special reason for this? as syncs are similar to uploads
<Bluefoxicy> http://pastebin.com/dfabCsAU
<broder> man, i had forgotten how intense the lintian test suite is
<Bluefoxicy> cjwatson:  any way I can break into the shell BEFORE casper is executed so I can replace the script and see what happens?
<mdeslaur> geser: no special reason, it just didn't occur to me that syncs were supposed to be handled differently than autosyncs
<Bluefoxicy> or do I need to build a livecd and boot it in VirtualBox to find out?
<Laney> my, Lintian's test suite takes rather a long time to ru
<Laney> n
<Bluefoxicy> (the diff above is my first, untested attempt to tell casper to use a zram device instead of tmpfs for the /cow and copy-to-RAM, with ext2 being the filesystem of choice)
<Bluefoxicy> (the advantage is that these are compressed and so take up less RAM)
<geser> mdeslaur: for me syncs are a special kind of uploading, so I test-build them like I do before uploading a package
<mdeslaur> geser: yes, I agree I should have been doing that, and will from now on...It just didn't occur to me before
<cjwatson> Bluefoxicy: you could just  zcat | cpio -it  the initrd and see what it contains
<cjwatson> Bluefoxicy: oh, misread - you can break=mount IIRC
 * micahg hugs mdeslaur
<cjwatson> yeah
<cjwatson> though you don't have many tools, so sometimes rebuilding is easier
 * mdeslaur hugs micahg back
<Bluefoxicy> hahavvv
<Bluefoxicy> there's no editor
<Bluefoxicy> well that's not a problem
 * Bluefoxicy mounts the squashfs from the medium, uses the tools there >:D
<infinity> micahg, broder: Alright, lintian failed again on the buildds, this time without crazy fakeroot issues (that must have been some other transient oddity).
<mdeslaur> infinity, broder: is one of you already taking a look, or shall I poke at it?
<broder> i am not currently taking a look
<cjwatson> Bluefoxicy: there is sed, which is occasionally useful with a bit of creativity; but yeah, no full-screen editor
<broder> i can take a look later if you'd like
<infinity> mdeslaur: I was just rebuilding to see if a previous issue was reproducible, I'll leave it to you to fix the current issues. :P
<micahg> mdeslaur: I'd suggest pushing back on AnAnt to look at it
<broder> might be worth pinging nthykier in #debian-qa on oftc to see if he can hel[p
<infinity> (The hardening failures are obvious, some of the others look slightly less obvious at first glance)
<mdeslaur> yeah, I'm trying to figure out the apache2-modules failure
<mdeslaur> hah, lintian is FTBFS on debian too
<mdeslaur> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673198
<ubottu> Debian bug 673198 in lintian "lintian: The 2.5.7 source package is missing files (causing FTBFS)" [Serious,Open]
<xnox> stgraber: http://debblog.philkern.de/2012/05/lazyweb-question-how-to-avoid-leaking.html lxc ?
<debfx> mdeslaur: <nthykier> Alternatively touch t/tests/apache2-modules-general/skip will make Lintian skip the test, which should be fine until the next upload
<infinity> mdeslaur: Oh, that's comforting.  One more reason why Debian needs to switch to source uploads.
<mdeslaur> debfx: awesome, thanks
<micahg> that's the problem with Debian and arch:all packages, no clean build env
<infinity> micahg: Yeah, see, speaking of people's "best practices" for syncs above, one of the first things I do is check buildd.debian.org logs.  Which is useless for arch:all.
<micahg> infinity: yeah, I like to do that as well
<micahg> helps on non-x86 archs
<stgraber> xnox: yeah, something like http://www.stgraber.org/2010/12/12/having-fun-with-containers/ (back when arkose was called sandbox). The only issue is that it needs root privileges...
<stgraber> xnox: you could also do something similar by directly using lxc-unshare -s PID <cmd>
<stgraber> xnox: but that'll all be a lot more secure once we have the user namespace in the kernel and these no longer require root access
<geser> just to realise that the build log for the arch you're interesting it doesn't exist because that's the arch the DD uploaded
<cjwatson> I vaguely recall hearing once that there was an interface whereby a DD could post their own build log, but of course hardly anyone does
<infinity> Yes, it's a tricky and high tech interface called "email".
<infinity> Though, it's been so long since I was a buildd admin, I now forget where the emails get sent. :P
<cjwatson> Yeah, I also find that I just send e-mails addressed to Santa Claus and they get where I meant them to go
<infinity> ;)
<cjwatson> Alternatively, "nobody remembers the right address" :-)
<cjwatson> - [cjwatson] Port ubiquity: DONE
<cjwatson> + [cjwatson] Port ubiquity: INPROGRESS
<cjwatson> barry: hmm?
<cjwatson> barry: (also, sent that mail now)
 * Bluefoxicy fixes a few bugs.
<Bluefoxicy> well it ALMOST worked (besides that I had to cp mkfs.ext2 out of the squashfs)
<Bluefoxicy> it's notably possible to mount the squashfs early and run /filesystem.squashfs/sbin/mkfs.ext2 ... all the libraries it needs are in /lib on the initrd
<cjwatson> still best to use LD_LIBRARY_PATH when running binaries from a different fs
<cjwatson> even if it happens to work at the moment - we learned that lesson in d-i a while bac
<cjwatson> k
<mdeslaur> not to self: never touch lintian again
<Bluefoxicy> cjwatson: i think it doesn't matter anyway ... tmpfs swaps, this is silly.  Just using zram as swap would accomplish the same goal methinks
<barry> cjwatson: maybe the work items got out of sync in our browsers?
<barry> cjwatson: thanks for the email
<Bluefoxicy> i installed chromium, brought the universe repository down ... there's about 400MB in /cow now and it's taking up 66% of its original size (the actual file data takes up 56%)
<Bluefoxicy> so this isn't great anyway
 * Bluefoxicy scraps this as  wasted effort.
<cjwatson> barry: ah well, fixed now
 * barry remembers to refresh the page before editing it
<dobey> hmm, multiarch breaks a symlink installed by libqt4-dev it seems
<cjwatson> shame there's no collision detection
<dobey> no idea why the symlink is there at all though
<barry> yeah
<bryceh> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bryceh
<bryceh> slangasek, lp #1000541 is assigned to you (and you fixed it for precise-proposed) but it's in the sponsoring queue with a patch from someone else that looks ok; shall I go ahead and upload it for quantal or would that mess you up?
<ubottu> Launchpad bug 1000541 in ia32-libs (Ubuntu Quantal) "ia32-libs-multiarch depends on gstreamer0.10-fluendo-mp3, causing problems when installing packages from partner" [Medium,Triaged] https://launchpad.net/bugs/1000541
<bryceh> slangasek, I'll go ahead and send the fix for quantal
<slangasek> bryceh: ia32-libs was going to be pocket-copied from precise-proposed to quantal
<slangasek> I don't think there's any point in fixing separately for the two, since it's a metapackage
<bryceh> slangasek, ah, too late
<slangasek> pfft
<slangasek> bryceh: did you increment the version number in the changelog?  Otherwise it'll be rejected and I still win ;)
<bryceh> slangasek, 20090808ubuntu36
<bryceh> didn't change it from the supplied patch
<slangasek> right, that's the version number I already used for -proposed because I knew it was going to quantal
<slangasek> so I'll pocket-copy now
<slangasek> (done)
<bryceh> you and your silly archive admin powers
<slangasek> ;)
<bryceh> there's a surprisingly large amount of not valid sponsor items in the queue today :-/
<maco> i hope the one i pre-reviewed before telling the person to submit it isn't one of them
<micahg> well, with 79  items, I'd hope some are valid :)
<bryceh> 0 for 4 so far
<stgraber> bryceh: if there are some you want to see off the queue, ping me with the URL and the status you want (Work in progres / Rejected / Merged)
<maco> oh good, her package did get sponsored and is in -proposed
<farkerhaiku> Hi, I was wondering for the correct value to insert into the gtk settings.ini file for gtk-shell-shows-app-menu and gtk-shell-shows-menubar.  For gtk-shell-shows-app-menu, the documentation says to use something that evaluates to TRUE, but we've tried "true", "TRUE", and 1 with an exception in my xsession-errors (asking here due to the canonical gtk fork)
<bryceh> stgraber, yeah https://code.launchpad.net/~jeffreytremaine/ubuntu/precise/balazarbrothers/fix-829819/+merge/106110 needs off the queue; already got taken by debian and we'll just sync it in (just a typo fix)
<bryceh> stgraber, thanks
<stgraber> bryceh: actually, just mark them as disapproved and I'll do a mass cleanup tomorrow morning during my shift, will be easier that way I guess
<bryceh> stgraber, ok sounds good
<farkerhaiku> The error we get is "Key file contains key 'gtk-shell-shows-menubar' which has a value that cannot be interpreted"
<slangasek> cjwatson: hmm, seb128 pinged bug #900526 about stalled SRUs... did we intend to have any further SRU verification for !lucid?  Not sure if we should kick those back out as "not worth it", push them without further verification, or rustle up the testing resources
<ubottu> Launchpad bug 900526 in debian-installer-utils (Ubuntu Hardy) "d-i fails to divert initctl when upgrading packages during install" [High,Fix committed] https://launchpad.net/bugs/900526
<geser> does quantal auto-sync from testing or unstable?
<geser> bryceh: can you do a quick sponsoring of "syncpackage libmemcached"? libmemcached 1.0.6-1 fixes the FTBFS in quantal. (or do you prefer a bug for it?)
<farkerhaiku> If there's a better place to ask this sort of question, I'll be happy to ask there
<bryceh> geser, a bug would be helpful yes
<bryceh> geser, for some reason syncpackage fails to run for me.  Trying to get it sorted, but if I don't, the bug will be there for someone else to do
<maco> farkerhaiku: maybe True
<maco> farkerhaiku: since python likes that capitalization...
<farkerhaiku> maco: I'll give that a shot
<maco> (i'm just guessing)
<infinity> bryceh: I'll sync it.
<infinity> geser: Don't bother with a bug.
<geser> infinity: thx
<geser> infinity: do you know if quantal auto-sync from testing or unstable?
<infinity> geser: Currently testing.
<infinity> Oh, hrm.  I hope you didn't want credit for that, I forgot -s
<infinity> (synced, though)
<Laney> bryceh: I'd appreciate it if you could process my emacs23 MP at some point during your shift too; emacs being uninstallable causes me great pain.
<geser> no problem, no credit needed (and I doubt one sponsored upload more (or less) would make a difference during an application)
<stgraber> Laney: I hear that vim works fine in quantal :P
<Laney> Don't look at the size of the diff. Launchpad knows nothing.
<bryceh> Laney, sure thing
<infinity> stgraber: ^5
<Laney> I actually use both, so you won't get anthing out of me :P
<geser> infinity: "currently"? will it switch at some point to unstable or it's not decided yet? or will it stay at testing for whole quantal?
<Laney> it will change
<infinity> geser: The plan is to switch to unstable, we're not entirely sure what will break when we do. ;)
<geser> only the whole universe and multiverse :)
<Laney> no change there
<infinity> geser: On, I didn't mean in the archive, but rather various launchpad UIs and bits going haywire because you can't really change derivation without fallout.
<infinity> It'll be a fun experiment.
<bryceh> Laney, heh your merge broke bzr
<Laney> heh
<Laney> maybe I can rustle up a debdiff
<bryceh> Laney, awesome
<Laney> UDD: the future.
<ajmitch> Laney: gold star for you!
<Laney> bryceh: http://people.ubuntu.com/~laney/emacs23_23.4+1-3ubuntu1.debdiff.xz
<Laney> Yes, I had to xz it.
<bryceh> wows
<Laney> The ubuntu-restore-non-dfsg thing is pretty crazy
<slangasek> twitch
<micahg> Laney: that's against the new Debian revision?
<Laney> I'm sure it could be done better with multiple-orig
<Laney> yeah.
<Laney> Or moving the non-dfsg thing to main or something.
<micahg> eek, /me adds to personal /ignore list
<Laney> slangasek: since you're here and we're talking about emacs, could you process bug #998460 please? :-)
<ubottu> Launchpad bug 998460 in emacs23-non-dfsg (Ubuntu) "Remove from Quantal and blacklist" [Undecided,Confirmed] https://launchpad.net/bugs/998460
<slangasek> hmm
<slangasek> poooosssibly
<Laney> Well, unless you think we could move it into main
<slangasek> is the blacklist still where it was?
<Laney> for now, yeah
<slangasek> main, or universe?
<Laney> hmm
<Laney> what relationship does it have?
<slangasek> it sounds like it might be easier to just shuffle the pockets, and keep the packages in sync with Debian
<infinity> Laney: If... Err, what vorlon said. :P
<infinity> If emacs23-non-dfsg really is just the same stuff that we're adding back in our diff, that seems like a silly amount of effort for us.
<slangasek> the only binary package it builds is emacs23-common-non-dfsg... should that be a dependency of emacs?
<slangasek> honestly, either way, I think that may be the simpler route
<slangasek> i.e. I don't see any barrier to having it in main if that's where it belongs
<slangasek> in fact since it's just a binary package split, it shouldn't need a MIR
<Laney> if we're OK having it in main as a Depends, that should get us to ~ where we are now
<Laney> and let us drop a bunch of delta
<infinity> Sounds reasonable to me.
<bryceh> dropping delta sounds nice
<slangasek> it's just the docs, after all
<slangasek> Laney: I'm in favor of just making it a binary dep from emacs23 and avoiding the horror deltas :)
<slangasek> rather, from emacs23-common
<Laney> rock
<Laney> deleted debian/patches/ubuntu-restore-nondfsg-files.diff
<rbasak> There's a tool to filter various apt list type files, but I can't remember what it's called and I can't find it. I think it's named after grep. Does anyone know what I'm talkinga bout?
<Laney> Probably grep-dctrl
<rbasak> that's it - thanks|!
<bryceh> Laney, do you want to shoot me another .debdiff for whatever remains?
<Laney> bryceh: yeah, 5 mins
<bryceh> Laney, great, thanks
<Laney> long emacs build is long
<bdmurray> If I'm planning on tag a bunch of bugs should I email ubuntu-devel or someone? or just have at it
<bdmurray> slangasek: what do you thinkâ¸® should I email some group before tagging a ton of bugs in Launchpad
<Laney> bryceh: http://people.ubuntu.com/~laney/emacs23_23.4+1-3ubuntu1.debdiff
<Laney> off now, I'll pick up any issues in the morning
<Laney> o/
<bryceh> Laney, thanks cya!
<bryceh> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<bryceh> bdmurray, 355 dupes against libx11, oh my
<bdmurray> and the one after that looks similar
<bryceh> bdmurray, of course the bug won't open now
<bdmurray> bryceh: use /+text
<bryceh> yeah I know
<bdmurray> should write a greasemonkey script to mark up +text
<bryceh> bdmurray, note that it says it's _asserting_ in libx11.  That (usually) means that the client is making x11 calls incorrectly
<bryceh> heh that'd be awesome
<bdmurray> right, I think we talked about an update-manager bug too
<bryceh> yeah so 507062 sounds like it might be a bug in cairo causing it
<slangasek> bdmurray: hmm, I don't see any need for emailing ubuntu-devel before tagging a batch of bugs.  will you be doing the tagging as a bot account?  That might be best, so people can filter out that kind of thing
<bdmurray> slangasek: yes a bot.  Right, I'm not sure the email is really necessary either, I just recall doing that years ago.
<Bluefoxicy> hmm, so here's a good question then
<slangasek> bdmurray: personally, I wouldn't worry either way
<slangasek> anyone who has time to worry about mass-tagging clearly has too much time to read bug mail ;)
<Bluefoxicy> tmpfs gets swapped, so there's no reason to put it on a zram device
<Bluefoxicy> Making an ext2 on a /dev/zram2 etc does work and will get you compression, but it's pointless
<Bluefoxicy> But what's the equivalent for block devices?
<bdmurray> slangasek: and doing it now it will get mixed in with other noise
<Bluefoxicy> to my knowledge there's no dm-compress, so the prospectus for compressing a COW on a persistent device is minimal
<psusi> Bluefoxicy, btrfs supports compression... there were some patches for ext compression but they were never merged
<psusi> Bluefoxicy, it can't be done at the block layer
<Bluefoxicy> psusi:  good point.  I'm trying to figure what's good for a persistent root.
<Bluefoxicy> er, cow
<psusi> Bluefoxicy, wait, what's your goal?  cow or compression?
 * Bluefoxicy patches casper to mount the cow at /moo instead
<Bluefoxicy> psusi:  I was just thinking like if you did a persistent root on a USB stick, it'd be huge
<Bluefoxicy> psusi:  especially if you upgraded packages etc
<melodie> Bluefoxicy, you could remove the packages and the docs once the update done
<Bluefoxicy> but also if you install to USB, you wind up with a situation where a 700MB CD becomes 2 gigabytes of crap
<melodie> I have persistant "changes" directory for one distro and I manage it not too bad
<Bluefoxicy> or... you copy filesystem.squashfs to the USB stick under a partition, use a COW partition
<Bluefoxicy> melodie:  that's true
<psusi> Bluefoxicy, try installing to btrfs with compression enabled?
<melodie> I also use this mode to make the changes in the usb stick before installing with the changes to hard drive
<melodie> Bluefoxicy, and usb sticks tend to be cheaper and cheaper. a 4 gb here now can be found for less than 5 euros.
<Bluefoxicy> melodie:  true as well, but does that have a dual-channel controller and get 60MB/s transfer across the bus?
<melodie> how can I check it ?
<Bluefoxicy> mind you my SSD gets about 384MB/s (it's on SATA2) and is capable of about 500MB/s if I get it on a SATA3 controller
<melodie> SSD is faster than usb 2 right ?
<Bluefoxicy> hdparm -t I guess
<Bluefoxicy> SSD is much faster :P
<Bluefoxicy> so is HDD
<melodie> what is your goal exactly ? perform a usb install for yourself or add a feature for all in a program ?
<Bluefoxicy> the other part of this argument is that reading 5MB of compressed libraries and expanding it to 15-25MB is likely faster than reading 25MB outright from a slow USB stick that can get 9MB/s
<melodie> I am very much interested in persistant modes on usb sticks to tell you all.
<Bluefoxicy> also I'm just asking questions right now
<Bluefoxicy> anyway psusi has a point
<melodie> very probably.
<Bluefoxicy> btrfs now supports LZ4, which is excellent:  unlimited parallel compression/decompression, the algorithm is fast, and it has pretty good compression ratios on par with LZO
<Bluefoxicy> parallel execution is fantastic with all these 4 core Intel i5 systems and the likely 16-32 core ARM systems we'll see in the future
<melodie> the interesting part for persistant, apart from the nomadic which is obvious, is the possibility to install a fully up to date and personalized (on the fly) version... at any time after a given distribution version has been made available.
<melodie> how much data can you put in a 700 MiB compressed iso, if using btrfs with LZ4 ?
<melodie> Let's say current usual programs, nothing special as sounds and videos.
<psusi> not as much as you can with squashfs
<psusi> the problem with compression is that it is always a tradeoff between compression ratio, and random access
<psusi> the more data you compress at once, the better compression you get, but to access some random data in the middle, you have to decompress the whole block
<melodie> which in clear means safe access to data ?
<melodie> or fast access...
<mdawkins> just means more memory is used to decompress
<melodie> ok
<psusi> that and you have to read data you don't necessarily need.
<melodie> ok. :)
<psusi> that's why gzip gets better compression that pkzip.... pkzip compresses 32k at a time... but if you want to extrat a file from a .tar.gz that is near the end, you have to spend a long time reading and decompressing the whole thing, but zip can skip to the end and start decompressing there
<mdawkins> is there any discussion about the unioning fs?
<melodie> psusi, what you said about squashfs does not concern unionfs right ? I think they are two different things ? (aufs vs unionfs maybe ?)
<mdawkins> melodie: the unioning fs is what makes the livecd interesting
<mdawkins> otherwise you cant do much with it except for boot and install
<psusi> melodie, unionfs just takes two different filesystems ( or more ) and combines them into one... it has nothing to do with compression
<psusi> aufs is the same thing pretty much
<mdawkins> i have been playing with overlayfs
<melodie> which one is used by default at Ubuntu ?
<mdawkins> i thot they were moving to overlayfs after speaking to dev
<mdawkins> but that was awhile ago
<melodie> good night
#ubuntu-devel 2012-05-18
<bryceh> stgraber, still about?
<bryceh> I've got 7 branches from the sponsor queue that need set to Work In Progress.
<bryceh> anyone able and willing to poke at merge proposal status buttons for me?
<mdeslaur> infinity: texlive-base in uninstallable right now...you were doing the tex stuff, right?
<slangasek> bryceh: I thought WIP was a status anyone with uploader rights could set?
<bryceh> slangasek, yeah I don't know.  Some branches I can set it but most I can't.
<slangasek> weird
<bryceh> I seem to recall there was a bug filed against LP about it, but doubt it's going to get attention any time soon
<infinity> mdeslaur: Seriously, who/what broke it this time? :/
<mdeslaur> infinity: looks like texlive-base got bumped and now needs a newer texlive-bin
<bryceh> 1000557, 1000558, 1000560, 1000561 were some textlive-* syncs that came through today
<infinity> bryceh: Oh dear.  Those are wildly sensitive to ordering, it seems.
<mdeslaur> infinity: so I now have an additional reason why lintian FTBFS :P
<infinity> bryceh: And can't happen without also merging texlive-bin.
 * infinity will do that now, and hopes this doesn't need another bootstrap.
<jbicha> infinity: you should be able to sync texlive-bin, right?
<jbicha> as in, I don't think we need to maintain a diff any more
<infinity> jbicha: If I'm reading the changelog correctly, while he included our patch, he didn't enable it.
<infinity> jbicha: Plus, there's the libpng transition (have we started that?)
<jbicha> well the patch didn't work....
<jbicha> I was told libpng-dev works fine on Ubuntu
<infinity> Well, yes.  It should.
<infinity> Cause our resolver's sane.
<infinity> Or insane, depending on opinion.
<infinity> Fair enough.
<infinity> Also, lolwut:
<infinity>    * move patches from debian/patches to debian/quilt, add quilt as
<infinity>      build dep, and include quilt patching in debian/rules
<infinity>      this gets us rid of the "strange" parts of the 3.0 format
<infinity>      (see quilt vs dpkg-source fuzzyness acceptance).
<jbicha> have you read the debian-devel discussion?
<infinity> I'm pretty sure I don't want to.
<infinity> Not if it resulted in the above.
<mdeslaur> infinity: GAH! seriously??
<jbicha> he doesn't like that dpkg fails on fuzzy patches, unlike quilt push
<jbicha> quilt push; quilt refresh is too much work!
<mdeslaur> wow, he wants to rely on fuzzy patches...awesome :)
 * infinity shakes his head.
 * infinity holds his nose and syncs.
<infinity> mdeslaur: I dare you to publically call him out on why relying on fuzzy patches is a Really Bad Idea.
<infinity> mdeslaur: But wear a false moustache, so no one knows you're from Ubuntu and/or Canonical.  Thanks.
<infinity> mdeslaur: That should totally circumvent the CoC.
<mdeslaur> infinity: uhm, yeah...I'll have to think about it...I get enough hate mail as it is :)
<infinity> mdeslaur: Oh, I can stop sending those, if you need to free up some time.
<mdeslaur> lol
<bryceh> heh
<slangasek> infinity: yeah, you don't want to read that thread
<infinity> slangasek: You know I'm going to now.
<psusi> wait, what the crap... he intentionally avoided the automatic quilt integration of 3.0 (quilt)?
<mtx_init> Good evening.  I am making a custom install, english is the only language needed, How can I turn off the menu asking the user for language?  I found the langlist in the isolinux directory but that just limits my selection
<infinity> psusi: Yeahp.  Which, to be fair, is commonly done for other reasons (like, when it violently disagrees with your VCS workflow), but his entire argument was that he *likes* quilt, but only if it allows fuzzy patches, which bare quilt does, dpkg-source doesn't.
<psusi> so basically he doesn't want to have to run quilt refresh?
<psusi> and isn't there something you can shove in debian/source/options to change that behavior?
<infinity> psusi: No, he doesn't want to be "forced" to resolve fuzziness until he's good and ready to!
<infinity> psusi: Read the thread.  Well, up until he stops responding.  It devolves into something unrelated after that.
<lifeless> infinity: whats the subject ?
<psusi> yea, but you resolve fuzzieness by just running quilt refresh
<infinity> psusi: And then, if you're sane, checking that the refresh gave you the correct result, but yes.
<infinity> lifeless: http://lists.debian.org/debian-devel/2012/05/msg00711.html
<lifeless> oh
<lifeless> I killfiled that on the subject alone
<infinity> psusi: I mean, by definition, a fuzzy patch implies that it miiiiight not be applying correctly, so trusting quilt refresh blindly is as silly as trusting it to remain fuzzy.
<infinity> psusi: But arguing that one should be allowed to upload their fuzzy patches and go check/unfuzz them "later, when I get around to it, how dare you force me, dpkg fascists" is a fun read.
<lifeless> its almost as bad as using a vcs and doing merges.
<infinity> I dunno.  I have little sympathy.  I used to maintain a package whose patch system was "for i in debian/patches/*; do patch -p1 < $i; done", and I used to review every patch and hand-edit for both fuzz and offsets on every upstream bump.
<infinity> Made sure I definitely knew how and why they still applied, and let me scan to see if maybe they'd been duped a few lines up, etc.
<infinity> I don't really grasp why this is "hard".
 * RAOF pines for 3.0 (bzr)
<infinity> RAOF: It's been pointed out that any of the 3.0 (vcs) formats present issues with license autiting, unless they're shallow clones/checkouts, which then loses most of the point.
<infinity> auditing, too.
<infinity> Typing hard.
<RAOF> infinity: Yeah, I've read that.
<RAOF> We're pretty much doing it anyway, though, just ad-hoc.
<RAOF> I'm not sure if there's a huge difference between distributing as source-package on ftp.debian.org and distributing as, say, git branch on alioth. Perhaps there is.
<infinity> I wouldn't be against doing it the way Nokia/maemo did with building from git tags.
<infinity> RAOF: The difference is that alioth isn't mirrored.
<infinity> RAOF: Nor is launchpad.
<RAOF> So... we can potentially clean up a mess on Launchpad, but not on archive.ubuntu.com?  Is that it?  I guess there's another indirection of distribution, too, but that's surely not a problem for the vast majority of things.
<infinity> Well, there's also the reality that branches-with-history as source packages would just bloat mirroring even more.  I do really like the "tag in a VCS, have a bot build a source package from the tag and upload it" way of doing things.
<infinity> No other infrastructure needs to change, source mirrors still have source packages that are shallow checkouts, but the VCS becomes authoritative (which it currently isn't, no matter how much people pretend it is).
<RAOF> That would also work, yes.
<mdeslaur> we've been asked to be able to retrace tarballs to upstream releases with their signatures, to make sure they have not been trojaned during downloads and stuff
<infinity> mdeslaur: pristine-tar solves that.
<mdeslaur> infinity: ah, interesting
<infinity> mdeslaur: And yes, I'm also in the "orig should be an exact copy of upstream's source, except when licenses prevent that" camp.
<RAOF> Yeah, that's actually really useful.  You can just pull the package branch, and it'll reconstruct the tarball for you.
<mdeslaur> I wonder how big the delta files it generates are, and if they're auditable
<RAOF> It depends on the tarball; they're often sub-kibibyte.
<RAOF> I'm not sure what you'd need for them to be auditable, though. The ability to see what they change from the VCS without applying them?
<infinity> Yeah, auditing them isn't really required, since it's the result that matters.
<infinity> checkout + pristine tar = orig + debiandiff + dsc = normal source package.
<infinity> The tiny xdelta is opaque to people who don't speak fluent xdelta (which is, like, everyone), but it's the resulting tar that it creates that you care about, which is obviously identical to the upstream one, so you win.
<mdeslaur> infinity: and are you building the package from the complete checkout, or just from the commits starting with the tarball's tag?
<infinity> mdeslaur: See pristine-tar commit and pristine-tar checkout.  You generally point it at a tag that represents the clean source.
<infinity> mdeslaur: Then you build the rest of the package from the tag that represents your Debian upload, now that you have a proper orig.tar.gz in ..
<infinity> Not positive, cause I don't use them, but I'd be surprised to discover that svn/git/bzr-builddeb don't already incorporate all of this into some nicely-wrapped workflow.
<mdeslaur> oh, right, so the metadata is stored at the same time, I see
<mdeslaur> s/metadata/delta/
<infinity> Given that the delta's metadata, it was right either way. :P
<mdeslaur> heh
<RAOF> infinity: bzr-builddeb does it in a somewhat more sophisticated way - it stores the delta as a commit property on the upstream merge, rather than using a dedicated pristine-tar branch.
<RAOF> Which has the pleasant property that I don't forget to push the gorram pristine-tar branch back to alioth all the gorram time.
<micahg> I think texlive-binaries is the last piece of the texlive puzzle
<micahg> oh, nevermind, that's bin
 * infinity nods.
<infinity> Patience.
 * micahg goes and grabs that hat off the shelf
<infinity> RAOF: When I was working on maemo in git, I just got use to push --everything-damnit-argh.
<infinity> s/use/used/
<RAOF> Sadly my repositories almost always contain branches that shouldn't be pushed.
<infinity> Well, yes.  I didn't actually push everything. ;)
<infinity> But I got used to remembering what I needed.  I dunno.  It gets drilled in after a while.
<infinity> Especially with an annoying bot that tells you you're a loser.
<infinity> "Hai, you pushed Debian revision tag, but I no haz upstream version tag matching, plz fix and/or die, kthx."
<RAOF> That'd work :)
<RAOF> Rather than the current method, which is the first person who tries to use the branch pinging me and going âhey, could you please, you know, make this branch actually *useful*?â
<psusi> so again, he's pitching a fit because he doesn't want to have to run quilt refresh after rebasing to a new upstream or inserting patches in the middle of the stack?
<psusi> who's in charge of the ubuntu foundations bugbot?  I think it's buggy
<micahg> psusi: nope, it's purposeful
<psusi> a few times in the last 24 hours or so, it apparently has flagged bugs as private and not subscribed ubuntu-crashes-universe for no apparent reason
<micahg> oh, hrm, that issue :), ask bdmurray
<psusi> thus, I get emails about bugs being filed, but can't go triage them
<dobey> ow. that thread hurt my brain :)
<psusi> it is hurting my brain too
<psusi> "We know what a primary concrete objection is.  We discussed it at length
<psusi> at DebConf two years ago, and then on debian-devel afterwards.  Uploading
<psusi> a Git archive requires reviewing the entire contents of the archive, not
<psusi> just the current code, for licensing issues, which is pretty painful from
<psusi> the ftp-master perspective."
<psusi> what the hell does that mean?
<dobey> i think the short version is "I have no idea what the hell I'm typing right now."
<RAOF> psusi: It means that the ftp-masters, who among other things need to check that what's being distributed is actually *distributable*, would need to check that *every revision* in the git history was distributable rather than just the final tarball.
<psusi> RAOF, I don't grok that... if the project is gpl, then it's distributable, regardless of whether you are distributing the head revision, or the full history
<dobey> psusi: assuming it was always GPL and didn't ever include anything that conflicted with that
<RAOF> psusi: Is every file in the full history GPL?  Has upstream ever made a mistake and committed something they shouldn't have?
<dobey> who the heck would stick a git archive in as a debian package anyway
<dobey> that's just insane.
<RAOF> People who basically already *use* a git archive as their source package? It's not like we're not doing it with bzr branches, either.
<dobey> "Here's 300K of code, and 5GB of history. Enjoy!"
<psusi> if they did commit something they aren't authorized to distribute, then THEY have to expunge it from their git repo
<dobey> RAOF: well, we're storing source packages inside bzr branches. the source package doesn't include the bzr history, no?
<RAOF> dobey: Some people have the source package branched of upstream trunk, and that's really quite useful.
<dobey> RAOF: well, they have a vcs which has the source. apt-get source package doesn't pull the bzr history, does it? or is it smart and pulls form Vcs-Foo now?
<RAOF> psusi: Yeah, but that doesn't help Debian. Sure, upstream needs to not distribute things that they don't have a license for. Debian also needs to not distribute things that they don't have a license for, and as a practical matter are *vastly* more likely than upstream to care.
<RAOF> dobey: apt-get source doesn't; debcheckout does.
<dobey> ah ok
<psusi> what's more, if they ever did put in unlicensed code, then simply not including the history doesn't help us does it?  because if the *current* code can be traced back to the unlicnesed code as a derived work, then the current code also can not be distributed
<RAOF> dobey: But I think the (eventual) end-goal is for the bzr branch to be the primary object; that people no longer upload source packages, just appropriately tagged bzr branches.
<lifeless> psusi: not if they got a license for it, which may involve changing it
<psusi> in other words, if you really don't trust upstream when they say their history is distributable, then you still have to audiit the history fully whether or not you are only distributing the head, or full history
<dobey> i basically never trust upstream when they say their code is distributable
<lifeless> psusi: that doesn't follow
<dobey> programmers, designers, and artists aren't lawyers
<psusi> lifeless, you mean they obtained the right to distribute derived versions, but not the old one that they still retain in their history?
<RAOF> dobey: Indeed! We care *much* more about copyright than the wast majority of upstreams.
<lifeless> psusi: yes
<psusi> then they are violating that grant
<psusi> by still having the old version in thier repo
<RAOF> But not in a way that Debian has to care.
<dobey> i could throw a nanobot into the vast sea of the internet and hit at least 5 license violations :P
<lifeless> psusi: not necessarily: say that the original version was distributable by them but not transitively
<lifeless> psusi: thats fairly common in fact
<dobey> indeed, distributable != redistributable
<lifeless> psusi: to get a transitively distributable version, they do something, which results in the code being different; there is now something in the history that:
<lifeless>  - they can have on the net
<lifeless>  - users can suck down
<lifeless>  - we cannot ship
<lifeless>  - we can ship the tip of it
<psusi> that's... fuck up ;)
<psusi> fucked up rather
<lifeless> psusi: its the exact complexity of this situation the ftp-masters quite rightly want to avoid
<dobey> eh, it's normal, actually
<RAOF> Hello, flash!
<psusi> why would the copyright holder ever say to a project you can distribute this code, but not under gpl, unless you make changes to it, THEN you can call it gpl?
<dobey> they don't
<psusi> I thought that's the scenario we were talking about... old rev isn't gpl... slightly modified version is
<psusi> both are in history
<dobey> they say ONLY you can distribute this code, from this point
<lifeless> right
<psusi> until some later point, prior to head?
<lifeless> the effect is old version == ship to your users, new version == ship under GPL/Apache/whatever
<dobey> sorry, by point i meant location
<lifeless> the old version being the one we can't redistribute
<dobey> newer code could possibly just not use that old library any longer
<infinity> psusi: Relicensing code isn't exactly uncommon.
<dobey> but the old code that uses it, and the thing itself, may still be in history
<psusi> but if they don't want their code to be redistributable, then why would they not only allow initial distribution, but redistribution on the later versions?
 * infinity glances at launchpad.
<lifeless> psusi: because they get petitioned by e.g. us.
<dobey> psusi: because the license, dependencies, etc changed
<lifeless> psusi: or they learn more about open source
<dobey> psusi: basically, the code is not the same thing it used to be.
<lifeless> psusi: or a patent got turned over
<lifeless> psusi: lots and lots of reasons
<psusi> dobey, changing the license requires the original copyright holder of all previous versions to agree though, not just whoever last touched it
<dobey> psusi: no it doesn't.
<dobey> it requires all copyright holders of current code to agree
<infinity> psusi: It requires the copyright holder of the current version.
<dobey> code that is no longer there doesn't have to change
<infinity> holder(s).
<psusi> huh?  version x is a derived work of version x-1... if the copyright holder of version x-1 doesn't say it can be relicensed under gpl, it doesn't matter what whoever touched version x says
<infinity> psusi: In your scenario, the copyright holder of x-1 is also the copyright holder of x.
<dobey> psusi: if my program used to have a huge block of code from you in it, but no longer does, i do not have to ask you to change the license of the new code
<infinity> psusi: If the copyright holder of x is different from x-1 (assignments happen), then no, I don't need x-1's permission to relicense x.
<infinity> Anyhow.  This is all rather moot.  I think it's clear (I hope?) that the license on an entire git archive doesn't have to be internally consistent.
<infinity> Or bzr, or whatever.
<infinity> And, more often than you'd think, they're not.
<lifeless> well, I think it has to be internally consistent, but if its not its a) not our problem and b) it can be internally consistent and still not consistent with the license of HEAD.
<lifeless> infinity: ^
<infinity> lifeless: How can it be internally consistent, but not consistent with HEAD? :P
<infinity> lifeless: (My meaning of "internally consistent" was "across revisions")
<dobey> anyway, must go now. later :)
<psusi> I would think that if the original file were non gpl, and even if after several revisions, none of the original code remains, and all of the revising authors grant gpl, a very solid argument could be made that the subsequent revisions were derived works and so the license could not be changed without the original author's ok
<lifeless> infinity: ah! definitions.
<lifeless> infinity: so, I think each revision needs to be internally consistent, or the owner of the archive may have trouble.
<infinity> psusi: If it's a derived work, I need permission to relicense if I don't hold copyright, yes.
<lifeless> infinity: I think cross-revision licenses can and do change, but there should be some capability granting relicenses that occur
<lifeless> infinity: none of which implies that we can distribute the archive :)
<infinity> psusi: You seem to be of the opinion that relicensing version 3.4 of my source magically retroactively relicenses all previous versions.  Which just plain isn't true, unless, again, clearly stated and agreed upon by all copyright holders.
<Chipzz> wouldn't relicensing of a file be a problem for upstream too if they published a VCS containing the old version (ie in the case of copyright violation or patent issue)?
<Chipzz> I basically don't see how this problem is unique to debian or ubuntu and not to upstream?
<infinity> Chipzz: Upstreams don't *re*distribute, they distribute.  If they hold copyright, they can do whatever the heck they want.
<infinity> Chipzz: Debian and Ubuntu not only redistrbute, but guarantee redistribution rights to others.
<infinity> Chipzz: As we're NOT the copyright holders, we need licenses to grant that.
<Chipzz> but wouldn't they have a problem with distributing the old version too?
<infinity> Chipzz: The old version that's theirs?
<Chipzz> since it's still available from their VCS
<infinity> Chipzz: As a copyright holder, you can do anything you want.
<infinity> As your downstream, I can't.
<infinity> It's as simple as that.
<Chipzz> infinity: I think you're missing the point :)
<infinity> Your violation/patent strawman is an interesting one, and yes, upstream would have to go cleaning to purge that from their VCS.
<Chipzz> upstream VCS contains file x, file x rev a has a problem (be it copyright or patent), file x rev y (which is in HEAD for example doesn't)
<Chipzz> wonrg placement of ) but whatever
<infinity> I try to operate from a default assumption that upstream has copyright on their code, and we have licenses to distribute it.
<infinity> Proving the latter is very hard with a long revision history.
<Chipzz> the problem is fixed in rev y but since ppl can still obtain rev x from VCS that revision (and hence the problem) hasn't really gone away
<infinity> Proving the former is up to courts.
<infinity> Chipzz: There are ways to purge a VCS, if upstream has that issue.
<Chipzz> right, but upstream would have to purge their VCS then
<infinity> Yes...?
<infinity> But that's not what we're talking about at all.
<infinity> We're not talking about the rare case of someone filing suit because upstream stole code.
<infinity> We're talking about upstreams and downstreams having different distribution rights.
<infinity> Which is always true.
<Chipzz> I was basically wondering if in the situation described above (before I joined the conversation) there being a problem for debian/ubuntu wouldn't imply a problem for upstream too
<Chipzz> but meh, it's getting late, and I should be sleeping :)
<Chipzz> and IANAL :)
<Chipzz> gn!
<psusi> infinity, no, quite the reverse... I am saying that unless all of the original authors agree, you can not relicense the new revision, and so a project that goes and changes license without all of the old holders' permission is not only violating copyright by distributing the old versions in vcs, but the head as well
<psusi> infinity, therefore, I don't see how you can have a situation where it is ok to redistribute the head, but not past revisions
<RAOF> psusi: Because infringing code got removed?
<lifeless> psusi: copyright isn't homogeneous, contributing to a single file (for instance) doesn't give you copyright over all files; even in books, contributing to a single chapter doesn't grant you copyright over the whole book
<psusi> yes, but if the whole chapter is removed to get around that, then what it is still doing in upstream's revision history?  shouldn't they expunge it if they can't get permission to relicense it?
<lifeless> why should they ?
<stgraber> bryceh: not sure if you found someone else to do it yet, otherwise just dump me the links in pm and I'll do it
<psusi> well, it seems really odd that 1) they would have a license to distribute, but it isn't redistributable, 2) they went to all the trouble of removing it completely without having any of the new code considered a derived work of the original, and 3) wouldn't care to expunge it from the history to avoid creating problems for downstreams when they have already done most of the work required to do so
<stgraber> bryceh: got the list from your e-mail to ubutu-devel, all done
<psusi> also I wouldn't think it would be that difficult if this were to occur, to figure out the point where the project was relicensed, and just refuse to import the history before that
<TheMuso> t/quit
<bryceh> stgraber, much thanks!
<mlankhor1t> pitti: http://status.ubuntu.com/ubuntu-quantal/people.html how do I get added to that list?
<pitti> Good morning
<pitti> micahg: gegl binaries are in main now
<mlankhor1t> morning :)
<pitti> cjwatson: I have no idea about ~lp_queue/manual-queue/ I'm afraid; langpack uploads happen the regular way, there's no special magic for them
<pitti> mlankhor1t: you need to be in https://launchpad.net/~canonical-desktop-team ; I added you now
<pitti> mlankhor1t: it should catch up in a few hours, possibly a day
<mlankhor1t> ah k :)
<mlankhor1t> thanks
<pitti> cjwatson: thanks for the universal_newlines=True subprocess hint! that's indeed one I didn't know about
<seb128> bdmurray, hey, is that wanted that your bot is going through bugs cleaning VarLogDistupgradeSystemstatetargz.gz files?
<seb128> bdmurray, would be nice to announce in some way when you do such cross archive run and why
<seb128> bdmurray, (would it only be so people know they can filter out the spam generated)
<tarzeau> are ppa's good for ubuntu? or should i put some effort/time/work into getting packages into universe (especially if it has been in there in a previous release)?
<tarzeau> or when will ubuntu sync packages again from debian?
<mpt> pitti, hi, how do I get the work item tracker to ignore work items for last cycle (other than by deleting them)? They're headered "Work items for precise:" but they're still showing up on the charts
<pitti> mpt: please retitle it to something like "work done in precise:"
<pitti> mpt: i. e. anything that does not contain "work items"
<mpt> ok, I'll try that, thanks pitti
<seb128> hey pitti, mpt
<pitti> hey seb128, bonjour
<mpt> Good morning
<seb128> mpt, are they in the whiteboard or the workitem section? (not sure how the workitem section is handled, maybe you need to move those to the whiteboard)
<mpt> seb128, they're in the whiteboard (remember, 6 months ago we didn't have a work items field)
<seb128> right, ok, so yeah what pitti said ;-)
<pitti> the tracker still looks at both
<pitti> for backwards compat reasons
<seb128> tarzeau, ubuntu packages are currently synced from Debian in Q
<pitti> we sync new packages much less often, though
<seb128> tarzeau, you can use a ppa if you want, universe give you better user exposure since it's in the default sources, where a ppa is something you need to look for and enable ... which most users will not do
<tarzeau> it's about old packages, and Q doesn't have it yet. oh well i'm just putting the stuff in our own repo
<geser> tarzeau: which package is it?
<tarzeau> geser: condor among some others, let me check...
<tarzeau> geser: and i don't get why darktable was not synced to the latest version
<seb128> does anyone knows how to debug "ureadhead doesn't seem to be used" issues?
<seb128> ivanka's login is slow, she sent me a bootchart and the ureadhead step on boot is taking less than a second, i.e seems to not be doing any preloading
<geser> tarzeau: darktable has an ubuntu delta, which should be either merged or dropped, but in any case it need human inspection
<tarzeau> geser: ubuntu has the experimental plugins package
<geser> tarzeau: and condor is currently only in unstable (but can by synced, testing if it builds in Ubuntu right now)
<tarzeau> geser: i'm building it on precise now.. condor was in ubuntu when it wasn't in debian yet, but they just threw out the a bit older version in precise
<tarzeau> natty had it though
<geser> tarzeau: the Ubuntu delta is for a FTBFS, Ubuntu has the still the pluings package because it got dropped after 1.0-1 (we still have 0.9.3-2)
<geser> tarzeau: condor synced to quantal, you can request a backport in a few days if you want to have available in precise
<geser> tarzeau: and darktable 1.0.3-1 synced to quantal too
<bkerensa> cyphermox: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/972063 <-- more affected
<ubottu> Launchpad bug 972063 in bluez (Ubuntu) "Bluetooth Headset pairs but does not show up in Sound Settings profile" [Medium,Incomplete]
<janimo> cjwatson, but redefine it in a hook prior to 10_linux so it takes precendence?
<janimo> cjwatson, sorry, accidentally repeated a question from histroy
<cjwatson> slangasek: 900526> I was actually going to do a quick sweep through my own SRUs and verify them, rather than having to debate it :-)
<cjwatson> now that we seem to have agreed that's kosher
<cjwatson> pitti: I'll nuke ~lp_queue/manual-queue/ before I lose the ability to, then :-)  I was pretty sure it was dead
<cjwatson> pitti: universal_newlines=True> yw, took me a while to figure out :)
<pitti> cjwatson: so as long as you can rely on the output being correct UTF-8, that makes it more convenient indeed
<cjwatson> pitti: FYI new packages are synced on every auto-sync run now - it's no longer true that it's a separate manual task that gets arbitrarily delayed
<pitti> cjwatson: oh, good to know!
<cjwatson> though auto-sync prompts and it's a manual decision
<cjwatson> but it provides enough information that it's a lot easier to do than it used to be
<cjwatson> janimo: np
<tjaalton> is /run/user a systemd'ism, or will we get something like that in the future?
<seb128> tjaalton, https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-xdg-runtime-dir
<seb128> bug #894391
<ubottu> Launchpad bug 894391 in consolekit (Ubuntu) "support $XDG_RUNTIME_DIR" [Medium,Triaged] https://launchpad.net/bugs/894391
<tjaalton> seb128: ooh, great
<cjwatson> ScottK: per-packageset build scoring is deployable at whenever the next Launchpad nodowntime is (today or more likely Monday, I guess).
<cjwatson> (depending on whether some other QA gets done first, it may or may not deploy with a different property name at first, but I don't think anyone will care)
<tjaalton> I'd like to add ~/.xsession-errors to the per-user runtime dir, since it's currently possible to fill up $HOME if apps go haywire
<seb128> tjaalton, is it better to file $HOME or /run?
<seb128> tjaalton, what happens if run is full?
<tjaalton> seb128: /run/user would be a separate tmpfs, but anyway
<pitti> tjaalton: it's not really meant for things like that
<tjaalton> pitti: well it's meant for krb5 cache apparently
<pitti> runtime_dir should be small files which change often and don't need to be written to disk, such as lock files, temporary copies, etc.
<seb128> tjaalton, isn't filling tmpfs a DoS?
<pitti> log files both grow indefinitely as well as should survive a reboot/logging out
<tjaalton> ok, I'm all ears how to fix this bug :)
<seb128> tjaalton, what? .xsession-errors filling up the user dir?
<seb128> I think old gdm used to truncate .xsession-errors to 500k or something
<seb128> lightdm should maybe do the same
<pitti> I think lightdm just creates a new files
<tjaalton> seb128: that's only on startup, it'll move the old file away and truncate if it's too large
<pitti> file
<pitti> but that doesn't help for long-running sessions
<tjaalton> aiui there's no way to reduce the logging
<pitti> to fix this, I don't think we can keep the current simple structure -- we need a filter in between the session and just redirecting all of its output to a file
<seb128> hum, are you sure that gdm didn't use to stop logging if the file was hitting 500k?
<pitti> yes, but only on session start
<pitti> once you have a running session there is nothing that can control this file
<tjaalton> hmm, would be neat if it was possible to feed it to rsyslogd somehow
<seb128> pitti, ok, it's a bit weird since the code is wipped out on session start so I'm not sure where the limit can kick in
<seb128> or did gdm used to not wipe it out?
<pitti> seb128: we do not have the problem on session start
<tjaalton> that patch is in xorg
<seb128> pitti, I'm pretty sure something stopped writting to .xsession-errors during session when the file hit 500k
<pitti> /etc/X11/Xsession
<seb128> but I might be wrong
<pitti> seb128: I'm not aware of that; only that we had some gdm (/etc/gdm/Xsession) which truncated everything but the last 500 kB on session start
<seb128> like it was adding "truncated..." and not logging after that
<pitti> seb128: it's still in /etc/X11/Xsession
<pitti> if [ "`stat -c%s \"$ERRFILE\"`" -gt 500000 ]; then
<pitti>   T=`mktemp -p "$HOME"`
<pitti>   tail -c 500000 "$ERRFILE" > "$T" && mv -f "$T" "$ERRFILE" || rm -f "$T"
<pitti> fi
<pitti> so if your disk gets full, you can at least log out and back in to win back some space
<seb128> pitti, well, lightdm wipe that file at login so no need to truncate it
<seb128> pitti, though nowadays it does rotate it
<seb128> pitti, which means you don't win space
<zyga> hey, has the llvm pipe stuff been rolled out to quantal yet?
<pitti> seb128: I know; I added that a while ago for other window managers which didn't do that
<pitti> zyga: it already works in precise, but unity-3d still blacklists it
<seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=459293
<ubottu> Gnome bug 459293 in general ".xsession-errors limit can be quite annoying" [Minor,Resolved: obsolete]
<seb128> in fact old gdm had code
<seb128> 		if G_UNLIKELY (d->xsession_errors_bytes >= MAX_XSESSION_ERRORS_BYTES &&
<seb128> 			       ! got_xfsz_signal) {
<seb128> 			VE_IGNORE_EINTR (write (d->xsession_errors_fd,
<seb128> 						"\n...Too much output, ignoring rest...\n",
<seb128> 						strlen ("\n...Too much output, ignoring rest...\n")));
<seb128>  
<seb128> pitti, i.e the logger job was stopping logging over a limit
<seb128> which is what I was remembering from it
<pitti> seb128: ah, so that one did put something in between the session stdout/err and a mere file redirection?
<seb128> yes
<tjaalton> it had it's own Xsession script as well, and didn't redirect the stderr/stdout to the file
<tjaalton> so ok, that'd fix it for lightdm if it had something like that
<jamespage> is there any etiquette I should be following before uploaded an large number of no-change rebuilds?
<pitti> jamespage: one thing that comes to my mind is to check whether the buildds might potentially be needed for an impending milestone or beta release
<pitti> jamespage: but since that's not the case, and the buildds are all empty and getting cold, go ahead :)
<jamespage> pitti, that had crossed my mind
<pitti> jamespage: please just make sure to not introduce "ubuntu"ish versions, use "build1" prefixes for unmodified packages
<pitti> err, suffixes
<jamespage> pitti, yep - was aware of that 'dch -R' has been my friend!
 * jamespage goes to warm up the buildd's
<pitti> oh, I didn't know about -R, thanks
 * pitti still uses an ancient script to do mass rebuilds
<Damjanek> Hi. Got a quick question about dependiences in debian/control file: I'd like to create dependency to upstream version, not to upstream+release version. How to do it? as I can see, there's no âpackage-name (~ version)â.
<jtaylor> upstream+release version?
<jtaylor> whats that
<Damjanek> 3.3.5+dfsg1-1ubuntu1 - this is upstream+release version
<Damjanek> 3.3.5 is upstream version
<jtaylor> (>> 3.3.5) ?
<Damjanek> it behaves like >=, right?
<jtaylor> that would be (>= 3.3.5) then
<jtaylor> >> behaves like >
<Damjanek> Ah.
<jtaylor> > and < should not be used
<Damjanek> I'll try it this way, then
<dpm> hi pitti, I've just been trying to build a python app, which had been building fine until I actually added po files to it. I had not noticed it locally, but when I uploaded to a PPA, I get an intltool error. It seems that it is looking for the bin/qreator.py, but that file does not exist (only bin/qreator). IIRC, python-distutils-extra in auto mode generally creates a temporary bin/qreator.py file to extract translations from it, but it did not seem to
<dpm> do it this time. Do you have any pointers on what could have gone wrong? Here's the build log -> https://launchpadlibrarian.net/105430456/buildlog_ubuntu-precise-i386.qreator_12.05.1_FAILEDTOBUILD.txt.gz
<dpm> pitti, oh, I see what happened, Quickly or p-d-e added a po/POTFILES.in file listing the .py file, that's why it can't find it. IIRC, p-d-e uses a temporary POTFILES.in file when creating the .pot file, but this one seems to be a permanent one. Perhaps that's the problem
<pitti> dpm: yes, that's correct; it won't create the "magic" POTFILES.in if one already exists
<dpm> pitti, thanks. I think it might be a bug in quickly. It seems to create and commit POTFILES.in after using the 'quickly release' command, despite using p-d-e in auto mode in setup.py.
<dpm> although quickly does not actually seem to touch any POTFILES.in files. Could it be that it got p-d-e or intltool to somehow create a permanent POTFILES.in file?
<pitti> perhaps from a failed run, when it fails to clean it up?
<pitti> but then it should have the "fake" .py entry
<Damjanek> jtaylor: Thanks for your help.
<Damjanek> Bye
<dpm> I'll keep investigating, thanks pitti
<elky> pitti, dpm is docutils involved in that?
<pitti> I doubt it, it sounds unrelated
<dpm> not that I know of
<elky> with intltool i mean
<elky> https://bugs.launchpad.net/ubuntu/+source/sphinx/+bug/997891
<ubottu> Launchpad bug 997891 in sphinx (Debian) "sometimes cannot build pdfs for de, sl, pt, es, nl, pl, or it locales" [Unknown,Confirmed]
<ScottK> cjwatson: Thanks for your work on the build priorities.  I think it's a good step forward.
<stgraber> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: stgraber
<cyphermox> bkerensa: got it, looking
<psusi> cjwatson: if grub fails to install under ubiquity, what log file would the error be in?
<ogra_> syslog ?
<cjwatson> psusi: should be in syslog and/or installer/debug
<psusi> hrm.... weird.. I looked at both log files this user posted and don't see any grub error... bug #1000934
<ubottu> Launchpad bug 1000934 in grub2 (Ubuntu) "Parallel installation with Windows fails!" [Undecided,New] https://launchpad.net/bugs/1000934
<hallyn> say, is there an easy way to tell debootstrap to use my local .deb instead of one from the archive?
<mlankhor1t> create a local repo :)
<hallyn> can i create a virtual mirror which only overrides packages i install?  wonder if mini-dak does that
<hallyn> maybe i can make it work just with --download-only and apt-move
<yofel> jbicha: a question about the boot procedure (re bug 894456): Where is fsck.<FS> read from when mountall calls it? / or initrd?
<ubottu> Launchpad bug 894456 in btrfs-tools (Ubuntu) "Please merge or sync new btrfs-tools from Debian testing or unstable - lots of bugs present in Ubuntu now :(" [Undecided,Triaged] https://launchpad.net/bugs/894456
<yofel> I'm having a bit of a hard time finding out under what exact conditions fsck is called my mountall
<yofel> *by
<hallyn> stgraber: ischroot fails with -2 if /proc is not mounted.  Fix is to temporarily mount it :)  my q is, should i do that in ischroot, or do it in the initscripts.postinst that is using it and messing up as a result?
<cjwatson> yofel: mountall runs in the real root
<yofel> cjwatson: how does it call fsck for / ? with / mounted RO or does it unmount / before checking?
<stgraber> hallyn: that's odd. I believe debootstrap mounts /proc so I'm not too sure why we don't have it mounted at the time we call ischroot
<stgraber> hallyn: or is that because initscripts gets updated later on (after debootstrap) in an environment where /proc isn't mounted?
<cjwatson> yofel: the former
<yofel> ok, thanks
<hallyn> stgraber: hm.  well then maybe i'm wrong about how i think it works
<stgraber> hallyn: I'd expect much more things to blow up if /proc isn't mounted during bootstrap
<xnox> Just started using 'request feedback' on blueprints... only to find bug #1000642
<ubottu> Launchpad bug 1000642 in Launchpad itself "Remove 'request feedback' feature for blueprints" [Undecided,In progress] https://launchpad.net/bugs/1000642
<hallyn> stgraber: all right i guess i need to nail down the local archive thing so i can better test
<cjwatson> tseliot: would you mind following up on bug 982710?  I copied it to -updates based on comment #46, but now there's a complaint about a regression
<ubottu> Launchpad bug 982710 in NVIDIA Drivers Ubuntu "[regression] Nvidia 295.40 driver is extremely slow" [Undecided,New] https://launchpad.net/bugs/982710
<cjwatson> xnox: request feedback was always an utter disaster of a UI
<tseliot> cjwatson: sure, thanks
<xnox> cjwatson: =))))
<kees> xnox: say, where do you want to coordinate raid documentation? I figure somewhere in the wiki. do you have a preference?
<xnox> kees: my preference would be a bzr branch of LaTeX documents, but I do understand that this is not the most contributor friendly format.
<xnox> kees: Wiki is probable, not sure if it will be the upstream RAID wiki or wiki.ubuntu.com
<xnox> kees: to begin with wiki.ubuntu.com
<xnox> depends how 'ubuntu' specific it will be
<xnox> kees: I'm still going through a few things here. My plan was to talk to you more after I did my initial digging of historic work done on the topic first.
<hallyn> kees: hey :)  (i answered late last night, but) yes, cap_sys_admin should be required for CLONE_NEWNS.
<hallyn> enforced by kernel/nsproxy.c (supposedly)  you're finding it isn't?
<xnox> kees: wiki.ubuntu.com ok with you? do you have a preference? (you have more knoweldge currently, so anything that works best for you is preferred)
<mdeslaur> infinity: could you take a look at my lintian debdiff before I upload it? I'd appreciate a second opinion, I'm not quite sure that's the best way to handle readelf: http://paste.ubuntu.com/994477/
<kees> hallyn: yeah, I think glibc was tricking me or something. my "child" function was getting called, but not after a clone. once I sorted things out, it correctly EPERMed.
<kees> xnox: yeah, wiki.ubuntu.com is my preference. initially, my brain-dump of the history will be very ubuntu-specific.
<kees> xnox: I was wondering what subtree to use in the wiki.  RAID/History or something?
<cjwatson> kees: oh, hey, you know about seccomp.  I don't suppose you want to take a guess at why the seccomp_filter probe child process in my patch in https://bugzilla.mindrot.org/show_bug.cgi?id=2011 falls over with SIGSYS?
<ubottu> bugzilla.mindrot.org bug 2011 in Build system "sandbox selection needs some kind of fallback mechanism" [Normal,New: ]
<xnox> kees: Maybe https://wiki.ubuntu.com/ReliableRaid/History ? Cause there is https://wiki.ubuntu.com/Raid but that should really be part of the server guide / help.ubuntu.com
<cjwatson> I haven't yet tried it in a more normal userspace/kernel combination
<hallyn> kees: ah, ok.  cool.
<bdmurray> slangasek: regarding https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/349469/comments/34 I think I see what clint was suggesting now
<ubottu> Launchpad bug 349469 in debconf (Ubuntu) "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable" [Medium,Triaged]
<bdmurray> slangasek: if we see 'config.dat' in the error message we could gather the output of another command
<kees> xnox: sure, that path sounds good.
<kees> cjwatson: looking...
<kees> cjwatson: fwiw, SIGSYS means seccomp killed it.
<cjwatson> Right, I'd worked out that much (though it was a new one on me).  But the filter it's loading should allow exit_group, which is the only syscall used after prctl in that process.
<kees> cjwatson: yeah... I was trying to find something to view the code....
<cjwatson> just grab lp:openssh
<kees> cjwatson: do you have a link to a vcs-viewer? I want to see the preauth filter
<kees> okay
<cjwatson> http://bazaar.launchpad.net/+branch/openssh/view/head:/sandbox-seccomp-filter.c
<mlankhor1t> is mmap allowed with seccomp?
<kees> I read this when Will was writing it originally. :P
<kees> mlankhor1t: depends on the filter
<SpamapS> is there no python3 bzrlib?
<mlankhor1t> was still toying with my program
<cjwatson> SpamapS: sounds like a project for you!
<SpamapS> cjwatson: aww man, why didn't you warn me before I stepped in that?
<SpamapS> ;)
<cjwatson> it hasn't been ported
<cjwatson> or, if it has, it hasn't been landed
<SpamapS> I'll skip. Been trying to use python3 in one-off scripts lately to get used to the differences.. :-P
<cjwatson> that said, they dropped pre-2.6 support in 2.4, which should help
<SpamapS> My knowledge of python3 packaging is also weak.. not sure if bzr is the place to learn
<SpamapS> though.. python-configobj might be
 * xnox sees no bugs about python3 support in bugs.launchpad.net/bzr
<kees> cjwatson: hunh
<kees> cjwatson: so, this is extra weird
<kees> cjwatson: I would expect your prctl to fail.
<kees> cjwatson: is it possible the seccomp filter is already in place, and the prctl itself is killing it?
<xnox> SpamapS: http://www.wefearchange.org/2012/01/debian-package-for-python-2-and-3.html
<cjwatson> kees: Why would the prctl fail?
<cjwatson> kees: I don't *think* that's possible, and strace shows the prctl returning 0
<kees> cjwatson: for SECCOMP_MODE_FILTER to work, you either need CAP_SYS_ADMIN or to have called prctl(PR_SET_NO_NEW_PRIVS, 1, ...) first
<kees> e.g. http://bazaar.launchpad.net/+branch/openssh/view/head:/sandbox-seccomp-filter.c#L200
<kees> cjwatson: iirc, what Chrome does to detect seccomp is to do a SECCOMP_MODE_FILTER call with an empty filter. if it replies with EINVAL, seccomp exists. if it replies ENOSYS, there's no seccomp
<kees> let me check that, though...
<kees> EINVAL would get sent for non-mode-2 as well...
<cjwatson> kees: oh, OK, I assumed the no-new-privs was unnecessary but I can go and do that now
<cjwatson> [pid  3977] prctl(0x26 /* PR_??? */, 0x1, 0, 0, 0) = 0
<cjwatson> [pid  3977] prctl(PR_SET_SECCOMP, 0x2, 0x80ac0b8, 0, 0) = 0
<cjwatson> [pid  3977] +++ killed by SIGSYS +++
<cjwatson> (adding no-new-privs doesn't help)
<cjwatson> I could restore the approach from openssh/configure if that's more likely to work; maybe I last tried that before adding the fork
<cjwatson> http://bazaar.launchpad.net/+branch/openssh/view/head:/configure.ac#L137
<cjwatson> but, in any case, if I make the probe just pass unconditionally, the monitor child does nothing obviously useful - so I'm wondering if there's something else wrong
<kees> ah! EFAULT, yes.
<cjwatson> maybe I should try in a 64-bit userspace
<kees> I do recommend the detection method from configure, though.
<kees> that doesn't require the nnp prctl, and doesn't even require a filter.
<kees> why it doesn't error out, though, is weird.
<slangasek> bdmurray: right - in theory we want to be able to do this kind of thing via whoopsie in the future so we can change such things dynamically, but I don't think we have the security model nailed down yet... so an updated apport hook could indeed be useful there
<cjwatson> kees: Has seccomp been tested in 32-on-64 systems
<cjwatson> ?
<bdmurray> slangasek: and what would that updated hook do?
<infinity> mdeslaur: Gah.  Looking.
<slangasek> bdmurray: some combination of 'fuser /var/cache/debconf/config.dat' and 'pstree', I think
<bdmurray> slangasek: okay, thanks
<mdeslaur> infinity: I'm still investigating why readelf works differently
<slangasek> bdmurray: though TBH, I've asked for that in the bug description and some people have provided those answers... and I haven't managed yet to make heads or tails of them
<infinity> mdeslaur: Yeah, I'm spinning up a sid chroot to poke too.
<mdeslaur> infinity: kees mentioned maybe related to -Bsymbolic-functions that's by default on Ubuntu
<mdeslaur> infinity: I was going to try that
<kees> and why isn't -Wl,-Bsymbolic-functions listed on https://wiki.ubuntu.com/ToolChain/CompilerFlags ?
<slangasek> bdmurray: still, if we were getting that info consistently from all duplicates, maybe we would see a pattern emerge
<slangasek> kees: because it's a linker flag? ;)
<kees> slangasek: *sigh*
<slangasek> nah, that's clearly not the reason
<stgraber> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<kees> cjwatson: yeah, works in compat mode
<slangasek> but I don't know
<kees> cjwatson: but if the arch test is wrong, it'll kill it.
<cjwatson> kees: hmm, ok, I probably screwed up something arcane then.  I'll try again later
<cjwatson> the arch test?
<kees> cjwatson: http://bazaar.launchpad.net/+branch/openssh/view/head:/sandbox-seccomp-filter.c#L83 <- that verifies that the program hasn't switched architectures (i.e. started doing compat calls when built 64-bit)
<kees> i.e. SECCOMP_AUDIT_ARCH must match the system that it's running on. (which is why it's best to avoid building a filter for the initial testing)
<cjwatson> oh, yeah, openssh isn't going to do that
<kees> cjwatson: oh! is $host wrong?
<kees> (in configure.ac?)
<cjwatson> oh, that's possible, I'm configuring by hand rather than via dh_auto_configure
<cjwatson> $ ./config.guess
<cjwatson> x86_64-unknown-linux-gnu
<cjwatson> bah, yes, good catch
<kees>         case "$host" in
<kees>         x86_64-*)
<kees>                 AC_DEFINE([SECCOMP_AUDIT_ARCH], [AUDIT_ARCH_X86_64],
<kees> yeah, so it's trying to set up a 64-bit filter and getting killed by that failure
<kees> cjwatson: so, looks like you'll need to adjust the SECCOMP_AUDIT_ARCH test a bit and skip the autodetection if there is no known arch, etc.
<cjwatson> or just configure with the right --build=
<cjwatson> so this is x86-only at the moment?
<kees> yes, though ARM patches are currently being written
<cjwatson> kees: thanks, that works now!  I'll fix up the test and resubmit upstream
<kees> cjwatson: yay! :)
<dylan-m> Hey, I'm writing some code that presents packages as applications (like "Text Editor" instead of 'gedit'). Looks like Software Centre has some pretty extensive logic to that end...
<dylan-m> Do you think there would be interest in moving that code to a separate library?
<dylan-m> So far I'm loading application .desktop files from app-install-data and the package's installed files, but there seem to be some discrepancies between my output and Software Centre's and I don't like duplicating lots of functionality.
<hallyn> hm, debootstrap from my custom mirror isn't working.
<infinity> mdeslaur: Okay, your patch looks sane.  And should also work on Debian.
<infinity> mdeslaur: Also has the added bonus of getting versions back, which their invocation seemed to drop...
<geofft> dylan-m: You might be interested in AppStream or PackageKit?
<dylan-m> Oh, it's for Update Manager, by the way. Do you know if it would be okay to have PackageKit as a dependency, geofft?
<mdeslaur> infinity: thanks for the review, I'll also add -U_FORTIFY_SOURCE, and I'll send it to debian
<kees> mdeslaur: can you CC me when you open that bug?
<geofft> I'm not the person to ask, I just lurk on distributions@l.fd.o :) But I recall hearing general "that should happen" regarding making software center and update manager use more of PackageKit.
<geofft> someone else probably knows more than I do regarding current thinking there
<dylan-m> geofft: Yeah, I've been getting that impression, too, but it looks like a bit of work to get everything talking to it :) I'm mostly concerned about being consistent for now.
<mdeslaur> kees: sure
<infinity> dylan-m: Wait, what?  You're making update-manager no longer display package names?
<dylan-m> infinity: I'm working on this: https://wiki.ubuntu.com/SoftwareUpdates#Expanded_presentation_of_updates.
<dylan-m> infinity: In short, it displays both ;)
<infinity> dylan-m: The mockup doesn't make "both" particularly clear there.
<infinity> dylan-m: (ie: what is "Terminal"?)
<infinity> dylan-m: If I have gnome-terminal and xfce4-terminal installed and both are available for update, do I just get two uninformative "Terminal" entries?
<dylan-m> infinity: Right now it's displayed as it would appear in the dash or an applications menu. I think there are a few ways to group apps and their packages that will behave slightly differently, so those will have to be played with as this goes along.
<cnd> slangasek, we need to upload a rebuild of evdev in precise for some magical ABI break that doesn't make any sense but a rebuild fixes (bug 973297)
<ubottu> Launchpad bug 973297 in xorg-server (Ubuntu Precise) "Xorg recognizes Logitech Headset USB dongle as input device then segfaults in XIChangeDeviceProperty" [High,Triaged] https://launchpad.net/bugs/973297
<cnd> the current package version is 1:2.7.0-0ubuntu1
<cnd> what would a rebuild package version be?
<slangasek> 1:2.7.0-0ubuntu1.1, preferably
<cnd> ok
<cnd> so basically the same as a full sru
<slangasek> yep
<slangasek> the only time rebuild-only uploads get a special version number is when we're currently in sync with Debian
<cnd> ahh
<barry> ScottK: ping
<cnd> slangasek, so I realized that this likely isn't fixed in quantal either since there hasn't been a rebuild of the package yet
<cnd> should I be uploading a 1:2.7.0-0ubuntu2 to quantal and a 1:2.7.0-0ubuntu1.1 to precise?
<cnd> or should I just upload to precise and somehow get it pocket copied to quantal like the current package has been?
<cjwatson> cnd: both are possible; it probably doesn't make sense to do two separate rebuilds here ...
<cnd> cjwatson, ok, so then should I forgo the SRU versioning and just upload version 1:2.7.0-0ubuntu2?
<cjwatson> I'd tend to use 1.1 myself anyway
<cnd> ok
<cjwatson> though strictly, it only needs not to clash; but you'll probably get fewer questions this way
<cjwatson> since it needs not to clash with potential future versions the SRU team doesn't know about as well :)
<cnd> yeah
<ScottK> barry: pong.  Replied to your mail.
<barry> ScottK: thanks!  i couldn't wait.  :)  glad it worked out
<kees> slangasek, xnox: ah-ha, in researching this raid brain-dump, now I know why the raid failure code wasn't running. :)
<kees> (and am documenting it)
<slangasek> kees: whee :)
<infinity> pitti: Say, uhm... Where's nscd-dbgsym?
<slangasek> infinity: did ev's blueprint eat it? :)
<infinity> slangasek: :P
<infinity> slangasek: My assumption is something more like ddebs doesn't deal sanely with packages with main/universe splits, or something, but you'd think someone would have noticed that...
<infinity> slangasek: (Or maybe pitti just dumped a bunch of universe ddebs to make space)
<slangasek> I wouldn't be so sure... it could easily be lost in the noise where ddeb bugs are concerned
<kees> slangasek, xnox: https://wiki.ubuntu.com/ReliableRaid/History
<slangasek> woot
<kees> omg, I just figured out how LVM and md get out of sync sometimes.
<kees> what a horrible race condition.
<ion> Heh, sounds nice.
<kees> I think it's because LVM lost a patch to have it ignore md devices.
<slangasek> kees: well ugh
<slangasek> which patch was that?
<slangasek> since we, er, didn't merge lvm2 forever
<kees> slangasek: I have no idea -- that will need much more digging
<kees> s/ignore md devices/ignore md components/
<hallyn> stgraber: could you ping me when you have a minute for me to pick your brain?
<stgraber> hallyn: ping
<hallyn> stgraber: thanks.  basically i'm doing https://wiki.ubuntu.com/SergeHallyn_localrepo  in the hopes of having debootstrap use my modified initscripts .debs
<hallyn> but it fails (let me pastebin the errors)
<hallyn> is it obvious to you why?  do i just need more packages than what debootstrap --download-only had grabbed?  (do i need to make it a full local mirror)?
<hallyn> here is the debootstrap.log: http://paste.ubuntu.com/994779/
<stgraber> hallyn: hmm, looks like something is wrong with your archive that confuses debootstrap and then dpkg
<stgraber> hallyn: just thinking of what you're actually trying to do, couldn't you use the --foreign flag to have debootstrap download + unpack, then change your initscript and do "chroot path debootstrap/debootstrap --second-stage"?
<slangasek> kees: this is of course an imminently SRUable issue, so let me know if you need us to do some legwork
<hallyn> yes i was going to pursue that if i couldn't get this working.  couldn't find any docs on that (besides the manpage) so i figured that woudl involve experimentation as well
<chrisccoulson> anyone got any bright ideas how to debug this? https://launchpadlibrarian.net/105416854/buildlog_ubuntu-quantal-amd64.firefox_13.0~b4%2Bbuild1-0ubuntu2_FAILEDTOBUILD.txt.gz
<chrisccoulson> the buildd is literally the only place this problem happens :(
<hallyn> stgraber: in particulary I'm not 100% clear on what state --foreign leaves it in, i.e. if i need to change a postintall script onthe chroot, or update the package in the chroot's cache
<slangasek> chrisccoulson: have you identified the root error?  looks to me like it's probably at line 283157, is that right?
<stgraber> hallyn: apparently you can do "sudo debootstrap --foreign precise my-chroot && sudo cp <your deb> precise/var/cache/apt/archives/<original deb> && sudo chroot my-chroot debootstrap/debootstrap --second-stage"
<chrisccoulson> slangasek, it's the abort in dump_syms multiple times which fails the build
<slangasek> chrisccoulson: have you ruled out it being a pkgbinarymangler issue?
<hallyn> stgraber: ah! that's why it failed the one time i tried it,
<slangasek> i.e., have you made sure to have that in your reproducing env?
<hallyn> i wasn't doing second-stage from chroot
<chrisccoulson> slangasek, no, good point!
<chrisccoulson> thanks
<chrisccoulson> i'll try that now
<stgraber> hallyn: confirmed that it runs here, so I guess it'll do the trick for you
<hallyn> it doesn't like my pkgs :)  it wants the same version as the original maybe
<stgraber> oh yeah, you'll need to have the same version
<stgraber> or manually mess with apt's list files (wouldn't recommend that)
<slangasek> chrisccoulson: another possibility might be that the code is building differently because it's running on a hardy kernel on the buildds?
<hallyn> stgraber: thanks.  i do wish i could get the mirror way working, but this gets me going :)
<chrisccoulson> slangasek, is it still a hardy kernel? i saw this line at the top of the build log and assumed it wasn't:
<chrisccoulson> Kernel version: 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64
<chrisccoulson> but if it is, then i should try that too
<hallyn> will keep working with that when i get time
<slangasek> chrisccoulson: oh, looks like you got one of the shiny new buildds then :)
<rbasak> "Failure while unpacking required packages.  This will be attempted up to five times." -- can this be made priority high rather than critical? I'd prefer my automated installs not to fail because of this.
<slangasek> rbasak: short answer: yes, I think so
<slangasek> rbasak: long answer: why is it failing?  is this more cloud apt love?
<slangasek> oh, though that's not an answer is it ;)
<rbasak> slangasek: this is d-i netinst on quantal, on ARM. It's from a static mirror, so I don't think it's apt. But it might be something I'm doing. Or it might be a temporary quantal issue. But after the retry it does work.
<slangasek> hmm
<slangasek> it's quite unusual that you should hit that
<rbasak> It's reliably reproducable for me at the moment.
<slangasek> can you grab the logs showing what failed?
<slangasek> (/var/log/syslog, I believe)
<rbasak> It's complicated, but let me try :)
<hallyn> stgraber: for pete's sake.  in the end, it turns out the args to compat_link are just int he wrong order
<ajmitch> heh
<stgraber> hallyn: ;)
<stgraber> hallyn: how comes that only broke containers?
<hallyn> well it's a path only taken 'if ischroot'
<stgraber> ah right
<hallyn> and then, toward the end, because the link failed, it mkdirs it
<hallyn> hm, there goes my battery again saying 'not present'
<xnox> kees: slangasek: Added two clarification footnotes on to https://wiki.ubuntu.com/ReliableRaid/History
<slangasek> xnox: o
<slangasek> k
 * xnox is worried. Is 'ok' split between two lines mean something dramatic?!
<slangasek> it means "I have forgotten how to type in my old age"
<hallyn> slangasek: hey - changelog for initscripts says you did the /dev/shm /run transition...  would you mind checking my debdiff on bug 974584 for sanity?  I can't help feel I'm doing something stupid
<ubottu> Launchpad bug 974584 in sysvinit (Ubuntu) "Semaphores cannot be created in lxc container" [High,Confirmed] https://launchpad.net/bugs/974584
<slangasek> hallyn: peeking
<hallyn> thx
<slangasek> hallyn: ln argument naming really is the worst
<slangasek> why would anyone call the real file being pointed to by a symlink the "source"
<slangasek> hallyn: yeah, looks like you're right
<slangasek> I'm surprised to see this hasn't been fixed in Debian either
<slangasek> well now, wait
<slangasek> if compat_link /var/run /run; then
<slangasek> how does that part 8ever* succeed, if this is backwards?
<hallyn> bc if the target exists it exits early with success?
<slangasek> heh
<hallyn> (sorry, checking :)
<hallyn> but no, when running debootstrap, at that point, /run/lock already exists.  so does some other package create /run/lock with /run as symlink to /var/run?
<slangasek> good question
<hallyn> dpkg -x initscripts*.deb x; ls -ld x/run.  run is there
<slangasek> hallyn: base-files extracts /run/lock
<slangasek> s/extracts/creates/
<hallyn> ok, so on an upgrade that might not happen?
<slangasek> hallyn: so is that consistent with your analysis?
<hallyn> yes
<slangasek> base-files creates /run/lock on initial package install only (so as part of debootstrap).  On an upgrade from a system / chroot initially installed using base-files lt 6.4, you won't have it from base-files
<hallyn> on a system, you wont' hit that path.  only in a chroot.  so... does anyone do that?  if so, why didn't they hit this?
<slangasek> hallyn: so my precise chroot has /var/run and /var/lock as directories - I guess that's the same problem?
<slangasek> I guess everything one runs in a chroot was consistent enough in its own use of /run vs. /var/run that nobody actually noticed?
<hallyn> yes
<slangasek> so yeah
<slangasek> I think your patch is correct
<slangasek> and probably should get SRUed
<hallyn> so the patch needs further fixing then
<slangasek> ah, because it also needs the /var/run /run swapped
<hallyn> i'm being told it's quittin' time though
<slangasek> :)
<hallyn> right, and /run/lock created
<hallyn> i'll give tha ta shot on monday, but still not convinced i'm smart enough to test it right.
<hallyn> slangasek: thanks.  ttyl
<slangasek> hallyn: have a good weekend
<bdmurray> slangasek: is there any reason not to won't fix bug 1001068?
<ubottu> Launchpad bug 1001068 in devscripts (Ubuntu) "debchange: "quantal" is the default distribution in precise" [Undecided,New] https://launchpad.net/bugs/1001068
<slangasek> bdmurray: hmm
<slangasek> bdmurray: I think we may have gone through this same through situation last cycle
<bdmurray> I'll look for closed bugs then
<slangasek> bdmurray: bug #870618
<ubottu> Launchpad bug 870618 in devscripts (Ubuntu) "debchange: "precise" is the default distribution in oneiric" [Undecided,Fix released] https://launchpad.net/bugs/870618
<slangasek> we decided that it was better to keep $release defaulting to $release for the upload target, for the ppa use case
<slangasek> even though for the distro, 'precise' is no longer a valid upload target
<slangasek> so yeah, I'm gonna do the opposite of wontfixing it :)
<bdmurray> willfix?
<slangasek> yep!
<cjwatson> slangasek: ln ordering> I think of it as directly analogous to cp -l
<cjwatson> (or -s)
<smallfoot-> why isn't AMD64 and AMD64 Mac merged into same image?
<cjwatson> smallfoot-: because it's hard
<smallfoot-> oh
<smallfoot-> whats really the difference?
<cjwatson> we'd like to, but it will take pretty noticeable work
<smallfoot-> oh
<cjwatson> http://askubuntu.com/questions/37999/what-is-different-about-the-mac-iso-image/40480#40480
<smallfoot-> aren't like 99,99% the same?
<smallfoot-> thanks
<cjwatson> Matthew Garrett posted some terrifying instructions on how he's been working on a similar problem in Fedora of late, which will likely form the basis of a solution; however we're using some slightly different tools so it may take a while to port
<smallfoot-> oki
<smallfoot-> guess it wont be done for 12.10 :(
<smallfoot-> im glad the alternative installer is gone
<cjwatson> it is not yet; there is a large dependency to fix first
<chrisccoulson> is there anyone who can bump up the score of https://launchpad.net/~chrisccoulson/+archive/ppa/+build/3500900 ?
<smallfoot-> oh
<cjwatson> chrisccoulson: done
<chrisccoulson> cjwatson, excellent, thanks!
<psusi> cjwatson, the partman port to libparted3? ;)
<cjwatson> psusi: no
#ubuntu-devel 2012-05-19
<psusi> cjwatson, I thought the boot catalog was entirely for el torito bios booting, and that efi systems would boot removable media ( be it cdrom or otherwise ) if they found the EFI directory with the boot loader in it?
<cjwatson> I don't really have much more to say than is in my post there
<cjwatson> you can go and read the efi spec on el torito handling
<cjwatson> it's pretty explicit
<directhex> i suspect reading mjg59's posts on efi booting would be more enlightening
<directhex> and by "englightening" i mean "should make you want to vomit, which is the correct reaction"
<psusi> weird... seems silly to use el torito on cdroms when efi already has a perfectly good way of accomplishing the same goals for other media
<Daviey> Hey, anyone fancy doing a anacron merge review for me please?
<cjwatson> for the specific question psusi asked, the uefi spec alone is enlightening
<psusi> directhex, which posts?
<directhex> anything with "EFI" in it on http://mjg59.dreamwidth.org/, pretty much
<Daviey> slangasek: Fancy reviewing my pending anacron merge (you are TIL). debian -> ubuntu: http://pb.daviey.com/0noa/ & ubuntu -> ubuntu: http://pb.daviey.com/7bmF/ .. thanks :)
<Daviey> (The query is mostly about maintaining the delta of using start vs invoke-rc.d, which i'm not entirely sure why we are doing.)
<smallfoot-> 12.10 will merge /usr ?
<smallfoot-> oh there is a blueprint for it
<slangasek> cjwatson: sure - I just find that calling the arguments "source" and "destination" is needlessly confusing in the case of links
<slangasek> Daviey: ummm.  I'm confused, didn't I already merge anacron?
<slangasek> Daviey: if not, I certainly have a merge staged here
<slangasek> Daviey: do you mind if I just upload this one rather than reviewing yours? :)
<slangasek> (and apols for not uploading it before you did duplicate work on it)
<Daviey> slangasek: ok, i'll happily drop mine :).. But i am interested, why does the original ubuntu delta use start rather thank invoke-rc.d?
<slangasek> Daviey: because someone was misguided when they wrote that bit :)
<Daviey> slangasek: nah, A) i didn't ask before touching it.. B) It was trivial.
<Daviey> slangasek: That makes sense :)..
<slangasek> so I happen to have kept the delta for using 'start' because it's a marginal performance improvement and also less noisy than calling invoke-rc.d
<Daviey> ok.
<Daviey> anyway, before for me.. Have a good weekend campers. o/
<slangasek> but I've pushed the upstart job to the Debian BTS; if that lands I'd be inclined to drop these bits to get us back in sync
<Daviey> s/before/bed
<Daviey> slangasek: super!
<psusi> hrm... mjg says he puts a GPT on along with an MBR that has multiple partitions covering various parts of the disk so that EFI systems that insist on having GPT will be happy, but last I heard, EFI also expressly requires the MBR to only contain the 0xee protective partition or the gpt is considered invalid
<psusi> iirc, a patch went into parted recently to enforce that provision... no ee partition in the mbr, and the gpt is ignored
<cjwatson> Apple have a "special" interpretation of EFI
<cjwatson> there's a rant by mjg59 on the subject in one of Ubuntu's patches to parted
<cjwatson> but briefly: "that would be lovely but Apple don't like to make things that simple"
<psusi> I just finished reading mjg's rant about why tvs suck, and nearly pissed myself when I got to the end: "It's all awful.  I recommend you drink until everything's already blurry and then none of this will matter."
<lazik> psusi : check out refit if you don't know, it's a hybrid MBR/GPT. I use it to triple boot my macbook
<cjwatson> refit isn't a hybrid MBR/GPT - MBR and GPT are partition table formats, not pieces of software
<lazik> ... is a software that creates MBR and GPT and can read both
<psusi> hrm... fedora is now gpt by default?  interesting...
<cjwatson> so's Ubuntu on big enough disks
<lazik> grub2 with efi is being rolled out on many distributions, like ubuntu 12.04+
<psusi> ohh... ubiquity in precise now lets you install grub to a partition
<psusi> I thought we weren't supporting that?
<cjwatson> under protest
<cjwatson> also only to a small selection of partitions
<psusi> hehe
<slangasek> mbiebl: did the 'timeout' option work out for you with post-lucid?
<mbiebl> slangasek: didn't get around to test it yet
<slangasek> ok
<arulmozhi> how cud I compile a linux device driver module. it seems the older examples won't compile on new kernel... my kernel version is 3.2 rev 20... how to include and what are  the  headers required
<arulmozhi> how cud I compile a linux device driver module. it seems the older examples won't compile on new kernel... my kernel version is 3.2 rev 20... how to include and what are  the  headers required
<mr_pouit> tar: Exiting with failure status due to previous errors
<mr_pouit> the chroot on meissa (arm panda) looks broken
<chrisccoulson> hi, is anyone able to bump the score on https://launchpad.net/~chrisccoulson/+archive/ppa/+build/3502198 please? :)
<cjwatson> chrisccoulson: done
<chrisccoulson> cjwatson, thanks!
<jtaylor> why is the as-needed linker flag not in the 12.04 release notes? is one supposed to read 10.10, 11.04, 11.10 and 12.04 release notes before upgrading?
<jtaylor> from 10.04
<cjwatson> jtaylor: hm, I thought it was supposed to have been - I'm sure we talked about it
<cjwatson> (can't look properly now though)
<jtaylor> cjwatson: its not in the gnu toolchain part, I think that is important enough to be mentioned
<jtaylor> just closed two as-needed bugs from 10.04 upgraders
<vibhav> can https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/932439 be nominated for oneiric?
<ubottu> Launchpad bug 932439 in xserver-xorg-input-evdev "Horizontal scrolling reversed recently" [Medium,In progress]
<cousin_luigi> Greetings.
<vibhav> python-django has a ubuntu delta and the control file mentions the svn path to be the one from Debian, should I change it to the bzr vcs?
<cousin_luigi> I'm not sure whether this has been already discussed or not, but why isn't burg an option? Would it be problematic to add support for it in the kernel postinst/postrm scripts?
<vibhav> cousin_luigi: burg an option?
<vibhav> Do you mean installing it by default?
<cousin_luigi> vibhav: making it optional as alternative to grub
<cjwatson> burg is an unmaintained hostile fork of grub
<cjwatson> I do not intend to make any effort to support it; I'd rather continue to improve grub itself
<vibhav> You cannot mkrescue, drivemap.mod is missing (you cannot chainload to other disks)
<cousin_luigi> cjwatson: hostile?
<cjwatson> it was forked by a developer who couldn't get on with the rest of the grub community
<vibhav> Burg is a single person maintainer and while his efforts should be commended
<cjwatson> it hasn't had any commits at all since October 2010
<cousin_luigi> oh
<vibhav> Though I love it
<cjwatson> many of the theming work is now in grub2 anyway in other forms
<cjwatson> just needs some polish and presentation
<cousin_luigi> cjwatson: I see.
<cousin_luigi> cjwatson: By the way, aren't forks usually the result of a battle of egos?;)
<cjwatson> often, yes
<cjwatson> in this case, nobody else joined in ...
<cjwatson> (afaict)
<vibhav> I dont agree
<vibhav> Some people make forks because their patches are not expected
<cousin_luigi> Well, in the spirit of freedom one can fork to prove their point. Granted, it tends to disperse talents.
<vibhav> yeah
<cousin_luigi> bbl
<arulmozhi> again. anybody???  how cud I compile a linux device driver module. it seems the older examples won't compile on new kernel... my kernel version is 3.2 rev 20... how to include and what are  the  headers required
<geser> infinity: is the armel quantal buildd chroot currently broken?
<mr_pouit> geser: there's one broken it seems
<mr_pouit> https://launchpad.net/builders/meissa/+history
<geser> looks like only meissa is affected as all the CHROOTFAIL I checked are from it
<slangasek> ummmm.  Why is rsyslog writing to /var/log/auth.log.1 instead of to /var/log/auth.log?
<slangasek> ah, I blame a chroot
<PaoloRotolo> Hi all!
<mlankhor1t> hey
<rzr> hi i am looking for some entry point to "u for android" project
<infinity> geser: Thanks for the heads-up.  Tidied up the fallout.
<Laney> Looks like rhythmbox can be given back.
<bryceh> Laney, heya
<bryceh> Laney, I think the latest upload failed to build due to I'm guessing the texlive confusion
<Laney> hey bryceh, yeah - just looked like some transient shuffling
 * bryceh visualizes a bum lurching through the archive knocking packages over
#ubuntu-devel 2012-05-20
<penguin42> yes, those broadcasting under managers are dangerous
<broder> Laney: do you still need a give-back on rhythmbox?
<bobweaver> Hello there I am trying to make a ubuntu core installation happen. but for some reason I can not chroot into the mounted /mnt/root I get the error chroot: failed to run command  `/bin/bash': Exec format error. Any ideas what is going on ? Also if this is the wrong channel I am sorry just point me to the correct one thanks a bunch :)
<bobweaver> never mind it is the arch that the host live cd is on sorry to waste your time.
<scientes> whats the name of the privacy control panel?
<scientes> (source)
<scientes> gnome-control-center doesn't seem to have it
<Chauncellor> Hi, I'm trying to develop a lens for Unity via a quickly template - when I try to install/run it (via sudo quickly install and quickly run) I get errors the lens not being provided by any service files: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name unity.singlet.lens.wikipedia was not provided by any .service files
<scientes> (and why does finding out what  programs are in gnome so damn difficult)
<Chauncellor> scientes, activity-log-manager
<Chauncellor> scientes, my bad, not that....
<scientes> i'm just trying to figure out how it does it
<scientes> so i can add similar functionality to my application
<scientes> (well just an opt-out of zeitgeist)
<slangasek> kees: hmm.  does bug #637303 look familiar?
<ubottu> Launchpad bug 637303 in mountall (Ubuntu) "Tries to mount raid element" [Undecided,New] https://launchpad.net/bugs/637303
<finch> Hello folks, I'm working on a puppet provider for network interfaces, and I have some questions about the allow-hotplug stanza. Is that value used these days, or is everything handled via udev for hotplugged network devices?
<vibhav> Can https://bugs.launchpad.net/ubuntu/+source/python-scipy/+bug/655192 be nominated for oneiric?
<ubottu> Launchpad bug 655192 in python-scipy (Ubuntu) "scipy.weave.inline requires python-dev to be installed" [Low,Fix released]
<micahg> vibhav: done
 * vibhav hugs micahg 
<vibhav> The version of python-scipy in oneiric is 0.9.0+dfsg1-1build1 , what should be version for the Ubuntu Delta?
<vibhav> micahg: ^
<micahg> 0.9.0+dfsg1-1ubuntu0.1
<vibhav> remove the build?
<micahg> yes
<vibhav>  can
<vibhav> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/932439
<ubottu> Launchpad bug 932439 in xserver-xorg-input-evdev "Horizontal scrolling reversed recently" [Medium,In progress]
<vibhav>                 be nominated for oneiric?
<micahg> Daviey: prettytable is trying to pull python-support back into main
<Laney> broder: looks like it
<Daviey> micahg: nah it aint.
<micahg> Daviey: sure, with your upload :)
<Laney> or one of you two could do it for me
<Laney> ubuntu-build rhythmbox quantal retry
<Laney> ^o)
<Daviey> micahg: I think you are mistaken :)
<micahg> Daviey: I meant that your new upload just fixed it
<Daviey> Laney: given back
<Laney> cheers boss
<vibhav> Can https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-input-evdev/+bug/932439 be nominated for oneiric?
<ubottu> Launchpad bug 932439 in xserver-xorg-input-evdev "Horizontal scrolling reversed recently" [Medium,In progress]
<jtaylor> vibhav: please prepare 655192 according to https://wiki.ubuntu.com/StableReleaseUpdates first please
<vibhav> jtaylor: What is wrong in the debdiff I provided?
<vibhav> 655192 according to https://wiki.ubuntu.com/StableReleaseUpdates first  please
<jtaylor> the debdiff is fine, but the bug description updated a bit
<vibhav> like?
<jtaylor> https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<vibhav> Oh wait
<Daviey> *sigh* http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673618 .. it's already using dh_python3 .. but refusing to use dh_python2.
<ubottu> Debian bug 673618 in prettytable "prettytable: Please consider converting to dh_python2" [Normal,Open]
<Laney> what debdiff?
<jtaylor> Daviey: this is to be expected from morph, never mention you're related to ubuntu to him :)
<micahg> Daviey: not mostly, actually deprecated: http://article.gmane.org/gmane.linux.debian.devel.python/6948
 * Laney fails at voting in the diversity GR
<Daviey> jtaylor: he took the python3 patch from us. *sigh*
<Laney> perhaps some other member of DPMT could broker a deal
<jtaylor> unlikely
 * Daviey replies
<Laney> is there some kind of team policy around switching from python-support for example?
<jtaylor> other dpmt members also refuse dh_python2 patches
<vibhav> jtaylor: Not sure what to put in the [Regression Potential] section
<jtaylor> vibhav: e.g. low, just adds dependencies
<vibhav> jtaylor: done
 * micahg would think it should be escalated if the team is being obstructionist
<jtaylor> its no release goal in debian to remove pysupport
<jtaylor> the python team is not very ubuntu friendly in the first place mainly to how python maintenance is done, I would advise against pouring oil into the fire
<vibhav> jtaylor: Is the bug description fine?
<jtaylor> just patch it in ubuntu and wait
<micahg> yeah, I guess it's not a release goal for wheezy
<micahg> maybe for wheezy + 1
<micahg> we're still ~700 packages away from being done anyways: http://people.canonical.com/~ubuntu-archive/transitions/dh-python2.html
<jtaylor> vibhav: you should also mention why -imaging is added
<vibhav> jtaylor: Why did you add -imaging to the recommends?
<jtaylor> vibhav: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=648036
<ubottu> Debian bug 648036 in python-scipy "python-scipy: imread in scipy doesn't work" [Important,Fixed]
<vibhav> jtaylor: jtaylor Done
<vibhav> oops
<jtaylor> the latest fftw3 update in unstable pulls in openmpi, that would need patching out in ubuntu?
<jtaylor> as its in main
<jtaylor> vibhav: looks ok I'll check it later
<vibhav> thanks
<jtaylor> *upload
<Bluefoxicy> it looks to me like Ubuntu doesn't recognize SSD, and thus doesn't put 'discard' into the fs options for SSD partitions
<broder> Bluefoxicy: you can set the discard option regardless of whether or not there's an ssd involved - it'll gracefully fallback to a noop if the device doesn't support it, but we're following upstream's decision to leave it "by default until sufficient testing has been done"
<Bluefoxicy> broder ah
<Bluefoxicy> broder:  what about setting deadline scheduler on SSD?
<broder> don't know anything about that
<Bluefoxicy> it's supposedly faster than CFQ
<Bluefoxicy> basically noop is just FIFO, deadline will try to get reads scheduled before writes, and CFQ will try to be fair and account for how close sectors are to each other so as to reduce seek time
<ion> [citation needed] (not sarcastically, iâm interested sincerely)
<Bluefoxicy> of course there's no seek time on an SSD
<Bluefoxicy> http://ubuntuforums.org/showthread.php?t=1464706
<ion> Thanks
<Bluefoxicy> you can set these through /sys/block/[device]/queue/scheduler
<Bluefoxicy> I'm using CFQ on my hard drive and Deadline on my SSD right now
<Bluefoxicy> forum post of course says set it on the kernel command line, but that's system-wide default
<Bluefoxicy> something like maybe
<Bluefoxicy> check_trim() {
<Bluefoxicy>         sudo hdparm -I "$1" | grep -q "Data Set Management TRIM supported" && return 0
<Bluefoxicy>         return 1
<Bluefoxicy> }
<Bluefoxicy> check_trim /dev/sda && echo deadline >/sys/block/sda/queue/scheduler
<Bluefoxicy> and so on
<Bluefoxicy> but with something to read /etc/fstab, build an array of all the block devices with partitions to mount, and then loop through them
<broder> if you were going to do that, i'd look more directly at /sys/block/sda/queue/rotational
<Bluefoxicy> nice :)
<broder> but basically, i think ubuntu is fairly unlikely to pick something like that up without upstream kernel buy-in
<Bluefoxicy> I don't think the kernel will ever auto-deadline
<broder> you could imagine it auto-nooping for non-rotational disks
<Bluefoxicy> on the one hand you might say, since the kernel can see it's non-rotational maybe it should stop taking a "Default Scheduler" approach and instead implement a smart policy that applies deadline to non-rotational media and CFQ to rotational media
<Bluefoxicy> but this argument has already come and gone
<Bluefoxicy> the kernel developers--Linus especially--do not support policy in kernel
<broder> hmm, fair
<broder> ok, i guess you could take it to upstream udev
<Bluefoxicy> This happened with grsecurity/PaX etc
<Bluefoxicy> yeah udev makes sense
<Bluefoxicy> in fact udev makes a lot of sense
 * Bluefoxicy checks to see if his cell phone shows up as non-rotational media
<Bluefoxicy> odd, it does.  (it's an SD card)
<penguin42> why do you say odd?
<Bluefoxicy> sorry, it shows up as a spinning disk
<Bluefoxicy> ~# cat /sys/block/sdc/queue/rotational
<Bluefoxicy> 1
<penguin42> ah yeh, that's odd
<broder> usb doesn't expose the rotational flag
<Bluefoxicy> yeah
<Bluefoxicy> i was gonna say, this would be useful for things like USB flash drives too, except it's ... not.
<geser> do you get a 0 for any block device? I get only ones for "cat /sys/block/*/queue/rotational"
<Bluefoxicy> geser:  I have an SSD
<Bluefoxicy> / is on SSD, /home/_vm/ is on SSD (I tried putting it in /var/vm/ and Ubuntu decided to delete its contents during installation, so screw that), /home/ is a spinning disk system
<geser> I get 1 for even /sys/block/ram0/queue/rotational (isn't this from a tmpfs mount?)
<Bluefoxicy> heh
<Bluefoxicy> this is a mess :P
<Bluefoxicy> Chromium is so friggin' awesome
<Bluefoxicy>  2806 bluefox   20   0 1708m 690m  34m S    5  8.8 599:21.25 chromium-browse
<Bluefoxicy>  
<Bluefoxicy> 690MB!?
<Bluefoxicy> 2806	Plug-in Shockwave Flash
<penguin42> Bluefoxicy: Can you see it in the developer tools , it has some profiles/heap snapshotting etc
<Bluefoxicy> penguin42:  ???
<Bluefoxicy> penguin42:  I pulled up the memory stats and Chromium informed me that the huge 700 meg process was just the Flash plug-in doing nothing.
<penguin42> Bluefoxicy: chromium's tools menu has a task manager and developer tools option, it shows you which tab is using what memory (to some degree)
<Bluefoxicy> the next biggest process is the browser itself at 230MB, and then the biggest actual tab eats about 55MB
<Bluefoxicy> so ... Flash is a ridiculous memory hog.
 * vibhav hugs jtaylor 
<melodie> hi
<melodie> is it possible to ask a pair of questions about the topic "LiveCDCustomizationFromScratch" please ?
<melodie> the link is : https://help.ubuntu.com/community/LiveCDCustomizationFromScratch
<melodie> is it ok to ask here ?
<JanC> I suppose it's okay to ask (depending on the exact question, there might be better places to ask, but people can point you there then)
<melodie> I would like to know if the part mentioning "There is a problem with 10.04 upstart package not containing /sbin/initctl.distrib ... " is still valid for Precise ? and if no one here knows, where could I ask ?
<melodie> hi JanC
<melodie> and in fact I don't understand at all this part, it lacks information
<melodie> and what does "sudo chroot chroot" mean ? Never seen chrooting that way before : is it the right command, or maybe, some mistake ?
<melodie> thanks for all pointers. :)
<penguin42> I think the second one is the directory of your chroot - ie. sudo chroot /whereever/you/put/yourchroot
<melodie> penguin42, I get it. I thank you !
<JanC> melodie: upstart-specific questions can also be asked in #upstart (but not so many people are active there) or on the upstart mailing list
<melodie> ahem... what does "upstart" mean ?
<melodie> I am there and I see a few persons
<JanC> upstart is the init system used in Ubuntu, basically the first program started by the kernel that then starts all other programs needed by the OS
<JanC> https://en.wikipedia.org/wiki/Init
<melodie> JanC, thank you very much !*
<JanC> I don't know what that specific issue is/was about, BTW, or whether it's fixed now
<melodie> JanC, ok thanks
<melodie> I am reading the page of the bug report. It more or less looks like an egg and hen problem
<melodie> cool the comment #44 is to say the chroot pb is solved ! I'll fetch someone to update the howto maybe ? I read the rest just in case
<JanC> melodie: it's a wiki?  ;)
<JanC> (although maybe the help part is locked, not sure?)
<melodie> JanC, I don't know yet but I will try to discover, and if needed will visit #ubuntu-doc (if it still exists of course)
<melodie> JanC, are we are being cooking now, I'll first finish to read that page to make sure the bug fix is effective, then I will look further. anyhow, thanks for your support !
<JanC> melodie: you can log in using your Ubuntu SSO account (the same account/password as used by UbuntuOne & Launchpad)
<melodie> JanC, ok
<melodie> I meant, I'll have to look at the rest a little later. :)
<JanC> yes, and "smakelijk" / "bon appÃ©tit" / "Mahlzeit" / "enjoy your meal" or whatever they say in your country...  ;)
<melodie> JanC, merci ! bon appÃ©tit aussi ! smakelijk too !
<melodie> bbl
<JanC> :) I ate a couple of hours ago  ;)
<malkauns> any X11 experts here?  How do i programatically create a new virtual X display?
<malkauns> like NX
<mlankhor1t> malkauns: things like Xnest/ephyr?
<malkauns> mlankhor1t, what's that?
<malkauns> nested X server?
<mlankhor1t> apt-cache show xserver-xephyr / xnest
#ubuntu-devel 2013-05-13
<Logan_> wgrant: Are you around?
<Logan_> Or lifeless?
<wgrant> Logan_: Hi
<Logan_> wgrant: Hey! Would you mind doing $ requeue_package.py --full openafs # ?
<wgrant> Logan_: Do you know why the tags changed?
<Logan_> No idea, honestly - someone must've done a push --overwrite during the Precise cycle or something. The trace makes it seem like a Debian tag issue, though.
<pitti_> Good morning
<bkerensa> pitti_: top of the morning to you
<pitti> doko_, cjwatson_: I wondered whether Debian's glib2.0 could now build-dep on python:any (our only delta); is that a question of apt, dpkg, wanna-build, python-defaults, or something else?
<bkerensa> pitti: ping
<pitti> bkerensa: hello
<bkerensa> pitti: May I PM?
<pitti> sure :)
<bkerensa> :D
<dholbach> good morning
<jibel> cjwatson_, I get bug 1179202 with latest openssh on saucy, could you have a look?
<ubottu> bug 1179202 in openssh (Ubuntu) "fails to login with error fatal: monitor_read: unsupported request: 144" [Critical,Confirmed] https://launchpad.net/bugs/1179202
<jodh> @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: jodh
<jodh> jibel: could you add a comment to lp:~jamesodhunt/ubuntu/raring/sbuild/dep8-procenv if you are happy with the changes I made? (Nothing seems to be happening on the Debian side yet).
<jibel> jodh, sure, I'll review the changes.
<jodh> jibel: thanks!
<pitti> slangasek, stgraber: I sent a mail to u-devel@ about testing the new udev (I now ported all our patches and packaging), as well as whether to move to the new net iface naming schema
<doko_> pitti, afaik, debian can't do that yet
<pitti> doko_: good morning
<pitti> doko_: do you know what part in particular handles that? sbuild's/wanna-build's build dep parsers?
<geser> does somebody know if it's intended to have/keep "fglrx-legacy-driver" in multiverse? (it got synced from non-free into saucy)
<tjaalton> geser: no
<tjaalton> most likely won't work on ubuntu, or will break things
<geser> tjaalton: so it should get removed from the archive again?
<tjaalton> yes, and blacklisted
<tjaalton> again?
<geser> ok, will file a remove bug for it then
<mardy> seb128: hi :-) Do you know if there is a Google calendar for the UDS?
<seb128> mardy, hey
<seb128> not that I know :-(
<seb128> mardy, http://summit.ubuntu.com/uds-1305/2013-05-15/display has a feed and a mobile version
<seb128> not sure if you can make the mobile version send you reminders
<mardy> seb128: oh, it works. In Google calendar, under "Other calendars", one can add a URL of an ical feed
<seb128> mardy, good to know, thanks ;-)
<soren> Holy crap, developers in India are cheap. I knew they were cheap, but not this cheap. They seem to average around USD 7500. A year.
<soren> Wow.
<soren> Wrong channel :)
<mlankhorst> 16 roof painters won't make a mondrian, though :P
<soren> I don't know, man. I know a lot of very good Indian devs. It seems disproportionate.
<cjwatson_> mitya57: proposed-migration only cares about regressions in the set of architectures with successful builds; it doesn't care about whether there are build failures on architectures that were never built before
<cjwatson_> pitti: I'm pretty sure there are still wanna-build/sbuild issues we need to fix before you can upload that to Debian.
<cjwatson_> jibel: ok
<mitya57> cjwatson_: thanks for responding! that's what I thought, yes
<yossarianuk> hi - I have an existing ppa - https://launchpad.net/~morgancoxuk - I am on a new desktop though and didn;t copy my GPG key over
<yossarianuk> i.e 6BDD7F66
<yossarianuk> do I have to create a new GPG key or can I just copy the existing one from the PPA sire / ubuntu keyserver some how?
<yossarianuk> i.e - if I go to  http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x711A47FD6BDD7F66
<yossarianuk> I can see the key - how can I use that key
<mitya57> yossarianuk: ubuntu keyserver only has your public key (not private), so you'll need to generate a new one
<yossarianuk> mitya57: thanks
<tkamppeter> Who is responsible for the UDS schedules, two of my sessions were put at the same time.
<Laney> talk to the track lead(s)
<yossarianuk> mitya57: Yes I guess it was silly question... (if anyone can get my key the security is broken...)
<yossarianuk> Just so I know for next time I migrate - where afre the key files kept?  is it just ~/.gpg ?
<StevenK> yossarianuk: ~/.gnupg
<StevenK> That always trips me up, I look for .gpg first
<seb128> tkamppeter, hey, what sessions?
<tkamppeter> Sorry, I see that it got already corrected. Thanks.
<seb128> yw
<mitya57> cjwatson: in bug 537998, we only want to localize two strings that are coming from https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/memtest86+/saucy/view/head:/debian/grub, right?
<ubottu> bug 537998 in memtest86+ (Ubuntu) "Boot screen is localized only partially" [Undecided,Triaged] https://launchpad.net/bugs/537998
<yossarianuk> StevenK: cheers !
<yossarianuk> btw the whole reason i'm creating packages is to get the latest nvidia driver
<yossarianuk> I wish Ubuntu just worked easily with the Nvidia bin file...
<cjwatson> mitya57: which are fundamentally unlocalisable right now
<yossarianuk> the 313 drivers are now out of date....
<cjwatson> mitya57: (yes)
<yossarianuk> xorg-edgers upgrades far to much (i.e kernel, xorg, etc..)
<mitya57> cjwatson: why fundamentally? we can create a gettext template (right inside debian/), allow rosetta to accept translations for it, and then use gettext(1) in that script
<cjwatson> mitya57: It needs to be localised at boot time, not when that script runs
<mitya57> cjwatson: why?
<cjwatson> Hmm, I swear menu entry strings used to be localised at boot time
<cjwatson> Maybe they aren't any more
<mitya57> (I know that different users can have different locales, but that's a rare corner-case)
<cjwatson> Possibly TEXTDOMAIN=memtest86+ gettext_printf blah would do then
<cjwatson> (Do use grub-mkconfig_lib's helpers rather than bare gettext
<cjwatson> )
<mitya57> $ which gettext_printf
<mitya57> $
<cjwatson> view /usr/share/grub/grub-mkconfig_lib
<cjwatson> which /etc/grub.d/20_memtest86+ already sources, albeit via a deprecated symlink
<mitya57> ok, I'll now try to implement that (and fix the symlink)
<cjwatson> compare with other current grub.d scripts
<cjwatson> the symlink isn't a major problem or anything, just mentioned it in case you were confused
<cjwatson> thanks :)
<mitya57> can /usr/lib/grub/grub-mkconfig_lib also be replaced with /usr/share/grub/grub-mkconfig_lib?
<mitya57> oops
<cjwatson> Don't replace anything - probably better to extend the conditional
<mitya57> I meant /usr/lib/grub/update-grub_lib
<mitya57> ok
<cjwatson> They're all various incarnations of the same thing, but it would be a hassle to have to have tight dependencies there
<cjwatson> However let's check when gettext_printf was introduced relative to those changes
<cjwatson> 2010-12-21 upstream, so 1.99
<mitya57> that was a long time before precise, so I don't think we should care about that...
<cjwatson> grub-mkconfig_lib was moved to /usr/share/grub in 2012-01-24
<cjwatson> The switch from update-grub_lib to grub-mkconfig_lib was 2008-09-29
<cjwatson> So I think you can drop update-grub_lib now and update any relevant dependencies/breaks/whatever to 1.99; but keep the check for /usr/lib/grub/grub-mkconfig_lib
<cjwatson> Looks like there aren't any relevant deps, it just uses whatever it can find
<cjwatson> Breaks: grub-common (<< 1.99) mightn't be terrible
<mitya57> ok
 * mitya57 's xgettext doesn't understand '[type: gettext/rfc822deb]' in POTFILES.in, weird
<cjwatson> Isn't that an intltool-debian thing?
<mitya57> right, I never used that before... :)
<mitya57> cjwatson: if I do "msgfmt debian/po/{}.po -o debian/memtest86+/usr/share/locale/{}/LC_MESSAGES/memtest86.mo" in build target, will it be correctly picked by dh_translations?
<mitya57> (using xargs)
<cjwatson> mitya57: I'm afraid you probably know dh_translations as well as I do
<mitya57> AFAIR removing .mo files happens after install step, so it should work
<cjwatson> Perhaps you mean pkgstriptranslations rather than dh_translations?
<cjwatson> Which happens in a dpkg-deb diversion, so at dh_builddeb time
<mitya57> yes, thanks
<cjwatson> wookey: mind if I merge libsepol from Debian?  you're touched-it-last in Ubuntu
<cjwatson> wookey: ditto zlib
<wookey> cjwatson: sure - just try not to lose the fixes if they've not propogated to debian yet
<cjwatson> wookey: that's within my meaning of "merge", yes :)
<cjwatson> thanks
<wookey> indeed. I realise I am teaching egg-sucking here. I wondered why you even asked  :-)
<cjwatson> wookey: Because the rule for merging from Debian is that you check with the previous uploader first, to avoid duplicate work
<cjwatson> And I should practice what I preach
<wookey> OK. in case they have other stuff pending, or were about to do it themselves?
<cjwatson> Either
<cjwatson> Or in case it's delicate somehow
<wookey> OK. noted for future use.
<jodh> @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:
<mitya57> working!
<mitya57> ### BEGIN /etc/grub.d/20_memtest86+ ###
<mitya57> menuentry 'ÐÐ¸Ð°Ð³Ð½Ð¾ÑÑÐ¸ÐºÐ° Ð¿Ð°Ð¼ÑÑÐ¸ (memtest86+)' {
<cjwatson> mitya57: well done
 * mitya57 is trying to make the template updating automatically, not manually
<mitya57> intltool-extract doesn't support .sh files, so that doesn't seem to be possible
<hallyn> hi - is the import from lp:ubuntu/raring/* into lp:ubuntu/saucy/* still on-going?
<hallyn> bzr branch ubuntu:lxc is still failing...
<apw> cjwatson, hey, i see you did some work on openssh, specifically on monitor_read stuff; i am seeing incoming interactive logins to saucy dropping immediatly with 'monitor_read: unsupported request: 144' -- seen anything like that in your testing ?
<cjwatson> apw: already fixed in unstable, fix will auto-sync tonight
<cjwatson> apw: bug 1179202
<ubottu> bug 1179202 in openssh (Ubuntu) "fails to login with error fatal: monitor_read: unsupported request: 144" [Critical,In progress] https://launchpad.net/bugs/1179202
<apw> cjwatson, ahh thanks
<hallyn> wgrant: ^  is the bzr import into lp:ubuntu/saucy done?
<wgrant> hallyn: package-import has caught up with both saucy and jessie, yeah
<hallyn> wgrant: drat.  ubuntu:lxc is still not right
<wgrant> hallyn: No, it's broken
<wgrant> http://package-import.ubuntu.com/status/lxc.html
<wgrant> package-import sees it as corrupt, but it works OK for me
<wgrant> I haven't had time to investigate properly
<smoser`> xnox, around ?
<hallyn> wgrant: ok, thanks
<stgraber> wgrant: I've been running manual import-dsc against ubuntu:lxc in the past after the importer apparently gave up on the branch, not sure whether that made it any worse
<stgraber> oh, I see, it's even more broken now than it used to be (can't even pull from it)
<wgrant> stgraber: Yeah, except that I can branch the branch fine :/
<wgrant> I might have time to poke harder at it late this week, but if someone else wants to have a look..
<apw> pitti, i just tried out your udevd-202, seems to work on a UEFI machine here; boots fine and sees USB sticks and the like
<pitti> apw: thank you!
<smoser> anyone want to venture a guess here:
<smoser> https://bugs.launchpad.net/ubuntu/+bug/1179513
<ubottu> Launchpad bug 1179513 in Ubuntu "attempt to ssh results in "closed by remote host"" [Critical,Confirmed]
<smoser> in the cloud images (at least, possibly elsewhere) on saucy i cannot ssh in
<smoser> well, cannot get a pty/console. I can ssh in only by giving giving commands to run
<pitti> smoser: duplicate of bug 1179202
<ubottu> bug 1179202 in openssh (Ubuntu) "fails to login with error fatal: monitor_read: unsupported request: 144" [Critical,In progress] https://launchpad.net/bugs/1179202
<pitti> will be fixed in a few hours
<apw> smoser, do you see a 'monitor_read: unsupported request: 144' in /var/log/auth.log on the other end, if so, what pitti said
<pitti> I get that with today's cloud images
<smoser> apw, yes, seeing that.
<smoser> pitti, apw thank you. pitti, you use cloud images?
<pitti> smoser: yes, with jibel's run-adt-test script
<pitti> in fact, I'm just using them for "give me a throwaway VM really fast in tmpfs" :)
<pitti> (doing NetworkManager testing, and I manage to screw it up quite often)
<smoser> i iddn't know about run-adt-test. neat.
<smoser> pitti, you use via kvm ? (for the tmpfs case)
<pitti> http://developer.ubuntu.com/packaging/html/auto-pkg-test.html
<pitti> smoser: yes, that creates a kvm based on the cloud image with an overlay qcowfs in tmpfs
<pitti> IOW, "run-adt-test -sl" -> shell in a pristine saucy environment
<pitti> same with -r raring -> raring VM, etc.
<pitti> and as I have apt-cacher-ng, installing a bunch of packages is literally done in two seconds
<smoser> pitti, nice.
<smoser> i've recently been using libeatmydata for everything like that.
<smoser> (and patching apt to always call eatmydata on itself)
<smoser> and also if you do 'cache=unsafe' in kvm, performance is really good.
<smoser> just mentioning those things as they may get you to closer to tmpfs performance without explicitly using memory.
<smoser> jibel, around?
<smoser> jibel, well, when you see this, i'd really like to talk to you some about simplestreams, which i hope can provide a way for http://bazaar.launchpad.net/~auto-package-testing-dev/auto-package-testing/trunk/view/head:/bin/prepare-testbed to download/sync images more easily
<smoser> hm.. i never thought to EATMYDATA kvm
<smoser> interesting.
<tedg> jdstrand_, Okay, I unwrapped the GIO stuff there a bit (not as much error handling) but the upstart app branch should be happier now.
<jdstrand_> tedg: cool, thanks! :)
<ogra_> cjwatson, are you replacing slangasek while he is sick ? i have two specs in the foundations realm that need approval and scheduling
<SpamapS> so, does anybody even triage bugs for compiz?
<SpamapS> https://bugs.launchpad.net/ubuntu/+source/compiz/+bugs?search=Search&field.status=New
<SpamapS> 524 New
<cjwatson> ogra_: yes
<cjwatson> (if I can remember how)
<ogra_> cjwatson, https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-non-interactive-touch-boot and https://blueprints.launchpad.net/ubuntu/+spec/foundations-1305-android-builds-revisited
<cjwatson> ogra_: OK, poked on LP, let's see if/when they show up in summit
<ogra_> thx
<cjwatson> cjohnston: Is there a guide somewhere for how to run a vUDS track?
 * cjwatson finds http://summit.readthedocs.org/en/latest/ and hopes it's up to date
<cjwatson> Hm, not entirely convinced
<cjohnston> cjwatson: that has everything except the hangout stuff
<cjohnston> mhall119_: sent out instructions last time on the hangout stuff. I don't know, but I would assume that is planned again
<mpt> cyphermox, are Bluetooth PINs always four digits?
<cyphermox> no, they could be longer
<mpt> "Any 16-byte UTF-8 string may be used as a PIN code; however, not all devices may be capable of entering all possible PIN codes."
 * mpt should have Googled first
<mpt> PIN: ðððð±
<cyphermox> hehe
<mlankhorst> mpt: but you can have 1 UTF-8 character that's 6 bytes in length, limiting you to 2 characters :>
<cjwatson> cjohnston,mhall119: I have two more foundations sessions to schedule, and no free slots.  Would it be best to steal slots from another track (appdev seems to have quite a few free)?
<cjohnston> cjwatson: you can ask the appdev track leads if you can have a slot or two.
<cjwatson> popey,dpm,mhall119: ^-
<dpm> cjwatson, I think you can use some of ours, yes. Otherwise if that is not enough perhaps we might want a second room for Foundations
<dpm> cjohnston, ^
<cjohnston> dpm: I think that would prolly be jono's call
<cjohnston> initially the one foundations room was added because client was too big
<jono> just add them to appdev
<mhall119> cjwatson: how many sessions?  I have a handful more to add today for appdev
<cjwatson> mhall119: two at the moment
<cjwatson> hoping that'll be it - it's a bit late to be adding things anyway
<tedg> jodh, On the instance interface in upstart the processes are a(si).  What is that string for?
<mhall119> cjwatson: that should be fine then
<seb128> cjwatson, mhall119: desktop is not full either and can probably host a few extra ones if needed
<mhall119> seb128: you mean client?
<seb128> mhall119, safe difference :p
<seb128> same*
 * cjwatson finds https://wiki.ubuntu.com/UDS/Sessions re how to do the hangout stuff
<slangasek> @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: slangasek
<balachmar> I am having a problem installing 13.04 on my system. The upgrade failed, but the installer is giving me problems as well. It boots and then when you should be able to select the installation type it stays empty: https://owncloud.wligtenberg.nl/public.php?service=files&t=3de9d7b808a91cfc69d0b6e159216be2
<balachmar>   And whenever I click on the change or (+/-) it crashes...
<balachmar> My old system, which is broken by the upgrade still boots. But I cannot perform a dist-upgrade because of some dbus error...
<ScottK> bdmurray: How would phased updates work in a case where I've got a new KDE SC upstream release with several dozens of packages that have been tested as a set and should hit a user's system at ~the same time?
<bdmurray> ScottK: that's a good question and something we haven't explicitly thought about.
<sarnold> ScottK: in your example, would you have versioned dependencies in place to force an all-or-nothing upgrade?
<sarnold> (just for my own curiosity..)
<dobey> hrmm, what does "[] Willing to be Crew" even mean for vUDS? :)
<dobey> balachmar: #ubuntu is the help channel
* wright.freenode.net 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:
<balachmar> @dobey yeah I found that out later, I thought this was technical enough...
<udevbot> Error: "dobey" is not a valid command.
<balachmar> dobey: yeah I found that out later, I thought this was technical enough...
<Daviey> stgraber: For reference mongodb is keen to allow us (and derivatives) to link against openssl and is actively working on a declared exception.  *They* questioned why it required extra work, as they assumed it was a system library.
<stgraber> Daviey: ah, ok, thanks for the update. I haven't rechecked the bug report in the past week or so, good to see it going in the right direction.
<Daviey> stgraber: That upstream bug report seems to be simply poor triaging
<kees> stgraber: hm, do you think /etc/init/container-detect.conf (and console.conf) should detect KVM as a container? Nice to have a serial console Just Work under KVM...
<stgraber> kees: it definitely shouldn't detect kvm as a container or it'll do very very bad things to it (like not install grub), but yeah, having an extra console job which does the right check for kvm either through a udev start on pattern or through pre-start would be nice
<stgraber> I think there's a tty-device-added or something similar that's emitted in upstart at boot time for console devices, so with the right starton pattern it should be possible to DTRT for kvm serial console
<sarnold> what does grub get you in a container?
<stgraber> sarnold: nothing, that's why we have a check in the grub scripts to turn them into no-op when in a container
<sarnold> stgraber: then not having grub doesn't sound so horrible?
<stgraber> we technically support running a full Ubuntu system (think desktop squashfs) in a LXC container without modification, so it's possible (and happens often) that you have grub and a kernel installed in the container, even though they're completely useless
<stgraber> the default container you get with lxc-create doesn't contain grub+kernel but things like the images used by the QA team do and so do the cloud images
<infinity> sarnold: I think his point was that if you detect KVM as a container, you won't get a functional grub in your kvm VM.
<stgraber> right
<infinity> Anyhow, some better way to automatically set up serial consoles has been a long-time wishlist of a lot of people.
<infinity> It's a point of contention on devices where you might still be using serial ports for weird things like, I dunno, talking to serial devices.
<infinity> (But if udev has some sort of event for "the kernel ran a console on this tty already", then that would be perfect)
<stgraber> yeah, jodh tried to build a generic job a while back, which worked pretty well except for all the cases where you want to use your serial port to talk to serial devices
<sarnold> infinity: wow. somehow I misread KVM -> LXC. thanks for fixing my reading. hehe. :)
<stgraber> I think we can pretty easily deal with the stndard /dev/tty[123456] and get down to just one multi-instance job dealing with them, hypervisor consoles should also be detectable, it gets tricky when you're talking about ttySX and ttyUSBX where you're never quite sure what you want on those
<infinity> stgraber: I could probably come up with some sick pathological case of using an hvc* serial port for something other than a console, but that's probably approaching "you get to keep both pieces" territory.
<infinity> stgraber: As for ttyS* (and friends), I've long been of the opinion that if you have console=/dev/ttyS32 on your kernel command-line, that's probably what you want for userspace too (and you can effin' kill the getty yourself if it's not what you wanted)
<stgraber> infinity: indeed, parsing /proc/cmdline and starting a getty on what console= points to should be safe and we should definitely do that
<kees> stgraber, infinity: yeah, I like this idea.
<kees> the thing is, I think the existing console.conf is correct already.
<kees> hm
<kees> actually... is there a way to detect if /dev/console != /dev/tty1 ?
<kees> because always starting a console on /dev/console seems like a sensible idea.
<lifeless> +1 on getty on your cmdline console
<stgraber> kees: I think it'd be more reliable to have upstart parse the console= argument if only because it'll need to get the bitrate and other stuff from there anyway. Then move upstart to have a single "getty.conf" job which uses instances (taking PATH, BAUDRATE as variables), then have that job triggered by another job or by a starton condition
<stgraber> the advantage being that upstart instances will prevent ever starting a getty twice on the same device
<lifeless> barry: hey
<barry> lifeless: hey
<lifeless> barry: so, image based updates - I'm going to be online for the session I think; but I wanted to ask - have you looked at e.g. lmirror for the updates ?
<lifeless> barry: it's got a bunch of properties that seem to match the stuff you wanted according to the wiki page
<barry> lifeless: i have not
<barry> stgraber: ^^
<lifeless> barry: including HTTP streaming, signed updates, sliding windows of history and so forth.
<barry> lifeless: https://launchpad.net/lmirror
<lifeless> it's probably not an exact fit, but I'd be delighted to have it's design tweaked to fit, if conceptually it fits.
<lifeless> barry: yeah
<barry> lifeless: is there more documentation on it available?
<barry> lifeless: or should i just grab the code and poke around?
<kees> stgraber: hm, yeah
<lifeless> barry: http://bazaar.launchpad.net/~lmirror/lmirror/trunk/files/head:/doc/
<lifeless> barry: http://bazaar.launchpad.net/~lmirror/lmirror/trunk/view/head:/doc/MANUAL.txt
<barry> lifeless: cool.  it's dinner time here, but i'll take a look either later tonight or in the morning
<lifeless> barry: kk
<barry> lifeless: thanks.  /me -> dinner
<stgraber> barry, lifeless: bookmarked, will try to read through the doc/ a bit later
#ubuntu-devel 2013-05-14
<ScottK> sarnold: No always.
<slangasek> stgraber: hey, could you please commit your changes from casper 1.332?  (Since there's a documented Vcs-Bzr field, and the importer is balking)
<stgraber> slangasek: hmm, I don't have those commits around anymore. Anyway, I just updated the packaging branch with a manual import of 1.332 so the content and the tags should be fine now.
<slangasek> stgraber: ok, thanks
<pitti> Good morning
<lifeless> morning pitti
<pitti> smoser: ah, today's cloud images work again (ssh)
<dholbach> good morning
<alkisg> LTS desktop packages are supposedly supported for 3y, and server packages for 5y. But that doesn't match what `apt-cache show package | grep Supported` says:
<alkisg> dpkg -l | awk '/^ii/ { print $2 }' | xargs apt-cache show | grep ^Supported | sort -u
<alkisg> Supported: 18m
<alkisg> Supported: 5y
<alkisg> ==> no "3y" anywhere there, although many packages don't have a "Supported" line in their control file. How can I see for how long a package is supported?
<StevenK> alkisg: That changed with Precise, everything is 5y
<alkisg> Thank you StevenK, and I assume the packages that are supported for 18m is just minor bugs...
<StevenK> I'm not certain of the rules
<StevenK> I just know that desktop stopped being 3 years and started being 5.
<alkisg> Thanks, it answers my concerns, the 18m packages are too few to bother with anyway :)
<alkisg> Maybe they are part of flavors that were not LTS, e.g. lubuntu maintained packages etc
<tjaalton> who's maintaining the vuds scheduling?
<seb128> tjaalton, nobody
<seb128> tjaalton, track leads and some others have edit access
<seb128> tjaalton, but I don't think there is one person responsive for the schedule
<seb128> tjaalton, would be easier it you asked what you really want to know ;-)
<pitti> tjaalton: for changes, poke one of the track leads
<tjaalton> seb128: the hybrid session got dropped from the schedule since it was mistakenly marked as superseded
<tjaalton> pitti: thanks, who is the track lead?
<seb128> tjaalton, I can schedule things
<tjaalton> seb128: oh, cool. well could we have the first slot tomorrow?
<tjaalton> it was originally today at 1800UTC but it was bad for me & tseliot
<seb128> no
<seb128> http://summit.ubuntu.com/uds-1305/2013-05-15/display
<seb128> there is no slot left at this time
<seb128> would thursday 15utc in client 2 works for you?
<tjaalton> nope :/
<tjaalton> oh well, put it back where it was, today 1805-1900
<seb128> tkamppeter, hey, would it be ok if the oprint dialog design session is moved from tomorrow 2pm to thursday 3pm?
<tjaalton> is it ok to lead the session without video? :)
<seb128> tjaalton, ^ if that works for Till I can put yours there, otherwise let's do today 18h
<seb128> tjaalton, yeah, audio is fine
<tjaalton> seb128: yeah that would be fine
<tjaalton> no, great
<pitti> jibel: FTR, run-adt-test -sl works again for saucy, so it really was the openssh issue
<tkamppeter> seb128, no problem.
<seb128> tkamppeter, thanks
<seb128> tjaalton, hybrid is on schedule for tomorrow 2pm utc
<tjaalton> tkamppeter, seb128: woohoo, thanks :)
<seb128> yw ;-)
<pitti> stgraber: I now added a NM test for hotplugging ethernet (with veth), still works fine
<pitti> stgraber: but that's using "ip link add name ethXX type veth peer name vethXX", not your two-command approach
<pitti> stgraber: I guess that eliminates the race
<Quintasan> dholbach: ping
<dholbach> Quintasan, pong
<Quintasan> dholbach: Do you happen to know who can I ask about jobs at Canonical? I'd like to know on what I might actually work on.
<dholbach> Quintasan, is it about a specific job?
<Quintasan> dholbach: Yeah, software engineer job id 622
<dholbach> Quintasan, can you give me a link please?
<Quintasan> uhhh
<Quintasan> dholbach: https://ch.tbe.taleo.net/CH03/ats/careers/requisition.jsp?org=CANONICAL&cws=1&rid=622
<Quintasan> There you go
<dholbach> thanks
<dholbach> Quintasan, I'll find out and get back to you
<Quintasan> dholbach: Thanks!
<ekarlso-> How come running "backportpackage -b -u ppa:endre-karlson/virtualization -s raring -d precise openvswitch" doesn't put a package at https://launchpad.net/~endre-karlson/+archive/virtualization ?
<ekarlso-> cjwatson: ? :)
<tumbleweed> ekarlso-: what *did* it do?
<cjwatson> ekarlso-: 2013-05-14 11:30:46 INFO    Failed to parse changes file '/srv/launchpad.net/ppa-queue/incoming/upload-ftp-20130514-112605-003226/~endre-karlson/virtualization/ubuntu/openvswitch_1.9.0-0ubuntu1~ubuntu12.04.1~ppa1_source.changes': Signing key E4B4AA25FA856267A8267A6A
<cjwatson> FDDCC098A811ECB6 not registered in launchpad.
<cjwatson> ekarlso-: https://help.launchpad.net/Packaging/UploadErrors#The_upload_appears_to_work_but_I_don.27t_get_any_email_about_it
<mpt> cyphermox_, is it possible to tell what kind of Bluetooth 2.1 pairing a device uses (numeric, alphanumeric, numeric comparison, etc) before trying to pair to it? I.e. is the pairing scheme broadcast along with the device name, or is it revealed only when pairing starts?
<tedg> The coffee at this hotel is good, but the service sucks.  âââââ
<roadmr> Hey folks! question about SRU. I have prepared a SRU bug 1059544, added a task for the affected Ubuntu release, and uploaded a branch with a fix. I have upload rights for the package. Should I just merge and upload this to -proposed, or do I need approval from e.g. release team?
<ubottu> bug 1059544 in checkbox (Ubuntu Raring) "checkbox alsa_record_playback should use autoaudiosrc instead of alsasrc" [Undecided,New] https://launchpad.net/bugs/1059544
<cyphermox_> mpt: I'll check and let you know. I'm not sure how pairing works precisely tbh
<ekarlso-> cjwatson: I have uploaded my fingerprint for the key
<ekarlso-> suggestions ?
<ekarlso-> nvm :p
<cjwatson> ekarlso-: OK.  You'll need to retry the upload after doing that
<ekarlso-> ok, thanks :)
<cjwatson> ekarlso-: ... looks like you managed it
<ekarlso-> yes :)
<mardy> kenvandine: does the latest signon-ui fix the integration tests for you (it does for me)?
<avalon78> hi,i want to ask sth on ip header declaration....right channel?
<kenvandine> mardy, i'll check
<sconklin__> @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: sconklin__
<bl4de> wow, guys, I'm trying GoLang...is incredible!
<psusi> I glanced at it once, seemed kind of nice
<cjwatson> stgraber: hmm, so I scheduled the language pack refresh session for 1905 UTC today, but I just remembered I have a RL conflict this evening (choir practice), so we can't have two parallel foundations sessions in the last two slots today
<cjwatson> stgraber: would it be inconvenient if I moved it to tomorrow, say 1605 UTC?
<stgraber> cjwatson: I don't have anything at 16:05 UTC tomorrow, so fine by me
<cjwatson> stgraber: ok, done
<bkerensa> cjwatson: are you foundation track lead?
<mitya57> Mirv: can we sync new qtchooser from debian? in 26-3 they finally added auto-fallback to qt4 versions, which is a very nice feature
<cjwatson> bkerensa: with bdmurray, yes
<Laney> what's the number on the y axis (and the one that appears when you hover on the graph) on an errors.u.c detailed page?
<xnox> smoser: am now. what's up?
<smoser> xnox, i sent you mail, and opened a bug and subscribed you.
<smoser> generally was a really big PITA because you didn't answer me :)
<xnox> smoser: i'm so sorry =) off on vacation.
 * xnox is catching up on irc pings first.
<bdmurray> pitti: could you have a look at bug 1179979?
<ubottu> bug 1179979 in apport (Ubuntu) "symlinks create different python tracebacks" [Undecided,New] https://launchpad.net/bugs/1179979
<pitti> bdmurray: ah, funny; I had thought that the kernel already resolves duplicates in /proc/self/exe
<pitti> oh wait, that's python, so we need to look at the second arg
<pitti> bdmurray: right, will fix
<bdmurray> pitti: great, thanks!
<pitti> bdmurray: I just did an apport upload some 10 mins ago..
<bdmurray> I needed ev's help to sort out the difference between the buckets since they looked so similar. ;-)
<mitya57> bkerensa: chromium non-maintenance was pre-qengho_ time, not relevant anymore :)
<bkerensa> mitya57: wat
<bkerensa> i have no idea what is qengho?
<mitya57> s/what/who/ (check the changelog entries) :)
<seb128> bkerensa, he's the ubuntu chromium maintainer (and on his channel)
<bkerensa> ah
<bkerensa> well thats great news then
<chrisccoulson> oh, i missed the start of uds?
<seb128> chrisccoulson, yes
<Laney> yeah, you missed the decision to switch to mosaic as the default browser
<chrisccoulson> *shrug*
<chrisccoulson> ;)
<TheMuso> lol
<chrisccoulson> i was hoping for lynx. never mind
<mdeslaur> w3m-img FTW
<Laney> hell yeah
<jpds> chrisccoulson: GET.
<chrisccoulson> heh
<cjwatson> Who needs GET when you have nc?
<cjwatson> (uphill, both ways, in the snow)
<mitya57> telnet.
<TheMuso> I'd take any of those choices. :)
<Laney> wetstring.iso
<cjwatson> I used to work for a high-performance web server company some of whose customers ... well, let's say they were the sort of people who *really* needed very high performance on lots of static files in 2000, and whose web sites you might not actually want to look at in a real web browser
<cjwatson> our support staff were encouraged to use low-level text-only HTTP clients where appropriate
<mdeslaur> cjwatson: hehe :P
<stgraber> ;)
<TheMuso> Ah... The way the web should have remained... :p
<seb128> greyback, dpm, pitti, mhall119, any of you coming to https://blueprints.launchpad.net/ubuntu/+spec/client-1305-printing-stack-with-mobile-in-mind ?
<pitti> seb128: no, I'm in the upgrade testing one
<seb128> pitti, ok
<greyback> seb128: I have no idea why I'm invited to that!
<seb128> greyback, no worry, I asked in case ;-)
<mhall119> seb128: no, I'm in app dev sessions all day
<seb128> mhall119, no worry
<lool> pitti: did I tell you how awesome the nm tests you're adding are?  it's really cool stuff
<pitti> lool: :) glad that you like them :)
<seb128> stgraber, pitti: can you mark https://code.launchpad.net/~timo-jyrinki/unity-lens-files/precise.sru.hiddenfiles/+merge/162780 as merged?
<stgraber> done
<seb128> thanks
<cjwatson> mhall119: are you collecting session videos in some kind of central account or anything?
<mhall119> cjwatson: no, but they will remain linked on summit
<mhall119> there was no easy way that we could find last time to put them all in the same place on YouTube
<mhall119> but Summit is searchable and has session descriptions and links to BPs and Etherpad, so it gives us other features too
<cjwatson> mhall119: ok, so I don't need to do anything special?
<cjwatson> having already filled out the broadcast url
<mhall119> cjwatson: nope, just end the hangout and that's it
<cjwatson> cool
<slangasek> cjwatson: last time there was a halfway-coordinated effort to use 'standard' tags on the videos so they could be found later
<slangasek> cjwatson: #uds, #uds-1305 for starters
<Daviey> ev: Do you know if improved whoopsie-daisy experience on server is on a vUDS topic?
<tjaalton> does anyone know why libtool forces link_all_deplibs to "no"?
<tjaalton> or, in other words, libtool in debian is patched to do that, but why..
<cjwatson>   * Don't add the contents of dependency_libs to the link line when
<cjwatson>     linking programs.  Closes: #191425, #199423, #238681.
<cjwatson> is I believe the relevant changelog entry
<tjaalton> ah, thanks
<cjwatson> there are several problems with overlinking
<cjwatson> one is performance on startup; another (more serious) is that you get screwed unnecessarily if one of your library deps changes the soname of something it links against
<cjwatson> now you are trying to load libfoo1 and libfoo2 into memory at the same time and hilarity ensues
<cjwatson> now, why this isn't upstream I can't help you with
<tjaalton> right, it's been there for nine years now :)
<slangasek> does our patched libtool DTRT for static linking, and does it work on non-Linux?
<tjaalton> git/beta version of sssd fails to build and the fedora guys noticed the patch, now thinking how to fix the issue for sssd
<cjwatson> I indeed assume that there are some portability problems
<slangasek> right, anything that fails to link on Ubuntu as a result of that libtool patch is itself buggy
<tjaalton> they created internally shared libs that various bits link to, they used to be statically linked
<tjaalton> https://lists.fedorahosted.org/pipermail/sssd-devel/2013-May/015053.html
<pitti> slangasek: I've got five positive (and zero negative) pieces of feedback for the new udev in my PPA now; is there a chance you could test it on your LVM setup, too?
<stgraber> pitti: ah, that reminds me I need to comment about the new network device name
<xnox> pitti: hmmm... which one? i can test my non-trivial lvm here as well.
<pitti> stgraber: yeah, I guess I'll forward port the old rules generator for the time being, to separate that question from the general update
<pitti> xnox: that'd be great -- https://lists.ubuntu.com/archives/ubuntu-devel/2013-May/037084.html
<slangasek> pitti: not immediately; but as you can see there are lots of others around with LVM in use who should be able to help make sure this is tested before upload :)
<pitti> slangasek: hehe
<pitti> xnox: there's nothing known-broken there with LVM, but we have a patch which was nontrivial to port, so I'd rather make double sure it's still right
<xnox> pitti: even with that patch, I don't think we were watching and using DM_COOKIEs correctly though. As nested LVMs sometimes did not come up for me before. I just check to make sure, my normal servers reboot with the upgrade ;-)
<pitti> xnox: yeah, I think we should not kill the udev in the initramfs and start a new one
<pitti> it should be possible to start it once in initramfs and just keep it running, as both /dev and /run are already move-mounted into the real system anyway
<slangasek> if we don't mind the memory penalty of running a process out of the initramfs indefinitely instead of backed by the filesystem
<slangasek> what is the argument for needing to keep it running from the initramfs?
<cjwatson> I always wondered whether there could be a udevadm control command to tell it to pivot
<pitti> slangasek: it seems a bit pointless to stop and restart it, but more importantly, it seems we had some problems with our lvm package that expects some events to never get lost, but shutting down and restarting udev would lose some events
<pitti> at least that's how I understood the purpose of that dm-cookies patch
<xnox> correct. and one ideally wants the cookies to check which VGs were scanned or not, thus not to "find" the wrong one by accident (in case of nested LVMs, fake-raids etc)
<slangasek> pitti: yes; and I think the right solution is to get that upstreamed, not to carry a shared library penalty on every system due to processes running from the initramfs
<pitti> sure; at this point it's only thinking aloud anyway
 * pitti waves good night
<lifeless> barry: sorry! I missed the UDS session
<lifeless> stgraber: ^
<lifeless> was in a meeting :(
<barry> lifeless: darn.  maybe we can set up a time for us to chat
<seb128> cjwatson, just saw your scribus merge, is it right to build-depends on a virtual package (libtiff-dev)? some other packages do "libtiff5-dev | libtiff-dev" ... is there one more correct than the other one?
<infinity> seb128: Build-depending on virtuals is fine.
<xnox> seb128: in ubuntu we transitioned to newer tiff ahead of debian. any should be fine, as long as you choose the better one =)
<seb128> xnox, what's the preferred way?
<xnox> any = is in real or virtual.
<cjwatson> seb128: yes, it's fine
<infinity> seb128: Binary deps are meant to declare a "real" preference, but build-deps have no such policy.
<xnox> seb128: 5 i think.
<cjwatson> seb128: there's only one provider of libtiff-dev at any one time so the distinction is immaterial
<infinity> seb128: (And, in Debian, build-deps on virtuals are preferred, as it makes binNMUs easier for transitions, since Debian's buildds don't respect alternate deps, intentionally)
<cjwatson> xnox: no
<seb128> I guess we rely on one version only having the provide?
<seb128> ok, cjwatson already said that :p
 * xnox is confused.
<infinity> xnox: Evidently. ;)
<infinity> xnox: Virtual build-deps are the preferred method, so transitions aren't a painful mess.
<cjwatson> I went through quite a few libtiff-dev r-build-deps a couple of releases ago; this ended up being the natural pattern for most of them, but I didn't bother pushing against the flow in cases where the Debian maintainer had decided to be specific
<xnox> i see.
<infinity> xnox: And alternate build-deps only work in Ubuntu because we hacked sbuild to make it work so we could do the main/universe split, they're explicitly not followed in Debian.
<xnox> infinity: that. thanks.
<seb128> infinity, what happens if several package provide the virtual? do we get a random version picked on build depending of the position of the moon?
<cjwatson> Though libtiff5-dev | libtiff-dev works in both, as long as you don't mind it never picking other versions in Debian.
<infinity> (ie: on a Debian buildd, "libtiff4-dev | libtiff-dev" == "libtiff4-dev")
<xnox> infinity: limitation or intention?
<xnox> (in debian)
<cjwatson> seb128: You shouldn't use this in cases where several packages provide the virtual, indeed.
<infinity> xnox: It's intentional in Debian.
<cjwatson> But I knew what was happening with libtiff-dev.
<infinity> sbuild's resolver actually does try to intelligently select in the case of multiple providers, it's not random.
<seb128> cjwatson, right, I was wondering because infinity said it's the preferred way for transitions
<cjwatson> In the case of transitions which follow the only-one-package-provides-preferred-virtual pattern.
<infinity> seb128: The Debian release team prefers things they can binNMU.  Individual library/stack maintainer may know better in specific cases.
<cjwatson> I'd be more cautious about it for others.
<lifeless> barry: yeah that would be good
<seb128> ok, makes sense
<seb128> cjwatson, infinity, xnox: thanks ;-)
<barry> stgraber: ^^
<seb128> btw do you know if debian plans to start the libtiff transition soon?
<stgraber> barry: yep, we can do that
<infinity> I suspect it'll start sometime after people are done being grumpy about doko and I doing toolchain transitions.  *cough*
<seb128> lol
<cjwatson> Debian tends to try to avoid overlapping transitions
<cjwatson> I think there's a decent queue :)
<cjwatson> http://lists.debian.org/debian-release/2013/05/msg00127.html
<xnox> seb128: there are 27 planned transitions filed, a few uncoordinated transitions started (even before wheezy release). Oh tiff3 is not out of the debian, ouch.
<seb128> well, it's not like the delta was hard to maintain... ;-)
<TheMuso> ugh forgot to include changelog entries from debian with a merge upload. :S easy to do when working with git buildpackage.
<roadmr> oh, a git user!
<TheMuso> Yes, since Debian uses git to maintain the packaging for the package I was working on, and I maintain the Ubuntu delta in the same repo.
<TheMuso> c
<stokachu> stgraber: ive got both bug 859600 and 1094319 in shape for a sponsorship if youve got time
<ubottu> bug 859600 in gnome-keyring (Ubuntu Precise) "Please convert gnome-keyring to multiarch" [High,In progress] https://launchpad.net/bugs/859600
<ubottu> bug 1094319 in gnome-keyring (Ubuntu) "p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory" [Undecided,Fix released] https://launchpad.net/bugs/1094319
<bdmurray> barry: still about I'm curious about python tracebacks ending in 'ValueError: bad marshal data'
<barry> bdmurray: yeah
<bdmurray> https://errors.ubuntu.com/problem/5b56cf70bb8fe037f020c4a2536d214092cb9823
<bdmurray> there is an example
<bdmurray> I gather this is due to corrupt .pyc files?
<barry> bdmurray: yeah, gotta be
<bdmurray> I wonder if apport should help out here
<barry> bdmurray: maybe we need a post-installation .pyc checker, but this one is happening in threading which comes with the stdlib.  i really should bring this up on debian-python ml
<bdmurray> barry: if you look at http://people.canonical.com/~brian/tmp/phased-updates.html
<bdmurray> every duplicity error for version 0.6.18-0ubuntu3.1 ends in bad marshal data
<barry> bdmurray: looks like they're all in "import threading" too.  that's pretty curious
<bdmurray> barry: ?     import time, types, re, calendar
<bdmurray> ValueError: bad marshal data (string ref out of range)
<bdmurray> from https://errors.ubuntu.com/problem/550cc32bf32c9dfe4901e6010c000ad39b69d5f4
<barry> okay, not that one ;)
<bdmurray> actually there are a lot of EOFError's about duplicity too
<bdmurray> https://errors.ubuntu.com/?release=Ubuntu%2012.04&package=duplicity&period=year
<barry> bdmurray: my best guess is that this is a systematic problem with the writing of .pyc files during package installation.  even though there's no atomic writes of pycs until python 3.3, i still can't think of a scenario that could cause this to happen.  can you do me a favor?  can you compile a list of public bugs of this type and send me an email?  i'll try to formulate something for debian-python, and perhaps upstream
<bdmurray> barry: public launchpad bugs with ValueError ... bad marshal data and /or EOFError: EOF read where ...
<cjwatson> barry: note that pyc files are handled specially by ubiquity, although I can't imagine how it'd matter
<barry> bdmurray: yes
<bdmurray> barry: okay both it is!
<cjwatson> But just in case these are all during installation
<barry> bdmurray: thanks!
<barry> cjwatson: interesting.  what does ubiquity do specially?
<cjwatson> We exclude .pyc files from the live filesystem to save space; ubiquity goes through and calls pycompile and friends a bunch of times to recreate them after installation
<barry> i guess there's no way to know whether the pyc was created at system installation time or via subsequent package installation
<cjwatson> Not easily, though anything that's on the live image and that hasn't been upgraded since installation from a live image would fall into that category
<cjwatson> https://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/view/head:/scripts/plugininstall.py#L334
<cjwatson> (configure_python)
<barry> cjwatson: is there any way more than call to configure_python() could run at the same time?
<cjwatson> No, that's all single-threaded/single-process
 * barry wonders how hard it would be to "backport" atomic pyc writing to python 2.7 - can't be backport-no-quotes because it's C in 2.7 and python (importlib) in 3.3
<cjwatson> Indeed it's only ever called once period
<cjwatson> And it should be strictly after all files from the live image have been copied to disk
<barry> yeah. i can't think of how this could happen in single-threaded/process
<barry> bdmurray: have you ever run across this bug in python3 code?
<barry> (this or any similar?)
<cjwatson> Just worth mentioning in case you wind up down some confusing blind alley and it turns out to be the fault of this code.  It may be unrelated
<barry> cjwatson: thanks
<barry> the big problem of course is that i have no idea how to reproduce this, but i could certainly try a few fresh installs to see if i can trigger the problem
<barry> cjwatson: so ubiquity is possibly a good clue
<bdmurray> barry: I haven't looked closely but will keep an eye out
<barry> bdmurray: cool.  my working hypothesis is that we have a race condition in writing .pyc files under some conditions.  py3.3 writes them atomically and so should be immune, but py2.7 does not.  if we see this problem with py3.3 then i really have nfc ;)
<cjwatson> barry: I suppose it is possible that ubiquity runs something else as root in parallel with that which might cause python to write the .pyc files on its own
<barry> cjwatson: that could do it
<cjwatson> There *shouldn't* be, and I can't think of an obvious place to start looking
<cjwatson> The only thing being run in the chroot at that point is py_compile.py (etc.) itself
<cjwatson> I think
<cjwatson> But it's perhaps worth some detailed strace investigation at around the point plugininstall.py kicks off (just after "Copying files" finishes)
<sconklin__> @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:
<barry> cjwatson: actually, i'm looking at the code now.  i need to investigate in more detail when dinner isn't ready <wink>, but i actually think that 2.7 may open the pyc file O_EXCL|O_CREAT|O_WRONLY|O_TRUNC
<infinity> barry: Couldn't this happen pretty much any time you're updating a python module via dpkg and also running some root-owned python process in parallel?
<infinity> barry: (Like, I dunno, python-apt)
<infinity> barry: Or, as the many errors point to, duplicity, since it's probably cronned as root, and can sometimes trip at just the wrong time (during a package update when the pyc files are briefly missing or being recreated).
<barry> infinity: it could.  3.3's behavior is a bit different than 2.7 here, since it writes the pyc to a pseudo-random file and then atomically renames it into place after successful write.  py2.7 doesn't do the atomic rename
<infinity> barry: That should be vaguely trivial to knock up a fix for.
<barry> infinity: yes, i think so too
<barry> (slightly less trivial in 2.7 since the import machinery is in C there, but not really that bad i suspect)
<infinity> barry: mkstemp(3)?
<bdmurray> a lot of these are upgrades rather than fresh installs
<mwhudson> i'm fairly sure python 2 isn't *hilariously* vulnerable to pyc-writing races
<infinity> barry: I'm not inclined to believe this is a harder problem to solve in C than in Python. :)
<barry> infinity: for posix perhaps :)  the question is whether we want to try to get a cross platform fix upstream or just hack it into debuntu's version.  i'll probably try to chat with a few of the other upstream import machinery experts so we can come to some consensus on the problem and proper fix
<barry> infinity: it's probably not, although the specific algorithm would be different a bit
<infinity> barry: A google for "mkstemp win32" gets me http://gitorious.org/git-win32/mainline/blobs/8cfc8e4414bbb568075a948562ebb357cb84b6c3/win32/mkstemp.c
<infinity> Or a much longer one in a random pastebin.  Heh.
<barry> mwhudson: yeah, it's *probably* true, but not as hardened as 3.3.  e.g. 2.7 opens excl|creat but no atomic rename afaict
<barry> infinity: yeah, but it's not like i'm personally ever gonna test it on windows :)
<mwhudson> barry: sure
<cjwatson> Gah, still no armhf porter box?
<infinity> Or http://msdn.microsoft.com/en-us/library/t8ex5e91%28VS.80%29.aspx ..
<infinity> cjwatson: Need a panda?
<cjwatson> that'd be nice
<cjwatson> as long as it's remotely :)
<infinity> cjwatson: shiva.0c3.net
<cjwatson> infinity: Cool, thanks.  No schroot?
<goddard> how many packages are in ubuntu?
<goddard> or in the repositories i should say
<cjwatson> which version, which architecture, and do you mean binary packages or source packages?
<goddard> how many for a given version at a time?
<goddard> like 13.04 for example
<cjwatson> different answers depending on which version, which is why I'm asking you.
<infinity> cjwatson: See /msg
<goddard> all x86 etc..
<goddard> can i get a list of all debs in the ubuntu repositories?
<cjwatson> sure, you can grab the Packages files from archive.ubuntu.com/dists/
<cjwatson> er /ubuntu/dists/
<cjwatson> 13.04 has 20477 source packages; as for binary packages,  amd64 41005  armhf 39953  i386 41054  powerpc 40161
<mwhudson> argh
<goddard> cjwatson: that was quick how did you get those numbers :D
<mwhudson> anyone got some random tips for figuring out why / is being mounted read only?
<cjwatson> goddard: I grepped the Sources and Packages files
<cjwatson> grep-dctrl is good for advanced tricks, but for this it's sufficient to just count matches for ^Package:
<goddard> cjwatson: so the software list is stored locally
<cjwatson> apt fetches Packages files in order to work out what to present to you, if that's what you mean, yes
<cjwatson> Though I ran my grep jobs on a machine with the full archive since that was faster than downloading the indices over my ADSL
<goddard> cjwatson: still a little fuzzy to me
<goddard> cjwatson: and you have a full archive of 13.04?
<cjwatson> I'm an Ubuntu archive administrator ...
<cjwatson> I have *the* full archive :-P
<sarnold> :)
<cjwatson> But it's all on archive.ubuntu.com
<cjwatson> (You only need the index files for this sort of thing, not the whole enormous site)
<infinity> mwhudson: dmesg may have enlightening info.
<infinity> mwhudson: Controllers resetting, write/read errors, etc.
<goddard> cjwatson: so that is like a few TB?
<goddard> cjwatson: and thats btw
<goddard> thanks*
<cjwatson> dists/raring/ is 3.5GB, but that's including all the installer images and such in there
<cjwatson> The Packages and Sources files in there are only 73MB
<cjwatson> The whole thing is pretty enormous, sure; I don't want to trash this machine's buffer cache by running du to find out
<mwhudson> infinity: seems to be a less deep problem actually, running mount / -o remount,rw works fine
<infinity> mwhudson: That doesn't imply fineness.  It just means you've ignored the kernel's attempts to save you from yourself.
<mwhudson> hmm
<mwhudson> mountall: Plymouth command failed
<mwhudson> mountall: Disconnected from Plymouth
<mwhudson> mountall: Skipping mounting / since Plymouth is not available
<infinity> Oh, or maybe it never got mounted rw in the first place.
<mwhudson> is there some way of making that more verbose?
<infinity> mountall is voodoo to me.  I'd suggest slangasek, but he's supposedly not here.
<slangasek> yeah, so don't suggest me
<infinity> (Though the error message implies that plymouth either isn't there, or isn't running... Did you break it somehow?)
<mwhudson> i don't know how this is supposed to work
<mwhudson> is it in the initramfs or in the rootfs?
<infinity> That depends.
<mwhudson> this is a 'linaro engineering build'
<slangasek> mwhudson: that message only appears if it can't connect to plymouth *and* there's an error mounting the root filesystem
<slangasek> so this is special++
<infinity> If you have a FRAMEBUFFER=y initramfs config (either explicitly or transitively via something like full disk encryption), then plymouth will be in the initrd.
<slangasek> s/full disk encryption/installation of the 'cryptsetup' package/
<mwhudson> slangasek: i just love being special
<infinity> Or that.
<mwhudson> i doubt that is involved
<infinity> mwhudson: If it's an LEB, all bets are off.  It might just be broken. :P
<mwhudson> yeah
<mwhudson> this very same image worked last week though :/
<mwhudson> and if i run mount / -o remount,rw and reboot ... it works
<infinity> A new definition of time-based release wherein the release only works one time?
<mwhudson> i still see
<mwhudson> mountall: Plymouth command failed
<mwhudson> mountall: Disconnected from Plymouth
<mwhudson> but not the skipping / one
 * mwhudson brb
<mwhudson> infinity, slangasek: is there some way i can make plymouth and/or mountall super verbose?
<slangasek> mwhudson: well, from the error messages I infer that you're managing to crash plymouth, so not really
<slangasek> (and mountall's verbose output is supposed to go *to plymouth*, so no dice there either)
<slangasek> mwhudson: you can try to run plymouth post-boot and see what you get?
<mwhudson> yay
<mwhudson> root@localhost:~# plymouth --ping
<mwhudson> root@localhost:~# echo $?
<mwhudson> 1
<mwhudson> i guess that's bad?
<mwhudson> hm get the same on my system
<slangasek> mwhudson: you would need to start plymouth first; see the /etc/init/plymouth* upstart jobs
#ubuntu-devel 2013-05-15
<mwhudson> root@localhost:~# start plymouth
<mwhudson> plymouth start/running, process 1127
<mwhudson> root@localhost:~# plymouth --ping
<mwhudson> root@localhost:~# echo $?
<mwhudson> 0
<mwhudson> seems better
<straemer> Hey, I'm interested in doing some bug-fixing for the ubuntu one music android app. Would anyone be able to show me where to get started on that?
<sarnold> straemer: (guessing) try #ubuntuone  ?
<straemer> sarnold: I think that's a support channel
<sarnold> straemer: ah :) darn, sorry
<mwhudson> ok now i'm reading the mountall source
<mwhudson> time to get out of the rabbit hole i think
<pitti> Good morning
<mlankhorst> morningg
<infinity> didrocks: The new webapps-application pulls a few things into main without an MIR.  Was someone going to do something about that?
<infinity> didrocks: Specifically gjs and mozjs.
<didrocks> infinity: we are going to demote all those scripts to universe AFAIK
<infinity> didrocks: "All those scripts"?
<didrocks> so I guess webapps-application is part of it
<infinity> didrocks: As in, unseed unity-webapps-common?
<didrocks> infinity: indeed, I still need to do a final check with robru, but that's what I understood
<infinity> didrocks: Alright.  Well, as soon as you know, please yank it from the seeds and I'll demote with extreme prejudice. ;)
<didrocks> infinity: ahah, I'll maybe take that demoting pleasure for myself TBH. This has been such a pain :p
<robru> didrocks: infinity: hi
<didrocks> oh, a robru!
<robru> I don't know about whether or not this stuff needs to be in main. that's a strategical question that you'd need to ask to somebody who makes plans. I just do what people tell me
<didrocks> robru: so, IIRC, the plan of record is to have all the scripts in universe, right?
<didrocks> robru: as we even don't install the firefox nor the chromium extension by default
<robru> didrocks: is that so? but I thought we were prompting people to install webapps by default
<robru> didrocks: maybe vrruiz is a better person to ask about this.
<didrocks> robru: I'm still lost in all that maze of webapps*, where is the firefox extension?
<robru> didrocks: I don't think the browser extensions are enabled for daily release yet, only CI
<didrocks> robru: yeah, I just need the name of the extension :)
<didrocks> robru: IIRC, the goal was: extension in main, all scripts in universe (including -common)
<robru> didrocks: ok, so it's unity-firefox-extension and unity-chromium-extension
<didrocks> ok, the extension is still in main for firefox
<robru> didrocks: as long as we end up in a situation where the default ubuntu install will prompt users to install webapps, then I think we're ok. I don't personally have any stake in whether the apps are living in main or universe.
 * robru just wants this nightmare to end
<didrocks> ah, there are those desktop files we install by default though :/
<didrocks> robru: I'm afraid that -common still need to be in main for now
<robru> didrocks: just amazon and ubuntuone-music right?
<didrocks> robru: right
<robru> didrocks: so it sounds like those .desktop files need to be in a different package so that we don't bring in gjs into main with -common package
<didrocks> robru: gjs is used for your lintian script?
<robru> didrocks: nope, gjs is used for style_checker.js, which is a wrapper around jslint. that's different than my linter script (jslint is linting js syntax, my linter is linting the packages, ensuring that translations are present, etc.)
<didrocks> robru: style_checker.js is run during package build?
<robru> didrocks: yeah
<robru> didrocks: yeah, there's no way around depending on gjs in -common, that's the closest thing we have to test coverage at the moment.
<didrocks> robru: in fact, I think we should move them
<didrocks> robru: scripts/third_party/jslint.js usr/share/unity-webapps/tools/
<didrocks> common/rules.mk usr/share/unity-webapps/
<dholbach> good morning
<didrocks> those should be move to another package (same source)
<didrocks> but another binary
<robru> didrocks: ok, that can be done
<didrocks> we can call it unity-webapps-script-build
<didrocks> robru: or any better word ^
<robru> didrocks: but keep in mind, either the -common package will have to depend on it, or we'll have to edit all 41 apps to depend on this new package too
<didrocks> having all the script biuld-dep on it
<didrocks> (yeah, I know :/)
<didrocks> robru: but you have sed foo now :)
<robru> didrocks: unity-webapps-dev
<didrocks> robru: excellent :)
<didrocks> and this one has the gjs dep
<didrocks> will be in universe
<didrocks> with all the scripts in universe
<didrocks> robru: do you think you'll have time to do that? any idea once this can be done (so that we can clear the mismatch components)
<robru> didrocks: if you make me push 41 MPs I am going to scream. I'll just commit those packaging changes directly to trunk
<didrocks> (this has the benefit to not ship -dev content on user's machine as well)
<didrocks> robru: direct commit is fine :)
<didrocks> hey dholbach!
<dholbach> hey didrocks
<robru> didrocks: I can do that right now.
<didrocks> robru: \o/
<didrocks> robru: we are *almost* there!
<robru> didrocks: ;-)
<didrocks> robru: btw, I relaunched the daily for webapps
<didrocks> robru: as I relaxed now the constrain to have the bootstrap commit message for distro
<robru> didrocks: this is going to cause another bootstrapping nightmare, isn't it? we'll need unity-webapps-dev pushed everywhere
<robru> didrocks: I saw your improvements to the changelog generation, very nice.
<didrocks> robru: well, I'll handle it, it's juts an upload to distro and to the ppa
<didrocks> robru: great ;)
<didrocks> robru: just put this unity-webapps-dev to review please :)
<robru> didrocks: right
<infinity> didrocks, robru: Thanks for the prompt handling.  Maybe you can teach the server team how to deal with component mismatches. ;)
<didrocks> infinity: ahah, yw! Sorry for introducing it first :-)
<robru> didrocks: https://code.launchpad.net/~robru/webapps-applications/dev/+merge/163848
<robru> didrocks: wait, build just failed locally. bah
<didrocks> robru: commenting
<robru> didrocks: ugh, I'm confused. my changes are causing dh_install --fail-missing to fail. I have no idea why... it says utils.js is not installed to anywhere, but I didn't change anything about utils.js (and trunk builds fine)
<robru> didrocks: and I added a line to unity-webapps-common.install to explicitly install it, but it doesn't help.
<didrocks> robru: I smell you forgot a bzr add unity-webapps-dev.install :)
<robru> didrocks: nope, if that were the case it'd be complaining about the files that go in the -dev package. it's complaining about files that should be in the -common package
<didrocks> robru: let me bzr branch
<robru> didrocks: please take my branch and do a 'bzr bd' in it, total mystery to me
<didrocks> robru: grep utils.js debian/*
<didrocks> -> nothing
<didrocks> robru: shouldn't you list usr/share/unity-webapps/userscripts/common/ in -common.install?
<robru> didrocks: yeah, well, build trunk and it works!
<robru> didrocks: but I added that line, like you would obviously expect to find, and it didn't make a difference.
<didrocks> robru: trunk built because your .install file was not that relevant (no debian/tmp for just one binary)
<didrocks> robru: added usr/share/unity-webapps/userscripts/common to debian/unity-webapps-common.install works here
<didrocks> the build pass then, and all files that we need to install are installed :)
<robru> didrocks: no idea
<robru> didrocks: anyway, pushed. please approve
<didrocks> robru: please set to UNRELEASED
<didrocks> robru: not saucy
<didrocks> in debian/changelog
<didrocks> other than that, looking good
<didrocks> (and wrap to 80 characters :p)
<didrocks> robru: I wonder why emacs didn't forbid you to save the file with all your automation :-)
<robru> didrocks: rushing
<robru> didrocks: it does display the long line with big angry red letters though
<didrocks> ahah ;)
<didrocks> robru: thanks! approving now
<didrocks> robru: once it's merged, I'll upload to saucy and the ppa for the boostrap
<didrocks> bootstrap*
<robru> didrocks: should I wait for you to be ready before pushing commits to the webapps trunks? or can I do that now
<robru> ?
<didrocks> robru: well, just show a diff and I will tell you yes/no, then, just push :)
<didrocks> robru: it's just about appending on build-dep I guess
<robru> didrocks: I am literally just going go s/unity-webapps-common/unity-webapps-dev in the control files
<didrocks> robru: you don't need -common still for the usr/share/unity-webapps/userscripts/common/* content to build the scripts?
<didrocks> (honest question, I have no idea ;))
<robru> didrocks: I guess so. -dev should have depended on -common though, oops ;-)
<didrocks> robru: I came to the exact same conclusion :)
<didrocks> robru: I aborted the merge, please push an extra rev :)
<robru> didrocks: it's fine. I'm just pulling all the webapps branches now, once that's done I'll show you one diff and then push identical changes to all branches
<robru> didrocks: oh, ok
<pitti> infinity: I tried to reproduce the libsoup2.4 armhf test case failure (leading to ftbfs) on my nexus; with plain dpkg-buildpackage, with and without fakeroot, our code vs. upstream git head, etc; it always works there
<pitti> infinity: is it possible to somehow get ssh access to a buildd-like machine?
<pitti> mbiebl: ^ FYI (affects Debian as well)
<infinity> cache-test: 1 error(s). Run with '-d' for details
<infinity> FAIL: cache-test
<infinity> ^-- If only it then DID that, so we had details in the build log...
<robru> didrocks: http://paste.ubuntu.com/5666777/ I am going to push this to all 41 webapps branches
<didrocks> robru: excellent :)
<didrocks> robru: I approved your additional commit bw
<didrocks> btw*
<robru> didrocks: great
<robru> didrocks: ok, pushing
<pitti> infinity: yeah, the makefile doesn't pass that on; we can temporarily call it manually in debian/rules, but that will also just list the individual tests, not why it's failing
<pitti> infinity: do we have a PPA where I can throw lots of test builds in, so that I don't have to clutter the actual archive?
<pitti> (which builds arm)
<infinity> pitti: We do, but let me give this a whirl locally first.
<infinity> pitti: Was your nexus7 test with a buildd chroot?
<pitti> infinity: no, just standard phablet installation
<infinity> Is that saucy?
<pitti> it's raring, but I got saucy's source
<pitti> oh, I guess I should upgrade to saucy's glib
<infinity> pitti: But not saucy's toolchain.
<infinity> pitti: Which is gcc-4.8...
<pitti> ack
<infinity> pitti: Better off just grabbing the chroot tarball from LP and using that.
<infinity> https://api.launchpad.net/1.0/ubuntu/saucy/armhf
<pitti> oh, handy!
<infinity> Just untar that, fix resolv.conf, mount /proc and /dev/pts, dist-upgrade, and go to town. :P
<infinity> Should be easier than going piecemeal on your phablet install.
<robru> didrocks: ok, done pushing the s/-common/-dev/ change for all webapps
<robru> didrocks: is that all you need from me? I'm thinking about going to sleep ;-)
<didrocks> robru: excellent! as you saw, the previous daily run worked, but it's in manual publishing mode due to the packaging changes (and upstream stack, like the QA one failing)
<infinity> pitti: Anyhow, also running here on a Panda, but I really doubt the kernel or hardware are your issue here.
<didrocks> robru: so I'll push -common once it's merged manually to bootstrap
<didrocks> robru: then run the daily
<robru> didrocks: you mean push -dev, but yeah
<didrocks> robru: then manually publish (as the failure from QA stack doesn't impact us)
<didrocks> robru: yeah, the source package containing both :)
<didrocks> robru: and I think we'll be done then! :-)
<robru> didrocks: the source package is called webapps-applications. I wonder if it would be too much of a pain to name that more meaningfully
<didrocks> robru: yeah, I'm also trying to bzr branch lp:<something>-common, but let's keep it that way for now
<robru> yeah, we would need to rename the lp project and everything, total pain
<didrocks> yep
<robru> didrocks: ok, g'night then.
<didrocks> robru: enjoy your (relatively early this time ;)) night!
<pitti> meh, no overlayfs or aufs on nexus kernel?
 * pitti repacks the unpacked chroot to not have a top-level directory then, to use it in tarball mode
<infinity> pitti: FFS, it didn't fail here.
<infinity> My test chroot wasn't entirely clean, but...
<pitti> aah, now I have schroot -c saucy working on the nexus at last
<tjaalton> siretart: hey, any reason not to sync libva & intel-vaapi-driver from experimental for saucy? I have gstreamer-vaapi updated for gst1.0 and would like to test these on haswell too
<infinity> pitti: Ah, the cache test failure is intermittent.  Re-running make check, I tripped it.
<pitti> ah, it seemed to happen fairly consistently on the buildds in the last few builds
<infinity> pitti: And, indeed, a retry on the buildd succeeded.
<pitti> infinity: I now have sbuild etc. set up, libsoup building ATM
<pitti> infinity: oh, handy; I'll still see if I can reproduce it here
<pitti> buildds are pandas, right?
<pitti> (i. e. slightly slower than nexus 7)
<infinity> pitti: http://paste.ubuntu.com/5666948/
<infinity> pitti: buildds are Pandas, yes.
<pitti> "leaked GInputStream!
<infinity> pitti: Took me about 10 tries to get that failure.
<infinity> pitti: So, it could just be racy, and slow machines trip it more easily.
<infinity> pitti: Which would explain my slightly faster Panda doing better than the slower ones in the DC.
<infinity> pitti: And Debian's much slower buildds always failing.
<infinity> pitti: And x86/ppc having no issues.
<infinity> (ie: it might not be ARM-specific)
 * pitti runs (set -e; for i in `seq 50`; do echo "=== $i ==="; ./cache-test -d; done)
 * pitti runs again with a find / in the background
<infinity> pitti: Same failure on mipsel (which is also notoriously slow) seems to back up my wild guess.
<pitti> infinity: ack, very much sounds like a race; thanks for confirming!
<infinity> pitti: Try to reproduce it on eder.debian.org ... No time like the present, doko's building GCC in the background. :P
<seb128> pitti, https://bugzilla.gnome.org/show_bug.cgi?id=698305 ?
<ubottu> Gnome bug 698305 in Misc "cache-test refcounting test fails sporadically" [Normal,New]
<seb128> pitti, just pointing the bug for reference, it has no info/patch/...
<pitti> yep
<pitti> seb128: that's the one I have chased for the past two hours now..
<seb128> pitti, thanks for looking into that!
<seb128> pitti, I tried for a bit before pinged you, but had no luck :/
<mbiebl> pitti: since you are a DD, you might try http://db.debian.org/machines.cgi (which I'm pretty sure you know about)
<mbiebl> iirc, you should now be able to install b-deps without having to contact DSA
<pitti> mbiebl: yes, I do (eder seems appropriate, it's really slow)
<mbiebl> even for a small lib like libsoup2.4, ouch
<pitti> I tried on my nexus7 with letting a cat /dev/urandom > /dev/null and a tar cj /usr running in the background, doing "echo 3 > /proc/sys/vm/drop_caches" all the time, and running the test endlessly, and it survived > 250 iterations so far
<ogra_> pitti, cant you do that easier via sysctl (cache_timeout or so) instead of always echoing into /proc ?
<ev> Daviey: it's not. Could stick it in on Thursday if you think we couldn't settle that one with a phone call?
<Daviey> ev: I don't think it needs a dedicated session or anything.  Just need to work out, *if* it is worth doing .. *how* to do it.. and *who* to do it :)
<rbasak> I'd love to see it. I think it'd be useful. Right now the best information we get is from bug reports, and most of those are from people who have misconfigured things and then send us reports for maintainer script failures.
<rbasak> No idea *how* though.
<Daviey> rbasak: Right, last time i spoke to ev about this.. we were interested in running it during the dev cycle, but turning off by default on production
<rbasak> And many server operators may prefer not to send us anything from production servers.
<Daviey> rbasak: do you think people would be happy running this on production servers?
<rbasak> Right - thanks makes sense, and would be a great start.
<rbasak> I think most people running production servers would want to vet reports, but wouldn't object if they had the option of sending reports.
<rbasak> Eg. how about a CLI with a prompt on motd if there's pending stuff in /var/crash?
<Daviey> That actually seems reasonable middleground.. :)
<rbasak> A "talk me through it CLI" like ubuntu-bug
<Daviey> maybe a session is warranted.. but our schedule is already full. Ugh
 * Daviey suspects we'll need a third track next time.
<rbasak> I think this is the sort of case where we really want an ML discussion thread first.
<rbasak> Not sure we'd gain much from a session as-is.
<ev> Daviey: we could just schedule a google hangout out of band
<Daviey> rbasak: Fancy kicking that off?
<ev> or that :)
<Daviey> ev: that sounds crazy enough that it might just work.
<rbasak> Sure. Give me a day though - I've some errands to run before vUDS.
<Daviey> rbasak: thanks :)
<mlankhorst> could one of the sru admins accept all the xorg related packages in https://launchpad.net/ubuntu/precise/+queue?queue_state=0&queue_text= ?
<siretart> tjaalton: no, please do. I just don't have the time and ressources to actually test them right now, but they should be good for saucy!
<Daviey> mlankhorst: is this the tracking bug 1177679?
<ubottu> bug 1177679 in llvm-3.2 (Ubuntu) "lts-raring sru bug" [High,New] https://launchpad.net/bugs/1177679
<tjaalton> siretart: one glitch I found is that libva-dev probably needs to depend on libva-drm1 too, but we can fix that later
<tjaalton> siretart: but yeah, I'll sync the current versions, thanks
<siretart> tjaalton: well, patches, as always, are very welcome  :-)
<tjaalton> :)
<mlankhorst> Daviey: yeah
<Daviey> mlankhorst: I think the bug report probably needs expansion TBH.  FOllowing the SRU template would be helpful, and linking to related discussion on the xserver ennoblement agreements made already?
<mlankhorst> Daviey: lts-quantal didn't even have a tracking bug at all
<mlankhorst> and it's pretty much s/quantal/raring s/ltsq/ltsr/
<Daviey> mlankhorst: Okay, I wasn't involved in that.  Maybe ping the person that handled that?
<mlankhorst> Daviey: code is at https://bazaar.launchpad.net/~xorg-edgers/xorg-server/xorg-pkg-tools/files running 'lts-stack raring' in an empty directory on raring grabs all the right versions. rerunning on precise in that directory with dev tools installed will make all the packages
<ev> rsalveti, apw: mornin'! What's the latest on the grouper kernel? Are you still fighting gcc bugs, or was this an issue with the kernel config?
<mlankhorst> but there is no way for this to break existing things anyway, they're all new packages
<Laney> mardy: I hear you want to hear about bugs like bug #1180297 :-)
<ubottu> bug 1180297 in gnome-control-center-signon (Ubuntu) "Opening facebook "Success" page in external browser" [Undecided,New] https://launchpad.net/bugs/1180297
<mardy> Laney: in a way, yes :-)
<mardy> Laney: damn, Facebook is redirecting to plain http again :-(
<apw> ev, it was an interaction between the kernel and compiler, who is to blame is unresolved, but the kernel in the archive is bootable
<ev> apw: oh? I hadn't noticed a new upload in saucy-changes
<ev> weird
<ev> I'll give it a bash today
<ev> thanks
<apw> ev, hmmmm maybe i am getting them all the different versions mixed up
<ev> nexus 7 :)
<cjwatson> That'd be "grouper"
<infinity> It was mako and/or manta that we were fiddling with gcc-4.8 issues on, wasn't it?
<infinity> Or did grouper suffer the same issue and need a rebuild?
<seb128> pitti, can you see https://code.launchpad.net/~nottheoilrig/ubuntu/quantal/python-gnutls/fix-for-1013798/+merge/154767 as merged? (went in quantal:  https://launchpad.net/ubuntu/+source/python-gnutls/1.2.4-1ubuntu0.1Ã 
<pitti> seb128: done
<seb128> pitti, danke
<pitti> infinity: sheesh -- now that eder finally built that thing, "cache-test: OK" *grumpf*; but i'll try some iterations
<infinity> pitti: Hahaha.  D'oh.
<seb128> pitti, can you reject https://code.launchpad.net/~vandersonmr/gnome-screenshot/bugfix1169904/+merge/161262 ?
<pitti> done
<seb128> thanks
<pitti> ok, it does reproduce quite often on eder
<tkamppeter> Any Upstart expert around? Can I start daemons on-demand with upstart, for example triggered by an access to a given port (like xinetd does) or to a given domain socket?
<tkamppeter> systemd is capable of this.
<doko> jodh, xnox: ^^^
<jodh> tkamppeter: see socket-event(7)
<tkamppeter> jodh, so if CUPS would have "start on socket PROTO=unix /var/run/cups/cups.sock, a client ("lpr" or anything else using libcups2) accessing /var/run/cups/cups.sock would trigger the start of cupsd and the access gets processed by cupsd?
<jodh> tkamppeter: "yes", but cupsd would need to be modified such that it does not call socket() et al itself - it would simply need to call accept(2) on the socket fd passed to it via the UPSTART_FDS env var. I believe systemd requires something similar.
<pitti> something like http://pkgs.fedoraproject.org/cgit/cups.git/tree/cups-systemd-socket.patch
<tkamppeter> pitti, thanks.
<tkamppeter> jodh, can you have a look into patch and see whether this can also be used with Upstart?
<rbasak> Looks like the patch is very systemd specific, but the general mechanism is the same.
<seb128> cjwatson, infinity: is https://launchpadlibrarian.net/138772411/saucy.debdiff fine to sponsor (just asking in case you have another upload planned for live-build)?
<seb128> (to sru for raring as well)
<cjwatson> seb128: sure
<seb128> cjwatson, thanks
<tkamppeter> rbasak, pitti, could someone of you help me to add upstart support to the patch?\
<pitti> seb128: I sent some analysis to gnome bug 698305, but I stop at this now; at this point I really don't understand glib weak refs and threading well enough, and as we can just give back the package it's not immediately urgent
<ubottu> Gnome bug 698305 in Misc "cache-test refcounting test fails sporadically" [Normal,New] http://bugzilla.gnome.org/show_bug.cgi?id=698305
<tkamppeter> pitti, is there also a patch for the cupsd to stop after a certain time being idle?
<pitti> tkamppeter: you can check http://pkgs.fedoraproject.org/cgit/cups.git/tree/, but I don't think there is
<pitti> you usually don't want cups to stop
<seb128> pitti, ok, thanks ... did you manage to get it to build after retries? we had a few on the buildds and it never went through
<pitti> and you usually don't want to start cups at the time when you need it first, but much earlier
<pitti> as remote printer detection will just take a while (DNS-SD announcements are only sent every 30 seconds or so)
<pitti> seb128: yes, infinity gave it back once, and it's built now
<rbasak> It looks non-trivial to me :(
<seb128> pitti, great, thanks again!
<rbasak> Although from that patch it looks like systemd provides a library as a general mechanism. It might be worth considering if it's worth implementing an equivalent compatibility library that supports upstart's socket bridge that could be used in place of it and support the same API. I'm not sure how likely systemd upstream are to change the API though. But it would be nice to easily support anything that supports systemd socket activation in this way. Bu
<tkamppeter> rbasak, pitti, we had discussion about starting cupsd and cups-browsed on-demand on mobile devices yesterday on the OpenPrinting Summit.
<tkamppeter> rbasak, pitti, to save some memory, battery, resources.
<rbasak> Is there a general Zeroconf story to fix the DNS-SD delay?
<tkamppeter> rbasak, not AFAIK.
<pitti> tkamppeter: yes, I think starting on demand on a mobile device is an acceptable compromise (the first time you want to print you just have to wait a bit)
<pitti> tkamppeter: I just wouldn't do it on a desktop; I think "start cups after one minute or when requested" keeps it out of the boot path, and yet has it ready when you realistically need it
<pitti> I guess on a mobile phone we actually do want to shut it down after some time, too
<pitti> on a desktop one usually has swap, so if it's not being used, it just gets swapped out
<GridCube> tedg, hello :) can you review https://wiki.ubuntu.com/GridCube/HUD_in_Xubuntu_Rationale please?
 * tedg clicks
<GridCube> :D thanks
<tedg> GridCube, Looks good to me!
<GridCube> :) excellent
<GridCube> by the way, could you consider joining the vUDS tomorrow at 20hs UTC to follow https://blueprints.launchpad.net/xubuntu-desktop/+spec/client-xubuntu-1305-software
<GridCube> if you cant there its no problem, but i do think you could bring some interesting help in the topic, sadly i wont be able to join :(
<ogra_> infinity, do you think it would be possible to build udev against klibc ?
<rsalveti> ev: for grouper it's probably a config issue still, didn't have time to investigate yet, was in vac last week
<roadmr> Hey folks! question about SRU. I have prepared a SRU bug 1059544, added a task for the affected Ubuntu release, and uploaded a branch with a fix. I have upload rights for the package. Should I just merge and upload this to -proposed, or do I need approval from e.g. release team?
<ubottu> bug 1059544 in checkbox (Ubuntu Raring) "checkbox alsa_record_playback should use autoaudiosrc instead of alsasrc" [Undecided,New] https://launchpad.net/bugs/1059544
<ev> rsalveti: *nods*
<rbasak> roadmr: AIUI, you upload -proposed, and then it sits in Unapproved until the SRU team review the upload. But IANAUbuntuDeveloper.
<roadmr> rbasak: thanks! well that makes sense. I'll probably do just that
<stokachu> stgraber: did you get my ping last night?
<stgraber> stokachu: I saw it but I'm rather busy at the moment between UDS and other tasks, will try to take a look later this week.
<stokachu> stgraber: ok thanks
<mpt> ev, how's the error rate recalculation going?
<cjwatson> mlankhorst: https://launchpadlibrarian.net/139941740/buildlog_ubuntu-saucy-amd64.ubiquity_2.15.2_FAILEDTOBUILD.txt.gz - hmm, is this X's fault?
<mlankhorst> cjwatson: seems more like a lack of root on xserver
<cjwatson> Nothing should have changed there ... trying a local build
<mlankhorst> but honestly I have no idea what's going on there :)
<cjwatson> Looks like I can't check properly until the 3FP outage is sorted out
<JordiGH> Is there a clean way to get an upstream Debian git-buildpackage archive and use it to maintain several different releases (the P, Q, and R releases) in a PPA for Ubuntu?
<JordiGH> Something hopefully cleaner than this: https://github.com/dac922/octave-pkg-octave/network
<rbasak> I've decided that gnome-terminal should have messaging indicator support for terminal beeps. Just putting it out there, in case someone wants to implement it :-/
<sarnold> I'd be happy if unity would do something with the URGENT flag..
<dobey> anyone know what the maximum value a digit in the version string of a package can have, with dpkg?
<dobey> rbasak: i don't see how that would belong in the messaging indicator
<rbasak> dobey: for when the thing inside the terminal signals a message with a beep.
<dobey> rbasak: a beep is not a message. a message is a commincation from another person, to the user, in terms of the messaging indicator.
<rbasak> But yeah, it isn't a good fit. Just solves my particular issue with missing irssi notifications.
<dobey> write an irrssi plug-in that puts irssi in the messaging indicator?
<rbasak> I would like to do that, yes.
<rbasak> I'd also like one for mutt.
<rbasak> And the terminal beep covers both cases.
<rbasak> (and it also covers the case when I'm attached to remote screen that's running irssi without having to forward the indicator plugin somehow)
<sarnold> rbasak: you can "this bug affects me" on https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1108348 ... :D
<ubottu> Launchpad bug 1108348 in unity (Ubuntu) "Unity does nothing with URGENT window flag" [Undecided,New]
<rbasak> sarnold: I'm pretty sure I've seen Unity wiggle the icon on the left. But I only occasionally see it continously wiggle until cleared. I never figured out what it was supposed to do.
<sarnold> rbasak: hrm. I've seen something vaguely similar with an update widget thingy, but it surely isn't the URGENT flag that does that, or I'd have seen it thousands of times by now...
<rbasak> I'm not familiar enough with X and window managers to understand this stuff in detail.
<rbasak> My gnome-terminal doesn't even beep audibly. No idea why. Probably some setting somewhere I've inherited from a dozen releases ago.
<sarnold> hehe
<cjwatson> dobey: Er.  9?
<pitti> rbasak: beep?
<cjwatson> dobey: (You may mean something else by "digit" ...)
<pitti> rbasak: it's not supposed to beep around
<cjwatson> dobey: If you mean a numeric part of a version, there's no upper limit
<dobey> cjwatson: i mean i can't use the infinity symbol, and dpkg complains that it's not a "digit" if i use it for the version number
<cjwatson> If you're trying to find a version greater than all other versions, there isn't one
<dobey> cjwatson: so just looking for the next best thing. wasn't sure if it converted it to an int, or kept it as a string, and just complained if it wasn't between 0-9
<cjwatson> dpkg's version comparison algorithm works on strings
<dobey> right. would be great if it treated the infinity character correctly, though
<cjwatson> And digits are only 0-9
<achiang> would a patch to unity-2d that a) adds a performance optimization but b) hides it behind a gconf setting to preserve existing behavior be acceptable for a 12.04 SRU?
<stgraber> achiang: provided very good justification for the added "feature", yes, it's something we may allow
<achiang> stgraber: see r1157 here - https://code.launchpad.net/~unity-2d-team/unity-2d/trunk
<achiang> stgraber: considering unity-2d is meant for low-end devices *and* this feature saves memory... it's very appropriate from my pov
 * sarnold idly notes that Unicode Character 'RIGHT ANGLE' (221F) is greater than 'INFINITY' (221E) ...
<stgraber> achiang: I think that's reasonable assuming you have a reasonably large pool of users who want that feature. Technically this doesn't fit in the standard SRU process but the TB can grant an exception for those.
<achiang> stgraber: i think potential ubuntu for android customers would count as a large pool of users? :)
<stgraber> achiang: agreed
<xnox> achiang: a few performance related only SRU have been pushed into precise, kind of hand-in-hand with hardware enablement story of low-end devices =)
<xnox> and scale-out workloads (well, maybe not for unity ;-) )
<stgraber> achiang: can you send an e-mail to the TB mailing-list about this? kind of in the middle of a meeting now so it'll be the best way to remind me to do a proper review and grant an exception
<doko> slangasek, mailx doesn't support maildir folders
<achiang> stgraber: yes, i can send an email. is there anything else i should do, considering the code is already in unity-2d trunk?
<slangasek> doko: is this in the context of my c-m fixing upload of lsb?
<doko> slangasek, yes
<stgraber> achiang: ideally a bug with a debdiff ready for upload attached to it would help
<achiang> stgraber: ah, ok. sounds good
<slangasek> doko: I was only restoring the previous state of affairs; if you think we should be kicking bsd-mailx out of main and replacing it with mailutils, that's fine with me, but I don't care about it and didn't want to be on the hook for an MIR
<doko> ok
<slangasek> doko: I would rather kick the lsb binary packages out of main than do an MIR for any of this stuff :)
<hallyn> ubuntu@server-f94526fe-8f7f-44df-93d7-710c86eb8927:~$ pull-lp-source lxc raring-updates
<hallyn> pull-lp-source: Error: The source package 'lxc' does not exist in the Ubuntu primary archive in raring-updates
<hallyn> this happens to me both in canonistack instances and my home laptop...  not sure why
<hallyn> oh i see - it shouldn't be there.  but also pull-lp-source lxc raring gives me 0.9.0-0ubuntu3.1
<barry> bdmurray: two questions re: the eof/pyc problem.  could this be related to a missing fsync at some place?  is there any way to identify whether this is happening primarily on laptops/mobiles or always-on desktops/servers?
<bdmurray> barry: I think we'd could only guess if it is a server based off InstallationMedia in the bug reports
<barry> bdmurray: i just wish we had a way to reproduce it ;/
<bdmurray> barry: maybe look for these types of bugs from ubuntu developers to see if they know more about the system that experienced it?
<bdmurray> or active community members
<barry> bdmurray: it's probably worth a message to ubuntu-devel anyway.  i'll write one to u-d and one to python-dev
<bkerensa> <jono> beer hangout: everyone welcome - https://plus.google.com/hangouts/_/2e35c93b7aca2d5bc4ce8eeaae65aba61ae84205?authuser=0&hl=en
<bdmurray> barry: maybe I should be telling people how to workaround this error since I am looking at all these bugs.  Any tips on what to say?
<mwhudson> eh?
<mwhudson> why is there no linux-tools-$VERSION for armhf in raring?
<mwhudson> https://launchpad.net/ubuntu/+source/linux/3.8.0-19.30/+build/4538742
<mwhudson> ah https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1171580
<ubottu> Launchpad bug 1171580 in linux (Ubuntu Raring) "linux-tools-<ver> not built for armhf" [Medium,In progress]
<mwhudson> ah proposed
<sarnold> barry: re: busted .pyc files, what feels to me more likely than a race condition is an abrupt marshal process death, before it has had an opportunity to flush stdio buffers -- or, not checking an fclose() error return value that might indicate a write error for some edge case internal to the marshaling code..
<mwhudson> how many times does building the python2.7 debian package run test suite??
<doko> one for the static build, one for the shared build, and one for the debug build
<mwhudson> oh ok
<mwhudson> i think i'm on the last one then...
<doko> but you can disable it using DEB_BUILD_OPTIONS=nocheck
#ubuntu-devel 2013-05-16
<stokachu> doko: http://goo.gl/rnQ4y - im having some trouble getting firefox built on raring/saucy and its related to python, any idea on what the error means?
<stokachu> http://pastebin.ubuntu.com/5669324/ thats the bottom of the error log
<stokachu> same build works on precise/quantal
<mwhudson> sigh
<mwhudson> why isn't perf finding my source code..
 * mwhudson learns that cc -ggdb is something different from cc -g
<geofft> -ggdb3! Featuring awesome things like preprocessor macros at the gdb prompt!
<mwhudson> huh
<mwhudson> i don't think perf will use that :)
<swiss> so is this where I could talk about an issue i'm having with a core ubuntu package?
<swiss> or would that be app-devel?
<mfisch> swiss: there's also ubuntu-bugs, but what's the issue?
<mfisch> Logan_: you around? I was updating distribute and wondered about the d/rules change you made in the last version
<swiss> mfisch: gnome-control-center-signin is looking for libraries that don't exist when working with stuff like unity-scope-gdrive
<swiss> i get an error, i straced it, and i can show you exactly where it's hunting. I tried purging and reinstalling all the related packages, but it didn't fix anything
<swiss> I'm assuming it's gnome-control-center-signon, but it might be the unity-scope packages
<swiss> in general I feel like I know what I'm doing when dealing with issues like this, the thing I find interesting is I've done most things to make my system similar to that of a fresh install, yet I still have this issue. And I imagine if others had this issue that the update that broke it (that happened with raring) wouldn't have been released
<Logan_> mfisch: hi
<mfisch> Your best bet is to file a bug on g-c-c-so and attach those straces
<mfisch> swiss: ^^
<swiss> g-c-c-so?
<swiss> oh
<swiss> gnome control etc etc
<swiss> well, i'm not sure if it's that, or signon, or accountsservice, or what :/
<mfisch> Logan_: why did you disable building for 3.2?
<mfisch> swiss: the bug control team can look at it
<swiss> i'm debating a reinstall right now
<mfisch> swiss: send me the bug number and I will look since i'm on bug control
<Logan_> mfisch: it was like that in the past - I was just carrying over the delta
<Logan_> the current Python 3 version is 3.3 in Ubuntu, in any case
<mfisch> yep
<mfisch> the latest debian dropped 2.6 support though
<mfisch> we need 2.7 and 3.3 I believe
<Logan_> oh, that change log entry has a typo
<Logan_> should say 2.6 and 3.2
<mfisch> Logan_: that makes a lot more sense!
<Logan_> could you fix that in a subsequent upload?
<mfisch> okay, so I'll update and keep the 3.2 drop
<Logan_> oh freenode
<mfisch> Logan_: it looks like the python3-sphynx dep was removed upstream so our delta is pretty small
<mfisch> Logan_: what did freenode do?
<Logan_> looks like a semi-netsplit
<mfisch> Logan_: you still here? I was curious about your other changelog comment
<mfisch> Logan_: I cannot find python3-sphinx in the build-deps, but you did remove python3.3-dev
<swiss> so, this is actually a online-accounts-with-unity issue. Is there a unity specific channel?
<mfisch> probably ubuntu-desktop
<swiss> is that a channel?
<swiss> checked, yep
<mfisch> yep
<pitti> Good morning
<dholbach> good morning
<robert_ancell> stgraber, do you know if someone is planning to maintain LTT-ng (source package ust) in Ubuntu? We're looking at taking a dependency on it for Mir, so I'll do a MIR for it. But if someone else is maintaining it I can leave it for them to do. (redirected from tvoss)
<infinity> robert_ancell: You might want to ask the kernel team.  rtg, specifically, seemed to have a keen interest in the kernel side of lttng-tools, the userspace library seems like it would go hand-in-hand.
<robert_ancell> infinity, thanks. What would be the best way to ask them>?
<infinity> robert_ancell: kernel-team mailing list, perhaps, or the #ubuntu-kernel channel.
<robert_ancell> infinity, ta
<seb128> @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: seb128
 * dholbach hugs seb128
 * seb128 hugs dholbach back ;-)
<seb128> does anyone has an opinion on dropping from vsftpd (https://code.launchpad.net/~diddledan/ubuntu/raring/vsftpd/bug-1160372/+merge/162980)? seems like opensuse did it with this rational
<seb128> "Kernel autid system prohibits the processes created with CLONE_NEWPID, so an
<seb128> attempt to log into ftp server ends with
<seb128> audit_log_acct_message() failed: Operation not permitted"
<seb128> vsftp seems to be broken on >= raring atm, but I don't know enough about CLONE_NEWPID to feel like making a call on that
<seb128> jdstrand, mdeslaur, sarnold, chrisccoulson: ^ any security team view on that?
<mdeslaur> seb128: seems reasonable
<seb128> mdeslaur, thanks, will sponsor it then
<seb128> mdeslaur, oh and good morning ;-)
<mdeslaur> seb128: good morning! :)
<sunweaver> dbarth: have you found time to look at the X2Go patches for unity-greeter + remote login?
<sunweaver> dbarth: have you found time to look at the X2Go patches for unity-greeter + remote login?
<sunweaver> dbarth: have you found time to look at the X2Go patches for unity-greeter + remote login?
<hulu> helo
<hulu> the 13.04 livecd create default live user without copy /etc/skel
<hulu> who can help me
<mzaza> If I want to contribute to the brightness and lockscreen in system settings, how should I start?
<pitti> seb128: actually, I had a closer look and the xwiimote patch doesn't even seem necessary; I'll just sync current Debian
<pitti> oh, someone already merged
<pjotr> infinity: you've fixed this bug very quickly (which is great!): 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,Fix released]
<pjotr> But it's tagged for Saucy
<pjotr> does this mean that it won't become available for Raring?
<ogra_> pjotr, follow the SRU guidelines
<ogra_> you need to open a saucy task and get the SRU team to take care
<ogra_> err
<ogra_> a raring task indeed
<infinity> Given that Q/R/S all had the same version, I probably should have just SRUed to Q and copied it forward to everything else.
<infinity> I could still do that.
<pitti> seb128: uploaded a revert
<pjotr> infinity: that would be great!
<dobey> should i file a bug about restart notification in indicator-session against update-manager or indicator-session?
<seb128> pitti, danke
<seb128> pitti, stgraber: can you set https://code.launchpad.net/~diddledan/ubuntu/raring/vsftpd/bug-1160372/+merge/162980 to merged?
<stgraber> seb128: done
<seb128> stgraber, thanks
<jodh> /join #ubuntu-uds-foundations-1
<jodh>  
<jodh>  
<zequence> diwic: I was working on the pulseaudio reserve card patch today. But, I don't understand how to apply it to for instance lp:~ubuntu-audio-dev/pulseaudio/ubuntu.quantal
<diwic> zequence, where are you now? I e, what have you got?
<zequence> I have the patch ready for quantal, and am able to apply and build it against the debian package, but I don't know how to apply it to the bzr branch. Do I just include it in debian/patches?
<zequence> hmm, I forgot to add it debian/patches/series
<diwic> zequence, I usually do "bzr bd-do" "quilt import <patchname>" "exit"
<zequence> ok, I was assuming there was some nifty tool for this :)
<diwic> zequence, preferrably "quilt push -a" after "quilt import" to make sure it applies
<diwic> zequence, then update debian/changelog (with dch or dch -i)
<diwic> zequence, bzr add debian/patches/*
<zequence> diwic: Great, thanks. I'll give it a go
<diwic> zequence, bzr commit, bzr push
<psusi> how do you do that thing where you flag a wiki page as broken/needs help?  It doesn't seem to be mentioned in the help page.
<ev> mpt: bdmurray and I were talking at the client sprint about how the graph on the bucket page has wild data and seemingly not useful in its current form. I think this is partly because I've made a mistake and our calculation is:
<ev> total instances of the problem across all releases / the number of unique systems seen in a 90 day period for a specific release
<ev> I can fix not including the release in the numerator (by collecting more data), but in thinking about it more, I wonder if the ideal calculation would be the weighted instances of just this problem for a specific release divided by the unique systems seen in a 90 day period for the specific release.
<ev> It's computationally more complex, but if that's going to give the best results then we can always try for it.
<ev> mpt, bdmurray: I also was toying around with the idea of having an instance count view, but I kept pulling myself away from it thinking that it was just papering over the problem with the graph in its current form
<ev> something akin to the left hand toggles on this: http://nvd3.org/ghpages/stackedArea.html
<ev> well, looking more like a toggle
<mpt> ev, if I understand you correctly, the formula for the bucket graph is different from the formula for the front page graph when it should be the same.
<ev> mpt: same with a smaller numerator for the bucket graph, yes
<mpt> yes, and correspondingly smaller scale
<ev> okay, I'll get a bug together for that
<kees> hrm, does nothing clean up /var/lib/ubuntu-release-upgrader/release-upgrade-available after an upgrade?
<bdmurray> barry: do you think it still useful to get more information about these pyc file corruption bugs?
<barry> bdmurray: i think so, yes
<bdmurray> barry: so gathering interpreter, release, and import failure line from them?
<barry> bdmurray: yes, for all three.  if there's a way to figure out the affected imports and upload the pyc files related to them, that would help too]
<bdmurray> barry: Okay, I'll see what I can do
<barry> bdmurray: awesome, thanks
<mfisch> Laney: question on the DMB wiki pages, are the meetings at 15:00 UTC or 14:00UTC, the pages in the wiki disagree on this
<mfisch> seb128: you too on that question to Laney ^^
<seb128> mfisch, I don't know, I'm not on that board, I would trust the fridge calendar I guess ... what time is listed there?
<mlankhorst> oops, forgot to upload wine to the ppa
<mfisch> seb128: 14:00 and 19:00
<mlankhorst> seb128: did you ever sign my gpg key after I gave it to you in london a few months back? :P
 * seb128 looks on his desk, ops
<seb128> mlankhorst, will do tomorrow ;-)
<zequence> diwic: So, I think I might have applied the patch in a useful way to quantal, but there's something different about applying to patches to precise.
<zequence> diwic: edit-patch is not working either, so I'm assuming it's not supporting this type of patch applying
<seb128> stgraber, pitti: can you set https://code.launchpad.net/~pataquets/ubuntu/precise/mumble/mumble-bug-934239/+merge/161105 as merged?
<stgraber> seb128: done
<seb128> stgraber, thanks
<pitti> stgraber is too fast
<stgraber> ;)
<diwic> zequence, I never use "edit-patch", so don't know what this tool can or can't do.
<zequence> diwic: I think it's basically just an automation of some quilt things
<zequence> diwic: quilt doesn't work either
<diwic> zequence, hmm, that's weird, in what way doesn't it work?
<zequence> diwic: I do "bzr bd-do", then "quilt import <mypatch>". The patch is loaded somehow, but I don't see it in debian/patches
<zequence> I can even apply it with "quilt push -a", but still nothing in debian/patches
<diwic> zequence, are you sure QUILT_PATCHES=debian/patches so it doesn't end up somewhere else?
<zequence> diwic: Haven't set that variable up. The patch didn't end up anywhere in the source tree anyway :P. I'll try adding that to .bashrc then
<zequence> diwic: Yep. It started working now
<diwic> zequence, good
<bdmurray> hallyn: your lxc upload in the raring proposed queue in the changelog indicates its patch 0005 but its really 0004.  I'd approve it anyway unless you want to fix it.
<hallyn> bdmurray: oh.  drat, i copied the msg from the saucy pkg
<hallyn> bdmurray: pls go ahead and kick that, and i'll re-push - thanks!
<hallyn> bdmurray: note that we're still waiting for the current lxc in raring-proposed to be promoted to -updates
<bdmurray> hallyn: that's only been in the archive for a day so I was just going to approve yours.  if it was at 6 days I'd wait.
<hallyn> ok, thanks - i've dput'ed with the fixed changelog
<bdmurray> roaksoax: https://bugs.launchpad.net/maas/+bug/1171418 is missing Regression Potential information
<ubottu> Launchpad bug 1171418 in maas (Ubuntu) "MAAS fails to power up machines when trying to install nodes" [High,Confirmed]
<roaksoax> bdmurray: thanks. will take care of it in a bit
<bdmurray> roaksoax: let me know when to rereview it
<roaksoax> bdmurray: done!
<roaksoax> bdmurray: thanks!
<Guest3570> cd
<Guest3570> cd
<infinity> @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: infinity, seb128
<Guest87491> If I want to contribute to the brightness & lockscreen were to go, which source code? Unity or Ubuntu core?
#ubuntu-devel 2013-05-17
<stokachu> cjwatson: would you be able to weigh in on bug 1172101 when you have time
<stokachu> cjwatson: i keep thinking there was a reason why this wasn't done yet
<infinity> stokachu: I believe that should Just Work, since d-i images are built with overwriting turned on, so that'll just overwrite the busybox-provided wget.
<infinity> stokachu: But simple enough to test.  Grab the d-i sources, build your new wget, toss the udeb in extra-udebs, and build d-i to see what you get.
<stokachu> infinity: ah ok, i wasn't sure if there was a political reason for not doing it
<infinity> s/extra-udebs/localudebs/
<stokachu> ill do some tests to make sure it works
<infinity> I can't think of any political reasons against, since we don't include wget in our default images at all.
<stokachu> cool sounds good, thanks man
<infinity> Now, including wget.udeb in the default images would be a different discussion.
<pitti> Good morning
<pitti> xnox: did you see anything odd with the new udev on your setup?
<geser> could someone do a give-back of file-roller on i386 and amd64 please? looks like LP lost track of those builds (no build log available)
<pitti> hmm
<pitti> No builds for 'file-roller' found in the Saucy release - it may have been built in a former release.
<pitti> oh, -proposed
<pitti> geser: done
<geser> thanks
<mlankhorst> does pbuilder allow you to keep the chroot if a build fails, so you can inspect what happens?
<geser> mlankhorst: sort of, you can have a hook which drops you into a shell to investigate
<geser> see /usr/share/doc/pbuilder/examples/C10shell
<mlankhorst> ah
<mlankhorst> cd /tmp/buildd/*/debian/..
<mlankhorst> that's actually quite smart..
<Mirv> mitya57: hi! thanks for the qtchooser sync! I've a plan now for the saucy uploads, see http://pastebin.ubuntu.com/5666894/
<mitya57> Mirv: what does "synced but pkg transition" mean?
<Mirv> mitya57: means that the packaging is in sync with Debian, but Ubuntu has an additional package transition from raring that needs eg Replaces:
<Mirv> since Debian never had 5.0.1
<mitya57> OK, sounds nice. Please subscribe me to the sync requests if you'll be doing any
<Mirv> mitya57: ok, I will, unless some coredev helps me in doing syncs directly
<mitya57> Mirv: by the way, qtdoc is currently useless, as documentation should be built in each module
<mitya57> I'm planning to look at qtbase documentation when I have some time
<Mirv> mitya57: I noticed that it indeed gives quite a skeleton of documentation out
<mitya57> yes, but only a skeleton
<Mirv> so not worth that much, even though with that Qt Creator gets Qt5 documentation topic
<Mirv> there are some examples et cetera
<Mirv> but no API docs
<mitya57> API docs is the most useful thing :)
<geser> infinity: as you are TIL for vim: can I grab the vim merge from you or do you plan to do it yourself?
<tjaalton> the manual partitioner of the installer has no option to resize ntfs volumes?
<tjaalton> saucy installer doesn't seem to recognize win8
<infinity> geser: I'll pick it up.  I'd prefer to retain TIL on it.
<infinity> @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: seb128
<seb128> @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:
<seb128> ups, forgot that yesterday
<Laney> mfisch: pretty sure it's supposed to be 14 & 19 UTC currently
<Laney> tumbleweed: confirm/deny?
<geser> infinity: ok, I just noticed that we probably can drop the delta to add liblaunchpad-integration to the help menu as liblaunchpad-integration got removed since raring
<Laney> ah, came up on the ML
<zequence> diwic: I linked two branches to this bug report https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1163638
<ubottu> Launchpad bug 1163638 in pulseaudio (Ubuntu) "pulseaudio fails to release card to jack" [Undecided,Confirmed]
<zequence> diwic: I've test built them, so they seem to work ok
<zequence> diwic: Would you mind looking at if the patches are well applied?
<zequence> ..and documented
<zequence> lp:~zequence/+junk/pulseaudio.precise
<zequence>  lp:~zequence/+junk/pulseaudio.quantal
<diwic> zequence, ok
<diwic> zequence, have you also tested the result to make sure the handover actually works now?
<zequence> diwic: Only on quantal, and only on a virtual install. I need to do more testing
<zequence> but, initially, it seems to work the way it's supposed to
<diwic> zequence, nitpick: "Let's pulseaudio let go" <- bad wording in changelog
<zequence> Ah, I think I wrote them one too many times :)
<diwic> zequence, also on SRUs I think it's always .x, i e not 1:2.1-0ubuntu5 but 1:2.1-0ubuntu4.1
<diwic> zequence, it's correct in the precise one but not the quantal one
<zequence> ok
<zequence> diwic: If that's all you can think of, then I'll happily redo both branches with those changes then
<diwic> zequence, that and proper testing
<zequence> jack people will be thoroughly happy once the fix is out
<zequence> it's one of the most common problems users face, so should make some channels a lot more silent for a while :)
<diwic> zequence, sounds good :-)
* rajaniemi.freenode.net 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: seb128
<Laney> bad ircd
* Laney 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:
<rbasak> If in Launchpad an Ubuntu package does not have a SF upstream linked as an upstream project, am I supposed to "register" this in Launchpad in order to make upstream bug tracker functionality work properly? Or is there some other way to do it? It's not clear to me whether "registration" in LP is necessary (whatever that means), or there's some other way to "link" the upstream that isn't hosted on LP.
 * rbasak asks in #launchpad
<tumbleweed> you can just put the bug URL in the report, and it'll track it, but it can't be added as a task.
<rbasak> Yeah, but it would be nice to know how to do it "properly". I've left bugs like that before, so it would be nice to learn how to do it right this time round.
<diwic> uhm, I seem to have a directory /home/<user>/.local/share/sounds without execute permissions, so I can't view the directory. This is weird. Any of you running saucy and can do a quick check if you have that too?
<diwic> I have no idea who could have created it
<diwic> i e what program
<geser> diwic: same here: drw-------
<diwic> geser, thanks. Do you have any idea of how one can figure out how it got there? It's causing libcanberra to malfunction
<seb128> diwic, drwxr-xr-x for me
<seb128> created on april 19
<diwic> seb128, any contents in it?
<seb128> no, empty
<geser> my directory got last changed/modified on 2013-05-15
<seb128> diwic, I can confirm, it's getting created on login if it doesn't exist and with the permission rw-
<seb128> diwic, I just tried with a test user, rm it, log in, the directory is created before you start anything
<diwic> seb128, okay, thanks, is there a smart way to figure out what process creates it?
<seb128> diwic, not that I know about
<cjwatson> strace -f or systemtap or something
<seb128> cjwatson, strace what process?
<seb128> something on login create that dir, the goal is to figure out what process something is ;-)
<cjwatson> strace -f the display manager :)
<cjwatson> (not from X ...)
<cjwatson> well, maybe that doesn't work with upstart user sessions
<geser> seb128, diwic: could it be the last upload of gnome-settings-daemon? the diff mentions a "sounds" directory
<cjwatson> something like systemtap should be able to do it, not that I really know how to drive it yet
<seb128> geser, I was looking into that yes
<diwic> geser, thanks, will have a look
<rbasak> The answer was to do the registration. Looks like the upstream project must get an entry in the LP namespace, and then the Ubuntu package can be linked to it and all the nice integration then works.
<seb128> geser, diwic:
<seb128> debian/patches/git_sound_not_polling.patch:+        if (g_mkdir_with_parents(p, 0600) == 0)
<diwic> yep
<seb128> geser, diwic: https://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-6&id=75b8bae1e71199ea7b19769be1c4f423722dffc7
<diwic> that must be it
<seb128> is the commit I backported
<seb128> that bug comment #2 describe the issue
<Laney> s/6/7/ probably
<seb128> seems like they screwed that backport
<seb128> https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/sound/gsd-sound-manager.c?h=gnome-3-6
<seb128> https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/sound/gsd-sound-manager.c?h=gnome-3-8
<seb128> has 700
<seb128> I will upload a fix and report it upstream
<seb128> diwic, do you have a lp bug number for the issue?
<Laney> https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=b97a62f56d7f3187c9ab516c8f3c2aa6785665c6
<Laney> just needs to be push to 3-6 too I guess
<Laney> pushedd
<diwic> seb128, no, I was just testing a new version of PulseAudio and discovered this
<Laney> argh
<seb128> Laney, want to take care of it?
<seb128> Laney, upload/ping upstream?
<diwic> upstream fixed it with https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=b97a62f56d7f3187c9ab516c8f3c2aa6785665c6
<Laney> https://bugzilla.gnome.org/show_bug.cgi?id=694134#c6
<ubottu> Gnome bug 694134 in general "g-s-d sets an inotify watch on ~/.local/share/sounds, which normally does not exist.. and causes polling" [Normal,Resolved: fixed]
<seb128> diwic, Laney snapped you ;-)
<diwic> seb128, Laney thanks for fixing it. The result is otherwise that testing speakers in gnome sound settings does not work.
<seb128> diwic, the sound panel is also unhappy and goes in an infine loop trying to update the timestamp if you try to change a sound effect
<Laney> I can upload that cherry-pick, but perhaps we should take care to fix existing broken ones too?
<seb128> Laney, it's only in saucy for people who didn't have the directory before and it has been in there for less than a week
<seb128> Laney, not sure how many users that set includes ... I guess it wouldn't hurt to add a temporary chmod call to that path in saucy though
<Laney> you could probably do something with g_access/g_chmod without too much difficulty
<Laney> will do it soon
<seb128> right
<seb128> Laney, you are on it then? just ping if you need a peer review or something
<Laney> sure, cheers
<cjwatson> seb128: looks like c2esp could be synced from experimental?
<cjwatson> infinity: would be nice to have a debhelper merge when you get a chance
<seb128> cjwatson, it can yes ... are you syncing it or should I?
<cjwatson> seb128: doesn't really matter I guess, doing now
<seb128> cjwatson, right, I just didn't want to dup the action, thanks ;-)
<seb128> well I guess whoever would have tried second would just have got a "nothing to sync"
<Laney> diwic: uploaded gnome-settings-daemon, thanks for reporting!
<seb128> tsdgeos, hey, are you on ubuntu-devel list? tkamppeter emailed it about mupdf/poppler
<lool> seb128, tsdgeos: just a heads up: you might want to followup on the thread for the PDF rendering backend for Touch printing stack that Till just started on -devel; e.g. maintenance wise, quality wise etc.
<lool> seb128: ah I saw you've seen it already
<lool> and pinged tsdgeos :-)
 * lool is so half-an-hour late
<seb128> lool, yeah, thanks, I'm planning also to follow with "do we have any benchmark showing the performance difference?", because so far it seems it's marketing speech from upstream without facts check
<lool> seb128: you mean the lightweightness claims?  yeah
<lool> I wonder whether we could throw a bunch of PDFs at both and compare rendering too
<lool> (or crashes  :-)
<diwic> Laney, thanks for the swift handling :-)
<zyga> hi, is jockey supposed to work with precise and -lts-{quantal,raring} kernel?
<tvoss> pmcgowan, ping
<pmcgowan> hey tvoss
<rbasak> What's the current best practice for the pocket in debian/changelog for an SRU? Eg. precise, precise-proposed or precise-updates? All work now, right?
<cjwatson> I wouldn't use -updates.  Either precise or precise-proposed is fine.  I've been drifting towards the former.
<pitti> rbasak: no, not precise-updates
<pitti> rbasak: as for precise vs precise-proposed, they behave the same now
<rbasak> OK. I'll use just precise then. Thanks!
<rbasak> (precise-proposed always felt a bit wrong as it doesn't actually end up there)
<pitti> strictly speaking it also doesn't land in "precise", but in "precise-updates"; but it eliminates the difference between pre- and post-release uploads, so it's nice
<cjwatson> precise might either refer to the suite (== release pocket) or to the series as a whole, so that part doesn't bother me
<tsdgeos> tkamppeter: why on -devel and not in 	ubuntu-phone ?
<ogra_> or both (since it affects both)
<tsdgeos> lool: tsdgeos_work@xps:/home/tsdgeos/okularfiles/pdf$ ls -l *.pdf | wc -l
<tsdgeos> 1404
<tsdgeos> "is the only free software which allows filling and saving PDF form"
<tsdgeos> oh really?
 * tsdgeos looks at poppler
<tsdgeos> ogra_: can you forward me the original email so i can answer to it? (me was not subscribed to -devel) (me hides)
<ogra_> tsdgeos, done ... its also in the archives on lists.ubuntu.com indeed
<tsdgeos> ogra_: sure, i've read it there
<ogra_> ah
<tsdgeos> but for a proper answer i need the mail on my mail client
<tsdgeos> so headers match, etc
<ogra_> hmm, i forwarded as attachment ... might not help ...
<tsdgeos> let's see :)
<ogra_> bounced now
<ogra_> that should have proper headers
<tsdgeos> ogra_: second forward better, tx
<lool> tsdgeos: this is mainly a convergence topic as printing isn't top priority for touch phones/tablets; -devel seems fine to discuss common topics
<tsdgeos> ok, mail subject is "Ubuntu Touch:" didn't mention much on convergence on the content either
<tkamppeter> tsdgeos, the missing capability of the Ubuntu desktop to fill forms is then probably caused by the GUI frontends, like evince.
<tsdgeos> no clue about evince, in okular we save forms, of course there are bugs, all software has bugs unfortunately :/
<sladen> tkamppeter: I'll reply later.  I've been using mupdf for rendering for the last decade, as it produces better results.  It is GPL, whether that's an issue having it as part of the API used by end-user apps
<tsdgeos> sladen: do you have any hard data for taht other than a feeling?
<tsdgeos> i'd like to see it :-)
<tsdgeos> lol, it's cool how pdf.js tells me that http://www.acquerra.com.au/poppler/img_0.pdf won't prbably work when opening it :D
<sladen> tsdgeos: works for me
<tsdgeos> what works?
<sladen> tsdgeos: http://www.acquerra.com.au/poppler/img_0.pdf  works for me [in Firefox, with pdf.js]
<tsdgeos> you don't get a nice warning at the top?
<tsdgeos> are you on ff21?
<tsdgeos> do you see the 3 ducks on the right?
<sladen> tsdgeos: firefox 20.0+build1-0ubuntu0.12.04.3
<tsdgeos> they problably introduced the warning in ff21
<sladen> tsdgeos: what is the warning about?  PDF-1.7 or duplicate trailers, or something else?
<tsdgeos> sladen: it just says "This document may not be shown properly"
<tsdgeos> which is correct
<stgraber> stokachu: alright, looking at your bugs now, sorry for the delay
<stokachu> stgraber: no worries, thanks for the help
<sladen> tsdgeos: seems the version poppler does equally badly (in a different way)
<tsdgeos> sladen: works fine here, can you get a screenshot?
<sladen> tsdgeos: 0.18.4-1ubuntu3.1  it's old though
<tsdgeos> lol
<sladen> tsdgeos: so you likely will not care
<tsdgeos> no need for a screenshot then
<sladen> ~,
<tkamppeter> tsdgeos, sladen, which PDF library does ff21 use? Poppler, MuPDF, Ghostscript, or did they write their own from scratch?
<tsdgeos> tkamppeter: pdf.js
<tkamppeter> tsdgeos, is this a complete PDF interpreter, not using any external library?
<tsdgeos> well, it's using firefox
<tsdgeos> :D
<tsdgeos> that's a quite big "external library"
<sladen> tkamppeter: $browser.$canvas implementation
<cjwatson> https://mozillalabs.com/en-US/pdfjs/ "without native code assistance"
<tkamppeter> tsdgeos, so the Firefox browser contains a complete PDF interpreter/renderer (at least from version 21 on)?
<tsdgeos> yes
<tsdgeos> it has for a while
<tsdgeos> it's not that good
<tsdgeos> but they know it
<tsdgeos> which is the first step to fixing it
<sladen> no, pdf.js (a bunch of ECMAScript) contains a complete interpreter
<ogra_> how about chromium (given there are plans to switch to it by default now)
<sladen> it simply does   var canvas = document.createElement('canvas');  and then draws into that
<tsdgeos> ogra_: chromium has no pdf rendeer
<ogra_> right
<tsdgeos> chrome has
<tsdgeos> but it's not free soft
<ogra_> can chromium use the external one
<tkamppeter> tsdgeos, and now they think it is reasonably good and so they started to make it be used by default?
<tsdgeos> chromium can use pdf.js
<tsdgeos> after all it's js :D
<ogra_> heh
<sladen> ogra_: fire up pdf.js in Chromium...
<Laney> I wouldn't say we're at the stage of planning to switch to Chromium yet
<tsdgeos> tkamppeter: i don't think it's reasonably good but that's my opinion
<Laney> FWIW
<sladen> ogra_:  chromium-browser http://mozilla.github.io/pdf.js/web/viewer.html
<sladen> ogra_: (and it's faster than in FF)
<psusi> cjwatson: just wanted to make sure you did get the parted merge bundle I sent.. I know you're busy but it's been over a week so I thought I'd check...
<ogra_> sladen, a wet sponge is faster than FF
<barry> bdmurray, ping
<Laney> highvoltage: stgraber: I just noticed that edubuntu has some Xsession.d scripts which look as if they may be crufty, FYI
<stgraber> Laney: ah?
<Laney> maybe, maybe not, but they caught my eye :-)
<Laney> 25edubuntu-menus looks curious
<bdmurray> barry: hey
<stgraber> Laney: is that edubuntu-menus?
<Laney> ya
<cjwatson> psusi: I did, UDS was in that week
<cjwatson> Which means not a lot else happens :)
<stgraber> Laney: right, that package is no longer shipped in Edubuntu and was replaced by edubuntu-menueditor+desktop-profile
<tkamppeter> tsdgeos, about the filled forms see https://bugzilla.gnome.org/show_bug.cgi?id=695615 and bug 1153517.
<barry> bdmurray: hi.  so over in python-dev, we've got some interesting theories about the pyc corruption problem.  question for you.  from the evidence you've seen, are the pyc files permanently corrupted or do they self repair?  i think we're seeing permanent corruptions, such that users have to take active role in fixing things (e.g. remove the .pyc and re-bytecompile it)
<ubottu> Gnome bug 695615 in PDF "evince does not save filled PDF forms" [Critical,Unconfirmed]
<Laney> stgraber: can we remove? :-)
<barry> bdmurray: can you confirm?
<ubottu> bug 1153517 in poppler (Ubuntu) "evince does not save filled PDF forms" [High,Triaged] https://launchpad.net/bugs/1153517
<Laney> I'm simply going through all of the Xsession.d scripts ATM so don't have information like that available (OK, I could have checked ...)
<stgraber> Laney: yep, I just checked, not seeded and no rdepends (just a conflict with ubuntustudio-menu), I'll kill it from the archive now (haven't tried that new power yet ;))
<Laney> phwoar
<bdmurray> barry: yes, from the bugs I've read of the people who've sorted it out they had to do it manually
<Laney> the other edubuntu one in edubuntu-live looks like it could become a job
<barry> bdmurray: okay, thanks.  guido outlined a scenario where the files could be temporarily corrupted, but should self repair.  i think he's on to something, but we still haven't identified the entire problem.  i still think i might have a fix though
<stgraber> Laney: 1 package successfully removed.
<Laney> *archive catches on fire*
<tsdgeos> tkamppeter: i don't do evince development
<tsdgeos> but yeah the fact that we major release old of poppler is not good
<tsdgeos> besides the fact that we still don't use libopenjpeg
<tsdgeos> but i've decided to not fight that battle anymore and accept we don't care about having good supported jpeg2000 rendering in pdf in ubuntu
<seb128> tsdgeos, we would ship new poppler if there was
<seb128> - a reliable release schedule
<tsdgeos> there is
<tsdgeos> there as always been
<seb128> - upstream stopped breaking ABI and changing soname forcing us into transitions
<tsdgeos> we don't break ABI
<seb128> well, you bump sonames
<tsdgeos> it's people that use headers we don't support
<tsdgeos> soname of the internal library
<tsdgeos> noone is supposed to use
<tsdgeos> yet people use them
<seb128> don't make it public then?
<tsdgeos> they are not
<seb128> if it's not supposed to be used
<seb128> they are installed in /usr/lib
<seb128> and the .h are installed
<tsdgeos> you use the --install-xpdf-headers swtich
<seb128> which is an option provided by upstream ;-)
<tsdgeos> that clearly says they are unsupported
<psusi> cjwatson: ok, I figured, just wanted to be sure the mail wasn't lost
<tsdgeos> "Install unsupported xpdf headers."
<tsdgeos> you can't blame us if we change unsupported things
<tsdgeos> can you?
<tsdgeos> well you can
<tsdgeos> but not that i care :D
<seb128> tsdgeos, reality is
<seb128> $ apt-cache rdepends libpoppler28 | wc -l
<seb128> 24
<tsdgeos> seb128: and please don't spread fud about not reliable schedule
<tsdgeos> seb128: as said, that's not our problem
<seb128> tsdgeos, I need to find my old email back, some years ago I emailed about that, and somebody from upstream replied my that poppler was not aligned on GNOME or Ubuntu schedule and have no intention to be
<seb128> so maybe that was that
<tsdgeos> sure
<seb128> schedule is reliable but not working for us
<tsdgeos> we have no intention to align to gnome or ubuntu
<seb128> ok
<tsdgeos> why would we do that stupid thing?
<seb128> so don't complain that we can't ship the current version ;-)
<seb128> because most distros are aligned on those schedules
<seb128> and it would make you have more current versions in distros
<tsdgeos> :D
<tsdgeos> you really believe that?
<seb128> yes
<tsdgeos> you've been working on ubuntu for too much D:
<psusi> aren't we behind by more than one release though?
<seb128> psusi, no
<seb128> current is 0.22 and we have 0.20
<psusi> ahh, ok then
<tsdgeos> seb128: yes you are, 13.04 ships something that was released on October
<tsdgeos> while 0.22 was released on December
<tsdgeos> that seems pretty out of sync to me
<seb128> tsdgeos, where can I find the 0.24 schedule?
<psusi> tsdgeos: that's not that long ago ;)
<tsdgeos> seb128: on the wiki
<seb128> "the wiki"
 * seb128 goes the.wiki.com
<seb128> k, found ity
<seb128> http://freedesktop.org/wiki/Software/poppler
<tsdgeos> also know "as google"
<Nafallo> seb128: wikipedia is likely "the wiki" these days, fwiw :-)
<tsdgeos> "poppler 0.24 schedule"
<seb128> I guess we could go for 0.24 this time
<seb128> do you plan to change your private soname between now and 0.24? (I guess you do)
<tsdgeos> you mean 0.22 and 0.24?
<tsdgeos> sure
<tsdgeos> 0.23.1 already changed it
<psusi> hrm... debian is still on 0.18, even in unstable
<tsdgeos> and we'll be changing it if needed
<Laney> it's probably the most pressing thing causing distros not to want to update as often as they might
<tsdgeos> seb128: can you elaborate on the problem of changing the soname? i mean archlinux gets to use newest poppler release all the time, what's the catch in our side?
<seb128> tsdgeos, we need to rebuild all rdepends to pick the new soname
<seb128> which includes libreoffice
<Laney> perhaps it would be profitable to investigate why people are using private things and try to provide public API?
<seb128> which doesn't build atm in saucy with the current toolchain
<seb128> tsdgeos, so it means we can't even update poppler atm, until we fix libreoffice's build
<seb128> the transition will get stucked otherwise
<tsdgeos> seb128: ok, so we have bigger problems :D
<seb128> well, libreoffice is being worked
<tsdgeos> Laney: well, i'm not going to go out there chasing random people
<seb128> but while that's not solved, I can't update poppler
<tsdgeos> if people feel the need of a stable api we have a nice mailing list where we don't eat people
<tsdgeos> most of times :D
<psusi> I'm confused... are you saying poppler provides two libs, and one is supposed to be internal and subject to frequent abi breakage?
<tsdgeos> we provide 4 libs
<tsdgeos> 3 of those we stable api (qt, glib and purec++ apis)
<tsdgeos> and the internal one use by those 3
<tsdgeos> whose abi/api changes as we see fit
<psusi> I see... and people keep going direct to the internal library eh?  I wonder why...
<seb128> but which is still installed in /usr/lib
<seb128> with a proper soname versioning
<seb128> as a public library
<seb128> and its name is "libpoppler" not libpoppler-private
<tsdgeos> so?
<seb128> so people don't see that it's private
<seb128> it's just like any other library
<psusi> so it's not very obvious that it's private ;)
<tsdgeos> you don't get it's headers unless you agree to install unsupported
<seb128> so they use it
<seb128> well, distro use the configure flag that you provide
<tsdgeos> and btw
<tsdgeos> libpoppler-private-dev
<seb128> you shouldn't provide it if it's not supported
<tsdgeos> ;-)
<tsdgeos> that's the package name
<tsdgeos> in ubuntu
<tsdgeos> tells you something?
<seb128> right, debian did that change recently
<tsdgeos> wonder why ;-)
<seb128> because the upstream naming was not giving the message
<seb128> because you guys don't?
<Laney> it's not all that many packages to be fair
<tsdgeos> because the debian packager is "one of us"
<seb128> Laney, no, but it includes libreoffice :p
<tsdgeos> and he gets it
<tsdgeos> seb128: i can change the library name to
<Laney> I'm talking about if there was a push to get people off the private lib
<seb128> sure, if everybody gets it wrong, blame it on everybody
<tsdgeos> libpopplerprivatedontuseitoryoulldie
<tsdgeos> and people will still use it
<seb128> easier than trying to think if you maybe could help them
<tsdgeos> seb128: i can't help them
<tsdgeos> i have no time to help them
<tsdgeos> so they have to help themselves
<tsdgeos> if they want
<psusi> so bottom line is that the fact that people still use this lib and it breaks abi a lot adds some resistance to keeping up to date on the very latest upstream, but hopefully saucy will get updated once this problem with libreoffice is sorted, right?
<tsdgeos> to keep using headers that change all the time
<tsdgeos> there's not much i can do
<seb128> psusi, to 0.22 yes, because it seems like 0.23 is going to change soname on the way again and we don't want to go through a transition every time that happens during the unstable cycle
<Laney> there's some scary beasts in there like tex though
<seb128> tsdgeos, you shouldn't have provided that unsupported configure option of installing those .h to start
<seb128> but oh well
<tsdgeos> seb128: blame redhat
<seb128> that's done
<tsdgeos> they started poppler
<tsdgeos> not me
<seb128> well, without that we would still have to use xpdf for things I guess
<tsdgeos> besides you distros would have done it anyway
<seb128> which apparently you, as poppler upstream would prefer
<seb128> but yeah, as a distro we prefer using poppler only
<cjwatson> transitions wouldn't be so horrible if not for libreoffice being in there
<tsdgeos> so don't blame me for doing waht you wanted
<tsdgeos> that's kind of nasty
<tsdgeos> but you install the headers!
<tsdgeos> but we would have installed them anyway if you didn't!
<psusi> tsdgeos: I think seb is just lamenting the status quo outloud, rather than really blaming you
<tsdgeos> psusi: well "<seb128> tsdgeos, you shouldn't have provided that unsupported configure option of installing those .h to start"
<tsdgeos> doesn't seem general lamenting :D
<Laney> aaaaaaaaaanyway
<seb128> tsdgeos, I'm just responding to you blaming us for using an option upstream provides :p
<seb128> but yeah, anyway
<Laney> As long as software is using it we don't really have a choice
<tsdgeos> anyway it's friday 6pm
<tsdgeos> bye guys
<seb128> life would be easier if upstream poppler made their private library not-so-private and supported a stabler api for it
<Laney> bonne nuit
<seb128> stgraber, pitti: could you mark https://code.launchpad.net/~jm-leddy/ubuntu/raring/lupin/fix-670096/+merge/162189 merged or rejected (not sure which one is right, it was targetting raring but got uploaded to saucy)
<stgraber> seb128: done
<seb128> stgraber, thanks
<seb128> stgraber, can you put https://code.launchpad.net/~fehwalker/ubuntu/precise/cobbler/lp1001846/+merge/151352 as work in progress?
<stgraber> seb128: done
<seb128> stgraber, thanks
<seb128> one day we should really get that acl issue fixed...
<seb128> stgraber, can you set https://code.launchpad.net/~kentb/ubuntu/raring/ledmon/dell-pcie-ssd-fix_lp1174386/+merge/161696 as merged as well?
<stgraber> done
<seb128> thanks
<stgraber> stokachu: bug 1094319 is missing the SRU paperwork
<ubottu> bug 1094319 in gnome-keyring (Ubuntu Quantal) "p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory" [Undecided,New] https://launchpad.net/bugs/1094319
<stokachu> stgraber: even though thats just a piggyback?
<stokachu> stgraber: i can add it real quick if required
<stgraber> stokachu: yes, every bug listed in the debdiff needs to have a reason why it's being SRUed, a testcase and some risk analysis
<stgraber> stokachu: and that last point will be very important when we're talking about splititng the package and introducing a new binary package post-release
<stokachu> k gimme a minute ill have it updated
<stgraber> (as in, will upgrades from precise => quantal => raring work, did you check that the breaks/replaces/provides are setup properly so we won't get install time file conflicts, ...)
<stokachu> stgraber: ive done the rdepends testing
<stgraber> the current bug report only sounds like an annoyance (spamming the console), so I think the SRU team will want a bit more than that as a reason to introduce a new binary package
<stokachu> stgraber: ive updated the description for the sru
<stokachu> stgraber: as far as I can tell regressions should be minimal
<stokachu> no hardcoded library paths etc
<stgraber> stokachu: diff looks reasonable, test build worked and the binary packages contain what they should, uploaded both packages to the queue
<infinity> *blink*
<infinity> Unity has decided that firefox and pidgin are the same application group.
<infinity> They both show up in the same Alt-` group.
<infinity> Has anyone else seen this madness? :P
<cody-somerville> infinity: I've seen things like that before, yea. One time it even decided one of my windows didn't exist at all anymore even though it clearly was still there.
<stokachu> stgraber: thanks
<straemer> I created a patch for the reddit webapp a while ago that's still in a "needs review" state, would someone be able to review it?
<straemer> Link: https://code.launchpad.net/~straemer/ubuntu/quantal/unity-webapps-reddit/fix-for-1059882/+merge/151347
<straemer> Sorry, my computer crashed there. Did anyone say anything regarding getting my merge request reviewed?
<sarnold> straemer: sorry, no one replied..
<robru> straemer, your MP is based against the ubuntu quantal package, which is incorrect. In order to make a change against quantal, it first needs to be fixed in Saucy and then SRU'd back to raring and then quantal (SRU is an intensive review process to make sure your changes won't break anything). please rebase your MP against lp:unity-webapps-reddit
<straemer> robru: I made the patch long enough ago that quantal would have been the relevant version at the time
<robru> straemer, yikes, sorry to hear that. still, lp:unity-webapps-reddit is where it needs to go to today.
<robru> straemer, actually, even back then it was still a mistake to propose an MP against a packaging branch. at the time you would have wanted to MP into lp:webapps-applications (which was the upstream trunk that housed *all* of the apps), but now they've been separated into individual projects, so lp:unity-webapps-reddit is the correct place today.
#ubuntu-devel 2013-05-18
<robru> straemer, updated it for you: https://code.launchpad.net/~robru/unity-webapps-reddit/lp-1059882/+merge/164559
<straemer> robru, Oh, thanks. I was just about to submit it
<robru> straemer, oh sorry, should have said I was working on it.
<robru> straemer, I set alex-abreu as the reviewer, he's the go-to guy for webapps currently.
<straemer> robru, cool.
<straemer> robru, I got an e-mail saying that the merge is broken. Looks like a public GPG key is missing or something. https://jenkins.qa.ubuntu.com/job/unity-webapps-reddit-saucy-amd64-ci/1/console
<robru> fginther, still around? ^^
<robru> straemer, that's a problem with the build system... there wasn't anything in that change that could have caused this
<cody-somerville> chrisccoulson: thank you! re: lp #1011073 :)
<ubottu> Launchpad bug 1011073 in network-manager-applet (Ubuntu) "NetworkManager submenus sometimes unpopulated" [High,Triaged] https://launchpad.net/bugs/1011073
<hendry> anyone know which IRC channel the Firefox/Chromium is happening upon?
<ScottK> xnox: Did you submit your CMake python multiple include directories patch upstream?
#ubuntu-devel 2013-05-19
<mightyiam> i'm getting an A-level annoyance on desktop. has to do with online accounts facebook i assume. this opens up once in a few minutes! http://picpaste.com/facebook-JOS0682U.png
<mitya57> mightyiam: please file a bug, most developers are not here on sunday
<Laney> It's already filed
<Laney> e.g. https://bugs.launchpad.net/ubuntu/+source/gnome-control-center-signon/+bug/1180297
<ubottu> Launchpad bug 1180297 in gnome-control-center-signon (Ubuntu) "Opening facebook "Success" page in external browser" [Undecided,Confirmed]
<mitya57> and it seems we already have a work-around ready for merge: https://code.launchpad.net/~mardy/account-plugins/facebook-http/+merge/150272
<NikTh> Hello, I'm stuck. :-) Newbie to the ubuntu-devel world. Not a programmer, but I want to fix a bug (I reported). I know the fix, but I cannot use the branch to do the changes. Here is the bug #1156306
<ubottu> bug 1156306 in linux (Ubuntu) "Blank screen after resume from suspend - Intel ironlake - i915 - Kernel 3.8.0 - Ubuntu 13.04" [Medium,Triaged] https://launchpad.net/bugs/1156306
<tumbleweed> NikTh: the kernel package is kind of special. They use git, for a start
<NikTh> I'm following of this tutorial : http://developer.ubuntu.com/packaging/html/fixing-a-bug.html and I've stuck to the section "Work on a Fix".
<mitya57> NikTh: I think you should use https://wiki.ubuntu.com/Kernel/Dev/KernelGitGuide instead
<NikTh> mitya57, tumbleweed : Thanks ! I will give it a shot .
<mitya57> (but if you already have a patch, simply attaching it to a bug should help)
<NikTh> I attached the patch to the bug. OK. Now another question: What if I want to upload the kernel patched version to my personal packaging archive ? (PPA). Can I do that ?
<NikTh> My PPA is up and running.. but no packages are in there.. nothing.
<mitya57> NikTh: https://help.launchpad.net/Packaging/PPA/Uploading
<NikTh> What is the usually time for a package to be build onsite (Launchpad) and appearing in a PPA ? (assume the package is linux-image)
<NikTh> .dsc , .diff.gz and source.changes have been uploaded correctly (done, done, done) in Launchpad via dput command. When the package will be available in my PPA ?
<Laney> hmm, I got a conffile prompt to create /etc/init.d/networking
 * Laney files it instead
<tumbleweed> NikTh: you get an e-mail within 5 mins, when the upload is accepted. The build time varies by package - and right now there's a 6 hour queue - https://launchpad.net/builders
<NikTh> I did something wrong.. tumbleweed . LoL. e-mail says "PPA uploads must be for the RELEASE pocket." Rejected !
<NikTh> dmn
<NikTh> Ok, here is the deal. 1) I downloaded the source package , 2) I've made the changes to the code , 3) I 've made the changes to changeslog file (dsc -i) 4)debuild the packages signed with my gpg key
<NikTh> Then used the dput command to upload the source.changes file. What did I miss ?
<NikTh> And the package actually is the linux-image (for raring)
<NikTh> The initial goal here is to upload to my PPA the linux-image patched.
<Laney> NikTh: what's the first line of your debian/changelog?
<Laney> If you have raring-<something> you should change it to just raring (or whatever release you're uploading to).
<NikTh> Laney: This is the first line " linux (3.8.0-21.32ubuntu1) UNRELEASED; urgency=low"
<infinity> NikTh: s/UNRELEASED/raring/
<infinity> NikTh: It may or may not actually build with that version number, mind you.  Have you tested it locally?
<NikTh> infinity: No, I haven't tested it locally. I'm pretty sure for the fix. But this specific package I did not build it locally. Maybe I need to change the version number ?
<NikTh> eg: linux (3.8.0-21-ubuntu1) to linux (3.8.0-21-ubuntu1-ppa1) ?
<infinity> NikTh: Adding more dashes is almost certain to break the kernel's build system. ;)
<infinity> NikTh: 3.8.0-21.32~nikth1 is likely to work vaguely sanely, but it's still worth testbuilding locally.  PPAs are for test-building, they're for distributing.
<infinity> s/are for/aren't for/
<NikTh> Yes but I think I must rename (versioning) the package. This is a must (I thing) to upload correctly in PPA
<infinity> You don't *have* to re-version it, it's just nice to not have something the same as one in the archive.
<infinity> Like I said, 3.8.0-21.32~nikth1 should work, but please test locally.
<NikTh> infinity: Ok, I will test it and I will use the 3.8.0-21.32~nikth1 as you said.
<NikTh> Thanks
<cjwatson> mdeslaur,SpamapS: you two changed php5 last; do you think you could merge it?  it's part of a library transition (libgd2 -> libgd3), and I also don't desperately want to be touched-it-last for php5 ;-)
<cjwatson> Oh, and it's part of the libsnmp15 -> libsnmp30 transition too, so two reasons to get it sorted out ASAP
<mdeslaur> cjwatson: sure, I'll do it
<cjwatson> Thanks
#ubuntu-devel 2014-05-12
<Logan_> siretart: probably as early in the cycle as possible
<mitya57> cjwatson: Thanks, will try to do something.
<pitti> Good morning
<pitti> mapreri: or try on IRC? (ping u-studio)
<pitti> mapreri: and if they don't answer soon, just upload; I can't imagine that this is that important for them, this was mostly from the ancient days of Ubuntu itself
<pitti> erk -- gnome-packagekit provides a transitional update-notifier now --- no!?
 * pitti removes it, but now we have to bump our u-n's version
<dholbach> good morning
<dpm> hi xnox, good morning. When you've got a minute, could you review https://code.launchpad.net/~dpm/reminders-app/fix-1317977-openssl-exception/+merge/219037 ?
<dpm> we're trying to do a release of Reminders with the new design today, and that's the latest branch that needs review before we generate the .click
<ev_> pitti: thanks for adding systemd support to whoopsie!
<pitti> ev: heh, yw; it was the first I stumbled across, so it became my guinea pig :)
<ev> :D
<pitti> xnox: hey Dimitri, how are you?
<pitti> xnox: FYI, I locally fixed the insserv path in update-rc.d (that's the only delta compared to the merge I uploaded to people.c.c on Friday)
<pitti> xnox: did you change anything else since then?
<pitti> xnox: I also uploaded a pure backport of systemd support for invoke-rc.d and service to utopic-proposed, so that the full merge doesn't block the other enablement work
<pitti> (and sent two patches to Debian's sysv-rc for invoke-rc during that)
<pitti> bdmurray: FYI, I uploaded an apport trusty SRU for bug 1282349 and bug 1316841
<ubottu> bug 1282349 in apport (Ubuntu Trusty) "Crashes on invalid/broken core dumps when using "Show details..."" [High,In progress] https://launchpad.net/bugs/1282349
<pitti> seb128: ^ FYI
<ubottu> bug 1316841 in apport (Ubuntu Trusty) "apportcheckresume does not create a duplicate signature" [Undecided,In progress] https://launchpad.net/bugs/1316841
<seb128> pitti, danke!
<pitti> cjwatson: I think https://code.launchpad.net/~jibel/britney/fix_missing_results/+merge/218467 is ready to go now
<pitti> cjwatson: would you be the best person to review this, and have some time for this, or someone else from the release team?
<cjwatson> That'd be me.  I'll have a look shortly, thanks
<pitti> thanks
<cjwatson> pitti: Would it be helpful if I merged your old test suite branch first (TBH I had basically just forgotten about it) or would that just confuse matters at this point?
<cjwatson> pitti: Oh, I didn't merge it because there was still a failing test
<cjwatson> (I guess)
<bulletxt> hi, what can we do to get ExifTool package update from 9.40 (november 2013) to a way more updated one ? Newer version supports plenty of more stuff and cameras. Thanks a lot
<bulletxt> I meant 9.46 sorry (jan 11 2014)
<cjwatson> It's at 9.60 in utopic.  We don't normally do wholesale upstream updates in stable releases.
<cjwatson> See https://wiki.ubuntu.com/StableReleaseUpdates if there are specific fixes that need to be applied to stable releases - but they probably ought to be done by selective backports, not by a wholesale update.
<cjwatson> Or https://wiki.ubuntu.com/UbuntuBackports is possible too.
<bulletxt> ok I guess I should ask for a backport then
<dpm> hi, could someone with experience with licenses help us review an easy MP? It seems xnox is not around today, and we're blocking on this one to do a release for Reminders today, so any help would be welcome: https://code.launchpad.net/~dpm/reminders-app/fix-1317977-openssl-exception/+merge/219037
<dpm> thanks!
<pitti> cjwatson: it would actually help, yes; otherwise we'd need to remove the tests from jibel's branch again and re-apply it to my tests branch
<pitti> cjwatson: yes, there's a failing test; it's not the end of the world, it's just a case I thought of when writing those; but I'm fine with adding an @expectedFailure for now
<cjwatson> pitti: Yeah, please xfail, I don't want to merge something with failing tests in general as it'll cause people to assume the tests are broken and not run them :)
<pitti> cjwatson: pushed
<cjwatson> ta
<pitti> cjwatson: to https://code.launchpad.net/~canonical-platform-qa/britney/tests/+merge/207982
<pitti> cjwatson: sorry for delay; weechat notifications apparently broke, will check after lunch
<Mirv> arm64 porters might be interested in "gcc: internal compiler error: Segmentation fault (program cc1)" in the latest qtbase upload
<Mirv> it did build for trusty with the same patch for all archs, and the previous utopic upload built fine, that's why I did a direct dput this time
<cjwatson> doko: ^-
<doko> Mirv, can you check with gcc-4.9 please?
<Mirv> doko: the way for me to test arm64 would be to use a CI Train landing silo, but there are so few available that I wouldn't want to take one of those for testing as the first option.
<doko> ok
<Mirv> doko: arm64 only anyhow, ppc64el/powerpc seem fine: https://launchpad.net/ubuntu/utopic/+source/qtbase-opensource-src/5.2.1+dfsg-1ubuntu16
<Mirv> I filed bug #1318635 for it
<ubottu> bug 1318635 in gcc (Ubuntu) "qtbase failed to build on arm64 on utopic" [Undecided,New] https://launchpad.net/bugs/1318635
<doko> Mirv, when did you enable pch?
<doko> Mirv, this is something that should not be enabled for package builds, makes debugging compiler bugs nearly impossible
<doko> Mirv, any reason to use the bundled pcre?
<cjwatson> pitti: Thanks, merged that now, so I guess the next step is to rebase jibel's branch on top of that
<cjwatson> We probably shouldn't have two nearly-identical test suites :-)
<Mirv> doko: it was always enabled, but there is an optional no_pch_architectures which currently includes armel, armhf and ia64 (comes from Debian)
<Mirv> doko: I'm not sure if anyone has checked pcre, usually as much of system libraries are used as can be enabled
<Mirv> I'm checking with Debian packagers if they've tried -system-pcre and disabled it for a reason
<pitti> cjwatson: jibel's branch started off from the tests/ branch, so it shuold just merge cleanly
<cjwatson> pitti: It appears to add a slightly different file name, tests/test_autopkgtest.py rather than tests/autopkgtest.py
<cjwatson> pitti: Though perhaps LP isn't rescanning it due to the "Work in progress" status?
<cjwatson> pitti: Can you set this to "Needs review" if it's ready to land?
<pitti> jibel: ^
<pitti> cjwatson: yes, jibel's branch had to rename it to avoid an import name conflict
<pitti> jibel: I think you ought to merge from trunk again, to pick up the exfail
<cjwatson> Ah, if it's just a renaming I'll be fine with that
<pitti> or just bzr merge and look at the diff locally
<pitti> cjwatson: the renaming is already in teh LP MP; this is just missing the @exfail addition
<jibel> pitti, cjwatson I merged from trunk
<cjwatson> Thanks.  I'll meditate on the diff for a while :)
<tsdgeos> tkamppeter: is there any change we can get http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3c4cfba8 in ubuntu packages of gs9.14 ?
<doko> Mirv, this works for me disabling pch, at least on arm64
<bdmurray> pitti: ah, thanks for that. maybe the changelog should reference bug 1316845?
<ubottu> bug 1316845 in apport (Ubuntu) "apportcheckresume does not contain package version" [High,New] https://launchpad.net/bugs/1316845
<pitti> bdmurray: ah, I didn't see a bug ref in the MP; will reupload
<bdmurray> pitti: thanks
<cjwatson> +            i = iter(linebits[3:])
<cjwatson> +            for trigsrc, trigver in zip(i, i):
<cjwatson> jibel: ^- is that meant to be a "take two elements at a time" gadget or something?  It seems rather opaque
<jibel> cjwatson, it is
<cjwatson> jibel: I don't see any reason to suppose that it's well-defined which order zip fetches from the two copies of the same iterator
<pitti> bdmurray: reuploaded
<cjwatson> jibel: You could use the "grouper" recipe from https://docs.python.org/2/library/itertools.html - but perhaps it would be clearer to just pop two at a time the way the previous code did?
<cjwatson> Oh, https://docs.python.org/2/library/functions.html#zip does say the ordering is guaranteed
<cjwatson> Mm, OK
<debfx> ScottK: the bug subscription is missing for the new backports projects
<jibel> cjwatson, I can revert that part if you think it's clearer.
<cjwatson> I don't mind too much now that I've worked through it
<pitti> \o/
<pitti> thanks cjwatson for the review
<pitti> so that means, no propagations of stuff which is known-broken any more?
<pitti> and propagating stuff with broken tests
<pitti> thanks jibel
<wschmidt> xnox: infinity suggested that you might be interested in this:  https://bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1318690
<ubottu> Launchpad bug 1318690 in emacs24 (Ubuntu) "emacs aborts for ppc64el in 14.04" [Undecided,New]
<wschmidt> thanks for any help!
<cjwatson> pitti: Let's hope so :)
<cjwatson> jibel,pitti: I think we might still have tests stuck in RUNNING?  See e.g. apport under sysvinit
<jibel> cjwatson, thanks for your review.
<jibel> cjwatson, we still have tests stuck in 'RUNNING'. That's a problem in the reconciliation of  the results from the new autopkgtest in Utopic. I'm on it
<cjwatson> Right
<hkraal> When having trouble rebuilding my own version of a Ubuntu package where can I drop my question better here or in regular #ubuntu?
<dobey> hkraal: #ubuntu-packaging perhaps
<hkraal> alright, gonna try there, thnx
<ScottK> debfx: Fixed.  Thanks.
<bdmurray> barry: could you add some SRU details to bug 1317660?
<ubottu> bug 1317660 in pexpect (Ubuntu) "[SRU] Bug: AttributeError: 'error' object has no attribute 'errno'" [High,In progress] https://launchpad.net/bugs/1317660
<barry> bdmurray: yep
<bdmurray> barry: thanks, let me know and I'll accept it
<pitti> jodh, xnox: ah, so in bug 1312836 I discovered that we generally don't call update-rc.d to enable rc?.d/ symlinks for init.d scripts when there's a corresponding upstart job
<ubottu> bug 1312836 in ifupdown (Ubuntu) "[systemd] /etc/init.d/networking not enabled" [Undecided,Triaged] https://launchpad.net/bugs/1312836
<pitti> jodh, xnox: in this case, we don't have an S??networking to call /etc/init.d/networking as there's /etc/init/networking.conf
<pitti> jodh, xnox: would upstart try to run /etc/rc*/S??foo if there's an /etc/init/foo.conf?
<pitti> i. e. could we add these init.d symlinks without harm, or would upstart then run both?
<mmazing> does unity in 14.04 still use dbus for the panel icons?
<bdmurray> superm1: Do you want to use bug 1309553 (referenced by a mythbuntu-common uploaded) instead of bug 1290460 for the bytes password issue?
<ubottu> bug 1309553 in mythbuntu-live-autostart (Ubuntu Trusty) "Mythbuntu Installer Crash enabling VNC" [Medium,In progress] https://launchpad.net/bugs/1309553
<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,In progress] https://launchpad.net/bugs/1290460
<superm1> bdmurray: either way is fine with me
<bdmurray> rather, than change the upload I'll mark bug 1290460 as a duplicate of the other
<pitti> xnox, jodh: I posted the question on that bug and sub'ed you; probably better to keep the disussion there
<pitti> jibel: ah, shiny colors on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html :)
<pitti> jibel: is the wrong "running" a result of that ordering fix? it seems unlikely as this sohuldn't affect the format or writing of the results files
<pitti> jibel: I uploaded two sysvutils this morning in relatively quick succession and they both triggered half of the world; that might have confused it?
<cjwatson> pitti: 16:05 <jibel> cjwatson, we still have tests stuck in 'RUNNING'. That's a problem in the reconciliation of  the results from the new autopkgtest in Utopic. I'm on it
<pitti> xnox: I did the first testing/followup on bug 1316712
<ubottu> bug 1316712 in plymouth (Ubuntu) "systemd unit support needs testing from -proposed" [Undecided,In progress] https://launchpad.net/bugs/1316712
<cjwatson> jibel: For autopkgtest regression detection, do we carry over history from series to series?
<jibel> cjwatson, no, that was one of the comment from pitti, it must be done manually when opening a new release.
<cjwatson> Might be worth putting that in NewReleaseCycleProcess
<jibel> cjwatson, right, I'll update the wiki
<ogra_> slangasek, do you happen to know why resize2fs just blindly resizes images even though its manpage claims it will not touch underlying partitions ? ... i.e. why does something like http://paste.ubuntu.com/7453165/ work without resizing the physical img ... is that a bug or a feature ?
<slangasek> ogra_: well, you have no partition; if resize2fs knows you're working with a file rather than a partition, why should it refuse to extend it?
<ogra_> dunno, i find the manpage entry confusing then
<ogra_> The resize2fs program does not manipulate the size of partitions.  If you wish to enlarge a filesystem, you must make sure
<ogra_>        you  can expand the size of the underlying partition first.
<ogra_> effectively the img file is a partition in my view
<ogra_> (i mean, it is nice that it works, but it would even be nicer if the manpage would tell me about it :) )
<slangasek> it's not a partition, there's no partitioning
<ogra_> ah, so it recognizes that ? ok
<sergiusens> is it possible to rebuild in a different builder? seeing a weird trace while building on ross https://launchpad.net/ubuntu/+source/nuntium/0.1-0ubuntu2/+build/6002151
<ScottK> sergiusens: retry the build and see if you get lucky.  They only way to reliably do it is to shut down the builder.
<sergiusens> it's already been rebuilt once; failed the same way; seems the gccgo-go tool is crashing
<ScottK> sergiusens: Running on adare.
<barry> bdmurray: https://bugs.launchpad.net/ubuntu/+source/pexpect/+bug/1317660/comments/1
<ubottu> Launchpad bug 1317660 in pexpect (Ubuntu) "[SRU] Bug: AttributeError: 'error' object has no attribute 'errno'" [High,In progress]
<sergiusens> thanks ScottK, sadly it still fails; I wonder how it worked on the first package  build :-/
<ScottK> No idea, but at least you know it's not buildd specific.
<bdmurray> barry: are the files supposed to be attached to the bug or are they part of the upload?
<sergiusens> yeah, no I only need powerpc hw :-)
<infinity> sergiusens: You have access to a porter machine.
<infinity> Doesn't look like gccgo-go has changed in that time either, so I'd guess it's GCC itself that's introduced some new fun.
<infinity> But I'll try building it on the machine where it worked last time for kicks.
<sergiusens> in the last 3 days though?
<sergiusens> it would be surprising if it worked :-)
<infinity> 3 days?  Oh, it really was only 3 days.
<infinity> Weird.
<sergiusens> yeah, it may have worked out of luck, but now I get stuck on proposed (at least that's what I read from excuses)
<infinity> Not a big fan of the idea that that only works sometimes because we're lucky. :P
<sergiusens> well it was the first build ever on powerpc, so it was 50/50 :-)
<barry> bdmurray: d'oh!  attached
<infinity> sergiusens: Built fine on sagari.  So, other than being a much newer machine, the most obvious difference there would be 24G of RAM instead of 2G.  Is it possible that process was OOMing on ross and adare?
<sergiusens> I am seeing that the gccgo-go tool has been stripped which may be the reason I see a panic on panic in the build
<sergiusens> infinity: the stack trace is incomplete to know, but it seems the gccgo-go tool was trying to access/deref some nil pointer
<infinity> sergiusens: Fun.  Well, worth experimenting with some time, but you're unstuck for now.
<sergiusens> thanks, I'll see if I can get better traces from these crashes
<sergiusens> rsalveti: ^^ built fine with more ram btw
<rsalveti> interesting
<infinity> sergiusens: Well, "more RAM" is a guess, it could also be the type of CPU.  Maybe gccgo on ppc is making faulty assumptions about the port baseline and compiling things for POWER7 instead of older CPUs.
<infinity> sergiusens: Though, one would expect a SIGILL in such cases.
<bekks> hi
<bekks> Out of curiousity, I want to know how automated (since I doubt that THAT number of packages is being built manually almost JIT) package building for utopic actually is being managed/done?
<mwhudson> is it the case that the ubuntu and debian packaging of libvirt are very diverged?
<dobey> bekks: what do you mean exactly?
<bekks> I guess building the packages for any new release is being done automagically somehow. The sheer number of package (>30k) would make it impossible to "edit the build instructions manually, compile the package, package it, release it) while utopic isnt event in beta state would take ages.
<bekks> So I assume this is being done automagically, while taking trusty as "base", and automagically "port" the trusty packages to utopic, so further work on them can take place.
<Unit193> bekks: If the package isn't blacklisted and contains no Ubuntu delta, it's sync'd from Debian.
<dobey> right, the base is debian
<bekks> So in first place, the "debian upstream" is taken, automatically adapted to the new release. And all packages containing ubuntu deltas are being built/adapted manually?
<dobey> no, packages that have ubuntu deltas are not automatically synced from debian
<dobey> they are copied from the stable release to the new development release when the new dev archive is opened
<bdmurray> pitti: ltrace version 0.7.3-4ubuntu5.1 is missing from ddebs
<cjwatson> bekks: For the majority of packages, no "adaptation" is needed - the source package from Debian builds without modifications on Ubuntu
<cjwatson> This is indeed rather essential for us being able to scale
<cjwatson> bekks: And we don't rebuild everything from trusty to utopic - if there's no new source package then it isn't rebuilt
<cjwatson> bekks: Our archive (like Debian's) supports having the exact same source+binaries published in more than one place - so for trusty, utopic, etc.  Some rarely-modified packages are published at the same versions all the way back for many releases
<bekks> dobey, cjwatson: thanks for the information :)
<cjwatson> bekks: http://bazaar.launchpad.net/~ubuntu-archive/ubuntu-archive-tools/trunk/view/head:/auto-sync is the top-level script we run every six hours (when not frozen) to copy non-Ubuntu-modified packages from Debian, although of course that relies on a bunch of other infrastructure in Launchpad
#ubuntu-devel 2014-05-13
<mwhudson> https://launchpadlibrarian.net/174134069/buildlog_ubuntu-utopic-arm64.scrub_2.5.2-2_FAILEDTOBUILD.txt.gz <- this just means "pls update config.guess" right?
<infinity> mwhudson: Yep.
<infinity> mwhudson: Fixing.
<mwhudson> infinity: how can i make that happen?
<mwhudson> oh cool
<mwhudson> (not that i'm completely sure this is relevant to me today but it's the end of this branch of the rabbit hole)
<infinity> mwhudson: Fixed in utopic-proposed.
<infinity> Well, soonish.
<mwhudson> infinity: will something that's depwaiting on that automagically try again ?
<mwhudson> eventually
<infinity> mwhudson: Yeah.
<infinity> mwhudson: Though if you identify that something, we can certainly force the issue earlier.
<mwhudson> of course the builds that didn't depwait out failed so eh
<mwhudson> infinity: https://launchpad.net/ubuntu/+source/libguestfs/1:1.26.1-1ubuntu1
<mwhudson> cp: cannot open '/boot/vmlinuz-3.13.0-24-generic' for reading: Permission denied
<mwhudson> this seems like the sort of thing that is well known about guestfs (even i know about it!)
<mwhudson> apw: i presume you're asleep like a sensible person?
<infinity> mwhudson: That's a fundamentally broken thing with that package...
<mwhudson> yeah
<mwhudson> i recall upstream was not very sympathetic to ubuntu's position...
<infinity> mwhudson: Andy and I have spent some time talking about it, but if you have good ideas to make it less stupid before he fixes it, go nuts. :P
<mwhudson> i have no ideas, but running tests that rely on that being readable is not going to work...
<infinity> It's not tests.
<infinity> It's trying to copy the *&!% kernel into its resulting binary.  I think.
<mwhudson> oh
<mwhudson> pff
<infinity> Or maybe I'm tihnking of a different broken package.
<infinity> Anyhow, it's all bad.
<mwhudson> this one is a test i think
<infinity> Well, that's less bad.
<infinity> Err, are you sure?
<infinity> supermin is trying to build a filesystem.
<infinity> And copy the kernel over.
<mwhudson> it's from running make -C /build/buildd/libguestfs-1.26.1/debian/build-python3.4 quickcheck
<mwhudson> i think?
<mwhudson> i might be mis-reading
<infinity> Oh, it might be a check from the POV of libguestfs.  But the bug is in supermin.
<infinity> You could not run that test that uses supermin, but I don't think that really gets you anywhere interesting, if it's meant to be used in conjunction.
<mwhudson> all i was trying to do was install python-guestfs because the openstack install guide said do :-)
<mwhudson> *to
<psusi> infinity, poke ;)
<infinity> psusi: Ow.
 * psusi hands infinity the rubber chicken
<psusi> how's that thar util-linux going?
 * infinity slaps psusi with it, in anticipation of his next question.
<infinity> Guess I should have typed that a bit faster.
<infinity> psusi: It's coming along.  I've enlisted others.
<psusi> lol... ok... any estimates?  half way done or what?
<infinity> No estimates.  It'll happen and it won't miss either upcoming release.
<infinity> Estimates just seem to be an invitation for people to be extra annoying.  But it's being worked on, not forgotten.
<psusi> ok... it's pretty slow going isn't it?
<infinity> I haven't done the "take work time to JFDI" bit yet.  That might be coming soon.
<psusi> *lots* of patches in there
<psusi> did I already ask you this?  what do you think of the /etc/mtab -> /proc/mounts migration?  something we want to do for utopic?
<infinity> psusi: I believe slangasek had strong feelings about why that can't happen.
<infinity> psusi: WRT network filesystems.
<psusi> hasn't debian sorted that all out by now?  they made the migration some time ago now
<infinity> Erm, they did?
<psusi> afaics from upstream, you just need to link the mount helpers against libmount and it takes care of stashing the extra parameters in utab instead
<infinity> Well, we'll cross that bridge when we get to it.  But the "they did?" comment was me looking at a sid chroot.
<infinity> Where, if Debian has "migrated", I would expect to see an /etc/mtab -> /proc/mounts symlink, which isn't there.
<infinity> So, they didn't migrate very hard, if they did. :P
<psusi> hrm... I think the way they did the migration was kind of goofy... its' there in a fresh vm install
<infinity> psusi: Right, so it happens on boot (every boot!) via /lib/init/mount-functions.sh, called by /etc/init.d/checkroot.sh
<psusi> yea.. it should be done in postinst instead
<slangasek> infinity: heh; yes, Debian migrated /etc/mtab to /proc/mounts, without cleaning up the migration bugs.  There's still an open bug report from me against util-linux about this, Debian bug #702935.
<ubottu> Debian bug 702935 in mount "'mount -f' does not update /run/mount/utab" [Serious,Open] http://bugs.debian.org/702935
<infinity> slangasek: Ta.
<slangasek> infinity: so recasting psusi's question as "can we do this migration in Ubuntu that there's currently an open RC bug about in Debian on a package I'm keen to adopt?"... ;)
<infinity> slangasek: Right, I think the way forward is to clean this up in Debian while I'm cleaning up util-linux in general, and then make it work in Ubuntu.
<slangasek> sure
<pitti> Good morning
<Unit193> Howdy.
<Unit193> pitti: I suppose you saw https://lists.debian.org/debian-devel/2014/05/msg00469.html and it's pointless for me to link?
<pitti> Unit193: no, I'm not on d-devel; shim will *not* work with > 204 at the moment
<pitti> that requires quite some work with cgmanager and systemd-shim first
<Unit193> Yes, he stated that in a follow-up. :)
<dholbach> good morning
<tsdgeos> tkamppeter: is there any chance we can get http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=3c4cfba8 into our gs 9.14 packages?
<Mirv> pitti: hey, ubuntuone-credentials autopkgtest is failing for everything and doing a bit of blocking, is there a possibility you could glance at that?
<pitti> Mirv: looks like a missing test dependency at first, yes
<pitti> Mirv: I'll have a look
<Mirv> thank you!
<tkamppeter> tsdgeos, I can do, no problem.
<tsdgeos> tkamppeter: great :)
<pitti> Mirv: meh, ubuntuone-credentials' autopkgtest is rather useless
<pitti> and I can't push to the branch either
<pitti> *grumble*
<pitti> Mirv: yep, the test is right -- the package really is FTBFS (checked in sbuild)
<pitti> Mirv: filed bug 1318947 to track this; checking with adding pkg-config as build dep
<ubottu> bug 1318947 in ubuntuone-credentials (Ubuntu) "FTBFS: Could NOT find PkgConfig" [High,Triaged] https://launchpad.net/bugs/1318947
<Mirv> pitti: ok, good. yeah, I actually suspected that since the phone stuff tends to develop so fast the rarer updated packages start FTBFS:ing at times.
<Mirv> when I was preparing Qt 5.2, I ran into many of such that failed to build even against the archive version
<pitti> so adding pkg-config build dep helps; I'll let this build finish and then propose a merge
<pitti> debian/tests/control is also rather messy, cleaning this up along the way
<pitti> Mirv: https://code.launchpad.net/~pitti/ubuntuone-credentials/fix-ftbfs/+merge/219308
<Mirv> pitti: thanks, I tested it now.
<pitti> Mirv: I tested in sbuild and adt-virt-qemu
<pitti> Mirv: this should also get a ps-jenkins bot approval, right?
<Mirv> pitti: I think it should, still, even if the automerger would be disabled for the component because the CI Train process is used instead.
<Mirv> dbarth is the lander for ubuntuone-credentials
<Mirv> dbarth: https://code.launchpad.net/~pitti/ubuntuone-credentials/fix-ftbfs/+merge/219308 would need to go in
<pitti> oh the days when we could just upload these trivial fixes..
<pitti> :)
<Laney> I still would, and then propose the merge back ;)
<pitti> well, it would be nice if people who can upload the package could also commit to the branch
<caribou> Laney: remember bug 1296755
<ubottu> bug 1296755 in sosreport (Ubuntu Saucy) "sosreport archive /var/lib/maas by default" [Medium,In progress] https://launchpad.net/bugs/1296755
<caribou> Laney: two tasks are for the -backports pocket (one of which is Quantal)
<Laney> caribou: kind of!
<caribou> Laney: I uploaded debdiffs for all tasks, though I think that the Quantal one should be dropped; it is EOL in 3 days
<Laney> I suppose we can let that slide, yeah
<caribou> Laney: well the debdiff is there anyway; I'll resubmit the sponsors & see what the sponsor decides
<Laney> backports aren't handled by the sponsors
<caribou> Laney: well as I understood, it needs to get to saucy first
<Laney> You don't actually need a debdiff for those, assuming the package is identical between saucy and -backports
<caribou> Laney: who does worry about -backports ?
<Laney> the backporters team
<caribou> Laney: ah, ok
<Laney> So it'll get into saucy-proposed, then you say "yes I built/installed/ran this on precise and it works" and a copy gets uploaded to precise-backports
<Laney> No need for a debdiff unless you need changes over saucy
<caribou> Laney: ok, thanks for the details
<Laney> np!
<dbarth> Mirv: ok, i may add it to my silo; almost done with regression testing
<Mirv> dbarth: no need, already taken care of! we needed the packaging fix to unbloc other landings.
<shadeslayer> bdmurray: ping
<shadeslayer> bdmurray: regarding those crashes in kde-telepathy-contactlist, upstream has pushed a fix here http://quickgit.kde.org/?p=ktp-contact-list.git&a=commitdiff&h=d254bb9779ddf186de33e9482c8668d223339bb5&hp=221d08672a932a2b1cbca3e8eaf46c5465f6d63f , do you reckon I should SRU that or just wait for their next point release which I intend to get SRU'd
<shadeslayer> the way that they're triggered is if you have a broken dbus service file for mission-control
<ajnas> hello
<ajnas> anybody out there?
<Ajnas_> helo
<tkamppeter> tsdgeos_, ghostscript 9.14~dfsg-0ubuntu2 with the LCMS patch released.
<tsdgeos_> :)
<shadeslayer> cjwatson: ping
<shadeslayer> cjwatson: could you shed more light on your cdimage stuff + PPA association? Does that mean one could provide ISO's which have certain PPA's enabled? Because Kubuntu was thinking of doing that for 14.10 ( have 2 ISO's , one with regular KDE 4 and one with Plasma 5 + KDE Frameworks 5 )
<shadeslayer> the latter being provided by a PPA
<cjwatson> shadeslayer: I'm not making any promises about how much we can open it up for wider use, because there are resource limits
<shadeslayer> cjwatson: right
<cjwatson> shadeslayer: And, while the livefs parts of your example would be technically handleable by what I'm doing, there are other things involved in building ISO images with PPAs (i.e. the stuff that goes into the pool) that aren't currently on my list to handle
<ogra_> you could just resort to build kubuntu-phone instead ;)
<cjwatson> shadeslayer: so, um, the short answer is "maybe" - but I don't think I can make any promises and it may need somebody who cares about this to roll up their sleeves and get involved with the infrastructure
<cjwatson> also expanding this by very much is likely to end up blocked on prodstack4 (an IS project) due to librarian disk space limitations
<cjwatson> pitti: ubuntu-purchase-service looks like another one of the same species as ubuntuone-credentials?
<pitti> cjwatson: right; I'll do a similar MP
<mapreri> zequence: I sent you an email some days (7?) ago about xscreensaver. do you mind reply or tell me here your opinion about? otherwise I'll go ahead and drop the ubuntu delta
<shadeslayer> cjwatson: ack
<mapreri> pitti: anyhow, looking at the changelog seems like the original different split was needed to gain 5 MB on the CD iso (dapper age), so not really useful now :) (just, fyi)
<pitti> mapreri: right, because we don't install it at all any more
<dobey> Mirv: how about giving the people who actually maintain a project a chance to review an MP before approving it and landing it via CI train?
<pitti> cjwatson: https://code.launchpad.net/~pitti/ubuntu-purchase-service/fix-ftbfs/+merge/219361
<pitti> Mirv: ^ FYI
<dobey> gah
<dobey> pitti: why are you removing allow-stderr?
<Mirv> dobey: it was a packaging only fix that was needed to unblock other packages, and it could be reverted if wanted then later on
<pitti> dobey: as long as these tests don't do anything, they don't need all this noise?
<dobey> pitti: the tests do do things
<Mirv> dobey: but that ^ ubuntu-purchase-service now blocks 3 packages as well, so it'd be nice to get landed too
<pitti> the test is literally just a "set -ex"
<pitti> dobey: no, it's a totally empty script except for a "set -ex"
<dobey> pitti: the tests are run by the build, which can dump stuff to stderr
<dobey> pitti: there's no point in running "make check" and then immediately running "make check" again in the build tree
<pitti> dobey: yes, but the build can do that as much as it wants; the build is *not* a test
<pitti> (in autopkgtest terms)
<pitti> dobey: yes, I agree
<pitti> dobey: the point is, an autopkgtest should check the *installed* package, not the build tree
<pitti> so you don't need to run make check in an autopkgtest in the first place
<dobey> pitti: uh, but it was causing failures before when the build was happening in the autopkgtest, and stderr had things
<pitti> something like "make check-installed", or just a small smoketest calling the binaries, etc.
<pitti> dobey: well, perhaps you had something in debian/tests/run-tests (which, contrary to its name, doesn't do anything)?
<pitti> with set -x being active, any command there would cause stderr
<dobey> i don't think so
<dobey> but whatever, if autopkgtests start failing, this is probably why :)
<pitti> so it's basically the same asa bug 1316416
<ubottu> bug 1316416 in ubuntuone-credentials (Ubuntu) "autopkgtest: does not test installed package" [Undecided,New] https://launchpad.net/bugs/1316416
<pitti> dobey: no, it's not; I tested it locally (also with ubuntuone-credentials)
<pitti> and if they fail because of stderr, that'd be an autopkgtest bug
<dobey> ok
<pitti> dobey: but right now they fail because the pacakge is FTBFS
<pitti> (new qt stack, some build dep dropping pkg-config dependency; I didn't check and it doesn't matter much)
<dobey> an empty run-tests is the only way i've found to make autopkgtests work
<pitti> dobey: well, the way to make an autopkgtest work would be to have a test that checks the installed package :)
<pitti> we already run the tests against the build tree during package build, so that's not that useful to repeat
<dobey> yes, but uploading a new build-dependency doesn't force a rebuild of everything that depends on it
<pitti> aside perhaps from issues like these when the pacakge becomes FTBFS due to changes in the build deps
<dobey> so we have to rebuild in autopkgtests ot catch such breakage
<pitti> dobey: yes, that's correct
<dobey> which sadly apparently doesn't actually block the thing being uploaded from migrating to archive
<dobey> but eh
<pitti> (in some way it's also an abuse as it doesn't scale to the relatively few test machines that we have, but as long as not too many packages do it it's ok)
<pitti> dobey: yeah, that bug got finally fixed yesterday
<pitti> dobey: (not blocking stuff that causes regressions in autopkgtests)
<dobey> yay
<dobey> though now it matters much less for me, because no more u1 client
<pitti> yeah, that was one of the most annoying/critical issues there and rendered the whole thing fairly useless
<dobey> and if i could get beuno go give us proper oauth2 for sso, it would make life all that much better
<beuno> but beuno hates nice things.
<dobey> but it's so webby
<beuno> dobey, I'll throw it into the developer pit next week, so what comes out
<seb128> barry, coming to the upgrade testing call?
<doko> Mirv, I didn't look how much in sync the qt5* packages are compared to Debian. But please could you make sure the symbols files are ok?  The Debian maintainer doesn't want to fix these before 4.9 is the default
<barry> seb128: yes. sorry.  will try to get g+ working
<nandersson> Hi, there seems to be a dependency problem in package samba-common-bin. Package has hard dependency: samba-common (= 2:4.1.6+dfsg-1ubuntu2), but there is already another package released internally with suffix version that breaks that dependency
<nandersson> If dep was (>= .... it would surely work
<nandersson> but as it is (= ... it doesn't
<nandersson> If you run "sudo apt-cache show samba-common-bin | grep Depends" you'll see there are conflicting depends inside the package
<cjwatson> nandersson: In what Ubuntu release, trusty or utopic?
<nandersson> trusty
<nandersson> I get error when realmd tries to install samba-common-bin (and it is strange becuase package is already installed)
<cjwatson> nandersson: There's a samba-common-bin 2:4.1.6+dfsg-1ubuntu2.14.04.1 along with the updated samba-common version, and that Depends: samba-common (= 2:4.1.6+dfsg-1ubuntu2.14.04.1)
<cjwatson> So it looks fine to me.  Check that you don't have held packages or some other issue that's causing apt to hold back some of the upgrade
<nandersson> When I run realm I get "samba-common-bin: Depends: samba-common (= 2:4.1.6+dfsg-1ubuntu2) but 2:4.1.6+dfsg-1ubuntu2.14.04.1 is to be installed
<cjwatson> Right, you're just restating what you said earlier :)
<cjwatson> Try "sudo apt-get dist-upgrade" first and see what that says
<nandersson> ...I have a couple of packages there - I'll try to install them.
<nandersson> :)
<cjwatson> Then "apt-cache policy samba-common-bin" should show 2:4.1.6+dfsg-1ubuntu2.14.04.1 as the candidate version
<nandersson> yes, it does
<nandersson> It looks like it is PackageKit that reports the problem
<nandersson> hrmm...I'll re-roll this one
<kentb> if I want to pull in a bunch of recent security patches for a universe package (openwsman) is it best to open individual bugs for each one or can I incorporate them in one fell swoop?:  https://github.com/Openwsman/openwsman/commits/638b9c8acfa6ded84c94c01e137c61c29d65d62e/src
<kentb> (this is for 14.04)
<mdeslaur> kentb: file a bug, attach a debdiff to it, and then subscribe ubuntu-security-sponsors
<mdeslaur> kentb: you can do them all in the same bug
<kentb> mdeslaur, ok
<kentb> cool. thanks!
<mdeslaur> np
<OdyX> tkamppeter: Did you see Debian's #748028 ? You probably want to fix that in cups-filters' upstream.
<arges> tkamppeter: hi. can you add an SRU template to bug 1315864, so I can approve hplip? thanks
<ubottu> bug 1315864 in hplip (Ubuntu Trusty) "HP1510 Not Printing" [Undecided,New] https://launchpad.net/bugs/1315864
<tkamppeter> arges, the SRU is not needed as separate SRU, as this problem was introduced to Trusty by the SRU of bug 1311697. There I have already announced that the SRU is broken and should not be tested and uploaded a corrected SRU package. So please approve that corrected package (hplip 3.14.3-0ubuntu3.2) into -proposed.
<ubottu> bug 1311697 in hplip (Ubuntu Trusty) "HP Officejet Pro K550 should use hpijs by default" [Low,In progress] https://launchpad.net/bugs/1311697
<arges> tkamppeter: well the changlog indicates that it fixes both of those bugs 1315864 and 1311697, so does the changelog need to be corrected?
<ubottu> bug 1315864 in hplip (Ubuntu) "HP1510 Not Printing" [Undecided,Fix released] https://launchpad.net/bugs/1315864
<sil2100> dobey: hi! Could you take a look at this merge? It will fix some of the problems in the -proposed pocket: https://code.launchpad.net/~pitti/ubuntu-purchase-service/fix-ftbfs/+merge/219361
<dobey> sil2100: done
<sil2100> dobey: that was fast! Thanks
<zequence> mapreri: I missed that mail. I'll have a look at it.
<Saviq> xnox, just posted a current upstart assert in libnih: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1319083
<ubottu> Error: launchpad bug 1319083 not found
<Saviq> (still private)
<dobey> slangasek: is https://bugs.launchpad.net/ubuntuone-storage-protocol/+bug/1307549/comments/2 acceptable as a test case? i'm not sure of a particularly good general test case for that though, "install current version and ensure ubuntuone-client connects to the server, install new version and ensure ubuntuone-client still can connect to the server" will work but doesn't point out a specific failure (as deployement of new cert on 
<ubottu> Launchpad 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]
<tkamppeter> OdyX, for me this builds without warnings or errors on my 64-bit Ubuntu Trusty system, but anyway it is not correct to have two different types here. I will correct pdf.h to size_t to have them both the same. Thanks for the report.
<tkamppeter> arges, this is because I have fixed it in Utopic first and then copied the changelog to the Trusty fix.
<mapreri> zequence: thanks
<arges> tkamppeter: ok. so trusty never had the problems shown in 1315864 since that package never made it past -proposed. So sounds like that bug should be removed from the changelog for the trusty upload.
<tkamppeter> OdyX, cups-filters fixed upstream in BZR rev. 7203, which will make part of 1.0.54. How urgent is the fix, should I release 1.0.54 quickly?
<OdyX> tkamppeter: no, doesn't seem to urgent. Pointing the bug to the fix would be nice though.
<tkamppeter> arges, how to proceed then? Should I reupload with the wrong bug number removed (then you would need to reject the current 3.14.3-0ubuntu3.2 to make space for a corrected one) or will you simply put the current one into -proposed?
<tkamppeter> OdyX, I have answered the bug report now.
<bdmurray> ev: is there a design decision behind bug 1319099?
<ubottu> bug 1319099 in apport (Ubuntu) "whoopsie-upload-all does not upload RecoverableProblem reports" [Undecided,New] https://launchpad.net/bugs/1319099
<arges> tkamppeter: do you mind re-uploading with that bug number removed? I'll reject the current one. Thanks!
<ev> bdmurray: commented - not by design
<bdmurray> ev: thanks
<ev> sure thing
<ev> bdmurray: don't know if you saw, but Chipaca landed the imei code
<tkamppeter> arges, no problem.
<bdmurray> ev: no, thanks for that. How does recoverable_problem get called? Is it by an individual package?
<tkamppeter> arges, package is corrected and re-uploaded now.
<ev> bdmurray: as in generating a recoverable problem using that program? Yeah, any software can call it and feed report data over stdin
<ev> ted has simplified this recently by adding support for it in libwhoopsie
<ev> it's like we have a developer community for the error tracker :D
<arges> tkamppeter: great! I'll review it when I see it in the queue.
 * ted needs to finish the test for thatâ¦
<ted> bdmurray, The code in that MR is used by a few projects already. You could look at url-dispatcher to see how it does it.
<ted> bdmurray, We file a recoverable error on programs that send us bad URLs.
<ted> (well, except for click packages. Someday. Someday.)
<bdmurray> ted: I'd guess the whoopsie change needs fixing for bug 1316763.
<ubottu> bug 1316763 in Daisy "bucketing of recoverable problems is done poorly" [Undecided,New] https://launchpad.net/bugs/1316763
<ted> bdmurray, I'm not sure if that's wrong or right. Sometimes we want to see a problem across programs.
<ted> bdmurray, I'd say it's displayed wrong though :-)
<nandersson> Happy 1400000000 everyone!
<nandersson> http://coolepochcountdown.com/
<Unit193> Wow.
<dobey> how is that a countdown?
<nandersson> :D yeah
<nandersson> should be a countup
<ogra_> nitpickers
<dobey> whoever owns that site should make it use a 32-bit int and make it an actual countdown to the end of time in 2038
<dobey> and then have it restart at 0, like it's 1970 all over again, just like the mayan calander crushed our hopes and dreams
<nandersson> haha :D Yeah, lots of people trying to solve the 2038-bug
<dobey> i really just wanted to watch the chaos of the end of civilization in 2012. but alas. c'est la vie.
<bdmurray> how can I manually set a hostname on a phablet?
<bdmurray> I want to add something to /etc/hosts and its read-only
<popey> bdmurray: interesting, i set the hostname on mine
<bdmurray> popey: well its not really the devices hostname rather I want to map daisy.staging.ubuntu.com to a different ip
<popey> oh â¹
<popey> seems that might be a candidate for being in writable/
<popey> ogra_: ^
<bdmurray> I was going to manually try that but its read-only too :-(
<ogra_> hmm
<bdmurray> I mean /etc/system-image/writable-paths is read-only
<ogra_> yeah, thats on purpose
<ogra_> you would have to add the entry to the lxc-android-package ...
<bdmurray> ogra_: do you have any other ideas?
<ogra_> well, that would be the proper way ...
<ogra_> for a quick hack: mouont -o remount,rw / ... make your changes ... mount -o remount,ro /
<dobey> slangasek: btw, i see you accepted the ubuntuone-client into precise-proposed. can you also accept the one for saucy-proposed?
<michagogo|cloud> If anyone who knows how to do Ubuntu packaging etc. has a few minutes and wants to do something small, Bug #1314616 would be a good choice.
<ubottu> bug 1314616 in bitcoin (Ubuntu) "Replace the package "bitcoin" with an empty dummy package" [Undecided,New] https://launchpad.net/bugs/1314616
<sladen> michagogo|cloud: we'd probably prefer to follow whatever solution is made in Debian
<sladen> michagogo|cloud: and so keep it upstream where possible
<sladen> michagogo|cloud: there may also be better ways of solving the issue (a dummy package is one option; but there might be other solutions too)
<michagogo|cloud> sladen: debian solves it by keeping the software in unstable only, where it can be updated
<michagogo|cloud> In fact, the bitcoin package was already removed and blacklisted from syncing starting in trusty
<ogra_> sladen, there was a related mailing list discussion on ubuntu-devel-discuss
<ogra_> upstream asked for this ... packages will be maintained in a PPA by them instead
<michagogo|cloud> sladen: Did you read the discussion I linked?
<michagogo|cloud> (in the bug)
<michagogo|cloud> ogra_: hm, was there a discussion on that ML? Got a link (or a date)?
<michagogo|cloud> Also, the PPA has been around, maintained, and recommended for a long time
<michagogo|cloud> But we still occasionally get people in #bitcoin trying to run 0.3.24 :-/
 * sladen adds some high-level context
<hjd> Hm... I saw that elementary failed to build on http://qa.ubuntuwire.com/ftbfs/, because it waits for libemotion-dev. That belongs to this source package (http://packages.qa.debian.org/e/efl.html) which seems to only be in Debian, not Ubuntu.
<hjd> Though I can't find efl on the sync blacklist (http://people.canonical.com/~ubuntu-archive/sync-blacklist.txt) or any other reason why it hasn't been synced. Does anyone know?
<Unit193> Looked at the blacklist, and systemd-ui is on there.  Reason was that we use upstart and systemd unavailabile, which has changed in utopic.
<hallyn> bdmurray: fwiw i'm aware there are a slew of sru's ripe for validation;  i'm hoping to spend time tomorrowm orning going through them (libvirt,cgmanager,kvm,and a kernel one at least)
<Logan_> Unit193: I beat you to it :P
<Logan_> Bug 1318776
<ubottu> bug 1318776 in systemd-ui (Ubuntu) "unblacklist and sync systemd-ui from unstable" [Wishlist,New] https://launchpad.net/bugs/1318776
<Logan_> oh, and I could've answered hjd's question, but s/he left :(
<Unit193> Logan_: Oh dang you!  Stinking snipers everywhere. ;)
<Logan_> literally did it last night, haha
<Logan_> I've been going through the blacklist and finding outdated stuff
<sarnold> Laney: the ubuntu codesearch looks unhappy, "502 Bad Gateway" :(
#ubuntu-devel 2014-05-14
<infinity> hallyn: So, when do I get qemu-system-aarch64, now that it's upstream? ;)
<hallyn> infinity: ?  why don't you have it yet?
<infinity> hallyn: Sorry, I should have specified "with full emulation".
<hallyn> ah
<infinity> hallyn: We have kvm-only right now.
<hallyn> yeah
<hallyn> so it depends how badly you want it i guess :)
<infinity> hallyn: OMG SO BADLY.
<hallyn> clearly my preference would be to wait until it'sin a release,
<hallyn> but i'll happily do buidl with the patchset if you need it
<infinity> hallyn: Nah, I don't *need* it.  Though, if it's undisruptively backportable to 2.0, it would be shiny to have.
<infinity> hallyn: (And if it were isolated enough to be ignorable in a review as obviously not breaking other targets, I'd even consider it for an SRU so the LTS can emulate all the arches we shipped)
<infinity> That might actually be a first, given that qemu-system-ppc was pretty broken until just recently too.
<hallyn> speaking of which has openbios-ppc's mir happened yet?
<hallyn> but anyway i'll see if i can get a reasonable patchset (at ods this week so not sure when i'll get a chance to do it justice)
<infinity> hallyn: People emulating sane systems use qemu-slof, not openbios-ppc.
<infinity> hallyn: (Though that's also in universe, I think)
<infinity> Yeah, it is.
<hallyn> actually taht's the one i meant, yeah
<infinity> We probably should have pulled it into main for trusty and made qemu-system-ppc depend on it, didn't even think about it.
<infinity> Oops.
<infinity> Oh well.  That one extra step of "install slof" isn't a world-ending thing to put on a wiki HOWTO or something.
<hallyn> well i'd hoped tha tthe suggests would suffice, but it doesnt' seem to be reducing the # of bugs :(
<hallyn> yeah maybe i should add it to the community docs
<infinity> hallyn: Oh, you actually get bugs about it?
<hallyn> yeah, suggesting more ppl are trying out qemu-system-ppc in the last few months than... ever
<infinity> hallyn: Yeah, that's actually a positive note, other than the bit where it generates bugs. :P
<infinity> hallyn: So, AFAICT, people who want to emulate ancient Macs need openbios-ppc, people who want to emulate pSeries (ie: newer IBM machines) want qemu-slof.
<infinity> hallyn: I'm less fussed about the first group, but we kinda want the second group to work.
<infinity> hallyn: And, indeed, if we decide to make trusty a viable host for ppc64el KVM guests, we'll need slof too.
<infinity> hallyn: So, we might have to look at a sketchy promotion-to-main-in-updates for that one down the road.
<hallyn> or a fugly in-universe qemu-ppc metapackage that depends on the right things :)
<infinity> Ick.
<hallyn> :)   half-joking
<infinity> I don't think you'll find much (any) resistance from people on the points of SLOF being well-maintained upstream and a worthy candidate for main in general.  It's just the post-release promotion thing that's an unpleasant hack (as we can't/won't change it in release, so it'll be mismatched in release/updates)
<siretart> infinity: when do you think would be a good time to start the libav transition in utopic? https://release.debian.org/transitions/html/libav10.html
<infinity> siretart: yesterday?
<hallyn> is that going back to ffmpeg?
<infinity> siretart: More seriously, check to see if there are any other transitions in progress that you'll heavily overlap with before you start.
<siretart> infinity: ok, so I can certainly upload libav10 to utopic, but I currently don't have the resources and time to push this transition through in both debian and ubuntu. I would definitly need someone to keep an eye and drive that in ubuntu
<hallyn> hm,what're the odds i'll brick my vm byinstalling dh-systemd
<infinity> siretart: And by the looks of britney, I'd say the answer is "no", I don't see any multimedia madness currently.  So this wouldn't be an awful time to try to bang out a libav transition *is* it's going to go smoothly.
<siretart> I'd certainly help out, but I'm not able to actually drive it
<infinity> siretart: Do you know how much of it will be clean rebuilds, how much needs patches for API changes, etc?
<siretart> it's going to be pretty bad
<infinity> siretart: Okay, so, some numbers on what the "pretty bad" is, and if there are already patches in flight for the badness, etc, would be nice before you upload.
<siretart> there have been a lot of API deprecations and many year-old deprecated functions have been dropped
<Unit193> hallyn: Pretty much none, it's a dh helper and that's it.
<siretart> it will also very likely require some removals.
<infinity> siretart: Also, if you write up (or have a reference to) a porting guide that outlines API changes, what's been dropped, what we might want to use instead, etc, others can certainly help.
<hallyn> Unit193: cool, that was my hope
<infinity> siretart: We have people who are pretty good with this sort of thing, but we prefer not to work blind. ;)
<siretart> infinity: you mean such as https://wiki.libav.org/Migration/10 ?
<infinity> siretart: Exactly that, yes.
<siretart> infinity: I've been working on this transition by patching packages since february (no kidding)
<infinity> siretart: So, if you give me a bit of time to rustle up some formal resources for a +1 rotation of people who I know are solid with this sort of thing, between you working on it in Debian, and us working in Ubuntu and pushing patches back, we could probably knock it out quickly.
<siretart> infinity: that would be awesome.
<siretart> infinity: as said, I'm definitly going to assist as good as I can, but realistically, we'd better have someone else driving and coordinating this transition on the ubuntu side
<siretart> infinity: so just let me know when you think it would be a good time to upload it to utopic-proposed
<infinity> siretart: Understood.  Normally, I might be inclined to say "eh, stuff it, we'll just wait until it's done in Debian and sync it all", but if you're trying to get this done before jessie's freeze, a bit of help from us might not hurt. :P
<siretart> absolutely
<siretart> keep in mind that we do have a couple of extra packages in ubuntu that are not being taken care of in debian
 * infinity nods.
<siretart> I guess we should just remove the binaries and hope for the best
<siretart> for some packages, such as mplayer, we might get away with using its internal copy of libavcodec, but that's certainly not going to fly in general
<siretart> infinity: in any case, thanks for your understanding and assistance!
<infinity> siretart: I'm pretty not happy about the idea of a statically linked mplayer.  Is mplayer really no longer libav-compatible? :/
<infinity> siretart: Does this go back to the age-old libav-vs-ffmpeg debate, and mplayer is primarily an ffmpeg project?
<siretart> infinity: if you are truely bored, see the fight I had with raimar here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732159
<ubottu> Debian bug 732159 in ftp.debian.org "RM: mplayer - RoM - unmaintained, RC-buggy, alternatives exist" [Normal,Open]
<siretart> infinity: short story: we both agreed that it would be feasible to get it working with libav if you are willing to compromise on infrequently used features, but nobody could be found to actually make that happen. I am certainly pissed off enough to no longer bother.
<infinity> siretart: *sigh*... Is there any chance _at_all_ of a reconciliation between libav and ffmpeg people and a merge of the codebases?
<siretart> infinity: well, you shall never say never, and there are indeed efforts on both sides, but given the current state of affair, I certainly wouldn't hold my breath
<infinity> :(
<infinity> Why can't we all just get along? :P
<darkxst> infinity, could you upload https://bugs.launchpad.net/ubuntu/+source/gnome-photos/+bug/1319236 (it should be in our packageset but it isnt ;( )?
<ubottu> Launchpad bug 1319236 in gnome-photos (Ubuntu) "support tracker 1.0" [Undecided,New]
<infinity> darkxst: Or, if I can figure out how, I could add it to your packageset.
<darkxst> infinity, that would work too
<infinity> darkxst: I'm running to the store with my roommate.  I'll figure out how to fix it when I get back.
<darkxst> infinity, ok and thanks
<infinity> darkxst: Oh, maybe I can't edit it anyway.  Weird.  I thought the TB could.  Maybe it's only the DMB.
<infinity> That's annoying.
<infinity> stgraber: Halp.
<infinity> darkxst: I give up on doing the right thing.  Just test-building before I sponsor. :P
<darkxst> infinity, ok, I will get the packageset sorted later
<Mirv> doko_: I can take a look. some Qt packages come directly from Debian via autosync, but some have our own changes (and symbols files)
<Mirv> could someone with powers mark https://code.launchpad.net/~israeldahl/ubuntu/utopic/lmms/lmms_1.0.1/+merge/217857 as having been merged (at the latest revision)?
<TheMuso> Mirv: WIll do, that was my fault, forgot to do that after having to work on the package outside of UDD.
<pitti> Good morning
<Mirv> TheMuso: thanks!
<TheMuso> np
<pitti> doko_: btw, bzr-builddeb's test is fixed in debian, just waiting for LP to import it and sync
<pitti> (one of the two remaining things that hold back python-default)
<RAOF> pitti: Would you like to upload colord to experimental at your leisure?
<pitti> RAOF: sure
<RAOF> While I'm waiting on a transition slot.
<pitti> RAOF: do you want to dch -r/debcommit -r or want me to?
<RAOF> pitti: Done so.
<pitti> RAOF: hm, were you missing git push --all? pristine-tar/upstream seems outdated
<RAOF> pitti: Quite possibly; now done.
<pitti> RAOF: ah, all there now; building
<dholbach> good morning
<pitti> RAOF: aaaand uploaded
<mvo> hey dholbach
<dholbach> hey mv
<dholbach> hey mvo
<pitti> mvo, dholbach: guten Morgen!
<mvo> hey pitti, good monring
<dholbach> hey pitti
<dholbach> na Jungs, wie lÃ¤uft's?
<RAOF> pitti: Danke
<nandersson> Hi cjwatson, reported a package problem yesterday with respect to samba-common-bin - looks like it is a bug in the version of PackageKit that trusty comes with.
<nandersson> so, it is not related to apt or packaging, but PackageKit rather :-/
<doko> xnox, are you able to reproduce the unity issue with pch? if yes, a stacktrace of cc1plus would be nice
<darkxst> Laney, a while ago I asked (on devel-permissions list) for gnome-photos to get add to our packageset, did you miss that one?
<Laney> darkxst: maybe
<stgraber> stgraber@castiana:~/data/code/ubuntu-archive/ubuntu-archive-tools$ ./edit-acl add -P ubuntugnome -s gnome-photos -S utopic
<stgraber> Added:
<stgraber> gnome-photos
<stgraber> infinity: ^
<Laney> why infinity?
<Laney> also, I was checking if it was seeded and it's not
<Laney> â desktop-extra
<darkxst> stgraber, Laney, yes it should have gone into desktop-extra!
<Laney> unless you do plan on seeding it in which case it might not be worth the effort to change :-)
<darkxst> Laney, probably not this cycle, its not quite feature complete yet
<stgraber> Laney: I'll move it. I guessed ubuntugnome based on the earlier discussion with infinity but I apparently guessed wrong ;)
<Laney> ah I didn't see any earlier one
<Laney> I think desktop-extra is for the random gnome-y additional bits and ubuntugnome itself for the image
<stgraber> done
<Laney> ty
<Laney> btw, we should make some time at $sprint to look at fixing that script if possible
<Laney> as it's clear that I'm failing to do it on my own
<stgraber> Laney: yeah, we can do that
<stgraber> Laney: I'll add an item for that to the foundations malta agenda so I remember :)
<Laney> great
<Laney> put my name or something so that I can legitimately go away for a bit :P
<stgraber> Laney: "fix the packageset/seed generator (stgraber, Lantey) "
<stgraber> *Laney
 * Laney nod
<darkxst> stgraber, thanks!
<Laney> darkxst: btw codesearch should be back
<Laney> well, as back as it ever was
<darkxst> Laney, great!
<mlankhorst> hm can someone put mesa in utopic? seems to fail on an unrelated autopkgtest, probably because of gnat
<pitti> right, the ada stack is broken in utopic-proposed (and debian unstable), so libgtkada can't work
<pitti> mlankhorst: the release team can override the failure
<mlankhorst> ok
<mlankhorst> is this enough of a ping or should I ask in #ubuntu-release?
<seb128> tjaalton sort of asked earlier
<pitti> Laney: ^ ?
<seb128> well, he asked what was the issue, not to override
<seb128> but overriding it seems fine to me
<mlankhorst> ah goodie :)
<pitti> yes, to me too
<Laney> will look in a min
<pitti> dholbach: we changed the time of the tech board meeting; how can I get http://fridge.ubuntu.com/calendars/ updated?
<dholbach> pitti, https://wiki.ubuntu.com/Fridge/Calendar
<pitti> dholbach: right, I found that, but it doesn't link to a particular google cal, or say how I can update an existing event?
<dholbach> pitti, for the event you're looking at, can you see who created it?
<pitti> ooh, I can click on it on fridge.u.c.
<pitti> https://www.google.com/calendar/render?eid=MXFwcnZuZW5lbWlraDU0ajY0MmhmbGU4NjhfMjAxNDA0MjhUMjAwMDAwWiBqNXE4NW1taTZ1anZqdGlpNXMxbjNsaTVpb0Bn&ctz=Etc/GMT&sf=true&output=xml
<pitti> dholbach: mdz apparently
<pitti> dholbach: so, I'll ask him to update that
<dholbach> pitti, I pinged pleia2 and jose - maybe they have fridge calendar super powers
<dholbach> I have no idea, sorry
<pitti> dholbach: ack, thanks
<jtaylor> is there anything we can do about the incomplete tcl/tk transition in trusty?
<jtaylor> like finishing it up post release or adding new source packages?
<jtaylor> e.g. blt is linked against 8.6 and itcl3 still against 8.5, use them together and boom
<jtaylor> (both libraries so they affect a fair share of applications)
<jtaylor> infinity: you ported blt to 8.6, we still need a 8.5 blt for e.g. skycat
<jtaylor> as the shared library is luckily versioned I would suggest adding a new source package blt8.5 to trusty which builds against 8.5
<doko> jtaylor, can't we just link itcl3 with 8.6?
<jtaylor> doko: yes but then we have to change a whole stack of applications too
<rbasak> jtaylor: thanks for digging into this. Can I suggest a dep8 test too? This would catch the same issue next time I think, right?
<doko> jtaylor, how many?
<jtaylor> doko: direct dependencies about 9
<jtaylor> but some of them look like bases of other stuff
<jtaylor> like plplot
<jtaylor> some apache stuff even
<doko> ugh, ugly package anyway
<jtaylor> rbasak: well looking at build logs would have been enough in this case already :)
<doko> so can we build these in utopic first using 8.6 and then decide what to do?
<jtaylor> one could try
<jtaylor> I tried buildint itcl3 against 8.6 but still didn't get it to work
<jtaylor> don't know why yet
<jtaylor> building blt against 8.5 worked
<jtaylor> I may have forgotten some other library thats still linked against 8.5
<jtaylor> assuming we get utopic to work with 8.6 only, can the fixes be all SRU'd to trusty?
<doko> honestly, that would the right thing to do. but others may disagree ...
<jtaylor> adding new 8.5 would be less invasive
<jtaylor> *packages
<jtaylor> because building is one thing, but actually working is another
<jtaylor> and its too much stuff to test
<mterry> pitti, how do I retry a failed autopkgtest run from proposed-migration?
<pitti> mterry: answering in the distro channel
<psusi> pitti: I was wondering if I could pick your brain for a second on udisks.. I'm trying to have it grab the IO counters for the drive and stash them so it can compare it on the next 10 minute poll and skip the smart update if there has been no IO... but I can't find a "regular" struct somewhere to stuff it in.
<psusi> it looks like all of the structs are auto generated from xml files and their contents is intended to be exported over dbus
<psusi> so how can you store some private data like this, that isn't supposed to go over dbus?
<pitti> psusi:
<pitti> err, I was about to say "hi!"
<pitti> psusi: so you can't put it into one of the private structs like struct _UDisksLinuxDrive?
<psusi> hi ;)
<psusi> hrm... I didn't see that one, let me go look
<psusi> ahh, it's not in a header.. it's defined in udiskslinuxdrive.c
<pitti> right, it's a private struct
<psusi> hrm... I was looking at adding the code to udiskslinuxdriveata.c, which wouldn't have access to that
<pitti> psusi: if you need to access it from someplace else, you need to add some internal API to it, like udisks_linux_drive_{get,set}_whatever
<psusi> hrm... maybe I can find a way to add it to udiskslinuxdrive.c instead... I'll look it over some
<psusi> thanks for the pointer
<pitti> psusi: ah, struct _UDisksLinuxDriveAta then? :-)
<pitti> pretty much every class has its private data struct
 * psusi facepalms
<psusi> it never occured to me that they would be defined in the source instead of the header ;)
<pitti> hehe
<pitti> psusi: that's the standard GObject approach to ensure it stays private and doesn't leak into any headers or PAI
<pitti> API
<pitti> mterry: but yes, those "hash sum mismatches" during apt-get are mighty annoying; we get them very often, I don't really know what that means
<pitti> mvo: ^
<mterry> pitti, :(  I get them occasionally on my own devices, but they go away
<pitti> could it be that apt-get starts with downloading Release, then the publisher runs and pushes out new indexes, and apt catches those new ones in the middle of the update run?
<pitti> I almost never see them on my workstation
<cjwatson> Yes, I believe it's roughly that
<pitti> mterry: yes, I just restart these, and it usually works then
<mvo> pitti: yeah, its this race condition usually
<pitti> cjwatson, mvo: ok, thanks for confirming
<mvo> pitti: there was talk about a "by-hash" fetching to avoid this race condition some time ago we are working on some code in the abi-break branch that might help too, if its a problem for you we can make it (more of) a priority
<pitti> mvo: well, clicking the retry button 10 times a day isn't a big problem for me personaly
<mvo> pitti: well it is
<mvo> pitti: i mean, thats a lot
<pitti> but it creates these "nice sets of "jenkins failed"/"jenkins fixed" things which hold up promotion a bit and annoy people
<mvo> indeed
<pitti> I'm quite sure we can work around this in adt-run somehow, too
<pitti> or in the machinery above, to auto-retry stuff
<pitti> just didn't get to that yet
<pitti> mvo: so in essence, it's really far from easy to fix on the apt-get side, so we should fix it in the layer(s) above? (i. e. wait and auto-retry)
<mvo> pitti: I think we should give it a shoot on the apt side, its annoying too many people for too long already :/
 * mvo puts it on his list
<jibel> pitti, we used to auto-retry these jobs, but the regex to detect the retry condition must have changed with the new autopkgtest. Do you have an example, I'll adjust it.
<pitti> mvo: I mostly wanted to understand why it happesn -- by the logic above, retrying immediatel actualy shoudl work, right?
<mvo> pitti: yes, a retry should fix it. its fetch old-release file, packages and release file gets replaced on the server so new release file, new packages files but apt downloaded the previous one
<pitti> jibel: e. g. http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-upower/13/ARCH=i386,label=adt/console
<pitti> mvo: ok; I wouldn't want to "sleep 1800" in adt-run, but retrying immediately once in adt-run seems fine to me
<pitti> jibel: ^
<pitti> jibel: ah, it was in bin/testbed/run-adt
<cjwatson> pitti: FWIW I applied a similar workaround in launchpad-buildd a little while back
<pitti> cjwatson: ah, with immediate retry?
<cjwatson> pitti: http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/revision/106?compare_revid=104
<pitti> ah, 15 s counts as "immediate", that's fine
<cjwatson> pitti: While I agree with mvo that it's a pain to have to work around this everywhere, in practice I don't think I've seen a single problem in LP builds since I applied that
<pitti> great
<cjwatson> And IIRC your autopkgtest builders are talking to ftpmaster.internal directly?
<cjwatson> So should have basically the same constraints
<pitti> jibel: so, I think it might be best to just apply a similar workaround to adt-run like http://bazaar.launchpad.net/~canonical-launchpad-branches/launchpad-buildd/trunk/revision/106?compare_revid=104
<pitti> cjwatson: yes, they are, to ensure we see (by and large) the same archive as britney
<cjwatson> Right
<cjwatson> Before that I'd had a pretty much daily routine of looking for chrootwait builds
<cjwatson> It got more frequent when we made publisher runs much more frequent last summer
<pitti> jibel, mterry, mvo: ok, filed as bug 1319416
<ubottu> bug 1319416 in autopkgtest (Ubuntu) "Auto-retry on apt-get update failures" [High,Triaged] https://launchpad.net/bugs/1319416
<mterry> pitti, ah nice
<pitti> jibel: that'll be much cheaper than re-running the whole test (as that means to re-build a VM etc.)
<mterry> hallyn, hello!  I'm seeing occasional crashes in cgmanager in Touch when testing my split greeter branches.  But the .crash files don't have usable stacktraces.  Is there a good way to get logs or some such from cgmanager?
<labsin> hi, I have a merge proposal for click. But I'd like to first build a package. How can I build the source from the ppa?
<mterry> I guess it logs to /var/log/upstart already...  seems to be a double free
<mvo> labsin: build the click package? you can just run bzr-buildpackage in the source tree of click
<labsin> mvo, I'll try
<jtaylor> how would one add a new source package to trusty?
<mvo> good luck!
<nandersson> Hi, what package does aptd belong to?
<ogra_> dpkg -S $(which aptd)
<nandersson> ogra_, Thanks!
<nandersson> Bug is filed :) https://bugs.launchpad.net/aptdaemon/+bug/1319454
<ubottu> Launchpad bug 1319454 in Aptdaemon "Dependencies break when dealing with multiple sources" [Undecided,New]
<rbasak> Laney: [flavor name] how about ubuntu-desktop-dev, or ubuntu-desktop-preview?
<rbasak> (no response required)
<Laney> rbasak: thanks, all suggestions are going into the pot ;)
<dobey> can someone *please* accept ubuntuone-client into saucy-proposed?
<cjwatson> doko: The problems you ran into with cancelling builds early should be fixed by the launchpad-buildd that's rolling out now
<doko> \o/
<doko> which reminds me to re-run ruby-moneta locally
<hallyn> mterry: that double free is something we've seen very occasionally before, especially from some of stgraber's build machines.  if you can catch it in a debugger that woudl rock.
<mterry> hallyn, no luck so far  :(
<hallyn> mterry: you'll get more output by adding 'cgmnager_opts=--debug' to /etc/default/cgmanager, but probably not enough to debug it
<mterry> hallyn, I set MALLOC_CHECK_=3 which I *think* is supposed to help prevent the stack from dying?
<hallyn> mterry: so in your case you didn't have any proxies at all right?
<mterry> hallyn, I don't know
<hallyn> mterry: cool, hopefully you can track it down, this oens' been bugging me, and i have nto been able to reproduce
<mterry> hallyn, can you explain the difference between cgroup, cgmanager, and proxies?
<hallyn> mterry: cgmanager allows configuration of cgrousp through a dbus api over a unix socket
<hallyn> mterry: cgproxy is a cgmanager proxy which can run in containers, and only forwards requests along to the host's cgmanager
<hallyn> (the cgamanger mounts the cgroup filesystems privately;  the proxies don't have to)
<mterry> hallyn, I'm debugging some weird race during startup between sessions logging in, registering with logind, and cgmanager.  So I'm a little confused about what is *supposed* to happen vs what is happening sometimes
<hallyn> logind should be sending dbus requests to create your cgroup, then chown it, then move you into it, one cgroup at a time
<xnox> pitti: i haven't done anything else yet. I've chatted with steve, and the next steps are to introduce back dropped init.d scripts from e.g. initscripts package but in a way that don't change anything under e.g. upstart (if init_is_upstart; exit 0/1 as needed as per current debian policy)
<xnox> pitti: after that is done, we should be able to enable insserv & thus drop the guard from dh_installinit and thus start calling update-rc.d for all packages that have init.d scripts.
<xnox> wschmidt: infinity: thanks for the emacs24 bug, will look into it.
<xnox> pitti: or more complete follow-ups from vorlon on the bug you investigated =)
<infinity> xnox: Don't thank me, I just SEPed the bug to you. :P
<infinity> xnox: AFAIK, the correct fix is "apt-get --purge install vim emacs24-"
<xnox> infinity: SEP stands for... ?
<infinity> s/AFAIK/AFAIC/
<infinity> xnox: SEP = Somebody Else's Problem.
<xnox> infinity: ah, that ok =)
<slangasek> xnox: "more complete follow-ups"?  I think I've laid out the necessary steps on this most recent debhelper bug, no?
<xnox> slangasek: yeah, that's the one i meant.
<slangasek> ack
<genii> Is there more current documentation than https://wiki.ubuntu.com/systemd  ?  "Status as at December 2010" doesn't lend much confidence
<sladen> genii: done upstream in systemd
<genii> Hm.
<sladen> genii: done upstream in Debian
<genii> sladen: I think I found it now, thanks.
<xnox> genii: look at history, that page has been edited recently, there is ongoing work in utopic to get systemd support on-par with debian.
<xnox> genii: and match the current user-experience & integration that upstart has reached in ubuntu.
<genii> There seems to be an older doc with a bit of history: https://wiki.debian.org/Debate/initsystem/systemd   and a current one: https://wiki.debian.org/systemd
<xnox> genii: what are you after?
 * genii gets ready to read for a while
<genii> xnox: Basically how to use it, write startup files for it, etc, and how it compares to sysvinit and upstart
<arges> hallyn: if I want to clone and LXC container for another host machine. I assume I copy the rootfs and then do I need to add something else to ensure the container is setup properly?
#ubuntu-devel 2014-05-15
<Netsnipe> hi everyone. anyone seen utlemming or anyone else responsible for the AWS AMIs around?
<pitti> Good morning
<pitti> xnox: ack, thanks; we have that in Steve's bug reply as a reminder
<dholbach> good morning
<didrocks> morning dholbach :)
<dholbach> salut didrocks
<pitti> RAOF: oh dear, I was blaming the new libgphoto2 all along, but it seems the @DEV stuff broke umockdev recording
<pitti> RAOF: and on top of that, @DEV isn't actually written; I'm looking at both
<RAOF> pitti: Huh, for what? I rather thought I'd *used* that feature!
<pitti> RAOF: just FYI in case you try to actually use that with Mir
<RAOF> I, um, *have* used that in Mir.
<pitti> RAOF: if you record several commands (or  more generally, open/close cycles of the device), only the last is kept
<pitti> instead of all of them
<RAOF> Oh. I don't do that.
<RAOF> So wouldn't have noticed.
<pitti> RAOF: but the way how ioctl records work the @DEV was never written to them
<pitti> RAOF: oh, unless  your program never called close() but you just ^Ced it
<RAOF> Ding!
<pitti> which would be with evtest
<pitti> infinity: nice job on bug 1319122!
<ubottu> bug 1319122 in tzdata (Ubuntu Trusty) "tzdata needs expedited SRU for Egypt DST change on May 15" [Undecided,Fix released] https://launchpad.net/bugs/1319122
<pitti> RAOF: hm, still a miracle how it worked with ^C though, as it essentially does the same thing as with close()
<RAOF> pitti: It's also possible that I hand-edited in the @DEV line because I was umockdev-recording with the system-wide binary which didn't yet have the patches.
<pitti> RAOF: ah, that sounds plausible then
<pitti> RAOF: anyway, fixed now, releasing 0.8.2
<infinity> pitti: Yeah, I don't have high hopes that many computers actually got updated in time, but at least we did our best in Debian/Ubuntu.
<pitti> infinity: one thing that's weird is that utopic has the trusty SRU; we can't sync from Debian?
<infinity> pitti: Look again.
<infinity> pitti: I just copied the trusty SRU over as a stopgap while LP caught up with dinstall.  They're in sync now.
<pitti> ah :)
<pitti> thanks
<infinity> pitti: It was just a complete fluke that an Egyptian user popped into #debian-glibc to tell us about it, mind you.  I might suggest that Paul Eggert set up an emergency broadcast list for these rare times when governments go crazy with 0 notice. :P
<pitti> I thought there was some tz-announce@ thingy
<infinity> If there is, no one seems to be on it.
<infinity> There sure is...
<infinity> Oh, but that's just his release announces.
<infinity> I should subscribe to that anyway.
<infinity> But I meant something even lower traffic and higher visibility for "OMG THIS COUNTRY IS CRAAAAZY, UPDATE NOW!"
<pitti> so what was Argentina back then is now Egypt :)
<infinity> In this case, though, thanks to said user, I think we got all the updates out within hours of Paul's release.
<infinity> There, subscribed to tz-announce, at least.
<seb128> hum
<seb128> what's going on with e.u.c?
<seb128> https://errors.ubuntu.com/?period=day looks bugg
<seb128> ev, bdmurray: ^ do you know if there is a known issue?
<seb128> +y
<ev> seb128, bdmurray: that's troubling. Brian, do we have any recent changes to production that could've caused this? I had a look through RT and the daisy and errors trunks, but I don't see anything that landed in the past day or two.
<seb128> ev, I guess Brian is not going to be up before some hours
<ev> yeah
<ev> on first blush it looked like it was only showing package installation crashes, but there's at least one regular crash in there
<seb128> well, default view is the packages you are subscribed to no?
<seb128> it gives me an empty list here
<seb128> (well, now it's stucked on "Loading...")
<seb128> but like if I do trusty reports on 1 day
<seb128> I get "no data to display"
<seb128> https://errors.ubuntu.com/?release=Ubuntu%2014.04&period=day
<ev> https://graphite.engineering.canonical.com/dashboard/#15may-crashes suggests that we are at least capturing the data
<seb128> ev, do you want me to file a report about the issue? against what tracker/component?
<ev> seb128: please, against lp:errors
<ev> I *think* (/hope) at this point that the problem is in the UI layer, not in our data collection
<seb128> ev, https://bugs.launchpad.net/errors/+bug/1319730
<ubottu> Launchpad bug 1319730 in Errors "the current reports are (mostly) empty" [Undecided,New]
<ubilli8> please how do i build a software on ubuntu
<brendand> ubilli8, depends
<ev> seb128: thanks! ^ bdmurray would you mind digging at that when you get a chance? It doesn't appear like we're dropping data on the floor in daisy, but please do confirm in case of I've missed something obvious :)
<brendand> ubilli8, which software
<seb128> ev, bdmurray: thanks for looking at it ;-)
<ubilli8> i want to develop LAMP just like WAMP for windows but i want to know how the ubuntu architecture works to do that and what language to use to write the language
<ubilli8> @<brendand>
<udevbot> Error: "<brendand>" is not a valid command.
<brendand> ubilli8, 'LAMP' is not one piece of software
<ubilli8> yeah something like wamp that holds all the software during installation and manages it. just like wamp
<infinity> ubilli8: Are you referring to http://www.wampserver.com ?
<brendand> ubilli8, so some sort of gui for managing the installation?
<ubilli8> yes do you think it is possible...???
<infinity> ubilli8: Anyhow, I'll throw you a bone.  To replicate that set of packages installed, you want "apt-get install lamp-server^" and "apt-get install phpmyadmin", but this is also a question for #ubuntu, not #ubuntu-devel, this isn't a channel for people who develop using Ubuntu, but for people who develop Ubuntu itself.
<ogra_> xnox, why would you not ship the cmake tools sdk-libs-dev ? cmake itself is shipped there too ... sounds kind of logical to me to ship the needed tools for development in there as well
<ogra_> (i would have asked you in #ubuntu-touch ... but you seem to not be there)
<xnox> ogra_: hm? i explicitly said that they should be shipped in sdk-libs-dev.
 * ogra_ re-reads the mail 
<xnox> ogra_: but since it's a metapackage -> that means in one of the seeded depedencies.
<xnox> ogra_: metapackages should be empty.
<xnox> ogra_: especially those generated from seeds/germinate.
<ogra_> xnox, heh, lol, ignore me ... you said exactly what i meant
<ogra_> i totally misread
<zyga> what is the *correct* way to disable all i18n aspects? so far I'm using LANG= LANGUAGE= LC_ALL=C.UTF-8 but I have no real reference that would say this is correct and minimal, setlocale(3) is not really helping much
<zyga> from what I see, setting LANG=C is insufficient, I get a mixture of translated/localized text, equally insufficient is LC_ALL
<zyga> is there a document that says how l10n is supposed to be initialized and specifically, disabled
<cjwatson> LC_ALL=C
<cjwatson> or LC_ALL=C.UTF-8 if what you actually mean is "disable locale-specific things but let me have UTF-8 character encoding"
<cjwatson> (note, C.UTF-8 is a bit system-specific, but it's always there on Debian and descendants)
<cjwatson> actually, sorry, you must also unset LANGUAGE because LC_ALL doesn't imply that
<zyga> cjwatson: yeah, pure LC_ALL is irrelevant it seems
<cjwatson> but LC_ALL overrides LANG and all of LC_* so you don't need to deal with those separately
<cjwatson> LC_ALL is NOT irrelevant
<zyga> http://paste.ubuntu.com/7467208/
<cjwatson> it's just not quite sufficient
<zyga> LC_ALL=C.UTF-8 pactl list
<cjwatson> LANGUAGE= LC_ALL=C.UTF-8 will be sufficient though
<zyga> right, it doesn't do much effectively though (I get it that it gets respected though I don't understand why it's not overriding LC_MESSAGES
<cjwatson> no, it just doesn't do one specific thing
<zyga> cjwatson: which thing  is that?
<zyga> cjwatson: is LANGUAGE documented anywhere?
<cjwatson> info libc
<cjwatson> LANGUAGE overrides LC_ALL IIRC just for the purpose of the message translation category
<zyga> cjwatson: thanks
<cjwatson> but that's just for gettext; for all other locale categories the master variable is LC_ALL
<zyga> cjwatson: reading the relevant part of the info page
<cjwatson> so for instance collation order for sorting things, case conversions, numeric/monetary/time presentation, etc.
<zyga> cjwatson: hmm, I think there's a bug though still
<zyga> cjwatson: look at gettext(3)
<zyga> cjwatson: LANGUAGE is apparently ignored if locale is "C" but apparently it doesn't know about C.UTF-8 which is for all intents and purpuses just better "C"
<cjwatson> I expect that would be worth fixing in gettext(3), yes
<cjwatson> I suggest filing a bug, I don't work on this stuff :)
 * zyga just verified that C is special cased and C.UTF-8 isn't 
<zyga> cjwatson: yeah, I'll file a bug on that
<zyga> cjwatson: thanks for showing me info libc :)
<cjwatson> yw
<zyga> ara: hey, your office space fixed their internet filters :)
<ara> zyga, no, I just moved back home :D
<infinity> zyga: Can you file a Debian bug against src:eglibc for the lack of special-casing of C.UTF-8 there?
<zyga> infinity: my pleasure
<infinity> zyga: Ta.
<infinity> This is likely a missing piece I need to fix before I start enacting my "C.UTF-8 everywhere" plans.
<hallyn> arges: yes, rsync the rootfs and also copy over the files under $lxcpath/$name, i.e. /var/lib/lxc/u1/config and if it exists .../fstab
<zyga> infinity: :)
<zyga> infinity: I could patch it, should be relatively simple
<infinity> zyga: Yeah, I didn't assume it would be hard, but since you've already gone and found the relevant bit, a bug with a pointer would be awesome, so I don't duplicate the effort next week. ;)
 * infinity wonders if maybe it's about time to try to push C.UTF-8 upstream for glibc 2.20, and puts that on his "talk to aurelien" list for when it's not 5am.
<mlankhorst> ok, uploading lts stack part 1 (all !drivers)
<zyga> gah, reportbug just ate my bug description
<zyga> infinity: sent, I'll give you the number as soon as I get it back
<infinity> Speaking of C.UTF-8, can anyone reproduce https://errors.ubuntu.com/problem/70c1930688440b1818145db3346da61eb39a7ac8 ?
<zyga> infinity: on 14.{04,10}? no
<infinity> zyga: Either.
<infinity> Seems to work fine for me at a python3.4 interactive prompt.  No idea why it's crashing there.
 * infinity shrugs.
<zyga> infinity: I've seen odd locale crashes but typically mid-upgrade or remotely
<zyga> infinity: but software properties
<zyga> wait, could that be add-apt-repository?
<zyga> infinity: might be worth to see on a cloud image, those are usually locale-challenged
<zyga> infinity: debian bug 748215
<ubottu> Debian bug 748215 in src:eglibc "gettext(3) should special case both C and C.UTF-8 wrt LANGUAGE lookup" [Wishlist,Open] http://bugs.debian.org/748215
<infinity> zyga: Ta.
<cjwatson> locale-challenged> they are, but C.UTF-8 is in libc-bin, it should be everywhere
<zyga> cjwatson: true
<zyga> cjwatson: does it need to be generated somehow though, or is it always available?
<infinity> zyga: It's always available.
<infinity> zyga: That's why that crash confuses the heck out of me.
<zyga> infinity: yeah, I can understand that
<infinity> (And why I can't reproduce it in a minimal test case in a barebones chroot...)
<zyga> infinity: I have no idea why it might occurr
<cjwatson> It *is* possible to remove it, but you have to ignore the "you're trying to remove an Essential package, you idiot" prompt
<cjwatson> Maybe somebody did
<zyga> cjwatson: ;-)
<infinity> mvo worked around it by just trapping the error, but it shouldn't error in the first place.
<infinity> cjwatson: A fair few someones...
<zyga> infinity: the random instance I looked at had a freshly installed 14.04 (0 days old)
<zyga> infinity: so I doubt they would remove those packages really
<cjwatson> Unfortunately libc-bin isn't in Dependencies (since it's Essential)
<infinity> Yeah.  Oh well.  Unless someone can reproduce it and tell me how, it'll be one of those things that just annoys me peripherally but I won't do anything about.
<infinity> I doubt anyone would remove libc-bin, but I suppose I could see someone deleting the locale itself.
<infinity> But still, that's a lot of crash reports for something as silly as that that I can't see many people doing.
<cjwatson> "we don't need this bit"
<cjwatson> yeah, as you say
<mvo> right, I'm also quite puzzled by this fwiw
<infinity> We do have a race in locale-gen that I intend to fix, which could actually cause this sort of issue in the middle of a libc6 upgrade, but since fresh installs see it, and I've not SRUed glibc yet, that theory's out the window.
<infinity> Oh, and c.utf-8 is pre-generated in the package anyway.
<infinity> So... I dunno.
<infinity> I shall try to forget it, like so many bad relationships^wbugs passed.
<n4uah> is any one here?
<pitti> xnox: hm, the new sysvinit seems to have broken at least LXC, and that looks real (i. e. not just like a CI machinery quirk)
<xnox> pitti: ouch, i've tested everything extensively.
<xnox> pitti: how/what ?
<pitti> Setting up lxc (1.0.3-0ubuntu3) ...
<pitti> lxc start/running
<pitti> invoke-rc.d: unknown initscript, /etc/init.d/lxc-instance not found.
<pitti> http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-lxc/22/ARCH=i386,label=adt/console
<pitti> or https://jenkins.qa.ubuntu.com/job/utopic-adt-lxc/22/ARCH=i386,label=adt/console for folks without VPN
<xnox> pitti:
<xnox> $ sudo initctl --system status lxc-instance
<xnox> initctl: Unknown parameter: NAME
<xnox> Usage: NAME=name of LXC instance
<pitti> I have a /etc/init/lxc-instance.conf, but not /etc/init.d/lxc-instance
<pitti> +   && initctl status ${SERVICE} 2>/dev/null 1>/dev/null
<pitti> oh, likely due to that?
<pitti> xnox: right, you're ahead of me
<pitti> so apparently status doesn't work for these "template" jobs
<xnox> pitti:  it think it's a bug in lxc postinst, it should not have "dh_installinit --name lxc-instance --no-start -p lxc"
<xnox> pitti: as there is no way to invoke lxc-instance without an instance....
<xnox> pitti: verifying that now.
<xnox> pitti: hm, that is kind of sad. But e.g. initctl show-config still lists lxc-instance.
<pitti> xnox: you (or Debian, not sure) does this instead of a simple [ -e /etc/init/lxc-instance.conf ] to also catch overrides etc.?
<xnox> pitti: yes.
<xnox> pitti: and multiple configuration directories, as we will need in the future.
<xnox> pitti: it's more strict, but more correct at the same time. And e.g. i'll be able to resurrect php upstart job.
<pitti> xnox: so perhaps only check if "LC_ALL=C initctl status $job | grep -q Unknown"?
<pitti> unfortunatley the exit status always seems to be 1
<pitti> i. e. both for the lxc-instance "template" situation and a real unknown job
<xnox> (upstart job added in trusty, with syntax not supported by precise upstart. and at the moment invoke-rc.d tries to use upstart job, instead of the init-script whilst pid1 is still precise-upstart which has no clue about this new job with what it thinks is invalid syntax)
<xnox> pitti: i'll check other template jobs, but for lxc it really should be doing --no-start in it's dh_installinit calls.
<pitti> ah right, it doesn't
<xnox> pitti: at least no pam-systemd should configure in the lxc container just fine, even if one does lxc-attach to it =)
<xnox> pitti: will email people about it, once verified.
<pitti> xnox: nice!
<xnox> s/no/now/
<saiarcot895> Hi, is it possible to disable building ddebs in sbuild? From PPA build logs, there is a line that seems to does this. (dh_strip debug symbol extraction: disabling for PPA build)
<pitti> it can be enabled/disabled by PPA
<pitti> saiarcot895: but that means it's already not happening, i. e. it shoudln't spit out ddebs
<xnox> saiarcot895: or in packaging you can export a variable to make sure pkg binary mangler doesn't create ddebs.
<saiarcot895> pitti: The PPA isn't spitting out ddebs, but sbuild locally is spitting out ddebs. I'm trying to disable that
<pitti> saiarcot895: ah; drop the pkg-create-dbgsym package from it then
<bdmurray> pitti: could you have a look at bug 1318034?
<ubottu> bug 1318034 in Daisy "indicator-sound crashes frequently fail to retrace" [Undecided,New] https://launchpad.net/bugs/1318034
<xnox> saiarcot895: you probably have binary pkg mangler installed.
<xnox> saiarcot895: i have this in my ~?.sbuildrc
<xnox> saiarcot895: $build_environment = { 'NO_PKG_MANGLE' => '1', 'DEB_BUILD_OPTIONS' => 'parallel=12', 'HOME' => '/build/' };
<pitti> bdmurray: yes, will do
<xnox> saiarcot895: you want the NO_PKG_MANGLE => 1 option.
<saiarcot895> xnox: I'll try that
<pitti> that should work too, yes
<xnox> pitti: i uploaded fixed lxc, and i hope in time autopackagetest will migrate both.
<pitti> xnox: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#sysvinit is looking good so far
<pitti> xnox: and I'm glad this stuff is now actually useful, now that britney is fixed :)
<xnox> pitti: looks like that's the only package affected so far. Well at least on my system, didn't check the $world.
<pitti> xnox: so grep -r ^instance /etc/init/* are all potentially affected ones, right?
<xnox> pitti: well & calling invoke-rc.d in their postinst.
<xnox> pitti: for all those that i had on my machine, there are none that called invoke-rc.d.
<xnox> pitti: well none, apart from the now fixed lxc-instance.
<pitti> nice
<xnox> stgraber: i did direct to archive upload of lxc, packaging change only. Not sure if it needs to be committed somewhere else as well.
<pitti> I figure at least to Debian?
<xnox> pitti: packaging appears to be a fork. and in debian --no-start is passed.
<pitti> ah :)
<cjwatson> mvo: Would you mind retargeting your click merges to lp:click/devel?  I've just created that.
<mvo> cjwatson: sure, no problem
<barry> xnox: let's talk about py2
<xnox> barry: > #ubuntu-ci-eng
<xnox> barry: oh, you are not there. I was chatting to ogra_ about it there already.
<barry> xnox: i'm there now
<pitti> xnox: http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-lxc/23/ARCH=i386,label=adt/console crashed with something weird in apt-get update, retrying
<pitti> xnox: but amd64 succeeded
<andrewrk> hey I'm trying to copy a package to my PPA and I'm getting "source contains expired files". what's the deal with that?
<andrewrk> I went spelunking into the superceded section of old libav builds and found one that I want to put into my PPA for precise
<andrewrk> and launchpad won't let me do it
<andrewrk> hmm maybe I should go to #ubuntu-app-devel
<bdmurray> arges: are looking at the trusty SRU queue?
<arges> bdmurray: had a few minutes between a test I was running. sorry if I steps on your toes a bit
<bdmurray> arges: not at all, I was just gonna get started
<arges> bdmurray: ok cool : )
<stgraber> xnox: I'm used to pick it up when changing in the archive, that's fine
<bdmurray> arges: bug 1316125 is fixed in trusty presumably?
<ubottu> bug 1316125 in autofs5 (Ubuntu Saucy) "Autofs leak file descriptors when reloaded (-HUP) and daemon may stop working on high # of shares/reloads" [Undecided,In progress] https://launchpad.net/bugs/1316125
<arges> bdmurray: let me verify
<bdmurray> arges: it doesn't look like it to me...
<arges> bdmurray: yup il'l have tinoco fix that thanks
<tinoco> yep, im on it
<bdmurray> arges: okay, I've also added an autofs task since the closure looks at the source package name
<arges> oh didn't realize it was targeted against the binary package
<arges> bdmurray: thanks
<bdmurray> I think there was some weird renaming of autofs / autofs5
<bdmurray> and if its not fixed in trusty then it isn't fixed in utopic since they are the same verison
<tinoco> bdmurray: the same version was kept from saucy to utopic
<tinoco> and this bug fix is based on a commit on 5.0.7 so all of them needs the fix
<tinoco> im creating the diffs for them
<tinoco> i'll attach to ua and lp, ok ?
<Saviq> kirkland, hey, shift+f2 stopped working a day or two ago in my byobu under utopic (shift+f7 stopped working before that), both print ~ at that point, any idea where that might come from?
<jtaylor> can one add new source packages to trusty?
<Logan_> through a backport
<jtaylor> I mean into updates
<jtaylor> so other srus can depend on it
<Logan_> does an important bug fix depend on a new source package? o_O
<jtaylor> yes
<Logan_> go on
<jtaylor> one could do it in an existing one but thats incredibly ugly
<mterry> robert_ancell, when were you thinking of releasing the next lightdm revision?
<robert_ancell> mterry, whenever, is there something you were blocking on?
<mterry> robert_ancell, split greeter would appreciate that login1-race fix
<robert_ancell> mkay
<robert_ancell> mterry, perhaps you could also look at https://code.launchpad.net/~christian-w/lightdm/qt-binding-keyboard-layouts/+merge/205356
<infinity> jtaylor: Yes, but it's rather ugly and needs some justification.
<mterry> robert_ancell, looking
<jtaylor> justification is I don't want to touch tcl ._.
<xnox> jtaylor: try again =) what's wrong with tcl in trusty? we even have two, if i recall correctly
<jtaylor> thats the problem
<jtaylor> I want to add a new package using tcl 8.5 instead of 8.6
<jtaylor> to make the stuff we didn't transition work again
<xnox> jtaylor: you don't have to build against both, you can use just one of them. and both should be in main.
<jtaylor> so far I know porting is either non-trivial or impossible
<jtaylor> xnox: doesn't work with libraries
<jtaylor> one library uses 8.5 the other 8.6
<jtaylor> you can imagine that that will not end well
<xnox> jtaylor: what's the incompatible set of packages you are talking about?
<jtaylor> the blt and itcl3 rdepends
<jtaylor> it seems itcl3 was incorporated into tcl 8.6 as itcl4/tclOOP
<jtaylor> I have not found if you can even use itcl3 with 8.6
<jtaylor> trying it just crashes
<xnox> jtaylor: so you are saying that skycat & tkdesk are borked?
<jtaylor> yes
<xnox> jtaylor: well one or the other way it needs to be fixed in utopic, and is probably worth an sru into trusty.
<xnox> jtaylor: have you filed a bug yet?
<jtaylor> I would do that by adding a blt8.5
<jtaylor> which is really easy
<jtaylor> as its library is versioned
<jtaylor> the question is can I do that in trusty too
<xnox> jtaylor: you don't need to add a new source package though. you can just add a second binary package.
<jtaylor> xnox: I know but thats not easy
<xnox> jtaylor: or it would be best to resolve it by e.g. rebuilding itcl3 with 8.5 in trusty. but that needs testing.
<jtaylor> itcl is 8.5 in trusty
<jtaylor> blt would need rebuild against 8.5
<xnox> well then blt should be to.
<xnox> right, that.
<jtaylor> which is problematic as its rdepends use 8.6
<jtaylor> its safer to add a new package
<xnox> given that blt's rdependes is relatively short, we will probably need to rebuild those as well.
<jtaylor> reverting a transition seems more ugly than adding a new source
<xnox> jtaylor: a new package doesn't solve the problem that you have binaries linked together with incompatible tcl's and only adds more cases to the depedency chart.
<jtaylor> it helps at least for skycat
<xnox> well in utopic we really should port itcl3 to 8.6
<xnox> and in the best interest of everyone cherrypick that into trusty.....
<xnox> jtaylor: please open a bug report against blt, itcl3, skycat & tkdesk.
<xnox> jtaylor: we'll need to track this, whichever way this is going to be solved.
<jtaylor> I don't know how to port it
<jtaylor> I can't even get a reasonable backtrace of the crash ._.
<xnox> jtaylor: that's ok, others know how to port things, but please open the bug report describing the issues you are seeing.
<TheMuso> mdeslaur: Re bug 1319970, I am happy to take care of this if you like. I have commit access to the git repo for speech-dispatcher in Debian, and I track Ubuntu's changes there too.
<ubottu> bug 1319970 in speech-dispatcher (Ubuntu Utopic) "speed-dispatcher user needs a restricted shell (/usr/sbin/nologin or /bin/false) instead of /bin/sh." [Undecided,Confirmed] https://launchpad.net/bugs/1319970
<saiarcot895> When building Qt 4.8.5 on Trusty, there's a message printed out about using the -no-exceptions flag (http://paste.ubuntu.com/7470347/). Might this be beneficial?
<robert_ancell> mterry, 1.11.2 uploaded
 * mterry high fives robert_ancell
<mterry> thanks
<mdeslaur> TheMuso: sure! that would be great, thanks!
<TheMuso> mdeslaur: np, I'll assign the bug to myself then.
#ubuntu-devel 2014-05-16
<pitti> Good morning
<Unit193> Howdy.
<pitti> hey Unit193
<Unit193> Say, while it's quiet, know why utopic wouldn't like init=/bin/systemd while trusty was fine with it?
<pitti> that never worked
<pitti> you mean init=/lib/systemd/systemd
<pitti> oh, there's a symlink
<pitti> I never tried that
<pitti> so, no off-hand idea
<Unit193> Cool, works for me.
<Unit193> Not that it matters much, but I've narrowed it to the initrd, but didn't really look much into it.
<pitti> Unit193: yeah, this shoudl really only apply after the initrd
<Unit193> Yes, I say it's initrd because an old kernel worked, but after update-initramfs -c -k all it no longer did.  Also from what I remember of the error message, it can't find the file it's looking for.  Anywho, it works, and you've got better things to look at. :)
<RAOF> pitti: Good morning! Is there a way to arch-
<pitti> RAOF: hey
<pitti> arch-?
<RAOF> Premature <enter>. It's a curse :)
<Mirv> aaaarch
<bzoltan1> pitti: good morning
<RAOF> ...arch-restrict autopkgtests? Say if I wanted to test that you can install apitrace-gl-tracer:i386 and apitrace-gl-tracer:amd64 and then run âapitrace trace glxgearsâ with glxgears:i386 installed and âapitrace trace glxgearsâ with glxgears:amd64 installed?
<bzoltan1> pitti: I would need an ack on this landing https://ci-train.ubuntu.com/job/landing-019-2-publish/lastSuccessfulBuild/artifact/packaging_changes_qtcreator-plugin-ubuntu_3.0.1+14.10.20140516-0ubuntu1.diff
<pitti> RAOF: you can use the full arch dpkg dependency syntax
<bzoltan1> pitti: it is a single line fix in the .desktop file
<pitti> RAOF: so e. g. Depends: apitrace-gl-tracer:i386 [amd64], apitrace-gl-tracer:amd64 [amd64], ...
<pitti> bzoltan1: hey
<RAOF> pitti: Ah, funky! And that'll ensure the test gets run on an amd64 box?
<pitti> bzoltan1: it could certainly do with a justification in the changelog ("got dropped in X.Z.Y", "it's the default now", etc.)
<pitti> RAOF: no, they'll still run everywhere, but that means that those packages will only get installed on amd64
<RAOF> So the test will fail everywhere but amd64?
<pitti> RAOF: your test can just query uname -m or dpkg --print-architecture or whatever to do arch specific stuff
<bzoltan1> pitti: this -client was introduced in the previous release, before that it did not exist. Eventually I overlooked that it causes problem
<RAOF> Yeah, about to say that :)
<pitti> or just test if a particular command is available with "which" or so
<RAOF> Cool. I'll see about hooking up some tests.
<pitti> RAOF: so at the moment there's no "Architecture:" field there
<pitti> bzoltan1: so the general change is trivial and fine of course, and you know much better whether it's right than me
<bzoltan1> pitti:  it brakes the Ubuntu SDK desktop file  when there is no QtC instance running ... would be cool to publish this revert before the rest of the world wakes up and does upgrade
<pitti> RAOF: and for the  "just :i386 installed" vs. "just :amd64 installed" you should create two tests which just depend on one of those; you'll get a clean test bed for each test
<darkxst> hmm, lp:ubuntu/mutter and lp:ubuntu/gnome-shell branches are way out of date!
<pitti> RAOF: and you want to run xvfb-run -s '-screen 0 1024x768x24' glxgears ?
<RAOF> pitti: Yeah, something like that. I think I'll actually need to run it under a proper Xorg with dummy drivers, though; does xvfb do GLX nowadays?
<pitti> RAOF: yes, with above -screen option
<RAOF> Sweet. That's even easier!
<pitti> RAOF: the only reason why "xvfb-run glxgears" doesn't work is because xvfb still defaults to an 8bpp screen
<pitti> RAOF: but GLX swrast needs 24bpp
<pitti> RAOF: yeah, took me a while to find that out
<pitti> RAOF: (that command works, just tried in a chroot)
<pitti> llvmpipe for the win (I think)
<RAOF> Presumably :)
<dholbach> good morning
<ogra_> pitti, xnox, all image builds failed tonight with what looks like an invoke-rc.d issue ... seems everything that has an init script (or rather an upstart job burt no init script) fails to install
<ogra_> invoke-rc.d: unknown initscript, /etc/init.d/whoopsie not found. (and a lot of other packages on touch)
<ogra_> xnox, pitti ^^^^
<pitti> ouch, that smells like yesterday's sysvinit upload indeed
<ogra_> yeah, i just see the lxc upload from xnox
<ogra_> i guess we need to do that for a lot more packages
<pitti> ogra_: that was just a followup for the sysvinit one
<pitti> no, that was a special casea
<pitti> $ sudo initctl status whoopsie
<pitti> that works
<pitti> the LXC issue was that "sudo initctl status lxc-instance" does not work
<ogra_> well
<ogra_> -	dh_installinit --no-restart-on-upgrade --name=lxc-instance
<ogra_> +	dh_installinit --no-start --no-restart-on-upgrade --name=lxc-instance
<pitti> right
<ogra_> it just adds --no-start
<pitti> yes, because lxc-instance isn't meant to be started during boot or on package install
<ogra_> oh
<pitti> but whoopsie and friends are
<ogra_> k
<pitti> ogra_: if you try above status command, you'll see "initctl: Unknown parameter: NAME"
<pitti> ogra_: that's a "template" job which can be instantiated, it's not a standalone job by itself
<pitti> hence the special case
<ogra_> ok ... so not the image build issue then
<pitti> so, apt-get install whoopsie works in a schroot
<pitti> ogra_: do you have an URL for an affected log?
<pitti> http://people.canonical.com/~ubuntu-archive/livefs-build-logs/utopic/ubuntu/20140515/ ?
<ogra_> ubuntu daily only has the one whoopsie issue above ... touch has a lot more: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/utopic/ubuntu-touch/20140516/livecd-armhf.out
<pitti> ack
<pitti> I see it there
<pitti> ogra_: is that actually a failure?
<pitti> the "All runlevel operations denied by policy" is fine, due to policy-rc.d
<ogra_> dpkg thinks so at least
<pitti> the "invoke-rc.d: unknown initscript, /etc/init.d/whoopsie not found." is certainly ugly
<pitti> ogra_: hm, I don't see an actual failure in above log
<pitti> oh, I was looking at http://people.canonical.com/~ubuntu-archive/livefs-build-logs/utopic/ubuntu/20140515/livecd-amd64.out
<pitti> which is fine
<ogra_> pitti, look at the touch log ... seems /20140516 was not mirrored yet for desktop
<ogra_> (failed only 20min ago)
<pitti> oh, I have an idea
<pitti> the new update-rc.d calls initctl status
<pitti> but that wouldn't actually work if upstart isn't running
<ogra_> Processing triggers for libreoffice-common (1:4.2.3~rc3-0ubuntu3) ...
<ogra_> Errors were encountered while processing:
<ogra_>  modemmanager
<ogra_>  whoopsie
<ogra_> E: Sub-process /usr/bin/dpkg returned an error code (1)
<pitti> so it would consider this as "no such upstart job" and fall back to init.d
<ogra_> this is how desktops 0516 ends in the mail
<pitti> *nod*
<pitti> and in my schroot it can talk to the "outside" upstart and thus succeed
<ogra_> ah
<pitti> I bet if I boot with systemd I can reproduce it in a schroot, brb
<ogra_> do our chroots use systemd ?
<pitti> ogra_: schroots don't have a pid 1 (that's not a container)
<pitti> well, they just use the "outside" pid 1, they don't have a separate process NS
<ogra_> well, i was talking about the build ... that uses plain chroots
<pitti> ogra_: yeah, so apparently these schroot builds either don't have upstart "visible" in the schroot (unlikely)
<pitti> ogra_: or, which is more likely, they don't run whoopsie
<pitti> thus "status whoopsie" in the chroot fails as the host doesn't have a whoopsie job
<pitti> etting up whoopsie (0.2.26) ...
<pitti> invoke-rc.d: unknown initscript, /etc/init.d/whoopsie not found.
<pitti> dpkg: error processing package whoopsie (--configure):
<pitti>  subprocess installed post-installation script returned error exit status 100
<pitti> bingo
<pitti> xnox: AYT?
<ogra_> hmm i think we simply inherited debians policy here ... while we allowed upstart only they dont ... isnt it like that ?
<pitti> ogra_: that too
<pitti> ah, I think it's even a bit different in my schroot now and the livefs builders
<pitti> they do have upstart running, but no whoopsie job
<ogra_> on touch it is like 30 packages that fail
<pitti> while I now don't upstart running
<pitti> i. e. "initctl version" should succeed on the livefs builders, but fail for me
<pitti> ogra_: it seems xnox is still not awake; I think I know what to revert, I just wonder if we should wait a bit for him to get online, or upload right now
<ogra_>   * service & invoke-rc.d: unset UPSTART_SESSION environment variable to
<ogra_>     make sure all upstart initctl commands are executed against system
<ogra_>     init and not the session one. (Closes: #745505)
<pitti> no, it's the other one
 * ogra_ glares at this changelog entry in sysvinit ... what ?!?
<pitti> -   && [ -e "$UPSTARTDIR/${INITSCRIPTID}.conf" ]
<pitti> +   && initctl status ${INITSCRIPTID} 1>/dev/null 2>/dev/null
<ogra_> still
<pitti> ogra_: that one is right and harmless
<ogra_> why would you run a session job against the system process ?
<pitti> ogra_: no, if you run "initctl status whoopsie" as user, it will look for a session job
<pitti> ogra_: while that is always wanting the system job
<pitti> i. e. "initctl --system status whoopsie"
<pitti> the "service" change also looks ok to me as it's guarded with initctl version
<pitti> ah no, same problem
<ogra_> about half of the failed jobs on touch are session ones ...
<ogra_> and i dont think the code above matches for that
 * pitti needs to reboot with upstart again to completely verify the fix, brb
<ogra_> ah, looks like all the session ones i see fail are somehow depending on a package with a system job ... so all is fine
<xnox> pitti: ogra_: hello, what's up?
<pitti> xnox: so, sysvinit broke live fs builds
<pitti> xnox: I think I understand the problem now:
<pitti> xnox: the live fs builder's host is running upstart, so initctl version will succeed
<pitti> xnox: the live fs builder is not running whoopsie, so initctl status whoopsie will *fail*
<pitti> xnox: but we use that now to decide whether $INITSCRIPTID has an upstart job, instead of [ -e "$UPSTARTDIR/${INITSCRIPTID}.conf" ]
<xnox> pitti: *sigh*
<pitti> xnox: thus it tries to fall back to an init.d/whoopsie script, which doesn't exist
<pitti> and then it throws up its arms
<xnox> pitti: (a) shroots shouldn't be running or trying to start an upstart session by default
<pitti> xnox: xnox they don't
<pitti> xnox: its' the *host's* upstart they are talking to
<pitti> xnox: remember, it's a simple chroot, not a container; no separate process NS
<xnox> what's the version of upstart on the host?
<pitti> it doesn't matter
<pitti> (and I don't know)
<jodh> pitti: it does matter - you could potentially boot the host init with sessions disabled
<xnox> upstart used to have chroot session, which should be fine. and i thought invoke-rc.d was diverted during package builds.
<pitti> jodh: well, perhaps it does, but not for this bug
<ogra_> the builds happen in a triple stacked chroot setup ... iirc
<xnox> pitti: upstart has ability to load and start /etc/init/ jobs in the chroot.
<pitti> xnox: no, it installs policy-rc.d to just disable jobs
<pitti> I can reproduce the problem just fine
<ogra_> not sure what version the uplevel one has ... perhaps it is trusty ...
<xnox> pitti: oh, only policy-rc.d. hm =(
<pitti> "sudo dpkg -P whoopsie" on your workstation
<ogra_> *toplevel
<pitti> schroot -c utopic -u root
<pitti> apt-get install whoopsie
<ogra_> (but could well be precise)
<pitti> xnox, ogra_: tested fix/revert: http://paste.ubuntu.com/7471889/
<pitti> certainly not ideal and this will need refinement, but it reverts to a known-working state for   n ow
<xnox> pitti: how is policy-rc.d preventing upstart jobs to be started?
<pitti> xnox: invoke-rc.d checks policy-rc.d, and exit code "104" means "disable this job"
<xnox> pitti: right, yeah, go ahead and upload that.
<pitti> err, 101
<xnox> pitti: ok, and that is not happening here, and we still go and invoke start?!
<pitti> it's in man invoke-rc.d; that has been the standard way to build chroots for decades in Debian, and every init system implements it
<pitti> xnox: what is not happening here?
<pitti> ah, my reproducer was missing "rm /usr/sbin/policy-rc.d"
<xnox> i want to know how that check is implemented against upstart jobs.
<jodh> pitti: so you cannot modify the hosts init options? If it's precise, you could boot with --no-sessions to fix this issue. To be clear that option is referring to *chroot* sessions - nothing to do with upstart users sessions
<pitti> jodh: right, this has nothign to do with user sessions
<xnox> jodh: well, ultimately, package installation in a chroot should not start the jobs in the chroot.
<pitti> jodh: it's about "initctl status" in a chroot talking to the host's pid 1 (as there is nothing else to talk to really)
<xnox> (as per distro/debian policies)
<pitti> correct
<jodh> pitti: I know - please re-read what I just wrote! :)
<xnox> pitti: =)))) i'll show you in malta how initctl in the chroot, can talk to host's pid 1 and control it's own jobs in chroot =))))
<pitti> jodh: well, I did; I might have misunderstood it
<pitti> xnox: can we do that in invoke-rc.d instead of the simple "initctl status"?
<jodh> pitti: upstart is "chroot-aware" - so if an initctl command is run in a chroot (or schroot), the init *outside* the chroot *will* respond to those requests... unless you boot the outer init with --no-sessions (precise). This is the default with upstart in utopic.
<pitti> jodh: ah, then I did misunderstand it
<pitti> jodh: right, I suppose the livefs build host is running precise
<xnox> pitti: but we should be, as per policy-rc.d, not even reach doing the "start" action.
<pitti> xnox: yeah; as I said, I think in spirit your change is good; we just need to make it work with chroots
<pitti> this revert is certainly not the "right" solution, it just unbreaks our live fs builds for the moment
<xnox> pitti: i did $ schroot -u root -c utopic-amd64; did apt-get install whoopsie, and that installed fine.
<pitti> xnox: did you purge whoopsie on your host?
<xnox> ah, need update to latest / broken initscripts.
<pitti> :)
<ev_> man, my whoopsie highlight is going ca-razy
<pitti> whoopsie, I didn't mean to highlight you that often :) (SCNR)
<ev> lol
<ev> well played
<pitti> it's kind of appropriate to use whoopsie to debug failures though :)
<ev> 'tis :)
<xnox> pitti: i wonder if chroot's initctl can control system jobs =)
<xnox> pitti: totally can....
<xnox> infinity: ^
<pitti> jodh: FTR, I reproduced that with current utopic on current utopic; I didn't enable chroot sessions anywyere, but you said that shoudl be the default now?
<pitti> xnox: well, it's not like chroots were any kind of a security boundary :)
<jodh> pitti: ignore the version of upstart in the chroot - it's the version of the one outside that matters
<xnox> infinity: togging off chroot session, gives us a side effect that all upstart commands now control hosts system upstart =) and see hosts jobs, etc.
<xnox> jodh: i'm thinking if initctl & friends should somehow figure out if they are in a chroot, and host's upstart has chroots not enabled, and then like error out and not return anything in $ initctl list, show-config, etc.
<pitti> xnox: perhaps we could do "initctl status $job || [ -e /etc/init/$job.conf ]"?
<pitti> that would still go wrong in a chroot where initctl fails and the job is not in /etc/init/ but someplace else
 * xnox ponders why i see + [ ! -e /whoopsie.conf ]
<xnox> exit 100
<pitti> but I'm not sure whether the situations where the job is someplace else would be relevant in a chroot build
<pitti> xnox: did you forget to put "UPSTARTDIR=/etc/init/" back?
<pitti> xnox: I assume you just changed initctl status to [ -e ]
<xnox> pitti: i think i see what's wrong.
<xnox> $UPSTARTDIR was removed, but used in the fallback path of the "failed to run job in chroot"
<xnox> add back the variable or replace that last instance with /etc/init/
<xnox> pitti: so actually just adding UPSTARTDIR=/etc/init in your upload whould have fixed it.
<xnox> pitti: see lines 281-292
<xnox> pitti: hm, after your upload reaches release pocket, i'll upload http://paste.ubuntu.com/7472003/
<pitti> xnox: hm, won't that exit with 100 then?
<pitti> ah no
<xnox> =)
<pitti> '!' matters :)
<pitti> xnox: nice, that's much better, thanks!
<infinity> xnox: That seems to be exactly what you'd want without chroot sessions, yes.
<xnox> infinity: you are probably right. chroots should be anything special.
<ogra_> hmm
<ogra_> since when do we not have "lo" defined in /e/n/i anymore ?
<ogra_> is that part of the systemd transition ?
<xnox> ogra_: we do, but i thought installer defines that, no?
<xnox> (i see where you are going with that....)
<ogra_> xnox, well, the file looks different to trusty ... i have lo up and running (this is indeed on a tablet with ubuntu touch as you might guess)
<ogra_> it is just the entry thats missing
<cjwatson> lo was always done by netcfg, which obviously isn't run in ubuntu-touch
<ogra_> doesnt seem to do any harm ... just looks odd
<ogra_> /etc/init/network-interface.conf sets it up anyway
<stgraber> yeah and I believe ifupdown also has it hardcoded so it's pretty hard to get a system without lo
<ogra_> right
<ogra_> i was just wondering about /e/n/i
<ogra_> (well, i was always wondering before why we put it there ... since we have enough mechanisms to bring it up anyway)
<cjwatson> We almost certainly didn't when that code was added
<ogra_> i have it on trusty
<ogra_> auto lo
<ogra_> iface lo inet loopback
<darkxst> stgraber, would you accept patches for ppa support in the sbuild-launchpad stuff?
<cjwatson> Sure, but I don't actually spend most of my time looking for old code to remove ;-)
<ogra_> heh
<stgraber> darkxst: sure
<darkxst> stgraber, ok I will clean up my hacks, the general idea is to pass in a ppa when creating the chroot and it will create a bunch more alias'
<darkxst> (though they end up being really long alias'!
<brendand> no answer on #ubuntu-phone so hoping for better luck here - no network indicator on ubuntu-touch image 32?
<brendand> nmcli reports:
<brendand> GENERAL.STATE:                          20 (unavailable)
<brendand> GENERAL.REASON:                         2 (Device is now managed)
<stgraber> darkxst: that sounds like how I'd have implemented it, so great!
<ogra_> come on sysvinit ... migrate faster ...
<cjwatson> Hm, linux autopkgtest failed
<cjwatson> pitti: ^- was that a testbed failure?
<ogra_> for syvinit ? excuses shows it still in progress
<cjwatson> I'm looking at the backend
<ogra_> ah
<ogra_> :(
<cjwatson> excuses is updating at the moment
<ogra_> yeah, i dont want to reload :P what i see currently at least left some hope :P
<pitti> cjwatson: kind of; I guess we need to bump the timeout for the copying a bit higher :/
<pitti> cjwatson: feel free to temp override this as it's blocking live images
<ogra_> \o/
<ogra_> :)
<cjwatson> pitti,ogra_: forced
<ogra_> thx
<pitti> sil2100: hi!
<pitti> sil2100: sorry to ask, where is that spreadsheet again to list the landers for a project? I'm looking to land https://code.launchpad.net/~pitti/ubuntu-system-settings-online-accounts/fix-autopkgtest/+merge/219819
<pitti> sil2100: or can I just add it to https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=1 ??
<sil2100> pitti: hi!
<sil2100> pitti: so, we don't use that spreadsheet anymore ;) We have a different one, but let me find you the list of landers - but from the branch I see it's either dbarth or mardy
<sil2100> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdC05a2ZQSmgwU2NFYnJQOE9qMDRYa3c&usp=sharing#gid=1 <- here's the list of landers for each component
<sil2100> But I don't see that component there
<sil2100> pitti: let me poke dbarth about that one
<pitti> sil2100: ah right, sorry (found it from https://wiki.ubuntu.com/citrain now)
<sil2100> mardy: hi!
<sil2100> mardy: could you take a look at pitti's merge request and, if +1, be the lander for it?
<sil2100> mardy: ^
<pitti> so for system-settings it would be seb128, but there's no name for s-s-online-accounts
<pitti> does that mean "whoever gets to it"?
<seb128> pitti, landers are not strict assignement, anyone can land anything
<asac> ack
<seb128> it's just "usual contact point"
<pitti> ah, ok
<seb128> I think dbarth is handling the online account ones
<seb128> but I'm happy to put a landing up for you
<asac> yeah, just coordinate with the team owning the upstream branch i gues
<pitti> sorry, so far Mirv or sil2100 have been so kind of doing landings for me; need to learn that stuff some day
<pitti> asac: I looked, but the owner is pretty much "everyone" (111 members)
<asac> right.
<asac> so if that component never landed, there might be no testplan in wiki yet
<seb128> pitti, you want mardy for online account
<sil2100> pitti, asac: this one is from dbarth and mardy so that's why I poked him
<asac> usually we would like to see that happen before the first landing
<asac> ack
<sil2100> pitti: you could be the lander as well but we would have to ci-train train you ;)
<pitti> asac: in that regard it shoudl be easy -- it's fixing a test, not the actual code :)
 * asac levaes it to sil
<pitti> sil2100: well, if I coudl self-approve/self-land, I could just JFDI dput it :)
<asac> pitti: right, but someone should create a testplan - even if very simple - for that tree; check with upstream team owning so they do that (if not now, at least after)
<sil2100> pitti: ok, since mardy is not around, let me be your lander :)
<asac> thought pitti wanted to learn it by doing now :)
<asac> hehe
<pitti> sil2100: thanks; I verified it with adt-run .// --- qemu adt-utopic-amd64-cloud.img
<pitti> sil2100: that builds the package, installs the built binaries, and runs the autopkgtest against it, and it succeeds now
<pitti> and it's changing nothing else
<pitti> the fixed AP test gets skipped on the phone (that's why it wasn't noticed before)
<sil2100> pitti: that's good enough for me :) Do you need someone to also look at that merge request? Not sure if there's someone in upstream who could have more experience in autopkgtesting than you anyway ;p
<pitti> sil2100: not me personally; might be that upstream wants to look at it, of course
<ogra_> we're canonical, we dont care about upstreams :P
<pitti> so yes, looks like mardy has poked it recently
<sil2100> ogra_: ;p
<pitti> ogra_: ah, right of course -- TOSS IT IN! :)
<ogra_> haha
<pitti> (merci dieu c'est vendredi)
<ogra_> yeah :)
<sil2100> Whatever that means!
<pitti> sil2100: TGIF
<ogra_> sil2100, polish your french
<ogra_> oh the pun :)
<sil2100> ogra_: I prefer to french my polish :D
<pitti> TGIFÂ²
<ogra_> haha
<sil2100> hah ;)
<mardy> pitti: sorry, was afk
<mardy> pitti: just approved
<pitti> mardy: no worries; thanks, that was fast!
<mardy> sil2100: maybe you can put pitti's branch in dbarth's silo? (row 25)
 * pitti goes to fix autopilot-gtk for the recent ap py3 change
<sil2100> mardy: right, but since it's a standalone change, and row 25 is still blocked on unity-mir
<sil2100> mardy: I think we can quickly land this before unity-mir is freed and before we can assign a silo for 25...
<pitti> mardy, sil2100: it's not that urgent really, I just came across it; so no extra efforts please
<mardy> sil2100: ok, but then maybe it's better to take https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/autopilot/+merge/218777 away from row 25 and make it land together with pitti's
<mardy> pitti: does https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/autopilot/+merge/218777 look OK to you?
<sil2100> Oh
<sil2100> Ok
<sil2100> mardy: ok :) Can I make you the lander for those then? :)
<pitti> mardy: ah, I didn't see that; but my branch supersedes that
<pitti> mardy: or rather, it won't be enough
<pitti> mardy: autopilot-desktop is py3 now, and there's still that broken test
<mardy> pitti: yes, so we need both, right?
<pitti> mardy: no, we don't
<pitti> mardy: my branch also adds a dependency to autopilot-desktop-legacy
<sil2100> It seems to be a Friday of confusion for me ;p
<mardy> pitti: ah, didn't see that
<pitti> mardy: but as a test depends, not as a pacakge depends; if you prefer a package depends that works too; but it's unnecessary on the phone
<mardy> sil2100: sorry, then please just delete https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/autopilot/+merge/218777 from dbarth's request
<sil2100> mardy: ok ;)
<mardy> sil2100: about being the lander, what does that mean in practice?
<sil2100> mardy: in practice being a lander means the responsibility for building the package, resolving merge conflicts, testing the merge and setting it to 'ready' when it's OK to land
<sil2100> *merges
<sil2100> mardy: in case of this one, I guess not much testing is needed though
<sil2100> mardy: I'll do this one if anything
<mardy> sil2100: I could do all of that, except setting the "ready" bit, as the spreadsheet is view only for me
<sil2100> mardy: it is? Weren't you a lander already ? :O
<mardy> sil2100: no
<mardy> sil2100: mmm, actually, I don't even know how to start the build; maybe it's better to wait for dbarth, we'll be back later
<mardy> s/we/he/
<sil2100> mardy: no problem, I already started the build and will lead this one till the end - but it would be nice if you could be a lander as well anyway
<mardy> sil2100: +1
<hrw> hi
<ogra_> hey hrw
<hrw> ogra_: can you remind me what is ubuntu way of dealing with software tests?
<ogra_> depends on what level ...
<ogra_> we have autopkgtests for packaging ... we have autopilot for UI tests
<hrw> ogra_: I went to another package where testsuite was not built at all
<xnox> hrw: and unit tests are build & executed at build-time.
<ogra_> then there are unit tests ... and there are CI tests that run in jenkins for each merge proposal on LP
<xnox> hrw: by default equivalent of $ make check test, is run at build time. Unless disabled, or the test target is somthing funky.
<hrw> mkey
 * hrw -> figure out how to run openbabel tests in ubuntu
<xnox> hrw: maybe there is simply a typo? http://paste.ubuntu.com/7473039/
<xnox> hrw: building now.
<hrw> xnox: thanks
<xnox> test targets are getting built....
<hrw> xnox: now arm64 will fail
<xnox> hrw: tests are getting executed.
<xnox> hrw: well such is life then.
<hrw> xnox: sure. but now I know that fedora and ubuntu share results
<shadeslayer> bdmurray: ping
<bdmurray> shadeslayer: hi
<shadeslayer> xnox: bdmurray ScottK do you reckon I can apply for MOTU on the meeting on the 19th if I send in my application today
<bdmurray> I think we have at least two applications to review as it is
<shadeslayer> ah hm, ok
<bdmurray> and three days to review the application seems a bit short to me, but I'm the new guy
<Laney> We ask for a week for that reason
<shadeslayer> bdmurray: MOTU applications : 1
<shadeslayer> sure, just wanted to ask if it was possible, if not, that's fine by me :)
<xnox> shadeslayer: it's 2 in total applications, not 2 per type.
<shadeslayer> xnox: in which case, don't you have 3?
<xnox> shadeslayer: and we already have 3 queued up (well, benjamin & lukasz is carry over, but we are porcessing lukasz over email)
<shadeslayer> ah ok
 * shadeslayer will wait then
<xnox> shadeslayer: don't wait, but rather add your name to Jun2nd meeting _now_
<xnox> shadeslayer: as it may get filled =)
<shadeslayer> roger
<xnox> shadeslayer: following the normal process.
<shadeslayer> right
<xnox> hrw: https://launchpadlibrarian.net/175730114/buildlog_ubuntu-utopic-arm64.openbabel_2.3.2%2Bdfsg-1.1ubuntu1_UPLOADING.txt.gz
<xnox> hrw: tests are now run, and fail, but they do not fail the build =)
<hrw> xnox: one more test failed
<xnox> Mirv: is it possible to compile qt5 without libx* dependencies?
#ubuntu-devel 2014-05-17
<Unit193> pitti: Well howdy.  Hope you show up soon.  So I found out more on the problem, it's readlink related.  The validate_init() function in /usr/share/initramfs-tools/init errors with: /init: line 307: readlink: not found   (more output: http://paste.openstack.org/show/lpnfpPHaBzzH6OFQRRom)
<Unit193> pitti: I had another minute to look at it, the busybox hook in Ubuntu removes readlink, the one in Debian doesn't.
<NikTh> pitti: Available ? :-)
<NikTh> pitti: Check this out, when you have time: http://pastebin.com/raw.php?i=bnjFKtZ4 . It is from todays (14.10) updates (systemd as PID 1)
<NikTh> pitti: Filed a bug, just for any case : https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1320480 :-)
<ubottu> Launchpad bug 1320480 in whoopsie (Ubuntu) "[systemd]Failed to issue method call: Unit whoopsie.service failed to load: No such file or directory" [Undecided,New]
<Celine> Hello. I' m a pro-tester. I've installed Lubuntu 14.10 and what to test as a volunteer what hasn't been tested.
<Celine> Hello. I' m a pro-tester. I've installed Lubuntu 14.10 and want to test as a volunteer what hasn't been tested. Where should I give a sign?
<bekks> Whats a "pro-tester"? Same as a "pro-gamer"? :P
<ion> bekks: https://encrypted.google.com/search?tbm=isch&q=protester&tbs=imgo:1
<Celine> Hello. I' m a pro-tester. I've installed Lubuntu 14.10 and want to test as a volunteer what hasn't been tested. Where should I give a sign?
<ScottK> Celine: Try asking in the #debian-testing channel.
<ScottK> Sorry
<ScottK> #ubuntu-testing
<Celine> Hello. I' m a pro-tester. I've installed Lubuntu 14.10 and want to test as a volunteer what hasn't been tested. Where should I give a sign?
<Celine> ScottK: Thank You.
<jdstrand> bdrung: hey, can you reply to my comment on bug #1276650?
<ubottu> bug 1276650 in vlc (Ubuntu Trusty) "please update VLC to version 2.1.3" [Undecided,New] https://launchpad.net/bugs/1276650
<CounterPillow> I heard there was a pro-test going on in here
<bdrung> jdstrand: done
<noorez> Attempted my first ever patch to ubuntu in response to a bug. Was wondering if I could get some guidance on it: https://code.launchpad.net/~noorez-kassam/ubuntu/utopic/initramfs-tools/fix-for-1317437/+merge/219927
<noorez> was in response to this bug: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1317437
<ubottu> Launchpad bug 1317437 in initramfs-tools (Ubuntu) "wubi kernel option "rw" required " [Undecided,Confirmed]
<Logan_> siretart: gonna sync libav from unstable? we no longer need the tiff delta
<Logan_> anyone know when the new GTK+ 3 will be uploaded to Ubuntu?
#ubuntu-devel 2014-05-18
<suudy> I'm working on porting plymouth to a customized ubuntu distro (based on 12.04).  I'm having trouble getting the Image.Text() to render while in the initramfs.  It works fine when plymouth is used after the switch to the rootfs.
<suudy> Also, the '--debug --debug-file=<path to file>' doesn't seem to produce anything in the initramfs.
<suudy> I asked on #ubuntu, but was directed here.
<xnox> suudy: do you have needed fonts in the initramfs?
<xnox> suudy: on ubuntu, ubuntu-logo theme does work from initramfs and can render Image.Text(), compare your initramfs with the one produced in stock ubuntu (when plymouth has been added into the initramfs) and check what's different / missing.
<suudy> I have the same packages installed in both the initramfs and rootfs.  But I'll double check the fonts.
<suudy> But I can't figure out why debug and debug-file aren't doing anything in the initramfs.
<suudy> xnox: I figured it out.  I had to hack the source to get plymouth to log in the initramfs, but I narrowed it down to find out that libgobject wasn't found.
#ubuntu-devel 2015-05-11
<pitti> Good morning
<dholbach> good morning
<ari-tczew> hello dholbach
<dholbach> hey ari-tczew
<dodeluser> hello. I got a special question about this tutorial: https://help.ubuntu.com/community/LiveCDCustomization#Advanced_Customizations
<dodeluser> I do not understand this line: sudo chroot edit mkinitramfs -o /initrd.gz 2.6.15-26-k7
<dodeluser> someone can help me?
<dholbach> @pilot in
* udevbot 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: dholbach
<flexiondotorg> dholbach, As pilot could you take a look at https://code.launchpad.net/~ubuntu-mate-dev/indicators-gtk2/indicator-application-gtk2/+merge/244116
<flexiondotorg> dholbach, I've discussed this with infinity.
<flexiondotorg> dholbach, infinity was able to get it to build and pass the test, just as I was when testing in a PPA.
<flexiondotorg> dholbach, infinity and I agreed to wait to merge and upload for the 15.10 cycle.
<flexiondotorg> dholbach, Any chance you could merge and upload today please?
<tseliot> pitti: hi, u-d-c seems to fail to build (i.e. to pass all the tests) on armhf and arm64. Is there a way to skip some of the tests based on the architecture?
<tseliot> pitti: that's in wily
<pitti> tseliot: I don't think you want to skip based on the architecture, but rather availability of the nvidia-experimental pacakge or hybrid-detect, or whatever the test checks?
<pitti> tseliot: and yes, you can do that; we already conditionally skip some tests
<pitti> tests/ubuntu_drivers.py:    @unittest.skipUnless(os.path.isdir('/sys/devices'), 'no /sys dir on this system')
<pitti> tseliot: just odd that this worked in vivid, looks like something in nvivia-experiemntal changed between vivid and wily?
<pitti> https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.4.5 succeeded on all arches, after all
<tseliot> pitti: maybe nvidia-experimental was finally removed
<tseliot> pitti: or it was never there for arm
<tseliot> that's a transitional package
<tseliot> actually, it was
<tseliot> pitti: also, we no longer have nvidia-current and nvidia-current-updates
<pitti> tseliot: ah, nvidia-experimental is a dummy package from the tests, it never existed in actual ubuntu
<tseliot> pitti: we had nvidia-$ver-experimental at some point, but the version was in the name too
<pitti> so this looks like an issue/regression in python-apt, or something missing in the fake apt repo setup
<tseliot> oh
<pitti> in test_system_driver_packages_chroot() there is no nvidia-experimental being set up
<pitti> only in test_system_device_drivers_chroot()
<pitti> so that somehow seems to leak to the other test
<tseliot> pitti: also the error on arm64 seems to be different
<tseliot> an AssertionError vs the KeyError on armhf
<pitti> tseliot: probably the same issue, though -- the apt cache is bogus
<tseliot> :/
<pitti> aptdaemon and python-apt didn't change, but apt did
<tseliot> pitti: shall we just skip the test for now? I'm trying to get a fix into wily before I actually SRU it
<pitti> no, please don't skip it
<pitti> this is an actual regression or bug somewhere which should be investigated
<tseliot> no doubt about it being a bug that needs to be fixed
<pitti> and it's not likely to be specific to armhf, I guess it would randomly occur on any arch; so doing a few test builds in wily-proposed locally would be a good first step?
<pitti> the fix is committed to git already, so you can SRU it anyway
<tseliot> pitti: ok, it works for me then
<dholbach> flexiondotorg, will take a look
<flexiondotorg> dholbach, Thanks!
 * zyga recalls a discussion about [dg]conf sandboxing 
<zyga> and recalls the path issue
<zyga> and recalls windows virtual store feature
<zyga> http://www.codeproject.com/Articles/66275/Windows-Vista-File-and-Registry-Virtualization
<dholbach> LocutusOfBorg1, I'll update the changelog entries in the patches on 1417563, ok?
<jamespage> anyone know whether its possible to use multicast on the launchpad builders?
<jamespage> (context - http://paste.ubuntu.com/11077249/ - test failure in designate)
<jamespage> interestingly that works just fine in a virtualized PPA builder
<cjwatson> jamespage: don't think we really define that either way
<cjwatson> that's a kernel module, I suppose?
<jamespage> cjwatson, maybe - I was just surprised by the diff between virtualized ppa and distro builders
<cjwatson> jamespage: well, everything will become more like the former soonish
<cjwatson> it's a bit odd, I would have expected that kind of module to be autoloaded IIRC
<jamespage> cjwatson, it might be the SO_REUSEPORT flag that's actually prohibited
<jamespage> that does have some security implications I guess
<jamespage> cjwatson, what kernel do the distro builders run on?
<cjwatson> jamespage: look at the top of any build log
<jamespage> yeah - sorry - just realized that
<jamespage> its 3.2.0
<cjwatson> right, and reuseport was 3.9
<jamespage> cjwatson, yeah - https://git.openstack.org/cgit/openstack/designate/commit/?id=c09a295c403e19811bf748d88155b368412c31bd
<jamespage> looks like upstream have a workaround
<jamespage> picking that now
<cjwatson> and the virt builders are 3.13
<cjwatson> oh, right, the non-virt builders are still on precise base systems
<cjwatson> we won't be fixing that directly, we'll be moving all builds into scalingstack architecture by architecture instead
<cjwatson> (well, some of the non-virt builders, it varies)
<LocutusOfBorg1> dholbach, please hold on, I can update them :)
<LocutusOfBorg1> seems that Debian has new releases ready
<dholbach> LocutusOfBorg1, it's done already
<dholbach> @pilot out
* udevbot 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:
<LocutusOfBorg1> dholbach, thanks!
<dholbach> anytime
<pitti> smoser: hey Scott! do you plan to merge cloud-utils with Debian? (I'm interested in the fix for debian bug 783826), or is cloud-utils independently maintained in Ubuntu?
<ubottu> Debian bug 783826 in cloud-utils "cloud-utils: growpart uses deprecated sfdisk options" [Important,Fixed] http://bugs.debian.org/783826
<cyphermox> good morning!
<cyphermox> @pilot in
* udevbot 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: cyphermox
<smoser> pitti, i have a fix for that . do we have htat sfdisk in ubuntu now?
<pitti> smoser: in wily-proposed
<smoser> ok. let me see if i can't get it uploaded.
<pitti> smoser: it doesn't migrate as it curently unconditionally Breaks: cloud-utils; that'll become versioned once cloud-utils gets fixed
<pitti> smoser: i. e. it's "safely" stuck in -proposed, I mostly wanted to know how we apply the fix
<smoser> cloud-utils is in ubuntu, debian maintain separately.  i should probably look to merge with them at some point. lp:~smoser/cloud-utils/growpart-sfdisk-2.26 has the fix .
<pitti> smoser: ah, you developed that independently? fedora and Debian have a fix too
<pitti> smoser: ok, thanks! I'll adjust the Breaks: in util-linux once this hits wily, then it can migrate
<smoser> pitti, well, i kind of re-impleented what htey had.
<smoser> this new path with sfdisk 2.26 actually gets us to a point where we could use sfdisk for gpt partition table growth also.
<xnox> doko: can you make -Wabi the default in debian & ubuntu and then grep logs / make buildd log scanner pick them up ( https://qa.debian.org/bls/ ) i guess it would already, no?
<doko> xnox, did you check, what it will pick up? because nobody did this experiment
<xnox> doko: well, actually that's the wrong one. I'm after -Wabi-tag as per dual abi docs https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html
<xnox> doko: boost started to intentionally use 03 abi string et.al. in a few places because they started to get bug reports about mixed abi.
<xnox> or rather use things that didn't change abi.
<xnox> Not all uses of the new ABI will cause changes in symbol names, for example a class with a std::string member variable will have the same mangled name whether compiled with the old or new ABI. In order to detect such problems the new types and functions are annotated with the abi_tag attribute, allowing the compiler to warn about potential ABI incompatibilities in code using them. Those warnings can be enabled with the -Wabi-tag option.
<xnox> that's what i'm afraid off.... when symbol names mangle the same way, but are in fact different.
<doko> argh
<xnox> doko: looking at fedora they did f22 release with gcc-5 but changed _GLIBCXX_USE_CXX11_ABI to be 0
<doko> no, cxx11 symbols mangle differently
<xnox> and they ware doing f23 release with _GLIBCXX_USE_CXX11_ABI to 1. Not sure if that's good or not.
<doko> yes, they didn't have the time
<doko> suse is doing it directly
<xnox> "for example a class with a std::string member variable will have the same mangled name whether compiled with the old or new ABI." -> surely things will explode if something uses that member variable in 03 & 11 context, no?!
<smoser> pitti, just realized util-linux should break cloud-guest-utils, not cloud-utils. i think.
<pitti> smoser: ah, Debian didn't split it; sure, I'll adjust that together with the versioned breaks: then
<doko> xnox, who says this? note, that currently can't check this without a custom build, had to disable the dual abi
<xnox> doko: call me conservative, but when upstream docs say "things can break" i give them a benefit of a doubt that "the world will be on fire"
<xnox> ... and given latest election results, we are all conservative here in the UK, supposedly. ( /me ponders if Laney will find this comment funny )
<doko> xnox, which upstream, boost or libstdc++?
<xnox> doko: boost.
<xnox> doko: libstdc++ did it for e.g. exceptions. (internally)
<xnox> doko: well, some portions of boost upstream (maintiner of boost-filesystem for example did that)
<xnox> but they do believe it is not sustainable.
<doko> yes, the old experimental c++11 abi and the new stable c++11 abi are not compatible
<doko> that's the reason why I disabled the dual abi for now
 * Laney votes for xnox 
<infinity> Unit193: It's in the trusty branch.
<bdmurray> mpt: Do you have a suggestion on what color to use for Wily in the Error Tracker?
<mpt> bdmurray, the current sequence goes through the primary and secondary colors ROYGBV â¦ Have we gone through a complete cycle of that? (I donât remember, and canât tell while bug 1073560 and bug 1053410 are unfixed)
<ubottu> bug 1073560 in Errors "Legend doesn't scale to the number of versions shown" [Medium,Confirmed] https://launchpad.net/bugs/1073560
<ubottu> bug 1053410 in Errors "Graph doesn't go back as far as the first recorded errors" [Low,Triaged] https://launchpad.net/bugs/1053410
<mpt> bdmurray, if we havenât, the answer is easy. :-) If we have, maybe repeat the cycle but go lighter
<mpt> (since âby 12.04 standardsâ makes hardly any difference any more)
<bdmurray> mpt: 15.04 is the bright green https://errors.ubuntu.com/?release=Ubuntu%2015.04&period=day
<mpt> Ah, right, so weâve already started the âgo lighterâ cycle, since 12.04 was dark green
<mpt> which means that Wily would be â¦ light blue?
<mpt> a lighter blue than 12.10
<ogra_> pitti, dont you like #snappy anymore ?
<ogra_> :)
<pitti> ogra_: ah, must have lost it in last bip reconnect, sorry
<doko> jamespage, maven mismatches ...
<markelite> UK
<markelite> no, ignore that
<elfy> ok
<smoser> is it sane/possible to Recommends with an |
<smoser> i'd like:
<smoser> Recommends: util-linux (>= 2.26) | gdisk
<smoser> slangasek, ^ ?
<slangasek> smoser: that's legitimate, sure
<smoser> ok. thanks.
<lifeless> IIRC left hand is chosen in the absence of any other constraints
<smoser> yeah, that shwat i thought
<slangasek> yes
<slangasek> so in this case you probably want gdisk | util-linux (>= 2.26), to force install of gdisk to satisfy the recommends on those systems too old to have util-linux 2.26
<smoser> ?
<smoser> really ?
<smoser> i dont follow that.
<smoser> if the left hand side matches (util-linux >=2.26) then that is preferable.
<smoser> no?
<smoser> oh well. /me assumes slangasek is right and uploads and goes afk
<smoser> pitti, just uploaded 0.27-0ubuntu16 which should work
<slangasek> smoser: if util-linux 2.26 is already installed, the recommends is a no-op
<slangasek> but if it's not installed that probably means it's not available
<slangasek> smoser: however this is all a corner case
<smoser> k. thanks.
#ubuntu-devel 2015-05-12
<pitti> Good morning
<Unit193> Howdy.
<pitti> smoser: cool, thanks! updating util-linux then with adjusting the package in breaks: and versioning it
<pitti> utlemming, smoser: hmm - http://cloud-images.ubuntu.com/wily/20150511/ says "vivid-*"?
<dholbach> good morning
<Unit193> LocutusOfBorg1: Howdy.
<LocutusOfBorg1> hi Unit193
<LocutusOfBorg1> can anybody please retry casablanca/wily?
<LocutusOfBorg1> thanks
<xnox> slangasek: congrats on level-up! =)
<cjwatson> pitti: ok, fixing that ddeb-retriever crash is now waiting for RT#81133
<pitti> cjwatson: thanks; I'm glad we don't lose ddebs any more :)
<cjwatson> (LP rollout including r17493 which adds build.source_package_name)
<cjwatson> pitti: indeed, it will just be delayed but should catch up fine
<cjwatson> pitti: I considered the workaround option of manually bumping the threshold past the offending build and setting it back later to retry, but this is safer
<smoser> pitti, talk to utlemming about it, but they're still getting wily builds going.
<pitti> smoser: ok, thanks (I pinged him as well); just wanted to make sure that this is known
<pitti> vrr, sil2100: wrt. updating -touch langpacks automatically: where should these go? post-release they usually go into https://launchpad.net/~ubuntu-langpack/+archive/ubuntu/ppa/+index?field.series_filter=vivid and are SRUed to vivid once a month
<pitti> vrr, sil2100: but I figure that might not be what we want? should the updates be uploaded to the overlay PPA?
<pitti> (automatically)
<sil2100> pitti: hey! I think touch langpacks could go directly to the overlay as this is what was happening for RTM
<sil2100> So I suppose it might make sense here as well
<pitti> sil2100: right, my toughts
<sil2100> +1 on that :)
<pitti> sil2100: tested with one package: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+sourcepub/5060036/+listing-archive-extra
<pitti> seems to work
 * pitti scriptifies it
<LocutusOfBorg1> ping, can anybody please retry casablanca? the newer gcc-5 might have fixed the build failure :)
<pitti> LocutusOfBorg1: done
<LocutusOfBorg1> thanks :)
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/casablanca/2.4.0-2/+build/7389439
<LocutusOfBorg1> doko_, ^^^ actually the new libstdc++ and gcc-4.9 makes the build fail
<LocutusOfBorg1> I'm going to upload with g++5 forced in the b-d
<LocutusOfBorg1> (of course if this is ok for you)
<cjwatson> pitti: ddebs should be fixed now
<pitti> cjwatson: \o/ cheers
<mdeslaur> slangasek: happy birthday! :)
<caribou> Is there a way to be sure that an upstart job terminates before RUNLEVEL is emited ?
<pitti> caribou: doesn't "start on starting rc RUNLEVEL=[2345]" do that?
<caribou> pitti: no, I didn't get much luck with this one when you suggested last week
<xnox> caribou: and "task"
<xnox> pitti: ^
<pitti> ah :)
<caribou> xnox: so start on starting rc RUNLEVEL=[2345] and task ?
<xnox> caribou: no
<xnox> task
<xnox> start on starting rc RUNLEVEL=[2345]
<caribou> ah, ok let me try that...
<xnox> caribou: this way "started" will only be emitted, when the thing exits.
<xnox> caribou: aka systemd Type=oneshot RemainAfterExit=true
<caribou> xnox: good as the task is kdump & it will trigger a reboot
<smoser> hey. what am i doing wrong....
<smoser>  echo "manual" > /etc/init/pollinate.conf.override
<smoser> but job still runs
<smoser> in trusty.
<xnox> smoser: echo "manual" > /etc/init/pollinate.override
<xnox> smoser: .override is the right extension...
<smoser> xnox, bah.
<smoser> thank you very much
<didrocks> slangasek is spamming wily for his birthday :)
<didrocks> I guess someone has found the "publish all silos" button
<seb128> didrocks, or rather syncing the overlay ppa to wily?
<seb128> or pocket copying it over
<Laney> timely ...
<didrocks> seb128: I guess you are right
<pitti> oh, I'm just copying my two uploads from the PPA to wily, is this being done en masse now?
<didrocks> pitti: seems so from -changes
<slangasek> xnox, mdeslaur, didrocks: actually I lied to Google about my birthday, this is the first time I've ever known them to pass this lie on to people.. :)
<mdeslaur> slangasek: well, happy birthday anyway, you've used up your one birthday wish for the year.
<pitti> slangasek: oh, then I won't say congrats :)
<slangasek> :-)
<didrocks> slangasek: google can't be wrong, so happy birthday anyway! :p
<mdeslaur> slangasek: google also tells me you're 23, I gather that's a lie too?
<didrocks> heh
<seb128> slangasek, congrats, your birthday officially got updated to today ;-)
<xnox> wait what, i'm not older than slangasek ?! phhhh
<slangasek> mdeslaur: it does? that's interesting, because I told google I was born in 1945
<mdeslaur> slangasek: hehe
<pitti> oh dear, the interweb is wrong.. https://xkcd.com/386/
<cjwatson> slangasek: happy 70th birthday, then
<slangasek> :-)
<pitti> slangasek: do you know what britney does with the packages which are newer in wily than in your copied wily-proposed packages? (top of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html)
<pitti> slangasek: I assume we just remove them manually?
<slangasek> pitti: oh I assumed they would have failed to upload.  if not, then yes we should manually remove
<pitti> slangasek: I guess they would have, but copy-package doesn't seem to do that check apparently
<cjwatson> Copies are allowed to go backwards
<cjwatson> You're meant to check :)
<slangasek> noted :)
<cjwatson> pitti,slangasek: I can't quite remember the rules; if I were you I'd check publishing histories to make sure that there were no cases where there was already something in wily-proposed
<utlemming> pitti: s/vivid/wily for future builds of Wily
<utlemming> pitti: the next builds should be okay
<pitti> utlemming: :) thanks for preparing wily images, much appreciated
<pitti> fginther: ^ FYI (for autopkgtest CI)
<shadeslayer> rbasak: do you reckon docker.io can be backported to utopic?
<shadeslayer> bah
<shadeslayer> needs new libdevmapper1.02.1
<shadeslayer> :(
<fginther> utlemming, pitti, yes, thanks
<rbasak> shadeslayer: that's the plan. To Trusty too. I have 1.6.0 working on Trusty in testing, though not ready for upload yet. I didn't hit your libdevmapper issue though, so I'm a bit confused about that.
<rbasak> shadeslayer: what's your issue exactly?
<shadeslayer> rbasak: I just tried to install the willy package on utopic
<shadeslayer> hoping it would work ;)
<shadeslayer> but clearly not, rebuilding it now
<rbasak> shadeslayer: oh, I see. Rebuilding it should work I think.
<shadeslayer> rbasak: and hurray @ backporting \o/
<shadeslayer> rbasak: yeah
<shadeslayer> kind of sucks that docker doesn't provide arm packages
<rbasak> It should work on arm.
<shadeslayer> yeah it does
<rbasak> Vivid supports ppc64el too - IBM enabled it. So general cross-platform support should be there.
<shadeslayer> nice
<rbasak> shadeslayer: I'd appreciate some help with testing when it hits trusty-proposed if you're up for that.
<shadeslayer> let me check
<rbasak> Maybe in a week or two.
<shadeslayer> rbasak: yeah can do
<rbasak> Thanks! I'll ping you when it hits -proposed.
<shadeslayer> cool
<shadeslayer> thanks to you too :)
<shadeslayer> rbasak: https://paste.kde.org/paykz2byz
<rbasak> shadeslayer: oh yeah, sorry. I forgot about that.
<shadeslayer> utopic has 1-1 apparently
<shadeslayer> rbasak: reckon just downgrading the deps wil lwork
<rbasak> In my backport I started embedding the dependencies, but the conclusion is to push the build deps back to each stable release as well.
<rbasak> I'm not sure downgrading them will work - I think various things need newer features.
<shadeslayer> ah
<rbasak> shadeslayer: I can give you a work in progress diff that embeds the dependencies if you want it.
<shadeslayer> yes plz
<rbasak> shadeslayer: try http://people.canonical.com/~rbasak/docker-wip/docker.io_1.6.0+dfsg1+revendor-0ubuntu0.14.04.1~dev1.dsc
<rbasak> That embeds the build deps, which is no longer the plan, but I think it builds OK on Trusty.
<shadeslayer> rbasak: trying, though this is on utopic
<rbasak> shadeslayer: I'm not aware of any reason it should fail on Utopic.
<shadeslayer> ok
<pitti> stgraber, infinity, kees, slangasek, mdeslaur: TB meeting now, right?
<mdeslaur> pitti: yep
<rbasak> shadeslayer: btw, you might want to be aware of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=784726. We expect to have 1.6.1 merged in wily this week, and when I prepare the backports for upload they will be 1.6.1.
<ubottu> Debian bug 784726 in src:docker.io "docker.io: CVE-2015-3627 CVE-2015-3629 CVE-2015-3630 CVE-2015-3631" [Grave,Fixed]
<shadeslayer> oh
<shadeslayer> hm, thank
<shadeslayer> *thanks
<shadeslayer> rbasak: seems to have built, thanks
<hallyn> infinity: arges: when you talk about SRUing the kvm-on-all-arches bug, is bug 1369785 what you are talking about?
<ubottu> bug 1369785 in qemu (Ubuntu) "kvm modules not autoloaded on ppc64el" [High,Fix released] https://launchpad.net/bugs/1369785
<infinity> hallyn: "kvm-on-all-arches" sounds like a description of having a functional /bin/kvm (and the kvm package) on all arches.
<infinity> hallyn: So other packages can depend on and rely on it.
<infinity> hallyn: But that autoload bug is also important.
<infinity> s/kvm package/qemu-kvm package/
<arges> hallyn: infinity we would probably need to do ppc64_cpu --smt=disable (or whatever the command is)
<arges> before modprobing that module? or would that be something we do when we launch the actual instance
<infinity> arges: It's not required to have the module loaded, just to actually start akvmish qemu.
<infinity> s/akvmish/a kvmish/
<arges> infinity: so whose responsibility would it be to disable smt? qemu?
<arges> or the user
<infinity> arges: I'm not sure we're ever sorted out exactly who should be perpetrating the hack.
<infinity> arges: Ultimately, it's a qemu bug that requires it, but it's a Very Hard bug to fix.
<arges> yea
<infinity> arges: I wouldn't be against the init/systemd jobs doing an [ -x /usr/sbin/ppc64_cpu ] && disable_smt, under the assumption that if you have qemu-ppc installed *and* you're on a PPC host, you probably intend to use KVM at some point.
<hallyn> sounds like i'm out of my depth
 * hallyn needs to gethisself a p8 box :)
<infinity> hallyn: You and me both.
<arges> : )
<infinity> Lemme double-check that /usr/sbin/ppc64_cpu doesn't explode nastily when run on a machine that doesn't support it.
<hallyn> ok - sounds like i need to make this something to look into separately, and not part of today's SRU
<arges> yea i think we should make qemu work similar to amd64
<infinity> hallyn: Yeah, I think we'll want one big "ppc packaging fixes" roundup SRU.
<infinity> hallyn: That said, I'm about 95% sure that LE hosts don't work on trusty's qemu anyway, without some patches backported from 2.1, which IBM has yet to identify.
<hallyn> fun
<hallyn> ok, thanks, hopefully after ODS i can dig in
<infinity> Oh, FFS.  Thanks, IBM.
<infinity> Can't even call ppc64_cpu unconditionally.  Exits non-zero on non-SMT CPUs.
<infinity> I guess we can just || true it and carry on with life.
<arges> hallyn: so back to your bug... should we be SRU'ing that to T/U/V?
<arges> should i target it as such
<infinity> V should be all fixed, except for the SMT thing we were just discussing.
<infinity> The goal would be to make T and U look like V.
<arges> ok adjustin
<hallyn> arges: well, as i recall infinity was the one who had asked for this, so i just wanted to make sure he has what he needs.  so whatever satsifies him
<infinity> hallyn: Nothing will ever satisfy me.
<hallyn> snickers?
<arges> hehe
<infinity> Maybe!
<infinity> Anyhow, I think the goal should be for the qemu-kvm packaging to look like vivid, since that seems to be where we finally got it mostly right for arm64/ppc64el.
<infinity> And we should also fix the smt-disabling thing while we're at it.
<hallyn> which isn't yet fixed in vivid/wily right?
<mdeslaur> deep fried bacon snickers?
<hallyn> ok, thx, i'll make a note of all this for in ... a few weeks
<infinity> Actually, wait, did we get it right?
<infinity> Oh.  I'm looking on an x86 system, and the builds are more "clever" than that.
 * infinity grabs a ppc version of qemu-system-ppc
<infinity> Okay, no, it's still not quite right in vivid. :P
<infinity> And, indeed, with the upstart->systemd switch in vivid, it's actually actively broken on vivid.
<hallyn> hm, why does pull-lp-source not know about wily yet
<hallyn> (on my wily laptop)
<infinity> hallyn: Because you need to upgrade?
<infinity> hallyn: I'd assume your distro-info-data is out of date.
<hallyn> hm, i updated yesterday... one more for good measure
<infinity> hallyn: Works for me with distro-info-data 0.27
<hallyn> infinity: bah.  now it works.  but distro-info was last updated on may 10.  weird
<hallyn> oh, well, it works, happy :)
<jdstrand> bdmurray, arges: hey, I was wondering if someone could look at bug #1450642. I fixed the version issue last week
<ubottu> bug 1450642 in libseccomp (Ubuntu Vivid) "seccomp missing many new syscalls" [Undecided,In progress] https://launchpad.net/bugs/1450642
<arges> jdstrand: taking a look
<arges> jdstrand: so would this be worth backporting to trusty, since we'll be supporting lts-vivid at some point
<arges> is it backwards compatible with 3.13/3.16?
<luist> how do i remove unity completely and use gnome classic as default?
<jdstrand> arges: it should be backwards compatible-- it is just a list of calls that the library knows about. that said, that would need to be tested. that said, trusty userspace running with an lts-vivid kernel still had the userspace compiled on the lts-release kernel, so software won't know to use the new syscalls
<jdstrand> so I don't think it is actually required
<jdstrand> this bug is the inverse of that though
<jdstrand> software compiled on a system with a new kernel headers (and therefore knowing about the new syscalls) not working because libseccomp wasn't updated
<jdstrand> well, the software works-- it is just denied when run under certain seccomp filters (like on snappy)
<arges> jdstrand: ack.
<arges> jdstrand: ok accepted into vivid-proposed
<jdstrand> thanks!
<infinity> jdstrand: Which kernel headers are available when you build software have no relation to wich syscalls you can use at runtime...
<arges> yea, my question is a user could build an app against lts-vivid headers too, so this may be useful for trusty/3.19
<jdstrand> infinity: well, maybe I didn't explain it right, but software in trusty isn't going to just start using getrandom() (which was added later)
<jdstrand> just cause the kernel happens to now all of a sudden support it
<infinity> arges: We don't build userspace lts-vivid headers, which was jdstrand's point (linux-libc-dev is 3.13), but one can invoke syscalls directly that glibc/linux-libc-dev don't know about.
<infinity> jdstrand: But yeah, a fair point that software we ship shouldn't be using syscalls that don't appear in 3.13
<arges> gotcha
<infinity> jdstrand: Out-of-archive software, OTOH.  I guess that depends on seccomp's use cases.
<jdstrand> libseccomp's use on trusty is mostly limited to lxc. but they use a blacklist, so it too shouldn't be needed
<jdstrand> (ie, the new ones just magically are allowed)
<jdstrand> snappy uses a whitelist though, so the out of date libseccomp was causing some issues cause we'd get a denial and no way to allow it
<irl> hi, anyone here a launchpad admin of some sort?
<irl> need some help with someone claiming email addresses that do not belong to them
<irl> they appear to be impersonating the debian hamradio team
<infinity> irl: Context?
<irl> https://launchpad.net/~frank-duron
<irl> we got an email to our mailing list saying he was merging the account
<irl> and now debian-hams@lists.d.o shows on his page
<infinity> A valid reason for lists to be moderated.
<irl> which it shouldn't do, because i've never heard of him
<irl> infinity: that would make life difficult
<irl> massively difficult
<infinity> irl: Yeah, I know.  We can get the address removed again.  But it's a fundamental flaw with email validation of any sort.  Anyone who can recieve the email can clik the "yeahp, this worked" link.
<infinity> (Same for signing up for mailing lists, etc)
<irl> ok, so can you remove the address?
<infinity> irl: On it.
<irl> and maybe bar the address from being used?
<irl> in fact, could you bar @lists.debian.org from being any kind of authority on who owns the address
<infinity> cjwatson: Is there a blacklist of address patterns humans can't use?  Seems like allowing people to sign add mailing lists to their accounts is less than ideal.
<infinity> s/sign //
<infinity> irl: It's removed from his account.  We'll discuss blacklisting out of band.
<irl> ok
<speck84> hiya guys can somebody tell me how can i set my html5 app into portrait mode only?
<sarnold> speck84: perhaps #ubuntu-touch is more appropriate?
<speck84> they sent me here
<sarnold> oh :)
<sarnold> carry on then
<speck84> cheers
<speck84> here are the pro's
<dobey> speck84: #ubuntu-app-devel is the channel you want i think
<speck84> thx dobey but is a back to forward thing they told me to come here
<speck84> anyway somebody just know it I still digging the gogle
<speck84> I can't immagin noone ever faced with this situationn before
<dobey> no, ubuntu-app-devel didn't tell you to come here
<dobey> i am in there and you are not, and i see no previous conversation from you in there within the last couple of hours
<cjwatson> infinity: I don't believe so, other than syntactic validity.  Trying to blacklist lists is probably doomed to failure ...
<infinity> cjwatson: Perhaps, yes.
<infinity> cjwatson: In this case, I don't think it was someone specifically adding foo@lists.d.o to his account anyway, it was a side-effect of the silly "create an account for every email address in Packages.gz" thing we did ten years ago, and then someone attempting to merge that account with his onw.
#ubuntu-devel 2015-05-13
<slangasek> barry: bug #1454457 - do you recall where we ended up wrt stable device identifiers?
<ubottu> bug 1454457 in Ubuntu system image "Update fails on lack of space, after factory reset still won't update" [Undecided,New] https://launchpad.net/bugs/1454457
<kgunn> robert_ancell: hey, how's life ?
<kgunn> got a question just now, thot you might know a trick....
<kgunn> so i've hit this twice now, where i want to install a ppa on the phone...and since phone is now vivid+overlay ppa
<kgunn> overlay is newer than the ppa i want to install...so it doesn't install the debs i want
<kgunn> is there some trick, possibly with apt source list file naming or something...
<kgunn> to always pick a particular ppa regardless of which one is newer
<kgunn> ?
<sarnold> kgunn: apt_preferences(5) describes some pinning that may be able to help
<kgunn> thanks!
<kgunn> seems i recall "pinning" from some forgotten time
<sarnold> (it doesn't mention ppas, and the location seems to be based on server name, so it might not actually work out..)
<robert_ancell> kgunn, yeah, pinning is what you want
<kgunn> robert_ancell: sarnold ...thanks guys, worked
<tbharath_> can we find some articles on how to develop lxc templates?
<pitti> Good morning
<pitti> utlemming: ah nice, ! now we just need a /current symlink, and we're all set?
<dholbach> good morning
<sitter> ScottK, cjwatson: syslinux-themes-ubuntu-wily needs proding through binary NEW if you can find a minute
<infinity> sitter: Done.
<sitter> cheers
 * mgedmin wonders if https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/1384188 will finally be fixed for 15.10?
<ubottu> Launchpad bug 1384188 in gfxboot-theme-ubuntu (Ubuntu) "Missing translations for 'Install Ubuntu GNOME' and 'Try Ubuntu GNOME without installing'" [Undecided,Fix released]
<mgedmin> ugh, I meant https://bugs.launchpad.net/ubuntu/+source/gfxboot-theme-ubuntu/+bug/1442586
<ubottu> Launchpad bug 1442586 in gfxboot-theme-ubuntu (Ubuntu) "gfxboot-theme-ubuntu needs an update with new translations export" [Undecided,New]
<Mirv> mgedmin: most probably that should have been updated for vivid indeed.
<Mirv> cjwatson: who should be pinged on reviewing why gfxboot-theme-ubuntu wasn't updated for vivid as per https://wiki.ubuntu.com/ReleaseProcess ?
<infinity> Mirv: The why is probably simply because that was something cjwatson used to do and it slipped through the cracks while we tried to pass his bits around to everyone else.
<cjwatson> Mirv: I think mathieu-tl now, but honestly the "why" is probably basically "fell through the cracks because cjwatson moved to" ... that.
<Mirv> right, that explains it
<LocutusOfBorg1> hi folks
<ogra_> sil2100, ugh, someone imported ubuntu-touch-meta from the vivid PPA to wily ... do you know if the wily seeds have been adjusted accordingly ?
<sil2100> ogra_: uh, well, I think simply all packages were copied
<sil2100> So I guess nothing was adjusted
<ogra_> the former chuck has slangasek's signature
<ogra_> this one came alone and signed by a bot
<ogra_> *chunk
<ogra_> oh
<ogra_> that was just the migration from proposed ... ignore me :P
<pitti> sil2100: btw, do you forward-copy with or without binaries?
<ogra_> (it was actually in the set from yesterday)
<pitti> (rebuilds would be more correct, as wily has a newer toolchain, etc.)
<sil2100> pitti: that was a binary copy still - a rebuild would require each version number to be changed before upload
<pitti> sil2100: why?
<pitti> oh, in case someone wants to dist-upgrade from vivid+PPA to wily?
<pitti> (seems like a corner case to me, but *shrug*)
<pitti> copying binaries seems wrong as well
<pitti> they might not even be installable, due to different shlibs (that'll be caught in -proposed, but still)
<sil2100> pitti: since we don't want to lead to a situation where we have 2 packages with same version numbers with different binaries, where a dist-upgrade is certainly possible for touch
<sil2100> It was just a one-time operation
<sil2100> We don't intend to do any more binary copies :)
<pitti> ah, it sounded like we'd regularly do this from now on
<sil2100> Nooo
<sil2100> No way
<pitti> ah, ok; ignore me then :)
<caribou> xnox: remember my task & start on rc RUNLEVEL=[2345] question of yesterday ?
<xnox> caribou: si
<xnox> caribou: what's your actual problem/but that you are trying to solve with above?
<caribou> xnox: kdump-savecore must complete before any job started by 'runlevel' starts
<caribou> xnox: For instance the CEPH OSD's start while kdump is dumping a kernel dump, hence eating up all  the memory
<caribou> xnox: triggering OOM during kexec session which has limited memory
<xnox> caribou: .... and what does kdump-savecore require? you either will not have any writable filesystems to do so, or other things will be running....
<caribou> xnox: it requires that root be mounted rw
<caribou> xnox: i.e. just before the rc-sysinit emits the 'runlevel' event
<xnox> one can do it with systemd... where you can make this thing a dependency of the basic target.
<caribou> xnox: problem is trusty specific
<caribou> xnox: I fixed it with systemd & it works fine
<caribou> xnox: trusty currently uses a sysvinit script, but it doesn't block upstart jobs from starting
<xnox> yeah, keying on to rc is to late
<caribou> xnox: so I'm switching kdump to an upstart job on trusty for that reason, but the upstart job must terminate before runlevel jobs start
<xnox> task
<xnox> start on starting rc-sysinit
<xnox> ..
<xnox> but it means that you will be executed each time there is a switch between runlevels
<xnox> thus you'd need to handle that gracefully.
<caribou> xnox: doesn't seem to work if I used 'starting on rc' as suggested yesterday
<xnox> caribou: yes rc is just after, but rc-sysinit should be just before...
<xnox> reading it again.
<xnox> caribou: or better use initctl2dot to get a full graph and figure out where you need to be.
<caribou> xnox: that's what I thought. & Yes, I found out about jodh initctl2dot already :-)
<caribou> xnox: thanks!
<infinity> xnox: Will that make rc-sysinit block on his job, or is there a different and special way one can achieve that?
<infinity> Cause if his concern is that he needs to run *before* sysv, the last thing he'd want it to end up being in parallel with it.
<infinity> s/it/is/
<xnox> infinity: start on starting -> blocks until one starts. "task" makes one emit "started" only after one quits.
<infinity> Ahh. shiny.
<caribou> infinity: yeah, looks like it's blocking normal boot
<infinity> Things I never bothered to learn, and no longer need to...
<xnox> infinity: it's Type=oneshot RemainAfterExit=true in the new world order.
<caribou> might need to tweak my job a bit
 * xnox cannot get enough of https://youtu.be/Q5lxM6uGr54
<infinity> xnox: I don't mean to alarm you, but you might be a 17-year-old white girl.
<xnox> infinity: dunno, but quiting everything and moving to surf in costa rica sounds attractive right about now.
<infinity> Heh.
<pitti> jdstrand, sbeattie: OOI, do you plan to merge apparmor with Debian for wily?
<diwic> hmm, I'm trying to use git-buildpackage and it just gives me an _amd64.changes, not a _source.changes like "dpkg-buildpackage -S" does. Do I dare to dput the _amd64.changes file or is that stupid?
<cjwatson> dputting it to Launchpad will get you a rejection.
<diwic> ok
<ogra_> diwic, sounds like to built a binary and not a source package
<rbasak> git-buildpackage -S should give you a _source.changes.
<rbasak> git-buildpackage takes all the same parameters that dpkg-buildpackage does.
<diwic> rbasak, thanks
<diwic> I'll try that
<pitti> it's "gbp buildpackage" now, FTR
<pitti> (has been for a few years, but in wily the git-* aliases got removed)
<xnox> pitti: you mean $ dgit sbuild, right?!
<xnox> =))))) </giggle>
<diwic> pitti, gbp ? okay
<kalxas> hi all, I am having a problem: I use travis CI on GitHub for testing my python application and I need libxml2 >= 2.9.0 for validation purposes. The problem is that I have not found this version in precise backports or in Launchpad. So I tried myself and I am stuck a bit. Could someone take a look at my ppa for some hint?
<kalxas> https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/ppa-tzotsos/+packages
<diwic> thanks everyone
<kalxas> I would really appreciate a hint on this problem. libxml 2.8.0 builds fine and finds Python.h in UbuntuGIS
<kalxas> https://launchpad.net/~ubuntugis/+archive/ubuntu/ubuntugis-unstable/+sourcepub/2892970/+listing-archive-extra
<barry> slangasek: no.  also, are you sure about that bug #?
<cjwatson> kalxas: The stuff in debian/rules probably wants to be just python-config rather than $(DEB_HOST_GNU_TYPE)-python-config for precise (similarly for python-dbg-config).  The multiarch python-config names weren't introduced until python-defaults 2.7.3-10 in December 2012, which was after precise.
<kalxas> cjwatson, thanks!
<kalxas> will try and report back
<pitti> xnox: btw, did you see that Lennart reviewed your "runtime preset" patch a few weeks ago?
<xnox> pitti: i did, but i didn't have time to reply yet. Busy with something else at the moment.
<xnox> pitti: i don't believe he is right in his review... as without checks runtime presets default to "enable *" and there lies madness.
<xnox> pitti: but need to test this first.
<pitti> xnox: ack, just wanted to confirm that you saw it, as it took a while to get reviewed
<xnox> yeah
<xnox> we are using it in clearlinux.org, and it's alright. But we don't like that it delays boot =(
<kalxas> cjwatson, thank you very much for your help! https://launchpad.net/~gcpp-kalxas/+archive/ubuntu/ppa-tzotsos/+build/7424658
<slangasek> barry: yes, that's the bug number, see comment #1 :)
<cjwatson> kalxas: great, you're welcome
<pitti> xnox: delays because it has to read all units on startup, not just the enabled ones?
<xnox> pitti: yes.
<xnox> pitti: and it doesn't cache them....
<xnox> pitti: speaking of which.....
<smoser> hey. i'd appreciate someone reading https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1443542
<ubottu> Launchpad bug 1443542 in curtin (Ubuntu) "curtin race on vivid when /dev/sda1 doesn't exist" [Undecided,Confirmed]
<smoser> input on my final comment (#4) would be appreciated.
<smoser> basically i assume:
<smoser>  a.) <some-partition-table-operation>
<smoser>  b.) blockdev --rereadpt /that/block-device
<smoser>  c.) udevadm settle
<smoser> will guarantee that partitions created in 'a' will exist in /dev
<ogra_> dont you need a "udevadm trigger" too ?
<ogra_> or is rereadpt enough to trigger udev
<smoser> well, it certainly *generally* is enough. to have allowed my assumption to get as far as it has.
<smoser> i imagined that 'a' makes some stuff happen in kernel, telling it to re-read ... then it sends events to udev, and 'b' is me saying "ok wait till that queue is empty".
<smoser> er... sorry. above 'b' and then 'c' for my previous statement .
<smoser> i guess that 'c' could read an empty queue if 'b' hadnt populated it.
<flyinprogrammer> anybody know how/where i might find the scripts that make the squid debs ?
<flyinprogrammer> oh maybe i should go to app-devel
<flyinprogrammer> or packaging LOL i'm an idiot - sorry guys
<hallyn> stgraber: infinity: so we have MRE for lxc;  can that be applied to lxcfs (which only exists in wily and vivid right now)?
<infinity> hallyn: I'm inclined to lump lxc and lxcfs together (and, indeed, not sure why the latter wasn't just bundled with the former in the packaging).
<hallyn> infinity: there are some bugs in vivid fixed in wily;  what would be the process right now to get the wiliy package into vivid?
<infinity> hallyn: Ask nicely, show a diff and explain the bugs fixed, and explain how it fits the general rules of the lxc MRE (no shiny new features, well-tested, blah blah).
<hallyn> in a bug opened against lxcfs?
<infinity> hallyn: Aye.
<hallyn> infinity: thanks.  will post that in a bit
<hallyn> infinity: hm, what do i call the version?  (0.7-0ubuntu4 is the old version, 0.9-0ubuntu1 is the wily version)?  do i create a 0.9-0ubuntu1~15.04.1 ?
<hallyn> going by ff example i guess 0.9-0ubuntu0.15.04.1
<infinity> hallyn: If it's a straight backport of the wily version (ie: identical source with a new changelog entry on the top), it's 0.9-0ubuntu1~15.04.1, if it's the vivid packaging with the new upstream applied, it's 0.9-0ubuntu0.15.04.1
<infinity> hallyn: We tend to prefer the latter, but if packaging changes are equally important in this case, the former works.
<hallyn> it can be a straight backport.
<hallyn> oh, you *prefer* the latter?
<hallyn> np, can do
<hallyn> thakns
<infinity> hallyn: One changelog entry that actually spells out the reason for the SRU is much more pleasant than 7 changelog entries between old and new that say "new upstream; fixed a thing" over and over.
<hallyn> cool
<infinity> hallyn: But the more usual reason for the argument is that packaging drifts over time to accomodate the rest of userspace/toolchain/etc in a newer series, and shoehorning the new upstream into the old packaging is usually the path of least disruption.
<infinity> hallyn: Probably not actually true or meaningful in this case, but yeah.
<infinity> hallyn: Anyhow, I won't reject either option, I imagine, if the result is sane, so do whatever feels more correct for the package.
<hallyn> and, i should attach a debdiff, or point to new source?
<infinity> hallyn: A diff is fine.  If the diff is unwieldly, that's usually a good sign that it's a lousy SRU candidate.
 * infinity stares at the kernel team.
<hallyn> cool, thanks.
<hallyn> posted bug 1454862, now leaving for the week (will check in tonight)
<ubottu> bug 1454862 in lxcfs (Ubuntu) "[MRE] merge 0.9 (which is currently in wily) to vivid" [Undecided,New] https://launchpad.net/bugs/1454862
<infinity> hallyn: Ta.  I'm out for the week too, but I'll open that in a tab and consider caring. ;)
<hallyn> lol
<hallyn> thanks i appreciate that :)
<cyphermox> oops.
<cyphermox> @pilot out
* udevbot 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:
#ubuntu-devel 2015-05-14
<chaos7theory> Does anyone know of a good admin GUI for Postgresql on Ubuntu 14.04 Server? I'm using Nginx but PhpPgAdmin wants me to install Apache
<jrwren> chaos7theory: pgadmin3 ?
<mwhudson> lolcopter, my "go standard library in a shared library" .so makes dpkg-shlibdeps pretty unhappy
<mwhudson> (probably because of all the spaces in the symbol names)
<sarnold> mwhudson: haha, spaces in symbol names does sound like something that would drive the linker insane :)
<infinity> mwhudson: Spaces in symbols names?  Really?  Ew.
<infinity> mwhudson: Sounds like that could use some C++ style symbol mangling.
<mwhudson> infinity, sarnold: oh yeah, there's some utf-8 too
<mwhudson> is that better or worse? :)
<mwhudson> sarnold: the linker copes fine (slightly surprisingly)
<mwhudson> shell scripts that parse the output of readelf... possibly not so much
<infinity> mwhudson: utf-8.. symbols?
<infinity> mwhudson: Is Go insane, or just your synthetic examples?
<mwhudson> infinity: the go linker coalsesces most of these symbols with silly names into one elf symbol + offset
<mwhudson> but that doesn't work for dynamic linking, so i just disabled that code
<infinity> mwhudson: Anyhow, if this is a thing that should actually be a thing, and if readelf's output is correct, it's not hard to fix dpkg-shlibdeps to DTRT.  Spaces and utf-8 in shell aren't actually hard, just unexpected in this case. :P
<mwhudson> i'm a little surprised that i never had to do anything else to make it work
<mwhudson> the utf-8 is limited, it's just interpuncts
<mwhudson> they usually get normalized to periods, but that ends up being a headache because obv it's not reversible
 * infinity nods.
<mwhudson> tbh, i don't think the linker (program or dynamic) cares at all about the contents of symbol names
<mwhudson> just a bunch of bytes
<mwhudson> i should create symbols that are differently normalized utf-8 for maximum lols
<infinity> I wouldn't be so sure that there aren't some locale-sensitive string functions in play for things like libdl.  But I guess dlopen is another thing to tackle down the road, or not at all, if you have no intent to mix-and-match C and Go in that direction.
<mwhudson> dlopen type stuff is special pain for a few reasons
<mwhudson> such as tls models
<infinity> By which, you mean, glibc is the One True TLS implementation, but others might not entirely agree? :)
<mwhudson> no, i mean le vs ie vs gd vs tlsdesc
<mwhudson> i've only found three things i want the dynamic linker to do differently in the course of this work
 * mwhudson needs to read all the debhelper documentation again i think
<xnox> infinity: and the one for today https://youtu.be/uV2uebhnqOw
<xnox> so many moves i need to study =)
<roaksoax> infinity: howdy! any update on the maas 1.7 SRU ?
<mwhudson> sigh, i wonder if there are any other packaging mistakes i can make today
<mwhudson> ah i can create broken symlinks
<davmor2> mwhudson: I have every faith in you
<infinity> davmor2: A+ sarcasm.
<infinity> roaksoax: I'm on vacation for a week, so ignoring your question for the sake of my own sanity (but I'll look more closely when I get back).
<Unit193> ...to make more mistakes, he forgot to add.
<davmor2> infinity: you're welcome :)
<roaksoax> infinity: thanks :)
<roaksoax> infinity: enjoy the holiday time and get away from a computer :) that's what vacations are for :)
<mwhudson> Unit193: that was my assumption as to meaning :-)
<mwhudson> woo:
<mwhudson> root@go1:/# go build -linkshared trivial.go && ls -lh ./trivial
<mwhudson> -rwxr-xr-x 1 root root 15K May 14 10:45 ./trivial
<mwhudson> (without -linkshared it's 1.1M)
<TJ-> Trying to backport Java 8 packages from Vivid to Trusty, I'm getting a PPA build failure for the openjfx package:
<TJ->  "Cannot find System Java Compiler". openjdk-8-jdk already built in the PPA and javac installed "update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/bin/javac to provide /usr/bin/javac (javac) in auto mode"; build log @ https://launchpadlibrarian.net/206487969/buildlog_ubuntu-trusty-amd64.openjfx_8u40-b25-1~ubuntu14.04.1~ppa1_BUILDING.txt.gz   ... anyone give me hints on this, web searches don't reveal much nor does #launchpad
<davmor2> roaksoax: no they aren't they are for test how well you can work and partake of the ubuntu community from your ubuntu powered phone aren't they or is that me :D
<roaksoax> davmor2: huh?
<rbasak> cjwatson: please could you take a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=782552? This is following up from a discussion we had on IRC a while ago - you asked that I sent to Debian instead of deltifying Ubuntu.
<ubottu> Debian bug 782552 in grub-common "recordfail false positive causes headless servers to hang on boot" [Normal,Open]
<davmor2> roaksoax: Sorry just catching up on the channel and saw your comment to infinity
<rbasak> This is something that I'd like considered for an SRU in time, too.
<roaksoax> davmor2: ah :)
<cjwatson> rbasak: Oh yes, sorry.  Committed as https://anonscm.debian.org/cgit/pkg-grub/grub.git/commit/?id=4473aff5090de389c9b5b2083c738df3b8fb91ac and uploading shortly.  Please could you organise the SRU?
<rbasak> cjwatson: no problem. Yes, I'll organise the SRU. Thanks!
<cjwatson> rbasak: (uploaded to Debian now, can be synced later)
<lathiat> cjwatson: rbasak: oh, awesome, nice patch :-)
<lathiat> ++
<barry> o/
<bdmurray> barry: How did you end up seeing the removal of the egg-info file?
<barry> bdmurray: okay, let's start at the beginning.  LP: #1324391 is the import error bug
<ubottu> Launchpad bug 1324391 in python-pip (Ubuntu) "pip 1.5.4 import an invalid dependencies " [Undecided,Incomplete] https://launchpad.net/bugs/1324391
<barry> bdmurray, doko what's the bug for the egg-info problem?
<doko> barry, did I file one?
<barry> doko: i can't find one on python-pip src pkg
<bdmurray> So I just recreated the missing egg-info by the following
<bdmurray> schroot as sudo, apt-get install python-pip, pip install httpie, pip --help
<bdmurray> (trusty-amd64)root@impulse:/home/bdmurray# debsums python-requests
<bdmurray> debsums: missing file /usr/lib/python2.7/dist-packages/requests-2.2.1.egg-info (from python-requests package)
<bdmurray> that's with -updates enabled
<barry> my chroot's broken.  while i fix that: i think that's the same repro for the import error, right bdmurray?
<bdmurray> and the same thing happens without -updates
<bdmurray> barry: that's right
<bdmurray> http://pastebin.ubuntu.com/11132197/
<barry> bdmurray: okay. so can do you do the following?  add that repro instructions to LP: #1324391.  describe that it causes both theimport error and egg-info problem
<ubottu> Launchpad bug 1324391 in python-pip (Ubuntu) "pip 1.5.4 import an invalid dependencies " [Undecided,Confirmed] https://launchpad.net/bugs/1324391
<barry> include the above output
<barry> i've reopened the bug and will assign to me
<bdmurray> barry: okay, and then what about phasing the update?
<barry> bdmurray: i'm on the fence about that ;)
<barry> not sure what the right thing to do there is
<barry> i guess, go with the plan from the meeting?
<bdmurray> slangasek: you were in favor of continuing the phasing of the SRU correct?
<slangasek> bdmurray: if that same problem (including .egg-info removal) happens both with and without -updates, then yes, I'm in favor of continuing to phase the SRU
<bdmurray> slangasek: okay, that's what I'd thought
<elopio> ogra_: do you know what's the equivalent of intitctl set-env --global Test=test in systemd?
<elopio> systemctl set-environment --global Test=test gives a permission error: Failed to get D-Bus connection
<elopio> who knows about systedm in here?
<ogra_> elopio, pitti mostly, but its a public holiday here in germany today
<elopio> yes, live is scary without pitti. He'll be away tomorrow too.
<slangasek> jodh: hi, so I've looked at merging lp:~jamesodhunt/upstart/bug-1447756-the-actual-fix; and the changes look fine to me, but I haven't landed it yet because I'm getting a test failure in test_job_process, have you seen this?
<slangasek> jodh: http://pastebin.ubuntu.com/11133446/  on a vivid system
<jodh> slangasek: ah - you've hit kernel bug 1429756 :)
<ubottu> bug 1429756 in linux (Ubuntu Vivid) "FTBFS: upstart test_job_process fails in majority of cases / Kernel returning unexpected EIO at end of file" [High,In progress] https://launchpad.net/bugs/1429756
<slangasek> jodh: mm ok
<slangasek> jodh: the bug history shows apw asking you for a test of his kernel, did you test that?
<jodh> slangasek: yes
<slangasek> jodh: ok, could you update the bug report with your test results? ;)
<slangasek> jodh: oh nevermind, it's written there - sorry!
<slangasek> so what's blocking this from being fixed?
<slangasek> apw: ^^ is bug #1429756 still on your radar?
<ubottu> bug 1429756 in linux (Ubuntu Vivid) "FTBFS: upstart test_job_process fails in majority of cases / Kernel returning unexpected EIO at end of file" [High,In progress] https://launchpad.net/bugs/1429756
<slangasek> jodh: and I guess this has no effect on package builds because those aren't done on a vivid kernel.  ok, merging
<jodh> slangasek: that's right. I believe we're awaiting feedback om apw's patch from upstream atm.
<jodh> slangasek: thanks!
<dobey> who can i bug about issues with lxc-create failing?
<rbasak> dobey: stgraber or hallyn
<rbasak> Though they may bug you back about using lxd instead :)
<dobey> well i'm not trying to do openstack stuff
<dobey> just create a simple lxc of wily to build stuff in
<rbasak> lxd != nova-compute-lxd. lxd gives you an lxc command which is a much more polished interface to the same backend lxc-* speak to
<rbasak> (+ the daemon, so it's not exactly the same I guess though)
<dobey> then someone needs to update http://www.ubuntu.com/cloud/tools/lxd perhaps
<dobey> anyway, i doubt that would solve the issue i'm seeing anyway
<dobey> i am seeing this when trying to create a vivid or wily guest: http://pastebin.ubuntu.com/11134153/
<dobey> an apparently non-existent and uninstallable virtual package
<elopio> I'm guessing the thing corresponding to --global in systemd is --system
<rbasak> dobey: using the "ubuntu" template? Sounds like a bug in the template. Are you aware of the "ubuntu-cloud" template? It uses a cloud image instead of running debootstrap
<elopio> !--global would be --user.
<ubottu> elopio: I am only a bot, please don't think I'm intelligent :)
<rbasak> dobey: so might be a suitable workaround depending on your case.
<dobey> rbasak: i wasn't aware, but i'll try it
<rbasak> dobey: there's also the "download" template for general pre-built stuff though I don't know much about it.
<rbasak> dobey: you probably want "-- -r vivid" or "-- -r wily -s daily -F"
<rbasak> (for the ubuntu-cloud template)
<dobey> ubuntu-cloud doesn't have the -b option to bind a user home dir?
<rbasak> I didn't know about that option. I guess not. You can probably arrange it by hand the same way the ubuntu template does though.
<dobey> There is no download available for release=wily, stream=daily, arch=amd64
<dobey> well, so much for that :)
<dobey> there's nothing for wily under /query even
<dobey> so i guess there are no wily cloud images yet?
<rbasak> utlemming, Odd_Blok1: ^^?
<rbasak> You could always dist-upgrade up from Vivid, though I appreciate that's tedious.
<dobey> i did that from utopic to get a vivid lxc on my laptop
<dobey> but it's still a bit off because rsyslog won't start properly on it
<dobey> hmm, i was able to create a new vivid lxc on my workstation fine just now
<elopio> tedg: should UbuntuAppLaunch work just the same with systemd and upstart?
<elopio> I'm seeing this: http://paste.ubuntu.com/11135179/ with no clue where to look next.
<tedg> elopio, It will, but we haven't ported it over. Waiting on session systemd to do that.
<tedg> elopio, For system systemd you'll need to have cgmanager running.
<tedg> (if you don't already)
<elopio> tedg: it is running.
<tedg> elopio, So then you should be good. You can make sure there's an application-legacy job by doing initctl list
<elopio> tedg: do you mean systemctl status?
<tedg> elopio, Nope, should be talking to the session Upstart
<elopio> tedg: ok, I need veebers here as he'll probably end up doing the work.
<elopio> I'll wait for him to arrive before asking more questions.
 * tedg yells VEEBERS WAKE UP! ;-)
<veebers> elopio: Is the UbuntuAppStart issue easy to reproduce?
<elopio> veebers: doesn't seem to make the autopilot selftests fail, but the tests in the toolkit fail.
<elopio> veebers: so, get a wily. Probably a vm would be smarter than what I did.
<elopio> bzr branch lp:~canonical-platform-qa/ubuntu-ui-toolkit/systemd
<elopio> cd test/autopilot
<elopio> run ubuntuuitoolkit.tests.test_fixture_setup. That will give you one failed test that tries to launch an app.
<veebers> elopio: ack thanks, VM it is :-)
<elopio> tedg: so... do you have an ETA for when the porting to systemd?
<elopio> and can you tell me more about session systemd or help me finding a link? I don't know what you are talking about, and I can see my next week full of test changes to support wily.
<tedg> elopio, No specific ETA, there's a lot of work that needs to happen before that can. Most notably getting the phone onto system systemd.
<tedg> elopio, Then work will start to port the services over, and then we can port UAL at roughly the same time.
<tedg> elopio, So I think we're talking roughly July.
<elopio> tedg: got it. So in the mean time, if we need to use UAL we need to install upstart, right>
<elopio> ?
<tedg> elopio, If you're running Unity (7 or 8) yes.
<tedg> elopio, They all use Upstart for their session process management.
<elopio> ok. That gives us time, we can just tell CI to install upstart in the wily machines.
<veebers> elopio, tedg: so reading what has been said here, there isn't anything we can do except wait for the work to land?
<tedg> I'm confused on your question. If for some reason you want to use a systemd based session, yes UAL needs to support that. Nothing uses a systemd session today.
<tedg> Currently vivd/wily both use a systemd for a system process manager.
<tedg> Except for phone, which still uses Upstart for system process management.
<elopio> so on wily for now we need to use systemd as process manager and upstart as session manager?
<veebers> tedg: hmm perhaps I'm missing some info; to rephrase: Running the UI toolkit autopilot tests fail on Wily with the error elopio pastebin-ed (it used to work i.e. on vivid)
<veebers> wait, that's not really a question :-P
<tedg> They're both process managers. Just system vs. session. On Vivid and Wily Upstart is the session process manager for Unity 7 and Unity 8.
<elopio> tedg: but I had wily installed with unity7 without upstart being installed.
<tedg> I don't think that's possible. None of the indicators would start if that's the case.
<veebers> elopio: I wonder if some of the grief that you're seeing is due to the upgrade process, maybe a fresh install won't see these issues?
<veebers> elopio: I'll be able to test that as soon as this iso is down
<elopio> veebers: that's possible.
<elopio> I upgraded, restarted. Used my machine for an hour with indicators and everything, and then it crashed.
<elopio> I will also try afresh.
<bdmurray> arges: Where is you libmlx4 upload to wily? bug 1409904
<ubottu> bug 1409904 in libibverbs (Ubuntu) "Needed patches for InfiniBand Support: Flow Steering and Offload Support + Fixes" [Undecided,In progress] https://launchpad.net/bugs/1409904
<bdmurray> it looks like libibverbs made it to wily
<veebers> elopio: any idea why trying to install ubuntu-ui-toolkit-autopilot wants to install autopilot-legacy-desktop?
<veebers> elopio: so I installed a fresh wily, installed bzr, py3-ap and ubuntu-ui-toolkit-autopilot (to make sure all deps where there) ran the test you mentioned an have 25 passed tests
<arges> bdmurray: thought I uploaded it
<arges> bdmurray: i'll reupload it
<arges> bdmurray: hmm i did upload it (according to my email)
<bdmurray> arges: was it rejected because the version number already exists?
<arges> bdmurray: last email I got was: [ubuntu/vivid-proposed] libmlx4 1.0.6-1ubuntu1 (Waiting for approval)
<arges> bdmurray: oh
<arges> bdmurray: i'll upload it into wily..
<arges> done
<veebers> elopio: is there a way to replicate the other issue you have (something about complaining about autopilot-finger)?
<rcj> Getting an error branching a pacakge source repo 'bzr branch lp:ubuntu/utopic/open-vm-tools' bzr: ERROR: Revision {package-import@ubuntu.com-20140404165114-xt0s4gbx0dii3fmt} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
<rcj> Full cmd output at http://paste.ubuntu.com/11138204/
#ubuntu-devel 2015-05-15
<rcj> cjwatson ^ Would could I ask about this?
<rcj> I can't branch open-vm-tools from trusty-update through vivid
<elopio> veebers: sorry, I fall asleep while waiting for the isos to download.
<elopio> thanks for trying to replicate. I'll talk to ci tomorrow to see what's different. Maybe only upstart missing.
<elopio> about the other error, don't know. I got it while running autopilot3 run ubuntuuitoolkit
<elopio> and about it installing autopilot legacy, not sure either.
<veebers> elopio: ack, I'm going afk now to get ready for travel. I might be around otherwise see you in a wee bit :-)
<elopio> veebers: safe travel.
<veebers> thanks :-) You too
<rcj> wgrant, having an odd issue with 'bzr branch lp:ubuntu/utopic/open-vm-tools' failing http://paste.ubuntu.com/11138204/ can you point me in the right direction?
<rcj> same problem for lp:ubuntu/trusty/open-vm-tools/trusty-updates and lp:ubuntu/vivid/open-vm-tools/vivid as I have with utopic
<rcj> Issue recreates on clean VM as well
<wgrant> rcj: https://bugs.launchpad.net/bzr/+bug/888615
<ubottu> Launchpad bug 888615 in Bazaar "UDD branch freshness checker breaks on incomplete history" [High,Confirmed]
<wgrant> rcj: Workaround in the comments.
<wgrant> rcj: rcj But open-vm-tools can't be imported into bzr, so you'll want to use the traditional source package until we have git up and running.
<rcj> wgrant, I see that there is now a file in open-vm-tools with a \ in the name so it will fail import.  Is that what you're referring to?
<wgrant> rcj: Yep :/
<wgrant> http://package-import.ubuntu.com/status/open-vm-tools.html#2014-10-16%2016:29:08.138369
<rcj> wgrant, okay, thanks. and if I ask upstream to rename the file will it unblock this as well, or is it doomed since there will be one bit of the history that can't be imported?
<wgrant> rcj: UDD requires the history to be imported.
<rcj> wgrant, thanks.  I'll wait for git then :)  Thanks again.
<wgrant> (but seriously, who has a backslash in a filename)
<rcj> wgrant, I was surprised when I ran into it today.
 * mwhudson reads /usr/share/perl5/Dpkg/Shlibs/Objdump.pm, cries
<mwhudson> 	} elsif ($section eq 'dynreloc') {
<mwhudson> 	    if (/^\S+\s+(\S+)\s+(\S+)\s*$/) {
<mwhudson> 		$self->{dynrelocs}{$2} = $1;
<sarnold> mwhudson: ouch. does that mean you've got to introduce mangling? or patch up dpkg..?
<mwhudson> sarnold: yeah, i guess one of those
<mwhudson> let's file a bug in debian and see how much they laugh
 * sarnold passes mwhudson the asbestos pants
<mwhudson> thanks
<mwhudson> " Is the bug you found listed above"
<mwhudson> i'm really guessing not
<mwhudson>     if ($line =~ /^[0-9a-f]+ (.{7})\s+(\S+)\s+[0-9a-f]+(?:\s+(\S+))?(?:\s+$vis_re)?\s+(\S+)/) {
<mwhudson> maybe i can rewrite dpkg-shlibdeps in go
<mwhudson> (it would actually be fairly easy i think)
<mwhudson> argh, dpkg from git doesn't build on vivid?
<infinity> mwhudson: Please tell me you're joking about dpkg-shlibdeps in Go.
<Unit193> GoGoGoGo!
<dholbach> good morning
<tjaalton> anyone here with gm45 (intel) graphics and on vivid?
<tjaalton> pci-id 2a42
 * mdeslaur hugs cyphermox for network-manager metric fix
<cyphermox> mdeslaur: you're out of date! don't you know the werewolf is out?
<cyphermox> ;)
<mdeslaur> cyphermox: heh, I like it when my laptop still boots so I can work. But thanks :)
<ogra_> it only doesnt boot on full moon
<cyphermox> hehe. my laptop still boots... for now.
<mdeslaur> cyphermox: wait, I have 23 pending merges to do :)
<mdeslaur> sorry, 29
<Unit193> cjwatson: Sorry to bother you again, but any chances of git support in germinate?
<cyphermox> Unit193: you'd like to keep seeds in git?
<Bluefoxicy> plant seeds in the ground
<Unit193> Add water, then wait 3 weeks.
<cyphermox> Unit193: could you file a bug against germinate about this? that way if it's cjwatson who does the work or someone else, we can know when it's done :)
<Unit193> cyphermox: Well, I more wondered if it was planned, and if not then I didn't want to hassle people about it,  But if you really want one, sure I could do that.
<cyphermox> I don't know if it's planned. my gut feeling is that it's not a bad idea, and say maybe I felt bored sometime I could work on implementing it.
<Unit193> I still owe you a plymouth bug too, I believe...
<cyphermox> ah? :)
<Unit193> Yeah, we talked a bit back.  Plymouth has seemingly never been merged, missing a boat load of files (as seen with --list-missing, lack of manpages, and lack of whatever file dracut needs.)
<cyphermox> ah, ok, dracut stuff
<Unit193> And manpages++
<cyphermox> ok
<Unit193> I just never rebuilt the package with --fail-missing to give you the list, it's on my TODO.
<cyphermox> Unit193: that's fine, I can deal with that, if you just open the bug report
<cyphermox> :)
<cyphermox> brb
<Unit193> I tend to be vauge, tell me if 1455688 isn't enough.
<Unit193> Bug #1455689 too
<ubottu> bug 1455689 in germinate (Ubuntu) "Please support git in addition to bzr" [Undecided,New] https://launchpad.net/bugs/1455689
<cyphermox> Unit193: looks just fine :)
<Unit193> Great, thanks!
<cyphermox> Unit193: thank you!
#ubuntu-devel 2015-05-16
<cjwatson> Unit193: Sure, shouldn't be too hard.
<Unit193> \o/
<cjwatson> cyphermox: (I'm happy to do it)
<infinity> cjwatson: Oo.  Very tempted to move all the ubuntu-core-dev seeds to git this cycle if we get germinate-update-metapackage --git
<cjwatson> And why not.
<infinity> Oh, except we kinda need to move everyone at once, unless you combine --bzr and --git to a new --vcs that parses the URI and DTRT.
<infinity> So we can get platform from A and flavour from B.
<cjwatson> infinity: Something like that might be a little saner, yes
<cjwatson> infinity: Although moving everyone at once wouldn't actually be hard, but it's the principle of the thing
<infinity> cjwatson: Moving everyone at once means informing them all and making sure they know how to use git, etc.
<cjwatson> Yeah
<infinity> cjwatson: A third option, instead of magic parsers, though, is just to keep platform mirrored realtime in bzr until everyone's moved.
<Unit193> FWIW, I'm pretty sure Xubuntu would be very, very much OK with this.
<cjwatson> infinity: I can probably figure out how to make it reasonably magic.
<cjwatson> I've spent most of the last three months doing things involving making bzr and git coexist more happily. :-P
<infinity> :)
<cjwatson> infinity: Say, didn't we bring up the fact that gcc no longer speaking -m32 on ppc64el breaks the grub2 build?  Did that get fixed somewhere?
<infinity> cjwatson: I thought we reverted that in gcc.  Or did it get unreverted again?
<infinity> Hrm, sure looks like it.
<cjwatson> Yup, neither gcc-4.9 nor gcc-5 support it in Debian unstable right now.
<infinity> cjwatson: So, we could switch back to using a cross-compiler, but I really think having it speak -m32 is the right answer.  And I kept meaning to have an argument with upstream about the default being wrong, so doko doesn't whine that he's deviating.
<cjwatson> Mind chasing that with doko?
<cjwatson> I would really rather not switch back to cross-compiling.  We put so much effort into demoting that stack.
<infinity> Hrm?  The cross compilers are all in main for other reasons.
<cjwatson> And I don't think it's even possible in Debian.
<infinity> And are landing in Debian any minute now.
<infinity> But I still think -m32 for freestanding binaries makes perfect sense on ppc64el.
<infinity> And it's a design flaw that attempts to disable ppcel entirely disable 32-bit compilation.
<cjwatson> Well, err, OK I guess, but -mbig-endian -m32 is a sane thing, as you say.
<cjwatson> Also it made my packaging a good deal less ugly not to have to use a cross-compiler. :-P
<infinity> cjwatson: I'll see about bringing it up with IBM folks.  I believe the patch that broke it came from Alan.
<cjwatson>   * Configure with --enable-targets=powerpcle-linux on ppc64el for
<cjwatson>     backports to jessie, trusty, utopic and vivid.
<cjwatson> So only reverted for the things I'm not using?
<cjwatson> Or maybe I misunderstand that.
<infinity> cjwatson: No, you read that correctly.  I think doko wanted to stick with upstream defaults for sid/wily, but understood that we relied on that feature for stables and we weren't about to fix the world to accomodate.
<cjwatson> Ah, so that went with the upstream change.
<infinity> cjwatson: So, I get his argument, sort of, but I think upstream is wrong.  I'll chase from both directions when I'm not quite as vacationy.
<infinity> cjwatson: Feel free to argue with doko about the Debian/Ubuntu default before then, though. :P
<cjwatson> Right, thanks.  I guess we can just leave grub2 in a busted state in the meantime.
<cjwatson> (stuck in unstable/-proposed)
<cjwatson> cyphermox: ^-
<infinity> cjwatson: The most annoying bit is that in the thread about the patches that disabled ppcle, someone suggested just tearing out the backend if it wasn't wanted, and Alan said "oh, but I use it for testing, so I'm keeping it".
<infinity> cjwatson: So, the same person who disabled it also doesn't disable it locally. :P
<infinity> cjwatson: FWIW, is this method of building GRUB a Debian oddity, or is it enshrined in upstream makefiles too that powerpc64le == -mbig/-m32 for the bootloader bits?
<infinity> cjwatson: If it was upstream, that would be a much stronger argument for the GCC default being just plain wrong.
<infinity> (Given that some overzealous keener porter GRUB to ppc64le, which is effectively useless, it's possible the upstream makefiles do entirely the wrong thing...)
<infinity> s/porter/ported/
<cjwatson> infinity: Paulo sent it upstream, although I don't think it was actually applied.
<cjwatson> Though it got a sort of ambiguous semi-ack.  It was during my mostly-burnt-out period.
<infinity> cjwatson: "it" being big/32, or the misguided ppc64le port?
<cjwatson> The former.
<infinity> cjwatson: Mmkay.  Well, I'm going to buy some ice cream and continue on my quest to see how fat I can get on my vacation, but I'll put this on my "whine to IBM" list and, if I get no traction with them, me "whine to doko" list.
<sarnold> hehe
<infinity> s/, me/, my/
<infinity> sarnold: Speaking of whining and IBM, they continue to ask every few weeks about the state of the messy ppc64-diag MIR.
<sarnold> infinity: oof. tyler and jamie are going over the backlog of security team issues and they do know the ppc64-diag's dependent packages are still outstanding
<sarnold> infinity: I havent looked over the changes in the new tarball, either; I sked for so much I'm almost scared to find out how much they changed..
<cjwatson> infinity: Enjoy :-)
<cjwatson> I enjoyed writing https://git.launchpad.net/germinate/commit/?id=54c933eecf57cfa10526432740cc27f7b7671446
<infinity> sarnold: Well, I'm less concerned about them making all the changes you asked for, I know they're good for it, and more about just getting all the deps reviewed with the same level of scrutiny, so we can go with a promote-and-fix-later approach.
<infinity> sarnold: I think you opened a lot of eyes with your first review, and shook up some of their teams. :P
<infinity> -build
<infinity> +/build
<sarnold> infinity: makes sense; I'm glad they followed through on the "fix later" bit, at least in intention :)
<infinity> cjwatson: ^-- Does gitignore anchor differently or something?
<Unit193> cjwatson: What'd you use for the conversion?
<cjwatson> infinity: I didn't have to add that, but it forces it to anchor at the start, yeah.  './build' would've been the equivalent in .bzrignore.
<cjwatson> Unit193: I actually forget, I did it a little while back as a test case for LP git.  I'd either have used git-bzr or (more likely) bzr fast-export | git fast-import.
<cjwatson> Unit193: For more complicated cases involving non-trivial surgery on merges and the like, I usually use reposurgeon.
<Unit193> cjwatson: I've used bzr fast-export the most for this, but had to patch it for it to work correctly.  Not heard of reposurgeon, thanks.
<wgrant> bzr fast-export has some correctness bugs that need a fair bit of work to fix.
<cjwatson> Unit193: Yeah, likewise.
<wgrant> We should really fix them, but I have a working version of bzr-git in the interim.
<cjwatson> Either way, you have to put a lot of effort into getting upstream->packaging merges right, IME.
<Unit193> wgrant: This got the basics, at least http://paste.openstack.org/show/eaeoGONThMUuJiyqtm0e
<cjwatson> But for a native package it's not too much trouble.
<cjwatson> For a non-native package, these days upstream is usually in git and you want to stitch your packaging history into upstream's (at least if you do full-tree VCS).
<oliver_> if here no one think to include maintained packages in LTS distros. than we need no long term support. example gcc 4.8 old stuff, llvm with a libc++ v1 and so on. thats crazy! what meens long term??? to wait if everyone is frustated? C++11 and C++14 the new standards and must work in LTS OSes. Or not?
<oliver_> you going in the direction from mickysoft. you start to ignore the importants of saying long term. working on newer versions of ubuntu like 14.10, 15.04 and the next longterm 16.04 LTS. what is to get a working solution in one version and not to develop on more then one version of ubuntu.
<oliver_> people need stuff to work with. have a nice day.
<oliver_> no one gives a answer. thats what i meen with ignoring everything whats happen around. you can't make somthing popular with this attitude !!!!!!!!!!!!!!
<s1aden> hello oliver_, sorry nobody was quick enough.  Alot of people focused on Ubuntu now work "9-5" on weekdays, it's a Saturday, and I believe in Germany Thursday was a bank holiday too... so very likely that people are away on holiday
<s1aden> oliver_ if you hang around a little longer, or can point to a bug report for context it may be possible to get you a better answer
<sladen> oliver_: and without a full name it's going to be hard to find you on Launchpad to follow-up
<teward> need some guidance before I go insane.  I'm trying to write an apport hook for the nginx package so when installing/upgrading fails it also automatically pulls in information from `systemctl status nginx.service` and `journalctl -u nginx.service` to supplement the bug information.  This is due to there being three or four bugs of "Failed to install/upgrade" but no usable information on it because there's no information about *why* it failed to
<teward> install/upgrade, just that it did, and that it needs data from systemd to try and diagnose
<teward> anyone want to give me guidance on how to write an apport hook to achieve this?
<teward> my next question is how to test if the hook works...
<sladen> teward: if it's failing to upgrade it's more likely a packaging issue; in which case (and I could be wrong here), the failure hook might want to be against the cross-release upgrade script.
<sladen> teward: if you can dump 'systemctl status nginx.service' etc to stderr it should make it as far as the system logs and be uploaded that way
<teward> sladen: lets just say i didn't write the init script and don't have time/luxury to make it log to stderr and i've already made complaints to Debian to fix it too
<teward> since their init/upstart/systemd scripts USED to be nice and verbose
<teward> but they changed it and everyone is losing.
<sladen> teward: less of blaming people, and please be civil here
<sladen> teward: my understanding is that you came here wanting other people's time and help
<teward> ...
<sladen> teward: people are more likely to provide their time and help on a Sunny bank holiday weekend, if you're willing to put in your own time to.  If one "do[es]n't have time" oneself, it might be considered unfair to ask the same of others
<teward> sladen: i fail to see where i wasn't civil.  secondly, i've gone over the init scripts before, and the bugs and attempted replication without success, which requires that these 'package install/upgrade triggered' bugs need additional information included in them.  When attempting to reproduce the installs, it does not fail to install with clean VMs, so i need additional...
<teward> ... info added to the bug, and this has been an issue since the 15.04 release
<teward> sladen: the problem is, that even with changes to the init scripts in the package to be more verbose and log to stderr, that information doesn't show up to the public with systemd, even when I tried such things
<teward> and the bugs don't include that information.
<teward> the problem still exists that the additional information needs to be queried/obtained by apport in order to attach to "Failed in install/upgrade" bugs.  Because the install fails when the service tries to start
<sladen> teward: is there a holding bug for this  "nginx failed to install/upgrade", so that everything can be kept together in one place?
<teward> sladen: i've had direct emails on this problem with three separate causes, but that's on an email chain, NOT any bugs, all the bugs are alarmingly data-less and can't be duped to one another without information from the posters in order to glean the cause
<teward> sladen: these are the current ones: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1449903, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1455766, https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1447294
<ubottu> Launchpad bug 1449903 in nginx (Ubuntu Vivid) "package nginx-core 1.6.2-5ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,Incomplete]
<ubottu> Launchpad bug 1455766 in nginx (Ubuntu) "package nginx-core 1.6.2-5ubuntu3 failed to install/upgrade: subproces post-installation script geÃ¯nstalleerd gaf een foutwaarde 1 terug" [Undecided,New]
<sladen> teward: can we create a holding bug, and get the email contents into it.  There might be subtle information or cominality that has been overlooked
<ubottu> Launchpad bug 1447294 in nginx (Ubuntu Vivid) "package nginx-full 1.6.2-5ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete]
<sladen> excellent
<teward> sladen: i'll have to go digging for the emails...
<teward> sladen: and i know for a fact two of the emails were "Hey, I don't want to make a public bug on this, can you help" types of bugs
<teward> so...
<teward> s/of bugs/of emails/
<teward> sladen: and i know from one person who 'hijacked' 1447294 (it wasn't their bug) that their issue was using named upstream locations without IP addresses, which is a known race condition/problem at boot/service install times where it doesn't always succeed in lookups
<sladen> it gets difficult if people don't report things.  :)
<teward> sladen: it gets more difficult when you email them for information requests and get "apache loads first and binds" problems and "DNS lookup failed, cannot bind" problems which are unrelated to the packaging
<teward> those're the big ones
<teward> the third is PEBKAC and a failure to use configuration files which are actually correct, but that's less a bug and more user problems
<teward> sladen: however, this is the...  what fourth bug on this i've seen in the past two months, and nobody's responding for reqs for info
<teward> sladen: hence the need for me to have apport 'do the work for them'... :/
<sladen> so reading bug #1447294, it's being suggested that it appears to be a DNS resolution issue as result of hard-coded domainname in the config files
<ubottu> bug 1447294 in nginx (Ubuntu Vivid) "package nginx-full 1.6.2-5ubuntu3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [High,Incomplete] https://launchpad.net/bugs/1447294
<teward> sladen: note the discrepancy.  Poster vs. commenter.
<teward> sladen: that wasn't their bug
<teward> sladen: i also commented that their problem isn't fixable, it's a known race condition between nginx vs. system, and i already emailed nginx-devel lists to try and determine if they know how to fix it or not
<teward> sladen: but since the actual original bug has no information, well...
<teward> that's why it's "Incomplete", not "Won't Fix" due to "No sane way to control this"
<sladen> teward: I've marked them as dups for the moment;  all three appear to have some logs from upgrade
<teward> sladen: which if you dig through give you bupkes
<teward> sladen: hence my reqs for the systemd command, and my more recently discovered command of the journalctl to find nginx information
<teward> but with nobody giving information and four bugs on this, i'd LOVE to force apport to include that information going forward
<teward> at least in wily, perhaps Vivid if the SRU team allows the change
<sladen> teward: would you be able to dup the the fourth one aswell.  This helps to give a better indiciation of the scale of the problem
<teward> god i'm tired... i need coffee.
<teward> sladen: s/four/three/, s/fourth/third/
<teward> the bug that i keep thinking is the 4th is an ancient bug from 13.10 and needs confirmed if it still exists xD
<sladen> teward: I think pitti might be the best placed to help; but likely won't be around until Monday
<teward> blargh.
<teward> no problem.
<sladen> teward: which is why what we can do in the mean-time is consolidate everything possible into the bug report
<teward> sladen: ack.
<teward> sladen: and of course, tell people to actually attach information...
<teward> triager/developer's worst problem: people don't actually attach followup information
<teward> even when requested
 * teward yawns.
<sladen> teward: indeed.  And the other thing you can do from your emails is subscribe the people who have reported it privately to that bug report
<sladen> teward: so that they can follow the discussion too, without having to file a bug report themselves
<teward> sladen: force-of-habit from work: don't subscribe people unnecessarily.  I gave them links to it all thoug
<teward> sladen: that way they can subscribe themselves.  That's a habit i've picked up, not necessarily a good one, but meh
<sladen> by not subscribing them directly, you're making more work for yourself, but having to back-and-forth
 * teward shrugs
<sladen> so while it might seem fairly to them, you should (as you noted above) remember your time too
<teward> mmm
<teward> sladen: my time right now is going to go to coffee... i have been awake and beating at the nginx packaging (for 1.9.x because reasons) for three hours and had no food or coffee today... i'll be back later, probably with more questions
<teward> (it's probably why i came off as less than civil and irritable earlier)
<Unit193> didi<tab><tab><tab><tab> dangit, still hiding.
<strikov> Hi guys. Is it okay that systemd-udevd gets started by upstart?
#ubuntu-devel 2015-05-17
<hallyn_> tedg: lxcguest is a remnant from maverick timeframe.  please open a bug showing how you tried to create that container, the templtae must be completely out of date
<tedg> hallyn_, I don't think you meant me?
<hallyn_> tedg: d'oh, youre right, that was dobey
<hallyn_> dobey: lxcguest is a remnant from maverick timeframe.  please open a bug showing how you tried to create that container, the templtae must be completely out of date
<hallyn_> tedg: sorry :)
<Bert_2> Not 100% sure whether this is meant for the channel, but I noticed trusty's munin smart plugin is on the old 2.1 version, this would normally not be a problemen, except that it is missing the key feature to ignore non-problematic status codes introduced in version 2.2 of the code (which is a very minor patch, not even 20 lines of code), I was wondering whether I could get that into trusty and if so how?
<lifeless> prepare a patch for trusty, put in tthe bugtracker, and follow the stablereleaseupdate process on the wiki
<Bert_2> lifeless: so I just create the patch file and file a bugreport, then follow the wiki procedure?
<teward> Bert_2: the wiki page of StableReleaseUpdate details the procedures for an SRU.  Create a patch file, file a bug, attach the patch to the bug, and wait for the process to work out.
<lifeless> Bert_2: in short, yes.
<teward> that's the short summary of the process anyways
<Bert_2> teward lifeless: ok, thx, I'm reading through it as we speak and afterwards I'll file the bug ;)
<teward> Bert_2: my only thought on this is that you introduce a new feature, so you'd have to do really thorough tests and have a thorough test case to test the functionality
<teward> if not multiple test cases
<teward> To quote you: "...it is missing the key feature to ignore non-problematic status codes introduced in version 2.2 of the code (which is a very minor patch, not even 20 lines of code)"
<teward> and SRUs typically don't 'add' features, but that's also not my call, just an observation of the most literal interpretation of SRU stuff :)
<Bert_2> teward: yeah, that's why I came to ask, whether there was any chance I could
<teward> Bert_2: the worst that can happen is they say "no" in which case the SRU goes away
<Bert_2> the thing is, I'm pretty sure I'm not the only sysadmin getting swamped with warning about disks that had an error in the past but are actually fine
<Bert_2> teward: true ;)
<teward> Bert_2: one observation suggestion though:
<teward> check currently existing bugs against hte package in that release
<teward> and make sure a bug for this doesn't already exist
<teward> (dupe bugs are dupes and having five bugs for the same thing is... ehh)
<Bert_2> teward: I already checked, there are no bugs for munin on launchpad that mention SMART
<teward> then you're good, just create the bug :)
<Bert_2> :D
<teward> but again the worst case is that they say "We can't add this functionality" or such
<Bert_2> teward: the hard part seems to be explaining a test case, cause you sorta need the right kind of SMART-erroring drive, which I think you can't emulate easily
 * teward shrugs, and returns to poking the nginx init scripts
<Bert_2> teward: enjoy ;)
<teward> blah
<teward> has anyone ran bug-closing scripts to close Lucid targeted bugs?
<teward> and if not should we
#ubuntu-devel 2016-05-16
<ginggs> morning! would someone please tell me why update_excuses shows freecad is missing a build on armhf, but as far as I can see it has never built there (depwait)
<sladen> me can't!
<cjwatson> looks like a bug related to arch: all handling maybe
<ginggs> cjwatson: thanks, can it be pushed through?
<cjwatson> probably but not by me :)
<Saviq> pitti, the bug you asked me to file: bug #1581628
<ubottu> bug 1581628 in klibc (Ubuntu) "resolvconf not populated after ipconfig" [Undecided,New] https://launchpad.net/bugs/1581628
<rbasak> ScottK: around? I'm looking at bug 1581839, and I'm struggling to find a reason that this doesn't also affect Debian. wheezy->jessie moved the clamdscan manpage from clamav-daemon to clamdscan, so shouldn't there be a Breaks/Replaces for that?
<ubottu> bug 1581839 in clamav (Ubuntu) "package clamdscan 0.98.7+dfsg-0ubuntu4 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/clamdscan.1.gz', which is also in package clamav-daemon 0.98.7+dfsg-0ubuntu0.14.04.1" [High,New] https://launchpad.net/bugs/1581839
<rbasak> ScottK: am I missing something?
<ScottK> There probably should and we missed it.
<rbasak> ScottK: if so I'm happy to file a bug. I'm just struggling to be sure.
<ScottK> At this point I don't think it's needed.
<ScottK> Wheezy has 0.99.
<rbasak> OK, thanks. I'll sort it in Ubuntu.
<ScottK> Debian is different than Ubuntu in that there's no fixed release pocket.  Once there's a point release it's all updated.
<rbasak> Ah, that's useful to know. Thank you.
<barry> Laney: ping
<Laney> hi barry
<barry> Laney: hi.  i'd like to so some moderate resyncing of libpeas with debian based on their changes to the packaging of the py2/py3 loaders: https://launchpad.net/~barry/+archive/ubuntu/libpeasresync/+packages
<barry> Laney: what they adopted is that the py3 loader is part of libpeas by default, but you have to add an explicit depends for the py2 loader
<barry> and they want to encourage folks to port to py2
<Laney> yeah I remember
<barry> Laney: so i'm not merging everything, just a few packages, and then looking at the reverse-deps to figure out which i have to modify in yakkety
<barry> but i don't want to merge the whole stack ;)
<barry> Laney: i can email the mailing list, but just wanted to get a sanity check from you and see if i should continue to move forward with this
<Laney> you have to undo everything you added the py3 dep on, right?
<barry> Laney: yep, basically just rm that dep from control{,.in}
<barry> Laney: the ones in the PPA (along with libpeas itself) are the only ones needing a new upload i believe
<barry> i'm doing local rebuilds of the other rdeps
<barry> against the ppa, just to be sure, but so far so good
<Laney> did you check they picked the same name for the py2 package?
<Laney> I saw someone talking about it changing
<Laney> maybe they changed it to be the same as your one
<barry> Laney: ah, yes good point, no they changed the name, and yes, i have to upload the py2 deps with the name change
<Laney> nod
<Laney> wasn't that many of them IIRC
<barry> liferea and gtranslator were it i think
<barry> Laney: we're already sync'd on gtranslator
<Laney> I'll check tomorrow
<Laney> (check your PPA)
<barry> Laney: cool, thx.  in the meantime, i'll finish up testing here and we can chat tomorrow
<Laney> if you want to give up your merges then probably mark them on MoM
<barry> i mostly have everything ready to go once i get the green light
<Umeaboy> Uuuuuuuuuuuuuhm. I installed regionset and ran it both as user and as sudo and I got no error changing the region to 2, but the disc won't mount after I rebooted and reinserted the disc.
<Umeaboy> What am I doing wrong?
<Umeaboy> I get no error message poping up as well
<Umeaboy> Here's the error in dmesg: http://pastebin.com/w9HGzJL8
#ubuntu-devel 2016-05-17
<pitti> Good morning
<pitti> hallyn: "systemctl status" says "bad", looks like this unit wasn't actually installed, or has some error? Alias= are translated into symlinks at install time
<pitti> stgraber: the libnl3 package caused many network-manager failures, so it got pulled after a quick discussion in #u-r; Adam later replaced trusty-updates with a reversion
<pitti> stgraber: right, that wouldn't have helped users who already upgraded, only those who didn't yet
<infinity> pitti: Should never delete without a revert.  The revert allows those who upgraded but didn't reboot to have a higher chance of being fixed before things go south.
<infinity> pitti: Anyhow, thanks to stgraber's script freaking out, I went on the warpath to fix it all.
<pitti> infinity: thanks! understood for next time (I ran out of time on Fri); i. e. I'll just leave it to some US folks right away next time
<infinity> pitti: Yeah, acting quickly was good, but if you couldn't revert, nick highlighting (or given the severity, phoning) someone who can DTRT would help.
<infinity> pitti: I suspect a whole lot of grandparents with broken networks phoned their grandkids over the weekend.
<infinity> pitti: But hopefully it's mostly settled out by now. :/
<sarnold> pitti: sorry to bother you directly, could you take a loot at my systemd timers for my archive sync? http://paste.ubuntu.com/16471760/
<sarnold> pitti: the goal is to run the rsync, and once that's finished, run the zfs snapshots, then wait four hours before repeating
<infinity> sarnold: Is it coincidence or intentional that 4h is the delay we use to trigger non-Canonical mirrors?
<infinity> sarnold: (The followup question being "why don't you ask IS to trigger you?")
<sarnold> infinity: I had the impression from IS that they only wanted to push-sync Big Mirrors and wanted everyone else to periodically pull
<infinity> Perhaps so, yes.
<sarnold> infinity: the 4hours was slightly informed by the "six times a day" mention I saw somewhere.. mostly I wanted lots of snapshots to work with in a hurry, and considered switching to five or six hours between syncs later on..
<infinity> sarnold: Well, 4h is a good cadence if you're pulling from a tier2 mirror, since that's when we trigger them. :)
<infinity> If you're pulling from archive.ubuntu.com, all bets are off, they update constantly.
<sarnold> pulling from archive.ubuntu.com, it's remarkably speedy over rsync :)
<infinity> Anyhow, I have no opinions on your units.  I still live in a mindset where replacing cron was silly.
<sarnold> I even found the 'fast' IP address and did terrible terrible things with /etc/hosts that I'm not proud of.
<infinity> Why mangle hosts?
<sarnold> because one IP was five to ten times fsater than the others for me
<infinity> rsync rsync://ip.add.re.ss::foo?
<infinity> I mean, why bother pinning down the hostname instead of just using the IP.
<infinity> rsync doesn't vhost.
<sarnold> hmm. good point. :)
<sarnold> thanks
<cpaelzer> good morning
<sarnold> re: replacing cron, believe me, I'm half tempted to return this to cron. but getting the one to run after the other finished, under two different user accounts, seemed like a worthwhile enough feature to try out
<sarnold> morning cpaelzer :)
<infinity> sarnold: Alternately, it might be that what you're looking for is "us.archive.ubuntu.com" :P
<infinity> For reasons I've never fully understood, archive.u.c is a round-robin of gb and us.
<infinity> So its usefulness fluctuates based on time of day and phase of moon.
<sarnold> infinity: even within the us hosts one was way faster than the other
<infinity> sarnold: Curious.
<infinity> sarnold: IS might want to know about that.  Pretty sure they sit on the same VLAN.  Probably the same switch on the same rack even.  If one sucks, that's odd.
<sarnold> especially since I saw roughly no difference between mtr results between the two. the fast one was 85 ms away, the slow one 80 ms away, and stddev was <5 ms on both
<sarnold> infinity: they are actually on different routers and different uplinks
<pitti> sarnold: the main issue is that you don't want to use a .target for those
<pitti> sarnold: as the .target is never stopped (there is no such thing as an "oneshot target", this doesn't make sense)
<pitti> sarnold: so once it's running, the timer won't do anything any more
<sarnold> pitti: ah :)
<infinity> sarnold: Hrm.  Not from me, they aren't.
<sarnold> infinity: hmm.
<pitti> sarnold: so, drop the .target, have the .timer trigger the rsync unit, and have that Requires/Before= the snapshot unit
<pitti> sarnold: and as both are oneshot, they will be restarted on the next timer
<pitti> sarnold: also, you don't need to add Before= to one and After= to the other, once is enough
<sarnold> infinity: 91.189.91.23 was the fastest -- 91.189.91.26 was the slowest.
<sarnold> pitti: excellent, good to know, I thought it seemed inelegant for Before/After to be anything except duals of each other, but that forum post was so sure.. (I should have known. :)
<infinity> sarnold: Very weird indeed.  I have identical routes to both.  Under severe load, economy would probably be faster due to being a slightly larger machine, but I'm not sure they have enough outbound bandwidth to actually cripple them.
 * infinity shrugs.
<sarnold> infinity: .23 would routinely give me 4-8 MBps, .26 would routinely give me 120KBps.
<infinity> sarnold: Ouch.
<infinity> sarnold: If that's reproducible, I suspect IS would definitely like to know.
<sarnold> ..especially since I wanted to see ~50MBps from these things :) heh
 * pitti needs to disappear for a few hours for a long appointment
<sarnold> pitti: thanks for the help
<infinity> pitti: Have fun storming the castle.
<ginggs> morning! freecad doesn't want to migrate because freecad-doc (arch:all) was dropped. would someone decruft please?
<infinity> ginggs: Done.
<ginggs> infinity: thanks!
<sil2100> cjwatson: hey! We had the 503 again during two image builds - is there a way to re-try those builds somehow?
<sil2100> cjwatson: since essentially the livefs builds succeeded, would be a waste of time to rebuild those from scratch
<sil2100> cjwatson: also, it's a bit worrying that it happens so frequently recently, in the past I don't remember it happening even once
<cjwatson> sil2100: as cdimage@nusakan, run the usual build command (you can get it from cdimage/etc/crontab) but without --live
<sil2100> Oh, ok
<sil2100> Good to know, thanks!
<brendand> why would it be the case that lxdbr0 isn't visible in ifconfig, after i've run lxd init?
<brendand> i have of course specified to set up networking
<juliank> infinity: Coverage report for APT https://apt.alioth.debian.org/coverage/index.html :D
<pitti> brendand: what does "systemctl status lxd-bridge.service" say?
<pitti> brendand: note that both lxd.service itself and also the bridge are only started on demand (via socket activation)
<pitti> brendand: i. e. you won't actually see the bridge up until you try to start your first container
<brendand> pitti, hi btw!
<pitti> hey brendand, how are you?
<brendand> pitti, i'm good. you know i'm back on the inside, right?
<pitti> brendand: yeah, I read it on the ML; welcome back!
<brendand> ok, didn't realise it only starts with the containers
<pitti> brendand: you didn't hold up on the outside for very long :)
<brendand> pitti, yep joining the same club as such luminaries as xnox and mvo :)
 * pitti waves to lamont to :)
<brendand> pitti, no, unfortunately it didn't last long at all - or fortunately maybe!
<brendand> pitti, oh lamont too, heh - he's on my team
<Laney> the outside world is that bad eh?
<brendand> Laney, yeah it's a dark and scary place
<brendand> pitti, so it looks like: http://paste.ubuntu.com/16473414/
<brendand> green is good
<brendand> but 'failed to setup lxd-bridge' seems bad
<pitti> right, so lxd-bridge.start should not succeed in this case
<brendand> i feel like i did something very bad to my lxd. even launch doesn't work
<farblue> hi all :) Maybe not the right channel to ask but I'm working with fan networking and wondered if anyone knew why the docs suggest docker should be configured with iptables=false when using fan networking
<xnox> brendand, so you are the new Yo-Yo =) as elmo called me the other day.
<farblue> anyone here know about fan networking?
<sladen> farblue: sorry know.  A possible reason for disabling iptables is that iptables is already being used to perform the static-nat that FAN-network requries
<sladen> farblue: however, I would stress that I don't know, and it's not something I've ever used
<farblue> ok, that makes some sense. Iâm struggling to work out what the problem is but while my containers can talk to each other and the host can talk to them, they donât seem able to talk to the outside world :(
<sladen> farblue: isn't that the point :)
<farblue> well, no, not really. I donât want anything other than the docker hosts to be able to talk to the containers but it is quite useful for containers to be able to talk out to other services
<sladen> kirkland: you are quoted on the PR for the fan-networking/OpenStack stuff.  If you're around, would you be able to follow-up with farblue
 * sladen reads with amusement "There are several class A network addresses reserved for Class E".  No, there are several /8s reserved for Class E.
<farblue> I think half the problem is that docker does all this âmagicâ stuff under the hood and I strongly suspect turning off iptables in the docker config does more than expected
<sladen> farblue: nb. kirkland is normally on US time, so likely to be around later rather than now
<farblue> ok, Iâll keep working on the problem and ask again later :)
<sladen> farblue: yes, but please stay on IRC!
<farblue> sure :)
<farblue> if iptables management is disabled in docker then it doesnât create the iptables FORWARD rules or create the DOCKER chain or the DOCKER-ISOLATION chain and it doesnât add the PREROUTING rules - which I suspect is rather more than I need disabled
<barry> Laney: hi.  have you had a chance to look at the libpeas PPA?
<Laney> hi barry, not yet
<Laney> I'll let you know
<Laney> inside CSS currently
<barry> Laney: cool, no worries
<barry> and thanks!
<rharper> infinity: pitti: so for the nm/libnl cluster;  where did I mess up in the process?  in the libnl bug, once we found out the nm break happened in -proposed, I built an update (attached v3 of the debdiff to the bug) and requested a sponser;  I can't upload myself.
<rbasak> rharper: I think it was adding verification-done. This implies that it's OK to copy the current version in -proposed to -updates.
<rharper> rbasak: hrm, yes;  I was pretty sure that we tested proposed; that we had unbroken proposed
<rharper> which I thought meant that v3 was in proposed already
<rharper> that is, I had to create the v3 with Breaks to *unbreak* anyone testing proposed;
<rharper> and ISTR that someone helped unbreak proposed by uploading the  newer version;  but maybe that didn't happen in which case changing the tag wasn't correct;
<rbasak> I understand how it went wrong - lots of moving pieces, especially when complicated by the extra coordination needed by sponsorship.
<rbasak> I'd say that marking verification-done needs double checking of everything, including what version is where and that everything known is accounted for (in this case the Breaks, together with everything else).
<rbasak> I wonder if it would be better to mark verification-failed and start again in this sort of case, to reduce the chance of error.
<rharper> rbasak: so, where would I check to ensure the right versions are in place?  pulling the Packages version from the the archive ?
<rharper> rbasak: as in start a new bug?  wading back into those it's quite a lot to take in after one has paged it out of memory context
<rbasak> rharper: rmadison, or https://launchpad.net/ubuntu/+source/libnl3 etc. That should tell you what version of what is where, and sometimes Launchpad has useful diffs to show you to save you downloading and checking.
<rharper> rbasak: cool
<rbasak> rharper: not necessarily starting a new bug, but marking verification-failed, having the SRU team delete from -proposed, and re-uploading new fixes or something. That's what I was thinking. I don't know if this is a good idea or not in general, but I feel that it might have reduced the probability of error in this particular case.
<rharper> ah
<pitti> rharper: I think that should have come up during testing, and indeed I considered teh v-done as "good enough" (when mass-processing SRUs I don't/can't check every detail again)
<pitti> rharper: not easy to put a finger on a particular point in the process, it was sort of an emergent corner case between sponsoring, verification, and not prodding about removing a known-bad proposed version
<pitti> rharper: i. e. the half-done version should have been removed from the queue, or marked as v-failed after accepting into -proposed, I think
<rharper> pitti: yeah; I think not being able to make those changes myself makes things harder since a sponsor has to grok all of what happened as well;
<rbasak> rharper: thank you for asking the question BTW. respect++.
<pitti> rharper: everyone can mark as v-failed, and everyone needs to prod the archive admins about dropping an upload from the queue
<pitti> rbasak: indeed, echoing rbasak; thanks for thinking about the post-mortem
<rharper> rbasak: only way to learn =)  also; I felt really bad since it happened while I was out; everyone here was putting out a fire I started.  =(
<hallyn> pitti: could the 'systemctl status' -> 'bad' error be related to 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
<pitti> hallyn: yes, very plausibly
<pitti> hallyn: I did see teh report and your call for feedback; didn't get to that yet, sorry
<hallyn> np.  i assume it has to do with the manual work i do in libvirt-bin.preinst, i suspect i should move another file or something.
<rbasak> pitti: it still feels wrong that there's only one person standing in the way of failure here though. Do we need more staffing on the SRU team so closer reviews are possible before accepting v-done?
<hallyn> i didn't get around to reproducing with a set of empty dummy packages
<pitti> rbasak: not really realistic, I think
<pitti> second-guessing v-done would mean a wholly new second v-really-done, and that's pointless as it doesn't add anything new
<pitti> rbasak: in this case, more testing results from "real users" would have helped
<rbasak> I'm thinking something like "<random> v-done; I checked X and Y"; "<SRU> <reviews what should be checked> what about Z?"
<pitti> rbasak: and we run the SRU process under the assumption that some folks run -proposed and report regressions
<pitti> which apparently didn't happen despite this being in -proposed for like half a year
<rbasak> So trusting results from v-done, but confirming that the right things were checked.
<rbasak> In this case we all knew what was needed, so I don't think additional testing would have helped.
<rbasak> What I think we needed was clarity over what we already knew.
<rbasak> (between us)
<pitti> rbasak: to me as an SRU process guy it wasn't at all obvious from this bug that this broke NM
<pitti> it was supposed to fix NM :)
<rbasak> Well, it fixed libnl3 but exposed a bug in NM.
<rbasak> pitti: how about a tag to say "this is complex, needs two full reviewers please?"
<rbasak> Most SRUs are trivial compared to this one.
<pitti> yeah, SRUs depending on each other are rare
<pitti> which is probably why it's easy to forget to add Depends:/Breaks:
<rbasak> Doesn't even need SRU team. Just another uploader.
<pitti> and given enough luck (installing NM first), even ten testers would have confirmed it works
<pitti> the root cause was to introduce a change that depended on a change in NM without saying so
<rharper> pitti: we didn't know it broke NM until we uploaded to -proposed; mostly because the testing done was on server (with no NM);
<pitti> and that most probably wasn't even known initially
<pitti> exactly
<rbasak> Another issue is that after the initial problem was revealed, we told testers that we knew about the issue.
<pitti> at that point we should have marked this as v-failed
<pitti> or ask an AA to pull the package
<rbasak> After that test results become muddled because we don't know if the tester accounted for the original regression proposed or not. They might fail the new version but not report because they think we already know because of the failure in the initial version.
<rbasak> Yeah. I guess one simple thing to do is to delete from -proposed immediately if we know that it isn't suitable to land in -updates.
<rbasak> And if that isn't immediate (eg. SRU team member online to immediately help with a replacement), then v-failed.
<pitti> that or tagging v-failed, which can be done by everyone
<juliank> infinity: pitti (?): bdmurray (?): Looking for endorsements on https://wiki.ubuntu.com/JulianAndresKlode/DeveloperApplication-PPU (or could I rather apply for core-dev?).
<juliank> mvo is not here, which is somewhat unfortunate
 * juliank contributes in somewhat unusual ways, so there is not that much evidence of what he does (mostly just told mvo to syncpackage something)
<seb128> could somebody from the SRU team look at unity-control-center / unity-settings-daemon in the xenial queue? they are small patches and things the oem team is wanting
<juliank> Anyone thought about AppArmor profiles for APT's http and https methods? I'm currently implementing seccomp for the former, but I thought it might make sense to also get some AppArmor safety (not an expert on that, though)
<juliank> I should probably also chroot() the method into the partial dir
<rbasak> juliank: that sounds like a good idea. AIUI those run in separate processes so should be fairly easy to do?
<juliank> rbasak: I think the problem is that it's not clear where they are fetching to. APT has CWD, /var/lib/apt/lists/partial and /var/cache/apt/archives/partial
<juliank> But some other programs also use them to fetch stuff into other dirs
<rbasak> I see.
<juliank> Also we have proxy scripts we need to run :/
<juliank> But we could at least use AppArmor to protect against writes to /usr and friends
<rbasak> That would certainly be a useful start.
<juliank> Although: They currently cannot do that anyway (under normal circumstances) since they run as a separate user
<nacc> rbasak: still around?
<coreycb> arges, hi, regarding the neutron-* stable release for xenial bug 1580674.
<ubottu> bug 1580674 in neutron-openvswitch (Juju Charms Collection) "[SRU] mitaka point releases" [Undecided,New] https://launchpad.net/bugs/1580674
<coreycb> xenial and yakkety are currently at 8.0.0-0ubuntu1
<coreycb> upstream will release the first beta of 9.0.0 for newton in two weeks which we'll then upload to yakkety
<coreycb> ara, can we get an exception to upload the stable release to xenial before that?
<coreycb> arges, ^  (sorry ara)
<ara> coreycb, no worries :)
<infinity> rharper: Absolutely what went wrong is that it should have been marked v-failed, not v-done.
<infinity> rharper: It would have flipped back to v-needed when the new version was uploaded (which never happened).
<bdmurray> pitti: wrt bug 1446537, would it be possible to tag bugs apport-hook-error that have an attachment named "HookError.*" so it is easier to find issues like this?
<ubottu> bug 1446537 in apport (Ubuntu) "apport hook fails in add_info with TypeError: 'str' does not support the buffer interface" [High,Fix committed] https://launchpad.net/bugs/1446537
<farblue> Iâm still working with the fan networking and it seems to me that a docker container on the fan network doesnât have a route out of the fan unless you enable iptables management in docker
<farblue> could it be because the fan network is overlayâd on top of a physical ethernet interface that doesnât actually have a route out anywhere?
<farblue> anyhow, home time for me now.
<arges> coreycb: i'm not sure what exception you mean. the version in xenial can't be >> than the version in yakkety
<coreycb> arges, ok I wasn't sure if there were any exceptions to that rule.  we can probably upload the xenial version to yakkety for the next 2 weeks.
<kirkland> farblue: hi -- you're interested in fan networking?
<coreycb> arges, can you reject the mitaka neutron* uploads?  there are 4 packages for 8.1.0-0ubuntu1.
<coreycb> arges, these are for xenial
<arges> coreycb: ok
<arges> done
<coreycb> arges, thx
<bdmurray> pitti: I ended up pushing a change to the ubuntu hook to the yakkety branch of apport re apport-hook-error
<sarnold> pitti: thanks for your help yesterday, my timer ran twice without trouble since then :)
<rharper> infinity: ok; thanks
<shadeslayer> chrisccoulson: hi, I was wondering, https://launchpadlibrarian.net/259046127/firefox_46.0.1+build1-0ubuntu0.16.04.1_46.0.1+build1-0ubuntu0.16.04.2.diff.gz seems to have extra things that are not present in https://code.launchpad.net/~mozillateam/firefox/firefox.xenial
<shadeslayer> could you please update the branch? :)
<shadeslayer> chrisccoulson: specifically : https://bazaar.launchpad.net/~mozillateam/firefox/firefox.precise/revision/1070
<karstensrage> are there any backporters that can help with  #1562434 and #1561837
<karstensrage> ive tested them up the wazoo with ppa's and vms
<karstensrage> they are a library and a pam module so im not sure how to propagate that information
<karstensrage> and its already in xenial, tested and working
<karstensrage> i will help anyone with configuring PAM in some way and credentials are required that can be provided as well
<karstensrage> or is there someone that would consider testing so that the backporter doesnt have to just take my word for it?
<karstensrage> debfx, you possibly, youre the newest approved backporter?
<karstensrage> Laney? broder?
<sarnold> bueller?
<karstensrage> it sure feels like that
<Unit193> Tempting to try getting a backport instead of SRU, because the former seems easier and more likely. >_>
<karstensrage> SRU?
<sarnold> stable release update
<Unit193> karstensrage: Different matter at hand, but st..dang.
<sarnold> the process for updating existing packages in published releases
<karstensrage> getting it in xenial proposed was easy
<karstensrage> getting a backport is proving frustratingly impossible
<Unit193> karstensrage: FWIW, part of that is limited number of backporters too, iirc.
<karstensrage> yeah ive heard it all
<Unit193> LP 1582713, LP 1562358.
<ubottu> Launchpad bug 1582713 in python-googleapi (Ubuntu) "1.5.0 xenial update needed due to oauth2client changes" [Undecided,New] https://launchpad.net/bugs/1582713
<ubottu> Launchpad bug 1562358 in python-googleapi (Ubuntu Xenial) "python-googleapi is incompatible with oauth2client >= 2.x" [Undecided,New] https://launchpad.net/bugs/1562358
<mapreri> I wonder, is a SRU acceptable just to fix an appstream issue (including bigger icons)?  my pet package is not showing up in that gnome-software thinghy allegedly for this...
<sarnold> mapreri: it looks sort of like the infrastructure should be there, there's icons-* appstream packages in the -updates, -security, and -proposed pockets
<sarnold> s/packages/blobs/
<mapreri> well, that's what I'd expect from an archive that supports DEP-11, I'd be surprised if those files weren't there.
#ubuntu-devel 2016-05-18
<pitti> bdmurray: we could surely; we can't search for HookError_* attachments?
<pitti> sarnold: great to hear!
<sarnold> good morning pitti :)
<sarnold> pitti: do you mean to find bugs like 1582992 ?
<pitti> yes
<sarnold> does that mean I get to skip reporting them when I find them? :)
<pitti> depends, if we want to track SRUs of broken hooks, or not assume that everyone looks for this tag, we should probably continue to have proper bugs for them
<sarnold> that makes sense
<karstensrage> it takes me about 20 minutes to test out my modules, they kind of go together so you can test them both at the same time
<karstensrage> so round to 1 hour, could i offer 4 hours of my time testing another backport request or w/e in trade for getting my backport requests looked at?
<karstensrage> michagogo if you are micahg would that be something you would consider?
<karstensrage> the four hours is just something to consider, like nothing like tomcat or java but something in the same ballpark as my modules in terms of effort and cognitive load and ill offer to do two or something
<sarnold> karstensrage: btw, what does the backports offer that e.g. a ppa doesn't? either method requires administrator effort to install, right?
<karstensrage> yes
<karstensrage> either method should be done by an administrator
<estan> hi, sorry if this is obvious, but what's the policy of updating packages in 16.04, will only security fixes go in? because 16.04 was released, quite unfortunately, with Octave 4.0.0, which had several bugs. 4.0.2 (which is now in Debian stretch / sid) is much better. any chance of it being updated?
<sarnold> estan: you can SRU updates, it takes some paperwork and testing, but ought to be tolerable: https://wiki.ubuntu.com/StableReleaseUpdates
<estan> sarnold: thanks! we're basing our product on 16.04, and compiling Octave is such a chore.
<cpaelzer> good morning
<michagogo> karstensrage: eh? Don't know who that is
<estan> sarnold: i'm a bit new to this, do you know if the procedure for requesting SRUs is special in any way when the updated package is in stretch?
<estan> sarnold: should i just refer to the debian package and suggest they pull it, with a motivation why the bug is grave? (in this case, it's a regression with the risk of data loss).
<sarnold> estan: a sync from debian may indeed be useful.. the 4.0.1 changelog was -huge-.. I didn't spot a 4.0.2 changelog, is it similar?
<estan> but i realize now that not all changes in octave 4.0.1 and 4.0.2 are okay for SRU, so maybe just that fix should be included?
<estan> hold on, i'll have a look.
<sarnold> back in the day there used to be a "MicroReleaseException" process that packages could apply for...
<sarnold> it's been mostly extended to anything with high-quality release processes... I hope that includes octave, but it may not.
<estan> yea. i'm not sure. i would hope it does :)
<RAOF> High quality release process or significant in-archive testing.
<RAOF> (ie: If you've got an excellent set of DEP-8 tests you may also win)
<estan> hm okay.
<estan> the changelog for 4.0.2 was smaller (had to look in the archive for it: ftp://ftp.gnu.org/gnu/octave/octave-4.0.2.tar.gz).
<estan> but considering the many changes, perhaps it's better to request the 4.0.0 package be patched with the fix i'm thinking of? (it's a bug in the reading of HDF5 format using Octave's open(..): http://savannah.gnu.org/bugs/?45225).
<estan> err, load()/save().
<sarnold> that would probably be easier
<sarnold> but that changelog.. heh
<estan> yea.. i don't feel like doing an SRU for all that now :)
<estan> this is the fix: http://hg.savannah.gnu.org/hgweb/octave/rev/d54aa96abadf , and they added a test case for it.
<estan> i'll try to make a patched package then (never done it before). in the middle of a dist upgrade atm, so it'll have to be a little later.
<sarnold> yeah that patch looks way easier to sru :)
<estan> the existing 4.0.0 package seems to do "make check" as part of the package building, and the tests seems fairly thorough, so that's good.
<farblue> Hi all :) I think I know the reason for the problems Iâm having with my fan network setup and itâs the SNAT rule added to iptables by fanctl. I need the âto:â to be a different IP address. does anyone know a sensible way to configure this?
<TJ-> cyphermox: could you tell me if bug 1582899 (live-installer / expert mode) is one of your areas of interest still?
<ubottu> bug 1582899 in live-installer (Ubuntu) "in-target: mkinitramfs: failed to determine device for /" [Undecided,New] https://launchpad.net/bugs/1582899
<estan> hm, could someone help me with the bzr command to get the xenial-proposed of the octave package? i'm trying to make my first patch.
<caribou_> estan: I don't see any octave in xenial-proposed but there is one in yakkety-proposed;
<caribou_> estan: you can get it with pull-lp-source octave yakkety (from the ubuntu-dev-tools package)
<pitti> estan: there are no more automatic (UDD) bzr branches for xenial, just use apt-get source or pull-lp-source ^
<estan> caribou_ pitti: alright. my end goal is to create a bug report + SRU for http://savannah.gnu.org/bugs/?45225#attached , it's just that i've never done any Debian packaging, and never used bzr, so i'm a little lost :p
<estan> i started with the Getting Set Up guide to get a launchpad account, GPG key etc, and now working my way through http://packaging.ubuntu.com/html/fixing-a-bug.html
<caribou_> estan: Traditional packaging might be more helpful in your case : http://packaging.ubuntu.com/html/traditional-packaging.html
<FourDollars> happyaron: Could you help to sponsor my patch for https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1582301?
<ubottu> Launchpad bug 1582301 in network-manager (Ubuntu) "/usr/bin/nm-connection-editor:11:recheck_pending_activations:g_closure_invoke:signal_emit_unlocked_R:g_signal_emit_valist:g_signal_emit" [High,In progress]
<cking> is there any reason why libjson0-dev is not in yakkety?
<cjwatson> cking: replaced by libjson-c-dev
<cking> cjwatson, ok, thanks
<cjwatson> cking: (it was a transitional package in xenial)
<cking> cjwatson, ah, I should have spotted that
<TJ-> cjwatson: do you have anything to do with live-installer package any more?
<cjwatson> TJ-: no
<TJ-> cjwatson: thought so but worth the ask :)
<TJ-> cjwatson: 2nd (and last!) Q: Do you know if with the ubuntu-server ISO installer, it selects between base-installer and live-installer depending on whether boot-time 'expert mode' is selected?
<cjwatson> TJ-: err I don't think so, IIRC that's purely about how the image was built (i.e. it uses live-installer if it's present); if you need to disable live-installer then you can preseed live-installer/enable=false
<cjwatson> TJ-: but the ISO image won't have the debs required for base-installer to work so that probably isn't very useful :)
<TJ-> cjwatson: OK, the reason for asking is a user reported a weird bug in expert mode that boils down to live-installer not mounting devtmpfs in the /target/ before doing update-initramfs, resulting in failing to locate the device for /
<TJ-> cjwatson: I noticed the ISO's pool/ does have base-installer but I failed to understand if it was used in any circumstance.
<cjwatson> TJ-: base-installer has common code used by both the bootstrap-base and live-installer frontends
<TJ-> cjwatson: the bug seems to be that the live-installer postinst script has the crucial "waypoint 1 setup_dev" commented out
<cjwatson> TJ-: so it's actually about switching between bootstrap-base and live-installer, not switching between base-installer and live-installer
<TJ-> cjwatson: I'm failing to understand why it only fails in expert mode
<cjwatson> pass
<TJ-> cjwatson: ahhh, bootstrap-base, yes, that was the code I was reading originally before I spotted live-installer running
<TJ-> I'll bug cyphermox about it when he's around :)
<happyaron> FourDollars: is it accepted by upstream? if so no problem
<FourDollars> happyaron: It is not accepted by the upstream yet, but seb128 asks me to work with you.
<seb128> FourDollars, happyaron, it was discussed on the upstream list, but yeah we should maybe wait for them to review/ack to backport/upload
<rharper> Hi, I've a debdiff that fixes 3 bugs I've filed against bridge-utils package;  should I attach the same debdiff against each bug? Or create separate patches/debdiffs for each one individually?
<cyphermox> rharper: you can attach it to just one, I'll review it now?
<rharper> cyphermox: sure
<rharper> cyphermox: https://bugs.launchpad.net/ubuntu/+source/bridge-utils/+bug/1576858
<ubottu> Launchpad bug 1576858 in bridge-utils (Ubuntu) "brctl provides no way to set gc_timer value of a bridge" [Undecided,New]
<rharper> the other two are: https://bugs.launchpad.net/ubuntu/+source/bridge-utils/+bug/1576876 and https://bugs.launchpad.net/ubuntu/+source/bridge-utils/+bug/1576870
<ubottu> Launchpad bug 1576876 in bridge-utils (Ubuntu) "bridge-utils: /etc/network/if-pre-up.d/bridge doesn't handle multiple stanzas of bridge_portprio" [Undecided,New]
<ubottu> Launchpad bug 1576870 in bridge-utils (Ubuntu) "bridge-utils manpage contains incorrect max for portprio" [Undecided,New]
<TJ-> cyphermox: could you at some point look at bug 1582899  - not sure if you're still covering the package
<ubottu> bug 1582899 in live-installer (Ubuntu) "in-target: mkinitramfs: failed to determine device for /" [Undecided,New] https://launchpad.net/bugs/1582899
<pitti> cjwatson: hey Colin, how are you?
<bdmurray> pitti: Easily search LP for bugs with an attachment name? Not as far as I know.
<pitti> cjwatson: do you still remember how http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt is produced?
<pitti> cjwatson: I find a reference in britney1-ubuntu run_b1(), which calls ./update_out.py; but neither run-proposed-migration nor britney1-ubuntu actually seem to call that
<sinzui>  rbasak: is there anything I need to do regarding the backport of juju 1.25.5 to wily and trusty per bug 1556981 . Do I poke someone on the SRU team?
<ubottu> bug 1556981 in juju-core (Ubuntu Wily) "[needs-packaging] Juju 1.25.5 is not in wily and trusty" [Wishlist,In progress] https://launchpad.net/bugs/1556981
<pitti> cjwatson: and I don't see another invocation of update_out.py (and it looks like update_output.txt is what this script produced)
<cyphermox> rharper: sorry, got distracted by half my coffee going in my cup, and the other half oozing from all sides of the machine onto the countertop
<cyphermox> rharper: -can have a fractional part.
<cyphermox> +can have a fractional part.  Available on kernel versions < TBD ?
<rharper> cyphermox: thx;  right;  I'll update with the data;
<cyphermox> other than that it seems alright
<cyphermox> it's for xenial?
<rharper> cyphermox: it's not available on any of the supported kernels we have;  I just need to find which kernel release dropped that
<rharper> cyphermox: yakkety and it ideally should go back to X and T and P IMO;
<rharper> the big issue is the per-port settings
<cyphermox> ok. your changelog reads xenial
<rharper> that's where I tested it
<cyphermox> cool cool
<rharper> since I didn't have a yakkety cloud-image yet
<rharper> also, thoughts on whether the bridge script should be -e ?
<rharper> set -e ;
<cyphermox> I'd be tempted to say no
<rharper> when you apply values to things like port priority and it fails
<cyphermox> would it be better to not have a bridge or to have a partial bridge with maybe missing options?
<rharper> I suppose it depends on the configurer of the bridge
<rharper> if you left stp on for example
<cyphermox> oh, yeah
<rharper> that might cause trouble for networks with loops
<cyphermox> it definitely would break in fun ways in that case
<rharper> I'm not sure about the SRU impact
<rharper> I would expect folks would have already complained
<cyphermox> for SRU it probably should not be changed
<rharper> but it's a pretty clear bug that if someone on trusty did want to apply settings, they can't
<rharper> right, the set -e; agreed;  what about the current patch for per-port settings ?
<cyphermox> it makes sense to me; I see not issue with it
<rharper> ok; let me clean up the manpage sentence on gc_timer/gc_int
<cyphermox> I'm not sure if it's a very common use-case, but this would work
<rharper> it isn't I think
<rharper> but I was extending our bridge config testing in curtin
<rharper> and wrote a testcase for validating bridge settings
<rharper> noticed the b0rkage and thus the bugs
<cjwatson> pitti: in britney1: britney:    cp $DATA_B2/output/$SERIES/output.txt $HTML/$SERIES/update_output.txt
<cjwatson> pitti: so then grep for just output.txt in britney2 and you'll find it
<cjwatson> or indeed case-insensitively for upgrade_output
<pitti> cjwatson: ah, thanks; so we don't use update_out.py at all?
<cjwatson> pitti: not the one in britney1, no.  I just didn't delete it to avoid making merges even harder
<pitti> cjwatson: background is, I'd like to add something like update_output_notest.txt which ignores autopkgtests, so that it's easier to untangle transitions
<pitti> cjwatson: thanks, that clarifies a lot
<cjwatson> pitti: Probably simplest to do a separate britney2 run with different configuration.
<pitti> cjwatson: right, that was the idea (with --dry-run or so, to not spit out the list of packages to migrate)
<pitti> (that was HeidiResult or something similar, no?)
<pitti> with ADT_ENABLE=no
<cjwatson> something like that, yeah
<cjwatson> you mostly just need to take care to avoid overwriting the delta from another run; britney2 doesn't do the actual copies itself
<cjwatson> I'd recommend generating the config dynamically in britney1, in order to avoid future problems with config drift
<cjwatson> i.e. sed over britney.conf
<pitti> cjwatson: *nod*; is HEIDI_OUTPUT that delta? or is it taken from output.txt?
<cjwatson> it's not taken from output.txt.  IIRC HEIDI_OUTPUT or something very similar is the delta
<cjwatson> yeah, HEIDI_OUTPUT sounds right.  (heidi is the old name for dak copy-suite, I think)
<cjwatson> dak control-suite rather
<cyphermox> rharper: done?
<rharper> yeah, lemme update the patch
<cyphermox> ok
<rharper> ok, updated
<rharper> for 2.6.0 or older, you can have gc_int ; and port priority has max 255, default 128;, newer has no gc_int and a port priority of 63, defaults to 32.
 * rharper downloaded 2.6.0-tar.bz2 for the first time in like a decade 
<cyphermox> oh wow, that is kind of old
<rharper> yeah, Linux git didn't have anything older than 2.6.12
<nacc> rharper: i think there is a historical linux tree
<nacc> rharper: but it's accuracy is ... imperfect :)
<nacc> rharper: i think it was a side-import from bk, not endorsed by Linus (I think technically he might not have been allowed to endorse it, random politics)
<rharper> nacc: hehe
<karstensrage> is there a better way to find a backport tester (42 members) than randomly pinging nick in irc?
<nacc> karstensrage: i would think a 'backport tester' is anyone ... a backports team member is distinct?
<nacc> karstensrage: meaning, if you have a backported package in a PPA, anyone could test it
<karstensrage> https://launchpad.net/~ubuntu-backports-testers
<karstensrage> nacc, how would i go about finding this "anyone"
<nacc> karstensrage: well, i mean, if you're backporting something, there must be a use-case or bug or something. So you find people affected by that bug and they test it... ?
<karstensrage> nacc, this is just a new thing
<karstensrage> it made into debian-testing, got pulled from unstable to xenial proposed and is now in xenial
<karstensrage> would also like it in trusty and precise
<infinity> What makes you think you need a third party tester?
<karstensrage> i dont know what i need, i cant get any traction on the backport, seems like the backport list is huge and no one is doing them
<infinity> The backports team might be a bit understaffed right now.
<infinity> But the testing stuff can be done entirely by you.
<karstensrage> ok done and done
<karstensrage> so if thats the case, and since they understaffed, and its tested and working, can someone else just push the button?
<karstensrage> infinity, you might have been the one that pulled it into xenial
<infinity> karstensrage: I was, but I don't do backports stuff.
<karstensrage> i thank you for that, that was unexpectedly seamless
<karstensrage> no freaking way
<karstensrage> Laney, i could hug you
<estan> how long does it usually take between uploading a ppa package before i can see it there?
<karstensrage> estan, usually very fast, or you get an email saying it was rejected
<karstensrage> like 5 minutes?
<estan> karstensrage: hm ok. weird. i uploaded quite a while ago and havent gotten a mail. the upload command was sucessful.
<karstensrage> check spam?
<karstensrage> the upload can be successful but it still be rejected for all kinds of reasons esp if you dont change the version at all
<karstensrage> Laney, if you have any questions please feel free
<karstensrage> if you want my direct number i can provide that
<Laney> karstensrage: questions about what?
<Laney> what's the best way to retire at 35?
<karstensrage> sell meth
<karstensrage> :P
<estan> yea, just thought i would have gotten a rejection by now in case somethibg was wrong. nothing in spam.
<estan> would it come from launchpad.net?
<infinity> estan: You won't get an email if you forgot to sign it.
<karstensrage> Laney, didnt you just handle one of my backports?
<karstensrage> i meant questions about the other one
<Laney> don't know
<estan> infinity: it refused to upload first since i forgot, then i signed and it succeeded.
<Laney> I handled some backports
<Laney> don't know if any of them were yours
<karstensrage> oic
<Laney> but if you're happy, that's nice
<karstensrage> well one was
<Laney> :)
<karstensrage> so thank you
<estan> ill look closer when im home, on the bus now.
<karstensrage> Laney, would you consider doing the other one?
<karstensrage> please?
<Laney> It depends on the first
<Laney> So I can't build it until that one is done
<karstensrage> yes
<karstensrage> it seems done?
<karstensrage> i see it in precise
<Laney> Takes a while to get to the mirrors
<karstensrage> ill check trusty
<karstensrage> ok
<estan> infinity: seems i signed with the wrong key. i thought i'd pick the one i set GPGKEY to in the environment, but i should have set DEBSIGN_KEYID (or passed -k).
<estan> infinity: meh: "Package has already been uploaded to ppa on ppa.launchpad.net". i uploaded with the wrong key. now i get that after trying to upload the debsign --re-sign'ed package. do you happen to know what i can do now?
<estan> infinity: ah, -f.
<estan> working now \o/
<jynik> I see that the releases linked from
<jynik> https://wiki.ubuntu.com/Core all 404. Any chance someone could point me to the associated build scripts?
<rbasak> sinzui: yeah it's waiting on the SRU team. See https://launchpad.net/ubuntu/trusty/+queue?queue_state=1 and equivalent for Wily.
<sinzui> rbasak: oh, "unappoved" thank you. Looked at "new"
<sarnold> jynik: odd, try theseinstad http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/
<jynik> sarnold: Yeah, I did see those. Trying to lend someone a hand who was using the 14.04 LTS and not quite done getting ready to jump to the 16.04 LTS.
<jynik> Was hoping I could at least find whatever build scripts/tools/etc. to rebuild the 14.04.x LTS Core image until they finish transitioning
<nacc> jynik: well, LTS -> LTS upgrades aren't offered ntil july anyways
<jynik> nacc: I see. Even more of a reason for me to track down where the 14.04 Core images my colleague needs went then.
<jynik> I'm hunting around the dev wiki - just having some trouble finding how these core images are built.
<dobey> there were 14.04 core images?
<ogra_> yes
<jynik> https://web.archive.org/web/*/http://cdimage.ubuntu.com/ubuntu-core/releases/14.04/release/
<ogra_> they were renamed tto ubuntu-base
<dobey> oh
<jynik> ogra_: Ah, to avoid confusion with Snappy Core?
<ogra_> look at http://cdimage.ubuntu.com/ubuntu-base/releases/ or some such
<ogra_> yeah
<dobey> they are the pre-snappy minimal ubuntu installs?
<ogra_> yeah
<dobey> ah ok, that makes sense
<ogra_> and they still get built, just under a new name
<jynik> ogra_: Thank you. While I have your attention - any chance you could point me to any docs on how these are being built?
<dobey> i guess someone should update the wiki page, and maybe add a "Base" wiki page and point people to it for old stuff
<ogra_> they are built on a launchpad-buildd using live-build ... the config for it lives in the livecd-rootfs package
<jynik> ogra_: Excellent, many thanks.
<ogra_> dobey, well, perhaps there are reasons that the page was removed completely ... slangasek would know
<dobey> ogra_: ? https://wiki.ubuntu.com/Core is very much still there
<ogra_> oh
<hallyn> pitti: hey - i have a tiny reproducer package-set for bug 1579922 (left the code links in the last comment)
<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> solving that is the key to fixing the libvirt upgrade problem...
<hallyn> arges: bug 1583009 , is the fix you uploaded for libvirt?  (not seeing it in rmadison)
<ubottu> bug 1583009 in libvirt (Ubuntu) "Error starting domain since update" [Medium,In progress] https://launchpad.net/bugs/1583009
<infinity> hallyn: https://launchpad.net/ubuntu/+source/libvirt/1.3.4-1ubuntu2
<infinity> hallyn: You're just impatient. ;)
<hallyn> tis true.  thx
<hallyn> arges: libvirt in sid doesn't have that, i wonder if they have a reason.
<pitti> hallyn: cheers, I'll look at that
<patcable> what's the usual length of time it takes from a package to go from being in -proposed to being something people will get when they apt-get upgrade?
<patcable> (provided verification happened)
<infinity> patcable: About a week.
<patcable> exciting, thanks
<Bluefoxicy> for point releases on Xenial, do you add new software packages to universe?
<infinity> Bluefoxicy: We sometimes add new packages, yes.
<Bluefoxicy> infinity:  cool.  What happens if a package is main and installed by default in a newer release, but also gets added to a prior LTS?  Does it go to universe?
<infinity> Bluefoxicy: It wouldn't be added to an older release without reason to do so, we don't just pull packages in willy-nilly.  So, "depends".
<Bluefoxicy> nod
<Bluefoxicy> I'm trying to write a zram manager and just curious what I should target as a long-term roadmap
<infinity> A zram manager?  Does it really need management?
<infinity> Or do you mean "enhancing zram-config to take a conffile"?
<Bluefoxicy> No, I mean an active manager.
<Bluefoxicy> I can pull statistics on how much data is stored in zram and how much RAM it takes up; it's trivial to write a few simple rules to manage it--i.e. to determine if there's less than $Xmin or more than $Xmax available swap, if the amount of RAM consumed by zram swap is below $Y maximum, and so forth
<infinity> Yeah, that doesn't sound like a thing we'd pull back into a stable release.
<Bluefoxicy> so you can say, "Use up to 50% of my RAM as zram", and zram will create swap space as it populates, and remove swap space as it depopulates
<jtaylor> sounds a bit like you want to use zswap instead
<Bluefoxicy> the problem with zram-config is it just says, "Make X amount of swap available"; if you fill it with almost-uncompressible data, it uses nearly so much RAM.  if you fill it with highly-compressible data, it uses almost no RAM.  You're rolling some dice and hoping for the best
<jtaylor> its config is max percent of ram and doesn't reserve any ram
<Bluefoxicy> jtaylor:  I'm not interested in writing back to disk as a cop-out to say "stop eating my RAM with this"; more importantly, I'm not interested in overprovisioning disk-based swap in an estimate of what's likely to achieve goals I can target directly.
<Bluefoxicy> last I checked, zswap cached a disk swap partition into compressed memory
<Bluefoxicy> that's interesting in its own right
<jtaylor> usually your disk is much larger than ram so its not really much overprovisioning
<Bluefoxicy> I've long-abandoned disk-backed swap as any significant portion of swap space, though, because while 8MB of swap space is reasonable in a world where 16MB is a lot of RAM, 12GB of swap space is not usable in a world where you have 24GB of actual RAM
<sarnold> the installer created a 120 gigabyte swap partition for me because I had 128 gigs of ram. this left about 800 megabytes for /.
<jtaylor> hehe
<Bluefoxicy> sarnold: lol what
<jtaylor> and then it still creats a 1gb boot which files up with like 5 kernels ;)
<Bluefoxicy> sarnold: a 5tb disk is like $110 now, goway
<sarnold> jtaylor: bingo :)
<Bluefoxicy> jtaylor: RHEL6 still creates a 99MB /boot and then freaks out every time you try to upgrade if you already have 2 kernels installed
<sarnold> Bluefoxicy: heh, I've got nine 3tb drives in this machine, plan on adding another six soon... the 120 gig SSDs are just for the OS :)
<Bluefoxicy> infinity:  anyway I figured it'd be useful as an available software package, but I'm trying to get away from the installer defaulting to making a swap partition--it would at least close bug #-99999Sarnold
<sarnold> oops. I broke Bluefoxicy :)
<Bluefoxicy> negative overflow :)
<infinity> Some use cases still need real swap, no matter how much we wish they didn't.  The first step to get away from swap partitions (by default) is to acknowledge that we can't create RAM out of thin air, but swap partitions suck, and switch to swap files.
<Bluefoxicy> there's a swapd that creates swap files on-the-fly similar to what I described
<infinity> If you mix zram and swap files together, the fact that swap files are a bit slower and icker is made up for by zram giving you some breathing room, and everyone wins.  Ish.
<Bluefoxicy> why do some things need real swap?  Memory is just too tight?
<infinity> Not everyone has gobs of RAM.
<infinity> Such is life.
<infinity> Not all computers are created equal.
<infinity> And, on the other end of the spectrum, some computers are HUGE, but run even more huge working sets.
<infinity> And extending to disk beats not being able to compute your weird set.
<pitti> xnox: FYI, upstart autopkgtests have been looping/breaking testbeds since yesterday, I'll blacklist them now (i. e. they'll stay in progress, but they stop DoSing the workers)
<Bluefoxicy> generally the ones with minimal RAM are things like phones and tablets
<pitti> xnox: as the test workers are still KDE/Qt-DoSed, need to make some room
<infinity> Bluefoxicy: Or old computers that suck.
<Bluefoxicy> on those architectures, it's traditional to not use swap because of some odd fear of destroying the nand
<infinity> Bluefoxicy: But, as I note, there's also the high end.  Some workloads just really need more RAM than it's feasible to buy, and slow beats not running.
<Bluefoxicy> infinity:  I think high-end HPEC and scientific computing are special cases and we shouldn't just partition out 9000 gigs of swap space because you might be building a nuclear bomb simulator :P
<infinity> To be fair, the installer can't really target those high end users, because we have no idea how much RAM they need.
<Bluefoxicy> right
<infinity> Still, "old computers suck" is a totally valid installation target.
<infinity> Just because my laptop has 20G of RAM doesn't mean they all do.
<Bluefoxicy> it's trivial to add functionality to create/use swap files at any path based on any rules
<sarnold> and it's amazing how quickly "new computer" turns into "sucky old computer".
<Bluefoxicy> also, in terms of old computers sucking, I don't think you can revive them by adding 2G more disk RAM to a 1G system
<Bluefoxicy> I tried that
<Bluefoxicy> what I got was "CHROME found another flash video that locks up my computer and requires me to unplug it"
<Bluefoxicy> that has actually happened to me with 24GB of RAM installed and 4GB of swap, which is why I disabled disk swap entirely
<Bluefoxicy> (it will ALSO happen with large amounts of lz4 zram, or zswap, of course)
<Bluefoxicy> (...less bad, maybe, but it'll still happen)
<infinity> sarnold: Yeah, I have a Nehalem i7 with 6G of RAM that may as well be a 486 for how crap it looks next to my laptop.
<Bluefoxicy> hey man
<Bluefoxicy> the 486 was a solid processor
<Bluefoxicy> Quake 1 had full, real-time, software-rendered 3D, but required a 486SX 33mhz with 8 megabytes of RAM
<Bluefoxicy> not even a math coprocessor
<infinity> If by 486, you mean the AMD 5x86 486 clone, I agree.
<Bluefoxicy> which, mostly, worked because John Carmack is a freaking wizard from another dimension
<infinity> Either way, my "beastly desktop gaming machine" is now "an old crap computer", just proving sarnold's point. :P
<Bluefoxicy> ha
<Bluefoxicy> I dispose of my machines after 10 years
<infinity> The Nehalem is a lot less than 10 years old. :P
<infinity> Hrm.  2008.  Well, not "a lot".
<infinity> That computer is a bit newer than that, though.
<Bluefoxicy> I got rid of my AMD64 X2 1.9GHz Barton core when a fan controller physically burned out from electrical wear due to being older than modern computing.
<Bluefoxicy> I then bought a Core i5 at 3GHz :)
<Bluefoxicy> Exciting times.  The AMD64 would overheat and shut down the system at 1.9GHz, but not at 1.8GHz, so I had a CPU power management daemon throttle it to 1.8GHz if the CPU core temperature reached 78C, and unthrottle it at 75C
 * Bluefoxicy gets back to work
<JanC> swap would be useful for moving leaked (and thus unused) memory out of RAM, except usually the leaked/unused memory is fragmented & mixed with used memory, meaning it get swapped in all the time  :)
<Bluefoxicy> there are ways to fix tht
<Bluefoxicy> that
<JanC> in theory, yes
<JanC> not leaking memory would be a good start, not fragmenting memory would be good too  ;)
<Bluefoxicy> things like Mono use compacting memory managers and physically colocate highly-used memory.  For non-managed memory allocators, it's a notably good strategy to allocate allocations from the same thread close together; allocate similar-sized allocations together; and allocate large allocations as anonymous mappings
<Bluefoxicy> some 10 years ago I tried to write a ptmalloc replacement on Hoary, but I'm not a programmer and got myself in all kinds of trouble I didn't know how to resolve :P
<Bluefoxicy> (I still say brk() is outdated)
<arges> hallyn: it fixes the issue. yea wondering why they don't have it
<dannf> hallyn: do you mind if i upload this to y? https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1566564/comments/4
<ubottu> Launchpad bug 1566564 in qemu (Ubuntu Xenial) "support query-gic-version QMP command" [Undecided,Confirmed]
<cjwatson> s390x builders will be going down in about 25 minutes for maintenance; expected downtime about an hour
#ubuntu-devel 2016-05-19
<hallyn> dannf: there's an extra patch in there, qemu-Add-virQEMUCapsSetGICCapabilities.patch, which is not in series?
<hallyn> dannf: other than that, nope, pls feel free.
<hallyn> pitti: thx - have you figured out my moronic mistake yet? :)
<hallyn> i was wrong before btw - i thought that this succeeded in xenial, and maybe with libvirt it did, but with my test pkgs it just fails differently in xenial.
<cjwatson> s390x builders back up; took a bit longer than expected, but there were no builds to be delayed
<hallyn> pitti: I find that if I manual rm the Alias symlink (/etc/systemd/system/pkg2.service) that seems to fix it
<hallyn> suggesting that i can simply in libvirt-bin.preinst do an rm -f /etc/systemd/system/libvirtd.service (the old alias)
<hallyn> dannf: if you push that new libvirt pkg could you also toss in http://paste.ubuntu.com/16503889/ ?
<cpaelzer> good morning
<pitti> good morning
<pitti> bdmurray: FTR, I reviewed all items in xenial-proposed queue, and they now all have something to complain about; the exception is pollinate which I uploaded myself, would be nice if you could review this?
<jamespage> pitti, apologies for those no-op MIR's - I'll make sure ddellav and coreycb pickup on those before they get to the SRU team in future...
<jamespage> MIR/SRU's
 * jamespage has not had enough coffee yet)
<pitti> jamespage: no worries -- should they be rejected?
<jamespage> pitti, yes please - I've marked the xenial bug tasks as won't fix
<pitti> ack, done
<jamespage> pitti, thanks...
<happyaron> pitti: waiting asac to add me to ~network-manager... so I can change the repo ownership
<pitti> happyaron: ah great, thanks for updating it
<Laney> doko: libpeas question - can you remember why you multiarched manually instead of setting the libdir?
<pitti> apw, sil2100: vivid-proposed has had linux-flo and linux-mako for > 250 days now (see http://people.canonical.com/~ubuntu-archive/pending-sru.html); are these orphaned and shoudl be removed, or released?
<apw> pitti, a good question indeed ... i am guessing they have been copied (if needed) out to the overlay ...
<pitti> apw: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=linux&field.status_filter=published&field.series_filter=vivid
<pitti> no, they haven't
<pitti> apw: however, jibel said that "These kernel have been on flo and mako for a while, marking as verification done."
<pitti> jibel: ^ do the images build with vivid-proposed enabled?
<Laney> barry: ^^^ AFAICT this is going to break since libpease-1.0-0 is M-A: Same
<Laney> libpeas-1.0-0
 * Laney is struggling to think why the loaders can't be multiarched
<sil2100> pitti: hmm, need to take a look
<sil2100> pitti: yes, our images build with -proposed enabled IIRC
<sil2100> pitti: actually these packages are not used during image builds but during the android package build
<sil2100> And since our silos have -proposed enabled, they have been used by our devices since long
<sil2100> pitti: so I would also opt for releasing them
<pitti> ah
<pitti> sil2100: ok, makes sense; I just didn't want to release them blindly and introduce a new kernel on touch all of a sudden
<sil2100> I'm triple confirming in the logs now
<pitti> apw: no objections from your side either?
<mvo> bdmurray: hi, could you please have a look at the snapd sru in the queue and let me know if there is anything missing on our end?
<sil2100> Give me a minute for firefox to un-hang itself ;)
<pitti> mvo: I commented on the bug already
<pitti> bdmurray: ^
<pitti> sil2100: not urgent at all :)
<mvo> pitti: oh, great
<pitti> mvo: also, 2.0.4 regresses tests in yakkety, so it didn't land; this could likely also affect xenial?
<mvo> pitti: on bug #1583085 or a different one?
<pitti> mvo: bug 1576287
<sil2100> Get:1 http://ftpmaster.internal/ubuntu/ vivid-proposed/universe linux-image-3.4.0-7-mako armhf 3.4.0-7.39~15.04.1 [8138 kB] <- yeah, looks like the one from -proposed
<sil2100> pitti: if apw has no objections then 'ship it!'
<sil2100> :)
<pitti> mvo: #1583085 isn't even mentioned in the SRU changelog
<pitti> sil2100: thanks for quadruple-checking :)
<mvo> pitti: thanks, I will do a 2.0.5 that clarifies the point you mention there then
<pitti> mvo: no need for a version bump, but if you upload a 2.0.5 to yakkety anyway, sure
<pitti> mvo: btw, cleaner to have 2.0.5 in devel and 2.0.5~16.04 as backport
<mvo> pitti: yeah, there is a 2.0.5 planned anyway so I will just fold it all in
<mvo> pitti: thanks again
<caribou> Q: when a package makes a modification to the default grub config, should it trigger a grub-update or just warn the user about the need to update grub ?
<pitti> mvo: no worries, *hug*
<apw> caribou, the kernel tells  grub, but it does cheat as in it supplies hooks which grub itself ties into
<caribou> apw: yeah, I do the same for kdump-tools to build the smaller initrd.img
<caribou> apw: but postinst only triggers the build of the small initrd.img; in this case, I'm adding crashkernel= to the boot param
<caribou> apw: what kexec-tools used to do. Hmm, I should check what was done by kexec-tools & do the same
<apw> caribou, yeah, i would expect you to be calling update-grub i suspect
<Odd_Bloke> pitti: smoser: I'm seeing a ~6 minute hang on boot after a "systemd-udevd[459]: seq 1648 '/devices/pci0000:00/0000:00:03.0/virtio0/net/ens3' is taking a long time" message in syslog, with "cloud-init-local.service @1.034s +7min 17.851s" in `systemd-analyze critical-chain`; what can I do to further work out what's going on here?
<Odd_Bloke> pitti: smoser: (I'm assuming this is something to do with the conversations you were having in Austin; I can give you SSH access to a machine exhibiting this problem if you want :)
<pitti> Odd_Bloke: at first sight this sounds like cloud-init blocking uevents
<pitti> Odd_Bloke: in Austin we indeed figured out how to avoid that, but I guess that change isn't in xenial (or even yakkety) yet
<Odd_Bloke> (This is yakkety, I should add)
<pitti> bug 1577844
 * pitti nudges ubottu
<pitti> Odd_Bloke: so, this is almost surely https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1577844
<caribou> apw: indeed that's what kexec-tools.postinst does
<Unit193> bug 1577844 in cloud-init (Ubuntu) "Drop unnecessary blocking of all net udev rules" [Medium,Triaged] https://launchpad.net/bugs/1577844
<Odd_Bloke> pitti: OK, so presumably I would expect to see this on xenial as well?
<pitti> Odd_Bloke: yes
<pitti> Unit193: oh, are you playing ubottu now? :-)
<Unit193> :)
<Odd_Bloke> Or is ubottu playing Unit193? :p
<pitti> let the Turing test begin
<caribou> pitti: is there a 'smart' way to run DEP8 tests on debian (equivalent to adt-buildvm-ubuntu-cloud) using qemu virt ?
<doko> Laney, because then the loaders dir changes as well. I wasn't sure what would need changing too. so best thing would be change it as well, and rebuild all things having loaders
<Laney> doko: you can't have external loaders, so I think it's okay
<rbasak> caribou: there are instructions in the adt-virt-qemu manpage
<caribou> rbasak: thanks; didn't think to look there :)
<Laney> doko: unless you can think of any other reasons, I'll do a full multiarch in Debian & then sync, if that's okay?
<doko> Laney, sure, but there's still #815727
<doko> but I assume that's addressed with your rationle
<doko> rationale even
<Laney> yup
<Laney> I was trying to figure out why you did it that way
<pitti> hallyn: I followed up to bug 1579922, but you pretty much figured it out already (I used d-s-h to also clean up in the Debian specific enablement tracking, although that's not really that important)
<pitti> hallyn: and it's far from moronic, this is way more complicated than it ougth to be..
<crocodilehunter> where the devs at?
<cpaelzer> Hi, I've seen the following in my builds quite often - is there something I e.g. can/should add to build dependencies to avoid that?
<cpaelzer> dpkg-distaddfile: warning: File::FcntlLock not available; using flock which is not NFS-safe
<cpaelzer> googling for it hit so many build logs that the obvious solution (if ther is one) is hidden behind them
<smoser> Odd_Bloke, why would it be 6 minutes ?
<Odd_Bloke> smoser: I have no idea. :)
<asac> happyaron: to lp?
<smoser> Odd_Bloke, where did you see this ?
<Odd_Bloke> smoser: Vexxhost.
<GunnarHj> Hi bdmurray, could you please move the SRU at bug #1575555 to -updates? Affects quite a few users.
<barry> Laney: yeah.  unfortunately i doubt i'll be able to finish that before pycon.  i got pulled into another project that has higher priority. :/
<happyaron> asac: yep, so I can put the git repos under the team, :)
<mvo> pitti: I uploaded a new 2.0.5 version that fixes the issues you mentioned
<pitti> ah, still with +16.10 .. unusal version number for devel
<pitti> mvo: thanks!
<mvo> pitti: our target right now is still xenial, thats where this comes from, but yeah, easy to enough if it really bothers someone :)
<pitti> cjwatson: I tested http://paste.ubuntu.com/16506628/ locally as much as possible (with local britney.py b2 run and running the sed locally), and it works; does that look halfway sensible?
<caribou> pitti: when DEP8 tests run on the builders using qemu virt, are the qemu images rebuilt each time ?
<cjwatson> cpaelzer: no, just ignore it
<cjwatson> pitti: I think so, but you'll also need something elsewhere to save the output somewhere useful
<pitti> cjwatson: isn't the new output_notest.txt rsynced to people.u.c?
<cjwatson> pitti: bit more complicated than that, look at the stats function
<pitti> cjwatson: I actually can't sudo -u ubuntu_archive -i any more on lillypilly, might be that this got moved somewhere?
<cjwatson> pitti: also there's no rsync involved, lillypilly does proxypass to snakefruit
<cjwatson> pitti: ubuntu-archive@lillypilly is gone
<cjwatson> pitti: you just need to put the files somewhere plausible in $HTML in the stats function
<pitti> cjwatson: ah, so snakefruit:~ubuntu-archive/public_html is "the thing"
<cjwatson> yep
<pitti> cjwatson: understood, thanks
<pitti> cjwatson: http://paste.ubuntu.com/16506661/
<pitti> cjwatson: I deliberately didn't archive it yet, I don't think it's very useful (if we want it later, we can still add it)
<pitti> cjwatson: archive> $HTML/update_excuses/$SERIES/$NOW
<pitti> actually, only doing that for the devel series would suffice, and save some time
<pitti> so, adding a [ "$SERIES" = "$DEFAULT_SERIES" ]
<cjwatson> pitti: that seems fine; the archives are very large as it is
<cjwatson> pitti: oh, one other thing
<cjwatson> pitti: the output from this all gets dumped into the raw log, and I think it might be confusing to have the two runs in succession
<pitti> cjwatson: next iteration: http://paste.ubuntu.com/16506698/
<cjwatson> pitti: I think the notest run should be >/dev/null 2>&1
<cjwatson> or at least >/dev/null
<pitti> cjwatson: good point; I'd do one run as-is, check that everything works as intended, and hten commit the >/dev/null ?
<cjwatson> pitti: first if there should have an else block that rms output_notest.txt
<cjwatson> rm -f that is
<cjwatson> otherwise it'll get confusing when a series goes from default to non-default
<pitti> cjwatson: ah, that applies to both if's actually
<asac> happyaron: ok done
<asac> thanks
<cpaelzer> cjwatson: thanks!
<pitti> cjwatson: http://paste.ubuntu.com/16506747/
<pitti> cjwatson: (I can locally drop the >/dev/null for debugging on snakefruit if needed); I also dropped the -v, no point with >/dev/null
<dannf> hallyn: oh, good catch. and yeah - i'll add that patch for ya.
<cjwatson> pitti: LGTM
<pitti> cjwatson: thanks for your review!
<hallyn> pitti: it seems like a sort of 'deb-systemd-helper rename-service pkg1.service pkg2.service new-package' would be helpful
<hallyn> pitti: in libvirt it's a bit simpler bc we restart on upgrade,
<hallyn> but if we didn't want to restart - as in lxcfs - then this would be even more complicated
<pitti> hallyn: yeah, then it gets hairy, as you remove the unit from the disk, so you can never restart it ; i. e. this basically needs a reboot (or a way to restart it after all)
<hallyn> pitti: but so when i have libvirt-bin.service provided by libvirt-bin pkg, and an upgrade doesn't have libvirt-bin.service;  does the upgrade not turn off and disable the libvirt-bin.service?
<pitti> hallyn: no, debhelper can't know that an earlier package version used to ship a unit that doesn't exist any more
<pitti> hallyn: i. e. there could certainly be some debhelper/dpkg-maintscript helper for this, but it needs to be declared explicitly
<hallyn> heh, sure it can, we have the technology :)   I thought prerm and postrm would do it
<hallyn> ok.
<hallyn> clearer then
<hallyn> thanks!
<pitti> well, we could pry it out of the /var/lib/systemd/deb-systemd-helper-enabled/ data
<pitti> but that doesn't have information which package shipped a service, so no
<hallyn> ... dpkg -S knows...
<pitti> at most, preinst could iterate over the previous .deb contents and disable stuff that disappeared, but that's well within "flaky heuristics/overcomplicated" territory I think
<pitti> so I think explicitly declaring this is more practical (also given how rare this is)
<hallyn> ok
<pitti> but that declaration should be much easier than writing the preinst code etc. yourself
<hallyn> actually what i think surprised me most was finding out that aliases are stored... under /etc.
<hallyn> so /etc/systemd is where deb-systemd-helper stores its info?
<pitti> hallyn: well, not speicifcally for d-s-helper
<pitti> that's where systemd itself stores its info
<pitti> /var/lib/systemd/deb-systemd-helper-enabled/ is just a helper to see whether or not to enable newly appearing services during upgrades
<pitti> hallyn: yes, Alias= translates to nothing more than a symlink in /e/s/ for the new name
<pitti> cjwatson: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_output_notest.txt \o/
<pitti> and the world didn't explode, it didn't clobber HeidiResult, and stuff with regressions didn't get promoted
<cjwatson> great
<pitti> cjwatson: thanks for your help!
<cjwatson> np
<pitti> doko: FYI: http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_output_notest.txt
<caribou> pitti: when running DEP8 tests with adt-run, one can provide the --show-boot to the qemu runner, is it possible to have that done systematically by the builders ?
<caribou> pitti: in short, is there a way to stipulate that in the source package ./debian/tests/control file ?
<doko> pitti: nice. some for excuses?
<bdmurray> pitti: was complaining about items in the xenial-proposed queue done in bugs?
<karstensrage> thank you Laney !!
<pitti> caribou: there isn't, as most virt backends don't actually have that option
<pitti> bdmurray: yes, I followed up to the referenced bug reports; a few issues got sorted out in the meantime and rejected
<caribou> pitti: k
<pitti> doko: not right now, what would be the point? it's regular excuses if you ignore the tests
<LocutusOfBorg> what happened to ppc64el builders?
<pitti> bos01 cloud just died
<pitti> autopkgtests on ppc64el are down too
<bdmurray> pitti: Thinking about the process did you subscribe to those bugs? Should we tell people to really ping us after fixing stuff?
<LocutusOfBorg> :(
<pitti> bdmurray: I didn't subscribe, I was just going to look again when I reprocess; but sub'ing sounds better indeed, I'll do that from now on
<cjwatson> impressive, I can't even sync logs from the ppa-manage unit
<pitti> even "nova list" is hanging
<bdmurray> pitti: Maybe we should put that in the SRU process then
<LocutusOfBorg> also almost all the arm64 build started some minutes ago are stuck in the fetch of gcc-4.9
<cjwatson> yes they're in the same cloud.
<LocutusOfBorg> thanks
<seb128> wtf
<seb128> sil2100, seems like you are copying some sort of overlay over to yakkety?
<Laney> barry: I'll upload what is (hopefully) a syncable version to unstable, and you can pick it up when ready
<barry> Laney: +1.  won't be until after pycon for me tho
<Laney> no biggy
<seb128> sil2100, unping
<sil2100> seb128: yeah, a batch copy of binaries, now will proceed with doing source copies for projects that had no-change rebuilds
<seb128> sil2100, I though one was reverting some xenial changes but I got confused by the changelog
<sil2100> (mentioned it on -release just in case there are any objections)
<hallyn> dannf: so, just to be sure, you're going to push that?  Or were you wanting me to?
<showaz> zabbix 3.x (agent) not work 15.04/16.04
<dannf> hallyn: already did :)
<hallyn> dannf: rockin' :)  thanks
<hallyn> then i can move on to qemu merge
<tdaitx> bdmurray: regarding 1566201, I can't reproduce the error locally, I just get a message:
<tdaitx> Unknown channel 'xenial-partner'
<tdaitx> The channel 'xenial-partner' is not known
<tdaitx> bdmurray: if I remove the "?channel=xenial-partner" param then a pop up "Install additional software" comes up and I can install it normally
<bdmurray> tdaitx: cyphermox and I are working on it
<tdaitx> bdmurray: nice, let me know if you need some testing... I'm not running unity though, I wonder if that is why I can't reproduce it...
<bdmurray> tdaitx: what was the command line you are using?
<tdaitx> bdmurray: the one from the bug report (with sudo)
<tdaitx> bdmurray: let me know if I should test without sudo (I have a private ppa entry in sources.list.d that is unreadable for any other use besides sudo and apt tools fail to work because of that)
<tdaitx> * s/besides sudo/besides root/
<mvo> bdmurray: if you could have a look at todays snapd 2.0.5 sru upload, that would be great
<bdmurray> mvo: okay
<GunnarHj> bdmurray: Thanks. :)
<LocutusOfBorg> I hope you will catch the arm64/ppc64el soon :)
 * LocutusOfBorg leaves
<bdmurray> dosaboy: From which archive did you test the fix for bug 1578351? The clould archive or the official ubuntu one?
<ubottu> bug 1578351 in keystone (Juju Charms Collection) "mitaka ksclient fails to connect to v6 keystone" [High,Fix committed] https://launchpad.net/bugs/1578351
<egsome> I'm thinking in creating a simple application which hooks into Apport to track program crashes and retrieve possible solutions from AskUbuntu and other websites. What do You think about that ?
<bdmurray> egsome: When you say solutions do you mean workarounds / hacks or updated packages to install which fix the crash?
<egsome> bdmurray, All of them. Workarounds, Hacks and Packages to install or update.
<dobey> i think that's a bad idea
<dobey> workarounds/hacks are unsupportable, and can possibly cause problems when fixed packages are available
<egsome> dobey, Great, Why then ?
<egsome> dobey, OK, You're right, and that what would be displayed to the user, to be careful while using any of these solutions.
<dobey> and it perpetuates a problem we have with random people on the internet giving bad information to users
<egsome> dobey, But, What actually happens for most of Ubuntu users, is their being looking for answers ( Hacks, Workarounds, .. ) simply in Google once they face a crash or a problem.
<dobey> "be careful" isn't enough
<dobey> if you want to make the situation better, then the better thing to do would be to help fix the crashes and get the fixes landed in ubuntu and then SRUed out to the stable releases
<egsome> dobey, Users would be able to see the possible solutions / workarounds, also the comments written on them, and maybe the rating of the answer ( Stack Overflow ).
<egsome> dobey, Fixing the bugs is something important, which I don't consider as part of the idea I'm talking about. The idea simply make the Ubuntu Community closer to new users and even old Ubuntu users.
<dobey> well, for one, there shouldn't be anything on askubuntu about "solving" crashes, because bug reports are off topic for ask ubuntu, so any question about a crash should be closed as off topic, and tell the person to report a bug
<dobey> sending mroe people to askubuntu to be turned away because they're asking off topic things, is not the right way to do whatever it is you're trying to do :)
<egsome> dobey, I'm not going to send people to AskUbuntu, I'm just developing a tool that queries AskUbuntu and similar resources for possible workarounds and solutions.
<egsome> dobey, OK, Let's talk about an issue like nm-applet being closed or "hidden" as most users express.
<dobey> express?
<egsome> dobey, I remember I saw lot of questions on AskUbuntu about it, and people talking about how to get it back, is that also off-topic ? I'm not sure, just asking.
<egsome> dobey, Sorry, I mean "as most users say or consider it is just getting hidden not crashed"
<dobey> while there may be a serious issue related to network-manager in 14.04 as the result of some other update, trying to generalize the sitaution to all problems isn't helpful.
<egsome> dobey, I'm using 16.04 and nm-applet also crash for specific situations.
<dobey> well yes, any software running on any comptuer can crash for many reasons
<dobey> it doesn't mean that you are prescient of those reasons or can somehow determine what to query askubuntu or other sites for
<nacc> does askubuntu even export an API to search all questions?
<dobey> nacc: yes, SE has an API
<egsome> dobey, I mean that such a tool can be useful in such cases, nm-applet crash, Apport dialog appear with possible solutions or workarounds like how to get it running again.
<nacc> dobey: ah ok, thanks
<nacc> egsome: but i think the underlying question is how do you determine "possible solutions or workarounds"?
<egsome> dobey, While that happen, the bug report already sent, and fixing the bug is the most important mission have to be done.
<nacc> egsome: as in, how do you know what is the root cause of the bug?
<dobey> egsome: askubuntu has no idea what crash reports are. the only way apport could associate a crash with a question would be if the question had a pre-existing crash report, and apport could find and match that data
<dobey> egsome: otherwise, it's just an arbitrary search, and it's only going to add confusion to the problem
<egsome> nacc, Apport collect lot of details about the crash, I'm sure that can be done in accurate way, maybe not the best, but would save lot of time, as I think.
<nacc> dobey: well- (better-than-me)-said
<dobey> egsome: askubuntu, ubuntu forums, google, etcâ¦ have no idea about the contents of crash reports
<dobey> so you can't query them to find "possible solutions"
<egsome> dobey, Sure I'll not search using the whole report ! I'd get use of the keywords to get the closest possible question.
<dobey> egsome: the only 'keywords' you could use are the package name. which as i said, is a general search and not going to be helpful here
<egsome> dobey, Sorry, It is not the only one at all ! Apport reports include lot of details even the error message if available, all of that can be used for the querying !
<dobey> egsome: well then just go do it. why did you ask what others think if you don't wnat to listen to any dissenting opinions? :)
<egsome> dobey, I don't want to listen ?? I wouldn't come here to discuss at all if I don't want to listen ! I'm just discussing the points You mention, which I think the main objective of being in this channel, development-related discussions.
<nacc> egsome: in open source development, code speaks louder than words, fwiw :)
<egsome> dobey, Anyway, I'm sorry if I have been annoying somehow, and I'm open for any discussion related to the idea I told.
<dobey> apport does a retrace on the crash reports server, not on the client. people don't go digging into the .crash files to find the stack trace signature when asking questions on askubuntu
<egsome> nacc, That's a fact nacc, but discussing with others before coding is very important, to be capable of focusing our efforts on the right track.
<dobey> they ask general things like "i have no network, how do i get it back?"
<nacc> egsome: it would be interesting to see, if given your crash in apport, you can extract enough useful information to query askubuntu for relevant articles
<egsome> nacc, That's exactly the core of my idea.
<nacc> egsome: right, so do that for one specific case and see if it can work?
<nacc> egsome: i disagree, in this case, re: discussing before coding
<nacc> egsome: you can always rewrite
<dobey> i'm just saying it's not feasible, because askubuntu doesn't know anything about crash reports. and your idea assumes that it does, and that there is useful information there related to how to "fix" the issues
<nacc> egsome: but you've chosen a relatively difficult problem to get "right"
<nacc> egsome: so it's better to try it first, see if it's tractable at all, then discuss, with that demo in hand
<TJ-> Great project to rope in a DNN though!
<dobey> i'm just pointing out all the difficulties you'll have to overcome to get something remotely close to what you want
<egsome> dobey, Can You have a look here ? http://askubuntu.com/search?q=nm-applet include 539 questions mentioning nm-applet, not just "Network tray icon is not there". So, Crashes related to nm-applet would have 539 results to get the closest one using rest of the keywords provided in Apport crash report.
<nacc> crashes != questions, as mentioned above -- they should be in bugs if they are crashes (and the question would have been closed, iiuc)
<egsome> nacc, I agree with You. I think a working demo is required to have more clear discussions. And sure re-writing is always possible.
<TJ-> egsome: if it helps you decide, I've been working on something similar, albeit with different aims, for 6 months now, and it is a very nuanced challenge to crack - artifical intelligence is the only way to have a chance
<dobey> and if we had that, we wouldn't even need moderators on askubuntu any more, because the AI would be smart enough to close questions as spam, duplicates, off-topic, whatever
<TJ-> you give AI too much credit... this is far harder than winning a game of a Go :)
<nacc> skynet.
<egsome> TJ-, I love AI, and I think Machine Learning can be used a lot to make that solution more smart and can decide more what to suggest to the user. Can I have a look at what You done so far if it is open-source ? I can even continue working on it with You if it is OK.
<TJ-> egsome: it's not open (yet) and it's very different in aim (it processes live streams of data )
<dobey> TJ-: my point exactly. if you had an AI that can understand the nuances of English, and the very bad English which is used on the Internet at that, then it would be good enough to be a moderator
<nacc> i mean in some sense what you are describing is an 'expert system' for ubuntu bugs, which could take as input some 'bug report' and spit out from all data sources 'relevant data'. Sort of like a good google search :)
<TJ-> dobey: as I told egsome in #ubuntu, any solution would need a lot of curating too
<TJ-> to make such a system effective the training needs to be done by expert bug solvers who can recognise solutions from misguided shotgun approaches
<jcastro> egsome: I think a generic AU scope would be useful
<jcastro> we used to have one, and when it worked it was awesome
<dobey> well, the suggested thing would be useless for the discussed situation where egsome is claiming it would be useful. if network-manager is crashing, and thus the applet has gone away, then there is no network, so apport would be unable to query AU anyway
<egsome> TJ-, Exactly, Training is a key to success of such system.
<jcastro> right, I'm just saying, if you ignore the crasher part, it's a good idea
<nacc> dobey: :)
<nacc> jcastro: good point, it's really two tools -- get stuff from crasher (unclear if it's possible) and query AU (useful)
<TJ-> it'd be great for folks using Chrome and wondering why the backspace key no longer goes back through the history, though :)
<egsome> jcastro, How it would be aware of the current issue user is facing without using the crash reports ?
<egsome> jcastro, To be just as a Searching Tool for AU ?
<nacc> egsome: don't try to solve too much :)
<nacc> egsome: in one tool
<dobey> askubuntu-mode.el
<egsome> nacc, Do You mean to ignore the Crash analysis part ? Don't know, feel like it would be just a searching tool.
<nacc> egsome: right
<nacc> do *two* tools
<nacc> egsome: there are two separate problems, as jcastro points out
<nacc> or problem-spaces, i guess
<egsome> nacc, One for analyzing the apport reports, and other for searching Communities of Ubuntu ?
<nacc> right
<egsome> nacc, Isn't Google enough for the second one ? I mean that second one can just be useful if integrated with the first one.
<nacc> then your solution is just tying them together by passing data from one to the other, presumably
<nacc> egsome: if so, then work on the first problem, but i don't think it is
<nacc> given some input, i dont' think google gives you the most relevant results
<nacc> or even knows what relevancy is, beyond its own algorithms
<egsome> nacc, Sure it doesn't, I've to do lot of work to make it capable of searching for the problem included in the Apport report.
<dobey> google is a pretty poor search engine any more
<dobey> but good if you like living in a bubble
<egsome> I think it is a good idea to begin with the part of analyzing Apport reports. I'm thinking in hooking into it using the py hooks available, and get the info of each report, and try to get out the primary keywords that can be useful in searching for the solutions or workarounds.
<TJ-> egsome: maybe see https://launchpad.net/+tour/api
<nacc> dobey: true
<ogra_> sounds more llike another frontend to errors.ubunntu.com
<egsome> TJ-, Thanks, I'm writing now a simple Apport hook in Python, trying to get a deeper idea of the structure of  'report' object passed. I hope it is well structured.
<ogra_> *http://errors.ubuntu.com
<nacc> egsome: --^ may want to look at htat too
<ogra_> which already maps crashes to bugs
<nacc> yep
<egsome> nacc, ogra_, Going to have a look at that.
<nacc> and there's tooling,i think, to add new rules to help it along
<dobey> errors.u.c has restricted permissions because crashes may contain private info
<nacc> which goes back to my previous point of how much information do you legitimately expose of the user's crash data to do these queries...
<dobey> basically, as little as possible, and only over secure transports
<nacc> yep
<dosaboy> bdmurray: i tested both xenial-proposed and trusty-proposed/mitaka (UCA) so should be good to go
<bdmurray> dosaboy: Got it, thanks for clarifying in the bug.
<dosaboy> bdmurray: np
<mwhudson> i have a vaguely general question, this failed build https://launchpad.net/ubuntu/+source/golang-github-hpcloud-tail/1.0.0+git20160415.b294095-3/+build/9686605 is blocking -proposed migration
<mwhudson> i don't really care about this package, i care even less about it on powerpc but i want to get it off the excuses page
<mwhudson> i think the best way to do this would be to remove the binary from yakkety-release and then it can continue to ftbfs on powerpc
<mwhudson> infinity, slangasek: does this ^ sound plausible? needs an AA presumably
<slangasek> mterry: does require an AA, yes; is generally a reasonable solution for per-arch build failures that we don't expect to see fixed, provided there's a specific reason why; in this case golang-github-mitchellh-packer-dev also depends on it so you'd need to go up the chain an remove revdeps too
<slangasek> hum
<slangasek> mwhudson: does require an AA, yes; is generally a reasonable solution for per-arch build failures that we don't expect to see fixed, provided there's a specific reason why; in this case golang-github-mitchellh-packer-dev also depends on it so you'd need to go up the chain an remove revdeps too
<mterry> :)
<mwhudson> :-)
<mwhudson> ok
<mwhudson> surely golang-github-mitchellh-packer-dev is an _all package?
<mwhudson> huh no it isn't
<mwhudson> well that's strange
<mwhudson> oh it's never built on powerpc though
<slangasek> ah
<slangasek> ok then
<slangasek> (and yes, actually the -dev package is arch: all, so that's fine anyway)
<mwhudson> slangasek: file a bug, subscribe ~ubuntu-archive or can you just jfdi?
<mwhudson> btw looking into build failures in odd situations is a good way of finding hilarious bugs
<slangasek> mwhudson: for this particular build failure, why is golang-golang-x-sys-dev apparenly so broken?
<mwhudson> https://github.com/golang/go/issues/15738 <- my favourite bug of recent months
<mwhudson> slangasek: it just doesn't have support for powerpc
<slangasek> ok
<mwhudson> it's an inherently arch/os dependent package
<mwhudson> it could be added
<slangasek> good argument for removing the binary
<slangasek> removed
<mwhudson> thanks
<mwhudson> i chased s390x support in golang-golang-x-sys-dev in via debian yesterday :)
 * mwhudson afk for a while
#ubuntu-devel 2016-05-20
<pitti> Good morning
<ricotz> good morning
<ricotz> this one needs some attention https://launchpad.net/ubuntu/+source/libreoffice/1:5.1.3-0ubuntu1/+build/9771317
<seb128> doko, hey, I noticed your merged packagekit 1.0 again ;-) ... do you plan to port/fix aptdaemon?
<pitti> wasn't the bigger blocker click?
<seb128> doko, also it breaks click still
<seb128> pitti, we sort of agreed that it would be ok to break them for a while because they don't plan to base any product on y
<pitti> ah, ok
<seb128> but we should sync up again with them to make sure it's still ok
<pitti> and moving to snaps at some point, I figure
<seb128> yes
<seb128> wth
<seb128> why is autopkgtest for aptdaemon 1.1.1+bzr982-0ubuntu14: amd64: Ignored failure,
<doko> seb128, hrm, thought it would be safe after the lts ...
<seb128> that failure should absolutly not be ignored
<seb128> it's an abi break that makes it fail to import packagekit
<pitti> aptdaemon's tests have been failing for a long time in xenial already
<seb128> well in that case they rightly fail
<pitti> would be good to fix them indeed, so that they become useful again to detect regressions
<pitti> i. e. to succeed in yakkety-release
<seb128> right
<pitti> (or even xenial)
<seb128> meanwhile can we make sure it's blocked in proposed?
<pitti> seb128: easiest is to have a bug against packagekit and tag it block-proposed
<pitti> I don't want to remove the force-badtest, as this would hold up a lot of unrelated stuff then
<doko> hmm, click has an older version in -proposed than in -release?
<seb128> weird
<seb128> doko, pitti, anyway, https://errors.ubuntu.com/problem/0cbdb94861b90a2bf18c183fb3031ed81f6bb5a7 is one of the issues with aptdaemon/new packagekit
<seb128>   File "/usr/lib/python3/dist-packages/aptdaemon/worker/pkworker.py", line 175, in __init__
<seb128>     pk.RoleEnum.GET_DEPENDS,
<seb128> AttributeError: type object 'PkRoleEnum' has no attribute 'GET_DEPENDS'
<seb128> pitti, ^ I've tagged bug #1496292 as block-proposed
<ubottu> bug 1496292 in aptdaemon (Ubuntu) "/usr/sbin/aptd:AttributeError:/usr/sbin/aptd@39:main:__init__:__init__" [High,New] https://launchpad.net/bugs/1496292
<seb128> is that enough for making sure it sticks there?
<pitti> seb128: it needs a packagekit task
<seb128> pitti, oh right, thanks, done
<seb128> slangasek, infinity, could you maybe have a look to https://launchpadlibrarian.net/259212950/lsb_9.20160110_9.20160110ubuntu1.debdiff from bug #1536353
<ubottu> bug 1536353 in lsb (Ubuntu) "[regression] Printer drivers install is broken as lsb package is not available anymore" [Medium,Fix committed] https://launchpad.net/bugs/1536353
<Saviq> pitti, morning, could you please expedite https://launchpad.net/ubuntu/yakkety/+queue?queue_text=mir into yakkety? thank you
 * seb128 wonders why Saviq wants pitti only to look at that, but ok
<Saviq> seb128, because I missed you on this list https://launchpad.net/~ubuntu-archive/+members ;)
<Saviq> and Mirv told me to choose the friendliest member ;D
<seb128> Saviq, well, usually better to just ask on the channel first
<seb128> you can nag individual when nobody replies
<seb128> lol
<pitti> Saviq: is it really necessary to micro-split the packages that way?
<Saviq> sry, first time /me doing this
<pitti> they seem to have similar dependencies and each new package just ships a single new driver
<Saviq> pitti, I'm afraid I can't answer that, but they've been split up more and more as they went, I'm sure there were some reasons for that
<doko> seb128, mvo attached a patch
<Saviq> RAOF, if still here, can you comment on why mir is split up into so many packages?
<pitti> anyway, debs look okayish, accepted
<Saviq> pitti, thank you
<seb128> doko, nice, I wonder how you manage to bribe him to spend time out of snappy :p
<seb128> doko, can you test/upload the patch?
<mvo> seb128: s/bribe/threatened/
<seb128> I've no yakkety system and no plan to start y work before a while, too much lts/snappy work
 * seb128 hugs mvo
 * mvo hugs seb128
<Saviq> this is a nice channel
<Saviq> snuggly!
 * pitti introduces seb128 to the magic of lxd
<seb128> doko, mvo, that enum issue was the reports we get from the time the new version was in proposed, I'm not sure those are the only uncompatible change in pkgkit1 that might bite aptdaemon
 * seb128 introduces pitti to the limitation of his 80G ssd
<pitti> seb128: "lxc launch images:ubuntu/yakkety/amd64" :)
<seb128> ENOSPACE
<seb128> I'm fighting constently with 1G free space
 * seb128 needs to laptop refresh
<pitti> oh, wow
<seb128> my config is 6 years old
<RAOF> Saviq: So many packages?
<Saviq> RAOF, <pitti> Saviq: is it really necessary to micro-split the packages that way? (that's re: mir)
<pitti> ok, armhf autopkgtests are now limping along on 4 lxd slaves in scalingstack, but they commit suicide every hour or so
<pitti> I might have to disable armhf autopkgtests until the CI lab comes back
<RAOF> pitti: Oh, you were referring to the new graphics-mesa-kms9 vs graphics-mesa-x9?
<pitti> RAOF: and -android9
<RAOF> -android9 pulls in android dependencies?
<RAOF> Merging -kms9 and -x9 would be painless; *technically* they have different dependencies, but in practise libGL pulls in X anyway...
<pitti> RAOF: do -android{5,8,9} have different deps?
<RAOF> pitti: No, but they're all superceded.
<pitti> RAOF: ah, so those will be NBS? good
<RAOF> Or, rather, we've got 2 ABIs in play - client platform ABI and server platform ABI; there'll be exactly one mir-platform-graphics-* for each platform, and exactly one mir-client-platform-* for each platform.
<RAOF> All the old ones will be NBS, and removable.
<mvo> seb128: you could simply change the ssd and keep the laptop ;) ?
<pitti> seb128: purging stuff like ~/.launchpadlib or .local/share/ubuntuimages also works wonders, I freed like 10 G the other day
<Saviq> uh oh
<Saviq> Failed to fetch http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/binary-i386/Packages  503  OUT OF DISK SPACE
<Saviq> that's not a local error is it?
<pitti> where do you see this?
<Saviq> pitti, apt-get update
<Saviq> and unless zfs went awry, I've 80G free locally
<Saviq> hmm wait
<Saviq> this could be apt-cacher-ng
<Saviq> that definitely makes more sense
<Saviq> pitti, my fault
<seb128> mvo, I guess I could, but the laptop is a bit bulky and old and 4G ram, time for a proper refresh ;-)
<seb128> pitti, right, I do a proper round of cruft cleaning every now and then and go back to 10G, then download some isos, do some pbuilding etc and I'm back to needing to watch free space ... just need a bigger disk, it's about time ;-)
<pitti> happy shopping then :)
<mvo> seb128: :) sure, it was only half serious
<seb128> but that was a side discussion anyway, it's just that I don't feel like that I've the bandwith to do xenial+yakkety+snappy+... work, and yakkety is at the bottom of my priority list atm, so please don't count on me for the packagekit/aptdaemon thing
<Laney> we did plan on doing it at some point this cycle
<Laney> but thanks to doko for taking it on :)
<seb128> yeah :-)
<Saviq> pitti, any idea why the mir you accepted isn't available in proposed still?
<seb128> Saviq, you are using an outdated mirror?
<Saviq> archive.ubuntu.com ;?
<Saviq> and so do silos?
<pitti> Saviq: rmadison says it's there
<seb128> maybe the publisher is not done yet?
<Saviq> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-058/+packages
<pitti> mir-platform-graphics-mesa-x9    | 0.22.1+16.04.20160516.2-0ubuntu2 | yakkety-proposed          | amd64, arm64, armhf, i386, powerpc, ppc64el, s390x
<seb128> Saviq, retry your build?
<jtaylor> hmm appstreamcli in xenial blocks apt update and eats 100% cpu for apparently ever since today
<jtaylor> known issue?
<Laney> https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1579712
<ubottu> Launchpad bug 1579712 in appstream (Ubuntu Xenial) "Refresh hangs indefinitely, appstreamcli using 100% CPU" [High,Fix committed]
<jtaylor> ah
<jtaylor> oh its much older, weird I only see it today
<Saviq> seb128, can you retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-058/+build/9776460 please - that one doesn't have a direct dep so not a dep wait, but fails because of a dep chain
<seb128> Saviq, done
<Saviq> seb128, ok seems I complained just when it got published
<seb128> Saviq, rmadison is your friend ;-)
 * mgedmin would appreciate some attention for https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/1548425
<ubottu> Launchpad bug 1548425 in update-manager (Ubuntu) "update-manager crashed with AttributeError in check_hovering(): 'tuple' object has no attribute 'get_tags'" [Medium,Incomplete]
<seb128> mgedmin, it's just a warning right? I can't reproduce here...
<seb128> mgedmin, maybe you can get mvo interested in reviewing the patch though
<seb128> mgedmin, but weird, "python3 -c "from gi.repository import Gtk; text=Gtk.TextView(); print(text.get_iter_at_location(0,0))"" returns
<seb128> <Gtk.TextIter object at 0xb539465c (GtkTextIter at 0x8e836e0)>
<seb128> here
<seb128> not a tuple
<mvo> seb128, mgedmin: looks fine, if it works +1, the GI api changes are a bit annyoing :/
<seb128> mvo, mgedmin, well as said I can't confirm the bug and ^ returns an iter for me
<seb128> mvo, mgedmin, OH
<seb128> libgtk-3-0 3.19.9-0ubuntu1~xenial2 [origin: LP-PPA-gnome3-team-gnome3-staging]
<seb128> so I guess the api changed with gtk 3.19
<seb128> *great*
<seb128> that explains it
<seb128> Laney, ^ more fun when we update gtk
<Unit193> s/when/if/ by the sounds of it.
<doko> sil2100, https://launchpad.net/ubuntu/+source/click looks like you copied old versions
<sil2100> doko: hey, yeah... cjwatson noticed that already, looks like this package somehow went through my checks
<sil2100> Ah, I know why
<sil2100> Since the xenial-overlay actually had a lower version than xenial itself, which is what I didn't expect :|
<sil2100> doko: could you drop it from proposed?
<sil2100> I actually expected it to just get rejected, since it's a lower version
<pitti> xnox: upstart autopkgtest times out after "ok 25 - with single-line script that writes 1 line to stdout" on the infra and also in local qemu; this is new from the y-proposed version
<mgedmin> gah!
<xnox> pitti, what about xenial-proposed -> does that one hang too, or no?
<mgedmin> yeah, I'm on ubuntu-gnome with the staging ppa :/
<pitti> xnox: no, that seems fine; and y-release apparently too
<xnox> pitti, ok.
<pitti> xnox: well, it failed of course, but didn't hang that way
<pitti> cyphermox: ok to steal your sysvinit merge?
<doko> sil2100, done
<pitti> caribou: when sponsoring things like bug 1390061, can you please insist on the reporter forwarding the fix to Debian too? (or do it yourself)
<ubottu> bug 1390061 in bash-completion (Ubuntu Wily) "bash-completion tilde expansion every time" [Medium,In progress] https://launchpad.net/bugs/1390061
<pitti> having to drag these fixes in Ubuntu is annoying, and it's relevant for Debian too
<pitti> caribou: stealing the bash-completion merge FYI, as it's blocking sysvinit and util-linux merges
<sil2100> doko: thank you
<doko> nacc, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg  dh-php wants to pull in xml2. either a MIR is needed or the dependency removed
<doko> seb128, Laney: suitesparse gained a dependency on metis (needs a MIR, or suitesparse needs again building with the internal metis)
<seb128> doko, doesn't seem something that has to do with desktop
<seb128> unsure what suiteparse is
<seb128> never touched it
<doko> seb128, suitesparse is owned by desktop packages
<Laney> used by libreoffice
<seb128> k, well as said earlier I've no slot of y-work at the moment
<seb128> so feel free to find somebody else interested
<caribou> pitti: ok ,will do. sorry for that
<stokachu> @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: stokachu
<caribou> pitti: you didn't forward the bug to debian ? 'cause I'll ask seyeong to do it
<ChrisTownsend> pitti: Hey, I have some britney runs for silo-031 that seem like they are stuck (or missing): https://requests.ci-train.ubuntu.com/#/ticket/1425
<ChrisTownsend> pitti: I was told to ping you for investigation.
<pitti> ChrisTownsend: prodded, running now: http://autopkgtest.ubuntu.com/running.shtml#pkg-content-hub
<ChrisTownsend> pitti: Thanks.  And the yakkety one's are just in the queue waiting, right?
<seb128> xnox, https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu24/+build/9737266 ... build is ongoing since yesterday, is that stucked?
<xnox> seb128, yes. will retry.
<seb128> xnox, I guess it's bug #1576914
<ubottu> bug 1576914 in upstart (Ubuntu) "upstart,libnih ftbfs on s390x with linux 4.4.0-21.37" [Undecided,New] https://launchpad.net/bugs/1576914
<seb128> ?
<xnox> pitti, https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1583563
<ubottu> Launchpad bug 1583563 in multipath-tools (Ubuntu) "System will not start with multipathd enabled" [High,Confirmed]
<xnox> looks very fishy =(
<Saviq> pitti, this seems stuck, doesn't it http://autopkgtest.ubuntu.com/running.shtml#pkg-unity8 ?
<Saviq> "Running for:	3 h 4 min 13 s"
<smoser> pitti, around ?
<cyphermox> pitti: yeah, have fun!
<cyphermox> sorry, I had some internet troubles
<nacc> doko: ack, will investigate, must be a new dep in dh-php in debian
<pitti> smoser: hello
<pitti> Saviq: there was an outage of lcy01, so it had to retry a few times
<pitti> Laney: meh, lcy01 and bos01 now both dieing? what's that, a strike?
<smoser> ah.great.
<smoser> pitti, so i was looking at Odd_Bloke 's cloud-image slow boot from yesterday
<smoser> i modified cloud-init-local.service to have this
<smoser>  http://paste.ubuntu.com/16522550/
<smoser> and then after boot
<smoser> $ grep . /run/cloud-init/pre-local*
<smoser>  /run/cloud-init/pre-local:4.73 1.23
<smoser>  /run/cloud-init/pre-local-python:27.13 22.84
<smoser> so the 'python3 -c' line took 24 seconds to start up, and copy /proc/uptime to /run/cloud-init/
<pitti> smoser: ooh, I know
<pitti> smoser: that's yakkety, right?
<smoser> yes
<pitti> smoser: debian bug 822431
<ubottu> Debian bug 822431 in python3.5 "python3.5: regression in -11: always calls getrandom() at start, causing long hang after boot" [Important,Open] http://bugs.debian.org/822431
<pitti> smoser: this bit me in autopkgtest as well
<pitti> smoser: use this workaround: http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/commit/?id=abfc34e2a0f
<pitti> smoser: i. e. call it with PYTHONHASHSEED=0
<pitti> smoser: and it'll be blazing fast again
<pitti> this issue is an utter nuisance
<pitti> basically every python3 during early boot blocks for ages
<pitti> I don't understand why hashes need to be cryptographically randomized
<pitti> and python would block on that
<pitti> in pretty much every language dictionaries are even predictable (although their "order" might change between compilers and versions of course)
<smoser> pitti, ok. i'm trying that. by changing /usr/bin/cloud-init's #! to be
<smoser>  /usr/bin/env PYTHONHASHSEED=0 python3
<pitti> you can use #!/usr/bin/env .. that
<pitti> at least there's a lot of discussion in the upstream python bug, so hopefully this gets fixed after all and the debian bug "wontfix" will be dropped
<Odd_Bloke> Great bug, 10/10.
<Odd_Bloke> Would encounter again.
<pitti> Odd_Bloke: sorry, can't parse that
<smoser> huh. why doesnt that work above ?
<smoser> cat >my.py<<EOF
<smoser> #!/usr/bin/env PYTHONHASHSEED=0 python3
<smoser> print("hello python 3")
<smoser> EOF
<smoser> chmod 755 ./my.py
<pitti> Odd_Bloke: but yes, I spent an entire afternoon tracking this down; in retrospect it should have been much faster, but after the fact everythign is obvious :)
<Odd_Bloke> pitti: (https://xkcd.com/325/)
<smoser> a++++ would read provided link again
<Odd_Bloke> pitti: Yeah, I probably didn't help by planting the networking seed in your mind. :p
<pitti> smoser: hmm, indeed, hashbangs don't work like that; perhaps just add Environment=PYTHONHASH=0 to the uit?
<pitti> unit too
<smoser> yeah. have to add it to each though
<smoser> what am i missing .. why dont sheang work like that. and what is it trying to do
<JanC> pitti: IIRC that was added after somebody illustrated a DDoS against Python's hashtables?
<smoser> oh. it endlessly loops env
<pitti> smoser: sounds like the rest of the file gets fed to env, not python3 or so
<smoser> yeah. i'll modify the Environment
<smoser> but i didnt' want to have to touch all of them.
<pitti> it's hopefully not a permanent change
<pitti> if upstream adds the NONBLOCK flag back to the getrandom() call, the world should be a brighter place again
<JanC> I suppose it's mostly useful where Python has to handle arbitrary data from untrusted users, e.g. in some internet services/apps
<pitti> JanC: that sounds curious; happen to have a link?
<pitti> I can't imagine how an unreliable hash order would be a security feature
<pitti> "unpredicable"
<Odd_Bloke> pitti: http://bugs.python.org/issue13703
<Odd_Bloke> pitti: Which points to https://mail.python.org/pipermail/python-dev/2011-December/115116.html
<JanC> pitti: if you can predict the hashes, you can submit data that computes to the same hash, I suppose...
 * pitti stashes that for later reading, thanks!
<smoser> pitti, what did i do wrong: http://paste.ubuntu.com/16523164/
<JanC> which of course makes hashtable lookups very slow
<pitti> smoser: PYTHONHASHSEED (sorry, typoed in my last reply)
<herrkin> hello, I have a problem with a modem that wont switch to modem mode
<herrkin> I have several modems to test but there is one that is very stupid, some times it just stays in mass storage mode and wont switch
<Odd_Bloke> herrkin: This channel is for development of Ubuntu itself; you probably want #ubuntu or #ubuntu-server. :)
<herrkin> is this the correct place to discuss abut it?
<herrkin> Odd_Bloke, the problem is with usb_modeswitch I think
<herrkin> its part of ubuntu
<Odd_Bloke> herrkin: Sure, but the venue for questions about _using_ Ubuntu belong in #ubuntu or #ubuntu-server.  There will be more people in those channels who may have run across the issues you are seeing, so you have a better chance of finding help. :)
<herrkin> ok let me see.
<herrkin> thanks
<pitti> xnox: I have a change to procps to make; should I steal your merge while I'm at it, or are you already at it?
<pitti> apw: do you know if /etc/init.d/ondemand is still a thing that we need with current kernels?
<pitti> apw: it's the only thing that's left from initscripts that we actually use; I'm working on dropping deps to initscripts so that we stop installing it by default, and wonder if I should put an equivalent unit into systemd or not
<smoser> pitti, something else is at play here.
<apw> pitti, we use that to boot in performance and drop back to something less batter sucking ... and the kenrel is still in performance by default
<smoser> $ pastebinit /lib/systemd/system/cloud-init-local.service
<smoser> http://paste.ubuntu.com/16523968/
<pitti> apw: I had assumed the kernel would drive the CPU to full steam while it's actualy busy doing something (like on boot)
<smoser> $ tail -n 10 /usr/bin/cloud-init | pastebinit
<smoser> http://paste.ubuntu.com/16523984/
<pitti> apw: i. e. I wonder why we are the only distro doing somethign like that
<apw> pitti, it was something that keybuk drove in, and it has never been revisited since
<pitti> apw: anyway, it's simple to port; I'll probably use a Type=idle so that it goes to ondemand as soon as boot is done, istead of a static "1 minute", I just wondered if the kernel still needs that kind of help
<smoser>  http://paste.ubuntu.com/16524007/
<xnox> pitti, please steal
<smoser> so i suspect that something in the cloud-init's imports is messing up the PYTHONHASH or something so it goes back to slow.
<apw> pitti, yeah it is pretty unclear for sure, would you file a bug on linux to review that and let me know, i will find someone to think about it
<apw> pitti, but in the short term, making it an idle systemd unit sounds much better anyhow
<apw> a i know it makes my lappy hot during boot :/
<pitti> apw: ok, so port to a unit in the short-term, and revisit if defaulting to "ondemand" works better now (after all, some 10 years have passed..)
<pitti> maybe 8
<apw> indeed
<Odd_Bloke> smoser: If you want to test the imports, you could (probably) move them all in to that if statement after the startup time is written out.
<smoser> yeah
<pitti> apw: bug 1584124 -- does that have enough context/
<ubottu> bug 1584124 in systemd (Ubuntu) "revisit /etc/init.d/ondemand" [Wishlist,Triaged] https://launchpad.net/bugs/1584124
<pitti> ?
<pitti> xnox: procps> ugh, a 100 kB Ubuntu diff? fun; well, I asked for it, I got it :)
<Odd_Bloke> pitti: doko: Is there an Ubuntu bug open anywhere for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=822431?  This is really serious for cloud images, because they all use Python 3 near the start of boot (via cloud-init).
<ubottu> Debian bug 822431 in python3.5 "python3.5: regression in -11: always calls getrandom() at start, causing long hang after boot" [Important,Open]
<Odd_Bloke> (I've seen a 7 minute hang as a result of it on an OpenStack cloud)
<cpaelzer> Hi, I know there are always all kind of super-skilled people around - for those of you who love gcc/ld to its darkest depth - you might take a look at http://stackoverflow.com/questions/37351699/how-to-create-both-so-files-for-two-circular-depending-libraries - there seem to be no good answer to that out there yet so I asked it openly
<cpaelzer> I'm giving up on it for now and let the weekend try to distract me from it :-)
<smoser> pitti, just for a summary of above using PYTHONHASH does not seem to affect all things.
<smoser> for example, 'import tempfile' does
<smoser>  from random import Random as _Random
<smoser> and that seems hits the same first boot hang even with PYTHONHASH set.
<Odd_Bloke> smoser: What do you see without that set at all?
<smoser> ?
<Odd_Bloke> smoser: Because I suspect you are working around the Python _startup_ issue, and then hitting a separate (but very much related) random module issue.
<smoser> yeah. i think so too
<smoser> i can take out the Environment and see
<Odd_Bloke> smoser: I've filed https://bugs.launchpad.net/cloud-images/+bug/1584147 (which also affects cloud-init).
<ubottu> Launchpad bug 1584147 in cloud-init (Ubuntu) "cloud-init hangs on boot as Python waits for sufficient randomness to start" [Undecided,New]
<smoser> Odd_Bloke, so setting PYTHONHASH *does* help.
<smoser> at least in a single test here
<smoser> but clearly doesnt make it all magic
<Odd_Bloke> smoser: I've added a comment with a high-level summary of what you've discovered; please feel free to flesh out with details. :)
<TJ-> Why would "Failed to connect to Mir: Failed to connect to server socket: No such file or directory" be reported when executing an X application from the terminal, launched by another (sudo) user, with e.g. "sudo /usr/bin/env DISPLAY=:0 XAUTHORITY=/home/<user>/.Xauthority xclock" - do we need to copy more of the target users' native environment? any in particular? presumably this is some kind of fallback
<TJ-> if the X session isn't found?
<dobey> where are you trying to do that?
<TJ-> from a VT. On my system (Ubuntu+Unity) it works fine. On another system using, I think, Lubuntu, it gets that error. Obviously Mir isn't installed, but it feels like a fallback if the X server/session for the target user cannot be located
<dobey> well i'm pretty sure xclock doesn't link to libmir
<sarnold> TJ-: I got that same error message trying to run evince via ssh -X https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1573300
<ubottu> Launchpad bug 1573300 in evince (Ubuntu) "ssh -X X11 forwarding doesn't work" [High,Incomplete]
<TJ-> no, it's something in the underlying libraries obviously. I've not pulled the sources of the libraries as yet to search for the string
<sarnold> TJ-: I never got around to debugging this thing :/
<dobey> well, xclock is a pure x app
<TJ-> sarnold: right; I've seen some similar reports but no bug reports as yet.
<dobey> it doesn't link to gtk+ or qt, and the X libs don't link to mir
<sarnold> xclock is a genius test case :) pretty simple, no churn
<TJ-> dobey: xclock is just an example
<TJ-> this is about the session-level env I think
<dobey> TJ-: sure, i'm just trying to figure out what could possibly cause something that does link to mir, to be run in that case
<dobey> and i just don't see anything
<TJ-> I suspect its the XDG_* vars
<dobey> eh?
<TJ-> looks like bug 1463263
<ubottu> bug 1463263 in Ubuntu "ssh-based X11 forwarding not working in 15.04 following upgrade from 14.10" [Undecided,Confirmed] https://launchpad.net/bugs/1463263
<dobey> TJ-: why not strace and follow the forks/threads to see what else gets run?
<TJ-> dobey: I suspect the failing Lubuntu system doesn't have those XDG_ vars that this Ubuntu has in each user's session
<TJ-> dobey: I don't have direct access to the failing system right now
<dobey> i don't understand what's failing exactly. you ssh to a remote system and then try to run something on that remote system's own local display?
<TJ-> interesting that bug has the quote "The "gdk_mir_display_open" error is just GDK/GTK trying to use Mir because it found no X11 server ($DISPLAY is blank)."
<TJ-> dobey: No, ssh is sarnold's issue :)
<dobey> *shrug* ssh -X works fine here
<TJ-> dobey: 2 completely unrelated separate systems here, trying to use the same mechanism to cause a (yad) window to be displayed in "user1" X session, triggered by "user2" non-GUI script doing "sudo /usr/bin/env DISPLAY=:0 XAUTHORITY=/home/user2/.Xauthority yad ...args..." ... I use xclock just to test it
<TJ-> user2 has sudoers NOPASSWD rights to /usr/bin/env so no user prompting is required
<sarnold> TJ-: are perms on /home /home/user2/ and /home/user2/.Xauthority all correct?
<TJ-> the background to this is some automated scripts the bring up a public Internet connection (wifi) and then a secure VPN, and inform the user whats' going on and, if the public internet is detected to have a captive portal, uses that mechanism with xdg-open http://some.domain/ to cause "user1" to see the captive portal login page
<TJ-> sarnold: yes, totally separate, and thatts why 'sudo' is being used, to ensure access to the files
<TJ-> I'll be in front of the Lubuntu system on Sunday, but hopefully I can get some background on this before then
<dobey> TJ-: and the user was definitely logged in on the remote machine?
<TJ-> interesting  bug 1433165 suggests it could be triggered by an apparmor profile
<ubottu> bug 1433165 in evince (Ubuntu) "evince fails to run due to a gdk_mir_display_open" [High,Confirmed] https://launchpad.net/bugs/1433165
<TJ-> dobey: yes, it's complicated, but user1 is the UID 1000 default user account ... user2 is a 2nd account used to contain the scripts and execute them such that user1 cannot mess them up. user2 has certain sudoers NOPASSWD permissions to run a few system commands via sudo with no need of user interaction
<TJ-> As I said, this looks to be partially due to the failing system being Lubuntu, so potentially a few things are different in the session env
<dobey> TJ-: as i said, i think you should strace to see where the actual failure happens. xclock and sudo don't link to libmirclient, so they can't possibly be trying to open a mir socket (unless of course the xclock is actually a link to some other app, which does link to libmirclient).
<TJ-> it'll be the gtk/gdk libraries I presume
<stokachu> @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:
<TJ-> aahhhh gdk/mir/gdkmirdisplay.c
<dobey> well yes, obviously gtk+ has support for mir
<dobey> but that doesn't explain your issue with xclock
<dobey> xclock does not use gtk+
<dobey> or gdk
<sarnold> there is a surprising number of libraries there though http://paste.ubuntu.com/16534039/
<sarnold> my guesses, libfreetype, libfontconfig
<sarnold> also why xclock needs a bloody xml parser .. *sigh*
<TJ-> ignore xclock, that is misleading. The first of several real commands that fails is xdg-open (synaptic is another one) ... xdg-open is a shell script that runs different programs based on the DE. for LXDE it used pcmanfm which is linked to gtk
<dobey> sarnold: apt-cache rdepends libmirclient9 doesn't show fontconfig or freetype as needing it
<sarnold> dobey: ldd
<sarnold> oh I see, read too fast
<sarnold> or rather, read too poorly :)
<dobey> TJ-: well if it's misleading, that's your fault. you said it didn't work and gave you that mir error. if that's not true, why did you say it? :)
<TJ-> that explains the error message, but it'll take some time to work backwards to figure out what is missing in the environment that caused the code to fall through to the mir code
<dobey> well, it couldn't connect to the X display
<TJ-> dobey: I gave it as an example of a quick test we tried to minimize the externals. But, the actual scripts use xdg-open yad and others, so tracing xdg-open now I know where the error is coming from, will actually help us find a workaround
<Saviq> who has access to snakefruit and could follow https://wiki.ubuntu.com/ProposedMigration/AutopkgtestInfrastructure#Re-running_tests to re-run the unity8 tests with --all-proposed? it's trying to build old unity8 with new unity-api and that won't work
<Saviq> the unity8 tests for http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api I meant
<Saviq> as we're in a chicken'n'egg situation
<sarnold> Saviq: just curious does that mean one of the packages is missing a version dependency of some sort?
<Saviq> sarnold, we never came up with the right way to encode those dependencies, we have a unity8 B-D: unity-api-dev >> $version
<Saviq> and a new unity-api-dev can break unity8 build
<lpotter> well... my update to xenial went better than the last time I tried...
<dobey> Saviq: it's only an issue becasue autopkgtests rebuild unity8 right?
<Saviq> dobey, bits of it still, yes
<Saviq> we're thinking how to avoid that
<Saviq> now that I think of it if we build-depended on a virtual package provided by unity-api-dev (is it even supported to B-D on a virtual package?), it would make it better
<Saviq> because a "breaking" unity-api-dev wouldn't Provide that any more
<dobey> hmm, well, unity8 seems to be flagged as always failing on yakkety, at least in my pay-service silo: https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-056/excuses.html
<Saviq> dobey, yeah but it's uninstallable
<Saviq> because of http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#unity-scopes-api
<dobey> but http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html doesn't show that any more
<dobey> err
<dobey> s/more/where/
<Saviq> i.e. https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-058/excuses.html
<Saviq> unity8-common/amd64 unsatisfiable Depends: unity-scopes-impl-12
<Saviq> and that is provided by unity-scope-shell, depending on the above unity-scopes-api, which regressed unity8... you know the drill...
<Saviq> *unity-scopes-shell
<Saviq> https://launchpad.net/ubuntu/+source/unity-scopes-shell/0.5.7+16.04.20160505-0ubuntu2
<Logan> hmm, any core devs around who want to trigger a no-change rebuild on portaudio19?
<Logan> see: https://launchpad.net/ubuntu/+source/espeakup/1:0.71-27/+build/9779375
<Logan> (it needs to be rebuilt against the pie-by-default compiler)
<Logan> slangasek, maybe?
 * slangasek tries to look busy
<Logan> :P :P
<slangasek> sbeattie: ^^ shouldn't portaudio19 have turned up in your list of libs for PIE no-change rebuilding?
<Logan> tsk tsk
<slangasek> Logan: portaudio19 uploaded
<Logan> cheers!
<rlaager> stgraber: Can you test the proposed fix in: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1567558
<ubottu> Launchpad bug 1567558 in zfs-linux (Ubuntu Yakkety) "ZFS is confused by user namespaces (uid/gid mapping) when used with acltype=posixac" [Undecided,Confirmed]
<sarnold> rlaager: cool :D
#ubuntu-devel 2016-05-21
<alkisg> Hi, when selecting the recovery entry in grub, I do get the whiptail-based rescue menu, but 1 minute later, some systemd jobs time out and complain about failed dependencies, and then start other things over the rescue menu, and the result is that the recovery mode is completely unusable in xenial
<sarnold> alkisg: try hitting ^L, see if that redraws the screen
<alkisg> It does, but moment, in my tests there were 2 processes reading stdin after that point, eating up half of the keypresses, let me reproduce the other part that isn't just about screen drawing...
<alkisg> (thanks btw...)
<alkisg> (the failed dependency in my current test is about swap, it's not mounted properly in recovery...)
<sarnold> blech it just keeps getting worse :)
<alkisg> Meh I can't reproduce the whole chaos in a vm, only on my real system so I'd have to reconnect to irc all the time...
<sarnold> :(
<alkisg> I'll try to reproduce it in a vm, but it'll take me some time, so I might have to continue that later, thank you... :)
<sarnold> does your vm have a swap device?
<alkisg> Yes, an extended one, the default ubuntu installation
<alkisg> swapon -a mounts it but systemd complains that the device isn't ready and it deactivates it after 1 sec...
<alkisg> I think that if I manage to achieve the swap target, then systemd will continue with the chaos that I see in my real system
<alkisg> Nope, I managed to make it to the swap target but I was still unable to reproduce the chaos in the VM. Maybe it's also related to the EFI/gpt that I have in my main system.
<alkisg> So for now I can only report the redrawing and the "swap failed" parts, which are minor, I'll come back when I've found a more solid way to reproduce the recovery chaos that I was talking about...
<stefanct> there was once a getXconsole function in lib/power-funcs from the acpi-support package that i was using in a script. any idea for an alternative in 16.04 and newer?
<Unit193> I don't suppose anyone will pull 'update-command-not-found' from Debian's command-not-found package?  This of course supports external repos whereas Ubuntu's doesn't.
<juliank> Unit193: We should really merge both variants into something common :/
<juliank> On the other hand, I thought about moving the u-c-n-f to apt-file
<Unit193> Like ubuntu shipping -data if needed.  And yeah, I need to file a bug on u-c-n-f. >_<
<Bluefoxicy> well that was inconvenient.
<Bluefoxicy> I allowed security updates and suddenly my keyboard and mouse and all USB stopped working
<Bluefoxicy> ssh in and dmesg while repeatedly unplugging and plugging in keyboard and kernel says "Whoa dude!  That USB cable might be bad!" reboot to fix
#ubuntu-devel 2016-05-22
<kees> uhm, http://changelogs.ubuntu.com/meta-release-lts <- shouldn't xenial be listed here?
<Unit193> Likely when it hits its first point release, yes.
<kees> oh right, I always forget that
<Unit193> slangasek: You missed #824943 with your upload to NEW.
<Unit193> *May have, don't remember all the different parts. >_>
<mcphail> mhall119: wrt http://mhall119.com/2016/03/help-make-gnome-software-beautiful/ , are you simply looking for new icons (and edits to the upstream .desktop files) or full, new appdata.xml files?
<elbrus> infinity: any luck on looking into the fpc with glibc on powerpc issue yet (LP 1562480)
<ubottu> Launchpad bug 1562480 in glibc (Ubuntu) "fp-compiler not installable on powerpc since glibc 2.23" [High,New] https://launchpad.net/bugs/1562480
<elbrus> I am getting multiple bug reports because we miss a feature from 3.0.0+dfsg-3
<elbrus> s/feature/bug fix/
<halvors1> Hi. Systemd version 230 came out yesterday with a lot of bug fixes, will you guys update systemd to this for Ubuntu 16.04?
<rbasak> halvors1: see https://wiki.ubuntu.com/StableReleaseUpdates. Seems unlikely to me that a new systemd upstream version would be suitable, but I don't know the details.
<halvors1> rbasak: Hmm. Because i'm hitting a really annoying bug with 229 :(
<halvors1> But at least it should be updated for yakkety ;)
<rbasak> halvors1: I'm sure Yakkety will be updated as appropriate. If there's a bug, please ensure a bug exists for it in Launchpad. Bugs in 16.04 can be fixed, just not necessarily by updating wholesale to a new upstream version.
<mhall119> mcphail: bad icons accounted for the bulk of the bad/missing appstream data, so we focused on that
<mhall119> but if you want to provide more, that would certainly be welcome :)
<mcphail> mhall119: :) - so a proper icon is OK with a tweaked .desktop file? Would probably be a bit much to expect upstream to package a metafile as well...
<teward> I"m seeing a ton of hook errors in Apport bugs as of late, and it prevents my apport hooks in nginx from running.  The traceback on the bugs points back to the 'general' apport hooks for any bug, who do I report this to for fixing?
<teward> this is in Xenial, and with apport hooks failing completely, there's no way to do debugging on those bugs (this extends to Yakkety, I believe, as well)
<rbasak> teward: a bug against apport might be appropriate there maybe? Do you have an example?
<halvors> rbasak: I did. https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1584491
<ubottu> Launchpad bug 1584491 in systemd (Ubuntu) "Starting DHCPv6 client on NDisc request failed: Invalid argument" [Undecided,New]
<halvors> ifupdown should really be replaced with systemd-networkd soon :)
<teward> rbasak: pick any of the latest 4 nginx bugs
 * teward grabs numbers
<teward> rbasak: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1581864 actually is a prime example, any foreign charsets (i.e. not english) choke the script, in rare cases the nginx hooks run, in others, it just fails.
<ubottu> Launchpad bug 1581864 in nginx (Ubuntu) "nginx.service: Failed to read PID from file /run/nginx.pid: Invalid argument" [Undecided,New]
<teward> rbasak: this is not "new" but it's new in so much that it's breaking *my* hooks when it tries to run
<teward> rbasak: it also makes it headachey to triage - i have to rely on the users to provide their data :/
<teward> rbasak: thankfully that person *attached* their data from the error logs that the hooks pull in
<teward> but there's other closed ones which are similar
<teward> and it's not confined to Xenial
<teward> perhaps the hooks need updated for international scripts?
<teward> hmm, maybe not that one
<teward> rbasak: it's probably buried under Expired
<teward> but let me grab the hook errors
<teward> here's one with International: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1584468
<teward> and it looks like this is a more general error too - https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1582954
<ubottu> Launchpad bug 1584468 in nginx (Ubuntu) "package nginx-core (not installed) failed to install/upgrade: Î· ÏÏÎ¿Î´Î¹ÎµÏÎ³Î±ÏÎ¯Î± installed post-installation script ÎµÏÎ­ÏÏÏÎµÏÎµ ÎºÎ±ÏÎ¬ÏÏÎ±ÏÎ· Î»Î¬Î¸Î¿ÏÏ 1" [Undecided,New]
<teward> both have hook errors
<teward> let me make a test bug...
<ubottu> Launchpad bug 1582954 in nginx (Ubuntu) "package nginx-light 1.10.0-0ubuntu1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Undecided,New]
<rbasak> teward: I think that's a bug that needs filing against apport.
<teward> ack
<rbasak> halvors: thank you for filing that.
<halvors> rbasak: It's probatly easy to do a backport of the commit that fixed that issue to 229 if that is desirable instead of upgrading the whole systemd package to 230 :)
<rbasak> halvors: if you're volunteering to do the backport, it'd be helpful to make that clear in the bug :)
<Unit193> LocutusOfBorg: Did you see PM a day or so ago?
<LocutusOfBorg> looking at it right now
<LocutusOfBorg> no anyway
<LocutusOfBorg> if it is about sponsoring, I'll look at it
<Unit193> \o/
<LocutusOfBorg> I'm gonna do it now
<LocutusOfBorg> making VCS-git in https
<Unit193> Eh...  I kind of intentionally left that one, but oh well.
<LocutusOfBorg> ok then
<LocutusOfBorg> done
<LocutusOfBorg> and pushed
<LocutusOfBorg> Unit193, can I sync it on ubuntu when it gets available?
<Unit193> LocutusOfBorg: Thanks.  And yeah, I was going to do that.
#ubuntu-devel 2017-05-15
<mwhudson> oh good good the celery in artful is not compatible with the kombu in artful
<mwhudson> ah it's only in proposed, phew
<mwhudson> jamespage: i assume you're asleep/not here but why did you sync kombu from experimental?
<jbicha> mwhudson: could you sync pygobject from Debian experimental?
<mwhudson> jbicha: ah does that have the ftbfs fix as well?
<lotuspsychje> good morning guys
<jbicha> mwhudson: yes, that's sort of where you got it from, I believe :)
<mwhudson> jbicha: okidoke :)
<lotuspsychje> ive edited 3 duplicate bugs on a fresh 17.10 install, all fixxed with dnssec=off
<lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1690605
<ubottu> Launchpad bug 1690605 in systemd (Ubuntu) "systemd-resolved: no dns resolution after upgrade to Artful" [Undecided,New]
<lotuspsychje> https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1681597
<ubottu> Launchpad bug 1682499 in systemd (Ubuntu Zesty) "duplicate for #1681597 disable dnssec" [High,Fix released]
<lotuspsychje> and https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1682499
<ubottu> Launchpad bug 1682499 in systemd (Ubuntu Zesty) "disable dnssec" [High,Fix released]
<mwhudson> jbicha: synced
<lotuspsychje> just letting you guys know it wasnt fixxed on a yesterdays install
<jbicha> xnox: systemd-resolved problems in artful for some people ^
<lotuspsychje> i enabled updates during setup
<mwhudson> what does launchpad's sbuild do with alternates in build-depends? i know debian's just takes the first entry
<pitti> mwhudson: it uses apt to resolve them, so it does take alternatives into acconut
<pitti> mwhudson: so "B-D: some-nonexisting-package | libfoo-dev" will work in Ubuntu, and we do use that occasionally to avoid a delta to debian
<mwhudson> pitti: but if all packages are available, it should use the first one?
<pitti> mwhudson: right, unless that's conflicted to by another build dep
<mwhudson> hm
<pitti> the first is the "preferred" alternative (in D and U), but if that's uninstallable, apt tries permutatinos
<mwhudson> pitti: what happened here then? https://launchpadlibrarian.net/319663773/buildlog_ubuntu-artful-amd64.aubio_0.4.3-4ubuntu2_BUILDING.txt.gz
<mwhudson> pitti: the dep is "python3-all-dev | python3-dev | python3 | python3-all" but it installed python3
<mwhudson> when i just deleted everything but the first dep it installed fine
<xnox> jbicha, re:u-u-t and dconf-qt i believe both are dead, but needs actual checking of reverse deps and filing bugs etc.
<xnox> jbicha, re systemd-resolved dnssec was re-enabled in the hope that it is better in latest new upstream release.... turns out it is not.
<pitti> mwhudson: did it actually install python3? it might already have been installed in your build env, so it was already satisfied that way
<pitti> mwhudson: but that doesn't make any sense as a build dep anyway -- either you need -dev or not, and either you want -all (for building a python module package) or not (for building a program that uses python, but doesn't export public libraries)
<mwhudson> pitti: no, it really installed python3
<mwhudson> Get:12 http://ftpmaster.internal/ubuntu artful-proposed/main amd64 python3 amd64 3.5.3-1ubuntu3 [8710 B]
<mwhudson> pitti: i agree it's nonsensical
<pitti> hm, if none of them was installed, it should have installed python3-all-dev indeed
<mwhudson> so it's not a real problem, but i was a bit confused nonetheless
<mwhudson> this smells like a wgrant or infinity sort of problem
<xnox> we do building with resolve alternative depends, thus it can choose other things if something else listed python3 | python3-all-dev for example.
<xnox> but meh, indeed such a b-d doesn't make much sense.
<mirak> hi
<mirak> how ubiquty knows what packages it must install ?
<infinity> xnox: I'm not sure how the dnssec bits in systemd-resolved can get "better", given that they rely on the internet not being crap.
<xnox> infinity, touche
<xnox> infinity, they fixed bugs, but not enough of them =)
<infinity> xnox: Insert one DNS server that publishes zones that claim to require dnssec and aren't signed (or are incorrectly signed), and your world explodes.  systemd can't fix that.
<xnox> well, it has fallback mode, which is not falling back hard enough, imho
<infinity> xnox: That above situation is exactly where you shouldn't fall back, though.
<xnox> and a lot of it is downgrade attacks if one does fallback too much
<infinity> xnox: Because falling back is accepting a potential MITM.
<xnox> yeah
<xnox> but what we do now is disable dnssec completely in stable series
<infinity> So, I aplaud the effort to use systemd to debug the internet, but the result is pretty frustrating.
<xnox> i'd rather have "we tried dnssec and it did work, you are dnssec connection *this* time" instead of "we didn't even bother"
<infinity> If there was a UI for this, sure. :P
<xnox> that's what the fallback option was supposed to do....
<infinity> But it's not like the user knows "hey, this lookup was dnsseccy".
<xnox> but doesn't
<infinity> They just know "the internet works" or "the internet is broken".
<xnox> google chrome shows that i think; but that i think also bypasses NSS to get that info.
<infinity> Yeah, there's no way one can get that info from gethostbyname.
<xnox> nah, plugin.
<xnox> (not builtin indicator into google chrome)
<infinity> I mean, if/when dnssec becomes the norm, I'm perfectly happy with a setup that drops badly-configured DNS zones on the floor.
<infinity> Just as I'm happy blackholing email from poorly-configured SMTP servers.
<infinity> But today probably isn't that day.
<xnox> yeah
<infinity> People are still learning how to use dnssec correctly, and it seems that a large number of them are learning slowly and poorly. :P
<maswan> I find that the problem isn't so much badly configured zones, as captive portals
<infinity> maswan: I've seen a lot of the former.  But the latter definitely makes things even more "interesting", for sure.
<maswan> Which mess with DNS (and all other things too)
 * xnox loves how android rejects captive portals with expired SSL certificates, for example London Underground WiFi
<infinity> The only reasonable solution to the captive portal mess is some collusion among OS and browser vendors to just test some well-known location.
<infinity> Cause "spoof DNS for the world" doesn't work in a dnssec world.
<maswan> yeah. been seeing more and more browser stuff of "this network appears to require a login" features testing towards a well-known page
<maswan> since it is already breaking for a mostly https world
<maswan> One more data point, a majority of swedish household ISPs do dnssec validation on the resolvers provided to the users
<maswan> So broken zones would be broken to them anyway
<infinity> maswan: Yeah, but who cares about Sweden? :)
<infinity> (Also, that's quite progressive... Next you're going to tell me that all Swedish ISPs give their customers v6 IPs and routing, too?)
<infinity> I wish the Canadian ISPs would wake up on that score.
<maswan> Nah, v6 they're horribly behind the curve on
<mapreri> jbicha: ok.  BTW, for me this is a proof that keeping the old changelog entry is useful, until you said so I believe you were the person introducing the delta.
<mapreri> :)
<hallyn> sarnold: bug 1690820 , fyi.  I can create a package for a, but istr there's a special process for security regressions?
<ubottu> bug 1690820 in shadow (Ubuntu) "killing su does not kill subprocess (SIGTERM not propagated)" [Undecided,New] https://launchpad.net/bugs/1690820
<mdeslaur> hallyn: do you know what the issue is?
<mdeslaur> sarnold: FYI ^
<hallyn> mdeslaur: yes, a security fix for unpriv users being able to kill other user's shells, introduced a regression which prevents sigterm sent to su fro mbeing forwarded to the job
<hallyn> (the git commit has the details)
<hallyn> yeah i assumed i was too early for sarnold, i know how he rolls :)  he probably just got to bed 2 hrs ago :)
<mdeslaur> hallyn: if you have the commit or the debdiff, could you attach it to the bug for sarnold to release as a security regression fix?
<mdeslaur> it does need to be built as a security regression updates
<mdeslaur> *update
<hallyn> mdeslaur: sure.  sorry i didn't even open the bug, assumed it would have a link to the commit.  will add it.
<hallyn> (added) \o
<mdeslaur> hallyn: thanks!
<sil2100> jdstrand_: hey! I was just looking at promoting snapd from -proposed to -updates and saw that LP: #1664638 has a comment from George - could you check if it's still good to go? I don't have enough context
<ubottu> Launchpad bug 1664638 in snapd (Ubuntu Zesty) "Need an interface for kubernetes" [Undecided,Fix committed] https://launchpad.net/bugs/1664638
<jdstrand_> sil2100: hi! the comment doesn't change what I said about the interface and its suitability for SRU. it is a work in progress interface that jut needs to be iterated on and George gave comments so that could happen
<sil2100> jdstrand_: ACK, in that case I'll be releasing it to -updates
<jdstrand> sil2100: great :)
<sil2100> jdstrand: hm, although I do see an autopkgtest failure for zesty
<sil2100> jdstrand: for armhf
<sil2100> jdstrand: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-zesty/zesty/armhf/s/snapcraft/20170511_171104_47fb3@/log.gz <- from snapcraft
 * jdstrand looks
<sil2100> Argh
<sil2100> Networkin error
<sil2100> Let me quickly re-run
<jdstrand> sil2100: that's all unrelated, yeah
<sil2100> Temporary failure resolving 'ftpmaster.internal'
<sarnold> hallyn: thanks <3 :) you know me too well
<sil2100> jamespage: hey!
<sarnold> hallyn: since A requires a merge from debian still I didn't actually fix shadow there
<sil2100> jamespage: I'm currently looking into releasing neutron-lbaas to -updates - the bug is verified for all releases but I just wanted to make sure it's tested both for neutron and neutron-lbaas, right?
<sil2100> I mean, it's tested with both packages, right?
<hallyn> sarnold: oh, so sru only?
<sarnold> hallyn: well, the security fix is still needed there, of course; it's a bit strange not being able to upload for -devel :/
<hallyn> so the security upgrade only exists in z, and that's bc it happened before a started?
<hallyn> noone should run z anyway, so ... :)  (it'st lts and not the latest :)
<sarnold> hallyn: exactly! :) I managed to lose two races on that one -- both z was released and p closed before I got the update out. agrh.
<sarnold> hallyn: or maybe that's three races lost, z released, a opened, p closed.
<sarnold> hallyn: in any event I was finally happy to have moved on. sigh. :)
<hallyn> sorry :(
<hallyn> and hopefully the code is right this time.  that's some fragile stuff
<sarnold> for as much time as I spent reading it i'm surprised to have missed it :(
<jamespage> sil2100: it is yes
<jamespage> thanks
<nacc> rbasak: dpb1_: fyi, automatic import restarted after the tooling change to `git ubuntu`
<nacc> meaning i think it works :)
<dpb1_> nacc: this sounds like good news
<nacc> rbasak: working on fixups to my namespace branch, i'll push (probably over the top, maybe replace) the branch again once
<dpb1_> :)
<nacc> dpb1_: yeah, `usd` is dead :)
<dpb1_> woohoo
<dpb1_> what git commit is that?
<nacc> slangasek: --^ as well. Still need to do the git delta for the automatic setup of lp:, but on my todo for this week
<nacc> dpb1_: master for the fully working replacement, but `usd` was killed in a separate branch (so the snap can redirect to git-ubuntu), sha of master right now is fa6e2ec5
<nacc> dpb1_: shell completion is still not quite working in the snap, but i recall some discussion in #snappy about it, i'm going to go read the logs
<nacc> *after lunch
 * dpb1_ nods
<mdeslaur> infinity: thanks for the mysql-5.7 sync
<nacc> rbasak: around?
<rbasak> nacc: sorry, just about to disappear
<nacc> rbasak: np, will talk tmrw
<nacc> rbasak: well, i think the namespace branch i have locally is 'just working' :)
#ubuntu-devel 2017-05-16
<slangasek> cyphermox: what was the resolution of the mtu issues in NM?  I'm trying to debug flaky wifi on zesty, and while NM hasn't been upgraded recently I notice that the interface is back to an MTU of 1500
<slangasek> cyphermox: and that furthermore, the NM UI doesn't let me save any edits to the MTU...
<slangasek> (this may be only part of my issue; I also see 78% packet loss to VPN endpoint)
<slangasek> cyphermox: looks like I'm seeing packet loss from my laptop on the local link, which is not affecting other devices on my network... so maybe not something that points to NM
<mwhudson> i wonder if i can rig/wrap dput to do some checking of version number against upload target
<mwhudson> e.g. if it's ppa target, version number must contain "~ppa"
<slangasek> cyphermox: right, so... I was just having problems because systemd-resolved and dnsmasq were arguing again and this time pulled the vpn dns server into the fight
<slangasek> nothing to see here, just packet flooding myself
<nacc> mwhudson: yeah, it should be doable
<mwhudson> not uploading $ver-0ubuntu1~16.10 to xenial would be nice too :)
<nacc> mwhudson: heh, yeah, there are some heuristics we can apply
<sarnold> oh yeah that'd be nice
<nacc> mwhudson: i think; we've talked about doing some of those in our git push equivalent of dput
<sarnold> here's the entry point to a bunch of the security team's heuristics http://bazaar.launchpad.net/~ubuntu-security/ubuntu-security-tools/trunk/view/head:/build-tools/umt#L539
<nacc> mwhudson: (to be implemented, to be clear)
<mwhudson> in fact, checking for SRU-type versions for non-dev-series uploads would be nice in general
<nacc> mwhudson: yeah, we already track which series (or at least have a wrapper to LP API) for active and stable series, etc.
<mwhudson> i've made that mistake every distro opening i've been core dev for so far :)
<nacc> mwhudson: if you want to file feature-like bugs aginst the importer project, to document ideas, that'd be awesome
<nacc> as we are working on a proper roadmap, etc. now :)
<mwhudson> there was a thread about this sort of thing on debian-devel recently i think
<nacc> and usability issues like that generally are exactly what i'd like to help avoid :)
<mwhudson> although of course our heuristics would be entirely different
<mwhudson> nacc: launchpad project name?
<nacc> mwhudson: if you ahve a pointer, please send it my way, or i can go look tmrw
<nacc> mwhudson: https://bugs.launchpad.net/usd-importer
<nacc> mwhudson: not by any means a requirement to file there, but i feel like the server team, at least, is collecting a lot of 'tooling' like requests in there -- and we can lways reassign to other tools as needed, or open tasks
<mwhudson> nacc: ack
<nacc> mwhudson: thanks!
<mwhudson> nacc: https://bugs.launchpad.net/usd-importer/+bug/1690967
<ubottu> Launchpad bug 1690967 in usd-importer "check package version number against upload target" [Undecided,New]
<derp_commander> !info
<mwhudson> naughty cking, he didn't update-maintainer when he uploaded ltt-control/2.9.3-1ubuntu1
<Unit193> gtk+3.0 (3.22.15-0ubuntu1) artful; urgency=medium
<Unit193>   * New upstream release 3.12.15 (also includes 14, 13).
<viral_mutant> I am creating a DEB package with are bunch of .service files . I am bit confused when to use the âdh âwith systemdâ ?
<viral_mutant> the dh_installinit automatically puts the service files in appropriate directory
<viral_mutant> what would âwith=systemd do ?
<mwhudson> viral_mutant: --with=systemd is what ensures dh_installinit gets run at all, i think?
<mwhudson> uh no
<mwhudson> sorry, --with=systemd inserts calls to dh_systemd_enable / dh_systemd_start
<viral_mutant> mwhudson: what would happen if I donât include âwith systemd
<mwhudson> viral_mutant: i don't know :)
<viral_mutant> :)
<sil2100> jbicha: hey, I'm looking at gnome-desktop3 in the zesty queue right now - I probably need some additional context on how relevant this version-bump is
<sil2100> jbicha: since to me right now it doesn't really look like a SRU-valuable change
<tjaalton> doko: hi, newer mesa seems to ftbfs on ppc64el on xenial, gcc segfaults (yakkety, zesty are fine). https://launchpadlibrarian.net/318462556/buildlog_ubuntu-xenial-ppc64el.mesa_17.0.5-0ubuntu1~16.04.1~2_BUILDING.txt.gz
<tjaalton> doko: do you have ideas?
<tjaalton> hmm
<tjaalton> doko: looks like this was fixed before but since dropped from the package, I'll try forcing -O2 again
<jamespage> if there is a MIR team member around - bug 1688091 is the MIR review for vine, which is blocking quite a bit of proposed from migration atm (via amqp/kombu dependencies)
<ubottu> bug 1688091 in vine (Ubuntu) "[MIR] vine" [High,New] https://launchpad.net/bugs/1688091
<tjaalton> doko: yep, that fixed it, heh
<jbicha> sil2100: the gnome-desktop3 SRU is low priority but I think it is useful LP: #1689371
<ubottu> Launchpad bug 1689371 in gnome-desktop3 (Ubuntu Zesty) "Update gnome-desktop3 to 3.24.2" [Low,In progress] https://launchpad.net/bugs/1689371
<slashd> rbasak, morning I see you talked with dragan about this LP: #1645324. From now on, I'm taking care of this bug, I see that some ppls suggest Dragan to submit in the upstream project first, but in this case it seems that ebtables is nearly "dead" last commits were made in 2015. Nowadays, all the development happen in nft. Do you think Dragan's patch could be eligilble for SRu anyway ? considering that Dragan already submitted
<slashd> the same patch to Debian ebtables but not upstream.
<ubottu> Launchpad bug 1645324 in ebtables (Ubuntu Artful) "ebtables: Lock file handling has races" [Medium,In progress] https://launchpad.net/bugs/1645324
<sil2100> jbicha: yeah, but what do those change from the user POV? I mean, it's just a version number change, so without context I fail to see the point to get this released as an SRU
<sil2100> Not saying there is no point, just that I possibly lack the context or knowledge
<jbicha> sil2100: in Artful, the GNOME version number shows up in gnome-control-center (it was patched out in previous Ubuntu versions): https://bicha.net/i/ubuntu-details-1710alpha.png
<jbicha> since we are SRUing most of the rest of GNOME 3.24.2, the correct version number to report is 3.24.2, but like my bug says it's difficult to find anywhere in 17.04 where this is shown to users
<jbicha> we did the update once a month ago LP: #1682236
<ubottu> Launchpad bug 1682236 in gnome-desktop3 (Ubuntu Zesty) "Update gnome-desktop3 to 3.24.1" [Low,Fix released] https://launchpad.net/bugs/1682236
<sil2100> jbicha: ok, thanks for the context o/
<sil2100> jbicha: while I'm on the gnome-* packages, do you know if there's by any change some test-case for checking if https://bugs.launchpad.net/ubuntu/+source/gnome-maps/+bug/1688702 is fixed?
<ubottu> Launchpad bug 1688702 in gnome-maps (Ubuntu Zesty) "/usr/bin/gjs-console:11:g_slice_free_chain_with_offset:g_list_free:maps_contact_store_dispose:g_object_unref:release_native_object" [Medium,In progress]
<sil2100> jbicha: like, does anyone know when the crash is happening to test if it's fixed or not?
<cyphermox> slangasek: re: packet flooding yourself> sure, but how come dnsmasq and resolved are arguing?
<jbicha> sil2100: I don't know how to trigger the gnome-maps crash
<sil2100> Might be tricky to validate that one I guess
<jbicha> the way I validate it is by checking to see if that error is reported with the new version
<jbicha> but sometimes the error isn't reported yet because not enough people are running the new version
<sil2100> Is there a lot of -proposed testers for gnome?
<jbicha> no, are there a lot of -proposed testers any where? :(
 * musician_pro si chiede se gmail non stia funzionando solo a lui
<rbasak> slashd: can we get the patch committed/uploaded into Debian? That would also alleviate Ubuntu's maintenance burden.
<sil2100> jbicha: then it might be a bit troublesome to get it verified once it's in -proposed, right?
<slashd> rbasak, sure will look at Dragan's debian bug status and continue from there.
 * rbasak wonders if it's time to unseed ebtables in favour of nftables
<rbasak> Relevant rdepends are lxd, neutron, nova, and a reverse recommends of libvirt.
<rbasak> jamespage, cpaelzer: ^ maybe something to consider for the future?
<cpaelzer> why does libvirt has to be mentiond in all kind of "old dependency" discussion :-)
<rbasak> ebtables appears pretty much unmaintained now.
<rbasak> :-)
<cpaelzer> rbasak: checked this, but that is not an ubuntu thing - not even Debian
<cpaelzer> rbasak: the dependency is from upstream and it is more than a bit
<cpaelzer> rbasak: so while I agree that would be a major upstream dev effort followed by a transition after merging that
<jbicha> sil2100: it's the same way I verified similar crash reports; but what's the harm if the fix is incomplete? we'll just have to reopen the issue and try again but it doesn't need to reject the update
<rbasak> cpaelzer: understood, thanks.
<sil2100> jbicha: it's just part of the formalities - every update is potentially risky, so it's generally best if we can somehow know if the given upload fixes the bug in mention, not to introduce additional risk for no reason - that's the theory of course
<sil2100> That being said I'll review it and if it's all good I'll let it in
<slashd> rbasak, in another subject, did you have the chance to look the isc-dhcp split binary ? (LP: #1176046) ?
<ubottu> Launchpad bug 1176046 in isc-dhcp (Ubuntu Trusty) "isc-dhcp dhclient listens on extra random ports" [Wishlist,In progress] https://launchpad.net/bugs/1176046
<rbasak> Not yet, sorry.
<slashd> rbasak, no problem
<Laney> sil2100: There used to be a time when the upstream fixes GNOME updates claimed to have were believed.
<Laney> I think that accidentally went away. Can we get closer back to that situation?
<seb128> Laney, what do you mean "were believed"? (sorry missed the start of the discussion)
<Laney> There was a GNOME Micro Release Exception.
<Laney> And it said that you don't have to explicitly verify each bug that upstream says is fixed.
<sil2100> Laney: I'll approve it as is, but currently I don't see any MRE (or don't know where to look for one) for gnome - maybe that's worth rediscussing then?
<sil2100> (checked the upload and it's fineish)
<Laney> sil2100: The SRU team moved to a more general MRE policy some time ago, and that obsoleted the GNOME one we had before.
<Laney> But I don't think most GNOME uploads meet the strict criteria that the new rules lay down...
<Laney> Formal upstream QA documents, autopkgtests, ...
<sil2100> Although I would really like that if some upload mentions to be fixing a crash and that being part of the SRU, I would prefer seeing at least a way of verifying if it's really the case
<sil2100> At least for the future
<sil2100> But I r a noob
<Laney> So yes, it would be great if we could get back to a frictionless way of uploading new GNOME point releases as SRUs.
<Laney> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions?action=recall&rev=59
<Laney> You can see the old verification process there
<seb128> sil2100, Laney, back then it had been discussed on https://lists.ubuntu.com/archives/technical-board/2012-June/001327.html
<Laney> Good link, thx
<seb128> yw
<jbicha> sil2100: I am actually able to reproduce the maps crash now so I'll update the SRU bug
<sil2100> jbicha: \o/
<jbicha> but there's still the point that often there are crash fixes where I can't duplicate the original crash, partly because errors.ubuntu.com gives very little context
<jbicha> if it's going to be a problem me being unable to verify a likely crash fix, then there's incentive for the SRU uploader to just not mention the LP crash bug # in the SRUâ¦
<seb128> e.u.c can tell you if reports stop with the new version
<seb128> your verification step can be "check that e.u.c reports don't exist on the new version"
<jbicha> right, that's what I said in LP: #1688702
<ubottu> Launchpad bug 1688702 in gnome-maps (Ubuntu Zesty) "/usr/bin/gjs-console:11:g_slice_free_chain_with_offset:g_list_free:maps_contact_store_dispose:g_object_unref:release_native_object" [Medium,Fix committed] https://launchpad.net/bugs/1688702
<seb128> and if it's not possible to verify you can always state "check that there is no regression"
<seb128> even if it doesn't actually fix it, as long as it doesn't create a new issue it should be ok
<sil2100> seb128: right, but errors will stop if users stop experiencing those - and there's not too many -proposed users around
<sil2100> seb128: so errors will still keep appearing until this goes to -updates for normal users to get them, right?
<sil2100> Anyway, it's approved already, but I *personally* don't like the idea of letting in things to from -proposed to -updates without actually verifying if the fix fixed anything
<santa_> mdeslaur: hi
<sil2100> As that's what I would expect for most SRUs
<mdeslaur> santa_: hi
<santa_> sorry if you are busy with something else, I just wanted to ping you about this security issue https://bugs.launchpad.net/ubuntu/+source/kauth/+bug/1689759
<ubottu> Launchpad bug 1689759 in kauth (Ubuntu Yakkety) "CVE 2017-8422 - kauth: Local privilege escalation" [High,In progress]
<santa_> because apparently it's not fixed yet in the LTS
<mdeslaur> santa_: it's community-supported...I see there are debdiffs in the bug. sbeattie is on community-sponsoring duty this week.
<santa_> ok
<seb128> sil2100, well, errors are matching a version of the package, so the fact you keep getting report isn't an issue, what you are looking for is sign of if there are report coming from the proposed version ... which true, is getting less testing, but new version sometime gets tested in new series
<sil2100> seb128: yes, but generally speaking if you don't see any mention of the version from -proposed in errors doesn't explicitly mean it's clean, it might mean: 'no one tested it' as well - or are there some metrics that could say otherwise?
<sil2100> I don't like the idea of uncertainty
<jbicha> sil2100: seb128 is offline
<sil2100> jbicha: anyway, all gnome- packages for zesty reviewed and approved o/
<Laney> sil2100: Sounds like you're arguing against restoring the MRE
<Laney> ?
<sil2100> Laney: *sigh* I'm not arguing
<Laney> Umm, I didn't mean arguing in that sense
<sil2100> I'm by no means an authoritative person, just saying that having a *reliable* test case is something I require from most SRUs that explicitly mention fixing a given bug, as per the currently standing procedures
<jbicha> thanks
<slangasek> cyphermox: I have not yet taken the time to debug the dnsmasq/resolved argument.  The dnsmasq is for libvirt, so not NM-related per se
<cyphermox> oh
<cyphermox> well, I'll keep an eye out for that kind of issue
<slangasek> cyphermox: there's probably three elements here: the system resolved, dnsmasq for libvirt, and split DNS for VPN
<cyphermox> yep
<slangasek> that seems to be enough to trigger a loop
<cyphermox> well I should be able to easily trigger this here
<nacc> rbasak: are you available to discuss git stuff?
<slangasek> cyphermox: it's possible a fourth element is that I've manually disabled nss_resolve on my host (/etc/nsswitch.conf) in order to force consistent behavior between host and chroots for debugging
<cyphermox> slangasek: nevertheless we really should have all of that working correctly
<slangasek> cyphermox: of course - I'm just saying that if you have trouble reproducing it, that might be a factor
<cyphermox> ok
<cyphermox> I haven't got to it yet, still busy with netplan and grub.
<slangasek> or it might be that I'm doing a lot of !A, !CNAME dns lookups
<slangasek> yeah, I certainly don't think this is a priority for you to dig into
<cyphermox> AAAA?
<slangasek> !A* ;)
<cyphermox> TXT then?
<cyphermox> (weee)
<slangasek> MX, TXT, SRV
<slangasek> (kerberos, local postfix)
<cyphermox> all the things that work really really well
<rbasak> nacc: not tonight, sorry
<nacc> rbasak: ok
<smoser> anyone successfully  use a bluetooth headset with gnome3 shell ? after switching to it (and to gdm3), my bluetooth headset doesn't show up in the sound settings.
<nacc> smoser: i have used it a few times
<nacc> smoser: in my case, my bt headset autocnnects, but doesn't work, so i have to go to bt settings, disconnect, then reconnect it and then it works
<jbicha> smoser: what Ubuntu version are you using?
<smoser> 17.10
<pdeee> rbasak, RAOF I just thought I'd ping about the Certbot SRU
<rbasak> pdeee: o/
<rbasak> pdeee: I need to find some time to sit down and catch up on that :-/
<pdeee> rbasak, we'd be happy to schedule a call or work session to get it done
<pdeee> we've been looking at our analytics and being a little horrified by how many of our users are running the ancient and unecessarily buggy Xenial packages
<rbasak> pdeee: that's a good idea. What time zone are you in?
<pdeee> we're on US Pacific time
<pdeee> San Francisco
<pdeee> you?
<rbasak> UTC+1
 * pdeee nods
<pdeee> we could do a 9am (us) / 6pm (you) call most days
<rbasak> Let me check my calendar
<slangasek> pdeee: by chance, has anyone talked to you about possibly migrating this to a snap package?  That would seem to be a better overall fit than periodically SRUing
<rbasak> slangasek: I'm not sure snaps are ready for certbot yet, due to the deep integration needed with existing deb-based packages (apache2, nginx, etc).
<pdeee> slangasek, apparently someone emailed some of our team members about them, but we haven't evaluated them closely
<Unit193> And there'd still be a lot of users on the real package, not the snap.
<slangasek> fwiw I had taken a brief look at those packages in the SRU queue and gave them a pass, because they're far from being a straightforward fit for the SRU process
<rbasak> Yeah - we'd need to carry on SRUing until a snap has feature parity and the distro release doesn't carry the deb I think.
<pdeee> Certbot has been a pain to package. The high level summary of why is:
<slangasek> rbasak: well, at some point I think we would make the deb in SRU transition to the snap; and yes, there are definitely integration touchpoints to figure out
<slangasek> Unit193: a snap is also a real package ;)
<Unit193> slangasek: Meh, whatever floats your boat...
<pdeee> 1. pyopenssl and python-cryptography are cffi-based wrappers to openssl. They're the best option for python crypto code today, but they're horribly fragile
<pdeee> native .deb / .rpm packages are the least-bad answer for getting an unbroken python-cryptography
<infinity> If only there was a way to talk to openssl without python.
<pdeee> we somewhat regret not having taken the bullet and just shelled out to openssl for everything Certbot needs from it
<rbasak> pdeee: how about tomorrow (17 May) at 1700 UTC for an hour? With the goal being to catch up and plan what needs doing next to get this landed.
<pdeee> there would have been a lot of awful if openssl version < x do A else do B
<pdeee> rbasak, that works for bmw and I
<rbasak> pdeee: what do you prefer? Eg. Google Hangout? IRC? Something in the middle?
<pdeee> I'll also invite our Debian maintainer, though I can't promise his availability
<rbasak> Sure
<pdeee> rbasak, Hangouts are good
<infinity> pdeee: Yeah.  I was actually referring to using libssl directly with C, not openssl(1), but also, don't mind my drive-by sarcasm.  An interpreted language is probably the right solution for this sort of project, as much as the bindings suck.
<rbasak> OK, I'll send invites. Can you send me the relevant email addresses? Privately if you wish.
<pdeee> rbasak, probably faster for me to do it since they're all in my addressbook :)
<rbasak> Sure :)
<rbasak> pdeee: that showed up at 1600 UTC for me. Are you sure that's right? It's fine there BTW, just want to make sure we don't miss each other.
<rbasak> Uh, 1500 UTC. 1600 local.
<rbasak> Isn't that about 6am for you?
<infinity> If he's in hawaii.
<nacc> heh
<infinity> rbasak: "TZ=America/Eastern date -d '1500 UTC'" (adjust to taste) is your friend if you hate timezones.
<infinity> Err, well, if that was a timezone.
<rbasak> I choose to just be friends with UTC instead. Everyone should be UTC's friend :-P
<infinity> America/New_York even.
<infinity> Oh, US/ is where Eastern lives.
<infinity> Silly zoneinfo.
<pdeee> rbasak, that's odd. 8am here is usually 17:00 in Central Europe...
<pdeee> unless there's a daylight saving difference, which there shouldn't be? Anyway, happily moving it an hour later :)
<infinity> pdeee: You're Pacific?
<pdeee> yes
<infinity> If so, yes.  8am for you is 1600 for rbasak and 1700 for central Europe, you're not wrong. :P
<pdeee> oh he said UTC + 1 but he meant daylight savings rather than Central Europe :)
<infinity> http://paste.ubuntu.com/24588672/
<infinity> Right.  He meant BST.
<rbasak> Forget daylight savings. "date -R" -> UTC offset. Know your UTC offset. That's all that's needed :)
<rbasak> No need for any other timezone knowledge, except that UTC offsets may change due to daylight savings (so is time-of-year sensitive).
<pdeee> RAOF, presuming if you're in Hobart that you won't want to join us :)
<infinity> rbasak: UTC offsets confuse all of us who grew up with sysv timezones, because "PST8PDT" is only 8 for a portion of the year, and then our poor North American heads explode.
<pdeee> RAOF, but I'll send you a calendar invite just in case you're a night owl, and we can take notes in any case
<infinity> (I'm MST7MDT, and it's never made sense to me... And this is the part of the year where I'm -0600 and confused)
<nacc> rbasak: do you want me to also join? or are you ok on your own? :)
<rbasak> infinity: well, that's just "limited knowledge is limited". Anything North America -specific fails internationally.
<infinity> Well, also, thanks to the US levering daylight savings wider and wider, MST7MDT is 6 a lot more than it's 7.
<infinity> rbasak: Well, yes, which is why sysv timezones are deprecated, but old habits (and the thought processes that accompany them) die hard. ;)
<rbasak> nacc: join if you wish. I may want you to review uploads with me later but I don't think we'll cover anything controversial or anything.
<cjwatson> I'm pretty sure MST7MDT is a cult TV show.
<nacc> rbasak: ack ok
<infinity> rbasak: It's just one of those things where I gave up and use date to tell me the truth now because my brain is permanently broken WRT timezones.
<slangasek> cjwatson: +1
<infinity> cjwatson: That's MST3KDT
<cjwatson> Silly me.
<infinity> Which would be the episode where they do nothing but voiceovers of Donald Trump speeches.
<infinity> Which, it turns out, need no alteration to be ridiculous, so it was their vacation episode.
<nacc> zing
<pdeee> infinity, on the openssl front, I think my tentative conclusion is that the openssl project should take over maintainership of python-cryptography and pyOpenSSL, so that they can protect those libraries with tests and release them in sync with openssl itself
<slangasek> barring that, if the tests exist we can+should make sure they're being run as autopkgtests in Ubuntu
<cjwatson> (autopkgtests ensure that dependencies don't get out of -proposed if they break things depending on them)
<pdeee> slangasek, they do; when openssl breaks those python bindings it's usually not subtle, so running python-cryptography's tests should be sufficient
<pdeee> on one memorable occasion, openssl broken them with a security patch
<infinity> That sounds like openssl alright.
<santa_> acheronuk: so ... I think we have the security issues either fixed or with a pending patch. tomorrow I guess I will resume my work on applications. thank you for the fixes you have done today, good job
<sbeattie> santa_: kauth for xenial/yakkety were published.
<acheronuk> santa_: that's good. yeah, I just stuck with kicking/prodding the CI today.
<santa_> sbeattie: thank you very much! we had a harsh week @ kubuntu :)
<nacc> rbasak: can you explain again why we wnat the --no-tags option by default? e.g., in that case, a pack exists so git resolves the tag, but there is no .git/refs/tags that correspond (so our copy algorithm doesn't quite work)
<rbasak> nacc: because git doesn't namespace tags between remotes. So you'd end up pulling or pushing tags to the wrong namespaces.
<nacc> rbasak: ok, but for the importer's run, i think we do want to fetch tags
<nacc> rbasak: as it's 'special'
<rbasak> nacc: sure, but according to a specific refspec surely, rather than refs/tags/*:refs/tags/* which it would do otherwise.
<nacc> rbasak: oh i see what you're saying
<nacc> rbasak: ok, yeah, that's true
<nacc> rbasak: well, my point about the pushing side is that you'd need permissions to do that
<nacc> rbasak: and it won't push a tag to a new commit without -f
<nacc> rbasak: so i feel like we're trying to avoid something that doesn't really need to be avoided :)
<rbasak> Yes, but we're trying to not rely on that, to also protect ~usd-import-team members.
<nacc> fair enough
<rbasak> Without --no-tags, I believe it tries to push tags corresponding to any other ref you push.
<nacc> this isn't for git-push though
<nacc> this is a fetch opt
<nacc> oh it's a *remote* opt
<nacc> i see
<nacc> rbasak: well, the idea of a refspec then changes the specification again :)
<nacc> a refspec for tags, i mean
<nacc> rbasak: or do we leave the refspec for tags in debian/ubuntu remotes, but just simply not fetch them?
<doko> tjaalton: did we see this ICE on ppc64el earlier?
<nacc> rbasak: the updated MP successfully imports php7.0 and php7.1 with proper fast-forwarding etc.
<nacc> rbasak: if you can find time tmrw, i'd like to go through it together
#ubuntu-devel 2017-05-17
<tjaalton> doko: yep, in xenial at least
<tjaalton> doko: but forcing -O2 fixed it
<flavian> Hello, I am quite new into building deb packages, and I have a problem while building some deb packages for a PPA, I am using a cmake project, and after it compiles I am selecting what files to deliver into separate packages with .install files. How can I explicitly tell where it should install those files, for example for one package (after I do dpkg -c ) I have:
<flavian> drwxr-xr-x root/root         0 2017-05-17 12:46 ./ drwxr-xr-x root/root         0 2017-05-17 12:46 ./usr/ drwxr-xr-x root/root         0 2017-05-17 12:46 ./usr/share/ drwxr-xr-x root/root         0 2017-05-17 12:46 ./usr/share/doc/ drwxr-xr-x root/root         0 2017-05-17 12:46 ./usr/share/doc/libmraa-java/ -rw-r--r-- root/root      2232 2017-05-16 18:16 ./usr/share/doc/libmraa-java/copyright -rw-r--r-- root/root       181 20
<flavian> -rw-r--r-- root/root     30662 2017-05-17 12:46 ./usr/lib/lib/java/mraa.j
<flavian> I would like to only have  /usr/lib/java/mraa.java, is there a way to midify/config this?
<flavian> nevermind, I found my answer :D
<mirak> hi
<mirak> please allow to no install grub bootsector at the end of the installation. What I do is grub-install --no-bootsector /dev/null . I need that because I do a multiboot with grub chainloading on LVM
<mirak> I need "multiboot core.img" because you can't embed a bootloader in lvm partitions
<nacc> rbasak: just checking in on a git sync
<rbasak> nacc: I'm almost ready with the empty directory workaround. But have the certbot meeting in 25 minutes.
<nacc> rbasak: ack, are you EOD after that?
<rbasak> nacc: nominally, but I should be able to find some time to chat this evening. Just not exactly sure when. Is short notice OK?
<nacc> rbasak: yep
<rbalint> why don't we have greasemonkey anymore in Ubuntu?
<rbalint> the version in sid works nicely
<nacc> rbalint: my guess, it was deleted manaully and maybe it's blacklisted from the sync?
<nacc> https://launchpad.net/ubuntu/+source/greasemonkey/+publishinghistory
<nacc> deleted by pitti on 1/13/2011
<nacc> unsupportable Mozilla extension, see https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/extension-list
<jbicha> https://people.canonical.com/~ubuntu-archive/sync-blacklist.txt
<infinity> rbalint: Yeah, we don't ship any firefox extensions because they're next to impossible to maintain with the constant security updates.
<infinity> (If you see any we do ship, that's a bug, and they should be removed and blacklisted :P)
<jbicha> infinity: on the other hand, we probably do actually ship several Firefox extensions now because I don't think that list has been maintained?
<infinity> jbicha: See above. :)
<jbicha> personally, I'll just wait for Firefox 57 to break a bunch of them :|
<infinity> Yeah, we have some.
<Unit193> infinity: Block xul-ext-ubufox!
<chrisccoulson> feel free
<jbicha> chrisccoulson: what are the important features of ubufox?
<nacc> jbicha: thanks for that link
<infinity> jbicha: Pretty much outlined in the package description, I'd say.
<rbalint> infinity: it seems i have to download them to sid then
<infinity> rbalint: Or install extensions via the extention interface in firefox.  *shrug*
<infinity> That seems more sensible to me than installing them system-wide anyway.
<mdeslaur> doko: I'm stealing your bash merge
<doko> mdeslaur: just that? ;-/
<mdeslaur> doko: nice try :)
<rbalint> infinity: i prefer packaged versions because i trust them more and i can also list them in my puppet config for desktop
<infinity> rbalint: Trust level is debatable, but as for puppet configs, I'd expect your entire ~ to be in a VCS anyway, if you're that sort of person, so extensions would follow you around. :)
<nacc> rbasak: fyi, i just did a merge (php7.1) with the namespace branch and it all worked ... i think we do want a pushurl by default, though, as it's annoying to have to type it out (presuming permissinos, it is nice to be able to do `git push ubuntu-origin <upload tag>`
<rbasak> nacc: \o/
<rbasak> nacc: I'm just getting dinner. HO in 20-30 minutes?
<nacc> rbasak: sounds good
<rbasak> nacc: ready when you are
<nacc> rbasak: ack, want to just use the team HO?
<rbasak> Sure. I'll be there in a minute.
<rbasak> nacc: I'm there. Are you there? :)
<nacc> rbasak: yeah it's just taking a while to join :)
#ubuntu-devel 2017-05-18
<nacc> mdeslaur: re: LP: #1677958, the reporter indicates it's a security problem in 16.04 (possibly also 16.10, 17.04, not sure yet) -- it's in universe, though, so I'm not sure what I should do with the bug?
<ubottu> Launchpad bug 1677958 in nghttp2 (Ubuntu) "no SSL certificate verify " [Undecided,New] https://launchpad.net/bugs/1677958
<mdeslaur> nacc: it's in an example program, -EDONTCARE
<nacc> mdeslaur: oh there was another one :)
<nacc> mdeslaur: that is actually in the lib
 * mdeslaur looks
<nacc> mdeslaur: c#5 and on
<mdeslaur> nacc: hopefully we only want the actual library package in main, and not the packages that contain the server and client and other unneeded stuff
<nacc> mdeslaur: right, we only want ht elib in main, and in artful it's fixed. I meant what to do about the xenial universe security issue :)
<nacc> mdeslaur: less relevant to the MIR, sorry, should have given better context, just wondered what the general policy is
<mdeslaur> since it's in universe, it's community-supported. Mark it as confirmed, and that's pretty much it.
<nacc> mdeslaur: ok, thanks
<coreycb> bdmurray: i had a late upload of designate for bug 1688557 if you wouldn't mind taking a peek
<ubottu> bug 1688557 in designate (Ubuntu Yakkety) "[SRU] newton stable releases" [Undecided,New] https://launchpad.net/bugs/1688557
<bdmurray> coreycb: looking
<coreycb> bdmurray: thanks
<xnox> juliank, new apt is finally in artful \o/ there was too many k* things testing the $world
<juliank> xnox: ack. and the SRUs for that should come tomorrow then
<juliank> Oh, ndiswrapper needs an update for 4.11
<juliank> Gotta figure out why  âstruct net_deviceâ has no member named âlast_rxâ - and what to do about it. That's always fun
#ubuntu-devel 2017-05-19
<Unit193> mwhudson: You may be interested in 'parsedatetime' from experimental, adds python3 package.
<juliank> xnox: Lots of apts uploaded.
<Laney> apt apty apt apt
<juliank> The .changes is getting a bit unreadable now, as it contains quite a few versions since {xenial,yakkety,zesty}-updates (we had about 3 fixup releases or so that were never part of the Ubuntu archive, but were released in the APT PPA)
<juliank> But well, it should work now :)
<juliank> Let's just say we probably should have slowed down the rates of SRU builds.
<juliank> Oh, we fixed it.
<juliank> Next day: Oh no, something was broken.
<psusi> cjwatson: I can't seem to find the postinst or udeb that populates /etc/default/grub... do you know where that's done?
<cjwatson> psusi: ucf from grub-<platform>.postinst
<infinity> A bit of optional mangling in grub-installer too.
<cjwatson> at some point the latter should probably drop a file into /etc/default/grub.d/ instead
<infinity> That's where quiet and splash are written.
<cjwatson> that directory didn't exist when it was first implemented
<infinity> cjwatson: How does .d work for CMDLINE stuff?  Is it additive or an override?
<infinity> Might not be entirely appropriate for the quiet/splash stuff if it's a hard override.
<infinity> Oh, except that on a default install, those are the only bits in CMDLINE, so maybe that works.
<cjwatson> sourced shell fragments so can mangle however it likes ...
<infinity> Ahh, so could be CMDLINE="CMDLINE $splash"
<infinity> And one snipper for splash, one for extra kopts passed from d-i, etc.
<cjwatson> (in principle; might confuse various configurator-like tools ...)
<infinity> snippet, too.
<psusi> thanks... I'm looking into a bug where the tty7 option sounds like it is being set in the console only installs and it shouldn't be
<cjwatson> that's probably more about the stuff in grub-installer (perhaps the one that copies options from d-i if they're provided after ---)
<psusi> that is what I thought of first but I'm not seeing it in there
<cjwatson> search for user-params
<psusi> only one line: user_params=$(user-params) || true
<psusi> hrm.. where's that sucker come from?
<infinity> psusi: You mean the vt_handoff stuff?
<psusi> infinity: yea
<infinity> That's hardcoded in grub configs, but doesn't take effect if splash isn't on the commandline, which server preseeds out.
<infinity> IIRC.
<cjwatson> user-params is in debian-installer-utils
<infinity> if [ "$vt_handoff" = 1 ]; then
<infinity>   for word in $GRUB_CMDLINE_LINUX_DEFAULT; do
<infinity>     if [ "$word" = splash ]; then
<infinity>       GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT \$vt_handoff"
<infinity>     fi
<infinity>   done
<infinity> fi
<infinity> Yeah, no splash, no handoff.
<xnox> infinity, cjwatson, apw - can we please drop all the vthandoff stuff and boot to vt1 by default everywhere?
 * cjwatson recuses self
<apw> xnox, and lose all that prettiness for approx 1s of the boot, how would we cope
<xnox> apw, the point is that our prettiness will be pitch perfect.
<xnox> apw, you did notice that windows 10 boots with black background and a white spinny graphic at the bottom to achieve flickerless boot.
<xnox> apw, and i thought booting to vt1 (and having graphical login on vt1) will make the whole vthandoff easier to do flickerless
<jbicha> xnox: gdm3 in Debian & Ubuntu already has login on vt1; robert_ancell was considering maybe doing that for lightdm
<jbicha> most distros now use vt1 for gdm, so I think the question is whether it's more important to match other distros (with their good reasons) or preserve tradition
<rbasak> I don't think Ubuntu is the appropriate distribution for a user who would care that X is now on vt1, unless there's an actual use case that it breaks.
<apw> it seems unlikely anyone would care where we put it
<apw> and being the same as everyone else is always nice in the sense of sharing the fixes
<psusi> infinity: so the default is to add splash, but the server cd uses a preseed to prevent the default from kicking in, and the preseed omits splash?  It sounds like maybe the default should be no splash, and maybe ubuntu-desktop being installed should trigger splash....
<infinity> psusi: Quite possibly, yes.
<psusi> I can't remember the reason for the vt.handoff in the first place... does vt1 want to run at a different resolution, so we use vt7 to keep it at the same resolution that grub was in?
<infinity> psusi: Or, as xnox points out, maybe we want to rethink this whole mess.
<psusi> if so, why don't we just have vt1 use that same resolution?
<infinity> It was all some misguided attempt to create a flicker-free boot.
<infinity> Some of us are more fond of the solution than others. :P
<psusi> yea, but I can't recall the cause of the flicker
<infinity> I don't recall the specifics either.  Colin or Andy might.
<infinity> But it's worth revisiting regardless.
<psusi> as long as vt1 is a graphical console instead of VGA mode, and uses the right resolution, there should be no flicker
<xnox> we patched grub/kernel/plymouth/lightdm to not clear the screen and paint things in to the same hue of aubergine and never switch vts such that plymouth&desktop run on vt7 with handoff
<psusi> right... but why did switching from vt1 to vt7 after X loaded make a flicker?  is vt1 in a different mode?
<xnox> all of that is semi-custom patched. the rest of the people decided to simply default to vt1 without any patches to achieve the same result
<xnox> psusi, vt switches cause flicker, yes.
<psusi> only if the two vts are different modes no?
<xnox> because graphics drivers
<xnox> psusi, that i do not know. but there was flicker / clearing of the screen, visibly. There are videos of that happening on various laptops.
<infinity> I suspect any non-kms driver will flicker on vt switch.
<psusi> heh, just leaving it on vt1 does seem a lot simpler ;)
<infinity> But non-kms drivers will probably "flicker" when X comes up too, even without a vt switch.
<infinity> But yeah, I entirely forget the specifics.
<infinity> I think revisiting the vt switch is a sane plan.  And if we decide it's still awesome, then maybe swapping the defaults so, as you say, only graphical installs get splash, instead of the server ISO being "special" would be reasonable.
<psusi> yea, apparently the netinstall isn't "special" so it gets splash with a non X install
<infinity> Though, in an ideal world, "splash" would work reasonably on servers too, but that would requite killing the handoff stuff, I think.  Currently, it goes a bit wonky.
<xnox> infinity, ooooh i also recall that we did do splash by default on server too / intentially / and then server complained and we reverted to non-splash on server
<xnox> imho systemd boot log is pretty enough for non-quiet boot on server by default even.
<xnox> the plan was to splash everywhere all the time.
<xnox> in 11.10 or something
<xnox> pre 12.04
<doko> nacc, rbasak: @PyCon, certbot talk. there was a "thanks to the maintainers" on his last slide, including you
<slangasek> pitti: I see you accepted the previous SRU of borgbackup (LP: #1615380), there's another one with the same rationale; do you mind expanding on why you're confident in the upstream testsuite here?
<ubottu> Launchpad bug 1615380 in borgbackup (Ubuntu Yakkety) "[SRU] security issues on borgbackup" [Undecided,Fix released] https://launchpad.net/bugs/1615380
<nacc> doko: nice :)
<nacc> doko: they've done most of the heavy lifting, I'd say :)
<doko> nacc: they didn't yet consider snapping the app ...
<nacc> doko: yep, that's probably the next reasonable step at this point
<doko> ohh, and it's packaged using python 2.7 ...
#ubuntu-devel 2017-05-20
<rbasak> doko: nice to know. Thanks!
#ubuntu-devel 2017-05-21
<juliank> slangasek: I'm not pitti, but I can say that the coverage of the diff from 1.0.7 to 1.0.10 is 76%, with the average code coverage improving to 83.88% - https://codecov.io/gh/borgbackup/borg/compare/f32c885...e5f712129685e02a6755fa53f1546a66e842b215/diff - that would make me fairly confident.
<juliank> That link really should have been in the SRU bug IMO
<juliank> There's one part that is not well tested, which is the newly adding importing of paperkeys. If that's broken, that would not cause a regression, though.
<erle-> Why is âunattended-upgradesâ updated so often recently?
<erle-> And why is it called upgrades rather than updates in the first place?
<JanC> erle-: did you read the changelog?
<rbasak> erle-: probably because "update" and "upgrade" have specific meanings in the context of apt.
<slangasek> juliank: well, I don't think unit test code coverage ever tells the whole story, but that's useful info, thanks
#ubuntu-devel 2018-05-14
<robert_ancell> bdmurray, the gnome-initial-setup SRU failed one of the components due to a change not being included (bug 1768557). Is it OK for the SRU to complete anyway? Any other paperwork required for that?
<ubottu> bug 1768557 in gnome-initial-setup (Ubuntu Bionic) "Update what's new graphic for Welcome to Ubuntu wizard" [Low,Fix committed] https://launchpad.net/bugs/1768557
* louis_ changed the topic of #ubuntu-devel to: /!\ THIS CHANNEL HAS MOVED TO #krustykrab /!\
* Unit193 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
<cpaelzer> doko: the retrigger you did for http://autopkgtest.ubuntu.com/packages/pglogical/cosmic/i386 was that with special triggers?
<cpaelzer> or just a retry?
<cpaelzer> ahasenack: ^^
<cpaelzer> The test result history on these also doesn't look good in general ... hmm
<joelkraehemann_> hi all
<joelkraehemann_> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1770324
<ubottu> Launchpad bug 1770324 in gsequencer (Ubuntu) "Sync gsequencer 1.4.29-1 (universe) from Debian unstable (main)" [Undecided,Incomplete]
<joelkraehemann_> ^^ I am unsure why it is in state incomplete
<joelkraehemann_> How can I change this?
<cjwatson> juliank: ^-
<joelkraehemann_> juliank: ping
<juliank> joelkraehemann_: one sec
<juliank> joelkraehemann_: synced
<joelkraehemann_> thank you
<juliank> joelkraehemann_: seems I missed your response, I think I forgot to subscribe myself to the bug, sorry
<joelkraehemann_> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1769958
<ubottu> Launchpad bug 1769958 in gsequencer (Ubuntu) "broken clipboard" [Undecided,New]
<joelkraehemann_> ^^ you can close it
<joelkraehemann_> since it is about the same
<juliank> ugh, I forgot to add parameters to syncpackage to mark it as sponsored and close the bug, sorry
<juliank> joelkraehemann_: We actually should wait until it migrated out of proposed
<juliank> but we can still revert it later if it does not leave proposed
 * juliank gets some tea before doing any more uploads or syncs
<femme> https://efail.de/
<joelkraehemann_> juliank: I actually did sync request for bionic, does it require any additional action?
<juliank> joelkraehemann_: For bionic, we'd have to release a stable release update following the procedure in https://wiki.ubuntu.com/StableReleaseUpdates
<xnox> too late to sync things into bionic..... one can fakesync with right version numbers; or can sync some -security -stable updates, but it is rare that the versions match up right.
<joelkraehemann_> yeah, I was providing a patch
<juliank> joelkraehemann_: I added a bionic task to that bug now
<juliank> I'm not sure if it makes sense to just SRU that patch or just SRU the cosmic upload as ~18.04.1
<juliank> the diff from 1.4.24 to 1.4.29 looks tiny
<tarzeau> is there a chance popcon.ubuntu.com will get fixed?
<walbon> hey folks, is there any package or module(or magic) to read the changelog from a .deb file directly?
<wxl> you could script the process of unarchiving it, then unaraching the control archive
<Odd_Bloke> walbon: debs are ar files containing tar files: https://en.wikipedia.org/wiki/Deb_(file_format)#Design
<walbon> wxl: yeah, that's I have done like this : https://github.com/walbon/ubuntu-devtools/blob/walbon/dpkg-changelog
<walbon> well, I just looking for a official way in less steps
<walbon> odd_Bloke: interesting and complete that post, thx, but I have look for a straightway command.
<wxl> walbon: `ar x /path/to/deb control.tar.gz` will get you the control archive and `tar -xO -f control.tar.gz -T <(echo changelog)` will get you the changelog, but unfortunately piping from one to the other (with p instead of x in `ar`) doesn't seem to behave well.
<Faux> bsdtar behaves a lot better than ar in many cases; not sure if this is one of them.
<wxl> good call Faux
<wxl> walbon: bsdtar -xOf /path/to/deb -T <(echo control.tar.gz) | bsdtar -xOf - -T <(echo changelog)
<wxl> no temporary anything required (except for subshells............)
<wxl> i would have done tar|tar but it seems like only bsdtar can handle ar
<walbon> wxl: bsdtar ? I found it and I'm installing it here to test. thx
<wxl> walbon: as in not gnutar :)
<Faux> As in "oh god you let libarchive do WHAT?".
<wxl> XD
<Faux> I wrote an even more crazy bsdtar in RUST which supports e.g. recursing into ext4 filesystem images. I should finish that up sometime.
<wxl> actually to be fair, gnutar can handle it. you just need to give it a J
<wxl> ap p /path/to/deb control.tar.xz | tar -xJOf - -T <(echo changelog)
<wxl> s/ap/ar/
<roaksoax> win 8
#ubuntu-devel 2018-05-15
<cjwatson> I see walbon's left, but just in case they're reading logs, "apt-listchanges --all foo.deb" is probably the single straightforward command they were looking for
<tsimonq2> What does the SRU Team think about bug 1770678?
<ubottu> bug 1770678 in simbody (Ubuntu) "[SRU] Simbody package ships erroneous paths for blas/lapack in the cmake module" [Undecided,New] https://launchpad.net/bugs/1770678
<tsimonq2> It's the Debian maintainer asking for a no-change rebuild of their package in Artful.
<ipatrol> Guess https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1117481 can be closed up with perhaps a little QA
<ubottu> Launchpad bug 1117481 in ImageMagick "Imagemagick lacks support for webp" [Undecided,New]
<ginggs> tseliot: hi, will you SRU the /dev/nvidia-uvm-tools fix for bionic as well please?
<tseliot> ginggs: yes, I uploaded in cosmic today, and I hope to SRU that soon
<ginggs> tseliot: thanks
<ahasenack> jbicha: hi, good morning/afternoon, #1737053 came to my attention as I'm preparing a new apache upload for cosmic
<ahasenack> jbicha: looks like brotli is still in universe
<ahasenack> should I just upload the new apache which can depend on it, and then libbrotli1 will be pulled into main? Or should some action be taken before by an AA about it?
<ahasenack> I don't see it in excuses, even though cosmic-proposed has one upload from may 4th
<ahasenack> ah, that upload is the one that failed the armhf build
<jbicha> go ahead and upload, it will be noticed for promotion to main once something in main pulls it in
<ahasenack> rbasak: hi, could you please import brotli? It's in universe now, but will be promoted to main
<rbasak> ack
<ahasenack> rbasak: th
<ahasenack> thx
<rbasak> Importing
<rbasak> ahasenack: the import was successful
<ahasenack> rbasak: thanks
<teward> anyone know how to fix mk-sbuild in Xenial to get a Cosmic schroot?  It's failing to create the schroot with 'Package pkg-create-dbgsym has no installation candidate" in mk-sbuild.  (I'm not yet able to upgrade to Bionic at this time)
<mdeslaur> teward: ignore the warning
<mdeslaur> teward: I got that on bionic creating bionic schroots too but it seems to work fine
<teward> mdeslaur: well I ask because it hard-failed
<mdeslaur> oh, hrm
<teward> mdeslaur: 'twas not a warning, was a hard-fail "error"
<teward> i've got a Bionic system at home, I can test there to see if this is a Xenial-specific mk-sbuild issue, and if it is then I'll probably open bugs, but until then I can't test it (because "work")
<mdeslaur> I got a hard fail too, IIRC, and the schroot still works
<mdeslaur> have you tried the resulting chroot?
<teward> waiting for the other schroots to finish updating (I have a "fire and forget" script that fires off all the updates for supported release chroots)
<teward> i've only got so much computing power on this here system :p
<doko> ginggs: mrbayes and esys-particle autopkg tests are still running, but any other openmpi autopkg test failures are real
<teward> mdeslaur: huh, working now.  I worry that something that's supposed to be in the chroot isn't because installation exploded at one step.
<ginggs> doko: ok, will have a look - not sure what can be done about all the armhf FTBFS
<femme> Have differential privacy/data anonymization been evaluated for the ubuntu telemetry? for example this could be used http://arx.deidentifier.org/
<Odd_Bloke> debootstrap in bionic doesn't know about cosmic yet; how can I work around that?
<Odd_Bloke> (To mk-sbuild, for clarity.)
<cjwatson> sudo ln -s gutsy /usr/share/debootstrap/scripts/cosmic
<Odd_Bloke> Hmm, that should have been more obvious to me.
<Odd_Bloke> Thanks!
<wxl> i had the same question, actually. are you suggesting, cjwatson, to just build as "gutsy" after the symlink?
<teward> wxl: i did that
<teward> and have for bionic, etc.
<teward> it's basically what i've had to do while not on the latest release(s)
<wxl> huh, ok
 * wxl buys more band-aids :/
<Odd_Bloke> wxl: The debootstrap hasn't changed since gutsy, so it's just reused via symlink.
<wxl> Odd_Bloke: well i guess it DOES make sense then :)
<rbasak> doko: does bug 1770748 have to go directly to the TB? Why not the ubuntu-devel@ ML first?
<ubottu> bug 1770748 in ilmbase (Debian) "ilmbase symbols files were dropped by the forced merge" [Unknown,Confirmed] https://launchpad.net/bugs/1770748
<rbasak> I'm talking about should-we-maintain-C++-symbols-files in this case question.
<rbasak> (because I have an opinion on that technical point, and I'd like to hear the opinions of others)
<doko> rbasak: sure, we can have the technical discussion there, not sure about the procedures
<jbicha> I personally think that this escalated way too quickly
<wxl> jbicha: re: i386?
<jbicha> no, me being referred to the TB about the ilmbase issue
<wxl> ah. can't really comment there.
<jbicha> I assume the referral wasn't meant to be personal but that doesn't help relieve the stress much
<wxl> yeah it doesn't read as personal to me
<teward> mdeslaur: just an FYI, I didn't run into that issue with pkg-create-dbgsym during chroot development when building the Cosmic chroot in a Bionic environment.  Guess something with Xenial's sbuild/schroot doesn't like Cosmic?
#ubuntu-devel 2018-05-16
<wxl> arges, rbasak: anything we can do to get this SRU moving? not being able to use apport is Not Goodâ¢ https://bugs.launchpad.net/ubuntu/+source/lubuntu-meta/+bug/1764399
<ubottu> Launchpad bug 1764399 in lubuntu-meta (Ubuntu Cosmic) "running apport in terminal doesn't work, as python3-launchpadlib is not installed by default in Lubuntu Bionic" [Critical,Fix committed]
<wxl> (btw i'm assuming the vanguard roles go by utc date, as it's currently wednesday by said time)
<RAOF> What would we need to do to make debugging on Ubuntu as nice as it in in Fedora?
<rbasak> wxl: looks like it's been accepted since your message. Do you need anything else?
<rbasak> RAOF: maybe start by stating how exactly Ubuntu is deficient?
<RAOF> rbasak: Oh, huh. My second line didn't come through.
<RAOF> rbasak: Specifically - on Fedora, when you start gdb it'll give you the `dnf debug-install` line to get the debugging info for all the relevant libraries.
<RAOF> rbasak: And then once you've got them installed, you get source listings in gdb for everything.
<rbasak> That sounds handy
<rbasak> I guess that just needs implementing for Ubuntu?
<rbasak> I can't imagine that the underlying mechanism is particularly exclusive to one distribution
<femme> RAOF: I filed an apport bug for that
<femme> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1747644
<ubottu> Launchpad bug 1747644 in apport (Ubuntu) "apport-retrace package should automatically add the debugsymbol repository" [Low,Confirmed]
<joelkraehemann> hi all
<joelkraehemann> https://wiki.ubuntu.com/StableReleaseUpdates
<joelkraehemann> ^^ just read it, microreleases are fine
<joelkraehemann> julian: ping
<cpaelzer> hey fellow packagers, I want to remove a binary from a src, but it has a special twist this time
<cpaelzer> normally I'd breaks/replaces from the main package that now takes over the functionality
<cpaelzer> the special part this time is that it is not exactly taken over - so it might be discussion worthy if "replaces" would be correct (it would get it uninstalled thou which is what we want)
<cpaelzer> now the more special and why I ask
<cpaelzer> I'd want the postrm of the old package that is removed NOT to be executed
<cpaelzer> it had modified config files and would restore them back, I'd prefer if there would be a way to eliminate it without that
<cpaelzer> I currently lean towards trying a transitional package that will replace it
<cpaelzer> but if there is a known best approach to the scenario described above let me know
<cpaelzer> TL;DR: src:A want to get rid of binary A-1, but NOT have postrm of A-1 be processed
<ahasenack> tricky
<cpaelzer> If there is no best-known-approach I'm fine to find out - I just want to avoid puzzling just to be told "nah usually done that way" :-)
<cjwatson> I believe that this is a situation where there is no good answer.  I have once in the past resorted to manually removing the postrm from my package's preinst, but obviously you have to be extremely careful about that sort of nonsense ...
<cjwatson> (And in fact I think that may have been an older version of the same package, rather than a different package that I was replacing)
<cpaelzer> cjwatson: thanks for the example
<cpaelzer> I'll for now go and test a few variants that come to my mind
<cpaelzer> worst case I'm back here even more confused in a bit :-)
<tsimonq2> rbasak, nacc: How is the Git importer working out for packages?
<tsimonq2> Lubuntu wants to try importing our packages if that's OK.
<tsimonq2> Our packageset might not be up to date (?) but it would fit super well into our workflow.
<rbasak> tsimonq2: we can probably whitelist your packages so they all get imported, no problem. But can you explain your use case? The importer might not necessarily fit your workflow. What do you do at the moment?
<nacc> rbasak: it's a todo i have to work with the lubuntu devs to explain what the importer does :)
<nacc> tsimonq2: would now work?
<tsimonq2> rbasak: At the moment, we use Phab.Lubuntu.me to do task tracking internally at Lubuntu, and we have Git repositories for some core packages mirrored there so we can reference them in tasks.
<tsimonq2> Right now, when we work on packaging changes that are more than a simple patch, I usually use something like gbp to import the repo and then mirror it on Phab. The goal here would be to have everything mirrored there and have team members (mainly wxl, more in the future) have the ability to submit patches to packages there, where I (or another person with upload access) would review and merge.
<tsimonq2> I can handle things on my side as long as it's imported on LP.
<tsimonq2> One question I do have is this; can I make commits in the actual Git repo then just tag when I want to upload? How is the actual workflow if I just wanted to use it as a Git remote?
<tsimonq2> Because something would be better than nothing right now.
<nacc> tsimonq2: the imported repositories are basically read-only, by and large.
<nacc> tsimonq2: you *can* provide rich history corresponding to uploads
<nacc> tsimonq2: right now, that's only possible with what we call 'upload tags', which are only create-able by folks in ~usd-import-team
<tsimonq2> OK.
<tsimonq2> Read-only is fine for now, I think.
<nacc> we eventually want to be able to get to a point where you can just approve an MP against a branch in the imported repository. Then if you dput the same source-ful contents (Git Tree) as the approved MP, the importer will see that and internally create an upload tag and integrate the MP as rich history (which would also make it "Merged")
<nacc> then the only ACL we have to have is who can approve MPs, wich would be tied back to who can upload to the source package in question
<tsimonq2> Right.
<tsimonq2> So how far away is that?
<nacc> https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+ref/importer-abstract-out-upload-tags
<nacc> it probably needs some further massage, because it was the last thing I did
<tsimonq2> OK.
<nacc> but in theory, we're not actually that far away -- we do need some LP work, to get the ACL part in place correctly (afaict, the logic all present in the data model we just need to give a name to the 'upload-capable' alias)
<nacc> obviously it's really down to rbasak right now, though :)
<tsimonq2> OK; so for now, could a read-only import please be done of all of the packages we explicitly seed that are in Universe? (And additionally, all direct dependencies of the lxqt and lxqt-core binaries)
<nacc> tsimonq2: that's something rbasak has to agree to (I technically can do the one-off imports, but the keepup tool is running inside Canonical)
<rbasak> I agree to do it. But I would like to discuss more to make sure that I think it'll be benefitial rather than problematic. If, after we've discussed, you still think you want it, I wouldn't obstruct that.
<rbasak> tsimonq2: where does your packaging start? Debian? Or do you maintain the origin packaging yourselves?
<rbasak> tsimonq2: could you perhaps show me an example that's typical for you?
<tsimonq2> rbasak: So for core packages, I would point you at lp:lubuntu-artwork or lp:lubuntu-deefault-settings.
<tsimonq2> *lubuntu-default-settings
<rbasak> tsimonq2: OK. Are those maintained in a VCS somewhere?
<nacc> rbasak: good point
<tsimonq2> rbasak: Yes.
<tsimonq2> (thus the "lp:")
<rbasak> Sorry otp. Back later.
<rbasak> tsimonq2: sorry, I'm running out of time today. Can we chat more tomorrow?
<tsimonq2> rbasak: Sure.
<nacc> I should be able to follow along as well
<wxl> rbasak: nope, thanks. :)
<wxl> @VikingRedwolf who else?
<udevbot> Error: "VikingRedwolf" is not a valid command.
<wxl> oops wrong channel
#ubuntu-devel 2018-05-17
<odyssey4me> cjwatson I've been referred to you by jamespage for this and hope you can help. We're still seeing 'Hash Sum mismatch' errors for apt update executions. According to http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-errors.html this should be a thing of the past from Xenial onwards, but we're still seeing it. I'm trying to figure out how to verify whether this is actually being used or not.
<odyssey4me> If I do 'apt-get -oDebug::Acquire::http=true update' then it shows the InRelease download happening from the standard ubuntu sources, but out failures are from those sources - for example: E: Failed to fetch http://mirror.rackspace.com/ubuntu/dists/xenial-updates/universe/binary-amd64/Packages.gz  Hash Sum mismatch
<jamespage> odyssey4me: I wonder whether you have to use a specific mirror configuration to pickup the extra bits
<Faux> Yeah, I don't think you should be hitting packages.gz if you are by-hash.
<odyssey4me> that's what's confusing me - unfortunately docs on all this are very sparese
<odyssey4me> *sparse
<odyssey4me> according to http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-errors.html I should see the InRelease file fetched, then the by-hash ... and I'm not seeing that
<odyssey4me> so I'm wondering if there's some sort of apt or whatever config that needs to be in place to activate this, or if using it can be forced somehow
<Faux> By-Hash Try to download indexes via an URI constructed from a hashsum of the expected file rather than downloaded via a well-known stable filename. True by default, but automatically disabled if the source indicates no support for it. Usage can be forced with the special value "for
<Faux> man 5 apt.conf
<Faux> man:apt.conf(5)
<cjwatson> odyssey4me: can you pastebin a full debug dump?
<cjwatson> the debug option you quoted earlier should be enough to get started with
<cjwatson> you shouldn't need any special config, though perhaps there's something weird about the mirror you're using or about your existing config
<odyssey4me> cjwatson ok, posting info to https://gist.github.com/odyssey4me/549131501f752dfe957d1ec151d62914 - just did one with a mixed set of repo sources, which also goes through apt-cacher-ng... I'll post another one now with just a plain default set of sources
<odyssey4me> (and no apt-cacher-ng)
<cjwatson> while acng should work, I'd rather start with as few things in the mix as possible
<cjwatson> odyssey4me: so that info you've posted doesn't show a failure - I need one that does
<cjwatson> nor does it even show fetching any Packages file at all
<odyssey4me> oh, well, that's a problem - because it's not consistent
<cjwatson> right, but you should be able to get it eventually presumably
<cjwatson> there's no point in me spending time debugging the successful cases
<odyssey4me> we're seeing it in CI jobs, so by the time we see it the host it happened on is gone
<cjwatson> temporarily add -oDebug::Acquire::http=true to the CI job config?
<odyssey4me> is there some sort of config I can add to have apt log things, then we can collect those logs?
<cjwatson> you could drop in e.g. /etc/apt/apt.conf.d/99debug with Debug::Acquire::http "true";
<cjwatson> if that's easier than a command-line option
<odyssey4me> will that drop info into /var/log/apt ?
<cjwatson> no, stdout/stderr (I forget which) of apt
<odyssey4me> hmm, ok - that's worth a try - thanks for the advice
<odyssey4me> lemme give that a go, and I'll come back when I have something useful to peruse
<odyssey4me> thanks Faux cjwatson jamespage :)
<cjwatson> thanks.  it's worth capturing /etc/apt/sources.list too
<odyssey4me> the only fail I have on record right now is the output from an ansible task which I've just added to https://gist.github.com/odyssey4me/549131501f752dfe957d1ec151d62914 - not sure if that helps at all
<cjwatson> mm, not really enough detail unfortunately
<cjwatson> odyssey4me: oh, and if you're using apt-cacher-ng, make sure that you have the fix or workaround linked from my blog entry
<odyssey4me> I thought that was trusty only?
<odyssey4me> It looked to me like xenial's package got patched?
<cjwatson> if you're using xenial's acng then that should be OK, yes
<cjwatson> but this is the kind of symptom you can get from a bug there - i.e. acng serves a by-hash file that turns out to not actually match the requested hash, then apt falls back to the non-by-hash version, and finds that it's out of sync due to old-fashioned mirror update in progress or whatever
<cjwatson> the debug output should hopefully make this kind of thing clear
<cjwatson> the by-hash scheme is generally more robust against cache breakage, but acng is a special case because it's sufficiently clever about the archive structure that if misconfigured it can undo the robustness savings
<cjwatson> and I suppose it's also possible that the mirror.rackspace.com mirror sync script is incorrect and fails to put the new by-hash files in place before InRelease, which would also have a similar effect
<cjwatson> in that case the debug output should show a 404 for the by-hash file followed by 200 for plain old Packages
<odyssey4me> hmm, let me get hold of our mirror folks and see whether they've implemented the 2-step mechanism
<odyssey4me> thanks again - really appreciate your time
<cjwatson> they probably have two-stage sync (most decent mirrors do), but worth checking the details
<cjwatson> specifically whether InRelease is excluded from the first stage
<cjwatson> ubumirror is also unfortunately a bit wrong and we should reeeeally fix it
<cjwatson> (it needs to exclude only Packages* Sources* Release* InRelease from the first stage, not all of dists/
<cjwatson> )
<Nafallo> ohhai :-)
<Nafallo> cjwatson: we don't have a bug about that, right? (I create one otherwise)
<cjwatson> I don't think so
<Nafallo> bug 1771796
<ubottu> bug 1771796 in Ubuntu Mirror scripts "Fix the two-stage sync" [Medium,Triaged] https://launchpad.net/bugs/1771796
<joelkraehemann> hi all
<joelkraehemann> please consider for bionic because I don't feel like dealing with broken segmentation in files
<joelkraehemann> https://bugs.launchpad.net/ubuntu/+source/gsequencer/+bug/1770324
<ubottu> Launchpad bug 1770324 in gsequencer (Ubuntu) "Sync gsequencer 1.4.29-1 (universe) from Debian unstable (main)" [Undecided,Fix committed]
<_0kx__> hi
<_0kx__> is the bug known: 1.) i've entered the password in gdm3 in the first time wrong. after this, i've entered the password in the right way (second) and the login hangs up.
<_0kx__> ?
<_0kx__> thanks!
<_0kx__> the bug appears after the upgrade from 17.10 to 18.04!
<seb128> _0kx__, hey, yes, a fix has been commited this week and is being backported for a SRU
<seb128> it's in the SRU queue waiting for review in fact now
<seb128> https://launchpadlibrarian.net/370642960/gdm3_3.28.0-0ubuntu1.1_source.changes
<_0kx__> seb128: yeah, that's my bug. thanks a lot! there is hope.:-)
<seb128> _0kx__, yw!
<_0kx__> bye
<tsimonq2> rbasak: Morning! Will you be around in about three hours to continue our conversation from yesterday?
<rbasak> tsimonq2: yes. Ping me when you're ready.
<rbasak> nacc: ^ FYI
<tsimonq2> ACK
<Nafallo> hello. anyone willing to sponsor a package change for bionic for me? the package became unusable this morning. http://people.ubuntu.com/~nafallo/lastpass-cli/
<Nafallo> let me know if this is supposed to be in -motu :-)
<Nafallo> quite sure I need to follow some policy I don't know about yet :-)
<tsimonq2> Nafallo: Please file a bug, attach your diff, subscribe the sponsors team, and link it here.
<tarzeau> can this be fixed somehow for 18.04? https://bugs.launchpad.net/ubuntu/+source/protracker/+bug/1769693
<ubottu> Launchpad bug 1769693 in protracker (Ubuntu) "protracker does not run due to SDL2 library version" [Undecided,Confirmed]
<Nafallo> tsimonq2: cheers :-)
<Nafallo> I suppose I should do this against cosmic to begin with :-)
<rbasak> tarzeau: I commented on the bug
<tsimonq2> rbasak, Nafallo: Cheers
<Nafallo> I think bug 1555562 is ready for sponsorship now :-)
<ubottu> bug 1555562 in lastpass-cli (Ubuntu) "lastpass-cli changed bundled CA certificates" [Undecided,In progress] https://launchpad.net/bugs/1555562
<ddstreet> coreycb hey are ddebs getting built for uca pkgs yet, do you know?
<coreycb> ddstreet: i dont think so. jamespage, do you know?
<jamespage> ddstreet: nope
<jamespage> well they get built but I don't think we've figured out the sync process yet
<nacc> rbasak: ack
<ddstreet> jamespage they get build in the private ppa tho, not -staging right
<ddstreet> we need them in -staging so they're publicly available
<jamespage> ddstreet: we really need to sync them to the actual cloud archive
<jamespage> ddstreet: the packages get rebuilt in proposed so its not the same binary
<ddstreet> jamespage that's fine, but unless you plan to leave them all there forever for all versions, that's not good enough
<ddstreet> getting rebuilt is a problem, too
<jamespage> why
<jamespage> ?
<ddstreet> you may not have to support (debug) old versions, but some people do, like my team
<ddstreet> only making the latest ddebs available is nice for development, but not terribly useful for support/debugging
<jamespage> ddstreet: I'd be happy to commit to doing the same as we do in the ubuntu archive - whats the policy for ddeb retention there?
<ddstreet> jamespage 1-2 most recent versions, which is exactly why i said it's not enough
<ddstreet> however all pkgs have ddebs in LP, which is what we are asking you to do
<ddstreet> there's an existing bug for this, rather old, i'll find it
<jamespage> lp was a full record of all build artefacts?
<jamespage> ddstreet: yeah I know the one
<ddstreet> k
<ddstreet> no progress on it then?
<jamespage> no
<jamespage> its never quite managed to bubble to the top of the priorities list
<ddstreet> any plan for there to be progress on it? ;-)
<jamespage> ddstreet: do PPA builds keep full history as well?
<ddstreet> jamespage yes
<jamespage> so you can always grab the binaries from older versions - I did not know that
<ddstreet> yes
<ddstreet> see ppa:ddstreet/ubuntu-dev-tools which includes pull-lp-ddebs
<ddstreet> can get ddebs for any package in LP history as long as it was actually built with ddebs
<ddstreet> pull-lp-debs too, which is handy to reproduce issues on older versions (common requirement)
<ddstreet> anyway it really would be nice to finally have ddebs for uca pkgs, it's a bit of a pain to debug stuff without any dbgsyms, which is what we have to do currently
<tsimonq2> rbasak, nacc: Hi.
<tsimonq2> Let's continue.
<rbasak> o/
<rbasak> tsimonq2: you mentioned lubuntu-artwork and one other yesterday. How long is the complete list?
<rbasak> tsimonq2: and are there any on your list where the workflow (including VCS location, where it's derived from etc) is different from lubuntu-artwork?
<cjwatson> ddstreet,jamespage: PPA builds do get garbage-collected after a while once they've been superseded by later versions.
<tsimonq2> rbasak: Default settings and artwork  (as well as calamares-settings-ubuntu)we keep an up-to-date VCS to.
<tsimonq2> rbasak: The rest would be good to have for tracking.
<ddstreet> cjwatson that should be turned off for the UCA public ppa, then
<cjwatson> ddstreet,jamespage: you may like to look at lp:ddeb-retriever, which is very carefully constructed to use the correct LP APIs for keeping up with publication flow
<ddstreet> as i assume it is turned off for the ubuntu archives
<cjwatson> ddstreet: oh, maybe it is for that particular case
<rbasak> tsimonq2: how big is the rest?
<rbasak> tsimonq2: and what do you mean by tracking?
<cjwatson> ddstreet: Yeah, it is, assuming this is owned by ~ubuntu-cloud-archive
<cjwatson> we have a blacklist of stuff that never gets expired
<tsimonq2> rbasak: https://phab.lubuntu.me/diffusion/ is what we currently keep eyes on all the time.
<rbasak> "    No repositories found for this query."
<tsimonq2> Waat.
<wxl> rbasak: tsimonq2: i see them all here
<rbasak> Is a login required perhaps?
<ddstreet> cjwatson hopefully the UCA -staging ppa is on that blacklist
<wxl> shouldn't be but checking
<rbasak> BTW, I only have about 25 minutes.
<wxl> yep
<wxl> that's it
<tsimonq2> rbasak: Perhaps I need to play with permissions, but it's just settings, artwork, and the Calamares settings that we actively keep a rich history to, right now.
<rbasak> First I'm just trying to understand your workflows
<cjwatson> ddstreet: it's by owner, so if it's owned by ~ubuntu-cloud-archive then it is
<tsimonq2> I would like to be able to extend that to be able to do some rich commits in some LXQt packages. We have some git repos which just contain me branching from Debian and adding patches.
<rbasak> I hope it doesn't seem too much like an interrogation :)
<cjwatson> ddstreet: if it's not then you need to stop abbreviating :)
<rbasak> tsimonq2: so you'd be asking us to initially import those three packages for you? Just trying to understand scope.
<tsimonq2> rbasak: You're fine, but I'm determined to figure something out here. ;)
<ddstreet> yes, that's it, my fat fingers would surely misspell ~ubuntuy-cloud-archive ;-)
<tsimonq2> rbasak: Yeah, but ideally we could have everything we explicitly seed imported.
<wxl> man the policies suggest it should be viewable
<rbasak> Let's start with just considering this set of three
<tsimonq2> OK.
<wxl> nope
<wxl> actually it's per repository :/
<rbasak> What do you expect to happen to the LP project VCS repositories you have at the moment?
<wxl> fixing
<ddstreet> cjwatson yeah ddeb-retriever is interesting, but it just grabs all ddebs for all pkgs in lp, which is a bit less fine-grained than pull-lp-ddebs ;-)
<rbasak> Will they become a read only archive only, or will you still be pushing to them?
<wxl> oh actually i think i made it all visible now
<tsimonq2> rbasak: I still would like rich history, so pushing.
<cjwatson> ddstreet: sure, I meant it for the case where jamespage perhaps wants to publish them in the cloud archive
<wxl> no, that's just for new repos. ugh
<cjwatson> ddstreet: or something along those lines
<rbasak> tsimonq2: wouldn't you end up with two divergent repositories for each package then?
<ddstreet> ah right yep definitely, i assume that's the standard way to publish them
<rbasak> I see "rART Lubuntu Artwork" under https://phab.lubuntu.me/diffusion/ now - only one entry.
<tsimonq2> rbasak: It would be good for rich history to be there, but if someone just dputs, importing that would be good.
<wxl> keep refreshing
<wxl> more are coming
<ddstreet> cjwatson jamespage looks from the code like it might need to be modified tho, since it logs into LP anonymously while the ~ubuntu-cloud-archive source ppas are private
<ddstreet> anyway
<rbasak> tsimonq2: I still think you'll end up with divergence
<rbasak> You'll get two parallel repositories
<wxl> they're all there no
<wxl> w
<rbasak> wxl: I see them now thanks
<tsimonq2> rbasak: Is there a way to not have them diverge?
<cjwatson> ddstreet: sure, there would be plenty of details
<tsimonq2> rbasak: nacc said something along those lines yesterday.
<rbasak> tsimonq2: the easiest way would be for you to drop the other respository and use the git-ubuntu imported repository for everything only.
<rbasak> That repository would become your single source of truth, and you wouldn't push any commits except in that repository.
<tsimonq2> rbasak: Is that r/w or just r?
<rbasak> It's r/o.
<rbasak> If you need a holding area for changes yet to be uploaded, you could put that in a team repository branched from ubuntu/devel in the importer repository.
<rbasak> When you upload from the holding area, you could provide that to the importer as rich history.
<tsimonq2> How would that work?
<rbasak> Providing the importer with rich history is currently limited to ~usd-import-team, but the plan is to make it possible for any uploader to provide the rich history automatically.
<tsimonq2> Because that seems like what I'm looking for.
<tsimonq2> rbasak: Is that Canonical-only right now?
<rbasak> Let's see if I can summarise the importer's operation.
<nacc> tsimonq2: it's what i described yesterday (approved MPs, e.g)
<rbasak> The importer repository is read-only. We consider this essential as it is supposed to represent Launchpad's publication history as the single source of truth, and allowing anyone to push directly would break that.
<tsimonq2> Right.
<rbasak> So only the importer pushes to the "official" repositories and only in response to Launchpad publications of uploads.
<rbasak> However, if you make available rich history to the importer, it can choose to adopt that rich history as part of the "official record" of how it got to a commit that matches a Launchpad publication.
<rbasak> It will only adopt the rich history if the final commit of the rich history matches the published version exactly.
<nacc> (it might be helpful to point to a server team merge to see the result)
<tsimonq2> rbasak: So where does it look for that rich history?
<rbasak> Currently the rich history is provided by pushing a tag with the appropriate name to the official repository. Which is not ideal, because we want to keep the repository read-only for all other purposes, and Launchpad currently doesn't permit refspec-based ACLs.
<rbasak> In the long term, I think we'll be wrapping dput and supplying the importer with information on how to find the rich history corresponding to the upload in the changes file.
<rbasak> Then the rich history can be obtained by the importer from any Launchpad git repository branch such as the one from your MP.
<cjwatson> rbasak: That's scheduled for this cycle, FYI
<tsimonq2> Can I have rich history and tag it, but still manually dpput?
<tsimonq2> *dput
<rbasak> We have an intermediate plan for the importer to be able to grab rich history by looking for them amongst approved MPs.
<tsimonq2> Approved but not merged MPs, right?
<rbasak> Right now the process to ensure that rich history is adopted is to push the tag with the rich history first (someone in ~usd-import-team and we call it the "upload tag") before dput.
<rbasak> There is no wrapper currently.
<rbasak> tsimonq2: yeah something like that.
<cjwatson> (We haven't started it yet, but it's about halfway down my dept's "Infrastructure" roadmap list so it has a decent chance of finally getting done.)
<rbasak> cjwatson: thanks. You understand that our plan no longer requires refspec-based ACLs though right?
<rbasak> I mean it'd help right now, but long term we won't need them.
<cjwatson> I lose track, but you mentioned it, that's all :)
<tsimonq2> rbasak: Do you have an example of this in action? (Can you walk me through itt?)
<tsimonq2> *it
<cjwatson> (You're not the only people who've wanted it at various points)
<rbasak> tsimonq2: maybe follow https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/345498?
<rbasak> Actually that's not ready for upload.
<rbasak> I can of course show you an MP where it happened, but I'm not sure whether that'll be helpful as it'll be in the past and not in action.
<cpaelzer> sorry, I don't have the time this evening to make it ready rbasak
<tsimonq2> rbasak: OK.
 * tsimonq2 looks.
<rbasak> In that MP, cpaelzer is working on an upload for chrony.
<rbasak> When it's ready, he'll have a branch inside ~paezler with it ready.
<rbasak> Someone in ~usd-import-team will run "git ubuntu tag --upload" on it, and then push the tag to the official repo.
<rbasak> cpaelzer will then dput.
<tsimonq2> dput to Debian?
<rbasak> When the importer sees the upload published by Launchpad, it will look for the upload tag, find it, verify that the tree matches the upload and adopt it into the formal record.
<rbasak> dput to Ubuntu.
<rbasak> "Merge into: ubuntu/+source/chrony:debian/sid" is a hack.
<cpaelzer> but dput to Debian would work just the same
<rbasak> Really it won't be merged by anything.
<rbasak> The importer will create the commit based primarly on Launchpad's publication history.
<tsimonq2> rbasak: What's the logic behind the hack?
<rbasak> We use debian/sid so the preview diff looks sane.
<tsimonq2> Ohh, it's a merge from Debian?
<tsimonq2> That'd make sense.
<rbasak> It's a hack because usually MPs are intended to be merged by something like "git checkout target-branch && git merge proposed-branch".
<tsimonq2> Right.
<rbasak> Whereas our importer repositories reflect Launchpad's publications as the single source of truth.
<tsimonq2> Will this be the way it is long term?
<rbasak> So instead of doing a merge directly, we round trip through a Launchpad publication via dput
<rbasak> When the importer sees the upload, it creates the merge commit based on the publication and not the MP.
<tsimonq2> Right.
<rbasak> For as long as Launchpad's publication history forms the official record for Ubuntu uploads, this will be how it has to be.
<rbasak> One day very far in the future and not on any roadmap, Ubuntu may wish to switch to git repositories as the single source of truth, with uploads secondary to that. If and only if that happens, only then will MPs get merged directly.
<tsimonq2> OK.
<tsimonq2> So does Launchpad then have the tag from Debian on the Ubuntu tree as part of the merge, or at least a reference that this is a "merge" commit?
<tsimonq2> (Once merged.)
<nacc> tsimonq2: which way do you mean merge?
<nacc> tsimonq2: Git-merge or Ubuntu-merge ?
<rbasak> I need to go soon.
<rbasak> If nacc is around he can take over.
<nacc> rbasak: I can try and pick up a bit here
<rbasak> Thanks
<rbasak> My main concern is that you don't end up with two diverging repositories as I don't think that'll be useful for you workflow-wise.
<nacc> right
<rbasak> As I said, I'm quite happy to add your stuff to the whitelist if that's what you decide you want in the end.
<tsimonq2> I'd say, do it.
<tsimonq2> It would be good to try it out and play with it.
<nacc> tsimonq2: afaict, what you'd end up doing is having the ubuntu LP repo for your srcpkg as 'pkg' (the default with `git-ubuntu`) and then you'd have your personal (or team's, any LP user reference) as "<LP user name>". Your active development would be in the remote at <LP user name>
<nacc> you can do whatever  you want there, but you woudl eventually propose changes to the 'pkg' remote via a MP
<rbasak> tsimonq2: send us an MP against https://code.launchpad.net/~paelzer/ubuntu/+source/chrony/+git/chrony/+merge/345498 please
<nacc> rbasak: presumably not that? :)
<rbasak> Oh
<rbasak> Yeah. I meant: https://git.launchpad.net/usd-importer/tree/gitubuntu/source-package-whitelist.txt
<rbasak> We've got some CI brokenness going on at the moment.
<tsimonq2> Will do later this evening.
<tsimonq2> Thanks!
<rbasak> I can manually use a newer whitelist, but I'd prefer to get it landed properly before activating it, unless you're in a real hurry.
<rbasak> I'd estimate a week or so to do it properly.
<tsimonq2> Nah, let's do it properly.
<rbasak> But if you really want it sooner I can hack our importer instance up a bit.
<rbasak> OK, thanks.
 * rbasak EODs
<tsimonq2> o/
<nacc> powersj: is there a reason I can't get to https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/427/?
<tsimonq2> wxl: So we can stay on the same page... ^
<nacc> referred to from https://code.launchpad.net/~racb/usd-importer/+git/usd-importer/+merge/345670
<rbasak> It's broken for me too
<nacc> weird
<nacc> rbasak: ok
<powersj> nacc: we have had some jenkins issues and the latest update blew away our pipeline jobs :\
<nacc> powersj: urgh
<powersj> yeah...
<wxl> @tsimonq2: you referring me to your conversation with rbasak? if so, sounds good. let's see it when it's done. :)
<udevbot> Error: "tsimonq2:" is not a valid command.
<nacc> heh
<tsimonq2> wxl: Yep; OK. :)
 * tsimonq2 kicks the differently named udevbot.
<nacc> wxl: tsimonq2: if you have any other questions, though, i can answer them in the meanwhile
<wxl> i'm mainly going to let tsimonq2 run point on this and otherwise keep my hands out of the pot, but i'll find ya'll if things go south XD
<nacc> heh
<externalreality> I need more space for my VMs, So I scored a 970 Evo on amazon gift cards that have been building from birthday gifts and such
<nacc> externalreality: wrong channel?
<externalreality> nacc, ha, thx
<nacc> externalreality: np :)
<jbicha> bdmurray: could you review gnome-initial-setup for promotion to bionic? we're going to fix the failed (missing) bugfix in our next upload
<bdmurray> jbicha: looking
<bdmurray> jbicha: Could you explain what went wrong? How is it still the old ones?
<jbicha> I must have badly merged the branches. Our packaging workflow wasn't very good as we're just starting to switch our packaging to git
<jbicha> one complication was that it wasn't obvious to the person doing the previous uploads that we could actually do binary git patches to include the .png we needed
<bdmurray> jbicha: okay
<dmj_s76> ricotz: What's the difference between the ways nvidia's being packaged now?
<tdaitx> hi, I need someone from desktop to take a look at a LP: #1765914, it seems dconf is reporting a wrong scale-factor, but I have no idea of the cause
<ubottu> Launchpad bug 1765914 in openjdk-lts (Ubuntu) "Java windows and fonts are huge running in openjdk-11-jre" [Undecided,New] https://launchpad.net/bugs/1765914
#ubuntu-devel 2018-05-18
<tsimonq2> rbasak, nacc: Here you go: https://code.launchpad.net/~tsimonq2/usd-importer/+git/add-lubuntu/+merge/345799
<scientes> realtek wireless drivers suck
<scientes> i just patched the 8822bu driver to work with 4.15+
<tarzeau> when is popcon.ubuntu.com going to be fixed?
<TheMaster> Did someone file an issue with rt?  I've done that in the past to get it fixed.
<tarzeau> where's the rt? i'll file it
<tarzeau> TheMaster: past? being > 1 year?
<tarzeau> Wed Jun 22 15:09:05 2016 UTC last update
<tarzeau> 2 years almost
<tarzeau> RETARDED, there's bugs for it on launchpad.net
<TheMaster> Yeah I quit filing them after it kept on breaking, it was fixed every time I filed it.
<TheMaster> tarzeau: rt@ubuntu.com
<tarzeau> how many more bug reporting places do they want? they already also have bug reports in gnome-software appstore
<tarzeau> TheMaster: where can i look the bug up, after filing it?
<tarzeau> do you have your last mail that succeeded filing it? i'll just copy paste your's
<tarzeau> can you send it to alex@aiei.ch ?
<TheMaster> I do not have it, no.  I used the web interface to file.
<tarzeau> TheMaster: sent
<TheMaster> tarzeau: Looks like I filed it 5 years ago, also had gotten someone else to file one about 4 months later too.
<tarzeau> i filed it got an auto reply to see further discussion in another channeld
<tarzeau> #canonical-sysadmin
<tarzeau> but they say it's not their business
<TheMaster> I would put money on a stale lock file.
<tarzeau> it's another people, and they don't read rt@u-d
<seb128> tarzeau, hey, just curious but do you see value in those popcon result/want to use them? like would it be let down if the site was removed rather fixed?
<seb128> not saying that it's going to
<Laney> xnox: how does systemd decide if the system is 'running' do you know?
<tarzeau> seb128: absolutely, YES!
<tarzeau> I ABSOLUTELY ENJOY THE DATA YES
<tarzeau> but the major thing is, either inform people on the url, it's not there anymore AND REMOVE POPCON-deb package
<tarzeau> OR fix it
<seb128> yeah, agreed either it should be fixed or removed
<seb128> unsure it provides useful data though
<tarzeau> not have the url work with half assed outdated data. making the poeople go crazy reporting it to gnome-software center review, launchpad and rt@u-d
<seb128> it's strongly biased toward what is installed by default
<tarzeau> seb128: maybe not useful for you. but maybe check the webserver access logfiles? of the time when it was up to date
<seb128> "people" being you? ;)
<tarzeau> it'll have the answer
<TheMaster> That's true, but can still be useful nevertheless.
<tarzeau> there's this other guy:
<tarzeau> TheMaster: SAY SOMETHING!
<tarzeau> i don't know how much work it needs kept running, if it was way too complicated, i'd also just get rid of it - but i have no idea, i was only user of it
<TheMaster> It was mentioned in the other channel that it's only useful to show 'installed', but that entirely ignores the 'vote' data..
<tarzeau> i'm only interested in how many machines have it installed
<tarzeau> but then now that ubuntu 18.04 has snap, flatpak support, they should probably integrate/add that to popcon too:
<tarzeau> http://www.aiei.ch/linux/sw
<TheMaster> Eh, I couldn't really care about that info.
<tarzeau> i did write this littly thing for me to get an overview on cluster nodes and foreign-computers
<tarzeau> TheMaster: what info are you looking for?
<TheMaster> I'm only interested in things actually packaged.
<tarzeau> TheMaster: i want to know of specific deb packages i maintain how many users do i have in debian, how many in ubuntu (registered popcon users)
<tarzeau> TheMaster: anything you miss? or work on?
<Laney> xnox: oh right, I guess if some units are still activating
<tarzeau> TheMaster: ah about non-deb packages. likewise here
<tarzeau> TheMaster: so my sw script is to make sure there's no snap packages
<tarzeau> TheMaster: for the at my @work place
<TheMaster> tarzeau: Yeah, I maintain a few packages in Debian too, but not usually the only things I'm interested in.
<tarzeau> the biggest issue now is pip packages, and getting them updated (or not, if people link stuff against cython stuff) not packaged, but hand installed
<Laney> xnox: so on artful & bionic in lxd it seems like we timeout waiting for dev-getty, do you know why that might be?
<Laney> that makes the time to running be 90 seconds
<xnox> Laney, need a copy of your container i guess. or how do recreate it locally?
<xnox> Laney, we possibly have bugs in the config of the default container.
<Laney> xnox: just lxc launch images:ubuntu/bionic/amd64 should do it I think
<Laney> see if it is 'starting' or 'running' after 5 seconds or so
<xnox> Laney, ack. I can look into it. note this is not the image that foundations produces, but it is stgraber's edition.
<Laney> yeah
<xnox> # systemctl list-jobs
<xnox> JOB UNIT                                 TYPE  STATE
<xnox>   1 graphical.target                     start waiting
<xnox>  64 serial-getty@getty.service           start waiting
<xnox>   2 multi-user.target                    start waiting
<xnox>  58 getty.target                         start waiting
<xnox>  82 systemd-update-utmp-runlevel.service start waiting
<xnox>  66 dev-getty.device                     start running
<xnox> yeah, not sure why serial-getty@ is there.
<Laney> yeah, who put that there?
<xnox> Laney, # systemctl disable serial-getty@.service
<xnox> Laney, makes the reboot of said container faster. It is an odd thing:
<xnox> # systemctl enable serial-getty@.service
<xnox> Created symlink /etc/systemd/system/getty.target.wants/serial-getty@.service â /lib/systemd/system/serial-getty@.service.
<Laney> who's enabling it?
<xnox> given that no instance is specified, thus it's confusing as to what device it is picked to operate on. Imho that shouldn't execute at all.
<Laney> something in the image build I guess
<xnox> Laney, most likely overlay metadata of the container.
<xnox> Laney, let me try digging as to where the images are built. I've done that once before.
<Laney> https://jenkins.linuxcontainers.org/view/Images/job/image-ubuntu/architecture=amd64,release=bionic,restrict=lxc-priv,variant=default/
<xnox> Laney, i wonder if this is systemd regression. cause it looks like serial-getty@.service "choose" to use bar part of the foo-bar@.service as the instance name.
<xnox> when in fact instance name is empty....
<xnox> (normally foo-bar@instance.service)
<Laney> laney@nightingale> ls etc/systemd/system/getty.target.wants                                                                                                                                                           ~/Downloads/s
<Laney> 'getty@tty1.service'@
<Laney> hmm
<Laney> xnox: the ubuntu: images don't have this unit enabled
<Laney> just getty@tty1 but not serial-getty@
<xnox> Laney, hehe =) i hope you feel special now
<Laney> I do feel confused
<Laney> but that's not special, quite normal :'(
<xnox> Laney, i guess my email is faster than yours ;-)
<xnox> Laney, back to image - i've tracked down the image rootfs in /var/lib/lxd/images by hash from image list, mounted it.... and it doesn't have said thing enabled in the image
<xnox> it's magic as to where it comes from
<Laney> xnox: I only get emails every 5 minutes, and even then there's no notification thank you very much
 * Laney goes to see what you're talking about :-)
<Laney> and yes indeed, that rootfs I linked doesn't have it enabled in there
<xnox> Laney, i get push pop-up on the phone & chrome browser on the desktop =)
<Laney> I reckon some runtime thing
<Laney> eww
<Laney> my phone is also on silent and turned face down
<Laney> haha, thanks, what a nice email
<xnox> Laney, stgraber - 1) no idea where /etc/systemd/system/getty.target.wants/serial-getty@.service comes from 2) no idea why that runs at all, given no instance specified...
<Laney> xnox: it's actually serial-getty@getty that gets instantiated
<Laney> this seems weird
<xnox> Laney, yeah, that's also one more no-idea
<Laney> there's no DefaultInstance in there (or whatever it is)
<xnox> omg
<xnox> something is broken in systemd.
<xnox> Laney, so i created a service called 'foo-bar@.service' which does ExecStart=/bin/echo %i
<xnox> impossible to start it.
<xnox> Laney, made it "wanted by" getty.target, and I got this....
<xnox> # ls -latr /etc/systemd/system/getty.target.wants/foo-bar\@.service
<xnox> lrwxrwxrwx 1 root root 19 May 18 10:30 /etc/systemd/system/getty.target.wants/foo-bar@.service -> ../foo-bar@.service
<xnox> May 18 10:31:00 prepared-pony systemd[1]: Started foo-bar@getty.service.
<xnox> May 18 10:31:00 prepared-pony systemd[92]: foo-bar@getty.service: Executing: /bin/echo getty
<Laney> haha
<Laney> getty is a special case?
<Laney> (hmm, there's a systemd-getty-generator)
<xnox> yeah, i'm looking into getty-generator.c and it appears to be mangling stuff in add_symlink
<Laney> xnox: this is just what systemd does...
<Laney> May 18 11:45:26 nightingale systemd[3946]: Starting Why laney...
<Laney> May 18 11:45:26 nightingale echo[9380]: laney
<Laney> laney@.target.wants/laney@.service -> ../laney@.service; systemctl --user start laney.target
<Laney> you get @targetname apparently
<xnox> O_o
 * xnox is very puzzled.
<Laney> xnox: it's got to be that detect_container() <= 0 hasn't it?
<Laney> and add_serial_getty() get an empty string
<Laney> but we shouldn't get that far if detect_container works properly
<xnox> Laney, but container=lxc is set as an environment variable... hence detect_container should always work right
<xnox> Laney, also I hate that there is no logging from generators anywhere that I can see.
<Laney> well it should, if that /run/systemd/container thing is written at the right time
<xnox> root@test-laney-slow-boot:/run# rm systemd/container
<xnox> root@test-laney-slow-boot:/run# /lib/systemd/system-generators/systemd-getty-generator
<xnox> Found container virtualization lxc.
<xnox> Automatically adding console shell.
<xnox> container=lxc is set globally, as the environment =/
<xnox> i wonder if systemd clears that when launching generators
 * xnox ponders how to create lxd container and mangle it before booting it for the first time
<xnox> lxc init!
<Laney> xnox: it only uses the getenv thing if you're pid 1 though, so not sure how that works
<Laney> and yeah, when it works you get that console-shell thing which you don't get on normal first boot
<Laney> maybe the ptrace thing works though to fish the environment out of pid1 from another process
<xnox> Laney, well used init, and then modified things on disk, then started the container
<xnox> diverted that generator to &> /run/getty.log
<Laney> nice, I always forget about init
<xnox> to get
<xnox> # cat /run/getty-generator.log
<xnox> Automatically adding console shell.
<xnox> which is bad, as it doesn't say "detected container blah"
<xnox> let me crank up the logging on said generator.
<Laney> but console-shell isn't there?
<xnox> /dev/console should be there.
<xnox> and is mostly harmless.
<Laney> the unit isn't generated
<Laney> xnox: nope, I actually removed that generator completely and the units were still made :/
<xnox> Laney, i'm lost, strace lxd daemon?!
<Laney> xnox: ha, no thanks, let's rope in stgraber when he's around
<xnox> stgraber, in summary. we are confused and we need your expert guidance, cause it seems like the force is not with us anymore....
<smoser> am i the only one ?
<smoser> Could not establish FTP connection to upload.ubuntu.com: timed out
<smoser> that is just from 'dput' on cosmic
<ahasenack> isn't this a policy violation? https://pastebin.ubuntu.com/p/JNtz6dZ7z9/
<ahasenack> having libcurl3 shipping libcurl4 instead of libcurl3
<cjwatson> smoser: logs seem to think it's up and handling connections, and I can connect to it with lftp (for testing).  But of course FTP is often pretty firewall-sensitive, so if it's being problematic in your network environment then use SFTP.
<smoser> well,. it worked 30 minutes ago
<smoser> and then not 20 minutes ago
<smoser> and now it just worked.
<cjwatson> no indication of a problem in the logs
<smoser> and just 'ftp upload.ubuntu.com' did get a login prompt when iut wasnt
<smoser> odd.
<cjwatson> but could be your network env.
<smoser> yeah.. but i use the network sometimes
<smoser> i would probably notice :)
<Nafallo> ubiquity seem to use $RELEASE for at least the live installer. now, where does it get that from? :-)
<Nafallo> ^-- xnox cyphermox: one of you might know?
<jbicha> I'm having problems using dput to Ubuntu now also
<jbicha> SFTP error uploading to upload.ubuntu.com: SSHException('Error reading SSH protocol banner',)
<jbicha> or
<jbicha> Could not establish FTP connection to upload.ubuntu.com: timed out
<smoser> jbicha: i saw that and then it went away.
<smoser> cjwatson: ^
<cjwatson> hmm, pepo is very loaded
<cjwatson> top - 15:10:39 up 39 days, 20:34,  2 users,  load average: 34.18, 27.68, 18.73
<cjwatson> maybe SAN sadness again
<cjwatson> it was bad for a while and then better when its load dropped
<jbicha> ok, my upload worked now
<Nafallo> xnox cyphermox: never mind. found it when I checked the right source code :-)
<cjwatson> The state of the SAN is an ongoing problem there though, so if it's that then it's not something I can fix in a couple of hours before my EOW.  wgrant ^- FYI
<cjwatson> interesting, the load graph has a really obvious daily spike correlating with the apt-ftparchive cache vacuum
<cjwatson> which I guess would make sense, so another reason to try to move that to weekly and at a more fixed time
<dmj_s76> tseliot: What has changed between the old/new nvidia packaging?
<Unit193> sarnold: Poke?
<sarnold> hey Unit193 :)P
<sarnold> sigh
<sarnold> please forgive typos, swapped keyboards again
<Unit193> I just thought your beard was on sideways.  Mind a quick PM?
<sarnold> sure :)
 * sarnold double-checks his beard
#ubuntu-devel 2018-05-20
<elim_garak> does anyone here help manage the ubuntu bugs mailing list?
<elim_garak> i have subscribed but i never get the email to accept
#ubuntu-devel 2019-05-13
<ricotz> mwhudson, hi, thanks for uploading rustc 1.33, do you have an eta for 1.34.1?
<mwhudson> ricotz: will be working on it soon but don't know how long it will take
<mwhudson> ricotz: what do you want it for?
<oSoMoN> firefox trunk, probably
<ricotz> mwhudson, as oSoMoN said, they directly bumped from 1.32 to 1.34
<ricotz> oSoMoN, mwhudson, basically ff trunk is getting 68 beta in a few hours
<mwhudson> ah ok this is the thing i am already getting email about then :)
<mwhudson> oSoMoN, ricotz: i wrote this up https://wiki.ubuntu.com/FoundationsTeam/RustUpdates btw
<mwhudson> but debian hasn't packaged 1.34 yet so that's going to be an exciting new adventure for me
<mwhudson> tomorrow
<ricotz> mwhudson, I have reverted the bump curently and it still builds, still it might break any time
<oSoMoN> mwhudson, ricotz: thanks!
<ricotz> mwhudson, I would expect some progress in debian (exp) while 1.34.0 is available over a month already
<LocutusOfBorg> seb128 good morning, I patched xpdf... review is appreciated! sorry if it took soo long https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3714/+packages
<LocutusOfBorg> also jbicha seb128 this should be the last upnp blocker... https://github.com/intel/dleyna-renderer/issues/166
<LocutusOfBorg> I don't know how and if it can be patched
<seb128> hey LocutusOfBorg
<seb128> LocutusOfBorg, I guess we can demote that one to proposed as well?
<seb128> LocutusOfBorg, I try to have a look at xpdf but I'm at a sprint
<tsimonq2> valorie: First I need to make the reports machine-readable.
<tsimonq2> That will likely happen after what will be a crazy couple of weeks for me (AP exams, starting college courses this summer, etc...)
<tsimonq2> Thanks :)
<seb128> LocutusOfBorg, hey again, so we are down to sushi to fix ... can you have a look to that one?
<LocutusOfBorg> seb128, gupnp-tools sigh
<seb128> LocutusOfBorg, ?
<LocutusOfBorg> seb128, needs fixes?
<LocutusOfBorg> oh you fixed it 8 minutes ago, nice
<LocutusOfBorg> sushi probably needs only a no change rebuild, lets see
<LocutusOfBorg> smoser, hello, pollinate sync? https://merges.ubuntu.com/main-manual.html
<ahasenack> LocutusOfBorg: hi, I'll grab pollinate
<valorie> tsimonq2: exciting times this spring for you!
<smoser> ahasenack: thanks for grabbing that. i did take a quick look, and it looked like there would need to be an ubuntu delrta
<smoser> delta
<ahasenack> ok
<mwhudson> is there a way i can run dpkg-source -b . but have it not bother checking for upstream changes (which is slow with a huge orig like rustc)
<mwhudson> LocutusOfBorg: thanks for merging golang-1.12
#ubuntu-devel 2019-05-14
<LocutusOfBorg> thanks ahasenack!
<LocutusOfBorg> and thanks mwhudson :)
<LocutusOfBorg> stgraber, hello, I'm trying to merge/sync some packages around lxc with Debian... e.g. https://launchpad.net/ubuntu/+source/lxc-templates/3.0.3-1ubuntu2 is that one ok now? its sad to have such lxc "version checks" delta...
<Unit193> LocutusOfBorg: Hah, lastlog.  I already asked that. :P
<LocutusOfBorg> nice!
<LocutusOfBorg> Unit193, do you have a telegram account btw?
<Unit193> "yeah, assuming it's packaged in a similar way, no reason it couldn't.  I didn't know they had it now"
<Unit193> LocutusOfBorg: Not for Ubuntu stuff, no.
<stgraber> LocutusOfBorg: we can do a gratuitous bump of the epoch on lxc in Ubuntu to avoid that part of the delta, but I don't expect us to rename our binary packages unfortunately, so if we can't get Debian to call the tools lxc-utils, it's going to be a problem
<LocutusOfBorg> the lxc soname bump will resolve almost all the delta issues
<LocutusOfBorg> and yes, did you try to ask debian about creating an lxc-utils package? this seems a good idea, right?
<LocutusOfBorg> also the liblxc-dev package creation...
<LocutusOfBorg> handsome_feng, please, please please do not upload tarballs for the same package in Debian and Ubuntu, same version and different content (wrt kylin-burner_3.0.6.orig.tar.gz)
<LocutusOfBorg> extract patches on top of the same orig tarballs instead, so we don't have to fakesync or similar
<LocutusOfBorg> and we don't break the archive
<LocutusOfBorg> stgraber, python3-lxc is now merged! :)
<handsome_feng> LocutusOfBorg, Sorry, something changed that I didn't noticed when I upload it to Debian last year, It won't happen again!
<mwhudson> ricotz, oSoMoN: what's the relative priority of rustc 1.34 vs cargo 0.35?
<mwhudson> ricotz, oSoMoN: https://launchpad.net/~ubuntu-mozilla-security/+archive/ubuntu/rust-updates/+packages has rustc 1.33 and cargo 0.34 now btw, if you could kick the tyres of those packages it would be great
<mwhudson> i have 1.34.1 building in another ppa but it would be good to know if those packages work
<ricotz> mwhudson, rustc 1.34 *and* cargo 0.35 must be updated in sync, note that the internal version of cargo 0.35 is actually 1.34
<ricotz> mwhudson, thanks, I will make the next 68 builds use those packages
<mwhudson> ricotz: cool, let me know how it goes
<oSoMoN> thanks mwhudson
<ricotz> mwhudson, you can delete the trusty packages from that ppa
<oSoMoN> ricotz, I'm preparing 67.0+build1, btw
<mwhudson> ricotz: i was just wondering about that :)
<ricotz> oSoMoN, thumbs up
<LocutusOfBorg> handsome_feng, no real problem :) it was a suggestion, nothing to worry about, now the package will be seen in http://merges.ubuntu.com/ next time you upload in Debian :)
<handsome_feng> LocutusOfBorg, Thanks for your kind reminder! :*
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/dleyna-renderer/+bug/1828792 seb128 can we close it?
<ubottu> Launchpad bug 1828792 in upnp-router-control (Ubuntu) "New gupnp transition" [Undecided,New]
<LocutusOfBorg> it shouldn't migrate now that release pocket has the new gupnp, right?
<seb128> LocutusOfBorg, those needs to be fixed/ported so no it can't be closed
<seb128> LocutusOfBorg, I untagged the block-proposed though
<LocutusOfBorg> so you think it will migrate?
<LocutusOfBorg> oh exactly that was the point...
<LocutusOfBorg> probably the fix will come from Debian when its time, so this is why maybe we can close it
<seb128> I think it's work that needs to be done so the bug is valid/should stay open
<LocutusOfBorg> this makes sense, removing block proposed is enough for me, in case the fix comes from auto sync :(
<LocutusOfBorg> :)
<seb128> yeah
<seb128> bbl, lucnh
<LocutusOfBorg> jamespage, python-murano-pkg-check was syncable, I did it, can you please double check? I tried to build the Ubuntu and Debian versions, results looks mostly the same, except for some additional deps in Debian, and the documentation not being installed in the -doc package...
<LocutusOfBorg> also, now the python3 version has an higher installation priority wrt the python2 one, and this looks correct to me
<LocutusOfBorg> not sure who did put that "complex, leave alone" on merge page, but this is the second package with "complex" that can be just syncd
<Unit193> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928975 might be important to follow?
<ubottu> Debian bug 928975 in src:seafile "seafile: copyright concerns" [Normal,Open]
<jamespage> LocutusOfBorg: ack thankyou
<coreycb> sil2100: hi, thanks for reviewing bug 1805332. the [Test Case] section is updated now with a better test and gnuoy responded to your query in comment #13. do you think that's enough to accept the upload?
<ubottu> bug 1805332 in python-glance-store (Ubuntu Disco) "[Swift backend] Upload image hit error: Unicode-objects must be encoded before hashing" [Medium,In progress] https://launchpad.net/bugs/1805332
<sil2100> coreycb: excellent, looking!
<coreycb> sil2100: note i haven't re-uploaded yet
<sil2100> coreycb: yeah, please re-upload, the explaination is sufficient
<sil2100> coreycb: and I see the test case is more senseful now
<coreycb> sil2100: great, thanks. it's uploaded now.
<sil2100> coreycb: hm, I don't see it in the queue yet though
<sil2100> coreycb: should I take it from Rejected?
<coreycb> sil2100: hmm, yes i guess so. there's no change.
<sil2100> coreycb: ok, doing that
<sil2100> coreycb: accepted o/
<coreycb> sil2100: thanks!
<acheronuk> cjwatson: hi, I was suggested to ask you a question
<acheronuk> this a a section from a patch in abi-compliance-checker https://i.imgur.com/ZqSeBCO.png
<acheronuk> https://perldoc.perl.org/functions/do.html
<acheronuk> says "do BLOCK does not count as a loop, so the loop control statements next, last, or redo cannot be used to leave or restart the block. See perlsyn for alternative strategies."
<acheronuk> which seems to tally with some autotest fails with "Can't "next" outside a loop block at /usr/bin/abi-compliance-checker line 10171"
<acheronuk> which is the sub patched in there
<cjwatson> acheronuk: I guess?  Not sure why you were pointed to me
<acheronuk> cjwatson: just someone suggested you. ah, the patch is vorlon's. I'll ask him. thanks
<acheronuk> vorlon: that was yours from this I believe? http://launchpadlibrarian.net/385954640/abi-compliance-checker_2.3-0.1_2.3-0.1ubuntu1.diff.gz
<coreycb> bdmurray: hello, if you have cycles in your sru rotation would you be able to take a look at bug 1822129 ?
<ubottu> bug 1822129 in horizon (Ubuntu Cosmic) "[SRU] leave device name empty so that nova can determine it instead" [Medium,In progress] https://launchpad.net/bugs/1822129
<bdmurray> coreycb: review something in unapproved or release something to -updates?
<coreycb> bdmurray: sorry, i wasn't clear. this is for the horizon packages that are in the unapproved queues.
<bdmurray> coreycb: no problem, I'll try and have a look today
<coreycb> bdmurray: thank you
<bdmurray> coreycb: There are two uploads of horizion in the cosmic queue...
#ubuntu-devel 2019-05-15
<mwhudson> ricotz, oSoMoN: good morning, did you get to try my rustc 1.33 packages?
<mwhudson> ricotz, oSoMoN: i have hopes that my 7th (!) attempt to build 1.34.1 will succeed
<mwhudson> (haven't looked at cargo 0.35 yet)
<ricotz> mwhudson, hi, it didn't went so well yet, https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+packages
<ricotz> I am about to upload another snapshot
<mwhudson> ricotz: "34:25.80 error[E0658]: use of unstable library feature 'integer_atomics' (see issue #32976)" ?
<mwhudson> ricotz: is that the actual thing that is breaking the build?
<ricotz> yes
<mwhudson> hmm
<mwhudson> is that something that stabilized in 1.34?
<ricotz> the eoan package uses your intermediate 1.34.1
<ricotz> the others are 1.33
<mwhudson> er
<mwhudson> well 1.34.1 hasn't built on amd64 yet
<ricotz> correct, but on the other archs
<ricotz> let's wait for the next upload
<mwhudson> ah right
<ricotz> upload is quite slow here, but should be up within the next hour
<ricotz> mwhudson, btw you are allowed to use +dfsg0.x to avoid issues with debian tarballs
<mwhudson> oh right i gues that would make sense
<ricotz> mwhudson, please cancel https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/16794083
<mwhudson> ricotz: cancelled
<mwhudson> ricotz: we won't ever collide with debian here though because we repack the tarballs differently
<ricotz> mwhudson, correct, but if you rebase on an official debian package, it avoids confusion
<mwhudson> ricotz: ok
<oSoMoN> mwhudson, firefox 67.0+build1 built fine on eoan against rust 1.33 and cargo 0.34
<oSoMoN> I didn't test other series
<oSoMoN> I had to backport an upstream patch, but that's not a problem in rust itself (https://bugzilla.mozilla.org/1521249)
<ubottu> Mozilla bug 1521249 in Internationalization "--enable-rust-simd fails to build using Rust 1.33" [Normal,Resolved: fixed]
<mwhudson> _finally_ https://launchpad.net/~mwhudson/+archive/ubuntu/rust-stuff/+build/16795765
<mwhudson> oSoMoN, ricotz: would uploading rustc 1.34.1 to eoan be appropriate at this stage? (I'm not going to do it now, maybe in the morning)
<ricotz> mwhudson, should be fine if the tests are passing
<oSoMoN> mwhudson, yes that's fine
<mwhudson> two tests are failing, linkchecker which is probably the fault of my awful hacks to the docs build
<mwhudson> and tidy
<mwhudson> which fails with 'thread 'main' panicked at 'no entry found for key', src/libcore/option.rs:1038:5"
<mwhudson> i guess i'll try to figure out what this is about tomorrow but it doesn't feel like a serious problem somehow
<ricotz> mwhudson, fyi, to keep an eye on https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa/+build/16796388
<rbasak> xnox: I think I agree about where you're going with PATH in bug 1803958, but in addition, what about all the other "dangerous" environment variables - LD_LIBRARY_PATH, etc? Seems to me that the environment should be cleaned up properly if it needs to be cleaned at all.
<ubottu> bug 1803958 in Ubuntu on IBM z Systems "[UBUNTU] zkey: Fails to run commands generated by 'zkey cryptsetup'" [High,In progress] https://launchpad.net/bugs/1803958
<rbasak> (not a blocker for SRU - I'm still reviewing)
<seb128> rbasak, hey, I reuploaded those xenial SRUs with non private bugs references, sorry for not catching that before uploading
<rbasak> seb128: np. I tried to ping you before but you didn't appear to be online
<seb128> rbasak, right, I'm at a sprint this week
<rbasak> Oh, right.
<bdmurray> ddstreet: Can you explain to me how bug 1811471 was fixed again for Ubuntu 18.04? I ask as it seems to have regressed for me.
<ubottu> bug 1811471 in systemd (Ubuntu Disco) "local resolver stub fails to handle multiple TCP dns queries" [High,Fix released] https://launchpad.net/bugs/1811471
<sarnold> ow :(
<bdmurray> xnox: ^^?
<ddstreet> bdmurray per xnox that bug was intentionally regressed under the conditions i mention in comment 20
<ddstreet> vorlon and xnox, that ^ is what i mentioned when we had the discussion about stripping out edns0
<ddstreet> when i mentioned that would regress people experiencing that bug
<ddstreet> bdmurray sorry if it's a problem on your systems :(  i had originally suggested backporting the actual upstream systemd fix, which i still think is the best option, but xnox seemed rather against that
<ddstreet> maybe i should look again at the tcp pipelining support backporting
<bdmurray> ddstreet: I don't really care about my comcast email and I know how to workaround but I worry about other people.
<ddstreet> bdmurray as do i
<ddstreet> i was overruled by vorlon and xnox at the time we had the discussion
<ddstreet> an alternate approach could be to reinstate edns0 into resolv.conf but amke sure there are no cases where /etc/resolv.conf has any nameservers added besides the systemd stub resolver
<ddstreet> that's been on my long list for a while actually, as using any resolvers besides systemd can introduce problems
<alkisg> Hi, initramfs-tools passes the last cmdline parameter to pid 1 as its cmdline. For example, this tells bash to run sh: init=/bin/bash -c /bin/sh
<alkisg> It affects at least bionic and buster. Should I file a bug about it in launchpad/debian?
<alkisg> (that also means that if someone puts init=/bin/bash somewhere in the middle of his kernel cmdline, he gets a kernel panic, as bash can't understand its command line, e.g. "quit")
<alkisg> *quiet
<alkisg> root=/dev/sda1 init=/bin/bash ro quiet splash ==> that would run "/bin/bash vt.handoff=1", and bash would exit with error ==> kernel panic
<alkisg> *it would run "/bin/bash splash", sorry, mistyping a lot today :/
<ddstreet> bdmurray i opened lp #1829284 to backport tcp pipelining back to b/c :-)
<ubottu> Launchpad bug 1829284 in systemd (Ubuntu) "systemd-resolved doesn't support tcp pipelining in b/c" [Undecided,New] https://launchpad.net/bugs/1829284
<Pici> 25
<TJ-> alkisg: interesting; I cannot see how 'splash' is getting onto the cmdline of /sbin/init - certainly nothing else from the kernel cmdline does, and I don't see anything in the plymouth script that does that, it sets SPLASH=true and that just causes plymouthd to be started
<alkisg> TJ-: I think the "read parameters" loop of /usr/share/initramfs-tools/init, reads all the parameters, and "shifts", and then it calls init "$@"
<alkisg> So it's passing the last one left, that wasn't shifted
<alkisg> Let me dig into it...
<alkisg> exec run-init ${drop_caps} ${rootmnt} ${init} "$@" ${recovery:+--startup-event=recovery}
<alkisg> While "$@" is whatever was left from some "set" somewhere
<TJ-> alkisg: but the loop is reading /proc/cmdline not the init script's args array... or did I miss it reading its own command line?
<alkisg> TJ-: I haven't found the exact point yet; true, it's using a for loop without "shift"; also, the kernel doesn't pass any parameters to initramfs' init; finally, in that run-init line, it's using "$@",
<alkisg> so, so far, I'm thinking that this comes from some "set -- $var" command somewhere, which sets the last kernel parameter into "$@"
<TJ-> alkisg: there are only 3 occurences of "shift" in scripts/functions and none related to the shell command-line (but to function args)
<alkisg> TJ-: `set -- quiet` can cause this too; it's not necessary to use shift to cause it
<TJ-> alkisg: i just checked here on "cat /proc/1/cmdline" and I see "splash" where /proc/cmdline contains  BOOT_IMAGE=/vmlinuz-4.15.0-49-lowlatency root=/dev/mapper/VG02-rootfs ro no_console_suspend acpi_osi=! "acpi_osi=Windows 2013" splash vt.handoff=7
<alkisg> TJ-: oh, so it passed the previous one there, not the last one? Hm...
<TJ-> alkisg: right... I agree that the end of init script with $@ does appear to be the source, but I'm not seeing how right now!  exec run-init ${drop_caps} ${rootmnt} ${init} "$@" ...
<mwhudson> rbasak: LD_PRELOAD etc are filtered out by glibc for any setuid binary fwiw
<TJ-> alkisg: weird, there's only one "set -- ..." and that is in mask2cidr()  !
<alkisg> TJ-: it seems to skip all var=value parameters; it doesn't pass those to the init cmdline, it passes all the single-word ones
<alkisg> TJ-: which in your example above, is only "splash"
<TJ-> alkisg: it doesn't though. See "ro" "no_console_suspend" as well as "splash"
<alkisg> This happens from some point and on; e.g. I tried with "a test with var1=value and var2=value" and I got "a test with and"
<TJ-> alkisg: interesting, I'm doing:  sudo qemu-system-x86_64 -kernel /boot/vmlinuz-$(uname -r) -initrd /boot/initrd.img-$(uname -r) -append "ro no_console_suspend splash break=top"
<TJ-> alkisg: and at the initramfs shell "cat /proc/1/cmdline" shows "/sbin/init" "splash"
<TJ-> alkisg: which means *kernel* is passing it :)
<alkisg> TJ-: I tried that previously with break=premount and a stock buster vbox vm, and the kernel didn't pass anything to init. Hm...
<alkisg> I put "echo $*" in various places of initramfs-tools/init; they're all not showing the var=value parts
<TJ-> alkisg: they won't, the values are all in /proc/cmdline
<alkisg> They all show the plain "word" parameters
<alkisg> ==> e.g. I tried with "a test with var1=value and var2=value" and I got "a test with and"
<TJ-> alkisg: kernel's init/main.c::run_init_process() calls the init and sues arg_init[] which is populated thus:
<TJ-> /* Anything after -- gets handed straight to init. */
<TJ-> static int __init set_init_arg(char *param, char *val,
<TJ-> alkisg: so is that somehow getting confused?
<alkisg> Let me try completely on top of initramfs/init; if the problem is there too, then yes it's a kernel issue
<alkisg> TJ-: oh my, yup, indeed. If "word1 var1=value word2 var2=value" is used in grub, then the kernel calls init with "word1 word2"
<TJ-> alkisg: and start_kernl() has after_dashes = parse_args("Booting kernel",
<TJ-> alkisg: aha! see static int __init unknown_bootoption() ... "/ * Unknown boot options get handed to init, unless they look like ..."
<alkisg> ...I can't make any sense of that. In what point would one want /bin/bash to receive a "quiet splash" parameter? :/
<alkisg> ...and it's receiving only the "single words that follow" init=/sbin/init; not the ones before; not the var=value parameters after
<TJ-> alkisg: right, because the kernel detects those
<alkisg> At least this allows for clean instructions: "put init=/bin/bash at the end of the cmdline, or else hell will break loose"
<TJ-> in unknown_bootoption() any key=val is treated as an environment variable, anything without a value is treated as an init_arg *if* all prior tests did not 'consume' the option
<TJ-> alkisg: and indeed, in the initialramfs do "env" you see all the key=value options
<alkisg> I really can't imagine in which case "init" will find this butchered "$@" useful
<TJ-> alkisg: actually, you have to do "cat /proc/1/environ" to see it
<TJ-> alkisg: it's essential, it would handle passing systemd.log_level= and all other such options to init
<alkisg> TJ-: the kernel will remove that parameter and will not pass it to init, because it contains the equals sign
<bdmurray> manjo: The test case in bug 1764628 contains the same output for expected behavior and actual behavior... so is the SRU necessary or does the test cased need fixing?
<ubottu> bug 1764628 in util-linux (Ubuntu Xenial) "incorrect hypervisor and virtualization type reported in compat mode guest" [Medium,Fix committed] https://launchpad.net/bugs/1764628
<manjo> bdmurray, looking
<manjo> bdmurray, ouch.. I think that is a cut and past mistake
<manjo> bdmurray, if you look comment #7 you should see before and after patch
<manjo> bdmurray, I will mod the description to say see comment #7 for test
<bdmurray> manjo: Instead of just changing Hypervisor vendor to horizontal?
<manjo> ah or I can do that .. let me modify the description
<manjo> bdmurray, fixed description
<bdmurray> manjo: cool, accepted
<manjo> thanks!
#ubuntu-devel 2019-05-16
<tjaalton> LocutusOfBorg: hi, ideas how to fix 1829034?
<tjaalton> bug 1829034
<ubottu> bug 1829034 in llvm-toolchain-8 (Ubuntu) "libomp5-8 fails to install" [Undecided,New] https://launchpad.net/bugs/1829034
<tjaalton> looks like conflicts/replaces aren't properly set on the backport..
<seb128> sbeattie: hey, pointing that bug in case you didn't see it/it's interesting, bug #1829245 claims to be a regression from the recent security upload
<ubottu> bug 1829245 in qemu (Ubuntu) "Networking issues after upgrade to 1:2.5+dfsg-5ubuntu10.37" [Undecided,New] https://launchpad.net/bugs/1829245
<cpaelzer> seb128: he's off now - but I subscribed him and others
<seb128> cpaelzer: thx
<rbasak> ddstreet: thank you for raising the sudo/HOME question on ubuntu-devel-discuss@
<rbasak> ddstreet: FWIW, ubuntu-devel@ would have been fine. https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel says "Discussions seeking consensus among Ubuntu developers" is on-topic.
<ddstreet> rbasak i think user input is fairly important for this change as much as developer input, which is why i chose -discuss
<rbasak> ddstreet: fair enough
<xnox> bdmurray:  please purge resolvconf from your system. and use resolved only.
<LocutusOfBorg> tjaalton, https://salsa.debian.org/pkg-llvm-team/llvm-defaults/commit/a1287b19315f64f15fba7126cb98c314f1a5ebc2
<LocutusOfBorg> unfortunately that meta-package seems to be non-existing in bionic...
<LocutusOfBorg>  libomp-dev | 5.0.1-1               | bionic/universe          | amd64, arm64, armhf, i386, ppc64el
<LocutusOfBorg> it is provided by another libomp package, not by llvm
<tjaalton> LocutusOfBorg: no, the breaks/replaces are built wrong on bionic for llvm7 & 8
<tjaalton> Conflicts: libomp5
<tjaalton> vs
<tjaalton> Conflicts: libomp-x.y
<tjaalton> er, C/R
<tjaalton> LocutusOfBorg: unless you mean llvm-defaults would fix this
<tjaalton> LocutusOfBorg: uhm, no.. I'm just confused. it's llvm7 where libomp5-7 doesn't provide libomp-x.y
<seb128> cyphermox, hey, bug #1828996 ... wouldn't be that an hostnamed issue? I think g-c-c only calls into that
<ubottu> bug 1828996 in network-manager-applet (Ubuntu) ""Advanced Network Configuration" is displayed in both Utilities and Sundry categories" [Low,Confirmed] https://launchpad.net/bugs/1828996
<seb128> sorry wrong bug number
<tjaalton> LocutusOfBorg: so we'd need d9b6d3fd40bc107 in bionic
<seb128> bug #1162475 I meant
<ubottu> bug 1162475 in systemd (Ubuntu Xenial) "[hostnamed] Changing hostname doesn't update /etc/hosts" [Low,Triaged] https://launchpad.net/bugs/1162475
<cyphermox> it is a systemd issue, as currently assigned to it. there are *control-center tasks too because of .pkla issues in the past, and I don't know whether they all go call on whatever the dbus method is to set-transient-hostname
<cyphermox> err
<cyphermox> set-static-hostname
<seb128> cyphermox, k, thx
<seb128> cyphermox, hey btw :)
<cyphermox> seb128: good morning :)
<seb128> cyphermox, oh, while I'm talking to you. Do you plan to look at the plymouthd patches/update early in the cycle? I'm mostly curious and I a bit interested in helping with upstreaming some of our distro changes if that helps
<bdmurray> xnox: that only helps me, not other users of Ubuntu 18.04
<vorlon> bdmurray: refresh my memory, what actually introduced the behavior regression originally?
<bdmurray> vorlon: upgrading to 18.04 iirc
<vorlon> bdmurray: right, I mean, what component of the system changed its resolver behavior
<cyphermox> seb128: I'll see when I can get to that
<vorlon> is it newer glibc doing more aggressive pipelining?
<seb128> cyphermox, sounds like "not now/help welcome"? :)
<bdmurray> vorlon: I haven't had a clear understanding of the issue. ddstreet might
<LocutusOfBorg> yes tjaalton probably that one
<LocutusOfBorg> sbeattie, I syncd intel-microcode from Debian, because their version looks better than the Ubuntu one... https://launchpad.net/ubuntu/+source/intel-microcode/3.20190514.1
<ddstreet> bdmurray dns lookups with responses > 512 bytes cause getaddrinfo to fallback to TCP dns lookups, unless 'options edns0' is enabled
<ddstreet> the systemd stub resolver doesn't (correctly) support that until disco
<LocutusOfBorg> looks like they are picking stuff from github repo now, and the "releasenotes" are more up-to-date
<ddstreet> with only systemd installed, this was worked around by adding 'options edns0' to systemd stub resolver
<ddstreet> but with resolvconf installed, it might throw upstraem nameservers into /etc/resolv.conf, depending on the specific system config, so xnox told me to strip 'edns0' out of resolv.conf when resolvconf is installed to avoid that (since we can't guarantee upstream nameservers support edns0)
<ddstreet> hence, bionic/cosmic without resolvconf installed can lookup e.g. toomany.ddstreet.org
<vorlon> ddstreet: bdmurray's configuration isn't using the stub resolver, he has resolvconf and therefore upstream nameservers in /etc/resolv.conf
<ddstreet> while bionic/cosmic with resolvconf installed cannot lookup e.g. toomany.ddstreet.org
<ddstreet> vorlon resolvconf throws the stub resolver in there too
<ddstreet> and strips out edns0
<vorlon> and the configuration of the stub resolver itself is independent of /etc/resolv.conf, so if he WAS using the stub resolver it should work, since the configuration of options on the stub resolver (edns0) should be independent of the configuration of /etc/resolv.conf via resolvconf
<ddstreet> so gai won't fallback to edns0, it'll fallback to tcp
<ddstreet> edns0 is a resolv.conf conf, not systemd conf
<vorlon> bdmurray: what's your /etc/resolv.conf?
<ddstreet> it tells glibc's gai what to fall back to
<bdmurray> vorlon: https://pastebin.ubuntu.com/p/X6zdcSSdS2/
<vorlon> ok so the problem is falling back to tcp and then trying to talk to the stub resolver which doesn't listen
<vorlon> right
<vorlon> so in fact if you have resolvconf and ONLY systemd-resolved as a DNS server, we should in fact set options edns0
<vorlon> or else "fix" the stub resolver by backporting a huge new feature what could go wrong
<vorlon> or alternatively, after we finish nuking resolvconf from eoan and make systemd conflict with it (calling dr xnox), we could SRU that to bionic
<vorlon> except that's a package removal which won't be applied by update-manager
<ddstreet> yeah we really need to fix the cases where upstream nameservers are handed to resolvconf, then we can apply edns0 safely
<ddstreet> e.g. ifupdown static ip's
<ddstreet> maybe ibft
<ddstreet> no idea about network-manager or openvpn
<vorlon> maybe we should update resolvconf itself to magically re-add options edns0 if it sees only the resolved ip
<ddstreet> what if it does have an upstream nameserver?
<vorlon> I don't see a sane way to solve that case
<ddstreet> does it rip out the stub resolver?
<vorlon> hmmm there's an idea
<vorlon> why not?
<ddstreet> because the  upstream namesever might not resolve all addresses
<ddstreet> e.g. local stuff, per-interface stuff, etc
<ddstreet> we had this discussion already when you reverted my patch to make resolvconf use upstream nameservers :)
<ddstreet> pretty sure either we corral and kill all things that might put an upstream nameserver into resolvconf, or we backport resolved tcp pipelining
<ddstreet> i think tcp pipeline backport is probably the less dangerous option, but it's certainly not trivial
<vorlon> I thought the reason we reverted it was because we were winding up with /etc/resolv.conf containing *both* resolved which requires options edns0, *and* upstream nameservers that were not guaranteed to work with them
<vorlon> if we always select one or the other, and choose whether to emit options edns0 selectively according to which we choose, I don't think that has the regressions we had before
<ddstreet> that only works if you don't actually need the stub resolver to resolve anything
<ddstreet> and that's hardly going to be the case all the time
<vorlon> right, we do also need to make sure in such a case that there are no DNS servers being poked into resolved that aren't also poked into resolvconf
<ddstreet> besides backporting tcp piplining, the only sane thing to do is make all your dns belong to resolved
<ddstreet> well resolved has per-interface dns
<ddstreet> you can't do that with resolv.conf
<ddstreet> there is no way to fit resolved into resolv.conf
<ddstreet> that covers all situations
<vorlon> yes, which means you would not have BOTH per-interface dns AND upstream nameservers in resolvconf
<vorlon> changing the resolvconf package in the presence of resolved to emit only 127.0.0.53 into /etc/resolv.conf, and redirect all other servers to resolved?
<vorlon> (did we already rule that option out?)
<ddstreet> yes, that is the only sane solution - all your dns belong to resolved
<vorlon> ok
<ddstreet> but, you have to either fix the soures (ifupdown, open-iscsi, etc) to send stuff to resolved, or oyu have to hack resolvconf to send stuff to resolved
<vorlon> in that case we don't need to backport tcp support at all as long as we're telling gai to use edns0
<ddstreet> yes
<vorlon> I think hacking resolvconf centrally is better
<vorlon> xnox: ^^
<seb128> juliank, bug #1829401 looks like a recent regression/bug from your changes
<ubottu> bug 1829401 in software-properties (Ubuntu) "/usr/bin/software-properties-gtk:TypeError:on_pktask_finish:on_pktask_finish:new_init:__init__:new_init:__init__:new_init" [Undecided,New] https://launchpad.net/bugs/1829401
<xnox> bdmurray:  it helps everyone who did clean install of bionic, as none of those use resolvconf
<xnox> vorlon:  ok
<sbeattie> LocutusOfBorg: that's fine, thanks
<coreycb> sil2100: hi, any chance you could take a look at accepting nova into disco-proposed and cosmic-proposed? (the latest upload, the one before that can be rejected) - note this version will replace the current versions in -proposed
<sil2100> coreycb: sure, let me try getting to that
<coreycb> sil2100: thank you
<sil2100> coreycb: hm, actually, I think the .changes file for at least the disco one seems to be missing one version
<sil2100> coreycb: the current nova in disco-proposed has 2 versions pending SRU verification, 2:19.0.0-0ubuntu2.1 and 2:19.0.0-0ubuntu2.2
<sil2100> coreycb: you included 2:19.0.0-0ubuntu2.2 in it, but 2:19.0.0-0ubuntu2.1 got dropped
<sil2100> coreycb: could you re-upload with -v2:19.0.0-0ubuntu2 ?
<sil2100> Then we should have all the bugs in the .changes file
<coreycb> sil2100: i thought the 2nd version i uploaded included it
<sil2100> coreycb: it includes 2, while it should include 3 ;)
<sil2100> https://launchpadlibrarian.net/424039899/nova_19.0.0-0ubuntu2.3_source.changes
<sil2100> The current one in -proposed already has 2 versions scheduled, so puttin the new one on top means it should have 3 entries in the .changes file
<coreycb> sil2100: gotcha! fixing.
<coreycb> sil2100: ok uploaded a new one to disco
<sil2100> coreycb: thanks o/
<sil2100> coreycb: for the future, could we get a bit more info regarding regression potential? I'd say normally it's not enough giving context where the patches come from - every cherry-pick can cause regressions (as it was visible multiple times in the past)
<sil2100> coreycb: this section should outline where one should expect issues to pop up if anything after looking at which parts of the code have been touched
<sil2100> coreycb: it should be more of a thought exercise, identifying what areas can regress potentially due to the code changes, which other pieces can be affected by this
<sil2100> (that's for the two new bugs)
<sil2100> Anyway, accepted that for now
<coreycb> sil2100: yes i'll do my best to improve on that. there's a lot of throughput as you can tell with openstack.
<coreycb> sil2100: thank you
<coreycb> sil2100: the point i usually try to make with with cherry-picked changes is that they've gone through a whole lot of gate testing, unit and functional, and upstream reviews.
<sil2100> coreycb: that's always useful info, but we always feel safer after we know someone did look through some of the regression-potential scenarios ;)
<sil2100> Also, it really depends on the fix, since sometimes there can really be not much to write in the regression potential field indeed
<coreycb> sil2100: ack on both points
#ubuntu-devel 2019-05-17
<rbasak> mwhudson: I'm not clear on what "Fix Released" for the subuiqity LP project actually means. Am I right in thinking it isn't tracking actual availability to users? If so, any chance we could arrange for the bug tracker to be able to track when users have a fix available, eg. by using series tasks?
<rafaeldtinoco> hello, i just had a random launchpad user deleting my attached patch to LP: #1828288. I wonder how this user was able to delete my attached patch...
<ubottu> Launchpad bug 1828288 in qemu (Ubuntu Xenial) "QEMU might fail to start on AMD CPUs when 'host-passthrough' is used" [Undecided,In progress] https://launchpad.net/bugs/1828288
<rafaeldtinoco> https://usercontent.irccloud-cdn.com/file/I2DcRftj/image.png
<rafaeldtinoco> am I missing something ? :\
<marcustomlinson> tjaalton: hi, got a mail from bdmurray this morning about an increased crash rate on my libreoffice disco SRU: https://errors.ubuntu.com/?release=Ubuntu%2019.04&package=libreoffice-core&period=week&version=1%3A6.2.3-0ubuntu0.19.04.1
<marcustomlinson> Looking at them, thereâs really only one there thatâs new (the âSwPaMâ one), the rest are pre-existing conditions.
<marcustomlinson> From that stack trace, the crash is related to pasting content which causes page inserts. Iâve just tested all kinds of scenarios around that and canât reproduce.
<marcustomlinson> Can we continue phasing the update? It doesnât look (at least to me) like much regression has occurred really.
<cjwatson> rafaeldtinoco: Permissions there are unfortunately weak: https://bugs.launchpad.net/launchpad/+bug/117752
<ubottu> Launchpad bug 117752 in Launchpad itself "Any logged in user can delete any attachments" [Low,Triaged]
<cjwatson> But as noted in that bug we need to be careful, and it seems nobody has got round to it
<ahasenack> hello archive admins, I have a few NBS packages that can now be removed from eoan: libpmemcto1, libpmemcto-dev and libpmemcto1-debug
<ahasenack> https://people.canonical.com/~ubuntu-archive/nbs.html
<ahasenack> they came from pmdk 1.4.1, which I updated to 1.5.1 yesterday and upstream removed that code, so pmdk no longer produces these packages
<cjwatson> You don't really need to ask about that stuff - if it's green in the report then somebody will take care of it semi-automatically at some point
<cjwatson> I'll do it now
<ahasenack> thanks
<ahasenack> I was following https://wiki.ubuntu.com/UbuntuDevelopment/NBS which said a ping in #ubuntu-devel was appreciated :)
<cjwatson> I didn't write that :)
<ahasenack> hehe
<cjwatson> Done
<ahasenack> \o/
<coreycb> tjaalton: hello, if you have cycles in your SRU rotation today can you take a look at nova in the bionic unapproved queue?
<coreycb> there's also a software-properties change in the bionic unapproved queue to enable the train cloud archived. i'd like to get that in soon too and get the train moving along. 8)
<coreycb> cloud archive, that is
<tjaalton> coreycb: sure
<coreycb> tjaalton: thanks!
<tjaalton> marcustomlinson: I'm not sure how to do that, as I never release updates since my shift is on friday
<marcustomlinson> bdmurray could you continue phasing the libreoffice update for me?
<tjaalton> coreycb: I don't see nova on the queue
<coreycb> tjaalton: erm.. ok me neither. working on it.
<coreycb> tjaalton: i think it may have been rejected yesterday
<tjaalton> coreycb: and software-properties has a pending sru in proposed already
<tjaalton> so won't be touching that either
<coreycb> tjaalton: darn ok.
<ahasenack> uscan is failing in eoan, is this known? https://pastebin.ubuntu.com/p/Q2XvDNjCGC/
<ahasenack> same watch file worked on bionic
<ahasenack> apt-file on eoan can't find CTX_clear_m.al
<bdmurray> marcustomlinson: yes, I'll have a look at the phasing shortly
<marcustomlinson> bdmurray: thanks
<coreycb> tjaalton: nova is in the bionic unapproved queue for real now
<Eickmeyer> If any MOTU wants a quick, easy package to sponsor, I've got one at bug 1829562. lintian --pedantic returns no errors. The copyright file is a little long, but I went over it pretty thoroughly.
<ubottu> bug 1829562 in DPF Plugins "[Needs Packaging] DPF-Plugins for Eoan" [Undecided,New] https://launchpad.net/bugs/1829562
<ddstreet> coreycb in case you didn't see, i added you to a WIP MP i have for software-properties, https://code.launchpad.net/~ddstreet/software-properties/+git/software-properties/+merge/367276
<ddstreet> if you have any comments/suggestions/concerns about my changes overall or specifically to cloudarchive.py backend, let me know
<ddstreet> updated cloudarchive.py file is https://git.launchpad.net/~ddstreet/software-properties/tree/softwareproperties/cloudarchive.py?h=lp645404
<SwedeMike> win 575
<sarnold> 575? wow :)
<CarlFK> ddstreet: https://git.launchpad.net/~ddstreet/software-properties/tree/softwareproperties/cloudarchive.py?h=lp645404#n54  "This page has moved to https://wiki.ubuntu.com/OpenStack/CloudArchive. "
<coreycb> ddstreet: i think i'm missing context. is there a related bug i can read?
<coreycb> sory, i see related bug
<ddstreet> coreycb sure lp #645404
<ubottu> Launchpad bug 645404 in software-properties (Ubuntu Eoan) "Support Private PPAs" [Low,In progress] https://launchpad.net/bugs/645404
<ddstreet> CarlFK ah ok - that's what it is currently in software-properties, i just left it in
<ddstreet> CarlFK i.e. that isn't something i changed :)
<ddstreet> but i will now ;)
<ddstreet> CarlFK thnx, fixed that in my branch (not in main s-p repo tho, until mine is merged)
<ddstreet> vorlon i see you're retrying those systemd autopkgtest...you have any idea what's going on with those?  it seems like a autopkgtest nova/vm problem?
<ddstreet> it's been failing strangely like that since earlier this week, with the nova guest output summary at the bottom, and timing out ssh'ing into the testbed
<ddstreet> sorry, by 'autopkgtest nova/vm problem' i mean it seems like a problem with autopkgtest.ubuntu.com testbed vms
#ubuntu-devel 2019-05-18
<vorlon> ddstreet: I hadn't looked at the failures before retrying them.  The latest i386 failure looks like the kernel regression/race that xnox was chasing for a while on power
#ubuntu-devel 2019-05-19
<jamespage> xnox: hey - I'm starting to look at ceph for eoan I need a newer smartmontools than we have in Ubuntu (7.0 vs 6.6)
<jamespage> xnox: if I prep and upload would you be able to review?
#ubuntu-devel 2020-05-11
<ackk> xnox, hi question about maas transitional deb. we're considering dropping it entirely in groovy, given that users will be migrated to the snap. is that acceptable, or does it have to be demoted to universe first?
<xnox> ackk:  open an RM bug report in launchpad, subscribe ubuntu-archive and let it be gone.
<ackk> xnox, cool, thanks
<ackk> xnox https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1877973 FTR
<ubottu> Launchpad bug 1877973 in maas (Ubuntu) "RM request - removal from archive" [Undecided,New]
<cpaelzer> paride: you wrote on https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1877575 that this happens with focal live-server as well
<ubottu> Launchpad bug 1877575 in qemu (Ubuntu) "kernel crash with 0010:ovl_open_realfile+0x4a/0x150 [overlay] in Qemu with focal daily" [Critical,Confirmed]
<cpaelzer> paride: does it crash the guest or the host?
<paride> cpaelzer, it's the guest that crashes
<cpaelzer> paride: while looking at that - is it concerning that on http://cdimage.ubuntu.com/ubuntu-server/daily-live/current/ the most recent arm64 image is of 	2019-11-04 07:40 ?
<paride> cpaelzer, the pending->current promotion script did certainly run on much newer images
 * paride checks
<paride> cpaelzer, well I think we shouldn't have focal images at all in that location
<paride> sil2100, what do you think? ^^
<rbasak> paride: around? May I have some help/advice with a git-ubuntu release task please?
<paride> rbasak, yes, 1 minute as I finish replying to a bug
<paride> rbasak, available when you want
<rbasak> paride: I just realised that it might take far too long to type and explain. To save time, do you have time now to join a hangout? Maybe my squad's daily standup?
<paride> rbasak, joining
<paride> rbasak, standups done, looking into the job
<rbasak> Thanks! Let me know if you need anything
<paride> rbasak, the git-ubuntu-ci-nightly job now has a parameter to specify which branch/tag to checkout
<paride> I'm testing it with the default settings (master)
<rbasak> Thank you!
<paride> rbasak, once it's done you can try with the tag you want to release
<rbasak> Will do
<paride> https://github.com/canonical/server-jenkins-jobs/pull/119 <- to be merged if everything works
<rbasak> bryce: ^ just FYI - that's for a 0.10.1 release as it's the first time we're releasing from not-master.
<bryce> rbasak, ok
<rbasak> I'll update the doc
<bryce> rbasak, is this new policy or just for the 1.0?
<rbasak> bryce: it's just the means to get a build if master isn't on the release tag. I suppose we could change the procedure to always do that in order to make the process simpler.
<rbasak> paride: your build succeeded, so I'll start one now against the release tag.
<rbasak> Oh. The "Build Now" button didn't ask me for parameters.
<smoser> whats the correct way to ask for a git-ubuntu import ?
<ahasenack> smoser: here is fine
<smoser> i'm interested in sbuild-launchpad-chroot
<ahasenack> let me run that
<ahasenack> rbasak: is it ok to import that now, given your g-u work, with what is running on the importer nodE?
<ahasenack> rbasak: I'll run it
<ahasenack> smoser: it's imported now
<ahasenack> smoser: I also committed a change so it's whitelisted from now on, but to have that effective requires a new deployment of the importer, which doesn't happen all the time
<ahasenack> in other words, ping me if it's out of date
<smoser> ahasenack: k. thank you
<rbasak> ahasenack: yes, that was fine
<ahasenack> ok
<rbasak> ahasenack: in general, if the service is running, then it's safe to do a manual import also. If it is not, then I'm messing with it and it's not.
<rbasak> paride: git-ubuntu-ci-nightly seems to still have a "Build Now" button but I'm expecting a "Build with Parameters" button. Any ideas?
<rbasak> The git-ubuntu-ci job is an example of one that has "Build with Parameters"
<paride> rbasak, yes, the new job definition got overwritten by the auto-deploy job
<rbasak> Ah. That would explain it!
<paride> rbasak, now it has "build with parameters" again
<rbasak> It was very puzzling :)
<rbasak> Thank you!
<rbasak> I've started a job for 1.10.1. Let's see.
<rbasak> I hope aborting the previous job didn't break anything.
<paride> it shouldn't
<paride> rbasak, wrong tag?
<rbasak> paride: :(
<rbasak> paride: I've retried with the right one (I hope!)
#ubuntu-devel 2020-05-12
<seb128> RAOF, bdmurray, SRUteam, could someone review the gnome-shell stack SRUs in the focal queue? it has several fixes for rough edges in the LTS desktop, the updates are not trivial but GNOME bugfixes ones, would be nice to see those accepted :-)
<juliank> didrocks: i recently had this crazy idea - given that zsys snapshots the system before you upgrade stuff, why don't we just turn off some consistency features in apt and dpkg on such systems, as you can just reboot and revert if stuff fails
<juliank> like all the fsync stuff
<paride> rbasak, all good with the git-ubuntu build, right?
<rbasak> paride: yes, thanks. I have a built snap, just sorting out the release announcement etc
<didrocks> juliank: that would be excellent! The idea is also to offer offline upgrade in the long term, but meanwhile, this is a good improvements for our users
<juliank> didrocks: Also makes me wonder if you want to setup boot so that if you have a crash during apt run, it automatically restores to the working state from before you ran apt
<juliank> so that you get online upgrades but with an offline upgrade like feel if the machine resets during an upgrade
<juliank> #safety
<juliank> "Your system rebooted in the middle of package operations, do you want to continue with the possibly broken system or revert to the last known-good state?"
<didrocks> juliank: good idea, something to file a bug against and see how we can instruct grub doing that. Just file it against the zsys github project so that we donât forget about it
<juliank> ack
<Teduardo> Hello, does anyone have any idea why autoinstaller's default storage schema is to create a 100% VG on the first disk but then only use 1% of that VG for the filesystem?
<Teduardo> I tried asking ubuntu-installer folks but I can't seem to get ahold of any of them.
<ubusr> Is there any ETA on fixing ubuntu 18.04 and 16.04 "file/libmagic" packages to fix the ELF parsing bug ?
<rbasak> Do you have a bug reference?
<ubusr> nop
<rbasak> Then presumably there is no ETA.
<ubusr> :/  I can rereport it here if anyone is intrested
<rbasak> If you want to track progress, I suggest that you find the existing bug there is one, or file one if there isn't.
<ubusr> how can I track when the bug was introduced ?
<ubusr> something likt git bisect, where I can rollback the file package till the bug stops ?
<seb128> ubusr, is there a bug open about that issue? you mention it as it was a known problem
<rbasak> ubusr: https://launchpad.net/ubuntu/+source/file/+publishinghistory might be helpful, assuming the root cause was actually in that package.
<ubusr> seb128: ahh, I typed it yesterday here :/ , not sure if there is an open bug, but in the last few month, the file program started truncating the interpreter path of ELF binaries in the output
<ubusr> (atleast in docker environments)
<rbasak> Please don't assume that mentioning a problem in this channel is sufficient. If there isn't a bug filed, you can't assume there will be any progress.
<ubusr> would be glad if someone can do it, I hate keeping track of yet one more password leak :/
<seb128> ubusr, I don't think you described enough what the issue is for anyone to be able to open a report for you
<seb128> do you have a testcase?
<rbasak> I'm against doing it. A bug report isn't the end of the story. If developers can't communicate with the people actually affected bugs can often stall.
<ubusr> basically if you run docker (maybe regular one as well) ubuntu 18.04 and 16.04 and install the "file" package, and run file /bin/bash this si the output
<rbasak> If you want it fixed, please at least file a complete bug report yourself.
<ubusr>  /bin/bash: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=12f73d7a8e226c663034529c8dd20efec22dde54, stripped
<ubusr> you can see the interpreter is truncated there (/lib64/l) on ubuntu 20.04 docker it's not truncated, and I'm sure that about 6 month ago, it wasn't on 16.04 as well
<ubusr> so somewhere along the line something changed in previous ubutnu versions
<seb128> ubusr, there is already a report on https://bugs.launchpad.net/ubuntu/+source/file/+bug/1835596
<ubottu> Launchpad bug 1835596 in file (Ubuntu) "incorrect argument to file_printable in [PATCH] PR/62" [Undecided,New]
<ubusr> hmm... 16 month ago it worked ok
<cjwatson> Introduced as part of a security fix
<cjwatson> E.g. https://launchpadlibrarian.net/414997700/file_1%3A5.25-2ubuntu1.1_1%3A5.25-2ubuntu1.2.diff.gz
<seb128> https://launchpad.net/ubuntu/+source/file/1:5.25-2ubuntu1.2
<seb128> ah, cjwatson beat me to it
<seb128> mdeslaur, ^ fyi
<ubusr> nice, thanks for the info, will it ever be fixed :/  I had a script that dependend on the correct output
<mdeslaur> thanks cjwatson seb128
<seb128> ubusr, now that you raised it probably
<mdeslaur> ubusr: yes, I'll handle it, I wasn't aware of it
<ubusr> cool, thanks
<ubusr> btw, how come in 20.04 it's ok ?
<mdeslaur> thanks ubusr
<cjwatson> I presume the regression was fixed upstream a bit later but that fix didn't make it back into security updates for older series
<cjwatson> Hm
<cjwatson> Or maybe a bad backport
<cjwatson> Yep, bad backport
<cjwatson> https://github.com/file/file/commit/9109a696f3289ba00eaa222fd432755ec4287e28 changed interp in that function from being a const char * to a char[]
<cjwatson> Which changes what sizeof(interp) means
<mdeslaur> yes, it's a bad backport
<cjwatson> So the code was correct when committed to upstream file, but when backported it needed to be changed to um strlen(interp) + 1 or something
<mdeslaur> ubusr: I'll publish the regression fix tomorrow or thursday
<seb128> ubusr, thanks for raising the issue
<seb128> mdeslaur, and thanks for taking on fixing it :)
<mdeslaur> I broke it, I get to glue the pieces back together :)
<rbasak> cpaelzer, waveform, ahasenack: FYI, I'm going to reimport and force push branches for u-boot, qemu, chrony, gpsd and squid soon. Previous bugs are fixed, so hopefully this will be the final time - take 2.
<ahasenack> rbasak: ok
<waveform> rbasak, no prob
<ahasenack> sergiodj: ^ about squid
<sergiodj> ahasenack: thanks
<ubusr> seb128: if you want to see how I "found" the issue https://github.com/tzickel/docker-trim/issues/1
<ubusr> took me time to understand that report was because ubuntu 16.04's file truncated it
<ubusr> https://github.com/tzickel/docker-trim/blob/master/Dockerfile.get_instrumentation <-- is there a better way to get a static version of file to work ?
<rbalint> ddstreet, i need to rewrite the ubuntu-groovy because the reverts are still needed, please rebase your branches if you have anything in flight
<rbalint> ddstreet, i'm about to upload the queued fixes to groovy + the lxd tests to let them being srud and will try dropping the reverts again
<ddstreet> rbalint ack thanks, i dont think i have anything outstanding for g but i'll rebase if so
<rbasak> cpaelzer, ahasenack, sergiodj: reimports of squid, chrony and gpsd are cmoplete.
<rbasak> u-boot and qemu are still going
<ahasenack> ok
<sergiodj> rbasak: thanks
<rbasak> waveform: u-boot reimport is done
#ubuntu-devel 2020-05-13
<cpaelzer> rbasak: I saw the effect of gpsd re-import - looks fine to me
<cpaelzer> LP showed odd-diffs on existing MPs, but they at least still existed
<cpaelzer> I could easily rebase from old to new without anyy problem
<mitya57> wgrant, doko: Hi, we get internal compiler error when building qtbase 5.14 for riscv64, see https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4057/+build/19293614
<mitya57> We retried it two times, it fails each time in a different file, but early enough in the build process, so there is little hope that further retries will help.
<mitya57> Do you know what I can do about this? A similar thing happens in Debian (experimental).
<wgrant> mitya57: Ugh, thanks for the poke, I thought that was fixed with new qemu etc. Sounds like I'll have to downgrade the buildds again
<wgrant> Oh, interesting
<wgrant> Oh experimental is still on qemu iirc
<wgrant> So it could be the same thing
<wgrant> There's a bug in either the new qemu, OpenSBI or Linux that seems only break really heavy g++ runs
<wgrant> But at least this one seems to repro quickly enough
<mitya57> Debian's buildd name is rv-rr44-01, looks like it's also used for sid.
<wgrant> Oh interesting, that one is real hardware.
<wgrant> So maybe this isn't the thing we saw a month ago which was fixed by the qemu downgrade
<wgrant> There was also a potential issue with Linux 5.4 over 5.3, but I wasn't able to reproduce it. Which kernel is the Debian one running?
<mitya57> I wonder how I can check that
<wgrant> mitya57: We print it at the top of our build logs, but I forget if Debian does
<mitya57> wgrant: found it, Kernel: Linux 5.6.3+ #1 SMP Thu Apr 16 06:33:06 UTC 2020 riscv64 (riscv64)
<mitya57> wgrant: The last successful build was with 5.0.0+, and the first failing build was with 5.5.0-1-riscv64.
<mitya57> And the last successful build in Ubuntu was with 5.3.0-13-generic, so it may confirm your hypothesis.
<wgrant> Ubuntu also has a new qemu and firmware, so it's not definitive, but I definitely saw at least one similar crash that I believe I isolated to the new kernel
<wgrant> Will try to run a few scenarios tomorrow, including on hardware, and see what turns up
<mitya57> wgrant: ok, thanks
<LocutusOfBorg> wgrant, do you think we can backport qemu to support riscv64 on bionic?
<wgrant> LocutusOfBorg: Ubuntu Cloud Archive contains backports of qemu. https://wiki.ubuntu.com/OpenStack/CloudArchive#Ussuri is what's running on the prod builders atm
<LocutusOfBorg> wgrant, thanks a lot! I tried to backport it by myself but it was needing too much effort
<LocutusOfBorg> wgrant, looks like the same issue I faced  qemu-block-extra : Depends: libssh-4 (>= 0.8.4) but 0.8.0~20170825.94fa1e38-1ubuntu0.6 is to be installed
<LocutusOfBorg> how can I install something like that?
<wgrant> LocutusOfBorg: Hm, is that not in the PPA too?
<LocutusOfBorg> nope, not in sudo add-apt-repository cloud-archive:ussuri
<LocutusOfBorg> I think I can fix via sudo add-apt-repository ppa:ubuntu-cloud-archive/ussuri-staging
<LocutusOfBorg> or sudo add-apt-repository ppa:openstack-ubuntu-testing/ussuri
<LocutusOfBorg> but its ok, I already have the new qemu now :) thanks!
<wgrant> Huh, maybe that's not fully done yet. But yeah, I actually used ussuri-staging
<LocutusOfBorg> I'm already creating a riscv64 chroot now :) thanks!
<wgrant> LocutusOfBorg: Nice, let me know if you run into any trouble.
<wgrant> LocutusOfBorg: Are you using the image from https://people.ubuntu.com/~wgrant/riscv64/ or building your own?
<LocutusOfBorg> building myself
<LocutusOfBorg> pbuilder-dist groovy riscv64 create
<LocutusOfBorg> I don't like pre-built stuff ;)
<wgrant> LocutusOfBorg: Oh, I meant to boot the system
<wgrant> On the chroot, yes, I agree
<LocutusOfBorg> I don't care about booting, I care about debugging build issues for now!
<wgrant> Oh, qemu-user, right
<LocutusOfBorg> yay
<LocutusOfBorg> it has been successfully created thanks!
<LocutusOfBorg> now I lost my interest in upgrading bionic to focal, thanks to you :p
<cpaelzer> fighting with i386 a bit and dependencies - is there a md->man converter that is available on Ubuntu i386?
<cpaelzer> the project I look at by default uses pandoc, but that isn't on Ubuntu i386
<cpaelzer> is there an established common way to go on i386 build deps for md->man?
<juliank> cpaelzer: can you build that on amd64?
<juliank> nobody should need docs on i386
<juliank> you can't just switch out pandoc for something else, that's not going to work - markdown syntax is specific to the tool
<wgrant> There are a scary number of things that need pandoc for their arch build, though you'd think those could mostly end up in -common or -doc :(
<wgrant> You can get basically nowhere with an arch bootstrap without pandoc
<juliank> wgrant: I feel like i386 builders should have amd64 as a foreign architecture, so it can use amd64 pandoc
<wgrant> (and pandoc brings in several hundred deps)
<juliank> it's m-a foreign after all
<wgrant> Making ports not self-hosting is a non-trivial decision.
<cpaelzer> making an arch neutral -doc package was my next best guess already
<cpaelzer> seems you confirm these thoughts (and destroy my hope of an easier way out)
<juliank> heh or just don't build the docs on i386 or fake pandoc
<cpaelzer> "just don't build the docs on i386" is what we do atm - but strictly speaking that is against the policy
<wgrant> Yeah, I suppose a -dev without docs on i386 wouldn't be the end of the world.
<cpaelzer> I need to get this to Debian which still cares about i386
<juliank> don't get it there and carry a delta
<juliank> it depends on whether it makes sense splitting out doc or not
<cpaelzer> I can ask if they'd be open to split it
<juliank> I've had ftpmaster reject packages because they were too small
<cpaelzer> this is the only delta the pkg has, so dropping it would make it a sync again and reduce the maintenance-toll
<juliank> ack
<cpaelzer> thanks for your hints juliank and wgrant - I'll give it a try and ask
<cpaelzer> asking never hurts
<wgrant> We already have to carry a bunch of deltas for the partial port
<kanashiro> hi, I have a build failure on riscv and I'd like to reproduce it. What is the best way to setup a riscv build environment locally? I found this Debian doc: https://wiki.debian.org/RISC-V#Setting_up_a_riscv64_virtual_machine
<kanashiro> wgrant: ^
<wgrant> kanashiro: https://people.ubuntu.com/~wgrant/riscv64
<wgrant> Has images and instructions
<wgrant> Which is the failure?
<kanashiro> wgrant: https://launchpadlibrarian.net/479313809/buildlog_ubuntu-groovy-riscv64.ruby2.7_2.7.1-3_BUILDING.txt.gz
<kanashiro> the same in Focal
<kanashiro> https://launchpad.net/ubuntu/+source/ruby2.7/2.7.0-5ubuntu1.1/+build/19295534/+files/buildlog_ubuntu-focal-riscv64.ruby2.7_2.7.0-5ubuntu1.1_BUILDING.txt.gz
<wgrant> That might be the same thing that qtbase ran into, which seems to be some kind of bug in the new kernel or qemu
<wgrant> They've all been upgraded since the final focal builds, and there are a couple of new mysterious failures in some heavy gcc runs
<kanashiro> yeah I was considering something like that because I am quite sure the changes in the package did not trigger the failure
<wgrant> Good to have another test case. I'll hopefully investigate it tomorrow, or just downgrade all the VMs again and see if they work
<kanashiro> thanks wgrant
<rbasak> cpaelzer: on bug 1873415
<ubottu> bug 1873415 in gpsd (Ubuntu Focal) "gpsd needs to ship packaging/deb/etc_default_gpsd as default instead of debian/gpsd.default" [High,Triaged] https://launchpad.net/bugs/1873415
<rbasak> I'm not convinced that this change is justified in an SRU, even if bundled in other changes - because of the conffile prompt issue
<cpaelzer> rbasak: yeah of the three bugs in this SRU this is the least important
<rbasak> I'm willing to be persudaded
<cpaelzer> not worth on its own, but along the others it will help users
<cpaelzer> rbasak: starting persuasion
<rbasak> But my feeling is that if it's the mere knowledge of existence of the tunable is the reason, that's not worth a conffile prompt for users who tune
<cpaelzer> rbasak: lets's break into the potential cases that might happen
<rbasak> And that documentation elsewhere would be more suitable
<cpaelzer> rbasak: this file is not commonly modified, so the majority will not get a conffile prompt
<cpaelzer> rbasak: as checksums will match
<rbasak> Agreed, though the same is generally true of all conffile prompts
<cpaelzer> oh wait
<rbasak> The file mentions dpkg-reconfigure
<cpaelzer> I have too many SRUs in flight
<cpaelzer> this default file
<cpaelzer> no it is actually rather common to have that one modified
<rbasak> So "checksums" alarms me a little. Should debconf be being used in the usual way, so no maintainer script managed checksums present?
<cpaelzer> to set the device you want it to operate on
<cpaelzer> rbasak: you know what - I wanted to help the users with that - if you think it violated the SRU policy let me strip it
<cpaelzer> rbasak: the important ones are the others
<rbasak> No specific policy here
<rbasak> TO be clear
<cpaelzer> rbasak: could you cancel the upload from -unapproved and I'll push a new one in a minute?
<rbasak> Just a user impact concern
<rbasak> Sure, if you prefer
<cpaelzer> it is a corner case in a not too common package - not worth having us discuss 20 minutes longer
<rbasak> I don't mind talking it through though. I'm still open to more details and persuasion :)
<rbasak> OK
<cpaelzer> I'll not waste my SRU persuade credits on this case
<rbasak> The apparmor changes looked fine to me
<cpaelzer> to me as well :-)
<cpaelzer> rbasak: I'm ready to re-upload
<rbasak> I'll double check but they seem appropriate, even though there's also a conffile prompt risk there!
<cpaelzer> rbasak: did you cancel the old one already?
<rbasak> I've rejected but you don't need to wait for that anyway :)
<cpaelzer> rbasak: I have to wait - othersiw I'll get the "version is already there" reject
<rbasak> Really?
<rbasak> Is that a new thing?
<cpaelzer> I did in the past and since then avoid it
<cpaelzer> haven't retried
<cpaelzer> rbasak: new upload should be in the queue
<rbasak> I was fairly sure that this doesn't happen. I will experiment at the next opportunity :)
<cpaelzer> rbasak: and on the apparmor change - the conffile-prompt there exists but isn't a blocker of any sort
<cpaelzer> otherwise we'd never fix aa profiles :-)
<rbasak> Yes - it will stop the fix if somebody has their own changes
<cpaelzer> also the gain by the fix is much much higher than the one we had on the USBAUTO variable
<cjwatson> cpaelzer: I believe you are mistaken
<rbasak> But the request for the merge is correct and the user will have .dpkg-new there in that case and that's the best we can do
<cpaelzer> cjwatson: am I, ok maybe it is bad memory
<cjwatson> cpaelzer: It's an extremely long-standing bug (arguably) that what you describe *doesn't* happen.  https://bugs.launchpad.net/launchpad/+bug/62976
<ubottu> Launchpad bug 62976 in Launchpad itself "Soyuz should not allow duplicated packages in NEW/UNAPPROVED queue" [High,Triaged]
<cpaelzer> cjwatson: you'd expect the new upload to overwrite the old one?
<cpaelzer> oh duplicate
<cpaelzer> thanks for the info cjwatson
<cjwatson> It's not completely clear what should happen, but the current situation permits results that are very confusing
<cpaelzer> I still perfer to properly cancel and then upload it then - to avoid any ambiguity
<rbasak> cjwatson: personally I find the current behaviour useful, as it doesn't block the uploader from superseding and the person processing the queue can easily enough sort it out with no real extra effort
<cjwatson> rbasak: I tend to think that uploaders should be able to self-reject, which would help with that, I think
<rbasak> Agreed
<rbasak> If you change things, please enable that first :)
<cpaelzer> rbasak: ping me if you find anything worth to discuss on the apparmor changes then
<rbasak> ack
<cjwatson> Right, it certainly needs systemic thought rather than just changing that one thing.  I'll make a note in the bug
<rbasak> Thanks!
#ubuntu-devel 2020-05-14
<Unit193> Regarding https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2020-May/018679.html, I actually ran into this issue between Debian unstable and Ubuntu Bionic as well.  I ended up backporting 1.3.0
<wgrant> doko, kanashiro, mitya57, RAOF: I've downgraded kernel and firmware (but not qemu) on the riscv64 buildds and retried some affected builds, and it looks promising so far. I've also been able to repro the qtbase-opensource-source gcc segfault on focal on real hardware with 5.4, so it does seem likely it's a kernel regression.
<cpaelzer> rbasak: new fun with git-ubuntu on qemu
<cpaelzer> rbasak: my special edge-cases  keep on coming it seems
<cpaelzer> rbasak: newer releases work fine it seems, but historically there was some mismatch between git based on salsa and git-ubuntu imports
<cpaelzer> rbasak: that sometimes led to mismatches and is resolved in newer releases
<Unit193> cpaelzer: Stop being a corner case, then! :P
<cpaelzer> rbasak: but we might face something like it again due to git submodules
<cpaelzer> Unit193: that isn't a problem - rbasak is happy to settle the corner-cases with me instead of later on a wider user group :-)
<Unit193> cpaelzer: Hah, sorry in case the humor doesn't carry over.  I've hit some weird corner cases in things too, it's pretty nifty when you can find a bug like that and get it fixed. :)
<cpaelzer> np, the humor carried over
<cpaelzer> rbasak: repro should be 1. check out qemu bionic-devel 2. dpkg-buildpackage -S -nc -d - it will fail complaining about a mismatch between tarball and source in qemu.git/ui/keycodemapdb/..git
<cpaelzer> that is a git submodule - part of git-ubuntu import (e.g. I get it restored when I git checkout .) and can be resolved by rm'ing the file before build
<ackk> xnox, hi, is there anything I have to do to progress https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1877973 or will it just get picked up at some point?
<ubottu> Launchpad bug 1877973 in maas (Ubuntu) "RM request - removal from archive" [Undecided,Triaged]
<mitya57> wgrant: thanks! qtbase is building for 5 hours and has not failed yet :)
<wgrant> Downgraded just the kernel on hardware, and my test case has been running for 25 minutes now, whereas it previously failed in 10-600s reliably.
<cpaelzer> rbalint: hi, I've done the identificationa nd driving of a journald issue in focal in https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875708
<ubottu> Launchpad bug 1875708 in systemd (Ubuntu) "Truncated messages in journald since systemd v244" [Undecided,New]
<cpaelzer> rbalint: I think all the prep is done, next step would be backporting to focal and pushing it there with the next update
<cpaelzer> in the past that part was doen by xnox usually grouping things with a bunch of others in his queue - would now you do such and I can "pass" the bug over to you?
<ddstreet> cpaelzer i upload the majority of systemd srus, i can include yours if it's ready, i'm watching your bug
<cpaelzer> ddstreet: it is ready upstream
<cpaelzer> I didn't look into doing a backport yet and how complex or not that might be
<cpaelzer> different topic - did the arm builders just have some hard reset - I see builds in failed state but no build log
<cpaelzer> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4062/+build/19301601
<cpaelzer> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/4062/+build/19301602
<cpaelzer> https://launchpad.net/builders doesn't look like all would be gone ...
<rbalint> cpaelzer, ddstreet  i kept an eye on LP: #1875708, it missed last upload to groovy, but good to go in next one, thanks for driving it and for the heads-up
<ubottu> Launchpad bug 1875708 in systemd (Ubuntu) "Truncated messages in journald since systemd v244" [Undecided,New] https://launchpad.net/bugs/1875708
<ddstreet> ack rbalint, and there's a version in focal-proposed that should go out next week, i think it only needs backporting to focal so can go into the next one
<rbalint> ddstreet, cool, thanks
<ddstreet> i can push to focal once you've got in groovy.  thanks!
<cpaelzer> thank you ddstreet and rbalint - so I can keep 1875708 to you then to be grouped with the next uploads \o/
<cjwatson> cpaelzer: #launchpad
<cjwatson> (it is known)
<kanashiro> wgrant: thanks! ruby2.7 migrated to the release pocket :)
<wgrant> kanashiro: Great. Sorry about that.
<wgrant> I have a kernel bisect to look forward to tomorrow.
<kanashiro> np
<xnox> ackk:  you can ping AA => ~ubuntu-archive team members, i.e. sil2100 vorlon RAOF doko
<ogra> AA ... the anonymous archivists ...
<rbasak> cpaelzer: on qemu and ..git, that's expected I believe
<rbasak> git cannot store anything called .git found in the source tree in general, so it must be stored escaped
<rbasak> If you use dpkg-buildpackage directly then you won't get that unescaped
<rbasak> The intention is that "git ubuntu build" would do the correct unescaping. I'm not sure if that's implemented yet. But it's not an issue from the importer end.
<cpaelzer> rbasak: the problem is that the decision how to "not store" it seems to be different
<cpaelzer> rbasak: you stored it as ..git while the tarball doesn't have it at all
<cpaelzer> so on build it complains that there is a ..git it doesn't know
<rbasak> The extracted source tree must have .git - otherwise there wouldn't have been anything to escape at import time
<rbasak> But yes - if .git gets renamed to ..git, then from the perspective of dpkg-source it'll be a new directory not present in the orig tarball and you'll get a complaint
<rbasak> This escaping has been present for years, BTW. It's not a new thing.
<rbasak> Oh
<rbasak> But I did fix a bug in it not too long ago
<rbasak> cpaelzer: I think it's an error for Debian to be uploading source packages with .git in them
<rbasak> Even if it's a submodule reference thing
<rbasak> If the process for generating the source package from git before upload could be adjusted not to do that, then that'd fix the problem for you maybe?
<rbasak> Because otherwise the result simply cannot be imported back into git, since git will not accept an entry called .git
<cpaelzer> rbasak: it seems it was a recent upload by mdeslaur that did this
<cpaelzer> rbasak: I'm usually working of git-ubuntu (whichi didn't have .git or ..git) but I expect he would work of the source package
<cpaelzer> rbasak: he then has got the .git as it is in the tarball
<cpaelzer> and on re-import it became ..git
<cpaelzer> see git diff import/1%2.11+dfsg-1ubuntu7.22..import/1%2.11+dfsg-1ubuntu7.23 -- ui/keycodemapdb/
<cpaelzer> that is why I only see this "recently"
<rbasak> cpaelzer: in the reimport that gives me no results. Could you pastebin what you see please? But I'm still puzzled as the orig tarball is the same for both. So git-ubuntu should see the same situation for both versions.
<rbasak> What's in your source tree in !debian, for a "3.0 (quilt)" package, should be unconnected to what ends up in the built source package assuming your source package build succeeds
<rbasak> Because on extraction that part of the source tree will come from the orig tarball and nowhere else.
<cpaelzer> rbasak: https://paste.ubuntu.com/p/xQV7m5GfGZ/
<cpaelzer> commit 9514499ffce37066c0048f543b33d9ec01ef5cc4 (tag: reimport/import/1%2.11+dfsg-1ubuntu7.22/0, tag: import/1%2.11+dfsg-1ubuntu7.22)
<cpaelzer> commit 9360dd8574d10d92b62742d9cbb09e9c2274296e (tag: import/1%2.11+dfsg-1ubuntu7.23)
<rbasak> Right I see https://git.launchpad.net/ubuntu/+source/qemu/diff/ui/keycodemapdb/..git?h=9360dd8574d10d92b62742d9cbb09e9c2274296e thanks
<rbasak> cpaelzer: you're still looking at the previous import tree I think?
<rbasak> That change came from the bugfix I believe - not anything Marc did or didn't do
<cpaelzer> rbasak: well formerly it wasn't important and therefore worked
<cpaelzer> rbasak: now it is imported as ..git and breaks on buildpkg
<cpaelzer> so "correctly" importing made it worse in this particular case :-/
<rbasak> cpaelzer: that sounds right :-/
<ahasenack> what if .git isn't imported at all?
<cpaelzer> which is as it was before
<ahasenack> dpkg knows how to ignore its presence
<rbasak> ahasenack: theoretically a source package build might depend on its presence
<rbasak> cpaelzer: could you use -I..git?
<ahasenack> I've seen builds break because they *see* it
<cpaelzer> rbasak: but it won't get that as it is only ..git not .git it was depending on
<ahasenack> i.e., they assume they are in a devel environment
<cpaelzer> ahasenack: yes I've seen the same
<rbasak> cpaelzer: "git ubuntu build" would then round-trip it correctly
<cpaelzer> I can work around it, but perception wise loosing the ability to dpkg-buildpackage out of a git-ubuntu checkout is a loss for me
<ahasenack> specially since git ubuntu build was almost removed from the snap
<cpaelzer> and I don't want it back :-)
<cpaelzer> I want the normal paths to work
<rbasak> cpaelzer: I don't see any workaround that doesn't result in some source package I could construct that would then break even with a fully implemented "git ubuntu build".
<rbasak> cpaelzer: can you convince upstream to stop shipping .git in their release?
<rbasak> cpaelzer: or configure dpkg-buildpackage to use -I..git, assuming that works?
<ahasenack> how does gbp or dgit import such a package?
<ahasenack> (obvious question)
<rbasak> I assume they drop the .git
<rbasak> Which is fine if you're the package maintainer, because you're in a position to fix your build if dropping .git causes a problem
<rbasak> But git-ubuntu doesn't have that luxury
<ahasenack> isn't it more surprising to fine a ..git directory?
<ahasenack> find
<rbasak> It's more surprising to have a build from "git ubuntu build" fail when it succeeds otherwise from the archive.
<ahasenack> hm, no, git ubuntu build has many bugs :)
<ahasenack> it's surprising when it works ;)
<ahasenack> unless you mean a future git ubuntu build
<rbasak> A fully implemented "git ubuntu build" with bugs fixed :)
<rbasak> Yes
<rbasak> I'm avoiding having the import broken by design
<ahasenack> and these are not going to be addressed soon
<ahasenack> the build bugs
<rbasak> Very few packages even have a .git AFAIK
<ahasenack> cpaelzer: qemu_4.2.orig.tar.xz does not have a .git
<ahasenack> is it a new upstream version that has it?
<rbasak> It is a new development that .git is found in an upload that isn't the main .git repository
<cpaelzer> no new versions are already good
<cpaelzer> it was Bionics 2.11 that has the issue
<ahasenack> qemu_2.11+dfsg.orig.tar.xz has it in a subdirectory,
<ahasenack> $ find . -name .git
<ahasenack> ./ui/keycodemapdb/.git
<ahasenack> is that it?
<rbasak> That's it
<cpaelzer> yep
<cpaelzer> as I said I can work around it
<cpaelzer> I was mostly wondering why it now shows up
<cpaelzer> but it seems we can only decide to break some or some oter packages
<cpaelzer> then being correct on import seems to be the better choice and we can keep things as-is
<rbasak> Thanks
<rbasak> cpaelzer: so on the other thing
<rbasak> The qemu reimport didn't adopt your latest upload tags
<rbasak> AFAICT, it's because of the empty directory thing
<rbasak> http://paste.ubuntu.com/p/FVnHFDymV4/ is the difference between the import and the upload tag
<cpaelzer> rbasak: yes I have seen that it didn't adopt my history
<cpaelzer> rbasak: the old packaging around roms was very bad
<rbasak> Is that different to before?
<cpaelzer> rbasak: that is why I went some lengths to clean it up
<cpaelzer> also mjt did on the debian side improve rom handling
<rbasak> cpaelzer: does this mismatch any of your expectations from the reimport?
<cpaelzer> rbasak: consider anything starting with roms/ <Eoan as "probably awkward"
<cpaelzer> rbasak: I'd be ok wit hthe re-import as-is
<rbasak> OK thanks
<rbasak> So we got some talking points around edge cases but so far the reimports are "expected behaviour" then
<rbasak> Please keep an eye out for anything else :)
<cpaelzer> will do
<ackk> xnox thanks
<ackk> sil2100, hi, around?
<sil2100> ackk: hey! Yeah, I'm aroundish now
<ackk> sil2100, hi, could you take a look at https://bugs.launchpad.net/ubuntu/+source/maas/+bug/1877973 when you have time? it's not urgent, though
<ubottu> Launchpad bug 1877973 in maas (Ubuntu) "RM request - removal from archive" [Undecided,Triaged]
<sil2100> ackk: ok, looking in a few moments o/
<ackk> sil2100, thanks!
<smoser> ahasenack: can you do an import of squashfs-tools-ng
<ahasenack> smoser: importing
<ahasenack> smoser: done
<smoser> gracias.
<gpiccoli> vorlon, xnox - do you know exactly why Ubuntu uses "wait-for-root" as its initramfs approach to..wait for root? Debian has no mention of it...
<gpiccoli> instead, Debian relies on script-looping on local stage, which for me, makes sense (and would allow me to fix an issue I'm working hehe)
<gpiccoli> Tnx in advance
<vorlon> gpiccoli: because it makes the boot faster instead of having to wait for udev settle of random events
<vorlon> on systems with significant numbers of unrelated disks
<vorlon> what is your case where you need to loop?
<gpiccoli> vorlon, thanks! My case is a crypto volume on top of raid1 - currently it does not work. Reason is that cryptroot fails on local-top and panics to shell
<vorlon> well, that's surprising to me
<gpiccoli> sorry vorlon, I express myselg in an incomplete way hehe
<vorlon> because both raid and crypto are meant to be udev-activated, and self-assemble with no need to loop in the main script
<gpiccoli> It works! The issue is if a raid1 member is removed
<vorlon> ah
<gpiccoli> hehe my bad!!
<gpiccoli> my idea to fix was to allow cryptroot to fail gently, and let the "xnox's poor man last resort" mdadm script on local-block to start the md array with a missing member...
<gpiccoli> then cryptroot (also in local-block) would take over and decrypt the volume
<gpiccoli> that..relies on the man page idea of local-block, the it loops
<vorlon> so the issue then is that you have both mdadm and cryptroot hooks that you want to be able to interact with the console?
<vorlon> why do we not in general allow mdadm arrays to be assembled in degraded mode by default?
<gpiccoli> no console involved, I want a "broken" raid1 array (or any mirroring) to be able to mount and continue the boot
<vorlon> ok
<gpiccoli> it's an option vorlon
<vorlon> alright
<gpiccoli> to allow the degraded by default, without spinning on local-block script
<vorlon> if it's an option, and it's enabled, then I think that ought to be handled inline by the udev rules and not depend on falling through to an initramfs script?
<vorlon> xnox: ?
<gpiccoli> vorlon, again my bad english! It's a design option, that I could work
<gpiccoli> It's not currently an option!
<vorlon> ah
<gpiccoli> Desculpe vorlon =)
<vorlon> well, it's possible that not assembling degraded arrays by default is a deliberate design decision also, but I don't remember
<gpiccoli> currently, mdadm tries for 2/3*ROOTDELAY iterations before giving up and degrade-assembly
<vorlon> we should at least ensure that the default behavior between initrd and rootfs is similar
<gpiccoli> I geuss this is what is currently doing, keeping the consistency
<gpiccoli> *guess
<gpiccoli> vorlon, the problem that I see with wait-for-root is that it seems to just care with udev, it doesn't give a chance to re-running scripts on local-block
<gpiccoli> how about if we do partial waits for root, allowing local-block scripts to re-run in between,
<gpiccoli> accouting the total time to not exceeds ROOTDELAY ?
<gpiccoli> *accounting
<vorlon> gpiccoli: that sounds plausible
<gpiccoli> great vorlon, I'll try to work something, let's see xnox opinion also about mdadm default to degrade option hehe
<The_LoudSpeaker> Hey! I have asked the OP to provide requested details on the bug report. Can anyone else also test this? https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1877553
<ubottu> Launchpad bug 1877553 in gnome-shell (Ubuntu) "wifi gets automatically disabled when screen is locked and can be enabled only after a reboot." [Undecided,Incomplete]
<xnox> gpiccoli:  vorlon: the intention is to use udev and assemble all the things, failing that there is a loop to interate things, and failing that there are fail hooks.
<xnox> gpiccoli:  vorlon: it is possible, that when we have disigned and implemented the loop + eventual fallbacks, that didn't get integrated into ubuntu properly. As we had still the remains of "just udev activate everything"
<vorlon> xnox: so what is the intended /outcome/ if a raid array is missing members but can be assembled in degraded mode?
<gpiccoli> I can say this works! ^
<xnox> gpiccoli:  vorlon: loop, loop, loop, start degraded, loop, loop, loop
<vorlon> what's the loop loop loop?
<vorlon> after starting degraded
<xnox> i.e. start it degraded, whilst there are still some loops available to assemble things on top of it.
<xnox> vorlon:  the loop that interates in the initramfs, trying to assemble/start/find rootfs
<gpiccoli> but only works due to a hack I found (from Ben Hutchings) in initramfs-tools
<vorlon> why does that require looping instead of udev?
<vorlon> xnox: we've basically disabled the loop part of initramfs-tools since forever in Ubuntu
<xnox> vorlon:  because we don't have systemd, such that udev can start systemd timer units that assemble things degraded after a delay.
<xnox> vorlon:  it's not the old loop part, but a new block-disk loop only.
<vorlon> xnox: however, assembling the array degraded should trigger dependent udev events with no further looping required
<xnox> which uses udev
<xnox> vorlon:  correct. and that's what i expect to happen. Cause after start degraded, that block loop thing calls udevadm trigger/settle, and try any futher hooks.
<xnox> gpiccoli:  i guess the question is => does that work on debian? degraded mdadm+crypto?
<vorlon> udevadm trigger/settle, instead of wait-for-root
<xnox> i think so.
<xnox> vorlon:  because that new block-loop, is to support really weird shit like mixing encrypted & non-encrypted PVs in VG, where things jump layers.
<xnox> vorlon:  and like nested VGs
<gpiccoli> xnox, I don't expect that to work currently due to the first limitation on cryptroot script - it fails on local-top and drops to a shell. With my change, it should work in debian (I can test), but not on ubuntu
<vorlon> hmm
<gpiccoli> because we don't loop in local-block, instead we use wait-for-root and give-up after a while
<xnox> gpiccoli:  ack. i think our crypto script is better than debian's true.
<gpiccoli> no, the script is the same hehe
<xnox> gpiccoli:  i think you want to open a bug report with details.
<gpiccoli> it fails in both currently hehe
<xnox> gpiccoli:  against cryptsetup mdadm initramfs-tools
<xnox> and we can check what's missing.
<gpiccoli> right, I'll do that and propose my change there
<xnox> nesting is hard.
<xnox> i thought we did well to support "normal stackings" and "degraded stuff" sensibly, but we might be missing some stacks orderings.
<gpiccoli> agreed
<xnox> i.e. i think 2 LUKS => assembled into RAID1 end up degraded more often than they should.
<gpiccoli> tnx xnox and vorlon =)
#ubuntu-devel 2020-05-15
<ali1234> xnox: i'm confused by openssl SECLEVEL patches in ubuntu https://launchpad.net/ubuntu/+source/openssl/1.1.1f-1ubuntu1
<ali1234> specifically i don't understand why you: Revert "Enable system default config to enforce TLS1.2 as a minimum" & "Increase default security level from 1 to 2".
<ali1234> but then later on re-apply the same changes
<ali1234> it seems to me that you end up exactly where you started, with default SECLEVEL=2 and all the problems that causes
<ali1234> also it seems that ubuntu openssl is even more strict than the version in buster, and i don't understand why
<ali1234> and i'm not sure if it is even intentional
<ali1234> hmm ignore that last bit, i reproduced it with debian 10 as well
<jamespage> ddstreet: the rmq changes in groovy have been merged and uploaded to debian unstable so a re-sync should be possible
<ackk> juliank, hi, I reworked by branch for the maas transitional package based on your input. I created a new MP since we want this in focal now, as maas is gone from the archive in groovy. Could you please take a look when you have time: https://code.launchpad.net/~ack/ubuntu/+source/maas/+git/maas/+merge/384013 ?
<ackk> juliank, I linked the SRU bug as well, please let me know if that needs tweaking as I don't know the process well
<juliank> ackk: ack
<FourDollars> Could anyone help me to upload https://bugs.launchpad.net/bugs/1875797?
<ubottu> Launchpad bug 1875797 in OEM Priority Project "[MIR] oem-somerville-melisa-meta" [High,In progress]
<ddstreet> jamespage i'm confused about rabbitmq-server.service Wants epmd@.socket...it's not a template socket (or service)...?
<ddstreet> i see lp #1808766 but i still don't get what it's doing
<ubottu> Launchpad bug 1808766 in rabbitmq-server (Ubuntu) "fails to start" [Undecided,Fix released] https://launchpad.net/bugs/1808766
<ddstreet> or trying to do
<paride> sil2100, Laney, xnox, bdmurray, we have a problem with a xenial update: https://bugs.launchpad.net/ubuntu/+source/json-c/+bug/1878723
<ubottu> Launchpad bug 1878723 in json-c (Ubuntu) "Kernel panic when used with upstart after 0.11-4ubuntu2.1 update" [Critical,Confirmed]
<paride> this is taking down xenial instances with unattended-upgrades enabled
<Laney> paride: doh, but I can't really help pull the update
<Laney> leosilva: ubuntu-archive ^-
<ddstreet> ouch, that's bad
 * apw looks at the panic removal request
<apw> paride, i assume this was not happening before the json-c update, so it is that we are looking to remove
<paride> apw, that's my understanding too
<Laney> if it's that bad an emergency chmod might be warranted - thoughts?
<apw> Laney, i am unclear if that is significantly quicker to propogate other than our mirrors
<cjwatson> It doesn't help with propagation, but lots of people use our mirrors
<Laney> It'll help people who use the Canoncial mirrors
<apw> cjwatson, and we would not remove it in that case ?
<cjwatson> https://wiki.canonical.com/UbuntuEngineering/DealingWithCrisis#Limitation
<Laney> You would, but this would mitigate immediately
<cjwatson> ^- that
<Laney> yes, that wiki page
<cjwatson> That procedure has been tried and updated recently
<wgrant> At least it doesn't break unattended-upgrades, so as long as we get the new update out before people reboot we're not too bad.
<chrisccoulson> hi, what's the status of this right now?
<wgrant> So it seems of high priority to push a revert with greater version.
<apw> ok removed; and the previous version is now copied back in
<cjwatson> apw: Thanks, as long as we know that isn't the end of the relatively urgent story (as wgrant says)
<apw> cjwatson, yep we know that thanks
<wgrant> Is it just xenial?
<apw> i have only been told about xenial
<wgrant> Until we hear otherwise, let's prep reverts to -security of everything in that USN?
<cjwatson> It was only issued to xenial and newer, and >= bionic doesn't have upstart
<wgrant> Ah yes, no pre-xenial indeed.
<apw> wgrant, how do we identify the USN
<cjwatson> https://usn.ubuntu.com/4360-1/
<wgrant> https://usn.ubuntu.com/4360-1/
<cjwatson> Ah, ESM
<wgrant> Ah yes
<cjwatson> Conceivable it affects that too ...
<wgrant> That's annoying, technically does need security team then
<cjwatson> Is anyone in a position to try?
<chrisccoulson> Hi :)
<cjwatson> Before it takes out half our DC or something
<rodarvus> folks, I'm from AWS - joining to cooperate on the efforts
<wgrant> I have a VM I can sacrifice.
<chrisccoulson> cjwatson, wgrant, I'm just going to build 0.11-4ubuntu2 as 0.11-4ubuntu2.2 in the security PPA and drop these changes.
<rodarvus> to address a comment from wgrant above - we have actually heard from customers that this issue does indeed affect unattended-upgrades.
<cjwatson> chrisccoulson: makes sense
<wgrant> rodarvus: I mean rather that it shouldn't break unattended-upgrades from upgrading to a fixed version, just that if someone reboots in between they're in trouble.
<rodarvus> right.
<chrisccoulson> I don't think it's worth trying to fix the existing patches on a friday afternoon
<wgrant> chrisccoulson: Please do. Ping me or Colin if there's any blocker at all.
<wgrant> Absolutely.
<wgrant> The vulnerability is way less bad than the breakage.
<wgrant> Straight revert.
<apw> chrisccoulson, if you need anything ping away
<rodarvus> chrisccoulson: amazing. that sounds like the best way forward to me also. do you have any estimates on how long until the build complets and propagates to the security PPA?
<xnox> ali1234: Ubuntu is more strict. I should publish my blog post about it. We enforce minimum protocol versions without configs.
<wgrant> Huh
<wgrant> Was it published to ESM?
<wgrant> I don't see it on my trusty systems
<AsciiWolf> kenvandine, hi, it looks like that the Snap Store "_Permissions" string translations are not synced from Launchpad, see: https://bugs.launchpad.net/snap-store/+bug/1878672
<ubottu> Launchpad bug 1878672 in snap-store ""_Permissions" string not translated" [Undecided,New]
<ivoks> wgrant: seems bionic is impacted too
<wgrant> ivoks: We'd like to know what impact people are seeing.
<wgrant> Since it can't break upstart there because upstart isn't used for boot.
<ivoks> wgrant: aws just reported that customers are complaining for bionic too now
<xnox> wgrant: *cough*
<wgrant> xnox: ... oh?
<wgrant> xnox: What dirty secrets do you hide!?
<xnox> We do not re-exec from upstart to systemd
<wgrant> xnox: You mean during an upgrade, pre-reboot?
<wgrant> Breaking that is deeply unfortunate, but not world-burningly critical.
<cjwatson> Did we use upstart for user sessions in xenial?  I forget
<xnox> wgrant:  revert libjson-c update obviously. As far as i can remember on package upgrades that upstart uses, we trigger stateful re-exec of init & all user-session upstart inits.
<philroche> We have reports that this is affecting libjson-c3 version 0.12.1-1.3ubuntu0.1 in bionic too. See SF case # 00278097
<wgrant> xnox: ... on bionic?
<xnox> and clearly that's crashing at serialization, or deserialization
<wgrant> Oh or you mean it will break the system at upgrade on xenial, not at reboot?
<wgrant> philroche: "affecting" is very vague.
<wgrant> We'd really really really appreciate specifics.
<xnox> wgrant: upstart is not published in bionic; but it can be still installed (xenial version). And i bet the maintainer hooks in libjson-c3 still try to restart it.
<xnox> wgrant:  thus i'd check that libjson-c3 stops trying to initrctl daemon-reexec or whatever it was called
<wgrant> xnox: Right, but breaking something that isn't /sbin/init is approximately one thousand times less critical than the situation on xenial, isn't it?
<philroche> wgrant: it is vague :( Direct quote "Ubuntu will need to block the Bionic version as well, as it is also affected 0.12.1-1.3ubuntu0.1"
<xnox> wgrant:  if they have upstart still installed, it means they are forcing to still use it.
<wgrant> Ah
<xnox> as pid 1
<xnox> wgrant:  and upstart has support to be used inside chroots
<cjwatson> philroche: The thing to sort out is whether that's just somebody observing that it's from the same USN, or whether it causes real issues (and if so what)
<philroche> cjwatson: ack. I will get clarificaiton
<ddstreet> rodarvus are you able to share details about how it affects bionic?
<xnox> wgrant:  telinit u || : is done by json-c in xenial; but not bionic.
<wgrant> Aha
<xnox> wgrant:  so it almost feels like "affects bionic" => where someone has xenial enabled in sources, and force installed upstart?
<wgrant> In which case they get to keep both pieces for the next two hours?
<ddstreet> philroche cjwatson latest report from AWS is to ignore the 'affects bionic' comment.  they are doing more testing before being sure about that.
<wgrant> Unless anyone strenuously disagrees.
<philroche> ddstreet: ack
<xnox> wgrant:  should i be looking into fixing up upstart stateful re-exec here?
<xnox> and or rebuilding upstart, to see the testsuite emit fire balls
<rodarvus> ddstreet: we don't have access to customer instances, so unfortunately all we have is a number of customer tickets. I (personally) don't have any indication that is happened in bionic.
<xnox> wgrant:  rodarvus: ddstreet: at most, i'd expect dist-upgrades failing.
<xnox> xenial => bionic, where one opted to stay on upstart in xenial.
<wgrant> xnox: right, thanks for confirming.
<AsciiWolf> kenvandine, btw. there is another issue that was already fixed in upstream and it would be great if it could also be fixed in Snap Store (and deb gnome-software): https://bugs.launchpad.net/snap-store/+bug/1750818
<ubottu> Launchpad bug 1750818 in gnome-software (Ubuntu) "Already installed deb packages not showing as installed when opened" [Low,Triaged]
<AsciiWolf> (the fix is easy to backport)
<wgrant> So, now that reverts are in progress, and it seems likely that it is only properly fatal to xenial...
<wgrant> We should try to work out the various xenial scenarios
<wgrant> We have reports of OOMkills after upgrade and before reboot
<wgrant> We have reports of panics on reboot
<wgrant> And we have reports of OOMkills some time after reboot
<wgrant> Oh, I guess the second case may be the third, just soon after boot.
<wgrant> At least that means that booting and quickly upgrading should avert doom. The system isn't entirely unbootable.
<cjwatson> Mirror triggering is disabled for the time being to avoid accidents
<cjwatson> (from the master)
<philroche> Update RE bionic "So bionic doesn't get the crash on init, and no kernel panic. But I am testing that the bug is still present in Bionic, just not triggered, as there is no upstart in Bionic. I'm looking to test the bug"
<wgrant> philroche: Thanks for confimring.
#ubuntu-devel 2020-05-17
<cgi> when distributing a deb file, I want to compile my c code with single executables optimized for multiple CPU architectures - how can i do this? where can i get help for this?
<rbasak> cgi: we don't do this in Ubuntu itself, and that's what this channel is for discussion about.
<rbasak> If you want to make Unix executables with that feature then that's not really an Ubuntu-specific thing
<rbasak> Try stackoverflow maybe?
