#ubuntu-devel 2005-07-04
* ..[topic/#ubuntu-devel:ogra] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | BugDay !! June 29 2005 in #ubuntu-bugs join in, go squash !
<Omni> could anyone help me with a prism2 usb wifi adapter and hostap?
<KaiL_> wrong channel, that's someting for #ubuntu
<KaiL_> +h
<Omni> sorry
<ogra> seb128, join #ubuntu-bugs, its for you :)
<seb128> ogra: what is for me?
<ogra>  #ubuntu-bugs :) should fell like home ;)
<seb128> a bug squash without notice on the day where bugzilla.gnome.org box is beeing moved? no thanks 
<ogra> feel even
<tseng> can someone remind me what UVF really means to me as a maintainer
<ogra> tseng, no new upstream version
<tseng> it would be sortof crap if I couldnt put in the next beagle
<tseng> etc
<ogra> tseng, only with approval
<tseng> I see.
<\sh> hmmm....can someone translate this for me: http://mnm.uib.es/gallir/posts/2005/06/24/343/
<tseng> i do not like the stucture of Debian
<tseng> the second sentence is harder :P
<uniq> Too much democracy is sometimes bleak and it does not allow you to continue advancing.
<uniq> says. babelfish.altavista.com
<tseng> that sounds close
<\sh> yes...but the comments are not making any sense to me ;)
<restrex> sh me :)
<restrex> \sh what do you want to know?
<azeem> \sh: probably he says you have not much knowledge on how Debian works, if you think it's a democrazy
<\sh> hmmm..i should learn spanish 
<\sh> so i can answer him ;)
<restrex> \sh aprende pues ;)
<restrex> well
<\sh> hehe..I was surprised to get many hits from this site
<restrex> there appears that somebody called Stephan Hermann
<restrex> said that he doesn't like debian estructure
<\sh> restrex: thx :)
<ogra> \sh, he qoutes this: ...nd it's also a matter why I don't like the Debian structure. Too much of democracy is sometimes hopeless and stops you from going further.
<\sh> ogra: jajaja ;) I know what I wrote ;)
<restrex> there appears that somebody called Stephan Hermann said that he doesn't like debian estructure and said that it's so much democracy that sometimes doesn't allow you to advance
<restrex> :)
<restrex> sorry mi english \sh 
<restrex> :p
<restrex> some comments are negative :)
<ogra> restrex, which is very much out of context :) since he compares debian "democracy" to ubuntu "dictatorship"
<ogra> this qoute doesnt credit that.... sadly
<restrex> hmm the guy who posted says that ubuntu exits 'cause exits debian, and that kind of comments criticing debian it's not valid (im only translating him idea)
<restrex> are not valid
<daniels> and, indeed, ubuntu would not exist without debian
<ogra> sure
<\sh> and I never said, that debian is evil...(as one of my comments on my blog tried to say)...so I put it right in another article...anyways
<ajmitch> the MOTUs would have a very hard time without debian, especially
<\sh> I should drink some beer with martin in oldenburg...
<restrex> \sh ye, he only wanted to critique you, 'cause there aren't so good argumentents, only a: "ubuntu exists 'cause exits debian"
<restrex> that's only a debian fan comment, you have to understand that :)
<restrex> on the commnets there are people that don't think like him :)
* ajmitch is a debian fan also, but doesn't talk like that :)
* \sh is going to be PC: \sh 's a fan of debian, redhat, suse, mandriva, sun, ubuntu, gentoo, archlinux, damnsmalllinux, damnbiglinux, livelinux,offlinelinux, whateverlinux ;)
<\sh> anylinux i forgot? well, yes, goingtobedlinux :)
<Mithrandir> what about opensolaris?
<restrex> wuahahha
<\sh> so g'night :)
<Mithrandir> \sh: sleep tight. :-)
<\sh> Mithrandir: I'm a joerg schiling fan as well ,-)
<Mithrandir> \sh: sick bastard. :-)
<restrex> :o
<\sh> Mithrandir: hahaha
<\sh> Mithrandir: sad, that bsdi doesn't exist anymore...:(
<\sh> so...off to bed
<ajmitch> night \sh 
<Burgundavia> mdz, who would I talk to about wiki improvements?
<ogra> Burgundavia, hno73
<Burgundavia> ok
<Burgundavia> mdz, nev ind
<ogra> Burgundavia, there is a feature request wikipage
<Burgundavia> ogra, yes
<Burgundavia> ogra, I was talking with upstream moin about a feature
<ogra> use it :)
<Burgundavia> they liked it
<ogra> ah
<Burgundavia> said it would take about an hour of dev time
<Burgundavia> I was wondering who to whinge to about paying that person (a moin dev) to do it
<doko> ogra: about the bug squashing party ... there are still about 15 C++ libs not yet converted / buildable on breezy and about 500 reverse depends on libstdc++5 without an explicite build dependency on g++-3.3 or libstdc++5-3.4-dev.  Many of them are packages with patches in Debian, which are not applied in Ubuntu. The rest needs to be sorted out to C++ problem/xorg reorg problem/dpkg-architecture problem. I don't know if fixes for thes
<doko> e kind of bugs are sexy enough, but you may want to propose them
<mdke> doko, he just went to bed i think
<lamont__> daniels: ping
* infinity looks at the 1000 new failed build logs in his INBOX and grunts at doko.
<lamont__> #0  0x083de64c in a52_free ()
<lamont__> #1  0x083dd5cd in a52_block ()
<lamont__> #2  0x081287a3 in a52_fillbuff ()
* lamont__ hates audio
* toresbe sings in front of lamont__ 
* lamont__ wonders if there are known bugs in AD1981B OSS + mplayer
<mpt> jdub: busy?
<fabbione> morning
<minghua> Hi, I am wondering how unstable is synchronized with breezy right now
<minghua> since the freetype 2.1.10-1 in unstable is broken
<minghua> see debian bug #314385 and #316031
<minghua> breezy should stick to freetype 2.1.7
<minghua> and wait for this to be sorted out
<daniels> lamont: pong, ish
<daniels> lamont: my laptop's hard drive blew up today, so I'm kind of limited
<lamont> daniels: heh
<lamont> ouch
<daniels> and got to remember how to crimp cat5
<daniels> it's about a 20m run from my desktop to the AP
<lamont> was wondering if you could (in email, even) rattle off the list of packages that have been split out of xorg
<minghua> hmm, maybe it should be "how breezy is synced with unstable"?  anyway, I think everyone understands me
<daniels> lamont: in email, no
<daniels> lamont: irc, yes (bear in mind my email lives on my laptop ...)
<lamont> daniels: here is fine to, or in /msg
<daniels> lamont: x11proto-*-dev, libxau, libxdmcp, libice, libsm, libx11, libxext
<daniels> libxfixes, libxdamage and libxcomposite are next on my hit list
<daniels> oh, also xtrans
<daniels> and xterm
<daniels> and xfonts-core :)
<lamont> daniels: plan is to queue those ahead of xorg... and then pester you about what we really want to do about the ones that are non-PIC-in-shlib
<daniels> lamont: hrm
<daniels> surely libtool should take care of all this
<lamont> minghua: breezy has  freetype_2.1.7-2.4ubuntu1, so manual effort will be required to get the debian version.
<lamont> daniels: choices are (1) provide a .so, (2) provide a _pic.a, (3) don't link that lib
<lamont> in at least some cases, it's really (1) but there's a missing build-dep
<minghua> lamont: yes I saw that breezy is fine right now, I am just here to raise the alarm
<lamont> er, "some cases" == some cases across the entire archive, not necessarily specifically xorg
<minghua> lamont: I hope the developers are already aware of this
<lamont> minghua: whoever does the merge will hopefully note that there are RC bugs in the debian version before they upload... if those debian bugs are RC, then they're already in ubuntu
<lamont> er, in the bts, that is.
<lamont> right then.  sleep
<daniels> lamont: we already provide a .so
<jdub> yo lamont 
<lamont> daniels: coolness
<lamont> jdub: sup?  she's gonna kill me if I don't leave soon
<minghua> lamont: Okay, there is a RC bug, so things should be fine.  Thanks for the explanation.
<mxpxpod> does anyone else get a relocation error when using the workspace switcher applet on ppc in breezy?
<lamont> jdub: /msg or something - I'll probably wander past again in about 60-120 minutes or so
<jdub> lamont: just saying yo :)
<lamont-away> jdub: heh. yo back at ya. :-)
<lamont-away> and hello to the nice lady, too
<jdub> lamont-away: she sends hugs :)
* lamont-away sleeps
<Burgundavia> salut jdub 
<jdub> yo
<jdub> much yo
<whiprush> yo jdub 
<jdub> YO!
<Treenaks> yo all
<mxpxpod> oy
<whiprush> jdub: I take it you maintain planet ubuntu?
<jdub> yeah
<jdub> though i don't have shell access to it
<jdub> which can be annoying at times
<whiprush> can I get syndicated? I have some cool ubuntu stuff I'd like to blog ... and since I'm blogging about ubuntu 90% of the time anyway ...
<jdub> whiprush: are you a member yet? (you should be)
<whiprush> yep
<jdub> ahr!
<jdub> dude, why didn't you say? :)
<whiprush> heh.
<jdub> i'll add you now, but it has to wait on elmo love to update
<whiprush> <3
<whiprush> I've been kind of out of the loop, been doing lots of loco stuff locally.
<nails> daniels, heya, decided to stalk you for an X question
<nails> daniels, will R7 use regular pathnames - /usr/bin etc?
<jdub> whiprush: added
<jdub> elmo: please update planet -> can we work out something better for this?
<whiprush> woo, thx.
<daniels> nails: yeah, fo'sho
<daniels> nails: no more /usr/X11R6
<nails> sweet. 
<nails> sun will melt.
<daniels> heh
<daniels> well, we already started that with XF86Config-4 -> xorg.conf
<daniels> the compromise was leaving it in /etc/X11
<robitaille> jdub: for planet.u.c:   http://www3.telus.net/robitaille/hackergotchi.png
<nails> daniels, ok, just as long as you make the new config file use m4
<nails> ;^)
<daniels> nails: usability++, yo
<jsgotangco> whiprush: hey long time no see
<whiprush> hey man
<jsgotangco> what's keeping you busy other than the "Ubuntu loco" stuff i've been readin g in the log
<whiprush> sheer ineptitude.
<jsgotangco> hahaha
<jsgotangco> go blam
<jsgotangco> it just died but the notification icon still lives
<whiprush> lesson #1 from UDU, don't say "oh sure, I'll help" when you don't have the time.
<jsgotangco> it doesn't eat up that much time to help out (unless you're really swamped with real work)
<whiprush> I plan on doing the bug day tomorrow (tomorrow for me), and starting to file down my todo a bit. Just been procastinating.
* jsgotangco hugs his emacs planner for keeping him on track
<whiprush> on the plus side our LoCo's been growing. Up top over 20 people now.
<jsgotangco> wow that's news
<whiprush> It's kind of odd, I've ran into three C/GTK dudes in the past few weeks that are just "looking for a way to help."
<jsgotangco> oh i know the feeling, i've encoutered those types recently
<whiprush> So we're starting to organize activities around that. Hopefully get funding from my University to get us all to a GNOME thing in NY or Boston where I can point them to mentors or something.
<jsgotangco> at least you have access to potential funding...
<whiprush> heh
<whiprush> We've been slowly converting professors over to Ubuntu for their research work. Hopefully they'll include Ubuntu in their biblios.
<whiprush> All these math people seem to seek out linux for fortran compilers and whatnot, they're kind of ripe targets.
<whiprush> jsgotangco: and how are things in the phillipines?
<jsgotangco> major bummer dude, its like Watergate here in the political side
<whiprush> Heh, I meant on the Ubuntu front.
<jsgotangco> wiretapped materials on the president heh
<jsgotangco> heh
<whiprush> heh
<jsgotangco> oh we had our loco running and will be sponsoring software freedom day
<whiprush> good good
<whiprush> we're doing an installfest on SFD here.
<jsgotangco> on the docteam side, we'll be starting our regular meeting tommorow at 14UTC
<whiprush> good good.
<jsgotangco> that should end those CAN! CANNOT! threads on the list
<whiprush> heh
<whiprush> You guys did the wiki transition right? Your team?
<jsgotangco> well not really, it was henrik's project he's a canonical guy but some people helped out on the transition scripts
<whiprush> cool
<ajmitch> hey whiprush, jsgotangco 
<jsgotangco> i don't really mess up with the former wiki but the moin wiki now is actually great
<jsgotangco> it still has some bugs though
<jsgotangco> ajmitch: hey
<whiprush> hey aj
<jsgotangco> (some people still like mediawiki though)
* jsgotangco is a mediawiki closet practitioner
<whiprush> I'm a mediawiki fan, but at this stage I'd settle for "don't change it again please."
<jsgotangco> yeah moin is actually great
* squinn joins jsgotangco and whiprush 
* Burgundavia grumbles at gimp
* Burgundavia grumbles at fspot
<Burgundavia> fspot will not import the bloody image
<Burgundavia> gah
<pitti> Morning
<marilize> morning
* infinity grumbles about the old xlibmesa-glu in the archive that needs to be removed.
<infinity> elmo / kamion ---^
<\sh> can someone remove gmetadom_0.2.2-3ubuntu2 from the buildd asap? there is an error inside :(
<infinity> Too late, dude, it's already installed.
<\sh> *grmpf*
<\sh> anyways...preparing ubuntu3
<infinity> Alright, I re-froze the two things that were supposed to build against it, so no harm done, really.
<\sh> i'm too tired and my eyes playing games with me :( annoying this
<\sh> I need some holidays
<infinity> Oo, oo, me too!  Send me some!
<daniels> at that price, I'll take two
<\sh> beginning of september I'll take 2 weeks off...but I need to think about the place where I want to stay...
<\sh> ivoks: what r u doing from the 2nd of September +2 weeks? I think I need to visit croatia and need a place to sleep ;)
<ivoks> :)
<ivoks> \sh: 2 weeks? :)
<ivoks> i think i'll be able to manage something...
<\sh> ivoks: i don't really know...depends on my money ;)
<\sh> one week minimum :)
<ivoks> so... what's your motivation to come here? :)
<\sh> ivoks: holiday :) 
<\sh> ivoks: u know this stuff: relaxing, reading, looking out for a new Mrs. \sh
<\sh> forget the new Mrs. \sh
<ivoks> :)
<\sh> coffee first...
<ivoks> well, i'm in continental part of croatia
<cameron> hey
<cameron> the ubuntu laptop team is in this channel, correct?
<pitti_> Hi cameron 
<cameron> i am thinking about buying a powerbook, and i am wondering how compatable they are with ubuntu
<cameron> what advice would you have for me?
<cameron> hi pitti
<cameron> hi pitti_ *
<pitti_> cameron: #ubuntu
<cameron> so sorry.. good day!
<pitti_> cameron: well, many of us are using pbs, I'm using an iBook
<cameron> is ther any of the hardware that is incompatable?
<pitti_> cameron: the airport extreme doesn't work, but the rest works pretty well
<cameron> i was planning on usin\g an orinoco anyway
<fabbione> daniels: can we please get the xterm default colors back?
<daniels> fabbione: can you what the what?
<fabbione> daniels: xterm default colors are white fg and black bg
<cameron> pitti, thanks for your help
<fabbione> the latest xterm is fg black on greish bg
<pitti> fabbione: btw, since breezy's 2.6.10 kernel has a lot of outstanding vulns, shall we demote it to universe?
<daniels> er, xterm default colours are black fg, white bg
<fabbione> pitti: we can just remove it
<fabbione> pitti: completely
<pitti> even better
<fabbione> daniels: and get -rv to work again.. :)
<fabbione> daniels: either one or the other ;)
<daniels> fabbione: will check it out; -fg white -bg black should make you happy in the meantime
<fabbione> daniels: yeah i did that already... :)
<daniels> but yeah, upstream's default colours have been like that forever
<fabbione> not in our xterm...
<fabbione> i used to execute just xterm and get white fg and black bg
<fabbione> the net is going to be highly unstable soon
<pitti> Hey chmj, good morning
<chmj> good morning pitti 
<pitti> chmj: could you check whether we can sync wget? the new debian version has security fixes
<chmj> i already asked elmo for a sync 
<pitti> ah, thanks
<infinity> Didn't ours have aun updated translation or two?
<infinity> s/aun/an/
<pitti> infinity: that should have been the translation from upstream, wasn't it?
<infinity> Oh, yes.  It was.  Didn't realise that Debian had a new upstream version finally.
<infinity> In that case, nevermind. :)
<doko> infinity: the last batch of uploads reduced the libstdc++5 rdepends from 880 to 530. Now we know which packages need manual fixing.
<infinity> doko : I noticed.
<\sh> doko: cxx stuff?
<doko> \sh: yes
<\sh> 530 packs?
<infinity> 530 rdeps.  Some may be from the same source packages.  Hopefully. :)
<infinity> I've got 427 on powerpc...
<infinity> That's a lot of i386-specific C++ packages... Or doko's count is old.
* \sh has 610 rdeps on stdc++5
<daniels> daniels@brainfreeze:~/Maildir% offlineimap -u Curses.Blinkenlights
<daniels> offlineimap -u Curses.Blinkenlights  159.90s user 15.23s system 3% cpu 1:36:45.33 total
<daniels> daniels@brainfreeze:~/Maildir%
<daniels> thank god for mail backups, but that wasn't quick
<doko> \sh: you are sure, you don't have old libraries installed on your system? apt-cache rdepends libstdc++5|wc -l counts 528, minus the two header lines
<elmo> chmj: I don't have any record of a sync request for you from wget
<Lathiat> elmo: pitti asked for one yesterday
<Lathiat> ah,he said he asked
<pitti> elmo: yes, I sorted that out with chmj, I asked before he uploaded ubuntu3. It can still be synced, though
<pitti> seb128: does the gstreamer polypaudio sink work for you? I get nothing but silence
<seb128> pitti: lemme try, I use alsasink atm
<Lathiat> pitti: from what i understand, its only basic
<seb128> pitti: polypaudio doesn't start ..
<pitti> Lathiat: basic what?
<Lathiat> pitti: the plugin
<Lathiat> it should work tho
<Lathiat> for basic values of workign
<pitti> Hi Kamion 
<Kamion> morning
<daniels> Kamion: g'morning
<fabbione> hey Kamion 
* Kamion sucks down a load of images
<Kamion> ogra: good grief, your bug-day mail is a bit ZIPPY the PINHEAD :-)
<ogra> heh
<ogra> was it to political ? :)
<daniels> ogra: i think he means TOTALLY RANDOM words capitalised THROUGHOUT the SENTENCE
<elmo> too ZIPPY.  ZIPPY.
<Lathiat> argh
<ogra> ah
<Lathiat> network manager sucks
<Lathiat> if i have a cable in, it refuses,no matterhow many times i forceit bac, to stick on the wireless
<daniels> elmo: at least it was zippy rather than btaf
* hunger agrees with Lathiat.
<ogra> yes it was late... i'll do better next time :)
<Lathiat> imt rying to use my ethernet temporarilyto talk to abox im setting up
<Lathiat> and its imposible
<Lathiat> furthermore
<Lathiat> i had to kill it 15 times before it stopped spawning itself
<Kamion> apt 0.6.39ubuntu1> hoorah
<Kamion> elmo: can we get the extraoverrides patch applied on the ftp-masters?
<Kamion> (er, both machines, I mean)
<hunger> Why is python2.4-numarray trying to install gcc-3.4-base?
* daniels giggles.
<daniels> Kamion: we can patch ftp-masters?
<Kamion> patch omnic < useful.patch
<daniels> Kamion: damnit man, get out of my head
<Kamion> haha
<elmo> damn, you guys are HARSH
<Kamion> elmo: we learnt from the master
<daniels> Kamion: now if only we could patch elmo
<daniels> -tuna
<daniels> -saveloys
<daniels> +vegetables
<Mithrandir> daniels: while for you it would be:
<Mithrandir> -bling
<Mithrandir> +working x
<Mithrandir> ?
<daniels> hey
<daniels> x works fine
<Lathiat> daniels: you back?
<Mithrandir> daniels: so we can patch you with bling again? :-)
<daniels> Lathiat: hm?
<daniels> Mithrandir: everyone loves bling
<Lathiat> daniels: from whereever you were hiding making people do dodgy xorg uploads for you :)
<daniels> oh, germany
<daniels> hey, I didn't ask for any of those
<Lathiat> sure but you werent there to stop them! :)
* \sh knows only the machine with the ping
<\sh> pitti: ping
<\sh> thom: ping
<pitti> \sh: boonngggggg
<\sh> pitti: https://bugzilla.ubuntu.com/show_bug.cgi?id=4679 
<ogra> pitti, it boog day ! you'll see all this dusty old stuff today :)
<pitti> \sh: I know about that, warty is still vulnerable
<\sh> pitti: ok...and a backport from hoary to warty?
<pitti> \sh: the pending warty update fixes some 20 vulns, but has a regression that needs to be sorted out first
<\sh> pitti: k thx 4 the info :)
<pitti> \sh: thanks to you guys for cleaning up :-)
<pitti> oops, I was thrown out of #u-bugs
<seb128> just curious, who has decided to do a bug day today?
<ogra> seb128, mdz, kiko and me
<seb128> k, bad choice guys
<ogra> seb128, we didnt know about the gnomeaoutage
<seb128> just picking the day where gnome.org is down
<seb128> you point that for bug triage
<seb128> and there is no way to do desktop bug triage
<seb128> yeah
<ogra> seb128, but google chache works... you just cant change gnome bugs, but read them at least
<seb128> no communication is bad
<ogra> seb128, its only the initial bugday... we'll have more of them
<seb128> somebody would have send a mail 2 days ago ...
<seb128> yeah, but still
<seb128> why keeping that private until the bug day ?
<seb128> I've read about the bug day when the topic has been changed here ...
<ogra> seb128, sorry, i planned to announce it earlier... it just didnt work, and its also a bad day for me, since i have to prepare for the edubuntu summit... we'll do better next time, for now we have at least the institution of a bug day...
<ska-fan> What's the other images in the directory with the isos for the cds that hp ships with its notebooks? HP ships the 0516 version, what are the newer versions?
<hunger> Who is working on the laptop task for breezy?
<ogra> hunger, mjg59 
<hunger> mjg59: My laptop (T43p) does not work very well. What can I do to help fix it?
<ogra> hunger, there was a announcement of a laptop testplan on the -devel mailling list... with a link to a wikipage ...
<Kamion> ska-fan: HP will be shipping newer versions
<hunger> ogra: I'll check...
<Kamion> ska-fan: we sent 20050627 to the factory for pressing on Monday
<Kamion> ska-fan: some of the older ones were a different project, that was fully integrated into Hoary
<HiddenWolf> Kamion, is it expected that they'll ship ubuntu in some volume?
<HiddenWolf> And how in the lords name did you manage to get in there? :D
<Lathiat> Kamion: 2 million hoary cds?
<seb128> rofl
<ogra> heh
<Lathiat> oh sory
<Lathiat> 20 million!!! ?
<Kamion> HiddenWolf: I believe so; I've just been doing the image production, though - I haven't been involved in discussions beyond that
<Kamion> HiddenWolf: no idea, but I'm not complaining :-)
<HiddenWolf> Kamion, rock on. :)
<HiddenWolf> But they're shipping breezy? :S
<Kamion> HiddenWolf: no, slightly modified hoary
<Kamion> mjg59's been doing a bunch of hacking for their laptops
<HiddenWolf> right, cool
<Kamion> ska-fan: I'm told the 20050516 image was sent out to magazines as a preview
<ska-fan> Kamion: Ah. So when I need one such CD, and am not getting one from HP, I just use the latest one
<ska-fan> ?
<jordi> did I read 20 million?
<Lathiat> jordi: thats what i read
<ogra> jordi, yes, someone said that
<jordi> where?
<Lathiat> jordi: and 50 thousand ;p
<HiddenWolf> Kamion, so can you say their laptops are fully supported? 
<ogra> jordi, <Kamion> ska-fan: we sent 20050627 to the factory
<Lathiat> ogra: that many what, specifically
<ogra> $$ ?
<ogra> :)
<jordi> ogra: err, that's not a quantity, but a date?
<ska-fan> that's 2005-06-27 = 1972
<ogra> hehe
<Kamion> ska-fan: well, you won't be getting one from HP *just* yet because they haven't been pressed yet - it's not HP's fault :)
<ogra> jordi, it was a joke, yes
<Kamion> ska-fan: 20050627 should be fine, though, yes
<jordi> ogra: I'm veeery slow today
<jordi> ogra: I just said on a ml that apt 0.6 verifies sigs in .debs :)
<ska-fan> Kamion: but the notebooks without windows aren't available yet, too :/
<ogra> jordi, dont worry.... blame the heat :)
<Kamion> ska-fan: I don't know anything about that
<ogra> jordi, i read debian-gtk-gnome ;)
<Kamion> Lathiat: oh, er, yes, that was a date, not a number
<jordi> ogra: ok :ppp
<ogra> :)
<azeem> and see whether ntfs is in there
<azeem> eh, sorry
<jordi> ogra: we need to chat about that presentation I'm leading with JaneW.
<fabbione> and there... new cluster crack all over the place
<ogra> jordi, have you had a look at my first proposal ? 
<jordi> ogra: for apps? yeah. It nearly matches our (LliureX) selection
<ogra> jordi, http://www.edubuntu.org/EdubuntuDesktop
<jordi> I wanted to add a few comments in the iki, but had no time last night
<ogra> i'm still looking for a easy gui backup tool.... there is absolutely nothing...
<ogra> i hoe we get a good one with the bounty....
<ogra> hope even
<seb128> fedora has alsa a bounty for this
<seb128> s/alsa/also/
<ogra> seb128, geat to hear
<ogra> great
<jordi> ogra: yeah, the SoC bounty hopefully helps
<ogra> i found uberbackup that looks quite good, but sillyness of the world, its written in realbasic...
<ogra> http://www.mooncheese.org/projects/uberbackup/
<azeem> nice name, though
<ogra> and realbasic source is binary o_O you can only see the real source in the realbasic editor.... 
<jordi> my mom just told me my grandfather is about to die. Better like this... :/
<ogra> :(
<fabbione> Kamion: i need a fast breefing on d-i if you have time
<jordi> wow, realbasic is braindead then
<ogra> jordi, absoultely...
<Kamion> fabbione: sure?
<ogra> binary sources *shakes head*
<fabbione> Kamion: i need to start hacking around partman-auto-lvm.. can i still install it as custom udeb (udpkg -i) and get it to run properly?
<fabbione> Kamion: if so.. when it's the best moment to do it?
<fabbione> (i can use netinstall for sake of speed)
<Kamion> fabbione: udpkg won't work properly because templates won't get registered with cdebconf if you do that; use the boot parameter anna/choose_modules=partman-auto-lvm
<Kamion> fabbione: but use a scratch machine with nothing valuable on its disks ;-)
<fabbione> Kamion: that will use the default... what if i need to use a custom one?
<fabbione> Kamion: yeah clearly i am not going to play with it on my ws :)
<Kamion> as long as you install the default one first, you can do udpkg -i after that
<Kamion> providing you don't change templates
<fabbione> i hope i won't need that
<Kamion> sorry, we haven't quite managed to figure out how to get debconf-loadtemplate to tell the running cdebconf instance about the new templates - it all gets confusing
<fabbione> oh it's ok.. i just need to know the way :)
<Kamion> failing that, fake up a mirror with your custom udeb
<fabbione> i am not scared of messing round
<fabbione> around even
<fabbione> mirror fake isn't an option here...
<Kamion> no local mirror?
<fabbione> yes, but it's in use by the sparc buildd
<Kamion> cp -al :)
<fabbione> ahha
<Kamion> you only need the udebs, anyway
<fabbione> or lvm snapshot?
<Kamion> or that ...
<fabbione> yeah one or the other.. let me try the standard install first ;)
<fabbione> lunch time anyway
<fabbione> thanks "d-i allmighty"
<fabbione> ;)
<Kamion> er, right :)
<jordi> ogra: have you explored pythoncad?
<ogra> jordi, i've looked at the screenshots quite often
<ogra> but never tried it
<ogra> jordi, can it cope with qucad (usability wise) ?
<ogra> s/qucad/qcad
<jordi> ogra: *nod*. We planned using pythoncad, but we know little about CAD stuff so we can't evaluate it too well.
<jordi> qcad has the qt dep which is annoying here.
<jordi> ogra: I don't really know how advanced it is, but there's pythoncad releases every few weeks
<ogra> yep, i know, but i havent found anything similar yet ... at least nothing i would consider mature enough
<jordi> yeah, I fear pycad would be a bit too simple.
<ogra> the same with scribus... passepartout is coming along great, but still feels too young
<jordi> even so, could be enough for our current scope - schools and high schools
<jordi> yeah, we ship passepartout, but it not good enough yet.
<tseng> they are both better than nothing
<tseng> consider that
<ogra> tseng, scribus isnt "nothing"
<tseng> imagine shipping nothing and trying to do it in the gimp
<jordi> re: bluefish, well, NVU is WYSIWYG, while bluefish is "launch your web browser" :)
<ogra> as well as qcad
<hunger> Is there a reason why I must bring up eth0 before being able to log into gnome?
<jordi> tseng: scribus is pretty cool actually.
<jordi> hunger: have the lo interface up?
<ogra> jordi, the people want dreamwaver... nvu is the nearest i guess
<hunger> jordi: Yes, that was up before I tried.
<fabbione> Kamion: it's a good start... i can see it gets downloaded, but it doesn't kick in at all :P
<tseng> hunger: is your hostname in /etc/hosts pointing to the eth0 ip?
<hunger> tseng: Nope... only 127.0.0.1 is listed there.
<Kamion> fabbione: you don't get a "Use free space for the Logical Volume Manager" menu entry?
<seb128> pitti: debian has polypaudio? that's new?
<Kamion> fabbione: check for /lib/partman/automatically_partition/60vg_all_free/choices - you might like to hit that with 'set -x' or something
<Kamion> fabbione: oh, and yay, I have a network interface again ;)
<jordi> seb128: yeah, got in a week ago or so
<hunger> I can not log onto gnome on my rather fresh breezy install:-(
<fabbione> Kamion: no.. i don't get that option..
<fabbione> Kamion: yeah dude.. the yesterday's marathon was just to get that in :)
<jordi> ogra: what about oregano for electronics'
<jordi> ogra: I'll bring my full list to london so we can discuss
<ogra> jordi, yeah...
<ogra> jordi, i havent thought about electronics yet...
<doko> elmo: please sync java-gcj-compat from incoming. after that, java-gcj-compat-dev needs to be moved out of the NEW queue, and to main (no added stuff, pitti already did look at it). there's currently one package uploaded b-d on java-gcj-compat-dev (gjdoc), so it should be pulled in from the seeds.
<mdke> hunger, #ubuntu might be able to help you with that
<hunger> mdke: Good point... thanks.
<ogra> doko, join #ubuntu-bugs, go and push your C++ stuff ;)
<Kamion> nggg, apt is broken
<fabbione> Kamion: oh here it is.. now i do get the option...
<fabbione> Kamion: i had to do some weird crack tho...
<Kamion> doesn't surprise me ...
<jordi> ogra: gcompris, childsplay for games
<jordi> ogra: I'll put this up in the wiki comments
<ogra> jordi, oh, i forgot that... had gcompris on my initial list
<seb128> jordi: the PTS is b0rked?
<fabbione> Kamion: if what is the real status of that package.. there will be quite a lot of work to be done :)
<Kamion> fabbione: sure, it's a prototype
<fabbione> cool
<fabbione> i love crack
<fabbione> food is ready
<Kamion> fabbione: I'm sure you could get commit access to d-i if you wanted to hack on it there
<Kamion> or I can just commit your patches, whatever :)
<seb128> jordi: http://packages.debian.org/cgi-bin/search_packages.pl?keywords=polypaudio&searchon=names&subword=1&version=unstable&release=all !?
<fabbione> Kamion: we will see how far i can go first.. i don't mind splitting up patches in simple bits
<Kamion> seb128: that's not the PTS
<Kamion> packages.debian.org is an entirely different system - the PTS is packages.qa.debian.org
<seb128> Kamion: I know, when I said PTS that's it http://packages.qa.debian.org/p/polypaudio.html returning a 404
<seb128> Kamion: but I don't find it either on packages.debian.org
<Kamion> cjwatson@newraff:~$ madison -r .\*polypaudio.\*
<Kamion> cjwatson@newraff:~$
<Kamion> it's in queue/new
<hunger> Why on earth does gnome need to write into /usr to start?
<seb128> what gnome?
<seb128> Kamion: oh, k, thanks
<hunger> seb128: The one currently in breezy.
<pitti> seb128: polypaudio is still in Debian's NEW
<seb128> hunger: define gnome
<hunger> seb128: I can only login after mounting /usr rw.
<seb128> weird
<pitti> seb128: I maintain it together with otavio, but the first upload was only ~ 1 week ago
<hunger> seb128: Try mounting /usr rw...
<seb128> pitti: k, I'm waiting to put the polypaudio sink for Debian too
<mdke> vuntz, ok we will
<hunger> seb128: I further need to bring up eth0 for the panel to work.
<seb128> hunger: it's rw
<hunger> seb128: Try remounting /usr ro and try again.
<mdke> vuntz, ah sorry wrong chan ;)
<seb128> hunger: for the panel I doubt of that, or you have an applet waiting on the network ...
<hunger> seb128: Possible...
<seb128> anyway no need to write to /usr or to have eth0
<hunger> seb128: After starting gnome once with /usr mounted rw it is fine to have mount /usr ro again.
<Mithrandir> Duck_Happy: thanks for the bug, btw.
<hunger> seb128: Try this: reboot, mount /usr ro, restart gdm, log into gnome.
<seb128> lemme try
<hunger> seb128: You will get a brown background, the progress indicator won't show.
<hunger> seb128: stop gdm, start gdm, mount /usr rw, log into gnome: All works fine.
<ogra> hunger, he left
* hunger wonders why the panel freezes with the network down.
<vuntz> hunger: does it freeze loading an applet ?
<ogra> hunger, weather applet ? (or something similar)
<vuntz> (while loading an applet)
<hunger> ogra: vuntz: seb128 suggested the applet idea.
<vuntz> hunger: what applet do you have on your panel?
<hunger> vuntz: I just installed breezy... whatever that has by default.
<hunger> vuntz: I get nothing in the upper right corner...
<vuntz> hunger: ok. And is nautilus running ?
<seb128> works fine with /usr ro
<hunger> vuntz: How do I find out?
<vuntz> hunger: right click on the desktop and see if you have a popup menu
<hunger> seb128: It doesn't here.
<hunger> vuntz: Yeap, I get that.
<hunger> vuntz: I can access the CDROM via its icon as well.
<hunger> vuntz: It does freeze if I try to eject the cdrom though.
<vuntz> hunger: so, you have a panel at the top of your screen. On this one, what can you see ?
<hunger> vuntz: Applications, system, etc on the left, nothing on the right.
<vuntz> hunger: do you have a panel at the bottom?
<hunger> vuntz: The lower has the Desktop thingy on the left and a pager and waste basket on the right.
<hunger> seb128: This is even weirder than I thought: It works with /usr mounted ro all the time, but I need to login once, restart gdm and log in again.
<hunger> seb128: The secound time round the panels show up (first time there isen't even a startup notification), but it stays frozen.
<vuntz> hunger: can you launch gconf-editor?
<hunger> seb128: third login: everything works fine, applets show up, can eject cdrom.
<hunger> vuntz: Now I can... but this time the applets showed all up.
<vuntz> hunger: so the panel is working?
<hunger> vuntz: Yeap, after restarting gdm twice it works after logging in the third time (first login: black background only, secoud time: applets missing, third time: all is fine).
<hunger> s/black/brown/
* hunger repeated that exercise three times in a row now.
<vuntz> hunger: so everything is perfectly working ;-)
<hunger> vuntz: really strange this...
<jordi> mvo: have you seen your synaptic changelog? mvo: have you seen your synaptic changelog?
<mvo> jordi: pffff ... you can't peeve me with that :P
* \sh has a problem with gdome2-xslt
<mvo> it was so importend that it was worth mentioning twice :)
<\sh> dpkg-source: error: unrecognised file suffix `.tar'
<\sh> Entpack-Befehl dpkg-source -x gdome2-xslt_0.0.6-7.dsc fehlgeschlagen.
<jordi> mvo: I see :) BUT DON'T TOUCH MY PRECIOUS STRINGS
* jordi svn up's and prepares for the worse
<mvo> *cough* ... it shouldn't be too bad *cough*
<Kamion> \sh: upgrade dpkg
<Kamion> dpkg-dev, rather
<jordi> mvo: not *too* bad.
* mvo thinks he needs a string-police that always gives him a little bashing when he accidently changes strings again
<\sh> huu?
<mvo> jordi: how many this time?
* mvo hides
<\sh> ajnew updates ;)
<jordi> 644 missatges traduts, 15 traduccions difuses, 4 missatges no traduts.
<mvo> oh well ... 
<seb128> jordi: go go go translate
<seb128> lazy guy
<jordi> I'm so unmotivated to translate lately
<seb128> pffff
<seb128> go go go upload GNOME 2.10.2 
<mvo> jordi: there is this _huge_ package description string repository :)
<seb128> or BTS clean, that's actually a good idea :)
<seb128> :p
<jordi> mvo: is the Recommends file a file named like that, or can I translate?
<mvo> jordi: can you give me the context please?
<jordi> msgid "Bad regular expression '%s' in Recommends file."
<mvo> jordi: I think it should be left untranslated (the whole string). I'm sorry that a error message like this sneaked in again
<mvo> this is something that a user should never ever see
<jordi> msgid "could not open recommends file %s"
<mvo> same, sorry :/
<jordi> should this stanza have a capitalization?
<jordi> that's what made me doubt.
<azeem> 4
<azeem> *sigh*
<ogra> azeem, switching TV channels through Xchat ? 
<jordi> seb128: no dude you clean the bts
<seb128> jordi: no way
<azeem> ogra: forgot the /w in front of it
<ogra> :)
<jordi> seb128: I have a better idea, I'm goign to interview you.
<jordi> Now.
<azeem> ogra: irssi anyway, of course :)
* seb128 runs
* azeem is around for shouting stupid comments during the interview
<mvo> jordi: I removed both strings from being translatable
<jordi> mvo: should this other message have it in capitals?
<mvo> jordi: just ignore both messages, the user will never see them and they will be gone in the next version. sorry for the trouble 
<Duck_Happy> Mithrandir: was i right ?
<Mithrandir> Duck_Happy: yeah, I got two other errors reports on the pkg-config list already too.
<Duck_Happy> Mithrandir: ho ok, i though i was perhaps too tired, but was unable ot build new panel, and sad
<Mithrandir> Duck_Happy: http://incoming.debian.org/ has the fixed package.
<Duck_Happy> Mithrandir: great :-)
<Mithrandir> Duck_Happy: I've asked it to be synced into ubuntu too, so we should see it RSN.
<Duck_Happy> Mithrandir: nice, seb128 is gonna be happy
<Duck_Happy> Mithrandir: thanks :-)
<jordi> mvo: ok, ready.
<mvo> jordi: already? that was quick (/me is impressed)
<jordi> and sent :)
<mvo> jordi: thanks!
<\sh> Kamion: thx. helped
<jordi> seb128: I promise this time it'll be a short and fun interview
<seb128> no no
<seb128> interview ross :p
<jordi> seb128: but people want to read about you.
<jordi> just a few questions and we're done
<AwayWolf> jordi, don't forget to take naughty pictures. -> "Seb128, famed hacker exposed!"
<jordi> AwayWolf: I have a few good ones.
<seb128> NO
<jordi> I still have a pending blog entry about how seb128 compares to some famous French fiction character.
* seb128 slaps jordi 
<Keybuk> silly question, I'm sure, but why is there no l-r-m for 2.6.12-3-686 ?
<AwayWolf> I'd imagine daniels is swamped with just making X work atm...
<daniels> variety of reasons
<Lathiat> daniels: do suse have some kind of xserver optimizations?
<Lathiat> daniels: it seems to load up stupidly fast when i hit ctrl=alt+backsapce
<daniels> the only optimisations going around that I know of are ours
<Lathiat> hm
<Lathiat> maybe just whatever manager they are using loading really fast is fooling me
<Treenaks> Lathiat: KDM
<Treenaks> Lathiat: (at least, on my suse)
<Lathiat> Treenaks: i assumed so, why do they have no /etc/init.d/kdm ?
<Treenaks> Lathiat: because they're silly.. look in /etc/inittab
* Lathiat laughs
<Lathiat> its started from inittab?
<Lathiat> baha, thats almost as bad as djb
<jordi> seb128: seb come on, look at #gnome-debian.
<Treenaks> Lathiat: oh wait
<Treenaks> Lathiat: it has S13xdm in rc5.d for me
<Treenaks> Lathiat: so it's using xdm
<Lathiat> oh
<Lathiat> see i sawthat
<Lathiat> thats evil
<Lathiat> heh
<seb128> mvo: could you document what you change when you sync some packages with Debian? That's easier to know what the ubuntu changes are and for the next sync
<doko> mdz, wasabi: libxerces2-java FTBFS, even when using jikes
<seb128> just mention the changes/patches with the Changelog ...
<seb128> doko: do you know when cairo will be updated for Debian ?
<mvo> seb128: yes, sorry
<seb128> mvo: no need to be sorry :)
<doko> seb128: sorry, no. it's not in the NEW queue?
<seb128> doko: no
<seb128> doko: but since you said there is no hurry because it requires a new gtk too I thought you were working on it
<seb128> thanks
<doko> seb128: no, the libgcj GTK peers need the new cairo, and the new GTK. So I disabled the use of cairo in libgcj.
<jordi> seb128: you coward!
<seb128> doko: k
<seb128> jordi: what?
<seb128> jordi: wanna fight? :p
<jordi> no dude. I asked you a question!
<jordi> #gnome-debian is waiting.
<seb128> no
<seb128> interview ross I said
<jordi> he doesn't ping back. It's you!
<seb128> I don't ping back neither :p
<jordi> 14:50 < seb128> interview ross I said
<jordi> hmm. I could use this.
<jordi> that would make you appear like a villain
<seb128> I could kick your ass
<jordi> are you going to .fi?
<jordi> oh no you aren't.
<jordi> damn it.
<jordi> we could do a real interview there.
<seb128> ah ah
<jordi> don't ruin my publication. It's only two easy questions I want to ask!
<seb128> jordi: sorry but I've some real work to do :p
<jordi> I could use that too...
<jordi> seb128: this is not the end, sbastien bacher. I will be back.
<seb128> :)
<Treenaks> Nobody expects the Catalan inquisition?
<melodie_> hello :)
<JanC> is there a known problem with esd in breezy or is it just my system that's fucked up ?  :-/
<Treenaks> JanC: both ;)
<Treenaks> I guess
<cogumbreiro> lol
<cogumbreiro> JanC: esd works on my system, i updated it yesterday
<melodie_> I just found out a trick about burning and wish an advise
<melodie_> I could not burn datas anymore for seveval weeks with error "wrong encoding chain caracters" message
<melodie_> I just found out why when I did a 'ls -l' on one of the sub-repertories I could not burn:
<melodie_> there was a hidden backfile matching a file I had moved
<melodie_> but 
<melodie_> :)
<melodie_> it was totally invisible, save in the shell
<melodie_> should it be reported as a bug ?
<melodie_> and if so, rather in Bugzilla or to Gnome ?
<JanC> I installed polypaudio & that works
<pitti> JanC: good to hear :-)
<JanC> programs were hanging when trying to create (or use?) a pipe to esd or something like that
<JanC> (I have no real experience using strace)
<[hawk] > Hello!
<[hawk] > I'm Vincenzo Di Massa... one of the Google Summer of Code students...
* mvo is away for ~1h (appointment)
<bddebian> Hello
<hunger> fabbione: Sorry, forgot to attach a patch to #12065. Just attached one.
<fabbione> hunger: please do... 
<hunger> fabbione: I just did:-)
<fabbione> hunger: what kind of attachment is that one?
<hunger> fabbione: It's a bzip2'ed diff file.
<fabbione> ok
<hunger> fabbione: Oh, sorry, I was not aware that the description will end up as the name.
<fabbione> hmm it's a bit intrusive patch.. where did you get it?
<hunger> fabbione: tpmdd.sf.net.
<fabbione> ok.. i will need to see if a) build b) doesn't break the ABI
<fabbione> if it breaks the abi i will have to queue it together with some other major changes
<hunger> fabbione: The tpm driver in the kernel assumes all kinds of things to be static to whatever kylene uses;-)
<fabbione> hunger:-EXPORT_SYMBOL_GPL(tpm_time_expired);
<fabbione> this is an ABI change
<hunger> fabbione: This is what was changed when people started to shout;-)
<fabbione> if other modules are using tpm_time_expired than it's an issue :)
<hunger> fabbione: Other modules shouldn't do it.
<fabbione> well we will see :
<hunger> fabbione: So far nothing uses it but the trousers lib (which is userspace and not in ubuntu yet) afaik.
<fabbione> hunger: an automatic test build will tell... :)
<hunger> fabbione: I am sure the change will make it into the vanilla sources soon.
<fabbione> hunger: if it will hit upstream soon, the better...
<elmo> kamion: will you cry if I demote 2.6.10?
<fabbione> elmo: kill it
<fabbione> elmo: and kill 2.6.11 please
<fabbione> elmo: d-i uses .12 now
<elmo> kill as in remove from the archive kill?
<fabbione> elmo: yes
<elmo> well, I'd like sign off from kamion; I'm scared of his vicious high kicks
<fabbione> the default is .12
<elmo> killed 2.6.11 in the meantime
<Kamion_> elmo: fine by me
<elmo> killing l-r-m 2.6.10 too
<ogra> elmo, killer
<elmo> uh
<pitti> cool, that will clean up ubuntu-cve
<elmo> uh, did someone reorganize l-r-m?
<elmo> we seem to have 2.6.12 packages, but not built from l-r-m source and nothing is claiming to build all the non l-r-m packages (nvidia, x* etc.)
<tseng> elmo: lrm isnt built for 2.6.12 yet
<ogra> elmo, we have no l-r-m for 2.6.12 yet
<fabbione> elmo: daniels was going to look at it
<fabbione> elmo: we have still a few problems to solve related to the compiler
<elmo> linux-restricted-modules-386 |   2.6.12.2 | breezy/restricted | i386
<elmo> tseng/ogra: :-P
<elmo> fabbione: hum, ok, I'll leave l-r-m alone then
<pitti> ogra: isn't that from linux-meta?
<pitti> erm, elmo^
<elmo> probably
<fabbione> elmo: you can kill l-r-m for .10 in breezy
<ogra> pitti, yep.... and linux-meta was modifiaed afaik
<fabbione> there is no point 
<elmo> fabbione: I'd rather not - it'd make them NEW, etc.
<elmo> I'll kill it when we have 2.6.12 replacements
<fabbione> elmo: ok, but .10 are useless without .10 kernel
<fabbione> you really can't use them in .12
<elmo> yah, I know, it's purely a ease-of-archive-maintenance thing
<fabbione> linux-meta is ok :)
<fabbione> elmo: eheh eok
<elmo> Kamion: dude, what's up with your ADSL?
<elmo> you're scaring me off of metronet
<chrissturm> is it known that the .12 kernel doesnt work with ipw2100 (at least with wep) ?
<mdz> seb128: I thought you were there during the discussion where we proposed this Wednesday...when was the gnome outage announced?
<pitti> Hey mdz
<seb128> mdz: I've not noticed anybody announcing a data
<seb128> mdz: the GNOME outage is known for around 10 days I would say
<fabbione> chrissturm: yes.
<chrissturm> fabbione, is it fixable? i saw someone fixed it by compiling the ipw2100 driver himself: http://lists.ubuntu.com/archives/kernel-bugs/2005-June/001820.html
<Kamion_> elmo: I'm beginning to conclude that it's nothing to do with Metronet; my router is actually rebooting all the time, not just losing line sync
<elmo> ah
<fabbione> Kamion_: is that a linksys router?
<fabbione> elmo: can you kindly NEW the kernel for sparc?
<elmo> fabbione: already did
<fabbione> thanks
<robitaille> Kamion_:  did  you ever looked again at bug 2727 (see last comment there from you)?  I cannot reproduce it on my Hoary install
<mdz> Kamion_: sorry about the apt breakage; I made the changes in a different tree from the one where I made the release from :-/
<doko> Kamion_: some MOTUs want to fix C++ bugs. which is the easiest way to tell (for universe packages), which are out of date?
<hunger> doko: kexi is broken due to gcc transition (*hint* *hint*)
<doko> hunger: fix it ;)
<bddebian> doko: According to the wiki most if not all are done
<doko> bddebian: not the library list
<bddebian> Hmm
<ogra> hunger, we are looking at easy to fix targets, that require one or two small dependency changes and a rebuild
<doko> bddebian: see https://wiki.ubuntu.com/UniverseCxxTransition
<hunger> Yahoo, wireless utils are 28pre8 now! So I no longer need to roll my own.
<bddebian> doko: 99% of that list has a patch in Debian, unless it has been updated in the last day or two
<doko> bddebian: it should be 100%
* lamont -> work
<madduck> bddebian: now it seems to work. I am ordering you a copy, ok?
<bddebian> Awesome, thanks!
<madduck> $69.40
<madduck> is that okay?
<madduck> it's worth it... :)
<bddebian> If you pay for it. ;-P
<bddebian> Nah, that's fine
<madduck> ha ha.
<bddebian> That includes shipping?
<madduck> yessir
<madduck> but not credit card charges
<madduck> they may be 1% or so
<bddebian> NP
<madduck> for international
<madduck> ok. pressing ok
<madduck> 10... 9...
<madduck> 8... 7...
<bddebian> Is that $69.40USD or Euro
<madduck> USD
<bddebian> Cool, press it man, press it! :-)
<madduck> 4... 3...
<madduck> 2... 1...
<madduck> BOOOM
<madduck> done
<bddebian> Sweet
<bddebian> ANd that should arrive in about a year? ;-P
<madduck> i'll forward that email to you, even though it
<madduck> yeah, with etch.
<bddebian> hehe
<madduck> oops. this *is* ubuntu-devel... :)
<bddebian> Yeah, you blashpemer. :-)
<madduck> whatever. you all love me anyway. :)
<bddebian> Of course we do
* madduck is not so sure. :)
<bddebian> madduck: Well at least both sides don't hate you like they do me.. ;-P
<Kamion> elmo: looks like it's netgear that're thpethul - downgrading router firmware seems to have helped matters, touch wood
<madduck> bddebian: http://rafb.net/paste/results/0bwJaS89.txt
<daniels> mdz: any comments on the seen flag with preseeding issue?
<elmo> kamion: DOWNgrading?? what router do you have?
<Kamion> daniels: what's that?
<daniels> Kamion: matt's seeing auto_answer stomping all over his layout when he preseeds stuff
<Kamion> elmo: dg834g. 1.05.00 bad, 1.04.01 good. enormous thread at http://forum1.netgear.com/support/viewtopic.php?t=1366 about it
<daniels> Kamion: so preseeding foo/bar=baz appears not to set the seen flag of foo/bar, afaict
<daniels> either that or I'm on crack and -33 will fix it
<bddebian> madduck: :-)
<Kamion> daniels: preseeding has always set the seen flag - it's only recently that it's even been possible to preseed something without setting the seen flag
<bddebian> madduck: Was that before you copied it?? ;-)
<daniels> Kamion: crack wins the day!
<madduck> bddebian: nah, i only pasted it to #hax0rz-lair
<Kamion> daniels: of course, maybe I'm assuming that he's using the standard preseeding code
<bddebian> madduck: Sweet, thanks! :-)
<Kamion> mdz: are you using debconf-set-selections, or manual db_set etc.?
<mdz> Kamion: in which context?
<mdz> oh, xorg
<mdz> I'm doing SET through debconf-communicate
<Kamion> and not FSET?
<Kamion> (and why debconf-communicate?)
<mdz> Kamion: it didn't seem wise to source confmodule in an init script
<mdz> Kamion: and no, I don't use fset in that bit at the moment
<Kamion> ok, sounds like an easy fix then
<Kamion> I think you might be the first person to attempt to use debconf from an init script
* Kamion builds another round of CDs with hopefully-this-time-yes-really-fixed apt
<mdz> Kamion: so I just need to set the seen flag, and everything will work as I expected it to originally?
<mdz> auto_answer seems insane to me though
<mdz> it's wrapping appropriate logic which already exists in debconf for using the default if the question isn't asked
<daniels> not quite
<Kamion> mdz: dunno, was really just answering daniels' question about preseeding - I thought he was talking about the preseed package at first
<daniels> mdz: it will pick a sensible default dynamically, which you can't do otherwise
<Kamion> there's no easy way in debconf to set the default to something different than is in the templates file
<daniels> i agree in general the code is crack, but there are worse abominations than auto_answer
<daniels> to be fair, the seen flag really is the best metric for 'has this question been answered?'
<Kamion> yeesh, we've switched to libiw28?
<Kamion> nobody told the installer :-/
<mdz> Kamion: oh, substitutions aren't valid in the default field?
<daniels> mdz: anyway, once you do that, force_keyboard_redetection (later to be autodetect_keyboard) should be sweet
<Kamion> mdz: no, Debconf::Question::value() does not do _expand_vars()
<daniels> does anyone here actually have i810 desktop hardware?  need to test a (rather belated) hoary update before I uplaod it
<mdz> Kamion: is there a good reason for that?  this isn't the first use case that has come up
<Kamion> mdz: I imagine dynamic defaults weren't envisaged originally
<mdz> this stuff is in matt.zimmerman@canonical.com/ltsp--main--0 (and the ltsp source package) if anyone's curious
<Kamion> so SET would have been sufficient
<zanaga> Kamion: which package should i report a bug of floppy module being constantly re-installed during installation?
<Kamion> now I guess I'd be slightly concerned about breaking compatibility, although hopefully nobody's actually put "${...}" in a default without meaning it to be a variable
<Kamion> zanaga: it's already reported, and should be harmless except for slowing stuff down a bit
<zanaga> Kamion: yeah, it's harmless. But it's starting to get on my nerves =)
<Kamion> mdz: well, I mean dynamic defaults in combination with reconfiguration
<Kamion> mdz: hmm, apt 0.6.39ubuntu4 is an odd almost-no-op upload and removed my changelog entries from 0.6.39ubuntu{2,3}
<mdz> Kamion: you missed the error message in apt-key, and it was easier to reapply my changes from the other tree than to debdiff.  I'll merge in the changelog entries
<mdz> Kamion: changelog entries are restored in arch
<mdz> I wonder if apt is hct-able
<pitti> elmo: please sync ruby1_8 1.8.2-9 from incoming
<elmo> is this going to kill my amd64 buildds again? :P
<Lathiat> haha
<pitti> seeeeeeeeb!
<pitti> seb128: any idea where the gnome games went to? I have gnome-games installed, but the package is empty and there's nothign in the menu
<pitti> seb128: surely a GTK bug, but I'd wanted to ask anyway *duck*
<seb128> pitti: are you sure it's installed?
<seb128> pitti: and not rc? 
<pitti> huh?
<pitti> purge-ok-installed
<pitti> $ LANG=C sudo apt-get install gnome-games
<pitti> gnome-games is already the newest version.
<pitti> WTF??
<elmo> infinity/fabbione/thom: apache2 can't run separate virtual hosts as different users right?
<elmo> [and can apache1.3] 
<seb128> pitti: funny :p
<thom> no, no
<pitti> seb128: sorry for bothering, but that doesn't look right...
<tseng> elmo: the only way i know of apache running with seperate prililages is suexec
<tseng> elmo: which is also evil
<thom> elmo: as tseng says, you can run cgis as different users with suexec
<tseng> http://httpd.apache.org/docs/suexec.html#model
<tseng> suid, boo, hiss
<seb128> pitti: no worry :)
<pitti> seb128: install --reinstall did the trick
<maswan> so, are the apache folks planning on solving this in a better way then?
<seb128> pitti: cool
<daniels> elmo: theoretically, you could do this sort of thing with perchild
<daniels> but perchild is thpethul
<daniels> seb128: i just fixed about 30 functions with unchecked arguments in xcursor.  this is your fault.
<seb128> thanks :)
<elmo> daniels/tseng/thom: thanks
<whiprush> ogra: have you gotten much feedback on gnome-power?
<jordi> the name is cool
<ogra> whiprush, not much yet
<whiprush> is it mature enough for me to test out? (ie does it work?)
<ogra> its good for showing the battery state for now, orthe stuff will get waved in soon
<ogra> it needs some integration love ut does no harm, try it :)
<ogra> but even
* whiprush sacrifices a laptop
<StoneTable> mvo:  would you mind if I wrote a patch for bug 12226?
<mvo> StoneTable: IIRC this is fixed already, could you please check?
<mvo> StoneTable: could you please verify if it is still a problem. if you, a patch is very welcome of course :)
<StoneTable> There were still issues with it as of this morning
<torkel> mvo: it is not fixed in 2.59-0.2ubuntu3
<mvo> torkel: ok
<mvo> a patch is welcome then :)
<StoneTable> okay, I'll tackle that next then, and attach the patch to the bug report
<mvo> great, thanks!
<torkel> StoneTable: if you need anyone to test the patch let me know
<StoneTable> okay, cool, thx
<torkel> my python knowledge is less than desirable or I would have given it a try myself
<chuck_> 3/window 3
<daniels> elmo: could you please install libglide2-dev in concordia/hoary-i386?
<elmo> daniels: done
<daniels> thanks
<elmo> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=157270
<elmo> is fascinating and disturbing reading
<daniels> Kamion: so, uhm
<daniels> Kamion: sort of discovered a bit of a brown-paper-bagger at linuxtag
<daniels> Kamion: intel i915 hardware is listed as vesa still within discover1-data.  which means unaccelerated desktops.
<daniels> Kamion: if we drop a one-line change (which I uploaded to breezy recently) into hoary, whenever people next update xserver-xorg, their config will get rewritten to use i810 and thus have an accelerated desktop (2D as well as 3D).
<daniels> Kamion: is that worth a hoary-update?
<daniels> noting that d1-data is trivially small
<daniels> crap
<daniels> elmo: bzip2 pls
<daniels> elmo: or just all the xorg b-ds in general
<elmo> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
<Kamion> daniels: seems reasonable to me; I suppose we can tell people to dpkg-reconfigure xserver-xorg
<elmo> for xorg?
<elmo> and bzip2 is installed?
<daniels> Kamion: sure
<daniels> elmo: blah, must've landed in the middle of an apt run or something, because concordia/hoary-i386 was telling me to install bzip2
<doko> pitti,elmo: please could you promote java-gcj-compat-dev to main?
<pitti> doko: I can't
<lamont> pitti: and here I had been impressed with your new super-powers.
<elmo> daniels: sorry, yeah, I did a sly dist-upgrade
<pitti> lamont: they still have to grow, I'm afraid :-)
<daniels> elmo: ahr
<daniels> elmo: nothing can escape my roving eye
<doko> pitti: but you can approve it?
<Kamion> java-gcj-compat-dev seems not in need of approval, unless it has vast wodges of new deps
<pitti> Kamion: AFAIU it was just a package split
<pitti> doko: didn't I already do that yesterday? it's a no-brainer
<Kamion> doko: promoted
<Kamion> hooray, CD build actually debootstraps successfully now
<daniels> nice :)
<Kamion> be grateful for small mercies
<doko> Kamion: thanks
<daniels> seb128: xcursor uploaded
<Kamion> sigh, I still get "Error" "failed to initialize HAL"
<Kamion> pitti: any ideas? this is a fresh install
<Kamion> .xsession-errors says:
<Kamion> ** (gnome-session:29555): WARNING **: Host name lookup failure on localhost.
<Kamion> and shortly afterwards a complaint from g-v-m that HAL is not running
<Kamion> dunno whether the localhost thing is related though
<Kamion> and 'host localhost' works fine
<ska-fan> Got localhost in /etc/hosts ?
<Kamion> yes
<Kamion> default install, dude :)
<daniels> elmo: i think concordia would like a biger disk
<Mithrandir> like 666G instead of 66G?
<daniels> yeah
<ogra> Mithrandir, uhh devlish
<daniels> oh, bloody hell
<daniels> elmo: any chance we could blacklist xresprobe from syncs?
<mxpxpod> seb128: ping
<seb128> mxpxpod: pong
<mxpxpod> seb128: I filed a bug yesterday against gnome-panel regarding libwnck and the workspace switcher... have you read it yet?
<seb128> the stuff fixed with a rebuild ?
<mxpxpod> yeah, a rebuild of libwnck
<seb128> no clue of the issue
<seb128> works fine for me on i386
<seb128> and no other bug about that
<seb128> any explanation of the bug?
<mxpxpod> it's really strange, but it affects gnome-power as well
<mxpxpod> seb128: it must only be on powerpc
<mxpxpod> seb128: what do you mean?
<seb128> any idea of why it bugs?
<seb128> I've no bug from other ppc users
<seb128> and we have for sure other ppc users
<seb128> Kamion, pitti: do you run the current gnome-panel on ppc?
<mxpxpod> no clue... just that error on the command line that I put in the bug
<mxpxpod> that's really strange
<seb128> Kamion, pitti: that's about #12241
<mxpxpod> seb128: also, the workspace switcher applet's preferences gives me an error about an invalid schema
<seb128> are you sure than the packages are correctly installed?
<seb128> what error exactly?
<mdz> daniels: the easiest way to prevent it from syncing would be to upload a -ubuntuN version
<mxpxpod> Failed: Failed: Schema `/schemas/apps/workspace_switcher_applet/prefs/display_all_workspaces' specified for `/apps/panel/applets/applet_88/prefs/display_all_workspaces' stores a non-schema value
<mxpxpod> Failed: Failed: Schema `/schemas/apps/workspace_switcher_applet/prefs/num_rows' specified for `/apps/panel/applets/applet_88/prefs/num_rows' stores a non-schema value
<daniels> mdz: it seems horribly wrong, though, given that we're the upstream version that debian makes modifications (that we do not want to sync) to
<daniels> mdz: i.e. the debian packager would always need to be one revision down
<mxpxpod> seb128: ok, I just re-installed gnome-panel-data and did a gconftool-2 --shutdown
<mxpxpod> and then pkilled gnome-panel and it works fine now
<seb128> weird
<mxpxpod> yeah
<seb128> imho that's a local problem during the package install on your box
<mxpxpod> ok, I'm going to try re-downloading the libwnck packages and see if that fixes my issue
<mxpxpod> seb128: it probably is... maybe gconf was still running when I installed, or something
<seb128> the packages reload the gconf base when installing keys
<seb128> so that should not be an issue
<mxpxpod> nope, re-downloading the libwnck packages from ubuntu doesn't help
<mxpxpod> seb128: hmmm... maybe the postinst didn't run correctly
<seb128> possible
<mxpxpod> anyway, I'm really not sure what's up with libwnck... I'm getting that error:
<mxpxpod> /usr/lib/gnome-panel/wnck-applet: error while loading shared libraries: /usr/lib/libwnck-1.so.16: R_PPC_REL24 relocation at 0x0ff77fc8 for symbol `malloc' out of range
<mxpxpod> I downloaded the source of libwnck and recompiled and the recompiled packages don't give me that error
<mdz> daniels: yeah, I guess that would be awkward too
<pitti> seb128: no, I don't
<seb128> k
<seb128> any idea about the "/usr/lib/libwnck-1.so.16: R_PPC_REL24 relocation at 0x0ff77fc8 for symbol `malloc' out of range" ?
<bryanf> seb128: just so you know, this is mxpxpod
<seb128> k
<bryanf> did kamion respond?
<seb128> no
<bryanf> ok
<bryanf> that's such a strange bug... I'm not sure if it has something to do with gcc-4.0 because I haven't used it enough
<mxpxpod> seb128: will you be online later tonight?
<seb128> depending of "later"
<mxpxpod> seb128: around 8:00 CDT
<seb128> what is CDT?
<seb128> maybe 1-2 hours from now before sleeping
<mxpxpod> central standard time on daylight savings
<mxpxpod> darn
<daniels> seb128: slacker
<seb128> is that american?
<mxpxpod> seb128: yeah
<seb128> daniels: shut up :p
<Kamion> seb128: sorry, don't know, I haven't been quite current on powerpc for a while
<seb128> k, np
<Kamion> anyone else have any clue about the hal thing?
<seb128> what hal thing?
<Kamion> should I ignore it for the purposes of Colony 2?
<Kamion> 19:46 < Kamion> sigh, I still get "Error" "failed to initialize HAL"
<Kamion> 19:47 < Kamion> .xsession-errors says:
<Kamion> 19:47 < Kamion> ** (gnome-session:29555): WARNING **: Host name lookup failure on localhost.
<Kamion> 19:47 < Kamion> and shortly afterwards a complaint from g-v-m that HAL is not running
<Kamion> 19:47 < Kamion> dunno whether the localhost thing is related though
<Kamion> 19:47 < Kamion> and 'host localhost' works fine
<Kamion> dialog when logging into GNOME after a default install
<seb128> weird
<daniels> gtk bug and all that
<seb128> I've the same warning about localhost here but not hal issue
<seb128> I guess that's not the same issue
<hughsie> ogra: ping?
<ogra> hughsie, hi
<hughsie> ogra, you done any work on gnome power manpage? I was hoping to release 0.0.6 this week and wondered if you want me to include it upstream?
<ogra> hughsie, nope, i must prepare my talks etc for the summit on the weekend, i cant do much this week
<ogra> hm
<hughsie> ogra: sorry about that - you'll piss yourself laughing when you hear what I just did..
<ogra> tell me :)
<hughsie> testing the low battery notification in gpm, but forgot to put the ac back in. The warning was copletely disregarded!
<ogra> you played with gpm
<ogra> :(
<hughsie> anyway, whats the verdict on the manpage?
<ogra> hughsie, i must prepare my talks etc for the summit on the weekend, i cant do much this week, probably tomorrow evening in the hotel ...
<hughsie> dont worry about it mate, i wondered if it was ready to go..
<ogra> no, i havent done much beside watching porn pages ( i have to talk about content filtering and had to test squidguard configs)
<hughsie> ogra: lol !
<ogra> but thats an awful thing, lots and lots of false positives
<hughsie> like?
<ogra> http://www.veganporn.com/
<ogra> :)
<ogra> nearly all parental control software advertising pages ...
<maswan> woudl http://porno.acc.umu.se/ be caught?
<hughsie> lol, not cool..
<ogra> lots of stuff where porn is mentioned without being a porn site... even some church pages
<maswan> (hey, that was selected Geek site of the day, 15 of May 1996!)
<ogra> maswan, yep
<ogra> 403 :)
<hughsie> ogra: on gnome-power-devel we are discussing whether the icons in gpm should be generated on the fly (like now, with an overlay)
<hughsie> or just taken from a set of icons that could be themed
<hughsie> David Zeuthen is very keen on the seporate icons idea, and i just wondered on your view
<ogra> could you get it upstream (hicolor-theme) ?
<ogra> so a default set is always in there 
<hughsie> yes, not a problem.
<ogra> i saw the thread btw :)
<hughsie> gotcha
<ogra> i would go a themed way, to make it easier for icon designers and distros to adjust it to their needs
<hughsie> thats what david said.
<ogra> yep
<hughsie> but i'm not sure about creating circa 50 icons for al the different devices and states
<ogra> thats easy with gimp... you normally have only one background with a handfull of variants
<hughsie> point. so you would say go with david?
<hughsie> what about making it configurable?
#ubuntu-devel 2005-07-05
<ogra> in gconf, yes, in the interface, nope
<hughsie> thats what i was thinking.
<hughsie> lets people choose a "gnome default" or have a "distr-wizzy" icon theme
<ogra> yop
<hughsie> also, I wanted to spilt up the g-p-p screen into an extra tab "advanced" - is that a good idea / bad idea?
<herzi> seb128: ping
<seb128> herzi: pong
<herzi> seb128: any chance to get tag-writing enabled in ubuntu unstable's rhythmbox?
<mitsuhiko> does anybody knows which PCI class represent which device?
<mitsuhiko> i think PCI class 3 are graphic cards
<ogra> hughsie, what do you want to put there ?
<hughsie> "Battery is critical when" and the 4 checkboxes
<hughsie> i'm sure other stuff will com up
<seb128> herzi: I'll ping upstream, but according to teuf it doesn't work fine 
<seb128> herzi: I don't want to create a bug flood on that
<herzi> seb128: of course
<herzi> i was just asking, because people in #rhythbox told me about a month ago that they are using it fine
<ogra> hughsie, yes, why not, i see no problem with another tab
<herzi> .oO(and someone will need to enable it by default to get the missing bits fixed)
<seb128> herzi: really dependant of the kind of file you edit according to teuf
<seb128> yeah
<mitsuhiko> ok. I've found something: http://developer.apple.com/qa/hw/hw91.html
<seb128> but before pushing on upstream I prefer to be sure than upstream will respond
<hughsie> sweet, consider it done. I can only see more options coming for differnt things, and I don;t want to blind the average user when the defaults would do fine for most cases
<herzi> seb128: okay, i'll file a bug and add you and teuf to the cc
<herzi> then we can discuss it there, better than irc
<seb128> thanks
<seb128> upstream bug?
<ogra> i think it also gives the options tab a better look, it appears quite full currently
<hughsie> ogra: agreed.
<herzi> seb128: ubuntu
<seb128> maybe putting that upstream to discuss the default value for the configure option
<herzi> okay
<seb128> I would be happy to follow upstream on this
<seb128> and both teuf and me are subscribed to the upstream bugzilla for it
<hughsie> ogra: I have a new tab, and a few more options - double clicking on the default icon will be able to perform an action too - good/bad?
<ogra> sounds good to me, did you look into the HIG ? what does it say about doubleclick on tray icons ?
<hughsie> ogra: will check itnow
<Burgundavia> hughsie, most applets are single click
<ogra> Burgundavia, its a tray icon, no applet
<Burgundavia> again, single click
<hughsie> notification area icon, i guess that changes things
<hughsie> okay, i admit i can't think of any icons in the tray i double click
<ogra> i only have gaim here and thats not really representative for good HIG but uses single click
<hughsie> okay, i'll add it, and see if i get shouted at.
<ogra> yep :)
<ogra> good plan
<hughsie> i can always remove the option from g-p-p and keep it as a gconf
<Burgundavia> beagle and blam also use signal click
<ogra> right
<Burgundavia> so does update-manager, AFAICR
<hughsie> okay, i get the point, thanks :)
<Kamion> hm, damnit, the firefox and evolution icons still haven't been restored to the default top panel
<Kamion> and no mdz around to delegate upwards to ...
<Riddell> Kamion: are you going to start building daily kubuntu CDs
<hughsie> guys, I sleep. thanks for your help tonight
<ogra> night hughsie 
<ogra> hughsie, thanks for your app ;)
<Kamion> Riddell: hm, yeah, I should get around to that
<Kamion> Riddell: I can't remember whether I fixed everything so that it'll work, but I've made it start building at least. sorry I neglected it until now
<Riddell> Kamion: what needed fixed?
<Kamion> last I checked I think kubuntu-desktop was uninstallable
<Kamion> but that's been sorted out
<Riddell> should be fine now I hope
<Riddell> worked fine for me and others who have tried
<Kamion> AHA
<Kamion> got the hal thing
<Kamion> -    if [ -x /etc/init.d/dbus-1 ] ; then
<Kamion> -      invoke-rc.d dbus-1 restart || true
<Kamion> +    if [ -x /etc/init.d/dbus ] ; then
<Kamion> +      invoke-rc.d dbus restart || true
<jp> kewl 4 u
<Kamion> too late for a Colony release tonight, though. Again.
<jp> no1
<jp> :P
<jp> it's not too late
<jp> ;)
<jp> jajaj
<Kamion> whatever
<lifeless> Kamion: colony ?
<Riddell> lifeless: I collection of badgers
<lifeless> ahha
<Kamion> lifeless: http://lists.ubuntu.com/archives/ubuntu-devel/2005-May/007591.html
<Riddell> Kamion: I'm looking forward to a Kubuntu colony :)
<Kamion> eek. I think that might have to be Colony >= 3 :)
<jp> ?
<whiprush> msg StoneTable around?
<jp> please, kubuntu at #kubuntu-devel
<jp> :)
<whiprush> oops
<lifeless> if I open(foo, O_CREAT|O_WRONLY, 0222) - can I write to it (i.e. does the mode affect later users only ?)
<lifeless> dumbarse question I know
<Kamion> jp: his question was quite welcome here
<Kamion> and appropriate
<jp> I don't know why mark shuttleworth talked and presented about 10x10 having kubuntu :)
<jp> I think must think a little bit about kubuntu :)
<lifeless> because we want 20x10 ;)
<jp> nah
<jp> :)
<jp> I want 20x10 gnome ;)
<lifeless> Kamion: ^^^
<Kamion> ?
<lifeless> if I open(foo, O_CREAT|O_WRONLY, 0222) - can I write to it (i.e. does the mode affect later users only ?)
<lifeless> dumbarse question I know
<Kamion> I imagine you can, but I'd have to try it
<lifeless> ah, k.
<Kamion> 0222 is write-only anyway - did you mean 0444?
<Kamion> open("foo-test", O_WRONLY|O_CREAT, 0444) = -1 EACCES (Permission denied)
<Kamion> oh, no, ignore that
<Kamion> lifeless: works fine even with 0444
<lifeless> Kamion: thank you for humouring my lame-arseness
* Kamion sets CDs building and goes to build; night
<lifeless> night
<ogra> night all
<mdke> night ogra
<wasabi> So, how long does it usually take between buildd building a package and it showing up in the archive?
<tseng> the master archive updates every 30 minutes iirc
<wasabi> And what time zone is people.ubuntu.com in?
<wasabi> [   ]  ecj-bootstrap_3.0.1-4ubuntu3_20050629-2109-i386-successful.gz    29-Jun-2005 21:13  6.8K  
<tseng> wasabi: the main data center is in the UK
<tseng> that sounds more like US centra
<wasabi> Apache should localize these times. ;0
<tseng> l
<tseng> im in est and its 10:13
<tseng> 10:41 rather
<wasabi> I'm in CST.
<daniels> it's 0342 in UTC right now
<daniels> so I assume it built 6 hours ago, because all the data centre machines are currently UTC+1
<tseng> yeah im lost
<wasabi> *spins*
<tseng> yep
<wasabi> OKay, so it was built 6 hours ago.
<wasabi> Why isn't it in the archive yet?
<daniels> *shrug*
<tseng> its not new is it?
<daniels> might have binary packages which need to go through NEW
<wasabi> oh hell.
<wasabi> Yeah, it's NEW.
<tseng> yep
<wasabi> Forgot I added a new package to it.
<tseng> consider yourself rocked by moderation
* wasabi wishes it would email him with status.
<tseng> enter holding pattern
<tseng> wasabi: it does, for NEW sources
<mxpxpod> Kamion: ping
<tseng> not so smart about NEW binaries
<wasabi> Ahh well.
<wasabi> How fast does NEW go these days? :)
<tseng> depends on elmo's level of spite towards you/your package
<tseng> his free time, i mean
<lamont> tseng: *whap*
<wasabi> Haha. So Never? :)
<lamont> since elmo's not here to defend himself
* lamont sees the time, runs out the door
<tseng> wasabi: java?
<tseng> wasabi: pretty close
<wasabi> Yeah.
<tseng> lamont: :)
<tseng> lamont: cya.
<wasabi> I have Eclipse 3.1 ready to upload.
<wasabi> BUt it'll be stuck behind ecj-bootstrap anyways.
<tseng> yeah dont upload anything else that will just fail
<tseng> it would require manual kicking or more uploads
<infinity> <shrug>, if it has proper build-deps, it won't fail, it'll just enter dep-wait.
<infinity> Also, katie mails the uploader on NEW source/binaries.  That's why you get a mail for NEW sources, but the buildd gets a mail for binaries.  A weird side-effect of source-only uploading.
<lu|away> hrm
<lu|away> is it possible to get dpkg -l to show package sizes?
<lu|away> (or get a list of installed packages, sorted by size, some other way?)
<jamesh> lu|away: "less /var/lib/dpkg/status"
<lu|away> installed size in dpkg/status is K?
<jamesh> I guess
<jamesh> I have some Python code that extracts some info from the file that might be useful
<jamesh> http://people.ubuntu.com/~jamesh/identify.py
<lu|away> probably not worth it
<lu|away> hrm
* lu|away discovers some of the size growth
* lu|away discovers lots of lang packs
<jamesh> "apt-get clean" ?
<lu|away> no, sadly
<Burgundavia> jdub, nautilus with that thunar-style interface, possible?
<fabbione> morning
<wasabi> Wow. Interesting cron bug.
<wasabi> Thing checks in /etc/passwd for users before running per-user crontabs.
<fabbione> maswan: buttercup is down again :(
<Burgundavia> ogra, xscreensaver has reverted to pre ogra-love ugliness
<Lathiat> Burgundavia: yeh it makes me want to cry
<Burgundavia> related to the cursor breakage?
<lamont> I: Configuring ubuntu-keyring...
<lamont> W: Failure while configuring base packages.  This will be attempted 5 times.
<lamont> bummer
<fabbione> hey lamont 
<lamont> hrm... that reminds me
<fabbione> if you are not tired....
<fabbione> i am not going to work on kernel today or tomorrow
<lamont> I have a toolchain now, and sometime soonish (since I unthrottled it), my mirror will be current, and I can install said toolchain in the local archive and let the buildd have some fun
<lamont> then the other buildd will get the toolchain tomorrow, and off to the races
<fabbione> ehhe neat
<lamont> gsyprf11 has a hoary chroot... (and a pretty broken breezy chroot - I need to build a fresh once I can debootstrap breezy/hppa)
<lamont> 67 files to go on the mirror.
<fabbione> lamont: is the hoary chroot updated ?
<fabbione> lamont: the chroot isn't exactly ok
<fabbione>  dchroot -c hoary
<fabbione> Executing shell in 'hoary' chroot.
<fabbione> crimsun: Authentication service cannot retrieve authentication info.
<fabbione> meh
<fabbione> s/crimsun/su
<lamont> hrmpf... I'll have to pester ggg tomorrow and figure out what that means - tired enough tonight that it's a bad idea to muck about.
<lamont> note that you do wind up in the chroot after that warning.
<fabbione> yup
<fabbione> i think elmo knows what the problem is
<fabbione> we digged into it once
<fabbione> lamont: can you wait a sec to install the b-d?
* lamont launches 67 wget's in parallel... just for giggles
<fabbione> lamont: please install ccache and distcc 
<lamont> sure - just tell me what you need
<fabbione> ( i will need to recheck the other 2/3 hostnames for distcc )
<lamont> but be aware that the hppa/breezy archive is pretty empty atm
<fabbione> yup.. i am unpacking it now
<fabbione> i am in the hoary chroot... it's enough for me to do test build
<fabbione> xmlto kernel-package gcc-3.4-hppa64 gcc-3.4
<lamont> although with my chages, you _should_ be able to build it on a mostly-hoary world
<fabbione> lamont: no problem for that.. i can relax the b-d for hppa while i am working
<fabbione> s/working/building
<lamont> installed... wanna check the versions, and maybe I can fix them if needed...
<fabbione> no i am fine with what's there
<lamont> cool
<fabbione> perfect
<fabbione> dpkg-checkbuilddeps: Unmet build dependencies: kernel-package (>= 9.001ubuntu1)
<fabbione> it's the only one
<fabbione> but it doesn't need to be there
<fabbione> not in hoary
<lamont> so I don't need to go fetch that from breezy?
<fabbione> nope
<fabbione> it's to workaround a gcc/glibc/dpkg -gnu- non-gnu crap
<fabbione> that's not in hoary
<lamont> ah, ok
<lamont> dpkg-dev crapage you mean?
<fabbione> and ppc64
<lamont> or sparc crapage?
<fabbione> nope.. dpkg-dev
<fabbione> sparc is ok :)
<lamont> notice how I made the gcc-3.4 be ppc-concious...
<fabbione> yup i know
<fabbione> i saw it
<lamont> kernel-package wasn't a hard one to grab and drop in my hoary chroot though, so I didn't bother (that and I didn't know just how required it was...)
<fabbione> nah that's ok.. the old one is fine
<lamont> yeah - wasn't worth the time to find that out though... /me would like it if the build-deps were properly versioned to start with, for us backporting-to-hoary types....
<lamont> so subversion is kinda bloated (debsize-wise, that is..)
<fabbione> lamont: i don't want people to backport kernel tbh...
<lamont> yeah, but ... :)
<fabbione> lamont: a kernel backport requires also all the userland tool syncronzation...
<fabbione> and mostoften people have no clue about it
<lamont> very true
* lamont successfully hits 400kbps
<lamont> (avg over 5 minutes)
<Lathiat> heh ive been sitting on about 1300 for the last 30 hours or so
<Lathiat> managed to push it faster than i thought was possible
<fabbione> SPARC KERNEL UNBUSTED!
<lamont> fabbione: coolness!
<fabbione> lamont: at least this is according to BenC. i need to test it ;)
<fabbione> it looks like the error we get at build time are ghosts
<fabbione> and the resulting kernel is still good
<fabbione> so it was never busted
<fabbione> Ben Collins is a machine...
<lamont> if the kernel throws ghost failures, it's not a good kernel....
<fabbione> apparently it's not the kernel ...
<fabbione> scripts/mod/modpost.c
<fabbione> is at fault.. it barfs on sparc64 elf
<fabbione> and that one is linked with glibc
<fabbione> that can explain why the problem shows up only on recent glibc
<fabbione> <@GoodGuy> AHA!
<fabbione> ok he figured
<lamont> checking for shared library run path origin... /bin/sh: ../buildlib/config.rpath: No such file or directory
<lamont> done
<lamont> building apt.  Bad apt.  /me looks at mvo
<mvo> lamont: what did it this time?
<mvo> it does not build? 
<lamont> mvo: apt_0.6.39ubuntu4 should it be bitching about config.rpath not existing during configure?
<mvo> how strange. what architecture?
<lamont> it builds, but it's a wierd errpor
<lamont> hppa
<lamont> bootstrapping the world, so that's mostly hoary bits
<mvo> I don't have a config.rpath here
* lamont looks at the i386 log, just for giggles
<lamont> same output
<lamont> so it's consistent....  but could be an issue, no?
<mvo> does it die from that error? or at some later point? is the buildlog available somewhere?
<lamont> no death.. just crap in the log
<lamont> see also people.ubuntu.com/~lamont/buildLogs/a/apt/0.6.39ubuntu4/apt_0.6.39ubuntu4_20050629-1740-i386-successful.gz 
* lamont happened to be tailing the log file
<lamont> it's not fatal, it just makes me wonder why it's there....
<mvo> lamont: it's a autoconf macro thats there for ages I guess. a bit weird because the macros configure.in look all pretty standard (/me checks again)
<\sh> hey JaneW how is london today? :)
<JaneW> \sh - wet ;)
<\sh> JaneW: hmm...wet? two choices: wet because of hot summer, to much of sweat or wet, like london rain ,-)
<JaneW> \sh: sweat from over heated airport and wet from Londin rain ;)
<\sh> hahaha...ok..this is london :)
<lamont> daniels: you around?
<\sh> JaneW: are u visiting germany after london? on sunday it's CSD time for cologne :) 
<Simira> good morning JaneW :)
<Simira> hm, she didn't like that
<lamont> hi JaneW 
<fabbione> hey JaneW 
<fabbione> lamont: still awake? ;)
<lamont> fabbione: yeah - iterating on xorg - I want to start that 4-hour build before I go to bed
<lamont> but it's not looking good for that
<lamont> Total 4 package(s) in state Building.
<lamont> Total 16 package(s) in state Installed.
<lamont> Total 6080 package(s) in state Needs-Build.
<lamont> woot
<lamont> .25% and climbing. :-)
<fabbione> ahah
<fabbione> A  patches/scripts-mod-modpost_deal-with-new-glibc.dpatch
<fabbione> there!
<fabbione> lamont: phear ;)
<JaneW> hi lamont and fabbione wassup?
<fabbione> JaneW: started digging in VolumeManager
<lamont> JaneW: well, not sleeping yet, although I probably should be...
<fabbione> i need to update the wiki tho
<lamont> thought I'd say hi, since I hadn't in forever
* JaneW didn;t get much sleep last night...
<JaneW> lamont: yeah I haven;t seen you around much... how's HP?
<lamont> daniels: ../../src/lcFile.c:252: warning: implicit declaration of function `getresuid'
<lamont> JaneW: well, busy somewhat
<lamont> JaneW: I almost have my environment where I want it (couple things left), actually getting to do real work instead of administrivia, etc.
<lamont> JaneW: hoping to create time to work on testing and such an ia64/breezy cd sometime soonish
<JaneW> lamont: cool
<JaneW> lamont: is your baby 13 yet?
<lamont> she turns 13 on July 30.  the other turned 10 in May
<lamont> depending, of course, on your definition of 'baby'
* lamont is also reminded that he owes Jane a picture or 3...
<lamont> hrm.. must deal with that tomorrow
* fabbione needs more coffee
<fabbione> Kamion: ping?
<fabbione> Kamion: is there any function in partman* that given a devfs name will return me the device name?
<fabbione> Kamion: eg: /dev/hda1 is a link to /dev/ide/foo/bar
<fabbione> and given /dev/ide/foo/bar i need to get /dev/hda1 back?
<Kamion> fabbione: mapdevfs, in di-utils-mapdevfs
<Kamion> it's an external program
<fabbione> do we install it by default, don't we?
<Kamion> you can call it safely on any device regardless of naming format, as long as the device exists
<Kamion> Depends: di-utils-mapdevfs
<fabbione> ok cool thanks
<fabbione> Kamion: i did quite a lot of progresses already in auto-lvm
<fabbione> Kamion: but there is the problem that pvscan/vgcreate do not recognize the devfs name..
<fabbione> so i need to map it back to get it right
<Kamion> right, that happens
<fabbione> yeah no big deal :)
<elmo> hey, is 'going within 500 miles of devfs' on that "list of things we really should clean up - one day" spec?
<Mithrandir> elmo: aka "uglyhacks"?
<elmo> right, that was it
<Kamion> elmo: yes, there's a "clean up devfs paths" item there
* lamont makes a note to beat daniels over the head for having xorg build-depend libxcursor-dev which build-depends libxfixes-dev which xorg provides
<infinity> lamont : The whole situation will improve when the modularisation is complete.  Bootstrapping xorg right now is a bit unfun, though.
<lamont> infinity: exactly
<doko> wasabi: the last ant upload did break java/gcj :-(  bad idea to upload a new ant with a dependency on a ecj-bootstrap, which failed to build.
<infinity> lamont : I'm working with him to make sure the pain is lessened as quickly as possible.
<infinity> lamont : I have a vested interest in making sure we can boostrap xorg from a xcroched-earth scenario as easily as possible, and he has a vested interest in me buying him alcohol and not killing him in his sleep.  It's a good trade.
<infinity> s/xcorched/scorched/ ... I wonder if that was freudian.
<fabbione> Kamion: we need to consider to remove DEVFS support in the kernel soon. .13 won't have it upstream
<infinity> fabbione : YAY!
<lamont> infinity: right now, it's a matter of installing just the right stuff from hoary, and the right stuff from breezy to make life happier.
<Kamion> fabbione: it's all blocking on jbailey, not me. :)
<fabbione> Kamion: ok :)
<fabbione> Kamion: i am going to ask jbailey nicely to do it before yesterday :P
<fabbione> ;)
<lamont> ok.  sbuild thinks it can handle xorg, now to see if the build-deps actually install without erros
<fabbione> Kamion: i guess i just found the only corner case where mapdevfs doesn't work :P
* fabbione will look after coffee
<Kamion> fabbione: ?
<fabbione> Kamion:
<fabbione> echo $path -> ok
<Kamion> fabbione: it's easy to fix given examples, generally
<fabbione> realpath="$(mapdevfs $path)"
<fabbione> echo realpath -> empty
<Kamion> you need to use mapdevfs $path || true unless you're certain $path exists
<Kamion> what is $path?
<fabbione> path is always set (got it from the a PARTITION_INFO)
<fabbione> it's usually /dev/ide/host0/....
<fabbione> that is mapped to /dev/hda1
<fabbione> works from busybox
<Kamion> fabbione: "works from busybox" - what do you mean?
<lamont> infinity: and it helps to have the morgue nearby. :-(
<fabbione> Kamion: the same 4 lines of above, they work fine if executed in the busybox shell
<fabbione> i assume they use the same shell...
<lamont> infinity: specifically, xorg -32 needs xcursor >=1.3-1ubuntu1; the current xcursor needs an xorg >-10 to be in the archive, and hoary gives you 1.1.3-1 and -10
<Kamion> the shell should be irrelevant
<Kamion> but your poor quoting might be relevant :P
<Kamion> (mapdevfs is a C program)
<Kamion> um - are you trying to run this from a normal system? do you have mapdevfs in $PATH? :-)
<fabbione> Kamion: i did check and try different ones.. i will check again
<Kamion> it won't be installed on normal systems
<fabbione> Kamion: i am running it from inside d-i on a test box
<Kamion> the binary is only shipped in a udeb
* lamont waits to make sure that xorg gets through configure before going to bed
<Kamion> fabbione: yes, but how are you managing to try any shell other than busybox inside d-i?
<fabbione> Kamion: isn't d-i running inside busybox?
<Kamion> d-i uses busybox for lots of stuff, yes
<Kamion> one of us is very confused
<Kamion> step back and tell me in exactly what environment mapdevfs is failing for you?
<fabbione> ok
<fabbione> i started installing the machine. so i have d-i "running" at partioning stage, where i can select "Guided partitioning" -> "Use free space as lvm"
<fabbione> so i do select "Use free space as lvm"
<fabbione> that option runs /lib/parman/automatic_partitioning/60vg_all_free/do_option
<fabbione> i need to run mapdevfs inside do_option
<fabbione> now.. i edit that file from the shell on f2
<fabbione> and tested there that it wasn't failing
<fabbione> but
<fabbione> to add extra debug i added to do_option
<fabbione> echo path $path >>/var/log/messages 2>&1 || true
<fabbione> in a bunch of points
<fabbione> and i can see that $path is ok
<Kamion> ok, if I were you I'd add 'set -x' to do_option and run it from partman
<fabbione> next step:
<sivang> fabbione: Hey there, do we have a working 2.6.12 d-i image already?
<Kamion> sivang: current daily builds
<fabbione> realpath="$(mapdevfs "$path")"
<sivang> Kamion: cool, with all of the ppc64 stuff in right?
<fabbione> echo realpath $realpath >>/var/...
<fabbione> and realpath is empty
<Kamion> sivang: theoretically - untested
<sivang> Kamion: that's where I come into the picutre :-)
<fabbione> Kamion: i am running do_option within partman
<Kamion> fabbione: can you mail me the current do_option, and a set -x dump?
<fabbione> Kamion: not easily... the machine is without anything that can connect to the net atm..
* fabbione will try
<Amaranth> timeless: This is where all the developers are actually at so you don't have to go by my guesses anymore. :)
<lamont> Event.c:1134: warning: function declaration isn't a prototype
<lamont> daniels: and hundreds more... grumble
<lamont> but I suppose that's known
<lamont> anyway, xorg build started, off to bed.
<fabbione> night lamont
<ivoks> ntp maintainer here? mdz?
<Kamion> mdz is travelling, and wouldn't be around at this time of day anyway
<ivoks> ok, thanx
<ivoks> i'll write patch for ntp and send him
<Kamion> bugzilla would be more appropriate
<Kamion> last I checked mdz wasn't the ntp maintainer
<Kamion> in fact he's mentioned precisely once in the ntp changelog
<Kamion> besides, you should always send patches to bug tracking systems rather than individuals if at all possible, otherwise they have a habit of getting lost :)
<ivoks> hehe ok
<ivoks> we talked about ntp yestrday, so I tought he's maintainer
<ivoks> my bad, should've check changelog
<Kamion> fabbione: ok - and what happens if you run mapdevfs on that path from a shell on tty2?
<fabbione> Kamion: it works
<Kamion> erm, boggle
<fabbione> interesting
<fabbione> for some reasons mapdevfs fails in there
<fabbione> i did try a:
<fabbione> realpath="$(mapdevfs $path)" || realpath="test"
<fabbione> and i got test...
<Kamion> all that mapdevfs does is to look at the major and minor numbers of the device file you give it, and work out the traditional path corresponding to those
<Kamion> strace it
<Kamion> (you can get strace.deb and udpkg -i that)
<Mithrandir> it might be a shell bug; doe realpath="$(true)" || realpath="test" give you test or ""?
<fabbione> Kamion: ok
<fabbione> but i still wonder why it works in the other parts of d-i
<Kamion> Mithrandir: never had a problem there
<Kamion> fabbione: let's put it this way ... it's unlikely to be mapdevfs breakage ;-)
<fabbione> Kamion: oh i agree...
<fabbione> i am not blaming mapdevfs
<Kamion> unless the device in question has major and minor numbers that mapdevfs doesn't know about
<fabbione> given that it works from busybox..
<fabbione> i am sure there is something royally wrong in what i am doing...
<fabbione> i just don't get what
<fabbione> AH
<fabbione> the device must exist for mapdevfs to work
<fabbione> so THAT might be the problem
* fabbione sighs at udev
<fabbione> Kamion: our code is too fast :P
<fabbione> BINGO!
<fabbione> Kamion: it's all due to a race condition
<Kamion> you might have to run udevstart
<fabbione> would that speed up?
<Kamion> udevstart forces udev to create all the pending devices
<fabbione> or can i just make a wait_device() ?
<fabbione> ah ok
<fabbione> perfect
<Kamion> we use it in hardware detection already
<Kamion> obviously wrap it in an existence guard
<Kamion> if type udevstart >/dev/null 2>&1; then
<Kamion>         udevstart
<Kamion> fi
<fabbione> ok
<Kamion> then we can commit it to Debian too
<fabbione> yup...
<fabbione> Kamion: another question to speed up testing.. how can i preseed all the d-i answer from boot to partman (excluded) so i don't need to spend half of the time chaning mirror and accepting keyboard?
<Kamion> http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-i386/current/doc/manual/en/apcs01.html
<fabbione> thanks
<Kamion> preseed/locale, keymap, hostname, mirror should be sufficient
<fabbione> yup
* fabbione starts to feel a d-i hacker :P
<HiddenWolf> fabbione, isn't the kernel enough for you? ;)
<fabbione> HiddenWolf: ehhe
<fabbione> HiddenWolf: i will never ever be at the level of Kamion ;)
<fabbione> he is the "d-i allmighty ;)"
<Treenaks> fabbione: that's what you said about kernel addiction
<Kamion> I've only been at it for a year and a half, dude :)
<fabbione> Kamion: still > than my last hmmm .. 10 hours?=
<Kamion> One of the many problems with moving house is that I can't find my big stash of DVD-RWs. Bah.
<Kamion> Ah, here they are. Now I can *test more than one image at once*. Advanced technology.
<fabbione> lol
<fabbione> Treenaks: yeah yeah :)
<Kamion> drat, breezy-install-powerpc.iso fails to get as far as the main menu
<fabbione> Kamion: there are a few details that need to be updated for the preseed docs
<Kamion> yeah, I have a recent bug about that
<fabbione> ok
<Kamion> suggestions welcome
<fabbione> Kamion: do you rememebr the bug number?
<Kamion> not offhand, sorry - searching for 'preseed' should find it
<fabbione> ok
<Kamion> eh?! it's hanging in /lib/debian-installer-startup.d/S35initrd-preseed
<Kamion> that's straying into impossible territory
<fabbione> i blame jbailey
<Kamion> + [ -e /preseed.cfg ] 
<Kamion> [hangs] 
<Kamion> I blame the kernel :-P
<fabbione> i really don't :)
<Kamion> hmm, possibly an overly-scratched disk
<Kamion> bizarre symptoms, though
* fabbione kicks the kernel option max lenght
<Kamion> that's been fixed in 2.6.9 surely
<fabbione> Kamion: i am not sure if it's syslinux the problem
<Kamion> although my documentation of that may not have made it to our archive yet
<fabbione> the string it's truncated after N chars
<Kamion> what's N?
<fabbione> didn't check yet...
<Kamion> # Note that the kernel accepts a maximum of 8 command line options and
<Kamion> # 8 environment options (including any options added by default for the
<Kamion> # installer). If these numbers are exceeded, 2.4 kernels will drop any
<Kamion> # excess options and 2.6 kernels will panic. With kernel 2.6.9 or newer,
<Kamion> # you can use 32 command line options and 32 environment options.
<fabbione> yes the kernel boots fine.. 
<fabbione>        append vga=normal initrd=initrd.img-crack ramdisk_size=14972 root=/dev/rd/0 rw preseed/locale=en_US console-keymaps-at/keymap=Danish kbd-chooser/method="Danish" netcfg/choose_interface=eth0 netcfg/get_hostname=gundam preseed/url=http://192.168.1.1/pd --
<fabbione> that's almost the limit
<fabbione> now i need to understand why d-i doesn't like my preseed fine...
<fabbione> s/fine/file
<fabbione> hell this is fun
<Kamion> if you're building your own initrd, you could put the preseed file in there and use preseed/file= instead
<fabbione> who wants to maintain the kernel for a while?
<Kamion> which would let you put the netcfg stuff in the preseed file instead of on the command line
<fabbione> no i am using the standard initrd
<fabbione> i am trying very hard not to diverge
<fabbione> hi sabdfl 
<sabdfl> hiya
<Simira> morning sabdfl 
<sabdfl> hey Simira, how's norway today?
<fabbione> Kamion: can you show me a preseed file example?
<sabdfl> Kamion: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=196697 doesn't seem to have a status, is the default 'open'?
<fabbione> http://www.fabbione.net/pd <- is mine
<Simira> sabdfl: nice and sunny. And stressful. We're moving to Oslo (50km) tomorrow.
<fabbione> and d-i refuses to like it :)
<sabdfl> Simira: what's prompting the move? big city bright lights?
<Kamion> mozilla-firefox 196697 1055132296 open [Adam Heath <doogie@debian.org>]  wishlist
<Kamion> seems to have a status
<sabdfl> Kamion: what gives you that?
<Simira> sabdfl: yup. And Tollef longing home ;p How about you? Are you going to DebConf?
<Kamion> sabdfl: that's in index.db
<Kamion> oh, I guess you're looking at the summary
<Kamion> or not
<sabdfl> Kamion: i'm using the debbugs.py which shells out to the Debbug.pm so a whole bunch of things could be going South :-)
<sabdfl> let me just rsync up...
<Kamion> any idea where it gets the status from? I forget
<Kamion> laptop's doing test runs, don't have a debzilla checkout here
<Kamion> hmm, debbugs.py effectively greps index.db
<Kamion>         index_record = re.compile(r'^(?P<package>\S+) (?P<bugid>\d+) (?P<date>\d+) (?P<status>\w+) \[(?P<originator>.*)\]  (?P<severity>\w+) (?P<tags>.*)$')
<Kamion> oh, hey, that regex assumes that there are some tags
<sabdfl> hmm... debbugs.py.Database.load() seems to miss out on status
<Kamion> sabdfl: the regex should be ... (?P<severity>\w+)(?: (?P<tags>.*))?$
<Kamion> sabdfl: or something along those lines
<sabdfl> Kamion: i'll try that, but i think that's orthogonal
<Kamion> making [space <tags>]  optional
<Kamion> >>> import re
<Kamion> >>> index_record = re.compile(r'^(?P<package>\S+) (?P<bugid>\d+) (?P<date>\d+) (?P<status>\w+) \[(?P<originator>.*)\]  (?P<severity>\w+) (?P<tags>.*)$')
<Kamion> >>> print index_record.match('mozilla-firefox 196697 1055132296 open [Adam Heath <doogie@debian.org>]  wishlist')
<Kamion> None
<Kamion> >>> index_record = re.compile(r'^(?P<package>\S+) (?P<bugid>\d+) (?P<date>\d+) (?P<status>\w+) \[(?P<originator>.*)\]  (?P<severity>\w+)(?: (?P<tags>.*))?$')
<Kamion> >>> print index_record.match('mozilla-firefox 196697 1055132296 open [Adam Heath <doogie@debian.org>]  wishlist')
<Kamion> <_sre.SRE_Match object at 0x2a9558cc68>
<Kamion> apologies for flood - but it looks like the right fix to me
<Kamion> surprised debzilla hasn't run into this all the time
<sabdfl> maybe it's a Debbugs/pm version thing?
<Kamion> very unlikely, that has nothing to do with the perl glue
<Kamion> it fetches and reads index.db directly from python
<Kamion> the perl glue is only used to parse .log files, which are way after working out the bug's status
<fabbione> bah
<Kamion> fabbione: will have a look at the preseed file in a sec
<fabbione> done
<fabbione> Kamion: i just found the error :)
<fabbione> thanks a lot anyway
<fabbione> but for sure you can tell me if i can preseed anna from it
<Kamion> fabbione: hmm, looked ok to me
<fabbione> yeah i just fixed it :)
<Kamion> what needs to be preseeded in anna?
<fabbione> to load partman-auto-lvm
<fabbione> since it won't fit in the syslinux.cfg
<Kamion> yes, 'd-i anna/choose_modules multiselect partman-auto-lvm'
<fabbione> but i don't see any anna preseeding in the example
<Kamion> works for netboot anyway, I'm not sure it's guaranteed for cdrom
<fabbione> iam using only netboot
<fabbione> for testing is way faster
<Simira> how broken is Breezy now?
<Simira> do I want to run an upgrade?
<fabbione> Simira: if you feel lucky today :)
<sabdfl> Kamion: think i've narrowed it down, see privmsg
<Simira> fabbione: luckiest ever. We're preparing tomorrows moving, and it's my birthday tomorrow. Hm. Maybe I should wait until tomorrow, then? ;p
<fabbione> Simira: good idea to wait after the movement if you don't want to spend the rest of day fixing your machine ;)
<Simira> fabbione: ok,thanks. I can always boot in windows, anyway. 
<fabbione> Kamion: YAYAYAYY the udevstart did it..
<fabbione> Kamion: i got my first set of lvm partitions from preseeding and so on ;)(
* fabbione is happy enough to go and eat
<Kamion> fabbione: well done
<fabbione> Kamion: nah.. thanks to you..
<Kamion> so I think my laptop's CD-ROM drive is hosed, or needs cleaning, or something :(
<Kamion> which means no powerpc CD testing, unless somebody would like to volunteer
<fabbione> Kamion: netboot?
<Kamion> no, CD
<sivang> Kamion: I'm going to do ppc64 in a LPAR testing sometime soon
<Kamion> I mean, yes, I could netboot, but that isn't much good for CD image testing
<Kamion> sivang: I was kind of thinking more "in the next hour" :)
<sivang> Kamion: ah :-) Sorry, I wish I could .....
<Kamion> though, cool
<sivang> Kamion: I wonder if d-i would recognize the virtual disks, and virtual NIC I will set up for it
<fabbione> sivang: mostlikely not if that's an iseries machine
<fabbione> afaik an LPAR ppc64 needs iseries
<fabbione> and we don't have udebs for it yet
<fabbione> anyway food....
<sivang> fabbione: bon appetite
<fabbione> Kamion: we might need to add a template and i think i just found a corner case that might be problematic to handle...
<fabbione> Kamion: a) we need "Erase entire disk and make it lvm"
<fabbione> b) we might have a system with N harddisks.. should we consider them all for inclusion in the lvm of point a) ?
<fabbione> the latter is a rare case but it might happen..
<fabbione> jbailey: i was talking with Kamion before about killing devfs from the kernel...
<fabbione> jbailey: any ETA for when you will be ready for it?
<Kamion> fabbione: a) ideally yes, although I'm a little concerned about adding too much stuff to the partman main menu
<Kamion> fabbione: b) let's not worry about it for now :-)
<fabbione> Kamion: a) we need that option if we want to switch later as default. Otherwise i need to mangle the meaning of use free space as lvm to achive installation...
<fabbione> and that won't be nice
<fabbione> b) i agree :)
<jbailey> fabbione: Oy.  I need to get myself an lvm system them... hmmm..
<jbailey> Apparently the tetris music has words..  either that or one russian song sounds like another to my ears (also quite possible)
* jbailey wonders how the CBC morning DJ chose that.
<Kamion> fabbione: oh, sure, but it's trivial to add
<Kamion> fabbione: it's autopartition $dev rather than autopartition $dev $id
<fabbione> Kamion: didn't get there yet :)
* fabbione wonders if preseed/early_command can be used to grab a modified version of p-a-l
<sivang> jbailey: Jeff! Hi , 'sup ?
<jbailey> Sivan!  Long time. =)
<\sh> hmmm...anyone up to a really special question? how can I convert a HD with ext3 to xfs, without losing data? ,-) any possibility, or just even: reinstall and format with xfs?
<Lathiat> \sh_away: you dont :P
<Lathiat> \sh_away: depend show full it is ;)
<fabbione> Kamion: i guess an error like: "10 p-a-l/text/vg_all_free doesn't exist" means that the template is not registerd....
<fabbione> (i am trying to install p-a-l from preseeding instead than from the archive to make customization simpler)
<Kamion> fabbione: yes
<fabbione> and let me guess... this is the exact problem you were describing about templates registration :)
<Kamion> ayup
<fabbione> hmmm
<Kamion> anna gets it right
<fabbione> it's interesting.. because the udeb is downloaded before anna gets to run
<fabbione> so the templates are there...
* fabbione looks at anna's code
<resmo> hi
<resmo> is there any action to integrate php5 in breezy?
<fabbione> Kamion: i think it would rather easy to patch anna to install a local deb :)
<fabbione> Kamion: given that anna is capable of installing the templates properly
<Kamion> probably better to make udpkg do it right, imho
<Kamion> although actually that doesn't help you
<Kamion> now that I remember, the problem is not anna vs. udpkg
<Kamion> it's running something in tty1 (subprocess of the main running debconf instance) versus running it from a shell on tty2
<sivang> Kamion: what does anna do?
<HiddenWolf> who is the thunderbird maintainer?
<Kamion> sivang: roughly, apt equivalent for d-i
<fabbione> Kamion: it's interesting that templates.db isn't updated at all 
<Kamion> fabbione: the problem is that there's no mechanism for something you run by hand on tty2 to communicate with the main running debconf instance on tty1 to tell it to load new templates
<fabbione> Kamion: the template file it's simply not changed
<Kamion> fabbione: it almost certainly is, but gets overwritten shortly afterwards when debconf on tty1 next saves
<fabbione> oh hmm
<Kamion> we need some kind of out-of-band communication, maybe a signal you send to debconf after fiddling with templates.db
<fabbione> Kamion: no.. it's not modified at all
<Kamion> udpkg calls debconf-loadtemplate when it sees a .templates file
<fabbione> hmmm ok. you are right...
<fabbione> using the example doesn't exactly help :)
<fabbione> i keep forgetting how restricted is debconf on checking stuff around
<rob^> is dvd+/- r support compiled into the breezy version of cdrecord?
<rob^> from what I can tell it isnt
<Lathiat> rob^: use growisofs
<fabbione> Kamion: i have the solution :)))))
<rob^> Lathiat, what package is that in? apt-cache search shows nothing
<fabbione> Kamion: http://www.fabbione.net/pd <--- install it in tty1 if you can't from tty2 :)
<Lathiat> dvd+rw-tools
<rob^> ah ok thanks
<Kamion> fabbione: yeah, that would do it
<fabbione> Kamion: it works :)
<fabbione> it can't work for everything.. but still better than nothing
<Kamion> GRRR. I have absolutely no idea how to make this initrd work. It is breaking for no reason.
<Kamion> and it's fine on i386, but broken on amd64 and powerpc
<fabbione> Kamion: can you get a strace to see where/why it hangs?
<Kamion> I've been trying, but no luck yet
<jbailey> Kamion: I have ppc here, I can troubleshoot if you need.
<Kamion> jbailey: if you can try cdimage/daily/current/breezy-install-powerpc.iso, that would be wonderful
<Kamion> jbailey: I mean the d-i initrd, of course, not the initrd-tools one
<Kamion> but at this level the skills required to debug it are likely to be rather similar :)
<jbailey> Oh, I thought you meant initrd-tools. =)  Sure, lemme pull it down.  It'll take awhile to come down, my connection to the data centre sucks.
<Kamion> it seems to be hanging in one of /lib/debian-installer-startup.d/S{30env,35initrd}-preseed
<Kamion> hmm, /var/lib/cdebconf/*.dat are empty
<fabbione> Riddell: ping?
<Kamion> /usr/share/debconf/frontend is sitting waiting on a futex ...
<fabbione> glibc bug?
<Kamion> I can't quite tell what it's *really* trying to do yet
<jbailey> fabbione: There are no glibc bugs, just applications that use functions they weren't meant to use.
<fabbione> ehhehe
<Riddell> fabbione: hi
<fabbione> hi Riddell 
<fabbione> Riddell: if you have a minute, could you try to build kdesdk in a clean breezy chroot?
<fabbione> Riddell: it seems to be FTBFS on sparc because of missing b-d
<fabbione> libxi-dev ;)
<fabbione> but perhaps you want relook at it
<Riddell> fabbione: quite possible, I'll do that now
<Riddell> I wonder what other packages have been caught with that libxi-dev move
<Kamion> damnit, the problem goes away when I strace it
<Kamion> or possibly when I install the unreduced libc6 in order to be able to run strace
<fabbione> Riddell: thanks :) 
<fabbione> Riddell: probably quite a lot of packages....
<fabbione> Kamion: since when d-i needs poxml from kdesdk to build? :P
<fabbione> jbailey: told you it's a glibc bug :)
<Kamion> fabbione: docs
<fabbione> Kamion: 02_add_menu_entry.diff <- on roockery :)
<fabbione> Kamion: yeah i could guess so...
* jbailey only has 43 minutes left until the ISO comes down.
<Kamion> jbailey: any thoughts on how I could even start to debug this?
<jbailey> Kamion: Can you reproduce in a chroot on the running system with the reduced glibc?
<Kamion> hmm, ok, I'll try that
<fabbione> jbailey: you will need to update klibc b-d to linux-headers-2.6.12-3
<jbailey> fabbione: 'kay, thanks.  I'll try to fix the last couple things that keep it from using lkh directly.
<fabbione> jbailey: yup.. i just noticed.. it's nothing urgent for me
<jbailey> Kamion: If you can get this working, you can strace/gdb/etc from outside the chroot.
<Kamion> I'm wondering if it might be a 2.6.12 thing.
<fabbione> Kamion: i doubt.. otherwise it would effect i386 too
<Kamion> depends
<fabbione> Kamion: are you using the ppc64 kernel?
<Kamion> fabbione: no
<fabbione> so we have 32/64 bit + endianess.. iirc that ppc is != i386 endian
<lamont> daniels: ping
* fabbione goes offline for a while
<maswan> fabbione: heh. good timing on offlining, I just rebooted buttercup
<fabbione> maswan: thanks a lot
<maswan> fabbione: aren't you supposed to be offline? ;)
<fabbione> maswan: well yeah.. i decided to update the wiki and i saw my screen blinking :)
<maswan> fabbione: :)
<fabbione> maswan: thanks a lot dude :)
<maswan> fabbione: sure. feel free to fix the kernel too. ;)
<fabbione> maswan: ehhe
<lamont> mvo: apt-preferences question for you... how do I tell apt that if version X of package foo exists in repository Y with a different md5sum than in repository Z, to ignore the one in Z completely. :-)
<fabbione> CRACK
<lamont> fabbione: LOL
<mvo> thanks fabbione for pointing that out
<lamont> Preparing to replace diff 2.8.1-7 (using .../archives/diff_2.8.1-7_hppa.deb) ...
<mvo> lamont: so you have two debs with identical version but different md5sums :) ?
<lamont> mvo: yeah.  it happens when you build everything for hoary, and then have to rebuild it from scratch for breezy because the archive doesn't exist.  But the same version is in both hoary and breezy
<mvo> lamont: that's a tricky one. wouldn't pinning help you?
* fabbione goes offline for real
<lamont> mvo: pinnings are as follows:
<lamont> a=breezy == 1650 and 640 (yeah, well, autogenerated, and all that), o=Ubuntu == 630
<lamont> wonder if it's the 1650 thing
<lamont> hoary and breezy are in sources.list, since breezy's kinda sparse atm
<lamont> not a big deal though
<mvo> you always produce the most interessting use-cases for apt :)
<lamont> always glad to do my part. :-)
<mvo> I'm only glad that you don't use X that often (other then for xterms) otherwise would probably get quite a few interessting synaptic bugreport ;)
<mdke> documentation meeting now in #ubuntu-meeting :D
<lamont> mvo: what's synaptic? :0)
<lamont> that's some gui thing, right?
<lamont> iz gtk bug
<mvo> heh :P
<Mithrandir> elmo: could I please have xorg's build-deps in the breezy chroot on concordia?
* dilinger giggles
<dilinger> "This fix is also _officially_recommended_ by upstream"
<dilinger> i love when people say that in relation to php fixes, as if that holds weight (because upstream is so wise!)
<`anthony> just thought I'd check in here first (haven't been able to find anything similar in bugzilla) - when I put my laptop to sleep (to mem) and wake it up, the 'lo' device doesn't get ifupped automatically. 
<`anthony> this makes any number of Bad Things happen.
<lamont> `anthony: that's strange
<`anthony> aha! I wonder. I have an if-up.d script that restarts certain flaky processes (e.g. kio_imap). On wakeup, that might be failing and exiting with non-zero status. Could that then make the network startup abort?
<`anthony> just added an exit 0 to the end of that script, see if that makes it better.
<lamont> non-zero exits would have that effect
* lamont goes to get ready for work
<`anthony> lamont: should it? 
<lamont> `anthony: it's in the spec that non-zero exit causes ifup failure (for up, and pre-up in interfaces, that is...)
<lamont> I expect if-up.d is the same wayh
<elmo> GAR
<davyd> so... who wants to start the unofficial Ubuntu/Alpha port?
<zul> uh no one i think
<davyd> http://webcam.ucc.asn.au/ <-- mmm, alpha
<lamont> davyd: I know that the hppa port is being pushed by someone with a serious personal investment in hppa, just to please about 4 users worldwide. :)
<zul> my...such a wide user base you have lamont ;)
<lamont> zul: shaddup. :-)(
<elmo> has no one really done a file overwrite checker thing yet?
<Kamion> djpig did one for Debian I think
<lamont> elmo: zgrep , Contents-i386.gz
* lamont ducks
<Mithrandir> it should really be part of linda or something.
<Mithrandir> or katie could refuse to accept binaries with just "buggy" as the reject message.
<lamont> elmo: this would be a check that if the deb in question delivers the same file as another package, that it conflicts with it?
<elmo> yes
<Kamion> Mithrandir: "rejected: kthxbye"
<elmo> there's a file overwrite in linux-sound-base ATM I keep running into and it's annoying me
<elmo> it's such an obviously automateable check, you'd think
<Kamion> I guess it's a question of, which .deb do you reject
<zanaga> where should i file a bug about beagle package?
<Kamion> hmm, well the new one ought to have a Replaces regardless, I suppose
<zanaga> malone says, no such package..
<Mithrandir> elmo: anyhow, thanks for fixing build-deps.
<elmo> Mithrandir: np
<lamont> zul: sometimes a small user base is good... hurts less when you have an archive event
<maswan> davyd: what you need is people willing to put in lots of work (you?) and some machines. :)
<davyd> maswan: we have the machines
<davyd> http://webcam.ucc.asn.au/
<davyd> 7 dual EV6 800MHz alphas
<lamont> davyd: I'm happy to help a technically savy person come up to speed on bootstrapping the archive
<maswan> davyd: Wow. Another university computer club. neat. :)
<davyd> maswan: we're possibly the oldest one
<Mithrandir> I wonder how long xorg takes to build.  I guess I'll find out.
<davyd> maswan: we're older then the homebrew computer society by a year
<lamont> Mithrandir: on concordia, with ccache, not all that long
<lamont> ~30 min?
<davyd> lamont: well, it's my immediate goal to get them all booting something
<Mithrandir> lamont: that's not bad
<maswan> davyd: lysator started in 72-73
<lamont> xorg:                   00:35:53 (17 entries, sigma 00:10:24)
<lamont> that's amd64
<davyd> I got the big dual 750 on the floor to netboot the sarge installer this evening
<davyd> then managed to break it trying to give it 2.6
<davyd> lamont: what's the approximate requirement on disk space?
<elmo> lamont: oh oh, lemme try that on hutte
<lamont> hutte?
<maswan> davyd: but neat, we're much younger (90ies). but we have some neat stuff to play with anyway. :)
* lamont points elmo at the other window
<maswan> davyd: no alphas, but lots of ppcs and sparcs. :)
<davyd> these babies were donated by my new work
<lamont> anyway, must really go get ready for work. back in 20-30 min
<maswan> davyd: neat. no webpage of "this is our hardware"? :)
<davyd> maswan: yeah, but it's dodgily out of date in parts
<davyd> http://www.ucc.asn.au/machines/
<davyd> we've recently received a heap of donations, and spent a heap of money
<davyd> for example, our machine Manbo now has 11G of RAM in it
<maswan> neat
<maswan> davyd: http://www.acc.umu.se/technical/hosts/index.html.en
<davyd> maswan: oh, you're ACC?
<maswan> davyd: recent donations include a 10-cpu 7-gig E4500
<maswan> davyd: yes
<maswan> davyd: heard of us? :)
<davyd> maswan: rocking
<davyd> maswan: we want your bandwidth ;)
<davyd> maswan: yeah, we just bought an E4k
<maswan> davyd: we want your E6000 and floorspace. ;)
<davyd> to get some more fast cpus for our E6k
<maswan> heh
<davyd> the E4k currently netboots Sarge
<davyd> maswan: we're low on space
<davyd> and available current
<davyd> and available cooling
<maswan> running a 2.6 kernel?
<maswan> yes, of course
<davyd> we're not sure what we're going to do with these alphas
<davyd> we can fit them in the rack, but I don't think we can provide them all with power at the same time... yet
<davyd> I should update the machines page at some point to include some of our new machines
<davyd> also, the fact that someone blew up our Ultra 30 :(
<maswan> davyd: ah, (partial) suckage.
<maswan> :(
<davyd> I did find an Ultra 60 though, that we might be able to have for free instead
<davyd> we need more desk space
<maswan> hmm.. acutally, we might have about as much floorspace. just never enough. and never enough cooling either. ;)
<maswan> We also have a rack full of 4-gig drives that currently serve as $HOME for all users. :)
<maswan> davyd: our terminal room: http://www.acc.umu.se/images/archive/20050419-Mek/index.html?view=100_1609.JPG
<davyd> our home is currently 40G... but I don't think the entire LVM has been mapped yet
<maswan> http://www.acc.umu.se/images/archive/20050308-Mek/index.html?view=100_1559.JPG
<maswan> important admin aids :)
<davyd> served off our opteron, martello
<maswan> http://www.acc.umu.se/images/archive/20050302-Hjulafton/index.html?view=IMG_5116.JPG
<maswan> the computer room
<davyd> your racks have doors!
<davyd> and you appear to have an Indigo2 on the flor
<maswan> well, the SP frames have doors
<Kamion> jbailey: I can't reproduce the problem under strace in a chroot either
<Kamion> jbailey: although I can reproduce it in a chroot, at least sometimes
<davyd> I think your machine room is bigger then ours
<davyd> it seems that gallery has eaten the photos of our machine room again
<maswan> davyd: probably, it is a bit bigger than that, we fit two more racks behind/left of the visible black SP frame door
<davyd> we currently have two racks, and the E6k on one side
<mdz> wasabi: looks like eclipse failed very early, applying a patch?
<mdz> trying patch org.eclipse.jdt.core_ecj-options.patch at level 0...1...2...3...failure.
<mdz> make: *** [patch-stamp]  Error 1
<jbailey> Kamion: Is the program threaded?
<wasabi_> I know, im looking at it.
<wasabi_> Just got into work. uploaded it before I left. ;)
<davyd> and on the other side is shelving and a desk
<Kamion> jbailey: no
<davyd> we could rip all that shelving out, but we just can't get enough air flow through the room
<Kamion> jbailey: it links to libdl, libtextwrap, libc, libdebian-installer
* jbailey tries to think of what sort of other non-kernel bug would cause strace to keep it from showing a failure.
<davyd> maswan: aah, I see you want a drinks server
<davyd> anyway, it's about time to sleep
<davyd> work tomorrow
<maswan> davyd: 'night. talk to you later
<davyd> maswan: there needs to be some sort of world wide computer club convention
<davyd> where we can spend a day dicksizing
<davyd> anyway... g'nit
<maswan> davyd: yes. we have one for the nordic computer clubs, yearly. perhaps you want to send a foreign delegation? :)
<davyd> maswan: yeah, I've seen that
<davyd> I think northern europe is a bit out of our way ;)
<Mithrandir> maswan: I think that would be very welcome.  I know some efforts have been tried to get interest from Foreign Places, but without luck so far.
<maswan> davyd: well, put a propeller at your silly little island and move it up here? ;)
<davyd> It would rock though ;)
<davyd> maswan: heh
<davyd> I should get my EU passport
<davyd> I've been thinking about moving to Europe for a while now
<maswan> :)
<davyd> damned pricey move though
<maswan> Mithrandir: well, long-way travel for students suck, cost-way
<davyd> anyway, sleep time
<Mithrandir> maswan: we get it all refunded from our university, IIRC
<Mithrandir> it just takes like two thirds of a year
<maswan> Mithrandir: oh, neat. we don't. :)
* ..[topic/#ubuntu-devel:ogra] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko
<mvo> elmo: please sync memtest86+ (override ok)
<Mithrandir> daniels: around?
<Mithrandir> daniels: would you mind if I fixed the pkg-config issues in xorg and did an upload?
<daniels> Mithrandir: absolutely not
<daniels> Mithrandir: define 'pkg-config issues in xorg'
<Mithrandir> "putting the .pc files in the wrong place so stuff FTBFS"
<Mithrandir> it's a two-line fix to debian/rules and a slight adjustment to four *-dev.install files.
<daniels> is this /usr/X11R6/lib/pkgconfig vs /usr/lib/pkgconfig?
<Mithrandir> yes
<Mithrandir> pkg-config should not look in random sets of directories just because somebody thought /usr/X11R6 was a brilliant idea fifteen years (or so) ago. :-)
<daniels> bah
<daniels> i'm the only one that's allowed to have ideological purity
<mdz> wasabi: ah, you fixed it :-)
<Mithrandir> daniels: anyhow, would you mind me just fixing it?
<wasabi_> yay me
<wasabi_> "fix"
<wasabi_> I just disabled the questionable patch.
<wasabi_> I am curious why it worked for me, but not THAT curious. heh.
<Kamion> mdz: please merge colin.watson@canonical.com--2005/debzilla--index-format--0
<mdz> Kamion: safe to put it straight into production?
<Kamion> should be, yes
<Kamion> hmm
<Kamion> one sec, just want to check what happens if <tags> is undefined
<mdz> Kamion: hmm, was that causing lots of bugs to be invisible to debzilla?
<Kamion> probably
<Kamion> just noticed a problem, fixing
<daniels> Mithrandir: feel free -- i'm not owrking until sunday
<Mithrandir> daniels: hooray! ;-)
<Kamion> mdz: ok, merge again please
* lamont -> work
<wasabi_> man, I am an impatiant person.
* wasabi_ paces until the buildds try to build eclipse
<Kamion> damn, jbailey left
<mdz> Kamion: merged and deployed
<Kamion> the cdebconf hang appears to be in confmodule->run(), which forks
<Kamion> mdz: thanks
<mdz> I will be somewhat displeased if suddenly 5000 new bugs appear in bugzilla :-)
<Kamion> I'm fairly sure you wrote that code, not I ;-)
<Kamion> although I may misremember
<mdz> yes, it was me
<mdz> I would expect to have noticed a long time ago
<mdz> if we weren't importing RC bugs unless they had tags
<Kamion> mdz: I figured either it was masked by something else, or most RC bugs in practice ended up having tags at some point
<mdz> Kamion: the space is never there in the index unless there are tags?
<Kamion> the latter hypothesis has probably been fairly reliable of late
<Kamion> mdz: I don't believe so
<mdz> Kamion: I consider it a bug to omit the field delimiter just because the field is null :-P
<mdz> brb
<wasabi_> SUCCESSFULY
<wasabi_> yay
<wasabi_> You may now apt-get install eclipse.
<mdz> wasabi: doesn't it need to be built and uploaded first? ;-)
<wasabi_> Well, it's built.
<wasabi_> So it's probably uploaded. ;)
<mdz> wow, short build
<Kamion> mdz: it seems I was wrong
<wasabi_> Yeah, I disabled the gcj native enhancements for the first upload.
<Kamion> mdz: the space does seem to be there
<Kamion> mdz: I was fooled by the way the example sabdfl happened to pick was exactly 80 characters long, so I didn't notice the trailing space
<elmo> wasabi: dude?
<elmo> wasabi: what's up with eclipse-efj, it seems only tyo have a 454 byte binary and minimumal docs?
<\sh> wasabi: and there is a file missing for /etc/java-vm/ something...u put that into the package, but it will never be installed ;)
<wasabi_> It's going to be more. ;0
<wasabi_> elmo, it's going to eventually be a full binary, with a proper man page, etc.
<wasabi_> I just wanted to get it "working".
<wasabi_> Is that not acceptable?
<wasabi_> it will be a command line code formatter. Something Fedora introduced in a set of patches to Eclipse.
<seb128> wasabi_: somebody asked about "cdt", does the package have it?
<wasabi_> No. I am working on it though.
<seb128> cool, thanks
<wasabi_> It's a seperate Eclipse development plugin.
<seb128> any idea if that's a lot of work?
<wasabi_> It will be some, yes.
<seb128> k, keep the good work so :)
<wasabi_> heh
<seb128> thanks :)
<wasabi_> Do we have a nice Ubuntu logo in a package anywhere? Just the plain logo. Icon form, but bigger than an icon
<wasabi_> Ah there we go. One with the gdm theme.
<Kamion> oh my GOD
* Kamion finds cdebconf's signal handler
<Kamion> signal handlers are not meant to save databases
<elmo> heh
<Kamion> if this is why I've spent the entire day tediously stepping through d-i init code in a chroot, I'm going to hurt someone very badly
<carstenh> jeff bailey's nick in irc is?
<stratus> carstenh, jbailey
<carstenh> stratus: thanks
<stratus> np
<carstenh> hmm, is he usually here?
<ogra> carstenh, yep
<carstenh> thanks ogra 
<xTina> I'm not sure if this is the right place to ask, but are there any plans for implementing support for "--onpart" in kickstart files? Or is there way to achieve similar functionality with d-i preseeding using partman recipes? Or will I have to do something nasty to the installer to preserve existing partitioning and format just a few of them during a fully automated install?
<Kamion> xTina: iirc partman-auto preseeding didn't let me implement that
<ska-fan> Stephan Hermann?
<xTina> Kamion: That's what I suspected after looking at partman :(
<Kamion> oh, hi colinw, long time no see
<\sh> ska-fan: yes
<ska-fan> \sh: Ah, that's you. You know #postgresql, right?
<\sh> ska-fan: no :)
<colinw> Kamion: hello
<ska-fan> \sh: Now you do :)
<\sh> ska-fan: i just started to have a look on postgresql
<\sh> ska-fan: and right now, I didn't have any crash for a long time now ;)
<ska-fan> \sh: #postgresql is very helpful and friendly. And you can ask me about anything when I'm online :)
<\sh> ska-fan: good to know :)
<Kamion> xTina: yeah, just checked, it'd require partman-auto extensions; without that it would be nasty
<xTina> Kamion: partman-auto extensions?
<Kamion> xTina: ability to nominate a device
<pitti> Hi guys
<xTina> Kamion: Is there any easy way to get around this? I have a lab here that's dual-boot and I must not touch the partitioning. We've been using Fedora before, so I'm not really familiar with anything but ks. I was thinking on the line of getting my own udeb with just a shell script in there that depends on e2fsprogs-udeb ... but maybe there's an easier way?
<Kamion> xTina: I think there'll have to be a bit of coding involved; you could create the partitions you need and mount them all under /target, bypassing partman entirely
<carstenh> hi ex-mentor :)
<pitti> Hi carstenh 
<xTina> gotta run, thanks Kamion 
<enTr> alien
<enTr> help?---what is alien
<pitti> elmo: ruby1.8 sync, please
<enTr> how to install using alien
<elmo> pitti: same question I asked yesterday?
<enTr> how to use debian-alien to make installation?
<enTr> somebody help please...
<carstenh> enTr: alien converts rpm to deb
<carstenh> enTr: i don't think you need this
<enTr> i try but cannot
<carstenh> enTr: converted rpms suck
<enTr> but how to install vm ware that give me two type of installer 1. *.rpm 2.*.gz... 
<carstenh> enTr: are you sure that you really want to install alien-converted rpms?
<pitti> elmo: I didn't get your question any more
<JanC> enTr : alien only converts .rpm --> .deb
<enTr>  ic... 
<carstenh> enTr: shrugs, i never used vm-ware
<JanC> then you have to install it with dpkg -i
<JanC> but like carstenh says: it might sometimes cause problems
<elmo> pitti: will it kill my amd64 buildds?
<JanC> because the program isn't compiled for Ubuntu
<enTr> ic... actually i just install ubuntu into vmware and try to install the vm-tool there but something i didn't know how to use linux at all...
<pitti> elmo: well, my 7ubuntu1 upload to breezy went fine
<elmo> pitti: hum.  I wonder what ruby upload was killing them then
<mdz> JanC: alien converts any-to-any
<pitti> elmo: it was just the hoary build that caused trouble, warty worked as well
<elmo> lamont/infinity?
<elmo> ah, ok
<carstenh> enTr: do you know man?
<enTr> do you have any suggestion where i can find a list of linux command
<carstenh> enTr: "man alien" tells you how to use it
<enTr> please..
<mdz> enTr: please use #ubuntu for support; this channel is for development-related discussion
<enTr> ic thanks...
<lamont> elmo: ping
<elmo> lamont: ?
<mdz> Kamion: how is BrandingForDerivatives going?
<bddebian> Heya
<hughsie> ogra: ping?
* Mithrandir does Yet Another Compile of xorg.
* Mithrandir hugs the battlestar
<elmo> how long is it taking concordia?
<ogra> hughsie, :)
<hughsie> ogra, hello my friend
<hughsie> ogra: http://article.gmane.org/gmane.comp.gnome.powermanager.devel/237
<ogra> hughsie, nice screenshots :)
<hughsie> you like?
<ogra> yep
<Mithrandir> elmo: half-hour-ish
<elmo> ?! really?
<Kamion> mdz: no progress since last status report on that page I'm afraid, I've been busy on other items
<hughsie> ogra: then we can have my informative icons and theme the mains ones like davidz suggested
<ogra> hughsie, i like the fact to have all info available without havig 485248 icons in the try :)
<ogra> tray even
<hughsie> one icon - max!
<ogra> yep
<hughsie> this is all theory atm
<hughsie> the menu code from Andrei is a bit rough atm, but its coming on.
<Mithrandir> elmo: .. without ccache, yes. :-)
<hughsie> ogra: not too much information?
<elmo> hum, I wonder what's wrong with hutte
<azeem> the name
<ogra> hughsie, no, why? as long as not everything is shown by default ... i'm fine with right clicking to see my UPS status
<hughsie> left clicking
<hughsie> right click brings up the usual menu
<ogra> ah, ok
<hughsie> plus i was thinking of using the new notification std for the notifications
<ogra> so you dont bind a default action to the left click but a menu, thats nice...
<hughsie> rather than using modal dialogues
<ogra> yep... the tooltip sutt you mean ? 
<ogra> stuff
<ogra> hrm
<hughsie> yup
<hughsie> hrm?
<ogra> yes... typos :)
<LeaChim> what does this error message mean? - Value too large for defined data type - i'm trying to copy a 50M file
<hughsie> ogra: okay, lets do some hacking :-)
<LeaChim> surely ubuntu linux can handle 50 meg files
<hughsie> ogra: I'm away for a few days. Phone is cut off today (for moving house)
<ogra> hughsie, yay... i'll be fully available on monday again....
<ogra> so how long do you think you'll be offline
<hughsie> ogra: Monday I would think, unless I can get some some cafe somewhere or an unsecured access point!
<hughsie> ogra: and then dial up for a couple of weeks
<hughsie> NOT COOL
<ogra> where do you move to ?
<hughsie> ogra: not far, back to Guildford
<ogra> (i heard BT takes its time...)
<hughsie> ogra: triffic.
<LeaChim> so, does anyone have any idea why ubuntu is having problems reading a mere 50 meg file?
<ogra> hughsie, hey, you have a nice country, ijust arrived in london, the first time i'm in uk
<hughsie> ogra: where in London? difffernt parts are better than others
<hughsie> I'm in Rochester at the moment working for a cool company
<ogra> south kensington 
<hughsie> ogra: that is cool.
<hughsie> ogra: my g/f lives in Richmond, so I know south ken quite well
<ogra> yep, it appeard quite nice... i walked from the hotel to the office, to see a bit 
<hughsie> ogra: just watch for pick-pockets
<ogra> i'll do :)
<hughsie> ogra: anytime you're in Surrey or Kent, give me a call.
<ogra> i'll do :)
<hughsie> ogra: my last day at work tmw.
<hughsie> loving the thought
<ogra> but this weekend i'm boung  tothe hotel here
<ogra> bound even
<hughsie> n/p, this weekend I'm moving!
<ogra> :)
<Kamion> jbailey: I *think* that hang is down to abysmal signal handler hygiene in cdebconf.
<mdz> Kamion: like that awful gzip bug
<Kamion> oh, yes, I vaguely remember that
<Kamion> I've stuck a band-aid over just cdebconf's SIGCHLD handler, which at least cleans up the immediate problem as far as I can see
<Kamion> but it'll need a total rework later
<mdz> mako: what is the name of that firefox extension which lets you edit textareas using emacs?
<pitti> ... and is there a counterpart for vim? :-)
<tseng> pitti++
<pitti> so far I do that with copy+paste, but that's error prone
<wasabi_> Hmm. postinst questions. Package needs to create a directory in /usr/local on install. How should I do that in postinst?
<wasabi_> should I test for $1 = configure or what?
<wasabi_> And should that dir be removed on purge?
<pitti> wasabi_: yes, and yes (with rmdir --no-fail-if-nonempty)
<pitti> wasabi_: erm, --ignore-fail-on-non-empty
<pitti> wasabi_: however, why not ship it in the package itself?
<pitti> wasabi_: that seems much easier
<wasabi_> Lintain says no
<wasabi_> Should put it in a script.
<pitti> wasabi_: hm, right
<pitti> wasabi_: /usr/local might be mounted ro
<pitti> wasabi_: yes, then the postinst/postrm makes sense, and postinst should ignore failures on the dir creation
<mdz> pitti: it can work with any editor, I'm sure
<wasabi_> Hmm. What if failure of the dir being created results in an unusable package?
<pitti> wasabi_: it mustn't
<wasabi_> Pssh.
<pitti> wasabi_: you *must not* depend on anything in /usr/locale
<pitti> erm, s/e$//
<wasabi_> Would it be possible to fail postinst and put the package into a non-configured state?
<pitti> wasabi_: no
<pitti> wasabi_: /usr/local is taboo for packages
<wasabi_> Oh heck.
<wasabi_> I'll give you some context if it might hange things.
<wasabi_> Eclipse.
<pitti> wasabi_: it is fine to create a directory to indicate where the user can plugins to, etc.
<pitti> wasabi_: everything you ship and depend on must be in /usr
<wasabi_> /usr/share/eclipse/plugins is where the packaged Eclipse plugins are kept.
<wasabi_> But Eclipse contains an auto install feature which allows you to browse for an install plugins at runtime.
<wasabi_> It's very useful, most third party plugins are published that way.
<wasabi_> So, I have added /usr/local/lib/eclipse/plugins as an alternative source. Eclipse however fails to start when the dir doesn't exist.
<pitti> wasabi_: no chance to install them in your ~ alternatively, btw?
<wasabi_> Yes, that *also*.
<wasabi_> I wanted to make it easy for users to install system-wide plugins
<wasabi_> From remote sources.
<pitti> wasabi_: then you need to patch eclipse to not fail
<pitti> wasabi_: well, or at least fail gracefully with explaining that the dir is missing
<wasabi_> Hmm. I could do that in the startup wrapper.
<pitti> wasabi_: the common case is that postinst will be able to install it
<shaya> join #debian-devel
<torkel> wasabi_: in the startup wrapper, why not create a link from /u/l/l/e/p/* to ~/.eclipse/plugins/ ? or is that too evil?
<wasabi_> what?
<wasabi_> That's not even reasonably acceptable.
<torkel> k
<wasabi_> Wait did I misunderstand?
<torkel> wasabi_: it was probably me missunderstanding what you meant
<Kamion> infinity: any chance you could kick off a d-i build once cdebconf 0.81ubuntu1 binaries reach the archive?
<Kamion> infinity: if you don't know how to drive that yet, no worries, I'll do it when I get back - but I'm going out for the evening and it would be nice for the wheels to continue to turn :-)
* Kamion goes
<shaya> anyone know if there's a restricted modules floating around somewhere for 2.6.12?
<pitti> not yet
<mako> mdz: mosez
<mako> pitti: it works with vim
<mako> mdz: mozex
<mako> pitti: mozex lets you edit any text editor with an editor of your choicce
<mako> pitti: sorry, any text AREA
<mako> wikis are *so* painful without it
<pitti> how is it called like?
<ogra> http://mozex.mozdev.org/
<pitti> danke
<tseng> ive never managed to install that
<tseng> i have the context menu, but i cant find the prefs panel
<tseng> mako: can you get to the prefs in firefox?
<Treenaks> tseng: in the extensions screen, there should be a button for that
<tseng> Treenaks: you would think so
<hunger> shaya: fabbione said he is waiting for a finalish linux kernel before the restricted modules are tackled.
<ogra> its 2 years old and didnt get updated for quite some time
<Treenaks> ogra: ah ,that would explain why it doesn't work anymore.. bitrot
<ogra> install mozilla :P
<Treenaks> ogra: make me :)
<ogra> heh
<tseng> so is there a file i can edit?
<tseng> if you cant change the apps this thing is basically useless it seems
<mdz> mako: doesn't work ("no 'textarea' command is set")
<mdz> mako: do you not use firefox?
<jp> epiphany rocks :)
<mako> mdz: i do.. i think it's slightly broken in firefox
<mako> mdz: i had to do about:config
<mako> mdz: and then set the command that way
<mako> mdz: PITA, but not as bad as textareas
<mako> i found some documentation on how to do it
<mdz> mako: I couldn't even find it in about:config
<mdz> mako: no matches for mozex or textarea
<mako> mdz: ergh.. i gotta run.. i'll find it tomorrow
<mako> or later tonight i find net
<pitti> mdz: I'm just doing a hoary->breezy dist-upgrade and collect some bugs. Shall I make them a dependency of a meta-bug again which is assigned to you? 
<mdz> pitti: to me?? ;-)
<mdz> a meta-bug sounds reasonable
<pitti> mdz: yes, so that you see which bugs are still outstanding
<pitti> mdz: I don't want to assign the actual bugs to you :-)
<pitti> mdz: just like I did for warty->hoary
<mdz> doesn't matter to me where the meta-bug is assigned, but sure
<pitti> ok
<ogra> tseng, point your browser to chrome://mozex/content/mozexPrefDialog.xul
* Mithrandir uploads a new xorg.
<ogra> Mithrandir, so you got infected too ?
<HiddenWolf> Mithrandir, is that the third revision today? :P
<Mithrandir> nah, just a fix for some pkg-config bug
<Mithrandir> bah, has there been xorg uploads today already?  I probably need to rebuild then
<seb128> elmo: libgt2-perl (experimental) and verbiste syncs please
<seb128> elmo: libgtk2-perl
<elmo> [Updating]  libgtk2-perl (1:1.090-1 [Ubuntu]  < 1:1.091-1 [Debian] )
<elmo> ... ?
<elmo> [ignoring the off-by-one error in my code] 
<wasabi_> Anybody want to move some packages from multiverse to universe? :)
<elmo> seb128: verbiste done anyway
<seb128> elmo: thanks. What is the message about libgtk2-perl?
<wasabi_> shell script's confuse me.
<tseng> ogra: thanks
<wasabi_> Okay so. A shell script. It does 4 things. One of those 4 things can fail. How does that command effect the exit code of the script itself?
<danielki> the exit code of the script is the exit code of the last command executed
<danielki> unless you explicitely write 'exit 0'
<wasabi_> What about set -e?
<tseng> oh man this is cool
<danielki> ah you want it to abort
<wasabi_> No. What I want to do is ignore errors for just 2 of the commands.
<wasabi_> But abort on all the others. ;)
<danielki> use command || exit 1
<wasabi_> Hmm. I should be able to make these two commands || true maybe
<danielki> the ones you want to ignore, yes
<danielki> that should even work with set -e
<elmo> seb128: version in ubuntu == version in debian experimental
<seb128> elmo: 1.090 and 1.091 ?
<seb128> oh, k
<seb128> hum
<seb128> elmo: http://archive.ubuntu.com/ubuntu/pool/main/libg/libgtk2-perl/ and http://ftp.debian.org/debian/pool/main/libg/libgtk2-perl/ have different versions
<elmo> libgtk2-perl |  1:1.090-1 |        breezy | source
<elmo> it just hasn't built ....
<fabbione> elmo: yes it's FTBFS on a test case
<fabbione> but seb128 sync request is right
<elmo> oh, 1.091.  well it hadn't reached ftp.d.o at the time seb asked for it
<elmo> I'll try again late
<seb128> thanks
<seb128> (http://ftp.debian.org/debian/pool/main/libg/libgtk2-perl/ has it)
<elmo> oh, I know why
<elmo> project is after debian
<elmo> hum, maybe.  anyway.
<wasabi_> Oh hey I could get added to planet.ubuntu.com couldn't i.
* mae builds anjuta2
<mae> shall i make a deb?
<ogra> mae, yes, do it together with MOTU (see #ubuntu-motu) to get it properly reviewed
<ogra> night all
<mae> is GObject meant to deprecate gtkmm?
<danielki> huh
<danielki> no
<sivang> mae: ?
<danielki> mae: GTK+ has always been based on an OO design
<sivang> mae: GObject is GLib's object's abstraction to allow to use objects in GNOME without actually needing an OO languiage
<danielki> mae: gtkmm is about the language
<sivang> mae, danielki : it's gtk bindings for C++ no ?
<danielki> yes
<danielki> erm
<danielki> the other way around
<danielki> C++ bindings for GTK+ :)
<wasabi_> sivang is right
<wasabi_> actually they both make sense
<wasabi_> =
<sivang> wasabi_: right :-)
<sivang> wasabi_: how are you doing buddy by the way?
<wasabi_> I am decent.
<sivang> wasabi_: heheh , how's java stuff going?
<wasabi_> apt-get install eclipse-sdk
<sivang> wasabi_: err, I can't, have you gotten into this:
<sivang> dpkg: error processing /var/cache/apt/archives/xlibs-data_6.8.2-32_all.deb (--unpack):
<sivang>  trying to overwrite `/usr/X11R6/lib/X11/xkb', which is also in package libx11-6
<Zomb> Ubuntu has 3.0? 3.1?
<wasabi_> I just replaced it.
<wasabi_> overwrite.
<wasabi_> Then upgraded everything.
<sivang> wasabi_: I give it apt-get -f , but it won't work
<wasabi_> install the xlibs-data deb with --force-overwrite
<wasabi_> then just upgrade libx11-6
<sivang> wasabi_: k, thanks a lot
<sivang> wasabi_: yay, easy as pie. 
<mae> danielki, what I mean is, gtkmm is a wrapper over the c functions also using libsigc.. is GObject is meant to replace gtkmm, right? .. I know that gtk uses and object oriented design
<mae> er gtkmm is a wrapper for the C functions providing C++ bindings, rather :)
<danielki> mae: GObject is written in C
<danielki> glibmm wraps it too
<mae> ermm but i think GObject was new.. is it not replacing something else?:
<danielki> it replaced GtkObject as a base class for everything
<danielki> without being GUI related
<danielki> i.e. it's kind of a design cleanup
<danielki> (GtkObject still exists though, and derives from GObject)
<danielki> mae: the main purpose of GtkObject nowadays is to implement container ownership
<mae> i see :)
<lamont> elmo about?
<wasabi_> GObject is not new. And I don't know what you mean about "main purpose"
<wasabi_> All of Gtk is built with GObject.
<sivang> wasabi_ is right, AFAIK
<wasabi_> gtkmm is just a wrapper around Gtk's GObjects (and probably extending into Gnome stuff too) in C++, so you can use real C++ classes
<sivang> IMHO, right again
<wasabi_> GObject itself is just really a small framework and some standards for writing structs so you can prentend to use objects in C.
<sivang> (at least that's what I Know that gtkmm is)
<wasabi_> s/small/big/
<wasabi_> Heh. Eclipse ssureees has been building a long time.
<danielki> wasabi: I was talking about the main purpose of GtkObject, to explain why it's actually there at all
<danielki> instead of just deriving from GObject directly
<wasabi_> depends what you were tlaking about
<wasabi_> GObject the project or GObject the class.
<danielki> the class
<wasabi_> k.
<wasabi_> didn't sound like that at first.
<lamont> elmo: is glibc/hppa NEW or somethign?
<sivang> has anyone seen jinty lately?
<danielki> wasabi_: I sometimes forget that it's a separate project from glib :)
<danielki> it's like gdk-pixbuf vs gdk
<i_m_meen> hello
<i_m_meen> just one question: apt-build is a dead project?
<sivang> wasabi_: hmmm:
<sivang> Setting up eclipse-platform (3.1-0ubuntu2) ...
<sivang> touch: cannot touch `/usr/local/share/eclipse/.eclipseextension': No such file or directory
<sivang> dpkg: error processing eclipse-platform (--configure):
<sivang> wasabi_: and there are lots o' lots of errors..:-(
<i_m_meen> WARNING: The following packages cannot be authenticated!
<i_m_meen>   xfe
<i_m_meen> E: There are problems and -y was used without --force-yes
<i_m_meen> output from apt-build...
<i_m_meen> but apt-build doesn't have a force yes option
<i_m_meen> so what should i make of it?
<i_m_meen> google doesn't help..
<i_m_meen> the manual doesn't help...
<wasabi_> that /usr/local problem is fixed in the next version! =)
<wasabi_> What other errors?
<sivang> wasabi_: ok, when are you uploading?
<wasabi_> An hour ago. It's waiting to be built.
<sivang> wasabi_: http://paste.uni.cc/7434
<wasabi_> You could build it if you were feeling bored. heh.
<wasabi_> Oh just that one problem.
<sivang> wasabi_: everything else is caused by it?
<wasabi_> rm /var/lib/dpkg/info/eclipse-platform.postinst; apt-get -f install
<wasabi_> Yeah
<mxpxpod> does anyone here use beagle on breezy on powerpc?
<wasabi_> sivang, new version built.
<sivang> wasabi_: cool, but will test it tommorow :-) it's bed time now
#ubuntu-devel 2005-07-06
<Kamion>   mcmurdo.buildd: forward host lookup failed: Unknown host
<lamont> Kamion: sounds about right
<Kamion> is that not a machine that does d-i builds any more?
<lamont> d-i is vernadsky.buildd
<Kamion> what's the current set?
<Kamion> oh
<Kamion> I have mcmurdo hooker ross yellow
<lamont> vernadsky, ross, yellow, hooker
<lamont> mcmurdo was a .5TB box, which them launchpad? folks stole from us
<lamont> dude.  we got a dell.
* Kamion opens another screen window and hits vernadsky from that
<lamont> where is pitti so I can hit him???? huh???
<wasabi_> I need some packages moved to universe. ;)
<mae> um, memory management is done by parents with gtk right?
<mae> for widgets?
<lamont> libgnomecanvas2-dev_2.11.1-0buntu1_i386.deb
<lamont> what's the 'buntu' suffix, I wonder?
<wasabi> 0buntu
<tseng> infinity: did you get my mail?
<wasabi> post update interaction!!!
<lamont> Kamion: you around?
<lamont> hrm.. .actually, it's not too hard to check that myself..
<lamont> hrm.. actually... anyone with a jackass login around?
<lamont> GAH
<tseng> nice vlc is horribly uninstallable
* lamont figures out the error of his ways..
<waterseven> Hi there... is anyone here that does translations? need some help finding a template.
<infinity> tseng : The mail about whacky mono segfaults?
<infinity> tseng : I looked at it briefly a few days ago, then got swamped.
<alvaro> hi
<alvaro> somebody know the reason why can't use directy the nvidia drivers from the nvidia page?
<whiprush> nvidia drivers are included in ubuntu. (this question is best for #ubuntu instead of here)
<alvaro> but if I compile the kernel... how install this modules?
<alvaro> I install the nvidia drivers from the www.nvidia.com and now can't go back to my old configuration
<jdub> alvaro: why did you need to recompile your kernel?
<jdub> you can probably try to build linux-restricted-modules against your kernel
<alvaro> because I can't active the dma in my dvd
<whiprush> if you did rebuild your kernel make sure /usr/src/linux points to the right source, the nvidia drivers should just find it.
<jdub> alvaro: you can do that without rebuilding your kernel, just use hdparm
<alvaro> when I use hdparm say: invalid instruction
<whiprush> Mr. Dub: I hear toronto is a possible location for the next conference?
<jdub> whiprush: hrm, not hugely likely; south america more so
<whiprush> k
<whiprush> still cheaper than europe for me
* whiprush crosses fingers
<jdub> yeah :)
<whiprush> alvaro: I usually enable dma on a drive in /etc/hdparm.conf (iirc)
<whiprush> lemme bust out my laptop and check.
<alvaro> I tried but not work
<whiprush> and you're sure the drive supports dma? (I assume so since it's a dvd drive)
<whiprush> jdub: dude, networkmagic on a laptop is a wonderful thing, I've been suspending and having it Just Work all day long.
<whiprush> different aps and locations too.
<whiprush> I'm going to buy thom a big batch of $LOCAL_BEER at the next conference.
<alvaro> this my problem when y try to activate: HDIO_GETGEO failed: Invalid argument
<alvaro> its a dvd drive, y sure because the driver work with dma in other pc
<whiprush> you sure the syntax is right?
<alvaro> yes
<alvaro> , /dev/hda because I have a sata hd
<whiprush> ok, I'd do two things, a) submit your hardware config via hwdb-client, and then file a bug in bugzilla.ubuntu.com on it.
<whiprush> make sure you put as much detail in the comments in hwdb-client, when it submits it'll get looked at eventually.
<alvaro> I think that the chipset is the reason
<ajmitch> jdub: when is it likely to be?
<alvaro> I try to install the ndorce chipset module...
<whiprush> well, when you submit it'll send along the hardware config, the important thing is that you submit it so a developer can get to it.
<alvaro> ok, I do it
<alvaro> but now I can't run X... how can I reconfigure to my old configuration?
<jdub> ajmitch: october, november
<ajmitch> jdub: great, I'll start saving then :)
<alvaro> I try to reinstall the nvidia dirvers how in unoficial guide, but I can't run X
<whiprush> alvaro: most of the people in here are busy fixing up the next release, it's best if you ask in #ubuntu.
<alvaro> thanks whiprush
<whiprush> no problem, good luck!
<fabbione> morning
<fabbione> Mithrandir: xcursor is still FTBFS
<fabbione> even with xorg -33
<Lathiat> uh all X upgrade
<lamont> fabbione: xcursor is missing a build-dep in ubuntu1 - did a new upload happen there yet?
<fabbione> nope
* icaro goood morning at all
<Mithrandir> lamont: no, I haven't uploaded the new version
<Burgundavia> just saw what google is funding
<Burgundavia> very nice stuff
<whiprush> jdub: hey planet.u.c doesn't highlight links at all
<whiprush> like, I had to hover my mouse over you thurott entry to find the link
<jdub> only on some links, too
<whiprush> yeah, odd
<jdub> i hate wrangling with the plone css
<jdub> i'm probably going to rip it out
<whiprush> that whole "bottom row of an entry being clickable" is kind of suck for both planets
<robitaille> whiprush:  in blogger, I have to make sure all my blog text entries are delimited by <p> </p> so that the links work on planet
<whiprush> robitaille: mine are like that in typepad also
<jdub> whiprush: that's being fixed (same with the top)
<whiprush> woo
<whiprush> yeah, on a pad on a laptop, planet's been sucking lately.
<whiprush> with that bug 
<highvoltage> Burgundavia: what is google funding?
<Burgundavia> highvoltage, google summer of code
<pitti> Morning
<whiprush> heya pitti
<whiprush> heya to you too sabdfl. :p
<fabbione> hey pitti
<fabbione> morning sabdfl 
<Simira> morning all
<whiprush> hey fabbio.
<fabbione> hi whiprush 
<sabdfl> well howdy guys
<whiprush> man, I almost forgot to say, our loco is over 20 now.
<sabdfl> edu-buntu summit in london today!
<sabdfl> whiprush: stormin!
<sabdfl> did you guys read the LinuxTag summary from JoshKress? awesome
<whiprush> sabdfl: we're determined to make detroit a destination on the world tour.
<whiprush> yeah, read it a few hours ago, wish it had some pics though.
<Burgundavia> whiprush, you have more in detroit than I do in my entire loco
<fabbione> sabdfl: some good news from ports.u.c.. sparc buildd's are idling for the first time in a year or so :-) we might get out this time :)
<sabdfl> fabbione: how the installer look?
<whiprush> Burgundavia: don't be discouraged, half our people are just "students interested in linux". Getting them there is easy, getting them to stay and help out is ... as you can imagine, difficult.
<fabbione> sabdfl: i need to work on it.. the hoary one was ok.. in breezy is FTBFS atm...
<fabbione> sabdfl: but we will get it there ;)
<Burgundavia> whiprush, we were too busy gutting ourselves over who to have a contact person
<sabdfl> fabbione: anybody out there helping you?
<Burgundavia> whiprush, and it wasn't robitaille or myself (the only 2 canadian members)
<Amaranth> where is the list of things google is funding?
<fabbione> sabdfl: we had quite of a problem with kernel due to an arbitrary change in glibc elf header... 
<Burgundavia> Amaranth, BreezyBounties on the udu wiki
<fabbione> sabdfl: yes... a bunch of people fixing stuff around
<whiprush> Burgundavia: scott balenaves from ltsp is an ubuntu guy, make him #3. 
<fabbione> sabdfl: or extremely cooperative...
* Amaranth can't remember where the udu wiki is
<Burgundavia> whiprush, he is a canuck? bradb is also one
<Burgundavia> http://udu.wiki.ubuntu.com/BreezyBounties
<whiprush> Burgundavia: so you have 4, see, you've already doubled your numbers!
<Burgundavia> whiprush, bradb works for canonical, so he doesn't count
<whiprush> heh
<Amaranth> what's with the overuse of the udu wiki?
<Amaranth> someone got the FindingPackages bounty? :/
<Amaranth> oh well, i wasn't going to have time to work on it anyway
<robitaille> Burgundavia: don't worry, one day the Canadian LoCo will been flying high.  It will just a bit more effort...and time
<Burgundavia> when everybody buys my Inuktitut idea
<robitaille> Burgundavia:  it is a good idea...just a bit different, and tough to do without local people helping us in the north
<Burgundavia> that is what government funding is for
<Burgundavia> ahh, tabs turning blue everywhere!
<whiprush> scott works for the local government in winnipeg and admins quite a number of thin clients running linux and OOo, get him on board!
<Burgundavia> whiprush, got an email?
<whiprush> sure.
* robitaille also works for the government...but doesn't seem to help bringing Ubuntu at his work...
* Burgundavia used to be a contracter to the gov, and used windows
<whiprush> sbalneav@ltsp.org
<HrdwrBoB> I work for the government and we use ubuntu because I Say
<robitaille> Burgundavia:  we're mostly a Mandrake shop for the desktop, but with some Windows machines; the local system admin doesn't want to touch sometjing he isn't familiar with
<Burgundavia> prov gov is all XP
<Burgundavia> sad
<sabdfl> Burgundavia: it will change
<Burgundavia> not within 10 years, unless the gov does
* Burgundavia is glad not to work with windows anymore, as his stress level is considerably lower
* ivoks works for uni, over 60 linux boxes here...
* whiprush is in the same boat as ivoks 
<ivoks> all my servers are ubuntu :)
<ivoks> except one
<robitaille> sabdfl:  not clear it will change that easily; we are mostly Linux locally , but higher up they are all Windows; obtained with department-wide contracts that pay Microsoft money per number of employees, no matter if they use Windows/Office or not; so at one point a department has to ask the question:  why some of us don't use the Microsoft products that have already been paid for.
<Mithrandir> fabbione: new xcursor uploading now.
<whiprush> ivoks: I had to choose a distro before hoary was ready, so I'm with sarge for all our stuff.
<ivoks> whiprush: i had sarge too on my servers
<ivoks> whiprush: i upgraded/downgraded them to hoary
<ivoks> on-line, without reboot :)
<whiprush> heh
<fabbione> Mithrandir: ok thanks
<Burgundavia> and the entire prov gov is one big contract with two local companies and IBM supplying hardware
<whiprush> Burgundavia: I used to work for a US government contractor, I can so feel your pain on this.
<sabdfl> robitaille: interesting, the "pay irrespective" idea
<sabdfl> robitaille: i think those contracts were popular when people figured there was no alternative
<Burgundavia> they are still popular
<sabdfl> as soon as they think there IS an alternative, those contracts come up for review
<Burgundavia> here in Canada and the US at least
<Burgundavia> where we are wealthy enough to pay the MS tax
<sabdfl> yes, that's part of it
<sabdfl> in developing countries, afaics they are all looking to migrate big chunks
<Burgundavia> or they use pirated windows
<whiprush> depends on the contract. Here in the US there are provisions for every federal contract for small and minority-owned busineses. 
<Burgundavia> the "buy canadian" thing is also starting to penetrate the minds of canadian politicians
<Burgundavia> most especially after the patriot act thing
<ivoks> our goverment has a contract with MS
<whiprush> they won't big contracts but in many defense contracts the big companies will subcontract to smaller companies to win the contract.
<whiprush> for example, if you're a native indian alaskan and own a logistics company, there is plenty of money to be made.
* whiprush has learned far more about the US military-industrial complex than he cares to.
<whiprush> but on the upside, a good percentage of the us govt is still using novell, so there's some kind of hope for linux in there somewhere.
<robitaille> Burgundavia:  the "buy canadian" hasn't  work before; Corel at one point sued and won against the Canadian Government since bidding process was unfairly biased against them toward Microsoft (http://www.washingtontechnology.com/news/14_21/federal/1046-1.html).  Now we have very lengthy bidding process for Office suites, but Microsoft still wins every single time
<Amaranth> mp1: On GnomePanelEnhancements, you can use <Layout> tags in the menu files to order things and make sure they stay order that way (instead of being alphabetized)
<whiprush> fabbione: question: I happen to have a madwifi card, while debugging networkmanager, is the driver in l-r-m as important as the wireless-tools? I don't want submit bugs to network-manager if it's a madwifi issue. 
<whiprush> so am I better off submitting bugs to network-manager now, or wait for the madwifi update in l-r-m?
<ajmitch> evening
<pitti> Hey ajmitch 
<Amaranth> hmm, it seems lots of hoary users are finding out that i broke gnome-app-install :)
* Lathiat smirks
<Amaranth> well, pyxdg broke it, but smeg needs the latest pyxdg so...
<hunger> Is there a reason for using pngs as backgrounds for gnome? Saving the image as jpg would shrink it by more than a factor of 20.
<Burgundavia> is hdd space still a factor anywhere?
<Amaranth> png is free
<hunger> Burgundavia: I find it annoying to waste space.
<highvoltage> hunger: what's more annoying? a few kb less space, or ugly, distorted images in your working environment?
<hunger> Burgundavia: And It is a difference whether I have to download 30k or 900k on upload (minus compression from deb).
<hunger> highvoltage: ? Do you really see a difference between jpg and png?
<highvoltage> hunger: yes
<Amaranth> yes, compressing a png into a jpg will make a smaller image
<Burgundavia> but I don't see the win
<Amaranth> but it will make an image that looks worse, you're transcoding
<Burgundavia> if you have a slow connection, download elsewhere
<Burgundavia> or usethe default
<hunger> Amaranth: The default background does not have that many details that can get lost;-)
<hunger> Burgundavia: I am talking about the two default images.
<Burgundavia> the space saving on the disk is not worth the lost clarity
<hunger> Burgundavia: The non-ws one is ~870k as png and ~38 as jpg.
* hunger shrugs.
<hunger> Burgundavia: What do you mean by clarity?
<highvoltage> hunger: jpeg distorts images. if you see it often in highly compressed images, you get sensitive toward it.
<highvoltage> which is why many of us stick to .png (after we've tried to over-optimise some web pages in the 90's)
<Amaranth> oh, the pngs are lossless?
<HrdwrBoB> highvoltage: you know, both png and jpeg have adjustable compression :)
<highvoltage> nope, but they look much better.
<HrdwrBoB> Amaranth: they can be lossy or lossless
<highvoltage> HrdwrBoB: I know, but jpeg is more lossy, afaik
<Amaranth> HrdwrBoB: I know. :) I was asking if the backgrounds were lossless.
<hunger> highvoltage: The factor 20 is with 90% quality setting for jpg. There is no visible difference.
<highvoltage> hunger: a png with the same compression will be smaller as a jpg with the same compression, and the quality will be better.
<highvoltage> (ime, anyway)
<Amaranth> hunger: You looked at them at 640x480 resolution, right?
<hunger> highvoltage: Even with a quality setting of 70% the image is basically identical to the png... jpg is ideal for the image that is used as the default background.
<hunger> Amaranth: I look at the image at 400%.
<highvoltage> hunger: fine, convert all your ubuntu images to jpeg's then :)
<hunger> highvoltage: Sorry, but that is crap... png and jpg use *WAY* different algorithms. You can not really compare the compression technics.
<HrdwrBoB> you can
<HrdwrBoB> they're both compression techniques for images to display pictures
<highvoltage> hunger: of course you can compare them, even though they encode images differently. anyway, this is a silly discussion. google png vs jpg instead, we're wasting irc space.
<hunger> highvoltage: I do know both compression technics.
* hunger shrugs and shuts up.
<pitti> hunger: in general, jpg is suitable for photo-like pictures, png for drawings (sharp edges)
<hunger> pitti: I know both jpg and png compression technics.
<hunger> pitti: The default ubuntu background is a perfect match for jpg compression, which is why I was suggesting to use that.
<Amaranth> does ubuntu use jpg for anything?
<pitti> hunger: right
<hunger> Amaranth: Most kde backgroungs.
<Amaranth> isn't there a patent on jpg that just hasn't been enforced? (like gif was)
<hunger> Amaranth: kubuntu comes with about 50 backgrounds and uses about 5 times the space of the 2 gnome ones.
<hunger> Amaranth: Not that I am aware of... but possible.
* Amaranth wonders when you would ever want 50 backgrounds
<hunger> Amaranth: In fact: So do I;-)
<Burgundavia> kde is all about more options
<Amaranth> ha, IBM says they've been able to build G5s for laptops this whole time
<hunger> Well, encode your pictures however you want... I do not have to care about the bandwith to update them whichever format you are going to use.
<Amaranth> i don't think they ever get updated
<Amaranth> what's the package name?
<hunger> Amaranth: Yes... considering that they are still called warty;-)
<Amaranth> gnome-backgrounds?
<hunger> Amaranth: ubuntu-artwork
<Amaranth> ubuntu-artwork?
<Amaranth> ah
<Amaranth> 3 different debs
<Amaranth> could just be 3 different versions of ubuntu
<pitti> stupid me -- /etc/init.d/gdm stop != /etc/init.d/gpm stop
<hunger> pitti: You are doing this too?
<pitti> hunger: I fixed a gpm bug in the init script, but mistyped...
<pitti> Hey trulux 
<trulux> hey pitti 
<shackan> hi pitti
<pitti> Hi shackan 
<shackan> I'm one of the lucky guys doing the SoC with you, remember ?
<Amaranth> which one are you? your whois doesn't have a name
<pitti> shackan: of course, I already missed you :-)
<shackan> sorry but I was without an internet connection until yesterday
<shackan> pitti, I have a question, is it ok if I put the code on berlios ?
<Kamion> morning
<pitti> Hey Kamion 
<pitti> shackan: I don't mind where the code is, as long as I can download it (what's berlios?)
<pitti> shackan: will you use a vcs? Maybe even arch? :-)
<shackan> http://developer.berlios.de/
<shackan> berlios relies on svn, but it seems they have cvs too
<shackan> btw, what is arch ? :)
<Amaranth> hook him up with bzr? :)
<pitti> shackan: sure, that looks fine; however, please use svn, cvs is soo evil
<pitti> Amaranth: good idea :-)
<Amaranth> arch is a distributed vcs
<pitti> shackan: GNU arch is another version control system; one particular implementation ("bazaar") is very popular among the Ubuntu developers 
* Amaranth doesn't know how to explain it
<pitti> shackan: it has a strong emphasis on branching 
<shackan> mmkay, sorry I didn't know that
<Amaranth> basically anyone can work on something with full vcs capabilities on their own branch then just point you to the branch when they're done
<pitti> well, svn is certainly fine for now
<pitti> shackan: see Amaranth, right; and then you can merge and cherrypick from each other
<shackan> nice :)
<Amaranth> bazaar-ng usable yet?
<Amaranth> err, that should have an is
<pitti> Amaranth: I use it for pmount now
<pitti> Amaranth: I emulate "push" with a wrapper that calls rsync 
<pitti> Amaranth: but pull, commit, diff, log, merge, etc. work fine
<Amaranth> what about pull?
<Amaranth> oh, pull is done?
<pitti> yes
<pitti> bzr is a breeze, it's so much easier to set up than bazaar-ng
<pitti> erm, bazaar
<pitti> it always takes me a while to get a newbie going with baz
<Amaranth> hrm, didn't debian have a newer version of bzr once?
<Amaranth> i mean, they had a version newer than ubuntu's version
<pitti> Amaranth: 0.0.5 is in breezy too, but it's ftbfs
<Amaranth> ah, that's what it was
<pitti> Amaranth: I nagged bob2___ a while ago, but he didn't fix it yet
<Amaranth> ok, bzr lovers, use debian! :D
<pitti> Amaranth: I use bzr bzr head :-)
<Amaranth> that's kinda funny
<pitti> Amaranth: I just downloaded bzr.dev and do a "bzr pull" from time to time. 0.0.5 doesn't have merge yet
<lifeless> pitti: lol
<pitti> lifeless: ?
<lifeless> "bzr is a breeze, it's so much easier to set up than bazaar-ng"
<pitti> lifeless: conceptually
<lifeless> oh its true
<lifeless> it was the bzr is easier than bzr thing I laughed at
<pitti> lifeless: personally I really love baz, but explaining all the id and archive setup always takes a while for newbies
<lifeless> sweet, thanks
<pitti> lifeless: <pitti> erm, bazaar :-)
<lifeless> 1.5 is bringing in much nicer inventory management
<lifeless> should make some performance difference too ;)
<pitti> lifeless: btw, thanks for fixing relative paths with undo/commit - that really sucked
<pitti> nice
<lifeless> pitti: cool
<lifeless> leonerd did the heavy lifting there, if you want to thank him ;)
<Amaranth> now we just need a bzr gnome-vfs backend that does branches on copy (from remote to local) and merges on copy (from local to remote?)
<pitti> Amaranth: a copy _is_ a branch in bzr (there's no explicit branch command AFAIK)
<Amaranth> well, i meant something like DnD from nautilus windows
<pitti> yes, I meant that branch is essentially already implemented :-)
<pitti> Amaranth: and since merge requires manual resolving, this probably won't happen with DnD
<pitti> Amaranth: but push would be nice
<Amaranth> DnD and open gedit with tabs of things that need to be merged
* Amaranth has never used bzr and doesn't know how this works
<Amaranth> does it crap in your files like cvs does?
* pitti still prefers a single "bzr push" shell command
<pitti> Amaranth: I didn't try conflicted merges
<pitti> Amaranth: my bigger projects with many branches (postgresql) use bazaar, I don't yet dare to use bzr
<lifeless> Amaranth: what do you mean by crap in your files ?
* pitti assumes the >>> ORIG <<< NEW thing like CVS does
<Amaranth> lifeless: Well, cvs dumps something like diff output in your files
<niran> i spent the last day or so wrapping my head around bazaar and playing with it
<niran> i am in love.
<mae> Is there a straightforward method of using eclipse/cdt to make GTK projects, i.e. on the linux platform, I would normally use "pkg-config" to configure all the libs and includes for gtk and/or glade.. how can i integrate such functionality into eclipse?
<lifeless> Amaranth: if you mean the <<<<<<<<<<<<<<<<<<< ... ======================== etc like pitti is indicating, yes - thats diff3 merge conflict output
<lifeless> niran: sweet
<Amaranth> lifeless: For once, that's a good thing. My idea could work. :)
<pitti> lifeless: I think the bazaar .orig and .rej approach is nicer
<pitti> lifeless: I would just like to get the .rej files in unidiff format
<Amaranth> when merging with conflicts, it could open gedit with a tab for each conflicting file
<pitti> but AFAIK patch doesn't support that
<fabbione> Kamion morning 
<lifeless> pitti: yah. the problem there is repeated merges - bazaar does diff3 conflict foo too if you use merge.
<fabbione> Kamion: if you want to send me your try i can do easily a test build....
<Amaranth> save them and the conflict is resolved
<fabbione> Kamion: i have 2 buildd's idling ;)
<lifeless> pitti: hopefully we'll get some interesting results out of bzr and be able to improve this
<Kamion> fabbione: edit build/config/sparc/sparc64/netboot-2.6.cfg, replace the KERNELNAME value with just 'vmlinuz'
* fabbione will try
<Kamion> I much prefer CVS/svn's approach to conflicts, FWIW
<Kamion> although as pitti says unidiff .rej files would help
<pitti> Kamion: I'd like to have that in patch in general
<pitti> patch --unidiff-rej
<Amaranth> Kamion: I like the diff output, I don't like the extra files you have to remove before it considers the conflict resolved
<pitti> applying non-unidiff rejected patches is a PITA
<Kamion> the CVS/svn approach means that one does not have to either (a) use specialised tools like emacs' 3diff mode or (b) copy chunks of stuff from one file to another in order to resolve the conflict
<pitti> hm, right
<Kamion> it's just "edit single file"
<Kamion> Amaranth: yeah, 'baz resolved' should remove those for you
<lifeless> pitti: is there such an option ?
<pitti> lifeless: no, but there should be :-/
<pitti> lifeless: it's badly missing
<lifeless> Kamion: nice idea, care to file a bug ?
<Kamion> lifeless: sure, doing now
<lifeless> Amaranth: baz doesn't require the files to be removed, unless one deliberately configures a tree to be like that. it used to require it by default .
<Kamion> lifeless: it's already filed, https://launchpad.ubuntu.com/malone/bugs/360
<lifeless> Kamion: heh, ok
<Amaranth> Kamion: baz resolved is too much work
<lifeless> Amaranth: baz resolved --all
<Amaranth> Kamion: whether i've cleaned up the file to remove the diff stuff or not, next time i commit it consider it resolved
<Amaranth> that's how i think it should be, anyway
<lifeless> Amaranth: I take it you've never put yourself in merge hell by committing the <<<<====>>>> lines?
<Amaranth> nope
<Amaranth> but you shouldn't blame the user for the failings of the computer
<Amaranth> s/blame/torture/
<pitti> it's not the computer that failed...
<Amaranth> then i didn't understand what 'merge hell' was
<pitti> lifeless: indeed, maybe resolved should be dropped and instead bzr should refuse to commit a file if it contains such markers
<pitti> (and bazaar, too) :-)
<lifeless> pitti: well, resolved was added by user request.
<pitti> hm, ok
<lifeless> some things will annoy some users but please others
<pitti> lifeless: well, it's necessary with external rej files, but also with inline markers?
<lifeless> I'm sure that I'd get bug reports if we had a heuristic on files - what if you *do* want ====== lines in your file
<Amaranth> pitti: Actually, I like your idea plus a 'resolved' command for forcing things through.
<lifeless> pitti: huh? external rej files don't affect commit or not-commit. resolved is 100% UI assistance.
<Amaranth> and _no_ extra files
<Amaranth> lifeless: When would you have a bunch of <s, =s, and >s in the same file?
<Amaranth> lifeless: other than when you've got a conflict
<lifeless> well in my specific case, when I'm testing conflict output ;)
<lifeless> but the point is that its a heuristic - its hoping that noone else does that
<Amaranth> you could use the file's modified time to figure out if the user edited the file after it conflicted
<lifeless> vcs tools should not impose limits on what you can store in them
<pitti> well, right, that was the advantage of external .rej files
<fabbione> Kamion: meh.... E: Couldn't find package cdrom-core-modules-2.4.27-2-sparc32-di
<fabbione> we are still trying to build 2.4 :P
<fabbione> and sparc32 ;)
<Kamion> huh
<Kamion> don't see where - please mail me the new build log?
<fabbione> it's in the miniiso..
<fabbione> sure.. in a minute.. i wasn't saving the log
<fabbione> Kamion: the first fix seems to work :)
<fabbione> (mail on the way)
<Kamion> fabbione: oh, ok, try putting 'MEDIUM_SUPPORTED = 2.6' at the top of build/config/sparc/cdrom.cfg please
<fabbione> Kamion: building
<fabbione> hmm p-a-l is going to be a very interesting challenge :/
<fabbione> Kamion: the next error is interesting.. it's trying to use cramfs...
* fabbione digs
<Kamion> INITRD_FS = cramfs
<Kamion> hmm
<Kamion> isn't that correct?
<fabbione> build/config/sparc/cdrom/2.6.cfg:INITRD_FS = cramfs
<Kamion> bit silly to have it just for cdrom though maybe
<fabbione> it wasn't cramfs before..
<fabbione> well i don't mind.. we need to add the build-dep
<Kamion> ok, just zap that line, upstream's building for ext2
<fabbione> cramfsprogs [powerpc ia64 mips sparc]  <-
<fabbione> ok
<fabbione> zapped
* fabbione goes hunting some food
<mvo> hmmm ... food 
<\sh> would be nice
* mvo goes to get some food too
<tseng> infinity: yep. thanks
<uniq> can kubuntu-5.04-dvd-powerpc.iso be downloaded somewhere.. so i can setup a seeder for bittorrent? downloading from torrent stops at ~70% for everyone.
<Kamion> torrent.ubuntu.com may not be working properly
<Kamion> elmo: ?
<elmo> meh, stupid tracker died
<elmo> restarted
<uniq> thanks :)
<niran> mvo, searching works now in gnome-app-install, and it is glorious.
<niran> now i can sleep in peace.
<mvo> niran: it's 5 in the morning for you, right :) ?
<niran> mvo, yes. yes it is.
<mvo> niran: I'll check the archive now then, please don't forget baz archive-mirror :)
<niran> mvo, i did
<niran> if anyone else wants to play with it, knock yourself out: http://niran.org/arch/niran@niran.org--soc/gnome-app-install--niran--0/
<fabbione> Kamion: d-i builded.. checking the contents :)
<Kamion> fabbione: I tweaked my working tree slightly to do KERNELNAME = $(KERNELNAME_2.6) instead of = vmlinuz, but that should be safe
<fabbione> Kamion: i can rebuild to test.. no problem at all
<Kamion> I wouldn't bother, I'm just mentioning it for completeness
<fabbione> Kamion: for once that i can claim spare CPU's cycles.. let me enjoy my little moment of glory :P
<Kamion> heh
<fabbione> Kamion: hmm not.. that won't work
<Kamion> ?
<fabbione> nevermind.. wrong file :)
<fabbione> Kamion: d-i looks good :)
<Kamion> excellent, I'll upload once I've figured out what's going on with cdebconf
<fabbione> sure
<fabbione> i did a binNMU in the meanwhile...
<Kamion> (in order that I can use the upload to suck in a new cdebconf)
<fabbione> so i can test it if i get to have spare time from my wife ;)
<Kamion> it's a hard life
<fabbione> Kamion: sure.. i have no rush really.. sparc is looking much better now that we have 2 buildd's
<fabbione> Kamion: you will soon join the team
<lifeless> is mdz on leave ?
<fabbione> Kamion: next time you will tell me: "eh yeah i understand"
<fabbione> lifeless: uk eduubuntu
<lifeless> ah, k
<Kamion> fabbione: hah
<Kamion> fabbione: (but yeah)
<fabbione> Kamion: do we have a primitive in d-i to understand if a certain recipe will create /boot (or any other partition) ?
<fabbione> the problem is that some recipes create /boot, other don't
<fabbione> i need to filter it so that if it has /boot, i will use the recipe info to create /boot outside LVM and filter it later for creating LVM partitions
<fabbione> if it doesn't i need to create it from scratch
<Kamion> fabbione: don't think so, talk to Anton Zinoviev
<fabbione> ok
<fabbione> does he irc?
<carstenh> pitti: i've just updated the wiki :)
<pitti> Hi carstenh 
<carstenh> hi pitti 
<Kamion> fabbione: not much, he's in Bulgaria and connected to the rest of the world by a piece of wet spaghetti as far as I can tell
<fabbione> Kamion: ok.. i think i found an easy way to do it
<fabbione> yup
<{Seb}> sorry to bother you guys
<{Seb}> but after doing a latest upgrade on Breezy
<{Seb}> i can't login
<{Seb}> i exited Xorg and ran startx from the command line
<{Seb}> the errors including
<{Seb}> Could not init font path element unix/:7100, removing from list!
<{Seb}> Synaptics DeviceOff called
<daniels> those aren't actual errors
<{Seb}> right
<fabbione> {Seb}: you have been asked a few times already to ask these questions in #ubuntu
<daniels> suggest you put your Xorg.0.log up on pastebin.com or such -- and this is far more of an #ubuntu thing than #ubuntu-devel
<fabbione> please respect the policy for this channel
<daniels> breezy is not always expected to be totally usable: in particular, there are a number of 'gotchas' with upgrading X that mean you have be to be very comfortable with fixing broken systems if you want to use it right now
<{Seb}> where is the Xorg.log ?
<daniels> #ubuntu, please
<Kamion> elmo: could I have libnewt-dev libtextwrap-dev libdebian-installer4-dev in concordia's breezy chroot, please?
<Kamion> lifeless: any word on svn syncs?
<Kamion> elmo: actually, don't bother, I'm a muppet
<Kamion> note to self: do not assume that current CD images were built before the version of d-i you checked was in the archive an hour or two *after* the CD images were built
<Kamion> s/before/with/
<pitti> Hi mdz 
<pitti> mdz: how's the hotel? :-)
<mvo> hey mdz 
<mdz> pitti: ok
<mdz> about to break for lunch
<mdz> the weather in london is dreary as usual
<Kamion> speaking of lunch
* Kamion departs for same
<pitti> well, a Californian is not easily impressed...
<mvo> the weather in germany is pretty depressing too (at least in my part)
<pitti> ah, mvo
* pitti catches mvo 
<fabbione> hey mdz
<pitti> mvo: I plan to upload the split langpacks soon (monday maybe, still have to test them a bit)
<mvo> pitti: you need a update to the language chooser then? no problem
<pitti> mvo: I will add an upgrade notice about the split
<pitti> mvo: in that note I mentioned to consider the language selector
<pitti> mvo: is that possible?
<pitti> i. e. to do the transition automatically?
<pitti> mvo: it doesn't need to be ready at Monday, but by Breezy of course
<mvo> pitti: could you please give me the url of the final plan for the langpack split. i think it can be done
<pitti> mvo: http://udu.wiki.ubuntu.com/LanguagePackRoadmap is all I have
<pitti> mvo: I think the per-domain mapping can be done later; a coarse Ubuntu/Kubuntu distinction should be enough for now
<mvo> pitti: so we'll have -main, -kde, -gnome?
<pitti> well, we have l-p-de, l-p-kde-de, l-p-gnome-de
<pitti> I didn't want to add yet another 100 packages to introduce -main
<mvo> ok
<pitti> (well, 200 actually for base and update)
<pitti> mvo: can they be told apart by looking at /etc/lsb-release?
<pitti> mvo: i. e. is there "kubuntu" anywhere on kubuntu?
<Riddell> no
<mvo> pitti: my current idea would be to check if the "kde" package is installed
<Riddell> mvo: check for kubuntu-desktop
<mvo> Riddell: thanks
<pitti> mvo: I'd rather check for kde-core, since we don't have Kubuntu, but KDE language packs
<Riddell> well kubuntu doesn't install kde-core
<pitti> makes the thing more generic
<mvo> seb128: you asked me about direct insalls of debs with synaptic. as soon as apt can do it, synaptic will support it too. there is a apt--local-install--0 branch that works for me. I "just" need to sneak it somehow into apt--main 
<pitti> mvo: hm, it almost seems that we do need to select by actually installed packages and domains...
<mvo> pitti: looking for the packages is not a big deal is not a big deal as long as the package names are known
<pitti> mvo: seb128 will distract mdz for a while with a panel bug, then you can merge :-)
<pitti> mvo: I can give you can give you the map :-)
<seb128> easy :)
<mvo> pitti: with the map it should be easy
<mvo> (because language-selector already has to know about packages)
<pitti> mvo: I currently have a map source package -> {kde,gnome,}
<mvo> seb128, pitti: yeah! for distraction :)
<pitti> mvo: however, generating a map binary package -> {kde,gnome,} should be easy
<seb128> jdub: translation list?
<pitti> mvo: in fact l-s can produce that map on its own
<seb128> jdub: I could use it now to send something to translators ... :)
<pitti> mvo: I have a simple heuristics in langpack-o-matic which correctly maps all source packages
<mvo> pitti: do you export it somewhere? 
<mvo> (the list I mean)
<pitti> mvo: not that map, it's done on the fly
<pitti> I /msg'ed you
<mdz> mvo: hi, thanks for tracking that apt bug
<mdz> mvo: did you find the cause of the root bug, or just the wrong error message?
<mvo> mdz: so far only the wrong message. for the root of the bug I somewhat suspect the ftp.nl server. I can only reproduce it with that server
* icaro hi all
<pitti> hi icaro 
<icaro> hi pitti 
<seb128> elmo: libgtk2-perl sync should be fine now ? :) Can we sync gnome-alsamixer again (dholbach asked to drop it for no real reason and is fine to sync it)
<elmo> seb128: done
<seb128> elmo: thanks
<mdz> Kamion: now that we have debootstrap 3, when debootstrap is failing (like now, on libiw28), what does it mean we need to do?  update the overrides?
<\sh> hmm...anyone knows a possibility to buy ubuntu branded material in germany, for people without a CCard?
* lamont -> honey-do list
<pitti> Hey Keybuk 
<Keybuk> heyhey
<Kamion> mdz: yes, see jackass:~cjwatson/jessica which tells you what to do
<Kamion> mdz: (or use debootstrap --resolve-deps)
<Kamion> Packages to change from priority extra to important
<Kamion> ---------------------------------------------------
<Kamion> libiw28
<Kamion> mdz: note that some of the things it says are wrong, because it's only looking at germinate output on one arch
<Kamion> mdz: so it requires some human care
<Kamion> mdz: I've fixed the priorities of libiw{27,28}
<CarlFK> http://packages.ubuntu.com lists linux-image-686 but apt-get/cache don't see it - is this a bug?
<Kamion> linux-image-686 has been there for ever ...
<Kamion> check sources.list, apt-get update
<Kamion> if you only have a CD in sources.list you won't get linux-image-686
<CarlFK> ah - that explains it
<CarlFK> i thought everyting in main was on the cd
<pitti> CarlFK: that's the DVD
<CarlFK> thanks
<mdz> Kamion: thanks
<Kamion> mdz: also, cdimage fixes those priorities up based on its own germinate runs, so problems in the archive there shouldn't affect CD releases
<Kamion> yay, amd64 works again, powerpc doing pretty well
<maswan> Oh, joy. Reading /proc/net/tcp causes package loss when you are pushing some bandwidth.
<maswan> s/package/packet/
<Kamion> mdz: have you tested recent live CDs at all?
<Kamion> I'd like to release colony 2 but I'm leaving before I have time to try it
<Kamion> installs fine ...
<highvoltage> mdz: i see the breezy ltsp package installs nbd, is it used for local disk access?
<pitti> seb128: yay, fully translated gtk, panel, evolution, etc. again
<pitti> seb128: wanna test the new langpacks? :-)
<CarlFK> hoary, "recording level monitor" says "cannot connect to sound deamon.  please run 'esd' at a command prompt." but no sudo, so access denied.  is this worth a bug report? 
<pitti> CarlFK: why sudo?
<CarlFK> "access denied"
<pitti> hm?
<CarlFK> a user cant launch esd
<pitti> esd is a pure user app
<CarlFK> hmm
<CarlFK>  /dev/dsp: Permission denied
<CarlFK> guessing it is because the user isn't in the audio group
<pitti> that's possible
<CarlFK> although I am curious about the " at a command prompt" - that seems not verry Ubunu-ish
<HrdwrBoB> CarlFK: the default user is in audio
<HrdwrBoB> yeah submit a bigreport
<CarlFK> oh yeah... not a bug.. this is an added user
<Kamion> come *on*, little
<pitti> Kamion: colony 2?
<Kamion> aye
<pitti> \o/
<Kamion> though untested live CD unfortunately
<Kamion> if it works, it works, if it doesn't, it doesn't ;-)
<pitti> tautologically true at least :-)
<CarlFK> Kamion - if you can make it pxe boot, Ill test it every morning ;)
<Kamion> tempting
<Kamion> be bloody slow mind you :)
<Kamion> of course I'm going to release this image and then immediately run off to a different country for the weekend, but hey
<CarlFK> knoppix does it - it might even be faster than booting from the CD 
<CarlFK> yeah... HD access over the LAN is quicker than most of my CD drives
<Kamion> the casper hacking required would probably not be too difficult
* ..[topic/#ubuntu-devel:Kamion] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-love for getting involved | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released
* Kamion -> France
<Kamion> :-)
<pitti> Kamion: oh, wanna help seb128 to fix some gtk bugs?
<Kamion> no way
<CarlFK> pretty sure they have le net access ;)
<terje> sorry to bother, I asked in #ubuntu already. I'd like to customize the startup script that requests Language and Keyboard information on the ubuntu live CD. Does anyone know where that's located on the extracted CD image?
<lu|away> terje: https://wiki.ubuntu.com//LiveCDCustomizationHowTo <- in there, somewhere, I believe
<terje> I've read that already and it's not in there.
<terje> there's a lot of great info in there though...
<terje> I'm finished w/ the isolinux part.
<lu|away> oh, you want to customize it
<lu|away> I had assumed 'customize' meant 'force it to one language'
<terje> what I'm trying to do actually, is have the CD boot and not ask the user any questions.
<terje> I'd like to preselect some defaults
<wasabi_> I am speaking out of my ass, so I don't know anything... but here's what I suspect.
<wasabi_> There is a debconf file listing prefilled question answers someplace. ;)
<terje> heh
<terje> go on....
<terje> ;)
<wasabi_> I did some work on making an unattended d-i
<wasabi_> a few months ago.
<terje> unattended d-i ?
<wasabi_> yeah
<wasabi_> I belive the liveCD is just d-i.
<terje> what's d-i ?
<wasabi_> debian installer
<terje> oh!
<terje> ok, I gotcha.
<wasabi_> So, armed with that knowledge, I assume the language selection process is a debconf question
<wasabi_> and that you can preanswer it by finding this file and just putting the key/value into it
<terje> right, that's exactly what I'm after.
<terje> I wonder if there's anymore documentation that explains how the live CD is laid out.
<\sh> elmo: ping -> please remove sip-qt3, h.a.l. https://wiki.ubuntu.com/MorgueCandidates
<wasabi_> What is 'gecos'?
<terje> it's your entry info in /etc/passwd
<terje> more specifically, the users 'real name' in /etc/passwd
<\sh> hey mvo, janew :)
<mvo> hey \sh 
<dilinger> hm
* dilinger realizes his ubuntu cds that he ordered a while ago are probably waiting for him at his old residence
<tseng> dilinger: at least they are sans-porn this time
<tseng> id feel a little weird going in to pick those up
<dilinger> tseng: but i like porn!
* dilinger points out webcollage as his screensaver
<dilinger> :)
<JaneW> hi \sh
<\sh> JaneW: how is london today? And how is ogra behaving? I hope he's not boring u with his statements about gnome *lol*
<seb128> pitti: have you updated the language-packs or is colony 2 a "my translations suck" version? :)
<highvoltage> hi JaneW 
<Nafallo> maswan: ping!
<JaneW> hello highvoltage ...
<Nafallo> maswan: error 403 on http://se.archive.ubuntu.com/
<mdz> highvoltage: nbd is to be used for swapping over the network
<mdz> Kamion: I tested a live CD about a week ago, and X failed to start I think
<mdz> Kamion: I'm not going to be able to test live CDs until I return home, I expect
<pitti> seb128: no, it's not on colony 2
<wasabi_> Hey wow
<wasabi_> anybody tried putting ubuntu live cd in a windows box? haha
<ddaa> seb128: the copyright files for bonobo and libbonobo appear to be out of date
<ddaa> (ftp download addresses are not public)
<ddaa> mh... apparently it's just that ftp.gnome.org is broken...
<seb128> ddaa: ftp://ftp.gnome.org ?
<seb128> ddaa: yep, there is some issue atm
<ddaa> I guess the guy in charge is Novell staff :)
<seb128> rather redhat guys
<ddaa> I love to get upstream issues fixed by complaining to a co-worker :)
<seb128> actually jdub is the right guy to complain for that probably :p
<ddaa> seb128: btw, do you have any clue of the way gnome tarballs relate to cvs branches?
<seb128> jdub: ftp.gnome.org is private now? :)
<Lathiat> seb128: yeh we turned it into a warez dump
<Lathiat> apparently acc have broken something
<seb128> ddaa: they use gnome-2-n for names
<seb128> and tag BLABLA_2_N_M for the tarballs
<ddaa> okay so, for example, libbonobo-2.8.1 likely comes from the the branch gnome-2-8 in the libbonobo module, while bonobo-1.0.22 likely comes from MAIN?
<seb128> no
<seb128> -1.0.22 is a GNOME1 stuff
<ddaa> yes... but I have been told it is in the libbonobo cvs history...
<ddaa> maybe I was told wrong
<ddaa> (this sort of shit is a bit difficult to figure out)
<ddaa> So... you agree with the "libbonobo-2.8.1 likely comes from the the branch gnome-2-8 in the libbonobo module" bit?
<seb128> yep
<seb128> jdub probably knows for GNOME 1 stuff
<seb128> I've started to use GNOME with GNOME 2 ....
<seb128> http://cvs.gnome.org/viewcvs/ is useful for such stuff
<ddaa> lifeless told me that bonobo ~ libbonobo for RCS purposes...
<ddaa> seb128: yes, I know, but it's still archaeology...
<ddaa> And I prefer to ask people who know to sanity check my assumptions.
<ddaa> Don't worry, I'm not going to bother you for each and every gnome package.
<seb128> yeah, that would be jdub for this one
<ddaa> Just the annoying shitty confusing obscure ones :)
<seb128> or you can try on #gnome-hackers on gimpnet
<seb128> people here come from the GNOME1 ages :p
<ddaa> that's too much trouble... guess and hearsay will be enough, anyway, nobody really cares about gnome1 anymore.
<seb128> nop
<seb128> we are planning to drop these packages
<seb128> not all because some app (ie: gnucash) still use GNOME 1
<ddaa> gnucash... NIH galore
<ddaa> they have reivented about everything in gnome and guile...
<JaneW> highvoltage: fwiw I fixed the typo in the agenda for you ;)
* Lathiat wonders why the hell the bus logic driver is cased BusLogic
<highvoltage> JaneW: thanks! i'll edit the description a bit...
<JaneW> highvoltage: great thanks
<\sh> ok...time to go :)
<\sh> cu later ladies :)
<dilinger> what's the url to that ubuntu logo that's been floating around?  the 3 naked people
<dilinger> it was on planet.u.o a week or two ago
<Lathiat> http://www.alobbs.com/images/3ubuntu.jpg
<mdz> elmo,wasabi: did eclipse get sorted out?
<dilinger> Lathiat: thanks
<siretart> hi folks
<siretart> is there some issue with the torrent tracker? I don't get any seed with bittorrent when downloading colony-2 i386 live-cd
<mdz> terje: you can preseed all of the questions by the usual d-i means
<tseng> thom: would you suggest i take networking out of my runlevel, or will it actually integrate usefully with NM someday?
* Lathiat has found NM useless if you want to do anything other than switch between wired and wireless on a laptop and never used wireless if wired is plugged in or both interfaces at the same time
<Lathiat> which is annoying
<Lathiat> i cant for example bring up eth0 with an ip temporarily, NM eats it
* Lathiat uhs at CentOS
<Lathiat> its totally useless, it wont even do a basic install, the installer crashes out with some python backtrace
<tseng> the whole idea behind CentOS is a joke
<tseng> "here, use redhat with no support"
<Lathiat> i know
<Lathiat> i just find it amusing that it wont do a basic install
<tseng> that defeats the whole purpose, no one runs RH because they want to
<tseng> :D
<Lathiat> heh yeh
<Lathiat> oh well that was a wasted download
<Lathiat> suse seems pretty neat
<tseng> if you like kde maybe
<Lathiat> im ignoring that
<mae> Hi, is there a good howto or informational site on how to do C development on linux w/ eclipse?  I am a bit confused on how I can integrate something like `pkg-config gtk+-2.0 --cflags --libs` into the eclipse make system
<Lathiat> the bootup process is nice, and yast seems to work fairly well
<Lathiat> im sure i'd hate it shortly after i actually tried using it for anything usefull or something
<tseng> Lathiat: dont forget submount
<Lathiat> ah yes, submount
<Lathiat> <3
<Lathiat> so is ubuntu going to get a nice pretty bootup process in breezy
<tseng> right after sladen stops spreading plagues and starts coding
<Lathiat> heh
<Lathiat> one thing i found interesting about suse
<Lathiat> if i kill X
<Lathiat> it comes back within 1-2 seconds
<Lathiat> as in, boot loader and all
<Lathiat> s/boot/session
<Lathiat> seems to be a hacked up xdm which kinda explains it
<tseng> Lathiat: eh you mean it logs you back in?
<Lathiat> tseng: no as in it comes back to xdm
<tseng> hm sure
<Lathiat> tseng: back after hitting ctrl+alt+backspace its back ready to go in like 2 seconds
<tseng> kdm?
<Lathiat> im sure there X loads faster than ours, gdm aside
<Lathiat> tseng: it appears to be a pretty looking xdm
<tseng> are they maybe using dlloader?
<tseng> that starts faster in my experience
<Lathiat> dlloader?
<tseng> er
<tseng> its an xorg module loader that doesnt sacrifice goats to load things by pure magic
<Lathiat> oh
<tseng> it uses dlopen and resolves symbols like a normal application
<Lathiat> what does xorg do now?
<tseng> evil things
<Lathiat> ah, is dlloader better?
<tseng> yes
<Lathiat> why arent we using it?
<tseng> nvidia
<tseng> or was it ati
<tseng> one of them supports it now
<tseng> i think the other does not
<tseng> youd have to see daniels 
<Lathiat> heh it breaks with that?
<tseng> yeah
<maswan> Nafallo: we just patched and rebooted the ftpcluster
<tseng> they have to be linked properly to work
<Lathiat> tseng: as in open source or binary
<tseng> binaries are fine
<tseng> they just need to be sane binaries
<maswan> Nafallo: it should be working now, right?
<Lathiat> s/binary/proprietary binary
<tseng> which nothing was until recently
<Lathiat> i.e. nv vs nvisia, ati vs fglrx
<tseng> closed ones
<Lathiat> right
<tseng> needed fixed
<tseng> at least one was
<Lathiat> hey cool, the FC4 installer generates a kickstart file
<mae> FC4 blows.
<Lathiat> maybe, but the kickstart generation rocks :P)
<mae> its very polished, yes, but oh.. how i LOATHE yum/rpm
<Lathiat> (I'm fiddling with various distros i havent touched with a barge pole for a long time
<Justin> Lathiat: debian-installer will if you tell it to
<mae> and the anaconda partitioner makes me want to punch myself in the face
<Lathiat> Justin: yeh?
<Lathiat> Justin: didnt knwo that
<Lathiat> Justin: how do i tell it to?
<Lathiat> i want to automate installation of my laptop :)
<hunger> fabbione: Any news wrt. my tpm patch for the kernel? Did it change the ABI?
<Justin> debconf-get-selections --installer or such
<Justin> google: debian-installer preseed
<doko> wasabi: eclipse should build-depend on firefox-dev, not mozilla-dev. firefox-dev is in main
<doko> wasabi, wasabi_: eclipse should build-depend on firefox-dev, not mozilla-dev. firefox-dev is in main
<doko> mdz, wasabi, wasabi: eclipse still has a dependency on lucene, which is in multiverse.
<CarlFK> Lathiat https://wiki.ubuntu.com/LocalNetInstall
<Lathiat> CarlFK: thanks
<CarlFK> Lathiat - hang on...
<CarlFK> I need to rearange some steps to make it simpler
<CarlFK> Lathiat - reload
<CarlFK> Lathiat - previously I cut/pasted the commands I actualy used
<CarlFK> but later realized how to do it better, so I shifted things around
<CarlFK> so the changes I just made should work, but the commands were typed up in the editor, not the command promp - so let me know if anything is screwy
<Lathiat> cool
<CarlFK> it is lots of fun once you get it setup
<CarlFK> I did a laptop this morning, 1 hour later something was scrwey
<carlos> seb128, around?
<CarlFK> installing is so easy I had no problem just installing again
<seb128> carlos: pong
<carlos> seb128, hi
<carlos> I know universe is not yours, but could you take a look at https://launchpad.ubuntu.com/malone/bugs/1206  ?
<pitti> elmo: can I please have the libgda b-deps in davis' breezy dchroot?
<seb128> carlos: daf is upstream for that?
<seb128> pitti: new g-v-m for you
<pitti> seb128: oooh, will it fix all bugs?
<seb128> pitti: upstream version I mean
<carlos> seb128, no, he's not, I think jdub is
<seb128> pitti: there is quite some activity about it on #commits from novell guy atm, so I guess it has some changes
<seb128> pitti: have fun for your patches :p
<pitti> *sigh*
<seb128> pitti: new gnomevfs has some hal love too
<mae> guys do you think scoop will happen?
<seb128> carlos: you could have put the patch with the bug :p
<seb128> I'll have to get it before fixing :)
<seb128> carlos: I'll fix it 
<carlos> seb128, anyway, I think malone does not accepts attachmets (yet)
<carlos> seb128, O:-)
<carlos> seb128, thank you!
<seb128> np
<carlos> seb128, I had to move to breezy and it's a bit difficult to work with bazaar + gpg without gnome-gpg caching the passphrase
<seb128> carlos: blank passphrase? :p
<carlos> seb128, remind me that I should revoke from my key any trust I have in your key
<hunger> fabbione: My patch to the tpm module is supposed to be in 2.6.13-rc2 from what I hear.
<seb128> carlos: ah ah :)
<swarm> for 3rd party module patching issue is this the channel or #ubuntu-kernel?
<mae> what is a simple gtk ide.. (perhaps a *little* more advanced than gedit)
<mae> or really just editor
<mae> i can deal with compiling separately
<tseng> mae: you can set some prefences in gedit to make it alot more useful for editing code
<mae> man i've been trying to wrestle with eclipse.. but too hard to make it work right with pkg-config .. i dont think i'll ever be able to get past using vim :P
<siretart> mae: did you check anjuta?
<mae> anjuta is pretty automake-centric
<weasel> so, who do I pester if I want a package in hoary/universe updated?
<siretart> weasel: #ubuntu-motu
<weasel> motu stands for?
<siretart> weasel: master/maintainer of the universe
<weasel> thanks
<mgalvin> i'm running off the colony 2 live cd, its working pretty well so far on my home machine :)
<mgalvin> on to some more poking around, l8r
<camilotelles> Kamion? there is any news about UE?
#ubuntu-devel 2005-07-07
<daniels> if anyone's not convinced of the merits of using #include <X11/foo.h> instead of -I/usr/include/X11, consider the fact that that directory now includes 'misc.h' and 'os.h.'
<mjg59> Haha
<daniels> (of course, I think this is a bad idea, but whatever.)
<lamont> hrm... how does one get apache to return a TTL for stupid squid proxies to tell them not to cache things like Pacakges.gz and Release for more than say, 30 minutes?
<dato> lamont: vi /usr/share/doc/apt/examples/configure-index.gz +/No-Cache ?
<lamont> dato: thanks muchly
<tseng> lamont: ping
<lamont> tseng: ack
<tseng> lamont: dude, i could use some buildd mono love if you have time
<tseng> lamont: it needs a one-off bootstrap
<tseng> aka, its its own build-dep and we moved packages around
<tseng> lamont: should i mail you/infinity?
<_Legion_> I got a question about cairo-0.5 in breazy, could I use this channel?
<lamont> tseng: thanks for reminding me that mano is a pain... :-)
<lamont> go ahead and fire email at me/infinity and one of us will get to it...
<tseng> lamont: i head you were just starting to forget :)
<tseng> heard
<lamont> I might do it in the next few hours, family permitting, then I'll be offline for ~36 hours
<tseng> yeah ill be away a bit this weekend too
<tseng> ill try to get a mail out tonight with instructions
<_Legion_> Where could I fill a bug on a breazy package?
<_Legion_> sorry, breezy
<wasabi_> Epiphany still sucks at printing. =(
<daniels> gar, where's seb128 when you need him?
<daniels> pressing ctrl+shift results in a sticky keys alert
<retrix> hi all
<mae>  Hi, no matter what I try, I can't seem to get libglade to recognize my handler i keep getting "libglade-WARNING **: could not find signal handler" I compile wth : gcc `pkg-config --libs --cflags gtk+-2.0 libglade-2.0`
<mae>  = new 
<mae>  this is the source : http://cpp.sourceforge.net/?show=6980
<Lathiat> mae: looked at some workign examples to check yoru prototype is correct etc ?
<mae> ya its correct
<mdke> smurfix, around?
<smurfix> mdke: yo
<mdke> smurfix, man you are the best highlight responder around
<smurfix> heh
<smurfix> so wht's up?
<smurfix> other than me typing badly
<mdke> smurfix, -it has got some questions about hosting
<mdke> i can email if you prefer
<smurfix> please do that
<mdke> smurfix, the reason I came in here is that I forgot your address
<mdke> but i've found it now
<smurfix> :-)
<mdke> smurfix, you don't use an ubuntu one? just the noris one?
<mdke> smurfix, ok i mailed it to noris
<smurfix> mdke: I haven't yet asked anybody to set up an ubuntu address, so yeah, for now use @smurf.noris.de
<mdke> smurfix, i'm gonna be out for the whole of today so no need to answer particularly quickly
<pitti> Good morning
<\sh> jdub: ping
<Lathiat> bytee_: where the speaker at the fudcon panel?
<bytee_> Lathiat: where the speaker? eh?
<Lathiat> were
<Lathiat> ignore my engrish skills :P
<bytee_> i didn't speak at FUDCon II, no. i was busy in melbourne sitting for an exam ;-)
<bytee_> i attended the private conf call though
<Lathiat> ah i was just wondering if you were doing the speaking of the panel stuff cus it sounded like you on the videos :)
<bytee_> we have videos for FUDCon II?
<bytee_> Lathiat: if its FUDCon I, yes, i spoke at the panel. it was my summary
<Lathiat> i dunno i just found some torrents on the topic of some fedora channel :)
<bytee_> ah, right, then, thats me
<Lathiat> cool
<pitti> Hi shackan 
<pitti> Hi seb128 
<seb128> hey pitti
<pitti> elmo: here?
<seb128> pitti: have you read the comments about colony 2, one guy has GNOME hanging on startup, probably this esound issue
<pitti> no, I didn't see that
<pitti> odd thing
<seb128> the bug I pointed yesterday
<seb128> 3 guys already bugged about that this week
<pitti> ok, I'll try to triage it today
<seb128> thanks
<seb128> grumpf
<seb128> 17 mails on the GNOME ftp-list
<seb128> packaging day I guess :p
<pitti> seb128: does that happen for you, too?
<seb128> no :/
<pitti> seb128: it's saturday!!! :)
<daniels> seb128: yo!  something was broken earlier
<daniels> seb128: oh yeah
<daniels> 01:35 < daniels> gar, where's seb128 when you need him?
<daniels> 01:35 < daniels> pressing ctrl+shift results in a sticky keys alert
<pitti> daniels: hmmm?
<pitti> where?
<daniels> tseng: neither of nvidia or ati support dlloader at the moment, to my knowledge
<seb128> daniels: no updated related to that for weeks ...
<daniels> pitti: if I press Ctrl+Shift, I get a popup window saying 'oh my god dude, you just tried to activate sticky keys'
<seb128> and works fine here
<daniels> of course, I've done some seriously strange things to XKB over the life of this server
<HiddenWolf> seb128, who is the developer of sound-juicer?
<daniels> so it might just be that I need to restart
<seb128> HiddenWolf: ross
<daniels> root     30132  0.6  6.4  84900 65804 ?        S    Jun14 166:43 /usr/X11R6/bin/X :0 -br -audit 0 -auth /var/lib/gdm/:0.Xauth -nolisten tcp vt7
<HiddenWolf> he ever on irc?
<daniels> HiddenWolf: not here
<seb128> HiddenWolf: why ?
<seb128> HiddenWolf: if you have a bug use bugzilla :)
<HiddenWolf> seb128, got some questions about sound-juicer and replaygain.
<seb128> daniels: do you actually use the sticky keys? If not you can unset the config option
<HiddenWolf> live.gnome.org tells me he'd add it, but can't find anything on it.
<jdub> ftp://ftp.ssc.com/pub/lj/Web/RC/8272.txt
<jdub> ^ DO IT NOW
<daniels> seb128: i don't, no
<seb128> daniels: system, pref, keyboard, access, you have a sticky option
<seb128> jdub: WTF is that?
<seb128> "audio tool: amaroK
<seb128> audio tool: XMMS"
<jdub> seb128: LJ reader's choice awards
<seb128> is that a joke ?
<jdub> yeah, there were a number of rounds
<seb128> oh
<seb128> sucking
<jdub> those were the ones that made it, it seems :)
<jdub> amarok is rad though
<daniels> a little busy for my tastes, but does look to have some pretty cool stuff
<seb128> it sucks
<seb128> it's ugly :p
<pitti> seb128: only because it has the 'K' in it, or objectively? :-)
<pitti> hey hey sabdfl 
<seb128> pitti: I've tried it once, the UI has a zillion of stuff to click on
<sabdfl> hi guys
<sabdfl> elmo: around?
<abelli> pitti: ding
<pitti> Hi abelli 
<abelli> pitti: i love you, said this.
* pitti blushes
<abelli> pitti: . can you tell me more on your work on ruby packages?
<daniels> either that or my control key is actually sticking, which I refuse to believe
<daniels> it must be a GTK bug
<pitti> abelli: I don't work on them, I just did a security update
<daniels> seb128: as I said -- a little busy, but has great capabilities
<abelli> pitti: because in hoary there are big problems with ruby ..
<abelli> pitti: the soap library isn't in the main package .. and cannot be found by gems ..
<pitti> abelli: any details?
<pitti> is there a bug?
<pitti> ... report?
<abelli> its not really a bug is just that the debian maintainer has split ruby on several packages.
<abelli> and i can't find madeleine and soap libraries.
<abelli> well not only me .. everyone.
<pitti> hm, no idea
* pitti never wrote a single line of ruby
<pitti> abelli: so if we need to promote some libs into main in breezy, that shouldn't be a problem
<abelli> pitti: yes .. but i think its not very correct separating the interpreter from the base libraries ..
<abelli> moreover even rdoc is not in the maian package, and this is wrong because ruby needs rdoc to be ruby.
<pitti> abelli: rdoc doesn't seem to exist in breezy
<abelli> mmm wait a sec, im going trough logs.
<mdz> Kamion: around?
<pitti> abelli: sorry, it's there
<pitti>       rdoc |    1.8.2-1 | http://de.archive.ubuntu.com breezy/universe Packages
<abelli> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=290705
<pitti> abelli: what a mess...
<abelli> pitti: i know .. :(
<abelli> pitti: can you ppl do something?
<abelli> Keybuk: ciao
<pitti> Hi Keybuk 
<pitti> pitti: sure, just file bugs about what is necessary to sanitize it again
<abelli> that would mean doing something completely different from ruby ..
<pitti> well, then it should really be fixed in Debian proper
<abelli> s/ruby/debian .. sorry :)
<abelli> got to go .. ciao 
<pitti> Riddell: here?
<pitti> seb128: 
<pitti> here?
* Keybuk secretly hands today's dilbert around
<pitti> hehe
<seb128> pitti: pong
<pitti> seb128: if I run "esd -nobeeps" in a shell, is that supposed to daemonize?
<pitti> seb128: I can reproduce the hang here if I call esd in a shell and killall gnome-panel
<pitti> seb128: it worked on my desktop, but that is gone now (new computer arrives at wed); on my ibook it hangs
<pitti> seb128: I can't remember whether just calling esd daemonized or not on my desktop
<seb128> pitti: yep, it should play a sound and return
<pitti> seb128: well, the ugly sound is suppressed with -nobeeps
<pitti> ok, and it does return for you? with 0.2.36?
* seb128 installs esound
<pitti> ah, you didn't have it`
<seb128> just noticed that I've installed polypaudio the other day when you asked for the audiosink for it
<seb128> no, "esd" is not supposed to return
<pitti> well, the "esd" emulating wrapper of polypaudio does return
<daniels> Keybuk: you broke sabdfl
<seb128> pitti: esound not, I run "esd &" usually 
<pitti> ah, ok
<pitti> seb128: can you please run it in the foreground, then killall gnome-panel?
<seb128> yep
<seb128> supposed to do something out of breaking gaim ? :p
<pitti> well, for me it hangs the panel
<seb128> panel restarted fine
<pitti> the panel finishes loading if I kill esd
<seb128> I don't use sound events neither
* seb128 activates that
<seb128> no change
<seb128> works fine
* pitti downgrades to 0.2.25
<pitti> erm, 0.2.35 even
<pitti> however, that hangs the panel too, so no regression
<seb128> weird
<pitti> I try to restart my session and see whether it hangs
<seb128> we started getting bugs about this this week
<pitti> I didn't have esd installed when I booted this session
<pitti> brb
<Keybuk> daniels: I did, how?
<daniels> 12:26  * Keybuk secretly hands today's dilbert around
<daniels> 12:28 -!- sabdfl [~mark@sabdfl.silver.supporter.pdpc]  has left #ubuntu-devel [] 
<Keybuk> heh
<lsuactiafner> he left us ):
<pitti> seb128: I get the hang, too, debugging now
<pitti> seb128: btw, I didn't find a new g-v-m on ftp.gnome.org
<seb128> pitti: the ftp sync is broken, I'll copy it somewhere for you
<seb128> pitti: and yep, it breaks stuff too here, probably stuff playing sound events
<seb128> pitti: ie, just got a "mail reply" hanging and a new browser window, and stop esd fixed them
<pitti> seb128: really funny, as long as I strace the daemon, it works and makes progress, but as soon as I stop strace, it hangs again *grumpf*
<seb128> ah ah
<pitti> heisenbug
<ajmitch> pitti: sounds like udev problems I had in the past :)
<tseng> daniels: http://www.nvidia.com/object/linux_display_ia32_1.0-7167.html
<tseng> daniels: "added xorg dlloader support"
<seb128> pitti: for me it hangs when trying to play a sound event
<pitti> seb128: and when you "strace -p $(pidof esd)" it works?
<pitti> I swear, that will be the last esound bug I chase, I'll try to fix polypaudio instead...
<seb128> pitti: now it doesn't hang
<seb128> even without the strace
<seb128> I've just restarted esound ...
<daniels> tseng: hm.  wonder if they added a _drv.so or whether they just fixed inter-module global data references
<tseng> daniels: .so iirc
<tseng> daniels: not to quote me on that
<seb128> pitti: funny, the session hangs when I start it, and unblock when I strace esound
<pitti> seb128: same for me
<pitti> seb128: Debian's version hangs, too, so it's not a bug in the Ubuntu patches
<pitti> seb128: gdb output is useless even with -O0 -g :-(
* seb128 kicks esound
<pitti> and strace doesn't help, too, so how on earth shall this be debugged`
<JanC> pitti the panel finishes loading if I kill esd
<JanC> heh, you have the esd problem I had a couple of days ago ?   :)
<pitti> yes, it happens on my notebook
<pitti> worked fine on my desktop
<JanC> well, I'm using polypaudio now  :)
<Zomb> yeah, consider replacing esd
<pitti> I do
<pitti> but polypaudio crashes very often for me
<pitti> in general, polypaudio is soo much better
<tseng> if esd/polyp crashes
<tseng> it causes very confusing badness for gstreamer users
<pitti> we had gstreamer->alsa for a while, but dmix doesn't work for everybody, so I decided to keep a sound daemon for now
<tseng> muine segfaults, totem probably throws up some incomprehensible warning
<pitti> erm, a C# program segfaults? ouch
<tseng> eh thats not C#
<JanC> the bindings are not C# ...
<tseng> it has a C lib to bind gstreamer and libogg, libid3 etc
<tseng> i filed a bug sometime ago to deal more nicely with total gstreamer failure :)
<pitti> bah, 121231 layers of sound API really suck...
<hunger> Is xkb broken once again?
<daniels> worksforme
<seb128> pitti: http://pastebin.com/306402
* Lathiat grins at daniels 
<hunger> daniels: I can no longer get back to the consoles (Alt F1, etc.)
<tseng> i can
<seb128> pitti: that's esound staced for some working time and then hanging
<hunger> daniels: Maybe just a local messup... I have those way more often than you can possibly break X;-)
<pitti> seb128: it works with libesd0, but hangs with libesd-alsa0, can you confirm this?
<seb128> pitti: lemme try
<daniels> hunger: x hasn't been touched in a while now
<hunger> daniels: Are you sure? I remember updating xorg during the last couple of days.
<hunger> daniels: I have not rebooted since this morning... xev does show Alt, Ctrl and Fx working, so it is probably something local.
<daniels> hunger: well, tollef uploaded what was more or less a straight rebuild
<daniels> the last significant change was mdz last sunday or so
<pitti> seb128: I think I have some idea where to look now
<seb128> pitti: cool ... what is the issue?
<pitti> seb128: since it works with oss, the bug seems to be in the alsa driver
<seb128> pitti: BTW http://people.ubuntu.com/~seb128/gnome-volume-manager-1.3.2.tar.gz
<pitti> seb128: esd ships with two alsa drivers
<pitti> seb128: alsa09 and alsa (old and new)
<seb128> hum, k
<pitti> seb128: esd 0.2.36 switched the default one
<seb128> but you have the issue when downgrading ti 0.2.35 no ?
<pitti> seb128: so first I'll try with the old one, if that works, we have a nice workaround
<pitti> seb128: hm, I tried that, but I can't remember any more (should work)
<seb128> you have downgraded libesd too, or only esound?
<pitti> no, everything
<pitti> lemme try again
<seb128> k
<pitti> seb128: I now have condensed the significant changes between 0.2.35 and .36, only 137 lines
<lamont> daniels: could you deal with xorg/xcursors, so I don't have to hit Mithrandir with you?
<seb128> pitti: it works fine with 0.2.35?
<pitti> seb128: just testing
<pitti> seb128: it hanged in 2/4 cases
<seb128> k
<lamont> daniels: xorg -33 build-dep's xcursors, which is dep-wait libxfixes-dev (>= -33)
* pitti blames new alsa code in the kernel
<daniels> lamont: you can't build with an old libxcursor?
<lamont> if I _HAD_ an old libxcursor
<daniels> lamont: *shrug*
<daniels> i was in favour of fixing pkg-config, myself
<lamont> s/fixing/bastardizing/
<daniels> lamont: if you can wait for -35, fixes/damage/composite are being split out
<lamont> how soon on that front?
<pitti> Hi lamont
<daniels> next week?
<pitti> seb128: yes, definitively hangs with 0.2.35, too
<daniels> i'll upload -34 tomorrow fo'sho, then -35 tuesday or so
<seb128> pitti: :(
<pitti> seb128: recent 2.6.12 updated the alsa driver, maybe that was buggy
<lamont> any chance of getting fixes split out for -34? :)
<seb128> pitti: oh, right
<pitti> seb128: I try with the hoary kernel now
<lamont> tuesday is plenty soon enough
<daniels> lamont: i'm trying to separate my break-stuff-out and fix-stuff uploads
<lamont> makes sense
<lamont> morning pitti
<daniels> but yeah, tollef sucks for causing a regression in pkg-config :)
<lamont> seb128: btw, control-center is ftbfs - looks to be a dpkg-dev victim
<lamont> dh_install -pcapplets-data
<lamont> cp: cannot stat `./debian/tmp/usr/share/control-center-2.0/icons': No such file or directory
<seb128> k, thanks
<seb128> any other GNOME stuff ftbfsing?
<lamont> libgtk2-perl_1:1.091-1
<seb128> that's known
<seb128> others? :)
<lamont> mozilla-thunderbird_1.0.2-1build1 guile-1.6_1.6.7-1ubuntu2/ia64
<lamont> gnome-app-install_0+20050404a-3/i386
<seb128> that's for mvo :p
<lamont> seb128: that's about it in my mailbox
<lamont> there might be some b0rked dep-wait's that I'm not seeing
<seb128> that's fine, thanks
<pitti> seb128: negative, it hangs with the hoary kernel, too
<tseng> wb pitti 
<pitti> seb128: it seems that this is a gtk bug after all... *duck*
<seb128> ah ah
<pitti> seb128: seriously, did anything gnome-ish change in the last week that deals with gstreamer/sound events?
<pitti> seb128: so what we have: hang: hoary esd+hoary kernel, hoary esd+breezy kernel, breezy esd + hoary kernel, breezy esd + breezy kernel
<pitti> (all with libesd-alsa0)
<pitti> I try again with libesd
<pitti> s//0/
* lamont was wondering when  became a number...
<daniels> pitti: see?  told you qwerty was evil
<daniels> er, qwertz
<lamont> qwertz comes from the ground
<daniels> qwertz comes from hate
<pitti> daniels: well, it's rather my hands... on my dvorak it would have been [ which doesn't look much nicer :)
<daniels> otoh, qwerty is made of awesome
<pitti> yes, for programming american qwerty rocks
<pitti> just not for writing German texts :-)
<daniels> ctrl:nocaps,compose:ralt
<daniels> 
* pitti tries to use english dvorak, but falls back to qwertz too often...
* lamont goes to renn faire with the family
<pitti> seb128: nope, reverting to the older esd driver doesn't help either
<pitti> seb128: WHAT DID YOU DO???
<seb128> pitti: surprise :p
<pitti> seb128: do the sound events use gstreamer? or esound directly?
<lamont> Manifying blib/man1/cyradm.1p
<lamont> "Manifying"???? that's not a verb, even in americanese
<pitti> ah, *idea*
<seb128> pitti: esound
<seb128> oh?
<pitti> seb128: urgh, it's the old driver that sounds so ugly with dmix...
<pitti> seb128: right, switching gstreamer to alsa doesn't help to prevent the hang
<seb128> gstreamer doesn't act here
<pitti> seb128: which package does sound events?
<seb128> gnome-control-center
<pitti> that's the library for sound events?
<pitti> it must be something gnome-panel links to...
<seb128> pitti: g-c-c has a libsounds/ folder
<seb128> pitti: and ./gnome-settings-daemon/gnome-settings-sound.c 
<pitti> bah, gstreamer-properties now hangs as well
<seb128> pitti: oh, libgnome has stuff too
<pitti> works well with polypaudio at least
<seb128> when it doesn't crash *g*
<pitti> does it crash for you very often?
<seb128> I don't use it
<pitti> seb128: I immediately see it since I get a crash report dialog 
<seb128> I'm not a good audio client
<pitti> ah, ok
<seb128> I don't care of playing 2 sounds, and I don't use sound events for GNOME
<seb128> basically alsa without dmix is fine for me :p
<pitti> I don't use sound events either
<pitti> but hearing icq sounds or console beeps is nice when I listen to ogg files...
<seb128> I use "beep" :)
<pitti> powerpc's don't have a "pc speaker"
<seb128> yeah, I know
<seb128> just speaking for me
<seb128> anyway, where do you want to get people playing?
<pitti> "where"?
<seb128> polypaudio? esound? alsasink?
<pitti> polypaudio actually
<seb128> just say what setup I should use
<pitti> if we can stabilize it
<seb128> I'm happy to play with either of that
<pitti> esound is the fallback if polypaudio is too buggy
<pitti> that's why I try to get both in shape
<seb128> k, go for polypaudio so
* seb128 kicks Debian
<pitti> why?
<seb128> that would make easier if any ftpmaster would accept polypaudio and the new gst-plugins0.8
<pitti> yep
<seb128> pitti: speaking about audio ... libmpcdec?
* seb128 wants to sync gst-plugins0.8 on Debian
<seb128> and some people are asking for that
* pitti whistles
<seb128> :)
<pitti> seb128: sorry, network trouble, I didn't get your last question
<pitti> no, will do it RSN
<pitti> well, let's do it *now*
<seb128> thanks
<pitti> and defer that esd shit a bit :-)
<seb128> he he
<seb128> elmo: glib2.0 (experimental) sync please
<pitti> seb128: latest gnome-control-center is from June 12
<pitti> seb128: I think the problem appeared way after that
<seb128> we started get bugs this week about this
<pitti> hm, libgnome is from yesterday...
<pitti> too late, I guess
<pitti> previous version from Jun 10
<seb128> yep
<pitti> any other idea?
<pitti> it makes both gstreamer-properties and gnome-panel hang
* seb128 reads -changes
<seb128> it makes epiphany/evolution hang here
<seb128> and gnome-session
<seb128> ie: everything trying to play sound-events
<JanC> for me even gedit hanged with esd  :)
<JanC> or gnome-terminal
<JanC> almost everything in gnome   :)
<pitti> seb128: any idea which package actually could cause that?
<seb128> pitti: I've sync gstreamer0.8 with Debian on the day of the first bug
<seb128> but I'm not sure than gst is used for sound-events
<pitti> $ ldd /usr/bin/gnome-panel|grep gstr
<pitti> -> empty
<seb128> the app don't use gst
<seb128> they make sound events
<pitti> yeah, that's why gstreamer is unlikely
<seb128> probably using libgnome for this
<seb128> which doesn't use gst
<pitti> well, we can try downgrading to the previous libgnome
<seb128> look on the bug
<seb128> wednesday
<seb128> and libgnome has been updated 2 days after that
<seb128> I doubt of it
<pitti> yeah, me too
<pitti> well, esd is certainly part of the problem, but there must be another package involved
<seb128> elmo: can you reject libwnck NEW? if it's accepted that's not a big deal, that's just some debian/changelog changes
<seb128> pitti: have you looked on the strace output before?
<seb128> seems weird to me
<pitti> which url again?
<seb128> http://pastebin.com/306402
<seb128> why all these timeout?
<pitti> ah, have it
<pitti> well, if nothing connects to esd, select() returns with a timeout, nothing unusual
<pitti> I guess it does some periodic tasks in between
<seb128> k
<seb128> bah, doko has uploaded a zillion of package this week
<seb128> nice to figure what changed from -changes :p
<seb128> pitti: oh, you have hacked the control-center 
<seb128>    * debian/patches/23_default_soundcard_selector.patch:
<seb128>      - After changing the default soundcard, send a SIGUSR1 to esd to have it
<seb128>        reconnect to the sound card.
<pitti> right, but that only affects gnome-sound-properties, no libraries
<seb128> bah, I don't have this version
<seb128> it ftbfs as pointed by lamont
<pitti> oh?
* pitti adds todo item
<seb128> I'll have a look
<seb128> no, that's for me :)
<pitti> ok
<seb128> lamont said probably some dpkg changes
<seb128> and I've to roll a new tarball and update the package
<JanC> can the esd problem be triggered/caused by the kernel update on tuesday?
<JanC> http://lists.ubuntu.com/archives/breezy-changes/2005-June/007506.html
<seb128> nop
<seb128> does that with the hoary version too according to pitti
<pitti> JanC: I think that is a combined esd/some gnome library bug
<JanC> ah that's what you were talking about alsa updates
<pitti> JanC: 
<pitti> <pitti> seb128: so what we have: hang: hoary esd+hoary kernel, hoary esd+breezy kernel, breezy esd + hoary kernel, breezy esd + breezy kernel
<pitti> <pitti> (all with libesd-alsa0)
<pitti> Hi ogra
<ogra> hi pitti
<pitti> seb128: https://wiki.ubuntu.com/MainInclusionReportLibmpcdec  -> go ahead :)
<seb128> pitti: thanks :)
<seb128> you rock ;)
<pitti> Hi mdz 
<mdz> pitti: hey
<pitti> mdz: I just saw that ocfs2-tools is already in main
<pitti> mdz: https://wiki.ubuntu.com/MainInclusionReportOcfs2Tools -> has this been resolved? upstream still says it's beta
<mdz> pitti: what does fabbione say?  isn't that his baby?
<pitti> mdz: AFAIK we agreed to defer it until we have a definitive word about getting dedicated upstream support
<pitti> .. or at least an upstream release
<mdz> pitti: ok, it should be removed from the seeds, then
<pitti> "*** WARNING WARNING WARNING ***
<pitti> This is BETA software. It should absolutely NOT be run on production systems."
<pitti> and upstream bug tracker has shitloads of critical bugs
<pitti> having it in universe is fine for playing around, but it's too premature for main IMHO
<pitti> s/premature/immature/
<mdz> May 30 22:41:55 <fabbione>      mdz: can we promote ocfs2-tools to supported? and can i pre-seed the redclustersuite for supported? the latter is more important since it ships a build-dep for lvm2
<mdz> pitti: feel free to remove from the seeds if you and fabbione are in accord
<pitti> mdz: ok, I talk with him agaiin
<pitti> Hi fabbione 
<pitti> fabbione: I just saw that ocfs2-tools is already in main. Are there any news wrt dedicated upstream support? upstream's hp still says it's too unstable for production
<fabbione> pitti: yo
<fabbione> pitti: i know. it's exactly the same as before, with the difference that ocfs2 is going kernel upstream.. so there is a lot of bug fixing going on
<fabbione> together with some of the redhat cluster stuff
<pitti> fabbione: would you agree to demoting it to universe later if there is no release and dedicated support by breezy release?
<fabbione> pitti: yes. that will be ok for me.
<pablo_> where can I download Colony CD 2?
<pitti> cdimage.ubuntu.com
<pablo_> thanks pitti :-)
<doko> seb128: the uploads this week were universe and java only
<seb128> doko: still a flood on -changes :p
<doko> pitti: the main inclusion review for libxt-java and libxp-java is outstanding, OOo2 FTBFS
<pitti> yes, I know
<fabbione> doko: so OO2 is still FTBFS?
<doko> fabbione: universe dependency :-/
<pitti> doko: reviewing now
<fabbione> oh ok
<daniels> doko: why are those abominations being packaged for java?
<daniels> assuming libxp-java is the java binding for xprint, libxp6 has been deliberately kicked out of main, so having libxp-java in main would be counterproductive
<pitti> daniels: no, it's something XMLish
<pitti> XmlParser
<pitti> yay for clear package names
<fabbione> doko: what's the debian/rules target to unpack/patch gcc-*
<daniels> pitti: jesus
<pitti> daniels: similarly, libxt-java is XSLT
<pitti> those lazy bastards...
<fabbione> JEEEE
<pitti> libxslt-java would not have been *that* much longer
<fabbione> let's move java in breezy-will-never-see-the-light
<daniels> i'd reject it for that reason alone
<daniels> HEY LETS SAVE TWO LETTERS ON A PACKAGE NAME, ITS NOT LIKE ANYONE IS USING LIBXT OR LIBXP ANYWAY, RIGHT?
<fabbione> ROTFL
<pitti> daniels: it's a library for interfacing windows xp :-)
<fabbione> daniels: file an RC bug on them ;)
<pablo_> :o
<fabbione> Severity: grave
<fabbione> Justification: X developers had a heart attack
* pitti has some real fun searching for security vulnerabilities of "xp"
<pitti> 225 advisories, 224 viruses, for "xp+java" -> REJECTED :-)
<fabbione> ahaha
<daniels> aspires to be like xprint, but can't even be that good -> REJECTED
<doko> fabbione: patch
<doko> fabbione: or unpack
<fabbione> doko: thanks
<fabbione> doko: btw.. did you get my emails with gcc ICE on sparc?
<doko> today?
<fabbione> doko: do you think the last gcc will fix?
<fabbione> doko: nope.. a couple of days ago more or less
<doko> probably not. there is one C++ wrong-code bug fixed in the RC3 upload.
<fabbione> doko: hmm ok
<doko> you mean: Log for failed build of mysql-dfsg_4.0.24-10 (dist=breezy)
<fabbione> yes
<fabbione> the same ICE happens on a more recent version of mysql-dfsg
<fabbione> we also still have the ICE problem on ppc with UNIONFS
<pitti> doko: ok, approved, mdz automatically got mail
<doko> pitti: fine
<doko> fabbione: I know, the preprocessed source would help
<fabbione> doko: there is no preprocessed source.. if you can tell me how to generate it
<pitti> cu later
<swarm> patches for a kernel module should be discussed here or in #ubuntu-kernel?
<fabbione> doko: we agreed (last time) that either you or jbailey would look at it
<fabbione> swarm: #ubuntu-kernel usually....
<fabbione> swarm: but what kind of patch is it?
<swarm> fabbione, it's about ati fglrx kernel module
<daniels> swarm: what about it?
<fabbione> swarm: and why do we need to patch the kernel?
<swarm> fabbione, that ati distributes new versions with same mistakes and I have tried to fix them using same type of modifications from past patchs. such changes seem to work but thereisn't any official patch for new releases of such ati fglrx kernel module.
<daniels> swarm: try the forums over on rage3d.net (and, conversely, nvnews.net for nvidia)
<fabbione> swarm: we don't support ati binary drivers.
<daniels> they seem to have the most active community of fglrx/nvidia-binary users
<fabbione> swarm: patches for them, is something you want to discuss with ATI.
<doko> fabbione: ok. I'm away now. just compile the next time adding -save-temps to CFLAGS
<fabbione> doko: ok.. that's either tomorrow or monday business :)
<swarm> fabbione, I can do it myself. I was only stating that currently fglrx support from ubuntu lacks due to ati mistakes propagated version to version and that could be easy to fix such mistakes. thanks for your hints.
<fabbione> swarm: you are not giving us enough information.. on what distro are you trying to build and what kernel?
<fabbione> swarm: i did compile ATI/nvidia yesterday on .12 without (almost) any problem)
<fabbione> distro = release 
<fabbione> hoary? breezy?
<fabbione> swarm: if you maen that breezy is lacking linux-restricted-modules.. we know.. we didn't get around to prepare it yet :)
<swarm> fabbione, fglrx64-6-8-0_8.13.4-2 on hoary using 2.6.12-2 and 2.6.12-3
<daniels> swarm: yes, the upstream module will need a patch as it only supports .11
<fabbione> swarm: we don't support .12 on hoary... 
<daniels> swarm: check rage3d.net et al
<fabbione> daniels: yeah the patch is a 2 line change...
<daniels> swarm: that's the package name as it comes from ati -- he's downloaded it, but the source as it comes doesn't support .12
<daniels> fabbione: sounds about right
<fabbione> daniels: yeah.. it's something like:
<fabbione> - dev->node_num
<fabbione> + dev->dev.node_num
<fabbione> or along that line
<fabbione> repeated in more or less 10 printk
<swarm> fabbione, that is in agpgart_be.c no?
<fabbione> ;)
<fabbione> swarm: yes
<swarm> fabbione, 8 times
<swarm> fabbione, then there is fglrx_public.c that is more a mess
<fabbione> it did build fine here.. i think
<swarm> on breezy?
<fabbione> yes
<fabbione> kernel backports are bad
<fabbione> seriously
<fabbione> specially if you don't know why/what to backport
<fabbione> anyway.. dinner time :)
* fabbione &
<rubenv> I'd like to help out in stress testing breezy, I know how to fix breakage, but I'd like to use my laptop at least occasionally, would I be crazy to upgrade as soon as restricted modules have landed again?
<ogra> Riddell, ping
<daniels> http://cvs.freedesktop.org/xorg/xc/programs/Xserver/hw/xfree86/common/xf86Events.c?r1=1.10&r2=1.11
<xhaker> hello daniels, any word on fglrx module compilation in gcc4 ?
<Lathiat> xhaker: You know gcc-4 miscompiles the kernel atm (or so im told)
<Lathiat> current ubuntu kernels are built with gcc-3.4
<nanophase> Lathiat, in what way?
<nanophase> (does it miscompile the kernel)
<Lathiat> nanophase: dunno
<nanophase> ah ok
<Lathiat> it just generates some wrong code somewhere i guess
<nanophase> my last build runs fine I guess
<nanophase> good to know, will check a bit more, thx :)
<xhaker> wierd, when i compile fglrx module it does indeed say it was compiled with 3.4, when i patch it using fc4 patches
<Lathiat> fc4 patches?
<Lathiat> you may need to put CC=gcc-3.4
<xhaker> but, i need the patches because it doesn't compile normaly, complaining of deprecated functions and such
<Lathiat> most things (vmware, nvidia) will whinge
<xhaker> fedora core 4
* Lathiat looks at the name of the channel
<Lathiat> ;p
<xhaker> the thing is, it gives a bunch of errors with normal compilation, but shouldn't it work if the module is being compiled with 3.4? well, fc4 patches for ati drivers, can't say that is distro specific
<xhaker> i just know that it compiles with the patches, BUT dri doesn't work
<Lathiat> should work, assuming the FC4 patches dont do anything else
<Lathiat> but i mean, compiles != works
<Lathiat> check google, forums
<Lathiat> just make sure you compile with gcc-3.4
<Lathiat> if its really dodgy you might need to change what 'gcc' points to temporarily
<Lathiat> or throw out that ati and get a nvidia :P)
<xhaker> kinda hard... im pretty sure my laptop would die
<xhaker> lol
<Lathiat> i can swap my laptop one around :)
<Lathiat> can order it with an ati or a nvidia and its just a module :P)
<Lathiat> damnit, my stupid P keyu
<Lathiat> keep hitting it when i hit )
<xhaker> lol
<xhaker> hmm.. mine is modular, but i don't think it supports other than ati 
<xhaker> it has a intel integrated tho
<xhaker> lol
<schweeb> intel integrated isn't bad at all, as long as you're not trying to play a lot of games
<xhaker> then i prefer the ati with the radeon driver
<xhaker> :P
<Lathiat> i dunno, the intel drivers are pretty godo
<schweeb> Lathiat: not to mention OSS
<schweeb> I like not having to use the linux-restricted-modules packages anymore
<xhaker> hmm.. lets not be like.. "all should be oss"
<xhaker> i don't use them
<xhaker> i just install the ati package or something
<schweeb> I was fine with the closed source driver... it's just that there are licensing issues involved, and any common problems with the OSS drivers tend to get fixed more quickly
<schweeb> i.e. you don't have to rely on the vendor to fix them
<xhaker> true
<Lathiat> the nvidia driver seems to be generally of better quality
<Lathiat> altho it took them a long time to get laptop power management right
<xhaker> nvidia's are oss?
<Lathiat> no
<Lathiat> well, the is one
<Lathiat> but the official 3d drivers arent
<xhaker> nv
<Lathiat> same as ati
<xhaker> i remember now
<pablo_> ls
<schweeb> wrong terminal, pablo_
<thesaltydog> yes, for sure
<pablo_> hi guys I installed the latest snapshot, but when I start gnome gnome-panel doesn't charge totally and it freezes :/ 
<pablo_> hahah yes schweeb :)
<pablo_> some suggestions for that? :)
<schweeb> pablo_: have you apt-get updated && apt-get upgraded to the latest versions?
<pablo_> uhh nop, I'll do it right now, thanks schweeb :P
<schweeb> and did you install from the Colony 2 CD, or an actual daily snapshot?
<pablo_> actually dialy snapshot
<schweeb> daily snapshots are generally really broken in my experience
<schweeb> the colony CDs are a bit better
<pablo_> off! :(
<schweeb> best to go colony then upgrade from there
<pablo_> :S I dowloaded 600 mbs for nothing, jesus
<xhaker> pablo
<pablo_> yes xhaker ?
<xhaker> you can easily fix that
<pablo_> :D 
<schweeb> pablo_: once you upgrade, you should be fine
<pablo_> oh ok
<schweeb> that's your first course of actoin
<schweeb> *action
<schweeb> and you're not using an old profile, are you?
<xhaker> go to the first terminal, sudo killall gdm && sudo killall esd && sudo apt-get install polypaudio polypaudio-alsa polypaudio-x11
<schweeb> you may have to start out with new gnome profiles and stuff
<xhaker> then sudo gdm
<xhaker> and enjoy
<schweeb> isn't polypaudio pretty much being entirely scrapped?
<schweeb> I've heard stirrings of actually using DMIX
<xhaker> hmm
<pablo_> uhh! thanks xhaker !
<xhaker> pablo if you prefer you can keep esound..
<xhaker> and just get libesd0
<schweeb> polypaudio wasn't ready for this release, and I haven't heard much about it being fixed since
<schweeb> esd should be installed by default
<xhaker> libesd0-alsa is the cause of the problems, or not, but this two methods fic it
<pablo_> oops
<xhaker> fix
<pablo_> so? just upgrading I think :/
<xhaker> pablo_
<pablo_> yes?
<schweeb> gnome-panel problems are libesd related?
<schweeb> that's a new one to me
<xhaker> sudo killall esd && sudo killall gdm && sudo apt-get install libesd0
<pablo_> ok
<xhaker> do that in the first terminal :)
<xhaker> schweeb, there is a bug filled i think
<xhaker> installing libesd0 fixes the hand
<xhaker> hang
<xhaker> libesd0-alsa is having some problems.. or might be gnome having some problems with it
<schweeb> hrm, I've not had any problems recently
<xhaker> i had that problems and unticked the "sounds for events"
<schweeb> and I just upgraded mere hours ago
<xhaker> it was working, but then, if i'm really testing this thing why not polypaudio?
<xhaker> :P
<pablo_> yep, I don't use esd :P
<xhaker> pablo_ so.. now hows the status ?
<pablo_> installing libesd...
<pablo_> :D
<pablo_> thanks xhaker :D
<xhaker> :D
<pablo_> it's rocking :D
<xhaker> see schweeb :D
<xhaker> pablo_, you just lost dmix
<pablo_> jeje
<pablo_> I love the new clearlooks human :D
<xhaker> but it doesn't hang anymore.. if i were to choose you know what i would pick
<xhaker> hmm
<schweeb> dmix is alsa specific... you can use dmix and esd on the same system
<Lathiat> does dmix work with the oss devices yet?
<pablo_> I hope that thepackager put into it the new clearlooks buttons :P
<xhaker> schweeb, he lost dmix on esd apps?
<pablo_> guys im gonna restart byee :D
<pablo_> thanks
<pablo_> :D
<xhaker> schweeb, any place i can see the status of polypaudio?
<schweeb> dunno
<schweeb> look in the changelog for the package
<schweeb> /usr/share/doc/<packagename>/changelog.gz
<schweeb> or, occasionally, it won't be gzipped
<xhaker> thanks
<Lathiat> changelog.Debian.gz can also be usefull
<jordi> Anyone from London here?
<jordi> I'm trying to find out how to reach those streets with Chinese games and losts of Asian restaurants
<pablo_> hi all :)
<pablo_> wow evolution crashes when you add an account and select the receiving server (pop, imap, etc.) =)
<pablo_> somebody have tried that?
<pablo_> :-)
<mdke> jordi, still lookin?
<pablo-> what about evo?
<pablo-> are you having crashing problems when you add and select a receiving type while adding an account?
<pablo-> :$
<mdke> pablo-, probably best to try bugzilla
<pablo-> mdke ok :) thanks
#ubuntu-devel 2005-07-08
<mxpxpod> seb128: did you get the bug I closed and then re-opened?
<seb128> yep
<mxpxpod> does my explanation sound reasonable?
<seb128> not really
<mxpxpod> ok
<mxpxpod> I'm not sure why, but a recompile of libwnck fixes my problems
<seb128> "the symbols in libwnck need to be updated with a recompile"
<seb128> what's that?
<seb128> the symboles are the the list of stuff declared by the lib
<seb128> that's not going to change on a rebuil
<mxpxpod> ok
<seb128> a rebuild doesn't change the ABI
<mxpxpod> maybe what the lib points to in other libs needs to be updated
<seb128> that would mean than a lib has changed its ABI
<seb128> wnck has not
<seb128> and I doubt that libc breaks the compatibility
<mxpxpod> could it be glib?
<seb128> no
<mxpxpod> man...
<seb128> all the GNOME libs have an ABI compatibility
<mxpxpod> this makes no freaking sense
<seb128> google about the error, just tried that and there is a bunch of responses
<mxpxpod> ok
<seb128> seems to be a toolchain issue
<mxpxpod> which means...
<seb128> build issue
<seb128> fPIC code
<mxpxpod> seb128: any clue how to fix it?
<seb128> nop
<mxpxpod> wonder if jbailey would know...
<seb128> could be a gcc or libc issue
<seb128> yep, he's probably the right guy to ask about this
<mxpxpod> and he just happens to be gone...
<mxpxpod> seb128: ok, could you try something for me really quick? could you add a workspace switcher to a panel and then open its preferences?
<seb128> and ... ?
<mxpxpod> do you get a warning message?
<seb128> no
<mxpxpod> suck
<seb128> what does it say?
<mxpxpod> Failed: Failed: Schema `/schemas/apps/workspace_switcher_applet/prefs/display_all_workspaces' specified for `/apps/panel/applets/applet_84/prefs/display_all_workspaces' stores a non-schema value
<mxpxpod> Failed: Failed: Schema `/schemas/apps/workspace_switcher_applet/prefs/num_rows' specified for `/apps/panel/applets/applet_84/prefs/num_rows' stores a non-schema value
<mxpxpod> now, here's something really strange
<mxpxpod> if I pkill the panel, the preferences work fine
<mxpxpod> it looks like the defaults aren't getting written correctly (not sure if that's just here or what)
<seb128> it's a GNOME dialog with this message?
<mxpxpod> I'll get you a SS
<mxpxpod> seb128: http://www.reigndropsfall.net/images/Screenshot-Error.png
<pablo_> mdke thanks, I added a comment to the bug https://bugzilla.ubuntu.com/show_bug.cgi?id=12188 :
<pablo_> :)
<seb128> mxpxpod: weird
<mxpxpod> seb128: yeah, very
<mxpxpod> check this out
<mdke> pablo_, good stuff :)
<mxpxpod> there's no display_all_workspaces key in gconf/gconf.xml.defaults/schemas/apps/workspace_switcher_applet/prefs doesn't exist
<mxpxpod> s/doesn't exist/
<mxpxpod> s/doesn't exist//
<mxpxpod> man, I can't type today
<pablo_> hmm when I'm trying to change the cursor, it's not changing :/ (/etc/alternatives/x-cursor-theme) at hoary it changes, at breeze it's not doing that :/ somebody with the same problem?
<xhaker> its broken
<pablo_> xhaker for me?
<xhaker> for everybody
<seb128> not for me
<pablo_> I mean if you have talked to me :)
<pablo_> seb128 you're cool =P
<mxpxpod> seb128: was that for me?
<pablo_> jajaja
<pablo_> :)
<xhaker> pablo_, it is broken in breezy
<xhaker> it happened in hoary devel times too
<seb128> mxpxpod: nop, for the cursors
<mxpxpod> seb128: ok, just making sure
<mxpxpod> seb128: ok, so for some reason the defaults aren't getting written right for these keys
<pablo_> xhaker Ok, I remember
<seb128> mxpxpod: do you have a /etc/gconf/gconf.xml.defaults/schemas/apps/workspace_switcher_applet/prefs/%gconf.xml ?
<mxpxpod> seb128: yes
<seb128> mxpxpod: can you put it somewhere?
<mxpxpod> seb128: yeah
<mxpxpod> seb128: ok, I was wrong... it is getting written
<mxpxpod> if I open up gconf-editor and go to that key, it tells me this:
<mxpxpod> Type mismatch: Expected `UNKNOWN, 5' got `Boolean' for key /schemas/apps/workspace_switcher_applet/prefs/display_all_workspaces
<seb128> your wnck seems to have issues
<mxpxpod> you're telling me
<seb128> is that with your rebuild of the package?
<mxpxpod> it's getting kind of old ;)
<mxpxpod> seb128: yeah
<xhaker> Akira Haraguchi, 59, managed to recite the number's first 83,431 decimal places, almost doubling the previous record held by another Japanese.
<mxpxpod> seb128: do you have _any_ idea what would be causing all of this chaos?
<xhaker> he memorised the PI
<seb128> mxpxpod: nop
<mxpxpod> argh
<seb128> mxpxpod: do you have the issue only with wnck?
<mxpxpod> yeah
<mxpxpod> all the other applets work fine
<seb128> I've uploaded a new version today
<seb128> maybe it's going to fix the issue
* mxpxpod crosses his fingers
<mxpxpod> seb128: what changed?
<seb128> wnck? not a lot
<seb128> but maybe a rebuild will fix your issue
<mxpxpod> :)
<mxpxpod> seb128: thanks for the help... hopefully this helps :)
<Burgundavia> seb128, did eog 2.11 fix --> https://bugzilla.ubuntu.com/show_bug.cgi?id=8742
<seb128> nop
<Burgundavia> ok
<seb128> you can probably bug that upstream
<wasabi_> We need 128bit uids
<lifeless> when does upstream version freeze occur ?
<Burgundavia> july 7th
<HiddenWolf> Heh, and hopefully, bugs will start dying in droves after that. :)
* xhaker is away (Away, bnc logging)
<mdke> i wanna see some hard core backports for july th
<mdke> 8th
<lsuactiafner> man, i was like , i wanna see some hard core
<lsuactiafner> and from there your sentance wasnt funny anymore
<mdke> ok i'll rephrase
<mdke> s/backports for july 8th/_
<pablo_> hi guys :) how can I determinate a default background color for nautilus? Thanks :)
<mdke> pablo_, you can ask questions in #ubuntu
<mdke> they will help!
<pablo_> mdke hihi thanks :)
<pablo_> mdke of, that was a simple gconf set on apps/nautilus :P
<mdke> pablo_, ok good. its also in the nautilus menu btw
<mdke> either is good
<pablo_> mdke yep, but it doesn't apply to all windows, so you open a folder and that windows older have the default :)
<mdke> it works for me
<pablo_> so on  gconf  I clicked background_set :)
<pablo_> in that way works for all windows :)
<mdke> the menu also works for all windows here
<mdke> maybe investigate and file a bug if it doesn't work on yours
<pablo_> 'cause is probably that you have on apps/nautilus/preferences/background_set on :)
<pablo_> 'clicked' :$
<mdke> nope
<pablo_> oops :/
<pablo_> mdke when I change the background with the 'Backgrounds and Em...' it only changes for that window :/
<pablo_> the only way for me is gconf :(
<mdke> the menu method should handle those gconf things for you
<pablo_> mdke I don't want to record a video with gvidcap ;)
<pablo_> so believe me :$
<pablo_> jeje :P
<mdke> i didn't suggest that I didn't believe you
<pablo_> well, now it works for that I want #525252 color :)
<pablo_> Build-dependencies for evolution could not be satisfied. =P
<pablo_> libgtkhtml3.8-dev: Depends: libgtkhtml3.8-15 (= 3.7.2-0ubuntu1) but 3.7.3-0ubuntu1 is to be installed :o
<lamont> coreutils and procps both deliver /usr/share/man/man1/kill.1.gz
<lamont> GAH
<jdub> lamont: guess you'll be wanting to kill that
* lamont grimaces.
<jdub> ;-)
* wasabi_ just got Heimdal + LDAP set up
* lamont is going to bed now... someone upload a fix pls.  kthxbye
<calc> anyone managed to get a laptop running amd64 arch to wake up from sleep?
<calc> mine now goes to sleep properly (it seems) with 2.6.12 but i can't the screen to come back
<calc> vbetool doesn't seem to work either saying it can't do a real mode interrupt
<calc> and its not even normally on the amd64 arch i extracted it since the scripts seemed to use it from i386 arch
<punkrockguy318> on hoary?
<punkrockguy318> or breezy?
<calc> breezy
<pablo_> breezy <
<daniels> vbetool can't do real mode stuff on amd64, regardless of which packages you install
<calc> daniels: yea i figured that after reading the error it gave me
<calc> so is there a way to bring back video on amd64?
<punkrockguy318> Where might I contribute my bugs and suggestions to the breezy colony 2? bugzilla?
<daniels> calc: right now, no
<pablo_> bugs bugzilla :)
<pablo_> suggestions I think mailing list
<punkrockguy318> alright, i posted my suggestions on the mailing list earlier today
<punkrockguy318> breezy is actually much more stable than i anticipated
<calc> daniels: ok
<calc> btw xlibs-data libx11-6 upgrade from hoary->breezy as of earlier today still is broken
<calc> i reinstalled ubuntu on my laptop to play with wpa and acpi and noticed that problem
<calc> purging both and installing them fixed it
<daniels> i know
<calc> ok
<daniels> i haven't been working for a while (did wednesday/thursday in one long stretch, swapped friday for today)
<daniels> i'll do my last upgrade tests when I get back from lunch
* pablo_ compiling evo from source 
* pablo_ compiling evo from source  :)
<pablo_> hopefully it works :/
<pablo_> wow! on nautilus is applied the patch for viewing as list as an xml style :D
<pablo_> cool
<pablo_> hihihi
<calc> the hoary live cd can come back from S3 but it doesn't set the keyboard back up apparently
<calc> i see the X login screen but can't type anything in or switch terminals, so it seems the keyboard is dead
<calc> this is on the same amd64 laptop, btw
<calc> er hoary i386 live cd (forgot to specify that)
<pablo_> libgtkhtml3.8-dev is broken guys now i'm compiling the source of that to get working evo :(
<pablo_> I wana evoo :'(
<crimsun> does #kubuntu also follow the same guidelines as #ubuntu regarding CoC?
<crimsun> (or should I be inquiring in #kubuntu-devel?)
<schweeb> crimsun: probably
<crimsun> (sometimes it's difficult to keep things on-topic)
<fabbione> hmm
<fabbione> what's wrong with:
<fabbione> next if (! /^foo/ ) || (! /^bar/ );
<fabbione> if i use only foo it's ok
<daniels> put parentheses around the whole thing?
<fabbione> if i add bar it filters a but too much
<fabbione> next if ((! /^foo/ ) || (! /^bar/ )); ?
<daniels> next if ((!/^foo/) || (!/^bar/));
<daniels> right, might be worth a go
<daniels> hold on, that will always trigger
<daniels> you can't have something that's ^foo *and* ^bar
<daniels> so that's the same as next if (1)
<fabbione> daniels: there is no such case
<fabbione> given a list of something
<daniels> well, think about it
<fabbione> the first word in the list indicates a category
<fabbione> that can be foo bar baz
<daniels> if you have three lines, foo, bar and baz
<daniels> !^/bar/ will trigger on foo
<fabbione> and i want to get only foo and bar
<daniels> !/^foo/ will trigger on bar
<fabbione> ah right
<daniels> and both will trigger on baz
<fabbione> needs to be &&
<daniels> that would probably be more useful
* fabbione needs more coffe
<fabbione> much better :)
<fabbione> hey mdz
<fabbione> hey JaneW 
<JaneW> hey fabbione 
<sivang> hey all
<mdz> fabbione: morning
<mjg59> mdz: Did you get my email?
<mdz> mjg59: I did, thanks
<mdz> mjg59: your list looks fine
<mdz> let's go ahead and start contacting folks
<mjg59> mdz: Cool
<mjg59> I'll sort the shortlist of hardware, then we just need to make sure we have agreement on what the agreement with people is
<mdz> mjg59: can you draft something for the terms and conditions in the wiki?
<mjg59> Yup, no problem
<mjg59> I'm moving house today and tomorrow, so this may end up being Tuesday
<mdz> mjg59: still in cambridge, or elsewhere?
<mjg59> Cambridge
<mjg59> Moving in with Daf
<mjg59> We can't get a phoneline for 3 weeks, so the internet situation may be... interesting
<ivoks> vedran: name sounds somewhat slavic...
<vedran> ivoks: yup :)
<vedran> whois vedran: blahblahblah.ba
<ivoks> vedran: pa sta ima u bosni? :)
<vedran> ma nista vala, ruzno vrijeme
<vedran> kisa pada, poplave itd.
<ivoks> ok, english on...
<vedran> np
<Kamion> mdz: hi, what was up yesterday?
<Kamion> lamont: fixing your coreutils thing now
<Kamion> lamont: it's #314713
<Kamion> lamont: (actually, not fixing right now, it's using dbs' dpkg-arch.mk - I'll see if/how I can get that changed first)
<dholbach> hi, could somebody trigger a rebuild of libxml-writer-perl? somehow ./usr/share/perl5/XML/Writer.pm wasn't contained. a rebuild in pbuilder fixed it.
<dholbach> shall i upload with build1 suffix?
<pitti> Nice Sunday everybody!
<dholbach> leaving again?
<dholbach> have a nice sunday too, pitti :)
<pitti> dholbach: well, in ~ 45 minutes
<pitti> just some email reading
<dholbach> how's the weather at your place? going out today?
<\sh> *rearrangesomewikipagesnow
<pitti> dholbach: it's just great, gf+me will take our bikes and go to my parent's garden (celebrating my mother's birthday)
<dholbach> oh nice
<dholbach> garden party with grilling outside? :)
<pitti> yep :-)
<dholbach> EXCELLENT
<dholbach> much better than exam revision :)
<dholbach> i won't spoil your sunday - have fun! :)
<daniels> dholbach: yo dude
<dholbach> hey daniels, how's it going?
<\sh> dholbach: one beer in the evening will do it, to make your day ;)
<pitti> daniels: you have to revise other student's exams?
<dholbach> pitti: erm, i have to review my stuff to be prepared on friday (last exam) :)
<pitti> dholbach: oh, I see *crossing fingers*
<dholbach> pitti: thanks :)
<ajmitch> dholbach: good luck :)
<dholbach> \sh: yeah, i'm going to watch the oscar wilde movie tonight - i wanted to see it for ages
<daniels> dholbach: not too bad, thanks
<daniels> pitti: ...
<dholbach> ivoks: hey ante!
<ivoks> dholbach: hi!
<ivoks> i'm having some problems with eclipse :(
<\sh> dholbach: actually I wanted to go to the parade today, but my head is paining too much today, just because yesterday we had a nice day ,-)
<dholbach> ivoks: i tried to install it, but it didn't work yet - you might want to ask wasabi_ - he's the java/eclipse/... expert :)
<ivoks> hi \sh 
<ivoks> heh, guess he isn't here
<ivoks> dholbach: for me it doesn't even start :(
<dholbach> \sh: go for a *slow* walk then, have some water :)
<ivoks> \sh: so, what were you doing yesterday? :>
<doko> ivoks: install eclipse-sdk as a workaround
<ivoks> hm... thanks doko 
<dholbach> hey doko
<dholbach> doko: how's it going?
<\sh> ivoks: bought a washing machine :) and had some drinks at the cologne pride, made some nice contacts there, and had a very interessting outing ;)
<ivoks> oh, what's cologne pride?
<dholbach> sounds like a "headache next day" :)
<ivoks> :))
<\sh> ivoks: it's a gay and lesbian party, just before the CSD parade today. CSD== Christopher Street Day, a happening where gays/lesbians/bisexual people are celebrating a party and demonstrating for their legal rights in the community
<ivoks> ah, it's called gay pride in zagreb :)
<\sh> was quite nice, i went there with two colleagues, he is muslim, and she likes girls :) and she knew about my situation, and he wasn't quite sure what to think and how to handle it but now he understands and is respects our way of life :) 
<mdke> fabbione, around?
<ivoks> \sh: well, everybody lives in the way he/she chooses
<ivoks> at least, it should be that way
<JanC> IIRC there is an event/parade like that called "Roze Zaterdag" ("Pink Saturday") in Belgium  ;-)
<mdke> 12344
<mdke> whoops sorry wrong paste
<\sh> JanC: looks like the same event ;-)
<lool> (Gay Pride in Paris too)
<daniels> mardi gras in australia
<JanC> it has a new name now, it seems: http://www.blgp.be/en/
<\sh> #ubuntu-gblp ,-)
<lool> daniels: mouahaha
<\sh> what's the email address of chmj
<dholbach> Charles Majola <charles at ubuntu.com>
<\sh> thx
<pitti> sjoerd: just uploading pmount 0.9.2-1 to experimental :-)
<sjoerd> pitti: \o/
<sjoerd> pitti: still haven't got a reaction from the cryptsetup maintainer :(
<pitti> me neither
<pitti> ok, have a nice Sunday
<dholbach> \sh: FinishedUniverseLibraries is a complete list?
<\sh> dholbach: not now...I just figuring out what is finished and what not
<\sh> takes some time
<dholbach> ok
<dholbach> hey seb128 :)
<seb128> hi dholbach 
<fabbione> mdke: now... but not for long time
<seb128> elmo: glib2.0 (exp) sync please
<fabbione> seb128: you are supposed to be watching F1 :)
<fabbione> seb128; they are running in france today ;)
<seb128> fabbione: yeah, I'm watching the TV while working :p
<dholbach> fabbione: F1 needs no concentration at all - you can hack/whatever while watching it
<fabbione> seb128: eheheh
* dholbach 'd get a headache :)
<fabbione> dholbach: i prefer to relax and watch F1 :)
<fabbione> IRC and www.formula1.com are the 2 only things around at this time
<dholbach> fabbione: F1 and relaxing just don't fit together... at least not for me :)
<fabbione> dholbach: probably because you are a decade younger than me .. and didn't watch much of Senna/Prost/Mansel fights
<fabbione> this F1 is boring compared
<HiddenWolf> it is
<HiddenWolf> and you should all be spanked for being OT ;)
<mdke> fabbione, i just wanted to clarify a bit #12344 which I reopened just now, if you're happy, then no need, otherwise, I can try and clarify
<fabbione> a second... i don't have buzilla handy here
<dholbach> fabbione: once i'm not chained to the computer anymore, i'll be happy to let you try to explain the fascination to me :)
<fabbione> dholbach: eheh
<mdke> i prefer motogp to f1 i have to say
<fabbione> mdke: the RADIO16.BIN that you have on warty2hoary partition is the same as the one in the brand new hoary installation?
<fabbione> check the md5sum of them
<fabbione> if they are not the same i would suggest you get the file from the other partition
<fabbione> that's all i can suggest
<fabbione> the driver in the kernel is the same
<mdke> fabbione, sure. But the main part of the bug is the fact that the firmware is not shipped with Ubuntu
<fabbione> mdke: dude.. you open a bug with a firware that doesn't load...
<fabbione> now it's turning in the firmware is missing..
<fabbione> it's one bug per problem
<fabbione> not 2 problems in one bug...
<mdke> ok
<fabbione> in any case the firmware won't be added to hoary
<mdke> ignore the comment then, the report shows clearly that the firmware is missing
<fabbione> ok
<fabbione> mdke: please reassign the bug to linux-restricted-modules-2.6.10
<mdke> fabbione, sure ok
<fabbione> thanks
<mdke> fabbione, is it normal that linux-restricted-modules was installed automatically by the installer?
<Kamion> yes
<mdke> k cool
<Kamion> normal and intentional
<mdke> yes I appreciated it
<mdke> :)
<fabbione> hey Kamion 
* lamont drives by, thanks Kamion, leaves for a few hours.
<fabbione> hey lamont 
<fabbione> lamont: the gnome-alsamixer mismatch seems to be caused by the pkg being moved to universe... but wanna-build doesn't realise that
<lamont> fabbione: because it's UNKNOWN == main.  iz override file fix that elmo needs to do.
<dholbach> hey lamont: do we have to bug you in some weeks for a BIG TEST REBUILD? :)
<fabbione> lamont: right
<xhaker> hmmm, how come the new gnome-icon-theme has the real firefox logo?
<HiddenWolf> xhaker, guess they cleared that with the moz foundation
<fabbione> dholbach: afaik they are working on it... it's going to be fun to fix 39483943 FTBFS 
<fabbione> dholbach: and there are pleny
<fabbione> plenty even
<fabbione> between gcc-4.0 and X split
<dholbach> fabbione: yeah... but that'll be 5-6 weeks before release, right?
<fabbione> dholbach: i truely hope a bit before that
<fabbione> and that it will run constantly on all the archive
<dholbach> it should be (some time) after mergingShouldBeCompleteFreeze
<dholbach> fabbione: then i'll do everything i can to help out (when i finished thesis/exam/move)
<fabbione> dholbach: i have seen a huge bunch of FTBFS in universe due to X split
<\sh> grmpf...somethings goes terrible wrong with quantlib...too much of love 
<dholbach> yeah
<fabbione> it's not difficult to fix.. just extremely boring
<dholbach> that'll be fun
<dholbach> yeah, we'll manage
<fabbione> yeah
<dholbach> the last weeks before the release will be the "MOTU weeks" :)
<\sh> dholbach: enlish work for "fleissarbeit"? ,-)
<dholbach> \sh: yeah, lots of motu hopefuls can prove themselves
<\sh> yepp
<\sh> no wonder why quantlib is not building properly....DH_VERBOSE=1 should always be enabled
<fabbione> jamesh: eh?
<fabbione> not at all
<fabbione> DH_VERBOSE is optional
<fabbione> \sh ^
<\sh> yeah, but helped me 
<fabbione> it does help to track down possible errors
<fabbione> not to build the package itself
<\sh> fabbione: yeah...but without it now, i didn't see the compile errors :(
<\sh> now i have them :(
<\sh> and for gods sake there is a patch in b.d.o
<\sh> so i don't have to work on this ;)
<dholbach> hey ogra 
<\sh> www.the-tower.co.uk -> search for prisoners: ogra ,-)
<ogra> hehe
<ogra> still locked in the hotel ;)
* \sh is reading "Deutsch Frau, Frau deutsch" 
<\sh> and no..this  isnot nice...they're playing the german national anthem in kerpen sindorf 
<ezequiel> hi ppl
<ezequiel> isn't there any qt4 build for ubuntu?
<\sh> no not right now
<dholbach> hi ezequiel, this is more a  #ubuntu -question, but packages.ubuntu.com should be able to tell you
<ezequiel> yup, but not a #ubuntu answer ;)
<loo> 1/j #ubuntu
<ezequiel> sorry, I asked @ #kubuntu
<\sh> ezequiel: lets say it like this: qt4 is not important right now, without kde4 in our eyes...and lets wait for some more bugfix releases...
<ezequiel> \sh: well, it does matter to me, 'cause I was just to begin developming a qt application and I don't want to port it later
<ezequiel> \sh: btw, have you read about the plasma
<ezequiel> ?
<Kamion> \sh: DH_VERBOSE=1 should generally be set by the person building the package in the environment, not hardcoded in debian/rules
<\sh> Kamion: yeah..but this stupid package didn't show me any build errors, it just went on to installing ...:(
<wm_eddie> ezequiel: I think it'd be easier to write it in Qt3 now and port it to Qt4 later.
<ezequiel> wm_eddie: I hate porting, I'm too slow
<ezequiel> wm_eddie: even if I does not know the differences yet
<wm_eddie> well, looks like you are going to have to get qt4 from trolltech and install it yourself.
<ezequiel> I just got some debian packages
<\sh> ezequiel: yes I read aarons announcement
<wm_eddie> that works.
<wm_eddie> hopefully that wont break anything.
<ezequiel> I'm gonna fill the deps with breezy and prays
<ezequiel> the past week a friend asked me if he could install windows in his mac...
<ezequiel> that would be a problem...
<wm_eddie> ezequiel: Virtual PC.
<wm_eddie> unless he meant as the main OS.
<ezequiel> as main os he asked, he has no idea about virtualpc or whatever
<wm_eddie> He can install Ubuntu :)
<ezequiel> yup, I gave him a hoary cd
<ezequiel> hope he wants to test it
<dholbach> bye guys, see you later
<davyd> daniels: has that X.org upload happened yet?
<tseng> davyd: no
<davyd> ooher, whatever update I got the other day now gives me an iPod logo
<tseng> indeed
<davyd> rocking
<davyd> although, it has decided to mount the media somewhere new
<davyd> is there a non-shit iPod application that will find out where my iPod is for me?
<tseng> hey the last applets seb uploaded it says i can change governer in battstat
<davyd> tseng: if you've built that part
<tseng> davyd: snorp is working on that
<tseng> and abock, lewing
<davyd> excellent
<davyd> gtkpod is... average
<tseng> also, the next g-v-m has an ipod target
<davyd> and I wasn't feeling like attempting it myself
<tseng> davyd: the muine plugin rocks
<tseng> davyd: just now that it uses hal.. it doesnt work on breezy yet :)
<davyd> tseng: I haven't tried that
<davyd> tseng: oh, because of new HAL?
<tseng> ya
<tseng> they are working on that also
<tseng> i dont see why we wont have it by breezy release
<davyd> new HAL was ok to port to
<davyd> once I got new documentation
<tseng> yeah but they are all NLD/SuSE lamers
<davyd> I started porting gnome-netstatus to HAL
<davyd> unfortunately, this job has eaten up a lot of my holiday time
<davyd> I see it also sends an eject to the iPod to make it 'tick' ok
<davyd> and doesn't send HAL into the D-state
<lsuactiafner> shouldnt gcc for ubuntu be able to do ./configure --target=athlon_xp --cc="gcc -m32" --as="as --32" --with-extralibdir=/usr/lib32/ ?
<lsuactiafner> mplayer source
<tseng> davyd: last i tried that the eject failed
<davyd> tseng: hmm, my breezy is a little out of date on this machine
<mdke> I'm just upgrading to hoary, linux-restricted-modules-386 and ubuntu-desktop are kept back from a dist-upgrade, is this intentional?
<mdke> gah
<mdke> s/hoary/breezy
<Kamion> there's no l-r-m for 2.6.12 yet
<mdke> cool thanks Kamion 
<Kamion> ubuntu-desktop is odd, http://people.ubuntu.com/~cjwatson/testing/breezy_probs.html doesn't show it as uninstallable
<Kamion> but it may just be confused by the X modularisation; last time I did a hoary->breezy upgrade I had to help it out a fair bit
<mdke> yeah right now it is having some xlibs-data conflict issues
<davyd> the biggest thing about distro hacking, seems to be the number of times you are doing upgrades and other stuff
<davyd> it seems to incredibly painful
<davyd> anyway, time to sleep
<mdke> so I'm gonna wait til that if fixed before finishing the upgrade
<mdke> if/is
<mdke> i figured I could do a nice clean hoary install, then upgrade to see if I could find any new bugs
<davyd> mdke: my laptop is booting currently
<davyd> so it seems good
<davyd> beagle seems broken
<Kamion> there's a bug filed about xlibs-data
* xhaker is away (Away, bnc logging)
<mdke> Kamion, yeah i saw it
<davyd> anyway, sleep
<Kamion> you have to dpkg --force-overwrite -i either it or libx11-6 (can't remember which) for the moment
<mdke> Kamion, its marked pendingupgrade so I figured it was better to wait rather than do some force-conflicts stuff
<wasabi_> Morning
<Kamion> --force-overwrite is safe in this context
<mdke> Kamion, is there a difference between that and --force-conflicts?
<mdke> Kamion, ok i did it and it worked, thanks
<Kamion> mdke: er, yes!
<Kamion>   overwrite              Overwrite a file from one package with another
<Kamion>   conflicts [!]           Allow installation of conflicting packages
<Kamion> (dpkg --force-help)
<Kamion> WARNING - use of options marked [!]  can seriously damage your installation.
<mdke> oops
<mdke> i did the [!]  one :p
<Kamion> --force-conflicts is for packages tagged with the Conflicts header
<mdke> oh well, that was in the bug report
<Kamion> which is different from what are often confusingly called "file conflicts"
<mdke> ok so am i likely to have seriously damaged my installation?
<mdke> having done --force-conflicts -i libx11-6
<mdke> if that is dangerous it might be worth noting in the bug report that the workaround posted is wrong
<Kamion> no, I imagine not
<Kamion> which bug is it? I'll correct it
<mdke> Kamion, #12108, thanks
<Kamion> corrected
<mdke> Kamion, merci. Is there any need for me to undo what I did with the --force-conflicts?
<daniels> not really
<daniels> it's going to be fixed as soon as I test this fb patch
<mdke> daniels, as long as I haven't done my system any harm :)
<\sh> hmmm
<\sh> is it ok to source upload the package described in: https://bugzilla.ubuntu.com/show_bug.cgi?id=11456
<Kamion> mdke: n
<Kamion> no
<mdke> great, thanks for your help!
<eruin> thom, have you abandoned http://people.ubuntu.com/~thom/network-manager/ now that its in breezy main?
<mdke> ok the rest of the hoary->breezy seems to have gone really well
<mdke> except for some reason each kernel in the grub menu has two entries
<hubH> eruin: breezy
<lsuactiafner> tseng 
<lsuactiafner> this software patents vote, why aint the whole of freenode organising things to fight it?
<tseng> lsuactiafner: freenode is too busy soliciting donations and killing hub nodes
<tseng> lsuactiafner: heh sorry.. did you ping me for something?
* Lathiat grins at tseng 
<tseng> dont do that, im a bad example
<Lathiat> heh
<Nafallo> maswan: yea, works again :-).
<trulux> anyone preparing the marbles for the LSM 2005?
<\sh> hmm...evolution with imap is crashing *cry*
<\sh> hmmm...
<wasabi_> Hmm. Could the X move have messed up vncserver?
<wasabi_> Yup, it did.
<Burgundavia> fabbione, http://www.ubuntuforums.org/showthread.php?t=46031
<\sh> does anybody run evolution on breezy with an imap account?
<wasabi_> I do.
<\sh> did u have any crashes when u created an imap account? 
<wasabi_> no
<wasabi_> the imap account has been created for many upgrades though
<\sh> can u try to create an imap account right now? cause when I tried it many of times now, evolution crashed all the time when I choose imap4 or imap4rev2
<wasabi_> Yup, it does.
<seb128> it crash on the account selection?
<seb128> nothing specific to imap
<\sh> i only tried with imap4
<\sh> let me try pop3 or something else
<wasabi_> yeah, crashes on everything.
<\sh> ah and it crashed when I tried to edit an account ... I choosed "nothin" now 
<\sh> hmmm...gnome is at least completly broken in the moment ;)
<seb128> what's broken with GNOME?
<seb128> for the account bug, downgrading to the hoary libglib2.0-0 fix the issue according to upstream comments
<\sh> no...try to install straw
<\sh> python-gnome2-extras doesn't want to install
<\sh> gdesklets
<\sh> hmmm...w8
<\sh> I had my fingers on straw
<\sh> strange
<\sh> if i install libgda2-3 by hand, then it worked installing straw *reallystrange*
<Lathiat> that often happens when say
<Lathiat> libgsa2-3 provides: something
<Lathiat> straw depends: somethingt
<pablo> are you working to fix evo? I've not seen activity on that bug, evo now it's not usable, you can't read email, and the bug is unconfirmed yet :)
<pablo> https://bugzilla.ubuntu.com/show_bug.cgi?id=12188 oh I see seb128's bug
<pablo> =)
<seb128> no my bug
<seb128> I don't have a window box
<highvoltage> seb128++
<pablo> seb128 I had the same problem with the same version of evo when I build a garnome snapshot
<seb128> evo-exchange bug?
<pablo> *built
<pablo> seb128 obvios ;)
<seb128> you should probably go upstream with the bug
<pablo> hahah seb128 it's assigned for you :)
<pablo> yhmmmm
<pablo> uhmm
<seb128> I don't know who has a exchange setup to work on this bug
<pablo> Jeff Bailey
<pablo> sorry seb128 :)
<seb128> np
<seb128> anyway, I'm away now, bbl
<pablo> :)
<\sh> but eclipse is running 
<pablo> for all those want to try evo there's a new version http://ftp.gnome.org/pub/GNOME/sources/evolution/2.3/evolution-2.3.4.tar.gz
<pablo> without the bug I hope :/ so try it =)
<ivoks> which bug?
<pablo> ivoks, https://bugzilla.ubuntu.com/show_bug.cgi?id=12188
<pablo> that's a genereal bug, 'cause I got it con garnome too, with the same evo version
<pablo> general* con=with
<pablo> ;)
<pablo> sorry brb
<ivoks> thanks
<wasabi_> doko, what do you think about integrating a update-gcj-classmaps script into gij?
<wasabi_> It doesn't belong in Eclipse, and it doesn't belong in j-g-c
<wasabi_> It belongs with gcj-dbtool.
<daniels> gar debconf
<wasabi_> Ooops
<wasabi_> Somehow I had meant to put all that in anothe rchannel too.
<herzi> seb128_: ping
<wasabi_> When ya'll submit Ubuntu patches to Debian, do you tailor them up to remove the changelog entries for ubuntu?
<daniels> it seems to be good form
<wasabi_> We should get ongoing merge to do something like that. Combine all our entries into one. ;)
<seb128> herzi: pong
<herzi> seb128: can you tell me why gnome-cc didn't find xcursor-dev while building though it's in build-depends?
<siretart> does anyone know about issues with gnomemeeting in hoary against gnomemeeting in sarge?
<herzi> s/can you tell/do you know/
<siretart> s/sarge/unstable/
<siretart> I just tried a testcall, but the version from debian keeps crashing
<seb128> herzi: maybe the current xorg's changelog?
<seb128> herzi: pkg-config files moved to fix ftbfses
<pablo> wtf http://www.renewnyc.com/images_WMS/freedom_tower/model_view_southwest_8x10-5_RGB-wmark.jpg
<pablo> that's so pretty
<pablo> the new building on wordl trace center <-
<mitsuhiko> pablo: don't like it
<Treenaks> world trace center?
<mitsuhiko> yes
<pablo> Treenaks does sound you september 11?
<pablo> :)
<Treenaks> pablo: that was the World Trade Center
<Treenaks> pablo: the World Trace Center sounds like CIA HQ or something
<mitsuhiko> Treenaks: ^^
<pablo> http://www.renewnyc.com/News/mediaresources.asp more photos
<pablo> somebody knows why appear that wanings? libtool: link: warning: `/usr/lib/gcc/i486-linux-gnu/4.0.1/../../..//libglib-2.0.la' seems to be moved
<pablo> thanks :)
<wasabi_> haha im a retard
<lamont> dholbach: setting up breezy-autotest is an in-progress project
<Burgundavia> should the new gnome-panel have the ff official logo?
<pablo> how can I adjust the bonobo path setting? I want to build evo myself :/
<pablo> /usr/lib/bonobo-activation/bonobo-activation-server
<pablo> thanks
<mdke> Burgundavia, yes apparently so
<mdke> the gnome icon set has the ff logo now
<Burgundavia> hmm
<pablo> please
<pablo> the evo packager! :(
<pablo> 2.3.4 version, to use it :(
* pablo is crying 'cause he can't get working evo en breezy
#ubuntu-devel 2005-07-09
<pablo> andy@nat-pool-brisbane.redhat.com cool :P
<pablo> jaja
<tseng> pablo: he used ubuntu first
<tseng> pablo: gotta pay the bills somehow.
<pablo> tseng: jajajaj
<pablo> :P
* pablo is packaging evo 2.3.4 =P
<pablo> who's the ubuntu evo maintainer?
<crimsun> seb has done a lot of work with it
<pablo> ok crimsun :)
<daniels> pablo: be patient -- it's 0141 on a sunday night in seb's timezone
<pablo> daniels heheh ;) ok :P
<mdke> pablo, evolution should be in breezy already
<pablo> mdke 2.3.4?
<pablo> uhm
<pablo> mdke: my problem with the version of breezy is this: https://bugzilla.ubuntu.com/show_bug.cgi?id=12188
<mdke> pablo, the latest version of evolution is inserted into breezy periodically until version freeze. Bugs will get fixed in time
<mdke> yeah i've seen that bug
<pablo> oh ok mdke :)
<pablo> that's an horrible bug ;)
<pablo> jejeje
<mdke> pablo, breezy will have lots of bugs, it is the version for testing. If you want a distro without bugs, you should really use hoary hedgehod
<mdke> d/g
<pablo> yep, I know that.
* pablo away
<camilotelles> mdz: hi there
<mdz> camilotelles: hello and goodbye; I'm going to sleep ;-)
<camilotelles> mdz: see you tomorrow, goodbye
<camilotelles> and good night
<tseng> daniels: omfg you suck
<tseng> daniels: X not executable
<daniels> i didn't change anything
<daniels> -33 or -34?
<tseng> 34
<tseng> the /etc/X11/X symlink is broken
<tseng>  /usr/bin/X11 is gone
<daniels> please dump a full ls -l of everything X-related in the chain at me in /msg
<tseng> ill need to put it back where it was
<daniels> OH, I see
<tseng> and install gpm
<daniels> right, needs new x-common
<borkdox> hi
<tseng> the link is fixed is all
<borkdox> anyone knows the deal with openoffice on amd64 udner breezy? are ia32-libs broken right now?
<tseng> *needs
<borkdox> http://www.ubuntuforums.org/showthread.php?p=239584#post239584
<borkdox> i posted that in the quest of finding out whats the deal...
<daniels> tseng: new x-common uploaded, which makes /usr/bin/X11 a symlink to /usr/bin
<tseng> daniels: rock on dude, thanks
<daniels> np
<daniels> i had it prepared, just forgot to upload
<lamont> daniels: xfixes was tomorrow?
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<fabbione> morning
* seth_k is away: food
* seth_k is back.
<karthik085> Hello, My name is Karthik. I would like to actively contribute to Kubuntu and KDE. What is the process I need to go to become one of the maintainers?
<fabbione> hi karthik085 
<fabbione> a good place to start is #ubuntu-motu and #kubuntu-devel
<fabbione> karthik085: the first step to become a maintainer is to become a "MOTU"
<fabbione> (very short version of the story)
<karthik085> Hey fabbione. I applied to become a MOTU.
<fabbione> ok did you read all the documentation on how to become one?
<karthik085> Yup.
<fabbione> because you need to show up during TB/CC meetings and prove yourself as a valid MOTU before you can be one
<fabbione> i think the best is to ask in -motu how to do so
<karthik085> I will be attending the one on Tuesday
<fabbione> i personally don't recall all the details and i don't want to put you in the wrong direction
<karthik085> Do you know what skills one need to become a maintainer?
<fabbione> it depends what your skills are
<fabbione> there is always something to do :)
<karthik085> :-)
<karthik085> I am good at programming, especially C++ and Java. Currently, I am learning Ruby. I also designed/developed various projects for my university. Recently, a paper based on my program got accpted in a conference.
<fabbione> karthik085: sounds good.. i think you need to find yourself a place where to apply these skills...
<fabbione> we don't exactly force people to do something they don't want to :)
<fabbione> and talking with the MOTU's is the best you can do imho
<karthik085> Ok.. I will talk to MOTU's. Thanks.
<fabbione> welcome :)
<pitti> Good morning
<jsgotangco> hi
<fabbione> hey pitti
<pitti> infinity: ping
<infinity> pitti : pong
<fabbione> hey infinity 
<infinity> Yo Fabio.
<fabbione> infinity: what's up?
<infinity> Working to get a bunch of upstream version bumps ready in the next 2 days, since I just went back and re-read the release schedule and checked the calendar. :)
<fabbione> ehehe
<\sh> question: the upstreamfreeze is only for main, or is it also for universe? 
<infinity> Also, wishing customs would release my laptop and send it to me.
<pitti> elmo: 
<pitti> elmo: please sync pmount from Debian experimental
<infinity> \sh : Just main.  Universe gets some slack cut, since we don't officially support it anyway.
<\sh> wonderful :)
<jdub> \sh: syncing stops, but uploading has been fine thus far (without approval)
<pitti> \sh: right, that's entirely MOTU driven; if they accept a new upstream release 2 days before release, that's fine
<Amaranth> hehe
<infinity> FOr some value of "fine"... A little common sense would be nice.
<pitti> of course
<Amaranth> since universe doesn't ship on a CD i don't see why it should freeze at all
<\sh> Amaranth, we need to get some apps stable in the end...and sometimes it's better to have an older stable version, then an unstable new version ,-)
<fabbione> WOW.. i think i never managed to hang d-i so badly.. getting the screen to switch to another tty :)
<crimsun> I think we've hashed this one before and reached a consensus that a stable release really needs to be stable, even for universe.
<womble> fabbione: I saw a similar problem with a Hoary pre-release
<fabbione> womble: nah.. i am messing with it :)
<womble> Oh, OK.  Might want to get that one fixed before release... <grin>
<fabbione> womble: no.. really? :)
<ajmitch> Amaranth: and that it's trickier to accept uploads to universe while leaving main frozen
<\sh> but actually I would really like to have some comments on this showstopper...should we put this app into universe as a replacement of the old package, or should we w8 for debian and kick the old one out of the repos?
<\sh> https://bugzilla.ubuntu.com/show_bug.cgi?id=11456
<womble> Ever seen Dumb and Dumber?  I'm thinking the "IOU 1 ferrari" scene here
<\sh> (actually it's not only an app)
<infinity> \sh : Does anything {build-,}depend on it?
<\sh> infinity, only the packages generated directly from the source 
<infinity> \sh : And do your packages seem to build and work fine?
<\sh> infinity, i tried the last official "stable release" of gnuradio-core (replacement for old gnuradio-0.9) and it didn't compile with gnu c/c++ 3.4 or 4.x
<infinity> \sh : If so, I see no issues.  Just version your package with -0ubuntu1, so a Debian -1 will be higher, and see about working with the Debian maintainer to converge the packaging/sources at some point in the future.
<\sh> the latest cvs head is compiling and the debian maintainer was really surprised as well to see it's compiling..(i only test it for i386)
<infinity> \sh : Debian will be doing the gcc4 transition very (VERY) soon, so the Debian packages will need updating ASAP anyway.
<\sh> infinity, yeah read the announcement of doko on d-d
<Amaranth> is the kernel going to get built with gcc 4?
<infinity> Amaranth : Not for breezy.
<\sh> well, new xorg and some new eclipse stuff nice
<Amaranth> ok, can we at least get the same version of gcc 3.4 that the kernel was actually built with? :)
<dholbach> morning
<pitti> Hey dholbach 
<\sh> E: /var/cache/apt/archives/libx11-6_1-0x1,ba1a10000005bp-1336.2.1+cvs.20050615-4_i386.deb:  versuche /usr/lib/X11/XErrorDB zu berschreiben, welches auch in Paket xlibs-data ist
<jsgotangco> dholbach, morning!
<\sh> uhh
<dholbach> what were those magic symlinks i had to place to get x working again?
<dholbach> morning jerome
<dholbach> morning martin
<crimsun> new x-common should fix that
<Lathiat> daniels: bah you broke X again ;p
<jsgotangco> you have to offer some virgins though first
<dholbach> poor daniels :/
<\sh> Lathiat, force it force it ;) xorg is more maso then anything else ,-)
<Lathiat> daniels: /usr/bin/X11 has only a symlink of bin to /usr/bin
<crimsun> I thought he fixed that in the last upload
<Lathiat> yeh and broke it in this one :)
<infinity> daniels didn't do the last upload.
<Amaranth> crimsun did? :)
<Lathiat> he did according to my changelog
<infinity> Err, yes he did.  I'm blind. :)
<\sh> good morning chmj 
<pitti> Hi chmj
<chmj> good morning all 
<pitti> brb
<dholbach> where should /usr/bin/X11 point to?
<infinity> Lathiat : The symlink from x-common looks correct to me.
<infinity> dholbach : ../bin, just as it does.
<dholbach> hrm
<dholbach> i'll take a leaf out of keybuk's book and strace it =)
<dholbach> and prepare some coffee in the meantime
<Lathiat> well, i have /usr/bin/X11/bin pointing at /usr/bin
<Lathiat> is that right?
<Lathiat> judging by the look of things, /usr/bin/X11 shoudl be -> /usr/bin, to /usr/bin/X11/bin
<torkel> 'ln -sf /usr/bin/Xorg /etc/X11/X' made it work for me
<Lathiat> i did get an error when upgrading, after using apt-get -f install to get libx11-6 everythign finished up fine
<Lathiat> torkel: yeh thats hacky tho, ki think /usr/bin/X11 is just wrong
<infinity> root@lucifer:~ # ls -l /usr/bin/X11
<infinity> lrwxrwxrwx  1 root root 6 Jul  4 06:59 /usr/bin/X11 -> ../bin
<Lathiat> not that i have any idea why theres a /usr/bin/X11 in the first place
<Lathiat> infinity: right, see thats not what i have
<Lathiat> hm
<infinity> Lathiat : Do you have the latest x-common and other X friends?
<dholbach> torkel: thank you
<torkel> Lathiat: right now I'm more intrested in getting it working :-)
<Lathiat> well i should do
<Lathiat> everythings up to date and ubuntu-desktop is installed so unless something isnt included somewhere
<dholbach> brb
<Lathiat> x-common is 1.01
* infinity looks at the x-common source.
<dholbach> RE :)
<infinity> Lathiat : Does "apt-get --reinstall install x-common" magically fix it?
<infinity> Lathiat : Oh, wait.  DO you have a DIRECTORY called /usr/bin/X11 with a symlink in it that's "bin -> /usr/bin"?
<Lathiat> infinity: yes
<infinity> Hrmph.  Kay, I can see why.
<infinity> If you delete that symlink then reinstall x-common, you'll get fixed up.
<infinity> (you don't have any other files in that directory, do you?)
<Amaranth> oh, i remember that problem
<infinity> The real bug needs to be fixed, though.
<Amaranth> hacks to fix old X problems cause new X problems!
<infinity> Not tough.  WOuld have been less hackish if it was done right the first time, though.
* infinity thinks it's high time to write a "migrating directories to symlinks and vice versa" mini-HOWTO or something.
<infinity> It seems that every time someone reinvents this wheel, they break it in new and interesting ways.
<dholbach> infinity: you're so positive about things... i like that :)
<infinity> Oh, there's clearly a silver lining here.
<infinity> Mainly being that every time this wheel IS reinvented, I see it done in completely different broken ways!
<infinity> (I broke it about 4 different ways myself just a few months ago(
<dholbach> but you can at least find them interesting :)
<infinity> s/\($/\)/
<dholbach> mvo: good morning, michael!
<pitti> Hey mvo
<mvo> good morning to dholbach, pitti and to others!
<\sh> chmj, did u receive my mail?
<dholbach> see you later guys
<fabbione> Kamion: ping?
<chmj> \sh, not yet 
<fabbione> Kamion: do i remember right that ppc is the only arch that doesn't have lvm support in parman?
<\sh> chmj, charles@ubuntu.com, right?
<chmj> yes got it 
<\sh> chmj, good :)
<doko> elmo: please sync java-gcj-compat and python-imaging from unstable
<fabbione> sabdfl mornign 
<Kamion> fabbione: it's not partman, it's parted
<Kamion> fabbione: but yeah, only one of our supported arches anyway
<fabbione> Kamion: yes.. sorry... i still get confused by the names
<fabbione> Kamion: do you know about sparc/ia64/hppa?
<Kamion> not offhand - but I would imagine they do, the only reason powerpc (actually just powerpc with Mac partition tables) doesn't is that there isn't a standard for recording it in the partition table, and the pseudo-standard we agreed hasn't been implemented in parted yet
<Kamion> powerpc with IBM partition tables (e.g. RS/6000s) should be able to manage LVM just fine
<Kamion> likewise RAID
<fabbione> Kamion: ok...
<fabbione> right now i am at a good point in parsing the recipe's and take some proper actions to create separate /boot and the LVM envelope
<fabbione> i am fighting a bit with creating partitions with open_dialog...
<Kamion> bah, still no working syncage of svn->baz imports
<Kamion> and as infinity observes we have upstream version freeze in two days, at least if my recollection of breezy release on 12th October is correct
<Kamion> if it's 19th October we have another week
<infinity> Kamion : Well, the wiki told me it was in 2 days.  Maybe it lied to me.
<infinity> Kamion : I can always hope.
<Kamion> which page?
<infinity> http://udu.wiki.ubuntu.com/BreezyReleaseSchedule
<Kamion> oh, I was looking at the wrong wiki, as usual
<Kamion> yeah
<pitti> Hey mdz 
<mdz> pitti: morning
<sabdfl> morning fabbione, all!
<pitti> Hi sabdfl 
<fabbione> morning mdz
<pitti> mdz: still remember the sound card hotplug discussion?
<mdz> pitti: whether to change the default when a new sound device is hotplugged?
<mdz> fabbione: morning
<pitti> mdz: I have a patch for g-v-m ready for some weeks
<pitti> mdz: I just didn't upload it because it is incredibly hard to tell the audio mixer to display a certain card by default
<pitti> mdz: but that's entirely unrelated to the question whether we do that in g-v-m or in the mixer applet
<pitti> mdz: I just think it is not worth the trouble of temporarily introducing huge modifications to the mixer applet if we want to have an universal event notifier in the future
<mdz> pitti: so the g-v-m patch detects the change, but can't take the appropriate action for the mixer applet?
<pitti> mdz: well, it can also change the default card, that's no problem
<pitti> mdz: however, we wanted a "configure card..." which calls the mixer 
<pitti> mdz: of course this should show the new card by default, to make any sense
<pitti> mdz: however, that's an entirely different problem, it's just the reason why I didn't yet upload that
<mdz> pitti: is it something we could bounty upstream for?
<mdz> to make it easier to tell the mixer to change?
<pitti> mdz: I already talked with upstream
<pitti> mdz: upstream's preferred solution would involve some heavy gconf/gstreamer action
<mdz> daniels: still a file overlap between libx11-6 and xlibs-data
<pitti> mdz: however, finally he didn't think a simple command line argument were entirely wrong
<doko> seb128: ping
<seb128> doko: pong
<Kamion> fabbione: after a fresh install, I get a post-update information item telling me that I've just installed a new version of the Linux kernel
<fabbione> Kamion: hmmmmm.... yes.. 
<fabbione> Kamion: that's a tricky problem to solve
<tvo> Riddell: hi
<fabbione> Kamion: because the notification file is installed with the package.. making it part of postinst is an issue...
<fabbione> Kamion: because a kernel update with an ABI change will be recognized as fresh install
<fabbione> and you won't get the notification of such kernel
<mdz> doko: you mentioned you had been preparing new oo.o2 packages; what is the blocker?
<fabbione> Kamion: perhaps we can clean the messages queued for the notification applet at first install?
<doko> libxt-java and libxp-java, reviewed by pitti, waiting for universe->main promotion
<doko> mdz: ^^^
<mdz> doko: I didn't get an email about that; did you ask elmo or Kamion?
<doko> hmm, you are subscribed to the wiki page? anyway, I'll send a notice in the future. uploaded it on Saturday
<mdz> doko: done
<mdz> doko: does it need to be given back?
<Kamion> fabbione: uh, I guess - seems pretty hackish though :(
<doko> mdz, infinity: yes
* infinity looks up.
<Kamion> fabbione: I see what you mean, though, it's problematic
<doko> mdz: ahh, no, it's auto-tried ... so it should just build.
<fabbione> Kamion: yes.. and there is no way i can change postinstall dynamically at build time because it's added by kernel-package....
<mdz> infinity: oo.o2
<pitti> fabbione: I have the same problem with the language pack upgrade notification; writing the file in postinst is the only solution I see
<fabbione> pitti: i can't write it in postinst.. really..
<Kamion> pitti: with package names changing, that's tricky for the kernel
<Kamion> so how do I clear out the notification applet's queue?
<infinity> doko : Indeed, OO.o2 is in needs-build on all arches.
<fabbione> Kamion: i think it's enough you remove the files from the notification dir before executing it
<infinity> doko : Do any of its build-deps need some TLC?
<fabbione> Kamion: since it's a fresh install the notification applet won't even see them
<pitti> Kamion: /var/lib/update-notifier/user.d/notification-2.6.12-3-powerpc
<doko> infinity: TLC?
<Kamion> fabbione: (a) I don't execute the applet, I just start GNOME, (b) that file is shipped in the .deb so I can't remove it
<infinity> doko : Tender Loving Care.  Or "effort on my part".
<doko> infinity: no
<infinity> Alright.
<fabbione> Kamion: well yes you can remove it.. it's not a config file ;)
<pitti> fabbione: /etc/kernel/postinst.d
<pitti> fabbione: I use that for linux-hardened-support, works very well
<fabbione> pitti: ?
<pitti> fabbione: that's a hook dir for kernel postinst's
<pitti> fabbione: you can drop a file in that directory, and it will be executed; you can use that to generate the update notifications
<fabbione> pitti: and what would be different from installing the file directly?
<Kamion> fabbione: it's rather painful for me to mark that update-notifier hook as seen
<Kamion> fabbione: (short of just rming the file, which I won't do)
<pitti> fabbione: you can check whether you are installing from scratch, or upgrading
<fabbione> pitti: you will hit the same problem as Kamion told you above...
<Kamion> fabbione: to do that, I have to write into the initial user's home directory; and I can't do that in all cases, because it might be e.g. NFS-mounted
<fabbione> pitti: with a name change due to ABI change, you won't see the difference between a fresh install and an upgrade
<Kamion> the installer avoids stuff that requires it to write into the initial user's home directory for good reason
<Kamion> fabbione: you can look for /boot/vmlinu* or similar
<Kamion> fabbione: or I can try to get you some hint that you're running within the initial bootstrap
<fabbione> Kamion: i am more prone to remove this notification area thingy
<Kamion> though that's also relatively hackish ...
<fabbione> it's more a problem to do than the problem that it solves
<fabbione> and hounetly the kernel maintainer scripts are already complex enough to add extra point of possible failures
<Kamion> mm
<mvo> could the hooks themself extended to better support your needs somehow?
<mvo> (sorry for jumping in late)
<fabbione> mvo: eheh no problem dude :)
<Kamion> if there were a global way (not touching users' home directories) to mark a hook as seen, that might help?
<fabbione> mvo: the hook would require a high level of complexity to recognize only what's happening
<mvo> Kamion: that would certainly be doable
<fabbione> Kamion: would it be so bad for you to just trash that file at first install? imho it's at the same level of hugly hacks as me getting crazy to figure that out from maintainer script hooks
<Kamion> fabbione: I think it goes over my hack threshold
<pitti> mvo: u-n should check the md5sums of changed files, so that it doesn't display the same notice again
<Kamion> I don't mind globally saying "no notifications on first install", but trashing a specific file for a specific package (even if it is the kernel) is getting pretty grotty
<pitti> well, the first alternative would indeed help
<mvo> Kamion: the hook files are not precious, I think I'll add some sort of cleanup for old hook files anyway in the future
<pitti> mvo: right now I wanted to convert the langpack update notice from "ship in deb" to "generate dynamically in postinst" for the same reason
<fabbione> Kamion: i understand that
<mvo> Kamion: but your point is valid of course
<pitti> mvo: I basically have the same problem: if I install the langpack from scratch, I don't want the note
<mvo> pitti: not sure about this, the kernel message "please reboot" is always the same, but needs to be displayed nevertheless
<Kamion> mvo: I think all files shipped in .debs have to be considered precious - I don't want to confuse tools like debsums by going around removing shipped files
<mvo> right
<pitti> mvo: maybe a better solution than reinventing the wheel in many postinsts is a "install-update-note" script in u-n?
<mvo> pitti: what would that script do?
<pitti> mvo: maybe "i-u-n <package version> <package version for displaying note> <file>"
<pitti> it could compare postinst's $2 lt-nl <package version for displaying note>
<pitti> so it wouldn't be installed if the pkg is installed from scratch ($2 == '')
<pitti> and wouldn't be installed if it already exists
<pitti> however, I didn't think about that thoroughly, I just need that for the langpacks
<pitti> fabbione certainly has different requirements for ABI changes etc.
<mvo> pitti: would it be ok if you could try to make your language-pack script a bit more generic so that it could be envoled into a generic i-u-n script later?
<Riddell> tvo: hi
<tvo> you're my mentor :)
<tvo> you received my mail?
<pitti> mvo: well, I'll implement what I need now, then we can discuss about a generic approach
<mvo> pitti: fair enough, thanks
<tvo> Riddell: you received my mail?
<Amaranth> tvo: Can you do me a favor? You don't have to do it now, just for next time you connect.
<tvo> Riddell: any comments about it?
<tvo> Amaranth: probably
<Amaranth> tvo: It helps others figure out who people are if they put their real name in for their user info.
<Amaranth> right now /whois tvo says 'gaim', I dunno if you can change that with gaim
<tvo> Amaranth: ah ok, I'll try to figure that out
<mdz> elmo: is it possible/reasonable to move things from multiverse to universe via teri, or should I ask you instead?
<pitti> brb
<tvo> Amaranth: done, thanks for the info
<Amaranth> tvo: Awesome, now I can look up what you're working on. :)
<tvo> hehe
<Riddell> tvo: don't see an e-mail from you, what was the subject?
<tvo> Riddell: "Kubuntu Summer of Code"
<Riddell> tvo: ah of course, havn't read it
<Riddell> Edinburgh has been fairly hectic this weekend
<Riddell> naturally it's not at the top of my TODO list
<Riddell> s/not/now/
<tvo> Riddell: ah ok, just checking, some feedback would be appreciated once you've read it...
<pitti> Riddell: btw, I tested the new KDE langpacks; the mo files were installed, but the app didn't even look for them
<pitti> Riddell: may it be that kdelibs does not use libc's gettext(), but its own implemenetation?
<Riddell> pitti: KDE does need the language set
<Riddell> pitti: do you have an example package I could test?
<pitti> Riddell: http://people.ubuntu.com/~pitti/langpacks/ -> language-pack-kde-de-base_20050702_all.deb language-pack-kde-de_20050702_all.deb   
<pitti> Riddell: I tried with "kenolaba"
<pitti> Riddell: I straced it, and it does not look in /usr/share/locale-langpacks, as libc does
<pitti> Riddell: so I assume KDE apps use a kdelibs or whatever implementation?
* icaro hi all
<pitti> Hi icaro
<icaro> hi pitti 
<sivang> pitti: Hi Martin, 'sup?
<pitti> Hi sivang
<ivoks> hello
<doko> mdz, Kamion, elmo: please promote libdb4.2-java-dev to main as well, just a split from libdb4.2-java
<mdz> doko: I already had
<mdz> doko: python2.4-numarray now depends on some atlas3 packages
<mdz> atlas3 is that massive optimized math library, right?
<mdz> the packaging has seemed questionable to me
<doko> mdz: very strange, libdb4.2-java-dev and libdb4.2-java are missing in the archive now. the buildd cannot find the package either.
<mdz> doko: I moved them into main at the same time as libxt-java and libxp-java
<mdz> they were just new binaries from a source package in main
<mdz> libdb4.2-java-dev | 4.2.52-19ubuntu2 |        breezy | amd64, i386, ia64, powerpc, sparc
<mdz> libdb4.2-java | 4.2.52-19ubuntu2 |        breezy | amd64, i386, ia64, powerpc, sparc
<doko> mdz: yep. I'm waiting for a reply from the Debian maintainer. at least on our release architectures they should be preferred over the blas and refblas packages.
<doko> mdz: ok, after the last Packages update, it can be found again.
<mdz> doko: I also moved boost, since it was required by openoffice and pitti reviewed it
<mvo> Kamion: I'll upload a new update-notifier with support for a global "seen" file in /etc/update-notifier/hooks_seen. the format is "hookfile-name mtime was-run" (e.g. "kernel `date +%s` 0")
<pitti> mvo: how does that help?
<mdz> mvo: how does the current mechanism work, to know when the message has already been seen?
<doko> mdz: thanks
<mvo> pitti: after a fresh install kamion can add a entry to this file and the kernel hook will not be displayed
<mvo> mdz: it save a seen-file (same format) in the users homedir (in .update-notifier/hooks_seen)
<seb128> elmo: ping?
<pitti> hm, still looks h4ck1sh
<mvo> pitti: yes :/
* fabbione -> food
<mdz> seb128: left alt+tab works as normal, but right alt+tab acts funny (when I release right alt, the selector stays up, and focus never changes).  do you know what might cause that?
<Kamion> mvo: ok, I guess the only problem after that is that I have to work out the hookfile-name, but that should be straightforward
<Kamion> find /var/lib/update-notifier/user.d/ -type f | sed "s/\$/$(date +%s) 0/"
<Kamion> or similar
<mvo> yes, that should work
<Kamion> well, with an extra space and with -printf '%P\n'
<mdz> infinity: what's happening with the infrastructure bits of SoundEvents?
<seb128> mdz: nop, seems to be a xorg/xkb issue
<Kamion> mvo: what does the was-run bit do?
<Kamion> mvo: I've committed that to base-config, anyway
<mvo> Kamion: it tells if the script that may be embedded into the hook was run
<seb128> mvo: libgtk2-perl issue is known upstream and by the Debian maintainer, should be fixed with next upstream, you can comment stuff on debian/rules for the moment as workaround if you want
<Kamion> mvo: ok, thanks
* ..[topic/#ubuntu-devel:mdz] : Ubuntu Development | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://www.ubuntulinux.org/wiki/DeveloperResources | If you have unexpectedly lost editbugs privileges, talk to mdz/ogra/kiko | Colony CD 2 released
<mvo> seb128: disable the tests for now you mean? 
<seb128> mvo: yep
<seb128> I was waiting on new version/Debian version
<Riddell> pitti: I think your kde-language packs should include the entry.desktop, flag.png and charset files used by KDE
<Riddell> pitti: but also if you do kde-config --path locale it comes out with /home/jr/.kde/share/locale/:/usr/share/locale/
<pitti> hm? desktop files in langpacks?
<Riddell> pitti: so I need to work out how to add /usr/share/locale-langpack to that path
<pitti> Riddell: so /usr/share/locale-langpack needs to be added to that path?
<pitti> ok 
<pitti> Riddell: can't this rather just use libc's gettext?
<Riddell> pitti: seems not, I think for historical reasons
<Riddell> hopefully KDE 4 will use gettext properly but I think back when this was written gettext didn't support everything needed
<mdz> Riddell: did we reach a resolution on whether we need to upload another gettext package for kde?
<Riddell> mdz: nope, carlos was going to look into it after rosetta 1.0, which was going to be start of july as I mind
<mdz> Riddell: is it blocking any of your work?
<Riddell> mdz: it's blocking KDE support in rosetta.  I have plenty of other things to get on with
<mdz> ok
<mdz> seb128: is there a newer (not yet uploaded) version of gst-plugins0.8 which build-deps on libmpcdec?
<mdz> the version in breezy doesn't seem to require it
<seb128> mdz: yep, on my list for today, why?
<mdz> seb128: ah, ok
<mdz> seb128: because it has a main inclusion report
<seb128> mdz: was waiting on the approval before uploading
<Riddell> pitti: the entry.desktop is needed to select the language through KDE Control Centre, works fine if you export LANG=foo but that's not very user friendly
<pitti> Riddell: hm, but these desktop files should already be shipped somewhere, right?
<Riddell> pitti: they're in kde-i18n-xx
<pitti> hrm
<infinity> mdz : Now that we actually have people submitting sounds, I'll upload the packagy bits in the next couple of days.
<mdz> fabbione: have you been in contact with the XenIntegration mentee?
<mdke> smurfix, around?
<fabbione> mdz: yes.. i did send out pings to all the guys and received acknoledge from all of them.
<mdz> fabbione: ok, please update the BreezyGoals entry accordingly
<fabbione> mdz: they will feed me with weekly status reports.
<mdz> list the student as the responsible person and mark it as a google project
<mdz> (there are examples already on the page)
<Kamion> hmm, the firefox logo in gnome-icon-theme needs to be fixed I think
<fabbione> mdz: will do
<mdz> fabbione: thanks
<fabbione> no problem
<Kamion> why is mozilla-firefox.png shipped by about n different packages anyway?
<mdz> infinity: is there something about the changes which makes them unsuitable until we have sounds?
<seb128> Kamion: why?
<mdz> I expect the process of gathering and refining the sounds will take some time yet
<seb128> Kamion: what's wrong with the icon theme?
<Kamion> seb128: it's the Mozilla foundation logo rather than the de-branded globe
<seb128> they can't ship it?
<mdz> doko: regarding OpenOfficeLocalisation, the status says it depends on oo.o vs. oo.o2; I think we are essentially committed to v2 at this point
<mdz> doko: what remains to be done?
<Kamion> seb128: the one in gnome-icon-theme is trademarked according to mozilla-firefox 0.8-6 changelog
<Kamion> and there seem to have been some problems with that
<seb128> Kamion: hum, should I bug GNOME upstreams?
<seb128> any pointer for them?
<Kamion> best check with thom, maybe
<Kamion> I think he knows the history
<seb128> k
<Riddell> pitti: how is that locale-langpack directory added to gettext programmes locale path?
<pitti> Riddell: a libc6 patch
<smurfix> mdke: yo
<pitti> Riddell: I proposed to upstream to generalize that facility, but it was rejected
<Riddell> pitti: right.  and what's the reason for using locale-langpack over just installing to locale?
<pitti> Riddell: to avoid file conflicts with locally installed debs
<mdke> smurfix, yo indeed. thanks for the email, we've been looking at smf, can you tell me which locoteams use it so we can see what it looks like in practice?
<smurfix> mdke: -fi and -ru
<mdz> pitti: I was thinking yesterday about whether we could avoid stripping locales from .debs
<mdke> smurfix, thanks
<mdz> pitti: and do a delta from upstream translations->current translations instead of last-langpack->current translations
<mdke> smurfix, -fi looks quite nice
<mdz> pitti: depending on the activity level in rosetta and how quickly upstream integrates translations, it could be similar size
<mdz> and would simplify things
<seb128> and would be better for users
<pitti> hm, worth thinking about that
<seb128> atm if a package change the translation domain, the app goes to 0% translated 
<pitti> well, that doesn't happen in stable releases
<seb128> no, but it happens with unstable
<seb128> and translators need to have correct translations to work to translate the next version
<seb128> hum, lot of "translat" on the same sentence :p
<pitti> mdz: I think that would mean a bigger sum of package sizes (mo files in deb + delta langpacks), so we probably need to drop more langpacks from CD
<mdz> pitti: you think?  it seems non-obvious to me
<pitti> mdz: i. e. if somebody in Rosetta fixes just one string, we would ship the same mo file twice
<mdz> pitti: would it be a lot of work to calculate it?
<pitti> mdz: well, calculating it requires the percentage of touched translations
<fabbione> YES YES YES!!!!
<pitti> mdz: we currently can't ship a "diff mo", just complete mo files
<fabbione> Kamion: i just got the first automatically generated /boot out of p-a-l :D
<mdz> pitti: right
<pitti> mdz: so in the worst case the amount of shipped mo files doubles
<mdz> but I think the percentage is relatively small at this point, right?
<pitti> mdz: right now, yes
<mdz> and I expect that in mature projects it would stabilize
<pitti> mdz: but only because I don't yet pull translations from Rosetta
<mdz> e.g., gnome will integrate new translations very quickly
<pitti> mdz: right now I generate everything completely on my own from the stripped tarballs
<mdz> when a new language is translated, it won't be upstream, and we still ship only one copy
<pitti> right
<mdz> pitti: right, but that should change in...3 days?
<pitti> the exceptions are Ubuntu specific strings
<infinity> mdz : Well, one of the major changes will involve pointing apps at what we would consider to be "sub-optimal" sounds, with the expectation that we'll get those files replaced with something more appriopriate in ubuntu-sounds before we ship.
<pitti> but there aren't so many
<fabbione> mdz: wiki updated
<infinity> mdz : Now that I'm fairly confident the latter will happen, I'm happy to go ahead with the former, to make sure it's all in place.
<mdz> fabbione: thanks
<pitti> mdz: yes, if it really changes in 3 days, then I have actual numbers for estimating the overhead
<highvoltage> What is Oliver's nick? Ogra?
<pitti> highvoltage: yes
<highvoltage> pitti: do you perhaps have an idea when he'll be back home?
<pitti> highvoltage: no, sorry
<highvoltage> np
<pitti> well, next week at latest
<pitti> mdz: I calculate the diff when I get the first Rosetta updates, then we can evaluate that again. okay for you?
<mdz> pitti: sounds good
<pitti> mdz: just let me tell you that the latest Hoary tarball I got imported some 200 MB worth of new po files (uncompressed)
<mdz> highvoltage: I would expect that he would be home already
<highvoltage> mdz: okay. is he normally on irc most of the time, or not?
<mdz> highvoltage: yes
<mdz> his flight back was yesterday at about 2000 I think
<highvoltage> mdz: thanks, i'll just come check a bit later.
<pitti> mdz: so maybe I shall wait for another 3 days with uploading the split set of langpacks?
<doko> mdz: OO.o2 translation: I'm sending an update this afternoon, will CC you and update the wiki
<mdz> seb128: why is it that the X server is started by gdm without -br now?
<Kamion> fabbione: cool :)
<mdz> pitti: why, is the split affected by the rosetta exports?
<pitti> mdz: no, but say we only upload diff packs, then we might not need the split any more
<mdz> pitti: good point
<seb128> mdz: I've dropped the change while switching the package to CDBS, I'll fix that with next upload
<seb128> mdz: thanks for noticing
<seb128> pitti: I'll do a gst-plugins0.8 upload, what audiosink do you want as default?
<pitti> seb128: I think it should be esd for now
<seb128> k
<pitti> that'll work with both polypaudio and esd
<pitti> seb128: does the polypaudio sink work for you now?
<seb128> I've not built the new version yet
<seb128> I'll let you know when I try
<mdz> seb128: pitti approved libmpcdec (https://wiki.ubuntu.com/MainInclusionReportLibmpcdec), so feel free to upload and I will process the promotion
<seb128> mdz: I've doing the sync with Debian atm, will upload soon
<mdke> smurfix, i've noticed there is something at ubuntu-it.org already, is that your server
<\sh> strike...gnuradio-core actual cvs is compiled on all archs
<smurfix> mdke: it's my server, but not the default page that *should* be there :-/
<smurfix> I'll fix that
<mdke> smurfix, no biggie, the other thing I noticed is that there are three directories in the irclogs directory, i don't know if there is a difference between them?
<smurfix> mdke: No, they're symlinks
<mdke> whoops
<mdke> ok
<smurfix> I've added a -FollowSymlinks to the .htaccess file there, but it does't take for some reason
<pitti> seb128: hell, that Jeffrey Stedfast guy rewrote half of g-v-m, and still declares that as a microrelease
<seb128> pitti: that's a unstable serie
<pitti> seb128: in any case he did some really nice work
<seb128> cool :)
<pitti> seb128: it seems to be maintained again
<seb128> pitti: GNOME change the minor only between tarballs, no consideration on much code has changed
<pitti> sjoerd: here?
<seb128> is there any Ubuntu ftpmaster around? :)
<pitti> well, this set only contains elmo :-)
<seb128> I've a evolution-data-server to upload with 2 new binary packages, can these be directed to main when the package is accepted?
<seb128> pitti: :(
<seb128> pitti: I'm trying to ping him to get a glib2.0 sync from Debian for 3 days now (k, I should not work during weekends) 
* seb128 consider doing an upload to Ubuntu instead of the sync
<pitti> seb128: that should indeed work
<seb128> jdub: what are you pimping and where?
<pitti> does anybody know whether a sync is any more than just "upload the package from Debian to Ubuntu"?
<seb128> pitti: the issue is that you can't upload the Debian version to ubuntu, you need to update the changelog and then have to sync for next upload
<seb128> which is not optimal
<pitti> seb128: ah, right
<pitti> seb128: so upload -0ubunt1 :-)
<seb128> sucking
<pitti> that should be autosynced over on the next occation
<seb128> I want a sync
<seb128> and I want e-d-s accepted to new break evo
<seb128> s/new/not/
* seb128 declares lunch time
<mdke> ah good
<Kamion> seb128: I can do the e-d-s -> main thing
<Kamion> seb128: I don't know the runes for doing syncs, though
<seb128> Kamion: can you also accept NEW packages?
<Kamion> yes
<seb128> k, I'll do my e-d-s upload so :)
<seb128> libexchange-storage1.2-0 libexchange-storage1.2-dev are the new binaries
<Kamion> ok
<\sh> seb128, will it solve the add account evo crash bug? your new upload? :)
* fabbione kicks harddisks metadata!
<zul> raid went kablooie again?
<fabbione> zul: no... thanks god no...
<fabbione> pvscan was reporting a partition as part of an VG
<fabbione> when it wasn't
<fabbione> dd is your friend :)
<fabbione> when you need to clean partitions metadata :)
<fabbione> i couldn't really understand how my 20GB harddisk all of sudden reported 37G :P
<zul> lol
<seb128> \sh: nop, downgrading libglib2.0-0 fixes that
<seb128> Kamion, mdz: can you move system-tools-backends-dev to main to fix gnome-applets build?
<\sh> seb128, k...
<Kamion> system-tools-backends-dev | 1.2.0-4ubuntu1 |        breezy | all
<mdz> seb128: I already did
<Kamion> seb128: it's already there
<mdz> a couple of hours ago
<mdz> seb128: ping infinity if it needs attention
<seb128> Kamion, mdz: oh, right, that has just changed, thanks
<{Seb}> i've just downloaded colony 2 and it is looking good
<{Seb}> but after apt-get upgrade, i can't login
<pitti> {Seb}: does the gnome startup hang?
<{Seb}> yep
<pitti> {Seb}: https://bugzilla.ubuntu.com/show_bug.cgi?id=12276
<{Seb}> only on my laptop though
<{Seb}> so if i install libesd0, it shoudl solve it?
<pitti> either that, or install polypaudio
<pitti> (and p-alsa)
<{Seb}> what does polypaudio do?
<pitti> it's a much better esd 
<pitti> however, still a bit unstable
<pitti> but testing is highly appreciated
<{Seb}> will it become default in breezy>
<pitti> that depends on whether it is stable enough
<{Seb}> esd seems to cause a lot of problems
<{Seb}> what would you recommend? libesd0 or polypaudio?
<pitti> I'd recommend to try polypaudio and tell me about any crash you experience :-)
<pitti> it runs stable on my laptop for many days now, though
<{Seb}> are you by any chance the package maintainer?
<pitti> the current one in Ubuntu
<{Seb}> but my desktop (Audigy 2) works fine so i'll leave it
<pitti> I'm the dude who should sanizite the audio infrastructure
<pitti> sanitize, even
<{Seb}> will the next esd upload sort out the problem btw?
<pitti> well, neither seb128 nor me could identify the real culprit by now
<pitti> probably a gtk bug
<{Seb}> it only seems to be with some cards though
<pitti> seriously, could be a bug in a new gnome library wrt. sound event handling
<{Seb}> ah, you are Martin Pitt from the Bug report ;-)
<pitti> yes :-)
<{Seb}> just jotting down
<{Seb}> i need to install polypaudio
<{Seb}> and will this remove the nasty stuf
<{Seb}> f
<pitti> yes, it replaces esound
<{Seb}> thanks pitti
<pitti> no worries :)
<{Seb}> going to try it out
<{Seb}> i will report back within the hour!
<{Seb}> bye
<pitti> thanks
<pitti> seb128: btw, any new idea about a sound events gnome lib?
<seb128> pitti: libgnome a some sound stuff
<mdz> fabbione: do you know anything about the tpm_nsc module?
<mdz> fabbione: it's loaded automatically by hotplug on the craptop, and when it is loaded, it breaks networking
<mdz> if I blacklist it, it then tries tpm_atmel, which also breaks networking
<mdz> if I blacklist all tpm*, it works OK
<fabbione> mdz: all i know it's a driver to manage some crypto stuff in hardware
<fabbione> mdz: there is a patch in bugzilla that seems to fix some of the issues, backported from that upstream
<fabbione> mdz: it won't make 3.3
<fabbione> (that i am about to upload)
<fabbione> because the patch is quite intrusive and i need to check what's going on upstream
<hunger> mdz: Could you try the patch in bugzilla for tpm?
<hunger> mdz: That makes the module autodetect the proper chip for me.
<mdz> hunger: url?
<mdz> I may not have time to build a module to test, but I'll grab the patch in case I do
<hunger> mdz: search for tpm... that should get it for you.
<hunger> mdz: It worked for me... I asked fabbione to try to include it in the ubuntu kernel. Not sure what he will do about it (the patch does change the ABI of that module).
<tseng> mdz: https://bugzilla.ubuntu.com/show_bug.cgi?id=12065
<fabbione> hunger: as i explained to you i need to test it. i have an upload to do before that patch
<hunger> fabbione: I did not mean to criticise... I hope that didn't come across as such! I was mearly trying to say that I do not know whether you can include it or not.
<fabbione> hunger: not at all... i was explaining on what i was workign and for when it's scheduled
<hunger> fabbione: By the way: AFAICT the patch is part of the 2.6.16-rc2 set.
<hunger> fabbione: s/2.6.16/2.6.13/
<fabbione> hunger: even better :)
<spacey> k
<{Seb}> seb128: sorry to ask you again but after installing colony 2, i can't add an evolution account and you said to downgrade a package. What was it?
<seb128> {Seb}: libglib2.0-0
<{Seb}> seb128: thanks
<seb128> np
<mdz> seb128: libmpcdec promoted
<seb128> mdz: thanks
<mdz> fabbione: so the SoC guy has not started work on Xen yet?
<mdz> fabbione: (you left it as Pending rather than WIP)
<fabbione> mdz: he didn't send me any status update yet.. so for me it is still pending
<fabbione> mdz: take into account i joined the loop later, because my email address was wrong in the first emails communications and i got them not from the beginning
<mdke> the hoary installer will resize ntfs won't it?
<Kamion> should do, yes
<mdke> Kamion, ok thanks, is there a caveat?
<{Seb}> seb128: that works thanks but only temp. 
<{Seb}> seb128: i can't leave it there :-(
<seb128> ?
<{Seb}> seb128: loads of deps. are broken when installing libglib 2.6.3-1
<seb128> {Seb}: you can force the install time to make the account and apt-get -f install than
<{Seb}> seb128: i have got it forced installed and made my Evolution mail account but I now need to remove 2.6.3-1 because everything in GNOME (from eog to gstreamer) seems to depend on 2.7.0
<seb128> {Seb}: upgrade to 2.7.0 again
<fabbione> Kamion: i think for tomorrow we will get the first install on P-A-L :)
<fabbione> Kamion: now i have everything i need ;)
<fabbione> Kamion: /boot and the vg container are created automatically :)
<fabbione> Kamion: recipe parsing is the rock :=)
<fabbione> actually...
<fabbione> i might be able to do it right now ;)
<melodie> hello everybody :)
<melodie> I'm coming for a question about Backports becoming official repository
<melodie> I read several web pages about that
<melodie> and this one particularly:
<melodie> https://wiki.ubuntu.com//UbuntuBackports
<melodie> I didn't find yet an info about authentification key. Does someone know if one is ready or will be ready soon ?
<melodie> :)
<mdke> hmm that page still shows the agenda for the meeting
<mdz> melodie: when the official repository is in place, it will be signed with the usual key
<mdke> i don't know if there was a meeting summary published
<mdz> I posted a followup to ubuntu-devel at one point
<mdz> not a summary as such...though I vaguely recall someone offering to summarize
<mdke> yes one of the forum admins did
<mdz> perhaps the summary was posted to the forums :-/
<melodie> mdz: do someone know when the repository will be ready ?
<melodie> I didn't find more info on the Backports forum
<melodie> the most recent message I found:
<melodie> http://ubuntuforums.org/archive/index.php/t-38727.html
<mdz> melodie: soon
<mdz> the work is in progress
<melodie> mdz: does someone know precisely when or too early to say ?
<melodie> :)
<mdke> looks like maybe the report was intended to go on the wiki page
<Keybuk> hmm
<Keybuk> did anybody else notice that Ubuntu is now #1 on DW 12 months?
<mdke> yeah there was a post to the ML
<mdke> totally cool
<mdz> Keybuk: sounder noticed
<melodie> Keybud: sorry, what is 'DW 12 months' ? :)
<mdz> melodie: there will be an announcement when it is finished
<Keybuk> kinda cool that it wasn't even public twelve months ago :)
<mdke> ;)
<mdke> melodie, DW = distrowatch
<mdke> its a website
<melodie> ok I know distrowatch :)
<melodie> I think Ubuntu can become a major distribution
<melodie> although it is still young
<mdz> mdetect on the craptop takes ages for some reason
<melodie> but it is maybe the one distributions that benefits of the best organisation and communication methods :o
<melodie> about the officiallisation of Backports, anyhow we are sure it's going to be done aren't we ?
<ivoks> ubuntu will be de facto standard :)
<melodie> :)
<ivoks> i have found backports very bad (depending on libs that aren't in ubuntu; debian's version of libc), so i did some backporting my self...
<Kamion> mdke: sometimes has problems with unclean filesystems, otherwise seems ok
<melodie> Backports hold many interesting packages, it's a good new that they join the official componants
<melodie> then the dependency problems are going to be checked... :)
<mdz> melodie: as I already said, the work is in progress.  so, yes, it is going to happen.
<fabbione> cya tomorrow guys
* fabbione &
<ivoks> http://akaimbatman.blogspot.com/2005/06/linux-desktop-distribution-of-future_15.html - not a bad read
<ivoks> if anyone interested...
<Treenaks> about what?
<ivoks> few toughts by a guy who admiers OSX :)
<Treenaks> ivoks: is that a gentoo dude? with the "a new --prefix for EVERY program" ?
<pitti> *shudder*
<ivoks> yeah :))
<mdz> daniels: gah, when you changed the name of autodetect_keyboard, you also changed the semantics
<mdz> daniels: and in a way that I can't override
<mjg59> mdz: Hi
<mjg59> mdz: I'll try to get that draft done today
<mdz> mjg59: thanks.  daf said you may come down to london on wednesday?
<mjg59> mdz: Yeah, it's a possibility. If not then Thursday.
<mjg59> Thursday may actually work out easier, but do you have any preferences?
<mdz> mjg59: wednesday is preferable, since thursday is my last day here
<mdz> (leaving midday friday)
<mjg59> Ok, sure
<mjg59> I'll need to leave for the evening, but should be able to get a few hours done
<mdz> Kamion: so we need to straighten out xorg's autodetect_keyboard
<mdz> what we want is for the default on new installs to be true, the default on upgrades to be false, and for preseed-for-reconfigure to work
<mdz> Kamion: we also presumably want preseed-for-new-install to work
<mdz> I assume what this means is checking the 'seen' flag on new installs
<Kamion> typically one ends up setting the seen flag to false after asking the question rather than before
<doko_> elmo: please sync java-gcj-compat and python-imaging
<mvo> AndyFitz: do you have a idea for #12223 (better icon for update notification messages)?
<seb128> pitti: is docbook2x on your list? it's a build-depends for gnome-doc-utils
<pitti> yes, it's in the queue
<pitti> however, still busy with g-v-m
<seb128> should I make a wiki page for it or something?
<pitti> if you want to, that'd be great
<seb128> pitti: k, I'll
<pitti> evaluate debian and upstream bugs, look for the security history (although that shouldn't be an issue), review packages
<pitti> it's a particularly uncritical program, so that should be fine
<seb128> pitti: I'll base it on the libmpcdec page you made
<pitti> :w
<pitti> sorry, EFOCUS
<seb128> pitti: EWINDOW
<seb128> bah :p
<pitti> yes, bloody touchpad...
<pitti> fabbione: from your kernel changelogs: "monotith: targets" -> monotits? that sounds scary :-)
<mdz> seb128: there's a page which explains the review process
<mdz> seb128: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
<seb128> mdz: yep, I've just read it, thanks
<melodie> I thank mdz and mdke for the informations, before quitting :)
<melodie> good end afternoon as see you... 
<pitti> seb128: new g-v-m is indeed a nice piece of work, I could drop a lot of patches
<pitti> seb128: I'll send the remaining ones to that guy, he seems to be pretty active
<seb128> pitti: cool
<seb128> pitti: that's a novell guy, they seem to have good motivation to work on the desktop
<daniels> mdz: how did the semantics change?
<daniels> mdz: ah, just seen the bug mail now
<mdz> seb128: what's happening with LaunchpadIntegration?
<mdz> the last time we spoke about it, I think you were still deciding on the method to implement the menu extensions.  we need to get started on the implementation quite soon
<daniels> mdz: found and fixed the issue
<mdz> daniels: covers all the cases in the bug?
<mdz> it seems like whenever we fix one of these, we forget about another
<mdz> that's why I tried to lay them all out
<daniels> mdz: as far as I can tell, it does, yes.  i think the issue was just that we were trying to be way too clever on reconfigure, so I nuked that stanza.  will double-check it in the morning.
<mdz> daniels: how do we arrange for it to be true on fresh installs?
<mdz> since the template default is false
<\sh> can someone sync the latest python-xmpp from debian, please?
<Kamion> \sh: ask elmo
<\sh> i would push the upload by myself, but it's in main :(
<Kamion> and then we'd complain at you, anyway :P
<{Seb}> pitti: i installed polypaudio and polypaudio-alsa and now i get a gnome desktop and sound!
<{Seb}> pitti: never had sound working before
<pitti> {Seb}: yay
<\sh> Kamion, *g* sometimes someone has to make a choice, between complaining or running software ,-)
<daniels> mdz: use auto_answer for it; it'll not be seen in that case
<Kamion> \sh: all the same, please follow the standard procedures
<seb128> mdz: most of apps use gtkuimanager, we can start patch apps for stuff using something else. jamesh said he'll give a shot on gtk to determine how easy that would be to change here ... I've that on my todo list for this week
<\sh> Kamion, that's why I'm asking :) 
<{Seb}> pitti: the log in sound doesn't play though
<mdz> seb128: ok, please make it your top priority, thanks
<seb128> k
<pitti> {Seb}: right, that's a known bug
<Kamion> \sh: the standard procedure is to ask elmo
<{Seb}> pitti: any other known bugs?
<pitti> {Seb}: not to me, apart from the broken sound events you mentioned
<\sh> elmo: please sync the latest python-xmpp from debian :)
* \sh will also provide a debdiff for python2.4 compile ;)
<{Seb}> just wondering, is there any chance of the ubuntu logo becoming the gnome menu icon in breezy?
<pitti> seb128: funny, docbook2x includes simple-patchsys.mk but still does inline patching (not a single file in debian/patches)
<seb128> pitti: lazy maintainers :p
<{Seb}> also, can i put in a request for a newer gmime?
<{Seb}> it is currently at 2.1.13 in Ubuntu and the latest version is 2.1.15
<{Seb}> next version of beagle requires 2.1.15
<tseng> when there is a "next version" of beagle i will update things
<{Seb}> thanks tseng
<seb128> {Seb}: https://bugzilla.ubuntu.com/show_bug.cgi?id=10121 for the menu logo
<pitti> seb128: thanks for the wiki page, I approved it
<{Seb}> tseng: can i take back what i said before
<seb128> pitti: thank you :)
<tseng> {Seb}: i dont know what you said before.
<{Seb}> tseng: about monodevelop
<tseng> {Seb}: sure..
<{Seb}> tseng: been working through my mono books and in SUSE, MonoDevelop crashes 5 times
<{Seb}> tseng: on breezy, none!
<tseng> :)
<seb128> bah, when you have uptodate version people start asking before new versions to know if they are going to be packaged ....
<pitti> seb128: COTF
<seb128> pitti: what? :)
<pitti> Crack Of The Future
<pitti> the next step after COTD (-day)
<seb128> ah ah
<pitti> seb128: bah, I'm reading ubuntu-bugs for a while now (just the new ones), it really must suck to be you :-(
<seb128> pitti: how long is your while? :)
<pitti> seb128: hm, maybe 4 weeks, don't know exactly any more
<seb128> oh, k, enough to get a picture
<seb128> you are welcome to subscribe to desktop-bugs list if you want :p
<pitti> seb128: but isn't that just a subset of u-bugs?
<seb128> yep
<seb128> that's if you want to follow desktop bugs without reading the whole u-b flood
<mdz> Kamion: can you think of a robust way for me to determine the PID of the sshd child which is serving my connection?
<mdz> Kamion: if not, would it be reasonable to add an environment variable for that?
<pitti> seb128: oh, I just see the new ones, assign the ones to me that fall in my field, and CC to interesting ones
<Lathiat> mdz: $SSH_PTY
<pitti> seb128: works better for me than even more mail
<Lathiat> err, $SSH_TTY, rather
<mdz> Lathiat: how can I map that to the PID?
<Lathiat> mdz: with grepping of ps or looking through /proc
<mdz> ick
<Lathiat> i guess the other way would be some way of stepping up parent processes
<Lathiat> nfi how to do that
<mdz> hmm, I thought the child process was started in its own session, but perhaps now
<mdz> not
<mdz> looks doable, but an awful mess of a shell one-liner is required in order to do it as an ssh remote command
<Kamion> mdz: what for?
<infinity> mdz : Uhh, 'ssh host "echo $PPID"' seems to work for me... Unless you want one process up from that.
<infinity> (make that 'echo $PPID', even)
<Kamion> ssh host 'echo $PPID' is pretty pointless though, seeing as the process in question will immediately go away
<mdz> Kamion: LTSP
<Kamion> mdz: expand?
<mdz> stand by
<Kamion> mdz: if I want a new environment variable, I'd want to propose that to upstream, and they'd want a reason
<mdz> Jun 17 14:02:12 <mdz>   seb128: right, this isn't a problem with gdm logins because it resets the X server
<mdz> Jun 17 14:02:30 <mdz>   I can't reset the X server because I can't tell when the session has ended
<mdz> Jun 17 14:02:36 <mdz>   because these processes cause ssh to keep running
<mdz> Jun 17 14:03:05 <mdz>   I run ssh, wait for it to exit, and then reset the server
<mdz> Jun 17 14:03:13 <mdz>   gdm runs gnome-session, waits for it to exit, and then resets
<mdz> Jun 17 14:03:14 <seb128>        right
<mdz> Jun 17 14:03:29 <mdz>   gnome-session exits when it exits, but ssh doesn't exit
<mdz> until all connections are closed
<mdz> Kamion: I need to shut down the connection when the command exits, rather than when the X connections close
<Kamion> you could use the master/slave stuff and then do -O exit
<mdz> master/slave stuff?
<Kamion>      -M      Places the ssh client into master mode for connection
<Kamion>              sharing.  Refer to the description of ControlMaster in
<Kamion>              ssh_config(5) for details.
<mdz> interesting
<mdz> I don't think that will do what I want, though
<Kamion> the actual connection sharing stuff is unnecessary here, but you can use it to provide you with a mechanism to control a running client
<mdz> that would only let me control the running client from the local end of the connection, no?
<mdz> I could just as easily kill it there, but I can't reliably know when to do that
<mdz> which is why I set about looking for a way to do it on the remote end
<Kamion> oh, I see
<mdz> kill -1 $PPID isn't all that evil
<mdz> I didn't think ssh started a shell by default for the command
<Kamion> but doesn't the remote end already know when the command has exited?
<mdz> yes
<Kamion> for example the command could write a line to a FIFO when it's done
<Kamion> oh, never mind me
<mdz> I think ssh host <command>'; kill -1 $PPID' will do the trick, testing
<Kamion> would it be good enough to be able to tell ssh not to wait for forwarded connections to close?
<mdz> well, yes
<mdz> that's what I really want
<Kamion> (which is a more generic long-standing wishlist)
<mdz> that seemed like a harder battle to fight
<wasabi_> Eclipse ---> Universe? :)
<mdz> Jul 04 02:12:26 mdz     elmo: is it possible/reasonable to move things from multiverse to universe via teri, or should I ask you instead?
<Kamion> http://bugzilla.mindrot.org/show_bug.cgi?id=52 is kind of related
<Kamion> (other scary things WRT exiting early
<Kamion> )
<Kamion> not the same thing though, but would need to be considered
<mdz> hmm, doesn't seem to work reliably for some reason
<mdz> maybe there is some race condition in the signal handling
<Kamion> it might be more reliable to kill all the X clients on that display
<mdz> it would be more reliable to simply reset the server
<mdz> which drops all their connections
<mdz> but this probably requires writing an additional C program and installing it on the server side
* Kamion -> dinner
<mdz> which, as it happens, is arch: all at the moment
* mdz discovers python-xlib
<Kamion> you could just write random data down the X connection until the server crashes
* Kamion runs from daniels
<hunger> Kamion: Yes.... and send a copy of the random data to daniel, so that he can fix the bug it triggered. I'm sure he would be delighted to get mailed lots of random data:-)
<elmo> mdz: yes, it's fine
<elmo> teri's not tied to any specific component, the only problems she has are the "can't overwrite existent symlink" stuff you've run into once or twice before
<mdz> elmo: thanks
* mvo is away now to play hockey
<mxpxpod> seb128: ping
<seb128> mxpxpod: pong
<mxpxpod> seb128: alright, the rebuild fixed the one relocation error, but I'm getting a new one :)
<seb128> oh?
<mxpxpod> if I had a faster connection, I'd reinstall all the packages on my system
<mxpxpod> also, I'm having problems with X
<mxpxpod> wait, there's a update... let me get those and I'll see if those fix my X problems
<ivoks> xcompmgr and transset are really nice feauters :(
<ivoks> doh.. wrong channel :)
<mdz> daniels: what is the correct way to determine when it is safe to start a client for the X server you just started a bit earlier?
<mdz> daniels: it seems that if I do it too early, it can't connect.  I've added an arbitrary delay of a few seconds and that works
<mxpxpod> seb128: hmm
<seb128> ?
<mxpxpod> seb128: X still won't start for me...
<seb128> that's a bug for daniels :p
<schweeb> mxpxpod: think it's a symlink problem
<schweeb> from what I've heard
<mxpxpod> schweeb: ah, ok
<Riddell> seb128: what's the status of default folders for users (Documents, Music etc)?
<torkel> mxpxpod: you can probably work around it with: ln -sf /usr/bin/Xorg /etc/X11/X
<mxpxpod> torkel: yeah, just figured that out :)
<mxpxpod> thanks, though
<seb128> elmo: glib2.0 (experimental) clearlooks gtk-doc (incoming) syncs please
<seb128> Riddell: no move on that afaik
<mxpxpod> torkel: yeah, that worked... thanks :)
<Riddell> seb128: any ide
<seb128> Riddell: somebody need to pick a package name and a list of folder and to mail the list about it probably 
<torkel> mxpxpod: np
<Riddell> seb128: any idea which spec that was part of?
<seb128> Riddell: http://udu.wiki.ubuntu.com/FileManagerImprovement
<Riddell> seb128: thanks
<seb128> np
<mxpxpod> seb128: wanna see the new relocation error?
<seb128> mxpxpod: yep
<mxpxpod> /usr/lib/gnome-panel/wnck-applet: error while loading shared libraries: /usr/lib/libwnck-1.so.16: R_PPC_REL24 relocation at 0x0ffa7b58 for symbol `XextRemoveDisplay' out of range
<seb128> still wnck ...
<mxpxpod> yessir
<seb128> wait for jbailey :p
<mxpxpod> I noticed that libwnck17 just went in
<seb128> yep
<seb128> time for diner here, bbl
<mxpxpod> maybe (crosses fingers) that will solve stuff when everything is converted
<mxpxpod> seb128: have a nice dinner
<seb128> thanks
<terrex> where can i read a tutorial for writing makefiles
<terrex> ?
<mxpxpod> terrex: lidn.sf.net
<terrex> mxpxpod: thx
<mxpxpod> terrex: you can learn a lot of stuff there :)
<jp> hi all :) the upgrade of some x packages broken my x server :D cool, why you don't try them before upload? =P
<jp> tday opgrade :)
<mxpxpod> jp: do you know how to fix it?
<jp> mxpxpod: no dude :(
<mxpxpod> jp: try this: sudo ln -sf /usr/bin/Xorg /etc/X11/X
<jp> thanks mxpxpod :)
<mxpxpod> jp: thank torkel 
<mxpxpod> he showed me
<jp> hehe thanks torkel :P
<torkel> jp: np
<torkel> jp: ...as long as you don't hang me next time X fails when upgrading, because the changed link makes anything else to break :-)
<mxpxpod> torkel: it shouldn't break anything else
<torkel> mxpxpod: and ypu are willing to bet on that? It is X we are talking about :-)
<torkel> s/ypu/you
<mxpxpod> torkel: haha, good point... I retract my last statement
<jp> torkel ;) :P
<jp> /var/cache/apt/archives/libx11-6_1%3a6.2.1+cvs.20050615-4_i386.deb
<jp> E: Sub-process /usr/bin/dpkg returned an error code (1)
<jp> uhmm :$
<jp> I upgrade with reinstall on my other pc running breezy too :$
<chol> 3~
<chol> oops
<jp> sudo apt-get install --reinstall libx11-6 xlibs-data
<jp> I just didi it :)
<jp> jeje
<jp> now let's compile gnome :p
<calc> is wpa-supplicant going to be integrated with network manager for breezy?
<jp> torkel the ln didn't work :(
<jp> when I startx says /etc/X11/x isn't executable :/
<calc> it should be a symlink to the X executable
<hunger> jp: IIRC startx does not like symlinks.
<calc> jp: on my system its actually /usr/bin/X11/Xorg not /usr/bin/Xorg
<hunger> calc: Are you on breezy?
<calc> hunger: yea
<jp> I did ln -sf /usr/bin/Xorg /etc/X11/X
<hunger> calc: It is /usr/bin here... strange.
<jp> I'll try what you say calc 
<calc> hunger: hmm i haven't updated since yesterday
<calc> jp: well just look to see where that binary is on your system to link it properly
<jp> calc: thank you dude
<jp> ;)
<jp> now it works :D
<jp> :P
<{Seb}> has anyone got Network Manager to work on Breezy?
<calc> hmm there is another xorg update since i lasted updated my system
<shaya> sigh, /usr/X11R6/bin/X isn't installed suid, which means startx doesnt work
<calc> its suid here
<calc> xserver-xorg 6.8.2-33
<shaya> it's suid for me now too
<shaya> because I made it
<calc> i didn't change anything
<shaya> 6.8.2-34
<calc> hmm upgrading to that now
* calc kicks someone for breaking things in between releases ;)
<calc> yep my suid bit went away
<shaya> :(
<shaya> filed a bug
<shaya> https://bugzilla.ubuntu.com/show_bug.cgi?id=12397
<shaya> and gdm's been broken for ages for me
<shaya> hence why I see this startx
<shaya> anyways
<shaya> off to see batman begins in imax
<shaya> later
<calc> gdm works for me, but i just installed this laptop yesterday
<shaya> hmm
<shaya> maybe should try again
<shaya> but not now
<shaya> movie beckons
<wasabi_> Is there a way to create a symlink using a full path, but actually have it stored with a relative path?
<wasabi_> Build-script related. I don't want to be ln -s .../.../../../../../blah
<wasabi_> But rather ln -s $(FULLPATH)/file
<doko_> wasabi_: policy is to use relative symlinks
<carstenh> .oO(why not try it and be surpriced that it works?)
<wasabi_> doko_, I know. I want them stored relative... but I want to use a build-script variable to create them.
<carstenh> .oO(hmm, policy)
<Lathiat> so make your build script figure out how many .. you need
<Lathiat> add one each makefile iteration? :)
<wasabi_> Lathiat, =(
<wasabi_> I'd like ln to figure it out for me haha
<doko_> use dh_link
<wasabi_> I had thought dh_link wouldn't take absolute paths.
<doko_> it does, and makes relative link when necessary
<wasabi_> I just basically thinkg ../../../../ looks ugly and unreadable.
<daniels> guh, -EMDZ
<Yann2> hi
* Yann2 , from the french locoteam, wondering if it might be possible to open a forum for all locoteams
<Burgundavia> Yann2, that would be a forum issue, and they have there own channel #ubuntuforums
<Yann2> thx :)
<Yann2> bye ! :)
* Riddell replies to tvo 
* tvo checks his mail
<doko> elmo: please could you install OOo2 build-deps on davis/breezy?
<siretart> wasabi_: impressive work on eclipse! running great here!
<wasabi_> Super. Thanks!
<wasabi_> The #classpath guys desearve more credit than I, however,
<siretart> wasabi_: just a minor "tweak", in Help->About the build id is @build@ ;)
<wasabi_> Yeah. I know. ;)
<siretart> ok :)
<siretart> wasabi_: why is the default workspace place ~/.eclipse/workspace? Is this new at upstream since eclipse 3.1?
<wasabi_> No. It's sort of something I need to think about more.
<siretart> it's not a real problem, but I'm used to work with ~/workspace. just a habit
<wasabi_> Eclipse tries to put hte workspace in the current directory.
<siretart> ah, ic
<wasabi_> And I cd into .eclipse before launching it.
<wasabi_> And I don't like ~/workspace since it's ambiguous.
<elmo> doko: done
<jordi> elmo: too bad you were in Leeds :|
<wasabi_> Actually, I think the entire workspace idea sucks.
<wasabi_> But the worksapce is where the per-user settings go.
<jordi> mdz nearly got me drunk
<ivoks> :)
<wasabi_> So... what I'd *like* is for the user to never be asked about the workspace.
<wasabi_> For Eclipse to just open, properly.
<wasabi_> But, when you create a new project, for it to attempt to create the project outside the workspace by default.
<wasabi_> Or open an existing project and it works as normal, etc.
<siretart> that would really be nice, but I this does not integrate cleanly in a windows environment, which upstream seems to be concerned about
<siretart> :/
<wasabi_> How so?
<wasabi_> ~/workspace isn't defautl for Windows.
<siretart> no?
<siretart> never worked with eclipse on windows, maybe I'm talking bullshit ;)
<elmo> jordi: yeah, sucky timing
<wasabi_> Well, first off ~ doesn't exist on Windows. ;)
<wasabi_> I think Eclipse creates it in My Documents, actually.
<wasabi_> It's still compatible in the same way. You can alter teh worksapce to be anywhere.
<siretart> wasabi_: I tried to "run" a hello world from eclipse, but I keep getting this error dialog "An error occured. See error log for more details". Is this a known bug or a misconfiguration on my side?
<wasabi_> Nope. I don't know it.
<wasabi_> Let me give it a go, hold on.
<wasabi_> I don't think I've run anything yet.
<wasabi_> HEHE
<ivoks> i did perl :)
<jordi> elmo: next time. I hear your living room is the data centre now ;)
<wasabi_> Yeah I see it.
<wasabi_> Looks like a classpath issue.
<wasabi_> XML parsing.
<wasabi_> Super
<doko> elmo: thanks
<doko> hmm, bad time for a dist-upgrade ... no atheros driver in 2.6.12, and the gnome-session doesn't start.
<ivoks> ? it does :)
<siretart> wasabi_: if I find further issues, shall I ping you on irc, or do you prefer email? or some other bug tracking system?
<wasabi_> bugs.
<wasabi_> I haven't looked at malone enough yet to understand it.
<wasabi_> I wish it was just in bugzilla. =/
<siretart> bugs. ?
<stratus> fabbione, what's up with linux-restricted-modules-2.6.12-3-686 ? linux-meta build a related metapackage but i can't see the package itself around, can you?
<stratus> daniels, around?
<daniels> l-r-m for 2.6.12 isn't ready yet, and it will take a little while
<Treenaks> daniels: people will love you for it
<stratus> daniels, thanks i just need the updated ipw2200 firmware, i'll do it manually now.
<daniels> i'm doing what I can
<daniels> stratus: er, I didn't think that was in l-r-m
<daniels> no, it's not
<daniels> the only firmware in there is for acx1xx
<daniels> ipw2x00 stuff is in linux-source
<stratus> was it moved after hoary ?
<spotter> daniels you here?
<daniels> stratus: no
<daniels> spotter: sup
<stratus> daniels, packages.ubuntu.com is lying to me so
<spotter> calc experienced same suid problem
<spotter> maybe dpkg related?
<stratus> daniels, i'm talking about files sitting at /lib/hotplug/firmware the ipw2200* ones
<trukulo> hi ppl
* spotter cant believe he decided to irc from his cell
<Lathiat> stratus: they are in linux-image-2.6.12
<daniels> stratus: i've maintained l-r-m since 2.6.8.1 days, and I don't remember ipw2x00 ever being in there, largely because it was already in the core kernel package
<Lathiat> stratus: dpkg -S /lib/hotplug/firmware/ipw-2.3
<stratus> Lathiat, i found thanks
* spotter pokes calc
<daniels> spotter: i dunno, sorry
<daniels> spotter: but yeah, xserver-common has always had it suid, and I've never touched that bit of the code
<spotter> I'l look again when i get back from this movie
<spotter> irc from cell way too painful
<doko> hmm, somebody knows, if libnss-dev can be built from the firefox source instead of mozilla?
<Mitario> lo everyone
<jp> ol
<mvo> hey Mitario 
<jp> now I upgraded and x crashed again
<jp> ;)
<jp> now it says: fatal server error, unable to connect to x server =P
<jp> now it says: fatal server error, unable to connect to x server =P
#ubuntu-devel 2005-07-10
<elmo> 5%#!^!#$%!
* maswan runs for the hills
<maswan> or.. what's wrong?
<elmo> some{one,thing} killed concordia again
<Lathiat> concordia?
<daniels> elmo: not me
<dholbach> hi
<Mitario> hi dholbach 
<dholbach> hey Mitario :)
<dholbach> sleep tight, i'm off for now
<dholbach> *wave*
<hidde2> seb128?
<seb128> hidde2: pong
<hidde2> seb128, sorry to bug you, but I did something to the session of my main user, and I can't log in now. What can I do to reset it so it won't hang on initialising the session?
* hidde2 added irexec -d to his set of startup-programs and is locked out now
* daniels coughs.
* hidde2 feels exessively foolish
<seb128> hidde2: you can move ~/.gnome2/session away
<seb128> or edit it
<mxpxpod> seb128: have you seen jbailey?
<hidde2> seb128, i think i rm-ed that file, that used to solve it, when I did something similar earlier
<hidde2> brb
<seb128> mxpxpod: nop
<mxpxpod> k
<daniels> elmo: could you please pre-NEW xserver-xorg-driver-{apm,ark,ati,chips,cirrus,cyrix,dummy,fbdev,glide,glint,i128,i740,i810,imstt,mga,neomagic,newport,nsc,nv,rendition,s3,s3virge,savage,siliconmotion,sis,sunbw2,suncg14,suncg3,suncg6,sunffb,sunleo,suntcx,tdfx,tga,trident,tseng,v4l,vesa,vga,via,vmware}
<daniels> elmo: and also xserver-xorg-input-{acecad,aiptek,calcomp,citron,digitaledge,dmc,dynapro,elographics,fpit,hyperpen,js,kbd,magellan,microtouch,mouse,mutouch,palmax,penmount,spaceorb,summa,tek4957,ur98,void,wacom}
<daniels> elmo: thanks
<elmo> no
<daniels> hm?
<hidde2> seb128, i removed ~/.gnome2/session, and I still can't get in. It's hanging on something it's trying to start, not something that's left over from a previous session
<Kamion> daniels: (you realise it's easier to just NEW when they arrive rather than pre-NEW, right?)
<elmo> I'm not going to pre-NEW stuff, it's a horrible absolute-emergency only habit
<seb128> hidde2: seems to be the esound issue happening atm
<daniels> righto, then
<seb128> elmo: thanks for the syncs
<elmo> there's 2 other people with full katie privs and more than enough skillz to NEW stuff
<seb128> hidde2: try installing libesd0 
<elmo> if you're about my availability
<elmo> s/about/worried \&/
<hidde2> seb128, i'm running hoary, and it's something I did, some program/command it can't handle
<seb128> oh
<seb128> how have you put them here?
<elmo> (is upstream really splitting into that many input methods?  that seems like oversplititis)
<seb128> elmo: can you give these people the sync magic too? :)
<hidde2> I added irexec -d to my session startup with priority 1 system > preferences >session :$
<daniels> elmo: that's input/*_drv.o; we already have that many different drivers
<seb128> hidde2: this dialog is ~/.gnome2/session-manual
<daniels> elmo: so it'll be that many source packages in the future (when we all have flying cars)
<elmo> seb128: these people are kamion and mdz - you really want mdz or kamion spending time on syncs?
<daniels> elmo: mostly for weird-shit tablets and stuff
<hidde2> seb128, so if I remove that file, I should be ok?
<daniels> elmo: but, er, yeah, we'll pretty much end up with the biggest Binary line in the west
<seb128> elmo: "spending time" ... is that taking that amount of time? No, that's just a "when you are not around and a sync could be useful"
<elmo> seb128: dealing with sync requests are like bugs, they may seem trivial in of themselves, but they add up
<seb128> elmo: ie, I was waiting since saturday for new glib2.0 ... no big deal, but if somebody else can run the sync ... :)
<seb128> elmo: right
<elmo> seb128: and besides, did you miss the part where I said they already had full katie privs?
<elmo> seb128: saturday... you want me to work saturday/sunday now too?
<seb128> elmo: Kamion said today he doesn't know how syncs work
<Kamion> only because I haven't looked and I consider it elmo's bailiwick until told otherwise
<daniels> elmo: i thought we all checked our weekends at the door when we joined
<Kamion> I assume it's josie but I didn't want to poke too hard
<seb128> elmo: nop, you are right :)
<HiddenWolf> seb128, you rock
<elmo> anyway, sleep.  night all.
<seb128> 'night
<seb128> HiddenWolf: np
<HiddenWolf> can anyone here tell my why the kernel loads a driver for the serial port?
<Lathiat> ... ?
<Lathiat> So you can use the serial port?
<HiddenWolf> sort of
<shack\out> I think he means "even if you don't have one"
<Lathiat> oh
<Lathiat> is it a generic driver or a specific driver?
<HiddenWolf> The piont is, i have one, and I can use it, as long as I tell the kernel to get the hell off the port, and allow lircd to listen on it
<Lathiat> oh right
<Lathiat> thats a different story
<Lathiat> so, theres a driver for the serial port
<Lathiat> but lric doesnt want to use that and wants to use it directly
<Lathiat> so you can configure with setserial not to use it
<HiddenWolf> that's another way of putting it ;)
<Lathiat> using lirc with FIR mode?
<HiddenWolf> lathiat, happen to know how exactly?
<Lathiat> want to know how to release the serial port?
<HiddenWolf> lathiat, not using lirc at all, atm, just trying to get lirc_serial loaded manually
<Lathiat> setserial /dev/ttyS0 uart none iirc
<HiddenWolf> lathiat, yeah, automagicly preferably
<Lathiat> setserial can be configured to save its config
<HiddenWolf> So sudo  setserial /dev/ttyS0 uart none iirc && sudo dpkg-reconfigure setserial -> to manual > reboot should do the trick?
<HiddenWolf> ugh
<HiddenWolf> without the iirc, ;)
<Lathiat> somethign like that
<Lathiat> read lirc docs im sure they cover this :P)
<Mez> Lathiat, why does your name seem so...familiar?
<Lathiat> cus im on various other irc channels?
<Lathiat> avahi?
<Mez> hmmles
<HiddenWolf> lathiat, can I bug you if I can't get it to work?
<Lathiat> maybe yoru in one of the other communities i hang aroudn in *shrug*
<Lathiat> HiddenWolf: no, cus im ;leaving, good luck with that :)
<Mez> Lathiat, Trent Lloyd?
<Lathiat> Mez: yes
<Mez> ah
<Mez> I've read your LJ before thats why
<Lathiat> ah
<Lathiat> planet.fd.o ?
<Mez> no
<Mez> http://www.livejournal.com/users/lathiat/
<Lathiat> nah just thought you might have known it from planet.fd.o or something :)
<Mez> fd.o ?
<Mez> whats fd /
<Lathiat> freedesktop.rog
<Lathiat> *org
<Mez> wait - are you in the UK Lathiat ?
<Lathiat> nope, australia
<Mez> have you been to UK recently?
<Lathiat> nope, never been outside australia :P)
<Lathiat> (IRJ*#RR@#*(H@R#@*H()#R(*H
<Lathiat> i'm goign to remove my P key
<Lathiat> i look like such a dick typing :P)
<Mez> lmao
<Lathiat> i hit it accidentally typing :) all th etime
<Mez> lol
<Mez> take the key off... and chop away prt of the key to make it lighter then put it back on
<Mez> have to hit it arder then to make it register
<jsgotangco> ajmitch, hello
<ChurcH_of_FOamY> mako are you there?
<ChurcH_of_FOamY> someone told me to contact you about promoting ubuntu
<ChurcH_of_FOamY> and i would love to do so ^_^ it absoulutely rocks! ^_^
<fabbione> morning
<Mitario> morning too :)
<jp> hohoh
<jp> here I'm gonna sleep now :)
<Mitario> yeah, still night here too
<jp> heh
<Mitario> although
<jp> fabbione where are you from ?
<Mitario> its getting very light out here
<jp> :o
<jp> here it's 23.30 :)
<fabbione> jp: i live in EU :)
<Mitario> 05:30 here
<Mitario> it's already daylight
<Mitario> well morninglight..
<jp> fabbione kewl :)
<jp> jeje
<jp> here we're on winter :'(
<Mitario> heh
<Mitario> hmm, i'm considering not going to sleep and just go to work in a few hours
<jp> :S
<calc> daniels: did you find the issue with the suid X binary?
<jp> tomorrow I'll have to give a school test :( it's a global mathematics test (from all one semester) :/
<calc> daniels: upgrading from 33 -> 34 caused it to no longer be suid for me
<calc> daniels: not sure which shaya upgraded from
<jp> I think I won't sleep too Mitario :P
<Mitario> hehe, been hacking update manager all night :)
<jp> Mitario :o hihi :P
<daniels> calc: and shaya said that upgrading again worked fine
<daniels> calc: no-one else has seen it, and the binary is *definitely* suid in all of the debs
<calc> hmm ok
<calc> i'll try it on my desktop now to see what happens
<calc> it is at 33 right now
<calc> -rwsr-sr-x  1 root root 9504 2005-06-30 15:58 /usr/X11R6/bin/X
<calc> should take about 5-6min
<calc> finished downloading, installing now :)
<calc> -rwxr-xr-x  1 root root 9504 2005-07-03 16:23 /usr/X11R6/bin/X
<calc> stripped on this box as well
<calc> perhaps it only affects upgrades?
<calc> btw dpkg -i the package again doesn't fix the perms
<calc> i'll try purging and installing it
<jp> bye guys
<calc> er nm i tried dpkg -i on the wrong package
<calc> so upgrading 33 -> 34 is reproducibly removing ug+s but dpkg -i xserver-common fixes it
<calc> did /usr/X11R6/bin/X change packages between 33 -> 34?
<calc> if so perhaps dpkg itself is hosing it
<calc> it wouldn't be the first time i have seen dpkg screw stuff up
<daniels> no, it's always been in xserver-common
<calc> hmm thats really strange that it wouldn't keep the permissions then :\
<daniels> keybuk's fault
<calc> its in the package itself as ug+s and dpkg -i xserver-common preserves them but upgrading from 33 -> 34 does not
<calc> heh
<jdub> Kamion: around? (unlikely as it may be...)
<pitti> A most beautiful good morning to everybody!
<AndyFitz> morning to you pitti
<HWolf> pitti, what's the occation? :)
<Church_of_foamy> morning pitti
<Church_of_foamy> ^_^
<pitti> HWolf: it's raining cats and dogs, and I try to maintain a good mood :-)
<HWolf> pitti, you most certainly lightened mine. ;)
<fabbione> hey pitti
<pitti> Hi my dear fabbione 
<fabbione> ehheh
<pitti> no kernel vulns in a week, that's suspicious...
<fabbione> last time you said like that... it costed me 40 hours of extra work on the kernel
<pitti> fabbione: this time I assure you that I don't have anything like that in my mind :-)
<fabbione> ok thanks :)
<pitti> fabbione: well, if you want to, you could make the breezy kernel not crash on my iBook :-) but nevermind, the hoary kernel works fine
<fabbione> pitti: is the sleep crash you filed?
<pitti> fabbione: that one too, but I have a really funny one
<fabbione> ok.....
<pitti> fabbione: I start my wireless, everything works perfect
<fabbione> yeah..
<pitti> fabbione: then, after some minutes I execute something with sudo, and this process hangs
<fabbione> hangs how?
<pitti> fabbione: normal user apps, and the wireless connection continue to run fine, just sudo processes are unkillable and hang
<pitti> fabbione: well, they sit around and don't do anything
<pitti> fabbione: and sudo kill ... doesn't work, because that sudo process of course hangs as well :-)
<ivoks> :)
<fabbione> pitti: i fail to see how that can be a kernel bug..
<pitti> it's like April's fool...
<fabbione> can you reproduce it on another arch?
<pitti> fabbione: I get an oops when the symptoms start
<fabbione> ok.. can you file a bug with the related oops?
<fabbione> i still blame GTK and QT
<pitti> fabbione: sure, will do. it should still be in my klog
<pitti> fabbione: but it's not that urgent
* ivoks thinks that's only bad hardware :)
<fabbione> i really need to stop to make make xmenuconfig :P
* pitti slaps ivoks
<Church_of_foamy> i want to become an endorser for ubuntu who do i talk to?
<pitti> fabbione: does that use gtk now?
* ivoks hates Macs :)
<whiprush> Church_of_foamy: mako probably
<fabbione> xmenuconfig uses QT...
<Church_of_foamy> is he on?
<fabbione> otherwise gconfig.. for GTK
<pitti> ivoks: my iBook works just perfectly with the hoary kernel, and the kernels before that
<fabbione> Church_of_foamy: he might be in a few hours...
<Church_of_foamy> i'm new to ubuntu but i like it so much....
<Church_of_foamy> cool
<whiprush> Church_of_foamy: on and off probably, you can always mail him
<pitti> Church_of_foamy: spread the love :-)
<ivoks> pitti: i was kidding
<Church_of_foamy> naw i'll just wait for him 
<ivoks> but i do hate Macs and OSX
<Church_of_foamy> i don't want to be imposing
<fabbione> Church_of_foamy: i am sure he doesn't mind emails...
<fabbione> Church_of_foamy: so don't worry about that
<Church_of_foamy> k
<Church_of_foamy> ^_^
<pitti> Hey jdub 
<fabbione> hey jdub
<daniels> infinity: ping
<infinity> daniels : gnop
<daniels> infinity: does this xmlrpc crap require an update to the php4 package, or is it just stuff using it?
<infinity> Requires an update to php4-pear.
* Amaranth kicks things
<infinity> It's on my "TODO in the next few days" list, since PEAR is in universe currently (and because most PHP apps have so many RCE vulns anyway, what's one more?)
<Amaranth> small bug in a PEAR library leaves half the web open to attack, yay
<infinity> Actually, maybe I'll do those uploads in the next couple of hours.
<infinity> Just 'cause that's what kinda nice guy I am.
<daniels> infinity: cock
<infinity> Diff is here, if anyone feels an urge to patch locally:
<infinity> http://cvs.php.net/diff.php/pear/XML_RPC/RPC.php?r1=1.75&r2=1.76&ty=u
<pitti> infinity: do you want to prepare {warty,hoary}-security as well? or shall I do it?
<infinity> daniels : Beware that some (many?) crap PHP apps ship with their own broken xmlrpc implementations that are besed on the one from PEAR.
<daniels> infinity: yeah, so I'm discovering
<infinity> pitti : Those were the two uploads I was referring to.  I'm must less concerned about breezy and sid.
<daniels> infinity: hence why ~a2se/500-clipart.freedesktop.org disappeared earlier this morning
<daniels> infinity: how 'bout sarge? :)
<pitti> infinity: ah, cool
<pitti> ok, cu later
<infinity> daniels : I'm doing sarge and woody, not sure how quickly joey will get the advisory out.
<daniels> infinity: any chance the package could make its way to gabe?
<infinity> daniels : Of course it will.
<fabbione> hey infinity 
<infinity> daniels : So, who's running a PHP app that uses PEAR xmlrpc, and can we smack them?
<daniels> infinity: rock, thanks
<daniels> infinity: guess who
<infinity> openclipart?
<daniels> got it in one!  running wp, as it turns out.
<infinity> I thought they were "taking their business elsewhere", or something.
<daniels> such is life
<infinity> Not soon enough, I guess.
<infinity> Oh well.  RCE vulns in PHP apps are so common in my neck of the woods, I take a pretty slack attitude to it.
<infinity> And try to make sure my I have no prev escalation holes lying around.
<infinity> One of my machines gets random crap written to /tmp as www-data all the time, cause I'm too lazy to tell all the users to upgrade their broken phpBB installations.
<daniels> just as long as there's no more weird shit in /var/tmp
<infinity> When in Aug are you going?
<infinity> -EWIN
<comadreja> dear developers all of you :) How could I get started into helping out you ?
<HWolf> you <-> out
<HWolf> :)
<comadreja> oh, sorry :)
<comadreja> my english is getting better everyday 
* fabbione successfully boots in a partman-auto-lvm installation of breezy
<fabbione> daniels: xserver-xorg postinst just barfed here...
<fabbione> (latest version.. clean install)
<fabbione> daniels:
<fabbione> Setting up xserver-xorg (6.8.2-34) ...
<fabbione> dexconf: error: cannot generate configuration file; 
<fabbione> xserver-xorg/config/inputdevice/keyboard/layout not set.  Aborting.  
<fabbione> and manual reconfigure hangs....
<pitti> Hey carlos
<carlos> pitti, morning
<pitti> Hi jsgotangco 
<jsgotangco> pitti!
<pitti> Morning mdz
<fabbione> hey mdz
<mdz> morning
<seb128> hey mdz
<jsgotangco> hey
<doko> carlos, morning
<carlos> doko, hi
<mdz> chmj: morning...how is the bluetooth work going?
<carlos> doko, I'm reading all mail since Friday, will try to answer your oo2 mail soon
<chmj> mdz, morning  
<chmj> mdz, been testing some other devices, we still don't have a workable UI interface for it though
<doko> carlos: fine
<mdz> chmj: Paolo Durante will be working on that part of the project
<mdz> chmj: meanwhile, we should ensure that the pieces that we already have work out of the box
<chmj> mdz: can you give me his email?
<jsgotangco> :)
<mpt> comadreja: http://ubuntulinux.org/community/participate
<doko> lamont, infinity, elmo: OOo2 FTBFS on powerpc on the buildd, builds fine on davis.
<doko> cc1plus: out of memory allocating 1643995136 bytes after a total of 80863232 bytes
<mdz> chmj: I don't have it; you can get it from JaneW
<mdz> chmj: or perhaps pitti
<mdz> doko: does it build on i386?
<chmj> mdz: ok 
<doko> mdz: yes. just fixed a packaging error, but it got until the binary target. let's wait some hours for the ubuntu2 build
<doko> however davis does have that amount of memory
<infinity> OOM allocating 1.6 gigs?... Am I reading that right?
<fabbione> doko: eh?
<fabbione> doko: davis has 3GB of RAM for a mistake
<fabbione> and only because it's running the 64bit kernel
<doko> fabbione: yes, it succeeds on davis, but not on the buildd.
<fabbione> doko: the buildd don't have more than 2GB of RAM
<infinity> The more interesting question is why does gcc want that much RAM?
<doko> poor buildd
<fabbione> and i guess that single process can't swap a single byte
<infinity> Seriously.  Ouch.
<fabbione> doko: it won't build on other arches as well...
<doko> fabbione: it did on i386
<fabbione> i am not talking on i386 :) i am more thinking of sparc :)
* fabbione only has 512MB of ram
<doko> never heard before ... ;-)
<fabbione> doko: speaking of which.. i have a couple of intersting FTBFS that might be gcc related
<fabbione>  /usr/lib/gcc/sparc-linux-gnu/4.0.1/../../../../lib/crt1.o:../sysdeps/sparc/sparc32/elf/start.S:60: multiple definition of `_PROCEDURE_LINKAGE_TABLE_'
<fabbione>  /usr/bin/ld: Disabling relaxation: it will not work with multiple definitions
<fabbione> collect2: ld returned 1 exit status
<doko> fabbione: don't forgot to attach the preprocessed source for ICEs
<fabbione> doko: i didn't get there yet...
<fabbione> the preprocessed source is for ppc..
<fabbione> i need to do that on davis
<fabbione> dokoo: ah rigth.. there was the ICE for mysql on sparc..
<fabbione> will do soon 
<mdz> is there any existing tool which will output the addresses of network interfaces on the system in a parseable format?
<mdz> iproute really ought to do this, but doesn't try very hard
<mdz> the -o output format is not so bad I guess
<elmo> ip addr ls ?
<fabbione> hey elmo
<elmo> hey fabbione 
<fabbione> elmo: i think it's time to upgrade ppc kernels around...
<fabbione> elmo: so if you can schedule it for the next time you will be at the datacenter
<fabbione> doko: DOH! the last gcc-3.4 upload you did.. it fixed it :)
<fabbione> doko: the ppc ICE i mean
<fabbione> ah no
<fabbione> never mind
<doko> would be strange, no code changed
<pitti> shackan: Hi, still here?
<fabbione> doko: got confused by -j :)
<doko> fabbione: use the tools you can master ;-P
<elmo> fabbione: yeah, should be wed/thu
<fabbione> doko: CFLAGS += -save-temps
<fabbione> right?
<fabbione> elmo: cool
<fabbione> doko: is that the flag you need right?
<doko> fabbione: yes
<fabbione> doko: doing...
<fabbione> oh my darling.. -save-temps removes -pipe
* fabbione sighs at a full rebuild of the kernel
<chmj> ouch!
<doko> fabbione: or you build with verbose logs, and re-run the command, where it fails
<fabbione> doko: the kbuild doesn't like this kind of hacks ;/
<fabbione> i am going to rebuild.. it takes only a few minutes on davis
<fabbione> hey sabdfl 
<jsgotangco> ogra!
<ogra> hey
<fabbione> hmm food time :)
<jdthood> pitti: I have been thinking about set-default-soundcard.  I would like to add it to alsa-utils rather than to alsa-base (where it currently resides in ubuntu).  That seems like the most logical place to put it, even though alsa-utils is an arch-any package rather than an arch-all one.
<pitti> jdthood: would be fine for me, and since alsa-base depends on -utils, we don't have a migration problem either
<pitti> jdthood: however, what about python?
<jdthood> pitti: I'll add it to alsa-utils's dependency list.
<pitti> do you want to add a dependency? or wait for python-minimal?
<pitti> ah, ok
<jdthood> pitti: What exactly should that Depends item look like?
<jdthood> Just 'python2.4' ?
<pitti> just "python"
<pitti> there's nothing special in it, it works with both 2.3 and 2.4
<jdthood> "python" is a metapackage in both Debian and Ubuntu?
<pitti> yes, all python modules come with a metapackage that depend on the default version
<infinity> python always pulls in the current "default" python version.
<infinity> Just as "gcc" and "g++" do.
<spafbnerf> kill ubuntu!!!
<pitti> depending on a particular version should generally be avoided, unless there is a special reason
<pitti> nice dude, that spafbnerf
<jdthood> pitti: I want to remove aserver from libasound2.  Do you know anyone who uses that program?
<jdthood> If someone uses it then I'd rather ship it in alsa-utils, to comply with Debian policy.
<jdthood> If no one uses it then obviously we shouldn't ship it at all.
<pitti> jdthood: I never heard about it
<jdthood> /usr/bin/aserver
<jdthood> There is no manpage for it and I have never been able to find any explanation of how it should be used.
<pitti> hm, ENOMAN
<pitti> no help either
<jdthood> I have filed requests in the ALSA BTS for documentation.  Nothing has come forth.
<jdthood> pitti: Remember to add "Replaces: alsa-base" to the new alsa-utils (if you merge again after our next release) so that upgrades don't gag on the conflict between alsa-base and alsa-utils over /usr/bin/set-default-soundcard.
<pitti> right, good point
<pitti> well, MOM should see that automatically
<jsgotangco> brb
<camilotelles> mdz: hi there
<fabbione> doko: http://people.ubuntu.com/~fabbione/gcc-3.4-ppc-unionfs-ice.tar.gz
<fabbione> doko: there is everything inside.. code, build log with ICE and preprocessed code
<doko> wow
<doko> the fix is missing ;)
<fabbione> doko: that's your job. kthxbye
<fabbione> it happens with gcc-4.0 too (i did check it a long time ago)
<fabbione> but i can try again if you want me to
<doko> no, I'll do that
<fabbione> it would all be nice if -save-temps would actually save the temp files in the same dir as the source/obj
<doko> AFAIK it saves it in the current directory
<fabbione> doko: yes but current is not necessarely the one where the source/obj is stored
<seb128> daniels: around?
<Riddell> pitti: new kdelibs uses the locale-langpack path
<pitti> cool, thanks
<daniels> seb128: wassup
<pitti> Riddell: i. e. they look in -langpack if there is no matching file in locale?
<Riddell> >kde-config --path locale
<Riddell> /home/jr/.kde/share/locale/:/usr/share/locale/:/usr/share/locale-langpack/
<seb128> daniels: g-c-c cries on libXrandr.so because it tries to use /usr/lib and the lib is /usr/X11R6/lib ... xorg bog?
<Riddell> yep
<seb128> daniels: I've workaround it with a -L/usr/X11R6/lib for the moment
<pitti> Riddell: looks great
<Riddell> pitti: are you going to alter kde langpacks to include the entry.desktop and related files?
<daniels> seb128: g-c-c bug but it'll go away when libxrandr-dev moves to /usr
<seb128> daniels: do you know what g-c-c could do wrongly? So I can fix that ...
<daniels> seb128: not sure, sorry ... it's too late
<seb128> daniels: don't worry, the -L/... works fine if that's going to be fixed with the move to /usr that's all right
<seb128> is anybody maintaining firefox atm?
<daniels> cool
<fabbione> daniels: did you read the scrollback?
<daniels> not really
<fabbione> daniels: xserver-xorg barfs on fresh install
<daniels> no-one made my screen light up except seb
<fabbione> i did paste the error
<fabbione> i did
<daniels> oh, that
<daniels> yeah, I saw that, don't know what's going on there, will take a look
<fabbione> <fabbione> (latest version.. clean install)
<fabbione> <fabbione> daniels:
<fabbione> <fabbione> Setting up xserver-xorg (6.8.2-34) ...
<fabbione> <fabbione> dexconf: error: cannot generate configuration file; 
<fabbione> <fabbione> xserver-xorg/config/inputdevice/keyboard/layout not set.  Aborting.
<fabbione> 
<fabbione> <fabbione> and manual reconfigure hangs....
<fabbione> pl
<fabbione> ok
<Kamion> jdub: yo
<fabbione> Kamion: any objection for me to upload partman-auto with this change: http://people.ubuntu.com/~fabbione/partman-auto.diff ?
<fabbione> it's basically to move some common code in a "lib"
<fabbione> so i don't need to duplicate it
<fabbione> probably clean_method should go in another lib, but i wanted to ask you first
<fabbione> (there might be more coming later)
<Kamion> fabbione: looks ok, except that I don't understand why you removed one db_progress step
<fabbione> Kamion: expande_scheme is 2 functions in a raw..
<fabbione> in the original there was a db_progress in the middle
<fabbione> that i can't ensure it is a available in other packages that might use that function
<fabbione> (right now there is none in p-a-l)
<Kamion> oh, uh, I guess, ok
<fabbione> ok thanks...
<fabbione> Kamion: and this morning the first p-a-l installation succeeded :)
<fabbione> with a few errors.. but it managed to install breezy
<fabbione> Kamion: when you have more time, you will need to tell me how to apply some branding love to all the .po files for p-a-l :)
<fabbione> iirc you had somekind of method for it
<Kamion> partman-auto-lvm (2) UNRELEASED; urgency=low
<Kamion>   * Colin Watson
<Kamion>     - Change "new Debian system" to "new system" to help with derivative
<Kamion>       branding.
<Kamion> it will become irrelevant
<fabbione> ah ehehe :)
<fabbione> good
<fabbione> when do you plan to upload that one?
<Kamion> hadn't really decided
<Kamion> I can do it today/tomorrow if you like
<fabbione> well the code in the package is useless atm....
<fabbione> it doesn't work...
<fabbione> so up to you really...
<fabbione> it will just spare me time to merge .po stuff later on
<Kamion> sure, I'll do it now then
<fabbione> ok thanks
<Kamion> $ DEBIAN_FRONTEND=readline ./debconffilter.py ./dftest
<Kamion> tzconfig/change_timezone: I am a custom widget
<Kamion> Configuring
<Kamion> woo
<Kamion> 77 lines of python for something that filters and intercepts the debconf protocol
<daniels> hm, reminds me I need to upload my hundred-lines-of-python discover1
<daniels> but right now, I need to sleep
<Unfrgiven> hi all. anyone else having sound problems on breezy atm? logging into gnome just freezes untill i kill the two instances of esd. totem,xine and mplayer exhibit the same behaviour. any ideas? i just did a dis-upgrade for the first time after UDU.
<Lathiat> install polypaudio? :)
<Lathiat> dmix is beign used, maybe its reaking havoc on your hardware
<Treenaks> Lathiat: setting gstreamer to "automatic" helps a bit too :)
<fabbione> Kamion: if you didn't upload p-a-l i have something you can add to it for the sake of fun :)
<Lathiat> Treenaks: ooh it has that now?
<Unfrgiven> Lathiat: tried that. didnt help for totem, xine, etc.
<Treenaks> Lathiat: it had that yesterday
<Unfrgiven> Lathiat: i am using dmix atm. is that a possible cause?
<Kamion> fabbione: hadn't quite uploaded yet
<Lathiat> could be
<Unfrgiven> Treenaks: where does one do that?
<Unfrgiven> Lathiat: whats the easiest way to disable dmix?
<Treenaks> Unfrgiven: Multimedia Systems Selector in preferences
<Lathiat> Unfrgiven: dunno
<Lathiat> how can i found out what sink its autodetecting
<fabbione> Kamion: http://people.ubuntu.com/~fabbione/pal/03_make_vg_list_something_meaningful.diff <- apply this.. VG_list isn't use anywhere yet and definetely mine is better than the original :)
<fabbione> (note that vgs is available only on lvm2
<Kamion> fabbione: changelog entry?
<fabbione> oh right..
<Kamion> uh ok, upstream will need a 2.4able solution too
<Kamion> so vgs won't fly
<fabbione> ok
<fabbione> Kamion: why do you always have these complex questions like changelog entry... :)
<fabbione> Kamion: btw.. i don't think etch will have 2.4, but that's only rumors from #debian-kernel
<Kamion> fabbione: mm, it's unclear yet, but d-i is still supporting them until that decision's taken
<Kamion> fabbione: (I think you're probably right, but all the same I don't want to be the person who broke it :-))
<fabbione> Kamion: sure :) i understand perfectly :)
<Unfrgiven> Lathiat: disabling dmixer didnt work :(
<Unfrgiven> now esd appears to start
<fabbione> Kamion: i am keeping track of all the bits and pieces.. so you can just push them when you want
<Unfrgiven> but still no joy for totem, xine or mplayer
<Unfrgiven> totem hangs. xine and mplayer segment fault
<pitti> mdz: what do you think about putting cryptsetup into main?
<doko> mdz: what were the problems with atlas packaging?
<mdz> pitti: seems sane
<hunger> pitti: Yes, that would be great!
<mdz> doko: I don't remember; just a vague feeling of badness
<mdz> doko: if it's OK, it just needs review and it can go in
<seb128> can anybody move docbook2x and libexchange-storage1.2-dev to main to fix the gnome-doc-utils and evolution-exchanges ftbfses?
<hunger> pitti: Want a better init-script for it/
<pitti> hunger: what did you improve?
<pitti> hunger: right now I want to add a script which eases creating and formatting an encrypted partitino
<hunger> pitti: Mine does work with files (sets up loopback) and allows to run scripts at farious points.
<hunger> pitti: like format a drive, etc.
<Treenaks> hunger: nefarious points? :)
<ogra> mdz, ping
<hunger> Treenaks: nefarious?
<pitti> hunger: eek, formatting drives in init scripts?
<hunger> pitti: I need that: I have a /tmp that uses a random key...
<pitti> ah, I see
<pitti> hunger: can you send me the diff?
<hunger> pitti: So I need to format it after creating it... or mount will fail.
<hunger> pitti: I rewrote it from scratch... didn't like the original too much;-)
<hunger> pitti: Where can I mail it to?
<pitti> hunger: martin.pitt@ubuntu.com
<doko> mdz: ahh, because of the extra sse2 and 3dnow packages?
<hunger> pitti: OK, I'll take a while... I think I should add some documentation for you;-)
<pitti> that'd be nice :-)
<fabbione> doko: http://p.u.c/~fabbione/sparc-ice.tar.gz
<doko> fabbione: thanks, better nuumber them ;-) can I see from the source the package name?
<doko> pitti: where do you store the po/pot data, which you put into the language packs? Can we store OOo's GSI files there too?
<pitti> doko: they are in the tarballs stripped by pkgstriptranslations, currently hosted in people.u.c
<pitti> ... /~lamont/translations
<pitti> doko: I could adapt pkgstriptranslations to store these files too, no problem
<pitti> doko: however, this should be discussed with the Rosetta guys, to avoid import trouble
<doko> pitti: yes, waiting for carlos
<carlos> pitti, will not be a problem at all, Rosetta will ignore any file that is not needed
<carlos> pitti, will try to answer that email later today
<fabbione> doko: i did include the build-log in the tar.
<fabbione> doko: it's mysql-dfsg-4.1 anyway
<hunger> pitti: send...
<mdke> hi all
<jp> hi :)
<mdz> ogra: pong
<pitti> elmo: please sync pmount from debian experimental
<elmo>  * libwnck implements the "urgent" flag now, useful for gaim by example which can use it when a message arrive
<elmo> seb128: does that mean I can use gaim again?
<seb128> elmo: it makes some "glowing effect" on your windows' list when you get a message
<seb128> should be enough to notice that something is asking your attention :)
<elmo> which window list?
<seb128> that's a libwnck change, which is the lib used by gnome-panel for the window list applet ... if you don't use that, no change from gaim for you
<mvo> elmo: please sync synaptic from unstable
<elmo> seb128: the thing in the bottom right hand of the screen?
<elmo> mvo/pitti: done
<seb128> elmo: the stuff that use most of the bottom panel with the default config
<seb128> the bars with the windows' title on your workspace 
<elmo> seb128: hum, ok
<mvo> elmo: thanks!
<seb128> elmo: they are working on a libnotify though, that should what you want (ie: opening something on a place of screen to say that you get a message)
<seb128> s/what/do what/
<elmo> seb128: woo
<bddebian> Heya
<thom> seb128: gnome-system-tools is uninstallable right now
<mvo> thom: what is wrong with it? seems to work for me ?
<thom> seb128: "I/O warning : failed to load external entity "/etc/gconf/schemas/gnome-system-tools.schemas"
<seb128> thom: what does it say? what arch?
<thom> i386
<seb128> WTF
<thom> this is on a new breezy daily install
<seb128> do you have this file?
<thom> nope
<thom> it doesn't appear in the contents of the deb afaict either
<seb128> placed to /usr/share/gconf ?
<thom> yes, it's in there
* seb128 apt-get source
<fabbione> seb128: yeah .. i have seen that too
<seb128> thom, fabbione: somebody has put /etc/gconf/... instead of using dh_gconf, I'll fix that
<seb128> thanks 
<thom> np
* seb128 blames mvo who has synced with Debian :p
<thom> heh
<seb128> thom: are you still maintaining firefox? :)
<thom> hell no
<seb128> somebody is?
<seb128> I've 2 patches for it pointed by chpe, just wondering if I can bounce the task to somebody or if I just have to go and upload :p
<pitti> let's demote it to universe then
* pitti ducks
<thom> seb128: i think pitti wants to
<infinity> \o/
<bddebian> heh
<seb128> pitti: dholbach will be happy :p
<pitti> RIGHT! :-)
<thom> oh, yay
<thom> and now X is segfaulting
<infinity> That's intentional.
<infinity> It prevents you from getting far enough to find all the other bugs.
<pitti> thom: Breaky Badger?
<fabbione> lol
<fabbione> thom: it didn't even configure here :)
<thom> pitti: utterly fucked badger, currently
<pitti> infinity: then that segfault should rather be in grub, shouldn't it?
<fabbione> thom: you are more lucky than i am
<thom> fabbione: this is after dpkg-reconfigure
<fabbione> thom: do you still have your ia64 handy?
<infinity> pitti : I'll get right on that.
<Kamion> thom: the badger can never be ...
<fabbione> thom: dpkg-reconfigure hangs on me :)
<Kamion> no wait, wrong suite
<pitti> Kamion: your rule?
<thom> fabbione: it took a long time to do mouse detection
<thom> Kamion: giggle
<fabbione> thom: no.. it just hanged for like 10 minutes before i realizes it was dead....
<fabbione> thom: if you have time.. can you fire up 2.6.12 on ia64?
<fabbione> thom: the last version should be able to boot
<thom> fabbione: i'll look once i fix my power
<fabbione> sure
<fabbione> no rush
<fabbione> i am in d-i mode these days
<plovs> i try to build a meta-package that overwrites the conf-files of the package it installs, i use "Replaces: <pkg-name>" , but still get an error about overwriting files, what is wrong?
<seb128> overwriting config files? utch
<Kamion> replacing conffiles is evil
<Kamion> you'll probably need to make the package use a configuration file (non-dpkg-managed) instead
<ogra> but you can do it if you are a cfengine god ;)
<ogra> (which is evil as well)
<Kamion> I'm fairly sure you'll confuse dpkg if you try to ship the same conffile in two different .debs
<plovs> what would be the right way(tm) i don't want to change the original and i do want different settings?
<Kamion> you'd probably have to overwrite it in the postinst then - but you can never upload a package that does that to the distribution, it has to be local only
<plovs> Kamion: that's what i do atm,and it doesn't let me, but i can't think of a better way
<bddebian> jbailey: ping
<plovs> so, the right way would be a script in my meta-package that changes the underlying packages so everything playes nice?
<plovs> and run the script seperately?
<jbailey> bddebian: pong if urgent.  Just got net access, need to go out and buy breakfast...
<Kamion> no the right way is to fix the underlying packages to cooperate in the ways you need
<bddebian> jbailey: Just a quickie.  Is a P2/333 OK for the FTP server?  ( I need to check disk size though )
<jbailey> bddebian: Yes, fine.
<bddebian> OK, thx
<plovs> Kamion: thanks
<solomarv> mvo, are you subscribed to ubuntu-devel list?
<mvo> solomarv: yes
<solomarv> mvo, have you read the post about gksudo called "gksudo potentially ver insecure"?
<mvo> solomarv: yes
<solomarv> mvo, what is your opinion on this?
<mvo> solomarv: it was dicussed before, the problem is that if people would have to enter there password too often they will probably just change the password to something so easy/short that the security benefit of having to type it all the time would go away
<mvo> solomarv: I like the idea of a notification applet that indicates that you have (potential) root. if it would also have a option "forget sudo rights" (or something) that would be a good compromisse
<solomarv> mvo, an applet! that's a great idea. although, it might go unnoticed by some users. what about a notification dialog window?
<solomarv> mvo, something that says "You are running this application with root priveleges" , and have buttons {OK} and {Cancle}
<mvo> solomarv: yes, that idea is nice as well. both might be a bit challenging on the technical side because sudo is not very frontend-friendly
<solomarv> mvo, i will try to look into it
<pitti> seb128: if you open system -> settings -> audio -> sound events, does the "Play" button actually work for you? I try again to chase that esd hang bug
<mvo> solomarv: that sounds nice, thanks! if you actually start working on it, please open a whishlist bug in bugzilla, assign it to me and add "kov@debian.org" as QA contact (he is upstream) so that he knows what's going on
<seb128> pitti: it used to work, it doesn't atm
<pitti> seb128: not to mention that I don't get any sound events apart from the login sound in the first place, although I activated them
<solomarv> mvo, ok. i will do this if i find that i am capable of making a patch
<pitti> seb128: I wonder whether this might have anything to do with #12276...
<seb128> pitti: do you use esound or polypaudio?
<mvo> solomarv: great, thanks. if not, a whishlist bug to remind us about the issue may still be usefull
<pitti> seb128: esound ATM, I switched again to test that bug
<pitti> seb128: how does polypaudio work for you? I didn't get a crash in the last week
<pitti> seb128: I'm almost apt to switch to polypaudio now to get wider testing and circumvent the esd hang for the breezy users for now
<seb128> pitti: hum, I was using alsasink and polypaudio not started
<seb128> the play button works now
<pitti> seb128: ah, gnome-sound-properties hangs with esd, too
<pitti> seb128: might be easier to debug than killing the panel :-)
<pitti> seb128: indeed, play works with polypaudio
<pitti> seb128: however, the sounds are still not played when the event occurs
<seb128> pitti: there is a bug about that saying you need to restart gnome-session ....
<pitti> ah, ok
<pitti> seb128: well, one thing after the other, I continue to chase the esd bug now
<hub> I upgraded to breezy, and I had to remove network-manager to be able to get network
<solomarv> weird
<hub> yep
<thom> hub: anything in daemon.log?
<hub> thom: can't tell right now., I left the laptop at home ;-/
<thom> ah
<hub> I'll look at it and file a bug
<hub> I could access it if they didn't break the VPN here 
<thom> if you were upgrading from the pacakges at people.u.com/~thom they may well break
<hub> thom: using the universe package
<thom> i'd remove network-manager-gnome entirely and the reinstall network-manager
<thom> ok
<hub> resolvconf has never worked also
<solomarv> mvo, i downloaded gksu source using "apt-get source gksu". do you know how to build it now?
<hub> because it does no honnour the DNS passed by the DHCP server
<hub> I reported the bug upstream
<hub> so I'll take some time tonight to file a proper bug
<thom> you mean resolvconf with NM, or on its own?
<thom> ok, cool
<hub> with NM
<thom> don't report a bug on resolvconf about that
<hub> ok
<thom> it's purely an NM problem, and I know how to fix it
<hub> just for the NM breakage
<mvo> solomarv: dpkg-buildpackage -rfakeroot (if you have fakeroot installed)
<solomarv> ok
<mvo> seb128! you have a blog now?
<ogra> oh, he blogged *again* ? 
<mvo> ogra: two times today!
<ogra> woah
<Treenaks> I hope he's blogging & uploading at the same time.. otherwise I'd have to miss my New Gnome crack!
<seb128> mvo: that's not new, I just use it now :p
<seb128> Treenaks: I blog about the updates :p
<Treenaks> seb128: cool :)
<Treenaks> seb128: so now we know what crack we're getting ;)
<Treenaks> uh, wow.. people still use advogato?
<hub> Treenaks: some still do
<adamh> Has anybody here installed ubuntu on a flash drive? How well would it work?
<hub> adamh: can you boot off the flash drive ?
<adamh> hub: yes
<loo> hi
<loo> Does someone know how I can use a SMP kernel with hoary, ich have a ASUS Server with 2 xeon cpus and if I use a smp kernel the system freezes when gdm starts
<loo> I found in the forums some people with the same problem, but no solutions
<wasabi_> sounds like a pretty serious bug
<wasabi_> are there any bug reports for it?
<loo> yes, .. wait a moment
<loo> https://bugzilla.ubuntu.com/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=UPSTREAM&bug_status=PENDINGUPLOAD&field0-0-0=product&type0-0-0=substring&value0-0-0=smp&field0-0-1=component&type0-0-1=substring&value0-0-1=smp&field0-0-2=short_desc&type0-0-2=substring&value0-0-2=smp&field0-0-3=status_whiteboard&type0-0-3=substring&value0-0-3=smp&field1-0-0=product&type1-0-0=sub
<loo> BUG: 10135
<solomarv> loo, you should comment that bug with information you have gathered. 
<loo> I tried linux-image2.6.11-1-686-smp and 2.6.10-5-686-smp
<ogra> there is no supported 2.6.11
<ogra> thats a bitkeeper development snapshot from mit feb.
<ogra> s/mit/mid
<loo> ok
<loo> but 2.6.10 doesn't work too
<adamh> Is there a way to install Ubuntu on jffs2? (I want to set up Ubuntu on a flash drive)
<Kamion> the installer doesn't support jffs2 - you'd have to set up the filesystem by hand using debootstrap or similar
<adamh> Could I not pre-partition/format the drive, then run the installer and tell it not to repartition?
<ogra> loo, i would follow up with the data fabbione asked for in that bug, it probably helps tracking it down
<adamh> (since I notice the stock Ubuntu kernel comes with jffs2 support)
<wasabi_> Heh. In the Menu Editor, the hide checkbox is reversed.
<wasabi_> "Hide" is checked to show.
<Kamion> adamh: no, because the jffs2 module isn't shipped in udeb form, which would be needed in order for the installer to be able to mount it
<Kamion> sorry
<ogra> wasabi_, thats a string bug :-P just add a "Un" as prefix ;)
<adamh> Kamion: Okay, well, I'm tempted to try this anyway some night :). I haven't installed Ubuntu in a while, does it have a "server" installation option which omits an X server?
<Kamion> yes, type 'server' at the boot prompt
<adamh> Kamion: Great :)
<Kamion> debootstrap really is your best option though, unless you fancy some installer hacking :)
<wasabi_> I might call it "Show" instead.
<adamh> Kamion: I guess there are debootstrap howtos I can find with Google, right?
<Kamion> http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-i386/current/doc/manual/en/apcs04.html
<Kamion> adamh: alternatively, install onto a regular filesystem, and then copy that onto jffs2 in one shot later
<adamh> Kamion: Thank you! :)
<Kamion> adamh: that might involve fewer flash writes, too
<adamh> Kamion: yeah, that'll probably be faster
<loo> btw, should I use for xeon amd64 or x86?
<thom> x86
<adamh> I'm a bit worried about the booting part... I know I can boot from flash, but what will the /dev entry be? /dev/sde?
<Kamion> you could boot the installer in rescue mode to find out
<solomarv> does anyone here have permissions to edit pages on wiki?
<solomarv> probably should ask at #ubuntu-doc
<ogra> solomarv, everybody can change the wiki
<loo> does someone know what "usb-handoff" as booting parameter means?
<adamh> Kamion: Thank you for all your help :)
<loo> with usb-handsoff the system does not freeze when gdm starts
<solomarv> ogra, oh yeah, i need to create a login
<loo> but after login ;)
<loo> :(
<ogra> solomarv, yep :)
<Kamion> adamh: no problem
<adamh> Heh, one last question: if I'm installing onto a flash drive, should I put a swap partition? (I've got 256MB RAM)
<Lathiat> swap on flash is bad
<Lathiat> it'l eat it
<Lathiat> flash has a limited number of write cycles
<adamh> Yeah, I'm more worried about speed, though.
<Lathiat> trust me, its a bad idea :P
<adamh> So I'd have a server without a swap partition... whee, I've never used Linux without a swap partition before :)
<mdz> daniels: did you get my question about timing the start of a client vs. the X server?
<wasabi_> beagle somehow doesn't depend on mono
<ogra> wasabi_, mono is a metapackage
<wasabi_> Hmm. Okay. What's libMonoPosixHelper?
<ogra> wasabi_, it depends on the interpreter (mono-jit)
<wasabi_> Getting a DllNotFoundException
<tseng> its in libmono0-dev
<wasabi_> libmono0 perhaps?
<ogra> that should be in mono-assemblies-base afaik
<tseng> because of an upstream bug
<ogra> oh
<tseng> they named it .so.X
* ogra shuts up
<tseng> but it uses .so at runtime
<tseng> which is wrong
<tseng> (its fixed upstream now)
<wasabi_> Still missing it, and I have all that installed
<tseng> ls /usr/lib/libMonoPosixHelper.*
<tseng> you need .so
<tseng> if you dont have it, it doesnt work
<wasabi_> Well, it's there. No .so though. I see.
<wasabi_> Need to make the link myself?
<tseng> $ dpkg -S /usr/lib/libMonoPosixHelper.so 
<tseng> libmono-dev: /usr/lib/libMonoPosixHelper.so
<tseng> WFM.
<wasabi_> Cool.
<tseng> you said you had that
<tseng> i am doubting you
<wasabi_> I didn't have -dev installed.
<tseng> ok :)
<wasabi_> Wow. It works.
<wasabi_> That ROCKS.
<doko> elmo: can we upgrade one powerpc buildd to a ppc64 kernel? i.e. gcc-4.0 still seems to use huge memory building ooo2 (boost templates), and I'd like to turn on the gcc-4.0 testsuite for ppc64
<elmo> doko: not today
<elmo> I'll try and do it later in the week, but I have a bunch of other stuff to do that's time critical
<elmo> lamont/infinity: oh (not) speaking of, I need to reinstall royal at some point
<mdz> elmo: speaking of which, did you get a handle on the approach for backports?
<doko> elmo: thanks. do we have a powerpc devel machine with an 32bit kernel?
<mxpxpod> jbailey: ping
<wasabi_> Just neesd to search IRC now.
<elmo> doko: nope
<highvoltage> elmo: read your private messages
<mdz> highvoltage: you're still here in london?
<highvoltage> mdz: yes.
<jp> jbailey evo receiving option crash bug ;)
<highvoltage> will be leaving tonight
<mdz> highvoltage: I am impatient for you to get back and try the new thin client stuff ;-)
<highvoltage> mdz: me too! really!
<highvoltage> i'm also on a bit of a high from the weekend, I didn't expect such a positive reaction.
<highvoltage> i'm eager to get home, put that iso together and send it to you so that you can set up a test system with my software too.
<highvoltage> mdz: ltsp-client messed up my laptop badly, btw :)
<mdz> highvoltage: oh, I'll bet
<ogra> highvoltage, rather work on the edubuntu iso with me and make sure all your apps are in ;) 
<mdz> highvoltage: do you have your code in a revision control system?
<Mez> hmm
<highvoltage> ogra: ok, i'll do that too!
<ogra> ;)
<Mez> gnome-pkg-tools = unauthenticeated yet from gb.archive.ubuntu.com
<highvoltage> mdz: heh! no. nothing that fancy! this is hacky to the maximum extent possible.
<seb128> Mez: what?
<Kamion> highvoltage: you don't consider revision control systems to be totally basic? :-)
<Mez> seb128, I jsut installed gnome-pkg-tools and it said the package could not be authenticated, then went and downloaded from an ubuntu archive.
<Mez> whereas normally only packages that cant be authenticated are from kubuntu/backportsd
<seb128> Mez: the authentification is for the mirror, not the packages
<Mez> seb128, yes, but i;m wondering why the mirror is authenticating wrong... or if that package has been compromised
<ogra> Mez, did you apt-get update before the installation of gnome-pkg-tools ?
<seb128> try to install an another package ...
<highvoltage> Kamion: well, no one worked on it besides me, and I didn't have an internet connection while working on it, and I had a few minutes a day to work on it, so I didn't even think of a revision system at the time
<Mez> ogra... i did one this morning...
<Mez> (am on hoary)
<Kamion> highvoltage: I find that using a revision control system makes me much more relaxed about making big changes to code, on the grounds that I know I've still got the last working version
<ogra> Mez, 1. try another package and reproduce, 2. run apt-get update and see it vanish for the next package :)
<Mez> meh t'works now
<Mez> it was onlt that package  - lol
<Mez> weird
<highvoltage> Kamion: you're right.
<Mez> hmm
<Mez> why is debian/rules modifying debian/control
<Kamion> some debian/control files are generated
<Kamion> sometimes this is extremely scary and wrong, sometimes only mildly scary
<Kamion> depending on which parts of the file are generated
<ogra> but still not right :)
<bddebian2> Heh
<Kamion> well, there are only certain bits which will get you into trouble
<Kamion> like build-dependencies
<Mez> hmm
<Kamion> fiddling with the binary stanzas is generally ok, if you're very careful
* ogra did give up counting how often he fell into the control.in trap
<Mez> I foudn out why - it does weird things from control.in
<Kamion> but it's a "dire emergencies only" option
* Mez just found it :d
<Mez> I'm backporting epiphany which depends on firefox ... it's mozilla-firefox in hoary :D
<highvoltage> http://edubuntu.org/Preview_Wallpaper_Examples
<Mez> unless someone wants to add pseudo packages to hoary for firefox to point to mozilla-firefox ;)
<Mez> highvoltage, nice but... the logo /could/ be considered sexist
<ogra> highvoltage, i think the logo still needs fixing... the e needs to move nearer to the d
<ogra> highvoltage, but they look cool
<mdz> Mez: beg your pardon?
<highvoltage> Mez: how is it sexist?
<Mez> lol - symbology :D the "hand" bit could be concieved as a phallus :P
<Kamion> Mez: I'll echo the general "eh?"
<Kamion> I think if you equate hands with phalluses ... well. :-)
* ogra joins the choir
<Mez> (sorry been reading a lot of symbology books recently)
<Mez> kamion - I just saw the bit sticking up... and thought that... didnt see the rest of the logo
<highvoltage> hehe
* Mez shuts up
<highvoltage> mdz: have you played with privoxy before?
<stratus> fabbione, any hint on #12417 ?
<mdz> highvoltage: no, ogra mentioned it today
<highvoltage> it's really cool, I would highly recommend that you look at it.
<mdz> highvoltage: unless it's obviously superior to what the community is already using, I don't think we should change now
<mdz> we've held two discussions about content filtering, and both times people have said "squidguard or dansguardian"
<highvoltage> it has a web interface, small footprint, it's based on internet junkbuster...
<fabbione> stratus: no. this is the latest driver/firmware set from upstream.
<highvoltage> i think it's fine if we stick with dansgaurdian/squid. I still urge you to look at privoxy, though.
<coolio> hi matt- thought we will still have a beer but only return at 12h00 last night
<fabbione> and i don't own any of thes ipw2x00 hw.. so for me it's a jump in the empty space each time
<highvoltage> mdz: sorry, i shouldn't be giving you more work, please ignore me :)
<mdz> coolio: do you leave with jonathan?
<mdz> fabbione: they're very popular; it should be no problem at all to find testers
<mdz> I can see five of them from where I am sitting right now
<chrissturm> fabbione, someone commented on the bug that he fixed it by compiling the upstream driver. maybe it has to do with the patches that are applied
<coolio> yep I cant wait-we are at the hotel till 18h00
<fabbione> mdz: i know that.. but i can't fix with blind uploads
<fabbione> chrissturm: that's the ipw2100
<fabbione> chrissturm: and it's a known problem
<mdz> fabbione: there is no way that you can test every driver; sometimes (especially before UVF) you need to trust upstream and let the community test
<fabbione> mdz: this is the last version of the drivers..
<Kamion> UVF is tomorrow
<chrissturm> fabbione, sorry, i thought that was the 2100 bug again
<mdz> Kamion: UVF is Thursday
<fabbione> and both upstreams are broken because they are focusing in getting the drivers upstream for .13
* Kamion deconfuses himself. Right.
<mdz> we are under the new Thursday World Order, or TWO
<fabbione> so the situation is a mess
<fabbione> because upstream they merged the wrong ieee8* layer
<Kamion> yeah, I'd forgotten about the Thursday change, despite writing it up :-)
<fabbione> and the overall doesn't make our life simpler
<fabbione> mdz: we never really respected UVF for kernel drivers exactly for the above reasons
<fabbione> stratus: you can try to compile the ipw2200 from the sf.net site and see if it solves?
<fabbione> if that works.. than i suspect something really bad happened at merge time
<siretart> mvo: I don't have real access to my imap folder, so I had to copy n paste my encrypted message around. I hope you could decrypt my message
<stratus> fabbione, yes i can reading the messages above wait..
<jp> :)
<stratus> fabbione, i'll test it now. btw i checked the firmware files and the md5sum files match.
<fabbione> stratus: i am sure the firmwares are ok...
<fabbione> stratus: their update is way simpler than the driver one :)
<stratus> heh ok
<fabbione> stratus: anyway if it works or not.. add a comment to the bug.. i will be off soon
<fabbione> stratus: and i will look at it tomorrow
<stratus> i'll let you know, thanks
<fabbione> thanks for checking
<stratus> np
* fabbione heads offline
* stratus downloading kernel headers
<stratus> :)
<carlos> doko, around?
<carlos> doko, you are in charge of gcc, right?
<carlos> ok, question solved
<{Seb}> sorry to ask but....is x still broken?
<{Seb}> after doing an upgrade last night, it said that an executable called 'X' could not be found
<chrissturm> {Seb}, it works for me on my ati card and its broken for me on i810
<{Seb}> mine are atis
<chrissturm> /usr/bin/X
<chrissturm> chi% ls -l /usr/bin/X
<chrissturm> lrwxrwxrwx  1 root root 14 2005-07-04 01:19 /usr/bin/X -> ../X11R6/bin/X
<chrissturm> oops, sorry
<carstenh> jbailey: ping
<jbailey> carstenh: pong - still moving furniture and stuff, so I'm *very* laggy.
<bddebian2> jbailey: You are moving again?
<carstenh> jbailey: hi, nothing important. we can also talk tomorrow
<jbailey> bddebian2: Eh?
<jbailey> bddebian2: This is my first move in the last 4 years.
<bddebian2> jbailey: NM. :-)
<bddebian2> jbailey: Oh for some reason I thought you moved recently.
<jbailey> carstenh: If you can email me, I'll catch up on that this evening.
<jbailey> We went out to buy some stuff and shower curtains and stuff.  
<bddebian2> ahh
<bddebian2> Well get back to work then. :-)
<mxpxpod> jbailey: ping
<jbailey> mxpxpod: See above. =)  very laggy.
<mxpxpod> jbailey: yeah, I saw that :)... just wondering if you know what "R_PPC_REL24 relocation at 0x0ff77fc8 for symbol
<mxpxpod> `malloc' out of range" means
<carstenh> jbailey: as i already said, nothing important. i just wanted to ask if it would make sense wo work with the GraphicalConfigTools-project together or if i should extend gnome-system-tools
<jbailey> mxpxpod: It means your binutils or gcc is having issues and you should treat it nicer.  What arch?
<jbailey> oh, pcc
<jbailey> ppc
<jbailey> duh. =)
<mxpxpod> :)
<jbailey> Pardon me, I'm tired. =)
<mxpxpod> it's happening with libwnck
<mxpxpod> with the workspace switcher applet
<jbailey> carstenh: The trick is that you need to finish by the end of August right?  (And earlier in order to make the Breezy target)
<jbailey> I'm guessing that the backend logic is probably the same all around, and that gst might have some extensibility options you can play with.
<carstenh> jbailey: yes GraphicalConfigTools is a SoC-project too
<jbailey> So that way you're losing very little.
<jbailey> Oh, is it?
<jbailey> Hmm
<carstenh> yes
<carstenh> who is gst?
<mxpxpod> gst == gstreamer
<jbailey> I don't know who's involved with that, but I usually try to avoid tying my vapourware projects with other people's vapourware projects.  It makes it harder to make them come true.
<jbailey> gnome system tools
<jbailey> sorry
<mxpxpod> oh, right
<mxpxpod> don't mind me
<carstenh> but don't know what excatly they planned
<jbailey> That's what I mean.
<jbailey> You tie yourself to someone else's development cycle then.
<carstenh> jbailey: ok, thanks. then i'll extend gst :)
<jbailey> It would be good if you think of the code as needing to eventually go somewhere else (so don't play with gst internals more than absolutely necessary) and that way it can be integrated later.
<jbailey> But given your timeframe, I wouldn't rely on a project that's due at the same time as yours.
<carstenh> yes, good point :)
<carstenh> jbailey: thanks for your time :)
<jbailey> Anytime, sorry for the poor timing of my move. =)
<mxpxpod> jbailey: you're forgiven this time ;)
<jbailey> mxpxpod: ;)
<mxpxpod> jbailey: does binutils affect runtime?
<jbailey> mxpxpod: So what were you doing to your box to get a reloc error on malloc?
<mxpxpod> jbailey: umm, I installed breezy and whammo
<mxpxpod> everything else works, though
<mxpxpod> which is really strange
<mxpxpod> it's only on libwnck
<jbailey> What app gave you this?
<jbailey> Oy.
<mxpxpod> workspace-switcher applet
<mxpxpod> hold on, I filed a bug
<jbailey> I haven't assemlbed my boxes yet.
<mxpxpod> https://bugzilla.ubuntu.com/show_bug.cgi?id=12241
<jbailey> (or my desk for that matter.  I'm on my laptop on the floor)
<mxpxpod> ignore my last post because I'm an idiot and I don't know what I'm talking about
<mxpxpod> jbailey: a new version of libwnck came out and I'm getting a relocation error on a new symbol
<jbailey> I'd have to take a look at it, but it sounds like some sort of evilness in gcc/glibc/binutils rather than something in libwnck.
<jbailey> Unless they've done some linker magic of some sort in there.
<mxpxpod> jbailey: XextRemoveDisplay
<jbailey> But I'll need to reproduce and take a look with readelf.
<mxpxpod> what's readelf?
<jbailey> binutils tool that disects the linker bits in a program or library.
<jbailey> You can learn alot about how the program is structured that way.
<jbailey> Try "readelf -a /bin/ls" for instance.
<jbailey> (Might want to feed it through less)
<mxpxpod> hmm
<jbailey> You can see which module defines which symbols, which ones are defined, not, weakly or strongly.
<mxpxpod> that's interesting
<mxpxpod> well, I reinstalled glibc from archives.ubuntu.com (after deleting the one from /var/cache/apt/archives) and that didn't solve it
<mxpxpod> so I don't think it's a glibc issue
<mxpxpod> jbailey: and I seem to be the only one suffering from this problem
<jbailey> Oh, so the question is whether you've got something strayin lying in your path.
<mxpxpod> jbailey: I think... but I'd be curious to see if this happens to you
<jbailey> Yeah, I should have at least one ppc box up by the end of the night.  Both by midday tomorrow at the latest.
<mxpxpod> sweet
<mxpxpod> jbailey: when's "the end of the night"?
<jbailey> Hopefully 6 to 8 hours from now.
<mxpxpod> sweet
<mxpxpod> jbailey: binutils doesn't affect runtime, does it?
<jbailey> No, it's compile time.
<mxpxpod> ok
<mxpxpod> so reinstalling it wouldn't affect the relocation I'm getting
<jbailey> No.
<jbailey> But it should also affect others.
<mxpxpod> see, that's what gets me
<jbailey> Is this an Ubuntu chroot on a Debian system, or a full Ubuntu system?
<mxpxpod> full ubuntu
<jbailey> 'k, so it's not a strange mismatch there then.
<mxpxpod> right
<malex> Hi. I am maintaining a package in Debian and also participating in the upstream development of the packaged software. How can I find out who maintains my package in Ubuntu? I would like to talk to that person/people.
<solomarv> malex, do you use ubuntu?
<malex> solomarv: no
<hunger> malex: From what I understand it is maintained by whoever finds the time to do so... ubuntu has way fewer developers than debian.
<solomarv> malex, what package do you maintain?
<hunger> malex: But I am just a hang-on, so I might be wrong:-)
<bddebian-ng> A hang-on?
<malex> solomarv: I use Debian, but a sufficient number of Ubuntu users began appearing on the upstream ML and in the IRC channel that I would like to assist in building up-to-date Ubuntu packages from what I maintain in an upstream repository.
<malex> solomarv: scribus and related packages
<hunger> bddebian-ng: I hang on to ubuntu till I find something better;-)
<bddebian-ng> There's alway Gentoo.. ;-P
<solomarv> no flames
<ivoks> did i hear good? nokia, siemens, ercisson, philips and alcatel are lobbying against software patents?
<ivoks> in the form they are proposed now
<hunger> malex: scribus seems to be in main... so this should be the proper channel...
<hunger> bddebian-ng: I said something better, not  more annoying.
<bddebian-ng> :-)
<solomarv> malex: Olkesandr Moskalenko <malex@tagancha.org> is shows as maintainer. lol, is that you?
<malex> solomarv: So, I guess my questiion could be rephrased to "who should I contact to make them aware of a debian repository I maintain upstream, so they could build more up-to-date packages for ubuntu". This is important to me as Scribus develops fairly fast and it is imperative to stay current. 1.2.1 in the Ubuntu breezy is too old already.
<malex> solomarv: Yes
<malex> solomarv: Oleksandr actually
<solomarv> malex, i know, it was a typo
<malex> solomarv: :)
<solomarv> so malex, you are shown as the maintainer. i don't know how to help you further
<malex> solomarv: How can I make it known to people who build Scribus package for Ubunty about the upstream repository? That's all the help I "need" :)
<chrissturm> malex, you could file a bug
<Riddell> malex: hi
<malex> Riddell: hello
<Riddell> malex: I maintain Kubuntu so I'm happy to look after scribus packages
<malex> Riddell: I have a wiki page in the upstream wiki: http://wiki.scribus.net/index.php/Scribus_on_Debian_GNU/Linux Would that be a sufficient starting point?
<Riddell> malex: cool, how far behind is ubuntu just now?
<Riddell> 1.2.1-1
<Riddell> malex: what's on http://debian.scribus.net/debian/ and what's on http://debian.tagancha.org/ ?
<malex> Riddell: 1.2.1 is _too_ old. 1.2.2.1 was just released and I track cvs changes at least once a week.
<malex> Riddell: I don't upload the packages into Debian very often as I'm still in Damination (waiting for debian account creation basically) and need a sponsor for that, but I keep my upstream repositories very current.
<malex> Riddell: debian.scribus.net is a primary and debian.tagancha.org is a backup upstream repositories I maintain. They are synchronized on every package upload, i.e. identical.
<malex> Riddell: We had a discussion among scribus devz about different distros and I thought I'd try to get scribus to be more current in Ubuntu :)
<malex> Riddell: scribus-cvs mentioned in the wiki page is actually a non-policy conformant (installs into /usr/local for parallel use with scribus 1.2.x) package of the developmental series (1.3cvs). Quite a few people are interested in it, so I package it upstream only.
<Riddell> malex: I don't see 1.2.2.1
<malex> Riddell: I patched 1.2.2 as the 1.2.2.1 tarball wasn't ready, yet. So, 1.2.2-2 is the fixed version of 1.2.2-1.
<malex> Riddell: See 02-pageitem.cpp.patch in "debian/patches".
<Riddell> malex: so 1.2.2-2 is effectivly 1.2.2.1?
<malex> yes
<Riddell> malex: are you going to make 1.2.2.1 packages?
<malex> Riddell: I think it's a good idea to avoid users asking "where is 1.2.2.1?". Though the upstream repos will be 1.2.2+cvs200507xx within a week, I expect. The way to 1.2.3 has already begun.
<pitti> seb128: does serpentine actually work for you?
<pitti> seb128: when I click on "write CD", nothing happens
<ogra> pitti, it works for a bunch of people
<seb128> pitti: nop
<Riddell> malex: can you poke me when you have 1.2.2.1 packages and I'll test and upload them to ubuntu
<malex> Riddell: sure. ttyl.
<seb128> pitti: I keep saying we have almost no feedback on it ...
<ogra> pitti, in fact i heard this release solves the bugs in ubuntus bugzilla...
<seb128> pitti: it was broken by gnome-python for some time and we didn't even get a bug about it, I doubt somebody actually uses it
<ogra> seb128, i get a lot of feedback in#ubuntu-motu
<pitti> when I insert a CD, I'm asked what to burn, I click on "audio", nothing happens
<ogra> tseng was the last who reported it working to me iirc
<pitti> so I started serpentine manually, but burning doesn't work eitehr
<tseng> i reported it not crashing :)
<seb128> ogra: and you have not bugged when it got broken by nautilus-cd-burner changes?
<ogra> seb128, i havent burned anything the last 3 weeks ....
<seb128> k, and nobody pointed it to you
<seb128> that's what I say
<ogra> nope
<seb128> the userbase is small
<seb128> it can be broken for weeks without anybody noticing
<ogra> i'll make another call on the lists
<seb128> cool
<ogra> lets see how the response is
<ogra> seb128, sorry, i'm currently wearing blinkers and am a bit focused on edubuntu... thats becoming huge...
<seb128> np
<seb128> did you get a reply about the videolan mail?
<ogra> plase poke me heavy if i miss something and thanks ;)
<seb128> don't worry, all is fine
<ogra> nope, but imet hilton in london this weekend, he didnt notice that we go with gstreamer currently
<seb128> if we don't have a lot of feedback on serpentine atm that's probably because people don't need it that much :p
<ogra> heh... then they wont even notice if we remove it again :P
<ogra> but i really wouldnt like to cripple gnomebaker or graveman
<ogra> just to get it in main....
<pitti> bah, I hate my ISP, he fiddled with the port blockers again
<pitti> seb128, ogra: did you say anything after "<pitti> so I started serpentine manually, but burning..."?
<ogra> hmm
<mvo> hehe
<ogra> :)
<mvo> poor pitti ;)
<ogra> at least he seems to keep the ip :)
<ogra> hey pitti
<pitti_> bah, I *really* hate these ISP guys
<pitti_> IRC doesn't work, and they also cut my ssh sessions to my server (where irssi is now running)
<pitti_> ogra, seb128: in any case I know better what's going on
<ogra> fun... dont you use the telecom ? 
<pitti_> ogra: no DSL here, long story
<ogra> iheard they want to provide wlan
<ogra> in all areas where fiber blocks the dsl
<hunger> pitti_: Did you get my mails?
<ogra> pitti_, so whats going on ?
<pitti_> ogra: at the time nothing happens it tries to throw an exception, but the exception constructor takes 3 args, but the exception initialization only provides two
<pitti_> ogra: the exception it tries to raise is about a wrong temporary dir
<ogra> oh
<\sh> hmmm..we should replace konsole with gnome-terminal
<pitti_> ogra: it fetches the temporary dir from some "preferences" structure
<pitti_> ogra: but there is no temp dir key in gconf
<ogra> pitti_, could you bug it ? ustream is on CC aotomaticaly
<ogra> upstream even
<pitti_> ogra: sure, I try to fix it
<pitti_> guys, I guess I'll be pretty much IRC less this evening
<ogra> :(
<pitti_> if there's something urgent, please email me or ping my mobile
<seb128> pitti_: dude, you have already worked your 8 hours today I'm sure, don't worry about not working on the evening :)
<ogra> seb128++
<pitti_> seb128: nope, I was in the cinema in the afternoon :-)
<seb128> elm<TAB>
<seb128> where is elmo? gnome-games-extra-data sync please :p
<pitti_> ogra: it tries to read /apps/serpentine/temporary_dir from gconf, but there is no such key *grumpf*
<seb128> pitti_: you enjoyed the movie?
<ogra> hmm... schema bug
<seb128> pitti_: create it
<pitti_> seb128: Star Wars 3, yes, was quite good :-)
<pitti_> ogra: how can that work for some people?
<seb128> serpentine has no schemas
<ogra> seb128, it has here
<seb128> ogra: the source package has no schema on my box
<seb128> ogra: and that's from here I've uploaded the package
<ogra> pitti_, i guess it was in an older version....
<ogra> seb128, i have a schema
<seb128> ogra: dpkg -L serpentine | grep schemas ?
<ogra> on a machine i deinstalled serpentine....
<ogra> so it was in an old version
<ogra> and is missing now
<seb128> 0.5 and 0.6.1 have no schemas
<seb128> where is your schemas ?
<ogra> where do the gconf keys come from then ? 
<seb128> the app can set them on first start
<seb128> to know if you have a schema use gconf-editor and browser /schemas
<pitti_> now I at least fixed the exception
<pitti_> and get a proper error dialog that tells me about the missing cache directory
<ogra> ah, yes, seb128 youre right, there is no schema, but /home/ogra/.gconf/apps/serpentine/%gconf.xml
<seb128> pitti_: 
<seb128> $ gconftool-2 -R /apps/serpentine
<seb128>  use_max_speed = true
<seb128>  eject = false
<seb128>  view_toolbar = true
<seb128>  specify_speed = false
<seb128> temporary_dir = file:///tmp
<seb128>  write_speed = 1
<pitti_> $ gconftool-2 -R /apps/serpentine
<pitti_>  eject = true
<pitti_>  view_toolbar = true
<pitti_>  write_speed = 24
<seb128> booooog
<ogra> beeh
<pitti_> bah, no debian/patches
<bddebian-ng> "Ah, I see you have the machine that goes bing"
<seb128>   File "/usr/lib/python2.4/site-packages/serpentine/common.py", line 118, in validate_music_list
<seb128>     raise SerpentineCacheError (SerpentineCacheError.INVALID, "Please "    \
<seb128> TypeError: __init__() takes exactly 2 arguments (3 given)
<seb128> 
<pitti_> seb128: right, that's the bug I just fixed
<seb128> I get that here when clicking on the record icon
<seb128> $ gconftool-2 -R /apps/serpentine
<seb128>  eject = true
<seb128>  view_toolbar = true
<seb128>  write_speed = 48
<seb128> 
<seb128> after cleaning my gconf
<seb128> so the new version doesn't write correctly the config
<ogra> yep
<seb128> and it doesn't use a schemas
<ogra> it really should...
<comadreja> I need some help, I'm trying to debug totem because of bug 11693
<comadreja> my problem is, even when I pass CFLAGS="-g -O0" to configure
<comadreja> I get no debugging symbols
<comadreja> oh, I see
<comadreja> nostrip, right ?
<bddebian-ng> Yep
<comadreja> thanks
<pitti_> ogra: I uploaded a version with the fixed exception for now
<ogra> pitti_, wow, thanks :)
<pitti_> now I debug the temp dir
<bddebian-ng> Hello sabdfl
<comadreja> what's the proper place to set DEB_BUILD_OPTIONS ?
<\sh> when is meeting? 22UTC?
<mdke> \sh, yes
<\sh> mdke: thx
<sabdfl> hiya bddebian-ng
<sabdfl> \sh: in two hours, roughly
<\sh> sabdfl: yeah :) good evening btw
<pitti_> Hey sabdfl 
<sabdfl> hi!
* sabdfl is happy his big launchpad landing landed today
<pitti_> cool, all went well?
<Mez> hey sabdfl, btw - twas nice meeting you (briefly) :P
<pitti_> ogra: *sigh* now I fixed the temp dir issue by providing a fallback value, now it greets me with "converting files to wav failed"
<pitti_> ogra: WTF wrote this? 
<ogra> pitti_, the last version worked better ....
<pitti_> ogra: btw, nowhere in the code the tempdir key is actually written, it's just read without a default
<pitti_> ogra: maybe we should revert to the last version then?
<pitti_> ogra: shall I upload the temp dir fix nevertheless?
<pitti_> or do you want to care for that yourself?
<sabdfl> pitti_: a few glitches, but so far all looks good
* pitti_ smells fresh langpacks
<ogra> pitti_, lets see what upstrem says about it...
<pitti_> ogra: where shall I forward the patches?
<malex> Riddell: I have scribus-1.2.2.1-1 and scribus-doc-1.2.2.1 package in the upstream repos. Thanks.
<ogra> pitti_, bugzille.ubuntu.com ;)
<Riddell> malex: cool :)
<ogra> pitti_, bugzilla indeed
<pitti_> ogra: the funny thing is, there are widget callbacks for adjusting the temp dir, but no widget that calls them
<pitti_> ogra: CC somebody?
<ogra> pitti_, me, if i'm not in the default CC, i dont know if seb128 added me too
<seb128> there is no default Cc:
<seb128> there is 1 assignement and 1 QA
<seb128> the bugs are assigned to the desktop-bugs list and the QA is upstream
<ogra> ah
<pitti_r> ogra: did you ever try to burn ogg files?
<ogra> pitti_r, yep, worked fine when i tried it with v4
<ogra> but its a while ago
<mxpxpod> ogra: you're working on gnome-power, right?
<ogra> mxpxpod, i package it and am in tight contact with upstream, yes
<mxpxpod> ogra: who's the upstream author?
<ogra> richard hughes
<ogra> (hughsie)
<mxpxpod> oh, right
<ogra> he's around from time to time...
<pitti_r> ogra: it seems that it uses gstreamer to convert ogg files, and I do have gstreamer0.8-vorbis installed...
* ogra glares at the copyright file of squeak.... phew
<ogra> pitti_r, hmm, packaging bug then...
<pitti_r> ogra: hm?
<ogra> oh, i read dont for do
<pitti_r> ogra: WARNING: erroneous pipeline: could not link audioscale0 to wavenc0
<pitti_r> ogra: maybe they should test their gstreamer pipelines before using them...
<ogra> hmm... incompatible gstreamer version probably...
<pitti_r> ogra: if I remove the audioscale from the pipe, it works with gst-launch
<ogra> hmm
<pitti_r> WOW
<pitti_r> it actually prepares my disc now!!!
<ogra> yay
<ogra> pitti_r, you can run it with -s for simlation mode
<pitti_r> ogra: it's still dumb, rather than piping the wavs directly to cdrecord and burn it track-wise, it dumps 650 MB in my /tmp...
<ogra> it desnt use cdrecord directly
<pitti_r> ogra: oh, I actually *want* that CD burned, that's why I started that stuff in the first place :-)
<ogra> it uses nautilus-cd-burner
<mxpxpod> pitti_r: since nautilus-cd-burner uses cdrecord, it doesn't do piping
<pitti_r> that sucks
<mxpxpod> yea, it does
<pitti_r> there's no reason for 650 MB of files in /tmp, that will break people's tmpfs horribly
<mxpxpod> which is why after my next release of coaster, I'm going to do a rewrite of libburn so we can get on-the-fly cd burning within applications
<ogra> mxpxpod, so fix coaster :) i would have loved to discuss it as alternative...
<mxpxpod> ogra: cdrecord sucks
<ogra> i know
<pitti_r> ogra: would you mind if I add a dependency to gstreamer0.8-vorbis?
<mxpxpod> until we get a library that does the burning nicely, cd recording on linux will suck
<ogra> but we're lacking alternatives
<mdke> elmo isn't around?
<\sh> who is responsible for the wiki?
<ogra> pitti_r, absolutely not :)
<mxpxpod> that's why I'm going to work on a rewrite of libburn
<mxpxpod> pitti_r: why not make it a suggestion?
<mdke> \sh, we have some pages for bugs and recommendations
<mdke> \sh, https://wiki.ubuntu.com/wiki
<mxpxpod> ogra: by friday, I hope to have a new release of coaster that does audio
<pitti_r> mxpxpod: well, Recommends: would be appropriate IMHO
<mxpxpod> pitti_r: oh, right
<mxpxpod> ogra: so, it will cover what n-c-b and serpentine do
<mdke> \sh, or is it something else?
<\sh> mdke: i'm searching a rename function ;)
<\sh> rename page or something like this
<ogra> mxpxpod, yeps :) do you use gstreamer to convert the audio ? 
<mdke> \sh, its under "Rename" ;) in Other actions
<mxpxpod> ogra: of course :)
<ogra> yay
<mdke> \sh, BUT!
<mdke> \sh, use it with care, links will break
<\sh> mdke: yeah:) it's a user page for bddebian ;)
<mxpxpod> ogra: and once the libburn rewrite is done, it will go audio file->gstreamer->libburn->disc
<ogra> cool
<mxpxpod> and data file->libburn->disc
<mdke> \sh, heh, ok for the future though, you can see all links by clicking on the page title
<mxpxpod> no more temporary crap
<ogra> yeah
<\sh> mdke: thx :)
<mdke> \sh, np
<mxpxpod> ogra: the problem I'm having is an endianness issue... libburn will do on-the-fly burning from data on i386, but on powerpc it makes coasters (no pun intended)
<ogra> hmm
<pitti_r> TypeError: __on_progress() takes exactly 3 arguments (4 given)
<pitti_r> OMG
<mxpxpod> so I think I'm going to tear it apart and start over from scratch and make it a sane library
<\sh> mdke: sometimes I'm really a noob with webapps, even I'm helping to develop them ;)
<mxpxpod> right now it has all of its functions crammed into one header
<mxpxpod> and it doesn't use typedefs for its structs
<mdke> \sh, no problem. You can always email ubuntu-doc if no one answers
<mxpxpod> ogra: so my next big endeavor is the libburn rewrite
<mxpxpod> which should be "fun"
<mxpxpod> :D
<ogra> heh
<mxpxpod> but if I set it up correctly, it shouldn't be too hard
<mxpxpod> and a friend and I have talked about making libburn into libdisc which would give linux 1:1 reading/writing on all discs
<mxpxpod> and then making it into a simple plugin architecture to add new read/write methods
<ogra> sabdfl, squeak is completely under apple license, its not only the fonts ...
<ogra> This is the Squeak package for Debian.  All debianisations are
<ogra> Copyright (C) 2002 Lex Spoon and are released under Apple, Inc.'s license
<ogra> for Squeak.  A copy of this license is included below.
<ogra> :(
<pitti_r> ogra: yay, it indeed burned the CD, and it even seems to work :-)
<ogra> great
<ogra> pitti_r, and we have still plenty of time until release to fix remaining bugs in it... :)
<pitti_r> like, make it work in a sane fashion? :-)
<ogra> yeah
<ogra> its only python ;)
<pitti_r> ogra: it should rather use cdrecord directly for piping
<ogra> i'll mail upstream and aks if he can implement it
<pitti_r> ogra: I have a small shell script that does the same (burn a set of mp3/ogg to an audio cd) which directly calls cdrecord, and it works just great
<mxpxpod> pitti_r: how big is your shell script?
<pitti_r> mxpxpod: 10 lines of bash
<mxpxpod> pitti_r: can you query it to me?
<pitti_r> mxpxpod: http://www.piware.de/tools/burnmusiccd
<mxpxpod> pitti_r: so, that doesn't do dao, right?
<ogra> pitti_r, cool.....
<pitti_r> mxpxpod: no, why should I want that?
<mxpxpod> pitti_r: because if I'm burning an entire album that I've ripped, I'd want that
<mxpxpod> I don't like gaps where there shouldn't be
<pitti_r> mxpxpod: well, I usually want pauses between the tracks, but I see the point
<mxpxpod> :)
<mxpxpod> also, do you have a method of copying one audio cd to another?
<pitti_r> mxpxpod: however, in C/python/whatever, a "pipe multiplexer" is easy, it's just a pain in bash
<mxpxpod> pipe multiplexer?
<pitti_r> mxpxpod: call oggdec/mpg123 one after the other, take their outputs and concat their outputs into a cdrecord pipe
<mxpxpod> oh, so store their outputs in memory, basically
<pitti_r> mxpxpod: I usually did cdparanoia, "wavcut" (small program of me that cuts away silence), then cdrecord
<pitti_r> mxpxpod: but I don't do that very often, so I didn't write a script for that so far
<mdke> [OT]  EU software patents news http://www.groklaw.net/article.php?story=20050705130920424
<mxpxpod> can gstreamer output to a variable?
<mxpxpod> pitti_r: well, cdrecord sucks, so I'm going to rewrite libburn to a useable state
<pitti_r> mxpxpod: that's right :-)
<mxpxpod> pitti_r: is there a way to use cdrecord with a pipe from mkisofs so you don't have to have an intermediate iso?
<pitti_r> mxpxpod: sure, that's the way I always burned data cds at the command line
<pitti_r> mxpxpod: mkisofs ... | cdrecord -data -
<mxpxpod> hrmmm
<mxpxpod> so why the heck am I using an intermediate iso...
<mxpxpod> and why does libnautilus-burn?
<pitti_r> no idea :-)
<mxpxpod> me either
<pitti_r> I don't do intermediate ISOs any more since my althlon 500, which was already magnitudes faster than necessary for on-the-fly pipe burning
<pitti_r> mxpxpod: the only advantage is that you  can test loop-mount the iso before burning
<mxpxpod> now, if the user has a slow system... can the pipe be a problem?
<pitti_r> sure, maybe on a Pentium-100 class
<pitti_r> if mkisofs uses too much I/O
<pitti_r> then the cdrecord output could underrun
<pitti_r> but that's not an issue on today's computers, so it should be optional
<mxpxpod> pitti_r: man, it would be sweet if I could get coaster to do on-the-fly burning for data and maybe audio
<mxpxpod> I'll have to see about that tonight
<sabdfl> ogra: what is the apple licence?
<Burgundavia> sabdfl, APSL, OSI approved, but not considered DFSG-free
<ogra> sabdfl, i'll mail it to you... its mainly saying that the shipped fonts may not be modified... 
<sabdfl> ogra: it's redistributable though?
<ogra> sabdfl, but the software may
<ogra> yep
<ogra> looks like, its just ugly....
<sabdfl> seems ok for edubuntu
<ogra> and i dont know if it clashes with the GPL anyhow
<ogra> but it shouldnt...
<lamont__> Kamion: ping
<comadreja> daniels, you there ?
<daniels> comadreja: sup
<comadreja> daniels : it's about bug 11693
<comadreja> daniels : I've been trying to debug it
<daniels> oh, cool
<comadreja> daniels : I first thought it was an audio problem, (mplayer crashed at audio_decode, and if you disabled audio video worked fine)
<daniels> what've you got so far?
<comadreja> daniels : then I tried xine... and I got audio, but a blue a screen as video
<daniels> right, that would be an xvideo problem
<comadreja> daniels : totem died with a BadAlloc problem
<daniels> do you have enough video RAM?
<comadreja> funny thing is, I downloaded mplayer from mplayerhq
<comadreja> when I compiled it, it worked fine
<comadreja> So my guess right now is that it is an i810 X problem
<comadreja> probably glx
<bddebian> AGPGART?
<daniels> comadreja: was the mplayer from mplayerhq definitely using xv?
<daniels> comadreja: gl wouldn't be causing problems with xvideo
<comadreja> daniels : let me check
<comadreja> daniels : -vo x11 works
<comadreja> daniels : but with ubuntu package it doesn't
<comadreja> I get this:
<comadreja> MPlayer interrupted by signal 11 in module: decode_audio
<comadreja> - MPlayer crashed by bad usage of CPU/FPU/RAM.
<comadreja> it's probably the async video problem, is that possible ?
<daniels> so if mplayer crashes with -vo x11, that's mplayer's problem
<daniels> the only X problem is where something works with -vo x11 but fails with -vo xv
<comadreja> but xine fails too, and totem too
<daniels> if anything works with plain X and fails with Xv, that's an Xv bug
<comadreja> I don't know if mplayer fails with xv...
#ubuntu-devel 2006-07-03
<Keybuk> hey Tollef
<\sh> Keybuk: it's ok for you (for sync request) if one motu is saying that "it's ok to sync"?
<Keybuk> yup
<\sh> Keybuk: kk..you got them :)
<Keybuk> \sh: is just a "sponsor" formality basically
<bddebian> Howdy
<\sh> Keybuk: no problem :) I just working on some merges and syncs while I'm bored ;)
<\sh> Preparing to replace libc6 2.4-1ubuntu4 (using .../libc6_2.4-1ubuntu6_i386.deb) ...
<\sh> touch: setting times of `/etc/ld.so.nohwcap': Function not implemented
<\sh> dpkg: error processing /var/cache/apt/archives/libc6_2.4-1ubuntu6_i386.deb (--unpack):
<\sh> hmmm...known ?
<\sh> or is my chroot broken?
<Keybuk> dunno, what filesystem?
<bddebian> Keybuk: Sorry about the sync requests, apparently I have a pbuilder problem :-(
<\sh> Keybuk: xfs
<Keybuk> bddebian: which ones?
<\sh> moment...recreating chroot
<bddebian> gnome-build and gdl
<Keybuk> bddebian: I don't tend to look at the name unless it works :p
<Keybuk> ah, yeah
<bddebian> OK, so how do I figure out where this .la file dependency coming from?  I don't see it in ltmain.sh
<Keybuk> "la file dependency" ?
<bddebian> Sorry.  ajunta is looking for /usr/lib/libwnck.la which is no longer in the libnwck-1-dev package
<Keybuk> then another library it uses has libwnck as a dependency
<Keybuk> grep "libwnck" /usr/lib/*.la
<bddebian> But the only place I can find reference to it is in another .la
<Keybuk> right
<\sh> bddebian: that's the bugger then ;)
<bddebian> Keybuk: I did that but the .la files are generated are they not?
<Keybuk> they're generated when the package is built
<Keybuk> so if a dependency of anjuta's hasn't been rebuilt, it may still be depending on libwnck
<\sh> bddebian: mostly a rebuild of the broken package which has the wrong .la does help
<bddebian> Grrr
<bddebian> The ajunta author doesn't even build-dep libwnck
<Keybuk> there should be a way to store dependencies inside .a files
<Keybuk> then we wouldn't need .la files
<Keybuk> bddebian: he almost certainly doesn't need to
<bddebian> No?
<DaSkreech> Whats up with libcairo2?
<Keybuk> DaSkreech: why don't you tell us?
<DaSkreech> It's set to be upgraded but doing so breaks my system
<Keybuk> how does your system break?
<DaSkreech> Should it be set to upgradeable if it's breaky?
<DaSkreech> Adept freaks
<Keybuk> "freaks"
<DaSkreech> It complains about package conflicts
<Keybuk> edgy right?
<DaSkreech> Unfortunately no
<DaSkreech> I'm on Dapper
<Keybuk> what's the conflict?
<bddebian> \sh: ajunta is the broken package but it looks for /usr/lib/libnwck.la
<Keybuk> we need explicit, accurate, verbose, details
<DaSkreech>  And it's jumping from version 1.1 to 1.2
<Keybuk> not wishy-washy hand-wavy things like "freaks" and "breaks"
<DaSkreech> I'm looking it up now
<DaSkreech> :-) I just wanted to know if it was a known thing :)
<\sh> bddebian: as I said, someone else depends on libnwck and it wasn't rebuild
<bddebian> \sh: Sorry, I don't understand that
<Keybuk> bddebian: just accept it
<Keybuk> you don't need to understand it
<bddebian> I don't?
<\sh> bddebian: if libwnck.la is not there anymore, and it shouldn't be there, there is another build-dep of anjuta, which is not rebuild, because it points to this .la file
<bddebian> Ahhh, OK
<\sh> bddebian: now, cd /usr/lib/ ; grep "libwnck.la" *.la
<\sh> and you will find this lib which is using still "libwnck.la", then try to rebuild the package which provides this .la and try again
<bddebian> No, it's an .la inside ajunta, I already know that
<bddebian> devhelper.la or some such
<Keybuk> oh, and libtool's picking up the installed anjuta's .la file? :p
<Keybuk> and using it when rebuilding anjuta itself
<bddebian> No libtool is failing becuase it isn't install either :-)
<Keybuk> eh?
<\sh> bddebian: give me a few minutes, and I have a look at it. ok_
<Keybuk> now you're flat-out making no sense
<\sh> ?
* \sh missed all that
<bddebian> Keybuk: sed: /usr/lib/libwnck.la no such file or directory
<bddebian> then libtool: command not found
<Keybuk> ?!  why you using sed?!
<Keybuk> \sh asked you to use grep!
<bddebian> I am not
<bddebian> Ohh, I am talking about the package
<Keybuk> we've already told you, it's nothing to do with anjuta
<\sh> bddebian: forget anjuta for a moment...use a chroot and install all build-deps of anjuta
<Keybuk> anjuta is just linking to a broken library
<Keybuk> it's that broken library that needs to be fixed
<Keybuk> then anjuta will work
<Keybuk> so ignore anjuta
<bddebian> And I am telling you it is a .la in anjuta itself
<bddebian> I have the build deps and no .la files in /usr/lib use libwnck.la
<Keybuk> no it's not
<Keybuk> if you're not going to listen, I'm not going to help you any more
<\sh> bddebian: but you told us, that anjuta doesn't depend on anything which is libwnk
<bddebian> \sh: No, I said the author doesn't build-dep libwnck
<bddebian> It is a bug on BTS
<\sh> bddebian: there...
<bddebian> plugins/devhelp/libanjuta-devhelp.la:dependency_libs=
<bddebian> Keybuk: I'm not trying to be difficult
<Keybuk> bddebian: shut up
<Keybuk> yes you are
<Keybuk> you're asking for help, and not listening to people who are trying to help you
<bddebian> Well I'm trying to but apparently not explaining myself well
<Keybuk> you're explaining yourself just fine
<Keybuk> we just know better than you
<Keybuk> but you won't let us teach you
<bddebian> OK
* bddebian shuts up
<Keybuk> good
<Keybuk> now; grep "libwnck" /usr/lib/*.la
<bddebian> I did.  No hits
<Keybuk> ok, grep -r "-lwnck" .
<Keybuk> (in the anjuta source tree)
<bddebian> Yields the file I posted above
<bddebian> plugins/devhelp/libanjuta-devhelp.la:dependency_libs=
<Keybuk> no
<Keybuk> it's not that file
<Keybuk> another one
<Keybuk> keep looking
<Keybuk> actually, also grep "-lwnck" /usr/lib/*.la
<Keybuk> you'll have to grep -- "-lwnck" obviously
<Keybuk> any hits?
<bddebian> Nothing matches -lwnck unless I am doing something majorly incorrect
<Keybuk> right
<Keybuk> hmm
<Keybuk> grep "wnck" /usr/lib/*.la
<Keybuk> any hits for that?
<\sh> I'm checking
<bddebian> Oh, glad maybe
<bddebian> /usr/lib/libdevhelp-1.la:
<Keybuk> aha
<Keybuk> that's a good candidate
<bddebian> shit, bbias, sorry
<\sh>  /usr/lib/libdevhelp-1.la:dependency_libs=' -R/usr/lib/firefox -L/usr/lib/firefox /usr/lib/libglade-2.0.la /usr/lib/libxml2.la /usr/lib/libpangoxft-1.0.la /usr/lib/libpangox-1.0.la /usr/lib/libxml2.la /usr/lib/libwnck-1.la /usr/lib/libgtk-x11-2.0.la /usr/lib/libstartup-notification-1.la -L/usr/X11R6/lib -lSM -lICE -lXRes /usr/lib/libgtk-x11-2.0.la /usr/lib/libgdk-x11-2.0.la /usr/lib/libatk-1.0.la /usr/lib/libgdk-x11-2.0.la /usr/lib/libpangocairo
<\sh> a /usr/lib/libatk-1.0.la /usr/lib/libgdk_pixbuf-2.0.la /usr/lib/libpangocairo-1.0.la /usr/lib/libcairo.la /usr/lib/libpangoft2-1.0.la /usr/lib/libpango-1.0.la -lXext -lXinerama -lXi -lXrandr -lXcursor -lXfixes /usr/lib/libpango-1.0.la /usr/lib/libcairo.la -lXrender -lX11 -lpng12 -lfontconfig /usr/lib/libfreetype.la -lz /usr/lib/libgobject-2.0.la /usr/lib/libgconf-2.la /usr/lib/libORBit-2.la /usr/lib/libORBit-2.la /usr/lib/libgmodule-2.0.la /usr/
<\sh> .0.la /usr/lib/libgthread-2.0.la -lm /usr/lib/libgmodule-2.0.la /usr/lib/libgthread-2.0.la /usr/lib/libglib-2.0.la /usr/lib/libglib-2.0.la -lgtkembedmoz -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -ldl'
<\sh> first hit ;)
<\sh> libdevhelp-1-dev: usr/lib/libdevhelp-1.la
<\sh> try to rebuild this first ;)
<bddebian> Gah devhelp is in main
<\sh> bddebian: doesn't matter...did the rebuild worked?
<\sh> devhelp needs to be merged anyways
<\sh> Keybuk: when is mom running and updating the stats pages?
<jsgotangco> good morning
<\sh> hey jsgotangco
<Keybuk> \sh: hourly
<jsgotangco> hi \sh!
<\sh> Keybuk: I just ask because e.g. afterstep is gone from the merges page, but doesn't show up in the "updated merges" section
<Keybuk> is there a new Debian upload then?
<Keybuk> ah, maybe there's confusion
<Keybuk> the top list ("outstanding merges") is things which haven't seen an upload to edgy yet
<Keybuk> so probably haven't been merged ever
<Keybuk> the things in the "updated merges" list HAVE had uploads to edgy
<Keybuk> so have probably been merged
<\sh> Keybuk: afterstep was in the list, I did the merge today, and bddebian uploaded for me :)
<Keybuk> right
<Keybuk> so his upload would have cancelled the need for a merge
<Keybuk> Ubuntu is "up to date"
<\sh> Keybuk: ah you mean, the lower section is "uploaded already just before mom was running"
<Keybuk> when a new Debian upload happens (Ubuntu is out of date) then it'll appear in the "Updated Merges" list
<Keybuk> it's especially important for main
<Keybuk> everything must be merged at least once
<Keybuk> so we want to clear the top list
<Keybuk> and then review the second list for anything important (looking at the version skew)
<Keybuk> and do that list if we have time
<Keybuk> it's impossible to have zero merges, after all :p
<\sh> Keybuk: ah .. now I understand :) 
<\sh> well...some of the main merges are still on my laptop...
<Keybuk> cause if we managed to get them to zero
<Keybuk> then Debian would do some updates that day, and there'd be merges again! :D
<Hobbsee> morning all
<\sh> uh...NMU from debian is wrong 
<licio> here is night :)
<\sh> here is morning...early morning ;)
<Hobbsee> 10am here - monday
<licio> :)
<licio> 21pm here - sunday
<licio> :)
<licio> I'm sleepy
<\sh> 02:11am here - monday
<licio> bye all
<licio> I'm going to bed 
<Hobbsee> night licio 
<licio> Hobbsee, morning :)
<Burgundavia> \sh: flue is a part of the chimney. Flu is the sickness :)
<bddebian> heh
<\sh> Burgundavia: oh damn
<\sh> you see I'm sick ;)
<\sh> fixed
<Burgundavia> \sh_away: no worries
<TTT_Travis> I am trying to compile and this is the error I get after about an hour: http://pastebin.ca/77532
<Lathiat> TTT_Travis: This is the wrong channel for support with that, try #ubuntu
<TTT_Travis> ok
<TTT_Travis> thanks
<pitti> Good morning!
<jsgotangco> hi pitti!
<pitti> hi jsgotangco 
<crimsun> 'morning pitti. When you're less busy, please check the openvpn debdiff on security-review in may 2006 (malone bug 45827)
<Ubugtu> Malone bug 45827 in openvpn "openvpn old security problems (Breezy)" [Medium,In progress]  http://launchpad.net/bugs/45827
<pitti> crimsun: https://lists.ubuntu.com/archives/security-review/2006-May/000405.html ? That looks empty
<pitti> crimsun: and I do not have that in my mailbox for some reason
<pitti> crimsun: maybe you can attach the debdiffs to the bug?
<crimsun> pitti: I'll resend inline (again)
<crimsun> err, attach I mean
<crimsun> sent.
<fabbione> morning
<whiprush> jdub: awake?
<Burgundavia> hey whiprush, shouldn't you be asleep?
<whiprush> Burgundavia: yeah, but it's a holiday here, so long nites, lots of beer, etc. etc.
<Burgundavia> whiprush: ah, you lucky thing. I just left the US, just before the 4th and after the 1st (our holiday) :(
<whiprush> I just picked up the Ubuntu Hacks book (which is excellent btw), and I wanted to blog about it, but I think I'm broken on planet.u.c. :-/
<fabbione> crimsun: ping?
<crimsun> fabbione: pong (sorry, phone)
<fabbione> crimsun: did you coordinate your xorg-server upload to dapper-updates with somebody from the x team?
<crimsun> fabbione: that was an accidental upload, and I asked for it to be rejected
<fabbione> ok
<crimsun> fabbione: the correct one was for xserver-xorg-input-mouse, which mdz approved in bug 38272
<Ubugtu> Malone bug 38272 in xserver-xorg-input-mouse "option EmulateWheelTimeout not working" [Medium,Fix released]  http://launchpad.net/bugs/38272
<fabbione> okydoky
<pitti> siretart: ping
<siretart> pitti: morning!
<pitti> siretart: I test and upload the new cdbs now
<pitti> siretart: I just saw that you already merged
<pitti> we need it as build-dep for e. g. pyxdg
<siretart> pitti: it didn't build for me for some reason why I merged it, but I was quite sure that it wasn't because of the merge
<siretart> pitti: anyway, I didn't want to upload untested stuff, which didn't work for me
<siretart> pitti: if it does for you, just upload whats in the bzr branch
<pitti> siretart: I'll do some test builds anyway
<pitti> siretart: all tests passed and the package builds; what failed for you?
<Kagou> hi pitti :) the new print system included in gtk2.10 will be used for edgy ?
<pitti> Kagou: well, the gnome apps certainly will
<Kagou> pitti: we will continu using g-c-m  ?
<pitti> Kagou: if someone comes along and adapts redhat's tool to Ubuntu, we'll gladly use it
<Kagou> ok :)
<fabbione> hey mvo
<pitti> hi ivoks 
<siretart> pitti: the testcase failed in 2 or 3 tests
<fabbione> mvo: you should be good to re-enable selinux support in device-mapper and lvm2
<ivoks> hi pitti 
<siretart> pitti: I didn't have the time to investigate the failure, wanted to do it this weekend, but forgot it. sorry :(
<mvo> fabbione: ok, will do
<fabbione> mvo: you want to do dm first, and lvm2 later with a versioned B-D
<fabbione> mvo: to make sure to build with the right dm
<fabbione> mvo: great thanks
<siretart> pitti: s/testcase/testsuite/
<pitti> siretart: hm, not here; and g-v-m builds fine, doing two other test builds here
<pitti> s/here$/now/
<pitti> doko_: ping
<siretart> anyone knows how often NEW packages from debian are synced to ubuntu/edgy?
<siretart> I know about a package in debian which I'm waiting to appear in edgy for quite some days...
<pitti> siretart: hm, indeed, with the old cdbs installed, the testsuite passes, now with the new one isntalled it fails 3 cases
<siretart> pitti: now I'm a bit confused, because doesn't the cdbs testsuite use the cdbs classes from inside the package?
<pitti> siretart: actually yes
<pitti> siretart: and I just noticed that I installed my debug symbol stripper wrapper; this could cause the regressions
<pitti> dholbach! Guten Morgen, Alter! :-P
<pitti> siretart: ah, that was it. panic mode off then :)
<dholbach> good morning!
<dholbach> hey pitti, ALTER!
<doko> pitti: pong
<dholbach> hey doko
<pitti> doko: will you merge python-support soon? it's required as build-dep of e. g. pyxdg
<pitti> siretart: ok, works fine here with test suite, postgresql, g-v-m, and my debug strip test suite. away with it! :)
<siretart> pitti: excellent
<pitti> siretart: (also tested with dash and bash)
* siretart begins to fall in love with bzr mantained packages :)
<crimsun> they are nice
<doko> pitti: hmm, thought mvo would do it ...
<doko> pitti: anyway, I can do it. 
<pitti> doko: the only difference is that we do not build 2.3 stuff, right?
<pitti> doko: (diff to Debian)
<mvo> doko: oh, that was a misunderstanding, I was asking for it
<pitti> gar, why did I end up having to do the mesa merge?
<Yagisan> pitti: you like the pain ?
<pitti> hi Yagisan 
<Yagisan> G'day pitti. for the -ssp arch. Is is up yet ?
<pitti> wow, and an 1.1 MB ubuntu patch
<pitti> Yagisan: YES!!!!1!!! :-)
<pitti> Yagisan: packages build with ssp on since Friday
<Yagisan> pitti: ok. all packages ?
<pitti> yes, it was globally turned on in gcc
<siretart> pitti: how do you coordinate merges?
<Yagisan> pitti: ok. Could you pm me details, I'll put it on  a production web server
<pitti> siretart: the default claimer is the name on the {main,universe}.html page
<pitti> siretart: if you want to merge something else, ping the default claimer before
<siretart> pitti: so basically the last uploader. I see
<siretart> I was wondering how we'll manage universe
<crimsun> siretart: pretty much the same way, no? I've been going through the ones with my name beside it
<siretart> pitti: thanks for sponsoring ;)
<siretart> crimsun: Let's do so for now, and look in the last week for missing merges
<siretart> crimsun: I fear that there may be poeple less active in edgy than in dapper
<\sh> siretart: I'm doing my merges first, from last time, and then working from top to bottom
<tseng> morn pitti 
<pitti> hi tseng 
<tseng> can you please look at the inclusion report for XSP again?
<tseng> whenever you can.. and tell me if you still want it split up
<pitti> tseng: uh, you really want the web server in main?
<fabbione> uh?
<tseng> not really, no
<pitti> there was a recent vulnerability in it, was that fixed?
<tseng> yes.
<Kamion> crimsun: rejected xorg-server from dapper-updates per request
<tseng> I can fight with Debian about where to put the script, then.
<tseng> discuss nicely, I mean
<pitti> tseng: :)
<crimsun> Kamion: thank you
<Kamion> (and accepted xserver-xorg-input-mouse)
<crimsun> (thank you!)
<\sh> Kamion: thx for the sync
<\sh> s
<pitti> mjg59: ping
<phanatic> Kamion: ping
<mjg59> pitti: Hi
<pitti> mjg59: do you know a bit about mesa? the current MoM merge is nothing but a mess
<Kamion> phanatic: hi
<pitti> Kamion: do you care about libsdl1.2debian-udeb?
<pitti> Kamion: in Debian, it builds a directfb video backend and not much else
<pitti> probably for a graphic installer
<fabbione> pitti: g-i
<Kamion> pitti: not at present, but the graphical installer will eventually want it
<Kamion> should go to universe for now
<pitti> Kamion: so, ok if I disable the package for now?
<Kamion> pitti: sure
<pitti> or universe, works for me as well
<Kamion> I guess you can't build it in main, can you?
<pitti> Kamion: I removed the directfb build-dep
<Kamion> I wouldn't mind sucking the build-deps into main, if we can do that reasonably
<pitti> Kamion: so the udeb is fairly useless for now
<phanatic> Kamion: hi, i had a sponsored upload by siretart to dapper-updates (sysinfoi package) a few weeks ago, but it wasn't approved. is something missing?
<seb128> pitti: what are you trying to kick to universe? directfb?
<pitti> seb128: it's already in universe
<seb128> pitti: because new libcairo and GTK 2.10 I'm about to package needs it
<pitti> oh, ok
<fabbione> pitti: i am afraid it's a useless attempt
<seb128> GTK has a directfb backend now
<fabbione> sooner or later we will suck in g-i
<pitti> alright
<fabbione> and all its dependencies
<Kamion> seb128: I'd very much like that in main; then we can start syncing cdebconf rather than merging it
<pitti> then we'll move directfb into main and I build the sdl udeb
<Kamion> phanatic: looking
<siretart> Kamion: Keybuk said that ubuntu-archive wouldn't know how to sync to dapper-backports, is that right?
<seb128> pitti: could you take care of the main promotion? :)
<phanatic> Kamion: thanks
<pitti> seb128: seems to be fairly harmless anyway
<Kamion> phanatic: it appears to have been manually rejected
<Kamion> phanatic: did neither you nor siretart get mail about it?
<phanatic> Kamion: no, at least i did not
<phanatic> Kamion: why was it rejected?
<Kamion> siretart: I know how to do it, but the script in question has not yet been ported to soyuz; I began work on that last night
<Kamion> phanatic: I don't know; rejects don't have reasons attached to them in the database at present - that's why I was hoping you'd have got mail
<Kamion> mdz: did you reject sysinfo from dapper-updates?
<mjg59> pitti: What's the Debian version now?
<mjg59> pitti: We can probably drop all Ubuntu patches
<pitti> mjg59: 6.4.2-1
<mjg59> Oh, argh. That's going to be awkward.
<pitti> mjg59: even our binary package names do not match
<Kamion> phanatic: try sending mail to ubuntu-archive@lists.ubuntu.com to see if any of the other archive admins know
<mjg59> pitti: You'll want to talk to Daniel about binary package names
<pitti> right
<Kamion> phanatic: feel free to cite this conversation
<phanatic> Kamion: thanks, i'll do that
<pitti> eventually we need to get back in sync with Debian wrt. X
<mjg59> Any of the patches I added can be dropped
<fabbione> pitti: is that for mesa?
<pitti> mjg59: ah, good to know; thanks!
<pitti> fabbione: yes
<mjg59> We'll fix those up again afterwards
<fabbione> pitti: better you leave it to infinity
<pitti> fabbione: the merge is assigned to me since I added a pot file as last uploader
<pitti> fabbione: I'd love to get rid of it :)
<fabbione> pitti: yeah but it doesn't mean you are forced to do it NOW. coordinate it with adam because he was already looking at it
<pitti> but this package needs to be merged together with the rest of X
<Kamion> Adam is on vacation this week, and X needs to be got out of the way
<fabbione> Kamion: yes i am aware of Adam vac. mesa has been source of different troubles due to excessive renaming of pkgs
<fabbione> that's why i was suggesting to let it to Adam.
<fabbione> he did most of those transitions with daniels
<Kamion> as I say, I think we are running short on time and need to get this at least started before Adam gets back
<siretart> Kamion: ah, so I was right about the procedure how to request syncs to dapper-backports
<Kamion> I do not think we can afford to wait a week
<Mithrandir> Kamion: I'd really like to have a bootable and somewhat-working -desktop in about a week too, for the first knot.
<siretart> keybuks mail made me wonder if I missed something
<Kamion> indeed
<Kamion> siretart: since elmo stopped doing archive maintenance, there's never been a defined procedure
<Kamion> siretart: filing bugs and ccing ubuntu-archive is as good as any other procedure one might invent, I think
<siretart> Kamion: at the TB meeting I asked mdz, and he confirmed that this would be a job for ubuntu-archive. and that we could upload directly now to dapper-backports if needed..
<Kamion> siretart: I'd like to have a little time to see if the script is easy to port to soyuz
<pitti> siretart: directly upload to d-backports? that sounds evil
<Kamion> I'm certainly less comfortable with that myself
<tseng> I am told coredev has that power now
<siretart> pitti: only core-dev, and only for very small changes like updated build-dependency and such
<Kamion> tseng: technical power yes, but it still has to go through archive admins for approval, and (as far as I'm concerned) it won't get that until we've at least made a token attempt to port the backporting script
<siretart> Kamion: take your time
<pitti> slomo: I'm currently merging sdl, btw
<slomo> pitti: ok, np :) why don't you wait for directfb?
<pitti> slomo: you mean directfb needs to be merged as well?
<dholbach> pitti: mvo asked for a sync
<pitti> slomo: no, we have the latest debian version
<slomo> pitti: no... directfb in main
<fabbione> pitti: should we take a look at that dovecot thingy?
<Kamion> dholbach: that got processed a while back
<dholbach> Kamion: yeah, I should have said "there's no merge to do" :-)
<dholbach> Kamion: how are you?
<Kamion> dholbach: a touch hungover but otherwise ok :)
<Kamion> importing base-installer into bzr pre-merge
<dholbach> :-)))
<dholbach> nice
<pitti> slomo: yes, see discussion above, we need it anyway
<pitti> fabbione: can you give me another 30 minutes or so?
<fabbione> pitti: yes, i am looking at how upstream broke in the meantime
<slomo> pitti: joined only 13 minutes ago ;) can you paste me the discussion?
<tseng> slomo: the summary was
<tseng> pitti: kamion: do you care about directfb udeb; kamion: no; pitti: ok i will stop building it (or move to universe)
<slomo> tseng: thanks
<Kamion> erm
<Kamion> to clarify, pitti asked me about libsdl1.2debian-udeb, not directfb-udeb
<tseng> oh right, off by one
<seb128> can anybody tell me what is happening to evolution-data-server 1.7.3 build?
<seb128> according to the corresponding launchpad page it's neither built, nor building, nor waiting for build
<seb128> nor listed by any other category
<tseng> https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=3&queue_text=evolution
<tseng> according to this it is "done"
<tseng> unclear on what that means
<seb128> tseng: if you click on "View Builds", it's not listed though
<tseng> right
<fabbione> tseng: evolution != evolution-data-server ?
<tseng> fabbione: its a search
<tseng> WHERE foo LIKE "%mysearch%"
<fabbione> oh ok
<crimsun> doko: ping, is Ubuntu's lib32asound2 supposed to conflict with ia32-libs (<< 1.9) ?
<pitti> hi ogra 
<pitti> ogra: I just finished merging dhcp3, and it seems to work fine
<pitti> ogra: I also left revert-next-server.dpatch
<pitti> ogra: s/left/kept/
<fabbione> pitti: i am writing to the debian maintainer and dovecot upstream
<fabbione> we should take the same direction here to fix it all over
<pitti> fabbione: the DD is quite responsive
<fabbione> otherwise it will be a mess
<pitti> right
<\sh> hmmm
<\sh> I think I found a really strange but
<\sh> bug
<\sh> create a /var partition and everything what needs /var/run (most of the init scripts) are failing
<\sh> I just rechecked, and removed the /var partition and everything works
<\sh> (dapper it is)
<ogra> pitti, yay, thanks :)
<pitti> fabbione: ok, I'm done so far; shall I still look into anything?
<fabbione> pitti: your inbox for now.
<pitti> ok
<\sh> yes, it doesn't mount /var/run as tmpfs and failes completly...
<fabbione> pitti: if you feel like looking at the code, it is clear how the thing went all downhill
<fabbione> pitti: 0.99.14 had one and only one declaration of SUBSCRIPTIO_
<fabbione> SUBSCRIPTION_FILENAME
<fabbione> while it has been broken down in different storage libs in 1.0
<fabbione> becoming inconsistent
<pitti> fabbione: thanks for the heads-up; I basically agree to your proposal
<\sh> https://launchpad.net/distros/ubuntu/+source/initscripts/+bug/51452 
<Ubugtu> Malone bug 51452 in initscripts "missing /var/run in root partition fails many services" [Untriaged,Confirmed]  
<fabbione> Kamion: 45523 -> rejected. He didn't create a separate /boot and none of our booloaders can boot from lvm
<fabbione> not lvm2 at least
<\sh> hmmm..how can I see the last uploader of a package in LP?
<\sh> hmpf...keybuk is not here :(
<fabbione> pitti: score.. upstream is doing it for us :)
<dholbach> did anybody remove UniverseFreeze from EdgyReleaseSchedule and the UniverseFreeze wiki page?
<dholbach> ok, the UniverseFreeze page was still there, I linked it from EdgyReleaseSchedule again
<Kamion> fabbione: well he says it works fine if he installs the bootloader by hand
<Kamion> fabbione: so no, I think rejected would be inappropriate
<Kamion> \sh: e.g. https://launchpad.net/distros/ubuntu/+source/sysvinit and look at the "Creator" field
<Kamion> it's badly named, but it means "last uploader"
<Kinnison> Kamion: No, it means "last person listed in changelog" really
<fabbione> Kamion: he is forcing lilo. It will break at the first upgrade. iirc we went trough this in breezy already.
<fabbione> (kernel upgrade that's it)
<Kinnison> Kamion: the dscsigningkey indicates the uploader really
<Kamion> fabbione: *shrug* it's only a matter of re-running lilo. sure, it's not perfect, but I do not think it justifies going around rejecting all bugs about it
<Kamion> Kinnison: oh, right, true
<Kamion> fabbione: I talked with Adam about that at UDS-Paris, and we noted that folks who've been using lilo forever tend to paranoidly rerun lilo -v after every upgrade anyway, so it's no big deal for them if the kernel upgrade doesn't do it for them
<fabbione> Kamion: oh the problem is lilo not understanding a bunch of LVM2 things and break
<fabbione> Kamion: but ok.. if you are sure it will work, i am ok with that
* fabbione -> food
<\sh> hmmm..I think in /lib/init/functions.sh: function domount ... the "if mountpoint -q $2" is the problem...
<Kamion> well the submitter reckons it works for him once he sets it up by hand ...
<Kamion> so I don't really need to be sure :)
<pitti> fabbione: wow, that was fast
<pitti> hey sabdfl!
<\sh> moins sabdfl
<thom> sabdfl: your talk at AC seems to have gone down well!
<tseng> lo thom 
<thom> heyhi
<\sh> anyone interested in fixing #51452 with me?
<pitti> \sh: how did you manage to get /var/run removed?
<\sh> pitti: no..I created a separate /var partition....and /var/run is not being mounted at all...
<\sh> pitti: if I partition without a separate /var partition everything works fine
<pitti> \sh: ah, ok. Well, that sounds like PEBCAK then - you'll miss /var/lib etc, too
<pitti> \sh: ah, I see
<pitti> \sh: you created /var in the installer, not in the isntalled system
<sabdfl> moin moin \sh, pitti
<pitti> bug 51452
<Ubugtu> Malone bug 51452 in initscripts "missing /var/run in root partition fails many services" [Untriaged,Confirmed]  http://launchpad.net/bugs/51452
<sabdfl> thom: thanks! i didn't get many questions so was a little worried that i put them all to sleep
<sabdfl> or didn't fully wake them up after the night before :-)
<thom> sabdfl: lots of interest on planetapahce.org 
<thom> heh
<\sh> pitti: what I don't understand is the first term in /lib/init/functions.sh: domount() ==> >> if [ ! -d $2 ]   then return fi << means to me, if the directory /var/run does not exists, return to caller. But wouldn't it be better to just create the missing directory then?
<pitti> \sh: where is this function called?
<\sh> pitti: in mountvirtfs
<\sh>  /etc/init.d/mountvirtfs
<\sh> # /var may be on another drive so create /var/run if we need to
<\sh>         domount tmpfs /var/run "-o mode=0755"
<pitti> \sh: hm, but domount is also used for /proc and /sys
<pitti> \sh: and an admin might not want these
<ogra> \sh, you need to move the data over ... just creating the dir might not be enough ...
<pitti> \sh: so instead of changing this in domount(), I'd rather stick a mkdir -p /var/run into it
<\sh> ogra: there no data actually, it's while booting the system
<pitti> \sh: so the comment clearly doesn't match the code :)
<ogra> i.e. /var/run is created in initramfs ... then your kernel boots and fstab is executed and /var is mounted on top of that
<ogra> then everything in /var/run that was created before is lost ...
<ogra> i thought keybuk had adressed that
<\sh> ogra: I don't boot with initramfs...
<ogra> that might be your prob then :)
<\sh> but it does the same when I used the default kernel
<\sh> which I'm doing right now actually ;)
<\sh> 2.6.15-23-amd64-server
<\sh> pitti: I did "if [ ! -d $2 ]  then mkdir -p $2 fi but it didn't help.
<pitti> \sh: (I hope that's a copy&paste bug)
<\sh> forget the " and put some \n in ;)
<pitti> \sh: hm, if that's a bug in the initramfs stuff, then Keybuk might be the best person to talk to
<ajmitch> evening all
<pitti> hey ajmitch 
<\sh> pitti: the question is, what if I don't use a kernel with initramfs, because I need to use a selfmade kernel, where most of the stuff we need is compiled in...and we don't want to use an initrd.
<pitti> \sh: hm, then I don't understand why the mkdir -p doesn't work
<sivang> morning
<\sh> pitti: well yes, I'm totally confused...think I'll have a smoke and a cup of coffee...and then another try..need to fix it
<pitti> slomo: libvisual approved
<slomo> doko: will you upload python-stdlib-extensions to ubuntu soon or request a sync? we need python-gdbm back ;)
<slomo> pitti: thanks :)
<doko> slomo: it should be automatically synced, there's no ubuntu version
<\sh> pitti: I'm installing the machine with another kernel (selfmade)..takes only 30 seconds ;)
<slomo> doko: hm, for two other NEW packages i had to file a sync request because they weren't synced automatically
<Kamion> it's semi-automatic
<Kamion> we have a report on the missing ones
<Kamion> nudge Keybuk about it next time he's aroundd
<slomo> ok, thanks
<pitti> hi rodarvus 
<rodarvus> good morning
<rodarvus> hi pitti
<irvin> mvo, can i bother you for a few minutes?
<sivang> hey pitti 
<pitti> hi sivang 
<mvo> irvin: hello, yeah, go ahead
<mdke> pitti: seems that cups-pdf doesn't work out of the box without doing "sudo chmod +s /usr/lib/cups/backend/cups-pdf", do you know if this is easy to solve? (bug #42147)
<Ubugtu> Malone bug 42147 in cups-pdf ""PDF Printer" does no not show up in "existing printers" (Dapper)" [Untriaged,Confirmed]  http://launchpad.net/bugs/42147
<pitti> mdke: not really, unless you create a directory in your ~ that the cupsys user can write into
<mdke> pitti: so chmod +s is a bad solution?
<pitti> mdke: well, it's good enough if you know what you are doing
<mdke> pitti: what knowledge does it need?
<\sh> pitti: it doesn't work either with a selfmade kernel, without initrd and initramfs
<pitti> mdke: but I never audited cups-pdf whether it's suitable for suid root operation
<mdke> so we shouldn't really recommend that solution in documentation?
<pitti> mdke: hm, no idea, really. If you really need it and don't use gnome apps or OO.o (which can do PDF natively), then, well, it's a good workaround
<mdke> pitti: right.
<mdke> pitti: thanks!
<pitti> Kamion: ok, directfb and libmpeg3 approved for main
<mjg59> What are we doing with directfb?
<jdub> (*and*... why is libmpeg* still in main?)
<fabbione> mjg59: coffee, the and biscuits? ;)
<pitti> jdub: libsdl1.2, graphical d-i, gtk 2.10
<pitti> mjg59: ^ 
<ogra> jdub, ask KDE :P
<pitti> jdub: libmpeg3 was in main in hoary, and in universe since then
<pitti> jdub: now it comes back due to directfb
<ogra> oh, right that was libmad
<pitti> jdub: libmpeg3 bad?
<mjg59> Ah, right
<jdub> some day, graphical d-i will be sane and use kdrive/similar
<jdub> pitti: patent-encumbered up the wazoo
<fabbione> jdub: you really should maintain X a bit before saying somthing like that :)
<mjg59> kdrive is pretty straightforward
<mjg59> And we've already got it in the archive
<fabbione> mjg59: how portable is it?
<pitti> jdub: so, shall I un-approve libmpeg3, and instead try to build directfb without it?
<jdub> and it's not evil/slow/yuck
<jdub> pitti: that'd be rad - for edgy, i'd like to get rid of all of them
<pitti> ok
<ogra> jdub, you cant get rid of libmad as long as KDE is in main
<jdub> ogra: we've did it before (fixing xine)
<ogra> its deeply woven in ...
* Fujitsu snips the threads and de-weaves it.
<fabbione> ogra: i am pretty sure you can build KDE without libmad
<ogra> fabbione, not according to the KDE people i spoke to (i havent looked myself yet)
<mjg59> fabbione: Uses framebuffer
<slomo> jdub: you will be my hero when you get all the ugly stuff out of main for edgy :)
<jdub> if we have to fix a broken KDE attitude towards putting their distributors in jail, then that's what we have to do :-)
<Kamion> mjg59: that's much slower though, right? the directfb advocates note that it makes much better use of hardware acceleration
<jdub> Kamion: it's all bollocks (based on benchmarks i read last week)
<Kamion> and I don't want an X-a-like in d-i any more than the last seventeen times we've talked about this, personally
<mjg59> We don't use accelerated framebuffers anyway
<jdub> Kamion: up to 10 times slower than GTK+ on X
<Kamion> jdub: interesting
* pitti goes to un-libmpeg3-ify directfb
<jdub> Kamion: (and down to 4 times slower, roughly)
<Kamion> but anyway, if you want d-i to change, go upstream - I'm not involved in graphical d-i any more, to a good first approximation
<jdub> Kamion: (none of the gtk+/gnome embedded folks are planning to use it, based on quite a few independent benchmarks)
<mjg59> Kamion: Directfb doesn't support vga16 (so we have problems with compatibility), vesafb is not usefully accelerated, and the specific framebuffers don't tend to work usefully on modern hardware
<fabbione> do we really care so much about speed in the installer?
<fabbione> i mean.. it's not like we are playing quake 4 while we wait
<pitti> fabbione: you don't?
<pitti> fabbione: just throw a grenade at packages you want installed :)
<fabbione> pitti: ahah
<fabbione> hmm that would be fun. your system install better as you hit more enemies
<fabbione> each time you die a random package is purged
<pitti> 'meet the Ubuntu devs in the Quake arena!'
<Kamion> fabbione: yes; it's pretty noticeable if the screen takes a large fraction of a second to redraw
<crimsun> Kamion: is there a failed upload of openvpn for breezy-security?
<fabbione> Kamion: yes but again installer is not glxgears ;)
<Kamion> fabbione: it's actually pretty noticeable on some hardware even at the moment, and I get bug reports about it
<Kamion> though admittedly certain vmware versions are the worst hit - but still
<mjg59> Kamion: There's a tradeoff - using vesafb provides other amusing issues
<Kamion> crimsun: Rejected: The key used to sign openvpn_2.0.2-1ubuntu0.1_source.changes has expired.
<Kamion> mjg59: suspend/resume in the installer is not terribly important :-)
<mjg59> Kamion: I thought the reason we used vga16 in the installer was that vesa didn't work on all hardware?
<mjg59> At least, I'm sure (you?) gave that as the reason at some stage
<Kamion> mjg59: we use either in the installer, depending on vga= parameters
<mjg59> Right
<Kamion> but yes we do default to vga16fb
<mjg59> But directfb forces vesafb
<crimsun> Kamion: ok, is there a second upload (also failed)? I signed with my current key for the second upload approximately 16 minutes ago (the previous upload was signed in late May)
<Kamion> for the graphical installer, that's not necessarily too much of a problem; the text mode would remain available
<mjg59> So we have to invert the current logic
<mjg59> Defaulting to vesafb for the installer is arguably saner than defaulting to vga16fb, but I think we need to recheck why that decision was made in the first place
<Kamion> I think vga16fb is right for the text mode
<mjg59> Why?
<Kamion> given the change to 640x400
<Kamion> most compatible
<mjg59> vga16fb doesn't work on some SIS hardware and is weird on a couple of other machines
<Kamion> you lose either way in corner cases, but my impression remains that vga16fb is a better default, particularly as it's what we default to in the installed system and thus gets more testing
<mjg59> Yeah
<mjg59> I guess supporting graphical d-i at all just seems a bit odd to me, given that we've got Ubiquity
<Kamion> I'd like the two to converge in the long run
<mjg59> The easiest way of doing that would seem to be to just run Ubiquity in an X session :)
<mjg59> As the only client, I mean
<jdub> :-)
<Kamion> not really, ubiquity isn't internally as flexible
<mjg59> Yeah
<Kamion> by design, it can't do half the stuff d-i can do
<Kamion> hence "converge" rather than "replace"
<Kamion> anyway, I don't actually plan to present graphical d-i at least for the next couple of Ubuntu releases
<Kamion> but I would like to avoid the merge pain caused by not being able to build core bits of d-i in main
<Kamion> having to merge cdebconf all the time is silly
<mjg59> Yes, that sounds like a pretty convincing argument
<fabbione> Kamion: only for curiosity. what is the status of g-i in Debian?
<mjg59> Hm. How hard would it be to hack up a mode for the live CD where it just launches ubiquity in the session rather than a full gnome session?
<mjg59> It would help the low-memory case
<Kamion> more convincing to me than to anyone else, I suppose, since it's me (or Tollef) who gets to do the work
<Kamion> mjg59: yeah, it's been suggested, probably not too difficult; though I know Mark wouldn't want it to be the default
<seb128> who is doing syncs nowadays?
<Kamion> seb128: me/Keybuk
<mjg59> Kamion: Sure
<Kamion> fabbione: functional but not polished
<seb128> I would appreciate a libcairo 1.2.0 sync from Debian incoming, it's required to package GTK 2.10 which has been rolled this morning
<Mithrandir> mjg59: it's quite trivial.
<fabbione> Kamion: ok thanks.
<seb128> Kamion: should I open a bug about it?
<Kamion> seb128: see DeveloperResources for how to request syncs these days
<Kamion> yes, please
<mjg59> Kamion: Could we put logic in gfxboot to check available RAM and prompt the user for whether they want to install or run a live session?
<Kamion> we do syncs in batches
<seb128> Kamion: I know, I just have no idea on how fast is the queue processing nowadays and I want to do GTK 2.10 today ... anyway, filling the bug now :)
<Kamion> seb128: measured in hours
<seb128> cool
<seb128> thanks Kamion
<Kamion> mjg59: yeah, should be possible
<Kamion> though I'm not sure exactly how reliable gfxboot's memory detection is - haven't used it much in anger
<Chipzz> pitti: seriously, I once heard about a quake mod where you could kill processes by shooting them ;)
<pitti> Chipzz: heh, me too :)
<pitti> 'stand still, damn apache!'
<Chipzz> .o0O( Where's that fucking eggdrop hiding? Fucking camper ) ;)P
<thom> Chipzz: http://psdoom.sourceforge.net/
<sivang> thom: wow
<ogra> hey Keybuk 
<Keybuk> heyhey
<jdub> mjg59: cool idea
<jdub>    * debian/control: Remove libmpeg3-dev build-dependency and dependency to
<jdub>      keep jdub out of the jail.
<jdub> ha ha
<ogra> *g*#
<jdub> pitti: thanks for putting my fingerprints *all over it*
<fabbione> ahhaha
<\sh> ah Keybuk
<\sh> the man I need
<Keybuk> oh aye?
<\sh> Keybuk: https://launchpad.net/distros/ubuntu/+source/initscripts/+bug/51452 
<Keybuk> it's nice to be needed
<Ubugtu> Malone bug 51452 in initscripts "missing /var/run in root partition fails many services" [Untriaged,Confirmed]  
<Keybuk> yeah, I saw that one this morning
<Keybuk> how did you install dapper?
<\sh> Keybuk: via FAI ;)
<Keybuk> then it's likely an FAI bug
<\sh> Keybuk: I don't know how the reporter installed dapper
<Keybuk> \sh: aye, just asked him
<\sh> Keybuk: but what really bugs me is : if [ ! -d $2 ]  then return fi
<Keybuk> the simple answer is that we do make /var/run and /var/lock
<Keybuk> the installer makes them
<Keybuk> and initscripts postinst makes them on upgrade
<\sh> Keybuk: so, creating /var first, then mkdir -p /var/{run,lock} and then installing could solve the problem?
<Keybuk> right
<Keybuk> that's what we normally do
<\sh> thx :)
<\sh> as I said, the man I need :)
<Keybuk> why does that if statement bug you?
<\sh> because if it's not there, it returns to the caller (in this case mountvirtfs) 
<Keybuk> right?
<\sh> but mountvirtfs should complain in this case
<Keybuk> -v please :p
<Keybuk> why should it complain?  nothing the user can do about it at that point
<Keybuk> the complaint will speed past so fast, etc.
<\sh> Keybuk: but gives errors later on, e.g. not starting simple networking 
<Keybuk> right
<Keybuk> what we should have is the error that causes networking not to start to be logged as "/var/run not writable" or something
<Keybuk> which makes it doubly obvious what happened
<\sh> Keybuk: in my POV it would be better to do a "mkdir -p $2" in this if clause, but this doesn't work when I tested it
<Keybuk> root filesystem isn't writable :)
<ogra> that at least slows down booting
<Keybuk> which is precisely _why_ we have these tmpfs's in the first place
<ogra> and what Keybuk said :)
<\sh> Keybuk: argh...you are right...
<\sh> we aren't at the stage of remounting root rw
<StevenK> ogra: Um, I did.
<StevenK> ogra: (the windowlab merge)
<Keybuk> if the filesystem was writable that early in the boot, we wouldn't need a separately writable /var/run
<StevenK> ECHAN
<ogra> StevenK, yeah, you missed to change the address in the changelog :)
<StevenK> DOH!
<ogra> nobody injured :)
<\sh> Keybuk: yeah...I missed that...let me check if I can work around that :)
<StevenK> Just proves I'm a bozo.
<StevenK> ;-)
<Keybuk> \sh: you could do a unionfs mount on /var with a tmpfs, make /var/run and /var/lock under that and then mount /var over the top again later
<Keybuk> ...oh dear, I appear to be chanelling Tollef <g>
<\sh> Keybuk: well, it's easier for me, to create /var/{run,lock} after the partitioning and formatting...
<Mithrandir> Keybuk: oh shiny.  You think that'd work? ;-P
<Mithrandir> Keybuk: also, unionfs gets very confused if you touch files in the file systems underneath it.
<Keybuk> \sh: I believe u6y creates it after formatting, yes
* fabbione disables crack detector to void extra bans on Keybuk and Mithrandir 
<\sh> Keybuk: yes...and my luck is, that the target partitions are mounted rw during install
<Keybuk> one would hope the targets were writable during install
<Keybuk> otherwise you'd have different problems <g>
<\sh> Keybuk: they are :) 
<Kamion> Keybuk: yes, it does
<Kamion> by virtue of using partman
<Kamion> oh, hmm
<\sh> Keybuk: and if I solve this little problem, I can get an ubuntu install (desktop) in less then 80seconds :)
<Kamion> the KDE frontend does not use partman for everything in the same way that the GTK frontend does - it's possible it doesn't make the directories
<Kamion> this is a bug in the KDE frontend
* \sh hugs Keybuk for opening his blind eyes...
<Keybuk> Kamion: interesting ... will see if the bug reporter was using KDE
<\sh> I'll ask him 
<Keybuk> Lathiat: ping
<pitti> jdub: SCNR :)
* pitti hugs jdub 
<Lathiat> Keybuk: pong
<Keybuk> Lathiat: was just curious to a bit more technical detail of how the mdns stuff works
<Lathiat> Keybuk: shoot
<Lathiat> or do you want a general rundown?
<Lathiat> or have specific queries?
<Keybuk> yup, general rundown of the major components
<Keybuk> and how they play together
<Lathiat> Well its made up of two things
<Lathiat> Multicast DNS and DNS-based service discovery
<Lathiat> both are basically independant, but complement each other
<Lathiat> multicast dns is fairlylike normal dns where
<Lathiat> you send a UDP query, in the same format
<Lathiat> askign for reecords for a name
<Lathiat> and you get replies
<Lathiat> the major difference is that instead of asking one serve,r you multicast the request
<Lathiat> and everyone with a reply multicasts back
<Lathiat> so theres no authorative zone its just an adhoc hi i want this, hi i have that
<jdub> pitti: SCNR?
<Keybuk> so that is "show me all blah on the network" ?
<Lathiat> well that dies into dns-sd
<Lathiat> so dns-sd is a method of describing services in DNS
<Lathiat> it can run over normal dns too
<Lathiat> basically you have records like
* jdub has unicast dns-sd records on his home domain
<Keybuk> is that like the SRV records?
* Keybuk has a _sip._udp.netsplit.com SRV record
<Lathiat> yep
<Lathiat> thats _exactly_ the same
<Lathiat> thats dns-sd over unicast dns
<Lathiat> just you request them over multicast dns in an avahi environment
<Lathiat> your _sip._udp would SRv to like
<Lathiat> keybuk's phone._sip._udp.netsplit.com
<Lathiat> which can also have TXT records and other data
<Lathiat> theres also some magic for discovering all types of services running on a network
<Lathiat> basically once you start publishing _sip.-udp
<Keybuk> right
<Keybuk> so how does that work over multicast?  what domain do you use?
<Lathiat> you start publishing
<Lathiat> _services._dns-sd._udp.local which PTRs to _daap._tcp.local
<Lathiat> _workstation._tcp.local etc
<Lathiat> bu thats not require in the spec
<Lathiat> bu tits usefull for avahi-browse etc
<Lathiat> Keybuk: .local is the default
<Lathiat> its not restricted to that but thats basically what everyone uses
<Keybuk> ok
<Lathiat> so over multicast dns you go
<Lathiat> "please give me SRVs for _daap._tcp.local"
<Lathiat> and all the nmodes respond with
<Lathiat> _daap._tcp.local IN PTR lathiat's music._daap._tcp.local
<Lathiat> and then you query lathiat's music._daap._tcp local and you get for example
<Lathiat> Lathiat\039s\032Music._daap._tcp.local  IN      SRV 0 0 3689 chiana.local ; ttl=120
<Lathiat> Lathiat\039s\032Music._daap._tcp.local  IN      TXT "org.freedesktop.Avahi.cookie=4255070712" ; ttl=4500
<Lathiat> which basically says its on port 3689 of chiana.local and the TXT data is some extra info
<Lathiat> you can put some auxillary info in there that may be usefull at discover time
<Lathiat> rather than conneting to the host
<Lathiat> for example ichat puts your status in their
<Lathiat> away, online, etc
<Lathiat> yo udont want to have to connet to just find that out
<Keybuk> ok
<Keybuk> so how does this tie in to avahi and mdns*, etc.
<Lathiat> the cookie is avahi's magical way of determining if two services on different interfaces and/or protocols (ipv4/ipv6) are the same
<Lathiat> Keybuk: well avahi is basically what i just described above
<Lathiat> rhythmbox asks avahi for _daap._tcp
<Lathiat> it broadcasts a query for _daap._tcp.local via mdns
<Lathiat> gets the results and passes them back to rhythmbox
<Lathiat> it can then choose to go query the indiivudla servers for their SRV/TXT records
<Lathiat> etc
<Lathiat> you dont need to do that to start tho, e.g.to display a list of shares all you need to do is get the SRVs
<Lathiat> as the first label (Lathiat's Music) is the service name
<Lathiat> its only once i click on it i need to get the SRV record etc
<Lathiat> that saves network traffic et al
<Lathiat> in reality theres more in the background like it actually announces when a service comes online
<Lathiat> and defends collisions and whatnot
<Lathiat> but thats just implementation detail
<Keybuk> ok, so avahi does the "discover" part of this?  it's what applications use to find out what's on the network?
<Lathiat> yep
<Lathiat> avahi-daemon runs and basically proxies between the app and the network
<Lathiat> it sends queries and announces its own services
<elmo> tuna 14:11 ~ % apt-cache show libgd2-noxpm | grep libxpm
<elmo> Depends: libc6 (>= 2.3.4-1), libfreetype6 (>= 2.1.10-1), libjpeg62, libpng12-0 (>= 1.2.8rel), libx11-6, libxpm4, zlib1g (>= 1:1.2.1)
<tortoise_> Does anyone have any tips on how to package python apps?
<Keybuk> Lathiat: ah, so what does mDNSresponder do?  or is that the old stuff?
<Lathiat> Keybuk: mDNSResponder does the same thing
<Lathiat> its just apples versiojn
<Keybuk> right
<Lathiat> avahi-daemon is what we called ours
<Keybuk> so I'm thinking about the whole discoverable/discovery thing
<Keybuk> would it be possible to tell avahi-daemon to service application's requests, but not service network requests?
<Lathiat> how so?
<Lathiat> to query the network but not respond?
<Keybuk> exactly
<Lathiat> you can tell avahi to disallow publishing
<Dr4g> Is most of the Ubuntu development in C ?
<Keybuk> so rhythmbox can still look for nearby shares, without actually announcing your own
<Lathiat> root@chiana:/etc/avahi# grep disable avahi-daemon.conf
<Lathiat> #disable-publishing=no
<Lathiat> #disable-user-service-publishing=no
<Dr4g> Any C++/python..etc
* Lathiat nods
<Dr4g> Lathiat:: nodding to me ?
<Keybuk> when that's disabled, and when applications haven't requested anything, is there a network port open?
<Lathiat> Dr4g: no, sorry, keybuk
<Lathiat> Keybuk: yes
<Lathiat> for avahi to do anything
<Lathiat> it has to talk on the network
<Dr4g> Okay :o)
<Lathiat> its the same as real dns 
<Keybuk> right, but why doesn't it open that port when the application makes the request, and then close it after?
<Lathiat> when your doing a query port 53 udp is open
<Lathiat> :)
<Lathiat> Keybuk: because then you miss out on all of the caching etc that makes mdns effecient
<Lathiat> and
<Lathiat> requests arent 1-time
<Keybuk> true, but once you've finished doing the query, the port closes again
<Lathiat> they are long term queries
<Lathiat> mdsn updates
<Lathiat> hosts comes and go etc
<Lathiat> thats all handled by listening to the announcements
<Lathiat> and goodbyes
<Lathiat> and theres no time you can say "you've got all the services now"
<Lathiat> you can guess tho
<Keybuk> we have "policy exceptions" for DNS and DHCP already
<Keybuk> trying to decide whether avahi deserves one or not
<Lathiat> for avahi to operate
<Lathiat> it raelly needs to be listening all the time
<Keybuk> the trouble is, I don't think we can trust avahi's code as much as we can trust libc and dhclient -- which have been around for years
<Lathiat> Keybuk: sure
<Lathiat> avahi has some advantages in security
<Lathiat> chroot(), unprivd user
<Lathiat> but that still doesnt stop you from doing things
<Lathiat> just helps minmize the damage
<Lathiat> we've had 2 issues so far that could have been potentially exploitable iirc
<Keybuk> which implies that we should ship with all service discovery off by default
<Keybuk> and have a set of options
<Keybuk> "discover network services" and "be discoverable yourself"
<Lathiat> i mean
<Lathiat> theres two issues here
<Lathiat> security wise, theres not alot of difference between the two
<Lathiat> information disclosure wise, there is
<Keybuk> exactly
<Lathiat> as i highlighted in my email which i see you read
<Lathiat> i guess that would be a resaonable set of options
<Lathiat> just promise me no mac-specific allowances or something ;)
<Lathiat> i think ekiga advertises without asking
<Lathiat> in rhythmbox you have to specifically allow it
<Lathiat> i guess a desktop wise setting could be usefull
<Lathiat> i wonder if avahi will pay attention to a change in the disable-publishing option and reset all services published
* Lathiat tries
<Keybuk> yeah, from a code-security POV, I don't think we can yet give avahi the same level of trust we give to libc's resolver and dhclient
<Keybuk> it just hasn't been around long enough
<Keybuk> which leads me to believe we need to be able to turn the network port on and off -- which implies having the daemon on/off
<Keybuk> and also from an information-disclosure POV, I think we should give people the option to discover, but not be discoverable themselves
<Keybuk> which implies a daemon configuration
<jdub> Keybuk: are you analysing nss-mdns (with or without avahi) at this point, too?
<Chipzz> Keybuk: avahi is run in a chroot iirc
<Keybuk> btw, if an app like rhythmbox decides to do discovery, does the daemon get started anyway?
<Keybuk> jdub: not yet, will get onto that later
<Keybuk> Chipzz: chroots, nobody users, etc. can all be broken
<Lathiat> brb call
<sivang> I guess some pycentral breakage is inevitable.
<sivang> Setting up python-logilab-common (0.16.1-2) ...
<sivang> pycentral: pycentral pkginstall: already exists: /usr/lib/python2.4/site-packages/logilab/common/ureports/__init__.py
<sivang> pycentral pkginstall: already exists: /usr/lib/python2.4/site-packages/logilab/common/ureports/__init__.py
<sivang> known ?
<Keybuk> sivang: file a bug
<sivang> Keybuk: sure, I have some more stuf from last night's dist-upgrade, care to let me know which ones are worth a bug or should I just file them all?
<Keybuk> sivang: any breakage is worth a bug
<sivang> k,
<sivang> something I wanted to ask you about yesterday, was:
<sivang> Setting up liblockdev1 (1.0.3-1) ...
<sivang> /var/lib/dpkg/info/liblockdev1.postinst: line 3: [: : integer expression expected
<sivang> cpio: ./lib/udev/path_id: No such file or directory
<Keybuk> two bugs there
<sivang> (this is how it appeared while I dist-upgraded)
<Keybuk> <sivang> /var/lib/dpkg/info/liblockdev1.postinst: line 3: [: : integer expression expected
<Lathiat> one of the thigns i want to look at sending patches for
<Keybuk> ^ bug in liblockdev1's postinst
<Lathiat> is that if avahi is started
<Keybuk> <sivang> cpio: ./lib/udev/path_id: No such file or directory
<Lathiat> most of the apps arent starting to use it
<Keybuk> ^ bug in udev (filed)
<Lathiat> avahi has the functionality to wait aroudn for the daemont o start
<Lathiat> and start advertising/querying when it does
<Lathiat> including if its restarted
<Lathiat> thatd be fairly essential to making this work for us
<sivang> Keybuk: okay, so I'll only file the one agaisnst liblockdev1 ?
<Keybuk> sivang: yup
<sivang> k, thanks
<Lathiat> unless we want to say "reboot for service discovery to be enabled" :)
<Keybuk> Lathiat: I don't think we do :p
<Lathiat> sure? i'm sure its the easy way out... :)
<Keybuk> rebooting is bad
<Keybuk> so, all this works provided you have an IP address on the network?
<jdub> *yay d-bus!*
<Keybuk> how does it work when you don't?
<Lathiat> hrm changing the disable user publishing option 
<Lathiat> doesnt work until the daemon is restarted
<Keybuk> what assigns the link-local IP?
<Lathiat> Keybuk: avahi doesnt
<Lathiat> that needs to be done by somethign else
<Lathiat> network-manager for example
<jdub> zeroconf has improved
<Lathiat> or if the interface is up, ipv6 :)
<Lathiat> or zeroconf
<Keybuk> I've yet to find the code in n-m that actually does link-local :p
<Keybuk> ah, yeah, I was going to ask that
<Lathiat> it works, i knwo that much
<Keybuk> does this work over IPv6 ?
<Lathiat> :)
<Lathiat> yes
<Lathiat> it does
<Lathiat> its off on ipv6 by default tho
<Keybuk> because IPv6 gives you link-local for free
<Lathiat> thats true, buttt
<Lathiat> a) the application needs to support it
<Lathiat> b) applications that support ipv6 in general will often fail with link local
<Lathiat> because
<Lathiat> you need to specifically specify the interface to bind to
* jdub upgrades to IT2006 final
<Lathiat> which most apps dont do
<Lathiat> altho, you can get that information from avahi
<Lathiat> so is supportable in theory
<Lathiat> (because the same link local range is on all interface,s by default linux has no idea which one you want)
<Lathiat> try ping an ipv6 link local address without -I
<Lathiat> and with -I
<Lathiat> and you'll see what i mean
<Lathiat> it2006?
<Keybuk> right
<Lathiat> ah
<Lathiat> n770 stuff
<jdub> Lathiat: 770 foo
<Keybuk> jdub: what's new?
<Lathiat> who wants to give me a 770? :)
<jdub> Keybuk: it's final, so quite a few bugfixes and so on
<Keybuk> jdub: I still only see Beta 2
<jsgotangco> jdub!
<Keybuk> jdub: did they get SIP support yet? :p
<jdub> Keybuk: it's behind the maemo download page (ignore the front bits)
<jdub> Keybuk: don't think so
<Keybuk> meh, will do it later, can't remember its MAC address <g>
<jdub> it'll be in your daemon.log :)
* jsgotangco can only dream for the 770 being available in his place
<iwj> Keybuk: Would it be possible to make MoM a bit smarter about changelogs which have tails not in standard Debian changelog format ?  ATM it removes blank lines.
<jjesse> s
<Keybuk> iwj: that should be fixed
<Keybuk> iwj: oh, hmm
<Keybuk> so it's keeping the tail, but removing blank lines from it?
<Keybuk> (it used to just drop the tail entirely)
<iwj> Yes.
<iwj> It's not a huge problem, but it would save a bit of faff fixing it up if it didn't mangle it :-).
<Keybuk> will look into it
<Keybuk> (have a few bits of "real work" to do first today -- several large merges :-/)
<iwj> Fun fun.
<iwj> See for example the psutils merge.
<iwj> (Nice simple case where the generated package would have been just right otherwise.)
<Keybuk> it's pretty easy to fix though -- you have the other source next to you, so can just copy the end of the changelog in
<Keybuk> but yes, it's unwanted faff
<iwj> Yes, indeed.
<Kamion> mjg59: mind if I merge gnu-efi?
<Kamion> or possibly sync, still checking
<Keybuk> jdub: so, the location for next year's GUADEC is decided?
<jdub> Keybuk: b'ham
<Kamion> mjg59: indeed, it's a sync
<Keybuk> jdub: not sure I'll make that one ... it's SO FAR to travel :-/
<jdub> heh
<Seveas> Keybuk, MoM screw up greek .po files - they look like rubbish in .patch but look good in .diff.gz
<Keybuk> Seveas: s/MoM/msgmerge/ :p
<Seveas> (see the apollon merge for an example)
<seb128> Kamion: do you know if evolution-data-server 1.7 is waiting to NEW or something like that?
<ogra>  rss-glx (0.8.0-4) unstable; urgency=low
<ogra>  .
<ogra>    * I am an idiot. (Closes: #350985)
<tseng> seb128: you can see NEW now on launchpad
<seb128> tseng: URL?
<tseng> moment
<ogra> wow, i didnt know the debian bts has such cool features :)
<tseng> its hard to find :P
<tseng> https://launchpad.net/distros/ubuntu/edgy/+queue
<seb128> tseng: thank you
<tseng> np
<iwj> Glargh.  The psutils Debian maintainer copied the changelog entry from the patch I sent but forgot to actually apply the change to the source.
<Keybuk> ogra: ?
<ogra>  rss-glx (0.8.0-6) unstable; urgency=low
<ogra>  .
<ogra>    * I'm still an idiot. (Closes: #356971)
<ogra>  .
<ogra> hehe, another one 
<ogra> Keybuk, well, bugs that are closed by stating youre an idiot :)
<tseng> the feature is Closes:
<tseng> not I'm an idiot
<Keybuk> tseng: heh, that still has the same bugs as the tool we get :-/  doesn't say what's NEW and confuses i386 and all
<tseng> it does say what is NEW
<tseng> no?
<seb128> could somebody process the new e-d-s then? :)
* tseng bribes Keybuk to process NEW
<Keybuk> tseng: no, just says "here's a changes file with 30 binaries in it"
<Keybuk> doesn't tell you which one is the new one
<tseng> Keybuk: ah
<tseng> right, new binary
* Keybuk opens up NEW :-/
<tseng> dholbach: so, very shortly beagle will ship python2.4-beagle not python-beagle
<seb128> Keybuk: e-d-s has a new -common
<Keybuk> tseng: for my bribe, I'd like avahi and mono installed by default in edgy please <g>
<Kamion> tseng: isn't that going in the opposite direction to current python policy?
<Kamion> (see recent debian-devel-announce)
<tseng> Kamion: it changed again?
<dholbach> tseng: thank you
<iwj> Oh, no, I'm wrong, it's using some hideous patch system.
<Kamion> tseng: yes, much saner now
<iwj> And psutils _has no upstream_ !
<tseng> Kamion: goodness, ok.
<Kamion> though the changes are a little complex to get your head around at first - but the result is better
<Keybuk> iwj: most stuff close to the kernel doesn't
<Keybuk> iwj: suggest to jon masters that it should be added to kerneltools.org ?
<iwj> No, psutils, not procps.
<tseng> Kamion: will review with debian beagle maintainer
<Keybuk> iwj: oops :p
<Keybuk> iwj: my brain read "ps" and stopped
<tseng> Kamion: thanks for the tip
<iwj> The maintainer is going to hate me now for messing with this bug and so on.
<ogra> isnt procps supposed to die since 2.6 started ? 
<ogra> as well as /proc ?
<tseng> Keybuk: it sounds like there is a concensus to desktop seed at least f-spot
<Keybuk> ogra: no, /proc will always retain the /proc/$PID functionality
<ogra> ah
<Keybuk> ogra: it's just /proc/$PSEUDO_SYSCTL that's getting phased out
<Keybuk> well, actually, what I mean it
<Keybuk> /proc/$JUNK
<ogra> yep in favor of sysfs
<Keybuk> /proc/sys (which is the sysctl interface) might stay
<ogra> isnt that just redundant to /sys ? 
<dholbach> who's going to do the gnome-power-manager update?
<Keybuk> no, sysctl is things like sys.vm.overcommit_ratio, etc.
<ogra> ah
<tseng> dholbach: is it simple? :)
<Keybuk> /sys is the kernel's kobject tree
<dholbach> tseng: look at it :)
<tseng> dholbach: i have been running CVS
* ogra looks for more packages from ari pollack, these changelogs are entertaining :)
<dholbach> tseng: you should do the package then :)
<tseng> ok we'll see
<tseng> can I drop these silly icons?
<tseng> upstream has tango
<ogra> tseng, you mean the beutiful ones ?
<dholbach> tseng: ask Mark
<tseng> oh goodness
<tseng> I knew there was a catch
<dholbach> tseng: does it use proper gtk icon theme support now?
<tseng> hm I dont think
* tseng looks
<dholbach> tseng: if so, I can move them to the yet to come human-icon-theme package
<dholbach> they shouldn't use hardcoded icons
<tseng> should have thought of that last week
<tseng> when i could have punched hughsie in the arm
<tseng> dholbach: 
<tseng> dholbach: /usr/share/icons/hicolor/16x16/apps/gpm-ups-100-charging.png
<tseng> /usr/share/icons/hicolor/24x24/apps/gpm-ups-100-charging.png
<tseng> looks nice!
<dholbach> tseng: then it should be fine to drop them, I'll add them to human (probably) next week
<tseng> ok
<tseng> alot of patches here to figure out as well
<ogra> tseng, could you make a tgz of them and mail them to me ? i'd like to habve them in the gartoon package for edubuntu 
<tseng> ok
<dholbach> ogra: which ones? the Human ones or the Tango ones?
<dholbach> ogra: seems the OLD are lost
<ogra> NOOOO !
<dholbach> ogra: or somewhere in an old package
<dholbach> ogra: or in cvs
* ogra cries about the beautiful icons
<ogra> yeah
<ogra> i'll grab them from the breezy package :P
<tseng> it is in tseng.ath.cx/~brandon/gpm-icons.tar.gz
<ogra> tseng, thanks a lot, but these are the new ones already ...
<dholbach> doko: do you still know why we wanted to use mcpp for libidl?
<pitti> Mithrandir: wrt mailman, I would do the merge now to get it off my list, unless you want to grab it
<Mithrandir> pitti: feel free
<doko> dholbach: to remove cpp from the live and install CD
<dholbach> doko: I see
<tseng> dholbach: can you help me with this?
<tseng> dholbach: i have fixed a few patches already
<tseng> 90 is scary, the upstream file is very different
<dholbach> tseng: hum, i never looked at it
* tseng looks who wrote it in the first place
<dholbach>  :-)
<tseng> Daniel Silverstone
<tseng> ugh
<tseng> some of these 9x patches are hard to tell since upstream is moved so much
<tseng> what do you think?
<tseng> i dont want to drop them and piss someone off
<ogra> tseng, also note that there might be corresponding patches in gnome-screensaver for some of the g-p-m patches
<dholbach> tseng: Kinnison and mjg59 might know better than me
<tseng> maybe Kinnison should update it then
<tseng> i have merged the gconf patches
<tseng> but the C has moved too much for me to do a merge
<tseng> bits are entirely gone/changes
<dholbach> doko: trying to merge it, it gives 'configure: error: C preprocessor "mcpp" fails sanity check' in pbuilder :-(
<tseng> I have it all done besides 9x patches
<tseng> if that is useful at all to anyone
<tseng> btw
<tseng> what is gpm_screensaver_poke called again now?
<dholbach> doko: just try to build the dapper version in a edgy pbuilder
<tseng> we need a patch for that as well
<dholbach> gnome-screensaver-command --poke   ?
<tseng> i seem to recall that the name of the function changed recently
<sivang> so, I have this merge I'm doing for bittornado, I have one question: One of the build-deps is  python-support (>= 0.3) , and we have in edgy 0.2.3ubuntu1 , should I upload the source with the new dependency , assuming we are anyways getting to python-support (>= 0.3) part of merging from upstream? (debian)
<tseng> ioh, that is internal anyway
<tseng> if someone wants my WIP let me know, I can't do anything with 9x patches
* dholbach hugs tseng
<tseng> *hugs*, sorry
<tseng> a good case for why patches should go upstream
<pitti> sivang: doko wanted to look into merging the newer version, so just hold back the upload for now
<mdz> phanatic: pong
<mdz> anibal: pong
<phanatic> mdz: i just wanted to ask about the thing i posted to the ubuntu-archive list
<phanatic> (sysinfo vs. dapper-updates)
<ogra> mdz, i renamed the ltsp upstream branch, can you point https://launchpad.net/people/mdz/+branch/ltsp/ubuntu-main to http://people.ubuntu.com/~ogra/bzr-archive/ltsp/mainline/ ?
<Keybuk> phanatic: how many explanations do you need?  you've had three already
<phanatic> Keybuk: excuse me, i've pinged mdz before Kamion told me to write to ubuntu-archive. i understand the situation now...
<mdz> Keybuk: I was responding to a ping from over the weekend
<mdz> ogra: I don't see why I should?  I'll just rename it so that it doesn't say mainline
* Hobbsee waves to the room
<ogra> mdz, ah, so i register a new one then, ok
* pitti waves to Hobbsee 
<lbm> slomo: ping
<Hobbsee> hey pitti :)
<phanatic> btw is there a dapper-updates approval howto? maybe a wiki page or something like that which describes the process?
<Keybuk> iwj: coreutils is incorrectly marked as an "Updated Merge" ... could you make sure that one isn't forgotten?
<Hobbsee> phanatic: there might be something in developer resources, in the topic, but they rarely seem to accept updates to the stable version
<iwj> Keybuk: noted
<Hobbsee> wow, only 759 universe merges to go - that's not really so many
<Seveas> Hobbsee, minus a few dozen that I just found out are syncs :0
<Hobbsee> Seveas: yeah, exactly, minus the few that we killed off tonight.
<Seveas> and minus the hundreds to kill today ;)
<phanatic> Hobbsee: thanks. then i'll stop bugging the people and focus on edgy :)
<Hobbsee> phanatic: usually a good idea, yeah
<Hobbsee> Seveas: yeah, yeah, of course.
<jdub> Hobbsee: going to do all 759 before bed time?
<Hobbsee> jdub: nah, i dont think so - it wouldnt be a great idea to piss the parents off more than they  already are - which is a lot
* Hobbsee looks at the rest listed under her.
<Hobbsee> bleh.
* Hobbsee will need to find someone else to upload more of her stuff, in order to do much.  or file sync requests.
<Hobbsee> jdub: evil.  tempting me with something like doing more merging etc before sleeping.
<mjg59> Kamion: Feel free
<sivang> pitti: sure thing, thanks
<doko> pitti: Setting up libgphoto2-2 (2.2.1-1ubuntu1) ...
<doko>  /var/lib/dpkg/info/libgphoto2-2.postinst: line 21: /usr/share/hal/fdi/preprobe/10osvendor/20-libgphoto2.fdi: No such file or directory
<doko> dpkg: error processing libgphoto2-2 (--configure):
<doko>  subprocess post-installation script returned error exit status 1
<dholbach> doko: any idea how to fix libidl regarding mcpp?
<doko> dholbach: does the current package build?
<dholbach> doko: no, as i said: if you grab the current source and build it in edgy pbuilder it ftbfs
<dholbach> 'configure: error: C preprocessor "mcpp" fails sanity check'
<ogra> Keybuk, Kamion, 
<ogra> <Gadi> I have this issue with an adaptec raid card - seems the install cd used i2o_core and friends, while the installed initramfs wants to load dpt_i2o first
<mdz> Keybuk: why shouldn't edgy-artwork be informational?  the actual artwork targets are in separate specs, and the artwork plan is a process document
<ogra> do we have a bug open for that  ?
<Keybuk> mdz: umm, it should?
<Keybuk> mdz: and it is
<pitti> doko: oh, oops; thank you for pointing out
<Keybuk> are you confusing edgy-artwork and update-manager-edgy ?
<Keybuk> ogra: probably at least a dozne
<ogra> oki
<ogra> then i wont tell him to file one ;)
<pitti> doko: this was a fresh install? this works on dapper upgrades
<ogra> Keybuk, thanks
<mdz> Keybuk: yes, I confused those emails
<Keybuk> mdz: Mark's been annoying and changed the approver on everything
<doko> pitti: see the openoffice.org build log
<Keybuk> so I don't get e-mails anymore
<Keybuk> *sulk*
<Hobbsee> Keybuk: you dont get enough emails as it is?  :P
<pitti> doko: ah, ok; since the directory is shipped by hal
<pitti> doko: but hal is not a dependency; will fix now
<doko> dholbach: checking how to run the C preprocessor... mcpp
<doko> checking if C preprocessor likes IDL... yes
<doko> checking if C preprocessor can read from stdin... yes
<doko> checking how to ignore standard include path... -I-
<seb128> could anybody promote libdirectfb-dev and give a retry to libcairo 1.2.0 build?
<iwj> Aaargh I hate patch systems.  They make merges such a PITA.
<seb128> that's blocking pango 1.13, GTK 2.10 and most of GNOME 2.15
<Kamion> seb128: I'm going to promote it after this publisher run
<seb128> Kamion: thank you
<doko> works for me, could you have a look at the config.log file of a failed build?
<Kamion> Keybuk will need to prod the libcairo build though
<iwj> Keybuk: Did you send debian/patches/60_ubuntu-force-clobber-specials.patch (coreutils 5.93-5ubuntu2) upstream to Debian ?  I can't seem to find it in the Debian BTS.
<dholbach> doko: hum, I double-check
<seb128> I'll ping him when directfb has been promoted :)
<dholbach> doko: did you try in edgy pbuilder?
<Keybuk> iwj: I sent it directly to the coreutils list, ages ago
<Tonio_> hey
<dholbach> doko: i tried on amd64 (if that matters) *try on i386*
<iwj> Keybuk: Aha.
<Keybuk> in general, I tend to send patches upstream than to Debian
<iwj> Keybuk: IC.  Do you know if they took the patch ?
<Keybuk> I never got a reply to the mail, so I guess not
<iwj> OK.  I'll chase it up.  Thanks.
<iwj> Let me just check the code first ...
<Keybuk> iirc, that was the distro sprint patch to fix the fact -f didn't do what it seemed like it should
<iwj> Yes.  AFAICT your patch only fixes it for devices and not for fifos.
<Keybuk> yeah, I suspect we did "fix the bug, and not other cases"
<pitti> doko: libgphoto2 fix uploaded
<iwj> Keybuk: I think your patch is quite wrong, really.  It is as if you always said --remove-destination whenever the object to be created is a device.
<Keybuk> then you'd need to patch busybox to support --remove-destination
<Keybuk> which isn't specified by POSIX
<iwj> Err, what ?
<Keybuk> the patch was written to fix a problem
<iwj> I mean, the supposed behaviour of coreutils cp is fairly clear I think.
<Keybuk> we decided the behaviour was wrong
<iwj> Eg, if you say    cp -a /dev/null /dev/zero   it ought to refuse.
<Keybuk> right, but if you so cp -a -f /dev/null /dev/zero it should not refuse
<iwj> If you say    cp -af /dev/null /dev/zero  or   cp --remove-destination /dev/null /dev/zero    it ought to unlink /dev/zero first.
<Keybuk> right
<Keybuk> that's what the patch does
<Keybuk> it makes the former work
<iwj> Really ?
<Keybuk> which doesn't without the patch
<iwj> Yes, but the behaviour doesn't seem to depend on -f.
<iwj> And -f means `try again with an unlink if it fails', not `always unlink it'.
<Keybuk> it only comes into play with -f, due to some random flow through that code
<iwj> (I'm not sure why there are two different options.)
<iwj> Joy.
<Keybuk> without -f, it never reaches that bit anyway
<iwj> Keybuk: Not quite true.  There's a race.  If you    cp -a /dev/null foo & cp -a /dev/null foo   then both can succeed.
<iwj> ogra: coreutils patch 99a_fix_cp_manpage in 5.93-5ubuntu3 edits cp.1 but cp.1 is an output file.  Did you know that ?  The thing you were trying to fix seems to be addressed in Debian #351601.
<Ubugtu> Debian bug 351601 in coreutils "Subject: coreutils: minor formatting issue in the mv an cp manpages" [Minor,Open]  http://bugs.debian.org/351601
<ogra> iwj, if debian adresses it, feel free to drop it :)
<iwj> Yes, I will :-).  But I thought I should point out your mistake in a spirit of education :-).
<highvoltage> :)
<iwj> Anyway, I have to go and have dinner.
<dholbach> me too
<Kamion> The localechooser merge is making me lose my sanity. I'm off for dinner before it all disappears entirely.
<Keybuk> swap you for sysvinit :p
<Kamion> no deal
<thom> Keybuk: you have no sanity left to lose, colin is a more serious matter 
<thom> ;-)
<highvoltage> colin is sanity personified.
<mdz> ogra: you should make yourself a bug contact for fuse
<Keybuk> I reckon jdthood examined our changes carefully, and then deliberately changed the Debian package in ways that would make this merge annoying <g>
<Keybuk> like he's reindented a bit we changed, for no other readily apparent reason
<ogra> mdz, will do
<ogra> ugh, how did that makedev rubbish get in there .... 
<Keybuk> oh, that's kinda annoying
<Keybuk> new-mom drops an Ubuntu change to a file Debian removed, rather than flagging it
* jdub sucks down edgy
<crimsun> Keybuk: out of curiosity, do -security pull from a different keyserver? My uploads to breezy-security are failing due to key expiration, but I'm using the same key that I use to sign uploads to Edgy (which are accepted).
<Keybuk> crimsun: not sure, -security goes down a different path
<siriusnova> hello
<crimsun> fabbione: anibal has prepared merged nfs-utils at http://users.monash.edu.au/~anibal/ubuntu/nfs-utils/ . They look sane to me.
<ogra> Kamion, mind if i merge makedev (its only 3 lines in postinst to merge)
<Laser_away> can a reviewer please look at https://launchpad.net/distros/ubuntu/+spec/edubuntu-dynamic-menus ? Thanks
<Burgwork> Laser_away, I will look at it, but I am not a reviewer
<Burgwork> Laser_away, "A standard location/format for determining the user -> group mapping will be used so both Gnome's sabayon and KDE's kiosk tool frontends can access the same groups."
<Burgwork> Laser_away, that part is not clear to me
<Riddell> Laser_away: kisoktool spelt wrong
<Burgwork> Riddell, to the sharks, eh?
<Riddell> "A standard location/format.." that would require quite major and incompatible changes to kiosk
<crimsun> unless he means to develop a proxy...do you?
<Burgwork> how does kiosk work?
<Burgwork> does it set keys in kconfig?
<Riddell> Laser_away: you might also be interested in https://wiki.kubuntu.org/KubuntuKioskProfiles
<Riddell> Burgwork: it does indeed
<Laser_away> Riddell: well, I talked to aaron about it
<Burgwork> is that not a stand place?
<Burgwork> if for no other reason, gconf and kconfig should be merged because of all the duplicate lockdown stuff
<Riddell> Burgwork: the use to profile mapping is done in /etc/kderc, presumably sabayon doesn't use that file
<Riddell> user to profile
<Burgwork> it uses a .zip based format to define keys within it
<tseng> hi Burgwork 
<Burgwork> hey tseng 
<Burgwork> you know what is really sad? My company has 4+ years of experience with locking down linux public computers and yet we are unwilling to share
<Laser_away> well, the idea was to at least allow kiosktool and sabayon to be able to share user->group/profile mappings
<Laser_away> what we want is for Edubuntu to be able to have group driven menus
<Burgwork> Laser_away, just the mappings, not the actual settings?
<Laser_away> sabayon seems to be the way to do that
<Laser_away> at least mappings
<Burgwork> to me, the implementation is still not very clear
<Laser_away> settings might depend on DE if it is more than just menus
<Burgwork> maybe but that stuff there about what exactly needs to be common and what can't be/shouldn't be
<Burgwork> Laser_away, you should also chooose profiles or .menus. I don;t know if you have, but the spec seems to indicate that the decision was still up in the air
<Kamion> ogra: Mithrandir said he was doing makedev
<Kamion> he said "I've prodded bdale to take our final change to makedev, so you don't need to think about that merge."
<Kamion> feel free to do it if you just want to get it off the list though - but sounds like it should turn into a sync
<ogra> yeah, if bdale added the change ... its just that fuse seems to need a newer one ...
<Keybuk> oh, joy
<Keybuk> I just accidentally wiped a merge that's taken me most of the afternoon
<Keybuk> *sigh*
<pygi> Keybuk, :-/
<Keybuk> oh well, hopefully my brain is still fresh and I can resurrect it from memory
<mjg59> Do we have magic OLPC images anywhere?
<rodarvus> what are magic OLPC images?
<mjg59> One Laptop Per Child
<mjg59> Someone's looking at customising Ubuntu for the boards, but I don't know how far things have got
<rodarvus> I know what OLPC means :)
<rodarvus> afaik, no one is working on an Ubuntu OLPC image - yet
<rodarvus> a few Ubuntu developers (me included) have subscribed to the developer program
<Kamion> ogra: feel free to go ahead then
<mjg59> rodarvus: Yes, I have one of the boards
<rodarvus> mjg59, nice!
<rodarvus> mjg59, do you have other plans for it, or want to have Ubuntu running on the board?
<mjg59> I'm doing power management stuff on it
<sladen> all of the power-management?
<mjg59> Well, that sort of depends what already works...
<Burgwork> rodarvus, you are doing X stuff for Canonical, no?
<rodarvus> Burgwork, right
<Burgwork> ah, cool
<ogra> Kamion, done, thanks for all the info
<Kamion> Keybuk: I'm trying to grok the bit in replacement-init about level events
<Kamion> "Level events are just edge events that have a string value associated with them, e.g. "up" and "down". Any change in the value triggers an edge event of the same name."
<Kamion> Keybuk: shouldn't that be "triggers a level event" - or am I missing something?
<Keybuk> hmm, not describing that very well there
<Kamion> Keybuk: where does the init daemon's event socket reside?
<Kamion> presumably has to be somewhere guaranteed to be on /
<Keybuk> Kamion: undecided, might just use a named unix socket
<Kamion> '
<Kamion> k
<Kamion> I hate my k key
<Keybuk> ok, tweaked that paragraph
<Keybuk> "Level events are just like edge events, except that they also have a string value associated with them, e.g. "`up`" and "`down`". Any change in the value triggers the level event with that value associated, and an edge event of the same name (without any value)."
<Kamion> ah ok, though I wonder how useful such edge events would be in practice
<Keybuk> e.g. "on power" (whenever power state changes) vs. "when power is battery" or something
<Kamion> fair enough
<Keybuk> they're most useful for the associated stop events
<Keybuk> start when power is battery ... stop on power  (whenever it changes to something else)
<Keybuk> which is just "while power is battery" <g>
<Kamion> the fs repair console case is interesting - might want to provide for a way to make init stop reacting to events while the repair console is active
<Kamion> I'd be a bit freaked out if I were trying to put my system back together from sulogin and init started randomly doing stuff
<Keybuk> yeah, that's special-case'd in ordinary init too
<Kamion> your XML config file example has unbalanced tags ;)
* Keybuk hates XML
<Kamion> ich auch
<Kamion> it occurs that having "reload"/"restart" or whatever in addition to "start" and "stop" might be useful in the future
<Keybuk> restart is actually in there, I think
<Keybuk> yeah it is
<Keybuk> mentioned under the state machine description
<Kamion> "restart dhcpd whenever list of interfaces change"
<sladen> Keybuk: "edge events just show change, level events show change to a _particular state_ which is provided as an accompanying string such as 'up' or 'down'."
<Kamion> ah, ok, hadn't got that far yet
<bluefoxicy> Keybuk or Kamion, which one of you knew the linker intimately, and are you going to be not busy enough to talk to me in #-offtopic when I get back from mcdonalds?
<Keybuk> bluefoxicy: not right now, maybe later
<sladen> bluefoxicy: it might be useful to say what you're actually trying to do
<bluefoxicy> sladen:  Offtopic stuff, I'm writing an article on prelink and want to make sure I've described things like the relocation process properly et al, hence why #-offtopic
<Kamion> bluefoxicy: not me
<bluefoxicy> anyway there's real work going on so I'm gonna go for a bit, maybe later.
<sladen> bluefoxicy: then post a link to the wiki page
<bluefoxicy> sladen:  it's not on the wiki
<sladen> bluefoxicy: then how are you going to show people to ask for comments?
* bluefoxicy slips out for a few
<sivang> Since it's getting close to spec approval dead line, I'd like to know about my two specs, home-user-backup, and make-free-space-wizard. Are they still pending in the reviewers queue ?
<Kamion> Keybuk: your state machine is missing transitions for Waiting->Starting and Waiting->Stopping (I'm assuming the former is == Stopped->Starting and the latter is a no-op); also I think your Stopped->Waiting transition is bogus
<Keybuk> let me check
<Keybuk> heh
<Keybuk> I must have badly C&P'd that
<Kamion> Keybuk: with regard to non-root user events it might be worth referring people to userv if they want cross-user functionality (or studying the measures it takes if you want to do it in upstart)
<Keybuk> I was fighting moin's formatting for that bit
<Keybuk> Waiting->Stopping is definitly a no-op
<Kamion> presumably also Stopping->Stopped
<Keybuk> aha!
<Keybuk> first thing is supposed to be Waiting to Starting
<Keybuk> (starting->waiting is a no-op)
<Kamion> in particular I remember that userv is very careful to sanitise file descriptors
<Kamion> you mention file descriptors being left open in one of your use cases, but don't address what you're going to do about it
<Keybuk> Kamion: that's more an edgy+1 fix
<Kamion> ok, wanna note that?
<Keybuk> trying to split a spec across multiple releases, while retaining enough to describe the intent is hard :p
<Kamion> understood
<Kamion> it's just 'cos it's in the use cases
<Kamion> your configuration file format reminds me of fetchmail ;-)
<Keybuk> yes
<Kamion> (whether this is a good thing or a bad, I'm not sure)
<Keybuk> it's actually just supposed to be a pseudo-format in the spec, to give you an idea of the functionality, rather than the actual format -- because I haven't yet put too much thought into that; as the edgy package will just ship set config files anyway and no other package will
<mdz> Keybuk: I'm seeing .po file changes I can't attribute in MOM output (e.g., netbase)
<Keybuk> but it did come out looking very fetchmailish
<Kamion> yeah, you'd want to deal with stuff like quoting of 'end script'
<Kamion> but noted that it's pseudo
<mdz> it seems unlikely that we would have messed with those at all, but there's a delta
<mdz> it's not in netbase_4.24ubuntu3.patch, so I don't think it came from the package itself
<mdz> something with the .po file merging?
<Keybuk> mdz: msg* likes to reflow strings
<Kamion> I think --no-wrap suppresses that although I suspect if you passed that to everything it would *never* wrap even though it should
<Kamion> don't think there's a way to say "wrap iff it was already wrapped"
<sivang> mdz: should I be waiting for review feedback to come about my two specs, or am I missing some info  on the LP spec page for it to be reviewed? (I applied all fixes as noted by previous reviews)
<Kamion> damn, I'd better finish ubiquity-advanced-partitioner
<Keybuk> the spec, or the code? :p
<Kamion> the spec - haven't started yet
<Kamion> (on the code)
* sivang hopes he's not bugging, it's just that spec approval dead line is getting closer, and he would like to know the fixes he needs to apply sooner then later.
<gnomefreak> the issues with ubiquity is from python2.4-* (biggest issue) right?
<Kamion> gnomefreak: no
<Kamion> I'm not even sure what that might mean :)
<gnomefreak> oh ok 
<Kamion> gnomefreak: are you extrapolating from all the crashes being python tracebacks?
<gnomefreak> yes
<Kamion> gnomefreak: ubiquity is written in python, so of course all its crashes will be python tracebacks
<gnomefreak> and im connected that with the python changes
<gnomefreak> ah
<Kamion> that doesn't mean it's python's fault
<gnomefreak> didnt know it was python code
<Kamion> at any rate the frontend is python, if not all of the backend
<Keybuk> whew
<Keybuk> had enough brain-state to redo the merge in just an hour
<Kamion> if somebody would like to review ubiquity-advanced-partitioner, that'd be welcome
<Keybuk> sure
<Kamion> the UI description is unfortunately in text but I think my textual description of a UI will actually be more legible than any drawing I might try to produce :)
<dholbach> good night
<sivang> night dholbach 
<dholbach> night sivang
<LaserJock> Keybuk: ping?
<LaserJock> anybody know if new packages in Sid are being automatically included still?
<Kamion> Keybuk: would appreciate sanity-check of seed-cleanup too
<Kamion> LaserJock: yes, semi-automatically
<Keybuk> LaserJock: they have never been automatically included
<Kamion> there's a script that tells us which ones are new
<Keybuk> unless you could me (and previously, elmo) being an automated process <g>
<LaserJock> Keybuk: I do ;-)
<Keybuk> Kamion: there WAS a script <g.
<Keybuk> rm $VAR_* is dangerous, m'kay
<LaserJock> until Paris I has serious concerns that you and elmo were cron jobs ;-)
<LaserJock> just kidding
<Keybuk> the script was just taken out of my .bash_history anyway
<LaserJock> how often are the new ones included? I got an email from a DD that wants to make sure his new packages are included in Edgy
<Kamion> Keybuk: d'oh
<Kamion> can you put it back in a less dangerous directory? :)
<Kamion> like, er, ~/bin
<Keybuk> Kamion: yeah
<Keybuk> put it back now :p
<Keybuk> I've moved sync-source into ~/bin as well
<Kamion> ta
<Kamion> hmm, duh, just occurred to me that germinate would probably be a whole lot faster if I made stuff like self.all be sets rather than lists
<Keybuk> LaserJock: I haven't done new stuff in a week or so though
<Keybuk> there's a bunch of crap in there I need to get my head around
<Keybuk> was waiting for some merges to happen too
<LaserJock> yeah, I can imagine
<Keybuk> and almost a third of it is X
<LaserJock> fun
<Keybuk> I may just forcibly sync X, to see if it motivates anyone into caring about it <g>
<Keybuk> (actually, I plan to do some of it myself)
<Keybuk> holy fuck, what happened to vim?!
<Kamion> let me guess, you ran into debchangelog folding?
<Keybuk> yes
<Keybuk> how do I make it not do that?
<Kamion> au BufEnter * if &filetype == "debchangelog" | setlocal foldlevel=1000 | endif
<Kamion> not sure that's perfect but it's what I have
<pitti> autocmd FileType debchangelog :set nofoldenable
<pitti> Kamion, Keybuk: ^
<pitti> (my solution, looks a bit cleaner)
<Kamion> hmm, yeah, that would work too
<pitti> but I feel this should be the default
<pitti> right now it's horribly confusing OOTB
<pitti> (IMHO)
<jono> hey
<Keybuk> hey Mr O'Bacon!
<Keybuk> how was GUADEC?
#ubuntu-devel 2006-07-04
<Seveas> guadalicious, I presume
<jono> Keybuk, awesome :)
<jono> Keybuk, had a great time, met some old and new pals and spoke about Jokosher :)
<jono> Seveas, it was :)
<Keybuk> jono: I was sad to miss it, but timing was not good
<Keybuk> btw, is it lug this week?
<jono> Keybuk, damn you and your ways
<jono> Keybuk, it is, but I won't be there - I am away
<Keybuk> heh, where are you this week?
<jono> Keybuk, we need to hook up for a pint sometime soon
<Keybuk> aye, we should
<jono> Keybuk, visiting friends
<jono> Keybuk, its their anniversary
<jono> so wha you guys up to ?
<Keybuk> merges :-(
<jono> heh
<Seveas> Keybuks mom is giving everybody work
<jono> oof
<Keybuk> "new mom"
<Seveas> yeah, the old mom was even worse :
<Keybuk> Kamion: just reviewing seed-cleanup ... got a few secs?
<Kamion> Keybuk: sure
<Keybuk> Kamion: the scope mentions the review of the actual seeds; it would have been nice for the rationales of the changes to be included in the spec
<Kamion> Keybuk: (I've nearly finished the implementation, so I guess now is a good time ;-))
<Keybuk> but I guess that's all long forgotten now
<Keybuk> so maybe just drop mention of that review from the spec and make it a germinate spec
<Keybuk> also (and in particular for the implementation)
<Kamion> Keybuk: I'll note explicitly that it was carried out at the conference
<Keybuk> germinate already supports regexes for the language packs and friends
<Keybuk> so having both regexes and globs for different functionality seems ... bogus
<Kamion> good point
<Keybuk> could this use regexes, OR the existing stuff use globs?
<Kamion> I'll make that regexes
<Kamion> don't really want to break the existing stuff
<Kamion> in retrospect globs would probably have been sufficient for the language pack stuff, but it's too late now
<Keybuk> aye
<Keybuk> if both called out to a common function that could be changed to globs later, that would be nice
<Keybuk> otherwise no other comments there, so if you could fix those bits, it's fine for approval
<jdub> oh man, i'm getting that perl locale spew again
<sivang> I'd like to sign off for the night, will it be okay to sort left over spec approval fixes tomorrow UTC time ?
<Kamion> Keybuk: my current implementation needs 10 exclude patterns to produce IMO sane results following including *-{dbg,dev,doc}
<Kamion> which is pretty much as good as I'd hoped for
<Keybuk> can you mention those in the spec? :p
<Kamion> sure, why not
<Keybuk> sivang: I don't understand the question
<sivang> Keybuk: Well, if on the next review round there will be more stuff to fix, I wouldn't be able to do them until tomorrow morning UTC time, and since the 4th is the spec approval dead line, I'd like to kow if it's okay that I sort these past the dead line and get my specs approved.
<Keybuk> there's a spec approval deadline?
<Kamion> yes, but it's the 6th, not the 4th
<Kamion> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2006-June/000153.html
<Keybuk> 6th sounds more sane
<sivang> hrm 
<Keybuk> 4th is not a Thursday :)
* sivang silently slips out of the room so nobody would notice he asked that question :)
<sivang> Doh!
<sivang> For some reason I made it in my head to be the 4th of July , which incidently, is US independence day ...interesting mis-association.
<sivang> Kamion: thanks for the reminder
<Kamion> Keybuk: actually, how about I cheat, kind of
<Kamion> Keybuk: regexes in seeds are always surrounded by //
<Kamion> Keybuk: so I just extend that to say you can provide globs if you don't surround by //, and you can use either globs or regexes in either context
<Keybuk> sounds fine to me :)
<Kamion> then I get the prettier syntax *and* consistency *and* don't break backward-compat
<sivang> night Kamion , Keybuk , laters
<Keybuk> WIN!
<Kamion> night sivang
<Keybuk> sivang: g'night
<LaserJock> sivang: I thought the same thing, don't feel bad ;-)
<Kamion> Keybuk: spec adjusted
<Kamion> oh I'll just dump the current exclusions in
<jdub> weird:
<jdub> $ locale
<jdub> locale: Cannot set LC_ALL to default locale: No such file or directory
<jdub> LANG=en_AU.UTF-8
<jdub> LANGUAGE=en_AU:en
<jdub> 
<Keybuk> strace
<Keybuk> Kamion: ok, approved
<Kamion> thanks!
<Keybuk> given I suspect strongly it'll move straight to Implemented <g>
<jono> hey jdub 
<Keybuk> am about 1/3 though u6y partioner
<Kamion> I'm not going to do the germinate regex changes tonight, but I'll attack that tomorrow
<jdub> Keybuk: http://people.ubuntu.com/~jdub/2006/locale-strace.txt
<Keybuk> jdub: odd
<Keybuk> jdub: dpkg-reconfigure locales
<jdub> Keybuk: hrm, it's "... done" for all of them (not skipping)
<jdub> $ locale
<jdub> LANG=en_AU.UTF-8
<jdub> LANGUAGE=en_AU:en
<jdub> 
<Keybuk> what's your LC_COLLATE ?
<jdub> LC_COLLATE="en_AU.UTF-8"
<Keybuk> weird *shrug*
<jdub> everything's en_AU.UTF-8 apart from LANGUAGE
<jdub> but it's all ok now
<Keybuk> wrong ABI I guess
<Keybuk> dpkg --configure -a
<lifeless> 'lo
<jono> hmm
<lifeless> gnight
<mdz> sivang: if you've revised it, then you need to set it back to 'review' state to get further review
<zul> hey
<Keybuk> fabbione: ping?
<Lathiat> wow the zeroconf thread fired off into a mess yestrday
<Keybuk> it reached four levels
<Keybuk> after that, all threads are inherently useless
<Lathiat> heh
<zul> heh...i dont have the energy to read that tonight
<Lathiat> i skimmed over the second useless half of it
<robertj> neuralis: you home?
<neuralis> robertj: sorry, have we met?
<robertj> neuralis: nope, just stalking based off a poste to -devel. Was going to ask you about the whole zeroconf flameware and whether an amended policy for zero-conf was 100% off the table
<robertj> because the one thing I haven't read is "Let's do another code-audit and amend our policy"
<neuralis> it's actually been relatively non-flamewarish. no one has called anyone an idiot yet ;)
<neuralis> robertj: i don't think an amended policy is absolutely, completely off the table, but it's not too far from. going down the exceptions road is a slippery slope.
<neuralis> robertj: i'm very strongly against it, to be sure. my mind could be changed, but it would require a good spec.
<robertj> neuralis: I will say that I think a firewall is a non-solution
<robertj> neuralis: would you accept a trite saying if it was true :)
<neuralis> robertj: it might well be the case that the right thing to do is to open up zeroconf. but i want a spec convincing me, not a bunch of people shouting at each other on -devel.
<robertj> the little saying that grinds my mind is this: things should be a simple as possible but no simpler
<robertj> but it argues both sides of the coin, one in terms of UI and the other in terms of policy :)
<neuralis> robertj: basically, i'm fully open to discussing this, but NOT without a spec. i want a spec that looks at the implications, zeroconf's privilege needs, possible solutions, et cetera.
<robertj> neuralis: is there really not a spec yet?
<neuralis> robertj: not that i've seen, but i haven't been looking at zeroconf too closely.
<neuralis> robertj: there's kubuntu-easy-zeroconf targetting edgy, and zeroconf targetting dapper (deferred).
<robertj> digging now
<neuralis> robertj: both are looking at a way to enable zeroconf easily, but keep it turned off by default, so no spec exists that details what you're proposing.
<neuralis> robertj: https://wiki.ubuntu.com/ZeroConfSpec and https://wiki.kubuntu.org/KubuntuEasyZeroconf
<robertj> ahh I was looking in launchpad
<neuralis> these are launchpad specs, yes.
<robertj> I wans't finding em there, I should have used the Wiki
<neuralis> robertj: they're there as zeroconf and kubuntu-easy-zeroconf, respectively. 
<robertj> ahh now i'm on the ubuntu spec page
<robertj> neuralis: your certainly right, no deluge of information in these "specs"
<neuralis> robertj: it would be very helpful if you decided to remedy that.
<robertj> should I start a new wiki page & spec?
<robertj> ZeroConfSpec seems fine but the launchpad description does not
<robertj> (fine as a name that is)
<neuralis> yes, i'd start a new spec. you have until the 6th to get the spec approved, so you'd ideally want to have it done in a day or so.
<robertj> you going to be on for the next little bit?
<bddebian> Howdy
<neuralis> robertj: 10pm here, i'm about to leave the office, but i'll be back on later tonight. feel free to mail me and request feedback.
<robertj> will do, thanks
<Keybuk> hmm
<Keybuk> I have absolutely no idea what I've done to my knee :-/
<zul> banged it?
<bddebian> Blown ACL? :)
<Keybuk> it's a dull pain _under_ the knee cap
<bddebian> Ugh
<bddebian> Water on the knee?
<zul> i think i have that
<Keybuk> yeah, that's vaguely what it feels like
<Keybuk> probably a result of insufficent exercise at the conference
<Hobbsee> morning Keybuk 
<bddebian> Bah, I'm old, fat, and out of shape and my knee doesn't hurt :-)
<tseng> bddebian++
<bddebian> Heya tseng
<Keybuk> I've got an edgy knee ... painful at the moment, but I'm sure it'll be fine given time
<bddebian> hehe
<neuralis> Keybuk: it'll be edgy+1, given time.
* Keybuk wonders when that "foo+1" notation started
<Hobbsee> Keybuk: i believe when foo = breezy
<Hobbsee> when #ubuntu+1 started
<Keybuk> Hobbsee: nah, it was a lot earlier than that
<Hobbsee> although, maybe earlier
<bddebian> Keybuk: I dunno but it's irritating
<Hobbsee> bleh
<Keybuk> I think foo was originally "woody"
<Keybuk> bddebian: why?
<Keybuk> Hobbsee: it's definitely something we inherited from Debian, and just started using when we ran out of pre-decided names
<bddebian> Well not the term itself, just the usage.  Edgy barely opens and people start spouting Edgy+1.. :-)
<Hobbsee> Keybuk: ah right
<Keybuk> http://groups.google.co.uk/group/linux.debian.devel/browse_thread/thread/d0bf5b3ae3e75625/433891e87d7f0ab4?lnk=st&q=woody%2B1&rnum=8&hl=en#433891e87d7f0ab4
<tseng> bddebian: because ubuntu is transparent enough for the noisy kids to make a fuss about the next release
<Keybuk> bddebian: that's the best thing possible!
<tseng> or maybe because the next release isnt 5 years in the future?
<Keybuk> it's a sign of a mature time based release process when you can talk about "not for this release"
<Keybuk> hmm, yeah, woody+1 is the earliest I can see ... don't find a potato+1 or slink+1 in my mail archive
<Keybuk> woody+1 was probably the first time Debian sat down and thought about "the next release" while still doing a release (it was the first time Debian had testing/)
<bddebian> OK,OK, I give up
* Hobbsee gave up long ago.
<zul> its like that nine inch nails song
<zul> i tired...i gave up
<Keybuk> zul: "Closer" ?
<zul> yeppers
<Keybuk> or a _different_ Nine Inch Nails song? :p
<Keybuk> there's many to choose from
<tseng> I think there is one called "Gave Up" actually
<Keybuk> yeah, I was just thinking, I don't think I got the right one there <g>
<bddebian> NiN..pfft.. Metallica...
<zul> whatever
<zul> Keybuk:  http://www.azlyrics.com/lyrics/nineinchnails/gaveup.html
<robertj> Keybuk: can you look over https://wiki.ubuntu.com/ZeroConfPolicySpec please?
<siriusnova> i feel really bad asking this in here but no one in #ubuntu can help me
<siriusnova> :(
<bddebian> You haven't asked anything
<siriusnova> i need to recompile wpa supplicant because i am using patched madwifi drivers (no WPA menus show up in network manager) 
<siriusnova> :/
<siriusnova> how do i recompile wpa supplicant so that i can use Network manager and my new drivers, wep works fine
<siriusnova> basically is my question 
<siriusnova> i know ths is the wrong place to ask but no one in #ubuntu could help me
<siriusnova> sry :(
<bddebian> siriusnova: Sorry, I don't know
<siriusnova> its ok
<siriusnova> no one else does either haha
<bluefoxicy> siriusnova:  file bugs with the patches and the issue and maybe somedev will look at it and fix it :P
<siriusnova> hrmm ok
<siriusnova> but do i need to recompile wpa after using patched drivers or not?
<siriusnova> im confused about the issue
<bluefoxicy> I have no idea
<siriusnova> me either heh 
<bluefoxicy> I am more thinking, why did you patch the drivers
<siriusnova> for security testing, packet injection
<bluefoxicy> file a bug on whatever problem required it for a start-- ah, that sounds like a useful feature :)
<siriusnova> aircrack-ng etc..
<bluefoxicy> (oh yes, "Ubuntu now supports cracking wifi encryption" in the list of new features for Edgy XD)
<siriusnova> the default madwifi drivers dont support it so they have to be patched, i used madwifi-old and patched them. Network Manager with wep works fine but there is no WPA menu so i am assuming i had to recompile wpa too but i cant find any detailed information regarding what exactly i have to do
<bluefoxicy> tseng: ssp looks to be on by default in edgy now, did pitti/doko fix the propolice issue on sparc?
<bluefoxicy> .... o.O
<bluefoxicy> I am STILL trying to figure out why certain things are in ubuntu-desktop (libgnome2-perl for now) ...
<siriusnova> ok another stupid question, the madwifi in Dapper is madwifi-old right?
<wasabi> All this ZeroConf talk is interesting.
<jsgotangco> :)
<bluefoxicy> what does Ubuntu use cpio for...?
<msw> bluefoxicy: initramfs?
<bluefoxicy> msw:  figured it probably did... you could use tar/gzip for that or cpio, either or.
<msw> bluefoxicy: note that you have to have the archive unpacker in kernel code -- you don't want to have to support every formt under the sun
<msw> format
<bluefoxicy> oh
<bluefoxicy> cpio works on its own archive format, not on tarballs?
<msw> right
<bluefoxicy> wait.. I thought initrds were EXT2 file system images that were gzip'd?
<msw> that'
<msw> that's old initrd -- not initramfs
<bluefoxicy> what's initramfs?
<msw> bluefoxicy: http://marc.theaimsgroup.com/?l=linux-kernel&m=101095500820185&w=2
<msw> alas, I must retire - gnight
<msw> see also http://lwn.net/Articles/14776/
<bluefoxicy> msw:  interesting
<bluefoxicy> msw:  I had considered busybox + tarball on the initrd; mount a tmpfs; unpack the tarball to it; copy busybox into it; pivot_root; exec a fresh /linuxrc; umount the ramdisk
<bluefoxicy> which would appear to generate the same results
<bluefoxicy> I guess kernel code to do this shorter is simpler though ;)
<msw> somewhat -- initramfs's size is dynamic
<bluefoxicy> so is a tmpfs
<bluefoxicy> you specify a max size but really it uses about 0 until it stores files
<msw> whereas initrd has to have a RAMDISK_SIZE set large enough to decompress the image
<bluefoxicy> yeah
<bluefoxicy> (it doesn't calculate that on the fly?)
<msw> no
<msw> you can set it on the kernel command line
<bluefoxicy> ok point made :)
<msw> but it's not dynamic
<bluefoxicy> night msw
<msw> g'night
<renewip> hi, can I write on ntfs partition if I rebuild ubuntu kernel ???
<wasabi> grrr. udev.
<anibal> fabbione, ping
<fabbione> morning
<fabbione> anibal: pong
<siriusnova> im going to shoot my laptop
<siriusnova> :X
<stub> Launchpad will be going down in 15 minutes for its regular code update. Estimated downtime is 20 mins.
<anibal> fabbione, when you have a chance, please have a look at my package nfs-utils_1.0.8-10ubuntu1
<fabbione> anibal: where is that supposed to be?
<crimsun> 14:40 < crimsun> fabbione: anibal has prepared merged nfs-utils at  http://users.monash.edu.au/~anibal/ubuntu/nfs-utils/ . They look sane to me.
<fabbione> oh
<fabbione> meh.. ok
<fabbione> yeah
<fabbione> it's kind of overkill to check a merge
<fabbione> it's faster to do it 
<fabbione> but ok
<crimsun> fabbione: just following protocol ;)
<anibal> fabbione, I would like to keep my debian packages in sync with the ubuntu packages
<fabbione> anibal: yes i could guess that
<fabbione> i don't disagree at all in the reason why
<fabbione> anyway fetching
<fabbione> anibal: did you consider to join the MOTU and later core-dev?
<anibal> fabbione, I'm very interested to join the MOTU and later core-dev :)
<fabbione> anibal: ok
<anibal> it would be nice to upload same versions of packages to debian and ubuntu at the same time :)
<anibal> mdz, hello
<fabbione> anibal: what's the diff between the deb and ubuntu package by now?
<fabbione> i mean what's leftover?
<sivang> morning
<anibal> the lbs in the init.d scripts
<fabbione> and that's it?
<anibal> yep
<anibal> soon the debian and ubuntu packages will be the same
<fabbione> anibal: didn't debian adopt the lsb stuff already?
<anibal> yep
<anibal> it's one of our release goals
<fabbione> right
<fabbione> so why can't we just merge the lsb changes in -11 and we sync from you?
<fabbione> what's holding that up?
<anibal> testing
<anibal> I need to test it
<fabbione> anibal: what kind of testing would you like to see?
<fabbione> we have been using this changes for the last 2 years + or -
<fabbione> and i do personally use nfs here
* fabbione can prove it
<anibal> and also, I want to have the current package moved to etch, before I introduce the lsb changes
<fabbione> fair enough
<fabbione> all good reasons
<fabbione> ok
<fabbione> i will upload these changes to edgy
<anibal> fabbione, ta
<fabbione> but can you be so kind to remind me when -11 with lsb changes will hit sid?
<fabbione> at that point we can enable the autosync
<anibal> ok
<fabbione> and you just upload to sid
<fabbione> does it sound like a plan for you?
<anibal> yep, sound good to me :)
<anibal> s/sound/it sounds
<fabbione> perfect
<anibal> thanks again
<fabbione> no problem
<fabbione> anibal: uploaded
<fabbione> thanks for the merge
<anibal> good :)
<fabbione> anibal: did you get all the bits and pieces for NFSv4 too, right?
<fabbione> (catching up on -devel)
<fabbione> E: Could not open file /var/lib/apt/extended_states - open (2 No such file or directory)
<fabbione> E: Failed to open StateFile /var/lib/apt/extended_states
<fabbione> mvo: ^^
<fabbione> mvo: what the hell is that?
<mvo> fabbione: ah, thanks
<fabbione> mvo: freshly updated EDGY :P
<sivang> probably the code that was moved from aptitude to apt? :)
* sivang updates as well
<mvo> fabbione: I'm fixing this with the next upload
<mvo> sivang: yes
<fabbione> mvo: ok thanks :)
<sivang> mvo: cool :) Will I be able to call the package left over removal stuff from another program? 
<mvo> sivang: yes, I will send a mail about this soonish
<sivang> mvo: yay
<mvo> fabbione: what operation did give you this message?
<fabbione> apt-get install libx11-dev
<fabbione> mvo: everything did install fine
<fabbione> the error was the very end
<mvo> fabbione: thanks, I have it here now too
<fabbione> Setting up libxt-dev (1.0.0-0ubuntu3) ...
<fabbione> E: Could not open file /var/lib/apt/extended_states - open (2 No such file or directory)
<fabbione> E: Failed to open StateFile /var/lib/apt/extended_states
<fabbione> mvo: no problem at all
<pitti> hi ivoks 
<ivoks> pitti: hi
* sivang hugs pitti 
<ivoks> i have great news
<pitti> hi sivang 
<ivoks> pitti: i found python ipp library
<pitti> ivoks: oh, I thought you knew about it?
<ivoks> pitti: it's even better than redhat's pycups
<pitti> ivoks: jamesh wrote a python module for it once
<pitti> but I thought you would know it
<ivoks> pitti: jamesh?
<ivoks> i found ipplib
<ivoks> (c) 2003, 2004, 2005, 2006 Jerome Alet
<jamesh> ivoks: mine is at http://www.gnome.org/~jamesh/code/ipplib.py
<jamesh> haven't touched it for a few years
<ivoks> heh
<ivoks> this one is fresh (may 2006)
<ivoks> but i'll take a look at yours
<pitti> jamesh: your's was very nice for a few debugging tasks so far :)
<ivoks> maybe combine it with this one
<jamesh> mine worked okay with cups and HP jetdirect cards
<jamesh> but I had some problems talking to a Canon ImageRunner
<ivoks> i needed to talk with cups only, atm
<ivoks> svn://svn.librelogiciel.com/ipplib/trunk iplib
<jamesh> ivoks: actually http://www.jamesh.id.au/files/ipplib.py is a little newer
<ivoks> ipplib
<ivoks> same name, but somewhat different :)
<ivoks> i'll tak a look at your ipplib later today, when i'm back from work
<ivoks> bye for now
<dholbach> good morning
<carlos> doko: ping
<sivang> morning dholbach 
<raphink> hi sivang, dholbach
<dholbach> hi sivang, raphink
* sivang hugs raphink 
<raphink> :)
<raphink> hi cousin :)
<raphink> lol
<sivang> hehe
<sivang> raphink: hey Mr. Grunberg :)
<raphink> ;)
<doko> <carlos> doko: ping
<doko> <doko> carlos: pong
<carlos> doko: I'm on a phone call, give me some minutes...
<anibal> fabbione: that was the last package waiting for NFSv4, everything looks good now :)
<carlos> doko: I'm back
<fabbione> anibal: ok thanks
<carlos> doko: what's the status of OO.org language packs?
<fabbione> who is Glite that just edited UbuntuCluster ?
<carlos> doko: other than the warning we saw? did you manage to workaround the long path problem?
<carlos> s/saw?/saw,/
<doko> carlos: yes, removing two languages :)
<carlos> doko: so, are we able to upload an update?
<\sh> mvo: ping 
<mvo> \sh: pong
<\sh> mvo: aptitude: Depends: libapt-pkg-libc6.3-6-3.11 but it is not installable
<\sh> mvo: freshly created edgy chroot :)
<mvo> \sh: its edgy ;)
<mvo> \sh: there is a new version of aptitude uploaded, its just not build yet
<mvo> \sh: we got a new apt (PHEAR!)
<Kamion> seb128: libcairo binaries newed
<seb128> Kamion: thank you!
<\sh> mvo: yes ;) ah ok...I thought it was the latest aptitude
<doko> carlos: carlos didn't check yet, trying to get 2.0.3 built before seb128 starts to upload the new gnome
<mvo> \sh: 0.4.1-1.1ubuntu2 is currently waiting to be build
<\sh> mvo: k
<carlos> doko: ok
<dholbach> Gloubiboulga: i'm just merging goffice and gnumeric - it'd be nice if you'd look over them (later) and see if I retained your *-gtk* changes correctly
<ogra> Riddell, do you have any idea what happened to the plans of the kdeedu guys to split the source in single packages ? it seems to get bigger and bigger with every release
<Riddell> ogra: I've not heard of any such plans, packagers keep asking for it but KDE quite like their large modules
<Riddell> ogra: are you merging kdeedu?
<ogra> i'm about to ... seems trivial
<ogra> unless you claim it
<Riddell> nope, go ahead
<Riddell> although adding the ocaml stuff to it would be cool
<ogra> its just the 60Mb upload thats a *bit* annoying everytime :)
<Riddell> unfortunetely the ocaml build stuff is broken
<ogra> oh, so i should probably wait and jump on something else for now
<Riddell> why?
<ogra> well, if it ftbfs ...
<ogra> (i like to see my results asap after doing package work, else i tend to forget about it :) )
<Riddell> it'll get stuck in NEW, I think there's a kdeedu-dbg package added
<Riddell> but the ocaml stuff is broken upstream, it doesn't do builddir!=sourcedir
* Kamion halves germinate's runtime
<Riddell> so to add it to the kdeedu package you'd need to do funky tricks to get it to build
<ogra> any ETA when that'll be fixed ?
<Kamion> ok, since you two (Riddell/ogra) are here, I think I should have seed-cleanup pretty much implemented, so shortly I'll change the Ubuntu seeds to say "Extra-Include: *-dbg *-dev *-doc" and a few excludes to eliminate the packages matching those patterns that we don't want
<\sh> when is the cronjob running which is pushing newly build packages to a.u.c?
<Kamion> you will have a somewhat interesting merge as a result
<pitti> \sh: at :03 hourly AFAIK
<\sh> pitti: thx
<Kamion> feel free to talk to me if you're confused, but the upshot is that we shouldn't need to seed -dbg/-dev/-doc packages by hand any more
<ogra> Kamion, fun :)
<Kamion> \sh: it *starts* at :03 hourly but takes quite a while to run; in practice the mirrors don't get triggered until :40 or so
<Riddell> Kamion: cool
<\sh> hmm...complete ubuntu server with apache, nfs, tftp, dhcp3, fai + configuration in 150secs...too long
<\sh> time to beat: <=120secs
<pygi> jdub, you have a sec?
<Hobbsee> pygi: i believe he's severely jetlagged and asleep
<pygi> Hobbsee, oki, thanks :)
<ogra> Riddell, libfacile-ocaml-dev is already in kdeedus build deps
<ogra> seems thats a no op for us
<Riddell> ogra: oh, interesting
<Riddell> ogra: want to do the main inclusion report for libfacile-ocaml-dev? :)
<ogra> meh, but they also added a dep for a ttf we dont have ...
<pitti> Riddell: ouch, do you want to reintroduce ocaml to main?
<ogra> well, i have to do one for ttf-sjfonts, so i can do the one for libfacile-ocaml-dev as well
<pitti> Riddell: we were about this -><- close to throw it out
<Riddell> pitti: it's mostly up to ogra, whether he wants/needs the functionality it adds
<ogra> pitti, write me some educational gnome apps and we can drop kdeedu and ocaml from main :P
<ogra> (i'd *so* love to drop it)
<pitti> ogra: find -type f | xargs sed -i s/G/K/g in the sources is not eough to port it :-P
<ogra> :P
<Riddell> ogra: you can still remove the ocaml stuff if you want to keep pitti happy
<ogra> i guess i'll do that then ... we lived fine without it in dapper
<ogra> at least i have heard no complaints yet
<\sh> what kdeedu app needs ocaml?
<ogra> all ?
<Riddell> \sh: kalzium I think
<ogra> at least kalzium
<Riddell> and it doesn't need it, it just adds some extra features if you have it
<ogra> which is the main reason for kdeedu in edubuntu
<\sh> and kalzium needs it to run properly or is it just some scientist gimmick?
<pygi> ogra, sorry for interupting, but arent we removing kdeedu from edgy?
<ogra> its an optional add on
<ogra> pygi, if you have a replacement 
<\sh> ogra: then throw ocaml somewhere but not in kdeedu ;)
<Riddell> it can probably be split out into a separate source package without too much difficulty
<ogra> you mean kalzium ? 
<Riddell> I mean the ocaml bits of it
<ogra> hmm
<pygi> ogra, I don't really have a replacement, but ... 
<Riddell> ogra: so I'd say remove the ocaml dep to keep pitti happy and I'll find an elite MOTU to build the ocaml stuff in a separate universe package
<\sh> pygi: without kdeedu edubuntu has nothing...I think it helds the majority of edu apps...but I can be wrong
<ogra> pygi, well, Kamion donated 20MB free space to the CD so if we now could switch yelp to xulrunner and have epiphany as default browser that should gain us a lot in the end ...
<ogra> Riddell, fine with me :)
<spacey> epiphany++ =)
<pitti> Riddell, ogra: don't worry too much, ocaml isn't a real burden
<pitti> if you need it, we keep it
<ogra> pitti, no we dont *need* it (apparently)
<tseng> ogra: so, is there a real plan to move anything to xulrunner?
<tseng> ogra: i am merging gecko-sharp2 which uses libxul in debian
<ogra> tseng, well, edubuntu needs to switch to epiphany in any case
<tseng> ogra: i was going to build on firefox-dev per our last talk
<tseng> and epiphany will use libxul?
<ogra> tseng, ask the epiphany maintainer :)++
* tseng tickles seb128 
<ogra> seb128, do you plan to go with debian here ? 
<ogra> i know there is an informal spec
<tseng> I am assuming it is pretty safe to mix firefox-dev and libxul-dev packages at runtime?
<dholbach> ogra: epiphany and everything else will build with firefox
<ogra> no idea, i'd drop all ff-dev deps if possible
<dholbach> ogra: it makes no sense to have firefox AND xulrunner source in main
<ogra> dholbach, why ? thats a huge delta to debian we produce here
* tseng goes ahead with his building with firefox-dev
<dholbach> it's not, it's some characters in debian/control and debian/rules
<ogra> so i still have to waste tens of megabytes in the edubuntu CD, sigh
<dholbach> ogra: it's not my decision, but try to ask pitti and iwj if they want to support xulrunner and firefox in main
<ogra> OLPC wont work either withhout xul btw
<dholbach> ogra: firefox supports xul too - xulrunner is just the name of the 'engine'
<ogra> yes
<ogra> but firefox pulls in language packs
<Kamion> indeed, if firefox can be built against xulrunner then that would solve the problem
<ogra> its not ff itself
<ogra> its the deps that make probs 
<Kamion> we may not want to push that ourselves, but the xulrunner maintainer in Debian is also one of the firefox maintainers
<pitti> dholbach, ogra: If firefox can use xulrunner, then I'm fine with it; otherwise, having two copies of ffox code on the CD seems bad to me (not even considering the overhead of providing security updates for two copies)
<ogra> s/make probs/eat space/
<dholbach> for that we need a supported and maintained "firefox-without-xulrunner-parts" tarball from upstream
<ogra> pitti, my biggest prob are the deps of yelp and epiphany
<ogra> if these two could swwitch i'd already be fine ... 
<ogra> i'm not after commiting to be xulrunner maintainer, but if thats the only way i'd even take the bllame here
<ogra> (indeed that still duplicates the source)
<dholbach> iwj: do you know something about the state of things concerning "firefox-without-xulrunner-parts"?
<heno> mvo: ping
<heno> dholbach: will you guys be taking this https://wiki.ubuntu.com/FutureOfGst forward for Edgy?
<dholbach> heno: yes, carlos garnacho will work on some select fixes and problems
<heno> dholbach: ok, there is some related work being done by these people: http://www.ubuntuforums.org/showthread.php?t=207894 FYI
<tseng> dholbach: carlos rocks!
<dholbach> heno: that's more about control-center, isn't it?
<heno> dholbach: yes (heno is still not quite clear on where those overlap ...)
<heno> dholbach: any work on control-center being planned I could look at?
<dholbach> heno: to me it seems they are only referring to control-center
<dholbach> heno: just upstream control-center CVS, sorry
<heno> ok
<sladen> ogra: we ported xpdf to poppler, which is a fairly similar setup
<ogra> sladen, yes, but poppler is in main already and doesnt duplicate source
<Riddell> pitti: any opinion on adding back gpgsm to kdepim in edgy?  I've talked to the upstream and he insists its stable despite having a .9 version number
<pitti> Riddell: that's gnupg2, right?
<Riddell> pitti: yes
<pitti> Riddell: is there any ETA for 2.0 release?
<pitti> Riddell: I wouldn't mind too much having it in main
<Riddell> pitti: "sometime in summer", but I wouldn't hold my breath for it
<tseng> any build admins who can try kicking mono-tools?
<fabbione> tseng: you need to ask Keybuk when he is around
<tseng> fabbione: k.
<ogra> hrm, why the heck did they add cdbs as build dep to kdeedu ... there are no cdbs bits in it at all ...
* ogra sees the conflicts in rules and shuts up
<Gloubiboulga> dholbach, ok (about goffice/gnumeric), I'll have a look
<dholbach> Gloubiboulga: i wait on a sync and upload another merge before - i'll notify you
<iwj> dholbach: No, I know nothing about that.
<iwj> Sorry.
<Kamion> I'm about to do a sync run now
<dholbach> iwj: it would have been the perfect opportunity to introduce it in a "edgy" release cycle. :-)
<dholbach> Kamion: thanks a lot - you rock! :-)
<tseng> https://launchpad.net/people/brandon/+packages
<tseng> if anyone missed this page like I did
<tseng> most useful thing of all time
<fabbione> oh cow
<fabbione> they fixed it
<pitti> fabbione: moo?
<fabbione> my page is endless.. i don't even want to think about Colin or Seb :)
<zul> hey
<pitti> hi zul
<zul> hey pitti how is it going?
<Hobbsee> hi zul 
<zul> hey Hobbsee 
<heno> what's the right procedure for suggesting removals from edgy main? 
<ogra> grmbl ... you cnat build that silly kdeedu sourcepackage in dapper, sigh
<\sh> a segmentation fault during building is not a good sign
<Kamion> heno: file a bug on the package concerned and subscribe ubuntu-archive
* heno remembers seeing a spec somewhere, but can't find it ...
<heno> Kamion: ok, thanks
<Kamion> heno: see https://wiki.ubuntu.com/DeveloperResources for documentation of this and caveats
<\sh> removals from main?
<heno> cool, thx
<ogra> \sh, demotions to universe
<Kamion> heno: oh, you meant demotions, not removals?
<heno> Kamion: yes, demotions 
<Kamion> heno: ok, see "Seed management" in DeveloperResources
<heno> thx
<\sh> anyone familiar with dietlibc?
<Riddell> ogra: why not?
<ogra> Riddell, it needs cdbs 0.4.37
<Riddell> ogra: which kde.mk is it using?
<ogra> debian/cdbs/debian-qt-kde.mk: No such file or directory
<Hobbsee> ogra: what? why?
<Hobbsee> bleh
<Hobbsee> guess you can call it anything if you're shipping it with the package
<ogra> it has a build dep on cdbs >= 0.4.37 which apparently ships that file 
<Riddell> debian-qt-kde.mk is part of the package
<ogra> its just annoying that i have to build an edgy chroot just to build the source package
<Hobbsee> oh good
<Riddell> hopefully it'll use the stock kde.mk
<Riddell> ogra: if you're developing for edgy it's kindae a good idea to have an edgy chroot
<ogra> Riddell, well, for most sourcepackages a edgy pbuilder is sufficient ... 
<\sh> bin-i386/diet gcc -pipe -nostdinc -Os -fomit-frame-pointer -falign-functions=1 -falign-jumps=1 -falign-loops=1 -mpreferred-stack-boundary=2 -Wall -W -Wchar-subscripts -Wmissing-prototypes -Wmissing-declarations -Wno-switch -Wno-unused -Wredundant-decls -o bin-i386/elftrunc contrib/elftrunc.c
<\sh> make[1] : *** [bin-i386/elftrunc]  Segmentation fault
<\sh> not for this 
<Kamion> doko: re 51818, did you check out the wxwidgets2.6 changes?
<Kamion> ogra: and a pbuilder is what exactly if not a chroot? ;-)
<ogra> having to have a chroot to just create a sourcepackage is just bad ... you'll not be able to backport for example ...
<fabbione> ogra: you should be running edgy no matter what :)
<ogra> Kamion, well, an additional one just to have a source package i can throw into pbuilder 
<Kamion> 'pbuilder login' HTH
<fabbione> ogra: you have pbuilder login to enter the chroot
<ogra> fabbione, and suffer from all the breakage you guys introduce ? :)
<fabbione> ogra: and the chroots are in /var/ somewhere
<ogra> Kamion, i know
* fabbione larts ogra 
<fabbione> edgy is BUG FREE
<ogra> i find it still wrong for a source package to do that
<zul> hey fabbione 
<fabbione> hey zul
<Hobbsee> fabbione: famous lasts words :P
<Yagisan> of course there are no moths in edgy ;)
<ogra> fabbione, really 
<ogra> 7me quickly starts the upgrade
<fabbione> Hobbsee: it works (for me) so it must work for everybody
<fabbione> Hobbsee: if it doesn't work, your setup is wrong
<Mithrandir> fabbione: yeah, must be hardware bugs.
* ogra expects evo cant crash more often for him than in dapper and ff might still work ...
<fabbione> Mithrandir: they are indeed
<zul> ogra: evolution is so much fun though
<ogra> Mithrandir, sorry for the makedev merge yesterday, Kamion told me about your plans but it was urgent to fix a fuse bug 
<ogra> zul, especially on powerpc :)
<ogra> i.e. if you forget that searching in mailboxes gets evo in an infinite crash loop and you have to delete your mailboxes completely to make it work again, these are the moments where i think about reinstalling breezy :P
<zul> yeah thats why i dont use it
<ogra> well up to breezy it worked fine ...
<Mithrandir> evo is quite debuggable so it should be easy enough to track down and get a fixed version into -updates and edgy, though
<tseng> so
<tseng> so far evo 2.7 has worked better for me
<ogra> in dapper i get at least one "evo recieved an X window system error" a day if i just move the mouse over the window and that upstream search bug they dont find a fix for
<ogra> Mithrandir, its an upstream bug they didnt find the cause for in time ...
<ogra> but well, i'll go to edgy, things can only get better :)
<tseng> edgy so far is our smoothest devel cycle yet
<tseng> ironically
<ogra> tseng, wait until rodarvus starts his work :P
<rodarvus> tseng, things will change on this regard ;)
<tseng> rodarvus: oh no!
<tseng> daniels-lite
* Yagisan looks forward to less USN's with edgy :)
<tseng> (I *hope* -lite)
<doko> Kamion: yes
<Kamion> doko: thanks
<sivang> ogra: I switched to thunderbird. Gives me much better workflow with imaps
<ogra> sivang, i'm fine with evo... as long as it works ;)
<sivang> ogra: it mostly worked for me actually, but it took too much time to fetch emails, and to shutdown when I wanted to close my machines. Also I find it easier to read emails with it and do all srots fo sorting and grouping
<ogra> sivang, but it would be boring if i had nothing to rant about on days you can only survive with 2kg of icecram to your left and right and with your feet in a bucket of iced water ;)
<sivang> ogra: ha ha ha, I'm actually trying to use my room's AC, currenly it failes to really cool the room :)
* sivang needs to get a bucket of iced water as well
<doko> Kamion: please sync #51777 as well, so that the other python packages can build
<sivang> malone #51777
<Ubugtu> Malone bug 51777 in Ubuntu "sync requests" [Untriaged,Fix released]  http://launchpad.net/bugs/51777
<sivang> doko: I saw there was already one sync of python-support, no? (as in the "updated mergers" in m.u.c)
<mvo> \sh: I will request a ssync for cpunit (you touched it last, that is why I tell you :)
<mvo> cppunit
<Kamion> doko: ...
<Kamion> doko: I did that first
<Kamion> can a member of ubuntu-dev confirm bug 51824, please?
<Ubugtu> Malone bug 51824 in fonttools "sync fonttools 1.99+2.0b1+cvs20060225-1 from unstable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51824
<doko> Kamion 51824 looks ok, just python changes
<Kamion> doko: thanks, could you put a note in the bug?
<Kamion> doko: oh, don't bother, it was one of your python syncs already
<Kamion> thanks
<doko> Kamion: hmm, didn't get an email for the 51777 syncs
<doko> I should subscribe to edgy-changes ...
<pitti> Keybuk: did you plan to process NEW today?
<Keybuk> pitti: I process NEW *everyday*
<pitti> ok, cool :)
<Kamion> doko: they're definitely in accepted
<Kamion> with the exception of the one that landed in new
<pitti> Keybuk: I uploaded the first version of pkg-create-dbgsym today; it should remain in universe for now
<pitti> Keybuk: (it's not urgent, just telling you for the overrides)
<\sh> slomo: ping
<\sh> grmpf
<sivang> \sh: He'll be online this evening
<sivang> \sh: he has project in uni he needs to attend to, etc
<\sh> libquicktime sync depends on libavcodec-dev which is in universe, because ffmpeg is universe, too
<pitti> Keybuk: if you could accept gnutls13 from NEW soon, that would rock
<\sh> or are there plans to promote ffmpeg to main?
<Kamion> $ q info gnutls
<Kamion> Listing ubuntu/edgy (NEW) 0/17
<zul> BenC: ping
<tseng> \sh: are you kidding?
<\sh> tseng: no...looks like I have to deal with libquicktime first
<Keybuk> Kamion: u6y-advanced-partitioner approved
<tseng> Keybuk: hi, can you please kick mono-tools, evolution-sharp
<Kamion> \sh: I believe that one will need a merge but I'm not sure
<Kamion> Keybuk: thanks
<Keybuk> tseng: define "kick"
<pitti> Kamion: oh, hm; it's in unstable, I thought we'd automatically get it
<\sh> Kamion: it was a sync on 2006-06-28 
<tseng> Keybuk: "rebuild the same source package on the buildd because it theoretically works fine now"
<\sh> Kamion: https://launchpad.net/distros/ubuntu/edgy/+source/libquicktime/
<tseng> evo-sharp had a broken evo-dev at the time, bad luck
<tseng> similar for mono-tools
<Kamion> pitti: it's on the new-packages list
<Keybuk> tseng: ah, you want a give-back
<Kamion> Keybuk: do you wanna sync gnutls13? I'm bored of archive admin for a bit
<tseng> Keybuk: hm right sorry
<Keybuk> Kamion: sure
<Keybuk> tseng: ok, all needs-build again
<tseng> Keybuk: thanks!
<Keybuk> pitti: any ubuntu changes?
<pitti> Keybuk: for what?
<Keybuk> gnutls13 ?
<pitti> Keybuk: oh, that's not in ubuntu yet
<Kamion> it's new
<Keybuk> oh, I see, it's literally NEW in Debian
<Keybuk> E: libgnutls-dev is in main but it's source (gnutls13) is not.
<pitti> Keybuk: right now, the gnutls12/13 libtasn1-2/3 situation is quite confused
<Keybuk> grr
<pitti> we need to clean it up
<Keybuk> Kamion: can we get a cruft-check for that one?  (binary in main, but source in universe)
<pitti> Keybuk: Keybuk libgnutls-dev is currently built from gnutls12 for us
<Kamion> Keybuk: anastacia reports it
<Kamion> you'll get "source only promotions to main" or some such
<pitti> Keybuk: (it's not new in Debian, BTW)
<Kamion> (I just promoted python-central for the same thing)
<Keybuk> Kamion: it doesn't ?
<Keybuk> Kamion: e.g. gnutls12 above
<Kamion> Keybuk: when you're syncing a new source, use -f -F to override the component check
<Keybuk> Kamion: yeah, I know the override wibble :p
<Kamion> Keybuk: gnutls13 is not in Ubuntu and sync-source assumes universe therefore
<Kamion> if it's being newed into main then it's not a problem
<Kamion> Keybuk: anastacia obviously doesn't report it when the package isn't in the archive yet
<Keybuk> ah, duh
<Keybuk> right, it's just sync-source being silly, that one
<Kamion> Keybuk: sync-source is saying "libgnutls-dev is in main but you're asking me to sync new source for it which [I think]  won't be in main"
<Keybuk> yeah
<Keybuk> I've seen it the other way too, where syncing a non-new package had the same problem
<Keybuk> but I haven't looked at anastacia in edgy through fear
<Kamion> yeah, that's possible in the event that it starts generating packages it didn't previously generate
<Keybuk> yup
<Kamion> I'm not touching demotions from main in edgy until hppa catches up or I'm told not to care
<Keybuk> heh
<Keybuk> I figure caring about promotions is sufficient for not
<Kamion> yeah
<Keybuk> btw, who put type-handling in the supported seed? :p
<Kamion> Keybuk: that's a weird-shit germinate thing
<Kamion> it's not actually in supported, it's because type-handling provides: linux
<Keybuk> linux is in the supported seed?
<Kamion> but for some reason germinate isn't picking the real package
<Kamion> %linux-meta is in supported
<Kamion> it's not a massive deal, I'll figure it out at some later point and in the meantime we can just ignore it
<Kamion> Keybuk: I implemented seed-cleanup this morning - just deployment stuff to go before we can delete loads of stuff from supported
<pitti> Keybuk: basically we have two options: first get rid of libtasn1-2 to migrate to 1-3, and then do the gnutls12->13 migration as a second step (which will mean to rebuild a lot of packages twice), or do it all in one shot (tasn+gnutls) which will be messier, but faster
<Kamion> actually didn't pull in toooo many new binaries, but enough to reassure me that it was actually doing something :)
<Kamion> Keybuk: I also halved germinate's runtime ;-)
<Keybuk> \o/
<\sh> if someone cares, on http://archive.linux-server.org/ is the new libquicktime source package which resolves the dep-wait and can be pushed by keybuk...
* Kamion struggles to see how a Keybuk-push would be needed
<Keybuk> pitti: we have the new libtasn and gnutls now, yes?
<\sh> Kamion: manual dep-wait...or is keybuk not processing the manual dep-waits?
<Kamion> new uploads automatically clear dep-waits
<tseng> manual dep-waits arent that manual anymore
<pitti> Keybuk: libtasn1-3 is already in main, but not yet used; gnutls13 will appear soon then, I assume?
<pitti> Keybuk: I'd really like to get this transition behind us soon (I'll care for it), since right now it's a mess
<\sh> ok, then the text of buildlog_ubuntu-edgy-i386.libquicktime_1:0.9.7-0.6_MANUALDEPWAIT.txt.gz is wrong ;)
<pitti> Keybuk: so if you are fine with the 'let's do it all at once' approach, that'll be my afternoon
<Keybuk> pitti: yup, it's processed
<pitti> cool, thanks
<pitti> Keybuk: in main already?
<Keybuk> pitti: I think it just made this publisher run, yes
<Keybuk> \sh: what does your upload fix?
<\sh> Keybuk: it removes libavcodec-dev from build-deps and let this package build
<Keybuk> \sh: ok, so just uploading is fine
<\sh> Keybuk: yes, i would, but can't so someone with main powers has to do it :)
<Keybuk> \sh: BTW never upload signed dsc or changes files
<Keybuk> hmm
<\sh> Keybuk: oh yes
<Keybuk> why should this not link to libavcodec?  what's the loss of functionality?
<Mithrandir> seb128,dholbach: are any of you taking the control-center merge?
<\sh> Keybuk: libavcodec-dev is build from ffmpeg which is universe
<ogra> Keybuk, kino depends on libqicktime
<azeem> is kino using gstreamer these days?
<ogra> azeem, not in debian, no
<ogra> (i havent looked upstream though)
<Keybuk> right ... but what happens to libquicktime if you strip it of a build-dep?
<azeem> ok
<ogra> seems to still do the job
<ogra> pitti, i get a conffile prompt for /etc/dhcp3/dhclient.conf ?
<\sh> Keybuk: so I think it removes 
<\sh> MPEG,
<\sh>  DivX, MPEG4, AC3, DV,
<ogra> (i havent touched that file)
<\sh> Keybuk: nothing it just builds, because it's just a codec for libquicktime
<\sh> Keybuk: so some fileformats are not handled by libquicktime.
<Keybuk> \sh: aren't a bunch of those required for quicktime itself/
<\sh> Keybuk: not that I know of, in dapper it works as well without ffmpeg
<ogra> Keybuk, it worked for two releases (at least i havent seen a bug about it)
<Keybuk> right, so it's a new build-dep?
<\sh> hmm...I merged it for dapper, too...how strange ;)
<\sh> Keybuk: yes
<ogra> Keybuk, it always was a build dep in debian, i had to drop it in breezy to get kino to main
<pitti> ogra: hm; can you file a bug? (EBUSY)
<ogra> pitti, k
<Keybuk> ogra: ok, so whoever requested the sync instead of doing the merge properly needs to be spanked
<ogra> wasnt me :)
<ogra> WOW
<ogra> my panel just exploded to 48pt sized icons
<\sh> phew, I thought you are playing this evil game ;)
<ogra> no, i opened my menu in the middle of a dist-upgrade to edgy
<dholbach> Mithrandir: we'll do it, once the new gtk is in the archive and we can do the update with it
<Hobbsee> Keybuk: and who was it?
<ogra> tseng, 
<\sh> Keybuk: thx
<ogra> Got a SIGSEGV while executing native code. This usually indicates
<ogra> a fatal error in the mono runtime or one of the native libraries
<ogra> used by your application.
<Mithrandir> dholbach: ok.  I'm playing Adam this week while he's on vacation and doing some of his merges, but I'll leave that to you.
<dholbach> Mithrandir: thanks
* Hobbsee just hopes it wasnt her or something :P
<ogra> tseng, sh: line 1: 31278 Segmentation fault      /usr/bin/mono /usr/lib/mono/1.0/gacutil.exe /i .//usr/lib/cli/dbus-sharp-0.60/dbus-sharp.dll >/dev/null
<ogra> tseng, thast on ppc
<Keybuk> Mithrandir: I think we all are :)
* Mithrandir idly wonders why junit seems to pull in dmidecode as a build-dep (indirectly, but still)
<ogra> Use of uninitialized value in print at /var/lib/defoma/scripts/gs.defoma line 108.
<ogra> didnt we get rid of that around release time ? 
<hunger> ogra: I always had those...
* ogra tries to put on a brave face and reboots to edgy
<dholbach> ... and was never seen again
<Hobbsee> hehe yeah, i suspect so
<Hobbsee> or was hiding in a corner, whimpering
<Keybuk> edgy is fine
<ogra> urgh
<dholbach> Kamion, Keybuk: can one of you get libvte9 (of the vte package) out of NEW and promote it to main, once you have a bit of time?
<ogra> BenC, !
<Hobbsee> ogra: welcome back!  you did survive?
<ogra> not really
<Hobbsee> heh
<ogra> i have to attach a usb keyboard to my ibook
<pitti> Kinnison: ping
<ogra> no keyboard support at all anymore
<Keybuk> dholbach: are you going to take care of rebuilding everything that depends on it?
<dholbach> Keybuk: yeppa
<Kinnison> pitti: I'm about to go into a pre-implementation call, anything I can do for you in the short-term?
<ogra> gnome is also weird but that was expected ...
<pitti> Kinnison: you mean for ddeb support?
<pitti> Kinnison: actually I wanted to ask you if I can grab the exim4 merge from you
<ogra> that my suspend light on the ibook turned into a disk indicator lamp somehow wasnt
<Keybuk> dholbach: accepted
<dholbach> Keybuk: rocknroll - thanks a lot
<Kinnison> pitti: No, not for ddeb, for ppa
<Kinnison> pitti: and I don't have a merge, what do you mean?
<pitti> Kinnison: http://merges.ubuntu.com/main.html -> exim4 belongs to you right now
<sivang> pitti: what's ddeb ? :)
<pitti> Kinnison: but I need to touch exim4 anyway for the gnutls13 transition
<pitti> sivang: https://wiki.ubuntu.com/AptElfDebugSymbols
<pitti> Kinnison: I don't have a special urgency for ppa
<sivang> pitti: ah, righ, cool
<Kinnison> pitti: amazing since I don't work on ubuntu
<Kinnison> pitti: Noone in distro cares about ppa, but it's mark's highest priority for the soyuz team
<ogra> mumble mumble
<sivang> Kinnison: it just indicates you're the last person to have touched it :)
<Kinnison> sivang: oh righty
<pitti> Kinnison: oh, I'd welcome PPA, it's nice for providing testing packages to users and such
<pitti> Kinnison: just from my perspective it's less important than security or ddeb support
<Kinnison> pitti: If you can find a single distro team member that rates ppa above build-unpublished-source, security-in-soyuz or similar then I'd love to know about them
<sivang> Kinnison: right, and it would make it quicker for folks to publish their packages and to use them as basis to get approved for uploading to different section of the archive :)
<ogra> dholbach, do you have a reciepe to work around the panel taking 100% CPU in edgy ?
* ogra fears his laptop case might melt
<dholbach> ogra: it's the first time i hear of that
<dholbach> ogra: any other processes taking a lot of cpu?
<ogra> well, now it dropped to 65%
<ogra> but stays there
<ogra> the app menu doesnt work either
<ogra> its a flickering something ...
<Mithrandir> doko: do you happen to know if there is a consensus in the debian java community to move towards java-gcj or if that's just us?
<ems> hello
<ogra> looks like its collapsing/expanding in half second cycles
<dholbach> ogra: hum... never heard of anything like it
<ems> did anyone notice http://www.ubuntu.com/include/ubuntu-cof-606.png might be offensive to Jews and the like
<ogra> well, it also expands to 48px if i use the gartoon icons i blame version inconsistency for now
<ogra> i was just hoping you had a reciepe or something
<dholbach> ogra: no, heard of it for the first time
<ems> it looks much like the Nazi swastika
<doko> Mithrandir: there is (we said we did want to use java-gcj-compat), although it's not done very active.
<jsgotangco> ems: surely the art director did not think of it
<Kamion> ems: it's just as much like the Isle of Man symbol
<Kamion> (in neither case does it have the same number of legs)
<sivang> ems: I suspect you would be able to say this about every group of people photoed from above holding hands :)
<sivang> ems: (like this, and close in number)
<jsgotangco> sivang: did you find it offensive?
<jsgotangco> surely not :)
<ems> but the hand bends...
<sivang> jsgotangco: ofcourse not :)
<ems> can we make sure it does not happen again?
<ems> can it be noted to the director?
<Kamion> it is not possible to ensure that nothing will offend anyone
<ems> Kamion: obviously.
<Kamion> it is not a swastika; the swastika has four legs
<sivang> Kamion: they hands are also tilted in angle, no association AFAICS
<ems> could it be noted to the director so it doesn't happen next time?
<Kamion> so that what doesn't happen next time? an accidental association with some random other symbol?
<ems> look lets keep this simple
<jsgotangco> right there's hardly anything to argue about it
<ogra> surely not :)
<Keybuk> ems: the swastika is a holy symbol to some religions
<Keybuk> rather than a symbol of evil
<zul> like hinduism
<zul> its just reverse
<ems> Keybuk: I understand that
<Keybuk> ems: pretty much any symbol or shape offends some people, and delights others
<Kamion> in any case, I'm reasonably sure it's come up in the hearing of art folks
<ems> Keybuk: so lets keep this simple. The current photo has got criticism. Just point out the criticism to the director and it should be over.
<Kamion> but I doubt it's possible to give any guarantee
<Keybuk> there are groups of people who'd be equally offended that the women in that picture aren't covered
<Keybuk> not to mention that people are holding hands
<Keybuk> etc.
<ems> Keybuk: sure. 
<ems> Keybuk: and the director I guess knows about that criticism
<Keybuk> which director?
<ems> as I have no idea who the director is
<ogra> we neither :)
<ems> could this criticism be passed on to him
<Kamion> the ubuntu-art mailing list would be more appropriate
<ogra> yeah
<Keybuk> ems: we don't have "a director"
<ems> <jsgotangco> ems: surely the art director did not think of it
<jsgotangco> ems: its contracted outside
<Kamion> in any case as I say I'm pretty sure it has already been brought up
<Kamion> but of course everyone who thinks of it wants their objection individually logged
<ems> Kamion: if it has then okay...
<ems> Kamion: I actually never notice it.
<Kamion> you just did, vocally :-)
<ems> Kamion: a German pointed it to a friend who pointed ... who told me about it
<Kamion> was that somebody who was offended by it themselves?
<ems> Kamion: I clearly above said it has the possiblity of offended Jews. I have no idea if it will actually ever offend a Jew.
<Kamion> given that the Hebrew speaker I know of on this channel doesn't seem bothered, I don't think we should be overly worried
<ems> Kamion: and that is why I said lets keep this simple. 
<Kamion> it's sometimes much easier to get righteously angry on behalf of imaginary people
<ogra> ems, as you heard before it doesnt at least offend the jews in this channel
<ems> ogra: of couse but that doesn't mean it couldn't offend...
<fabbione> Keybuk: pong
<jsgotangco> were going in circles
<ems> anyway we have talked enough over this issue
<Keybuk> fabbione: kernel FTBS on sparc, I assume you're aware?
* Hobbsee is kinda tempted to take offence that there is no person representing general Asia in that picture
<Kamion> come back when somebody's actually offended, and then it will be possible to discuss it with them
<sivang> I'll repeat - I don't find it offensive neither I could see any association talked about.
<fabbione> Keybuk: 17-4 ?
<ems> just pass it on to someone who might care if (s)he exists...
<Keybuk> Hobbsee: oddly enough, someone did complain about that
<Keybuk> fabbione: yeah
<jsgotangco> Hobbsee: im not offended at all though
<Hobbsee> that could cause offence, thinking that ubuntu isnt designed for people who live in the area, etc
<fabbione> Keybuk: no i didn't know, but i think BenC will notice.
<ems> see you later
<Hobbsee> jsgotangco: so i thought
<Hobbsee> Keybuk: darn!  :P
<Hobbsee> Keybuk: i was hoping for something that had never been, and never would be, thought up :P
<fabbione> Keybuk: i am not watching the kernel as close as i used to
<fabbione> Keybuk: but thanks for the info
<robertj> Keybuk: I appreciate your response to my avahi policy-change spec
<Keybuk> robertj: was chatting to Lathiat a lot about it yesterday
<robertj> Keybuk: I feel like it's a good but not perfect solution
<Keybuk> which?
<robertj> Security audit + policy change
<Keybuk> It'd have to be a hell of a security audit, I'm afraid
<Keybuk> every single line carefully considered, and the implications of every branch taken and expanded
<robertj> Which is a step above firewall which I consider "workable but long-term security problem"
<Keybuk> I still think that just having avahi-daemon switchable on/off at user request is adequate
<robertj> Keybuk: It couldn't hurt, System->Administration->Services seems like the best place for it although its a but unfriendly these days to new users
<robertj> err it's a bit unfriendly
<Keybuk> robertj: I think the notification area is the right place for it
<Keybuk> as a clickable icon
<dholbach> robertj: i hope gnome-system-tools >= 2.15 will be a bit nicer
<robertj> Keybuk: In it's present form I believe almost nothing should go on the notification tray
<seb128> robertj: what is unfriendly about it ?
<Keybuk> robertj: why?
<robertj> Keybuk: almost no user would every want to turn it off
<lifeless> Keybuk: you have mail I hope
<Keybuk> robertj: it'd be off by default
<elmo> robertj: you know how bluetooth in mobiles defaults to off?  ever wonder why?
<Keybuk> robertj: I would expect most people to turn it on
<Keybuk> but then that's their funeral
<Keybuk> I like the idea of the notification area being like the little icons on a mobile phone
<Keybuk> it's an interface most people will be familar with
<Keybuk> it's already like that really -- battery power, network signal, "you have (voice)mail", etc.
<Keybuk> don't see why "laptop is discoverable via avahi/bluetooth/etc." shouldn't be in that list
<robertj> seb128: overly-large icons, "real" service names, names & descriptions that are too mcuh alike, etc...
<robertj> seb128: even so, I'd prefer it be there. I'll also assume that default installs don't have 2 mail agents, 3 action schedulers, and 2 loggers
<robertj> seb128: but not horrible by any means, and it sure beats nothing
<seb128> robertj: what is wrong about using the service name?
<seb128> robertj: upstream is not planning any change afaik because he's not aware of any issue, if you have some real complain suggestions are welcome
<robertj> seb128: bug about it?
<seb128> robertj: saying that it's unfriendly is not of real use
<seb128> robertj: by example
<robertj> seb128: can I get back with you in a few minutes after I get out of avahi-mode?
<robertj> I _promise_ I won't drop the ball & will file a bug report
<seb128> sure, no hurry
<jdub> ahr
<seb128> hey jdub
<robertj> Keybuk: I think there are some battery concerns that bump bluetooth up the list, wifi has a level of security exposure that is more severe than avahi advertising so I think there are reasons it should be more prominant
<Keybuk> robertj: bluetooth certainly has security concerns!
<robertj> Keybuk: I know it does
<seb128> jdub: GTK 2.10 is the suck, static build is b0rked and nobody has an idea (or people who could have an idea seems to not bother about it enough to track it)
<Keybuk> how do you figure hiding an option in a dialog is more prominent than an icon on the desktop?
<jdub> seb128: static matters for us?
<mvo> seb128: wasn't static building b0rked with earlier versions too anyway?
<robertj> It's not, it's less. I think Wifi is a-ok for an always-on-screen element, as well as bluetooth
<seb128> jdub: it matters for Debian apparently and I didn't want to divert from them, but I'm that near || of dropping it
<seb128> mvo: no, at least it has already been b0rked but fixed too
<Keybuk> robertj: make it a single element
<jdub> seb128: weird - the gtk+ dudes are not being responsive?
<robertj> Keybuk: no matter what you have to decide either on or off by default
<jdub> seb128: got some build log output?
<mvo> seb128: hm, last time I tried that (1-2y ago) it claimed to be doable, but in reality it wasn't (because of dynamically loaded stuff like pango-modules and all this stuff)
<seb128> jdub: mclasen and owen have no idea "offhand" and neither of them showed interest to look at it
<seb128> jdub: http://bugzilla.gnome.org/show_bug.cgi?id=346531
<Ubugtu> Gnome bug 346531 in gtk "GTK 2.10 static build is broken (required to package it for Debian and Ubuntu)" [Major,Unconfirmed]  
<robertj> Keybuk: I guess you could ask when a network connection was created
<seb128> mvo: GTK has a static build target since before I started working on GNOME for Debian
<robertj> Keybuk: Most users will want guidance on what to select and not remember the dialog 2 days for then and be confused when their auto-detect doesn't work.
<seb128> mvo: 
<seb128> gtk+2.0 (2.2.0-1) unstable; urgency=low
<seb128>   * debian/rules:
<seb128>     modified to build the static libraries. (closes: Bug#161938)
<seb128>  -- Akira TAGOH <tagoh@debian.org>  Mon,  6 Jan 2003 18:34:31 +0900
<robertj> Keybuk: but if we say This is a good idea for 99.9% of users then we will just be bothering people.
<mvo> seb128: right, what I say is that also it is available I was not able to build a static linked gtk app that had no external dependencies (e.g. on pango-modules). this may be me of course
<seb128> mvo: ah right
<robertj> If you are the kind of person who disables access to your USB ports then you can disable it, and if your not _and_ a vulnerability is discovered _and_ someone is on your subnet to exploit it _and_ your not doing your updates then you are screwed
<seb128> mvo: <Np237> I've already raised the question on -devel, and people do use static libraries *especially* for gtk
<seb128> mvo: I've not really tried myself
<robertj> Keybuk: but right now we are holding back major functionality because of a purely theoretical problem which we have lots of evidence to suggest is a non-issue and no verifiable way to ever know for sure the software is safe. 
<Keybuk> robertj: *choke*
<Keybuk> security is not a "non-issue"
<Keybuk> the No Open Ports policy is there for a reason
<robertj> Keybuk: I didn't say it was a non-inssue
<Kamion> robertj: thing is, the burden of proof is on the proposer of opening up ports, not the other way round
<robertj> Kamion: we shouldn't open up dhcp because there is no way to prove there isn't an exploit left
<Kamion> robertj: there are ways to demonstrate that vulnerabilities are contained
<Kamion> if that cannot be demonstrated for a piece of software, then it shouldn't be allowed to listen by default
<robertj> Kamion: what proof has been done on dhcp client then?
<Kamion> also, dhcp is a very long-established piece of software; we have a security history for it
<Keybuk> dhclient has been around for a very long time, and has had a large number of security audits done on it
<Keybuk> likewise the libc resolver
<Keybuk> avahi has been around for a very short time, and to my (and Google's) knowledge, never had a formal security audit
<Kamion> we've also taken steps to ensure that the client runs as non-root
<robertj> Mandrake had DHCP exploits in 2002
<robertj> So vintage is no gauruntee unfortunately
<Keybuk> robertj: a history of exploits is not necessarily negative
<Kamion> it's a rare piece of network software that never has an exploit, but if 2002 is the best you can do, then that's not so bad
<Keybuk> I actually feel more comfortable about code that's had bugs and exploits shaken out of it
<Keybuk> (and yes, I know avahi has had very recent exploits :p)
<robertj> Kamion: I do to but technically I don't know they are "out" though
<Keybuk> anyway, this talk about DHCP is not much relevant; that has been granted a policy exception
<robertj> In the end the only way to know is to put it out there and let it sit a decade
<Kamion> well, no, having people who care turn it on is a good way to start finding out
<Keybuk> avahi is an interesting case, because while it is non-root and chroot'd, it still communicates with things outside of that jail -- dhclient doesn't
<Kamion> it's not mass deployment that tells you about exploits, it's *just enough* deployment that people start auiting it
<Keybuk> so it's a little more concerning
<Kamion> auditing
<Keybuk> we should certainly ship avahi in an "off by default" state
<Kamion> deploying avahi on my mum's computer won't tell you a thing about exploits :)
<Keybuk> then, later, we can decide whether enough users have turned it on and shaken the bugs out
<robertj> Keybuk: what makes you think people turning it on will spur an audit
<Keybuk> robertj: such things often do
<Keybuk> the right people using it makes other people look at it, etc.
<robertj> Keybuk: I don't think that's a very realistic expectation
<robertj> You have a 1:1000 chance that someone will get a group together & do a full code audit & do a good job
<robertj> You have the black-hats who won't look at it until there is an install base large enough for pandemic spreading to occur because it's in their best interest not to
<pitti> how come that all our buildds are idle when there are a thousand packages waiting to be built?
<Zdra> the problem I see is if we don't activate it by default users won't know about that feature ! What is great is tu turn on an ubuntu computer and say "oh my god I can see shared folders from my other ubuntu machine !"... I don't understand how we can tell it "zeroconf" if the user has tu enable it...
<robertj> And you have the white-hats who for the most part have more fun things to do than do a code audit & a whole slew of ways around the issue including turning a blind eye, firewalling traffic, disabling multicast & setting up machines by hand, etc
<neuralis> robertj: there are multiple ways to approach the problem. very carefully looking at avahi's security implications, and documenting how each can be best addressed in the code first (e.g. sshd's privilege separation, etc) would be an excellent start.
<neuralis> robertj: i haven't read your spec yet, it's in my queue for later today.
<robertj> There is no use case in which a code audit takes less effort/money than disabling multicast or securing your network in general
<robertj> Keybuk: do you see these as factors that make it unlikely for anyone to do the kind of needed audit themselves?
<Keybuk> robertj: tbh, I don't care :P
<Keybuk> until such an audit has happened, I don't see that avahi has proved itself worthy of an open port
<Keybuk> I really don't see a problem shipping it off by default forever
<neuralis> keybuk: +1.
<Keybuk> my phone came with bluetooth and irda off by default
<robertj> neuralis: next question, do you think its important enough that it's worth begging Mark for $$$ to pay someone to do?
<Keybuk> this, to me, is not a problem
<robertj> err Keybuk, sorry
<Keybuk> nope, I don't
<mjg59> Keybuk: Bluetooth comes switched off by default because of battery life concerns more than security
<Keybuk> I don't think it's important at all
<Keybuk> I seriously don't think anybody will care that it's off by default
<robertj> I think a lot of the least-vocal users will
<Keybuk> mjg59: right, the reason they're off doesn't matter
<Keybuk> if those users are missing the obvious "turn this on forever" button, then those users are idiots
<pitti> G0SUB: ping
<Keybuk> and not worth caring about
<neuralis> robertj: quite honestly, an easy, approachable way to turn it on from the networkmanager menu would more or less completely satisfy me, at least to begin with.
<Zdra> Keybuk: I think nobody will care because nobody will know that ubuntu can discover services automatically...
<neuralis> robertj: almost certainly you won't get more into edgy; edgy+1 is debatable again, contingent on audits, etc being done.
<Keybuk> I'd like a generic "service discovery" gubbins to turn on/off things like avahi, cups browsing, bluetooth, irda, etc.
<Keybuk> if it's easy to find and use, people will discover very quickly
<mjg59> Bluetooth has a strong distinction between discovery and listening
<tseng> the service manager is pretty easy to use in gnome-system-tools
<neuralis> Keybuk: what's the latest story with networkmanager? i didn't pay too much attention in paris. are we planning to actually install it by default?
<Keybuk> mjg59: aye, I think the pattern works well for avahi too
<Keybuk> neuralis: we are not
<mjg59> Keybuk: Not really
<mjg59> Bluetooth discovery is a per-connection thing - you don't opportunistically look for Bluetooth devices
<Keybuk> mjg59: sorry, I mean the pattern works well for dns-sd
<mjg59> No
<Keybuk> avahi allegedly doesn't implement them separately
<robertj> With bluetooth the likelyhood that an attacker is in a 30" proximity is somewhat less than someone being on your dorm-floor with an infected computator
<mjg59> The protocol doesn't really allow them to be implemented separately
<Keybuk> why not?  doing dns service discovery is distinct from announcing your own services
<mjg59> No, because you don't do dns-sd just when you're specifically looking for something - you opportunistically pick up announcements as well
<mjg59> Bluetooth has a protocol-level timeout for service discovery
<mjg59> Which dns-sd doesn't seem to
<neuralis> robertj: i'll take a 15-minute look at the avahi source today, to get a super-general feel for the security.
<mjg59> If it did, there'd be much less of a problem
<pitti> neuralis: I did that a while ago, btw, and also talked with upstream
<jdub> Keybuk: multicast dns-sd != unicast dns-sd
<pitti> I pointed him to an integer overflow or two, which he promptly fixed
<neuralis> pitti: what did you think about the rest?
<pitti> in general, the code look quite well
<robertj> neuralis: thanks, please grafitti the spec page when done ;)
<pitti> it's carefully written to not cause overflows etc., but I do not vouch for the higher-level threats
<pitti> like, stealing files from other people, that sort
<pitti> I didn't audit the protocol at all
<neuralis> pitti: were you satisfied with the privilege separation that they do, and such?
<pitti> I just checked for the usual suspects (malloc, arrays, etc.)
<mjg59> pitti: That's presumably more a function of the applications using it rather than avahi itself?
<neuralis> pitti: well, the protocol isn't avahi's, it's standardized, right? so it's a layer7 matter.
<pitti> mjg59: well, the daemon opens a port, thus potentially you can abuse it to read anything avahid can
<pitti> as I said, I just looked at the code to get a feeling for the cautiousness
<pitti> I have never used avahi nor checked the network application layer
<pitti> neuralis: privsep> that looked quite well, running as non-root in a chroot, IIRC
<robertj> pitti: http://avahi.org/wiki/SecurityConsiderations <- that was written for Ubuntu & then posted up genearlly
<pitti> https://wiki.ubuntu.com/MainInclusionReportAvahi has that list, too
<neuralis> pitti: okay, i'll take a brief look at some of the higher-level things that you didn't look at originally
<neuralis> pitti: if it's a non-root process in a chroot, and the outside helper is sufficiently paranoid, that's a rather secure combination; i could be convinced not to oppose the policy amendment on security grounds
<pitti> neuralis: agreed
<neuralis> pitti: cool. i'll report findings to -devel later today.
<neuralis> robertj: --^
<pitti> neuralis: the thing that frightens me most about enabling it by default is that it might allow outsiders to see data and files which the user never intended to share
<pitti> neuralis: maybe that's just my wrong understanding of how avahi works, I didn't yet find the time to deal with it
<epx> dns-sd can't share files, AFAIK
<Amaranth> pitti: you have to explicitly turn on sharing in the individual applications
<Amaranth> pitti: like music sharing in rhythmbox, you have to go into the preferences and turn it on
<epx> dns-sd just 'shares' smal TXT records about services, it is way less powerful than upnp to expose things
<Amaranth> all they should get by default from your computer is the fact that there is a computer there and the name of the computer
<shackan> dns-sd is just a protocol to publish services, sharing files could be a concern IFF the user installs a service to share files which advises its existence on the network via avahi
<neuralis> pitti: yeah, that's what i plan to look at.
<neuralis> pitti: i think we should be in the clear about it, based on what i remember reading of the apple docs on this a long time ago, but i'll look at it again.
<shackan> avahi by default doesn't do much more than listen what services other people made available on the network
<robertj> pitti: as an applied use case - if you have Avahi instalelled by default you will see other Music Shares in Rhythmbox but must enable Music Sharing in Rhythmbox
<robertj> pitti: it's purely an advertising endeavour. The idea is that it tells the world that you are sharing as a side-effect of the actual sharing itself which is handled elsewhere
<pitti> robertj: I see; thanks for the heads-up
<robertj> pitti: this does lead to issues that end-users consider "security problems." For instance graduate students are able to locate the IP printer in the faculty closet & print to it. 
<neuralis> robertj: that's not a security problem, that's tuition reimbursement :)
<robertj> think of it as a scholarship for people with an emphasis in computers
<Amaranth> robertj: how could avahi let them find that printer?
<Amaranth> robertj: unless that printer advertises itself
<robertj> Amaranth: it does
<robertj> New HPs advertise that way
<Amaranth> robertj: that's a SEP :P
<robertj> SEP?
<Amaranth> Somebody Else's Problem
<robertj> Oh, of course. Just be on the look-out for that.
<neuralis> ok, i'm about to go grab some food.
<neuralis> robertj: you're getting your audit, now take it easy and let -devel and #-devel think about other things than avahi for a bit.
<robertj> planned on it :)
<robertj> i'm already looking at seb128's request for a bug at services applet
<pitti> Keybuk: do you know what's wrong with our buildds?
<pitti> (why they went on strike)
<Keybuk> pitti: I don't
<Keybuk> are they still on strike?
<Keybuk> hmm
<Keybuk> the only things Pending Build are security and backports
<dholbach> Gloubiboulga: you will need to rebuild xfce4-terminal against the new libvte-dev
<pitti> Keybuk: there should be a thousand things waiting to be built
<Keybuk> pitti: there aren't
<Keybuk> there's 1,350 things in dep-wait
<pitti> Keybuk: ah, ok :)
<Keybuk> Missing Dependencies python-setuptools
<pitti> Keybuk: many of them waiting for python-support or so?
<Kamion> bet they just need new processing
<pitti> yep, gnutls13 binaries are missing as well, but probably for the same reason
<Kamion> hmm
<Kamion> oh, python-setuptools needs to be promoted to main I suppose?
<Kamion> pitti: your call
* pitti reviews
<Kamion> WBNI python-support built
<Kamion> Keybuk: python-support is in "no builds recorded" and all the buildds are idle - that can't be right
<pitti> same for gnutls
* Keybuk returns from Typing Break
<pitti> or pkg-create-dbgsym
<ompaul> http://www.dvocha.org/index.php/Main_Page
<ompaul> woops
<ompaul> wrong place
* ompaul scurrys back under a rock
<Keybuk> Kamion: yeah, that one's odd
<pitti> Kamion: the only reverse dependency of python-setuptools is celementtree, so that is hardly the reason for The Big Lock
<Keybuk> pitti: no builds have even been attempted yet
<Keybuk> so it won't yet know it's in dep-wait
<pitti> Kamion: nevertheless, p-setuptools is fine for main for me
<robertj> seb128: Shares admin does come from gst right?
<robertj> err not Shares, Services setting
<seb128> yep
<robertj> It's not listed as a component on bugzilla
<robertj> after thinking about it more, I recommending that there be a list of "essential system services" (basically everything installed by default) that are hidden unless users check a "View system services" checkbox
<robertj> seb128: sound reasonable? The idea would be to get it very bare-looking so that at some point we could say "lets add more informatin about the selected service, links to logs, a configure button, etc."
<seb128> robertj: gnome-system-tools, runlevel-admin
<seb128> robertj: on bugzilla.gnome
<robertj> ahh
<robertj> gnome bug 346560
<Ubugtu> Gnome bug 346560 in runlevel-admin "visual cleanup for Services dialog" [Enhancement,Unconfirmed]  http://bugzilla.gnome.org/show_bug.cgi?id=346560
<seb128> robertj: we discussed that, upstream opinion is that it should only list services that are installed and you might be likely to change (ie: not dbus by example)
<robertj> yeah, even though system logging _could_ be disabled...for most people it's not a use-case
<seb128> robertj: thank you, I've subscribed to the bug, let's see what he says about it
<robertj> oh yeah, and the dialog needs to be wider if we can swing it;)
<robertj> (pork-barrel bug-filing)
<mdz> doko: will you take care of the bash and zlib merges?
<robertj> seb128: I will volunteer that OS X has a Services admin utility that succeeds in being profoundly useless
<pitti> mdz: good morning
<mdz> pitti: I am not here
<pitti> oh, I hate it when I talk to illusions :)
<ogra> pitti, stop licking on frogs then :)
<ogra> that helps a lot :)
<pitti> *wuerg*
<ogra> heh
<robertj> seb128: and OS X server has a seperate one for Net-facing services where you can actually do some managing that is ugly (although it doesn't need to be) but functional
<pitti> Keybuk: did you recently get reports about wrong device permissions? /dev/usblp0 is now always in group root in edgy
<Keybuk> pitti: yeah, known bug (typo in rules file)
<pitti> ok, great; thanks
<Keybuk> KERNEL="lp" needs to be KERNEL=="lp"
<doko> mdz: after the half final :-)
<mdz> doko: half final?
<pitti> mdz: soccer today :) Germany - Italy
<doko> semi final? anyway, Italy <->Germany
<pitti> semifinal, or so
<mdz> oh
<Keybuk> woo!  now the only things in new-source output are things that look like they've been in Ubuntu in the past
<Keybuk> elmo: don't suppose we have the historic katie removals.txt around anywhere?
<elmo> Keybuk: sure it's on jackass?
<Keybuk> elmo: I have no account on jackass
<pitti> Keybuk: I have
<elmo> it's in drescher:~james/ now too
<Keybuk> elmo: should I have one?
<elmo> Keybuk: no
<elmo> jackass is only used for security
<elmo> which AFAIK is just pitti and infinity
<Keybuk> *nods*
<Keybuk> what does "ROM" mean in removals.txt, btw?
<elmo> Request Of Maintainer
<elmo> there should be a legend at the top
<Keybuk> ah
<elmo> or if not, there will be at the top of http://ftp-master.debian.org/removals.txt
<Keybuk> we seem to just use NBS now :)
<msw> Keybuk: the == thing has bitten me more than once...
* netjoined: irc.freenode.net -> brown.freenode.net
<hunger> Any kernel people around? I get oopses with the 2.6.17 series in edgy.
<hunger> The OOps is attached to #51384.
<jsgotangco> goodnight
<highvoltage> goodnight jsgotangco 
<pygi> jdub, around this time ? :)
<slomo> Keybuk: hi, please move libvisual to main. the main inclusion report was approved by pitti yesterday
<bddebian> Heya
<simosx> hi there
<bddebian> Hi simosx
<iriefrank> I'm trying to create a patch that changes a default gconf setting for epiphany-extensions, where can I find a schema file or equivalent?
<iriefrank> how are gconf settings set when installing a .deb?  I'm sorry, this is my first patch
<sladen> iriefrank: calls in  postinst  to  gconftool-2
<iriefrank> so is there somewhere in CVS where there is a file with default gconf values?
<iriefrank> thanks sladen
<sladen> iriefrank: have a lookin   /var/lib/dpkg/info/epiphany.postinst
<iriefrank> i see calls to schemas in the epiphany-browser.postinst but there is no postinst file for epiphany-exensions
<iriefrank> sladen: what about  /epiphany-extensions/include/ephy-prefs.h
<iriefrank> that seems to contain gconf settings
<sladen> iriefrank: you can neither add a postinst file, or workout what it's actually doing in ephy-prefs.h and see if it makes sense to add your extensions there
<sladen> iriefrank: iwj may know how to add your gconf-overrides WRT to firefox
<Kamion> s/neither/either/ surely
<iriefrank> sladen: thanks
<sladen> Kamion: affirmative
<BenM> are any of you who might know stuff  about glibc packaging here?
<simira> BenM: Mithrandir might know a thing or two
<BenM> ok,so i'm looking at /usr/lib/gconv/gconv-modules.cache
<BenM> it seems this is a cache for /usr/lib/gconv/gconv-modules
<BenM> there are 60kb some of allocations caused by reading the gconv-modules
<BenM> which seems to be potentially avoided by the .cache file, which ubuntu doesn't have
<BenM> somebody on fc5 reports having that file
<Kamion> running iconvconfig should create it I think
<BenM> yea
<BenM> so, that saves 70kb of mallocs
<BenM> for most gnome programs
<Kamion> should be possible to run it in the postinst
<BenM> want me to file a bug
<Kamion> and make sure it gets removed in the prerm or so
<Kamion> I'm not a glibc maintainer, but it sounds like a good idea to me FWIW; yes, filing a bug would be sensible
<Kamion> jbailey wrote the iconvconfig man page so he should know about it
<Kamion> BenM: yeah, I can see the difference in an strace
<BenM> in valgrind it's even more obvious :-)
<Kamion> http://people.ubuntu.com/~cjwatson/tmp/man-iconvconfig.diff
<Kamion> any idea of the memory saving across the whole desktop?
<BenM> well, every program that uses gnome_program_init seems to make use of it
<BenM> a really easy test would be to reboot and see how many procs mmapd that file
<BenM> one issue, the stack trace is:
<BenM> ==14654==    by 0x429146A: gnome_program_parse_args (in /usr/lib/libgnome-2.so.0.1401.0)
<BenM> ==14654==    by 0x4291BC7: (within /usr/lib/libgnome-2.so.0.1401.0)
<BenM> ==14654==    by 0x4291ED8: gnome_program_init (in /usr/lib/libgnome-2.so.0.1401.0)
<BenM> it's possible that popt using programs avoid this
<BenM>               1272 kb private dirty
<BenM>               1188 kb private dirty
<BenM> that's a before/after for me
<Kamion> one process?
<BenM> ya
<BenM> multiply that by 10? 20?
<Kamion> $ sudo grep -l gconv /proc/*/maps | wc -l
<Kamion> 21
<Kamion> might be a reasonable approximation
<Kamion> (pre-reboot)
<bddebian> Hmm, are we going to have xutils-dev in Edgy?
<BenM> i could just kill X
<BenM> that'd get most of the data
<BenM> hold on
<Kamion> bddebian: xutils-dev |  1:1.0.2-3 |      unstable | source, alpha, amd64, arm, hppa, i386, ia64, m68k, mips, mipsel, powerpc, s390, sparc
<Kamion> bddebian: so I'd guess so
<bddebian> Hmm.  Should I wait on cernlib merge then?  It was build-depping xutils-dev which apparently wasn't in dapper?
<BenM> [bmaurer@omega ~] $ grep gconv-modules.cache /proc/*/maps -l | wc -l
<BenM> 23
<crimsun> you can either merge it by hand by adding the necessary b-ds, which should be imake
<crimsun> or you can wait
<bddebian> What is preferred?
<crimsun> I take the "clear the merge list ASAP" approach
<bddebian> And why wasn't xutils-dev synced/merged already?
<Kamion> bddebian: I'd wait
<Kamion> because otherwise we just introduce diffs unnecessarily
<Kamion> bddebian: because our new X maintainer is just getting up to speed
<bddebian> Kamion: So should I file a sync request bug on LP and put "After xutils-dev makes it in"?  Or just do nothing?
<Keybuk> Kamion: btw, I've put the sync-blacklist file into bzr
<Keybuk> and tidied it up rather a lot
<Keybuk> bddebian: do nothing
<Kamion> bddebian: if it can be synced now, it can just dep-wait
<Kamion> so a sync request would be fine IM
<Kamion> O
<Kamion> Keybuk: thanks
* bddebian shoots himself
<Kamion> bddebian: syncs are harmless if they won't build yet :-) but if you want to test it before requesting the sync, then wait
<BenM> man, this looks nice, about 1.5 MB on startup
<BenM> probably a bit more once apps are launched
<Kamion> assuming that's the only necessary diff from Debian
<Kamion> BenM: nice!
<bddebian> Kamion: Well I usually like to make sure something "works" before I request a sync.  I get in enough trouble as it is :-)
<Kamion> might be worth trying in a non-English locale, just to make sure it still works ...
* BenM has firepower for today's blog
<Keybuk> Kamion: sync won't work :)  xutils is blacklisted
<Kamion> Keybuk: sync of cernlib not xutils
<Keybuk> Kamion: oh, sorry, duh :p
<bddebian> Keybuk: Why is X blacklisted?
<bddebian> Err xutils
<Keybuk> bddebian: because it's going to come in together
<bddebian> Ah
<Kamion> bddebian: because we know it all needs manual love and attention
<Kamion> and careful ordering
<bddebian> Goddamn I hate being useless
<rodarvus> bddebian, debian xutils is quite different from ours (for now)
<bddebian> rodarvus: Aye, I know
<Keybuk> that's why it's blacklisted, to prevent us picking it by accident via a sync
<bddebian> OK
<bddebian> Hello pygi
<pygi> hey bddebian :)
<BenM> open("/usr/lib/locale/locale-archive", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
<BenM> open("/usr/share/locale/locale.alias", O_RDONLY) = 3
<BenM> that looks fishy
<jdub> BenC: ping
<Mithrandir> lifeless: you played a bunch around with opensync, didn't you?
<lifeless> yes, I package libopensync
<Mithrandir> lifeless: doesn't seem to be in dapper?  Will be in edgy?
<lifeless> no, not in dapper, no way was it suitable
<lifeless> upstream are being slow doing next release
<Mithrandir> ok, do you have the packages somewhere?  I'd love to play with it now that I got a phone which should be able to sync over *
<lifeless> Mithrandir: its in edgy
<lifeless> just pull the package ;)
<Mithrandir> oh, cool.
<Mithrandir> I'll take a look at that, then.
<jdub> known b0rkage with atheros in edgy's 2.6.17?
<sivang> Keybuk: Will you take a look at +spec/make-free-space-wizard and let me know what it's missing to be approved? (I just read the TB meeting backlog)
<sivang> iwj: thanks for your fixes and approval for home-user-backup
<bluefoxicy> Keybuk:  you got a little time?
<bddebian> Is CLK_TCK from time.h deprecated?
<jdub> hrm, ok, there's some funny module ordering problems with atheros
<Keybuk> bluefoxicy: not right now
<Keybuk> sivang: not right now
<pygi> jdub, you here finally? :P
<jdub> pygi: hi
<bluefoxicy> Keybuk:  hrm, I'll try later then.
<pygi> jdub, hi hi, you have a sec?
<jdub> pygi: very early morning here, been jetlagged after guadec - expect the unexpected.
<jdub> sure
<pygi> jdub, oki, pm/ed you
<jdub> pygi: quick - gotta have breakfast
<pygi> jdub, just you go eat, its not urgent
<jdub> pygi: if it's private, mail it, if it's not, here is fine
<pygi> not private...
<pygi> was just wondering where is that conference in asutralia, to see if I could try to attend
<jdub> sydney
<pygi> eh, not where*
<pygi> sorry, when*
<jdub> jan 15-20, 2007 - as stated on the website...
<pygi> uh, havent seen that :) Thanks :)
<pygi> uh, havent read the dates :P
<pygi> thanks :)
<sivang> Keybuk: okay, let me know when you can or I should bug someone else :)
<sivang> Keybuk: I'm singing off for today, if you do get to review it, email me with any fixes I need to do and/or put remakrs inline the wiki page.
<sivang> night all
<bddebian> Gnight sivang
<shaya> is it just me, or is aptitude seriously broken in edgy?
<shaya> pegging my cpu on startup with "Initializing package states"
<pygi> shaya, everything is seriously broken in edgy :P
<shaya> :-p
<shaya> not quite true
<crimsun> 0.4.1-1.1ubuntu2?
<shaya> yes
<shaya> filing a bug
<shaya> and filed
<zul> Keybuk: can you check up on kernel-package, it got accepted into edgy but i dont think its in the archive yet
<Keybuk> zul: not right now
<zul> ok
<Kamion> kernel-package | 9.001ubuntu15 |          edgy | all
<Kamion> kernel-package | 9.001ubuntu16 |          edgy | source
<Kamion> probably just blocked on the buildd queue being fixed
<Kamion> (which Keybuk is sorting out)
<zul> ah ok...thanks
<Keybuk> right
<Keybuk> so 500 in needsbuild, 1258 in depwait
<elmo> does gnome-cups-icon randomly leak memory like it was going out of fashion for anyone else?
#ubuntu-devel 2006-07-05
<elmo> it's using 37M and I only killed it last week
<Keybuk> yeah
<Burgwork> elmo, there is a thread on planet gnome about just that
<elmo> 45406
<elmo> or #45406 or LP#45406 or whatever gets the stupid bot to trigger
<Keybuk> bug #45406
<Ubugtu> Malone bug 45406 in gnome-cups-manager "memory leak in gnome-cups-icon" [Medium,Confirmed]  http://launchpad.net/bugs/45406
<Keybuk> it actually goes to 128MB or so instantly for me
<Keybuk> though, curiously, I can't see why in the pmap
<BenC> jdub: pong
<Burgwork> BenC, jdub was talking about an atheros module issue, don;t know if that is why he pinged you
<jdub> BenC: i had to do some insmodding to get the ath_pci driver dependencies to load correctly - looked like new_wlan was being loaded, which stops (the correct module) wlan and ath_pci from loading
<BenC> new_wlan?
<BenC> this is all linux-restricted-modules?
<jdub> new_* are madwifi-ng
<BenC> jdub: is this on edgy or dapper?
<jdub> the only lrm stuff is (new_)ath_hal
<jdub> edgy 2.6.17
<BenC> ok, weird, nothing changed in lrm for 2.6.17
<anibal> how can I add an edgy spec about NFSv4?
<LaserJock> anibal: https://launchpad.net/distros/ubuntu/+specs ?
<anibal> LaserJock, thank you
<Seveas> anibal, it's too late for edgy specs, final round of approvals will be in <48 hours
<Seveas> (doesn't mean you can't work on it for edgy though ;))
<neuralis> Seveas: it's not too late for uncontroversial specs.
<Seveas> neuralis, true
<Seveas> nfsv4 would be a nice thing to have
<anibal> Seveas, https://launchpad.net/distros/ubuntu/+spec/nfsv4
<anibal> Seveas, all the package are already in edgy
<anibal> packages
<Seveas> anibal, then why a spec?
<anibal> because it will be a good feature for the next release
<Keybuk> I'm confused
<Keybuk> is the spec implemented?
<Seveas> apparently yes
<anibal> Keybuk, yep
<Seveas> anibal, specs generally are use for tracking implementation, writing them after all is done is not too useful 
<Keybuk> anibal: probably doesn't really need one then
<Keybuk> we tend to use a spec for when we have to do something hard
<anibal> should I remove my spec then?
<Burgwork> Keybuk, the droppage of all the python stuff from -meta. Was that due to the python migration or a policy decision?
<Keybuk> policy decision
<Keybuk> edgy will include a standard python runtime environment, rather than everything python related
<Keybuk> in practice, this is sufficient for everything
<Keybuk> (and deps drag in anything with synaptic anyway)
<LaserJock> too bad, I enjoyed the "WTF is all of python doing on the install CD" threads ;-)
<Burgwork> Keybuk, ok, just wondering
<Keybuk> lifeless: biff (sorry it took ages :p  wanted to give the e-mail some brain time)
<jsgotangco> good morning
<neuralis> robertj: ping
<robertj> pong
<robertj> afk for 60 seconds though
<neuralis> what of the avahi tree actually runs as a server?
<neuralis> just avahi-daemon?
<Riddell> it's not really a server
<neuralis> Riddell: by "server", i mean "listens on a port". i'm being lazy, and don't want to read the whole source.
<Riddell> yes, only avahi-daemon
<Riddell> and it doesn't listen on a port such that nmap will find it, for example
<robertj> neuralis: that's my understanding of it
<neuralis> robertj: do you know if any developers are online?
<robertj> neuralis: nope, I'd suppose there is probably an #avahi somewhere
<neuralis> robertj: i spent half an hour looking at the code. i have some questions, but i'm largely satisfied with what i've seen.
<neuralis> robertj: if my concerns were addressed (or shown invalid), i would not oppose a policy exception on security grounds.
<robertj> any thoughts about the spec itself?
<neuralis> let me look..
<robertj> https://launchpad.net/distros/ubuntu/+spec/zeroconfpolicy
<neuralis> yeah, i have the link.
<neuralis> points 1 and 3 of the implementation plan are debatable.
<Keybuk> I would *highly* recommend your spec includes an alternate plan that did not require an open port policy exception
<Keybuk> otherwise your spec is almost certainly likely to be rejected
<robertj> Keybuk: that's the whole point of the spec though, there are other non-policy specs out there
<neuralis> Keybuk: i'm actually warming up to the idea. it's very likely that there's no reason to not grant an exception on security grounds, in which case only things like the slippery slope argument, etc, apply. those are still valid, obviously, but far less potent than a "this is insecure" argument.
<Keybuk> neuralis: of the three people whose ultimate decision it is, two are unhappy that dhcp requires an open port and would rather that was fixed ... so I really don't think avahi will be granted an exception
<tseng> its easy enough to start avahi
<tseng> this is like the openssh debate all over again
<Keybuk> right ;)  we don't give the most audited, and self-proclaimed most secure piece of software in the known universe an open port :p
<neuralis> Keybuk: openssh's security record is terrible.
<tseng> haha
<tseng> because people audit it non-stop
<Keybuk> neuralis: note "self-proclaimed"
<Keybuk> and that's not a bad thing
<Keybuk> avahi has no security record
<Keybuk> NONE
<neuralis> Keybuk: pitti and i independently did brief audits, and were both happy; remember that avahi is a non-root listener running in a chroot with explicitly dropped capabilities.
<Keybuk> giving avahi an open port is like wandering into a public toilet, kneeling on the floor, dropping your pants, and *hoping* it's not one of the dodgy ones
<Keybuk> neuralis: it communicates with things outside of the jail ... so there is a risk
<sladen> neuralis: I think you need to right the spec on the basis that the exception will /not/ be granted.  And provide a Plan B, in case an exception /is/ granted.
<sladen> s/right/write/
<neuralis> sladen: it's not my spec. i don't care.
<neuralis> sladen: i don't use avahi.
<Keybuk> sladen: it's robertj's spec
<sladen> robertj: I think you need to right the spec on the basis that the exception will /not/ be granted.  And provide a Plan B, in case an exception /is/ granted.
<sladen> s/right/write/
<neuralis> Keybuk: the communication is apparently one byte in either direction; i just audited that region of source, and so did pitti some time ago. we were both satisfied.
<neuralis> Keybuk: in any case, i'll post a summary of my audit to -devel, and after that, i really don't much care.
<Keybuk> neuralis: it does the entire functionality, announcing all shares, etc. in just one byte?
<sladen> robertj: at UDS, I AFAICT, the decision from the BOF was to provide a checkbox in the network config to "[x]  Enable Zeroconf on this interface"
<Keybuk> that's a hell of a compression ration
<Keybuk> 30GB of advertised rhythmbox mp3s ... in one byte? :p
<neuralis> Keybuk: please read carefully. i'm talking about communication with the helper that lives outside the chroot.
<Keybuk> neuralis: right, and I'm saying that makes zero sense given what the implementation does
<Keybuk> either the helper has access to the network
<sladen> robertj: and a policy that if an application wanted Zeroconf, it cause a dialogue appear offering to enable zeroconf for either "This Session" or "Forever"
<Keybuk> or all network-potential traffic has to pass between them
<Keybuk> in which case, there's an escape from the jail
<neuralis> Keybuk: dude, are you always this impatient? :)
<sladen> Keybuk: read, it again.
<sladen> Keybuk: carefully this time
<Keybuk> sladen: read which?  I'm still reading, and still not seeing anything
<Keybuk> neuralis: yes :P
<neuralis> Keybuk: the helper will optionally return a R/O fd into the chroot process, which points to one of the static introspection/PID files. other than that, all communication between the two is one-byte commands and one-byte responses.
<neuralis> Keybuk: the introspection files are likely movable into the chroot, so that portion of the code can be likely dropped outright.
<Keybuk> so it's a reasonably secure network daemon
<Keybuk> that does not grant it an open port
<Keybuk> because we grant *nothing* an open port
<sladen> Keybuk: AFAICT, the chroot'ed deamon only speaks DBUS and DNS;  and the help outside with godmode only hands in open file-descriptors to the deamon
<Keybuk> sladen: I thought the chroot'd bit did not do dbus?
<neuralis> no, it does dbus, if you configure it to do dbus.
<Keybuk> so an attacker can compromise the daemon and issue arbitrary dbus commands?
<neuralis> not if you tell it to not use dbus.
<Keybuk> why would you tell it to use dbus?
<tseng> uh?
<neuralis> Keybuk: i didn't see a good reason for it, but that's for an avahi developer to answer.
<Keybuk> anyway, this is an increasingly boring conversation
<Keybuk> given that avahi is *not* getting an open port
<sladen> Keybuk: strong words.  never say never.  
<neuralis> Keybuk: hey, i was going to post my findings to devel and wander off. you pressed the issue.
<sladen> Keybuk: at least keep people hanging on with a thread of hope for as long as possible before politely shafting them
<Keybuk> neuralis: I just suggested the spec be altered to allow it to have a hope of being approved :)
<sladen> so, regarding this dbus thing.  Does avahi actually have any point if you can't talk to it.  I was under the impression that that was how one told avahi to do things
<neuralis> Keybuk: quite honestly, avahi provides (in terms of functionality) a level of convenience that's indispensable to many users; it's not unlike dhcp in that regard. the issue needs to be seriously thought through, especially if security doesn't factor in particularly strongly.
<Keybuk> security does factor into this though
<Keybuk> and as you see, it's a convenience
<Keybuk> users can turn it on if they want it
<neuralis> Keybuk: so i'm writing my security mail now, and then you and the rest of the tb bunch can do the thinking, and robertj can do the fanboying. 
<Keybuk> we have a spec for that
<robertj> I think I'm done with my chearleeding
<Lathiat> *reads up*
<sladen> robertj: realistically, for Zeroconf we're going to end up with a tick box along the same lines as for Remote Desktop.  "[x]  Share my services"
<Lathiat> if you cant talk to avahi on dbus
<sladen> robertj: or something similar.  The spec needs writing with that in mind, and how exactly to address that in a cross-desktop way
<Lathiat> its relatively useless for a deskto papplication
<neuralis> Lathiat: then the security breakdown doesn't make sense; the helper should be doing the dbus brokering, and passing in information into the chroot process.
<Lathiat> and it would do that with what?
<Lathiat> something like d-bus? ;)
<neuralis> Lathiat: uh, exactly how you currently pass in information from the helper?
<Keybuk> neuralis: and then you still have an IPC protocol that the compromised chrooted process can talk to something outside of the chroot
<Lathiat> neuralis: the daemon basically does 99.9% of the work
<Lathiat> the helper just does a few extra bits
<neuralis> Keybuk: not if it's one-way, or mostly one-way.
<neuralis> anyway, i really don't care about avahi nearly enough to continue this discussion. :)
<Lathiat> but avahi *isnt* one-way
<Lathiat> or mostly one way
<Lathiat> its very 2 way
<Keybuk> neuralis: but it's not, it's very bi-directional
<neuralis> Keybuk: yes, clearly, but if the helper is doing the dbus brokering, then it can enforce extremely strict validation on what goes out over dbus, rendering the "someone can do crazy shit on dbus if they break into the chroot daemon" argument moot.
<Keybuk> neuralis: but the helper isn't doing the dbus brokering
<Lathiat> well
<Lathiat> dbus hsa escurity policies
<Lathiat> avahi is only allowed to speak on the avahi interface, etc
<Lathiat> so you cant go sending other dbus messages
<neuralis> Keybuk: yes, that's why i told lathiat that the current security model isn't right.
<Keybuk> neuralis: also, more to the point, because there is a communication path from the daemon to the helper ... you're now at risk of the helper having an exploit too
<Lathiat> sounds more complicated and your putting more exploitable code outside the chroot
<Lathiat> where its "less safe" 
<Keybuk> so while chroot, etc. are useful for reducing the security risk; this is certainly not in the "LA LA LA! NO SECURITY RISK HERE! CURVE AROUND THE SCENE OF THE CRIME!"
<sladen> Lathiat: the separation is that you are protecting  *everything*  from stuff hitting the  *network port*.  Everything not coming from the network port wants to stay outside of the process that is talking to the network port.
<neuralis> what sladen said.
<Lathiat> ah, i see
<Keybuk> I'm not passing any judgements on the design of avahi itself, I'm just saying that your comments above that security doesn't factor is completely bogus -- this is a daemon with a high bi-directional interaction with other processes -- no matter how isolated you make it, it is never completely isolated because it can't be by design -- so security *is* a factor
<sladen> so, the if a daemon *really must* talk to the network, it should do that, and nothing else.  Unfortunately, this makes the daemon a bit useful since that wouldn't include talking to the local machine...
<sladen> useless
<Lathiat> i just dont see how some other home cookd IPC mechanism is any better than d-bus which has restrictions on what interface it can talk on
<neuralis> Keybuk: i wasn't contending that security isn't a factor because there's no risk, but because i, after a hand audit, find the dedication to, and design of, the security systems in place fully adequate. 
<Keybuk> you'd have to djb it, split it into very small processes that each have a particular job and communicate over a strict protocol to a companion process in a different "security zone"
<Lathiat> assuming d-bus is secure, but any home grown protocol is likely to get bugs too
<Lathiat> Keybuk: hehe...
<Lathiat> mm djb, dont get me started on djb :)
<neuralis> Keybuk: you're allowed a fully different definition of adequate, and thus ymmv.
<Keybuk> neuralis: except that in your audit, you appear to have not noticed that the chroot'd daemon needs to talk dbus ... which puts my faith in your audit as very low, I'm afraid
<Keybuk> and, note, that no piece of djb software has been granted an open port either ... because we don't do open ports around here
<neuralis> Keybuk: bah. still not my spec, still don't care about avahi. i was asked to audit the bigger picture, after pitti audited the lower-level primitives, and i did. in the end, i don't use avahi, and couldn't care less about it being enabled.
<sladen> Lathiat: "assuming D-Bus is secure".  Bzzzt.  Bad assumption
<Lathiat> sladen: see following comment
<sladen> Lathiat: okay :)
<neuralis> Keybuk: the audit noticed dbus fine, but no developers were around for me to ask specific questions about how and why the design was the way it was.
<Lathiat> neuralis: avahi developers?
<neuralis> Lathiat: yes.
* Keybuk points at Lathiat  ...  ask away :p
<Lathiat> neuralis: im around now :)
<neuralis> Lathiat: well, i've already inferred the answer to the dbus question; you felt that it's better than a homebrew ipc protocol, and you also thought it's better to keep the dbus stuff chrooted (which, i believe, is approaching the separation incorrectly.)
<neuralis> Lathiat: the remaining question was why not move the introspection files into the chroot instead of passing them around via the helper.
<Lathiat> thats a question i dont know the answer to 
<Lathiat> lennart did that
<Lathiat> i'd have to ask him
<Lathiat> he doenst seem to be around atm tho (is guadec still on?)
<neuralis> Lathiat: it's something to ask him later.
* Lathiat nods
* neuralis is off to killian court for the fireworks
<Lathiat> thanks for the chat :)
<Lathiat> whats the fireworks for?
<neuralis> http://en.wikipedia.org/wiki/Independence_Day_%28United_States%29
<Lathiat> ah right
<robertj> Didn't know you Harvard Commies still celebrated the 4th ;)
<neuralis> robertj: we don't, that's why i'm going to killian court :P
<neuralis> robertj: (those commies, on the other hand..)
<bddebian> Heya
<Burgundavia> hey bddebian
<bddebian> Hi Burgundavia
<Hobbsee> hi all
<LaserJock> hi Hobbsee 
<Chipzz> hi
<Hobbsee> hi LaserJock and Chipzz 
<zul> hey Hobbsee 
<Chipzz> at least on an international channel most of the time someone is awake ;P
<Hobbsee> hi zul 
<Hobbsee> Chipzz: hehe, true
<Hobbsee> jdub: awake today?
* Chipzz looks for beer ;P
<Hobbsee> Chipzz: it's gone, i drank it.
<Chipzz> Hobbsee: I live in Belgium, the country of beer ;)
<Chipzz> there is no such thing as "no beer" in Belgium ;)
<Hobbsee> Chipzz: hehehe
<Chipzz> there IS such a thing as "no-one awake" though ;P
<Hobbsee> true
<Hobbsee> because they've all passed out due to being drunk.
<Chipzz> heh :P
<Chipzz> they just have better things to do than to be on irc ;P
<Hobbsee> Chipzz: you mean there are better things than being on irc?
<Hobbsee> Chipzz: actually, i agree with you -in a hack session with some of the other devs, and chatting on irc like that - and being able to watch the responses to what you type.  now *that's* fun!
* Hobbsee breakfasts
<Chipzz> 03:27 < Chipzz> wa doet gij nog zo laat op om te beginnen? :)
<Chipzz> heh ;)
<Chipzz> and I thought *I* was a nerd ;P
<Chipzz> ;)
<Chipzz> (no offence meant ;))
<Hobbsee> hehe
* Hobbsee is just weird.  and a nerd.
<Hobbsee> Chipzz: actually, irc is the communication medium to meet up with people - which is why i logged on before breakfast.
<Chipzz> Hobbsee: but is it a medium to meet people you work with, or to make new social contacts?
<Chipzz> after having been on irc for 10 years, I'm more and more convinced it's mostly the former
<Chipzz> also the latter
<Chipzz> but for a large part the former
<profoX`> Chipzz: belgian beer ftw
<Chipzz> profoX`: FTW?
<Lathiat> for the win? :)
<Lathiat> ..dows
<Chipzz> is there any winning to be done then, really? :)
<profoX`> Lathiat: is right
<profoX`> please guys, you ruin the... eh.. acronym
<profoX`> :P
<Chipzz> profoX` ;)
<profoX`> what i meant to say was: belgian beer = good
<profoX`> Duvel+
<Chipzz> profoX`: yes, but WHICH belgian beer? ;)
<profoX`> Duvel, of course :D
<Chipzz> which one of the more than 100 belgian beers? ;P
<Chipzz> duvel gives me stomach gasses :P
<profoX`> tss...
<profoX`> :)
<profoX`> what do you drink then
<profoX`> jupiler ?
<Chipzz> kriek lindemans is very nice
<Chipzz> geuze
<profoX`> kriek lindemans is okay for once, but i'd rather have my duvel ;P
<Chipzz> some people think it is *too* sweet
<Chipzz> I was drinking jupiler earlier :)
<Chipzz> stella was all gone :/
<Hobbsee> Chipzz: the former, mostly.
<profoX`> Chipzz: it is too sweet to be considered real beer :P
* Hobbsee sends all the beer talk back to -offtopic
* Chipzz gives Hobbsee a Kriek Lindemans ;)
<Chipzz> profoX`: also, rodenback grand crue
<Chipzz> rodenbach is crap, but the grand crue is great :)
<profoX`> never drank that
<Chipzz> Hobbsee: you into sweet things?
<Hobbsee> Chipzz: depends what sort of things
* Hobbsee isnt here.
<profoX`> lol
<Chipzz> she really is not ;P
<bluefoxicy> Here's a thought.
<bluefoxicy> I recently installed Ubuntu Dapper on a 350MHz K6-2 with 192 megs of ram
<bluefoxicy> it took some fighting; I had to kill GDM and then startx with xterm in my .xinitrc, just to get enough ram free for the damn thing to not lock up totally during install
<bluefoxicy> (as to why the OOM didn't stab things to death I have no idea)
<Chipzz> bluefoxicy: use the altnerative install cd?
<bluefoxicy> Once it's installed, it works.  A little sluggish, takes about 3 minutes to open up openoffice.org, not yet swapping.
<bluefoxicy> Well, my question is this
<bluefoxicy> 486 stops at 66MHz.  No.  Freaking.  Way.
<Chipzz> my question is this: who is as machosist as to run OO.o on a 192MB machine? ;)P
<bluefoxicy> Is there ANY benefit to building the whole system as 586 or 686 (I have been looking for a list of instructions introduced in those processor lines with no luck), or should we not care?
<Chipzz> bluefoxicy: and 486 stops at DX4 120Mhz
<bluefoxicy> Chipzz:  okay, I've never physically seen more than 33MHz but heard of 66.  120, that's ... still... not going to be fun.
<Chipzz> and I do not think that there is much substantial benefit as to build for i586
<bluefoxicy> Me either, it's just a thought.  It's between "is anyone going to ever run this on a 486?" and "Is there a practical benefit to going 586?"; I don't see a practical benefit, even if there's no real way anyone is running this thing on a 486
<Chipzz> much of the stuff that makes stuff fast is either pure ordering of instructions (386 <-> 486) or use of a particular extensions, like MMX(2), or SSE(2)
<bluefoxicy> heh.  Don't get me started on SSE
<Chipzz> MMX and SSE for making string instructions faster
<bluefoxicy> using that as a general math coprocessor is slooooooooow.
<bluefoxicy> (there's apparently a gcc optimization that uses sse for math!)
<bluefoxicy> (a lot of gentoo people were using it @_@)
<Chipzz> iirc sse can be faster for string copy stuff than integer stuff is
<bluefoxicy> SSE is faster for repeatedly computing on the same data set
<Chipzz> or maybe that's just MMX; dunnow
<Chipzz> so SSE would also be faster for doing the (null) computation on the same data set?
<Chipzz> ie strcpy?
<bluefoxicy> like if you want to calculate a particular value and it starts with 4 variables A B C D and does A % B -> ab , C / ab -> N, N * AB -> Z ..... for like a 70 step pipeline, it's faster
<Chipzz> or am I mistaken with mmx?
<bluefoxicy> sse won't do anything for strings
<bluefoxicy> it's for like, math stuff
<bluefoxicy> I'm told it takes 17 cycles to load a value into an SSE register, and 17 to get it back out
<bluefoxicy> (slow)
<Chipzz> then I'm probably mistaking with mmx
<bluefoxicy> but then when you do a string of math instructions it executes like a jillion of them a cycle
<bluefoxicy> hence if you have really, really long mathematical computations it's super fast
<bluefoxicy> but that's EXTREMELY special cased
<wasabi> Weird bug: System > Quit.  GDM "Choose Server" box appears (I have two X servers configured), but right when the box appears, the screen fades out and gnome-screensaver locks.
<wasabi> Apparently the case of having GDM prompt wasn't considered.
* wasabi files.
<fabbione> morning
<jsgotangco> hello fabbione
<fabbione> yo
<Mithrandir> fabbione: any chance you could review https://launchpad.net/distros/ubuntu/+spec/live-cd-share-live-cd for me?
<fabbione> Mithrandir: yeps.
<fabbione> Mithrandir: i will need to bother you later for sparc
<fabbione> (but not now. i still need to do them)
<Mithrandir> fabbione: thanks
<fabbione> Mithrandir: see /msg
<pitti> Good morning
<ivoks> 'morning
<ivoks> pitti: care to upload something to dapper-updates? :)
<ivoks> pitti: fix for bug 45406
<Ubugtu> Malone bug 45406 in libgnomecups "memory leak in gnome-cups-icon" [Unknown,Unknown]  http://launchpad.net/bugs/45406
<pitti> ivoks: ah, that one; yes, it's in my mbox so far, but I'm not sure whether it's worth the trouble
<ivoks> pitti: i've fixed it
<ivoks> pitti: (applied debian patch)
<ivoks> pitti: it's on http://www.grad.hr/~ivoks/ubuntu/libgnomecups
<pitti> ivoks: can you please attach the debdiff to the bug, so that mdz has something to look at for approval?
<ivoks> sure
<jamesh> ivoks: btw, I updated my ipplib.py + printerlist.py demo to work with current CUPS (and fixed an issue with encoding multiple values for an attribute)
<jamesh> if you were still interested in it.
<ivoks> sure I am
<\sh> moins
<jsgotangco> hello sabdfl
<sivang> morning!
<lifeless> seb128: steve would like to speak to you, as me
<seb128> lifeless: about?
<jsgotangco> morning sivang
<dholbach> good morning
<sivang> morning jsgotangco , dholbach 
<dholbach> hey sivang
<sabdfl> hi jsgotangco... i see everyone's in https://launchpad.net/distros/ubuntu/edgy/+specs "get cracking" mode
<jsgotangco> =D
* hunger gets a kernel oops when booting the 2.6.17 kernels for edgy. Anyone looking into those problems?
<crimsun> w/ 2.6.17-4.6?
<fabbione> hunger: please file a bug in LP
<fabbione> hunger: add all the OOPS
<slomo_> hunger: bug #51308 maybe?
<Ubugtu> Malone bug 51308 in linux-source-2.6.17 "linux-image-2.6.17-[34] -686 doesn't boot, libata error" [Untriaged,Confirmed]  http://launchpad.net/bugs/51308
<hunger> fabbione: I did... #51384v
<crimsun> that should be fixed in 2.6.17-4.6.
<hunger> fabbione: I am afraid that will get lost as a duplicate of the hd->sd bug.
<fabbione> hunger: then please wait...
<hunger> crimsun: Oh, great!
<hunger> fabbione: I will. but since the bug was marked as a duplicate of the hd->sd thing before, I was afraid it would fall through the cracks.
<sivang> hunger: I also have this bug , and non of the edgy kernels have ever booted for me
<Kamion> ogra: in practice you want to support gcompris-sound-* for edubuntu, don't you?
<Kamion> (just dealing with NEW and figuring out which components stuff goes in)
<Kamion> ogra: at present gcompris-sound-eu and gcompris-sound-hu are in universe and all the rest in main, which seems a bit ranom
<Kamion> random
<jhemono> Hello. I've written a spec a long time ago and I recently posted it on ubuntu-devel mailing-list. I saw a meeting have been planned for reviewing specs at july 6th 2000 UT. Herre it's wiki page : https://launchpad.net/distros/ubuntu/+spec/automated-localization-download . Do you think I sould register it for reviewing at the meeting ? I
<simosx> jhemono: I have the impression that when you install Ubuntu 6.06 and you have chosen a language during the CD booting, you get the basic localisation from the CD. However, when you setup the system and the network connection, AFAIK apt considers that the localisation packages for Firefox, OOO, etc are pending and asks you to install them.
<jhemono> yes ....
<jhemono> In my mail to the mailing list we are discussing about how to tell the user that full localization is avaiable : a notification would be too pervasive said someone and an icon would'n be pervasive enough i said. so do you think I have to register it for the meeting for more brains think to it ?
<mdke> hey Seveas, can you get my cloak back? it has disappeared. Lemme know if you want an email about it
<Seveas> one sec
<jhemono> up
<jhemono> So, what do think of it ?
<Seveas>  -:NickServ!NickServ@services.- +Cloak for [mdke]  has been toggled [ON]  and changed to [ubuntu/member/mdke] 
<mdke> Seveas: thanks. did i disactivate it myself by accident?
<Seveas> no idea
<Seveas> maybe a subspace rift caused it
<mdke> Seveas: ok. cheers
<Treenaks> Seveas: a twist in the fabric of space where time becomes a loop!
<ogra> Kamion, yes, i need to sort the seeds
<Hobbsee> hi ogra 
<jdub> Kamion: could you please s/python-sqlite/python-pysqlite2/ in the python seed?
<ogra> hey Hobbsee 
<dholbach> could somebody give back gksu?
<Kamion> ogra: I can do it now if you want - I already have the local chance
<Kamion> change
<Kamion> dholbach: you need Keybuk
<dholbach> Kamion: ok... thank you.
<dholbach> Gloubiboulga: i just deleted my work on goffice and gnumeric merge
<dholbach> Gloubiboulga: i'll restart on it (they're both in debian experimental already)
<Gloubiboulga> dholbach, I can take care of this if you want
<dholbach> Gloubiboulga: that'd be lovely - you know the *-gtk-* build parts a bit better
<dholbach> Gloubiboulga: if you're done i can have another look at it and upload it
<Gloubiboulga> dholbach, ok, I'll try to get this done this evening (fighting with xfce4-terminal for the moment)
<dholbach> Gloubiboulga: merging? or the rebuild for vte?
<Gloubiboulga> dholbach, packaging a svn snapshot, I don't even know how the package in dapper has been built or how it works
<Kamion> jdub: if you mean s/python-sqlite2/python-pysqlite2/, I did that on 21 June
<jdub> Kamion: ah, ok
<jdub> Kamion: thanks
<Kamion> jdub: oh, apparently python-sqlite is still there. you want me to drop that then?
<Kamion> can I have a rationale for the bzr log?
<jdub> Kamion: uses old, buggy sqlite 1.x, not desireable or recommendable
<Kamion> sqlite 2 according to dpkg -I
<ogra> dholbach, evo crashing isnt gpg related
<Gloubiboulga> has anyone seen janimo lately? I haven't seen him on irc or MLs since the Paris uds
<Kamion> interestingly, we currently have both sqlite 2 and 3 in main
<ogra> (happens as well if i switch off gpg completely)
<Kamion> libsqlite0 | 2.8.17-0ubuntu1 |          edgy | amd64, hppa, i386, ia64, powerpc, sparc
<Kamion> libsqlite3-0 |  3.3.5-0.2 |          edgy | amd64, i386, ia64, powerpc, sparc
<dholbach> Gloubiboulga: me neither... i wondered about that too. didn't he want to travel now?
<dholbach> ogra: you have a backtrace?
<Kamion> is there any prospect of getting rid of libsqlite0?
<Gloubiboulga> dholbach, no idea... I mailed him a few hours ago, I hope he'll reply soon
<Kamion> (if not, surely we should keep its bindings)
<ogra> dholbach, not yet... in the state my system is that takes some effort (i cant even type properly and the linux-image fix that adds keyboard support for me is still MIA)
<Kamion> jdub: ^--
<ogra> dholbach, i have a bug buddy backtrace, but i cant copy and paste apparently ...
<dholbach> it has a "save" button
<Kamion> ok, the seeds now require germinate 0.19 / 0.11ubuntu1 kthxbye
<ogra> dholbach, only if the "show details" button works .... damned
<ogra> upgradinbg to edgy with inly one laptop around was the worst idea evah
<dholbach> gdb -p $(pidof evolution)
<dholbach> or evolution-2.8 (whatever process is running now)
<ogra> dholbach, i cant copy and paste and i cant send mail, how would i get that to you ? :)
<ogra> i'll record it for later
<dholbach> ogra: https://wiki.ubuntu.com/Backtrace
<dholbach> is somebody aware of the wiki being a bit broken? like links going to help.ubuntu.com/community/<something> and are empty and stuff?
<ogra> i noted the extreme slowness through the forwarding, but i havent been forwareded to empty pages yet
<dholbach> http://wiki.ubuntu.com/DebuggingProgramCrash -> click on "Backtrace"
* ogra types the url ...
<Kamion> ogra: (done gcompris-sound-* seed change)
<ogra> Kamion, thanks
<ogra> dholbach, right, none of the subpages are there
<Kamion> damn, my germinate change wasn't *quite* right
<Kamion> it's randomly not grabbing some bits from extra
<Kamion> oh, I bet some bits don't realise that build-depends -> supported ...
<sivang> do we have a python roadmap for edgy? e.g., which versions we are going to support, transistions we process from debian etc?
<pitti> sivang: we should be almost back in sync with debian now
<sivang> pitti: I see, thanks, what is going to be 
<sivang> pitti: "the" python version for us?
<sladen> pitti_laptop: -dbgsym.ddeb or -dbgsym.deb ?
<sivang> (2.5 ?)
<pitti_laptop> sladen: .ddeb
<pitti_laptop> sladen: did I write a typo in my announcement?
<sladen> pitti_laptop: you wrote ".ddeb", and my instant reaction was kwtf, that must be a type, somebody would have to be utterly nuts to use a brand-new extension
<sladen> typo
<pitti_laptop> sladen: .ddeb was on purpose, see the spece
<pitti_laptop> s/e$//
<sladen> pitti_laptop: yeah, I found that
<elmo> pitti: you realise these can not possibly go on archive.ubuntu.com right?
<pitti_laptop> elmo: my original plan was to use .deb, but the soyuz guys and infinity convinced me that a separate extension/namespace was better
<elmo> pitti: I don't care about the extension
<pitti_laptop> elmo: we need a separate namespace to not kill the mirrors
<elmo> pitti: I care about the fact that archive.ubuntu.com even with only supported architectures is 160Gb
<elmo> you need a separate MIRROR to not kill the mirrors
<elmo> expecting hundreds of mirrors to add --exclude="*.ddeb" is utter crack
<sladen> pitti_laptop: the .ddeb is going to be a PITA though, lots of things are already set to see 'ahh .deb', I know what mimetype to serve that with and tools that assume that the file they are working with ends in .deb
<pitti_laptop> elmo: they will live somewhere else anyway AFAIU
<sladen> pitti_laptop: valid point, the application is probably broken if it is hard-coded to always append .deb
<Kamion> elmo: sorry, I'm going to need another germinate upgrade on drescher in a bit - trying to nail down the fix for the bug now
<elmo> pitti: ok - but just in case, I am going to add --exclude "*.ddeb" to our top levels :-P
<elmo> Kamion: k
<Seveas> pitti, how about s/-debugsym.ddeb/.debug.deb/ ?
<sladen> .udeb, .ddeb, .fudeb, .ubudeb
<pitti_laptop> elmo: I am sorry that I do not know the soyuz details; but the guys are aware that we must not silently push them to the mirros
<pitti_laptop> Seveas: it would make it hard to exclude the .ddebs from Packages.gz
<elmo> a new extension really isn't a problem
<elmo> any more than .udeb was for, err, udebs
<pitti_laptop> Seveas: also, since they do not appear in debian/control, dpkg-genchanges and soyuz will cry out
<Seveas> just add .ddeb to the mime databasses in standard ubuntu programs (so they eg still open with gdebi)
<sladen> pitti_laptop: find -name \*.deb -a \! -name \*.debug.deb
<pitti_laptop> sladen: btw, the intention is not that users actually install them, btw
<pitti_laptop> sladen: having a .deb-like file makes it convenient for developers, though
<Kamion> Seveas: if it's a different enough kind of thing (as pitti suggests) to deserve a separate extension, it should be properly separate rather than .debug.deb
<Seveas> Kamion, fair enough
<pitti_laptop> Seveas: hm, teaching our tools to append .debug everywhere would be even more invasive, I think
<pitti_laptop> although, no, forget that
<sladen> pitti_laptop: presumebly these packges Extend: the real one, or are they completely separate?
<pitti_laptop> sladen: right now, the .ddeb depends on the exact version of the .deb, nothing else
<pitti_laptop> sladen: I'm open to suggestions for improvements
<pitti_laptop> sladen: Extend:? There is an Enhances: AFAIK
<sladen> nod
<elmo> what on dapper renames my eth<n>'s?
<Mithrandir> udev
<elmo> ok, so any idea why it would rename a machine with two onboard nics, to eth2/3 on upgrade from breezy?
<Lathiat> does /etc/iftab apply?
<Lathiat> elmo: it could be one of those conflict things
<Lathiat> that causes them to jump up
<Lathiat> actualy i wouldnt have thought youd end up with 2/3
<giftnudel> I can confirm this on my Desktop, btw
<elmo> giftnudel: the random NIC renaming?
<giftnudel> not random, but +1
<giftnudel> when I upgraded to dapper
<sladen> elmo: /etc/udev/rules.d/25-iftab.rules
<sladen> elmo: bitch to keybuk about it, I think that is his crack
<elmo> hmm, the /etc/iftab was entirely disconnected from reality
<Kamion> gnomefreak: please don't mark ubiquity bugs as duplicates until you have read and understood http://wiki.ubuntu.com/DebuggingUbiquity
<Kamion> "you must not mark bugs as duplicates on the basis that they both contain a traceback such as this"
<Kamion> also if you use my standard texts from that page then you won't forget to ask for one of the log files I need :-)
<Toadstool> nice, I didn't know of this wiki page, makes ubiquity bugs triaging a piece of cake :)
<Toadstool> hi devs
<ogra> where is make-kpkg supposed to put my kernel package ? i just built my own kernel to get keyboard support back, but i cant find the package now
<Mithrandir> in .., usually
<ogra> meh, then i did something wrong
<ogra> *sigh*
* ogra tries something
<Mithrandir> Keybuk: would it be possible to have a list of merges mom skipped due to blacklisting in a BLACKLISTED directory or something like it?
<Keybuk> Mithrandir: mom doesn't have a blacklist
<Keybuk> which merge is missing?
<Mithrandir> Keybuk: x11proto-composite was, at least.
<rodarvus> most X packages are missing - but due to different package naming
<fabbione> Keybuk: all x11proto stuff was missing but it might be becuase of unmatching md5sum for the orig.tar.gz
<fabbione> Keybuk: perhaps it's just exploiting a bug in MoM
<Keybuk> let me look
<fabbione> Keybuk: you can try x11proto-xinerama
<fabbione> not the merge i already did, but using an older version
<Keybuk> DEBUG:root:x11proto-xinerama: ubuntu is 1.1.2-3ubuntu1
<Keybuk> DEBUG:root:x11proto-xinerama: debian is 1.1.2-3
<Keybuk> DEBUG:root:x11proto-xinerama: base is 1.1.2-3 (1.1.2-3 wanted)
<Keybuk> so there's nothing to merge there
<zul> hey
<Keybuk> our "base version" is the current version in Debian, as far as mom is concerned
<fabbione> <fabbione> not the merge i already did, but using an older version
<Keybuk> fabbione: do you have an example of something you haven't done yet
<fabbione> Keybuk: yes.. give me a minute to find one
<Keybuk> s'ok, found x11proto-xinerama in an earlier log
<Keybuk> i:Exit  -:PrevPg  <Space>:NextPg v:View Attachm.  d:Del  r:Reply  j:Next ?:Help
<Keybuk> DEBUG:root:x11proto-xinerama: ubuntu is 1.1.2-0ubuntu2
<Keybuk> DEBUG:root:x11proto-xinerama: debian is 1.1.2-3
<Keybuk> (note, no base)
<Keybuk> so there's never been a version in Debian prior to 1.1.2-0ubuntu2
<fabbione> x11proto-record
<Keybuk> DEBUG:root:x11proto-record: ubuntu is 1.13.2-0ubuntu2
<Keybuk> DEBUG:root:x11proto-record: debian is 1.13.2-3
<Keybuk> same problem, never been a version in Debian < 1.13.2-0
<fabbione> Keybuk: they have different md5sum for the orig.tar.gz in Debian and Ubuntu
<fabbione> that's all it matter
<fabbione> we had more history than debian
<Keybuk> fabbione: I don't think mom especially cares about that
<Kamion> perhaps it would be possible for MoM to output a list of packages that are in both Debian and Ubuntu but that have no common base
<Keybuk> it will do the merge with the Debian orig.tar.gz
<Kamion> in some of those cases it's worth our while trying to merge (most notably X but there might well be one or two others)
<Keybuk> Kamion: yeah, i can do that ... gimme a sec
<Keybuk> the interesting thing is that we have "Ubuntu Patches" for those
<Keybuk> they'd be at least useful for a manual merge
<seb128> does anybody know what is going on with the pango1.0 build?
<Keybuk> seb128: ask me in a minute
<seb128> ok
<fabbione> Keybuk: BenC was asking for a give-back of the kernel all over
<bddebian> Heya folks
<Keybuk> fabbione, Mithrandir:
<Keybuk> http://merges.ubuntu.com/main-manual.html
<Keybuk> http://merges.ubuntu.com/universe-manual.html
<Keybuk> that is the list of things MoM was not able to find a base version in Debian for
<Keybuk> each one is linked to the patch from the Debian -1 if it exists
<bddebian> whew, I only have 1 on that list :-)
<Keybuk> in a few cases (like xorg) the patch won't exist ... so that will need to be a truly manual merge
<fabbione> Keybuk: thanks
<Keybuk> ok, kernel given back
<Keybuk> seb128: yes?
<Keybuk> seb128: no builds recorded .. right
<Keybuk> probably needs me to shove my arm into the queue builder again
<Keybuk> yes, we're still in publish-distro ... the days are too long
<seb128> Keybuk: is there any public queue order or something like that?
<Keybuk> https://launchpad.net/distros/ubuntu/+builds?build_state=pending
<seb128> https://launchpad.net/distros/ubuntu/+builds?build_state=pending&build_text=pango
<Keybuk> you'll note there's nothing in the queue
<seb128> not listed
<seb128> right
<seb128> what does that mean?
<Keybuk> it means I need to do this
* Keybuk greases up his hand
* Keybuk sticks it into the buildd's innards
* Keybuk massages the appropriate point
<ogra> *shudder*
<bddebian> hmm
<seb128> Keybuk: thank you ;)
<bddebian> Hehe, response from Debian Developer:  "What is a desktop file" :-)
<ogra> seb128, i cant right click and suspect the main menu to be at fault for gnome-panel taking up 65% CPU, do you know of any key combo to remove an applet ?
<Keybuk> seb128: basically, the problem is that the buildd queue builder (which finds all the new sources that need building) cannot run during the publisher's cron.daily
<Keybuk> and right now, for various reasons, cron.daily is taking the full hour
<Keybuk> so there's no time for the queue builder to run
<Keybuk> unless it's run manually
<Keybuk> which is what I've just done
<seb128> ogra: gconf-editor? :)
<ogra> ah, thanks ...
<seb128> Keybuk: ah, ok
<Keybuk> so now we have another 300 things in the build queue
<Keybuk> and one of them is pango1.0
<Keybuk> https://launchpad.net/distros/ubuntu/+source/pango1.0/1.13.2-1ubuntu1
<Keybuk> ^ has a "Builds of pango1.0" portlet
<bddebian> Anyone happen to know when Debian is going to make the move to Python 2.4?
<seb128> right
<seb128> Keybuk: thank you :)
<seb128> bddebian: some weeks ago?
<tseng> bddebian: there is a new policy
<tseng> bddebian: python2.4-foo is not the way to go apperantly
<Amaranth> i think doko would be the person to ask about that
<ogra> seb128, yay
<ogra> seb128, i can reliably report the main menu in gnome is proken in current edgy on ppc :)
<ogra> *broken as well
<fabbione> ogra: you just destroyed my theory
<seb128> ogra: don't use edgy then
<ogra> fabbione, which was ?
<ogra> seb128, :P
<fabbione> ogra: edgy is bugless
<Amaranth> heh
<ogra> fabbione, well, apart from not having a keyboard driver in the kernel for my ibook and from the panel eating 65% CPU and the main maenu flickering wildly .... it *is* bugfree :)
<bddebian> tseng: ?
<fabbione> ogra: ok, then please go and fix bgu #51923
<fabbione> bug even
<jsgotangco> lol
<ogra> bug 51923 ?
<Ubugtu> Malone bug 51923 in Ubuntu "Please package footiefox (FireFox extension)" [High,Confirmed]  http://launchpad.net/bugs/51923
<ogra> haha
<bddebian> footiefox? Hehe
<Amaranth> high?
<fabbione> Amaranth: read the bug
<pitti> Hi Keybuk
<ogra> fabbione, only high ? 
<Amaranth> ah, football
<Amaranth> germany lost :/
<ogra> fabbione, well, you guys play the final ... so do something for it :P
<fabbione> ogra: i am sure you will get to critical.. you play saturday :)
<jsgotangco> hahaha
<ogra> i wonder if they willl put any effort into that game :)
<jsgotangco> i bet it was painful
<fabbione> jsgotangco: very!
<ogra> fabbione, you must admit, for a team that was completely new and partially players were even added weeks before the championship started they did very very well
<jsgotangco> beginner's luck!
<ogra> if they stay like that and just train over the next years they'll kick your butts next time :)
<fabbione> ogra: i didn't criticize at all how Germany did play.. it was a very balanced match
<ogra> yep
<fabbione> i still did suffer till the end
<bddebian> Goddamn I hate active stupid users...
<ogra> i found it impressing ... i wouldnt even have expected them to be that good
<fabbione> scoring 2 goals in the last 90 secs was well.. good
<\sh> ogra: germany never won against italy during a World/European Championship. but the statement: "Germany never lost a game in Dortmund" is now wrong
<ogra> luck ;) both teams deserved to win imho ...
<bddebian> fabbione: Hey, what's all this X crap from you? :-)
<fabbione> bddebian: helping the new X guy to stretch his wings
<ogra> bddebian, he leads us to new edgys :)
<fabbione> but as you said.. it's crap..
<Amaranth> stretch his legs?
<fabbione> they are barely include headers
<fabbione> Amaranth: no wings... X have angels...
<fabbione> Hell Angels
<Amaranth> they ride motorcycles? :P
<fabbione> Amaranth: yes here in dk they do. they are one of the most dangerous group of people around
<bddebian> ogra: Well fabbione, swore to me he wasn't touching X ;-)
<ogra> so can i find any reviewer to take a look at https://wiki.edubuntu.org/StudentControlPanelCompletion =
<ogra> ?
<fabbione> bddebian: and i am not touching it
<Amaranth> grr, kernel set the boot line to hda1 again
<fabbione> i am only merging it to help somebody that will do my job :)
<fabbione> bddebian: or do you expect us not to pass the cluebat
<fabbione> ?
<bddebian> fabbione: Of course not, isn't it "you are on your own fool.."? ;-)
<bddebian> Of course, before you yell at me, you know I am kidding :-)
<zul> mmm...clue bat
<fabbione> i am melting
* fabbione -> fridge
<fabbione> later
<ogra> fabbione, take a printout of https://wiki.edubuntu.org/StudentControlPanelCompletion with you and review it ;)
<jpatrick> ogra: "he is able to monitor the students desktops via vnc to see if his suspicion is true." sneaky :(
<bddebian> ogra: Persistent aren't you? :-)
<ogra> :)
<bddebian> I wonder how many DDs I can annoy today..
<zul> i awy atleast 2 :)
<bddebian>  awy? :)
<azeem> who's the new X guy?
<bddebian> azeem: rodarvus
<jsgotangco> hail our the new xorg czar
* bddebian bows before the czar
<jsgotangco> but aren't czars end up being beaten up by a mob?
<jsgotangco> heh
<bddebian> jsgotangco: Oh, I am sure he will :-)
<zul> jsgotangco: actually they wound up being shot :)
<jsgotangco> lol
* rodarvus just read the backlog now :)
<bddebian> Don't do it ;-)
<rodarvus> bad fabbione
<ogra> rodarvus, if fabbione is bad he turns into pinhead :)
<ogra> that was still the calm fabbione :)
<jsgotangco> scary
<bddebian> I packaged up a newer version of attal and pinged the Debian folks weeks ago and have heard nothing back.  Should I upload it?
<TheMuso> If anybody on the spec review team could give one final glance over spoken-boot that would be great. It was approved, but wasn't set as an edgy goal. I changed that and set it back to review just to make sure this is ok. Thanks in advance.
<ogra> Keybuk, dpkg-source: error: file kdeedu_3.5.2.orig.tar.gz has size 32344987 instead of expected 29849290
<ogra> i just try to build the original debian package, got all three files from mom
<pitti> ogra: then we have a different orig.tar.gz with the same name
<ogra> pitti, hmm
<ogra> thats evil
<pitti> ogra: you need to apply the diff.gz manually then
<pitti> ogra: (Debian's)
<ogra> pitti, yes, i know
<pitti> ogra: and chmod 755 debian/rules
<pitti> ogra: yes, it's evil :/
<ogra> i was just wondering why i got that error
<ogra> but indeed mom can only use one orig.tar.gz :)
* ogra goes to grab the debian orig.tar.gz to compare ...
<seb128> when is the next autosync from Debian run?
<Riddell> ping ubuntu-reviewers, kubuntu specs to be reviewed: adept-usability kde-kiosk-profiles kubuntu-accessibility kubuntu-printer-sharing kubuntu-system-settings-usability kubuntu-edgy-package-manager
<seb128> we need to the new pycairo to fix pygtk apps non running atm
<ogra> hrm, gtk2-perl is broken again ...
<ogra> pitti, hmm, how does mom get a orig.tar.gz for a package that *is* not in ubuntu yet ... kdeedu has no 3.5.2 in ubuntu 
<ogra> Keybuk, ^^^ ?
<ogra> so it must be the debian orig.tar.gz
<Riddell> ogra: is touch broken for you on amd64 in edgy?  it doesn't want to set timestamps for me
<ogra> Riddell, mount /proc :)
<Riddell> bah, more chroot hassle
<fabbione> ogra: sorry i managed to close myself inside the fridge
<fabbione> ogra: do you still need review for that spec?
<bddebian> fabbione: Nice, are you cooler now? :-)
<fabbione> bddebian: it depends what part of my body you are referring to
<bddebian> Hmm
<ogra> fabbione, yep
<fabbione> ogra: 
<fabbione> ogra: ok
<ogra> wow, thanks 
<fabbione> ogra: ok i will review it
<ogra> i think its pretty straight forward ...
<fabbione> just gimme a few minutes
<bddebian> Are we going to have libgl1-mesa-swx11-dev in Edgy?
<Kamion> it's in Debian unstable, so ...
<bddebian> Damnit, another blocked merge..
<bddebian> I guess I'll just wait till UVF to merge everything.. ;-P
<Kamion> \sh: the subject lines of bug 51976 and bug 51978 do not match the package names you've assigned them to; please clarify
<Ubugtu> Malone bug 51976 in libsdl-sge "[Edgy MoM]  sync libxbase 2.0.0-8 from unstable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51976
<Ubugtu> Malone bug 51978 in livehttpheaders "[Edgy MoM]  sync libhttpheaders 0.12-2 from unstable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/51978
<fabbione> ogra: Anselmo <- WORST NAME EVAR
<bddebian> heh
<bddebian> ogra: Put him back in the fridge ;-P
<Kamion> 16:03 < Kamion> Would someone who's experienced in writing specifications mind writing some use cases for https://wiki.ubuntu.com/UbuntuServerTasks? I've done the rest of the specification, but I couldn't
<Kamion>                 quite face the use cases ...
<Kamion> 16:03 < Kamion> some way to make them not just effectively a copy of the design would be nice
<Kamion> neuralis: ^-- maybe you could?
<tseng> bddebian: ?
<ogra> fabbione, feel free to put a new one in, its a wiki ;)
<bddebian> <tseng> bddebian: python2.4-foo is not the way to go apperantly <-- ?
<tseng> what part was confusing
<Kamion> see debian-devel-announce@
<bddebian> tseng: All of it?
<Kamion> one of the more recent posts has a link to the new python policy
<tseng> in the previous line i mentioned there was a new policy
<bddebian> Aye
<tseng> they were meant to be read as a pair
<fabbione> ogra: "/usr/share/doc/student-control-panel" is not policy compliant either and all that section is not clear at all
<bddebian> tseng: Ah, OK
<bddebian> Kamion: OK
<fabbione> ogra: otherwise it looks ok to me
<ogra> fabbione, hmm, you want the script there (it will be a five liner calliing chroot $LTSPROOT apt-get install x11vnc)
<ogra> ?
<fabbione> ogra: no, the script can't be in share/doc
<fabbione> ogra: share/$pkg/ is fine
<fabbione> ogra: plus you could install the package in the chroot without a script
<fabbione> ogra: iirc you still create the chroot on the server to boot
<neuralis> neuralis: i'll take care of it
<neuralis> er.
<ogra> fabbione, yes, thats the plan but i cant call it from postinst
<neuralis> Kamion: i'll take care of it.
<Kamion> neuralis: thanks!
* Kamion regains the will to live
<fabbione> ogra: you need to explain me what you are trying to do. it's not clear from the spec
<ogra> and you could also use it on ubuntu with no existing client chroot
<ogra> ok
<ogra> i'll change that section
<Gloubiboulga> dholbach, you want to merge the experimental packages for goffice and gnumeric, right?
<fabbione> ogra: ok and expand it if required. it doesn't need to be in one long sentence :)
<bddebian> dholbach?  Where is dholbach? :-)
<fabbione> ogra: you are allowed to use 2/3 of them :P
<ogra> heh, yep, will do :)
<Gloubiboulga> bddebian, he's everywhere
<bddebian> Gloubiboulga: Aye, just haven't "seen" him lately
<iwj> Ahhh, it's not finding the chrome _at all_.
<ogra> iwj, xulrunner doesnt need chrome :P
<dholbach> Gloubiboulga: yeah, that was the plan
<dholbach> bddebian: hellas :)
<Gloubiboulga> dholbach, ok
<neuralis> Kamion: some of these tasks look suspicious.. should xen really be a task?
<bddebian> Daniel!!
<dholbach> Barry!!!1111!! :)
<tseng> dholbach!!!!
<dholbach> hey tseng
<dholbach> rodarvus: congratulations to your first upload! :-)
<bddebian> heh
<rodarvus> dholbach, thanks! glad you noticed :)
* dholbach hugs rodarvus!
* rodarvus hugs dholbach back!
* pitti praises rodarvus for his X love
<Kamion> neuralis: dunno, I was just going off the BoF minutes, I was kinda tuned out during that
<Kamion> neuralis: I'm not hugely convinced by that one, no
<rodarvus> pitti, praise fabbione and Mithrandir :)
<neuralis> Kamion: yeah, the same for some of the other tasks. i'll take a cluebat to it.
<Hobbsee> jdub: oh *crap*
<Hobbsee> anyone got anywhere i can escape to in the next few days?
<pitti> rodarvus: I do! :)
<tseng> only if you can make it as far as Philly
<bddebian> hehe, I was going to say that
<Kamion> neuralis: ta
<tseng> pretty long trip
<bddebian> Hi Hobbsee
<Hobbsee> hi bddebian 
<Hobbsee> tseng: damn.
* Hobbsee is in real trouble now.
<tseng> ?
<Hobbsee> tseng: i got home about 1am, curfew was 12.
* tseng confused face
<zul> oh oh..
<Hobbsee> tseng: i was supposed to be home by a specific time, and couldnt be.
<tseng> yes?
<Hobbsee> so mum's not happy
<pitti> Hobbsee: then come home at 4am, then nobody will be angry any more; instead they'll be happy that you got back :)
<ogra> Hobbsee, offer lawn mowing or car washing to her :)
<Hobbsee> pitti: heh, i wish it worked like that.  i chose not to drive earlier cos i was tired.  but she'll still whinge, as that's twice in one week.
<Hobbsee> ogra: heh
<\sh> Kamion: sorry...
<Hobbsee> no, she'll just get utterly and totally pissed off and lecturing, i think.
<\sh> Kamion: the power of autocompletion :(
<\sh> Kamion: sync request for livehttpheaders corrected, #51976 rejected and sync request libxbase newly created 
<ogra> Keybuk, ping
<Yagisan> Hobbsee: you poor thing. Want me to pop over and give your mum the wrong idea ;)
<dholbach> tseng: thanks for pushing me
<tseng> dholbach: np
* Hobbsee kicks Yagisan again.
<Hobbsee> Yagisan: you know, i'd avoided comments like that *all* night - it felt so odd.  pity it didnt work this mornign too.
<Kamion> \sh: in future, no need to reject, just change the package name
<\sh> Kamion: right, k
<fabbione> morning mdz
<Keybuk> ogra: pong
<Hobbsee> hi fabbione 
<fabbione> hey Hobbsee 
<ogra> Keybuk, where does the orig.tar.gz in the kdeedu merge come from ? 
<ogra> (th eone for 3.5.2)
<Keybuk> please be more specific
<Keybuk> which orig.tar.gz, for which part of the merge (base, ubuntu or debian)
<ogra> i cant build the debian package thats on mom
<Keybuk> then it is likely the Ubuntu one
<ogra> hmm, i thought there was no 3.5.2 in ubuntu yet
<Keybuk> if Debian and Ubuntu have a different orig.tar.gz, you get whichever gets copied into the directory second ;)
<ogra> in any case its not the upstream one ...
<ogra> hm
<Keybuk> ubuntu: 4:3.5.2-0ubuntu9
* ogra looks
<Keybuk> ubuntu had 3.5.2 to begin with
<ogra> gah, i'm blind
<Keybuk> given the resulting merge is also 3.5.2, you'll need to upload with the Ubuntu orig.tar.gz
<ogra> well, the merge is completely broken
<Keybuk> you can grab the Debian tarball from Debian directly, or casey:/srv/patches.ubuntu.com/pool/debian/k/kdeedu
<ogra> yep, did that, buiuld is running
<Keybuk> ogra: how is it "completely broken" ?
<ogra> but the upstream source is different
<ogra> it isnt buildable ..
<Keybuk> right, there isn't anything mom can do in that circumstance
<Keybuk> manual merge time
<ogra> there seem to be pieces missing etc
<ogra> (from the tarball)
<Keybuk> that I doubt
<seb128> Keybuk: when is the next standard sync from Debian going to be done (ie: for packages already in sync)?
<Keybuk> I suspect you will find that the merge makes perfect sense if you compare the three source packages
<ogra> Keybuk, dpkg-source: error: file kdeedu_3.5.2.orig.tar.gz has size 32344987 instead of expected 29849290
<ogra> dpkg agrees with me :)
<Keybuk> ogra: now you're just being silly :)
<Keybuk> obviously the Debian source can't be unpacked ... the wrong orig.tar.gz is in the directory
<seb128> Keybuk: we need pycairo 1.2.0-1 to fix pygtk, if somebody could force a sync now instead of waiting on the next (daily?) run... :)
<Keybuk> seb128: I'll do it now
<ogra> Keybuk, the upstream tarball is missing stuff ... 
<ogra> (ours)
<seb128> Keybuk: thank you
<Keybuk> ogra: then that's our fault, not mom's :p
<ogra> Keybuk, yes, i didnt blame mom for it :)
<Riddell> ogra: what's it missing?
<Keybuk> probably worth uploading a new 4:3.5.2.0 or something with the Debian .orig.tar.gz
<Riddell> or just move to 3.5.3
<ogra> is there a 3.5.3 in debian 
<Riddell> packages.d.o says no
<ogra> Riddell, 
<ogra> ogra@edubuntu:/mnt/devel/packages$ rm -r kdeedu-3.5.2/debian
<ogra> ogra@edubuntu:/mnt/devel/packages$ rm -r kdeedu-3.5.2-1ubuntu1/debian
<ogra> ogra@edubuntu:/mnt/devel/packages$ diff -ruN kdeedu-3.5.2/ kdeedu-3.5.2-1ubuntu1/|wc -l
<ogra> 1050367
<ogra> there is missing a lot ...
<bddebian> eeks
<Riddell> ogra: anything important, i.e. not created by buildprep?
<Keybuk> TheMuso: ping
<ogra> Riddell, thats the unpacked source tarball ... no debian/ubuntu changes
<ogra> the upstream sources differ ...
<ogra> i have no idea how to merge that apart from doing a completely new package based on the debian version ...
<Riddell> well you should start by getting 3.5.3
<ogra> (well, we could carry around a 1050367 lines long patch ...)
<ogra> Riddell, but then we'll have that case again next time we'll merge ...
<Riddell> then copy the latest debian packaging, copy the kubuntu patches in debian/patches and debian/patches/common and make sure any changes in KUBUNTU-DEBIAN-CHANGES are included and voila
<ogra> unless i can be 100% sure the upstream tarball doesnt change before debian builds it
<Riddell> merge the changelogs too of course
<ogra> still, how can i be sure thats mergeable next time if we dont use the debian packages at some point ?
<Riddell> we can't use the debian packages, they're a version behind
<ogra> kdeedu is a hell of a package ... i wouldnt want to touch it again if there is *any* way to sync it
<ogra> phew, ok
<Riddell> the only part you need to care about is the debian directory, anything outside that is automake stuff
<ogra> sure
<ogra> i still dont undestand why our upstream tarball is 3M smaller than debians though ...
<sladen> ogra: if you unzip the tarballs, how does the size of the tars compare?
<pitti> ogra: gzip -9?
<ogra> ogra@edubuntu:/mnt/devel/packages$ ls -lh kdeedu*.tar
<ogra> -rw-r--r-- 1 ogra ogra 94M 2006-07-04 12:43 kdeedu_3.5.2-1ubuntu1.src.tar
<ogra> -rw-r--r-- 1 ogra ogra 29M 2006-03-30 13:47 kdeedu_3.5.2.orig.tar
<ogra> well ... wait ...
<Riddell> ogra: the debian packager has done it as bz2 inside .orig.tar.gz
<ogra> Riddell, yep, looks like it ...
<Riddell> ogra: however it looks like debian has changed to cdbs so you should just start by coping over their latest packaging (to kdeedu 3.5.3)
<ogra> yep
<neuralis> Kamion: done, let me know if you need anything else
<mdz> pitti: regarding bug 45406, should I review what is there or are you going to revise it based on the comments?
<Ubugtu> Malone bug 45406 in libgnomecups "memory leak in gnome-cups-icon" [Unknown,Fix released]  http://launchpad.net/bugs/45406
<mdz> oh, I see a new one has been attached, though I didn't receive mail about it. odd
<pitti> mdz: hm, I didn't get the last one as mail either; but maybe it'll still arrive
<ivoks> hi
<ivoks> new one is better
<bddebian> Heya ivoks
<ivoks> mdz: i add it couple of minutes ago
<ivoks> bddebian: hello, what's up?
<Riddell> carlos: are you able to take ownership of a l10n team?
<rodarvus> mdz, do you think you'll be able to review fully-automatic-swap-server and ltsp-login-and-session-handling today, or should I ask someone else on the ubuntu-reviewers group?
<carlos> Riddell: no, I don't have such rights, but we can ask an admin
<Riddell> carlos: who's one of them?
<carlos> Riddell: is there any abuse of the system?
<Riddell> carlos: nope, just the en-gb admin is without internet
<rodarvus> s/be able/have time/
<Keybuk> rodarvus: I'll take the first one
<rodarvus> Keybuk, thanks!
<carlos> Riddell: https://launchpad.net/people/admins
<mdz> rodarvus: ubuntu-reviewers
<rodarvus> mdz, I'll ask them, thanks!
<bddebian> ivoks: Not much thanks, you?
<mdz> why do people keep trying to subscribe to the technical-board list?
<mdz> I wonder if it should be hidden from the index
* bddebian is innocent for once, I swear
<Riddell> do I really needs to ask all the ubuntu-reviewers to look at all the kubuntu specs still to be reviewed?
<ivoks> bddebian: same here :)
<mdke> mdz: the CC list is hidden
<mdz> mdke: good point, I'll do the same for TB then
<mdke> rather more surprisingly, so is ubuntu-server
<Keybuk> mdz: I just did already :p
<mdz> Keybuk: yes you did
<adamant1988> can anyone tell me what kind of packages will be included in the commercial repos?
<Keybuk> commerical ones
<adamant1988> nice.  But i mean would a DVD play back program that allows for DMCA compatible dvd playback be in there?
<Keybuk> if there was a piece of commerical software that did that for Linux and was appropriately licenced to allow distribution (which I believe is not possible)
<ogra> adamant1988, if you have to offer one we're alloed to distribute by your company, we could put it in there, yes
<ogra> Keybuk, sure, why shouldnt it be licensed appropriate ... if the company that offers it pays for all the patents etc ...
<adamant1988> keybuk, it's possible.  Linspire offers LEGAL dvd playback
<seb128> adamant1988: they probably pay for it
<Keybuk> ogra: company has to pay for patent per-seat, no?
<Keybuk> adamant1988: you pay for linspire, it's not freely downloadable
<adamant1988> i'd pay for the program
<ogra> Keybuk, and ? then you need a key to activate the proggy ...
<lukaswayne9> After latest edgy updates, X.org redraws things VERY slowly.  Should I report a bug, or is too early in the release cycle?
<Keybuk> lukaswayne9: X is very much being changed atm
<lukaswayne9> Keybuk: may I ask what changes are happening?  7.1 transition?
<Keybuk> lukaswayne9: sync with debian
<lukaswayne9> Keybuk: I guess I'll wait a bit to report a bug, things will probably get flushed out once the sync finishes
<ogra> lukaswayne9, give it until UVF to stabilize :)
<seb128> Keybuk: could you run the buildd queue builder? Would be nice to have GTK 2.10 planned for build :)
<Keybuk> seb128: cron.daily is still running
<Keybuk> and, dude, you've only just UPLOADED the frickin' thing
<Keybuk> it hasn't even had the source published yet
<bddebian> heh
<Keybuk> the buildds don't pick source off your hard drive, you know
<seb128> Keybuk: I've uploaded like half an hour ago I think
<pitti> Keybuk: that'd be even better than building from accepted :)
<Keybuk> seb128: so you missed a cron.daily run
<Keybuk> it'll be published tomorrow
<Keybuk> then built the day after
<Keybuk> and then the binaries published the day after that
<ogra> Keybuk, we could do that with zeroconf :)
* robertj smacks ogra
* ogra hides
<seb128> Keybuk: right, but I just would like to be around when the package becomes available so I can fix any issue with it without letting it b0rked until tomorrow morning :)
<robertj> (worst thread ever)
<seb128> Keybuk: anyway, no hurry, I'll wait the some "days" required for it :)
<pitti> seb128: before I want python-defaults to be built, which is sitting in needs-build since this morning :)
<Keybuk> of course
<Keybuk> we won't get a build queue run today anyway
* pitti guesses the build queue must be endless
* Keybuk takes a pick-axe to soyuz
<seb128> pitti: doesn't look like
<Keybuk> pitti: no, the build queue is empty
<Keybuk> pitti: python-defaults built 3 minutes ago <g> -- https://launchpad.net/+builds/+build/221939
<pitti> Keybuk: oh, whoa, it must have been built in the last 10 minutes
<pitti> Keybuk: \o/
* pitti apologizes to the buildds
<bddebian> pitti: :-)
<pitti> argh, mvoooooo!
<pitti> el: Encountered a section with no Package: header
<Keybuk> oh,
<pitti> breaks apt and goes to holiday *sigh*
<Keybuk> this could be fun
<Keybuk> cron.daily has so far been running for 52 minutes
<pitti> s/el:/E:/
<Keybuk> and hasn't even reached publish-distro yet
<Keybuk> !!!!
<seb128> pitti: that's your languagepack source, right?
<pitti> seb128: indeed
<seb128> hehe :)
<pitti> 'Problem with MergeList /var/lib/apt/lists/people.ubuntu.com_%7epitti_langpacks_daily_dapper-updates_._Packages'
<crimsun> pitti: hi, how how does -security handle GPG key retrieval for keys used to sign uploads? I presume my uploads of openvpn to breezy-security have failed due to a key expiration (since I've received no accept or reject e-mail), which seems odd because the precise key used to sign the upload is accepted for Edgy uploads.
<bddebian> Heya crimsun
<bddebian> Did mine not go through either?
<pitti> crimsun: -security is on a different host (jackass); you need to ping elmo to refresh your key there, I assume
<pitti> bddebian: what did you upload?
<crimsun> bddebian: I presume you uploaded to security.upload.ubuntu.com?
<pitti> crimsun: let me look into the log
<bddebian> crimsun: Yes
<pitti> crimsun: indeed, it's expired
<crimsun> pitti: ok, thanks much
<crimsun> elmo: please refresh 0xC88ABDA3 for -security uploads, thank you  [context: < pitti> crimsun: -security is on a different host (jackass); you need to ping elmo to refresh your key there, I assume] 
<mdz> sivang: why do you want to have two separate menu items for backups?  seems confusing
<wasabi_> I'd sure like to see swapd work at some point.
<fabbione> wasabi_: why?
<wasabi_> I think it's much more flexible than a static swap partition.
<wasabi_> And can handle situations better, such as extending the swap on the fly.
<wasabi_> (with the posibility of raising an event to the user that it happened)
<pygi> mdz, poke?
<mdz> pygi: yes?
<pygi> there isn't library for burning, but we agreed to work on that for edgy+1
<pygi> feature freeze for edgy is too soon
<ogra> pygi, ?
<ogra> pygi, what about the libburn stuff ?
<fabbione> wasabi: it's something you can do even now, if you install your machine properly with lvm 
<fabbione> wasabi: or use loop files to achieve that
<fabbione> wasabi: nothing stops you to add a loop device as partition
<fabbione> s/partition/swap &/
<pygi> ogra, any python bindings for that?
<ogra> i dont think so, but they should be easier to add than to write a burn lib from scratch
<ogra> and you dont need cdrecord
<pygi> ogra, right :)
* pygi totally forgot the libburn, thanks ogra ^^
<wasabi_> fabbione: Sure, mostly what I mean, is swapd does it "automatically".
<wasabi_> Creating loop swap files as needed.
<wasabi_> I think there's a value in having that easily apt-get installable and Just Work.
<rodarvus> Keybuk, ping
<Keybuk> rodarvus: heyhey
<rodarvus> did you had time to review fully-automatic-swap-server?
<Keybuk> I have had no time yet
<Keybuk> it's on my list
<rodarvus> I ask because I have two others I need to find someone to review :)
<bddebian> Oh no, one of my Debian BTS submissions went to lamont :)
<rodarvus> edubuntu-xfce-desktop and ltsp-login-and-session-handling
<mdz> rodarvus: edubuntu-xfce-desktop should probably say something about how the seed will be maintained.  presumably it needs to be kept in sync with xubuntu-desktop
<mdz> rodarvus: also, how will it differ from xubuntu-desktop?  does it need to?
<ogra> mdz, the idea was to only have xfce
<ogra> we have nautilus on the CD already, no need for a different filemaneger for example
<mdz> ogra: and no applications at all?
<rodarvus> it will only need to be different from xubuntu-desktop if we need to create extra packages with different configuration, specific for Edubuntu
<ogra> well, sure applications as well, but the main complaint iss that there is no light desktop in edubuntu ...
<ogra> the CD has all other bits ...
<mdz> ogra: I'm asking why you can't use xubuntu-desktop instead of creating a new seed and metapackage
<ogra> i dont want to use up the CD space we have now with xubuntu packages
<mdz> because the spec doesn't say how it will be different
<ogra> i think highvoltage wanted edubuntu branding for it
<highvoltage> mdz: another reason is that xfce needs to be aware of edubuntu specific things, ie. use the same wallpaper, similar menus, etc
<bluefoxicy> heh
<ogra> highvoltage, ?
<mdz> don't tell me; write it in the spec
<bluefoxicy> ogra:  I had a silly thought earlier to split out the gnome/xfce desktops from *-desktop
<ogra> :)
<bluefoxicy> ogra:  so that it'd be ubuntu-minimal ubuntu-standard ubuntu-gnome (workable GNOME desktop) ubuntu-desktop (a bunch of GNOME applications like gimp, ekiga...)
<bluefoxicy> and similar with XFCE
<highvoltage> strange, i thought i had that in the rationale, but i don't :/
<ogra> well, there is no real need for that ... 
<ogra> why would you split the desktop package ? 
<pygi> sivang, poke? :)
<bluefoxicy> ogra:  If you're going to fork something off xubuntu-desktop but try to stay in sync with them, that may be a bit easier, since the common packages would be in one meta-package instead of two.  Then again, you would have ANOTHER meta-package to keep track of.
<bluefoxicy> ogra:  so, just a thought.
<ogra> bluefoxicy, thats donnr on a bzr level ... no need for changes on the toplevel
<ogra> *done
<bluefoxicy> bzr?
<bluefoxicy> BZflag Reloaded?
<ogra> bazaar
<bluefoxicy> .... I like my idea better.  bzflag is fun.  :)
<bluefoxicy> anyhow.  *slips off*
<shawarma> does anyone know when infinity will be back from his holidays?
<fabbione> shawarma: sometimes next week i think
<fabbione> anyway i need to get out of here
<fabbione> later
<shawarma> fabbione: Thanks.
<mdz> doko: why do we want an i386->amd64 cross compiler?
<doko> mdz: a) a faster compiler for i386 only, b) correct code for -m64. I don't know if the latter is still valid. need to find some other people to validate that
<mdz> doko: reviewed with comments
<bluefoxicy> i386->amd64 is faster?  I thought an amd64 compiler building i386 code would be faster... o.o
<bluefoxicy> (no, really, with 8 more GPRs and the freaking lot of work the compiler does shifting shit around, there should be a substantial speed gain here >.>)
<bluefoxicy> Hey does anyone know when abouts I should expect Edgy to explode horribly-- I mean, get Xorg 7.1?
<tseng> bluefoxicy: can you please troll somewhere else?
<bluefoxicy> troll what?
<bluefoxicy> Where else is there to ask that?
<tseng> it wasnt the question, it was the horrible signal/noise, and the attitude
<wasabi_> Linux memory confuses me.
<wasabi_> What the heck does this figure in "top" "cached" refer to.
<tseng> wasabi_: i think that refers to some kind of system cache for recently used files
<bluefoxicy> wasabi_:  disk cache, every time a file is read it's stored in memory so you don't have to toy with the disk every 10mS and lag like hell.
<wasabi_> Not exactly. Because the OOM killer kills a program vs sacrificing it.
<wasabi_> Which suggests a different purpose.
<\sh> re
<bluefoxicy> or just a bug in the OOM killer.
<wasabi_> True... but I doubt it.
<bluefoxicy> I have seen Linux OOM kill things when I have a gig and a half of free swap
<bluefoxicy> trust me it can have bugs.
<wasabi_> Well, I turned my swap off, to try to understand what it's doing.
<wasabi_> free shows 2048MB total, used 2020MB, cached 1515MB.
<wasabi_> Which, from my original understanding meant that there was very small amounts of ram actually "used"... ie data that wasn't directly from a disk.
<wasabi_> basically used - cached
<bluefoxicy> yes
<wasabi_> mmaped files. Where do they fall.
<wasabi_> I'm guessing they don't show in used, but show in cached.
<\sh> moins slomo
<slomo> hi \sh 
<\sh> guys I'm happy to be back in action :)
<bddebian> And we are happy to have you ;-)
<LaserJock> we are happy you are back in action too
<ogra> fabbione, still around ? i fixed https://wiki.edubuntu.org/StudentControlPanelCompletion
<slomo> hm, why is dash the default shell now?
<ogra> slomo, beacuse its way faster and smaller
<slomo> ok, good reason :)
<ogra> no need for a user shell for script execution
<ogra> adduser still uses bash for user accounts
<\sh> woot? you mean I have to adjust my default shell from dash to bash?
<ogra> nope
<slomo> \sh: no but /bin/sh is now dash
<ogra> the system uses dash ... but all users go on using bash
<crimsun> thank god
<crimsun> dash++
<\sh> how compatible is dash to bash?
<ogra> yeah
<slomo> \sh: dash is 100% posix compliant and only supports that, nothing else
<\sh> because I have to be careful then with all my shell scripts which are using bash style ;)
<\sh> rodarvus: do you know why libxext-dev is not in x-dev? 
<Kamion> neuralis: thanks! will look over it post-karate-training
<rodarvus> \sh, x-dev is a dead package
<rodarvus> X >= 7.0 is modular
<\sh> rodarvus: ok...I just wondered why we are behaving differently from debian
<rodarvus> we aren't
<rodarvus> they have libxext-dev on a separate package too
<Kamion> xorg-dev will have that sort of stuff
<Kamion> it's a metapackage in Debian
<Kamion> x-dev was only ever the core protocol headers
<\sh> rodarvus: right, but I just had a package which had only libx11-dev, x-dev as build-dep but I had to add libxext-dev to it
<Kamion> (and it'll be called x11proto-core-dev in edgy)
<Kamion> \sh: x-dev isn't a metapackage, it's the core protocol. if you need X extension headers then you need to build-dep on libxext-dev
<Kamion> oops, late, gotta run
<\sh> Kamion: yeah, but I wonder why debian just used libx11-dev and x-dev as build-dep ... 
<Burgwork> slomo, do you have any plans with tomboy or beagle for edgy?
<slomo> Burgwork: for beagle ask tseng... for tomboy no idea yet... we'll see. but would be nice to have it installed by default
<Burgwork> slomo, ok, just wondering. tomboy might make it upstream as well
<slomo> Burgwork: what do you mean with upstream?
<Burgwork> slomo, gnome is considering tomboy for .16
<crimsun> hmm, what is polypaudio's new name [if it has one] ?
<slomo> Burgwork: oh, cool. that would be nice :) is it likely or will it probably fail because "mono is evil"?
<jdub> eek
<jdub> whoa
<Burgwork> crimsun, pulse
<slomo> crimsun: pulse audio iirc
<jdub> vim in edgy has all the crack on by default
<jdub> like folding in changelogs
<Burgwork> slomo, it might fail, there was some discussion of that
<jdub> whoooa
<ogra> jdub, yeah its hefty :)
<Keybuk> jdub: :se nofoldenable
<crimsun> Burgwork: / slomo: danke
<Keybuk> vim7 has some serious arse-wobble going on
<jdub> Keybuk: not sure i don't like it yet, but it was surprising. it also has shiny paren matching.
<Keybuk> "you're editor's so FAT ..."
<dieman> oooo. i got my stickers and cds today
<jdub> "your" :)
<Keybuk> yes, that too
<jdub> hrm, i should set up pbuilder again
<slomo> Keybuk: hi :) can you move libvisual to main (report approved by pitti a few days ago), give-back gst-plugins-base0.10 (after libvisual is in main) and gtk-sharp2? ;)
<Burgwork> slomo, http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00457.html
<ogra> jdub, merges.ubuntu.com :)
<crimsun> I thought you were an emacs user, Keybuk (perhaps wrongly assumed from the u-d-a post regarding package maintenance in bzr)
<Burgwork> slomo, and http://mail.gnome.org/archives/desktop-devel-list/2006-April/msg00253.html
<jdub> ogra: hrm?
<ogra> <jdub> hrm, i should set up pbuilder again
<LaserJock> jdub: a good workout for you pbuilder :-)
<slomo> Burgwork: thanks :)
<Keybuk> crimsun: I am
<jdub> ogra: didn't see the connection
<Keybuk> slomo: no.
<ogra> jdub, well, give it something to do :)
<jdub> ogra: i want to test my own packages! (i'm lazy with build-deps withotu pbuilder)
<jdub> does our pbuilder have ubuntu love by default?
<ogra> if you create one in edgy, it will be an edgy pbuilder for ubuntu ...
<Keybuk> crimsun: what about that post implied emacs user?
<jdub> has X broken in amusing ways yet?
<crimsun> Keybuk: sorry, not that post but one of myriad ones related where you mentioned an emacs mode?
<crimsun> Keybuk: (my memory's pretty bad)
<zul> are we using mdadm by default now or have we always been using it?
<ogra> jdub, just starting 
<ogra> i guess next week will be the fun week :)
<jdub> as in, the latest uploads are broken?
<ogra> no idea, after i lost my top panel and my keyboard on the ibook i got careful about upgrades for now ;)
<Keybuk> slomo: (verbose answer; I'll move libvisual to main when there's not a publisher run going on ... gst-plugins-base0.10 doesn't need a give-back because it's already in dep-wait ... gtk-sharp2 failed for other reasons)
<slomo> Keybuk: it failed because libbonobo was broken at that time... i fixed it yesterday. with current edgy the latest gtk-sharp2 package build just fine
<^robertj> ogra: btw, does your ibook smell?
<slomo> Keybuk: for gst-plugins-base0.10... nice that auto-dep-wait-removal is now implemented :)
<Keybuk> slomo: ok, gtk-sharp2 given back
<Keybuk> slomo: dep-wait removal has always been implemented, afaik
<Keybuk> it just takes a couple of days
<^robertj> ogra: I was wondering if there is some mis-calibration of some software controlled fan in there...mine stinks and other people have had issues where the fan stops spinning properly, the bottom of the keyboard starts to melt, and the whole thing smells rather putrid
<ogra> the bottom gets very hot, yes ... but i have no probs with the fan ... and i wouldnt smell if it stinks, i'm a strong smoker
<tseng> Keybuk: thanks
<slomo> Keybuk: thanks :)
<jdub> "my ibook has no nose!"
<ogra> how does it smell ? 
<Keybuk> well, it _looks_ like a toilet seat
<ogra> hehe
<highvoltage> my thinkpad has no mouth, but it can scream
<bluefoxicy> tseng:  Not including -DFORTIFY_SOURCE in Edgy?
<bluefoxicy> (no, I don't have an analysis or opinion on why/how/if this would/wouldn't help)
<tseng> well, please get one :)
<bluefoxicy> it does compile time checks (nice) and replaces strcpy() et al (I'm wary of screwing with this...) with functions that do checks where we know the buffer size and length of the data to be copied at run time but not compile time.  Obviously that has some gains in some places, not sure how significant it can be when SSP is already trapping "before any damage can be done" or how much of a trade-off this is WRT stability
<tseng> right so SSP has a strong heuristic for writing into a buffer
<tseng> not "these 3 functions that we dont think are safe"
<tseng> right?
<bluefoxicy> SSP will trap ANYTHING before a 'ret' happens, but after memory space is destroyed
<bluefoxicy> fortify source will trap a few choice functions before memory space is destroyed, but still abort
<tseng> well, i am thinking of the difference between -fstack-protector and -fstack-protector-all
<tseng> if there is still such a thing
<bluefoxicy> nicely, it'll also look at things like 'char a[4] ; strcpy(a, "this is too long")' and go "No, I'm not compiling this crap"
<tseng> sounds nice
<bluefoxicy> yeah.  I'm not sure if there's a way to do the compile time checks without the code replacement though
<bluefoxicy> if fortify_source sees something like "char a[5] ; strcpy(a, passed_string);" it'll replace strcpy() with some sort of _internal_strcpy(a, passed_string, 5) and then check if strlen(passed_str) < 5
<bluefoxicy> Which to me is minimally useful.  It won't do jack if you use glib, for example.
* tseng makes a face
<tseng> that adds nothing with ssp
<bluefoxicy> I know.
<bluefoxicy> oh
<bluefoxicy> it'll also check a strcpy() if it's copying to a buffer that was JUST allocated in the same scope
<bluefoxicy> (i.e. malloc() ... heap protection)
<bluefoxicy> which is not that spectacular.  glib will break this again.
<tseng> why dont you spend your time getting things to work with ssp rather than futzing with fortify_source then?
<bluefoxicy> my regression test suite says the current edgy gcc is spitting out SSP'd code by default.
<tseng> most of the problems in HG were from -fstack-protector-all
<\sh> Keybuk: are syncs not removed from the merge pages?
<bluefoxicy> personally I don't like -all; I guess it protects var_args functions, or so I've been told, but those are far and few and I would rather not sacrifice performance in a lot more places for gains in a number of places countable on one hand
<Keybuk> \sh: they should be
<Keybuk> \sh: assuming the sync has been published
<Keybuk> \sh: which has not been removed?
<\sh> I have a look...
<bluefoxicy> tseng:  Xorg doesn't have a problem with -fstack-protector anymore right?  I can't remember if that was pie or SSP... or if it was fixed ages ago (I remember it was 'fixed' 10 times and kept still being busted)
<tseng> it was NX
<bluefoxicy> I mean libbitmap.a/la
<tseng> oh, that was ssp I think
<bluefoxicy> it would scream about duplicate symbols.
<tseng> and I definately remember fixing it
<tseng> yes?
<bluefoxicy> thought so
<tseng> maybe i just used filter-flags
* bluefoxicy reads cvs
<bluefoxicy> 	ALLOWED_FLAGS="-fstack-protector -march -mcpu -mtune -O -O0 -O1 -O2 -O3 -Os"
<bluefoxicy> tseng:  I guess you fixed it.  It definitely worked last I was on Gentoo.
<\sh> Keybuk: e.g. alps-light1
* jdub blinks.
<tseng> -fPIE -fPIC are notably missing
<tseng> but they arent in ubuntu, anyway
<\sh> Keybuk: https://launchpad.net/bugs/51608
<Ubugtu> Malone bug 51608 in alps-light1 "[not dev]  sync request of alps-light1_1.2.2-2 from debian unstable" [Untriaged,Fix released]  
<Keybuk> \sh: looks like the sync never happened
<tseng> -fPIE is scary
<Keybuk> a couple went messing
<Keybuk> I'll do it again
<bluefoxicy> tseng:  -fPIE is nice though, if you have code in the kernel to randomize the executable and brk() base
<\sh> Keybuk: ah ok...yeah I see it now on the source package LP page
<bluefoxicy> Computers are so violent, executing tons of poor, innocent programs every day.
<Keybuk> whooo
<Keybuk> a smidgen under 2 hours for a daily
<Keybuk> that's juuuust enough time to run the queue builder
<bluefoxicy> tseng: http://gcc.gnu.org/ml/gcc-patches/2004-09/msg02055.html  I can't understand this, it's muddled.  It looks like -DFORTIFY_SOURCE=1 turns on compile checking and -DFORTIFY_SOURCE=2 modifies code... maybe.  I haven't a clue and I can't find 'FORTIFY' in the body of the damn patch.
<bluefoxicy> you know what.  Jelinek wrote it, I'll ask him.
<crimsun> is $() preferred over ``  [for commands]  in sh?  (considering the transition to dash in Edgy)
<elmo> both are POSIX, so it's moot
<crimsun> elmo: ok, thanks
<Keybuk> they just have different quoting semantics
* jdub prefers $()
<wasabi_> I like $() too. Shows "containment" much better.
<wasabi_> Also nestable.
<wasabi_> So has anybody considered swapd in Ubuntu, vs a swap partition?
<wasabi_> Would love to read some opinion on pros/cons
<wasabi_> Maybe with some tuning, etc.
<bluefoxicy> swapd never seems to de-allocate swap; and OOM's a lot.
<bluefoxicy> it's insensitive to disk cache vs swappiness as well
<bluefoxicy> plus linux allows like 8 swaps to be active
<wasabi_> How so?
<wasabi_> Curious about the swappiness problem. What's that mean?
<bluefoxicy> wel
<bluefoxicy> if you have a 2 gig swap partition
<bluefoxicy> you may wind out with 300 megs used in swap, 700 megs of ram used, and 300 megs of disk cache (vm.swappiness = 60)
<bluefoxicy> if you have no swap partition and 32 meg swap files in swapd, you may hit 950 megs of RAM used and 2 32 meg swap partitions holding 50 more megs of memory
<bluefoxicy> leaving about 50 megs of disk cache (kernel will keep around 5-10 megs free though, so more like 40 megs)
<bluefoxicy> oddly enough, this is less efficient.
<wasabi_> Not understanding why. ;0
<wasabi_> Does the kernel see the available swap as a factor in it's decision on when to cache?
<wasabi_> Also the OOM thing, would it not be proper for swapd to be notified before the OOM killer runs, in order to expand instantly?
<wasabi_> vs polling
<wasabi_> Also, it might make sense to have a minswaps option for swapd, which always forces the creation of at least one swap file.
<wasabi_> Or maybe "auto" options, which adjusts the size of swap files based on available core.
<ogra> mdz, get off the idea of writing everything into the client chroot in ltsp :P
<ogra> we need to get to a poiunt where ldap auth is possible and you can select between multiple servers in the network on login in the future ...
<Burgwork> ogra, isn't that what ajmitch is working on?
<ogra> Burgwork, yeps
<ogra> Burgwork, i was commenting on a spec comment mdz made ...
<pygi> sivang, poke? :)
<TheMuso> Keybuk: pong
<Keybuk> TheMuso: any particular reason you unapproved your own spec?
<TheMuso> Well I thought that since it wasn't targeted for edgy, and since I wanted it to be as such, that I should run it by you guys first.
<Keybuk> I approved it
<Keybuk> and I marked it as proposed for edgy
<TheMuso> I know you approved it, but I didn't see anything for it to do with edgy.
<Keybuk> I was surprised that you marked it as "needs review" again, without making any changes
* TheMuso is still getting the hang of launchpad
<Keybuk> so, what would you like to do with that spec?
<Keybuk> would you like it reviewed again?
<Keybuk> would you like to alter it?
<Keybuk> would you like it to be approved and targeted for edgy?
<Keybuk> would you like it to be approved and targeted for a later release?
<TheMuso> Yeah please
<TheMuso> Approved for edgy if possible.
<Keybuk> to which? :p
<Keybuk> I see espeak is already in NEW, and the other bits should be in place for other reasons, I don't see why it wouldn't make it for edgy with your help
<Keybuk> so approved
<Keybuk> (again)
<TheMuso> ok thanks, and apologies. :)
<TheMuso> BTW how is boot message logging getting on?
<Keybuk> no worries
<Keybuk> I haven't started it yet
<Keybuk> we're still doing merges until upstream version freeze next week
<Keybuk> and then I'll begin working on specs
#ubuntu-devel 2006-07-06
<TheMuso> Ah fair enough.
<sladen> UVF is next week?!
<Keybuk> yes
<Keybuk> week tomorrow
<Keybuk> effectively a week from now, in fact
<sladen> do we even have a building build system yet
<sladen> ...nevermind
<Keybuk> at the moment, yes
<Keybuk> don't stare at it too hard though
* LaserJock looks away
<HiddenWolf> sladen, dapper ran long, edgy is a 4 month cycle only
<Keybuk> ergo 6.06 "Late To Ship"
<LaserJock> lol
<LaserJock> now I know why that LTS was there ;-)
<HiddenWolf> Keybuk, you wish. :)
<jdub> Keybuk: what's the name of that user style firefox extension you suggested? "stylish"?
<Keybuk> stylish = greasemonkey for css
<HiddenWolf> Keybuk, that'd save you from fixing weird dapper bugs for paying customers. ;)
<Keybuk> yes
<Keybuk> https://addons.mozilla.org/firefox/2108/
<jdub> thanks
<LaserJock> Keybuk: where's that LP thing you did for stylish?
<Keybuk> http://people.ubuntu.com/~scott/launchpad.user.css
<Keybuk> though you also need greasemonkey and
<LaserJock> ah, sweet thanks
<Keybuk> http://people.ubuntu.com/~scott/launchpad.user.js
<LaserJock> way cool
<givre> great day today, svn works and france is in final ;)
<givre> sorry wrong channel
<Keybuk> 2006/07/06 00:46 BST [-]  Scheduling queue_builder for   1.18 seconds time
<Keybuk> 2006/07/06 00:46 BST [-]  Running queue_builder
<Keybuk> 2006/07/06 00:49 BST [-]  Job queue_builder completed with exit code 0
<Keybuk> AHA!
<Keybuk> the queue builder took three minutes
<Keybuk> that's more like it!
<robertj> btw, does anyone know an easy way to reply back to a specific digest message without screwing up the threading?
<Hobbsee> hi all
<Hobbsee> hi jdub 
<jdub> hey Hobbsee 
<Hobbsee> jdub: i didnt *quite* get killed :P
<jdub> haha
<bddebian> Hello
<bluefoxicy> Can I change #51881 to critical
<Keybuk> bddebian: I was just thinking about you
<bddebian> Keybuk: Uh oh, what did I do now?
<bluefoxicy> I mean seriously, I just got another font package that went nuts on me
<whiprush> jdub: what's your preferred email address for requests for speaking at shows/cons? 
<Keybuk> bddebian: sync requests :p
<bddebian> Keybuk: Did I screw one up again?
<Keybuk> nope
<jdub> whiprush: depends on the context ;)
<jdub> whiprush: i've applied for ohio btw
<whiprush> oh, one of the planners just mailed me, I just wanted to make sure I linked you guys up.
* whiprush adjusts the mail accordingly.
<HrdwrBoB> is there any special reasons why uniq has actually had features removed from version 5.2 to 5.93? (breezy- dapper)
<bddebian> WAY OT: But have any of you heard of any EDI Translators for GNU/Linux?
<bddebian> Thanks Keybuk :-)
<bluefoxicy> Setting up xfonts-intl-european (1.2.1-6ubuntu1) ...  <-- this is main, right?
<Keybuk> jdub: hang on, phone died :p
<jdub> heh
<jdub> 1:17 in one call ;)
<dieman> oh jeez, people are digging ubuntu specs now
<Keybuk> k, calling again
<dieman> you know its crazy when...
<Keybuk> uh, call again even
<Keybuk> (I don't have your sip address in my book yet)
<jsgotangco> good morning
<Hobbsee> hi jsgotangco 
<ajmitch> hi jsgotangco 
<Keybuk> http://www.nowcast.co.uk/lightning/index.htm
<Keybuk> jdub: ^
<Keybuk> btw, thanks for the quick headset test <g>
<jdub> Keybuk: ;)
<Keybuk> woo, so the thunderstorm we've been promised for 24 hours looks to be finally on its way!
<Keybuk> jdub: so, f-spot is cute then
<shaya> how does one file a bug against malone?
<Lathiat> shaya: http://launchpad.net/products/malone/+filebug
<Lathiat> at a guess
<shaya> yea
<shaya> figrued it out
<shaya> painful to search for bugs on malone :(
<shaya> unsure how to word the bug
<shaya> oh well
<shaya> I'll sleep on it
<crimsun> hmm, I'm attempting to dput alsa-utils_1.0.11-5ubuntu1_source.changes, and I'm receiving "Connection failed, aborting. Check your network (111, 'Connection refused')". Known issue?
<crimsun> (tried from two different hosts on different ISPs)
<Hobbsee> crimsun: i got that once, tried again, it went away.  not much help, i know
<crimsun> yeah, I'll try again in ~10 mins. 
<fabbione> morning
<crimsun> 'morning fabbione 
<Hobbsee> hi fabbione 
<Keybuk> http://www.boardsmag.com/screeningroom/commercials/2206/
<Keybuk> ^ I do like that advert ... pretty much every F1 race has it in one break
* Hobbsee waves to Keybuk 
<Keybuk> morning
<Hobbsee> afternoon :P
<jsgotangco> hello
<crimsun> Keybuk: hi, hate to bother you this early, but is the ftpd running on upload.u.c?
<Keybuk> crimsun: probably
<Keybuk> why?
<Keybuk> are you getting connection refused?
<crimsun> "Connection failed, aborting. Check your network (111, 'Connection refused')
<Keybuk> me too
<Keybuk> so that would be "no" then
<Keybuk> that requires admin intervention :-/
<crimsun> Keybuk: ok, thanks
<Keybuk> hmm
<Keybuk> maybe it doesn't
<Keybuk> this will be ugly, but
<Keybuk> ok, we should have an FTP daemon again
<crimsun> indeed, thanks again
<dholbach> good morning
<Hobbsee> hey dholbach!
<fabbione> morning dholbach 
<dholbach> heya Hobbsee, fabbione!
<jsgotangco> hi dholbach!
<pitti> Good morning
<Hobbsee> hi pitti!
<pitti> hi Hobbsee 
<\sh> moins
<Hobbsee> hi \sh 
<pitti> \sh: Guten Morgen!
<\sh> pitti: how's the weather at your place? still raining or still hot like hell? ;)
<sivan> morning all
<pitti> \sh: the latter
<pitti> hi sivan
<sivan> hey pitti 
<\sh> moins sivan
<sivan> MoinMoin \sh :)
<\sh> sivan: I heard some rumours from raphink that he had lunch with your roomate? :)
<sivan> \sh: hahah, amazing, isn't it? :-)
<sivan> speaking of the devil :p
<Hobbsee> hehe
<sivan> morning raphink
* Hobbsee wonders if sivan and sivang are the same person on two machines, or different.
<\sh> sivan: yeah...ubuntu is everywhere :)
<raphink> hi sivan :)
<raphink> :)
<raphink> sivan : just saw shahar 5 mins ago, he just arrived ;)
<sivan> raphink: hehe
* sivan is also sivang on the muse. However muse doesn't respond to SSH again :-(
<sivan> Riddell, sladen : ^^
<Keybuk> pitti: so, is Debian undergoing a C++ transition?
<Keybuk> or has it recently completed one?
<dholbach> Keybuk: I think they fixed most of the c++ packages to build with g++ 4.1
<Keybuk> they've dropped the "c2a" from most of the package names
<dholbach> afaik you can only do that, if the soname changes in the meantime
<dholbach> i don't know if g++ 4.1 changes the abi
<Keybuk> they haven't changed the soname
<Mithrandir> Keybuk: uh, example package?
<Keybuk> libalps-light1c2a -> libalps-light1
<dholbach> doko will know for sure
<dholbach> i thought gcc 4.1 was only "pickier"
<pitti> Keybuk: I don't know, but 4.1 doesn't change the ABI
<Mithrandir> Keybuk: it might never have had a non c2a package in the archive in which it's fine to drop the c2a.
<Keybuk> just wondered
<Keybuk> after UVF, we'll probably have to do a cruft shakedown and rebuild
<fabbione> i assume it is known that .17-4 kernel postinstall is broken...
<Keybuk> nope?
<fabbione> hmmm
<\sh> Keybuk: oh fck....
<fabbione> it didn't do a bunch of things... like the initrd, update grub menu and depmod
<Keybuk> \sh: what did you break?
<\sh> Keybuk: alps-light1 and c2a missing...I have to set conflicts/replaces I think
<Keybuk> \sh: hmm?
<\sh> Keybuk: if we had c2a in the name, and debian not...then I have to, no?
<\sh> Keybuk: and in dapper we had c2a in the name
<seb128> The following packages have unmet dependencies:
<seb128>   libpango1.0-dev: Depends: libxft-dev but it is not going to be installed
<seb128> hum
<Keybuk> \sh: yes.
<\sh> fixing
<seb128> hum
<seb128> "x11-common: Conflicts: libxft-dev (<= 2.1.8.2-5) but 2.1.8.2-0ubuntu2 is to be installed."
<seb128> is somebody working on fixing x11-common? :)
<\sh> alps-light1 fixed
* Keybuk hugs Soyuz
<Keybuk> you seem much happier today *pats it*
<\sh> Keybuk: btw...thx for the syncs :)
<Keybuk>   libgtk2.0-dev: Depends: libpango1.0-dev (>= 1.10.0-2) but it is not going to be installed
<Keybuk> seb128: ^ ?
<fabbione> seb128: it's going to take a few days to get all of X in shape
<seb128> Keybuk: 
<seb128> <seb128> "x11-common: Conflicts: libxft-dev (<= 2.1.8.2-5) but 2.1.8.2-0ubuntu2 is to be installed."
<seb128> <seb128> is somebody working on fixing x11-common? :)
<Keybuk> same thing?
<seb128> yeah
<seb128> libpango1.0-dev wants libxft-dev
<fabbione> <fabbione> seb128: it's going to take a few days to get all of X in shape <-
<seb128> which refuses to be installed
<seb128> fabbione: welcome to edgy :)
<fabbione> seb128: i didn't complain it was not working.. you are welcome to edgy :)
<seb128> which means we will have nothing remotly GNOMish building for a days then?
* seb128 goes to watch some TV then
<seb128> :p
<fabbione> seb128: it depends from you too.. 
<fabbione> rodrigo is doing his best, but there are still 100 or more pkgs...
<seb128> sure, I don't blame anybody
<fabbione> so perhaps getting some help to do the libs will unleash gnome too
<Keybuk> seb128: no, no TV ... MERGES
<seb128> Keybuk: I can't build packages atm :p
<fabbione> seb128: and libs are like any other libs around :)
<fabbione> seb128: yes you can.. X libs
<sivan> heh
<Keybuk> seb128: build them on dapper?
<Keybuk> seb128: or help out with the X merge?
<fabbione> Keybuk: the latter
<crimsun> fabbione: is there a roadmap or sequence? I'm happy to help out
<seb128> Keybuk: I was joking for the TV; don't worry I've enough to do on my list too :)
<fabbione> crimsun: yes.
<fabbione> crimsun: #ubuntu-x for X merges
<seb128> Keybuk: I'll keep doing GNOME merges and stack them for now
<\sh> seb128: you could help out with KDE 
* \sh hides
<seb128> sure
<seb128> let's break KDE
* dholbach hands seb128 something heavy to throw at \sh
<dholbach> \sh: he was angry at me for weeks, when i touched kde packages
<seb128> dholbach: I'm still :p
<dholbach> \sh: see
<Keybuk> oh, wow, &batch=3000 does bad things to both LP and Firefox
<\sh> dholbach: I'm sorry for that...but I think you had a good reason for touching evil KDE packages...:)
<dholbach> \sh: seb128 didn't think so
<seb128> I just think you have enough to do without trying to fix KDE yourself too :p
<\sh> seb128: be happy, france will be world soccer champion
<\sh> seb128: and let dholbach fix KDE ;)
<Keybuk> so
<Keybuk> how upset do you think LP will be if I do a mass give-back? :p
<fabbione> Keybuk: i was able to reproduce the kernel issue on ppc too. i will have to talk to Ben and zul
<Keybuk> "the kernel issue" ?
<pitti> hi ivoks
<ivoks> hi
<Hobbsee> fabbione: ajmitch reproduced it on his amd64 (i think) laptop earlier too
<ivoks> pitti: hplip for edgy and dapper shouldn't just get backported :)
<ivoks> pitti: that source should provide different binarys for them
<pitti> ivoks: I mean a manual backport, not the 'press the button and generate dapper-backports version'
<ivoks> :)
* hunger sighs. The new edgy kernel still oopses when trying to mount his root fs.
<sivan> hunger: is it on a laptop with SATA->PATA bridge ?
<Kamion> grr @ merges which revert stuff needed for new X
<Kamion> if your merge looks like it needs new X, just leave it alone and do something else, don't revert the bits and then have to put them back again later
<Mithrandir> Kamion: which one this time?
<Kamion> Mithrandir: jnethack - I'm catching up on edgy-changes
<Kamion> -*-Mutt: =ubuntu/edgy-changes [Msgs:1244 New:288 Post:11 Inc:49 6.0M] ---(threads/date)--------------------------------------------------------------------------------------------------------------------(81%)---
<sivan> Hobbsee: you have any idea if Riddell should come online soon?
<pitti> seb128: what's the issue with this never-ending 'symbol for evolution-2.6 could not be found'?
<seb128> pitti: what distro do you speak about, dapper?
<pitti> seb128: edgy
<seb128> edgy has evolution-2.8 afaik
<Hobbsee> sivan: none at all, i dont remember speaking to him last night either
<seb128> not 2.6
<seb128> pitti: ELACKOFCONTEXT
<pitti> seb128: well, I just did a daily dist-upgrade, and now my evo icon is broken
<pitti> seb128: (since a few days ago)
<pitti> and I repeatedly get this error message
<seb128> ah, panel icon?
<pitti> yes
<seb128> you must point to 2.6 where the icon is name 2.8 now
<dholbach> hum, why doesnt it point to /usr/bin/evolution?
<pitti> dholbach: the icon is the issue, not the link target
<pitti> oh, wait
<dholbach> (as upstream is so fond of changing the name every now and then, even if they're not installalble in parallel)
<pitti> if I click on it, it cannot execute 'evolution-2.6'
<pitti> seb128: since I didn't do anything special with that, this might become a general dapper->edgy upgrade problem
<seb128> pitti: is that a launchpad you created or the top panel stock one?
<pitti> seb128: hm, if it doesn't happen for other people, maybe I removed it in the past and dragged it again to the panel from the menu
* pitti removes it and re-drags from the menu
<pitti> seb128: yes, now it points to evolution-2.8 and has the 2.8 icon
<seb128> pitti: might me, we still have time before edgy, I'm sure somebody else will hit the issue if that's an upgrade issue :)
<pitti> yep, we'll do upgrade tests anyway
<seb128> pitti: BTW is there any language-pack update planned? due to the translation domain change evolution is 0% translated again...
* sivan dist-upgrades
<pitti> seb128: I'd like to, but carlos needs to enable edgy tarballs
<pitti> seb128: so, next Monday he should be back from vac, then I hope we can do that
<pitti> he promised me to look into it soon
<seb128> is there a trick to tell to the buildd to not stip translations for that package? :)
<seb128> strip
<pitti> well, yes
<seb128> like some variable to set or something?
<pitti> seb128: NO_PKG_MANGLE=1
<pitti> seb128: it doesn't have time until next week?
<seb128> it has, but if I do another upload I'll set that
<seb128> it might weeks to carlos to get edgy on road
* pitti wonders if supporting multiple versions at the same time is really worth all that upgrade and translation breakage
<seb128> pitti: what do you mean?
<pitti> seb128: appending the -version suffix everywhere instead of just /usr/bin/evolution, evolution.png for the icon, and evolution.mo
<seb128> there is no translation breakage out of Ubuntu
<seb128> we are the only one to strip translations out like that
<sivan> did I ever mention http://fridge.ubuntu.com/files/no-pony-for-you.jpg is SO cruel? I just accidently clicked it while checking the time of the DevTeam meeting today, and it just made me hurt :)
<seb128> and they have a non-versionned binary and icon since previous cycle
<Keybuk> sivan: NOT YOURS
<sivan> Keybuk: mehhhhhhh ! But it's so cute!
<Kamion> \sh: merging X fonts before X is merged isn't the best idea in the world :P
<ogra> seb128, is it intentional that evo asks for a keyring password now on every start ? thats pretty annoying
<seb128> ogra: if it does that's probably because somebody hacked the feature
<ogra> hmm... thne he/she should make it work right :)
<seb128> ogra: feel free to bug upstream ;)
<seb128> ogra: (or to use dapper)
<\sh> Kamion: well, am I too fast again? ;)
<ogra> at lest is seems i can search my mailboxes without crashers again :)
<Zdra> ogra: I guess they uses gnome-keyring to manage password of your email account... I've the same thing here
<Zdra> so it asks your password to unlock the keyring and get your emails
<Kamion> \sh: yes
<Kamion> top tip, if it won't work yet, don't merge it
<\sh> Kamion: the xfonts worked yesterday evening ;)
<ogra> Zdra, which is very annoying ... 
<Kamion> \sh: at least some of the packages affected by 51881 were ones you merged
<ogra> whats even more annoying is that its not upgrade safe at all ... you loose all your passwords for all your accounts 
<\sh> Kamion: argl..ok
<fabbione> sh: if you are doing X please join #ubuntu-x and coordinate otherwise nothing is going to work
<Zdra> ogra: yes that's a problem... seb128: don't know if it's possible to import passwords from evo's config to gnome keyring in the upgrade ?
<Zdra> that's much a evo bug which should import him self
<seb128> no idea
<TheMuso> c
<doko> hmm, looks like dist-upgrading via dselect is broken ...
<seb128> doko: only by dselect?
<doko> Reading package lists... Done
<doko> Building dependency tree
<doko> Reading state information... Done
<doko> and hangs with 100% CPU time
<doko> seb128: apt-get dist-upgrade works
<seb128> weird
<doko> seb128: can you reproduce it?
<seb128> doko: right, does the same on my box
<doko> ok, submitting a report ...
<doko> mvo: bug 52074
<Ubugtu> Malone bug 52074 in apt "apt-get -f dselect-upgrade hangs with 100% CPU time" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52074
<dholbach> doko: mvo is on holidays
<doko> dholbach: I'll use apt-get dist-upgrade in the mean time
<tseng> you want apt-get upgrade atm :)
<tseng> dist-upgrade will remove half your system
<tseng> ez gtk boog
<dholbach> tseng: not really
<tseng> :D
* dholbach larts tseng with passion
* tseng hugs dholbach 
<dholbach> . o O { he loves it }
<ogra> haha
<tseng> Mithrandir: ping
<Mithrandir> tseng: hello
<tseng> Mithrandir: hey
<tseng> can I do a drop-ubuntu sync on openbox?
<tseng> build-deps are in line in Debian now, i dont see any other glaring changes we need
<Mithrandir> tseng: yeah, should work fine, apart from it might very well end up ftbfs-ing due to X being all over the place atm, but I guess we'll solve that by a mass-give-back of doom.
<tseng> right, will file the bug
<tseng> thanks.
<heno> Keybuk: can you use your ubuntu-driver super powers to set a priority on https://launchpad.net/distros/ubuntu/+spec/sok ?
<heno> Keybuk: Medium will do nicely :)
<Keybuk> heno: done
<heno> Keybuk: thanks!
<heno> Keybuk, Mithrandir, fabbione: would any of you care to review sok and xubuntu-accessibility ?
<heno> these should really be on the edgy track
<fabbione> heno: if it can wait 30 minutes i can take one of them
<fabbione> i am in the need of food
<Keybuk> heno: I don't really have the time right now I'm afraid
<heno> fabbione: great, thanks
<Keybuk> I have a small stack of specs already, and I need to sleep at some point before the meeting
<heno> Keybuk: np, sleep well :)
<heno> iwj, Kinnison: either of you have time for a spec review today?
* sivan notes he will also need some more review time for 2 specs today
<pygi> sivang, poke? :)
<sivan> pygi: hi
<pygi> sivan, what's the review status ? :)
<sivan> pygi: there's more stuff to fix, take a loot at both of the specs mdz and Keybuk have comments inline
<pygi> ok, looking 
<pygi> system backup is out of edgy scope
<pygi> we agreed on edgy+1 for that
<sivan> pygi: Well, mvo noted it is something very easy to do, and what's proposed there is a very simple system backup, read on :)
<jsgotangco> yeah
<sivan> pygi: it's far from being something complete or comprehensive. Just another step to make it easier to return a bit more closer to a previous system state.
<pygi> sivan, ah :P
<Kamion> fabbione: do you have time to review https://launchpad.net/distros/ubuntu/+spec/ubuntu-server-tasks ?
<sivan> hmm, I wish mvo was here..
<pygi> the UI for the clean tool is libnotify baloon :P
<Keybuk> pygi: you can't click anything inside one of those, or offer choices
<sivan> pygi: not only, the kernel clean up (the highest priority use case for it) will need some sort of a treeview/list so users can choose to keep more then only the currently running and the previous kenrel.
<pygi> Keybuk, indeed ^_^ When you click the baloon, the UI will appear :P
<Keybuk> pygi: right... that's the UI that isn't specified
<pygi> Kamion, isn't that something like Ubuntu Instant Server?
<pygi> Keybuk, agreed ^-^
<Kamion> pygi: never heard of it
<pygi> Kamion, hm, sec,if it still exists
<iwj> heno: Should be able to, yes.
<sivan> Keybuk: I think there's some tests in the libnotify package that offer more then just one callback, as in choices
<Kamion> pygi: apparently does; Adam never mentioned it so I assume he hadn't heard of it either
<heno> iwj: great, thanks :)
<iwj> Which one ?
<Kamion> pygi: this should obsolete the first half of ubuntu-instant-server-manager I guess; we already have all the mechanism mapped out
<heno> iwj: you can choose :)  sok is much longer
<Kamion> so I'm not too interested in going back to the start again
<pygi> Kamion, no worries, seems like u-i-s is mostly removed anyway :-
<heno> xubuntu-accessibility is almost informational in nature
<Kamion> pygi: shame about the duplication, but there you go
<fabbione> Kamion: yer
<fabbione> Kamion: yeps looking..
<pygi> Kamion, partly my fault probably
<iwj> heno: I'll take sok for now.
<fabbione> heno: which one do you need first?
<sivan> pygi: are you going to work on the specs? I intend to work on them in about 15 minutes, if you have any additoins or suggestion add inline like keybuk did and I'll merge stuff
<heno> fabbione: well, iwj is doing sok now, so if you could do xubuntu-a sometime today, that would be great
<Kamion> pygi: it didn't help that the spec was off on a random product rather than on /distros/ubuntu
<pygi> Kamion,yes, I am aware of that
<fabbione> heno: sure.. i will do it in few mintues
<pygi> sivan, will do, just not right now
<sivan> Riddelll: around? are you able to log into muse ?
<sivan> pygi: okay, then please let me know before as I may be editing it.
<pygi> sivan, no worries :)
<Riddelll> sivan: no, ssh has died
<sivang> Riddelll: I see, well, I guess you're onto it already or should we wait for sladen ? :)
<Riddelll> sivang: he's awake now at least
<fabbione> Kamion: -> Pending Approval.
<fabbione> heno: checking xubuntu-a right now
<Seveas> Kamion, is the CC meeting scheduled yet?
<iwj> heno: Looks pretty good.  Just a couple of comments, see Review Comments in the wiki page.
<heno> iwj: great, thanks
<fabbione> heno: i think we need to work a bit in xubuntu-a and add a few more details
<Kamion> fabbione: thanks
<heno> fabbione: should it be made an informational spec you think?
<fabbione> heno: basically you need to think in a position like mine. I know absolutely nothing about accessibility and xubuntu. reading the spec i should be able to implement it.
<heno> ok
<heno> I'll look again from that perspective
<fabbione> heno: for example: package foo, move foo from universe to main, link xubuntu-terminal to library bar provided by foo to enable Sticky Keys (or whatever)
<Kamion> Seveas: is now, although mako never replied to my mail
<fabbione> heno: just as general guide line..
<heno> I see
<Seveas> Kamion, gracias!
<heno> sounds good
<fabbione> heno: same goes for the LiveCD. I don't know what i should do if i was assigned this spec..
<Kamion> Seveas: do you remember who does the meeting logs?
<fabbione> heno: perfect.. just ping me when you are ready for the next review
<Seveas> I *think* robitaille
<Kamion> apparently they're out of date
<Seveas> ah
<heno> fabbione: you mean https://launchpad.net/distros/ubuntu/+spec/livecd-access ?
<iwj> heno: ping me again here when you've updated it and I'll re-review.
<Seveas> maybe I should rig up ubugtu to do the logs (automation++)
<fabbione> heno: no i mean xubuntu-a.
<fabbione> heno: "Scope: Create a Live CD configuration based on the Ubuntu one."
<heno> fabbione: right. I'll explain it better there
<fabbione> perfect :)
<heno> https://launchpad.net/distros/ubuntu/+spec/livecd-access has the explanation, so I can link to that
<heno> iwj: thanks. I'll need some help finding the right terms for the keystroke-sending bit
<heno> Mithrandir: ping ^
<heno> The keystrokes are sent 'directly to X'
<heno> is probably too vague
<Mithrandir> heno: hmm?
<heno> Mithrandir: in SOK we feed keystrokes directly in through the X infrastructure
<heno> what is a good way to express that?
<heno> we don't use AT-SPI or anything
<Mithrandir> heno: you're probably synthesizing input events using the Record X server extension.
<heno> Mithrandir: very likely. What should I look for in the source to be sure? (python)
<Mithrandir> heno: no idea, I've never used the extension myself.
<heno> Mithrandir: ok, thanks I'll look at the code and old emails, thanks
<TheMuso> heno: The xtst extension is used AFAIK.
<heno> TheMuso: thanks :)
<iwj> heno: You might be using XSendEvent, which is an even older thing.
<heno> iwj: could be. I'll ask my student for details when he turns up. It's coded and working nicely already though :)
<fabbione> who knows quilt enough to tell me what's the canonical way to add a patch to it?
<lifeless> refresh I think
<lifeless> or something like that 
<Kamion> 'quilt new' surely
<Kamion> ?
<heno> iwj: ok, I've saved my changes
<iwj> Urr.  OK.  Well, I'll send it up for approval.
<iwj> But first I'll edit your answers into the body of the text.
<ogra> would someone mind looking at the student-control-panel-completion spec ? fabbione already looked and had some critics on the remote desktop section which i rewrote
<iwj> heno: Is that 90 developer days really right ?
<iwj> ogra: From a review PoV ?  Sure.
<ogra> iwj, thanks :)
<heno> iwj: it's a SoC project, with a student working on it full time. Those are his days, not ours
<iwj> Ah.
<heno> If I were to list my days, I might make it 15
<iwj> Still, 90 working days is 18 weeks (at least).
<heno> iwj: right he started on it before dapper was out though
<iwj> Aha.
<heno> We have made good progress, so I'm happy to set it to 50 now
<iwj> ogra: I take it you don't mind if I edit it for grammar ?
<ogra> totally not, go ahead :)
<heno> you can grab a working version of SOK here: https://wiki.ubuntu.com/Accessibility/Projects/SOK
<iwj> ogra: Is comma-splice allowed in German ?
<iwj> Because it's not in formal English.
<ogra> well, its mostly german comma rules with english words there ... might all be wrong :P
<ogra> sorry for that
<Kamion> Toadstool:  -> http://librarian.launchpad.net/3282392/y1QkQEkEU4T7Yb3BgaUnAvCvATC.txt (GPG verification of mini-dinstall_0.6.21ubuntu1_source.changes failed: No public key)
<Toadstool> uh?
<Kamion> Toadstool: oh, you aren't in ubuntu-dev, you can't upload to universe
<Kamion> ... but mini-dinstall 0.6.21ubuntu1 is already in dapper/universe. what's going on?
<Toadstool> Kamion: never tried to upload mini-dinstall as far as i remember
<Kamion> is somebody automatically reuploading crap from revu? I see a number of failures like that
<Toadstool> or anything else in universe
<Kamion> yeah, sorry, I saw your name but forgot to check the date
<Toadstool> ah ok, no problem :)
<Toadstool> I thought I did something wrong :)
<iwj> This wiki is so slow atm ...
<ogra> iwj, urgh, all other sections were already approved ...
<ogra> oh, you only edited the remote desktop stuff ... sorry ... it became so big :)
<ogra> iwj, recommends can install stuff inside a unspecified chroot if i install soemthing in the host system ?
<ogra> (thats really news to me)
<iwj> ogra: Oh, I see, like that.
<iwj> Err, you could do that in the postinst.
<iwj> Although it's a bit scary.
<iwj> `all other sections were already approved'> I see.  Well, no, I don't see.
<ogra> iwj, running: chroot /opt/ltsp/$(dpkg --print-architecture) apt-get install x11vnc from postinst would be allowed ?
<ogra> wow, i wouldnt have guessed ...
<iwj> I don't see why it wouldn't work.
<iwj> How do you normally set up this chroot ?
<iwj> You are going to get hideously confused if installing x11vnc does anything unexpected (worst case: asks debconf questions).
<iwj> You might have to untangle some of the debconf env vars to stop it from trying to talk to the outside debconf db.
<ogra> well, the chroot might not exist if you run it on debian systems ... but a simple if clause could check that
<iwj> No, I mean, how does the chroot normally get there ?
<iwj> Whether or not it's reasonable to mess with it like that depends on how much you own it.
<Kamion> if you actually want to pass through debconf questions it asks then that's massive fiddliness
<ogra> and setting depconf to noninteractive at the top of the postinst for the chroot and setting it back at the end should work as well
<Kamion> ogra: you also need to unset DEBIAN_HAS_FRONTEND at least to make it start up a new debconf frontend
<Kamion> if you think it's straightforward then you've never done it before
<ogra> iwj, the chroot exists either because you installed edubuntu or because you ran ltsp-build-client in ubuntu
<iwj> Right, so if you do that, it makes the chroot for you with debootstrap or some such ?
<ogra> Kamion, i didnt plan to do that at all from the postinst ... i was wondering why iwj suggested that 
<iwj> Eg, as part of the edubuntu install setup ?
<ogra> yep
<ogra> in edubuntu the installer runs the chroot setup script
<Kamion> ogra: it doesn't sound like a terribly good idea to do it from the postinst, I agree
<iwj> Well, then your edubuntu/ltsp stuff definitely owns it and I think you're probably entitled to mess with it.
<ogra> in ubuntu you have to do it after you installed ltsp-server manually
<iwj> Hmm.  I'd still be cautious.
<Mithrandir> iwj: thanks for the new meeting times, they look much better.
<ogra> thats why i want a gui option that just installs it 
<ogra> Mithrandir++
<iwj> Mithrandir: Oh, good.  No-one has said anything at all about them on email which I suppose means everyone agrees :-).
<ogra> iwj, they are great :)
<Kamion> meeting times> I agree. Will be interested to see how it works out in winter time (I suppose we'll have a new schedule).
<Mithrandir> iwj: mdz seemed happy enough, but I didn't see the point of mailing everybody to say I'm happy.
<iwj> ogra: GUI option> Fine, that's a good answer.  Just write it into the wiki page.
<ogra> its in there :)
<iwj> new schedule> Indeed, we will.
<iwj> Mithrandir: :-).
<ogra> A "first start popup window" will be added to the GUI, with a checkbox "Dont show this window again" and a button "Install remote desktop access".
<ogra> :)
<ogra> i'll rewtite it a bit :)
<iwj> Right.  But point out the thing about a chroot.
<iwj> I missed that when I was reading it.
<ogra> yep
<iwj> I'm sure it's clear if you already understand all of this stuff.
<ogra> well: Choosing the latter option will execute a script /usr/share/student-control-panel/install-client-vnc.sh which will run  apt-get install x11vnc  in the client chroot with the above described option preseeded.
<iwj> I thought the alternative you were dismissing was to run apt-get install something _not_ in a chroot from a postinst which would an "unusual" approach.
<ogra> i thought "client chroot" would suffice there ... i'll re-formulate it
<iwj> Sorry, maybe I just didn't read it carefully enough.
<iwj> I haven't had any lunch yet :-).
<ogra> yeah, that'd be silly, i'd just add a dependency :)
<doko> pitti, BenC: http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00206.html
<ogra> iwj, no its fine, even hungry people should understand my specs ;)
<Hobbsee> ogra: just make sure you talk about lots of food in the spec :P
<ogra> haha
<iwj> So, yes, lunch.
<Hobbsee> :P
<Seveas> The have-lunch-before-reading-specs-spec
<mdke> Znarl: around?
<zul> hey
<doko> Keybuk, Kamion: anyone of you wants to review edgyplusone-toolchain-roadmap or python2.5?
<azeem> whoa, I thought that was a package name for a second
<Kamion> doko: I'll do python2.5
<Kamion> doko: either fill out the Scope section or delete it
<Kamion> don't leave empty sections
<enrico> Is there some free LPI ubuntu training material available?
<ogra> iwj, "Which actual protocol will you be using ?" there is only *one* protocol dbus speaks ... if oyu add a listener for student control panel that one will be used ... what exactly do you mean with the comment ? 
<enrico> sorry, wrong channel
<enrico> was there a decision to migrate to smart for edgy?  I just heard people mentioning it but I didn't remembering hearing official decisions
<enrico> (but maybe it's in one of the new specs I haven't looked at)
<neuralis> enrico: no.
<seb128> enrico: there is plan to play with smart but not to use it by default (yet?)
<enrico> ok, thanks.  Maybe I can correct that statement
<heno> Mithrandir: with live-cd-stacked-filesystems will be be able to have different packages installed for different boot options on the same Live CD? So a xubuntu-access package could be installed only if F5-... were selected?
<iwj> ogra: You give a reference to the dbus spec.  The dbus spec says any SASL authentication mechanism is supported and also offers one of its own.
<Mithrandir> heno: conceivably, yes, but it's a stack, not a heap so you need to choose carefully.
<ajmitch> any reviewers available to re-check network-authentication?
<iwj> And you just say `dbus does it for us' but which authentication mechanism with which credentials ?
<heno> Mithrandir: ok, thanks
<ogra> iwj, the default one we use everyawhere indeed (no sasl, i'll add a note)
<iwj> You mean DBUS_COOKIE_SHA_1 ?
<ogra> iwj, i expect someone who wants to implement that dbus part to know about dbus, i dont think that needs further specification
<iwj> So using which private key ?
<ogra> no keys
<ogra> you have a listener in the users session (like all other apps have) if thats connected, it blocks
<ogra> s/other apps/other dbus based apps/
<iwj> Listen to me: you're proposing to allow the LTSP admin tool to run commands as users.  Ie, to give them full control of the user accounts.  Well, fair enough, you may say.
<iwj> But you haven't explained how you will prevent other people from (ab)using this mechanism.
<iwj> That is absolutely critical for this feature, surely ?
<ogra> by a dbus connection thats established
<ogra> if its established it blocks ...
<iwj> Maybe we're having a language barrier here.
<iwj> Because I can't understand how whether it blocks or not is at all relevant.
<iwj> Did you read the dbus spec authentication section, that you link to from the spec ?
<ogra> i read the dbus-specification, yes ... 
<ogra> the auth section is only a subpart
<seb128> I'm away for some hours, I've spoke with mdz about it yesterday and will catch up later today, bbl
<iwj> The auth section is obviously what we're talking about in this context.
<iwj> So far your spec just says `DBUS has the security built in to not accept any messages except from SCP (see [WWW]  http://dbus.freedesktop.org/doc/dbus-specification.html#auth-protocol for tech details)' which is not enough detail I'm afraid.
<ogra> (/me is near to just enable xdmcp in edubuntu and just use xhost as everyone else does)
<iwj> If you propose not to have any security at all then write that in the spec and we'll see whether it gets approved, eh ?
<ogra> i'll take out the auth part if that bothers you and just say we'll do it via dbus
<iwj> Taking stuff out is not the answer.
<ogra> with the same security constarints every other dbus aware app has
<pitti> doko: oh, that sounds nice; thanks for the link
<iwj> We're going round in circles here.  Bottom line: I'm not happy with it as it stands; I've tried to explain to you what I think needs to be in the spec, and apparently failed.  I'm going to go and calm down a bit and then I'm going to send an email about it.
<ogra> ok
* ogra wasnt planning to write up how dbus connections work ...
* pitti guesses it's okay to grab some merges from Charles Majola
<Zdra>  sudo apt-get build-dep nautilus
<Zdra> Reading package lists... Done
<Zdra> Building dependency tree
<Zdra> Reading state information... Done
<Zdra> E: Build-dependencies for nautilus could not be satisfied.
<Zdra> does it mean something is broken ? or mirror not up-to-date ?
<ogra> dapper ? breezy ? hoary ?
<Zdra> edgy :)
<tseng> alot of things in edgy are broken atm
<ogra> pfft
<tseng> but please do not paste big blocks here
<ogra> what do you expect ? we dont even have a complete X 
<ogra> ;)
<jsgotangco> heh
<Zdra> ok so it is normal... (sorry I should use pastbin)
<jsgotangco> i can't even boot my box!
* Zdra have some patches to cook that's why I upgraded to edgy :)
<ogra> Zdra, i'm not even sure gtk is there yet ... 
<Hobbsee> jsgotangco: however did you manage that?
<Zdra> ogra: yes 2.10 is running just fine here :)
<jsgotangco> Hobbsee: i'll do it later
<Kamion> Zdra: we're in the middle of merging Debian's X into edgy. Breakage is expected.
* Hobbsee stops merging and goes back to reading the newspaper then.  guess i'll have to wait till the X merge is finished to be able to merge again.
<Hobbsee> Kamion: any ETA on the end of the merging?
<ogra> Hobbsee, nah ... only if you merge X stuff or things with direct X deps
<fabbione> Hobbsee: not really.. we are dealing with LP being a bit slow today
<fabbione> Hobbsee: because most of X is ok .. and it should be able to install
<Hobbsee> ogra: kdelibs4-dev depends on libxft-dev.  and that's screwed.  and most kde based things have a b-d on kdelibs4-dev.
<Kamion> not so much LP being slow as an archive inconsistency problem
<Mithrandir> Hobbsee: apparently the publisher part of launchpad decided to blow up so until that's fixed, there's not much we can do.
<sivang> does anybody have good ideas for HomeUserBackup's files file extension for a mime type registring? Please consider that in the future it might be use for more then just home user folder's backups..
<Zdra> why merging X from debian if we'll upgrade to 7.1 after that ? :)
<Hobbsee> Mithrandir: oh what fun, hehe.  blowing things up is great!
<Kamion> Zdra: (a) syncing the packaging first makes our lives much easier
<Mithrandir> Hobbsee: not so much when it leads to not being able to do ones work.
<Hobbsee> Mithrandir: that's true
<ogra> Hobbsee, libxft-dev was uploaded already so if the LP prob is solved it should be available
<Kamion> Zdra: (b) Debian have at least part of 7.1 in experimental so we may well be able to sync that
<fabbione> Zdra: "we"? are you helping with the merge?
<Hobbsee> ogra: any idea on what version?
<ogra> Hobbsee, no, but surely the most recennt debian one 
<Hobbsee> ogra: right, good, i'll just wait for that then.
* Hobbsee looks for something else that's still possible to merge.
<Zdra> fabbione: no, no... I just don't know how to translate impersonal "on" from french :p
<ogra> Hobbsee, X :)
<Hobbsee> ogra: you *really* want me to run away screaming?  :P
* Hobbsee could install edgy instead.
<ogra> Hobbsee, join #ubuntu-x so you can at least lurk :)
<Hobbsee> ogra: hehe at the topic!
<Kamion> the topic is serious; we have a serious time shortage and would appreciate minimal distractions in -x
<Hobbsee> ogra: if it's simplish, i can probably help you out.  but if it's complicated, then there's probably no point in trying to explain it, and taking time to do it as a result, instead of just getting on to the job at hand.
<Hobbsee> Kamion: sure
<sivang> pitti: do you know how complex would it be to have support for detecting HomeUserBackup CDs and fire up a program when such "Backup CD" is detected?
<pitti> sivang: it would require a hook in update-notifier or gnome-volume-manager
<sivang> pitti: what's invloved to actually recognize a CD or another device to contain CD of type 'X' ? do we have special checks in g-v-m's hooks to positively recognize it's an ubuntu install cd? like certain files or so?
* sivang pokes onside g-v-m source package
<pitti> sivang: Ubuntu CDs are recognized by update-notifier
<pitti> it checks for a special file and its contents
<tseng> it would make more sense to me to have an autorun file on the cd
<pitti> tseng: we disable autorun by default
<sivang> pitti: so update notifier checks that file each time it receives an insert CD event from hal?
<pitti> yep
<sivang> ah, so I'd probably use g-v-m to not have to depend on another daemon I will have to create for that.
<sivang> althought if a daemon is created to count days since user's last backup operation I can add this there..
<sivang> pitti: do we have any other stuff that's using  g-v-m hook to do something when something happens?
<sivang> (I'd like to try look at an example to get an idea for it)
<pitti> sivang: gvm doesn't provide any hooks
<pitti> you have to hardcode it into the code
<sivang> bah 
<sivang> so I need a daemon... or attempt to use hermes if it's planned to have it in for edgy..
* sivang moves another item to future work in home-user-backup.
<ajmitch> Kamion: if you have time for a quick review of network-authentication, it'd be much appreciated 
<Kamion> ajmitch: have to go out for a bit now, but if nobody's picked it up when I'm back (an hour or so), I will
<ajmitch> iirc it was unapproved just before paris 
<ajmitch> thanks
<sivang> yay, my muse is back :)
<bddebian> Hello
<heno> fabbione: when you get a chance, I've made changes to https://wiki.ubuntu.com/Accessibility/Specs/XubuntuAccessibility based on your feedback
<fabbione> heno: looking now
<bddebian> Heya fabbione
<fabbione> hi bddebian 
<bddebian> fabbione: Done holding rodarvus's hand yet? ;-P
<Riddell> mdz: kubuntu-system-settings-usability is ready for another review
<Riddell> as is kubuntu-edgy-package-manager
<Kamion> slomo: mono FTBFS on powerpc again; did you drop that workaround patch?
<slomo> Kamion: no this is a new problem unfortunately
<Riddell> and if any reviewer wants to take over from keybuk on kde-kiosk-profiles that would be great
<slomo> Kamion: we have a better patch now that worked some time
<slomo> Kamion: and then mono failed completely on ppc so i guess it's a change outside of mono that caused this breakage now
<Kamion> d00m
<slomo> Kamion: it's not ssp at least, pitti tested this already. and the new patch for the old problem is not broken because we get the same segfault with the old patch as with the new patch
<slomo> no idea what we can do about it... i asked the guy who fixed the old problem to reproduce it on his machine (on debian)... if he can't i'm lost ;)
<pitti> zul, BenC: ping
<slomo> Kamion: FYI, last time the problem was that new memory for code was allocated via malloc() on another cpu and the memory was not marked executable
<zul> pitti: ping
<zul> er...pong
<doko> Mithrandir: could you review edgyplusone-toolchain-roadmap?
<BenC> pitti: pong
<jbailey> Is there a reviewer handy for https://launchpad.net/distros/ubuntu/+spec/edgyplusone-toolchain-roadmap ?  I did a bunch of the editting on it, so I'm not longer comfortable passing it past review stage myself.
<Kamion> Riddell: re bug 52104, you have a koffice-l10n in dapper too (as well as koffice-i18n). Are you still sure you want to sync?
<Ubugtu> Malone bug 52104 in koffice-i18n "Please sync koffice-l10n from unstable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52104
<Kamion> mdz: can you look over ubuntu-server-tasks?
<Riddell> Kamion: yes please sync
<Kamion> Riddell: for kubuntu-file-transfer-dialogue, how does the user configure whether to show/hide finished downloads if they've already chosen to hide them and they have no downloads in progress?
<Kamion> "The option to show and hide finished downloads is accessible via the system tray icon's right context menu."
<Riddell> Kamion: and can you remove koffice-i18n?
<Riddell> Kamion: right click on systray menu
<Kamion> Riddell: but you said the icon would disappear if there were no downloads in progress and you'd configured it to hide, so how do you get to that?
<Kamion> koffice-i18n-srlatn | 1.4.1-0ubuntu1 | edgy/universe | all
<Kamion> koffice-i18n-zhcngb2312 | 1.4.1-0ubuntu1 | edgy/universe | all
<Kamion> koffice-i18n-zu | 1.4.1-0ubuntu1 | edgy/universe | all
<Kamion> ^-- binaries still shipped by koffice-i18n, for the record
<Kamion> ok to remove those too?
<pygi> sivang, poke?
<Riddell> Kamion: yes, remove them
<Kamion> done
<Riddell> Kamion: once you've chosen to hide finished downloads you don't get to show them again
<Kamion> that seems like a design bug
<Riddell> you don't get to see copied files curently once they've finished downloaded
<Riddell> s/ed/ing/
<doko> reviewers: could you still do two reviews, one informational: edgy-openoffice.org and ooo-langpacks?
<Kamion> Riddell: right but you also don't get to turn it back to "show all downloads from here on"
<Kamion> without starting a download long enough for you to find the icon and right-click on it
<mdz> Kamion: ok
<Riddell> Kamion: you can configure this in Konqueror's Settings, leave a note on the wiki and I'll clarify that
<Kamion> Riddell: ok, that's what I wanted to hear :)
<mdz> Kamion: "Each task will be implemented as a seed, from which the server seed will inherit"
<mdz> Kamion: do I misunderstand or is that backwards?
<mdz> I'd assume the task seeds should inherit from the server seed, not vice versa
<mdz> oh, right, server is actually server-ship
<mdz> Kamion: can we rename that regardless of whether we create a true server seed?
<Kamion> sure, I was talking about the current server seed
<Kamion> (renaming's out of scope for that spec)
<Kamion> I can add a note to say that the server seed should inherit from them if they're to go on the CD
<Kamion> (done)
<slomo> Kamion: nice, i can reproduce this one on my ibook... so it's not only ppc64 related this time
<mdz> Kamion: no metapackages?
<Kamion> mdz: I'm not hugely keen on creating another n metapackages
<Kamion> at some point, apt is just going to have to understand tasks
<Kamion> or smart
<Kamion> I think the upgrade concern here is much less than for ubuntu-desktop - the tasks won't change often, and once somebody's set a server up they're unlikely to want to radically change the set of packages implementing their services anyway
<Kamion> mdz: thanks
<iwj> doko: Do you have reviewers for those yet ?
<iwj> doko: Err, EdgyOpenOffice still looks like a braindump to me.
<iwj> doko: Am I looking at the wrong page ?
<iwj> doko: OpenOfficeLangPacks still seems a bit sketchy.  There are empty sections which you should put some stuff in, or rename, or delete, or something.
<Kamion> heno: could you note the DVD content requirement from EdgyContent somewhere in LargerLivefs, please?
<iwj> doko: re OpenOfficeLangPacks> It would be nice if you could perhaps explain the build flow process before-and-after.
<Kamion> heno: EdgyContent seems to have quite a few outstanding issues; which of those need to be addressed before approval?
<iwj> doko: Do you want me to put these comments somewhere in the page and set it back to Drafting, or are you going to pick it up right now ?
<Kamion> heno: (for the record I don't think a separate content repository is a good idea; it requires too much support in the installer, packaging infrastructure, etc. before random users actually stand a chance of finding it)
<bddebian> is #!/bin/sh -e  valid for pre-post-etc inst files?  Or should it be #!/bin/bash?
<pitti> bddebian: sh -e is the prefered shell
<pitti> bddebian: as long as the script is POSIX clean and works with dash, you should use sh
<bddebian> pitti: OK, so what if they use bashisms in the script then?
<pitti> bddebian: then use /bin/bash, of course
<pitti> (-e)
<bddebian> Hmm.
<bddebian> Is there a POSIX let?
<bddebian> pitti: Thx btw :-)
<pitti> bddebian: let> no idea
<pitti> bddebian: use dash -n and a test run with dash
<bddebian> pitti: I already know it fails :-)  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367939
<Ubugtu> Debian bug 367939 in libapache-mod-mp3 "Subject: libapache-mod-mp3: bashizm in postinst" [Important,Open]  
<pitti> bddebian: oh, then just use bash and let it RIP
<iwj> doko: I have put my comments (as wittered above) into the wiki page and adjusted the spec status.
<iwj> doko: NB that I'm going to be going swimming at about 1800ish (in 19mins from now) and will probably not return until the meeting so you should get someone else to do the next iteration review.
<jdub> mako: ping
<heno> Kamion: yes, it's a shame we didn't get a chance to have a session on EdgyContent in Paris. I think I need to email or phone a few more people to get their views. I'll take your word for the problems with Outstanding Issue #2 though, and skip that notion
<heno> Kamion: By DVD requirement to you mean in disk space?
<heno> that depends on how much useful content we find by then
<heno> setting an upper limit is an idea though
<rodarvus> mdz, (asking you since you were the last reviewer for them) ltsp-login-and-session-handling and edubuntu-xfce-desktop are back on the review queue - do you think you'll be able to review them, or should I bug someone else?
<bddebian> rodarvus: Don't you have X work to do? ;-)
<rodarvus> bddebian, as everyone else, I have various tasks ongoing. (including X)
<pitti> rodarvus: lart him, lart him! :)
<bddebian> Gah, I was joking
<dholbach> bddebian: you do some X merges!
<pitti> bddebian: me too, saw the smiley? :)
* bddebian begins to realize that anyone dealing with X has no sense of humor ;-P
<doko> iwj: thanks
<bddebian> dholbach: I'd love to
<rodarvus> bddebian, don't worry :)
<doko> iwj: added a background section, left in your review comment. please remove it if you think it's understandable
<doko> iwj: I'm away for today, dholbach has my phone number if needed
<Kamion> heno: DVD requirement> at present larger-livefs only envisages adding language packs to the DVD filesystem; if extra content is to be added as well then that just needs to be noted as well, that's all
<wasabi_> There a good reason why linux-image-2.6.17-4 isn't builidng an initramfs?
<heno> Kamion: ok, did that. I added a speech synthesis language file use case as well ;)
<pitti> mdz: I have prepared and tested the new cupsys package for dapper-updates now; it also includes some fixes from upstream svn that are in the forthcoming 1.2.2; they are already in edgy, but I didn't send you the changelog for them; are these okay for you? http://paste.ubuntu-nl.org/17361 
<mdz> rodarvus: I'm pretty swamped right now and trying to focus on approvals + email
<mdz> rodarvus: better to have someone else review them and I'll verify when they get to approval
<rodarvus> mdz, ok, I'll do that - thanks!
<heno> Kamion: I've resolved the outstanding issues in EdgyContent
<rodarvus> Kamion, ping
<Riddell> Kamion: commend addressed on kubuntu-file-transfer-dialogue
<wasabi_> Nice. 2.6.17 panic on boot. Hmm.
<mdz> doko: is https://wiki.ubuntu.com/OpenOfficeL10n still relevant?
<jdub> (yay, in edgy i can remove tcl/tk!)
<tseng> jdub: blasphemy
<bddebian> heh
<mako> jdub: hola
<jdub> mako: hey - where is your voting software kept?
<mako> jdub: http://rubyvote.rubyforge.org/
<mako> jdub: i guess i never put that on my homepage
<jdub> mako: thanks!
<mako> jdub: not sure what you're looking for but it ships with a test script that should make it clear how to use it to compute a vote
<jdub> mako: do you know of (fully baked with ui) anonymous election systems that do preferential voting for named positions?
<jdub> forgot that yours was a lib :)
<pygi> sivang, poke? :)
<mako> jdub: when do you need it?
<mako> jdub: i have a prior date with someone to write a rails frontend to this in two days :)
<jdub> mako: novemberish ;)
<jdub> ha ha
<mako> what do you mean by anonymous?
<jdub> anonymous voting
<mako> our plan was to have it do either authentication over XML-RPC or against database built with a simple sort of username:password list
<mako> jdub: yeah, this would probably work for you
<jdub> (voters should be verified, but disassociated from their votes)
<mako> even to the administrator?
<mako> it's possible
<jdub> ideally
* mako nods
<mako> jdub: i'll blog it when it's done
<jdub> rad, thanks :)
<mako> jdub: i know spi has used a php based system but it pure condorcet and doesn't have a lot flexibility
<pitti> seb128: are you fine with me doing the xsane merge? (it has your name on it right now)
<pitti> seb128: I'd also take intltool from you
<pitti> seb128: ... and gamin, if you want
<pitti> seb128: since you seem to be offline, I guess it's safe for me to proceed until you return :)
<sivang> re
<Riddell> mdz: what do you mean by updated status for specifications?
<sivang> pygi: I'm also here :)
<pitti> hi ivoks 
<ivoks> hi
<pygi> sivang, specs status report?
<pitti> ivoks: cups 1.2.1 + some upstream svn fixes from 1.2.2. is prepared for dapper
<ivoks> pitti: nice
<pitti> ivoks: I'm just waiting for mdz's ack to the 1.2.2 fixes, then I'm ready to go
<mdz> Riddell: the implementation status
<ivoks> pitti: ok, i'll prepare gutenprint
<sivang> pygi: no yet, need to work on the other one to make sure it's approved, will talk to you later okay ?
<mdz> Riddell: i.e., which are started and which are not
<pitti> ivoks: that would rock
<pygi> sivang, sure :)
<ivoks> pitti: i allready have is somewhere, but i have to find it :)
<ivoks> s/is/it
<Riddell> mdz: right
<mdz> Riddell: I've asked for a "Not Started" status, but use Unknown meanwhile
<sivang> mdz: home-user-backup could be go to go now, I've merged all your comments, and it can go another round of review now, setting it up to review in LP.
<ivoks> pitti: is there something specialy new in 1.2.2 fixes?
<mdz> Burgwork: ubuntu-art-wacom-documentation (art?) is up for review, but it only links to an email which doesn't contain enough information to provide any feedback
<ivoks> pitti: something that i should watch out for?
<mdz> Burgwork: a proper spec should describe the work to be done (e.g., what tasks the documentation should allow the user to complete, links to the old documentation, etc.)
<Burgwork> mdz, just got that, will do\
<seb128> pitti: I was having diner, feel free to do them :)
<pitti> ivoks: no, just bug fixes (but by reading them I was reminded of some bugs we have)
<pitti> ivoks: http://paste.ubuntu-nl.org/17361 
<ivoks> pitti: thanks
<pitti> seb128: already at it :) (merged gamin, requested intltool sync, merging xsane now)
<pitti> seb128: I can take inkscape and libgnomeprint, too, but the rest of your's is too gnomeish for me
<jdub> hrm
<jdub> on edgy
<jdub> Failed to fetch http://people.ubuntu.com/~jdub/edgy/./Packages.gz  404 Not Found
<jdub> Packages.bz2 exists there though
<bddebian> Damn, all my merges are turning into syncs.. Sheesh :-)
<sladen> bddebian: that's good
<bddebian> Well and now I am getting reply's back from DD's that they are adding in my changes too so they can be synced next go round... :-)
<sladen> bddebian: this sounds like the grand scheme is starting to work
<sivang> does anybody know what would be the fastest call to get the modification time of a file? 
<seb128> pitti: I can do libgnomeprint*
<seb128> pitti: if you didn't start on it, other way feel free to do them
<bddebian> sladen: Well in Dapper I got a lot of "huh, what" responses from DDs :)
<mdz> jdub: works for me
<mdz> jdub: -rw-r--r-- 1 root root 2994 2006-07-06 12:13 /var/lib/apt/lists/people.ubuntu.com_%7ejdub_edgy_Packages
<mdz> jdub: deb http://people.ubuntu.com/~jdub/edgy /
<jdub> mdz: 0.6.44.2ubuntu?
<mdz> jdub: no, not yet
<mdz> that was uninstalling the world last I checked
<jdub> ahr :)
<jdub> btw, what's a sane way of using an ssh key with ssh:// ?
<elmo> how do I tell where a gnome app is hiding it's data?
<elmo> short of strace
<Zdra> seb128: If you have time I reported a crash for evolution: http://bugzilla.gnome.org/show_bug.cgi?id=346740
<mdz> jdub: ~root/.ssh/config I suppose
<elmo> specifically, ekiga and it's addressbook
<jdub> mdz: *boh* not entirely sane,but... ;)
<Ubugtu> Gnome bug 346740 in Mailer "crash when sending gpg signed email" [Critical,Unconfirmed]  
<jdub> elmo: .gnome2/ekiga maybe?
<sivang> hmm , Keybuk is not here ?
<mdz> jdub: works fine for me after upgrading as well
<elmo> jdub: nope
<mdz> jdub: there's nothing insane about .ssh/config
<dholbach> Zdra: upstream is aware of the problem and i suppose they're working on it
<seb128> Zdra: I've some hundreds bugs waiting, any reason I should give a priority to that one? :)
<jdub> mdz: yeah - thought you meant putting the keys there for a moment
<dholbach> elmo: isn't it using evolution's adress book?
<elmo> dholbach: I've no idea
<Zdra> seb128: no :p
<mdz> elmo: I rm -rf'd it once but can't remember where it was
<mdz> jdub: maybe your sources.list line is wrong
<dholbach> elmo: looking at its depends: libebook1.2-5 (>= 1.6.1), libedataserver1.2-7 - seems like it's evolution's
<jdub> mdz: apart from the / -> ./, no - and it was fine earlier today
<seb128> dholbach: what?
<mdz> elmo: ah, looks like it's all in gconf
<dholbach> elmo: which would be in .evolution/addressbook
<elmo> aiee!
<elmo> evolution is importing all my mail
<dholbach> seb128: ekiga's addressbook
<mdz> jdub: the . is unnecessary
<mdz> and confusing
<seb128> ah, it uses e-d-s afaik
<elmo> no no no no no, BAD evolution.  that 2GB is not yours
<elmo> and the cancel button only cancels each individual folder it's oimporting.  wah.
<bddebian> Heya Keybuk
<bddebian> Keybuk: Stop closing my sync requests and stealing my karma.. ;-P
<jdub> mdz: yeah, i removed it after seeing the difference, but still no love.
<mdz> jdub: proxy?
<jdub> mdz: nup
<mdz> jdub: (that you know of)
* jdub is suspecting apt-get
<elmo> seb128: is there anyway to check that doesn't involve running evolution?
<elmo> oh, well rm -fr .evolution should work
<jdub> mdz: see the output - 404 on the gz (which indeed is not there)
<Keybuk> bddebian: huh?
<Keybuk> bddebian: I can ignore all of your sync requests if you like ... :p
<bddebian> Keybuk: Doh...
<seb128> elmo: install contacts ?
<mdz> jdub: opinion on menu placement for https://wiki.ubuntu.com/HomeUserBackup ?
<dredg> why discriminate? ignore all sync requests!
<bddebian> w00t
<elmo> seb128: ah, thanks, that looks useful
<seb128> np
<elmo> so - next question, if I want to provide people data in a form they can pump into e-d-s, how do I do that?
<bddebian> Keybuk: Well I'm stacking you up some more so I guess I'll shut up :-)
<seb128> send some csv or vcf?
<jdub> mdz: seems sane to me (i think we moved too many "apps" into system > administration)
<elmo> seb128: there's a csv import option?
<jdub> elmo: in evo, yeah.
<seb128> elmo: from evolution yep
<dholbach> elmo: don't hit me, but ldap seems to be still the best solution, not sure, if there's "subscribe to a url of a vcf" (if you want to be able to change it every now and then)
<elmo> whine
<jdub> elmo: thanks for mentioning this
<sivang> Keybuk: Hey, I am trying to address your comments on system-clean-up-tool, however, I have partial answers to some of the issues, there are more complete answers from mvo on this, specifically, about being able to differentiate an upgrade installed kernel vs. dpkg -i one.
<dholbach> elmo: (one time vcf import should work fine though)
<sivang> Keybuk: also, I did understand what you were having issues with another question regarding that feature 
<sivang> Keybuk:     1. The new kernel that was just installed.
<sivang>      ''ScottJamesRemnant: this seems a bad time to mark the currently running kernel?  Why?''
<Keybuk> sivang: perhaps you need to explain why what you're using the current kernel for
<mdz> seb128: evolution upgrade seems to break the panel icon (evolution-2.6.png is gone)
<sivang> Keybuk: ah, k, I'll try clarifiying this some more.
<seb128> mdz: was that the stock icon or one you added?
<mdz> seb128: it was the stock icon afaik
<seb128> mdz: pitti already told that today, but it's supposed to use the non-versioned icon
<seb128> since when do you have your profile?
<seb128> dapper or before?
<mdz> seb128: since warty
<mdz> though I may not have had the evo icon the whole time
<mdz> I probably dragged it from the menu at some point
<seb128> ok, so that's probably the issue
<seb128> you dragged a version variant
<bddebian> Grr I hate trails of broken depends..
<seb128> it's non-versionned since dapper
<seb128> we will probably have to add a compatibility 2.6 symlink for it 
<mdz> seb128: the current icon is versioned also
<seb128> the menu one is, the panel one should be evolution-mail.desktop
<kbyrd> I guess I'll come out of lurk mode. I've got an inetd and etc/services question.
<mdz> Keybuk: when you approve a spec, don't forget to target it for edgy (unless there's some reason not to)
<Keybuk> mdz: did I forget one?
<Keybuk> I usually do
<mdz> Keybuk: edgyplusone-toolchain-roadmap
<Keybuk> hmm, I just did that one
<Keybuk> oh, right, yeah, I deliberately didn't target that one
<mdz> it's not on https://launchpad.net/distros/ubuntu/edgy/+specs
<Keybuk> because it says "edgy plus one" :p
<kbyrd> Would it be horrible if my package depended on inetd and conflicted with xinetd?
<mdz> Keybuk: the idea is that the work gets done duringso that it can land immediately in edgy+1
<mdz> s/duringso/during edgy so/
<mdz> it won't be due by feature freeze, but should be on the edgy radar
<mdz> (I've targeted it)
<Keybuk> ah, fair enough
<Keybuk> I vaguely misinterpreted "Release Goal" then :p
<rodarvus> Keybuk, (asking to you since you were the person who reviewed it) ogra, sbalneav and I updated the spec fully-automatic-swap-server earlier today - do you think you'll have time to review it again before the meeting?
<pygi> sivang, uh, forgot to tell you about libburn stuff :(
<Keybuk> rodarvus: given the meeting is in 10 minutes time, no :p
<Keybuk> I'll have a quick skim
<rodarvus> wow, its *late* :)
<ogra> pygi, gah, that was for sivang ? i could have told him if i had known 
<rodarvus> I didn't noticed the current time :)
<pygi> ogra, yea, we need that for HUB :P
<pygi> mdz, poke?
<mdz> pygi: yes?
<pygi> your comment on HUB is adressed
<sladen> kbyrd: what is your package doing?
<mdz> pygi: oh, there is a python API for libburn? I didn't realize
<mdz> we should package it
<mdz> and that should go in the spec, since it's a prerequisite for using it
<pygi> mdz, pyburn
<pygi> mdz, ok, will address that as well
<mdz> pygi: set to pending approval when you're finished
<sivang> pygi: yay, thank
<pygi> sivang, :)
<pygi> sivang, do we have KDE UI in spec for edgy or is it edgy+1?
<pygi_> sivang, sorry, ISP
<pygi_> do we have a KDE UI in scope for edgy?
<pitti> seb128: ok, then I just take inkscape (I didn't start libgnomeprint yet)
<pitti> seb128: and since it'll interact with gtk 2.10 anyway, I leave it in your capable hands then
<seb128> k
<pygi> sivang, you still alive? :)
<sivang> pygi: yeah, #u-m
<pygi> sivang, just please set spec to pending approval
<pygi> all mdz's comments are addressed now
<kbyrd> sladen. It's VMware VirtualServer, it's a soon to be release free version of what used to be called VMware GSX.
<kbyrd> Yea, that was a copy pasto. Official product name is VMwareServer, not VirutalServer.
<rodarvus> Keybuk, thanks a lot for reviewing the spec!
<sladen> kbyrd: does  update-inetd --add/remove  do what you need?
<sladen> kbyrd: you should be able to call them from postinst and prerm to add and remove your entries
<pygi> iwj, poke? :)
<iwj> Hello.  I'm in the distro meeting atm.  Can it wait an hour ?
<pygi> oki
<kbyrd> sladen: update-inetd adds the line to inetd.conf and restarts it. That's all fine. But, if the user has xinetd installed instead, they get some instruction that they need to convert inetd.conf to xinet.d format manually. 
<kbyrd> sladen: my inetd.conf line doesn't use a service name, it uses 902 explicitly. inetd is ok with this, xinetd is not (by default). I'm wondering if it's ok to just depend on inetd.
<kbyrd> sladen: and not "inetd | xinetd"
<sladen> kbyrd: xinetd wants an entry in /etc/services?
<kbyrd> sladen: it seems so. Looking at debug output it looks up the service by name. There's an option I can use in the config file that looks like it'll not do that. But I would be relying on users to know that and do it themselves based on the warning about xinetd update-inetd generates.
<kbyrd> sladen: I'm wondering if I can just depend on inetd and be done with it.
<kbyrd> s/just depend on/depend just on/
<sladen> kbyrd: might be the easiest way of getting away with it, the other is to get /etc/services updated with your port-number.  However, since that's below 1024 I don't know whether that'll wash
<kbyrd> sladen: Right, I wouldn't be here asking if I thought I had a chance of getting a <1024 port added.
<kbyrd> sladen: it loos like I should do depends on inetd and conflicts with xinetd. xinetd does this "/etc/init.d/inetd" redirection thing
<sladen> kbyrd: go for it, if anyone has a better solution, I'm sure they'll complain and let you know :)
<kbyrd> sladen: thanks. I was kind of hoping someone would pipe up with something like: "no theres this "foo-baz-update script that will do both xinetd and inetd updating. 
<pitti> seb128: control-center merge will fall under the general gnome 2.15 upgrade wave, I assume? c-c merge is currently infinity's
<seb128> pitti: yeah, anything GNOMEish will be merge during 2.15.3 or 2.15.4 updates this week or next week
<pitti> ogra: nessus-plugins was already synced
<pitti> ogra: oh, good to know that you claim kino, it was already on my list of things to grab from Adam
<pitti> Mithrandir: ah, let's coordinate merge-wise then; today I noticed that we two merged bcel and cup at the same time
<Mithrandir> pitti: given that I merged bcel and cup two days ago, that'd be special.
<pitti> Mithrandir: oh, hm, then main.html lagged behind that amount of time
<pitti> Mithrandir: anyway, I'll ping you when I do stuff from Adam or Charles, ok?
<Mithrandir> pitti: excellent.
<pitti> (unless you want to do them all on your own, that is :) )
<pitti> it's not that I'm bored, but we need to get it behind us soon
<Mithrandir> pitti: I've mostly moved on to X crack now, but we should coordinate better, agreed.  Ideally, we should have a way of grabbing merges.
<bddebian> Is something hosing up libxft-dev?
<pitti> Mithrandir: I'm fine with doing all of Charles' -java stuff; it's boring, but it's trivial, just takes time
<pitti> Mithrandir: if you want to turn your attention to X instead (which seems more important to me)
<Mithrandir> pitti: ok, please.
<crimsun> bddebian: yes, libxrender. Btw, it's src:xft now.
<crimsun> bddebian: I interpret "hosing up" to mean "holding up".
<bddebian> crimsun: Aye.  So it's been replaced or it's just held up?
<crimsun> bddebian: libxrender hasn't completed the transition yet.
<gnomefreak> crimsun: while we are on libxrender something i was asked earlier gimmie looks for libxrender.la but its no where in ubuntu and not in libxrender-dev where i thought it would be
<bddebian> Well get on it damnit ;-)
<gnomefreak> libxrender.a was the only thing close in the -dev package
<bddebian> gnomefreak: Probably the same issue I had last week.  Something else is bringing that in
<gnomefreak> is this a left out lib or just something that was never added?
<bddebian> gnomefreak: In my case it was libwnck-1.la that was brought in from devhelp.
<crimsun> gnomefreak: that's correct, it's not supposed to ship .la anymore.
<gnomefreak> oh ok ill count that as gimmie hasnt been updated than ty
<dholbach> gnomefreak: gimmie?
<bddebian> gnomefreak: You can try to figure it out by grepping the source tree to see what is looking for libxrender.la
<gnomefreak> dholbach: gimmie is some crap like panels (not sure never used it)
<tseng> hah
<dholbach> i looked into packaging it and it's nearly ready
<dholbach> but i'm waiting for upstream to fix their install target
* bddebian tries to sound like he knows what he is talking about
<gnomefreak> dholbach: that would be nice since ive had alot of people asking for it
<dholbach> gnomefreak: i know
<dholbach> install:
<dholbach>         @echo
<dholbach>         @echo "Gimmie isn't ready to be installed yet!"
<dholbach>         @echo "Just run ./gimmie.py for now."
<dholbach>         @echo
<dholbach> in ./gimmie/Makefile.am
<Amaranth> lmao
<dholbach> that's problem
<gnomefreak> ah
<bddebian> heh
<dholbach> if that doesn't get fixed we don't get a package :)
<tseng> you could call cp and then dh_install
<gnomefreak> im assuming its nto gonna be in edgy maybe edgy+1
<dholbach> tseng: assuming that everthing does *not* depend on static paths and stuff (same for import xyz (python modules)) :)
<tseng> dholbach: hah :)
<Mithrandir> mdz: could you look at https://launchpad.net/distros/ubuntu/+spec/cd-packet-writing now?
<jdub> tseng: hrm, no libbeagle-dev?
<jdub> libbeagle0 is described as "development files"
<jdub> but it is not :)
<LaserJock> mdz: in Paris somebody had talked about getting doc team reports at the distro meetings, is that correct?
<Mithrandir> mdz: also, https://launchpad.net/distros/ubuntu/+spec/live-cd-share-live-cd should be review- and approvable now, I think.
<mdz> Mithrandir: I'm having a couple of other conversations at the moment, but I will, yes
<mdz> LaserJock: I remember discussing artwork updates, and probably doc as well, yes
<mdz> LaserJock: are you volunteering to liase?
<Mithrandir> ogra: live-cd-share-this-live-cd was demoted to priority low now so I think you'll have to get some volunteers to help out if it's going to really happen.
<mdz> Mithrandir: I'm pretty sure it needs to be copied; tftpd shouldn't follow symlinks (in fact it should chroot itself)
<ogra> Mithrandir, i think i can find some 
<jdub> mdz: your opinion on fuse in general - good or bad?
<Mithrandir> mdz: tftpd-hpa can be told to do either, IIRC.
<ogra> Mithrandir, but i think your second usecase is rather utopic
<ogra> you wont be able to run *a bunch* of thin clients that way ... access times of the drive are to slow
<LaserJock> mdz: I can't for all meetings, but I could write up a note for the ones I can't make I suppose
<ogra> (unless the server is fat enough to cache everything)
<LaserJock> mdz: more or less a quick note on the doc teams progress?
<mdz> LaserJock: what's happened in the past week, what's planned for the next week, with a particular focus on edgy targets
<Mithrandir> ogra: 1G of memory isn't very expensive those days.
<Mithrandir> ogra: but maybe it is; *shrug*
<pygi> Mithrandir, 115$ I would say
<pygi> or less
<ogra> Mithrandir, we have a default of 256MB for an edubuntu server with additional 128MB per client ...
<sivang> pygi: libburn doesn't have a debian package yet?
<ogra> so with 1G you can run 6 clients *without* space for caching ...
<pygi> sivang, I think it doesnt
<pygi> lemme check
<LaserJock> mdz: ok
<pygi> sivang, libburn does, pyburn (python bindings) don't
<ogra> if that thing caches 512MB you are left with 2 clients ...
<mdz> Mithrandir: cd-packet-writing is fairly open-ended; could you do some investigation and see which of the open questions under Scope are necessary?
<ogra> its a good thing to demo ltsp, but i dont think it can be a full time solution
<pygi> sivang, have you changed to pending approval and notified mdz?
<mdz> pygi: yes
<mdz> pygi: you can see that in LP
<pygi> oki :)
<ogra> Mithrandir, i'll do some tests with sshed sessions to a livecd next week so i can get some real impression ...
<Mithrandir> mdz: willdo
<mdz> ogra: s-c-p-p whiteboard says comments inline, but there are no comments and it's still in drafting
<ogra> mdz, oh, sorry i'll change status ...
<ogra> fixed
<mdz> sivang: you set make-free-space-wizard to pending approval instead of back to review. why?
<sivang> mdz: by mistake sorry, I am supposed to set to pending approval only after reciving informal approval from the approver or only he's supposed to do that?
<mdz> sivang: a reviewer sets it to pending approval after it has been reviewed
<Kamion> sivang: you set it to review
* Kamion <- (just here very briefly to see if there was anything I had to do urgently arising from the meeting)
<sivang> Kamion, mdz : noted, I'll set both of my specs to review then. (I also set h-u-b for pending approval)
<mdz> sivang: I already reviewed and approved h-u-b
* pygi yays
<pygi> thanks mdz :)
<sivang> mdz: I just saw that, thank you mucho
* pygi congrats to sivang :)
<tseng> jdub: hm?
<tseng> jdub: its called beagle-dev
<tseng> jdub: and yes, I know
<Mithrandir> mdz: fixed the scope bit after testing a little bit with packet writing here.
<mdz> Mithrandir: better, thanks
<mdz> Mithrandir: presumably the existing hook for erasing cd-rw media could be used for the formatting
<Mithrandir> mdz: good point.
<mdz> ogra: doesn't ltsp have an existing info daemon?
<ogra> mdz, ltsp-org has
<mdz> ogra: right, wouldn't it be better to use that?
<mdz> oh, wait, that one runs on the client, doesn't it
<mdz> even so
<ogra> well, it would also still need the extensions for ldm (assuming youre on that atm)
<mdz> I'm on login and session handling
<ogra> i dont think it provides either of the info we need there
<mdz> yes, but it already exists, is tested, works and provides a network service for retrieving information
<ogra> (neither languses nor installed X session)
<mdz> no need to reinvent the wheel
<ogra> *languages
<ogra> ok, i'll change the spec so it uses ltspinfod
<ogra> (i'm pretty sure it can run either on the server or on the client, its just an inetd started daemon)
<mdz> Mithrandir: hmm, just saw the Opera announcement in LWN...I suppose we should get that into dapper-updates
<Mithrandir> mdz: can you investigate where the upload went?
<Mithrandir> or, you could grab the source from http://people.ubuntu.com/~tfheen/opera/ and upload that to dapper-updates then do the third-party-packages dance.
<mdz> Mithrandir: looking
<mdz> Mithrandir: version '3'?
<Mithrandir> mdz: ? opera_9.00-20060616.7 is the version.
<mdz> oh, I was looking for app-install-data-commercial
<Mithrandir> oh, sorry, I haven't touched that since there'd be no way for me to test it until the package was in an archive.
<mdz> I have no idea how the commercial repository works
<mdz> Mithrandir: to what queue did you upload it?
#ubuntu-devel 2006-07-07
<ogra> mdz, ltsp-login-and-session-handling updated
<ajmitch> morning
<pitti> hi ajmitch 
<pitti> good night everyone!
<pygi> night
<zul> hey
<sivang> mdz: I'd like to sign off for today, add your comments inline again, I will address them when I get up tomorrow, and we can discuss again SCUT (system clean up tool) tomorrow when you're online?
<ajmitch> mdz: I've cleaned up that network-authentication spec 
<mdz> sivang: Keybuk should review it since you were attempting to address his comments.  I will look at it when it is pending approval
<Kamion> mdz: I approved app-install-data-commercial 3 earlier, which included support for dapper-commercial which was apparently the relevant bit
<mdz> Kamion: it adds a repository file for it, but it doesn't actually exist in the archive yet
<mdz> so as far as I can tell it's broken
<mdz> deb http://archive.canonical.com/ubuntu dapper-commercial main
<Kamion> oh, opera's not there, true
<mdz> Kamion: I have no idea how things are supposed to get from drescher to wherever that is
<Kamion> upload.canonical.com != upload.ubuntu.com
<Kamion> AFAIK it doesn't go near drescher
<mdz> where does it go?
<Kamion> wherever 82.211.81.142 is
<Kamion> jackass is 82.211.81.140, although that was my first guess
<Kamion> I believe it's a katie instance elmo set up - at least that was the plan
* Kamion accepts libx11 from NEW; now maybe slightly more of the world will be installable
<mdz> Kamion: I'm sure it's sitting in a new package queue somewhere
<mdz> .142 seems to be rockhopper
<mdz> where I don't have an account
<Kamion> nor I
<Kamion> elmo: help
<Kamion> [Updating]  libast (0.6-0pre2003010606.1ubuntu4 [Ubuntu]  < 0.7-1 [Debian] )
<Kamion> yay for version number reduction
<jsgotangco> good morning
<ajmitch> hello jsgotangco 
<Burgwork> hey jsgotangco, ajmitch 
<Burgwork> is it my imagination, or is there no central place for development of cups drivers? we appear to have foomatic, guten-print, hplip, etc
<jsgotangco> we're one big happy decentralised family
<Burgwork> lovely ;)
<Whoopie> Hi, I'm a little bit confused. After the language-pack updates today, gnome-power-manager shows new german translations for suspend/hibernate on one machine, but not on another machine. I already rebooted, but no change. Any ideas?
<Burgwork> Whoopie, please use #ubuntu as this is not a support channel
<Whoopie> ok
<Burgwork> Whoopie, but for the record, check to make certain dapper-updates is on both
<Whoopie> yes, it's. Since I installed on both machines the new packages.
<crimsun> Whoopie: Is there a reason you adjusted the Status of #38272?
<Whoopie> crimsum: did I? sorry, then it was accidently.
<Whoopie> s/crimsum/crimsun
<crimsun> np, just checking
<ajmitch> hello Burgwork 
<Burgwork> how is your SoC project coming?
<ajmitch> ok
<ajmitch> things are moving, it's getting there :)
<Burgwork> got any shiny code to show us?
<ajmitch> patience.. :) I'll throw some stuff that way next week when I'm back home
* ajmitch is currently in foreign lands
<bddebian> Howdy
<Burgwork> greeting bddebian 
<bddebian> Heya Burgwork
<jdub> "A netfilter connection tracking helper for the SIP protocol." -> in 2.6.18 -> ooh!
<jdub> BenC: is edgy going to be .17 or .18?
<jsgotangco> oohhh
<BenC> jdub: .17
<jdub> BenC: ah well ;)
<BenC> jdub: if the sip helper is pretty self-contained, should be no problem to add it to .17
<jdub> BenC: you'd laugh at the idea of pulling the libata changes, right? ;)
<BenC> jdub: hehe
<jdub> BenC: good answer. ;)
<jcole> my synaptics touchpad is jumpy and is now hard to control... this happens every so often and i don't know why...  any way to remedy this without restarting X? i've got a bunch of stuff open right now
<bur[n] er> can anyone help me get a backtrace for a nautilus bug?  
<bur[n] er> http://bugzilla.gnome.org/show_bug.cgi?id=330625
<Ubugtu> Gnome bug 330625 in general "sftp crashes on clicking any folder once connected" [Critical,Needinfo]  
<bur[n] er> i'll set up the sftp server that makes nautilus crash and give someone a user/pass
<Chipzz> bur[n] er: 1) this is not a support channel
<Chipzz> bur[n] er: 2) even if it was, it is most likely an issue with upstream; it'll be far more effectief to get someone to debug the bug with if you contact them
<bur[n] er> i know... but it is a developer channel, and developers fix bugs, and a dev wants a better trace, and I'm hoping someone here has nautilus with debugging symbols installed
<Hobbsee> bur[n] er: which app is it asking you to do the backtrace with?
<bur[n] er> nautilus i think
<Hobbsee> bur[n] er: with these things, it's usually done by installing gdb, then gdb program, run, then copy the backtrace
<bur[n] er> i did
<Chipzz> bur[n] er: you're referring to a bug in gnome bugzilla btw; how is this the ubuntu developers responsability to fix it?
<bur[n] er> but i need nautilus with debug symbols installed ot get a deeper trace it says
<Chipzz> I'm not sure there are debug packages of nautilus
<Hobbsee> bur[n] er: yes, the debugging symbols *are* gdb
<Hobbsee> usually
<bur[n] er> i need "more" of them ;)
<Chipzz> there probably are of the libs, but most likely not of the apps
<bur[n] er> so I think i need nautilus-dbg or something
<Hobbsee> bur[n] er: install gdb, and you'll have moe of them
<Hobbsee> if there's a package called that, that's likely it.
<Hobbsee> anyway, --> #ubuntu
<bur[n] er> holy crap, there is... ok, #ubuntu it is
<bur[n] er> thanks
<Chipzz> bur[n] er: anyway, this channel is about the development *of* ubuntu, not development *with* ubuntu :)
<bur[n] er> I've also tried #gnome on irc.gnome.org, but they're not so active ;)
<bur[n] er> ubuntu uses gnome which has nautilus as part of it... it's an issue with gnome 2.14.2 so yeah... there's my logic ;)  sorry to interrupt the calmness of #ubuntu-devel ;)
<Chipzz> bur[n] er: and you need to understand that what the ubuntu developers do is mostly *packaging* the software, they do not actually *write* it :)
<bur[n] er> some do... I've heard stuff about ubuntu pushing things back upstream
<Hobbsee> Chipzz: depends what software it is :P
<Chipzz> idd some do; depends on the technical knowledge of the developer
<Hobbsee> bur[n] er: of course they do, but they dont generally discuss gnome stuff in here
<Chipzz> Hobbsee: true; but in general what I said holds
<jdub> bur[n] er: install nautilus-dbg
<Hobbsee> speaking of which, what happened to kvdr, i wonder.
<Chipzz> bur[n] er: also, there is 2 kinds of upstream in the case of ubuntu
<Chipzz> there is debian which is upstream wrt packaging
<Chipzz> and there are people like the gnome developers, who actually write the software
<Chipzz> also, in most cases, when patches are applied, they're rarely patches the ubuntu developers wrote themselves, but rather patches pulled from upstream cvs :)
<Chipzz> does this clarify stuff a bit? :)
<bur[n] er> sure
* bur[n] er heads back to #gnome ;)
<Chipzz> bur[n] er: good luck :)
<Hobbsee> something ate my kvdr.  i could have sworn i did that.
<bur[n] er> thanks
<bur[n] er> i hope this sucker gets fixed by 2.16, so annoying
<bur[n] er> peace
<Hobbsee> ohhh...it was kdbg that got done, not kvdr.  MOM isnt crazy.
<wasabi> Is 1.002-1+b1 less than 1.002-1ubuntu1
<wasabi> I would think so.
<wasabi> Ahh. Actually no. I see.
<fabbione> morning
<Hobbsee> hi fabbione 
<ajmitch> hello fabbione 
<fabbione> hey guys
<jsgotangco> hey
<imbrandon> heya fabbione
<dholbach> good morning
<Burgundavia> I noticed I have not seen infinity around for a while
<dholbach> Burgundavia: he's on vacation
<Burgundavia> ah, ok
<Burgundavia> they let you have those? ;P
<Hobbsee> Burgundavia: no, it's only an illusion
<Hobbsee> that's why those who are on vac still come to the meetings.
<Burgundavia> Hobbsee: indeed
<fabbione> i am going to renew my offer to give away for adoption openais
<fabbione> that's going to hit archive in not too long from now
<fabbione> as in a couple of hours
<\sh> moins
<highvoltage> hi \sh and viviersf 
<viviersf> lo
<pitti> Good morning
<pygi> mornin' pitti 
<Hobbsee> hi pitti, pygi 
<mdke> does anyone know if there are plans for speeding up gnome-app-install? the time it spends calculating dependencies and so on before and after you install anything means that I never use it at all
* pitti just notices that the keyboard selector now works again in edgy - great!
<Hobbsee> dholbach: what group do you have to be in to be able to set the importance of a bug?
<dholbach> ubuntu-qa afaik
<Hobbsee> dholbach: i was under the impression it was bug-squashers, but it seems that even that doesnt give you the privelages
<Hobbsee> ahhh...
<Hobbsee> dholbach: approve me please?
<Hobbsee> dholbach: thankyou very much :)
<dholbach> de rien :)
<herzi> mjg59: ping
<pygi> doko, you have a sec
<sivang> morning
<pygi> hey simira 
<pygi> sivang*
<Hobbsee> hi sivang 
<sivang> hey Hobbsee , pygi 
<pygi> doko, poke? :)
<sivang> pygi: what's up? 
<pygi> sivang, not much, working on website
<sivang> pygi: for? :)
<pygi> do you need help on make-free-space-wizard
<pygi> sivang, personal one (pygi.pykix.net, pykix.net), blog (blog.pykix.net) and projects (projectname.pykix.net, projectname.pykix.net/trac)
<dholbach> Riddell: i hope you don't mind, if I don't do the KDE merges (my name shows up quite some times, since I did the KDE mass uploads)
<sivang> pygi: yes, I will require help with it. specifically read the part of how not to impact system performance while still needing to calculate aging for files
<pygi> sivang, will do now ^_^ You comment pages while I read ^_^
<pygi> sivang, I dont see any review comments on spec? :-/
<Hobbsee> dholbach: were those merges uni or main?
<dholbach> Hobbsee: main
<Hobbsee> dholbach: bleh, okay
<pygi> sivang, you'll need to point me to exact thing that needs thinking, but about impacting system perfomarmance...
<pygi> we could calculate that stuff while system is idle
<sivang> pygi: already added this to the spec, question his, how do you reliably know when the system is idle, and more importantly, since this is heavy load on disk access, how do you instantly detect that a user has started using it again, such that he won't notice a difference or "spikes" ? 
<sivang> s/his/is/
<sivang> pygi: I don't think Keybuk has had a chance yet to review my previous addresses
<pygi> we could initiate "disk access lock" for anything but our application, and put high priority
<pygi> until it's finished
<sivang> pygi: what do you mean in "disk access lock" ?
<sivang> pygi: how do you do something like that?
<pygi> well, once we detect system is in idle state, we could invoke calculation, and prevent user from running any application
<sivang> pygi: We can't prevent him from doing so, it's his system, not ours :P
<pygi> we can actually :P
<sivang> pygi: we can't. Seriously, I wouldn't want my systme to lock down every time I leave it alone for 5 minutes
<sivang> pygi: I would not use such a system
<pygi> sivang, not everytime really :P
<sivang> pygi: okay, so what's the plan?
<pygi> sivang, I must go now, but should be back quite soon
<pygi> I'll try to think of something acceptable to both us and users
<sivang> pygi: thanks, I'd beinterested to hear I'll also try to come up with something
<Mithrandir> pitti: are you planning on uploading the freetype security fix to edgy as well?
<Mithrandir> bah
<Mithrandir> 11:10 < Mithrandir> pitti: are you planning on uploading the freetype security fix to edgy as well?
<pitti> Mithrandir: bah, that's still not in Debian?
<pitti> Mithrandir: yes, I can do that of course
<Mithrandir> pitti: unsure, but if so we haven't merged.
<pitti> Mithrandir: I'll check with Keybuk; if that's the only diff, then I'd rather do a Debian NMU and sync
<pitti> otherwise I can take the merge and apply the patch
<Mithrandir> (I only discovered this because I had ubuntu2.1 installed, then upgraded to edgy then tried to install -dev and it all blew up)
<pitti> Mithrandir: no, it's still on the merge list (assigned to Keybuk)
<pitti> Hi Kagou 
<Kagou> hi pitti  :)
<Kagou> hi seb128 
<seb128> lu Kagou
<Riddell> dholbach: don't mind at all, what KDE merges would you not be doing?
<Kamion> wasabi: for future reference this is how you check:
<Kamion> $ dpkg --compare-versions 1.002-1+b1 lt 1.002-1ubuntu1; echo $?
<ogra> doko, ping
<dholbach> Riddell: none of them? :)
<pitti> Mithrandir: ok, I did all of chmj's merges now; I'd continue to pick some from Adam, since he's on vac
<dholbach> Riddell: i'm quite busy with the whole gnome stack still
<pitti> Mithrandir: I'd start with mysql-dfsg-5.0 unless you already started it
<Riddell> dholbach: are you talking main or universe?
<dholbach> Riddell: both, although i can't remember universe kde uploads i did
<Hobbsee> dholbach: nothing showing for universe w.r.t kde with your name on it
<dholbach> Hobbsee: ok, thanks
<Riddell> and not much left in main, I'll get those all done today
<Riddell> still, shame that my secret plan to have dholbach take over kde maintenance failed
<Hobbsee> hehe
<dholbach> Riddell: i don't think you want that ;)
<Hobbsee> dholbach: what, you'd just run rm -rf kde*?
<Hobbsee> shame.
<dholbach> "Kubuntu delayed 8 weeks, investigations in ominous patches are still on-going."
<Hobbsee> haha
<Mithrandir> pitti: please do, I'm busy with X.
<pitti> Mithrandir: ok, then maybe you can tell me if you grab one of infinity's merges? (since that seems to be much less likely)
<Mithrandir> pitti: sure
<pitti> great
<pitti> seb128, dholbach: bah, this gnome-terminal bug that enlarges itself when switching tabs becomes really annoying...
<pitti> seb128, dholbach: is that a known issue or do you want a bug report?
<seb128> ah, there is a such bug? that's new?
<seb128> not known by me
<seb128> I don't use tabs for g-t
<seb128> feel free to open a bug
<pitti> ok
<seb128> switching tabs works fine here apparently
<pitti> it started today
<seb128> I might be not uptodate enough then :)
<pitti> well, or me; I didn't dist-upgrade today yet
<pitti> seb128: but I'm happy that the xkb stuff works again :)
<seb128> pitti: is that http://bugzilla.gnome.org/show_bug.cgi?id=346222 ?
<Ubugtu> Gnome bug 346222 in general "Window doesn't resize when the tab field disappears" [Minor,Unconfirmed]  
<pitti> seb128: no, sounds unrelated
<seb128> ok
<pitti> hi slomo 
<dholbach> pitti: there's a bug filed already, but i don't encounter it
<slomo> hi pitti 
<pitti> dholbach: maybe it only occurs with special settings
<dholbach> oh, i encounter it too
<pitti> dholbach: it doesn't happen everytime, but when switching to particular tabs
<pitti> and sometimes it enlarges by 1 line, sometimes by 5 or so
<dholbach> but doing ctrl-shift-t, ctrl-d, ctrl-shift-t, ctrl-d, ctrl-shift-t, ctrl-d, ctrl-shift-t, ctrl-d, ctrl-shift-t, ctrl-d is not what i regularly do :)
<pitti> dholbach: no, I use alt+1, alt+2 etc.
<pitti> to switch
<pitti> (switchign with mouse click on tabs does the same)
<pitti> dholbach: but yes, c-s-t maximizes my window, too
<slomo> hm, you're not talking about the weird gnome-terminal behaviour with tabs with latest vte/gnome-terminal?
<pitti> slomo: I think we do
<slomo> oh ok... i noticed it just before starting xchat ;) my terminal changes the height when switching tabs
<dholbach> Kinnison/mg59: could you look into the gnome-power-manager merge/update? I know it says my name on merges.ubuntu.com/main.html - but I really don't feel comfortable about it. tseng already investigated in porting our patches, but found upstream had gone a long way since you added the patches. :/
<ogra> dholbach, i was about to ask how the status is
<dholbach> ogra: i merely added some icons to it
<dholbach> ogra: that's why my name shows up in the list
<ogra> we always had our own package, seems debian uses the native stuff from hughsie but it only differs in the rules now
<ogra> i think we should rather grab upstreams 2.15 :)
<dholbach> i silently agree :)
<Kinnison> dholbach: richard was very good at taking on my patches, so you may find you need to remove patches in order for things to work. However I don't know what he has done since and our suspend-gating patch might break
<ogra> i'll probably do that tonight if i'm in the eifel again
<shawarma> win 1
<shawarma> gah...
<sivang> please don't break to syspend to ram, it works so beuatifully now :)
<fabbione> pitti: ping
<dholbach> Kinnison, ogra: thank you
<ogra> sivang, g-p-m only triggers it ... the rest is the kernels job :)
<sivang> ogra: ah, cool then, you can probably grab upstream in that case
<fabbione> Kamion: ok slam it in universe for now. It might take sometime to get it reviewed etc.
<fabbione> Kamion: thanks
<Kamion> ok
<cain__> chz 
<ogra> dholbach, looks like g-p-m 2.15 has to wait ...
<ogra>   libgnomeui-dev: Depends: libbonoboui2-dev (>= 2.13.1) but it is not going to be installed
<ogra> dholbach, but i have a prepared package around ... wil go on with it if the gnome stack is complete
<tseng> ogra: *hugs*
<dholbach> ogra: because of libgnutls11-dev vs libgnutls-dev or x?
<ogra> oh, hm ... good question... libbonoboui2-dev *is* at 2.14.0
* ogra checks whats missing
<dholbach> ah no
<dholbach> that's on amd64?
<dholbach> then it'S because of libgnomeui because of gtk because of pango because of libxft because of x (or something)
<tseng> oh thats interesting
<tseng> in gtk+ 2.10, moving a scroll bar all the way to one side desensitizes the button in that direction
<dholbach> yeah
<dholbach> that's neat
<ogra> dholbach, powerpc
<dholbach> ogra: might be the same story
<ogra> yep
<dholbach> afaik gtk and gnomeui only built on i386 already
* Mithrandir sighs at us getting bitten by the freetype6 ABI breakage.
<dholbach> then X hit in :)
<dholbach> Mithrandir: where did it bite you? i mean, which package?
<tseng> Mithrandir: had to happen sometime, no?
<Mithrandir> dholbach: dapper has the package with the broken ABI.
<ogra> but thats weird, it complains about libgnome2-dev and libgnomevfs2-dev not being installable ... but both of them are fine if i install them in my chroot ... the versions are fine as well
<seb128> ogra: most of GNOME -dev are not installable since yesterday
<dholbach> Mithrandir: afaik nothing was done in debian about it. and to the best of my knowledgy only some gnustep apps were bitten directly, right?
<Kamion> dholbach: it was fixed in Debian recently
<dholbach> oh ok
<seb128> ogra: libpango1.0-dev Depends on libxft-dev which is not installable ... should be fixed soon
* dholbach reads the debian changelog
<Mithrandir> dholbach: what Colin says and even though gnustep is the one bitten by it, it's bad nevertheless.
<ogra> seb128, dholbach, ugh, please check the dependencys of libbonoboui2-dev
<Kamion> where recently = March
<Mithrandir> seb128: it's been synced and NEWed 
<dholbach> Mithrandir: i'm not happy about it either
<seb128> Mithrandir: cool :)
<Kamion> we're going to have to rebuild xft after freetype though
<Mithrandir> so it just needs to be published and built.
<ogra> seb128, dholbach, there is a doubled entry for libgnome2-dev
<Kamion> we *really* should have caught the freetype upgrade in March
<Mithrandir> Kamion: we should, but we didn't so we get to cope now. :-/
<seb128> ogra: who cares about that :p
<seb128> (we will fix it with next upload)
<hunger> Is it really necessary for gs-esp to install libglib1.2? gs-gpl does not have that dependency. But then cupsys needs gs-esp...
<dholbach> ogra: i agree with seb128... it could be worse :)
<ogra> seb128, well, libbonoboui2-dev claims to be not installable because libgnome2-dev isnt there (which is an evil lie from apt :P)
<tseng> dholbach: do you have any gnome merges I can help with w/o crazy ubuntu patches?
<Mithrandir> Kamion: rebuilding xft is trivial enough though, so I guess we should just note this down on the big "stuff we have to fix" list.
<Kamion> so I propose we sync freetype now, which appears to be doable
<Kamion> all the patches have been incorporated
<seb128> ogra: nothing to do with the matter
<dholbach> tseng: i think there's quite a bunch of stuff on merges.ubuntu.com/main.html left
<Mithrandir> Kamion: sync freetype, then immediately rebuild xft?
<Kamion> yeah
<Mithrandir> sounds like a plan to me.
<Kamion> freetype syncing
<Mithrandir> I'll do xft
<ogra> seb128, i can install the libgnome2-dev and libgnomevfs2-dev packages just fine so there is no reason why libbonoboui2-dev shouldnt be installable ...
<seb128> ogra: either it's installable or not
<ogra> The following packages have unmet dependencies:
<ogra>   libbonoboui2-dev: Depends: libgnome2-dev (>= 2.13.0) but it is not going to be installed
<ogra>                     Depends: libgnome2-dev but it is not going to be installed
<ogra>                     Depends: libgnomevfs2-dev but it is not going to be installed
<tseng> dholbach: ok i will look in a few days when i can install my build-deps
<ogra> i can install the two dependencies, but not libbonoboui2-dev
<doko> ogra: ?
<seb128> ogra: libbonoboui2-dev is not installable, it requites libpango1.0-dev which requires the new xft
<dholbach> ogra: sudo apt-get install libgnome2-dev  ---  what does it say?
<Kamion> Mithrandir: we should merge new fontconfig too
<ogra> doko, see #ubuntu-toolchain
<seb128> requires
<Kamion> (before rebuilding xft)
<Kamion> +  * noftinternals.patch: patch from freetype.org to avoid using freetype
<Kamion> +    internals (closes: #370458).
<ogra> dholbach, it installs libgnome2-dev
<seb128> ogra: what does aptitude say on the topic?
<ogra> seb128, let me try (i never used aptitude in my life :) )
<seb128> ${la:Depends}
<seb128> hum
<seb128> is that new? :)
<Mithrandir> Kamion: ok, should I do that or would you like it?
<Kamion> doko: how quickly could you get fontconfig merged?
<dholbach> Kamion: thanks for the syncs
<ogra> seb128,  aptitude: Depends: libapt-pkg-libc6.3-6-3.11 but it is not installable
<ogra> :P
<seb128> ogra: you should use dapper :p
<Kamion> noting that fontconfig build-depends: libfreetype6-dev so it needs to go in the publisher run *after* freetype binaries are built
<doko> Kamion: oops, I missed that; should be easy
<ogra> seb128, thats in my edgy pbuilder :)
<doko> doing it now
<Kamion> doko: can you do it but wait for a signal before uploading? this all looks unpleasantly delicate
<Mithrandir> Kamion: I'm tempted to just add a versioned build-dep on the fixed libfreetype6 but still make it an build1 upload, that should be ok?
<doko> Kamion: sure
<Kamion> Mithrandir: yeah
<Kamion> doko: thanks
<Mithrandir> ok, xft with tightened build-deps (which should leave it in dep-wait for a bit) uploaded.
<Chipzz> hrrrm mvo not here?
<dholbach> Chipzz: he's on holidays
<Kamion> pitti: I've NEWed liboobs straight to main because gnome-system-tools already build-deps on it, but could you have a look over it?
<dholbach> Chipzz: can I help you with something?
<dholbach> Kamion: thanks a lot for that
* pitti looks at the boobs
<pitti> Kamion: sure
<dholbach> pitti: ! :-)
<Chipzz> dholbach: a repository which previously worked flawlessly all of a sudden is causing apt to b0rk
<dholbach> pitti: i guess that will require the other main inclusion reports, sorry :-(
<Chipzz> I suspect something broke with the last apt-upload, as the release file (which apt is complaining about) actually looks fine
<dholbach> pitti: i can write a liboobs one too, if you like
<Chipzz> apt upload, that is
<dholbach> Chipzz: humhum, i suppose it's better to write a bug report about it. I'm not that apt 
<pitti> dholbach: a small one would be nice; I can do the security bits, but an assessment of quality and purpose would be nice
<dholbach> pitti: okay!
<doko> Kamion: #52102, eunuchs and epydoc are not synced
<dholbach> pitti: done
<Kamion> bug 52102
<Ubugtu> Malone bug 52102 in semperwiki "view rendering configurable" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52102
<Kamion> doko: ^-- try again? :)
<doko> Kamion: bug 52101
<Ubugtu> Malone bug 52101 in Ubuntu "sync requests" [Untriaged,Fix released]  http://launchpad.net/bugs/52101
<Kamion> doko: epydoc certainly is merged and built
<Kamion> as for eunuchs:
<Kamion> $ dpkg --compare-versions 20050320.1ubuntu1 lt 20050320.1-0.1; echo $?
<Kamion> 1
<Kamion> can't sync that
<Kamion> (sync-source didn't tell me about that so I didn't notice, sorry)
<elmo> so, gnome apps can't add stuff to my panel
<elmo> is there anyway to debug/fix that, short of trashing ~/.gconf, ~/.gnome*  and starting again?
<dholbach> elmo: what do you mean by that?
<dholbach> elmo: to the notification area?
<elmo> dholbach: yes, I thought it was just update-notifier, but ekiga has the same problem
<dholbach> elmo: but you still have the notification area applet on the panel?
* seb128 bets he has no notify area on his panel
<dholbach> i'd be happy if somebody who worked on i18n would take scim to merge
<pitti> dholbach: is libmusicbrainz something gnomeish you'll update in the next time? if not, I'll do the merge now (it's Adam's)
<elmo> oh.  oh dear.
<elmo> how embarassing
<dholbach> pitti: i didn't intend to - if you take it, i'm happy.
<pitti> dholbach: I'd just monkey-merge it, I don't even know what it is for :)
<seb128> elmo: didn't have the applet? ;)
<elmo> seb128: yes :-(
<seb128> hehe
<elmo> I'll go and close that several month old bug on update-notifier now *blush*
<ogra> elmo, but i can confirm update-notifier behaving weird :)
<pitti> dholbach: any idea why we dropped the python packages for it?
<dholbach> pitti: lookup of cddb data, etc
<dholbach> pitti: because we didn't have python-random-xyz in main at that time and it was past uvf
<seb128> pitti: something like "require stuff from universe"? :)
<pitti> seb128: ah, indeed; thanks
<seb128> np
<dholbach> it'd be great to have them, though
<dholbach> hum, why is  screem  in main?
<seb128> because somebody likes it and asked for it probably? :p
<doko> Kamion: does fontconfig need a tightened b-d on libfreetype6?
<Kamion> doko: not sure - *probably* not, and I think it would only be for build ordering
<Kamion> doko: just waiting for https://launchpad.net/distros/ubuntu/+source/freetype/2.2.1-2 to have a set of "Successfully built" lines at the moment
<\sh> doko: is http://wiki.debian.org/DebianPython/NewPolicy valid for ubuntu, too?
<doko> \sh: yes
<pitti> iwj: do you think you can do the gsfonts-x11 merge?
<ivoks> pitti: ping
<pitti> Kamion: oh, I just noticed that we didn't drop courier from the seeds yet (as discussed in Paris); ok if I do that now?
<pitti> hi ivoks
<ivoks> pitti: i've finished gutenprint-rc3
<pitti> ivoks: cool
<Kamion> pitti: sure
<ivoks> pitti: http://www.grad.hr/~ivoks/ubuntu/gprint
<Kamion> (without knowing anything about the specific change)
<Kamion> UbuntuServerTasks mentions courier as a possibility
<Kamion> (which would need it in main)
<pitti> Kamion: we have dovecot and cyrus21 already, no need for a third MTA
<Kamion> 'k
<pitti> Kamion: right now there are no rdepends, I just checked
<pitti> in warty we used courier because dovecot wasn't quite there yet
<pitti> Mithrandir: btw, freetype 2.2.1 has the security fixes upstream, so all is good
<Mithrandir> pitti: excellent.
* ogra wonders if suspend works with the new kernel
<Hobbsee> ogra: try it :P
<Kamion> could somebody (a Kubuntu person?) in ubuntu-dev please confirm #52215?
<ogra> Hobbsee, i just did !
<ogra> Hobbsee, works wonderful
<Hobbsee> ogra: yay!
<Hobbsee> bug 52215
<Ubugtu> Malone bug 52215 in codeine "Please sync with debian" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52215
<ogra> (if you use an ibook)
<Riddell> Kamion: yes please
<Riddell> confirmed
<Kamion> thanks
<hunger> ogra: Unfortunately that kernel does not even boot if you have my thinkpad:-(
<ogra> hunger, well, mine booted, but i had no keyboard until yesterday :)
<ogra> edgy is so much fun :)
<iwj> pitti: I don't see why not.  I'll take it.
<iwj> Yay, a working firefox build.  OK it's the debug build but the end is in sight.
<ogra> is anybody on libgtk-perl ?
<pitti> ogra: I asked for a sync
<ogra> pitti, ah, fine
<pitti> ogra: oh, sorry, that was libgtk2-perl
<gnomefreak> what is this? Qt::VBoxLayout
<pitti> seb128: ok for me merging gnumeric?
<seb128> pitti: I think dholbach was doing it yesterdya
<seb128> yesterday
<thom> gnomefreak: it looks like a function to me.
<pitti> dholbach: did you? it's not yet uploaded
<gnomefreak> well the error starts with DESTROY and that kind of worried me
<seb128> pitti: jui 04 12:39:00 <dholbach>      seb128_: for gnumeric i look into goffice, for that i have to merge libgnomeui, for that i have to merge libbonoboui (hope you didn't start on any of those)
<seb128> pitti: let him some time, I'm sure you have other merge you can do for now ;)
<dholbach> pitti, seb128: Gloubiboulga is working on it
<seb128> pitti: knowing that we have a GNOME stack being broken since yesterday so it's not easy to try the merges and to upload something
<dholbach> he already did goffice, which i need to review
<gnomefreak> it seems to be going so ill ignore the message for the moment
<pitti> dholbach: alright, thanks; I let it alone then
<seb128> pitti: gnome-power-manager is looking for somebody determined though, if you feel doing so (dholbach would love you for it)
<dholbach> seb128, pitti: ogra is working on it
<seb128> ah, k
<ogra> hmm, looks like gtk-perl can be synced as well
<dholbach> seb128: doing gok
<seb128> dholbach: feel free to do whatever on your list without saying you do them :)
<pygi> hey raphink 
<raphink> hi pygi
* ogra really wonders why suddenly so many packages have doubled build deps
<ogra> i.e. Build-Depends: cdbs (>= 0.4.23-1.1), autotools-dev, gnulib (>= 0.0.20041014-2), quilt, patchutils (>= 0.2.25), cdbs (>= 0.4.27-1), dh-buildinfo
<raphink> huh?
<raphink> :s
<ogra> why is cdbs twice in there ? 
<raphink> ogra: I'd guess this is a package using cdbs evil auto control rule, no?
<ogra> hmm
<ogra> auto-update.mk ?
<raphink> in debian/rules
<raphink> the @@ stuff
<raphink> don't remember it by heart
<raphink> I had to kick it out sometime 
<raphink> cause it was generating conflicting deps
<raphink> lol
<ogra> there *was* a DEB_AUTO_UPDATE_DEBIAN_CONTROL = 1 at the top that was apparently dropped
<raphink> did you remove it?
<pitti> dropping this sounds gooooood
<raphink> very good :)
<ogra> nope, lamont commented it ...
<raphink> hmmm
<ogra> and the recent debian version dropped it
<ogra> but that didnt fix the build deps :P
<raphink> thre must be a bit of it somewhere still
<raphink> ;)
<raphink> it's not dead yet
<ogra> there is still a control.in
<thom> just kill cdbs and be happy
<raphink> just pretending it s
<ogra> but no trace of anything that updates it
<raphink> thom: no :p
<raphink> cdbs is great when it's used properly
<raphink> :)
<ogra> thom, i dont want to redo libgd2 :P
<ogra> even i agree, cdbs should just die
<raphink> :p
<ogra> lol
<ogra> Build-Depends: @cdbs@, debhelper (>= 4), autotools-dev, d-shlibs (>> 0.23), libpng12-dev, libz-dev, libfreetype6-dev, libxpm-dev | xlibs-dev (<< 4.3.0), libx11-dev | xlibs-dev (<< 4.3.0), libxt-dev | xlibs-dev (<< 4.3.0), libjpeg62-dev, libfontconfig-dev
* seb128 kicks ogra
<ogra> its using control.in *only* for the cdbs build dep 
<seb128> ogra: you don't have any work to do instead of trolling?
<ogra> seb128, but but ... trolling is so much fun :P
<seb128> slacker
<ogra> heh
<tseng> i hate control.in
<ogra> seb128, want libgd2 ?
<seb128> no, thank you
<raphink> ogra: typical ;)
<seb128> but you would be already done with it if you didn't spend so much time trolling on IRC
<elektranox> is libfreetype6-dev defect in edgy?
<ogra> seb128, i just share the entertainment of this funny package
<raphink> ogra: what package is that?
<seb128> ogra: looks like a borring trolling tentative to me
<ogra> raphink, lingd2
<raphink> ok
<ogra> *lib
* raphink gets back to cfengine hacking
<Mithrandir> elektranox: not once the publisher runs.
<Mithrandir> elektranox: so yes, at the moment.  In an hour, no.
<elektranox> ah ok thx
<dholbach> thom: pffft :)
<hunger>  /join #kubuntu-devel
<hunger> X broke?
<hunger> Damn... I should better not log out then.
<ogra> hunger, you should better not use edgy then ;)
<hunger> ogra: I *MUST* use edgy!
<ogra> heh
<hunger> ogra: My package-addiction drives me;-)
<hunger> ogra: dapper just does not see enough updates to stick with it;-)
<ogra> well, edgy will break in intresting ways the next weeks :)
<hunger> ogra: I fully expect that.
<Mithrandir> hunger: I don't think we've actually _broken_ X yet.
<hunger> ogra: If it does I can always use the suse box at work.
<hunger> Mithrandir: I was responding to someone on #kubuntu-devel. I have not yet run into trouble myself.
<fabbione> hunger: no X is still all in one piece. the fun will begin next week
<hunger> Mithrandir: Well, I was trying to respond on #kubuntu-devel.
<fabbione> breaking the server and fonts
<hunger> fabbione: What are you planning to do?
<Mithrandir> hunger: sync with Debian
<fabbione> hunger: what Mithrandir said
<hunger> fabbione: at least one font package has a broken postinst already. I guess that is to get people used to the hard times ahead;-)
<hunger> fabbione: Mithrandir said you are going to break X. I do hope that is not the complete plan;-)
<Mithrandir> hunger: we're going to fix it too.  Eventually.
* gnomefreak makes mental note dont expect X to work nextweek
<bddebian> Morning folks
<gnomefreak> morning bddebian 
<bddebian> Hi gnomefreak
<fabbione> hunger: Mithrandir didn't say i am going to break X. I said that next week the fun begins
<Keybuk> fabbione: any time next week would be fine :)
<fabbione> Keybuk: ok perfect thanks :)
<Keybuk> fabbione: I don't know anything about asterisk and modems, sound cards, etc. though
<Keybuk> I have a hardphone that talks SIP to it
<fabbione> Keybuk: no i don't need modems or sound cards. I have ekiga clients and i want to set it up as gw/voice mail or something like that
<Keybuk> *nods*
<fabbione> iirc it can do also proxy for nat traversal and that would be good to
<fabbione> basically i don't want to end up with 20 ekiga account 
<fabbione> but get asterisk to do all the job for me as you can imagine
<Keybuk> right, you can get asterisk to register with all the accounts, and then just route them all into one place
<sivang> Keybuk: have you had a chance to review make-free-space-wizard specification?
<Keybuk> sivang: nope, none
<Keybuk> I'm concentrating only on stuff I need to get done today I'm afraid
<bddebian> OK damnit, I was trying to "help" with X merges and now the ones I looked at last night are all uploaded already .. :-(
<sivang> Keybuk: I see, is there anyone else who can review it? mdz said that you'll have to do it since you had comments...
<Keybuk> I will do it on monday
<sivang> Keybuk: okay, is it okay dead line wise? :)
<sivang> (that it'd be on monday)
<Keybuk> sivang: you're already passed the deadline
<sivang> Keybuk: I know, let's hope to close it down on monday then.
* sivang continues to clean it up, and polish
<sivang> hmm, how do one chooses to show diff between two arbitrary revisions in Moin?
<shawarma> sivang: https://wiki.ubuntu.com/Pagename?action=diff&rev2=57&rev1=22
<shawarma> Adjust pagename, rev2, and rev1 accordingly.
<sivang> shawarma: thanks , it seems to be missing from the top menu
<zul> hi
<shawarma> sivang: No, it's there alright.
<shawarma> sivang: It speaks Danish to me, so I can't tell you the name of the link, but it's the third from the left.
<fabbione> shawarma: change your lang is an option.. Danish isn't sane anyway
<shawarma> fabbione: Ah, so it is. My browser is configured for Danish so it just went with that.
<shawarma> fabbione: it takes forever to save the new preferences, though. It's been about a minute now, and it's still not done.
<sivang> fabbione: heh
<sivang> fabbione: is it boiling hot for you as well?
<Kamion> hunger: the font packages' postinsts are only broken because some people synced/merged them in the wrong order; they'll get fixed automatically and in the meantime should be left alone
<shawarma> Wow. three minutes to save my preferences on the wiki.
<fabbione> shawarma: eheh no idea for the pref ... really
<fabbione> sivang: i am always boiling hot
<sivang> fabbione: right, I should have know :p
<fabbione> sivang: it's part of being italian
<mdke> shawarma: the wiki in general is extremely slow
<pygi> sivang, poke? :)
<mdke> sivang: it's behind "info"
<ogra> knopper, ping
<ogra> Mithrandir, the comments about unionfs on https://wiki.ubuntu.com/LiveCDShareThisCD dont really sound encouraging
<iwj> Re the X merge: we're adopting the new paths from Debian wholesale, right ?
<sivang> mdke: thanks
<Gloubiboulga> dholbach, could you upload goffice if the merge is correct? it'll be easier to test gnumeric then
<dholbach> Gloubiboulga: right, looking at it now
<Kamion> iwj: I believe that's the current plan, possibly with the odd compatibility symlink.
<iwj> Right.
<Gloubiboulga> thanks dholbach 
<iwj> Oh, the soyuz "it depends on which ftp session the file arrived in" bug ate my gs-gpl upload.
* iwj reuploads it.
<iwj> That's annoying because it means I have to repush the 9.5Mb .orig.tar.gz.
<sivang> pygi: pong
<sivang> pygi: 'sup?
<pygi> sivang, now I forgot !!!
<pygi> o right, the ideas on how to calculate..
<pygi> you got any? :)
<sivang> pygi: I've put them on the wiki page, let me know what you think
<sivang> pygi: (this is to address one of Keybuk's comments)
<sivang> pygi: wiki page = SystemCleanUpTool
<sivang> pygi_: lost network ? :)
<HiddenWolf> sivang: you really should get a better name for that
<pygi_> sivang, yes, AGAIN!!!
<pygi_> I am going insane, and starting to think of starting my own ISP :P
<pygi> sivang, will check spec  in a bit
<iwj> Who is responsible for xfonts-utils and perhaps a corresponding change to debhelper ?  My merged gsfonts-x11 has a debhelper-generated call to update-fonts-dir which uses an unknown option --x11r7-layout.
<iwj> For that matter, why is xfonts-utils not in the mom output ?
<iwj> (Source: xfonts-core)
<sivang> pygi: sure thing
<pygi> sivang, also check pm, please ^_^
<sivang> HiddenWolf: better name for what?
<HiddenWolf> sivang: scut
<sivang> HiddenWolf: ah, why not? does this have some nasty meaning in English ? :-)
<HiddenWolf> Scuttle \Scut"tle\, v. i. [For scuddle, fr. scud.] 
<HiddenWolf>    To run with affected precipitation; to hurry; to bustle; to
<HiddenWolf>    scuddle.
<HiddenWolf>    [1913 Webster] 
<HiddenWolf> It's a tad close. :)
<sivang> cut \Scut\, n. [Cf. Icel. skott a fox's tail. [root]  159.] 
<sivang>    [Obs.] 
<sivang>    The tail of a hare, or of a deer, or other animal whose tail
<sivang>    is short, esp. when carried erect; hence, sometimes, the
<sivang>    animal itself. "He ran like a scut." --Skelton.
<sivang> HiddenWolf: seems reasonable unless I'm missing something :-) 
<HiddenWolf> scut
<HiddenWolf>      n : a short erect tail
<HiddenWolf> :P
<sivang> does anyone else have reservations about it? it's really nice for the acronym :p
<pygi> sivang, pm please ^_^
<beezly> elmo: did you get my /msg ok? i was suffering some irc client insanity earlier :(
<wasabi> ZeroConf in Ubuntu Edgy... the most horrible thread ever. It just keeps going and going.
<ogra> iwj, its not merged yet see http://people.ubuntu.com/~fabbione/x-pkgs
<bddebian> wasabi: Amen
<ogra> first the libs have to go
<sivang> wasabi: I'm already CTRL-Ting instinctively in mutt
<sivang> pygi: I can't see anything from PM from you
<sivang> :-(
<wasabi> I like the suggestion to forward all packages to userspace with QUEUE, and have a userspace daemon say yes or no.
<wasabi> s/packages/packets/
<Kamion> iwj: xfonts-utils is yet to be merged, as ogra says
<Kamion> iwj: please defer merging gsfonts-x11 until that's done
<pygi> sivang, ah, are you registered
<sivang> Riddell: do you mind that I do dput ? still only minor control file merge to fix python version it depends on.
<sivang> I didn't realize I was not registered, sorry PM me again now
<Riddell> sivang: go ahead
<Kamion> iwj: xfonts-utils isn't in the MOM output because it's a new package in Debian as far as MOM is concerned (source package name changed)
<sivang> Riddell: thanks
<Kamion> doko: oh, freetype has built everywhere now, please go ahead and upload fontconfig
<doko> Kamion: already seen and uploaded
<Kamion> thanks
<bddebian> Heya LaserJock
<LaserJock> hi bddebian 
<pitti> Kamion: can you please approve my libgnomecups upload to dapper-updates? mdz approved it in bug 45406
<Ubugtu> Malone bug 45406 in libgnomecups "memory leak in gnome-cups-icon" [Unknown,Fix released]  http://launchpad.net/bugs/45406
<Kamion> pitti: done
<pitti> merci
<iwj> Kamion: defer> Roger.
<siretart> is this something to worry about? http://paste.ubuntu-nl.org/17427
* pygi points: bug #52243
<Ubugtu> Malone bug 52243 in Ubuntu "Please sync bonfire from debian, there is no ubuntu version yet." [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52243
<dholbach> pygi: if there's no ubuntu version yet, it will get done automatically and then will sit in NEW for a while
<Kamion> pygi: I already saw it thanks
<Kamion> and as dholbach says, it's not necessary in general, unless there's some urgency
<pygi> no urgency, no worries ^_^
<sivang> Kamion: It's my mistake, I reported the bug I was not aware we are auto syncing new stuff from debian
<Kamion> don't worry about it, it's not a problem, just saying you don't need to
<bddebian> Oh sure yell at me and be all sweet to sivang :-)
<Kamion> when did I yell at you for a sync request?
<iwj> pygi: Oh, what did you want to talk to me about yesterday ?
<pygi> iwj, doesn't matter anymore, but thanks for remembering ^_^
<iwj> NP
<bddebian> Kamion: I was kidding :)
<Yagisan> mako: thanks for signing my key from UDU (0x42E2C1E5), I thought you forgot as it was so long ago. Unfortunately I no longer have access to that key. Hopefully next time we meet you can sign my new one.
<pitti> slomo: ping?
<slomo> pitti: pong
<pitti> slomo: libgdiplus is weird - it has no soname, no -dev package, and does not ship any .h files - what the hell is that? 
<pitti> slomo: oh, I led, it has soname 0, but the package name does not
<pitti> s/led/lied/
<slomo> pitti: it's only used by mono... mono invokes the exported functions and doesn't need any headers or something else for it
<pitti> uh
* pitti doesn't quite like the idea of omitting the soname
<jsgotangco> Yagisan: hehehe right, he did a massive keysign it seems, i got mine too
<pitti> well, that can be fixed once it changes
<pitti> slomo: btw, did you have any enlightenment about the ppc segfault?
<slomo> pitti: it will probably never change... it's like any other "private" libraries only that it is released separate
<slomo> not really... i'm still at the libgcc_s/libpthread backtrace :(
<Kamion> next time Keybuk appears, somebody tell him he gets to handle NEW for the weekend - I'm off camping/beer-festival-ing shortly
<bddebian> Heey, where's my beer?
<slomo> pitti: but i can reproduce it as often as i want now ;)
<Kamion> there's a certain amount of stuff in the queue but I think nothing earth-shattering
<pitti> slomo: and rebuilding gcc-4.1 without ssp helps?
<pitti> Kamion: maybe you can acknowledge the cupsys upload to dapper-security? if not, I ask mdz once he wakes up
<slomo> pitti: downgrading to the version that doesn't use ssp helps... i don't really want to rebuild gcc ;)
<bddebian> Heya mdz
<pitti> hi mdz 
<ogra> hey mdz 
<slomo> hi mdke 
<slomo> s/mdke/mdz/ :)
<pitti> dholbach, slomo: there, all your stuff approved
<mdz> morning
<dholbach> pitti: thanks so much
<dholbach> pitti: after a massive give back, it should be all happy
<dholbach> morning mdz
<slomo> pitti: thanks :) btw, you could try liferea 1.0.16 on your amd64 with gtkhtml... it should've fixed the crasher and you can approve it too then ;)
<pitti> hey sabdfl
<sivang> hi sabdfl 
<bddebian> Heya dholbach, sabdfl
<dholbach> hi bddebian
<dholbach> hi sabdfl
<jsgotangco> hey dholbach hey sabdfl
<jsgotangco> heh
<ogra> hi sabdfl 
<Kamion> pitti: err ... I'd rather mdz did that
<Kamion> or at least said it's ok
<pitti> Kamion: he ok'ed it yesterday, but nevermind, he's here now :)
<pitti> Kamion: happy beer drinking
<nix4me> pitti, when might that new libgnomecups fix hit the repositories?
<pitti> nix4me: give it a few hours
<nix4me> ok, thanks.
<Kamion> mdz: would appreciate if you did cupsys, I need to run soon and don't have time to sanity-check right now
<mdz> Kamion: did it before you mentioned it
<Kamion> ok, cool
<mdz> pitti: is libgnomecups done already?  you said in the bug you were uploading it, but it's not in the queue
<mdz> ah, I just received colin's followup to the bug
<sivang> slomo: can you see my PMs ?
<pitti> mdz: yep
<slomo> sivang: yes, answered it already ;)
<pitti> mdz: the only thing left in the ack pipe for you is pmount bug 49655
<Ubugtu> Malone bug 49655 in pmount "could not compile regex" [Medium,Fix committed]  http://launchpad.net/bugs/49655
<sivang> mdz: Keybuk noted he would be able to review SystemCleanUpTool only on monday, is it okay? if not, I'm keen to work on any comments you might have today.
<mdz> pitti: what about 51038?
<pitti> bug 51038
<Ubugtu> Malone bug 51038 in dovecot "sub-folders disappear on upgrade from breezy to dapper" [High,Fix committed]  http://launchpad.net/bugs/51038
<pitti> mdz: oh, right, that too :)
<mdz> pitti: both acked
* pitti uploads, thanks
<pitti> mdz: can you please nudge these two uploads through the queue?
<mako> Yagisan: hah :)
<kdefreak> when was deadline for suggesting new packages/versions?
<mako> Yagisan: i had what had grown into a rather large pile
<Yagisan> mako: nice. If/When your next in Sydney we can meet again
<Yagisan> alternatively hope I win lotto and I'll see you at the next Ubuntu conference.
<mako> Yagisan: do you play the lotto?
<Yagisan> on occasion.
<mako> well, then at least it's a non-zero chance
<Yagisan> although my chances are astronomically small.
<mako> that's right
<mako> i own a book on how to win the lotto
<Yagisan> run the machines and sell your own tickets
<mako> that would have been a much more useful book than the one i own
<mako> this one was incorrect
<Yagisan> heh, blackjack and a good memory can get some money. Pity I have neither a good memory, or rain man.
<jsgotangco> lol
<sladen> Yagisan: you could always hitch to the next Ubuntu conference
<jsgotangco> there's a lotto outlet just in front of my house
<Yagisan> sladen: which is where ?
<sladen> Yagisan: well, hitch to where ever it is
<jsgotangco> hitch on a plane?
* Yagisan ponders the difficulties of hitching a ride off an isolated continent. makes note to pack flippers and lifejacket
<mdz> pitti: done
<pitti> thanks
<jdub> mdz: might've missed a response
<jdub> boh
<jdub> mdz: did you get my last messages?
<mdz> jdub: no
<jdub> mdz: who is our scim point person?
<mdz> jdub: mvo is probably most familiar with it, though none of us are experts
<jdub> there's a meeting about xkb, gnome and i18n issues (particularly related to keyboard configuration) coming up in an hour and a half
<mdz> unfortunate timing
<mdz> it's friday evening for europe
<jdub> yeah :|
<fabbione> jdub: try to text Mithrandir ?
<fabbione> he knows about keyboard config stuff
<fabbione> perhaps he can partecipate
<jdub> dholbach: ping
<dholbach> jdub: pong
<jdub> dholbach: hey - do you happen to have a rebuilt ekiga deb lying around?
<dholbach> you're so lazy
<dholbach> lemme have a look
<ogra> i just tried to build on ppc
<dholbach> i386?
<ogra> :(
<jdub> dholbach: yeah
<jdub> dholbach: i would have to download a lot and fix things up afterward due to depends b0rk :)
<dholbach> suuuure :-p
<ogra> yeah, libgnomeui-dev is still not built ...
<ogra> it seems
<dholbach> jdub, ogra: building it on i386
<ogra> i have no i386 around :( ... all packed in boxes
<dholbach> i can't build you a powerpc deb sorry
<ogra> i know
<dholbach> the memory in my powerpc box is broken
<dholbach> i ordered new one and it doesn't seem to take 512 mb bars
<dholbach> GAR
<ogra> if it would be only libgnomeui i'd do it myself, but i suspect its the whole rest of the stack
<dholbach> so don't mention powerpc fuckup to me
<ogra> since when do you have a ppc ? 
<ogra> you didnt tell :)
<dholbach> a very old one, 2 months ago
<dholbach> just good enough to testbuild stuff or run xubuntu
<ogra> yep
<dholbach> jdub: http://daniel.holba.ch/temp/
<bddebian> Later folks
<dholbach> jdub_: http://daniel.holba.ch/temp/
<jdub_> dholbach: thanks!
<dholbach> de rien
<pygi> jdub, what exactly would this mean: "Need travel assistance? " on that submit paper thingie? :)
<jdub> pygi: if you think you'll need financial assistance to get to lca
* jdub adds that to his list of things to clarify
<pygi> jdub, oki, thanks ^_^
<jdub> dholbach: heh, didn't avoid the evolution-exchange/ubuntu-desktop b0rk after all ;)
<dholbach> shit happens, hm? :)
<jdub> EDGY LOVES US!
<zul> ill hug and pet him and take care of him and call him george
* pygi should probably submit an article on "Diva - Video editing" or something :)
<ivoks> i think my laptop battery just died :/
<Burgwork> pygi, why not talk about pitivi?
<pygi> Burgwork, because I work on DIva development? :P
<pygi> what's wrong with Diva? :)
<elektranox> mh can anyone repair the libfreetype6-dev package? It has wrong dependencies: libfreetype6 ( = 2.1.10-1ubuntu2 )instead of  ( = 2.1.10-1ubuntu2.1)
<Burgwork> nothing, but pitivi actually has a release out
<pygi> Burgwork, hm, Diva also has a release? :)
<Burgwork> not packaged
<pygi> that's true, but it will be as soon as 0.0.3 is out
<sivang> pygi: you are going to lca ? :)
<pygi> sivang, might happen, but very unlikely
<Mithrandir> elektranox: no, it doesn't.  Freetype in edgy is 2.2.1-2.
<pygi> sivang, why you ask? :P
<LaserJock> hmm, if a Debian package has moved from main to non-free will it correspondingly go from Universe to Multiverse?
<LaserJock> or do I need to poke ubuntu-archive
<sivang> pygi: no special reason, I know it's very esteemed conference and people say they've enjoyed there. I would like to visit it someday
<pygi> ok, please register with freenode so you could see my pm' :P
<sivang> (we have lci but last time it happened I was too busy with work to attend, and I'm sure it's not near close to lca ;-) by terms of size, upstream people you get to meet, etc)
<elektranox> Mithrandir: I've installed "2.1.10-1ubuntu2.1" and apt-get install libfreetype6 says that there are no newer packages
<elektranox> Mithrandir: http://packages.ubuntu.com/cgi-bin/search_packages.pl?keywords=libfreetype6&searchon=names&subword=1&version=edgy&release=all
<Amaranth> elektranox: reenable dapper-updates
<Mithrandir> elektranox: https://launchpad.net/distros/ubuntu/+source/freetype/2.2.1-2 claims to disagree with you.  Which mirror are you using?
<Amaranth> elektranox: you got your freetype from there
<elektranox> I use the german one
<elektranox> deb http://de.archive.ubuntu.com/ubuntu/ edgy main restricted
<ogra>  well, looks out of sync
<AlinuxOS> mjg59, ping
<mjg59> AlinuxOS: Hi
<ogra> http://de.archive.ubuntu.com/ubuntu/pool/main/f/freetype/ has differnt content from http://archive.ubuntu.com/ubuntu/pool/main/f/freetype/
<mjg59> AlinuxOS: I'm just about to go out - what's up?
<AlinuxOS> mjg59, no nothing I'll ping you later so
<AlinuxOS> or tommorow
<AlinuxOS> ;)
<AlinuxOS> mjg59, have some news about ttf-bpg-georgian-fonts.
<mjg59> AlinuxOS: Cool. Tomorrow is good
<jdub> mjg59: when i think about you, i touch myself.
<LaserJock> yikes
<rleigh> siretart: The version of schroot you packaged last week had an unintentional dchroot option parsing regression.  Please could you update to 0.99.2-2?
<siretart> rleigh: thanks for notice, will remerge it
<rleigh> Also, the config.guess in ubuntu appears to be 10 months out of date.  It's not often you see a patch reverting things! http://patches.ubuntu.com/s/schroot/schroot_0.99.0-1ubuntu1.patch
<siretart> holla!
<rleigh> siretart: 0.99.2-1 is in unstable; 0.99.2-2 will enter incoming in a few minutes (this is just a hppa-specific testsuite fix, so if ubuntu doesn't support hppa, 0.99.2-1 is just fine).
<siretart> rleigh: there is an ubuntu hppa port, so I will merge it tomorrow, ok?
<rleigh> siretart: Cool, thanks!
<siretart> rleigh: btw, you don't happen to have a public VCS for schroot?
<rleigh> siretart: Yes.  svn://svn.debian.org/svn/buildd-tools/trunk/schroot  The releases are all tagged under buildd-tools/tags.
<siretart> rleigh: cool. will look into this tomorrow.
<shaya> mdz: my bug descriptions aren't good enough for you? hmph. :)
<dieman> is there a timeframe on firefox for -security on breezy/hoary?
<tseng> "when it is done"
<dieman> hrm
<tseng> updating firefox is a huge challenge
<dieman> i thought backporting had been agreed upon
<dieman> anyhow, if its delayed, I'll just take care of it from my end
<Mithrandir> mdz: is it on purpose you're not in #canonical?
<LaserJock> Mithrandir: he must be hiding ;-)
<mdz> Mithrandir: xchat has forgotten how to auto-join me there
<mdz> and I've been rebooting today
<HiddenWolf> Can someone with a clue toss some weight around on the zeroconf thread?
<HiddenWolf> It's getting repetitive
<jdub> i recommend changing the subject to "end of thread" and... ;)
<shaya> btw, has anyone had problems w/ edgy's aptitude lately, or is it just me?
<HiddenWolf> jdub: how about a message "this is a policy decision, let's put it up in front of the technical board?"
<simira> shaya: it's just you
* shaya watches aptitude _slowly_ "initialize package states"
<jdub> HiddenWolf: yeah
<sharms> is there a schedule on the wiki about an updated dapper iso release?
<tseng> I dont think we have ever done an updated iso release
<tseng> there is only 6 months between releases
<tseng> this is out first "LTS"
<tseng> the wiki has a search feature btw
<sharms> Just didn't know if there was going to be a "service" release since certain ppc users cannot use dapper without installing breezy, searched and didn't see thats why I asked
<gnomefreak> tseng: i thought it was talked about do to the desktop-cd problems
<Burgwork> afaik, there is a plan to reroll dapper around when edgy comes out
<Burgwork> a "service pack 1" if you will
* gnomefreak doesnt see why people dont just get alternative cd (although the 25cds i got from shipit dont work) but hence the alter.
<rleigh> siretart: While getting changes from the schroot SVN is fine, I would not recommend packaging it directly.  It needs bootstrapping with a development version of gettext, so I would prefer the release tarballs be used (which have been thoroughly tested by me, so are known to be good).
#ubuntu-devel 2006-07-08
<DaveTheAve> Can anyone please help a fellow with a simple bash script problem? The script is at: http://pastebin.ca/81888 I would have used pastbin.com but they seem to be offline.
<BenC> anyone know how to keep inetd from invoking programs with ipv6 protocol (like tftp)?
<Mez> BenC - remove the ipv6 kernel module ? :P
<BenC> I just ran tftpd standalone
<Mez> lol
<devscott> Hi, I was wondering if I could get an extra pair of eyes on some C++ code. I just want to know if I'm setting my termios flags correctly. http://cpp.sourceforge.net/?show=17507
<wasabi> Is anybody packaging flumotion?
<wasabi> Hmm. Seems like Debian version is fairly recent.
<ogra_> mdz, you dont happen to be still awake i guess
<Burgundavia> morning ogra_
<monomaniacpat> does anyone here know what driver version the xpad module is that came with dapper?
<crimsun> * X-Box gamepad - v0.0.5
<crimsun> or if you want the define, #define DRIVER_VERSION "v0.0.5"
<crimsun> http://www.kernel.org/git/?p=linux/kernel/git/bcollins/ubuntu-dapper.git;a=blob;h=43112f040b6de336bf9b2e3428aa3b49e44c115f;hb=2a96c68fa3ac71c1211f1eb1db5045e3f15ba296;f=drivers/usb/input/xpad.c
<Hobbsee> hi all
<monomaniacpat> crimsun: thank you very much
<crimsun> np
<\sh> moins
<mdz> ogra_: I do
<ogra_> mdz, am i not clear enough in the SCP spec that there is no server client architecture ?
<mdz> ogra_: how can that be?
<ogra_> it all runs locally on the server
<ogra_> your comment sounded like i would build an SCP server and an SCP client app
<ogra_> in facct there is only an additional dbus listener i can access in the users session, not more 
<ogra_> i'm fine to rewrite it, i was just wondering what made you think there would be an SCP server
<mdz> ogra_: if there is no client/server communication, why do you use dbus?
<mdz> there must be something on the other end
<ogra_> because i need to acess the users session ... preferably as the user, which dbus makes possible
<ogra_> since the session dbus runs as the user in his/her session
<mdz> ogra_: you need to access it from where?
<ogra_> so i only connect to that and send a message to execute ap X
<mdz> there must be more than one entity here if you need to communicate between them
<ogra_> from the SCP gui ...
<mdz> gui = client
<mdz> bit which runs in the user's session = server
<ogra_> sure, there is the GUI thats the frontend to the session dbus listener
<ogra_> ok, then i misunderstood your comment :)
<\sh> hmm...who is working on the NEW queue?
<ogra_> indeed the listener is the server 
<ogra_> \sh, ubuntu-archive
<ogra_> mdz, i'm clear then, thanks ... get some sleep man ...
* ogra_ wonders why his ekiga only runs for some minutes before it just gets quiet ...
* sivang notes the new fonts in edgy rock
<sivang> (looks much better on a laptop)
<sivang> err, LCD screens , that is
<pygi> sivang, !!!!
<slomo_> sivang: err? you mean the new fonts in gnome-terminal and firefox? i don't like them, they're far too blury for my taste ;)
<\sh> working on weekends doesn't make sense, but gives more money, oh joy
<sivang> slomo_: I'm using 1400x1050 , nothing is blury for me :)
<sivang> slomo_: the previous ones were becoming hard to notice , and the new in firefox makes web site alot more readable for me ;)
<ogra> hmm, mom seems not to update anymore ... gartoon was synced yesterday and built fine but still shows on the list
<\sh> ogra: same here.
<Hobbsee> ogra: same here too.  how annoying.
<ogra> well, i doubt Keybuk will fix it today :)
<\sh> ogra: and the sync of python-qt4 is somehow in NEW, because no ACCEPTED mail 
<ogra> yep, its in the NEW queue
<\sh> how can I see the NEW queue via LP?
<ogra> dunno if you can, try it
<ogra> https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=0&queue_text=python-qt4
<\sh> cool works :)
<HiddenWolf> ogra: it seems everyone can see that. :)
<ogra> HiddenWolf, then its fine, i wasnt sure if it was limited to -core-dev
<HiddenWolf> ogra: I can see it, i'm not in any teams
<webben> Where is sudo supposed to get its PATH from? /etc/environment?
<webben> And if so, is there a bug with this? It's not working on my machine. And it looks like others are having the same problem: http://ubuntuforums.org/showthread.php?t=203414&page=2
<gnomefreak> webben: this is not a support channel of any kind
<webben> gnomefreak: oh well, thanks
<imbrandon> webben, for future ref though sudo uses the env / path from the user running it 
<imbrandon> but dont ask support in here
<webben> imbrandon: that's what i thought it was supposed to do (even though it's not for me) : thanks :)
<Chipzz> *ugh*
<Chipzz> what an upgrade mess in edgy currently :P
<mhb> hello everyone
<highvoltage> hello
<mhb> me and some other folks from #ubuntu-artwork are using Inkscape for vector graphics (after all, it's one of the best FLOSS vector editors) ...
<mhb> a new version came out (after Dapper upstream freeze), 0.44 ... Edgy upstream freeze will be very, very soon and there's no sign of the new Inkscape version
<mhb> https://launchpad.net/distros/ubuntu/edgy/i386/inkscape/ (for example) shows 0.43-4ubuntu3
<ivoks> mhb: i wouldn't worry
<ivoks> mhb: i'm sure it will get in
<mhb> who's responsible for putting new versions in?
<mhb> he should be aware of that before the upstream version freeze, you know ...
<mhb> should I send an email to someone?
<ivoks> no, cause there is no single person that does inkscape uploads in ubuntu
<mikearthur> Is it safe to mount /var/ as noexec with ubuntu?
<mhb> ivoks: well ... if it is automated and the deadline is in 5 days or so, how can I be so sure it gets in? (I know I'm a bit paranoid, but the new features and fixes in 0.44 are worth it :o)
<mikearthur> not a support question, just thought you guys would actually know this, before my machine explodes
<ivoks> mhb: well, i'm sure no one will do it today or tomorrow
<wasabi> mikearthur: Check if there are any +x binaries in it...
<wasabi> If not, apparently. ;)
<mikearthur> wasabi: whats an easy was of doing that?
<neuralis> mikearthur: find -perm..
<neuralis> ivoks: 'morning
<mikearthur> n1
<mhb> ivoks: what does that mean?
<ivoks> neuralis: 'evening :)
<mhb> ivoks: that it will/won't get included with Edgy?
<ivoks> mhb: it's weekend :)
<ivoks> mhb: weekend like "two days in week when people don't work, but spend their time with those they love"
<ivoks> neuralis: how are you?
<mhb> ivoks: emails arrive even on weekends :o)
<neuralis> ivoks: busy, a bit tired still. you?
<ptlo> neuralis: 'sup
<neuralis> hey ptlo
<ivoks> neuralis: preaparing some exams and then planing to take some seriuos vacation before some major changes in autum...
<neuralis> ptlo, ivoks: i ended up having to leave a lot earlier than i planned; sorry for not being able to meet up :/
<ivoks> neuralis: np, i didn't even know you were here
<neuralis> ivoks: about a month ago.
<ptlo> neuralis: yah, shame, but understandable (i had to do 100 of things also :), i hope you're visiting again soon
<neuralis> ptlo: i'll let you guys know. possibly decemberish, if i end up with any time away from the office.
<ptlo> ivoks: btw "weekend" usually means "two days in a week when people don't work, but spend their time hacking, at the expense of those they love" :-)
<ivoks> ptlo: :)
<sivang> ptlo: that depends who much they want to keep those they love with them :)
<ivoks> now we know why ptlo is single :)
* ivoks dodges...
<ptlo> sivang: its a delicate line :)
<neuralis> okay, kids. development channel, and all that jazz. 
<sivang> heh, right
<ptlo> that's a cue for me, cya later guys :)
<ivoks> ok, anyone interested in fullfiling mhb's whish?
<ivoks> there is inkscape 0.44 in sid
<sivang> ivoks: is inkspace in main?
<ivoks> yes
<sivang> icah, then better find a main uploader ;)
<ivoks> hehe
<ivoks> weekend :)
<sivang> indeed
<ivoks> well, time to leave you
<ivoks> see you, bye
* sivang goes back to the weekend
<neuralis> sivang: i wanted to chat about backup a bit at some point, but that's completely non-urgent
<mhb> so ... should I "inform" you again on Monday?
<sivang> neuralis: oh, pleae be my guest and feel free to email me, ping on irc etc, when I less away etc :)
<sivang> neuralis: but email does work on weekend :)
<neuralis> sivang: okay, that's fine.
<bddebian> Heya folks
<pygi> sivang, poke, altought you are not around :)
<bddebian> heh
<pygi> bddebian, what? :P
<bddebian> pygi: what, what? :-)
<pygi> bddebian, I am going insane ... the access to pyburn library is restricted !!!
<bddebian> Restricted?
<pygi> bddebian, the tarball is located on ftp which is protected by username and password
<bddebian> Oohh
<pygi> that means we have to write libburn bindings
<bddebian> I'll take your word for it :-)
#ubuntu-devel 2006-07-09
<zul> i know this might be a long shot but mdz ping
<mdz> zul: pong
<zul> mdz; should the quieten grub be turned on by default when the user runs update-grub?
<mdz> zul: yes; it should be the default for the standard boot (though not for recovery)
<zul> ok
<mdz> I
<mdz> I believe update-grub already has variables set up for that
<mdz> default options for standard and recovery mode boots
<zul> correct..i just have to add quiet to it
<floam> I seem to be terrible at manipulating this wiki -- is edgy targeting 2.6.18?
<zul> no
<floam> so it's still going to be using 2.16.17 upon release? 
<floam> errr
<neuralis> yes.
<floam> 2.6.17
<floam> yikes. I wonder why that changed, I thought originally they planned on aiming at .18
<floam> guess I'll get to maintain my own kernel for another iteration
<Hobbsee> floam: no, they were never aiming for .18
<floam> Hobbsee: are you sure? I know I heard something about .18 six months ago or so.
<floam> maybe it was someone who had no idea what's going on.
<Hobbsee> floam: likely off the forums, yeah.  they still swear that .18 will get in.
<floam> no, I don't read forums :P
<floam> I think it was in bugzilla/launchpad somewhere
<Hobbsee> or off someone who had read the forums
<Hobbsee> that too - a wishlist.
<floam> that could be, web forums are really good at spreading false information
<zul> very
<floam> normally I couldn't care less about the kernel, but my poor little serial ata dvd burner needs special love that supposedly come with it.
<neuralis> i never quite got that; the forums exert zero actual direct influence, but seem to be sufficiently large and self-contained that they go on, pretending this just isn't so.
<floam> s/come/comes/
<sharms> can someone explain why 2.6.18 would not be included if the kernel freeze isn't til october? https://wiki.ubuntu.com/EdgyReleaseSchedule
<floam> neuralis: thank your deity it can't exert force
<neuralis> floam: clearly.
<floam> at least it functions as a good playpen
<Hobbsee> neuralis: yeah, that's true.  it is kinda useful if you're looking to see how edgy is running at the moment.
<Hobbsee> sharms: because UVF is on the 13th.
<Hobbsee> after the 13th, you get 2.6.17-x-* changes only
<floam> 13th of which month?
<sharms> July
<Hobbsee> floam: this one
<floam> wow, that feels early
<floam> is this release iteration shorter than dapper was?
<floam> (when is it supposed to come out?)
<Hobbsee> floam: yes, it's half the time.
<jono> jdub, ping
<neuralis> Hobbsee: i find the forums perfectly useful, in that they've kept 133733 people from posting 1226284 messages to -devel.
<floam> okay, then it makes perfect sense that they wouldn't use 2.6.18
<Hobbsee> neuralis: hehe, that's true also
<floam> I thought there was twice as much time as there is
* Hobbsee just wishes they would file bugs.  and not crack howtos.
<floam> worse than the howtos are their little patented fixer scripts
<neuralis> haha. the horror, the horror..
<Hobbsee> true, when then cause more bugs.
<sharms> I just install everything with --force
<floam> yes, plus they don't use apt at all, from what I've seen
<Hobbsee> actually, to be fair, i havent had trouble with the system bootup one - about stopping unneeded services
<floam> they have scripts that just wget crap, build it, overwrite installed stuff
<Hobbsee> (why is my laptop staring bluez-utils - i've got nothing even related to bluetooth on here - no bluetooth port, either!)
<floam> they distribute a script to remove sysv services there?
<Hobbsee> floam: not a script, it's manual.
<floam> couldn't they just tell you to how to alter the symlinks or install sysvconfig or something
<neuralis> floam: or, er, use update-rc.d, if you need to remove things?
<Hobbsee> "this process is this and does this, and is on default runlevels x, y, z, it is fine/is not fine to turn it off"
<Hobbsee> that type of idea
<floam> there's that too, I'm too lazy to figure out what the tool of the year is
<sharms> seems like a standard control panel for services under system->administration would be a good usability idea
<Hobbsee> sharms: write one :P
<sharms> I might, but if I do it's probably pygtk
<Hobbsee> so?
<floam> so it probably wouldn't get into main
<floam> (which sucks, I can't believe in 2006 people are still suffering with C/GObject)
<sharms> agreed
<floam> though GObject doesn't map very well into python's bindings either
<slomo> why wouldn't it get into main because of pygtk?
<slomo> gnome-app-install, language-selector, $whatever are pygtk too ;)
<sharms> I was thinking just the extra dependencies on a default install would be bad
<sharms> but maybe I was dropped on the head as a small child
<floam> are they? I thought people generally frowned upon it.
<floam> but maybe not. I was dropped on my head a decent number of times
<slomo> just take a look at the packages ;)
<floam> yes, you're correct
<Hobbsee> hi slomo 
<slomo> hi Hobbsee :)
* Hobbsee is off to work.
<Hobbsee> bye all!
<floam> sharms: apparently they aren't extra dependencies, it already comes with pygtk et al
<sharms> gotcha
<floam> when I take over the world I'm going to force gnome to stop using C, decide on C++ or Objective C, and then force some of my other slaves to write some decent bindings
<floam> a dictatorship is only bad when the dictator sucks
<floam> oh hell, maybe I'll force them to all work on GNUStep
<sharms> does anything stop me from just chopping up fedora/redhat's services manager?  It appears to be GPL
<neuralis> sharms: you know about services-admin, correct?
<floam> what's wrong with the one that's in dapper?
<floam> right, services-admin
<floam> it's clearly overly simplified, but you could fix that
<floam> since I can't really figure out what checking and unchecking does to the specific runlevels
<sharms> I am not seeing a way to deactively bluez through services-admin
<floam> it probably has a table of services it "knows about"
<floam> with icons and descriptions and whatnot.
<sharms> just seems ironic I can turn off klogd but not bluetooth :)
<floam> it shouldn't be too difficult to add the bluetooth stuff
<floam> (surely much easier than writing your own manager)
<sharms> what package is that a part of?
<floam> gnome system tools
<floam> gnome-system-tools, that is
<sharms> got it
<trulux> moin
<trulux> what's the current status of edgy for sparc64?
<trulux> do the current netboot images work out of the box?
<trulux> or it's recommended to use dapper instead?
<techmad> i dont think its recommended to use edgy for anything yet 
<techmad> so i would stick to dapper :)
<trulux> ok, thanks
<trulux> hmm
<trulux> does the server-type installation work out of the box with netboot?
<trulux> ex. used instead of desktop
<trulux> over there: http://www.ubuntuforums.org/showthread.php?t=185136&highlight=sparc
<trulux> they mention using a .seed file
<trulux> boot net preseed/url=http://192.168.1.20/ubuntu-server.seed
<trulux> any idea?
<techmad> do you want a desktop gui?
<trulux> in sparc64? hell, no
<trulux> hah
<techmad> i dont know much about out of the box with netboot you could ask over in #ubuntu
<trulux> let's check
<trulux> afaik most distro user-related channels are mad houses
<trulux> and answers range from the provoking-noobish to totally-rude
<trulux> anyways....
<trulux> :)
<sivang> morning all
<trulux> moin
<pitti> Hello
<jsgotangco> pitti: hi!
<sivang> hey pitti 
<slomo> hi pitti :)
<sivang> pitti: working on sunday or just checking emails as always :)
<pitti> hi jsgotangco 
<trulux> hey pitti
<tseng> hey trulux 
<trulux> hmm, latest dapper netboot image is halting in a Sun Netra X1
<trulux> tseng, how's life?
<tseng> trulux: good, you?
<tseng> I am fighting SSP atm
<tseng> maybe you saw, we turned it on everywhere after all
<trulux> tseng, I'm preparing a showcase for some win32/crossplatform stuff
<trulux> I didn't read about it
<trulux> isn't that kind of brave as Ubuntu has tons of multimedia-related stuff?
<tseng> if we build gcc (libgcc_s specifically) with ssp, it bombs building mono
<trulux> brb
<slomo> not only building mono
<trulux> yeah
<tseng> trulux: we'll see :)
<slomo> but running something with mono
<slomo> on ppc
<trulux> expect that for most applications that do strange stuff with runtime code generation
<tseng> slomo: does mono link in libgcc somehow?
<slomo> tseng: sure
<tseng> ok.
<trulux> fortunately in win2k sp4 I don't have such problems. all the 0days work
<tseng> hah!
<slomo> tseng: oh... no it doesn't
<trulux> it's awesome
<trulux> tseng, no, seriously
<trulux> tseng, if you ever knew a bit of what MS has done to XP and friends...
<slomo> tseng: hm i thought everything is using libgcc but for some reason mono doesn't even use it... so how can it segfault in libgcc then? =)
<tseng> slomo: no idea!
<tseng> not p/invoked?
<slomo> that would be insane
<tseng> it would..
<tseng> but its mono
<tseng> you know
<tseng> the JIT has ppc specific areas
<tseng> its per-arch
<tseng> could be in there (again)
<slomo> right... looking for libgcc on i386 isn't very useful then ;)
<slomo> one moment
<trulux> anyone knows about this sparc stuff?
<trulux> it's really a showstopper
<tseng> trulux: which stuff
<slomo> tseng: no, same on ppc... it doesn't like with libgcc directly
<tseng> it looks like the GC uses it
<tseng> from a grep
<slomo> right, i found something new btw ;)
<tseng> yes?
<slomo> i didn't tell you yet but the segfault happens on finalizing an object
<slomo> => GC is a good direction :)
<tseng> bingo?
<tseng> we could..
<trulux> tseng, the latest netboot image for sparc64, dapper
<tseng> try another GC backend
<tseng> or disable GC completely
<trulux> jesus, I must get bac to work out tomorrow
<tseng> trulux: ah. no idea.
<trulux> tseng, I may be an army guy soon ;P
<slomo> tseng: we could try linking with the system libgc instead of the internal one
<tseng> trulux: btw, I was near Barcelona last week
<slomo> tseng: because that works... inkscape works
<tseng> trulux: nice place
<tseng> slomo: sure
<tseng> slomo: miguel will kick and scream if you ship it though
<tseng> just for testing
<slomo> tseng: i'll try it now... thanks for the pointer to the obvious :)
<slomo> tseng: if he screams he should fix it instead :P
<tseng> slomo: go team mono!
<slomo> tseng: we use it for freebsd on debian already because mono's libgc is broken there
<tseng> huh
<tseng> big usebase :)
<tseng> user
<trulux> tseng, I see, well, I personally dislike Barcelona and mostly any place here, maybe because I live around rather than spending a holidays weekend :P
<tseng> trulux: not saying id like to move in for good :)
<tseng> its awfully hot
<trulux> and full of Spanish guys
<slomo> tseng: would be nice if the new GC will be default for 1.2... this way we don't need to ship the libgc copy anymore
<tseng> true
<tseng> but an all new GC is kind of scary
<tseng> on such short notice
<sivang> trulux: Barcelona is beautifull AFAIR, in what ways do you dislike it? :)
<trulux> tseng, I have relocation plans so far
<trulux> sivang, I don't like .es
<slomo> tseng: it's scary, yes... but at least the ideas and design seem to be very nice ;)
<sivang> trulux: hmm, could it be that we talked about it alreayd? :p
<tseng> slomo: we can test build it in 1.1.16
<tseng> slomo: for fun.
<trulux> sivang, sure, everyone who has met me once knows I'm a .es hater
<tseng> slomo: interesting
<tseng> slomo: mono-1.1..../docs/exceptions
<tseng> talks about the stack unwinding
<straycat> an advice for fans of linux distros: is there real significance in caring about new versions of a distro? it's mostly a face-lift of the FORM; if you really want to contribute to a public endeavor, join Wikipedia or MIT OCW; those are really about develoopment of useful CONTENT.
<tseng> and the use of libgcc
<Hobbsee> hi all
<trulux> BenC, you are one of the sparc guys right?
<slomo> tseng: could you paste the relevant part to a pastebin?
<tseng> slomo: ok.
<hunger> straycat: I like the contents already... it's the form that needs improvement.
<trulux> tseng, any other non-ssp plans on mind?
<tseng> trulux: finish merging mono stuff
<tseng> trulux: maybe poke a few gnome things.
<slomo> tseng: the F11->middle mouse button mapping is gone on latest edgy :(
<tseng> or you mean security wise?
<trulux> sec. wise
<tseng> i heard someone was looking at ASLR again
<tseng> I am only up on SSP
<tseng> because its biting me in the arse :P
<trulux> ASLR? it's now on vanilla kernel since many time ago...
<tseng> really.
<damo22> anyone tried patching ubuntu kernel source 2.6.15 to 2.6.15-rt9 with ingo's patch.... 
<damo22> ubuntu needs realtime preemption
<trulux> tseng, really to the ASLR thing?
<tseng> slomo: http://pastebin.ca/83160
<tseng> trulux: yes, I didnt know
<tseng> trulux: but im way out of kernels these days
<trulux> I wouldn't touch ASLR, really :)
<trulux> unless you want to break applications that Canonical allegedly supports
<trulux> ala DB2, etc
<trulux> even MySQL if you take it the hardcore way
<slomo> tseng: *compiling*
<tseng> slomo: woo.
<sivang> what's ASLR ?
<tseng> address space layout randomization
<tseng> does pretty much what it says.
<slomo> iirc they plan it for edgy+1... pitti?
<sivang> tseng: for data protection, that is ?
<tseng> sivang: yes.
<tseng> makes canned code injection and stuff like this harder
<sivang> tseng: cool, could be pribably applied for the good in GPGP
<trulux> guys, I'm getting pretty annoyed with this sparc thing
<tseng> its in the kernel
<trulux> I'll end putting Solaris
<trulux> :(
<tseng> trulux: it is sunday, most folks dont work
<sivang> tseng: ah, so everything is automatially protected and scrambled
<tseng> sivang: yes.
<Hobbsee> tseng: most :P
<Hobbsee> hi sivang 
<trulux> tseng, have you seen this? 8http://www.ubuntu.com/employment#head-ee181be4e2f101318f548b6e62a74711085e9224)
<trulux> I'm kidding on solaris
<tseng> trulux: yep.
<trulux> it's enough waste of space to keep one VM here with x86 solaris
<tseng> trulux: you've applied?
* sivang hugs Hobbsee 
<trulux> tseng, have you done so? I was going to let you know about it for applying)
<trulux> I sent a CV
<tseng> trulux: nope, I am very happy with my job
<tseng> and been out of this area for too long to be of any use
<trulux> hah
<trulux> I'm getting now more into datamining and win32 stuff
* Hobbsee hugs sivang 
<sivang> trulux: win32 ? :)
<trulux> I'm sick of software wars
<trulux> yeah
<trulux> tseng, I'm mostly making a living out of the 0day stuff
<sivang> 0day ?
<trulux> tseng, It's a bitchy ground because it sucks a lot of time for ensuring at leas a 2k check per month
<trulux> and you literally feel lost sometimes, as there's no established path of work
<tseng> yeah.
<trulux> so basically I try to blow up everythign else that falls in my hands
<trulux> I've made around 2k the past month
<trulux> some people don't like that such a business is growing
<trulux> Scanning disks... < here it hangs
<trulux> at 41%
<trulux> damn it
<trulux> http://www.ubuntuforums.org/archive/index.php/t-77190.html
<Fjodor> Anyone know of a bug where the machine reboots right after grub/lilo on a server install. Can't seem to find any?
<sivang> trulux: what th 0day bussiness?
<damo22> is ubuntu owned by canonical? canonical hires ppl to work on ubuntu?? 
<tseng> damo22: the second one
<trulux> sivang, selling information on undiscosed security flaws, generally in widely used products in the enterprise business
<tseng> canonical also owns all of the hosting/building hardware if you are a conspiracy theorist
<trulux> heh, indirectly Canonical owns Ubuntu
<trulux> without Canonical , it would be something else, and I bet the people being paid to work on it would do whatever Canonical does
<trulux> a contract is a contract, everywhere
<damo22> so ubuntu isnt just the result of people giving up their free time to do what they love?
<tseng> it is for me, and a bunch of others here
<tseng> most of "core-dev" is employeed by canonical, however
<damo22> :)
<damo22> okay
<tseng> anyone can join in
<damo22> i think its a beautiful way to share knowledge, but im sure there are big commercial opportunities and niches for people to take advantage of
<trulux> hmm
<trulux> etch can be considered "stable"?
<trulux> tseng, I'm going to try out etch netboot images
<trulux> to see if I can reproduce the damn issue
<damo22> canonical must see that... i guess they have vested interest in making ubuntu the best linux distro 
<damo22> but then, how different from microsoft would that be? :P
<tseng> its very different
<tseng> you cant download the source from microsoft, start submitting patches, and become a key member
<tseng> and help guide the entire project
<damo22> true
<tseng> thats huge.
<damo22> definitely
<dsas> damo22: Also members of the Technical and Community councils which guide Ubuntu aren't all canonical employees
<damo22> i see, thats good 
<trulux> tseng, there's some nice people at MS
<trulux> maybe the just take more time to understand the points, but they finally are getting to something else good
<tseng> I am sure they are "nice".
<damo22> i would say that as a thorough user of ubuntu, i can see that it could bring to life old hardware to be used in schools... but it still has a few bumps to iron out to make it really stable for that purpose
<tseng> my comment had nothing to do with it
<trulux> damo22, is getting too focused on the shiny details, at least that's my opinion
<trulux> less QA maybe
<tseng> linux has bugs.
<trulux> at Red Hat they do tons of QA work
<damo22> QA?
<trulux> and they get to meet and work with the right people
<trulux> quality assurance
<damo22> u think ubuntu is focussing too much on the "eye-candy" for desktop?
<trulux> yes, so to speak
<damo22> i agree
<tseng> we dont really spend much time at all on "eye-candy"
<trulux> ...
<trulux> yes you do :)
<trulux> and doing a big marketing
<trulux> that's Canonical's job actually
<tseng> haha "big marketing"
<trulux> I expected you to smile at least on that one ;P
<damo22> its difficult to talk about things in a very general sense without pointing out specific problems, but i think people generally like to see a desktop that is familiar, with all the simple tasks easily accessible... of course the underlying OS is even more important, but general users dont see that 
<damo22> i think the great freedom of choice available to users for different applications makes it difficult to unify this idea and achieve the goal. 
<damo22> thats probably why ubuntu seems to have spent a lot of time on "eye-candy"
<damo22> id like to suggest something for the next release.... a realtime preemptive (multimedia) kernel so musicians (like me) dont have to compile their own kernel
<tseng> trulux: how many bytes is the ssp header/trailer
<tseng> trulux: 4?
<trulux> tseng, what do you mean, the functon "prologue" from SSP?
<damo22> id really like to know how to obtain the ubuntu kernel patches as a patch for the vanilla kernel...
<tseng> trulux: yes.
<trulux> tseng, I think it was a simple cmp to the address of the guard
<trulux> dunno right now
<trulux> what do you need to do?
<tseng> mono is doing some interesting stack functions in the GC on ppc
<tseng> and is failing when SSP is used
<trulux> I have messed with /GS from Microsoft, which is similar but I forgot about some stuff
<trulux> well
<tseng> my guess right now is it doesnt know about the ssp offset
<trulux> coud you check tha guard isnt being overwritten?
<trulux> ie
<tseng> check how
<trulux> get __guard at different locations
<tseng> it is segfaulting, which could also mean SSP is killing it
<trulux> printf it's hex value
<trulux> well
<trulux> SSP uses abort signal by default
<trulux> tseng, BTW, I got rejected for the sec. engineer position ;P
<tseng> ah :/
<tseng> wonder who got it
<trulux> who knows, maybe too much MS stuff in the CV ;)
<trulux> anyways...
<trulux> back to work
<trulux> I need to finish this showcase
<trulux> asap
<trulux> tseng, what's your job about right now?
<trulux> consulting?
<tseng> no
<tseng> network monitoring/automation
<trulux> I see
<tseng> on a *huge* network
<trulux> I might get into that soon, some opportunities in the NJ area
<trulux> hah
<trulux> how's the salary?
<tseng> good.
<trulux> 40k?
<tseng> us?
<trulux> yeah
<trulux> plus insurance/whatever
<tseng> could start at 60-65 in my area pretty easily in networking w/ some experience
<trulux> I see, sounds nice
<trulux> well, I'm going to give a try to some ideas I've been working on
<trulux> related to data mining
<trulux> outsorcing mostly
<trulux> *outsourcing
<trulux> fsck this kbd
* jsgotangco begs tseng for some spare change
<sivang> jsgotangco: hehe
<trulux> hmm
<trulux> too bad, sparc64 images are broken, dma maybe?
<trulux> slved
<trulux> it's DMA
<trulux> only 2.4 is supposed to be failsafe with DMA on most sparc64 machines
<trulux> this should be fixed in the sparc64 installers
<trulux> BenC, check that out when you have the time please
<trulux> this is normally problematic with some seagate hd's distributed wit some appliances
<fabbione> trulux: our images are fine. You want to check that your hd is not ELO
<fabbione> EOL even
<trulux> fabbione, fucked so to speak
<trulux> fabbione, I'm sure that there's no major corruption on the disks
<fabbione> i am sure the config is fine
<fabbione> if  there are problems are mostlikely locel
<fabbione> local
<trulux> well, for all the sparc64 configurations out there?
<trulux> MANY people experience these errors with Netra's
<fabbione> i have a Netra right in my rack
<trulux> what model
<trulux> T1?
<fabbione> T1
<trulux> Netra's come in many shapes
<fabbione> also
<trulux> right, X1 here
<fabbione> MANY people.. no bug reports...
<trulux> slightly different environment
<trulux> well, not everyone has the time to fill a bug proeprly and the like, most of us try to solve it at our own
<fabbione> then it will never be fixed upstream assuming it's a bug
<tseng> you have spent enough time today complaining to have filed a bug tbh
<fabbione> so complaining here is only annoying
<fabbione> and it will be lost in about 2 minutes when i leave the ws
<trulux> fabbione, agreed
<Hobbsee> hi tseng, fabbione 
<tseng> hi Hobbsee 
<fabbione> hi Hobbsee 
<trulux> fabbione, btw, it's been a long week with the kernel stuff right?
<trulux> with all the new revs coming out
<fabbione> trulux: ?
* fabbione isn't sure what trulux is talking about
<trulux> fabbione, 2.6.17.3 hit the record so far with aprox. 24 hours since last patchset
<trulux> and so on
<fabbione> i don't follow kernel devel any longer..
<trulux> lately it's like if all evil haxors unified their efforts to warm up the kernel guys
<trulux> how's that?
<trulux> you were doing a nice job with the stuff back in Hoary times
<fabbione> because i don't maintain the kernel? (haven't done since breezy)
<jsgotangco> because another guy is already doing the kernel
<trulux> I see
<trulux> tseng mentioned about someone interested on "ASLR" for Ubuntu
<fabbione> for now my only concerns are clusters and sparc
<trulux> hmm, btw, the sparc64 installation is server one only right?
<fabbione> no
<trulux> no workstation crap like desktop, window managers, etc
<fabbione> you can install both desktop or server
<fabbione> it's up to you
<fabbione> we do support officially only server
<fabbione> but in general desktop should work (modulo X autoconfig)
<trulux> i see
<fabbione> i am planning LiveCD and stuff for edgy
<fabbione> there was simply no time in dapper for it
<fabbione> probably i will support only PCI based GFX's for autconfig
<trulux> fabbione, BTW, is there any QA-focused team at Canonical?
<fabbione> sflaw <-
<fabbione> sfllaw <- hime
<jsgotangco> and a group of volunteers as well
<fabbione> s/e$//
<fabbione> i can't type
<fabbione> yes and the #ubuntu-bugs guys of course
<trulux> fabbione, how's supposed to be selectable, the installation type?
<fabbione> trulux: it depends how you are installing
<trulux> it seems to be installing desktop stuff
<trulux> netboot
<fabbione> oh that's funny.. yes
<fabbione> hold on
<trulux> if I can wipe it out later I see no trouble here
<fabbione> server is: boot net base-installer/kernel/linux/extra-packages-2.6= pkgsel/install-pa
<fabbione> ttern=~t^ubuntu-standard$ pkgsel/language-pack-patterns= pkgsel/install-language
<fabbione> -support=false
<fabbione> on feh
<fabbione> all in one line
<fabbione> unfortunatly the alias boot net server doesn't work
<fabbione> the cd has it right
<trulux> good luck on attaching ATAPID CDROM devices to some sparc64 boxes :P
<trulux> do you think it's worth re-starting the installation?
<trulux> or I can remove the crap later?
<fabbione> trulux: they are debs.. 
<fabbione> you can do whatever pleases you the most
<trulux> I mean, easily, or it will conflict?
<trulux> ala ubuntu-desktop must be removed
<fabbione> why should it conflict?
<trulux> meta-packages can be used?
<fabbione> package management is the same as on any other arch
<fabbione> except the filenames are sparc.deb instead of x86juck.deb
<trulux> well man, then go and try ahead to remove gnome on an ubuntu desktop installation of Hoary/Dapper
<trulux> I'll catch up later with that :)
<fabbione> do what you want
* fabbione doesn't care both ways
<fabbione> i am out of here
* fabbione &
<siretart> mdz: re: your recent email to u-d-a: when is the deadline for universe packages?
<slomo> siretart: beta release... 29th september or something
<siretart> ah, i see.
<rleigh> siretart: The schroot build on powerpc seems to fail with a number of segfaults in the testsuite.  (http://librarian.launchpad.net/3303410/buildlog_ubuntu-edgy-powerpc.schroot_0.99.2-2ubuntu1_FAILEDTOBUILD.txt.gz)  Are there any known issues with the powerpc port?
<siretart> rleigh: ooh, interesting segfaults. unfortunately, I don't have access to ppc hardware to test :(
<rleigh> siretart: Since I developed schroot on a powerpc system, I doubt it's an issue with the code.  I would suspect an Ubuntu powerpc-specific library or toolchain issue.
<siretart> perhaps some toolchain issue. The buildlog doesn't indicate too clearly whats going wrong there..
<rleigh> siretart: No.  It really needs looking at with gdb.  I'm afraid I don't have an Ubuntu install on my powerpc to test either.
<sivang> hey glatzor !
<glatzor> hi sivang!
<glatzor> how are you?
<sivang> glatzor: fine, and you? how was your trip back home to the club? 
<mdz> siretart: dholbach outlined the dates for universe; ask him to add them to EdgyReleaseSchedule
<siretart> ok. willdo
<slomo> siretart: if you get a backtrace could you notify me?
<bddebian> Heya folks
<siretart> slomo: er, sorry?
<siretart> hi bddebian 
<glatzor> sivang: http://muenchen.nachtagenten.de/pictures.php4?content=display&event=2006.06.23_Cassius&pic=DSC08478.jpg
<bddebian> Hi siretart
<slomo> siretart: i meant for schroot on ppc :)
<siretart> slomo: as said before, I cannot do a backtrace because of lack of ppc hardware
<bddebian> Anyone know what scope a friend class has in C++ ?
<siretart> bddebian: the same as the hosting class, I'd say
<slomo> siretart: oh... i missed that part of your sentence, sorry :(
<bddebian> siretart: The hosting class?
<siretart> bddebian: maybe I don't get your question? did you look in the c++ faq lite?
<bddebian> siretart: No, where's that? :-)
<siretart> bddebian: http://www.parashift.com/c++-faq-lite/
<bddebian> Thx siretart
<bddebian> strange, I don't see the derived class for this attal thing though
<bddebian> Hmm
<slomo> siretart: regarding schroot... it has exactly the same problem as mono on ppc currently
<slomo> siretart: => libgcc_s bug on powerpc with ssp
<siretart> rleigh: ^^--
<rleigh> siretart: Thanks!  There's not much I can do to help in that case.
<slomo> siretart: do you have a small c++ program that throws an exception somewhere? i think this might serve as a minimal testcase
<rleigh> slomo: http://paste.debian.net/8783
<slomo> rleigh: segfault... thanks :)
<slomo> siretart, rleigh: bug #52465
<Ubugtu> Malone bug 52465 in gcc-4.1 "[libgcc1]  segfault on ppc when unwinding stack (c++ exceptions, mono exceptions)" [Critical,Confirmed]  http://launchpad.net/bugs/52465
<sivang> slomo_: can you get PM's on your slomo nick ?
<slomo_> no, my connection died :(
<sivang> k
<pygi> sivang, you around?
<sivang> pygi: I am :)
<pygi> we have problems :-/
<pygi> the pyburn stuff isn't publicily available (it's located on ftp server protected with username and password)
<sivang> pygi: isn't it open source?
<bddebian> pygi: So crack it ;-P
<pygi> it should be, but it exists only on one server on internet, and it's protected
<pygi> bddebian, eh :)
<pygi> sivang, I found another bindings for it written with pyrex
<bddebian> Isn't there some way to get in touch with the authors?
<sivang> pygi: ^^^ what about what bddebian said ?
<pygi> cracking the server sivang ? ^_^
<sivang> pygi: well, worst case we can still use my wrapper around cdrecord
<sivang> pygi: what about getting in touch with the authors? :p
<sharms>  I was testing a hostname bug, and was able to confirm it, and now I cant change my hostname back.  You guys know another way to use sudo? all I get is: sudo: unable to lookup bobvila via gethostbyname()
<pygi> sivang, sec, trying to locate authors
<sivang> pygi: do you have a link to it's home page/
<sivang> ?
<pygi> sivang, homepage doesnt exist
<sivang> pygi: so how did you find about the bindings ?
<pygi> sivang, ok, so I located author's email address
<sivang> pygi: do you know what his bindings offer? maybe it's not suitable for us?
<sivang> what are they wrapping? libnautilus-burn ?
<pygi> libburn
<pygi> sivang, which should be appropriate for us if it's written clearly
<pygi> sivang: pyrex bindings, which I think are not appropriate but oh well...
<pygi> svn co http://www.tortall.net/svn/mu/trunk/python-libburn
<sivang> pygi: checking out
<bddebian> OK, wtf do I do about attal?  The source tarball extracts to attal-src-0.10.1 ?
<Amaranth> smack upstream around a bit
<bddebian> :-)
<bddebian> What's the "policy" on packaging from CVS?
<slomo_> bddebian: where's the problem?
<pygi> sivang, k, great
<sivang> pygi: have youo mailed the author ?
<pygi> sivang, yes, the one with "real" bindings
<sivang> pygi: cool :)
<bddebian> slomo_: Shouldn't it be attal-0.10.1?  Or does it not matter?
<sivang> pygi: I wonder how proven those bindings are , or libburn itself
<sivang> pygi: do you have an idea ?
<slomo_> bddebian: it should... but it doesn't hurt in most cases if it isn't called that way
<bddebian> slomo_: Oh, OK, thanks
<pygi> sivang, libburn is good I guess, bindings have never been used !!! :)
<sivang> pygi: who uses libburn ?
<sivang> (apps, that is)
<pygi> sivang, I am not really aware of such application as libburn is not really able to replace cdrecord right now
<pygi> but it serves well for basic tasks
<sivang> pygi: If it can't do multi sessions burns correctly we can't use it
<pygi> sivang, it can
<sivang> pygi: so it can do regular and multi session burn nicely? that's good then
<sivang> pygi: We need to test it though before we port home-user-backup to use it
<pygi> sivang, ofcourse
<sivang> pygi: so we won't do it and then realize it's making it unstable
<sivang> pygi: the problem is that we have little time to do so...We should have already started with implementation 
<pygi> right, that's true :-/
<pygi> we have like 20 more days, right? 
<pygi> uh, DAR bindings :-/
<sivang> something like that, until september 7th
<bddebian> Heya zakame, mdke
<pygi> sivang, ok, so I guess if we get the bindings I'll get on work testing both bindings and libburn
<sivang> pygi: do you think it's feasiable to get the bindings  for dar in shape in time ?
<sivang> it seems too big to complete in the edgy time frame...
<pygi> sivang, right, especially if we have to test the libburn stuff :-/
<pygi> but then again, for edgy+1 dar will be on second place, but I guess we'll have more time for edgy+1
<sivang> pygi: well, if we get out of the way the burning bindings, the new UI and the bits we need from nautilus to detect free space on multi session cds, I think we could concentrate on that for edgy + 1
<pygi> right, right
<pygi> and we could use libburn even in pre-boot status I guess
<pygi> sivang, btw. I think libburn is able to detect free space on multi session cd
<sivang> pygi: if that's true, then you deserve a hug :-)
* sivang wishes it's so
<sivang> and it also has pythong bindings for that as well probably?
<pygi> well, I am tellinh you that I contacted the author ^_^
<sivang> pygi: okay, we should wait to see what he says
<sivang> pygi: thanks
<pygi> There is only one potential problem...but if my thinking is correct, that will be quite easy to "fix"
<sivang> what is it?
<pygi> well, it seems libburn isn't maintained anymore ^_^
<sivang> interesting
<pygi> tho, that shouldnt be a problem
<sivang> "and the plot thickens"
<sivang> pygi: how come?
<pygi> Don't worry, I'll just take over the maintainment
<pygi> ergh, wrong spelling :P
<pygi> sivang, it's much more stable then cdrecord, and in the long term it could even have more features
<sivang> pygi: do we have any proof that it's more stable the cdrecord?
<sivang> or cdrdao ?
<slomo_> pygi: and hopefully isn't that weird regarding licensing as cdrecord ;)
<pygi> slomo_, GPL
<pygi> sivang, yes, I used it some times ago (the same version)
<sivang> pygi: very cool :)
<pygi> I just wonder why it's development stopped...it had very bright future according to mailing lists
<sivang> slomo_: the etherape edgy diff.gz has weird stuff...:-/
<sivang> pygi: maybe the developer needed to work on dayjob stuff, etc
<sivang> pygi: or lost interested
<pygi> sivang, right right
<sivang> pygi: but if we can resorect it it would be cool, we could split maintianership of python bindings and the lib itself
<sivang> pygi: (you and me)
<pygi> sivang, yes, I do agree
<pygi> We must see status of python bindings, perhaps we will have to write it from scratch if this don't suit us
<pygi> altought I think this is really out of scope for edgy if we have to do it
<sivang> pygi: I hope they will. Not sure we have the time
<pygi> what is our current status? do we have new UI integrated?
<sivang> pygi: not yet, I will start work on it tomorrow
<pygi> ok, that should take you few days if I am not mistaken?
<sivang> pygi: you are free to join me , though, glatzor as well :)
<sivang> pygi: yes
<pygi> yes, I saw we got another contributor ^_^ Haven't heard from him tho ^_^
<sivang> pygi: perhaps more. Some stuff changed in the workflow that could trigger changes in the underlying backend some bits.
<sivang> pygi: on the Backupers team?
<pygi> well, the "glatzor" :P
<sivang> ah :)
<sivang> He already worked so hard on the UI during the conference, you wouldn't believe it.
<sivang> I owe him my life :p
<pygi> :)
<pygi> sivang, o yes,and we have to integrate python-libnotify this cycle :)
<pygi> I think we don't have it in repos just yet tho?
<mdz> zul: around?
<slomo_> regarding libnotify there is some work to do anyway... we need new notification-daemon, new libnotify, new libnotify bindings. i wanted to talk with mvo about it tomorrow as he cared for it in dapper
<zul> mdz: yep
<mdz> zul: was just trying out your new grub, but there's a problem
<zul> oh?
<mdz> zul: if update-grub is run without grub-install, it breaks the boot
<pygi> slomo_, hm, right
<mdz> and update-grub is run automatically in a number of places (e.g., kernel upgrades)
<zul> hmmm...ok ill have a look at it tonight
<pygi> slomo_, thanks ^_^
<stratus> slomo_: i've uploaded python bindings for debian, i told sivang. probably will do the latest lib soon, but nothing urgent is there from .40 to .42.
<mdz> zul: then I ran grub-install to test that, and my system doesn't boot at all
<mdz> I can get to the grub menu, but can't load a kernel
<slomo_> stratus: i know :) nice to see you here too
<zul> ok ill back out my patch then
<mdz> I get "Error 1: Filename must be either an absolute pathname or blocklist" if I try to boot manually
<stratus> slomo_: hi. i'm always here, i just don't talk too much.
<mdz> if I just let grub continue, my system reboots in a loop
<sivang> slomo_: this is the first time there are libnotify python binding IIRC, Gustavo told me it's sitting in NEW in sid,
<mdz> zul: are you sure the compiler change took effect?  it seems unrelated to your patch, possibly a compiler regression
<stratus> sivang: no, no. it isn't sitting in NEW anymore, it was processed in just one day. :)
<zul> its a compiler regression
<pygi> stratus, o, that's a news indeed :)
<slomo_> sivang: and yes, before you had to use the dbus interface of notification-daemon :)
<sivang> stratus: ah! then we should attemempt to import it and then apply the changes you told me to make it work
<mdz> so backing out the patch might not fix it
<stratus> pygi: sure, i even blogged about that :)
<sivang> slomo_: yes, one can hardly call those bindings =)
* pygi nods
<stratus> sivang: sure, i've some other stuff to do now like vte python transition, but i can branch out and prepare some of that changes if you're busy with other stuff
<zul> mdz: so you did grub-install and then update grub and rebooted?
<sivang> stratus: now, I can do them, the question is if it's alredy in ubuntu or still waiting at our NEW for the overrides or so
<mdz> zul: I think we were building grub with gcc-4.0 before
<mdz> zul: did you try -4.0 before going all the way back to -3.4?
<mdz> zul: I did update-grub, rebooted, worked around the fact that it couldn't parse menu.lst anymore, ran grub-install, rebooted and that's where I am now
<stratus> sivang: which NEW? ubuntu's? i doubt it will be merged due to the new python infrastructure in Debian.
<slomo_> sivang: you could file a sync bug for it... but we need to merge libnotify 0.4 first iirc
<zul> mdz: no i didnt try gcc-4.0
<mdz> zul: I'll give that a try
<sivang> slomo_: I think I'll do that so I'll be notified when it's in and I can then merge it
<mdz> hmm, doesn't build with 4.0
<slomo_> sivang: in think we can just sync the python bindings... not sure about libnotify though, that's what i wanted to talk with mvo about :)
<mgalvin> mdz: just so you know, i have been busy all week, i should have some time tonight to get the UWN out before the day is out
<sivang> slomo_:  I see. Well, I stratus noted to me that we would probably need to drop some stuff form his current packaging in order to make it work, but maybe if all of the python transition is done then we could sync it proper.
<mdz> zul: eek, with the gcc-4.0-compiled one I get an empty menu
<mdz> mgalvin: cool, thanks
<zul> mdz: yeah im having the same problem now
<mdz> zul: this must have worked for you at some point though, surely?
<zul> yes it did, but i wasnt using quiet in my grub-menu i was using quietboot
<mdz> I have no idea why building it with gcc-4.0 doesn't fix the problem; perhaps it's a bug in your changes after all
<zul> mdz: i was running it yesterday without sany problems
<mdz> zul: any reports from anyone else of success or failure?
<zul> i havent heard anything except for you mdz
<zul> ill back out the patch and see if that works
<mdz> zul: building with -4.1 causes grub to segfault for me; is that what happened to you as well?
<zul> yes
<pygi> sivang, you still here?
<mdz> gcc-4.0 has been updated to the latest svn; it's possible there's a regression there
<sivang> pygi: yes, but intend to go to sleep now
<mdz> I'm going to try it with dapper's gcc-4.0
<pygi> sivang, ok, sleep, I have some good news for you at wednesday (will be absent by then)
<sivang> pygi: let me have them now :)
<pygi> I talked with a few more people, and they seem to be higly interested in resurecting the libburn stuff
<sivang> oh cool;
* sivang has no idea where the semi colon came from
<pygi> sivang, ok, don't let me hold you off anymore,sleep ^_^
<sivang> pygi: laters dude, thank you for all your help :)
<pygi> sivang, no, thanks for all your help :)
<mdz> zul: I built dapper's grub with edgy's gcc-4.0 and that produces a working grub
<mdz> zul: so the regression is either in your patch or the Debian merge
<zul> debian merge of grub?
<mdz> yes
<zul> ok
<mdz> I'll do some further testing
<zul> so will i
#ubuntu-devel 2007-07-02
<pygi> morning Hobbsee 
<Hobbsee> hiya pygi 
<voltagex> I think I'm in the wrong channel, I'd like to discuss a bug report with someonw.
<pygi> which bug?
<voltagex> https://bugs.launchpad.net/ubuntu/+source/vlc/+bug/103025
<ubotu> Launchpad bug 103025 in vlc "(Feisty) VLC sound quality is poor for many video files" [Medium,Invalid]  
<pygi> no idea about vlc, sorry
<voltagex> I don't believe it's a VLC issue
<pygi> hey LaserJock 
<voltagex> and from what other people in that discussion have said, it's an alsa problem
<voltagex> but personally I think it needs investigating, because there's a lot of confusion in that thread.
<pygi> if it's really alsa problem, then crimsun is your guy, but he's probably sleeping now
<voltagex> which timezone?
<voltagex> sorry, which timezone is crimsun in?
<LaserJock> hi pygi 
<pygi> voltagex, no idea
<voltagex> (so I know when to look for him :) )
<pygi> LaserJock, how is it going at this early morning? :)
<LaserJock> pygi: it's 6:50 pm here
<pygi> voltagex, ah, he's already following the bug
<voltagex> 11:50 -!- crimsun is away: moving.  Offline until sometime Monday
<pygi> LaserJock, 3:50 :)
<pygi> 3:50AM :)
<voltagex> 1150AM here.
<pygi> voltagex, he's looking at the bug, don't worry
<voltagex> I'd like to get more involved in bug reporting, because I seem to keep stumbling onto them.
<voltagex> pygi: what would be the best way to help him?
<pygi> voltagex, reproduce bug, attach traces, and such :)
<minghua> voltagex: for help reporting bugs in general or alsa bugs in specific?
<voltagex> ah...complex
<voltagex> this bug in particular, because I have some free time now to chase it down.
<minghua> then just put whatever you found in the bug report, since crimsun is already following the report
<pygi> nod :)
<voltagex> crap, just realised what I wrote is very unhelpful - I made a post before I came in here.
<voltagex> so, reproduce this bug by playing a "crackling file", then copy some kind of verbose output to the report? Stack traces are beyond my current skill level, but if someone could point me in the right direction I'm willing to learn.
<Hobbsee> siretart: er, are you talking about the fact that libxine-ffmpeg and plugins and whatnot depend on libxine1, or that libxine1 depends on itself?
<Hobbsee> looks like a circular dependancy between libxine1-ffmpeg and libxine1 too, where recommends are installed by default.
<Hobbsee> maybe i'm on crack or something
<pygi> Hobbsee, possible :)
* Starting logfile irclogs/ubuntu-devel.log
<pitti> Good morning
<Hobbsee> morning pitti!
<pitti> it's a Hobbsee! *hug*
<Hobbsee> pitti: it is!  *hugs back* :)
* StevenK waves to pitti
* Hobbsee turns violent, and eats pygi 
<pitti> hi StevenK 
<StevenK> Turns, you say?
<Hobbsee> pitti: can you reject the first ubuntu-restricted-extras v7 please?
* Hobbsee attempted to upload again to overwrite it, but it appears that i was too slow.
<Hobbsee> StevenK: surely i'm not *always* violent...
<minghua> Hobbsee: so, emm, resumes? :-P
<Hobbsee> minghua: sorry?
<Hobbsee> minghua: oh, resumes being violent?
<minghua> Hobbsee: yes
<StevenK> pitti: Regenerate cruft when and if you feel so inclined.
<StevenK> Please.
<fabbione> morning guys
<Hobbsee> morning fabbione!
* Hobbsee turns fabbione into a squid, in greeting
<fabbione> hey Hobbsee 
* fabbione spreads inks all over Hobbsee 
<ion_> Hobbsee already did that to me. http://heh.fi/tmp/cephalopod
<nixternal> hey, I can't get upstream (and I have asked very nicely) to incorporate the license into his tarball. he does post the license on his website though (LGPL), this is for an icon package. Is there any work around what so ever, to get this in and legal?
<Burgundavia> nixternal: which package is it?
<ion_> nixternal: I think youll only have to recreate orig.tar.gz, adding COPYING.
<pitti> Hobbsee: sorry, nothing in NEW or accepted; I'm afraid you have to upload a new version
<ion_> nixternal: I could be wrong, though. :-)
<nixternal> Burgundavia: icon package for kde
<Hobbsee> pitti: okay, will do
<Hobbsee> ion_: hehe, yummy
<nixternal> I would love it if I could rerecreate the orig.tar.gz with the license file..this icon package is the yummiest out there :)
<ion_> nixternal: Id like to see a screenshot, btw.
<nixternal> http://www.kde-look.org/content/show.php/Crystal+Project?content=60475
<nixternal> the screenshot on that page doesn't do it justice..the link to the homepage has more
<ion_> Thanks
<Hobbsee> fabbione: just what i wanted.  to be covered in ink...
<nixternal> http://www.everaldo.com/crystal/?action=preview
<nixternal> there you go
<fabbione> :)
* ion_ still enjoys Tangerine.
<ion_> The Home icon reminds me a lot of the equivalent icon in the good old Amiga icon set, whatever its name was.
<pitti> StevenK: it finally finished, updated
<StevenK> pitti: Thanks
<pitti> siretart: can I remind you about the ffmpeg soname transition?
<StevenK> pitti: spandsp is waiting on a new release of asterisk-plugins-spandsp to hit unstable, I'm not really comfortable poaching an unreleased version from pkg-voip's SVN.
<pitti> StevenK: that's fine; but a simple rebuild won't do?
<StevenK> pitti: No, the current package can't build against Asterisk 1.4
<ajmitch> hi pitti 
<Hobbsee> ah well, closed a couple of bugs
<pitti> hey ajmitch 
<Hobbsee> pitti: where can i find info on the ffmpeg soname transition?
<Hobbsee> as in, to find out which packages are affected
<pitti> Hobbsee: same as where StevenK works from: http://people.ubuntu.com/~pitti/tmp/cruft/
<Hobbsee> pitti: bah.  where's that duncecap?
<StevenK> My blood, sweat, tears, and occasionally other bodily fluids are in those lists.
* StevenK watches the entire channel say "Ewww"
* ion_ watches some channel members say Mmmmm and says Ewww to that.
* polopolo don't belive ion_, and I want also say that that is for #ubuntu-offtopic
<StevenK> pitti: Can I bug you to look at the MIRs for OpenAL and co to banish rss-glx from that list? :-)
<pitti> StevenK: ah, yes
<StevenK> pitti: Okay, that should be everything bar libavg for the libavformat0d transition. They should all get published and built over the next 2 hours.
<pitti> StevenK: yay you
* StevenK glares at libavg.
<fabbione> do we already have GutstyReleaseNotes ?
<pitti> fabbione: we have them in distributed form in the specs at least
<fabbione> pitti: this is a bug fix.. there was no spec for it and it needs a note
<fabbione> "whops we just figured that we were writing an almost totally wrong SUN disk label on sparc.. and you really want to update it by running fdisk manually and reboot"
<pitti> fabbione: I don't see an existing one, but feel free to create https://wiki.ubuntu.com/GutsyGibbon/ReleaseNotes
<fabbione> kind of thing..
<fabbione> pitti: yeah i couldn't find one either.. just making sure the RM god was ok with that before doign
<Hobbsee> fabbione: he'll come and hit you with lightening soon if he isnt
<fabbione> Hobbsee: no thanks. i am not in "getting spanked" mood today
<pitti> lol
<Hobbsee> fabbione: i wouldnt have called lightning an implement for spanking...more "blasting"...but whatever you prefer :)
<pitti> nah, unlike Hobbsee I don't eat/burn people :)
<Hobbsee> pitti: you sad, deprived person.
<Hobbsee> pitti: besides, i'm not the one who normally eats people.
<StevenK> Yay. libavg fails to build because of avformat API changes. Not totally unexpected.
<pitti> StevenK: ok, openal/freealut checked and promoted; yay for two more obscure libraries in main :/
<fabbione> BRRRRRRRR
<fabbione> pitti: i use them almost regularly
<Hobbsee> pitti: could you be persuaded to do pinentry-qt too?
<fabbione> pitti: x-plane needs them too :)
<pitti> right, but this is highly universe games stuff
<fabbione> pitti: x-plane is not in archive :)
<pitti> Hobbsee: that sounds more delicate, I'll have another look later; breakfast first :)
<Hobbsee> pitti: heh
<fabbione> pitti: http://www.x-plane.com/ <- better than FlightSimulator
* Hobbsee gets out the lightning bolt
* Hobbsee gets out the lightning bolts
<StevenK> fabbione: Better than FlightGear?
<fabbione> StevenK: mostlikely
<StevenK> Ahh, x-plane ENOFREE
<pitti> fabbione: looks cool
<fabbione> pitti: it is.. 9 dual layers DVD + updates + plugins + SDK.. highly portable etc.
<fabbione> pitti: i can take it with me in London to show
<fabbione> StevenK: right, but it runs everywhere and it's FAA certified for official pilot training
<StevenK> Which automatically kicks FlightSim all over the place.
<fabbione> yeps
<fabbione> it has a lot more tho.. you should really give it a shot
<fabbione> StevenK: http://people.ubuntu.com/~fabbione/pics/random/xplane.jpg
<fabbione> (running on Linux expect on ppc where port is beta stage)
<StevenK> I think I'd rather get a handle on flying with FlightGear before I shell out cash for x-plane. :-)
<fabbione> StevenK: it's cheap tho.. like 60 USD or so
<fabbione> to be a game of that size is almost no money
<fabbione> (given the 10 dual layer DVD)
<persia> fabbione: Can x-plane actually handle all 34 buttons on that joystick under linux?
<fabbione> persia: yes. I have 2 joysticks attached to it
<fabbione> it's fully configurable
<fabbione> 2 joysticks and i still can't cover all the config options for flying
<persia> fabbione: Thanks.  I wasn't sure it would work (given flightgear's arrangements).  Thanks.
* fabbione needs an 8 levels throttle "joystick" and pedals still
<fabbione> pitti: could you check if gutsy-changes died again?
<Hobbsee> fabbione: should be alive.
<Hobbsee> fabbione: i saw at least one from you before
* StevenK tries to figure out how to drive quilt
<fabbione> ok then it's in the queue to arrive here i guess
<StevenK> fabbione: There ought to be about four from me.
<Hobbsee> accepted parted
<Hobbsee> fabbione: ^
<fabbione> Hobbsee: ok.. i just didn't get them yet
<Hobbsee> :)
<fabbione> Hobbsee: yeah parted and util-linux
* Hobbsee ponders...go to the bakery, or make own food...
<fabbione> StevenK: got one second for me?
<StevenK> fabbione: Certainly.
<fabbione> StevenK: could you try to resolve smtp.fabbione.net from where you are?
<fabbione> or telnet to it on port 25
<fabbione> looks like emails are not coming back to me
<StevenK> It responds.
<fabbione> ok thanks
<StevenK> 220 trider-g7.fabbione.net ESMTP Postfix (Ubuntu)
<fabbione> yeps..
<fabbione> that's right
<fabbione> thanks mucho
<StevenK> No problem
<StevenK> Okay, then. quilt is .... interesting.
<persia> StevenK: Why?
<pitti> fabbione: I don't have particular powers to check that
<StevenK> persia: It's the first time I've used it.
<pitti> fabbione: I can just talk to the soyuz guys; did you get a reject email again?
<persia> StevenK: Ah.  Yes, it's a little different.
<StevenK> persia: A little you say? :-)
<persia> StevenK: Yes, in the same way that the width of the pacific ocean is a little far to swim (although I believe it has been done).
* Hobbsee grumbles at the inconvenience of blood spurting everywhere.
<pitti> Hobbsee: WTH did you do?
<lifeless> Hobbsee: !!!
<Hobbsee> cut myself on a can by accident
<pitti> fabbione: it seems to work for StevenK at least
<Hobbsee> right.  fixed.  darned inconvienent, that
<Hobbsee> heya lifeless 
<lifeless> hiya.
<StevenK> pitti: libavg fixed and just uploaded, too.
<pitti> cheers
* StevenK waits for rss-glx to retry.
<pitti> StevenK: publisher is still running for the promotion change
<StevenK> Ahh
<fabbione> pitti: it seems to be a canonical mail server issue.
<fabbione> pitti: nothing you can do about it
<StevenK> Hrm. My libavformat fixing should have fixed libavcodec too.
<StevenK> pitti: Was it decided that the Beryl stuff would be killed?
* Hobbsee gives pitti and lifeless a copy of hitch hikers guide to the galaxy, and suggests they read the front cover
<pitti> Hobbsee: I have the entire Douglas Adams collection here :)
<pitti> StevenK: not really officially decided, but I guess it makes sense to kill those
<Hobbsee> pitti: then you know what the friendly green letters say on the front cover :)
<Hobbsee> i'm disappointed - my school library never had all of them.
<Hobbsee> i wonder if the uni library does.....
<pitti> Hobbsee: they don't have the real essentials? :/
<Hobbsee> pitti: seems not
<Hobbsee> pitti: our school wasnt great on such things.
<Hobbsee> they had the first 2 books of tomorrow when the war began - and note that the first was on the prescribed reading list for one of the subjects
<StevenK> Heh. My wife and I both have a complete set.
* Hobbsee wonders who timfrost is.
<siti> nag: https://bugs.launchpad.net/ubuntu/+source/gksu/+bug/66518 <-- debdiff here for a very annoying bug, it's been sitting here far to long :(
<ubotu> Launchpad bug 66518 in gksu "[Edgy + Feisty]  Startup Notification broken" [Medium,Confirmed]  
<siti> please could some dev look at it :'(
<seb128> mvo: ^
<mvo> siti: looking
<siti> thanks
<mvo> siti: we usually do only fix major crashers or security problems in already released versions of ubuntu. 
<siti> yes, but for gutsy would be good
<mvo> siti: right, gutsy should be fixed, but let me double check
<siti> (the debdiff would need to be changed for gutsy)
<siti> thanks
<pitti> carlos: the current gutsy update langpacks are relative to 20070625?
<seb128> pitti: would it be easy to make apport ignoring g_logv and g_log for the bug title?
<pitti> seb128: it would be cleaner to also 'unwind' it from StacktraceTop; would that be right?
<seb128> pitti: ie, bug #123462
<seb128> yes
<pitti> seb128: so the new gtk/glib now always calls g_logv() for a crash?
<ubotu> Launchpad bug 123462 in gnome-vfs2 "gnome-vfs-daemon assert "volume->priv->drive == drive"" [Medium,Confirmed]  https://launchpad.net/bugs/123462
<seb128> g_assert_warning () from /usr/lib/libglib-2.0.so.0
<seb128>  gnome_vfs_volume_unset_drive_private ()
<seb128> pitti: no, only for a gdk_x_error or an assert
<pitti> seb128: seems that we actually should unwind until (including) g_assert_warning()?
<carlos> pitti: they should
<carlos> let me check to be sure...
<pitti> seb128: so this bug would be shown as a crash in gnome_vfs_volume_unset_drive_private()
<seb128> pitti: this bug is an assertion in gnome_vfs_volume_unset_drive_private() yes
<seb128> we want to keep the g_assert_warning() though
<seb128> to indicate it's an assertion
<pitti> seb128: ah, ok; as you wish
<pitti> seb128: right now I don't have logic to construct the bug title from a different StacktraceTop line than the first
<pitti> seb128: that would introduce heuristics on two different places and might interact in a weird way
<seb128> pitti: I'm fine having the title mentionning the g_assert_warning
<pitti> seb128: ok; so I only unwind g_log() and g_logv() for now?
<seb128> pitti: yes
<pitti> cool, will do that
<seb128> pitti: or do you think dropping the g_assert_warning as well would make sense?
<pitti> seb128: it might, depending on how useful it is for dup detection
<pitti> seb128: if it's just a standard function that happens on every assert, it should probably go
<seb128> would it be easy to change the title when there is a g_assert_warning?
<pitti> seb128: would be an ugly special case, so I would need to think about some generalization, but yes
<seb128> "gnome-vfs-daemon crashed with signal 5 in g_logv()" is the current title
<seb128> "gnome-vfs-daemon crashed on assert in gnome_vfs_volume_unset_drive_private()"
<seb128> that would be better ;)
<pitti> seb128: so g_assert() actually raises signal 5 now?
<carlos> pitti: yes, it is
<carlos> only 172 files exported yesterday
<seb128> pitti: g_assert calls g_log and then "abort()"
<carlos> pitti: btw, I think I will need to delay when the process starts because the mirror took a bit more time today so the exports failed..
<seb128> pitti: afaik g_assert didn't change
<cjwatson1> Hobbsee: FWIW, self-dependencies are harmless
<cjwatson1> (dpkg ignores them)
<Hobbsee> cjwatson1: ahhh, right
<cjwatson> Hobbsee: circular dependencies are *mostly* harmless, though can lead to postinst scripts being executed in something other than the order you might hope for
<ion_> I cant believe i didnt think of this earlier. No need to quit Firefox anymore when watching a movie (since theres always some stupid script in some tab thats going to steal the precious CPU time from mplayer). I simply added pkill -STOP firefox and pkill -CONT firefox to my panel. :-)
<Hobbsee> cjwatson: right
<cjwatson> circular pre-dependencies are bad; circular build-dependencies are sometimes necessary but are a pain
<Hobbsee> ahhh
* Hobbsee commits a serial troll back into his jail cell.
<Hobbsee> hooray!
<siti> is there anyone passionate about no more source packages, or wants the debian packaging to be more collbrative? could they have a look at: https://wiki.ubuntu.com/NoMoreSourcePackages/GitImpl
<siti> it's just a very rough idea, but so far I already see huge advantages
<Mithrandir> siti: given our big commitment to bzr, I doubt we would want to build a solution around git's model.
<siti> Mithrandir: yeah, I've thought about that, but would debian ever move to bzr?
<siti> also bzr is probably to slow for large packages
<Mithrandir> siti: debian is probably never going to adopt just one VCS.
<siti> git is gaining traction...
<Mithrandir> and bzr is getting faster
<siti> is bzr as easy to script for, e.g. could I do something like this in bzr: git-ls-files --ignored -x \* -o --directory | grep -v debian | xargs rm -rf
<siti> it automatically deletes all non-referenced files (much easier than writing cleaners in the rules file)
<Mithrandir> bzr unknowns |xargs rm -rf?
<siti> ok
<cjwatson> (or 'bzr ls --ignored --unknown' to catch both ignored and otherwise-unknown files)
<siti> hmm, I wonder if there would be a way to standardise this across multiple DVCS ;)
<siti> ok
<siti> I really want this to happen because currently (for me anyway and I bet many others) making debian packages is well horrible, dpatch/quilt are very annoying to work with
<siti> quilt is a bit better, but it's very much the maintainer model
<Hobbsee> pitti: ping
<siti> Mithrandir: well, what do you think would need to happen for something like this (what ever DVCS) to be adopted
<siti> because I really want it to happen...
<pitti> hey Hobbsee 
<Mithrandir> siti: lots of infrastructural work, probably.
<Hobbsee> pitti: are you busy?  got a concept question about apport
<Hobbsee> pitti: https://bugs.launchpad.net/bugs/123394 - how it handles during dist-upgrades, and memory usage.
<ubotu> Launchpad bug 123394 in apport "adept notifier crashes and bogs down after a dist-upgrade" [Undecided,New]  
<pitti> Hobbsee: hm, weird; the apport UI should load the problem reports one by one
<pitti> Hobbsee: I'm not sure what exactly adept-notifier does, but I guess it just checks for new reports and calls apport-qt
<pitti> Hobbsee: the root of the problem might be that libapt reports followup package errors; it should only report the first one
<pitti> mvo: ^
<mvo> pitti: it should ignore follow-up errors, let me check the report
<mvo> pitti: the bugreport does not look like it is releated to libapts problem reporting
<pitti> mvo: hm, ok; but something must have written those reports?
<mvo> pitti: right. I have seen parts of kde crash during a upgrade, so it maybe just those?
<pitti> mvo: ah, right, maybe
<pitti> we'd need to actually see those crash reports
<mvo> yeah
<Hobbsee> what i'm wondering about is "is htere a safeguard to make sure apport + the upgrader doesnt take up all available ram?"
<pitti> Hobbsee: apport> depends; it will limit core dumps to 3/4 of available RAM
<pitti> Hobbsee: apport> but if there are multiple processes crashing in parallel, there will be multiple apports, too
<dholbach> good morning
<cjwatson> siti: if you're using a distributed VCS it really doesn't make sense to use dpatch or quilt *as well*, IMHO.
<siti> cjwatson: yep
<siti> I think we will see productivity gains for packages similar to what you would see with software if both moved from emailing patches -> DVCS
<siretart> pitti: dammit, I forgot some uploads. Yes, will look into them!
<siretart> Hobbsee: both
<pitti> siretart: StevenK did some (all?) now; thanks for looking into it
<StevenK> I did all of the libavformat0d ones.
<StevenK> That should have also taken care of libavcodec0d.
<StevenK> Nice how logs for currently building packages isn't available anymore.
<Hobbsee> siretart: right
<siretart> StevenK: thanks!
<StevenK> siretart: No problem, and sorry if I stepped on your toes.
<siretart> StevenK: not at all!
<siretart> Hobbsee: is there any problem with that self dependency?
<siretart> Hobbsee: I think it is a bug (or at least interesting behavior) of dpkg-shlibdeps: it perhaps should check that it is about to generate a self dependency and just drop it
<StevenK> Hey, way cool. libgoffice-0-3 appears in it's own cruft list.
<Hobbsee> siretart: dunno.  i would have thought all dependancies on itself were bad...
<siretart> Hobbsee: I haven't noticed problems because of this. in any case, I think that should be fixed in dpkg-shlibdeps (if necessary at all)
<Hobbsee> siretart: fair enough, i just noticed it by accident
<StevenK> Oh, that's right. I can't fix kwave because the error defeats my C++ skills.
<pitti> seb128: apport change for the assert unwinding committed
<pitti> seb128: that doesn't change the subject structure for now, though
<seb128> pitti: rock on ;)
<seb128> ok
<pitti> seb128: it'll end up as 'signal 5 in gnome_vfs_volume_unset_drive_private' ATM
<seb128> that's good enough
<seb128> triagers will stop to mark bugs duplicates because they crashed in "g_logv"
<pitti> seb128: hm, seems it's urgent enough to upload it now?
<seb128> pitti: would be nice
<seb128> no hurry, but having bug title with an actual function name would be better
<pitti> seb128: uploaded
<seb128> pitti: danke
<pitti> cjwatson: could you please mark https://code.launchpad.net/~kamion/langpack-o-matic/depends-fixes as 'merged'?
<cjwatson> pitti: done
<pitti> thanks
<pygi> Hobbsee, why did you try to eat me? 
<saispo> 3/win 24
<Hobbsee> hiya sabdfl 
<Hobbsee> pygi: because you clearly were wanting it?  I could have fed you to the troll in #ubuntu-offtopic if you like, or the one in #ubuntu-ops
<pygi> Hobbsee, I wasn't even here, I was sleeping!
<Hobbsee> pygi: sure sure.  you were just pretending.
<pygi> :'(
* Hobbsee wonders how many other people she's going to need to kick in the next half an hour.
* pygi counter-eats Hobbsee 
* Hobbsee makes pygi deal with the mess of the userland channels.
* pygi sweeps it under Hobbsee 
<pygi> (the mess)
<Hobbsee> heh
<Fujitsu> Hobbsee: What about the poor kernelspace channels?
<Hobbsee> Fujitsu: the trolls tend not to go there
<Hobbsee> Fujitsu: and even if they do, they dont bring 50 spambots with them.
<Hobbsee> it's much easier to kb one into the middle of next millenium than 50
<Fujitsu> Ah. Fun.
<Hobbsee> Fujitsu: of course!
<StevenK> seb128: Is Gstreamer 0.8 going to stay around for Gutsy, or are we going to kill it?
<Hobbsee> Fujitsu: and 2 more gone from #ubuntu
<seb128> StevenK: it's on my list of things to clean, why?
<StevenK> seb128: gstreamer0.8-flac depends on an old version of libflac.
<StevenK> seb128: Trying to determine if it'd be a waste to spend time on it.
<seb128> yeah, don't bother with 0.8
<Mithrandir> we still have gst 0.8 in the archive?
<StevenK> Mithrandir: It seems so.
<Mithrandir> sounds crackful
<seb128> Mithrandir: there is still some apps using it
* Fujitsu recalls getting rid of a couple of rdepends in Edgy.
<Mithrandir> seb128: goobox and gstreamer-editor?
<Fujitsu> goobox looks to be about it.
<Fujitsu> What Mithrandir said.
<seb128> Mithrandir: yeah, it's good enough to be cleaned now
<seb128> Mithrandir: that's what I said, it's on my "to clean" list for gutsy ;)
<Mithrandir> seb128: you and your lists. ;-)  Always on top of things. :-P
<dholbach> there was a goobox update that crevette is working on
<seb128> lol
<dholbach> could possibly be they switched to gst0.10
<Fujitsu> dholbach: They would be fairly deranged to not have siwtched.
<Fujitsu> *switched
<Fujitsu> goobox in experimental uses 0.10, so I presume they've switched.
<dholbach> oh nice
<dholbach> thanks Fujitsu, I prodded crevette about it
<Fujitsu> Is gstreamer-editor any use if there's nothing using 0.8?
<seb128> dholbach: he knows about it
<seb128> Fujitsu: no
<seb128> Fujitsu: that's just a matter to update goobox and clean the gst0.8 stack, I'll do it this week
<Fujitsu> seb128: Great :)
<linux_user400354> where can i find the default wallpapers from breezy? ive searched at packages.ubuntu.com and didnt find it.
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b *!*@208-117-26-76.block5.gvtc.com]  by Hobbsee
* linux_user400354 was kicked off #ubuntu-devel by Hobbsee (see #ubuntu+1)
<pitti> Hobbsee: harsh
<Hobbsee> flipping hell....
<Hobbsee> pitti: when he asks the same question in 4+ places...
<Hobbsee> pitti: besides, i've already kickbanned over 10 people today - the trolls are out in force.
* mode/#ubuntu-devel [-b *!*@208-117-26-76.block5.gvtc.com]  by Hobbsee
* mode/#ubuntu-devel [+b *!*@208-117-26-76.block5.gvtc.com!#ubuntu]  by Hobbsee
<StevenK> pitti: Regenerate the cruft lists when you feel so inclined, thanks.
<pitti> StevenK: grinding
<StevenK> Poor drescher.
<cjwatson> isn't that list cronned?
<pitti> not yet, I didn't manage to do that any more on Friday
<cjwatson> StevenK: Shouldn't requestsync use 'rmadison -u ubuntu' now? It's probably more reliable (i.e. less dependent on the local system) than 'apt-cache madison'.
<cjwatson> StevenK: likewise it seems like it should use rmadison rather than looking at http://qa.debian.org/madison.php manually
<StevenK> Good idea, I'll hack that in shortly.
<siretart> pitti: I've tried to upload g-wrap, but my upload seems to have been eaten several times. I did uploads afterward, that did got accepted, but g-wrap is constantly getting eaten. Who can I bug about this?
<pitti> siretart: let me take a look
<Mithrandir> siretart: seems like you've triggered a bug in soyuz
<Mithrandir> 11:00:24 ERROR   Exception while accepting: ERROR:  permission denied for relation bugtracker
<pitti> StevenK: /cruft/ updated
<siretart> Mithrandir: uh, shall I reupload without the Launchpad-Bugs-Fixed: magic?
<Mithrandir> siretart: probably a good workaround
<Mithrandir> I'll nag cprov when he wakes up
<siretart> willdo so. thanks
<siretart> Mithrandir: yepp, removing that line helped here
<StevenK> pitti: Thanks.
<StevenK> pitti: It was as I suspected - libavformat0d and libavcodec0d can be killed when you wish.
<pitti> StevenK: cool, thanks
<pitti> done
<pitti> StevenK: would you mind looking into what Debian did with curl? Did they add a shim to provide the old ABI as well, or did they revert an upstream version, and is there some discussion somewhere?
* StevenK twitches. Curl bad.
<pitti> StevenK: if the new package in Debian is sane, we should sync/merge it ASAP and re-rebuild the libcurl4 dependencies, I guess
<StevenK> Where's geser, he's been following this madness closely.
<ion_> Does it look like PulseAudio is going to be installed by default in gutsy, btw?
<minghua> I roughly remember Debian's curl situation
<minghua> upstream bumped SONAME version, but no actually ABI change
<minghua> Debian first changed package name, then changed back
<minghua> now libcurl3-* ships libcurl*.so.4, and a symlink of libcurl*.so.3 pointing to .so.4
<minghua> All the details should be on debian-release list
<pitti> \o/ http://ppa.dogfood.launchpad.net/ubuntu-langpack/ -> it's working! /me bounces
<StevenK> pitti: Okay, it seems that Debian has reverted to libcurl3 package names... It does mean that libcurl4 is now cruft, and not libcurl3, if we sync/merge the latest curl.
<pitti> minghua: " now libcurl3-* ships libcurl*.so.4" -> eewww
<pitti> StevenK: well, I guess we have to bite that bullet
<StevenK> As a symlink to libcurl*.so.3, even more disgusting.
<Mithrandir> pitti: if you could NEW hildon-control-panel and hildon-control-panel-l10n, that'd be good.
<pitti> we only have 10ish rdepends of libcurl4, that seems manageable
<StevenK> pitti: Would you like me to push that onto on my queue after cjwatson's suggested changes to requestsync?
<pitti> StevenK: that would be great
<pitti> StevenK: the ubuntu diff should be trivial (removing a build dep AFAIR)
<pitti> Mithrandir: is 30 minutes ok? I still have a lot of state in my head which I'd like to get written down
<StevenK> pitti: Okay, cool.
<Mithrandir> pitti: sure, no problem.
<pitti> ihatemyinternet: hey, it's our internet, too! :)
<ihatemyinternet> pitti: ;-) ihatemyisp is probably more accurate
<Daviey> ping bdmurray, BenC, or dholbach
<seb128> Daviey: you might want to give some context, they are not around
<Daviey> Just want to talk to them about a 'hug' :)
<seb128> k
<seb128> dholbach should be around in not too long
<Hobbsee> mvo: are you around?
<Hobbsee> [22:16]  [Whois]  mvo has been idle for 59 minutes and 9 seconds.
<Hobbsee> seems not.
<Daviey> thanks Hobbsee 
<seb128> Hobbsee: you might want to ask your question ;)
<Hobbsee> seb128: i could.  there are multiple things though :)
<siti> lol
<mvo> Hobbsee: yes
<mvo> Hobbsee: but hacking
<Hobbsee> mvo: right.  so i should save my question about ubuntu-restricted-extras, and recommends?
<mvo> Hobbsee: it is not working with recommends currently?
<Hobbsee> mvo: no.  it's getting fed the recommends correctly, but it's not installing them by default.
<Hobbsee> mvo: it's a metapackage, in section metapackages, so i'm not sure hwy
<Hobbsee> (thru apt, at least)
<mvo> Hobbsee: oh, that is indeed strange, does it make a difference if you run it with "apt-get install --install-recommends ubuntu-restricted" ?
<mvo> Hobbsee: what does apt-get install ubuntu-restricted -o Debug::pkgDepCache::AutoInstall=true" say?
<Hobbsee> mvo: with the first, the recommends get installed too, as expected, and the second doesnt seem to produce any different output to normal
<Hobbsee> as in, shows the recommends, but that they're not going to be installed
<Hobbsee> (can show you the output if you want, but there's nothing terribly interesting)
<mvo> Hobbsee: is that for the package that is currently in the gutsy archive? or is that for your local one? I would like to reproduce this here
<Hobbsee> mvo: it's in the gutsy archive
<Hobbsee> mainly because i was lazy and didnt want to set up a repository here.
<Hobbsee> and the previously uploaded version didnt compile (oops, dunno how i forgot to test that one)
* Hobbsee hides from the ubuntu gods with lightening bolts
* Mithrandir throws a few lightning bolts in the direction of .au
<Mithrandir> :-P
<StevenK> Ouch!
<StevenK> That *stings*
<Mithrandir> oops, I just hit the moon
* Hobbsee gets hit, and dies bloodily on the ground
<Hobbsee>  * HOBBSEE IS ON THE MOON, DAMMIT!!!!
<Mithrandir> hard to fling them over the horizon.
* Hobbsee is a green alien, after all.
* Hobbsee was holidaying there.
* Mithrandir zaps Hobbsee with a bit more lightning and thereby revives her
* Hobbsee dies more
* Hobbsee listens to the ambulances outside
<Hobbsee> or is it fire?  or police?
* Pici blinks
* StevenK whispers "yada" near Hobbsee's bloody corpse.
* Hobbsee stays dead.
* Hobbsee doesnt have to deal with yada when dead.
<StevenK> :-P
<sladen> pitti: would there be a way to tag the failed stacktraces.  hopefully they can be rerun whenever gdb/each is actually fixed
* sladen sees yet more Hobbsee change notifications appear.  people aren't going to be able to keep up!
<Hobbsee> sladen: Hobbsee change notifications?
* Hobbsee pictures Hobbsee changing from a green alien to a blue alien to a purple alien to a multicoloured alien, to a squid...
<pitti> sladen: sure, we can just invent a tag
<sladen> pitti: that's the easy bit, having apport/launchpad add it is the hard bit
<mvo> Hobbsee: the problem is that the section is multiverse/metapackages
<mvo> Hobbsee: for apt that is different from just "metapackages"
<sladen> pitti: I guess if it's an apport thing it's easy, but it's a launchpad needed change they we could be here until next year
<Hobbsee> mvo: ah, point
<pitti> sladen: ah, I see
<pitti> sladen: no, it would be changed in the retracer bot
<pitti> sladen: the entire reprocessing magic is not LP code, but my own
<sladen> pitti: apt-get source apport ?
<Hobbsee> mvo: therefore...you cant have any metapackages installing recommends that arent in apt. that sounds like a bug.
<mvo> Hobbsee: its not hard to make apt more clever, I'm just busy currently with other tasks :/
<pitti> sladen: bzr get https://code.launchpad.net/~ubuntu-core-dev/apport/ubuntu
<Hobbsee> mvo: no problem
<pitti> sladen: (as apt-get source will tell you as well nowadays \o/)
<StevenK> pitti: curl uploaded.
<pitti> StevenK: yay
<StevenK> pitti: So now you get to rescue it out of binary NEW in about 2 hours. :-)
<pitti> StevenK: oh? which binary package does it introduce?
<StevenK> Oh, wait. If libcurl3 hasn't been NBS'd, you don't.
<pitti> StevenK: no, not with that insane list of rdepends :)
<StevenK> Heh
<StevenK> Actually, you'll need to regenerate cruft in 2 hours to deal with libcurl4, not 3.
<dholbach> hi Daviey
<StevenK> pitti: cmus now Build-Depends on libfaad2-dev. Should we just drop it to multiverse?
<pitti> StevenK: sounds fine
<StevenK> pitti: Can you throw the magical switch then, please?
<pitti> thrown
<StevenK> Danke
<StevenK> pitti: After the curl mess is sorted out, it looks like the largest transition is libflac.
<mdz_> pitti: I just had apport decline to file a bug because it said it was already reported 'in the bug displayed in the web browser', but nothing was displayed, and I got an error from firefox about it already running
<mdz_> pitti: was it trying to launch the browser as root or something?
<mdz_> (this was a system daemon crash)
<pitti> mdz_: apport GUI itself is ran as root, but it tries very hard to start firefox as user
<pitti> mdz_: every other browser works without a hitch, but firefox just fails with that sometimes
<pitti> I didn't yet find out why
<pitti> I pass the necessary environment variables etc.
* StevenK stares at cynthiune.app. What the hell is this written in?!
<pitti> mdz_: do you already have a firefox open?
<mdz_> pitti: I just tried again, and it still doesn't display in the browser, and no error this time
<mdz_> pitti: yes
<persia> StevenK: ObjectiveC?
<StevenK> persia: Does that use .m and .h?
<pitti> mdz_: so it opened ffox, but doesn't load any page?
<pitti> mdz_: might be a broken bug pattern; which package is this for?
* persia looks at cynthiune.app, having not used ObjC in long enough to be unsure
<StevenK> error: expected specifier-qualifier-list before 'FLAC__FileDecoder' -- and I'm neatly unsure what that means. :-)
<StevenK> I've never needed to touch ObjC.
<persia> StevenK: Yep.  That's Objective C.
<StevenK> Hrm. I think curl's binaries are going to miss this publisher run.
<StevenK> persia: And what about the compiler error? :-)
<persia> StevenK: I appear to be having difficulties with my disks currently, so I can't reproduce.  I'm searching now (is this a good time to mention that my one (1) engagement with Objective C was to reverse-engineer a replacement in Java?)
<siti> mvo: https://bugs.launchpad.net/ubuntu/+source/gdebi/+bug/87029  I am getting this problem in gutsy
<ubotu> Launchpad bug 87029 in gdebi "[apport]  gdebi-gtk crashed with error in finish_dpkg()" [Medium,Fix released]  
<StevenK> persia: Ohh.
<persia> StevenK: It appears that a specifier-qualifier-list is something of the form "const long" (that's actually the qualifier followed by the specifier).
<persia> StevenK: http://objc.toodarkpark.net/objctoc.html might be interesting reading
<mvo> siti: let me check
<StevenK> persia: But how am I supposed to qualify something that is a struct?
<persia> StevenK: use the struct-or-union-specifier or the struct-or-union-identifier, I think.
<persia> StevenK: In comprehensible language: put the name of whatever it is before the thing that returns it.
<StevenK> That isn't very comprehensible. :-)
<persia> StevenK: Sorry.  It made more sense to me than the first thing I said.  From what I understand, it's complaining that FLAC__FileDecoder is untyped, and wants a type.  Either the syntax in the area is generally wrong, there is an issue with namespaces, or you need to insert the struct-or-union-specifier for the return type of FLAC__FileDecoder before the declaration (or something).  I would probably make more sense with a pastebin to look at :)
<StevenK> Way cool.
<StevenK> Launchpad is reporting that cmus 2.1.0-2ubuntu1 is both Published and PendingRemoval in multiverse.
<pitti> StevenK: hm, is there a new version of it?
<StevenK> Not that I can see.
<StevenK> persia: I think the *real* reason is that the FLAC header files no longer declare FLAC__FileDecoder.
<persia> StevenK: That would certainly do it.  Unless you're especially daring, I'd suggest hunting an expert in Objective C (or reading the manual not a few times) prior to attempting a patch.
<StevenK> It seems I'm especially daring, given I've just fired off another test build
<persia> StevenK: Best of luck :)
* StevenK watches it blow up.
<StevenK> Oh, it helps if you pass the right .dsc to sbuild. :-P
<iwj> StevenK: The __ suggests to me that it's an internal name, not intended for use by things outside the flac libraries.
<StevenK> iwj: It seems everything in FLAC starts with FLAC__.
<iwj> Weird.
<StevenK> iwj: Weird seems to describe FLAC quite well. :-)
<StevenK> Why I'm up fixing a package that Build-Depends on it at quarter to 1 escapes me, though.
<pitti> StevenK: ah, indeed curl is in NEW due to libcurl3-dbg *grumpf*
<pitti> StevenK: built on all 5 arches, NEWed
<StevenK> Hah! I win!
<StevenK> Ahem. Or something.
<StevenK> pitti: Thanks.
<pitti> np
<StevenK> Just in time for the next publisher run.
<ScottK> pitti: Woud this be a decent time to harass you about my MIR?
<pitti> ScottK: let me open a tab for that to do it tonight
<Hobbsee> hehe
<pitti> ScottK: pinentry, right?
<ScottK> pitti: Yes - https://wiki.kubuntu.org/MainInclusionReportPinentry
<Hobbsee> pitti: it's after breakfast.  keep putting it off :P
<ScottK> pitti: Thanks.
<agoliveira> Hi guys. I think I found another bug regarding instalation. I dont' have the means to send a log now but for what I can see, something called ma-search-users crashed badly with a glibc error "corrupted double-linked link". Anyone wants to talk about it?
<agoliveira> I mean, Gutsy Tribe 2
<cjwatson> agoliveira: that would be evand
<evand> arr
<agoliveira> Oh, indeed.
<agoliveira> evand: So, what to check it out?
<geser> StevenK: Hi, I see that curl was merged
<evand> agoliveira: can you file a bug and attach /var/log/syslog from the livecd.  Let me know the number and we'll go from there.
<geser> any reason why curl 7.16.2-6 wasn't merged?
<agoliveira> evand: Sure.
<evand> thanks
<agoliveira> evand: Hmmm... the bug does not show up in /var/log/syslog. I saw it because I had to run ubiquity in a terminal. Does this log go anywhere else?
<Hobbsee> geser: i think StevenK has something to do with it
<StevenK> geser: Because MoM didn't tell me about it?
<cjwatson> evand: while randomly looking at ma-search-users.c I noticed that it calls opendir but never calls closedir
<geser> StevenK: the little bit I know about that libcurl mess, I attached as a comment to bug #122775 (which can be closed now btw)
<ubotu> Launchpad bug 122775 in curl "merge curl 7.16-5 from Debian unstable (main)" [Undecided,New]  https://launchpad.net/bugs/122775
<evand> hilarity.  That code is a bit of a mess in general, I'll take a look and push out a slightly less buggy version.
<evand> thanks for the heads up
<geser> StevenK: so that means that the packages upload for a libcurl3 -> libcurl4 transition can now be uploaded again for libcurl4 -> libcurl3?
<StevenK> geser: Yes.
<StevenK> geser: I will merge -6 when MoM/ftp.d.o catch up
<StevenK> And of course packages.d.o doesn't know about -6. POS.
<geser> StevenK: I usually use the PTS for such thinks and it knows about -6
<StevenK> geser: Yes, but I can't read the changelog with the PTS.
<geser> it would be good to merge -6 soon, as else pacakging still depending on libcurl3 get broken as the symlink from libcurl3*.so to libcurl4*.so is missing
<geser> unfortunately the PTS is missing currently the recent changelog (ends at -5)
<evand> agoliveira: on second thought, can you run through with --debug.  It might give me a slightly better idea of why it's failing. (Attach /var/log/installer/debug)
<StevenK> pitti, geser: curl 7.16.2-6ubuntu1 uploaded.
<pitti> yay
<StevenK> geser: Now, shush
* StevenK did the merge completly manually, just to quieten geser.
<agoliveira> evend: I have to go lunch in a few minutes but I'll try that as soon as I return, ok?
<evand> sounds good, thanks again
<agoliveira> My pleasure
<StevenK> pitti: Let's leave re-running the cruft until you re-surface tomorrow, methinks.
<geser> StevenK: thanks, I will start upload packages from universe for the libcurl4 -> libcurl3 transition in a few days (probably the second half of this week)
<geser> StevenK: btw apt-cache lists currently only 43 rdepends for libcurl3* and 90 for libcurl4*, so we had already done the most part of the libcurl3 -> libcurl4 transition
<pitti> geser: urgh? apt-cache rdepends libcurl4|wc -l says 19 here, and that includes some noise
<pitti> geser: ah, erk, -gnutls
<geser> pitti: libcurl4 (no SSL, dropped again), libcurl4-gnutls and libcurl4-openssl
<pitti> geser: right, I didn't consider that
<geser> let's hope this libcurl mess is finished soon
<mvo> hey glatzor_
<glatzor_> servus mvo
<agoliveira> evand: I just did what you said. The error I found shows up in the console so I captured it too just as it happens. After that I canceld the instalation as I recall it does not happen again. Do you want me to open a bug and attach it or send the files for you directly?
<agoliveira> s/said/asked
<evand> bug please
<agoliveira> Sure do.
<Daviey> BenC: Hey, are you about?
<BenC> Daviey: yeah
<Daviey> Hey, can i pm quickly?
<BenC> Sure
<agoliveira> evand: Here it goes - https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/123584
<ubotu> Launchpad bug 123584 in ubiquity "ma-search-users crash when installing Gutsy Tribe 2" [Undecided,New]  
* agoliveira thinks obotu is to noisy :)
<evand> thanks agoliveira.  I'll follow up from there.
<agoliveira> evand: No problem. If you need anything else, just ping me.
<ogra> agoliveira, nah, you are :) sayiung bug #123584 would suffice to trigger it ;)
<ubotu> Launchpad bug 123584 in ubiquity "ma-search-users crash when installing Gutsy Tribe 2" [Undecided,New]  https://launchpad.net/bugs/123584
<mikmorg> cjwatson: ping
<cjwatson> mikmorg: hi
<LaserJock> cjwatson: are you available for a little debian-cd chat?
<cjwatson> LaserJock: now's not a great time
<LaserJock> cjwatson: ok, that's fine
<cjwatson> sometime, sure
<LaserJock> cjwatson: I've got a bzr branch on LP with changes for Edubuntu's addon cd
<LaserJock> another time is fine
<mikmorg> cjwatson: Hello again.
<siretart> Mithrandir or cjwatson: please reject the gnochm upload to feisty-proposed. Clearly a mistake on my part, sorry :(
<micahcowan> Would anyone like to sponsor my fix to vim/screen interaction (plus a typo in filetypes.vim)? bug 113227. cjwatson, particularly (since you uploaded the last vim).
<ubotu> Launchpad bug 113227 in vim "Incomplete/broken mouse handling in screen" [Wishlist,In progress]  https://launchpad.net/bugs/113227
<cjwatson> mikmorg: hello, only here briefly though. UK evenings tend not to be good times for me
<cjwatson> micahcowan: opened in my web browser for attention tomorow
<cjwatson> tomorrow
<micahcowan> cool, thanks much! :)
<Chipzz> micahcowan: I don't think that fix is correct actually
<Chipzz> micahcowan: I think this comment is actually correct (or half-correct):
<Chipzz> https://bugs.launchpad.net/ubuntu/+source/screen/+bug/113227/comments/4
<ubotu> Launchpad bug 113227 in vim "Incomplete/broken mouse handling in screen" [Wishlist,In progress]  
<Chipzz> micahcowan: IIRC there are 3 mouse protocols
<micahcowan> Chipzz, it has been approved upstream (not yet in upstream source, though)
<micahcowan> Was discussed fairly well on the ML (which has been down for the last few weeks, but you can see the archives).
<Chipzz> micahcowan: I think the actual bug is that the termcap/terminfo for screen is incorrect
<micahcowan> Chipzz, there is no means for termcap/terminfo to specify xterm-style mouse support.
<micahcowan> Nor the other two protocols. Only the basic kmous.
<micahcowan> Why did you give the link to my own comment?
<Chipzz> one sec
<Chipzz> take a look at:
<Chipzz> http://chipzz.safehex.be/docs/rxvt-2.16/rxvt.ref
<Chipzz> and
<Chipzz> http://chipzz.safehex.be/docs/rxvt-2.16/dec_vt_mouse.html
<micahcowan> Chipzz, what about them? I'm familiar with the escape sequences. My point is, terminfo/termcap do not have methods for specifying them nor their support.
<micahcowan> They should, and that would be the better fix (I'm going to try to work with the ncurses team to make that happen), but in the meantime, checking the TERM value is how most apps are doing it (and how vim has been). My fix just ensures that screen is one of those accepted values (since it handles mouse sequences corretly, both in the case that it's being used by an "xterm", and when it's not).
<micahcowan> Some ncurses-based apps also use the presence of kmous to indicate that the terminal also supports appropriate DEC/xterm-style mouse sequences, even though they really don't have anything to do with eachother. screen does lack kmous (no idea whether screen supports kmous); however, its presence would do nothing to resolve this issue, as vim doesn't check kmous to determine this.
<Chipzz> hrrrm ok
<Chipzz> I thought there was a way to check it
<micahcowan> Yeah, I wish :/
<agoliveira> kylem: yo! ping?
<micahcowan> There's a couple other things that it would be nice for terminfo to support, such as the use of modifiers with special keys (like the cursor keys).
<Chipzz> problem is, won't do you much good in the end
<Chipzz> ncurses is built on top of termcap/terminfo
<Chipzz> and even you fix it in ncurses
<Chipzz> you still have a whole list of other OS's which it won't work on
<Chipzz> legacy, legacy, and then some more legacy :P
<kylem> agoliveira, ?
<agoliveira> kylem: Hi. Stupid nOOb question: I want to try to create a device driver for an USB device in my spare time, any pointers on how to reverse engineer such a beast? There's no docs on it that I'm aware of.
<agoliveira> kylen: ... if you ever tried that, I don't know ;)
<kylem> if you have a windows driver, it's pretty easy
<agoliveira> kylem: Yes, there is.
<kylem> you can log all the usb urbs submitted to the device fairly trivially, there's some usb snooping drivers for windows/linux/macosx.
<kylem> usb is actually one of the most pleasant protocols to reverse engineer, heh
<agoliveira> kylem: Hmmm... so I think that's the way I go. ANy pointers to suitable docs?
<kylem> agoliveira, http://sourceforge.net/projects/usbsnoop/
<agoliveira> Cool. In case you're wondering, it's a simple stupid thing. I got one of this http://www.notebookreview.com/default.asp?newsID=3403 and I want to create a device for the small OLED display on the top.
<agoliveira> kylem: Thanks man. I'm closing the shop for today. Bye.
<kylem> night.
#ubuntu-devel 2007-07-03
<mikmorg> cjwatson: If you happen to still be around, I was wondering if I can trust Ubiquity to run /usr/lib/ubiquity/target-config AFTER it removes dpkgs based on the manifest diff?
<rproenca> hi mpt. when you have a couple of minutes I'd like to talk with you and hear your suggestions for a better naming of some terms used on aptoncd
<mpt> rproenca, hi
<rproenca> rproenca: Hi. If you don't mind, can we talk about your suggestions?
<mpt> sure
<rproenca> mpt: To don't flood the -devel with some OT content, you can join with me at #aptoncd, please
<mpt> ok
<LaserJock> StevenK: you around?
<StevenK> LaserJock: Nope. :-P
<Hobbsee> morning all
<LaserJock> hi Hobbsee 
<Hobbsee> :)
<Hobbsee> someone's alive :)
<LaserJock> somebody is always alive
<Hobbsee> LaserJock: it seems quiet today.  really quiet
<Hobbsee> i mean, quieter than the weekends usually are
<LaserJock> mhm
<ScottK> Good morning Hobbsee.
<Hobbsee> morning ScottK!
<evand> morning Hobbsee, ScottK, LaserJock, others
<LaserJock> hi evand and ScottK 
<ScottK> Heya LaserJock.
<zakame> yo LaserJock 
<ScottK> LaserJock: Have you done much with gpg?
<LaserJock> ScottK: not other than signing packages
<LaserJock> yo zakame 
<LaserJock> zakame: how's it going?
<ScottK> LaserJock: OK.  Thanks.
<LaserJock> ScottK: and I only recently started using seahorse for a key agent
<LaserJock> I've always done it the "hard" way
<ScottK> Ah, well then you'
<ScottK> ...
<ScottK> ll be glad to know that debuild will now work with seahorse-agent in Gutsy.
<persia> ScottK: It works fine, with no messy .devscripts adjustments.
<ScottK> Yep.  Thanks for testing it persia.
<ScottK> Thanks StevenK for fixing it.
<Hobbsee> heya evand!
<zakame> LaserJock: looking at some revus now
<zakame> the past couple of days have been terrible, with no electricity and all...
<LaserJock> ah
<Hobbsee> zakame: check licencing, else Mithrandir will eat you
* persia continues to believe that *eat* is not the appropriate verb in this context.  Smite, maybe.  Perhaps malign or defame, but "eat"?
<zakame> Hobbsee: pointers to said eatings?
* ScottK thinks persia hasn't met Mithrandir.
<Hobbsee> zakame: motu mailing list was his annoyed mail
<Hobbsee> zakame: he tends to take his victims into his cave, and eat them there, so it wouldnt be public
<Hobbsee> persia: yes, eat.  You'll meet Mithrandir one day, i'm sure.
<Hobbsee> he likes threatening to eat people :P
<zakame> ah, /me syncs
<zakame> lolgrue
<Hobbsee> oh *darn*.  i remember what i was going to discuss with pitti now.
<ScottK> It was the pinentry MIR, wasn't it?
<Hobbsee> no
<ScottK> Oh well.
<StevenK> ScottK: If you recall the "I want a pony" link and picture on fridge.u.c, that used to be MIR. :-P
<StevenK> IE: "No MIR for you!"
* ScottK thinks Hobbsee wants what that MIR will bring, so retains hope.
<Hobbsee> hehe
<ajmitch> better to eat people than throw them into a pool
<ScottK> And don't throw anyone whose eaten someone in the pool until after they've had 30 minutes to digest.
* Hobbsee grumbles at horrible people like ajmitch 
<ajmitch> heh
<Hobbsee> You know, i wish that part of trademark policy stated that "if you want to make a custom cd distro, please point your bugtracker somewhere else"
<LaserJock> heh
<ScottK> Hobbsee: What are you getting bugs from?
<Hobbsee> ScottK: ubuntu CE, ubuntu lite, ubuntu mint, ubuntu + automatix/...
<Hobbsee> the mint ones, particularly
<Hobbsee> well, linuxmint.
<ScottK> Ah.
<LaserJock> Hobbsee: well, Launchpad is supposed to be used by many distros
* ScottK just periodically searches LP for bugs with the phrase automatix and rejects most of them (a few look legit).
<Hobbsee> LaserJock: true - but they tend to get their bugs filed in the source pacakges of ubuntu
<Hobbsee> oh, and that they need to have a custom distro name in their /etc/lsb_release.
<Hobbsee> (so we can pick out their bugs)
<minghua> Hobbsee: they use Ubuntu in /etc/lsb_release?
<minghua> That's really bad.
<Hobbsee> not positive..
<Hobbsee> i think some of them do - or did
<StevenK> Maybe Ubuntu CE needs a bug tracker where they are refered to as 'divine interference' instead of bugs.
* Hobbsee snorts
<minghua> Speaking of LSB, is there a way using lsb tools to differentiate Ubuntu and Kubuntu?
<Hobbsee> i like that
<fabbione> morning
* StevenK waves to fabbione
<Hobbsee> morning fabbione!
<Hobbsee> minghua: i think kubuntu currently has hte same stuff as ubuntu in the lsb stuff
<minghua> Hobbsee: Yeah, I think it should as it use the same lsb* packages as Ubuntu.  Hence my question.
<Hobbsee> bug #15739
<ubotu> Launchpad bug 15739 in Ubuntu "libgd: new changes from Debian require merging" [Medium,Fix released]  https://launchpad.net/bugs/15739
<Hobbsee> minghua: ah right.  it does
<LaserJock> minghua: I think most derivs don't even know what /etc/lsb_release is
<minghua> :-(
<dholbach> good morning
<Mithrandir> iz Daniel in many channels
<dholbach> hey ccm
<LaserJock> hi dholbach 
* StevenK waves to dholbach
<dholbach> hiya LaserJock
<dholbach> hey StevenK
<ccm> hey, dholbach 
* Mithrandir jumps on SK
<StevenK> Ooof
<StevenK> I hardly know you!
<ccm> i am suprised how many karma points launchpads gives you for answering questions
<dholbach> that never stopped Mithrandir from doing anything :)
<StevenK> pitti!
<dholbach> hey pitti
<LaserJock> hiya pitti 
<pitti> Good morning everyone
<StevenK> pitti: Re-run the cruft checker at your leisure, please.
<pitti> StevenK: I will; and I'll finally take some time to set up an automatic one
<StevenK> Yay!
<Hobbsee> morning pitti!
<pitti> hey Hobbsee 
<StevenK> pitti: The last 45 of 46 mails in my INBOX are Accepted mails, with 1 being a build failure on ia64.
<pitti> StevenK: wow, curl? :)
<StevenK> Nah, I've been working through flac as best I can.
<pitti> erk, I'm sorry for DoSing the PPA buildd: https://dogfood.launchpad.net/+builds/rubidium/+history
<Hobbsee> haha
<Mithrandir> heh
<StevenK> The problem with flac is the API changed in incompatible ways, and worse, the virtual-ness of some objects have changed, which leads to some build failures.
<Mithrandir> morning Hobbsee
<Hobbsee> morning Mithrandir!
<StevenK> pitti: I plan on doing most of curl tonight, if I can.
* pitti puts the "Mr. Archive-Proper" Badge on StevenK's chest
* StevenK grins
<LaserJock> StevenK: what is it that you're doing?
<Hobbsee> he's breaking things
<StevenK> LaserJock: A metric shedload of rebuilds for archive cruft. And being pitti's hero in the process.
<StevenK> And what Hobbsee said.
<LaserJock> oh, excellent
<LaserJock> I love those kinds of QAish things
<lifeless> StevenK: I don't think thats the *only* problem with flac :)
<StevenK> lifeless: Agreed. :-)
<sladen> morning all
<Hobbsee> hi sladen 
<pitti> StevenK: cruft updated
<pitti> hey seb218
<pitti> hey seb128, too
<seb128> hello pitti
<StevenK> pitti: Thanks
<StevenK> Ugh. oo.org is in the list for libcurl4.
<pitti> StevenK: better leave that to doko; unnecessary rebuilds are a pain
<StevenK> I was planning on.
<StevenK> Given it also seems to take 2 rubber chickens and goat to get oo.org to build sucessfully.
<pitti> StevenK: at this point I wonder whether it wouldn't make more sense to have libcurl3 Provide: libcurl4
<LaserJock> StevenK: rubber chickens?
<pitti> StevenK: instead of going through all this rebuild mess
<StevenK> Hrm.
<pitti> StevenK: for all practical purposes, ABI 3 and 4 are the same now, right?
<StevenK> It's a symlink, so I don't think there are any differences at all.
<StevenK> But since libcurl4 has existed before, we can't use versioned Provides.
<pitti> StevenK: ok, then maybe introducing a dummy package which just depends on libcurl3
<Mithrandir> well, apart from the fact that our packaging system doesn't support versioned provides?
<siretart> hrmpf. for some reason, gdm thinks my $HOME was full or not writable. I cannot find a report in launchpad, but wanted to ask if someone has already observed that behavior (current gutsy, that is)
<StevenK> Which is then another change away from Debian, and may bite us the next time they update curl.
<Mithrandir> StevenK: they won't move to libcurl4, that soname is used now.
<seb128> siretart: what permissions do you use for the directory?
<siretart> seb128: I tried even with 777 for my home, no change (and disk is NOT full)
<StevenK> libcurl4 -> libcurl5 (if it happens) will be a barrel of laughs.
<seb128> siretart: the partition didn't get remounted ro due to errors or something?
<pitti> StevenK: that's what I mean with 'for all practical purposes' -> upstream has to bump to 5 next time
<StevenK> pitti: If you think that's a way out of this mess, I'm happy to upload curl again.
<siretart> seb128: no, it is writable. I can work as normal after I got login
<pitti> StevenK: let's think about it a bit deeper, wrt. shlibs files and such
<pitti> siretart: please ask iwj; he recently did some experiments and changes for handling a full $HOME
<siretart> seb128: it's just that gdm complains about .dmrc not writable, and places my XAUTHORITY to /tmp
<seb128> siretart: k, so I don't know, you are the first to complain about it on gutsy
<StevenK> pitti: By my count there is ~ 40 rebuilds for curl4.
<pitti> siretart: maybe he left some piece of testing code somewhere
<pitti> StevenK: hm, 40 rebuilds wouldn't be too bad, but it's still a nuisance
<seb128> siretart: active debug mode and look to the log maybe
<StevenK> pitti: *nod*
<siretart> seb128: how to do that?
<siretart> gdm.conf?
<seb128> siretart: run gdmsetup and click the option
<siretart> ah, ok
<seb128> it's in the security tab
<pitti> StevenK: but I can't see anything wrong with a dummy libcurl4 which depends on libcurl3; if the shlibs point to 3, rebuilds will ignore it, and the installed system should cope because the 4 symlink is in libcurl3
<siretart> found it
<StevenK> And if packages depend on libcurl4 currently, and get rebuilt, they'll jump over to libcurl3, which is no bad thing.
<pitti> StevenK: right, so at the end of gutsy we might get rid of it again
<StevenK> Exactly.
<pitti> . o O { and if Debian decides to go back to four, we are prepared }
<pitti> :)
<StevenK> Heh
<StevenK> pitti: I'll start on preparing an upload when I get home, and point you at a debdiff.
<pitti> StevenK: cool, thanks
<siretart> seb128: nope. nothing interesting neither in ~/.Xsession-errors nor in /var/log/gdm/:0.log
<seb128> siretart: and /var/log/syslog?
<siretart> wow, there's more (and partly localized!)
<siretart> Jul  3 09:39:18 faui44a gdm[17695] : WARNING: gdm_slave_session_start: Gruppe hat Schreibzugriff auf /home/siretart. 
<seb128> ah, right, gdm doesn't like having user directory writable for other users
<siretart> it complains if the group has write access?!
<siretart> WTF?!
<seb128> it considers it not secure
<seb128> it should be +w for your user only
<siretart> retrying
* siretart hugs seb128 
<siretart> seb128: that did the trick
<seb128> ;)
<siretart> okay, now I can retitle and correct my just filed bugreport
<seb128> 			       _("User's $HOME/.dmrc file is being ignored.  "
<seb128> 				 "This prevents the default session "
<seb128> 				 "and language from being saved.  File "
<seb128> 				 "should be owned by user and have 644 "
<seb128> 				 "permissions.  User's $HOME directory "
<seb128> 				 "must be owned by user and not writable "
<seb128> 				 "by other users."));
<seb128> 
<seb128> that's the normal error message
<seb128> you didn't get it?
<siretart> it is NOT writeable by other users
<seb128> it was g+w no?
<siretart> I have my own user group (named like my username), which has no other users
<siretart> so there are no other users with write permissions there
<seb128> you mentionned trying 777 before
<siretart> the error messages says 'should not' not 'must not'
<siretart> that was for debugging, normally I have it set to 775
<siretart> TBH, I copied my home directory from my debian system. the gdm over there didn't complain about this
<siretart> so therefore I didn't notice that
<seb128> we don't change gdm
<seb128> so either Debian patch gdm to not display the warning or the upstream behaviour changed in a new version
<seb128> right, it happens when the directory is g+w
<siretart> I strongly recommend to s/should be owned/must be owned/ in the error message
<siretart> because that's closer to the truth
<seb128> feel free to update the bug description with suggestions on what you would change ;)
<siretart> I rejected the bug for now
<siretart> but the behavior on user home set to 775 should get more though. I need to think about it
<pitti> Mithrandir: hm, I NEWed the hildon-contol-l10n thing yesterday, but the other package is still not in NEW; it's FTBFS?
<Mithrandir> pitti: yes, I fixed it this morning, it should be there in about an hour.
<Hobbsee> Mithrandir: did you ever find out what happened to the developer weather report?
<pitti> Mithrandir: ah, the symlinks to auto* stuff?
<Mithrandir> yes
<pitti> Mithrandir: I noticed them, but I thought you would b-dep on autotools or so
<Mithrandir> pitti: yes, that would have been bright to do. :-)
<Mithrandir> Hobbsee: disappeared into the whole named "ENOTIME", iirc.
<Hobbsee> Mithrandir: right.  dont suppose anyone published notes about them somewhere?  i know bdmurray had a lot
<Hobbsee> Mithrandir: or that fell into the "ENOTIME" hole too?
<Mithrandir> Hobbsee: I think sobby might have eaten them for breakfast.
<Hobbsee> tasty.
<Hobbsee> then i'll grab them off bdmurray, as i noticed he was writing them in vi.
<Hobbsee> or, attempt to
<Hobbsee> Mithrandir: you should really make sure you feed sobby a bit more...
<Hobbsee> maybe then it wouldnt eat things it's nto supposed to
<Hobbsee> hi jono 
<persia> There's a patch for sobby eating things on Launchpad.  Anyone want to test it?
<lifeless> have we dropped breezy backports ?
<Fujitsu> lifeless: Breezy has been dead for a while, so yes.
<jono> hey
<lifeless> that would explain the conflict checker errors
<lifeless> hiya trouble
<Fujitsu> Right, why did mysql-server-5.0's postinst cause 
<Fujitsu> *cause my kernel to OOPS repeatedly?
<lifeless> mvo: conflictchecker is running on macaroni now
<lifeless> just need a bzr version thats not prehistoric :)
<mvo> lifeless: heh :) good news!
<lifeless> in a role account
<Hobbsee> lifeless: there's a machine named macaroni?
<pitti> doko: does http://packages.qa.debian.org/z/zope3/news/20070625T194326Z.html mean that we can sync now?
<lifeless> Hobbsee: :)
<Hobbsee> :
<Hobbsee> :)
<lifeless> http://macaroni.ubuntu.com/~conflictchecker/
<Mithrandir> Hobbsee: it's a kind of penguin, so yes, naturally we have a machine called macaroni.
<Mithrandir> Hobbsee: more confusing is we have a machine named gentoo..
<Hobbsee> Mithrandir: heh
* Hobbsee wants a macaroni penguin!
<pitti> erk, I never actually uploaded the new hal
<lifeless> mvo: progress: http://macaroni.ubuntu.com/~conflictchecker/possible-conflicts.txt
<ogra> our kernel source doesnt ship any oss headers anymore, does anyone know if thats an upstream drop ?
<shawarma> ogra: Which header in particular are you looking for?
<StevenK> pitti: http://wedontsleep.org/~steven/curl.debdiff
<ogra> shawarma, ac97.h and soundcore.h from the oss subdir for example 
<ogra> shawarma, seems with .21 all of that was dropped, i have a very popular (even though very bad) thin client that only has an oss driver ...
<Mithrandir> mvo: did you end up writing a spec about the upgrader for mobile?
<ogra> i'd like to have a sis7019-source package so people can at least build the driver ... 
<shawarma> ogra: They're still in the kernel source.. Hm.
<ogra> and i need to know if its safe to delive the headers inside that package or if the oss headers might come back or something
<ogra> shawarma, i only found alsa headers n ym source 
<ogra> *in my
<ogra> (note there is an ac97 for alsa as well as one for oss)
<pitti> StevenK: I would change the "Depends: libcurl3" line to have an (= ${binary:Version}); similar for the Depends: libcurl3-gnutls one
<shawarma> ogra: ./sound/oss/ac97.h is in my tree.
<StevenK> Ah, good point.
<shawarma> ogra: git tree, that is. Not from linux-source-2.6.22. I don't know about that one.
<StevenK> pitti: debdiff updated.
<ogra> ogra@laptop:/opt/ltsp/i386/root$ ls /usr/src/linux-headers-2.6.22-6-generic/sound/oss/
<ogra> dmasound  emu10k1  Kconfig  Makefile
<pitti> lol @ "This is a transitional package depending on the older (newer) SONAME of libcurl"
<shawarma> ogra: What about /usr/src/linux-headers-2.6.22-6 ?
<pitti> or wasn't it the newer (older) one?
<StevenK> pitti: :-)
<ogra> shawarma, same
<StevenK> It's older now, since libcurl3 is the real library and libcurl4 is a symlink
<ogra> shawarma, i'm fine if they are gone :) i just dont want to clash
<pitti> StevenK: Section: libs -> Section: oldlibs (minor nitpick only)
<ogra> i'm also pretty sure there are no oss drivers at all in the archive anywhere
<pitti> StevenK: looks good to me otherwise
<ogra> so it wouldnt be a loss :)
<StevenK> pitti: For both curl4's?
<pitti> StevenK: yes, I think so
<pitti> StevenK: really just a cosmetical detail, though
<doko> pitti: no, zope3 has a different source tarball, unfortunately
<doko> did do it manually
<pitti> doko: ah, ok
<StevenK> pitti: Done, and uploading.
<Hobbsee> StevenK: next thing they'll do is probably go to libcurl3.5
<ogra> shawarma, 2.6.20 seems to be the last that had them
<StevenK> Pity that I just missed the publisher.
<Mithrandir> Hobbsee: libcurl3.14.15.9 ?
<ogra> (here at least without git)
<Hobbsee> Mithrandir: even better.
<StevenK> But TeX already has that numbering scheme.
<Mithrandir> so somebody is then bound to port curl to TeX
* StevenK sobs.
<Hobbsee> Mithrandir: and build it with yada.
* StevenK sobs louder
<Hobbsee> Mithrandir: and then request a MIR for it, 
<StevenK> curl is already in main.
<Hobbsee> oh, damn.
<Mithrandir> BAD Hobbsee 
<Hobbsee> so it is
* Hobbsee looks around innocently
<Hobbsee> me?  bad?
<pitti> hi thekorn 
<pitti> thekorn: looking forward to use the new p-lp-bugs API :)
<Hobbsee> Mithrandir: i couldnt possibly be bad!
<thekorn> hi pitti, thanks for your mail
<ogra> hi thekorn , oh what a nice domain :)
* pitti hugs thekorn for being one of the (apparently very few) active GSoCers
* ogra is happy to see soeone from hannover :)
<Hobbsee> Mithrandir: "tell him he's dreaming, son"
<Hobbsee> actually, probably only people like StevenK will get that.
<shawarma> ogra: Ah, it seems that nowadays only the .h-files from include/ is put into the linux-header-* packages.
<ogra> shawarma, do you know if it will stay that way ?
<shawarma> ogra: No clue.
<ogra> who would know ? BenC ?
<shawarma> ogra: Why doesn't the kernel package build your driver? 
<shawarma> ogra: Probably.
* thekorn hugs pitti back
<ogra> shawarma, there is no package, i have a sis7019.c file, thats all 
<shawarma> ogra: I meant our official, normal kernel package.
<ogra> shawarma, we dont build/ship/support oss :)
<shawarma> ogra: The header files you're missing are still in linux-source-2.6.22, aren't they?
<StevenK> Hobbsee: Heh
<StevenK> Hobbsee: Great movie. :-)
<shawarma> ogra: We ought to for stuff that's not supported by ALSA, I think.
<Hobbsee> StevenK: yup :D
<shawarma> ogra: that would be the right thing to to.
<shawarma> ogra: do, even.
<ogra> shawarma, thats would break a lot in our setup i think
<ogra> this is a very very rare case, usually there is an alsa driver ...
<shawarma> ogra: Just adding an extra driver?
<ogra> hmm
<shawarma> sounds pretty innocent to me.
<ogra> you need to configure it 
<ogra> it needs setup in modprobe.d etc
<shawarma> ogra: Ah..
<ogra> and it needs oss stuff in the back (i.e. ac97_codec for oss)
<shawarma> ogra: Right, ok. 
<shawarma> ogra: This is not a very common thin client, I suppose?
<ogra> i'm fine with either having a source package the users can build with m-a or a binary in universe or so
<ogra> it will become a very common one
<ogra> shawarma, http://www.compactpc.com.tw/ebox-2300.htm
<ogra> you can get it for $80
<ogra> its as small as a CD and you can attach it to the back of most flat panels
<ogra> (its the wrost HW ever though)
<pitti> ScottK: pinentry> it b-deps against glib/gtk 1.2, which we want to get rid of in main; does the package support 2.0 as well? please disable gtk or use 2.0
<ogra> if you ever want to see how nautilus draws the background use that thing at 1600x1200 resolution :)
<Burgundavia> ogra: I was fixing a pc for friend with a Dell 27" screen. 2560x1600
<ogra> Burgundavia, well, but thats wasnt a 200Mhz one with badly supported shared graphics
<ogra> i guess
<siti> Burgundavia: 30" runs at that res 
<Burgundavia> siti: it might have been 30". I was big and I wanted it
<siti> :)
<seb128> pitti: I've just removed gstreamer0.8 from the archive
<pitti> ScottK: https://wiki.kubuntu.org/MainInclusionReportPinentry updated
* Fujitsu applauds seb128.
<pitti> seb128: yay!
* Hobbsee hugs seb128. yay!
<seb128> ;)
<StevenK> seb128: Yay!
<ogra> seb128, poor Hobbsee, now she has to explain it to shirish
<Hobbsee> ogra: explain what now?
<seb128> ogra: lol
* ogra waits for the mail to devel-discuss
* Fujitsu shudders at the mention of that name.
<Fujitsu> ogra: Hahahah.
<ogra> Hobbsee, gstreamr0.8 was just dropped :)
<StevenK> ogra: That's naughty.
* ogra goes to the corner
<seb128> ogra: "gstreamer0.8|0.10-swfdec in launchpad" on the mailing list
<ogra> yeah :)
<Hobbsee> ogra: i realise that, but what's that got to do with shirish?
<ogra> Hobbsee, now there is no "gstreamer0.8-swfdec anymore
<seb128> Hobbsee: he's the one who sent the mail on the mailinglist
<Hobbsee> ogra: ah right
<Hobbsee> seb128: yeah, i remember that much.  didnt remember that he was talking about 0.8-swfdec though
<Hobbsee> seb128: according to him "You're a good MOTU" iirc :P
<Hobbsee> ogra: no, i can just ignore him, on the basis that it's against the COC to tell him what i really think.
<pitti> pdflatex: symbol lookup error: pdflatex: undefined symbol: _ZN12GlobalParamsC1EPc
<pitti> arrgh
<pitti> seb128: ^ poppler love again? :/
<seb128> Mithrandir: hildon-control-panel-dbg_1.9.5-1ubuntu3_all.deb ... dbg arch all, doesn't look like it's correct
<Fujitsu> Hobbsee: I'm sure you can get an exemption.
<ogra> heh
<Mithrandir> seb128: ouch, true.
<Mithrandir> seb128: can you NEW it anyway and I'll fix it with a new upload?
<seb128> Mithrandir: ok
<Hobbsee> Fujitsu: no, no.  i dont think so.
<Hobbsee> Fujitsu: i'm coping enough crap over telling someone who was harassing me to F$%& off, on the irc mailing list.
<StevenK> Neat.
<Hobbsee> Fujitsu: it doesnt seem to matter that the guy was harassing me enough, that when the staffers saw the logs from it, they klined him immediately.  no, the problem is that i apparently broke the COC by responding in such a manner.
<Hobbsee> go figure.
<Hobbsee> the dissenting members have now been enlightened, incidently.
<seb128> pitti: bug #121327
<ubotu> Launchpad bug 121327 in texlive-bin "pdflatex produces a symbol lookup failure since recent libpoppler upgrade" [Medium,In progress]  https://launchpad.net/bugs/121327
<seb128> Mithrandir: accepted
<pitti> seb128: oh, thanks
<Mithrandir> seb128: thanks
<pitti> seb128: erk, that seems to be more than a rebuild
<seb128> pitti: yeah, they broke the API again it looks like :/
<thom> mvo_: hey, i have a working https transport :-)
<minghua> 121327 needs a new patch for texlive
* Hobbsee blames pitti 
<pitti> seb128: they are very good at expressing this with correct SONAMEs, aren't they? :(
<seb128> yeah :/
<mvo_> thom: woah! great news, care to share your patches :-D
<mvo_> thom: I will be happy to apply them
<thom> mvo_: attached to launchpad bugs; #109294 and #122294
<thom> or just pull http://www.planetarytramp.net/bzr/apt
<mvo_> thom: you rock! thanks a lot, merging now
<seb128> pitti: could you have a look to libcompizconfig-backend-kconfig in NEW?
<seb128> there is some script in admin under LPGL
<seb128> but there is no LGPL license in the tarball nor mention to debian/copyright
<pitti> seb128: currently evaluating the UGooString poppler issue, in 30 minutes or so?
<seb128> pitti: no hurry, I don't accept it from now, but looks like it's something common for KDE packages so I'm not sure if that's ok or not
<seb128> another archive admin opinion is welcome ;)
<seb128> Mithrandir: ^ if you want to comment ;)
<mvo_> thom: it does not merge cleanly, is there anything outside methods/https.cc that needed to be changed? or should I just merge those bits?
<Mithrandir> seb128: reject.
<seb128> Mithrandir: ok, thanks
<seb128> mvo: ^
<mvo> seb128: thanks, I will talk to upstream about this
<seb128> mvo: danke
<Mithrandir> mvo: I wrote it in the email I sent you with the rejection yesterday.
<mvo> Mithrandir: I uploaded a new version in the meantime that fixed the missing GPL COPYING file after I talked to upstream. I will talk to upstream again
<thom> mvo: i'm quite suprised it didn't merge, since that branch is merged up fully with the ubuntu apt branch...
<pitti> fabbione: hmm @ http://launchpadlibrarian.net/8288570/buildlog_ubuntu-gutsy-sparc.strace_4.5.15-1_FAILEDTOBUILD.txt.gz; it built on all other arches
<fabbione> pitti: will look in a minute
<pitti> fabbione: thanks
<pitti> yay, texlive is really alive again
* pitti kicks poppler
<cjwatson> ogra: touching ~/.hwdb is sufficient for oem-config to disable the hardware database client notification on new installs, isn't it?
<cjwatson> or do I need to put something in that file?
<ogra> cjwatson, hmm i think the client wont work properly if its empty
<cjwatson> what will go wrong?
<ogra> ah, no, i was clever enought to just run the collection again if no content is found
<cjwatson> oh good, that's perfect then
<ogra> i'm not sure how it affects the notificatuon though, pitti wrote that part
<ogra> pitti, ?
<cjwatson> DisplayIf: [ ! -e ~/.hwdb ] 
<ogra> ah, perfect
<pitti> ogra: hm?
<pitti> cjwatson: no, it's mere existance will inhibit it
<pitti> confirmed, empty .hwdb doesn't break the client
<ogra> cjwatson, can we allocate 30 min or so during the sprint to talk about the edubuntu liveCd and the removal of the edu apps through ubiquity to find some kind of solution ? 
<cjwatson> sure
<ogra> great :)
<fabbione> pitti: feh.. ok i need to look into with deep love...
<fabbione> pitti: gonna grab some food first
<shawarma> pitti: I think we need to discuss the language pack building stuff on the ppa's..
<pygi> hey folks
<shawarma> pitti: It's been hogging the ppa's buildd's for 8 hours now.
<fabbione> pitti: looking into strace
<StevenK> pitti: libcurl can be rescued from NEW, it's built on everything bar sparc, which is underway.
<persia> Is a libcurl fix in Debian worth a sync, or would it just make more churn, given the proposed solution.
<fabbione> doko: ping?
<doko> fabbione: pong
<fabbione> doko: i think i found a bug on glibc 2.6 on sparc... could you please try to reproduce it locally?
<fabbione> doko: try this: lftp http://url of your choise/
<fabbione> it will hang just there
<fabbione> if you start stracing lftp it will go
<fabbione> stop stracing.. download some files/cd/etc.. will work
<fabbione> try to exit and it will hang again
<fabbione> start the strace again and it will exit
<fabbione> i never seen anything like this with 2.5
<doko> fabbione: seems to work for me; any specific URL?
<fabbione> doko:  lftp http://archive.ubuntu.com/ubuntu
<fabbione> for example
<fabbione> are you using Niagara right?
<doko> yes
<doko> still feisty kernel
<fabbione> hmm no
<StevenK> persia: Don't tell me libcurl -7 exists in Debian now.
<fabbione> i have all gutsy here
<StevenK> persia: I. Just. Don't. Want. To. Know. :-)
<fabbione> doko: can you try to upgrade and test?
<fabbione> doko: i can't downgrade to feisty with this LDOM setup or nothing will work 
<fabbione> doko: nevermind.. i found the problem
<persia> StevenK: Umm..  No.  More specifically, one of the RC sync candidates I'm looking at is for a package fix for the libcurl4 -> libcurl3 transition, and I didn't know if it was worth syncing just for that, given the new libcurl4 you've been working on.
<fabbione> doko: it's NFS going banana
<doko> fabbione: ahh, ok. will hopefully be able to upgrade before the sprint
<fabbione> doko: thanks for looking into it anyway
<StevenK> persia: Ah. Wait for the new libcurl, and then request a sync.
<persia> StevenK: OK.  Thanks.
<fabbione> pitti: i can see the upstream change that broke strace, but i still can't figure out why it breaks. the change seems sane in respect to the other arches that got the same code 2 years ago
<pitti> fabbione: hm, it looked like a problem with linux headers initially; so that's not it?
<fabbione> pitti: it doesn't look like...
<fabbione> that stuff doesn't include linux headers at all...
<fabbione> or at least
<pitti> shawarma: right, I discussed it yesterday with celso
<pitti> shawarma: it's only the initial build bootstrap that will take long, gutsy will soon be moved to direct archive uploads, and we'll get more buildds soon
<fabbione> pitti: i will need to talk to david tomorrow. this is a bit out of my knowledge to do it right
<fabbione> pitti: can we leave for a few days without it?
<fabbione> pitti: (btw.. it fails on Debian too.. it's not just us)
<pitti> fabbione: of course, it's not urgent at all; should be fixed by the final release
<fabbione> pitti: i made it build locally but i am not convinced that is the right move
<pitti> fabbione: ah, good, then maybe we can just sync the next version :)
<fabbione> ok i need to go now
<fabbione> pitti: will let you know as usual
<pitti> bye fabbione, thanks
<fabbione> no problem
<zul> morning
<Mithrandir> hiya zul
<Mithrandir> zul: mind if I reject your application for ubuntu-mobile, at least until you've contributed something?
<zul> Mithrandir: no problem
<ScottK> pitti: Thanks for the review on the MIR for pinentry.  I'll see what I can do.
<Mithrandir> seb128: has evince switched how it paints the documents somehow?  It's very, very slow on this machine (ATI Radeon 8500 with free drivers)
<seb128> Mithrandir: I've tried to track the bug but no luck for now, I'm wondering if that's an xorg bug
<seb128> Mithrandir: according to sysprof it take > 90% of the time to /usr/bin/Xorg, but there is no function name nor anything
<Mithrandir> seb128: it seems related to the graphics driver at least, since it's much faster on my intel-based laptop
<Mithrandir> seb128: at the same time, it's only evince, no other applications I've seen
<seb128> we received a bug about it, the guy is using a radeon
<Mithrandir> is there something I can do to help debug the problem?
<seb128> and my desktop does that also, radeon 9600 card
<seb128> thanks, but that's ok, I get it on my desktop as well
<Mithrandir> with the free driver or fglrx too?
<seb128> ati driver
<seb128> the open source one
<seb128> what is weird is that it doesn't happen running the feisty binary
<seb128> evince binary
<seb128> so it looks like evince is doing something which makes xorg unhappy
<seb128> not sure of what ...
<Mithrandir> might be using some other code paths in cairo or something like that?
<seb128> right
<Mithrandir> (he says, waving his hands around)
<seb128> the rendering is done by poppler though
<seb128> and it doesn't happen running the feisty evince with the gutsy poppler and cairo
<seb128> I'll let you know if I figure something
<Mithrandir> hm, weird.
<Mithrandir> thanks
<Mithrandir> at first, I wondered if I had gone mad, or something
<StevenK> pitti: If the new libcurl binaries have been published, can you run cruft again, please?
<shawarma> pitti: Alright. Can you tell from the build history list how long it's going to be?
<seb128> Mithrandir: according to sysprof (which works today) it spinning a lot in fbComposite
<Mithrandir> seb128: hm, maybe try without composite enabled?
<seb128> I will
<StevenK> pitti: I'm turning my archive cleaning gaze onto apache1 and its remaining offenders.
<ScottK> pitti: pinentry has pinentry-gtk and pinentry-gtk2.  If I remove pinetry-gtk and the gtk1 build-dep from the package and lean on upstream to start working on a port to qt4, would that be sufficient to resolve your concerns?  Upstream isn't so much dead as thinking they are done AFAICT.
<pitti> ScottK: that sounds fine; if there is already a -gtk2 package, disabling the gtk 1 one sounds like the right thing; thank you!
<StevenK> Software is never finished! Those heathens. :-P
<pitti> StevenK: cool
<ScottK> pitti: Thanks.  There is and I will.
<pitti> shawarma: probably still the entire day, but please ping cprov if you need to get something built, then he can bump the build score
<pitti> shawarma: sorry for the trouble, I wasn't aware that it'd take so long
<StevenK> pitti: We're looking to completly drop apache 1 and related packages?
<seb128> Mithrandir: ok, evince changed to use cairo rendering
<Mithrandir> StevenK: I sincerely hope so.
<seb128> Mithrandir: before they were using a gdkpixbuf
<seb128> so that's cairo sucking
<Mithrandir> seb128: ah, and that broke it?
<seb128> something like http://bugs.freedesktop.org/show_bug.cgi?id=4320
<ubotu> Freedesktop bug 4320 in Driver/Radeon "Over from xrgb8888 pictures not fast-pathed in XAA" [Normal,Assigned]  
<StevenK> In that case, I'll completly rip out the apache 1 packaging for request-tracker 3.[46] 
<Mithrandir> StevenK: fwiw, it's gone from unstable
<shawarma> pitti: I'll just build it on my laptop. No worries.
* StevenK pauses from ripping bits of request-tracker out to see if we can just sync the changes.
<StevenK> (But it's so fun...)
<StevenK> Hum. If drop all of apache 1, it leaves request-tracker and probably a few others bits uninstallable and unbuildable (at least in rt's case). On the other hand, it's fun, but it leaves a large diff.
<StevenK> Mithrandir, pitti: Opinions, or neither of you care much? :-)
<Mithrandir> StevenK: NMU it in Debian and ask for it to be synced? :-)
<StevenK> Bugger that, I'd rather file RC bugs saying it doesn't build. :-)
<Mithrandir> that'd work too
<seb128> Mithrandir: bug #122786 if you want to subscribe and that seems to be due to xorg http://bugs.freedesktop.org/show_bug.cgi?id=4320
<ubotu> Launchpad bug 122786 in evince "[gutsy]  very hi cpu usage when scrolling pdf" [High,Confirmed]  https://launchpad.net/bugs/122786
<ubotu> Freedesktop bug 4320 in Driver/Radeon "Over from xrgb8888 pictures not fast-pathed in XAA" [Normal,Assigned]  
<claviola> has anyone ever had trouble getting pbuilder to install packages that come from security?  I have a feisty chroot and it's failing to build because it won't install a couple of packages that had security updates, but they both show up as 500 on apt-cache policy and are perfectly installable with an apt-get install inside the chroot
<StevenK> Oh, they will be buildable, it's installability.
<StevenK> Mithrandir, pitti: rt3.4 can probably be killed, and rt3.6 has a serious bug already asking for it to be fixed.
<ScottK> pitti: I'm fixing up pinentry now.  Since it's still in universe, I should make MOTU the maintainer, but I was wondering if I should go ahead and just make it core developers since it's about to move?
<evand> pitti: Shouldn't restricted-manager be in restricted?  It will not even start without l-r-m.
<ion_> E.g. apt-get shouldnt be in restricted just because one can install non-free software with it.
<cjwatson> apt-get starts without restricted, though
<cjwatson> it's analogous to main vs. contrib in Debian; we've always mapped contrib into restricted/multiverse in Ubuntu
<ion_> If i make a fork of apt-get that exits immediately if the Macromedia Flash plugin isnt installed, does it become non-free software? ;-)
<cjwatson> restricted-manager's entire purpose is to install restricted-licensing software and if you're the sort of person who turns off restricted then you likely don't want it
<cjwatson> ion_: no, and nobody's suggesting it would
<cjwatson> we don't have a precise analogue of Debian's contrib, but it's for free software that depends on non-free software
<cjwatson> restricted is the best we have
<StevenK> pitti: When checkrdepends has stopped spinning here, I'm going to compile a list of apache 1 modules with no rdepends that can be killed from the archive right off, shall I just submit the list as bug?
<cjwatson> if you made a fork of apt-get that was specially customised for stuff in the restricted and multiverse components and wouldn't deal with anything else, I'd suggest putting that in the restricted component too, but wouldn't say it was non-free.
<claviola> did no one run into this issue with pbuilder before? I came across it while trying to backport pidgin from gutsy to feisty
<mvo> claviola: what issues in particular? dependency resolution?
<pitti> StevenK: either that, or just tell me
<pitti> ScottK: pinentry maintainer> yes, just set it to core developers (it doesn't matter that much, though)
<seb128> what's going on with libcurl?
<ScottK> pitti: OK.  WIll do.  I've about got the package done (testing things now).
<seb128> which version has to be used?
<Spads> claviola: I recently discovered that cowdancer's cowbuilder stuff doesn't work in ubuntu because cowdancer itself isn't in main
<pitti> evand: r-m> the software itself is GPL and free, so not sure
<pitti> seb128: libcurl3 now
<seb128> pitti: they downgraded the soname?
<pitti> seb128: yes :/
<seb128> utch
<pitti> seb128: we now have a transitional package in place which depends on libcurl3
<seb128> k
<evand> pitti: Well in the case of ubuntu-without-restricted, they don't have any restricted software on their system and an application that says "install this restricted software to make this software work"
<pitti> evand: it can also install firmware for free drivers like bcm43xx
<pitti> evand: but I don't mind much, if it's easier for you when it's in restricted, I'll move it there
<cjwatson> pitti: the firmware's non-free though, or we wouldn't need to use that approach :)
<evand> pitti: If you have no major objections, I would appreciate it.
<pitti> evand: no, I don't see a problem; we can install stuff from restricted on the CDs
<pitti> StevenK: why does libcurl4-dev still depend on libcurl4 then? shouldn't there just be a libcurl-dev which depends on -3?
<evand> thanks pitti 
<pitti> evand: moved to restricted, should land there in 40 minutes
<pitti> (after the next publisher run)
<ogra> hrm
<ogra> if i get mmap():Permission Denied in an app, is there a way to make that work ? 
* ogra wonders why he doesnt have permission 
<Mithrandir> chown root /usr/bin/app ; chmod u+s /usr/bin/app ? :-P
<ogra> well, its run by root 
<ogra> (its pulseaudio trying to run with the oss-mmap module ... i run it with --system so it should behave proper i'd expect)
<ogra> i'm not really keen on running pulse suid root :)
<evand> thanks
<ogra> oh, err
<ogra> root@laptop:/# ls -l /usr/bin/pulseaudio
<ogra> -rwsr-xr-x 1 root root 35480 2007-06-28 13:51 /usr/bin/pulseaudio
<ogra> it *is* suid root ?!?
<pitti> ogra: it just checks for pulse-rt membership and drops it
* ogra scratches head
<pitti> ogra: if you are in pulse-rt, it runs with higher priority
<pitti> but it still runs as user in either case
<ogra> pitti, well, i run it with --system ... sho it will ignore that part i guess
<ogra> the pulse-rt group stuff i mean
<pitti> ogra: right
<ogra> ther is no other proper way to use mmap ? 
<ogra> any capability i could set or so ? 
<ogra> (this crappy thin client drives me nuts here)
<pitti> ogra: you should really avoid capabilities for that; mmap shouldn't need particular ones
<pitti> ogra: what does it do, just read/write? maybe you have PROT_EXEC?
<ogra> pitti, no idea yet, i havent looked at the code ... it took me some days to even get the oss driver to work on that thing ... now i have sound but it gets choppy if i move the mouse or have high net traffic ... module-oss-mma is supposed to fix that ... it seems to function on other distros ... i'll check the source
<ogra> *module-oss-mmap
<pitti> ogra: if you strace it and note down the mmap() arguments, it should give a hint
<ogra> choppy sound is better than no sound though :) 
<ogra> right, i'll do tat
<ogra> *that
<ogra> pitti, i see PROT_READ and _WRITE ... no EXEC
<pitti> ogra: hm, and which file does it mmap()?
<ogra> well, i only see: "mmap2(NULL, 12288, PROT_WRITE, MAP_SHARED, 7, 0) = -1 EACCESS (Permission denied)"
<ogra> no filenames ot paths anywhere 
<ogra> *or
<pitti> ogra: that's fd 7
<ogra> ah
<ogra> hmm
<pitti> ogra: above in the strace must be an open call with results in "= 7"
<pitti> ogra: if that file descriptor is not opened for writing, you should get that
<ogra> ah, right
<ogra> there is a PROT_READ call above as well that doesnt seem to fail
<ivoks> then probably program is not running under sufficient privileges or file is read only
<ogra> ah, the read is on -1 then
<ogra> well i dont even have /dev/fd/7 
<pitti> ogra: so maybe the fd has really been opened with O_RDONLY?
<ogra> that should be there, no ?
<pitti> ogra: not sure, it might have been closed again already
<ogra> ah, k
<pitti> ogra: just save the strace into a file and grep for 'open.*= 7'
<pitti> (with open() being the most common function for getting an fd; there are others, of course)
<pitti> ogra: just grepping for '= 7' should work, too, can't be too many hits :)
<ogra> ah
<ogra> yeah, lots of O_RDONLY
<pygi> we're opening some devices? :)
* pygi reads above 
<claviola> mvo: yeah, dependency resolution
<mvo> claviola: what package do you see it with, can you please give some advice how to reproduce?
<claviola> mvo: will do, running it again now.
<claviola> both packages have newer versions in the ubuntu security repository
<claviola> I added it to the chroot, they are installable from within
<claviola> mvo: alright, here it is
<claviola> The following packages have unmet dependencies: libebook1.2-dev: Depends: libebook1.2-9 (= 1.10.1-0ubuntu1.1) but it is not going to be installed libnss3-dev: Depends: libnspr4-dev (= 1.8.0.10-3ubuntu1) but it is not going to be installed
<claviola>   Version table:
<claviola>      1.10.1-0ubuntu1.1 0
<claviola>         500 http://security.ubuntu.com feisty-security/main Packages
<claviola>      1.10.1-0ubuntu1 0
<claviola>         500 http://br.archive.ubuntu.com feisty/main Packages
<seb128> claviola, mvo: I don't know what the bug is in this case, but those bugs are often due to a source package having binaries in main and universe and having security only enabled for main
<claviola> I have security enabled for all components
<seb128> apt-cache policy libebook1.2-de libebook1.2-9 ?
<seb128> apt-cache policy libebook1.2-dev libebook1.2-9 ?
<claviola> both candidates are the security versions
<mvo> claviola: out of curiosity, does it help if you change /etc/pbuilder/pbuilderrc and there PBUILDERSATISFYDEPENDSCMD="/usr/lib/pbuilder/pbuilder-satisfydepends-gdebi" ?
<claviola> will give it a shot
<claviola> is /usr/lib/pbuilder/pbuilder-satisfydepends the standard?
<mvo> claviola: yes
<claviola> yeah, gdebi was fine
<mvo> claviola: that is interessting. I knew it would be faster, its good to know that its more correct too :)
<claviola> yeah, *much* faster :)
<claviola> I'm trying to figure out why apt is going nuts now
* mvo thinks we should just make it default 
<claviola> I don't think anyone would complain
<claviola> but I haven't used it at all yet
<claviola> this is really weird considering all that happens is that apt-get is ran inside the chroot
<claviola> unless there's something else that happens when one runs 'pbuilder login', I'm doing the same thing by hand
<mvo> claviola: IIRC (I may be wrong here) satisfydepends does not really runs chroot apt-get but calls with with a bunch of -o DIR:: arguements, is that correct?
<claviola> mvo: with a set -x, what I get are calls like "chroot /var/cache/pbuilder/build//29338 /usr/bin/apt-get -s install cdbs debhelper libgtk2.0-dev libxss-dev libmeanwhile-dev libgadu-dev libnss3-dev tcl8.4-dev tk8.4-dev libgstreamer0.10-dev libgtkspell-dev libltdl3-dev libperl-dev libstartup-notification0-dev"
<mvo> ok - wrong memory than :)
<claviola> I think I've ran into a bug
<claviola> with the command line above, apt-get breaks
<mvo> claviola: what is the error mesage?
<claviola> the same I get with pbuilder
<claviola> this happens if I try to apt-get -s install libnss3-dev libebook1.2-dev
<claviola> if I try to simulate them both separately, everything is fine
<claviola> if not, just the old
<mvo> claviola: could you please run it with -o Debug::pkgProblemResolver=true and -o Debug::pkgDepCache::AutoInst=true
<claviola>   libebook1.2-dev: Depends: libebook1.2-9 (= 1.10.1-0ubuntu1.1) but it is not going to be installed
<claviola>   libnss3-dev: Depends: libnspr4-dev (= 1.8.0.10-3ubuntu1) but it is not going to be installed
* claviola needs to find a pastebin
<ScottK> !pastebin | claviola
<ubotu> claviola: pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<claviola> I wonder why the hell it needs javascript, but still... http://paste.ubuntu-nl.org/28353/
<claviola> this is pretty weird, I get this outside as well. am I the only one?
<claviola> outside = of the chroot, on feisty
<geser> StevenK: I've reread the scrollback now about curl: upstream is already at so-version 4 so the next one will be 5. Debian managed to restore the API/ABI and went back to libcurl3 to save the transition. libcurl3 installs now libcurl.so.4 and symlinks from libcurl.so.3 to libcurl.so.4 to make the old packages happy (AFAIUI)
<axxo> you make that sound like a good thing
<cjwatson> I think everyone involved thinks it's a necessary disaster
<cjwatson> though I haven't read up on it all
<geser> I've only read the discussion on the debian-project ML
<geser> Debian didn't want the transition as the many libcurl rdepends would make a transition from unstable to testing very hard and long
<claviola> mvo: so the main problem seems to be with libnspr4-dev right now
* pitti pokes mvo, you broke apport retracers :)
<pitti> mvo: what was the magic option to have apt-get source download the source without asking for version control confirmation?
<mvo> pitti: *cough* you mean the option that is about to be added ;) ?
<pitti> mvo: ah: "yes | apt-get source apport"
<pitti> mvo: that should do for now :)
<cjwatson> pitti: --assume-yes seems to do the job too
<pitti> cjwatson: yay
<ion_> When apt-get source points you to a VCS branch, whats the canonical (no pun intended) way to get the orig.tar.gz?
<tkamppeter> pitti, I did some thoughts about the source debian package for automatically rebuilding all drivers from OpenPrinting (see https://blueprints.launchpad.net/ubuntu/+spec/printerdriverautodownload)
<pitti> ion_: I'd say, say yes, download the package, and then checkout the bzr
<pitti> tkamppeter: ah, will have a look at it
<tkamppeter> pitti,I see one problem there:
<mvo> ion_: you can use apt-get source --tar-only pkg too 
<ion_> Thanks
<tkamppeter> The printer driver offered at OpenPrinting are third-party drivers, so they are packaged to be installed in /opt (see http://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers)
<pitti> tkamppeter: right
<pitti> tkamppeter: that's probably a good thing to avoid package file conflicts
<tkamppeter> Now an automatic rebuilding with installation into /usr is not trivial, as the original packager of the distro-independent RPM (which is not necessarily me!) can have hard-coded /opt paths, and can have used very many different methods to introduce paths.
<pitti> tkamppeter: right; but if there is a standard PPD search path in /opt, and cups looks for that, it should work, shouldn't it?
<tkamppeter> And if I do no conversion, simnply rebuilding the RPM under Ubuntu and then uncompressing the RPM and letting the resulting files and maintainer scripts get packages as Debian package gives a Ubuntu package installing in /opt.
<pitti> tkamppeter: ah, wait, we wanted to ship those as an official Ubuntu package, right
<pitti> darn
<iwj> I remember many years ago trying to kill /opt in FSSTND.  I won too but then later during the FHS merge it rose from the dead.
<pitti> iwj: well, if it was /usr/local/, it wouldn't help us either
<tkamppeter> pitti, there is a standard PPD path, /usr/share/ppd, and the maintainer scripts of the distro-independent packages link their PPDs to /usr/share/ppd.
<iwj> pitti: Yers.
<pitti> they do the right thing by *not* installing into /usr
<iwj> /opt is better than /usr/local.
<pitti> tkamppeter: there should be /opt/ppd or so, too
<iwj> You could retarget the package and leave a symlink behind ?
<iwj> That way it won't overwrite anything anyone else put in /opt but it will still work.
<tkamppeter> pitti, my concept is that all actual files in the distro-independent package install into /opt/<supplier>/ and the maintainer scripts set symlinks to connect the driver appropriately to the system.
<tkamppeter> /opt/share/ppd and //usr/local/share/ppd were rejected by two distros, Red Hat (Tim Waugh) and Ubuntu (was it you, pitti?).
<pitti> tkamppeter: no, having cups search those directories would be perfectly fine
<pitti> tkamppeter: the issue was *shipping* those directories in the packages, not adding it to the cups search path
<tkamppeter> Does a .deb create a directory when it is missing?
<pitti> tkamppeter: I think there's no way around relocating the files and paths
<pitti> tkamppeter: missing in what way?
<tkamppeter> RPM does not do it, RPM distros must ship /opt to be able that packages can be installed in /opt.
<iwj> root@lalonde:~# pvremove -f /dev/sda11
<iwj>   Can't pvremove physical volume "/dev/sda11" of volume group "gtest" without -ff
<Chipzz> tkamppeter: I think it does (.deb creating the dirs)
<tkamppeter> package contains file /opt/gutenprint/ppds/epsonc80.ppd, distro has no /opt at all, does the package install?
<pitti> tkamppeter: if some upstream package wants to install into /opt, it should mkdir /opt if it doesn't exist; otherwise it would be fairly broken
<pitti> tkamppeter: however, /opt is there by default anyway
<Chipzz> tkamppeter: I even think there is no way to have .deb not create these dirs
<pitti> tkamppeter: sure, it will
<pitti> tkamppeter: (except that Ubuntu packages must not have files in /opt)
<iwj> pitti: normally constructed .debs contain the directories in their fsys tarball so the directories would get automatically created.
<pitti> iwj: right
<tkamppeter> pitti, and that rule would be broken by the fully auto-rebuilding printer driver package.
<pitti> tkamppeter: right, so we need to relocate the files there to /usr/share/ppd
<iwj> NB that if the package has  drwxr-xr-x /somedir/  but the system has  lrwxrwxrwx /somedir -> /otherdir  then dpkg will follow the link.
<pitti> tkamppeter: and /usr/lib/cups/backend-available/
<tkamppeter> pitti, the driver packages do not only contain PPDs.
<iwj> tkamppeter: The difficulty is that they might contain programs which would refer to /opt/supplier/somethingorother, right ?
<iwj> And it's impractical to fix that.
<pitti> tkamppeter: right, those need manually maintained patches, I think
<pitti> tkamppeter: preferably the sources would have a configure option for that
<iwj> pitti: They might be binary-only nonsense.
<pitti> tkamppeter: that might make sense for the spec anyway
<iwj> pitti: And the idea is to translate the binary packages, not the sources.
<iwj> AIUI
<pitti> iwj: I wouldn't repackage and ship those in Ubuntu anyway
<iwj> You're sure they wouldn't end up in restricted ?
<pitti> iwj: binary translation> oh, was it?
<claviola> could someone try installing libnspr4-dev on their feisty box? It seems to be the root of my problems
<iwj> pitti: I think so but tkamppeter will know.
<tkamppeter> Perhaps we do the follwing, we simply drop everything in /opt/<supplier> into /usr/lib/printdriver/<supplier> (for each <supplier>) and let the maintainer scripts link /usr/lib/printdriver/<supplier> to /opt/<supplier>. After that we run also the original maintainer scripts to complete the symlinking.
<pitti> tkamppeter: that would still break the /opt rule
<siretart> has anyone tried to boot tribe-2 in qemu?
<iwj> pitti: I think it's probably OK if we have a careful thing that just makes one symlink.
<siretart> I'm getting dropped to an initramfs shell :*
<pitti> iwj: well, it minimizes the evilness, yes :)
<pitti> siretart: only in qemu? or also in vmware/real iron?
<tkamppeter> Yes, it was some time told that /opt could be mounted from an application server where the local root is not root.
<mvo> hey iwj, do you have a opinion about  bug #123757 ?
<ubotu> Launchpad bug 123757 in dpkg "Please do not localize error messages send over --status-fd" [Wishlist,New]  https://launchpad.net/bugs/123757
<tkamppeter> So probably I have to revise the driver design and packaging HOWTO http://www.linux-foundation.org/en/OpenPrinting/WritingAndPackagingPrinterDrivers that drivers MUST be packaged in a way that if the %install_into_opt macro in their RPM spec file (simply commenting out that line) that they MUST install and work correctly under /usr, like original distro packages.
<pitti> tkamppeter: right, that would be helpful for all distros, i guess
<claviola> Is there any good reason for libnspr4-dev to conflict with libnspr4?
<pitti> tkamppeter: do you know whether, by and large, the drivers have source available?
<tkamppeter> Yes, and this only works out where suppliers are willing to provide an SRPMs, binary-only packages often come as RPM only.
<pitti> tkamppeter: for binary-only drivers we probably have to bite the bullet and do an /opt symlink
<ScottK> pitti: I've done a new upload of pinentry (waiting to build now) and I think answered your comments on https://wiki.kubuntu.org/MainInclusionReportPinentry.  I'd appreciate it if you'd put it back in your queue to look at soon.
<pitti> ScottK: I got the wiki change notification mail, will do
* pitti -> off for a bit
<ScottK> pitti: Thanks.
<tkamppeter> pitti, free drivers will have source available, non-free drivers can have the SRPM available (for example a package which only puts binary files together but does not compiule anything), but it can happen that only RPMs will get delivered.
<iwj> mvo: Hi.  I saw that.  It looks really difficult.
<iwj> I haven't checked this but AIUI the status fd error messages are just the ones from ohshit and ohshite.
<iwj> So you'd have to send up through the status pipe the printf template and the formatted substitution values.
<iwj> (And what if the formatted substitution values are already translated?)
<mvo> iwj: that is my impression from the code as well, we would have to go over all of them, mark them with N_() and then on display use gettext() only for display and the original one on the pipe (does that make sense)?
<mvo> iwj: (the impression that it would be difficult)
<iwj> But you can't do gettext after you've done snprintf.
<iwj> doorbell
<iwj> back
<iwj> Perhaps you'd like to explain your problem more fully :-).
<mvo> iwj: I see the problem now (haven't looked at ohshit() before too closely)
<mvo> iwj: well, the problem is that we want to generate apport bugreports for failures to install/remove etc
<iwj> Right.
<iwj> But you want the apport reports to be untranslated
<mvo> iwj: and it would be good to have the reports not being localized because it makes e.g. dup finding harder
<cjwatson> you could put a catgets-style code before each possible error
<iwj> Niiice.
<cjwatson> E1001: package exploded
<mvo> iwj: and reading the report too of course :) it would be cool if apt could just drive dpkg with LANG=C, but that would mean that debconf and friends are not localized too
<cjwatson> that wouldn't be ideal for people running apt at a terminal either
<iwj> We could make dpkg not call setlocale.
<iwj> I mean, optionally.
<iwj> Or we could dual-track all of the error message handling code so that there'd always be a translated and an untranslated message.  Urgh!
<geser> but wouldn't programms called from postinst still be localized (and their errors too)?
<iwj> Yes.
<cjwatson> localised errors are fairly rare there ...
<cjwatson> well, apart from 'rm: no such file or directory' and such, I suppose
<pitti> bdmurray, seb128, asac: do you think it would be useful if apport would add a 'apport-failed-retrace' tag to bugs which do not have an useful stack trace after retracing?
<seb128> yes
<seb128> it would make an easy list of bugs to triage
<pitti> I already have report.has_useful_stacktrace(), so I can implement this trivially
<seb128> t-hat would also allow to make stats on how many bugs are broken
<asac> pitti: at best add mt-needretrace :)
<asac> pitti: for all packages in realm of mozillateam ;)
<seb128> I think that's quite a lot at the moment
<bdmurray> pitti: that sounds good to me too
<pitti> asac: would the MT consider using that tag instead? having multiple ones is too confusing, I think
<asac> hmm ... cannot decide right now
<asac> pitti: for whom would it be confusing?
<bdmurray> asac: wouldn't the apport-failed-retrace end up replacing mt-needretrace?  or are there some cases where mt-needretrace would still get added manually?
<pitti> asac: first, for finding the crashes which need manual traces or apport fixes, and second, I don't like hardcoding special cases about teams and source package names into apport
<asac> pitti: bdmurray afaik there is not just black and white ... mt-needretrace would probably still be needed
<asac> for cases where we need better
<pitti> asac: that's fine
<pitti> asac: I don't want you to abolish that tag, just asking whether you would get disturbed about apport-failed-retrace
<asac> we would probably have to automatically rename it
<asac> so go ahead and add it
<asac> if you feel you don't want special cases
<pitti> asac: well, if you would rename it automatically, then it would be semantically identical to mt-needsretrace; but you just said that it's for cases which need manual checks?
<pitti> asac: we can still introduce them later if we externalize the mapping for it, but I'd rather have common tags so that other people don't need to be aware of those special cases when looking for bugs
<asac> pitti: mt-needretrace subsumes apport-failed-retrace ... but not the other way around i guess
<pitti> ah, right
<asac> so renaming to mt-needretrace is safe ... while the other way might not be right.
<asac> pitti: how can we improve backtraces
<asac> pitti: shall i try to remove omit-frame-pointer optimization?
<pitti> asac: is this something ffox specifically turns on in debian/rules?
<pitti> asac: it's worth a try at least
<asac> pitti: problem is we cannot really reproduce what your retracers do ... otherwise we would evaluate on our own
<pitti> asac: today I fixed the Contents.gz scanning
<asac> pitti: no its standard -O2 optimization
<pitti> asac: i. e. things which are loaded dynamically and need extra packages now actually work :)
<asac> ah ok ... lets wait another few days then
<pitti> asac: hm, then I don't see why it specifically fails for ffox; it works for other packages after all
<asac> another thing ... i get lots of signal 5 crashes?
<asac> why that? we never had that signal before?
<claviola> so, does anyone know if there is a good reason for libnspr4 to conflict with libnspr4-dev on feisty?
<asac> claviola: yes
<asac> claviola: libnspr4-dev ships files that are in libnspr4
<pitti> asac: the other thing is bug 74691, that might be a reason, too
<ubotu> Launchpad bug 74691 in linux-source-2.6.22 "Unable to debug under 2.6.22 on i386: Failed to read a valid object file image from memory" [High,Confirmed]  https://launchpad.net/bugs/74691
<pitti> asac: signal 5> that's usually a glib assertion
<claviola> asac: and why is this the case
<claviola> like, usually it is pretty common for someone to install an accompanying -dev package...
<asac> claviola: they don't belong together
<asac> claviola: libnspr-dev + libnspr4
<asac> claviola: or libnspr4-dev + libnspr4-0d
<asac> those are the pairs
<claviola> okay, will try.
<asac> so for developing the transition is not really perfect
<asac> but its old cruft we have to deal with
<claviola> well, the thing is
<asac> you don't need to go on
<claviola> I'm trying to build pidgin on feisty
<asac> its bearable for developers ... setup a chroot
<claviola> funny thing, because this is what I'm doing.
<claviola> and it still fails on the chroot
<asac> the non-dev packages can be installed side by side
<asac> claviola: yeah ... what does pidgin build-depend on?
<claviola> because, as I was going to say, there's a conflict between libnspr4-dev and libebook1.2-dev
<claviola> well, I guess libnss3-dev is the culprit.
<asac> claviola: what are you trying to do?
<asac> backport pidging to feisty?
<claviola> yes.
<asac> claviola: if so, you are probably best of changing build depends to libnspr-dev and libnss-dev
<claviola> I need to read more on the changes to those two
<asac> claviola: it should just work
<asac> claviola: if not ping me
<claviola> it's fine now, but it drove me nuts earlier today :P
<asac> ok ;)
<claviola> I just realized I'll have to setup a mini repository to host my own pidgin-dev so I can build plugins against it
<claviola> sigh, what is an easy to maintain one? mini-dinstall?
<asac> claviola: we have those libs in mozillateam archive
<asac> !moztest
<ubotu> The Mozilla-testing repos can be found at: https://wiki.ubuntu.com/MozillaTeam/PreviewArchives. Please remember these are testing repos, the packages in these repos are not stable and may break things on your system. Use with caution. Please report bugs found from these packages to: https://wiki.ubuntu.com/MozillaTeam/PreviewArchives/Bugs.
<claviola> asac: I'll just need my own pidgin-dev package
<claviola> now I'm just wondering about what "mini dak" to use
<asac> just push everything to one directory and run dpkg-scanpackages and dpkg-scansources
<thom> or just apt-ftparchive
<asac> yeah
<iwj> Oh, of course, I bet I've been bitten by the ginormous menu.lst bug.
<Keybuk> iwj: collecting kernels? :p
<pitti> my menu.list is regularly prolonged with having Ubuntus in other partitions
<pitti> "Ubuntu, kernel 2.6.22-7-generic (on /dev/hda2) (on /dev/hda3) (on /dev/hda2)"
<Keybuk> I just use VMware for that kind of thing :p
<pitti> well, sometimes it's useful to test on real iron :)
<iwj> Yes, what pitti said.
<iwj> -rw-r--r-- 1 root root 156137 2007-07-03 18:08 /mnt/boot/grub/menu.lst
<iwj> If it's >64K then grub crashes when it tries to show the menu.
<pitti> erk
<Keybuk> pitti: bah, that's what users are for :p
<pitti> Keybuk: just gotta love your QA approach :-P
<Keybuk> pitti: most of the testing I do tends to require unreal iron in order to replicate the bugs
<Keybuk> it's much easier to cause race conditions in VMware
<pitti> sure :) (I meant CD image testing, actually)
<Keybuk> pitti: trouble with that is you're testing the install alongside an existing Ubuntu install
<Keybuk> so you're offsetting the "real iron" with an "unusual scenario"
<iwj> I have a caddy for that so I can do `wipe disk' installs etc.
<pitti> yeah, but I hope that a combined vmware + real iron multi-installs will cover enough
<pitti> iwj: getting one of these 4 GB SRAM IDE disks would be really cool for that, I think
<pitti> boot or install Ubuntu in 20 seconds or so :)
<kylem> it takes more than 20 seconds to boot ubuntu?
<kylem> :)
<Keybuk> kylem: oddly enough, I was going to say the same thing <g>
<pitti> sad as it is, we are still quite a bit behind Windows :(
<kylem> er.
<kylem> really?
<Keybuk> a fresh or little-used Windows install, maybe
<pitti> I saw xp boot on an old 800 MHz Celeron in 30-odd seconds
<Keybuk> not a real one
<kylem> it takes a good minute for my machine to boot XP, versus like 15 seconds to a running gnome session.
<Keybuk> my partner's laptop takes over three minutes to boot XP
<pitti> Keybuk: that is the desktop system of a friend of mine
<pitti> kylem: well, that's still faster than Ubuntu :)
<kylem> i'd time it, but the only time i boot windows is to boot civ3, and i don't have time...
<pitti> I disabled a lot of services, and it takes some 1:30 minutes to an usable desktop, even with autologin
<pitti> kylem: and I don't have Windows to test, but I saw quite a few
<kylem> dunno. in my experience, macosx is only just barely faster than ubuntu.
<Keybuk> the gnome login time of Ubuntu is kinda interesting
<pitti> hmm, I only used that two or three times and I wiped it years ago, I don't remember any more
<Keybuk> I did some comparisons with F7 a few weeks back
<Keybuk> (which is stunningly fast to login)
<sn0> when i was in school we had risc os StrongARM based systems that booted from rom in a second :)
<kylem> Keybuk, on a fresh install of gutsy using vesa (unsupported until about 5 minutes from now) on my 3ghz c2d box, gnome starts moments after i finish my password... no splash screen.
<Keybuk> I know that they're shiny, but do we really need 2.5MB of default desktop background and startup sound?
<Keybuk> kylem: it shouldn't, there's a lot of cruft we load
<kylem> Keybuk, seriously...
<Keybuk> why no splash screen?
<Keybuk> we haven't disabled that yet?
<Keybuk> (oddly, the splash screen itself adds about 1.5s to the login time)
<kylem> Keybuk, because the desktop loads so damned fast.
<mjg59> Gnome is very fast to start up, assuming a warm cache
<Keybuk> kylem: you disabled it yourself?
<mjg59> It's entirely the i/o that's killing us
<Keybuk> mjg59: not entirely
<Keybuk> the fact we're using far more I/O than we need to is a major factor
<ion_> AFAIK Windows rearranges HDD blocks to boot faster and load oftenly used software faster.
<ijuz__> on my shinny new laptop Vista (without _anything_ installed) takes 35sec from grub to login and additional 15 sec for login
<mjg59> Keybuk: If I log out and then log in on a 1.2GHz machine, I'm at a desktop in a couple of seconds
<Keybuk> and the fact we load huge amounts of Python (multiple python interpreters) in our default login doesn't help either
<Keybuk> mjg59: sure, because the big bits are cached <g>  I'm not saying a warm cache doesn't help; I'm saying that we can be much faster with a cold cache than we are
<mjg59> Keybuk: Uhm. Isn't that what I said?
<Keybuk> mjg59: no, you said it's entirely the i/o - which it isn't
<pitti> mjg59: right, second gnome login is fast here, too
<Keybuk> I put together a login that's faster on a cold cache than our default is on a warm cache
<Keybuk> so it's not entirely cache
<mjg59> Keybuk: The warm cache case is sufficiently fast that it's not a problem. 
<Keybuk> mjg59: the warm cache is sufficiently rarely seen that it *IS* a problem
<Keybuk> people primarily login on a cold cache
<Keybuk> because they've just booted their machine
<mjg59> Yes. But we're not spending time on the CPU, we're spending time in i/o
<Keybuk> they tend to logout when they're rebooting it or turning it off
<mjg59> So we need to reduce the i/o
<Keybuk> we're spending a lot of time in both actually
<Keybuk> lots of Python uses the CPU a bit
<mjg59> No, because we can log in from a warm cache in a couple of seconds
<mjg59> The contribution of CPU time is tiny compared to the amount of time spent in i/.o
<Keybuk> but we never login from a warm cache
<Keybuk> it's cold ;)
<mjg59> Keybuk: Yes. But even if we spent no time on the cpu, the best we could save (on a slow machine) is a couple of seconds
<Keybuk> ?
<Keybuk> have you compared Ubuntu and F7
<Keybuk> the difference is quite staggering
<Keybuk> even on slow hardware
<mjg59> Keybuk: The amount of time spent in cpu is independent of whether something is in cache or not, right?
<Keybuk> right
<ion_> F7? Fedora Core?
<mjg59> So, if I can log in in two seconds from a warm cache, the amount of time spent in cpu cannot be more than 2 seconds
<Keybuk> ion_: Fedora 7
<Keybuk> mjg59: indeed; but we can reduce that to near-zero seconds
<mjg59> If we reduced that time to 0, the most we could remove from the login time would be 2 seconds
<ion_> Whats the difference? I.e. which one is faster?
<Keybuk> mjg59: err? we could remove more
<mjg59> But I'm spending 20 seconds in i/o
<mjg59> Keybuk: Only if I can log in in negative time
<Keybuk> ?
<mjg59> Keybuk: Total CPU time spent during login, regardless of whether the cache is warm or not, is two seconds
<mjg59> So reducing the amount of CPU time used cannot reduce the amount of time taken to log in by more than two seconds
<Keybuk> yes
<iwj> Keybuk: This USB modem is a Conexant softmodem :-(.  Looks like we should be telling people to get a USB serial dongle and a real modem.
<mjg59> So we're dominated by i/o, not cpu use
<Keybuk> yes, the majority of time is i/o
<iwj> Shame you can't discover this before you buy it.
<mjg59> We can either improve throughput (by reducing seeking) or reduce the number of programs started
<Keybuk> you said "entirely" :-)
<Keybuk> we can also reduce the I/O by reducing the size of some of the files we load simply for effect
<Keybuk> (startup sound, desktop background, etc.)
<mjg59> Keybuk: Two seconds is within the noise threshold for a typical login for me
<mjg59> And 2.5MB is still only about 0.1 of a second
<ogra> iwj, just carry a liveCD with you to the shop ... and ask if you can test it ...
<Keybuk> ?
<iwj> ogra: Mmm.
<ogra> in good shops that usually works
<mjg59> Keybuk: My (1.8") drive is capable of over 20MB/sec
<Keybuk> so you think we load about 500MB on gnome login?
<mjg59> Keybuk: No, I think the majority of the time is spent seeking
<iwj> ogra: Except we don't really have such things in Cambridge.  Either very upmarket shops or the likes of Maplin.  I normally do everything mail order.
<mjg59> Which isn't a problem when you're talking about two files
<iwj> Hmm.  I wonder if this can be made to work with sl-modem-daemon.
<mjg59> iwj: The Conexant ones? Not as far as I know.
<Keybuk> perhaps, but by shrinking those and removing a couple of things from the autostart, I reduced my cold cache startup time to <5s
<ogra> iwj, yeah, it's indeed hard to test in advance that way :)
<Keybuk> (from about 20s)
<mjg59> Keybuk: If the background and startup sound are adding significant time to login, that indicates a bug we should fix rather than anything else
<iwj> mjg59: It's a conexant-based USB thing.
<mjg59> iwj: Yes
<iwj> Hmm.
<mjg59> Linuxant provided drivers at some point, I believe
<iwj> Yes, they still do I think.
<mjg59> Certainly for the Apple ones
<iwj> Payware.
<iwj> I bet they work with this too but I think testing that is a bit out of scope.
<RainCT> Hey, a little question. Is it ok to create a page in wiki.ubuntu.com about a program I'm creating if it's not directly Ubuntu related?
<LaserJock> cjwatson: got a minute now? :-)
<axxo> i have a full hour!
<asac> any idea how i can get the same affect as physically unplugging and plugging in an usb device programmatically from userspace?
<pitti> StevenK: erk, libcurl3-gnutls has files from old libcurl4-gnutls, but doesn't Conflicts:/Replaces: it
<asac_> i was offline ... in the unlikely case that anyone answered my usb question ... please repeat :)
<Kmos> anyone answered
<pitti> Kmos: no, nobody did
<pitti> ^ asac_ 
<pitti> asac_: I might have an idea, let me try
<asac_> pitti: but you certainly know, right ;)
<asac_> like echo 1 > /....
<asac_> :)
<pitti> asac_: this works for me:
<pitti> cd /sys/block/sda/device/driver; echo -n '1:0:0:0' | sudo tee unbind; echo -n '1:0:0:0' | sudo tee bind
<asac_> samn ... what does that do?
<asac_> damn
<pitti> asac_: sda is the block device you want to 'replug'
<Kmos> pitti: crazy geek
<Kmos> lol
<pitti> asac_: and '1:0:0:0' is the single directory in /sys/block/sda/device/driver/
<asac_> ok lets see ;) if i can project that for my case
<pitti> asac_: it essentially tells the driver (which is the sd module in this case) from unbinding and binding to the device 1:0:0:0 (on the USB bus, which is sda here)
<pitti> s/from unbinding/to unbind/
<asac_> its not a block device though
<asac_> some mtp device (ouch)
<pitti> asac_: if I do that here, I get the automount magic back
<pitti> asac_: doesn't matter, you just need a convenient way to find the device in /sys
<pitti> asac_: what's mtp?
<asac_> http://libmtp.sourceforge.net/
<asac_> mtp is an implementation of Microsoft's Media Transfer Protocol (MTP)
<pitti> asac_: look in /sys for the various groupings of devices (by block device, bus, kernel module name, etc.)
<asac_> sucky mp3 player
<pitti> asac_: aah, that's more or less raw USB
<asac_> that cannot be reset/closed by libusb
<pitti> asac_: well, just try unload and reload the particular USB module
<asac_> it works pretty well, but once you try to release it it will not get back to a usable state
<pitti> asac_: unloading a module is often bad, though, which is why unbinding/rebinding is better
<asac_> ehci_hcd is the only module used
<asac_> no idea if its good to do that
<pitti> asac: rmmoding that will kill *all* your USB devices
<asac> pitti: ok how can i find the proper device node? does lsusb help?
<pitti> or, it won't even work
<asac> yeah
<asac> thats what i thought
<pitti> asac: lsusb might help
<pitti> asac: then look in /sys/bus/usb/devices/ for the device number
<pitti> asac: /sys/bus/usb/devices/<usb port number>/driver/ -> there you have the driver for that device again
<asac> let me see .... :)
<asac> pitti: http://paste.ubuntu-nl.org/28389/
<asac> on top is lsusb -t of that device
<asac> how do i figure the port number ... i can guess which one it is
<asac> but ...
<asac> i would guess that its 1-1
<sladen> StevenK: your libcurl*-{,gnutls} uploads are barfing on install
<pitti> asac: hm, just check */idVendor and */idProduct for your device
<RainCT> nobody knows if it's ok to create a page in wiki.ubuntu.com about a program that is not directly Ubuntu related?
<pitti> RainCT: in general, wiki.u.c. should have Ubuntu related things
<sladen> RainCT: the page would make sense if it's about using that program on ubuntu
<RainCT> ok, thanks. do you know of any other open source related wiki where I could create a page for that purpose then?
<sladen> RainCT: what's the program you had in mind?
<sladen> RainCT: there are likely to be wiki's (eg. audio, graphics, GNOME, KDE) where the page would fit neatly
<RainCT> sladen: https://launchpad.net/qttube
<sladen> RainCT: that's an interesting issue.  currently launchpad is semi-hardcoded to point to (a particular) external wiki
<RainCT> sladen: so do you know any wiki where I could create a page for that program?
<mruiz> hi all
<holycow> hi guys
<LaserJock> lifeless: what is the conflict checker specifically checking for?
<lifeless> missing conflicts:/replaces: stanzas
<lifeless> LaserJock: across tim
<lifeless> *time*
<LaserJock> ahhh
<lifeless> two packages with the same file must do one of: divert, conflict, or replace.
<LaserJock> I noticed a bunch of tex related ones
<LaserJock> lifeless: will those cause dpkg errors when upgrading?
<lifeless> LaserJock: some of them will; some of them wont because we lie to dpkg when its used from apt/synaptic
#ubuntu-devel 2007-07-04
<cypherbios> that's pygi switching names again :)
<pygi> what I did now, what I did now?
<cypherbios> pygi: what you always do :P
<cypherbios> pygi: hi man, what's up?
<pygi> cypherbios, nothing much, my head hurts, I had to sent an application for a seminar *yesterday*, failed to do so, have an important exam today and stuff :)
<pygi> what about you?
<cypherbios> pygi: less worst than you I guess :D
<cypherbios> hehe
<pygi> cypherbios, hehe :)
<pygi> cypherbios, will be better one day :
<pygi> :P
<cypherbios> pygi: I hope so :)
<StevenK> Ah, crap.
* StevenK prepares a fix for curl.
<ajmitch> more curl?
<ajmitch> you're not sick of it yet?
<StevenK> I am, but I should fix it. :-)
<lifeless> anyone here use kvm on feisty ?
* sn0 would if his cpu supported it :)
<lifeless> well mine loads the module
<lifeless> but booting an ubuntu-7.04 iso on it is using 100% cpu and doing squat
<lifeless> bywhich I mean its done the ISOLINUX prelude but appears to have hung on kernel load
<sn0> silly q lifeless but you are added to the kvm group ?
<lifeless> yup
<sn0> other than that i cant think of anything sorry, willing to accept a cpu to try it though ;)
<lifeless> (not silly :))
<sn0> i remember seeing something about kvm on the ubuntu wiki but i believe it was just installing, load module, add to group and qemu-img create then run kvm with the iso
<lifeless> yeah
<lifeless> its just the basics not debugging
<sn0> on the talk of virtualisation i was having real trouble with vmware + usb pen drives :<
<lifeless> to get the guest to see them ?
<calc> wow this sven stuff on d-p is interesting, missed it a few months back due to moving
<ajmitch> calc: please, don't read it - stay sane
<StevenK> ajmitch beat me to it.
<siti> is anyone else getting launchpad timeouts?
<pygi> siti, gimme a sec
<pygi> siti, nop
<persia> siti: I haven't seen any (despite frequent page loads)
<siti> ok, it's when I am submitting a bug..
<fabbione> morning
<Hobbsee> greetings, earthlings.
<Fujitsu> Greetings, green alien.
<Hobbsee> :)
<Hobbsee> darn, heno's not here again
<fabbione> Hobbsee: probably on your starship it's a normal time of the day, but here is 6:30 am
* fabbione sends some pagliata to Hobbsee 
<Hobbsee> fabbione: timezones are for weak humans.
<Hobbsee> real people, and aliens ignore timezones!
* Hobbsee notes that dict is failing her
* Hobbsee checks google
<fabbione> Hobbsee: the first hit in google is good enough
<Hobbsee> fabbione: looks tasty
<fabbione> for an alien it's lovely
<Hobbsee> hehe :)
<fabbione> even for a human tho ;)
<fabbione> Hobbsee: i guess you can see that's all the internal of a baby cow...
<Hobbsee> yeah
<ajmitch> sounds tasty
<fabbione> it is
<fabbione> with lots of red wine is even better :)
<Hobbsee> heh
<Hobbsee> the stuff i dont drink, yes.
<fabbione> oh white is ok too
<Hobbsee> oh goody.  yesterday was payday.
<LaserJock> evening
<Hobbsee> hiya LaserJock!
<LaserJock> hi Hobbsee!
<ajmitch> hello LaserJock 
<Fujitsu> Hi LaserJock.
<LaserJock> hi guys
<LaserJock> Fujitsu: stellarium 0.9.0 is already in Debian, we just need a sync request
<Fujitsu> LaserJock: I noted that right after I commented. It doesn't seem to build here at the moment, due to the curl breakage.
<LaserJock> ah, I hadn't built it yet, that's why I didn't comment
<StevenK> It needs archive mangling before it will, too.
<Fujitsu> How often does NBS stuff get kicked out?
<StevenK> When the archive peoples get around to it.
<StevenK> I need to mention this curl mess to pitti when he gets here, I'll bring it up then.
<pitti> Good morning
<Fujitsu> Hi pitti.
<Hobbsee> morning pitti!
* StevenK waves to pitti.
* Fujitsu watches StevenK burn to the ground.
<StevenK> pitti: Bad, bad, bad news. :-( And it's all my fault. :-(
<pitti> StevenK: oh?
* Hobbsee sprays Fujitsu with the fire hose
<pitti> StevenK: the missing Conflicts/Replaces:?
<pitti> StevenK: or did libcurl get a new soname over night? :-P
<Fujitsu> pitti: That's not bad bad bad news.
<StevenK> pitti: No, and no.
<StevenK> pitti: Worse. Versioned symbols worse!
<StevenK> pitti: libcurl.so.3 doesn't provide a CURL_4 symbol to link against.
<pitti> StevenK: erm, I thought it was supposed to, and Debian made it work like .so.4?
<pitti> StevenK: that means that everything that links against .so.4 doesn't work ATM?
<StevenK> pitti: Right.
<StevenK> pitti: It terms of the Conflicts/Replaces, I uploaded a fix a while ago.
<pitti> StevenK: umpf; is that known in Debian, too?
<StevenK> pitti: But in terms of what to do about this, I think we have two possible solutions. 1) Revert my changes, take the hit and do the rebuilds. 2) Hack our libraries to provide both versions at the same time.
<StevenK> pitti: I'm not sure, they may not have gone as far through the transition.
<pitti> StevenK: hm, TBH I don't have an idea how to achieve (2)
<pitti> hey tfheen 
<Hobbsee> morning tfheen 
<StevenK> pitti: I do. Apply a patch after configure that plays with libcurl.vers
<Mithrandir> hi pitti
<pitti> StevenK: ah, my hero
<StevenK> pitti: I'm not certain if it will work, though.
<ajmitch> morning Mithrandir, pitti 
<pitti> hi ajmitch 
<dholbach> good morning
<pitti> hey dholbach 
<dholbach> hey pitti
<pitti> argh, argh, p-lp-bugs
<LaserJock> hi dholbach 
<dholbach> hey LaserJock
<dholbach> pitti: hm?
<pitti> dholbach: I just thought I'm going crazy
<dholbach> ok good :)
<pitti> set([94694, 103275, 111139] ) + set([94694, 103275, 111139] ) == set([103275, 111139, 111139, 94694, 103275, 94694] )
<pitti> and so on; I got a steadily growing set with duplications of those three elements
<pitti> dholbach: this is a BugList result, btw
<Mithrandir> uh, a set with duplicates in it?
<pitti> Mithrandir: that's what I thought, too :)
<pitti> until I noticed that those are in fact not integers, but strings
<pitti> but it took me 20 minutes to resolve that miracle
<pitti> dholbach: so I added a loop which converts the string set from BugList to a set of ints
<Mithrandir> still, it should use a comparison function and see that they're the same?
<pitti> dholbach: but that could really bite other apps, too
<dholbach> pitti: please let thekorn know, so we can get it in with the API changes
<pitti> Mithrandir: apparenty set collapsing uses identity, not equivalence
<pitti> I'm not sure whether this is a feature or a bug, though
<dholbach> we will have to find out :)
<Mithrandir> buture, I'd call it. :-P
<pitti> dholbach: yeah, I'll write a bug
* dholbach hugs pitti
<lifeless>  prefer fug
<pitti> dholbach: btw, would you mind blessing me to a bughelper developer? would avoid always annoying you or mvo with merging/uploading a p-lp-bugs fix
<dholbach> pitti: blessing?
<Mithrandir> pitti: he wants to join yet another team. :-P
<pitti> dholbach: joining the team for getting push access to the main branch
<pitti> Mithrandir: s/pitti:/dholbach:/?
<dholbach> gosh
<Mithrandir> pitti: yeah, nicks are hard in the morning.
<dholbach> I thought you were part of the team already
<dholbach> done
<pitti> dholbach: only of the team that can actually upload and screw up the package :-) but I'd rather not have the main branch get of of sync
* pitti hugs dholbach, thanks
<Hobbsee> Mithrandir: but he who dies being on the most teams wins!
<Mithrandir> Hobbsee: you can also win if you transcend, I thought.
<dholbach> how many emblems do YOU have? ;-)
<Hobbsee> Mithrandir: transcend hey?
<Mithrandir> dholbach: only 18. :-P
<Mithrandir> Hobbsee: I believe you did not catch the reference.
<Hobbsee> Mithrandir: you're correct, i didnt.
<Hobbsee> Mithrandir: i dont know all of your earth-references.
<Mithrandir> it's a nethack reference
<Hobbsee> ahh
<dholbach> 28, muhuhuahhahaha ;-)
<Hobbsee> awww, only 17 here with emblems.  24 teams, directly and indirectly
<Mithrandir> I have a couple without emblems too, but nowhere near Daniel's level.
<StevenK> Gee, I'm only 13 emblems.
<Hobbsee> dholbach: the more emblems you have, the more reviews and sponsorships you have to do.
<Hobbsee> dholbach: so get going!
<Hobbsee> :P
<mdke_> morning all
<Hobbsee> morning mdke!
<dholbach> Hobbsee: I did a bunch of reviews already :)
<Hobbsee> dholbach: not enougH :P
* dholbach hugs Hobbsee
<pitti> dholbach: ok, I gave a detailled explanation in bug 123933
<ubotu> Launchpad bug 123933 in python-launchpad-bugs "BugList should return a set of int, not string" [Undecided,New]  https://launchpad.net/bugs/123933
<dholbach> pitti: you rock
* Hobbsee hugs dholbach 
<Hobbsee> :)
<LaserJock> hi mdke 
<mdke> dholbach: would you try and do an ubuntu-docs upload today from our trunk? We haven't done one yet, and it would be nice just to get something uploaded, even if only to fix bug 121810. I haven't tested anything but it should work since not much has happened since the feisty release
<ubotu> Launchpad bug 121810 in ubuntu-docs "Gutsy has Feisty documentation" [Medium,Confirmed]  https://launchpad.net/bugs/121810
<dholbach> mdke: yes, will doo
<mdke> thanks
<dholbach> de rien
<StevenK> pitti: Right, my hacks for curl don't work.
<pitti> StevenK: :(
<pitti> StevenK: so, we'll solve the problem with buildd horse power then?
<StevenK> pitti: Looks like.
<StevenK> pitti: If that it's the case, we should revert my last 2 changes for curl, too.
<pitti> StevenK: in which direction would it be easier? towards soname 3 or 4?
<StevenK> 3, since that's where Debian has landed.
<StevenK> And there are slightly less to do.
<pitti> ok
<pitti> StevenK: yeah, so the package should be reverted back to only have the build dep change
<StevenK> pitti: Right.
<StevenK> pitti: I'll do that tonight, and start making a list of the rebuilds.
* pitti finally looks into setting up cron'ed cruft checking
<dholbach> hey seb128
<seb128> hi dholbach
<Hobbsee> morning seb128 
<seb128> hello Hobbsee
<ion_> you.find_all {|person| not person.idle? }.each {|person| hello person }
<dholbach> mdke: hum... looks like a stuff went missing - I'll make sure to use trunk, but re-add all the debian/ changes
* Hobbsee replaces ion_ with a small shell script
<dholbach> mdke: looks like feisty and trunk were not in sync
<mdke> dholbach: I thought that I'd synched everything, but I suppose I may have missed something... What isn't working?
<dholbach> mdke: looks like debian/ changes gfrom 7.03.2 on are missing
<dholbach> mdke: in changelog, control, copyright and rules
<dholbach> ok, remove copyright from the list - that was a valid change
<mdke> ouch
<dholbach> I fixed it
<mdke> thanks
<dholbach> I'll send you the patch
<mdke> :)
<dholbach> mdke: disregard the mail I just sent
<mdke> ok
<dholbach> mdke: sent you another mail - this time it should be fine
<mdke> thanks :)
<dholbach> uploaded the package too
<mdke> dholbach: can't seem to apply the patch...
<dholbach> uh?
<dholbach> it should apply to trunk
<mdke> lemme paste
<mdke> you updated your copy of trunk right?
<dholbach> yes
<mdke> http://paste.ubuntu-nl.org/28461/
<mdke> disregard lines 15-17
<dholbach> patch -p1 < .......?
<dholbach> is that a clean checkout of trunk?
<mdke> I'll check
<mdke> ugh
<mdke> I must have done the sync myself in local and forgotten to upload it
<mdke> works now, sorry about that
<dholbach> ok super
<dholbach> *phew*
<dholbach> I just thought I might have uploaded the wrong branch or something ;-)
<mdke> :)
<mdke> thanks for your help dholbach 
<dholbach> anytime
<pitti> StevenK: http://people.ubuntu.com/~ubuntu-archive/NBS/ -> now generated daily at 0:00 and 12:00
<Fujitsu> libcurl4-dev can be killed without any changes, can't it?
<StevenK> pitti: Excellent.
<StevenK> pitti: ~pitti/tmp/cruft has ceased to exist, too?
<pitti> StevenK: let me delete it, it's obsolete
<StevenK> pitti: While you're deleting stuff, purge libcurl4-dev from the archive? It's NBS, and it may negatively impact on this mass rebuild.
<pitti> StevenK: *flush*
<StevenK> pitti: Thanks
<StevenK> pitti: Sorry for all this confusion, I feel dreadful for not picking up on the versioned symbols thing. :-/
<pitti> StevenK: no worries, nobody thought about this
<pitti> ScottK: pinentry promoted
<StevenK> pitti: curl uploaded. The 0:00 and 12:00 for NBS re-generation is UTC?
<pitti> StevenK: it's drescher time, which is BST
<StevenK> Which is UTC, at this point.
<pitti> StevenK: no, other hemisphere ;)
<pitti> StevenK: UTC+1 from March to October, UTC otherwise
* StevenK nods.
<StevenK> I knew that, hence why I said "at this point" :-)
<pitti> StevenK: hm, I thought "at this point" == "now"
<StevenK> Now as in this time of year. :-)
<pitti> so, drescher is at UTC+1 now
<StevenK> TZ=BST == TZ=UTC here
<pitti> that would be weird
<StevenK> Oh wait, it's because TZ=BST doesn't exist, and date is braindead
<dholbach> doko_: how do I use java web start in ubuntu? do we have that?
* pitti uploads editmoin into universe
<pitti> seb128: ^ I don't want to source NEW this myself, so maybe you can get to it today?
<doko_> dholbach: it should be there
<dholbach> doko_: how do I start it? where do I get it from?
<crimsun> Applications> Internet> Sun Java foo Web Start
<dholbach> hum, then I don't have it - do you know which package it is in?
<seb128> pitti: I just uploaded gtksourceview2, which is basically a gtksourceview new version with API,ABI changes which they versioned so it doesn't conflict with the previous one ... maybe you want to look at this one in exchange ? ;)
<seb128> pitti: I don't expect problems since we already have gtksourceview and that's rather a new version
<pitti> seb128: sure, my pleasure
<seb128> cool
<seb128> looking a editmoin
<crimsun> dholbach: sun-java[56] -bin
<dholbach> crimsun: i have both installed
<dholbach> maybe I'm blind
<crimsun> dholbach: /usr/share/applications/sun-java5-javaws.desktop?
<dholbach> nope
<crimsun> dholbach: (on gutsy, BTW)
<dholbach> yes, on gutsy too
<seb128> sun-java6-bin: /usr/share/applications/sun-java6-javaws.desktop
* dholbach tries on i386 (was on amd64)
<pitti> seb128: wow, 1.90.1 -> 1.90.2 had a soname change?
<seb128> pitti: no, 1.8.5 -> 1.90.1 had
<seb128> pitti: 1.90.1 has been prepared by a contributor but he didn't rename things correctly so I did cleanup while updating
<pitti> seb128: do you need that in main? why do we still need the old version?
<pitti> aah
<seb128> pitti: yes, we need that in main, old version ... we can move it to universe or drop it when applications have been ported to the new API
<pitti> gedit
<pitti> gnome-python-desktop
<pitti> gnome-python-extras
<pitti> screem
<pitti> ok, not that many
<seb128> gedit is already ported
<pitti> seb128: ok, thanks
<seb128> gnome-python-* upstream will do it most likely
<seb128> I'll have a look at what screem is doing
<seb128> I expect we will move the old one or drop it before gutsy
<dholbach> go java go!
<dholbach> crimsun, doko_, seb128: thanks it exists on i386, but not on amd64
<seb128> dholbach: what an idea to use amd64 ;)
<seb128> pitti: editmoin accepted
<pitti> yay
<pitti> seb128: gtksourceview2 accepted
<seb128> danke :)
<pitti> someone please file an apport crash bug, I want to check a new toy :)
<gnomefreak> pitti: just file bug on app that crashes and sends report to LP?
<pitti> Mithrandir: hm, has MoM been stopped? it hasn't updated since yesterday apparently
<pitti> gnomefreak: I can file a demo bug, too, but maybe someone has something useful :)
<gnomefreak> let me see if firefox still crashes and you can have it :)
<gnomefreak> pitti: i gotr tbird to crash but apport tells me i dont have enough memory to report it safe to just upload crash report
<pitti> gnomefreak: ok, nevermind; thanks
<gnomefreak> sorry
<pitti> np :)
<pitti> gnomefreak: you see, the very best that could happen is when nobody would report a crash any more. ever. :)
<gnomefreak> true :)
<seb128> pitti: opinion on bug #123860?
<pitti> and in the other 1-10^(-10) range of probability I'll get one sooner or later
<ubotu> Launchpad bug 123860 in apache "please remove from archive" [Undecided,New]  https://launchpad.net/bugs/123860
<pitti> seb128: ah, have all rdepends now been removed/fixed? cool
<pitti> seb128: indeed geser and I have worked on that
<pitti> seb128: hm, checkrdepends is next to unusuable, since there are so many alternative dependencies
<seb128> right, I was running it, there is still quite some things listed there
<pitti> seb128: but we can just kick it out of the archive and then use apt-cache unmet to fix/delete the remaining ones
<seb128> pitti: k, let's do it
<seb128> Debian removed it
<pitti> yay! it took long enough to get rid of it, but finally \o/
<seb128> :)
<pitti> * debian/rules: remove symlink-dupes bits.
<pitti> dholbach: ^ not necessary any more? the changelog doesn't have a rationale
<Mithrandir> pitti: unsure, I can check after I've eaten some breakfast
<dholbach> pitti: trunk did not contain it anymore
<Mithrandir> pitti: I think removing a1 at this point is fine; Debian has already done so.
<pitti> seb128: weird, there's no gutsy-changes@ mail for editmoin, but it seems to be getting published now
<pitti> Mithrandir: I agree
<seb128> hum
<seb128> pitti, keescook: apache removed now
<keescook> neato
<keescook> thanks!
<thom> yay
<seb128> ;)
<Mithrandir> PARTY!
<Mithrandir> :-)
<seb128> pitti: editmoin accepted, I did a typo before and didn't notice, thanks for mentionning it ;)
<seb128> dholbach: 
<seb128>  o sng: sng
<seb128>    [Reverse-Build-Depends: human-icon-theme] 
<dholbach> seb128: hm?
<seb128> dholbach: could you have a look at why human-icon-theme Build-Depends on sng and either make it not or file a MIR?
<seb128> dholbach: sng wants to go to main because of human-icon-theme
<seb128> and the current build "Dependency wait"
<dholbach> ok, I'll try to find out who synced that
<seb128> you talked with Riddell I think
<seb128> and you agreed that Debian merged all the changes
<dholbach> I did not agree
<dholbach> Riddell said that the only thing that was different is the changelog
<dholbach> anyway
<dholbach> ...
<dholbach> I'll fix it
<dholbach> the branch wasn't updated either
<seb128> dholbach: k, thanks ;)
<Riddell> dholbach: you still need to merge tangerine-icon-theme
<dholbach> Riddell: ok
<seb128> Toadstool: xfce4-cellmodem-plugin debian/Copyright has a "GNU Library General Public License for more details", why is the "Library" mentionned there, the software is under GPL
<seb128> Tonio_: do you want kaffeine-gstreamer to main? In which case you need to get it seeded or have something depending on it
<Riddell> ogra or whoever: what's the password that's equivalent to a blank password?
<ogra> Riddell, "U6aMy0wojraho" i think
<Mithrandir> ogra: that's correct.
<Tonio_> seb128: hum, the point is that unfortunatelly we need xine for amarok, so let's use kaffeine-xine in the first place maybe...
<Tonio_> seb128: if amarok would have been gstreamer capabe, i would have say yes, but that'll have to wait for kde4 I guess
<seb128> Tonio_: so you want kaffeine-gstreamer moved to universe?
<Tonio_> seb128: yep
<Tonio_> seb128: wasn't it already demoted ? thought it was for a very long time
<seb128> Tonio_: it's listed on http://people.ubuntu.com/~ubuntu-archive/component-mismatches.txt
<Tonio_> hum right, so yes, you can demote it to universe, no pb
<seb128> Mithrandir, pitti: should be better demote a binary from a main package or add them to supported? 
<dholbach> seb128: fixed
<seb128> dholbach: danke ;)
<Mithrandir> seb128: depends on what it is; if there's no point in keeping it in main, just demote it
<seb128> Mithrandir: I don't like much splitting binaries from a same package between main and universe, that often creates problems for users
<seb128> it happens quite often that they enable -updates for main only by example
<Mithrandir> which package is this?
<seb128> which one? the one we received quite some bugs about was totem-xine
<Mithrandir> nah, the one you're wondering if you should demote or not
<seb128> I'm looking at the component-mismatches.txt list
<seb128> no special example
<seb128> take kaffeine-gstreamer for example if you want
<seb128> Mithrandir: well, that's not likely a problem for most of them if they don't force Depends
<seb128> it was for totem-xine because totem-mozilla has a versionned Depends
<seb128> and the totem-mozilla update from main was breaking without universe (no match totem-xine to upgrade)
<dholbach> Riddell: done
<pitti> seb128: for innocent packages I prefer to have them seeded, for the reasons you described
<pitti> seb128: only if it would introduce complex dependencies or is particularly hard to maintain, we should demote it
<seb128> pitti: ok, I've the same opinion
<Tonio_> dholbach: fyi, I just packaged the latest kdebluetooth, with dbus support
<Tonio_> dholbach: not everything works of course, but you won't have to patch bluez-utils anymore :)
<Tonio_> dholbach: we'll probably include it soon to the archives, needs discussing intoday's meeting
* allee kicks Tonio
<keescook> pitti: can you check on the sanity of php-imap and php-mcrypt ?  I can't find the builds, but the source was accepted.  I'm assuming it's still caught in some archive blacklist?
<pitti> keescook: https://launchpad.net/ubuntu/+source/php-imap/5.2.3-0ubuntu1 -> that looks fine?
<pitti> keescook: it didn't build yet
<pitti> dholbach: yay, I could finally upload a p-lp-bugs bug fix myself \o/
<keescook> pitti: ah!  there seems to be some kind of dead-time between upload and a build showing the state "Pending".  :)  i'm too impatient.  :)
<pitti> keescook: source needs to get published first
<pitti> keescook: i. e. at about 40 minutes past the hour
<keescook> okay.  sorry for the noise.  :)
<pitti> no problem
<Fujitsu> pitti: Doesn't publisher run at about 3 minutes past?
<pitti> Fujitsu: it starts at that time, right, and finishes around 40 past
<Fujitsu> Ah.
<Fujitsu> That's... fairly long.
<pitti> indeed :/
<Fujitsu> I saw some binaries published at about 4 minutes past a few hours ago...
<pitti> but we'll get "build from accepted" soon, which will speed up the process considerably
<Fujitsu> We had build-from-accepted, but didn't it get turned off because it stuffed up changelog-closes-bugs?
<pitti> Fujitsu: they might be shown as that in the launchpad UI, but not on archive.u.c.
<pitti> Fujitsu: right
<Fujitsu> Ah. Right, that makes sense.
<Mithrandir> we haven't had build-from-accepted with soyuz.
<Tonio_> seb128: is there a maintainance or something on the archives ?
<seb128> Tonio_: what do you mean?
<Fujitsu> Mithrandir: I saw a comment saying it was turned off shortly after 1.1.6 was released, because it broke things.
<Tonio_> seb128: I have strange issues in pbuilder, packages are downloaded but then apt complains size missmatch
<Tonio_> seb128: also happens on a clean and new chroot...
<seb128> Tonio_: change your mirror maybe?
<Tonio_> seb128: well I use the standard, but yeah, I can try with fr.
<Tonio_> seb128: will let you know if the error also occurs there
<seb128> ok
<pitti> hey rodarvus 
<rodarvus> hey pitti :)
<rodarvus> nice to see you!
<pitti> rodarvus: and you! how's life?
<dholbach> Tonio_: rock on! - do we need the bluez-utils patch then still?
<dholbach> pitti: rock on!
<Tonio_> dholbach: not with this one
<Tonio_> dholbach: but it'll take a bit of time to get it in
<Tonio_> dholbach: hopefully that'll be done or feisty
<dholbach> ah ok
<Tonio_> dholbach: there is a big bunch of bugs, upstream wants to fix them in the next 2 weeks, and we have a li to get in main
<Tonio_> dholbach: maybe in about one month it'll be in
<dholbach> alright
<dholbach> cheers
<Tonio_> that'll be for for "gutsy" sorry ;)
<dholbach> *nod* :)
<Tonio_> dholbach: first thing is to write a MIR I guess :)
<Tonio_> seb128: I can confirm the issue on all mirrors
<Tonio_> seb128: all the corrupted packages seems to come out of the kdepim src package
<seb128> Tonio_: maybe something on your machine, broken RAM or something
<seb128> did anybody else complained about that?
<Tonio_> seb128: not yet, but I cannot reproduce with any other build, that's what looks strange to me...
<Tonio_> seb128: it only concerns a very specific set of debs
<seb128> Tonio_: which ones?
<Tonio_> seb128: all debs produced by kdepim src package...
<Tonio_> seb128: https://launchpad.net/ubuntu/+source/kdepim/4:3.5.7-1ubuntu4
<Tonio_> seb128: this version, which builds succesfully
<Tonio_> seb128: hum works with apt.... that's probably a local problem with pbuilder, even if I can't figure out what is the problem....
<Tonio_> seb128: no need to waste time on that point
<gicmo> ALTER-S
<seb128> gicmo: Alter!
<seb128> pitti: can you have a look to pygtksourceview in NEW, it should be trivial
<pitti> seb128: doing
<StevenK> pitti: 37 ubuntu/curl-cruft/src-list
<seb128> pitti: can you also consider it for main directly? I've started writting https://wiki.ubuntu.com/MainInclusionReportPygtksourceview but there is not a lot to write, it's a trivial binding package and it's NEW
<StevenK> pitti: That's discounting stuff like openoffice and apt, but covers about 95% of them.
<pitti> seb128: don't bother, it's just a new upstream version; I already put the source into main
<pitti> StevenK: that means 37 rebuilds? that's not too bad after all
<StevenK> pitti: Right.
<pitti> seb128: ah, *py*gtksourceview; yes, I'll have a look
<pitti> seb128: so you already binary-NEWed gtksourceview2?
<seb128> pitti: yes ;)
<pitti> seb128: is this going into Debian? I don't like -1 uploads into Ubuntu
<seb128> pitti: well, I think it'll go one day in Debian, I'm not working on it for Debian though
<pitti> seb128: could you rename it to -0ubuntu1?
<seb128> pitti: they will need to get gtksourceview2 first
<StevenK> pitti: What's worse is it's over half a gig of packed and unpacked source.
<pitti> StevenK: eww
<pitti> StevenK: we should do that in the DC then
<seb128> pitti: there will be a new version before Debian gets it for pretty sure but if you want, sure
<pitti> StevenK: even without OO.o?
<pitti> seb128: hm, point
<StevenK> pitti: Correct, even without OO.o
<pitti> seb128: but still, common practice and all that
<StevenK> 557Mb
<seb128> pitti: well, we package it first, there is no reason we can't use -1 ;)
<StevenK> pitti: Uploading it is okay, since most if not all of them aren't native.
<pitti> StevenK: if you don't want to download that, can you check which ones can do with a mere no-change rebuild? I'll do these in the DC with a script then
<seb128> pitti: do you reject this one? I'll reupload using 0ubuntu1
<pitti> seb128: yes, I will
<pitti> seb128: it looks fine otherwise
<StevenK> pitti: I already have downloaded them all
<seb128> pitti: cool
<StevenK> pitti: It's quite alright, telling you for information purposes. :-)
<pitti> StevenK: oh dear, poor Australian internet straw
<StevenK> pitti: Don't remind me. :-P
<Hobbsee> pitti: dont you have a go at the shoestring, else it may break!
* pitti does not send a reply to StevenK or Hobbsee to not strain the shoestring even more with IRC replies
<StevenK> :-P
<Hobbsee> pitti: you have a phone.
<Hobbsee> :P
<pitti> hey, all my packets fly through the air and are occasionally eaten by birds, rain, etc., so I feel with you :)
<StevenK> pitti: I'm tempted to test build all 37 of them, but that might take all night.
<pitti> StevenK: that's what we have buildds for :)
<Hobbsee> pitti: dont let Mithrandir hear you say that...
<StevenK> Heh
<pitti> StevenK: for such mass transitions it's generally accepted to throw them at the buildds and clean up after the one or two that fail afterwards
<Hobbsee> pitti: he decided to have a go at me during Developer Weather Report over that one...
<StevenK> pitti: Aye.
<pitti> Hobbsee: developer time >> buildd time
<Hobbsee> pitti: right.  i'm using that as my rationale next time.
<StevenK> I didn't think I was smart enough to be a developer. :-P
<pitti> hm?
<StevenK> pitti: That hm is for me or Hobbsee?
<Hobbsee> for you, StevenK 
<Mithrandir> Hobbsee: If I came across that way, I apologise.  I meant you should test build when you've done changes to the package.  If it's just a rebuild for a transition where you believe there is no breakage involved in the rebuild, it's less important to test first.
<pitti> StevenK: still trying to interpret your sentence
<Hobbsee> Mithrandir: :)
* Hobbsee hugs Mithrandir 
* Mithrandir bounces
<StevenK> pitti: It parses correctly for me..
<Hobbsee> Mithrandir: why bouncing?
<seb128> pitti: 0ubuntu1 uploaded
<Mithrandir> Hobbsee: just in general.
<Hobbsee> Mithrandir: fair enough
<Hobbsee> Mithrandir: i dont test build when i'm fairly certain that it wont fail.
<StevenK> I always test build.
* StevenK cleans up his /home so he has more than 35Mb free, first.
<Hobbsee> Mithrandir: mind you, i never said that you having a go at me over not test building was not warranted...
<StevenK> 1.8G. Much better.
<Mithrandir> Hobbsee: heh. :-P
* Hobbsee stomps on Mithrandir's feet.
<Mithrandir> ouch
<pitti> why is she always so violent to our feet?
<Mithrandir> bad Hobbsee!
<Hobbsee> pitti: because people didnt seem to like being kicked in the shins.
<StevenK> Heh
* Hobbsee isnt bad!
<Mithrandir> Hobbsee: while we like that you stomp our feet?
<Hobbsee> well...
<Hobbsee> pitti: violence is the solution to any problem!  :P
<Hobbsee> unless it's against me.
<Hobbsee> unless it's used against me.
<pitti> seb128: accepted
* seb128 hugs pitti
<seb128> pitti: thank you!
<pitti> de rien
<seb128> now I can update gedit ;)
<pitti> seb128: oh, gedit is written in python now? :)
<seb128> pitti: only plugins ;)
<ccm> can somebody tell me please whats the console command to launch the disk analyzer?
<ccm> think it crashes on tribe-2 but i only find the icon
<ccm> and want to investigate on the command line
<cjwatson> ccm: clarify "disk analyzer"?
<Fujitsu> ccm: baobab?
* StevenK wonders how to use gpg-agent
<ion_> stevenk: I recommend keychain
<Mithrandir> StevenK: echo use-agent >> ~/.gnupg/gpg.conf
<Mithrandir> then log in again.
<StevenK> Let's just say I have 37 uploads to sign, and the thought of having to type my > 20 character passphrase 74 times doesn't appeal.
<Keybuk> I hope you weren't so lazy testing them ;-)
<Keybuk> why do you have to type it 74 times, anyway?
<StevenK> Signing the .changes and .dsc
<Keybuk> ah, of course
<Keybuk> (I've used gnome-gpg for so long, it's been years since I signed one directly :p)
* Mithrandir ruffles gpgsm
<StevenK> mMithrandir: Which means it will prompt once and remember the passphrase?
* Hobbsee hugs pinentry-qt
<StevenK> s/^m//
<Mithrandir> StevenK: AIUI, yes
<ccm> cjwatson/ Fujitsu: it seems to be baobab, thank you 
<StevenK> Mithrandir: gpg: gpg-agent is not available in this session
<Mithrandir> what is $GPG_AGENT_INFO set to?
<Mithrandir> you might need to eval `gpg-agent`
* ion_ still recommends adding keychain to your X and shell sessions. It initializes gpg-agent and ssh-agent nicely.
<StevenK> Hrm. Command not found.
<ion_> With it, each session shares the same instance(s) of the agents.
<ion_> So you need to type the password even less.
<Mithrandir> ion_: no, it doesn't, not when you're not using the stock gpg agent, nor the stock ssh agent.
<ion_> Well, there are many ways to configure the system so that keychain doesnt work. :-)
<cjwatson> err, x11-common ships an ssh-agent session script itself, and gnupg-agent ships a gpg-agent session script
<cjwatson> you don't need keychain to get that feature
<ion_> Agents started that way arent shared between sessions.
<ion_> which is the point of keychain.
<cjwatson> oh, between X sessions not between terminal sessions. OK.
<cjwatson> that might help me deal with agents in chroots more elegantly
<StevenK> Sigh. I can't script it because pinentry-curses is brain-damaged
<ion_> Keychain starts the agents once and they keep running until stopped or the system is halted. No matter how you login to the box, you environment always points to the same agents.
<iwj> The cmos clock in this laptop is very very confused.
<iwj> /dev/sda4 has gone 49710 days ...
<mjg59> iwj: Is that immediately after install?
<elmo> we get that immediately after every netboot install we do, ATM
<Hobbsee> greetings mjg59, elmo 
<mjg59> It's something to do with the timezone changing during the install
<iwj> mjg59: t
<iwj> This is from a gutsy CD with no networking.
<iwj> 49710 days is rather more than a timezone.
<mjg59> What I think it /actually/ means is "/dev/sda4 has gone -1 hours"
<iwj> 49710*86400
<iwj> 4294944000
<iwj> So I now see.
<geser> pitti: re apache: I've got a list with the remaining apache rdepends and their Debian bugs about it
<mjg59> Quite why fsck is doing unsigned arithmetic, I'm not sure
<StevenK> geser: I was planning on filing a large removal request for apache modules with no rdepends.
<geser> StevenK: what happens if the Debian maintainer decides to build it with apache2 (if possible)?
<cjwatson> mjg59: possibly suggests that the CMOS clock is failing in such a way that it's zero on initial boot until you get NTP going?
<StevenK> geser: For some of the modules I can't see it happening, and it only means they hit NEW if the Debian maintainer does.
<geser> ok, are you interested on my list for the rdepends with their Debian bug numbers?
<StevenK> geser: I have my own list of the rdepends.
<StevenK> pitti: All 37 libcurl4 rebuilds uploaded.
<pitti> StevenK: yay, thanks
<StevenK> pitti: No problem. I think I might kill someone if Debian handles another transition like this one. :-)
<Hobbsee> StevenK: now now.  killing people is BAD.
<geser> will those libcurl4 transitions debs be removed again?
<Hobbsee> StevenK: else let me kill the people at work, dammit!
<StevenK> geser: They have been already, if you'd checked.
<StevenK> Hobbsee: :-P
<mjg59> cjwatson: No, I get it on known good hardware
<StevenK> pitti: Did you NBS libcurl4{,-gnutls} (again)?
<cjwatson> mjg59: can't think why else mkfs would set the modtime to -1
<mjg59> cjwatson: No, it's set it to one hour ahead of the current time
<cjwatson> oh I see, ok
<cjwatson> yes, it's tricky because of (a) ordering of bits of the install and (b) the hardware clock isn't actually set in the installer at all
<cjwatson> I think the fix should be some combination of clobbering mkfs to adjust the mtime it sets, and clobbering the boot scripts to do hardware clock vs. fsck in the right order (which is tricky)
<mjg59> cjwatson: I suspect that the easiest thing to do would just make fsck do it with signed values and ignore negative numbers
<asac> Keybuk: Mithrandir ... do you know anything about the origin of our 05-debian-backend patch in NM? e.g. when and where did it first appear? I don't find anything in changelog
<Mithrandir> asac: written partially by Scott and partially by me.
<asac> good ... look http://paste.ubuntu-nl.org/28497/ lines 74,81 ... or lines 94,101
<asac> what is that hunk for? whatever it does ... the outcome should completely undeterministic
<Mithrandir> uh, unsure
<Mithrandir> I don't think I wrote that bit of the code.
<asac> yeah ;)
<Hobbsee> or if you did, you're nto claiming it!
<Mithrandir> it'd be easy enough to check if I did.
<asac> how?
<Keybuk> asac: that's the meat of our patch
* Keybuk wrote it
<asac> funny thing is I don't find any bug that has a message that is outputted there ... so it looks like the code is never used?
<asac> hehe
<Keybuk> the code is used all the time
<asac> he ... so what happens if it returns FALSE?
<Keybuk> oh. wait a minute
<asac> what it definitly will from time to time
<Keybuk> sorry, wrong hunk
<Mithrandir> it's just dialup bits.
<Keybuk> I thought you were referring to the blacklist stuff
<asac> no ... lines above
<Keybuk> the dial-up bits probably came from Debian unmodified
<Keybuk> my apologies
<asac> status not initialised
<Keybuk> yeah, no idea on that
<Keybuk> certainly wasn't me; I never touched dial-up related stuff
<asac> another blind spot is 17_avahi_autoipd.patch ... its completely undocumented in changelog
<asac> http://paste.ubuntu-nl.org/28499/
<asac> thats the patch
<Mithrandir> that's pitti's code.
<asac> pitti: ^^^
<asac> pitti: and can we go over the ifup/down bug lets say tomorrow? ... i still cannot follow your reasoning ... at least not for the original bug reporters case.
<pitti> asac: right, let's
<pitti> asac: however, I did document the patch; maybe it was lost in a merge?
<asac> huh
<pitti> asac: however, I think we can drop it anyway
<asac> when should that --check exit with 0?
<asac> i cannot get it exit with zero ;)
<ScottK> pitti: Thanks (for pinentry).
<Hobbsee> seb128: now, what were you saying to me yesterday....?
<geser> StevenK: I got home only an hour ago, so I hadn't time to check it
<Hobbsee> :P
<pitti> asac: when I wrote it, it seemed that avahi would need avahi-autoipd to work, but n-m's own code should do as well
<pitti> asac: it will exit with 0 if autoipd is running on an iface
<geser> StevenK: you seem to have much time now to do archive cleanups. Will you work through the apache rdepends or should I do it?
<asac> ok ... when do you have a slot tomorrow (1 hour) to look at the ifup/down bug?
<StevenK> geser: I'm happy to do it.
<asac> pitti: ^^
<pitti> asac: I'll do some experiments and check whether we can drop the patch
<Hobbsee> geser: see http://people.ubuntu.org.au/~fujitsu/debcheck/
<StevenK> I've been doing archive cleanups for a while.
<pitti> asac: yes, no problme
<asac> pitti: thanks
<shirish> ubotu paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<asac> pitti: shall i just ping ... or do you prefer some time ... like 8 in the morning ;) ?
<pitti> asac: just ping me, I don't have anything special planned for tomorrow
<asac> great
<crimsun> Keybuk: hi, is it possible to run MoM for selected source packages in main?
<pitti> asac: I'll check out the current state of autoipd interaction
<shirish> StevenK: I'm sorry to bring it here but I hope you know about http://paste.ubuntu-nl.org/28503/
<Keybuk> crimsun: yes, though why do you need to?
<crimsun> Keybuk: I'd like to merge alsa-driver from Sid
<StevenK> shirish: They are being taken care of.
<shirish> StevenK: ok thanx, just wanted to bring it to your notice, that's all :)
<Hobbsee> StevenK: https://launchpad.net/bugs/124008 too, it looks like
<ubotu> Launchpad bug 124008 in curl "libcurl4-openssl no longer exists" [Undecided,New]  
<Keybuk> crimsun: what's wrong the the published merge?
<crimsun> Keybuk: 1.0.14-1 is the current Sid one; MoM lists 1.0.13-5
<shirish> StevenK: there is also this http://paste.ubuntu-nl.org/28504/
<shirish> that's gnash in firefox-granparadiso 
<geser> shirish: all this should get fixed if all the rebuilds are done and on the archive
<Keybuk> crimsun: mom is still updating, probably hasn't updated the html yet
<Keybuk> http://merges.ubuntu.com/a/alsa-driver/
<Keybuk> has 1.0.14-1
<shirish> geser: I am hoping, I didn't want to file a bug as I know things are in transaction
<crimsun> Keybuk: ah, ok.  Thanks.
<geser> StevenK: I assume bug #123826 can also be closed
<ubotu> Launchpad bug 123826 in curl "libcurl3-gnutls gutsy upgrade failed" [Undecided,New]  https://launchpad.net/bugs/123826
<Keybuk> a big "day" from Debian
<StevenK> Hobbsee: Thanks, sorted out.
<geser> shirish: ask again if the problem is still there in the next week
<Hobbsee> StevenK: no problem
<shirish> geser: cool :)
<StevenK> geser: Closed.
<StevenK> shirish: It looks I missed gnash.
<shirish> :)
<StevenK> shirish: I'll sort out that now, thank you.
* Hobbsee :( .  No heno.
<shirish> keep up the good work guys, I'm gonna watch 'Its a beautiful life' for the umpteenth time :)
<geser> StevenK: you've also missed gnupg2 (at least LP doesn't show a recent upload)
<StevenK> geser: So noted.
* Hobbsee ponders laptop keyboards as pillows
<StevenK> Heh
<sladen> Hobbsee: find real people, they're softer (though they move about more too)
<Mithrandir> laptop keyboards are wonderful pillows
<Hobbsee> sladen: i think i did at UDS a couple of times...
<simira> sladen :) Where are you now?
<pitti> asac: I blame Mithrandir; http://changelogs.ubuntu.com/changelogs/pool/main/n/network-manager/network-manager_0.6.3-2ubuntu7/changelog still has my changelog, and the subsequent merge dropped it
<pitti> asac: let's restore the 0.6.3-2ubuntu[1-7]  logs on next upload
<asac> pitti: cool
<seb128> pitti: do you usually merge the changelog entries?
<pitti> seb128: yes, of course
<asac> seb128: i hope so
<seb128> "of course"
<seb128> we don't for desktop packages ...
<seb128> we just summarize all the change in the merge entry
<pitti> well, explaining everything is fine, too
<pitti> if that includes bug numbers, etc.
<seb128> that's easier to read, easier to merge and there is no need to keep a zillion of old entries
<pitti> (I usually do both)
<asac> seb128: depends how much development was put into your changes
* Hobbsee makes a mental note to destroy all cameras at the next UDS that she's at.
<bhale> Hobbsee: ?
<asac> if its really development vs. a one-line bug fix ... having a verbose explanation is good
<seb128> asac: well, the summary has explanation for the patches, etc
<Hobbsee> bhale: so they cant take photos of me, and use them for talks.
<asac> ah ... depends on who made the patches :)
<asac> seb128: but then yes
<cjwatson> desktop is a historical exception, but standard practice in the rest of the distro is to keep old changelog entries unless syncing with Debian
<ScottK> Hobbsee: What package is the bug against?
<asac> pitti: bug 124018
<ubotu> Launchpad bug 124018 in network-manager "reinstantiate dropped changelog entries on next upload" [Undecided,Confirmed]  https://launchpad.net/bugs/124018
<Hobbsee> ScottK: kubuntu-meta, i guess
<ScottK> OK.
<seb128> Hobbsee: hey, I was saying something yesterday?
<Hobbsee> ScottK: whichever
<pitti> asac: (or summarize the patches)
<pitti> asac: thanks
<Hobbsee> seb128: a few days ago.  @ gstreamer0.8-swfdec
<Hobbsee> seb128: did you see the ping in -bugs? :P
<seb128> Hobbsee: yeah, but he left before I replied :p
<Hobbsee> seb128: completely coincidently, of course :D
<pitti> asac: ok, autoipd patch still works for eth devices, but not for wifi
<seb128> indeed ;)
<mjg59> cjwatson: I think just adding a cast to line 288 of e2fsck/unix.c would do
<asac> pitti: when does avahi step in? recently i had an avahi eth interface after crashing network-manager ... but i usually don't have it
<pitti> asac: /etc/dhcp3/dhclient-exit-hooks.d/zzz_avahi-autoipd
<pitti> asac: i. e. if DHCP times out, dhclient starts avahi-autoipd on that interface to get an IPv4ll address
<asac> hmmm ok ... might have been related as networking was completely broken after nm crash .. anyway .. i would have expected to dhclient to just retry
<pitti> and a manual 'iwconfig eth1 mode ad-hoc essid pittinet; dhclient eth1' still works
<asac> the outcome was completely broken ... e.g. networking didn't work at all
<pitti> asac: n-m starts dhclient with -1, so it won't retry
<pitti> so n-m doesn't call dhclient correctly for ad-hoc wifis, as it seems
<asac> i don't have wifi
<pitti> asac: the idea was to have autoipd kick in if you create a new wireless network (ad-hoc), and thus don't have DHCP
<asac> just plain eth
<pitti> asac: for that it should work; plug in a cable without a running DHCP server, and you should get an ipv4ll address after 30 seconds (DHCP timeout)
<asac> yeah ... for me it brought brokeness ;) ... just because my dhcpd was down for a while
<asac> or not reachable ... anyway ... nevermind
<pitti> asac: well, it doesn't break the network any further
<asac> no idea how i can get back to that state
<pitti> asac: if you don't have DHCP, then wit ipv4ll you have at least *some* valid address
<pitti> instead of none at all
<pitti> asac: hm, it doesn't seem to trigger dhcdbd at all for wifi
<asac> hmmm  i am not convinced
<pitti> gosh, I'll track that down later
<asac> anyway ... i might be wrong :)
<pitti> asac: what's your doubt?
<asac> my doubt is that i ended up in unusable state
<pitti> asac: do you think that having an ipv4ll address is worse than having none?
<asac> yeah ... if having none is just temporary
<pitti> asac: right, because your DHCP server was down; nothing that n-m could do about fixing that :)
<asac> it should not have removed my ip to start with
<pitti> asac: when did it remove it?
<asac> i have no idea ... network  manager crashed ... ip was removed ... and avahi interface went up
<mjg59> cjwatson: Ben Hutchings points out that it looks like older e2fsck versions did this differently
<mjg59> Which is probably why we didn't see it in the past
<asac> anyway ... its not reproducible
<pitti> asac: that very much sounds like this infamous bug 90267 :)
<ubotu> Launchpad bug 90267 in network-manager "network-manager stops and restarts already ifup'ed interfaces" [Critical,Confirmed]  https://launchpad.net/bugs/90267
<asac> iirc, it happened when i restarted dbus in my gutsy chroot or something
<asac> pitti: yeah ... hope it is :) ... lets look at that tomorrow
<cjwatson> mjg59: looks plausible, but I think somebody who understands it and has thought it all through should apply that :-)
<pitti> asac: I can perfectly reproduce that, and it's easy to do; anyway, tomorrow
* pitti -> dinner
<dholbach> ogra: new gnome-power-manager
<ogra> thanks :)
<dholbach> de rien
<asac> pitti: i never claimed that the ifup'ed bug doesn't exist :) ... i am just unsure if the initial reporters problem was really due to that bug
<geser> StevenK: as you work your way currently through the NBS files: I've already looked at gnome-chemistry-utils (one of the last depends on libgoffice-0-3). g-c-u 0.6 doesn't build with libgoffice-0-4. So it needs either patching or the current stable version g-c-u 0.8 which does.
<Hobbsee> geser: it's 2.30am here - he'll be asleep
<Mithrandir> Hobbsee: unlike you? :-P
<geser> Hobbsee: I should install some clock which shows me also the time in .au
<Mithrandir> geser: 'TZ=Australia/Sydney date'
<sladen> pitti: unable to renew shouldn't (from the user point of view) lead to "break my working config".  On non-flakey networks with silly renew times (eg. 600 seconds) I kill -9 dhclient once I have a working config so that it won't pull the carpet from under my feet the next time it misses 3 packets in a row, on a congested network
<sladen> s/non-/known-/
<dholbach> use tzwatch :)
<ogra> dholbach, wow, you were even faster than the announce mail ;)
<Mithrandir> sladen: if the lease expires, it should bring down the interface.
<ogra> just got it
<Hobbsee> Mithrandir: he does slightly saner timezones than i do.  and i had a kubuntu meeting.
<Hobbsee> Mithrandir: i'm a night owl, remember?
<dholbach> ogra: I'm not :)
<Mithrandir> Hobbsee: I've noticed
<Hobbsee> :)
<dholbach> I got the mail before already :)
<geser> Hobbsee: you live in the wrong timezone :)
<ogra> dholbach, well, then i blame my evo for slowness :P
<Hobbsee> geser: i know.  i plan to move to europe at some point in the future.
<Mithrandir> Hobbsee: hopefully you then won't just switch to hawaii time
<sladen> Mithrandir: there's "should" and "should".
<geser> Hobbsee: which TZ value should one now use to know when you sleep (you do still sleep, do you?)?
<Hobbsee> Mithrandir: haha, true
<Hobbsee> geser: hell yes, i still sleep.  european time, or so
<Hobbsee> maybe berlin time + 4 hours or something
<sladen> Hobbsee: move to European.  Less holes in the Ozone layer!
<Hobbsee> sladen: the plan is there.  the execution is not.
<Hobbsee> sladen: okay, the vague plan is there, the detailed plan and execution is not.
<ogra> sladen, she wants to tan a bit before :)
<geser> StevenK: but g-c-u 0.8 needs a new openbabel (I've got updated debs for both) but I'm currently stuck at gchempaint (it needs to be updated too because of the new g-c-u)
<Hobbsee> ogra: i go red.  ask kgoetz if you want.
<Hobbsee> ogra: i dont seem to tan much
<geser> StevenK: could you help me with it?
<ogra> Hobbsee, ah, well, probably more ozone helps that then :)
<Hobbsee> heh
<seb128> ogra: gnome-power-manager 2.19.5 available
<Hobbsee> ogra: and i've found out that i dont like keeping on whiting/blacking out due to major dehydration, after said sunburn :P
<ogra> seb128, heh, yes, thanks 
<sladen> Hobbsee: post degree plan?
<ogra> dholbach, seb128's evo is slower *g*
<Hobbsee> ogra: i could walk 6 steps - and splat
<ogra> seb128, thanks :)
<Hobbsee> sladen: yeah, something like that.  i think.  switching degrees anyway, so i may be able to do bits overseas.  *shrugs*
<Hobbsee> sladen: havent looked into it
<seb128> ogra: not sure, I'm just not sleeping the whole day in front of it ;)
<ogra> lol
<rexbron> mr_pouit: hey, could you check your email. I sent you a message regarding Murrine
<Keybuk> openoffice ... anyone know how to adjust the scale of the chart
<Keybuk> if I want it so the X-Axis goes from 0 to 100, whatever the data, how do I do that?
<Mithrandir> scale your numbers?
<fabbione> cjwatson: what is the installer package in charge to detect disks? When installing, right before you go to the partitioner, there is that sequence of modprobe of different modules..
* fabbione needs to check if there is also a udevtrigger in the sequence 
<cjwatson> fabbione: disk-detect
<fabbione> cjwatson: thanks
<cjwatson> fabbione: and yes, it calls udevtrigger via update-dev in debian-installer-utils.
<fabbione> cjwatson: am I blind, but i can't see it in debian/svn ?
<fabbione> cjwatson: ok cool then i don't even need to look at it..
<cjwatson> fabbione: apt-cache showsrc disk-detect ...
<fabbione> point
<Keybuk> gnargh, now how do I get OO to print in frickin' Landscape
<geser> Keybuk: Format -> Page
<Keybuk> geser: ah
<Keybuk> I tried the "Portrait"/"Landscape" box in the Print dialog ... silly me
<Keybuk> I would do anything for the person who comes up with a decent set of "Office" applications
<ion_> vim-latex
<ion_> ...suite
<pitti> ion_: and latex-beamer!
* pitti -> Taekwondo, cu tomorrow
<Keybuk> ion_: sorry, something that involves *less* pain than openoffice
<Toadstool> seb128: re xfce4-cellmodem-plugin, I'm a moron, please reject it. I used the same debian dir as the one for xfce4-cddrive-plugin and obviously screwed up big time when I updated debian/copyright. I'd better do something else than packaging sorry for the noise
<seb128> Toadstool: it's not that bad, just fix that line and it's good enough ;)
<seb128> Toadstool: use the text in /usr/share/debhelper/dh_make/licenses/gpl (dh-make)
<Toadstool> yep, thanks
* desrt waves to keybuk
* desrt is licked
<LaserJock> cjwatson: available?
<cjwatson> LaserJock: sure
<dholbach> http://wiki.ubuntu.com/DesktopTeam/WeeklyTODO needs some applause, I think :)
* LaserJock claps
<xxxxx1> heya people
<xxxxx1> bug #122852
<ubotu> Launchpad bug 122852 in ecryptfs-utils "[gusty gibbon]  Ecryptfs Hangs during file save" [Undecided,Confirmed]  https://launchpad.net/bugs/122852
<xxxxx1> can someone give a look at this bug?
<xxxxx1> is related to gutsy Linux kernel version
<xxxxx1> if someone have a suggestion... i'll appreciate
<xxxxx1> :)
<dholbach> xxxxx1: #ubuntu-kernel maybe?
<xxxxx1> dholbach, >:)
<xxxxx1> wrong channel, sorry
<xxxxx1> heh
<dholbach> no problem :)
<geser> LaserJock: are you familiar with gnome-chemistry-utils?
<LaserJock> yes
<LaserJock> I work on it upstream, although that's fairly recent
<LaserJock> geser: what do you need?
<geser> the current g-c-u in gutsy depend on libgoffice-0-3 which got replaced with libgoffice-0-4
<geser> is it ok to update to g-c-u 0.8?
<LaserJock> geser: yes, I think so
<LaserJock> geser: 0.8.1 is new (even includes some icons I did, scary)
<geser> LaserJock: is gchempaint also save to update to gchempaint 0.8.*?
<LaserJock> geser: safe?
<geser> yes, safe
<LaserJock> geser: hmm, well 0.8 is nice, but I'm not sure about the deps
<LaserJock> geser: I kinda think that our openbabel isn't higher enough
<LaserJock> blah, high enough version
<geser> the homepage for gchempaint mentions that 0.6 doesn't build with g-c-u 0.8 so it would be wise to update it also
<LaserJock> yeah, I'll ask Jean about that
<geser> LaserJock: yes, I needed to update openbabel too
<LaserJock> we're working on 0.9 right now
<LaserJock> we do the "odd unstable, even stable" versioning
<LaserJock> geser: I do know that debian is working on openbabel
<geser> and as openbabel changed the soversion to 2, so gchempaint needs at least a rebuild
<geser> ok, I try to get in contact with the Debian maintainer
<LaserJock> debichem is the place to ask
<geser> LaserJock: is http://lists.alioth.debian.org/mailman/listinfo/debichem-devel the right one?
<LaserJock> geser: http://lists.alioth.debian.org/pipermail/debichem-devel/2007-June/000073.html
<LaserJock> geser: yeah
<geser> so I will wait with the whole batch
<Chipzz> if I wanted to file a bug I'm sure also applies to debian, where would I file it? launchpad or debian bts?
<geser> both? and link them
<mpt> Chipzz, what geser said
<sladen> our Firefox disable middle-click URL paste patch seems to have been dropped
<AlinuxOS> hello doko!
<AlinuxOS> ;)
#ubuntu-devel 2007-07-05
<geser> StevenK: about gnome-chemistry-utils and gchempaint (rdepends of libgoffice-0-3 (NBS)): I'll mail the Debian maintainers if updated packages are planned in the near future
<azeem> they are
<azeem> geser: well, I think Debian is waiting for libgoffice-0-3
<LaserJock> well, 0.3 is the unstable version
<LaserJock> hopefully 0.4 will be in unstable soon
<azeem> yeah, ok
<azeem> geser: what's the problem with g-c-u in Ubuntu anyway?
<LaserJock> geser: it's old and we have goffice 0.4
<LaserJock> g-c-u 0.8 need goffice 0.4
<azeem> did 0.4 get released as a stable version upstream?
<LaserJock> yes
<azeem> ok
<LaserJock> really Ubuntu should lead the packaging for g-c-u
<LaserJock> because we tend to take goffice from Debian experimental
<azeem> I think it also needs a newer openbabel
<LaserJock> yes
<LaserJock> 2.1
<azeem> one option would be to upload it to exprerimental as soon as 2.1 is released
<LaserJock> it's odd to me that goffice has been in experimental for over a year
<LaserJock> there aren't really a lot of packages that depend on it
<azeem> because it was an unstable release series I guess
<LaserJock> I suppose
<azeem> goffice (0.4.0-1) experimental; urgency=low
<LaserJock> but 0.4 has been out for about 2 months now
<azeem> * New upstream development release.
<azeem> that's odd, yes
<azeem> I'm gonna ask jbrefort about it when I see him next
<LaserJock> azeem: I talk to him most every day
<azeem> heh
<LaserJock> hmm, the Debian maintainer maintains 64 packages it seems
<LaserJock> I wonder if he just doesn't have time to work on goffice
<LaserJock> StevenK: so what are you doing now with libcurl?
<StevenK> LaserJock: Plotting flaming death for the Debian release team and the Debian maintainer.
<LaserJock> sweet
<LaserJock> so did you end up reverting your transition?
<StevenK> The transitional libcurl4 packages got killed again, and I've just finished the second lot of sixty rebuilds
<LaserJock> so we are going to go to libcurl4 ?
<StevenK> Nope, we are heading back to libcurl3
* LaserJock is a little confused
<LaserJock> so we tried to go to libcurl4 but it didn't work so well so we're going back to libcurl3?
<ajmitch> SONAME screwups
<StevenK> Debian went to libcurl4, found a complete path of pain, and went back to libcurl3.
<LaserJock> there's a forum thread so I thought I'd give a response if I figure out what's going on
<LaserJock> StevenK: unless you want to write it? ;-)
<StevenK> We went to libcurl4, did a bunch of rebuilds, and then pitti and I decided the bitter pill needed to swallowed at some point, so we first tried to provide libcurl4 packages, which didn't work, and so went back to libcurl3 and a complete bunch of rebuilds.
<StevenK> LaserJock: I'm not eloquent enough. :-)
<LaserJock> and I am?
<LaserJock> somebody might as well do it
<StevenK> LaserJock: You're probably more eloquent than I am. :-)
<ajmitch> of course, he's a doc writer
<StevenK> Good point.
<LaserJock> ajmitch: and that means what exactly? :-)
<LaserJock> I'm dumb enough to get suckered into writing
<LaserJock> StevenK: is that because libcurl4 was supposed to be compatible with libcurl3?
<StevenK> LaserJock: Supposed to be
<StevenK> LaserJock: The problem is because Debian includes a patch that versions the symbols, so they aren't really compatible ...
<LaserJock> umm ... darn
<StevenK> LaserJock: As you can tell, it's a little complicated anyway.
<LaserJock> mhm
<LaserJock> well I just made a post
<LaserJock> as the thread started 1hr ago and already has like 5-6 posts
<StevenK> LaserJock: Link me?
<LaserJock> http://ubuntuforums.org/showthread.php?t=492502
<StevenK> Thanks
<LaserJock> please feel free to correct/add to my post
<StevenK> Hrm. I might have to duke it out with amarok, too.
<StevenK> That would require signing up to the forums. :-)
<LaserJock> really? I thought you had an account there
<StevenK> If I do, it's news to me.
<LaserJock> maybe it was ScottK 
<ScottK> What was maybe me?
* ScottK does have an account with maybe a full handfull of posts.
<ScottK> Now that I've read the scrollback.
<LaserJock> sorry, my bad
<LaserJock> wahoo, first "real" upload to Main
<shirish> StevenK: are you there buddy?
<shirish> StevenK: ok just so you know whenever u come back openoffice also needs rebuilding for the libcurl thing
<LaserJock> morning Hobbsee 
<LaserJock> or afternoon
<LaserJock> or whatever it is there
<Hobbsee> hey LaserJock!
<Hobbsee> meh.  i just got up, so it's morning
<ajmitch> a nice definition of morning
<Hobbsee> yep
<ajmitch> very flexible
<LaserJock> hmm, it seems like app-install-data got turned into app-install-data-ubuntu
<Hobbsee> it's morning in europe
<LaserJock> very early morning
<LaserJock> Hobbsee: how's life?
<Hobbsee> LaserJock: life?  it's going OK.  i'm waiting, whcih is sucking a bit :)
<ajmitch> waiting for exam results?
<Hobbsee> that too
<fabbione> morning
<Hobbsee> hiya mpt, fabbione 
<fabbione> StevenK: ping?
<StevenK> fabbione: Pong
<fabbione> StevenK: i just noticed the big rebuild of death for libcurl. Are you going to take care of main too? at least git-core needs love
<fabbione> StevenK: or do you need people to sponsor to main?
<Hobbsee> fabbione: he's a core dev
<fabbione> ok
<StevenK> Thanks for noticing. :-P
<fabbione> Hobbsee: sorry i can't remember everybody :)
* Hobbsee has persuaded *him* to upload *her* stuff before :P
<StevenK> fabbione: git-core should be fixed.
<fabbione> StevenK: ok
<Hobbsee> fabbione: you need a better memory.
<fabbione> Hobbsee: i need to be 10 years younger :)
<StevenK> Heh
<mpt> hi Hobbsee 
<Hobbsee> fabbione: good luck finding that time machine.
<fabbione> hmm StevenK I guess we also need an OOo rebuild...
<StevenK> fabbione: Correct. But pitti told me not to touch it, which I plan on following to the letter. :-)
<fabbione> ehehhe
<ajmitch> let calc handle it?
<StevenK> Suits me.
<fabbione> all good :)
<StevenK> fabbione: Are you a big bad buildd person?
<fabbione> StevenK: no sorry, i have no access to the buildd
<StevenK> fabbione: It's fine, I can wait.
* StevenK waves to pitti
<Hobbsee> morning pitti!
<StevenK> pitti: I missed a bunch of rebuilds - 21, which I've done.
<StevenK> pitti: The total is 62, with 3 FTBFS on all archs, and 3 FTBFS on ia64 only.
<StevenK> pitti: The 3 FTBFS on all archives can be fixed with a give-back. The three are bibletime, cduce and gnomesword.
<StevenK> s/archives/archs/
<pitti> Good morning
<pitti> StevenK: I'll give them back, thank you!
<StevenK> pitti: Thank you. :-)
<pitti> hi Hobbsee!
* Hobbsee hugs pitti :)
<StevenK> pitti: I think that this publisher run should polish off the rest of them. Now I can look at other stuff, like apache 1
<pitti> StevenK: you are tireless, aren't you? :) *MUST* *CLEAN* *ARCHIVE*
<Hobbsee> pitti: s/tireless/insane/ i suspect
<StevenK> Both?
<Hobbsee> pitti: you should make him an archive admin next, so he can cue his own stuff :P
<StevenK> pitti: Hey, if it helps you and Hobbsee in your jobs, and cuts down on the number of bugs, I'm all for it.
<Hobbsee> StevenK: you could help me in my job by going to work for me tonight.
* Hobbsee hopes that the boss hasnt utterly screwed up the rosters *again* for tonight.
<StevenK> Hah
<LaserJock> umm, stupid bash question, can I have a variable in a variable name?
<StevenK> I think so.
<Treenaks> ${$WHATVER} ?
<Treenaks> no.. that doesn't work
<StevenK> Doesn't for me, either.
<StevenK> LaserJock: You can in Perl...
<Treenaks> eval?
<StevenK> That works
<StevenK> foo="blah" ; eval lala${foo}="foo" ; echo $lalablah
<minghua> You can, I just forgot the grammar.
<LaserJock> blah
<LaserJock> I should just do this in python
<minghua> $ A=B; B=foo; echo ${!A}
<minghua> foo
<StevenK> That smells like a bash-ism
<StevenK> It is, too
<minghua> Yes, definitely bashism.
<mikmorg> Is there any way to do something like: dpkg --install --recursive --pending pool/*.deb ?
<mikmorg> Ie. I want to install given a path, only the files marked for installation
<dholbach> good morning
<dholbach> hey pitti
<pitti> hey dholbach 
<pygi> good morning folks
<mdke> morning all
<pygi> hey mdke 
<pitti> StevenK: so, the give-backs mostly worked, except for some ia64 stuff
<pitti> StevenK: looking forward to this noon's NBS output :)
<Tonio_> pitti: there is a little problem with libcurl-gnutls, it has been reverted, but I think version 0ubuntu3 should be removed (the deb files) from the repos, since libcurl4-gnutls is still there, so wants to be installed, and conflicts with latest version
<Tonio_> pitti: looks like the "real" package is prior to the virtual one and thus that blocks the all openoffice installation..... a bit annoying :)
<pitti> Tonio_: ah, right; I just asked doko_ about a new OO.o, but we should wait for Chris
<Tonio_> oki
<dholbach> hey seb128
<Tonio_> pitti: to be honnest I don't know if the problem is due to libgnutls or openoffice.... looks like OOo should be rebuild with libcurl3-gnutls, but I may be wrong...
<seb128> hi dholbach
<Tonio_> dholbach: we'll be able to make a point on kdebluetooth in about 3 weeks, time for upstream to heavilly fix bugs and us to prepare a nice package
<Tonio_> hey seb128
<seb128> hi Tonio_
<dholbach> Tonio_: rock and roll - that's good news
<siretart> asac: do you use a VCS for network-manager?
<Fujitsu> Tonio_: OOo needs to be rebuilt; all other packages depending on libcurl4{,-gnutls} except apt have been already.
<pitti> Tonio_: it should, right, and the 4 stuff needs to be removed
<pitti> siretart: yes
<pitti> siretart: https://code.launchpad.net/network-manager
<siretart> ah, excellent
<siretart> thanks
<pitti> yay, apport-failed-retrace tags work now, as well as removing the CoreDump.gz for successful retraces
<YokoZar> Is there an Ubuntu.com jabber server?
<Fujitsu> YokoZar: I don't believe so, but it is particularly not suitable for this channel.
<YokoZar> Fujitsu: I meant for developers and people with @ubuntu.com email addresses
<pitti> shawarma: ah, langpack bootstrap on PPA is finally done; the buildd is unDoSed again now :)
<Fujitsu> pitti: That took a while.
<pitti> erk, yeah
<pitti> in the old days I built the entire batch of 300 packages in 10 minutes or so
<Fujitsu> But now we have some reasonable translations
<Fujitsu> *?
<pitti> Fujitsu: the packages itself didn't change a lot, but with PPA I don't need to have nasty hacks for maintaining an archive for myself and care about domination and multiple releases and such
<pitti> Fujitsu: and it's easier to just sync/copy the packages from the PPA to archive.u.c.
<Fujitsu> pitti: Is PPA working OK?
<shawarma> pitti: Yes, I used it last night, too. It's alright, I just thought it was going to be like that every day. I'm calmer now. :)
<mdz> morning all
<Fujitsu> Hi mdz.
<pitti> Fujitsu: apart from buildd shortage, yes
<pitti> shawarma: no, I only build new daily packages when there are actually some changes; those are usually 10 languages or so
<Fujitsu> Still just the two?
<Fujitsu> Oh, and one won't have been doing anything, because it's amd64?
<pitti> shawarma: I enable the cronjobs on rookery again now, let's see whether it's sustainable
<pitti> Fujitsu: right
* Fujitsu hugs pitti for StacktraceSource.
<pitti> Fujitsu: is it useful for you? cool
* pitti flips the switch to upload daily gutsy langpack straight to the archive; let's see how that goes
<mikmorg> Could anyone help me out - I can't remember the command that tricks 'uname -r'
<pitti> mikmorg: sounds like an #ubuntu question; but 'tricks'?
<mikmorg> pitti: yea, sorry.. actually probably more like ##linux.. but there is a standard way to make it return a false value if I remember right.
<pitti> seb128: ah, nice: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=apport-failed-retrace
<pitti> seb128: CoreDump.gz removal for successful retraces works now, too
<seb128> pitti: rock on!
<seb128> pitti: good job ;)
* pitti goes to fix various bugs in lib->package mappings which are likely to be responsible for the failures
<cjwatson> mikmorg: you could do it with an LD_PRELOAD wrapper for uname(2); a standard way doesn't spring to mind
<seb128> pitti: the compiz one is "CoreDump" is not a core dump: File format not recognized"
<seb128> pitti: I'm wondering where the coredump is screwed, the non debug backtrace looks ok, so it means it was working on the user machine
<Fujitsu> pitti: Why am I seeing a lot of bugs tagged apport-crash that are several days old?
<pitti> seb128: I have a lot of cases where /lib/tls/i686/cmov/lib*-2.6.so cannot be identified
<pitti> seb128: that might account for a good deal
<pitti> Fujitsu: because that tag is a permanent one; it denotes the ProblemType: (crash, package, kernel, etc.)
<Fujitsu> pitti: Ahh, but they were also not retraced.
<pitti> seb128: also, some parsing bugs: "its package compiz-fusion-plugins-main,universe is not available" or "but its package libs is not available" :)
<pitti> Fujitsu: please give me the numbers, I'll look in the logs
<Fujitsu> pitti: I don't know any offhand, but I'll find some in a sec.
<Fujitsu> Bug #123870
<ubotu> Launchpad bug 123870 in listen "[gutsy]  listen.py crashed on exit (SIGSEGV in PyThreadState_New())" [Undecided,New]  https://launchpad.net/bugs/123870
<Fujitsu> pitti: ^^
<pitti> Fujitsu: ah, broken core dump: struct.error: unpack requires a string argument of length 4
<siretart> is anyone using mwolson's emacs22 packages here yet?
<seb128> siretart: "mwolson"?
<siretart> pitti: would emacs22 need a MIR?
<pitti> Fujitsu: since it's the gzip wrapping that is damaged, and not just the compressed core dump itself, I suspect that something went wrong during upload or so
<siretart> seb128: Michael Olson <mwolson@gnu.org>, discussed the last days on ubuntu-motu@
<pitti> siretart: no, I don't need one; however, I *do* want only one emacs in the archive :)
<siretart> pitti: its rather a new upstream (in a new source package)
<pitti> siretart: well, s/archive/main/ at least
<siretart> I see
<Fujitsu> pitti: I guess that would do it.
<pitti> Fujitsu: I updated the bug and removed the core dump attachment
<Fujitsu> pitti: So I aw.
<Fujitsu> *saw
<dholbach> can somebody give back gnome-terminal on amd64 and sparc?
<pitti> dholbach: doing
<dholbach> thanks pitti
<Nafallo> running update-initramfs multiple times in one run is going to be fixed in gutsy, right? :-)
<pitti> sabdfl: good morning Mark
<Nafallo> ...and morning * :-)
<cjwatson> Nafallo: https://blueprints.launchpad.net/ubuntu/+spec/dpkg-triggers
<cjwatson> targeted, but as ever not certain
<Nafallo> cjwatson: thanks. I'll subscribe if I'm not already :-)
<crimsun> is cprov the one to ask about alsa-driver source uploads silently going the way of /dev/null, possibly due to a rather extensive LP: #foo entries?
<crimsun> (on the order of 25 bugs)
<cjwatson> crimsun: I looked into it briefly, and it's certainly well beyond a humble archive admin to sort out
<cjwatson> http://launchpadlibrarian.net/8312458/fSl6HTFlQliJLUZlM1vUKk7DaiY.txt
<pitti> http://launchpadlibrarian.net/8312459/6qiBYhYEVQ0X5VDjVgz0H9EEer9.txt, too
<pitti> crimsun: something between carlos (Rosetta import) and cprov, I think
<crimsun> ok, thanks.
<carlos> pitti: hmm, I don't think it's related with me
<pitti> carlos: right, entirely a permission problem
<pitti> it just seems to happen during translation tarball import
<carlos> pitti: hmm, that backtrace is about sending the notification email
<carlos> pitti: where do you see it related with translation uploads?
<pitti> SELECT pluralforms, code, uuid, direction, visible, pluralexpression, nativename, englishname FROM Language ...
<pitti> carlos: but that's just where it dies with a permission error on anguage
<pitti> language
<carlos> that doesn't mean it's a translation upload problem
<carlos> it looks more related with answers tracker
<carlos> it also uses language table
<carlos> Translations is not the only user for that information anymore
<Sp4rKy> dholbach: around ?
<Sp4rKy> dholbach: you commented bug #124145
<ubotu> Launchpad bug 124145 in libtunepimp "Please merge libtunepimp (main) from Debian unstable (main) " [Undecided,In progress]  https://launchpad.net/bugs/124145
<Sp4rKy> the depends was remove in the last debian update
<ogra> woah ...
<ogra> did anyone here ever try to run gnome in 8bit graphics mode ? 
<Sp4rKy> dholbach: (appears in libtunepimp_0.5.3-4.patch )
<seb128> ogra: no, does it crash?
<ogra> seb128, yeh, like mad
<Sp4rKy> dholbach: anyway, no doc about this change, so i'm not sure it has to be added ...
<ogra> panel restarts in an endless loop
<seb128> ogra: there is a known cairo bug
<ogra> ah
<seb128> looks like it's not trivial to fix
<ogra> well, not that i'd expect any users to run gnome in 8bit
<ogra> :)
<seb128> ogra: https://bugs.freedesktop.org/show_bug.cgi?id=4945
<ubotu> Freedesktop bug 4945 in general "Cairo doesn't support 8-bit pseudocolor visuals" [Critical,New]  
<coNP> actually why not (esp. with vnc)?
<seb128> coNP: let's say it's not a standard usecase
<ogra> wow, seems there are some concerned actualy
<mjr> vnc can color-convert from higher bpps to 8bpp for transit
<mjr> anyway, it's not so long that my SO used a 8bpp SparcStation as an X term...
<dholbach> Sp4rKy: it was added in 0.5.3-3 - "fix depdendencies to be binNMU safe"
<Sp4rKy> yep
<Sp4rKy> but i don't know why it was removed 
<dholbach> it's removed in your debdiff
<Sp4rKy> yes
<Sp4rKy> and it was removed in the debian update
<dholbach> yeah, you didn't merge it into your patch
<Sp4rKy> i didn't merge it because it was explicitly removed in the debian update
<Sp4rKy> http://paste.dunnewind.net/8
<dholbach> oh ok
<Sp4rKy> line 17/18
<dholbach> now I see it too
<Sp4rKy> :)
<dholbach> excusez-moi :)
<Sp4rKy> ^^
<Sp4rKy> np
<Sp4rKy> so i don't need to add it ?
<dholbach> no, let me review it again
<dholbach> if it's good, I'll upload it
<Sp4rKy> ok
<Sp4rKy> np
<pitti> keescook: btw, it seems I can remove the ptrace hack from apport's _read_maps() again? IIRC you said that ptracing is not necessary any more?
<keescook> pitti: yes, that's correct.
<StevenK> Oh, damn.
* StevenK fixes nexuiz harder.
<persia> StevenK: There's a sync that might help (I've just been drafting the bug)
<StevenK> persia: For what?
<persia> StevenK: nexuiz / curl
<StevenK> Cool. I'll ignore uploading it, and pitti/someone else can sync it.
<pitti> StevenK: tell me once you confirmed it
<persia> StevenK: No promises that Debian was perfect - testing is on my immediate TODO :)
<Fujitsu> StevenK: What went wrong with it?
<StevenK> Fujitsu: I fixed nexuiz, and not nexuiz-server.
<Fujitsu> Ah.
<StevenK> So now the sync can.
<pitti> crimsun: still here?
<pitti> crimsun: cprov evaluated the error; you can either unlink the answer tracker item from the bug report and upload again, or wait a bit longer (should still happen today) for the real fix
<Mithrandir> is it possible to remove an offer of mentorship from another person?
<persia> Well.  That was exciting.  nexuiz 2.3-2 compiled against updated libcurl, installed successfully, and overheated my graphics card during testing.
<persia> pitti: Do you want a sync bug for nexuiz, or is here good enough?
<pitti> persia: are you a MOTU?
<persia> pitti: Yes.
<persia> pitti: https://launchpad.net/~persia/+participation
<pitti> persia: good enough for me then
<persia> pitti: Thanks.
<Mithrandir> we usually want bugs so we have a trail
* persia files a "Fix Committed" Bug as a trail
<pitti> persia: just use requestsync; I'll get to it later then
<persia> pitti: OK.  Thanks.
<StevenK> pitti: I wish checkrdepends could cope with multiple packages at once. I'd rather not have it download every Packages.gz file for gutsy it can lay its hands on 24 times.
<pitti> StevenK: true :) at some point this needs a more elaborate rewrite, also to get better output formatting
<pitti> like sorting all the arches to one line and such
* StevenK nods.
* StevenK wonders if he can cache the files somewhere
<Mithrandir> pitti: it's called a web proxy, isn't it?
<Mithrandir> s/pitti/SK/
<StevenK> I haven't trusted squid in quite some time.
<persia> StevenK: oops worked fairly well last time I was playing with proxies...
* Hobbsee waves
<Mithrandir> iz Hobbsee
<Hobbsee> Mithrandir: it iz!  R U Scared YET???
<Mithrandir> Hobbsee: should I be? ;-)
* Hobbsee lets the canon ball above Mithrandir loose, and watches as it falls on him, as a way of answering his question.
<Hobbsee> oh dear.  Splatted Mithrandir.
<Mithrandir> Hobbsee: good thing I just moved out of the way then.
* Mithrandir looks suspiciously at the hole in the floor where he just was.
<Hobbsee> Mithrandir: it fell where you moved.  you're out of luck.
<Hobbsee> it was big enough that it'd fall on you wherever you moved to.
<StevenK> pitti: Should I file bugs about Apache modules that Build-Depend on apache-dev, but not apache2-* and have no rdepends, or just tell you here?
<mdz> something is enabling laptop mode on my laptop in gutsy, when I switch to battery power
<mdz> causing bug 12483 to rear its ugly head again
<ubotu> Launchpad bug 12483 in linux-source-2.6.15 "laptop-mode/IDE-APM hang on various laptops" [Medium,Confirmed]  https://launchpad.net/bugs/12483
* Hobbsee keeps her finger off the kickban button for a second there.
<Hobbsee> damn these people with nicks the same length, and the same colour on my client.
<mdz> amitk: are you familiar with that bug?
<mdz> it would save a lot of headache and learning which new power management component is responsible, if laptop mode just worked
<amitk> mdz: not yet. I can have a look tomorrow at the earliest
<mdz> amitk: do you happen to know which package is responsible for activating laptop-mode?  this used to be done by acpi-support, but no longer
<amitk> mdz: no I don't
<kylem> mdz, laptop-mode-tools: /etc/init.d/laptop-mode
<kylem> /etc/init.d/laptop-mode stop
<mdz> kylem: thanks
<mdz> does laptop mode actually work properly on some laptops?
<kylem> yeah. it works fine on mine.
<pygi> hey folks
<Hobbsee> hiya pygi.  how's burning* going?
<pygi> Hobbsee, well, good, but I am more worried about my exams right now ^_^
<Hobbsee> pygi: when do they finish?
<pygi> Hobbsee, I had last written one yesterday ... if I pass, then it's oral one in the Monday, and that's it for now
<pygi> but it still leaves me with too much exams ... I was playing too much :p
<Hobbsee> pygi: heh
<Hobbsee> pygi: exams suck.  so does waiting for results.  but that sucks less than the exams :P
<pygi> Hobbsee, hehe :)
<Hobbsee> pygi: sounds cool :)
<Hobbsee> pygi: oral for what?  language or something?
<pygi> Hobbsee, no, that exam is "Organization"
<pygi> well, from that class
<Hobbsee> pygi: erk
<pygi> Hobbsee, for language exams I was forbidden to attend class one month and a half before end of it, and got A's :p
<pygi> so no exams for me there ^_^
<Hobbsee> pygi: a class on organization.  that's...interesting...seeing as anyhting you learned in that class would probably be negated by the time you spent being in that class
<Hobbsee> haha
<pygi> Hobbsee, just you laugh ^_^
* pygi thinks he need to learn more languages =)
<Hobbsee> pygi: so do i.  german will be useful if/when i move there.
<Hobbsee> or somewhere german-speaking.
<pygi> Hobbsee, ehm, you're moving?
<pitti> StevenK: removal bugs would be nice, for record keeping
<Hobbsee> pygi: sometime, yeah.  after uni, i expect
<pygi> Hobbsee, o well :)
<Hobbsee> pygi: australia's so far away from everythin gelse, etc
<pygi> Hobbsee, ah
<pygi> Hobbsee, a place is as far from everything else as you make it
<Hobbsee> heh
<pygi> Hobbsee, but I do understand you
<ijuz__> Hobbsee: i would not move to europe anymore, because it sucks
<Hobbsee> ijuz__: why?
<ijuz__> Hobbsee: politics are turning the EU into a state that would make Hitler and Mielke happy, i'm all negative
<Mithrandir> ijuz__: Europe != EU.
<ijuz__> well, .no and .ch is still there, but not much else
<pygi> ijuz__, Croatia is in Europe, and that's != EU as well :)
<Hobbsee> meh, politics
<thom> we're way, way off topic :-)
<pygi> thom, it's all fine tho ^_^
<ijuz__> yes, well, not really soon, the EU will have laws that will bring you in prison when you write free software  >:->
<Hobbsee> thom: it's no war.
<Hobbsee> :P
<wasabi> somebody needs to clearly define a difference between files in ~ which shoudl be shared between machines and ones that shouldn't.
<maswan> wasabi: "files in ~ should be shared between machines.", seems resonable, no?
<wasabi> Seems reasonable to me... but it implicitly implies files in ~ should be SHAREABLE between machines.
<wasabi> Which is not the case all the time.
<Hobbsee> hi calc 
<pitti> hi calc
<pitti> calc: do you plan a new OO.o upload soon? it's currently uninstallable due to the libcurl mess (it needs to be rebuilt against libcurl3)
<maswan> Yes, but this should be considered a bug, IMHO. Sharing the entire ~ is rather common if you have more than a couple of computers. Say at a workplace/university/similar.
<wasabi> Wonder how Beagle should handle that.
<wasabi> Since it's indexes are in ~
<calc> pitti: ah yea i will try to get that done asap
<calc> pitti: i can't run gutsy on my boxes due to several issues but i can build it in a chroot
<maswan> wasabi: name indexes after fqdn?
<calc> pitti: i just updated gutsy last night on my desktop and now it causes my machine to oops in the middle of apt-get dist-upgrade
<mynameisdeleted> winehq.org's wine crashes on my latest gutsy upgrade, and so does crossover office
<StevenK> pitti: Oh, can you ask mvo about an apt upload. I'm happy to do a rebuild update for it if he is.
<mynameisdeleted> both with the same error
<pitti> calc: we recently promoted lp-solve and usfparse to main, so that OO.o can use those external build deps instead of using the internal copies
<calc> pitti: and either wpa or ifupdown is broken on my laptop
<mynameisdeleted> and both in ld-linux
<pitti> calc: crash> oh, oops
<wasabi> maswan, I think my personal preference would be for indexes to not be in ~.
<Hobbsee> mynameisdeleted: please see the /topic
<wasabi> maswan, We're talking about huge files, which don't have much performance when network mounted.
<pitti> StevenK: yep, he's on vac; a mere rebuild won't hurt, though
<maswan> wasabi: that would be the sensible solution, yes
<StevenK> pitti: Shall I do it, then?
<calc> pitti: not sure what causes it but it does it every time i run the command
<Hobbsee> StevenK: i have an apt udpate anyway...
<wasabi> But then where should they go?
<Hobbsee> but i want to test it out first :)
<cjwatson> wasabi: I agree with maswan, I think non-shareable files in ~ are a bug
<pitti> StevenK: even if we should lose the changelog due to version control not seeing your upload, it doesn't matter much
<persia> wasabi: How about ~ indicies in ~, and machine indices in /usr/lib/beagle (/usr/lib to force local machine for shred /usr/share)
<pitti> calc: with the feisty kernel, too?
<cjwatson> wasabi: /var/lib/beagle/$USER?
<persia> s/shred/shared/
<cjwatson> or /var/spool or /var/cache or whatever
<cjwatson> definitely not /usr
<wasabi> All of those sound fine.
<StevenK> pitti: Right, I'll do it when I get up so I can keep an eye on it.
<wasabi> Now convince the beagle guys. ;
<calc> pitti: haven't attempted using the feisty kernel on my desktop since it was working fine with the same kernel before doing the update last night
* persia retracts in favor of cjwatson
<cjwatson> wasabi: surely changing paths is standard distro integration work
<pitti> calc: ah, it was just a daily update, not one from Feisty? hmm
<calc> pitti: i am going to try blasting the box and reloading feisty on it later today and make sure it is ok
<wasabi> Maybe.
<calc> pitti: yea a daily gutsy update caused the oops afaict
<maswan> cjwatson: splitting the indexing for ~ and rest of system might be an upstreams request though
<calc> pitti: of course blasting a production machine takes a while :\
<pitti> calc: you can check /var/log/dpkg.log to see which packages have been upgraded
<pitti> calc: and revert some which might be the culprit
<calc> pitti: it was quite a few i hadn't updated in a week or two
* ..[topic/#ubuntu-devel:Hobbsee] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Tribe 2 released
<pitti> calc: oh, erk; maybe install tribe-2 again instead of gutsy
<pitti> Hobbsee: topic diff?
<Hobbsee> pitti: adding gutsy support location
<coNP> pitti: #ubuntu+1 
<calc> pitti: if it works, i tried tribe-2 installer on my laptop last night and it couldn't get past partman
<calc> pitti: kept hanging up trying to set the partitions
<pitti> calc: ah, manual parittioner?
<calc> pitti: i partitioned it already was just using partman during the install process to mark which was swap and / and it hung during that
<ScottK> pitti: Thanks for the notify-python sync.  I've been working my way through the packages owned by Debian Python Modules Team to see what I can do to make them syncable and notify-python was next on my list.
<pitti> ScottK: I just filed a bug, I didn't sync it yet
<cjwatson> calc: do you think you could preserve it in a state where that happens so that we can dissect it at the sprint?
<cjwatson> calc: part of the problem is that neither evand nor I can reproduce it locally
<shirish> pitti: could you look up https://bugs.beta.launchpad.net/ubuntu/+source/apport/+bug/124206
<ubotu> Launchpad bug 124206 in apport "apport 0.88 while uploading shows errors" [Undecided,New]  
<calc> cjwatson: wrt the partman or something else?
<cjwatson> calc: partman
<ScottK> pitti: Understand.  You've already saved me the trouble of writing the bug and the trouble of determining if it's syncable.
<calc> cjwatson: i was able to reproduce it after reboot so it may still be reproducible at sprint
<evand> cjwatson: I was able to reproduce it last night
<evand> I think
<evand> bug 122645
<calc> cjwatson: needed to get one of my machines back online so i ended up reinstalling feisty for the time being
<ubotu> Launchpad bug 122645 in ubiquity "manual partitioning hangs indefinitely" [High,Confirmed]  https://launchpad.net/bugs/122645
<cjwatson> evand: ooh, good
* ScottK can move on to nose (working in reverse alphabetical).
<calc> cjwatson: i also have an issue with wpa/ifupdown one of them not working properly even for open APs on gutsy
<calc> cjwatson: i can get an ip address if i run dhclient eth directly but not if using network manager or ifupdown
<cjwatson> calc: that I can't help with, but maybe asac or somebody else will be able to
<calc> cjwatson: haven't been able to track it down to what exactly causes it due to not being able to install gutsy on my laptop yet, heh
<cjwatson> live CD?
<pitti> shirish: will loko in a bit
<calc> cjwatson: yea
<calc> cjwatson: from what i recall it happened on the installed version also
<calc> cjwatson: also happens on amd64 gutsy as well from what i recall
<cjwatson> oh, I meant that a live CD might be enough to track it down
<calc> oh ok yea
<calc> it shows up on the live cd definitely
<shirish> pitti: thanx, I have sent you a pm also, i'll hang here for a while, if you need more info. either pm me or here itself, either is good :)
<cjwatson> assuming you have enough memory (or set up swap) you can build and install packages on the running live CD, which is usually enough
<asac> siretart: sorry ... i currently really don't use much of network-manager ... currently trying to change that
<Hobbsee> shirish: that's already reported, i think
<shirish> Hobbsee: ok cool Hobbsee please mark it duplicate it then, so I can subscribe to the original
<Hobbsee> shirish: btw - people tend to be busy, and he's likely subscribed to all apport bugs, so bringing up $yourpetbug isnt going to get so far
<Hobbsee> shirish: it's filed under synaptic, i think.  it was in -bugs yesterday or so.  look it up.
<shirish> Hobbsee: oh, synaptic? ok 
<pitti> shirish: what Hobbsee said, I'm subscribed to apport bugs and regularly look at them anyway
<Hobbsee> shirish: unless i shoved it to apport
<shirish> pitti: I'm sure of it, I was unsure whether it was a genuine bug or was it something I was doing wrong, Hobbsee just confirmed it :)
<Hobbsee> shirish: if it is, or is not, you'll find out when he happens to go thru the new apport bugs
<ogra> BenC, hey ...
<BenC> ogra: yo
<Hobbsee> like i say, bringing it up in here, when he's usually busy with something else, isnt going to make him drop the something else, and go and fix $yourpetbug.
<ogra> BenC, would it be possible to ship the oss headers in the linux-headers package again, they somehow vanished recently
<Hobbsee> shirish: nor care, particularly much.  particularly teh more you do it.
<shirish> Hobbsee: true. 
<calc> BenC: i was able to determine it is not the ipw3945 driver in gutsy at fault
<pitti> evand: oh, something just occured to me
<calc> BenC: not sure if you saw my discussion with crimsun about it last night
<evand> ok
<pitti> evand: it's gksu vs. sudo, right? Recently I changed sudo to print more detailled password prompts
<evand> Yes, running with sudo works, but gksu does not.
<pitti> evand: that did not break kdesu nor sudo in any way that I tested it with, and it's rather unlikely that it causes ubiquity to hang, but it's worth mentioning at least
<pitti> evand: so maybe it's worth trying the tribe-1 version of sudo
<evand> hrmm, I'll keep that in mind, thanks
<pitti> evand: it would be really curious if that would fix it, but can't hurt to check :) 
<evand> indeed
<cjwatson> I'm sceptical about that as a cause too
<cjwatson> after all it only runs gksu/sudo right at the start
<pitti> at most something like 'gksu checks for output, sees something different, and does not export an important variable" or so
<Hobbsee> i wonder if it happened for kdesu...
<cjwatson> pitti: I suppose that's possible
<Hobbsee> stgraber: ping?
* pitti fires up vmware
<stgraber> Hobbsee: pong
<Hobbsee> stgraber: at the bottom of the iso testing page, hwo hard would it be to have a link to "previous snapshot releases", where you could go back to tribe 1, 2, or whatever, done chronologically down the page (collapsable, i guess), and view the test results from them.  currently, it's either not possible, or i havent figured out how to see the old tests and results.
<stgraber> Hobbsee: oh, looks like our archive page isn't public ... strange it should be
<Hobbsee> stgraber: ah
<Hobbsee> stgraber: i didnt see it even hwen logged in, though
<Hobbsee> stgraber: it's quite possible that i could have missed it - i'm terrible at finding things right in front of me...but i would have thought i'd find something like that
<calc> anyone know of any packages that would have caused my oops in apt-get dist-upgrade that were uploaded to gutsy in the past ~ 2 weeks
<stgraber> Hobbsee: no, it seems that the link is only shown for site admins, I just added to my todolist for Monday, you can still use : https://isotesting.stgraber.org/isotesting/archive/ (but you'll see some weird thing like the checkboxes :))
<calc> i can try tracking it down myself but just wondered if anyone had run across the issue already?
<Hobbsee> stgraber: okay, cool, thanks :)
<BenC> rough update...xchat-gnome started locking up, and then wont start again afterwards...firefox session restore is broken
<BenC> wonder what else I can find :)
<calc> BenC: have you seen the lovely oops during apt-get dist-upgrade?
<BenC> calc: I ran dist-upgrade, didn't see an oops
<calc> BenC: i saw that last night after not upgrading gutsy for a while
<calc> BenC: ah too bad ;)
<BenC> calc: so you were probably running a kernel older than -7?
<Hobbsee> pitti: evand no one seemed to report that on the kde side, so it may be specific to gksudo.  or maybe no one found it.  not sure.
<calc> was running -6 yea, i think i rebooted into -7 and the same thing happened
<persia> BenC: Regarding firefox session restore, try removing .mozilla/firefox/(session)/extensions/extensions.rdf and .mozilla/firefox/(session)/extensions/staged-xpis
<calc> BenC: anything wrong with -6 that would cause that?
<evand> hrm
<BenC> calc: very possible..if it happens with -7, please save and report
<BenC> persia: thanks
* evand starts downloading a kubuntu daily
<calc> BenC: ok
<Hobbsee> evand: i'll try it here now
<Lure> siretart: whay did you add gnome depends back to network-manager?
<Hobbsee> evand: at least, a tribe 2
<evand> thanks Hobbsee 
<Lure> siretart: this will not make Riddell happy (and will make kubuntu cd oversized)
<Hobbsee> Lure: yay, 2 people not happy on that basis :P
<Hobbsee> evand: find me some more ram, kthxbye.
<Hobbsee> :)
<Hobbsee> evand: i've got this strange feeling that ubiquity-kdeui doesnt use either sudo or kdesu on the live cd, but it's allowed to run as root, without requiring a password
<Hobbsee> evand: it neither mentions kdesu or sudo in it's desktop file
<BenC> that mystery is solved, sort of...xchat-gnome blocks on read from the esd socket
<BenC> kill esd and things go back to normal
* pitti purged esound a long time ago
<pitti> right, I wanted to demote that to deskop recommends a long time ago, too
<pitti> no need to kill ubuntu-desktop just for removing insanity
<Hobbsee> evand: it doesnt have X-KDE-SubstituteUID=true either...doesnt even have that line - which something like adept_manager does.
<Hobbsee> evand: i lie.  it's calling with kdesu --nonewdcop
<evand> Hobbsee: it's done by ubiquity itself
<Hobbsee> right, yeah
<Hobbsee> evand: i cant reproduce it on kde in virtualbox
<evand> hrm, ok
<evand> thanks
<Hobbsee> didnt try proper hardware, of course
<pitti> hm, I need to do an experiment for a new apport change, but I need someone who is *not* an ubuntu-core-dev for this
<geser> what do you want tested?
* shirish also listening
<pitti> one is enough, I guess, thanks for the interest :)
<pitti> please install apport-cli as a guinea pig package and add an 'assert False' to /usr/bin/apport-cli, right after "if __name__ == '__main__':" (at the bottom)
<siretart> Lure: I agree that the gnome-dependency is unfortunate. however breaking 3 reverse dependencies (the vpn plugins) isn't nice as well
<pitti> i. e. that's a package where I'm comfortable with dealing with some bug spam and which is easy to control
<Lure> siretart: but breaking kubuntu is not an option ether
<siretart> Lure: perhaps we can split the nm-vpn-properties application to an own binary package. 
<siretart> asac: how do you think about it?
<Lure> siretart: yep, but I think that vpn-properties is supposed to move to n-m-applet in future, that is why it was moved there as a patch 
<siretart> Lure: please don't imply I wanted to break kubuntu
<Lure> by Tonio_ if I recall correctly
<Lure> siretart: I did not want to imply that, sorry for that
<siretart> Tonio_: around?
<Tonio_> siretart: yep
<Lure> pitti: do you recall this discussion about vpn-properties being moved to -applet
<pitti> Lure: vaguely
<siretart> Tonio_: I had the impression that nm-vpn-properties has been moved from -applet to network-manager
<Tonio_> siretart: we discussed with mbiebl and decided to do that way
<Lure> Tonio_: you discussed it with mbiebl or n-m upstream?
<siretart> Tonio_: I didn't find any traces of that there, so I reenabled it in the network-manager source package
<geser> pitti: done, what's next?
<Tonio_> Lure: mbiebl
<Tonio_> siretart: let me check
<pitti> geser: http://people.ubuntu.com/~pitti/tmp/python-apport_0.89_all.deb -> can you please gdebi that?
<siretart> Tonio_: why did nm-vpn-properties get dropped then in gutsy from -applet?
<Lure> siretart: it may have been dropped by recent rework by asac
<Tonio_> siretart: it wasn't in my package afaicr
<pitti> shirish: http://people.ubuntu.com/~pitti/tmp/python-apport_0.89_all.deb -> can you please gdebi that?
<Tonio_> but it has been reworked a lot to fix patches issues which I couldn't handle
<Tonio_> siretart: I need to investigate, gimme a moment
<shirish> pitti: ok will do
<siretart> Lure: it has been missing for more than one week. I was too annoyed about the broken openvpn package so I looked at the source packages and just fixed it
<pitti> shirish, geser: with the new python-apport, please call 'apport-cli' and report the crash as usual
<siretart> Lure: it seems to me that there should be a more visible hint in the source package where nm-vpn-properties is supposed to be
<Lure> siretart: problem is that upstream has left vpn-properties in wrong tar
<Hobbsee> Lure: Tonio_ any idea why knetworkmanager doesnt seem to autoconnect on startup, and hasnt for the past few weeks now?
<Tonio_> Lure: exactly
<Tonio_> Hobbsee: known bug, waiting for a fix :)
<siretart> Lure: I assume you are in contact with upstream to fix that?
<Lure> siretart: mbiebl talked with them and this is supposed to be addressed in next upstream release
<Hobbsee> Tonio_: right.  guess you cant shove them along?
<Tonio_> siretart: to make it simple, the point was that the vpn-prpperties is still in the n-m tarball, not the applet
<siretart> Tonio_: I got that. I reenabled it in network-manager because of lack of better knowledge
<eagles0513875> jw is anyone else have the problem where after they login on a broadband connection they connection doesnt automatically start 
<eagles0513875> once u log in
<eagles0513875> im on the 64bit version of gutsy
<Hobbsee> eagles0513875: ...
<Tonio_> siretart: the problem is that due to shlibsdeps, this was giving gnome dependancies on the n-m package
<Hobbsee> eagles0513875: #ubuntu+1 for a start, and i just answered you.
<Tonio_> which is not good for kubuntu
<Hobbsee> eagles0513875: and the fact that you've just come in and disturbed a whole lot of other conversations, too.
<Tonio_> so we dedided to install it in a hidden directory, then tell to shlibsdeps to ignore it, and patch n-m-applet, so that you could use it while the applet is installed
<eagles0513875> sry i will leave channel
<Hobbsee> Tonio_: sounds...crackful
<Hobbsee> slightly
<Lure> Hobbsee: good observation ;-)
<Tonio_> Hobbsee: no other way if we don't want n-m to ship with 30 megs of gnome deps
<Hobbsee> Tonio_: tru ethat
<Tonio_> siretart: the change probably was lost by esac I guess
<siretart> Tonio_: as said, I got that
<Tonio_> siretart: then n-m-applet pointed to a place where vpn-properties was missing....
<siretart> Tonio_: yes
<siretart> I know
<Tonio_> siretart: so what is the problem ? I mmust say I don't get you now ;)
<siretart> Tonio_: I don't really care where vpn-properties actually is. I just don't want the package to be left broken around just because nobody cares
<siretart> Tonio_: see my recent network-manager uploads from today morning
<Tonio_> siretart: that I understand
<Tonio_> siretart: well I id the package, but I don't use it myself, hard for me to be sure new uploads still work
<Tonio_> siretart: do you still hide it from shlibsdeps ?
<siretart> Tonio_: the network-manager package currently depends on libglib
<Tonio_> hum....
<Tonio_> siretart: isn't that possible to simply switch back to what I did first upload ? it worked afair
<siretart> Tonio_: you mean to drop nm-vpn-properties again? sorry, I don't want to break packages on purpose
<Tonio_> siretart: no, no, no
<Tonio_> siretart: install in not in /usr/bin, then patch the applet, and tell dh_shlibsdeps to ignore it
<Tonio_> siretart: it was working on the initial upload
<crimsun> pitti: ok, thanks.
<siretart> Tonio_: that part got dropped somehow. Feel free to reintroduce it (as long as nm-vpn-properties doesn't get dropped again ;)
<Tonio_> siretart: sure
<Tonio_> siretart: will do that toonight
<Tonio_> siretart: I'll email asac on that point for further maintance of the package
<pitti> geser: nevermind any more, I have the test results; please make sure to "apt-get install python-apport/gutsy" and purge apport-cli (or restore it); thank you
<shirish> siretart: I have pmmed you something, please take a look at it as & when you can. 
* pitti sneaks towards slomo and gives him a big hug
<slomo> hi pitti :)
<Hobbsee> hi slomo 
<slomo> hi Hobbsee 
<asac> Tonio_: pong
<asac> Tonio_: sorry ... still fighting with some wifi setup stuff here ... so unreponsive
<asac> siretart: did you commit your changes to bzr?
<Lure> Tonio_: [17:15]  <asac> Tonio_: sorry ... still fighting with some wifi setup stuff here ... so unreponsive
<shirish> asac: who is responsible for network-manager stuff?
<pitti> asac: run!
<asac> yeah ... i already have the feeling
<Lure> asac: siretart's changes are in bzr
<asac> and her dropped more than just adding vpn?
<pitti> Master dholbach? can you please check whether you got bug mail for #124219?
<Lure> asac: we need old hack from Tonio_ for vpn-properties in order not to pull in gnome depends for kubuntu
<Lure> vpn-properties is supposed to move to -applet in next release to fix this long term
<asac> Lure: can we please make a list of changes needed ... and don't do stuff in a hurry
<dholbach> bug 124219
<ubotu> Launchpad bug 124219 in apport "apport-cli crashed with  IndentationError in CLIUserInterface()()" [Undecided,New]  https://launchpad.net/bugs/124219
<Lure> asac: Tonio_ said that he will write e-mail to you
<pitti> dholbach: it's a test bug for checking LP behaviour of email notifications
<asac> Tonio_: ping
<pitti> dholbach: I just need to know whether anyone from ubuntu-core-dev got bug mail about this
<siretart> asac: sure!
<dholbach> pitti: no, didn't get it yet
<asac> Lure: siretart Tonio_ ... feel free to change things ... but please bring up a private bzr branch and tell me to pull and release changes in future :)
<pitti> dholbach: well, you shouldn't :)
<dholbach> I thought so ;-)
<dholbach> great
<pitti> dholbach: ubuntu-core-dev is sub'ed to that bug through ubuntu-crashes-main
<dholbach> right
<pitti> dholbach: so it seems that the "black hole" team contact address fro u-crashes-main does its job
<asac> Lure: siretart Tonio_  ... at least we can discuss stuff before they get pushed... otherwise we will always end up playing ping pong with network-manager
<pitti> dholbach: cool, thanks! https://wiki.ubuntu.com/CrashReporting, there you go!
* dholbach hugs pitti
* dholbach hugs pitti
<Tonio__> asac: I agree, and btw the changes I've done for the vpn-properties should have been documented in the package
<asac> Tonio__: so is documentation missing now ... or is all fine now ... let me pull latest branch
<Tonio__> asac: the only thing to be done is re-add the changes I've done for the vpn-properties part
<Tonio__> asac: are you there toonight (means 2~3 hours) ?
<Tonio__> asac: i'm at work yet, no way to do that atm
<asac> i will be here at development meeting
<asac> tomorrow i am here as well
<pitti> asac: so, we'll have our discussion tomorrow?
<asac> pitti: maybe we can do it in a few minuts ... depends if i get this wifi working here :)
* pitti throws an ESSID towards asac
<asac> pitti: haha ... i have problems with encryption
<asac> pitti: normal works
<asac> pitti: but i want more :/
<asac> pitti: can i do the testcase for our infamous bug without enc?
<pitti> asac: you don't need wifi for that
<pitti> asac: simple eth is enough
<pitti> asac: in fact it's much easier, since you can unplug/replug
<pitti> the lack of a cable makes this a bit harder for wifi :)
<asac> pitti: ah ... so eth1 and eth0 ?
<asac> pitti: or do i just need one ?
<pitti> asac: either is fine
<shawarma> testing.... bug 12345
<ubotu> Launchpad bug 12345 in isdnutils "isdn does not work, fritz avm (pnp?)" [Medium,Fix released]  https://launchpad.net/bugs/12345
<ogra> BenC, did you get my question from before ? (i think your xchat crashed)
<BenC> ogra: no, I didn't see it
<ogra> BenC, would it be possible to ship the oss headers in the linux-headers package again, they somehow vanished recently
<BenC> ogra: in gutsy?
<ogra> yep
<ogra> i have one thin client with a sis7019 soundchip
<ogra> for these things exist no alsa drivers
<BenC> ogra: Can you file a bug so I or someone else can look into it?
<ogra> i have one oss driver here that works but i need to pull the oss headers out of te linux-source package 
<ogra> indeed
<ogra> so it wasnt on purpose ?
<BenC> ogra: Not by me, but maybe something upstream did
<ogra> well, its in the source tarball
<ogra> just doesnt get packaged into the headers package
<EvanCarroll> can someone confirm a defualt ubuntu install only has that which is listed as a dependency in ubuntu-standard and ubuntu-desktop ?
<Keybuk> EvanCarroll: no
<Keybuk> EvanCarroll: it also has kernels, boot loaders, etc. as appropriate for your architecture
<Kmos> Keybuk: can you look at bug 46657
<ubotu> Launchpad bug 46657 in kdenetwork "Kopete gives error when you're on your own contact list" [Medium,Incomplete]  https://launchpad.net/bugs/46657
<pitti> StevenK: what about asterisk? It's the last reverse dependency (apart from nexuiz-server, which you wanted to get synced)
<pitti> StevenK: oh, and gambas-gb-net-curl and apt, of course
<geser> pitti: he uploaded gambas 1.0.18-1build1 already
<geser> or didn't the upload fix it?
<pitti> geser: ah, then NBS is just out of date, I guess
<pitti> hm, FTBFS on sparc and powerpc
<pitti> ah, that needs a P-a-s change
<Keybuk> Kmos: ?  I don't think I'm a good person to look at that bug
<asac> pitti: if you ask someone about p-a-s change ... can you remind them about flashplugin-nonfree on amd64 as well :)
<asac> ?
<pitti> asac: it needs to be added there?
<asac> amd64 ... yes
<asac> i pinged elmo infinity and send mail .. no answer so far
<pitti> asac: mail sent, you are in CC
* asac hugs pitti
<cjwatson> EvanCarroll: it's also possible for it to have random other hardware-appropriate packages, e.g. mouseemu on Macs - and you forgot about ubuntu-minimal
* pitti hugs dholbach 
<dholbach> pitti: which mail address would you set for ubuntu-main-sponsors then?
<pitti> dholbach: hm, we cannot recycle ubuntu-bugs@
<pitti> it needs a new one, so we'll probably need another 'black hole' address
<dholbach> but people who are in the team and want to have bug mails about that as they're used to?
<dholbach> I didn't want to change the workflow for people who use the teams arleady
<dholbach> that's why I founded the new team
<mjg59> pitti: Hm. Looks like your laptop-mode upload reintroduced the acpi event scripts (sorry for not catching that)
* maswan waves back to simira 
<pitti> dholbach: that's why I think we should mail the team members; we need to do that in either case
<pitti> mjg59: uh; as I said, I could not test it, I just reviewed the merge and it looked reasonable; sorry for that
<dholbach> pitti: I think that an announce of the new team and workflow will be just fine ;-)
<mjg59> Ah, sorry, I thought you'd looked over it rather than just pointing me at the MoM
<mjg59> My fault :(
<mjg59> (Though, like I said, we should drop it - it does insanity)
<pitti> mjg59: I did look over the patch, but since I did not exactly know what it actually does, I didn't notice that this script is a problem
<mjg59> It handles policy inside laptop-mode
<pitti> dholbach: right, I'm fine with mailing the old members and point out the new team, but it still feels wrong to me; your call, though
<dholbach> pitti: I think it only makes sense to re-use ubuntu-main-sponsors and ubuntu-universe-sponsors, if we mail each and every of the team members, explaining the workflow and get a mailing list for the *-main-* team
<geser> pitti: could you please give-back commons-io?
<pitti> dholbach: right; but as I said, we need to mail them all anyway
<dholbach> ok, fine with me... ... ... although it will take a while until we get that mailing list
<pitti> geser: kicked
<geser> pitti: thanks
<Kmos> evand: bug 47238
<ubotu> Launchpad bug 47238 in ubiquity "Bugs with time settings during installation" [Medium,Confirmed]  https://launchpad.net/bugs/47238
<tormod> mjg59: what laptop-mode are you talking about? laptop-mode-tools 1.34-1ubuntu1 ?
<mjg59> Yess
<evand> thanks Kmos 
<tormod> mjg59: I guess I am at fault, since I did the merge. But there was not mentioned in older changelogs that some events scripts were left out. Anyway, what do you think of https://bugs.launchpad.net/ubuntu/+source/laptop-mode-tools/+bug/80980/comments/6 ?
<ubotu> Launchpad bug 80980 in laptop-mode-tools "power management on ipw2200 and ipw3945" [Undecided,New]  
<mjg59> This is why I want to reimplemtn it
<cjwatson> Kmos: at least part of that bug appears to be wrong; see my comment
<mjg59> We have something that manages policy in respones to acpi events - acpid
<mjg59> laptop-mode-tools should control laptop-mode and nothing else
<tormod> mjg59: do you agree with Bart, so we can do it (more like) the upstream way?
<mjg59> tormod: No
<tormod> mjg59: I hope you can discuss it with Bart, so we get sanity in both Ubuntu and Debian.
<Kmos> cjwatson: ok
<mjg59> tormod: As I said, laptop-mode-tools is the wrong place to manage policy
* fabbione stares at 123809
<fabbione> how did system-config-cluster landed on the livecd?
<pitti> fabbione: ??
<pitti> fabbione: it's not in the seeds
<pitti> and no reverse dependency of anything
<fabbione> pitti: see the bug
<fabbione> pitti: he might have installed it manually but i doubt
<pitti> fabbione: well, you can install it in the live system
<fabbione> pitti: do you have an amd64 where you can try to reproduce it? (not now.. sometime tomorrow would be fine)
<pitti> fabbione: yes, I have
<pitti> (my main workstation)
<fabbione> pitti: if you have time.. would you mind ?
<pitti> and vmware
<fabbione> i will test i386
<pitti> fabbione: no, that's fine; I keep the browser tab open to remind me tomorrow
<fabbione> but tomorrow is fine
<fabbione> thanks
<pitti> fabbione: but the traceback is quite clear?
<tormod> mjg59: I found your changelog note "Don't ship acpi scripts (we handle that ourselves)" from 2005... Maybe that should go in a separate patch file instead of all the handpatching.
<fabbione> pitti: yes, but it starts on i386 normal installation here
<pitti> fabbione: I saw quite a number of similar bugs on restricted-manager and such
<pitti> fabbione: either we have a  pretty nasty bug in python-central, or he ran it during an upgrade or so
<pitti> fabbione: I'll try it out tomorrow
<fabbione> pitti: thanks
<Kmos> doko: dpkg has a new version on debian
<fabbione> pitti: from the menu i can't start it at all.. i think the helper should invoke gsudo or something.. and it doesn't.. from console it works fine..
<fabbione> pitti: anyway.. tomorrow.. thanks man
<pitti> fabbione: sleep well
<fabbione> you too
<cjwatson> Kmos: you realise that will be extremely common now we're past Debian import freeze?
<cjwatson> from then to upstream version freeze, new syncs/merges can happen freely but generally only when there's some interesting reason to do so, rather than just "because it's there"
<Kmos> cjwatson: hmm.. i think it's the time to do some merges/syncs
<Kmos> because there are a lot to do
<cjwatson> please re-read what I said
<cjwatson> we are not aiming to get merges/syncs down at this point just for the sake of it
<Kmos> yeah
<Kmos> only for important things
<cjwatson> right, and important changes rather than important packages
<Kmos> things = bugs
<Kmos> I think it'll only freeze for tribe-4
<cjwatson> the relevant freezes are scheduled and visible on GutsyReleaseSchedule
<cjwatson> they aren't necessarily synced to milestone releases
<Kmos> ok :)
<Kmos> sorry
#ubuntu-devel 2007-07-06
<alex-weej> i don't think the rt2x00 ralink drivers work
<alex-weej> at least the rt73usb driver is causing pain for people, it just doesn't associate
<alex-weej> the legacy rt73 driver the same guys provide works, but it's not bundled with ubuntu
<alex-weej> what's the solution here
<alex-weej> ?
<alex-weej> in fact, they claim that the rt2x00 driver is still beta
<alex-weej> every "legacy" driver they provide EXCEPT rt73 is bundled
<ScottK> alex-weej: Most of the core devs work on European time, so this isn't a great time.  I'd suggest discuss it in #ubuntu+1.
<alex-weej> ScottK: should i use ubuntu-devel-discuss?
<pygi> doko, poke?
<ScottK> alex-weej: That would be another good option.  That or file a bug.  #ubuntu-kernel might be another place (but probably not right now).  All in all, mailing list doesn't sound bad.
<alex-weej> ScottK: i'll attack it tomorrow
<mjg59> ogra: Why does education-laptop recommend laptop-mode-tools?
<AlinuxOS> doko, hello.
<bdmurray> Kmos: how is 107716 fix released?
<robby> hi all
<wolfeon> I really need to test out python-fam like a good little user.
<ScottK> wolfeon: Yes.  You do.
<wolfeon> ScottK: I know =]  I'll test it this afternoon while I develop.
<unfo> hi all, I wish Ubuntu had a graphical bootloader like GAG with mouse support.  Should I file a bug?
<Hobbsee> create a spec for it, more like
<Hobbsee> however, i thought they were working towards grub 2
<LaserJock> unfo: that's not really a bug, that's a feature request
<unfo> Hobbsee, is grub 2 graphical?  That'd be ideal: a powerful command line (lets you do commands like find /vmlinuz) and graphics too.
<Hobbsee> look up the page.  i beleive so, last i checked
<unfo> You don't really need graphics, just a text mode mouse would be helpful.
<evand> iirc, no Grub 2 for the time being.
<evand> why would you need a mouse in a boot loader?
<Hobbsee> evand!
<evand> Hobbsee!
<Hobbsee> evand: did you get anywhere with that bug?
<fabbione> morning guys
<evand> morning fabbione 
<Hobbsee> morning fabbione!
<fabbione> does anybody know if the old Feisty Herd test results are stored somewhere?
<evand> Hobbsee: sort of.  It's definitely gksu interaction, but oddly enough it still happens with the feisty version of gksu, which confuses me to no end.
<fabbione> it looks like i can't dig all of them out of the wiki
<fabbione> and then we moved to the iso tracker
<Hobbsee> evand: that's...weird.
<unfo> evand, i don't need it but, for example, IIRC Macintosh dual-boot has it and it makes people feel it's more user-friendly.
<tepsipakki> evand: is grub2 still too immature?
<fabbione> (that requires admins for historical
<ajmitch> fabbione: what page names on the wiki?
<evand> tepsipakki: that was my understanding.  I had to miss the grub2 spec session for something, so there's probably a better source of information on this one.
* ajmitch might still have the diffs in mail
<fabbione> ajmitch: it was Testing*
<ajmitch> right, I'd need to reconstruct a page from diffs
<fabbione> ajmitch: do you have them?
<ajmitch> looks like I do
<fabbione> ajmitch: could you just tar up those messages and send them to me+
<fabbione> it's easier for me to grep in there than for you to rebuild pages
<ajmitch> sure
<fabbione> thanks
<ajmitch> just changes from this year?
<fabbione> for all of feisty if you have them
<ajmitch> http://ajmitch.net.nz/~ajmitch/feisty-testing.mbox.bz2
<ajmitch> mbox file with what is hopefully enough
<fabbione> thanks
<Hobbsee> for i in 'annoying people'; do hammer.splat($i); done
* pygi eats Hobbsee 
* Hobbsee splats pygi too, then
<pygi> Hobbsee, o no, you won't!
<Hobbsee> morning pitti!
<StevenK> Hi pitti!
* Hobbsee notes that pitti isnt contained in $i
<pygi> morning pitti, dholbach 
<Hobbsee> morning dholbach!
<Hobbsee> fortunately, dholbach isnt in $i either
<dholbach> good morning
<dholbach> hey pygi, hey pi
<dholbach> tti
<dholbach> hey Hobbsee :)
<pitti> Good morning
<pitti> Hobbsee: $I?
<Hobbsee> [16:43]  <Hobbsee> for i in 'annoying people'; do hammer.splat($i); done
<pitti> hey dholbach 
<pitti> oh, *phew* :)
<Hobbsee> i must be turning slowly geekier, when i'm expressing frustration via bash loops...
<pitti> Hobbsee: you just need to fix the syntax of the set now :)
<StevenK> pitti: Can you give-back asterisk and boinc on ia64?
<Hobbsee> pitti: yeah, well.  what is it?  :P
<StevenK> for i in $annoying_people ?
<Hobbsee> hammer.splat(i) is a c++ ism, i assume
<Hobbsee> or at least, i've used it in c++ before
<StevenK> Yup.
* Mithrandir waves
<Hobbsee> morning Mithrandir!
<pitti> hi Mithrandir 
<StevenK> hammer --splat $i
* Hobbsee splats Mithrandir with the large hammer anyway, even though he's not part of $i
<Mithrandir> yh!
<Mithrandir> no splatting.
<Mithrandir> at least not before breakfast.
* pygi takes away the hammer from Hobbsee 
<pygi> no splatting kid
<pitti> StevenK: done
<pygi> ^_^
<Hobbsee> pygi: splatting is allowed.  and it's my hammer!
<Hobbsee> StevenK: oh, yeah, right.
<pygi> Hobbsee, everything will be all right ... now calm ...
<StevenK> pitti: Thanks. Can you convince you to look at the nexuiz sync, too?
<StevenK> Can I, even
* StevenK needs more tea
<pitti> StevenK: I just logged into drescher to do syncs :)
<StevenK> pitti: :-)
<Mithrandir> the list didn't look too bad as of last night
<pitti> Mithrandir: ah, did you that big sync wave that hit -changes@ last night? :)
<pitti> no, just 11 ATM
<Mithrandir> pitti: did I what?
<Mithrandir> I didn't do the syncs, no
<dholbach> pitti: I think for now I'll request the ubuntu-main-sponsors@ list and will just assign bugs to people without using any special team
<pitti> dholbach: I think we should also set auto-expiry on ubuntu-{main,universe}-sponsors and mail the members about the new approach and your wiki page; WDYT?
<dholbach> pitti: which interval do you think about?
<pitti> Mithrandir: hm, weird; neither did I, and I wasn't even aware of so many sync bugs
<dholbach> 3 months?
<Mithrandir> pitti: maybe Colin or Seb did them
<pitti> Mithrandir: it almost looked like a sync-source -a with forgotten NOMAILS
<pitti> dholbach: 3 months sounds like a good compromise between annoying resubscription and cleansing to me
<dholbach> ok good
<dholbach> Hobbsee: can you do that for ubuntu-universe-sponsors too?
<Hobbsee> dholbach: ah yes, i was going to discuss that stuff with you
<dholbach> Hobbsee: we had a discussion about the team structure yesterday and we're likely to drop ubuntu-code-reviewers
<Hobbsee> yeah, is aw the meeting
<Hobbsee> makes me wish i was coming to teh distro sprint :P
<dholbach> I'll file an RT ticket to get ubuntu-main-sponsors@lists.u.c so people don't get bug reports if they don't want to
<dholbach> we'll soon have more people doing reviews and reviews that lie around for weeks will get assigned to team members, trying to balance the load
<dholbach> people who don't want to do reviews any more can simply deactivate their membership
<Hobbsee> the problem with i have with this, is that it works fro canonical employees, but it doesnt work for volunteers so well.
<fabbione> dholbach: i assume that when we sponsor uploads we keep the name of the person that did the change, right?
<dholbach> but I expect more distro team people to help out there
<dholbach> fabbione: yes, using -k<keyid> would be nice
<fabbione> dholbach: and perhaps add a: Sponsored by: in debian/changelog?
<dholbach> fabbione: shall I add a note about that to UbuntuDevelopment/CodeReviews?
<Hobbsee> u-u-s already has a ML, incidently
<dholbach> fabbione: you can do that if you like
<dholbach> Hobbsee: yeah and that's great
<dholbach> Hobbsee: we just need it for main
<Hobbsee> cant help you there :)
<fabbione> dholbach: i did that, but then realized that we have no way to make sure (quickly) who uploaded what when mom time comes
<Hobbsee> i'm not the head of it, and i dont have special links to RT - it took so long to get ours that i asked siretart to get us one on tiber before.
<dholbach> fabbione: I should think that MoM will care about the name in debian/changelog - no?
<fabbione> dholbach: so at the next merge session we will have perhaps a man page fix for a package and the name of somebody that's not yet able to merge or not interested at all in doing that
<dholbach> Hobbsee: don't worry - we can do without it too
<Hobbsee> mom doesnt care about the sponsoring name, no
<fabbione> dholbach: right, that's exactly why I am suggesting to add a sponsored by and perhaps teach MOM to look at it in the last changelog entry
<fabbione> dholbach: or another XCSB- entry but that would be overkilling when merging debian/control
<Hobbsee> dholbach: the reason those bugs sit, i suspect, si because people dont know a lot about those main packages, and dont want ot break something that's supported, etc
<dholbach> fabbione: I have confidence that a lot of people we sponsor will be part of ubuntu-dev at that time around :-)
<persia> fabbione: That means the sponsor has to change the changelog, which should generate something new with dch.  How about only in .changes?
<Hobbsee> so i'm not sure that randomly assigning things is the best way to go - because people will end up just uploading what they dont understand
<dholbach> Hobbsee: that's why some distro team people will take up the slack :)
<dholbach> Hobbsee: it will be no problem to swap reviews
<Hobbsee> well, true - but i'm not sure that you can relate hwa tyou want to do for the distro team, and use the same methods for the community
<dholbach> Hobbsee: it's a measure to make sure that stuff gets done
<fabbione> dholbach: i see what you mean.. let's hope for the best :)
<dholbach> Hobbsee: I'm happy to leave the volunteers out of that process
<dholbach> fabbione: yeah :)
<Hobbsee> ie, me going in and saying "you must do these reviews by this date" will invariably get the response of "too bad, i'm a volunteer"  "i'll do what i can"  "what right to do you have to tell me what to do" etc
<dholbach> fabbione: I'll add the note about -k though
<Hobbsee> and some that will do it
<Hobbsee> attempting to force them usually isnt the best way to go
<dholbach> Hobbsee: as I said...
<pitti> fabbione: uploader> that's the .dsc signer
<dholbach> Hobbsee: I'm happy to leave them out
<Hobbsee> and from what i'm getting so far - that seems to be what you're saying?
<fabbione> dholbach: yeah i used it automatically because it's not the first sponsor, might be a good reminder for others
<dholbach> fabbione: alrighty
<fabbione> pitti: yes, that requires mom to have knowledge of gpg and other few things
<Hobbsee> dholbach: right, then on that basis, what do you want me to do?
<Hobbsee> dholbach: and wha'ts the scope of this?  just main, or universe sponsors as well?
<dholbach> Hobbsee: when I announce it, I'll ask for comments and people can ping me, if they would like to get a review assigned or not
<pitti> fabbione: at least this seems much easier to implement than asking every sponsor to modify the package IMHO
<dholbach> Hobbsee: I merely wanted you to set the expiry time of the universe team to 90 days
<dholbach> Hobbsee: so we can make sure that people stay active or leave the team
<Hobbsee> dholbach: ah right
<dholbach> :-)
<fabbione> pitti: sure. i don't really care about how but that there is actually a reference
<dholbach> the team will take care of ubuntu-{universe,main}-sponsors + fix committed needs-packaging bugs
<Hobbsee> right, so this is REVU stuff too.
<pitti> fabbione: I agree, that would be nice
<fabbione> dholbach, pitti: should we make this a point for next week sprint?
<dholbach> Hobbsee: yeah, but we'll keep everything in bug reports - we have too many people who just don't want to use REVU or don't have an account
<Hobbsee> dholbach: true that
<fabbione> i have no mom access.. so no idea how easy it is to implement
<dholbach> fabbione: sounds good
<pitti> fabbione: sure, let's
* fabbione does
<fabbione> done
<fabbione> stgraber: ping?
<Hobbsee> dholbach: seems weird that the distro team would now have ot be involved in sponsoring, etc.
<Hobbsee> dholbach: is this now what happens, if the community fails?
<persia> Is there a posted spec for the changes?  I missed the beginning of the conversation, and am quite interested.
<dholbach> Hobbsee: I expect us to have many more contributors soon and it's good if the distro team helps out with reviews
<fabbione> Hobbsee: no, it's a way to encourage community to provide more patches and fixes.
<Hobbsee> dholbach: indeed.
<dholbach> http://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews
<dholbach> persia: ^
<Hobbsee> persia: was in this morning's meeting, too
<dholbach> persia: we're just kicking it off and I'll announce it once all the bits have come together
* persia should start attending development team meetings
<persia> Right.  I don't think we need more team (at least for universe), but just more process.  For universe, we've gotten the queue down to around 12 hours for over 90% of the bugs, with many active contributors.
* Hobbsee thinks on this some more
<Hobbsee> persia: it's the main that seems to be the problem
<Hobbsee> and REVU stuff
<persia> Ah.  For main, assignment might work.  I'd not like to see any official action towards U-U-S, as it's currently working fairly well (although we need more work for REVU).
<Hobbsee> although, that will be useful for SRU procedures, which a fair few people, including myself, are avoiding
* persia goes to clean up the "Preparing New Packages" section of MOTU//Contributing to define a sane process
<persia> Hobbsee: True that, but I think an SRU team would be more useful than a sponsors team to handle that.
<pitti> fabbione: bug #123809 updated
<ubotu> Launchpad bug 123809 in system-config-cluster "system-config-cluster.py crashed with ImportError in <module>()" [Undecided,Incomplete]  https://launchpad.net/bugs/123809
<fabbione> pitti: cheers
<fabbione> pitti: right.. do you know how can I fix the .desktop file or where to look for it?
<Hobbsee> persia: which the distro team can be a part of, of course
<persia> Hobbsee: Absolutely.
<pitti> fabbione: look at /usr/share/applications/users.desktop for an example
<fabbione> pitti: cool thanks
<pitti> fabbione: in particular, "Exec=gksu foo"
<pitti> fabbione: and "X-KDE-SubstituteUID=true"
<fabbione> roger that Sir!
<fabbione> :)
<pitti> fabbione: (yes, don't complain about KDE, hysterical raisins :) )
<fabbione> pitti: this is a gtk app... but well whaever :)
<pitti> fabbione: KDE defined the field first, so we had the choice of either introducing a second one and change KDE, or change it upstream everywhere, or just use it as it was; the latter was easiest :)
<StevenK> pitti: Right, asterisk and boinc sucessfully built on ia64, nexuiz will sort itself out with a few publisher runs, and Hobbsee will fix apt when she uploads it. Which leaves one package left for curl ... openoffice.org
<pitti> StevenK: I talked to calc yesterday, he'll see to doing a new upload (and fix some other things, too)
<fabbione> pitti: ehehhe
<persia> StevenK: nexuiz is the sync, or is there an ubuntu2?
<pitti> persia: just synced
<StevenK> persia: The former.
<persia> pitti: Ah.  mail lag delay :)  Thanks.
<Hobbsee> dholbach: i'm slightly hesitant to set the 90 days without there being an annoucement out about it, though
<Hobbsee> depending on whether it'll be 90 days from when tehy applied, or 90 days from when i set it
<pitti> Hobbsee: <pitti> dholbach: I think we should also set auto-expiry on ubuntu-{main,universe}-sponsors and mail the members about the new approach and your wiki page; WDYT?
<StevenK> pitti: Well, this means that we can kill libcurl4{,-openssl} tonight, and libcurl4-gnutls a bit later, and more importantly both of us can stop caring about the damn thing. :-)
<pitti> heh, cruel, but effective: file a bug against that team, so all members will get mail, and announce it there
<Hobbsee> pitti: yeah...i'm still thinking on that one.
<Hobbsee> there's a ML
<pitti> StevenK: yay :) then we can turn our attention towards the other outstanding transitions :)
<Hobbsee> people  died when all the bugs were getting sent to them
<StevenK> pitti: Yup.
<fabbione> there.. upload fixed
<StevenK> pitti: FLAC is a *pain*.
<fabbione> meh
<fabbione> fix uploaded
<pitti> StevenK: indeed; Debian must have done it as well, though, I figure?
<StevenK> I'm not certain.
<StevenK> I was pondering filing a bug asking for the removal of 21 apache 1 modules.
<dholbach> pitti: yes, we should do that
<pitti> StevenK: please don't open 21 tasks for it, though
<StevenK> pitti: Wasn't planning on. :-)
<pitti> StevenK: although that would be technically correct, it's a pain for you to open and a pain for me to close :)
<pitti> StevenK: well, the last one of that type had :)
<StevenK> pitti: It's not a pain to open ... It's a for loop and gpg-agent. :-D
<Hobbsee> persia: where's your docs about u-u-s, again?
<Hobbsee> oh, found it
<StevenK> pitti: So, no trouble, although I suspect I'd end up in a little. :-)
<persia> Hobbsee: https://MOTU/Contributing and https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue (two different viewpoints)
<Hobbsee> dholbach: done as requested
<dholbach> Hobbsee: thanks a lot
<Hobbsee> dholbach: no problem
* Hobbsee continues to fight apt
<Hobbsee> i thought this thing was supposed to build...
<pitti> Hobbsee: it doesn't?
<Hobbsee> pitti: not the version in bzr, with my changes.
<fabbione> HMMMMMM
<Hobbsee> http://rafb.net/p/4Nbkqp95.html
<pitti> Hobbsee: you mean the no-change rebuild you uploaded for StevenK?
* Hobbsee is contemplating committing the non-working code to bzr, but would really like to test it doenst break teh world
<Hobbsee> pitti: he uploaded that.  i added the automake into this lot, which means it only fails to build later.
<Hobbsee> which is what his failed with
<pitti> right, I just saw the build log
* Hobbsee has no reason to upload StevenK's stuff, he was a core dev before me :P
<Hobbsee> right, yes.  that's my local build here, with the bzr + stevenk's rebuild changelog entry + my changes
<pitti> ah, ISTR that Steve mentioned something like 'after Hobbsee uploaded apt...'
<Hobbsee> and my changes shouldnt be having anything to deal with that
<StevenK> pitti: It should be uploads, sorry
<Hobbsee> yeah.  i think that was "after Hobbsee uploads apt" - ie, future tense
<Hobbsee> or should have been
<pitti> StevenK: aah
<Hobbsee> seeing as i wasnt about to upload yet another version taht didnt build.
<Chipzz> Hobbsee: regarding unfo's question about a graphical grub, you could have also answered the following: dapper (and I think edgy) had a patch for a graphical grub, though without mouse support and you had to enable it manually; also, you have to put grub on hold since that patch got dropped later. ;)
* StevenK stamps himself with "Should have test-built apt"
<Hobbsee> Chipzz: ahhh
<Hobbsee> awww
* Hobbsee hugs StevenK 
<Hobbsee> StevenK: just remember what Mithrandir said yesterday
<Hobbsee> or the day before.  whichever it was
<StevenK> Heh
<Chipzz> Hobbsee: as a matter of fact, I still *have* a graphical grub on 2 of my boxes
* Hobbsee had grub with a different splash screen before
<Chipzz> Hobbsee: the reason it got dropped was that it didn't work with laptop widescreens iirc
<Hobbsee> ahh
<Hobbsee> works OK here, iirc.  but whatever
<Chipzz> ;)
<persia> Hobbsee: It requires different special settings for each type of laptop.
<Hobbsee> ahhh
<persia> (rather, each general class of laptop)
<Mithrandir> persia: or rather, it just plain didn't work on some graphics cards, and well, not giving people a menu they can see is bad.
<persia> Mithrandir: Really?  That's even worse.
<Hobbsee> wow, lots of new pot files.
<Chipzz> the version of grub I have installed on this laptop (with graphical splash) is 0.97-11ubuntu14, which is from edgy
<Chipzz> Mithrandir: worse, it failed to boot at all with laptops that didn't support it iirc
<Chipzz> which is why it got dropped in the first place
<Mithrandir> I think we can agree it had a multitude of failure modes, none of which were pretty
<Chipzz> hrrrrm, that patch has been in debian grub since about warty :P
<Mithrandir> it's in the package, it's just not enabled by default?
<Hobbsee> pitti: shoved my version to bzr, if you were interested in having a look, at some point
<RAOF> I sent bug #123664 upstream, and its now got a patch committed which will be in g-p-m 2.19.6.  Should I attach a debdiff with upstream's patch to that bug, or wait for the new g-p-m?
<ubotu> Launchpad bug 123664 in gnome-power-manager "Should not count time suspended in battery profile" [Undecided,Confirmed]  https://launchpad.net/bugs/123664
<stgraber> fabbione: pong
<fabbione> stgraber: hey
<fabbione> stgraber: do you have 2 seconds?
<stgraber> sure
<seb128> pitti: is the network-manager maintained in bzr?
<fabbione> offtopic question: does anybody know of a good man page editor?
<fabbione> stgraber: see /msg please
<pitti> seb128: yes
<seb128> bah
<pitti> seb128: https://code.launchpad.net/~ubuntu-core-dev/network-manager/ubuntu.0.6.x
<seb128> pitti: danke
<dholbach> fabbione: I always wrote them in docbook and converted them in the build target - sorry that's the best I can offer
<pitti> POD is nice, too
<pitti> but usually I just write them manually
<cjwatson> fabbione: I remember looking at gmanedit once and it didn't seem to be entirely hopeless
<cjwatson> but being groff maintainer I obviously write them by hand, so I'm not the best judge
<fabbione> thanks guys
<jml> editing by hand isn't too hard
<cjwatson> I generally recommend people use either mdoc or pod; I find docbook a bit too verbose, but each to their own
<Mithrandir> groff isn't horrible to write by hand either
<cjwatson> and mdoc is better at dispelling the myth that *roff is a purely physical markup language than the traditional man format is
<realist> docbook ftw :-)
<StevenK> Yes, but docbook is *dreadful* to write by hand.
<pitti> seb128: just to confirm, you should be able to see https://bugs.launchpad.net/ubuntu/+source/apport/+bug/124352; right?
<pitti> <ubotu> Error: This bug is private
<pitti> yeah, yeah
<seb128> pitti: yes, work fine
<pitti> seb128: thanks
<seb128> np
<Hobbsee> pitti: erm, should i be able to see that?
<pitti> Hobbsee: yes
<Hobbsee> right
<pitti> Hobbsee: all core devs
<Hobbsee> just checking if it was a canonical only thing or something
<Hobbsee> !ping
<ubotu> pong
<Hobbsee> !ping
<Hobbsee> !ping
<seb128> hey Hobbsee
<pygi> Hobbsee, don't abuse bot
<Hobbsee> hi seb128 
<Hobbsee> pygi: attempting to see if i'm still connected to the netwrork
<pygi> you are
<pygi> :)
<Hobbsee> good
<Mithrandir> asac: middlemouse.contentLoadURL got flipped from true to false for me here; any idea why?
<Hobbsee> apparently fn != alt
<Hobbsee> so fn+f2 will not bring up the run dialog, it will just toggle the kill switch on my wireless.
<asac> Mithrandir: yes ... every tweak got dropped ....
<asac> Mithrandir: intentionally ... install ubufox
<Mithrandir> asac: uh, you dropped all my personal settings?
<asac> he?
<persia> asac: installing ubufox doesn't fix everything.
<asac> Mithrandir: no ... personal settings should be still there
<Mithrandir> asac: well, they're not.
<cjwatson> asac: shouldn't our firefox recommend ubufox?
<asac> it does
<cjwatson> oh, it does
<asac> and it will go to ubuntu-desktop
<pitti> won't be installed by default, though
<cjwatson> duh, sorry, apt-cache's double output when you aren't up to date confuses me
<pitti> ah
<Hobbsee> cjwatson: apt only does recommends by default for metapackages though, it seem
<Hobbsee> s
<cjwatson> can we get that into the seeds now?
<cjwatson> Hobbsee: yes
<Mithrandir> asac: it's just middlemouse.contentLoadURL which got dropped for me
<Mithrandir> Hobbsee: apt-get only does that, aptitude does for all packages
<Mithrandir> iirc
<cjwatson> should be written as * (ubufox) since firefox is also a recommends
<Hobbsee> Mithrandir: true.  but i dislike aptitude
<asac> have you installed ubufox? ... isn't middlemouse.contentLoadURL a tweak we previously carried?
<Mithrandir> asac: oh, and I have ubufox installed.
<asac> hmm
<Mithrandir> asac: yes, we previously carried it, but I changed it in my profile.
<asac> actually it should not reset your profile settings
<cjwatson> asac: you should be able to commit to the seeds, though I don't remember if you've done so before
<Mithrandir> asac: the change in my profile got dropped.
<asac> Mithrandir: any other change got dropped?
<Hobbsee> asac: you broke it!
<asac> cjwatson: i haven't done that before
<Mithrandir> asac: not that I can see, and most of my changes seem to be there.
<cjwatson> asac: bzr checkout sftp://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.gutsy/
<Mithrandir> asac: (I don't have a list in my head of all the tweaks I have applied, sorry. :-)
<Hobbsee> heh, i was about to offer to do it
<asac> Mithrandir: do you have  backup of your profile (from a day or two ago)?
<Mithrandir> asac: actually, I do.
<Mithrandir> let me find it
<asac> cjwatson: i have to submit a main inclusion report first, right?
<asac> s/report/request/
<cjwatson> if it's not in main already, yes
<cjwatson> though it's probably fairly trivial as it's logically split out from firefox
<cjwatson> in fact, I'm happy to just promote it
<asac> yes ... let me do that main inclusion thing first ... anyway I look at desktop in the ubuntu.gutsy seeds branch
<cjwatson> promoted, don't bother :)
<asac> is that the file that I need to edit?
<cjwatson> yes
<asac> cjwatson: rock!
<asac> hmmm the syntax doesn't look like xml ;)
<cjwatson> it, er, isn't ;-)
<cjwatson> it was originally on the wiki, as you can probably tell from the format
<asac> is that some standard format or did we do a new parser for that?
<asac> ah
<asac> ok
<cjwatson> the parser was hand-written
<cjwatson> though is not exactly complicated
<asac> so do i add this to the end of gnome desktop apps?
<asac> oh probably sorted
<asac> why are some things in brackets?
<Mithrandir> recommends
<Hobbsee> asac: they're recommends
<asac> ah ok ... then this is the way to go
<asac> thanks
<cjwatson> asac: I'd stick it just after firefox
<asac> ok
<cjwatson> there's no requirement for lexical sorting
<dholbach> I'm just reviewing the main sponsors queue, Tormod Volden merged grub from Debian - who would be best to check the merge?
<pitti> asac: NB that you should merge this change to the derivatives who ship ffox as well, such as edubuntu and maybe xubuntu (I didn't check that one)
<cjwatson> the format is very loosely documented in germinate(1), although that doesn't mention recommends
<cjwatson> dholbach: hmm, I hate to say it but probably me
<dholbach> cjwatson: is it ok, if I assign that bug to you?
<cjwatson> dholbach: yeah
<Hobbsee> cjwatson: delegation101: FAIL.
<cjwatson> mm, hence "hate to say it"
<dholbach> I just wanted to avoid getting beaten up at the distro sprint :)
<asac> pitti: what do you mean with merge ... should I just add that to their seeds list?
<asac> pitti: ah ... they probably have there own bzr branch 
<pitti> asac: right, but by merging the ubuntu.gutsy changes to edubuntu.gutsy and so on
<pitti> asac: right
<cjwatson> that's not urgently necessay
<cjwatson> necessary
<cjwatson> particularly not if this is the first time you've touched the seeds :)
<asac> pitti: hmm ... maybe this should be done by people that maintain those distros? ... ogra ?
<pitti> asac: fine, you don't need to do it now, but I wanted to point out their existence :)
<ogra> asac, i'll do that, thanks for the ping
<asac> who is xubuntu lead btw?
<pygi> jani monoses
<dholbach> asac: janimo, gpocentek and mr_pouit work on it
<asac> gpocentek: mr_pouit  ... i extended gutsy seeds by ubufox ... you probably want to merge that change from bzr
<asac> ok ... i committed the new seeds ... when will the result become visible?
<cjwatson> asac: you mean in ubuntu-meta dependencies?
<pitti> asac: if you change the desktop, minimal, or standard seeds, you need to rebuild the ubuntu-meta package
<pitti> asac: I'll walk you through it or can do it myself, depending on whether you want to learn it
<cjwatson> asac: grab ubuntu-meta, run ./update, fix the version in debian/changelog (by default, you get ubuntu1, whereas it should be native version), and upload
<pitti> cjwatson: btw, any chance that germinate-update-metapackage could call dch with -iU?
<asac> cjwatson: ok ... will do
<cjwatson> pitti: I was waiting until I figured out how to detect whether the -U option was present, since it isn't in Debian
<cjwatson> dch --help | grep -- -U should be sufficient though
<Hobbsee> cjwatson: okay, in more "hate to say it" news, could you be persuaded to sync https://launchpad.net/bugs/124363 - it's got to go thru binary NEW, and we need it for the digikam  & kipi syncs.  https://launchpad.net/bugs/124364 and <digikam sync still coming>
<pitti> dch --help|grep -q -- -U?
<ubotu> Launchpad bug 124363 in libkdcraw "sync libkdcraw 0.1.1-2 from debian/unstable" [Undecided,Confirmed]  
<pitti> cjwatson: heh :)
<Hobbsee> cjwatson: well, were you planning to push that change back to debian a nyway?
<cjwatson> Hobbsee: germinate is synced between Debian and Ubuntu right now
<Hobbsee> cjwatson: ahh.  didnt check that
<cjwatson> Hobbsee: syncs -> some other archive admin
<Hobbsee> cjwatson: okay
<cjwatson> preferably
<pitti> Hobbsee: my duty shift today
<Hobbsee> cjwatson: no problem
<Hobbsee> pitti: the real problem is the binary NEW'ing, as we'd like to see it before tribe 3
<Hobbsee> cjwatson: apologies for attempting to give you more work, then :)
<pitti> Hobbsee: I can do that as well, of course
<Hobbsee> pitti: true, but can doesnt necessarily mean "will"
<pitti> Hobbsee: I already finished syncs today, so I'll open that bug in ffox, but I didn't get to NEW yet; will do a bit later
<Hobbsee> pitti: no problem :)
<Hobbsee> it's not critical
<asac> Mithrandir: would be really great if you could confirm whether your setting gets reset by just upgrading firefox ... or by installing ubufox ... do you still have previous ffox package in your cache?
<pitti> Hobbsee: synced
<cjwatson> pitti: done in bzr
<Hobbsee> pitti: thanks a lot
<Mithrandir> asac: if not, I can get it from LP
<asac> Mithrandir: hmmm where are those published/hidden?
<asac> i just find links to sources ... no binaries
<asac> https://launchpad.net/ubuntu/+source/firefox/2.0.0.4+2-0ubuntu2
<pitti> Hobbsee: I let the stuff build now and thus it'll be in NEW once I turn my attention towards it
<Hobbsee> pitti: excellent, thanks :)
<persia> asac: click on "gutsy" in the release subsection
<pitti> yay, all my tests for https://wiki.ubuntu.com/CrashReporting are successful; I can flip the switch now :)
<keescook> is there a command to recalculate the "@@" lines of a patch if I forgot to change them when editing the contents of patch?  :P
<pitti> keescook: maybe editdiff it, do a trivial change, and have it fix the hunks for you?
<keescook> pitti: ah-ha!  editdiff!
<pitti> keescook: recountdiff claims to do this as well, but contrary to editdiff I never used it, so YMMV
<keescook> yeah
* Hobbsee drools
<Hobbsee> why couldnt have someone mentioned that a year ago?
<pitti> Hobbsee: I'm sure that the patchutils description did that a year ago :)
<keescook> \o/  worked
<Hobbsee> pitti: then perhaps i should read it.
<pitti> Hobbsee: it has some real live-safers
<ion_> TimeTravel.travel(1.year.ago) { system "mail hobbsee <message" }
<Hobbsee> haha
<ion_> The TimeTravel implementation: http://johan.kiviniemi.name/stuff/ruby/acme/timetravel
<wolfeon> ruby++
<wolfeon> oh darn it, I forgot to test python-fam :)
<shawarma> pitti: I'm looking at https://bugs.launchpad.net/ubuntu/+source/sysklogd/+bug/19889 again... Is there anything more I should be doing? (other than poking the archive admins, of course :)   )
<ubotu> Launchpad bug 19889 in sysklogd "sysklogd: Large file support is broken in dapper" [Medium,Fix committed]  
<pitti> shawarma: erk, I wonder why that doesn't appear on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=verification-done
<pitti> shawarma: that's the list I usually use
<pitti> shawarma: I'll handle it, thanks for the poke
<shawarma> pitti: np
<pitti> shawarma: done
<shawarma> \o/
<pitti> dholbach: hm, https://wiki.ubuntu.com/Bugs/HowToTriage seems to be the most appropriate place to add a stanza about how to handle apport crash bugs; WDYT?
* keescook looks around for mvo
<pitti> keescook: on holiday
<keescook> okay; I thought I remembered that, but thought I'd check.  :)
<keescook> I'm curious if there is a common response for "zomg _cache->open() failed" bugs
<Mithrandir> keescook: gslice thingies?
<Mithrandir> oh, or no, that's something else
* persia wonders if linking to Debian removal bugs would be preferred by archive admins reviewing Ubuntu removal bugs
<cjwatson> I have found it useful in the past
<persia> cjwatson: Thanks for the feedback.  I'll go update my bugs
<seb128> persia: I usually look for them in the Debian PTS, so having a link to the bug would be nice yes
<luisbg> when is the next community council meeting?
<pygi> anyone saw mvo lately?
<cjwatson> 11:25  * keescook looks around for mvo
<cjwatson> 11:25 <pitti> keescook: on holiday
<pygi> cjwatson, o, didn't knew that
<pygi> cjwatson, he should have told me that :P
<pygi> cjwatson, thanks ^_^
<dholbach> pitti: yes, I think so
<pitti> dholbach: thanks; I did so (see my u-d-a@ mail)
<dholbach> cool
<Lure> any archive-admin around: can you give libkdcraw through binary NEW (to resolve build depends)?
<seb128> Lure:done
<Lure> seb128: thanks a lot!
<seb128> no problem
<glatzor> hello, is there anybody with a Belinea monitor? I would need an edid.
<persia> Just to confirm my understanding of the phases of the devlopment cycle: is it the case that between DebianImportFreeze and UpstreamVersionFreeze, we're focused on stabilization and ensuring that the featureset we have is the featureset we wish to ship, or should we still be pulling all the new upstreams we can find until UpstreamVersionFreeze, at which point we would then focus on stabilization, etc.
<cjwatson> persia: you should feel free to pull new upstreams, but generally that should be because it's needed for something (not necessarily stabilisation, could be a shiny new feature) rather than because it's there
<cjwatson> persia: the reason for the split is to reduce the time that we spend essentially spinning wheels doing syncs and merges
<persia> cjwatson: That's what I thought.  Thanks for the confirmation.
<persia> cjwatson: Right.  So syncs & merges are pre-DIF, feature set development is DIF - UVF, and polish is port-UVF?
<persia> s/port/post/
<cjwatson> tracking syncs and merges and trying to ensure that they reach zero is pre-DIF
<persia> Great.  Thanks.
<cjwatson> feature set development is actually pre-FF but it so happens that UVF==FF this cycle
<cjwatson> it turns out, of course, that often one of the best ways to develop a feature is to persuade upstream to do it and pull from them ...
<persia> cjwatson: Sure :)
<ScottK> keescook: Ping - I'm pondering trying to fix Bug #15485 and Bug #76983 (and thinking I might as well sweep up Bug #39459 while I'm at it.  Do you have a moment to discuss it?
<ubotu> Launchpad bug 15485 in gnupg "kmail don't ask the phrase for gpg-encrypted mails" [Medium,In progress]  https://launchpad.net/bugs/15485
<ubotu> Launchpad bug 76983 in gnupg "Doesn't create settings correctly on first start" [Low,Confirmed]  https://launchpad.net/bugs/76983
<ubotu> Launchpad bug 39459 in gnupg "gnupg crash on breezy" [Medium,Confirmed]  https://launchpad.net/bugs/39459
<keescook> ScottK: one moment, just got back from lunch.  I'll go read them.
<ScottK> OK.
<Keybuk> xorg-server is very very large :-/
<Mithrandir> much smaller than xfree. :-)
<pygi> :P
<Keybuk> I think I encountered a libtool bug ...
<Keybuk> Xdmx (whatever that is) wasn't linking against composite, damageext, xfixes, etc.
<Mithrandir> Xdmx is distributed multihead X.
<Mithrandir> like Xinerama on heavy, heavy drugs.
<Keybuk> yeah, I figured I didn't need/care about that bit, but it was stopping the build :p
<Keybuk> of course, I am applying random patches from the Internet; so this could all go horribly wrong :p
* pygi keeps his xorg-server safe from Keybuk 
* shirish can't stop laughing seeing the brotherhood between pygi & Keybuk :P
<agoliveira> Can anyone there help me with a sed line? I have a string like this "hotkey ATKD 00000020 00000001" and I need to have as result just the 2 last digits of the first number (20 in this case).
* agoliveira promisses to revisit ER ASAP.
<coNP> agoliveira: what about |cut -d " " -f 3 | tail -c 2
<agoliveira> coNP: That should do. I was just hoping to make a RE on this.
<Keybuk> s/^[^0-9] *\([0-9] [0-9] \).*/\1/
<coNP> Keybuk: does not work for me
<agoliveira> Keybuk: Nope. I got 00
<Keybuk> oh, sorry, last two digits
<agoliveira> coNP: BTW, it should be tail -c 3 because of the trailing space 
<coNP> sure I noticed that since :)
<Keybuk> s/^[^0-9] *[0-9] *\([0-9] [0-9] \).*/\1/
<agoliveira> Keybuk: That's it :)
<agoliveira> Geez... I really have to read again about REs.
* agoliveira hugs Keybuk and cpNP
<agoliveira> sorry coNP
* coNP hugs agoliveira back
<Keybuk> odd request time
<Keybuk> anyone got an HD video file (like a trailer or something?)
<thom> Keybuk: download one from apple?
<ogra> HD TV but no recording device here :/
<agoliveira> Keybuk: Look for that Elephant Dream short movie.
<Ng> there's fairly good google juice from: hd sample video  :)
<Keybuk> thom: ah, good call!
<Hobbsee> bah.  why is pitti *always* not here when i have a earth-shattering line of logic for him?
<Hobbsee> and why is heno not here whenever i want to speak to him?
* Hobbsee sighs 
<axxo> because then you couldn't make us curious with lines like that
<keescook> ScottK: I can't say I entirely understand 15485.  76983 looks very important to fix, and yeah, snag 39459 while you're in there.  :)
<keescook> er, I should say, I'm not sure I understand the full ramifications of the proposed solution to 15485.
<ScottK> keescook: For 15485 we need to configure gpg to use-agent.  I had mail to devel discuss on the topic.  All the other pieces are there.
* ScottK will get you the link for the mail.  Just a moment.
<Hobbsee> pitti!   speak of the devil!
<keescook> ScottK: will this cause problems for people who use gpg when outside of xorg?
<ScottK> No.
<ScottK> If gpg is configured for agent and it can't find an agent it just prints to the terminal that it couldn't find an agent and asks you for the passphrase as usual.
<pitti> Hobbsee!
<seb128> pitti: re, could you give a retry to gnome-main-menu on all arches?
<ScottK> Both pinentry-qt and pinentry-gtk have fallback modes for curses.
<keescook> ScottK: aah, perfect.  sounds good to me then.  :)
<ScottK> Here's the mail: https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2007-July/001282.html
<pitti> seb128: don
<ScottK> OK.  I'll go work on them some more and ping you when I have a diff.
<seb128> pitti: danke
<pitti> seb128: ...e
<ScottK> Actually it's pinentry-gtk2... not gtk.
<StevenK> pitti: libcurl4, libcurl4-openssl, libgoffice-0-3, libgoffice-gtk-0-3 and libntfs-3g2 can all disappear now, they all no longer have rdepends.
<keescook> ScottK: looks good to me.  :)  go for it.
<ScottK> OK.
<Hobbsee> pitti: how busy are you at this point?  i've had some earth-shattering thoughts w.r.t cd testing/release management.
<Hobbsee> pitti: which i should probably run past you, as you're the current RM.
<Hobbsee> but, i can wait until you're not busy if you prefer
<pitti> StevenK: yay!
<seb128> StevenK, pitti: I cleaned some of them already, doing libgoffice now
<pitti> Hobbsee: that's fine, I'll just do some NEW love alongside
<StevenK> seb128: Oh, great
<StevenK> seb128: If you do a rebuild of gnome-power-manager, libwnck18 can go, too
<StevenK> If bug 124385 is dealt with, too
<ubotu> Launchpad bug 124385 in emerald "Packages to remove from Gutsy" [Wishlist,Confirmed]  https://launchpad.net/bugs/124385
<pitti> StevenK: I think seb already removed 2/3 of gnutls and libntfs-3g2, but I didn't see rebuilds for goffice yet
<seb128> StevenK: a new package has been uploaded this morning and I already removed libwnck18
<StevenK> seb128: Great.
<pitti> seb128, StevenK: let me regenerate cruft first
<StevenK> pitti: I uploaded two of them one and two hours ago
<pitti> ah, cool
<seb128> I mentionned them on #ubuntu-motu and he picked them immediatly, good team work ;)
<pitti> NBS regenerating
<StevenK> I've been living and breathing the NBS list for the past two days, just ask pitti. :-)
<pitti> updated
<pitti> heh, does libgoffice have a dependency on itself, or what? :)
<StevenK> Hmph, it hasn't seen my uploads of gchempaint and gnome-chemistry-utils.
<seb128> pitti: looks like ;)
<geser> StevenK: is the NBS file for libwnck18 already gone? because emerald and heliodor still depend on it
<StevenK> geser: seb128 killed libwnck18 already, and NBS can't check it if it isn't in the archive ...
<seb128> geser: there is a removal bugs for those
<geser> ah, seen the bug now
<seb128> and it's pitti's archive day, so I'm sure you can get him to close the bug ;)
<StevenK> pitti? *flutters his eyelashes*
<seb128> StevenK: http://launchpadlibrarian.net/8322723/buildlog_ubuntu-gutsy-i386.gchempaint_0.6.6-3build1_FULLYBUILT.txt.gz
<seb128> StevenK: both libgoffice3 and 4 got installed
<StevenK> I see that.
<StevenK> I see why, too
<StevenK> I wasn't aware gchempaint also linked against libgcu.
<StevenK> seb128: I'll reupload gchempaint when I get up.
<seb128> ok
* StevenK makes a note to upload digikam and gchempaint tomorrow ... er, later today.
<geser> StevenK: what's your plan with beryl-ubuntu package which depends on heliodor?
<StevenK> Kill it also?
<geser> StevenK: I can upload gchempaint if you want
<StevenK> geser: It needs to wait for gnome-chemical-utils, and I already have it prepared.
<geser> is emerald/ heliodor the only part from beryl already merged?
<StevenK> For CompComm? No idea.
<shirish> ogra: can you look at http://pastebin.ubuntu-nl.org/28806/ and see if there is a bug filed against it, icon-theme & artwork of edubuntu doesn't live with ubuntu, xubuntu-desktop icon theme & artwork. 
<shirish> ogra: seb128 told me you are the best person to answer this 
<shirish> or know about this
<ogra> shirish, sorry, i didnt have time to care for edubuntu-artwork yet, some dependencies need to change ... i'll do that before tribe3
<shirish> ogra: ok cool, i just wanted to know if a bug has been filed against it, so I know the progress whenever you do the edubuntu-artwork stuff & release it. So I can try installing it then. 
<Ditiris> Can anyone give me a clue on how to diagnose this problem:
<Ditiris> *Loading hardware drivers... 
<Ditiris> [    43.288051]  input: PC Speaker as /class/input/input3 
<Ditiris> [    43.320373]  pci_hotplug: PCI Hot Plug PCI Core version: 0.5 
<Ditiris> [    43.321851]  shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 
<Ditiris> [    43.323796]  agpgart: Detected an Intel 965G Chipset. 
<Ditiris> [    43.338657]  Bad page state in process 'modprobe' 
<ogra> edubuntu-artwork needs some essential changes thats why i didnt touch it yet, i want to do it all in one go
<Ditiris> [    43.338659]  page:ffff81011fd3e308 flags:0x0000000000000000 mapping:0000000000000000 mapcount:1 count:0 
<Ditiris> [    43.338660]  Trying to fix it up, but a reboot is needed 
<Ditiris> [    43.338661]  Backtrace: 
<Ditiris> [    43.338712]  Bad page state in process 'modprobe' 
<Ditiris> [    43.338714]  page:ffff81011fdb9860 flags:0x0000000000000000 mapping:0000000000000000 mapcount:1 count:0 
<Ditiris> [    43.338715]  Trying to fix it up, but a reboot is needed 
<ion_> ditiris: PLEASE
<Ditiris> [    43.338716]  Backtrace: 
<Ditiris> [    43.338717]  
<Ditiris> [    43.338718]  Call Trace: 
<seb128> !op
<ubotu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<Ditiris> [    43.339539]  
<Ditiris> [    43.339540]  Call Trace:
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [+b *!*@mail.mustangtechnology.com]  by Hobbsee
* Ditiris was kicked off #ubuntu-devel by Hobbsee (Hobbsee)
<seb128> Hobbsee: thanks
* Hobbsee bashes ditiris with the pastebin sitck
* ogra hugs Hobbsee 
* Hobbsee bashes ditiris with the pastebin stick
<Hobbsee> seb128: no problem
* Hobbsee hugs ogra 
<Hobbsee> ogra: that means i should hound you about the artwork stuff?
<ogra> nah
<ogra> :)
<Hobbsee> you're *kidding* me.
<shirish> ogra: ok in that case, should I file a bug & then tell you about it, so the bug-report tells me when you are done with it. 
<ogra> i need to care for it anyway, else tribe3 wont happen
<Hobbsee> the guy just flooded #ubuntu with it too, after getting kickbanned from here!!!!
<ogra> shirish, feel free
<shirish> ogra: ok cool 
<cjwatson> Hobbsee: I'd have just kicked him rather than banning him too ...
<Hobbsee> cjwatson: true, but i'm too used to /kb
<shirish> ogra: erm.... which package should it be filed under?
<Hobbsee> cjwatson: i've been dealing with #ubuntu for a few days
* mode/#ubuntu-devel [-b *!*@mail.mustangtechnology.com]  by Hobbsee
<ogra> shirish, edubuntu-artwork
<Hobbsee> cjwatson: also, i didnt want him to rejoin, say "did you get my question?" and start flooding again.  clueless people do that.
<shirish> ogra: ok, there is a meta-package by that name, I just took it like that
<Hobbsee> cjwatson: whereas if they see the big "you are banned" message, they tend to have to read it a few times, when they realise they cant rejoin the channel, and actually think about it and process it.
<azeem> just banning might be more effective then, it will silence them, and you can explain them in-channel what they did wrong
<StevenK> Or +q them.
<Hobbsee> azeem: well, the guy hasnt jumped into #ubuntu yet again either?
<Hobbsee> StevenK: /kb is faster than /quiet
<Hobbsee> and both are faster than /remove
<Hobbsee> and the autoresponse is to reach for the /k or the /kb
* azeem uses /ab
<StevenK> You just have itchy trigger fingers. :-P
<Hobbsee> StevenK: hush, you, else i'll make you op #ubuntu during australian timezones for a week.
<Hobbsee> and that'll give you a trigger finger too
<Hobbsee> and -offtopic :)
<StevenK> Heh
<Ditiris> Sorry about the large text.
<Ditiris> Here's the error I receive in console: Here's the console output: http://paste.uni.cc/16642
<Hobbsee> Ditiris: please please please learn about a pastebin
<Ditiris> Hobbsee: Sorry.
<Hobbsee> no problem
<Hobbsee> Ditiris: i'd suggest you go to #ubuntu+1 for gutsy support, though, seeing as this is not a support channel
<Ditiris> Hobbsee: Thank you for redirect.
<Hobbsee> no problem
<shirish> ogra: filed bug 124414
<ubotu> Launchpad bug 124414 in edubuntu-artwork "[Gutsy]  edubuntu-artwork reports a conflict with ubuntu, xubuntu-artwork" [Undecided,New]  https://launchpad.net/bugs/124414
<ogra> thanks
<Hobbsee> Ditiris: in fact ^ is the issue you're facing, i imagine
<shirish> :)
<Hobbsee> oh wait.  wrong pastebin
<shirish> ubotu paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<Hobbsee> cjwatson: btw - a lot of clients now rejoin on kick.  so you really have to use a remove, or a kickban
<cjwatson> Hobbsee: they don't usually continue pasting, though
<cjwatson> Hobbsee: and if they do, *then* you can kickban
<Hobbsee> cjwatson: erm...can i just agree to disagree with you there, on the first line, having seen too much of #ubuntu recently?
* Hobbsee should alias /remove to something even shorter, though
<LaughingMan> fdfd
<Hobbsee> hi LaughingMan 
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<cjwatson> Hobbsee: fair enough
* cjwatson goes back to trying to nail his tribe-3 bugs
<Hobbsee> hehe, good luck :)
* pygi also has his own tribe-3 bugs
<Hobbsee> pygi: yes :)
<Hobbsee> pygi: need a sponsor for htem?
<pygi> Hobbsee, yes, but next week
<Hobbsee> pygi: oh right.  for some reason i thought it was a week later.
* Hobbsee had around half a week off work - it's totally thrown her internal calender
* Hobbsee had around half a week off work - it's totally thrown her internal calendar
<pygi> /kickban Hobbsee do not paste
<pygi> :)
<Hobbsee> pygi: /kb Hobbsee learn to spell
<cjwatson> pitti: confirmed your restricted-manager bug, BTW, or at least a different incarnation of the same problem - it bites ubiquity-oem too
<Hobbsee> pygi: not much point though.  i can unban myself, being on the access list :)
<cjwatson> it's actually more of a missing feature :-(
<pygi> Hobbsee, :)
<pitti> cjwatson: in the sense of "apt-install doesn't install anything that's not already in the live system"?
<cjwatson> pitti: yees
<cjwatson> er, yes
* Hobbsee whines over apt.
<cjwatson> it prevents things from being removed, but doesn't actually install them. whoops
<Hobbsee> it's broken, and i dont know how to fix it.
<geser> Hobbsee: what did you break?
<Hobbsee> geser: it was already broken.
<Hobbsee> geser: i fixed some of the FTBFS' in the bzr, and then got stuck.
<Hobbsee> unfortunatley, stevenk's rebuild in the archive FTBFS too.  so we actually have no building apt at the moment.
* pitti sobs, my nice canned bug replies went away again, except for the first oen
<pitti> keescook: ^ so moving that script to the top of the stack didn't help
<Hobbsee> pitti: that really does seem to hate you..
<pitti> as much as I love it when it works, yes
<keescook> pitti: ugh.  let me see if I want figure out some way to export and import replies -- that way you can externally save them.
<keescook> Hobbsee: have you seen them vanish for you ever?
<pitti> keescook: I wonder whether I'm the only one who sees this
<Hobbsee> keescook: nope
<pitti> keescook: I might just kill my ffox profile and start all over
<Hobbsee> keescook: not even changing firefox versions
<keescook> pitti: so far, the people I know of using it is me, bdmurray, Hobbsee, and you.
<pitti> keescook: or maybe some of Mithrandir's and your scripts don't mix well with that one
<pitti> keescook: I think Mithrandir has a version which hardcodes the replies in the .js source; that would work, too
<keescook> yeah, the hardcoded one was where mine started from.
<Kano> why is in a daily snapshot of a kubunut live cd the xserver-xorg-intel 2.0.0 and not 2.1.0?
<luisbg> cjwatson, thanks for the approval in devel ML
<Hobbsee> Kano: what was the build date on the daily snapshot?
* Hobbsee wonders if they're even getting built at the moment
<Kano> 671M 2007-07-06 06:26 gutsy-desktop-amd64.iso
<Kano> also i need a new mesa snapshot
<Hobbsee> that's the time/date it was modified on your system.  != build date
<Kano> for 3d on intel g33
<Hobbsee> ie, that tells us nothing about which build it might be
<Kano> i download with wget -N, thats server data
<Kano> the latest
<Kano> for g33 you need 2.1.0+new mesa
<Kano> mesa from sid is still too old
<Hobbsee> sarah@LongPointyStick:~$ madison xserver-xorg-video-intel
<Hobbsee> xserver-xorg-video-intel | 2:2.1.0-1ubuntu1 | http://mirror.pacific.net.au gutsy/main Packages
<Hobbsee> xserver-xorg-video-intel | 2:2.1.0-1ubuntu1 | http://archive.ubuntu.com gutsy/main Packages
<Hobbsee> xserver-xorg-video-intel | 2:2.1.0-1ubuntu1 | http://mirror.pacific.net.au gutsy/main Sources
<Hobbsee> sarah@LongPointyStick:~$ madison mesa
<Hobbsee>       mesa | 7.0.0-0ubuntu2 | http://mirror.pacific.net.au gutsy/main Sources
<Hobbsee> them?
<Kano> the intel driver works when i do a dist-upgrade 
<Kano> just 2d
<Kano> btw. hal breaks the dist-upgrade of the lastest iso
<Kano> but at least intel driver is current enough
<Kano> mesa is indirect rendering
<Hobbsee> pitti: the daily cds that are building - are they actually real dailies, with what's in the archive, or are they the same as the tribe 2 ones, just with a different date?
<pitti> Hobbsee: real dailies actually
<Hobbsee> that's weird.
<Hobbsee> pitti: any idea why the xserver-xorg-video-intel, mesa wouldnt be the updated versions on the cds, then?
<pitti> http://cdimage.ubuntu.com/daily/20070706/gutsy-alternate-amd64.list has /pool/main/m/mesa/libgl1-mesa-glx_7.0.0-0ubuntu2_amd64.deb
<pitti> which is precisely the current version in gutsy
<pitti> same for -xorg-intel
<cjwatson> the live filesystem builds are failing, though
<pitti> mesa is current on i386 alternate as well, but -intel isn't on the CD
<cjwatson> note that Kano is using desktop not alternate
<pitti> aah
<cjwatson> The following packages have unmet dependencies:
<cjwatson>   libcurl3-gnutls: Conflicts: libcurl4-gnutls but 7.16.2-6ubuntu3 is to be installed
<cjwatson>   libcurl4-gnutls: Depends: libcurl3-gnutls (= 7.16.2-6ubuntu3) but 7.16.2-6ubuntu4 is to be installed
<Hobbsee> even by using http://cdimage.ubuntu.com/kubuntu/daily/20070706/gutsy-alternate-i386.list
<pitti> Hobbsee: right, due to curl and OOo mess
<Kano> also i use KUBUNTU desktop
<pitti> Hobbsee: we need the OO.o package from calc 
<cjwatson> Kano: Kubuntu is not an acronym and thus should not be in all-caps
<Hobbsee> Kano: yeah, i eventually figured that one, due to the file size.  helpful if you can actually *tell* us such information, without having to go fishing for it, too, btw
<cjwatson> same error for Kubuntu, anyway
<Kano> cjwatson: ?
<pitti> Kano: we need to get rid of the libcurl4 package, which requires a new OO.o upload
<Hobbsee> http://cdimage.ubuntu.com/kubuntu/daily-live/20070706/gutsy-desktop-amd64.list that, sorry
<cjwatson> Kano: you said "KUBUNTU". That is not the correct capitalisation. In English only acronyms should be in all capital letters.
<pitti> after that's done, live CDs will build again; its' already in progress
<Kano> cjwatson: i just wanted to tell you that i dont use the ubuntu one
<cjwatson> I realise that, but it doesn't matter in this case
<cjwatson> both have the same problem
<Hobbsee> cjwatson: anywhere public that we can check the live filesystem builds, then?
<cjwatson> Hobbsee: sure, they've been public for ages and ages
<pitti> http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/
<Hobbsee> cjwatson: sorry, where are they?
<Hobbsee> ahhh....
<cjwatson> Hobbsee: 
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/
<Hobbsee> thanks
<cjwatson> cd-build-logs is something else
<pitti> ah, right
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/kubuntu/latest/livecd-20070706.1-amd64.out is the one pertaining to Kano's build
<Kano> how about using aufs instead of unionfs?
<Kano> unionfs behaves very bad in some cases (especally in vm)
<Kano> aufs is very similar in use and does not have that problem
<cjwatson> pkl is looking into newer versions of unionfs; not sure about aufs
<Kano> using aufs is really the more stable choice
<cjwatson> we certainly cannot use something not in the Ubuntu kernel, though
<cjwatson> so the appropriate people to ask are the kernel team
<Kano> well i do my own live cd, i have integrated both for testing
<Kano> hmm in theory mesa 7 is new enough when i grep for G33..
<Kano> but why do i have got still indirect rendering then
<Kano> will check with next livecd...
* Hobbsee --> bed.  night all.
<pitti> bye Hobbsee 
<keescook> cya Hobbsee
<Hobbsee> :)
* Hobbsee waves hello and goodbye to bryce 
* bryce waves back
<Hobbsee> :)
<ScottK> keescook: gnupg has me stumped.  The recommended change for installing the config file does not appear to me to solve the problem.  Would you be able to look at it?
<pkl_> cjwatson: I'm currently looking into both Unionfs and aufs...
<keescook> ScottK: just heading out now; can you describe the issues in that first bug?  I can dig into it a little later?
<ScottK> OK.  I'll attach the debdiff of where I am with some additional discussion and subscribe you to the bug if you aren't. keescook: will that work?
<keescook> yup!  perfect, thanks.  :)
<geser> ScottK: what problem do you have?
<ScottK> geser: I'm writing it in the bug just now.  
<ScottK> geser: Please see Bug #76983
<ubotu> Launchpad bug 76983 in gnupg "Doesn't create settings correctly on first start" [Medium,In progress]  https://launchpad.net/bugs/76983
<ScottK> geser: There's no pride of authorship here.  If you can figure it, please do.
<geser> ScottK: have you already a .gnupg/gpg.conf?
<ScottK> No
<ScottK> I did, but I removed it before installing.
<geser> only the file or the whole dir .gnupg?
<ScottK> Only the file
<geser> can you check if you still have a problem, with no .gnupg dir?
<ScottK> OK.
<ScottK> On the phone at the moment.
<ScottK> geser: When I ran gpg after moving .gnupg it reacreate the dir, but no gpg.conf in it.
<geser> and the error about the wrong directory to options.skel is gone?
* ..[topic/#ubuntu-devel:GhoSt] : Ta geule connard
<tsmithe> erm...
<nixternal> yay, idiot on board
* ..[topic/#ubuntu-devel:GhoSt] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Tribe 2 released
<tsmithe> ok that was weird
* ..[topic/#ubuntu-devel:GhoSt] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs | Im a lame | Tribe 2 released
<nixternal> !ops
<ubotu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<geser> ScottK: is there a reason why you comment out the 60_install_options_skel patch in 00list in your debdiff? only because it's not working?
<ScottK> Argh
<GhoSt> !ops
<ubotu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
<ScottK> There is a reason, but not a good one.
<GhoSt> !ops*
<ubotu> Sorry, I don't know anything about ops* - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<GhoSt> !ops
<thom> oi!
<GhoSt> !ops
<thom> once is enough
<GhoSt> Help me ! Im lame !!
* mode/#ubuntu-devel [+o thom]  by ChanServ
<nixternal> thank you thom
<GhoSt> bye
<GhoSt> Happy to knew U :'(
<GhoSt> !ops
<ubotu> Help! bhale, infinity, Hobbsee, jdub, thom, fooishbar, fabbione, mdz, lamont, or Keybuk
* ..[topic/#ubuntu-devel:thom] : Development of Ubuntu (not support, even with gutsy; not application development on Ubuntu) | #ubuntu for support and general discussion for dapper/edgy/feisty, #ubuntu+1 for gutsy support | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs |  Tribe 2 released
<ScottK> geser: I had a theory that maybe the patch was getting applied to late in the build process so edited the makefiles directly and commented out the patch.  Forgot to uncomment the patch for the debdiff.
<GhoSt> !help kb me !
<ubotu> Sorry, I don't know anything about help kb me ! - try searching on http://bots.ubuntulinux.nl/factoids.cgi
* mode/#ubuntu-devel [+b *!*n=psyko@83.214.23.*]  by thom
* GhoSt was kicked off #ubuntu-devel by thom (thom)
<thom> W.T.F?
<nixternal> hehe
<ScottK> geser: I also (just) tried creating a new user and running gpg there.  Same result.
* pitti bounces happily
<pitti> Listing ubuntu/None (NEW) 0/0
* nixternal high-fives pitti
<pitti> *phew*
* nixternal quickly dputs 1000 NEW packages ;p
<nixternal> 0/0 means you need work :)
<pitti> nixternal: thanks, staring at licenses and files for two hours is enough for a day :)
<nixternal> ahh, licenses are not fun at all
<tsmithe> thanks for going through the queue, pitti :)
<bhale> thom: jeez
<geser> pitti: have you some time to upload a small fix for the apt FTBFS?
<pitti> geser: I'm about to leave, but if it's quick, toss it over
<geser> pitti: http://members.ping.de/~mb/apt.debdiff
<geser> it just needed a autoconf before building the source package
<pitti> geser: did you check this into the bzr?
<geser> not yet
<ScottK> geser: I wonder if that's my problem with GPG too....
<pitti> I'd rather have it there, for the sake of consistency
<geser> have to figure out how to do it
<shawarma> geser: That works?!?
<geser> I can't commit directly to the apt bzr
<pitti> geser: ok, I'll commit it there
<geser> shawarma: yes, it complained that it can't find autoconf
<geser> pitti: thanks
<pitti> geser: thanks for fixing
<geser> ScottK: looking at your gnupg problem now
<ScottK> Thanks
<pitti> geser: uploaded; bzr get takes ages, I'll check it in later
* pitti waves goodbye
<pitti> have a nice weekend
<ScottK> geser: I don't have it figured yet, but I'm thinking it's a path issue of some kind.
<geser> ScottK: I guess you were right about autoconf
<ScottK> Could you make it work then?
* ScottK hasn't succeeded.
<geser> I'm doing a build know
<geser> ScottK: gpg: new configuration file `/tmp/.gnupg/gpg.conf' created
<geser> gpg: WARNING: options in `/tmp/.gnupg/gpg.conf' are not yet active during this run
<geser> I tested it from within a pbuilder
<ScottK> OK.  What additional changes did you make then?
<geser> it only works if the user hasn't run gnugpg before (i.e. has no ~/.gnupg dir)
<eagles0513875> do we have any debuggers in here cuz i just bought a linux magazine that hasa kool program that is easy to debug stuff
<geser> ScottK: http://members.ping.de/~mb/60_install_options_skel.dpatch
<geser> that's the updated dpatch
* ScottK looks
<geser> I've run autogen.sh and stripped out the unneeded changes (as I did know how to patch g10/Makefile.in by hand)
<geser> the only new patches are for configure and g10/Makefile.in
<ScottK> OK.  Would you update the debdiff on the bug then or do you want me to?
<geser> I will update it
<Kmos> BenC: bug 63402
<ubotu> Launchpad bug 63402 in linux-source-2.6.17 "Edgy Beta cannot boot" [High,Fix committed]  https://launchpad.net/bugs/63402
<ScottK> geser: Great.  Thanks.
<eagles0513875> ScottK: u might like this program www.undo-software.com 
<eagles0513875> it should make debugging stuff easier
<ScottK> eagles0513875: This isn't a random chit-chat about stuff channel.
<eagles0513875> i know i was just trying to make debugging easier for u guys
<ScottK> eagles0513875: If you know anything about Ubuntu at all, I think you'd understand that random touting of proprietary software isn't particularly appreciated.
<eagles0513875> ok
<geser> ScottK: while we are it: could we fix bug #62864 too?
<ubotu> Launchpad bug 62864 in gnupg "[Edgy]  Refreshing my keyring stops after some keys (keyserver time out)" [Undecided,New]  https://launchpad.net/bugs/62864
<geser> adding libcurl to build-depends fixed it for me and I've done it already for gnupg2 which I use
<ScottK> geser: I sure don't mind.
<ScottK> It all depends on what you can convince keescook to upload.
<ScottK> And if it's your name at the bottom of the debian/changelog entry so you touched it last and not me, I don't mind that either ;-)
<Luckye> hello
<Luckye> there is someone who now use php?
<ScottK> Luckye: This is a development channel, not a support channel.  Try #ubuntu.
<Luckye> mmm
<Luckye> sorry
<Luckye> thanks 
<ScottK> No problem.
<Luckye> how can i access at that room?
<evand> Luckye: type /join #ubuntu
<Luckye> where? here?
<geser> that same way you joined this channel
<Luckye> escuseme?
<Pici> Just type it here.
<Luckye> where is there someone who can help me to learn to use  glade?
<ScottK> Luckye: In the same place you just typed escuseme?, type /join #ubuntu
<ScottK> Luckye: Not here.  It's off topic for this channel.
<geser> ScottK: added the updated debdiff to the bug
<geser> waiting now for keescook for review :)
<ScottK> Cool.  Thanks.
<ScottK> geser: I see you added libcurl4-gnutls-dev.  I thought we went back to libcurl3?
<geser> yes, curl is very special nowadays
<geser> the package with the library is called libcurl3{,-gnutls} but the headers are in libcurl4-*-dev
<ScottK> geser: At this point the fix for the lack of a gpg.conf only works on new installs.  Should we do something for upgrades?
<geser> ScottK: I'd add only a news entry
<geser> users already using gnupg must add the option manually (if they use kmail)
<ScottK> OK.  I guess we cover that in the documentation.
<ScottK> geser: What about a check in the postinst to see if ~/.gnupg/gpg.conf exists and cp /usr/share/gnupg/options.skel ~/.gnugpg/gpg.conf if it doesn't.  That won't help a lot for multi-user systems, but for single user systems that would solve the concequences of the bug without risking over-writing existing user setting.
<geser> ScottK: package installation is run as root so ~ will point to /root
<ScottK> Of course.
<ScottK> We could walk through all the dirs in /home, but it's probably well into more trouble than it's worth at that point.
<superm1> ScottK, what is the bug you guys are referring to?
<geser> superm1: bug #76983
<ubotu> Launchpad bug 76983 in gnupg "Doesn't create settings correctly on first start" [Medium,In progress]  https://launchpad.net/bugs/76983
<geser> ScottK: when I think again about it, I'm not sure if ~ will point to /root as update-manager is run through sudo but I wouldn't depend on this
<geser> that it points to the users home
<superm1> at the same time wouldn't you want to install that options file into /etc/skel too?
<ScottK> Right.  If we were going to do it we would want to check explicitly in each dir in /home.
<ScottK> superm1: That would make sense.
<geser> superm1: gnupg copies it itself if no ~/.gnupg exists (but you can do it also through /etc/skel)
<superm1> ah
<ScottK> superm1: You want to whip us up a quick shell script I can add to the postinst to make it all better?
<superm1> ScottK, I could later on - but i'm at work atm :)
<ScottK> Ah.
<ScottK> geser: Is libcurl4-gnutls supposed to be installable right now?
<geser> ScottK: as gnupg is in the ubuntu-minimal task it's installed on every system so I'd be very careful about scanning /home (I think about edubuntu/LTSP)
<ScottK> superm1: If you get to it before keescook does the gnupg upload you might add it to the debdiff on bug #76983.
<ubotu> Launchpad bug 76983 in gnupg "Doesn't create settings correctly on first start" [Medium,In progress]  https://launchpad.net/bugs/76983
<ScottK> geser: I was thinking look for .gnupg and if you don't find it, stop.  If you do check for gpg.conf.  If you do find it, stop.  If you don't copy in the skel file.
<geser> ScottK: you mean libcurl4-gnuts-dev? yes, at least in a pbuilder
<superm1> ScottK, okay i'll see if i can do that later this evening
<ScottK> geser: Any chance you could pop over to #kubuntu and give manchicken (don't ask) a hand with it as he's still having trouble with it (libcurl4-gnutls).
<geser> sure
<ScottK> geser: Oops.  #kubuntu-devel.  Sorry.
<superm1> ScottK, actually i've got a quick script you can throw in it
<superm1> i just ack'ed how easy that would be 
<superm1> let me throw it in a pastebin for you
<ScottK> OK
<superm1> ScottK, http://paste.ubuntu-nl.org/28858/
<geser> superm1: I'd only copy it if a .gnupg exists
<geser> that way only users using gpg get it
<geser> if the user decides to use gpg in the future he will get the actual options file when running gpg the first time
<ScottK> Yes.  I agree with that.
<superm1> http://paste.ubuntu-nl.org/28861/
<ion_> Also be paranoid about someone stupid enough to have a space in his username. :-) (Does something prevent that?)
<superm1> something like that instead then
<geser> ion_: I'm not sure if adduser allows them
<geser> superm1: you also want to fix the ownership, the user should be able to edit it afterwards
<evand> ion_: the installer checks for that
<evand> but yeah, not sure if you can do it after the fact
<superm1> geser, what should permissions be on the resultant file then?
<evand> apparently not
<superm1> -rw-r--r--?
<ScottK> 600 I think
<ScottK> http://paste.ubuntu-nl.org/28862/
<ScottK> is what I was thinking.
<superm1> right
<superm1> but dont you need the file your changing as an argument?
<ScottK> I have a dapper box (with a gpg.conf from before this bug was introduced) and it's 600
<ScottK> Yeah. Details like which file...
<ScottK> http://paste.ubuntu-nl.org/28863/'
<ScottK> http://paste.ubuntu-nl.org/28863/
<ScottK> even
<geser> ScottK: it's not garanteed that every user has it's own group (although is common)
<ScottK> That's the standard Ubuntu install, right?
* ScottK would think supporting standard installation would be enough for this.  Anyone doing a non-standard install should know how to fix it themselves...
<ScottK> ?
<geser> yes, USERGROUPS=yes in /etc/adduser.conf
<ion_> getent passwd | awk 'FS=":" { if ($3 >= 1000) print $6 }' | while read home; do if [ -d "$home/.gnupg" ] ; then ...; fi; done
<geser> but I don't know if it's true for all Ubuntu variants
<geser> ScottK: and a package updated shouldn't fail on a non-standard installation
<axxo> nor should it mess around in $home imo, but i'm clueless
<ScottK> Agreed.
<geser> axxo: that too
<ScottK> axxo: normally you wouldn't have too, but the bug is a missing conf file.  The question is how to get it un-missing.
<axxo> it doesn't inherit from a global defaults config file?
<ScottK> Not if you are past first run for gpg.
<cjwatson> ScottK: can't the program itself be fixed, rather than hacking around it in the postinst?
<superm1> ion_, have to be careful with that getent, it still got a /nonexistant in the list
<cjwatson> ScottK: postinst fiddling won't work on systems that NFS-mount /home
<superm1> for the nobody acct
<cjwatson> ScottK: which is one reason no package does it
<ion_> superm1: [ -d "$home/.gnupg" ] 
<ScottK> cjwatson: We have the fix to create on first run.  The question is do we try and fix the upgraders who don't have it at all because of this bug.
<superm1> oh right :)
<ScottK> It may well be to hard and we mention it in the release notes.
<cjwatson> ScottK: you can't do it correctly, and attempting to do it in the postinst will likely make matters worse in harder-to-find ways
<cjwatson> ScottK: it would also be possible to create the options file on non-first run if it's missing
<ScottK> OK.  
<cjwatson> (I don't know enough about gpg to know whether that's sane)
<ScottK> Having explored it here (thanks) it sounds to me like it's to important a package to take risks with.
* ScottK thinks release notes it is.
<geser> ScottK: older gpg used .gnupg/options as options file
<geser> I'd need to look up if it's still supported
<geser> it's ok for those users to not have an gpg.conf file
<geser> ScottK: another note: the gpg-agent starts (currently) only if use-agent is set
<ScottK> Right.  That's why the new patch sets use-agent.
<ScottK> geser: See 61_use_agent_default patch.
<geser> ScottK: you should add to the release notes that users who add use-agent manually need to logout and login again to be able to use it (to get one running gpg-agent)
* Nafallo wonders how long we will have the transitional package ssh along
<ScottK> geser: That or (I think) eval agent (I'll get the exact syntax, I have it in my notes).
<Nafallo> ssh has been a transitional package since warty :-P
<Nafallo> time to remove it? ;-)
#ubuntu-devel 2007-07-07
<blueyed> Nafallo: file a bug about ssh. I think it should become a meta/redirect package instead. Maybe only the desc needs to get changed?
<ijuz_> ok, damn, no idea what package exactly is causing this: tribe-2 alternate installs on my laptop (dell latitude D830), but 20070704 produces just really fancy colourful signs at the point when you can choose the resolution, 20070706 produces just a black screen
<calc> i managed to pack a weeks worth of clothes and my laptop, psp, etc into my laptop bag :)
<realist> Always helps when a "weeks worth" of clothing is one spare shirt, and 7 days worth of undergarments :-)
<calc> 7 undergarments, 5 shirts, shorts, undershirt, etc
<Hobbsee> calc: did you fix openoffice first, though?
<calc> Hobbsee: doko wasn't able to get back to me until late today so i wasn't able to fix it yet
<fabbione> calc: either you are really tiny or your laptop is huge :)
<calc> Hobbsee: he has some fixes he wants me to do with the upload
<calc> fabbione: its a case logic laptop bag
<Hobbsee> fabbione! 
<Hobbsee> calc: ahh.  please do it, i want a working office :)
<fabbione> Hobbsee: !
<calc> i think the newer version of it has a wheel cart built in
<Hobbsee> heh
<calc> Hobbsee: me too, hopefully someone will fix gutsy while i'm there so i can run it too
<Hobbsee> heh
<calc> wow they have even bigger bags now, heh
<calc> looks kinda like this http://www.caselogic.com/15_4_rolling_lightweight_laptop_case/product_detail/index.cfm?modelid=63667  but they don't actually make my model anymore
<srbaker> folks.  having a bit of trouble with netboot.  i've three-times checked my config
<srbaker> but the client is saying File Not Found (even though the logs say the server is sending it)
<srbaker> anyone have any ideas what to check?
<Hobbsee> i'd suggest you want #ubuntu+1
<srbaker> ?
<Hobbsee> support?
<srbaker> i want wherever i can find someone smart enough to give me an answer.
<Hobbsee> not development?
<srbaker> #ubuntu didn't cut it
<srbaker> i'll try there
<Hobbsee> besides, almost no one is here now...
<srbaker> damn
<srbaker> yeah, it's 2 here.  i've never had a netboot not work
<srbaker> and i've done dozens
<Hobbsee> geser: ping
* Hobbsee wishes people would actually *use* bzr for packages in bzr.
<Mithrandir> packages using bzr should have a check in debian/rules which makes the build fall over if you have uncommitted changes.
<Mithrandir> with an override switch, probably
<Hobbsee> Mithrandir: unfortunately the bzr version doesnt actually build at the moment, though
<Hobbsee> mmm...now that would be a ncie plan
<Mithrandir> I pondered doing that for casper, but then I got distracted by something shiny.
<Hobbsee> hehe
<Hobbsee> mmm...shiny
<Mithrandir> now, have we turned you over to the brown side yet?  With shiny.
<Hobbsee> no.
* Hobbsee doesnt like the look of gtk, etc.
<Hobbsee> it's very grey.  not silver.  very dull, and definetly not shiny
<Hobbsee> hi spam
<luka74> StevenK: merged digikam is on http://muse.19inch.net/~lure/digikam/ if you want to upload ;-)
* Lure has seen SteveK digikam rebuild 
* Starting logfile irclogs/ubuntu-devel.log
* #ubuntu-devel  [freenode-info]  channel flooding and no channel staff around to help? please check with freenode support: http://freenode.net/faq.shtml#gettinghelp
<shirish> ubotu paste
<ubotu> pastebin is a service to post large texts so you don't flood the channel. The Ubuntu pastebin is at http://paste.ubuntu-nl.org (make sure you give us the URL for your paste - see also the #ubuntu channel topic)
<shirish> ubotu bug-reporting
<ubotu> Sorry, I don't know anything about bug-reporting - try searching on http://bots.ubuntulinux.nl/factoids.cgi
<shirish> ubotu bug
<ubotu> 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.
<RoC_MasterMind> When 2.6.21 makes it into an Ubuntu package, will the tickless feature be enabled?
<tepsipakki> gutsy has .22
<RoC_MasterMind> with tickless?
<tepsipakki> dunno, what config name is it?
<RoC_MasterMind> I can check
<RoC_MasterMind> CONFIG_NO_HZ maybe.
<tepsipakki> CONFIG_NO_HZ=y
<RAOF> Yeah that's it.
<RoC_MasterMind> I see.
<RoC_MasterMind> Good to know.
<cjwatson_> Nafallo: I've changed ssh to identify itself as a metapackage rather than as a transitional package in my tree.
<geser> Hobbsee: pong
<geser> pitti wanted to check in my apt debdiff as I can't commit directly to the apt branch
<geser> but as he was about to leave and bzr took to long he wants to do it later
<StevenK> Lure: Can I ask you merge my changelog entry into digikam?
<StevenK> Lure: I can do it, if you wish.
<Lure> StevenK: I can do that, no problem
<Lure> StevenK: updated package on http://muse.19inch.net/~lure/digikam/
<Sp4rKy> hi there :)
<Sp4rKy> anyone to check my initramfs-tools merge ?
<Sp4rKy> http://paste.dunnewind.net/15
<ccm> is there a draft somewhere what changed with luks encryption in gutsy? i am interested especially in a hopefully set up gui password prompt
<Fujitsu> ccm: I don't think much has changed, other than some feisty initramfs changes being reverted.
<Sp4rKy> Fujitsu: are you available to check my merge ?
<StevenK> Lure: Okay, I did make it. Source publishing as I speak, and it should hit the buildds in next 45 minutes or so.
<Fujitsu> Sp4rKy: I'm no core-dev, and I know nothing about initramfs-tools.
<Lure> StevenK: great
<Kmos> https://launchpad.net/+builds/kohnen -> someone check the status of this machine
<Nafallo> cjwatson: nice :-)
<Kmos> bug 48556 is already fix released ?
<ubotu> Launchpad bug 48556 in linux-source-2.6.15 "ACPI-0517: ****Error Method parse/execudion failed" [Critical,Fix committed]  https://launchpad.net/bugs/48556
<cjwatson> Kmos: you should ask the kernel team, when they aren't (nearly) all travelling
<Kmos> cjwatson: you aren't a member of kernel team ?
<Kmos> i'm checking the old bugs with fix commited, when Launchpad doesn't check the changelog for LP: #number
<cjwatson> Kmos: no; https://launchpad.net/~kamion/+participation
<cjwatson> I manage the kernel team, but that's different :)
<Kmos> :-)
<Nafallo> https://www.der-winnie.de/?p=94 <-- will that affect us?
<Fujitsu> Nafallo: They're not installed by default, but... hm...
<Nafallo> what might need to add some disclamer on install as we do with codecs maybe :-/
<persia> I don't think we're any more affected than we are for not labeling our distribution of quake2 in accordance with the German game distribution laws, although the german archive may be on both counts.
* Fujitsu pities German network admins.
<Nafallo> Fujitsu: they need shells in other countries now :-)
<ccm> well yes
<ccm> that sucks
<ccm> i swear you
<ccm> i am afraid of using nmap
<pygi> hey sivang 
<ccm> imagine that one
<sivang> hey pygi 
* sivang wonders if was implemented that spec that said we will document changes in process, packaging conventions and distro policy and characteristics for folks who want to do a come-back to ubuntu development :)
<giftnudel> hey sivang, how are you?
<sivang> giftnudel: Martin! I'm fine, thanks, and you?
<giftnudel> me too
<sivang> hmm, don't we have an ltdp package on the feisty repos? odd
<sivang> and it seems to be available from debian unstable
<ijuz__> ccm: the usage is no problem
<yveslu> anyone knows if there is a feisty package for the new intel-xorg driver (version 2.1.0) (http://lists.freedesktop.org/archives/xorg-announce/2007-July/000318.html) ?
<Nafallo> damn this is kewl!
<Nafallo> I just looked at Dell Support for my new laptop and they list Ubuntu Desktop 7.04 in the list of OS :-)
<tepsipakki> Nafallo: in europe?
<ijuz__> Nafallo: so it isn't a new santa rosa model?
<Nafallo> tepsipakki: Swedish pages let me choose Ubuntu on the supportpages :-)
<Nafallo> ijuz__: it is
<Nafallo> D630
<ijuz__> Nafallo: on my D830 it's not so simple, i'm just trying gutsy, but sounds doesn't work at the moment (with feisty it worked)
<ijuz__> (but intel 2.1 is required, otherwise the screen is fuzzy and opengl crashes the box)
<Nafallo> ijuz__: I know who to scream at if it doesn't work for me with gutsy :-)
<ijuz__> when you are bored... you could try gutsy daily, the alternate cd from yesterday just goes black...  i think that is when it tries to detect the screen
<Hobbsee> the gutsy dailies arent worth running
<Nafallo> ijuz__: I'll wait for the laptop, install the latest Tribe and updates to current.
<tepsipakki> Nafallo: ok sweet, couldn't find the equivalent on the finnish pages though.. it'll come for sure
<Nafallo> tepsipakki: sure will :-)
<Kano> hi, today's desktop images still have old packages. i thought someone fixed it?
<Hobbsee> not yet
<Hobbsee> try back in a week or so
<Hobbsee> besides, it's a saturday
<Hobbsee> in fact, a week and a half, probably
<Kano> is there the code available to create those snapshots
<Hobbsee> the fact is, those packages arent all installable, which is why the livefs fails to build
<Hobbsee> so even if you create one locally, it'll still fail
<Kano> well can i get the code to create
<persia> Kano: More generally, there's a lot of library transitions underway, which makes the results not very useful, even if they worked today.
<Hobbsee> the code to build the livefs?  it's probably somewhere.  in fact, debian will have code for it published somewhere.
<Kano> i would like to have it for aufs
<Hobbsee> i dont know exactly where it is
<Kano> funnyly when i backport your mesa 7 on etch along with some backported sid xserver-xorg+intel i can use 3d fine
<Kano> (testing intel g33)
<Kano> i thought you had a fallback included but currently with your live cd X does not start at all, with a (broken) dist-upgrade i can use 2d but not 3d
<Kano> wasn't a vesa fallback somewhere before?
<Kano> or does it rely on autodetection
* Hobbsee has no idea, to be honest
* Hobbsee does not know everything about everything.
<Kano> when you know about the xserver detection (i wrote my own giving the same result then the debian standard one just faster)
<Kano> then you find in the pci.lst the defaults
<ijuz__> probably vesa doesn't work on the g33 gfx chip
<Kano> grep ffffffff /lib/discover/pci.lst
<Kano> sure it does
<Kano> but the defalt for intel is i810
<Kano> or intel, does not matter
<Kano> that will work with intel 2.1.0 driver
<Kano> but in case that default does not work (as it does not with 2.0.0) you get no X at all
<Kano> i see no big problem for intel as soon as you can install a new driver, but the same problem is for nv just more dramtically
<Kano> new nvidia cards work with nvidia binary just fine, but when you force nv then the system even locks
<Kano> my next live cd can install nvidia or fglrx drivers on the fly because of that reason
<Kano> when i have the live code i may add that feature too on these kind of cds
<Kano> is there already a way to execute external scripts?
<Kano> like stored on hd, usb stick or whatever
* Hobbsee splats bryce with a large hammer.
<Hobbsee> bryce: you're clearly not good with spelling names, if you spelt *two* of your sponsors wrong
<bryce> Hobbsee, rats... 
<Hobbsee> bryce: heh
<Nafallo> woha! Tribe 3 is to be released the day before my new lappy arrives :-)
<Hobbsee> https://bugs.launchpad.net/ubuntu/+bug/124587 doesnt look good
<ubotu> Launchpad bug 124587 in Ubuntu "Missing package or incorrect package in the Repositories" [Undecided,New]  
<sn0> Hobbsee it seems its pointing to linux-libc-dev_2.6.20-16.28_i386.deb where linux-libc-dev_2.6.20-16.29_i386.deb is there instead, i wonder have they upgraded to the latest linux-image before installing build-essential
<Hobbsee> i've already seen one of them today
<geser> linux-source-2.6.20 | 2.6.20-16.29 | feisty-security | source, all
<geser> I guess that it's an outdated package lists
<Hobbsee> the fact that there's been 2 of them...
<Hobbsee> it's not in new...
<geser> I've checked the Packages.gz on for feisty-security and -16.29 is referenced there
<AlinuxOS> doko, ping
<Nafallo> will Dells internal WWAN-thingies be included in the deal with them so that it might even work if I order one? :-)
<ijuz__> fast umts would be cool
#ubuntu-devel 2007-07-08
* Hobbsee waves
<Mithrandir> an Hobbsee!
<Hobbsee> it's a Mithrandir!
<Mithrandir> indeed, it is.
* Hobbsee hugs Mithrandir 
* Mithrandir hugs Hobbsee back
<Hobbsee> Mithrandir: are you still in norway, or in london now?
<Mithrandir> how's your sunday afternoon?
<Mithrandir> leaving for London this early evening.
<Hobbsee> Mithrandir: well, i was working.  so...
* Hobbsee had one guy telling her she was cute.  *shrugs*
<Hobbsee> and it was quiet - hooray!
<Mithrandir> sounds good.
<Mithrandir> being told you're cute is nice though?  As long as it's done in a nice and polite fashion.
<Hobbsee> sure.  as long as there isnt a look in the teller's eyes of "oh i wish i could date you" or worse. 
<Mithrandir> yup
* Hobbsee has now changed her real name on her client, to attempt to reduce harassment.
<Hobbsee> will see how well it works
<Mithrandir> you have?
<Hobbsee> (or at least, it'll change when i reconnect)
<Mithrandir> ah, ok.
* Hobbsee bashes all the harassers with a large hammer.
<Hobbsee> Mithrandir: do enjoy london. i'm envious of you :P
<aquo> hi
<aquo> i have created a debbootstrapped minimal ubuntu in a directory
<aquo> is there a way to give a parameter to the initrd-image to use this directory for pivot root?
<|Cordyce|> tftpd doesnt show up in ps list after ive installed it and ran it. why might this be? not using inetd
<Mithrandir> |Cordyce|: please, this channel is not for support, try #ubuntu
<|Cordyce|> they are clueless
<|Cordyce|> had a hard time even getting them to respond
<pitti> hey Mithrandir 
<Mithrandir> try asking a question on the answer tracker, then.  Asking for support in here is inappropriate in any case.
<Mithrandir> hiya Martin
<|Cordyce|> what is answer tracker
<Mithrandir> https://answers.launchpad.net/
<Fujitsu> Can somebody with appropriate superpowers please check what ate all sparc binaries for dcc 1.3.42-4build1?
<cjwatson> aquo: I don't think that's possible with current initramfs-tools without some additional hacking
<cjwatson> Fujitsu: nothing as such - but for some reason the cron.daily that was busy processing it seems to have got stuck
<cjwatson> so it's actually in the archive on drescher but not mirrored
<Fujitsu> cjwatson: Ah, right. So LP is right when it says it's published.
<cjwatson> yeah
<Fujitsu> cjwatson: Thanks for looking at that. Any idea when it'll be resolved?
<cjwatson> I'm sorting it out
<Fujitsu> Thanks.
<cjwatson> Fujitsu: I've killed the hung process, so with any luck the next cron.daily will proceed normally, and those binaries should be visible in maybe three-quarters of an hour
<Fujitsu> cjwatson: Right, thanks.
<cjwatson> if they aren't, wait another 15 minutes or so beyond that and then ask me again
* Fujitsu wonders how it can take so long.
<cjwatson> cron.daily doesn't start until :03
<cjwatson> normally it would finish around :30 or so
<Fujitsu> I thought it was around :40, but that's still a rather long time.
<Fujitsu> Anyway, thanks for looking into that.
<cjwatson> mm. a lot of it's (1) apt-ftparchive and (2) death row processing (which needs to walk timestamps in the pool, IIRC)
<Fujitsu> Doesn't it have a table it can look death row candidates up in?
<cjwatson> actually, yeah, looking at it, it does seem to be a honking great SELECT
<Fujitsu> Still, that's surely only... 5 architectures * 22000 binaries * 4 releases + sources... I guess that's a few.
<cjwatson> I'm not sure, could be insufficient db indexing, could be badly optimised SELECTs so that it has to read big wodges of stuff into python
<cjwatson> I'm not enough of a postgresql expert to be able to tell
* Fujitsu decides to leave the LP deep magic alone.
<Hobbsee> greetings all
<ajmitch> greetings Hobbsee 
<Hobbsee> :)
<Fujitsu> Hi Hobbsee.
<Hobbsee> hi Fujitsu, ajmitch 
* Fujitsu hopes cron.daily finishes this time.
<Hobbsee> it wont.  it hates you
<StevenK> Heh
<Fujitsu> Of course, my very evil dcc sparc binaries caused it choke.
<cjwatson> Fujitsu: you're quite right - there's a clear inefficiency there. I'm writing a mail to the launchpad list now with an analysis and a suggested patch
* Fujitsu wonders how the heck he could have identified a clear inefficiency without having any significant idea of what it does.
<Fujitsu> cjwatson: And it seems to have not completed this hour either.
<Nafallo> *s*S
<Nafallo> -S
<Fujitsu> cpr
<Fujitsu> Oops.
* Fujitsu attacks the kitten.
* Hobbsee rescues the kitten, and demands that Fujitsu do some revu'ing.
<cjwatson> Fujitsu: no, it worked fine this time
<pochu> slomo: liferea has released 1.4~rc1. The major feature in 1.4 is comments in the feeds are now displayed. I'm using it, and it seems stable here. Since there are still more than 3 months for Gutsy's release, do you think it's a good idea to upload it, so we can test and debug it? Or better wait for the final release?
* Nafallo stops playing music for his neighbors :-)
<Fujitsu> cjwatson: I can't see those sparc binaries on archive.u.c.
<Nafallo> pochu: when is the final release? :-)
<cjwatson> Fujitsu: I think the mirroring must be still in progress or something
<cjwatson> oh, hmm, the Packages files for sparc still say -4
<Fujitsu> cjwatson: Ah, I normally see it done by about 20 minutes ago.
<cjwatson> what the hell is going on?
<pochu> Nafallo: as soon as there are no major bugs ;) Probably in a couple of weeks or so.
<Fujitsu> That's... odd. So maybe it did get eaten?
<cjwatson> well, no, the binaries ARE on disk
<Nafallo> pochu: well, it IS development version :-P
<Fujitsu> But apt-ftparchive didn't pick them up?
<Nafallo> pochu: but yea, wait for slomo :-)
<cjwatson> there was nothing to publish this time round, so apt-ftparchive wasn't run
<Fujitsu> Haha.
<cjwatson> I reckon that after I killed cron.daily, it didn't put the new dists tree in place
<pochu> Nafallo: maybe we should wait for at least an rc2...
<cjwatson> so it needs another real item to publish to get back in sync
<Fujitsu> cjwatson: Process the sync queue :P
<slomo> pochu: ask them if the final release will definitely be ~2 weeks before gutsy release... and then let's upload it :)
<Nafallo> pochu: you might want to build one, throw it around to some more people and make them report if it's stable for them :-)
<StevenK> cjwatson: If you want to kick something in, sync kwave from incoming.d.o, it's one more nail in libflac++5's coffin. :-)
<Nafallo> pochu: /me and slomo are such people that will want to try it out ;-)
<cjwatson> Fujitsu: not on a Sunday :P
<cjwatson> I can do one though ...
<Fujitsu> cjwatson: Hence the `:P'
<Hobbsee> cjwatson: bah.  i'ts almost mondya
<Hobbsee> hell, wait 55 mins, then it really is monday.
<StevenK> In which timezone?
<StevenK> Oh, right. NZ.
<Hobbsee> nz, i believe
<pochu> Nafallo, slomo: http://emilio.pozuelo.org/~liferea/liferea_1.4~rc1-ubuntu1_i386.deb ;)
* Nafallo grabs
<slomo> pochu: thanks :)
* Fujitsu whispers `PPA'
<slomo> pochu: just tell me when upstream promised to release early enough ;)
<pochu> slomo: they told me it might need a couple of RCs more, but that they will try to release them every week. So 2 RCs * 1 week = 2 weeks :)
<Nafallo> Fujitsu: server? :-)
<Nafallo> sabdfl: morning Mark :-)
<slomo> pochu: good, source package is at the usual place?
<sabdfl> hey Nafallo
<Nafallo> sabdfl: how's life? :-)
<sabdfl> good! off to wimbledon now :-)
<realist> lucky you!
<Nafallo> nice :-)
<cjwatson> Fujitsu: inefficiency> well, you got me to stop assuming that it was slow because it was walking the disk
<cjwatson> StevenK: done
<Fujitsu> cjwatson: Ah, right. I didn't think it would be /that/ stupid.
<cjwatson> (kwave)
<Fujitsu> cjwatson: It has missed this run, hasn't it?
<pochu> slomo: to upload to ubuntu? I have to make a couple of changes (e.g. remove changelogs and that...)
<cjwatson> Fujitsu: yeah
<slomo> pochu: yes, this evening then :) bbl
<pochu> slomo: ok, will upload to it soon. Thanks!
<StevenK> cjwatson: Ohh, thanks!
<Hobbsee> hi persia 
<persia> Hi Hobbsee
<yaccin> didnt somebody yesterday say, that there were new kopete packages later that day? ^^
<Hobbsee> yaccin: not here they didnt, and i said that i'd fix it
<Hobbsee> for gutsy, at least.
<Hobbsee> however, i was working on my paid job today, so i may not be doing as much ubuntu stuff tonight.
<Hobbsee> seeing as i take breaks occasionally - especially when it's not in the european working week, which means it's quiet here :)
<pochu> slomo: done :) http://emilio.pozuelo.org/~deb/
<yaccin> oh only for gutsy :/
<yaccin> hmm can you tell me, how i can fix it on feisty? :D
<Hobbsee> well, i'ts a pain to build for multiple releases for every patch
<Hobbsee> sure, take the patch, apply it to the feisty source, build it
<yaccin> i know how to compile stuff, but i dont know where i get the fixed sources
<yaccin> or how to apply a patch :D
<yaccin> but if you can tell me, where i can download that stuff, ill try :)
<yaccin> oh... and is checkinstall fixed or still buggy 
<yaccin> if it is ill use the edgy-version
<Hobbsee> checkinstall is always crap.
<yaccin> but i dont know any other programms to build packages :/
<yaccin> and id love to set up a repo for the packages ive done so far, but i dont know how :(
<Hobbsee> what i'd like to do is go and triage some kopete bugs, send them upstream, etc, and get patches for more bis
<Hobbsee> *bits
<Hobbsee> hi pygi 
<pygi> heya Hobbsee 
* Hobbsee wonders when mvo gets back.
<mr_pouit> pygi: hey! are you working on brasero ftbfs? :P
<yaccin> Hobbsee: can you tell me, where i can get that patch? or is the patch already in the sources from kopete.kde.org?
<pygi> mr_pouit, yea, I'm on it
<Hobbsee> yaccin: it's the one linked on the bug report, in svn
<pygi> mr_pouit, I'll upload a new version tomorrow
<Hobbsee> it's also the attachment before the SVN commit, i think
<pygi> mr_pouit, is 0.6.0 out?
<mr_pouit> pygi: ok (please check if the patch properly applies before :P)
<mr_pouit> pygi: afaik, no
<pygi> mr_pouit, ok, and I'll check everything, ofcourse
<Fujitsu> Yay, apt-ftparchive ran again :)
<pygi> mr_pouit, I know what's the problem anyway ^_^
<mr_pouit> ^^
<hikenboot> greetings all-- cat packages_removable-final.txt | cut -f 1 --delimiter=, |  xargs apt-get remove --purge causes all the listed packages to be removed at once. I would like to remove each one and prompt between each package listed so I can see which one is removing packages I do not wish---any idea how?
<cjwatson> xargs -n1
<cjwatson> apt-get will prompt whenever more than just the package you asked for is to be removed
<cjwatson> apt-get -s if you just want to simulate each in turn
<hikenboot> so if I am feeding it from a list that will do one at a time?
<cjwatson> yes
<hikenboot> thanks
<cjwatson>        --max-args=max-args, -n max-args
<cjwatson>               Use at most max-args arguments per command line.  Fewer than max-args arguments will be used if the size (see the -s option) is exceeded, unless the -x option is given, in which  case  xargs
<cjwatson>               will exit.
<hikenboot> thanks!
<hikenboot> i thought I would have to do it with a for loop some how
<yaccin> ok
<yaccin> i build kopete
<yaccin> and the bug is gone
<yaccin> but also is the option to hide the scrollbar -_-
<StevenK> cjwatson: I know it's weekend and all, but if you feel so inclined would you mind checking why kwave hasn't got any builds at all, even though the source was published 2 hours ago?
<Hobbsee> StevenK: he's probably on a plain - or waiting at the airport, or something
<StevenK> "plain", you say?
* StevenK grins, and ducks.
<Fujitsu> StevenK: Because soyuz is doing crazy things? cron.daily was having issues with publishing them to the outside world, so I'm sure it'll find an excuse to not publish sources internally.
<Hobbsee> er, plane
* Hobbsee beats StevenK 
<StevenK> Ouch!
<StevenK> Fujitsu: Mmmm, more Soyuz breakage fun.
<Fujitsu> That's right :)
<geser> was there a LP rollout again in the last days?
<Fujitsu> geser: We're about half way between releases at the moment, so nought but cherrypicks.
<Kmos> https://launchpad.net/+builds/kohnen -> it's normal the status of this machine
<Kmos> ?
* StevenK patches muse, and waits for roughly 25 minutes to see whether it builds or not.
<StevenK> Kmos: It's hppa, which was last bootstrapped for dapper.
<Fujitsu> Kmos: It's hppa, and it's likely that nobody really cares during the weekend.
<StevenK> If you look, you'll notice that no builds for hppa get registered.
<Fujitsu> Particularly due to the fact it'll only dodapper-updates, yes.
<Kmos> Fujitsu: so any admins to fix it.
<Kmos> that's bad
<Hobbsee> Kmos: not.  on.  a.  weekend.
<StevenK> Why does it fixing? It's *allowed* to be idle.
<Fujitsu> Kmos: And particularly not because it's hppa.
<StevenK> need fixing, even
<Fujitsu> It might get used every few months.
<StevenK> It's not broken, ergo, it doesn't need fixing.
<StevenK> It's not rocket science.
<Kmos> :)
<Tuxist> hi
<Tuxist> why you build openldap packages without sql support ?
<realist> Perhaps it's not a typical use case
<Hobbsee> !weekend
<ubotu> It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<realist> Hobbsee: or a mailing list, bug reporting?
<Hobbsee> realist: that too
<geser> Hobbsee: it looks like I got apt building
<Hobbsee> geser: yay!
<geser> the last missing build-depends is docbook
<geser> Build-Depends: debhelper (>= 5.0), libdb4.4-dev, gettext (>= 0.12), libcurl4-gnutls-dev (>= 7.15.5), automake, xsltproc, docbook-xsl, xmlt
<geser> o, docbook
<geser> broken line-wrap
<geser> that's the B-D line it tested the last build attempt
<Hobbsee> automake or autoconf?
<StevenK> automake Depends on autoconf
<Hobbsee> the last one died over autoconf, i thought
<Hobbsee> ah
<geser> you need both but automake installs autoconf, so I wouldn't list it
<Hobbsee> ah right
* Hobbsee tries
<hackeron> when is asterisk going to be fixed in gutsy? (any why was libcurl3 deprecated without testing what it breaks)
<StevenK> asterisk was fixed 2 days ago.
<StevenK> And actually, it's the other way around.
<Hobbsee> geser: holy hell, this actually builds
<StevenK> Heh, upload it, quick.
<Hobbsee> i'd prefer to test first...
<hackeron> StevenK: errr, not here -- complains about libcurl3-gnutls
<StevenK> Then I suspect your mirror is out of date.
<geser> hackeron: does it perhaps want to deinstall OO.o?
<hackeron> I tried 4 mirrors already
<StevenK> Oh, that could be it.
<StevenK> Openoffice.org is still waiting to be fixed.
<geser> was it uploaded today?
<Nafallo> was about to say that :-)
<StevenK> That's a question for calc.
<Hobbsee> it wasnt
<Hobbsee> doko had some changes he wanted to make
<hackeron> geser: err, no, apt doesn't mention openoffice
<Nafallo> hackeron: does here.
<geser> StevenK: there was an OO.o upload today, amd64, powerpc and sparc are building now and i386 failed to build
<Nafallo> language-support-sv, libcurl4-gnutls, openoffice.org*, python-uno :-)
<hackeron> all it says for me is these are being kept back: apt apt-utils libcurl4-gnutls vorbis-tools
<hackeron> when I apt-get install libcurl4-gnutls it says libcurl3-gnutls unavailable
<geser> try apt-get install libcurl3-gnutls
<gnomefreak> hackeron: its not ready to be updated yet
<hackeron> geser: hmm, yeah, that works openoffice removed
<hackeron> ok, I compiled my own asterisk and openoffice still works :)
* Hobbsee uploads apt
<Mithrandir> Hobbsee: are you uploading all the other bits which depends on it too?
<Hobbsee> Mithrandir: i will, but i thought i had to wait until after it was built
<Hobbsee> Mithrandir: currently, no one's uploaded those other bits anyway, so it's in limbo now
<Mithrandir> yes, I know, and it's made me slightly annoyed that I have bits which are uninstallable. :-P
<Hobbsee> Mithrandir: haha.  i didnt upload it the last 2 times.
<Hobbsee> Mithrandir: "you could just...you know...fix it."
<Mithrandir> yes, I could, if I had wanted to work even more than I already do.
<Mithrandir> :-P
<Hobbsee> this is true :P
<Mithrandir> and I didn't say I was annoyed at you, just that I was annoyed at it being uninstallable
* Hobbsee wonders if you recognised the quote
<Hobbsee> hey now, my key was nowhere near it.  it's got nothing to do with me.  *holds hands up*
<Hobbsee> mine was only near the bzr section
<Hobbsee> :P
<Mithrandir> unsure what the original source for the quote was
<Hobbsee> twas you.
<Hobbsee> about beryl-crack, iirc.
<Hobbsee> about all the work arounds they were using
* Hobbsee has a brain for detail, remember?
* Hobbsee prods the australian shoestring.  upload faster!
<Mithrandir> ah, ok.
<Hobbsee> Mithrandir: no, i'm not strange.  i dont think.
<desrt> raise hands for guadec attendence
<Mithrandir> only slightly.
<Hobbsee> Mithrandir: well, i'm insane enough to be involved in this, so...
<Mithrandir> desrt: I'm coming on Monday and Tuesday, possibly Sunday too, at least Sunday evening.
<Hobbsee> hiya desrt!
<Mithrandir> Hobbsee: strange != insane. :-)
<desrt> Mithrandir; nice
<geser> I could prepare some debdiffs for apt's rdepends after Hobbsee uploads apt 0.7.2ubuntu6
<Hobbsee> geser: it's OK - i ahve them here
<desrt> Mithrandir; seems that you will miss my talk on sunday :(
<desrt> and my talk on thursday too :p
<Mithrandir> desrt: I can buy you beer instead.
<desrt> mmmm.  beer.
* desrt considers a sober guadec
<Hobbsee> Mithrandir: heh
<Hobbsee> desrt: not possible.  surely
<Hobbsee> oh come on apt...upload...
<desrt> Hobbsee; i dunno
<Mithrandir> desrt: let's smash that pondering. :-)
<desrt> Hobbsee; it might be possible if i immediately go back to the hotel after the last talk
<Hobbsee> haha
<desrt> hanging around in the common area outside of talks has a tendency to get you drunk
<Hobbsee> well, it was possible to mostly not drink at UDS, so...
<Mithrandir> Hobbsee: but we got even you to drink a tiny bit.
<Hobbsee> yeah.  *shudder*
<Mithrandir> shudder?
<desrt> cheap drunk?
<Hobbsee> Mithrandir: i'm sure you wouldnt want to see me drunk
<Mithrandir> it was decent bubbly wine. :-P
<Hobbsee> sure.  i just dont like the taste of wine :P
<Hobbsee> desrt: i can go a bit crazy at times.  also happens with large amounts of coke.;
<desrt> well
<desrt> cocain is a bit more of a serious matter than alcohol
<Hobbsee> of the red can variety... :P
<desrt> gawd!
<desrt> you snort it by the can-full?
<desrt> hardcore
<Hobbsee> hahaha
<Hobbsee> oh dear
<Hobbsee> or of the glass bottle variety.  either wya.
<Mithrandir> bottles or cans, you snort either?
<Hobbsee> :P
<Mithrandir> doesn't the glass hurt when it hits the nose?
* desrt has had glass bottle coke exactly once
<Hobbsee> not if you do it right.
<Mithrandir> also, bubble in nose => badness.
<Mithrandir> bubbles, even
<desrt> it was delicious.
<Mithrandir> ooh, plane.
<desrt> Mithrandir; what hotel are you staying at?
* Hobbsee removes the plane.
<Hobbsee> NOT YOURS.
<Mithrandir> Hobbsee: that's ok, I'm only going to use it for a little while.
<Hobbsee> Mithrandir: not even yours to borrow.
<Mithrandir> desrt: unsure, the 35 one on the accomodation page.
<desrt> etap
<Mithrandir> Hobbsee: I'm just borrowing a seat.
<Mithrandir> yup, that's the one.
<desrt> me too :D
<Hobbsee> not allowed either.
<Mithrandir> Karianne's coming for Friday, Saturday and Sunday morning.
<Mithrandir> bad Hobbsee!
* desrt doesn't know karianne
<Hobbsee> bah.  send her out here, i want to meet her :)
<Mithrandir> desrt: my wife, simira in here.
<desrt> cool
<Mithrandir> Hobbsee: just come to london.  Or Norway, I'm sure we could spare you space on the couch
<desrt> what does she hack on?
<Hobbsee> Mithrandir: tempting.  tempting.  and it would be warm, too.
<Hobbsee> Mithrandir: i wish i could come to london.
<desrt> Hobbsee; norway?  warm?  heh.
<Mithrandir> not much, she helps out with the norwegian ubuntu community and has done some translations.
<Hobbsee> desrt: well.  it's winter here.  it's summer there.  it's supposed to be somewhat warm!
<desrt> Hobbsee; "winter" in australia is a ficticious concept
<Hobbsee> desrt: heh
<desrt> it goes down to what?  15?
<Hobbsee> desrt: and not all of us actually hack much, you know :P
<Hobbsee> 8 or so.
<Hobbsee> during the day
<desrt> oo.  that's cold.
<Hobbsee> goes down to 2C, or 0C, at night sometimes
<Hobbsee> depends where you are
<desrt> ya.  we get -40 in canada.
* Hobbsee shudders
* Hobbsee would not survive.
<desrt> i shudder too.  we all do. :p
<Hobbsee> unless i was piled in jackets, or something
<desrt> you learn the value of owning a very good coat
<Hobbsee> would be more than one, i can tell you...
<desrt> eh.  canadian coat construction techniques are quite a lot better than you've probably ever seen :)
<Hobbsee> mmm.  i want one for here, then.
<Mithrandir> Hobbsee: you must come to Norway and try my sheep's coat then.  It's like a couple of sheep you wrap yourself in.
<desrt> we also have toques
<Mithrandir> very comfy.
<Mithrandir> very warm
<Hobbsee> Mithrandir: hehe.  bring it with you to boston, if i get there.
<desrt> !!
<Hobbsee> might be a bit big for me though
<desrt> boston is gonna be wild
<Mithrandir> Hobbsee: maybe, but it's slightly heavy.  Like 10kg or so.
<desrt> it's close enough that i might be able to roadtrip down with some friends
<Hobbsee> Mithrandir: way cool.  then i'd be harder to pick up!
<Mithrandir> true dat
<Hobbsee> which would be good.  less temptation for people to try to do mean things to me, like break me.
<Mithrandir> we could still throw you in the pool
<Hobbsee> you wouldnt, though.
<Mithrandir> I'm much too nice a person.
* Hobbsee hides her still-somewhat-stuffed wrist away from all of you, and looks around warily.
* Mithrandir enters the aircraft.
<Hobbsee> Mithrandir: did you feed the carrier pigeons before you got on?
* desrt feels very much outside of an inside joke
<Hobbsee> desrt: clearly you never read elkbuntu's blog, after UDS
<Hobbsee> desrt: carrier pidgeons went on strike from singapore
* elkbuntu tickles Hobbsee
* Hobbsee tickles elkbuntu back :)
<Hobbsee> oh yay, apt finally uploaded.!
<superm1> Hobbsee, is apt what was breaking debootstrap lately?
<Hobbsee> dont remember.  quite possible
<superm1> hopefully:).... was getting a whole lot of these W: Failure while configuring base packages.  This will be attempted 5 times.
<superm1> ah and looking a little closer, it was  libapt-pkg-libc6.5-6-4.4 which wasn't installable - i anticipate that was a binary result of the apt source package you uploaded?
<Hobbsee> yeah, that's to do with apt
<superm1> great! :)
<Hobbsee> superm1: all of the apt-related stuff (synaptic, aptitude, adept, etc) needs to be rebuilt each time a change is made to apt, from what i understand
<superm1> Hobbsee, is that sort of thing going to be automatic after your apt upload, or will each of those need to have a bug filed to be rebuilt as well?
<Hobbsee> superm1: wasnt planning on filing bugs for it
<Hobbsee> superm1: was planning to just update them in the morning
<superm1> oh right your core-dev, you can just bump the changelog and reupload :)
<Hobbsee> it's all listed on gutsy_problems anyway
<Hobbsee> yeah :)
<Hobbsee> well, you need to be in core for apt, too
* superm1 obviously needs to eat this morning yet - - should have made that connection in the first place
<Hobbsee> hehe
<stgraber> openoffice is building for 14 hours now :)
<geser> it failed in i386, so a fixed upload will be necessary
<stgraber> right, but I'm running amd64 :)
<stgraber> btw, I don't really see why the build failed on i386 and not on the others as well ... (looking at the log)
<geser> stgraber: i386 builds also the arch all debs
<geser> the others don't
<stgraber> argh
<geser> so you won't have much use for the amd64 debs if they need an arch all deb from this upload
<stgraber> and I think that's the case for OOo :(
<hunger> the apt-stuff seems to be out of sync with everything that depends on it.
<Hobbsee> hunger: i know.  i'll fix it in the morning
<Hobbsee> more to the point - later in the morning
<hunger> Hobbsee: Great. Thanks!
<Hobbsee> hunger: having apt working is not very fun at all, really...
<Hobbsee> i'ts much better if it's segfaulting!  :P
<geser> Hobbsee: isn't it soon morning in Australia? :p
<Hobbsee> yeah....
<hunger> Hobbsee: Who needs apt anyway? Everybody just uses aptitude/synaptic/adept anyway;-)
<Hobbsee> geser: i was going to get better in when i went to bed, after UDS.  unfortunately, the european day fits in far better if i stay up, then go to bed at some late hour
<geser> :)
<Hobbsee> besides, it's uni holidays at the moment
<Hobbsee> so my only real time constraint is work, and any meeting people around here that i do
<Hobbsee> however, it's time for bed.
<geser> sleep well
<Biagi> http://biagi.miniville.fr/sec
<desrt> don't visit that link.  it's a referal scam.
<desrt> visit this one instead: http://desrt.miniville.fr/
<desrt> :p
<desrt> it's like an online simcity... people have to visit your page in order for your population to grow.
<bhale> meh
<ion_> Well said.
<desrt> pretty boring, i think
<desrt> as far as i can tell you can't actually do anything except watch people come
<ion_> Well, you also get to annoy people.
<desrt> like any good web 2.0 property
<jdong> desrt: that's how the population grows? My mommy told me when two people really love each other, they give each other a "special hug"
<sivang> hi folks
<sivang> so, how dangerous is it to dist-upgrade to gutsy? 
<geser> sivang: a curl tranisition is ongoing (OO.o is still missing) and now also an apt transition
<geser> so this is not the best time for an dist-upgrade
<sivang> geser: right
<sivang> geser: why are the transitions happening ?
<sivang> geser: (I've been away for a while, now catching up)
<geser> curl is a long story
<sivang> geser: switching to a different implementation ?
<geser> curl is a libcurl3 -> libcurl4 -> libcurl3 transition
<geser> and apt changed one of the provided libs, so everything depending on it needs to be rebuild
<geser> usual library transitions, nothing special
<sivang> geser: so bump up to a new version and then a downgrade ?
* sivang tries to understand the rationale
<minghua> sivang: curl is a upstream thing
<ion_> AFAIK upstream bumped the library version, but the ABI didnt really change, so now libcurl3 contains the newest package with a symlink from libcurl.so.4 to .so.3.
<ion_> Feel free to correct me. :-)
<geser> Debian managed to restore the API/ABI as it cause to much pain in unstalbe -> testing transitions and moved back to libcurl3
<sivang> ion_: thanks, that explains it
<sivang> darn, I have to run , see you tomorrow folks
<sivang> geser: just before I run, so we just suck in the transition from debian or do we need to do stuff ourselves ?
<ion_> The libcurl3 changelog in gutsy says: -6ubuntu1: Merge from Debian unstable; -6ubuntu{2,3}: ..., -6ubuntu4: Completly revert the two previous changes
<sivang> ion_: thanks
<sivang> laters
#ubuntu-devel 2008-06-30
<beDrung> hi gnomefreak
<gnomefreak> beDrung: hi was just talking about you :)
<gnomefreak> beDrung: whats up with licenses on the 2 extensions?
<gnomefreak> i didnt know you talked to asac so im lost on it i grabbed it but only got first block of license in the md5.js
<beDrung> http://revu.ubuntuwire.com/revu1-incoming/pwdhash-0806221510/pwdhash-1.5/debian/copyright
<beDrung> all files have the same licence, except md5.js
<beDrung> i am in contact with the upstream author. he will add a licence file to the source package. he said, that the package uses bsd as licence.
<gnomefreak> beDrung: im guessing its a clause 2 license?
<beDrung> clause 3 licence (e.g. http://revu.ubuntuwire.com/revu1-incoming/pwdhash-0806221510/pwdhash-1.5/chrome/stanford-pwdhash/content/domain-extractor.js )
<gnomefreak> beDrung: ah perfect
<beDrung> and md5.js says: * Distributed under the BSD License
<gnomefreak> waiting on upstream to add the files?
<gnomefreak> beDrung: yeah i know it didnt tell me anything i wanted to know
<beDrung> yes, he wrote june, 26 that he will do it. so i am waiting.
<gnomefreak> beDrung: ok thanks for update :)
<beDrung> and for htmlvalidator: someone should check all files for the licence.
<beDrung> if i remember correct opensp uses bsd licence and tidy uses mit
<gnomefreak> beDrung: ok i will ask someone to look into it or i will when i get caught up
 * gnomefreak gone good night
<mcquaid> is it no longer required having an fstab entry for ones cdrom/dvdrom drive?
<persia> mcquaid: The presence or absence of such an entry will affect behaviour of the system.  Not having an entry is current recommended.
<mcquaid> ok thx.  since going to hardy from gutsy i can't successfully burn a data dvd.  failed in brasero, gnomebaker and k3b. trying to figure it out
<mcquaid> i currently have an entry, will remove it.  but i find it a stretch thinking that could cause burning issues, but i'm not sure
<mcquaid> i asked about this when i first upgraded to gutsy, that there should be a way to generate a new fstab post install
<StevenK> persia: HAL handles it automagically?
<persia> StevenK: Well, HAL provides the notification that media is available.  I believe that then is available over dbus, and the relevant system (gnome-volume-manager for GNOME) then performs a user-mount on the device in a new directory in /media.
<StevenK> persia: Much like it does for USB keys and the like.
 * persia is fuzzy on the details, as this was last investigated in Edgy or so
<persia> StevenK: Exactly the same mechanism.
<persia> This also works for any fixed device not in a blacklist that happens to be present in the system.  If a user connects a new hard drive to the SATA bus, and it is formatted with an acceptable filesystem, it will be mounted in /media at next boot.
<persia> s/boot/login
<persia> I think there is some permissions layer, due to a complaint that anyone logging in automatically got access to NTFS/HFS+ drives in dual-boot configurations, but don't remember the details.
<persia> (and modern HFS+ is especially annoying, as it presents UNIX userids, etc. which then further confuse permissioning if not aligned)
<StevenK> persia: You can have exactly the same problem with ext3 on a USB key, or NFS.
<persia> StevenK: Well, for NFS I rarely consider it a "problem", but yes, any UNIX FS that gets pulled by the /media mounting gets confusing.  It seems optimised for FAT, which might be right in some cases, but isn't reliably always correct.
<wgrant> (it's actually Nautilus which does volume mounting in GNOME now)
<persia> So what does gnome-volume-manager do?
<wgrant> Any device that isn't a volume, IIRC.
<persia> Right.  All the more reason for programs to have names that are completely unrelated to function.  This wouldn't be confusing it this was gnome-frobnicator.
<persia> s/it this/if it/
 * StevenK chuckles
<mcquaid> if i remove the fstab entry for my cdrom, would it stil lbe accessible outside gnome, like say in icewm?
<wgrant> persia: It did do volumes until Hardy, I believe.
<persia> wgrant: It did.  I'm just amused, as between Nautilus and the HID layer, there aren't a lot of devices left to be handled by g-v-m.
<wgrant> System->Preferences->Removable Drives and Media shows a few.
<wgrant> They're neither removable drives nor media, though.
<persia> Well, digital cameras might be considered that: many can be represented as volumes.  Input devices is sadly lacking in several classes of device (joysticks, MIDI, 6D CAD controllers, "gaming" pads, sensors, etc.), and this panel doesn't actually have any influence over the activation.  PDAs are just an odd inclusion, and we've a whole separate Printer system.  Oh well.
<persia> Maybe that can go away entirely for intrepid :)
<StevenK> persia: Maybe GNOME are hoping printers will just quietly go away :-P
<persia> StevenK: I guess, although printers are the part of that which I'm least likely to actually use (my printer has a parallel port).
<persia> I prefer gizmod for input devices, use usbnet for PDAs, and would expect scanners and cameras to be accessible from within relevant applications, rather than taking action on device detection (would I have to close the scanning app every login if I had a scanner attached to the workstation?)
 * StevenK sighs at bzr merge
<lifeless> StevenK: ?
<StevenK> lifeless: It is moving directories around, shifting files around and generally making a mess of my working tree
<lifeless> StevenK: arbitrarily, or because whomever you are merging from did that?
<StevenK> lifeless: Because it thinks there are conflicts
<StevenK> I can't find said conflicts, or why it thinks they do ...
<lifeless> StevenK: what type of conflicts is it claimin
<StevenK> Text conflicts
<lifeless> StevenK: text conflicts ondirectories?
 * StevenK manages to crowbar the working directory back into a state that looks okay
<StevenK> lifeless: I can point you at the two repositories, and tell you the merge command I ran, if that would help explain it?
<lifeless> StevenK: yes, though if they are huge I'd rather see you pastebin the relevant stuff
<lifeless> StevenK: anytime a merge is bad, if you think bzr should have been able to do better (if you can't understand teh conflicts and why) - please see #bzr immediately
<lifeless> feedback is valuable
<StevenK> lifeless: The repos are on LP and are small
<YokoZar> Hmm, Intrepid Alpha 1 amd 64 doesn't log into gnome for me in vmware
<YokoZar> As a fresh install
 * TheMuso wipes sweat from his forehad after finally uploading initramfs-tools merge for intrepid. That was a big one.
 * RAOF gives props to TheMuso for working on the bombs :)
<TheMuso> RAOF: If you track intrepid-changes, I think you'll see what I mean.
<RAOF> Not yet.  I track via the rss feed, and it's not updated for me yet.
<TheMuso> RAOF: Right.
<wgrant> It'll be another minute until it's accepted.
<nxvl> there is a rss feed of -changes?
<wgrant> Unofficially.
<wgrant> TheMuso: Nasty merge, indeed!
<StevenK> TheMuso: *Daaamn*
 * wgrant thinks that TheMuso needs to now file a few dozen bugs in Debian to merge the changes.
<wgrant> That would be even more fun.
<TheMuso> wgrant: Thats the plan, but tomorrow. My head is in no shape for complex thought patterns atm.
<nxvl> is there any way to use any chroot environmet or something to build packages in other architectures?
<TheMuso> nxvl: You would have to set up a cross-compiler.
<nxvl> i need to fix a problem on amd64 and i only have an i386 machine
<RAOF> That's more difficult :)
<nxvl> TheMuso: did you know if there is a wiki page about that?
<TheMuso> nxvl: No, I am not aware of such a page.
<RAOF> Actually, you could probably do some virtualisation magic.  Wasn't there a qemu frontendything?
<nxvl> RAOF: virt-manager
<nxvl> i'm using ppa, but it's kind of slow, and no the best way to do it
<RAOF> Well, that'd work.  I actually meant a qemu frontend around pbuilder.
<RAOF> qemu-x86-64-buildpackage
<StevenK> TheMuso: "Fire bad, tree pretty" ?
<RAOF> (May or may not exist)
<wgrant> nxvl: Probably best to convince somebody else to do it.
<TheMuso> StevenK: ??
<wgrant> Or get access to an amd64 machine.
<StevenK> TheMuso: It's a Buffy quote.
<TheMuso> StevenK: oh.
<RAOF> Right.  I've been known to hand out access to my amd64 box.
<StevenK> TheMuso: Giles asks Buffy a complex question after a big-bad fight and her response was "My thought patterns are only capable of 'Fire bad, tree pretty'"
<TheMuso> StevenK: hahaha right.
<nxvl> also i have another problem
<nxvl> i don't know why the build process is deleting a directory called "build" which i don't know why ships with upstream release
<nxvl> and it's making my package fail to build twice in a row
<nxvl> is there any way to search for packages that depends on others?
<cody-somerville> nxvl, you can list reverse dependencies if thats what you mean
<persia> nxvl: apt-cache rdepends covers the simple case.  debcheck has more complex cases.
 * nxvl HUGS cody-somerville and persia 
<cody-somerville> :)
<nxvl> cody-somerville: mm
<nxvl> err
<nxvl> persia: it doesn't work
<persia> nxvl: Please supply a referent for "it".
<cody-somerville> nxvl, you'll need to be a bit more descriptive then that :)
<nxvl> i'm trying to find packages that depend on chrpath to use them as examples
<mvo> if you like guis, synaptic can do it too in its filters (and search)
<Hobbsee> mvo!
 * mvo waves
<persia> Ah.  You want reverse build-depends.  For that you need grep-dctrl.
<Hobbsee> mvo: i have a bug for you.
<Hobbsee> mvo: so you might want to run away, instead of waving.
 * mvo considers this
<persia> nxvl: I think it's `grep-dctrl -FBuild-Depends chrpath -sPackage /var/lib/apt/lists/*intrepid_*_source_Sources
<persia> `
<nxvl> persia: there is not apt way to do it?
<nxvl> persia: someone point me to some command some days ago but i didn't write it down, and it's not on my history
<nxvl> :(
<persia> nxvl: BNot for build dependencies.  You could perhaps add something to apt-cache or synaptic, if you wanted.
<nxvl> i will se
<slangasek> TheMuso: how's alsa-lib coming?
<slangasek> TheMuso: I noticed some feedback suggesting there were some problems with the repo you'd set up, are those ironed out?
<slangasek> asac: have you seen my follow-up to bug #210481?  Do you or another member of the mozilla team have time to fix that this week?
<ubottu> Launchpad bug 210481 in firefox "gutsy->hardy upgrade problem" [High,In progress] https://launchpad.net/bugs/210481
<cody-somerville> mvo, when do you guys first start uploading gnome to Intrepid?
<cody-somerville> mvo, as soon as the first alpha or beta is available or just the release candidates?
<mvo> cody-somerville: uploading of the current devel version of gnome has already started, we do it as soon as gnome releases tarballs
<mvo> cody-somerville: seb128 is the lead for this effort and usually a new tarball release goes very quickly into our archive as well
<cody-somerville> Although I know this may be a question you can't answer, do you think that would be a good approach for Xubuntu too?
<cody-somerville> Xfce4 just moved to a time-based release schedule
<mvo> cody-somerville: this is great for testers, they get the new unstable gnome very quickly and easily
 * cody-somerville nods.
<cody-somerville> Well, upstream is worried about or modifications
<cody-somerville> In the past, they have caused problems for them.
<mvo> cody-somerville: it depends a bit on the xfce upstream community and the xubuntu community
<mvo> I think its great if you have man-power (two-three decidated people) making regular updates and feed bugreports back to upstream
<mvo> (that is what the gnome team is doing, also more people :)
<mvo> and it also depends if xfce upstream has a reliable release process
<mvo> that is aligned with our releases dates somewhat
<cody-somerville> They're releasing in september
<cody-somerville> we're releasing in October I believe
<cody-somerville> so I think it'll work
<mvo> but if that is the case, then it can be a great resource for upstream for additional testers (just running it from the livecd for people who are scared of running intrepid entirely)
 * mvo nods
 * cody-somerville nods.
<mvo> you mentioned upstream might be concerned about it earlier?
<mvo> maybe its a matter of explaining that its more of a help than a burden because of better feedback
<mvo> (we do the same for compiz, upload git snapshots into the archive early and upstream likes that a lot)
 * cody-somerville nods.
<seb128> mvo: well, he mentioned that distro changes were an issue
<seb128> not sure what sort of changes they are doing though and why that's an issue
<mvo> hm, those should be discussed with uptream again I guess - what kinds of changes are we talking about?
<seb128> but we try to have a low delta for GNOME
<cody-somerville> It might have been more to do with Xfce4 upstream not getting along well with Jani Monoses
<cody-somerville> Which is a shame : (
<cody-somerville> What was happening was that Xubuntu was shipping SVN with patches, lol
<cody-somerville> And as you know, once a release becomes stable we don't just randomly update it with svn snapshots
<slangasek> cody-somerville: in keeping with tradition, 8.10 will definitely be released in the 10th month of the year; however, in the event of unforeseen setbacks I'm prepared to switch to the pre-Julian Roman calendar
<dholbach> good morning
<persia> slangasek: Please don't: it gets very close to end-of-year stuff, and hurts the immediate blush of SRUs.
<StevenK> slangasek: Bwahaha
<slangasek> persia: er, I hope you don't mean to say you were taking me seriously :)
 * cody-somerville has a number of SRUs to do sadly.
<cody-somerville> I wish I had been able to get them done in time for .1 but work ate up all my time with getting our product ready for the release of the new iPhone
<persia> slangasek: Well, there was 6.06, so I'm yet convinced it's impossible to make such a switch, and you've a better rationale than some.
<seb128> hello dholbach
<dholbach> hi seb128
<mvo> hey dholbach!
<dholbach> hiya mvo
<seb128> hello mvo
<mvo> hey seb128!
<emgent> morning
<halex> moin emgent
<emgent> heya halex
<asac> slangasek: when is 8.04.1 release date?
<slangasek> asac: Thursday
<cjwatson> how goes the certification side of things?
<slangasek> cr3 gave us a clean bill of health, with the exception of one wireless issue which was not a regression vs. 8.04 and remains unresolved
<cjwatson> oh, good news
<slangasek> that was before the last l-r-m change, so I'll ask him today for another run
<asac> slangasek: for 210481 i can include the fix in the security upload that is about to go out
<slangasek> asac: a security upload for ff2?
<asac> slangasek: yes. on Wed is target date
<dholbach> thekorn: can we distinguish between types of descriptions in py-lp-bugs?
<asac> slangasek: all the bits are loaded ... e..g build and ready to be released, but since ffox 2 is in universe I could reupload it (after checking with jdstrand that the builders have cycles atm)
<slangasek> asac: ok, that'd be swell :)
<thekorn> dholbach: sorry, but which types of descriptions do you mean?
<dholbach> erm sorry
<dholbach> thekorn: SUBscriptions :)
<thekorn> dholbach: ok, that's possible but only in the html mode
<thekorn> let me find an example
<dholbach> thanks a lot Markus
<\sh> direct_list=self.bugReport.get_subscriptions_category("directly")
<\sh>         via_duplicates=self.bugReport.get_subscriptions_category("duplicates")
<\sh>         also_notified=self.bugReport.get_subscriptions_category("notified")
<\sh> you mean those subscriptions, right?
<dholbach> ah perfect
<dholbach> thanks \sh
<\sh> dholbach: welcome
 * thekorn is too slooow again
<\sh> thekorn: na...I just have eclipse open with the source ;)
<asac> slangasek: we currently have http://paste.ubuntu.com/23904/ ... i guess that we have to bump that on every security update :/
<asac> or start to use funny versions for ffox updates
<wgrant> Why does it need to conflict with a lower version of itself?
<asac> wgrant: Package: firefox-2
<wgrant> Why does it need to be so strict, even so?
<asac> wgrant: good point
<wgrant> What is its purpose?
<persia> Wouldn't it help force the upgrade case if someone had the ancient package around?
<slangasek> asac: hmm? surely you should just update it once, to (<< $minimal_hardy_version) ?
<Koon> dholbach: you sponsored the pam-pgsql upload for hardy, would you be interested in sponsoring my fakesync for intrepid ? Fixes a security hole.
<persia> (firefox -> firefox-2)
<asac> slangasek: guess << 3
<wgrant> slangasek: That's what I thought.
<slangasek> asac: I think so, yes.
<asac> k. will do that then
<dholbach> Koon: did I? is your fakesync in the sponsoring queue?
<Koon> dholbach: I just subscribed ubuntu-universe-sponsors, following persia's advice.
<dholbach> ok great
<dholbach> I'll triage the quee later on
<dholbach> queue
<Koon> dholbach: thx
<ogra> siretart, hmm, your rss-glx upload wil break al screensavers that have sound (not thatthis is a bad thing, but expect some bug fallout as last uploader)
<ogra> (people like to complain about such stuff)
<persia> ogra: Aren't there already none of those as a result of bug #21507 ?
<ubottu> Launchpad bug 21507 in rss-glx "Disturbing sounds in Skyrocket screensaver" [Medium,Fix released] https://launchpad.net/bugs/21507
<ogra> there are mre than skyrockat afaik and this one just ha the volume set to zero, you can easily swithc it back on
<ogra> *skyrocket
<ogra> persia, i dont really care (especially since my name isnt the last uploader here :) and i gave screensavers to tedg quite a while ago ... ) but there are many people ot there that use xscreensaver for example where you have the opportunity to adjust volume of a single screensaver, they will surely open bugs for that
<siretart> ogra: are you serious with people complaining that their screensaver won't make any noise anymore?
<siretart> that is a so unbelievable silly feature to me that I have to ask this question
<ogra> siretart, the bug abouve definately had the same (less funny though) in the opposite direction, yes :)
<ogra> take over screensavers for a release, you will encounter the funniest bugreports :)
<ogra> siretart, i totally agree with you about the sillyness, that was just a warning that people will surely notice it and complain
<siretart> ogra: I think having openal in universe is way more desireable than having screensavers making silly noises
<siretart> and I'm willing to argue about this in front of the TB
<ogra> is rss-glx realy the only one to use it ? i would have expected some sdl games etc to use it too
<ogra> no need to involve the TB here unless the bugs get to tricky :)
<siretart> ogra: AFAIK all those packages are in universe. if you happen to notice another package in main using openal, please notify me
<ogra> will do so, thanks for caring for the breakage
<persia> ogra: SDL games use SDL sound.  SDL sound can use several backends, openal included.  I believe it uses ALSA by default.
<ogra> (and for tagging your name on the screensavers *G*)
<siretart> and since there is no libsdl1.2debian-openal, sdl is not a problem here
<siretart> ogra: you need openal for games that feature *spacial* sound. having a screensaver with *spacial* sound supported is so unbelievably silly to my mind that I cannot express it
<ogra> well, if you want to hear the rockets flying over your head ....
<ogra> :)
<siretart> exactly
<persia> ogra: And at angles, so you hear them getting louder, and in the right direction?  Isn't it easier to code it to just swoop?  Anyway, aren't screen savers supposed to avoid CRT burn-in, while letting your computer sleep?
<ogra> woah
<ogra> http://parker1.co.uk/eternity/
<ogra> we should urgently get these in
<broonie> A lot of people use them because they look pretty :)
 * ogra poders for tedg to wake up
<siretart> persia seems to agree with me :)
<ogra> persia, they were when CRTs showed green text  ... today they are to support global warming :)
<persia> ogra: I had more burn-in on polychromatic CRTs than on monochromatic ones.  I have one CRT that can't get bright enough to use anymore, due to phosphor loss.
<siretart> ogra: do they feature spacial sound? ;)
<sistpoty|work> siretart: rss-glx does
<ogra> siretart, patches accepted, i'm sure :)
<sistpoty|work> siretart: though it imho should play mp3/ogg instead *g*
<slangasek> asac: mmm, I should probably ask here for realtime feedback - what are your plans for bug #230209?
<ubottu> Launchpad bug 230209 in thunderbird-locales "upgrade thunderbird locales for 2.0.0.x and include new upstream translations" [Wishlist,In progress] https://launchpad.net/bugs/230209
<slangasek> asac: if you think this still belongs in 8.04.1, I need it in the archive today
<siretart> sistpoty|work: not anymore, I disabled openal in rss-glx in the last upload
<siretart> ogra: /me runs away. screeming
<ogra> heh
<sistpoty|work> heh
<ion_> benc: Iâm sure youâve already thought of what iâm saying, but here goes anyway: there probably should be a package that contains a /etc/kernel/prerm.d script that generates a last-good-boot from the current running system if one doesnât exist, and the version of apt that removes the NeverAutoRemove rules from /e/a/a/01autoremove probably should depend on that package, in order to make sure a last-good-boot exists before any kernels are autoremoved in ...
<ion_> ... case the user happens to be running an earlier kernel because the newest one doesnât boot for her.
<asac> slangasek: not needed imo. I will talk to ArneGoetje about including it in the usual language pack update batch
<slangasek> asac: ok, unmilestoning, thanks
<asac> slangasek: i dropped  a comment too :)
<ogra> ScottK, bug 235135, that fix wont work generally and for everyone... if you use asound-plugins instead of libflashsupport while pulseaudio is running (and claiming the device) on a non dmix capable soundcard, you wont have any sound from flash at all
<ubottu> Launchpad bug 235135 in flashplugin-nonfree "[MASTER] Please backport flashplugin-nonfree version 10 beta and asound-plugins from Intrepid so we can drop libflashsupport and the crashes it causes" [Undecided,Invalid] https://launchpad.net/bugs/235135
<mantiena> hi all
<mantiena> I'm going to testï»¿ 8.04.1 candidate imagesï»¿, mï»¿aybe someone knows - are there any important bugs, which I should test with Ubuntu 8.04.1 candidate from http://ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿ï»¿cdimage.ubuntu.com/cdimage/hardy/ ?
<ln-> ...
<halex> er...
<ln-> ZERO WIDTH NO-BREAK SPACE
<ln-> how did that even happen?
<Pici> mantiena: Have you checked out #ubuntu-testing ? They might be able to point you in the right direction.
<Spads> ln-: guh, unicode allows for all sorts of horror.  Try pasting a zillion combining characters with nothing to combine to sometime.  irssi in screen goes completely spare
<mantiena> Pici: I already asked this question at ubuntu-testing, but no answer :( in any case - downloading takes about 3 hours, so, I have some time to get an answer :)
<ScottK> ogra: I'm looking for a good recommendation on how to approach that bug.
<ogra> if we knew one hadry wouldnt suck so much with flash :)
<ogra> the proper solution would be to have libflashsupport fixed, but that requires internal knowledge of flash code ...
<ogra> pulse expects to hog the device completely with nothing interfering .... but flash with pulse needs libflashsupport ... all other solutions wil end up with concurret access to the sound device which works or doesnt depending on the dmix capability of your driver/card
<ScottK> OK.  So maybe good is the wrong word.
<ogra> its kind of gambling to rely on dmix here but probably the only solution, i just wanted to point out that you wont fix it for everyone with either solution ... (one opportunity would be to just hide the crash through using nspluginwrapper in 32bit like fedora does, but thats no oportunity for hardy and also doesnt *feel* right)
<ScottK> How about least bad.
<ogra> yeah, "sucks least" is probably the right term :)
<ScottK> It just seemed that 'everyone will use pulse by default' was not the right assumption to use.
<ogra> well, if libflahsupport would work as it did in gutsy it would all be fine ... but flash changed and the lib didnt keep up
<Company> ubuntu should just default to pulse everywhere
<Company> and drop dmix
<Company> well, maybe not, because that means more poeple use swfdec instead of closed source
<ScottK> Company: Hardy is what it is at this point and won't change at that level.  It's to late for should.
<Company> oh right
<Company> i was thinking intrepid here
<ogra> Company, right, thats what we will likely do
<Company> but flash isn't the only one talking to dmix - or did you make mplayer etc talk to pulse, too?
<ogra> i think mplayer has an opportunity, i'm not much into players myself
<ogra> siretart would surely know ...
<Company> i don't have much of a clue about the hardy situation as i have everything customized - life of an upstream developer
<wgrant> mplayer defaults to pulse.
<wgrant> Or maybe I didn't end up doing that.
<wgrant> But it has the option.
<Company> alsa has the option to default to pulse, too ;)
<ogra> yes, thats how we do remote sound in LTSP
<persia> Company: Yes, but as pulse uses ALSA for output, that ends up being a little odd.
<Company> persia: nope
<Company> persia: pulse only takes hardware devices
<ogra> well, it uses the alsa driver to do so
<Company> persia: fedora 9 does it that way
<ogra> (not the libs tough)
<Company> so they transparently moved all apps to pulse
<Company> almost transparently
<ogra> heh
<Company> i was under the impression pulse only replaced esd in hardy
<persia> Company: Almost transparently.  There's a number of side effects of the app -> alsa -> pulse -> alsa -> HW loop, but it's more transparent than hardy.
<Company> persia: i'm aware of the problems (like no mmap access) - but the fedora guys seemed pretty happy
<Company> you could hack libflashsupport to check for a pulse output in alsa and if it exists prefer that over default
<Company> dunno if that requires hacking alsa config to provide one though
<ogra> that wont keep libflashsupport from crashing firefox
<ogra> first of all libflashsupport needs to actually not segfault before we can even think about going on using it :)
<Company> oh, it's that bad?
<Company> ignore me then :)
<ion_> nspluginwrapper for 32bit would be nice indeed.
<ogra> it tears down FF if you go back and forward on a youtube site
<ogra> ion_, well, it only hides the prob
<Company> i think you deserve it for not going entirely free :p
<ion_> Yes, but as long as we have closed-source plugins, it might be best to hide the problem. :-)
<ogra> (and surely many others as well, which is a bad sideeffect since such bugs wont be reported ot fixed)
<Company> seeing flash and nvidia blow up in your face is nice :p
<ogra> buy intel :)
<Company> i have intel
<ogra> well, that was a more generally meant shameless advert :)
<Company> ubuntu should have more shameless adverts
<ogra> heh
<Company> put "everything works better than nvidia" on the cds
<ion_> fglrx doesnât. :-P
<ogra> "you have to play this CD backwards to make it run on nvidia hardware"
<laga> heh
<emgent> morning
<TheMuso> slangasek: Nobody has got back to me with anything. I'm going to post instructions to the bug once again to try and get people to help. If nothing happens, theres not much I can do.
<alex-weej> every time there's a kernel update it breaks my wireless, i have to rebuild svn madwifi and install it in place of the distributed madwifi
<persia> alex-weej: What is the difference between the two that causes you to do this?
<Hobbsee> alex-weej: it builds kernel-api-specific modules?
<alex-weej> possibly... let me try to load the distributed ones. i'll be back in 2 minutes!
<alex-weej> http://pastebin.ca/1058984
<alex-weej> not much to see...
<alex-weej> with the distro modules from l-r-m, n-m doesn't even think i have a wlan adapter
<wgrant> alex-weej: It's not every kernel update...
<wgrant> Just ABI-breaking ones.
<alex-weej> basically all of them :P
<alex-weej> but yeah
<persia> alex-weej: The right way to fix that is to determine what bit you need to make your device work, and ensure that this is available in the next update.
<alex-weej> i was simply trying to say that with every new kernel release, the madwifi version is still ancient
<alex-weej> or just built wrong
<alex-weej> cause this has been going on for a very long time
<persia> alex-weej: It likely needs someone with affected hardware (e.g. you) to investigate, and generate a good bug report.
<alex-weej> is already up here actually. https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/122703
<ubottu> Launchpad bug 122703 in linux-restricted-modules-2.6.24 "Upgrade Atheros drivers to snapshot/trunk to support AR5008/AR5418" [Low,In progress]
<alex-weej> i wanted to test intrepid actually... see if it was fixed
<alex-weej> but no Live CD :(
<persia> alex-weej: I think that bug tells the story well.  Upstream keeps deciding that the versions you need aren't ready for release, and the kernel developers respect their opinion.
<alex-weej> yeah i see that myself now.
<persia> Probably best to update one of the upstream tickets with your successful test report and help build confidence in the driver upstream, if it works for you.
<alex-weej> annoying, as they claim all their efforts are going on ath5k now
<alex-weej> and this chipset won't be supported for a while as there's no open HAL for it
<BenC> pitti, doko, cjwatson: Is it possible to get makedumpfile MIRd today? :)
 * cjwatson <- not in ubuntu-mir and would rather not
<BenC> cjwatson: ah, thought you were for some reason
<croessner> Hi, somebody here, having experiences with installing hardy on Apple Xserve Intel? Where can I get (commercial) support on that?
<Pici> croessner: This isnt a support channel. You might be able to find free help in #ubuntu or #ubuntu-server Canonical.com sells support, although I do not know the specifics of what hardware they will support it on.
<croessner> Pici, thx, I know that this is not a support channel. At the other side, I did not know where to ask elsewhere. All the commercial supporters are PC supporters not Apple Xserve. So I thought asking the devs for help.
<BenC> croessner: canonical would be able to provide more information on support contracts
<ubuntuzistheneww> ok who  is the guy making all the restart jokes
<ubuntuzistheneww> i just updated samba and openssl and i am told to reboot, what kind of joke is it ?
<ubuntuzistheneww> why don't i go use windows that is better than this ?
<ion_> Eh.
<ion_> Please read the topic.
<ubuntuzistheneww> sorry to be rude
<ubuntuzistheneww> yeah i'm in here complaining to the devs
<cjwatson> you don't have to reboot if you're sure that you've restarted everything using the relevant libraries
<ubuntuzistheneww> you guys. this isn't an issue or a bug
<ubuntuzistheneww> cjwatson: why doesn't ubuntu just do that for me ?
<cjwatson> unfortunately, while restarting server processes is relatively straightforward and we do that, restarting clients is infeasible
<ubuntuzistheneww> this is not a good way to keep new users
<ion_> So, youâd rather tell newbies âplease restart everything that depends on the following librariesâ?
<cjwatson> and it can actually matter for the openssl updates, I'm afraid
<ubuntuzistheneww> cjwatson: yeah i have done 4 in the past month why is that ?
<ubuntuzistheneww> my debian box has had about 2ish
<cjwatson> see the changelogs
<cjwatson> we provide extensive documentation with each update, for those interested in digging
<ubuntuzistheneww> can you guys up in in dev fix your distro so we don't get new users jumping over to vista. which reboots far less often
<ubuntuzistheneww> no offense
<joaopinto> ubuntuzistheneww, like if new users had major concerns with the need to reboot, specially when they get a proper notification...
<cjwatson> we're not really interested in a debate of this form
<cjwatson> bugs are bugs, and are given priorities
<cjwatson> but sometimes we just disagree
<ubuntuzistheneww> this is a bug
<ubuntuzistheneww> i'm filing a bug
<cjwatson> it's not especially clear that it is
<ubuntuzistheneww> its a bug
<ubuntuzistheneww> thank you
<ion_> Meh.
 * cjwatson shrugs, if he doesn't even want to listen to us trying to explain ...
<ion_> benc: Have you had a chance to look at my email (the grub last-good-boot debdiff), btw?
<ubuntuzistheneww> i have filed a bug https://bugs.launchpad.net/ubuntu/+bug/244250 good day
<ubottu> Launchpad bug 244250 in ubuntu "reboot every single update in the past month on ubuntu hardy nearly. massively decreasing my uptime." [Undecided,New]
<ion_> I wonder how *uptime* is relevant.
<soren> im in ur apt eeting ur uptimez..
<ScottK> If you're selling hosting services and have quality of service provisions in the contract every reboot can cost you.
<cjwatson> I'm addressing the bug report; there is at least one real issue buried in there, I think
<sistpoty|work> ScottK: but then you wouldn't want a single point of failure as well, like only one box for a service? ;)
<ion_> scottk: Such servers arenât running a desktop that suggests a user to reboot. It is expected that such servers have admins that can handle the restarting of services in a way they see fit.
<ScottK> True.
<BenC> ion_: yeah
<broonie> OTOH, if you've got lots of state open then then rebooting can be rather inconvenient.
<cjwatson> please see my comments in the bug report
<ion_> benc: When the apt rule for not autoremoving old kernels is removed, perhaps apt should have a versioned dependency on grub (or another package to which the last-good-boot scripts may be split to from grub), in order to make sure a last-good-boot exists when the kernels are finally autoremoved.
<lamont> Jun 30 08:46:47 gw kernel: [ 1273.611780] audit(1214837207.018:23): type=1503 operation="inode_permission" requested_mask="::w" denied_mask="::w" name="/var/cache/bind/" pid=20209 profile="/usr/sbin/named" namespace="default"
 * lamont curses apparmor
<BenC> ion_: we can't add a dependency
<BenC> ion_: and we don't support partial upgrades...plus, not having last-good-boot (even in some skewed fashion) doesn't break anything
<ion_> benc: I was thinking of a case where someone upgrades from, say, hardy to intrepid and afterwards runs an aptitude command that autoremoves old kernels, only to reboot later and notice that the intrepid kernel doesnât boot for her.
<ion_> Would be nice if *something* created an initial last-good-boot from the running system. Perhaps grub postinst?
<BenC> ion_: I thought the /etc/kernel/prerm.d/last-good-boot would handle that case
<cjwatson> we do necessarily have to support partial upgrades to some extent
<cjwatson> with the best of good will, upgrades will fail sometimes, and we don't want to leave the user's system unbootable in the middle of it
<BenC> cjwatson: well, to the extent that it works
<cjwatson> we should try to avoid making it worse, as a general rule ...
<mkrufky> can we merge the fix for bug #244005 (pull request included in bug report) ...  or do I have to send it to kernel team?
<ubottu> Launchpad bug 244005 in linux-ubuntu-modules-2.6.24 "sms1xxx OOPS on 64 bit kernels" [Undecided,New] https://launchpad.net/bugs/244005
<BenC> a kernel doesn't really allow itself to be uninstalled if it is the currently running kernel, IIRC
<ion_> benc: Hm, that might be true... I was just thinking it would be best to make sure /etc/kernel/prerm.d/last-good-boot is already installed when removing the NoAutoRemove rules.
<BenC> maybe kernel-helper shouldn't be part of grub then...not sure where to put it
<ion_> Perhaps a separate last-good-boot package, which just contains kernel-helper and the /etc scripts?
<BenC> I feel like there should be someplace else to put it (if for no other reason than to avoid yet another MIR :)
<ion_> Smaller delta from Debianâs grub as well.
<BenC> the extra script in grub doesn't really bother me delta wise...the changes to update-grub would still be there
<ion_> Yeah
<wgrant> 5~/win 3
<Riddell> asac: what's the plan with network-manager?
<asac> Riddell: bits are in ~network-manager PPA if you want to test.
<asac> Riddell: is knetworkmanager more or less ready for 0.7?
<Riddell> asac: no idea, I'll grab those ~network-manager packages and see if I can get anything working
<Riddell> it should be, suse uses it for opensuse 11 I believe
<asac> Riddell: yeah right. the gnome applet still needs a bunch of work too, so i if it basically works it should be fine
<dbmoodb> oh hi does any one know why -f --- the option to fsck on reboot was removed from ubuntu ?
<Spads_> dbmoodb: experimentally, I can tell you that touching /forcefsck (the effect of -f on shutdown was to create this file) does have the desired effect on boot
<dbmoodb> yes but was was it removed ...
<dbmoodb> why*
<Riddell> asac: network-manager-0.7~~svn20080628t003601+eni2 not compiling for me in intrepid http://paste.ubuntu.com/23994/
<ion_> Likely nobody happened to implement it in the Upstart reimplementation of the command.
<dbmoodb> if all it does is make do that operation ... why is the option in upstart ?
<dbmoodb> not in *
<asac> Riddell: hmm. dont you have hardy to test?
 * ion_ is compelled to repeat his previous line
<asac> Riddell: you might be able to override CFLAGS so that warnings dont make compiler bail out for now
<mario_limonciell> pitti, ping.  if you have a moment, I wanted to chat with you on the modalias detection on intrepid for fglrx/nvidia and jockey
<EtienneG> question about debconf (yeah!)
<EtienneG> using DEBIAN_FRONTEND=noninteractive, should it still display notes of priority critical that are unseen ?
<EtienneG> (ie, ssh/vulnerable_host_keys)
<cjwatson> EtienneG: no - noninteractive means noninteractive, regardless of priority
<mario_limonciell> pitti, oh I just saw your message that you are on holiday until wed.  for the package fglrx-modaliases, currently we're dropping the aliases in /usr/share/modaliases/fglrx-modules.alias.override.  It doesn't seem that this is currently in the search path for Jockey.  What path did you want things to be put in instead so that detection worked properly?
<cjwatson> EtienneG: if you want "only ask critical questions", use an interactive frontend with appropriate priority configured
<EtienneG> cjwatson, thanks, that confirm my understanding
<cjwatson> EtienneG: I'm curious as to what's behind your question
<EtienneG> cjwatson, someone complains that DEBIAN_FRONTEND=noninteractive still prompt for openssh-server and ssl-cert (vuln cert/host keys), and on config file replacements
<EtienneG> cjwatson, I think the way he set DEBIAN_FRONTEND is wrong; that is what I am going to check now
<cjwatson> EtienneG: right
<cjwatson> EtienneG: note that configuration file replacements are often *not* through debconf
<cjwatson> DEBIAN_FRONTEND will not affect many of those in the slightest
<EtienneG> cjwatson, thanks, that is something else that needs to be taken into account
<cjwatson> we don't have a good solution to that across the board; some packages use ucf which is debconf-based, but really dpkg's own prompts need to be glued into debconf; that will take a while yet
<EtienneG> cjwatson, ok, I see
<EtienneG> the two packages that have prompted for conf file replacement are clamav-freshclam and samba-common
<EtienneG> I will investigate
<EtienneG> cjwatson, assuming conf file is indeed managed without the help of debconf, should a bug be filed ?
<EtienneG> it is debatable, I am not too sure
<cjwatson> EtienneG: not generally
<cjwatson> EtienneG: it needs to be fixed centrally rather than piecemeal
<EtienneG> 'k
<cjwatson> EtienneG: incautious mucking about with configuration file handling code can be dangerous, so I don't want to encourage it to be done widely by people not very familiar with the packages
<EtienneG> cjwatson, I am all good that
<cjwatson> EtienneG: however: if the user did not modify the configuration file in question and still gets prompted, then that is definitely a bug
<EtienneG> cjwatson, re: ucf, should it honor DEBIAN_FRONTEND or not?
<cjwatson> EtienneG: this sort of thing sometimes happens when a package maintainer decides to edit the file in maintainer scripts as well as managing the file with dpkg, which is explicitly forbidden in the policy manual
<cjwatson> EtienneG: ucf asks all its questions through debconf and therefore automatically honours DEBIAN_FRONTEND
<EtienneG> cjwatson, samba-common does indeed some mucking around smb.conf, if I read the postinst correctly
<EtienneG> sed -e ...
<cjwatson> samba -> painful case
<cjwatson> slangasek: ^-- ?
<sbeattie> calc: is the openoffice update intended to make 8.04.1 release?
<calc> sbeattie: yes, probably need to talk to slangasek about whether it can still make it, sine it didn't get accepted until today
<calc> s/sine/since/
<calc> it fixes a crasher bug on gnome and kde
<sbeattie> okay.
<calc> apparently it affects many people, just not me :-\
<calc> so it took me a while to be able to track it down
<sbeattie> Eww. Is that bug 236676?
<ubott2> Launchpad bug 236676 in openoffice.org "OpenOffice 2.4 in Hardy AMD64, Locking assertion failure" [High,Fix committed] https://launchpad.net/bugs/236676
<calc> yes
<calc> it should be done in about 14hr on ia64 (if it takes as long as usual)
<calc> iirc it was actually caused by heap corruption in xrandr
<calc> but the symptoms were really strange :)
<jcristau> calc: was that ever fixed, other than by disabling the randr thing in ooo?
<calc> jcristau: from what i could tell in the ooo-build changelog yes
<jcristau> ok
<calc> yea they aren't disabling randr anymore afaict
<cody-somerville> slangasek, ping
<smagoun> evand: do you have a minute to chat about https://wiki.ubuntu.com/USBInstallationImages ? Are you writing the ISO-->USB tool from scratch?
<evand> smagoun: sure.
<evand> smagoun: indeed, as it stands it's going to be written from scratch.
<smagoun> evand: Have you considered using Fedora's liveusb-creator? It looks like it does everything the Ubuntu tool needs, and as an added bonus it works on windows
<evand> smagoun: unfortunately I think this is going to be a little too tied to Ubuntu to reuse their tool.  Also, we can't use Qt for it as we'd like to put it on the CD and there is not enough space for Qt on that.
<evand> I will take a closer look though and confirm though.
<smagoun> evand: ah, ok. I assume that the Ubuntu tool doesn't exist yet?
<evand> smagoun: correct
<slangasek> cody-somerville: pong
<slangasek> TheMuso: hrm, I see follow-ups to bug #191027 with no reply from you, though
<ubott2> Launchpad bug 191027 in totem ""Failed to connect stream: Invalid argument"" [High,Confirmed] https://launchpad.net/bugs/191027
<SolarWar> i'm trying to build my own ubuntu package- is this the correct place to ask questions?
<thom> nope; try #ubuntu-motu
<thom> this is for development of the core OS :)
<SolarWar> oh okay :)
<slangasek> cjwatson: so, samba-common uses ucf, and I don't see any evidence that ucf would fail to honor DEBIAN_FRONTEND
<slangasek> cjwatson: so I don't know what that's about
<ScottK> smagoun: Of course the Kubuntu CD already has QT on it, so maybe for Kubuntu.
<ogra> heh
<cjwatson> ScottK: I doubt we'd want a different backend for different flavours
<cjwatson> if the Fedora one has frontend/backend separation then we could work with it
<ScottK> Right, so we start with Kubuntu and Ubuntu can catch up for once.
<ScottK> Yes.
<ogra> smagoun, given that -mobile looks into a wrapper around livecd-rootfs for building USB capable images my bet would be that its easier for you to build native images with that instead of converting isos
 * cjwatson would tend to agree
<smagoun> ogra: my current plan is to teach liveusb-creator to install an existing Image Creator image onto a USB drive, rather than deal with an ISO directly or wait for -mobile to get something working. I need something that a) exists today b) works on windows and c) can be used by mere humans. liveusb-creator seems to be the only option.
<ogra> well, the changes we need in livecd-rootfs are pretty minor and it would take me a day or two to adjust my classmate builder tool for using a squashfs built with changed livecd-rootfs ... the planned wrapper script will likely work similar to my tool or the virtual image builder scripts .... all operate quite similar with small differences
<mkrufky> brb
<ogra> smagoun, we dont have liveusb-creator anywhere in the distro and i wouldnt expect it to work out of te box with an ubuntu setup ... so time has to be invested in any case, doing that on the existing proven tools we will as well go on using in the future sounds somehow like better invested manpower ...
<smagoun> ogra: The problem is not how to create the images, it is how to get them onto a USB drive. I need a tool that does that.
<ogra> you maean something like a graphical dd ?
<ogra> *mean
<smagoun> ogra: right, that's why I asked here in the first place. liveusb-creator seems to be the only option that exists today.
<smagoun> ogra: exactly.
<mkrufky> argh, i said brb to the wrong room, again
 * mkrufky hides
<smagoun> ogra: the reason I want a graphical dd is that I don't want a user picking the wrong device. 'dd if=C:\my.iso of=C:\' would be bad in this case.
<ogra> smagoun, well, first step would be to get it packaged then, second to get it working with ubuntu at all, third backport to hardy (which i assume you target atm) that probably wont be faster than writing something from scratch
 * ogra wasnt aware windows had dd at all ... i always point users to rawrite
 * ogra reads liveusb-creator homepage
<ogra> heh
<ogra>  * Completely non-destructive install. There is no need to deal with formatting or partitioning your USB key.
<smagoun> ogra: liveusb-creator worked out of the box on Hardy, so that's not a problem. I'm not familiar with rawrite, is that something I could give to (say) a marketing person without worrying about destroying his/her hard disk?
<ogra> i wonder how you overwrite an usb key in a nondestructive way :)
<ogra> smagoun, i'm not even sure it works with USB devices, its from the time where you had to dd images to floppies under linux and rawrite was the equivalent to do so on windows
<ogra> from the screenshots it looks very close to what we planned for the ubuntu iso->USB thing in pargue
<smagoun> ogra: liveusb-creator will write an image to an existing filesystem on the USB disk, then install syslinux to make the USB key bootable. It even works, I used it a previous job.
<ogra> well, one question is how it interacts with casper or whatever custom initramfs script you use for booting the installed system on the key
<ogra> it looks like it would be easy to customize to just grab ubuntu isos instead of fedora ones
<ogra> hmm
<ogra> "Linux support for the liveusb-creator is still in beta, but you can easily test it by doing the following..."
<ogra> seems the oly released version is the winows tool yet
<davidm> smagoun, are you talking about moving image to a USB stick on Linux or Windows or both?
<smagoun> davidm: both, really
<davidm> cause on Linux it's a 10 line bash script if you want to be super safe, windows I have no idea
<davidm> one line if you don't care about safe
<smagoun> davidm: safe is the problem (and windows is the other problem)
<davidm> Safe is prompt them to insert USB and wait for new USB drive to insert, prompt OK and then copy to device, done. WIndows hell if I know.
<ogra> ugh, liveusb-creator works with device names ... should use UUIDs and descriptive names instead ...
 * ogra tries to install a hardy iso with a modified liveusb-creator ...
<davidm> Could wrap a gui around a script and even make it cool looking.
<ogra> yeah
<ogra> for the linux side thats an afternoon of work for an experienced pygtk programmer ...
<ogra> but smagoun wants a windows tool as well
<ogra> tedg, hey ... do you know these ? http://parker1.co.uk/eternity/
<ogra> (check the videos, they are quite cool, somethig to consider to include)
<tedg> ogra, no I hadn't see them.  Just the pictures are pretty cool.
<ogra> yeah, and upstream seems very ubuntu enthusiastic
 * ogra twiddles thumbs waiting for liveusb-creator downloading the hardy iso ... i bet it will fail becaue we dont provide sha1 checksums in the archive for the isos 
<ScottK> doko: I've attached a patch for Bug #207150.  I'd appreciate it if you'd take a look.  If you like, I can upload it (or not), but thought I should check with you first.
<ubott2> Launchpad bug 207150 in python-central "pycentral crashed with UnboundLocalError in read_pyfiles()" [Low,Triaged] https://launchpad.net/bugs/207150
<davidm> ogra, I've not used Windows in so long I have no idea how to approach it there, except maybe Cygwin?
<ogra> QT runs on windows as well as gtk does
<smagoun> davidm: fedora has a tool (liveusb-creator) for getting ISOs onto USB. It uses QT, and runs on Windows.
<ogra> the liveusb-creator git tree has a dd.exe and (7z.exe in the source intresting there is no license or sourcecode for it which breaks the GPL)
<ogra> it has only four functions and is really not very much code ...
<ogra> but i still doubt our isos will work with it at all ... fedoras bootpocess and especially the initramfs is *massively* different to ours
<ogra> it will need a fair amount of adjustment and testing before you can even think about using it ... i tend to agree with davidm, writing a quick gui for a script will pretty much achieve the same functionallity ...
<davidm> Wonder if they got dd from here: http://gmgsystemsinc.com/fau/
<ogra> they cheat by using a binary dd.exe
<ogra> we can do pretty much the same (but properly licensed i bet)
<ogra> "The Forensic Acquisition Utilities are distributed under the GMG Systems, Inc. Open License. "
<ogra> hmm
<davidm> Or it could be from here: http://uranus.it.swin.edu.au/~jn/linux/rawwrite/dd-old.htm  That at least is GPL'ed
<ogra> no sourcecode anywhere on the fau site
<davidm> ogra, Nope, it's binary only
<ogra> yeah, the latter looks like something that can be used though
<ogra> ah, well
<ogra> "This version does not actually do any conversion but it allows the flexible copying of data under in a win32 environment. At the moment block devices under Win9x are not supported but that will be added soon."
<ogra> last modifies in 2006
<ogra> *modified
<ogra> doesnt look like fast progress
<davidm> ogra, nope, slow as in stopped.
<ogra> http://www.garloff.de/kurt/linux/ddrescue/ looks more recent and is GPL
<ion_> dd_rhelp is a nice frontend for dd-rescue.
<davidm> Ah, yea that might be better.  Tell you the truth however I don't really care about windows too much, not my cup of tea.
 * ogra read frontend as in GUI above ... 
<ogra> so i looked for screenshots
<ogra> http://linux.softpedia.com/progScreenshots/dd-rhelp-Screenshot-30608.html
<ogra> :P
<ogra> smagoun, liveusb-creator is defnately no option for shipping it to customers until that dd.exe license issue is clear
<davidm> is dd-rescue Windows?  I only really see Linux stuff
<ogra> hmm, it was linked from the fau page
<ogra> ah, no from the rawrite page, sorry
<ogra> i guess the rawrite one is the best bet we have, even though its old and outdated, it claims to run on win2000 which makes me think it will likely work on XP as well
<smagoun> ogra: the DD license is listed in README.txt, it is GPLv2.
<smagoun> ogra: https://fedorahosted.org/liveusb-creator/browser/README.txt
<ogra> oh, right i looked at the different shipped license files
<ogra> heh, and it links to http://www.chrysocome.net/dd which looks suspiciously like http://uranus.it.swin.edu.au/~jn/linux/rawwrite/dd-old.htm :)
<ogra> (not to say its the same content :) )
<davidm> http://www.chrysocome.net/projects has dd for windows and rawWrite for windows, all under GPL but you need delphi!!!
<davidm> Which explains the development slowdown....
<ogra> yeah
<ogra> download is at 92% ...
<ogra> *twiddle* *twiddle*
<davidm> ogra, years ago I wrote a .h file that let me rename .pas files. to .c and include the .h and it would compile under C.  I wonder if you could do that with delphi files.
<davidm> That was straight pascal however not object pascal
<ogra> no idea, i never touched dlphi in my life ... when delphi was recent there was also perl (and perl-gtk) for windows ;)
<ogra> Downloading ubuntu-8.04-desktop-i386.iso...
<ogra> Download complete!
<ogra> Verifying filesystem...
<ogra> Not enough free space on device.
<ogra> 699MB ISO + 0MB overlay > 164MB free space
<ogra> LiveUSB creation failed!
<ogra> ah well ...
<ogra> its an empty 2G usb key you silly thing !
 * ogra expected problems ... but surely not at that stage yet
<ogra> its funny because it offers me to use the full 2048M of the key to select as persistent space ... so it knows there is enough room
 * soren_ thinks he knows why Intrepid won't boot in kvm..
<soren_> Hmm... where'd that underscore come from?
<slangasek> cody-somerville: would you be able to test that the fix for bug #220817 is good?
<ubott2> Launchpad bug 220817 in openoffice.org "OpenOffice.org language packs pull in openoffice.org binaries" [High,Fix committed] https://launchpad.net/bugs/220817
<slangasek> cody-somerville: i.e., that if you enable -proposed immediately, you don't get OOo pulled in right after a xubuntu install?
 * ogra wonders why he seems to get a handfull of mail duplicated once a week ... 
<ogra> i have gotten that "please compile git with curl" mail 18 times in ubuntu-devel-discuss now
<ogra> and a bunh of bugmail that comes dulicated at least once a wekk
<ogra> *week
<ogra> does anyone else see that ?
<ScottK> No.  POP3 or IMAP?
<ScottK> What mail client?
<ogra> pop3 googlemail ....
<ogra> i see it coming in at the google interface as well, its not an issue on my side according to that behavior
<ScottK> Right.  I'd blame Google.
<ogra> you mean an internal SMTP server that sends it over and over ?
<ogra> hmm, might be
<ScottK> Dunno.
<smagoun> ogra: FWIW I got liveusb-creator to copy an MIC image onto a USB stick. I hacked l-c to do a straight dd, no non-destructive writing for now. Now to see if it works on windoze...
<ogra> well, then just rebrand it and you got what you want ... we can put a package in intrepid and backport it from there so you have it available for hardy users in ome way
<ogra> *some
<smagoun> yup, that's the plan (not sure it's going into intrepid/backports yet, I'll think about that one tomorrow :) )
<ogra> well, if we need it i can package it in the distro, no probs here
 * ogra doesnt see a prob telling customers to use an ubuntu liveCD instead of having to maintain win software though 
<ogra> uhm, intresting, i cant ctrl-C liveusb-creator in the terminal i stared it in
<ogra> *started
#ubuntu-devel 2008-07-01
* mthaddon changed the topic of #ubuntu-devel to: Launchpad is going down from 00:00 UTC until 02:00 UTC for a code update | intrepid alpha-1 released, archive open | frozen: Ubuntu 8.04.1 | 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-
* mthaddon changed the topic of #ubuntu-devel to: intrepid alpha-1 released, archive open | frozen: Ubuntu 8.04.1 | 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
<lamont> so... if I have a random laptop with network-mangler installed, and I want to tell it to STFU and let me manually configure both the wireless interface and the wired interface is that trivial without killing various applets and daemons and such?
<RAOF> lamont: Yes.
<lamont> how?
<RAOF> lamont: Unless it's changed in Intrepid, any configuration of an interface will make NM ignore it.
<RAOF> For example: left-click on NM's applet.  Hit "Manual configuration". :)
<lamont> kewl
<lamont> and afk while it's still light-ish outside
<lamont`> RAOF: telling NM 'Manual config' not so much love.  editing /etc/network/interfaces? love
<RAOF> lamont: NM->Manual config should be brining up something that edits /etc/network/interfaces.  It didn't?
<lamont> it did
<RAOF> It just didn't work?
<lamont> and I left it there and used my other tool for editing interfaces...
<lamont> since the gui is extremely cumbersome, and vi is love
<lamont> and then it decided that just because I said manual config, didn't mean that I wanted manual config, and started doing it's thing.
<lamont> so I finshed the vi session, and there was love
<lamont> after all, my question was "how do I make it STFU", not "how do I edit the config in a nice pretty gui"
<lamont> :-)
<RAOF> Right.
<emgent> morning
<lamont> RAOF: and definitely a more elegant hammer than the random kill commands I was using the last time when it pissed me off
<saivann> In case a ubuntu developer want to take a look at it, bug 189814 contains very detailed informations about a bug which seems to be clearly well identified.
<ubott2> Launchpad bug 189814 in linux "[hardy]computer and touchpad is buggy with BIOS password set" [Medium,Triaged] https://launchpad.net/bugs/189814
<TheMuso> Hrm when attempting to install into a kvm image from an iso, the alternate CD, it always seems to freeze at the stage where its instaling the bootloader. This is hardy alternate.
<Hobbsee> power!
<Hobbsee> electricity!
<lifeless> education!
<Hobbsee> it's very boring without power :(
<persia> Hobbsee: You just need larger solar arrays ...
<Hobbsee> persia: i wish.
<ScottK> We had a several hour power outage a few months ago and it was kind of fun continually telling our 5 year old that no she couldn't X because there was no power.
<ScottK> So I think she would agree.
<Hobbsee> haha
<persia> I lived in a house for a while with a bank of "Navy Batteries" that didn't have the "No power" issue.  Unfortunately, it did have the "not enough amperage" issue on a regular basis.
 * ScottK cheers the new firewall script running without locking me out of the box.
<RAOF> THat be a winner.
<ion_> BoFH excuse #612: the new firewall script locked everyone out of the box.
<Amaranth> I lost power Friday night
<Amaranth> was out for 17 hours
<TheMuso> Ouch.
<Amaranth> yeah
<Amaranth> really nasty storm
<ion_> Thatâs #329.
<ion_> And ouch, too. :-)
<Amaranth> 90mph (144km/h) winds, 120,000 lost power, 2 people died
<TheMuso> Really ouch.
<RAOF> Eeep.
<TheMuso> Amaranth: Where are you?
<Amaranth> omaha nebraska
<Amaranth> wasn't even a tornado, just wind, rain, and hail
<TheMuso> That is nasty.
<Amaranth> worst hit part of town is less than a mile from here, we got it pretty bad
 * Amaranth 1-ups Hobbsee 
 * Amaranth goes to read xkcd
<Hobbsee> ouchy
<RAOF> !!!
<RAOF> Evolution seems to have gone on a no-holds-barred spam hunting expedition.
<RAOF> And, in the process, marked almost _everything_ as spam.
<TheMuso> hehe
<RAOF> So if, say, you've responded to a bug I'm subscribed to and are a little bit surprised I haven't done anything about it...
<persia> We should poke you mercilessly and update the bug hourly?
<RAOF> Well, until evolution stops classifying all mail as spam, I'll remain blissfully ignorant of your bug updates!
 * RAOF wonders where "Sonopia" is, and why he should join someone there.
<Hobbsee> persia: do you think you'd be able to write a howto for the sound cards, and getting decent sound on intrepid?
<Hobbsee> forums people are advocating all sorts of crack
<Hobbsee> or i could be not lazy, adn do it myself, i guess.
<RAOF> Hobbsee: Are you referring to the pc speaker thingy, or what?  I haven't noticed sound problems?
<ion_> âforums people are advocating all sorts of crackâ â business as usual. :-)
<persia> Hobbsee: I'll write the MOTU Meeting minutes for you, if you'll write the HOWTO for sound card selection.
<StevenK> Heh, yes
<Hobbsee> RAOF: yes
<Hobbsee> persia: deal.
<Hobbsee> persia: i knew i had something outstanding.
<Hobbsee> ion_: it's only safe to say that when you're in a room not full of forums people :P
<Hobbsee> ion_: i tested this out in sevilla.
 * persia appoints Hobbsee high-user-educator-for-all-things-alsa
<ion_> hobbsee: :-)
<Hobbsee> ion_: iirc, it was the planet editorial spec, and they were talking about what to do if information gets published on the forums where it shouldn't.  I suggested that there was often a lot of incorrect information on there anyway that it was unlikely that the correct rumours would blend in rather well with it - or something similar to that.
<Hobbsee> perhaps that wasn't such a good idea :P
<ion_> Hehe
<Amaranth> it scares me that the intrepid forum is the 346th they've made
<dholbach> good morning
<Hobbsee> hey dholbach
<dholbach> hi Hobbsee
<jengelh> kirkland: then if you are so unhappy about pam_mount, why not report the bugs?
<geser> Hi Hobbsee, dholbach
<dholbach> hiya geser
<Hobbsee> hey geser!
<sistpoty|work> mvo: do you happen to know some details about libcap vs. libcap2? (zsh b-d on libcap2-dev nowadays, but that's in universe)
<mvo> sistpoty|work: I'm somewhat disconnected from it (hasn't seen changes in a long time) but my understanding is that libcap2 used to be a cvs snapshot and provides essentially the same functionality
<sistpoty|work> mvo: ah, k.. thanks... then I'll try to rebuild zsh with libcap1 instead :)
<mvo> ok, good luck
<fabbione> morning guys
<siretart> hey fabbione!
<fabbione> ogra: you around?
<fabbione> hi siretart
<siretart> how are you? I haven't seen you for quite some time!
<fabbione> i am doing fine, you?
<fabbione> yeah i don't spend a lot of time on IRC anymore
<siretart> ah, right. I'm doing fine as well, now working at the university, and probably doing some research that will involve work in ubuntu/debian, we'll see ;)
<asac> ogra_cmpc: ever opened a bug for the nss issue?
<Iulian> Good morning.
<asac> ogra: ping ;)
<asac> soren: there?
<soren> asac: Oui.
<asac> soren: about NM-Xvpn :)
<asac> soren: i have updated 0.7 packages in ~network-manager ppa and want to update the vpn plugins
<asac> Ng: you want to test NM 0.7 on hardy? :)
<tjaalton> asac: I do!
<asac> Ng: the ~network-manager PPA has hardy packages
<asac> they should be fine
<asac> https://edge.launchpad.net/~network-manager/+archive
<tjaalton> oh, sorry, not hardy
<asac> tjaalton: intrepid?
<tjaalton> asac: yeah, dist-upgraded yesterday :)
<asac> takes a few more days as it doesnt compile due to gcc pickiness
<tjaalton> ah, ok
<Ng> asac: yeah :) thanks
<asac> tjaalton: lucky you. i am still waiting for 8.04.1 before upgrading :/
<tjaalton> asac: well I need to test the new x stuff as promised ;)
<asac> Ng: only thing to remember is that you might need to sudo killall wpa_supplicant after resume
<asac> otherwise it works great here
<Ng> asac: ok. I'll chuck it on at lunchtime and file some bugs ;)
<soren> asac: Oh, I see. Erm...
<asac> Ng: hehe. yeah
<soren> asac: I really don't have the time to work on them right now,  I'm afraid.
<asac> soren: sure. i can take them over i guess
<soren> That would be lovely!
<asac> soren: did you always rip them out of the NM svn?
<asac> soren: or did they just recently move to a subdirectory of the svn tree?
<soren> asac: Yep. I don't think there was ever a proper release of any of them.
<soren> Oh, no, they've been right there all the time.
<asac> soren: do you maintain them in debian too?
<soren> asac: In theory, yes.
<asac> soren: now mbiebl took over?
<soren> asac: Well, they're in the pkg-utopia thing.
<soren> asac: ..so I guess they're meant to be a bit of a group effort anyway.
<asac> soren: how did they end up there?
<soren> mbiebl was my sponsor from the beginning, and he suggested we put them there.
<soren> In retrospect, I wish we hadn't, though. The main thing that has kept me away from working on it is that svn-buildpackage kept getting in my way. :/
<asac> soren: ok, but you are Maintainer: ?
<asac> soren: if so, we can move them to the ~network-manager team in launchpad ;)
<soren> Ah, yes.
<asac> soren: if you still need a sponsor i can do it too
<soren> asac: I'll be sure to keep that in mind.
<asac> soren: hmm. so move the branch or not move?
<asac> soren: i need to know what and how to do ;)
<soren> Well, we can put the ubuntu packages there, no problem.
<soren> I'd need to talk to mbiebl about the Debian packages.
<broonie> soren: Are there any plans to look at the issues with n-m reporting connected status too early?
<soren> broonie: bug number?
<broonie> Don't know off-hand, let's see if I can find any in lp....
<broonie> 152794 looks like one of them.
<asac> soren: I'd like to not duplicate work on those packages
<asac> soren: i am still trying to convince mbieble to join efforts, but he appears to be not really interested
<broonie> (the bit where it gets a connected status reported but no IP configuration yet - only seems to happen for some cards/systems)
<soren> bug 152794
<ubottu> Launchpad bug 152794 in nis "nis daemon fails to attach to domain the first time it is run in Gutsy" [Undecided,New] https://launchpad.net/bugs/152794
<mvo_> asac, I just tested it here on my laptop, works nice, but a reboot is required, otherwise it gets pretty unhappy
<soren> asac: I totally understand. My other main problem was that I was really more interested in getting stuff into Ubuntu, so the process was: a) Get it into Ubuntu, b)  rework package to get it into Debian, c) do useless merge.
<asac> mvo_: how?
<asac> (unhappy)
<asac> soren: right. I'd suggest -> we maintain the packages in bzr and inject to debian
<asac> then sync them down to ubuntu :)
<asac> i think NM 0.7 is or is about to be in debian experimental. so we could upload there.
<mvo_> asac, the icon was displayed but showed that no network was attached and the terminal printed something about a dbus method that could not be resolved
<soren> asac: That sounds great.
<mvo_> asac, sorry, I haven't investigated further
<mvo_> the test machine was crashing then (unreleated most likely) and I had to reboot
<asac> soren: so how to proceed? i suggested to mbiebl that we rebase the branches on top of the "official" gnome bzr mirror: http://bzr-mirror.gnome.org/
<asac> soren: now the vpn plugins are somewhat not available as a top-level project.
<asac> does this mean we cant do it?
<asac> maybe we should just build them in the network-manager source package ;)
<soren> asac: Well, IIRC the vpn plugins aren't in the network-manager release tarballs?
<soren> asac: They're only there now because the package is based on an svn snapshot.
<Riddell> lool: why is sdk-default-icons a native package?  also why the generic name?
<lool> Riddell: Debian renamed it to something more specific; I used the usptream name as used at maemo.org
<soren> asac: But apart from that, it makes perfect sense to build them out of the n-m source package.
<lool> Riddell: and also the name we were using in gutsy
<Riddell> lool: why don't we sync it from debian?
<lool> Riddell: It's not in Debian yet
<Riddell> lool: well if debian renamed it, we should too
<lool> Riddell: I worked on it for Ubuntu and when we discussed it in the Debian chan there was interest for it; I didn't expect to push it to Debian when I started work on it
<lool> Riddell: Indeed; so please kick it out
<lool> Riddell: We'll use whatever name Debian accepts
<lool> And concerning the native package, it looks like I misnamed my orig tarball
<lool> I had to repack upstream's to drop debian/ IIRC
<siretart> Riddell: could you please remove the source package named 'ffmpeg' from intrepid? It has been superseeded by 'ffmpeg-free'
<cjwatson> you can file bugs for removals, and we're not especially far behind on our bug queue ...
<ogra> asac, hmm, i was sure i had ...
<ogra> fabbione, pong (sorry, slept in, i had a long night)
<Riddell> siretart: yeah, bug please, I'll get to it in a bit
<siretart> ah, okay, will do
<asac> ogra: at least you didnt give me the bug id ;)
 * asac searching
<ogra> its weird, i could swear i did but cant find it myself
<asac> ogra: did you search for all bugs by "reporter ogra"?
<ogra> no, i searched my evo bug folder where usually all lp mail lands
<ogra> (and which is ten times faqster than LP :) )
<asac> soren: the svn tags (and bzr branches) contain vpn-daemon for 0.6
<asac> soren: guess that means we can just use NM. now we need to convince debian :(
<StevenK> Can I bug an archive admin to look at bug 236979 ?
<ubottu> Launchpad bug 236979 in opal "[intrepid] Please sync opal 2.2.11~dfsg1-4 from Debian" [Undecided,Confirmed] https://launchpad.net/bugs/236979
<cjwatson> StevenK: doing
<StevenK> cjwatson: Thank you :-)
<cjwatson> StevenK: so the Ubuntu patch just isn't needed any more for some unspecified reason?
<ogra> asac, wow, i used tracker for the first time ever :)
 * ogra hands asac Bug 242379
<ubottu> Launchpad bug 242379 in nss "constantly shows popups with certification errors on some pages" [Undecided,New] https://launchpad.net/bugs/242379
<StevenK> cjwatson: Well, it was a fix an FTBFS in Hardy, it doesn't fail to build. I can track it down explicity if you wish.
<persia> I tracked it down previously, and will comment in the bug to indicate as much.
<cjwatson> StevenK: how about this, you get to reinstate it if it fails to build on the buildds ;-)
<StevenK> cjwatson: Happy to fix it if it breaks :-)
<fabbione> ogra: ehhe no worries....
<fabbione> ogra: do you still have that dvb-t card around you mentioned a while ago?
<asac> ogra: triaged ;)
<ogra> fabbione, yes, want me to test anything ?
<fabbione> ogra: yes if you can.. i am having problems with my dvb-t card on intrepid kernels and with updated drivers from dvb-t tree.
<ogra> (i might need to rebild the kernel for that, the dvb-usb fix i need is only in intrepid afaik)
<fabbione> I am trying to nail down if the problem is my specific driver
<fabbione> or the general dvb subsystem
<fabbione> i can't even scan for channels basically
<ogra> did it work in hardy ?
<fabbione> yeps
<fabbione> but as i said, i am trying to nail the problem within the subsystem
<fabbione> or the driver
<fabbione> testing another driver is not an option as i only have one card
<ogra> hmm, i know pitti did a lot of work on the tools there are packages in his ppa
<fabbione> so if you could fire up intrepid kernel and tell me if you can scan for channles that would be awesome
<fabbione> ok?
<fabbione> so it might be userland that needs smashing?
<fabbione> there was a thread on one of the fedora mailing lists that the userland interface was broken by mistake but it was also fixed again before rc8 AFAIK
<ogra> not sure, pitti ?
<fabbione> maybe the change is not in ubuntu yet... that is entirely possible
<ogra> i know there was a fix in dvb-usb
<ogra> without that my card oopsed
<fabbione> ok..
<fabbione> well anyway if you have time to give it a shot that would be great.. otherwise no worries
<fabbione> i will just wait the next kernel
<ogra> gimme some time, i have no intrepid install here, need to upgrade one machine first
 * ogra is stuck with hardy for subnotebook work :(
<fabbione> please don't kill your machine for me :)
<fabbione> it's really not important
<ogra> well, i'll test it anyway, will just take some time... stay around and i'll ping you if i know more
<fabbione> ok cool thanks
 * ogra still didnt find the time to install his dvb-s card :( its lying on the shelf since nearly a year
<ogra> )
<laga> bah
<laga> you're too lazy.
<ogra> haha
<asac> StevenK: if liferea just builds with xulrunner-1.9-dev we need to check if the startscript is ok. otherwise sync and provide the debian -dev package name
<asac> StevenK: hmm. we still have the ubuntu feeds. nevermind
<bliZZardz> when would pitti be online? any idea?
<halex> wasn't he on earlier, or am i imagining things?
<bliZZardz> i see him online..
<Pici> bliZZardz: Hes been idle for 4 days, his away message says "holidays, back next Wednesday"
<bliZZardz> Pici : thanks... :)
<bliZZardz> i can ask the Q here at the expense of it being OT. If someone can shed somelight , then it would be great
<cjwatson> it's generally better to Just Ask
<bliZZardz> was wondering how DBus is being used in GNOME? when callbacks are already present as part of the GTK. How is Dbus implemented? Sockets?
<cjwatson> GTK callbacks implement in-process communication, not inter-process communication
<bliZZardz> ok.makes sense - corollary to that Q : do callbacks leverage multi-core?
<StevenK> cjwatson: Note the lack of opal build failures. :-)
<StevenK> cjwatson: Now to teach me a lesson, sparc, powerpc and ia64 will fail. :-P
<bliZZardz> cjwatson : and hints on other Qs?
<cjwatson> StevenK: heh, cool
<Company> bliZZardz: glib callbacks are single-thread as they guarantee execution before the callback emitting function returns
<bliZZardz> Company, and DBus uses IPC - is this using sockets?
<cjwatson> bliZZardz: I don't know all the answers. As an example, processes that require administrative privileges mostly now call out to PolicyKit over D-BUS to gain authorisation.
<Company> bliZZardz: yes
<cjwatson> bliZZardz: it might be worth reading the D-BUS documentation
<Company> bliZZardz: dbus is IPC using unix sockets
<cjwatson> http://www.freedesktop.org/wiki/Software/dbus
<bliZZardz> cjwatson : i even looked at teh source - it is a little confusing, would be better if i get some guide who can show me the door
<cjwatson> start with the documentation, not the osurce
<cjwatson> source
<bliZZardz> cjwatson : so where is it being used in GTK? i couldnt find the reference of Dbus in GNOME - though am finding some references the other wat
<bliZZardz> *s/wat/way/
<cjwatson> bliZZardz: it's not used in GTK itself
<cjwatson> bliZZardz: a variety of GNOME applications use it
<bliZZardz> cjwatson : can you name a few?
<azeem> bliZZardz: grep your Packages.gz
<cjwatson> 'apt-cache rdepends libdbus-1-3'
<cjwatson> you can then use 'apt-get source' to get source for individual packages there
<bliZZardz> cjwatson : ah...good one. missed it completely :)
<james_w> I'm merging a package which introduces init scripts. I switched the dh_installinit command to not install symlinks for runleves 1 and 6, however, I left the priority for runlevel 1 the same.
<YokoZar> Do the build daemons now autoinstall recommends by default as well?
<james_w> I see that there is a bug that means that really this should be set to (100-priority). I can easily do this, as the package has not hit the archive so there is no transition to worry about. However, is there a danger that acting unilaterally would break something else? (i.e. stopping earlier than dependent services)
<ogra> apt does .... the buildds use apt ...
 * ogra would expect so 
<james_w> I don't think there are any dependent services in this case, so I believe it should be safe, but can it be assumed to be so in every case?
<YokoZar> ogra: They might be passing funny switches.  I'm not sure how it works when you have pbuilder using satisfy-build-depends = gdebi, for instance...
<cjwatson> james_w: it's 0 and 6 that we normally disable, not 1 and 6
<james_w> cjwatson: yes, sorry, 0 and 6
<cjwatson> james_w: I don't think we can always assume it to be safe, which is one reason we haven't really worried much about changing all those to date :-)
<james_w> cjwatson: thanks.
<Keybuk> ok, my laptop is definitely doing odd suspend/resume things
<Keybuk> it appears to suspend as normal
<Keybuk> but when I press the power button to resume it, it just boots
<ogra> Keybuk, try blacklisting the button module
<Keybuk> (and usplash still prevents the X server from starting)
<ogra> i had similar probs on the classmate
<Keybuk> ogra: I tried that, it just stopped the power button doing anything
<ogra> SUSPEND_MODULES="button" in /etc/pm/config.d/default
<ogra> hmm
<StevenK> asac: So, we do need to merge liferea? Should I drop the patches aside the Ubuntu RSS feeds list, and see if the dratted thing builds?
<emgent> morning
<soren> No, it isn't.
<Hobbsee> evening soren!
<soren> No, it isn't evening either. :/
<Keybuk> it's Mailman Day *and* Abel & Cole Day ... double celebration!
<Hobbsee> Keybuk: i hope you're advocating listadmin as much as possible today, then.
<Hobbsee> Keybuk: oh, and reping!
<Keybuk> reping?
<Hobbsee> re-ping, as you didn't answer the first one.
<Hobbsee> is there any chance you can set an address for ubuntu-core-dev on launchpad please?
<Hobbsee> it would save us all getting spammed every time someone decided that it'd be a good idea to assign a bug to them.
<Hobbsee> ubuntu-devel-discuss@lists.ubuntu.com is probably a good one.
<Keybuk> https://edge.launchpad.net/~ubuntu-devel-discuss
<Keybuk> lol
<Hobbsee> Keybuk: merge the accounts?
<ogra> its all calcs fault !
<Keybuk> Hobbsee: the merge mail probably hit the mailing list
<Keybuk> or maybe the moderation queue
<Keybuk> who has mod access to u-d-d ?
<Hobbsee> cjwatson: may well?
<Hobbsee> i don't, i've only got it to u-d
<asac> StevenK: yes, keep that + the other patch introduced by fta
<cjwatson> Hobbsee: I don't think I do
<Keybuk> listadmin says evand
<asac> StevenK: fix_systray_behavior
 * Keybuk tries to find a duckie who isn't at the QBR festival of love
<StevenK> QBR festival of love?
<lifeless> hi
<Keybuk> https://edge.launchpad.net/~ubuntu-devel
<Keybuk> https://edge.launchpad.net/~ubuntu-devel-discuss
<Keybuk> make those go away please ;)
<Keybuk> Hobbsee: the answer would appear to be No.
<Keybuk> I cannot change the contact address
<Keybuk> \o/ LP
<Hobbsee> Keybuk: why?
<Keybuk> because LP has automatically created accounts for those addresses
<Keybuk> repeatedly it strikes me that LP's auto account creation is more trouble than its worth
<Hobbsee> Keybuk: you can't merge them?
<Keybuk> nope
<Hobbsee> or force a rubber ducky to merge them?
<Hobbsee> but why?
<Keybuk> seems that LP decided they're teams, so they can't be merged
<Hobbsee> teams can still be merged with other teams, surely?
<wgrant> Hobbsee: At ducky request.
<Hobbsee> Keybuk: so requests from ducks fail, i presume?
<wgrant> It was deemed a restricted enough use-case that it wasn't to be exposed in the UI.
<Hobbsee> !!!
<Keybuk> ducks just get OOPS
<Hobbsee> ah
<wgrant> So you need a superduck.
<wgrant> Can't a duck unassign the email address, at least?
 * Hobbsee finds it odd that such a decision was made, when autocreating accounts of teams or people, yet deciding that merging a team to be a corner case.  Because in almost all cases of teams created, they will want to be merged with a real team at some point - whether it exists now or later.
<Keybuk> more OOPS
<Hobbsee> yay, launchpad.
<Hobbsee> Keybuk: okay, i'll attempt to poke.  i'm really not liking the fact that people can spam 50 or so people with a click of a button.
<wgrant> I guess this is the same reason that MOTU Media maintains every package in universe.
<wgrant> Er, all modified packages.
<Hobbsee> probably
<Hobbsee> oh, wait.  they attempted to get that one merged, and i don't remember the problem being an oops.
<Hobbsee> but i don't remember what it was...
<wgrant> It wasn't supported at the time.
<ScottK> Argh.  Are the Perl Artistic license and 4 clause BSD (with the advertising clause) compatible?  I think so, but am looking for second opinions.
<Riddell> mvo_, pitti: bug 241431 SRU for feisty looks ok to accept, should I?
<ubottu> Launchpad bug 241431 in update-manager "edgy to feisty upgrades fail due to use of old-releases" [Medium,In progress] https://launchpad.net/bugs/241431
<mvo_> Riddell: I proposed it so I should probably not be the one who has the final say. it would be nice
<mvo_> Riddell: pitti is on leave today
<mnabil> guys, how can i revert the last ubuntu update, i mean i need to return the state before the last update(remove the last update)
<Keybuk> tests/com.netsplit.Nih.Test_impl.h:31: warning: array âmy_interfacesâ assumed to have one element
<Keybuk> gnargh
<Keybuk> I hate C sometimes
 * Keybuk tries to remember how to declare in the header that there's an array of pointers in the C file
<dholbach> thekorn: is there a bigger problem with the HTML connector right now? :)
<sistpoty|work> Keybuk: s.th. like "extern (int*)[20];" iirc... not to sure if I got the braces right though
<Keybuk> it's the [20] bit I don't want to do
<Keybuk> since the struct is just declared *foo[] = { ... }
<thekorn> dholbach, oh, dont know, let me check
<Riddell> ScottK: I would expect so, might depend on the exact form of mixing
<Riddell> mnabil: support in #ubuntu
<nxvl> good morning!
<dholbach> thekorn: http://paste.ubuntu.com/24205 :-/
<dholbach> (that's with pylpbugs/main
<dholbach> )
<ogra> Laney, hey
<Laney> ogra: Hi
<sistpoty|work> Keybuk: int (*foo)[] ?
<ogra> Laney, did you check debian for the xaos update ? can we just sync it ?
<Laney> ogra: It's been orphaned, there is no update
<sistpoty|work> erm... my foo is the name of the variable not of the type though
<Laney> ogra: I do plan on working with whoever to get my new version in Debian though
<ogra> Laney, well, i was pondering to take it over in debian, since it falls into the edubuntu package list i maintain anyway
<ogra> but i'm extremely busy atm so it might still take a week before i can look into that
<ogra> Laney, are you upstream ?
<Laney> ogra: Oh, well I'm almost ready to upload my new version to LP. Perhaps you could use that when you get time
<Laney> ogra: No, just looked through the list on ubuntuwire and picked that out
<ogra> can you ping upstream to take your fixes ?
<Laney> Shall do
<thekorn> dholbach, ok thanks, this is fixed in my intrepid.merge branch,
<sistpoty|work> Keybuk: that works only as argument of a function of course... you can't declare a variable like that (since no storage size)
 * dholbach hugs thekorn
<dholbach> awesome
<ogra> Laney, thanks a lot :)
 * ogra hugs Laney 
<Keybuk> sistpoty|work: sure you can, storage size is inferred from the initialisation ;)
 * Laney hugs ogra
<Laney> ogra: Are you a DD?
<sistpoty|work> Keybuk: oh, you want to initialize it in the header?
<ogra> nope, only UD ...
<Laney> Bah, OK
<Keybuk> no, initialise in the C, but make it extern
<Laney> Was hoping you would be able to sponsor it ;)
<Laney> But no matter
<thekorn> dholbach, I hope to merge this two branches soon
<ogra> but xaos woul be a good opportunity to go for DD :)
 * thekorn hugs dholbach 
<ogra> Laney, i can find someone
<sistpoty|work> Keybuk: I'm not too sure that's possible... from what should any other compilation unit know the storage size then?
<Laney> mmk
<dholbach> thekorn: it'd be nice to get at least into the PPA too
<Laney> Just porting the patches to quilt, then will put the diff up
<Keybuk> /usr/bin/ld: Warning: size of symbol `my_interfaces' changed from 8 in test_com_netsplit_Nih_Test_object-test_com.netsplit.Nih.Test_object.o to 24 in test_com_netsplit_Nih_Test_object-com.netsplit.Nih.Test_impl.o
<Keybuk> oops
<Keybuk> :p
<thekorn> dholbach, https://edge.launchpad.net/~bughelper-dev/+archive has all these changes (~ppa4 or something)
<dholbach> ah ok
<Keybuk> sistpoty|work: trouble is I can't find any way to make it visible at al
<nxvl> dholbach: would you please do one more build for me?
<Keybuk> only way so far
<Keybuk> is in the .h declare it as a **
<Keybuk> in the .c declare static as a *[] and then a second extern as ** taking its address
<dholbach> nxvl: can you ask somebody else? I'm quite busy right now - I can do it later
<nxvl> dholbach: ok, thanks anyway :D
<nxvl> did someone has an amd64 machine and want to build a package and run lintian for me?
<sistpoty|work> Keybuk: you mean s.th. like that? http://paste.ubuntu.com/24209/
<nxvl> sistpoty|work: i think i have it
<sistpoty|work> nxvl: excellent!
<nxvl> sistpoty|work: and raphink says he has test it
<Keybuk> sistpoty|work: except I don't want the [2] in the header
<nxvl> sistpoty|work: and now it works
<sistpoty|work> Keybuk: you can't do that. otherwise gcc cannot determine the storage size of instance_of_foo (and e.g. the sizeof would fail)
<Keybuk> sistpoty|work: so how do I use that array outside of that C file? :)
<Keybuk> even declaring it static foo **instance_of_foo = {
<Keybuk> doesn't work
<sistpoty|work> Keybuk: oh, I forgot to declare the type foo in the header
<sistpoty|work> (instead of in the c file)
<sistpoty|work> Keybuk: then you can simply use s.th. like "instance_of_foo[1]->x"
<Keybuk> ?
<sistpoty|work> Keybuk: http://paste.ubuntu.com/24213/
<sistpoty|work> meh... pastebin doesn't like me
<sistpoty|work> Keybuk: now: http://paste.ubuntu.com/24214/
<Keybuk> sistpoty|work: you still have [2] in the header
<Keybuk> which is the bit I don't want :p
<sistpoty|work> that's where it gets tricky *g*
<sistpoty|work> Keybuk: I'm not entirely sure, but imo "extern struct foo **instance_of_foo;" should be the right thing
<Laney> ogra: New .diff.gz uploaded if you're interested :D
<ogra> i'll take a look if i find time
 * ogra is swamped with building some custom images
<Laney> Well I've subscribed the sponsors queue anyway, so no need for you to specifically review it
<Laney> Just though you might like to know
 * Laney is out for a bit, bye all
<sistpoty|work> Keybuk: hah: http://paste.ubuntu.com/24220/
<sistpoty|work> (I was not aware c allows such wonky things in the first place)
<cjwatson> sistpoty|work: C allows a significant amount of wonk, as long as it fits neatly into machine implementations ;-)
<sistpoty|work> heh
<geser> has someone an idea why the build of libgnupg-interface-perl fails? (http://launchpadlibrarian.net/15667866/buildlog_ubuntu-intrepid-i386.libgnupg-interface-perl_0.36-1_FAILEDTOBUILD.txt.gz)
<geser> I don't have an idea why it can't find gpg which is installed
<Hobbsee> geser: no build-dep on gnupg?
<Hobbsee> oh, hm.
 * Hobbsee wonders if the gpg is actually in the chroot itself, or only gets used before the unpacking, and the unpacked bits get fed to sbuild.
<Keybuk> sistpoty|work: that doesn't work
<geser> Hobbsee: dpkg-source is run inside the chroot, right?
<persia> Hobbsee: In the repo sbuild, it unpacks in the chroot, without a secondary chroot.
<Hobbsee> ahhh
<Hobbsee> geser: i don't know the internals of sbuild :)
<geser> I wander also about the "sh: gcc: not found" message (but I guess it's unrelated)
<geser> s/wander/wonder/
<sistpoty|work> Keybuk: hm? works in the test case... are you using -D_FORTIFY_SOURCE? (I could assume that would implicitely add a sizeof then, and hence would bail out)
<Keybuk> I am
<sistpoty|work> Keybuk: hm... then I can only think of a little trick to still make it work... give me a sec
<Keybuk> the only way I could come up with was declaring it static in the .c
<Keybuk> declaring a ** that took the address of it
<Keybuk> then making that extern
<Keybuk> oh, great
<Keybuk> the laptop suspended mid-update
<persia> On the list of things that should block suspend: add "high CPU or IO load", which often means one went for a beverage whilst waiting.
<Keybuk> that's not the problem
<Keybuk> the problem is that the laptop currently doesn't want to resume from suspend
<ogra> i think g-p-m has a gconf key for that
<ogra> to check for CPU usage before suspending
<ogra>  /apps/gnome-power-manager/general/check_type_cpu
<ogra> silly name
<Ng> what if you have a stupid screensaver going? it'll never suspend
<Ng> shouldn't the update thing be emitting the suspend inhibiting signal?
<ogra> thats why its disabled by default i guess :)
<persia> ogra: Right.  It's just whether we turn them on.  If we didn't suspend for all the possible reasons, we'd not often suspend.
<persia> Ng: On the device I suspend most often, I have the screensaver configured to only load on mains power.  If I'm on battery, I'd rather suspend than do a screen-saver cycle (mind you, it takes ~1 sec to wake up, which helps).
<ogra> persia, i dont maintain g-p-m anymore so i rarely look at it nowadays :) but that key was never enabled ...
 * ogra finds the network_sleep key and wonders why we still use pm-utils scripts to shut down NM on suspend
<Ng> ogra: could be because we remove network modules too
<ogra> well, then we can leave the list of modules in SUSPEND_MODULES and not maintain the extra scripts
<ogra> pm-utils and g-p-m have proper functions for that, no need to duplicate them
<sistpoty|work> Keybuk: yes, your solution seems the best one imho
<geser> Hobbsee: please give-back pbuilder. Thanks.
<Hobbsee> geser: given back
<MacSlow> how can I best inject a freshly built goffice (from my PPA) in my intrepid-pbuilder environemnt?
<MacSlow> can I just extend my /etc/apt/sources.list under the pbuilder-intrepid environment with my PPA?
<geser> add your PPA to your pbuilder
<MacSlow> geser, ah ok
<sistpoty|work> cya
<MacSlow> hm... the build did not automatically pick up the goffcie 0.6.3 from my PPA while trying to build gnumeric 1.8.3
<MacSlow> but I guess I found the reason
<seb128> build-depends not strict enough?
<ogra> PPAs are not signed ....
<ogra> you will likely run into probs with any autobuilder (i.e. pbuilder) wih that
<Hobbsee> MacSlow: did you, by any chance, edit your /e/a/sources.list when logged into pbuilder, then quit that, then run pbuilder build foo.dsc?
<MacSlow> Hobbsee, I know that his kill all my changes to it... as it recreates the environment from scratch each time
<MacSlow> Hobbsee, but right now I'm staying logged in and do all the changes in one session
<Hobbsee> MacSlow: that's correct, but i don't think that answered my question?
<Hobbsee> ah right.
<Hobbsee> MacSlow: i presume you ran an apt-get update after editing the sources list, inside?
<MacSlow> Hobbsee, edited sources.list -> apt-get update -> apt-get install ...
<Hobbsee> ogra: it'll whine, sure, but i didn't think it was a terminal error?
<MacSlow> and now I've my goffice 0.6.3 from my ppa installed
<ogra> Hobbsee, for me it stops then ...
<Hobbsee> ogra: oh.
<MacSlow> ogra I just got a warning and said "Yes" to continue with the installation
<ogra> oyu have to set the pbuilder apt opts to allow unauthenticated
<ogra> oh, right, if yu do that nteractive :)
<Hobbsee> MacSlow: for one thing, you dont' want to install anything extra, before you run the build.
 * ogra has scripts that run various pbuilder thingies ... these will hang forever 
<MacSlow> Hobbsee, but apart from what I do now I don't see how I could test building my merged gnumeric
 * Hobbsee is also confused at the order you've done things.
<MacSlow> it needs goffice 0.6.3
<Hobbsee> MacSlow: to build?
<jengelh> kirkland:
<MacSlow> goffice 0.6.3 is not yet publicly available
<Hobbsee> oh, that's right, you have to do fun stuff with that.
 * Hobbsee hasn't had the fun of building an unreleased kde for a while.
 * MacSlow has a different idea of fun
<MacSlow> :)
<ogra> Hobbsee, you should try a mobile build :) they come from ports, -updates, -proposed and PPA to build whole systems
<ogra> now thats the real fun
<MacSlow> building Xorg if far more satisfying
<Hobbsee> ogra: i'd probably just change the sources list, use --save-after-login, and then use the standard pbuilder build foo.dsc, at that point.
<Hobbsee> for bonus points, by creating a mobile pbuilder, with the repositories set up
<ogra> heh
<Hobbsee> which is far simpler, in the long run, then fudging around inside pbuilder.
<tedg> I haven't tried, but does a PPA include itself in the build environment?
<Hobbsee> tedg: yes
<tedg> Hmm, that means one should be careful when moving packages from a PPA to a distributed repository.
<Hobbsee> correct.
<MacSlow> I still get "dpkg-buildpackage: failure: debian/rules build gave error exit status 2"
<Hobbsee> MacSlow: that's akin to saying "something died here."
<MacSlow> from trying to "dpkg-buildpackage -j4 -rfakeroot" gnumeric
<Hobbsee> MacSlow: -v
<Hobbsee> (as in, look higher0
<MacSlow> xgettext: error while opening "./POTFILES.in.temp" for reading: No such file or directory
<MacSlow> ERROR: xgettext failed to generate PO template file. Please consult
<MacSlow>        error message above if there is any.
<MacSlow> make: *** [configure-stamp-gtk] Error 1
<MacSlow> make: *** Waiting for unfinished jobs....
<MacSlow> hm...
<MacSlow> still missing something from my pbuilder-environemnt?
<seb128> MacSlow: the build likely doesn't like the -j option
<seb128> would be an upstream bug and not the first one to have the issue
<seb128> try not using -j and see how it builds
<MacSlow> seb128, so gnumeric doesn't like parallel compilation?
<MacSlow> just started it without -j
<seb128> that would be my bet, but just guessing I didn't look at the issue
<MacSlow> compiling now
<MacSlow> phew
<MacSlow> /usr/bin/ld: /usr/lib/libgoffice-0.6.a(goffice.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
<MacSlow> /usr/lib/libgoffice-0.6.a: could not read symbols: Bad value
<MacSlow> not good
<cjwatson> oww, localedef is hideously complicated inside
<cjwatson> I think I might be close to doing something about its memory use though
<ion_> Nice
<cjwatson> it turns out that what it's doing is keeping a big table in memory of the byte representations of all the possible characters in the current character set
<cjwatson> which, unfortunately, due to the locale definition file format, it pretty much has to do (well, it might be able to use an mmapped temporary file I suppose)
<cjwatson> but it could represent contiguous ranges of characters with "contiguous" byte representations much more efficiently than it currently does, I think, at the cost of somewhat more painful code
<bmhm> Hello. Please set Bug 244591 to urgent/critical.  It makes Pidgin useless and may make People go away from ubuntu.
<ubottu> Launchpad bug 244591 in pidgin "Cannot connect to ICQ ("The client version you are using is too old.")" [Undecided,Confirmed] https://launchpad.net/bugs/244591
<bmhm> Hello, some dev around?
<cjwatson> bmhm: IRC is an asynchronous medium; please be patient. (I've set the importance to Critical, but don't get overly fixated on importance please.)
<bmhm> cjwatson: I know IRC, I am sorry for my inpatience. I just didn't want my message to get "lost"
 * ogra sighs 
<ogra> why is the whole of X depending on cpp
<darkfile> https://bugs.launchpad.net/ubuntu/+source/pidgin/+bug/244591
<ubottu> Launchpad bug 244591 in pidgin "Cannot connect to ICQ ("The client version you are using is too old.")" [Critical,Confirmed]
<cjwatson> darkfile: scroll up
<cjwatson> darkfile: oh, it was just before you arrived - anyway, bmhm already mentioned that
<darkfile> cjwatson, im not in here long enough :)
<darkfile> do you know if this will be fixed for 7.10, too?
<darkfile> or will i have to upgrade to 8.04?
<cjwatson> for a start, I'm not a Pidgin developer, but, on the face of it, a reasonable fix for this kind of thing would be eligible for updates to all stable releases
<cjwatson> obviously it needs somebody to do the work first, though
<darkfile> ok thanks for the info
<alex-weej> can i get any ubuntu package from bzr?
<Laney> cjwatson: I'll have a go at the SRU once a fix is out if that's OK?
<cjwatson> sure
<cjwatson> alex-weej: not yet, though we're working on that
<alex-weej> cjwatson: that would be absolutely rock
<alex-weej> i really wish i could do all my development in Ubuntu rather than having to build everything an the kitchen sink in JHbuild then port changes to Ubuntu packages
<cjwatson> alex-weej: https://blueprints.launchpad.net/ubuntu/+spec/distributed-development-importer
<cjwatson> we'll be doing it in stages, so it won't be fully joined up at first
<alex-weej> that's cool. only concern is that, in some cases, even the development packages we have are way behind upstream
<cjwatson> right, we'll get further along eventually; baby steps :-)
<cjwatson> ultimately we want to be able to update to new upstreams by 'bzr merge' or similar
<ogra> alex-weej, https://wiki.ubuntu.com/NoMoreSourcePackages
<cjwatson> the spec ogra quotes is an older version of a similar idea
<ogra> outdaed but essentially still the target
<alex-weej> right. awesome. really glad people are working on it
 * ogra updates his links
<cjwatson> actually that's sort of a middle phase rather than the target
<cjwatson> it's a possible benefit we might be able to pick up along the way
<slangasek> cody-somerville: hi, why have you milestoned bug #220899?  this seems like something that should be reasonable to fix in an update after the point release, no?
<ubottu> Launchpad bug 220899 in xubuntu-default-settings "[Hardy] Wrong default image browser" [Medium,Fix released] https://launchpad.net/bugs/220899
<Keybuk> that's weird
<Keybuk> second time the computer has hung/crashed since the hardy kernel update
<lool> cjwatson: Hey, mobile-meta made it to the archive and I proceeded according to plan; http://people.ubuntu.com/~ubuntu-archive/component-mismatches-mobile.txt seems to be empty, could you tell me where I can find what generates it to check whether it's still working?
<ogra> lool, it has the generation date at the top usually the script is called anastacia (at least is once was, not sure if LP has taken over that part as well since i last looked) i'm not sure where its stored though
<ikonia> gents has anyone got a solid understanding of how gnome/hal deals with automounting file systems
<ikonia> I'm trying to troubleshoot an issue for an ubuntu-user in #ubuntu, and the feedback / information he's giving me suggests that gnome/hal now mounts the disks in userspace, I'm struggling to find informtion on this so if anyone has first hand knowledge on this it would be appriciated
<Kopfgeldjaeger2> Will there be an SRU for the pidgin/icq issues?
<Laney> Kopfgeldjaeger2: Yes!
<laga> what about kopete? ;)
<laga> ooh, there is a workaround for kopete
<slangasek> cody-somerville: bug #228784 also awaits SRU verification for 8.04.1
<ubottu> Launchpad bug 228784 in xfce4-session "xfce4-session-logout : buttons not localized except "Restart" and "Cancel"" [Low,Fix committed] https://launchpad.net/bugs/228784
<apachelogger> laga: shouldn't be necessary
<slangasek> cody-somerville: actually, I meant bug #232364; so both of them do, really :)
<ubottu> Launchpad bug 232364 in xfce4-utils "dbus-launch hangs at session start waiting on socket output in libxcb" [Critical,Fix committed] https://launchpad.net/bugs/232364
<apachelogger> laga: kopete has an auto-update feature kicking in once the connecation failed
<apachelogger> considering it works properly ;-)
<slangasek> blah, an auto-update feature that hasn't been disabled in the packaging?
<laga> apachelogger: yeah, i saw that.
<laga> apachelogger: after i asked i here :)
<slangasek> so anyone who uses kopete on Ubuntu systems is subject to updates that haven't been QAed through Ubuntu?
<apachelogger> slangasek: yes
<apachelogger> though
<apachelogger> this update feature only effects icq
<apachelogger> and actually only it's desktop file, defining the version stuff
<apachelogger> slangasek: and I can say KDE also has pretty good QA ;-)
<slangasek> yes, the point is that it's not been QAed in situ
<slangasek> there's no guarantee that the builds have been tested to work with Kubuntu itself, as opposed to KDE generally
<apachelogger> sladen: there is no build
<apachelogger> slangasek: ^
<apachelogger> sladen: sorry
<apachelogger> slangasek: http://kopete.kde.org/oscarversions.xml
<slangasek> ah
<apachelogger> once the login failed it downloads that file and if necessary adapts the versions in the desktop files
<asac> tjaalton: do all common intel chipsets get EXA by default?
<asac> bryce: ^^
<asac> (in hardy)
<bryce> asac, correct
<asac> bryce: how sure?
<asac> (percentage) :)
<bryce> 85%
<asac> not much ;)
<asac> not enough ... hmm
<bryce> there may be some internal logic to fall back to XAA for some chips, I don't remember
<asac> jcastro: what graphics chipset do you have?
<ogra> (==) intel(0): Using EXA for acceleration
<bryce> asac, what prompts the question exactly?
<asac> jcastro: i remember that you saw the ffox rendering bug until you flipped to EXA on your intel
<jcastro> I have an i965
<ogra> ogra@osiris:~/Devel/liveusb-creator$ lspci|grep -i vga
<ogra> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
<asac> jcastro: so for you EXA was not enabled by default back in london?
<jcastro> I don't remember
<asac> jcastro: are you still on hardy?
<jcastro> I think it was, because looking at my xorg.conf right now shows I enabled it and added that greedy thing to it
<jcastro> nope, intrepid
<asac> jcastro: ok. i guess that means that not all intel chips use(d) EXA :)
<asac> bryce: SRU verification talk raised this question
<jcastro> asac: you can of course do what you want to it during the next sprint.
<jcastro> not that that helps you right this instant
<asac> jcastro: no. that would be too late ;) ... can you restart X with the EXA line removed and see if you still use EXA?
<jcastro> sure.
<asac> (in Xorg.0.log)
<bryce> you shouldn't need the greedy line either
<asac> what is greedy?
<bryce> if you had that in there it makes me think you'd configured those back before we switched to EXA by default
<asac> bryce: when was that?
<jcastro> bryce: I think so as well
<bryce> it's a memory migration heuristic, that is a workaround to a bug that was preventing us from switching to EXA by default
<jcastro> Option "ExaNoComposite" "true"
<jcastro> do I need that?
<asac> bryce: ok. so when did you flip the switch?
<asac> jcastro: i guess the idea is that you shouldnt need any option ;)
<jcastro> heh
<bryce> jcastro, that's for preventing compiz from going, and I would imagine you'd only need that if you had a severe problem with compiz for some reason
<bryce> jcastro: so in theory you shouldn't need that, unless your HW has some weird bug
<asac> heh
<ogra> jcastro, the idea is that you shouldnt need an xorg.conf ...
<ogra> especially as US american with the right default keymapping
<bryce> asac the switch was made around the end of march
<jcastro> asac: ok, it's all using EXA according to the log
<jcastro> ogra: I thought we weren't quite there yet for going xorg.conf-less
<jcastro> though I can try that next if you guys want
<asac> jcastro: ok thanks
<ogra> we need it for keymap and mouse settings
<jcastro> does it default to US or something?
<ogra> but with en_US you shuldnt need the keymap part and with a default laptop touchpad the mouse settings shouldnt be needed either
<jcastro> actually, I won't try it, I'm in mid-move and this is my only working PC at the moment
<ogra> just move it to xorg.conf.bak and try ;)
<ogra> ah, indeed
<ogra> well, it works since gutsy
<jcastro> find another victim, I'm actually on vacation and need to finish packing. :D
<bryce> jcastro, it will default to US
<slangasek> Ubuntu 8.10 will ship with a GPS dongle to auto-detect your keyboard preference based on latitude and longitude
<ScottK> But only if you're outside where the sattelites can see you.
<LaserJock> slangasek: but what if I'm an American in Europe and want the US keyboard? :-)
<LaserJock> me wonders what keyboard would be set in Antarctica
<ogra> slangasek, can we get these dongles as totrrents please to not make the shipment costs explode ?
<slangasek> LaserJock: when in Rome, swear at your keyboard like the Romans
<LaserJock> slangasek: lol
<slangasek> ogra:
<slangasek> ogra: I'll see what I can do
<ogra> \o/
<Chipzz> slangasek: wrt Kopete QA... I have had the same reservations about firefox
<slangasek> Chipzz: is firefox auto-updating itself in Ubuntu...?
<Chipzz> slangasek: shouldn't ubuntu patch firefox to not have the auto-update feature at all?
<slangasek> haven't we?
<Chipzz> slangasek: it isn't, but there's an option for it which can be turned on
<Chipzz> hrrrm I though it wasn't... maybe need to check
<slangasek> oh; well, if users want to shoot themselves in the foot like that, I don't see the problem
<slangasek> removing the feature entirely is just more likely to cause unnecessary friction with upstream
<Chipzz> fucking up the packaging system is not something we should allow IMHO
<Chipzz> heh
<Chipzz> mozilla needs to get their heads unstuck from their asses
<slangasek> it doesn't touch the system binaries
<slangasek> unless you run it as root :)
<LaserJock> well, I happen to like having Firefox updates for most things
<LaserJock> but I understand the thought behind turning the auto-update off
<Chipzz> slangasek: if it only works as root, there's no point in having it anyway
<LaserJock> I'm more concerned with all the extentions
<slangasek> Chipzz: I didn't say it only works as root, I said it will only update over the *system* binaries as root
<slangasek> if you run it as a user, I expect it does something horrible like downloading and installing all of firefox into your .mozilla directory ;)
<Chipzz> either way you get a broken system
<Chipzz> LaserJock: yeah, but exactly how many extensions does ubuntu package?
<slangasek> maybe, but users have to opt in to that brokenness
<LaserJock> Chipzz: 10+ I think
<Chipzz> LaserJock: out of... ? several hundreds?
<ogra> Chipzz, do i hear you volunteering ?
<LaserJock> umm yeah, that's the problem
<ScottK> The one package I maintain in Debian/Ubuntu that ships from upstream with auto update capability is missing it entirely in Debian/Ubuntu.  I think it's generally a bad idea for distros.
<LaserJock> if some of your extensions come from Ubuntu but others through the "normal" means it confusing
<Chipzz> ogra: I'm merely pointing out that while updating extensions via our packaging system would be ideal, it's not feasible in practice
<LaserJock> I just use Firefox's method, I don't trust our extensions really
<ScottK> Of course the fact that it uses checkinstall to generate it's updated packages might have influenced my thinking.
<ScottK> (my package, not FF).
<Chipzz> also, won't installing an extension via the packaging system install it for all users?
<LaserJock> presumably
<ogra> likely
<Chipzz> which is not something you want anyway
<Chipzz> more mozilla suckage
<LaserJock> right
 * Chipzz repeats above statement about mozilla, heads, and asses :P
<LaserJock> so I'd rather let Firefox handle it
<Chipzz> problem is
<Chipzz> in a lot of ways firefox is mainly a windows app
<Chipzz> windows lacks proper package management
<Chipzz> mozilla devs work around that by features such as auto-update
<Chipzz> with no regard for linux
<LaserJock> well, I doubt they'd do it much differently if it was more linux-centric
<Chipzz> macosx has the same problem
<slangasek> kees: where does atlas's debian/rules weigh in, at 1145 lines?
<asac> Chipzz: whats you issue here?
<Chipzz> asac: mozilla wanting to be something that's already provided by proper linux distro's (ie: proper package management)
<Chipzz> and the possible havoc ensuing from users updating firefox through it
<asac> Chipzz: we dont allow that
<asac> only extensions are auto updated
<Chipzz> asac: that's actually patched out?
<asac> (if installed in profile)
<asac> Chipzz: 1st. its disabled by upstream if you dont run as root (e.g. if not having write permissions)
<asac> 2nd. its patched out by us (explicit upstream request) to prevent root from auto updating app
<Chipzz> ah k
<Chipzz> how long has that been patched out?
<Chipzz> I seem to recall seeing that checkbox, but that may have been in an old version
<asac> Chipzz: it was there in b5 (if you start ffox as root)
<Chipzz> my laptop is still at feisty I think, so would have been ff2
<asac> Chipzz: in ff2 it was always disabled
<asac> unless you flipped it on by editing system config filed in editor
<Chipzz> hrrrm
<Chipzz> didn't do that
<Chipzz> where did I get that idea then?
<asac> Chipzz: most likely you confused the app-auto-update feature with the extension-auto-update thing
 * Chipzz boots laptop
<asac> Chipzz: but to be fair, i cannot speak for the initial edgy release. just since feisty.
<Chipzz> asac: just checked
<norsetto> asac: 0.6.3 will be out today, where should I upload the gnome-mplayer/gecko-mediaplayer packages which I would like you to review for debian?
<Chipzz> asac: the checkbox exists but is grayed out
<Chipzz> version 2.0.0.10+2binonly-0ubuntu1.7.10.1
<asac> Chipzz: yeah
<asac> its deactivated
<Chipzz> asac: with you as packager ;)
<Chipzz> shouldn't we just not show that checkbox at all instead of greying it out?
<asac> Chipzz: i dont know ;). i doubt that it creates lots of confusion for the normal user ;)
<Chipzz> asac: btw, what's your opinion on packaging extensions?
<asac> Chipzz: i addressed that quite extensively in the beginning of the last FF extension packaging session i gave during openweek
<asac> Chipzz: the logs are https://wiki.ubuntu.com/MeetingLogs/openweekhardy/ExtensionsPackaging
<kees> slangasek: hehe, I'm not sure.  I suppose I could generate some kind of stat.  :)
<Chipzz> asac: reading that page... but won't installing extensions as packages enable them for all users?
<asac> Chipzz: thats one deficiency, yes.
<asac> at some point we should do something about that
<ogra> depends on the extension ...
<ogra> parental control is surely something that makes sense to have installed systmwide
<Chipzz> asac: hence why I asked about your opinion on packaging extensions ;)
<Chipzz> ogra: but for example flash-blocker isn't
<ogra> and i bet there are others where its sane to have them not per users
<ogra> right
<Chipzz> especially on large sites
<asac> Chipzz: my opinion should be clear from the logs ;)
<ogra> is likely only a minority
<slangasek> Daviey, superm1: images aren't finalized just yet, but I wanted to check with you guys whether you'll have some spare cycles for testing 8.04.1 alternate ISOs for mythbuntu
<asac> Chipzz: i wont teach people how to package if I'd think its a bad idea ;)
<Chipzz> asac: I'm not saying it's a bad idea :)
<asac> Chipzz: so you dont ask about opinion, but vision?
<Chipzz> but like you said, having them enabled for all users is a deficiency
<asac> Chipzz: yes, its a lack of flexibility
<Chipzz> what I was most curious about was your opinion on the enabling-for-all issue
<asac> Chipzz: its not really a blocker. users usually can disable their extensions
<asac> even if installed globally
<Chipzz> asac: maybe the extensions should be disabled by default then?
<asac> Chipzz: why?
<Chipzz> asac: prevent unwanted side-effects on large sites?
<Chipzz> asac: consider the case of a university using ubuntu, with the flash-blocker extension packaged
<asac> Chipzz: as i said above. the only deficiency i see for the enable-ing-for-all approach is a lack of flexibility
<Chipzz> I'm pretty sure that would cause a whole lot of confusion for a whole lot of users
<Chipzz> "Why doesn't flash work?"
<asac> Chipzz: yeah. if the admin thinks its a good idea to install flash blocker for all, its his decision
<Chipzz> asac: my pov is the "making available" pov :)
<asac> Chipzz: thats not the current use-case covered
<Chipzz> admin installs a huge load of extensions using the packaging system, all disabled by default
<Chipzz> user wants to use an extension, just clicks on enable
<asac> Chipzz: yes, that might be a valid use-case, but still a corner case
<Chipzz> asac: well what it boils down to I think is there are 2 use-cases
<asac> most users want to install the extension and use it
<Chipzz> 1) single user install
<Chipzz> 2) large site deployment
<asac> 1a) home install (a few family users)
<ogra> 1.5) LTSP server  :)
<asac> for 1* its ok
<asac> for 2 it could be better, but that is something the admin has to take care of
<asac> for now
<Chipzz> ogra: LTSP is exactly what I had in mind with 2)
<Chipzz> ;)
<ogra> well, thats rarely large as in enterprise :)
 * cody-somerville notes that whoever highlighted him earlier today needs to do so again: freenode netsplits pushed it out of buffer
<asac> Chipzz: what you want is an integrated installer
<asac> Chipzz: the right way is to make the globally available extensions accessible for users in the firefox addons "install extension" tab
<Chipzz> ogra, what are your thoughts on this? :)
<asac> Chipzz: there is no real point of discussing this ;)
<Chipzz> asac: what will that do? copy the extenion to ~/.mozilla ?
<asac> disabling extensions you installed by default will not happen
<asac> better integration of extension install wizard: yes, but needs cycles
<asac> Chipzz: that is undecided and needs to be specified in a specification unless someone just does it
<ogra> Chipzz, as i said before i see it valid to have extensions systemwide on a pre extension base, for some it makes sense for some it doesnt
<ogra> *per
<emgent> night.
<ogra> things like adblock or any parental control extensions surely make sense in that context
<Chipzz> that's what I was thinking
<Chipzz> but take flash-block as an example
<ogra> or even flashblock since the user is always able to installflash in ~
<Chipzz> how would you handle that on an LTSP install?
<ogra> heh
<asac> Chipzz: for now we need to fix the addons dialog to support multiple search/install methods.
#ubuntu-devel 2008-07-02
<Chipzz> asac: probably :)
<ogra> well, i'm rather struggling with having flash than not having it in most cases
<slangasek> heh :)
<ogra> but if you want to block it on your ltsp server it definately makes sense to have it globally
<Chipzz> ogra: let's for the sake of argument say flash works ;)
<asac> Chipzz: your argument is really far away
<asac> Chipzz: if you have cycles and can code mozilla, join #ubuntu-mozillateam :)(
<ogra> since you might do that because of company policy or school policy
<asac> and join forces in fixing the plugin + extension wizard framework for firefox 3.1
<Chipzz> ogra: I'm more thinking along the lines of: a lot of users will want to have this, so from a maintainability pov (ie not having hundreds of (possibly out-dated) copies of the extension in ~/.mozilla)
<ogra> right
<Chipzz> asac: but you haven't answered my question; ie how would that work? would the plugin get copied in ~/.mozilla ?
<asac> Chipzz: that doesnt matter at this stage
<asac> Chipzz: and that info wouldnt help you.
<asac> Chipzz: whatever is needed needs to be done ;)
<asac> most likely it wont be copied in .mozilla
<asac> maybe it will ... as long as its auto updated if admin updates the global package ;)
<Chipzz> asac: well, like I said, it matters from a maintainability pov
<Chipzz> ie possibly out-dated
<asac> Chipzz: "... as long as its auto updated if admin updates"
<Chipzz> yeah
<Chipzz> asac: don't get me wrong, I'm not trying to be annoying or get on your nerves ;)
<Chipzz> just considering a possible use case
<asac> Chipzz: that use-case is well understood
<asac> Chipzz: next step would be to write this as a spec
<Chipzz> asac: uhu
<Chipzz> but anyway, I'm allmost of to bed :)
 * ogra sees Chipzz's whois info and wonders what he did with the former versions ...
<Chipzz> ogra: ah yes, some old bullshit :) I should probably nuke that ;)
<ogra> heh
<Chipzz> has been in there for years :P
<Chipzz> that's what you get from keeping the same homedir for over 10 years :P
<slangasek> I thought what you get for keeping the same homedir for over 10 years is a self-aware fvwmrc
<superm1> slangasek, yeah just throw a url over and should be able to run through it at least once at some point
<Chipzz> slangasek: lol :)
 * Laney is patching pidgin now
<lamont> interesting... alsactl, brltty, umount.hal, vstp, wpa_supplicant all live in /sbin and use libs in /usr/lib... --> fail
<lamont> (ok, and {mkfs,fsck}.cramfs too... for completeness)
<slangasek> on the bright side, grep didn't start depending on libpcre until it was moved to /lib ;)
<lifeless> lamont: Score!
<lamont> lifeless: isn't it though
<lamont> the cramfs one has been around for a while
<lamont> http://bugs.debian.org/338604
<lamont> it won't be 3 years old for another 4 months or so
<TheMuso> The brltty issue I can see what I can do to get that sorted, as I am in contact with upstream, and the DD responsible for the package as well.
<TheMuso> Hrm that may not be easy to solve, since brltty tracks the mouse via gpm.
 * Hobbsee sighs at ICQ.
<calc> slomo: ping
<Hobbsee> slangasek: re: kopete, fwiw, i've pushed patches for that issue direct from upstream kde into the stable releases at the time, with no regressions.
<calc> slomo: if you see this can you merge mono 1.9.1+dfsg-2 it has SIGSEGV fix for AMD64 and other fixes that are important
<Laney> Debdiff for pidgin in bug #244591 for sponsoring if anyone's interested
<ubottu> Launchpad bug 244591 in pidgin "Cannot connect to ICQ ("The client version you are using is too old.")" [Critical,Confirmed] https://launchpad.net/bugs/244591
<slangasek> Hobbsee: patches for the ICQ issue?
<Hobbsee> slangasek: the version change #'s, yes.
<Hobbsee> it didn't have an autoupdater when i last looked at it, though.
 * Hobbsee still has nfi why they keep changing the number required every once in a while, when the protocol doesn't appear to change - or at least, no other changes seem to be required apart from the version string.
<StevenK> It probably adds the ability to do other things on the server.
<calc> everyone should just switch to gtalk :)
<Hobbsee> calc: ?
<ScottK> I've heard good things about this thing called IRC.
<Hobbsee> sure, but why bump the version number in that case?  it hasn't actually had any changes, so any new code on the server side will work with the older version of pidgin.
 * StevenK doesn't know what IRC is
<StevenK> Hobbsee: Ah, probably because other clients, like the offical one also support the new messages.
 * TheMuso notes that bitlbee never seems to require updates for ICQ...
<calc> IRC = i repeat classes
<StevenK> You say, on IRC
<Hobbsee> TheMuso: now, that's interesting.  i thought it was all clients.
 * calc is out of school already :)
<Hobbsee> StevenK: probably.
<calc> but yea i repeated classes when first finding IRC ;-)
<ion_> On an unrelated note, TheMusoâs ICQ contacts have been surprisingly quiet recently. ;-)
<TheMuso> Hobbsee: Yeah, I've been using ICQ on bitlbee the last few weeks with no issues.
<TheMuso> ion_: True, I idle on it the vast majority of the time, but I am logged in.
<StevenK> Ah, so that's TheMuso's secret. He never logs out of ICQ, therefore never gets the oppurunity to get the error message.
<LaserJock> people still use ICQ?
 * TheMuso tests logging out/in now to see if anything happens.
<Hobbsee> LaserJock: ++
<TheMuso> <@root> oscar - Logging in: Signon: 18444344
<TheMuso> <@root> oscar - Logging in: Connection established, cookie sent
<TheMuso> <@root> oscar - Couldn't log in: SNAC threw error: Busted SNAC payload
<TheMuso> <@root> oscar - Logging in: Logged in
<LaserJock> I just can't get Jabber to work with pidgin, couldn't care less about ICQ ;-)
<saivann> Can a GNOME developer take a look at patches in this bug report : https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/187540
<ubottu> Launchpad bug 187540 in gnome-panel "Gnome-panel freeze when 8 windows are open when the panel is on the right" [Unknown,Confirmed]
<saivann> I tested the patches and it works correctly in my case
<Laney> Bug #244591 awaits SRU approval :)
<ubottu> Launchpad bug 244591 in pidgin "Cannot connect to ICQ ("The client version you are using is too old.")" [Critical,Confirmed] https://launchpad.net/bugs/244591
<lamont> so how much pain is it to get a broadcom NIC working under hardy?
<lamont> compaq box with BCM94311MCG
 * lamont waits for the flamage
<calc> wow i can refuse to fix people's computers now on not wanting to violate a law
<calc> apparently we have some really stupid well bribed people here in texas :-\
<calc> if you fix a computer or ask to have a computer fixed by a non private investigator you can be sent to jail for 1yr
<StevenK> You now need to be a private investigator to fix a computer?
<brandonperry> yeah
<brandonperry> it is retarded
 * brandonperry used to be a computer technician
<lifeless> wtf
<ion_> calc: :-D
<lifeless> URL ?
<persia> Is this law related to some disclosure statute, or just gratuitous?
<persia> Bah.  It's interpretive.  http://www.legis.state.tx.us/tlodocs/80R/billtext/html/HB02833F.htm allows retailers to service on-site, and allows lots of other exceptions if security is not the primary area of business for the affected person.  Plus, employees of a firm with any of a PI, law, or accounting license are exempt.
<YokoZar> cjwatson: ping
<YokoZar> cjwatson: Could you please take a look at https://bugs.edge.launchpad.net/hardy-backports/+bug/240755 if you haven't already?  Just a small update that you might of missed since I reopened the bug weirdly rather than filing a new one.
<ubottu> Launchpad bug 240755 in hardy-backports "Please backport Wine 1.0 from Intrepid to Hardy" [Medium,In progress]
<ScottK> YokoZar: I approved a big stack of backports (cleared out the Hardy backlog) on Sunday.  Not sure what order they'll get done in.
<calc> anyone know how to properly branch a bzr repo, i need to branch one from bzr.debian.org into launchpad
<RAOF> calc: Do you want it mirrored, or a one-off branch?
<RAOF> calc: Because if you want it mirrored you can register it on launchpad and LP will mirror it for you.
<calc> hmm, what is the difference?
<calc> i need to commit stuff to the lp one as well
<calc> so i guess not just mirrored
<calc> its for OOo 3.0 packaging
<RAOF> Right.  So, you'd just bzr branch $REMOTE, then bzr push lp:wherever-it-should-go.
<calc> so $REMOTE equals my full bzr+ssh path?
<RAOF> Yes.
<calc> hmm actually i need the other bzr repo to be a subdir of the new one
<calc> is that possible?
<RAOF> I'm not sure what you mean.
<calc> eg debian has the top level dir be the debian dir i need it to be the package dir so i can have a ubuntu dir beside the debian one (same level hierarchy)
<calc> eg ooo-3.0/debian and ooo-3.0/ubuntu
<calc> and the debian bzr has the top level bzr as just the debian dir
<RAOF> That's just naming the branch, though?
<bliZZardz> cjwatson, reg DBus - how is it different from messaging solutions? (i could not find this in the wiki)
<calc> i don't think so?
<calc> instead of top of the bzr branch being debian it needs to be ooo-3.0
<calc> that isn't just naming at least aiui
<calc> because in the ubuntu version i need to also have a ubuntu dir as well which means my top level needs to be one dir higher than how it is setup on bzr.debian.org
<RAOF> Why do you need both the Ubuntu and Debian debian/ dirs in your branch?
<calc> i have to modify the debian dir for ubuntu and some of the ubuntu specific stuff is under the ubuntu dir as well
<RAOF> Isn't the idea to take Debian's debian/, make the Ubuntu changes, and commit that?
<calc> well yea, but we have other files such as artwork, etc that is version controlled for ubuntu and it is under ubuntu dir instead
<calc> i guess to be able to branch it cleanly i would need to move all of that under the debian dir?
<RAOF> calc: Wait - we've got both a debian/ and ubuntu/ dir in the package?
<calc> yes
<calc> is there a way to branch into an already existing repo
<RAOF> No, not yet.
<calc> ok
<lifeless> RAOF: what do you mean?
<calc> some other way to cause my branch to be a subdir of a new repo?
<lifeless> RAOF: by 'not'
<RAOF> lifeless: You can't attach branches to arbitrary subtrees?
<lifeless> do you mean 'bzr join' ?
<lifeless> RAOF: or do you mean 'partial checkout' ?
<lifeless> also, if you consider teh proposed best practice, we want a single tree with the packaging & patches in a loom, not disjoin versioned data
<RAOF> lifeless: Wow.  bzr help join looks like fun.
<calc> lifeless: so its possible to do that then?
<lifeless> calc: well I still don't understand the question
<lifeless> calc: you asked about repositories, and they -exist- to have many branches within them.
<lifeless> RAOF: seems to be suggesting you didn't mean repository
<calc> lifeless: i need to somehow branch the openoffice packaging bzr from bzr.d.o into a subdir of my bzr for OOo 3.0 packaging
<lifeless> calc: are they currently related?
<calc> lifeless: for < 3.0 i was just copying the data over so i want to do it right for 3.0
<calc> and i don't know enough about how bzr works to actually set it up right
<lifeless> calc: I advise doing what you were doing while james_w bring up the toolchain
<lifeless> calc: and send him a mail saying what you were wanting to do :P
<calc> in the past i just hand merged from debian's bzr
<calc> with no history, etc
<lifeless> calc: if they are not related, that will be easiest
<calc> i'm confused
<calc> what is this about related? :)
<lifeless> calc: did the bzr packaging start as a branch off your oo branch?
<lifeless> calc: or vice verca?
<lifeless> calc: or neither
<calc> neither
<lifeless> so, 'bzr merge' doesn't know what to do, or how things should be connected
<lifeless> https://code.edge.launchpad.net/~bzr/bzr-merge-into/trunk
<calc> but for the future i was hoping to try to branch it off from debian if possible to keep history with them
<calc> i don't even know how to begin to make it work
<lifeless> calc: right, and we're trying to do that for 13K branches
<calc> since the top level dirs aren't the same
<lifeless> which is why I'm saying *don't* special case it yet, just pester james_w with your use case
<calc> oh
<lifeless> if we're writing a toolchain to set it up automatically/trivially it isn't a great use of your time to scale the learning curve for one package right now
<calc> ok
<lifeless> IMO of course. If you want to do it regardless - the bzr-merge-into plugin is what you'll need to join the two branches together.
<calc> his email is jamesw@ubuntu.com ?
<lifeless> check the directory
<lifeless> I don't recall offhand
<calc> ok
<StevenK> Aww, bzr join no worky for me
<RAOF> But bzr split works!  Funky.  bzr-mirror.gnome.org just got a lot more awesome.
<lifeless> RAOF: happy to please
<TheMuso> Hrm. Something in the hardy-proposed/updates jungle is broken. http://www.pastebin.ca/1060232
<kahrytan> When is Ubuntu going to start using gfxboot  with grub? openSUSE and Linux Mint have the right idea. grub in ubuntu is ugly. and makes ubuntu look unpolished.
<StevenK> Yay for a drive-by feature request
<RAOF> Wasn't that one of those many apps that won't work on !x86?
<Hobbsee> StevenK: yeah, 'ive had the misfortune of watching that.
<StevenK> I thought it also rendered some machines unbootable
<RAOF> Well, if it failed then presumably the bootloader does, too.
<TheMuso> RAOF: But non-x86 architectures use different boot loaders.
<RAOF> TheMuso: I was sure grub supported more than x86.  Doesn't it?
<TheMuso> RAOF: Grub2 des i think, but I am not sure about grub that Ubuntu uses.
<TheMuso> s/des/does/
<RAOF> The vagries of boot loaders.  Hm.
<dholbach> good morning
<dholbach> bdmurray: can you merge thekorn's fix for making the HTML connector work again or did you find any problems with it?
<Hobbsee> hey dholbach
<dholbach> hi Hobbsee
<cody-somerville> Good Morning folks :)
<nxvl> damn cheap connection
<Hobbsee> nxvl: find a better one?
<nxvl> Hobbsee: there is no better one
<nxvl> just 1 ISP
<Hobbsee> nxvl: where are you?
<nxvl> Lima Peru
<Hobbsee> ahhh, drat.
<nxvl> the governmet sign a contract with Telefonica giving them the monopoly for several years
<Hobbsee> ugh
<jpds> nxvl: I feel your pain.
<nxvl> and it has just expire so the 1st ISPs are shoing up, but they don't have good coverage
<nxvl> 1sts*
<nxvl> jpds: where are you from?
<nxvl> Hobbsee: can you belive that they sell you a bandwith but they only ensure the 10% of it?
<jpds> nxvl: Right now I'm in Spain with Telefonica as ISP (cos they're the only ones who reach here).
<nxvl> heh
<nxvl> :D
<Hobbsee> heh
<slangasek> on the bright side, it could be worse
<slangasek> it could be Telstrafonica
 * StevenK shivers
<nxvl> here we call them timofonica, timo = swindle
<pitti> Good morning
<StevenK> Morning pitti
<nxvl> morning!
<pitti> ogra: versioned sysv-rc dependency> no, it's not needed any more
<TheMuso> slangasek: Even Telstra doesn't give it as badly as what those guys have to experience.
<nxvl> i just love when upstream projects take care of your suggestions/patches
<slangasek> TheMuso: Telstrafonica would be a merger that adopts the worst practices of each, standard operating procedure for corporate mergers :)
<pitti> BenC: I'll get to MIRs today, yes
<TheMuso> slangasek: This is true.
<nxvl> well
<slangasek> pitti: morning
<nxvl> when i call them for techincal support i end up giving them technical support
<pitti> superm1: modaliases> first, the standard kernel one, then /usr/share/jockey/modaliases/, then /usr/share/linux-restricted-modules/<kver>/modules.alias.override/
<nxvl> one time a technical comes here because my bandwith was the half or less than i really have, and he said it was a problem on my router!
<Hobbsee> hey pitti!
<pitti> fabbione, ogra: I didn't try dvb-t drivers on intrepid yet, sorry; I'm still on hardy; if there is a patch I should apply to my driver package, I can do that, of course
<pitti> Riddell: right, looks ok
<pitti> Riddell: accepted
<pitti> hey slangasek, hi Hobbsee, moin StevenK
<superm1> pitti, so for the purposes of nvidia/fglrx, where do you think you would like to see it placed?  Probably the second one.
<superm1> it's sole purpose is for the jockey enablement
<pitti> superm1: the third path was meant for that actually
<pitti> superm1: oh, for dkms packaging?
<superm1> pitti, but the kernel version isn't known
<pitti> superm1: yes, then the second one
<superm1> okay.  i'll upload a fix sometime tomorrow then to use that second one
<bliZZardz> pitti : i was searching for you over the last couple of days.
<pitti> bliZZardz: I was on holiday
<bliZZardz> pitti : yea - your status said that you were away for 4 days. welcome back :)
<bliZZardz> pitti : I wanted to know some internals of Dbus and how it is being used in Gnome
<pitti> bliZZardz: not sure how much I can be of help there, but what's your q?
<bliZZardz> pitti : (1) Does dbus use sockets for communication?if not, which is the IPC mechanism? (2) how id dbus different from a typical message queue? (3) How it is being 'actually' used across applications? - as in , is this like a callback mechanism for across-applications?
<pitti> (1) yes, it uses standard Unix sockets
<pitti> bliZZardz: (2) what is a 'typical message queue'?
<pitti> bliZZardz: d-bus' complexity is somewhat in between a socket and corba
<pitti> bliZZardz: d-bus has signals, method calls, callbacks, and data type marshalling/handling
<lifeless> closing in on corba daily
<pitti> bliZZardz: (3) there are two classes of use cases: (1) session bus, where programs on the session bus communicate with each other; e. g. totem tells gnome-screensaver to disable while a video is playing
<nxvl> heh
<pitti> and the system bus, where programs from the user session access system-wide functionality (usually access restricted); e. g. nautilus gets aware of a new USB drive by HAL, and then issues a mount
<nxvl> pitti can always help on anything, no matter what he says
<nxvl> :D
<nxvl> that's why we love pitti
<pitti> bliZZardz: callback> something similar; programs can 'subscribe' to signals, which indicate status changes
<bliZZardz> nxvl : you bet ;)
 * pitti hugs nxvl
 * nxvl HUGS pitti back
<bliZZardz> pitti : callbacks more like 'intra-process' communication
<pitti> nxvl: well, with "d-bus internals" I was afraid of something like marshalling formats :)
 * bliZZardz hugs everyone...provided you smell good and of opp gender ;)
<bliZZardz> pitti : that was my next Q :)
 * pitti tries to estimate the probability of hugging a girl when picking a random member of #ubuntu-devel
 * bliZZardz concludes probability = ZERO
<pitti> bliZZardz: not true
<nxvl> ugh, launchpad is broken
<bliZZardz> nxvl : ??
<nxvl> bliZZardz: i'm looking for some bugs and i only get error messages
 * jussi01 hugs Hobbsee
<bliZZardz> nxvl : interesting. what did you search ;) ?
<nxvl> i first get it going to b.e.lp.n/ubuntu
<nxvl> which is really odd
 * Hobbsee hugs jussi01 back :)
<Hobbsee> pitti: almost 0, yeah.
<jussi01> better chances in #kubuntu-devel
<fabbione> pitti: nah.. i was just trying to figure out if my driver is broken or the kernel subsystem. Not sure .26 needs new userland
<bliZZardz> pitti : will it be possible to do a code-walkthrough of Dbus? (i get confused when i look at it; or can you point me to some tutorials which would be of some help)
<pitti> bliZZardz: that's where it becomes internal; I read very little of the d-bus code myself
<pitti> bliZZardz: what kind of tutorial? http://dbus.freedesktop.org/doc/dbus-tutorial.html is a nice one for programmers
<fabbione> pitti: btw... what drivers do you have in your ppa? or is it only userland stuff?
<fabbione> because i can reproduce this problem using latest mercurial from linux-dvb
<pitti> fabbione: it's a pretty recent snapshot of the upstream dvb-t hg tree, DKMSified
<fabbione> and it's basically the same as in .26-rc8
<fabbione> or whatever is the current git from linus
<fabbione> ok so it's pretty much the same crack
<fabbione> pitti: do you use dvb-t?
<pitti> fabbione: yes, I have a card
<fabbione> ok
<pitti> I don't *actually* watch TV, I just bought it for playing around
<fabbione> ehhehe
<pitti> fabbione: the soccer championship was the first time I actually watched TV :)
<fabbione> ROFL
<bliZZardz> nxvl : LP is sick , i guess .. i went on to file a bug , and saw one more bug in the process :)
<dholbach> slomo: do you have an idea about bug 197763 - somebody pinged me about it
<ubottu> Launchpad bug 197763 in seahorse "panel menu entry doesn't show correct icon" [Low,Confirmed] https://launchpad.net/bugs/197763
<fabbione> hmmmmmmmmmmmm
<fabbione> pitti: looks like downgrading the kernel doesn't solve the problem.....
 * fabbione tries to go back to a known working version
<pitti> fabbione: what is the problem?
<pitti> fabbione: I noticed that if I build the tree, some modules from l-u-m break (especially the alsa related)
<fabbione> when i try to scan for channels, it timeouts
<pitti> I tried to build linux-dvb against the l-u-m headers as well, but that didn't seem to have worked :(
<pitti> oh
<fabbione> scan -n /usr/share/doc/dvb-utils/examples/scan/dvb-t/dk-All
<fabbione> WARNING: filter timeout pid 0x0011
<fabbione> etc.
<fabbione> this used to work
<fabbione> pitti: all the header stuff is a very well known packaging issue but i thought it was addressed
<pitti> BenC: makedumpfile promoted, and bug 244780 tossed towards you
<ubottu> Launchpad bug 244780 in makedumpfile "fix debian/copyright" [High,Triaged] https://launchpad.net/bugs/244780
<fabbione> pitti: this smells like userland brekage
<pitti> warp10: did you get my reply wrt. gbemol? I didn't get an updated package, and debomatic.linuxdc.it times out
<fabbione> pitti: somewhere that is not even related to dvb-utils
<warp10> pitti: I just sent you an email. BTW, I uploaded gbemol on mentors.debian.net
<pitti> fabbione: oh, good to know; hm, but where else then? maybe a slight change in glibc 2.8?
<pitti> warp10: ah, good
<pitti> warp10: I still have tons of email to dig through after my vac, but I'll get to it
<warp10> pitti: no problem, take your time, and thank you for sponsoring! :)
<pitti> heno, slangasek: many thanks for https://wiki.ubuntu.com/RCBugTargetting; finally some guidelines \o/
<fabbione> pitti: dunno yet... there are so many places where it might be broken
<pitti> fabbione: do you see a long hang in strace?
<fabbione> pitti: i can see the ioctl timing out...
<fabbione> ok this is going to take a fair amount of time..
<fabbione> pitti: i will give you a head up once i get somewhere more solid
<pitti> fabbione: good luck! thanks
<dholbach> thekorn: hiya - did bdmurray say anything about merging your intrepid.merge branch?
<dholbach> thekorn: it'd be nice to have it in .main - http://people.ubuntu.com/~dholbach/sponsoring/ is broken without it :)
<thekorn> dholbach: hi, definitely. I think I will do the merge when I'm back home later today
 * dholbach hugs thekorn
<dholbach> thekorn: you ROCK :)
<dholbach> there are no other words for it... you rock! :)
 * thekorn hugs dholbach
<fabbione> pitti: found the problem... kernel bug
<pitti> hah
<Hobbsee> asac: when's nm 0.7 planned to go into intrepid?
<Hobbsee> my 0.6 version is not behaving at all, yet the hardy version does.
<fabbione> and once again udev dropped the vbi symlink patch
 * fabbione sighs
<ogra> fabbione, waht chipset is that ? wht driver are you using ?
<fabbione> HVR3000
<fabbione> cx88-dvb
<ogra> hmm
<fabbione> ogra: http://www.fabbione.net/hvr3000-fix-init.diff
<fabbione> easy fix
<ogra> i'm using dvb-usb-umt-010 and know there is one special fix i need
<ogra> oh, wow, thas bigger then the one i need :) mine is only changing a 20 to a 10 i the defines ....
<ogra> run it though timg, he'll surely commit it asap
<ogra> s/tmg/rtg/
<heno> pitti: np
<asac> Hobbsee: consider to test the 0.7 packages in  ~network-manager PPA
<fabbione> ogra: well.. my original patch is here: http://dev.kewl.org/hauppauge/mfe-7285.diff
<fabbione> ogra: but that's to support dvb-t + dvb-s at the same time
<Hobbsee> asac: right, will try tomorrow
<ogra> your card can do thyt ?
<ogra> *that
 * ogra is impressed ....
<fabbione> ogra: yes.. mine can do dvb-t dvb-s analog tv, radio and usual RGB/s-video stuff
<ogra> i have two separate cards for that (and dont actualy use either :P )
<fabbione> well i also have other dvb-s cards.. but no extra dvb-t
<ogra> the program selection for dvb-t in the area where i live sucks anyway, so i'm not really after it ... i sometimes use it if my GF wants to look somethig i dont so i go upstaris and whatch in my office :)
<ogra> but thats very rare
<fabbione> ogra: i have 3 channels here from -t
<ogra> well, i have 7 or so .. but the content isnt really great :) they dont allow private stations into the dvb net ....
<ogra> s/dvb/dvb-t/
<fabbione> gotcha
<gnomefreak> was nvidia-glx-new pulled from repos in last day or so?
<gnomefreak> the 2.6.26 version
<ogra> i dont think it ever entered
<gnomefreak> the drivers were working before i reinstalled now they are not
<ogra> as far as i heard the closed driver stuff is being reworked atm
<gnomefreak> this happened on sunday IIRC
<ogra> so it would surprise me if the old nvidia stuff even enters itrepid
<gnomefreak> ah ok thanks i will boot 2.6.24 than
<seb128> pitti: I'm already building those pidgin updates, just to let you know so you don't duplicate work there
<seb128> pitti: got the intltool errors?
<pitti> seb128: oh, thanks; I was just doing the same and wondered about the intltool FTBFS
<seb128> pitti: that's a classic one, either intltoolize needs to be run or intltool not to be installed
<seb128> that's a bug in the package but not new
<pitti> but intltool is a build dep
<seb128> ok, so that's not it
<seb128> it doesn't happen in a pbuilder or on the buildd
<pitti> Global symbol "@INTLTOOL_ICONV" requires explicit package name at ../../intltool-merge line 96.
<seb128> but happens on my boxes if I don't run intltoolize
<seb128> dunno why, I never bothered debugging it
<pitti> it looks like some .in file was copied instead of macro-processed?
<seb128> but that's buggy this way since before hardy
<pitti> seb128: ok, so you are building test packages in a pbuilder?
 * pitti hugs seb128, thanks for taking care about this
<Ng> asac: ppa nm is working pretty well, modulo its odd new behaviours. I don't seem to be having to kill wpa_supplicant either :)
<seb128> yes, or just run intltoolize -c -f for the intrepid build
 * seb128 hugs pitti
<mvo> asac: yep, works well for me too, good work!
<Ng> asac: I am getting some syslog entries about security policies preventing it acquiring "the NetworkManagerSystemSettings service" though
<asac> Ng: so no two instances running after resume?
<asac> Ng: do you have /usr/share/dbus-1/system-services/org.freedesktop.NetworkManagerSystemSettings.service ?
 * ogra points asac and Ng to d-feet ... awesome dbus debugger 
<asac> ogra: i think we are not yet there, but thanks ;)
<mvo> ogra++
<heno> *** Hardy.1 candidate images are now up at http://iso.qa.ubuntu.com/qatracker/build/all Please help test! ***
<slangasek> heno: fwiw, I unfortunately have one more respin of the desktop images to do (excluding kubuntu/kubuntu-kde4, which are done)
<slangasek> I should have done it earlier, but I was fighting with the larger archive problem :/
<ogra> slangasek, but alternate are ready to test ?
<slangasek> yes
<heno> slangasek: ok, good thing I've been focusing on alternate then :)
<seb128> pitti: the pidgin build issue is due to automake1.10 apparently, the patches probably change some timestamp and the build system decided to run the autotools-1.10, if they are not available the build works correctly, if they are available somebody gets screwed
<ogra> ogra@osiris:~/Isos/hardy$ rsync -az --progress rsync://cdimage.ubuntu.com/cdimage/daily/20080701/hardy-alternate-i386.iso hardy-alternate-i386.iso
<ogra> receiving file list ...
<ogra> rsync: link_stat "/daily/20080701/hardy-alternate-i386.iso" (in cdimage) failed: No such file or directory (2)
<ogra> hmm
 * ogra checks the link
<james_w> ogra: you're missing a /hardy/
<slangasek> see the notes at the bottom
<pitti> seb128: ah, ok; that's not a build dep, thus explains the issue
<james_w> rsync://cdimage.ubuntu.com/cdimage/hardy/daily/current/hardy-alternate-i386.iso
<ogra> james_w, i copy pasted the link from the iso tracker
<slangasek> er, at the top
<slangasek> Note: The download links for Hardy images are not correct. Please use http://cdimage.ubuntu.com directly.
<ogra> ah, http://iso.qa.ubuntu.com/qatracker/info/1708 doesnt have that note ...
<seb128> s/somebody/something too ;-)
<ogra> i missed that on the former page :)
<asac> Ng: ok, i uploaded a new package revision to PPA which should have the missing policy files
<Ng> asac: cool :)
<Ng> asac: in answer to your question, I do have that dbus service file
<asac> Ng: yeah. found that i forgot two policy files. lets see if you need to kill the supplicant in turn ;)
<Ng> aha
<Ng> asac: I was chatting to someone in #nm yesterday about the weird new multiple-network-connections behaviour. I really hope they allow that to be disabled ;)
<asac> Ng: once you dont get that message anymore you can test system-configuration that in theory starts up your wiki connection without logging in as user
 * ogra grins about pitti "unless we will throw all of rc?.d/ away anyway in favor of some upstart scripts." ... high hopes :)
<asac> Ng: yeah. the applet will get a redesign
<Ng> asac: will do
<asac> s/wiki/wifi/ :)
<cjwatson> YokoZar: done. BTW, was it intentional that debian/patches/fix-system-tray.patch was dropped without a changelog entry to that effect?
<asac> smurf: my ubuntu-l10n-de membership is about to expire.
<james_w> is there a list of packages which are blacklisted from syncing anywhere?
<james_w> I'm interested in the ones where we have the package but never want to sync it. I believe udev falls in to this category.
<wgrant> james_w: http://people.ubuntu.com/~ubuntu-archive/sync-blacklist.txt
<james_w> great, thanks
<YokoZar> cjwatson: oh, the patch was dropped in an earlier release (it's part of 1.0 upstream now), I think I wrote that in an earlier changelog but didn't actually delete it
<cjwatson> ok
<YokoZar> cjwatson: anyway, thank you
<slomo> dholbach: no idea, sorry
<dholbach> slomo: OK :/
<dholbach> thekorn: does http://paste.ubuntu.com/24437 look OK to you?
<dholbach> thekorn: I'd be interested to know if that's all I'd need to change to get the new fiveaday out into the open :)
<thekorn> dholbach: looking a the code, it changed a bit since I looked at it the last time ;)
<dholbach> thekorn: be sure to pull the latest
<dholbach> thekorn: I replaced some embarassing code with something hopefully saner
<thekorn> dholbach: i think it looks good,
<dholbach> ROCK
<dholbach> I'll get it uploaded soon :)
<thekorn> ROCK!
 * dholbach hugs thekorn
<asac> Hobbsee: what kind of probs do you see with nm 0.6 in intrepid?
<wgrant> asac: Are we getting NM0.7 at some point?
<asac> wgrant: now can the answer be no? :-D
<asac> wgrant: are you on hardy still?
<wgrant> asac: I'm running Intrepid.
<asac> wgrant: then you are out of luck. have to make it compile there
<asac> wgrant: if you want to help, go ahead ;)
<seb128> dholbach: why did you subscribe me to bug #244591?
<ubottu> Launchpad bug 244591 in pidgin "Cannot connect to ICQ ("The client version you are using is too old.")" [Undecided,In progress] https://launchpad.net/bugs/244591
<ln-> clearly not a critical bug, no need to be fixed.
<dholbach> seb128: sponsoring?
<seb128> dholbach: I did sponsor the hardy update some hours ago and I don't see something else to sponsor?
<seb128> dholbach: just wondering if I missed something
<dholbach> oh ok - if it's all done that's fine then
<dholbach> ROCK
<seb128> should I unsubscribe the sponsoring team in this case?
<dholbach> yeah, that sounds good
<dholbach> thanks seb
<seb128> cool
 * seb128 hugs dholbach
<cjwatson> ln-: err, there's a critical task on that bug
<cjwatson> ln-: and brief observation would reveal that it's being fixed
<ln-> so i notice.
<pitti> seb128: btw, does the patch apply to dapper/feisty/gutsy as well?
<dholbach> thekorn: new 5-a-day uploaded :)
<pitti> seb128: and there's also an intrepid fix; do you want me to upload that one, or are you preparing it already?
<dholbach> let's see how it works out :-)
<seb128> pitti: as commented on the bug I've an intrepid upload ready, I'm just waiting because upstream has no tar.gz and I would like to avoid having a different orig.tar.gz than debian
<pitti> ah, nice
 * pitti hugs seb128
<seb128> pitti: I didn't look at dapper to gutsy yet, and I've no install to test those easily
 * seb128 hugs pitti
<seb128> pitti: the pidgin patch applies to the gutsy version
<seb128> pitti: I've no gutsy box to test the build and run the update though and I would like to avoid having to install gutsy only for that
<thekorn> dholbach: ok, super, will test it later today
<dholbach> ROCK :)
<thekorn> :)
<Laney> seb128: I'm testing it now
<seb128> Laney: the gutsy version?
<Laney> seb128: Yes
<seb128> cool, thanks
<Laney> When gmail's imap decides to start working again...
<pitti> seb128: I have chroots and can test it there if you want me
<Laney> seb128, pitti: Works fine, uploading debdiff now
<pitti> Laney: many thanks
<Laney> pitti: No probs, it's up now
<mvo> seb128: I have a gutsy VM if needed
<fabbione> oh boys.. this is so painful
<pitti> fabbione: still kernel fighting?
<fabbione> pitti: so the problem is in the driver, the init code does something wrong and different if the card is cold booted or warm booted. The latter doesn't re-init the card properly so if a previous version of the driver was messing things up, you keep the mess as long as you don't poweroff
<fabbione> pitti: yeah.. trying to fix this
<cody-somerville> pitti, could you accept xubuntu-default-settings in hardy-proposed queue? It is an important SRU that I'd like to try and squeeze into .1
<pitti> cody-somerville: sorry, you have to coordinate that with slangasek
<cody-somerville> pitti, oh. Is -proposed frozen for .1 or something?
<ScottK> cody-somerville: It is.
<pitti> cody-somerville: yes, .1 will be released tomorrow, and is being tested now
<gnomefreak> has anyone seen the grep -i bug?
<gnomefreak> bug 243717 it seems everyone is complaining about it at this time
<ubottu> Launchpad bug 243717 in grep "case sensitive grep broken with UTF8 in intrepid, breaking scripts" [High,Confirmed] https://launchpad.net/bugs/243717
<pitti> Keybuk: any ETA on the intrepid spec approval?
<Keybuk> pitti: am reading through them today, as it happens
<pitti> ah, sweet, thansk
<ScottK> pitti: Thanks for the stack of MIR approvals.
<pitti> ScottK: thanks go to doko this time
<ScottK> pitti: I have an amavisd-new upload to do in the next few days, so it would be efficient if the Sendmail MIR was done so I could unsplit the package at the same time.
<ScottK> doko: Thanks for doing all the heavy lifting on my stack of MIR.
<pitti> ScottK: ok, I can do that alongside hardy.1 CD testing
<ScottK> Great.
<ScottK> doko: Did you see the python-central patch I posted earlier in the week?
 * pitti thinks that the "sensible-mda" package built by sendmail is just slightly exaggerated
 * ScottK agrees.
<ion_> :-D
<pitti> well, admittedly it's by the same definition of "sensible" that goes for the vim default of sensible-editor :-P
<ion_> vim and emacs both. :-)
<pitti> . o O { we need to split sensible-editor into dwim-editor and nerd-editor }
<ion_> Oh, btw, nowadays sensible-editor seems to ask the user to pick one and saves that as a per-user default.
<pitti> right
<pitti> ScottK: done
<ScottK> pitti: Thanks.
<ogra> pitti, https://launchpad.net/vigedit we should just default to gedit and default to that :)
<ScottK> Hopefully my amavisd-new NMU will get sponsored today too and I can upload an unsplit package with DKIM enabled (the spec goal) tomorrow.
 * BenC hugs pitti
<ion_> vigedit, huh? Whatâs wrong with plain gvim? :-)
<ogra> gvfs/gnome-vfs suport for example
<ogra> apart from the fact that every editor should have a vi mode anyway, else its not a real editor :)
<ion_> That could be added to vim-gnome, i reckon.
 * ogra hides
<seb128> pitti: I've sponsored the pidgin gutsy update, the patch is similar to the hardy version and Laney has tested it on gutsy
<cjwatson> pitti,doko: any objection to me promoting libelf1 as obvious (for makedumpfile)? I can't see an ELF library causing a problem
<pitti> cjwatson: I asked BenC to use libelf1g-dev instead
<pitti> cjwatson: we already have libelf in main, so I'd rather use that
<cjwatson> oh, really? why? it's older
<cjwatson> (you mean libelfg0-dev, I think)
<pitti> no particular reason, I think, it's just the status quo
<pitti> right, sorry
<cjwatson> or at least I think it's older
<cjwatson> OK, fair enough
<cjwatson> do they have remotely similar APIs?
<pitti> I had a look at the header files, and they seemed very similar
<pitti> and I remember switching a package from one to the other without effort in the past
<seb128> for bug-buddy we just changed the build-depends I think, there was no code change required
<pitti> it's just bug-buddy and ltrace, so if we want libelf instead, we can probably convert those two easily
<seb128> right, bug-buddy was initially using the other one
<seb128> we just switched because the other lib was already in main
<seb128> changing back should be no issue
<BenC> pitti: I don't think libelfg0 has the dwarf stuff that makedumpfile needs, but I'll recheck
<pitti> BenC: ok; I test ltrace against libelf now
 * ogra shakes his head about elfs providing dwarfs
<BenC> pitti: yeah, there's not one dwarf thing in libelfg0-dev
<sistpoty|work> seb128: do you want bug #193791 back in totem, or do you think it should rather go to l-r-m (it's certainly no xserver-xorg-video-nv, that's not being used there at all)?
<ubottu> Launchpad bug 193791 in xserver-xorg-video-nv "Default video playback settings are bad" [Low,New] https://launchpad.net/bugs/193791
<seb128> sistpoty|work: why should to go back to totem?
<sistpoty|work> seb128: due to the last comment? (I wouldn't ask if I new what's to blame ;))
<seb128> sistpoty|work: the previous comments indicate other player have a similar issue, I would reassing to the closed source driver
<sistpoty|work> seb128: ok, will do so, thanks
<PecisDarbs> hi people, why importing po again in Launchpad is soooo slow? :) Third day already going
<seb128> PecisDarbs: better to ask on #launchpad, that's not really an ubuntu thing
<PecisDarbs> seb128: sure thing, thanks for pointing out
<pitti> BenC: hm, ltrace doesn't build OOTB against libelf-dev, but that seems to be a bug in libelf-dev itself, not ltrace, or a compatibility problem
<pitti> gelf.h needs off64_t without including/defining it)
<pitti> BenC: I'll poke it harder, but for now, I think we can go with elfutils
<pitti> cjwatson: ^ FYI
<BenC> pitti: that means you need -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
<cjwatson> pitti: ok, will you promote it or will I?
<pitti> BenC: ah, I already added the latter, but not the former
<BenC> pitti: _FILE_OFFSET_BITS=64 just changes existing off_t to 64-bits
<pitti> cjwatson: still busy with hardy, so please go ahead if you are at it
<BenC> pitti: I can do ltrace if you are busy
<pitti> BenC: if you can, that would be nice; thanks!
<cjwatson> lool: I fixed component-mismatches-mobile to at least be non-empty, but it'll be wrong - need to rewrite it a bit to use the mobile seeds
<cjwatson> lool: so ignore it for now
<ogra> cjwatson, is it not generated by anastcia nymore ? i was trying locate o chinstarp and rookery but that didnt show anything
<ogra> s/o/on/
<cjwatson> pitti,BenC: done; hit retry on the linux builds in maybe 1.5 hours or so
<cjwatson> ogra: it is, but anastacia was never on either of those systems; it's on drescher
<ogra> ah !
<ogra> well, it was in mdz's homedir on rookery ages ago :)
<cjwatson> the problem was that it was raising a python exception because the mobile seed had gone
<pitti> seb128: ok, then please drop the libelf change in bug-buddy on the next occasion; I demoted libelf to remind us
<cjwatson> ogra: the output was, but I don't think the script itself was?
<seb128> pitti: alright
<cjwatson> ogra: unless I'm misremembering, which is possible of course :)
<ogra> ah, that might be ... i thought the script was there as well
<cjwatson> I think mdz just mirrored it from jackass way back when
<ogra> but the output was also called anastacia ... so its indeed confusing ... :)
<lool> cjwatson: Thanks; I noticed it wasn't empty this morning after the STRUCTURE issue discussion
<lool> cjwatson: Perhaps you shouldn't spend time on it and I should?
<doko> cjwatson: just the binary, are all binaries?
<lool> cjwatson: You might recall I once complained that ./update completed successfully despite some Packages.gz not having been fetched?  I discovered when looking at the other scripts you handed me that urllib didn't throw an exception in some cases and used urllib2 instead; I see you did the same change early June in germinate which probably fixes the old issue I saw
<lool> cjwatson: So ... thanks!
<cjwatson> doko: elfutils source + libdw-dev libelf-dev libelf1 binaries
<cjwatson> lool: ah, right, er, you're welcome ;-)
<cjwatson> lool: though I did it in June 2006 ...
<doko> cjwatson: that should be fine
<lool> cjwatson: Ah then it was probably another issue, unless this just landed
<cjwatson> lool: component-mismatches-mobile> I don't think you have access to do it
<cjwatson> at least not on drescher - leave it with me, I'll get back to you
<lool> cjwatson: I don't; I'm happy to bzr branch and try running locally, or ask for access if ultimately it saves you time
<lool> cjwatson: Ok; thanks
<norsetto> asac: just sent you an email with links to gnome-mplayer/gecko-mediaplayer 0.6.3
<asac> norsetto: i didnt get it :)
<asac> norsetto: just kidding ;) all is fine
<asac> thanks!
<norsetto> asac: of course :-D
<pitti> cjwatson, Keybuk: hm, who should I set as approver of https://blueprints.edge.launchpad.net/ubuntu/+spec/kernel-abi-package-handling ?
<BenC> pitti: me if you want
<pitti> BenC: ok, will do
<pitti> oh, Keybuk just added something to the whiteboard, but no details
<Keybuk> pitti: talk to mvo more ;)
<pitti> mvo: you know what "doesn't address various things" expands to?
<mvo> pitti: sorry, essentially the bits that I mentioned in the last meeting, aptitude support and smart support and coordination with debian. that makes me feel a bit uneasy about it
<pitti> hm, so what can I do to advance this?
<mvo> pitti: I have no better plan currently to offer, that is the problem and this is why I was not outspoken about it
<pitti> mvo: I can start a discussion on debian-devel@
<mvo> pitti: how about this: I explain the problem on the apt development list and CC daniel burrows explicitely and ask if he would be willing to implemnt it in aptitude too
<mvo> pitti: hm, debian-devel might be a good place too
<pitti> mvo: right, that's more specific than d-devel@
<seb128> what is the discussion about?
<pitti> mvo: can you keep me in CC:, just in case? I won't be able to judge about the apt internals, but I can contribute use cases and the intention
<pitti> seb128: https://wiki.ubuntu.com/DesktopTeam/Specs/KernelAbiPackageHandling
<seb128> ah ok
<mvo> pitti: don't get me wrong, I definitely want to solve this problem too, I just don't want to spent a lot of time impleneting it and then not getting it over to debian
<pitti> mvo: absolutely, we shuold implement it 'upstream'
<mvo> pitti: great, thanks. I will draft the mail right away and give it to you for review?
<pitti> mvo: excellent!
<pitti> mvo: I'm almost done with beating on the hardy.1 CDs, so I'll be able to review it today still
<jamiejackson> ï»¿i see an update coming in that says: "Version 2.6.24.13-19.44:   * Just ditch bcmwl from nic-restricted udeb." (in the restricted modules package) <-- where can i read more info on this update?
<mvo> pitti: ok, thanks
<seb128> pitti: maybe you could approve the pidgin gutsy sru?
<pitti> seb128: done
<seb128> pitti: danke
<calc> i'm going to need to reinstall my laptop back to base hardy, since june 26 it has been crashing (goes off immediately) every 1 to 2 days
<calc> anyone else hear of a problem like this? i am not sure if it is a hardware problem or kernel crash or something like that
<mvo> pitti: on the bright side I started with a dbus/policykit backend for language-selector that seems to be working ok-ish already. so that we can drop another one of the gksu use-cases
<pitti> mvo: you mean packagekit?
<mvo> pitti:  policykit to set stuff like the global default langauge
<pitti> oh, sweet!
<mvo> pitti: or the default fontconfig configuration
<pitti> mvo: took me a while to get polkit working with python...
<mvo> pitti: its in the dbus branch
<mvo> pitti: yeah, I found the lack of error messge not great - but the stuff from murrayc helped me go get accross it and then I discovered jockey uses it too
<mvo> pitti: it was not working for me because I had upper case charackters in the action_id first
<pitti> mvo: yes, I added some fairly generic server and client functions to jockey trunk
<pitti> mvo: hah, that confused me as well; polkit-policy-file-validate kept barfing at me due to this :)
<mvo> pitti: yeah, I was pretty puzzled by this :) I wonder why this restriction was added
<mvo> pitti: maybe we should create a python package for this until policykit-gnome gets a python port (this is in the works as I understand it but not finsihed yet?)
<pitti> mvo: there's a first version of pypolkit, but only for the client side
<BenC> pitti: ltrace done, tested and uploaded
<pitti> BenC: just saw it on -changes; many thanks!
<BenC> pitti: bug-buddy takes too many build-deps...are you handling that? :)
<pitti> BenC: don't worry about that one, seb128 and I will figure it out
<BenC> ok, great
<guysoft42> hello all, i seem to be having a problem to exacting the following line in C:  fp = popen("dmidecode", "r"); . it works fine in debian. the error i get is a stack trace. also, using ls works fine.. what could be worng?
<bdmurray> dholbach: merge with which branch?
<dholbach> bdmurray: thekorn's intrepid.merge into .main
<dholbach> bdmurray: it has the fix to make the HTML connector work again
<dholbach> it seems to be in PPA already
<bdmurray> dholbach: I just need it sponsored
<dholbach> bdmurray: oh, I was merely talking about the branches
<bdmurray> dholbach: okay, I'll push it then
<dholbach> thanks
<BenC> pitti: looks like makedumpfile/elfutils/ltrace have all successfully made their way to main (and built against libelf-dev in ltraces case)
<pitti> yay
<pitti> BenC: so, time for a linux give-back?
<Keybuk> pitti: so I'm having an interesting bug at the moment
<BenC> pitti: doing it now (retry button rocks)
<Keybuk> since about Friday
<pitti> BenC: done
<Keybuk> my laptop suspends as normal
<BenC> pitti: thanks
<Keybuk> but pressing the power button makes it boot up again, not resume
<pitti> BenC: ok, you already do, sorry
<pitti> BenC: please go ahead then, my script seems to have broken again (403: Forbidden)
<BenC> ok
<pitti> Keybuk: does /etc/initramfs-tools/conf.d/resume look reasonable?
<Keybuk> pitti: that's not involved in suspend?
<pitti> Keybuk: i. e. did you reformat your swap partition or something?
<pitti> Keybuk: oh, -to-ram; hmm
<Keybuk> the laptop definitely thinks its in ram sleep
<Keybuk> since the power light pulses
<Keybuk> which is its way of saying in standby
<pitti> right, I have the same laptop :) (almost)
<Keybuk> in hibernate, the power light is simply off
<Keybuk> I assume that the power button hasn't been set to be a wakeup device
<BenC> Keybuk: wonder if the kernel is putting the laptop in a bad sleep state
<pitti> Keybuk: I just wonder where the heck the OS would have an influence on that?
<Keybuk> pitti: cat /proc/acpi/wakeup
<Keybuk> PBTN  S4  *enabled
<pitti> Keybuk: i. e. if you press it, you see the BIOS message right away? or some flickering which would be linux resuming and immediately rebooting?
<Keybuk> should that not be S3 ?
<Keybuk> pitti: bios right away
<pitti> Keybuk: let me boot mine and look
<pitti> Keybuk: oh, intrepid or hardy?
<Keybuk> intrepid
<pitti> Keybuk: "PBTN S4 *enabled"
<pitti> it just woke up from hibernate
<pitti> now, suspending
<pitti> no change
<pitti> Keybuk: I have "LID S3 *enabled", though
<pitti> neither change if I use the lid or the power button
<Keybuk> on intrepid, if you stand by, then press the power button, it resumes ?
<pitti> that's all hardy
<pitti> I don't have an intrepid installation on real iron yet
<Keybuk> hardy it worked fine
<pitti> right, I was just comparing
<Keybuk> this is a very recent intrepid breakage for me
<pitti> so the S4 in /proc/acpi/wakeup seems unrelated
<Keybuk> agree
<Keybuk> as soon as I've done this upload, I'll test what the lid does
<dholbach> bdmurray, thekorn_: it seems the right fix is not in .main yet
<dholbach> I still have trouble getting the summary of a bug with the HTML connector
<Bravewolf> Is 8.04.1 sheduled for tomorrow?
<bdmurray> dholbach: I merged the fix for bug 244452 what bug are you talking about?
<ubottu> Launchpad bug 244452 in python-launchpad-bugs "launchpad.net/edge were changing layouts for reporter/activity log, py-lp-bugs doesn't work " [Undecided,Fix committed] https://launchpad.net/bugs/244452
 * calc tries to decide whether to wait for his to crash again in 2 days or reinstall hardy today without any updates
<dholbach> bdmurray, thekorn_: http://paste.ubuntu.com/24508/
<calc> anyone been having problems with spontaneous reboots on up to date hardy?
<cjwatson> Bravewolf: yes
<Keybuk> BenC, pitti: closing and opening the lid also makes it simply boot, rather than resume from standby
<bdmurray> dholbach: okay, I've recreated it and will work on it
<dholbach> bdmurray: seems that thekorn_ already fixed it in his branch
<bdmurray> dholbach: however, it does work with the txt interface which is much less fragile
<dholbach> right, I use the HTML connector because of the activity thing
<dholbach> other than that I use the text connector wherever I can
<thekorn_> dholbach, bdmurray this is fixed in intrepid.merge, I plan to do the merge later today
<BenC> Keybuk: that's either kernel or hardware
<Keybuk> BenC: since it works on hardy, that implies kernel ;)
<BenC> Keybuk: damn you and your proper regression testing :P
<Keybuk> heh
<Keybuk> I have hardy-proposed and intrepid on different partitions ;)
<Keybuk> that's not regression testing
<Keybuk> that's "development release sometimes gets very broken and I need to be able to work" :p
<BenC> Keybuk: hardy kernel on intrepid userspace would make me feel better (though it's kernel team problem either way...just want to rule out pm-utils)
<Keybuk> let me try that
<Keybuk> BenC: hardy kernel works fine on intrepid userspace
<BenC> Keybuk: Ok, then my next request will be to try the 2.6.26-3-generic kernel that is currently building (thanks)
<decriptor> does anyone know who takes care of mono packaging?
<BenC> decriptor: obviously it's only one guy
<pochu> doko: would it be reasonably and possible to move the libpython2.5.so symlink from python2.5-dev to python2.5? See bug 44704 and Debian bug 488760
<ubottu> Launchpad bug 44704 in nautilus-python "Expects to find libpython2.4.so, should look for libpython2.4.so.1" [Low,Fix released] https://launchpad.net/bugs/44704
<ubottu> Debian bug 488760 in python-nautilus "Failed to start: Try to load non-existent libpython2.5.so" [Grave,Open] http://bugs.debian.org/488760
<decriptor> BenC: the sky is blue
<cjwatson> decriptor: https://launchpad.net/~mono
<decriptor> cjwatson: thanks
 * BenC assumes his poor attempt at a joke was lost
<Keybuk> kees: gotta love people who see something, and file a bug about it, without actually verifying the planet-sized assumption about what they saw
<kees> Keybuk: heh, yeah
<decriptor> BenC: sorry, last time (about a year ago), I got a crappy/no answer so faulted to misreading it
<decriptor> BenC: now that you mean it, that was a pretty good one :P
<decriptor> BenC: errrr..... I should reread my posts, not that I've reread it and understand it, that was pretty funny
<decriptor> s/not/now/
<BenC> decriptor: thanks you, I'll be here all week...you've restored my comedic confidence :)
<decriptor> BenC: lol
<decriptor> BenC: I've looked at mono and associated with monkey (spanish meaning) that mono in english has changed its meaning :)
<slangasek> cody-somerville: yes, hardy-proposed is currently frozen for .1; it doesn't look to me that the xubuntu-default-settings fix is important enough that we would want to respin the CD images for it?
<slangasek> cody-somerville: also, we need to have feedback in bug #232364 that the fix works so we can copy it to hardy-updates
<ubottu> Launchpad bug 232364 in xfce4-utils "dbus-launch hangs at session start waiting on socket output in libxcb" [Critical,Fix committed] https://launchpad.net/bugs/232364
<slangasek> cody-somerville: oh, 232364 has feedback now, right then \o/
<mario_limonciell> slangasek, what has been the current bottleneck in daily-live disks for intrepid?
<mario_limonciell> looking at http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/livecd-base/intrepid/livecd-base-20080702.log it's not clear what is actually happening
<slangasek> mario_limonciell: ubiquity wasn't in a working state in time for alpha1, IIRC mostly due to needing to catch up with d-i changes; I don't know if it's caught up now, I've been in point-release-lala-land
<mario_limonciell> slangasek, ah
<mario_limonciell> evand, has ubiquity caught up?
<slangasek> mario_limonciell: I think that log you pointed at shows that it can't find a lives image
<slangasek> livefs
<slangasek> er, no, it doesn't
<evand> mario_limonciell: negative, working on it.
<mario_limonciell> evand, okie dokie
<slangasek> actually, I'm not sure that particular log shows any errors
<mario_limonciell> ah yeah this is the log to be looking at http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu/20080702/livecd-20080702-i386.out
<mario_limonciell> and it's apparmor causing havok
<mario_limonciell> kees, wrg to apparmor stuff, are you going to filing MIR's for libapparmor-perl and libterm-readline-gnu-perl?  those are both universe pieces (Depends and Recommends ) that are keeping livedisks from building at all currently
<kees> mario_limonciell: yeah, I need to do that.
<kees> I had actually forgotten about the libapparmor-perl bit
<kees> do we need to promote things in Recommends now?
<mario_limonciell> kees, there was some chatter about it on ubuntu-devel ML
<kees> mario_limonciell: yeah, I was waiting for a conclusion.  ;)
<mario_limonciell> kees, it looked like to me that was the conclusion.  you should be able to get the same result from a CD install as you would a network install
<kees> hmpf.  what's the point of recommends vs depends then, if they both need to be in main and are installed by default?  :P
<norsetto> kees: you can get rid of recommends ;-)
<mario_limonciell> yeah
<mario_limonciell> kinda like a "weak depends"
<kees> norsetto: heh, yeah, I guess so.  :P
<kees> cjwatson, pitti: do I need a full MIR for libapparmor-perl since it is just swig bindings to libapparmor1 which is already in main?
<mkrufky> is there a way to install an i386 deb on a lpia machine?  ...or is that just a bad idea
<kees> mario_limonciell: actually, which is depending on libapparmor-perl currently?
<kees> mario_limonciell: oh, nm, -utils is in main
<directhex> is it possible for a source package in universe with only build dependencies on main & universe to construct a binary package for multiverse (amongst others)?
<mkrufky> i swear, on one of my ubuntu mailing lists somebody mentioned a way to install i386 packages under a lpia kernel, and i cant seem to find it :-9
<mkrufky> :-(
<directhex> dpkg -i --force-architecture foo.deb
<mkrufky> thank you very much, directhex
<directhex> mkrufky, got used to it in the early days running amd64
<mkrufky> ah
<mario_limonciell> mkrufky, depending on what it is though, that's not always a smart idea
<mario_limonciell> so just be cognoscente of that
<directhex> mario_limonciell, --force-foo is always a great idea!
<mkrufky> i was afk
<mkrufky> anyway, its working :-D
<maix> ping ScottK
<ScottK> Hello.
<maix> hi
<maix> > So far it's not been requested. It would have to be requested (use also
<maix> > affects to add gutsy-backports) and them tested on gutsy.
<maix> (https://bugs.launchpad.net/ubuntu/+source/mercurial/+bug/223789)
<ubottu> Launchpad bug 223789 in hardy-backports "Please backport mercurial 1.0.1-2 from Intrepid to Hardy" [Wishlist,In progress]
<maix> i cannot find such a link/option there
<ScottK> See where it says "Also affects project" right under mercurial(ubuntu)?
<ScottK> Click on that.
<maix> yes?
<maix> (i've tried that but it did not seem to be the right thing to me :)
<ScottK> Yes.  Actually you need to do that from https://bugs.launchpad.net/hardy-backports/+bug/223789
<ubottu> Launchpad bug 223789 in hardy-backports "Please backport mercurial 1.0.1-2 from Intrepid to Hardy" [Wishlist,In progress]
<ScottK> Then when it asks you about the affected project say gutsy-backports.
<ScottK> maix: Does that work better?
<maix> yes
<ScottK> Feel free to discuss the user-friendly U/I in #launchpad.  My thoughts on the matter are well known.
<maix> but that's very confusing, why are there completely different options if i access the same bug by a different url
<ScottK> That's a good question to ask in #launchpad.
<maix> ok then i can guess what your thougts are :)
<ScottK> I've been told my opinions on the Launchpad U/I aren't credible because I don't think it's getting better.
<maix> hm i'll complain too, maybe they will change something when more people complain :)
<maix> and ScottK may you set importance to wishlist, i am not allowed to
<imbrandon> ugh, anyone elses crontab just stop executing jobs ?
<ScottK> Sure.
<maix> thx
<maix> ok done ranting :)
<Riddell> jdstrand, kees: poke.  libzip.  poke.
<kees> Riddell: oh, thanks for the reminder.  do you have the bug# handy still?
<Riddell> kees: https://bugs.edge.launchpad.net/ubuntu/+source/libzip/+bug/238883
<ubottu> Launchpad bug 238883 in libzip "main inclusion report for libzip" [Undecided,Incomplete]
<cjwatson> kees: libapparmor-perl doesn't need an MIR since it's
<cjwatson> kees: ... part of a source package already in main
<kees> cjwatson: okay, that's what I suspected.  I opened a bug report for it.
<cjwatson> you can close it again ;-)
<cjwatson> (libapparmor-perl promoted)
<doko> pochu: well, it belongs to the -dev package
<pochu> doko: so do you know whether there is any other solution than for python-nautilus to depend on python-dev, or for the current patch which opens the .so.X (and needs to be manually updated whenever the soname changes) ?
<doko> pochu: the soname will never change
<doko> only when moving to a new python version
<Caesar> slangasek: what is the current ETA for 8.04.1?
<slangasek> Caesar: tomorrow
<slangasek> Caesar: probably late in the day, Pacific time
<Caesar> slangasek: thanks
<kees> 0Uhmm... is quilt broken in intrepid?
<kees> it's not following my QUILT_PATCHES env var any more.
#ubuntu-devel 2008-07-03
<slangasek> ogra: there are occasionally alphas being offered on the debian-alpha mailing list that are located much closer to you :)
<ogra> yeah, i'm not running after one, if i stumble over it i'll take it ...
<ogra> but alpha is defiately one i want in the collection :)
<slangasek> anyway, if you want one that /runs/, the one I'm using as a doorstop doesn't qualify
<slangasek> it's my spare parts chassis
<liw> ogra, my local favorite computer store has no less than three alphas on their list... I don't know what shipping from Finland would cost, but if you want one, it might be possible to arrange it
<slangasek> but for fun, I could bring it with me as a checked luggage item to London
<slangasek> through Heathrow
<slangasek> no-fee computer recycling, just take it to Heathrow and let them lose it
<ogra> slangasek, i wont be in london :(
<slangasek> oh, right
<slangasek> well then I could make kees take it ;)
 * ogra is already missing everyone
<kees> eek.
<kees> I bet I have suitcase big enough, it just needs to be under 50lbs
<slangasek> :-)
<slangasek> why use a suitcase, that takes all the fun out of it
<slangasek> just use one of the luggage-baling machines at the airport
<kees> ooh, this is reaaaly good.  intrepid chroot: quilt ok.  my intrepid host: quilt freaky
<ogra> its a hardware issue :P
<kees> heh
 * TheMuso had an alpha for a while, but it died a slow death.
<pochu> doko: ok, so let's keep with the current solution. thanks for the info
<slangasek> superm1: I see that we have a pending mythbuntu-control-centre SRU that appears to account for most of the on-ISO delta between the 8.04.1 test images and the -updates pocket
<slangasek> superm1: can we finalize this SRU today?
<slangasek> superm1, Daviey: oh, speaking of which, those alternate images are at http://cdimage.ubuntu.com/mythbuntu/hardy/daily/current/ :)
<slangasek> TheMuso: there are a couple of ubuntustudio-related SRUs to finish as well; #175536 and #221382, do you have time to follow up on these or is there someone else you can prod about them?
<slangasek> superm1: also bug #220087, an SRU for mythplugins, needs to be closed out
<ubottu> Launchpad bug 220087 in mythplugins "Some mythplugins packages fail to configure if /var/lib/mythtv NFS mounted" [Undecided,Fix committed] https://launchpad.net/bugs/220087
<TheMuso> slangasek: I'll have a look at them now.
<slangasek> laga: have any tests been done to confirm that the mythbuntu-control-centre in the archive fixes bug #221921?
<ubottu> Launchpad bug 221921 in mythbuntu-control-centre "SRU: progress bar oddities break creation of diskless clients" [Undecided,Fix committed] https://launchpad.net/bugs/221921
<dholbach> good morning
<dholbach> bdmurray: could you figure out which patch of thekorn fixed the problem?
<dholbach> at http://people.ubuntu.com/~dholbach/sponsoring/ I pull from .main, but it's not working :-/
<ion_> Hi
<bdmurray> dholbach: what revno are you on now?
<dholbach> 107
<bdmurray> and with which branch does it work?
<dholbach> I don't know - it works with the package in PPA, thekorn mentioned "intrepid.merge"
<dholbach> I'm not on top of things in pylpbugs land
<bdmurray> well, we merged intrepid.merge with .main today so that's why I'm confused
<dholbach> hmhmhm
<bdmurray> and printing bug.summary with rev 107 works for me
<dholbach> ok, let me try to run the script again
<bdmurray> okay, let me know
 * dholbach hugs bdmurray
<dholbach> ah, different crash
<bdmurray> that's interesting
<dholbach>     for bug in BugList(link):
<dholbach>   File "/home/dholbach/public_html/sponsoring/launchpadbugs/connector.py", line 117, in __call__
<dholbach>     progress_hook=self.__progress_hook)
<dholbach> TypeError: set() does not take keyword arguments
<dholbach> maybe it's a python2.4 vs python2.5 thing?
<dholbach> rookery still has 2.4
<bdmurray> oh, right
<bdmurray> it doesn't look like it
<dholbach> no, I'm having the same problem with 2.5 too
<bdmurray> well, thats good
<bdmurray> can you pastebin the code again?
<dholbach> if you  bzr branch http://people.ubuntu.com/~dholbach/sponsoring/  you have an example
<dholbach> python2.4 seems to have a different error than python2.5 has
<dholbach> I can pester thekorn about it too, if you like :)
<bdmurray> it is late here but I'll give it a shot
<dholbach> don't worry - I'll pester thekorn about it
 * dholbach hugs bdmurray
<cody-somerville> Can someone please process this merge request? :)
<cody-somerville> https://code.edge.launchpad.net/~xubuntu-dev/ubuntu-seeds/xubuntu.intrepid/+merge/405
<pitti> Good morning
<dholbach> hi pitti
<pitti> kees: libapparmor-perl> just a MIR bug is fine
<pitti> kees: oh, right, what cjwatson says; binary-only promotion is fine
<Hobbsee> hey pitti!
<tjaalton> hi, could someone help with sed.. I need to change 's%.*/%%' to match "until the second /", not last
<slangasek> s%[^/]/%% ?
<slangasek> sorry, s%[^/]*/%%
<pitti> tjaalton: [^/]*/[^/]*/
<slangasek> oh, second one, then probably pitti's
<pitti> tjaalton: erm, without the final /, sorry
<pitti> tjaalton: anyway, [^/] means "any character except /"
<slangasek> also, that fails in the case that there are no / in the string, if that's an issue
<tjaalton> thanks! 's%[^/]*/[^/]*/%%' works
<pitti> tjaalton: if you need "at most two", you need to enclose the second one in ()?
<tjaalton> mesa configure.ac is buggy btw ;)
<tjaalton> since I wanted to have --libdir=/usr/lib/foo, and it would use /usr/foo
<slangasek> curious
<tjaalton> ok, then if I had /foo, the result should be foo
<dholbach> that reminds me of http://regex.info/blog/2006-09-15/247 :)
<tkamppeter> Any Python library expert here?
<tkamppeter> I am packaging the new system-config-printer and it contains a Pythong library for general use now.
<tjaalton> dholbach: indeed :)
<ScottK> pitti: Is what I have in Bug #245096 sufficient for the removal?
<ubottu> Launchpad bug 245096 in amavisd-new-milter "Please remove amavisd-new-milter source package" [Medium,Confirmed] https://launchpad.net/bugs/245096
<tkamppeter> It puts .py files into /usr/lib/python2.5/site-packages/cupshelpers/
<tkamppeter> So I add a rule to the debian/rules file to execute "dh_pysupport -ppython-cupshelpers /usr/lib/python*/*/cupshelpers/"
<tkamppeter> And let these files go into a package named python-cupshelpers
<tkamppeter> Problem is now that the byte-compiler complains about
<tkamppeter> from .cupshelpers import parseDeviceID
<tkamppeter> and
<tkamppeter> from . import _debugprint
<tkamppeter> in the .py files when I install python-cupshelpers
<tkamppeter> It says "Syntax error" on these.
<tkamppeter> Running system-config-printer with these files works.
<dholbach> hi mvo
<pitti> tkamppeter: nice, you are packaging the cupshelpers?
<tkamppeter> pitti, I am doing so as they are part of the source tarball of system-config-printer
<tkamppeter> So python-cupshelpers is a binary package created from the source package s-c-p.
<pitti> tkamppeter: I had a look at it last week, works nicely
<pitti> tkamppeter: why the path for dh_pysupport?
<tkamppeter> Perhaps Tim Waugh is not much familiar with the Python library policy of Debian
<pitti> tkamppeter: it shuold just work with no arguments
<pitti> tkamppeter: he shouldn't need to know about it
<tkamppeter> pitti, does dh_pysupport find /usr/lib/python*/*/PACKAGE by itself? It is not documented in the man page.
<pitti> tkamppeter: it's supposed to, at least
<ScottK> tkamppeter: Generally it does.
<tkamppeter> pitti. Can it be that
<tkamppeter> from .cupshelpers import parseDeviceID
 * ScottK notices the time and heads to bed.
<tkamppeter> and
<ScottK> Good night all.
<pitti> I'm not sure, dh_py{centrla,support} is still somewhat black magic to me
<tkamppeter> from . import _debugprint
<pitti> ScottK: looking at your bug
<StevenK> pitti: Only somewhat?
<tkamppeter> is something new of Python 2.5?
<ScottK> pitti: I'll wait up then.
<pitti> ScottK: looks obvious to me
<ScottK> pitti: OK.  It seemed so to me, but thought I'd make sure.
<ScottK> It's late and I'm tired, so who knows how well I'm thinking.
<pitti> ScottK: I'll remove and update the bug
<tkamppeter> The mentioned error mentions also Python 2.4, and the default Python under which s-c-p is running is 2.5.
<ScottK> pitti: Thanks.  And thanks for getting libmilter promoted quickly so this particular problem could go away.
<tkamppeter> Is there a way to run dh_pysupport with Python 2.4 excluded?
<ScottK> tkamppeter: Yes.  If you were using pycentral you could set XS/XB-Python-Versions:current
<ScottK> You can do it in pysupport too, but it's not obvious. You use pyversions and set it to 2.5 there.
<mvo> dholbach: hello!
<ScottK> Of course it's 2:35AM here, so I could be completely full of it.
<dholbach> hi thekorn
<ScottK> Good night.
<tkamppeter> So pycentral and pysupport are two different programs for the same task, like vi and emacs?
<thekorn> dholbach, hi
<tkamppeter> ScottK, How do I use "pyversions"?
<ScottK> tkamppeter: As I said, I'm headed to bed, but it's just another file in debian.  As compat may have '5' in it, make pyverssion with '2.5' in it.
 * ScottK really going to bed now.
<slytherin> any archive admins around?
<Hobbsee> slytherin: -v
<Hobbsee> slytherin: (there are always some here, but may not be watchnig the screen)
<persia> Also, they tend to be more likely to respond when asked a specific question :)
<slytherin> A package needs to be moved to multiverse. A bug was fixed recently which added build dep on sun jdk. bug 189125
<ubottu> Launchpad bug 189125 in xmlgraphics-commons "Missing classes due to building without com.sun.image.codec.jpeg.JPEGCodec" [Undecided,Fix released] https://launchpad.net/bugs/189125
<slytherin> Hobbsee: ^^
<Hobbsee> pitti: do you want to demote that without a bug, or?
<Hobbsee> (it's fallen into depwait)
<pitti> xmlgraphics-commons?
<Hobbsee> yes
<slytherin> I was going to file bug. But geser suggested yesterday to just bug some archive admin. :-)
<pitti> hm, it's in Debian contrib
<pitti> moved
<slytherin> pitti: thanks.
<tjaalton> ... how to make autoreconf not to strip []'s from the sed script?-)
<slangasek> tjaalton: hard to say without context, but [ is a magic character in the m4 language used for autoconf preprocessing
<slangasek> tjaalton: so [[] []], I think?
<slangasek> (or maybe just the first)
<tjaalton> slangasek: thanks, I'll try that
<tkamppeter> pitti, ScottK, thank you very much, now my first Python library package works.
<pitti> tkamppeter: \o/
<pitti> tkamppeter: fun, today I was just going to ask you about packaging cupshelpers :)
<pitti> tkamppeter: (since I need it for integrating it into jockey for printer driver management)
<tkamppeter> pitti, it is nearly ready to upload, one quick test and I will dput it
<tjaalton> slangasek: adding both of them worked :)
<slangasek> cool
<tkamppeter> pitti, "lintian python-cupshelpers*.deb" says
<tkamppeter> W: python-cupshelpers: old-versioned-python-dependency depends: python (<< 2.6)
<tkamppeter> but on my up-to-date (as of yesterday) intrepid there is only Python 2.5.
<tkamppeter> Is Debian already on 2.6
<slangasek> haha, good one ;)
<slangasek> what does lintian -i give as an explanation?
<tkamppeter> lintian tells that if the package requires a ceratin Python version that I have to add a Python-Version control field.
<tkamppeter> What is a Python-Version control field
<tkamppeter> I have
<tkamppeter> XS-Python-Version: current
<tkamppeter> in debian/control.
<slangasek> is the python (<< 2.6) written verbatim in debian/control?
<tkamppeter> And in general, my package should work with any Python of version 2.5 or higher, it does not work with 2.4 or lower.
<tkamppeter> slangasek, no, it is inserted by dh_pysupport.
<slangasek> ok, I have no idea what that lintian warning means then.
<dholbach> bdmurray: thekorn fixed it in .main!!! :)
<tkamppeter> slangasek, thanks, I will leave it alone for now. For Intrepid it works
<tkamppeter> pitti, new s-c-p with python-cupshelpers is on the way to the archive...
<pitti> tkamppeter: nice, thanks! it'll land in binary NEW, I'll have a look at it
<cjwatson> cody-somerville: pulled, sorry for the delay
<MacSlow> where's the upstream of libpam?
<jengelh> kernel.org
<MacSlow> jengelh, taking a look... thanks!
<nightwish> hi! is anyone of the kernel team available? i'd like to know wether and when bug #199934 will be fixed. a working patch is already attached, and i think the icp vortex support is still critical for many people running ubuntu on servers...
<ubottu> Launchpad bug 199934 in linux-meta "Kernel Panic, in gdth (RAID) driver on reboot" [Undecided,Confirmed] https://launchpad.net/bugs/199934
<jengelh> i think this got fixed in 2.6.25
<nightwish> yes, correct. however, i doubt we'll get 2.6.25 in 8.04
<jengelh> what a pity :p
<nightwish> indeed. this means if i want to stay with lts, i will either have to build my own kernels until the next lts arrives or will have to revert back to 6.06? or is there any chance to get that patch included in the 8.04 kernel somewhen?
 * jengelh happily runs a distro with 2.6.25 by default.
<james_w> nightwish: there's a -kernel channel
<nightwish> ah
<nightwish> ok
<MacSlow> I assume there are no plans to move to libpam 1.x fore Intrepid, right?
<pitti> MacSlow: anything is possible in intrepid at this stage
<MacSlow> pitti, ok... atm I've trouble getting upstream gdm compiled as it is using a struct form libpam, which is only part of the newer libpam-1.x
<mvo> pitti: I updated the package-groups-discssion document, I think its good for sending now
<tkamppeter> pitti, I have a problem with using my new python-cupshelpers now
<tkamppeter> After installing it I have
<ogra> pitti, do you know any replacement for time-admin ? seems to be the only g-s-t app we use in mobile
 * ogra wouldnt like to see g-s-t persist just for that
<seb128> ogra: do you use gnome-panel there?
<pitti> ogra: the gnome panel already handles that nowadays, AFAIUI?
<ogra> seb128, we might in the future
<MacSlow> pitti, to be more precise the new sturct was introduced with libpam-0.99.10.0
<ogra> nono, we need something that sets timezone on system level and the like
<tkamppeter> ls /var/lib/python-support/python2.5/cupshelpers/
<tkamppeter> cupshelpers.py   __init__.py   openprinting.py   ppds.py
<tkamppeter> cupshelpers.pyc  __init__.pyc  openprinting.pyc  ppds.pyc
<ogra> does the panel go that deep down ?
<seb128> ogra: gnome-panel uses policykit to set the system timezone
<ogra> oh, cool
<pitti> seb128: hm, it looks like "set date/time" actually just calls time-admin?
<pitti> yep, it does
<tkamppeter> pitti, now I want to use functions in cupshelpers.py and in ppds.py
<ogra> in hardy for sure
<tkamppeter> I do
<pitti> right, on hardy
 * ogra doesnt have any intrepid and likely wont before the sprint
<pitti> tkamppeter: after installing the package, "import cupshelpers" should work
<seb128> pitti: yes, we changed before hardy to use this one because the gnome-panel had no ntp sync option and quite some users complained
<tkamppeter> import cupshelpers
<seb128> pitti: should be fixed this cycle
<pitti> seb128: aah, nice
<tkamppeter> and it does not find the functions in ppds.py
<tkamppeter> pitti, __init__.py contains "import ppds"
<ogra> seb128, right, ntp is essential on UME
<pitti> tkamppeter: "import ppds" in __init__.py doesn't make sense
<pitti> tkamppeter: (AFAIK)
<pitti> tkamppeter: you need to explicitly "import cupshelpers.ppds"
<tkamppeter> pitti, so there is perhaps a problem in the upstream code?
<pitti> in the program where you want to use it
<pitti> tkamppeter: well, I might misunderstand __init__.py's special magic
<tkamppeter> "import cupshelpers.ppds" does not work, too. Same error.
<tkamppeter> pitti, how does a multiple-file Python library work? Is "import cupshelpers" running __init__.py in the cupshelpers directory or is it running cupshelpers.py whereever it finds a file with this name?
<tkamppeter> pitti, I have found the solution:
<tkamppeter> "import cupshelper" is enough, but all function calls "ppd. ..." have to be changed to "cupshelpers.ppd. ...".
<tkamppeter> pitti, is this normal or should something need to be changed in the upstream code?
<pitti> tkamppeter: this sounds pretty normal
<slangasek> ok wtf; as if thunderstorms in western oregon aren't weird enough, now we're getting hail too?
<pitti> tkamppeter: ah, so the import in __init__.py makes "import cupshelpers" suffice
<pitti> instead of "import cupshelpers.ppd"
<bigon> infinity, still not around?
<ogra> slangasek, you did a lot in grub in the past, do you have any idea if we can switch to grub2 in intrepid ?
<slangasek> ogra: the things I've done in grub don't qualify me to have an opinion on that; what I know from the Debian side is that lenny, which is due in the same timeframe, doesn't look like it will use grub2 by default
<ogra> the mobile team is just discussing merges and there is one grub merge thats not in ubuntu .... grub2 would make that obsolete
<slangasek> (the grub maintainers wanted this, but it doesn't appear to have coalesced yet)
<ogra> well, i remember we discussed it pre release, but dont remember the outcome ...
<slangasek> I think we last discussed it at UDS Boston
<ogra> apart from that "fast-resume" sounds like a patch ubuntu might like to have as well :)
<ogra> so we could probably just merge it in general and not have it as separate mobile patch
<slangasek> hmm?
<ogra> there is a patch thats called fast-resume thats only used on lpia atm
<ogra> preferably those mobile patches should go into te main ap where possible so the mobile team doesnt have to carry all that ... there are way to many custom changes in mobile so each oe that can go to the normal package counts :)
<Keybuk> slangasek: are there any known 8.04.1 issues?
<slangasek> Keybuk: care to limit the scope of that query any? :)
<Keybuk> slangasek: I'm running hardy+proposed+updates and in the last week or so, my machine is behaving very strangely
<Keybuk> random hangs, failing to launch apps, etc.
<slangasek> hrm
<slangasek> no, I haven't heard of anything like that
<Keybuk> Jul  2 14:24:25 quest kernel: [68849.261370] gnome-terminal[6744] general protection rip:7fe5d7305f58 rsp:7fffe2253460 error:0
<ogra> uuuh
<Keybuk> seeing lots of things like that in dmesg
<slangasek> well, the kernel itself hasn't been updated in the past week, that I recall
<slangasek> only lrm
<slangasek> and that just to drop a pre-built driver
<cjwatson> Keybuk: have you attempted to rule out hardware trouble?
<cjwatson> particularly if the set of things that's failing does not seem especially consistent
<Keybuk> cjwatson: not yet, it's hard to rule out
<Keybuk> but it strikes me as suspicious
<Keybuk> it was about  week ago I installed linux-image-2.6.24-19.34
<persia> Keybuk: Downgrade and see if it goes away?
<Keybuk> persia: that's what I'm just doing
<cjwatson> certainly wouldn't hurt to compare your hardware against the set of things changed in that kernel
<Keybuk> cjwatson: there were a few hits of that
<Keybuk> I'm pretty sure I saw an updated nvidia driver
<Keybuk> which would usually be the first thing I'd blame
<Keybuk> ok, rebooting to downgrade
<Keybuk> not for the fortieth time, I wish that session management worked properly ;)
<StevenK> Keybuk: Four-hundredth, perhaps? :-)
<Keybuk> StevenK: I don't reboot that often
<Keybuk> which is why having to reboot several times this last week has been such a trauma ;)
<MacSlow> Does someone know if Jamie Strandboge is around here?
<StevenK> Keybuk: Haha
<pitti> MacSlow: jdstrand, but unlikely to be awake at this hour
<pitti> StevenK: I certainly cursed broken session management that often :)
<MacSlow> pitti, ah ok... well I've issues getting Linux-PAM (upstream and the 1.0.1 release compiled)
<StevenK> Note to self: Storing a backup in /tmp and then rebooting did not work as planned.
<pitti> StevenK: undelete /tmp/* ... oh, wait
<MacSlow> pitti, I'm just looking for somebody who's a bit experienced with pam and related things to help me get it to compile
<pitti> MacSlow: jdstrand and slangasek are your best bets, I think; but particularly for slangasek, you shuold rather mail him instead of IRC
<MacSlow> pitti, btw... I also contacted one of the upstream devs, but don't know how fast they will responsd
<StevenK> pitti: Meh, it's just a backup, I'll just wait for the cron job I wrote. :-)
<slangasek> MacSlow: why are you trying to compile 1.0.1? :/
<MacSlow> slangasek, oh... ehm email is just on it's way.
<MacSlow> slangasek, well... I need it because of the new gdm
<slangasek> um
<MacSlow> slangasek, it uses a new struct from PAM introduced with Linux-PAM 0.99.10.0
<MacSlow> slangasek, it's the pam_xauth_data structure
<MacSlow> slangasek, in Linux-PAM it was added december last year... in gdm the use of this new Linux-PAM feature was added just last week :/
<slangasek> well, merging such a critical security lib straight to the new upstream without some inspection of the changes is... imprudent
<slangasek> I intend to get pam updated for the intrepid cycle, but yeesh at upstreams depending on non-portable features of Linux-PAM 0.99.10 and above
<MacSlow> slangasek, I feared something like that... and always ask myself why such things have to happen to me :/
 * ogra wonders how that will affect remote commections again ... 
<ogra> it took me nearly a month to get xauth right for everything in ltsp ...
<slangasek> I guess that means GNOME doesn't care so much about Solaris anymore? :)
<ogra> i hope they dont break backwards compatibility
 * MacSlow is so "happy" to have to show something working next week
<MacSlow> atm my best idea to get "around" this it to revert that gdm-patch and use an older version
<ogra> but pam is woven into many many things in the distro ... updating that ill be a major task for all teams from server to mobile
<Ng> slangasek: does anyone? ;)
 * MacSlow feels that something in this universe hates him
<slangasek> MacSlow: unless the xauth feature is relevant to what you're showing, I would strongly recommend selectively backing out that upstream change rather than fighting to build PAM and then fighting to understand why your whole authentication system has subtly changed
<MacSlow> slangasek, ogra: well your comments are indication enough for me to not try to push for this just yet
<slangasek> MacSlow: I mean, if you really *want* to be my guinea pig for testing the new upstream version with the Debian/Ubuntu patch set, be my guest ;)
<MacSlow> slangasek, no way... I've far too little experience with such security-related libraries and tools to be wanting this battle
<slangasek> ogra: not to worry, I have a great martyr complex and am happy to bear the task of updating PAM on my own ;-)
<ogra> MacSlow, it doesnt need to be a bad thing .... i for one would appreciate if i could drop my xauth handling in lts *if* pam_xauth_* would handle remote auth data properly
<ogra> i just say it wont be a small transition and affect all teams :)
<ogra> *ltsp
<slangasek> hah, that pam_xauth thing is the thing that I objected to as being bad design when they committed it upstream, isn't it :P
<ogra> heh
<slangasek> and unfortunately I lacked the time to follow through, so now we're saddled with unnecessary vendor divergence from the PAM spec, ohwell
<MacSlow> slangasek, ogra: thanks for the insight sofar... I'm fine with reverting to an older gdm
 * slangasek waves buh-bye to east Portland as the storm knocks it off the network
 * ogra still waits for the announced one in germany to approach
<slangasek> MacSlow: btw, your build failure appears to be because you're building with -DDEBUG; I don't think you want to do that anyway...
<MacSlow> slangasek, I explicitly added --disable-debug to configure... so I'm surprised it still does define DEBUG
<slangasek> right, well, I guess that just confirms that you don't want to be touching this without proper protective clothing :)
<pitti> oh, nice: https://code.edge.launchpad.net/~nderkach/apport/opensuse
<MacSlow> slangasek, the cheap solution is of course to comment out that particular line
<cjwatson> pitti: re yesterday's conversation about libelf, demoting libelf means that bug-buddy is uninstallable in intrepid, which is pretty inconvenient. Could I promote it back and file a targeted bug instead?
<pitti> cjwatson: works for me
<cjwatson> done
<laga> slangasek: i asked people to test #221921 but nobody bothered :( i'll ask again later
<zul> morning
<emgent> hi zul :)
<zul> hi emgent
<Riddell> kees: what did you make of libzip?
<tedg> Riddell: I can't imagine that kees is awake yet, it's 630 his time.
<tjaalton> is it valid to upload -0build1?
<ion_> There has been a -0 uploaded?
<tjaalton> no
<tjaalton> I mean that it would then sync with -1 automatically
<tjaalton> maybe I'll just do -0ubuntu1..
<sistpoty|work> tjaalton: not right now (since past DIF), but iirc in theory yes
<tjaalton> sistpoty|work: right, good point
<geser> tjaalton: are you sure that debian will contain all changes you did to the package?
<tjaalton> geser: there are no changes. it's the same as current -1 candidate
<tjaalton> so if -1 will end up with more changes it wouldn't matter
<geser> ah, then it should be ok to upload as -0build1
<tjaalton> but since I don't expect these to hit unstable before intrepid is close to being released it doesn't matter
<tjaalton> but.. just curious :)
<geser> tjaalton: but as you need to file a sync request either way it doesn't really matter if it's -0build1 or -0ubuntu1
<geser> in that case -0build1 will get auto-synced in intrepid+1
<tjaalton> heck, let's see how it goes. if we need to change it the it can be renamed
<tjaalton> *then
<tjaalton> there, libdrm uploaded
<sistpoty|work> tjaalton: does your upload mean we might get nouveau for intrepid soon? *g*
<tjaalton> sistpoty|work: 2.3.1 is not enough for nouveau :/
<sistpoty|work> :(
<tjaalton> experimental has drm-snapshot & nouveau
<ogra> oooh
<ogra> Riddell, switched KDE to g-p-m as well now :)
<Riddell> ogra: as an acronym, yes
<ogra> (even though the first word seems a bit mistyped in the name there :) )
<BenC> Would someone mind NEWing linux 2.6.26-3.9, please?
<jengelh> newing?
<BenC> jengelh: processing it into the archive now that it's built
<jengelh> what archive
<jengelh> kernels come in source form generally
<ogra> BenC, is there a spec or something about the future of the different flavours that are gone now ?
<BenC> ogra: it's on the kernelteam UDS discussion wiki
<ogra> jengelh, the package archive
<ogra> BenC, gracias :)
<BenC> jengelh: the people that can help me will know what I mean
<jengelh> oh nuts
<jengelh> -EWRONGCHANNEL
<BenC> hehe
<jengelh> kinda felt like ##kernel
<ogra> yeah, thast the aura BenC carries with him
<Nafallo> jengelh: he was in the office and it felt like ##kernel ;-)
<Nafallo> the rest of the kernel team might have influenced that though :-P
<milosz> hey all
<milosz> how can i determine whether a package has a maintainer?
<milosz> i'd like to take over maintainership (in code and maybe packaging) for an app that seems unmaintained
<Riddell> milosz: we don't typically have formal maintainers.  but look at the changelog and see who's been working on it
<milosz> Riddell, the source package changelog?
<Riddell> yes
<milosz> or an Ubuntu-specific one?
<milosz> ah ok
<Riddell> in debian/changelog
<milosz> ok allright
<milosz> there's no debian/ directory in the source tarball (which i got from packages.ubuntu.com)
<jengelh> these debian/ dirs seem quite obstructive
<ogra> if you have it installed look in /usr/share/doc/<packagename>/
<ogra> there you usually got the debian changelog
<milosz> oh yeah there it is
<milosz> hmm the last change is from 2006
<ogra> deb packages consist of three files, not only the source tarball
<milosz> the dsc file and the .diff file?
<ogra> right
<milosz> sorry i'm just really a noob at .deb packaging
<milosz> i guess i'll ask
<ogra> #ubuntu-motu is a good school :)
<milosz> ask a friend of mine to do the packaging, i just want to mostly take over maintainership of code
<milosz> ah
<pochu> milosz: for code maintainership you likely want to contact/become upstream maintainer
<ogra> for the code you should contact upstream
<milosz> yeah i was going to mail the guy anyway
<milosz> what's the formal procedure?
<milosz> what if i don't get any response (the website at least is gone)?
<milosz> can i just assume upstream maintainership in that case?
<ogra> we're mainly doing the packaging ... only rarely changing the upstream code
<ogra> the upstream tarball should have an AUTHORS file or some such
<pochu> milosz: if it's open source, you likely can fork it
<ogra> and an upstream ChangeLog file as well
<persia> milosz: If upstream is gone, and you can't find them, you can create a new website.  In that case, you likely want to chat with the Original-Maintainer to determine where/what is good.
<milosz> ok
<ogra> either of these files should have a mail adress in it
<ogra> to contact the last upstream maintainer
<persia> Shouldn't all the core upstream people be listed in debian/copyright anyway?
<milosz> there's one person listed in the debian copyright file but it's not the upstream maintainer
<persia> Which package is this?
<Riddell> asac: I got knetworkmanager 0.7 working to the extent that it shows itself and which wifi networks it can see, but can't connect to anything
<Riddell> asac: however that's better than nm-applet which doesn't even show itself
<asac> Riddell: haha
<asac> Riddell: works here ;)
<asac> intrepid not yet done though
 * ogra thought there were standards for system tray implementations ... doesnt nm-applet respect them ? 
<ogra> i thought systray apps were interchangeable by design
<Riddell> ogra: yes, it seems to be a gtk issue Gtk-CRITICAL **: gtk_notebook_set_tab_label: assertion `GTK_IS_WIDGET (child)' failed
<ogra> bah
<Riddell> asac: is intrepid being worked on?
<ogra> doesnt find the tab to apply the label to it seems ...
<asac> Riddell: obviously yes.
<asac> Riddell: my main system is just stuck on hardy. ... but ill upgrade any day
<milosz> persia, "dlume"
<milosz> it's a simple address book app
<milosz> i started to u se it but the UI is terrible
<milosz> let's say at least it could use improvement
<milosz> also i want to make it use a standard format like vCard or something
<BenC> cjwatson: Do you have a moment to NEW the latest linux build?
<milosz> there's also contacts from openedhand but i don't see it being much better, maybe the code is
<persia> milosz: http://changelogs.ubuntu.com/changelogs/pool/universe/d/dlume/dlume_0.2.4-5/copyright has 5 people.  Try contacting those listed under "upstream author" if you want to significantly change the code.
<milosz> persia, allright, thanks
<cjwatson> BenC: yep, give me a sec
<james_w> pitti: http://www.redhat.com/archives/fedora-desktop-list/2008-May/msg00006.html
<BenC> cjwatson: thanks
<cjwatson> BenC: done
<cjwatson> just in time for this publisher cycle too
<pitti> james_w: oh, nice!
<dholbach> Ubuntu Java team meeting in #ubuntu-meeting now
<mathiaz> james_w: I've been experimenting with bzr looms with the openldap package and went through a merge from debian. I was wondering about the commit messages when doing up-thread. Here is what the recent history looks like - http://paste.ubuntu.com/24755/
<zul> I take it proposed is open again
<pitti> zul: yep :)
<zul> pitti: great! thanks..
<james_w> hi mathiaz
<james_w> mathiaz: what's your "bzr show-loom"?
<mathiaz> james_w: http://paste.ubuntu.com/24756/
<mathiaz> james_w: I was wondering if there was a better I should use in place of "Merge down-thread."
<mathiaz> james_w: which doesn't really carry any meaning full content
<james_w> mathiaz: you did those commits after a "down-thread", or an "up-thread"?
<mathiaz> james_w: up-thread
<mathiaz> james_w: my workflow is - bzr up-thread, bzr st, bzr ci -m "Merge down-thread.", ...
<mathiaz> james_w: So you can see that there is the debian thread at the very bottom
<james_w> yeah, that looks sensible to me.
<james_w> I'm not sure what to put for the commit message.
<mathiaz> james_w: I've started there, by doing a bzr merge ../debian, where ../debian is the debian svn branch
<james_w> I guess you could use the same message at each thread.
<mathiaz> james_w: and then made my way up-thread up to changelog where I can do a bzr bd -S
<MacSlow> pitti, ogra: I think I can get away without needing a new libpam for the new gdm.
<mathiaz> james_w: right - I think it makes more sense to do that, because when I get to the changelog thread, I need to figure what has been done in order to document it correclty
<MacSlow> pitti, ogra: so no need for discussing it on the -devel ml
<pitti> MacSlow: nice; that's better for not blocking you
<mathiaz> james_w: one issue I ran into was the usage of combine-thread
<mathiaz> james_w: once I had merge the new debian revision, there were some thread that were no longer needed
<mathiaz> james_w: so I'd arrive to such a thread after an up-thread
<ogra> MacSlow, great :)
<mathiaz> james_w: bzr st would show a stack of merges waiting for being commited
<mathiaz> james_w: then I would do a bzr combine-thread, since this thread is no longer needed
<mathiaz> james_w: however, when I moved to the next up-thread, the changes would be carried over there
<mathiaz> james_w: so I'm not sure I fully understand what combine-thread is meant for
<james_w> the changes from below, or including the changes from the thread you just got rid of/
<mathiaz> james_w: changes from the thread I just got rid of
<mathiaz> james_w: it may have been an operational error though - or something I didn't grasp in the merge process
<mathiaz> james_w: I got bitten a couple of times whith changes that were part of a combined thread would still show up in the thread above it
<james_w> did you revert after the combine-thread?
<mathiaz> james_w: hm - I'm not sure... I think that's the part I didn't get
<mathiaz> james_w: it seems that somewhere I have to do a revert
<james_w> I'm not sure, but that might be important.
<james_w> I haven't spent enough time working with looms.
<mathiaz> james_w: ok - I came to the conclusion to that combine-thread wasn't enough to get rid of a thread - you also had to do a revert somewhere along the line.
<mathiaz> james_w: anyway - it was the first time I went through a merge from debian with a bzr loom branch
<james_w> happy with it otherwise?
<mathiaz> james_w: I still need to wrap my head around the whole process and tweak it - but in the end I made it
<mathiaz> james_w: another issue I have is when I need to review if the current thread still applies to the merge
<mathiaz> james_w: openldap bzr branch has the full source code in it
<mathiaz> james_w: I merge a new upstream revision, so there was a lot of code changes
<mathiaz> james_w: I haven't found a way to figure out if the current thread still applies to the pending merges
<james_w> what were you using to judge that? bzr diff?
<james_w> "bzr diff -rthread:" might be what you are after
<mathiaz> james_w: I was using bzr diff -r thread: to figure out what was the patch about
<mathiaz> james_w: but then bzr diff would show me a huge diff
<james_w> yeah, that will be the diff of everything new underneath.
<james_w> is there a way that this could be made better?
<mathiaz> james_w: so figuring out if the thread change was still needed for the new merge was kind of difficult
<mathiaz> james_w: well - I ended up using filterdiff and lsdiff - bzr diff -r thread: would give a list of files that are changed
<mathiaz> james_w: then using filterdiff to extract only the changes related to the files would help a little bit
<james_w> ah, so you want the "bzr diff" output, but only for files that are part of the "bzr diff -rthread:" output?
<mathiaz> james_w: yes - I want to know if the changes that were part of the current thread are still relevant for the code that is being merged from the down-thread
<mathiaz> james_w: IIUC doing an up-thread will use bzr merge algorithm to try to merge the current thread changes in the new down-thread
<mathiaz> james_w: in this  case the new down-thread has *a lot* of changes since it's an new upstream revision
<mathiaz> james_w: so I wasn't sure which changes were related to the new down-thread and which ones where the result of the current thread applied to the new down-thread
<james_w> mathiaz: interesting. I'd advise you to bug lifeless about that ;-)
<mathiaz> james_w: As you can see, I'm not sure I've totally understand the process to go through when merging an new upstream revision
<james_w> mathiaz: are you in the US for the sprint?
<mathiaz> james_w: I may miss something in the whole picture and don't take the correct approach
<mathiaz> james_w: yes :/
<james_w> ah, shame, it would have been good to go through this with you.
<james_w> it seems like you are doing good though.
<pitti> asac: seems that bug 244439 is not really fixed in -proposed, it shouldn't be necessary to purge/reinstall the package
<ubottu> Launchpad bug 244439 in nspr "missing symlinks break binary compatibility with native upstream components" [High,Fix committed] https://launchpad.net/bugs/244439
<mathiaz> james_w: well - I'm happy with the result - I got what I wanted
<darkfile> hi
<darkfile> I just wanted to ask if you ever plan to upgrade libpurple
<darkfile> so we can use ICQ again
<pitti> darkfile: already in hardy-proposed
<darkfile> ah cool
<darkfile> but i'm using the previous version
<darkfile> 7.10
<darkfile> hope it will be fixed as well?
<persia> darkfile: Quite likely, although hardy is the primary QA target, 7.10 will probably be a little later.
<Laney> darkfile: It's in gutsy-proposed too ;)
<darkfile> cool, now ICQ works again
<darkfile> but jabber stopped working ;)
<darkfile> SSL certificate error
<robertknight> Can someone point me to the script that starts console-kit-daemon?
<ogra> /etc/X11/Xsession.d/90-console-kit ?
<kees> Riddell: it's not a trivial audit, and I'm still very busy with a bunch of stuff.  I've started poking at it.  jdstrand, have you had a chance to look at it at all?
<ogra> ah, no thats not the daemon
<jdstrand> kees: not yet, I am getting to a place where I can start. I can take it if you wish
<slangasek> laga: well, "later" doesn't help so much for trying to release images with 8.04.1 today :)
<laga> slangasek: where today is UTC?
<james_w> robertknight: I think it's started by dbus activation
<ogra> yeah
<laga> slangasek: has someone actually verified the mythbuntu images (apart from that mythbuntu-control-centre SRU)? obviously it'll be pointless to push for that SRU if 8.04.1 is not going to happen for mythbuntu.
<laga> i'm out of the loop
<laga> mario_limonciell: ^^
<ogra> robertknight, /usr/share/dbus-1/system-services/org.freedesktop.ConsoleKit.service
<robertknight> james_w: I am looking for a memory leak in console-kit-daemon so I need to restart it under valgrind with the same arguments used to start it on startup/login
<james_w> robertknight: it's started the first time something tries to use it. The file ogra pointed you to shows that it gets no arguments.
<james_w> if you launch it from a terminal, dbus probably won't try to start it for you.
<slangasek> laga: today is US/Pacific, actually
<slangasek> laga: I haven't gotten any feedback on the mythbuntu images as a whole either; I can certainly hold back the mythbuntu images until someone can verify them, if that's what needs to happen...
<robertknight> james_w: Do you know how I can find out what other processes interact with console-kit via DBus?
<laga> slangasek: well, they can't be released unless someone tried them. :) lets wait for mario_limonciell
<laga> i'll ping our RM
<james_w> robertknight: dbus-monitor?
<ogra> robertknight, read up about dbus-monitor
<ogra> :)
<laga> when he comes online
<ogra> robertknight, d-.feet is also a cool tool to inspect dubs stuff (not the traffic though)
<ogra> *d-feet
<Le_Vert> I'm looking for a cowbuilder gui. I read one planet ubuntu that someone created one but I can't remember it's name
<Le_Vert> could you help me ? ;)
<slangasek> soren: around?
<soren> slangasek: ish
<soren> presence -> 0 for time -> in a bit
<slangasek> soren: we have a JeOS test case for ISO testing that didn't get covered
<slangasek> soren: none of the testers have access to VMWare ESX
<soren> Ah.
<slangasek> do we need a separate test for that, if we have VMware server covered?
<soren> Yes.
<soren> they're wildly different beasts.
<soren> nijaba: I don't suppose you have time/opportunity to do a ESX JeOS test?
<ScottK> Didn't someone say earlier that nijaba was off in the south of France at a conference?
<soren> That was me.
<soren> ...who said it.
<soren> He's aroundish now, it seems.
<soren> Ah, except he's away.
<soren> well, I suppose he'll notice eventually.
<soren> Otherwise...
<soren> tjaalton: I don't suppose you have time/opportunity to do a ESX JeOS test?
<soren> slangasek: Sorry, but I have to run now. The only two people I know who can do ESX testing are tjaalton and nijaba.
<Riddell> asac: if you approve my membership of ~network-manager I'll look to upload packages
<slangasek> tjaalton: hmm, do you have time to test JeOS on ESX?
<\sh> soren: what needs to be done?
 * \sh can still grab a coffee and work with his ESX 3.5 here...
 * \sh 's gone now
<jdstrand> kees: eek, I'm not as close to being able to review that as I'd hoped
<jdstrand> (libzip)
<jdstrand> cjwatson: hi! I seem to remember you saying that you could no longer boot your kvm intrepid guests. is this with a hardy host?
<luisbg> slangasek: ping
<slangasek> luisbg: hi
<luisbg> hi
<luisbg> did the ubuntu studio cd got built for hardy.1?
<slangasek> luisbg: there are ubuntustudio images being vetted for .1, yes
<luisbg> slangasek: awesome, thanks! :)
<tm512> What's the chance that a suggestion for the devlopment of Ubuntu would be listened to?
<stdin> !brainstorm
<ubottu> Post your ideas for ubuntu at http://brainstorm.ubuntu.com and vote for the ones you like!
<stdin> tm512: post it there ^
<macd> Any file browse selection dialog takes forever to come up regardless of application triggering it, ideas?
<slangasek> luisbg, TheMuso: we still have an UbuntuStudio SRU that no one's been able to verify yet, and I can't figure out how to even get a test case out of this... genpo, bug #221518
<ubottu> Launchpad bug 221518 in genpo "broken .menu file" [Medium,Fix committed] https://launchpad.net/bugs/221518
<slangasek> luisbg, TheMuso: do you want to try to verify this fix, or should I re-roll the image dropping this package from -proposed?
<persia> slangasek: I'll test it now: I've genpo installed on hardy.
<slangasek> persia: well, I can't figure out where to even find the Debian menu in hardy after installing the 'menu' package :/
<persia> slangasek: Did you install menu-xdg?
<slangasek> no, the test case didn't say to do that
<persia> Yeah, the test case is bad, but menu alone doesn't generate a menu for GNOME: one needs menu-xdg
<slangasek> persia: but if you can verify this, that'd be awesome
<persia> slangasek: I can't verify the behavioural issue, as my menu works, but I can verify that the .menu file is malformed.  checking for regression and validation of fix only.
<slangasek> your Debian menu works, and shows other items that are after genpo in the list?
<persia> It did before and after the update.  Applying the SRU gave genpo an icon, and genpo still runs (although I only tried one note)
<persia> Is this sufficient validation of the bug for a comment and validation, or is maybe the bug questionable?
<luisbg> thanks persia
<ogra> slangasek, you need to enable it in alacarte
<ogra> its disabled by default .... then it will show up in your gnome menu
<slangasek> persia: is it possible that the problem is specifically if you try to install another package, its menu entry won't show up?
<slangasek> ogra: no, I did that
<ogra> hmm
<ogra> weird
<slangasek> ogra: it's almost certainly the menu-xdg package
<persia> slangasek: Except that I've had genpo installed for months, and installed bunches of other stuff that show in my Debian menu.
<slangasek> persia: sigh
<slangasek> persia: ok, please comment your findings to the bug, and I'll copy it over since it doesn't regress, trusting that the submitter wasn't just blowing smoke
<persia> slangasek: weaselly comment committed.
<slangasek> right :)
<infinity> Meh.
<infinity> Do we want mingw32 in main, or do we want to mangle gzip to not build gzip-win32 on Ubuntu?
<kees> doko: what behavior exactly did you want for the "nohardening" stuff?
<slangasek> laga: how about the fix for bug #220087?  Anyone tested this one?
<ubottu> Launchpad bug 220087 in mythplugins "Some mythplugins packages fail to configure if /var/lib/mythtv NFS mounted" [Undecided,Fix committed] https://launchpad.net/bugs/220087
<soren> jdstrand: Intrepid guests on hardy hosts will probably not work. I know what's wrong, and I'll fix it real soon.
<jdstrand> soren: well, if it helps any, they used to work until I updated the guest
<jdstrand> soren: right now, I have an updated amd64 guest, and it's broken. I have an i386 guest I haven't updated, and it still works fine
<soren> jdstrand: That's.. odd. Could I please see the kernel config for the i386 guest?
<jdstrand> soren: hold on...
 * soren holds on
<jdstrand> soren: linux-image-2.6.24-16-386
<jdstrand> soren: (and I'm getting the config now)
<soren> jdstrand: Oh.
<soren> jdstrand: Yeah, that would work.
<jdstrand> soren: so you don't need the config?
<soren> jdstrand: The problem is in >2.6.24
<soren> Nope.
<soren> thanks anyway.
<jdstrand> sure
<soren> I expected it to be a working 2.6.26, which would have surprised me greatly.
<laga> slangasek: i guess not if nobody answered on the bug report.
<laga> slangasek: i'm not being very helpful, i know, just somewhat busy right now.
<laga> i'll take a look at the forum thread in a minute
<slangasek> laga, mario_limonciell: ok; since these two SRUs account for a significant portion of mythbuntu proper and haven't completed SRU verification yet, and I need to move forward with .1 today, I think the best option is to hold back the mythbuntu images for the moment and push them out a little later
<laga> slangasek: thank you.
<laga> i'll go bug some people to test the SRU bugs
<laga> no replies in the forum thread either. so yeah, we need to wait.
<mkrufky> mario_limonciell: ping?
<mkrufky> ...or anybody else --  anybody know anything about packaging xine?
<mkrufky> i just did debuild, got 12 debs
<mkrufky> dunno which one does what :-/
<mkrufky> im sorry -- i mean libxine
<laga> what debs did you get?
<mkrufky> these: http://rafb.net/p/rLwI7n28.html
<mkrufky> basically...  i did a patch to make the xine engine more forgiveable to loss of signal lock, or stream errors
<mkrufky> ...so that it can recover a broken DVB stream rather than dropping it all on the floor
<mkrufky> ...but this is just a test, ive no idea if it will work.  i dont know which package of the above needs to be installed
<laga> well, use dpkg -l libxine* do find out what you have installed currently.
<laga> and then install those
<mkrufky> ah, that's great -- thanks
<laga> installed packages will have 'ii' at the beginning of the line
<mkrufky> ok, it *seems* like this is the one:
<mkrufky> libxine1_1.1.11.1-1ubuntu3_i386.deb
<mkrufky> i'll try it
<ScottK> Wow.  An actual lawyer commenting on a legal related discussion.  I don't think I've ever seen that happen before.
<calc> "BTW is there any chance that you can call the next release or so of
<calc> UBUNTU "The Dog's Bollocks?" - I assume you are in the States but just
<calc> in case you think I'm being abusive - the Dog's is Northern English
<calc> slang for the best thing since sliced bread - why, I don't know... as
<calc> Edmund Hillary should perhaps have said "Because they're there"?"
<calc> lol
<bdmurray> calc: hehe
<cjwatson> jdstrand: yes, intrepid guest on hardy host
<cjwatson> infinity: I remember taking mingw32 out from syslinux, so I assume it should be ripped out of gzip too
<tjaalton> slangasek: is it too late to test?
<slangasek> tjaalton: it sounds like we got the case covered, thanks though
<tjaalton> slangasek: cool
<anthony> slangasek: Meaning that testing's done or that enough people are working on it already?
<slangasek> anthony: testing is done
<anthony> slangasek: Oh, sweet!  No e-mail yet though - must be waiting for mirror syncing as usual I take it?
<slangasek> anthony: correct
<TheMuso> I hope to verify that SRU this morning, unless there is a deadline here.
#ubuntu-devel 2008-07-04
<slangasek> TheMuso: no deadline now, the rest of the flavors are going out and we'll catch up mythbuntu once the SRUs are resolved
<TheMuso> slangasek: Gotcha.
<slangasek> TheMuso: oh, wait; which SRU were we talking about? :)
<slangasek> oh, 221518
<TheMuso> slangasek: Sorry I was talking about the genpo SRU.
<slangasek> TheMuso: well, persia semi-verified it; if you can actually reproduce the original bug, with a test case, I would feel better about the fact that I just shoved it into -updates
<TheMuso> slangasek: Although there was another one you mentioned yesterday against audacious that I have yet to test, as I have to set up a gutsy environment.
<TheMuso> slangasek: Ok I'll look into doing that once I'm through my morning email run.
<slangasek> I did the audacious one myself
<TheMuso> slangasek: Oh you took care of the audacious dist-upgrade bug.
<TheMuso> yeah just saw that, and wrote my above comment after I switched back to IRC from reading bug mail. :)
<slangasek> :)
<Awsoonn> has there been any talk as to what version of xorg will ship with 8.10?
<cody-somerville> The new one
<tjaalton> Awsoonn: 7.4
<tjaalton> xserver 1.5
<Awsoonn> with xserver 1.5?
<Awsoonn> :)
* slangasek changed the topic of #ubuntu-devel to: intrepid alpha-1 released, archive open | Ubuntu 8.04.1 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
<RAOF> Awww.  libdrm 2.3.1 doesn't seem to ship with the nouveau drm headers.
<Awsoonn> I see that intrepid is running almost the same version as Hardy, would it be useful to package up the RC of 7.4 so it's ready for alpha 2?
<tjaalton> RAOF: should it?
<LaserJock> slangasek: \o/
<tjaalton> RAOF: it's too old for nouveau anyway
<tjaalton> Awsoonn: WIP
<tjaalton> (see my post on planet)
<Awsoonn> WIP?
<RAOF> tjaalton: I haven't been following, but the drm snapshots I've been taking have been reporting themselves as version 2.3.1.
<tjaalton> work-in-progress
<RAOF> I was just seeing whether it'd be nice and easy.
<tjaalton> RAOF: they should be 2.4.0
<tjaalton> hah, nice and easy..
<Awsoonn> right on, I'll find something else to hit with a rock then. :)
<tjaalton> :P
<RAOF> Yeah.  It was a pretty long shot :)
<tjaalton> RAOF: we might get 2.4.0 if the stuff intel is working on (GEM) proves to be worth it
<RAOF> Gah.  Memory managers.  Why isn't there one already?
<tjaalton> not just one, _TWO_ :)
<RAOF> That's what I mean.
<tjaalton> heh
<RAOF> Two incomplete managers.
<tjaalton> 1 + 1 ~= 2
<RAOF> tjaalton: Did you mean ~1/2 + ~1/2 ~= 1?
<ion_> tjaalton: FSVO 1
<tjaalton> ion_: heh
<tjaalton> RAOF: yep, that's more accuraty
<tjaalton> *te
<ion_> ~= â â
<tjaalton> ah the flashbacks of some math courses.. FSVO
<tjaalton> *FSVO foo
 * RAOF is a particular fan of "almost all".
<ion_> Is there a âstandardâ Finnish equivalent for FSVO?
<tjaalton> "pienillÃ¤ arvoilla"
<ion_> Alright
<tjaalton> "pienillÃ¤ n:n arvoilla"
<ion_> Yeah
<tjaalton> hmm, the warm smell of offtopic dung
<ion_> (The S in FSVO typically means âsomeâ, though.)
<tjaalton> oh :)
<tjaalton> I thought it was "small"
<tjaalton> no cookie for me
<TheMuso> slangasek: Ok, genpo's SRU has a rubber stamp now. :)
<slangasek> thanks :)
<LaserJock> TheMuso: rock!
<TheMuso> Now... To work out why there are broken deps for some packages in hary-proposed/updates.
<pwnguin> im not sure how to query apt to figure this out: is wacom-tools installed by default, for say ubuntu-desktop?
<LaserJock> pwnguin: doesn't seem so directly
<crimsun> not according to the seeds.
<pwnguin> well thats clearly the challenge
<pwnguin> ok
<LaserJock> crimsun: would you need to germinate to really be sure?
<LaserJock> or are the seeds enough
<crimsun> no, you can cheat and grep through http://people.ubuntu.com/~ubuntu-archive/seeds/ubuntu.hardy/
<pwnguin> heh
<LaserJock> crimsun: but those aren't germinated, couldn't it be pulled in indirectly?
<crimsun> in a very, very, obscure universe, possibly.
<Awsoonn> I have a VM with a fresh install on it, give me a sec :)
<pwnguin> wacom seems like an obscure place
<pwnguin> Awsoonn: while you're there, see if xserver-xorg-input-wacom is also in
<Awsoonn> kk, I do know xauto config sets up wacom stuff by default...
<pwnguin> that part i know
<pwnguin> but its been ages since ive installed from scratch
<Awsoonn> xserver-xorg-input-wacom 1:0.7.9.8-0
<TheMuso> Can anybody on hardy confirm that python-all-dev is uninstallable?
<Awsoonn> negitive on  wacom-tools though
<pwnguin> interesting
<pwnguin> i dont know how the installer is written -- is it possible it only installs some packages if the hardware is present?
<Awsoonn> I am  under the impression that the only case that happens is through the Restricted Manager. But I would love to know for reals
<wgrant> Shouldn't you be able to tell by the Task field on the package?
<pwnguin> if its empty?
<pwnguin> well thanks for the info
<wgrant> pwnguin: If you apt-cache show another package that you know to be pulled in by a seed, and can see the Task field, but can't see it on package X, X probably isn't pulled in.
<TheMuso> Bug 244110
<ubottu> Launchpad bug 244110 in python2.5 "python2.5-dev cannot be installed" [Undecided,Incomplete] https://launchpad.net/bugs/244110
<aib> i'm trying to mix some intrepid packages with hardy. i added APT::Default-Release "stable"; to apt.conf and added the main intrepid repo to my sources.list, then ran apt-get -t intrepid install hello, but it still grabs hello from hardy
<aib> if someone knows how to do this, i'd appreciate the tip. its too advanced for #ubuntu.
<aib> i followed the debian guide as much as possible http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html
<Hobbsee> aib: or #ubuntu+1?
<aib> thanks
<EagleScreen> hello, i am trying to port gdebi to Debian, I have problems with gdebi-kde
<EagleScreen> from kparts import konsoleParts,TerminalInterface
<EagleScreen> they cannot be imported
<EagleScreen> its python
<EagleScreen> python-kde3 is installed
<ScottK> EagleScreen: The konsolepart has been removed from python-kde3
<EagleScreen> oh
<EagleScreen> when happened?
<ScottK> The latest upstream release, whatever it is .1.
<ScottK> It was incompatible with KDE4
<bluefoxicy> someone explain this
<bluefoxicy> read(3, 0x8103564, 4096)                = -1 EAGAIN (Resource temporarily unavailable)
<bluefoxicy> Rhythmbox works after booting, but after a while even if I close/open it again, it does THAT when trying to play a file, in a constant loop, and doesn't play
<bluefoxicy> and FREEZES and won't close (sigterm kills it)
<bluefoxicy> what the hell?
<bluefoxicy> it looks like 3 is closed, but there's a pipe(3,4) reading man page...
<bluefoxicy> ok at the time of this anal behavior, it looks like connect(3, {sa_family=AF_FILE, path="/tmp/.X11-unix/X0"}, 110) = 0 has not seen a close(3)
<bluefoxicy> Welcome to Asshole Reactions 101
<bluefoxicy> Today we are discussing Pidgin, as a casualty of Malone #219848
<ubottu> Launchpad bug 219848 in pulseaudio "rhythmbox freezes after playing for an hour or more and locks all sound until reboot" [Medium,New] https://launchpad.net/bugs/219848
<bluefoxicy> It seems killing pulseaudio causes Pidgin to have a VIOLENT reaction and consume RAM as fast as possible, possibly even rivaling do{malloc(4096);}while(1);
<persia> !ohmy
<ubottu> Please watch your language and topic to help keep this channel family friendly.
<pitti> Good morning
<pitti> slangasek: congratulations for 8.04.1!
<slangasek> thanks - congrats to you as well, for surviving all the SRUs :)
<geser> Good morning pitti
<pitti> hey geser
<nxvl> pitti: good morning!
<dholbach> good morning
<geser> Good morning dholbach
<\sh> hey geser, dholbach
<dholbach> hi geser, hi \sh, hi thekorn
<nxvl> dholbach: good morning!
<thekorn> hey dholbach
<thekorn> hi all
<dholbach> hi nxvl
<\sh> and yeah
<\sh> happy birthday 8.04.1 :)
<Iulian> G'morning
<dholbach> hi Iulian
<Iulian> Hello Daniel
<tjaalton> are 8.04 images still available?
<lifeless> 8.04 images have the ssl bug I believe; 8.04.1 is available now
<tjaalton> lifeless: I know, but thought that for testing purposes the original images might be nice to have somewhere
<lifeless> tjaalton: I don't know for sure, sorry.
<liw> tjaalton, if you can't find them on mirrors, I have copies of some (ubuntu only, alternate/desktop/server, i386/amd64)
<asac> pitti: thats interesting. unless the conflicts/replaces have a glitch i dont see what one would need to --purge nss/nspr
<asac> s/what/why/
<pitti> asac: maybe missing epoch or so?
 * asac looking
<asac> no epoch in nss :/
<asac> pitti: the other idea is that firefox gave up on component registration when it found that it couldnt load all libs
<asac> if you purge nss, you will purge xulrunner ... and if you reinstall that you will force component registration
<asac> s/purge xul/remove/xuL/
<asac> and component registration might have been what cured the previous "blacklisted" weave component
<asac> (one theory)
<tjaalton> liw: no worries, I was just wondering if they were available. good to know where to find them ;)
<xnv> How do "officially supported" packages work? Do they all go through Canonical, or is there a way to help the process? (Trying to figure out why Pidgin 2.4.3 still isn't released for Hardy.)
<laga> xnv: look up the SRU process (stable release updates)
<seb128> xnv: why should 2.4.3 be uploaded to hardy?
<xnv> seb128: Well, a fix for the ICQ problem should be uploaded. It appears a patched version of 2.4.1 is what is being proposed, which I'd also be happy with.
<seb128> xnv: the ICQ fix has been backported indeed and moved to hardy-updates already
<seb128> xnv: maybe you are using a mirror which is not lagging behind?
<seb128> -not rather ;-)
<xnv> seb128: Possibly. I'll try changing servers.
<xnv> seb128: Tried 'Main Server' without luck.
<seb128> xnv: maybe it's not published yet in -updates, it has just been moved this morning, hardy-proposed has it since yesterday
<pitti> sorry, pidgin hardy-updates is delayed, due to the *$#($ hppa buildd not catching up
<pitti> ETA 2 hours
<pitti> xnv: ^
<xnv> pitti: Alright. Thanks for the info.
<xnv> So the rule is you have to release for every supported architecture at once?
<pitti> at the moment, anyway (due to a pretty harsh restriction in the package copy script)
<tjaalton> is it agreed upon that the new xserver etc can be pushed in for alpha2
<tjaalton> ?
<asac> ogra: can you confirm bug 242379 please ;)
<ubottu> Launchpad bug 242379 in nss "constantly shows popups with certification errors on some pages" [High,Fix committed] https://launchpad.net/bugs/242379
<cjwatson> tjaalton: 8.04(.0) images are available from http://old-releases.ubuntu.com/releases/
<tjaalton> cjwatson: oh, thanks
<cjwatson> (the HTML there is a bit wrong - I've corrected it on the master, may take a while to sync out though)
<cjwatson> ArneGoet1e,pitti: have intrepid language packs only been partially uploaded or something? see the end of http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/intrepid/ubuntu/latest/livecd-20080704-i386.out
<cjwatson> (I've fixed the gparted thing there already)
<pitti> cjwatson: there were tons of failed-to-uploads, and rejects, due to a soyuz bug
<pitti> cprov: could you please do your magic "reprocess all f-t-u" again?
<cprov> pitti: I've already re-procesed all binaries.
<pitti> ArneGoet1e: hm, how did your langpack upload from yesterday go?
<cjwatson> cprov: when was that?
<cprov> cjwatson: yesterday evening
<cjwatson> cprov: ok, there were still some failures then
<cjwatson> cprov: e.g. /srv/launchpad.net/ubuntu-queue/failed/upload-20080703-100950-001203/language-pack-pt_8.10+20080527_source.changes hasn't been processed
<cprov> cjwatson: did I miss anything ? I can only see libdrm from the 1st
<cprov> cjwatson: that's source, I've only done binaries
<cjwatson> and http://people.ubuntu.com/~ubuntu-archive/testing/intrepid_probs.html shows a number of similar problems
<cjwatson> cprov: ok, shall I reprocess those source failures then?
<cjwatson> cprov: has the deadlock issue been fixed, or is it still likely to happen sometimes?
<cprov> cjwatson: yes, the problem is fixed (or excluded, in fact)
<ArneGoet1e> pitti: I got a number of 'upload failures' back
<pitti> ok, those need to be reprocessed as well, then
<cjwatson> ok, I'll give it a go
<cjwatson> ArneGoetje: should be reprocessing more happily now - I'll keep an eye on them and go round again if any fail
<cjwatson> much better, all done
<ArneGoetje> cjwatson: thanks :)
<cjwatson> Riddell: can I remove kubuntu-kde4-meta from the archive now that kubuntu-meta is KDE4?
<Riddell> cjwatson: yes
<cjwatson> Riddell: (then I can do NBS removals for the stuff only it depends on ...)
<cjwatson> cool
<pitti> cjwatson: oh, are you processing NBS? (I planned to do so today, too, as part of archive admin)
<cjwatson> done
<cjwatson> pitti: yeah, just trying to clean up a bit for alpha 2
<pitti> thanks
<cjwatson> I'm just doing the ones with zero reverse deps
<pitti> ok, good to know; I'll have a look at the nonzero ones then
<pitti> (still processing NEW, though)
 * Riddell sets kubuntu-kde4.intrepid to merged
<cjwatson> I'm assuming that some of the non-zero ones will go to zero due to other NBS removals
<cjwatson> pitti: you're using lp-remove-package for everything now, yes?
<pitti> yes, I do
<cjwatson> (just checking)
<pitti> and AFAICS I changed all scripts and documentation to do so, too
<pitti> cjwatson: ah:
<pitti> $ remove-package.py
<pitti> Use lp-remove-package.py, see https://wiki.ubuntu.com/ArchiveAdministration
<pitti> right, we did that some months ago, as a reminder :)
<cjwatson> oh good :)
<pitti> Riddell: out of interest, how does dbus-1-qt3 (in source NEW) differ from dbus-qt3?
<Riddell> pitti: different implementation.  dbus-1-qt3 is a backport of the qt4 bindings
<pitti> Riddell: (dbus-qt3 is in main, too)
<Riddell> pitti: hopefully dbus-1-qt3 won't have to go to main, it's needed for knetworkmanager 0.7 but hopefully there will be a kde 4 version of knetworkmanager soon
<cjwatson> is some other archive admin doing syncs but not closing bugs (and so presumably not using syncbugbot)? see 244955 and 244974
<seb128> bug #244955
<ubottu> Launchpad bug 244955 in licq "Please sync licq 1.3.5-7 from Debian(Unstable)" [Undecided,Fix released] https://launchpad.net/bugs/244955
<seb128> bug #244974
<ubottu> Launchpad bug 244974 in dlocate "Please sync dlocate 0.96.1 (universe) from Debian unstable (main). " [Undecided,Fix released] https://launchpad.net/bugs/244974
<seb128> not me
<cjwatson> whoa. is it just me or did somebody do an autosync?
<seb128> looking at the commands history it looks like some did one indeed
<cjwatson> own up :)
<wgrant> Somebody did up to p* a couple of days ago.
<wgrant> I presume an 'oh crap' moment then ensued.
<cjwatson> that can also happen because sync-source.py bails out completely on errors
<cjwatson> so if something starting with 'p' failed to sync, and then the archive admin went for coffee and forgot ...
<pitti> oh, argh, that was me
<wgrant> Ah.
<pitti> darn, we are past DIF
<cjwatson> we are indeed
 * pitti fetches brown paperbag, sorry
<wgrant> Only just.
<cjwatson> yes, fortunately not very far past
<cjwatson> old habits die hard? :)
<pitti> yeah, standard Friday routine...
<pitti> ah, so that's why above bugs weren't covered by syncbugbot, since they already got autosynced
<liw> pitti, please use a cloth bag instead of a paper one, it's re-usable and thus more ecological
 * pitti closes manually
 * liw has several :)
<Mithrandir> liw: I believe you can reuse brown paperbags stuck over your head.
<persia> liw: Do cloth bags provide the same benefits of opacity and airflow restriction?  I'd think most cloth bags wouldn't properly restrict oxygen flow.
<liw> Mithrandir, I find that they get all soggy and break from my tears
<Mithrandir> liw: you're supposed to hide, in it, not cry.
<pitti> ok, sync bugs match reality again
<Mithrandir> persia: paper bags are too stiff to restrict oxygen flow properly.
<lifeless> liw: 57/73 indices from that mega-repository converted to the new index format
<lifeless> liw: 22GB repositories make baby jebus cry.
<lool> dpkg-gencontrol: erreur interne: The method merge_union() is only valid for Dpkg::Deps::Simple
<lool> Hmm
<pitti> len(NEW) == 0 \o/
<persia> Source too?
<pitti> yes
<persia> WooHoo!
 * seb128 hugs pitti
<lifeless> liw: ping
<liw> lifeless, pong
<lifeless> liw: do you still have that 8Gb server and that 22G repository ?
<pitti> cjwatson: http://merges.ubuntu.com/libm/libmtp/REPORT popped up over the weekend (just uploaded to Debian recently); do you think we should do those kind of merges, or ignore them?
<liw> lifeless, I have the machine, but I don't seem to have the repo
<lifeless> liw: I'm upgrading the index to one that has an upper bound on memory use :)
<lifeless> 28609 robertc   18   0 2303m 1.9g 1416 R  0.0 96.7   9:46.52 python
<liw> lifeless, good, good -- will the new index code be in a bzr release soon?
<lifeless> liw: the machine is thrashing :( 2G ram
<lifeless> liw: hopefully yes. For now lp:~robertc/+junk/index2
<lifeless> erm
<lifeless> bzr-index2
<liw> lifeless, if I get some extra time, I'll try that out, but don't hold your breath
<lifeless> :)
<lifeless> I appreciate your torture
<wgrant> What is this enormously massive branch?
<lifeless> wgrant: Ubuntu
<wgrant> All one branch?
<liw> I keep forgetting whether it was Debian etch or Ubuntu hardy
<wgrant> Ooh dear.
<liw> one repository, but one branch per source package
<wgrant> Oh.
<lifeless> wgrant: I blogged it
<lifeless> it found some scaling considerations
<liw> lifeless, you might talk to james_w about large repositories
<lifeless> liw: well, I'll make this one work fast first. He should be doing separate ones per package for now :)
<lifeless> liw: will you be in London?
<liw> lifeless, I will
<lifeless> then we can hack
<cjwatson> pitti: I have no strong feelings either way. We shouldn't waste time on a campaign to do them, but if somebody's bored and wants to then I don't object
<pitti> cjwatson: same here; for this particular merge it's not really worth it, since the only Debian change is the adoption of half of our patch
<pitti> tkamppeter: if you have a moment, could you take a look at http://bugs.debian.org/286127 ? I think the depends/recommends should be updated, and some packages might be obsolete due to the PPD-autogenerator in cups 1.3
<lifeless> liw: http://advogato.org/person/robertc/diary/90.html
<wgrant> lifeless: Is the bzr branch format likely to stabilise at some point?
<wgrant> There seems to be a new one every couple of months.
<wgrant> Which is probably bad.
<lifeless> wgrant: ubuntu changes every few months
<lifeless> wgrant: thats probably bad
<persia> lifeless: Ubuntu is supported for bzr for between 18 and 60 months, but bzr format changes can make the distributed tools unsuitable for use.
<lifeless> persia: we maintain compatibilty with every format since 0.0.4 or so
<lifeless> persia: we can write back to 0.0.6 or so
<persia> lifeless: Forward compatibility?  Old clients can access new trees?
<lifeless> persia: and users explicitly choose when to upgrade
<lifeless> persia: no, users can publish in arbitrarily old trees
<persia> Right.  Users of older distributed clients can't participate with newer trees.
<lifeless> persia: also we provide builds for all the supports versions of Ubuntu, and other platforms via community members
<lifeless> persia: for some value of can't
<persia> lifeless: It's distro-attitude vs. upstream-attitude.  I understand your motivations entirely, and am sympathetic.  It would still be nice to have stability so that the distributed tools just worked.
<lifeless> persia: generally, they do just work
 * pitti is using the etch backpor on his server happily
<lifeless> persia: when was the last time you had bzr's default format bite you with a contributor, or your bzr unable to read someone else's tree?
 * persia notices the work "backport", remembers lots of comments about problems working with updated trees because some member of the development group felt like upgrading, and hopes that waiting another couple years will make it go away
<tjaalton> mesa 7.1rc1 incoming
<pitti> tjaalton: yay new crack!
<lifeless> persia: there are two dimensions on formats; one is a _real_ problem. Its called 'rich root' and its a one way trapdoor.
<persia> lifeless: I'm not really a bzr user, but I'll admit to not seeing many complaints in the past 6 months.
<tjaalton> pitti: indeed :)
<wgrant> tjaalton: Then new X soon enough?
<pitti> I'm currently dist-upgrading my laptop to intrepid, let's have a look at all the other intrepid crack :)
<tjaalton> wgrant: I might upload xorg-server too, but all the drivers need a rebuild so it'll take a few days until things have settled down
<lifeless> persia: the second dimension is just disk encoding and is trivially exported to any other format that has teh same encoding, and we don't see problems with that.
<wgrant> lifeless: I suspect people won't use new formats because they know anybody running less than $LATEST_DEVELOPMENT_RELEASE won't be able to use their branches.
<lifeless> persia: we've been sitting on the rich root change for about 3 years now, because its a problem
<liw> pitti, I tried upgrading a hardy virtual machine to intrepid, now it doesn't boot
<lifeless> the other, we've changed the default from time to time with no problems - because we've thought about the toolchain, and the window between introducing and making default etc
<liw> pitti, I was too lazy to investigate, though
<pitti> wgrant, lifeless: isn't that merely a problem of having the latest bzr on the server side? if you have new bzr and new branch format on the server, and old bzr on the client, the client should still be able to read/write through bzr+ssh:///, right?
<lifeless> wgrant: honestly, people use the the default format, which is not the newest format. Because they shouldn't need to know.
<lifeless> pitti: in principle but we're not there yet.
<wgrant> pitti: bzr+ssh itself is fairly new.
<persia> lifeless: seeing "we're not there yet" is hugely confidence inspiring :)
<lifeless> wgrant: compare with hg - has changed format as often as bzr, but with less doco and clarity, or svn which has _forced_ upgrades (svn 1.5 silently upgrades working trees to its new format)
<lifeless> persia: you need to disable all VFS methods to achieve the abstraction pitti is referring to. Thats not possible if you want to support _all_ bzr operations.
<wgrant> lifeless: Ah yes, but nobody uses Hg.
<lifeless> or git, which hasn't changed formats but has introduced features that cause older versions to barf
<wgrant> and SVN 1.5 isn't anywhere yet, so people won't have had time to be horrified and murder them.
<lifeless> (and not barf with a beautiful message either)
<wgrant> Nothing about git is beautiful.
<liw> whenever I use git, I am astonished at how much output it gives in normal use -- output that I then have to sift through to see if there's any problems reported
<lifeless> wgrant: so, your point then is 'it will be nice when the bzr folk can not think of anything to make better that involves disk or network formats' ? :)
<wgrant> lifeless: My original question was when that was likely to happen.
<pitti> I guess when bzr manages every network operation in a single round-trip with 0% data redundancy :)
<lifeless> wgrant: ok, I may have jumped slightly because we do get critiqued about this, even though I think when one looks deep we're no worse than others and better than most about managing this.
<persia> lifeless: Sorry for any confusion: I meant "hugely confidence inspiring" seriously.
<persia> (and that I was happy as a result)
<lifeless> persia: oh, ok :)
<persia> lifeless: That it is a goal is a good thing, as with 5-year distro support, changing formats are unfortunate: in comparison to git, hg, svn, etc.: you're here to hear the complaints.
<lifeless> wgrant: anyhow, I'm pretty bad at predicting the future. All I can say right now is I have a long list of things that we know would be better; and another list of things in the R&D space I'd like to experiment with, and finally a list of user desired features.
<pitti> lifeless: btw, are you already at a point where some operations actually start to become CPU-bound instead of I/O bound, i. e. the relative Python slowness starts to matter?
<liw> lifeless, my friend with the time machine tells me you'll be finished making bzr faster than git in 2009
<lifeless> pitti: we're way past that
<lifeless> pitti: 60% of performance with the new index was in 'str.split' in python
<pitti> wow
<lifeless> pitti: so I wrote a C parser
<pitti> I had expected it to still be pretty much I/O and network bound
<lifeless> which is used if compiled otherwise you get python
<lifeless> network is a headache
<lifeless> and disk efficiency
<lifeless> also memory efficiency
<asac> mbiebl: there?
<ogra> cjwatson, did you come around to drop hwdb-client from the archive ? i still get bugreports for it and whould like to close them (or point tem to hwtest where appropriate)
<ogra> *them
<cjwatson> I didn't, is there a bug report for it?
<ogra> no, i'll write one
<cjwatson> also, is there a bug on hwtest that it should conflicts/replaces hwdb-client, or something like that, to deal with upgrades?
<MacSlow> What part of dbus am I missing if I get "Couldn't connect to system bus: Failed to connect to socket /tmp/gdm-new/var/run/dbus/system_dbus_socket: No such file or directory"?
<ogra> hmm, i dont think so, and it doesnt, we just replaced the seed entry afaik, i'll check that with cr3
<Keybuk> MacSlow: running system daemon at that socket address
<Keybuk> assumedly the dbus system daemon isn't actually under /tmp/gdm
<Keybuk> DBUS_SYSTEM_BUS_ADDRESS=/var/run/dbus/system_bus_socket
<Keybuk> ?
<tkamppeter> pitti, http://bugs.debian.org/286127 is stone-old it is from the time of CUP 1.1.x and the answers are from clean-up rounds when CUP 1.2.x was introduced. We are now at 1.3.x, and until FF for Intrepid 1.4.x is possible.
<tkamppeter> PPD auto-generation was introduced with CUPS 1.2.x.
<pitti> tkamppeter: I am aware of that; I just think some parts of it are still relevant, so I'd like to check which dependencies/recommends should still be there, and which should go
<cjwatson> ogra: done, thanks
<tkamppeter> You can for sure remove any Recommends or Suggests on foomatic-filters-ppds. This package is obsolete and probably already removed from Ubuntu.
<asac> pitti: on nss bug i'd suggest to flip back the tag to verification-needed and give a bit more infos what to test.
<pitti> asac: works for me; can you do that, please?
<asac> pitti: sure. just wanted to let you know ;)
 * pitti -> off to lunch
<ogra> cjwatson, bug 245488 files accordingly
<ubottu> Launchpad bug 245488 in hwtest "please add proper replaces for hwdb-client to hwtest " [Undecided,New] https://launchpad.net/bugs/245488
<ogra> *filed
<cjwatson> thanks
<tkamppeter> pitti, remove only foomatic-filters-ppds from Suggests, all the rest is OK in the cups package.
<Hobbsee> asac: where exactly was your nm 0.7 for intrepid supposed to be?
<Hobbsee> asac: the version in your ppa appears to be for hardy.
<asac> Hobbsee: my ppa is dead NM wise ;)
<asac> long live ~network-manager team
<asac> Hobbsee: http://launchpad.net/~network-manager/+archive
<asac> Hobbsee: you have to edit the nm-dhcp-client.conf in /etc/db*/sys*/ and grant rights for "root" instead of "dhcp"
<Hobbsee> ahhhh
<asac> we found out that dhclient no longer runs as dhcp in intrepid ... thats why
<Hobbsee> useful
<ogra> asac, isnt that a bug in dhclient ?
<asac> ogra: no we dropped a patch intentionally and are now back to upstream behaviour according to pitti
<ogra> hmmm, for the daemon as well ?
<ogra> pitti, ^^^ ?
 * ogra wishes he could run intrepid :/
<Hobbsee> ogra: why can't you?
<tkamppeter> pitti, SVN for Debian and Ubuntu updated.
<ogra> Hobbsee, some project bounds keep me from it at least until the sprint
<Hobbsee> ogra: damn.
<MacSlow> Anybody here who messes around with upstream gdm atm?
<ogra> pitti, unping ... sorry for not reading the changelog first :)
<seb128> MacSlow: what do you call messing around?
<MacSlow> seb128, grabbing it from svn, compiling, installing, running it
<seb128> I doubt anybody is doing that on this chan
<tjaalton> umm, could an archive admin promote x11proto-dri2-dev to main?-)
<seb128> maybe pedro_ is using jhbuild but that's about it
<MacSlow> seb128, last week I got it working... since yesterday it refuses to start... issues with dbus
<MacSlow> seb128, ok
<seb128> MacSlow: what issue?
<seb128> tjaalton: do you have a mir for this one?
<tjaalton> seb128: no.. I noticed that mesa is waiting for it
<MacSlow> seb128, it cannot connect to the system bus
<cjwatson> I think I'd regard x11proto-* as trivial
<tjaalton> cjwatson: right..
<tjaalton> it's just protocol headers
<cjwatson> promoted
<tjaalton> cool, thanks
<MacSlow> seb128, the gdm-binary cannot find  /tmp/gdm-new/var/run/dbus/system_bus_socket and I thought I could make it use the system-wide /var/run/dbus/system_bus_socket
<seb128> right, maybe a configure option or something?
<MacSlow> seb128, I've not changed those since last week... that's why I don't get it that it does not work anymore
<seb128> maybe an upstream bug
<MacSlow> *shrugg*
<Hobbsee> !ping
<ubottu> ping yourself ;-) really the diodes all down my left side are sore
<seb128> MacSlow: you can try asking on #gdm on gimpnet
<seb128> hey Hobbsee
<MacSlow> seb128, of course I'm trying that first all the time... but there's hardly traffic... only yesterday I got Ray there
<Hobbsee> hey seb128, how's it going?
<Hobbsee> oh, interesting, that did go through.
<seb128> Hobbsee: good, thanks, what about you?
<Hobbsee> seb128: fighting with network mangler, but otherwise good
<Hobbsee> it likes my wired, hates my wireless...
<Hobbsee> !ping
<ubottu> ping yourself ;-) really the diodes all down my left side are sore
<Hobbsee> !ping
 * Mithrandir tickles the little green alien
 * Hobbsee stomps on Mithrandir's feet, before he can levitate
<Mithrandir> good thing they were already on my desk then
 * Hobbsee can jump onto desks, stages, and other objects.
 * Mithrandir watches Hobbsee trip over the USB-powered greenhouse
<chmj> oin #ubuntu-za
 * chmj #$$%#%@ keyboard 
<pitti> tkamppeter: ok, thanks for checking
<pitti> tkamppeter: there is no svn for ubuntu any more, we are in sync
<pitti> tkamppeter: but thanks
<pitti> ogra: :)
<pitti> *grumble* after intrepid upgrade, my laptop's X.org is broken
<pitti> Keybuk: ^ did you have that as well? I just get a black screen
<liw> pitti, but at least it boots
<Keybuk> yup
<pitti> yes, it does, and I can ssh in
<Keybuk> I've been complaining about it to the silent gallery for about two to three weeks
<pitti> and numlock etc. work, ctrl+alt+del too
<Keybuk> pitti: disable usplash
<pitti> I just wanted to make sure not to start debugging from zero if it's already known
<Keybuk> I haven't had time to find out why
<pitti> even restarting gdm doesn't help
<Keybuk> but it's something to do with usplash, since if you leave "splash" off, it works just fine
<seb128> pitti: try disabling compiz?
<Keybuk> seb128: is a fundamental X problem
<pitti> seb128: gdm doesn't come up at all, nor a simple "X"
<seb128> alright
 * pitti tries with the hardy kernel, and then intrepid without usplash
<Keybuk> pitti: does your suspend/resume break too?
<Keybuk> or haven't you got that far yet? :p
<pitti> Keybuk: the latter
<pitti> it was the first virgin boot of intrepid on my laptop
<pitti> my desktop is still hardy
<pitti> ah, so intrepid with hardy kernel -> usplash and X work
<Mithrandir> and hardy usplesh, I suspect?
<Hobbsee> pitti: ahcompletely black screen when usplash finishes, or?
<pitti> Mithrandir: everything else is intrepid
<pitti> Mithrandir: well, except hte initramfs, of course
<pitti> Hobbsee: 'zactly
<Hobbsee> pitti: ah yes.  i noticed that when i just rebooted, and thought that was odd.
<Hobbsee> hadn't seen that happen before
<pitti> ugh, WTH?
<pitti> screen colors are completely messed up
<pitti> the background is ok, but panel and windows are utterly dark
<pitti> (still intrepid with hardy kernel)
<pitti> oh, that's the new theme, and might actually be deliberate, I'm afraid
<Hobbsee> pitti: ah, yes....
<Hobbsee> pitti: it's lovely, isn't it?
<pitti> well, the brown of active windows and the dark gray don't harmonize at all, but *shrug*
<Hobbsee> so lovely that you
<Hobbsee> 'll put on your release team hat, and say "no way"?  :P
<norsetto> can't be worse than the elephant skin
<tkamppeter> pitti, OK, then I know that I need to upload my contributions to the CUPS package only into trunk (pkg-cups/cupsys/trunk, or is there a new "cups" repo?) and you upload the new package into Debian and an automatic process passes it from Debian to Ubuntu?
<pitti> argh, my ears explode
<pitti> instead of the start up sound I hear something utterly sqeaking and hurting
<pitti> tkamppeter: no, trunk is fine
<tkamppeter> pitt, ears? You use a screen reader now where your X does not work?
<pitti> tkamppeter: exactly, I just sync it over
<pitti> tkamppeter: startup sound
<norsetto> thats an ibex in heat ...
<Mithrandir> pitti: it's the sound of intrepids in the morning.
<pitti> no, X works again with disabling usplash
<Mithrandir> well, ibices in the morning
<Hobbsee> pitti: oh yeah.  tha'ts a known problem too - it's playing through your onboard pcspkr instead of your sound card.
<sistpoty|work> tjaalton: btw. what are the plans in regards to x drivers, as I'm listed to merge xserver-xorg-video-nv... is it ok for me to go ahead, or should this be taken from somewhere else?
<pitti> Keybuk: confirmed your suspend problem, too
<wgrant> Somebody decided to turn pcspkr into an ALSA module :(
<tkamppeter> pitti, if I see a package at Debian and I want to have it unchanged in Ubuntu, can I sync it over with some simple clicks with my core-dev access?
<pitti> yeah, I noticed that in my vmware instance
<pitti> tkamppeter: not yet, you need a sync bug for that
<Hobbsee> tkamppeter: you can use his sync-source.py script
<tkamppeter> pitti, Hobbsee, what is a sync bug? what is sync-source.py? Is there a doc page for that?
<Hobbsee> tkamppeter: .....
 * Hobbsee attempts to revise what she's about to say.
 * Hobbsee attempts to find some better way of phrasing it, that will actually follow the code of conduct.  ish.
<pitti> Hobbsee: I know that my script is a piece of crap, that's why it isn't documented :)
<Hobbsee> pitti: no, not that.
<Mithrandir> pitti: I think what Hobbsee is trying to phrase is something along the lines of "I think it's a problem that we have people in core-dev who does not appear to know what a sync is or how it is done".
<Hobbsee> Mithrandir: it's bad enough that we have them in MOTU, let alone core dev.
 * wgrant bows to Mithrandir.
<Mithrandir> hiya wgrant, didn't recognize you with the new nick.
<tkamppeter> I know what a sync is, but I have never made one, the packages I have produced had always some Ubuntu bits ...
<sistpoty|work> tkamppeter: s.th. like bug #243774
<wgrant> Mithrandir: That's what they all say.
<ubottu> sistpoty|work: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/243774/+text)
<sistpoty|work> tkamppeter: there was also a post to ubuntu-devel some longer time ago what info should be present in a sync request, but I can't find the post right now
<Lrrr> There is a checksum error in the Gutsy archive.  Whom should I contact for that?
<Hobbsee> Lrrr: which mirror?
<Lrrr> Gulus.usherbrooke.ca, right now.  I can try another mirror but it's probably break again.  It's been like that for a few days now.
<Hobbsee> Lrrr: try another mirror first, if that doesn't work either, then come back
<Mithrandir> tkamppeter: part of knowing what it is is also to have performed it enough times that your spine knows how it's done.
<Lrrr> Hobbsee: Do you suggest any mirror?
<Hobbsee> Lrrr: archive.ubuntu.com ?
<Lrrr> Okay.
<Lrrr> Trying.
<Hobbsee> tkamppeter: i think what's most disturbing about that request is that you're asking about where basic development documentation is.  I can understand the fact that you don't normally need to do sync requests.  But i'm absolutely stunned that you don't know where the pages about syncs and merges are, particularly as you have to do them every cycle, and you are a core developer, who is supposed to be able to know and follow ubuntu processes.
<Hobbsee> s/be able to//
<wgrant> I recall that when others have applied for core-dev in the past on the grounds of sponsorship being inefficient, they have been denied.
<tkamppeter> Sorry, I found the page in the Wiki already. I have already merged a lot, most times when I change something in a package I look at merges.u.com and take in the Debian stuff.
<Hobbsee> Even people who are in ubuntu-universe-contributors know this information - or can at least point to it.
<Lrrr> Hobbsee: Same error when using archive.ubuntu.com.  I'm using reprepro but I can confirm the checksum error by manually.
<wgrant> Lrrr: You can confirm it, or have confirmed it?
<wgrant> Lrrr: If the latter, which package?
<wgrant> I thought all of those got fixed before release.
<wgrant> Or maybe that was for Hardy.
<wgrant> Oh to have NMAFA running on Primary...
<Lrrr> It's from a Release file.  Checksums for several (all?) Packages.gz in the Gutsy archive are apparently broken.
<Lrrr> I did confirm it manually.
<wgrant> That is very unlikely.
<wgrant> That would break the world.
<wgrant> Which pocket, or all?
<Lrrr> Wrong checksum during receive of 'http://archive.ubuntu.com/ubuntu/dists/gutsy/main/binary-i386/Packages.gz':
<Lrrr> sha256 expected: baa89858c7e545390273530ba63c61b94c2e09d38c28b0a0311bfa7bde396181, got: af96b1f3119c4ce4b0c6183750279bf7cbdfe62581289f03ad360787e79f968b
<elmo> neat, that's actually true
<wgrant> Ah, I've not seen things use the SHA256 before.
<wgrant> There's a Soyuz bug on that.
<wgrant> Filed a few days back.
<elmo> wgrant: got a #?
<wgrant> https://bugs.launchpad.net/bugs/243630
<ubottu> Launchpad bug 243630 in soyuz "Hardy release files contain invalid SHA256 signatures." [High,Confirmed]
<wgrant> Bug in python-apt, I guess.
<Lrrr> reprepro, AFAIK, has no --dont-bugger-me switch.  That means I can't pull from the Gutsy archive at all.
<elmo> it's still wrong, even in intrepid, that's pretty special
<wgrant> You can't convince it to use the other hashes?
<Lrrr> I doubt it.  Let me see.
<wgrant> elmo: It's rather special indeed. No response from mvo yet, either...
<cprov> elmo: it's broken since we've switched to python-apt SHA256 generation (it was mid feisty, IIRC)
<elmo> cprov: yeah, but I thought drescher being on hardy would have fixed it
<Lrrr> The man pages doesn't say anything about that.
<elmo> (at least for intrepid Release files)
<cprov> elmo:  apt_pkg still thinking it's correct in hardy, Crypto and sha256sum disagree
<Lrrr> That bug is relatively recent in the case of Gutsy because my scripts were working just fine a few weeks ago.
<cprov> elmo: yeah, but no .. the tests pasted in the bug where done in hardy (drescher, precisely)
<mvo> wgrant: it got under in my bug list, its the kind of bug that I like to hear about on irc too
<elmo> mmmmmmmveeeeeeeeeeeeeeeeeeoooooooooohhhh
<wgrant> Lrrr: You didn't happen to upgrade to a newer reprepro recently, did you? Those files haven't changed in ages.
<Lrrr> I'm running sid so yeah I probably upgraded reprepro recently.
<Lrrr> Let me check
<wgrant> elmo: Oh dear, I have been pronouncing it wrong all this time?
<Lrrr> Yep.  +1 to wgrant.  SHA256 support is new since early june.
 * Lrrr visits snapshot.debian.net
<mvo> cprov: could you please run "apt_pkg.sha256sum(open("Packages.gz"))" (without the .read()) ?
<mvo> cprov: that should fix it
<liw> does anyone here happen to know of a (scriptable) command line client for gobby?
<cprov> mvo: uhmm, let me try
 * mvo just had a mild heart-attack hearing
<alex-weej> pedro_: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/93256
<ubottu> Launchpad bug 93256 in evolution "Evolution icons are misrepresentative" [Low,Fix released]
 * mvo looks futher into the code
<pedro_> alex-weej: i've tested it with several icon themes and don't get what you described
<Lrrr> yay
 * Lrrr updates his sub-distro.
<alex-weej> pedro_: with GNOME, i get Internet -> Evolution Mail (mail icon) -- good
<alex-weej> and Office -> Evolution Mail and Calendar (mail icon) -- bad * 2
<alex-weej> firstly, it's not just mail and calendar, it's notes and contacts too
<alex-weej> and secondly, the icon should be the evo icon
 * pedro_ still wondering why we have evolution in 2 categories...
<alex-weej> rather than just mail
<cprov> mvo: yes, apt sha256 does match the world's value if I omit the read()
<alex-weej> pedro_: because it's actually like 5 different applications
<alex-weej> only one of which pertains to the "Internet"
<pedro_> alex-weej: yeah kind of that..
<alex-weej> pedro_: can you confirm you see the same as me?
<pedro_> alex-weej: let me check
<mvo> cprov: thanks for confirming, there is definitely a bug somewhere because the string stuff should work too
<mdz> mvo: is it a known issue that the upgrader can pop up *very* many dialogs from a single package failure (for everything which depends on it)?
<mdz> mvo: I am clicking through a very long list of such popups right now, upgrading to intrepid :-)
<mvo> mdz: yes, funny that you ask, asac mentioned it today too and I just fixed those redunadant dialogs
<tjaalton> sistpoty|work: wait until the new xorg-server is built, then you can upload a new merge
<mdz> mvo: oh good
<Mithrandir> mdz: "libc6"? :-)
<mvo> lol
<mdz> Mithrandir: findutils, which libc6 depends on
<sistpoty|work> tjaalton: ok, will do (of course in case you want to take over again, I don't mind at all as well ;))
<mdz> (!)
<Mithrandir> mdz: good fun, then.
<mdz> yes, this will take some time
<mdz> *click* *click* *click*
<cprov> mvo: okay, can we afford being wrong about SHA256 for sometime until you get the bug fixed on apt or should we change the publisher code to use the fd instead of the string ?
<mvo> mdz: that depends got added to work around assert failure in xargs
<mdz> findutils itself seems to have failed due to a Perl issue (via install-docs)
<tjaalton> sistpoty|work: ok, we'll see :)
<mdz> Can't locate Pod/Usage.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/sbin/install-docs line 18.
<sistpoty|work> heh
<mvo> cprov: I would say use the fd instead of the string, should be much more efficient anyway (or is there a risk here)?
<mvo> mdz: oh, you got hit by the doc-base failure too (bug #243830)
<ubottu> Launchpad bug 243830 in doc-base "base-passwd package failed to install during do-release-upgrade" [High,Triaged] https://launchpad.net/bugs/243830
<mdz> bug 243830, yes
<mdz> just found it myself
<mdz> mvo: I should have run the upgrade in a sandbox so that I could verify the fix once it arrives ;-)
<mvo> mdz: there is a spec called "upgrade-testing-in-a-sandbox" now .)
<mdz> mvo: yes, I was referring to it
<mvo> heh :)
<mvo> pitti: what is the current policy for new main compoenents that come from debian? new doc-base needs a universe build-depends now. is that reviewed internally or can I help by writing a MIR ?
<pedro_> alex-weej: right, i'll comment on the report
<alex-weej> pedro_: i'm just looking at the upstream repo... "Evolution Mail and Calendar" is their only Desktop Entry
<alex-weej> we're adding one explicitly for "Evolution Mail" i think
<pedro_> alex-weej: yes trunk is using that (just see it), that's what i added on the comment also
<alex-weej> ok
<cprov> mvo: no risk, I can do that quickly them.
<pitti> mvo: nothing is reviewed 'automatically', so we need at least a MIR bug
<pitti> mvo: for trivial packages, a bug is enough (libperl*), for complex ones we need a wiki MIR
<cprov> elmo: do you have any plan to regenerate the Release files for old series ? Can we do that without making people panic ?
<mvo> cprov: I'm updating the report with my findings
<cprov> mvo: thanks, dude.
<pitti> tkamppeter: which part of the printer device ID do I need for the web query? just MFG and MDL, or other stuff as well? (certainly not DES and CLS, but I don't knwo what P, S, and SN are
<pitti> tkamppeter: oh, it seems I can just submit the entire thing, and the sever just ignores unimportant bits
<pitti> tkamppeter: is the order of the fields important? i. e. does it always have to be MFG;CLS;MDL, or can they come in arbitrary order?
<tkamppeter> pitti, make and model are enough in most cases (if device ID is really standards-conforming). Some printers have no make and/or model tag, then you can use the description. CMD is only to find appropriate generic PPDs for a printer which is unknown to the database.
<Hobbsee> mvo: why does apt still try to install recommends for a package, if you've held the package back (by dpkg --set-selections), and won't let it upgrade to the newer version?
<pitti> tkamppeter: ah, thanks; I think I'll just submit everything cupshelper.getDevices() gives me
<Hobbsee> (when running a dist-upgrade)
<tkamppeter> P, S, and SN are not constant on different printers of the same model or even not constant during the printer's life (on HP they contain the ink levels). SDo they are not used.
<pitti> tkamppeter: lpinfo -l -v still is a string, but cupshelpers dissects it into a dictionary, so the order of the fields is lost
<pitti> tkamppeter: "SN" sounds like serial number
<tkamppeter> pitti, the order of the field of a device ID string is not relevant. It is always dissected on the server and the server only uses MFG/MDL, DES, and CMD in the given priority order to find its answer.
<pitti> tkamppeter: perfect; thanks!
<tkamppeter> You ususally can send device IDs as they are to the server. The server dissects them by itself.
<mvo> Hobbsee: that sounds like a bug
<tkamppeter> pitti, serial number can appear under SN, SER, or SERIAL. It is used by CUPS and by system-config-printer to distinguish two printers of the same model connected to one machine, especially when using USB.
<Hobbsee> mvo: http://rafb.net/p/S9g7K465.html
<pitti> tkamppeter: so I'll filter out those three, I think; I don't want to send serial numbers over the net for privacy reasons
<pitti> tkamppeter: or, rather, I'll only take MFG, MDL, DES, and CMD
<tkamppeter> pitti, exactly that, only these four are needed to identify which model a printer is and which drivers it needs. All the others are irrelevant.
<pitti> tkamppeter: so I rather don't send them in the first place; thanks!
<tkamppeter> You do not need to filter them out, as my software drops them (and does not send them to an ink cartridge store)
<pitti> tkamppeter: I still want to avoid sending serial numbers or other potentially personal data over the network
<tkamppeter> pitti, but better filter them out, as sooner or later we get mirrors, or simply someone is listening to the connections passing through the net and then delivers the ink ...
<pitti> lol
<pitti> tkamppeter: jockey 0.6 feature, I'd say :-P
<tkamppeter> pitti, when will 0.6 be released?
<pitti> dunno, currently working on 0.5
<pitti> plan is to get printer support ready, add some more required D-BUS interfaces for printer support, and release 0.5
<pitti> I'll probably move PackageKit to 0.6
<pitti> tkamppeter: oh, there was another thing I wanted to discuss with you, do you have a minute?
<tkamppeter> pitti, yes
<mathiaz> mvo: what do you think about bug 245493 ?
<ubottu> Launchpad bug 245493 in samba "sharing a folder reports permission issues in Hardy Heron (32 bit)" [Undecided,Invalid] https://launchpad.net/bugs/245493
<mathiaz> mvo: is there a warning message that is shown after the samba package is installed stating that the user has to log off and login ?
<ScottK> pitti: I assume it was you that rejected the debian-maintainers keyring package from New.  I'd like to discuss it with you as I find the package useful.
<pitti> ScottK: oh, I had assumed it was an accident from an autosync run, so I blacklisted it and rejected it from NEW, yes
<pitti> ScottK: hm, but how is it relevant for Ubuntu? we won't even keep it up to date
<ScottK> pitti: No, I filed a bug asking for it sync'ed.  I find it useful with who-uploads
<pitti> ah, then someone synced it without NEWing
 * mdz reboots into intrepid
<ScottK> Yes.
<pitti> mdz: good luck! did the same today, with mixed results
<Hobbsee> pitti: did you sort your sound out?
<pitti> Hobbsee: I blacklisted snd_pcsp, but I haven't rebooted yet
<pitti> (I think that should do it)
<Hobbsee> true
<pitti> the entire idea of that module is an abdomination anyway, IMHO
<pitti> it *cries* for trouble...
<ScottK> pitti: I'd appreciate it if we could have the package. Yes, it will always lag/be incomplete, but that's better than nothing.
<jordi> how does Ubuntu deal with ubuntu modifications that have a bigger version than Debian's next uploaded version?
<pitti> ScottK: ok; as said, I wasn't aware that it was an explicit request
<ScottK> jordi: It shouldn't happen.
<jordi> ie, Debian current is 1.0-2, ubuntu uploads 1.0-3, Debian then uploads 1.0-2.1
<jordi> ScottK: but it did
<mdz> pitti: hmm, spoke too soon, clicking the panel button didn't do what I expected
<jordi> MDZ
<mdz> pitti: it seemed to grab keyboard and mouse, but didn't fade the screen, and I wasn't able to do anything for about 2 minutes
<mdz> jordi!
<pitti> jordi: then the one who uploaded 1.0-3 to Ubuntu should be ... taught not to
<mdz> pitti: then finally the dialog came up, and I canceled it to try to see what happened
<ScottK> jordi: Then that's a mistake.  In general Ubuntu should upload 1.0-2ubuntu1
<ScottK> jordi: What package?
<mdz> .xsession-errors is full, as always, so it's no help
<jordi> pitti: but besudes that, how do we resolve this? It's clearly a mistake, yes
<pitti> mdz: hm, I think it happened to me, too, but I can't remember any more what the reason was
<jordi> tinyproxy in Debian is 1.6.3-2.1, Ubuntu has 1.6.3-3
<mdz> pitti: any guesses where I could look to see what's wrong?
<jordi> I'm about to upload 1.6.3-2.2
<ScottK> jordi: All we can really do is merge the changes into a 1.6.3-3ubuntu1.
<ScottK> Argh.
<pitti> mdz: I'd check the following: lo interface present? ck-list-sessions has a session for you? session d-bus running?
<mdz> mvo: I can't tell what happened to the upgrader
<Hobbsee> bad zul.
<mdz> mvo: it seems to have finished, but I don't remember seeing it prompt me to reboot or anything
<pitti> mdz: oh, that happened after you upgraded to intrepid, and were about to reboot?
<mdz> pitti: yes
<jordi> Scottk, pitti: I guess I could bump to -3.2 and add a justification in the changelog?
<pitti> hm, I did the same this morning, and it worked for me
<pitti> jordi: in Debian you mean?
<jordi> although this sucks
<jordi> yes
<mdz> pitti: I can't reproduce it; clicking the icon again brings up the dialog right away
<mdz> pitti: but shouldn't the upgrader prompt me to reboot immediately anyway?
<pitti> jordi: sure, possible, but I think we could just wait until Debian gets a non-NMU again, and in the meantime, do what ScottK said
<mdz> ah, probably it didn't because the upgrade failed
<mdz> but I don't remember dismissing it
<pitti> mdz: that would probably be useful, similar to ubiquity
<jordi> pitti: ok. That happened last in 2004 though, before the Oxford meeting. :)
<mdz> pitti: I think it does already, if the upgrade succeeds
<jordi> tinyproxy (1.6.3-2) unstable; urgency=low
<pitti> mdz: mine succeeded, but I wasn't prompted either
<ogra> mdz, the logout dialog you mean ? that asks g-p-m for ability to hibernate/suspend before it comes up ...
<jordi>  -- Ed Boraas <ed@debian.org>  Wed, 11 Aug 2004 12:20:18 -0600
<jordi> la la la
<mdz> anyway, rebooting for real now
<mdz> ogra: hmm, maybe something was wrong there.  but I can't reproduce anymore anyway
<ScottK> jordi: -3.something would make our lives easier here, but I don't think it's justifiable from a Debian perspective.
<jordi> ScottK: afaik there have been more than a few *epoch* bumps due to Ubuntu and Debian version desyncs.
<jordi> X, maybe?
<jordi> But I agree this is not good
<ScottK> I'd suggest 3.0 if you're going to.
<jordi> ScottK: this is https://launchpad.net/distros/debian/+source/tinyproxy/+bug/42598/ fwiw
<ubottu> Launchpad bug 42598 in tinyproxy "tinyproxy is compiled without transparent proxy mode support" [Medium,Fix released]
<ScottK> jordi: It'd certainly make our life easier if you uploaded a higher version.
<ogra> hmm, mdz doesnt seem to come back ...
<pitti> black X...
 * stgraber just reinstalled his lappy with Intrepid. Only broken things: fglrx not appearing in jockey (had to install + patch + start dkms) and missing wireless firmwares
<beDrung> \sh: have a look at bug 221205
<\sh> bug #221205
<\sh> hmm? no bot?
<ubottu> Launchpad bug 221205 in soundtouch "compiling pgAdmin from source gives an warning about underquoted soundtouch.m4 line" [Undecided,Fix committed] https://launchpad.net/bugs/221205
<stgraber> just laggy
<\sh> DktrKranz: ping same bug as above..please comment :)
<DktrKranz> \sh: I have not way to test it right now, but it seems good. Does debdiff fix FTBFS on amd64?
<DktrKranz> (anyway, it will require DebianMaintainerSpec adjustment too)
<\sh> soundtouch_1.3.0-2.2ubuntu0.1_v2.debdiff fixes it (according to bedrung)
<\sh> beDrung: please update the maintainer according to DebianMaintainerSpec and find another M-SRU member :)
<mdz> I survived the upgrade, but only barely
<DktrKranz> \sh: we just need one ACK, and you already gave one (or do we change policy and require two ACKs?)
<\sh> DktrKranz: if we just need one then ok..I thought we are at two acks ... (4 eyes are better then 2 ;))
<DktrKranz> \sh: sure, another review doesn't harm, but I think we are good with just only one ACK (given that we follow SRU verification)
<dholbach> Global Bug Jam Preparation Session in #ubuntu-meeting in 16 minutes.
<beDrung> DktrKranz: yes, it fixes FTBFS on amd64
<DktrKranz> beDrung: is soundtouch fixed in intrepid?
<beDrung> yes
<pitti> mdz: welcome back; X broken for you as well with usplash?
<DktrKranz> beDrung: good, I'll reflect it on bug status. thanks
<mdz> pitti: X broke due to nvidia.ko being missing entirely from lrm
<mdz> pitti: decided to test bullet-proof-x and encountered some problems there
<pitti> ah, that's currently split out to separate packages, yes
<mdz> pitti: also lrm-common is missing the tools (including lrm-manager)
<mdz> pitti: split out to separate packages?
<pitti> mdz: AFAIU Timo and Alberto, this is supposed to go away, since the modules will not be renamed any more
<pitti> mdz: right
<pitti> mdz: in fact, l-r-m will shrink to just a bunch of firmware files, AFAIUI
<pitti> tseliot and tjaalton would know details
<pitti> mdz: but the idea is to repackage them using DKMS, and each driver on its own, so that it becomes easier to maintain
<mdz> pitti: but meanwhile, they're missing entirely?
<pitti> as well as you don't need to install both
<tseliot> mdz: even with lrm-common and the nvidia.ko file, the driver wouldn't work on Intrepid. It needs some patches
<mdz> is this "envy-ng"?
<pitti> mdz: I don't know TBH, I just updated to intrepid today as well, and only my laptop (which has intel)
<mdz> tseliot: bug 243863 says that the current version ought to work with .26
<ubottu> Launchpad bug 243863 in linux-restricted-modules "there is no nvidia module/driver (interpid)" [High,Triaged] https://launchpad.net/bugs/243863
<pitti> tseliot: oh, it isn't compatible with 2.6.26 yet?
<tseliot> pitti: it depends on which driver version we're talking about
<pitti> tseliot: I wasn't aware that the current l-r-m already threw them out
<tseliot> mdz: driver 169.12 doesn't work with 2.6.26
<pitti> I thought intrepid still had the old -new, -legacy, -glx
<tseliot> pitti: it has those packages
<pitti> ah, that would be it then; so -legacy and -glx don't work?
<pitti> but -new does?
<tseliot> however the kernel modules are not included in the linux-restricted-modules
<tseliot> and nvidia-glx-<version> doesn't work without its kernel module
<tseliot> mdz, pitti: the new packages will be ready soon, I promise
<mdz> tseliot: right, the bug says there is a new version from nvidia which supports .26
<tseliot> mdz: 173.xx.xx does support kernel 2.6.26 and so does 177.xx
<pitti> tseliot: is there any chance at all to make the odler versions work on .26?
<tseliot> however they won't work without their respective kernel modules
<pitti> (since the newer versions don't support older models)
<tseliot> pitti: I'm writing the patches for them right now
<pitti> tseliot: oh, wow; so that is in the sourceful bits
<beDrung> \sh, DktrKranz: done
<tseliot> pitti: yes, a few functions and variables have to be removed and/or replaced by others
<cjwatson> any objection to me dropping hplip's recommends: hplip-gui to suggests?
<cjwatson> possibly also hpijs-ppds though I'm not sure
<mdz> pitti: something is still wrong with usplash on this machine, but it was having problems there before
<mdz> cjwatson: none whatsoever
<mdz> cjwatson: I had cause to look at it a few days ago and found it  wanting anyway
<mdz> it didn't provide much beyond what system-config-printer gives us
 * cjwatson is trying to get the list of extra packages pulled into the desktop by Recommends down to something manageable
<mdz> cjwatson: I can't speak for hpijs-ppds; that sounds important
<mdz> hpijs is the default driver for many printers
<cjwatson> hplip (2.8.6-1ubuntu1) intrepid; urgency=low
<cjwatson>   * Merge with Debian unstable. No remaining Ubuntu changes.
<cjwatson>  -- Till Kamppeter <till.kamppeter@gmail.com>  Mon, 23 Jun 2008 16:37:02 +0200
<cjwatson> blink
<pitti> but if we haven't installed it by default so far, we can probably do without?
<pitti> tkamppeter: ^ that's the point where you should request a sync (but I think I already told you about that one, right)
<cjwatson> I'll just do hplip-gui for now; the other at least doesn't pull in a bazillion dependencies
<cjwatson> BTW, I'm inventing even more seed syntax for the recommends-by-default thing
<cjwatson> I've opted for 'feature follow-recommends' in the STRUCTURE file
<cjwatson> 'feature' is followed by a space-separated list of flags
<cjwatson> this is the easiest way to keep germinate doing the right thing for <= hardy
<tkamppeter> hpijs-ppds is not needed. It is a bunch of ready-made PPDs which are for us generated by the hpijs.drv file coming with the HPIJS package and CUPS DDK.
<cjwatson> so the Recommends should be removed altogether?
<cjwatson> I mean, there's no point even suggesting it if it's not needed
<tkamppeter> cjwatson, you are right.
<cjwatson> ok, will do, thanks
<cjwatson> file-roller Recommends: rpm. What do we think? Seems not entirely useless
<mgross> I'm wondering how to test freedesktop.or Xserver bits on a ubuntu desktop system.  Are there any how to pages?
<Riddell> mgross: run them?
<pitti> cjwatson: hm, but 1.6 MB..
<mgross> Riddell: yup, I can build them but I want to run them without poluting the base install
<cjwatson> pitti: Size: 625388
<pitti> cjwatson: librpm4 is 1 MB
<pitti> I don't think we pull that in by default, do we?
<seb128> mdz: if you got bug #126797 on upgrade that's a different case than the one described there because before you stated on the same bug that your issue was not after a package upgrade
<ubottu> Launchpad bug 126797 in gdm "gdm spawns a new X server when told to restart the system" [Unknown,Fix released] https://launchpad.net/bugs/126797
<seb128> hum, no mdz ;-)
<cjwatson> pitti: oh, right
<cjwatson> yeah
<pitti> seb128: mdz has been intrepified
<seb128> I'm pondering doing that to my laptop
<cjwatson> mvo: friendly-recovery should recommend gettext-base rather than gettext, right? it's just for gettext.sh? (if so, I have that change in my working tree and can commit/upload)
<mvo> mdz: upgrade-finished> yes, another problem, it does not have a "upgrade-finished" prompt when there are failure, fixed in my bzr tree now
<cjwatson> oh, no, I can't, it's in ~mvo
<mvo> cjwatson: yes, it just needs gettext.sh, thanks for noticing that
<seb128> but I've still around 20 hardy updates waiting for approval and I would prefer to still run hardy when those are accepted
<cjwatson> mvo: will leave it to you then
<seb128> mvo: ENOMDZ
<mvo> cjwatson: feel free to push it to ~ubuntu-core-dev
<mvo> seb128: heh :) thanks
<seb128> ;-)
<mvo> cjwatson: ok, I will take care of it
<mvo> cjwatson: and push it to ~core-dev
<pitti> mvo: you can change the team in the branch details
<cjwatson> oh, ok, I was about to :-) but go for it
<mvo> mathiaz: note to logout/login is possible with debconf for the upgrade hooks
<mvo> pitti: oh, nice
<pitti> mvo: I keep mixing up registrant and author (it's not obvious which is which), but one works
<mvo> pitti: nice feature, I was not aware of this :)
<Riddell> pitti: dbus-1-qt3 in New again if you have time to check
 * mvo pushes the new friendly-recovery branch
<pitti> Riddell: accepted
<Riddell> thanks
<sistpoty> cjwatson: out of curiosity, is there a reason to disable autoindent in vim for ubuntu?
<Nafallo> sistpoty: it's really annoying when you paste indented code in? ;-)
<laga> :set paste
<laga> ?
<sistpoty> Nafallo: hm...? autoindent doesn't seem to do set for me, at least not while I was working on debian/stable systems
<sistpoty> Nafallo: I may be wrong, but imo the effect is just if you type in a line
<Nafallo> oh well. I'll live either way :-)
<sistpoty> Nafallo: well, it's no biggie, as I can easily override it (and I guess most vim users can so as well *g*)
<Nafallo> sistpoty: quite :-)
<sistpoty> <- vim novice, due to only 9 years of experience *g*
<pitti> "set pastetoggle=<F9>" FTW!
<mvo> pitti: I filed #245601 about the liblmdbm-perl" promotion, let me know what/if anything else is required there
<pitti> that sounds harmless enough
<mvo> great, thanks. its tiny too
<cjwatson>   * Don't autoindent by default (Ubuntu: #5602)
<cjwatson> sistpoty: ^- (bugzilla reference)
<cjwatson> which is bug 12000
<ubottu> Launchpad bug 12000 in vim "vim should DTRT by default or a sane vi should be supported too" [Medium,Fix released] https://launchpad.net/bugs/12000
<cjwatson> that said, it's possible we could drop that now that vim-tiny exists and is installed by default
<sistpoty> ah, thanks cjwatson
<cjwatson> but at any rate, that's the history
<sistpoty> hm.. interesting it still affects the first pasted line
<mvo> (offtopic) if someone speaks turkish, could you please check if http://paste.ubuntu.com/25046/ makes sense (i.e. would be understood)?
<ogra> mvo, translating your holiday mail while working ? :)
<mvo> ogra: exactly :P
<tseliot> pitti, mdz: just FYI my patches for the nvidia drivers work in Intrepid. I will test the packages on a 64bit system tomorrow.
<sistpoty> tseliot: does that mean we'll have working nvidia blob drivers soon again?
<cjwatson> just from my experience of seeing Turkish, I'm sure at least one of those 'i's statistically ought to be undotted
<tseliot> ï»¿sistpoty: yes :-)
<sistpoty> tseliot: excellent, thanks a lot :) (and feel free to ping me, if you need someone to test *g*)
<tseliot> ï»¿sistpoty: ok ;)
<cjwatson> I think I'm bored of chasing Recommends now
<cjwatson> germinate change to follow Recommends is in trunk, if anyone wants to try it out
<cjwatson> to enable it, put 'feature follow-recommends' at the top of STRUCTURE in a local checkout of the seeds
<Lrrr> cjwatson: I can I has germinate documentation? ;D
<cjwatson> Lrrr: you can has man page
<cjwatson> tell me what's missing, I know it inside-out myself so it's of course hard to know what other people don't :)
<Lrrr> Afaik, meta tags in the seed files are not documented anywhere.  I wanted to check the source to see what's supported because I might be missing useful things.
<cjwatson> meta tags?
<Lrrr> I mean, things such as Task-Seed and Task-Metapackage.
<Lrrr> Task-Seeds is in germinate-update-metapackage manpage, fine.
<cjwatson> oh, those aren't actually parsed by germinate itself, which is why it doesn't document them
<cjwatson> mostly they're for tasksel
<cjwatson> but sure, I can document those
<Lrrr> Anyway, don't care.  I know my way around germinate source so when it'll bother me enough I'll add it.
<Lrrr> I just wish I had time to work seriously on it.
<Lrrr> BTW, if you remember I told you LVM preseed possibly did not work with d-i.  I was wrong.  I had not updated enough partman components.  Now it work just fine.
<cjwatson> Lrrr: documented now
<cjwatson> Lrrr: ah good
<Lrrr> man you are fast.
 * Lrrr pulls
<cjwatson> anything else before I upload 1.3?
<Lrrr> No not really.
<cjwatson> I suspect the biggest thing germinate(1) needs is some examples
<cjwatson> it's all a bit abstract and hard to get one's head around in isolation
<Lrrr> I don't know how many people actively use that.
<cjwatson> not many I imagine
<cjwatson> it's a rather specialist tool, after all
<laga> cjwatson: yes.
<cjwatson> (cool, but specialist ;-) )
<laga> it'd be cool if the whole seeds thing was documented better
<Lrrr> Outside of Ubuntu I know just 1 person using it.
<laga> what do they do with it?
<Lrrr> A custom distro.
<Lrrr> And that's pretty much what I do with it too.
<cjwatson> somebody was trying to use it to construct Debian CDs a while back
<Lrrr> I use it for that purpose.
<cjwatson> and I heard of somebody using it to manage metapackages in a similar way to us
<Lrrr> I love to subvert Debian and Ubuntu tools for my own world dominative purpose.
<cjwatson> http://ubuntu.dustinkirkland.com/manpages/intrepid/man1/germinate.html - seems to format fairly reasonably there
<geser> pitti: looking at the last comment on bug #245178, I guess there went something wrong with the sync. Could you check?
<ubottu> Launchpad bug 245178 in ftpmirror "[Sync Request] please sync ftpmirror from debian/unstable (main)" [Wishlist,Fix released] https://launchpad.net/bugs/245178
<Iulian> Riddell: FYI: Giver was uploaded to Debian.
<pitti> geser: done
<Riddell> Iulian: ok, let me know when it's in and I'll sync
<Iulian> Riddell: Sure, thanks.
<sebner> te =)
<sebner> ah sry
<zerwas> Has there been a discussion or feature request about implementing a dialog which allows a user to install the application that can handle a link when he clicks on a protocol in firefox that firefox does not understand by default?
<zerwas> hm, hope this question was understandable
<nxvl> zerwas: asac is the person to talk to
 * Nafallo got confused in the middle somewhere
<Nafallo> ah
<Nafallo> now I get it :-)
<asac> zerwas: look at how the apturl package does it
<zerwas> asac, ya i have had a look in it a few months ago
<nxvl> Nafallo: yes, i needed to read it 3 times to get it
<zerwas> my first question is only if it already had been discussed and perhaps been dropped (due to security issues or so)
<nxvl> :P
<zerwas> Nafallo, ok easier: a webpage containing an irc:// link. i click on it and a dialog comes which asks me if i want to install an IRC program (xchat)
<Nafallo> "The shellcode returned a non zero exit value. Would you like to try as root?" :-)
<zerwas> think that would make it much easier for beginners to use IRC when they come across a note of an irc channel
<asac> zerwas: that idea is nice. and it can be solved in a upstream fashion (with distro integration) or in a distro-only fashion
<asac> zerwas: i am sure that both sides have been proposed at some point
<asac> but most likely nobody implemented it
<asac> zerwas: the way to get things started is to write a Specification
<asac> discuss that; get it approved and find someone who implements it ;)
<zerwas> asac, unfortunately i am only a beginner in programming ... but this idea came in my mind a while ago
<zerwas> asac, okay that sounds feasible
<asac> zerwas: you can even start a specification
<asac> and register it in launchpad
<asac> maybe someone else will fill in the implementation details
<asac> zerwas: you could at least draft the use-cases ;)
<asac> zerwas: look in the wiki for a specification template
<asac> once you are done you can register your specification in launchpad
<zerwas> asac, ok thank you very much for these hints! :-) i may try it
<zerwas> or ask some people to help me with it if they agree it would be a nice feature
<asac> zerwas: its not a simple thing as more than one component will be involved
<asac> zerwas: so better draft a spec first
#ubuntu-devel 2008-07-05
<jablko> how can i build an alpha 1 iso from source?
<jablko> are there scripts to build the ISOs - under version control somewhere?
<lamont2> jablko, debian-cd, iirc
<Hobbsee> pitti: interestingly, i didn't get a black X on my next boot, after shutting down my machine for the night (with a splash screen).  is it only a reboot thing, or does it only happen the first time after you reboot after that update?
<Hobbsee> cjwatson: definite blink.
<pitti> Hobbsee: always happens to me so far, even after several boots
<pitti> might be a race
 * wgrant is happy that his i915 is working fine.
<rleigh_> Hi folks, sorry if this is OT.  When launchpad was set up, IIRC Debian developers were created accounts automatically; does the same apply to the forums?  I've tried to register using "rleigh" as the user, but apparently I can't do that (or reset the password--is it locked?).
<james_w> hi rleigh_
<james_w> there is a #launchpad channel that will probably be more helpful
<rleigh_> james_w: Thanks!
<Hobbsee> james_w: ...?
<Hobbsee> james_w: does launchpad deal with the forums now?
<gnomefreak> Hobbsee: no LP doesnt support forums as in LP account is not transfered over for simple reasons like names aval. in one may not be in another
<Hobbsee> gnomefreak: i didn't think so
<gnomefreak> rleigh_: see my comment above for your answer
<rleigh_> gnomefreak: OK, thanks.
<gnomefreak> rleigh_: np
<mo> i have a problem with the dm_crypt password dialog at boot time. it does not take my password. if i wait and let me drop into initramfs-shell, i can mount everything with cryptsetup and go on booting. any ideas!?
<Chipzz> !weekend | mo
<ubottu> mo: It's a weekend.  Often on weekends, the paid developers, and a lot of the community, may not be around to answer your question.  Please be patient, wait longer than you normally would, or try again during the working week.
<Chipzz> also I'm not sure exactly how stable the functionality you're inquiring about is
<stgraber> Chipzz: encrypted LVM is a supported partitioning using Ubuntu Alternate
<stgraber> it's currently (at least the installer part) a bit broken in Intrepid but it's stable in Hardy and works well (at least here)
<stgraber> anyway, it's always best to file a bug report on LP and let the triagers and developers have a look at it
<alex-weej> need to pick someone's brain before i try and file this bug on behalf of a friend
<alex-weej> he has one of the apple mighty mouse things, bluetooth and all
<alex-weej> crap.. wrong channel
<mo> i first tried it by myself and then the alternate installer. allways the same
<mo> first i thought the enrypt modules are not loaded or not included in the initramfs, but as is said in the initramfs shell i can easly mount them by myself en continue booting
<alex-weej> is there some way to get "foreign" file systems whose UIDs don't match up with the running system's UIDs to just grant full access?
<alex-weej> i think i need to write a blueprint.
<Chipzz> any sysadmin here? packages.ubuntu.com appears to be down
<zorglu_> on hardy, ulimit by default is "max locked memory       (kbytes, -l) 32" so program refuses to run in normal cases. as one can not requires from user to change the ulimit, we have to change remove the mlock
<zorglu_> not a good move as it decrease security for no reason
<superm1> Chipzz, /j #canonical-sysadmin
<laga> zorglu_: ulimit says "unlimited" on my box
<geser> superm1: is p.u.c already hosted by canonical?
<superm1> geser, i thought it was?
<Adri2000> it wasn't until very recently at least
<zorglu_> laga: try "ulimit -a"
<geser> superm1: afaik frank lichtenfeld hosted p.u.c and packages.debian.org but there was a question about hosting on the ubuntu-devel ml but I don't remeber the outcome of it and if it switched in mean time
<superm1> geser, i was assuming that it had switched when the new SW interface was loaded on p.u.c
<superm1> but i may be wrong
<laga> zorglu_: indeed
<Adri2000> it seems you're right superm1: packages.ubuntu.com has address 91.189.94.219 and 219.94.189.91.in-addr.arpa domain name pointer sulfur.canonical.com.
<geser> superm1: I don't know, but I didn't see it mentioned either
<zorglu_> ok need to workaround this no more mlock on ubuntu, now :) security ++ :)
<Chipzz> geser: p.u.c is ambiguous btw :)
<Chipzz> geser: could be both planet or packages ;)
<emgent> heheh true :P
<Chipzz> but packages.u.c was recently moved I believe
<Chipzz> which is supported by the fact that packages.debian.org *does* respond to http requests
<emgent> pa.u.c seems donw
<emgent> s/donw/down/
<Chipzz> emgent: 17:44 < Chipzz> any sysadmin here? packages.ubuntu.com appears to be down
<slangasek> superm1, laga: ping, re: mythbuntu alternates for 8.04.1
<laga> slangasek: pong
<laga> slangasek: still no luck with the SRUs :)
<slangasek> laga: ok :)
<laga> except that superm1 tested one of them. yay.
<slangasek> laga: any sort of time table?
<laga> uh, 2 weeks before i can do anything.
<slangasek> hmm, ok
<slangasek> sooner would be nice, I guess I'll pester superm1 :)
<laga> and i guess if people dont test the SRUs there's no demand for a mythbuntu 8.04.1 :)
<Mirv> any PS3 devels here? I wonder if PS3 images from http://cdimage.ubuntu.com/ports/releases/8.04/release/ should be removed, as I heard even 8.04.1 is simply not functional? 8.04 images were never released over there and people were directed to the enchanced 7.10 build at least before
<slangasek> laga: well, I haven't pulled the 8.04 ISOs yet for mythbuntu, but I feel that we should at some point soon because of the OpenSSL vuln
<slangasek> laga: and of course I would like to be able to put something in its place, rather than just removing it...
<superm1> sladen, the MCC one is cleared.  i'm trying to assemble a good test VM to verify the other SRU
<alex-weej> can someone explain the mailing list situation to me briefly please -- ubuntu-devel still moderated?
<laga> superm1: is it? great. also, you probably meant to talk to slangasek
 * laga hugs superm1 
<slangasek> superm1: ok, good to hear :)
<slangasek> alex-weej: Ubuntu developers are allowed to post without moderation; other posts are moderated
<superm1> laga, well cleared in the sense that i verified it.  someone needs to copy it to hardy-updates probably still
<laga> superm1: is one ACK sufficient?
<superm1> laga, i dont anticipate we'll (easily) get any more testing on it.  i dont believe the SRU spec calls for any specific number of ACK's
<laga> well, basically, we have two ACK's, but mine probably does not count :)
<laga> SRU spec is overrated anyways.
<Chipzz> I'm not sure if this is appropriate here, or if I should ask on #ubuntu-motu (which I already did), but are there any people here who have experience in packaging php extensions?
<alex-weej> why is the default "configured mouse" in xorg.conf using the "vmmouse" driver?
<alex-weej> i don't even use vmware
<superm1> slangasek, laga okay I verified that the other SRU works out correctly too
<slangasek> superm1: spiff - should I go ahead with copying the current alternate images over as 8.04.1, or do they still need further testing?
<superm1> slangasek, i am doing one more test install with the alternate 8.04.1 image to make sure nothing else is broke
<slangasek> ok
<superm1> so in a little bit
<superm1> slangasek, okay test install just finished.  alternate looks OK
<Keybuk> ok, that was _deeply_ suspicious
<Keybuk> both my desktop and laptop both hung at the same time
<ion_> Some kind of a spike in the power supply perhaps?
<Keybuk> ion_: the laptop is on battery power!
<ion_> Huh. :-)
<Keybuk> was just after I did an apt-get
<geser> cosmic radiation
<Keybuk> Jul  5 18:24:50 quest kernel: [199208.875533] ip6_tables: (C) 2000-2006 Netfilte
<Keybuk> r Core Team
<Keybuk> Jul  5 18:24:51 quest exiting on signal 15
<Keybuk> Jul  5 18:33:50 quest syslogd 1.5.0#1ubuntu1: restart.
<Keybuk> ?!
<Keybuk> weird, it looks like it just shutdown normally
<Keybuk> probably iz upstart bug then :-/
<[reed]> is packages.ubuntu.com supposed to be down?
<Chipzz> [reed]: already known
<[reed]> k
<Chipzz> [reed]: I talked to elmo about it, he's aware of the problem, but rebooting the hardware needs physical access
<[reed]> no iLO, kvm, or remote hands? :)
<masood> hi
<masood> can anyone help me out about a question? Why some packages in the ubuntu repository have a strange version such as 4:3.5.9 ?
<LaserJock> masood: you mean the 4: part?
<masood> yep
<LaserJock> masood: that's called an epoch
<LaserJock> it allows packagers fix bad versioning
<masood> LaserJock: is that actually a standard practice?
<LaserJock> yes
<LaserJock> but you only want to use it if you have to
<masood> LaserJock: why does dh_make complain about it then?
<LaserJock> depends on the complaint
<masood> LaserJock: an error message like unknown version
<LaserJock> well, that could be because you don't usually create a new package with an epoch
<LaserJock> masood: is there a reason why you're using an epoch?
<masood> LaserJock: Also, if lets say we have pidgin packages with versions 3.4 and 1:3.5, which packages apt-get consider the newer version?
<LaserJock> 1:3.5
<LaserJock> in fact if it was version 1:1.0 and 3.4, 1:1.0 would be bigger
<masood> LaserJock: sorry i gave a bad example.. how about 3.5 and 1:3.4
<masood> ?
<LaserJock> 1:3.4
<masood> ok
<LaserJock> that's the purpose of the epoch
<masood> LaserJock: last time i tried to add new pidgin in my ppa and I came across this new versions..
<LaserJock> if the upstream developers change version schemes, or if we need to go back to a previous version, or if we make a mistake
<LaserJock> those are times when you'll see an epoch
<masood> LAserJock: how can we actually go back to old versioning scheme if we have one of these epoched version in the repo?
<LaserJock> you have to bump the epoch
<LaserJock> so you'd have to go to 2:
<masood> LaserJock: bump? meaning delete it?
<LaserJock> no
<LaserJock> increase it
<LaserJock> you can't go back
<LaserJock> that's why you only want to use an epoch if you have to
<masood> LaserJock: i got it now. thanks a lot for the help.
<Mirv> alex-weej: ubuntu-devel is moderated, ubuntu-devel-discuss is open for everyone
<alex-weej> yeah thought so. thanks.
 * alex-weej is surprised people read IRC logs that far back.
#ubuntu-devel 2008-07-06
<pipop> anyone here familiar with dual boot in Vista?
<ion_> Iâm not quite sure how thatâs relevant to the development of Ubuntu.
<pipop> oh, sorry
<bliZZardz> pitti: hi..you around?
<bliZZardz> pitti : apparently just realized that python has an interface(as in inbuilt module) to dbus by which handles to various events can be obtained - this is glorious!
<orbisvicis> any reasons for packaging cdemu ?
<maxb> mercurial in hardy-backports is currently not installable because the arch-any mercurial package has been placed into the archive but the depended-upon arch-all mercurial-common package is missing
<maxb> https://launchpad.net/ubuntu/+source/mercurial/1.0.1-2~hardy1 shows the i386 build as "Successfully built  (NEW)" rather than "Successfully built  (DONE)"
<maxb> What is the correct place to report this?
<Hobbsee> jdong: ^
<cjwatson> maxb: yes, that sort of thing happens sometimes when new packages are added - they need explicit archive admin approval to get into the archive. I've processed it now, thanks.
<cjwatson> Hobbsee: jdong can't do anything about that
<Hobbsee> oh, i'ts an archive admin job.
<cjwatson> maxb: (may be an hour or two before the results of my action are visible)
<maxb> cjwatson: Ah, thanks. I didn't think of it being "NEW" in that sense. But now I realize it is new to hardy, so it all makes sense. Do you think it's worth adding a note to the UbuntuBackports wiki page suggesting people check for this issue and note the need for the NEW-acceptance in the backport bug?
<cjwatson> no, not particularly, it's a routine part of archive admin and not something backporters should need to worry about
<maxb> ok
<cjwatson> besides, it takes some time between archive admin processing the backport request itself (and hence the bug) and the binaries appearing for processing
<cjwatson> so the bug wouldn't be a very good place for it anyway
<cjwatson> I've processed the rest of the archive *-backports queues while I was at it
 * ogra sighs ...
<ogra> so if i want proper progress output from dd i have to send a USR1 signal regulary to it ...
<laga> i read "dd i" as "d-i" and hoped you were working on that LTSP script ;)
<ogra> thats doable by using a shell wrapper around my python gui that execs "watch -n1 -- pkill -USR1 ^dd$" before pening the gui and kills the watch after the gui is closed ...
<ogra> anyone have a more elegant solution ?
<ogra> *opening
<laga> cjwatson: thanks for taking care of mercurial, i've had someone report this problem in the mythbuntu forums
<laga> ogra: why don't you use python to send the signal?
<ogra> laga, i'm not in my masochistic phase atm :) working on the LTSP udeb somewhat requires you to want to beat up yourself before starting :)
<laga> oh, really. :)
<ogra> laga, i thought about a gtk timeout or so, but thats still massively ugly
<ogra> (and essentially the same)
<ogra> though what bothers me is less the pinging in a certain frequency, but that it will affect all dd's that are currnently running
<ogra> hmm
<laga> well, did you spawn dd?
<stgraber> ogra: if you start it with subprocess or something similar you can get the pid
<stgraber> and then send the signal to that pid
<ogra> i need its output, so i use subprocess.Popen
<laga> it'd be surprised if you can't get the pid with that. or send signal
<laga> s
<ogra> you can get the pid ... but in a blocking way afaik ... i.e. after it finished
<ogra> i would need it in advance, establish the pinger and *then* run dd
 * laga goes to look at python docs
<laga> anything is better than studying. ;)
<stgraber> laga: :)
<ogra> heh
<stgraber> well, you are actually studying but probably not what you were supposed to study
<laga> kinda, yes. python won't help me with phonetics. :)
<laga> the subprocess docs are surprisingly unhelpful :)
<bdrung_> cjwatson: Bug #37750 should be an duplicate of Bug #47238 and not the other way round. Do you agree?
<ubottu> Launchpad bug 37750 in ubiquity "doesn't ask if BIOS time is in UTC" [Medium,Confirmed] https://launchpad.net/bugs/37750
<ubottu> Launchpad bug 47238 in ubiquity "add UTC/local time checkbox (dup-of: 37750)" [Wishlist,Confirmed] https://launchpad.net/bugs/47238
<laga> ogra: well, "kill" in the os module might work..
<cjwatson> bdrung: why do you feel that the direction matters?
<ogra> there is some module to use procps i think, i'll look into that
<cjwatson> bdrung: and no, I don't agree anyway
<laga> ogra: also, os.process can return the PID, but subprocess can probably do the same
<bdrung> the bug is that you cannot set the hardware clock to UTC or local time while installing. correct?
<cjwatson> yes
<bdrung> so it is a feature request to add an option to do it.
<cjwatson> some bugs are resolved by adding features
<cjwatson> in this case I regard it as a bug that the feature is not present
<cjwatson> in any case, why would that make the direction of duplication important?
<cjwatson> if you don't like the state of 37750, change it, rather than generating lots of confusing mail for little value by switching the duplication around
<bdrung> ok, thats an argument
<bdrung> is there someone working on this bug?
<cjwatson> not at present
<bdrung> adding a checkbox is no big work, so someone should do it. have a look at bug #239782.
<ubottu> Launchpad bug 239782 in ubuntu "Time zone bug in Ubuntu (dup-of: 37750)" [Undecided,Incomplete] https://launchpad.net/bugs/239782
<ubottu> Launchpad bug 37750 in ubiquity "doesn't ask if BIOS time is in UTC" [Medium,Confirmed] https://launchpad.net/bugs/37750
<cjwatson> bdrung: thank you for your recommendation, but please bear in mind that we have many many things to do
<cjwatson> the checkbox itself is not difficult but it comes with a requirement to test all the stuff behind it, which is actually rather complex and fragile
<cjwatson> if you feel you can tackle it, then you're welcome to send a patch and we'll review it
<bdrung> cjwatson: i know. if i had more time, i would have a look at it.
<cjwatson> goes for so many things :)
<bdrung> yes. :)
<bdrung> my list with things i want to do is very long.
<cjwatson> bear that in mind next time you ask why something hasn't been done ;-)
<bdrung> if it's not done then it is your fault. i you have no time you have to recruit someone to do it. ;)
<cjwatson> thank you for your kind remarks
<cjwatson> they are, however, not terribly helpful
<bdrung> this is why i add a smiley
<cjwatson> that's not generally much of an excuse
<cjwatson> "I was only joking"
<laga> "stop bleeding now, please"
<ogra> laga, stgraber https://launchpad.net/usb-imagewriter btw ...
<stgraber> ogra: so that's a GUI for dd if=blah.img of=/dev/sdX ? Looks really good
<laga> ogra: can't you simulate dd's functionality in python?
<ogra> yeah, i was actually expecting it to be a lot more trivial than that bloat it became :)
<laga> open image, open device node, copy 512 byte chunks?
<ogra> laga, there are several options, yes, but none gives me any info about the current amount of copied data without really heavy hacking
<laga> well, count the 512byte chunks? ;)
<ogra> i would need to parse the stream throuh anything ... dd is reliable and proven ... so i decided to keep it as backend
<cjwatson> same reason ubiquity doesn't just call cp -a ...
<ogra> the only thing bothering me is the missing progress output ...
<ogra> i tried sdd since that has such an option, but thats not much help either
<ogra> (it drops dots on stderr for every written block
<ogra> (but does that in one single line which is hard to parse at runtime)
<laga> is it? can't you just get single bytes from stdin instead of reading the whole line?
<cjwatson> I was going to say, what's wrong with .read(1)
<laga> most of the programming i've done in the last three months has been in java, so i'm probably spoiled.
<cjwatson> stderr is usually unbuffered
<ogra> hmm
<tgm4883_laptop> I'm looking at having more options during install for partitioning (more than just guided and manual).  I've tried adding custom recipes in the recipes folder as well as preseeding them, but neither way makes them show up in ubiquity during partitioning.  Could someone at least point me in the right direction?
<laga> cjwatson: ^^ aren't you the ubiquity guy?
<ogra> laga, evand is
<emgent> hello there
<ogra> emgent, hey, something to promote for the netbookers ... https://launchpad.net/usb-imagewriter it needs translators and code contributions (TODO included) :) a package sits in the intrepid NEW queue
<ogra> (there are screenshots linked from the LP site)
<laga> tgm4883_laptop: you need to bother evand ;)
<tgm4883_laptop> laga, will do, thanks
<emgent> ok nice ogra
<emgent> ogra: py+GTK ?
<ogra> and glade, yes
<laga> ogra: how did you solve the progress bar
<emgent> ok nice
<ogra> some shell that should be replaced by python
<laga> yuck :)
<ogra> laga, nope, i wrapped a shellscript around it for now so it works for a start ....
<laga> yeah, still yuck. ;)
<ogra> its one of my hit and run projects that i do for fun ... i have many of these that only last a weekend and produce proof of concept code for others to enhance ;)
<ogra> http://people.ubuntu.com/~ogra/LightBrowser/ or http://people.ubuntu.com/~ogra/MightyMailApp are such things :)
<laga> ogra: nice that you pushed it into intrepid then.
<ogra> well, it does the job
<laga> and thanks for the ltsp-build-client progress bar we stole ;)
<ogra> heh
<ogra> feel free :)
<ogra> but unlike the two others above i want the usb-imagebuilder to actually be used ... having to tell people who want to install a netbook or mobile device to use dd in a console just feels odd :)
<ogra> hese are typically endusers and should get a gui for the task
<ogra> *these
<bigon> rmadison libtotem-plparser10
<bigon> libtotem-plparser10 | 2.22.2-0ubuntu1 |         hardy | amd64, i386
<bigon> libtotem-plparser10 | 2.22.3-0ubuntu1 |      intrepid | amd64, i386
<bigon> libtotem-plparser10 | 2.22.3-0ubuntu2 | hardy-updates | amd64, i386
<bigon> the version in hardy-update is greater than the version in intrepid
<Nafallo> indeed
<geser> I guess it gets fixed when totem get updated to 2.23.x
<bigon> oh right
<bigon> btw brasero needs a rebuilt
<lool> bigon: This happens commonly; some new upstream releases of GNOME updates are first pushed to hardy-updates while we directly jump to the dev release for intrepid
#ubuntu-devel 2009-06-29
<ebroder> Is there any chance of seeing dpkg 1.15 merged into Karmic at this point, or is it too late in the release cycle?
<ebroder> Anybody? I'd like to see the fix to Debian #476899 make it into Karmic, but I don't want to expend the effort if I'd be wasting my time
<ubottu> Debian bug 476899 in dpkg "dpkg: Leaves new conffiles as file.dpkg-new if the conffile is" [Normal,Closed] http://bugs.debian.org/476899
 * ajmitch would probably ask again in a few hours when people are less likely to still be on their weekend
<ebroder> Fair 'nuff
<ajmitch> there's still a few weeks until feature freeze so it's far from impossible
<TheMuso> Maybe another 10-12 hours at least, since the people who work on dpkg are in EU timezones.
<ebroder> ajmitch: More than a few weeks; I just don't know what kind of special treatment dpkg gets
 * ajmitch wouldn't really be willing to do that merge right now :)
<ebroder> MoM says it's a small merge. Not convinced I believe it, but you know
<ajmitch> I imagine that it'd probably be done inthe next week or so if it happens
<ajmitch> last upload mentioned waiting for 1.15.1 in the changelog
<ebroder> Oh, I missed that
<ebroder> I guess I'll go ahead and file a merge bug, even if I'm not going to do the merge myself
<andrew_sayers> FWIW, 1.15.3 will cause some heartache.
<ebroder> how so?
<andrew_sayers> Fixes bug #391165
<ubottu> Launchpad bug 391165 in dpkg "Dpkg::Deps mishandles newlines in Build-Dependencies" [Unknown,Fix released] https://launchpad.net/bugs/391165
<andrew_sayers> I've spent a good portion of the past week reporting bugs in packages that will break when that goes through.
<andrew_sayers> Take a look at https://bugs.launchpad.net/~andrew-bugs-launchpad-net - you can spot when I noticed this issue :)
<ebroder> Ugh. Sounds like fun
<andrew_sayers> Yeah, I had to download every .diff.gz to file all them :s
<andrew_sayers> Anyway, those packages will break when 1.15.3 hits.
<ebroder> Break as in fail to install?
<andrew_sayers> Fail to build.
<ebroder> Ok. That's slightly less concerning
<andersk> Is someone aware that packages.ubuntu.com is only showing karmic packages?
<andrew_sayers> packages.ubuntu.com is up?
<ebroder> Yeah, but ==andersk on only showing karmic packages
<andrew_sayers> Since it was down for almost 24 hours, I'm guessing it's been reformatted or something.
<shaya> anyone have an issue w/ the firefox-3.5 segfaulting on startup in karmic?
<billybigrigger> no probs with 3.5 yet
<shaya> segfaulting for me on startup in libstdc++
<shaya> installing dbg libs now
<shaya> though very very large
<shaya> I think I see the problem
<shaya> libxul from 1.8 is being loaded
<shaya> seems to be that eclipse pulls in the libxul (1.8) lib into /usr/lib/
<shaya> firefox-3.5 (xul 1.9) then links against it
<shaya> and boom crash
<shaya> and removed and it works
 * ccheney finds it interesting that twitter apparently can't handle over 18 tweets/s (reading article about MJ and Google)
<icarus901> anyone getting signature validation failures when trying to pull security updates?
<icarus901> no proxy here
<dholbach> good morning
<jumentous> hi anyone, i was looking for some help understanding anna and the install process, i realise this probably isn't the place but can someone point me in the right direction
<superm1> hi pitti. i forgot to follow up. did jockey-text look sane, or did you want to see any other changes to it?
<StevenK> Morning pitti
<pitti> good morning
 * StevenK blinks at how he misread superm1 saying hi pitti as pitti greeting the channel
<pitti> hey StevenK :)
<pitti> superm1: sorry, didn't get mailed about it, and didn't look over the weekend
<ajmitch> hello pitti
<pitti> superm1: I opened https://code.edge.launchpad.net/~superm1/jockey/jockey-text now as a reminder
<StevenK> pitti: I had one dorky question about the MIRs for UNR -- does ubuntu-netbook-remix-default-settings really need an MIR given it's effectively a bunch of gconf defaults and some packaging around them?
<superm1> pitti, no problems. just wanted to make sure i had some time later this week to sort out anything with it necessary.  switching a few things to depend on such changes and wanted to time it all right
<superm1> thanks
<pitti> StevenK: MIR bug/task, yes; wiki page for trivial packages, simple language bindings, etc., no
<pitti> StevenK: for small packages, just have a quick look at the bugs in D/U
<StevenK> pitti: Right, okay, so I'll leave the task in the bug alone, but I won't write an MIR for it.
<pitti> StevenK: and such meta-packages don't generally require any effort at all, ubuntu-mir just has a quick look at the packaging
<StevenK> pitti: And there is no task for the meta package (unr-meta), should I add one?
<pitti> please
<pitti> tkamppeter: bug 361772 confuses me; it went through a successful SRU, but people have still problems, and there are several open tasks; what's the status of this?
<ubottu> Launchpad bug 361772 in foomatic-db-engine "black squares appearing instead of some letters when printing" [High,Fix released] https://launchpad.net/bugs/361772
<tkamppeter> pitti, I am looking through it currently to update the status. There were two situations how users could run into a Ghostscript upstream bug. One was fixed by the foomatic-db-engine SRU, the other gets fixed by the CUPS SRU of bug 382379.
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released] https://launchpad.net/bugs/382379
<tkamppeter> An additional measure to fix this problem is a change on the Ricoh family PPDs on the OpenPrinting web server which I did some weeks ago.
<pitti> tkamppeter: I just moved cups/poppler to -updates, FYI
<tkamppeter> pitti, Great. Thanks.
<tkamppeter> pitti, I have updated bug 361772, marking the CUPS tasks as "Fix Released" and referencing to bug 382379.
<ubottu> Launchpad bug 361772 in foomatic-db-engine "black squares appearing instead of some letters when printing" [High,Fix released] https://launchpad.net/bugs/361772
<ubottu> Launchpad bug 382379 in poppler "pdftops CUPS filter has several problems" [High,Fix released] https://launchpad.net/bugs/382379
<pitti> tkamppeter: thanks
<pitti> tkamppeter: the open ghostscript task is still valid then?
<tkamppeter> pitti, yes. The upstream bug in Ghostscript is not fixed yet. We do not need to do an SRU when the Ghostscript developers fix the problem, as the changes in foomatic-db-engine, in cups, and also automatic updating of PPD files of existing print queues in all printer driver packages prevent from the Ghostscript bug affecting any Ubuntu user.
<ebroder> pitti: Just saw the build failures for xen-3.3 to karmic. I swear these built the last time I touched them :)
<ebroder> I'll try to figure out what's up
<pitti> ebroder: oops; thanks
<ebroder> pitti: Do I bump the version number when the package FTBFS's?
<pitti> ebroder: yes, you need to
<pitti> and a new changelog
<ebroder> Sure
<ebroder> Oh, as in leave the ubuntu10 entry in there and add a separate ubuntu11 one with just these changes?
<pitti> right
<ebroder> Ok. Will do
<StevenK> pitti: So, I'm happy to leave the tasks as New, should I set them to something else when I have the MIR attached to the bug report?
<pitti> StevenK: that's fine
<al-maisan> Moin pitti, how are you?
<pitti> hey al-maisan; good, thanks!
<pitti> and you?
<al-maisan> pitti: not too bad :)
<\sh> moins
<al-maisan> pitti: I was wondering  what a "fake sync" is ..
<pitti> al-maisan: ah, it's essentially: take our orig.tar.gz, apply the debian diff.gz, add a "-Xbuild1" changelog with "fake sync from Debian (different orig.tar.gz)"
<al-maisan> pitti: I see .. thanks!
<pitti> al-maisan: that's something mvo can do easily, not necessary to upload a patch or so
<dholbach> al-maisan: it's cases where we can't sync because soyuz (and dak) already know a file named project_version.orig.tar.gz with a different md5sum
<al-maisan> pitti: even better, the ball is mvo's court now :)
<al-maisan> dholbach: gotcha!
<ebroder> Hey pitti: Xen died because it's being built with -Werror and threw a bogus warning. How bad would it be to add a -Wno-error for that particular subdirectory?
<pitti> ebroder: you can't fix the warning?
<pitti> ebroder: no-error is fine for me
<ebroder> I'm not seeing an easy way to fix the warning
<ebroder> Ok, I think -Wno-error is the most straightforward fix, honestly
<pitti> ebroder: calling memset with zero length?
<pitti> that doesn't make sense
<ebroder> Yeah. It's actually calling memset with sizeof(a_struct) where a_struct is an empty struct
<pitti> what's the code doing?
<pitti> ebroder: couldn't you just comment out that memset then?
<ebroder> Hmm...I guess that wouldn't actually change anything...
 * tjaalton hugs doko for the new eclipse :)
<dholbach> pitti: sponsoring king! :)
<pitti> dholbach: well, that's still you according to the statistics :)
<dholbach> pitti: I just noticed that you're working on it right now
<dholbach> and that's great :)
<pitti> right
<jamesh> pitti: do you how hard would it be to write a dh_shlibdeps style program if I've already got the logic to determine file dependencies?
<pwnguin> new eclipse?
<pitti> jamesh: what is a file dependency?
<pitti> jamesh: in general, dh_* are pretty easy (just look at it, it's perl)
<pitti> the dh lib does all the ground work for you already
<jamesh> pitti: This is to try and automatically calculate dependencies for Erlang programs
<pitti> jamesh: everything it needs to do is to set a dpkg variable ${your:depends} to the value you compute
<jamesh> pitti: I did a proof of concept Python program that can scan the Erlang .beam files, determine what they import, scan the /usr/lib/erlang directory to find those modules and finally do "dpkg -S" to find the package names
<pitti> jamesh: dh_shlibdeps is 88 lines of code, of which you can probably reuse most
<pitti> jamesh: oh, that wouldn't be debhelper then, though
<pitti> since that has to work at build time without all the (potetial) dependencies being installed
<pitti> if you build-depend on them, it would work, of course
<pitti> but then you already figured them out?
<pwnguin> doko: excellent
<jamesh> pitti: from the small sample of Erlang packages I've looked at, they generally build-depend on their dependencies
<jamesh> I'm not sure if that's due to a requirement in the compiler or not though
<pitti> jamesh: could be; for programs with test suites during build you also generally need them
<jamesh> pitti: out of interest, if this job weren't being done by debhelper, what would do it?
<pitti> jamesh: as I said, if the purpose is to fish out the three needed dependencies from your erlang-all-libs-meta package, dh is fine
<pitti> jamesh: there is little precedent for figuring out dependencies which aren't installed by b-deps, I'm afraid
<pitti> jamesh: for C programs, people generally determine build dependencies by a combination of reading configure.ac, READMEs, and try&error
<ebroder> pitti: Should I open a new bug for the Xen FTBFS bug, or just attach it to the one with the ubuntu10 patch?
<jamesh> pitti: I basically want something that will get correct minimal dependencies for binary packages and not break when the next upstream release comes out
<pitti> ebroder: as you wish; reopen it if you do the latter
<ebroder> *nods*
<jamesh> (or reduce the set of dependencies if upstream drops a dependency)
<pitti> jamesh: dh sounds fine then, if you assume that b-deps pull everything in that you potentially need
<Guest53149> hi all
<ttx> doko: I posted a workaround patch for the SHA384withECDSA ca-certificates-java issue on bug 392104.
<ubottu> Launchpad bug 392104 in ca-certificates-java "[Karmic] Update to ca-certificates 20090624 prevents ca-certificates-java from installing" [High,Confirmed] https://launchpad.net/bugs/392104
<cjwatson> ebroder: I have the dpkg merge half-done, just haven't quite got round to finishing it
<cjwatson> ebroder: still intending to do it
<ebroder> cjwatson: Great! I'll trust that you can handle it way better than I :)
<ebroder> I'm not trying to pressure you or anything, I just was trying to poke around to see what the situation was
<cjwatson> understood
<doko> tjaalton, pwnguin: and I'm filing a bug report to remove this package again, because it does include a handful or more third party libs inside the eclipse package. if you want to keep eclipse, please fix these bugs, hint, hint ;)
<ttx> doko: one issue is that the patched ca-certificates-java won't build in current karmic (with ca-certificates preventing ca-certificates-java to install as a build-dep)
<lesshaste> hi.. I have a weird bug where after a poweroff (shutdown -h or shutdown -P) my laptop skips grub when it restarts but after a restart (shutdown -r) it doesn't
<ttx> doko: so ca-certificates might need to be temporarily reverted first
<lesshaste> the problem is that I am missing some key facts.. does jaunty have some script that kick starts the kernel super fast somehow? (kexec?)
<lesshaste> that might be causing this
<cjwatson> lesshaste: only if you have the kexec-tools package installed. Do you?
<doko> ttx: yes, two ca-certificates upload (buildN) with the -java upload in between should work
<lesshaste> cjwatson: I believe not
<cjwatson> lesshaste: can you check, please?
<lesshaste> cjwatson: locate kexec only shows files in the linux headers
<cjwatson> dpkg-query -W kexec-tools
<lesshaste> dpkg-query -W kexec-tools
<lesshaste> No packages found matching kexec-tools.
<cjwatson> ok
<cjwatson> in that case, forget kexec, it's not your problem.
<cjwatson> I have seen another bug report to this effect, but have no idea what could be causing it
<lesshaste> cjwatson: so on a technical level, which part of the system could skip grub?
<cjwatson> none that I'm aware of
<cjwatson> you're sure the whole of grub is actually being skipped, and not just the grub menu?
<lesshaste> no I am not sure but I can't find any useful logs
<cjwatson> there won't be any
<lesshaste> is there a way to turn on logging somehow for this?
<cjwatson> no
<lesshaste> hmm
<cjwatson> what settings do you have for timeout and hiddenmenu in /boot/grub/menu.lst?
<lesshaste> http://launchpadlibrarian.net/28500841/menu.lst is at https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/389930
<ubottu> Ubuntu bug 389930 in grub "grub menu skipped after shutdown" [Low,New]
<lesshaste> it's also clearly assigned to the wrong place which doesn't help
<cjwatson> no it's not, it just has a stray task on gnome-power-manager
<lesshaste> it's assigned to grub now
<cjwatson> it's assigned to grub *as well*. Launchpad bugs can have tasks on multiple places
<lesshaste> umm.. hang on.. possible user error
<ebroder> pitti: Fix for xen-3.3 is attached to bug #393376. I'll subscribe ubuntu-main-sponsors soon, but I want to at least pretend to test the resulting package before I do. Hopefully that'll be some time tomorrow
<ubottu> Launchpad bug 393376 in xen-3.3 "xen-3.3 3.3.0-1ubuntu10 FTBFS" [Undecided,In progress] https://launchpad.net/bugs/393376
<tjaalton> doko: where is the package developed?
<tjaalton> doko: I mean the repository
<tjaalton> doko: if there is one
<lesshaste> cjwatson: sadly no user error :(
<cjwatson> lesshaste: you could try pressing Escape at boot to see if that brings up the grub menu
<cjwatson> lesshaste: other than that, I have no idea. sorry.
<tgpraveen> hi i wanted to know will we get that delta debs feature in alpha 3 or 4?
<tgpraveen> is any work being done on it. it would really make it easier for ppl like me on slow connection to help out in testing
<chrisccoulson> hey cjwatson - i'm not sure if you saw my message the other day about your gnome-session issue
<lesshaste> back in a moment
<doko> tjaalton: I updated the packaging in the debian pkg-java repository
<cjwatson> chrisccoulson: I did, but don't know what to say. It reproduces for me by calling the D-Bus RequestReboot() method in a live CD.
<cjwatson> nothing special going on
<chrisccoulson> hmmmm. that's strange. did you manage to test by running "gnome-session --debug" from a failsafe xterm, and redirecting the output to some permanent storage? the log may show what is causing it
<tjaalton> doko: ah great
<cjwatson> chrisccoulson: haven't yet, sorry
<cjwatson> chrisccoulson: I'm rsyncing an updated image right now, will try after that
<chrisccoulson> cjwatson - no problem. it will hopefully show what is going on :)
<dupondje> pitti: availible ? :D
<pitti> hi dupondje
<lesshaste> cjwatson: ha! cracked at least some of it :)
<dupondje> could u maby get the newest git from gvfs into repo's ? :P
<pitti> dupondje: seb128 has an upload ready, I think
<pitti> dupondje: at least for the latest release
<dupondje> 1.3git20090512-0ubuntu2
<dupondje> is newest
<pitti> right, "upload ready" -> not uploaded yet
<dupondje> oh ok :P
<dupondje> cause mounting is broken :(
<seb128> how broken?
<dupondje> seb128: I subscribed you to the bug :)
<lesshaste> cjwatson: are you still here?
<seb128> I got over 300 emails yesterday I'm not read of reading yours
<dupondje> seb128: https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/393051
<ubottu> Ubuntu bug 393051 in gvfs "Unable to mount any media in nautilus." [Undecided,Confirmed]
<seb128> gvfs didn't change are you sure it's a gvfs bug?
<cjwatson> lesshaste: yes. I was waiting for you to clarify your statement
<seb128> anyway it's monday morning let's catch up with normal tasks before looking at cracky bugs
<cjwatson> I didn't think I needed to say "go ahead" before you would ;-)
<chrisccoulson> wasn't there a devkit-disks and gdu upload before the weekend? mounting seemed to break after that
<dupondje> it was
<seb128> chrisccoulson, read backlog?
<dupondje> and it was a bug reported into gnome, and its fixed in the git atm
<lesshaste> the laptop is a Toshiba,  after a poweroff and restart the Toshiba logo appears and then it goes straight to booting linux without seeing grub, however, it seems that grub is actually running during the part where you can only see the Toshiba logo!
<seb128> we should forbid people to upload on friday afternoon ;-)
<dupondje> check the bugreport, somebody applied the patch I mentioned, and it fixed it
<lesshaste>  tested this by using the down arrow and pressing enter to boot into windows instead of linux.
<dupondje> http://git.gnome.org/cgit/gvfs/commit/?id=384b3a679e3cf5138ada51338d613df517e0658a
<seb128> dupondje, no need to check the bug, I've things ready on disk but that was the weekend and I don't work over the weekend
<lesshaste> cjwatson: strange eh?
<dupondje> :)
<seb128> we should close the bug tracker during the weekends that would avoid being flooded while you take a break ;-)
<dupondje> lol
<dupondje> :)
<dupondje> don't break anything !
<dupondje> :D
<chrisccoulson> seb128 - i'm sure users would find other ways to complain
<seb128> not really "lo"l, it's stressful to start monday with 800 bug emails in your inbox
<chrisccoulson> like e-mailing u-d-d
<chrisccoulson> ;)
<seb128> chrisccoulson, I'm used to ignore this list by now ;-)
<lesshaste> cjwatson:  so whatever part of the system attempts to display to the screen preboot doesn't work after a poweroff (-P), but does work after a restart (-r)
<cjwatson> lesshaste: may just be a broken BIOS then? dunno
<cjwatson> I'm not likely to be able to fix it
<cjwatson> best I can suggest is that you see if grub2 has the same symptoms
<lesshaste> I'll update the bug report and hope someone reading it is interested
<lesshaste>  what part of linux is running when the grub menu is showing?
<cjwatson> no part of Linux is running.
<cjwatson> GRUB's job in this context is to load Linux, therefore clearly Linux isn't running yet ...
<lesshaste> cjwatson: yes of course.. that was a bit dim of me
<lesshaste> cjwatson: so it really is a question of whether grub can fix whatever the bios has screwed up it seems
<lesshaste> and grub is only supported grub2 these days :(
<lesshaste> which isn't in jaunty
<lesshaste> is there an easy way to upgrade to grub2 on jaunty?
<pitti> mdz: did you actually commit your patch for bug 391021? I don't see it in trunk
<ubottu> Launchpad bug 391021 in apport "Dependencies.txt could be sorted" [Low,Triaged] https://launchpad.net/bugs/391021
<cjwatson> lesshaste: see my mail to ubuntu-devel-announce a little while ago
<pitti> james_w: hm, bzr bd -S just blew up for me, is that known? (trying to download upstream tarball) http://paste.ubuntu.com/206107/
<pitti> jamesh: hm, same for bd-do (I now have the orig.tar.gz)
<lesshaste> cjwatson: oh... let me check that
<lesshaste> cjwatson: hmm.. choosing it chained won't actually test whether it can initialise the screen though will it
<cjwatson> lesshaste: probably not
<cjwatson> well, dunno
<cjwatson> it'll probably try to initialise the screen whether it's chained or not
<mdz> pitti, it is definitely committed
<mdz> but is it pushed?
<mdz> pitti, revno: 1476
<mdz> committer: Matt Zimmerman <mdz@canonical.com>
<mdz> branch nick: apport
<mdz> timestamp: Tue 2009-06-23 10:53:14 +0100
<mdz> message:
<mdz>   Sort the list of dependencies so it's easier to scan (LP: #391021)
<mdz>         checkout of branch: bzr+ssh://bazaar.launchpad.net/%7Eapport-hackers/apport/trunk/
<pitti> mdz: weird, 1476 is "ui.py: Do not reject non-distro package reports if report sets CrashDB (for third-party destination). (LP: #391015)" for me
<pitti> mdz: see http://bazaar.launchpad.net/~apport-hackers/apport/trunk/changes
<pitti> mdz: so somehow your commit got lost, weird
<cjwatson> not sure how that could be allowed to happen to a checkout, since commits to a checkout actually commit to the master first and then pull
<mdz> pitti, looks like it is out of sync somehow, I will fix
<cjwatson> don't suppose you used commit --local?
<cjwatson> 'bzr up' should tell you
<pitti> mdz: hang on, I don't think you can currently commit to trunk
<cjwatson> (and should leave you with an uncommitted merge if necessary)
<mdz> pitti, Committed revision 1490.
<pitti> perhaps checkouts get confused if push fails due to -EPERM
<mdz> cjwatson, I think I probably committed locally (thinking I was bound), and then later did 'bzr bind'
<cjwatson> yes, you need push as well as bind in that case
<mdz> the resulting state shows no pending changes with 'bzr status' but in fact there are de facto uncommitted changes
<cjwatson> which is a bit annoying and confusing, I remember filing a bug about that ages ago
<cjwatson> I think bind should automatically push
<mdz> so I forgot about the commit because I couldn't see it anywhere
<mdz> cjwatson, at the least, bzr status should show outstanding changes
<cjwatson> or tell you if it couldn't
<pitti> mdz: I added you to ~apport-hackers now
<mdz> pitti, thanks
<pitti> push should work now
<mdz> pitti, 1490 should be there now
<pitti> right, appears on loggerhead
<lesshaste> cjwatson: I see my exact laptop is in the list https://wiki.ubuntu.com/KernelTeam/Grub2Testin
<lesshaste> +g
<pitti> seb128: apport 1.5 should now work around these constant "412 Precondition Failed" things, as well as fix the recent IndexError; testing/uploading backports now
<seb128> pitti, nice!
<pitti> well, with "work around" -> "except HTTPError: pass" *shrug*
<Keybuk> mdz: bzr missing would have told you what was up
<mdz> Keybuk, hmm, that's not part of my normal workflow
<Keybuk> but I agree, local extra revisions should be included in status output of a checkout
<Keybuk> since you only tend to learn missing if you follow a local branch/push to trunk workflow
<tseliot> cjwatson: I need to check the product name of a laptop so that the debian-installer proceeds with the installation only on that specific model. I'm using dmidecode to check the product name. Would /etc/rcS.d/ be the right place to perform the check? (or maybe /usr/lib/base-installer.d ?)
<cjwatson> neither
<cjwatson> do you just want to halt or something if it doesn't match, or do you want to display UI?
<tseliot> cjwatson: just halt and print a string of text with the reason why it stopped
<cjwatson> /usr/lib/debian-installer-startup.d/ would be appropriate, then
<cjwatson> err, sorry, make that /lib/debian-installer-startup.d/
<tseliot> cjwatson: ok, thanks. Is this documented somewhere?
<tseliot> ah, maybe this one? http://d-i.alioth.debian.org/doc/talks/debconf6/paper/index.html
<mdz> pitti, I wonder why LP didn't automatically link the bug to that commit
<pitti> mdz: did you specify --fixes lp:12345?
<pitti> it might just lag
<mdz> pitti, no, I just put it in the log message
<mdz> I thought that took care of things automatically
<pitti> it doesn't parse log messages
<pitti> mdz: for ubuntu packages, debcommit parses LP: #xxxx out of debian/changelot
<mdz> pitti, hmm, interesting.  I wonder why not.
<mdz> it seems a natural thing to do
<cjwatson> tseliot: that's a sensible paper yes
<tseliot> ok, thanks
<lesshaste> cjwatson: hah! https://bugs.launchpad.net/ubuntu/+source/grub/+bug/374823
<lesshaste> :)
<ubottu> Ubuntu bug 374823 in grub "GRUB menu not showing up at cold boot" [Undecided,New]
<lesshaste> it's just a matter of finding the right words it seems
<pitti> seb128: ok, please delete all the retracer cron mails sent by now; all following breakages are real, I'll look into them
<lesshaste> not that there is a solution there either really
<dupondje> outch
<dupondje> seb128: seems it blows another error now :s
<dupondje> after upgrading gvfs
<dupondje> seb128: added comment to
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/393051 :p
<ubottu> Ubuntu bug 393051 in gvfs "Unable to mount any media in nautilus." [Low,Fix released]
<seb128> dupondje, do you have policykit-1 installed?
<pitti> right, I guess somethign needs to pull in policykit-1-gnome
<seb128> pitti, something being whatever ask for the credentials, grepping for PolicyKit1 in gvfs returns nothing
<pitti> seb128: hm, tricky
<pitti> client programs don't need to know about PK any more, that's one of the nice things
<pitti> but I wouldn't like devicekit-disks to depend on -gnome, since it will also be used in KDE
<pitti> so, of course we can add it to ubuntu-desktop, but not everyone has that
<pitti> seb128: do you think it would be too evil to add a dependency to gvfs?
<seb128> I'm fine adding it to gvfs
<pitti> seb128: i. e. replacing the policykit-gnome one from gnome-mount?
<pitti> since gnome-mount is no more either
<seb128> but how does it work?
<seb128> who does the polkit calls?
<seb128> gvfs or devicekit?
<pitti> I'm not entirely sure, TBH; some clever callback mechanism
<seb128> alright, let's add the depends to gvfs
<seb128> did you mir, etc policykit-1 already?
<pitti> it's just a new upstream version, it went to main
<pitti> it just changed name to be co-installable until everything is ported
<glatzor_> hello mvo. I just merged my gobject branch of aptdaemon. all the threading is now gone!
<pitti> hey glatzor_
<glatzor_> servus pitti and seb128 !
<seb128> pitti, ok, let me grab some coffee and I will do the gvfs update with the depends
<seb128> hey glatzor_
<vadi2> Hi. Does anyone know anything about the "rebootless kernel upgrades" from http://www.ksplice.com/uptrack/ ? Is the thing safe to use?
<dupondje> seb128: wasn't installed, installed it now, but still doesn't work
<dupondje> seb128: ok it worked now after reboot :)
<pitti> dupondje: right, it currently has an .autostart file, thus you need to restart the session
 * apw wonders who is an archive admin today
<jpds> apw: https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days
<apw> jpds, perfect thanks
<ogra> pitti, thanks for the seed change :)
<pitti> ogra: ?
<ogra> f-spot and tomboy for arm
<pitti> ah, I just updated it to drop udev-extras from standard, but you're welcome :)
<directhex> is mono behaving itself on arm today?
<ogra> :)
<ogra> directhex, only f-spot ...
<ogra> banshee and tomboy have probs, havent debugged deeper yet
<directhex> oh? tomboy's not working? that's odd, i thought it was fully managed
<ogra> it works fine until i try to use the notification icon
<directhex> crashes?
<ogra> yep
<directhex> left or right click?
<ScottK> pitti: When you have a moment, I'd like to discuss clamav in -proposed for Jaunty (it's a point release update).
<ogra> directhex, either
<ogra> directhex, Bug 391124
<pitti> ScottK: ah, another round?
<ubottu> Launchpad bug 391124 in tomboy "tomboy crashes on ARM hardware if notification icon is clicked" [Undecided,New] https://launchpad.net/bugs/391124
<ScottK> pitti: We're about to do another round of major updates in -backports, but for Jaunty it should be updatable into -proposed with the existing minor version update authority, so it's a separate issue.
<pitti> ScottK: I see, so they should go to -proposed directly
<ScottK> For Jaunty, yes.
<directhex> ogra, looks like a gtk# problem. i'd forward it upstream asap
<ogra> will do
<ScottK> pitti: The question is about packaging updates.  When I've done point release updates in the past, I've packaged the new upstream for that release based on that release's packaging and not updated the packaging more than absolutely required.
<ogra> directhex, mono-debuuger would surely be helpful :P
<pitti> ScottK: right, makes sense
<ScottK> pitti: The clamav package we released Jaunty with was still not terribly mature, so I'd like to capture the packaging improvements too this time.
<ScottK> So I'm curious how you feel about that and how much detailed justification you want.
<pitti> ScottK: what would that change in particular?
<pitti> ScottK: changes to debconf, any conffiles, etc. are generally a no-go area IMHO
<ScottK> There are some improvements in the inits.  All the debconf translations now match the actual questions.
<pitti> ScottK: cleanup to rules, debhelper, etc. (internal build process) is bearable
<pitti> translation fixes are okay, we update them regularly anyway
<ScottK> OK.
<directhex> ogra, yes, but the debugger's backend is C - and someone would need to port it to arm. until novell start getting demand from commercial arm/linux users (their main arm port is osx) then it'll not be a priority for upstream
<ScottK> pitti: How about init scripts?
<pitti> ScottK: not for debconf translations generally, but it's the same result for the user
<ScottK> OK
<ogra> directhex, yeah, understood, and apparently its not an easy task
<pitti> ScottK: I'm not fond of conffile changes post release, since they cause prompting and potential hassle
<ScottK> pitti: OK.  I'll look through it in detail and make sure I only pull out what makes sense.
<directhex> ogra, well, being written in C is like kryptonite for me, so this is one i can't help with :p
<ScottK> pitti: Thanks for the feedback.
<ogra> mcasadevall took a look and told me its not trivial ...
<pitti> ScottK: whichever approach is easier then, I guess (revert init script changes and keep the rest, or just update upstream version and keep packaging)
<pitti> ScottK: thanks for working on this!
<ogra> so we'll live with gdb
<ScottK> pitti: OK.  No problem.
<lessshaste> cjwatson, hello again.. I just attempted sudo apt-get install grub-pc
<lessshaste> cjwatson, are you about? It didn't quite work out
<lessshaste> I get http://pastebin.com/f9a0cc84 rather worryingly
<lessshaste> I am attempting to upgrade to grub2.. sadly the ubuntu upgrade script made a mess so would anyone be able to look at my edited menu.1st please before I reboot to make sure I will still be able to log in again!  http://pastebin.com/f66d81456
<lessshaste> noone kind enough?? :(
<cjwatson> lesshaste: I don't see what point you're trying to make with those pastebin entries
<cjwatson> lesshaste: what is worrying? what is wrong?
<dvestal> cjwatson: I think that lessshaste was trying to get someone to make sure that he had setup his grub menu.lst file correctly.
<cjwatson> dvestal: thank you but I'd already been talking with lesshaste earlier and know what he was doing
<cjwatson> dvestal: I'm also continuing the conversation on #ubuntu-kernel now
<lesshaste> thanks
<dvestal> cjwatson: ahh. sorry then.
<shaya> anyone here using the firefox-3.5 package besides me?
<shaya> its incompatible w/ the libxul0d package
<shaya> instant segfault if both are installed
<lesshaste> dvestal, but thanks
<pitti> tseliot1, superm1: I uploaded a new jockey with all the recent broadcom wl changes; testing appreciated!
<tseliot1> pitti: great, thanks. I was planning on bugging you about this ;)
<pitti> this also drops libglade, to make seb128 a tad happier :)
<tseliot1> pitti: what's the name of the new module (which replaces libglade)?
<pitti> tseliot1: gtk.Builder
<tseliot1> pitti: thanks, I'll remember to use that from now on
<james_w> pitti: yeah, there's a big filed, I think I know how to fix it
<pitti> james_w: great, thank you
<Caesar> tjaalton: are you tjaalton or timo-aalton on Launchpad?
<Caesar> sorry timo-aaltonen
<dholbach> Caesar: probably the one with more karma :)
<Caesar> dholbach: ah yes, good idea
<dholbach> it's tjaalton
<dholbach> he's in ubuntu-core-dev too
<Caesar> Got him
<tjaalton> heh
 * Caesar waves
<tjaalton> hi
<Caesar> tjaalton: hi, I just filed the first of the two libxcb bugs we discussed
<Caesar> I'll file the second one with the patch when I get to work
<tjaalton> Caesar: ah, great
<tjaalton> ok, I'll have a look tomorrow
 * Caesar heads to work
<pitti> mdz: (just replied to bug report as well); udev-extras removal is deliberate, it's dead
<pitti> mdz: or, rather, merged into udev itself
<mdz> pitti, oh, the versioned conflict confused me
<mdz> Conflicts: hotplug, ifrename, libdevmapper1.02 (<< 2:1.02.08-1ubuntu7), udev-extras (<= 20090618)
<pitti> mdz: we added that just in case we'll ever have an udev-extras with new staging stuff
<pitti> but right now, the udev-extras git head is empty, and kay has no plans to re-fill it
<ogra> cjwatson, https://blueprints.launchpad.net/ubuntu/+spec/mobile-arm-karmic-subarches-in-debian-cd used to be dead, but given that we will have to support two different armel SoCs both using two different bootloaders we will need to revive it, do you have any problem if we implement it similar as the ps3 thing ?
<ogra> s/as the/to the/
<cjwatson> ogra: fine by me as long as you guys maintain the code ;-)
<ogra> (i think i remember to have heard rumours the ps3 hack isnt liked very much)
<ogra> ok, thanks :)
<cjwatson> I'm fine with it actually
<ogra> i'll steal from it then
<cjwatson> well
<cjwatson> the bit I don't like is that they're two separate CDs
<cjwatson> I'd rather that they were a single CD, since most of the content's the same
<cjwatson> if you can arrange for a single image that boots both ways, that's clearly technically superior
<cjwatson> if you can't, the ps3 hack is fine
<ogra> right, having u-boot for one board and redboot for the other makes two images somewhat required in armel land
<lesshaste> hi again
<alkisg> asac, if you'd need any more info or any patch-beta-testing for https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/391040 I'd be happy to help.
<ubottu> Ubuntu bug 391040 in network-manager "When eth0 is unmanaged, system connections for other NICs aren't displayed nor used" [Undecided,New]
<ScottK> slangasek: Ping.  Let me know when your coherent enough to deal with clamav backporting ....
<lesshaste> hi
<FJ_Sanchez> Hi
<FJ_Sanchez> I need help to fix a dependency problem
<FJ_Sanchez> I want to manually change version deps
<FJ_Sanchez> How can I do this?
<kb9vqf_> Anyone here willing to rescore a PPA build?
<kb9vqf_> This one https://launchpad.net/~ubuntu-389-directory-server/+archive/ppa/+build/1097734 and related were affected by a certificates bug that has since been fixed, but it'll be many hours before it rebuilds
<Ampelbein> kb9vqf_: perhaps you are better off asking in #launchpad.
<kb9vqf_> Ampelbein: Thanks for the suggestion!
<asac> alkisg: does it work if you name your iface ethtest (instead of eth0)
<alkisg> asac: eh, rename it from udev rules?
<c_korn> hello, I am trying to package pidgin-2.5.8 using the diff.gz of 2.5.7 in karmic. but after configure these errors occur: http://pastebin.com/d64f79db1
<alkisg> asac: sorry, my X crashed, if you replied about how to rename my eth0 to ethtest I didn't see it
<asac> alkisg: no. rename it in the interfaces
<asac> alkisg: replace iface eth0 ... with iface ethYOUR
<asac> and auto eth0 with auto ethYOUR
<alkisg> ok
<asac> alkisg: after changing that you need to sudo killall nm-system-settings
<alkisg> But #iface eth0 inet dhcp is commented out - or do you want me to modify eth1 which uses a static ip instead?
<Caesar> slangasek: you around?
<alkisg> asac: with the following /etc/network/interfaces, I'm still not able to manage system connections for ethYOUR: http://pastebin.ubuntu.com/206402
<Ampelbein> c_korn: did you update the autoconf patch?
<c_korn> Ampelbein: yes.
<asac> alkisg: well. you still have eth1 in there
<c_korn> http://pastebin.com/d2660e191
<asac> alkisg: try to change that to ethYOUR2
<c_korn> this is the autoconf patch I applied
<alkisg> asac: ok, trying
<robbiew> cjwatson: Keybuk: do you know what the current status of bug 383697 is?  I can't tell from the last few comments.
<ubottu> Launchpad bug 383697 in util-linux "lsb_release crashed with ImportError in <module>()" [Medium,Triaged] https://launchpad.net/bugs/383697
<alkisg> asac: Yes, now I'm able to manage the connections - but of course that was expected, because eth1 no longer has a static ip.
<alkisg> It's the same effect like I didn't declare any ethX interfaces at all...
<Ampelbein> c_korn: looking.
<Ampelbein> c_korn: builds fine here.
<cjwatson> robbiew: no progress since I sent that patch, AFAICS ...
<cjwatson> Keybuk: do you want me to rework it as an Ubuntu-specific patch as implied by your last comment (it would involve nothing more than removing that block) or are you happy to apply my patch as-is?
<kb9vqf_> I am trying to get a fix into the official archives for bug 357556 , and have attached a debdiff/followed all the steps on https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue -- is there any way to speed the process along or do I just wait?
<ubottu> Launchpad bug 357556 in xscreensaver "phosphor crashed with SIGSEGV in fileno_unlocked()" [Medium,Confirmed] https://launchpad.net/bugs/357556
<Ampelbein> kb9vqf_: xscreensaver is in main so the correct team to subscribe is ubuntu-main-sponsors.
<kb9vqf_> Ampelbein: OK
<Ampelbein> kb9vqf_: i unsubscribed u-u-s and subscribed ubuntu-main-sponsors
<kb9vqf_> Ampelbein: I am also looking for an SRU...I'm updating the description now
<kb9vqf_> Ampelbein: OK, I have the SRU request added to the bug
<kb9vqf_> This is my first attempt at this procedure; please go easy on me :)
<Ampelbein> kb9vqf_: no problem ;-)
<asac> alkisg: please post output of nm-tool
<alkisg> asac: working (ethYOUR): http://pastebin.ubuntu.com/206444        -      not working (eth0/eth1): http://pastebin.ubuntu.com/206445
<tjaalton> <
<tjaalton> uh
<c_korn> Ampelbein: did you build the package in karmic or jaunty?
<Ampelbein> c_korn: karmic. but i think i know why it built: i used autoreconf to build, not just autoconf.
<c_korn> didn't you just test the diff.gz for the new version?
<c_korn> I try to build it for jaunty
<sianis> fta: ping
<fta> sianis, pong
<sianis> fta: could you please see this: https://answers.launchpad.net/gwibber/+question/75068
<fta> sianis, is it in the upstream tree?
<shaw> where can I ask about PPA issues?
<sianis> fta: I don't know, we translated it at: https://translations.launchpad.net/gwibber
<sianis> fta: there is no hu.po here: http://bazaar.launchpad.net/~gwibber-committers/gwibber/trunk/files/head%3A/po/
<fta> sianis, ok, i'll ask upstream how they manage their translations
<sianis> fta: thank you, let me know if you have question
<shaw> if I have PPA trouble, where's the best place to ask about it?
<cody-somerville> #launchpad
<shaw> cody-somerville: thanks!
<asac> alkisg: are eth1 and eth0 the only interfaces you have?
<alkisg> asac: yes
<maxb> wgrant: Hi, any news on that xserver-xorg-input-synaptics upload? :-)
<shaya> what's going on w/ udev/udev-extras and ubuntu-standard?
<maxb> shaya: If you still have problems with that after "apt-get update", you have a slow mirror
<slangasek> Caesar: pong
<superm1> pitti, took a look at the handling for 'wl' now with the bcmwl-kernel-source package and jockey. it's really close to right now.  jockey just needs to unload b43/ssb and then load 'wl' and then things should be functional off the live disk
<shaya> maxb: using archive.ubuntu.com
<shaya> though appears its fine now
<pitti> superm1: thanks; can you please file a bug and assign it to me?
<Caesar> slangasek: o hai
<Caesar> I had a random Ubuntu development question for you
<Caesar> I'm half-tempted to email ubuntu-devel instead for wider circulation
<slangasek> Caesar: aw, I'm not wide enough?
 * slangasek eats more doritos
<Caesar> heh
<Caesar> In a nutshell, my question was...
<cjwatson> kirkland: do we need whatever patch https://bugzilla.redhat.com/show_bug.cgi?id=504787 was referring to? I don't seem to be able to boot PAE guests here ...
<ubottu> bugzilla.redhat.com bug 504787 in kvm "F11 - cannot boot 32bit PAE kernel guest under Qemu/KVM" [Medium,Closed: nextrelease]
<Caesar> When Ubuntu merges a package from Debian unstable, is that the end of paying attention to what happens to it in Debian?
<Caesar> For a concrete case, I'm thinking specifically of libxcb in Hardy
<TheMuso> c
<Caesar> Debian just updated Lenny's version of it to address performance issues
<Caesar> It's the same underlying version that is in Hardy
<Caesar> So if I hadn't noticed and filed bugs against Ubuntu, would Ubuntu have noticed?
<kirkland> cjwatson: what are you trying to boot?
<Caesar> By extension, what happens if RC bugs get filed against the Debian version after it's been synced into Ubuntu?
<slangasek> Caesar: merges, or syncs?
<cjwatson> kirkland: install of today's server CD
<kirkland> cjwatson: i'm able to boot the karmic i386 server cd
<Caesar> slangasek either I guess
<cjwatson> kirkland: the server CD installer itself isn't PAE
<cjwatson> kirkland: you need to actually install it
<cjwatson> and then try to boot the resulting system
<kirkland> cjwatson: ah, okay, let me do that
<slangasek> Caesar: in the case of a sync, there's not generally perceived to be an obligation on the part of the syncer to track the bug status of the package in Debian going forward, and the tools currently available don't exactly facilitate that
<cjwatson> kirkland: now, admittedly I was experimenting with grub2 and LVM ... but as far as I can tell it's got past the obvious problem points there and is reading the filesystem successfully
<slangasek> Caesar: in the case of a merge, you're "touched-it-last" for the package and are expected to watch whether there are further updates from Debian that should be merged in the cycle
<cjwatson> (I tend to do experiments like that with the server CD just because it's quicker)
<cjwatson> kirkland: https://bugzilla.redhat.com/show_bug.cgi?id=499596 might be a better report, and the workaround suggested there (-cpu qemu32) works for me
<kirkland> cjwatson: what's your host running?
<ubottu> bugzilla.redhat.com bug 499596 in qemu "32 bit KVM guest hangs enabling NX protection; booting with -cpu qemu32 works" [Medium,Closed: nextrelease]
<cjwatson> kirkland: karmic i386
<kirkland> cjwatson: what cpu?
<kirkland> cjwatson: pae, or non-pae on the host?
<cjwatson> pae
<cjwatson> core2duo
<cjwatson> flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc arch_perfmon pebs bts pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm ida tpr_shadow vnmi flexpriority
<kirkland> cjwatson: curious, do you have any older pae-kerneled images lying around?  do those work, or are those broken too?
<cjwatson> kirkland: not easily - jaunty server i386 worked not *that* long ago though
<kirkland> cjwatson: right, i have definitely tested that one pretty extensively, don't know that i've tested karmic-i386 lately
<kirkland> cjwatson: i'm onsite at eucalyptus, pulling the karmic-i386 iso now
<cjwatson> the patch in http://www.mirrorservice.org/sites/download.fedora.redhat.com/pub/fedora/linux/development/source/SRPMS/qemu-0.10.50-6.kvm86.fc12.src.rpm/qemu-fix-cpuid-trimming.patch?extract=true doesn't seem to apply
<kirkland> cjwatson: if you're slightly brave, you can try the daily build of qemu-kvm at https://edge.launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream
<kirkland> cjwatson: qemu-kvm will be replacing/providing/conflicting qemu and kvm very soon
<kirkland> cjwatson: that's built from upstream git, which might have this patch, perhaps
<kirkland> cjwatson: you can bzr branch lp:qemu-kvm and check the logs
<kirkland> cjwatson: otherwise, i'm downloading the iso now and can try to reproduce it here
<cjwatson> https://launchpad.net/~ubuntu-virt/+archive/virt-daily-upstream description needs a sudo before tee
<kirkland> cjwatson: thanks
<kirkland> cjwatson: is there any way do disable graphics mode in the server installer, such that i can use kvm -curses?
<kirkland> cjwatson: if so, I could boot/install this entirely remotely without vnc :-)
<kirkland> cjwatson: *very* low bandwidth :-)
<geofft> kirkland: you're asking about putting fb=false on the kernel command line?
<kirkland> geofft: oooh, will that do it?  /me tries
<cjwatson> kirkland: DEBIAN_FRONTEND=text
<cjwatson> geofft: that probably won't work quite right ...
<geofft> oh, is there something newer that I missed?
<cjwatson> you want to actually instruct the *installer* not to use a framebuffer, I think
<cjwatson> oh, sorry, fb=false is actually an installer option, I forgot that
<cjwatson> but still, I'd suggest DEBIAN_FRONTEND=text anyway
<kirkland> cjwatson: this is a kernel boot option?
<cjwatson> in low-bandwidth environments you probably want the lighter-weight frontend. It's actually as old as d-i :-)
<cjwatson> kirkland: yes
<directhex> d-i has a non-text-based frontend?
<cjwatson> newt != text
<cjwatson> I mean, as it happens, yes it does, but I think kirkland means how to turn off the full-screen thing
<cjwatson> kirkland: waiting for qemu-kvm to download
<kirkland> cjwatson: heh, i'm waiting for the iso to download
<kirkland> cjwatson: hmm, the bootloader itself goes graphical, which busts kvm's -curses option
<cjwatson> hold down shift at boot, if you can
<cjwatson> I think it's shift
#ubuntu-devel 2009-06-30
<cjwatson> or modify the .iso and remove the 'gfxboot' line from isolinux.cfg
<kirkland> cjwatson: shift didn't get it, will try to sed 'gfxboot' out
<cjwatson> kirkland: qemu-kvm is no help; kvm still exhibits the same symptoms. qemu does work though.
<kirkland> cjwatson: okay, thanks, i'll dig into it;  could you open a bug?
<kirkland> cjwatson: 3min left for iso download
<cjwatson> ok, will do once I downgrade so I can use ubuntu-bug
<cjwatson> no rush, bed soon
<kirkland> cjwatson: sure thing, thanks.
<kirkland> cjwatson: thanks for trying the daily
<kirkland> cjwatson: i'm hoping those become useful
<kirkland> cjwatson: installing both [jaunty & karmic]-server-i386 now
<YokoZar1> did Gnometris disappear off the default games?
<directhex> YokoZar, patents!!!
<YokoZar> what
<directhex> Results of Search in US Patent Collection db for:
<directhex> tetris: 63 patents.
<directhex> or, being less useless, it seems there's no binary for it in gnome-games in karmic
<directhex> the manpage is there
<directhex>   * debian/rules:
<directhex>     - Disabled gnometris as it requires clutter to build
<directhex> there you go.
<RAOF> That might be enabled again later; IIUC clutter is aiming for promotion to main for Empathy + geoloc?
<TheMuso> dtchen: I think you said the otehr day you have been working on rtkit. Do you have anything up anywhere that I could use as a starting point to get pulse 0.9.16 into my PPA for karmic?
<kirkland> cjwatson: okay, i have successfully installed and booted karmic-server-i386 and jaunty-server-i386, both of which I expect are PAE kernels
<kirkland> cjwatson: my host is an x86_64 jaunty system (running karmic's virt packages)
<Caesar> slangasek: so it sounds like in both cases it's a manual process to notice changes?
<slangasek> Caesar: prior to DebianImportFreeze, changes to the /package/ are automatically imported.
<slangasek> changes to /bugs/ aren't going to be noticed automatically
<Caesar> slangasek: I mean for the lifetime of the release that contains that package, particularly LTS releases
<slangasek> that's certainly true, yes
<Caesar> So it seems to me that there's some free work to be capitalised on if it could be automatically noticed
<Caesar> and free improvements
<Caesar> Again, using this libxcb thing as an example
<slangasek> SRUs are entirely driven by user demand (where "user" may be "uploader"); I don't think we should automatically take bugs that are marked as RC in Debian and nominate them as SRU candidates
<slangasek> the libxcb one seems to be an example of us not even keeping up with the demand for SRUs for bugs that users *have* said they care about, let alone auto-importing from debian
<Caesar> Perhaps not automatically nominate them, but auto-import them as applicable?
<ajmitch> auto-import the bugs or the package?
<slangasek> I think that's broadly inconsistent with how we do bug management for released versions of Ubuntu today
<Caesar> The bugs against the package
<Caesar> slangasek: of course it is
<Caesar> I wouldn't be having this conversation with you if it wasn't
<ajmitch> there have been tools to track RC bugs filed against debian that could be fixed in ubuntu, which ought to be fixed to work better for multiple ubuntu releases
<cjwatson> kirkland: I guess it must be i386-host-specific
<ajmitch> but it's not an easy thing, there are many false positives
<slangasek> Caesar: I mean that there are lots of other bugs that are in LP that we do know about already, and know they're applicable to released versions, but we don't mark them as applying to those releases unless we intend to SRU them
<slangasek> so I don't think Debian bugs should be treated differently
<Caesar> Not even fixed bugs?
<slangasek> but perhaps this is a discussion better had on ubuntu-devel to get wider perspectives, yeah
<Caesar> I will write something up and email ubuntu-devel
<slangasek> Caesar: opening tasks for bugs that are already fixed in the old release, just to close them?  sounds like busywork to me
<Caesar> Huh?
<Caesar> It's still applicable to that release
<Caesar> So you're not going to close it
<slangasek> Caesar: fwiw, I /personally/ strongly prefer the debbugs 'version tracking' workflow, but that's not the workflow Ubuntu uses in LP
<Caesar> I realise that
<Caesar> So your best option is to target to a specific release
<slangasek> and not for lack of considering the debbugs model
<slangasek> Caesar: ok, you meant bugs that are fixed in the latest release but still apply to previous releases - yep, tasks only get opened against the other releases if there's an expectation that they're SRU candidates
<Caesar> So I guess I'm proposing that if Debian fixes a bug in a version of a package that ended up in an Ubuntu release, that bug gets imported into LP (possibly along with the fix) for consideration
<slangasek> otherwise, it's implicitly "wontfix", so why open it
<Caesar> slangasek: yes, I'm not talking about the current development release
<slangasek> right, I just misunderstood what you meant by "fixed bugs"
<Caesar> slangasek: you should know by now that I'm usually talking about released LTSes :-)
<ajmitch> Caesar: as a rough start on something we've used for this for universe, see http://qa.ubuntuwire.com/bugs/rcbugs/
<ajmitch> though it only shows info for the development release rather than fixes post-release
<Caesar> ajmitch: that looks cool
<Caesar> Looks like a good starting point
<TheMuso> Yay. Either there is policykit or consolekit breakage that stops audio from working, permissions wise.
<james_w> slangasek: we are in DebianImportFreeze aren't we?
<maxb> Don't forget devicekit breakage too :-)
<slangasek> james_w: ahhh, the things that sprint travel does to one's hold on reality
<slangasek> james_w: yes, we're meant to be, but apparently I gave everybody an extension by running another round of autosyncs today ;)
<james_w> score!
<ebroder> "They're more of just guidelines anyway"
<slangasek> siretart: why have you subscribed ubuntu-archive to bug #223212?  I don't see anything there that's a request for action
<ubottu> Launchpad bug 223212 in linux-restricted-modules-2.6.24 "Non-free files distributed without license/copyright info" [Undecided,New] https://launchpad.net/bugs/223212
<slangasek> siretart: (unsubscribing
<slangasek> )
* slangasek changed the topic of #ubuntu-devel to: Archive: open | DebianImportFreeze in effect | karmic alpha-2 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
<slangasek> superm1: you seem to have subscribed ubuntu-archive instead of ubuntu-mir for bug #390973; adjusted
<ubottu> Launchpad bug 390973 in libftdi "MIR for libftdi" [Undecided,New] https://launchpad.net/bugs/390973
<superm1> slangasek, thanks, sorry my mistake
<superm1> pitti, sure
<billybigrigger> why does apt-cache policy nvidia-glx-180 show....nvidia-glx-180:
<billybigrigger>   Installed: 185.18.14-0ubuntu1
<billybigrigger> while nvidia-x-server settings shows 180.60
<cody-somerville> billybigrigger, because they're different?
<cody-somerville> billybigrigger, see #ubuntu for support please
<superm1> nvidia-glx-180 has a -185 series driver though?
<superm1> that doesn't seem right.
<ajmitch> superm1: that's somewhat intended though
<superm1> ajmitch, how so?
<ajmitch> at least bryce had a reason for doing so when I asked about the package in his PPA
<billybigrigger> well im just confused, as hardware drivers show's the 180 series installed
<billybigrigger> so which driver am i using? 180 or 185?
<superm1> billybigrigger, that's the 185 series driver, just the package is named 180 series
<billybigrigger> seems a bit confusing to me
<billybigrigger> wouldn't it make sense to label a 185 driver as 185, not 180?
<superm1> billybigrigger, that's what i was saying too.
<superm1> bryce, what's the reasoning for that?
<ion> The Gtk 2.17.2 package is called libgtk2.0-0 for the same reason. Itâs ABI-compatible, so other packages donât need to constantly keep changing their dependencies for no reason.
<StevenK> ScottK: Sorry for the delay, I'll be uploading livecd-rootfs presently
<ScottK> StevenK: Thanks.
<bryce> superm1, if the package gets renamed every time there is just a version number change, it makes bug management a PITA
<bryce> honestly, I'd sort of rather the source package be named either xserver-xorg-video-nvidia, or nvidia-installer, for consistency with other drivers
<superm1> bryce, ah
<bryce> superm1, probably we should discuss the naming more
<tedg> If ubiquity is core dumping (bug filed) is there still an easy way to install with the desktop CD?
 * tedg doesn't want to download another CD.
<bryce> it'd be nice to have a "stable" name.  the -177 to -180 transition was awkward as far as bugs go
<superm1> bryce, ah so maybe the stable name is always the same and if there needs to be a legacy drivers then add more source packages
<bryce> that seems like a better scheme
<persia> bryce, Any suggestions?  We dropped -legacy and -new because it confused people.  Having 4 nvidia-foo packages is somehow useful, and I suspect we'll only get more.
<RAOF_> Heh.  nvidia-glx, nvidia-glx-legacy, nvidia-glx-legacy-legacy, nvidia-glx-really-get-another-gfx-card-damnit-legacy? :)
<bryce> actually there's just 3 packages.  -177 went away once -180 was moved to
<persia> I see -71, -96, -173, and -180 on i386.  What shouldn't be there?
<bryce> oh yeah -71
<billybigrigger> http://pastebin.ca/1479097
<bryce> but I think that may not be updated to the jaunty kernel
<billybigrigger> so im not the only one complaining about the naming of 180 or 185
<billybigrigger> :P
<persia> I was looking at karmic, but hrm.
<billybigrigger> is this a normal error?
<RAOF_> persia: I'd guess it's in the archive but actually unusable.
<Kage_Jittai> Can I talk to someone about package development, my project is having a issue
<persia> -71 was last uploaded to jaunty 29 January.  If it's not useful, I think it ought be removed from the archive.
<persia> Kage_Jittai, What specific question do you have?
<DoYouKnow> it took me a while to find out that bcmwl-kernel-sources was the right package to install for broadcom sta wireless driver
<RAOF_> It'd be useful if it works; there are some gpus only supported by -71.  I'm just checking whether or not it actually builds.
<DoYouKnow> finally got it though
<Kage_Jittai> persia: I work on a project called The Mana World
<Kage_Jittai> persia: its a MMORPG
<DoYouKnow> someone told me but I was in kind of a jumpy mood so I was confused
<Kage_Jittai> persia: Our issue is with LTS distros
<DoYouKnow> finally figured it out after a good search on installing ubuntu on the dell mini 9
<Kage_Jittai> persia: as a MMO, we are always coming out with new features
<DoYouKnow> (in karmic)
<Kage_Jittai> persia: many of these features are unsupported
<Kage_Jittai> persia: since people connect to a server, and to play with others
<superm1> DoYouKnow, jockey now supports offering that as of today or so
<Kage_Jittai> persia: unsupported versions being used cause issues
<DoYouKnow> ok
<DoYouKnow> that must be the taskbar on the lower right
<Kage_Jittai> persia: http://pastebin.com/d608d5889
<DoYouKnow> err
<DoYouKnow> or not
<DoYouKnow> I'll look it up
<Kage_Jittai> persia: that is a pastebin of yesterday's version information
<Kage_Jittai> persia: as you see .24.1 is being used quite a bit
<persia> Kage_Jittai, Hrm.  I think you have an issue with the philosophy of how we support releases.
<Kage_Jittai> persia: how ever, we dropped support for .24.1 almost a year ago
<persia> My recommendation would be to do one of the following:
<Kage_Jittai> persia: well, as being the only real GPL MMORPG with a central server, our needs are special
<persia> Hrm,
<persia> With a central server, one of my options is out :(
<ion> How about a backport to foo-backports?
<RAOF_> persia, bryce: Yeah, in what shouldn't be a terrible surprise, nvidia-71 fails to build against 2.6.30-10-generic.  I guess someone should ask nvidia if they plan to support it, and remove the packages if not.
<persia> Yeah, backports is probably the least bad option.
<Kage_Jittai> we do offer backports, even package them our self
<Kage_Jittai> but they never seems to get accepted into LTS distros
<ebroder> Kage_Jittai: If you need everybody to be running the latest software, it seems like you really want to be running your own repository so you can control that
<ion> And have the server tell people to enable -backports if they seem to be connecting with the old Ubuntu client
<Kage_Jittai> ebroder: we don't need the latest software
<persia> Kage_Jittai, We don't change packages on backporting, just recompile against backports.  Are you familar with the Ubuntu Backporting team?
<Kage_Jittai> ebroder: we support .26 .27 .28 .28.1 .29 .29.1
<Kage_Jittai> persia: no, that is most likely part of the issue
<DoYouKnow> oh, jockey == restricted driver manager
<persia> !backports
<ubottu> If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<persia> Kage_Jittai, basically, you file a bug, get a few people to test following a specific procedure, and wait a week or two (usually).
<persia> Then you can just tell your users to use backports (which gets distro authenticated and everything), to use a newer version.
<Kage_Jittai> persia: can we somehow tell the backport team about our special needs?
<bryce> wouldn't a PPA be better suited for this?
<Kage_Jittai> we have .28.1 on ppa
<Kage_Jittai> we even link to it
<Kage_Jittai> but most people seem to still use the repo
<persia> Kage_Jittai, I'm not sure I understand how your needs are special in the context of backports.  backports is often just the newest software, recompiled against the older stack.
<persia> bryce, Also PPAs have architecture limitations, etc.
<Kage_Jittai> I think part of the problem with our backports is we use guichan
<Kage_Jittai> guichan seems poorly supported in older distros
<bryce> persia, "architecture limitations"?  You mean, like no PPC?
<persia> bryce, Yes.
<Kage_Jittai> persia: well thanks for trying
<persia> Kage_Jittai, Hrm?  Did something not work, or is there some special concern?
<Kage_Jittai> persia: we have requested backports
<Kage_Jittai> which go unanswered
<persia> have you organised some testers?
<Kage_Jittai> ^_-
<Kage_Jittai> no, not really
<persia> My memory is that there need to be several positive test reports for a backport to be approved.\
<persia> And I seem to remember the backports team several times claiming that the lack of testers was the primary obstacle to getting backports done.
<persia> So, I'd advise organising some testers, and having them report on the backports bugs.
<Kage_Jittai> persia: we need more ubuntu geeks
<Kage_Jittai> on our team
<Kage_Jittai> any voluteers?
<Kage_Jittai> :P
<persia> Most people here are busy developing the next release.  You might try asking in #ubuntu, and sometimes in #ubuntu+1 (people testing the new release)
<persia> #ubuntu-backports is theoretically the right place, but I almost never see anyone there when I join.
<geofft> You could always get some of your users to test it, no?
<geofft> Put a note on your PPA page saying "please test our backport so you don't have to use the PPA any more"
<Kage_Jittai> we use a public ppa
<Kage_Jittai> !backports
<ubottu> If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<Kage_Jittai> Hardy really needs to be updated
<Kage_Jittai> persia: ok I registered for launchpad
<Kage_Jittai> how would I request the backport
<persia> Kage_Jittai, I've only done it once, and years ago, so I'm probably not the best person to ask.  Does that wiki page not explain the process?  I think it's just filing a bug.
<Kage_Jittai> it says to file the report, but doesn't say what type of details to give
<persia> Oh, the package name, the version (in karmic) to backport, and the rationale for the backport should do it.
<persia> That's where you'd explain that TMW is a MMORPG, and that you don't support .24 anymore, so need the backport so users can upgrade.
<ScottK> What testing has been done is also important.  The testing standard for a backport is that it builds, installs, and runs.
<persia> ScottK, Does that go in the initial request, or in tester comments (or both)?
<ScottK> persia: It can all be done at once if the initial requestor is also the tester.
<persia> ScottK, That makes sense, and probably makes for a better report.
<Kage_Jittai> persia: this will work https://bugs.launchpad.net/ubuntu/+source/tmw/+bug/393724 ?
<ubottu> Ubuntu bug 393724 in tmw "Please Sync tmw 0.0.24.1-1 in Hardy with tmw 0.0.29.1-1 in karmic" [Undecided,New]
<persia> You want "Please Backport"
<Kage_Jittai> updated
<persia> Kage_Jittai, Other than that, you just need the test reports, I think.
<Kage_Jittai> *sigh*
<Kage_Jittai> now the hardpart
<persia> heh.
<Kage_Jittai> persia: wanna volunteer?
<persia> Kage_Jittai, Um, no.  I have a big stack of stuff I've already promised to do.
<Kage_Jittai> I am infact on hardy, even though I use git version, how could I post test data?
<ScottK> You need to backport the actual version and packaging that's in Karmic, and build and test that.
<persia> Kage_Jittai, Well, take the karmic version, follow the instructions for backporting to produce a hady backport, and test that version.
<Kage_Jittai> persia: these instructions are where?
<persia> Kage_Jittai, On the backports wiki page, I thought.
<persia> Kage_Jittai, Under "Backport Process", most of the way down the page.
 * Kage_Jittai gives puppy dog eyes to persia
<StevenK> Kage_Jittai: They don't work on him, which is a pity.
<persia> About what?
<Kage_Jittai> persia: doing the backport ^l^
<persia> I can't do it: I'm not a member of the backports team.  And for testing, I honestly believe that if I put it in my queue, it would get done by others before I got to it.
<Kage_Jittai> anyone that is part of the backport team?
<persia> Kage_Jittai, You don't want a backport team person to look at the bug until it's tested.
<persia> You need to get the testers first.  Once the testing is complete, then you want the backpoters.
<ScottK> Because such a person would just mark it incomplete and then tell you to get it tested.
 * ScottK really goes to bed this time.
<ScottK> Good night.
<Kage_Jittai> Grrr!
<pitti> Good morning
<ajmitch> morning pitti
<siretart> slangasek: it seems to me that the package is in clear violation with http://www.ubuntu.com/community/ubuntustory/licensing and I thought the archive administrators might want to have a look and comment on that issue.
<siretart> slangasek: in other words: this is clearly non-free software in 'main'. Doesn't really anyone care?
<dholbach> good morning
<persia> siretart, is it clearly non-free?  I read it as completely undocumented, leaving significant uncertainty as to the freeness.
<siretart> persia: it comes without source, without any copyright notice and is in main. According to my reading of http://www.ubuntu.com/community/ubuntustory/licensing this is in violation of what we require for packages in 'main'
<siretart> or at least I don't know how to understand the first point here in any other way: "Must include source code. The main component has a strict and non-negotiable requirement that application software included in it must come with full source code."
<persia> OK.  That makes sense.  I seem to remember there being some debate about linux-firmware in the past (leading it to be a separate package).
<persia> While I don't remember anything about missing licenses for specific items, I do believe that it was granted a special exception to be in main because otherwise the entire stack broke.
<StevenK> So this firmware thing keeps coming up in Debian? Can we just not repeat here? Please?
<persia> That said, if there exists some part of it that's not only without source, but actually non-free, it doesn't belong there.
<siretart> persia: well, without any copyright statement, we have no basis to believe that we are allowed to redistribute it
<siretart> and moreover, "special exception to be in main because otherwise the entire stack broke" is in clear contrast to "non-negotiable requirement that application software included in it must come with full source code."
<persia> siretart, I'd argue we also have no basis to believe we cannot ship it, but yes.  Still, the solution is to investigate, rather than remove.  The cost is high.
<persia> Hrm.  That's also true.   Either my memory or that wiki page is in error.
<siretart> I'm sorry, how can we possibly believe to retain any credibility here if we simply look away here?
<persia> Um, I think you perceive my input as something other than it is.
<siretart> possibly
<persia> If you want to file a removal bug, go ahead.  I don't read that as a removal bug.
<siretart> there is already a bug, and I subscribed the archive admins to comment on it
<siretart> slangasek just unsubscribed from there
<persia> You're talking about bug #223212?
<ubottu> Launchpad bug 223212 in linux-restricted-modules-2.6.24 "Non-free files distributed without license/copyright info" [Undecided,New] https://launchpad.net/bugs/223212
<siretart> I really hope there is some misunderstanding here
<siretart> yes
<persia> Right.  I don't see a request to remove the package in the log of that bug.
<siretart> because that's pointless, we do have a place for that in ubuntu. it's called 'restricted'
<StevenK> siretart: Right, so you subscribe ubuntu-archive without even commenting in the bug that you'd like ubuntu-archive to comment on the package in question, and you're suprised when slangasek just unsubscribes ubuntu-archive?
<persia> I think you need to make clear what action should be taken.
<StevenK> Just because we're memebers of ubuntu-archive doesn't mean we can read minds.
<persia> Putting it in restricted breaks ogre-model, but it quite likely possible with some wrangling.
<siretart> StevenK: well, yes, I'm indeed a bit surprised here. when I did that, a fellow DD pointed me to the issue, but I was at work and a bit in a hurry
<siretart> StevenK: in the end, you suggest me to comment on the bug and then re-subscribe ubuntu-archive?
<StevenK> No, just saying.
<StevenK> I hate how this issue keeps coming up over and over and over and over in Debian, and I don't want the same thing to happen here.
<persia> siretart, I'd recommend you make a clear statement of what action should be taken prior to subscribing ubuntu-archive.  Moving it to restricted probably first requires some fiddling with the kernel dependencies, which would involve working with the kernel team.
<siretart> StevenK: so do I. and I thought that we had settled that in ubuntu by other means than putting heads in the sand
 * persia has had little success with soliciting ubuntu-archive comment when it comes to policy in the past
<pitti> what would be bad with moving it to restricted?
<persia> pitti, Dependencies, mostly.  Probably just needs some sorting.
<pitti> persia: indeed, tech board is more authoritative in that regard
<pitti> ubuntu-archive executes policy, we don't actually define it in that scope
<StevenK> pitti: linux-image-generic Depends on linux-firmware
<persia> pitti, Well, perhaps, although I find that generall a developer statement is sufficient for most things, if they don't break anything.
<StevenK> pitti: linux-generic is in restricted, and linux-image-generic is in main
<pitti> this should be solved by TB and checked for feasibility with kernel team IMHO
<siretart> I'm surprised that we have a different understanding of policy here. up to now I thought http://www.ubuntu.com/community/ubuntustory/licensing was pretty clear
<persia> siretart, I don't think anyone is arguing about policy.  It's just the mechanics involved.
<pitti> indeed, so then we could theoretically shuffle the metapackages
<StevenK> siretart: So, we should just purge it from the archive and break the world?
<siretart> but half of the archive team thinks this should go via TB, well, then so be it
<pitti> e. g. linux-generic could pull in the firmware, and linux-image* stop depending on it
<persia> Um, no it's that the TB makes policy.
<pitti> siretart: TB -> change of policy
<persia> This doesn't need a policy statement: there is clear policy.
<siretart> I think policy is just fine here. the implementation isn't.
<pitti> if we just have a bug (wrong component), and you don't want to change the policy, TB isn't actually needed
<StevenK> pitti: I recall rtg had a reason why he didn't do that, but I don't recall what it is.
<persia> It's just that the mess of linux and linux-meta and linux-firmware needs to be sorted to not break the world.
<siretart> StevenK: well, at some point this has been accepted into main. I think this was an error.
<pitti> StevenK: you can install Ubuntu with "free software only", but well, then you have to keep both pieces if it breaks for you
<pitti> siretart: *nod*
<pitti> the "linux" metapackage is in restricted for a similar reason
<persia> siretart, I remember when it was accepted into main.  It was done because it introduced no new components.  The questionable bits came from upstream at some point nobody can identify in prehistory.
<pitti> so, AFAICS, if we move linux-firmware dependency from linux-image-generic to linux-image, and move linux-image and l-firmware to restricted, it should be all good
<siretart> persia: you are aware that your last statement can be read in a pretty malicious way, are you?
<persia> Can we not just clean up the confusing set of metapackages?
<persia> siretart, Erm, no.  Sorry.  It wasn't intended that way.
<pitti> persia: you have another proposal?
<persia> pitti, Well, we have linux, linux-generic, linux-image-generic, linux-image, etc.
<persia> Do we really need that many?
<siretart> persia: I know that you didn't mean it. I'm just saying that this argument will be perceived outside ubuntu completely different than you mean it here
<pitti> persia: not on i386/amd64 right now, I think
<persia> siretart, Ah.  I understand.  Right.
<persia> pitti, Do you know why not?  I remember this being discussed for the past 3-4 cycles, and it's always too late in the cycle to fix it, or there's some other reason.
<persia> But just moving the dependency should be sensible, and allow migration to restricted.
<slangasek> siretart: I unsubscribed the archive admins because all you did was subscribe us, without saying what you wanted.  And if you want it /removed/, then that would appear to be an inter-developer dispute, which I don't intend to mediate with my archive admin hat, to be sure
<siretart> that sounds quite right to me
<pitti> persia: well, re-thinking about it, we still have several flavours (-i386, -generic, -server, -rt, etc.), so we probably still need them all
<slangasek> for my part, I'm not convinced moving it to restricted is the correct course of action
<siretart> slangasek: okay, sorry for that, I was under the wrong impression that the bug was already clear. now I see that it is not
<persia> pitti, I guess the one I don't understand the most is the distinction between "linux" and "linux-image".  They seem to differ by a single transposed word.
<siretart> slangasek: can you please elaborate? How can we keep it in main without violating http://www.ubuntu.com/community/ubuntustory/licensing?
<persia> slangasek, Or were you saying that removal may be the more appropriate action?
<superm1> persia, before karmic, having linux and linux-image made sense because linux pulled in LRM as well as linux-image
<superm1> now for karmic since there is no more LRM, the linux meta package itself makes less sense
<slangasek> siretart: note that this page says "application software", which firmware are not
<persia> superm1, No, l-r-m was always pulled by linux-image-flavour, because l-r-m can be flavour-specific.
<persia> (or maybe it was linux-flavour)
<pitti> persia: AFAIUI, "linux-image" -> the actual kernel, like bzimage and modules; "linux" -> everything around it, such as restricted-modules, firmware, etc.
<slangasek> we do allow non-applications in main that don't permit free modification; e.g., RFCs
<superm1> persia, i'm looking at apt-cache depends linux on jaunty right now. the only two depends are linux-image and linux-restricted-modules
<superm1> where linux-restricted-modules is another metapackage
<persia> superm1, Hrm.  Maybe I'm confused.  I filed a bug about this a long time ago, was told it couldn't be fixed easily, and forgot some of the detals.
<superm1> persia, well now it really should be much more easily fixable with LRM gone, so i would recommend reviving said bug
<slangasek> pitti: the split between linux-image and linux is "depends on restricted" and "doesn't depend on restricted"
<slangasek> linux-image at various points in its history depends on linux-ubuntu-modules, too
<siretart> maybe I'm too much from the embedded world, but for me "application software" does not necessarily imply to be software on the same processor the linux kernel runs on. anyway. the next point is that we require permission to redistribute and modify it. are you positive that we have that permission? the bug is about these missing copyright statements
<persia> superm1, Perhaps.  Someone needs to sit down and untangle the mess.  It might be me, and it might be someone else.
<YokoZar> hey guys, apt-get install branding-ubuntu and then open solitaire, tell me what you think
<slangasek> siretart: no, I'm not positive; I agree that it's a bug, I just don't see that it's a bug that the archive admins can resolve, since our only available option is "pull it and make it uninstallable"
<persia> siretart, There are two issues being conflated.  1) Should linux-firmware be in main and 2) does the current licensing of linux-firmware meet the requirements (even for firmware as documented at http://www.ubuntu.com/community/ubuntustory/licensing)
<siretart> persia: perhaps you're right and these two issues should be discussed seperately
<persia> siretart, There's a separate section for firmware further down on the page.  I'm not sure that the bug raised doesn't even break that guideline, although it needs investigation.
<pitti> right, so 1) is the easy part here; (2), figuring out their licenses, is the real work here
<persia> Well, 1) is really making a call as to whether we consider the contents of the package "firmware" or "application software".  In the first case, main is fine (as I read the page).  In the second case, it belongs in restricted.  Probably easier to put it in restricted to avoid the argument, but needs confirmation from the kernel team.
<persia> In terms of undocumented licenses, I think we ought follow the practices we've followed in the past: when we encounter something where licensing is unclear (take a look at the copyright files for a bunch of stuff in Priority:required sometime), we try to fix them or work around any discovered issues.
<slangasek> moving linux-firmware to restricted also breaks the ogre model in that it builds two udebs that are embedded in the d-i initramfs
<slangasek> (nic-firmware, scsi-firmware)
<persia> Aha.  That's the part that breaks.  Thanks for the clarification.
<pitti> superm1: I answered to the jockey-text merge request, BTW
<siretart> ah, okay, this makes things more clear. but I need to leave now, will be back later. cu
<cjwatson> siretart: that page is absolutely explicit about whether firmware is application software; it says that it is not.
<cjwatson> "Ubuntu contains licensed and copyrighted works that are not application software. For example, the default Ubuntu installation includes documentation, images, sounds, video clips and firmware."
<cjwatson> (I've followed up to the bug separately)
<cjwatson> pgraner: bug 223212 needs attention from your team, I think
<ubottu> Launchpad bug 223212 in linux-restricted-modules-2.6.24 "Non-free files distributed without license/copyright info" [Undecided,New] https://launchpad.net/bugs/223212
<dholbach> seb128: can you please change the Maintainer from pidgin to ubuntu-devel-discuss instead of ubuntu-devel with one of the next uploads?
<dholbach> tkamppeter: ^ same goes for some of the printer related packages
<dholbach> update-maintainer of the ubuntu-dev-tools package will take care of it for you
<dholbach> (mails get into the ubuntu-devel@ moderation queue because of it)
<seb128> dholbach, why?
<seb128> which mails?
<dholbach> archive@ubuntu.com mails
<seb128> an upload should not spam any mailing list
<vise> if my software-0.0.2 is open source till date, can i now make it closed source at software-0.0.3 version?
<vise> it has lgpl currently...
<dholbach> seb128: they do get into the moderation queue though
<seb128> dholbach, I'm a bit concerned that an upload spam a mailing list, would that mean that emails would land on ubuntu-devel-discuss when I upload pidgin?
<cjwatson> they manifestly don't ...
<dholbach> seb128: I'm not moderator of that list, so I don't know - maybe archive@ubuntu.com is explicitly blocked there
<seb128> well, if they go in the moderation queue that's because they try to go there, if I change the email for an open list one what would block the email?
<cjwatson> vise: I don't think you should really be expecting free software developers to give you advice on taking your program away from us
<cjwatson> to be perfectly honest :)
<seb128> dholbach, what do those emails say?
<dholbach> seb128: it's the usual archive@ubuntu.com emails you get on every upload, plus the "rejected"ones
<dholbach> seb128: I just noticed pidgin and a few printing related packages
<vise> cjwatson: I dont want to either.. But please.. :)
<dholbach> also I'd like to get the merge proposal mails for ~ubuntu-core-dev from that list
<dholbach> but I don't know what to do there
<Hobbsee> dholbach: er, what?
<cjwatson> vise: it's my understanding that you can't withdraw the licence already given for software-0.0.2, so people can continue to modify and distribute that; furthermore, if you've incorporated code from anyone else under the LGPL then you don't have the right to make that closed-source. For anything else, I suggest asking your lawwyer
<cjwatson> lawyer
<dholbach> Hobbsee: what what? :)
<seb128> dholbach, I'm not sure to understand what is going on but I will change the email address anyway, still seems weird that the lists are mailed on upload
<Hobbsee> seb128: they really aren't.
<dholbach> Hobbsee: aren't what?
<vise> cjwatson: tyvm
<cjwatson> dholbach: I suspect we probably ought to add an ubuntu-reviews mailing list
<Hobbsee> dholbach: the lists (u-d, u-d-d) aren't mailed on upload
<dholbach> cjwatson: that sounds sensible, we could route the sponsoring there too
<Hobbsee> dholbach: did you want the merge proposals on u-d, or not?  I'm unclear with what you're saying thee
<dholbach> Hobbsee: let me do a pidgin upload that is going to be rejected - just a sec
<dholbach> Hobbsee: I'd prefer not having them
<dholbach> on ubuntu-devel@
<Hobbsee> right
<cjwatson> they were only ever temporarily on ubuntu-devel@, until they got past the point when they were manageable there
<dholbach> ok pidgin right now has Maintainer: Ubuntu Core Developers <ubuntu-devel@lists.ubuntu.com> - what the ubuntu-devel@ moderation queue in a few minutes
<dholbach> now
<Hobbsee> cjwatson: so we'e dopping the erge requests?  so far, iv'e just been skippign them
<Hobbsee> ah, that did dop in the moderation queue
<pitti> dholbach: (not sure whether it matters, but theh usual maintainer is u-devel-discuss@)
<Hobbsee> as fo how changing the addess to u-d-d will help mattes at all, i don't know
<cjwatson> Hobbsee: they're generally supposed to be let through for now, AIUI, but we probably ought to move them to a separate list soon
<dholbach> pitti: yes, that's what I'm saying - a few packages have ubuntu-devel@ (which is a mistake)
 * cjwatson screws Hobbsee's 'r' key back on
<StevenK> Hehe
<Hobbsee> cjwatson: right.  and thanks - but you'll need to do that fo a few othe keys too
<Laney> why don't we see mails for all packages that get uploaded? or are they always rejected by u-d-d?
<cjwatson> I *assume* that the u-d-d list configuration bins them
<Hobbsee> (bing on my netbook!)
<dholbach> I guess that in the configuration of u-d-d there's either a handler that drops them or the email address blocked completely somewhere else
<cjwatson> would probably be easy enough to do that in the u-d configuration too, but in this case it's fortuitously letting us know of a mistake in Maintainer ;-)
<dholbach> evand would be able to tell
<dholbach> cjwatson: I'm happy to pester people :-)
 * Hobbsee nicks StevenK's USB keyboard, and can type again.  woot!
<tkamppeter> dholbach, which printing-related packages spam ubuntu-devel@? I did not find any?
<dholbach> tkamppeter: I'll let you know with the next ones I encounter, nevermind for now :)
<dholbach> tkamppeter: I take it back
<dholbach> here's the list of packages that still have ubuntu-devel@lists.ubuntu.com:
<dholbach>  alcovebook-sgml
<dholbach>  ant
<dholbach>  automake1.9-nonfree
<dholbach>  intltool-debian
<dholbach>  kernel-wedge
<dholbach>  keymapper
<dholbach>  kmplayer
<dholbach>  libgnucrypto-java
<dholbach>  libio-string-perl
<dholbach>  libnet-ip-perl
<dholbach>  libparse-debianchangelog-perl
<dholbach>  libtext-format-perl
<dholbach>  libxfontcache
<dholbach>  libxml-namespacesupport-perl
<dholbach>  libxvmc
<dholbach>  pan
<dholbach>  pidgin
<dholbach>  pwlib
<pitti> pastebin FTW!
<dholbach>  pythondialog
<dholbach>  python-unit
<dholbach>  sockstat
<dholbach>  ttf-bitstream-vera
<dholbach>  ttf-bpg-georgian-fonts
<dholbach>  witalian
<dholbach>  x11proto-print
<dholbach>  xcursor-themes
<ogra> oh my
<pitti> dholbach: i. e. pretty much the ones that nobody touched in years, and thus shouldn't cause mail spam
<pitti> well, them, and pidgin
<tseliot> cjwatson: I installed my script for hardware detection to /lib/debian-installer-startup.d/ (from a udeb which depends on dmidecode-udeb) and bootstrap.log shows that dmidecode was installed. Is there some other log I should read to investigate the failure of my script?
<tseliot> cjwatson: my script: https://pastebin.canonical.com/19132/
<cjwatson> bootstrap.log is entirely irrelevant - look at the installer syslog
<cjwatson> if you've completed installation, it's in /var/log/installer/syslog
<cjwatson> for something that short, though, maybe just run it by hand in the installer environment and see if it works :)
<cjwatson> tseliot: oh, you'll need to actively halt or something rather than just exiting 1. debian-installer-startup ignores exit codes
<tseliot> cjwatson: oh, how do I halt the installer then?
 * ogra would also check for $RET != 0 and drop two lines :)
<tseliot> ogra: yes, that would help debugging
<cjwatson> tseliot: 'halt'
<tseliot> cjwatson: there's no trace of dmidecode in /var/log/installer/syslog: https://pastebin.canonical.com/19133/
<cjwatson> tseliot: then it probably didn't go wrong
<tseliot> shouldn't it be pulled automatically as a dependency?
<cjwatson> sure, but why would that be in the runtime log?
<cjwatson> are you rebuilding d-i to include this?
<cjwatson> debian-installer-startup.d is run before any runtime component installation happens
<tseliot> we set up  a new project to do it
<cjwatson> so you need to rebuild d-i to include any scripts there
<cjwatson> if you want to investigate whether dependencies are pulled in, you should check the *build* log
<cjwatson> also, you could do this in a much more lightweight way without dmidecode - just look in /sys/class/dmi/id/product_name
<tseliot> ok, let me check
<tseliot> cjwatson: yes, dmidecode was installed
<tseliot> and thanks for the tip about /sys/class/dmi/id/product_name
<A|i> is this the channel for ubuntu debian package maintainers?
<ogra_> A|i, the /topic should say it all
<A|i> ogra_, which channel is for package maintainers?
<ogra_> i wuld go to -motu for a start
<ogra_> *would
<A|i> i dont want to pack, i want to report a problem
<ogra_> for a specific package ?
<cjwatson> you should file a bug, then
<A|i> yes
<ogra_> ubuntu-bug -p <packagename>
<A|i> i know, but i was wondering if the package maintainers are around
<ogra_> they are usually subscribed to all bugmail
<A|i> ok thanks
<pgraner> cjwatson: that bug is on my radar as part of the license clean up with legal.
<cjwatson> thanks
<Pistos> Hello, is anyone around who is even remotely connected with Ruby on Ubuntu?  I think I have found a bug in the Ubuntu build of Ruby 1.9, because it doesn't appear on Debian or Gentoo, or when Ruby 1.9 is built from source on Ubuntu.
<cjwatson> ha!
 * cjwatson nails bug 185878
<ubottu> Launchpad bug 185878 in grub "GRUB installation fails if installing to non-ext3 partition" [High,Triaged] https://launchpad.net/bugs/185878
 * ogra applauds
<cjwatson> pain, suffering, and more pain
<StevenK> Duh, it involves GRUB
<StevenK> Oh, even better, it looks to be a race condition.
<cjwatson> I'm not actually 100% sure it's racy; it's a cache coherency bug
<StevenK> Disk cache coherency?
<cjwatson> writing to a partition device when you still have the disk device open does not guarantee that you will get new data back when you read from the disk device
<cjwatson> ioctl(BLKFLSBUF) fixes
<DoYouKnow> is that something that appeared today?
<directhex> which file lists packages in main (with hopefully justification)?
<StevenK> directhex: Packages in main have to be held there by being seeded or a build-dependancy or so
<DoYouKnow> I thought I installed to ext4, although I'm not sure about the boot partition
<DoYouKnow> and grub works fine
<cjwatson> DoYouKnow: the bug description overstates the case a bit
<cjwatson> DoYouKnow: see my last comment for a more accurate description of what's affected
<directhex> StevenK, i'm trying to work out why mono-tools is in main. i suspect monodoc-browser is to blame
<StevenK> directhex: The germinate output should tell you that.
 * StevenK tries to remember where it lives.
<cjwatson> http://people.ubuntu.com/~ubuntu-archive/germinate-output/
<StevenK> Hmmm. unr.karmic isn't in that list.
<cjwatson> feel free to edit ~ubuntu-archive/bin/update-germinate on rookery to add it
<StevenK> cjwatson: I was going to ask for a hint, thanks. I'll fix it tomorrow.
<directhex> hm
<directhex> as far as i understand it... supported-development.seed lists monodoc-webkit-manual
<directhex> meaning the documentation browser gets pulled in, meaning i need to merge mono-tools to disable the asp.net documentation browser
<tseliot> cjwatson: what's your opinion on bug 172830?
<ubottu> Launchpad bug 172830 in partman-auto "Too much of hard disk space (5% blocks) is reserved for big partitions (e.g. /home)" [Undecided,New] https://launchpad.net/bugs/172830
<cjwatson> tseliot: it's a bikeshed bug and not easily fixed in a way that will satisfy everyone; if you have a problem with the current value I suggest using preseeding facilities to change it
<cjwatson> "reserved_for_root{ 1% }" or whatever in a recipe
<mattn__> installing the package diff-ext on 9.04 leads to nautilus crashes when right clicking a file
<mattn__> uninstalling it again solved the issue
<cjwatson> tseliot: right now partman does not have a way to dynamically scale the percentage depending on the size of the disk, and I think there are still plenty of situations where you might be creating a relatively small filesystem
<Chipzz> cjwatson: not wanting to start a flamewar, but what arguments would there be in favor of it for large partitions? or is it purely a technical issue like you said?
<cjwatson> read the bug.
<cjwatson> the arguments in favour of larger percentages are for *small* partitions, not large partitions.
<cjwatson> hence a need for some kind of inverse scaling.
<Chipzz> I did, but you said it was a bikeshed bug (implying that there are arguments both in favor and against of it)
<tseliot> cjwatson: ok, I see your point
<cjwatson> Chipzz: whatever
<Chipzz> cjwatson: idd whatever, was just curious anyway :)
<cjwatson> Chipzz: if implemented crudely (i.e. just changing the percentage), it's a bikeshed bug because I'd just get a different bug asking to put it back up again.
<cjwatson> Chipzz: avoiding the bikeshed requires more sophisticated code
<cjwatson> I'm sorry I didn't spell that out in detail, I was rushing to get ready for a meeting
<Chipzz> get ready for your meeting :)
<Chipzz> no need to get late to satisfy my curiousity ;)
<cjwatson> (and sorry, I didn't mean to be terse)
<cjwatson> grub has put me in a foul mood
<Chipzz> cjwatson: no offense taken - now go get ready! :)
<Chipzz> tseliot: I wonder in what context you were asking about this bug; wouldn't that bug only affect alternate and server installs?
<Chipzz> or does it affect ubiquity too?
<tseliot> Chipzz: OEM stuff
<tseliot> and yes, alternate installs
<tseliot> well, what we use for OEM
<Chipzz> tseliot: I'ld say that OEMs should have enough clue to preseed an appropriate value?
<tseliot> Chipzz: yep
<Chipzz> (appropriate for the model on which it's installed)
<Chipzz> so largely irrelevant IMO?
<Chipzz> (well for your use case anyway)
<cjwatson> for the record ubiquity uses partman-auto in more or less the same way that d-i does
<cjwatson> certainly recipes are applied identically
<tseliot> Chipzz: communication is always useful ;)
<Chipzz> tseliot: anyway just my 2 cents :)
<Pistos> Okay, FWIW, I filed a full report: https://bugs.launchpad.net/ubuntu/+source/ruby1.9/+bug/393888
<ubottu> Ubuntu bug 393888 in ruby1.9 "Ruby 1.9.0 curses Alt-key handling broken" [Undecided,New]
<andrew_sayers> Hi evand, I just replied to your message about the migration assistant.  We can talk in here if you prefer.
<evand> andrew_sayers: email is probably best at the moment as it will give me a chance to mull over what you've sent.  I'll take a look at it shortly, just have a few things I need to sort first.
<andrew_sayers> evand: sure.
<pitti> TheMuso, dtchen: do you plan to package pulse 0.9.16test1? (https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009-June/004256.html)
<pitti> (lots of fixes, and de-hal-ification)
<seb128> pitti, speaking about pulseaudio do you have sound on your laptop and karmic?
<pitti> seb128: last tested yesterday, lemme check again
<pitti> seb128: hm, indeed it's just silent
<seb128> same here
<pitti> that worked yesterday
<pitti> and it's not just the mixer (which tends to be silent by default nowadays)
<seb128> lucky you I don't have sound on my laptop for several days
<seb128> I've tried to tweak all the mixer settings with no luck
<pitti> killall pulse doesn't work either, though, so it seems to be an alsa issue
<pitti> oh, hang on
<pitti> -EPERM?
<pitti> getfacl /dev/snd/pcmC0D0c -> FAIL
<pitti> seb128: investigating, thanks for poking
<seb128> where?
<seb128> not here
<seb128> but I didn't upgrade my laptop today
<seb128> I was trying to stay away from the libudev issue
<pitti> seb128: nothing to do with gudev
<pitti> seb128: are you not in the "audio" group?
<seb128> thanks for looking ;-)
<pitti> killall pulseaudio; sudo aplay /usr/share/sounds/card_shuffle.wav
<pitti> ^ please verify that this works
<mdz> cjwatson: Keybuk: which of you chaired the last TB?
<mdz> the other of you should chair the next one :-)
<pitti> seb128: and that aplay /usr/share/sounds/card_shuffle.wav doesn't
<seb128> pitti, I'm in the audio group (the gudev breakage is why I didn't dist-upgrade my laptop today)
<seb128> pitti, why do I need to killall pulseaudio before trying?
<ogra> mdz, colin did last
<Keybuk> mdz: I think it's my turn next
<seb128> pitti, aplay and paplay doesn't play any sound
<pitti> seb128: eliminating potential breakage, and avoid running pulse as root
<seb128> using sudo or not
<pitti> seb128: sudo aplay doesn't work either? it works here
<cjwatson> mdz: yes, I did
<seb128> pitti, no but my sound is broken for a while not only since today so we probably have different isues
<seb128> issues
<pitti> seb128: getfacl /dev/snd/controlC0 for you?
<seb128> yes
 * directhex fluffles Keybuk, apologises for him needing to waste his time on position statements
<ogra> directhex, dont be apologetic ...
<ogra> its not your fault
<seb128_> pitti, no error
<pitti> seb128: ah, then you still have udev-extras
<pitti> seb128: I just figured out what broke it
<seb128> pitti, no I don't
<seb128> that has been uninstalled yesterday
<pitti> ah, then you don't get ACLs either
<seb128> what do you mean?
<seb128> acl doesn't return an error
<seb128> group is audio and has rw-
<pitti> right, but "seb128" certainly doesn't have an ACL
<seb128> no, but the audio group should be enough no?
<pitti> not for me
<pitti> I'm not in audio
<seb128> I'm in audio
<pitti> ah, then this isn't what it breaks for you
<seb128> no, as said I've no sound for a while there, not until since yesterday
<dholbach> Can I interest somebody in giving a Packaging Training session at 02nd July, 06:00 UTC? https://wiki.ubuntu.com/Packaging/Training has lots of ideas for sessions
<Pici> Is anyone aware what the plans for Firefox 3.5 in Jaunty are? I'd like to have an answer to give to the many people that are asking in the other support channels.
<seb128> what plans?
<seb128> it's in jaunty universe
<Pici> oh, sorry, I thought it was in main. I misread.
 * Pici pops over to -motu
<seb128> you can ask your questions there but that is not a clear question, do you want to get a bug fixed there or something?
<Pici> seb128: It appears that FF3.5 was released today, we're getting a lot of 'when is this update coming?' questions.  I know its a separate package, but its still the beta version in Jaunty.
<seb128> asac, ^ is there any ppa or something with an updated firefox-3.5 for jaunty?
<asac> seb128: yes. ~ubuntu-mozilla-daily has the RC (its not daily atm)
<asac> seb128: once 3.5 final gets out we will update jaunty one
<asac> Pici: ^
<seb128> asac, somebody is claiming that 3.5 has been flagged stable today
<asac> so yeah. release is today.
<asac> seb128: yes. wasnt sure they woke up yet ;)
<Pici> asac: Thanks, thats all I needed to know :)
<asac> Pici: will take a day or two because we need to do some basic QA. if users asks tell them to enable ~ubuntu-mozilla-security
<seb128> users are crack addicts, they ask for updates the second it's announced
<asac> thats where this build will end up first
<asac> Pici: and we always love to have more security staging testers ;)
<Pici> seb128: believe me, I know. If I asked them whats so great about $newversion, most of the time they aren't able to answer.
<seb128> "it's new!" ;-)
<asac> Pici: so the crack addicts should use -daily ppa anyway ... the others should go for -security. thanks!
<Pici> asac: sorry, just need a little clarification: Will the 3.5 packages be updated in Universe or will they only be in the PPA.
<asac> Pici:  ~ubuntu-mozilla-security is the staging area for real archive ... it will first go there and then to universe
<Pici> asac: Okay, thanks.
<brettalton1> With SJR announcing that mono/C# is here to stay in the Ubuntu desktop, does this mean there will be discussion on Rhythmbox vs Banshee for Karmic? Or is that probably a LTS+1 thing? (aka 10.10)
<dholbach> bryce, pitti: you know about the hal/xserver-xorg overwrite problem?
<dholbach> /usr/lib/hal/debian-setup-keyboard
<seb128> brettalton1, rhythmbox and banshee have already been discussed at uds
<seb128> brettalton1, https://blueprints.launchpad.net/ubuntu/+spec/desktop-karmic-default-media-player-choice
<brettalton1> seb128: exactly what I was looking for, thank you.
<pitti> dholbach: I don't
<seb128> dholbach, ask tjaalton since the did the upload maybe?
<dholbach> http://paste.ubuntu.com/20038
<dholbach> http://paste.ubuntu.com/207038
<dholbach> sorry
<pitti> tjaalton, bryce, dholbach: ah, I remember that Debian ships that file in xorg, while we ship it in hal
<pitti> I don't mind removing it from hal, but we need the conflicts/replaces on xorg anyway
<dholbach> sounds like a merge oversight?
<tjaalton> oh yeah
<tjaalton> pitti: will you drop it from hal? I'll add the C/R to xserver-xorg..
<pitti> tjaalton: it's a little weird to have the .fdi in hal (which calls it) and the script in xorg
<pitti> tjaalton: shouldn't the fdi be moved as well?
<tjaalton> pitti: let me see where that is
<pitti> /usr/share/hal/fdi/policy/10osvendor/10-x11-keymap.fdi I mean
<tjaalton> it might be shipped by evdev in debian
<tjaalton> no, it's in xorg
<tjaalton> it's called debian-x11-keymap.fdi from now on :)
<pitti> tjaalton: so I should drop that as well, to avoid having two
<slytherin> cjwatson: Can you please point me to the powerpc chroot you had copied from buildd? I lost the link.
<tjaalton> pitti: yes
<cjwatson> slytherin: http://people.ubuntu.com/~cjwatson/tmp/karmic-powerpc.tar.bz2
<tjaalton> pitti: sorry for the short notice, I had forgot about this completely
<EvanCarroll> Pici: Dev's are crack addicts too, I want my firefox to not consume my whole PC, though I actually don't believe 3.5 will make a damn difference
<slytherin> cjwatson: ahh, my mistake I overlooked it while checking files in tmp.
<EvanCarroll> 3.5 seems like groundless chrome counter-hype
<superm1> pitti, yeah I saw thanks.  i'll let you know as soon as I get a chance to make the recommended changes
<EvanCarroll> 3.0 was supposed to be significantly faster than 2.5, and I didn't see a noticeable difference in that either.
<EvanCarroll> and wtf is the firefox launchpage covered with dolphins?
<EvanCarroll> mysql invasion?!?! surely it will be fastar!
<pitti> tjaalton: ok, will be dropped from hal_0.5.12+git20090626-0ubuntu2_source.changes; testing and uploading
<tjaalton> pitti: so I'll add C/R hal (<= 0.5.12+git20090626-0ubuntu1) to xserver-xorg
<pitti> tjaalton: *nod*
<tjaalton> oh man, mesa build makes my laptop boil
<bryce> heya tjaalton and pitti; got the hal stuff sorted?
<tjaalton> bryce: yeah, pushing right now
<tjaalton> next to fix the mesa ftbfs
<c_korn> why does the package text say that it is scilab-5.1-0ubuntu2 but it is scilab-5.1.1-6 (see the files at the right)? http://packages.ubuntu.com/karmic/scilab
<pitti> tjaalton: uploaded
<tjaalton> pitti: likewise :)
<infinity> c_korn: Because the binaries are the old version, the source is the new version (it failed to build on all arches except sparc...)
<infinity> c_korn: https://edge.launchpad.net/ubuntu/karmic/+source/scilab/5.1.1-6 might be a friendlier view of that situation.
<cjwatson> or https://launchpad.net/ubuntu/+source/scilab for another level up; launchpad.net/ubuntu/+source/SOURCEPACKAGENAME is generally a good place to start in LP
<infinity> cjwatson: Well, yes, but I was trying to point on the build failures. :)
<c_korn> keytool error: java.security.NoSuchAlgorithmException: SHA384withECDSA Signature not available
<c_korn>   error adding mozilla/COMODO_ECC_Certification_Authority.crt
<cjwatson> right
<c_korn> this is the error
<c_korn> this is not an issue related to scilab
<cjwatson> there's a sync request for that, which I'll process now
<cjwatson> (bug 393830; bug 392104)
<ubottu> Launchpad bug 393830 in ca-certificates-java "sync request (unstable -> main)" [Undecided,New] https://launchpad.net/bugs/393830
<ubottu> Launchpad bug 392104 in ca-certificates-java "[Karmic] Update to ca-certificates 20090624 prevents ca-certificates-java from installing" [High,Fix released] https://launchpad.net/bugs/392104
<cjwatson> hmm, already processed
<cjwatson> I'll retry scilab then
<c_korn> cjwatson: ok, thanks
<cjwatson> I'm not retrying ports architectures since openjdk seems to be uninstallable there
<pitti> Keybuk: heh -- sed -i 's/srcdir/builddir/g' gtk-doc.make fixes it. completely. \o/
<Keybuk> pitti: if we could get that upstream, that'd be awesome
<Keybuk> (gtk-doc upstream, that is)
<pitti> Keybuk: right, I'll file it to them
<pitti> Keybuk: http://bazaar.launchpad.net/%7Eubuntu-core-dev/udev/ubuntu/revision/2480
<pitti> Keybuk: so, it's "debcheckout", "debian/rules prep", and then dpkg-buildpackage just works
<pgraner> bryce: ping
<bryce> yep
<cjwatson> kirkland: dunno if you noticed, by the way, but I fixed w3mman to handle formatting characters correctly. Is it easy to upgrade ubuntu-manpage-repository to karmic's w3mman, or would it be easier to work around it by setting the same environment variable in your code that calls w3mman?
<pgraner> bryce: do you have any docs on setting up KMS with nouveau?
<bryce> pgraner, not as such, but there's a ppa
<bryce> https://edge.launchpad.net/~xorg-edgers/+archive/nouveau
<bryce> some docs on that page
<pgraner> brianchidester: yea I saw that, anything special after install ?
<pgraner> bryce: ^^^^^^^^^^^
<pitti> Keybuk: which stuff did you deliberately not install? I see the gudev gtk-doc (should go to libgudev-dev), ConsoleKit helper (absence breaks everything), udev.pc (should be in libudev-dev), README.keymap.txt (should be in udev)
<bryce> pgraner, I've not actually been able to get it to successfully do kms on -nouveau, so don't know what more needs done, but something does
<bryce> however I've not tried with raof's latest stuff
<pgraner> bryce: ok, I'll try the ppa and see what I can get going. My desktop is a Nvidia and would like to see if I can get it working
<bryce> pgraner, one thing I've noticed is that support varies widely from chip family to chip family
<Keybuk> pitti: it may have gone now
<bryce> G70 cards *should* work the best; earlier families maybe not so much
<pitti> Keybuk: udev.pc by and large just has udevdir=/lib/udev and the version; do you think we should have that in udev itself? or ignore?
<pgraner> bryce: I have a: nVidia Corporation GeForce 8600 GT
<Keybuk> pitti: we should include it I guess
<Keybuk> or maybe in libudev-dev
<bryce> pgraner, yeah G80 cards like that should be really well supported (I've one as well)
<pgraner> Keybuk: any idea of what this means when doing an upgrade in Karmic: E: /var/cache/apt/archives/xserver-xorg_1%3a7.4+3ubuntu1_amd64.deb: trying to overwrite `/usr/lib/hal/debian-setup-keyboard', which is also in package hal
<cjwatson> means that somebody forgot the mandatory Replaces field when moving a file between packages
<pgraner> cjwatson: what package should the bug go against?
<seb128> it has been fixed but the update is not published yet
<seb128> nowhere, it's fixed already
<cjwatson> xserver-xorg but it was already discussed above
<pgraner> seb128: ok, then I'll just wait
<bryce> pgraner, in fact we just put in a fix for that hal/xorg conflict
<pgraner> bryce: thanks...
<pitti> Keybuk: ok, I think udev package is back in working order now, and building from tree is back to sanity
<Keybuk> pitti: cool, please upload ;)
<pitti> done
<pitti> I want my sound and DRI acceleration back :)
<Keybuk> :)
<Keybuk> there's some bugs about that
<djsiegel1> Keybuk: do you know the name of the package that lets me edit the wiki in my own out-of-browser editor?
<cjwatson> editmoin
<cjwatson> (I haven't used it in a while, don't know if it works at the moment)
<elmo> it's all text (firefox extension) is also useful for that, FWIW
 * cjwatson gives up on trying to make bughelper work (I assume it's been broken by some LP UI change again) and writes a 15-line launchpadlib script instead
<cjwatson> is anyone working on a launchpadlib-ified version of bughelper?
<Ampelbein> cjwatson: sort of. i rewrote bugnumbers to use lplib.
<Ampelbein> cjwatson: i thought of rewriting bughelper, too.
<cjwatson> as it happens I generally only use it for quick searches and it looks as if lplib is easy enough to use for that that I personally don't really need a fully-fledged tool, but others might
<Ampelbein> cjwatson: I will see what I can do.
<cjwatson> Ampelbein: cool :)
<pitti> Keybuk: indeed, I closed bug 393591
<ubottu> Launchpad bug 393591 in udev "Regression: Sound stops working after udev upgrade from 142 to 143 in Karmic" [Undecided,Fix released] https://launchpad.net/bugs/393591
<cody-somerville> Is it safe to upgrade X now? Someone said earlier that it completely busts karmic up.
 * ogra_ didnt have probs with yesterdays upgrade
 * cody-somerville takes a deep breath and upgrades.
<cody-somerville> odd
<cody-somerville> update-manager refuses
<cody-somerville> I click install updates and a popup window says reading state information while the main window greys out before disappearing and the main window ungreying.
<ogra_> weird
<cody-somerville> I'll assume its a sign not to upgrade
<shaya> is there a reason that firefox-3.5 (yes, I know its rc2, not today's released) doesn't have HTML5 video support?
<kirkland> hmm, /dev/null permed 600 in karmic makes many things very unhappy
<slangasek> a /dev/null permed 600 anywhere makes things very unhappy
<soren> kirkland: Is it at least still a device node?
<Chipzz> /dev/null being a file instead of a device node makes things very unhappy :P
<soren> kirkland: I once saw it replaced with a (very, very big) file, because someone accidentally removed it, and kept piping things to it as root.
<Chipzz> soren: I had that happen once
<Chipzz> soren: nfs server didn't come up after a reboot (the box was the file server for our web sites, and had been up for ages)
<Chipzz> no idea what caused that
<c_korn> hm ,http://pastebin.com/d78ca1ca9
<kirkland> soren: was definitely a device file, might have been fixed in this last update
<kirkland> slangasek: okay, i got my /dev/null back
<kirkland> intel video is still hosed though
 * kirkland reminds himself to never update while away from home
<tormod> just as a word of warning, the last xorg (?) update might cause broken X
<tormod> gdm 2.20.10-0ubuntu4 will fix X again
<pitti> cjwatson: nice, upstream merged your unionfs-fuse patch
<cjwatson> good
<pitti> cjwatson: I'm currently sponsoring a new version into Debian which should fix the hardlink bug 386728, so we should sync this
<ubottu> Launchpad bug 386728 in unionfs-fuse "package tzdata 2009h-1 failed to install/upgrade: error creating hard link `./usr/share/zoneinfo/posix/Europe/Nicosia': No such file or directory" [Undecided,New] https://launchpad.net/bugs/386728
<cjwatson> sounds fair to me
<pitti> what's wrong with the buildds?
<pitti> they are all "private build" and disabled
<pitti> infinity: ^
<pitti> asking because the current gdm upload is super-urgent
<maxb> Is anyone using a non-US keyboard, and so in a position to confirm that the xkb callout seems to have broken (once you've fixed the gdm conffiles)
<seb128_> maxb, what gdm conffiles?
<maxb> the ones referencing /usr/X11R6, which are fixed in above-mentioned super-urgent upload
<seb128_> maxb, ah, that's not a conffile issue, that's a configuration issue
<maxb> conffile/configuration whatever
<maxb> Anyway, my point is that the callout seems broken to me, once I've fought past the already-reported breakage
<infinity> pitti: They really are building private builds.
<infinity> pitti: (security builds)
<infinity> pitti: So, it's a bit of a "sucks to be you" for now. :/
<pitti> ok, thanks
<pitti> well, *shrug*, it's karmic :)
<seb128_> infinity, suck to be users running karmic rather ;-)
<maxb> Users running karmic should be entirely capable of self-deducing the proper fix :-)
<maxb> pitti: Once the gdm stuff is out of the way, I think we have a re-regression of the "callout not being added" bug you debugged for me earlier in karmic
 * maxb reads irc logs of that time
<pitti> maxb: callout?
<pitti> ugh, and the ppa buildds are asac'ed
<seb128> pitti, great the gdm update doesn't build
<pitti> *sigh*, no builds for me
<seb128> Can't start Hardware abstraction layer - sysfs not mounted on /sys
<seb128> Setting up xserver-xorg (1:7.4+3ubuntu2) ...
<seb128> invoke-rc.d: initscript hal, action "restart" failed.
<pitti> hal??
<pitti> nothing should b-dep on hal
<seb128> gdm build-depends on xorg-server which depends on hal
<pitti> eww
<pitti> tjaalton: can we please stop xorg-server from depending on hal?
<maxb> LP 375618
<ubottu> Launchpad bug 375618 in hal "does not pass xkb* settings to xorg server" [High,Fix released] https://launchpad.net/bugs/375618
<pitti> -evdev should/could, but nothing else surely?
<pitti> maxb: I thought I re-fixed that some days ago
<seb128> pitti, is that required for the fdi which moved there?
<maxb> It seems to have re-broken just now in today's xorg/hal update
<pitti> seb128: not really
<pitti> xorg just needs to ship these two files
<pitti> nothing else
<seb128> right, the fdi will be used if hal is there and do nothing otherwise
<seb128> tjaalton, ^ that blocks the fixed gdm build
<seb128> brb
<pitti> seb128, tjaalton: want me to upload a new xorg?
<pitti> hm, hang on, xserver-xorg has always depended on hal
<pitti> at least in jaunty
<pitti> so it's just because it's now a build dep?
<pitti> anyway, moving to recommends should be fine
<cjwatson> xserver-xorg is a bit of an exotic build-dep isn't it?
<cjwatson> why is that needed?
<pitti> seb128:
<pitti> pitti| hm, hang on, xserver-xorg has always depended on hal
<pitti> pitti| at least in jaunty
<cjwatson> I can understand xvfb or something ...
<pitti> pitti| so it's just because it's now a build dep?
<pitti> seb128: can we not b-dep on xserver-xorg and just hardcode the new X path?
<cjwatson> recommends> doesn't hal give xserver-xorg its ability to accept input?
<pitti> xserver-xorg pulls in the entire xorg stack, which is weird
<cjwatson> that seems like a bit more than recommends to me
<pitti> cjwatson: it should just be -evdev, but let's not turn all of them upside down right now indeed
<pitti> so, dropping the xserver-xorg b-dep from gdm seems least intrusive to me
<seb128> yeah, I just copied what debian did to fix this issue
<seb128> seemed to be the quicker way
<seb128> I will have a look to change the configure logic rather now
<maxb> Concerning the keyboard setup callout, it seems that the current xorg seems to have copied an old fdi file from before LP 375618 was fixed
<ubottu> Launchpad bug 375618 in hal "does not pass xkb* settings to xorg server" [High,Fix released] https://launchpad.net/bugs/375618
<pitti> maxb, tjaalton: so perhaps xorg should update the fdi and script to the versions from hal? (http://bazaar.launchpad.net/~ubuntu-core-dev/hal/ubuntu/revision/336)
<maxb> I've just rebooted having taken the fdi that was shipped in yesterday's hal, and the bug is fixed again
<Sarvatt> sounds like thats what needs to be done
<pitti> ok, will upload then
<pitti> maxb: ah, you already added an xorg task?
<tjaalton> pitti: I'll fix it.. maintained in git etc
<pitti> tjaalton: oh, ok
<pitti> thanks
<maxb> xorg task added, now added explanatory comment
<pitti> tjaalton: reassigned to you
<tjaalton> ok
<tjaalton> oh, it needed all that.. perhaps debian wants that too
<pitti> tjaalton: yes, it wouldn't hurt in debian either
<pitti> to make it independent from the other fdis
<tjaalton> right, I'll push it there too
<tjaalton> guess I've seen a similar bug there
<pitti> tjaalton: see http://bazaar.launchpad.net/%7Eubuntu-core-dev/hal/ubuntu/revision/326 for rationale (and the same bug)
<tjaalton> yeah saw the diff from there
<kirkland> bryce: x on my karmic thinkpad looks to be hosed again?
<tjaalton> kirkland: just wait for the latest gdm to build
<kirkland> tjaalton: awesome, thanks
<tjaalton> or change the patchs to X in gdm.conf
<tjaalton> paths, even
<blistov1> what has happened to ctrl+c in server 9.04 and up?
<blistov1> along with ... most of the other ctrl commands?
<cjwatson> nothing?
<cjwatson> at least not for most people :)
<blistov1> sorry, 9.10
<cjwatson> there is a known problem with console-setup that means the keymap is a bit busted; if 'sudo setupcon' fixes your problem, then that's what you're running into
<infinity> pitti: Are you willing to pretend to be a hal expert for a second?
<pitti> infinity: I was, two seconds ago :)
<pitti> infinity: what's up?
<blistov1> cjwatson: sudo setupcon does not fix it.
<infinity> pitti: It's failing to stop "hald-addon-acpi" and purge from chroots.
<blistov1> ctrl+c, d, z... none of them work.
<blistov1> Every 9.10 install I have.
<blistov1> Just noticed :)
<infinity> pitti: And, more curiously, running my scan-for-processes script (the same one the buildds use at the end of a build) works fine.
<pitti> infinity: it's a miracle that it started in the first place..
<infinity> pitti: Does it auto-respawn or something insane when killed?
<pitti> infinity: nope
<pitti> it just gets started on startup, no d-bus activation for hal
<seb128> btw about this hal doesn't start breaks xorg-server install thing
<infinity> pitti: Miracles notwithstanding, it's being started on the lpia buildds. :/
<pitti> (just yet, it will come in the near future)
<seb128> is there really a reason to break xserver-xorg configuration if hal doesn't start?
<cjwatson> blistov1: 'stty sane'?
<pitti> infinity: what package pulls that in? it shouldn't be a build dep in the first place
<blistov1> cjwatson: root@ebackup:~# stty
<blistov1> speed 38400 baud; line = 0;
<blistov1> -brkint -imaxbel
<pitti> infinity: or is that just the 0ubuntu4 gdm?
<infinity> pitti: I suspect it's a recommends somewhere.
<infinity> pitti: xserver and gdm are both pulling it in as build-deps.
<cjwatson> blistov1: I know it works for me (9.10 desktop upgraded from $ancient, but should be no difference) because my baby daughter managed to type ctrl-z on a console earlier tonight ;-)
<blistov1> cjwatson: sane does nothing.
<pitti> infinity: either way, I hope to mostly get rid of hal in karmic, so I guess we shouldn't waste too much work on little issues like that
<infinity> pitti: (And the buildds still do recommends by default because... I haven't turned that off)
<pitti> infinity: gdm was fixed in 0ubuntu5
<pitti> infinity: oh, does Debian do that? I thought b-deps were depens only
<infinity> pitti: Right, well, I don't care much about the underlying bug, I care about it killing the buildds outright when it happens. :)
<cjwatson> blistov1: don't know, then, I'm afraid. File a bug and we'll look into it ...
<infinity> pitti: build-deps are depends-only, but apt kinda grew the "recommends-by-default" thing, so I need to explicitely turn it off.
<blistov1> cjwatson: grrr.
<pitti> infinity: if some other package b-deps on hal or xserver-xorg, I'd rather fix just that
<infinity> pitti: And, more annoyingly, only for the suites that support the option.
<blistov1> cjwatson: well, i'll install a test box using today's daily build. see what happens.
<blistov1> i noticed though that the default TERM  is not "linux" instead of "xterm"
<blistov1> cjwatson: oh, and its only through ssh.  Logging in on a physical terminal seems to work fine with "linux" term set
<tjaalton> seb128: are you suggesting the postinst fails if 'invoke-rc.d hal restart' fails?
<seb128> tjaalton, yes
<seb128> tjaalton, that what broke the gdm build
<superm1> ls
<superm1> oops :P
<tjaalton> seb128: hrm..
<cjwatson> blistov1: I'm not sure I understood your sentence about $TERM. Did you mean to type "now" rather than "not"?
<infinity> pitti: Err, wait, you say there's a new gdm source that doesn't build-dep on xserver-xorg?
<cjwatson> Ctrl-C works fine over ssh here
<pitti> infinity: yes, 0ubuntu5; only 0ubuntu4 did, and it was an error
<TheMuso> pitti: We need to package rtkit first.
<pitti> TheMuso: OMG, another kit?
<tjaalton> seb128: ok, it should be fixed then
<seb128> pitti, not really an error but right ;-)
<cjwatson> and TERM=screen, as it should be since I'm sshing from inside a screen session. TERM depends on what you're coming from not what you're going to
<pitti> okay, s/error/bad move/ :)
<cjwatson> having a mis-set TERM would certainly explain terminal features not working properly
<seb128> TheMuso, hey, what information would be useful for an "there is no sound being played on karmic" issue?
<TheMuso> pitti: Yes, and its a Lennart creation, and it needs kernel 2.6.31 or newer.
<cjwatson> blistov1: could be a buggy .bashrc or similar startup script?
<TheMuso> seb128: Whether volume is turned up in gnome-volume-control applet or alsamixer, whether there are any card# directories in /proc/asound, and whether there are any /dev/snd device nodes.
<seb128> TheMuso, yes for all of those
<TheMuso> seb128: Did sound work before? and are you able to run alsamixer in a terminal as an ordinary user?
<pitti> seb128: does aplay just play silently, or fail with an error?
<seb128> TheMuso, things do play sound in the sense they don't display any error and act as sound was being played but the is no actual sound
<seb128> pitti, ^
<pitti> TheMuso: FYI, there was a bug in udev which caused auto-ACLs not to apply; that's not seb128's problem, but it hit me, and anyone else who isn't in audio group
<seb128> TheMuso, it worked in jaunty, not since I updated to karmic I think
<seb128> TheMuso, and yes, I can run alsamixer, the gnome mixer or the new pulse mixer, use aplay and paplay, no error
<TheMuso> pitti: Yeah that hit me as well.
<seb128> they all act as they were doing their job
<TheMuso> seb128: Ok, are either any of master, PCM, or front turned down or muted?
<seb128> TheMuso, I've only master and pcm listed and they are not muted and have volume
<TheMuso> Hrm. Tried either killing pulse and playing sound, or restarting pulse?
<seb128> yes
<seb128> no luck
 * pitti suggests booting jaunty kernel
<seb128> but pulseaudio might just get auto respawned
<pitti> chmod 0 usually helps :)
<TheMuso> Or creat ~/.pulse/client.conf and put "autospawn = false" into it.
<pitti> good night everyone
<TheMuso> Youcould try clearing your .pulse* files and restarting pulse.
<seb128> pitti, 'night
<seb128> TheMuso, not a pulseaudio issue, still no sound with pulseaudio binary moved somewhere else and pulseaudio stopped, I will try what pitti suggested, booting a jaunty linux version
<TheMuso> seb128: ok
<seb128> TheMuso, ok, 2.6.28 has sound
<blistov1> cjwatson: brand new install. haven't touched anything with .bashrc or anything else
<blistov1> physical terminal works. ssh does not.
<cjwatson> blistov1: ssh *from what*?
<cjwatson> that's likely to be really quite relevant
<blistov1> from ... gnome-terminal of multiple versions, yakuake (multiple versions), xterm (multiple versions)
<blistov1> cjwatson: also, "exit" doesn't actually end the session.  just prints logout, and hangs.
<blistov1> something very odd with everything tty related.
<cjwatson> and you said TERM=linux on the server side?
<cjwatson> what does echo $TERM say if you run it in the same terminal before running ssh?
<blistov1> cjwatson: if i log in on a physical console (or rather, vm console), i get TERM=linux by default.  If i login via ssh, i get xterm
<cjwatson> that's as it should be, given an xterm-like client
<TheMuso> seb128: ok sounds like a kernel regression.
<seb128> TheMuso, right, what information would be useful in a bug out of the chipset reference?
<cjwatson> blistov1: it's after 11pm here and I'm not really awake enough to work this out. Could you please use 'ssh -vvv' to get a debug log and file a bug with it?
<blistov1> Before I ssh to the server, I have xterm set.  When i've ssh'd in to the server, i still have xterm.  If I set TERM=linux before sshing to the server, the TERM stay's "linux", but the problem remains.
<blistov1> cjwatson: will do.
<cjwatson> TERM is unlikely to be relevant; the values you are describing as being set are correct. Setting TERM to something different will only make things worse.
<TheMuso> seb128: Running http://www.alsa-project.org/alsa-info.sh or using ubuntu-bug alsa-base would get what is needed.
<seb128> TheMuso, ok thanks
<blistov1> cjwatson: you are correct.  TERM seems irrelevant.
<blistov1> brb
<TheMuso> seb128: I assume the no sound was with 2.6.31?
<cjwatson> I doubt it's actually ssh's fault, since it hasn't changed in any relevant way, but it's as good a place as any to start since it appears to be the distinguishing factor at the moment
<seb128> TheMuso, no, current karmic, 2.6.30-10
<TheMuso> seb128: oh ok.
<dupondje> seb128: u have no sound ? errors ? Cause I had no sound some hours ago neither and got it fixed
<seb128> dupondje, no, it's different from the udev permission issue
<seb128> dupondje, I've no sound since 2.6.30 and it works using 2.6.28
<dupondje> oh ok :)
<TheMuso> seb128: I wonder whether its worth trying with 2.6.31. Its in the archive, but not been pushed out yet as the next kernel to upgrade to.
<seb128> TheMuso, I will do that before opening a bug, thanks
<seb128> but for now time to sleep, I will see that tomorrow
<TheMuso> Ok good night.
<seb128> TheMuso, thanks for helping me to figure what is wrong
<TheMuso> seb128: np
<TheMuso> c
#ubuntu-devel 2009-07-01
<chrisccoulson> beuno - regarding bug 189192 - gdm-setup does not exist anymore in gdm-new, which is going to shortly appear in karmic I think
<ubottu> Launchpad bug 189192 in hundredpapercuts "gdmsetup dialog is to big for 1024 x 768 resolution" [Medium,Triaged] https://launchpad.net/bugs/189192
<chrisccoulson> not sure there's any point spending effort on fixing something thats about to disappear
<beuno> chrisccoulson, it's going away?
<beuno> in karmic?
<chrisccoulson> AFAIK, yes. i don't think there is a graphical tool to configure the new GDM yet
<beuno> chrisccoulson, if you can confirm it, please mark is as invalid
<chrisccoulson> and if it is, it won't be gdm-setup - it's all been re-written
<chrisccoulson> i'll try and confirm that tomorrow. i havent done any proper testing with gdm-new yet, but the last time i tested it there was no gdm-setup anymore, and upstream hadn't developed any tool to configure it yet
<ebroder> What are the rules for a version number of a Debian-native package that only exists in Ubuntu?
<ebroder> Are they arbitrary, so long as they end with ubuntuN?
<ScottK> ebroder: If it's truly Ubuntu unique and will never be in Debian either, the ubuntuN is optional.
<ebroder> Oh, ok. (package in question is branding-ubuntu, so it's probably not going to end up in Debian)
<ScottK> Probably not
<Mez> morning sabdfl
<sabdfl> hey Mez
<sabdfl> it is, in taipei :-)
<Mez>  sabdfl it's just about morning in the UK
<Mez> well, it is morning... but early enough that I should be going to bed
<ajmitch> depends on how early you need to be awake
<Mez> 7
<Mez> (ish)
<ion> Itâs 4:37 here. Bedtime.
<Mez> I'm session chairing @ EuroPython
<ajmitch> oh nice
<kees> tonight's puzzle: why is sizeof(struct dirent64) == 276 on i386 and == 280 on amd64?
<lifeless> bet its the timestamp
<slytherin> cjwatson: the powerpc chroot you gave, it is to be used with pbuilder, right?
<slytherin> cjwatson: I am getting this error when using it - http://paste.ubuntu.com/207307/
<dholbach> good morning
 * StevenK glares at compiz
<highvoltage> did it glare back?
<hyperair> hehe
<pitti> Keybuk: FYI: http://bugzilla.gnome.org/show_bug.cgi?id=485806
<ubottu> Gnome bug 485806 in general "gtkdoc-check can't cope with BUILDDIR != SRCDIR" [Normal,New]
<dholbach> When you stare into the abyss, the abyss is staring back at you.
<StevenK> Hehe
<nellery> dholbach: bug #?
<nellery> hehe
<StevenK> But compiz is pulling KDE for Ubuntu and UNR
<Quintasan> Hi \o
<dholbach> nellery: hm?
<nellery> dholbach: ah, nevermind you were referring to compiz
<nellery> bad attempt at a bad joke
<dholbach> it was a Nietzsche quote :)
<nellery> ah
<dupondje> Why does firefox-3.5 still use the Shiretoko menu item + logo ? :s
<RAOF> dupondje: I'd guess because we haven't switched on the branding yet?
<dupondje> menu item still says 'Beta' now :P
<dholbach> dupondje: I'm sure asac has a branch of it, where you can just fix it :-)
<dupondje> or we look friendly to asac to fix it ;)
<dupondje> hmz, that rule file is dynamic :P
<asac_> dupondje: plan was to switch branding when we switch to ffox 3.5 by default
<dupondje> oh ok asac_  :) looked bit weird now
<dupondje> and when is the plan to change to ff3.5 default ?
<asac_> dupondje: when all xul1.9 dependencies in main are ported to 1.9.1
<asac> shouldnt take too long
<dupondje> and the search providers aren't installed by default now ?
<asac> dupondje: yeah. keep firefox-3.0 installed for now
<dupondje> okey :)
<asac> dupondje: its  bug 383484
<ubottu> Launchpad bug 383484 in firefox-3.5 "search engine plugins missing in firefox-3.5 packages" [High,Triaged] https://launchpad.net/bugs/383484
<dupondje> I'm sure u'll fix it ;)
<pitti> mvo: meh, what is the working way of saying "apt-get source linux"?
<pitti> oh, --only-source
<pitti> mvo: nevermind, found it
<slytherin> can anyone please give back gnome-applets?
<Tm_T> slytherin: but they was so tasty
<pitti> slytherin: done
<slytherin> pitti: thanks
<dupondje> asac: I see that clicking links in other apps is broken also by install ff3.5, dunno if known bug
<cjwatson> slytherin: our chroots use launchpad-buildd (a wrapper around sbuild) to build, not pbuilder. You'll probably have to mangle it a bit to make it work with pbuilder; I'm guessing not *too* much but I don't know how
<asac> dupondje: yeah. its a missing custom application entry. you can change that in gnome preferred applications dialog ... just set custom command firefox-3.5 %s
<slytherin> cjwatson: I can try using sbuild. Any idea if it will work with sbuild out of box?
<cjwatson> I have no idea. Sorry. All I was doing for you was shovelling the bits around.
<cjwatson> Worth a try I'm sure.
<slytherin> cjwatson: I will try tonight and let you know. Meanwhile I guess I will also ask persia.
<pitti> cjwatson: ah, you managed to get something buildable out of the udev bzr branch? *applauds*
<cjwatson> pitti: debian/rules package didn't do what I wanted, I had to do the same but without the clean-tree
<pitti> cjwatson: I added a debian/rules prep for that yesterday
<pitti> cjwatson: to work around the gtk-doc breakage
<cjwatson> pitti: yes, I used that
<pitti> cool
<cjwatson> pitti: but debian/rules prep; debian/rules package resulted in a substantial diff from 143-7 because some things were cleaned up relative to what was in the 143-7 diff
<cjwatson> I had to do debian/rules prep; (the dpkg-buildpackage bit out of debian/rules package)
<cjwatson> and that worked fine
<pitti> cjwatson: right, I don't use debian/rules package either
<slytherin> pitti: I though gnome-applets FTBFS on ports architectures was transitional failure. But it looks like gnome-applets needs update in build-dependencies (libgucharmap-dev -> libgucharmap2-dev)
<seb128> slytherin, correct
<seb128> will be fixed in the next upload
<slytherin> seb128: thanks. :-)
<pitti> cprov1: hm, this SRU was uploaded/built yesterday, and apparently published just fine: https://edge.launchpad.net/ubuntu/+source/pidgin/1:2.5.5-1ubuntu8.2
<pitti> cprov1: however, binaries are missing from archive.u.c.: pidgin | 1:2.5.5-1ubuntu8.2 | jaunty-proposed | source
<pitti> any idea about that?
<pitti> hm, they are on cocoplum, so probably not a soyuz problem
<cjwatson> pitti: xorg-docs/xorg-docs-core looks like a trivial main promotion to me, and is necessary for installability. Any objections?
<pitti> cjwatson: agreed
<pitti> although I object to installing it by default
<pitti> it's 2 MB, and not really necessary; we have manpages already
<cjwatson> only xorg-docs-core is installed by default
<pitti> ah, good
<cjwatson> which is Installed-Size: 108
<cjwatson> xorg-docs is just in supported
<cjwatson> and xorg-docs-core actually seems to be the thing that provides manpages
<cjwatson> promoted
<mbiebl> <pitti_> mbiebl: would you mind if I add some bug fix patches to devkit-power and add myself to uploaders?
<mbiebl> pitti: please go ahead ;-)
<pitti> mbiebl: oops, sorry, I rebooted and was thrown out of debian
<pitti> mbiebl: thanks
<pitti> mbiebl: Richard just accepted my patch :)
<pitti> finally, no lid open-boot-lid-close at the right time madness at login any more :)
<maxb> Has anyone else experienced gtk programs segfaulting when you touch a combo box? So far I've only had this happen in Eclipse. But not much else that I use uses combo boxes.
<seb128> maxb, there is a bug open about that
<maxb> ah, /me heads malone-wards
<bullgard4> pitti: Why does the command /usr/share/apport/apport-gtk produce no output? It triggers some hard-disk activity though.
<pitti> bullgard4: by default it shows pending crashes
<pitti> bullgard4: (hd activity> it checks for pending crashes)
<pitti> bullgard4: try --help
<bullgard4> Thank you.
<dholbach> chrisccoulson: done
<chrisccoulson> dholbach - thank you:)
<dholbach> can somebody please change the Maintainer field of piding to ubuntu-devel-discuss@lists.u.c? :)
<dupondje> djsiegel: i'm on the bug u mailed :P
<djsiegel> dupondje: oh, sorry for the spam :)
<dupondje> np
<dupondje> :D
<dupondje> 100 mails /day
<dupondje> or 101 mails /day
<dupondje> who cares :)
<djsiegel> yeah, I am at about 1000
<djsiegel> dupondje: I am flailing around trying to find people with time to do a paper cut this week
<dupondje> N_("Toggle the Search Bar to locate documents and folders on this computer by name"),
<dupondje> ok djsiegel  ? ;)
<seb128> dholbach, you still have upload rights don't you?
<seb128> dholbach, ie no need to ask every day about pidgin, just upload?
<dholbach> if it were a branch, I'd just add it there
<dholbach> no need doing an upload just for that
<seb128> well why do you ask then? ;-)
<Laney> I didn't see a bug about it when doing the merge ;)
<seb128> I forgot when I sponsored the update today but if that's worth doing an another upload ...
<seb128> Laney, yeah there is none, that has been mentioned on IRC and I said I would change it but I forgot today
<Laney> yeah I did too...
<kirkland> pitti: ping
<kirkland> pitti: what's the story with hal?  there's a bit of hal in kvm that I'm wondering if it should remain, or be dropped?
<seb128> kirkland, he's away for the evening
<seb128> kirkland, but hal is being deprecated so better to stop using it
<kirkland> seb128: okay, cool, thanks.
<seb128> you're welcome
<Keybuk> kirkland: what do you use HAL for?
<kirkland> Keybuk: hal + policykit for /dev/kvm access
<Keybuk> I may be able to help with knowing what to replace it with
<Keybuk> ACL setting?
<kirkland> Keybuk: only pertinent for desktop-y use of kvm, like virt-manager
<Keybuk> or brokerage?
<kirkland> Keybuk: /dev/kvm perms are
<kirkland> crw-rw----+ 1 root root 10, 232 2009-06-29 17:53 /dev/kvm
<kirkland> whoops
<Keybuk> getfacl /dev/kvm ?
<kirkland> that's wrong
<kirkland> crw-rw----+ 1 root kvm 10, 232 2009-07-01 09:08 /dev/kvm
<Keybuk> kirkland: also getfacl /dev/kvm
<kirkland> Keybuk: http://pastebin.ubuntu.com/207624/
<Keybuk> ok
<Keybuk> so that's what HAL is doing for you
<Keybuk> it's arranging for active console users to have a rw ACL on /dev/kmem
<Keybuk> uh, kvm sorry
<kirkland> Keybuk: okay
<Keybuk> the good news is, you don't have to do anything
<zyga> mvo: hey
<Keybuk> littlebigplanet udev-143% grep kvm extras/udev-acl/70-acl.rules
<Keybuk> SUBSYSTEM=="misc", KERNEL=="kvm", ENV{ACL_MANAGE}="1"
<mvo> hey zyga
<zyga> mvo: nice to see you again!
<mvo> zyga: nice to see you!
<Keybuk> that bit is already being handled by udev now
<zyga> mvo: I've revived development on command-not-found
<mvo> zyga: nice, have you seen the latest stuff in the 0.2.x branch?
<zyga> mvo: I'll try to join all distros that use this kind of tool together with one client
<zyga> mvo: I've branched off the ubuntu-core-dev tree
<zyga> I've seen spellcheckin magic! (really amazing)
<zyga> and lots of nasty l10n/python/gettext issues helpers
<mvo> zyga: its pretty nice, I like it
<kirkland> Keybuk: cool, so i can just drop the hal part?
<zyga> I plan to track ubuntu-core-dev as I make improvements not to loose any patch
<mvo> zyga: its great to have you back
<Keybuk> kirkland: yup
<kirkland> Keybuk: rock on, thanks.
<zyga> mvo: I don't think I'll catch up with karmic (I don't know any deadlines) but I'll try to setup a ppa soon so that  interested people can inspect what I did
<zyga> I'm glad to be back
<mvo> zyga: keep me notified, I'm happy to merge/upload improvments and fixes
<zyga> mvo: I'll keep that in mind
<mvo> zyga: what are you plans? making it more distro indepedant?
<zyga> 1) speed
<zyga> 2) unified for distros
<zyga> 3) separate front and backend
<zyga> I'm planning on getting it to target ubuntu/debian, suse and later fedora
<zyga> suse has a totally independent implementation
<zyga> that can become a backend for cnf
<zyga> one source
<zyga> the packager/author already expressed interest in that
<shaya> anyone here using the firefox 3.5 package?
<shaya> it doesn't seem to play html5 video
<zyga> fedora is difficult because of packagekit, packagekit is sloooow on fedora, I'm no sure I can get the kind of speed I want
<zyga> mvo: but I have a technical question for you if you dont mind
<zyga> actually two:
<zyga> 1) is it safe to keep apt.cache open for long periods of time?
<mvo> zyga: nice, for speed, will the C client become reality?
<zyga> 2) what is the good way of accessing localized package description by name
<mvo> zyga: keeping it open is probably not a great idea, it can change under your feet
<zyga> mvo: I experimented with a vala client in the past but I was always put off buy vala being inmature back then
<mvo> zyga: for the localized description that should just work via python-apt transparently
<zyga> mvo: I hope to make a small stub client that just wakes a dbus service that actually gives you the data
<mvo> zyga: I was told its much better nowday, but I got no first hand experience
<zyga> mvo: I tried getting l10n summary but I failed, can you give me some hints?
<zyga> basically I did this:
<zyga> cache[package.name].summary
<zyga> where cache is apt.cache.Cache()
<zyga> but that is terribly slow
<zyga> I was thinking about manually getting at the required data (I know where it is)
<zyga> so that 1) you can "keep" the cache warm in the server
<zyga> BRB
<kees> ScottK: do you remember the history of cyrus-sasl2-heimdal's need for exact binary version matching with cyrus-sasl2?
<ScottK> kees: Vaguely.  It used to be in the same source package and Debian split it out for some odd reason.
<mvo> zyga: give me a minute, I build a example
<kirkland> Keybuk: what about lshal?
<kirkland> Keybuk: is something else going to provide that functionality?
<kirkland> Keybuk: we're using that for report-bug functionality
<Keybuk> kirkland: replace with /var/log/udev
<kees> ScottK: upstream uses this now:  Depends: libsasl2-modules (>= ${source:Version}), libsasl2-modules (<< ${source:Version}.), ${shlibs:Depends}
<kirkland> Keybuk: coolio
<ScottK> kees: I don't think we have any need to be more strict than Debian is.
<kees> ScottK: okay, I'm going to fix it for hardy, jaunty, karmic.  (intrepid is >=)   it broke when cyrus-sasl2 update went out.  :(
<zyga> mvo: back (kids), thanks for the example!
<zyga> mvo: I want to get access to package summary in a fast/safe/memory efficient way/without blocking regular apt
<zyga> mvo: I was thinking about parsing translationi files directly but they have no index (bad)
<zyga> cnf could keep a cache of package name -> seek offset with hints for the implementation
<zyga> and this cache could be built the first time the index is cold
<zyga> and discarded on index update (mtime
<zyga> mvo: but frankly this all seems to me like re-inventing packaging system in a bad way :/
<mvo> zyga: yeah, one problem is that you can not get the pkgcache without the depcache with python-apt :
<mvo> :/
<zyga> depcache is expensive?
<zyga> mvo: as I said for the time being I'd love to hack an 1) efficient 2) temporary solution
<zyga> mvo: http://pastebin.com/m7fe1c2dd (small peek at what I'm doing now)
<mvo> zyga: sweet, how do you record the amount of usage?
<mvo> zyga: yes
<zyga> mvo: I parse shell history (currently only bash)
<mvo> zyga: wife is calling, can I mail you the example (maybe there is a bug somewhere, the description should be localized)
<mvo> zyga: nice idea
<zyga> mvo: sure, thanks for your help - I'll stay in touch
<soren> tseliot: Hey. I patched up the bcmwl package last night to support 2.6.31. Is there some upstream that would want the patch?
<soren> tseliot: I doubt it would get very far if I just pasted into Broadcom's web based "Contact us" form or whatever :)
<allesmueller_> hi, I have really strange problem on jaunty (nbr) with a netbook nc10 - where to ask?
<ion> soren: I think the patch broke bcmwl with 2.6.30, btw.
<zyga> allesmueller_: I have an nc10 with me
<allesmueller_> zyga, with hsdpa modem?
<zyga> yeah
<zyga> :-)
<ebroder> Anybody familiar with iscsi? I think bug #394398 is a regression in the recently SRU'd-to-hardy open-iscsi
<ubottu> Launchpad bug 394398 in open-iscsi "Logic to determine expected number of running session wrong (regression in hardy's open-iscsi 2.0.865-1ubuntu3.1)" [Undecided,New] https://launchpad.net/bugs/394398
<soren> ion: Really? Hm... I wrapped it in #ifdef's and such.
<soren> ion: Perhaps I screwed it up :(
<allesmueller_> Zyga, good - did you experience problems with heavily used ssl streams like openvpn or citrix secure gateway?
<ion> soren: http://heh.fi/tmp/bcmwl-make.log
<zyga> hmm, no I don't use vpn's
<zyga> but still I did some heavy traffic
<zyga> (about 4Mbit sustained0
<soren> ion: Gah.
<soren> ion: I see the problem
<zyga> what kind of problems did you experience?
<soren> I checked that the #ifdef's were applied correctly, but didn't notice the wrong attribute name.
<ion> soren: I wouldnât mind using 2.6.31 if it didnât make X unbearably slow and break backlight control. ;-) (Didnât get around to reporting the bug yet, but i will)
<allesmueller_> zyga, well regular traffic seems ok, but these 2 applications fail - they work with same settings on a huawai e270
<zyga> I have a different modem
<zyga> I use an internal samsng modem (usb device)
<allesmueller_> zyga, yes thats the one which makes troubles :(
<zyga> It works perfectly for me
<allesmueller_> zyga, which firmware?
<zyga> but as I said I don't use the vpn
<zyga> I didn't add any extra repos I don't know
<zyga> stock from ubuntu
<zyga> but actually I don't have afirmware
<allesmueller_> zyga, it's in the hardware
<zyga> the modem just works using the acm driver
<zyga> (yeah but I didn't upgrade)
<allesmueller_> how old is your NC10
<zyga> I might update though... I did boot xp once to upgrade all "win" drivers
<zyga> sold in december 2008
<allesmueller_> you can look with minicom - if you wanted
<allesmueller_> mine is Revision: Y3100XXHL1
<zyga> actually it's downstairs
<zyga> if you want I can try
<zyga> ahh, samsung software ;-)
<allesmueller_> when did you upgrade last time
<soren> ion: Fix uploaded.
<ion> soren: Cool
<allesmueller_> zyga1, startet schnell :)
<allesmueller_> ups wrong lang :)
<zyga1> allesmueller_: nc10 !
<tseliot> soren: sorry but I have no idea. Did you use DKMS for the patch?
<zyga1> allesmueller_: what can I write to ask the modem it's version?
<zyga1> do you know the at command?
<allesmueller_> ati
<zyga1> Revision: Y3100XXHJ3
<zyga1> allesmueller_: I hope that helps
<allesmueller_> zyga1, seems older than mine ... thank you very much for your help
<zyga1> how do you determine that?
<zyga1> do you know how to parse samsung modem version numbers?
<allesmueller_> it's in german, sorry http://www.mobilfunk-faq.info/samsung-tipps-tricks/19134-howto-erklaerung-der-firmwarecodes-bei-samsung.html
<zyga1> can you write your modem version again
<zyga1> I know how those numbers work
<allesmueller_> Revision: Y3100XXHL1
<zyga1> hmm
<allesmueller> yessss?
<zyga1> I have a more recent version
<allesmueller> *urgs*
<zyga1> whoops no sorry
<zyga1> wrong
<allesmueller> *urgs*
<zyga1> I calculatated right but I swapped versions
<zyga1> your version is two months older
 * allesmueller lost last hope
 * allesmueller doesn't want to use the external modem - that really sucks
<zyga1> you can just use my version
<zyga1> samsung's polish page has those drivers
<zyga1> you can flash them somehow I'm sure (I don't know how regular people do that really)
<allesmueller> Y3100XXHJ3
<allesmueller> already downloaded, just don't know howto flash without windows
<zyga1> I'm sure you do need windows though :/
<allesmueller> maybe some freaky at command syntax :)
<slangasek> tkamppeter: do you know why printing has broken horribly for me some time in the last two weeks?
<slangasek> tkamppeter: are there reports of major regressions in karmic?
<tkamppeter> slangasek, no major regressions in Karmic. Please tell me what exactly does not work for you. Printer model? Files/apps which do not print? ...
<slangasek> tkamppeter: HP PSC 750, all printing from evince is broken
<slangasek> also from firefox
<slangasek> color printing is squished into a narrow band on the left of the page; b&w printing is rendered on 1/4 of the page
<slangasek> ... and the printing dialogs appear to have changed completely?
<mneptok> slangasek: <kosh> a stroke of the brush does not guarantee art from the bristles. </kosh>
<slangasek> full-duplex printing is a three-edged sword
<tkamppeter> slangasek, looks like that something with HPLIP is not working ...
<slangasek> tkamppeter: could be; is there testing I should do before filing a bug?
<tkamppeter> slangasek: My PhotoSmart C8100 works perfectly.
<tkamppeter> slangasek: Please file a bug, especially attach an error_log as described in the "CUPS error_log" section of https://wiki.ubuntu.com/DebuggingPrintingProblems
<c_korn> hello, why do I only get empty packages with this control and rules file? http://pastebin.com/d4904a825 http://pastebin.com/d3024e5e6
<maxb> cdbs! runaway!
<maxb> :-)
<c_korn> isn't my package. :P
<c_korn> it seems to be because of missing .install files.
<maxb> Makes sense. If you don't tell debhelper to install anything... :-)
<c_korn> well, I did not advise it to install into debian/tmp
<maxb> that's common idiom for a multibinary package
<c_korn> yes, I realized it. now I have to create a gnome-commander.install file with content "debian/tmp". then I think it stripes the binaries inside and installs the debugging symbols into the gnome-commander-dbg package
<hile> btw reminds me, why alsa-plugins build insists building amd64-versions on i386?
<hile> multiarch is fine, but seems strange you need to build multiarch by default
<slangasek> that's not multiarch
<hile> dunno if it's multiarch but you need to install binaries which don't work on your hardware to build it
<hile> i386 and x64 are IMO different architectures to me... not like m68k vs arm but if you can't run the binary you are required to build..
<hile> I just don't understand requirement for control file rules like libc6-dev-i386 [amd64]
<slangasek> multiarch is the exact opposite of this, fixing it so we /don't/ need to build i386 binaries on amd64 and vice-versa
<slangasek> what you're looking at is the workaround, needed in order to support installing 64-bit applications on an i386 system - which works only if you're running a 64-bit kernel
<hile> but this was build requirement, not install requirement?
<hile> well anyway, it works, was just confusing
<slangasek> tkamppeter: do you want this bug filed against cups, or against hplip?
<tkamppeter> sladen: hplip
<slangasek> tkamppeter: ok
<tkamppeter> slangasek: hplip
<tkamppeter> sladen: Sorry.
<slangasek> hmm, perhaps I should have the printer connected while filing this bug
<tkamppeter> slangasek: Yes, to get the correct error_log and also to get correct apport data.
<slangasek> the error_log is all but empty
<slangasek> but yeah
<tkamppeter> slangasek: There is something really broken on your box. Especially if you have set the debug mode of CUPS no one got an empty error_log.
<tkamppeter> slangasek: Can you look for CUPS-related "audit" messages in /var/log/syslog?
<slangasek> tkamppeter: er, I haven't set any debug mode for CUPS
<tkamppeter> See the web page which I mentioned earlier ...
<slangasek> I hadn't read that wiki page yet, didn't realize you wanted an explicit config change first
<slangasek> tkamppeter: btw, what happened that hpoj is now forced to be removed?  that appears to leave me with no option to have cups running at the same time as I'm using the scanner
<billisnice> i had trouble getting today's updates to update.  When i typed in my password to install all the updates, they unchecked for a second and went back to the update menu with them checked.
<slangasek> tkamppeter: bug #394447
<ubottu> Launchpad bug 394447 in hplip "karmic printing regression on HP PSC 750" [Undecided,New] https://launchpad.net/bugs/394447
<maxb> Does anyone have a version of update-grub that works across multiple ubuntu installations in different partitions?
<dupondje> Sarvatt: u have a nouveau version for 2.6.31 ?
<c_korn> the current ubuntu daily is not installable? xorg: Depends on xorg-docs-core which is not installable
<Viper550> hmm, I have a little pondering - have we ever thought of '''removing''' Gimp from the default install?
<Sarvatt> saves a huge chunk of space on the livecd removing it, thats for sure :D
<ion> Triple quotation mark? :-)
<Viper550> If we remove gimp from the default, an advanced piece of software whose basic functionality for image tweaking/etc can be found in other apps, we can put more useful stuff in
<Viper550> you know what, I'll make a spec for that
<Sarvatt> (like the pae kernel)
<EvanCarroll> I really wish the bug tracker permitted fileing a distribution bug link for CPAN
<EvanCarroll> it should permit linkouts to rt
<Viper550> https://blueprints.launchpad.net/ubuntu/+spec/remove-gimp
<EvanCarroll> The way Debian packages perl, is seriously 110% retarded.
<EvanCarroll> It makes me sick.
<ion> evancarroll: Because making a version control system do the hard work of rebasing patches is bad?
<EvanCarroll> exactly.
<EvanCarroll> This is why god invented subclassing, and namespaces -- if debian wants to break stuff, they shouldn't be monkey patching it into unbroken stuff.
<EvanCarroll> And they should be subclassing.
#ubuntu-devel 2009-07-02
<bluefoxicy> wtf?
<bluefoxicy> I have sound, but not if I'm watching a DVD in totem
<directhex> liba52?
<Viper550> https://blueprints.launchpad.net/ubuntu/+spec/remove-gimp
<dtchen> TheMuso: 'net access is intermittent ATM; i'll push rtk as soon as i can keep a decent connection
<TheMuso> dtchen: np, I've already got it packaged.
<TheMuso> dtchen: and its in the new ubuntu-audio-dev PPA.
<dtchen> TheMuso: ok
<TheMuso> and I'm about to upload pulse 0.9.16 there as well,a nd then get rtkit pushed to revu for inclusion in the archive.
<dtchen> right-o
<dtchen> HDA should be much better now that 2.6.31-git is in
<TheMuso> Right.
<TheMuso> bryce: Are any of you on the X team aware that the latest nvidia 180 drivers in the archive don't build against 2.6.31? If not, I'll file a bug.
<bryce> TheMuso, -nvidia will be broken until we get a new version from Nvidia built against .31
<directhex> Viper550, actually, it's been considered and marked as a "not happening without a damn good reason"
<dtchen> TheMuso: http://pastebin.ubuntu.com/207816/ is what i've been using
<directhex> Viper550, see https://wiki.ubuntu.com/DesktopTeam/Meeting/2009-06-09#The%20GIMP
<TheMuso> bryce: Ok.
<bryce> TheMuso, bug #394262 already covers this
<ubottu> Launchpad bug 394262 in nvidia-graphics-drivers-180 "[Karmic] nvidia DKMS building and installation for kernel 2.6.31-1-generic fails with exit status 10" [Undecided,Confirmed] https://launchpad.net/bugs/394262
<TheMuso> bryce: ok thanks
<TheMuso> Might set up nouveau then, as I want to give 2.6.31 a whirl.
<bryce> TheMuso, this is normal; the binary drivers always break at this point in the cycle when the kernel (or xserver) gets updated to new API/ABI stuff
<TheMuso> yeah I wasn't sure whether a fix was in the short term pipeline, thats all.
<bryce> TheMuso, that'd be great
<TheMuso> but I am aware of such breakage.
<bryce> doubtful
<bryce> we'll see though, Nvidia tends to be reasonably quick, although it could be several weeks
<TheMuso> bryce: Do I need to create a xorg.conf file for nouveau similar to nvidia? COuld I just change the driver name in the xorg.conf file I have now?
<bryce> TheMuso, yeah pretty much
<TheMuso> ok
<superm1> TheMuso, if it looks obvious, you can write a kernel patch that can be applied by dkms too
<bryce> -nvidia sometimes needs a lot of stuff in xorg.conf that nouveau won't need, so actually you could probably strip a lot of stuff out
<superm1> until nvidia has a new version
<TheMuso> ...and nouveau fails to build as well. I'll see if I can track down a fix for that.
<superm1> TheMuso, a quick google yields: http://leigh123linux.fedorapeople.org/pub/patches/nvidia-185.18.14.patch
<TheMuso> superm1: pOk thanks, I wasn't going to bother with that, but I'll take a look.
<dtchen> that and you just have to modify dkms.conf, and you're on your way
<superm1> here's the whole thread for it: http://forums.fedoraforum.org/showthread.php?p=1231266
<bryce> superm1, weird, that patch looks familiar for some reason
<bryce> superm1, is that the same change that's done to fglrx to make it build with .31?
<superm1> bryce, I don't think i've submitted anything for fglrx to build on .31
<superm1> bryce, i've tracked down a ton of stuff for .29 and .30 though
<dtchen> it's very likely the same change
<bryce> superm1, I think it was Sarvatt or Tormod that mentioned it to me
<superm1> knowing that i2c changed a lot, I think it's quite a hacky solution though to just remove i2c alltogether like that..
<dtchen> yeah, should poke zander for a real fix
<RAOF> TheMuso: Nouveau'll fail until I update the nouveau-kernel-source package.  Doing this requires updating the xserver-xorg-video-nouveau package, and libdrm-nouveau1 package, so there are a couple of pieces that need to fall into place first :)
<TheMuso> RAOF: Ok. I think at this point I'll just stick with 2.6.30. 2.6.31 is not urgent.
<RAOF> If you're lucky, the new nouveau stack will even do KMS.  And if you're _super_ lucky, it might even bring up X with kms enabled!
<ccheney> TheMuso: yea 2.6.31 crashes on boot for me :-\
<TheMuso> ccheney: It doesn't crash for me, I just don't have X.
 * ccheney thinks he will have to do a nice manually type in of the crash dump later to report the bug
<TheMuso> Mind you, I've only tried 2.6.31 on my desktop.
<TheMuso> My notebook will likely be another story.
<ccheney> ah i tried booting it on my x200
<ccheney> grr this is really annoying every time i restore my firefox it eventually crashes before finishing loading everything
<cjwatson> EvanCarroll: that's one package, afaict. I understand you're upset but I wish you'd stop generalising that to all of Debian's perl packaging, which is not as broken as all that
<cjwatson> EvanCarroll: it's pretty aggravating for those of us who package (small amounts of) perl stuff in Debian without this kind of problem
<cjwatson> and I don't think the problem I believe you're talking about has anything to do with core perl in Debian
<EvanCarroll> cjwatson: the issue is with anything debian modifies that is perl.
<EvanCarroll> cjwatson: It is totally wrong on its face.
<cjwatson> how is that in any way specific to perl?
<cjwatson> you could say the same thing about any distro patch (although it's only actually a problem in a minority of cases)
<EvanCarroll> I never said it was, I said it was specific to the way debian packages perl. it is all kinds of wrong.
<cjwatson> no, it's really not
<EvanCarroll> Yes, it really is.
<EvanCarroll> You see, you don't, if you're sane, open up a namespace and just drop your own stuff into it.
<cjwatson> from previous discussions, you're objecting to a patch that's been applied to one of the xml modules, changing its interface
<EvanCarroll> that completely defeats the purpose of a namespace.
<cjwatson> and distro changes to interfaces are often unwise, sure
<cjwatson> that has zero to do with perl packaging in Debian as a whole
<cjwatson> it's a single maintainer doing a silly thing
<EvanCarroll> No, I'm objecting to the debian policy that makes that kind of patch acceptable and ubiquitious
<cjwatson> but it's not ubiquitous
<EvanCarroll> Debian does it all over.
<ccheney> anyone know if there is a way to dump the current list of open webpages in a firefox profile? i can't get my firefox to come back up even with disabling all extensions
<cjwatson> that's a gross overstatement
<bryce> ccheney, wow I'd love to know how to do that
<bryce> that'd be *so* handy
<ccheney> asac: ping ^ ? :)
<ccheney> bryce: its probably in some sqlite format or something but any way to dump it at all would be useful
 * bryce nods
<ccheney> i have probably 100 tabs that i no longer can access :-\
<cjwatson> ccheney: it's in sessionstore.js in your profile
<cjwatson> you can run it through indent or whatever and then read it out fairly straightforwardly
<ccheney> cjwatson: thanks! :)
<cjwatson> some json library might even be able to parse it properly for you
 * ccheney hugs cjwatson 
<cjwatson> ah, no, sessionstore.js is apparently not json
<ccheney> cjwatson: do you know if there is a way to make indent properly break a js single line file that is 800KB?
<cjwatson> no, I think I had to fiddle about a bit last I tried that
<ccheney> ok
<cjwatson> ccheney: googling for "sessionstore.js parse" has some useful hits
<ccheney> ah thanks for the tip :)
<cjwatson> including e.g. http://tsukasa.net.au/~hg/greg_stuff/file/tip/parse_sessionsstore.py (untried)
<cjwatson> ... breaks for me, probably requires some munging
<ccheney> yea
<cjwatson> (specifically there are some values starting with #, I haven't looked into why)
<ccheney> one of the first links had a way to do it with grep
<ccheney> of course the file seems to have every url you have opened since your session started (or close to it)
<ccheney> 1542 urls for mine, lol
<ccheney> but a lot are dupes so it should be easy to get the useful ones out of the list
<ccheney> erm what is the guest password?
<ccheney> i used guest to search for the stuff in firefox but when i switched back to the guest session was locked and wanted a password
<bryce> ccheney, I've got a script that handles it now
<bryce> it's fugly and perl but works.  let me fix one thing and I'll pastebin
<ccheney> ok
<bryce> http://pastebin.ubuntu.com/207837/
<bryce> oops forgot one other bit...  http://pastebin.ubuntu.com/207838/
<cjwatson> ccheney: if you look at the file structure in more detail, closed tabs are in a different part of the file, and it's easy to distinguish the things that are open right now
<ccheney> ah ok
 * ccheney notes his two year old came up and told him it was time to eat, and pulled his highchair out
<ccheney> bryce: the script seems to be slightly off still only showed me 5 urls
<bryce> ccheney, hmm, maybe it is printing only one url per window, rather than one per tab
<bryce> yeah
<bryce> ccheney, cjwatson: actually it is JSON-ish, just that it breaks some syntax rules
<bryce> ccheney, bingo.  got it
<bryce> ccheney, http://www2.bryceharrington.org:8080/drupal/ff-pages
<emma> how are things going
<mneptok> emma: heya!
<emma> hi there :)
<emma> How are things going with your projects?
<mneptok> emma: OSCon coming up. working on prep for that. and the Community Leadership Summit.
<emma> Oh very cool.
<mneptok> emma: you going to either?
<slangasek> I'm boycotting OSCON because it's not in Portland
<slangasek> oh wait, that's not boycotting, I didn't attend when it was here
<mneptok> slangasek: that doesn;t stop you from being unrighteously indignant
<ghindo> slangasek, There's still open source bridge, Linux plumbers, etc.
<mneptok> the Linux Plumbers' Conference intrigues me, but i don't like prostate exams ...
<lifeless> LOL
<slangasek> ghindo: oh, I'm well aware. :)
<slangasek> I found the spontaneous appearance of OSBridge to be wonderfully amusing
<mneptok> slangasek: the OS Bridge people cut out "I planned to start my talk with an interpretive erotic dance to the theme from 'Knight Rider' ..." from the video of my keynote. i am not amused.
<slangasek> heh
<TheMuso> woohoo about time. Skype is getting pulseaudio support.
<dholbach> good morning
<dholbach> Ubuntu Development and Packaging Q&A in 10m in #ubuntu-classroom
<pkt> anyone here knowledgeable about the ca-certificates-java issue?
<pkt> the changelog claims it is fixed, but it seems it isn't
<pkt> and I can't find any hint of where exactly it filters out certificates using unsupported algrorithms
<pkt> oh, nevermind I found the code
<pkt> now, still need to figure out why it doesn't work ...
<pitti> Good morning
<pitti> kirkland: confirmed, please drop all the hal bits and the fdi; teh ACL si taken care of
<pitti> meh, I need to wake up, can't type yet
<YokoZar1> Can a package recommend a minimum version of a package?   If I recommend foo (>= 1.2) and there's a foo 1.0 and a bar 1.2 that provides foo,  will bar be installed?
<geser> provides are always unversioned
<geser> so foo (>= 1.2) will wait on foo 1.2-1 even if bar 2.0 provides foo
<asac> ccheney: while running?
<asac> (list of open webpages)
<j^> fta, whats the best place to file a bug for chromium-browser?
<j^> FFMPEG_MT_CONFIGURE_FLAGS has to include --extra-cflags="-m32" --extra-ldflags="-m32" on amd64 to build usable libs
<geser> mvo: do you need some more tests/output for bug 385144?
<ubottu> Launchpad bug 385144 in apt "apt-get dies with "E: Method http has died unexpectedly!"" [Undecided,Confirmed] https://launchpad.net/bugs/385144
<mvo> geser: yes, it looks like its exiting with a signal but the debug output does not catch which one (yet) - could you please either run strace on the http child (if that is possible I image its pretty quick to open/close) ?
<Quintasan> hi
<geser> mvo: http://launchpadlibrarian.net/28621735/apt.strace I see there a EPIPE on a write near the end
<mvo> geser: thanks, let me look into the source to see how it fits there :)
<lesshaste> I've remove the /var/cache/debconf directory by mistake, how can I restore it? It makes apt-get install unhappy
<siretart`> lesshaste: wrong channel, see channel topic. btw, the answer is: restore from your backups
<lesshaste> ok
<lesshaste> thanks
<cjwatson> siretart`: FWIW, it's a cache ... he'd probably have to use debconf-loadtemplate or something to put a skeleton back together, but all he's really lost is some default answers to questions
<cjwatson> (and actually there's a debconf bug filed in Debian for the fact that debconf doesn't recover automatically)
<siretart`> oh? that's interesting. thanks for the note
<siretart`> does a similar bug also exist for apt?
<cjwatson> siretart`: I don't know
<glatzor> hello mvo
<mvo> hey glatzor!
<glatzor> mvo, I think that aptdaemon is now in a quite good state for uploading
<mvo> glatzor: I'm on my way for lunch, but I send you some mails
<mvo> glatzor: I did the upload this morning
<mvo> glatzor: I played with it too and its pretty cool
<glatzor> mvo, oh, I made some changes in today's train ride
<glatzor> mvo, but great!
<glatzor> mvo, enjoy yourself!
<mvo> glatzor: trunk is at r174 for me
<mvo> glatzor: or do you mean g-a-i changes?
<glatzor> now it is at 175 :)
 * mvo hugs glatzor
<glatzor> I converted the console client to gobject
<mvo> glatzor: I noticed, nice
<mvo> glatzor: I will upload that after lunch, but its going to take a bit to go through NEW anyway, so no worries
<tseliot> soren: if you added a patch to the bcmwl can you update its bzr branch, please? lp:~broadcom-sta-hackers/broadcom-sta/ubuntu
<tseliot> cjwatson: I still can't get my udeb to be used. Do you think something's wrong in my debian/control file? http://bazaar.launchpad.net/~albertomilone/+junk/product-check/files
<TheMuso> Gah, turns out the kernel patch that rtkit needs is not even in 2.6.31 yet, and yet rtkit docs say you need 2.6.31 or newer. Since we are at rc1, I would have thought that is what he meant. :)
<TheMuso> s/he/Lennart
<pitti> TheMuso: hm, and it doesn't work at all without rtkit?
<pitti> shouldn't it work at least as good as with 0.9.15 without rtkit?
<TheMuso> pitti: I don't know what happens without rtkit.
<TheMuso> I think pulse just won't work with realtime privileges.
<TheMuso> However the patch does appear to be in a tree that gets merged periodically into mainline.
 * TheMuso pulls the tree to see what branch the patch resides in.
<cjwatson> tseliot: I doubt your debian/control matters; surely it's more important what patch you're applying to debian-installer when rebuilding it?
<tseliot> cjwatson: patch? I only added my udeb to the binary_local-udebs directory of my project
<cjwatson> that's not sufficient
<cjwatson> you're expecting this to be used at d-i startup, right? before d-i gets round to loading any bits of itself from the archive?
<cjwatson> that kind of implies rebuilding d-i ...
<cjwatson> if you don't want to do that, I wish you'd said earlier, since I'd have suggested a different approach :)
<tseliot> cjwatson: yes so that I can abort the installation on some hardware units
<tseliot> oh
<cjwatson> therefore you have to rebuild d-i with product-check listed somewhere appropriate under build/pkg-lists/, maybe build/pkg-lists/base
<cjwatson> and then the contents of the product-check udeb will be embedded into the initrd as a result
<cjwatson> d-i's build process will have to be pointed at your archive
<tseliot> cjwatson: hmm... this is all I have in my project: https://pastebin.canonical.com/19272/
<cjwatson> something of all of that is an apt archive, right?
<cjwatson> anyway, I'm not going to debug your archive layout for you :-)
<cjwatson> just advising what would need to be changed
<tseliot> cjwatson: ok, thanks
<cjwatson> if binary_local-udebs (odd name) is an apt archive, it can be included in d-i's build process
<cjwatson> there's a sources.list equivalent around somewhere in there
<cjwatson> easiest is to just build it and watch the output closely, you'll pick up what's going on
<cjwatson> does mean that you'll have to deliver the updated initrd somehow
<tseliot> cjwatson: we use the bootstrap file (which acts like a sources.list)
<mvo> geser: *wehhh* I can reproduce the problem with apt-cacher-ng now :-D
 * mvo is happy
<geser> mvo: does apt-cacher-ng manage to trigger this bug because it can serve packages that fast?
<mvo> geser: not sure yet, but its delivering faster than squid for me
<mvo> geser: might be some odd problem with apt-cacher-ng as well, but whatever it is, apt should deal better with it :)
<mvo> wb glatzor
 * glatzor waves mvo
<glatzor> mvo, I just added some security features
<glatzor> mvo, won't using the md5sum of a package as identifier in the xapian cache instead of the package name help to only re-index "changed" packages?
<cjwatson> let's not use md5sums as unique ids
<mvo> glatzor: I guess what we need is something like that, a uniq hash so that we can identify what is new
<mvo> and only add that
<glatzor> mvo, or we could just store the hash as an attribut in the xapian document
<ogra> tkamppeter, are there any known bugs with HP 1018 LaserJet printers ? i havent printed for quite a while and just had to use a deskjet instead, the 1018 used to work, but now it doesnt on my karmic and neither on my girlfriends intepid
<pitti> ogra: how it doesn't work? detection? doesn't print at all? prints wrongly?
<ogra> doesnt do anything
<pitti> ogra: /var/log/cups/error_log?
<ogra> i can plug it in, it gets recognized
<pitti> ogra: ah, so you do see it in "lpinfo -v"?
<ogra> hmm, i have rebooted several times, the log only has four lines
<ogra> one sec, i'll go back and plug it in
<ogra> oh, fun, now xsane looks for scanners when i plug it in
<pitti> you mean it spawns xsane?
<ogra> yes, lpinfo sees it though
<pitti> that sounds like an ancient gnome-volume-manager test version
<ogra> well, i suspect its something with a driver update
<ogra> susie says it stopped around a week or two ago on her intrepid
<pitti> ogra: and evince or whatnot don't generate an error, it just disappears?
<pitti> that should be in the log then
<ogra> the printer fully works on windows
<pitti> intrepid! hmm
<pitti> we didn't do an update to intrepid recently
<ogra> yes, she uses intrepid, i use karmic
<ogra> well, she uses to wait for months with hers :)
<ogra> she doesnt like reboots so leaves u-m idle in the panel
<ogra> http://paste.ubuntu.com/208071/
<pitti> ok, no idea about drivers, I'm afraid; I'll leave that for Till then
<ogra> thats my karmic lpinfo
<ogra> looks fine to me
<pitti> indeed
<ogra> doesnt print a testpage though
<pitti> so this needs some error_log after a print attempt, I think
<ogra>  [02/Jul/2009:13:46:49 +0200] Resume-Printer: Unauthorized
<ogra> looks suspicious
<pitti> ogra: can you do "cupsctl --debug-logging", then print something, then "cupsctl --no-debug-logging", then put error_log somewhere?
<pitti> ah, the log is usually full of "unauth" stuff
<ogra> hmm
<ogra> after cupsctl --debug-logging the printer ui doesnt react anymore
<ogra> i cant click on "print testpage"
<ogra> i mean, i can but nothing happens
<pitti> lpstat -p has the job?
<pitti> sorry, lpstat; lpstat -p is printer status (also interesting)
<ogra> Drucker HP-LaserJet-1018 ist inaktiv.  Aktiviert seit Do 02 Jul 2009 13:50:39 CEST
<pitti> ok that
<ogra> no job, UI unresponsive
<ogra> i cant close it either
<pitti> fail
<ogra> oh, there was a popunder
<ogra> ogra@osiris:~$ lpstat
<ogra> HP-LaserJet-1018-58     ogra            153600   Do 02 Jul 2009 13:54:00 CEST
<ogra> ...
<ogra> Drucker HP-LaserJet-1018 druckt gerade HP-LaserJet-1018-0.  Aktiviert seit Do 02 Jul 2009 13:54:00 CEST
<ogra> it thinks the printer prints
<ogra> which it doesnt
<pitti> sounds like a hplip bug then
<pitti> ogra: do you have some stuff in error_log now?
<pitti> it should have the filter chain, etc.
<ogra> yep ... but also says it printed successfully
<pitti> ogra: I'd recommend opening a hplip bug with that error_log and lpstat stuff
<ogra> i can put it up, but there seem to be no errors
<ogra> ok
<ogra> will do, thanks a lot
<pitti> upstream reads them, too, and have a clue about hplip
<ogra> its a bit weird, until recently that was the most reliable printer in my house ...
<ogra> strange that it stopped working on all ubuntus here
<pitti> <IT crowd voice>Hello, IT, have you tried turning it off and on again?
<ogra> indeed
<ogra> various times
<ogra> and i removed it and left it finding itself on plugin etc
 * ogra thinks he did everythig a dumb user can do before digging deeper :)
<pitti> and today is not Tuesday, so it's not that infamous file bug
<ogra> heh, no, i thought that first when susie told me she couldnt print last week
<ogra> she though i'm kidding when i asked which day it was
<pitti> ogra: "Gewerkschaftlicher Feiertag" :-P
<ogra> lol
<liw> Tuesday bug?
<pitti> liw: bug 248619
<pitti> weirdest bug EVAR
<ubottu> Launchpad bug 248619 in file "file incorrectly labeled as Erlang JAM file" [High,Fix released] https://launchpad.net/bugs/248619
<pitti> liw: caused printing from OO.o to fail on Tuesdays
<Ng> that was a great bug :)
<liw> heh
<liw> pitti, thanks, I needed that as fortification before I slaughter a perfectly working desktop machine with dmraid
<TheMuso> liw: You have my sympathies.
<liw> TheMuso, thank you
 * liw is sure he saw a screwdriver somewhere, probably next to the phone number for emergency services
<TheMuso> lol
<lool> Hmm 2.6.31 oopses for me in the initramfs; it seemed to be acpi + i915 related but I can't find other reports, it surprizes me that nobody else is seeing that
 * ogra__ didnt upgrade the last 4 days ... i'll do and tell you 
<lool> I saw at least pitti boot that successfully on his laptop since he mentionned testing a patch on top of 2.6.31-rc1
<pitti> lool: right, working fine here
<ogra__> still 2.6.30-10-generic here
<pitti> lool: Mobile 945GM/GMS
<ogra__> PM965/GM965/GL960 here
<pitti> lool: if you can isolate it, please report a bug in bugs.fd.o against -intel, the guys are pretty responsive nowadays
<pitti> lunch, bbl
<ogra__> hmm, it wants to remove udev-extras ?
 * ogra__ just goes for it ...
<lool> pitti: Yeah, I've actually followed your bugs because they looked like mine and am trying two patches which they sent  :)
<ogra> ogra@osiris:~$ uname -r
<ogra> 2.6.31-1-generic
<ogra> all fine here after upgarde
 * ogra tries a suspend/resume
<ogra> perfect
<lool> Grumpf
<MacSlow> asac, ping
<MacSlow> asac, got a "moment"?
<seb128> grrrr
<seb128> what can be making load on a box and not been listed as using cpu in top for example?
<seb128> my laptop has a 3.65 load
<seb128> but nothing is using cpu in an obvious way
<MacSlow> nasty
<seb128> it's doing nothing I just have IRC running
<MacSlow> seb128, something in the kernel itself maybe?
<seb128> dunni
<seb128> dunno
<seb128> that's why I'm asking ;-)
<MacSlow> seb128, I assume stuff like top & Co only show user-space processes
<Laney> iotop?
<seb128> Laney, the disk doesn't seem to be busy it makes no noise
<seb128> hum
<seb128> 0.00 B/s   35.76 K/s  0.00 %  0.00 % gconfd-2
<walters> one thing to keep in mind is that top compresses threads by default, but each runnable thread contributes to load i think
<glatzor> mvo, hello. I will be offline now until sunday or saturday. see you! I just comitted some improvements to the console client
<mvo> glatzor: thanks, you rock
<mvo> glatzor: I look at bit into xapian now
<seb128> ok it's gconfd
<asac> MacSlow: ?
<MacSlow> asac, still/again wifi issues
<MacSlow> asac, not sure if it's a NetworkManager or ath9k thing
<asac> MacSlow: did you try backport-modules yet?
<MacSlow> asac, after pulling and plugging back in the ath9k PCMCIA-card I only results from "iwlist scan" for about 10 secs
<seb128> Laney, thanks, iotop has been useful to figure it was gconf being busy
<asac> MacSlow: try installing linux-backports-modules-hardy
<Laney> seb128: no worries, it's been useful for me in similar situations before
<alex-weej> anyone have any idea why a boat load of processes keep wakign up in karmic?
<alex-weej> it's literally frying my legs
<alex-weej> stuff like indicator applet has used 18 seconds of CPU time since about 20 mins ago
<asac> MacSlow: that might also fix your intel thing
<alex-weej> i am watching top and there are about 30 processes always running
<MacSlow> asac, rebooting with that... was missing from the 2.6.30-10 update
<alex-weej> and gconfd2 is going absolutely mental
<seb128> alex-weej, your issue is probably some application doing lot of gconf queries
<alex-weej> gconfd2 is just one of many processes going off a lot
<seb128> alex-weej, that's what I had some minutes ago, see the log
<seb128> restarting the session made things better ;-)
<seb128> not sure how to track easily what is talking to gconf
<seb128> one frequent issue is things being restarted in loop by gnome-session
<seb128> ie nautilus when not drawning the desktop or vino
<seb128> hum ok so probably a different one
<asac> MacSlow: huh? you are not on hardy?
<MacSlow> asac, I'm (need to be) on karmic
<ogra> MacSlow, karmic has .31
<alex-weej> seb128, looking at the process list, it seems everything gconf-using is running pretty much all the time
<MacSlow> asac, backports-modules was missing
<MacSlow> ogra, I know, but can't use that as it has broken KMS for my i965
<asac> MacSlow: ah. ok. still 3945 doesnt work for you?
<seb128> alex-weej, do you use compiz?
<ogra> hmm, works on my i965
<MacSlow> ogra, nothing really works for me
<ogra> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
<MacSlow> asac, yes the iwl3945 is very likely to be broken
<asac> MacSlow: i would really suggest to file a kernel bug and poke them directly
<MacSlow> ogra, under 2.6.31 my laptop doesn't even boot
<ogra> weird
<asac> iwl3945 is definitly supposed to work on .31
<alex-weej> seb128, killed gconfd2 and it stopped waking everything up
<alex-weej> all of the ubuntuone stuff seems to be constantly doing stuff though
<alex-weej> it's not even "connected"...
<tgpraveen> MacSlow: hi in karmic it is planned to suppress notify-osd bubbles which are non critical for fulsscreen apps.
<tgpraveen> so will empathy/pidgin msgs be critical or non critical?
<MacSlow> tgpraveen, that is the plan
<MacSlow> tgpraveen, notifications from apps such as IM-clients should be either low or normal... not critical
<tgpraveen> MacSlow: but that will mean that if i am watching a movie and my friend IMs me i will miss it till the movie completes. is this not a bad thing?
<tgpraveen> IM msgs, voice calls are all critical as they require immediate response unlike say emails. will there be a setting to change this atleas?
<MacSlow> tgpraveen, I don't think so
<MacSlow> tgpraveen, if it is urgent would be pinged again from your friend
<MacSlow> tgpraveen, besides e.g. watching a movie is also meant to set you state to "busy" or "unavailable" so your friend won't be surprised if you don't respond right away
<tgpraveen> MacSlow: well in many use cases i might be watching the movie while i wait for my friend to contact me. also i dont understand waht u say above
<tgpraveen> "he would ping again" even if he does then also no notification will come and hence wont have any effect
<MacSlow> tgpraveen, don't make the movie fullscreen then
<MacSlow> asac, you know what that's all about
<MacSlow> tgpraveen, btw.. you should be talking to the Design folks not me, regarding such issues
<tgpraveen> MacSlow: if a explicit do-not-disturb mode is there then i can understand no notifications but if i am say available status in IM then i guess my frnds would expect me t o reply
<MacSlow> asac, you know what that's all about http://people.ubuntu.com/~mmueller/nm-applet-wtf.png
<tgpraveen> MacSlow: oh ok should i mail to ayatana amiling list?
<MacSlow> tgpraveen, or bug them on #ayatana on this IRC-network
<ogra> MacSlow, stop connecting to japanese wlans !
<tgpraveen> ok.thx
<ogra> MacSlow, what font is that ?
<ogra> looks intresting
<asac> MacSlow: whats going on with the AP names?
<asac> do you get those bogus values from the driver?
<MacSlow> asac, how should I know
<MacSlow> asac, I only ever entered "linksys" (the one with the shield)
<MacSlow> asac, where's this list shown there stored?
<asac> MacSlow: wpasupplicant
<MacSlow> asac, that's a tool or a directory?
<smb> looks a bit like receiving trash and trying to convert into something
<smb> Definitely not the AP names I'd expect to see in Germany...
<smb> MacSlow, question would be if you get the same names with the iwlist scan
<jdstrand> didrocks: hi! so I found the 'quickly' project and had some trouble. I don't have time to work through all of it right now, but I did a checkout, then installed everything found in debian/control, did quickly new ubuntu-project ... and everything seemed to work. problem is that it told me to click a ui file to update the gui, but that didn't work. .ui wasn't associated with glade apparently, and trying to start it didn't work either
<jdstrand> didrocks: this is using jaunty bt
<jdstrand> w
<jdstrand> btw
<didrocks> jdstrand: hum, this seems more a glade issue. I will try it on jaunty this evening
<seb128> jdstrand, do you get glade used when clicking on a .ui in nautilus?
<jpds> MacSlow: In which branch has bug #337820 been fixed?
<ubottu> Launchpad bug 337820 in notify-osd ""Overshoot" animation on volume/brightness bubbles is triggered every time it's at 100%" [Medium,Fix committed] https://launchpad.net/bugs/337820
<didrocks> jdstrand: also, you can try "quickly glade" in the project
<seb128> jdstrand, hum in fact that's not supposed to be working apparently
<jdstrand> seb128: I didn't at first, but now am (weird)
<seb128> (which is probably a bug)
<jdstrand> seb128: oh, not weird, I think I told it to open with glade via the application chooser thingie
<jdstrand> s/am/is/
<jdstrand> regardless, opening glade and trying to open the .ui file explicitly didn't work either
<jdstrand> I got the following error: Failed to load ....ui. The following catalogs are unavailable: ...
<didrocks> jdstrand: thanks because we use .xml file for ours widget
<jdstrand> I'm a bit new to glade-- seems the catalog is the xml file? well, that xml file does exist
<didrocks> jdstrand: does the documentation tell to double-clic in a .ui file?
<didrocks> normally quickly glade what it has to do for you
<didrocks> +does
<MacSlow> jpds, trunk
<jdstrand> didrocks: after running quickly it starts the application, which has some text telling me to double click the .ui file to edit the interface
<MacSlow> jpds, I also have patched/updated g-p-m and g-s-d in my PPA
<didrocks> jdstrand: ok, I must ask rick to update it
<MacSlow> jpds, I don't know if those all made it into karmic's main repo yet though
<jdstrand> didrocks: quickly glade from within the directory worked
<jpds> MacSlow: Oh, I looked in the commit history and couldn't find a revision with it.
<jdstrand> cool
<jdstrand> so maybe it is just a doc update
<jdstrand> s/doc/template/
<MacSlow> jdstrand, maybe it's a duplicate I didn't mark yet and thus wasn't marked as fixed
<didrocks> yes. I will do it this evening and adding some stuff to quicklyl release
<didrocks> (doc update)
<MacSlow> jdstrand, sorry.
<MacSlow> jpds, maybe it's a duplicate I didn't mark yet and thus wasn't marked as fixed
<jpds> MacSlow: Oh, was it fixed in g-p-m trunk then?
<MacSlow> jpds, no... I only did a distro patch for it...
<tkamppeter> ogra, what does "hp-info -i -d hp:/usb/HP_LaserJet_1018?serial=KP08PCR --id" return (on your Karmic box)?
<ogra> tkamppeter, http://paste.ubuntu.com/208165/
<tkamppeter> ogra, it did not load its firmware. Can you run hp-setup -i
<ogra> one sec
<superm1> TheMuso, re skype + pulse, where'd you hear that? public sources somewhere? https://developer.skype.com/jira/browse/SCL-237 and https://developer.skype.com/jira/browse/SCL-271 were the only two public public bug reports I knew, and nothing appeared to have changed
<ogra> ah, it downlods something
<ogra> tkamppeter, works !
<tkamppeter> ogra, so on karmic only the firmware was missing. Can you try also on Intrepid? If there is no "hp-plugin" on Intrepid, please install hplip-gui and run hp-setup.
<ogra> will do, but my girlfriend is using the machine at the moment so that has to wait a bit
<tkamppeter> ogra, OK.
<kirkland> pitti: awesome, thanks.
<pitti> kirkland: I thought I already told you a couple of weeks ago
<pitti> 09 Jun 08 11:20:51  <pitti> kirkland: please drop /usr/share/hal/fdi/policy/10osvendor/10-kvm.fdi and /usr/share/PolicyKit/policy/org.freedesktop.hal.kvm.policy from  kvm, it's not used any more (hal deprecation)
<kirkland> pitti: heh :-)  yeah, sorry, it's been pretty crazy
<pitti> kirkland: is it just that, or does it have other hal integration which we need to convert?
<pitti> kirkland: no need to be, just wondering if that's complete, or whether we need to design more stuff
<kirkland> pitti: there was an lshal call in a reportbug.sh script -- i dropped that because i have apport hooks now
<pitti> it might need hal to detect USB devices or whatnot
<kirkland> pitti: i plan on uploading the new kvm today-ish
<pitti> kirkland: oh, that could just stay as long as it's ||true'd, to avoid delta (doesn't matter much)
<kirkland> pitti: i went ahead and dropped it
 * pitti pats https://wiki.ubuntu.com/Halsectomy
<kirkland> pitti: i dropped the .fdi as well as org.freedesktop.hal.kvm.policy
<kirkland> pitti: http://bazaar.launchpad.net/~kirkland-auto/%2Bjunk/qemu-kvm-packaging/revision/28
<pitti> kirkland: cool; it shold just be cruft, we disabled ACLs in hal a few weeks ago
<liw> TheMuso, are you still here? I have two SATA disks installed (and they work), but the J-Micron bios raid thing does not recognize them, and I think I've cycled through all possible configurations now -- any suggestions?
<superm1> pitti, bryce: so if xorg.conf is going to be fully gone by default, what do you guys think about shipping an xorg.conf inside xorg-driver-fglrx and nvidia-glx-* that diverts any user xorg.conf, and then puts it's own while the package is installed?
<superm1> that'd mean jockey wouldn't need to do all sorts of work mucking around with the xorg.conf in the first (common) place
<bryce> superm1, it sounds ok to me
<bryce> superm1, though I wonder if the user has configured input devices or something, if we'd still need jockey to do its thing
<superm1> bryce, oh hmm. what input device config stuff ends up in there?
<superm1> I thought that should have all been fdi files
<superm1> or whatever the successor will be in the new hal-less era
<ScottK> superm1: Just because it's not there by default, doesn't mean it's completely gone.  I think you need to take care not to muck up what a user has put there.
<superm1> ScottK, well you are more likely to have a successful boot when adding and removing one of those drivers if you give it a fresh start I seem to feel though
<pitti> superm1: in theory there's nothing that stops nvidia's postinst from doing the exact same python-xkit invocation than jocokey
<superm1> along the lines of bryce's comment the other day that "what cases do we still need bulletproofx"
<pitti> with the added benefit that it would work with apt-get
<pitti> right, I woudln't entirely divert it away
<pitti> just check "can I change this", and then change it inline
<ScottK> superm1: I can understand it simplifies the problem significantly, but that still doesn't make it OK to throw away user changes.
<superm1> pitti, well then perhaps checking if the file doesn't exist, adding in one, and taking note that you did so then, and removing it when you purge
<pitti> superm1: right, that's pretty much what jockey does as well
<superm1> ScottK, yeah that's why i was saying to divert it, user changes would still be there, and they could merge them at their leisure
<ScottK> Ah, that seems a bit user hostile to me.
<pitti> as a compromise, it could create a default xorg.conf (or change the standard boilerplate one), and if you have a custom one, do nothing
<pitti> that would still cover the common case
<pitti> and if you hand-crafted your xorg.conf, you won't need hand-holding
<superm1> yeah that sounds  somewhat more sane.  then you can still depend on having jockey do it's modifications if you had the custom one, and let the package ship and remove it's otherwise
<bryce> yeah that sounds safer to me as well
<AnAnt> Hello, I have a question that guys on ubuntu-motu weren't able to answer, it's regarding sl-modem packaging
<AnAnt> https://lists.ubuntu.com/archives/ubuntu-motu/2009-June/005910.html
<bryce> you're right that hopefully the majority of input device configuration no longer needs done through xorg.conf, but it seems there is often still random corner cases left
<AnAnt> can someone lead me to where I can ask about udev related stuff ?
<pitti> AnAnt: /join #udev
<pitti> (I hang out there as well)
<AnAnt> pitti: hmmm, ok, but did you read the URL ?
<pitti> AnAnt: oops, no
<didrocks> jdstrand: "quickly" creates a better initial ui file now (a recent commit introduced 6000 instead of 600 as width). I fixed also the welcoming message. If you want to test, you can bzr pull ;)
<pitti> AnAnt: I don't see why sl-modem couldn't ship a .rules file which creates those devices
<pitti> AnAnt: however, it seems weird to me that you have to do that in the first place
<pitti> AnAnt: usually, devices are created in the kernel in /sys
<AnAnt> pitti: even if I do that, there's something that needs to be done in the C code itself
<pitti> AnAnt: if there's no real device behind the /dev node, then it wouldn't make sense to have it?
<pitti> AnAnt: what does it need to do with udev?
<ogra> pitti, tricky if they are virtually attached to a serial port
<AnAnt> pitti: well, sl-modem needs a /dev/slamr (or /dev/slusb)
<pitti> right, but if you mknod a new device, then there needs to be a kernel driver behind it which does the actual open()
<pitti> isn't sl-modem purely an userspace driver?
<pitti> and if it does have a kernel portion, why doesn't this just register a device properly, so that udev will "just create" it?
<AnAnt> pitti: there are the slamr & slusb kernel modules
<AnAnt> pitti: well, it doesn't, I posted the udevadm output
<AnAnt> pitti: the problem is that Ubuntu doesn't want static devices to be created
<pitti> AnAnt: so you are saying that the kernel functions to register a device are GPL only?
<pitti> AnAnt: right, static devices are wrong
<AnAnt> pitti: well, that's what I understand from the current maintainers
<ogra> AnAnt, .rules can match on pretty much everything, your UEVENT has a DEVPATH=/bus/pci/drivers/slamr
<pitti> EXPORT_SYMBOL_GPL(class_device_register);
<pitti> oh
<AnAnt> pitti: well, I don't understand, if the code is 3-clase BSD, why does it have a problem with the GPL class_device_register function ?
<pitti> hm, then I'm afraid I don't really have a good answer here
<pitti> AnAnt: I don't know :/
<AnAnt> isn't GPL compatible with 3-clase BSD
<AnAnt> ok
<AnAnt> you think ubuntu-kernel guys can help ?
<pitti> I don't know, worth a try
<AnAnt> ogra: I hope that would help, thanks for the tip !
<pitti> ogra, AnAnt: but I don't understand that
<ogra> the udev side should be the easiest part :)
<ogra> pitti, i think it took ian several months when he enabled it forst
<pitti> how can a driver be legal to load, and bind to a major/minor, but not register a sysfs object to create the device automatically?
<ogra> *first
<ogra> it was never ported to sysfs support ?
<pitti> if that's a real limitation, then it's super-easy to circumvent with a custom udev rule, so that would be silly
<ogra> is it even alive upstream anywhere ?
<pitti> allegedly not
<ogra> right, thats the prob i suspect
<AnAnt> pitti: there's a long discussion in debian bug 354216 aboutit
<ubottu> Debian bug 354216 in sl-modem-source "upstream license patched in debian package" [Unknown,Closed] http://bugs.debian.org/354216
<AnAnt> I tried to understand, but it's really way above my head
<AnAnt> ogra: they just accept patches
<AnAnt> ogra: I mailed them the relevant patches of Ubuntu & Debian packages, and they accepted it
<ogra> right, but nobody actively forward ported the code
<AnAnt> ogra: nope, the old active developers don't answer emails
<ogra> my assumption is it was ported from 2.4 to 2.6 and then never actively developed to match teh new models
<ogra> static dev -> udev -> sysfs etc ...
<ogra> it kept only alive through hackish patches
<ogra> and workarounds
<AnAnt> yup
<AnAnt> and ppl still need it
<ogra> indeed
<AnAnt> ogra: do you know how to match this DEVPATH=/bus/pci/drivers/slamr in a udev rules file ?
<ogra> man udev ?
<AnAnt> pitti: btw, there is some workaround that the previous debian maintainer did that I don't understand
<ogra> shoudl describe it
<AnAnt> he done this: MODULE_LICENSE("Dual BSD/GPL");
<AnAnt> well, I would  understand if he done MODULE_LICENSE("BSD");
<AnAnt> but I dunno why he done it Dual BSD/GPL
<AnAnt> in upstream code it was: MODULE_LICENSE("Smart Link Ltd.");
<AnAnt> which is not a license, but rather a copyright holder
<AnAnt> so changing it to a license is what I can understand
<AnAnt> but I don't understand that he set it to BSD/GPL !
<pitti> AnAnt: perhaps to coerce the GPL checks for above exported functions to accept it?
<AnAnt> pitti: but wouldn't that be an illegal workaround ?
<pitti> that's what the bug was all about :)
<AnAnt> aha
<AnAnt> yet debian-legal seems to have accepted it
<pitti> I have no clue at all how EXPORT_SYMBOL_GPL works, though
<AnAnt> ok
<AnAnt> thanks guys
 * pitti is into code, not licenses..
<tjaalton> pitti, bryce, superm1: or we default to fglrx, nvidia on those if it's installed, and the fallback is the free driver (+ vesa, fbdev)
<superm1> tjaalton, yeah that would be even more ideal.  easy to do?
<tjaalton> superm1: quite easy
<pitti> tjaalton: right, wasn't that already a patch upstream, which got reverted later, and heavily disputed?
<tjaalton> upstream dropped one such patch, but said that it's up to the distros to do that kind of stuff
<tjaalton> pitti: yep
<pitti> TheMuso: FWIW, still no sound with latest pulse :(
<pitti> TheMuso: ah, mixer foobar, works now
<pitti> TheMuso: nicely udevified \o/
<soren> tseliot1: broadcom-sta branch pushed.
<tseliot1> soren: thanks
<ScottK> pitti: Would you please rescore kdebindings on armel.  There's a large number of packages waiting for it.
<pitti> ScottK: nudged
<ScottK> Where 4 is a large number.
<ScottK> pitti: Thanks.
<pitti> ScottK: in binary, it's very large :-P
<ScottK> Heh
<lool> pitti: BTW on the patch I mentionned earlier: Intel's patch fixed my suspend / resume issues and the Xorg hangs I was getting when the screen turned off too!  And the latest tree boots fine too, so all is fine basically
<pitti> lool: yay
<mathiaz> slangasek: hi - what's your opinion on providing slapd.scripts-common as standalone scripts so that they can be used by other things than maintainer scripts?
<ogra> doko, hulp
<pitti> cjwatson, Keybuk: this morning I did some i915 debugging and noticed that the screen gets disabled as soon as KMS loads _if_ i915 is not loaded from initramfs, but from normal udev init script (udevtrigger); in http://bugs.freedesktop.org/show_bug.cgi?id=19304#c88, Jesse pointed out that this is likely due to missing fbcon
<ubottu> Freedesktop bug 19304 in Driver/intel "[i945 FBC] spontaneous black screen (major pipe-A underrun)" [Major,Resolved: fixed]
<pitti> cjwatson, Keybuk: is that intentional, and did we commit to always load the driver from initramfs now? or a bug?
<ScottK> directhex: Mono may or may not be evil, but it's stopping kdebindings on armel.  Would you please have a look at https://launchpad.net/ubuntu/+source/kdebindings/4:4.2.95-0ubuntu1/+build/1101054/+files/buildlog_ubuntu-karmic-armel.kdebindings_4:4.2.95-0ubuntu1_FAILEDTOBUILD.txt.gz and recommend a solution.
<ogra> ScottK, i'm working on it
<ScottK> ogra: Thanks.  Would you please hit retry on kdebindings then when it's fixed ....
<ogra> ScottK, i'm just not sure how evil it is to just dump --with-gc=boehm into configure or what else that breaks
<ogra> thats why i try to reach doko
 * ScottK has no idea either.
<ogra> (apparetnly that fixes the build failure but switches off a lot other stuff)
 * ScottK wouldn't lose much sleep over drop mono bindings from KDE either.
<andersk> Is there a main sponsor available to ACK bug 394634?  It fixes quite a number of SSL servers that were broken in the last ca-certificates version.
<ubottu> Launchpad bug 394634 in ca-certificates "Sync ca-certificates 20090701 (main) from Debian unstable (main)." [Low,New] https://launchpad.net/bugs/394634
<ogra> ScottK, lucky you ... i'm committed to provite all of ubuntu-desktop on arm
<ScottK> ogra: I'd drop it period, not just on one arch.  We don't have and KDE stuff packaged that actually uses mono.
<ogra> yeah, we have f-spot, tomboy and soon banshee
 * ScottK vaguely remembers reading some mail list stuff and blog posts about that.  ;-)
<ogra> nah, you must be hallucinating :)
<ScottK> Wouldn't be the first time.
<directhex> ScottK, okay, give me a minute to beat meebey with a spoon
<ScottK> directhex: You did see ogra said he was working on it, right?
<directhex> ScottK, yeah. i think the fix is known, it just hasn't been uploaded yet
<ogra> directhex, funnily i dont see 2.4+dfsg-5 anywhere but on the ftbfs list ... how did it enter ubuntu ?
<directhex> ogra, it built fine on all non-arm arches
<directhex> ogra, upstream told us that some arch-specific flags were no longer needed - they lied
<directhex> let me check git
<ogra> right, i see that, but i dont see it on -cahnges or so
<vimpulse> hi all.  I attached a patch to https://bugs.launchpad.net/ubuntu/+source/partman-auto/+bug/94382 to change the string "Use the entire disk" to "Erase and use entire disk" two weeks ago.  Because the bug could be considered a data loss bug, could someone please increase the priority?  Or better yet, cjwatson or TheMuso, could you please review and commit the patch?  :)
<ogra> directhex, very likely --with-gc=boehm in ./configure ...
<ubottu> Ubuntu bug 94382 in partman-auto "[PATCH] "Use the entire disk" is unclear; please rename to "Erase and use the entire disk"" [Medium,Confirmed]
<directhex> ogra, yes, but only on arm
<ogra> directhex, and a dep on libgc
<directhex> let me check -3 which worked
<ogra> right, thats what i'm testbuilding atm
<cjwatson> pitti: we didn't commit to always loading it from initramfs, as far as I know
<ogra> directhex, that drops EABI support on ARM though, which we would like to have ...
<directhex> -4 even
<cjwatson> vimpulse: I don't consider it a data loss bug; please don't inflate issues. We'll look at it
<cjwatson> vimpulse: it needs translations so we won't rush it
<cjwatson> vimpulse: oh, heck, and it's on partman-auto - that really needs to go through Debian
<cjwatson> oh, but you patched ubiquity for it, ok
<vimpulse> cjwatson:  ok, I'm glad to know you saw the patch.  :)  What does "it needs translations" mean -- that it shouldn't be committed until the translators make up foreign-language translations?
<cjwatson> no
<cjwatson> it just means that it's not a panic-upload-immediately-to-everywhere-we-can kind of thing
<cjwatson> which is what "data loss" tends to imply
<vimpulse> cjwatson:  what are the steps before it gets committed?
<cjwatson> vimpulse: you've done everything you need to do, thanks
<directhex> i think http://git.debian.org/?p=pkg-mono/packages/mono.git;a=commit;h=86dceb1f4a0089e324b9bf2c2a998b7ebf79f597 broke it
<ogra> hmm
<directhex> ogra, can you try building it with the above change reverted?
<cjwatson> vimpulse: (btw, #ubuntu-installer is more appropriate)
<vimpulse> cjwatson:  thanks for the info.  Also, next time I have ubiquity-related questions, I will ask in ubuntu-installer.
<ogra> directhex, i will, i'm waiting for the --with-gc=boehm build to finish though since i dont want to have wasted that build time
<cjwatson> vimpulse: should be able to commit that tonight
<vimpulse> cjwatson:  excellent :)
 * ogra wanders away for a while while his arm board builds ...
<directhex> ogra, this looks like the only commit affecting arm between -4 and -5
<directhex> ogra, i think it might break kfreebsd though
<directhex> i'm sure you care lots about breaking kfreebsd on ubuntu
<ScottK> We do have a downstream that probably cares.
<gp_will_be_back_> hi
<directhex> ScottK, well, until Front Desk/DAM make the appropriate changes, -6 needs to wait on meebey. so reverting the above commit for a hurried -5ubuntu1 is probably the best plan for hurried developers.
<YokoZar> Plenary videos appear to be up!
 * ScottK looks at ogra then
<directhex> ScottK, generally though i'd be VERY hesitant to upload a boehm version
<ScottK> directhex: Well I'm just waiting for ogra to fix it.
<gp_will_be_back_> is there any way to find file count per directory
<gp_will_be_back_> is there any way to find file count per directory
<gp_will_be_back_> is there any way to find file count per directory
<ScottK> gp_will_be_back_: Knock it off.  Repeating the question will get you kicked.  It won't get you an answer.
<gp_will_be_back_> i am sorry scotty
<gp_will_be_back_> i guess u guys dont know the answer .......i should try perl or python channel
<Tm_T> gp_will_be_back_: repeating won't help there either, though
<gp_will_be_back_> hehe no need to repeat there
* christoph_debian changed the topic of #ubuntu-devel to: Archive: open | DebianImportFreeze in effect | karmic alpha-2 released | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support /j #ubuntu-motu 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
* christoph_debian changed the topic of #ubuntu-devel to: Archive: open | DebianImportFreeze in effect | karmic alpha-2 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
<billybigrigger> hey all
<billybigrigger> where can i find out more info on when the 2.6.31 kernel will be released to karmic for testing? as i don't think i can file bugs againts the .31 rc1 can i?
<cjwatson> sure you can
<cjwatson> it's the current kernel in karmic
<billybigrigger> dkms can't seem to install my vboxnetflt module for networking in vbox
<cjwatson> 2.6.31 won't be released to karmic until it's ... released upstream :-)
<cjwatson> oh, don't file the bug here though please, use the bug tracking system
<ion> cjwatson: Aww, no time travel for karmic?
<billybigrigger> so are we going to see 8 different release candidates like with the 2.6.30 kernel?
<cjwatson> billybigrigger: entirely depends on what upstream do
<cjwatson> they usually have a fair number of rcs
<billybigrigger> cool beans
<billybigrigger> cjwatson::: my bad
<billybigrigger> i didn't see this :P
<billybigrigger> Get:1 http://archive.ubuntu.com karmic/main linux-image-2.6.31-1-generic 2.6.31-1.14 [28.1MB]
<billybigrigger> i was using the .31 rc1 kernel from the mainline ppa
<cjwatson> ah, right, I understand your confusion now
<cjwatson> indeed, you wouldn't want to file Ubuntu bug reports about a PPA
<billybigrigger> yeah
<Sarvatt> billybigrigger: https://bugs.edge.launchpad.net/virtualbox/+bug/392314
<ubottu> Ubuntu bug 392314 in virtualbox-ose "vboxnetflt module fails to compile on 2.6.31-rc1 due to old the net_device api being removed." [Undecided,Confirmed]
<billybigrigger> Sarvatt::: thanks
<billybigrigger> ok so when will i see vbox 3.0 come through repos?
<orbitus> kvm and its unquestioned advantages aside, what is the state of xen on ubuntu? the hypervisor is included, the -xen kernel (rightfully) abandoned. however, there are many many people who want a xen+ubuntu combination.
<orbitus> is there any path at all which would result in a xen kernel included as a package so users neither have to go elsewhere or otherwise hit a wall?
<orbitus> this is a question motivated by pragmatism rather than any desire to start a heated discussion about whether one platform is superior to another
<TheMuso> superm1: Someone stated as much in one of the bugs on Launchpad, and gave a link to a thread/poll where the devs where asking what version of pulse to support.
<TheMuso> pitti: Good to hear.
<pitti> TheMuso: in the literal sense :)
<TheMuso> heh
#ubuntu-devel 2009-07-03
<billybigrigger> how do i find out when vbox 3.0 will be hitting repos?
<billybigrigger> is there anyway to track the status of it on launchpad or anything? or is it whenever an motu uploads it?
<ogra> ScottK, directhex, mono uploaded, the testbuild is still runing, but got far enough beyond the failure point that i'm confident it will get through
<billybigrigger> can someone help me out debugging a problem with my webcam and the new kernel?
<billybigrigger> it worked fine yesterday, now after upgrading to 2.6.31 today it doesn't work
<billybigrigger> Jul  2 19:31:39 cabo kernel: [11502.374422] gspca: usb_submit_urb [0] err -28
<billybigrigger> Jul  2 19:31:39 cabo kernel: [11502.398542] ohci_hcd 0000:00:02.0: leak ed ffff88003781f2d0 (#81) state 2
<billybigrigger> i get that from syslog when running cheese, the webcam light goes on...but just purple garbled screen
<billybigrigger> i looked up gspca on launchpad and see that gspca-source
<billybigrigger> Deleted in karmic-release  (Reason: (From Debian) ROM; mainlined in Linux >= 2.6.28)
<billybigrigger> so do i file a bug against the new kernel? or where do i go from here?
<TheMuso> billybigrigger: Filing a bug against the linux package for version 2.6.31 would likely be a start, yes, giving the dmesg stuff you quoted above.
<billybigrigger> no dmesg, just syslog
<billybigrigger> gonna start digging around in dmesg i guess
<billybigrigger> should i just attach my whole dmes and syslog?
<TheMuso> It would probably be better to attach the bits that seem relevant.
<TheMuso> c
<TheMuso> woohoo. LVM snapshots are broken with kernel 2.6.31.
<TheMuso> ...or I wonder if the format for LVM stuff has changed, which causes the breakage...
<liw> TheMuso, yo!
<TheMuso> Hi liw.
<liw> TheMuso, I failed to get my disks setup in a raid -- the bios raid configurator does not see the disks (they do work), whether I follow the manual's instructions or cycle through all combinations of all relevant settings -- any suggestions?
<TheMuso> The BIOS doesn't see them. Are they connected to the right ports on the motherboard?
<liw> they bios sees them
<liw> I can install ubuntu on them and the installed ubuntu boots, for example
<liw> the bios lists them in the post, etc
<TheMuso> Ah but you can't configure them as RAID?
<RAOF> Is there any particular reason to be using the bios raid configurator?
<liw> TheMuso, yes, exactly
<TheMuso> RAOF: He has been given the unfortunate task of maintaining dmraid.
<liw> RAOF, yes
<RAOF> TheMuso: You've managed to palm that off?  Sweet!
<TheMuso> liw: I think the jmicron controller operates in a few different modes. Either IDE, AHCI, or rAID, depending on the BIOS/motherboard manufacturer, and the available ports on the board.
<TheMuso> RAOF: I didn't manage to do anything. Since changing teams, it was reassigned to someone else.
<liw> TheMuso, yeah, that's one of the settings I've cycled through
<RAOF> So, I guess "why not just use md softraid" isn't an approprate response, then :)
<TheMuso> I know the jmicron controller on my gigabyte board does that.
<TheMuso> liw: You want it in RAID mode.
<liw> TheMuso, I've tried it in each mode, to no effect, alas
<TheMuso> RAOF: Try telling all those users out there who want to sit WIndows and Linux on a bad RAID setup. :p
<TheMuso> liw: When in RAID mode, you have to press a key combination during boot to get into the RAID configuration utility.
<TheMuso> Thats what I have to do with mine.
<liw> TheMuso, yup, control-j. no effect :)
<TheMuso> liw: What is the motherboard?
<TheMuso> i.e manufacturer etc.
<liw> Asus P5K
<TheMuso> Ok.
<TheMuso> One thing I found with mine is that for some reason, when the system boots, capslock is toggled on internally, although this is not shown, well not at least on my wireless keyboard. Prior to the key command neetding to be entered, try pressing capslock twice, then pressing control + J at the appropriate time.
<TheMuso> Mine is a gigabyte board, which I think I've already said.
<liw> that's... an interesting behavior
<liw> I'll try that
<TheMuso> Yes, it is.
<TheMuso> Thats what I had to do with mine.
<liw> unfortunately, doesn't help
<TheMuso> grrr
<liw> (I have a wired keyboard, though)
<TheMuso> you could try control + shift + j
<TheMuso> but other than that, I am out of ideas.
<TheMuso> Does the board also have an intel controller?
<liw> I thought that was it
<TheMuso> If so, I would suggest using it instead, as it also supports RAID, and is somewhat better supported by dmraid./
<liw> just went through everyting in the bios. the jmicron one seems to be the only one.
<TheMuso> Hrm ok.
 * TheMuso googles the mb to see what it has.
<TheMuso> liw: According to what I've found, it uses an Intel P35/ICH9 chipset, which means there is an intel controller. Let me reboot, and see what its called in my BIOS.
<TheMuso> brb
<TheMuso> lionel: The section you want to go into if you have it is "integrated peripherals", and the option you want is SATA/RAID AHCI controller mode, or something similar.
<TheMuso> sorry, liw ^^
<TheMuso> lionel: sorry, wrong person, tab completion caught me out. :p
<liw> TheMuso, I have "Onboard devices configuration" with "J-Micron eSATA/PATA controller" (changing it has no effect), and "SATA configuration" with "Configure SATA as" and the only option ever there is "IDE", no "RAID"
<TheMuso> hrm ok, no idea then.
<liw> TheMuso, I now realize that the J-Micron setting only says eSATA, so might apply only to external SATA drives anyway
<TheMuso> hrm thats possible.
<liw> and PATA drives, of which I have none anymore
<TheMuso> I guess you could go into Linux, and try and find out what controller your drives are connected to, but I think that means digging through sysfs.
<liw> i'll do that
<TheMuso> In other news, a fresh install of the latest karmic daily from the alternate disk on my notebook leaves me with no sudo access. :)
<TheMuso> 8/c
<liw> lshw shows the disks as being connected to the 82801IB (ICH9) 2 PORT SATA IDE Controller
<liw> and there's nothing connected to the jmicron one, hmm
<TheMuso> Right, I thought as much.
<TheMuso> SO there is probably an option in your BIOS to turn it into a RAID controller, but i can't help you as to what you are looking for.
<liw> if there is, it isn't in the bios menus...
<TheMuso> So the "configure SATA as" option didn't have other choices other than IDE? TO find out, you should be able to press enter to get a list of options.
<liw> that only shows IDE as the only option
<liw> aha, I found a SATA port on the motherboard for the jmicron contoller
<liw> a single port
<liw> which is rather less useful for raid than I would hope
<liw> aha
<liw> "Tho configure a RAID 0, RAID 1, or JBOD set, install an external Serial ATA hard disk drive and an internal Serial ATA hard disk drive connected to the onboard Serial ATA connector labeled SATA_E2."
<liw> that's... an interesting design decision
<TheMuso> liw: SOunds like you got one of the basic boards then.
<liw> yeah, it's very basic
<TheMuso> And it sounds like the BIOS is not letting you run the intel controller in either AHCI or RAID mode, or at least so far as you have found.
<lifeless> liw: fakeraid time :)
<lifeless> liw: welcoe to my world
<TheMuso> liw: Yes, he has been given the task of maintaining dmraid, now that I've switched teams.
<TheMuso> s/liw/lifeless/
<lifeless> TheMuso: WOO
<lifeless> liw: hehehehe
<liw> the manual claims the "Configure SATA as" setting has options "IDE" and "ACHI", but I only ever see "IDE"
<liw> no "RAID" documented, though
<lifeless> liw: are you looking at the ISM setup ?
<lifeless> liw: sorry, IMSM
<liw> what is that?
<lifeless> the firmware
<lifeless> which is onboard, not loadable
<lifeless> the intel raid implemenetation is 'Intel Matrix Storage Manager'
<liw> and where would I find that?
<lifeless> it has three modes for the sata ports that are run by intel. The jmicron ones are a different controller.
<lifeless> IDE - runs a vanilla IDE command set
<lifeless> ACHI - reports a different device ID, and runs with more scsi like capabilities
<lifeless> and RAID, which is ACHI + the ability to read raid sets from disk during boot - but as soon as the OS starts running controllers directly that gets sidelined
<lifeless> liw: typically in the BIOS setup
<lifeless> liw: there may be multiple options labelled and looking the same.
<liw> lifeless, well, gee, the discussion so far, since yesterday, has been concentrated on the fact that the BIOS does not have that
<lifeless> liw: yes, I get that.
<lifeless> liw: another possibility is that your Motherboard has had the option disabled by the vendor
<lifeless> liw: is SATA_E2 the jmicron port?
<liw> yes
<lifeless> then my bet is that you don't have an IMSM module in that machine build
<lifeless> and instead only have the jmicron fakeRAID facility
<lifeless> which I haven't worked with :)
<liw> that's the way it's looking, yes
<liw> oh well, I'll write this up and email robbie
<lifeless> what motherboard is it ?
<lifeless> the jmicron is a good one to be able to test too
<lifeless> its just probably not the most common one
<liw> Asus P5K
<liw> the jmicron controller is utterly useless for this, since it only has one SATA port (plus an eSATA port)
<lifeless> well, it will work
<lifeless> just have to have an external chassis too:P
<lifeless> which p5K specifically? deluxe? premium?
<lifeless> http://event.asus.com/mb/p5k/spec.html
<liw> buying more boxes not an option for me, though; I have way too much computer stuff already, and I'm getting ready to move...
<liw> plain P5K afaik
<lifeless> its missing the magical R
<lifeless> you need the ICH9R chipset
<lifeless> not ICH9
<liw> oh
<liw> thanks, that's useful information: now I at least know that I don't ahve the right chipset from Intel and don't need to look at that further
<lifeless> I was aiming for helpful :)
<liw> you often are :)
<lifeless> and checking my facts - http://en.wikipedia.org/wiki/I/O_Controller_Hub
<lifeless> I'm correct
<lifeless> none of the p5k's listed ICH9D*
<lifeless> oly ICH9/ICH9R
<lifeless> so ifyou have a plain p5K, its ICH9 and can't do intel matrix storage manager raid
<TheMuso> Which IMO is the better of the 2 controllers.
<TheMuso> I have not had the best time with jmicron controllers.
<TheMuso> But it does work well enough.
 * TheMuso has a gigabyte board with the same 2 controllers, with intel and jmicron both able to do RAID. I use the jmicron controller for my DVD drive, and intel for disks. :)
<dholbach> good morning
<pitti> Good morning
<dholbach> hi pitti
<pitti> TheMuso: my mixer level always start with 0 and muted after a clean boot; is that just me?
<Sarvatt> not just you
<Sarvatt> same thing here
<Sarvatt> http://pastebin.ca/1482735
<Sarvatt> its just pcm and beep in alsamixer getting reset to 0 every boot, master stays where it is
<TheMuso> pitti: is this 0.9.16?
<pitti> TheMuso: yes, but it also happened with 0.9.15
<pitti> TheMuso: http://pastebin.com/f41bc1413
<pitti> TheMuso: I think its an alsa problem, not a pulse problem (ICBW, no idea how pulse fiddles with mixers nowadays)
<pitti> -rw------- 1 martin martin 780252 2009-07-03 09:10 gvfs_1.3.1-0ubuntu3_amd64.deb
 * pitti appreciates bzr-buildpackage to keep my s3kr1t code really secret, but that's a little over-ambitious :)
<pitti> james_w: ^
<pitti> james_w: (in ../build-tree/ they are okay, but the copies in ../ are 0600 now)
<pitti> james_w: I'll file a bug later, just for amusement
<TheMuso> pitti: you could try removing /var/lib/alsa/asound.state, however you ahve to unload all modules for sound before doing so, so that a new file is created with fresh settings. I did a fresh install on my notebook today and am not having that problem, whereas I was with the previous karmic install I had on there.
<pitti> TheMuso: I'll check out today's live CD
<pitti> TheMuso: thanks; if it's just local bad state, it's fine
<StevenK> pitti: Which failed to build, since seb128 broke it with gdm
<pitti> oh, will look into it
<StevenK> gdm: Conflicts: fast-user-switch-applet but 2.24.0-3ubuntu1 is to be installed
<StevenK> pitti: ^
<pitti> ah, need to unseed
<StevenK> pitti: Should I do the same for UNR?
<StevenK> pitti: And would you mind sharing your thoughts on bug 395030, when you have a sec?
<ubottu> Launchpad bug 395030 in gnome-do "gnome-do can no longer restart machine" [Undecided,New] https://launchpad.net/bugs/395030
<TheMuso> pitti: If the touchpad on my notebook is not working, where should I start debugging that? I
<TheMuso> pitti: It will be Monday, but a pointer would be good.
<pitti> StevenK: seeds updated; if you use gdm in unr, you need to do the same (merge?)
<pitti> TheMuso: your sentence was cut off
<pitti> TheMuso: I'm not familiar with the synaptics driver, I'm afraid; ubuntu-bug xserver-xorg-input-synaptics is all I can give you :/
<Sarvatt> 2.6.31 got really touchy about touchpads huh? i need to add i8042.reset=1 ever since around 2.6.30-git13 on this aspire one
<pitti> TheMuso: do you see it in sudo lsinput at least?
<pitti> or isn't it even detected?
<chrisccoulson> StevenK - i wrote a patch to gnome-session to expose restart and shutdown methods over DBus
<chrisccoulson> you could use that :)
<pitti> TheMuso: if it is in lsinput, please check lshal whether it has input.x11_driver = 'evdev'
<chrisccoulson> StevenK - gnome-power-manager has nothing to do with shutdown or restarting now in Karmic
<pitti> StevenK: 395030> looks like it needs to call ConsoleKit instead?
<hyperair> chrisccoulson: then what does?
<hyperair> oh whoops
<chrisccoulson> pitti / StevenK - the issue with ConsoleKit is that the session is terminated without being torn down properly
<pitti> ah, so it does want to do that
<pitti> org.gnome.SessionManager.CanShutdown()
<pitti> org.gnome.SessionManager.RequestReboot()
<pitti> org.gnome.SessionManager.RequestShutdown()
<pitti> if you use gnome-session
<chrisccoulson> those are the ones:)
<chrisccoulson> but the Request*() methods are Ubuntu patches though
<pitti> uh? how does that work upstream then?
<chrisccoulson> without those, I don't know of any other proper way now for an application to shut down the machine and terminate the session correctly
<chrisccoulson> pitti - i don't know about upstream. i forwarded my gnome-session patch upstream, but I've had no comments so far
<pitti> then I don't know either, I'm afraid :/
<pitti> gnome-power-cmd reboot perhaps?
<chrisccoulson> hmmm, i wonder what that does
<pitti> (don't want to try right now, have editors open, etc.)
<chrisccoulson> pitti - is the plan to migrate everything to polkit-1 this cycle?
<pitti> chrisccoulson: as much as possible, anyway
<pitti> http://fedoraproject.org/wiki/Features/PolicyKitOne looks pretty good already
<chrisccoulson> thanks. yeah, i was just taking a look at that
<chrisccoulson> it seems polkit-1 really breaks shutdown/restart
<tseliot> soren: I've just noticed that your requested that you branch was merged into lp:broadcom-sta instead of lp:~broadcom-sta-hackers/broadcom-sta/ubuntu . Can you merge it into lp:~broadcom-sta-hackers/broadcom-sta/ubuntu , please?
<pitti> hm, does bluetooth obexftp browsing work for anyone else in karmic? I can pair, but then it just says "service not supported by remote device"
<pitti> ah, the G1 doesn't like obexftp, works fine with my old one
<vise> hi yall
<dunham> Hi all! I'm packaging a software that has a COPYING (GPL2) and copyright information, but some source files miss license headers. some of them only report the author name, others haven't copyright/license info at all. Is such a package acceptable in the archives? Should I ask upstream to fix it?
<liw> dunham, a) there's probably thousands of such packages in the archive already b) it's always good to politely ask upstream to fix that, since ambiguity in licensing does nobody good any good
<dunham> liw: a) ok. So, in case upstream is not that responsive, can I suppose archive-admins would accept it? b) indeed! hopefully he will address my points and make everything easier
<liw> dunham, I would expect the archive admins to accept it, yes
<dunham> liw: ok, good. Thank you!
<vise> Im compiling a set of files (around 30) and then linking them together using my own makefile. In order to speed up, I use -j2. But while it reaches the link stage, there are unfinished compilations which result in the linker not finding 1 or more object files. Is there some way I could tell make to do the linking after all the concurrent compilation jobs are over?
<liw> vise, do you have the target of the link depend on all the object files?
<liw> if so, make should do the right thing
<vise> Okay! I have no dependencies for the link step.. Adding all the object files as dependencies there should do the job... Il try... tyvm
<vise> works... ty @liw
<liw> you're welcome
<dholbach> kirkland: why do I have Private/THIS DIRECTORY HAS BEEN UNMOUNTED TO PROTECT YOUR DATA -- ...?
<cjwatson> TheMuso: don't suppose you have an installation log from that system that was left without sudo access?
<cjwatson> dholbach: run ecryptfs-mount-private?
<cjwatson> I think that file has some useful contents, even
<dholbach> cjwatson: I was just surprised - I never had that file before
<cjwatson> I don't know why ecryptfs unmounted it, just explaining how to get things back :)
<dholbach> right :)
<dholbach> thanks
<pitti> it's even supposed to be clickable in nautilus, isn't it?
<dholbach> hum
<dholbach> Jul  3 10:38:31 bert kernel: [   33.496877] Unable to allocate crypto cipher with name [aes]; rc = [-2]
<dholbach> Jul  3 10:38:31 bert kernel: [   33.496882] Error attempting to initialize key TFM cipher with name = [aes]; rc = [-2]
<dholbach> Jul  3 10:38:31 bert kernel: [   33.496885] Error attempting to initialize cipher with name = [aes] and key size = [16]; rc = [-2]
<dholbach> Jul  3 10:38:31 bert kernel: [   33.496888] Error parsing options; rc = [-22]
<dholbach> I have no idea what's going on here
<dholbach> pitti, cjwatson, kirkland: nevermind, it was entirely my fault and is too embarassing to tell :)
<pitti> dholbach: it was your dog, right?
<dholbach> no, Murphy's far too clever :)
<dholbach> ... to have an overeager clean up command running that deletes /lib/modules
<dholbach> lalala
<dholbach> anyway, it's fixed :)
<pitti> :)
<pitti> kees always does that for security
<dholbach> and good to see that Ubuntu runs stable enough without it
 * dholbach hugs y'all
<pitti> thanks to the kernel team for building in the most important stuff :)
<dholbach> that's fantastic, really
<pitti> i915                  208744  3
<pitti> drm                   192800  3 i915
<pitti> those are really the only two you can't really do without
<pitti> well, there's still wifi/sound, but if you are on eth, you indeed might not even notice
<Keybuk> pitti: having all that in the initramfs is temporary
<pitti> Keybuk: ok, so the fbcon issue is a bug then?
<Keybuk> what's the issue?
<pitti> Keybuk: try booting without an initramfs
<Keybuk> right
<pitti> as soon as udevadm trigger kicks in, and thus KMS gets active, screen goes black
<Keybuk> though I suspect that's the most minor thing that goes wrong if you boot without an initramfs ;)
<pitti> Jesse suspects that it's due to fbcon not being loaded
<pitti> Keybuk: why? works fine
<Keybuk> by stripping back the initramfs to only mounting the root filesystem and nothing else, we'll solve most of those in one fell swoop
<Keybuk> pitti: there's a whole bunch of modprobes in the initramfs that aren't duplicated outside
<Keybuk> fbcon is just one of them
<pitti> Keybuk: so it seems we need to duplicate that fbcon modprobe after the udevadm trigger, to make VTs work if KMS doesnt' get flipped on in the initramfs?
<Keybuk> no, we need to take the kms drivers back out of the initramfs
<pitti> together with fbcon then?
<Keybuk> right
<pitti> I know that this worked a few weeks back, but something in the last few weeks has broken it
<cjwatson> Keybuk: (optionally; they'll need to stay in in some cases)
 * ogra wonders what mvo broke on strace to make it ftbfs on arm :P
<ogra> hmmm linux/arm/syscallent.h contains funny code thats aparently supposed to make builds fail ...
<ogra> #if SYS_socket_subcall != 400
<ogra>  #error fix me
<ogra> #endif
<ogra> thats just mean
<pitti> well, it doesn't say #error MUHAHAYOUSUCK
<pitti> it looks intentional?
<ogra> yes, apparently
<ogra> but that means it will never build
 * ogra tries to find out why it was added
<Keybuk> cjwatson: the "need a password for the root filesystem" case only, surely?
<ogra> aha !
<cjwatson> Keybuk: yes
<Keybuk> cjwatson: which has the nice property of not booting without an initramfs anyway, thus pitti's bug isn't relevant to that particular case <g>
<cjwatson> quite :)
<pitti> Keybuk: well, my bug is not really about "boot without initramfs", it's about when KMS gets flipped on
<pitti> apparently "kms after fbcon" is the problem
<Keybuk> yeah, not 100% sure how to handle fbcon yet
<Keybuk> haven't done the necessary testing
<Keybuk> I guess it's needed, otherwise you won't have a console
<pitti> but booting without initramfs is a nice and easy way to test it temporarily
<Keybuk> so we'd need to load it at some point
<Keybuk> and then, as you say, does it need to be loaded before or after the kms module?
<pitti> Keybuk: ah, it has no modaliases indeed
<pitti> after
<Keybuk> easiest way is probably going to be to just add "depend i915 fbcon" to module aliases somewhere
<pitti> would it work to add it to /etc/modules?
<pitti> is that run after udevadm trigger?
<Keybuk> /etc/modules is before right now
<pitti> oh, ok
<Keybuk> and I tend to dislike adding hardcoded things there
<pitti> *nod*
<TheMuso> cjwatson: I do, I'll file a bug and throw them in there.
<geser> could someone please unsubscribe u-m-s from bug #386428. subscribed the wrong team
<ubottu> Launchpad bug 386428 in xom "Please merge xom_1.2.1-1 (universe) from debian unstable" [Wishlist,In progress] https://launchpad.net/bugs/386428
<pitti> geser: done
<TheMuso> cjwatson: what package is responsible for setting user groups? I'll file it against that with a tarball of the install logs.
<cjwatson> TheMuso: user-setup
<TheMuso> ok thanks
<cjwatson> TheMuso: if you could just attach syslog, please, not as a tarball
<cjwatson> /var/log/installer/syslog - I'm unlikely to need anything else
<TheMuso> oh ok
<cjwatson> (tarball => extra faff)
<TheMuso> yep
<Laney> I just full-upgraded and now have a GDM greeter displaying which I cannot interact with in any way :(
<Laney> didn't even restart...
<TheMuso> cjwatson: bug 395082 filed
<ubottu> Launchpad bug 395082 in user-setup "No sudo access after installing of Ubuntu amd64 from July 2 daily." [Undecided,New] https://launchpad.net/bugs/395082
<Laney> had to SSH in and kill it
<pitti> meh "branch linked" spam
<Keybuk> I've said this before, but one thing I love about Upstart is that in single user mode, I can run "start tty2" ;-)
<ogra> pfft, excessive use of terminals
<ogra> :)
<Xhema> can someone please fill me in on one thing?  is there any requirement for people to publish changes to open office? is the PO files? is there any requirement for them to publish the sources?
<pbn> Xhema: hi, better ask on #openoffice.org
<Xhema> thanks
<ogra> asac, my cursor keys and pgup/pgdn dont work on LP pages in shiretoko, is that LPs fault or shiretoko ?
<ogra> hmm, the do work but only after some time
<asac> ogra: i dont think its a 3.5+ dependent
<asac> seems to be lower down the stack
<ogra> hmm, k
<asac> i will use 3.0 for a while today to see if it happens there too
<ogra> but ou notice the same ?
<ogra> *you
<james_w> does anyone have a bug number for the "unable to mount external media in karmic bug"?
<james_w> I thought I remembered someone saying it was a known bug the other day
<james_w> people keep filing it against dbus because you get a DBus timeout error
<pitti> james_w: "the" bug? works fine here
<pitti> they might not have upgraded and don't have policykit-1-gnome yet?
<Laney> I was seeing it with my iPod the other day, but I cleverly managed to lose it... :(
<james_w> pitti: thanks, I'll ask
<Laney> phone mounts fine though
<ogra> works here as well
<james_w> e.g. bug 393306
<ubottu> Launchpad bug 393306 in dbus "Unable to mount location" [Undecided,New] https://launchpad.net/bugs/393306
<ogra> "to well" actually :)
<Laney> is it .31? I heard that there may be problems there
<amitk> liw: should binutils-static be in computer-janitor?
<PPDP12> Hi, how do I get started developing with Ubuntu
<PPDP12> Maybe like tutorials and stuff?
<PPDP12> I have Experience with Microsoft Programming
<ion> The topic would be a good start
<PPDP12> Topic?
<ogra>  /topic
<PPDP12> O ok
<ogra> uuuh, where does my fusa applet go with this upgrade ?
<ion> gdm provides it now.
<ogra> ah
<ogra> i just saw it being deleted
<ogra> as long as shutdown and reboot are still functional all is fine :)
<ogra> err
<ogra> now that was irritating ... ending up on a login screen in the middle of an upgrade
<pitti> amitk: FYI, latest gnome-panel brings back shutdown options in system menu
 * ogra trusts his system when it tells to need to reboot after upgrade and just does that 
<ogra> eeek
<ogra> so the gdm fusa forces me to look at mz face all the time
<ogra> !
<ogra> my
<ogra> where is mz kbd mapping gone _
<ogra> grr
<pitti> ogra: https://bugs.launchpad.net/bugs/395103
<pitti> most probably
<ubottu> Ubuntu bug 395103 in gdm "Gnome doesn't have my configured keyboard layout after login anymore" [Undecided,New]
<ogra> ha
<pitti> you can switch it back in gnome prefs
<ogra> zep
<ogra> err
<ogra> yep
<pitti> but really, US-layout is LOVE
<ion> pitti: Amen, brother
<Tm_T> is not ):
<ogra> depends what zou are used to
<pitti> well, if a German guy had invented LaTeX and vim, it wouldn't be
<ion> pitti: I only use the fi layout for typing Finnish language.
<pitti> (and C, and shell, etc.)
<ogra> zzyyy
<ogra> hmm
 * pitti watches ogra practicing
<ogra> doesnt switch on the fly
<pitti> and enjoy shift/alt-gr less /, \, =, `, etc. :)
 * ogra tries a re-login
<geser> ogra: don't forget to reset your keyboard layout after the re-login
<ogra> hmm, why does nothing happen if i click quit in fusa
<ogra> oh, nice it automatically pops up behind all open windows ... how convenient
<ogra> Ã¤Ã¶Ã¼yyzz
<ogra> ha
<Tm_T> Ã¥ Ã¸ Ã¦ too
<ion> âº
<pitti> â¥
<pitti> ^ ubuntu-love key
<slangasek> mathiaz: what things other than maintainer scripts do you possibly need that horrible shell library for?
<slangasek> mathiaz: also, if it was provided separately it would also still need to be embedded in the maintainer scripts
<mathiaz> slangasek: right - I was looking for a standard way to create a new db backend
<mathiaz> slangasek: for example I was writting a ldap-based project and was looking into testing it
<mathiaz> slangasek: in order to do so I needed to setup up my own ldap directory and started to rewrite all the code from the maintainer script in my testing suite
<slangasek> hmm, is it that you're specifically looking for debconf prompting as part of it?
<slangasek> otherwise I wouldn't think those scripts would make a very good base
<mathiaz> slangasek: I don't think so.
<mathiaz> slangasek: right - I was just looking for a generic way setup a directory
<mathiaz> slangasek: one of the idea I had was to get something similar to the postgresql-common package.
<mathiaz> slangasek: where you have generic commands to create a new postgresql cluster, etc...
 * slangasek nods
<mathiaz> slangasek: I also need something similar to setup the directory infrastructure we talked about at UDS.
<mathiaz> slangasek: in that use case I need to load an additional schema to support MIT krb5
<ogra> slangasek, arent you supposed to pretend 3 is 4 today too ? (go holidaying!)
<mathiaz> slangasek: and load a default DIT
<slangasek> you might be able to derive from scripts-common for this, but I definitely wouldn't install it unmodified given that everything in it is specifically targeted for maintainer scripts
<mathiaz> slangasek: it seems that these are functions that are already done in the maintainer scripts and was looking into a way to provide the same functionality outside the package
<mathiaz> slangasek: sure.
<mathiaz> slangasek: so I looked at it yesterday and tried to implement the same thing with puppet
<mathiaz> slangasek: I'm almost done now.
<mathiaz> slangasek: I was able to implement most of the functionality in puppet recipes.
<mathiaz> slangasek: thanks to the no_configuration debconf question which doesn't setup the package at all.
<mathiaz> slangasek: it's an interesting concept though.
<mathiaz> slangasek: and quite different from using shell/perl/python scripts
<mathiaz> slangasek: and I don't really know how this could be integrated since it would add a dependency on puppet
<slangasek> -
<slangasek> yeah, not keen on that idea :)
<mathiaz> slangasek: right. However providing most of the functionality from the script-common in a package would be good idea?
<slangasek> seems a reasonable thing to do if that's what you need
<ion> Puppet is quite painful when you need functionality it doesnât already offer. If the recipe syntax were an actual scripting language with a Puppet DSL, everything would be so much nicer. For instance, AFAIU, you canât do something as simple as âif <query augeas for something> then <tell augeas to do something> else <tell augeas to do something else>â without implementing your own âifâ structure separately within the Puppet Augeas module.
<mathiaz_> slangasek: hm - I got dropped from my wireless network
<mathiaz_> slangasek: did you add something after: < slangasek> seems a reasonable thing to do if that's what you need
<mathiaz_> ion: right - however that's the point of puppet: not having a scripting langage
<mathiaz_> ion: the great strenght is to have a DSL which is a descriptive language, and not a imperative language to express your configuration
<mathiaz_> ion: it requires a change of mindset though.
<mathiaz_> ion: and I also have to admit that I don't have enough experience with puppet - you may raise a valid point though.
<ion> I simply havenât found a way (changing the mindset or not) to make the augeas module do changes based on the result of an augeas query without hacking the module itself.
<mathiaz_> ion: right. Why not use templates instead of augeas then?
<mathiaz_> ion: I think augeas is a great piece of technology but I'm not sure about it fits exactly in the big picture.
<mathiaz_> ion: I think augeas is a great piece of technology but I'm not sure *where* it fits exactly in the big picture.
<mathiaz_> ion: what is your use case for augeas within puppet?
<ion> When i wanted an automatically updated list of IRC server IP addresses as a whitelist for identd, instead of just doing DNS queries in the recipe, i had to write a Puppet module to do the queries. And even that can only be used in some very specific places in a recipe, not as a generic construct.
<ion> mathiaz: Iâd like to query whether thereâs a â* hard nproc <anything>â rule in /etc/security/limits.conf and either add â* hard nproc 400â or replace the existing rule with that.
<ion> mathiaz: And the equivalent for * soft nproc
<mathiaz_> ion: right - wouldn't writting a fact to cover this be a solution?
<mathiaz_> ion: and then use a template to generate the correct line?
<mathiaz_> ion: the idea here is to *not* base the condition on the content of the limits.conf but rather on some environment facts
<mathiaz_> ion: (such as this is a developer workstation, http production server, etc...)
<ion> mathiaz: Whether limits.conf is touched by the thing would depend on a puppet manifest, but what i meant was âupdate â* hard nprocâ to 400 if a value already exists; otherwise add â* hard nrpoc 400ââ.
<ion> mathiaz: I should investigate http://wiki.opscode.com/display/chef/Home, perhaps itâs a worthy replacement for me.
<mathiaz_> ion: right. so what you wanna achieve in this use case is to have a line that says '* hard nrpoc 400' in limits.conf on every host managed by puppet?
<mathiaz_> ion: chef looks also promising - however it's a much younger project.
<mathiaz_> ion: the main difference with puppet is that it uses ruby to express the configuration rather than a custom DSL.
<ion> mathiaz: Iâd make it a module (âclass proc-limit { if augeas-something then augeas-something else augeas-something }â) and do âinclude proc-limitâ within certain nodes.
<mathiaz_> ion: some people think it's a good thing, others prefer to have a declarative langage to express configuration.
<ion> If i could use any Ruby constructs within the recipe, i could do the equivalent easily.
<mathiaz_> ion: why don't you use a template instead of augeas? if every system needs to the same line it seems to be the best option.
<ion> How about if another module also wants to touch limits.conf? The point of puppet modules is supposedly that they are reusable. :-P
<ion> My puppet module for changing limits would supposedly be usable by anyone else with an OS that has limits.conf. Their OS packaging could even have preset rules that my puppet module shouldnât touch.
<mathiaz_> ion: right. It depends what the other module wanna do. The other module could call proc-limit definition with the relevant options.
<mathiaz_> slangasek: so to summarize, having a slapd-common package seems to be a good idea?
<mathiaz_> slangasek: the use case I'm trying to solve is the following: I need to be able to setup a slapd with a back-ldap + pcache overlay + nssov overlay with just one command
<mathiaz_> slangasek: and another use case is: I need to be able to steup a slapd with a back-hdb + load schemas + load default DIT
<mathiaz_> slangasek: all done from another package than slapd
 * pitti uploads gdm with unbroken keyboard layout setting
 * geser hugs pitti
<pitti> cjwatson: ok, so two of the desktop RC bugs are fixed now \o/
<pitti> cjwatson: thanks for fixing autologin in the installer
<mathiaz_> pitti: hi - I'm looking at your postgresql-common package
<mathiaz_> pitti: to get some inspiration for something similar to slapd
<pitti> mathiaz: for multiple different instances?
<mathiaz> pitti: hm - not necessarly
<pitti> mathiaz: don't look too hard, it's Perl :)
<mathiaz> pitti: it's true that sometimes we need to dump the bdb database
<pitti> it was from the time when we didn't have Python in a defualt install
<mathiaz> pitti: when we upgrade from one version of slapd to another one
<pitti> (which is still current in Debian)
<mathiaz> pitti: hm - that was one of my questions actually - if you had to restart now you'd code in python?
<pitti> mathiaz: I guess yes; OTOH it keeps my Perl skills above "dead"
<pitti> and you get pretty far with perl-base
<mathiaz> pitti: right. I should talk to the debian maintainer team (ie slangasek)
<mathiaz> pitti: most of the functionality is actually already written in shell script as it's embedded in the maintainer scripts
<mathiaz> pitti: I'd like to extract these and provide them in a package (slapd-common) that could then be used by others things to setup different configuration of slapd.
<mathiaz> pitti: that's why I'm looking at your postgresql-common package.
<pitti> have a good weekend everyone!
<mbana> why does my screen flash when i'm in fullscreen mode?
<geofft> ogra, just out of curiosity, what caused your upgrade to make you end up at a login screen?
<geser> probably gdm
<sebner> it's definately gdm, here too ^^
<sebner> huhu geser :D
<geser> Hi sebner
 * geser has a gdm without the keyboard layout bug :)
<sebner> geser: /me in some hours too (updates) *hehe*
<lfaraone> dtchen: hey, could you help with https://lists.ubuntu.com/archives/ubuntu-sugarteam/2009-July/001098.html by any chance?
<mneptok> lifeless: woohaa NZ! - http://www.youtube.co.uk/watch?v=7-Mq9HAE62Y
<ion> Great, gdm killed the user session on upgrade.
<c_korn> why did gdm remove fast-user-switch-applet?
<ion> It provides it.
<c_korn> eh, I don't see any applet
<geser> c_korn: the fusa changes didn't yet got updated for the new gdm (as far as the changelog tells)
<ogra> yeah
<ogra> and the gdm fusa thats replacing it is just weird
 * ogra would really prefer if it wouldnt use his picture ... its strange to look at yourself on the panel all the time
<Sarvatt> gdm restarting the gnome session might be a nasty surprise for someone upgrading from jaunty :D
<Ng> Sarvatt: mine didn't restart, it switched me to a login screen, but my session was still running
<Ng> but it's still not ideal ;)
<Ng> imho we're always going to have problems trying to upgrade significant core compoenents of a running session
<Sarvatt> oh nice, mine completely restarted which i imagine would stink because it'd close the installer. i'm in the middle of upgrading an ibook from hardy to karmic so i'll see how that goes in a few hours :D
<Ng> release upgrades seem like highly suitable fodder for the "install updates on shutdown" idea :)
<Sarvatt> wish i could have just installed karmic directly, but hardy is the newest release i could get to install on this thing. of course i found a way to do it on intrepid mid hardy install though
<james_w> cjwatson: thanks for your post on subprocess_setup, fta2 just reported a bug caused by that and I never would have found the solution otherwise
<YokoZar> So what happened to gnometris in karmic?
<ion> On that note, why is there a âFreeCell Solitaireâ, which seems to be just âAisleRiot Solitaireâ in Freecell mode and without the mode selector? :-)
<YokoZar> ion: because Aislerot is very unhelpful at helping you find other forms of solitaire to play
<YokoZar> ion: select game doesn't give a preview or explanation, for instance
<lifeless> mneptok: classic
#ubuntu-devel 2009-07-04
<cjwatson> james_w: horrible little gotcha, isn't it
<james_w> yeah
<cjwatson> I was ... unimpressed when that caused several people's disks to be eaten
<ion> URL?
<james_w> ion: http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2009/07/02#2009-07-02-python-sigpipe
<ion> Thanks
<ion> Exactly what caused peopleâs disks to be eaten?
<james_w> ion: see the bug report
<cjwatson> ion: subprocesses that were doing partitioning and expecting to receive commands on stdin and send responses on stdout got rather confused when stdin/stdout went away
<cjwatson> and carried on merrily doing something random when ordinarily they would have received SIGPIPE
<ion> Heh
<james_w> what's the term for that phenomenon where you hear about something for the first time and then for a while after you find that you keep hearing about the same thing where you never noticed it before
<cjwatson> (I forget the exact details, mercifully, but that's fairly accurate as summaries go)
<james_w> ?
<james_w> it seems like this sort of bug should have a name
<cjwatson> that sounds like a species of confirmation bias although it isn't quite the same thing ...
<james_w> I seem to remember my neuroscientist friend saying that it had be studied and named
<james_w> like the "cocktail party phenomenon"
<cjwatson> I'm looking through http://en.wikipedia.org/wiki/List_of_cognitive_biases but can't see it; I'm entirely prepared to believe it has a name though and I just can't find it :)
<Ng> james_w: I think star wars summed it up better than so-called neuroscientists... "your focus determines your reality" ;)
<Ng> james_w: http://www.damninteresting.com/?p=417
<nellery> that's probably it
<nellery> wikipedia: http://en.wikipedia.org/wiki/Baader-Meinhof_phenomenon
<radix> I'm testing an upgrade to karmic and it's failing because of a dependency problem between various packages, and I can't figure out which package is at fault by reading apt.log
<radix> though the package that the upgrade tool is reporting as being unable to be installed is ubuntu-desktop
<radix> I'd like to file a bug, I just don't know where it should be filed
<radix> oh, I see stuff related to fast-user-switch applet and I see a change from pitti about FUSA dependencies on ubuntu-desktop recently. guess it's related.
<wgrant> radix: The new gdm breaks fusa. Remove fusa if you don't need it, or keep gdm 2.20.
<radix> wgrant: okay. is there already a bug filed about that? would filing one be valuable?
<radix> I just removed fusa and that removed ubuntu-desktop and UNR but the upgrade now seems to be working.
<wgrant> radix: It's known. It's even mentioned in the gdm changelog.
<radix> okay, cool.
<reduz> hi guys, i'm here just to ask how in your right minds did you allow pulseaudio in ubuntu
<reduz> keeps crashing randomly since a few versions, never been stable, and likes to use 20% cpu when opening sound with bufers < 1024 frames
<reduz> also
<reduz> removing it causes sound to no longer work
<slangasek> mathiaz: hrm, you want a separate package just for this?  not sure why /that/ makes sense.
<emgent> someone up with intrepid ?
<ogra> bah, where is Keybuks plenary talk on bootspeed http://video.ubuntu.com/uds/karmic/ doesnt have any plenary_4 videos :(
<tgpraveen> actually many videos seem to be missing
<ogra> tgpraveen, only plenary_4 o far (others are not supposed to be up yet)
<ogra> (others than plenary ones)
 * ogra wonders why xscreensaver resolves "gnome-session | xterm | x-window-manager | x-terminal-emulator" wrongly on the armel buildd ...
<ogra> somehow that tries to install gnome-session ... which fails on xserver-xorg
<ogra> hmm, it uses gnome-session on x86 too ... weird
<ogra> lamont, infinity, can it be that the armel buildd chroot doesnt use --no-install-recommends while the others do ?
<ogra> pitti, poke ...
<ogra> pitti, could the check for chroots in the hal initscript be moved to the reload action as well ? seems xserver-xorg deliberately calls reload from postinst now which makes installation in the armel builds fail (which in turn causes an FTBFS in xscreensaver)
<ion> liw: Hi. Any benchmark results yet? :-)
<maxb> doko: Hi, Vcs-Bzr in python2.6 points to a nonexistent branch in your namespace, can you tell me where to find the actual branch?
<maxb> jinja2 needs promotion to main in order to satisfy sphinx depwait, what do I do to report that?
<Ampelbein> maxb: follow https://wiki.ubuntu.com/MainInclusionProcess
<geser> bug 382692
<ubottu> Launchpad bug 382692 in jinja2 "Move python-jinja2 to main" [Undecided,New] https://launchpad.net/bugs/382692
<geser> maxb: ^^
<netsurf3> what boot system does jaunty use? initrd or initramfs?
<Nafallo> netsurf3: this is a develop channel. for support, please see #ubuntu
<netsurf3> i thought it was relevant
<netsurf3> nevermind
<nixternal> anyone have karmic rocking on a dell mini?
<nixternal> ooh, nomodeset does it :)
#ubuntu-devel 2009-07-05
<billybigrigger> i have a few questions im hoping someone from this channel can answer...
<billybigrigger> with the new 2.6.31 kernel, vbox 2.2.4 and its networking module has quit working...now i see that vobx 3.0 was released to debian testing
<billybigrigger> what are the odds i will see a vbox 3.0 package in repos within the next few days, and if not for a long time, is anyone working on a patch or workaround?
<billybigrigger> i've been digging around and can't seem to come up with a solution, short of downloading 3.0 from vbox's site, but i'd rather run software from the repos only
<Sarvatt> https://bugs.edge.launchpad.net/virtualbox/+bug/392314
<ubottu> Ubuntu bug 392314 in virtualbox-ose "vboxnetflt module fails to compile on 2.6.31-rc1 due to old the net_device api being removed." [Undecided,Confirmed]
<billybigrigger> no wonder searching for virtualbox didn't return that :P
<billybigrigger> Sarvatt, thanks a bunch
<billybigrigger> Sarvatt, ok it says fix released, would that be the patch included in that bug page?
<billybigrigger> or is there a fix coming in my updates
<billybigrigger> ?
<Sarvatt> it says fixed release for the upstream bug, the fix being the svn commit for 2.2.4 thats also in 3.0
<billybigrigger> ok
<billybigrigger> Sarvatt, its been awhile since i patched something
<Sarvatt> just save the patch in the bug to your /usr/src/vboxnetflt-2.2.4/ directory and patch -p1 < whatever.patch
<billybigrigger> patch -p1 > VBoxNetFlt-linux.c
<billybigrigger> ???
<billybigrigger> oh
<billybigrigger> ok
<Sarvatt> patch -p1 < patchname.patch
<billybigrigger> just have to save it in the dir
<billybigrigger> gotcha :P
<billybigrigger> thanks
<billybigrigger> billybigrigger@cabo:/usr/src/vboxnetflt-2.2.4/linux$ patch -p1 < net_device-2.6.31.patch
<billybigrigger> can't find file to patch at input line 4
<billybigrigger> Perhaps you used the wrong -p or --strip option?
<billybigrigger> nvm
<billybigrigger> i guess it patched
<billybigrigger> Sarvatt, now i have to get dkms to reconfigure the module right?
<billybigrigger> Sarvatt, or am i supposed to be patching dkms?
<billybigrigger> Sarvatt, ping
<Sarvatt> ?
<billybigrigger> i applied that patch, and build the network driver with dkms and installed it, rebooted the system and im still getting the same errors
<billybigrigger> i know this isn't a support chan...but you seem to be the only guy awake in the last few hours
<Sarvatt> no idea then, i'm sorry man :(
<billybigrigger> k no prob
<billybigrigger> stupid stupid
<billybigrigger> booted the wrong kernel
<billybigrigger> haha
<billybigrigger> and am i missing something or can you not restart the system from gnome anymore?
<billybigrigger> you have to logout back to gdm, and restart from there?
<billybigrigger> bug or feature?
<ion> The System menu
<billybigrigger> nope
<ion> Upgrade and re-login
<bk> I have a question, and this is kind of advertisement but not intended to be as its part of the question.
<bk> Im apart of a site called amahi, amahi.org, and we run a "home server software" ontop of distrobutions, currently the only one we have this working on is Fedora, and are working on a ubuntu version along with others. I dont know if any of the developers that are apart of ubuntu would like to help on this or not but its worth a shot to ask. Would any of the developers happen to be able to help out in getting amahi to work on dist
<bk> I am also sorry if I broke any rules or if this is not the place to ask this question.
<CarlFK> bk: this sounds more like you need a bunch of packages ...
<CarlFK> I am looking at http://www.amahi.org/apps
<bk> CarlFK: no, not applications, those are oneclicks
<bk> we can handle that
<bk> just to get amahi itself working on ubuntu
<bk> its more a home server solution for the end user
<CarlFK> im not seeing what "amahi" is then - kinda makes me think "linux distro"
<ion> âWe default to using home.com for your home DNS domain. That means your machines at home will be part of this DNS domain.â Ew, EBW!
<bk> CarlFK: honestly, it kindof is, but it runs ontop of other distros (atm fedora)
<CarlFK> bk: it is sounding like a package.
<bk> it is, you install the distro, then install amahi
<bk> basically we need to change amahi to work with fedora
<bk> oops
<bk> ubuntu
<CarlFK> ah... I bet you want #ubuntu-moto (packaging chatter)
<CarlFK> this #chan is more for what ubuntu is, not what runs on it.  you 'might' get some interest, cuz it is a nice project... but that would be pulling people away from ubuntu, which would make me grumpy :)
<bk> CarlFK: ahh ok, im sorry then, I dont want to pull anyone away from ubuntu, I would just really love to see this running on ubuntu (i dont particularly like fedora, always been a ubuntu lover)
<wasabi> I don't think you've really explained what it is, anyways.
<wasabi> Looks like a bunch of applications, some of which are already available in Ubuntu.
<bk> wasabi: its a home server software for the end users. Web based applications,  Ease of shares with different users in a household, backup solutions (from files to bare metal) and other sorts of things, can make it into a web server if wanted, mail server, etc. But easily for the non experienced users.
<wasabi> Heh. And some of the package descriptions on your site are the exact same as the ones in apt.
<wasabi> So is it any unique code, or just a bunch of software repackaged?
<bk> wasabi: as well as in yum
<bk> unique code
<wasabi> Not open, or?
<bk> yes, opensource
<geofft> it sounds like amahi is a couple of packages that depend on other packages from the distro (currently Fedora)?
<wasabi> So is it just a UI to install packages that already exist?
<wasabi> That's the question I'm trying to get at.
<wasabi> "What is it?"
<bk> wasabi: i stated what it is above
<bk> for the users that use WHS, they can use this as easy as that
<bk> WHS=windows home server
<wasabi> You stated what it is from a marketing perspective.
<wasabi> Not from a perspective one might expect to require when helping you figure out how to package it.
<bk> Well, its written in ruby if that helps, im not really the maker, just the outer shell, i really wanted to see if this is the right place
<bk> there are about 4-5 users that work on the code currently
<wasabi> Oh. Well. Probably -motu is better then.
<wasabi> But they'll ask the same questions I did.
<bk> k
<geofft> I still haven't figured out what it is, but my ears perked up because it sounds kind of like what we're doing at MIT, for adding to existing packages
<geofft> take a look at http://debathena.mit.edu/ - if that concept sounds like what Amahi is, I can point you at hoe we did it
<wasabi> geofft, from the ONE screen shot I can find on the Wiki, it looks like a web-ui that sets up various apps.
<wasabi> Like ebox.
<bk> geofft: no, the packages are "one click apps" where you go to say http://apps in the browser, it shows that list of apps, you click install, then its done, then you go to http://appname and it takes you to that application
<bk> you can use it anywhere in your home or if your vpn'd into your home, you can use it away as well
<geofft> If it involves adding configuration on top of existing Ubuntu packages, then some (a little) of our setup might help
<geofft> but obviously we don't have this web installer thing
<wasabi> Web installer thing already exists:  apt:// or something
<bk> ok
<bk> amahi installs like LAMP does
<bk> installs ruby, pearl etc as well
<geofft> LAMP on Ubuntu (and Fedora) is just installing the Apache, MySQL, and PHP packages.
<wasabi> So vague.
<bk> yes
<bk> its like a web serverr
<bk> but more user friendly?
<bk> if that makes since
<wasabi> I'm guessing you don't know much about it technically?
<geofft> if you get someone with a better understanding of the code to show up, we can probably help more :-)
<bk> the user does not have to worry about setting up mysql passwords and databases, along with other things
<bk> I can send the guy for this part on over, send him to #ubuntu-motu?
<wasabi> Does that guy have any questions, or do you?
<bk> he will have more than i will
<bk> i know that centos devel was not particularly interested in helping us
<bk> wanted to make sure before we came on over
<wasabi> Well, without a question to be asked, there's not much anybody can do to help you.
<bk> well ok
<bk> thanks for your time, he might drop into motu to ask random questions about bigger things if needed
<CarlFK> that was odd
<CarlFK> makes me feel better about my OT questions :)
<FFForever> whats up with gnome/gdm/xorg?, they keep dieing =(, and something about gnome/gdm having a login issue about starting something
<billybigrigger> gdm-simple-greeter
<billybigrigger> or something like that? i get that error upon login
<FFForever> yeah
<billybigrigger> yeah i don't know what thats about either
<FFForever> do u get x dieing randomly while typing?
<billybigrigger> nope
<billybigrigger> what do you mean?
<FFForever> x randomly dies and i get a gdm login screen =(
<billybigrigger> oh kicks you right back to gdm?
<billybigrigger> how about your logs?
<billybigrigger> anything weird?
<billybigrigger> Xorg.0.log?
<FFForever> not that i can see one moment
<FFForever> http://pastebin.com/f1dcaea8c
 * FFForever loves pastebinit
<pitti> ogra: sure, feel free to commit it
<jono> pitti, ping?
<pitti> hi jono
<jono> pitti, hey, actually Rick S is going to ping you
<jono> something regarding some Python bindings for CouchDB
<reknol> hi
<reknol> wont ubuntu handle  '?
<reknol> such as find . -name '*.txt' -exec ls -R '{}' ';'
<reknol> will ubuntu handle the '
<maxb> reknol: that's a support question, not development one. please respect the topic of the channel. Try #ubuntu
<reknol> k
<reknol> thx
<mnabil_> hello guys , i 'm writing ubuntu install preseed file , my question is how can i add a tasksel ( new one ) like server,standard ....etc. say i wanna add a task called mnabil . any idea how can i do that ?
<mnabil_> guys how can the install cd use tasksel, what is the name of the packages (udeb) ?
 * cody-somerville has fell victim to the GDM-doesn't-start-anymore bug. doh.
<yacoob> Hello. Do you know of any existing efforts to create ubuntu build environment under OSX?
<EvanCarroll> as in, a simple chroot?
<silidan1> what else besides the files in hom dir .asoundrc and company, and /etc/modprobe.d/alsa-base.conf , do affekt the routing of audio on ubuntu?
<silidan1> what else besides the files in hom dir .asoundrc and company, and /etc/modprobe.d/alsa-base.conf , do affekt the routing of audio on ubuntu 9.04?
<dtchen> silidan1: the only files that affect audio routing by default in Ubuntu are /usr/share/alsa/pulse*.conf.  the module-init-tools file does not actually affect it.
<silidan1> did you know that setting audio out trough system->settings->sound doesnt affekt ubuntus theme sound output?
<dtchen> silidan1: it's a known issue for 9.04 and won't be resolved in that release.
<silidan1> :O
<silidan1> so i should upgrade to 9.10 ?
<dtchen> silidan1: you do not need to unless you want tightly integrated GNOME controls. you can install and use pavucontrol.
<silidan1> nope i cant it only reports -5 no driver or so
<dtchen> silidan1: if you need assistance, that's more appropriate in #ubuntu or #ubuntu-audio-help
<silidan1> lol
<silidan1> noone could help me there
<dtchen> "there" meaning the former? i don't see any remarks from your nickname in the latter.
<silidan1> the former
<silidan1> will ask in ubuntu audio thanks for the hint
<ryanprior> When is the toolchain freeze for Karmic? We've got a GCC 4.4 regression that we're trying to pin down, and it would be great if we could get a patch in to Karmic's toolchain instead of having to patch around the bug upstream.
<maxb> ryanprior: I've never heard of Ubuntu having a specific seperate freeze for toolchain
<ryanprior> okay. I didn't know.
<billybigrigger> can someone explain to me maybe why webcam quit working in 2.6.31? or if this is a known issue? i can't seem to find any info on the topic
<balloooza> hi, dose anyone here know how to get the kernel source to compile (or install I guess) the vmware server (2.0.0) on jaunty, the kernel-source-devel appears to be gone
<c_korn> balloooza: http://packages.ubuntu.com/search?suite=all&section=all&arch=any&searchon=names&keywords=kernel-image you mean that?
<balloooza> c_korn: that says debian installer, is that right
<balloooza> c_korn: there is no such package for jaunty
<c_korn> balloooza: a kernel for which architecture are you looking for? debian installer is correct because ubuntu uses the debian package format .deb
<ajmitch> c_korn: usually for something like vmware, just the headers for the current running kernel are used
<balloooza> I think I found it, ubuntu-headers-genaric
<mrooney> dtchen: any ideas on how I might debug HDMI audio intermittently cutting out on Karmic?
<mrooney> it seems to drop a split-second once or twice a minute, though it continues to play through the laptop speakers just fine
<directhex> ooh, i wonder if karmic will give me working hdmi audio
<TheMuso> directhex: Possibly, since 2.6.31 pretty much has the latest alsa code available.
<TheMuso> directhex: However, only 2 channel PCM is possible currently, no AC3/7.1 PCM etc is possible.
<directhex> TheMuso, that'd be a start
<mrooney> directhex: it is working fine for me in Jaunty, this is actually a regression
<directhex> i get nothin' on my server box
<directhex> nvidia audio...
<mrooney> also I should file a papercut bug to rename the IEC958 switch to something more discoverable and enable visibility of it by default
<ajmitch> directhex: a server with hdmi audio?
<mrooney> otherwise almost no one is going to figure it out
<directhex> ajmitch, well, until i can afford a mythfrontend, it does that job too
<mrooney> any tips on a good initial package for the bug? pulseaudio? nvidia-glx-180?
<TheMuso> mrooney: thats a rather difficult thing to do, rename the IEC control.
 * ajmitch doubts it'd be anyway related to nvidia-glx-180
<TheMuso> mrooney: Probably alsa-lib, but maybe at the kernel level as well. But please bare in mind taht if its renamed, it will brea a lot of bits/.
<mrooney> really? you can't just change the name in the volume control to anything?
<TheMuso> mrooney: We could make the change somehow in the UI, but not in alsamixer, and by UI I mean GTK/QT.
<ajmitch> there'd probably need to be some set of mappings from hardware names to user-friendly names for the volume controls
<mrooney> yeah
<mrooney> I just mean rename it in the UI so a remotely normal person can figure out that they should enable it to get digital audio
<mrooney> currently the switch is even hidden by default
<TheMuso> mrooney: Right, you want to look at gnome-media then, although teh gnome-volume-control appet uses gstreamer, so you will have to see hwo those too communicate device volume controls.
<TheMuso> As for KDE, I don't know.
#ubuntu-devel 2010-07-05
<dholbach> good morning
<pitti> Good morning
<pitti> apw: "failed to upload" -- no idea; usually for a rebuild test we are just interested in the build logs and in the boolean result (builds/FTBFS); but in this case I think we actually want to keep the binaries and build a live CD out of it for testing the new toolchain
<ogra> james_w, are you up already ? all image builds are screwed atm due to mono hangining in NEW (and for omap4 it would be nice if linux-omap4 could be released too)
<pitti> I just NEWed mono
<ogra> pitti, thanks a lot ... could you do linux-omap4 too ?
<ogra> (was only renamed, should be all ok beyond that)
<pitti> ogra: you mean the meta package?
<ogra> yeah, the binary of that
<ogra> it was initially wrongly names linux-ti-omap4 ... our builders dont like that
<ogra> *named
<pitti> done
 * ogra hugs pitti 
 * pitti hugs you back
<smb> pitti, Is it you or cjwatson I would ask to accept Lucid kernel packages in the accept queue? It would be good to have this available in proposed as soon as possible.
<pitti> smb: "either", I suppose
<pitti> I did some 1.5 hours on SRUs on Friday; I'll do another round somewhere this week, but my OEM stuff piles up, I need to catch up there a bit
<smb> Ok. So maybe cjwatson then?
<smb> I would like to have that available for people in proposed as soon as possible
<cjwatson> I can have a look in a bit; I just started the day
<smb> There is a bigger hunk of ext4 in that (which is queued upstream stable as well). But running fs tests looked quite good with the patches
<smb> cjwatson, That would be great. Thanks
<cjwatson> smb: done
<smb> cjwatson, Great. Thanks
<Laney> how can I find out why binaries were removed for a package?
<Laney> presumably it was FTBFS but I'd like to confirm
<jpds> +publishinghistory.
<Laney> jpds: where?
<Laney> https://edge.launchpad.net/ubuntu/+source/lhs2tex/+publishinghistory please tell me where to click
<Laney> they were removed for lucid
<Laney> also, I assume that I'd have no trouble SRUing the fix?
<jpds> Laney: The source in dists/lucid/universe/source/Sources.gz but I can't see anything in the corresponding Packages.gz files.
<Laney> jpds: the binaries were removed. I don't know how to find out why as it doesn't appear in the publishing history :(
<Laney> anyway it does indeed FTBFS so I'll assume it's that
<dholbach> TheMuso: I just had a look at bug 601758 and bug 601754 , they look good to me, but it seems like instead of libjack* we'll have libjack-jack2d* soon - it might be worth for you weigh in as well
<ubottu> Launchpad bug 601758 in Ubuntu "[NEW] Please sync jackd-defaults (5) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/601758
<ubottu> Launchpad bug 601754 in Ubuntu "Please merge jackd2 1.9.5~dfsg-15 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/601754
<dholbach> (I don't want to break all the audio world :-))
<pitti> seb128: bug 600622  - first maverick retrace :)
<ubottu> Launchpad bug 600622 in inkscape (Ubuntu) "inkscape assert failure: inkscape: /build/buildd/cairo-1.9.10/src/cairo-surface.c:337: _cairo_surface_begin_modification: Assertion `! surface->finished' failed." [Medium,New] https://launchpad.net/bugs/600622
<seb128> pitti, yeah you! ;-)
<pitti> seems it's working
<pitti> seb128: I'm just glad that we don't have surprises like gdb breakage again
<pitti> I hope we can continue to use the lucid dchroots for a while
<seb128> right
 * apw notes update-manager -d 'upgrade' button has stopped working ...
<pitti> hm, it worked fine last Wednesday when I tested it for alpha-2
<soren> apw: How does it not work? I see it here, and I can click it, and the release notes (or whatever you want to call it) come up.
<soren> (On a current Lucid system)
<apw> soren, for me it says 'Could not find release notes // the server may be overloaded"
<apw> and refuses to do anything
<soren> Ah.
<apw> soren, though i seem to have functional networking ...
<apw> and the error is too quick to be a timeout
<apw> soren, occuring on more than one clean updated lucid boxes
<soren> No clue, sorry.
<mvo> apw: are you behind a proxy? is this lucid?
<apw> mvo, i have a local proxy (apt-cacher-ng) though i am told that update-managers python apt implementation doesn't use it, this is lucid
<mvo> apw: if you could mail/pastebin me the output of DEBUG_UPDATE_MANAGER=1 update-manager -d that would be nice
<apw> mvo, sure, its reporting a 403 on DevelReleaseAnnouncement
<apw> i'll confirm its not a local proxy thingy
<mvo> apw: oh, let me check
<apw> i seem to be able to open the URL it mentions on the same machine
<mvo> apw: odd, the permissions on the server look correct, let me check further
<apw> mvo, seems that update-manager is now using the cacher
<mvo> apw: do you have any auth proxy setup?
<apw> so i suspect it is its fault somehow
<apw> nope, no authentication on the proxu
<mvo> apw: aha, that makes sense. the latest lucid-proposed update-manager fixed a issue with the proxy usage
<mvo> apw: so the fix may now have broken your setup :/ if apt-cacher-ng does not support fetchting this file
<mvo> apw: you should see something in the apt-cache-ng logfile, no?
<apw> mvo, i am suspicious its not compatible with apt-cahcer-ng
<apw> 1278328920|O|135|192.168.0.61|
<apw> i suspect that usless file is to blame
<apw> s/file/line/
<mvo> yeah :(
<mvo> but it should work if you unset your proxy in the gnome environment, no?
<apw> mvo its defined in the /etc/apt/apt.conf.d/01proxy file
<apw> and only there
<mvo> aha, ok. that will be read by u-m
<mvo> a good alternative proxy is squid-deb-proxy ;)
<apw> mvo, i suspect one of us should work out how to fix it given its a common solution
<mvo> ok, let me have a look at the apt-cacher source
<apw> i suspect its fixable in the configuration
<mvo> aha, cool. if its that simple we should do a sru for this as well
<mvo> my knowldege of this package is limited
<apw> mvo, mine is too, other than it being very effective (till now)
<mvo> :)
<TheMuso> dholbach: Thanks, will take a quick peak now, but will have a more indepth look tomorrow morning.
<mvo> apw: it seems to have a whitelist for meta-release*
<mvo> apw: could you please try adding: "http://changelogs.ubuntu.com/ to ./usr/lib/apt-cacher-ng/ubuntu_mirrors ?
<apw> mvo, if i remove the ?xxx bit from the url it seems to work
<apw> mvo the file which is erroring is not fetched from changelogs ?
<mvo> apw: ohhh, the ?lang= bits?
<apw> yep, that may be triggering the borkage
<mvo> interessting
<TheMuso> dholbach: Actually, these two bugs are syncs and not merges, as they don't yet exist in Ubuntu. They can be brought in without issue. I'll take care of them now.
<apw> mvo, ok it does appear we can fix this by updating the VfilePattern
<apw> mvo, i guess i should file a bug and put the config update on it ...
<mvo> apw: please do
<mvo> apw: I'm happy to sponsor it
<apw> mvo, be good for me :)
<mvo> :)
<apw> (as it it will be good for me to do some non-kernel packages)
<apw> mvo, ok the ubuntu1 upload for apt-cacher-ng just shows someone mangling the source directly
<apw> mvo, should i consider making this a quilt package ?
<mvo> apw: yes, feel free
<apw> mvo, they have also mangled the Maintainer to XSBC-original-maintainer, doesn't that happen automatically ?
<cjwatson> in binaries, yes, but you're supposed to change it in altered source packags
<cjwatson> *packages
<mvo> apw: jus trun update-maintainer
<cjwatson> https://wiki.ubuntu.com/DebianMaintainerField
<apw> cjwatson, mvo, thanks for the clarificaiton
<apw> cjwatson, i am right in thinking that the default for a source 3.0 (quilt) format archive is to have the patches applied, so that its sensible and appropriate to add 'debian/source/format'  as a patch ?
<cjwatson> everything except for "as a patch"
<cjwatson> as in, you certainly should not have debian/source/format added by a patch under debian/patches/
<cjwatson> in general, debian/patches/ should patch upstream source, not debian/
<apw> cjwatson, ok, ... makes sense
<cjwatson> debian/source/format should just be added directly
<cjwatson> hm, my grub2 vesafb test would work better with a kernel that has vesafb built-in
<dholbach> TheMuso: one of them is a merge (missing build-dep in main)
 * cjwatson upgrades that vm
<apw> is there an incantation for making quilt work with a 3.0 format repository, i suspect i need to find the 'kernel engineers guide to debian packaging with quilt'
<cjwatson> apw: you need an incantation? :)
<apw> the patches arn't in the normal place, so i assume i need at lease QUILT_PATCHES=debian/patches
<cjwatson> oh, that
<cjwatson> apw: /usr/share/doc/quilt/README.source has a suitable .quiltrc
<cjwatson> and general advice
<cjwatson> the only weird bit is that after you check out a branch corresponding to a 3.0 (quilt) package with patches applied, you have to do a bit of fiddling to get it into a state where you can use quilt
<cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204 has the rune I came up with for that
<ubottu> Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open]
<cjwatson> but after that initial setup step it just works
<lool> cjwatson: hola
<apw> cjwatson, and one final Q [sic], is there a standard for the header of a patch ?
<lool> cjwatson: LP #600988 has a sync request for libxml2, per the email I've sent to ev and you last week; mind having a look and syncing?
<ubottu> Launchpad bug 600988 in libxml2 (Ubuntu) "Sync libxml2 2.7.7.dfsg-4 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/600988
<cjwatson> sure
<cjwatson> apw: http://dep.debian.net/deps/dep3/
<lool> apw: https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines
<lool> (links to DEP3)
<cjwatson> lool: done
<lool> cjwatson: thank you
<lool> cjwatson: I dont think you'd actually need my help, but just in case, if you see regressions in migration-assistant and would like me to update the libxml2, let me know
<lool> +flags
<Amto_res> 59100 Roubai
<Amto_res> sory **
<ploum> Hello
<ploum> could someone help me to find back the archive of the gobby files of last UDS (La Hulpe) ?
<ploum> I'm looking for one and cannot find it back
<ploum> thanks
<seb128> they are on gobby.ubuntu.com
<seb128> but the server crasher midweek and they lost some documents
<seb128> which one were you trying to get?
<ploum> hi seb128
<seb128> hey ploum!
<ploum> I'm trying to get gtg-desktop
<ploum> I had a copy but I lost it
<seb128> I don't have this one but maybe ask people who joined the session
<seb128> bryce might have a copy
<ploum> yep, I've asked on our channel but I wanted to know if there was some kind of "official archives"
<seb128> usually gobby.ubuntu.com has the documents but as said there was a crash during UDS and no backup for some of those...
<ploum> unfortunatly, gobby port is blocked here so I've to try from somewhere else
<ploum> thanks for the information
<ploum> I hope to do some productive work this summer :-)
<ricotz> hello, could a SRU admin have a look at this proposal - https://bugs.edge.launchpad.net/ubuntu/+source/docky/+bug/579049
<ubottu> Launchpad bug 579049 in docky (Ubuntu Lucid) "Dragging files to folders causes data "corruption"" [Undecided,New]
<ploum> how is life going on the gnombuntu side ?
<seb128> ploum, there is always lot happening on the GNOME side, especially atm with GNOME3 coming ;-)
<seb128> so busy but nice to see changes ;-)
<ploum> seb128: but those gnome 3 stuffs will be only for 11.4, right ?
<ploum> or will be 10.10 a ubuntu remix of 2.30 with some 3.0 libraries ? (like dconf and gsettings)
<seb128> we plan to update the platform this cycle
<seb128> so yes GNOME3 is for next cycle
<seb128> we will get dconf and gsettings in the default install this cycle though
<seb128> gtk3 should be in universe or maybe in main but not installed by default
<seb128> we decided to do the gtk2 to gtk3 transition on 2 cycles
<ploum> indeed, this will be a lot of work for you then !
<seb128> yes ;-)
<ploum> keep it up, we, users, appreciate it :-)
<seb128> ploum, thanks :-)
<cjwatson> apw: is anyone working on the fbcon handoff stuff for foundations-m-grub2-boot-framebuffer yet?  I'm approaching the point where I could test it
<apw> cjwatson, hrm .. not sure ... will find out
<cjwatson> ta
<apw> cjwatson, doesn't look like it, i am unclear as to the requirements there, is there some info as to what the hand-off kit even is (i am assuming thats the task)
<apw> https://patchwork.kernel.org/patch/19287/ <-- is it essentially that patch ?
<cjwatson> apw: I think it was linked from the spec wiki
<cjwatson> yes, that's the patch, although I listed it as "something like [that]" rather than that exact patch since I know there were comments on it
<apw> mvo, ok ... i think i have put together patches and updated source packages for apt-cacher-ng they are on chinstrap:~apw/upload/sign ... apt-cacher-ng-DevelReleaseAnnouncement* are the debdiffs ... perhaps you could review and tell me how bad they are
<apw> cjwatson, cool ... yeah i can see the patch needs some love, but thats the missing functionality
<cjwatson> apw: regarding Alan's comment we should of course note that we *do* want to use the vt layer
<killown> hey ubuntu developers new bug here http://paste.pocoo.org/show/233756/  after execute help('modules') on python interpreter it enable compiz
<kaushal> hi
<kaushal> Please guide me about my post on https://lists.ubuntu.com/archives/ubuntu-server/2010-July/004402.html
<apw> basically this is about doing a PXE install but wishing to end up with a server kernel installed ^^
 * ogra bets there is a preseed value one can set
<apw> ogra, that email thread does talk about a preeseed.  kaushal says "i am using a kickstart ks.cfg not preseed" though i am unsure of the specifics
<ogra> hmm
<elmo> d-i base-installer/kernel/linux/extra-packages-2.6 string
<elmo> d-i pkgsel/include string linux-image-server
<ogra> perfect ;)
<elmo> is what we do, FWIW
<ogra> not sure how that translates into kickstart though
 * apw has no clue as to how or why we seem to have two methods to essentially control the install
<ogra> apw, kickstart is redhat's way of using preseeding
<ogra> d-i is (or at least once was) supposed to be able to translate such files
<apw> well indeed, but as this is an ubuntu install its not obvious how that relates ...
<ogra> into preseeding
<apw> ahh i see
<ogra> but i have no clue how well that works or if its still supported ... i remember it was introduced around dapper timeframe
<un214> I just discovered /tmp isn't ramdrive/swapdrive anymore. Intentional?
<cjwatson> still works and is still supported
<ogra> great
<cjwatson> un214: never has been by default
<apw> cjwatson, can you do a kernel switch via the kickstart form ?
<ogra> so the var or value the user uses might be wrong
<un214> was in jaunty when I first installed
<apw> preseed --owner gdm shared/default-x-display-manager select gdm
<apw> https://help.ubuntu.com/7.04/installation-guide/i386/automatic-install.html
<cjwatson> apw: the preseed in the post above should work fine; it looks like kaushal just needs help in using preseeding at all
<apw> kaushal, those docs imply you might be able to use 'preseed' to do the same things
<cjwatson> oh, and yes, you can use 'preseed' to drop down to raw preseeding from ks.cfg
<cjwatson> kaushal: so you want this in ks.cfg:
<cjwatson> preseed base-installer/kernel/override-image string linux-server
<cjwatson> un214: I don't know how you installed, but I maintain the Ubuntu installer and we have never put /tmp on a RAM-based filesystem
<cjwatson> by default
<kaushal> ok
<kaushal> cjwatson, ok
<kaushal> shall i pastebin the ks.cfg file ?
<kaushal> cjwatson, where exactly i need to put that line ?
<un214> maybe I installed by cloning the livecd
<cjwatson> kaushal: no need to pastebin.  just put it anywhere in the main section of the file (i.e. not %packages or %pre or %post)
<cjwatson> where you'd put commands like 'url'
<un214> that would certainally explain it
<kaushal> cjwatson, just after the url ?
<cjwatson> kaushal: no, on a line by itself
<kaushal> ok
<cjwatson> kaushal: just in the same section as all that stuff
<kaushal> cjwatson, so that line will tell the installer to install server kernel ?
<cjwatson> kaushal: yes
<kaushal> great
<kaushal> Thanks
<kaushal> and run the kickstart as it is
<kaushal> I mean using pxe boot
<apw> kaushal, i would suggest giving it a try
<kaushal> cjwatson, sure
<kaushal> Thanks a lot
<kaushal> will try and update apw and cjwatson
<kaushal> appreciate it
<Daviey> cjwatson, Can D-I be made to try to automatically obtain dhcp leases, trying all interfaces until it succeeds?
<apw> who does one subscribe to a bug for sponsorship these days ?
<pitti> apw: ubuntu-sponsors
<cjwatson> Daviey: sorry, I don't know - I suspect not
<Daviey> cjwatson, :(, thanks
<apw> pitti, ta
<cr3> when a release has an end of life date marked as "Month Year" on wiki.ubuntu.com/Releases, is that the 1st of the month, the last of the month or somewhere in between?
<cr3> nevermind, there are more specific dates provided lower on the same wiki page
<andrusk> "/format pubmsg_channel {pubmsgnick $3 {pubnick $[-9]0}{msgchannel $1}}$2"
<tseliot> seb128: your last upload of cairo makes chromium tabs disappear (if you have something like 130 tabs)
<tseliot> seb128: maybe rebuilding chromium against the new cairo will fix it
<seb128> tseliot, I've no clue about chromium but could be similar to bug #
<seb128> https://launchpad.net/bugs/601494
<ubottu> Launchpad bug 601494 in chromium-browser (Ubuntu) "Favicon in tabs appears as a flickering square while page loads" [Undecided,Confirmed]
<seb128> tseliot, ^
<seb128> tseliot, cairo upstream said chromium is buggy in its cairo use though
<apw> cjwatson, this fbcon handoff thingy ... does the kernel need to be in a PPA or will a .deb do you ?
<cjwatson> apw: .deb is fine
<cjwatson> I'll just be shoving it in a VM
<tseliot> seb128: my issue i different, all tabs are invisible if there's too many of them with the latest cairo
<tseliot> seb128: not just the icon
<tseliot> icons
<apw> cjwatson, ok cool ... i've gotten the raw patch applied and building, so i'll get you some .debs shortly.  my quick testing here showed it would boot, but as the screen is clear i cannot tell if its doing anything
<seb128> tseliot, ok, dunno then
<tseliot> ok, I'll investigate the issue
<cjwatson> apw: I'll CC you on the GRUB patch I'm about to send
<apw> nice thanks
<apw> cjwatson, i can see why upstream went 'ick' on this patch... it seems to conflate about 4 things in one
<cjwatson> apw: oh, I'm not saying I want *that* patch
<cjwatson> I want something that will let fbcon use existing framebuffer contents rather than clearing it
<apw> cjwatson, indeed, plan is 'give you that patch' and see if it does what you wanted semantically
<cjwatson> doing it as a config option certainly seems nuts
<apw> if so, pull it appart and clean up the bits etc.  i think this patch represents about 3 different module parameters
<cjwatson> I wonder if it should be done using the flags word that's currently used only to set initial cursor state
<apw> cjwatson, yeah i suspect either that or the 'logo' one
<cjwatson> global_cursor_default
<apw> but i am hoping this one touches all the bits you need, hense just slamming it in for a quick test
<cjwatson> f6c06b6807ff9281295989ebad72523865325a4f introduced the nocursor flag, together with a matching module parameter
<cjwatson> I quite like the approach of exposing it both ways like that
<cjwatson> flags are better for bootloaders that are already programming the boot parameters structure; module parameters are better for users
<seb128> ricotz, hi
<seb128> ricotz, you maintain the gnome-shell daily ppa right? would you be interested to help maintaining the official version as well?
<un214> ubuntu works just fine in a chroot jail -- all I need are bootscripts right?
<ricotz> seb128, hi
<seb128> ricotz, do you have any change to get libmozjs to work?
<seb128> ricotz, I would welcome patches for that for the maverick build
<ricotz> seb128, yes , jcastro asked me awhile ago
<seb128> it fails right now but I don't really have time to debug it
<ricotz> seb128, yes, g-s needs a patch for xulrunner
<seb128> I guess you had the same issues in the ppa and solved then by some way
<ricotz> seb128, is maverick going to ship gobject-introspection 0.9?
<seb128> ricotz, can you send me the change or open a bug with it or work on a debdiff?
<chrisccoulson> what fails at the moment?
<seb128> chrisccoulson, gnome-shell
<chrisccoulson> i suppose i should fix that really ;)
<seb128> chrisccoulson, I guess some ld_preload missing for libmozjs somewhere
<seb128> but I don't know if it's a gjs or gnome-shell issue
<chrisccoulson> oh, that's a gjs issue
<seb128> ricotz, dunno really, does it requires gtk3 or changes in libraries?
<chrisccoulson> it just needs rebuilding against the latest xulrunner
<chrisccoulson> gjs is still looking in the old location for mozjs
<seb128> hum
<ricotz> it is an g-s issue, there are some changes to the makefiles needed
<ricotz> not gjs
<chrisccoulson> ricotz - gjs has a rpath pointing to the mozjs location
<ricotz> of course gjs needs to be rebuild on every xulrunner release
<chrisccoulson> which breaks every time we do an upload
<seb128> chrisccoulson, gjs built with 1.9.2.6
<chrisccoulson> hmmmm :-/
<seb128> chrisccoulson, I think we have several issues there
<seb128> I really hate g-s for using gjs and not webkit ;-)
<chrisccoulson> we have 1 issue - that gnome-shell is using spidermonkey ;)
<ricotz> seb128, gobject-introspection bump the version to 1.1 which breaks every gir dev build
<seb128> chrisccoulson, http://launchpadlibrarian.net/51410657/buildlog_ubuntu-maverick-armel.gnome-shell_2.31.2-1_FAILEDTOBUILD.txt.gz
<seb128> ricotz, well for now I guess we have no issue
<seb128> ricotz, I know gobject-introspection format changed but I'm not sure what implication it has, it upgrading would force us to upgrade other components, etc
<ricotz> seb128, if g-s going to depend on gjs 0.8 it will be a problem
<chrisccoulson> oh, does it try to run gnome-shell during the build?
<seb128> chrisccoulson, I'm not sure, I've not tried to understand what it does yet
<seb128> ricotz, ok, one thing at a time
<chrisccoulson> yeah, it looks like it. it's just missing a LD_LIBRARY_PATH somewhere
<seb128> ricotz, could you send me your g-s build patch at some point when you have time for it?
<ricotz> seb128, http://paste.pocoo.org/raw/233809/
<seb128> ricotz, can you drop me an email with that diff or open a bug?
<seb128> will make easier for tracking, thanks!
<seb128> ricotz, or don't bother, I will try to do that today
<seb128> ricotz, hum, gjs 0.8 will require a new gobject-introspection then?
<ricotz> seb128, yes gjs-git doesnt build with 0.6.14
<seb128> do you know what debian plans to do?
<ricotz> sorry, no
<seb128> I need to understand what they change
<seb128> and what impacts that will have on the versions we need to ship
<seb128> since we will not ship gtk3 this cycle
<ricotz> this needs many changes
<seb128> well there is the update
<seb128> and the rebuild of all the packages shipping a gir
<ricotz> for example, gtk+2.0 ships a precomiled gir version 1.0 which break the build with a gir 1.1
<seb128> with corresponding build and packaging change for the abi version change
<ricotz> yes, i guess it need a bump the names to gir1.1-PACKAGE
<seb128> would it be easy to have a gir 1.1 compatible gtk gir on 2.22?
<ricotz> seb128, i hope it is, i am trying to do this in my ppa
<seb128> ricotz, ok, let me know how it goes
<ricotz> seb128, i think for gtk+2.0 needs a "autoreconf ..." like gconf has
<seb128> gtk has an autoreconf patch
<seb128> it needs to be updated if you do changes to the makefiles or configure
<ricotz> yes, but i doesnt rebuild the gir file
<seb128> well then we would need to update the copy
<seb128> or to make gtk build its gir
<seb128> could you try to figure if upstream plans to update gtk 2.22 gir to work with the new abi
<ricotz> yes, this is what i will try to do
<seb128> thanks
<ricotz> i might do this
<seb128> I will think about the transition to the new gobject-introspection
<seb128> I will keep you updated on what we do
<ricotz> seb128, so atk, pango and so on needs updates too
<seb128> but we will not hurry into it
<seb128> I need to understand the number of changes involved
<seb128> and if that will lead to something stable in this cycle
<ricotz> seb128, the transition back from the centralized gir build in gir-repository leads to this problem that now every package needs be updated with such a change
<seb128> well I'm fine doing that work
<ricotz> seb128, is there progress in packaging gtk+3.0?
<seb128> I just want to be sure it doesn't force us to pull gtk3 in or something
<seb128> ricotz, not that I know no, it's not a priority for us right now and I didn't check what was the status in debian
<ricotz> in some point g-s will need gtk+3.0, but they are keeping a fallback to gtk 2.22
<seb128> nice
<ricotz> not sure how long this will last
<ricotz> seb128, also dconf needs packaging
<ricotz> g-s depends on it
<seb128> dconf is packaged
<seb128> it's in universe for a while and has been accepted for main
<ricotz> i think the current dconf is not the "right one"
<ricotz> dconf is not python, it is written in valac
<ricotz> the current version is 0.4
<seb128> you want d-conf
<ricotz> http://git.gnome.org/browse/dconf
<seb128> ricotz, I know what d-conf is
<seb128> ricotz, see libdconf0
<seb128> Version: 0.4.1-0ubuntu1
<seb128> Description: Simple key-based configuration system
<ricotz> oh, sorry
<lex79> cjwatson: when you have time can you add akonadi, soprano and koffice to kubuntu-dev packages? thanks
<Riddell> lex79: the kubuntu-dev access list isn't a simple list of packages, it's based on some criteria of seeds which seems to not align perfectly with what we'd expect, cjwatson is aware of the issue and has promised to resolve it
<lex79> Riddell: I know, some days ago he added meta-kde, pkg-kde-tools and -workspace to the list when I asked
<Riddell> oh really?  that's handy
<lex79> yes, just ask politely :)
<johanbr> Hi. The revtex style in texlive-publishers 2009-7 doesn't work properly. A sync of the version from Debian Unstable would be much appreciated. See https://bugs.launchpad.net/ubuntu/+source/texlive-extra/+bug/592721
<ubottu> Launchpad bug 592721 in texlive-extra (Ubuntu) "Revtex 4 not found" [Undecided,New]
#ubuntu-devel 2010-07-06
<cjwatson> lex79: done
<lex79> cjwatson: thanks :)
<LucidFox> I wonder if I'll ever see the day, in the bright shiny future of which I can only dream of, when clang replaces gcc as the default compiler...
<un214> is there a way to remove upstart, plymouth, mountall, etc. as all they are doing is wasting disk space
<lifeless> actually, they boot your system.
<un214> not anymore they dont
<un214> I finally had it with the lot of them and pulled sysvinit from debian
<damascene> hi,
<damascene> what is the version of mlterm that is going to be in Lucid
<damascene> sorry,  Maverick Meerkat
<jmarsden> damascene: At the moment, Maverick has   mlterm |    3.0.1-1 | maverick/universe | source, amd64, i386
<damascene> thanks
<jmarsden> Use rmadison to check for this.
<pitti> Good morning
<ddecator> morning pitti
<mvo> apw:  thanks for the fix for bug #601883 - I uploaded your fix with a minor modifcation (added the \\? to the ReleaseAccountment string as well as its used there too)
<ubottu> Launchpad bug 601883 in update-manager (Ubuntu) "update-manager fails to download release notes with apt-cacher-ng" [Medium,In progress] https://launchpad.net/bugs/601883
<mvo> apw: could you please double check (and test) once its in maverick? then we can do a lucid SRU too
<dholbach> good morning
<damascene> https://bugs.launchpad.net/ubuntu/+source/language-selector/+bug/562130
<ubottu> Launchpad bug 562130 in language-selector (Ubuntu) "Selecting an RTL language should install RTL capable terminal emulator" [Low,Triaged]
<damascene> any help with this?
<apw> mvo will do
<scar_> hi I want to test bleeding edge of xorg to see if my gpu is working properly via the nouveau driver, is there a live cd I can use to test xorg-edgers or something like that?
<RAOF> scar_: Not really, no.  That said, Maverick is pretty close to xorg-edgers at the moment.
<damascene> hi seb128
<seb128> hey damascene
<damascene> I want to request main inclusion for mlterm for bug 562130 but the process seem to complected for me. what should Ido?
<ubottu> Launchpad bug 562130 in language-selector (Ubuntu) "Selecting an RTL language should install RTL capable terminal emulator" [Low,Triaged] https://launchpad.net/bugs/562130
<seb128> talk to ArneGoetje about it?
<seb128> I don't work on language selector
<damascene> ok, thanks
<seb128> damascene, the wiki has the documentation on how to write a mir otherwise
<damascene> but I'm not sure what thing should I work on first, main inclusion or get people to agree on the idea first
<seb128> no point to do the mir if people disagree about the change
<seb128> talk to ArneGoetje or dpm about the change, I'm wondering if that was not suggested on some UDS discussion
<damascene> ArneGoetje, are you here?
<ArneGoetje> damascene: yep
<damascene> can you help with the bug?
<ArneGoetje> damascene: I don't think so. mlterm is not really integration friendly into our desktop... I have to look if I can find my notes...
<damascene> but it's the only good solution for RTL users
<damascene> brb
<ArneGoetje> damascene: I know that. But it doesn't use fontconfig, IIRC. So we will have to set the fonts somehow depending on the language to be shown
<ArneGoetje> damascene: and I don't see any practical way to do that on the desktop
<kaushal> hi
<kaushal> cjwatson: hi
<kaushal> I did added preseed base-installer/kernel/override-image string linux-server
<kaushal> in ks.cfg file, It did not work
<kaushal> I mean after installation it got stuck
<cjwatson> kaushal: in what way did it get stuck?
<kaushal> I mean it did not boot only
<kaushal> Ã±pÃ²Ã±pÃ²Ã±pBooting..Ã²
<kaushal> something like that i got it
<kaushal> whereas it worked fine using linux-image-generic
<cjwatson> I'm afraid I can't help with kernel problems
<kaushal> cjwatson: can i add it in the %post ?
<kaushal> apt-get install linux-image-server
<cjwatson> I don't see how that would make any difference to the kernel failing to boot once installed
<kaushal> cjwatson: where can i seek help ?
<lifeless> #ubuntu or the ubuntu forums
<Daviey> cjwatson, Would you be able to wave the linux 2.6.32-24.38 (lucid-proposed), through the NEW queue into -proposed?
<damascene> ArneGoetje, when I installed it from Sabily.team ppa it was automatically using the right font
<cjwatson> Daviey: processing, it takes a while
<Daviey> cjwatson, you rock :)
<ArneGoetje> damascene: I don't know how you configured your machine. When I tested it on my machine it didn't. However, I did use the package which is in Universe.
<ArneGoetje> damascene: for which language(s) did you test?
<ArneGoetje> damascene: ah, a new version got released... gotta try the one in maverick again
<ArneGoetje> damascene: if the 3.0.1-1 version in Maverick works fine, I don't see any problem to auto-install it for RTL languages.
<apw> cjwatson, ok that dirty patch is applied to the kernels at this url, perhaps you could see if they work at all for you, if so then we can look at cleaning them up etc: http://people.canonical.com/~apw/fbcon-hold-maverick/
<lifeless> james_w: hai
<cjwatson> Daviey: done; other linux* packages on their way through now as well
<cjwatson> apw: thanks, will have a look
<Daviey> cjwatson, rockin'!
<lifeless> james_w: when you get up/around - the patch is finished, hope to talk to you your evening about it if needed.
<nigelb> mvo: where does software center pull categories from? debian/control?
<jpds> nigelb: screenshots.debian.net IIRC.
<nigelb> jpds: I mean if an app's category is wrong, correcting in debian/control is enough or there is another place I have to correct it?
<cjwatson> apw: that works quite nicely
 * cjwatson wonders if he can video it
<mvo> nigelb: the package desktop file
<cjwatson> apw: http://people.canonical.com/~cjwatson/tmp/fbcon-handoff.ogv
<apw> cjwatson, dammit, its too fast :
<apw> :)
<cjwatson> apw: plymouth doesn't spend long displaying the dots, but you can see it happening
<cjwatson> Keybuk: ^- you might be interested in the above too
<ogra> Keybuk, udevd is complaining about not being able to create and write to the queue on my omap setups (i get no space left on device errors in initramfs and also later if root is mounted)
<mvo> cjwatson: nice!
<ogra> Keybuk, by the looks of it it lives in ram, and there is pleanty of free ram, do i need any special mount options or something i'm missing here ?
<ogra> *plenty
<cjwatson> the mode switch to plymouth is interesting, because for some reason grub doesn't manage to draw all the way to the edges of the screen
<cjwatson> but I took care that the logo wouldn't move; now, how this will look when KMS needs to switch to panel native resolution I'm not quite sure
<nigelb> mvo: thanks :)
<cjwatson> I wonder if I got the background colour wrong
<apw> cjwatson, that looks totally awsome ... do we know why there is a mode switch to X after plymouth?  not that that is anything much to do with the point of the exercise
<Keybuk> cjwatson: cute, how's that working?
<cjwatson> apw: I'm not even sure if I have KMS here - this is in kvm
<kaushal> cjwatson: just an update
<cjwatson> Keybuk: patch to make grub program vesafb rather than efifb; shoved in a logo file based on plymouth's; patch to fix up its background image handling a bit; and that fbcon handoff patch applied to the kernel by apw
<cjwatson> Keybuk: currently arguing on grub-devel about the first of those
<Keybuk> how does plymouth react to the fb changing?
<cjwatson> it doesn't change resolution in my current setup; my next step will probably need to be rigging up a situation where it does
<apw> cjwatson, right ... so i guess i need a recipe for generating that VM, so then i can cut that patch up and work out which bits make sense and which do not
<Keybuk> does it work at all?  when I tested, plymouth ended up giving up
<Keybuk> or crashing
<Keybuk> but that may have been because the fb changed from planar to tiled or something
<cjwatson> it seems to, you can see it redrawing the logo in my video
<cjwatson> because I didn't get the colour match quite right or something
<apw> cjwatson, i got the feeling i got some black round the edge when watching it as it transitioned
<cjwatson> yes
<cjwatson> 12:24 <cjwatson> the mode switch to plymouth is interesting, because for some reason grub doesn't manage to draw all the way to the edges of the screen
<cjwatson> not sure what's happening there
<apw> but even given this is non-kms worst case scenario, thats very slick
<apw> and having booted a win-7 machine yesterday for the first time and watched the icons switch from pictures to white squares 3 times before settling, and having time to make tea while it booted, i am sure we look better than that
<apw> cjwatson, time to make plymouth not draw their either :)
<mvo> nigelb: what package is that ?
<cjwatson> apw: this is basically a current desktop vm with http://paste.ubuntu.com/459783/ applied to grub2
<cjwatson> Keybuk: definitely need to exercise this considerably more widely than my stunt vm, I agree :)
<nigelb> mvo: lernid
<nigelb> Its in development > python
<nigelb> I'll try to get a patch for it
<nigelb> mvo: though for this, python is defined in debian/control.  Maybe there is a fallback in case desktop file is not available?
<mvo> nigelb: yeah, that is true
<apw> cjwatson, that reminds me, with those patches applied, does VT switching to VT1 work as expected ?
<nigelb> mvo: awesome, I'll get a fix for it soonish.  thanks :)
<cjwatson> apw: I did notice before that patch that in some cases I couldn't switch back to VT7 after switching to VT1 (it switched, but didn't change the display other than turning off the cursor blink)
<cjwatson> apw: with that patch - no, fails
<apw> cjwatson, hrm
<cjwatson> apw: it corrupts a little area at the top left of the screen, so it's done something, but not a proper switch
<cjwatson> maybe doesn't know how to switch back to text mode?
<apw> cjwatson, well i think the patch is turning off all updates in non-graphics mode
<cjwatson> hah
<apw> so i suspect that is what i'd expect it to do.
<cjwatson> that would do it
<cjwatson> right, so that patch isn't really what we want as such
<apw> and i am not sure if it needs that or not, hense i want to be able to repro it in a VM myself so i can drop the dodgy bits and test it
<cjwatson> apw: yeah.  I think the patch I pasted above should be enough for you; however note that at the moment you also need to edit /etc/default/grub, comment out the two GRUB_HIDDEN_TIMEOUT* lines, and run update-grub
<cjwatson> I haven't got round to arranging to display the background even if the menu isn't shown yet
<apw> cjwatson, ok ta.  sounds like my afternoon is planned now
<ogra> doko, seems i found the issue of openjdk, ca-certificates-java depends on: openjdk-6-jre-headless (>= 6b16-1.6.1-2) | java6-runtime-headless ... seems the buildd installs default-jre-headless instead of openjdk-6-jre-headless
<ogra> doko, which in turn segfaults when running keytool
<ogra> doko, i wonder if we could make the "| java6-runtime-headless" arch specific since its unlikely that any of the other java implementations will work on arm anyway
<doko> ogra: hmm, but default-jre-headless depends on openjdk-6-jre-headless
<cjwatson> Keybuk: any particular suggestions for the sorts of setups that might trigger a plymouth crash?
<ogra> doko, hmm
 * ogra checks the build log again
<ogra> Unpacking openjdk-6-jre-headless (from .../openjdk-6-jre-headless_6b18-1.8-2ubuntu2_armel.deb) ...
<ogra> that looks quite outdated
<ogra> but its indeed the last one that built
<Keybuk> cjwatson: no idea
<apw> mvo, i am not at all sure this upload for apt-cacher-ng worked right ...
<apw> if you look at the diff the source package building made a patch for you which looks to have removed the change you made ...
<apw> mvo, i also think the change itself wasn't quite right as it didn't have a trailing ?
<apw> mvo, i suspect you just changed the patch in in debian/patches and didn't tell quilt
<apw> cjwatson, this automatic generation of a patch is there is any differences left ... is there any way to turn it off do you know?  (3.0 (quilt) format) ... it is a royal pain in the ass
<mvo> apw: that is what I did :( oh quilt you are the source of all my gray hair
<apw> its an utter pain
<cjwatson> why are there differences left?
<mvo> apw++
<cjwatson> this is not a problem I have in my packages
<apw> mvo, also note that you didn't add the ? after the () section
<apw> cjwatson, there can be differences left if you arn't careful with quilt
<mvo> apw: thanks, let me fix it
<cjwatson> you can't turn it off as then the resulting source package doesn't represent your build tree!
<apw> i would like an option --crash-in-a-heap-if-you-need-to-add-a-patch
<cjwatson> that might be a reasonable wishlist bug on Debian dpkg
<apw> yeah i am happy it shouldn't make an uploadable in that state i would just rather it hurt me a lot instead of giving me something
<apw> yea
<apw> cjwatson, had any problems with apparmour getting in the way of your VM usage recently?  all mine just stopped working
<cjwatson> not so I've noticed, though I only just upgraded to maverick
<apw> this is a lucid host ... hrm
<cjwatson> was working fine on lucid, though I was probably behind on updates
<mvo> apw: please double check http://paste.ubuntu.com/459811/ - if it looks ok I will upload
<apw> mvo that looks better :)
<mvo> apw: *puh* thanks :)
<mvo> apw: uploaded to lucid-proposed now too, many thanks for your work on this!
<apw> mvo, cool.  once its built in proposed i'll re-test there
<apw> dammit launchpad performance is a serious impediment to my work
<ricotz> jdong, hello, also pitti acked the docky sru, but he didnt add a comment
<maxwellian> Does anyone know the status of using OpenID login for Ubuntu sites?  The brainstorm page hasn't seen any activity since December.
<jpds> maxwellian: Doesn't the Brainstorm use the Ubuntu QA login thing?
<maxwellian> jpds: I don't know, I don't have an account on any of the sites, because I hate making new accounts.
<maxwellian> jpds: Exactly why I want OpenID.
<maxwellian> jpds: I'm talking about all of the sites accepting OpenID, ideally as a consumer.
<jpds> maxwellian: Right, I think stgraber would know more.
<maxwellian> jpds: Thanks, I don't know a lot myself, but it just seems like a great idea.  Wondering if it's in the works.  Thanks.
<jdstrand> didrocks: hey. I committed fixes for bug #599169 to bzr. feel free to pull it in SRU for lucid
<ubottu> Launchpad bug 599169 in evince (Ubuntu) "evince cbz support is broken on evince-2.30.3-0ubuntu1" [Low,Fix committed] https://launchpad.net/bugs/599169
<jdstrand> didrocks: (and upload to maverick, which I can do if you need me to)
<LucidFox> This may have been asked lots of times before, but will Maverick ship with GNOME 3?
<apw> cjwatson, the kernel on the live-cd's that is a full install of the kernel packages right ?
<ogra_cmpc> apw, livecd-rootfs installs the metapackage
<ogra_cmpc> so yes, it pulls in a full install of the kernel package
<apw> ogra_cmpc, ok, so the whole pacakge... thanks
<ogra_cmpc> the initramfs contains casper though
<shadeslayer> hi! can someone look at bug 565376 and this debdiff : http://people.ubuntu.com/~rohangarg/desktopcouch.debdiff :
<ubottu> Launchpad bug 565376 in desktopcouch (Ubuntu) "bughugger does not work in kubuntu lucid" [Undecided,New] https://launchpad.net/bugs/565376
<shadeslayer> after applying the debdiff,i hope to get the attached debdiff in the bug SRU'd
<shadeslayer> ( and yes,this issue is in maverick as well )
<apw> cjwatson, where can i get your background image, for grub2; and indeed how to configure it ?
<seb128> jdstrand, hey
<seb128> jdstrand, didrocks is not around this week, dunno if you could sru the update for apparmor profile to lucid for him?
<apw> cjohnston, as without it its hard to tell if the darned thing is workng
<seb128> jdstrand, it's getting tight for lucid .1
<apw> cjwatson, ^^
<jdstrand> seb128: ok
<seb128> jdstrand, thanks
<cjwatson> apw: oh, sorry, forgot that bit
<cjwatson> apw: http://people.canonical.com/~cjwatson/tmp/logo.png - drop that into /boot/grub/logo.png, and set GRUB_BACKGROUND=/boot/grub/logo.png in /etc/default/grub
<apw> cjwatson, ta
<cjwatson> apw: you should also set GRUB_GFXMODE=1024x768, probably
<cjwatson> (at least that's what I did)
<apw> cjwatson, ahh ok will try both
<cjwatson> apw: I see what's causing the border - will bring that up on grub-devel
<shadeslayer> btw is there a seprate dekstopcouch channel?
<jdstrand> seb128: fyi, uploaded evince to maverick and lucid-approved (waiting for approval). I did all the SRU stuff in the bug
<jdstrand> err
<jdstrand> lucid-proposed :)
<maco2> dang i thought youd found a magic go-faster section
<jdstrand> heh
<seb128> jdstrand, thanks!
<jdstrand> sure! :)
<kees> Riddell: can you remove the openjpeg build deps from whatever was using it?  I've rejected that MIR on the ground of scary code.  :)
<shapr> Hi, if there's not an Ubuntu Haskell Team, how would I go about starting one? I assume I'd need to be an Ubuntu developer first?
<Riddell> kees: ok
<Laney> shapr: what do you want this team to do?
<Laney> (I usually take care of that stuff)
<shapr> Laney: I just want more recent versions of Haskell packages.
<maco2> Laney: oh you make my xmonad go? thank you!
<Laney> maco2: well nomeata maintains that, I just sync and rebuild as necessary
<Laney> shapr: I suggest you get them updated in Debian and then included from there into Ubuntu
<Laney> but it's a fact of our release model that not everything is the newest crack all the time
<shapr> Laney: I'm new to ubuntu, have used debian for many years, is there an equivalent of debian/unstable?
<kees> Riddell: thanks
<Laney> no not really, there's a development release but it's subject to various freezes
<shapr> Assuming there were ghc6 and ghc6-unstable packages, or something, would I just notify you that there were newer packages in debian?
<Laney> you can file sync requests yourself even
<Laney> wonder if this works...
<Laney> !sync
<ubottu> Helpful information for filing a sync request can be found at https://wiki.ubuntu.com/SyncRequestProcess
<shapr> Oh, that's spiffy!
<Laney> (and then subscribe me if you like)
<shapr> Laney: I know a lot of people in the Haskell community, is there anything I could do to make your packaging tasks easier?
<Laney> get GHC to support dynamic linking and have a stable ABI :)
<maco2> hahaha
<shapr> I think there's support for dynamic linking in 6.13, dunno about a stable ABI though.
<Laney> afaik it's only x86/64 :(
<shapr> Oh, I see. I guess I haven't noticed because that's all I use.
<Chipzz> what's with the nick spam? :P
<shapr> Except for Linux on Cell, which requires Yellow Dog Linux :-/
<maco2> reboot_in_10: what are you doing?
<Laney> shapr: I think if you want to be a nice upstream liaison then a good place to look out is on the debian-haskell and pkg-haskell maintainers lists
<maco2> perm_denied: could you stop that?
<shapr> Laney: Thanks, I'll see what I can do.
<Laney> :)
<Laney> and of course, if you want to help me doing mass rebuilds once or twice every six months then we can maybe arrange this...
<Chipzz> shapr: the various releases are more analogue to testing
<Laney> not the most attractive of offers I'd wager
 * Laney runs
<shapr> Laney: I'll start small and work my way up :-)
<Chipzz> except for the fact that ubuntu doesn't have unstable, so packages get uploaded to "testing" straight away
<Laney> yeah doing sync requests is a really good way to help anyway
<Laney> I don't follow hackage all that close â mainly use agda myself
<shapr> Chipzz: So, is there an ubuntu/testing flavor where I can contribute bug reports?
<Chipzz> shapr: the current development release
<Chipzz> ie maverick
<shapr> Laney: I wonder whether it makes more sense to have packages only for libs that cabal doesn't handle?
<shapr> And of course, a package for cabal.
<Laney> no, we want to provide a development platform within the distro
<Laney> and of course we can't build app packages against anything other than debainised libs
<Laney> the distro is supposed to provide an extra layer of QA on top of upstream
<shapr> What's the correct way to switch to maverick?
<shapr> Laney: If I understand correctly, I'd switch to maverick, try the debian-haskell packages locally, and then send a sync request when everything integrates happily?
<Laney> if by "try" you mean "rebuild on my maverick box", then yes
<shapr> Right, that's what I meant.
<Laney> but be aware of https://wiki.ubuntu.com/MaverickReleaseSchedule â particularly feature freeze
<shapr> Laney: Is there a wiki page/blog post/other document that describes the entire Ubuntu dev process?
<Laney> oh, er, ... I don't know
<Laney> anyone?
<lifeless> shapr: there are docs for various things
<lifeless> shapr: what sort of thing do you want to know? what an ubuntu dev does? what ubuntu itself goes through?
<achiang> what is the proper way to add a patch to a package that is in debian 3.0 format?
<achiang> i've created the patch, added it to debian/patches/ and updated debian/patches/series, and can successfully push and pop it with quilt
<achiang> but when i try to build it, i get an error
<achiang> i'm pretty sure the patch is fuzz-free
<achiang> it seems like when i go to build, something is trying to apply the patch a 2nd time
<dupondje> Riddell: could you check https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/408119 ?
<ubottu> Launchpad bug 408119 in imagemagick (Ubuntu) "Merge imagemagick 7:6.6.0.4-2 (main) from Debian testing (main)" [Undecided,In progress]
<dupondje> Just waiting for your go to sync, then we can sync some other packages depending on new imagemagick also :)
<DarkLXVZ> driver sis mirage 3 3d per ubuntu
<achiang> should i be adding my patch to package.debian.tar.gz and re-tarring it up possibly?
* Chex changed the topic of #ubuntu-devel to: Alpha-2 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | Launchpad down/read-only from 23:00 - 00:30 UTC for a code update | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
#ubuntu-devel 2010-07-07
<lifeless> james_w: are you still up?
<highvoltage> #ubuntu-devel is quite different when you're in a US timezone
* Chex changed the topic of #ubuntu-devel to: Alpha-2 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
* Chex changed the topic of #ubuntu-devel to: Alpha-2 released | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for dapper-lucid | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<kees> is initramfs-tools stuck in binary NEW?
<kees> hm, no...
<kees> is the publisher just being slow?
<ScottK> Might have been affected by the LP downtime.
<pitti> achiang: no, debian.tar.gz is created automatically, no need to fuss with that; you just need to apply the patch (quilt push -a) before building binaries
<ricotz> pitti, good morning
<ronc> hi devs
<ronc> I just wanted to say that some man pages are not being updated since the early days of ubuntu
<dholbach> good morning
<ronc> I was trying to browse in w3m the other day, but couldn't find the items that these websites told me... then wham! I found this bug report: https://bugs.launchpad.net/w3m/+bug/525360
<ubottu> Launchpad bug 525360 in w3m (Ubuntu) "Man page isn't synchronized" [Undecided,Confirmed]
<ronc> which is like crazy, man
<pitti> cking: good morning
<pitti> cking: wrt. bug 599352, does linux' suspend-to-disk use compression at all?
<ubottu> Launchpad bug 599352 in upower (Ubuntu) "[Maverick] Need to not display hibernation in UI if do not have enough swap space" [Low,Confirmed] https://launchpad.net/bugs/599352
<cking> pitti, as far as I know, there is no compression used in hibernation
<cking> it just dumps the used pages + some meta data
<pitti> cking: thanks
<ev> Am I going insane or should md5sum /dev/sdb /dev/sdb produce identical results (all partitions are unmounted)?
<soren> ev: Sounds like a reasonable assumption.
<ev> yeah, I've got three usb disks that continuously produce different results.  I guess it must be a bad lot.
<ev> soren: thanks
<pitti> ev: do you see read errors in dmesg?
<soren> ev: Have you had anything from sdb mounted since your last reboot? Perhaps there's some cache flushing going on that's massing things up.
<ev> pitti: nope
<ev> hmm
<ricotz> pitti, could you please accept the docky sru upload? or is there something wrong? https://bugs.edge.launchpad.net/docky/+bug/579049
<ubottu> Launchpad bug 579049 in docky (Ubuntu Lucid) "Dragging files to folders causes data "corruption"" [Undecided,New]
<pitti> ricotz: I'm not doing SRU every day, just once a week or so (I'm not in platform this cycle)
<cjwatson> I can have a look
<pitti> ricotz: but I'll get to it this week, promised
<ricotz> pitti, sorry, ok
<ricotz> cjwatson, that would be great
<cjwatson> I've been doing them intermittently, just haven't had time to completely keep up
<cjwatson> oh, right, it's the one with an infinite number of bugs
 * cjwatson watches queuediff DoS his firefox
<ricotz> cjwatson, yes, there are quite some fixes
<cjwatson> ricotz: is anyone working on getting this into maverick?  in general, fixes should go to maverick first
<ricotz> cjwatson, yes, i requested an sync with debian/unstable
 * cjwatson looks at the sync queue
<ricotz> the packaging in debian/unstable isnt compatible with lucid anymore
<cjwatson> ok, I'll process that
<Laney> would be nice if someone could accept lhs2tex too
<ricotz> Laney, you are always behind my back :P
<Laney> I have my own SRUs in addition to yours!
<ricotz> Laney, i know
<Laney> :)
<BlackZ> cjwatson: could you look at bug #600121 when you can ? we're waiting this sync for the ekiga merge, thanks!
<ubottu> Launchpad bug 600121 in opal (Ubuntu) "Sync opal 3.6.8~dfsg-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/600121
<cjwatson> oh dear, I should go back to hiding, now everyone wants a piece
<BlackZ> heh
<Laney> the joys of archive adminship
<Laney> did something happen wrt sparc very recently? I see that glib2.0 has no build record there
<cjwatson> not that I know of ...
<Laney> oh, no it hasn't in the previous uploads either
<cjwatson> ISTR lamont killed glib2.0 on sparc because it had a habit of killing the buildd
<Laney> ok then, I won't worry about knock-on failures
<ricotz> do built packages need to be accepted manually like https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.7.0~beta1+git20100706-0ubuntu1 ?
<Laney> new binaries or source packages do
<cjwatson> ricotz: docky done (maverick and lucid-proposed)
<ricotz> cjwatson, thank you!!!
<cjwatson> BlackZ: opal done
<BlackZ> cjwatson: thanks
<cjwatson> ricotz: qt> I'd like to accept all architectures at once if possible, to minimise the chance of build failures due to them being out of sync
<ricotz> cjwatson, ok, so this will take some time then, currently it breaks my ia32lib build in xorgedgers
<cjwatson> Laney: lhs2tex done
<cjwatson> ricotz: hopefully not too long - I've scored it up on the other architectures
<cjwatson> they should start very shortly
<ricotz> cjwatson, ok
<Laney> thanks
<Laney> the FP lab will appreciate it
<cjwatson> FP lab?
<Laney> my research group
<cjwatson> ah, right
<mdz> mvo: is there a way to test a lucid->maverick upgrade of a real system in a sandbox?
<mdz> I remember you'd worked on some tools to do that in the past
<soren> mdz: update-manager has a -s option: "-s, --sandbox         Test upgrade with a sandbox aufs overlay"
<mdz> soren: do you know if it works in lucid?
<dholbach> or just check out http://people.canonical.com/~mvo/automatic-upgrade-testing/2010-07-06-15:03:01/ ;-)
<soren> mdz: Nope, never used it. The option is available on Lucid, though.
 * mdz notices --sandbox isn't documented on the man page, and prepares a branch
<mdz> soren, mvo: it seems to have hosed my system pretty badly ("command not found: ls" and such)
<mdz> seems to be getting EPERM on everything
<mvo> mdz: a reboot should cure it
<mdz> mvo: it has
<mvo> mdz: all changes are in /tmp, but it can take a bit until tmp is cleared
<mdz> mvo: my /tmp is tmpfs
<mvo> mdz: hrm, hrm, sorry for the trouble, the code should check that
<mdz> which is why the upgrade failed early (lack of disk space in /tmp)
<mdz> is it possible to set an alternative location for the sandbox?
<mvo> mdz: it uses tempfile.mkdtemp(), so it should honor TMPDIR in the environment
<mdz> mvo: ok, thanks
<mvo> mdz let me know how it goes
<mdz> mvo: having a non-functional $PATH will make it difficult to monitor the upgrade, which is a pain because I'm trying to reproduce a kernel bug
<mdz> mvo: (the disk free space was correctly checked, that worked fine. it's just that my system was still non-functional after the upgrade was canceled)
<mvo> a kernel bug that happens on upgrade
<mvo> ?
<mdz> mvo: yes
<mvo> mdz: the --sandbox option did not got a lot of love because aufs is not really suitable for the workload. this is why its a bit bumpy
<mdz> bug 602261
<ubottu> Launchpad bug 602261 in linux (Ubuntu) "Thrashing and OOM during upgrade from 10.04 to Maverick" [High,Confirmed] https://launchpad.net/bugs/602261
<mdz> rickspencer3 saw this as well
 * mvo looks
<mdz> I thought it was related to apparmor, but apw suspects it may be ext4
<mvo> mdz: is it only reproducable on real HW?
<mvo> otherwise the auto-upgrade-tester may be helpful
<mdz> mvo: I don't know
<apw> certainly there are reports of jdb2 being stuck running for over 2 minutes which is abnormal
<mvo> mdz: http://people.canonical.com/~mvo/automatic-upgrade-testing/current/ shows that a server upgrade (minimal server) is about 10min, ubuntu 30min, so total runtime seems to be not a good indicator
<mdz> mvo: I suspect it may be related to any/all of a) running processes (i.e. a normal user session), b) replacing apparmor profiles, or c) the idle I/O scheduler (ionice -c3)
<mdz> maybe even a combination of them
 * mvo nods
<mvo> I can create a auto-login profile so that there is a normal session
<mdz> apw: interestingly, doing a big dd on this system doesn't bog it down like it does my laptop
<mdz> though both are ext4
<mdz> this one has a faster disk and less memory
<mdz> and is 32-bit
<apw> mdz i wonder why that would be, less memory?
<mdz> (while the other is 64)
<apw> 32bit does have an effect on the kernel memory size
<mdz> apw: I get very high CPU utilization (system) and very low I/O wait
<mdz> flush-8:16 is the active thread
<mdz> on the other system I believe I get high I/O wait
<apw> hrm ... i use 64 bit quite a bit and have done an upgrade there without issue (lucid -> maverick)
<psurbhi> i wanted to know where I could pick the latest unreleased (or in development) mdadm source package for maverick. Is there a bzr repository for mdadm? where would that be?
<Keybuk> psurbhi: we don't really have unreleased/in development repos like that
<Keybuk> the latest version is generally just in the archive
<Keybuk> if there's a bzr branch, it's possibly lp:ubuntu/mdadm
<psurbhi> ok, i checked that.. no bzr branch then. So does it mean that apt-get source mdadm is the latest mdadm package?
<amitk> psurbhi: 'rmadison mdadm'
<psurbhi> amitk, Keybuk, thanks
<Keybuk> psurbhi: yup
<psurbhi> ok
<LucidFox> I think for the next year's April Fools, I'm going to blog about Ubuntu Genuine Advantage.
<LucidFox> With fake activation screens and everything.
<mdz> mvo_: /var/log/dist-upgrade/term.log suddenly stopped (in the middle of a line), but the upgrade is continuing to run
<mdz> plenty of disk space, no obvious problem
<mvo_> oh
<mvo_> odd, anything from strace?
<mdz> mvo_: it's as if a buffer isn't getting flushed somewhere
<mvo_> that is insndbox mode? or nomal?
<soren> LucidFox: http://www.linuxgenuineadvantage.org/
<mdz> mvo_: normal
<mdz> mvo_: strace of the maverick process shows write(11, "pmstatus:ure:70.6563:Installed u"..., 35
<mvo_> mdz: ok, that looks normal
<LucidFox> "According to an independent study conducted by some scientists, many users of Linux are running non-Genuine versions of their operating system. This puts them at the disadvantage of having their computers work normally, without periodically phoning home unannounced to see if it's OK for their computer to continue functioning."
<LucidFox> Yeah, that's WGA in a nutshell
<mvo_> mdz: do you have apt-term as well? and if so, is that keep getting updated?
<mdz> mvo_: but there is no activity in strace even though dpkg is completing more operations
<mdz> mvo_: I have a tail -f running on /var/log/dist-upgrade/*.log and nothing is changing
<mdz> mvo_: the terminal window is not updating either
<mdz> (the one inside the upgrader)
<soren> LucidFox: LGA doesn't work with upstart, though.
<LucidFox> Hmmmm *scribble scribble*
<LucidFox> soren> You know...
<LucidFox> Now I'm actually tempted to write an actual GUI system for Ubuntu mimicking WGA. Deliberately easily circumventable, of course
<soren> LucidFox: sorry :)
<mdz> mvo_: hmm, it just dumped about 2k of text into term.log and apt-term.log, all at once, and then stopped again
<LucidFox> Sorry? :)
<mdz> definitely some buffering issue
<soren> LucidFox: Yeah, didn't mean to get you motivated on.. um.. slightly less than useful things :)
<mdz> mvo_: I've emailed you the logs
<LucidFox> Hah
<mvo_> mdz: thanks, I'm working on the code currently (to port to the latest python-apt 0.8 api), that is going to be interessting :)
<mvo_> mdz: it looks like there are some issues in p-apt itself, nothing too scary so far fortunately, all easily work-aroundable
<mdz> mvo_: there seem to be two upgrader processes, and the child is blocking writing to the pipe to the parent
<mdz> mvo_: two things look weird to me: 1) the parent still has both ends of the pipe open, and 2) the parent is polling but it doesn't seem to be polling this FD
<mvo_> mdz: thanks, got the logs.
<mvo_> mdz: which frontend did you use? text? gtk? I will try to reproduce in a vm
<mdz> mvo_: GTK
<tseliot> cjwatson: do you have news on bug #258486?
<ubottu> Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/258486)
<cjwatson> tseliot: no, sorry - please check with ev though
<cjwatson> I've not been doing much on ubiquity this cycle
<cjwatson> and he's reworking jockey handling anyway, iirc
<tseliot> cjwatson: yes, that's why I asked but I was looking for "evand" not "ev". Thanks
<kirkland> pitti: howdy, around?
<pitti> kirkland: hey, how are you? I'm in the OEM meeting, but otherwise here, yes
<kirkland> pitti: awesome, i'm okay ...  i just realized a libvirt SRU that has slipped through the cracks for me for ~1 month: https://bugs.edge.launchpad.net/ubuntu/+source/multipath-tools/+bug/571093
<ubottu> Launchpad bug 571093 in libvirt (Ubuntu Lucid) "[SRU] multipath + libvirtd eats away more memory over time" [Medium,In progress]
<kirkland> pitti: it needed a minor version change in the upload;  i just re-uploaded that to lucid-proposed
<kirkland> pitti: i just wanted to make sure the other end didn't slip through the cracks too :-)
<pitti> kirkland: ah, thanks; I'll have a look at it
<kirkland> pitti: cheers, mate
<ev> tseliot: you're seeing something like this on Maverick?
<ev> Intrepid was a long time ago :)
<tseliot> ev: I haven't tried with Maverick yet. The problem can be reproduced in Lucid though
<tseliot> and this makes it more recent ;)
<ev> interesting
<tseliot> ev: basically xorg.conf remains there but the packages don't
<tseliot> but I guess that's already in the report
<ev> indeed, I'm quite surprised we haven't heard more people screaming about this
<ev> I've bumped the priority and assigned it to myself
<tseliot> ev: thanks. Let me know if you need any help for debugging, etc.
<ev> sure thing
<mdz> mvo_: I sent you a merge request with a  couple of small update-manager fixes I did while looking at this problem
<mvo_> thanks mdz
<mvo_> merged
<mdz> mvo_: one is a documentation fix, the other is a one-line code change (untested but trivial)
<apw> cjwatson, the grub boot sexification, are we keeping X on VT7 ?
<bankix> Hello.
<bankix> I'm currently customizing Lucid, but however I'm unable to find out which file is responsible for the little ubuntu logo in the upper left corner of the gnome panel. Could you give me a pointer?
<pitti> wgrant: hey, how are you?
<pitti> lamont, wgrant: do you happen to know the current state of native soyuz ddeb support?
<lamont> pitti: nfc
<a_ok> I still seem to have the problem that looks a lot like https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/546964 . I am using an Intel ET Nic and I have confirmed that the igb.ko driver is in the initrd image
<ubottu> Launchpad bug 546964 in initramfs-tools (Ubuntu) "10.04 beta1 iSCSI-on-root fails on boot" [High,Fix released]
<cjwatson> apw: yes
<a_ok> I am using the stable 10.4 release by the way and the latest initramfs-tools seems to be the one that comes with it (0.92ubuntu78)
<cjwatson> (to the best of my knowledge)
<ogra> apw, sexification ? will it be male or female after that ?
<apw> cjwatson, the kernel patches as were break VTs basically for good.  we really want the special functionality to remain only till we are on VT7 and settled in, i am thinking a VT switch may be the correct trigger to return normal behviour
<apw> then if you fiddle manually mid-boot you get the normal behaviour too
<a_ok> this is the exact error I get when trying to boot http://pastebin.com/3UXhaPKu
<cjwatson> apw: breaking VT switching definitely isn't on
<cjwatson> apw: remember that server boots won't have a VT switch but will have plymouth and the grub splash, though
<cjwatson> apw: so I'm not sure that's the right trigger
<apw> cjwatson, hrm, then i suspect i will need to be told you are clear
<cjwatson> apw: how about plymouth's switch to KD_TEXT?
<cjwatson> that seems like a good indicator
<apw> cjwatson, i presume it only does that on non-desktop
<apw> oh perhaps also on timeout ?
<cjwatson> we always switch back to KD_TEXT at some point, even if it's only when people do ctrl-alt-f1 fromX
<a_ok> is there a way I can get some more information on what goes wrong?
<apw> cjwatson, well no you don't change mode then you change which vt is displayed which is in a different mode
<apw> cjwatson, anyhow i am getting ahead.  i suspect a switch from graphics mode to text within a VT or switching VT should trigger normality
<apw> i thin
<apw> i think
<cjwatson> that seems fair
<cjwatson> apw: vt1 is switched to KD_TEXT even on desktop boots, I believe
<cjwatson> bloody well ought to be anyway
<apw> once i figure out why vt2 ->6 are all full of vomit of course i can smarten things up
<apw> cjwatson, so can you tell me when we switch to vt7 and which thing plymouth is on, i thought it was on vt7
<cjwatson> plymouth is on vt1
<cjwatson> we switch to vt7 when X starts
<apw> cjwatson, so if we vt switch to the same contents that is scemeless ?
<apw> visually ?
<apw> ie. plymouth maks vt1 purple, x starts on vt7 and copies the contents over, then vt switches ?
<cjwatson> X is *supposed* to take care of that; it didn't seem to quite work in my video but I am deliberately not caring about that
<apw> cjwatson, i suspect that as you said you don't have KMS therefore you cannot do a seemless cut
<apw> i will get this heap installed on some kms h/w and see what happens there
<pitti> kirkland: do you know the status of bug 566792 in maverick: the SRU is ready for -updates, but I won't as long as it's not yet fixed in maverick
<YokoZar> pitti: you probably don't need to copy the SRUed ia32-libs to maverick, as it needs to be freshly generated there to get the maverick versions of the libs
<ubottu> Launchpad bug 566792 in eucalyptus (Ubuntu) "metadata service returns empty data with 200 OK" [High,Confirmed] https://launchpad.net/bugs/566792
<pitti> kirkland: (or at least committed to bzr)
<apw> cjwatson, what do you use to take the video of the VM ?
<cjwatson> apw: gtk-recordmydesktop
<pitti> YokoZar: right, but as long as nobody does that, copying the SRU is better than nothing
<cjwatson> apw: by way of scoping I'm intentionally only caring about the period until plymouth comes up
<kirkland> Daviey: you've been managing that one ... can you tell us if that code has been applied to maverick?
<YokoZar> pitti: I suppose that somebody is supposed to be me.  Is there any movement on multiarch at all in maverick (and thus things that can be dropped from ia32-libs?)
 * Daviey reads
<kirkland> Daviey: i suspect it has, in the course of your regular weekly Eucalyptus merges
<apw> cjwatson, yeah, but sadly i have to care thorugh KMS to make sure i am not breaking that by munching the kernel
<kirkland> Daviey: can you check?
<cjwatson> apw: ah, fair enough
<pitti> YokoZar: no, I didn't mean "you" in particular
<YokoZar> pitti: I know that, but I usually do the ia32-libs uploads ;)
<pitti> YokoZar: I don't know about the multiarch plan, I'm afraid
<Daviey> pitti, Ah.. yes.. -> PM
<pitti> YokoZar: it's much faster to do in the DC, though
<YokoZar> slangasek might know about multiarch
<slangasek> step 1) fix dpkg
<pitti> is it just me, or is LP very slow today? (including launchpadlib)
<apw> pitti, it was upgraded to a nice shiney version last night i think
<sebner> apw: shiny = b0rken? :P
<pitti> they forgot to take out the sleep() debugging statements?
<sebner> pitti: agreed, slowwww
<apw> pitti, it does feel slow, but i am not sure if its more excruciatingly slow than normal
<apw> i already want to poke my own eyes out
<YokoZar> does anyone know if the new SFTP for PPAs can be done for normal uploads?
<YokoZar> to the main repository
<Laney> yes
<Laney> you have to set incoming to ubuntu, or so geser told me
<pitti> apw: it's even slow with the CLI tools on cocoplum, so I guess it's real
<YokoZar> Laney: and presumably modify /etc/dput.cf manually
<Laney> right
<apw> pitti, i am usng edge of course, so my milage is different
<pitti> apw: same here
<pitti> there, all SRU queues emtpy (except for some disputed uploads)
<geser> YokoZar: see http://paste.ubuntu.com/460266/ for my ~/.dput.cf for SFTP uploads
<apw> pitti, heh the kernel per
<apw> perhaps ?
<pitti> that (karmic), and sane
<YokoZar> geser: thanks
<apw> yep, thats the one
<YokoZar> geser: (I need sftp to upload ia32-libs from home otherwise my internet connection hangs forever)
<arulalan> Dear All, i have a doubt. How can i write graphics program in GCC. I googled , but cant get good link for this
<arulalan> i cant post this query in #gcc. it says ' Cannot send to channel'
<Chipzz> arulalan: this is not a good question for this channel; but either way, you don't specify what kind of graphics program you want to write (ie plain OpenGL, Gtk+, Qt...)
<Chipzz> arulalan: and if you can't send to the channel, there's probably a very good reason for it (like the channel being moderated); read the topic, it most likely has further instructions (and this goes for any channel, including this one; if you would have read the topic, you would have known your question wasn't appropriate here)
<arulalan> Chipzz: Ok sir. i need to write a program using graphics.h header file like turboc. is opengl right choice ?
<Chipzz> arulalan: again, your question is not appropriate here. also, a quick google for graphics.h shows a lot of different projects (quite expectable with such a filename) so your question is ambigous
<Chipzz> but again, this is not the right place to ask.
<apw> cjwatson, http://people.canonical.com/~apw/misc/fbcon-handoff.ogv <-- video from my latest test kernel
<Chipzz> but if graphics.h refers to sth like VGA/SVGA drawing, the closest thing on linux is SDL I would say
<apw> arulalan, normally you can't send to a channel if you arn't registered as owning that nick
<cjwatson> apw: not bad
<apw> cjwatson, note the cursor only appears when the debugging printk's come out, and they are at KERN_EMERG
<cjwatson> incidentally, with this, does the console subsystem start in KD_GRAPHICS or KD_TEXT?
<dupondje> Riddell: I did build imagemagick from debian, and those are the depds:  Depends: libbz2-1.0, libc6 (>= 2.11), libfontconfig1 (>= 2.8.0), libfreetype6 (>= 2.2.1), libglib2.0-0 (>= 2.12.0), libgomp1 (>= 4.2.1), libice6 (>= 1:1.0.0), libjasper1 (>= 1.900.1), libjpeg62, liblcms1 (>= 1.15-1), liblqr-1-0 (>= 0.1.0), libltdl7 (>= 2.2.6b), libpng12-0 (>= 1.2.13-4), libsm6, libtiff4, libx11-6, libxext6, libxml2 (>= 2.7.4), libxt6, zlib1g (>= 1:1.2.3.3.dfsg)
<Riddell> dupondje: no librsvg?
<dupondje> Riddell: nope
<dupondje>  Package: libmagickcore3
<Riddell> dupondje: something must depend on it though surely?
<dupondje> Riddell: libmagickcore3-extra and libmagickcore-dev depend on librsvg2-dev,
<dupondje> libmagickcore3-extra on librsvg2-2, libmagickcore-dev depend on librsvg2-dev
<Riddell> dupondje: that seems fine then
<dupondje> true :) can you give it a sync ? :)
<Riddell> dupondje: what about liblqr-1-0-dev ?
<dupondje> Riddell: it was dropped because it wasn't in main, but now it is
<Riddell> dupondje: groovy
<Riddell> dupondje: synced
<dupondje> sweet :)
<LucidFox> Any chance I could get the Liferea messaging indicator patch reviewed before the heat death of the universe? It's been waiting on LP for two months now and none of the core-devs even acknowledged its existence in the bugreport
<nigelb> vish: poke!
<vish> nigelb: here? me? o.0
<nigelb> vish: ^^ I think thats something ayatana could look at
<nigelb> LucidFox wrote this awesome patch to get indicator working with liferea, which we use via ppa for now
<vish> LucidFox: tried #ayatana  ?
<LucidFox> I did, nobody replied there either
<vish> i think tedg already had a patch for that.
<LucidFox> Where? It's not on LP
<LucidFox> My patch was all over the news, got talked about on Omg! Ubuntu, and I've never seen any other one in a public place. Definitely not on LP, at least
<vish> LucidFox: bug #  , tedg/kenvandine are probably the best people to review it?
<vish> LucidFox: its attached to a bug? or just a branch?
<LucidFox> bug #540490
<ubottu> Launchpad bug 540490 in liferea (Ubuntu) "liferea should be added to the indicator applet" [Undecided,Confirmed] https://launchpad.net/bugs/540490
<nigelb> g63
<nigelb> grr
<nigelb> window fail again
<vish> LucidFox: tedg seems absent today .. :(
<nigelb> isn't there a tag for it?
<vish> yeah , there is
<vish> LucidFox: if no response , jcastro is the next best person who can be poked :)
<kenvandine> tedhave you looked at that?
<kenvandine> whoops
<kenvandine> tedg isn't here :)
<kenvandine> LucidFox, ping tedg in #ayatana
<vish> kenvandine: thanks  :)
<vish> kenvandine: seems LucidFox has been asking about that for a while and no one has responded..
<JontheEchidna> So I've added a few PPAs via software-properties, but they do not seem to be showing up in software-center, and the origin as provided by libapt-pkg is empty. Any APT expert have any idea what could cause that?
<JontheEchidna> One hint that I have is that while adding the PPA, the lookup for keyserver.ubuntu.com fails, but I don't know if that would make apt not see the origin...
<LucidFox> I wonder, how does bash tab completion know when to unwrap to .dsc, when to .changes, and the like?
<LucidFox> I noticed that it always tab-completes to .dsc with pbuilder-dist, and to .changes with dput
<pitti> LucidFox: you can't upload (dput) a .dsc
<pitti> LucidFox: and likewise you can't unpack (dpkg-source -x) a .changes, only a .dsc
<pitti> so it's quite obvious
<JontheEchidna> dput installs a file for the bash autocomplete to use: /etc/bash_completion.d/dput
<pitti> likewise dpkg -i expands in *.deb
<geser> LucidFox: it's context-sensitive (i.e. command specific)
<LucidFox> I know, but how does bash know which file to tab-complete t-- oh
<pitti> ah, yes; completion.d/ rules
<JontheEchidna> I imagine the other CLI tools do similar things
<mvo_> JontheEchidna: the missing authentication keys for the ppa are most likely the problem
<mvo_> JontheEchidna: if you add them the origins should become visible
<JontheEchidna> mvo_: ok, neat. thanks
<JontheEchidna> Is there a way to manually add the keys without the keyserver.ubuntu.com lookup?
<JontheEchidna> oh, the PPA page gives the key, nevermind :)
<mvo_> you can manually grab them from launchpad
<mvo_> but that is a bit cumbersome
<mvo_> is keyserver.u.c timeing out for you?
<JontheEchidna> for both software-properties and add-apt-repository, yes
<JontheEchidna> the web interface seems to be working though
<JontheEchidna> well, the import seems to be working now :)
<JontheEchidna> must have fixed itself while I was at lunch
<bigon> dhcp 4 is now in debian unstable, any plan to switch to this version for maverick?
<JontheEchidna> mvo_: yeah, it's all fine now. Origin and origin labels showing up as expected :)
<mvo_> cool
<shadeslayer> jcastro: thanks :D
<td123> does anyone know where I can get the source to the mentioned fixed package all the way at the bottom of https://bugs.launchpad.net/do/+bug/591998 ? I'm mainly interested in the patch they applied to fix this bug
<ubottu> Launchpad bug 591998 in Do "Can't not recive any command" [Undecided,New]
<Laney> td123: you better talk to the gnome do developers
<td123> Laney: it's an ibus issue btw :)
<apachelogger> lex79: you might want to consider backporting my superior desktop file patch in kde4libs to the PPA, should improve performance quite a bit, especially combined with latest pkg-kde-tools
<apachelogger> neversfelde: bug 528259 is on your todo?
<ubottu> Launchpad bug 528259 in kdepim (Ubuntu) "Blogilo "QSqlDatabase: QSQLITE driver not loaded" " [Undecided,New] https://launchpad.net/bugs/528259
<bdrung> to which mailing list can i send legal questions?
<apachelogger> JontheEchidna: in case I forget, I booted cia off kubuntu-devel for now, to revert that just set the basic filtering to custom again :)
<JontheEchidna> apachelogger: kk, I was about to message you about noise pollution in that regard, actually :P
<geser> bdrung: I'd probably try debian-legal as both Debian and Ubuntu share a great part of a common understanding in licenses
<geser> bdrung: and if the questions is very Ubuntu specific, I'd probably mail the TB
<bdrung> geser: it's not a license problem. it's a problem with laws.
<geser> in what way? can you be more specific?
<bdrung> geser: then i mail the TB. i want an answer to the question why libdvdcss2 is not in the archive. i found no answer on the web.
<maxwellian> Oh man, I forgot about Kubuntu tutorials day!
<apachelogger> interesting, apparently one can only decline nominations for all packages, despite affected status -.-
<Riddell> maxwellian: still going on
<apachelogger> yeah, you hijacked my doctor who fan talk channel -.-
<maxwellian> Awesome. :)  I wanted to see the packaging one, but I think I missed it.  Anyway, thanks.
<apachelogger> JontheEchidna: don't blink! :P
<JontheEchidna> not the angels!
<apachelogger> in that case...
<apachelogger> can anyone here the drums? ;)
<apachelogger> s/here/hear
<apachelogger> JontheEchidna: muon build fails horribly if debconf stuff is not there :/
<lex79> apachelogger: iirc the latest pkg-kde-tools needs the latest dpkg :)
<JontheEchidna> apachelogger: don't I have a cmake check for that now?
<apachelogger> I really think a find script would be good there :/
<apachelogger> JontheEchidna: yeah, just that it will fall because the file is not there
<lex79> but I will backport your patch
<apachelogger> which is not a good error message :/
<apachelogger> lex79: well, you can backport my changes to pkg-kde-tools ;)
<apachelogger> lex79: you only need to take the cdbs bits I suppose
<lex79> kk
<lex79> I have to redo kdelibs, they uploaded the wrong tarballs
<lex79> bah
<lex79> 4.5.60 instead of 4.4.92
<apachelogger> that is because dirk is using a custom rip off of markey's amarok release script, instead of using my superior rewrite
<Riddell> dirk messed up?
<JontheEchidna> apachelogger: I will also have to talk to dantti about libdebconf-kde, it currently does not installed a versioned .so, so dh_shlibdeps isn't picking it up as a dependency
<lex79> Riddell: he already fixed in ktown, me not yet :)
<apachelogger> Riddell: it rarely happens I have been told :)
<geser> bdrung: I guess mailing the TB is the best plan. They can forward this to the Canonical lawyer if necessary. I've only found a thread from 2006 but with no clear answer.
<apachelogger> JontheEchidna: updating muon is quite the adventure with all those deps ^^
<apachelogger> JontheEchidna: search is the broken
<JontheEchidna> orly?
<apachelogger> JontheEchidna: search for linux -> does not yield linux-* stuff
<bdrung> geser: the mail is sent to the TB. let's wait for the results.
<Riddell> bdrung: the letterws DCMA would be the reason
<Riddell> although ordered as DMCA :)
<apachelogger> JontheEchidna: search for linux-image works though
<JontheEchidna> apachelogger: it might be that linux-* is below the quality cutoff for "linux" search term
 * apachelogger finds that unhandy
<apachelogger> oh, while I am at it
<JontheEchidna> e.g. other package names/descriptions contain "linux" to place "linux-" below the threshold
<apachelogger> what would be cool is to have a button "nuke all old kernels" ^^
<JontheEchidna> since "linux" is a more exact match
<apachelogger> with such a button I would not mind linux not matching linux-image ;)
<geser> Riddell: but wouldn't this only prevent it from entering main/universe? e.g. the DMCA doesn't apply (yet) to Europe (but they might be other laws in Europe that prevent the legal use there)
<JontheEchidna> I usually search for "2.6.35" or whatever
<apachelogger> even though that is the most appropraite package really :P
<apachelogger> JontheEchidna: well, I had a billion billion kernels installed, as noticed earlier
<JontheEchidna> lol
<apachelogger> spanning across various versions of course
 * apachelogger missed mass marking for action on that occasion too :)
<Riddell> geser: main and universe are mirrored in the US, and in Europe the Copyright Directive 2001/29/EC makes it illegal here too
<bdrung> Riddell: it's in the gray zone in europe.
<JontheEchidna> apachelogger: oh oh, try marking the package "gnome" for install :D
<JontheEchidna> apachelogger: are you in maverick?
<apachelogger> no
 * apachelogger needs to do serious development for master Riddell :P
<JontheEchidna> I'll have to show you then ^.^
<apachelogger> must not have my system broken by lex79 uploading something funny :P
 * apachelogger hugs lex79
<apachelogger> JontheEchidna: pretty please :)
<Riddell> bdrung: Copyright Directive 2001/29/EC is pretty clear
<lex79> my stuff is always good
<JontheEchidna> apachelogger: http://simplest-image-hosting.net/i0-plasma-desktopv18355-jpg.jpg <- apt-get has the same error, so it's not muon. I suppose I should file a bug
<geser> Riddell: does it imply that if a package is illegal in one country with an Ubuntu mirror, it can't be included in main/universe at all?
<Riddell> geser: in a country where canonical has an office yes
<Riddell> where there's a serious likelyhood of canonical getting sued it won't go in the archive
<apachelogger> JontheEchidna: yeah sure, like you couldnt sell this as killer feature :P
<JontheEchidna> :P
 * apachelogger would buy a product that prevented him from having a billion billion kernels ;)
<apachelogger> oh, and associated headers \o/
<apachelogger> JontheEchidna: marking foo as purge, where bar depends on foo, will mark bar as remove - IMHO logical assumption should be that bar ought to be purged too (though I suppose a dialog presenting additional changes with a tick box for purging would be best either way)
<JontheEchidna> hrm, recursive purge
<JontheEchidna> I'd probably have to set an apt setting or something
<JontheEchidna> because when you hit that button, you're really only telling that package to purge, then apt takes care of dependencies and you have no say in what it does
<JontheEchidna> kinda sucks
<apachelogger> meh
<apachelogger> more interesting: http://imagebin.ca/view/sbgYh6V.html
<apachelogger> can not help but noticing that it orders 19 < 22 < 23 < 20 < 21 < 16
<JontheEchidna> that is a lot of headers
<apachelogger> that is an interesting way of seeing the world really :)
<JontheEchidna> that is some compression: http://simplest-image-hosting.net/i0-plasma-desktopa18355-jpg.jpg
<JontheEchidna> (download size vs install size)
<JontheEchidna> apt-get agrees, but I had to check to make sure it wasn't a bug :P
<apachelogger> imagine if that was all lzma ^^
<apachelogger> 3mib vs. 1.2 gib :P
<JontheEchidna> :P
 * JontheEchidna uses the fancy undo button
<JontheEchidna> undo only goes back 20 actions, tho.
<JontheEchidna> to save ur RAMz
<apachelogger> hm
<apachelogger> manually swap it
<apachelogger> that way you can go across sessions
<apachelogger> imagine that!
<apachelogger> you go install foo
<apachelogger> test foo
<apachelogger> dont like it
<apachelogger> open muon again
<apachelogger> press undo
<apachelogger> and voila!
<JontheEchidna> undo gets lost after commit
<apachelogger> that would be brilliant I think
<apachelogger> JontheEchidna: well, manually rebuild it ;
<apachelogger> )
<JontheEchidna> but a history log is definitely a good idea
<apachelogger> if you log it you can go the extra mile and store it in a format that can be reused for cross session undo ;)
 * apachelogger wishes he had a timey wimey detector just to be a bit cooler :/
<apachelogger> JontheEchidna: suggestions on bug 554514 ?
<ubottu> Launchpad bug 554514 in akonadi (Ubuntu) "cant find resource agents" [Medium,New] https://launchpad.net/bugs/554514
<JontheEchidna> abandon all hope -> close
<apachelogger> other than setting it on fire and run while we can
<JontheEchidna> heh
<apachelogger> :/
<apachelogger> akonadi trunk is a whole different code base -.-
<apachelogger> there is not even hope to get that stuff fixed
<JontheEchidna> we could start a role playing game where we pose as various different animals and the reportees have to guess which animal we are
<JontheEchidna> *reporters
<apachelogger> rofl
<kees> can an archive admin take a look at the -7 kernel binaries in NEW?
<apachelogger> JontheEchidna: so, how do I bring this news to the reports without getting shot? there are 41 people affected, which is mostly because that bug is as inprecise as they get :/
<JontheEchidna> apachelogger: bribe an LP admin to silently delete it? :P (just kidding)
<ScottK> JontheEchidna: appmenu in action: http://kitterman.com/kubuntu/appmenu1.jpeg
<JontheEchidna> oh lovely, it has icons and shortcuts now. (It didn't at UDS)
<apachelogger> "due to ethic believes I must not do certain things to dead people, animals or inspects"
<apachelogger> s/inspects/insects
 * apachelogger really should get more sleep
<apachelogger> ScottK: I wonder how that goes under load
<ScottK> apachelogger: That's on my netbook, so everythin is always under load it seems.  Not too bad so far.
<apachelogger> k
<ScottK> Just started playing with it today though.
<apachelogger> dbusmenu has some oddish issues when it comes to high load situations, seeing that menus can have loads and loads of entries that is a bit of concern of mine
<apachelogger> how kubuntu.org will look on fluffy http://imagebin.ca/view/V-aeXjgi.html \o/
<lex79> lol
<Riddell> we should just do that for stock kubuntu.org, would give us a new market niche
<apachelogger> agreed
#ubuntu-devel 2010-07-08
<apachelogger> JontheEchidna, txwikinger, lex79: do you have time for a bug triage week sometime soon? (next week?)
<JontheEchidna> sure
<lex79> I'm out for two weeks since next monday, I will go to Hamburg :)
<apachelogger> Riddell: I'll try to get libcouchdb-qt && a not yet existing desktopcouch overlay for it ;) && the addressbook resource to alpha for next week ... though that has the same problem as the other stuff (gnome-keyring dependent) ... also for some reason I do not think that we will see a not-gnome-keyring dependent ubuntuone-syncdaemon any time soon :/
<Riddell> apachelogger: what is that reason?
<apachelogger> lex79: cool, vacation? :)
<apachelogger> Riddell: no progress on the u1 side of things
<apachelogger> gotta do some poking again
<Riddell> apachelogger: you're a core dev, you could just upload the package with the patch :)
<apachelogger> well, my patch does s/gnome-keyring/kwallet, so it is not any better ;)
<lex79> apachelogger: yes, meet my girlfriend, she is in Erasmus but come back to home in Italy in August :)
<apachelogger> come to think of it, I could just deploy a patched syncdaemon in the u1-kde ppa
<JontheEchidna> bleh, filter by origin has boogs
 * apachelogger really needs to do an alpha to get some feedback :)
<JontheEchidna> my assumptions were wrong :(
<apachelogger> lex79: brilliant, have fun :D
<lex79> thanks :P
<apachelogger> JontheEchidna: you know... assumptions are like workarounds ... ;) ;)
<Riddell> apachelogger: can't you write a patch for syncdaemon which does the right thing depending on the desktop?
<apachelogger> well, I could look into it
<apachelogger> python-keyring is supposed to do that anyway
<apachelogger> (i.e. provide a desktop-independent API)
<Riddell> the new freedesktop standard for it is also under way
<apachelogger> not implemented in KDE though :/
<Riddell> but in the team time, I'd just do a if env(KDE_FULL_SESSION):
<Riddell> mean time
<Riddell> sheesh
<JontheEchidna> Aha!
<JontheEchidna> When iterating over a QHash, the items are arbitrarily ordered. With QMap, the items are always sorted by key.
<JontheEchidna> ^from Qt docs, that explains my bug
<maco> Riddell: sleep time now?
<Riddell> maco: yes
<JontheEchidna> Oh, wait, they're out of order before I put them in the hash
<apachelogger> Riddell: do you want me to give more priority to getting a working UI or the raw essentials of akonadi foo?
<JontheEchidna> :/
<Riddell> although Kubuntu should do a takeover of #ubuntu-devel more often, it's quite fun :)
<maco> :D
<Riddell> apachelogger: my general preference would be getting file syncing working fully before caring about the data stuff
<JontheEchidna> Ah, but QSet is a QHAsh internally...
<apachelogger> okies
<Riddell> but either way is acceptable
<apachelogger> thing is
<apachelogger> full user experience will only be possible in KDE 4.6 anyway, because dolphin lacks appropriate plugin capabilities right now
<apachelogger> so what we can do is everything under the hood (authentication + getting the sync daemon all hooked up) but the dolphin integration will stay a bit behind expectations
<apachelogger> JontheEchidna: well, either way you should not use a data type that is not guaranteed to maintain a specific order where you need order IMHO
<JontheEchidna> yeah, but I also want no duplicate items in the list. I suppose I could use qlist and remove dupes manually
<apachelogger> ...imagine someone else does changes to the code in 1 year and does not know about the implicit order requirement... :/
<apachelogger> JontheEchidna: well, if you insert by key you would just overwrite any previous item in a QMap I suppsoe
<JontheEchidna> oh yeah, qmap doesn't allow dupes either
<Riddell> apachelogger: are there changes being made in 4.6 to improve plugins in dolphin?
<apachelogger> Riddell: that is the idea, no definite plans yet ... but something like putting the current VCSplugins on a generic base from which we can then draw what we need for u1 integration, most importantly more control over what goes on and when
<apachelogger> most importantly I want the ability to register for directories, because currently the .ubuntuone file is only necessary because the only way dolphin can tell whether to use a plugin or not is by asking the plugin for what dot-file it expects :S
<mathiaz> is there a way to get the list of binary packages with their description for a given source package using the LP API?
<slangasek> lifeless: could you trigger a retry of the UDD import of aptitude?  It complained about a missing tag, which I've manually added, but no retry since the 20th of June
<lifeless> slangasek: I think I might be able to. But i'm going to see if a losa can first.
<slangasek> ok!
 * lifeless counts the seconds till a losa pops up :)
<spm> 'udd import'??
<spm> heh, evil bugger
<lifeless> james_w's package importer service
<lifeless> spm: I think you added a ref to the losa docs a few weeks back about this very issue
<slangasek> lifeless: fwiw, that this error was hit at all tells me there's still a problem with the upstream branch tagging - possibly specific to packages that have had the merge done by a dev rather than by the importer
<spm> oh that thing. right.
<lifeless> mathiaz: I'm pretty sure there is
<slangasek> because my last merge of this package was done *after* our last conversation where you mentioned that the cause of the missing tags was fixed
<lifeless> mathiaz: have you had a poke around the API docs ? Its likely not a single call at the moment (and perhaps it needs to be)
<mathiaz> lifeless: I've looked at the api doc and I can't find it
<lifeless> mathiaz: ok, gimme a couple of minutes and I will have a poke at it with you
<lifeless> slangasek: yup
<slangasek> (I had already been suspecting this to be the case, given the high incidence of this issue on packages I've previously merged :)
<mathiaz> lifeless: https://edge.launchpad.net/+apidoc/devel.html
<lifeless> slangasek: I have another couple of days directly working on this
<slangasek> ok
<mathiaz> lifeless: ^^ doesn't show anything special
<lifeless> slangasek: but then my focus will be ... broadning
<lifeless> spm: https://wiki.ubuntu.com/DistributedDevelopment/UnderTheHood
<slangasek> lifeless: does that mean there will be someone else I should prod about bugs? :)
<lifeless> slangasek: so I'm the new Launchpad TA
<lifeless> slangasek: Once I track down the right people in prague to discuss UDD, we'll know what team(s) are responsible going forward
<lifeless> slangasek: and even after that I'll still be very interested.
<lifeless> slangasek: but not directly hacking on it myself
 * spm praises james_w and documenting everything I need \o/
<lifeless> spm: favour for me please.
<spm> sure?
<slangasek> lifeless: "TA"?
<lifeless> spm: when, in doing one of these things, you think it would be reasonable for an Ubuntu dev to 'make it happen' themselves - please file a bug somewhere.
<spm> slangasek: Tech Architect
<slangasek> ah, not teaching assistant
<slangasek> ok :-)
<lifeless> spm: and each time it happens poke in the bug that its affecting you - to keep it visible.
<spm> well..... this is debatable....
<spm> lifeless: sure. I'm honestly not sure on something like this.
<lifeless> spm: thats ok, so - in this case, are you applying any policy questions other than 'slangasek wants it' ? :)
<spm> lifeless: tho... from a brief, not analysis look; failing from codehost going offline and needing manual intervention does seem unnecessarilly fragile.
<lifeless> spm: definitely, that needs a bug, I think an incident report would be a bit heavyweight for now.
<spm> lifeless: 'slangasek wants it' is a policy in our policy documents. Number 6 or 7 frommemory
<slangasek> heh
<slangasek> spm: you may want that updated to say "the release manager wants it"? :)
<spm> no... I think we have it right atm. ;-)
<spm> heh. ./show_failure.py --help ==> --help has not failed
<spm> almaisan-away: in any event, aptitude is resubmitted whatever, the 700+ other failures do worry me - I suspect they're all tied to the release yesterday morn somehow.
<spm> gah sorry almaisan-away. slangasek ^^
<slangasek> spm: well, failures have been accumulating for a while and for the most part only resolve when someone has a chance to pick off the bugs
<slangasek> 700+ isn't a pretty number, but doesn't alarm me
<spm> ah, kk, I'll let it slide for now then
<lifeless> there is a situation where it will clamp up and stop
<lifeless> which is, i think, codehost downtime
<lifeless> I opened a bug with a plausible explanation
<spm> ah, ta.
<james_w> fwiw, there's automatic retries in the face of certain failure conditions, of which this should be one
<james_w> if it's like http://package-import.ubuntu.com/status/udav.html then it will be retried soon
<lifeless> james_w: right, slangasek was asking for 'now please'
<james_w> there's a bug that only the index page tells you that and not the individual page
<lifeless> james_w: you know these devs, impatient folk.
<james_w> sure
<lifeless> :P
<james_w> I was responding to "failing from codehost going offline and needing manual intervention does seem unnecessarilly fragile."
<lifeless> right - thats the bug I opened last release, I think :)
<spm> Ahh. coolio. I was wrong in my assumptions. excellent.
<slangasek> james_w: how frequent and where does the index page tell this?  The per-package page says last attempt was 20 Jun
<james_w> slangasek: that one is certainly different then
<james_w> under udav near the top of http://package-import.ubuntu.com/status/ it says "and will be retried automatically around 2010-07-08 02:18:31.725122"
<james_w> perhaps overly precise, but still
<slangasek> oh, and the index page only shows that detail for the last 50 failures
<slangasek> so for aptitude there was no indication whether a retry was intended
<maxwellian> james_w: I don't usually use "around" with a time that's precise to fractions of a millisecond. ;)
<james_w> maxwellian: then you're just not trying hard enough
<slangasek> it's a LP tradition to be precisely inaccurate
<slangasek> like the Ubuntu release dates that were specified to the minute :)
<james_w> both filed, thanks
<maxwellian> Heh. :)
<slangasek> james_w: cheers!
<james_w> first step to getting fixed at least
<wrinkliez> hey guys, im creating a source package for windows (first time! woot).  and im at the section section (what?) of the control file.  is there like a list of sections i can look at?
<RAOF> wrinkliez: Yup.  Debian policy has a list of the current sections.
<RAOF> http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections
<wrinkliez> ah great, exactly what i wanted. thanks man
<wrinkliez> and all of these are the same for ubuntu?
<wrinkliez> any sections i can use for one but not the other?
<RAOF> Same sections in Ubuntu.
<lukehasnoname> Where would I tell a developer or packager about package dependency issues in Maverick? Launchpad Bugs is not the place, I'm told.
<RAOF> Who told you that?
<RAOF> Unless it's a transient arch-skew dependency issue, Launchpad is absolutely the place.
<lukehasnoname> Brian Curtis, via a similar bug post
<lukehasnoname> At this time since all the packages can be out of sync at times, and because you are using the development release of Ubuntu this isn't a bug. Wait for the packages to get updated and it should fix itself.
<lukehasnoname> " "
<RAOF> Right.  Transient arch-skew.
<RAOF> If you're not sure whether it's a transient problem or not you c.  There'll still be a lot of transient dependency problems at the moment, though.
<lukehasnoname> OK, I don't understand why that would happen, but I'll go with it. My issue, for example, is that logging in Empathy is broken ATM in Maverick because telepathy-logger, the new empathy logging tool, isn't depended on.
<lukehasnoname> this change was made in empathy with the latest gnome updates a few days ago, and when I installed the package logging started happening again
<lukehasnoname> RAOF, assume it'll be fixed?
<RAOF> lukehasnoname: Indeed.  My update today pulled in telepathy-logger.
<LucidFox> Is it possible for me to get my access to the private fonts PPA revoked? I feel dirty just for being able to access it.
<LucidFox> Right. I suppose a better question would be: is it possible to get one's Ubuntu Member status revoked while retaining the @ubuntu.com address?
<lifeless> AFAIK, no.
<lifeless> whats wrong with the PPA ?
<mneptok> LucidFox: not to my knowledge. an @ubuntu.com e-mail address is a privilege of membership.
<LucidFox> Blimey
<LucidFox> I have too many things tied to that address :(
<lifeless> what is your concern with the PPA?
<LucidFox> lifeless> Soon Planet Ubuntu should pull my post detailing what I find wrong with this whole concept of a closed beta.
<wgrant> There were reasons given during the UDS talk, IIRC.
<wgrant> I don't like it either, but, well...
<LucidFox> Why is it named ubuntu-private-nda-fonts? Did I implicitly get signed an NDA without my knowledge?
<wgrant> LucidFox: They've said that the font isn't going to be proprietary.
<LucidFox> Right now it is.
<LucidFox> Apparently it wasn't enough that the default install includes a client for a Canonical-run proprietary file syncing service
<wgrant> The default install does not include a proprietary font.
<wgrant> This is not in the default install yet.
<LucidFox> But it's going to be. The default install is going to include a font that, right now, is proprietary and members-only.
<wgrant> Right now it is, yes.
<wgrant> Lost of things start off in development behind closed doors.
<LucidFox> But that's limited to developers.
<wgrant> No, this is not optimal, and I've been most critical of U1 and LP (while it was closed).
<wgrant> IIRC they don't want it distributed too widely, since they're still tweaking metrics and the like.
<wgrant> That was one of the reasons given; I do not recall the full rationale.
<LucidFox> I'm not a developer of this font, yet I got implicitly signed an NDA for this closed beta that I want to opt out of.
<wgrant> I don't think there's an NDA. I certainly haven't seen one. Perhaps there was before, before it was opened to community members.
<ScottK> If you didn't sign an NDA, then there's no NDA.
<j1mc> there's an article on arstechnica that shows the font... i don't really see how their could be an nda at this point.
<wgrant> The misleading name may simply be an artefact of the upgrade path requirement.
<j1mc> though i know the package name includes NDA in it
<LucidFox> The package name is ubuntu-private-nda-fonts
<wgrant> ScottK: Well, clearly.
<ScottK> I find it somewhat odd that they are distributing it while the license is undecided.
<wgrant> It is odd and probably unusable, yes.
<j1mc> if anyone has a few minutes, would you mind reviewing a packaging guide survey i put together?  http://spreadsheets.google.com/viewform?formkey=dHZEVGFLNkROMnROQ2FBVUdjRGlTYnc6MA
<j1mc> you DON'T need to fill it out
<j1mc> just let me know any feedback before i put it up
<j1mc> feedback... with regards to the questions i'm asking - if there's something else i should ask, or if i should ask something in a different way.
<j1mc> if it makes you cry, i would want to know that, too.
<ajmitch> j1mc: it's a little hard to answer some of those questions about what's missing from the packaging guide if I've answered that I very rarely reference it :)
<ajmitch> though at least those questions aren't mandatory
<j1mc> ajmitch: good point - not sure what i can do on that.
<j1mc> i didn't set any questions to be mandatory, so i'll certainly take that into consideration if you don't answer them.
<ajmitch> I haven't submitted anything, just read through most of the questions so far
<j1mc> sure - i haven't released it upon the world yet... daniel holbach has given me some feedback, but no one else really, yet.
<j1mc> ajmitch: would it be helpful to ask, "if you rarely reference the guide, why is that?" (or something similar) and then let the person know they can stop the survey...?
<j1mc> bbiab
<ajmitch> it could be useful to ask that & then skip to the last section about what packagers may need
<MagicFab> hi all
<MagicFab> what would be the difference between regression-release and regression-update ?
<j1mc> ajmitch: thanks
<j1mc> g'nite, all
<jcastro> ScottK: in wordpress there's an option to enable "full text feeds", if you enable that your blog posts won't be cut off on planet.
<ScottK> jcastro: Thanks.  I was just wondering about that exact thing.
<ScottK> jcastro: Did you like that one?
<ajmitch> the link to the post just links back to planet.ubuntu.com
<jcastro> ^^^
<jcastro> ScottK: the card game looks amazing!
<MagicFab> nevermind, found it
<ScottK> jcastro: I picked that because it shows of the beauty of KDE nicely.
<jcastro> ScottK: the Close X on the right is pretty genious
<jcastro> way more genius than my spelling today!
 * maco is getting a netbook preinstalled with KNR :D
<ScottK> jcastro: That's part of the standard Plasma Netbook interface (and I agree).
<maco> i like that newspaper view plasmoid
<maco> even on my fullsize laptops, i'd like that
<ScottK> maco: zareason?
<maco> ScottK: yep
<maco> i dont know of any other oems that do kubuntu
<maco> dell, hp, and s76 all do ubuntu but not kubuntu
 * ScottK neither.  That's why I guessed them.
<maco> riddell was surprised when "what os does it come with?" had that answer :)
<maco> i told him one step toward world domination ;-)
<maco> (since he was talking about world domination during tutorial day)
<ScottK> Nice.
 * ScottK is off to bed.
<maco> oh!
<maco> that screenshot is much more pleasant than what i expected
<maco> ScottK: good night
<maco> i thought it would be mac-style global menu. the hidden menu though...thats not bad
<ScottK> jcastro: wordpress.com is smarter than me tonight.  I'll look for it again tomorrow.
<ScottK> It'll do the mac style thing too.
<ScottK> That's not what we're looking at for Kubuntu netbook though.
<jcastro> LucidFox: ScottK: wgrant: the name nda in the package is a bug: lp #602835
<ubottu> Launchpad bug 602835 in UbuntuFontBetaTesting "Packaging states deprecated requirement to sign NDA" [High,Triaged] https://launchpad.net/bugs/602835
<LucidFox> ...So there was an NDA earlier in its development.
<jcastro> I guess
<wgrant> Well, it could well have been to indicate that it was covered under the normal Canonical NDA. That's what I would assume.
<jcastro> it would behoove us to fix it asap, I've pinged ken about it
<jcastro> LucidFox: I realize it's odd and not ideal
<LucidFox> There's a "normal Canonical NDA"?
<jcastro> all companies have NDAs, if you're doing contract work, etc.
<Damascene> hi,
<Damascene> ArneGoetje, there?
<pitti> Good morning
<dholbach> good morning
<wgrant> pitti: I have branches that give native ddeb support to PPAs, but primary archive stuff is still not finished, since it's not clear how we want to expire them to conserve librarian space.
<wgrant> I should probably try to start that discussion somewhere.
<pitti> wgrant: ah, thanks; when do normal packages expire?
<pitti> wgrant: i. e. is the difficulty to expire them after a different grace period than regular debs?
<wgrant> pitti: At the moment we only expire non-final binaries from obsolete series.
<pitti> wgrant: ah, right, I just thought about expiration on the archive, not in soyuz itself
<wgrant> We could probably expire them earlier, but it would require changes to the copying code, which is why I haven't written it yet.
<pitti> wgrant: right, I think we can discard non-current ddebs after a week
<pitti> they take an insane amount of space
<wgrant> pitti: Do you have numbers for how much the entire current set takes per arch?
<pitti> wgrant: hang on
<wgrant> I need to give the LOSAs a heart attack :)
<spm> .....
 * spm thinks wgrant is of the 'revenge is a dish best served cold' school
<ajmitch> spm: I don't think you're meant to be watching this conversation :)
<wgrant> Damn, forgot you lurked in here :P
<spm> ajmitch: I was reading it; does that change the dynamic at all? ;-)
<pitti> wgrant: du is running..
<wgrant> pitti: Thanks.
<dholbach> â¦ still running â¦
<pitti> wgrant: so we have 5 arches (i386, amd64, lpia, powerpc, sparc) and 5 releases (hardy to maverick), which take 146 GB pool/ space
<pitti> wgrant: since lpia died in between, it's not that accurate to divide by 25, though
<pitti> and ports have a lot of ftbfs, too
<pitti> wgrant: so perhaps 10 GB per arch and release sounds realistic?
<pitti> hm, wait, that can't be
<pitti> I thought I removed some ports
<wgrant> spm: Is mizuho creaking at those numbers yet?
<pitti> right, I killed lpia completely
<pitti> wgrant: let me clean up lpia properly and count agani
<spm> wgrant: hrm. not sure I appreciate the nuances there, is that 146Gb to be added? or removed? or?
<wgrant> spm: Added.
<pitti> and I stopped retrieving ports as well (except armel)
<pitti> wgrant: so, I think 12 GB per arch and release
<pitti> this includes the usual sharing of versions between releases, but that'd affect Soyuz all the same
<spm> we have space for that yeah, but that will have a corresponding hastening on getting more added
 * pitti will remove jaunty
<spm> err. assuming that's a single 146Gb. not multiples of same.
<pitti> spm: my entire ddebs.ubuntu.com pool/ is 146 GB ATM
<pitti> spm: but as I said, I filter out most ports
<pitti> there's some cruft, though
<spm> pitti: heh, fair enough. any chance of removing karmic and lucid while you're at it? no reason for asking... ;-)
<pitti> we certainly do want to keep hardy and lucid
<spm> damn. he's seen thru my cunning plan.
<pitti> karmic can probably go after maverick's release
<dholbach> spm: try harder :-P
<wgrant> I guess I can make the copier deal with it if ddebs are missing.
<wgrant> Revolting, but they're huge, so we'll need to expire them far earlier than everything else.
<spm> wgrant: it's probably worth getting julian (I assume) to raise this space issue via an RT or in the bi-weekly call. Just to ensure all the details are understood by those who make the decisions?
<wgrant> spm: Well, yes, I was just getting an idea of how big we were talking, and was going to bring it up with Soyuz when they were next around.
<spm> coolio, great minds etc
<pitti> well, I guess this would be a gradual buildup anyway?
<pitti> or is there a chance that we could import the current ddebs into that?
<wgrant> pitti: I think it would have to be gradual, I'm afraid.
<pitti> right, so we need some tricks to merge the old ddeb archive with the new soyuz-generated one
<pitti> with the easiest one being to ask people to just add two deb sources :)
<wgrant> Or just stick both in the retracers' sources.lists.
<wgrant> Right.
<wgrant> Then we can demolish the non-virt builders, pool the i386/amd64/lpia builders, and make the build farm a happier, more efficient place.
<wgrant> And use stock sbuild.
<wgrant> And that makes me happy.
<pitti> wohoo
<pitti> wgrant: oh, how can we build ports on virtualized PPAs?
<wgrant> pitti: Well...
<wgrant> LP 10.06 lets us nominate certain architectures as being restricted.
<wgrant> Archives need special configuration to be able to use restricted architectures.
<wgrant> For example, there'll be 'virtual' armel builders soon, which aren't actually virtual. This will let OEM PPAs be marked as virtual, but still build on armel.
<wgrant> It still has the big security issues, of course.
<wgrant> But that's what you get for platforms that don't do virt.
<wgrant> But the new system enables more flexibility with which architectures PPAs build on, and will let us safely remove the virt/non-virt distinction once ddebs are out of the way.
<pitti> wgrant: right, I'd be happy to see some unification there
<pitti> wgrant: it's sad to see three i386 buildds grinding through 800 langpacks while 20 other buildss just twiddle thumbs and amusedly watch them
<wgrant> pitti: Exactly.
<pitti> or the other way round with PPAs
<wgrant> I have a branch that makes the x86 buildds build whatever is available.
<wgrant> So there'll be something like 60 buildds available to build any given i386/amd64/lpia package.
<wgrant> Which will be handy, and eliminate the lag that i386 sees due to arch-indep packages building only there.
<pitti> nice
<pitti> we have had some amd64 congestion for quite some time now
<wgrant> I've found that a bit odd.
 * lag starts to thing that lag was a bad nick choice! ;)
<lag> think*
<wgrant> lag: No, no, my branch eliminates you. No mistake there.
<lag> ;)
<ogra> lamont, could it be that acorn died ?
 * ogra cant get a w3m connect
<ogra> hmm, does anyone know how to log in to LP via w3m ?
<ogra> i get the openid page but the continue link doesnt work
<geser> ogra: try with elinks. Bug #556927 mentions problems to login to LP with w3m.
<ubottu> Launchpad bug 556927 in Launchpad Foundations "apport-collect: login to launchpad impossible in text mode using w3m" [Low,Triaged] https://launchpad.net/bugs/556927
<ogra> ah, thanks
<pitti> wgrant, spm: cleanup run finished; 111 GB for three releases and 2.5 arches
<pitti> (.5 because hardy didn't have a lot of arm ddebs yet)
<wgrant> pitti: You mean jaunty? Hardy didn't have armel at all.
<pitti> wgrant: right; jaunty is gone, it's just hardy, karmic, lucid, maverick now
<pitti> ah, 4 releases
 * pitti shouldn't count from 0 :)
<wgrant> Heh.
<wgrant> So roughly 12ishGB, as you estimated earlier.
<wgrant> Thanks.
<lamont> ogra: acorn died yesterday, I think someone was going to go stab it back to life today..
<ogra> lamont, k, thanks ... archive is out of sync anyway
<apw> cjwatson, ok i've put a cleaned up version of this bios fbcon stuff over onto some real h/w, and we do seem to still get a mode-switch from plymouth to X, not sure how to tell why
<apw> cjwatson, i suspect this is cause the mode is actually different
<apw> http://people.canonical.com/~apw/fbcon-hold-maverick/ <-- cjwatson updated kernels are here
<cjwatson> apw: planar->tiled perhaps
<apw> cjwatson, i presum we are expecting this ?
<cjwatson> I think it happened before as well, didn't it?
<apw> before?
<cjwatson> with the current kernel in the archive
<kaushal> hi
<apw> with your grub yes
<cjwatson> certainly a mode-switch there isn't unfamiliar to me ... might be worth asking RAOF though
<kaushal> I have a wierd issue about disk space. my pastebin is here http://pastebin.ubuntu.com/460588/
<apw> with the regular grub setup, there is no modeswitch between plymouth and X
<cjwatson> oh, odd, I guess plymouth is doing something better than a vesa mode
<kaushal> I dont get count of approximately 43 Gb
<kaushal> Any ideas ?
<cjwatson> kaushal: please ask on #ubuntu
<kaushal> cjwatson: sure
<cjwatson> apw: any chance of a way to set the handoff flag via struct screen_info?
<kaushal> Thamls
<kaushal> Thanks*
<apw> cjwatson, well the machine in question has a 1024x600 native
<cjwatson> i.e. to go with VIDEO_FLAGS_NOCURSOR
<cjwatson> apw: so grub doesn't know how to deal with native modes, unless VBE exposes it
<apw> cjwatson, perhaps, i have been testing with it just added to the kernle command line for now
<cjwatson> in such cases, there has to be a mode switch at *some* point
<cjwatson> so the question is whether we want the mode switch on grub->plymouth or on plymouth->X
<apw> cjwatson, i suspect that means the very common case is a mode switch mid boot
<cjwatson> apw: right, I just don't want to have to do stringwise editing of the command line in grub
<apw> cjwatson, why would you need to do that in grub?
<cjwatson> because the decision on whether to keep the existing video mode is dynamic
<apw> hrm ok
<cjwatson> it depends on things like the type of video mode grub managed to probe at runtime
<apw> cjwatson, so i'll have a look then
<cjwatson> ta
<apw>  cjwatson oh an the cursor seems to be on at the moment on real h/w ... seems to be a difference from the VM
<cjwatson> apw: 'if (vt_handoff) vt_handoff = 0;' seems redundant
<apw> possibly we are losing visibility of it in the VM due to the changes based update
<apw> cjwatson, we need to clear it on mode swtich ?
<cjwatson> could be, I did try using VIDEO_FLAGS_NOCURSOR but it has a similar kind of problem - you need a way to turn it back on when you've finished booting
<cjwatson> apw: I mean you might as well just say 'vt_handoff = 0;'
<apw> well that dirties the cache line evret tim, whiis evil
<cjwatson> oh, hm
<cjwatson> ok, I bow to your superior expertise :)
 * apw hits his e key ... why does your disk being busy break xchat mid input line
<geser> StevenK (or any other archive admin): Could you please kill default-jdk-builddep from the NBS list. default-jdk-builddep got renamed to gcj-native-helper (which still provides default-jdk-builddep) and the stale deb prevents that packages build-depending on it can't currently get build. Except tex4ht all dependencies on default-jdk-builddep are unversioned so they are still fulfilled by
<geser> gcj-native-helper. For tex4ht bug #603101 awaits sponsoring. Thanks.
<ubottu> Launchpad bug 603101 in tex4ht (Ubuntu) "Make the build dependency on default-jdk-builddep unversioned" [Undecided,New] https://launchpad.net/bugs/603101
<\sh> jcastro: ping
<apw> cjwatson, can i not already tell which buffer you chose from the VIDEO_TYPE ?
<cjwatson> apw: which buffer?
<apw> cjwatson, sorry i mean do you not already pass me the frambuffer mode you chose ?
<cjwatson> no, you just know "it's VESA" AFAIK
<cjwatson> oh, it's in the screen_info structure
<cjwatson> I don't know offhand if that's precisely enough information to reconstruct the VESA mode
<cjwatson> but in any case, it's not necessarily the desired final mode
<cjwatson> enough information> you get height/width etc., not the actual VESA mode number
<apw> cjwatson, no indeed.  so it looks like there is only one flag in that byt,e, want to spin me a patch to set the bit in grub, and i'll have a go at it
<cjwatson> apw: something like http://paste.ubuntu.com/460598/ - it would probably need more checks than that in real life
<apw> cjwatson, don't think the padding needs to change size does it, the byte is still a byte
<cjwatson> it's an array of bytes which needs to get one shorter ...
<apw> cjwatson, no as you didn't use any additional bytes did you ?
<apw> oh you did, stupid me
<apw> i didn't see the + as i was expecting the flags to be there already
<apw> for the cursor on off which i thought was already supported
<apw> cjwatson, in other words yes thats looking great
<jdstrand> seb128: hi! would you mind taking a look at bug #597940? it is a very annoying bug for those that seem to hit it (one happens to be my wife, but people are blogging about it with workarounds posted on Planet Ubuntu)
<ubottu> Launchpad bug 597940 in gnome-panel (Ubuntu) "duplicate icons and miss icons in the gnome-panel" [Medium,Confirmed] https://launchpad.net/bugs/597940
<jdstrand> seb128: it had been stuck at Incomplete, but I changed that and the priority. It maybe should go even higher (see my comment), but I'll let you decide that
<apw> cjwatson, that patch changes a file i don't see to have, i suspect it is the copy of a file
<jdstrand> seb128: fyi-- I asked tedg about this issue at UDS, and he speculated it might be the indicator applet. it was a wild guess, so take it with a grain of salt. neither of us (at least at the time) had looked at any code or bugs
<cjwatson> apw: which one?
<apw> cjwatson, bah ignore me, seems if you use -p1 they apply to the wrong file
<seb128> jdstrand, hey
<cjwatson> apw: http://paste.ubuntu.com/460603/ -> more familiar formatting perhaps
<seb128> jdstrand, https://bugs.edge.launchpad.net/ubuntu/+source/gnome-panel/+bug/439448
<ubottu> Launchpad bug 439448 in gnome-panel (Ubuntu) "visual corruption affecting several panel applets" [Medium,Triaged]
<seb128> jdstrand, is that this one?
 * jdstrand looks
<seb128> jdstrand, in short, nobody in our team has any clue what's going on and how to start debugging
<seb128> jdstrand, we would very much like to get it squashed though...
<seb128> jdstrand, it's probably bug number 1 on our list of annoyance in lucid
<jdstrand> seb128: I'm still looking at that long bug, but I can say this: the hallmark sign of the bug for me is that the power button icon goes away and there is no way to logout via the desktop (obviously can use a terminal)
<jdstrand> seb128: I've not seen the issue on any of my computers, but my wife sees it at least once a week
<seb128> I don't get it a lot there
<jdstrand> seb128: I have seen my applets out of order occassionally
<seb128> we are still at a fail to know in which cases it triggers or what could trigger it
<seb128> the ordering bug is another known one
<seb128> especially if you change screen settings
<Tanguy> Hello.
<seb128> ie have a laptop and dock, undock it
<Tanguy> Do you know if there are currently problems with Launchpad?
<seb128> but that's a different issue than the corruption one
<seb128> Tanguy, hi, try #launchpad?
<Tanguy> Indeed. :-)
<jdstrand> seb128: yes, I think the ordering has to do with attaching an external monitor, which my wife does not do, so I figured that was a different bug
<jdstrand> seb128: let me rephrase
<jdstrand> seb128: I only saw that when attaching/detaching an external monitor, so thought it was different
<seb128> right, they are different
<seb128> the ordering bug has always been there
<seb128> it's likely the corruption one is due to the indicators
<seb128> but I've no clue what and why
<seb128> it happens on random applet
<seb128> and is a visual corruption
<seb128> changing the gnome-panel settings workaround it
<seb128> I got it a few times, I could move the applet but it stayed corrupted
<seb128> jdstrand, ie in your case the session button is probably there and can be opened using the keyboard
<seb128> super-s
<seb128> it just seems to not be layed out of the gnome-panel for some reason
<jdstrand> seb128: the workaround I used was found in http://en.andregondim.eti.br/?p=160, which is 'Alt+F2' followed by 'killall gnome-panel'. That is less than ideal ;)
<seb128> right
<seb128> if you read the bug I pointed some people tweak gnome-panel settings
<seb128> or move the orientation
 * jdstrand continues to read
<jdstrand> seb128: fwiw, my wife ran jaunty, then upgraded to karmic and then lucid the same day, so she never had a chance to see it in karmic
<seb128> jdstrand, it was there in karmic
<seb128> I'm not sure if it become increasing in frequency in lucid
<seb128> or if we just have higher number of users
<jdstrand> yeah, I saw that the report came in against 9.10
<seb128> if ted had any clue on what could create the issue that would be useful
<jdstrand> well, I only mentioned ted so you had all the info I had-- to be fair, that was a while ago and we were just chatting over a donut or something
<seb128> ok
<seb128> I would probably have told you I though it was indicator related as well
<seb128> but in practice it doesn't put us any closer of understanding what could be going on
<jdstrand> seb128: I'm at comment #15-- fyi wife does not have nvidia and she does have 32 bit
<seb128> I would be interested to have somebody who get the bug reliably to get debug infos though
<seb128> jdstrand, I think we can exclude any sort of video driver issue
<jdstrand> yeah, it is like once a week or so :\
<seb128> it happens on all sort of hardware
<seb128> we tried to turn off gtk client side which could have been an issue but it's not it either
<jdstrand> seb128: it also doesn't have anything to do with suspend/resume, as my wife doesn't do that
<jdstrand> seb128: so in comment #66, someone finally posted a screenshot of the bug I see (ie the shutdown button is missing). While I have seen the duplicate icons issue, that is more livable than the shutdown one. do you feel that comment #66 fits with everything else? I kinda do, but that bug is kinda all over the place so don't want to just duplicate it willy-nilly
<jdstrand> #70 also shows it
<jdstrand> ok, later comments people are talking more and more about the shutdown issue
<seb128> jdstrand, not sure to understand the question there
<jdstrand> seb128: I was looking for guidance, but no longer need it. I feel strongly it is a dupe and will mark it as such
<seb128> jdstrand, there is one bug I think, it just corrupts randomnly applets and indicators
<jdstrand> seb128: I'm still reading all the comments :)
<seb128> there is quite some of those, and yeah when it breaks the session indicator it's rather annoying since it breaks the way to stop the computer
<jdstrand> seb128: yes, and in the default install, there is no shutdown icon anywhere in the menus, etc
<seb128> well there is one in the corner which is enough when it doesn't get broken ;-)
<jdstrand> seb128: I'll provide a workaround for my wife and try to reproduce, but not hugely hopeful. intermittent bugs stink
<jdstrand> seb128: hehe, yes :)
<seb128> right, having the bug once a week makes debugging difficult
<seb128> it's not even easy to try potential fixes because not having it in 2 weeks doesn't mean it's fixed
<seb128> it's just that you could be a lucky for a week
<jdstrand> yeah :(
<cjwatson> pitti: what do you think about colouring INPROGRESS differently from TODO on work items charts?  we were talking about this in the foundations meeting yesterday
<ricotz> siretart, hello, are there plans updating/merging xine-lib?
<siretart> ricotz: I have a merge ready, but I have problems pushing the changes to launchpad. the merge just needs some testing and uploading
<ricotz> siretart, ok, i had just a look at https://merges.ubuntu.com/x/xine-lib/
<joaopinto> mvo, ping
<maxb> Hello, could I have a give-back on https://edge.launchpad.net/ubuntu/+source/subversion/1.6.12dfsg-1ubuntu1/+build/1853955 please?
<mvo> hey joaopinto
<ScottK> maxb: Done
<maxb> thanks
<maxb> Does anyone know about java segfaulting on armel? I'm uncertain what to do with the subversion maverick/armel FTBFS  (https://edge.launchpad.net/ubuntu/+source/subversion/1.6.12dfsg-1ubuntu1/+build/1853956)
<apw> cjwatson, ok that seems to be possible
<apw> s/possible/work ok/
<joaopinto> mvo, hey, a question about APT from a generic perspective, is it valid to have the same package in the same release contained in multiple components ?
<joaopinto> since Index is kept or a per release/component basis it can be done, but I am unsure if it's valid from a design perspective
<joaopinto> erm, I mean "Packages"
<mvo> joaopinto: what is your use-case?
<joaopinto> mvo, this is to help in a decision to define an archive structure, the goal is to have a "beta" and "stable", they can be implemented as releases or components
<joaopinto> on a regular archive I have never seen a package contained on multiple components for the same release
<joaopinto> I think the best solution is to use releases, but I didn't find anything invalidating the use of components for the same purpose
<cybersnoop> Wow.. something went pretty wrong with my SSD on 2.6.35-7 (on lucid).
<cybersnoop> System nearly locked-up. When I switched to tty1 I saw some messages from "ata3" about being unable to flush and failed command DRDY
<cybersnoop> Now these messages don't appear in /var/log/messages .. probably because that's on the same SSD
<mvo> joaopinto: it should work fine but its a bit unusal afaics. the only thing is that you need to ensure the packages are really the same (I guess that is obvious) if they have the same (name, version)
<cybersnoop> Is there anyway I can be of any help for kernel-developpers with this error?
<joaopinto> right, reprepro enforces that by validating the md5sums
<joaopinto> mvo, thanks
<mvo> cheers
<ebroder> Has anybody tried to use the live CD creator on an Android phone?
<ScottK> jcastro: Thanks for the hint.  I finally fixed it....
<pitti> cjwatson: anything is possible, of course; we'd need to actually start tracking "in progress" as a separate state (it can't be represented at the db level right now), and it's some code changes; I estimate two hours for the changes and testing
<cjwatson> pitti: do you think it's a worthwhile thing to do?  there are enough inprogress items on my team right now that I'd be willing to do so
<pitti> cjwatson: not from my side really, since the difference between "todo" and "inprogress" isn't that interesting in terms of planning
<pitti> cjwatson: (lagged, me @ phone)
<cjwatson> ah, the reason I find it interesting is that if work items are insufficiently granular for some reason then it means that progress is visible rather than artificially reduced
<gnarl> pitti, cjwatson I just uploaded lucid mvl-dove and ec2 which are rebases to the kernel we already got up in proposed. Can those get accepted?
<cjwatson> looking
<gnarl> thanks
<cjwatson> smb-afk: done
<smb-afk> cjwatson, Yeah, saw the mails coming in. Ta
<cjwatson> pitti,slangasek: could you review base-files and debian-installer in lucid-proposed?
<apw> cjwatson, so kernels which implement the check via 'flags' seem to work for me, also think i have the cursor turned off now.  kernels uploading to here now:  http://people.canonical.com/~apw/fbcon-hold-maverick/
<cjwatson> ok, I'm battling with my attempt to implement 'linearfb'
<cjwatson> which is being less than a perfect model of glorious success right now
<apw> cjwatson, ok ... hopefully that can give you some idea what it looks like on real h/w
<cjwatson> jdstrand: could you have a look at busybox in NEW?
<jdstrand> cjwatson: k
<apw> cjwatson, ok just tested the amd64 one on real h/w with your double patched grub and its looking pretty good ... obviously we have the mode switch to X due to the non-vesa native mode
<pitti> cjwatson: can do later on, just need to start a rather large build first
<jdstrand> cjwatson: looks like it got held up on the new busybox-syslogd. accepted
<pitti> lamont: the current qt4-x11 armel FTBFS in maverick looks like someone forcefully cancelled the build, is that right? i. e. it's not a "real" ftbfs in the "bad package" sense
<pitti> lamont: https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.7.0~beta1+git20100706-0ubuntu1/+build/1856835/+files/buildlog_ubuntu-maverick-armel.qt4-x11_4:4.7.0~beta1+git20100706-0ubuntu1_FAILEDTOBUILD.txt.gz
<lamont> pitti: um... well. ...  so about that.
<lamont> oops
<pitti> (this was probably done to ease the armel buildd load a bit, since there were a couple of OEM armel builds of qt4-x11, too)
<lamont> it was done to clean out a surplus of qt4-x11 uploads to an armel suite... OTOH, maverick is not that suite.
<pitti> lamont: ok, understood; thanks for confirming
<pitti> I just wanted to make sure that I interpret it correctly
<pitti> lamont: I'll take over that qt4-x11 OEM thing now and test it locally first :)
<lamont> yeah - totally mistook it for part of the OEM cluster
<pitti> so hopefully we'll just have one build then
<lamont> you'll give it back then?
<pitti> lamont: I don't really need it
<pitti> if the Kubuntu or mobile guys do, it should be fine to give back
<pitti> but it won't be the last maverick upload, so *shrug*
<ScottK> pitti: Thanks for bringing it up.  I've retried it because qt4-x11 being out of sync on armel has quite a number of unfortunate knock on effects (including making it really hard for NCommander to work on fixing KDE ftbfs that he's been exploring.
<ScottK> NCommander: Looks like nevermind on fixing qt4-x11 on armel.
<NCommander> ScottK: woo, unexpected good news
<pitti> ScottK: fair enough; it built everywhere else, so it should build on arm, too
<ScottK> That's an interesting theory that doesn't seem to work out in an unfortunate number of cases.  I suspect it's likely to be OK this time though.
<pitti> ScottK: it's my hope, anyway :)
<ScottK> ;-)
<ScottK> jono: I think the last line of your latest blog post is missing a word.
<in-pog-form> a friend of mine has uncovered a serious security issue
<in-pog-form> in PAM
<in-pog-form> i wish to let the devs here know
<ebroder> in-pog-form: https://wiki.ubuntu.com/DebuggingSecurity#How%20to%20File
<in-pog-form> without telling the whole world
<jdstrand> in-pog-form: if it is http://www.ubuntu.com/usn/usn-959-1, it was fixed yesterday, otherwise, follow ebroder's advice
<in-pog-form> ah yes it was that issue
<in-pog-form> thank you
<jdstrand> np
<in-pog-form> i tried it
<in-pog-form> shit gets real yanno
<jdstrand> I'm unfamiliar with that saying, but yeah, it is not good
<in-pog-form> exploitable privilege elevation is never a good thingÂ®
<in-pog-form> any way
<in-pog-form> back to sysadminning
<in-pog-form> cheers lads
<jdstrand> see ya :)
<jono_> ScottK, lol, I will fix that now
<ScottK> ;-)
<jono_> well spotted :-)
<jono_> cheers
<cjwatson> jdstrand: thanks
<jdstrand> oh sure :)
<zul> When someone from the foundations team review the upstart script in https://bugs.edge.launchpad.net/ubuntu/+source/dovecot/+bug/603285 thanks!
<ubottu> Launchpad bug 603285 in dovecot (Ubuntu) "Please convert init script to upstart." [Undecided,New]
<cjwatson> zul: commented on the bug
<zul> cjwatson: thanks
<SpamapS> Hm, trying to add memcached and libmemcached to the seeds as they've been approved.. but I'm not sure where things go.. https://wiki.ubuntu.com/SeedManagement seems to list a lot of seeds that aren't in maverick
<cjwatson> they're spread across platform.maverick and ubuntu.maverick
<cjwatson> what seed are you looking for?
<slangasek> cjwatson: base-files, debian-installer accepted.  What's the timeline for 10.04.1?  Is jul 29 the target date (as per https://wiki.ubuntu.com/LucidReleaseSchedule)?
<slangasek> er, getting ahead of myself here - haven't actually accepted d-i yet :)
<SpamapS> cjwatson: Well neither need to be on the CD, the main reason we're adding them to main is for long term support for web apps.. so I'm thinking 'supported-server'
<SpamapS> cjwatson: that page doesn't mention platform.XXX .. like I said, it seems very out of date
<cjwatson> SpamapS: lp:~ubuntu-core-dev/ubuntu-seeds/platform.maverick
<SpamapS> cjwatson: indeed, I just pulled that one down
<cjwatson> slangasek: shooting for what's on the release schedule but may not quite hit
<slangasek> <nod>
<SpamapS> actually supported-misc-servers seems appropriate for memcached
<robbiew> pitti: awake?
<slangasek> lifeless: the missing upstream tags thing is totally reproducible for me
<slangasek> lifeless: do you have time for us to put our heads together on it?
<lifeless> slangasek: not immediately. In 3 hours I will.
<slangasek> lifeless: sounds good
<lifeless> ok, I'll get out and do my chores before the sprint trip, and then ping you.
<achiang> how can one get the source to various udebs, such as partman-auto?
<achiang> just go poke around in the public pools, find it, and then extract? or is there a more elegant way?
<achiang> apt-cache search doesn't reveal anything useful
<achiang> hm, maybe they're tucked away in debian-installer
<achiang> apt-get source partman-auto works
<Cheery> It's not like anyone other would have ever noticed. but I think I/O for UI peripherals in linux is cumbersome.
<Cheery> it results in oddities like having to insert joystick before starting a game.
<Cheery> and having to use cumbersome libraries to do simple tasks like play a sound.
<SpamapS> hmm, looking at bug 603363 .. anybody know why ssh is the only service that uses 'stop on runlevel S' instead of [!2345] ?
<ubottu> Launchpad bug 603363 in openssh (Ubuntu) "sshd never stops, prevents umount of /usr partition" [Undecided,New] https://launchpad.net/bugs/603363
#ubuntu-devel 2010-07-09
<lifeless> slangasek: ok I have a little time
<slangasek> lifeless: hey there
<lifeless> hey
<lifeless> so tell me now, tell me true
<slangasek> lifeless: so the process I've been using for package merges is bzr co lp:ubuntu/$package; cd $package; bzr merge-package lp:debian/sid/$package; fwibble-fwibble; bzr commit
<slangasek> lifeless: and if I look at my local directory afterwards with 'bzr log -n0' or 'bzr tags', the upstream-$version tag is there
<slangasek> lifeless: and if I do a fresh checkout from lp:ubuntu/$package, the tag is *not* there
<lifeless> well
<lifeless> are you pushing back to lp:ubuntu/$package afterwards ?
<lifeless> oh
<lifeless> I see
<lifeless> uhm
<lifeless> workaround - don't checkout.
<lifeless> make a branch
<lifeless> then do 'bzr push :parent' after committing
<slangasek> workaround, yes :)
<slangasek> where should I file the bug?
<lifeless> please file a bug on bzr saying 'bzr commit in a heavyweight checkout does not propogate new tags'
<lifeless> thanks
<slangasek> ok
<slangasek> lifeless: bug #603395
<ubottu> Launchpad bug 603395 in Bazaar "bzr commit in a heavyweight checkout does not propogate new tags" [Undecided,New] https://launchpad.net/bugs/603395
<lifeless> thanks
<james_w> thanks slangasek, lifeless
<lifeless> de nada
<lifeless> its a one liner
<lifeless> but I doubt I'll get to it :(
<lifeless> EATADBUSY
<slangasek> eat a dbus?
<lifeless> E a tad busy
<slangasek> ohh
<slangasek> :-)
<lifeless> but I like your parsing too
<robertzaccour> I'm using the live cd and installing it. apparently there's a serious kernel problem. i'm gonna let the installer finish and update and find out what happens next
<JontheEchidna> I'm having a bit of trouble with DBus. It's spawning a Polkit-1 helper binary as root, but all the locale environment vars end up set as C
<JontheEchidna> rather than the system locale
<JontheEchidna> whereas starting the helper in a root shell results in the locale environment vars being the system locale
<JontheEchidna> Is there anything I can do short of parsing /etc/default/locale to get the system locale?
<achiang> if i did a 'bzr add foo' and then decide i don't want to commit foo, how do i remove it from the list of things to be committed?
<lifeless> bzr revert foo
<achiang> lifeless: yuck. that actually undid my changes to foo. :(
<lifeless> achiang: they will be stored in a ~ backup file
<achiang> i wanted to do the equivalent of git reset, aka unstage
<lifeless> achiang: are you perhaps a git user ?
<achiang> lifeless: yes
<achiang> struggling with bzr
<lifeless> bzr, like *every other VCS on the planet* has no staging area.
<lifeless> you might like the 'bzr shelve' and 'bzr unshelve' commands
<achiang> lifeless: don't yell at me because git did it correctly
<achiang> :P
<lifeless> they can take a change that you haven't committed and put it to the side for you
<lifeless> and restore it
<achiang> lifeless: but thank you for pointing out the ~ backup files, that helped
<lifeless> achiang: I'd like you to get the most out of bzr; assuming it works the same way as git won't get you that :(
<achiang> lifeless: i mean, point taken re: the tools work differently. i just would have expected that the inverse of 'add' wouldn't actually change the file
<lifeless> if the file was added, revert would have unadded it.
<achiang> that expectation came from the fact that 'add' and 'commit' are two separate steps
<RAOF> Well, âbzr addâ doesn't even do what you think it does â bzr commit will commit *all* changes, so you only need to add new files.
<lifeless> if the file was previously versioned, revert puts it back to the previously versioned state
<RAOF> (ie: the state of the versioned files on disc and the state of the tree that will be recorded by a commit is the same, barring selective commits via âbzr commit $FILEâ)
<achiang> RAOF: right, i've discovered that bzr commit wants to commit everything, so in my workflow, i've had to manually add the files i changed, and then manually commit them
<RAOF> lifeless: Incidentally, I didn't notice any colocated branches NEWS in the bzr 2.2 beta 4 notes - has that slipped from 2.2?
<achiang> RAOF: maybe i don't need that separate add step ; i can just say: bzr commit foo bar baz
<lifeless> achiang: that doesn't make any sense to me - in git you might say that but in bzr 'bzr add' something that is already added is a no-op.
<lifeless> right
<lifeless> you just say 'bzr commit foo' if you want to commit just foo.
<achiang> lifeless: right, that is just a git-ism. i was assuming that there was an index of some sort in bzr
 * achiang stands corrected
<RAOF> There is, kinda - âbzr shelveâ
<FourDollars> achiang: There is no stage concept in bzr.
<RAOF> But it works the right way around - ie: by default, you commit your changes :)
<achiang> thanks for the education. i appreciate it
<RAOF> bzr shelve is well worth exploring.  It's tremendously useful if you want to separate out a bunch of changes into multiple commits.
<achiang> do i need a plugin for that, or does it work out of the box?
<RAOF> Or just want to keep some debugging kruft uncommitted.
<RAOF> Out of the boz.
<RAOF> Ahem.  Box.
<achiang> cool
<achiang> so, in git, i can say, "git show <sha1>" which will show me the changelog and the patch.
<achiang> is there an equivalent for bzr? to look at revnos?
<lifeless> bzr log -p -r X
<RAOF> To expand on lifeless' comment, run âbzr alias show="log -p -n0 "â, then you can âbzr show -r$REVNOâ, or just âbzr showâ to get the full log.
<achiang> yep, i was just about to add an alias
<achiang> thanks lifeless, RAOF
<achiang> oh! a bzr alias!
<achiang> not a bash alias
<RAOF> Indeed.
<achiang> neat
<RAOF> bzr is full of love.
<pitti> Good morning
<pitti> robbiew: hello
<robbiew> pitti: hi
<robbiew> pitti: can't remember what I wanted...but I answered it anyway :)
<pitti> hehe, the best kind
<pitti> uh, what happened to our buildds..
<dholbach> good morning
<pitti> hey dholbach, wie gehts?
<dholbach> pitti: sehr gut - und dir?
<pitti> dholbach: prima, danke
<dholbach> :-)
<maco> is this the part where you three all have a hug and a beer and pout about losing to spain?
 * pitti hands dholbach a beer and hugs him over the loss
<pitti> maco: great idea!
<pitti> maco: although 8:30 in the morning is a little early for the beer part
<maco> hmm good point
 * maco looks at mvo
<maco> a cup of tea?
 * dholbach hugs pitti back
<dholbach> pitti: give that beer to mvo instead :-P
<dupondje> can somebody let rebuild https://launchpad.net/ubuntu/+source/bug-buddy/2.30.0+dfsg-1 ?
<dupondje> it builds fine now :)
<hyperair> didrocks: have you seen the banshee bugs regarding the netbook interface?
<pitti> ScottK, NCommander: I'd appreciate if you could ack bug 603480 soon, so that we can coordinate the new binarymangler rollout next week; I'll take the responsibility and blame
<ubottu> Launchpad bug 603480 in lucid-backports "Please backport pkgbinarymangler 70 to lucid" [Undecided,New] https://launchpad.net/bugs/603480
<hyperair> bug #602759 and bug #602760
<ubottu> Launchpad bug 602759 in banshee (Ubuntu) ""Media" header makes no sense" [Undecided,New] https://launchpad.net/bugs/602759
<ubottu> Launchpad bug 602760 in banshee (Ubuntu) "Doesn't display application menu in netbook mode" [Undecided,New] https://launchpad.net/bugs/602760
<hyperair> didrocks: ^^
<ricotz> can someone look at https://launchpad.net/ubuntu/+source/xine-lib/1.1.18.1-4ubuntu1 this needs also a rebuild
<dupondje> grant dupondje access on 'rebuild button'
<dupondje> :)
<pitti> ricotz: it'll build now?
<ricotz> pitti, there seemed to be a problem with the archive it is building fine in my ppa
<ricotz> pitti, https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1226883/+listing-archive-extra
<pitti> ah, I'll retry
<pitti> ricotz: done
<dupondje> pitti: https://launchpad.net/ubuntu/+source/bug-buddy/2.30.0+dfsg-1 => builds also now
<psurbhi>  hie! is there a good place to find more information about Ubuntu udev implementation or its variance from Debian?
 * psurbhi looking at debian/changelog in ubuntu and debian's udev package.. shall get back if needs more
<dupondje> https://launchpad.net/builders => we stop building for sparc ?
<pitti> dupondje: do you miss it?
 * pitti shakes hand with the new voluntary sparc maintainer
<Sarvatt> ack, powerpc too?
<dupondje> pitti: don't miss it no :) just wondering :)
<pitti> powerpc is still an official port
<pitti> sparc and ia64 were about to be removed
<Sarvatt> ah phew, just saw the powerpc builders were disabled too
<dupondje> that will fix alot of ftbfs ;)
<pitti> no, there just seems to be something generally wrong ATM; half of the buildss are broken
<wgrant> There was a networking glitch earlier.
<wgrant> Probably just needs someone to flip the disabled switch on LP
<apw> cjwatson, i seem to remember saying "my machine isn't suspending every time i close the lid" and you mentioned some bug or other with perhaps pmutils, can you remember/point me at it again?
<dupondje> https://launchpad.net/ubuntu/+source/openbios-ppc/1.0+svn640-1/+build/1729379/+files/buildlog_ubuntu-maverick-i386.openbios-ppc_1.0+svn640-1_FAILEDTOBUILD.txt.gz => can we force to build it on PPC ? as thats why its ftbfs :)
<directhex> dupondje, there's no way to say arch-all packages have specific build-arch requirements. this is a loooong standing issue which only affects, like, 3 packages
<dupondje> ok :)
<scar_> is there a specific channel for xorg releated questions, something in the line of XorgOnTheEdge? I want to compile/configure/install llvmpipe, preferabley just install.
<Sarvatt> #ubuntu-x, llvmpipe is in libgl1-mesa-dri-gallium in xorg-edgers though
<scar_> awesome thanks
<cjwatson> apw: pm-utils is pretty much the userspace side of power management these days, but I know very little more about it than that
<apw> cjwatson, must have been someone else, no worries
<apw> cjwatson, so this pretty grub work ... whats the next step.  i am getting close to cleanish set of patches here, not sure if they will ever be acceptible upstream but at least they are small and self contained
<apw> i assume we're not ready for them to be in the kernel yet, so perhaps we need a PPA with the bits in?  so people can test ?
<cjwatson> apw: can we at least try to get them upstream?  it would make it easier to get the corresponding grub changes upstream
<cjwatson> apw: due to an upstream conversation I'm currently working on writing a no-probe simple linear framebuffer device for the kernel
<cjwatson> apw: sort of like efifb but guaranteed never to do anything firmware-specific
<apw> if i am honest i suspect noone would accept the current approach
<cjwatson> apw: I thought it was all nicely tunable now and switched off by default
<apw> the "correct" approach probabally is a frame buffer which knows its already filled in like plymouth does
<cjwatson> apw: we need both
<cjwatson> the framebuffer device can't help when fbcon just goes and clears the screen
<apw> which picks up the contents and handles it, and then us not moving over to VT7, ie X on VT1
<cjwatson> no no no no nooooo
<apw> i am telling you what they are going to say
<cjwatson> I don't see why
<apw> what we are doing now is just ignoring the kernels desire to clear and update the VT until we switch to VT7
<cjwatson> there's no intrinsic reason X needs to move to vt1, and it breaks so much documentation
<apw> which is at vest vile
<apw> yes its all configurable, but what it does is utterly underhand
<cjwatson> so, wait, I didn't ask for no updates
<cjwatson> I only asked for no clearing
<cjwatson> which I think is much less underhand and much simpler
<apw> the only thing that occurs is the clearing though
<apw> oh and not turn
<apw> and not turning on the cursor
<cjwatson> yeah, but that's already upstream
<cjwatson> I really don't see that disabling the screen-clear until boot is finished is all that underhand
<apw> well except that what you want is not showing the cursor randomly while we are on VT1 the first time, but on for the second time
<apw> i am even struggling to put the semantics down in english!
<cjwatson> the problem with this not going upstream is that we have no other way to reserve the flags bit
<cjwatson> and not having a flags bit for it is really pretty nasty in grub, as I mentioned
<apw> in the failure to upstream case we could submit a 'bootloader specific' bit or something
<apw> or 'distro specific'
<cjwatson> shouldn't be distro-specific
<cjwatson> why don't we have the upstream conversation rather than giving up before we start? :)
<apw> oh we will, but they won't take sensible patches i suspect they will puke when they see what we have done
<cjwatson> this is *neater* than the no-cursor stuff which already went upstream
<apw> and they will gladly tell you to confuse all your users to make things clean in the code
<cjwatson> (which turns it off permanently, and requires horrible hacks in the login binary to turn it on again per-VT ...)
<apw> really?  i don't think it is nice at all, it has horrible semantics
<apw> necessary semantics perhaps, well only cause we want to switch VTs
<cjwatson> depends on your point of view I suppose
<apw> right, i am a sensible person and can see we might need to do it, but that doesn't stop it pegging my vile meter
<cjwatson> but I think the fact that the no-cursor patch already went upstream, and the fact that folks were working on plymouth/X framebuffer handover, indicates that it isn't just us interested in this
<cjwatson> I don't mind if we end up with something different that meets the same basic requirements
<cjwatson> what I don't want is to have to have fundamentally distro-specific code in the linux loader in grub
<apw> all understandable
<apw> i am just warning you that i think we're on for a beating
<cjwatson> because that introduces some real problems - the same linux loader is used for booting Ubuntu and booting other detected OSes
<apw> which had better ignore unknown bits me thinks
 * mvo hugs dholbach
<cjwatson> I'd actually welcome a discussion about the semantics; I agree they're grotty as it stands and perhaps somebody can come up with better ones
<cjwatson> I'm hoping that this is an example of "post wrong code on the internet and somebody will suggest right code"
<cjwatson> at least get the discussion going ...
 * dholbach hugs mvo back
<apw> heh indeed.  well it needs some more shining before its ready for that, but its close
<cjwatson> actually, surely there's only *one* screen-clear we need to kill
<cjwatson> the one when fbcon starts
<cjwatson> do we have to care about vt switching or any of that gubbins?  just remember whether it's the first screen-clear or not ...
<apw> cjwatson, no cause you don't want the vt switch to smack you either right
<cjwatson> which vt switch?
<apw> from vt1 to vt7
<cjwatson> the one to X is already handled in other ways, or at least it was
<cjwatson> X is supposed to snarf the framebuffer contents on its way up
<cjwatson> we don't need to solve that problem again
<cjwatson> (I think it snarfs the contents before the vt switch)
<apw> perhaps this is still doing more than it needs to suceed
<apw> will poke some more
<tseliot> the switch from vt1 to vt7 takes place when we start plymouth
<apw> tseliot, before or after plymouth actually starts
<tseliot> therefore when X starts we're already on vt7
<apw> that was more my belief too
<cjwatson> tseliot: are you certain about that?  I thought we changed that in lucid
<apw> so we have VT1 init which clears, VT1 -> VT7 switch which repaints a blank screen too
<cjwatson> apw: but again, there's no need to address the latter problem in the kernel
<cjwatson> apw: if it exists, plymouth can deal with it the same way X does - snarf the framebuffer contents before the VT switch
<apw> hrm
<tseliot> cjwatson: yes, I'm pretty sure. X simply doesn't clear the framebuffer when it starts on the same vt as plymouth
<cjwatson> tseliot: ok, well in that case do you agree that plymouth can solve this problem?
<tseliot> apw: I think we tell plymouth to use vt7, let me check the code
<cjwatson> I think you're right, from the changelogs, I'm just misremembering
<tseliot> cjwatson: what's the problem again? I think I've missed part of the discussion
<cjwatson> tseliot: trying to eliminate black screens between grub and plymouth
<apw> cjwatson, the problem then becomes is how does plymouth get the framebuffer contents, when the VT isn't even in framebuffer mode
<cjwatson> apw: you mean KD_GRAPHICS?
<apw> cjwatson, indeed
<apw> now maybe thats what we should be doing, putting VT1 into KD_GRAPHICS instead
<tseliot> cjwatson: the problem is that plymouth clears the screen when it starts
<apw> tseliot, that is simply a bug though right ?
<cjwatson> tseliot: userspace problems are shallow :)
<apw> (in this context)
<cjwatson> tseliot: I'm trying to figure out exactly what we need to change at the interface between grub and the kernel
<cjwatson> tseliot: we know that, at minimum, we need to stop fbcon init from clearing the screen
<apw> cjwatson, so now i wonder what would happen if we simply dropped VT1 into graphics mode based on your bit
<cjwatson> tseliot: what else do we need to change in the kernel?
<tseliot> apw, cjwatson: yes, it's something that can be fixed in plymouth. The only problem is that is that if you copy the fb content from a framebuffer that uses a different resolution, the result is ugly
<cjwatson> actually
<cjwatson> I'm entirely happy for plymouth to repaint the whole screen, it's going to do that anyway (based on the theme) and there's a possibility of a resolution change here which is something I'm prepared to cope with (one problem at a time!)
<cjwatson> all I want is for it to be a clean switch
<cjwatson> as in, no flicker to black
<apw> tseliot, what interface does X use to read the framebuffer contents
<cjwatson> so I guess it doesn't have to read the framebuffer contents
<tseliot> well, what I was trying to say is that plymouth clears the screen with a big black rectangle first and then draws the splash
<cjwatson> tseliot: ok, does it have to have the foreground vt before it does that?
<apw> tseliot, why the HECK would one do that
<apw> 'i am going to write over the whole screen with a splash, lets waste my time and make it shiney first' ???
<tseliot> apw: in case the resolution doesn't match
<cjwatson> as long as it's doing all this to a non-displayed framebuffer, I really don't care if it puts polka-dots on there first
<cjwatson> er, a non-displayed buffer
<tseliot> cjwatson: would you like to vtswitch only when the splash is ready?
<cjwatson> yes
<tseliot> I'm not sure it's possible
<apw> graphics mode is raw isn't it
<apw> ie when a mode is GRAPHICS, then you can't write unless you are the 'current' vt
<cjwatson> or, at minimum, at least prepare a suitable buffer and blit it over at once after the vt switch
<cjwatson> but then the kernel probably will clear the screen, so still not idea
<cjwatson> *ideal
<apw> not sure it will from <-> to GRAPHICS
<tseliot> apw: yes, something weird would happen
<cjwatson> looking at X
<cjwatson> as far as I can tell, it actually doesn't read the framebuffer contents at all
<apw> cjwatson, why do we need to VT switch?  this is just to make peoples fingers happy that we are on VT7 yes ?
<cjwatson> it just refrains from clearing them
<apw> cjwatson, what if we just told the kernel that the default VT was 7
<tseliot> cjwatson: we can copy the content of fbcon (if the resolution matches)
<cjwatson> the web is full of documentation that says "when stuff going wrong, you can get a login prompt with ctrl-alt-f1"
<cjwatson> apw: that would break server boots.  I'd really rather not go there
<apw> cjwatson, right ... happy with that ... what if we made the default VT-7
<apw> why would it break server boots
<apw> they get the same graphics poop we do, then they do something to get the login prompt yes?
<tseliot> cjwatson: right, X simply creates a root window with no background which makes it possible to see what the framebuffer left
<apw> a vt switch to 1 i assume ?
<cjwatson> well, not necessarily, a lot of server people disable the splash
<apw> right and without splash you'll go back to textual grub and not pass me the bit right ?
<cjwatson> no, splash is just a word in the command line
<cjwatson> grub refrains from trying to parse that stuff, it isn't generic
<apw> cjwatson, can i just say you are making this hard :)
<cjwatson> system design back 20 years is making this hard
<cjwatson> I'm just trying not to break it
<apw> surley we can jsut put a login on VT-7 for server :)
<cjwatson> if you think it's hard to get the rest of this upstream, try getting a change of the default VT upstream
<apw> cjwatson, i was proposing to make the default change only on a bit asking for it, or a command line option asking for it
<cjwatson> can we separate out these two problems?
<apw> actually a command line option would work with server well as well
<cjwatson> I'm not trying to solve everything at once
<cjwatson> avoiding the clear on fbcon init would be brilliant for now
<cjwatson> and I don't mind if it takes longer to sort out the rest
<apw> indeed, but the point is there are two issues... that init clears stuff is bad, that the VT switch will too is bad
<cjwatson> sure, but I think they need different solutions
<cjwatson> and the latter is much less intrusive anyway
<tseliot> cjwatson: I assume that you want to use the fb that grub provides. Am I right?
<cjwatson> init clearing stuff leaves us with a black screen for multiple seconds
<cjwatson> the VT switch to plymouth will be at most a flickere
<cjwatson> *flicker
<apw> well perhaps without some idea of how we are going to resolve it may change how we resolve the other issues
<apw> ok
<cjwatson> tseliot: well - grub will program an fb in order that we have something, but I expect it to be reprogrammed by the switch to KMS
<cjwatson> all I'm really trying to get round here is the several seconds of black screen before plymouth starts
<tseliot> cjwatson: right but some flicker would still happen if the resolution changes
<cjwatson> papering over the join is tricky, but as long as all of the images are as identical as we can make them (modulo resolution) then it will be an improvement over what we have today
<cjwatson> I don't want the perfect to be the enemy of the good here
<tseliot> still better thana black screen for sure though
<tseliot> than
<cjwatson> we can sit here all day saying that we can't make it perfect, but there are definitely improvements we can make
 * tseliot nods
<cjwatson> and I don't think it can ever be exactly right unless (a) grub gets support for programming native panel resolutions or (b) the native panel resolutions are loaded into the vbe bios
<tseliot> the former seems more realistic to me ;)
<cjwatson> (whether (b) would result in a flicker is still questionable, apparently the kernel does have to switch off the panel briefly right now but mjg59 doesn't seem to think that's an intrinsic problem)
<tseliot> ah
<cjwatson> something to do with changing the panel scaler
<tseliot> apw, cjwatson: so, to sum up, would it be useful if I made plymouth copy whatever it's in fbcon when it starts?
<apw> tseliot, what does 'in fbcon' mean ... and how and where do you get to it
<cjwatson> tseliot: is it possible if the vt is in KD_TEXT mode?
<cjwatson> tseliot: I actually don't think it would be useful, though, thinking about it
<cjwatson> tseliot: we want to inhibit the screen-clear
<cjwatson> tseliot: but that may be partly in the kernel and partly in plymouth
<apw> cjwatson, as you know what is in there anyhow right, its in /boot/grub/logo.png
<cjwatson> right, well ultimately I was going to try to get that dynamically from the plymouth logo
<cjwatson> but yes
<tseliot> apw: if grub puts something in the framebuffer, I can copy its content by mapping the framebuffer
<cjwatson> (the approach I gave you is resolution-specific)
<cjwatson> tseliot: is this significantly different from not clearing to black and just drawing it again, though?
<tseliot> cjwatson: not much
<cjwatson> remind me, when does the switch to kms happen?  it's before plymouth starts, isn't it?
<tseliot> but it can take a while before you see the splash
<apw> kms happens when the driver loads
<cjwatson> or rather, it's before plymouth-splash starts
<tseliot> yes, as plymouth's drm plugin requires kms
<apw> (kernel driver)
<cjwatson> so what happens to existing framebuffer contents when we switch to kms?
<tseliot> right
<cjwatson> they'll be cleared, won't they?
<apw> cjwatson, well they get redrawn, from the VT contents
<cjwatson> apw: VT text contents, or the prior framebuffer contents?
<cjwatson> apw: if the latter, presumably they aren't rescaled (they couldn't be since there may have been text drawn on top)
<apw> if its in text mode the text contents
<apw> (i can't see how it could do anytning else)
<cjwatson> what if it's in graphics mode?
<apw> then i believe the kernel asks the mode owner to redraw it
<cjwatson> that's if it's VT_PROCESS too, presumably
<cjwatson> you can be KD_GRAPHICS && !VT_PROCESS, IIRC
<cjwatson> and indeed if we were doing something where the kernel starts in KD_GRAPHICS, you'd have to be
<cjwatson> so I suppose grub does have to be made to know whether there's going to be a splash screen
<cjwatson> if there isn't, then it may well want to keep the better mode (people tend to like big framebuffers as long as they aren't too slow), but it shouldn't preserve the screen contents
<apw> cjwatson, vt relies on being able to tell someone to redraw on a resize as far as i can see
<apw> whether that is fbcon or X
<tseliot> oh, and as regards clearing the screen in plymouth, some time ago I spoke with upstream and they told me that:
<cjwatson> I can only find the text-mode vt resize code
<tseliot> with drm modesetting plymouth gets its own "screen" that it swaps in
<tseliot> so it's not really clearing the screen, just detaching it and putting a new on in place
<tseliot> but the initial contents of that "screen" is black
<cjwatson> tseliot: in that case it should be easy to draw the splash before swapping it in, if it doesn't do so already
<tseliot> I guess it's not as fast as ideally it should be then, if we can see the black screen
<cjwatson> apw: anyway, when Scott and I tested this a few months back, there seemed to be some plymouth bug that broke things on resize, but aside from that the duration of the flicker on resolution change wasn't particularly long IIRC
<apw> cjwatson, and you were testing with the patch i started from ?
<cjwatson> IIRC yes
<apw> and that patch simply turned off all VT updates in text mode
<cjwatson> apw: would setting the vt to KD_GRAPHICS on initialisation be enough to inhibit the screen-clear from fbcon_init?
<tseliot> cjwatson: it would take some restructuring but it would definitely be possible to do what you suggest by making plymouth render the 1st frame of the splash so that we could have that instead of the black screen
<cjwatson> apw: if KD_GRAPHICS + VT_AUTO works at all, and if it has that effect, I think it might well be what we want
<apw> cjwatson, it not clear you have failure tollerance in that case, or indeed if it would survive the KMS mode change
<cjwatson> let's ignore the latter, it's not obvious it's soluble at that point
<cjwatson> failure tolerance?  you mean things like the ability to display oopses?
<apw> or indeed to switch to VT-1 to see the text that the kernel put on it yes
<cjwatson> I think the solution for that is "disable splash", isn't it?
<tseliot> yes, it's not nice to leave things in KD_GRAPHICS is something goes wrong
<tseliot> if
<cjwatson> ok, so maybe KD_GRAPHICS won't fly
<cjwatson> in that case simply inhibiting the initial clear seems like the only kernel change that's particularly viable right now?
<apw>          * Ignore all switches in KD_GRAPHICS+VT_AUTO mode
<cjwatson> that's probably not good
<apw> cjwatson, our KMS story is going to look bad i suspect if its going to clear when kms loads
<cjwatson> apw: it will look better than it does now :-)
<apw> we don't start plymouth till after ureadahear on spinning media i think right?
<apw> so we'll still get 10s of black
<cjwatson> ureadahead is 'start on starting mountall'
<cjwatson> plymouth is 'start on (starting mountall or [other stuff])'
<cjwatson> plymouth-splash is 'started on started plymouth and [got a graphics device]'
<cjwatson> I don't know if there's something that explicitly serialises ureadahead before plymouth, but if there is I can't find it
<apw> cjwatson, cirtianly on my machine i have black for most of the time ureadahead is runnign
<apw> but its hard to know if thats kms not loaded yet or what
<cjwatson> my suspicion is that that is Keybuk's intention but is not guaranteed, but that's just my reading of the job graph
<cjwatson> well - udev is 'start on virtual-filesystems'
<cjwatson> udevtrigger is 'start on (startup and started udev)'
<cjwatson> and virtual-filesystems is emitted by mountall
<cjwatson> so you won't get the kms event until ureadahead is done
<cjwatson> I mean, userspace won't notice
<cjwatson> if it were KD_GRAPHICS + VT_AUTO, then theoretically we could rescale the existing framebuffer contents
<apw> cjwatson, who can ?
<cjwatson> it would have to be the kernel
<apw> deep joy
<cjwatson> yeah, I know.  I can't think of any other way to do it
<apw> cjwatson, ever played with the fbcon logo ?
<cjwatson> no, although it did occur to me just a few minutes ago
<cjwatson> is that scalable?
<apw> cjwatson, if i am honest i have no idea what it even is
<apw> though i have seen a penguin drawn on boot in videos so it could be that
<cjwatson> I bet it's not themeable in the ways we'd need
<cjwatson> I think I played with it in about 19198
<cjwatson> er, 1998
<cjwatson> yeah, you compile a logo image into the kernel
<cjwatson> (drivers/video/logo/)
<apw> a nice purple background perhaps :)
<cjwatson> kubuntu's colour scheme is still blue, iirc
<cjwatson> anyway, I don't think the fb logo is resolution-scalable
<cjwatson> it's just a ppm
<tseliot> apw, cjwatson: have you come to a conclusion? (someone shut down my computer here...)
<tseliot> i.e. what's the plan?
<apw> we're more confused than ever me thinks
<tseliot> apw: hehe
<cjwatson> apw,tseliot: I guess I'd like to talk about this with Keybuk when he's around.  Maybe we should take this to mail?
<apw> cjwatson, sure ok
<tseliot> cjwatson: sure
<Sarvatt> apw: 10 seconds of black? you mean people actually run KMS without doing a echo FRAMEBUFFER=y | sudo tee /etc/initramfs-tools/conf.d/splash? :)
<apw> Sarvatt, what does that do
<Sarvatt> loads the drivers and starts plymouth about a second into the boot :)
<apw> ahhh
<James> Hello
<tseliot> Sarvatt: that has drawbacks though
<Guest23585> Reading the topic I think im in the wrong place, but, I've just finished porting UBuntu to the iPhone but am having difficulty loading multitouch drivers
<tseliot> which is why we don't enable it by default
<Sarvatt> yeah it's a  bit racy, about 1/20 boots I get a high res text splash
<Guest23585> I've played with xorg.conf but most of the information I've used is fro X86Free
<ScottK> pitti: Done.
<pitti> ScottK: cheers!
<Sarvatt> loads the text splash in plymouth then resizes it to the drmfb
<Guest23585> Is there any dependencies fir touchscreen support?>
<tseliot> Guest23585: maybe #ubuntu-x is the right chat room
<Guest23585> ubuntu-x9;2~?
<cjwatson> Sarvatt: it's also a net slowdown
<Guest23585> ubuntu-x?
<tseliot> Guest23585: yes, the last one
<Guest23585> Ok thanks anyway
<Sarvatt> weirdly it feels faster because i'm not staring at a ugly screen for 15 seconds on this machine
<Sarvatt> i know it sucks because it's shoving the world into the initrd though, just prefer it that way here :)
<erle-> hello, guys
<erle-> are there any plans to fix the file system layout on amd64 ubuntu
<erle-> ?
<erle-> it really sucks
<erle-> the fedora way is so easy, just let /lib be /lib32, and avery problem of amd64 dissappears
<erle-> because you could ad every 32-bit-lib to repo
<erle-> without repackaging
<cjwatson> https://wiki.ubuntu.com/MultiarchSpec
<directhex> erle-, wrong.
<erle-> directhex, whats wrong with that?
<directhex> erle-, most of it, but in short, it fixes only a tiny tiny number of things, at the cost of patching 18,000 source packages
<cjwatson> we've gone over this in a great deal of detail - there's no need to redesign it now.  multiarch just needs to be implemented
<erle-> but there is no time to wait
<erle-> its a problem to be solved before 32 bit is obsolete
<cjwatson> and it will be
<erle-> when do you think?
<cjwatson> multiarch has been accepted by Debian as the right design as well
<erle-> i know that the crappy layout is derived from debian
<cjwatson> don't know exactly but we plan to have it before the next LTS
<directhex> erle-, lib64 is a leftover from sparc solaris
<erle-> hm
<erle-> i know
<directhex> and until itanium rhel/sles use lib64, i don't take your claims seriously
<erle-> thats all obvious
<erle-> suse has /lib32 and /lib64 as well
<erle-> but /lib points to /lib32
<directhex> only on amd64.
<directhex> not on all 64-bit arches
<erle-> in debian it points to /lib64
<directhex> just amd64
<erle-> of course
<erle-> it only matters, where there are two instructions sets
<erle-> in amd64 it really matters
<directhex> except itanium can run i386 code too
<cjwatson> please read https://wiki.ubuntu.com/MultiarchSpec - it explicitly refutes this
<cjwatson> it's tiresome to repeat it
<erle-> directhex, but thats software emulated, thats no full support
<erle-> and later versions of itanium dont afaik
<erle-> cjwatson, i am going to read that
<erle-> takes some more time that 1 minute
<cjwatson> you could have read it before continuing the conversation; there was no pressure on you to continue it within a minute. :)
<erle-> http://www.theregister.co.uk/2001/01/23/benchmarks_itanic_32bit_emulation/
<erle-> itanium x86 was dead from the first day
<directhex> hands up if you have a production itanium system, and are in a position to comment
<ansgar> What are the rdeps of libuuid-perl in Ubuntu? If it includes a standard package, it might be worth syncing the last revision from Debian that replaces the dependency on perl by one on perl-base (see http://bugs.debian.org/588427)
<cjwatson> itanium is a bit of a red herring for this anyway.  arm is much more interesting nowadays and there are plenty of specific use cases there for 32-bit-on-32-bit emulation.
<cjwatson> ansgar: it's only in desktop, not standard
<cjwatson> (and yes, i386-on-arm is software emulation, but so what?  the problems end up being quite similar in practice and they're sufficiently much work to solve each time that we want to solve them once.)
<erle-> directhex, does anybody have a itanium system?
<erle-> http://en.wikipedia.org/wiki/File:Itanium_Sales_Forecasts_edit.png
<cjwatson> forget itanium, it's a bad example for this.
<erle-> that what i wanted to point out :D
<cjwatson> it doesn't invalidate the design though.
<erle-> yeah, i like the design, too
<erle-> but thats not my concern here
<psurbhi> erle, there is still an existing group doing heavy research on itanium
<psurbhi> gelato.org
<cjwatson> people have already started work on multiarch; there's a gsoc project in progress at the moment to do the apt side of things
<cjwatson> just needs the dpkg side to get done
<micahg> does anyone have time to accept a gjs rebuild in lucid-proposed?
<cjwatson> persia: any progress on bug 294593?
<ubottu> Launchpad bug 294593 in lash (Ubuntu) "Please merge lash 0.5.4-1 (universe) from Debian unstable (main)" [Wishlist,Incomplete] https://launchpad.net/bugs/294593
<persia> Uhh, I forgot about it :)  I'll take a look tonight.
<cjwatson> thanks
<a_ok> can someone help me out with this documentation? https://help.ubuntu.com/community/DisklessUbuntuHowto#Static IP
<a_ok> I know I want to configure this but WHERE I might posibly configure this is never mentioned
<cjwatson> chrisccoulson: looks like you and Barry were responsible for the libticonv package.  Can you look at the apparently repackaged version now in Debian, and see if we can fakesync it?  (different .orig.tar.gz)
<ogra> cjwatson, do you know if foundations currently has a dedicated pulse maintainer now that crimson stopped working on it ?
<cjwatson> no
<cjwatson> as in, we don't
<cjwatson> TheMuso might know
<ogra> yeah, got (and expected) that
<joaopinto> mvo, do you happen to know if it would be safe to change a  sources.list.d entry on an APT Pre-Invoke Update configuration hook ?
<joaopinto> use case: a client side script validating and changing the mirror if required
<mvo> joaopinto: that will not work, the sources.list is read/parsed before that hook is called
<joaopinto> I was afraid :(
<mvo> joaopinto: the mirror method got some improvements recently
<mvo> joaopinto: is that not something you could use?
<joaopinto> I have played with mirror: a long time ago, need to revisit it
<joaopinto> mirror: fetches the archive just once and uses it for all the subsequent transactions, right ?
<joaopinto> I mean, the archive url
<mvo> joaopinto: yeah, it updates the mirror file on each apt-get update
<mvo> joaopinto: and then uses the mirror it gets from that
<joaopinto> ok so it's probably the best option
<joaopinto> mvo, the mirror list gets cached and will be used if the mirror mehtod url is unavailable during a future cache update ?
<joaopinto> just to make sure we don't keep a single point of failure :)
<mvo> joaopinto: the mirror list gets cached, yes
<chrisccoulson> cjwatson - yeah, i can look at that at some point next week. i'm not working today though
<joaopinto> ok, tks :)
<ScottK> Urgh.
<cjwatson> chrisccoulson: thanks
<ScottK> NCommander: mainwindow.cpp:109: internal compiler error: output_operand: invalid expression as operand <-- qt4-x11 on armel.
<NCommander> ScottK: ICEs go to doko :-)
<ScottK> NCommander: He's not here, so I pass it to you to pass to him.
<evdvelde> hi all, i am currently an archlinux user, but thinking to switch to ubuntu. However i love to have the newest software possible, so i was wondering... is ubuntu development version stable enough to use daily?
<persia> evdvelde: Depends on the day: the place to ask is #ubuntu+1
<kenvandine> cjwatson, we have a rather urgent upload waiting in the unapproved queue for lucid-proposed
<kenvandine> cjwatson, think you can take a look at it? it's gwibber
<evdvelde> ok thx persia
<kenvandine> cjwatson, facebook is throttling all gwibber users, and this fix will greatly reduce the amount of load we put on facebook, so the sooner people start to upgrade it the sooner everyone will start to be able to use facebook again
<cjwatson> kenvandine: ouch.  accepted
<kenvandine> thank you very much :)
<kenvandine> cjwatson, it has been a very painful bug... it is annoying that facebook throttles all gwibber users, not just the ones that are heavy users
<zul> cjwatson: i just uploaded a bunch of new landscape-client can we get this accepted into proposed plesae?
<cjwatson> zul: not now, have to prepare for the release meeting
<cjwatson> sorry
<zul> cjwatson: k
<cjwatson> pitti: can you look at bug 595650 please?  it's a regression from your libusb upload
<ubottu> Launchpad bug 595650 in libusb (Ubuntu Maverick) "After the last updates HP printer stopped working" [Critical,Confirmed] https://launchpad.net/bugs/595650
<cjwatson> seb128: can your team take bug 600194?  it's on our list for the release meeting, but seems desktopish
<ubottu> Launchpad bug 600194 in gir-repository (Ubuntu Maverick) "gir-repository fails to build from source in maverick" [High,Confirmed] https://launchpad.net/bugs/600194
<seb128> cjwatson, yes
<seb128> cjwatson, I wanted to work on it anyway since I need to do a gir update for other changes
<cjwatson> thanks
 * MattJ frowns at dput... it tells me I just uploaded to upload.ubuntu.com successfully
<seb128> cjwatson, np
 * cjwatson adjusts the agenda
<cjwatson> MattJ: the upload will succeed but if you don't have upload permissions then it'll be rejected when the queue runner gets to it
<MattJ> Excellent, thanks
<ScottK> seb128: What's the url for the desktop team report?  I'll add the Kubuntu stuff to it (Riddell is not available today)
<MattJ> I'm kind of surprised that's there's a default upload destination
<seb128> ScottK, https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus
<seb128> ScottK, thanks
<ScottK> seb128: Thanks.
<ScottK> seb128: What do I need to do to get gtk stuff to use the menubar?  For Qt/KDE stuff it just does.
<seb128> ScottK, install appmenu-gtk
<seb128> and restart your session
<ScottK> seb128: OK.  Thanks.
 * ScottK wonders if plasma-widget-menubar should recommend that then...
<lag> tkamppeter: ping
<smoser> just curious, anyone know why memtest86 would be part of ubuntu-standard ?
<lag> pitti: ping
<tkamppeter> lag, hi
<lag> Oh you are there :)
<lag> I wanted to ask you about cups
<tkamppeter> lag, then simply ask.
<lag> Specifically: modprobe -q -b parport_pc || true
<lag> I'm not sure it's such a good idea to be doing modprobes from your scripts
<lag> If you modprobe a module for a device which does not exist, it could have dire consequences
<tkamppeter> lag, this loads the parport_pc kernel module if it is available and if its requirements (I do not know whether a parport must be actually present) are fulfilled. The " || true" takes care that the script is not aborted if the parport_pc module is not loadable.
<tkamppeter> lag, the module is needed to print on parallel printers.
<lag> And if a parallel port doesn't exist?
<maxb> A package I got a sponsored upload for (subversion in maverick) FTBFS on armel and sparc. What should I do about it? I don't have access to those architectures.
<lag> tkamppeter: ?
<cjwatson> lag: what dire consequences?  the kernel will give you ENODEV
<cjwatson> lag: the kernel isn't that stupid :)
<ogra> cjwatson, sadly it is (atm)
<cjwatson> not for established devices like parallel ports
<ogra> https://bugs.launchpad.net/bugs/601226
<ubottu> Launchpad bug 601226 in linux-ti-omap4 (Ubuntu Maverick) "Unable to handle kernel NULL pointer dereference in ppdev module" [Medium,Triaged]
<ogra> same for parport_pc
<ogra> and same for the omap3 kernel
<cjwatson> I'm not surprised about problems on arm, but we don't generally have that kind of problem on x86
<ion> Thats a bug in the kernel, not in anything that modprobes stuff.
<cjwatson> and it's unambiguously a kernel bug, not a cups bug
<ogra> agreed
<lag> http://paste.ubuntu.com/461186/
<ogra> but it doesnt seem so clever to actually hardcode modprobe in the initscript, could that be solved more dynamically
<lag> cjwatson: I am in the process of fixing the bug in the kernel
<lag> But there are bound to be other problems if modules are loaded willy nilly
<lag> Udev should be used instead
<lag> Only only loaded if the hardware exists
<lag> This will become a problem for x86 also, when they start to remove parallel ports
<lag> And only*
<ion> Theyâve been leaving parallel ports out for a long time from PCs.
<ion> s/from/in/
<lag> So this will kill every PM without a parallel port running the Maverick rootfs
<lag> PC*
<lag> There must be a way for you to check if the hardware exists before loading the module (i.e. udev)
<cjwatson> lag: loading modules for non-existent devices doesn't usually cause null dereferences in the kernel, and I've never before heard somebody suggest that
<cjwatson> parallel ports are often hung off legacy busses that can't be so easily detected
<lag> cjwatson: I accept that this is also a kernel failing (as I say, I am in the process of fixing that)
<cjwatson> parport_pc is one of those devices we tend to just load because detection is often weak
<lag> I still think these scripts should use the functionality provided for extra security
<cjwatson> that's the problem, my understanding is that the functionality is not always provided
<cjwatson> sure, modern PCI devices and such, that's easy
<lag> udev?
<lag> Well it must in this case
<cjwatson> udev only gets uevents from the kernel if the bus can actually tell you that the device is there
<hallyn> cody-somerville: hey, kirkland` suggested you knew a lot about live-helper.  I'm jsut curious what I did wrong:  I did 'lh clean --binary; lh build'.  That ended up trying to rebuild chroot/ (which i didn't think it would), where i had made some customizations, and then failed anyway, trying to stat chroot/boot/vmlinuz-
<lag> Correct
<hallyn> (now i'm just re-doing a full lh_build, with lh_build hacked to pause while i make my changes between stages :)
<hallyn> what was the right way to make a change?  (I wanted to drop in my own initrd.img into chroot/)
<cjwatson> but, as far as I can see, only the parport_pc module itself knows how to probe for a PC parallel port
<lag> cjwatson: A uevent is not sent in this case
<lag> but it is on my PC
<lag> Thus, it must be detectable
<cjwatson> that depends on how the parallel port is hooked in
<lag> Ture
<lag> True*
<cjwatson> the IRQ probing stuff is not hooked into a MODULE_DEVICE_TABLE
<cjwatson> I don't see how uevents for that would ever arrive
<cjwatson> sure, if it's on PCI then fine
<kees> pitti: sourceful retracing is not working right now?
<lag> cjwatson: So your final word is that directly modprobing the module is the best solution
<lag> and just hope that it fails sensibly
<cjwatson> insofar as I'm authoritative on this, that is my understanding yes
<lag> Okay
<lag> I'll just fix it :)
<ScottK> seb128: Does appmenu-gtk set some magic config option to prevent menus from hiding?  It worked before on my system with the Qt/KDE stuff and now it doesn't.
<lag> tkamppeter - cjwatson: Thanks for your time
<smoser> cjwatson, how is it that update-grub gets run on kernel installation or removal ? does one have to have that in kernel-img.conf ?
<ScottK> jcastro: ^^^ re my question for seb.  Do you know?
<seb128> ScottK, yes, it installs a Xsession.d script
<seb128> ScottK, edit it and change the 1 to 0
<ScottK> seb128: Thanks.
<seb128> 80appmenu
<seb128> export APPMENU_DISPLAY_BOTH=1
<seb128> change that one to 0
<seb128> we will turn it to 0 next week probably by default
<cjwatson> smoser: yes, right now - there's a Debian bug to use /etc/kernel/postinst.d/ for that instead
<smoser> and is that option in kernel-img.conf just written by the installer then ?
<jcastro> ScottK: we're shutting that off to be "normal" next week
<ogra> smoser, the bootloader part in the installer sets it (based on the bootloader the system uses)
<cjwatson> smoser: yes
<smoser> ogra, thanks.
<ogra> which reminds me i need to remove that stuff for armel
<ScottK> jcastro: OK.  It's just a bit unfortunate that it affects the Qt/KDE stuff too, so by intalling the gtk bits, the Qt/KDE bits stop working right.
<ogra> since debian moved everything flash-kernel related into update-initramfs
<smoser> cjwatson, you did get a mail from me wednesday/thursday, right ? not pestering, just wanted to verify receipt.
<jcastro> ScottK: I wasn't aware of that
<ScottK> jcastro: Me neither until a few minutes ago.
<cjwatson> smoser: yes, sorry, haven't got to it yet
<smoser> no problem.
<cody-somerville> hallyn, it doesn't actualy rebuild the chroot/ - all the helpers run though but they skip doing anything.
<cody-somerville> hallyn, as for the stat chroot/boot/vmlinuz-, thats unfortunately a bug I've ran into as well.
<cody-somerville> hallyn, if you have a lot of ram, I suggest doing the build on tmpfs. with a local mirror you can do an entire build of ubuntu-desktop in 10 minutes.
<hallyn> cody-somerville: hm, great idea :)  yeah plenty of ram here
<hallyn> but the time wasn't the point - i wanted to drop in my own hand-built initrd
<hallyn> (to hack up the casper-helper function)
<hallyn> but...  it *did* rebuild the chroot/.  it removed it, and rebuilt it.
<cody-somerville> the .stage/ files must have been deleted then
<cody-somerville> are you sure the entire chroot was rebuilt or are you just guessing?
<cody-somerville> cause the stat error only happens when you do lh clean --binary;lh build
<ricotz> cjwatson, hi, do you mind increasing the priority a bit for https://edge.launchpad.net/ubuntu/+source/xulrunner-1.9.2/1.9.2.7+build1+nobinonly-0ubuntu1/+build/1861827 ?
<cjwatson> ricotz: done
<ricotz> cjwatson, thanks
<hallyn> cody-somerville: yeah, after i started 'lh build', chroot/initrd.img was gone (as were most dirs at first)
<cody-somerville> hallyn, oh, it stores things in .cache
<cody-somerville> hallyn, it goes through the entire process but if something is cached then it uses it instead of doing it
<cody-somerville> somethings get done no matter
<cody-somerville> like probably rebuilding initrd
<dupondje> What do we do with packages that are (wrongly) named in ubuntu and needs to be synced ? Example xfsprogs (3.1.2-1)  => debian, 3.1.2ubuntu1  in ubuntu ...
<hallyn> cody-somerville: drat, i was hoping chroot/ got built during 'lh chroot', and 'lh binary' woudl jsut package up the binary from chroot/
<BlackZ> dupondje: you should check why there's that number in debian/changelog
<hallyn> cody-somerville: ok, thanks, just having lh_build pause between steps is working for me so i'll stick with that - and start using a tmpfs like you suggested
<BlackZ> err, version
<dupondje> BlackZ: how you mean ? the ubuntu package should be named 3.1.2-0ubuntu1 no ?
<BlackZ> dupondje: however if the ubuntu changes are no longer relevant the version number doesn't matter
<cjwatson> dupondje: nothing much you can do except make it 3.1.2ubuntu2 in Ubuntu and wait for the next sync
<cjwatson> er, the next upstream
<dupondje> k :)
<cjwatson> BlackZ: you don't understand ...
<cjwatson> BlackZ: 3.1.2ubuntu1 > 3.1.2-1, so you can't sync
<BlackZ> cjwatson: ah, yeah
<cjwatson> it was 3.1.2ubuntu1 because at the time the Debian version was 3.1.2
<cjwatson> and 3.1.2-0ubuntu1 would have meant doing a native -> non-native transition in Ubuntu which has its own problems
<cjwatson> no good answers when a package is wrongly native in Debian really
<dupondje> What group you need to be in launchpad exactly to change bug importance ?
<BlackZ> dupondje: for ubuntu bugs, bug control
<dupondje> cjwatson: couldn't it be changed that 3.1.2-1 > 3.1.2ubuntu1 ?
<cjwatson> dupondje: no
<cjwatson> dupondje: do not muck with the versioning algorithm. :)
<dupondje> :P
<dupondje> better spank the debian maintainter :)
<cody-somerville> hallyn, why do you need to do that? live-helper has a mechanism to install files into the chroot and/or binary.
<smoser> i'm wanting to have a package install a file in /etc/kernel/postinst.d/ .  As it is, it gets marked as a config file, and left if the package is removed.  As the postinst.d script invokes something from the package, that seems wrong.
<smoser> how should I ensure that the file is removed on package uninstall ?
<hallyn> cody-somerville: jinkeys, that WAS fast
<hallyn> cody-somerville: oh, through lh_config arguments?
<hallyn> i'll have to take a look, thanks for the hint
<cjwatson> smoser: conffiles are removed on purge rather than on remove; the standard is that they must check whether any file they refer to outside /etc exists.
<cjwatson> smoser: you're not allowed to have files in /etc that aren't configuration files
<smoser> well, it would seem to me that /etc/kernel/postinst.d goes against that principal
<cody-somerville> hallyn, no, you can drop files into chroot_local-includes or binary_local-includes after running lh config
<hallyn> cody-somerville: thanks!
<cjwatson> smoser: same principle as init scripts
<smoser> so you're suggesting '[ -x /path/of/script ] || exit 0' ? I was using initramfs tools as an example, which puts files into the postinst.d, and invokes update-initramfs. it doesn't check, so that would be a bug, right ?
<cjwatson> minor bug in the case of initramfs-tools because the kernel depends on initramfs-tools so it's impossible for it not to be installed while running postinst.d
<cjwatson> /etc/kernel/postinst.d/dkms checks -x
<smoser> thanks cjwatson
<cjwatson> top tip: it helps if you install the version of the package you're trying to test
<Luke> does anyone know the difference between the indicate and appindicator modules in python for the indicator-applet stuff?
<Luke> oh i see i'm in the wrong channel
<ricotz> chrisccoulson, hello, will there be thunderbird "3.1.1 build1" in maverick? that would be nice
<cjwatson> SpamapS: any reason you reopened bug 603363?
<ubottu> Launchpad bug 603363 in openssh (Ubuntu) "sshd never stops, prevents umount of /usr partition" [Medium,Triaged] https://launchpad.net/bugs/603363
<cjwatson> SpamapS: I've reclosed it
<SpamapS> cjwatson: doh, I didn't refresh ;)
<SpamapS> cjwatson: the ajax code should flag any clicks that come from a page generated more than 2 hours ago. ;)
<SpamapS> cjwatson: apologies for the confusion. Thanks for fixing that. ;)
<cjwatson> ideally the ajax code should have some kind of way to spot mid-air collisions in general
<cjwatson> it's doing a transaction with the server, after all
<SpamapS> cjwatson: couchdb does this brilliantly, by assigning every record a generation, allowing developers to simply include that in all communications to the backend, and tell the user "you changed a document that has changed since you read it"
<cjwatson> indeed
<ScottK> jcastro: What's a gtk app the works the the appmenu stuff?
<jcastro> gimp
<jcastro> rhythmbox
<ScottK> jcastro: Thanks.
<jcastro> ScottK: anything but FF/ooo/chromium should work
<ScottK> jcastro: Guess which gtk apps I regularly use?
<jcastro> 0?
<ScottK> FF, OOo, and Chromium.
<ScottK> I'll try gimp.  I at least have that installed.
<jcastro> I just triggered a crash with it in gimp fyi, apported it
<njin> Hello, everybody
<ScottK> jcastro: Doesn't seem to work with the Qt/KDE appmenu.  I did install the packages seb said I needed.
<jcastro> that should work
<ScottK> It may be my fault.
<njin> I'm installing today's build Alternate amd64 but it failed cause unmert dependencies of imagemagick, it' a work in progres ?
<ScottK> jcastro: The Qt/KDE thing didn't work at all with the Xsession script, not even with  APPMENU_DISPLAY_BOTH=0, so I removed the script.  That was probably overkill.
<ScottK> I'll play with it some more over the weekend.
<jcastro> ScottK: I'll have agateau and ted/cody in the same room in 2 weeks
<ScottK> Excellent.
<jcastro> ScottK: if you file bugs just toss the "app-menu" tag on em
<ScottK> I will.  jcastro: You might want to subscribe to bugs for the plasma-widget-appmenu package as it's ALL appmenu stuff by defintion.
<jcastro> good idea
<jussi> cjwatson: you about?
 * jussi forgets cjwatson's tz. 
<jussi> anyway, anyone who knows, its rather frustrating that both the kubuntu and ubuntu maverick images are named exactly the same.
<jussi> perhaps we could get that changed??
<SpamapS> So ideally /win 10
<SpamapS> dooh
<zul> SpamapS: dude....hah
<ScottK> jcastro: I got it working in both.  In gtk it wants export APPMENU_DISPLAY_BOTH=0 to not double the menus.   If that environment variable exists at all, then the Qt/KDE version will show double menus.  To get it working for both, you need to just remove that line from the script.
<ScottK> seb128: ^^^ - When you get rid of the double windows, would you please just remove export APPMENU_DISPLAY_BOTH=1 from the Xsession script instead of setting it to zero?
<ScottK> jcastro: http://skitterman.wordpress.com/2010/07/09/menubar-for-gtk-and-qtkde-apps-on-kubuntu/
<tumbleweed> what's the development process for ubuntu-dev-tools? commit to trunk or merge review?
<ScottK> tumbleweed: Commit to trunk if you're an ubuntu-dev.  Merge review otherwise.
<tumbleweed> ScottK: cool. I have some ack-sync fixes
<jazzanova> hi
<jazzanova> I plug in usb headset, and the machine freezes:  10.4
<ScottK> jazzanova: #ubuntu.
<jazzanova> too busy there, those guy are not helpful
<veleno> hello. i'm following this guide http://blog.petersen.vg/post/237815372/debfile to build a deb. How do I do to install some files in the home directory of the user, instead of putting them in /usr/lib ?
<soren> Wow. There are so many things wrong with that article.
<veleno> soren: please point me to a more correct one
<siretart> veleno: don't. you cannot rely that a home is writeable or even existant at all.
<siretart> +on
<soren> veleno: All I know is the Ubuntu packaging guide, but that's probably not what you need.
#ubuntu-devel 2010-07-10
<maxwellian> Out of curiosity, what do people mean by "inline" patches?  Patches applied directly to the source, rather than saved in something like debian/patches?
<ScottK> maxwellian: Yes.
<maxwellian> ScottK: Thanks.  Presumably, it's better not to use inline patches if it can be avoided?
<ScottK> maxwellian: It depends.  Generally if the Debian maintainer doesn't use a patch system we prefer not to add it.
<ScottK> Beyond that, yes.
<maxwellian> ScottK: Copy that, thanks.
<Damascene> hi,
<Damascene> from time to time Ubuntu present you with update manager suggesting updating. updates are separated by importance. don't you think having a check box to enable/disable all the updates under each section?
<Damascene> * would be a good Idea
<corey__> I've got the command line installer going for 8.04 via usb on a system that has no cdrom. It's prompting me an error saying it has to have a cdrom loaded, what gives?
<corey__> supplying a mount point of /dev/usb errors as well.
<corey__> I seem to not be the only one with this issue. Any clever people with ideas?
<ScottK> corey__: Did you make the usb image with usb-creator?
<corey__> ScottK, Yes I did.
<ScottK> Hmmm.  Dunno then.  Usually I hear that about images made with unetbootin.
<ScottK> corey__: There are some releases where usb-creator-kde works better, you might try that.
<corey__> ScottK, Really. You think it's the usb creator and not the distro?
<ScottK> corey__: I don't know for sure.
<corey__> If I switch to a busybox, could I map /dev/usb to /dev/cdrom?
<ScottK> Alternatively, install 10.04.
<corey__> ScottK, That solution will not work for an Artigo A2000 that supports only 8.04
<ScottK> I don't know, I kind of doubt it would work.
<ScottK> I see.
<corey__> 8.04 Desktop Edition didn't even work properly when it came to displaying a graphical interface. It spewed corruption all over the place.
 * ScottK is the wrong person to discuss that with.  It matches my general feeling about Gnome.
<corey__> So naturally I went with the alt. cd image but (of course) I ran into another issue!
<corey__> I've used gnome for years so I don't understand what you mean by that.
<maco> Damascene: yes, that sounds like a good papercut to file
<corey__> I also used KDE. For about 5 minutes. It was the worse desktop environment I've ever used.
 * maco pats ScottK's wounded ego
<ScottK> maco: It's the beauty of FOSS, there's choice.
<maco> and choice is the beauty of kde ;-)
<maco> when its not being horribly confusing
<ScottK> That too.
 * maco recalls not-fondly the first day using kde, going "SCOTT! whats THAT mean?"
<gord> which one of these eight thousand buttons in my menu am i supoosed to press :( never really got past that with kde
<corey__> lol @ using the menu
<Damascene> maco, nice. should I open a bug about it?
<maco> Damascene: yes
<matrix> hello
<Damascene> hey matrix
<matrix> i want to be developer
<matrix> ubuntu developer
<matrix> what kind of programing language sould i learn ?
<nigelb> !developer | matrix
<ubottu> matrix: Want to become an Ubuntu developer? Look at http://www.ubuntu.com/community/processes/newdev and the Wiki (http://wiki.ubuntu.com) for involvement in specific projects such as Kubuntu or Xubuntu.
<hoare> guys I need help about creating initrd files by mkinitramfs.
<hoare>  anyone has experience?
<AnAnt> Hello, I need help with an apport script, I want to get the value of a config variable, so I did this:
<AnAnt>     SLModemdDevice = command_output(['sh', '-c', '[ ! -r /etc/default/sl-modem-daemon ] || (. /etc/default/sl-modem-daemon ; echo $SLMODEMD_DEVICE)'])
<AnAnt>  is that correct ?
<Damascene> AnAnt, Salam
<Damascene> I see you like sl-modem very much :)
<AnAnt> Damascene: wa alaykom as-salamu wa rahmatu Ullahi wa barakatoh , I maintain it because my mom's laptop needs it, and it has been orphaned by previous maintainer
<bdrung> is there something i can do to speedup bug #600626?
<ubottu> Launchpad bug 600626 in testng (Ubuntu) "[MIR] testng" [Undecided,New] https://launchpad.net/bugs/600626
<geser> bdrung: check https://wiki.ubuntu.com/UbuntuMainInclusionRequirements and document it in the bug (see https://wiki.ubuntu.com/MainInclusionProcess for the whole MIR process).
<Dupper> Good morning!  You guys gotta be awful busy so I won't take much of your time,
<Dupper> I just wanted to express praise/gratitude/amazement at how well this ubuntu thing works... I don't use it for networking or a server or anything special and it seems *much* nicer than windows
<Dupper> You really hit it on this one(running 10.04 here)
<directhex> offtopic!
<dupondje> http://ubuntu.dupondje.be/aptitude.debdiff => fix for aptitude ftbfs
<ScottK> directhex: As long as it doesn't drift into cult of personality, I think a little praise it OK.
<ScottK> ;-)
<directhex> ScottK, ~we-love-pitti ?
<ScottK> Arguably that's not cult of personality, just deserved.
<directhex> ~dholbach-huggers ?
<dupondje> fix aptituuuuude :p
<bdheeman> through 1.2.43 in the older series contain and bug; but we still only have version 1.2.42 of libpng even on lucid http://www.libpng.org/pub/png/libpng.html :(
<smoser> Hi, Is there an archive admin around ?
<smoser> I've added a new binary package 'legacy-grub-ec2' to 'cloud-init' source package, and I need to get it moved into the archive.
<smoser> I admit to not understanding what happens here, but I need 'grub-legacy-ec2' to move into the archive (build : https://launchpad.net/ubuntu/+source/cloud-init/0.5.12-0ubuntu5/+build/1862681 )
<smoser> https://launchpad.net/ubuntu/maverick/+queue?queue_state=0&queue_text=cloud-init
<zaytsev> Hi ppl. Could you please tell me whether Debian arch wildcards are supported ATM?
<zaytsev> On PPA build for Lucid it said it can't resolve deps. Does Maverick support it already?
#ubuntu-devel 2010-07-11
<lex79> cjwatson: can you add oxygen-icons, kdeartwork, kdetoys and kdewebdev to the kubuntu-dev set of packages, please? thanks
<LorgonJortle> So how does one start helping?
<evilshadeslayer> lex79: :)
<evilshadeslayer> ssup
<lex79> :)
<Damascene> hi,
<Damascene> any one knows what does eog uses for rotating images?
<LucidFox> http://www.rilpartner.se/en/rilpoint-sharepoint-look-alike-drupal-and-mediawiki-skin <-- Okay, this is some odd licensing
<LucidFox> It says GPL, but "free for personal use and non-profit organizations", and commercial users are supposed to buy the proprietary version
<LucidFox> but if it's GPL, isn't that unenforceable?
<jussi> LucidFox: that does seem strange
<lool> soren: Hmm I wonder whether you forgot to push to lp:vm-builder, or whether I'm looking at the wrong location?
<tumbleweed> can someone do a main lucid-proposed upload for me? It's been sitting in the sponsor queue for weeks (LP: #467278)
<ari-tczew> tumbleweed: on IRC you could use a phrase: bug 467278
<ubottu> Launchpad bug 467278 in openoffice.org-dictionaries (Ubuntu Lucid) "[SRU 10.04] South African English Dictionary still missing lots of words" [Undecided,New] https://launchpad.net/bugs/467278
<geser> lool: if you have some time for sponsoring bug #604241 then bogofilter is off your merge-list
<ubottu> Launchpad bug 604241 in bogofilter (Ubuntu) "Merge bogofilter 1.2.2-1 from Debian unstable" [Undecided,New] https://launchpad.net/bugs/604241
<AnAnt> this merge has been hanging for long LP 588736, is there a problem with it ?
<ubottu> Launchpad bug 588736 in mutt (Ubuntu) "Candidate release mutt 1.5.20-9ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/588736
<AnAnt> Hello, can someone sponsor this syncrequest: LP 604190
<ubottu> Launchpad bug 604190 in sl-modem (Ubuntu) "Sync sl-modem 2.9.11~20100303-5 (restricted) from Debian unstable (non-free)" [Wishlist,Confirmed] https://launchpad.net/bugs/604190
 * shadeslayer was about to say go to #ubuntu-motu :P
<lool> geser: Hope you found merging easier this time around  :-)
<lool> geser: I wonder whether we could have some Ubuntu main package as an alternate build-dep to libtokyocabinet to kill the last Ubuntu change
<lool> geser: uploaded
<bdrung> AnAnt: done
<AnAnt> bdrung: which one ?
<bdrung> sl-modem
<AnAnt> thanks
<bdrung> AnAnt: is there more?
<AnAnt> how about mutt ?
<AnAnt> LP 588736
<ubottu> Launchpad bug 588736 in mutt (Ubuntu) "Candidate release mutt 1.5.20-9ubuntu1" [Undecided,Confirmed] https://launchpad.net/bugs/588736
<AnAnt> it's been there for a while, I dont know why
<bdrung> AnAnt: standard reason: lack of manpower
<AnAnt> even for a package in main ?
<bdrung> AnAnt: yes. especially. there are more motus working on sponsoring than core-devs
<tumbleweed> AnAnt: look ta the sponsorship queue, it's dominated by main packages
<AnAnt> I see
<bdrung> i became core-dev to gain the ability to sponsor main packages
<bdrung> AnAnt: i need to write a tool that pulls the debdiffs and applied them...
<AnAnt> AnAnt: isn't there a MoM ?
<AnAnt> bdrung: isn't there a MoM ?
<AnAnt> crazy talking to myself !
<bdrung> AnAnt: there is MoM, but it doesn't help sponsoring
<AnAnt> ah, I understand now
<bdrung> AnAnt: for sponsoring a sync request, i have to type one command and then it pulls the package, builds it, and allows me to upload it
<tumbleweed> bdrung: although I find I spend a lot longer reviewing the changes than finding and applying patches
<bdrung> tumbleweed: yes, reviewing takes the longest time
<bdrung> but it depends on how large the diff to debian is
<bdrung> tumbleweed: is the debdiff http://launchpadlibrarian.net/50037132/openoffice.org-dictionaries-lucid-sru.patch really correct? You replace the broken South African English with the British English, don't you?
<AnAnt> bdrung: thanks again
<tumbleweed> bdrung: yes it's correct
<tumbleweed> we did a broken workaround to use the en_GB.aff for en_ZA
<tumbleweed> then openoffice fixed en_ZA and broke our workaround
<tumbleweed> this reverts the workaround
<bdrung> aha, ok
<bdrung> tumbleweed: done
<tumbleweed> bdrung: thanks
<bdrung> tumbleweed: more SRUs to sponsor?
<tumbleweed> bdrung: nope :)
<patrickk> why do we rush to put out a new release every 6 monthes
<lex79> cjwatson: thanks :)
<slangasek> superm1: have you seen Debian bug #588361 by chance?
<ubottu> Debian bug 588361 in wnpp "RFH: fglrx-driver -- non-free AMD/ATI r6xx - r7xx display driver" [Normal,Open] http://bugs.debian.org/588361
<hihihi100> hi, can I ask valgrind questions in here or this room has nothing to do with it?
<joaopinto> hihihi100, read the topic :)
<hihihi100> k
<superm1> slangasek, i haven't, but tseliot would be a better candidate to help since he's the primary one working on fglrx these days and has a working relationship with AMD about bugs now too
<superm1> slangasek, i'll propose them switching to ubuntu packaging though, it seems very sensible to me
<dupondje> somebody around
<dupondje> https://bugs.launchpad.net/ubuntu/+source/pybootchartgui/+bug/604140
<ubottu> Launchpad bug 604140 in pybootchartgui (Ubuntu) "ImportError: cannot import name GObject" [Undecided,New]
<dupondje> seem to be a bug with pygobject
<dupondje> alot of python apps are crashing ...
<dupondje> thx tumbleweed
<dupondje> :)
<dupondje> marked 'some' bugs as duplicate lol :)
<ryan22>  i posted a notice about a new AppUpdate service for ubuntu on the devel discuss mailing list and i was just wondering what you guys thought
<fagan> ryan22: we all sub the list so comments are posted there
<fagan> no need to ask for comments
<ryan22> no prob
<fagan> oh and most of the devs are off for the weekend
<ryan22> its just i only got a direct response from the getdeb guy, who has now agreed to track the packages on the service
<ryan22> im going to be prefectly honest
<fagan> so not much point asking until monday
<fagan> ryan22: I dont really follow packaging myself so I didnt read the thread myself
<ryan22> the point of the service to influence ubuntu to adopt my model for the post update application process
<fagan> ah well im sure that someone will comment on it during the week
<ryan22> i wanna show that there is a way to provide up to date applications without sacifising stability
<ryan22> ;)
<fagan> it takes a few days sometimes to get a response
<ryan22> i noticed your response on the process wiki and i think that your idea for a website to vote these applications is a great one
<fagan> well Mark said at the UDS that they are going to be a lot more careful anyway about their repo policy to keep things more stable for the users
<fagan> thanks
<ryan22> well you guys can always think of my service as a "beta"
<ryan22> im trying to keep it as "official" as possible in terms of process and policy
 * fagan goes reading his emails
<ryan22> man the only prob with my service is now i have like 81 packages to test...
<ryan22> i asked a friend for help :P
<micahg> ryan22: I don't know that you'd be able to host Firefox in there
 * micahg was going to post to the ML, but hasn't gotten around to it yet
<ryan22> on my former distro, i did host an updated version of firefox from one of the mozilla team ppas
<ryan22> im avoiding applications that require core library updates in any case, just to keep things syable and simple
<ryan22> *stable
<fagan> well we are updating firefox more now from what I can remember
<ryan22> gnome applications will not be to be updated on it, for example, as they usually require 300 package updates
<fagan> we upgraded hardy, intrepid, jaunty and karmic to the most recent stable version I think
<ryan22> so no empathy or epiphany updates :P
<micahg> fagan: hopefully, by the next point release, all supported versions will be on 3.6.7
<fagan> ryan22: well the problem with that is the gnome stack is a lot more complicated
<ryan22> ya
<fagan> and stuff breaks very very easy
<fagan> it would be unmaintainable IMO
<ryan22> well i uses this system on my former linux distro, so ive worked out all the kinks
<ryan22> and i know what application updates will be a pain *cough* gnome stuff *cough*
<fagan> ryan22: well its the customisations thats the problem
<fagan> we have so many things we do to make it Ubuntu
<ryan22> mind stuff like banshee and rythmbox seems to update no prob with only a few packages
<ryan22> well thats the point behind this
<fagan> well RB and banshee require bindings and up to date gtk..etc that would have to be updated too so its still to hard
<ryan22> I feel that Ubuntu is an organisation stretched to its limits. It's time for them to let go and let the developers maintain and package their own applications.
<ryan22> not really actually
<ryan22> banshee really only requires a few ipod mono libs
<ryan22> i had 1.6.0 updated perfectly on karmic
<fagan> and the mono stack too
<fagan> and thats big enough too
<fagan> its not really workable
<ryan22> to be honest, ive never had to upgrade mono when updating banshee
<fagan> ryan22: if you look at the banshee ppa you will see they update mono for you when you install it
<ryan22> if these updates require a such a core library update, they simply wont be updated
<ryan22> but thats for hardy and older versions
<ryan22> for karmic all you need to update is a few bashee and ipod mono libs
<ryan22> which is pretty isolated
<ryan22> youll see that alot actually in ppas
<fagan> I just think its unworkable because 1. its a lot of effort to keep track of the updates for the new and old versions already and 2. the ubuntu customisations each release
<ryan22> hardy will usually require 12424 package updates, but karmic and lucid will barely require anything
<ryan22> well this is a separate service
<ryan22> and ive been doing this system for about... 5 months
<fagan> the other applications are fine in ppas for users that want the newer versions and cant wait
<ryan22> and ive had no such problems
<jcastro> hi fagan, any progress on deluge?
<jcastro> fagan: if you don't have time to do it let me know asap pls
<fagan> oh jcastro im just finishing off the software properties thing first
<fagan> I can do it but it wont be this week or maybe next either
<jcastro> ok
<fagan> if thats too late then feel free to get someone else on it
<jcastro> fagan: I might have a contractor by then, I will let you know before I commit them though
<ryan22> the problem is sometimes there are problems in the packages in the ppas (very rare, ive pushed like ~250 packages, and had it happen twice, but it does happen)
<fagan> jcastro: cool
<ryan22> and its a pain keeping track and adding all those ppas
<ryan22> eh
<fagan> ryan22: I seem to remember someone talking about searching ppas if I remember
<ryan22> well right now im tracking 35 PPAs
<ryan22> and im planning on doing a testing-fest every sunday
#ubuntu-devel 2011-07-04
<robert_ancell> hughhalf, hey, can I ask you some questions about the language requirements we were discussion about lightdm?
<robert_ancell> probably best discussed in #ubuntu-desktop
<didrocks> good morning
<ricotz> slangasek, hello, perhaps you could take a look at this libgcrypt update -- http://people.ubuntu.com/~ricotz/libgcrypt11/
<dholbach> good morning
<jml> hello
<ajmitch> jml: hi
<jml> ajmitch: hi :)
<cjwatson> mvo: do you think python-apt's data.tar.xz support could be SRUed to lucid-updates for LP, or is it going to need to be a lucid-cat special?
<Laney> how do I do git reset --hard origin in bzr?
<mvo> cjwatson: I think we can SRU that
<cjwatson> Laney: bzr revert; bzr uncommit -r:parent
<Laney> cheers
<Laney> bzr: ERROR: exceptions.TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'
<Laney> :-)
<cjwatson> Laney: well, I was assuming you actually had a :parent
<cjwatson> you can use a specific revision number to -r instead
<Laney> cjwatson: I do
<Laney> cjwatson: I did bzr pull -r:parent --overwrite â seems to have worked
<Laney> seems like the problem was trying to uncommit to a revision not in the history
<cjwatson> Laney: ah, yeah, if the parent had moved on
<cjwatson> I suspect something involving ancestor: would've worked too
<doko> jhunt: upstart now built successfully on armel, I think you could revert back to build libnih with -Os on armel again
<infinity> doko: Shiny.
<infinity> doko: What fixed it?
<doko> infinity: #791315
<infinity> doko: Hrm.  I wonder if it might be time for a mass-give-back on armel.
<infinity> (Well, maybe I'll do some selective ones)
<doko> I doubt it. but then please wait until gcc-4.6.1 is uploaded and built for armel
<infinity> doko: Yeah, not doing a mass give-back.  Honest.  Just remembered a few build failures that sounded suspiciously like they could relate to that particular glibc fix.
<pitti> stgraber: edubuntu DVD built again, I fixed the langpack
<Aquina> hello!
<Aquina> Can someone point me to some config or thelike within the repo to get an impression on server and desktop kernel differences?
<persia> Aquina, Get the "linux" source package, and look at the different configs therein.  If you have questions about the organisation of that source package, #ubuntu-kernel may be a more targeted place to ask.
<Laney> persia maco Laney stgraber bdrung stgraber DMB ping
<Laney> geser you too
<geser> Laney: busy at work
<zul> didrocks: can you have a look at bug #795089 please
<ubottu> Launchpad bug 795089 in python-xattr (Ubuntu) "[MIR] python-xattr" [Undecided,New] https://launchpad.net/bugs/795089
<stgraber> Laney: sorry, was on holiday today and forgot to send an e-mail to the DMB mailing list...
<Laney> no worries, the agenda is hardly full anyway
<dupondje> bind9 version of natty seems more recent than the version in Oneiric mmmm
<cjwatson> dupondje: will be fixed in the next publisher run, thanks
<dupondje> thx
<seb128> doko, let's move there
<seb128> it's private because it's an apport segfault and it could contain password or other infos
<seb128> I don't but it got 5 duplicates since yesterday
<seb128> doko, in fact it could be a gdm bug, ignore the ping for now
<jamespage> hey - please could a member of the archive team reject metainf-services from the NEW queue - thankyou
<dupondje> Can somebody trigger a rebuild for https://launchpad.net/ubuntu/+source/ispell ?
<dupondje> its ftbfs because of broken dpkg some time ago it seems )
<dupondje> :)
<cjwatson> dupondje: indeed.  done
<tumbleweed> zul: your python-mox upload doesn't look like it called dh_python2 during build
<zul> tumbleweed: crappers
<Daviey> doko: Hey!  Can you clarify the reasoning for using dh_pysupport for bug 798362?  I thought we were supposed to be phasing it out, in favour of dh_python2?
<ubottu> Launchpad bug 798362 in python-mox (Ubuntu) "[MIR] python-mox " [Undecided,Incomplete] https://launchpad.net/bugs/798362
<dupondje> cjwatson: are you working on courier ?
<Quibus> tumbleweed: we registered openMSX at Launchpad now :-)
<tumbleweed> Quibus: hope you find it useful
<Quibus> tumbleweed: it doesn't seem to automatically couple to the sf.net stuff
<doko> Daviey: thinko. should be dh_python2
<tumbleweed> Quibus: it won't. But (if you tell it the project uses sf for bugs) it should let you link the bug to sf. You still have to file it there manually.
<sveinse> Is it possible to override/set the version in a package in a multi binary package, or is this always linked against changelog/the source package?
<micahg> sveinse: yes, you can
<sveinse> micahg: How do you do that?
<Daviey> doko: ah!  makes sense.
<micahg> sveinse: thunderbird is doing it now for the locales
<directhex> can someone push nunit through binary new, so i can upload the updates for the packages that it breaks?
<sveinse> micahg: Thunderbird on Oneiric? I didnt find anything (after a quick glance) in the natty sources
<micahg> sveinse: yes, check debian/rules in oneiric
<sveinse> micahg: Sorry, but I can't seem to find the magic in the debian/rules file. I don't see how the version number is overridden
<micahg> sveinse: line 122
<sveinse> Is the DEB_DH_GENCONTROL_ARGS var automatically passed to dh_gencontrol?
<micahg> it appears to be a per package argument that's passed
<sveinse> jup, I see the makefile things of this. I'm just wondering how this is passed on to dh_xx
<micahg> appears to be automagical
<sveinse> dh_gencontrol doesn't seem to be overriden at least
<dupondje> Somebody knows how to get pbuilder-dist have umask 0022 ?
<nh2> is there an API for the message indicator I can use to check if it is green (new message) or that tells me when it turns green?
<bdrung_> Laney: sorry. i was busy and forgot to let you know
<dupondje> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631087
<ubottu> Debian bug 631087 in pbuilder "pbuilder failed to create base.tgz (mount: /proc already mounted or /var/cache/pbuilder/build//24199/proc busy)" [Important,Open]
<dupondje> seems we have this in ubuntu also
<dupondje> :s
<`26> I'm trying to build a LiveCD image from scratch and I can't find the build scripts anywhere. Have I not been looking deep enough or are they simply not available?
<dupondje> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=631087 => I hope somebody can look at this bug. It affects Oneiric also :(
<ubottu> Debian bug 631087 in pbuilder "pbuilder failed to create base.tgz (mount: /proc already mounted or /var/cache/pbuilder/build//24199/proc busy)" [Important,Open]
<faina> The // makes me think that one of the $DIST variables isn't being set?
<faina> Hi. I tried building a new pbuilder on a 11.04 system and it worked for me. Though I have fairly customized .pbuilderrc
#ubuntu-devel 2011-07-05
<Gryllida> hi
<faina> hello
<Gryllida> faina: http://packages.ubuntu.com/natty/all/emacs/filelist ... is that all that Ubuntu has for emacs? Why do I download the .deb at http://packages.ubuntu.com/natty/emacs and it has very few files?
<faina> emacs is a meta-package just depends on the actual real packages that contain a real version of emacs
<faina> so you can just install emacs and not worry if its emacs22 or emacs23
<Gryllida> faina: I want to look into the deb. What package would the `real` one be?
<faina> Best path is to do apt-cache show emacs and look at the dependency list
<Gryllida> I'm trying to add a usr/share/menu/packagename to  .deb; I can extract it, add file to a dir, but have no idea how to compress it back.
<faina> Gryllida: I usually do apt-get source, modify the package, and then do debuild, but that can be difficult depending on the package
<Gryllida> faina, ok, I'll read on that; thank you.
<pitti> Good morning
<faina> hello
* pitti changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: zul
<didrocks> good morning
<dholbach> good morning
<infinity> pitti: "Two days out from the expected release of Maverick Alpha 3 ..." <-- Cut'n'paste, for the loss? :)
<pitti> infinity: argh
<pitti> at least the milestone bug link is correct
<infinity> Yeah, I just checked that.
<pitti> that indeed took some extra time to fight against the giant ftbfs bug list
<chrisccoulson> pitti has a time machine!
 * pitti quickly hides it, otherwise everyone would want to use it
<pitti> ScottK: do you know why kpackagekit/packagekit want to go to universe? doesn't kubuntu use that?
<pitti> plasma-widget-networkmanagement as well, was that replaced with something else?
<debfx> pitti: kpackagekit has been replaced by muon
<debfx> we still use plasma-widget-networkmanagement
<debfx> the source package has been renamed though
<pitti> debfx: ah, thanks
<pitti> debfx: so plasma-widget-networkmanagement should be removed entirely?
<debfx> pitti: yes (the source package)
<pitti> debfx: so the network-manager-pptp-kde binary should be removed with it? (no rdepends except plasma-widget-networkmanagement)
<pitti> oh, that's a replaces:
<pitti> so it seems both binaries can be removed along?
<debfx> the network-manager-*-kde binaries can be removed as well
<pitti> ok, done; thanks!
<tkamppeter_> didrocks, hi
<didrocks> tkamppeter_: hey
<tkamppeter_> didrocks, we have decided on that during our session and there we have already found out that the extra space consumption is small (~ 300K). RAOF is already working on packaging colord.
<didrocks> tkamppeter_: we are already oversized, but if there is a log of the session to bring color management to the CD, I'm ok
<didrocks> tkamppeter: can you see this blueprint btw?
<tkamppeter> didrocks, the Blueprint is https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-icc-color-management
<tkamppeter> It is approved for Oneiric and on the Whiteboard you can see that the estimated space consumption is ~300K.
<didrocks> tkamppeter: with colord and argyll?
<tkamppeter> seems so.
<didrocks> tkamppeter: so, can you make a MIR for argyll and update it as well to a recent version? seems nothing is happening there
<tkamppeter> didrocks, I will do so. IThere is a new package available but not officially uploaded. See Debian bug 622620, most recent posting: https://launchpad.net/~pmjdebruijn/+archive/argyll-release
<ubottu> Debian bug 622620 in wnpp "O: argyll -- Color Management System, calibrator and profiler" [Normal,Open] http://bugs.debian.org/622620
<didrocks> tkamppeter: poke me once done
<tkamppeter> didrocks, OK.
<dupondje> cjwatson: Are you working on merging courier ? Or can I take ,
<dupondje> ?
<soren>  /win 38
<soren> YEah, that'll work. :(
<pitti> YokoZar: FYI, removing ttf-umefont (following Debian), which wine1.[23] depend on; the package was renamed to fonts-horai-umefont
<nickmoeck> Hi, I'm not sure if this is the right place for this question, but #ubuntu is being pretty much useless, so... here goes:
<nickmoeck> Let's say the official repos contain software-2.2.1. I create a PPA with a package based on software-2.2.1 (with just a slightly different build configuration).  I call it software-2.2.1~ppa1 and I install it from my PPA.  What happens if software-2.2.2 gets uploaded into the Ubuntu repos, and I don't make a new package in my PPA?
<pitti> nickmoeck: 2.2.1~ppa1 is smaller than 2.2.1, so you couldn't even upgrade to your PPA
<pitti> nickmoeck: and if 2.2.2 gets into Ubuntu, an upgrade will use that
<nickmoeck> pitti: Okay, I guess it's time to get a little more specific then.  I need php without the suhosin patch, so I want to create a package with it disabled, put it into a PPA, and apt-get upgrade to that version. I don't want the version with suhosin to be installed if the official package is upgraded.
<nickmoeck> Is there any way to do that, short of using pinning?
<pitti> nickmoeck: I'd use apt pinning; I don't know of another way, excecpt of course always providing a newer version in your ppa
<nickmoeck> pitti: okay, thank you very much
<MrRagga> hi, is there any kind of frontend package maintainer use to promote packages between the different stages?
<pitti> "stages"?
<MrRagga> pitti: what i am looking for is a web gui frontend, which can be used to promote packages between different stages using an authorized system. e.g. user A is allowed to promote the package foo-1.0.deb from experimental to stable using a web gui
<MrRagga> pitti: similar to what is described here http://maemo.org/packages/
<pitti> MrRagga: for unstable -> testing that's done by a script; for the testing -> stable part, that's called "release team" :)
<pitti> in Ubuntu we have a release team, but no concept of "testing"
<pitti> (FTR, these are called "releases", not "stages")
<pitti> or "series" in the DAK/Soyuz terminology
<ogra_> well, we have a web gui for copying packages between PPAs
<ogra_> not necessarily the same but similar
<MrRagga> ogra_: is this web gui open source?
<ogra_> its part of launchpad, so yes, i think so
<ogra_> dont ask me about launchpad code though :)
<MrRagga> hehe, ok. thanks.
<jml> Good morning
<Satoris> How can I found out what graphics driver a live CD system is using, since it does not come with glxinfo? System settings just says it is  "unknown".
<tjaalton> grep Xorg.0.log
<tjaalton> though it's not that easy to actually find the match
<tseliot> pitti: I've added support for multi-arch to the fglrx handler in jockey. Shall push my changes, release and upload or just push and leave it unreleased? http://pastebin.ubuntu.com/638304/
<pitti> tseliot: hm, you didn't push yet?
<pitti> tseliot: anyway, please upload
<Satoris> Oneiric live cd has lost 3D acceleration on my Intel machine, so I need to find out if it's the driver or something in Unity.
<tjaalton> Satoris: grep drivers /var/log/Xorg.0.log | tail -1 | sed 's/.*\///;s/_drv.so//'
<tseliot> pitti: no, I haven't pushed anything yet. I'll make an upload too then, thanks
<Satoris> Hmm, it loads intel, vesa, fbdev and then intel for the second time.
<tjaalton> fallbacks
<tjaalton> dunno why it loads intel the second time though
<tjaalton> my X61 works fine with intel, and just finished the upgrade on my sandybridge desktop
<Satoris> What is the correct package for reporting this bug? X? Mesa? Kernel? Something else?
<tjaalton> intel is loaded but 3d doesn't work? pastebin the logfile
<tjaalton> and you can install mesa-utils on the live session :)
<tjaalton> btw, the upgrade removed many "unneeded" packages, like postfix, bsd-mailx etc
<tjaalton> dunno why
<Satoris> It says that "mesa-utils has no installation candidates".
<tjaalton> enable universe
<tjaalton> quite silly to move binary packages to universe, when the rest are in main..
<tjaalton> ah
<tjaalton> sorry, that's not the same source as mesa
<tjaalton> but mesa-demos
<Satoris> http://pastebin.com/zc7jNkgD
<tjaalton> everything looks ok to me, same chip as on my X61
<tjaalton> duh, no this is sandybridge of course :)
<tjaalton> ok let me boot up this one
<Kottizen> hi, the package 'teeworlds' is outdated - what can I do?
<tjaalton> Satoris: works fine here
<Satoris> With the latest daily build live CD?
<tjaalton> Satoris: nah, upgraded system. I can try that one too
<Satoris> Also, this is a Macbook which are always kind of tricky in their own ways.
<Satoris> Glxinfo says it should be working. But still I get unity-2d.
<tjaalton> what if you run 'compiz --replace' from a terminal?
<Satoris> Now it works. Modulo the fact that compiz crashes quite quickly after that.
<Satoris> Assuming it falls back to unity-2d?
<tjaalton> maybe so
<tjaalton> maybe the daily cd is missing some updates?
<Satoris> Trying to report the compiz bug gives an error saying that the problem can't be reported due to obsolete package version. So that would be a yes then.
<tjaalton> run dist-upgrade and restart gdm/lightdm
<seb128> hum, valgrind seems to be broken in oneiric
<seb128> doko_, lool: ^ do you know if that's due to the eglibc update?
<lool> that happens frequently wiht eglibc upgrades indeed
<seb128> :-(
<lool> --9631-- Warning: DWARF2 CFI reader: unhandled DW_OP_ opcode 0x2a
<lool> valgrind: m_debuginfo/readdwarf.c:2338 (copy_convert_CfiExpr_tree): Assertion 'srcix >= 0 && srcix < VG_(sizeXA)(srcxa)' failed.
<lool> that's pretty bad
<lool> Implement some extra DWARF ops that gcc 4.6.1 seems to use. Fixes #275284.
<lool> today on the valgrind devel list
<lool> Date: Tue,  5 Jul 2011 10:22:33 +0100 (BST)
<lool> some hours ago  ;-)
<lool> http://article.gmane.org/gmane.comp.debugging.valgrind.devel/13919
<lool> so actually due to gcc 4.6.1, not eglibc
<lool> seb128: I'm pushing this patch, but didn't test whether it's enough to fix valgrind
<seb128> lool, thanks, I will test once it's built
<seb128> lool, I found a bug where somebody confirmed r11856 fixes a similar issue so let's see
<lool> I read through the last 15 or so SVN commits, and that seemed to be the only interesting one for x86
<seb128> lool, thanks!
<lool> seb128: new valgrind works for me
<seb128> lool, \o/
<seb128> lool, well done, thanks again
<lool> seb128: np, I feel like I am returning the favors from last week   ;-)
<seb128> ;-)
<directhex> is something frozen?
<dupondje> cjwatson: https://bugs.launchpad.net/debian/+source/debootstrap/+bug/805886 if you have some time :)
<ubottu> Ubuntu bug 805886 in debootstrap (Ubuntu) "/proc does not get umounted after debootstrap" [Undecided,New]
<hrw> cjwatson: debootstrap hack for bug 802985 provided as debdiff - take a look when have time
<ubottu> Launchpad bug 802985 in eglibc (Ubuntu Hardy) "[lucid] /var/lib/dpkg/tmp.ci/preinst: 399: arithmetic expression: expecting EOF: "3.0-0-generic"" [High,Triaged] https://launchpad.net/bugs/802985
<mterry> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: zul, mterry
<barry> pitti: ping
<ScottK> pitti: Kubuntu doesn't use kpackagekit/packagekit anymore in oneiric.  It can go to Universe.
<pitti> ScottK: thanks
<pitti> barry: pong
<barry> pitti: hi, re: bug 788514 and python-oauth
<ubottu> Launchpad bug 788514 in Ubuntu Oneiric "python packages on the CDs not using dh_python2" [Medium,Confirmed] https://launchpad.net/bugs/788514
<barry> pitti: doesn't look like i can comfortably use udd to merge sid's package with oneiric (lots of conflicts).  do you have any suggestions?  i.e. should we just blow away oneiric's version and upload sids?
<pitti> barry: I haven't checked whether we have some ubuntu specific changes there; I just took the sid source, built it, and tested
<pitti> barry: we can sync sid's version if we don't need changes, no need for an upload there
<barry> pitti: gotcha.  okay, i'll investigate further then
<barry> pitti: unfortunately, all the changes are in-tree, so sussing out the ubuntu specific changes is going to be difficult
<pitti> barry: I hope they won't be necessary in the first place; distro specific changes in a protocol library sound bad
<barry> pitti: agreed.  i'll see what i can do and i'll ping dobey since he touched the package last
<barry> zul: ping re: bug 788514 and python-image-store-proxy.  any word on that package?  anything i can do to help?  it's the last python-central package on the server cd so i'm eager to see this one closed
<ubottu> Launchpad bug 788514 in Ubuntu Oneiric "python packages on the CDs not using dh_python2" [Medium,Confirmed] https://launchpad.net/bugs/788514
<zul> barry: sorry for the delay ill take a look at it today
<barry> zul: thanks!
<seb128> slangasek, hi
<seb128> slangasek, it seems you forgot to push your recent avahi upload to the vcs, do you still have it locally? could you push?
<apw> pitti, did we find any alternative to editmoin in the end?  i
<pitti> I didn't
 * apw has just reliased that his status pages are no longer updating as a result
<james_w> apw, why do you need an alternative?
<apw> james_w, it doesn't seem to work any more
<james_w> apw, "no content found" error or something similar?
<apw> error: body information not found
<apw> james_w, ^
<james_w> not sure that means you have to replace it :-) bug 801284
<ubottu> Launchpad bug 801284 in editmoin "Doesn't work with latest moin over https" [Undecided,New] https://launchpad.net/bugs/801284
<apw> james_w, ok i'll try and get that to work
<pitti> jibel: https://blueprints.launchpad.net/ubuntu/+spec/desktop-o-xorg-stakeholders-request has "Arrange community testing for Alpha-2" for you for alpha-2; does that go beyond the usual image testing which  happens anyway?
<jibel> pitti, yes there are specific test cases http://xorg.qa.ubuntu.com/qatracker/
<pitti> jibel: oh, nice!
<pitti> jibel: so if that is being done already, I guess this could be set to done?
<apw> james_w, did you test this change successfully ?
<jibel> pitti, it is not done, it will start next week. If binary drivers are ready of course.
<pitti> jibel: ack
<apw> james_w, as it seems to be sorely lacking some code, and doesn't work on wiki.ubuntu.com
<saam> hello, when I install fglrx form jockey in oneiric it says SystemError: installArchives() failed  But a recent changelog in jockey says multi arch problem with fglrx solved
<apw> james_w, so for w.u.c you need to use MOIN_SESSION_80_ROOT regardless of it being https, for w.c.c you need _443_ ...
<apw> james_w, and the patch as is doesn't actually pass the cookiename
<apw> pitti, ok with some hackery i have a (bodged) editmoin which works ... the changes arn't commitable me thinks, but it may be of use
<pitti> apw: oh, awesome! so it's not some complicated change to oauth?
<pitti> apw: we must make Gustavo use the wiki more
<apw> pitti, the issue is the names of the cookies have changed, and changed in an incompatible way on w.u.c and w.c.c
<apw> pitti, ok i've bodge this hideously but it at least works for those two destinations, and should be the same for the rest: http://people.canonical.com/~apw/misc/editmoin
<pitti> apw: hah, nice one
<apw> pitti, you need to lookup the new ID strings in your browser cookies and shove them in .moin_ids as normal
<pitti> apw: perhaps an upstreamable fix would be to try all three of these in succession?
<apw> pitti, yeah that sounds more reasonable doesn't it
<apw> i'll try that out later
<apw> pitti, ok i've updated the version at the above url, should be more like you are suggesting
<apw> james_w, i've pushed an updated patch to your bug, which seems to work on all the wikis
<apw> and james_w good work finding that, its been making me grumpy for weeks
<mterry> sabdfl, fyi just noticed that ~ubuntu-users is using the old Ubuntu branding
<mterry> (you are the team owner)
<jml> g'night folks.
<sabdfl> thanks mterry
<mterry> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: zul
<barry> pitti: bug 806103
<ubottu> Launchpad bug 806103 in python-oauth (Ubuntu) "Sync python-oauth 1.0.1-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/806103
<doko> ogasawara, apw: did miss the notice; gcc-4.6 4.6.1-2 now has the Linaro updates (still building on armel)
<slangasek> seb128: blast; if I didn't push it to the VCS, it's because I grabbed the UDD branch again by mistake.  Let me grab the right branch and push now, if you haven't already done it
<seb128> slangasek, I didn't but don't bother, I can do it when I do the upload if the work need to be redone anyway
<seb128> it was in case you had it and forgot to push
<slangasek> seb128: seems not :(
<seb128> slangasek, I would say "debcheckout it your friend" but it might have been confused by the debian vcs infos
<slangasek> seb128: debcheckout is only my friend if there is a Vcs field... I have suggested that debcheckout should DTRT for both UDD and non-UDD branches, but I don't think that's been implemented
<seb128> slangasek, there was a vcs field in the upload before yours
<seb128> oh you mean if there is not one if will not fetch the udd vcs
<seb128> would make sense to checkout the vcs if specific or udd if there is none
<seb128> (ok, we could also move to UDD for desktop, but that would be too easy :p)
<slangasek> there are still other packages maintained in non-UDD branches, it's not just a desktop problem
<seb128> indeed
<seb128> ev, could you drop the libcheese depends from ubiquity in the next upload if you still not use it?
<tlp> Bug #804655 must be what killed Unity for me on my iMac. No r300g.
<ubottu> Launchpad bug 804655 in mesa (Ubuntu) "r300 loading instead of r300g" [Undecided,New] https://launchpad.net/bugs/804655
<broder> so...if -dbgsym packages aren't going into the librarian currently, does that mean there's no way to get debugging symbols for a package that's been superseded?
#ubuntu-devel 2011-07-06
<nemo> so https support is added to apt finally...
<nemo> ... about a week after I manage to get an exception made in the stupid websense firewall at work for one ubuntu mirror
<nemo> oh well. should simplify adding other apt lines.
<nemo> (they ignored https since they could sniff it very effectively)
<nemo> they *could* request same file and make a deny decision based on that, but they fortunately don't
<maxb> nemo: er? apt has had https support for years
<nemo> oh? huh. I guess none of the mirrors have support
<nemo> I'd tried a bunch of 'em w/o success
<nemo> was just reading through latest updates to apt on natty, and one was about adding https as a transport
<nemo> supporting it in deb lines
<nemo> oh well, I got 'em to open up mirror.anl.gov  (picked it because it was short and official sounding)
<nemo> so hopefully no more stupidity with websense
<nemo> I also complained to websense, but that went absolutely nowhere
<echosystm> i need to package something up that uses a postgresql database and opens up a particular user to the world
<echosystm> is there some kind of includes folder for the pg_hba.conf settings?
<nibalizer> hi all, anybody had any luck making a puppet 2.7.1 package?
<echosystm> can anyone point me towards some information about packaging applications that use postgres?
<echosystm> or examples?
<broder> echosystm: i might take a look at http://people.debian.org/~seanius/policy/dbconfig-common-using.html/ but i don't know how official that is
<echosystm> thanks
<pitti> Good morning
<Gryllida> hi
<pitti> apw: thanks! I'll send it to Gustavo and prepare a new release
<RAOF> pitti: Re: bug #790145 - I'm pretty sure that the fixes for bug #786941 that were in the -proposed but not verified 0.12.3+noroms-0ubuntu9.7 package aren't in the new 0.12.3+noroms-0ubuntu9.10 that's now in proposed.
<ubottu> Launchpad bug 790145 in qemu-kvm (Ubuntu Maverick) "kvm husb: ctrl buffer too small" [Medium,Fix committed] https://launchpad.net/bugs/790145
<ubottu> Launchpad bug 786941 in qemu-kvm (Ubuntu Lucid) "Cannot boot from non-existent NIC" [Low,Fix committed] https://launchpad.net/bugs/786941
<pitti> RAOF: right, I thought that was the idea?
<RAOF> I thought the idea was that the 0.12.3+noroms-0ubuntu9.8 which had the fixes for both bugs had been superceded by the 9.9 from -security, so the proposed version needed to have the 9.9 changes folded in?
<pitti> yay! there, working editmoin heading archivewards
<RAOF> Oh, hai.  82% swap usage?  Maybe that's why things are stuttering every now and then :)
<pitti> RAOF: in https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/790145/comments/24 Serge said that they will only re-attempt that other SRU on request
<ubottu> Ubuntu bug 790145 in qemu-kvm (Ubuntu Maverick) "kvm husb: ctrl buffer too small" [Medium,Fix committed]
<RAOF> So, at minimum what should happen is the 786941 should lose the âfix committedâ status.  I would have thought that we didn't want fixes dropping out of the package like that, but I guess the unverified status makes things different.
<pitti> RAOF: at least they shouldn't block other fixes to go in, yes
<RAOF> Oh, arse.  Why did I think that would work?
<RAOF> pitti: I think bug #804655 should be fixed for A2, and it's got a simple and cringeworthy fix.  It's not too late to upload mesa, right?
<ubottu> Launchpad bug 804655 in mesa (Ubuntu) "r300 loading instead of r300g" [High,Confirmed] https://launchpad.net/bugs/804655
<pitti> RAOF: we can re-roll CDs; I need to go through the tracker still, but right now I'm not aware of any other major breakage
<pitti> RAOF: so please upload away
<RAOF> Thanks.
<didrocks> good morning
<dholbach> good morning
<pitti> RAOF: how big of an issue is 804655? does it cause the live CD to fail on these devices?
<pitti> RAOF: once jibel is up, I'll ask whether we can do another round of testing, but I'd like to know more about how bad it is
<RAOF> pitti: It causes unity to fail to work properly on the live CD.
<pitti> shouldn't it fall back to unity-2d?
<RAOF> It should, yes.
<RAOF> It's not a horrific problem, and if you'd prefer it to miss A2 it certainly can.
<pitti> it doesn't change the "should be uploaded now" part, of course
<pitti> (then upgrades will get the fix, and if we need to respin for other reasons, we'll grab it)
<RAOF> Aha!
<pitti> RAOF: ok, thanks; so let's see what jibel says
<RAOF> Waiting for the test build to finish to ensure I haven't made any other braindead mistakes :/
<poolie> pitti, hi!
<pitti> hey poolie, how are you?
<poolie> good thanks, a little tired
<poolie> about the bzr 2.3.3 natty sru
<poolie> first, thanks for accepting it into proposed
<poolie> there is a regression in it, bug 786980
<ubottu> Launchpad bug 786980 in Bazaar 2.3 "bzr: ERROR: bzrlib.errors.ReadOnlyError: A write attempt was made in a read only transaction" [High,Confirmed] https://launchpad.net/bugs/786980
<poolie> so, we should cancel the SRU
<poolie> it's not a catastrophic regression but still it shouldn't go in
<poolie> i'm not quite sure where to formally say that - on one of the SRU bugs?
<pitti> poolie: yes, on any of those would be good
<poolie> and i guess mark it 'verification-failed'? not actually true but might have the right effect
<pitti> poolie: right; I was going to do that, but feel free to do it yourself
<poolie> done, thanks
<broder> hmm...does the version of grub2 in maverick not support usb 3.0 boot?
<broder> i would have sworn i had tried this when i was prepping bug #565047, but i can't seem to make it past grub now
<ubottu> Launchpad bug 565047 in initramfs-tools (Ubuntu Maverick) "Unable to install off USB 3.0 port (HP Envy 15 Laptop)" [Undecided,Fix committed] https://launchpad.net/bugs/565047
<cjwatson> dupondje: courier> no
<cjwatson> dupondje: feel free
<dupondje> cjwatson: prepared one (https://bugs.launchpad.net/ubuntu/+source/courier/+bug/803176)
<ubottu> Ubuntu bug 803176 in courier (Ubuntu) "courier version 0.65.0-3ubuntu4 failed to build on i386" [Medium,New]
<ogra_> cjwatson, oh, back from holiday ? i thought you were out the whole week
<cjwatson> broder: grub doesn't have EHCI yet, no.  somebody posted a patch for it to grub-devel a week or two ago
<cjwatson> ogra_: no, just one day
<ogra_> cjwatson, the code live-build uses for ext2/3/4 creation doesnt come from livecd-rootfs, right ? seems resizing got massively slow with the way these images are formatted
<ogra_> a 4G SD card takes about 25min here (used to be 20-30sec with livecd-rootfs generated images)
<cjwatson> ogra_: no, it's separate, the livecd-rootfs code had accreted various weirdnesses and I didn't see a particular reason to keep it
<cjwatson> it's basically just mkfs.ext3 and copy stuff in
<ogra_> well, i think we adjusted the inode count or some such to make resizing faster
<cjwatson> I thought I mirrored that
<cjwatson> but feel free to patch it
 * ogra_ will have to check the code ...
<cjwatson> I'm not going to look at it any further at this point
<ogra_> k, will do
<pitti> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: zul, pitti
<ogra_> grmbl ... live-build ...
 * ogra_ curses
<ogra_> so it seems i get a broken sources.list on ports ...
 * ogra_ wonders why he sees irqbalance running all the time, i though that should only start once on boot and kill itself again
 * dholbach hugs pitti
 * pitti hugs back dholbach
<pitti> quite sizable queue this morning :)
<dholbach> yeah, there's quite a lot going on
<seb128> thanks to a week of rally with no sponsoring
<dholbach> I sponsored a few :)
<dholbach> but not too many
<seb128> I just cleaned a few as well
<dholbach> nice
<seb128> well, I tend to do desktop sponsoring often but those don't show up on the queue
<seb128> just on our versions page
 * dholbach nods
<dupondje> Whats the default umask on launchpad builders ?
<pitti> dupondje: hey
<pitti> dupondje: I had expected 022 as well
<pitti> infinity, lamont ^ do you know?
<pitti> it's about https://launchpad.net/ubuntu/+source/courier/0.66.1-1ubuntu1/+build/2611450/+files/buildlog_ubuntu-oneiric-i386.courier_0.66.1-1ubuntu1_FAILEDTOBUILD.txt.gz which complains about the buildd umask
<dupondje> Nothing changed in that part of the code neither, so before it was 022
<soren> Well, the umask changed in Oneiric, didn't it?
<soren> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-June/000862.html
<soren> Why would the buildd's be different?
<pitti> soren: it only affects users with a private user group
<infinity> pitti: Which the buildd user is.
<infinity> pitti: buildd:buildd
<pitti> if the buildd user falls into that case, then the umask would be 002
<pitti> dupondje: ^
<ogra_> infinity, you are talking in your sleep !
<pitti> infinity: thanks
<infinity> ogra_: Too hot here, keep waking up. :/
<infinity> dupondje: To be fair, a test for an EXACT umask in a build system is daft.
<soren> No.
<infinity> soren: Yes? :)
<soren> What is daft is to require a specific umask, but not just set it, but rather complain when it's wrong.
<infinity> soren: well, yes, that too.
<soren> Now *that* is daft.
<infinity> soren: But you're still doing something wrong if you need to set a umask to build things, IMO.
<pitti> dupondje: so I suppose debian/rules should call "umask 022" before calling build?
<dupondje> yep
<soren> infinity: Generally, yeah.
<dupondje> fixing that now
<infinity> You could just remove the test too.
<infinity> Since whatever it wants the umask set for (make install, probably) will just get fixed later by dh_fixperms
<infinity> debhelper: working around broken upstreams for over a decade.
<dupondje> It has been introduces here:
<dupondje>   * check umask in debian/rules because Courier requires umask 022 for
<dupondje>     installation (Closes: #157149)
<infinity> Err.
<infinity> Wait, that was in debian/rules, not the upstream makefiles?
<infinity> I didn't even look.
<infinity> Now that's EXTRA broken.
<infinity> This is the part where I back away slowly before I NMU the Debian package in a fit of rage.
 * infinity goes to try to sleep some more.
<geser> infinity: I hope you don't get any nightmares from this
<soren> infinity: I'm trying to visualise you trying to fall asleep in a fit of rage.
<soren> infinity: It doesn't look easy.
<dupondje> pitti: I added new patch now
<pitti> dupondje: uploaded, thanks! You might want to send that to Debian as well
 * dupondje doesn't get it anymore now
<Laney> hey, I just noticed that Debian asks derivatives to add a popcon url, rather than replacing theirs with ours. Why don't we do this? http://wiki.debian.org/Derivatives/Guidelines#Popularity_Contest
<tumbleweed> Laney: isn't our popcon around 10* higher than debian?
<tumbleweed> (I mean, debian wolud need a way to distinguish between the two)
<Laney> they ask for it.
<Laney> I think it's not supposed to be 'how many debian users use this package'
<Laney> (see the page I linked)
<tumbleweed> Laney: yeah, I know, but I still think Ubuntu is a little different from other derivatives here
<Laney> I don't see why it's not relevant
<pitti> dupondje: wah, failed again :/
<Laney> as long as you use the data wisely, of course
<pitti> https://launchpadlibrarian.net/74640246/buildlog_ubuntu-oneiric-i386.courier_0.66.1-1ubuntu2_FAILEDTOBUILD.txt.gz
<pitti> dupondje: did you actually try to build this under a 002 umask? (so that it would fail before)
<dupondje> I did a testbuild here. worked fine
<tumbleweed> Laney: I'd want to know waht the popcon maintainers in debian think, and why we never submitted to them in the first place (was it just because we predated http submission?)
<dupondje> Its strange, umask gets set without errors, but still its broken somehow
<Laney> sure, that's why I asked
<infinity> dupondje: Err.  You can't set the umask in a makefile like that.
<infinity> dupondje: Every call in make is a forked shell, it will inherit the umask of the parent (make), not the previous shell call.
<infinity> dupondje: Are you positive the package will actually FTBFS if you just remove the silly check?
 * infinity notes that the check was added 9 years ago, a lot may have changed...
<dupondje> The check is still in the Makefile
<dupondje> to check if umask is 022
<infinity> In which Makefile?
<infinity> The upstream one?
<tumbleweed> Laney: -> debian-derivatives?
<dupondje> Makefile.in:	@test `umask | sed 's/^0*//'` = 22 && exit 0; \
<pitti> dupondje: perhaps try something like
<pitti> -                && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \
<pitti> +                 && umask 022 && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \
<pitti> and drop the umask check before?
<infinity> It only checks on make install
<infinity> Which makes some sense.
<infinity> (Still broken for Debian, but makes sense for tarball dists)
<pitti> dupondje: perhaps try something like
<pitti> -                && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \
<pitti> +                 && umask 022 && $(MAKE) LIBTOOL=/usr/bin/libtool && touch stamp-build; \
<pitti> and drop the umask check before?
<dupondje> I'll test that :)
<pitti> (sorry if that came through twice, DSL reconnect)
<dupondje> :)
<Laney> tumbleweed: already did
<infinity> You can also export INSTALL_IGNORE_UMASK=1 to skip the check.
<Laney> actually there was (as is often the way) a fizzled out thread there already
<infinity> dupondje: pitti's patch won't do you any good.
<pitti> infinity: why not? it's the same shell?
<infinity> dupondje: Either export INSTALL_IGNORE_UMASK=1, or set the umask before each $(MAKE) call in the install target in debian/rules.
<infinity> pitti: It's install that checks for umask, not the build.
<infinity> pitti: (which makes sense, for tarballs distribution)
<infinity> pitti: Makes less sense for Debian. :P
<dupondje> first fixing pbuilder-dist now on my build system, so I can try different tests :D
<dupondje> cause debootstrap seems broken somehow :s
<tumbleweed> Laney: ah right, that's where I saw it. pere seemed to discourage it for distros who deviate from debian a bit
<infinity> dupondje: http://paste.ubuntu.com/638828/
<infinity> dupondje: That should do it.
<dupondje> thanks, will try it out
<infinity> (It will actually work if you only umask the first install call, but doing both is more in the spirit of what upstream wanted. :P)
<infinity> Their install-perms target in Makefile.in should depend on install-check-umask, but doesn't.
<dupondje> The package is not the cleanest one around indeed :(
<infinity> Nope.
<seb128> cjwatson, ev: could you drop the ubiquity libcheese-gtk-dev build-depends next time you upload it?
<dupondje> infinity: https://launchpadlibrarian.net/74642842/umask_fix2.debdiff
<ev> seb128: sure
<seb128> ev: thanks
<seb128> ev: I want to demote cheese since the current version doesn't build and we will need a bunch of mirs, if we need it in main we should handle it properly and not let it depwaiting as it's doing
<seb128> it will need mir and gst components from the universe sets
<dupondje> pitti: uploaded new fix. Should do the trick now
<infinity> dupondje: Looks correct.
<dupondje> build fine also :)
<infinity> dupondje: Uploaded for you.
<dupondje> thx
<stgraber> pitti: did you see bug 800700? I noticed that yesterday on a lucid system. Apparently half the langpacks are still in -proposed...
<ubottu> Launchpad bug 800700 in language-pack-gnome-fr (Ubuntu) "Lucid: package language-pack-gnome-fr cannot be upgraded" [Undecided,Confirmed] https://launchpad.net/bugs/800700
<pitti> stgraber: I didn't; thanks for pointing out! checking
<pitti> stgraber: fixed
<stgraber> pitti: thanks!
<pitti> thanks muchly for pointing out
<apw> pitti, do you know who promoted fsl-imx51, i am told it missed having its overrides applied
<apw> (and thus ended up in universe)
<pitti> I don't know, no
<pitti> it's not even in oneiric?
<ogra_> only lucid
<pitti> oh, do you mean linux-fsl-imx51 in lucid?
<apw> pitti, sorry yes, that
<pitti> so that was me
<pitti> the current kernel sru workflow doesn't really involve a step of setting overrides
<apw> pitti, note this information is second hand, and it is being fixed by someone, just wondering if we're missing a step
<pitti> apw: oh, it is? I'm currently changing it
<pitti> apw: direct PPA->archive copying is circumventing the binary NEW procedure
<pitti> so I guess we'll need to make "log into cocoplum and fix the componetn after copying" a part of the procedure :/
<pitti> apw: moved tomain
<pitti> to main
<apw> pitti, ok cool.  thats unfortuante that its a manual step
<pitti> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: zul
<pitti> zul: I think you might want to @pilot out, too :)
<zul> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<zul> geez..
<superm1> could someone look over why the mythbuntu livefs cron job decided to not even try yesterday? the others have logs, but nothing in http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/mythbuntu/
<seb128> pitti \o/
<seb128> (sponsoring queue down to 61!)
<pitti> just sent the report :)
<pitti> superm1: cron jobs are off for alpha-2 RM
<pitti> superm1: just poke me if you need another build
<superm1> pitti, ah, yeah then could you do another build for me?
<pitti> but they seem to have failed since July 2
<pitti> superm1: yes, running
<superm1> thanks
<pitti> there were eglibc troubles over the weekend
<pitti> superm1: so, let's see what this log will say
<seb128> barry, hey
<dupondje> https://launchpad.net/ubuntu/+source/vinagre/3.1.3-0ubuntu1/+build/2611478
<dupondje> launchpad says build failed, but the logfile shows that build was successfull ...
<tumbleweed> dupondje: look at the very end
<seb128> dupondje, the amd64 builder breaks build when the log has implicit conversions
<dupondje> ehh looked over that
<pitti> superm1: http://cdimage.ubuntu.com/mythbuntu/daily-live/20110706/
<pitti> superm1: added to tracker
<superm1> pitti, thanks
<shadowstalker> Hello all! :-)
<seb128> ogra_, janimo: bigon fixed the json-glib build issue on debian so will be fixed in ubuntu once it's synced
<seb128> will do that later when it's published in debian
<seb128> bigon, thanks ;-)
<bigon> np :)
<seb128> barry: could you commit your dh_python2 changes to the vcs for the packages you upload?
<seb128> barry, gnome-python-desktop gnome-applets gnome-menus gedit at least are outdated
<janimo> seb128, nice, I could not figure out what it was when I looked
<seb128> barry, which means either the next upload will get rejected or your change will be dropped
<barry> seb128: will do
<seb128> if people don't notice you uploaded without updating the vcs that's it
<seb128> barry, thanks
<shadowstalker> I'm quite a newbie but if someone has a minute to give me a little direction I would really appreciate it! (patching)
<seb128> barry, you might want to check other things you uploaded, and debcheckout is your friends to checkout a source ;-)
<barry> seb128: i wonder if the udd guidelines should be updated, or whether the tools themselves should be modified.  i'm not sure what the correct procedure should be though
<seb128> barry, well "udd guidelines" are for udd use, reality is that we don't use udd in a consistant way
<seb128> so ubuntu guideline != udd guideline
<bigon> seb128: any new for cheese (and the required mir?)
<barry> seb128: yeah, but i guess my question is this: if you grab a udd branch, how do you know you should ignore that and use the vcs branch?
<seb128> bigon, no
<seb128> bigon, i've asked ev to drop the ubiquity build-depends on libcheese so we can demote it
<cjwatson> at the moment, you have to find that out before deciding to grab the udd branch, realistically
<bigon> seb128: well cheese could become a hard dep for empathy
<seb128> bigon, well, we will patch it out
<barry> cjwatson: really?  what's the best way to do that?
<seb128> bigon, it's a no way until the gstreamer parts it needs are in good or base
<cjwatson> $ debcheckout -p gedit
<cjwatson> bzr     https://code.launchpad.net/~ubuntu-desktop/gedit/ubuntu
<cjwatson> seems reasonable enough to me ...
<seb128> barry, cjwatson: we should teach debcheckout to get the udd vcs if it doesn't do yet
<seb128> if there is no other vcs
<cjwatson> (for an authenticated checkout, drop -p and add -a)
<Laney> you should teach update-maintainer to drop the debian xs-vcs then
<seb128> that as well
<cjwatson> s/drop/move to XS-Debian-Vcs-/
<Laney> yes
<seb128> or teach debcheckout to favorite launchpad vcs-es on ubuntu when several are listed
<seb128> which is a bit hackish but should do what we want most of the time
<Laney> adding XS-Ubuntu-Vcs and preferring that is another solution
<brendand> mvo - has update-manager been switched to pygi/gtk3 yet?
<Laney> then it would also allow us to specify non-launchpad branches too ... (e.g. I have some git branches on alioth for Ubuntu packages that it'd be nice if people used)
 * cjwatson would prefer not having massive churn in everything that already has Vcs-blah in Ubuntu
<cjwatson> I don't see anything wrong with having an Ubuntu-specific Vcs-Git header
<mvo> brendand: no, not yet
<Laney> no there wouldn't be, if I could specify branches there
<seb128> well first step would be to suggest in the documentation to use debcheckout or to check for non UDD vcs-es
<seb128> seems some people read the UDD documentation and assume that UDD is the standard way to do things which is not the case...
<barry> but i'm missing something.  what exactly would that "check for non UDD vcs-es" be?  a non-launchpad or non-bzr url?  or something else?  iow, how would i know whether it's safe to use the udd branch?
<seb128> barry, apt-cache showsrc <source> and search for Vcs lines
<seb128> $ apt-cache showsrc gedit | grep Vcs
<seb128> Vcs-Bzr: https://code.launchpad.net/~ubuntu-desktop/gedit/ubuntu
<seb128> or use debcheckout...
<barry> seb128: so, you mean if there are any vcs lines at all, you cannot use the udd branch?
<Laney> debcheckout can't tell if Vcs is for Debian or Ubuntu
<tumbleweed> how common is using debcheckout for desktop packages, though? The majority of packages are not going to have launchpad Vcs lines, so I don't think I've ever used debcheckout on ubuntu
<cjwatson> an explicit Vcs line indicates that the maintainer is doing something outside of UDD
<Laney> so just unconditionally using that isn't enough
<pitti> tumbleweed: pretty much all GNOME related packages have them
<cjwatson> assuming it's for Ubuntu; Laney is right that there are wrinkles
<cjwatson> most installer packages have Vcs-Bzr too
<barry> cjwatson: right, but checking for Vcs-Bzr is a narrower test
<cjwatson> one of these days I'll get round to pushing them to lp:ubuntu/... and moving everything over, but a million and one things to do etc.
<cjwatson> barry: I have Debian packages with Vcs-Bzr; no reason to assume it's Ubuntu-specific
<Laney> which is part of the reason for suggesting XS-$Vendor-Vcs; then you are indicating that this is the location to use for $Vendor
<barry> cjwatson: no question, there will be false matches
<Laney> if you just change it in the merge you aren't giving the tools enough information
<pitti> well, as 95% heuristics it could always check for the word "ubuntu" in the branch
<cjwatson> barry: designing something that minimised them would be kind of nice though :)
<pitti> all desktop package branches are named "ubuntu", and most of them should be owned by ~ubuntu-{desktop,core-dev}
<seb128> well we could say that ubuntu modified package that to keep only the ubuntu Vcs info
<seb128> "have to keep"
<barry> i'm just looking for some criteria other than saying "if there's a vcs-* line, don't use udd" because i'm afraid it will make udd basically unusable
<cjwatson> the (not machine-readable) criteria should be "if there's a vcs-* line that looks like it's explicitly maintained by Ubuntu people, prefer that to UDD"
<pitti> let's say "if there's a Vcs- line, check first"?
<cjwatson> that's your criterion - now figure out how to make that machine-readable
<barry> cjwatson: :)
<cjwatson> pitti's heuristic certainly isn't a bad one
<seb128> you can use "if the revision has an ubuntu number and the control a Vcs use that, otherwise use UDD"
<barry> yes, but "check first" means?  ask someone, inspect the vcs branch, something else?
<seb128> then we just need to make sure we clean debian vcs infos when we modify sources in ubuntu
<broder> cjwatson: wait, does that mean that grub2 shouldn't currently work with usb 3.0 drives, or doesn't work with usb 3 drives in usb 2 ports? Because I definitely did the latter with natty last week, but can't seem to get it working with maverick
<barry> seb128: that matches much closer to what i was thinking
<pitti> barry: the naming/ownership of the branch sohuld generally make it clear whether it's the ubuntu one
<cjwatson> broder: I expect I mean the controller rather than the drive
<cjwatson> broder: maverick - no idea, too long ago :)
<seb128> but what pitti said, checking for ubuntu in the vcs url should work for most cases
<pitti> barry: like lp:~ubuntu-core-dev/pkgname/ubuntu obviously is
<tumbleweed> seb128: and the ubuntu packages without ubuntu in the version?
<seb128> tumbleweed, out of some special case of native ubuntu packages those are synced from debian
<pitti> tumbleweed: even upstart has an ubuntuish version number now, and udev too
<tumbleweed> yeah, I'm talking about the special cases :)
<pitti> tumbleweed: do we still have these? frankly, we should fix those packages to have ubuntuish versions and stop trampling Debian's namespace
<seb128> well, 95% if better than nothing
<seb128> is
<seb128> even if we have a few corner cases which has confusing
<barry> the other thing to remember is the process is different too, iow, you'll have to create a branch and do a mp against the vcs branch
<seb128> but usually things maintained in ubuntu are full source and packaging in bzr
<tumbleweed> pitti: I agree with that, but I still see people using them because "the package is blacklisted" or "ubuntu-only, no such package in debian"
<seb128> so they can easily be on lp:ubuntu namespace
<pitti> tumbleweed: for those you can still check Vcs-Bzr:, just as you'd do (or not) right now..
<cjwatson> barry: right, but for now, that's inevitable
<barry> cjwatson: yep, agreed
<cjwatson> pitti: honestly I can't see a reason to change e.g. ubiquity's version number
<barry> okay, i think i have enough to at least start a discussion on the udd mlist.
<tumbleweed> pitti: if the heuristic is "ubuntu" in version: use Vcs, else use UDD then those need to be special cased (but yes, there aren't many)
<barry> tumbleweed: or maybe -0ubuntuX ?
<pitti> tumbleweed: more specifically, use Vcs-Bzr
<cjwatson> especially for a native package it's annoying and makes it look like it's a branch from Debian when it isn't
<pitti> superm1: just saw your mythbuntu-default-settings upload; do you want that for a2?
<tumbleweed> having an XS-$Vendor-Vcs-* certainly helps to override all the special cases, whatever heuristic is used
<cjwatson> tumbleweed: yeah, I think I agree
<cjwatson> mvo: I've been seeing a number of cases recently where changelogs.ubuntu.com isn't up to date; the most recent I noticed was isc-dhcp-client 4.1.1-P1-17ubuntu3.  Could there be a systemic problem here?
<pitti> right, but any change to Vcs-Bzr: structure will take a cycle to implement
<mvo> cjwatson: let me check
 * barry -> lunch, but i'll open a thread on udd afterward
<pitti> barry: thanks; the non-UDD branches are not going to go away anytime soon, so any improvement for the current situation is appreciated
<pitti> unless we can retarget the lp:ubuntu/pkgname branches to the Vcs-Bzr: ones
<micahg> umm, the lp:ubuntu/foo branches still serve a purpose even if the branch for making changes is elsewhere, I don't think they should not be available
<micahg> in theory at least, it lets one look at upstream changes over time
<mvo> cjwatson: thanks for the pointer, there is indeed something broken on changelogs, seems to be caused by the recent machine upgrade, I am on it
<cjwatson> great, thanks
<dupondje> cjwatson: dunno if you got time to look at https://bugs.launchpad.net/ubuntu/+source/debootstrap/+bug/805886 ?
<ubottu> Ubuntu bug 805886 in debootstrap (Ubuntu) "/proc does not get umounted after debootstrap" [Undecided,New]
<chrisccoulson> kirkland`, you wanted the latest mongodb from debian didn't you?
<tumbleweed> I did a hacky patch to pull-lp-source, to do vcs checkouts, using the "ubuntu" in Vcs-Bzr + X-Vcs-$Vendor-Bzr heuristics: lp:~stefanor/ubuntu-dev-tools/udd-checkout if that interests anyone
<cjwatson> dupondje: not yet, no.  it certainly surprises me since that always used to be unmounted
<cjwatson> dupondje: I was on holiday yesterday and am still catching up.
<dupondje> cjwatson: hehe ok :) no stress :D
 * ogra_ hugs bigon 
<ogra_> thanks !
<cr3> barry: did something change in python-imaging or related package(s) in oneiric? I'm getting this error when building a package on oneiric that works just fine all the way down to lucid: IOError: decoder zip not available
<slangasek> bdmurray: where should I hook into apport to collect additional info if /var/cache/debconf/config.dat is mentioned in an upgrade log?
<bdmurray> slangasek: probably data/general-hooks/generic.py
<bdmurray> slangasek: in apport ...
<slangasek> bdmurray: ack
<barry> cr3: i think one of the launchpad guys got hit by this in dublin but i never found out what the issue was
<cjwatson> dupondje: can't reproduce this with a bare debootstrap run
 * cjwatson tries with the invocation from the Debian bug
<bdmurray> doko: so bug 756028 ended up being tagged multiverse as the source is multiverse although the binary is in universe.  Does that seem reasonable?
<ubottu> Launchpad bug 756028 in opendrim-lmp-powermanagement (Ubuntu Oneiric) "opendrim-lmp-powermanagement version 1.0.0-0ubuntu1 failed to build on i386" [High,In progress] https://launchpad.net/bugs/756028
<superm1> pitti, we're skipping a2, lots of other issues right now
<superm1> we'll start with a3
<cjwatson> dupondje: can't reproduce this with the debootstrap line in the debugging output from the Debian bug either.  Can you please show me a way I can reproduce this with plain debootstrap?
<cr3> barry: do you think the problem is likely to be ephemeral and will resolve itself somehow?
<barry> cr3: unknown at this point, sadly.  i wonder if it could be a multiarch related problem.  does it happen only on oneiric?
<barry> cr3: unfortunately too, PIL isn't being maintained upstream anymore afaik
<cr3> barry: yep, only oneiric, the same package built fine on natty and below
<barry> cr3: i suspect multiarch issues
<cr3> barry: this might affect people developing on launchpad because of spriteutils, I think
<cr3> barry: didn't multiarch kick in in natty though?
<barry> cr3: that's where i saw it.  the lp build process fails because of this error
<cr3> barry: exactly the same problem, and you encountered this on oneiric rather than natty though, right?
<barry> cr3: i actually didn't encounter the problem, one of the lp devs did.  maybe ask around on #launchpad-dev?
<cr3> barry: will do, thanks
<barry> cr3: okay, sorry to be so unhelpful atm.  let me know how it goes
<cr3> barry: for know, it's comforting enough to know I'm not alone :)
<barry> ;)
<micahg> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg
<directhex> when exactly do packages get removed from the archive which are meant to be removed from the archive?
<micahg> depends on the immediacy I think, definitely before the end of the cycle
<bdmurray> slangasek: so bug 756028 ended up being tagged multiverse as the source is  multiverse although the binary is in universe.  Does that seem  reasonable?
<ubottu> Launchpad bug 756028 in opendrim-lmp-powermanagement (Ubuntu Oneiric) "opendrim-lmp-powermanagement version 1.0.0-0ubuntu1 failed to build on i386" [High,In progress] https://launchpad.net/bugs/756028
<bdmurray> slangasek: so bug 756028 ended up being tagged multiverse as the source is multiverse although the binary is in universe.  Does that seem reasonable?
<bdmurray> slangasek: this has to do with the ftbfs bugs
 * micahg seems to be missing the point of tagging the component in the first place
<bdmurray> micahg: to be able to search for ftbfs and component using a tag rather than using the component thing in advanced search
<micahg> bdmurray: what's the point of searching by component though
<bdmurray> micahg: ask skaet
<slangasek> bdmurray: I think a 'multiverse' tag there is fine
<bdmurray> slangasek: okay, that's what I'd thought too
<seb128> barry, do you have upload rights?
<barry> seb128: i do
<cjwatson> directhex: if you care about anything in particular, file a bug - everything ubuntu-archive is subscribed to will get done
<seb128> barry, so feel free to commit directly rather than open merge requests
<barry> seb128: will do.  wasn't sure what the right etiquette was!
<seb128> barry, well, if you uploaded you should at least keep the vcs updated with what is in the archive ;-)
<seb128> barry, if you want review better to ask before uploading, it doesn't make sense to review the merge if you already uploaded
<barry> seb128: good point :)
<broder> i'm looking at the udd import failure for open-vm-tools. based on the comment in bug #494481, it sounds like the right thing to do is to uncommit and push --force - is that right?
<ubottu> Launchpad bug 494481 in Ubuntu Distributed Development "Too easy for people to not use merge-upstream" [High,Triaged] https://launchpad.net/bugs/494481
<broder> i guess i'd need to find someone else who could do that for natty since i don't think i can
<bdrung_> tumbleweed: patches are welcome
<tumbleweed> bdrung_: of course :)
<pitti> superm1: understood
<broder> where is the best place to ask udd infrastructure questions (specifically, trying to hunt down and fix an import failure)? here? #launchpad?
 * micahg wonders if there's a UDD channel
<broder> micahg: #ubuntu-udd and #udd are both empty, so i guess not
<Laney> there's a mailing list though
<mok0> Laney: liked your blog post
<Laney> which one?
<Laney> I liked that UDD one more :-)
<mok0> Laney: the motuvation one
<Laney> mok0: cheers, bit of a moan every now and again does good
<mok0> Laney: ... but does it help? :-(
<micahg> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Laney> mok0: I posted it to -motu too some time back. You should reply â we can have an 'old washed up gits' support group :-)
<broder> Laney: I think one thing we haven't done as good of a job of exploring is, in addition to getting more workers, trying to reduce the workload
<broder> e.g. more strongly discouraging REVU and Ubuntu-specific packages
<mok0> Laney: I missed it... stopped following u-m regularly since the there is rarely anything interesting and the team has basically stopped working (as you said)
<mok0> Laney: But "old-washed-up-gits"... sounds good to me :-)
<dupondje> cjwatson: commented the debootstrap bug
<Laney> broder: well I do try to advocate working elsewhere as much as I can, but that can only help so far
<Laney> and really the stuff that's left is the most tedious
<cr3> barry: I reported but about python-imaging and subscribed you, it's a recent regression so I hope that'll be helpful
<barry> cr3: okie dokie
<dupondje> damn, newest upgrade broke vinagre :(
<RedSingularity> Hey everyone.  This a good place to ask questions about packaging, or is there a more appropriate channel?
<maxb> RedSingularity: for packaging for ubuntu itself, yes. for ppas, use #ubuntu-packaging
<RedSingularity> maxb: thats what I am looking for.  Thanks much :)
<bdmurray> cjwatson: it might be helpful to look at bug 500175 as it has testcase in the description
<ubottu> Launchpad bug 500175 in software-center (Ubuntu Lucid) "Canceling an installation in Software Center crashes debconf with "Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66,"" [Undecided,Confirmed] https://launchpad.net/bugs/500175
<cjwatson> bdmurray: ok, tomorrow
<cjwatson> thanks
<TheMuso> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: TheMuso
<TheMuso> Whoops should have done that 20 mins ago.
#ubuntu-devel 2011-07-07
<soultekkie> http://brainstorm.ubuntu.com/idea/28233/ << vote if you like the idea
<Chipzz> soultekkie: have you thought this through?
<Chipzz> soultekkie: ubiquity simply copies the content of the livecd
<Chipzz> which would mean you would need to have both unity and gnome3 on the livecd
<RAOF> Well, that's a simple matter of programming.  More to the point, offering options like that in the installer is not philosophically aligned with what we want to do.
<Chipzz> which I doubt is an option, given that the available space is constantly an issue
<Chipzz> RAOF: it's not. not for ubiquity
<Chipzz> RAOF: it is an option for the alternate install cd, ok
<RAOF> Chipzz: If we *wanted* to do it we could without too much trouble.  We already (optionally) install packages from the internet during install.  I just don't think we want to do it.
<TheMuso> And given that classic GNOME 3 is rather different to GNOME 2...
<Chipzz> RAOF: that sounds more like a gross hack to ubiquity than "a simple matter of programming" though ;)
<lifeless> given ubiquities deep roots in d-i, not really.
<Chipzz> it would probably still qualify as "gross" though (IMO) ;)
<RAOF> As I say, we *already* do it.  It would presumably be simple to extend.
<Chipzz> I can see where it makes sense for things like nvidia drivers etc
<Chipzz> or certain network drivers
<Chipzz> because you need those to have a proper functioning system
<lifeless> network is one of the least sensible :)
<Chipzz> heh. right :)
<Chipzz> that just dawned upon me
<Chipzz> unless you have both wired and wireless and it's the wireless network driver you need
<Chipzz> or vice versa
<StevenK> "Let's connect to the Internet so we can download a driver, so you can connect to the Internet." Oh.
<Chipzz> StevenK: "04:10 < Chipzz> unless you have both wired and wireless..."
<StevenK> Don't assume the wired works either :-)
<RAOF> Could an archive admin please reject pyabiword from natty-proposed?
<TheMuso> The classic phrase comes to mind... "I would if I could, but I can't."
<RAOF> There's a StevenK here, right? :)
<TheMuso> Oh right.
<StevenK> RAOF: pyabiword/0.8.0-6build2 Component: universe Section: python ?
<RAOF> StevenK: Yes please.
<StevenK> RAOF: Rejected.
<RAOF> Ta muchly.
<soultekkie> I think ubuntu will lose many users by going "unity" only.and btw Gnome# is so great it can be used as is or with the classic look&feel
<soultekkie> *gnome3
<scialex> soultekki, im not so sure. its a WIP but its got potential
<TheMuso> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * micahg sees there's not much left in the sponsoring queue, will try to drive it down further in a little bit
<pitti> Good morning
<pitti> micahg: seems scarneiro now fixed all the opendrim packages, these seem easy
<micahg> pitti: they're all ready to go in?
<pitti> micahg: it's the same FTBFS fix for all of them, and it was fixed properly now
<pitti> just pointing out if you want to do some 10 queue items with relatively little effort
<micahg> pitti: sure, was about to go hunting for patches :)
<micahg> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: Alpha-2 soft freeze | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: micahg
<micahg> pitti: do they have to go in any order?
<pitti> micahg: I don't know these packages at all; but I suppose not
<micahg> pitti: oh, ok, no worries, I'll figure it out
<broder> micahg: i...don't ever think i've seen documentation telling me to update timestamps
<broder> launchpad will still keep its own timestamps, right? so this is purely a changelog optimization?
<micahg> broder: I did say try, not must :), but point taken, it does seem like changelog optimization to some extent, but the changelog is what ends up on the end-user's system, not the LP timestamp
<micahg> when I started using bzr, I was trained to update timestamps, but maybe that was just for the release commit...
<broder> i think i have a vague understanding of what you're trying to do, but whenever i've looked at timestamps in changelogs, i've only cared about them on the scale of months, so it seems weird to me to add this extra step i have to remember
<micahg> maybe someone will make debcommit do it for you :)
<micahg> broder: feel free to reply and say how pointless it is :), I don't mind being wrong
<micahg> broder: Actually, I should've been more specific I was referring to when the day was off, not just the hour or minnute
* pitti changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #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> (might as well lift the freeze now, a2 images aren't going to get any better)
<poolie> broder, which timestamps would you be updating? in debian/changelog?
<micahg> poolie: see my mail to ubuntu-devel
<poolie> i see
<didrocks> good morning
<brendand> anyone know if the default for 'When the power button is pressed' was changed to 'Suspend' deliberately in Oneiric?
<pitti> it's supposed to bring up a dialog with the shutdown/reboot/suspend/etc. options (works here)
<micahg> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> good morning
<ronin___> good morning
<dholbach> hey ronin___
<ronin___> hi dholbach
<ronin___> dholbech: Thank you for your reply
<ronin___> dholbech: I sand another mail to you
<dholbach> ronin___, great, I'll have a look in a bit
<ronin___> dholbech: thank you
<brendand> pitti - sure you haven't changed it manually? on all the default install i do it suspends
<pitti> brendand: I have upgraded since natty, could very well be due to that
<brendand> pitti - but the default should still be 'ask'? i'll file a bug if so
<pitti> I think so; suspending doesn't make much sense, that's what the lid is for
<pitti> if anything, it should default to powering off and asking
<pitti> (for confirmation)
<pitti> but the "power off/reboot/suspend" dialog makes sense IMHO
<brendand> as far as i can tell gnome-power-manager is setting the default so i'll raise a bug there
<pitti> brendand: should be gnome-settings-daemon
<brendand> pitti - true that
<brendand> pitti - thanks
<brendand> pitti - bet it got borked by the gconf -> gsettings move
<brendand> pitti - bug reported 806855. thanks
<pitti> thanks
<Quintasan> Good morning.
<wzssyqa> how to rebuild it : https://launchpad.net/ubuntu/+source/ns3
<didrocks> ScottK: hey, small question, is there any reason (other not nothing for now depends on it), that libboost-system1.46.1 and libboost-filesystem1.46.1 are in universe?
<evfool> hi all, quick question: is it worth fixing software-center bugs now, as the interface seems like its being reimplemented with gtk3 and also been redesigned by mpt and other designers
<mwhudson> is this a reasonable place to talk about dh_python2?
<brendand> got somebody with a touchpad broken by update in natty, anyone know how to find last weeks version of xorg-xserver?
<mvo> evfool: depeds on the bug, if its a small one its still worth fixing as we can backport it to 4.0. the gtk3 port is work in progress still, much is still missing s its good to have the gtk2 in good shape
<evfool> thanks mvo
<mvo> evfool: what bug do you have in mind?
<evfool> small ui/usability fixes, like bug 802918, bug 802919 and bug 802920
<ubottu> Launchpad bug 802918 in software-center (Ubuntu) "Message 'This App has not been reviewed yet' without network connection" [Low,Confirmed] https://launchpad.net/bugs/802918
<ubottu> Launchpad bug 802919 in software-center (Ubuntu) "Install menu is enabled while disconnected" [Low,Confirmed] https://launchpad.net/bugs/802919
<ubottu> Launchpad bug 802920 in software-center (Ubuntu) "'Reinstall previous purchase' menu is enabled while disconnected" [Low,Confirmed] https://launchpad.net/bugs/802920
<evfool> mvo^
<mvo> evfool: I think that is still fine, you can even do it in the 4.0 branch and I will merge it from there into trunk
<mvo> brendand: hello! you update-manager bbattery_msg_part_hidden branch is ready for merging, right?
<brendand> mvo - no, i have a problem where it hangs when any of the labels are hidden that i want to resize
<brendand> mvo - hope i don't offend anyone here but gtk is pretty stupid at handling text wrapping
<brendand> mvo - someone gave me an idea of how to finish it but not got time yet to check it out again
<brendand> mvo - do you have a deadline?
<mvo> brendand: iirc this got better with gtk3
<mvo> brendand: no, deadline, no
<brendand> mvo - that's cool, so the change might be even easier
<brendand> mvo - it might be good if i wait until the gtk3 changes are done
<mvo> yeah, exactly
<brendand> mvo - is there a tracking bug for that in update-manager?
<mvo> for gtk3?
<mvo> there is a branch by evfool that I check out now :)
<brendand> mvo - oh cool
<evfool> mvo - my branch? for update-manager? don't expect anything from that, just ran the pygi converter, and got stuck, but pitti asked me to push it somewhere and when he'll have time he'll look at it ... but he's extremely busy
<evfool> mvo: just wanted to experiment with porting from pygtk to pygi, but I was not able to handle it, so I though I'd leave it to more experienced people or wait until I gain some more experience
<evfool> *were
<mvo> evfool: aha, thanks anyway for the update, I have a look at it
<benonsoftware> Hi all
<mikey_> kees, RAOF or bryce: Hi, I got advised to direct a question I have to you last time I was on this channel. Basically I've been involved with writing a couple of very basic scripts / apps that use X to create a second X session on which to play games, as a workaround for Compiz and game clashes. As a strategy it works well but I'm finding it increasingly difficult to make work within the Ubuntu X session management f
<mikey_> ramework. I was hoping I could talk to you to come up with some definite solution.
<tjaalton> cjwatson: hey, I need a grub gfxpayload quirk in natty for lenovo L420, but I'm not sure where to get the information for the quirk line. any pointers?
<slomo> doko: are you aware that the two binutils versions in sid from this month are not working well with valgrind? dlopen of a .so that was linked with new binutils (no matter if gold or normal ld) crashes valgrind: http://pastebin.com/qBrsiiTC
<doko> slomo: lool pointed out an upstream fix
<slomo> doko: want me to try the fix?
<doko> slomo: sure
<slomo> doko: where is it? :)
<seb128> slomo, doko: the fix is in oneiric and verified to work
<seb128> slomo, https://launchpadlibrarian.net/74573993/valgrind_1%3A3.6.1-0ubuntu1_1%3A3.6.1-0ubuntu2.diff.gz
<slomo> seb128: thanks
<seb128> slomo, yw
<tjaalton> cjwatson: think I got it
<RAOF> mikey_: #ubuntu-x would be the place to talk about that.
<mikey_> RAOF: oh, ok
<Amoz> dholbach, you still need someone to freshen up the packaging guide?
<dholbach> Amoz, yes
<dholbach> Amoz, somebody started work on bringing it more in line with the general design of the ubuntu pages but ran out of time
<dholbach> Amoz, let me dig up the link again
<Amoz> dholbach, I already have it
<dholbach> oh, great :)
<Amoz> I was trying some different approaches, but all of them seems unclean
<Amoz> dholbach, and "ubuntu pages" refers to something like the wiki?
<dholbach> let me see if Ronnie and daker are in awake in #ubuntu-locoteams - they did quite a bit of web ui stuff for loco.ubuntu.com
<dholbach> Amoz, yes
<dholbach> there's already a branch with all the css, we just need to find a good way to map the css classes(is that what it's called? :-)) I think
<daker> hi
<dholbach> daker, Amoz and I were talking about http://daniel.holba.ch/blog/?p=1026
<Amoz> dholbach, I think the best way would be to redesign the html templates and let the django-light-theme (or what the name is) be untouched
<Amoz> if that's possible
<dholbach> Amoz, yes, and reuse those bits where possible
<Amoz> yeah otherwise we have to do a lot of css restyling I think
 * dholbach nods
<dholbach> even if we do it gradually, like do big changes first and then fix small bits as we go would be sweet
<dholbach> daker, does the approach generally sound sane?
<daker> ok, is there any work being done on that?
<dholbach> https://code.launchpad.net/~raoul-snyman/ubuntu-packaging-guide/new-colours/+merge/56010 was the first try (without using the ubuntu-website bits)
<dholbach> apart from that there's no work in progress AFAIK
<didrocks> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: didrocks
 * dholbach hugs didrocks
 * didrocks hugs dholbach back (I won't be there next week for my patch pilot time, so swapping with today as nobody is there :))
<dholbach> didrocks, nice :)
 * daker checking the code
<dholbach> Amoz, daker: should we maybe move to #ubuntu-website? (and whoever else is interested in retheming the packaging guide)
<daker> yep
<didrocks> dholbach: stupid question, but how can I reject https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/gnome-desktop3/oneiric-201107061510/+merge/67055 ? I can only set it as merged/WIP
<dholbach> didrocks, james_w can do it
<dholbach> I think there's a bug open for changing that in the LP UI
<didrocks> dholbach: ok, so apart from faking "merged", I can't make it disappear from the sponsoring list?
<dholbach> WIP will make it go away from the list
<tumbleweed> didrocks: you could delete the merge proposal too
<didrocks> tumbleweed: not sure if james_w doesn't want to clean afterwards the new branches
<didrocks> so yeah, WIP + comment then
<tumbleweed> didrocks: aah, I've deleted some recently
<cjwatson> tjaalton: you should be able to extract it from lspci and massage it into the format described in /usr/share/grub-gfxpayload-lists/blacklist/00_header
<pitti> james_w: who can I poke to get lp:ubuntu/gvfs updated?
<tjaalton> cjwatson: yeah, it should be fine now, just needs some testing
<james_w> pitti, should be up to date in a few minutes
<pitti> james_w: cheers!
<pitti> is that something we can avoid happening somehow?
<pitti> in oneiric we synced from Debian
<pitti> but now we'll need to modify it again
<james_w> pitti, in general you can ask in #bzr
<james_w> but that problem shouldn't happen
<evfool> mvo I have made some fixes for the 4.0 branch, and requested a merge to the 4.0 branch, I hope that's ok, and you can merge it in the trunk, if the fix's ok
<james_w> it happens if you push --overwrite the branch
<pitti> james_w: is that what syncing did?
<james_w> pitti, nope
<james_w> syncing should be fine
<mvo> evfool: \o/ awsome! thanks!
<barry> cjwatson: can you do the sync request in bug 806103 today?
<ubottu> Launchpad bug 806103 in python-oauth (Ubuntu) "Sync python-oauth 1.0.1-3 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/806103
<pitti> I can sync it
<barry> pitti: awesome, thanks
<barry> pitti: that'll close out python-central on the cds!
<pitti> yay
<cjwatson> barry: that's what I get for intermittently checking IRC
<ScottK> didrocks:  libboost-system1.46.1 and libboost-filesystem1.46.1 are only in Universe because nothing in Main needs them.
<didrocks> ScottK: thanks for the answer :) I know at least it's not a blocker then
<james_w> pitti, unfortunately it hit another (known) bug and so it won't be up to date
 * psurbhi booted successfully from the first event-based initramfs on my laptop :) - just uploaded a ppa 
<stgraber> yeah!
<psurbhi> https://launchpad.net/~csurbhi/+archive/natty-initramfs
<psurbhi> will not work for initrds that change the root device
<psurbhi> that might need some modification
<psurbhi> however should work otherwise
<psurbhi> if not, i will definitely wait for bugs
<psurbhi> :)
<psurbhi> is there a way of filing for bugs for a ppa?
<nigelb> Not yet
<nigelb> just make a project if you want
<psurbhi> ok
<psurbhi> nigelb, thanks :)
<nigelb> np :)
<psurbhi> editing the description of how to try the ppa
<psurbhi> any volunteers:
<psurbhi> https://launchpad.net/~csurbhi/+archive/natty-initramfs
<psurbhi> please follow the description at this ppa
<psurbhi> i will wait for updates
<stgraber> psurbhi: you may want to e-mail ubuntu-devel@lists.ubuntu.com to get more testers
<nigelb> Also, blogging on the kernel blog might me a good idea
<psurbhi> ok
<psurbhi> stgraber, nigelb, thanks!
<psurbhi> plan to make foundations team mates scape goats before i start attacking the ubuntu devel
<psurbhi> :D
<psurbhi> stgraber, which means i will wait for your input
<psurbhi> :P
<nigelb> heh
<nigelb> then you'll have "psurbhi made my laptop to stop working!"
<psurbhi> nigelb, hehee! if you follow the instructions, you are pretty much risk free
<psurbhi> if not, you definitely are at a big risk
<psurbhi> :D
<psurbhi> whatever gurantees, never delete your initramfs that works
<psurbhi> :)
<psurbhi> use a temporary one and edit your grub command line
<psurbhi> :)
<psurbhi> do that and you will sail safely
<nigelb> If were running Natty, I'd definitely give it a shot, but alas my machines run Lucid and Maverick
<nigelb> need to upgrade the Maverick machines this weekend
<psurbhi> nigelb, you could try it for maverick too really
<psurbhi> i have tested it on maverick and natty
<nigelb> In which case, trying on maverick now.
<psurbhi> nigelb, thanks a lot!!!!
<psurbhi> please remember not to install the ppa- but install the SOURCE
<Laney> why didn't you just upload the source if it's that bad?
<stgraber> psurbhi: hmm, I'll have to download and install a Natty VM then :) I only have Oneiric systems around.
<psurbhi> stgraber ok!
<psurbhi> Laney, I have uploaded the source
<Laney> i mean somewhere other than a ppa
<psurbhi> Laney, I haven't yet worked on the install scripts
<psurbhi> yet
<psurbhi> its not that bad yet!
<psurbhi> ;)
<psurbhi> Laney, let me upload the source somewhere too :)
<Laney> psurbhi: I meant that if you don't want people to install it then you might as well /just/ upload the source to your webspace
<Laney> PPAs are for distributing debs really
<Laney> but YMMV :-)
<psurbhi> Laney, yeah i agree with you
<nigelb> Actually, in that case, just push it into a bzr repo
<psurbhi> ok
 * Laney shrugs
<psurbhi> also kept the source as tar.gz here:
<psurbhi> http://people.canonical.com/~surbhi/event-based-initramfs/
<Laney> I was just trying to save users from accidently installing .deb :P
<psurbhi> Laney, ack!
<Laney> cheers psurbhi!
<mvo> barry: silly question, but can you recomment a good python indent tool? I have a piece of old python code of mine that is really a broken tab/2,4 indent piece that I want to fix once and for all
<mvo> barry: nevermind, I found reindent.py
<ion> I use vim to fix broken indentation.
<barry> mvo: yeah, i use emacs :)
<ion> :set et sw=4 sts=4, :%retab
<mvo> barry: emacs is too clever, it notces the 2 space indent in a class wanted to keep it
<mvo> thanks ion
<ion> (if i interpreted your message correctly)
<mvo> ion: yeah, that is what I want, a global reindent of the whole file with 4 spaces
<serge_> pitti: hi, regarding the ill-fated bug 790145, would you mind kicking the current qemu-kvm packages from lucid-proposed and maverick-proposed (they've been superseded) and accepting my new ones which sit atop the new -security versions?
<ubottu> Launchpad bug 790145 in qemu-kvm (Ubuntu Maverick) "kvm husb: ctrl buffer too small" [Medium,Fix committed] https://launchpad.net/bugs/790145
<bdmurray> mvo: I am looking at bug 803277 and an error message in the dpkgterminallog.txt regarding update-alternatives
<ubottu> Launchpad bug 803277 in mono (Ubuntu) "package mono-runtime 2.4.4~svn151842-1ubuntu4 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,New] https://launchpad.net/bugs/803277
<bdmurray> mvo: update-alternatives: error: /var/lib/dpkg/alternatives/cli corrupt: invalid status
<mvo> bdmurray: I think we need to ask for addding this file to the bugreport
<mvo> bdmurray: I asked in the bugreport now
<bdmurray> mvo: okay, looking around there are quite a few 'update-alternatives.*invalid status' bug reports
<bdmurray> mvo: should those be treated the same way or should dmesg be examined for memory / hardware issues?
<Sweetshark> where does the change that our ld is using --as-needed by default coming from? ubuntu? or debian?
<mvo> bdmurray: I don't now :/ I am not sure if that is the result of a programming error or fs corruption
<janimo> Sweetshark, I think it is an ubuntu change, at least that was the case in natty
<didrocks> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<Sweetshark> janimo: k, thx. good to know since it break the build here.
<bdmurray> mvo: okay, I'll look into some manually and see what I find
<mvo> bdmurray: thanks! keep me updated please
<janimo> Sweetshark, AIUI it is enabled so we fix packages preemptively, as this becomes default behaviour when a switch to the gold linker happens
<janimo> although I may be confusing it with the --add-needed option (which got renamed to avoid such confusions)
 * Sweetshark is scared of the thought to link LibreOffice with gold.
<janimo> siretart, is there a particular schedule for uploading libav? There's a crasher fixed upstream which I found useful but it may not be necessarily urgent for Ubuntu (lightspark crashes with it)
<janimo> siretart, I built a package locally to confirm it is the right fix http://comments.gmane.org/gmane.comp.video.ffmpeg.devel/133360
<bdmurray> slangasek: cjwatson commented on bug 500175 regarding passthrough and debconf
<ubottu> Launchpad bug 500175 in software-center (Ubuntu Lucid) "Canceling an installation in Software Center crashes debconf with "Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66,"" [Undecided,Confirmed] https://launchpad.net/bugs/500175
<cjwatson> it's not clear to me that the tzdata case is the same
<cjwatson> I'm having a go at reproducing that now
<bdmurray> I've also seen 'user did not accept license' in the msttcorefonts ones regarding passthrough.pm
<cjwatson> that sounds like a symptom of cancellation
<cjwatson> I think at least some of these are going to end up being package installation failures that should be suppressed from crash reporting
<cjwatson> I don't see any other way round some of them
<siretart> janimo: well, I'd prefer to have it fixed in libav upstream first, and then I'm happy to upload it to debian/ubuntu, but otherwise, I don't have a 'particular schedule' for uploads
<cjwatson> bdmurray: can't reproduce by just updating tzdata on top of 10.04 :-/
<cjwatson> (well, a 10.04 image from July 2010 sometime)
<cjwatson> I guess I can try 11.04 since there are reports from that ...
<cjwatson> bdmurray: what would be a good way to stop reports of this kind of thing when it's just that the user hit cancel?  dump a known piece of text into the terminal log or something?
<bdmurray> cjwatson: I think so but perhaps mvo would have a different idea
<mvo> sounds good to me
<cjwatson> if I could reproduce the damn thing it would really help, though.
<bdmurray> mvo: and then we'd put that text in apt or apport?
<cjwatson> it would have to be a message emitted by the debconf passthrough frontend
<cjwatson> so you'd just have something pattern-matching on error messages, which is ugh but anyway
<bdmurray> cjwatson: right and then added to apt or apport to not generate a crash
<mvo> I would prefer apport (but need to rush to dinner now)
<bdmurray> slangasek: i was rebooting and during the shutdown process noticed that 'Checking for running unattended-upgrades' appeared on the same line as something else.  Does that mean /etc/init.d/unattended-upgrades is missing a newline? and is there some log file I check for shutdown messages?
<barry> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: barry
 * cjwatson wonders why a bug's reporter is called .owner in the LP API
<infinity> cjwatson: Because all LP objects have owners?
<cjwatson> I guess.  It just seems an odd way to put it
<infinity> Thankfully, that's the only odd thing in the entirety of Launchpad.
<Pici> 4hah
<cjwatson> miaow
<highvoltage> you're not supposed to say that out loud are you? :)
<infinity> What?  That was my "completely sincere" voice.
<bdmurray> barry: could pilot https://code.launchpad.net/~brian-murray/update-manager/apport-gconf/+merge/67228 ?
<bdmurray> er could you
<cjwatson> bdmurray: gah, even fairly brutal methods are failing to reproduce the tzdata case
<cjwatson> escalating to a bigger chainsaw
<barry> bdmurray: yep, i'm looking at this one right now and will look at yours afterward: http://tinyurl.com/622frtw
<bdmurray> barry: thanks the debdiff in bug 797894 goes hand in hand with that merge proposal too
<ubottu> Launchpad bug 797894 in update-manager (Ubuntu Natty) "update-manager bug reports would benefit from an apport-hook" [Medium,In progress] https://launchpad.net/bugs/797894
<barry> bdmurray: cool
<cjwatson> bdmurray: aha!  I can reproduce it if I upgrade both libpam0g and tzdata in update-manager
<maco> any of you seen this odd behaviour on natty:  logging in only works at a DM, not at a TTY?
<bdmurray> cjwatson: great!
<maco> huh. well that just got more interesting. bugs are weird. works on TTY3, fails every time on TTY2
<infinity> maco: Maybe tty2 thinks you have a key stuck or something?  (reset tty2, or switch to tty2 and randomly hammer modifier keys a bit before trying to log in?)
<maco> ooh and rww spotted someone in #ubuntu having *all* TTY logins fail
<ahasenack> hi, quick package versioning question. I have a package in oneiric I want to build on lucid: python-psutil 0.2.1-1
<ahasenack> what should the version/release look like in lucid?
<ahasenack> not only build, but backport and maintain in a ppa of mine
<barry> bdmurray: is the patch in https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/797894 already uploaded to natty-proposed?
<ubottu> Ubuntu bug 797894 in update-manager (Ubuntu Natty) "update-manager bug reports would benefit from an apport-hook" [Medium,In progress]
<bdmurray> barry: no, it needs uploading
<barry> bdmurray: k, looking at that now
<bdmurray> barry: thanks!
<serge_> all right so if a debian package version jumped to 0.7.4.2-0.3 (used to be 0.7.3-1 format), do we make it 0.7.4.2-0.3-0ubuntu1?
<cjwatson> serge_: no, 0.7.4.2-0.3ubuntu1
<cjwatson> serge_: 'dch -i' on an Ubuntu system should generally do the right thing to add a suitably incremented entry to the top of the changelog
<barry> bdmurray: fwiw, the debdiff in #3 does not apply cleanly to the natty branch.  in fact: patch: **** malformed patch at line 36: diff -Nru update-manager-0.150.2/debian/update-manager-core.install update-manager-0.150.3/debian/update-manager-core.install
<barry>  
<serge_> cjwatson: thanks
<barry> bdmurray: any chance you can regenerate the patch?  otherwise i'll manually apply it
<bdmurray> barry: sure
<slangasek> bdmurray, cjwatson: 500175> so does cancel not get passed through the passthrough?
<slangasek> or else, why is the log so messy when someone presses cancel?
<slangasek> bdmurray: I don't think we have a shutdown log, no; but upstart jobs can run in parallel to init scripts even on shutdown, maybe that's what's happening here?
<pitti> james_w: ok, thanks; I'll update it the oldfashioned way then :)
<pitti> serge_: no need to explicitly kick them; we'll just review them
<bdmurray> barry: okay new one added
<barry> bdmurray: thanks, that applies cleanly
<barry> well, except for the changelog, but i'll fix that
<bdmurray> what is wrong with the changelog?
<barry> bdmurray: the debian/changelog hunk FAILED
<barry> bdmurray: hmm, i grabbed `bzr ubuntu:natty/update-manager`.  maybe i should have grabbed something else though
<bdmurray> barry: maybe natty-updates?
<barry> bdmurray: let's try that!
<barry> bdmurray: yep, much better
<cjwatson> slangasek: passthrough is a bit slow to notice cancel, and witters a bit about undef values until it eventually gets killed by SIGPIPE.  Fixing that would be a good thing.  However, the ultimate effect would be the same - the user's cancelled, it needs to exit non-zereo
<cjwatson> *non-zero
<cjwatson> so the nonsense spewed on stderr is just noise rather than substance IMO
<cjwatson> bug 442941 is much more interesting
<ubottu> Launchpad bug 442941 in debconf (Ubuntu) "debconf failed to upgrade from 1.5.27ubuntu1 to 1.5.27ubuntu2: exit status 128 - Use of uninitialized value $reply in scalar chomp at /usr/share/perl5/Debconf/FrontEnd/Passthrough.pm line 66" [High,Confirmed] https://launchpad.net/bugs/442941
<cjwatson> and I fear that the proximate cause is actually an installer bug
<cjwatson> after a fresh installation, /var/cache/debconf/config.dat is mode 0600
<cjwatson> this means that the UI side of aptdaemon's debconf proxy can't start
<cjwatson> I don't know if that's the whole problem
<ahasenack> hi guys, quick packaging question. I want to build https://launchpad.net/ubuntu/+source/python-psutil/0.2.1-1 in a lucid ppa, what should its version become? 0.2.1-1ubuntu0.10.04?
<micahg> ahasenack: try backportpackage from ubuntu-dev-tools
<broder> micahg: beat me to it :)
<micahg> :)
<ahasenack> micahg: thanks, I will
<ahasenack> micahg: hmm, I don't see it in that package
<ahasenack> micahg: mine is ubuntu-dev-tools                   0.99
<ahasenack> I have lucid-backports
<broder> ahasenack: yeah, that's likely too old...let me see if the daily PPA has lucid builds...
<broder> looks like it doesn't
<micahg> ahasenack: yeah, so basically VERSION~RELEASE~ppa1 is what the script uses
<broder> tumbleweed, bdrung_: ^
<ahasenack> it also has other problems, it fails to import lazr.uri
<ahasenack>     from lazr.uri import URI
<ahasenack> ImportError: No module named uri
<ahasenack> but I have it
<ahasenack> ii  python-lazr.uri                    1.0.2-1
<ahasenack> or I think I do :)
<ahasenack> that was ubuntu-build, btw
<broder> micahg: it's {VERSION}~{RELEASE}1~ppa1
<broder> because VERSION~RELEASE1 is what we use for automated backports
<micahg> broder: oh, hmm, right, was confusing with what I did before
<ahasenack> so, python-psutil-0.2.1-1 becomes python-psutil-0.2.1-1~10.04.1~ppa1?
<broder> ahasenack: no, we would do 0.2.1-1~lucid1~ppa1
<ahasenack> ok, s/10.04/lucid/
<ahasenack> and a dot
<ahasenack> broder: and if I do local changes, I bump to ppa2 and so on?
<broder> ahasenack: you only need to bump the number each time you upload to the PPA
<ahasenack> broder: ok, but it's that last number, right? After the "ppa" suffix
<broder> yeah
<ahasenack> broder: cool, thanks a lot
<broder> the idea is that you're doing a "prerelease" version of a real backport, so you always want your version number to be smaller than one the eventual real backports' version number would be
<ahasenack> broder: the real backport would be 0.2.1-1~lucid1?
<broder> right
<ahasenack> ok, I might have a shot to get a hang of this someday :)
<ahasenack> thanks again
<slangasek> cjwatson: ah, heh; well, great to see that we actually have a foothold on these bugs now :)
<ahasenack> broder: I'm getting this error, I suppose this is a good case to actually use the suggested -b?
<ahasenack> New version specified (0.2.1-1~lucid1~ppa1) is less than
<ahasenack> the current version number (0.2.1-1)!  Use -b to force
<ahasenack> this with dch -v 0.2.1-1~lucid1~ppa1 "Backported to lucid."
<broder> yeah, -b is fine
<ahasenack> ok
<broder> making the version number smaller is what we're going for, because it means that when you upgrade, the original will have a "higher" version than the backport, so you'll be upgraded back to the original
<ahasenack> right
<cjwatson> slangasek: I have no idea how to fix this post-release though
<slangasek> a chmod from a maintainer script won't do the job?
<cjwatson> it might be worth cramming into 10.04.3 as a late change to try to stem the flow of bugs there; but applying any upgrade to fix this might very well be hit by the same bug
<cjwatson> I don't see how to reliably fix it before users encounter it
<slangasek> right
<cjwatson> and it only affects the first upgrade that uses debconf, AFAICS
<cjwatson> once debconf rewrites the database, it sets the correct mode
<slangasek> ah
<cjwatson> which is why most of us never noticed
<slangasek> if we suppressed the apport reports, would the *users* notice?  Beyond having to rerun the upgrade?
<slangasek> well, I guess they'd still get the prompt about a crash, and told afterwards that they don't need to report the bug
<cjwatson> right, it would be an improvement but not perfect
<cjwatson> hard to make the bug pattern very specific, too
 * slangasek nods
<cjwatson> we'd have to ignore anything with this debconf warning pattern in it, and I can't claim confidence that this is the cause of all of them
<cjwatson> in fact I'm fairly sure it's not
<bdrung_> broder: if you get u-d-t building on lucid, let me know what dependencies needs to be updated
<cjwatson> perhaps it's a price worth paying, I'm not sure
<broder> bdrung_: oh, it doesn't build? that's too bad
<bdrung_> broder: probably (i didn't test it)
<bdrung_> broder: we probably need to backport a big bunch of packages
<cjwatson> slangasek,bdmurray: we could bugpattern it just in the tzdata case, I suppose, and maybe libpam*; the packages that this is most likely to be reported against will be high-priority packages that use debconf and that have been updated since release
 * cjwatson does a quick scour of "Binary package hint:" lines
<cjwatson> or "Package:" I guess
<slangasek> AIUI the 'Binary package hint' is considered deprecated and rarely accurate, so probably Package: yeah
<cjwatson> the accuracy bit isn't a problem here, but yeah
<slangasek> right, but I think the idea is to make that field go away entirely :)
<cjwatson> indeed
<cjwatson> http://paste.ubuntu.com/639704/ packages against which dups of 442941 have been reported
<cjwatson> so tzdata accounts for 66%
 * slangasek nods
<serge_> jbernard: hey
<cjwatson> I guess I'll have to check the others to make sure that they really are the same thing
<cjwatson> should be recognisable by the terminal log being fairly short
<serge_> jbernard: do you have any objection to my debdiff for bug 807199 ?
<ubottu> Launchpad bug 807199 in libcgroup (Ubuntu) "mount freezer cgroup by default" [Medium,In progress] https://launchpad.net/bugs/807199
<slangasek> I can speak for samba (samba, smbclient, samba-common, winbind) and libmyodbc to say that their debconf usage hasn't changed in a long time, so any failures there are unlikely to be caused by debconf misuse on the package side; dunno if that means it's the same bug on the debconf side though
 * cjwatson causes lp-shell to eat his firefox so he can find out
<cjwatson>  2794 cjwatson  20   0 2088m 1.6g  18m R  101 52.8  49:46.01 firefox-bin
<cjwatson> I suspect that the other common factor (other than high-priority packages) is stuff-users-install-straight-away
<cjwatson> and IIRC there's some bit of desktop furniture that offers to install some bit of samba for you, presumably using aptdaemon
<cjwatson> similarly for gstreamer0.10-fluendo-plugins-mp3-partner
<micahg> cjwatson: upstream's (Mozilla) working on that memory usage, I think by 8 you should see a significant improvement
<cjwatson> micahg: while it's certainly not fun, I just opened 100 tabs all at once from a script, so I suspect it's allowed to be a bit upset
<infinity> micahg: But it's already quarter past 9!
<micahg> heh
<micahg>  2789 micah     20   0 4440m 2.9g  22m S    6 36.6 465:05.60 firefox-bin, I run like this all the time :-/
<bdmurray> cjwatson: could we bugpattern a specific version of the package such that only lucid/maverick/natty were blocked?
<cjwatson> bdmurray: given that this is the first upgrade after installation, it would be simpler to bugpattern InstallationMedia or some such
<cjwatson> I mean, include that in the pattern
<cjwatson> the installer bug goes way back, I think it's very likely always been there
<cjwatson> since ubiquity started in dapper anyway
<cjwatson> we just never noticed it before package management frontends started using aptdaemon and having a user/root split
<Daviey> Any of the DMB around?
<stgraber> Daviey: what's up?
<Daviey> stgraber: can ~ubuntu-server-dev be added to ~ubuntu-dev please?
<Daviey> stgraber: *-server-dev is the package set team, and it's blocking the indirect ~ubuntu-dev and therefore ~ubuntumember foo.
<stgraber> Daviey: done
<Daviey> stgraber: rocking, thanks
<cjwatson> also voting rights
<stgraber> I also added edubuntu-dev as both kubuntu-dev and mythbuntu-dev were in it
<Daviey> stgraber: rocking.
<Laney> yeah, think you got everything
<Laney> what happened to the bzr package set we approved?
<stgraber> I think it needs implementation by TB, though I'm not sure if someone sent them an e-mail yet
<Laney> :S
<tumbleweed> broder: you wanting a u-d-t backport to lucid? the prerequise (for a no change backport) would be the dh_python2 backport
<broder> ah, ok
<Laney> stgraber: er, i can't actually find where we heard it. any clue?
<Laney> stgraber: ah nm, found it
<Laney> i wish we were better at minutes
<stgraber> Laney: I guess we should create the team, make it a member of ubuntu-dev, then poke the TB to get the ACLs updated
<Laney> right, doing that
<Laney> it was your adding of teams that made me remember (when I was thinking if we'd missed any)
<stgraber> then we'll be able to move the current PPU people we have for bzr to that team and maybe (not really needed) poke the TB again to drop the PPU upload rights (as they'll have them coming from the team)
<Laney> I'll just ask the TB to do all of that
<bdmurray> barry: still piloting? ;-)
<barry> bdmurray: yep.  need another one?
<bdmurray> https://code.launchpad.net/~brian-murray/apport/ubiquity-hook/+merge/67254
<bdmurray> I've tested it an awful lot
<bdmurray> probably too much
<barry> :)
<bryceh> slangasek, hi, we have xdiagnose as a Recommends of x11-common, however Sarvatt found it didn't get pulled in and installed in a fresh alpha2 install.  Any ideas where we went wrong?
<barry> bdmurray: i have a couple of comments that would clean the code up a bit.  do you want them here or in the mp?
<bryceh> slangasek, ubuntu-desktop depends on xserver-xorg, should xdiagnose be a recommends of that instead?  or should it be a Depends rather than Recommends?
<RainCT> pedro_: Hey. You'll probably see some more of those bug reports. Zeitgeist 0.8.1-1ubuntu1 is badly broken
<bdmurray> barry: here is fine
<pedro_> RainCT, yup already have one assigned to didrocks
<pedro_> he's doing the packaging there
<barry> bdmurray: line 28.  it's always preferred to compare against None with identity instead of equality, so use "if response is None" instead
<Sarvatt> bryceh: actually it depends on xorg not xserver-xorg, sorry
<bdmurray> barry: right that was dumb
<barry> bdmurray: line 30. it's generally not pythonic to test for equality against True, so just use "if response:" instead
<bryceh> Sarvatt, ah right
<pedro_> RainCT, bug 807203 , in case you want to subscribe
<ubottu> Launchpad bug 807203 in zeitgeist (Ubuntu) "ubuntuone-syncdaemon crashed with AttributeError in __getattr__(): 'Symbol' object has no attribute 'PAGINATED_TEXT_DOCUMENT'" [High,Confirmed] https://launchpad.net/bugs/807203
<barry> bdmurray: the only other comment is about the start of the message on line 22.  i find the first sentence a little hard to follow.  can you rephrase/simplify that first sentence?
<RainCT> pedro_: Yup, got the bug mail (and also sent didrocks a mail some hours ago). Just letting you know :)
<pedro_> ;-)
<bdmurray> barry: okay
<barry> bdmurray: push an update and ping me and i'll be happy to upload it
<bdmurray> barry: "The system log from your installation contains an error.  The specific error commonly occurs when there is an issue with the media from which you were installing."
<bdmurray> does that sound better?
<barry> bdmurray: beautiful :)
<cjwatson> slangasek,bdmurray: I think what I'm inclined to do here is to have a bugpattern that's as accurate as I can make it, but have it redirect to a wiki page that (a) explains the debconf database permissions problem and a workaround (b) explains the issue with cancellation (c) suggests e-mailing me if they have some different problem not covered
<cjwatson> does that seem reasonable?
<cjwatson> because I'm not even sure I can separate (a) and (b) in terminal logs manually, let alone automatically
<Daviey> bdmurray: Where is the bugpattern work being documented?
<cjwatson> bdmurray: do you think you've already caught all the duplicates with grab-attachments or whatever?
<bdmurray> cjwatson: yes that sounds reasonable to me, however there may be some complications implementing it.
<bdmurray> cjwatson: no, I stopped looking until we had the issue sorted more
<Daviey> bdmurray: I assume Ursinha is following this closely?
<cjwatson> bdmurray: what would the implementation problems be?
<Ursinha> me
<bdmurray> Daviey: Ursinha and I have talked about bug patterns
<bryceh> cjwatson, heya, we have a MIR approved for xdiagnose, and have a Recommends on it from x11-common, but it appears to still be in universe; do you happen to know if there is something more we need to do to get it in?
<Daviey> Ursinha: Guten Tag, i thought you might be /away by now.
<Ursinha> Daviey: not yet :)
<cjwatson> bryceh: I can do it now given an approved MIR
<bdmurray> cjwatson: well if you want the pattern to work on releases before natty there are some issues but I can sort that out.
<cjwatson> haven't gone through that queue for a bit
 * Ursinha reads backlog
<cjwatson> bryceh: where's the MIR?
<bryceh> cjwatson, that would be great, thanks - https://bugs.launchpad.net/ubuntu/+source/xdiagnose/+bug/784885
<ubottu> Ubuntu bug 784885 in xdiagnose (Ubuntu) "[MIR] Include xdiagnose in ubuntu" [High,Fix released]
<bdmurray> barry: the merge proposal has been updated
<cjwatson> I don't see it on https://bugs.launchpad.net/~ubuntu-mir/+subscribedbugs
<barry> bdmurray: looks great, i'll sponsor it
<cjwatson> bryceh: oh, you marked it Fix Released, that removed it from our queue
<cjwatson> the workflow is that MIR bugs go to Fix Committed once they're approved
<bryceh> cjwatson, guess I assumed since pitti uploaded some changes to it that he'd done the main promotion :-/
<bdmurray> cjwatson: so once a wiki page was made I'd go looking for more duplicates and include the wiki page in the coment.
<cjwatson> bryceh: different hats there
<bryceh> *sigh*
<bryceh> cjwatson, ok thanks for clarifying
<cjwatson> promoted now, anyway
<bryceh> Sarvatt, ok should be fixed now.  Once again a case of me being stupid, sorry.
<barry> bdmurray: how many branches of apport are there?!  lp:apport, ubuntu:apport lp:~ubuntu-core-dev/ubuntu/oneiric/apport/ubuntu
<micahg> that's actually a normal number of branches :)
<barry> ah, well clearly the last two are not in sync, given bug 494481
<ubottu> Launchpad bug 494481 in Ubuntu Distributed Development "Too easy for people to not use merge-upstream" [High,Triaged] https://launchpad.net/bugs/494481
<barry> micahg: but it hurts ;)
<micahg> barry: well, in this case your minimum is 2 since upstream is hosted in LP :)
<bdmurray> barry: well I know lp:apport is the upstream one and that doesn't contain the package hooks as those are ubuntu specific
<barry> i could handle two :)
<barry> no worries though, i'm just complainin' ;)
<ScottK> micahg: Get off barry's lawn.
<barry> ScottK: exactly :-D
 * micahg goes to find another lawn...
<barry> and with that...
<barry> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
 * Laney applauds barry
<Laney> jono: can you CC the DMB in on your recent tech-board discussion?
 * barry bows and collides with the keyboard
<jono> Laney, I want to get the TB's perspective first before moving forward to see if my suggestions even fly
<jono> as this is a technical policy decision
<jono> and then I will move it forward to the DMB
<ScottK> What's the topic?
<Laney> I'd have thought you wanted DMB input as you are proposing some quite serious changes to the way we work.
<Daviey> ScottK: https://lists.ubuntu.com/archives/technical-board/2011-July/000957.html
<jono> Laney, I am totally interested in input
<ScottK> Daviey: Thanks.
<jono> I just wanted to get the TB input first
<Laney> The effect that will have is that the path is rather firmly aligned when the discussion comes down to us
<ScottK> That is a bit of a change.
<jono> I am certainly keen that the DMB offers plenty of input on this
<ScottK> jono: I'm interested in specific examples (in private if you prefer) of people not getting through the current process as they should have.  My view has been that if anything the process is too biased towards acceptance.
<jono> ScottK, interesting
<jono> ScottK, would be happy to hop on a call
<jono> maybe tomorrow if you are around?
<ScottK> jono: Tomorrow is better for me.  I'm about EOD here.
<Laney> I thought that too.
<jono> thanks ScottK
<Laney> I wonder why people don't come to the DMB with their concerns
<jono> Laney,  thought it was too accepting?
<ScottK> jono: Give me a ping when you're awake and moving tomorrow (assuming you're in your home TZ).
<jono> ScottK, will do, thanks, pal
<Laney> jono: yes, or at least that we treat deferrals much more seriously
<jono> right
<jono> I think there are just some areas in which we can ease the process
<jono> as I outline in my mail
<jono> I believe it should be more about reputation than anything, and we should bring more value into the testimonials
<ScottK> Laney: I haven't said anything since I think that between the TB delegation and the election by ubuntu-dev the DMB has a lot of legitimacy to figure out how to handle approving members.  I'd have to find it seriously broken before I complained.  I don't think it is (seriously broken).
<ScottK> jono: It's been my experience that people I give solid testimonials to get in easily and the one time I gave a "Dear God, please no" testimonial they didn't.
<Laney> ScottK: I wasn't referring to your concerns, but these people who think that 'the process is too difficult to get through'
<ScottK> So I think they get a lot of weight already, but we can discuss tomorrow.
<jono> ScottK, great, and that is what I am keen to empower and set expectations firmly about - the value of a +1/-1 from a core dev
 * ajmitch wouldn't necessarily say that all core devs are the same
<ScottK> Some are definitely more equal than others.
<ScottK> See you all later.
<ajmitch> I trust my opinion on +1/-1 far less than I'd trust others
 * cjwatson had an extensive argument on this subject on the DMB list just before retiring.  My sense that I wasn't getting anywhere was part of why I retired.
<cjwatson> (though far from all; I just didn't have the time)
<cjwatson> of course that was a while back now.
<jml> barry: ping
<Laney> besides one which is currently unresolved, I'm not sure I can remember us voting down any applications since I joined anyway
<Daviey> it's a shame the list isn't open.
<Laney> however I'm not at all sure that the DMB commands the legitimacy that it should
<Daviey> Laney: I suspect that are quite a few people that are not applying through fear/embarrasement of applying for upload privs TBH.
<maco> Laney: "serious changes to the way we work" is an understatement, IMO. "making the DMB redundant" is a better description
<Daviey> fear of NACK, that is.
<Laney> maco: We get to press the 'Add member' button :-)
<Laney> Daviey: Right, applications are self selecting.
<nigelb> Laney: :)
<maco> Laney: but if all it takes is "well 2 people think its a good idea" then hey, just make there be a "make dev" button on everybody's LP page and once two core devs have +1'd by pressing it, there ya go automagic
<Daviey> Laney: surivial of the most confident :)
<nigelb> maybe it should be +2 with no objections to make it more fair
<ajmitch> Daviey: it should work like that, to some degree
<Laney> I didn't apply for MOTU until james_w told me to for the 15th time
<jono> maco, my suggestions do not make the DMB redundant
<jono> they just optimize the process around reputation
<maco> Laney: it is no longer unresolved, i believe. you and persia both said +0. based on what persia says is historical practice, the application is "not yet"'d
<jono> we still need a board to assess applications
<Laney> It assumes we undervalue testimonials, which I do not believe to be the case
<maco> Laney++
<maco> we just don't take testimonials as the end-all be-all
<cjwatson> jono: I think it may be worth assessing your past experiences in light of the facts around the current iteration of the DMB
<maco> i probably couldve gotten some nice testimonials from a couple of people 6mo before i applied for motu, but i wouldve only had 5 uploads
<cjwatson> that probably goes for me too
<cjwatson> jono: let's make sure it's actually a significant problem right now before changing anything
<Laney> upload count> I don't really consider that per se
<Laney> all activity goes into the mix
<nigelb> cjwatson: What was the conclusion of the discussion on the DMB list (if it is possible to be made public that is)?
<cjwatson> nigelb: inconclusive
<nigelb> ah
<cjwatson> but, as I say, that was the last board
<jono> cjwatson, totally agreed
<maco> actually, whatd be REALLY handy is if LP could tell us all uploads on which their name was *anywhere* in the changelog, since often with UDD and all, you get  [name]  stuff [name] stuff [name] stuff       name <email> $timestamp
<Laney> debian has 'ddportfolio'
<cjwatson> basically my thesis was that the DMB has two functions, gatekeeper (keep out the bad eggs) and nurturer (encourage new developers), and that at the point I retired we had swayed too far towards the former
<jono> Laney, and my suggestions may well be redundant
<cjwatson> I'm entirely prepared to believe that that's changed since then
<Laney> jono: we can't really judge without specific examples
<cjwatson> though I think the dual function is always worth keeping in mind
<nigelb> maco: Isn't that the responsibility of the candidate to say, "Hey, I've worked on foo, bar, and baz"
<cjwatson> nigelb: it'd be less tedious for everyone if we could just look up a full list
<jono> sorry, I have to head to a meeting, maybe this could be a good point of discussion at the next TB meeting? invite the DMB along to participate too?
<Daviey> maco: Funny you say that, i have a mbox parsing script for searching for names anywhere in the changelog.  Only takes 1.5 hours to run :)
<cjwatson> er, "we" being a board I'm not on, but YSWIM
<maco> nigelb: the template asks for a couple you're proud of. having a full list would by handy though
<maco> Daviey: i suspect LP's db is faster than text parsing....
<nigelb> cjwatson: ah, that makes sense
<cjwatson> jono: the proposal is to change DMB behaviour; I think it should be discussed primarily in the DMB, with the TB as guests
<nigelb> Daviey: well, if you could run it everyday....
<cjwatson> jono: but I agree, we definitely need concrete current examples
<jono> cjwatson, I suggested the TB as I see this as a wider policy that the DMB implements
<jono> but happy either way
<cjwatson> jono: that's a bit artificial though
<jono> DMB may well make better sense
<Laney> the TB has delegated deveoper membership to the DMB
<Daviey> maco: I would hope so!  I had hoped that Laney's UDD work would deprecate it.
<maco> LP shows who the uploader and sponsor were. if it showed "other contributors to the upload" and then had your /+relatedsoftware hook into that....yay
<Laney> Daviey: it doesn't include changelogs
<cjwatson> in practice I've not heard of any debate about any other team doing developer approvals (kubuntu council or whatever)
<Laney> but it does mean that I have a large cache of changes mboxes
<Daviey> Laney: arse.
<Laney> infact, the sysadmins kindly made them rsyncable for me
<Laney> lists.ubuntu.com::changes-mboxes
<Laney> so it's easy for anyone to get :-)
<micahg> maco: re person in changelog> I actually discussed something like that with barry about 5 months ago as part of UDD
<jono> tbh, I don't mind where the meeting is, so long as the DMB and TB both have input
<nigelb> lol
<nigelb> technically, we could parse the changes mbox, but that's going to be time consuming.
<nigelb> unless its a diff, hm. that should be interesting
<nigelb> Daviey: Could I have your mbox parsing script?
<Daviey> nigelb: no.
<Daviey> nigelb: it's an embarrasement.
<Laney> it's not that time consuming
<nigelb> Daviey: Don't worry, I won't show it to anyone. I don't want to start from scratch
<micahg> maco: one of the problems with parsing the changelog is without an e-mail address it's indeterminate as to whom the person is
<maco> micahg: thats true
<Daviey> nigelb: -> PM.
<Daviey> micahg: it's a reasonable indicator.
<Laney> with applicants, I suspect that a good time to apply is when existing developers get bored of sponsoring your changes and make you do it
<micahg> Daviey: it can't be automated is my point
<Laney> that's probably the way it works for a lot of people
<Daviey> micahg: agreed
<nigelb> Sure but a list of [Name] type entries is nice to have. Its posible to ask candidates, do you do that change?
<maco> Laney: a month before my motu app, ogra was going "what? you need a sponsor? but thats a universe package!"
<Laney> hah
<ajmitch> maco: that can happen a bit
<Daviey> is revu dead these days?
<Laney> mostly
<maco> pretty much
<ajmitch> it's just resting
<Laney> ajmitch locked it in the cellar
<cjwatson> it's pining for the fjords
<maco> i changed the wiki page to point out that the WNPP route is better because it benefits more users and involves a designated maintainer instead of just piling on to motu-work
<Laney> yay
<Laney> did you also link to wiki.d.o/Teams? :-)
<maco> i linked to the WNPP process stuff for sure. not sure on particulars though...was a while ago
<maco> i remember saying to persia that i couldnt apply for motu since i hadnt packaged enough from scratch, and he was like "that's fine! motu doesn't really need more work!"
<maco> oh hm. i should do whatever htat next step is in my DM application...
<Laney> if it's not leaking too much, the gist of cjwatson's email is that we shouldn't focus on debian/changelog too much but consider the whole
<Laney> is that a fair summary?
<cjwatson> pretty much yeah, plus my comments above on the two functions of the DMB
<Laney> so to refer to the conversation of a few minutes ago, we shouldn't worry too much about mining archives of upload history
<micahg> heh, I'm still working on my first package from scratch (through Debian) and even that I "borrowed" a couple files from the UBuntu package
<Laney> I just uploaded a NEW package to debian that started life in a PPA :-)
<Laney> http://packages.debian.org/changelogs/pool/main/s/sparkleshare/current/changelog
<maco> Laney: in most cases i dont think we need the extra upload history, but for example a recent person had only 1 visible upload on their +relatedsoftware page at the time of application, so in that case being able to see what they worked-on-but-didnt-officially-upload wouldve been handy to sway things toward a more positive space
<ajmitch> oh it'd uploaded now?
<cjwatson> for a lot of people upload history will be pretty significant, I just think y'all probably oughtn't be closed-minded about it
<Laney> ajmitch: yeah, for ages!
<ajmitch> Laney: well, uploaded & through NEW
 * ajmitch should try it out
<Laney> got NEWed rapidly, as happens in Debian these days
<Laney> initial setup is rough
<maco> cjwatson: given i had like...a dozen...uploads when i joined motu, i dont really think i can be *too* anal about # of uploads, but ...plural is nice
<cjwatson> and there ought to be some sponsored uploads; I think what I was trying to push back on was that people ought to have dozens and dozens of sponsored uploads over a seriously extended period
<ajmitch> Laney: synced to oneiric yet?
<cjwatson> *was the idea that
<Laney> maco: oh yeah, that's why applicants are encouraged to point us to more information that can help review
<Laney> ajmitch: in NEW
<cjwatson> at some level it was really just a difference of opinion about degree
<Laney> (was a merge to add appindicator stuff)
<maco> (im still a bit surprised yall approved me with a dozen uploads though)
<ajmitch> maco: I'm sure some of us got in with less
<maco> cjwatson: i do recall the "dozens and dozens" type talk before i applied.  sounded like some people wanted 50-ish uploads before you even think about applying, which...
<ajmitch> that seems excessive
<maco> to establish "i'm not stupid and will ask for help when i reach my boundaries" doesn't take NEARLY that many
 * micahg was told 30 once upon a time
<ajmitch> I'm sure that the DMB would take into account what sort of uploads they were
<maco> if you're doing merges and ftbfs and actually getting them right pretty plz take upload rights :P
<ajmitch> 30 syncs is quite different than 30 uploads of a complex set of packages
<Laney> don't forget the testimonials that started this discussion off
<ajmitch> right
<maco> balance
<serge_> jbernard: o/
<ajmitch> maco: and common sense
<lifeless> as a data point, I'm nervous about applying for core-dev
<maco> lifeless: you're not one?
<lifeless> nope
<ajmitch> heh
<nigelb> O_O
<lifeless> I have stuff in main I can upload to via Debian :)
<maco> huh.
<ajmitch> why are you nervous about it?
<infinity> lifeless: We're all nervous about you in core-dev.
<lifeless> ajmitch: I don't *routinely* change stuff that is in main
<lifeless> infinity: thanks :P
<infinity> lifeless: But, more seriously, people who are cautious about responsibility are the people who should be applying. :P
<lifeless> ajmitch: and I have the impression there is a high assessment bar around core-dev
<infinity> lifeless: Cause you won't break something you don't understand.
<maco> infinity++
 * ajmitch goes off to upload glibc for fun...
<infinity> ajmitch: *glare*
<Laney> lifeless: can we swap you for ajmitch please?
<infinity> ajmitch: You shouldn't have given me warning, I can head that off. :P
<ajmitch> infinity: yeah I'm not that stupid :P
<lifeless> Laney: hahaha :)
<lifeless> Laney: sure, its only ~600km drive
<ajmitch> Laney: <3 to you too
<nigelb> haha
 * Laney snuggles ajmitch really
<infinity> ...
<infinity> Should we be seeing this?
<Laney> :$
<Laney> lifeless: but really, if you can get a couple of testimonials then I see no problem
<Laney> I usually ask about working with Debian, but if you're a DD already â¦
<infinity> I suspect he just doesn't want to apply because then Daniel will rope him into patch piloting.
<Daviey> lifeless: Feel free to help out with the squid issues, then you'll get +100 testimonal from the server team :)
<micahg> infinity: he's already MOTU
<lifeless> I should do more piloting
<lifeless> I was doing revu a lot at one point, but dropped the ball and didn't get back onto it
<lifeless> Daviey: ask SpamapS .... I already do :P
<infinity> micahg: Oh, when I do my PP rotations, I can ignore people with patches to main?  Snazzy. ;)
<infinity> Daviey: I'm sure he helps with squid a lot, you just don't realise it because he refers to it as "quiche".
<Daviey> real developers don't eat quiche.
<lifeless> bah, fish schticks to you al
<micahg> infinity: you're a core-dev already, his way out is he's with Launchpad :)
<lifeless> l
<maco> Daviey: zuchinni quiche is delicoius
<maco> *delicious
<micahg> infinity: actually, upload rights isn't a requirement for piloting
<Daviey> pah.
<lifeless> maco: I think you just broke my tastebuds
<Laney> Canonical DDs should be forced to troll in -devel to bring Debian down from the inside
<Laney> debian-devle that is :-)
<micahg> or maybe it was only minimal upload rights...(PPU for one package at least)
<nigelb> like the opposite of patch piloting?
<lifeless> patch creation?
<infinity> micahg: Ahh, well.  I've not really been initiated into the whole process yet, I just have an event on my calendar, and a Holbach threatening me with doom if I attempt to back out. ;)
<Laney> cloak 'n dagger
<nigelb> infinity: On a positive note, its Daniel and not Jono :P
<micahg> heh, which day is that, I have to make sure to flood the queue with stuff to sponsor for main :P
<Daviey> micahg: yeah, Canonical engineering team who are in ~ubuntu-dev, are expected to do 4 hours per month.
<micahg> Daviey: yep, so the second one :)
<maco> nigelb: because daniel's version of doom involves stuffed teddy bears and jono's involves listening to Severed Fifth?
<nigelb> Exactly!
 * infinity snickers.
<lifeless> hmm, does gwibber have g+ integration in oneiric?
<infinity> lifeless: Impatient much?
<nigelb> hold on, g+ hasn't exposed api yet
<lifeless> infinity: curious is all
<lifeless> nigelb: its massive client side js, that pretty mnuch defines it having an API :)
<Daviey> nigelb: python-mechanize was invented for this reason! :)
<nigelb> lifeless: I'll rephase. API docs!
<nigelb> *rephrase
<Daviey> ah, JS.
<nigelb> ok, bed. 4 am is late enough.
<maco> yeah, hometime
<lifeless> hah, at least https://services.google.com/fb/forms/plusdevelopers/ is refreshingly honest
<lifeless> 'In addition, we'd love to gather more information about you.'
<nigelb> I need to tell my brain which timezone my body is in.
<nigelb> heh
<apachelogger> kees, mterry: bug 601662 requires attention, it is blocking movement on KDE 4.7 builds
<ubottu> Launchpad bug 601662 in grantlee (Ubuntu) "[MIR] libgrantlee-dev" [Critical,Triaged] https://launchpad.net/bugs/601662
<micahg> apachelogger: kees is on vacation until next week
<TheMuso> c
<apachelogger> micahg: oh, ok
<apachelogger> actually I could also live with a pre-promotion ;)
 * micahg hugs cjwatson 
#ubuntu-devel 2011-07-08
<broder> huh, i apparently missed the exciting discussion
<broder> Laney, maco: if you want people to make core-dev look less intimidating, you two should apply. right now i feel a little awkward applying for core-dev when my app is going to be reviewed by two people who were motu before me and who i know do more than i have recently
<micahg> broder: I don't think most people are thinking about that
 * ajmitch agrees that they should apply though :)
<slangasek> bryceh: installation should always recurse down the recommends as well as the depends; so I don't know why it didn't get pulled in on install.  Is it *available* at install time?  (I.e., is it on the CD where it should be?)
<slangasek> cjwatson: bugpattern - all seems reasonable to me
<bryceh> slangasek, cjwatson sorted it.  I thought pitti had seeded it but it hadn't.
<slangasek> bryceh: got it
<bryceh> er, wasn't
<lamont> if I go lucid->maverick->natty, do i need to bother rebooting into maverick?
 * penguin42 would
 * charlie-tca would, just to run all the updates
<slangasek> lamont: let us know! :)
<lamont> slangasek: heh
<slangasek> lamont: btw, has kees pestered you yet about the bind9 package not shipping the dnssec root cert? :)
<lamont> yeah
<slangasek> that sounds inconclusive. :-)
<lamont> he even convinced me that having installs of bind9 a year down the road fail horribly to run out-of-the-box, until manually corrected, makes sense
<slangasek> ah :-)
<lamont>  /bin/sh:        $python tests/test_all.py -q; \: not found
<lamont> neat.
<maco> broder: i kinda doubt ive done more than you recently :P also my next aspiration is kubuntu-dev :)
<maco> broder: all ive done lately is sorta-emergency ubiquity poking
<micahg> maco: there's no rush :), kubuntu-dev is very cool
<broder> maco: i may be giving you guys crap as much/more than i'm being serious :-P
<maco> and now that alpha 2 is out and kubuntu still doesnt have a working ubiquity, the emergenciness of my maybe figuring out how to fix it goes up *sigh* i think slangasek was a lot closer to figuring out what its doing than i am
<slangasek> maco: oh ugh, is that bug still there?  I figured it'd gotten fixed somewhere along the line, since I hadn't heard any more about it :/
<slangasek> maco: I understand what it's doing *wrong*, I just have no proposed solution for how to make it DTRT again
<maco> slangasek: i havent seen an email from lp saying i can stop worrying about it...
<maco> (i did see 9 emails from lp saying harald had decided i get 9 more bugs...)
<maco> slangasek: ooh though given i see some bug reports about it now crashing on the partitioner, maybe it is getting past that part. will need to attempt in a VM
<slangasek> we're talking about the keyboard map bug, right? which should have been language-specific?
<ScottK> slangasek: Could you promote grantlee and it's binaries back to Main.  kde4libs is now depwait for it.
<slangasek> ScottK: done
<micahg> ScottK: so, anything left to do with bug 601662
<ubottu> Launchpad bug 601662 in grantlee (Ubuntu) "[MIR] libgrantlee-dev" [Critical,Triaged] https://launchpad.net/bugs/601662
<ScottK> slangasek: Thanks.
<ScottK> micahg: Yes.  It needs some work, but let's not block everything for a MIR that's been undealt with through a whole dev cycle.
<micahg> k
<slangasek> the package was already in main last cycle, so I think it's reasonable to repromote it on that basis anyway
<pitti> Good morning
<pitti> bryceh: no, I didn't check main promotion for xdiagnose, I just wanted the thing to work and use GTK 3 :)
<pitti>  bryceh: it doesn't need seeding, it already has a reverse dependency
<pitti> i. e. it wants to go into main already, just needs an MIR and actually promoting it
<dupondje> Only Gnome Classic seems to work atm :(
<dupondje> :p
<pitti> not unity 2d? I heard talks that even 3d works on some platforms now
<dupondje> nope, Xorg going 100% cpu and doing nothing :p
<dupondje> gnome3 starts, but no menu's
<dupondje> unity 3d also 100% cpu on Xorg
<dupondje> :)
<dupondje> something in last upgrades broke Gnome3
<pitti> oh, somehow I read that as "on arm"
<pitti> dupondje: you might want to talk with RAOF then
<RAOF> dupondje: Define âlast upgradeâ.  Also, nvidia binary driver?
<dupondje> nope
<dupondje> broken Zeitgeist couldn't cause that ?
<dupondje> else I upgraded compiz yesterday
<RAOF> Oh, yeah.  Jason was reporting that ubuntuone was eating all his CPU.
<RAOF> Possibly a similar thing?
<dupondje> Yea zeitgeist causes that
<dupondje> but that could also cause Gnome3 doesn't start completely ?
<dupondje> thats https://bugs.launchpad.net/ubuntu/+source/zeitgeist/+bug/807203 btw
<ubottu> Ubuntu bug 807203 in zeitgeist (Ubuntu) "ubuntuone-syncdaemon crashed with AttributeError in __getattr__(): 'Symbol' object has no attribute 'PAGINATED_TEXT_DOCUMENT'" [High,Confirmed]
<dupondje> Any idea's on how I can debug the real cause ? Could be usefull :)
<didrocks> good morning
<evfool> morning didrocks
<didrocks> hey evfool
<dholbach> good morning
<mvo> cjwatson: the changelog stuff should be fixed now and the backlog it has caught up on now over night
<jml> good morning
<RAOF> Ra raw!  What's broken? :)
<jml> RAOF: M-d in my virtualbox install of Ubuntu
<RAOF> Oh.  Again, or still? :)
<jml> RAOF: More "still" than "again".
<jml> RAOF: am trying out the proprietary alternatives to see if things are better there
<RAOF> Ah.
<RAOF> It's not unity annoyingly eating the super key?
<jml> RAOF: no. At first I thought it was (and I think unity eating super complicates things), but after much xmodmap hackery and also, you know, seeing what happened without unity, I ruled it out.
<RAOF> Heh.  It's my great fear that at some point someone will really want me to learn about X keyboard handling in detail.
<jml> RAOF: I guess as a fallback I could get used to having meta & super switched around. But that's not the way that technology is supposed to work.
<RAOF> Right
<cjwatson> maco: I'm pretty sure I fixed the keyboard bug.  I tested my fix and I could no longer reproduce the bug.
<cjwatson> mvo: great, thanks a lot
<pitti> infinity, lamont: would it be possible to kill the glib build on allspice and gnome-keyring build on yellow? they both eternally hang in the test suite
<pitti> (and block amd64 builds)
<pitti> the i386 build of keyring on vernadsky has the same problem apparently
<pitti> infinity, lamont: bah, today is a good day for a buildd to die :( pygobject on crested is hanging as well, can you please kill, too?
<pitti> I understand the latter, and have a fix; for keyring/glib we are currently testing a fix
<pitti> elmo: ^ can you kill builds? lamont will probably still sleep for a couple of hours
<lamont> pitti: infinity can't
<lamont> on it
<lamont> pitti: if I'm hearing you correctly, that's glib on allspice, pygobject on crested (how about actinidiaceae??) and gnome-keyring on yellow?
<pitti> lamont: actinidiaceae can be killed as well
<pitti> lamont: thanks!
<pitti> need to disappear for a few hours, bbl
<dupondje> All right :) Gnome is working again :)
<dupondje> what was broken now ?
<dholbach> if somebody could approve my post to u-d-a I'd appreciate it :)
<dholbach> supi
<cjwatson> dholbach: done
<dholbach> cjwatson, thanks muchly
<nigelb> james_w: Do you want to talk about packageme for 5 minutes at UDS lightning talks?
<james_w> UDS?
<nigelb> er, UDW
<james_w> not this time I don't think
<nigelb> ok, np :)
<mterry> apachelogger, looking at the MIR now
<jbernard> serge_: no objections here
<lool> doko: Not sure whether you saw this, but latest gcc-4.6 has a libgcc1 breaking older gcc-4.4 and 4.5, which seem to need a merge from Debian
<doko> lool: yes, seen
<abhinav-> dholbach: kudos for bringing the long descriptions to harvest but I think something is wrong with harvest at the moment. can't list bugs in any package
<sabdfl> can IRC tell me last-seen, or do i need to ask a bot?>
<lool> sabdfl: nickserv might tell you
<lool> sabdfl: /m nickserv info sabdfl
<sabdfl> thanks lool
<serge_> jbernard: thanks, i'll push the pkg
<Amoz> dholbach, aha! found ya
<Amoz> dholbach, maybe you already know this but harvest isn't showing any opportunities
<maco> cjwatson: thanks! that one was scaring me :)
<dholbach> Amoz, it's known - I hope we get it fixed soon
<dholbach> abhinav-, yes, it's broken - I hope we get it fixed soon
<bdmurray> mvo: bug 801059 had a corrupt alternatives file added to it
<ubottu> Launchpad bug 801059 in firefox (Ubuntu) "package firefox 5.0+build1+nobinonly-0ubuntu0.11.04.2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" [Undecided,Incomplete] https://launchpad.net/bugs/801059
<Amoz> dholbach, cool
<jibel> users are reporting non working keyboard and mouse on Oneiric, bug 807306 , bug 807291, bug 807538
<ubottu> Launchpad bug 807306 in xorg (Ubuntu) "[oneiric] Keyboard & mouse not working in X" [Undecided,New] https://launchpad.net/bugs/807306
<ubottu> Launchpad bug 807291 in lightdm (Ubuntu) "Mouse and keyboard unresponsive until re-plugged in" [Undecided,New] https://launchpad.net/bugs/807291
<ubottu> Launchpad bug 807538 in linux (Ubuntu) "Keyboard and touchpad problems" [Undecided,Incomplete] https://launchpad.net/bugs/807538
<jibel> it started today, could someone have a look at it
<seb128> jibel: does downgrading the new xorg-server make it work?
<seb128> jibel: do you have the issue and can test?
<jibel> seb128, no I tried, but can't reproduce with usb keyboard and mouse
<seb128> hum
<seb128> jibel: would be useful to have a list of the packages they upgraded before getting the update as well?
<seb128> update->issue
<jibel> seb128, I requested more info and the history log.
<seb128> jibel: kenvandine has the issue, he says it's happening on a real box and with startx without lightdm
<seb128> cjwatson, did you do an autosync run around the time you did the manual sync round you did yesterday?
<cjwatson> no
<seb128> cjwatson, I'm trying to figure if -changes has a list of all uploads around that time or not
<cjwatson> we're past Debian import freeze, nobody should be doing autosyncs
<seb128> ok, so -changes probably has all what changed
<cjwatson> it should do, yeah
<tgardner> is it a known problem that oneiric x86en chroots cannot be installed on lucid/maverick/natty ?
<dholbach> Amoz, abhinav-: fixed
<abhinav-> dholbach: cool. thanks :-)
<cjwatson> tgardner: the other way round is known.  I hadn't heard of that way round
<tgardner> cjwatson, I just tested using an oneiric host. it doesn't work there either
<cjwatson> oh, you can't build an oneiric chroot at the moment anyway, the /run transition is incomplete and breaking stuff
<cjwatson> mentioned it in the release meeting just now
<tgardner> cjwatson, oh, is that the root of my problem ?
<cjwatson> could well be
<tgardner> I got busy watching the shuttle launch and forgot to pay attention to the release meeting
<doko> slangasek: for the eglibc build failure: either you try to build with gcc-4.6, or you wait until gcc-4.5 is uploaded
<slangasek> doko: I can wait for gcc-4.5 to be uploaded, certainly
<slangasek> doko: should eglibc not be switched to use gcc-multilib, instead of gcc-4.5-multilib?
 * doko didn't want to hear this ;p
<slangasek> heh
<doko> no, a first eglibc build with a new major version should be checked first
<slangasek> ok
<Laney> can someone please look at sparkleshare in NEW/oneiric? It's been there some time
<Laney> (and people are starting to ask me about it)
<infinity> Laney: Done.
<tkamppeter> pitti, hi
<cr3> is there a nice way to check if a package is installed programmatically, to be used in a shell script or a makefile?
<cr3> dpkg -l package_name | tail -n 1 | grep '^ii' doesn't seem absolutely reliable
<brendand> cr3: is dpgk --get-selections not reliable?
<cjwatson> I would go for something involving dpkg-query -W
<cjwatson> brendand: it's the wrong question
<cjwatson> --get-selections asks for the intended state, not the actual state
<cr3> cjwatson: so, if the package is installed, I get two columns, otherwise I get either one column if the package is known or the string "No packages found..." which might be localized. what about dpkg --status?
<cjwatson> you can customise the output with the --showformat option - you don't need to parse out columns.  read its man page
<cjwatson> dpkg-query will be easier than using dpkg --status and parsing the output
<cr3> cjwatson: awesome, I will have a closer look. thanks!
<cjwatson> the string "No packages found ..." goes to stderr, not stdout
<cjwatson> 2>/dev/null and only look at stdout
<cr3> dpkg-query -W -f='${Status}' and what you said about stderr, I should be set
<cjwatson> ${Status} is a bit fiddly because it has both desired state and actual state; I think I'd go for ${Version} being non-empty
<cjwatson> hm, maybe not, that fails on packages that are removed but still have config files present
<cjwatson> I guess ${Status} is the best you've got
<cr3> success: ifeq "$(shell dpkg-query -W -f='$${Status}' $package 2>/dev/null)" "install ok installed"
<bambee> any idea about this strange behaviour http://paste.ubuntu.com/640306/ ?
<penguin42> echo $PATH
<bambee> penguin42: already done, http://paste.ubuntu.com/640313/ <-- /usr/bin is there
<bambee> apparently the symlink is dead
<bambee> and not correct http://paste.ubuntu.com/640316/ (I am an amd64)
<slangasek> Keybuk: hey there
<slangasek> Keybuk: it looks like the base-files /run migration is incomplete compared to the Debian approach; /var/run isn't provided as a symlink.  Is this deliberate for any reason, or can I patch up base-files to do the same as in Debian?
<ion> Any major breakage in oneiric? Thinking of upgrading my laptop from natty.
<slangasek> I'm sure there is some, though I'm typing this from it and have no specific complaints :)
<slangasek> well, that's not true, I have many specific complaints but none that rise to the level of "major breakage"
<slangasek> or even "I've gotten around to filing a bug" ;)
<bdmurray> slangasek: I just uploaded a base-files debdiff to fix another issue
<bdmurray> slangasek: and when I say uploaded I mean added to bug 744253
<ubottu> Launchpad bug 744253 in base-files (Ubuntu) "documentation deep-links in motd" [High,In progress] https://launchpad.net/bugs/744253
<Keybuk> slangasek: umm, what base-files /run ?
<slangasek> Keybuk: the one uploaded to Ubuntu yesterday with your name in the changelog? :)
<bdmurray> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: bdmurray
<slangasek> bdmurray: do you think that change is required if we get the website fixed (which it ought to be, given that this URL is in existing releases)?
<bdmurray> slangasek: yes, I think it is still a nice addition
<slangasek> fair enough
<bdmurray> slangasek: however I don't recall what used to be at the original url
<Keybuk> slangasek: I didn't upload anything
<Keybuk> in fact, I'm pretty damned sure I still can't upload
<micahg> slangasek: barry uploaded that
<slangasek> oh
<Keybuk> due to the whole Launchpad hates my GPG key issue
<slangasek> why did barry put your name on it? :)
<slangasek> I saw the bzr log listed him, but thought that was some manual archive/UDD reconciliation
<bdmurray> didn't he say something about it in his pilot report?
 * slangasek looks
<stgraber> http://tinyurl.com/622frtw
<Keybuk> I don't know, I'm not barry ;-)
<stgraber> - merged base-files patch to resync archive with sjr's working branch. archive and udd branch should now be in sync.
<slangasek> Keybuk: so in conclusion, I should do whatever I think is right? :)
<stgraber> (from barry's e-mail to ubuntu-devel)
<slangasek> stgraber: yep
<Keybuk> slangasek: I think in general that is a good plan for life
<slangasek> heh
<Keybuk> for you, especially
<stgraber> I remember that last time we talked about it in #ubuntu-devel, the discussion was that the changes barry uploaded were done before Debian started migrating to /run and that now that we're late for that change we should merge whatever they did
<micahg> Keybuk: BTW, you could create a throwaway key just for uploading
<slangasek> stgraber: yeah, that seems approximately correct
<Keybuk> micahg: I'd have to install gpg on my Mac then ;-)
<micahg> heh
<Keybuk> natty really doesn't like VMs :-(
<micahg> Keybuk: unity-2d works with one of the kvm drivers
<Keybuk> micahg: all I see is an old-style gnome desktop with half the bits missing or not working
<micahg> oh right,, classic was fallback
<micahg> well, if you want unity, unity-2d it might work
 * highvoltage wants to see what goes wrong in gnome 3 fallback this weekend. it works fine in debian
<Sarvatt> ion: lots of people reporting no mouse/keyboard after the post alpha-2 updates, might be something to watch out for
<ion> sarvatt: Thanks. https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/807306 apparently
<ubottu> Ubuntu bug 807306 in xorg (Ubuntu) "[oneiric] Keyboard & mouse not working in X" [Medium,Incomplete]
<ion> Oh, thatâs about a VM.
<Sarvatt> yep indeed, people are hitting in on real installs too though
<Keybuk> micahg: tbh, I just wanted something vaguely usable for doing Ubuntu work on
<ion> Sounds like something i might be able to debug.
<ion> âAfter this operation, 8,765 MB disk space will be freed.â (Deleting a bunch of games i meant to try out but havenât got around to. :-P)
<ion> A.k.a. spring cleaning before release upgrade.
<bdmurray> slangasek: speaking of base-files bug 285734 is rather interesting too
<ubottu> Launchpad bug 285734 in base-files (Ubuntu) "[PATCH] In /etc/issue, tell users how to undo accidental Ctrl+Alt+F1 presses" [Undecided,New] https://launchpad.net/bugs/285734
<bdmurray> I'm particularly worried about that guy's sister
<bdmurray> "OMIgawds!"
<slangasek> bdmurray: who presses Ctrl+Alt+F1 by accident? :)
<ScottK> People like that aren't rare.
<ScottK> The same ones that hit Ctel+Alt+Backspace
<ScottK> Apparently it was a lot.
<bdmurray> slangasek: I seem to recall mpt mentioning it in a presentation at UDS
<slangasek> hmm
<slangasek> well, at the moment I'm trying to unbreak debootstrap... I don't think I'm in the right headspace to properly consider edits to /etc/issue
<infinity> I'm as puzzled as others by the idea that you can ctrl-alt-f1 by accident.
 * tumbleweed used to press ctrl+alt+backspace quite a lot when I was using ctrl+alt to change workspaces
<infinity> You could also end up with people, upon crashing their DM (okay, rare, but probably less rare than accidental ctrl-alt-f1) then wondering why the "text-mode's" instructions are a lie.
<slangasek> crashing the dm is supposed to launch the failsafe X interface
<slangasek> though I see now that /etc/init/failsafe-x.conf only handles gdm, not lightdm, hah
<Sarvatt> slangasek: it's trying to exec /etc/gdm/failsafeXServer which doesn't exist too
<infinity> slangasek: I like the theory and all, but there are still times when X is just so hideously hosed that you're ultimately going to end up at a terminal.  Or calling tech support.
<Sarvatt> looks like that's now in xdiagnose installed to /usr/share/xdiagnose/failsafeXServer
<slangasek> Sarvatt: ugh
<bryceh> lightdm doesn't call it anyway
<infinity> slangasek: I dunno.  I have no real objections to handholding in issue and motd, I just have old skool UNIX user grumpiness about issue being needlessly verbose, I suspect. ;)
<bryceh> slangasek, lightdm just exits to console right now if X terminates during startup
<infinity> slangasek: And one could keep it the same classic UNIX terseness with something like: "Ubuntu 10.04.2 LTS \n \l (Alt-F7 to return to GUI)"
<infinity> slangasek: (And of course, even that's a blatant lie if you don't actually have X and/or something graphical on VT7)
<bryceh> or if it is on vt8
<infinity> Yeah, or that.
<bryceh> pidof /usr/bin/X would give you whether X is running
<bryceh> ps a | grep X shows it on tty7, so seems like would be straightforward to figure out where it is too
<infinity> Yeah, but /etc/issue is just a text file.
<broder> ConsoleKit also knows
<infinity> So, this goes from a wishlist "update a text file" bug to something nasty involving hacking getty.
<infinity> Which still doesn't work, since getty outputs to terminals when it spawns, not when you switch to them. :P
<broder> infinity: one option would be something along the lines of "press enter to switch back to your session" or whatever
<broder> instead of outputting a specific tty to switch to
<infinity> You'd have to find a key sequence to trap that doesn't break the brains of every console user in the world.
<infinity> (for instance, the first thing I do when I connect a serial terminal is hammer enter a few times to get a prompt)
<infinity> Though, obviously, our slightly-odd getty codepath would only be running on VTs.
<infinity> I dunno.  I think we've just proven the bug's a bit deeper than a text file addition, regardless.
<bryceh> finally, a use for CAPSLOCK
<broder> sure, i do the same with enter. the potentially simpler solution would be to just use enter anyway, but include in the "please press enter" printout instructions on how to disable that behavior
<infinity> "To return to your graphical session, hit left, right, left, right, up, down, A, B, CAPS"
<james_w> just make changing VT a sysreq combo
<bryceh> if no user is logged in and it's just a login prompt, there's probably a set of keys which  have no purpose which could be used.  E.g. Home or Esc maybe
<infinity> james_w: And how long until people complain that they can hit sysrq by accident?
<infinity> james_w: Seems about as likely as ctrl-alt-f1, to be fair.
<slangasek> not only is /etc/issue just a text file, it's output to the console in parallel to X startup
<slangasek> right, infinity said that already
<infinity> slangasek: Before, generally.
<james_w> infinity, that's what was done for ctrl-alt-backspace
<james_w> I haven't heard complaints
<bryceh> I have ;-)
<james_w> it was only a semi-serious suggestion anyway
<infinity> james_w: I switch terminals a lot more than I need to kill X.
<james_w> heh
<james_w> complaints from people others that X developers :-)
<infinity> (And, sometimes I switch terminals TO kill X, since ctrl-alt-bkspc no longer works out of the box)
<bryceh> ;-)
<slangasek> infinity: usually after :)
<slangasek> infinity: we try to bring the X server up ASAP; we wait until rc is done before spawning getties
<infinity> slangasek: Oh, right.  Start on stopped rc, I forgot about that change.
<slangasek> at least for tty1
<bryceh> c-a-b angst recently spotted @ http://linuxlock.blogspot.com/2011/06/canonical-alienates-their-major-asset.html
<infinity> slangasek: Stil, close enough to parallel to not really allow you to do silly things like this.
<infinity> bryceh: I can't be bothered to read to article, but I love that the URI implies that our "major asset" is people who like to kill X servers.
<infinity> s/read to/read the/
<infinity> Besides, if he wants the old functionality back, all he has to do is install unity.
<infinity> It's less predictable, but just as reliable.
<bryceh> infinity, 'The first threads came apart when decisions were made to remove certain keyboard shortcuts, "for the good of the new user".  Ctrl/alt/delete and ctrl/alt/backspace were removed.'
<infinity> Ctrl-Alt-Del isn't removed...
<bryceh> plus it was upstream that removed the shortcut.  But why spoil a rant with messy facts.
<infinity> That sort of proves his Ubuntu = Linux side-rant.
<micahg> bryceh: it's in the comments
<bryceh> micahg, yep
<slangasek> ah, this is the HeliOS guy
<bryceh> but in terms of actual ubuntu users, james_w is right, we haven't gotten bug reports about it.  Seems a total non-issue with our users.
<james_w> I was commenting more about the lack of complaints that sysreq was too easy to hit
<james_w> I realise that there were complaints about taking away ctrl-alt-backspace
<bryceh> james_w, ah, also true
<infinity> james_w: I'll file a bug.
<james_w> or rather hiding it in the keyboard configuration
<infinity> james_w: My 1 Sysrq bug will match the 1 Ctrl-Alt-F1 bug, and we can have a showdown. ;)
<slangasek> bryceh: I don't think bug reports is an accurate measure of whether people are bothered by the Ctrl+Alt+BkSp change
<maco> bryceh: did the dude JUST realise c-a-b is non-default *now*?
<slangasek> I expect people who use Ctrl+Alt+BkSp to also be more likely to research issues before filing new bug reports
<bryceh> maco, I assume he's been holding it in until now ;-)
<bryceh> slangasek, I like the world you live in, with sane bug reporters, can I join?  :-)
<slangasek> bryceh: well see, that just goes to show that the people you're getting bug reports aren't the ones who use c-a-b! :)
<infinity> bryceh: It's easy, you just filter your bugmail and only read incoming mail from the 4 people you like.
<bryceh> anyway, from what I understand of how c-a-b works, it likely isn't going to give the relief that it used to, since the freezy bits have moved from X to the kernel, and c-a-b won't help there
<bryceh> it will help if a client goes seriously out of control and locks up X that way, but that seems to be thankfully rare in practice
<bdmurray> slangasek: I seem to recall a guideline for patch numbering like 33-zyx.patch
<bdmurray> slangasek: is there one?
<infinity> bdmurray: Patch numbering made more sense with systems like simple-patchsys where they were applied in filesystem order.
<infinity> bdmurray: But some large/complex source packages still like to codify meaning in numbers (like 000->500 = to/from upstream, 900+ = local only, never being forwarded, etc)
<infinity> bdmurray: With people (in some cases, slowly) moving to source-format 3.0 and quilt, though, the filesystem ordering is meaningless, and even the coded meaning is only marginally useful, since they're all meant to have headers that don't suck.
<bdmurray> ah okay thanks
<slangasek> yeah, I don't know of any guideline for patch numbering
<slangasek> there's a guideline for headers within the patches
<infinity> Does dpkg-dev, devtools, or quilt, have a utility to list patches with consice header info?  I haven't looked.
<infinity> concise too.
<infinity> devscripts, even.  It's clearly Friday afternoon.
<bdrung_> infinity: it's Saturday. :p
<micahg> bdrung_: the debian package doesn't include the entire multiarch diff as specified in the 1.4.6-5 changelog, is that not a problem?
<micahg> bdrung_: sorry, libgcrypt11 ^^
<bdrung_> micahg: multiarching it was done differently
<bdrung_> micahg: the result should be the same
<bdmurray> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Development of Ubuntu (not support, not app development) | #ubuntu for support and general discussion for hardy ->  oneiric | #ubuntu-app-devel for application development on Ubuntu | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
#ubuntu-devel 2011-07-09
<bdmurray> Any core devs about?  I seem to have indirectly (of course) broken suspend in oneiric
<bdmurray> I've a debdiff that fixes it at http://people.canonical.com/~brian/tmp/toshset_1.76-1ubuntu1.debdiff
<bdmurray> bryceh: still about?
<bryceh> yep
<infinity> bdmurray: Is that tested to DTRT?
<infinity> Oh, I'll let bryceh handle it.  Good timing. :P
<bdmurray> infinity: yes, I've installed it and suspended successfully
<bdmurray> the backstory is I fixed inhibit in pm-utils and revealed this bug in toshset
<infinity> How dare you create bugs while fixing others.
<bdmurray> bryceh: I just need a debdiff sponsored
<bryceh> bdmurray, ok, is there a bug # to associate with this?
<infinity> bdmurray: Build-depends seem to imply it's a quiltish package, but your patch isn't in patches/series?
<bryceh> (or, what was the original bugfix that uncovered this?)
<bryceh> infinity, good catch
<bryceh> wait, no it's in series
<bdmurray> there was already a patch that created novatel so I just modified it
<bdmurray> rather than creating a patch of a patch
<infinity> bdmurray: Oh, no, you were editing a patch that's already there.
<infinity> Yeah.
<infinity> Sorry, was one indent level back. ;)
<infinity> I'll go back to building things out of wood and metal.  It's too late in the week to use my brain.
<bdmurray> bryceh: I'll forward the patch to debian on monday
<bryceh> bdmurray, ok everything checks out; looks good, uploaded.  I elaborated the changelog entry a bit.
<bryceh> bdmurray, probably don't want to sru that pm-utils fix, at least not right away :-)
<bdmurray> bryceh: oh heh, probably not the first thing to do ;-)
<Quibus> hi all
<Quibus> tumbleweed: thanks to your help, openMSX now compiles in thumb2 mode on ARM :-) See http://openmsx.svn.sourceforge.net/viewvc/openmsx?view=revision&revision=12202
<penguin42> question for a glib type person - what should an _unref function do - does it just reduce the count and free if necessary?  What happens if hte poin
<penguin42> what happens if the pointer it is given is NULL?
<cjwatson> penguin42: I don't think you're supposed to implement your own _unref nowadays - you're supposed to set things up such that g_object_unref works, aren't you?
<cjwatson> http://developer.gnome.org/gobject/stable/gobject-memory.html
<penguin42> cjwatson: Thanks, I'm not trying to implement one - I'm trying to fix indicator-datetime that on my machine is passing a bad pointer to unref; it's doing that because the object was never created and currently has a pointer value of 0x1 for it; I was wondering if I just needed to make sure it was NULL or actually check before unref'ing
<cjwatson> g_object_unref will just do nothing if passed NULL
<penguin42> ok, good
<cjwatson> although I don't think that's documented
<cjwatson> given the lack of documentation of that, I think I would be inclined to check explicitly
<penguin42> OK
 * penguin42 has been having unity-panel-services crashing at startup for the last couple of weeks; turns out that for some reason I don't have an /etc/timezone and indicator-timezone segs if it's missing
 * lamont tries to understand what on earth the sound controls icon in the panel is supposed to be
<penguin42> right, added patch to bug 804754 - now time for breakfast :-)
<ubottu> Launchpad bug 804754 in indicator-datetime (Ubuntu) "[Oneiric] unity-panel-service crashed with SIGSEGV in g_date_time_unref()" [Medium,New] https://launchpad.net/bugs/804754
<penguin42> ok, now where the heck did lp put the old builds of packages
<penguin42> ah there
<anli__> Hello!
<anli__> Can I put suggestions in here?
<anli__> Ok, I try, what I really miss in gnome is a open or save dialog where you can also delete files
<anli__> So when an open dialog for instance pops up, you can mark a file and press delete, then you can cancel the open dialog if you want
<penguin42> anli__: You can open a bug which will be a wishlist item
<penguin42> anli__: You could do that on launchpad or on Gnome's bug tracker; you might also want to suggest it on the ayatana mailing list that's about UI design
<anli__> ok
<anli__> trying that
<anli__> If it is not cumbersome
<anli__> It should not be, then I give up
<anli__> :)
<penguin42> anli__: Shouldn't be too bad
<anli__> I prefer to open a bug rather than being on a mailing list...
<anli__> What I hate with those bugzillas is that you have to create an account to file a bug
<anli__> Its not commitment free so to say
<penguin42> anli__: You need a >little< commitment to get an idea through - not much!
<anli__> But what about no commitment :)
<anli__> Is there a finesse requiring me to create a username or password just to file a bug
<anli__> There are a lot of places around the internet where the user is required to create an account even if the user really doesnt know what to protect
<anli__> enhancement request commited
<penguin42> anli__: Thanks - it means that someone can come back to you and ask you whether they understand your idea correctly, or if they reject the idea you can ask them why
<anli__> Hm, must report some bugs, I hate the volume slider
<anli__> It slides above the level that I point to with the mouse
<anli__> Maximizing the volume without me wanting it :)
<anli__> hm, indicator applet is not on the list
<ScottK> cjwatson: We've got a significant part of the way through getting KDE 4.7 into the archive.  It involved a lot of package renames, so we've kubuntu-dev who can't upload the new packages since they aren't in the packageset.  What's the best way to get that resolved?  Wait and you'll get to it?  Ping you to update the packagesets?  Put together a list and give it to you?
<cjwatson> if they're in the relevant seeds, it's probably just a matter of me running a script
<cjwatson> which I've just done
<cjwatson> http://paste.ubuntu.com/640960/
<cjwatson> happy to be pinged to do that
<cjwatson> if there are others beyond that, give me a list
<ScottK> cjwatson: Thanks.  There are some like kde-workspace that are renames (of kdebase-workspace).  Will the script pick them up after the obsolete source is removed?
<ScottK> There are others, so I'll get you a list.
<cjwatson> I expect if you've split up anything that I previously had an exception for (http://paste.ubuntu.com/640963/) then I'll need to adjust the exceptions list manually
<ScottK> Yes.  Some of those are affected.
<ScottK> Will get you a list.
<cjwatson> ta
<cjwatson> waiting for me to get to it is probably in general not a good plan here :-)
<ScottK> OK.
<infinity> Where does this packagesettery business live?  I'm happy to be a redundant Colin after poking at it and being sure I know what's going on under the hood.
<ScottK> Unfortunatley since there is no redundant Colin at the moment he's the only one that can answer most of that.
<cjwatson> in this particular case it unfortunately lives in ~cjwatson in various places
<infinity> cjwatson: Smooth. ;)
<cjwatson> I *really* need to remove the SPOF in this case
<cjwatson> (and actually, ideally hand it over to somebody else to drive on a regular basis since it needs to be improved in ways I don't have the time to do)
<infinity> cjwatson: I see some in ~cjwatson on cocoplum.  By "various places", how many do you mean? :)
<cjwatson> I think most of it is there
<infinity> Such confidence.
<cjwatson> poke me about it during the week and I'll try to get it shifted into ~lp_archive and public bzr
 * infinity nods.
<infinity> The latter would be good for folks like Scott.
<cjwatson> even though the code is frankly embarrassing
<infinity> Well, and the former just for redundancy across a team being able to drive it.
<infinity> Embarrassing is no excuse to not release.
<infinity> If it was, none of my code would EVER be public.
<infinity> Ever.
<cjwatson> there's a cron job, that part should live in a team dir
#ubuntu-devel 2011-07-10
<rsalveti> did we properly change oneiric to use /run already?
<rsalveti> base-files is not creating /var/run anymore, since last update: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/oneiric/base-files/oneiric/revision/75
<rsalveti> and as a side effect packages trying to use /var/run will fail in some way, like described at bug 807974
<ubottu> Launchpad bug 807974 in eglibc (Ubuntu) "debootstrap fails to install libc6 installing oneiric from natty" [High,Confirmed] https://launchpad.net/bugs/807974
<rsalveti> this is caused because libc6 postinst is trying to touch /var/run/init.upgraded
<rsalveti> but /var/run doesn't exist anymore while debootstraping
<rsalveti> I believe /var/run will be bind mounted to /run, but I'm still looking to see if this changed is done already
<rsalveti> maybe removing the /var/run directory from base-files is wrong anyway, as we'll end up mounting it as bind later on
<broder> rsalveti: i think the transition is just incomplete, and not much is likely to happen over the weekend
<rsalveti> broder: but do you know if we're planning to have /var/run as a bind mount of /run?
<rsalveti> like fedora
<broder> i think the intent is to implement the same setup, yes
<rsalveti> so we may still need to create the /var/run directory anyway
<rsalveti> as it'll still be used, but as a mount point
<broder> i couldn't tell you. i think waiting until monday is probably best
<zombie-dev> hi im a new coder working on Unity. I got stuck on a few lines of code that seemed important to me but they had been commented out. How would I find when this change (in which version of Unity) had been made and why?
<penguin42> zombie-dev: Do you have the bzr checkout of the code?
<penguin42> zombie-dev: Do you have the bzr checkout of the code?
<zombie-dev> yes
<penguin42> zombie-dev: You should be able to do bzr annotate filename
<penguin42> zombie-dev: It'll show you the last commit to change each line
<zombie-dev> k ill try it
<zombie-dev> <penguin42> thankss annotate and log did it fr me
<penguin42> no prob
<htorque> bryceh: hi, i'm trying to help with bug 807306 but i'm unable to find the package xserver-common (https://launchpad.net/ubuntu/+source/xorg-server/2:1.10.2-1ubuntu1/+build/2571970). how would i find it?
<ubottu> Launchpad bug 807306 in xorg (Ubuntu) "[oneiric] Keyboard & mouse not working in X" [High,Confirmed] https://launchpad.net/bugs/807306
<penguin42> unfortunately I'm not going to get a chance to try much further through the list on that one - I think I've already done all the obvious ones, and have a feeling it's something like a config file that's not going to get wound back
<penguin42> htorque: It's a _all.deb so it's in the i386 build
<htorque> penguin42: ah, thanks!
<penguin42> htorque: As you can see from that list I rolled a lot of things back; but there are a lot to go and I don't have time to do many more, and am not really sure which ones are worth trying
<htorque> penguin42: unfortunately i haven't rebooted for about a week but done (lots of) regular updates :-/
<penguin42> htorque: Fortunately it has only happened to my play VM not my laptop that's running OO
 * penguin42 thinks it needs a udev guru to suggest some things to try
<mwhudson> is there any way i can easily tell if the fix for https://bugs.launchpad.net/ubuntu/+source/linux/+bug/761065 is in the kernel in natty-proposed?
<ubottu> Ubuntu bug 761065 in linux (Ubuntu) "[Sandybridge] Spurious "*ERROR* Hangcheck timer elapsed... blt ring idle" messages in dmesg when using compiz" [Medium,Triaged]
<lifeless> mwhudson: install it from -proposed ?
<mwhudson> lifeless: i guess
<lifeless> or look at the changelog in Launchpad
<mwhudson> right, that's here? https://launchpad.net/ubuntu/natty/+source/linux/2.6.38-10.46
<mwhudson> i can't see anything there
 * mwhudson wonders how much trouble he would get from just running oneiric kernel
<mwhudson> (i guess i like my filesystems too much for that)
<lifeless> oh yay win, one bug link. /sob
<lifeless> mwhudson: poolie has had fs corruption on oneiric FWIH
<mwhudson> oh great
<TheMuso> Anybody having problems with sbuild after recent upgrades? I am getting this from sbuild in oneiric: Can't create lock file /var/lock/sbuild: No such file or directory
<TheMuso> Sbuild was working fine on Friday.
<broder> TheMuso: probably /run-related issues
<pook1e> can anyone here help me with a problem i'm having building a package with pbuilder?
<TheMuso> broder: hrm ok thanks.
#ubuntu-devel 2012-07-02
<RAOF> infinity: You win a ânetinst is broken on quantal, works on preciseâ award!
<infinity> RAOF: Just what I always wanted.  And a bit disappointed because, in theory, we have people testing and QAing this stuff. :/
<vibhav> I was having a look at http://people.canonical.com/~ubuntu-archive/NBS/libsclang1 and saw that debian/control file of supercollider (which is listed in reverse-depends) does not have libsclang1 as any Dependency. Does this mean that the package is auto-selected and we just need a rebuild for the transition?
<infinity> vibhav: Probably, yes.  Most library dependencies are a product of the build, not hard-coded.
<infinity> vibhav: In that case, the problem is that supercollider is FTBFS on arm and powerpc.
<infinity> vibhav: Looks like a new upstream coming "soon" will fix it.
<dholbach> good morning
<dholbach> didrocks, salut mon ami!
<didrocks> hey hey dholbach!
<dholbach> didrocks, are you going to join us in #ubuntu-arb? :)
<didrocks> yep, coming :)
<vibhav> infinity: So should I file abug for transition or wait for a new upstream vversion?
<infinity> vibhav: The latter.
<infinity> vibhav: A bug won't magically make the package build, it'll just make someone mstakenly reupload it and it'll fail again. :P
<vibhav> infinity: Yeah, I meant filing a bug and providing a debdiff. But anyways, lets wait for the next upstream version
<infinity> vibhav: A debdiff for what?
<vibhav> infinity: transition. We just need a rebuild
<infinity> vibhav: No.
<infinity> vibhav: Look more closely, this is what I've been telling you.
<infinity> vibhav: It's already been rebuilt and transitioned on i386 and amd64, but it failed to build on arm and powerpc.
<vibhav> infinity: ah, I didnt see that
<infinity> vibhav: No matter how many times you reupload it, it won't magically start working.
<vibhav> infinity: I didnt know it had FTBFSed on arm and powerpc
<vibhav> anyways, thanks
<infinity> vibhav: I did mention it previously. :P
<vibhav> infinity: yeah *slaps forhead*
<vibhav> Strange, netinst doesnt seem to work in the daily builds
<infinity> On which arch?
<vibhav> i386
<vibhav> ah wait, its my internet connection
<vibhav> infinity: On which arch did you break netinst?
<infinity> vibhav: I didn't, personally, but I hear it's broken on ARM.  But it's a long weekend for me, so I'm deep in "not caring" mode today. ;)
<nigelb> infinity: Canada? :)
<infinity> nigelb: *waves flag*
<vibhav> hah
<cjwatson> Sweetshark: https://dogfood.launchpad.net/~cjwatson/+archive/dogfood-copy-target/+packages - libreoffice copied in there using +copy-packages.  This isn't doable on production yet but I thought you might like to know that we're getting there
<Sweetshark> cjwatson: you seem to be reading my mind!
<Sweetshark> cjwatson: I would need your help with copying binaries again I guess. https://launchpad.net/~libreoffice/+archive/ppa/+builds?build_state=building is running out of discspace again, leaving people on amd64 with a half (arch-indep only) update. Can you copy https://launchpad.net/~bjoern-michaelsen/+archive/libreoffice-precisetest-20120327/+sourcepub/2532414/+listing-archive-extra to https://launchpad.net/~libreoffice/+archive/ppa so that peopl
<cjwatson> cut off at "so that peopl"
<Sweetshark> ... so that people dont run into that anymore?
<cjwatson> Sweetshark: I'm not sure I can, since it's already building
<Sweetshark> cjwatson: or would this fail as there is such a package in the target ppa?
<cjwatson> LP will reject the copy attempt since there's a conflict
<Sweetshark> cjwatson: will it help to remove the package from the target ppa?
<Sweetshark> cjwatson: (likely the i386 would need to be removed anyway)
<cjwatson> Probably eventually, but I don't know how long it would take to remove it completely enough to allow a re-copy
<cjwatson> A version bump would definitely fix it; whether you want to do that ...
<cjwatson> So why doesn't it run out of disk space in your own archive?
<cjwatson> Surely it uses a deterministic amount of space
<Sweetshark> cjwatson: different buildd I guess ...
<cjwatson> Hm - actually, no, I don't think that deleting will help
<Sweetshark> cjwatson: so a version bump would mean another buildd -- and again a possible fail because of discspace.
<cjwatson> The test is "ever been published"
<Sweetshark> cjwatson: guessed so.
<cjwatson> If you have a buildd known to work, I can force it onto that
<cjwatson> With coordination
<cjwatson> Probably might as well just do that with the build in ~libreoffice/+archive/ppa at this point, once that fails
<Sweetshark> cjwatson: that would be great (doing it without a bump)
<Sweetshark> cjwatson: however, that buildd currently doesnt really fail. it just hangs indefinitelty.
<Sweetshark> cjwatson: If I cancel it, I am not sure I would be able to retry it.
<cjwatson> Probably not
<cjwatson> Really indefinitely, or just a long time?
<Sweetshark> cjwatson: its hanging for days without any change in the build log preview. unless launchpad times it out I dont think it will.
<Sweetshark> cjwatson: do you have any administrative way to force "kill the build" which doesnt imply canceling?
<Sweetshark> seb128: btw: see backlog
<tumbleweed> Sweetshark: re debian bug 679700. why isn't unopkg in /usr/bin on ubuntu?
<ubottu> Debian bug 679700 in accessodf "accessodf: unopkg isn't on the PATH in Ubuntu" [Minor,Open] http://bugs.debian.org/679700
<cjwatson> Sweetshark: I'll ask ops for it.
<hrw> hi
<hrw> does someone work on merging aptitude 0.6.8?
<Sweetshark> tumbleweed: dont know, if there is a explicit reason for that. However, since for example soffice is symlinked from /usr/bin, I would assume doing the same for unopkg to be more apporpriate than PATH-adding.
<tumbleweed> Sweetshark: debian has had it that way for ages, so I assumed it was intentional...
<Sweetshark> tumbleweed: I pinged _rene_ about it ...
<tumbleweed> Sweetshark: please reply on the debian bug too, then. it's a little invalid
<Sweetshark> tumbleweed: btw using the word "ubuntu" on renes debian bugs might make you get ignored quickly.
 * tumbleweed thought you had a good relationship with him? :)
<cjwatson> Sweetshark: the build is failed now; I have to go out for a bit now, but when I get back I'll try to force it onto a known-good builder.  Probably best to leave it alone in the meantime
<seb128> is anyone using chromium on precise and could help to verify bug #992352
<ubottu> Launchpad bug 992352 in chromium-browser (Ubuntu Quantal) "Please update to 18.0.1025.168" [Medium,Triaged] https://launchpad.net/bugs/992352
<Sweetshark> cjwatson: awesome!
<seb128> cjwatson, do you think you could verify bug #998492 if you ever get some spare cycles? ;-) the SRU is in proposed for 32 days, it would be good to get it moved to -updates
<ubottu> Launchpad bug 998492 in Baltix "Fails to detect package download errors on architectures other than amd64" [Undecided,New] https://launchpad.net/bugs/998492
<hrw> uf. looks like aptitude 0.6.8-1ubuntu1 builds
<cjwatson> seb128: yeah, I've been trying and failing to verify that for a little while actually, because I keep running into unrelated problems
<cjwatson> seb128: I'll give it another go ...
<seb128> cjwatson, thanks
<hrw> Can someone take a look at aptitude 0.6.1-1ubuntu1 at http://marcin.juszkiewicz.com.pl/~hrw/ubuntu/ - bug 824708
<ubottu> Launchpad bug 824708 in aptitude (Ubuntu) "aptitude can no longer show changelogs: "Changelog download failed: Download queue destroyed." Please merge the fixed version, 0.6.8, from Debian." [Medium,Triaged] https://launchpad.net/bugs/824708
<Sweetshark> cjwatson: https://launchpad.net/~libreoffice/+archive/ppa/+build/3609969 <- is now failed. can you give me a good buildd for a retry?
<larsduesing> Hmmm... could anybody sponsor SRU https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408 please?
<ubottu> Launchpad bug 1007408 in aiccu (Ubuntu Precise) "aiccu.conf does not need server directive, while upstart script wants it" [Undecided,New]
<ahasenack> hi, is there some place I can check for the SRU queue, to see where my request stands?
<larsduesing> ahasenack: good question... afaik there is no..
<ahasenack> larsduesing: do you know where to see all pending requests? I think there is a list somewhere
<ahasenack> http://reqorts.qa.ubuntu.com/reports/sponsoring/ hmm found this
<larsduesing> sec
<ahasenack> but mine isn't there
<ahasenack> I did subscribe sru-sponsors
<larsduesing> ohm
<larsduesing> strange...
<tumbleweed> who is sru-sponsors?
<larsduesing> ahasenack: could you please tell me which bug you mean?
<tumbleweed> you want ubuntu-sponsors
<ahasenack> larsduesing: bug #1004678
<ubottu> Launchpad bug 1004678 in landscape-client (Ubuntu Precise) "Please update landscape-client to 12.05" [Undecided,New] https://launchpad.net/bugs/1004678
<ahasenack> tumbleweed: https://launchpad.net/~ubuntu-sru this team
<tumbleweed> ahasenack: they don't sponsor, they review SRUs
<ahasenack> tumbleweed: sorry I got the name wrong above
<tumbleweed> you want ubuntu-sponsors
<ahasenack> tumbleweed: when does ubuntu-sru get involved?
<tumbleweed> they review the upload in the archive's queue
<ahasenack> tumbleweed: so first ubuntu-sponsors, and once it's in proposed, then ubuntu-sru?
<tumbleweed> so, after it's been uploaded, they accept the upload
<tumbleweed> the sponsor should subscribe ubuntu-sru if you haven't
<ahasenack> tumbleweed: it's weird: "after it's uploaded, they accept the upload"
<ahasenack> tumbleweed: they accept it after the fact?
<tumbleweed> yes
<tumbleweed> it gets held in the queue https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<ahasenack> tumbleweed: does ubuntu-sponsors take into account it's an sru, with different rules? Or does only the ubuntu-sru team do that?
<tumbleweed> the sponsor is lending you their upload rights
<tumbleweed> so yes, they'll take SRU rules into account
<tumbleweed> but it's not within their right to accept the upload, it still needs SRU team approval
<ahasenack> tumbleweed: what if ubuntu-sponsors and ubuntu-sru don't agree?
<ahasenack> tumbleweed: I'm thinking it might make sense for the sru team to review first
<tumbleweed> what if an uploader and ubuntu-sru don't agree, it's the same thing
<ahasenack> tumbleweed: ah, I guess I have this different perspective because I'm not an uploader then
<tumbleweed> ubuntu-sru gets to make teh final decision, and not every SRU involves sponsorship
<cjwatson> ahasenack: if you try to make the sru team review things first, you will probably only slow things down for yourself.  it's easier for the sru team to review once it's in their queue
<Laney> we used to have a review-first workflow, and it was a big bottleneck
<ahasenack> ok
<ahasenack> ok, can you guys take a look at the bug and do a quick check if I subscribed the right team and so on, so that it's visible now?
<Kalidarn> hmm what's the best way to debug an ATI fglrx kernel panic.
<Kalidarn> and is it even possible with closed-sourced proprietary drivers.
<Kalidarn> i considered https://wiki.ubuntu.com/Kernel/KernelDebuggingTricks#Serial_Console
<Kalidarn> i do have http://www.tripplite.com/en/products/model.cfm?txtSeriesID=849&txtModelID=3914 but yeah.
<Kalidarn> or would it be recommended to follow this approach https://wiki.ubuntu.com/Kernel/CrashdumpRecipe
<Kalidarn> come to think of it #ubuntu-kernel is probably a better channel to ask in
<tjaalton> jbicha: heh, thanks for syncing the 389ds/freeipa bits from debian, beat me to it ;)
<Kalidarn> hmm not really any point in bothering to debug it, the error trace appearing on the screen is exactly the same as comment #4 of bug 750437
<ubottu> Launchpad bug 750437 in fglrx-installer (Ubuntu) "fglrx hard lockup on shutdown" [Undecided,Confirmed] https://launchpad.net/bugs/750437
<Kalidarn> which i guess there's little i can do about that.
<directhex> oh, i get that
<Kalidarn> yand it's damn annoyinga
<Kalidarn> cos my filesystems unmount uncleanly
<Kalidarn> i wonder if updating to the latest proprietary drivers might fix it.
<Kalidarn> my friend says he never has it happen with is card.
<directhex> the post-release fglrx option in jockey is broken
<directhex> doesn't install properly
<Kalidarn> hmm, yeah i'm using the ubuntu supplied fglrx driver
<johnp_> How do I add a folder choose widget in glade? There is one for file chooser only.
<Kalidarn> directhex: if it happens for you can you click "affects me"
<johnp_> How do I add a folder choose widget in glade? There is one for file chooser only.
<Kalidarn> johnp_: try in #ubuntu-app-devel
<PaoloRotolo> Hi all!
<cjwatson> Sweetshark: OK, sorry for the delay; attempting rebuild on radon now
<Sweetshark> cjwatson: thanks a lot
<mterry> barry, heyo.  I uploaded update-notifier trunk with a bad depend (python3-debian which isn't available) and didn't notice.  Is there a branch for the python3 port of that yet, or shall I look into making one?
<cjwatson> mterry: There's a Debian bug; I plan to NMU in the next few days
<cjwatson> mterry: (The Debian bug has an extensive patch series from me)
<mterry> cjwatson, awesome.  I figured someone had something ready to go, or the port of update-notifier wouldn't have hit trunk already
<cjwatson> It will take a little while though, so I suggest reverting to py2 for now
<cjwatson> Unless that's particularly painful
<mterry> hrm.  OK, will look
 * cjwatson thinks that landing things on trunk that would break if uploaded to the archive is distinctly unwise.
<slangasek> yep, sorry
<slangasek> I think when I landed it I assumed python3-debian was Coming Soon <tm>
<mterry> It's simple enough to undo.  Will upload shortly.  Sorry for not testing well enough!
<cjwatson> I missed the Debian freeze which won't help, so I may have to beg -release
<cjwatson> Hopefully will catch up on that tomorrow ...
<ScottK> Does the FSF position on GPLv3 and GRUB2 stated in https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper.pdf mean that the non-GRUB2 approach might be reconsidered?
<BenC> chrisccoulson: Are you planning to use the patches I sent you to get thunderbird building on ppc?
<jono> cjwatson, slangasek did you see https://www.fsf.org/campaigns/secure-boot-vs-restricted-boot/whitepaper-web ?
<chrisccoulson> BenC, sorry, only had a quick glance so far. but they both have fixes upstream too
<BenC> chrisccoulson: Then will you pull those fixes for quantal?
<chrisccoulson> BenC, the larger patch might introduce crashes, because it adds additional members to JSContext when ENABLE_ASSMEBLER is defined, but not every consumer of jscntxt.h defines that
<chrisccoulson> BenC, i'm not sure there's much point in backporting patches. we upgrade to the next version again in a couple of weeks, and then another version 6 weeks after that
<BenC> chrisccoulson: The large patch is the same one from precise, just fixes the merge conflicts
<chrisccoulson> BenC, right, there was a reason it's not in precise any more
<BenC> chrisccoulson: can it be conditionally applied for ppc only?
<micahg> well, the advantage is to enable PPC support again in the stable releases sooner
<chrisccoulson> it could, but we should just use the upstream fix
<chrisccoulson> but this doesn't solve the problem that every new firefox release fails to build on ppc
<BenC> chrisccoulson: I guess I'm still wondering when that will happen
<chrisccoulson> i honestly think we should just stop building firefox on ppc, and stick iceweasel or something in universe just for that
<BenC> chrisccoulson: And to that end, I have to ask, why the problem that plagued ppc-precise still affected ppc-quantalâ¦I remember it being said that would have it permanently fixed
<BenC> chrisccoulson: I would argue not to do that
<chrisccoulson> BenC, well, upstream don't support ppc, which means it's down to us to keep it going. so, most releases we push out won't build on powerpc
<BenC> The past two dev cycles, every time I try to get things fixed, the feedback is "it's fixed upstream"
<cjwatson> There is non-trivial complexity involved in building different sets of packages on different architectures - what you'd effectively be doing is outsourcing complexity to other people, but not really reducing the net complexity of Ubuntu overall - in fact very probably increasing it
<BenC> But then why isn't it upstream?
<chrisccoulson> BenC, powerpc is not an architecure that is supported by mozilla
<micahg> hrm, I thought with the patches in 15 PPC should start working again normally
<BenC> chrisccoulson: but you said it was fixed upstream, or upstream said it was fixedâ¦but it isn't
<BenC> I'm not asking about support, I'm just wondering why this "its' fixed upstream" never materializes
<chrisccoulson> BenC, yes, that particular problem is fixed upstream in the next version
<cjwatson> jono,ScottK: Yes, it came up on the internal uefi list - I don't know the answer yet but I certainly hope it means we can reconsider
<BenC> chrisccoulson: does that mean it will get into quantal?
<chrisccoulson> but each new version brings a new powerpc build failure
<BenC> chrisccoulson: The last build failure was super trivial
<cjwatson> but I'm not in a position to speak for Canonical or Ubuntu on it yet
<BenC> I fixed it in a couple lines of diff
<BenC> I'd hardly call that a problem worth dropping ppc for
<jono> cjwatson, understoof
<ScottK> cjwatson: OK.  Thanks.
<jono> understood
<BenC> chrisccoulson: Also, the fact is, I'm putting in the time and energy to keep ppc building, but it's all being tossed aside "because it will be fixed upstream" when it never shows up ubuntu
<micahg> chrisccoulson: if BenC is willing to help with PowerPC support, I'd like to take the fixes as distro patches (assuming they're sane)
<BenC> chrisccoulson: Can you just take my patches and have them apply conditionally for ppc and I'll continue to maintain them :)
<chrisccoulson> BenC, well, they do end up in ubuntu. but they end up alongside new issues
<BenC> chrisccoulson: That's falseâ¦there was only one new issue, and I sent you a super small patch to fix it
<stokachu> seb128: re bug #890928, does QA do anything to verify this or should I do some QA on it?
<ubottu> Launchpad bug 890928 in libxkbfile (Ubuntu Precise) "When trying to install libxkbfile1:i386 the pkg manager asks to remove too many important packages [Multi-arch]" [Low,Fix committed] https://launchpad.net/bugs/890928
<chrisccoulson> BenC, one new issue in this version. what about the next version? and the version after that?
<BenC> And if issues do arise, I will fix them as well
<BenC> I said that during precise dev, and my offer was ignored and the patch I worked on was dropped and ppc-precise has no working thunderbird/firefox :/
<BenC> All I'm asking is that my "community" effort be usefulâ¦it's kind of hard to justify people putting in community work if that work gets ignored and dismissed so easily
<chrisccoulson> BenC, sorry, i don't want you to think that i'm dismissing your effort. if you want to backport this change to apply to the current version in quantal, then i'll add it as a distro patch: https://hg.mozilla.org/mozilla-central/rev/f5a3a7b9c6b0
<chrisccoulson> (which is the version of your larger patch which was committed upstream)
<seb128> stokachu, not sure, check with the SRU team ( slangasek, SpamapS, RAOF, bdmurray, ScottK) what they require to validate it as SRU verified
<BenC> chrisccoulson: Excellent, will do, thanks. Should I email it when done, and if so, where is best?
<chrisccoulson> BenC, you can just use the same mail as before
<chrisccoulson> also, it might be worth trying to build a nightly every now and again. if you find issues there, it means it might be possible to fix it without having to carry patches :)
<BenC> chrisccoulson: Where is there info on the source for the nightly and how best to build it?
<chrisccoulson> BenC, you could probably just grab a package from https://launchpad.net/~ubuntu-mozilla-daily/+archive/ppa/ and try building that
<stokachu> seb128: will do thanks
<SpamapS> stokachu: I believe the comments suggest the way to enable proposed and verify the bug fix.
<stokachu> SpamapS: well i patched it and built it myself.. would you say thats enough then
<SpamapS> stokachu: it was already patched and fixed in precise-proposed .. it just needs testing
<SpamapS> stokachu: https://bugs.launchpad.net/ubuntu/+source/libxkbfile/+bug/890928/comments/17
<ubottu> Launchpad bug 890928 in libxkbfile (Ubuntu Precise) "When trying to install libxkbfile1:i386 the pkg manager asks to remove too many important packages [Multi-arch]" [Low,Fix committed]
<stokachu> SpamapS: right so it was missing an sru and https://bugs.launchpad.net/ubuntu/+source/libxkbfile/+bug/890928/comments/7 already stated it works
<SpamapS> stokachu: Not sure what you are saying there. We have to test the actual binaries in proposed.
<stokachu> is there a daily install build that tests installing x86 packages on 64bit
<cjwatson> Not that I can think of
<cjwatson> Make a chroot and try it
<stokachu> was thinking we could automate these without having to wait for someone to physically install the package
<cjwatson> It'd take ten minutes
<cjwatson> to just try it out by hand - no need to wait for the reporter
<cjwatson> Second time round it would take two minutes
<cjwatson> Especially if you left the chroot around for the next test
<infinity> schroot -c precise-amd64 -u root apt-get install blah?
<slangasek> stokachu: bug #890928> we shouldn't expect the QA team to do the verification here.  Per RAOF's comment #18, it looks to me that we ought to have some regression testing of the reverse-dependencies?  or at least some code inspection to make sure they're not doing stupid things like dlopen()ing the library?
<ubottu> Launchpad bug 890928 in libxkbfile (Ubuntu Precise) "When trying to install libxkbfile1:i386 the pkg manager asks to remove too many important packages [Multi-arch]" [Low,Fix committed] https://launchpad.net/bugs/890928
<infinity> Although, I need to write some hooks to enable/disable pockets and components.
<infinity> cjwatson: Do you have any fancy to do the above, or do you just log in and mangle sources.list?
<stokachu> slangasek: yea i mean this is more than just install the package and see if it croaks
<cjwatson> infinity: I just log in
<infinity> cjwatson: Yeah, me too.  If I find the motivation to automate that, I'll be sure to share.
<mhall119> highvoltage: would you like to do another workshop hangout with me tomorrow?
<mhall119> giving packaging support
<mhall119> it'll be mostly technical Q+A
<highvoltage> mhall119: yeah I'll try to be a bit more prepared too :)
<highvoltage> mhall119: what time?
<Daviey> slangasek: Hey, who is on point for signing off an SRU today?
<slangasek> Daviey: no one, because infinity is celebrating Canada's independence from Mexico
<infinity> Daviey: It would be me, but... See above.
<infinity> Daviey: If it's urgent, I can throw on a community hat and still care.  'Sup?
<mhall119> highvoltage: 1700 UTC
<Daviey> infinity: well, another team will want to do an update of a package tomorrow.. and they need to know if they should base it on the -proposed package or current release/-updates.
<infinity> Daviey: That's delightfully vague.
<Daviey> So, i need it ACK'd or NACK'd before tomorrow.
<highvoltage> mhall119: great. see you then.
<ScottK> It would be useful to know what "It" is.
<mhall119> highvoltage: cool, thanks
<stokachu> seb128: ok verified re: 890928
<spaetz> mmh, nouveau leads to a black screen with tons of errors in dmesg, and nvidia-current requires and old xserver-abi which is not available. All thin quantal
<spaetz> all this in quantal
<spaetz> and yes, I'll file a nouveau bug.
<seb128> stokachu, thanks
<stokachu> seb128: np :D
<seb128> is anyone using chromium on precise and could help to verify the SRU on bug #992352 so it can move to -updates?
<ubottu> Launchpad bug 992352 in chromium-browser (Ubuntu Quantal) "Please update to 18.0.1025.168" [Medium,Triaged] https://launchpad.net/bugs/992352
<stokachu> seb128: im running it with no problems
<seb128> stokachu, can you comment on the bug saying that?
<stokachu> yea lemme try on a fresh install again just to verify
<stokachu> seb128: ok done
<seb128> stokachu, thanks
<stokachu> sure ting
<stokachu> thing*
<spaetz> thanks, Timo Aaltonen for just uploading the fixed nvidia package :)
<spaetz> tjaalton: that would have been you, I guess. Thanks :)
<seb128> ev, cjwatson: could somebody in the installer team look at https://errors.ubuntu.com/bucket/?id=/usr/lib/ubiquity/bin/ubiquity:ValueError:watch_debconf_fd_helper:process_input:wait:cleanup:preseed:%3Clambda%3E:command
<seb128> it's in the most reported issues on e.u.c (645 report since yesterday)
<Dr_Who> infinity, ping
<micahg> Dr_Who: he's off today, you might want to use a more contentful ping
<Dr_Who> no worries , guessing me might be off this week
<micahg> which actually isn't bad advice in general :)
<Dr_Who> doko_, don't support you're around?  re: update for libjpeg-turbo
<micahg> really, the whole thing should just go into Debian (debian 612341)
<ubottu> Debian bug 612341 in wnpp "ITP: libjpeg-turbo -- an accelerated libjpeg library" [Wishlist,Open] http://bugs.debian.org/612341
<dobey> how do i see crashes on errors.ubuntu.com for a specific package version? i don't see any bugs in launchpad for it that are marked as dup on the main bug, and the hash links aren't helpful
<Dr_Who> micahg, quite the lengthy bug for something so simple but yes that's really the thing long term,  time to jump on that I guess
<micahg> Dr_Who: fabo is the owner there, maybe ask how you can help
<micahg> we've got time for quantal (just don't forget about it :))
<Dr_Who> micahg, yeah shall do. fabo was the one that picked up what I had done for ubuntu and was pushing to debian
<Dr_Who> but also would be nice to get what I have in q so it's at least there and really precise should be updated as well tho it's not the end of the world tho some have tripped over the lack of checking in jpeg headers which would be one reason to get the update into precise
<infinity> doko_: Your gcc-4.5 update reverted the armel bits from the previous upload.
<infinity> doko_: Specifically, http://launchpadlibrarian.net/108530671/gcc-4.5_4.5.3-12ubuntu2_4.5.3-12ubuntu3.diff.gz
<infinity> doko_: I'm going to re-apply that now, but you might want to get it in your Debian branch so it doesn't revert again.
<infinity> doko_: (Or add me to the appropriate alioth group and I'll do it myself)
<micahg> infinity: hrm, I thought Debian was killing gcc-4.5...
<infinity> micahg: Oh, indeed.  But I suspect doko still maintains ours in the Debian SVN. :P
<micahg> well, Debian fixed mysql, so, can we kill it :)
<micahg> "fixed"
<doko_> infinity, thanks, fixing for debian. please care about q
<cousteau> nvidia-96 is not installable because of broken dependency on xorg-video-abi-10 which doesn't exist on precise
<infinity> doko_: Already uploaded for Q.
<cousteau> (however I recall being able to install this on the live cd...  what happened?)
<infinity> micahg: Fixing MySQL by disabling the tests isn't much of a fix.
<micahg> infinity: hrm, I thought they built with 4.4 on i386 until it can be fixed
<infinity> micahg: Oh, I may have missed that development.
<micahg> cousteau: is there a bug?
<cousteau> yes, a non-existant dependency
<micahg> cousteau: no, I mean in launchpad, I see the issue :)
<cousteau> oh
<cousteau> Bug #948053 and Bug #941325
<ubottu> Launchpad bug 948053 in nvidia-graphics-drivers-173 (Ubuntu Precise) "nvidia-96 and nvidia-173 uninstallable on Precise" [Medium,Confirmed] https://launchpad.net/bugs/948053
<ubottu> Launchpad bug 948053 in nvidia-graphics-drivers-173 (Ubuntu Precise) "duplicate for #941325 nvidia-96 and nvidia-173 uninstallable on Precise" [Medium,Confirmed] https://launchpad.net/bugs/948053
<cousteau> also there's a bug on ubottu when reporting 2 bugs on the same --er never mind
<cousteau> 2nd line was the same as 1st one but it said "duplicate"
<micahg> bryceh: ^^ can you poke tseliot about that?
<slangasek> Sweetshark: I'm trying to see if I can spot the problem with bug #1017125, but I don't think I have enough context for how to run this test case - maybe you could pass me a binary I could use for reproducing?
<ubottu> Launchpad bug 1017125 in LibreOffice Productivity Suite "LibreOffice crash in xmloff.Impress.XMLContentImporter::com::sun::star::document::XImporter with gcc-4.7" [Medium,Confirmed] https://launchpad.net/bugs/1017125
<slangasek> Sweetshark: also, the upstream bug only shows backtraces from before your latest change... would be good to have the current backtrace when building without cxx0x, which we know we have to do
<seb128> slangasek, not sure but I think the builds are on https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/+packages
<ignacio_> hola
<bryceh> micahg, will do
<hallyn> so i'm looking into FTBFS for nvidia-settings.  if i dpkg-source -x then debian/rules build, it works.  but if i dpkg-source -x then debian/rules build-arch, it fails.  there is a build: rule which explicitly builds a needed .a file.  there is no build-arch rule
<hallyn> i don't know the right way to fix this.  do ijust add a build-arch rule which builds that .a file then does dh build-arch ?
<micahg> hallyn: maybe it should be broken out to its own rule rather than duplicated
<infinity> hallyn: It just sounds like debian/rules has some ordering issues, then.
<hallyn> ok, i guess at this point i'll just open a bug.  revisit it when i get back thursday if it hasn't been addressed by the maintainers
<micahg> shouldn't build be called before binary-arch?
<hallyn> there is a binary-arch rule, but this is build-arch
<hallyn> is there a list of the predefined targets and their order?
<hallyn> i suppose i can do a libSTAMP
<infinity> hallyn: The problem is that they inserted at the end
<infinity> %:
<infinity>         dh $@
<infinity> hallyn: So, for build, it's calling the explicit build rule, for build-arch, it's calling the implicit build rule.
<infinity> hallyn: The quick fix would just be a "build-arch: build" rule.
<cousteau> not sure if perl or makefile...
<infinity> hallyn: (more correct is probably renaming build to build-arch, and then making build: build-arch.
<infinity> )
<hallyn> hm ok
 * infinity tests this.
<infinity> I'll just upload if this works. :P
<micahg> :q
<micahg> oops
<micahg> infinity: that package wouldn't fly in Debian as the binary name is created at build time
<micahg> do we have a similar rule?
<infinity> The part where it ships random binary blobs doesn't concern you?
<micahg> well, that's by design isn't it?
<infinity> micahg: The package name is created at clean time, not build time.
<infinity> micahg: So, assuming the uploader cleans before building, debian/control is right.
<micahg> infinity: it's done both times from what I can tell :P
<infinity> micahg: There's no policy against control.in, it's in half the desktop packages (though, not used this way).
<infinity> micahg: Well, sure, it's re-done, since that's the joy of running clean during the build, but whatever.
<infinity> Oh, and I see, build-arch also depends on the same target.  That's just sloppy.
<infinity> But whatever.
<micahg> infinity: there are certain rules, no mangling build-dependencies, and I just saw that binary names shouldn't change either
<micahg> no mangling during the build that is
<infinity> micahg: Sure, so the only real bug here is that that's done twice.  But it's a harmless bug, at least.
<micahg> infinity: assuming clean was run before uploading
<infinity> micahg: Right, but every control.in-using package assumes that.
<infinity> micahg: (Which I'd prefer wasn't the case, but it's rather common)
<micahg> that's fine as long as the build doesn't mangle it though :)
 * micahg still wonders why MOTU is the maintainer for a restricted package :)
<StevenK> RAOF: Wow, a Xid error without my screen becoming unusable.
<RAOF> Yeah, they do happen.
#ubuntu-devel 2012-07-03
<slangasek> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | 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: slangasek
<psusi> slangasek, say, why does loading vesafb preclude switching to the proper drm/dri driver later?
<slangasek> psusi: because there's no race-free way to switch between them in the kernel
<psusi> slangasek, howso?  iirc there was support for unloading a console driver, then loading a new one...
<slangasek> that's about as precise an answer as I can give you, I haven't looked deeply at the problem
<psusi> hrm... guess I'll take a look at it... it seems like you should be able to load the plain old fashioned vga16 driver then switch later.. last time I was poking around the generic console code it looked like it was designed to handle switching drivers like that
<larsduesing> good morning slangasek :)
<slangasek> larsduesing: good evening. :)
<slangasek> psusi: so yes, the console code is designed to support switching, but a) IME this hasn't actually worked for a while, b) the framebuffer code is another matter entirely, and fbcon has its hooks into the framebuffer device
<larsduesing> slangasek: could you have a look at https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1007408 please?
<ubottu> Launchpad bug 1007408 in aiccu (Ubuntu Precise) "aiccu.conf does not need server directive, while upstart script wants it" [Undecided,New]
<slangasek> sure, let's see
<larsduesing> cool, thanks :)
<psusi> slangasek, iirc, you would have to shut down fbcon, then vga16/vesafb, which it depends on, leaving you with the default null console, then load the new proper dri driver and then reload fbcon bound to that
<slangasek> psusi: if you manage to do this I would be interested to see it; I'm still not sure it would be sane to do it in Ubuntu by default, but I have a myth box I'd like to be able to use it on
<slangasek> psusi: don't forget that X and plymouth will both also try to use the framebuffer
<psusi> slangasek, yea... not something you can do after they load...
<psusi> would need to make the switch first
<slangasek> well, so then you're waiting until you've made a determination (via udev) that there's no better driver before you do anything useful with the console, so what's the point :)
<slangasek> not the console technically, but the fb
<psusi> well, you wouldn't load vesafb unless you need to drop to the initramfs prompt, then you can unload it if/when you continue
<slangasek> ah
<psusi> yea, this is just for the initramfs emergency shell, no need to bother unless the shit hits the fan
<psusi> err... fecal matter hits the rotary air impeller
<infinity> I'm highly insulted.
<psusi> ;)
<Jagst3r15> in 12.10 what will the gnome option be called
<Jagst3r15> like on the login screen will it say GNOME 3.5.X?
<slangasek> larsduesing: so you note in this bug that the impact is "medium to low", which would normally exclude it from an SRU according to https://wiki.ubuntu.com/StableReleaseUpdates.  Do you want to revise your impact statement, or should the SRU be withdrawn?
<larsduesing> oh
<larsduesing> second...
<larsduesing> so this won't be a SRU? James Page told me to do a SRU...
<psusi> slangasek, ohh, did you think I was getting at being able to have plymouth display the splash screen during the initramfs without including the proper dri driver?  I was just thinking about the emergency shell not showing up
<larsduesing> "crashing on startup" if someone deletes something in the config... First part is high impact - but second one... ahem... tough luck *g*
<larsduesing> so, no SRU in your opinion?
<slangasek> larsduesing: well, my personal opinion is that it probably shouldn't be an SRU; but if you think it's high enough impact that it should be, I'll sponsor it, I just want you to stand behind it :)
<slangasek> and if jamespage said it should be SRUed, that's certainly a point in favor
<larsduesing> Ok, lets wait a little bit...
<slangasek> what are we waiting for?
<larsduesing> I'm reading wiki about SRU
<slangasek> ok
<larsduesing> again
<larsduesing> and think about it all..
<slangasek> ok then :)
<Jagst3r15> hmm, you guys know where i'd inquire about including the latest build of chromium into 12.10?
<Jagst3r15> the package for 12.10 is only 18.xxxxx
<larsduesing> pro: it doesn't accept legal config-files. con: rarely anyone should run into it...
<larsduesing> PRO: Bugs which do not fit under above categories, but (1) have an obviously safe patch and (2) affect an application rather than critical infrastructure packages (like X.org or the kernel).
<larsduesing> slangasek: it files under that. aiccu is not critical infrastucture :) (ok, for us it may be... but for the normal user...)
<RAOF> larsduesing: Is acciu in Universe? We're less conservative there.
<slangasek> I'm not ;)
<RAOF> By policy, we're less conservative there :P
<larsduesing> ir is
<RAOF> Or perhaps I'm
<larsduesing> ik
<RAOF> ...misremembering policy?
<larsduesing> argh
<larsduesing> cat
<larsduesing> it is
<larsduesing> and patch is obviously safe: rather to stop starting it does set a default
<slangasek> larsduesing: have you reached a verdict? :)
<larsduesing> yes
<larsduesing> it matches clearly the above part
<larsduesing> in my opinion
<micahg> Jagst3r15: not available ATM AFAIK
<slangasek> larsduesing: ok, will sponsor it - thanks for thinking it through
<larsduesing> "This line-cut was proudly sponsored by Deutsche Telekom AG" *grr*
<larsduesing> thanks slangasek
<larsduesing> should I add the category it will fit in my SRU-Comment?
<vibhav> j #ubuntu
<vibhav> Is there any page for listing packages which have to be transitioned to dh_python2 ?
<slangasek> larsduesing: don't worry about it
<slangasek> vibhav: any package that still depends on python-support or python-central should be transitioned; however, aside from packages in main, we generally don't diverge from Debian on this because it increases the maintenance burden and not all Debian package maintainers have agreed to migrate to dh_python2
<slangasek> vibhav: and for main, the transition is already done
<StevenK> slangasek: The maintainers haven't agreed because they like pain?
<dholbach> good morning
<pitti> Good morning
<Sweetshark> moin!
<Sweetshark> slangasek: i dont think I can pass around a binary easily, the test cases have to run from a build (and are not packaged)
<Sweetshark> slangasek: I guess it is easiest still you get https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/+sourcepub/2537780/+listing-archive-extra and build it (overnight for example)
<slangasek> Sweetshark: extract the test case from your build tree and post it somewhere? :)
<slangasek> yeah :/
<slangasek> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | 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:
<Sweetshark> slangasek: no easy extracting this: it is a junit test remotecontrolling LibreOffice via UNO-API ....
<dupondje> slangasek: you take a look at the cryptsetup sync when you are bored ? ;)
 * dholbach hugs slangasek
<slangasek> dupondje: hmm, did you see my response on IRC to your last question?
 * slangasek hugs dholbach and slinks off toward bed :)
<Sweetshark> slangasek: and the test is started from inside the buildsystem (expecting the build, not only an install  to be there)
<slangasek> dupondje: we shouldn't sync it unless you're going to add full conffile upgrade handling to the package in Debian... and I don't see why you've changed the names of the upstart jobs in Debian anyway, wouldn't it be better to just make the Debian package use the names that are already in use in Ubuntu?
<Sweetshark> slangasek: :) good night then
<slangasek> Sweetshark: so I posted a reply on the list with some suggestions on how to go about debugging this... maybe that'll help you
<dupondje> slangasek: must have missed it :)
<Sweetshark> slangasek: cant see it yet on the list archive.
<dupondje> and dh_installinit can only handle <packagename>.upstart/.init
<dupondje> so if we want to install .upstart OR .init, we need to it give it the same name OR handle it in debian/rules, which isn't that clean
<dupondje> anyway :) enjoy your night
<xnox> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | 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: xnox
<xnox> dholbach: I am not a member of the ~ubuntu-sponsors. Would you please, please, add me? or maybe add ~ubuntu-core-dev to that one?
<dholbach> added you :)
<xnox> dholbach: \0/ yeah
<xnox> thanks ;-)
<larsduesing> ah, dholbach: short question, is it somehow possible to add the irc-nicks of the pilots to the calendar?
<dholbach> larsduesing, generally that'd be possible, but I'd need to change my pilot schedule script a bit for that
<dholbach> I'd need to write down in the code which mail address is tied to which irc nick
<larsduesing> dholbach: it's just a suggestion, as I stumbled over the names from time to time
<dholbach> I'll note it down in my TODO
<larsduesing> thanks :-)
<dholbach> didrocks, do you think you can join #ubuntu-arb again? :
<dholbach> :)
<didrocks> oooopsss
<didrocks> sorry, got stuck on the unity release
<didrocks> coming
<xnox> pitti: is it possible to set ProblemType when running $ apport-cli --save -p binarypackagename
<xnox> pitti: in particular due "if report['ProblemType'] == 'Package':" part of the source package hook is not run
<pitti> xnox: you can't change ProblemType in the CLI, but you can hack the .crash file, of coursr
<pitti> xnox: what prevents running the source package hook?
<xnox> pitti: I wrote the hook locally, I built the package, I installed the package, I want to run $ apport-cli --save -p mybinarypackage as it would by apport and I noticed that by default apport-cli didn't set ProblemType
<xnox> pitti: not really me, I am sponsoring an update / change to the source hook
<xnox> pitti: not really me, I am sponsoring an update / change to a source hook
<pitti> xnox: it sets it to "Bug"
<pitti> or, it ought to
<xnox> pitti: ok, when is 'Package' ProblemType set?
<pitti> xnox: that's done by apt (or dpkg, not sure), when a package fails to install or upgrade
<pitti> xnox: as I said you can vi the saved .apport file to change it
<xnox> ok...
<hrw> can someone hint me why my quantal reports as Debian for 'lsb_release -a'?
<pitti> it doesn't here, and is not supposed to
<pitti> hrw: dpg -s base-files ?
<pitti> dpkg even
<hrw> pitti: just resintalled base-files to 6.5ubuntu7
<pitti> conffiles are magic, though; if your /etc/lsb-release is modified locally, reinstalling won't restore it
<infinity> Or if it's been deleted.
<infinity> If it's done, lsb_release does, indeed, default to Debian.
<infinity> s/done/gone/
<infinity> hrw: dpkg -i --force-confmiss base-files.deb
<hrw> thanks
<hrw> restored it by hand
<infinity> We might want to mangle our copy of lsb-release to at least lie more creatively when the conffile is gone.
<hrw> ok, back to rebuilding cross toolchain
<saurabh> Hello, I have created a project and setup a ppa on launchpad. I am using quickly to create my application. But when I try to push the code to launchpad, it created 12.07 version instead of 0.1 version
<saurabh> can somebody help me to resolve this issue?
<pitti> sounds like "July 2012"
<pitti> didrocks: ^ do you know if that's intended?
<didrocks> yeah, it's the way Quickly is versionning apps
<didrocks> saurabh: ^
<saurabh> ok
<saurabh> how can change it to 0.1?
<didrocks> saurabh: when you quickly release, you can quickly release <version>
<saurabh> ok didrocks. thanks
<didrocks> yw :)
<saurabh> one more thing
<didrocks> saurabh: this discussion should rather be on #quickly btw :)
<saurabh> I have already tried there
<saurabh> in quickly, launchpad and also in ubuntu
<saurabh> but din't get the answer there
<saurabh> didrocks, I'm getting a warning while packaging my app
<saurabh> Hello, I have created a project and setup a ppa on launchpad. I am using quickly to create my application. But when I try to push the code to launchpad, it created 12.07 version instead of 0.1 version
<didrocks> saurabh: well, it was 2 minutes before you asked here, you can't expect people answering immediately on all channels
<saurabh> sorry, worngly pasted
<saurabh> ** (setup.py:5585): WARNING **: Error sending credentials: Error sending message: Operation not permitted
<didrocks> saurabh: let's continue on #quickly, this channel is not for application development
<saurabh> ok didrocks
<xnox> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | 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:
 * xnox should have done that before going to lunch, not after
<edlerk> I have just produced my first ubuntu package (.deb file) and am a little confused on how to submit it for possible inclusion in ubuntu. Is there a document which will walk me through this process?
<edlerk> I used "https://wiki.ubuntu.com/PackagingGuide/Complete#Introduction" to learn to make the package.
<xnox> edlerk: if it is a bugfix or an update to an existing package you can either submit a merge proposal against lp:ubuntu/$package or you can file a bug on launchpad against the package and attach a debdiff
<cjwatson> https://wiki.ubuntu.com/SponsorshipProcess
<xnox> edlerk: if it's a new package, you will need to upload .dsc & the tarballs to any http/ftp location or simply attach to a bug
<cjwatson> https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages
<xnox> cjwatson: do we have ubottu command to print all of the above? =)
<edlerk> xnox: it is just a simple program packaged from scratch. Okay. I will read the docs.
<xnox> cjwatson: or is it a short irc marco that you run? =)
<cjwatson> er I typed the first into my browser to check it and then copied and pasted
<cjwatson> the second is linked from the first
<xnox> !packaging
<ubottu> The packaging guide is at http://wiki.ubuntu.com/PackagingGuide - See https://wiki.ubuntu.com/UbuntuDevelopment/NewPackages for information on getting a package integrated into Ubuntu - Other developer resources are at https://wiki.ubuntu.com/UbuntuDevelopment - See also !backports and !sponsoring
<jbicha> edlerk: what software did you package?
<edlerk> jbicha: I packaged something called "ft232r_prog" (http://rtr.ca/ft232r/).
<edlerk> jbicha: It is for setting the eeprom contents of USB devices. Very useful if you are manufacturing your own hardware...
<jamespage> sbeattie, whats happening with the update of openjdk-6 in Lucid?
<edlerk> jbicha: Should I send Aurelien Jarno an email?
<edlerk> jbicha: I just sent him an email. Thanks.
<ev> mpt: so to be clear, you're happy for the apport window to disappear if the application becomes responsive again?
<edlerk> jbicha: I also sent him a copy of the package and its friends.
<edlerk> jbicha: Okay bye. I need to do more soldering...
<seb128> infinity, hey, do you plan to do your SRU review day you missed yesterday today? ;-Ã 
<seb128> ;-)
<stgraber> micahg: I know you'll notice, so sorry for the resolvconf merge without -v... my ctrl+c skills weren't good enough to kill the upload when I noticed I didn't pass it
<stgraber> should someone be actually interested, the full changelog is: http://paste.ubuntu.com/1073112/
<mvo> ev: is there something like http://errors.ubuntu.com/by-package/software-center ? instead of having to type it manually in the input field?
<ev> mvo: not yet. I've just created https://bugs.launchpad.net/errors/+bug/1020580 for it
<ubottu> Launchpad bug 1020580 in Errors "Permanent URLs for most common problems view" [Undecided,New]
<mvo> ev: awsome, thanks
<mvo> ev: its really minor, just a nice to have to include e.g. in a team report mail
<ev> mvo: shouldn't be too hard, and I'd love to have it as well :)
<mvo> :)
<highvoltage> stgraber: should I file a UI freeze exception for ldm-themes so long or should I assume that the design team is going to get the artwork in on time this time?
<highvoltage> stgraber: speaking of which, I screwed up and made the debian version a lot higher, so now we have the debian themes in Ubuntu... I'll at least get that fixed so long
<ScottK> highvoltage: Don't file for a UI freeze exception now.  Wait until something doesn't make the deadline.
<ScottK> If someone already knows they won't make it, they're doing it wrong.
<highvoltage> ScottK: ok, that sounds completely rational.
 * Laney wonders why he got an email to openstack-packaging
<robbiew> cjwatson: just updated quantal...interesting grub2 background
<robbiew> :)
<cjwatson> hm?  I didn't knowingly change anything
<cjwatson> Perhaps you have desktop-base installed
<cjwatson> mterry: Did you see bug 1020462 and bug 1020526
<cjwatson> ?
<ubottu> Launchpad bug 1020462 in ubuntu-release-upgrader (Ubuntu Quantal) "Precise to Quantal upgrade failed: do-release-upgrade -d failed with ImportError: No module named janitor.plugincore.manager in DistUpgradeQuirks.py" [Critical,Confirmed] https://launchpad.net/bugs/1020462
<ubottu> Launchpad bug 1020526 in update-manager (Ubuntu Quantal) "Software Updater crashes with: AttributeError: '_io.BufferedRandom' object has no attribute 'encoding' in MetaRelease.py, line 217, in parse" [High,Confirmed] https://launchpad.net/bugs/1020526
<highvoltage> ah yes that would give him the debian "joy" theme :)
<cjwatson> mterry: I was thinking of http://paste.ubuntu.com/1073223/ for the second one, but I haven't been able to reproduce the bug as reported yet
<highvoltage> like you'd get on ltsp with the current 'ldm' themes. that could really confuse someone :)
<cjwatson> Well, I could reproduce the missing do-partial-upgrade part of it, but not the crash
<seb128> bdmurray: hey, since you are off thursday, is there any chance you would do a SRU review round today?
 * seb128 has the feeling it will be hard to get SRU reviews this week ;-)
<mterry> cjwatson, I saw you assign the upgrader one, thanks.  The metarelease.py one I hadn't seen
<bdmurray> seb128: is there something specific you would like me to look at?
<seb128> bdmurray: hey, from an errors.ubuntu.com "target top issues" perspective ubuntu-sso-client and software-center, otherwise the recent unity-lens-video is a trivial 1 liner over the SRU from yesterday to fix a case which was not covered in the previous fix
<seb128> bdmurray: ubuntuone-client seems like a good one as well then if you still have time for SRU
<seb128> bdmurray: thanks ;-)
<seb128> gwibber could be good as well ... and I will stop there :-)
<robbiew> cjwatson: hmm, so I didn't purposely install desktop-base...but I can check...this machine went through a pretty crazy upgrade path lastweek (natty->oneiric->precise->quantal), so who knows :)
<cjwatson> It does occasionally get accidentally installed, despite being in universe
<robbiew> ah, cool
<robbiew> cjwatson: yep...that was it, thnx!
<cjwatson> np
<dupondje> heh, somebody forgot to remove [ Merge-O-Matic ] from his changelog
<nigelb> ev: "It's really fantastic. Very impressed." -- from a friend re: 12.04 installer :)
<ev> nigelb: thanks. Credit goes to everyone in #ubuntu-installer though. I barely touched it in 12.04
<ev> nigelb: my focus was then and continues to be http://errors.ubuntu.com :)
<nigelb> ah! Nice :)
<mterry> cjwatson, I can reproduce that update-manager crash by running "nosetests3" in update-manager trunk.  This is a new exception for some reason.  But your patch does fix it
<bdmurray> mvo: I'm looking at software-center in precise-proposed and a couple of bugs don't seem to be fixed in quantal
<bdmurray> bug 970627 and bug 971776
<ubottu> Launchpad bug 970627 in software-center (Ubuntu Precise) "expunge-cache.py crashed with IOError in _cleanup_dir(): [Errno 2] No such file or directory: '/home/username/.cache/software-center/piston-helper/rec.ubuntu.com,api,1.0,recommend_app,multiget,,2442bcf345374a73360143bd52431ab5'" [Medium,Fix committed] https://launchpad.net/bugs/970627
<ubottu> Launchpad bug 971776 in software-center (Ubuntu Precise) "software-center crashed with GError in constructor(): Format der Bilddatei unbekannt" [Medium,Fix committed] https://launchpad.net/bugs/971776
<mhall119> highvoltage: you ready for the hangout workshop in about 10 minutes?
<highvoltage> mhall119: will be in around a min
<vibhav> What is the concept of having a seperate debian/control.in?
<mterry> vibhav, some fields in it are generated (like @GNOME_TEAM@) and put in the real debian/control
<vibhav> ah
<jcastro> xnox: hey are you still going to try some archive rebuild madness on hp cloud? (please say yes!)
<xnox> jcastro: i'm listening
 * xnox is setting things up to launch one
<jcastro> yeah just take good notes, I am interested in how well it'll perform, etc.
<xnox> jcastro: ok.
<jcastro> if you could like time it or something measurable
<jcastro> I am interested if it's possible to see how much faster it'll be on these new servers than our typical resources
<xnox> jcastro: given the size of their instances I wonder if it can be done in less than one hour excluding libreoffice
<jcastro> heh, yeah.
<xnox> jcastro: the golden rule of archive rebuilds - always exclude libreoffice ;-)
<smoser> anyone else believe that firefox generally leaks memory? i've disabled just about all my plugins (other than pentadactyl that i can't live without) and it seems to grow in footprint over time.
<jcastro> xnox: is it possible to parallelize it? like split it into 3 parts on 3 different instances?
<micahg> smoser: each release it gets better
<xnox> jcastro: split what? the libreoffice build?
<smoser> micahg, personally, this one seems worse (precise)
<jcastro> xnox: the entire rebuild I mean
<micahg> xnox: you can't rebuild everything in one hour, on the grid 5000, a total rebuild took 8 hrs
<smoser> micahg, but you're suggesting it is at least accepted that it leaks. which saves me from proving it.
<xnox> micahg: grid 5000 only gave lucas ~100 instances
<micahg> smoser: yes, along with most other applications
<xnox> micahg: on HPCloud they have 8-core & 32RAM instances
<xnox> micahg: on HPCloud they have 8-core & 32 GB RAM instances
<micahg> xnox: you're still blocked on build time :)
<jcastro> xnox: ok so there's your baseline .... 8 hours. See if you can beat it. :)
<xnox> micahg: yeah, hence excluding libreoffice
<micahg> xnox: libreoffice isn't the worse thing time wise IIRC
<infinity> xnox: 8 cores isn't interesting.  How many of those instances are you using?
<smoser> well... most applications probably leak, but no other app both a.) do i run all day and use heavily and b.) leak memory in the dozens of megabytes per hour range.
<xnox> infinity: i'm fighting with juju, I will let you know as soon as I get plenty instances
<xnox> smoser: chromium is slightly better
<infinity> xnox: Not in my experience. :P
<micahg> smoser: https://wiki.mozilla.org/Performance/MemShrink#Bug_Tracking, feel free to file bugs if they aren't filed already if you have reproducers
<infinity> xnox: chromium just fools you into thinking it's better because no one can do basic arithmetic to add up all the processes.
<micahg> hehe
<xnox> infinity: LOL
<xnox> chromium generally uses MORE memory, but in my experience it LEAKS LESS
<xnox> in my usage anyway
<smoser> micahg, thanks. xnox, maybe, but chromium has no pentadactyl. so its not an option
<jcastro> xnox: the openstack provider hasn't landed yet for juju, if you plop over on #juju we can give you a hand.
<xnox> so it is rather under control.
<slangasek> infinity: to be fair, it does tend to overflow the register
<slangasek> so it's not entirely basic arithmetic
<xnox> jcastro: ok. But it does kinda work with canonistack for example
<smoser> but, thanks for the verification, micahg and xnox
<jcastro> xnox: yeah we turn on things they don't, which is why you need the native provider
<xnox> =(
<alazare619> hey anyone here have any ideas how to create an entire chroot enviorment say with like debootstrap but have a certain user who connects via ssh go into that chroot (for development purposes as they require a sudo password to run some commands)
<mterry> pitti, btw, test suites of trunks of update-manager and ubuntu-release-upgrader seem to work fine in a chroot now, so presumably will work on jenkins
<jtaylor> alazare619: thats not very safe, you can escape chroots quite easily
<alazare619> i did a vm server and port forwarded it to a vbox jtaylor but it kept on disconnecting the vbox session
<alazare619> what other options do i have?
<jtaylor> maybe a lxc container, but I don't know much about these
<roaksoax> jdstrand: howdy! I'm looking for your input as part of the MIR team. For MAAS, one of the targets is to remove yui3 from maas source. I've been working with the debian maintainer for it, and we now have it in Ubuntu. He has patched the source package to include the source files to build a couple *.swf files shipped in yui3. However, this has added a build-dep on swftools, which is in universe.
<roaksoax> jdstrand: swftoosl build-deps on libmp3lame-dev (from the lame source pacakage). So this means that in order to MIR this, we would need swftools and lame MIR's. Do you thin this is feaseable? Or, do you think I should remove the *.swf files from yui3 source and make it a dfsg package?
<micahg> it's already dfsg if you're building the .swf files from source :)
<roaksoax> micahg: right, but I mean repack the source and make it +dfsg
<micahg> there's no need for that if the source is provided AIUI
<jdstrand> roaksoax: hey. otoh I would suggest just removing the swf files. I'm guessing you don't use them, so I'm not super keen on pulling in these things just for a build-dep
<roaksoax> micahg: if drop DM's patch and remove the *.swf it because a repacked source including +dsfg
<roaksoax> s/because/becomes
<roaksoax> jdstrand: ok, will do so. Thanks for the input
<micahg> roaksoax: you can keep the patch and just not build the .swf files :)
<micahg> that should keep the diff lower
<roaksoax> micahg: good point!
 * micahg sees the patch adds the source, not the logic to build
<roaksoax> micahg: yes, the logic to build is in the rules files obviously
<micahg> roaksoax: just make sure you don't end up installing the upstream .swf files either :)
<OdyX> doko: are you coming to DebConf ? I'd like to handle the lsb sync from Debian (I'm planning to finish the testsuite and python3 port during DebCamp).
<OdyX> doko: â¦ to handle the lsb sync (â¦) in collaboration with you, preferably f2f.
<infinity> OdyX: He is.
<OdyX> infinity: cool, thanks.
<dobey> hrmm
<dobey> is there a way to force dh to use a specific build system, if multiple are in use?
<jtaylor> --buildsystem
<dobey> jtaylor: thanks. is there some easy way to see what it's doing exactly for cmake? is *all* the logic in the dh_auto_configure script?
<jtaylor> export DH_VERBOSE=1
<dobey> ah right
<dobey> hrmm, it isn't printing the exact cmake command though :-/
<micahg> roaksoax: I think we've been using yuicompressor rather than uglify to accomplish the same task
<micahg> technically since it's MIT, you can get away with what you did
<roaksoax> micahg: right, upstream ships a -min.js library which for some reason was not being included in the source when the debian maintainer packaged it
<roaksoax> micahg: so it made no sense to build one in packaging
<micahg> roaksoax: right, because, that's not the preferred form of modification
<ScottK> roaksoax: minified javascript is not considered source.
<micahg> ScottK: I thought that was license dependent
<roaksoax> ScottK: some libraries do ship minified javascript
<ScottK> Those are buggy from a Debian policy POV.
<micahg> roaksoax: that's not what he means :)
<ScottK> Just because the license allows it, doesn't make not providing source DFSG free.
<roaksoax> ScottK: right, but the minified version is distributed with the source
<ScottK> Effectively, you need to provide preferred form to meet DFSG even if the license doesn't require it.
<roaksoax> ScottK: i'm just adapting to what the maintiner did.
<ScottK> roaksoax: We strip pre-compiled binaries out of upstream source all the time.  This is the same thing.
<micahg> roaksoax: no adapting would be using yuicompressor instead of uglify, you basically reverted the removal of the non-source
<ScottK> Figure out what it's a minified version of and then depend on the appropriate javscript library.  It's probably in the archive.
 * micahg apologizes for the misinfomation earlier
<ScottK> dh_sphinx is super cool about handling this for sphinx based docs.
<roaksoax> ScottK: so these means an archive cleanup in debian would need to be done as other packages do ship minified versions
<roaksoax> such as YUI3
<ScottK> roaksoax: It is in progress.
<ScottK> There are lintian warnings about it now and eventually it'll be bugs.
<roaksoax> ack
<ScottK> It's a large mess that won't get fixed overnight, but in the meantime, don't make it worse.
<micahg> well, yui3 has both the minified versions and the full source shipped
<micahg> *in binary form as well
<ScottK> That's OK, although what's shipped in the binary package should be rebuilt.
<Daviey> slangasek: I seem to remember you were involved with DFSG discussion around packages which were Public Domain?  Was that right?
<slangasek> uh... possibly
<Daviey> slangasek: I failed to remember the outcome.. is it fit for universe/main ?
<slangasek> true public domain works are always free
<infinity> Daviey: Public domain is perfectly free.  The problem comes in with some countries that stubbornly insist that you "can't" put a work in the public domain.
<ScottK> Emphasis on the true.
<Daviey> i thought in some countries it meant it was actually non-free?
<infinity> Daviey: As long as we have a strong statement from the original copyright-abandoner, I do believe we tend to just ignore those countries and their silliness.
<slangasek> however, some licensors fail to use the term "public domain" correctly and make conflicting statements in their own license grant, in which case the "public domain" statement should be ignored
<slangasek> Daviey: the issue is that, in *most* countries, there's either no such legal doctrine as "public domain", or there's no process for a copyright holder to make a public domain grant of a work
<infinity> (There's actually a creative commons "as close to PD as you can get while still technically retaining copyright" license that tries to work around the weird places where you "can't" give up copyright)
<slangasek> where the intent is clear, it should be sufficient to let it in as-is provided we also follow up and ask them for a clarifying license grant
<Daviey> http://pb.daviey.com/PrwT/
<slangasek> ("clarifying" in the sense that it will stand up in court, even though we and they both already know what they mean)
<Daviey> PKG-INFO from upstream seems pretty clear
<Daviey> (yes, i know it's not a versioned dep-5 spec)
<slangasek> Daviey: wrong license on the debian/* files, should be GPL-3 ;)
<ScottK> Also this can't be right:
<ScottK> Copyright: 2012 Yannick Gingras
<ScottK> License: Public domain
<ScottK> It's have to be Copyright: None, wouldn't it?
<Daviey> ScottK: Well can you work out how to do it via dep-5?
<Daviey> hmm
<ScottK> Daviey: I manage it fine by ignoring DEP-5.
<tumbleweed> Daviey: start with the basics. Work out what the author meant
<infinity> Daviey: Copyright "None" or "Public domain" would be correct.  PD, by definition, means no copyright.
<Daviey> yeah
 * Daviey rejects.
<infinity> (Which is why it breaks in some countries, where original artists *always* retain copyright, legally)
<slangasek> Daviey: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ (DEP-5 was the draft), and yes, you can: there's verbiage in the spec about what to put in "Copyright" for PD works
<Daviey> slangasek: I think it'll forever be called DEP-5 :)
<Daviey> i see it should also be, Licence: public-domain
<slangasek> if it's meaning to be compliant with the spec, yes
<Laney> License ;-)
<Daviey> slangasek: What is the point in specs if it's not adhered to? :)
<slangasek> Daviey: getting DEP-5 syntax wrong is not grounds for rejecting a package from the archive
<Daviey> Laney: well spotted
<slangasek> claiming that something is both copyrighted and public domain is
<Laney> that always stands out to me
<Daviey> slangasek: No, but the Copyright: None is, right?
<galfly> hi everyone. How can I make changes to a package and test it locally? I downloaded the source but when I try to configure and make, I get a long list of errors
<Daviey> slangasek: Right, so i've made suggestions that the other parts are changed, but the Copyright: None is essential.
<slangasek> sounds good
<slangasek> galfly: package builds are controlled through the makefile called debian/rules; you can call it as a script, as in 'debian/rules build' or 'fakeroot debian/rules binary'
<roaksoax> micahg: does this satisfy your concerns? http://paste.ubuntu.com/1073845/
<micahg> roaksoax: looks great (and mirrors the other JS stuff in main)
<galfly> slangasek: I will try that. Thank you so much.
<jdstrand> tumbleweed: fyi, --install-layout=deb did the trick. thanks!
<seb128> barry, hey
<barry> hi seb128
<seb128> barry, I see that you have a work item "port xdg" on foundations-q-python-versions
<seb128> barry, is that pyxdg?
<seb128> barry, they released a new version compatible with python3 recently, http://freedesktop.org/wiki/Software/pyxdg
<barry> seb128: yeah, but i think that's a big task, if not improbable ;)
<barry> oh!
<seb128> barry, not sure if you saw, but I figured you might be interested to do the package update
<seb128> "Compatible with Python 3; requires Python 2.6 or later "
<barry> seb128: indeed i am, thanks for the pointer!
<seb128> barry, yw ;-)
<slangasek> barryyyy
<slangasek> how's post-apocalyptic DC?
<barry> slangasek: getting back to normal.  how precarious is our society! :)
<slangasek> :)
<seb128> barry, I've assigned you https://bugs.launchpad.net/ubuntu/+source/pyxdg/+bug/823150 so we don't dup work if anyone else wants to look at that update
<ubottu> Launchpad bug 823150 in pyxdg (Ubuntu) "Please provide a python3 package" [Undecided,Confirmed]
<barry> seb128: perfect thanks.  i'm going to start working on that now
 * slangasek replaces the WI in the blueprint with a linked bug
 * barry updates the spreadsheet
<seb128> barry, thanks
<barry> actually, spreadsheet is already updated
<seb128> slangasek, is the $XDG_RUNTIME_DIR support for our stack still likely for this cycle? :-)
<slangasek> seb128: yes, I think so
<seb128> slangasek, the most popular nautilus segfault on errors.ubuntu.com is due to the lack of $XDG_RUNTIME_DIR in Ubuntu :-(
<slangasek> oh really?
<seb128> yes
<slangasek> that seems like an unfriendly thing for nautilus to do
<seb128> dconf uses mmap and those don't work reliable on ecryptfs or nfs
<seb128> reliably
<slangasek> seb128: btw, can someone please revert the /run/media nonsense?  /media is defined in the FHS
<seb128> slangasek, I will have a look at what's the rational for using /run ... how much do we care about being compliant with the FHS on that? :-)
<slangasek> a lot?
<slangasek> moving mount points around under users for no reason is unfriendly
<Daviey> Perhaps i am a bad man, but I actually have things hardcoded to use /media/FOO
<maxb> If the FHS says you can.... :-)
<seb128> slangasek, I need to check but I think it makes sense for parts of the mounts to be under /run
<slangasek> seb128: there's no reason for this move, it's entirely gratuitous
<seb128> slangasek, i.e the ones which were in .gvfs before
<slangasek> oh
<seb128> the fuse user mounts
<slangasek> ok, I haven't seen that happening yet - so possibly
<slangasek> but e.g., my usb stick shouldn't suddenly move from /media/$SERIAL to /run/media/vorlon/$SERIAL on upgrade
<Daviey> unless at least a compat symlink is put in place?
<slangasek> gvfs-fuse-daemon on /home/vorlon/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,user=vorlon)
<slangasek> so no, this doesn't even touch gvfs ;)
<seb128> slangasek, http://git.gnome.org/browse/gvfs/commit/?id=6307d017a12642e71ba2f04e82fc3781425a3eb6
<seb128> that indicates it's coming from udisks2
<seb128> I will check with pitti what he thinks ;-)
<slangasek> okie
<seb128> slangasek, http://cgit.freedesktop.org/udisks/commit/?id=502fb5b7810afb50e48354e6b4d1781d07f79e10
<seb128> no bug reference or rational :-(
<seb128> slangasek, can you open a bug about that?
<seb128> so we make sure to track it
<slangasek> seb128: ok
<seb128> thanks
<slangasek> thank you!
<slangasek> seb128: bug #1020759
<ubottu> Launchpad bug 1020759 in udisks2 (Ubuntu) "/run/media is an unnecessary divergence from the FHS" [Undecided,New] https://launchpad.net/bugs/1020759
<seb128> slangasek, thanks
#ubuntu-devel 2012-07-04
<pp7> anyone else have suspend problems since last update?
<ajmitch> pp7: what sort of problems are you seeing? I haven't had a chance to file a bug about it yet
<pp7> ajmitch, well it wont suspend at all anymore
<pp7> i just have a script that calls pm-suspend after locking the screen but it doesnt suspend, just goes to lock screen
<ajmitch> a different problem than what I've been seeing. I'd file a bug with 'ubuntu-bug linux'
<pp7> mm k
<lifeless> there is a dbug page
<lifeless> debug page for debugging whats going on
<lifeless> I'd run through it quickly, I forget the URL.
<ajmitch> https://wiki.ubuntu.com/Kernel/Debugging perhaps
<pp7> k
<vibhav> mterry: Do we need 02_fix_install_path.patch in https://launchpad.net/ubuntu/+source/gbirthday/0.6.5-1ubuntu1 for quantal too?
<OdyX> n
<pp7> is there anything wrong with running echo -n "mem" > /sys/power/state on its own to suspend?  I just did it and it came back fine but i'm wondering if something will get screwed up next time
<OdyX> pp7: besides you don't benefit from all the preparation pm-suspend does for you, no.
<pp7> what preparation?
<pp7> i am doing this because pm-suspend now does nothing after latest update
<slangasek> pp7: pm-utils runs a series of scripts to set the hardware in a correct state before and after suspend (/usr/lib/pm-utils/sleep.d/); on some hardware, skipping these makes resuming from suspend fail completely, on others it might just mean your machine is in a suboptimal state after resume
<slangasek> pp7: if pm-suspend is failing for you, you might want to check /var/log/pm-suspend.log
<pp7> slangasek, yea i checked that but nothing useful, says it was successful when it wasn't
<pitti> Good morning
<TheMuso> c
<dholbach> good morning
 * xnox notes should not try to do too many things simultaneously, otherwise typos happen....
<jamespage> can someone help me understand why this package - https://launchpad.net/ubuntu/+source/libunwind/1.0.1-1ubuntu1
<jamespage> is only building for i386 and amd64? I was expecting powerpc and armel as well...
<seb128> jamespage, P-a-S has "%libunwind: ia64 i386 amd64 ppc64"
<seb128> jamespage, https://code.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu
<seb128> jamespage, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=569952
<ubottu> Debian bug 569952 in buildd.debian.org "Please let libunwind build on i386 and amd64" [Normal,Open]
<seb128> jamespage, I guess you need to tweak that if it can build on powerpc,armel nowadays
<jamespage> seb128, thanks for the pointer - I still seem to learn something new every day on this project :-)
<jamespage> seb128, I'll test those two architectures first and enable if it looks OK
<seb128> jamespage, sounds good
<seb128> jamespage, you might want to file a bug for Debian to do it as well if it works on those archs
<jamespage> seb128, ack
<tumbleweed> RAOF: ping on bug 950963: what's the chance of providing compatibility with Debian packages depending on libcuda / libopencl?
<ubottu> Launchpad bug 950963 in viennacl (Ubuntu) "nvidia-graphics-drivers needs to provide separate packages such as libcuda1" [High,Confirmed] https://launchpad.net/bugs/950963
<xnox> tumbleweed: RAOF: this looks familiar
 * tumbleweed prodded RAOF about it at UDS. He suggested Provides, but IIRC some packages have versioned dependencies
<tumbleweed> it's making the scientific computing people sad :)
<xnox> tumbleweed: there is a similar request for opencl
<tumbleweed> unsuprisingly
<xnox> tumbleweed: bug 763457
<ubottu> Launchpad bug 763457 in nvidia-graphics-drivers (Ubuntu) "please provide opencl-icd virtual package" [Medium,Confirmed] https://launchpad.net/bugs/763457
<xnox> tumbleweed: RAOF: i have pinged tseliot about bug 763457 and he said it should be easy to do for opencl, but I am not sure about the cuda bits.
<ubottu> Launchpad bug 763457 in nvidia-graphics-drivers (Ubuntu) "please provide opencl-icd virtual package" [Medium,Confirmed] https://launchpad.net/bugs/763457
<xnox> the opencl stuff came up as part of boost1.49 transition
<tseliot> xnox: last time I checked, the cuda package in debian needed some work to include it in Ubuntu
<tumbleweed> our nvidia driver packages include libcuda, don't they?
<mhr3_> doko, hey i hear you can help me with valgrind-related issue
<mhr3_> doko, so, it's pretty simple - callgrind_control doesn't work for us, cause there's a regex which fails, any chance to patch it?
<mhr3_> (it's just a perl script)
<mhr3_> it fails cause it expects valgrind to be valgrind, yet it's valgrind.bin for us
<jamespage> seb128, I am correct in thinking that I 1) push the required changes to the p-a-s branch and then 2) upload a new version to enable the new archtectures?
<cjwatson> Yes
<cjwatson> Wait a bit in between though
<cjwatson> (Also send the patch to Debian, Package: buildd.debian.org, if it applies there too)
<cjwatson> "a bit" here is an hour or so:
<cjwatson> 15 * * * *  cd /srv/launchpad.net/builddmaster/pas-bzr/ && bzr up -q
<jamespage> cjwatson, yep - I just finished testing on powerpc and arm*
<jamespage> I will submit patches for fixing arm* and enabling in debian
<doko> mhr3_, what to send a patch?
<mhr3_> doko, i just did
<mhr3_> $ diff callgrind_control.old callgrind_control
<mhr3_> 32c32
<mhr3_> <       if (/^use --pid=(\d+) for \S*?valgrind\s+(.*?)\s*$/) {
<mhr3_> ---
<mhr3_> >       if (/^use --pid=(\d+) for \S*?valgrind\S*?\s+(.*?)\s*$/) {
<mhr3_> sorry, didn't do the pkg-foo
<doko> mhr3_, I'm travelling, so please put it into a bug report for now
<mhr3_> ok
<gigix> Hello everyone. I'd like to contribute to the development of Ubuntu, read quite a few articles and wiki pages about how to do so, but I am still a bit confused about where to start. Could you guys share thoughts about a recommended path for 1st time contributors ?
<ev> mpt: yay, I just landed hanging application support in apport. I'll let you know when it's in the archive so you can poke around the UI and make sure it meets your expectations. Just need to land my compiz branch now and we're there.
<ev> much thanks to pitti for the steady stream of thorough code reviews
<mpt> ev, does it require a Q installation?
<ev> mpt: hmm, probably not
<ev> I can throw it in a ppa for precise
<ev> and we can evaluate backporting to get data from 12.04.1 users
<jamespage> anyone aware of any issues with the 3.5.0-3 kernel in quantal?  I get 0 peripherals including network, usb, monitor etc...
<pitti> ev: FYI, I have a build recipe for apport's trunk
<pitti> ev: FYI, bumping apport's version to 2.3, as it has new features (should have done this before already)
<ev> pitti: cheers!
<smb> cjwatson, While meddling around trying to figure kdump, I took the opportunity to do a merge of kexec-tools from Debian. Since you uploaded it last, I wanted to let you know and also ask how you would prefer me to go on. LP bug and subscribe you or just generic sponsors?
<cjwatson> Go ahead; just generic sponsors, I have no attachment to it
<smb> ok
<PaoloRotolo> Hi all
<zyga-food> mvo, hey, what decides that apt-get install selects a package from precise vs precise-backports? (when both repositories are enabled)
<stgraber> zyga-food: -backports is marked as NotAutomatic and ButAutomaticUpgrades. So apt will never select a package from it unless explicitly asked to do so, but once a package is installed from it, apt will continue pulling updates from -backports.
<zyga-food> stgraber, interesting, how would one install a package from backports? with explicit version provided to apt?
<Laney> zyga-food: apt-get install foo/precise-backports
<zyga-food> stgraber, and once you actually get that package, does it 'unlock' all other backport packages or just the package (name) that was installed
<zyga-food> ah
<zyga-food> interesting
 * zyga-food is trying to install something from backports and managed to do it with apt-get install foo=very-long-version
<Laney> that works too
<zyga-food> where can I read about it?
<Laney> !backports
<ubottu> If new updated Ubuntu packages are built for an application, then they may go into Ubuntu Backports. See https://help.ubuntu.com/community/UbuntuBackports - See also !packaging
<zyga-food> I'd like to understand how that works
<zyga-food> thanks!
<pitti> apw, ogasawara: is it planned to apply our remaining Ubuntu delta of module-init-tools to kmod and move to that?
<apw> pitti, i don't think we've done anything other than think that it was a good idea
<apw> i am sure its where most peopel are going
<pitti> apw: kmod should be backwards compatible from what I can tell; the "upgrade quirks" are most probably obsolete anyway after precise's release, so we just have some modprobe.d/ customizations
<pitti> you can't build systemd and newer udev without it, that's why I'm asking
<apw> pitti, heh ... well then our hand is forced, i can put it on my list
<pitti> apw: alternatively we could modify the Debian source package to not build the transitional module-init-tools package
<pitti> but it seems to be the official successor, also in debian
<apw> pitti, yep i think we want to change if we can, i'll look at it next
<pitti> apw: cheers! hopefully our delta is not too big
<micahg> xnox: why not just let mongodb fail than disabling it? (failure is a sign to fix)
<xnox> micahg: it's a toolchain issue, with bugs filed with tag boost1.49
<micahg> xnox: so what?
<xnox> it's one of the 3 remaining packages to remove boost1.46 from the archive
<micahg> xnox: and, as much as it would be nice to have boost1.46 gone, at this point in the cycle, it doesn't matter that much
<micahg> xnox: also, you can remove the binaries without disabling the build
<gmi> can anybody confirm if a new version of dnsmasq-base was added to precise-proposed? it was reportedly added around June 15th but I cannot seem to find it; the only version is 2.59-4 and I'm looking for 2.61
<micahg> xnox: when you disable the build, it no longer shows up here: http://qa.ubuntuwire.com/ftbfs/, so no one sees that there is an FTBFS bug to fix
<micahg> gmi: 2.62-3 is in quantal, it's unlikely that 2.61 would be uploaded to precise
<gmi> micahg: Chuck Short sent an email on the openstack mailing list on June 15th about uploading a fix to a dnsmasq bug affecting Ubuntu Precise users to the precise-proposed repo, but I don't see any new new version being available
<zul> gmi: no i said we are working on it...still working on it
<micahg> bug 1006898
<ubottu> Launchpad bug 1006898 in dnsmasq (Ubuntu Precise) "[SRU] dnsmasq fails at leasing issues when using vlan mode" [Medium,Triaged] https://launchpad.net/bugs/1006898
<gmi> zul: the email was worded differently, but if I have to wait I'll wait http://openstack.markmail.org/search/?q=or%20those%20who%20are%20affected%20by%20the%20dnsmasq%2Fvlan%20issues%20on%20Ubuntu%2C%20I%20have%20uploaded%20a%20fix%20for%20precise-proposed.%20It%20should%20be%20available%20for%20testing%20of%20the%20fix%20soon.%20You%20will%20have%20to%20turn%20on%20%22precise-proposed%22%20on%20your%20servers%20to%20test%20the%20f
<micahg> gmi: it was uploaded and rejected, see the bug for more info
<gmi> micahg and zul: thanks for the update; I'll be patient and wait for the update to land in precise-proposed
<micahg> BenC: thanks for the PPC patch for Firefox
<BenC> micahg: No problem
<xnox> micahg: I know that. I will have arm hardware in 1.5 weeks, and I'm planning on making them build again.
<xnox> micahg: but you do have a point, now that armhf builds, there is little point in not keeping armel as FTBFS
<micahg> xnox: also, something to keep in mind is Ubuntu isn't like Debian (yet) where we have to worry about binaries migrating
<xnox> micahg: but i can't remove the source package without binaries...
<micahg> xnox: huh?
<micahg> jamespage: doko: is it time to flip the openjdk 7 plugin to main in quantal?
<micahg> jamespage: doko: I mean switch the openjdk7 version to be default (and what icedtea-plugin pulls in)
<jamespage> micahg, I think so; the java alternates need to be updated as well to favour java7 over java6 when both are installed.
<jamespage> doko, I think I'm correct in what I say above ^^
<cousteau> so...  could someone please fix the problem on nvidia-96?
 * cousteau is considering the possibility of just opening the package and deleting the xorg-video-10-abi line
<micahg> cousteau: the person I poked is off today
<cousteau> ok
<cousteau> but it's a work in progress then
<cousteau> ok...  I've not upgraded to precise yet but when I do I don't want to be installing the Nvidia drivers manually again
<micahg> cousteau: I would do it myself, but I'm not sure if it needs more than a rebuild r not
<cousteau> (also another IRC user happens to have exactly the same graphics card model as I do...)
<cousteau> maybe the install can be forced by telling dpkg to ignore missing dependencies?
<stgraber> ScottK: around?
<ScottK> stgraber: Yes.
<stgraber> ScottK: Edubuntu has failed to build for a few days now because of python-avogadro not being installable
<stgraber> ScottK: as it depends on python2.7-qt4
<stgraber> which doesn't seem to exist
<ScottK> The Debian avogadro maintainer and I are arguing about that very point.
<ScottK> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679819
<ubottu> Debian bug 679819 in python-qt4 "Dropping Provides field broke depending software (python-avogadro)" [Serious,Open]
<stgraber> based on germinate output, I should be able to avoid python-avogdaro by changing the libavogadro1 recommends but I'm open to better solutions, as long as we get Edubuntu buildable again quickly :)
<highvoltage> thanks ScottK :)
<ScottK> It's easy enough to fix in either avogadro or PyQt.
<ScottK> I think fixing it in avogadro is better, but as you can see if the bug the avogadro maintainer has not agreed.
<ScottK> The needed diff for avogadro is in the bug.
<ScottK> Fixing PyQt makes even less sense in Ubuntu where there's only one Python version.
<stgraber> ok, I'll upload the avogadro change in Ubuntu, and once people are done fighting we'll use whatever they decide :)
<ScottK> Sounds good.
<xnox> stgraber: what avogadro changes? =)
<ScottK> xnox: Look in the bug I referenced.
 * xnox was offline.... looking up irclogs..
<Laney> lesson: never go offline
<doko> jamespage, yes the priorities need an update.
<micahg> jamespage: so, can you fix up icedtea-web then?
<micahg> xnox: what did you mean before about removing sources with binaries?
<jamespage> micahg, I can but not immediately - I have a few other things I need to clear first
<micahg> jamespage: sure, no rush, just want to make sure someone's taking it :)
<xnox> micahg: mongodb is part of boost1.46 -> boost1.49 transition.
<xnox> it's one of the last 4 packages
<xnox> can i remove boost1.46 sources, while keeping the remaining boost1.46 binaries which mongodb old version depends on in precise (and copied into quantal)
<ScottK> xnox: In that case no you can't.
<micahg> xnox: right, but you can remove the offending armel binary without disabling the build
<ajmitch> there are probably good (legal) reasons why you can't remove the source if binaries still exist
<xnox> micahg: that's why I disabled armel build, as far as mongodb armel build goes: either upstream should finally support things that are not *-x86, or armel toolchain needs target profile changes.
<xnox> it doesn't look like either of fixes will happen any time soon.
<micahg> xnox: right, but it was established that it's a toolchain bug that should be fixed, not an upstream issue, and the FTBFS reminder makes it more likely for some +1 maintenance person like infinity to actually fix it
<ScottK> I can remove binaries on a single arch if neeeded.
<xnox> ok. thanks.
<xnox> I will fix player and give another round to ball, before comming back to this
<xnox> ScottK: interesting maintainer of avogadro...
<ScottK> Yes.
<alazare619> anyone here build ubuntu 12.04 from scratch using live-build?
#ubuntu-devel 2012-07-05
<alazare619> anyone in here an actual ubuntu builder im using the ubuntu livecd-rootfs/live-build scripts could use a little assitance
<pitti> Good morning
<Roj> hi how i can use Gwibber in my apps?i need resource :(
<RAOF> Roj: What do you want to do?
<Roj> i went to create unity lens for it :)
<RAOF> How will this be different from the existing unity lens for it?
<Roj> like pading lens
<Roj> to seatch user in facebook or etc
<RAOF> I'd start with unity-lens-gwibber
<Roj> :( have lens for it?
<RAOF> Yes.
<Roj> you think i can use it in my app for submit in The Ubuntu App Showdown?
<dholbach> good morning
<dholbach> didrocks, care to join us again? :)
<didrocks> dholbach: oh sure :)
<iulian> Uh-oh! Sounds like a fancy party. Can I join you guys? :-)
<ev> mpt: do you think we should try to fold the Help buttons into the main interface? http://people.canonical.com/~evand/tmp/Screen%20shot%202012-07-05%20at%2010.20.15.png They can get quite long though (see the Extended_description entries in /var/cache/debconf/templates.dat).
<sladen> ev: 'needs your help' and '[help]' terminology confusion too
<ev> sladen: yeah, the text is very much a work in progress
<ev> https://wiki.ubuntu.com/ErrorTracker#debconf
<ev> ^ is the design I'm slowly moving towards
<ev> ah and indeed he's already covered this
<sladen> ev: *nod* sounds like it's already designed; the text from the second-level dialogue would simply be placed in the main area as 'Long description in smaller print'
<sladen> (if I understood correctly)
<sladen> and 'Mailname of your system:' would be the 'Short description above'
<bob235> hi, is this the right channel to ask about the qualtal debian import freeze?
<bob235> i see from the qualtal release plan that 5 july is the debian import freeze
<cjwatson> yes
<bob235> i'm hoping to get the latest version of rabbitmq-server into qualtal
<bob235> if i miss the deadline today have i missed the boat?
<cjwatson> are you the Debian maintainer?
<bob235> there is a sync request bug https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1018001
<ubottu> Launchpad bug 1018001 in rabbitmq-server (Ubuntu) "Please sync rabbitmq-server 2.8.4 from Debian" [Medium,Triaged]
<cjwatson> manual sync requests can be processed after Debian import freeze
<bob235> yes i'm the debian maintainer
<cjwatson> the only thing this freeze affects is that we won't run auto-syncs after today
<sladen> bob235: you can do it manually later.  Tomorrow is the end of automatic syncs
<cjwatson> so no, you have not missed the boat
<bob235> phew, that's good news!
<bob235> so what do i need to do manually later?
<cjwatson> I'd rather leave it up to somebody like roaksoax or Daviey to check the manual sync request
<bob235> ok, so i don't need to panic, and wait for Daviey to pick it up?
<cjwatson> inded
<cjwatson> *indeed
<bob235> thanks for your help. i'll sit tight until that happens then
<ev> sladen: exactly
<ev> I was just spending too much time staring at the first mockup
<cjwatson> stgraber: can the lttng-ust source package be replaced by ust 2.0.4-1 from Debian?  Noticed this while running auto-sync.
<Fudge> hi can i report broken links on developer.ubuntu.com/packaging/
<mpt> ev, are the Help buttons showing the "long description" part of the Description field?
<mpt> If not, where are they getting their text?
<mpt> And if so, I showed where the long description goes in the wireframes.
<ev> mpt: yes - sladen and I were discussing that around 10:45
<ev> indeed
<ev> mpt: back and continue for the buttons?
<mpt> ev, just Continue unless you want to implement back/forward navigation
<ev> or was your intent to not treat it like an assistant at all?
<seb128> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | 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: seb128
<ev> mpt: I'm asking because there's already back/forward navigation there
<ev> as debconf does let you back up through questions
<mpt> ev, I know, I'm asking you if you want to implement that in this cycle. If so, I'll add it to the design
<ev> mpt: ah, apologies
<ev> this would probably be so much easier if I just walked the 10 feet to you
<ev> yay, sorted
 * mpt giggles at the maximizable Help alert
<ev> :)
<mpt> I bet that looks just stunningly beautiful when maximized
<sladen> empty space is beautiful
<ev> mpt: for what it's worth, we're blocked on the compiz merge until we have that plan for dealing with applications hanging and coming back: https://code.launchpad.net/~ev/compiz/call-apport-on-hangs/+merge/113436/comments/243748
<ev> if we can recreate the wonderful Firefox experience of ZOMG XUL IS HANGING! that would be ace :)
<ev> mpt: ps. since you were curious: http://people.canonical.com/~evand/tmp/Screen%20shot%202012-07-05%20at%2011.34.14.png
<dupondje> cyphermox: cjwatson: noted https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1021122 ?
<ubottu> Launchpad bug 1021122 in software-properties (Ubuntu) "package python3-software-properties (not installed) failed to install/upgrade: trying to overwrite '/usr/share/man/man1/add-apt-repository.1.gz', which is also in package python-software-properties 0.83" [Undecided,Confirmed]
<cjwatson> dupondje: that's an entertaining arrangement of links
<cjwatson> lrwxrwxrwx root/root         0 2012-07-04 14:56 ./usr/bin/apt-add-repository -> add-apt-repository
 * cjwatson digs
<cjwatson> dupondje: fix uploading now
<dupondje> cjwatson: great :)
<seb128> cjwatson, hey, do you know what's the status on https://bugs.launchpad.net/ubuntu/+source/aptdaemon/+bug/926340? it's assigned to you and on the LTS .1 list?
<ubottu> Launchpad bug 926340 in aptdaemon (Ubuntu Precise) "aptd crashed with UnicodeDecodeError in _set_error(): 'ascii' codec can't decode byte 0xc3 in position 9: ordinal not in range(128)" [High,Triaged]
<cjwatson> not got anywhere as yet, sorry, but I thought glatzor had indicated some kind of progress there
<seb128> cjwatson, he asked you for a patch review mid june so I wondered if you had looked at the patch yet
<cjwatson> he did?  argh
<stgraber> cjwatson: hmm, I'm a bit surprised the Debian maintainer didn't also change the source name in the process, but yeah, the binary packages are the same so lttng-ust should be replaced by ust
 * cjwatson looks
<seb128> cjwatson, thanks
<ScottK> stgraber: I didn't check if you dealt with avogadro or not, but we decided I'll fix it in python-qt4 in Debian.  If you fixed avogadro, no need to revert.  It'll be happy either way.
<stgraber> ScottK: I uploaded avogadro yesterday afternoon
<ScottK> OK.
<ScottK> So for your purposes it's solved no matter what I do.
<stgraber> right
<cjwatson> seb128: replied now
<seb128> cjwatson, thanks ;-)
<apw> mvo, yo ... been playing with squid-deb-proxy and IPv6, finally figured out that the IPv4 records with IPv6 addresses make sense as that field refers to the broadcast channel we used to obtain the address and says nothing about the address itself
<hallyn> cyphermox: libnl3 FTBFS waiting on source-highlight, which looks like it is published since apr 30.  any idea?
<apw> mvo, anyhow, have put some patches together to advertise, prefer, a
<cjwatson>     libnl3 |    3.2.7-4 |       quantal | source
<cjwatson> source-highlight |    3.1.6-1 | quantal/universe | source, amd64, armel, armhf, i386, powerpc
<cyphermox> is source-highlight in universe?
<cyphermox> ah
<cyphermox> so we'll have to file a MIR
<apw> mvo, anyhow, have put some patches together to advertise, prefer, and use IPv6, under bug #1021298; branch attached
<ubottu> Launchpad bug 1021298 in squid-deb-proxy (Ubuntu) "squid-deb-proxy should advertise and use IPv6 addresses" [Medium,In progress] https://launchpad.net/bugs/1021298
<cjwatson> listed on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt
<hallyn> cyphermox: d'oh, shoulda checked that
<cyphermox> np
<hallyn> cyphermox: i do have a hard time believeing that 'source-highlight' could be crucial to building libnl3...
<cyphermox> hallyn: it's likely for the docs; if you want you can try to disable it ;)
<Laney> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657254
<ubottu> Debian bug 657254 in src:libnl3 "libnl-3-200: Fails to build from source due to missing build-dep on source-highlight" [Serious,Fixed]
<hallyn> cyphermox: i'll give it a shot.
<mvo> apw: \o/
<mvo> apw: I have a look  now
<apw> mvo, i have tested it here, but only on an ipv6 enabled network, in theory it should work using link locals anyhow if you have them or fall back to ipv4
<apw> mvo, so some testing on a normal network is in order before upload
<ScottK> apw: It's not going to slow things down if there's no IPv6 is there (RFC 6555, Section 3.2 warns about this).
<apw> ScottK, no the new code does fewer lookups so it should be quicker overall, it scans the same list twice picking any advertised v6 addys first, then falling back to ipv4
<apw> ScottK, and as avahi is link local anyhow, in theory you should be always able to use the link-locals if they exist
<apw> ScottK, but ... it does need some combintation testing before its released
<ScottK> OK.  I get nervous about people 'fixing' stuff to look at IPv6 first as it's often gone astray in the past.  I'm glad you've thought it through.
<ScottK> Besides, how often to I get to refer to an RFC titled "Happy Eyeballs"?
<apw> ScottK, i am worried enough still :)  but also unless we try things we'll not get things fixed at all, and thats a worry with ipv4 creaking so
<apw> ScottK, heh there is that indeed.
<ScottK> Agreed.
 * apw sees .eu has 3 weeks till it joins .ap
<didrocks> ev: hey, did you get any more info on why I got all those errors on errors.ubuntu.com with my credentials?
<didrocks> ev: it's really making hard using it :/
<ScottK> Recently I got an RC bug in Debian on opendkim due to IPv6 problems.  It turns out it works ~fine, but the documentation for use with IPv6 was sorely lacking.  I get the impression real people are starting to use it.
<ScottK> (it being IPv6)
<apw> mvo, i wonder if i should be using the IPv6/IPv4 fields to 'enable' use of addresses in that realm ... as a hint we as a consumer have ipv6 for instance
<ev> didrocks: I sadly haven't gotten to it yet. I don't suppose you could grab someone in #webops and see if you can pair through the issue? I imagine you'll have much more success than me trying to vaguely convey what's happening on your connection to them.
<ev> didrocks: as the openid stuff is not something I build yet
<ev> (it's currently an apache module, whereas in the future I hope to move to something like django-openid-auth, if I can rip the notion of writing to tables from its brain)
<didrocks> ev: I'll try a losa ping
<apw> mvo, ScottK, if you use squid-deb-proxy could you paste me the output of: avahi-browse -kprt _apt_proxy._tcp
<ScottK> I don't.  Sorry.
<apw> i can use those to test the algorithm
<apw> np
<xnox> dholbach: $ reverse-depends adept \n No reverse dependencies found
<xnox> is there a removal bug?
<dholbach> at least none https://bugs.launchpad.net/~ubuntu-archive is subscribed too
<dholbach> to
<dholbach> https://code.launchpad.net/~scarneiro/ubuntu/quantal/adept/fix-invalid-brace.expansions/+merge/111331 is how I found out about it (which can be rejected then)
<dholbach> and http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=673085 in Debian, maybe for reference
<ubottu> Debian bug 673085 in ftp.debian.org "RM: adept -- RoQA; RC buggy, unmaintained, low popcon" [Normal,Open]
<ScottK> If the rdepends are gone, I'll remove it.
<xnox> ScottK: do it ;-)
<xnox> dholbach: ScottK: i was about to $ import-bug-from debian 673085 + subscribe ubuntu-archive ;-)
<ubottu> Debian bug 673085 in ftp.debian.org "RM: adept -- RoQA; RC buggy, unmaintained, low popcon" [Normal,Open] http://bugs.debian.org/673085
<melodie_> Hi
<ScottK> Save yourself the trouble.
<xnox> thanks =)
<melodie_> I have a few questions related to services in relation with bum package and chkconfig package. I wonder where would the right chan be ? the #ubuntu : no way, full with users now and impossible to get a hint
<ScottK> xnox: Gone.
<xnox> =)
<ScottK> dholbach: ^^^
<dholbach> fantastic - thanks
<dholbach> can anyone reject https://code.launchpad.net/~scarneiro/ubuntu/quantal/adept/fix-invalid-brace.expansions/+merge/111331 because adept was removed from the archive?
<xnox> dholbach: I will with a comment
<ev> mpt, seb128: https://bugs.launchpad.net/errors/+bug/1021326
<ubottu> Launchpad bug 1021326 in Errors "Only show version numbers from official Ubuntu sources in "First seen" and "Last seen" fields" [High,Confirmed]
<seb128> ev, thanks
<ev> sure thing
<stgraber> dholbach: rejected
<dholbach> thanks
<stgraber> xnox: I don't think you can actually reject a branch, all you can do on a UDD branch is post a review. You need to be part of ~ubuntu-branches to actually reject a MP
<xnox> stgraber: it does offer me the reject option.... let me try
<xnox> stgraber: nah, can't be asked, will try some other time.
<melodie_> I'll rephrase : I tried to configure ssh for it to be started at boot in a Lubuntu precise but I could not find a tool for that in the distro and didn't know what file to look at. So I tried this package : http://packages.ubuntu.com/precise/chkconfig
<xnox> melodie_: surely you want to install openssh-server..... or use @reboot cron job.... or write your own upstart job to do this
<ScottK> Installing the server is both necessary and sufficient.
<melodie_> it appears after trying that it is not only buggy for the path : it looks for /sbin/insserv whereas this file is in the /lib tree directory, but when for a test I create a symlink to please him, the command I launch then complains that it is not an Upstart Job
<xnox> melodie_: try !askubuntu website in the future
<melodie_> so I thought there are at least 2 bugs :
<melodie_> one related to the program, one is that this program might be removed from the repos as becoming irrelevant : what do you think ?
<melodie_> I am not trying to solve just one issue, but to see what I could do to help improve Ubuntu
<ScottK> Since chkconfig doesn't know about upstart, I think it's unlikely to work on Ubuntu.
<melodie_> askubunty might help me find a solution as ubuntu-fr.org can : I read French more comfortably, but there I found bum which does not solve because I can't find the ssh service in it. (and I don't know if this is a bug yet)
<melodie_> xnox, and I have installed openssh-server, thanks. :)
<melodie_> xnox, I don't want to write jobs or scripts, I don't code, I don't know how to do that, I can edit files, and click on buttons sometimes too. ;)
<xnox> melodie_: i didn't ask you to code, but add configuration.
<melodie_> and if there is a more relevant chan to discuss about the packages meant to ease the management of the services
<melodie_> xnox, this is it : I am currently seeking for a tool or the info on which file to edit ?
<xnox> melodie_: $ sudo apt-get install openssh-server
<xnox> reboot
<xnox> ssh-server is started on boot
<xnox> what is your question?
<melodie_> what is the file where it is written ?
<xnox> melodie_: no need to write a file.
<xnox> but if you want details
<melodie_> yes, I would like to have details
<melodie_> I can start ssh with console, but knowing better the new programs managing the services would be nice too
<xnox> melodie_: $ ssh host; doesn't start ssh.... it creates a client session
<xnox> melodie_: /etc/ssh/sshd_config is the sshd (server) settings
<xnox> started by upstart using $ /etc/init/ssh.conf
<xnox> melodie_: do you want server or client to be started on boot?
<melodie_> I am thinking...
<melodie_> I use both and confuse both too. I have a remove machine : squirrel, which I wanted to connect to the local machine "copernic" to send a file to it. I couldn't. I randomly installed the ssh-server and didn't retry since I was trying to find a tool where to configure the jobs at start, and was wondering why I can't set it up the way I want with gui tools
<melodie_> suppose the server on "copernic" will allow connecting the remote "squirrel" to it ? (when I say remote it is still on a lan anyhow)
<xnox> melodie_: on squirrel do $ apt-get install openssh-server
<xnox> melodie_: on local machine open a folder -> file Connect to server -> select SFTP -> type squirrel your username and password
<xnox> done
<melodie_> xnox, squirrel already has it (a very old Archlinux install which is full with all what's needed)
<xnox> melodie_: please go to #ubuntu this is nothing to do with development
<xnox> melodie_: ask "how to connect to remote ssh server"
<melodie_> xnox, sure. (all works now)
<melodie_> xnox, what about the chkconfig package ? Should not I go somewhere (launchpad ? bug section ?) to say that it is not needed in the repos anymore ?
<seb128> xnox, hey
<melodie_> xnox, thanks, anyhow I know how to connect with ssh, sshfs and so on. I just wonder why it is so hard to find a gui to configure the services.
<melodie_> I mean, one which offers the choices for all services installed.
<xnox> melodie_: dunno. ask on #ubuntu-server. I am fine with editing files.
<seb128> xnox, I'm doing some sponsoring ... you maintain mdadm right? do you plan to do a SRU update soon? I'm wondering if I should sponsor the fix from bug #946758 to precise or let that to you for a SRU (since I saw other issues are milestoned for 12.04.1)
<xnox> seb128: yes?!
<ubottu> Launchpad bug 946758 in mdadm (Ubuntu Precise) "Format string overflow in Monitor.c:check_array" [High,Triaged] https://launchpad.net/bugs/946758
<melodie_> xnox, ok I try, thanks
<seb128> xnox, tldr ; should I upload https://launchpadlibrarian.net/109290854/mdadm.debdiff
<xnox> seb128: no.
<xnox> seb128: let me read now =)
<seb128> xnox, yes, no ... you are a binary man :p
<xnox> seb128: is there a bug or anything? this is just a launchpadlibrarian
<seb128> xnox, the bug was in the first sentence I wrote
<seb128> xnox, after the "hey"
<xnox> ah
<xnox> sorry to much highlight on the screen
<xnox> =)
<seb128> xnox, no worry ;-)
<xnox> seb128: i believe that bug fix is already part of my sru, but it got rejected. So i only need to add a changelog entry and fix up the sru and re-upload.
<xnox> seb128: i was planning to do it today or tomorrow.
<seb128> xnox, ok, good, I will unassign sponsors and assign the bug to you
<seb128> xnox, works?
<xnox> seb128: so please don't upload... unless you claim to reproduce it and test it.
<xnox> seb128: sure =)
<seb128> xnox, it's all yours then, thanks ;-)
<hallyn> cyphermox: libnl-3 seems to build find without source-highlight
<cyphermox> hallyn: cool
<hallyn> cyphermox: i don't have upload rights, do you mind making that change?
<Laney> wait
<Laney> the Debian bug said that it tried to download from the internet without that BD
<Laney> hallyn: did you build in such an environment?
<hyperair> it looks like bug #785822 which is the last remaining bug requiring verification-done for banshee can't be verified because nobody who experienced the bug in the first place is present to verify that it's fixed.
<ubottu> Launchpad bug 785822 in banshee (Ubuntu Precise) "Banshee does not remove selected song from playlist" [Undecided,Fix committed] https://launchpad.net/bugs/785822
<cyphermox> hallyn: that changes things a whole lot, should try building it in a PPA
<Laney> wait, maybe I'm misremembering
<seb128> hyperair, you can testify that there is no regression
<seb128> which is good enough to verification-done it
<hyperair> okay.
<cyphermox> (and anyway, it would be a good idea to try to build some of the reverse-depends in case something changes that breaks them)
<hallyn> sure, will try in ppa.  or i could just try in a container sans networking, iiuc
<Laney> yeah
<Laney> I think it might not be this bug I'm thinking of, though.
<hallyn> pushed, will ping when done :)
<Laney> also it might be easier in the long run to MIR source-highlighting, should be relatively innocuous
 * hallyn goes to look at the code
<Roj> hi have any why to run python code from glade web browser?
<Roj> write code in html tag and can run with glade web browser
<melodie_> bye, and thanks
<Roj> hi have any why to run python code from glade web browser?
<hallyn> cyphermox: Laney: fwiw libnl-3 built fine in ppa (https://launchpad.net/~serge-hallyn/+archive/virt)
<hallyn> still going to look at the source-highlight source code (looked over its new bugs for starters)
<Laney> cool
<hallyn> but it seems i messed up cgroup-lite, so fixing that first :)
<hallyn> general q - awk being in /usr/bin not /bin, i would assume that has come up before?  (for bootup for systems with separate /usr)
<hallyn> i assume i should work around that, moving awk to /bin is not doable?
<cjwatson> work around it - there should be enough other tools in /bin to make it workaebl
<cjwatson> *wowrkable
<cjwatson> oh bah, I give up
<hallyn> :)
<cjwatson> hate typing on systems under load
<hallyn> yeah i don't mind working around it, just seems like there would be lots of boot scripts using awk...
<hallyn> thanks
<cjwatson> shouldn't be, they should all already have run into the same problem :)
<cjwatson> not many things have to worry about being run before /usr is mounted
<slangasek> also, becomes a non-issue once we implement foundations-q-usr-merge
<cjwatson> exactly
<hallyn> oh no, no 'logger' command either
<slangasek> fwiw, moving awk to /bin is particularly knotty because it's an alternative provided by two separate packages
<hallyn> and no tail
<slangasek> so we shouldn't really do that
<hallyn> slangasek: right, it didn't look pretty
<hallyn> but, no tail?
<slangasek> tail is not in the category of "things required in order to mount filesystems" :)
<ogra_> for reading the end of the log after the mount failed !
<hallyn> 'required', guess not.  i was just using it to skip the first line of /proc/cgroups
<slangasek> where are you getting a log?  rsyslogd is on /usr :P
<hallyn> i'll use the '#'
<ogra_> heh
<cjwatson> sed -n '2,$p'
<cjwatson> hallyn: ^-
<hallyn> leading '#' might actually be more reliable.  will think on it
<dobey> how does one run "make check" in override_dh_auto_test when using cmake?
<dobey> it seems to do the cmake in a subdir, and none of the env vars have that path in them :-/
<debfx> dobey: doesn't dh_auto_test do that already?
<dobey> debfx: well i would like to use a different make target than check
<debfx> dobey: you could call dh_auto_build -- <TARGET>
<dobey> debfx: thanks
<hallyn> gah.  i left logger still.  though only in failure paths.  is there a good replacement for 'logger' for during early boot (pre-/sys) ?
<seb128> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | 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:
<SpamapS> hallyn: upstart?
<stgraber> hallyn: just going with echo should be good enough, the output will go to /var/log/upstart/cgroup-lite.log
<hallyn> SpamapS: going by the cookbook, it seems i'd jsut be writing to /dev/kmsg
<hallyn> stgraber: oh, so maybe is hould do that in all cases even if logger is available?
<hallyn> is that pretty new?
<stgraber> yeah, I don't see any specific reason to write to syslog when we have per-job logs now
<stgraber> was introduced in 12.04
<stgraber> before that job output would just be lost
<hallyn> stgraber: no wait.  is that only in the upstart job itself, or also for scripts called by the upstart job?
 * hallyn tests
<stgraber> any output to stdout/stderr cause by the job should end up there (including anything that it spawns)
<stgraber> *caused
<hallyn> not seeing a /var/log/upstart
<vibhav> I was having a look at http://packages.debian.org/changelogs/pool/main/g/gksu-polkit/gksu-polkit_0.0.3-1/changelog#version0.0.2-2
<hallyn> oh i still need console output then
<vibhav> and noticed https://merges.ubuntu.com/g/gksu-polkit/gksu-polkit_0.0.2-2.1ubuntu1.patch doesnt have gksu-polkit (0.0.2-2.1) unstable; urgency=low , Am I missing something?
<hallyn> no, no help
<vibhav> Actually, the debian/changelog doesnt have gksu-polkit (0.0.2-2.1) unstable; urgency=low
<stgraber> hallyn: that's weird... you should definitely have /var/log/upstart (a directory) on your system and /var/log/upstart/<job>.log for any job that outputs something
<stgraber> hallyn: unless for some reason your system booted with --no-log
<hallyn> proc/cmdline: BOOT_IMAGE=/boot/vmlinuz-3.5.0-2-generic root=LABEL=cloudimg-rootfs ro console=ttyS0
<stgraber> hmm, you really should have /var/log/upstart/ then :)
<hallyn> lemme mkdir it
<hallyn> still no file in there
<stgraber> try "sudo initctl notify-disk-writeable"
<hallyn> i do see my precise host has it
<ogra_> infinity, any idea what we can do about the flash-kernel unmount thing ? thats a longstanding bug we had in the old version and something i even ran into with rootstock at times
<hallyn> stgraber: still no /var/log/upstart/*
<hallyn> stgraber: but, i guess i'll assume that is a configuration bug, or an upstart bug in quantal - the point remains i should have 'console output' in the cgroup-lite.conf, and use 'echo' ?
<stgraber> jodh: ^ (hallyn doesn't have /var/log/upstart on his system even though he didn't boot with --no-log)
<ahasenack> smoser: hi, just so you know, https://bugs.launchpad.net/cloud-init/+bug/897688 backfired
<ubottu> Launchpad bug 897688 in cloud-init "cloud-init should support apt-proxy and hostname based mirror selection" [Medium,Fix released]
<vibhav> Also, what is the dh_python2 equivalent of XS-Python-Version = all?
<ahasenack> smoser: dpb has one of those stupid ISPs with wildcard domains
<stgraber> hallyn: you shouldn't need "console output" as logging is the default for any version of upstart that supports it
<ahasenack> smoser: that respond to foo.bar.stupid.domain.my.isp with a valid ip showing some standard "domain not found" html page
<hallyn> stgraber: excellent
<stgraber> hallyn: so just moving from these logger calls to echo should do the trick
<ahasenack> smoser: and the machines he fired up with cloud-init ended up pointing at ubuntu-mirror.localdomain, which didn't work, of course
<hallyn> so i'll just switch to echo and call it good.  thanks
<infinity> ogra_: It's recurred in 3.0?  Cause I thought we had is nailed in precise.
<infinity> ogra_: /is/it/
<ogra_> infinity, well, you were the last person editing bug 1014139
<ogra_> :)
<ubottu> Launchpad bug 1014139 in flash-kernel (Ubuntu) "flash-kernel fails to umount flash device after writing" [Undecided,New] https://launchpad.net/bugs/1014139
<infinity> ogra_: Oh, I was just reassigning some initramfs-tools bugs, but yeah, that's clearly with 3.0
<infinity> ogra_: I guess we need to look at what we mangled in 2.x and forward-port the violence.
<ogra_> i also saw the issue here personally when upgrading my ac100
<infinity> xnox: Hey!
<ogra_> haha
<ogra_> we have a filesystem specialist now, i always forget :)
<xnox> infinity: hello!
 * xnox was offline for an hour due to xchat crash
<infinity> xnox: Has anybody yelled at you about your mongodb and qpid-cpp uploads yet?
<xnox> infinity: ogra_: what did I miss? =)
<xnox> infinity: micahg did =)
<ogra_> infinity, i think we used a sledgehammer like umount -l back in 2.0
<ogra_> or something similarily bad
<infinity> xnox: Can you revert the disabling of armhf on the former?
<infinity> xnox: As for the qpid-cpp one, did you disable the entire testsuite (as the changelog suggests), or just some network tests?
<xnox> infinity: yes, that's what micahg told me to do. And you mean reverting disable of *armel* right?
<infinity> xnox: Err, armel, not armhf.  Whatever.
<infinity> xnox: I removed the problematic binaries for you for now.  Keep in mind that disabling building on an arch doesn't actually remove binaries anyway, so wouldn't have done what you wanted regardless.
<xnox> infinity: qpid-cpp I think i disabled it out-right =) but now that we have a boost1.49 binary, i can re-enable all of it back :P
<ogra_> xnox, heh, sorry, i thought infinity's ping was related to the mount issue we have in flash-kernel :)
<infinity> ogra_: Nothing all that bad about lazy umounts.
<ogra_> apart from the fact that the "physical" mount might still be there ?
<xnox> ogra_: well I have a panda in a box, but haven't booted it yet.
<ogra_> -l only updates mtab, no ?
 * xnox has nothing against pandas or animals in general BTW
<ogra_> just make sure you have enough bamboo in your storage :)
<infinity> flash-kernel (2.28ubuntu34) oneiric; urgency=low
<infinity>   * Avoid races between umount and rm of the mountpoint with umount -l
<infinity> That seems to be the last thing the changelog has to say about it.
<ogra_> yeah, that sounds like the "fix"
<infinity> ogra_: No, it does more than update mtab.  It detaches the filesystem, and cleans up once it's no longer busy.
<ogra_> i still dont like to hide a race behind a lazy unmount
<ogra_> but i invested plenty of time to track down the race in the past and failed
<ogra_> evcen if you run lsof in the script, the open files are gone already
<gema> ogra_: http://www.weather.com/weather/videos/news-41/top-stories-169/108-tai-chi-pandas-in-the-rain-29461
<infinity> ogra_: Yeah, looks like exactly the same race, just relocated to a different spot in the code.
<ogra_> right
<infinity> ogra_: -l should fix it.  You could also try to forceful syncs, but I don't see the point.  This is exactly what -l is for.
<ogra_> ok
<ogra_> well, i would like to know whats going on, this bothers me
<ogra_> gema, LOL
<vibhav> if XS-Python-Version=all , Then can I set X-Python-Version=$smallest_python_version_number ?
<infinity> ogra_: It'll bother you less if -l fixes it and you never see another bug report. ;)
<ogra_> heh, i still *know* its there
<infinity> (It certainly stopped bugging me after we fixed it in oneiric)
<ogra_> its like that stripe of duct tape holding your engine in place in the car ...
<jtaylor> vibhav: just drop it in that case
<ogra_> it might still work but its an ugly solution
<ogra_> and you know its there under the hood
<infinity> ogra_: Meh.  It worked in oneiric/precise, and no one complained, so I declare that it *is* the right solution. :)
<vibhav> jtaylor: Remove XS-Python-Version ?
<ogra_> heh, ok
<vibhav> Without using x-p-v?
<infinity> ogra_: Mostly because I don't want to try to hunt down all the things that might, potentially, be keeping that mountpoint open for a brief period.
<jtaylor> vibhav: yes, assuming your converting something to dh_py2
<vibhav> jtaylor: yeah, thanks
<ogra_> infinity, yes, and several people tried that in the past
<infinity> ogra_: In all seriousness, anything that might be keeping a file open there will be a child of flash-kernel, so the lazy umount will complete and clean up as soon as f-k is done, which is close enough to what we want anyway.
<nemo> Hm... Is this just my system, or is 12.04 a bit broken in package deps?
<nemo>  trac-wikiprint : Depends: python-pil but it is not installable
<nemo> E: Package 'python-pil' has no installation candidate
<jtaylor> nemo: bug 982669
<ubottu> Launchpad bug 982669 in trac-wikiprint (Ubuntu) "Not installable due to invalid dependency on python-pil, please rebuild to fix" [Undecided,Confirmed] https://launchpad.net/bugs/982669
<jtaylor> looks like a simple fix
<nemo> jtaylor: maybe, but sure doesn't seem like it was made :-p
<nemo> oh well. looks like I need to do my own source build it seems
<jtaylor> I'll fix it
<jtaylor> hm looks like a bug in dh_python2, nice ...
<ScottK> How so?
<jtaylor> it considers python-pil a valid dependency even though it has no installation candidate
<jtaylor> in debian the package does not exist anymore so it is not affected
<jtaylor> in ubuntu it only "exists" due to those two depending on it
<ScottK> Does it think that because it's in requires.txt?
<jtaylor> yes, it guesses it to python-pil
<jtaylor> which it only does if python-pil exists
<jtaylor> actually its a but more strange it should only accept the guess if its installed
<jtaylor> how does it consider it a valid guess
<ScottK> IDK and POX is mostly offline at Debconf.
<jtaylor> :( dig through the source then
<hallyn> Laney: cyphermox: i just dunno.  debian bug 657254 does say that libnl3 was FTBFS with asciidoc and without syntax-highlight.  it builds fine in ppa without.  But MIRing syntax-highlight is a bit daunting bc it depends on boost-defaults
<ubottu> Debian bug 657254 in src:libnl3 "libnl-3-200: Fails to build from source due to missing build-dep on source-highlight" [Serious,Fixed] http://bugs.debian.org/657254
<Laney> is that bad?
<Laney> and I was thinking of another bug I had yesterday with the internets thing
<jtaylor> hm dh_python2 does not validate its guesses at all
<hallyn> is which bad?  needing to MIR boost?  it's a huge chunk of c++ templates near as i can tell...
<jtaylor> how can that be
<Laney> boost-defaults. it's already in main
<hallyn> Laney: yeah, i'm mixing up my packages - meant libboost-regex-dev
<hallyn> hm
<hallyn> so it'll be promoted as soon as something in main uses it, bc its source pkg is in main?
<cjwatson> yeah, moving binaries to main doesn't need paperwork
<Laney> not sure what the main situation is with boost-defaults
<cjwatson> boost-defaults source is in main
<Laney> I see that package has never been in main
<cjwatson> uh
<cjwatson> boost-defaults |   1.49.0.1 |       quantal | source
<Laney> the binary
<cjwatson> oh, right.  but in any case MIRs are per source package ...
<hallyn> right
<Laney> so nothing in main has ever BDed on that. mildly curious, but doesn't matter
<hallyn> point being, i was worryin gover nothing - thanks :)
<ScottK> And boost-defaults isn't the right source.
<ScottK> Or it's not the only one.
<hallyn> eh?
<Laney> for libboost-regex-dev?
<jtaylor> ok, debian is affected it just got build with a dh_python2 version that does not have this "feature"
<jtaylor> time to file 2 rc bugs
<jtaylor> maybe 3, this behavior is very weird
<ScottK> hallyn: nevermind.  libboost-regex1.49-dev is already in Main.
<Laney> haha
<Laney> good old boost.
<ScottK> It's OK.  xnox is in charge of boost now.
<hallyn> ok - i think i'll file MIR for syntax-highlighting then
<hallyn> (just looking through some of the .c files first for sanity)
<Laney> it should be easier as it's only a BD, not something users will get installed for them
<ScottK> jtaylor: Which package are we on?
<jtaylor> ScottK: trac-wikiprint, trac-odtexport
<hallyn> Laney: and especially as there should be no setuid-root programs or daemons :)
<hallyn> of course there are comments like "Currently this looks like a security hole"
<Laney> heh.
<cjwatson> stgraber: ust> thanks - maybe you could syncpackage it if you've checked Ubuntu diffs?  I feel less comfortable auto-syncing things when they're at all complex
<stgraber> cjwatson: I'll have a quick look, and run syncpackage. I believe jbernard used the upstream lttng packaging so it should be identical to what we have currently (except for the source name)
<stgraber> cjwatson: diff looks good. Only problem I see is that we won't have armel and armhf binaries but I'll change that after the sync
<stgraber> jbernard: what's the reason for not going with arch any for these? IIRC lttng-ust builds just fine on armel and armhf and I didn't see any problem with it when I smoke tested on my pandaboard
<barry> jdstrand: apparmor py3 uploaded?
<jdstrand> barry: you bet. I was going to ask infinity to bin deNEW it since we added python3-libapparmor
<barry> jdstrand: awesome
<barry> thanks!
<jdstrand> (I'd do it, but I uploaded it, so I can't)
<jdstrand> infinity: hey, when you get a chance, can you deNEW apparmor? python3-libapparmor was added (and it should go to main)
<jdstrand> looks like they all build
<jdstrand> built
<infinity> jdstrand: Done.
<jdstrand> infinity: thanks! :)
<cnd> infinity: I have a package rename, and I need to transition rdepends on to the new package as soon as possible
<cnd> I've uploaded the new package "evemu", would you be able to review and approve it for me?
<ScottK> cnd: Does it have a transitional package with the old name that depends on the new one?
<infinity> cnd: ^
<infinity> cnd: That may matter for LTS->LTS upgrades... Unless it's just a library.
<infinity> Oh, and it kinda is.
<infinity> Except for the python bindings.
<highvoltage> xnox: btw, we're traveling from miami to managua at the same time. so this is just to let you know that I've marked you as my designated travel buddy.
<xnox> highvoltage: ok. Who are you? =))))
<Laney> The One and Only High Voltage
<xnox> xnox: found you on pad.lv
<highvoltage> Laney said it. well we met at UDS but at least I remember you and should be able to identify you in a crowd :)
<xnox> highvoltage: Hmmm. Now I remember you! =)
<xnox> get excited and make things =)
<highvoltage> :D
<xnox> highvoltage: ok, I have now mapped you in person from UDS to the irc nickname =)
<xnox> canada, eh?! =)
<highvoltage> xnox: oui
 * Laney paws at stgraber 
<Laney> have you seen stuff like http://paste.debian.net/177883/ before?
<Laney> lxc got itself into a bad way somehow
<stgraber> Laney: haven't seen that one yet, no. What kernel are you using?
<Laney> Linux iota 3.5.0-2-generic #2-Ubuntu SMP Tue Jun 26 14:11:06 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
<stgraber> Laney: anything special you had to do to trigger that?
<Laney> I'm not sure how I triggered it
<Laney> I had a container up today, stopped it, suspended & unsuspended a few times, tried to start it again now and it didn't come up, and then saw this in dmesg
<stgraber> it's definitely a kernel bug and looks like a bug somewhere in the network namespace code (based on that refcount entry for the loopback device)
<stgraber> hallyn: ^
<Laney> i'm being spammed by that message now :)
<stgraber> Laney: ubuntu-bug linux
<Laney> aye aye
 * hallyn reads up
<hallyn> oh sigh
<Laney> "This is not an official Ubuntu package."
<Laney> erm.
<hallyn> cyphermox: filed the MIR for source-highlight, fwiw
<cyphermox> cool, thanks!
<hallyn> Laney: hm, try linux-image-generic?  else ask on #ubuntu-kernel
<hallyn> i'm checking the git tree to see what has changed recently
<Laney> yeah that worked, thanks
<hallyn> Laney: wait, do you have cgroup-bin installed?
<Laney> nope
<hallyn> ok :)
<Laney> I do have cgroup-lite, if that means anything
<hallyn> you seem to actually be hung on a mutex, so i was wondering if a task might have been kept frozen after suspend
<hallyn> yeah, it measn your good wrt that
<Laney> bug #1021471
<ubottu> Launchpad bug 1021471 in linux (Ubuntu) "lxc-start sometimes stops starting containers" [Undecided,New] https://launchpad.net/bugs/1021471
<Laney> help me think of a better title :P
<hallyn> 'stuck on mutex_lock creating a new network namespace when starting a container'
<hallyn> Laney: thanks i was just going to ask you the # :)
<hallyn> odd i don't see any changes in net/core/net_namespace.c that woudl cause this
<hallyn> [26205.684141] unregister_netdevice: waiting for lo to become free. Usage count = 1   doh
<hallyn> that rings an atonal bell
<hallyn> feh, gotta be a buggy net driver
<Laney> :)
<hallyn> i'll wait and see if kernel team has an obvious idea, and if not by tomorrow take a closer look
<Laney> i'm going to have to reboot, so i'll lose the broken state until and if it recurs
<hallyn> Laney: if it's not too late, can you first do an lsmod?
<hallyn> just wondering if you have any "special" network drivers
<Laney> yep
<Laney> apport didn't do that?
<hallyn> actually that should be in your log info alraeady
<hallyn> yeah should have, nm, boot away :)
<hallyn> thanks
<Laney> did it anyway just in case: http://paste.debian.net/177888/
<Laney> brb
<BenC> When will things in quantal-proposed be moved to main (IOW, when will the buildd's pick up on it)?
<BenC> Mainly, there are two build failures in quantal universe that will be fixed with the latest build of thunderbird that is in proposed
<BenC> â¦on powerpc
<infinity> BenC: How do the buildds relate?
<BenC> infinity: the rebuild I asked for on enigmail didn't make use of thunderbird 14, it still pulled in 11.0
<infinity> BenC: If you just mean "when will stuff get copied to the release pocket?", it's waiting on the e-d-s transition in -proposed to be complete.
<infinity> BenC: You should have uploaded that to proposed, if you wanted it to build against proposed. :P
<infinity> BenC: Oh, it's just a retry.
<infinity> In that case, yeah, just wait.
<BenC> right
<infinity> Tbird is caught in a transition, it'll be out soonish.
<BenC> Ok, thanks
<infinity> But thanks for the subtle reminder that I should fix armel at some point, now that you fixed PPC to make me look bad.
<BenC> My job is done then
<infinity> BenC: :P
<infinity> BenC: When the ARM hardware in my house gets faster than my PPC hardware, watch out.
<BenC> My actual objective is to indirectly fix arm by making it inferior to an all but forgotten architecture :)
<tedg> slangasek, So I'm a bit confused about bootloaders :-)  For x86 on non-Secure Boot systems are we using GRUB2 ?
<slangasek> tedg: yes
<infinity> BenC: Heh.  Well, I'm sure you're indirectly fixing ARM here and there by fixing generic build failures, and the odd char-signedness issue.
<tedg> slangasek, And then for x86 secure boot systems it's efiboot
<slangasek> tedg: efilinux
<tedg> Ah, yes.  Sorry.
<BenC> infinity: I actually thought that the two fixes I dropped for tbird would fix armel, but I never looked at the problem in the log
<tedg> slangasek, And then ARM is uboot no matter if it's crazy MS thing or not?
<slangasek> tedg: if it's crazy MS thing, we don't get to boot on it anyway on ARM ;)
<BenC> Unpacking libschroedinger-1.0-0:powerpc (from .../libschroedinger-1.0-0_1.0.11-2_powerpc.deb) ...
<tedg> Heh, great.  Reduces the amount of work for me!  ;-)
<BenC> I'm certain I'm in unfamiliar territory now...
<infinity> BenC: No, the armel build is very ARM specific, it's that it's building some bits for v7 when it shouldn't.
<infinity> BenC: I just need to find some "free time" to hunt those down and purge them with fire.
<BenC> infinity: Ah, free timeâ¦the days of my youth
<tedg> slangasek, So is it possible that a system would have both efilinux and grub installed but only be using one of them, or would they conflict?
<tedg> slangasek, Like at the packaging level.
<infinity> BenC: Oh, speaking of porting issues and targetting the wrong CPUs...
<infinity> BenC: I know you don't directly care, since your product is based on a Freescale CPU that, I assume, has Altivec, but when you're doing PPC fixes here and there, can you look out for things enabling Altivec by default and disable that? :P
<infinity> BenC: (Of course, if it's runtime selection, that's perfectly cool, just not build-time)
<BenC> Actually, I've run into that already, and this particular CPU doesn't have altivec
<infinity> BenC: Oh, snazzy.  Then you're on my side.  Good.
<hallyn> infinity: does that mean you know where to look for the tbird and ffox armel FTBFS?
<slangasek> tedg: they would not conflict at the packaging level...the actual in-use bootloader gets written to a special EFI boot partition
<infinity> hallyn: Yeah, I know vaguely what's wrong, I just haven't had the time to fix it.
<BenC> So I'm killing them softly, as if they were -msse or similarly stupid things to have on ppc
<infinity> BenC: Excellent.  If things can do runtime selection, obviously, that's awesome, but yes, thanks for killing the compile-time stupidity as you spot it.
<hallyn> infinity: rockin', cause i didn't know how to tell if the code was wrong, or the toolchain flags (specified processor)
<tedg> slangasek, So, how do I know which bootloader was used to boot the system?
<infinity> hallyn: It's a twisty maze of configure breakage, nothing specifically wrong with the code.
<slangasek> tedg: that's a good question
<slangasek> tedg: but I'm not sure it's actually the right question :-)
<slangasek> tedg: what is it you really want to know?
<tedg> slangasek, Well, two things.  How do I determine if I want to change the boot parameters which one I should change?
<slangasek> tedg: right - so I would say they *both* need to be changed
<hallyn> jinkeys, libcommons-compress-java wants a non-existing package ( libxz-java )
<tedg> slangasek, Then the other would be, how do I check to see if the last boot was successful.
<tedg> slangasek, i.e. fail, then fallback, I want to report the fail.
<tedg> slangasek, But, if I change both and call the "install" routine for both wouldn't that install each of them in order into the magic EFI partition?
<slangasek> tedg: ah - so actually, we're going to have a shim bootloader in front of all of this
<slangasek> tedg: and *that* is the one installed to the magic EFI boot path
<slangasek> tedg: and it will be <handwavy> able to detect whether SB is enabled, and select the correct bootloader based on this
<tedg> slangasek, That's only in the Secure Boot situation, right?
<slangasek> well
<slangasek> how do you know a machine is in the Secure Boot situation or not?
<tedg> Could efilinux and grub be installed in the non-SB situation?
<tedg> I don't, I'm hoping you'll tell me ;-)
<slangasek> you only know two things: 1) the machine we're installing on does or does not claim to implement Secure Boot in firmware, 2) Secure Boot is currently enabled
<slangasek> do you want the machine to stop booting on a firmware upgrade?
<slangasek> or when the user toggles the setting?
<slangasek> if not, we need to start installing the whole kit'n'kaboodle whenever we're doing EFI
<tedg> So I guess I need to know whether we're BIOS or EFI then?
<tedg> Could a non-EFI system have efilinux installed?
<tedg> Seems like they could...
 * tedg is thinking bad things would happen...
<hallyn> is there a way to tell who sync'd a particular package?
<hallyn> don't see that info in the publish history
<Laney> quantal-changes / api
<Daviey> hallyn: Wanna write,  lp-sync-blame-and-finger-point-perhaps-berate ?
<hallyn> trying to tell whether whoever syncd libcommons-compress-java was planning to sync and MIR libxz-java (which it now depends on)
<Daviey> hallyn: Mr Page.
<hallyn> ah thanks
<hallyn> jamespage: are you working on sync request for libxz-java ?
<jamespage> hallyn, nope - want me to?
<hallyn> jamespage: libcommons-compress-java is currently waiting for it.  but that measn it'l lbe waiting until it's both sync'd and MIRd.
<jamespage> hallyn, marvellous
<hallyn> jamespage: so i dont know if libcommons-compress-java should be / can be built without it
<hallyn> jamespage: but if possible, yes please :)
<hallyn> eh, i personally prefer to try and build without it, but that sounds anti-java and probably impossible
 * ScottK finds nothing against being anti-Java in the CoC.
<hallyn> oh hey, look at that.  libgweather-3-dev is sitting in quantal-proposed
<hallyn> i apparently need to read up, i thought q-proposed would mainly be used during freezes?
<hallyn> ScottK: i just meant that i wasn't sure you could disable parts of a java package like that (as with configure flags during a regular build)
<ScottK> Well, being anti-Java myself, I was just being careful to make sure we weren't starting to establish a precedent that being anti-java was somehow 'bad'.
<hallyn> heh
<hallyn> i don't admit to being anti-java, but am eccstatic jamespage is willing to look at it :)
<stgraber> hallyn: -proposed is also used for transitions to prevent skew (currently the case for the eds transition)
<hallyn> stgraber: in the case of libgweather vs evolution that sems to have failed :)
<infinity> hallyn: sync request for libxz-java?
<infinity> hallyn: Wouldn't it need to exist somewhere to sync it?
<hallyn> infinity: it's in sid
<infinity> Not by that name...
<hallyn>  libxz-java | 1.0-1 | sid | all
<infinity> Oh, that's built from xz-java.
<infinity> Which is in Ubuntu.
<hallyn> d'oh
<infinity> (base)adconrad@cthulhu:~$ rmadison -S xz-java
<infinity> libxz-java |      1.0-1 | quantal/universe | all
<infinity> libxz-java-doc |      1.0-1 | quantal/universe | all
<infinity>    xz-java |      1.0-1 | quantal/universe | source
<jamespage> hallyn, so its just that it eithe needs an MIR or we need to disable it
<hallyn> jamespage: yup
<hallyn> robert_ancell: hi - i notice libgweather is in quantal-proposed.  is that just while awaiting some testing?
<hallyn> (evolution's build is hung waiting for that version)
<robert_ancell> hallyn, no, it just needs the archive admins to release it to quantal
<hallyn> robert_ancell: cool, thanks
<robert_ancell> infinity, who clears out quantal-proposed?
<infinity> robert_ancell: Me, if your transition is done.
<Laney> hm
<Laney> why didn't the depwait get cleared by the quantal libgweather3-dev?
<Laney> quantal-proposed*
<infinity> It only got published recently, people might be impatient.
<Laney> I guess I don't know how long whatever spells makes that happen are cast
<infinity> Laney: They happen post-publishing, so there's a bit of an irritating delay.
<hallyn> infinity: i'm pretty sure the FTBFS list i'm looking at is from this morning...  i'm afraide i have no concept how long one should normally wait
<hallyn> don't mean to be a pest
<infinity> Laney: dep-wait mangling is another thing on the long list of "could be done a lot better".
<infinity> hallyn: I only let gweather through NEW a little while ago.
<Laney> As long as it's not a bug with using proposed, I'm willing to not care
<infinity> It *shoudln't* be a problem with pockets, since I'm pretty sure we've hit dep-waits that DTRT in security before.
<infinity> But I kinda want to wait a bit and make sure now. :P
<infinity> Oh, yeah, it's working.
<infinity> You can tell from the other awesome LP bug.
<infinity> (Trying to give-back a package that's dep-wait on something currently in the locked/being-cleared set causes a UI timeout instead of an error)
<hallyn> yay, cjwatson has requested jbigkit MIR so i don't haveta
<infinity> robert_ancell: So, to confirm, e-d-s-in-proposed is all done?
<infinity> robert_ancell: gnome-panel being universally FTBFS could be an issue.
<robert_ancell> infinity, I uploaded an e-d-s with a fix
<robert_ancell> (it was a dependency missing on a -dev file)
<robert_ancell> just waiting for publishing before rebuilding gnome-panel
<infinity> robert_ancell: Check, I see that.
<infinity> robert_ancell: So, it's safe to say that when gnome-panel's done, you're good to go?
<infinity> (Well, gnome-panel, and evo...
<infinity> )
<robert_ancell> yup
<robert_ancell> yeah, once all the gears have cranked
<infinity> Alright.  When it's all built and published, I won't ask again, then, I'll just do.
<robert_ancell> infinity, what is the criteria for moving from -proposed?  Just all the dependencies have built successfully?
<infinity> robert_ancell: Normally, the criteria would be "it won't make anything in the release pocket break".
<infinity> robert_ancell: Well, and "all arches have built".
<infinity> robert_ancell: Thunderbird/armel gets a pass on that, since it's also not built in release.
<cyphermox> infinity: I rather perhaps waiting a bit more
<infinity> cyphermox: ?
<cyphermox> libreoffice should theoretically also be rebuilt; I want to check on it
<cyphermox> there's still going to be a few more packages that will need fixing after too
<infinity> libreoffice is already 17 transitions behind, I'm not sure it matters here.
<cyphermox> fair enough
<infinity> Well, unless moving these packages makes libreoffice uninstallable.
<infinity> If it does, then we have to wait.
<ceti331> hi
<cyphermox> let me finish up nautilus-sendto then
<ceti331> Greetings, i'm trying to compile compiz\plugins\expo ; link error "cannot find -lcomposite" "cannot find -lopengl".
<ceti331> any idea what i've missed ?
<infinity> ceti331: apt-get build-dep compiz
<ceti331> ok
<ceti331> sudo apt-get build-dep compiz
<ceti331> oops
<ceti331> ok thats installing tonnes
<cyphermox> infinity: libreoffice-evolution has no reverse-depends, it's probably fine
<infinity> cyphermox: rdeps aren't the issue, it's if it becomes uninstallable itself.
<infinity> Which it currently isn't, despite depending on NBS stuff.
<cyphermox> well, libreoffice-evolution does have a versioned depends on libreoffice-core, so it would
 * xnox did libreoofice-evolution ever worked?!
<infinity> So, I don't see that changing.
<infinity> cyphermox: Erm, I'm not sure I see how that would matter.
<cyphermox> but I suspect very few people have libreoffice-evolution installed, since it isn't depended on by anything
<infinity> cyphermox: I don't follow your logic.  Yes, all of libreoffice has versioned deps to the rest, so...?
<cyphermox> so I'm getting mixed up in logic
<cyphermox> l-evolution depends on libebook-1.2-12; that's what is going to be a problem
<infinity> Sure, but libebook-1.2-12 is already NBS, isn't it?
<cyphermox> I see that now
<infinity> Yeah, it is.
<infinity> So, as long as the new e-d-s libs don't conflict with the old ones, we're fine.
<ceti331> Ok. still same problem. it installed a lot of new stuff; i did cmake in a new plugin build directory
<cyphermox> infinity: libreoffice-evolution is already not installable.
<infinity> ceti331: You might want to check the topic.  This isn't really the right channel for this.
<infinity> cyphermox: That's patently untrue.
<cyphermox> infinity: I certainly can't install it now
<ceti331> whats the best channel
<cyphermox> well, not without breaking a lot of things
<infinity> apt-get install libebook-1.2-12 libreoffice-evolution <-- Works here.
<cyphermox> infinity: it wants to remove evolution-data-server libfolks-eds25 here
<infinity> Oh, because e-d-s breaks libebook-1.2-12.  Argh.
<infinity> A) Britney appears not to check for that.
<infinity> B) WHY DOES IT DO THAT?!
<infinity> (The breaks, I mean)
<cyphermox> yeah
<infinity> I guess because the library depends on the server version.
<infinity> Silly design.
<infinity> So, yeah.  You're right.  libreoffice-evo is just busted anyway.
<cyphermox> that particular thing didn't change in this transition though
<infinity> So, we won't make it worse.
<infinity> Sweetshark: Seriously, are we going to see a new LibreOffice soon?  It's falling woefully behind in several library transitions.
<cyphermox> infinity: my guess is at least for libreoffice-evolution, if upstream hasn't done the porting yet (and I suspect they didn't), it's going to need a substancial amount of work
<infinity> cyphermox: Has the API for libe* changed that drastically?
<cyphermox> enough to be painful
<cyphermox> enough that I spent four hours porting indicator-datetime with varying amounts of success, and gave up on evolution-exchange
<infinity> Fun.
<infinity> Stick apw on it.  He was a wizard with the libpoppler porting effort. ;)
<cyphermox> evolution-exchange will get fixed by upstream, if it hasn't been already since yesterday
<ceti331> whats the right channel for asking about a compile problem
<jbernard> stgraber: I had restricted urcu's arch to only those supported at the time, so I matched ust and ctl to match.
<jbernard> stgraber: bug now that I look again, there's no reason to set to all
<jbernard> stgraber: ill make that change change will my next upload
<jbernard> stgraber: which should be within the next day or so
<jbernard> stgraber: er, there's no reason to not set to all. sorry
#ubuntu-devel 2012-07-06
<cyphermox> ceti331: it was an issue with compiz right? have you tried #compiz?
<ceti331> hah
<ceti331> its an issue with building ubuntu's fork of compiz
<ceti331> they didn't know and advised i came here
<cyphermox> oh boy
<ceti331> "i dont know, i've never used their bzr stuff..."
<cyphermox> the expo plugin isn't specific to ubuntu though
<cyphermox> ceti331: join #ubuntu-desktop, ask smspillaz, he might know
<ceti331> before getting it compiling, we found that the git version from compiz was incompatable with the ubuntu-build framework
<ceti331> i.e. i can't compile compiz.org's expo source here in ubuntu , but i can from launchpad :)
<ceti331> ah ok
<ceti331> thanks
<cyphermox> I'm not sure I follow, are you trying to build the compiz package?
<ceti331> my goal is to modify some of the compiz plugins or how they are triggered. I miss my Mac, but in theory one should be able to modify ubuntu to be as efficient...
<ceti331> i'm just trying to build "expo"
<zul> is someone from the MIR team still around?
<Shinobi> I have a corrupt link. How can i fix?
<Shinobi> I can't delete it
<robert_ancell> infinity, I think they're all built now
<infinity> robert_ancell: Alrighty.
<pitti> Good morning
<alazare619> can someone explain the ubuntu seed files to me
<alazare619> im trying to figure out how to build one
<pitti> alazare619: https://wiki.ubuntu.com/SeedManagement documents how they work
<micahg> BenC: llvm-2.8 should just be removed from quantal as it was from Debian
<infinity> micahg: Oh, yeah, I meant to do that.
<infinity> micahg: 2.9 as well, but llvm-py hasn't been ported to 3.x yet, AFAIK.
<alazare619> livecd-rootfs tools is not correct
<infinity> alazare619: I disagree.
<micahg> infinity: at least llvm-2.9 isn't on the FTBFS list
<infinity> micahg: It's not?  It sure used to be.
<alazare619> the auto build script is missing a setup for --syslinux-theme "$project"-"$suite" \ needs to be added
<alazare619> otherwise it always uses onerics theme for syslinux
<infinity> Silly people fixing LLVM.
<infinity> micahg: Alright, I'll just yank 2.8 and leave 2.9 alone for now.
<micahg> infinity: silly me syncing the fix :)
<infinity> alazare619: We don't create ISOs with livecd-rootfs.  (so, for us, it's correct).
<alazare619> you guys create seed files for the livecd-rootfs system with live-build
<infinity> alazare619: But please do file a bug about your issue anyway, for when we decide to try to make live-build actually spit out Ubuntu ISOs.
<infinity> alazare619: Erm.  We do what now?
<alazare619> ok do explain how you build iso's then
<alazare619> cause the seed files on ubuntu's wiki point to live build seed files
<infinity> alazare619: live-build doesn't take seeds as input.  We ask live-build to install package sets via our configs in livecd-rootfs, yes.
<infinity> alazare619: But that all just spits out a squashfs on the other end.  Not an ISO.
<alazare619> i understand that
<alazare619> so the livecd-rootfs script has an error
<alazare619> does ubuntu devel not handle that?
<infinity> Kay.  And since syslinux doesn't exist in the squashfs, that's why I said the above bit doesn't matter to us.
<infinity> The auto/* scripts in livecd-rootfs are specifically for how Ubuntu builds CDs.
<alazare619> yes
<infinity> If you need something different locally, please do fork from there and tweak.
<alazare619> and thats where there should be a changed line tho
<infinity> But a bug for you isn't (necessarily) a bug for us.
<alazare619> line 276 should be --syslinux-theme "$PROJECT"="$SUITE"
<alazare619> of config in livecd-rootfs
<alazare619> livecd-rootfs/auto/config
<alazare619> = = -
<alazare619> = is - in the line 276 i mean
<infinity> alazare619: For you, yes.
<alazare619> without that being set it defaults the build to ubuntu oneric theme is what im saying
<alazare619> why for me what am i doing diffrent then "ubuntu"
<infinity> alazare619: You understand what I'm saying when I say that we only use this to build squashfs filesystems that don't have syslinux (or a syslinux theme), because they're not ISOs?
<alazare619> well yes i do
<infinity> What you're doing differently is building an ISO.  We do that with an entirely different set of scripts (debian-cd), which you almost certainly don't want to use.
<alazare619> well yes and no
<infinity> And there's nothing wrong with you using live-build and even livecd-rootfs to do what you're doing.  What I'm saying is that your config WILL differ from ours.
<alazare619> who and what actually manages the iso building then
<infinity> So your bugs aren't our bugs.
<alazare619> to pass the argument per say to them or will that never be incorporated since you guys dont use live build to build the iso too
<alazare619> wich i thought was true according to ubuntu wiki live build is used to build the iso too
<infinity> Where on the wiki does it say that?
<infinity> It's a lie if it does. ;)
<infinity> But, some day, we'll fix live-build to produce ISOs that match "official" Ubuntu ISOs.  Probably.  And then ditch our weird infrastructure.  That day isn't today.
<infinity> Anyhow, for now, anyone who wants to build an ISO with live-build can't use our configs exactly.  That's pretty much what I'm driving at.
<alazare619> im willing to help fork live-build so it produces it properly
<alazare619> but what exactly does live-build do wrong that it shouldnt?
<infinity> Good question.  It's on my TODO to look into it at some point.
<infinity> We've always done livefs and ISO building in two stages, and we, frankly, didn't trust the shiny new tool to do just do it all for us, so we didn't let it. :P
<infinity> We'll fix that at some point.
<pitti> I haven't followed the whole discussion; just want to mention that the official Chinese images are being built with ubuntu-defaults-image, which uses live-build all the way (with some tweaks)
<pitti> it does differ from the Ubuntu images indeed, though (most notably it does not have a pool)
<alazare619> yea only tweak ive done so far was add that line to the livecd-rootfs auto script
<alazare619> and changed config/chroot-local_hooks to config/hooks
<alazare619> as the new livebuild removed the chroot-local_ from it
<infinity> pitti: Is it?  nusakan doesn't touch it, except to publish it?
<pitti> no, it's built from nusakan
<pitti> well, "triggered by"; I guess it's actually built on the buildd machines, just like the regular livefses
<infinity> pitti: Okay, so yeah.  Like I said, "nusakan only touches it to publish it?"
<infinity> pitti: If so, handy datapoint to know.
<pitti> right
<infinity> pitti: So, maybe this man wants to talk to you about ubuntu-defaults-image. :P
<pitti> alazare619: if you only want to install some additional packages or do some tweaks, ubuntu-defaults-image is indeed much easier to use
<alazare619> nah
<alazare619> i want the full blown process
<pitti> it won't help you much for really invasive modifications, though
<alazare619> im actually a sys admin lol
<alazare619> its a pet project i have going in down time at work
<pitti> u-d-i more or less configures live-build to produce an Ubuntu-ish image
<alazare619> trying to build a distro with qt-razor by default and gnome-shell
<alazare619> ive done live-build with debian base of squeeze and wheezy and sid never ubuntu tho
<alazare619> but i actually want live build setup for auto so i can crontab the job to do a full clean and rebuild once a month for a new up to date iso
<alazare619> no real reason other then to say i did it
<dholbach> good morning
<seb128> cjwatson, slangasek, xnox, stgraber: is anyone looking at the ubiquity issue which is breaking the quantal dailies for 2 days?
<xnox> seb128: yes. i have been.
<seb128> xnox, how is that going? likely to be fixed today?
<xnox> i got the 900MB big strace, which clearly shows SIGPIPE in apt.
<xnox> seb128: either a fix, a workaround, or a downgrade should happen soon.
<seb128> xnox, right, so I guess one of the updates of 06-29 broke it?
<xnox> seb128: well. apt & python-apt were updated =)
<seb128> xnox, right, and ubiquity
<xnox> yeah.
<brendand> seb128, is there a bug number?
<brendand> (of course there is)
<seb128> brendand, bug #1020574
<ubottu> Launchpad bug 1020574 in ubiquity (Ubuntu) "SystemError: Broken pipe while installing language packs" [Critical,Confirmed] https://launchpad.net/bugs/1020574
<jamespage> hallyn, MIR already raise for xz-java
<xnox> and now it has full strace attached as well.
<dpm> cjwatson, RAOF, I think you're the only ubuntu-sru members online right now. So if you're around, may I ask you to have a look at bug 1018038 and approve the upload to precise-proposed? We're nearing the deadline for the Ubuntu App Showdown contest, this bug is blocking submissions and it would be very helpful to have it at least fixed in -proposed
<ubottu> Launchpad bug 1018038 in quickly (Ubuntu Precise) "When using submitubuntu, should build depend on libglib2.0-bin" [Medium,Triaged] https://launchpad.net/bugs/1018038
<RAOF> dpm: You appear to be adding more than just libglib2.0-bin to debian/control; is that intentional? Also, you seem to be adding debhelper (>= 6) twice?
<dpm> RAOF, mterry did the change and the upload, but I can look at how the update_file_content() function works to see if they're really duplicate arguments
<RAOF> dpm: Ah, no. Reading context makes that clear.
<dpm> ok, cool
<didrocks> RAOF: dpm: update_file_content take a start/end stenza
<didrocks> which are the second and third arg
<didrocks> and replaces this with the 4th :)
<RAOF> didrocks: Yeah, now that I've read the source that makes sense. Without reading the source the patch looks weird.
<didrocks> RAOF: I wrote it for updating the copyright in every files, hence the start/end need. Interesting mterry used it for that :)
<RAOF> dpm: Doneinated.
<dpm> RAOF, \o/ thanks!
<RAOF> SpamapS: Have you deliberately left a bunch of syncs from -proposed to -updates in the precise queue?
<infinity> slangasek: There, new dpkg now prints errors to stderr, My PickyPants. :P
<xnox> infinity: 8)
 * dholbach hugs seb128
 * seb128 hugs dholbach
<dholbach> :)
<seb128> dholbach, for once I did my piloting shift in solid way (I've been slacking for some of the previous ones, or rather too busy with other things to do a proper job of it)
<dholbach> yeah, I can imagine
<infinity> seb128: Does that mean you cleared out the queue, so I don't have to pilot when I wake up?
<infinity> seb128: Splendid.
 * infinity will sleep better now.
<seb128> infinity, lol, not quite
<seb128> infinity, but if somebody wants to clear the SRU queue a bit, we are getting close of 40 items unapproved
<seb128> slangasek, ^
<seb128> we are getting close from LTS freeze and things move too slowly atm, it's going to be an issue soon if we keep this delay in reviews
<infinity> seb128: I'll do a bit of cleaning up tomorrow.
<seb128> thanks
<infinity> seb128: slangasek is already at DebConf, so I suspect he'll be less inclined to SRUify.
<seb128> right
 * infinity isn't sure what the complaint is, as he uploaded an SRU earlier today that got through unapproved in a matter of minutes.
<seb128> the 4th of July and Canadian day didn't help this week either ;-)
<infinity> seb128: Nope.  Clearly not.  Silly fireworks.
<seb128> infinity, can I cheat and wave my SRUs through? ;-)
<seb128> is that what you did? ;-)
<infinity> seb128: I didn't cheat, I had RAOF review mine. :)
<seb128> lol
<infinity> On the other hand, it was a reeeeealy easy review.
<infinity> Anyhow, I'll poke the queues tomorrow.  Seems like a better plan that starting any long-term projects before I jump on a plane.
<infinity> seb128: Any specific urgencies, or just "everything"?
<RAOF> seb128: And in general, feel free to ping (particularly on Tuesday); I'm happy to process the SRU queue in an order that's not strictly FIFO.
<seb128> RAOF, noted, thanks
<seb128> infinity, out of "getting some progressed" I would like to see ubuntu-sso-client in, it has some of the most reported issues on errors.ubuntu.com
<infinity> seb128: Check.  I thought that was on Steve's hitlist when he filled in for me on Monday?  Maybe not.
<infinity> seb128: Anyhow, I'll start there, and then just get FIFOish until I get bored.
<seb128> thanks
<infinity> dholbach: I may steal some piloting time tomorrow to do SRU stuff instead, since this week's been a mess for that. :P
<seb128> I can do some extra sponsoring in exchange
<Daviey> infinity: Hey, you are in the MIR team, right?
<infinity> Daviey: I am now/again, yes.  Talk to me about it in ~6.5h  I'm going to sleep.  Honest.
<dholbach> awesome
<dholbach> infinity, sleep tight
<Daviey> infinity: ok, sleep tight.
<infinity> Daviey: Better yet, talk to mterry, cause he's +1 this month, and MIR and +1 kinda go hand-in-hand. ;)
<Daviey> infinity: I try to spread the world of pain we induce.
<infinity> You could introduce less pain instead.
<infinity> Just a thought.
<Daviey> Nah, no fun tere.
<infinity> Says you.
<Daviey> infinity: sure you don't want to take a real simple package?  it's a single py file. :)
<infinity> Bug me in the morning.
<Daviey> ok, thanks.
<Daviey> didrocks: Hey, how are you doing? :)
<infinity> Only C and POSIX shell are simple at this time of night.
<infinity> Everything else is voodoo.
<didrocks> hey Daviey, I'm fine, thanks!
<didrocks> and yourself?
 * xnox wonders if single.py file is like bzip2 base64 encoded binary blob ~3MB in size, similar to waf
<Daviey> didrocks: Pretty good.. As you are around and all.. fancy taking a seemingly simple MIR request?
<Daviey> <silence>
<didrocks> Daviey: if it's simple, I'm all for it. I still have on my backlog some long, complicated, and interdependant ones :)
<didrocks> but don't lie, it has to be simple now! :)
<Daviey> didrocks: bug 1021528 .. it really is just a 45 line python script packaged.
<ubottu> Launchpad bug 1021528 in python-setuptools-git (Ubuntu) "[MIR] python-setuptools-git" [Critical,New] https://launchpad.net/bugs/1021528
<didrocks> Daviey: sounds easy enough, looking now :)
<Daviey> much appreciated.. (it will be blocking openstack milestone uploads later today)
<didrocks> Daviey: will be quickly done
<didrocks> Daviey: I'm surprised, isn't openstack on launchpad?
<didrocks> they are using git now?
<tumbleweed> is setuptools-git even used in the Debian build process?
<Daviey> didrocks: It's complicated.. github for code hosting,  self hosted gerrit for code review, launchpad for bugs and bluepritns.
<tumbleweed> surely it's something that's trivially patched out?
<didrocks> Daviey: wow, quite an interesting setup!
<Daviey> tumbleweed: well it is easily patched out.. yes.. but long trm, that is more work than having a tool do it for us.
<didrocks> (I like the except: comment btw :p)
<tumbleweed> Daviey: but when you are building from a orig tarball there's no git repository for it to use
<tumbleweed> so it adds no value
<jamespage> can someone give me a clue as to what I've done wrong here - https://launchpadlibrarian.net/109452563/buildlog_ubuntu-quantal-i386.hsqldb_1.8.0.10-13_FAILEDTOBUILD.txt.gz
<Daviey> tumbleweed: Stop raising seemingly valid points.
<didrocks> Daviey: I'm interested and about to raise the same question btw :p
<cjwatson> I tend to think it's not worth patching out trivial bits of build system to avoid having them in main
<cjwatson> Unless it's going to pull in some giant stack of stuff
<didrocks> basically their build system is not shipping the MANIFEST file, right?
<tumbleweed> however, these setuptools plugins that rely on the VCS to know what to include in a package break when you don't have the vcs metadata
<Daviey> well, i admit i haven't dug into this myself.. i'm merely shepherding.. but base don the request, it seemed logical considering it's a 45 line python file with no deps.
<tumbleweed> so you often end up having to patch MANIFEST.in
<cjwatson> tumbleweed: It depends whether it's going to fail hard, or just fall back to looking at the tarball
<didrocks> Daviey: speaking of no deps, it should dep on git I guess :)
<tumbleweed> cjwatson: yeah
<xnox> jamespage: do you really have dpkg-checkbuilddeps: Unmet build dependencies: "build-essential:native" in your package deps? If not, then it's a bug in buildd or something =)
<tumbleweed> actually MANIFEST.in is for sdist, but one does have to frequently touch package_data in the setup.py
<xnox> jamespage: surely you never add build-essential to depends......
<jamespage> xnox, no - and the test build I did worked fine locally using sbuild
<jamespage> xnox, hence my 'either its broken or I'm being dumb' style question :-)
<infinity> That would be the new dpkg.
<Daviey> didrocks: Hmmpf.. on the face of it, this might be just for generating the source package.
<infinity> Which so shouldn't be doing that...
<tumbleweed> Daviey: I think it is. But as cjwatson said, if having teh package avoids patching, it's useful
<Daviey> tumbleweed: That is what i said initially :/
<xnox> infinity: well looks like fallout from .5 - but HOW?! http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=558095
<ubottu> Debian bug 558095 in dpkg-dev "dpkg: please accept ":native" multiarch qualifier in build dependencies" [Wishlist,Fixed]
<infinity> xnox: Yeah, I knew exactly what change broke it when I saw it.
<infinity> xnox: What I'm not sure about is how no one saw this. :/
 * infinity sighs as he goes about fixing.
<xnox> Daviey: well, for example gnome conditially includes git make snippet, to do build-from-git-foo. But it still builds fine without git.
<infinity> Sleep is for the weak anyway.
<xnox> Daviey: are you saying that upstream will not accept a patch: "build from tarball, without git, if no git available"?
<tumbleweed> or conditionally import git integration when the command is sdist
<Daviey> xnox: I'm not saying anything :)
<xnox> =)))
<xnox> Daviey: I'm not volunteering for writing any patches either ;-)
<Daviey> bah
<didrocks> Daviey: added some comments, but looks overall good apart from some quick fixes needed
<infinity> jamespage: Thanks for the heads-up.  Rebootstrapping a fixed dpkg now. :/
<jamespage> infinity, np
<infinity> I'll have to look later into why this appears to have blown up for us but not caused a huge mess in Debian.
<cjwatson> infinity: Maybe it matters that our sbuild understands :any build-deps?
<infinity> cjwatson: It's not sbuild failing, it's dpkg-checkbuilddeps.
<cjwatson> mm, ok, I can't think of a plausible way sbuild could be involved there :)
<infinity> And it doesn't fail for me in a Debian chroot, only Ubuntu.
<infinity> So, all I can think is that Steve's workaround hack had some fallout interaction here.
<infinity> But since it's simple to back out the :native from checkbuilddeps for now to "fix" it, we can look at root causes and fixes later.
<infinity> For now, I just need to make the chroots happy and get us building again.
<infinity> cjwatson: Hahaha.
<infinity> cjwatson: So, it could just be that the patch is busted. :P
<infinity> cjwatson: Yup, confirmed.
<infinity> cjwatson: Debian's build-essential isn't M-A:foreign, but ours is.  Apparently, a native-arch build-dep that's marked M-A:foreign isn't "native" in this feature's world.
<infinity> cjwatson: So, making the obvious(ly wrong, but will work for now) fix right now, and we can look into fixing this to not be broken later.
 * cjwatson tries to understand that and concludes coffee and breakfast would help.
<cjwatson> Rather you than me :)
<mvo> apw: if you could later check #1021298 that woudl be cool, it probably just shows my ignorance about ipv6, but help would be welcome (but lunch first :)
<apw> mvo, ok
<apw> bug #1021298
<ubottu> Launchpad bug 1021298 in squid-deb-proxy (Ubuntu) "squid-deb-proxy should advertise and use IPv6 addresses" [Medium,In progress] https://launchpad.net/bugs/1021298
<apw> mvo, can i have an ifconfig -a from the box which reports the error please
<apw> mvo, and the output of /usr/share/squid-deb-proxy-client/apt-avahi-discover
<apw> mvo, and avahi-browse -kprt _apt_proxy._tcp
<apw> mvo, belay all that, i've made a new network to test this on
<apw> mvo, i'll sort it out and get the branch updateds
<Daviey> didrocks: thanks
<infinity> cjwatson: Now that the crisis is averted, I might sleep on this before I upload the proper fix, but does this look sane to you for a correct interpretation of what should really be happening?
<infinity> cjwatson: http://paste.ubuntu.com/1077890/
<cjwatson> infinity: the multiarch spec explicitly says "so long as the [package build-depended on using :any] declares itself as Multi-Arch: allowed"
<cjwatson> so I don't think it's correct to extend that in dpkg without spec work
<infinity> cjwatson: Oh, so the fact that the previous dpkg-dev (ie: the one in precise, and everything up until just now) allowed "foreign" was a bug? :P
<cjwatson> well, a bug in either dpkg-dev or the spec :)
<infinity> cjwatson: Well, allowed foreign, host, and all.
<infinity> cjwatson: But okay, I can scrap the "fixes" to any to revert behaviour.
<cjwatson> ok, if it's restoring previous behaviour then fair enough for now
<infinity> We didn't use it much anyway, and I think we only used it for allowed stuff.
<infinity> (gettext was allowed, anyhow)
<cjwatson> the :native change looks ok as long as $a is the architecture of the package and not the current architecture or something
<infinity> $a is package, $host and $build are what you'd expect.
<infinity> (And the day those don't seem semantically backwards to me is probably the day I get a lobotomy)
<cjwatson> it's worse when you encounter packages that permute the semantics of build/host/target ...
<cjwatson> (I'm looking at you, nspr.  Or maybe nss.  IIRC they permute them *differently*.)
<infinity> At least "target" probably only has one sane meaning.
<cjwatson> I'm pretty sure at least one of those makes it mean host.
<infinity> And by host, you mean build?
<infinity> Cause I'd argue that target should mean host.
<cjwatson> I meant autotools host.
<cjwatson> But I could be misremembering; this was a while back.
<infinity> Aaaanyway.
<infinity> I'll revert the :any bits, if that's getting us closer to spec.
<infinity> Yes, I'm restoring previous behaviour, but no, I don't care to.
<cjwatson> Check with Steve first.  Since he wrote that spec and the original :any patch, he should know ...
<infinity> I suspect you'll find that 99% of our :any build-deps are all gettext anyway. :P
<cjwatson> I might just be missing some extension spec somewhere
<cjwatson> https://wiki.ubuntu.com/MultiarchCross
<cjwatson> So that also says :native on foreign is disallowed.  Why?
<infinity> That makes no sense.
<infinity> So, the patch was implementing the spec, but I'd argue the spec is wrong. :P
<infinity> I'll talk to Steve about it before I fix anything.
<infinity> My current workaround has us over the panic anyway.
<cjwatson> It's not *necessary* to use :native for M-A: foreign, but I can't see why it should be *disallowed*.
<cjwatson> But yeah, Steve may remember some argument that led to this.
<infinity> Very weird indeed.
<infinity> Cause I can't, for the life of me, determine a difference between a package with any M-A header or one without, if they're all BUILD_ARCH (ie: native).
 * infinity shakes his head.
<infinity> Sleep with fix everything.
<infinity> I also note that table assumes some cleverness on the part of the resolver.
<infinity> I wonder if the latest sbuild is actually that bright about selection.
<mvo> apw: thanks a bunch!
<mpt> What are the use cases for the "Source code" checkbox in Software Sources? (1) Meeting GPL etc requirements to provide source code. (2) Letting developers get the code to fix a package. (3) ...Anything else?
<mpt> ((2) being somewhat replaced by "bzr branch lp:ubuntu/name-of-package")
<tumbleweed> there's also pull-lp-source which doesn't use APT
<tumbleweed> (replacing 2)
<tumbleweed> apt-get build-dep requires deb-src entries, but one can use mk-build-deps instead
<cjwatson> source packages significantly better mirrored and thus much faster to download than bzr branch lp:...
<xnox> mpt: (3) allowing people to easily rebuild packages with local patches / changes for example. Which system administrators often do. And users often do by following online tutorials/howtos.
<mpt> ok
<xnox> mpt: (1) is kind of not true. We provide the sources on our servers and mirrors. we actually do not require to force include downloading deb-src lines to comply with GPL. with GPL you must provide source "upon request" and a check box is easy to do that ;-)
<tumbleweed> xnox: which makes 1 a use case for that checkbox
<xnox> tumbleweed: yeah I know =)))))) i somehow looped in my argumentation.
<xnox> while true:
<xnox>     punish(self)
<mdeslaur> hrm, why _do_ we enable deb-src in a default install? besides taking longer to download Sources files, is there a particular reason why all our users would need that by default?
<xnox> bdmurray: i was pondering if we can harvest launchpad bugs to find out how many % people have: normal installs, lvm installs, crypt installs, RAID installs
<xnox> bdmurray: I understand that it would be under-reported. but still any numbers would help even to see at least any correlations.
<hallyn> jamespage: \o/ thanks
<jamespage> hallyn, TBH I did not really do anything other than look :-)
<ScottK> Laney: Are the libs the depend on the libxml .la file in packages that are in Ubuntu, but not Debian?  Without really looking at it in detail, it seems to me that getting rid of those dependencies is the thing to do.
<Laney>  I don't know. Aron said he'd taken care of Debian, but I didn't check for him.
<Laney> and yes. See the bug I filed. There are only two packages.
<ScottK> OK.
<Laney> since they are both hosed atm, it was easier to unblock the update by just keeping it for now
<ScottK> I accepted it.  Please go back and clean up after they're fixed.
<Laney> cheers
 * BenC saw a notice on this window but can't find it
<cjwatson> BenC: 06:24 <micahg> BenC: llvm-2.8 should just be removed from quantal as it was from Debian
<cjwatson> ... ah, the answer to "how did this ever possibly work" is "it didn't"
<cjwatson> that makes more sense.
<apw> am i expecting usb sticks to be mounting on /run/media/blah now, and if so should /media point to /run/media (which it does not on my system)
<Daviey> apw: I thought it was agreed it would be reverted... seb128 & slangasek know more
<Laney> bug #1020759
<ubottu> Launchpad bug 1020759 in udisks2 (Ubuntu Quantal) "/run/media is an unnecessary divergence from the FHS" [Medium,Triaged] https://launchpad.net/bugs/1020759
<smoser> ahasenack, i'm aware of the issue, its covered under bug 974509
<ubottu> Launchpad bug 974509 in cloud-init (Ubuntu) "cloud-init selects wrong mirror with dns server redirection" [Low,Confirmed] https://launchpad.net/bugs/974509
<seb128> Daviey, apw: what Laney pointed, upstream disagree with using /media being important and say people who want a fixed mounting should use fstab to define it
<zul> didrocks: ping
<didrocks> hey zul
<zul> didrocks: saw the bug and just did what you asked for in python-setuptools-git
<didrocks> zul: excellent! upload on the way? :)
<zul> didrocks: just did
<xnox> apw: Daviey: seb128: Laney: I totally dislike the whole /run/media/$user/$bla because when i become root I need to search and hunt for usb-media in random directories instead of /media/$UUID
<didrocks> zul: ok, will wait for it to build, (looking at the diff meanwhile) then promoting to main
<zul> didrocks: cool thanks
<didrocks> zul: yw :)
<apw> seb128, a tricky one, the $user part seems reasonable for security, perhaps a compromise ln -s /run/media /media
<didrocks> zul: hum, is it me or you didn't do the most important change: depending on git?
<zul> didrocks: argh!
<didrocks> zul: I guess you just won some karma for a newer upload :p
<zul> didrocks: i did
<BenC> cjwatson: thanks, I'll stop porting it then :)
<BenC> I had actually fixed the second problem already
<didrocks> zul: hum, I don't see it in http://launchpadlibrarian.net/109463289/python-setuptools-git_0.4.2-0ubuntu1_0.4.2-0ubuntu2.diff.gz
<didrocks> zul: oh, the "I did" was for acknowleding the karma winning, gotcha :)
<zul> didrocks: gimme a sec ill add git to the depends
<ahasenack> smoser: thanks for the bug number
<zul> didrocks: uploaded with git depends
<smoser> ahasenack, the real solution, there is "use a real dns provider"
<didrocks> zul: excellent, thanks!
<smoser> but, we will likely be changing that functionality soon.
<ahasenack> smoser: chrome seems to do some pretty smart stuff
<ahasenack> smoser: it tries to resolve some randomly generated names
<ahasenack> smoser: if an ip comes back instead of a resolver error, it knows the isp is playing funky games
<smoser> ahasenack, that is an interesting solution.
<ahasenack> smoser: thinking out loud, we could try to resolve something like "shouldnotresolve.canonical.com" and get #is to never use that domain name :)
<apw> mvo, ok have figured out why it occurs, now to figure out what to do about it :)
<mvo> apw: so what is the 2min summary of what is happening?
<apw> apt is saying "convert the address into and address" but its doing that in the context of "taking into account which address families i have routable addressing for"
<apw> ie, its saying do i have a non-link local addy for ipv6, if not i can't use any ipv6 address even a link local one
<apw> i'd argue that that is a bug but, for now i need to work out when that would occur and not return the advertised ipv6 addressing
<BenC> cjwatson, infinity: Is there a plan to sync the tiff source that produces libtiff5? Several packages are dep-wait on it
<cjwatson> BenC: blocked on me resolving the MIR feedback on jbigkit
<cjwatson> which is indeed on my list if I can ever clear off emergencies :)
<BenC> What's more of an emergency than supporting the one-true-lossless-image-codec!?! :)
<Debolaz> Is the plan still to get rid of the alternate installer in 12.10?
 * BenC hopes not
<cjwatson> that is the current plan, conditional on some ubiquity features being implemented
<BenC> cjwatson: will there still be a net boot option of sorts?
<cjwatson> yes, netboot certainly isn't going away
<BenC> So is debian-installer still going to be around, it's just the alternate cd images?
<cjwatson> (as in, even if Canonical weirdly decides to stop supporting it, I'm entirely prepared to do so all by myself :-P )
<BenC> â¦that are going away
<cjwatson> right
<cjwatson> even that's flavour-specific, so I guess a flavour might choose to keep them
<BenC> Good goodâ¦count me in on the support-it-ourselves camp, if it ever comes to that
<zul> didrocks: hey did it get promoted yet?
<Debolaz> cjwatson: My main concern is somerthing that seems to be notoriously difficult to get right in installers: Full disk encryption. That's a mandatory feature for me.
<cjwatson> Debolaz: full-disk encryption is one of the ubiquity features that this is conditional on
<Debolaz> Good to know. :)
<Debolaz> I love Ubuntu, but I'm jumping ship if FDE goes away. :)
<didrocks> zul: I'm waiting for it to be published first
<zul> didrocks: ack
<cjwatson> and even if that weren't the case, as above, netboot installation will still exist either way and is basically the same UI as the alternate CD (you can even boot it from a CD, "mini.iso", if you prefer)
<SpamapS> RAOF: no I forgot to go in and approve them
<apw> is there an approved tool for looking up interface addreses, else can i rely on 'ip' being installed
<SpamapS> RAOF: just as I did the sru-release bit, I got pulled away for family stuff. :-P
<SpamapS> apw: for what purpose do you want to look up the address?
<SpamapS> apw: most of the time its useless to know your own address... you need to know the address by which others can reach you
<apw> SpamapS, i want to know if the local machine has a public ipv6 address
<SpamapS> best way is to grab the hostname and look for an ipv6 address
<Debolaz> Now if only support for apple keyboards could be fixed, ubuntu would be pretty darn perfect. :)
<apw> SpamapS, or more correctly an address which would be returned under AI_ADDRCONFIG
<apw> SpamapS, an
<apw> SpamapS, and an approved way of doing that ?
<mpt> Debolaz, I just finished sketches for full-disk encryption, so if it's notoriously difficult maybe you have comments on what I got wrong. ;-) <https://docs.google.com/a/canonical.com/document/d/1bZ4yQIVgGaUGSYu3qiUHnQt3ieBZoqunP_DcleHCr3I/edit#heading=h.n4153uoa2m9d>
<didrocks> cjwatson: change-override is not in the PATH anymore, I found it on cocoplum, but is that wanted, are there some new way for promoting?
<cjwatson> didrocks: https://lists.ubuntu.com/archives/ubuntu-archive/2012-June/045233.html
<cjwatson> the copy you found on cocoplum is probably in an old tree only used for poppy (the sftp uploader); do not attempt to use it
 * apw gets the feeling he is going to have to duplicate the code in apt for this in the end ... grrr
<didrocks> cjwatson: oh, seems I'm not on this ML
<SpamapS> apw: hostname?
<didrocks> cjwatson: excellent, using that now. That's why I prefered to ask you before doing anything :)
<Debolaz> mpt: Glancing over it, it looks like one feature is missing: Overwriting the encrypted partition with random data.
<cjwatson> didrocks: in general I'm steadily replacing programs on cocoplum with programs in ubuntu-archive-tools, so if you notice something disappearing from the former, look in the latter first
<Debolaz> mpt: Before encryption takes place.
<mpt> Debolaz, are you suggesting that should be optional?
<didrocks> cjwatson: I'll from now on :) (also, I'll subscribe to this ML)
<cjwatson> Debolaz,mpt: mm, the backend used to do that by default but it was outrageously slow so we turned it off by default
<cjwatson> (lots of testers complained)
<didrocks> cjwatson: thanks ;)
<Debolaz> mpt: It must either be mandatory, or a possibility.
<cjwatson> it must not be mandatory, but it may be optional
<Debolaz> cjwatson: Optional is fine by me, but it must be there.
<cjwatson> I agree it ought to be
<mpt> cjwatson, Debolaz: If you're both right, that leaves only one option, and it's not one I like...
<mpt> ... and that's a checkbox (or pair of radio buttons) offering two unpalatable choices
<mpt> "Do you want this to be slow, or do you want it to be insecure"
<didrocks> zul: done, please use arch:all for your next upload
<cjwatson> Actually, there might be a second option
<zul> didrocks: great thanks
<cjwatson> (Let me just do a bit of bug archaeology before following up on that remark)
<Debolaz> mpt: Seems like that has to be the way to go if making it mandatory isn't acceptable.
<cjwatson> So, we did once try making the erasure on by default but cancellable
<cjwatson> That didn't work well in d-i because of two bugs: firstly, there was no straightforward way to change the name of the Cancel button (bug 188085); secondly, the progress update was not very responsive (bug 218912)
<ubottu> Launchpad bug 188085 in debian-installer (Ubuntu) "debian-installers encrypted erase disc cancel button should read Skip" [Wishlist,Confirmed] https://launchpad.net/bugs/188085
<ubottu> Launchpad bug 218912 in partman-crypto (Ubuntu) "takes a long time to respond when cancelling erase process" [Medium,Triaged] https://launchpad.net/bugs/218912
<cjwatson> The first bug is pretty intractable in d-i, but would be easy to fix in ubiquity
<cjwatson> The second was never worth bothering to fix due to the first, but shouldn't be desperately difficult to do
<cjwatson> (Original bug about poor performance: bug 151244)
<ubottu> Launchpad bug 151244 in partman-crypto (Ubuntu Hardy) "encrypted lvm initialisation is very slow" [Medium,Fix released] https://launchpad.net/bugs/151244
<cjwatson> I think if we could fix 218912 and provide a better context-specific UI for cancellation, this would be a perfectly viable approach
<mpt> A "Skip" button would be quite difficult to understand in Ubiquity, with partitioning going on in the background of other steps
<mpt> (could be confused with skipping other steps)
<cjwatson> It could be "Skip erasure" perhaps (or better wording)
<cjwatson> I don't think it needs to be a single-word verb in any case
<mpt> So, let's say we go the option route instead of the Skip route
 * Debolaz is also happy BTRFS finally works with LUKS in 12.04 :)
<cjwatson> Anyway, just another option to consider
<mpt> Would it make sense to have it on by default (but turn-off-able) if you're overwriting a Linux partition, and off by default if you aren't?
<mpt> (e.g. if the disk is empty or has FreeDOS or something on it)
<Debolaz> mpt: No.
<mpt> No?
<Debolaz> mpt: a) Protecting previous information about the system, which is what you assume is the reason, is equally important for all previous systems, not just Linux and b) The actual reason for overwriting data is to protect the current system, not the previous installation. If you don't do a complete random erasure, the structure of the encrypted system is a lot more visible and can reveal a lot of information.
<mpt> Fair enough.
<cjwatson> Debolaz: If you happen to know about this, I'd appreciate a reference to cryptographic studies that show increased ease of attack when the contents weren't randomly erased first
<cjwatson> I can see the intuitive argument, but that's different from a proof :-)
<cjwatson> The closest I've been able to find quickly is http://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions 5.2, which is quite weak ("If you think this is a risk")
<Debolaz> cjwatson: Unfortunately, I don't have any research papers on hand about it. :)
<cjwatson> It's an interesting tradeoff; it matters until such time as you have written enough stuff to disk on the installed system to use all blocks, and after that point it's irrelevant
<cjwatson> So it's particularly relevant on very large disks where it might take you a long time to use all blocks, but that's exactly the case where it will result in a very great deal of waiting around during installation before you can actually use your system
<Debolaz> cjwatson: From a theoretical point of view: It gives the adversary access to ciphertext to use for analysis, while a with a randomized partition, he can't rely on any particular data (At least no significant chunks) being actually valid encrypted data.
<cjwatson> I understand the prose theoretical argument, but this sort of thing is terribly susceptible to folk myth
<cjwatson> And it's very easy to get the analysis wrong intuitively, or drastically misestimate the risks
<xnox> but we use lvm as well with LUKS, doesn't that scatter the blocks of data to make the chipertext access harder?
<xnox> or does lvm assign blocks continuously, while it can?
<cjwatson> I've never really checked, but from occasional observations I've had the impression that it generally tries to assign continuously within an LV
<xnox> my laptop is currently full-disk encrypted with plenty of space in the volume group, but I may be beyond the point of every block used at least once, due to using lvm volumes to back VMs and sbuild etc
<Debolaz> xnox: No, because all blocks that are not ciphertext will be all zeros. So you just collect all blocks that has nonzero data in it, and there is your ciphertext, ready for analysis. This *is* theoretical though, in the sense that it's not feasible for most to break AES-CBC even with a lot of known ciphertext (Not to be confused with known plaintext)
<cjwatson> That said I suppose I don't know whether its allocations within a PV are in order within the extents of that PV
<xnox> Debolaz: i probably should start a spec for next cycle for things that are "nice to haves"
<cjwatson> Debolaz: my concern is that if we (as an OSV) make it too inconvenient/slow/insert-bad-adjective to install a secure system, then the net effect will actually be a less secure world because people will choose not to bother
<cjwatson> the correct answer when faced with a convenience/security tradeoff is not necessarily to crank the security dial up to 11 :)
<Debolaz> cjwatson: That is a real concern and a tradeoff. So optional is fine for me.
<Debolaz> cjwatson: As long as the possibility is there.
<xnox> Debolaz: I would be willing to make this pre-seedable, but I am not sure if we want this in the UI
<xnox> maybe a --enable-random-disk-wipe button or in the advanced partitionaire.
<cjwatson> Debolaz: as a data point, the person who originally reported the "oh my god this is hopelessly slow and I don't want to bother with it" bug is a cryptographer ;-)
<xnox> i think it's too much for the automatic installer to use (aka a checkbox)
<xnox> =))))
<xnox> cjwatson: oooh the irony ;-)
<xnox> cjwatson: can we feel unused blocks with random data post-install with a cron job?
<xnox> s/feel/fill
<cjwatson> not sure
<cjwatson> I don't know how much of that relies on the device being unmounted for sanity
<cjwatson> as in do you introduce some weakness by going through the fs
<xnox> well yeah, cause we have four layers: fs, lvm, crypt, physical drive
<Debolaz> xnox: Making it pre-seedable only gives people a strong incentive to maintain a separate version with it enabled though (Like the alternate installer). Might as well satisfy everyone, just keep it in an "advanced" tab or something if you want to avoid normies to accidentially get a slow experience.
<xnox> Debolaz: $ ubiquity --enable-full-disk-erase
<cjwatson> things that make UI designers shudder: advanced tabs :-)
 * Debolaz would be fine with that.
<xnox> Debolaz: i used "pre-seedable" in the broad terms of not visible in the UI by default. at all.
<Debolaz> As long as it's possible, and documented somewhere. :)
<xnox> but "easy-enough to enable with those in the know"
<xnox> but "easy-enough to enable *by* those in the know"
<Debolaz> As an unrelated sidenote, I'm also happy that compiz has become a lot more stable in 12.04
<Debolaz> It haven't even crashed once yet. :) (Which wasn't exactly the experience in 11.10 and earlier)
<xnox> Debolaz: yeap. same here. I even switched back to 3D from 2D mode! =)
<Debolaz> 2D mode was a bit of a weird thing for me. It had a lot of small bugs and quirks I didn't like.
<Debolaz> I might give xubuntu a spin for a while though.
<Debolaz> Btw, does xubuntu have a dev channel?
<xnox> Debolaz: #xubuntu-dev i think
<xnox> Debolaz: nah, just #xubuntu
<xnox> Debolaz: there is! #xubuntu-devel
 * Debolaz goes to #xubuntu first to check if he's just missing something basic.
<frafu> Hi, The main coder of onboard is working on a prediction for onboard, the onscreen keyboard shipping with the LiveCD (no idea yet, whether it will be ready for quantal). The prediction will need dictionaries, but I suppose that it might not be possible to ship them with the LiveCD, because of the space they will occupy. Thus, we thought to have the onboard source package create two different debs: the usual onboard.deb and an onboard-p
<frafu> rediction-data.deb. The first would go as always on the LiveCD. Do we have to do anything special to make the package with the prediction data available to the Ubuntu users, or will the ubuntu developers take care of doing the necessary when they upgrade the package shipping with ubuntu to onboard with the word prediction?
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Quantal Quetzal A2 released! | 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: infinity
 * micahg just discovered pull-lp-source can use a mirror
<dobey> infinity: hi! :) i can bug you to accept stuff into precise-proposed right? :)
<infinity> dobey: I'm doing some of that today, yes.
<dobey> infinity: great. i think seb would be very happy if ubuntu-sso-client could move forward :)
<infinity> dobey: Yes, we talked about it last night. :P
<dobey> ah ok
<OdyX> pitti: pyppd got released as 1.0.0 and I'm preparing the upload to experimental. There is an upstream license change from GPL-3 to Expat and I'm relicensing my debian/* contributions. Are you okay to have yours relicensed too ?
<tumbleweed> micahg: that was an important feature for me
<alazare619> whats the official method of building an iso of a ubuntu spin
<alazare619> i know livecd-rootfs is for the chroot whats the actual iso method
<ScottK> Uses debian-cd
<alazare619> like i have the squashfs and everything built
<alazare619> whats the bootloader ubuntu uses for its live cds?
<alazare619> syslinux?
<jdstrand> infinity: hey, so I am getting this lintian error these days: 'E: ufw: postrm-does-not-call-updaterc.d-for-init.d-script etc/init.d/ufw'
<jdstrand> infinity: hmm, you are probably not the right person-- I read the changelog thinking you added this stuff, but you just merged
 * jdstrand continues to look
<infinity> jdstrand: Which changelog?  debhelper or lintian?
<jdstrand> infinity: debhelper
<infinity> jdstrand: Is it installing a real init script, not a symlink to upstart-job?
<jdstrand> I ship an upstart job (ufw.upstart), and do this: dh_installinit --no-start --no-restart-on-upgrade
<jdstrand> hmm, looks like precise had the same issue, and I didn't notice
<jdstrand> oh, no it didn't
<infinity> On precise, I have an upstart-job link.
<infinity> And since I don't have your quantal package, I'm not sure what it's doing...
<infinity> jdstrand: Throw me the deb?
<infinity> Or will rebuilding the precise source on quantal have the same effect?
 * infinity tries.
<jdstrand> ok, the quantal package is setting up a symlink
<jdstrand> ufw -> /lib/init/upstart-job
<infinity> Which is correct.
<jdstrand> yeah
<jdstrand> hmm
<infinity> And what precise did too.
<infinity> So, it could just be quantal's lintian being grumpy?
 * infinity is using precise's lintian still, and sees no issues.
<jdstrand> huh
<jdstrand> debhelper in quantal adds this to postinst: http://paste.ubuntu.com/1078515/
<infinity> Damn your testsuite.  I assumed this package would build in seconds.
<vadrao> Hi all, I am using Kubuntu 12.04 and trying to compile some systemc with Modelsim. I am getting several errors like "/usr/include/features.h:357:25: error: sys/cdefs.h: No such file or directory". That is, /usr/include/features.h references /usr/include/sys/cdefs.h which doesn't exist on my system, which is quite baffling since dpkg lists libc6-dev package as installed and I think that package should contain these header files...After running
<vadrao> find, I found that those files now reside in /usr/include/i386-linux-gnu/ instead of previously /usr/include/ .. What prompted this and how can I solve my compiling errors now ?  http://pastebin.com/EmSy5cLV
<jdstrand> infinity: DEB_BUILD_OPTIONS=nocheck is your friend :)
<infinity> jdstrand: Yeah, yeah.  I didn't expect a suite of doom. ;)
<jdstrand> yes-- it takes a while
<jdstrand> the fun thing is I will now run it twice (for py2 and py3 :)
<infinity> vadrao: I assume this is using a compiler we don't ship?
<infinity> vadrao: Cause ours all look in those paths by default.
<infinity> vadrao: If it's a non-Ubuntu compiler, you may just want to add -I/usr/include/i386-linux-gnu to your command line, or similar.
<vadrao> infinity: Yeah you are right, I am using Modelsim's builtin gcc compiler for this.
<jdstrand> right, so in quantal there is that extra bit of code, but it seems update-rc.d won't be triggered, cause I have /etc/init/ufw.conf
<jdstrand> I think this is a lintian issue
<infinity> vadrao: Yeah, we don't tend to support other people's compilers, but there's your answer, if you can't rebuild it to DTRT, just add the -I bits.
<infinity> jdstrand: That bit of code seems questionably odd anyway, but you can ask vorlon about it sometime, he's been the one slowly integrating upstart support into upstream debhelper.
<rtg> infinity, I'm having an interesting dpkg issue (I think). When cross compiling for armhf in an amd64 Quantal chroot, dpkg-buildpackage complains about 'Unmet build dependencies'. Non-cross-compiles are fine.
<rtg> echo "dpkg-buildpackage -b -aarmhf -us -uc 2>&1 |tee log.txt"|schroot -c quantal-amd64
<infinity> jdstrand: That said, if postinst has that code, and postrm doesn't have "undo" code, lintian's probably not wrong.
<infinity> jdstrand: (But it doesn't really affect us)
<jdstrand> right. it isn't wrong, but I don't really need to fix it by adding other code that does effectively nothing :)
<vadrao> infinity: OK thanks. How would the command look like in that case? an example. I am a novice :)
<infinity> rtg: Entertaining, given that the last dpkg was meant to make cross-compiling easier. :/
<rtg> which is why I suspected dpkg
<infinity> rtg: Your suspicion isn't wrong. :P
<rtg> infinity, known bug then ?
<infinity> rtg: Only because I skimmed #ubuntu-kernel backscroll when I woke up. :P
<rtg> infinity, I'll try to regress the version and see if the problem goes away.
<infinity> rtg: It will.
<infinity> rtg: The question is if this is a dpkg bug, or if dpkg adhering more strictly to multi-arch spec just means we need to add a bunch of multi-arch headers to the packages it's whining about for you.
<jdstrand> infinity: thanks or your help
<rtg> infinity, ok. in the meantime those chroots are worthless for cross compiling so I think I'll install an older version until this gets sorted.
<infinity> rtg: For now, though, downgrading to pre-yesterday versions of dpkg/dpkg-dev/libdpkg-perl and putting them on hold in your chroots (for i in $packages; do echo "$i hold" | dpkg --set-selections; done) will keep you happy while we sort it.
<rtg> infinity, just so you know, downgrading to dpkg 1.16.4.3ubuntu1 did the trick.
<infinity> rtg: Check.  Was pretty sure it would.
<Debolaz> Out of curiosity, does anyone in here use pidgin on vanilla ubuntu? And if so, do you have a really hard time noticing if anyone has written anything to you? The notification applet isn't designed to actively draw your attention, and pidgin doesn't seem to work well with the launcher wrt making noise when you have messages waiting.
<Debolaz> If I'm not missing something obvious here, I'd like to have a look at improving the situation.
<dobey> Debolaz: i think you can disable the plug-in in pidgin which integrates with the messaging menu. or you can just uninstall that bit. for me pidgin opens a new tab/conversation window when someone IMs me
<Debolaz> dobey: But unless I check the window, I won't notice the new tab is there. That's the problem.
<Debolaz> dobey: I currently have rewritten the messaging menu to blink to draw my attention, but I think the ideal way would be to have pidgin get a count on its icon when there are unread messages.
<dobey> i guess you'd need to fix the plug-in to set a count on the launcher if it's not doing so already then
<Debolaz> I'm also thinking about fixing the #1 annoyance I have with empathy and use that instead; That its "click and drag" feature on the contact list is a really, really, really bad idea under VirtualBox where the mouse will behave as if you click and drag from the side if you click into the window, causing contacts to either move, or worse, get deleted.
<Debolaz> Arguably it might be something VirtualBox should fix, but empathy is the only application that explodes because of it.
 * Debolaz should legally change his name to "Mr Edge Case"
<alazare619> i know livecd-rootfs is for the chroot whats the actual iso method is there a script ubuntu uses to pull the bootloader for hte iso and creates the iso?
<slangasek> infinity: hey, so what was the "everything" that broke with :native?
<slangasek> seb128: SRU queue> hard for me to do much about that today unfortunately, sitting in an airport :/
<slangasek> Daviey: /run/media not sure about agreement, but I have intent to ensure it's reverted ;P
<alazare619> infinity,  you here again?
<slangasek> infinity: debhelper upstart support in Debian is finalized; we aren't ready to sync it into Ubuntu though because we've been using a different approach on /etc/init.d compat stuff than what was settled in Debian
<slangasek> infinity: but you did the last merge of debhelper, no?
<infinity> slangasek: I did the last merge, yeah.
<infinity> slangasek: It doesn't seem to break anything (debhelper, that is), it just gives jdstrand scary lintian warnings.
<slangasek> so whatever's broken for jdstrand is your doing, right? ;)
<infinity> slangasek: As for dpkg, the breakage was that he declared the implicit build-essential build-dep as build-essential:native, while our build-essential is MA:foreign, a combination which the spec (and the implementation, which seems to match the spec) forbids.
 * jdstrand just override it for now, fwiw :)
<slangasek> infinity: ok - yeah, found the pastebin in scrollback, that's entirely expected and is all about reducing the delta with Debian
<infinity> slangasek: After sleeping on it, I think it's probably just that the implicit build-dep was wrong, so my quick workaround was perhaps the right fix.
<infinity> slangasek: But I mean to bring this up with you a bit more in person.
<slangasek> hmm, why is our b-e M-A: foreign?
<slangasek> right-o
<slangasek> we can discuss more effectively tomorrow :)
<infinity> slangasek: The latest dpkg build-dep changes also broke the kernel team's cross-building chroots, but I'm unsure if that's a dpkg bug/misfeature, a breakage in the spec, or just that a bunch of stuff they build-dep on needs MA headers.
<infinity> slangasek: I suspect perhaps the latter, combined with the implementation of the former being a somewhat draconian cutover.  For now, they've just rolled their chroots back, and we can look at the hows and whys, again, in person.
<infinity> slangasek: Well, s/tomorrow/Sunday/, unless you want to talk multiarch at midnight.  I get in fairly late.
<slangasek> that's the BEST TIME to talk multiarch
<slangasek> c'mon
<mu3en> maybe wrong channel, but is there some way to force grubpc install instead of grubefi install during server install?
<infinity> slangasek: if there's beer, I agree.
<infinity> slangasek: I'm still fuzzy, no matter how many times I read it, on the distinction between foreign and allowed, you may need to get me 3 gins deeps before you try to walk me slowly through it, especially as it affects build-deps, rather than normal deps.
<slangasek> infinity: allowed is "foreign if the revdep asks nicely"
<infinity> slangasek: And foreign is "allowed, if the native doesn't exist", from what I see in the spec.
<infinity> slangasek: The binary dep definitions make a bit more sense to me than how they're mapped for source deps.
<infinity> slangasek: But, yeah.  Booze.  Tomorrow.
<slangasek> eep, seems like a gratuitous overloading of 'allowed' :)
<slangasek> the build-dep side of things was done much more organically
<cjwatson> mu3en: boot the installer using BIOS rather than UEFI and you'll get grub-pc
<mu3en> thanks cjwatson, i'll check my server settings.
<alazare619> ok can someone point me to a guide from start to finish how ubuntu builds there iso's
<alazare619> i know livecd-rootfs is part of the mix for the chroot but what is after that etc
<micahg> !regression-alert
<ubottu> cjwatson, jdong, pitti, skaet, ScottK, kees, Daviey, pgraner: reporting regression in a stable release update; investigate severity, start an incident report, perhaps have the package blacklisted from the archive
<micahg> Bug #1021946
<ubottu> Launchpad bug 1021946 in lo-menubar (Ubuntu Precise) "lo-menubar 0.1.1 from proposed repositories makes plasma-desktop to crash" [Undecided,New] https://launchpad.net/bugs/1021946
<micahg> not worth an incident report most likely, but it is a regression nonetheless
<ScottK> micahg: Is it in proposed or updates?
<micahg> -updates now
<ScottK> Sigh.
<Sargun_Screen> Is there any way to test out newer packages on a specific installer
<ScottK> micahg: Can you upload something that reverts that change?
<micahg> ScottK: hrm, the other one looked pretty severe in itself
<micahg> 86 duplpicates
<ScottK> micahg: -updates is zero regressions though.
<ScottK> We don't get to screw a new bunch of people to unscrew others.
<ScottK> That or find Sweetshark.
 * micahg looks around for a desktopper
<ajmitch> ScottK: what about when it's a kernel update?
<ScottK> As a practical matter it's unavoidable sometimes .
<infinity> That was a pretty hefty SRU for a single bug...
<Sargun_Screen> SRU?
<infinity> Stable Release Update.
<infinity> micahg: There's a comment that removing it and reinstalling it magically makes it happy.  Which sounds a bit sketchy.
<micahg> infinity: I saw that too
<micahg> that's why I'd prefer someone who knows it to take a look before we start reverting
<infinity> Bleh.  Not sure why Steve released it.  The comments on the original bug didn't look promising either. :/
<micahg> right
<infinity> micahg: I'd be tempted to just push a revert through, but I dunno if, perhaps, the new breakage has to do with the new libreoffice and not lo-menubar.
<micahg> infinity: right, lots of moving parts :)
<infinity> Definitely could use someone who actually opens LibreOffice more than one a year.
<ScottK> Since there's no one around to deal with it, I guess I'll remove it so it at least doesn't pile up more problems over the weekend.
<infinity> ScottK: We're seeing about getting Ken involved.
<infinity> ScottK: But yeah, removing it won't hurt particularly (you're loving this new power, aren't you?)
<ScottK> Except I'm not.
<ScottK> KeyError: 'precise'
<infinity> It's the second time this week I've noticed you mentioning doing removals. :)
<infinity> precise-proposed?
<ScottK> Let me try that.
<ScottK> Nope
<infinity> Err, updates.
<micahg> ken will take a look later this evening
<infinity> ScottK: remove-package -n -m 'Busticated' -s precise-updates lo-menubar
<infinity> ScottK: Seems to DTRT here.
<infinity> ScottK: Might want a more verbose comment. :P
<micahg> umm, ken didn't seem to be for removal either due to the crazy crasher
<infinity> So, his opinion is that the current state is less broken than the previous?
<infinity> Or, at least, similarly bad?
<ScottK> Cockpit error.
<micahg> yes, at least on the surface
<infinity> Alright.
<infinity> ScottK: Stay the execution? :P
<ScottK> Slightly too late.
<infinity> Or not.
<ScottK> Actually I hadn't confirmed yet
<ScottK> Just in tiem.
<ScottK> time even
<infinity> Mmkay.
<infinity> I'm going to go back to my THRILLING laundry and packing.
<ScottK> micahg: I'm leaving it with you then.
<infinity> And trust that Ken will make this slightly less poop.
<micahg> ScottK: I go offline in a couple of hours, better off with you or infinity
<micahg> or jasoncwarner_
<infinity> micahg: I leave the country tonight.
<ScottK> That's probably after both of us.
<ScottK> I'm leaving for western Virginia, so it's probably even worse.
<infinity> Hah.
<micahg> awesome, the three who are usually around will be no where to be found :)
<infinity> I'll be around for a bit, though, I'll try to liaise with Ken before I go, and make sure there's some trail of responsibility.
<infinity> I don't think this is sever enough to warrant anything heavyweight and reporty, but it would be nice to make sure it doesn't get forgotten.
<ScottK> micahg: I think an incident report is, in fact needed.
<infinity> Or, we could report just so people don't forget. :P
<infinity> s/sever/severe/
<ScottK> New rule "LO SRUs accepted only on Monday"
<infinity> It was Tuesday...
<infinity> Close enough.
<micahg> jasoncwarner_: will you be around for a while?  could you take charge of this?
<jasoncwarner_> micahg: it is my saturday. I'll be around for a bit (maybe an hour). Though I'm completely lacking context here. You said it was a regression in -updates. is this something we can just revert?
<infinity> jasoncwarner_: The claim is that reverting it will just be trading one bad bug for another.
<micahg> jasoncwarner_: well, the upload fixed Bug #754562 supposedly
<ubottu> Launchpad bug 754562 in LibreOffice Menubar Extension "soffice.bin crashed with SIGSEGV in g_hash_table_lookup() (Libreoffice with lo-menubar crash from page preview)" [Undecided,In progress] https://launchpad.net/bugs/754562
<infinity> jasoncwarner_: Which may lower the overall urgency of the thing (going from broken to broken), but still worth seeing through.
<ScottK> Although I claim me reverting it is probably going to motivate the people saying that to maybe do something useful.
<ScottK> jasoncwarner_: I can remove it if you want, I"ll be around off and on for a bit.
<Laney> I think you shouldn't get to introduce regressions in updates without a lot of thought.
<infinity> ScottK: Possibly, but I suspect we have other ways to motivate. :P
<Laney> I would remove it from updates. It can always be put back.
<ScottK> Laney: ++
<micahg> maybe copy back to -proposed?
<infinity> That, I can do.
<ScottK> infinity: Is anyone actually commiting to do anything before Monday?
<Laney> yes, put it back there. Get it some more verification.
<jasoncwarner_> +1 what laney said and I like micahg suggestion to put it back in -proposed to get more eyes on it...
<infinity> Let me bounce it back to proposed, I'll let others sort out what to do with the one in updates.
<ScottK> infinity: I know what to do with that one.  Let me know when you're done.
<micahg> hrm, it might just be lo 3.5.4 that's broke
<Laney> Put the gun down.
<infinity> ScottK: Copied, will take a publisher run.
<infinity> micahg: This wouldn't be a shock.
<infinity> micahg: Are you testing new lo-menubar against the lo from release and it's okay?
<micahg> well, if it is lo and not lo-menubar, it's only regression-proposed
<ScottK> So it can stay in -proposed until it's sorted.
<micahg> but from what it sounds like, the update didn't fix the original bug as intended (just made the crashes stop, but broke the addon)
<infinity> Indeed.
<infinity> It's a broken SRU, no matter how you slice it, from the bug comments.
<infinity> Even if the new and fancy crash is lo's fault.
<Laney> Yet it managed to get to updates. Sounds incident-reporty.
<infinity> Laney: Sounds like you just volunteered.
<ScottK> \o/
<Laney> I conveniently have to leave now :-)
<Laney> Will look into it tomorrow.
<micahg> yeah, lo-menubar not working is better than hanging the DE
<micahg> so, removal from updates seems warranted'
<infinity> Right, well, I'll bounce it from updates once I've seen it published back to -proposed, and update the SRU bug.
<infinity> micahg: Want to take care of the new bug?
<micahg> infinity: take care ok?
<micahg> *of
<infinity> micahg: Mention what we plan to do, mark it with whatever shiny tags are appropriate, what have you.
<infinity> micahg: Or just take it out back and shoot it.  However you prefer to interpret "take care of".
<micahg> sure, let me go mark everything up
<micahg> and to top it off, there's no SRU master bug :(
<infinity> Should there be?
<infinity> I honestly find the concept rather pointless, except in the case of massive SRUs (like the kernel).
<infinity> An SRU to fix one or two bugs hardly needs another one just to track that.
<micahg> yes, because you can mark the master bug as failed if there are new issues and the other bugs are actually fixed
<ScottK> We use a master SRU bug for KDE updates.
<infinity> micahg: In this case, the "master" bug was the "one bug it was meant to fix".  Even if it did fix that bug, it hardly fixed it well if it broke in another way.
<micahg> infinity: I mean it when you SRU a new version, not just a single fix
<infinity> What does annoy me, though, is the lack of bug dependencies.
<micahg> infinity: that's in progress apparently
<infinity> So, you could make the old SRU bug now depend on the new bug.
<micahg> still, if you're pushing a new version, you need a bug to track issues related to that new version and unrelated to bugs fixed in the new version
<infinity> micahg: Perhaps, yes.  Depending on how one defines "new version".  In this case, I'd be inclined to agree, since it was a big set of changes.
<micahg> infinity: I'd include it for anything that does have a bug -> fix link in the changelog
<micahg> s/does/doesn;t/
<infinity> (Sometimes, a new version really just fixes the 3 bugs that you already targetted in the changelog, and a master bug seems silly).
<micahg> infinity: right, in which case, one of the fixes broke somethin
 * infinity nods.
<infinity> Well, this fix might have broken something too. ;)
<infinity> I routinely introduce segfaults by fixing segfaults.
<infinity> Chase the pointer!
<infinity> Whee!
<infinity> (I don't routinely release such fixes, mind you, I tend to keep my stupidity and shame confined to my laptop most of the time)
<micahg> right, well, it's true, but not readily apparent
<micahg> bugs updated FWIW
<micahg> anything else needed from me?
<infinity> Nope.  I've just bounced it out of -updates.
<infinity> Back to my wonderful world of laundry, packing, kernel SRUs, and.. Whatever else I can squeeze in before my flight.
 * micahg steps away
#ubuntu-devel 2012-07-07
<infinity> dobey: Can you reupload that ubuntuone-client SRU with a proper changelog that includes past history in security/proposed?
<R3pLiCa_> hello !!!!!!!!
<R3pLiCa_> which is the good book for kernel deve in linux????
<skunk> does anyone here think Ubuntu Software Center is slow and unstable?
<alazare619> can someone link me to the docs as to how ubuntu iso are built after the file system is squashed?
<stack_> by mistake changed the permissions on / as chmod -R 777 *. Now I can't ssh into the server. Is it possible to repair it without formatting it ? I do have physical access to the server
<alazare619> login as root?
<alazare619> username root  should still let you in ive done similar on /usr
<stack_> alazare619: but how can I undo these effects (I am not aware what's default)
<alazare619> i dont think you can  :S
<alazare619> you can 755 most of /usr etc but you best bet is to google most of the packages
<stack_> alazare619: I did it as a user with root priviliges but not exactly as root. So is it still possible to recover ?
<alazare619> can someone tell me what process x/k/ubuntu uses to build the isos after the chroot is squash.fs'd
#ubuntu-devel 2012-07-08
<alazare619> im trying to make a bootable ubuntu iso but whenever i make the iso its only 19mb like its missing the chroot
<psusi> well, the nautilus bug where it reports bogus size in the properties of the root has annoyed me for the last time... fixed it.
<justaguest> what level of C expertise is need to contribute to writing the ubuntu source code?
<Roj> HI  i need this trutrial creating your own browser using webkit
<larsduesing> good morning or so :-)
<larsduesing> I think, there is a bug in launchpad: If you look at the SRU-Queue and the Revision before the SRU is a security-update, the diff in the SRU-Queue is for both the security-update as well as the SRU...
<larsduesing> https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<larsduesing> (aiccu)
<larsduesing> http://launchpadlibrarian.net/109210156/aiccu_20070115-14.1ubuntu3_20070115-14.1ubuntu3.2.diff.gz
<larsduesing> it does a diff *ubuntu3 against *ubuntu3.2 (whilst there IS a *ubuntu3.1-Version out there)
<cjwatson> Yeah, diff ancestry isn't always quite right
<larsduesing> hi cjwatson :)
<larsduesing> I tried to look what component I should file a bug against, but nothing really found..
<cjwatson> larsduesing: the "launchpad" product ("Launchpad itself")
<larsduesing> it is launchpad itself? Ok
<larsduesing> :)
<cjwatson> it's in lib/lp/soyuz/model/queue.py:PackageUploadSource.getSourceAncestryForDiffs if you want to try fixing it
<larsduesing> lets have a look (and get completely confused *G*)
<cjwatson> See also my XXX comment in lib/lp/soyuz/scripts/packagecopier.py:check_copy_permissions complaining about the many different implementations of ancestry calculation
<cjwatson> It's possible that a correct fix would rip all of that duplication out and consolidate it, although that will require some moderately hard thinking about the correct semantics
<larsduesing> *reading through python code*
<larsduesing> sometimes I hate bzr... tons of source are being downloaded...
<larsduesing> cjwatson: is there any decent way to debug this?
<larsduesing> cjwatson: https://bugs.launchpad.net/launchpad/+bug/1022260
<ubottu> Launchpad bug 1022260 in Launchpad itself "lib/lp/soyuz/model/queue.py:PackageUploadSource.getSourceAncestryForDiffs doesn't look for anything in -updates or -security" [Undecided,New]
<cjwatson> larsduesing: hm?  not sure what requires debugging, the logic is clear enough and just diverges from what you expect
<cjwatson> larsduesing: oh, you should write unit tests for any changes - there's stuff on dev.launchpad.net about that
<cjwatson> larsduesing: I repeat my previous observation that this needs to be refactored though - and I don't think it's correct that you've made the ancestry of things in the release pocket include -updates
<larsduesing> hmm
<larsduesing> ok, thinking over it again
<cjwatson> I think this needs clear thought before hacking on it, and looking through the other functions that do similar things and trying to consolidate them is probably a good way to start
<cjwatson> larsduesing: BTW there's #launchpad-dev which is probably more knowledgeable :)
<cjwatson> (though mostly in working hours)
<Daviey> larsduesing: dupe of bug 680911 ?
<ubottu> Launchpad bug 680911 in Launchpad itself "Diff generation in the proposed pocket should consider the updates pocket even when there are previous proposed publications." [Low,Triaged] https://launchpad.net/bugs/680911
<larsduesing> oh
<larsduesing> Daviey: cjwatson told me the updates pocket should NOT considered
<highvoltage> 5n
<Daviey> larsduesing: All i know, is that i almost had a heart attack when i uploaded a core package (dpkg) as an SRU for a one line change, based on the current -updates package.. and almost had a heart attack when i looked at the LP diff as it was huge.
<cjwatson> larsduesing: err ... I was talking about relative to the release pocket, not relative to -proposed.  (This is why this requires careful thought and probably drawing up a big table or something. :-) )
#ubuntu-devel 2013-07-01
<adie> hi
 * adie huggles TingPing 
<adie> hi #ubuntu dev people, I have a problem in unity launcher API stuff, and I was wondering if you can help me out :O
<adie> I am trying to set a msg count number in hexchat with python launcher.set_property ('count', count), and it works the first time, but if I reload the script is breaks like this: http://pastebin.com/raw.php?i=eudXgAcG
<adie> I was wondering if there was something I can do to clear out whatever is preventing the script from working upon second launch
<sarnold> adie: you didn't miss any responses while gone..
<adie> okay, ty :|
<adie> :<
<sarnold> adie: still nothing while you were gone. perhaps try in twelve-sixteen hours, more people will be around
<adie> :D maybe
<adie> sorry for quit/join
<adie> have to restart the client to make the script work :D
<sarnold> ah :) hehe
<TingPing> adie, if only it were possible to have two clients open at the same time.. hmm
<adie> TingPing, I wouldn't be surprised if this script would interfere with two client instances
<adie> targeting the same external resource
<TingPing> adie, well you would be wrong
<adie> Isn't that the rule?
<adie> "Adie is always wrong"
<TingPing> the error has something to do with loading the glib library from the the same python library twice i guess
<micahg> adie: #ubuntu-unity might be of some help
<adie> okay
<pitti> Snow-Man: yes, unfortunately there is no way to ship a logrotate file which works on both < 3.8 and >= 3.8, so during package build we have to create a file for a particular version
<pitti> Snow-Man: FYI, unstable will switch to 9.3 as soon as it gets released (beta2 just came out)
<pitti> Good morning
<adie> mornin
<mwhudson> hi
<mwhudson> apache2-mpm-worker-dbgsym seems to be uninstallable
<dholbach> good morning
<mwhudson> https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1196440
<ubottu> Launchpad bug 1196440 in apache2 (Ubuntu) "apache2-mpm-worker-dbgsym is uninstallable" [Undecided,New]
<maxoiaojun> cjwatson: ping
<cjwatson> maxoiaojun: just leave your message directly, please
<maxoiaojun> cjwatson: I believe pad.lv/1035136 is not fixed even on saucy, please try "/usr/lib/lsb/install_initd" if you have saucy box
<xnox> bug #1035136
<ubottu> bug 1035136 in lsb (Ubuntu Raring) "install_initd crashed with SyntaxError in __main__: invalid syntax" [Medium,Triaged] https://launchpad.net/bugs/1035136
<cjwatson> maxoiaojun: I've followed up in the bug.
<maxoiaojun> thanks, i'm firing a saucy vm
<cjwatson> maxoiaojun: A chroot should be enough.
<jibel> hallyn, stgraber with kernel 3.10 I get the following error when I create an LXC container
<jibel>       lxc-start 1372673552.852 ERROR    lxc_cgroup - Invalid argument - write /sys/fs/cgroup/devices/lxc/saucy-i386-20130701-1012/devices.deny : Invalid argument
<jibel> hallyn, stgraber does this kernel requires a config change of the containers?
<jibel> I don't see this error with 3.9.0-7
<maxoiaojun> a bit confused now
<maxoiaojun> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lsb/saucy/files and what installed on saucy box is different?
<xnox> maxoiaojun: the new lsb is not in release pocket yet, above imports from release pocket with a propagation delay.
<hallyn> jibel: no, nothing like that should have changed.
<maxoiaojun> xnox: but the bzr branch is behind what is actually installed
<jibel> hallyn, okay, I'll report a bug
<cjwatson> I ignored the branch
<cjwatson> Also, in any case, the files you're probably talking about are modified in debian/rules
<cjwatson> (Looks like the branch is up to date otherwise)
<cjwatson> maxoiaojun: https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/lsb/saucy/view/head:/debian/rules
<cjwatson> $(twotothree) -n -w debian/lsb-core/usr/lib/lsb/*
<maxoiaojun> i see
<cjwatson> Not the way I prefer to do things myself, but whatever
<maxoiaojun> how about raring and quantal then, I propose that we just change rules so that /usr/lib/usb will continue to use python 2
<cjwatson> I'd rather we backported the fixes
<maxoiaojun> because it's all rules magic
<maxoiaojun> i guess just remove the python => python3 magic for /usr/lib/lsb/ is enough
<maxoiaojun> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/raring/lsb/raring-proposed/view/head:/debian/rules#L104
<cjwatson> Well, whatever.  I'm not going to do the work here.  But I think it'd be wiser to bring quantal/raring more into line with saucy rather than going backwards, as a general principle of SRUing
<maxoiaojun> https://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/lsb/quantal-proposed/view/head:/debian/rules#L104
<cjwatson> It's already running 2to3 over things there so it's not that big a change to expand that
<cjwatson> And it would be a more direct backport
<cjwatson> See bug 798192
<ubottu> bug 798192 in lsb (Ubuntu) "install_initd fails" [Undecided,Fix released] https://launchpad.net/bugs/798192
<cjwatson> In fact this bug is a dup of that one, I think
<maxoiaojun> indeed, but 2to3 is not enough for the scripts in quantal and raring I guess
<maxoiaojun> as someone mentioned "sudo sed -i "s/python3/python/" /usr/lib/lsb/install_initd"  as a workaround
<cjwatson> maxoiaojun: The bug fixed in 4.1+Debian9ubuntu1 was that 2to3 wasn't run over the proper files.  Backport that
<maxoiaojun> i see using tested python 2 code better than using untested 2to3 generated python 3 code
<cjwatson> I'm concerned about pulling python (2) back into environments where it wasn't needed before; and in general I prefer straight backports of what's in the development release for SRUs, where at all possible
<ogra_> also testing happens in saucy anyway, if there are bugs, fices can be backported easily
<ogra_> *fixes
<jibel> hallyn, I filed bug 1196518
<cjwatson> But, as I say, I'm not the one who's going to be doing the work here, so you don't have to persuade me
<ubottu> bug 1196518 in lxc (Ubuntu) "lxc-start failed with lxc_cgroup - Invalid argument - write /sys/fs/cgroup/devices/lxc/<NAME>/devices.deny : Invalid argument with kernel 3.10" [Undecided,New] https://launchpad.net/bugs/1196518
<jibel> apw, ^
<xnox> diverging further increases maintenance cost as the next fix will have to be written twice....
<ogra_> xnox, ++
<maxoiaojun> but the python 2 code is well tested by debian i guess
<apw> jibel, oh goodie
<ogra_> maxiaojun, that doesnt make maintaining two patchesets less work
<ogra_> -e
<maxiaojun> but the lsb package is already in different versions anyway
<maxiaojun> you can check the rules file, saucy one is very different from quantal/raring one
<maxiaojun> you know, saucy contains lsb4.1-blah while older releases all lsb4.0
<hallyn> jibel: thanks
<ScottK> barry: I see that socket.error is now deprecated: http://www.python.org/dev/peps/pep-3151/ - Is it deprecated, but won't be dropped for a long time because it's widely used or deprecated and I better make sure I don't use it because it's going away soon?
<barry> ScottK: the former, most likely.  i wouldn't expect it to go away before 3.5 at the earliest, if ever
<ScottK> barry: Thanks.
<stgraber> jibel: LXC appears to work fine here, can you pastebin your container config?
<stgraber> jibel: nevermind, just saw the bug report now
<barry> xnox: ping
<xnox> barry: hola =)
<barry> xnox: hi!  there's a comment in emacs24 24.3+1-1ubuntu1: - debian/emacsVER.desktop: Also set StartupWMClass for bamf and gnome-shell.  have you by any chance seen the icon break for tab completion after this?
<barry>  
<maxiaojun> https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1035136 branches linked
<ubottu> Launchpad bug 1035136 in lsb (Ubuntu Raring) "install_initd crashed with SyntaxError in __main__: invalid syntax" [Medium,Triaged]
<xnox> barry: define break? after this patch the icon has become a beautiful svg emacs bubble with a fountain pen; before this patch it was an ugly pixalated xmp icon instead.
<xnox> barry: what DE do you use?
<barry> xnox: unity
<xnox> same
<barry> xnox: i get a nice big question mark on a beautiful gray background
<jibel> stgraber, sorry was otp. The setup is a bit special because it uses 2 loop-mounted devices + an overlay
<xnox> barry: i can quickly test in a clean / new environment.
<barry> xnox: great, thanks.  i see it on two saucy desktops now
<jibel> stgraber, but downgrading to 3.9.0-7 clearly fixed the problem and we could dozens of test without any issue.
<xnox> barry: all works correctly in a saucy VM. Do you have custom .desktop files? are you launching emac24 or emacs which happens to be update-alternatives launching emacs24? are you starting emacs via upstart or some-such?
<ogra_> hallyn, i need to link a dir across from the containers /dev to the hosts /dev (there are sockets the binary android blobs create) ... i used to use a link from /dev/socket into /proc/$lxc_pid/root/dev/socket but seems a normal user cant access that, any idea how to do that more elegant and with permission for normal users ?
<barry> xnox: launching emacs via gnome do.  i wonder if that would matter
<barry> xnox: nope
<xnox> barry: emacs (symlink) or emacs24 ? can you type "emacs24" in gnome-do?
<barry> xnox: so i see the right icon in both the hud when i use the launcher to start it, and in gnome do when i use that to start it
<barry> xnox: but either of those, and starting from the shell, all give me broken icons
<xnox> weird. no idea.
<barry> dang
<barry> not that it's a huge deal of course
<jibel> xnox, jodh there is a regression in upstart 1.8-0ubuntu1.1 in Raring and bug exists in Saucy (bug 1124384 and bug 1195955)
<ubottu> bug 1124384 in cloud-init (Ubuntu Saucy) "Configuration reload clears event that others jobs may be waiting on" [High,Confirmed] https://launchpad.net/bugs/1124384
<ubottu> bug 1195955 in upstart (Ubuntu) "Setting up upstart (1.8-0ubuntu1.1) ... dpkg: error: unknown option --compare-version" [Undecided,Confirmed] https://launchpad.net/bugs/1195955
<hallyn> ogra_: well you should be able to get around the permission issue by doing a bind mount instead of a link
<hallyn> ogra_: probably the more robust way would be to use mounts propagation to cause the contaienr's / or /dev to be mounted someplace where the host can see it
<hallyn> ogra_: is the container's /dev a static dir, or a tmpfs?
<jodh> jibel: yeah, looks like a typo from the last uploader
<ogra_> hallyn, android uses a tmpfs for /dev
<ogra_> and we hold our boot until thats propagated
<hallyn> ogra_: what do you mean by propagated?
<hallyn> populated, or are you actually propagating the mount already?
<stgraber> hallyn: IIRC you can't bind-mount /proc/<pid>/root/<something> (or at least it wouldn't let me do that the last time I tried)
<xnox> jibel: that's mine.
<ogra_> hallyn, like ubuntu has udev, android uses ueventd to propagate the tmpfs /dev
<ogra_> stgraber, right, i had the samme issue, thus the link
<ogra_> which worked fine until rsalveti came around :P
<ogra_> (trying to access it as normal user)
<stgraber> ogra_: btw, you mean "populate" not "propagate" :)
<ogra_> errr, yeah
<hallyn> ogra_: ok, i think you should make the container's rootfs --make-rshared
<ogra_> what does that chare and how ?
<ogra_> *share
<hallyn> set lxc.rootfs.mount to /container/rootfs in the container config,
<stgraber> hallyn: won't help much as the final setup (once we're fully flipped and loop-mounted) uses a tmpfs rootfs mounted from the container ns
<ogra_> we want the container to stay haf way safe ...
<hallyn> and on the host do mount --bind /container/rootfs /container/rootfs; mount --make-rshared /container/rootfs
<stgraber> hallyn: so the rootfs isn't visible outside of the container mountns
<hallyn> stgraber: I think I might need a pic :)
<stgraber> hallyn: basically /var/lib/lxc/android/rootfs is empty (or in ogra's case doesn't even exist), at boot time we have a pre-start which mounts a tmpfs on top, then unpack a cpio initrd, then does a bunch of stuff and finally boots that as rootfs
<hallyn> stgraber: that shouldn't matter
<hallyn> stgraber: so long as you make lxc.rootfs.mount = /container/rootfs, then the actualy rootfs that you pivot-root into will be /container/rootfs
<stgraber> hallyn: but as all of this happens in pre-start, we're already in the container mountns so the rootfs isn't visible from the host, which means that if we were to use rshared, we still wouldn't be able to see it
<hallyn> and if you make that rshared, then the mounts from the child container should be reflected on the host
<hallyn> stgraber: the rootfs you're building isn't visibile in the host,
<hallyn> but when you mount that onto /container/rootfs to pivot-root to it, you should see that on the host
 * ogra_ thinks he slowly gets it
<hallyn> i coudl be wrong, as this is being held together by duct tape, but that's what I"d expect :)
<stgraber> ah, let me try that
<hallyn> (duct tape == bind mounts :)
<ogra_> :)
<hallyn> cool.  meanwhile i've got someone telling me they can't provide apport info bc the bug is happening on fedora.
<ogra_> hallyn, so adding "lxc.rootfs.mount = /var/lib/lxc/android/rootfs" .... makes the container sigsev
<ogra_> nothing further in the logs
<ogra_> (or did you mmean literally /container/rootfs ?)
<hallyn> ogra_: yeah :)
<ogra_> doesnt work either
<hallyn> does that directory exist?
<ogra_> do i need to create /container soemwhere ?
<ogra_> heh, snap :)
<hallyn> mind you i wouldn't expect /var/lib/lxc/android/rootfs to segv...  it should just bind mount that onto itself then pivot to it.
<hallyn> ogra_: and after you create /container/rootfs, remember to make it rshared
<hallyn> so mkdir -p /container/rootfs; mount --bind /container/rootfs /container/rootfs; mount --make-rshared /container/rootfs
<apachelogger> heya, any kernel guys around?
<ogra_> hallyn, well, the container doesnt start
<hallyn> i can't reproduce quite your setup, but let me try a simpler case here
<hallyn> ogra_: which release is this on, and which lxc package?
<ogra_> apt-get source lxc-android-config ...
 * stgraber fights with make-rshared being a bit stupid
<ogra_> hallyn, saucy latest lxc package indeed
<hallyn> k
<ogra_> stgraber, does your container start at all ?
<stgraber> ogra_: yes, mine is fine because I'm using my loop-mounted images which have a saner lxc setup
<ogra_> why didnt you pull  that into the non loop one :P
 * ogra_ wants sanity too !
<stgraber> no point we'll get rid of those eventually and I have no way of testing them :)
<ogra_> phablet-flash --flipped
<ogra_> :P
<ogra_> easy to test
<hallyn> jibel: so just to be clear, you created that container completely by hand, writing your own config?  If not, can you add steps including lxc-create command to the bug?
<ogra_> stgraber, point is that we need a fix for flipped atm, it doesnt help if it works for you in the loop case
<ogra_> (we want to swtich to flipped by default today, that one is a blocker)
<stgraber> ogra_: well, my container works with a lxc.rootfs set, rshared still doesn't so getting you past the lxc.rootfs won't help much
<bjf> bug 1196363
<ubottu> bug 1196363 in network-manager (Ubuntu) "network-manager is breaking my wireless during "Stage 5 of 5 (IPv6 Configure Timeout)"" [Undecided,New] https://launchpad.net/bugs/1196363
<bjf> ^ this is saucy, 100% reproduceable
<ogra_> stgraber, hmm, k
 * ogra_ would at least like to know what keeps his container from starting at all :(
<hallyn> ogra_: can you do lxc-start -l info -o outout and pastebinit outout?
<hallyn> i'm still waiting for my testbed to install saucy...
<ogra_> root@ubuntu-phablet:/# cat outout
<ogra_>       lxc-start  947224102.538 INFO     lxc_start_ui - using rcfile /var/lib/lxc/android/config
<hallyn> uh
<hallyn> dat not good
<hallyn> ogra_: in that case can you strace it?  (strace -f -ooutout2 lxc-star ...)
<ogra_> we start from an upstart job btw ...
<ogra_> (on which other boot bits depend)
<ogra_> bah, sigh, cant install strace without NM running
<stgraber> ogra_: wget http://ports.ubuntu.com/ubuntu-ports/pool/main/s/strace/strace_4.5.20-2.3ubuntu2_armhf.deb + adb push strace_4.5.20-2.3ubuntu2_armhf.deb /tmp/ + dpkg -i /tmp/strace_4.5.20-2.3ubuntu2_armhf.deb
<ogra_> stgraber, :P i know, i'm lazy
 * ogra_ just rebooted with reverted container config
<stgraber> hallyn: ok, finally got /var/lib/lxc/android/rootfs mounted rshared here, pivot_root fails
<ogra_> hallyn, http://paste.ubuntu.com/5816923/
<ogra_> not really informative, it seems to die when reading the fist line of the config
<stgraber> slangasek: hey, with all the /run talks a while back, do you ever remember someone mentioning /etc/mtab? just noticed that one being an obvious candidate for /run and pretty annoying when /etc is read-only
<ogra_> stgraber, didnt we always follow the "link to /proc/mounts" directive for readonly rootfs ?
<hallyn> stgraber: no, /var/lib/lxc/android/rotofs is not to be rshared,
<hallyn> stgraber: /container/rootfs is
<hallyn> stgraber: in other words, /var/l/ib/lxc/android/rootfs is the *source* of the mount, but you want the target to be rshared - the dir you end up pivot_rooting into
<stgraber> ogra_: yeah and that's what I'm doing here, though /run may make more sense (so that things like mount -n work)
<ogra_> yeah. /proc/moounts definiely isnt 100% equal
<stgraber> hallyn: hmm, right, that'll be even trickier because of mount's silly restriction of having the target be in /etc/mtab...
<jibel> hallyn, I don't use the ubuntu template but scripts from https://code.launchpad.net/otto if that's what you mean by "by hand". The default config is a modified version of an install on Saucy months ago.
<jibel> hallyn, the major difference being the hooks, and lxc.cgroup.devices.allow on snd, dri, input and tty
<jibel> and the memory limits
<hallyn> holy schnickities
<jibel> hallyn, I also noticed +lxc.hook.mount = /usr/share/lxc/hooks/mountcgroups which is not there with latest template
<jibel> I'll add steps to reproduce
<hallyn> jibel: thanks
<hallyn> stgraber: holy schnickities, bug in saucy's lxc with lxc.rootfs.mount set.  oh!  i think i knew about that one
<stgraber> hallyn: so I added:
<stgraber> mount --bind $LXC_ROOTFS_PATH $LXC_ROOTFS_PATH > /tmp/debug 2>&1
<stgraber> mount --make-rshared $LXC_ROOTFS_PATH > /tmp/debug 2>&1
<stgraber> hallyn: to the pre-start, was that what you were saying?
<hallyn> stgraber: yeah
<stgraber> hallyn: because if it's, then pivot_root still fails
<hallyn> d'oh
<hallyn> right, kernel won't allow that will it
<stgraber> yeah, same thing we had with UFA I think, kernel won't let us do it
<hallyn> ok, new plan :)
<hallyn> mkdir /junk;  mount --bind /junk /junk;  mount --make-rshared /junk
<hallyn> start the container as per usual
<hallyn> oh no, I guess bind-mount /junk into the container with lxc.mount.entry
<hallyn> then, mkdir /junk/console; lxc-attach $container mount /dev/console /junk/console
<stgraber> hallyn: we're on old kernels, can't rely on lxc-attach :)
<stgraber> hallyn: but I have an idea for our specific case
<stgraber> ogra_: how about we create /dev/sockets on the host (ubuntu), then bind-mount that to /sockets in the container and then have init.rc mount --move it to /dev/sockets right after /dev is mounted in android?
<hallyn> stgraber: then just ssh $container mount /dev/console /junk/cnosole :)
<stgraber> hallyn: no ssh or getty either :)
<ogra_> stgraber, not sure how the blobs will cope with that ...
<ogra_> we try to not change anything on the android side that could affect the binary blob functionallity (we already have way to many intrusive changes in the android setup)
<hallyn> stgraber: club it over the head and shout?
 * hallyn will wait to hear what stgraber is trying and whether it worked :)
<stgraber> ogra_: they won't have to, it's just an extra line in the init.rc to make /dev/sockets a mount instead of a standard dir
<stgraber> ogra_: unless the blobs start checksuming /proc/mounts or something, they won't notice and if they're looking at /proc/mounts, they'd already fail today :)
<ogra_> stgraber, ok, lets try it
<stgraber> ogra_: ok. I'm stuck in meetings for the next 2 hours at least but will try to do some tests in parallel
 * ogra_ is in a call now as well
<xnox> jibel: uploaded a fix into raring-proposed unapproved queue and pinged about it on #ubuntu-release. Also committed a fix for the next upstart upload into saucy.
<ev> mpt: I don't think using the rate of errors is going to work for determining whether the architecture is significant.
<ev> As an example, if we have 1,000 errors from 1,000 am64 machines in a day, the error rate is 1. If we have 1 error from 1 machine in that same day, the error rate is also 1.
<xnox> ev: but if on adm64 for a particular crash error rate is 0.98, whilst i386 error rate is 0. it does imply an arch specific bug. And a single error from a single i386 machine instantly makes the bug report "not arch specific, yet triggered easier on amd64"
<ev> xnox: the error rate would be 1 on both cases
<ev> or am I missing something?
<xnox> ev: i see what you mean, as we only collect crashes.
<xnox> ev: i guess what matters is proportion of architectures within a given crash report, and whether it's statistically significant disproportion.
<ev> xnox: as opposed to machines that were out there running a particular version, package, and architecture?
<xnox> that's overly specific, but yeah =)
<ev> xnox: yeah, proportion seems to be more helpful at least for architecture differences
<xnox> if foo is 50/50 amd64-i386 yet one crash of foo is 90/10 amd64-i386 it does hint arch-specific bug or "... easier to trigger on amd64"
<ev> I've been using >= 75% in my tests
<xnox> ev: but even comparing with overall architecture split of all machines reporting any errors would be fine. As anything within 20% of a split can be accounted to random.
<xnox> ev: 75 sounds good, but what's the current split between amd64/i386 reporters? 50/50? 60/40? 70/30?
<xnox> (across all crashes ever uploaded)
<ev> that's a good question, and an interesting thing to start monitoring
<xnox> it's not true indication of install base, but for the purpose of hinting arch-specific bugs that's the only baseline we can go by.
<xnox> ev: don't forget about multi-arch though, just because my machine is :amd64 a crash in :i386 package should still count towards i386.....
<ev> oh ew.
<ev> I had not considered that.
<ev> I've been going off the Architecture field in the report.
<xnox> ev: all skype crashes are i386 binaries & libraries & dependancies. As there is no amd64 skype.
<ev> yeah
<xnox> ev: if the Architecture field from the report comes from the dpkg Architecture filed, all is fine. If it comes from machine/kernel then it's not so useful for this exercise.
<xnox> ev: of course there are kernel bugs that only matching i386 kernel + i386 userspace binary will trigger, but those are rare.
<xnox> and given enough reporters should still generate significant arch bias.
<mpt> ev, if we have 1000 errors from 1000 amd64 machines in a day, that would be a fluke unless the error is clock-based. Nonetheless, the calculated error rate wouldn't be 1000/1000, it would be 1000/(weighted count of AMD64 machines).
<mpt> Which, at the moment, is 1000/(number of AMD64 machines that reported any error in the past 90 days).
<mpt> But would become more sophisticated once bug 1077122 is fixed.
<ubottu> bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed] https://launchpad.net/bugs/1077122
<ev> why would 1,000 errors from 1,000 amd64 machines be a fluke?
<mpt> It would be a fluke that every single machine that had the error had it only once in that 24 hours -- that none of them had it twice or thrice.
<mpt> (And thank you for giving me an opportunity to use the word "thrice". I was beginning to lose hope of using it at all in 2013.)
<ev> you could start listening to the band. That would give you plenty of opportunity
<ev> I'm not convinced this solves the problem though. The frequency an error occurs at is not what makes the architecture interesting. The percentage of instances that occurred on said architecture is though.
<ev> mpt: You may have an error that, on average, happens twice a day for i386 and twice a day for amd64, but is significantly more prevalent on amd64.
<stgraber> ogra_: early-init is pretty much the first thing to be called right?
<ev> even when factoring in the population of systems seen in the past 90 days
<stgraber> ogra_: (talking of init.rc targets)
<ogra_> stgraber, hmm, yeah, i think so
<stgraber> ogra_: ok, I'll try to dump my extra mount line as the first thing it does, that seems to be the easiest to do with sed and should avoid any potential race
<slangasek> stgraber: current util-linux supports /run/mount/utab; however, the implementation is only half-finished despite having been rolled out in Debian, Debian bug #702935
<ubottu> Debian bug 702935 in mount "'mount -f' does not update /run/mount/utab" [Serious,Open] http://bugs.debian.org/702935
<stgraber> slangasek: ok, good to hear someone's working on that. I indeed noticed /run/mount/utab in the strace output but the file ended up empty so wasn't of much use (which appears to be exactly the bug you mentioned)
<mpt> ev, if you're controlling for the proportion of machines that have that architecture, you'll end up with exactly the same result starting from the proportion of errors coming from an architecture as if you start from the error rate for the architecture. They're just two routes to the same formula: (errors(amd64)*count(all arches))/(count(amd64)*errors(all arches)).
<slangasek> stgraber: right; it's meant to be supplemental to /proc/mounts, so it's assumed that /etc/mtab is a symlink there first of all - but it still fails in various scenarios
<doko> Daviey, zul: can I pass you the  system-config-cluster merge?
<Daviey> doko: I think that one is better handled by either roaksoax or ivoks TBH
<doko> roaksoax, ivoks: ^^^. thanks for the pointer
<ivoks> sigh
<ivoks> that thing is still alive?
<ev> mpt: so we don't actually keep a count of the number of unique machines over a 90 day period per architecture, yet.
<ev> mpt: we never did return to the denominator question. Is this "count of machines (eventually weighted)" for the bucket in question, or for all problems seen that day?
<mpt> ev, remember it's not just per-architecture: That's just one of the most interesting variables.
<mpt> Package versions being another, locale settings, upgrade vs. fresh install, etc.
<ev> sure, I was just doing architecture first as it seemed easiest
<ev> "c(amd64)" implies an architecture-specific count of machines
<mpt> Okay, just as long as you don't fix that problem in a way that works for architecture and nothing else
<ev> I can't envision a way in which I would, but I'll keep that in the back of my mind
<mpt> ev, re. denominator: Neither. It's the count of machines that are using Ubuntu.
<roaksoax> doko: i can take care of it
<doko> roaksoax, thanks
<ev> mpt: yeah, we don't keep a count of the number of unique systems in the past 90 days for a given architecture. I'll work on a branch to add this to both the current approach and the weighting code
<stgraber> ogra_: ok, I have an updated pre-start.sh that fixes /dev/socket (triple testing it now)
<ogra_> yay
<stgraber> ogra_: had to read android's init source code to figure out exactly how those commands work... they look like shell but they're not at all...
<ogra_> heh, no, its its own language
<stgraber> after reading builtins.c it's much clearer what's allowed and what's not :)
<stgraber> ogra_: I guess I should probably fix cpuctl too while I'am at it?
<ogra_> i'm not even sure we access it
<ogra_> but yeah, all subdirs in /dev should eb available in the hosts /dev preferably
<ogra_> we can drop them still if we find we dont need them
<stgraber> ogra_: ok. I'll do the right thing for it which is to bind-mount /sys/fs/cgroup/cpu to /dev/cpuact (we already have it in the host, just not at the same place as Android)
<ogra_> stgraber, err, with the same permissions ?
<stgraber> or rather, have it symlinked when booting the current flipped images and have it bind-mounted when booting the loop-mounted images (much simpler to implement)
<ogra_> i took the /dev nodes because i know everything is already processed there and listening processes are in place proper
<stgraber> ogra_: yep, the permissions are identical as the cgroupfs isn't namespace aware and so any change from android or from ubuntu will show up on the other side
<ogra_> ah, good
<ogra_> cjwatson, just FYI, maguro and grouper images work fine from the new build
<stgraber> ogra_: please test http://paste.ubuntu.com/5817323/
<stgraber> ogra_: tested here and I get /dev/socket and /dev/cpuctl working as expected (and no more /proc/<pid> black magic)
<ogra_> stgraber, i think the cpuctl stuff should become a udev rule instead
 * ogra_ reboots with the changes
<stgraber> ogra_: that'd trigger on what? you need to wait until cgroup-lite is started before it can be bind-mounted so it can't be a reaction to a uevent
<cjwatson> ogra_: Brilliant
<ogra_> stgraber, hmm, i was thinking to just match on sysfs node creation ... but that might indeed not work then
<ogra_> stgraber, the change doesnt work
<ogra_> Jul  1 17:12:07 ubuntu-phablet ofonod[868]: Excluding AT modem driver
<ogra_> Jul  1 17:12:07 ubuntu-phablet ofonod[868]: create_ril: can't connect to RILD: Connection refused (111)
<ogra_> Jul  1 17:12:07 ubuntu-phablet ofonod[868]: Exiting...
<stgraber> ogra_: what do you have in /dev/socket on Ubuntu?
<ogra_> the right files
<ogra_> but apparently the connnection between rild and the socket on the android side isnt working
<stgraber> Jul  1 17:03:35 ubuntu-phablet ofonod[1253]: [UNSOL]< UNSOL_RIL_CONNECTED
<stgraber> Jul  1 17:03:35 ubuntu-phablet ofonod[1253]: No SIM card present.
<stgraber> I have that on mine
<ogra_> weird
<ogra_> i have ofono just adly respawning on maguro
<ogra_> *madly
<ogra_> stgraber, out of ten reboots one worked
<ogra_> stgraber, so the race got a lot worse than without the change
<ogra_> (it was one out of 20 or so that failed before)
<ogra_> and the boot seems to have gotten slower
<ogra_> but thats a subjective feeling
<ogra_> (at with an 1.5min boot probably even not a real issue :P)
<stgraber> ogra_: not sure what would make boot slower, we're doing less stuff now :)
<stgraber> ogra_: can you get: lsof -n -p <pid of rild> 2>/dev/null
<ogra_> yeah
<stgraber> ogra_: to avoid a respawn loop we could have a start on starting upstart-file-bridge job create /dev/socket, then have ofono.override use FILE=/dev/socket/rild
<ogra_> doesnt work
<ogra_> :)
 * ogra_ spent days on that bit already ... just to find that inotify doesnt seem to operate on sockets 
<ogra_> so the file bridge doesnt work
<ogra_> stgraber, i think having it respawn properly is the solution... just add that upstart fix so ofono doesnt die on respawns :)
<stgraber> ogra_: well, upstart as a respawn limit, so on fast phones we may hit it, then ofono won't start...
<ogra_> oh, we actually want the limit being used
<ogra_> but we dont want it to die on the second one already :)
<stgraber> actually we should just have a wait loop in pre-start, that'd be much simpler :)
<stgraber> oh, just like we do, nevermind
<stgraber> oh, 8s sleep is a bit excessive isn't it? it's basically the time the phone takes to do a full reboot here
<ogra_> lol
<ogra_> yeah, mako isnt our target arch
<ogra_> a reboot on maguro takes  about 2-3min
<ogra_> the boot lies between 50sec and 1.5min alone
 * ogra_ would really like to get rid of the shutdown process ... having the shell thell the apps to save the UI realted data, calling sync and reboot -f would be so much more effective)
<stgraber> ogra_: anyway, got that lsof output?
<ogra_> stgraber, the 8s was already in ... i think telepathy required it in unflipped
<ogra_> stgraber, stop sending me copy paste lines with 2>/dev/null ... then i can easier find out that lsof isnt installed :P
<stgraber> ogra_: ah yeah, should have told you you'd need to install it first ;)
<ogra_> heh, i thought it was in -minimal
<stgraber> ogra_: the 2>/dev/null will be useful once you have it though (otherwise it spits out errors about unknown uids)
<ogra_> http://paste.ubuntu.com/5817408/
<ogra_> looks ok
<ogra_> this boot also has found the socket in time
<ogra_> stgraber, so your idea is to loop over lsof until it connected ?
<stgraber> ogra_: can you get me the same thing from a boot where the socket doesn't work?
<stgraber> ogra_: well, I'm not sure why it doesn't connect... to me it seems like if the socket exists it should work, so I'd like to see exactly what rild is listening on when it doesn't work
<ogra_> if i only could get one now
<ogra_> the first ten were all broken ... the next ten werent
<stgraber> I first thought it was a race in my init.rc change but I triple-checked and early-init runs before everything else including ueventd so there's no way that rild can be spawned before that and listen to the wrong /dev/socket (the one under my bind mount)
<slangasek> stgraber: race between the bind() and listen() calls?
<slangasek> well, not a race /between/ those calls; but a race because bind+listen is not atomic
<ogra_> stgraber, http://paste.ubuntu.com/5817423/
<ogra_> stgraber, nah, the race is oldm nothing you caused ... but the timing of the startup indeed changed a bit
<ogra_> ofono used to come up later before
<ogra_> slangasek, well, likely something inside rild ...
<ogra_> not much we can do about it
<cjwatson> Can anyone unpick https://jenkins.qa.ubuntu.com/job/saucy-adt-apt-clone/7/ARCH=amd64,label=adt/artifact/results/log ?  It doesn't happen for me locally, and I don't think acpi-support has changed.  Although I suppose it relies on archive state so maybe it's inherently chancy ...
<stgraber> ogra_: that second lsof shows that it's listening twice
<ogra_> ah
<slangasek> ogra_: yes, bind+listen are the calls made by rild
<ogra_> stgraber, hw do you see that ?
<ogra_> i only see one entry
<slangasek> listen-before-bind would be race-free, but I'm not sure if that's actually allowed... it's not the conventional order
<ogra_> stgraber, you mean the first one shows it is listening twice, right ?
<ogra_> oh, how did my browser tabs flip their places
<cjwatson> We can't have rild fork/daemonise/whatever after it listens?
<ogra_> stgraber, ignore me ...
<cjwatson> Ah, I guess it isn't supervised by upstart
<ogra_> cjwatson, rild is a highly confidential binary blob
<cjwatson> i.e. broken :)
<ogra_> living in android ... and each vendor seemss to have its pown rild implementation
<ogra_> *own
<cjwatson> Can we ptrace it?
<slangasek> currently it's launched by android init
<ogra_> they are not even 100% protocol compatible
<cjwatson> i.e. ptrace until it calls listen, detach, emit upstart event
<slangasek> we could unpick all of that, but currently we're trying to avoid having to make deep changes there
<slangasek> I suppose a ptracing wrapper could work
<slangasek> cjwatson: do you know ptrace well enough to cook something like that up quickly?
<ogra_> for kernels where we have ptrace :)
<cjwatson> Do we not have ptrace on the relevant kernels?
<stgraber> that should be all of them, otherwise upstart would have some difficulties
 * ogra_ doesnt think it is enabled on ports 
<slangasek> ogra_: er, that seems unlikely
<ogra_> cjwatson, in our nexus kernels it definitely is
<slangasek> the ports kernels need to have ptrace enabled, period
<cjwatson> slangasek: It'd be ab initio, but I can read docs quickly :)  However I'm at EOD for today
<slangasek> if they aren't currently enabling it, that's a bug that they'll need to fix
<slangasek> cjwatson: mmk, never mind then :)
<ogra_> slangasek, yeah, its a one line change to the porting docs
<ogra_> just saying i dont think they have it now
<cjwatson> If they don't, as stgraber says, Ubuntu won't work
<stgraber> ogra_: so, just to confirm the theory, what happens if you add let's say a 5s sleep after you find the socket and before starting ofono?
<ogra_> oh, k
<ogra_> stgraber, to the existing 8s sleep you mean ?
<stgraber> ogra_: if we indeed have a race between bind/listen, that should be way enough to get it past that point and so it should be reliable (wouldn't recommend it as a solution, but good enough to test)
<stgraber> ogra_: right, the current loop won't be executed (no sleep) if the socket is found, the 8s is only if it's not there
<stgraber> ogra_: so just add a "sleep 5" after the while loop
<ogra_> oh, right, let me add 5s above the while
<stgraber> below please
<ogra_> bah, to late ...
<stgraber> otherwise we may still get the race
<ogra_> even tough ... heh ... another hanging reboot
<stgraber> (if the socket happens to show up right after the sleep 5, we'll skip the loop and start running ofono before the bind/listen is done)
<ogra_> yeah
<stgraber> ogra_: can you retry with the sleep after the while loop, as the last thing in pre-start?
<ogra_> yes, waiting for the boot ro finish
<ogra_> (as i said, takes minutes)
<ogra_> this one worked, let me do a few more
<ogra_> stgraber, still there ... but more like it was before the shole change
<ogra_> *whole
<ogra_> 1 out of 10 fails
<stgraber> not very reassuring
<ogra_> well, as long as the respawn works all is fine
<stgraber> right and I gave a workaround to rsalveti for that earlier
<ogra_> adding the 5s sleep and having respawn work should get us going until we can do something proper
<ogra_> so its just that upstart fix :)
<ogra_> stgraber, ok with you if i add all the chnages to lxc-android-config now ?
<ogra_> or do you have a package branch ready
<stgraber> ogra_: I'll upload in a couple of minutes
<ogra_> ok
<ogra_> rsalveti, readable /dev/socket for you ^^^
<stgraber> ogra_: I won't push the ugly while loop (instead of respawn) though as I just thought of a couple of problems that'd cause (pid tracking), so I'll just try to fix the upstart bug asap (once I'm done with lunch, uploading that stuff and a couple of meetings)
<ogra_> stgraber, right, the 5s sleep should be fine for now
<ogra_> as long as we arent more broken than before i'm fine for now
<ogra_> the respawning usually works at least once ... its the subsequent ones that fail
<rsalveti> ogra_: thanks, patch seems fine
<rsalveti> stgraber: thanks :-)
<ogra_> stgraber, so i used the UI for the first time with the change in place ... *something* changed ... it is a lot less choppy !
<ogra_> i can scroll through G+ without it stuttering now ... never worked on the flipped images
<stgraber> ogra_: uploaded
<ogra_> thx
<ogra_> stgraber, ugh, copying the two files over to the grouper breaks completely :(
<stgraber> ogra_: hmm, that's weird, can't think of why the change wouldn't work on grouper... let me update mine quickly (for some 30min definition of quickly... that's why I don't use it)
<ogra_> stgraber, lxc_conf - File exists - failed to symlink '/dev/pts/ptmx'->'/dev/ptmx'
<ogra_> weirdo
<stgraber> ogra_: weird indeed, can't remember changing anything that'd affect that...
<ogra_> yeah
<ogra_> they are also the exact same image both installed at the same time
<ogra_> the only thing that differs is that there is indeed no rild on the N7
<ogra_> stgraber, aha, the init.rc mangling doesnt happen
<stgraber> ogra_: ah? missing early-init target?
<ogra_> nope, it is there
<ogra_> but the mount line isnt
<stgraber> ogra_: what mount line? my new sed only requires "on early-init" to be present, then it adds a mkdir and a mount line below it
<ogra_> right, these two arent there on grouper
<ogra_> i see them on maguro
<ogra_> hmm, no red herring
<ogra_> seems it didnt even unpack the initrd
<ogra_> stgraber, so it looks like we dont get into pre-start.sh at sll
<ogra_> *all
<stgraber> ogra_: container started fine here (using loop mount)
<ogra_> very weird
<stgraber> ogra_: ah, wait a sec, I'm not on the new lxc-android-config ;)
<ogra_> i really only replaced the upstart job and pre-start.sh with the ones from maguro
<ogra_> on a brandnew image
<stgraber> ogra_: ok, rebooted with the new version of lxc-android-config and the container still starts /dev/socket and /dev/cpuctl look good and init.rc contains the two extra lines
<ogra_> hmm weird, i'll wait for the package
<tedg> ogra_, So when /sbin/initctrl is move to /sbin/initctrl.REAL is /sbin/init moved as well?
<ogra_> nope
<tedg> K
<tedg> ogra_, Thanks
<ogra_> tedg, debian-installer-utils has a good reference script (chroot-setup.sh), similar code is used all over the place when chroots are used and daemon startups need to be prevented
<tedg> ogra_, Wow, that's a very evil script :-)
<ogra_> well, thats what you need to do in an image build chroot or if you want to avouid to taint a fresh install while putting stuff into place
<tedg> Sure, but that's usually a little bit lower than where I play.
<ogra_> yeah, plumbing ...
<luist> anyone familiar with multistrap?
<ogra_> stgraber, lol ... so i transferred pre-start.sh via adb from one devices to the other ... guess what my issue was :) .... adb removes the executable bits from files
<ogra_> stgraber, so flase alarm, all is fine with the scripts ...
<stgraber> ogra_: oh, that'd explain it ;)
<stgraber> good
<ogra_> wow
<ogra_> and even the nx7 all of a sudden feels snappier
<luist> can anyone help me with multistrap? I'm trying to add my custom repository/package , but its not working. This is the config file: http://pastie.org/8101130
<roaksoax> doko: makes sense? http://paste.ubuntu.com/5834245/
<doko> roaksoax, did the fix for the desktop file exist before? if yes, then maybe write in the changelog "resync ..., remaining changes"- but that's a minor nit.  and use -v to include the changes from the debian updates in the changes file
<roaksoax> doko: cool thanks1
<hallyn> jibel: ok, sorry this took so long - had some other issues.  but all i'm seeing is that memsw.limit_in_bytes appears to be misbehaving
<bdmurray> dobey: are you working with software-center now?
<dobey> bdmurray: it's in maintenance mode, so sort of. my team owns it now though, yes.
<bdmurray> dobey: there is a reference in aptd.py to ERROR_PACKAGE_MANAGER_FAILED errors (from aptdaemon) and those being reported by dpkg and this isn't really happening and trying to sort out why
<bdmurray> aptdcon creates package install failure crash files and so does apt itself, so I think software-center is stopping them some how
<dobey> bdmurray: unfortunately i don't really know much about the core of the code. maybe send an e-mail to glatzor/mvo about it?
<bdmurray> dobey: okay, thanks
<dobey> sure
<hallyn> jibel: when i remove that line from the config, i can start the otto container - no complaints about devices cgroup
<hallyn> oh, d'oh.  but that wasn't kernel 3.10.  sigh.
#ubuntu-devel 2013-07-02
<pitti> Good morning
<dholbach> good morning
<jibel> hallyn, thanks for looking. What was the problem with memsw.limit_in_bytes? I had to enable is with swapaccount=1 on the boot command line. Anyway, I'll try to reduce the test case on a fresh installation.
<bigon> hi, is that expected that rmadison tool is still showing me packages from hardy?
<xnox> bigon: probably just not removed from the rmadison config.....
<xclaesse> seb128, (sorry if it's not you to ping): gnome3 ppa has libharfbuzz-icu0 package but no corresponding -dev
<seb128> ricotz, ^
<xclaesse> something went wrong in the split of icu out of harfbuzz I guess
<ricotz> xclaesse, the libharfbuzz-dev packages contains the needed dev bits
<ricotz> xclaesse, i wasn't involved in the split, but it is fine that way
<xclaesse> ricotz, hmmm, indeed... wondering why my webkit build does not find it then :/
<xclaesse> probably confused between distro package and what's in jhbuild :(
<doko> mlankhorst, mdeslaur: you looked last at libx11 and libxcb. could you have a look at the build failures in the test rebuild? and/or decide on the merge from debian?
<xclaesse> thanks anyway :)
<ricotz> xclaesse, probably make sure you have libicu-dev installed and maybe even enable the harfbuzz-confflag explicitly
<cjwatson> bigon: I've removed hardy and oneiric from rmadison, thanks
<mlankhorst> sure
<tseliot> pitti: hi, can you approve nvidia-graphics-drivers-319-updates in saucy please?
<pitti> hey tseliot
<pitti> tseliot: approve for NEW, presumably? it's been a while since I've done archive admin, let me look
<pitti> tseliot: did the packaging or license change compared to the previous versions?
<tseliot> pitti: yes, new and then please move the binaries to main
<pitti> tseliot: restricted, I presume?
<tseliot> pitti: not really, it's the same as the 319 flavour
<tseliot> pitti: yes restricted
<pitti> "same as 310"?
<pitti> oh, 319 without updates
<tseliot> yep
<tseliot> 319 replaces 310
 * pitti gives that some spot-checking and comparing with -319
<pitti> tseliot: LGTM, source-NEWed
<tseliot> pitti: excellent, thanks!
<pitti> cjwatson, xnox: I'm currently experimenting with letting DanChapman's ubiquity autopilot tests run in a VM with xvfb; before I get to that, I need to provide it with a fake disk drive, so that it has something to install to
<pitti> I created a 5 GB loop device and put a raid0 on top of that, getting a /dev/mdX; that bit works fine
<cjwatson> I think it will probably need to look a bit more like a regular disk
<cjwatson> Maybe virtio instead?
<pitti> is there a way to hide the other, "real" /dev/vda from partman's consideration?
<pitti> right now, if I do it like that and install in automatic mode, it trashes the (mounted!) /dev/vda, partitions/overwrites it, and fails
<pitti> with manual partitioning to /dev/md42 it works
<xnox> pitti: providing fake disks to the installer and hiding host/VM disk, is something i have not managed to do yet. If this was possible, we'd be able to fully automate installer tests in lxc or somesuch =)
<pitti> xnox: well, we have the smoketests, but they use pre-seeding; it would be cool to run the ubiquity UI tests with autopilot
<pitti> we don't need to actually boot the installed disk, of course
<cjwatson> There isn't a general filter mechanism, short of diverting parted_devices or something
<pitti> just a coarse inspection that the partitioning is right should be enough for the UI tests
<xnox> pitti: yeah, my current plan was to further modify ubiquity pre-seeding to self launch itself under autopilot, instead of using preseed-file to automate itself.
<xnox> (if above makes sense)
<cjwatson> (Which isn't necessarily *completely* stupid; divert it, call the real one and grep out the devices you don't want ...)
<doko> barry, you uploaded python-configglue, without a MIR for python-configparser
<pitti> cjwatson: that seems fine
<pitti> it's a bit of a bugger that it defaults to a mounted device, but I guess that doesn't happen in real life
<doko> zul: you uploaded python-greenlet without a MIR for python-all-db
<pitti> cjwatson, xnox: I also need to divert grub-install for that, as my fake /dev/md42 isn't visible by grub; diverting /usr/sbin/grub-install doesn't work, though, as it calls grub-install from /target; did any of you already run into this? if not, I'll look for a workaround
<cjwatson> There are various mechanisms for avoiding the installation medium, avoiding things that are part of dmraid, and the like, but the above isn't one of them
<pitti> we can of course also set up a custom VM with a spare virtio drive
<cjwatson> I'm concerned that by the time you've worked around all the problems with this it won't look enough like a real environment
<pitti> but I wanted to check if we can do it in a bog standard autopkgtest VM, which would be easiest (also for reproducing problems, etc.)
<cjwatson> The installer is pretty sensitive to details of disk layout
<doko> zul, ahh, a typo. fixed. thanks for testing the build deps before upload ;)
<cjwatson> For GRUB, I'm not sure, what would you do instead if you can't see /dev/md42?
<doko> zul, python-keystoneclient and python-warlock ftbfs
<pitti> cjwatson: I'm not sure what grub-install considers as "see", but its current behaviour is quite alright; I'm mostly checking if we can skip the bootloader install. That's possible in manual mode of course
<pitti> (or brainwash grub-install to accept /dev/mdX anyway)
<doko> jamespage, could you have a look at the maven mess? wants to get in main again, see http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt
<pitti> anyway, I'll play around with this a bit
<pitti> cjwatson: thanks for the parted_devices trick
<jamespage> doko, yeah sure
<doko> jamespage, \o/
<jamespage> doko, hmm dom4j - lets see now
 * jamespage goes to poke it with a big stick
<cjwatson> pitti: I guess it depends exactly how grub-install is currently failing
<doko> Daviey, cjwatson, looking at http://people.canonical.com/~ubuntu-archive/component-mismatches.svg, I see that only ruby-json has a MIR (just promoted)
<cjwatson> We've been asking for MIRs for those for some time :-/
<rbasak> Daviey asked me to look at those last week.
<rbasak> This does seem a bit backwards though. Is it normal to just bump a major version and cause a bunch of component mismatches without examining the situation first?
<doko> rbasak, I think I do repeat myself here. getting puppet away from ruby1.8 was requested for the last *three* releases
<doko> nothing did happen, so I did take the clue bat
<cjwatson> rbasak: I'm wary of complaining about that aspect of it, since it's so easy to do by accident
<cjwatson> But it does need to be sorted out
 * rbasak will sort it out
<doko> thanks
<doko> zul, Daviey: the apache2 merge cause a lot of packages to dep-wait. mdeslaur told me that you would care about it?
<rbasak> doko: please remember that I'm new here. I wasn't aware of any communication about wanting puppet out of ruby1.8. I'd have happily tried a merge without bumping to puppet 3 first had I known about it. Might it be an idea to send a warning to ubuntu-devel or ubuntu-server before you take your clue bat out in future?
<zul> doko: yeah ill take a look at it today
<rbasak> doko: to say "X needs to be done; it hasn't been done, so I propose that I'll do Y unless I hear otherwise".
<rbasak> doko: because had I seen that, I'd have looked at it.
<doko> rbasak, well, I can try (and I didn't know that you were not involved with that earlier). but maybe people should be reminded at the various ftbs and component mismatch web pages at regular intervals
<rbasak> doko: AIUI, puppet wasn't FTBFS nor component mismatching before your upload, though. Is there somewhere that I could have seen that you wanted the ruby1.8 dependency removed?
<doko> rbasak, I don't know. had that mentioned several times at UDS'es in public sessions, so it should have some recording
<rbasak> So I'm new to MIRs. ruby-hiera needs an MIR, but recommends mcollective, which I've found evidence is safe to drop with no consequences. Should I just upload a ruby-hiera delta that drops the recommends down to a suggests first before filing the MIR to resolve that issue?
<rbasak> ie. do we do uploads to universe to get packages ready for main inclusion?
<rbasak> (I presume so but I wanted to check)
<xnox> rbasak: yeah. packages are promoted from universe/multiverse into main/restricted. Thus they should be in the archive already.
<rbasak> OK, thanks!
<dpm> seb128, ok, this is still WIP, but I've added the Launchpad setup instructions for new translatable projects, so that next time it's easier to find out how to do it -> https://wiki.ubuntu.com/Touch/CoreApps/Translations
<dpm> it's for core apps, but it can apply to any LP project really
<ev> mpt: is the count of machines what we're really weighting? I thought it was the errors themselves? That is, (min(days since first error, 90) / 90.0) for each error in the release / number of unique systems seen in the past 90 days in the release
<ev> This is looking at "c = count of machines (eventually weighted)"
<ev> (for the error rates of architectures in each problem)
<seb128> dpm, thanks!
<mpt> ev, I think you need to weight both
<mpt> The point of weighting a machine when counting it is to take into account the probability that it no longer exists, no matter what you then use that count for.
<ev> we create an awful lot of work for ourselves by not just counting systems running Ubuntu.
<ev> mpt: so what would you weight the denominator with?
<mpt> Even if we did count them, we'd still need to weight them in exactly the same way. :-)
<ev> fair point :)
<doko> pitti, there seems to be a bug in your dependency tracking code for component mismatches. shortens libc++ to libc ...
<cjwatson> That's not pitti's code
<cjwatson> Wait, unless I misunderstand.  Which dependency tracking code do you mean?
<doko> cjwatson, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
<doko> and it eats dashes too in the popups
<doko> the txt files seem to be correct
<hallyn> jibel: well I"m not sure.  I had swapaccount=1 set in my grub.cfg, but it never seemed to honour that.  kept getting EOPNOTSUPP
<cjwatson> Wah, where on earth is libc++ in all of that
<cjwatson> Oh, I see, that might be my fault
<doko> on the top, the graph shows gmp depending on libc
<doko> and unrelated, if you hover over the green circles, then the dashes are missing in the popups
<mpt> ev, r(whatever) = ( Î£ whatever (machine weight * errors in period / period) ) / ( Î£ whatever (machine weight) )
<mpt> I doubt that's simplifiable
 * xnox ponders about introducing LaTeX irc extensions.....
<ev> I maintain again: we need a whiteboard
<ev> xnox: this thing doesn't even support unicode properly.
<maswan> xnox: just write it out, the experienced reader will understand \frac{...
<maswan> xnox: had a lecturer that provided lecture notes on the web in that form, was surprisingly readable. :)
<ev> mpt: this looks completely different than the previous formula for weighting errors per calendar day. Was that method incorrect?
<cjwatson> doko: Currently wishing I were a little bit more familiar with dot
<mpt> ev, no, the difference between them is bug 1077122. :-)
<ubottu> bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed] https://launchpad.net/bugs/1077122
<mpt> oh, we had a previous formula for *weighting* errors?
<mpt> Oh, right, P = e ^ (âÎ» t)
<ev> no, I think this is the confusion I have between bug 1077122 and bug 1069827
<ubottu> bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed] https://launchpad.net/bugs/1077122
<ubottu> bug 1069827 in Errors "Error rate incorrectly spikes with any influx of machines" [High,Confirmed] https://launchpad.net/bugs/1069827
<mpt> P = e ^ (âÎ» t) is just my prediction of what the weight curve will end up looking like
<cjwatson> Looks like there might be an undocumented way to quote symbols
<doko> didrocks, promoted sphinxbase n -proposed as well
<mpt> ev, yeah, probably we should avoid using the word "weight" w.r.t. 1069827 ... that's a fudge
<mpt> 1077122 is about the probability that a machine doesn't exist any more
<didrocks> doko: thanks!
<mpt> 1069827 is about the probability that a new reporting machine is representative of a large number of new not-yet-counted machines
 * ev nods
<ev> that much I get, and it results in the formula you came up with and I coded with the following test: http://bazaar.launchpad.net/~daisy-pluckers/daisy/trunk/view/head:/test/test_weighting.py#L42
<ev> but what I don't get is how that connects to weighted machines or bug 1077122
<ubottu> bug 1077122 in Errors "Machine weighted at 100% 89 days after last report, 0% 90 days after" [High,Confirmed] https://launchpad.net/bugs/1077122
<mpt> aha, weight weight weight
<doko> seb128, you synced jackd2 from experimental, now stuck in -proposed because of a component-mismatch (opus)
<ev> I see a whiteboard, off in the distance
<ev> but I bet people are precious about it
<seb128> doko, seems like one for TheMuso or diwic
<seb128> TheMuso, ^ could you have a look?
<mpt> We could call them ... ramping and damping
<mpt> Ramping is the weight increasing from 0 to 1 over the first 90 days
<mpt> Damping is the weight declining from 1 to 0 over however long machines are known to usually take to do that
<cjwatson> doko: Fixed for the next run; those two things were actually not unrelated, but two aspects of the same problem
<doko> cjwatson, thanks!
<doko> seb128, TheMuso: https://bugs.launchpad.net/ubuntu/+source/opus/+bug/1196967
<ubottu> Launchpad bug 1196967 in opus (Ubuntu) "[MIR] opus (b-d of jackd2)" [Undecided,Incomplete]
<doko> jamespage, jarjar now requires libasm4-java instead of libasm3-java. should we just promote this, or trying to demote libasm3-java?
<cjwatson> doko: Also fixed the slightly incorrect +filebug links for the next run
<doko> cjwatson, I didn't note that one =)
<cjwatson> quote_plus is my friend
<jamespage> doko, we should go for demoting asm3 if possible - there are only two other deps in main
<jamespage> * libcglib-java
<jamespage> * libow-util-ant-tasks-java
<doko> jamespage, ok, then I'll promote and file issues for these
<doko> jamespage, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg now looks much nicer without the maven stuff
<jamespage> doko, yeah - I had to drop the XSD support that ebourg added
<jamespage> msv looks awkward - again I'll raise a bug to track we disabled it and why
<jamespage> if someone wants to re-enable then converting msv to build with ant would make sense
<doko> barry, there is a MIR missing for python-configparser for your python-configglue upload
<barry> doko: ack
<doko> barry, just uploaded configparser to remove the unused python-support b-d
<mpt> ev, mistake fixed. https://wiki.ubuntu.com/ErrorTracker?action=diff&rev2=170&rev1=169
<jamespage> @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 lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: jamespage
<ev> mpt: right, that's how we have it in the code as well
<doko> didrocks, seb128: who is handling qtwebkit-opensource-src? (b-d of signon-ui now)
<didrocks> doko: Mirv
<doko> Mirv, ^^^
<mpt> ev, basically the mistake was our April attempt to answer the question, What if the ramping and damping overlap? I thought the damping should immediately stop the ramping. But  if they just multiply each other, the weighting curve is smoother over time, which suggests it's more correct.
<doko> jamespage, https://bugs.launchpad.net/ubuntu/+source/ow-util-ant-tasks/+bug/1196979
<ubottu> Launchpad bug 1196979 in ow-util-ant-tasks (Ubuntu Saucy) "[MIR] libasm4-java (b-d of jarjar)" [Undecided,New]
<ev> ah, right
<jodh> stgraber/cjwatson: could you take a look at lp:~jamesodhunt/upstart/fix-libupstart and suggest why this might be failing at the 'make distcheck' stage due to lib/upstart/ not having been created?
<doko> didrocks, hmm, and sphinxbase is ftbfs in -proposed
<didrocks> doko: I think it's mterry who uploaded it, right? ^
 * mterry looks
<mterry> didrocks, hrm, so I am
<xnox> jodh: in the gen target you use all pre-requisites via variable "$<", one of your prerequisites is "upstart" which is just a directory and actually shouldn't be part of the nih-dbus-tool call. And when using suffix rules the amount of targets $@ should match the amount of pre-requisites $<.
<seb128> didrocks, making mterry pay for enabling tests on build? :p
<didrocks> seb128: exactly, failing on i386! :)
<xnox> jodh: that might not be all of it, but it does result in out-of-order execution, where "upstart/com.ubuntu.Upstart.c" is generated from matching .xml pre-requisite, without considering "upstart" dependency.
<mterry> didrocks, seb128: pfft, who uses i386 anymore?
<didrocks> mterry: agreed, only some people like seb128 does that! :p
<jodh> xnox: $< is the first prereq, $^ is all.
<seb128> mterry, you!
<seb128> mterry, (and me)
<seb128> or did you stop?
<mterry> seb128, I'm on amd64 now
<mterry> seb128, join us!
<seb128> bah
<seb128> mterry, I will when I get my new laptop
<seb128> mterry, I'm just pondering between 2 models, need to decide on that ;-)
<xnox> jodh: excatly, which means that "upstart" prerequisite is not needed to build $@ using $<
<xnox> thus not executed beforehand.
<seb128> mterry, I wish Dell was making an xps13 with a non glossy screen
<dobey> i wish someone would make a 10" laptop that's at least 1080p, if not 4k2k
<Sarvatt> seb128: absolute worst time to buy an ultrabook but x1 carbon has my recommendation from the current models (and its matte) :P
<xnox> psivaa: i do wonder what has changed in the mean time, as well installer was not updated/uploaded in the timeframe between failures and the bug disappearing =)
<cjwatson> I'm dealing with it :)
<cjwatson> xnox: ^
<xnox> ack.
<seb128> Sarvatt, I hate thinkpads' look
<jodh> xnox: I think it is. the problem seems to be that lib/upstart/ is getting created in the unpacked source directory, not _build/lib/upstart/ which is where I though it would create it as I've specified $(builddir).
<doko> zul, apache2 failed to build
<xnox> jodh: strange.
<zul> doko:  strange it built fine here
<doko> zul using -proposed components?
<zul> doko:  no
<zul> ill take a look
<psivaa> xnox: is this about bug #1195690
<ubottu> bug 1195690 in ubiquity (Ubuntu) "Exception in GTK frontend during preseeded default installations" [High,New] https://launchpad.net/bugs/1195690
<psivaa> which does not occur anymore btw
<cjwatson> Oh, OK, xnox may be asking psivaa about a different bug from the one I thought
<cjwatson> Sorry for butting in, then :)
<jdstrand> cjwatson: hi! we've defined the security section of the manifest file and have adjusted our tools to take a manifest file and look under the toplevel 'security' key for a JSON object (dictionary)
<jdstrand> cjwatson: I read http://bazaar.launchpad.net/~click-hackers/click/trunk/view/head:/doc/file-format.rst, but it doesn't have a security section
<xnox> psivaa: yeah that.
<jdstrand> cjwatson: so, I was curious about your thoughts on that (I'd also like to submit a couple of tests for some manifests that have the security section in them)
<psivaa> xnox: not sure how that got fixed, but does not occur anymore, i too did not see ubiquity changes during the weekend
<jdstrand> cjwatson: in other news, we (sbeattie) should be working on the apparmor hook this week
<jdstrand> cjwatson: I plan to write to ubuntu-devel soon for sdk coordination, but here is something of a preview - https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement/Manifest
<jdstrand> cjwatson: (note there is a click package section about half-way down)
<cjwatson> jdstrand: I'm expecting you to fill in the section in that doc
<cjwatson> I don't have any particular thoughts on it really
<jdstrand> cjwatson: ah, when I read the manifest section, I thought you might have been thinking this should be x-security
<cjwatson> Nope
<cjwatson> x- is for local extensions, not for things we define for widespread use
<cjwatson> the point being that that way we can define things without fear of clashing with somebody's local extension for whatever reason
<jdstrand> cjwatson: ok cool. alright, so I'll do a merge request with the doc change and some tests. sbeattie will come along later and may ask about the click apparmor hook
<cjwatson> cool, thanks
<cjwatson> the hook interface may need to be changed; he shouldn't necessarily expect it to be adequate right now
<jdstrand> sbeattie: ^
<jdstrand> cjwatson: ack. are we the first ones to do a hook?
<cjwatson> yep
<cjwatson> though I need to figure out one for desktop files / application upstart job integration / whatever it is
 * jdstrand nods
<Daviey> Isn't X- as a prefix for an identifier considered deprecated now?
<jamespage> cjwatson, there is a merge of efibootmgr in the sponsorship queue - https://code.launchpad.net/~logan/ubuntu/saucy/efibootmgr/0.5.4-6ubuntu1/+merge/169572
<jamespage> it looks OK - are you good for me to sponsor?
<cjwatson> sure, though I thought I already said it was pointless :)
<cjwatson> it's waiting for Sledge to accept a patch I sent to Debian and then it can be a sync
<cjwatson> but whatever
<jamespage> cjwatson, OKies
<cjwatson> Daviey: who gets to deprecate prefixes on identifiers on a format I'm defining, if not me?
<cjwatson> just curious
<mdeslaur> hehe
<Daviey> cjwatson: IETF covention, not a mandate . http://tools.ietf.org/html/rfc6648
<cjwatson> not sure what the IETF has to do with the price of bread here :)
<Daviey> cjwatson: Just conversion, not saying you cannot.
<cjwatson> I think file formats for packaging mechanisms designed to integrate with a particular product are a bit different from widespread interop protocols
<Daviey> Sure.
<cjwatson> I do understand the IETF's reasoning, and considered it - but I think at least at the moment the introduction of new fields is going to be rapid enough that I'd prefer to have an explicit local marker
<Daviey> agreed.
<cjwatson> maybe once things settle down a bit and we have a clearer registry for manifest key names it will be easier
<cjwatson> for now I just wanted to keep local things out of the way and not have to worry about them
<cjwatson> and sorry for being snippy, it's just a stressful project
<infinity>  3879 adconrad  20   0  872m 370m  12m R 100.9  2.3  63:42.74 unity-panel-ser
<infinity>  7465 adconrad  20   0 3944m 3.4g 4548 R  95.6 21.6  19:00.93 indicator-sessi
<infinity> ^-- I can't be the only one seeing this on a regular basis?
<seb128> infinity, it was fixed yesterday
<seb128> infinity, but I guess you didn't kill/restart the service since the update
<infinity> seb128: Oh, shiny.  I'll make with the upgrading.
<seb128> infinity, https://launchpad.net/ubuntu/+source/indicator-session/12.10.5daily13.06.19-0ubuntu2
<infinity> seb128: I hadn't upgraded at all since Friday or so.
<seb128> k
<seb128> upgrade, and kill indicator-session-service (it will respawn)
<seb128> things should be happier then
<infinity> seb128: That'll make unity-panel-service stop being sad too, or is that a different bug?
<seb128> infinity, that seems like a different one but I'm unsure
<infinity> Fun.
<seb128> kill the service as well
<seb128> see if it comes back
<seb128> if it does bug us
<jdstrand> cjwatson: are the installation paths for click packages completely defined? ie, I know it is /opt and something with a reverse domain name, but I don't have the full path
<cjwatson> jdstrand: I expect to have to fiddle with them to support image-based upgrade layouts
<cjwatson> jdstrand: So, no, not set in stone yet
<cjwatson> jdstrand: Currently it's /opt/click.ubuntu.com/<app-id>/<version or "current">/, but the prefix part of that may have to change
<jdstrand> cjwatson: ok, thanks
<ogra_> Setting up lxc (0.9.0-0ubuntu16) ...
<ogra_> chfn: PAM: System error
<ogra_> adduser: `/usr/bin/chfn -f LXC dnsmasq lxc-dnsmasq' returned error code 1. Exiting.
<ogra_> dpkg: error processing lxc (--configure):
 * ogra_ wonders if anyone has an idea how to work around this or if there is already some kind of standard reciepe 
<ogra_> (this is inside a chroot)
<doko> cjwatson, thanks for libtool
<cjwatson> you're welcome
<xnox> doko: there are android specific binutils patches in linaro build.
<xnox> doko: building those now.
<ogra_> oh
<ogra_> i wonder if the quoting is broken in lxc's postinst
<ogra_> hmm
<ev> [17:33:19] <bdmurray>	 is it intended for the graph at https://errors.ubuntu.com/problem/27a5550c8a96660e9b19630655aa1c613772e29b to show the number of reports per day?
<ev> [17:36:03] <bdmurray>	 The security team released a version of ubuntu-release-upgrader to security so I'm expecting to see less incidents per day but I don't know how to see if that is the case or not.
<ev> (reposting here, so mpt can chime in if he so desires)
<ev> so, I think that's the purpose of the version table. You can see if there are instances in the new version without there being noise from users who don't have the latest version installed.
<mpt> ev, yep. I wonder if it would be worthwhile adding the release date of each version to the version table?
<bdmurray> the version table doesn't tell how much more 89996 is than yesterday though
<mpt> ev, bdmurray: If nearly all the reports for that error are in Ubuntu 12.10, why does 12.10 not show up in the graph?
<mpt> The graph shows only Saucy, despite it having no errors in the table at all.
<ev> mpt: if you think it wouldn't add to information overload, sure. Any suggestions to improve that page are definitely welcome. Right now I think it looks a mess.
<ev> mpt: that's because the table back population job hasn't finished
<jamespage> @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 lucid -> raring | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<mpt> ev, is that a job that lags for every bucket?
<ev> mpt: no, it's accurate for new crashes
<tedg> stgraber, Why do you have the dbus upstart job starting before the xsession one?
<ev> just not ones before we added a new column family to track the relationship between releases, versions, and buckets
<ev> (BucketVersions)
<mpt> ok
 * dholbach hugs jamespage
<jamespage> dholbach, managed to clear a few from the sponsoring list
<jamespage> still lots of old ones left tho
<mpt> ev, the left edge of every Y axis label is cropped, but I suspect that's not because there's too little room, but because it's showing error counts rather than rates
<stgraber> tedg: because in the standard Xsession, dbus-agent is spawned before anything that's part of the session, that's to ensure we do the same thing, otherwise things like input methods would fail to connect
<tedg> stgraber, Sure, but wouldn't that be before gnome-session, not the job that sets the env vars?
<bdmurray> mpt: I want to be able to see if the error is occuring less now than it was.  Where would I look for that information?
<dholbach> jamespage, yeah, I noticed - I'll take a look tomorrow :)
<ev> mpt: suggestions also welcome for dealing with very long stacktraces: https://errors.ubuntu.com/bucket/?id=/usr/sbin/NetworkManager:6:g_assertion_message:g_assertion_message_expr:handle_ip_config_timeout:real_act_stage4_ip6_config_timeout:nm_device_activate_ip6_config_timeout&format=json
<ev> I played with using an expander there, but I wasn't particularly fond of it. Was thinking about trying something cute, like a CSS terminal window with scrolling, but maybe that's really silly?
<ev> mpt: it's showing error rates, but yes, I've been working in spare moments today fixing the graphs
<ev> possibly by moving from nvd3 to Rickshaw, since the former is somewhat dead upstream
<stgraber> tedg: not sure I understand what you mean, anything that used to be part of the STARTUP command needs to be run after dbus is started, the only way of ensuring that this is done reliably with the env set for all the jobs is to do it before xsession-init can emit xsession
<tedg> stgraber, So you're worried about the jobs that are start on xsession-init, not the xsession job itself.
<ev> mpt: padding values also welcome :-P
<tedg> stgraber, Shouldn't those jobs be start on started dbus and xsession-init SESSION=foo ?
<mpt> ev, I don't see how the error rate for an individual error could be on the order of 100 times the error rate for all errors combined.
<mpt> e.g. for 13.04 peaking in that particular error around 8.00, while the total error rate is around 0.08.
<ev> I suspect that's due to the small population size for 13.04 when that was recorded
<stgraber> tedg: so let's say you have a job that needs to set an environment variable for the user session and depends on dbus, how would you do that without race conditions if dbus was started after xsession-init is done?
<ev> I was thinking about that last night. Tempted to filter out values if we have less than say, 100 machines
 * ev pulls up the current algorithm for that graph
<mpt> ev, ah, so that will be fixed by the ramping anyway.
<ev> good point
<stgraber> tedg: all of the current conditions are designed so that all the user session environment is ready by the time xsession is emitted so that anything that starts after it inherits the full environment and we don't get into weird races
<tedg> stgraber, That's specifically the issue I have :-)  start on "started dbus and xsession-init SESSION=ubuntu" is what I want.
<ev> so the graph is: number of instances for the bucket in the release / number of unique systems in a 90 period for the release
<tedg> stgraber, The problem I have is that I want dbus to get that env var.
<ev> the denominator is broken on production. It's using the number of unique systems in a 90 period for *all releases*
<tedg> stgraber, Otherwise dbus activation doesn't get it.
<ev> fixed on http://poppy-dev.local/
<stgraber> tedg: what env variable do you need dbus to get?
<tedg> stgraber, I was looking at UNITY_MENUBAR_PROXY.
<ev> mpt: but I do worry that the error rates are such low values
<tedg> stgraber, It's not for dbus itself, but for things that get dbus activated
<ev> http://poppy-dev.local/problem/88ac2e0e3a52787f78f23718c885431aba2a5f9c as one example
 * cjwatson read denominator as dominator (publisher component) and panicked
<ev> (ignore the data in "what's unusual about this problem")
<stgraber> tedg: and does that work if you turn off upstart user sessions? (it shouldn't)
<tedg> stgraber, Right now it's being done by a script thrown in /etc, trying to "upstart-ize" it.
<tedg> stgraber, So it builds the env before upstart runs today.
<ev> cjwatson: have we moved on from naming machines after fruits and minerals to characters from adult cinema?
<stgraber> tedg: just keep it that way then, there's nothing wrong with setting environment variables in /etc/X11/Xsession.d under upstart user sessions
<tedg> ev, Quite clearly, we'll never run out of names with that scheme :-)
<stgraber> tedg: the only case where you need to convert that stuff to user jobs is if you spawn a subprocess
<ev> tedg: :D
<tedg> stgraber, Well, and the fact that to remove it you have to use purge :-/
<tedg> stgraber, I imagine we'll (hopefully) not parse xsession.d for Unity 8 on Mir.
<cjwatson> ev: you know about suggestions being dangerous sometimes, right?
<ev> the Cassandra nodes are named after various demons. I wonder if this was foresight on elmo's part, knowing what would happen if we were allowed to throw massive amounts of data like heavy bricks at the webops team.
<stgraber> tedg: probably not, though until then it's best not to break non-upstart sessions unless we really have to and in this case it doesn't sound like we do
<ev> cjwatson: lol
<mpt> bdmurray, if by "now" you mean "recent days", the graph would tell you that. If you mean "the current package version", the table would be a hint, but you couldn't tell whether it was low because the problem was fixed or just because no-one had updated.
<tedg> stgraber, Well, it's kinda test case.  And these env vars are only used in ubuntu sessions (upstart).
<tedg> stgraber, So here we're not going to break anyone else.
<bdmurray> mpt: I meant recent days so the graph sounds like a good place to look
<mpt> Only three more weeks before the apparent Ubuntu 12.10 error rate climbs back above the apparent 12.04 rate :-]
<xnox> mpt: Ubuntu Visionary and Fortune Teller
<mpt> Okay, a bit more than three weeks. I predict July 27th.
<barry> tedg: ping.  was wondering what if any documentation is available on using dbus-test-runner, and if it's possible to use from python.  i'm working on a new dbus service for the image based update client and i wanted to see if i could use d-t-r in my test suite
<tedg> barry, Uhm, I've written a couple of blog posts.  As far as the command line utility it should be usable anywhere.
<tedg> barry, There's also a library, it should work with GObject Introspection, but I haven't tried.
<tedg> barry, More out of not having a reason than and reason to believe it wouldn't work.
<tedg> Figured someone would ask one day :-)
<barry> tedg: today's the day! :)
<tedg> Heh
<barry> tedg: i think i found your blog.  i'll take a look there.
<tedg> barry, Are your tests using the glib mainloop?  The lib needs that.
<barry> tedg: right now i have no dbus support or tests.  just gearing up for that now
<tedg> barry, Okay, cool.  I'd also recommend looking at the hud test suite.  It does a good job of using dbusmock and dbustest to bring things together.
<barry> tedg: this?  http://bazaar.launchpad.net/~unity-team/unity/trunk/files/head:/tests/
<tedg> barry, No, here: http://bazaar.launchpad.net/~indicator-applet-developers/hud/trunk.13.10/files/head:/tests/
<barry> tedg: cool, thanks
<cjwatson> doko: Please could you merge libapache2-mod-perl2?  Blocks several bits of the Apache 2.4 transition
<doko> cjwatson, ok
<Bayo> oi
<Bayo> oi oi
<sladen> Bayo: hello
<zul> can an archive admin please review python-amqp please, openstack is kind of broken right now because of it
<Daviey> zul: if nobody offers before hand, i will after i have eaten
<zul> Daviey:  cool thanks
<infinity> tumbleweed: The logtail for https://launchpad.net/ubuntu/+source/pypy/2.0.2+dfsg-4/+build/4754026 hasn't moved in a day or so.  Should I assume it's given up trying to do whatever happens next?
<tumbleweed> infinity: the thing that comes next is a make
<tumbleweed> well, once pyhon has shut down
<tumbleweed> I've seen it stick there before on buildds, but never been able to investigate
<infinity> Curious.  I wonder what it's doing there.
<tumbleweed> anyway, you are welcome to kill it if you're still expecting better ARM buildds soon
<infinity> tumbleweed: We have them, but they're being tested currently.
<infinity> tumbleweed: If being hung there isn't directly a result of having crap memory I/O, though, perhaps this is something worth debugging.
<tumbleweed> I always assumed that when builds died here, it was because it took too long to get everything off swap during GCing all the objects in python shutdown
<tumbleweed> s/died/timed out/
<infinity> tumbleweed: So, it's still doing... Something.
<infinity> tumbleweed: http://paste.ubuntu.com/5838153/
<infinity> tumbleweed: Note the python in D state with a bazillion hours of CPU time.
<tumbleweed> that's the translation. I guess it's blocking on that runsubprocess
<tumbleweed> whatever that is doing...
<infinity> Yeah, no idea.
<infinity> I'm going to kill it and retry on a Calxeda node once they're in place.
<infinity> And if that doesn't happen before we ship saucy, I'll remove the armhf binaries so it can all migrate for you.
 * tumbleweed sees mentions of a pypy 2.1 branch in #pypy
<tumbleweed> infinity: thanks
<Daviey> zul: accepted, but i'd love to see a python3 package...
<zul> Daviey:  so would i
<zul> Daviey:  thanks
<Daviey> zul: is there a py3 issue with it?
<zul> Daviey:  no i was more focused getting it on packaged
<Daviey> zul: It will still need an MIR, right?
<jtaylor> as you may be at new'ing can you have a look at pyparsing3?
<zul> Daviey:  correct
<jtaylor> pytohn3-pyparsing
<Daviey> jtaylor: Hmm, i'm not seeing it in the queue ?
<jtaylor> hm, no idea
<jtaylor> its in debian since more than a month
<Daviey> jtaylor: hmm, it looks like you last touched it in ubuntu raring, and introduced a delta :)
<jtaylor> yes but there is a new source now
<Daviey> jtaylor: So we can just sync this?
<jtaylor> doesn't it count as new?
<Daviey> (sorry, you didn't introduce a delta)
<jtaylor> autosync doesn'T pick it up
<Daviey> jtaylor: Nah, you can just sync ontop
<jtaylor> maybe because of the delta
<Daviey> yep
<Daviey> if there is ubuntu in the version string, it doesn't auto sync
<jtaylor> python-pyparsing and python3-pyparsing are two different source packages
<Daviey> Oh!
<jtaylor> syncing pyparsing and new'ing python3-pyparsing should be done close together to not lose the py3 package for too long
<Daviey> jtaylor: Okay, I've caught up now.. Thanks for outling it. :)
<infinity> jtaylor: If the binary package name is the same, NEWing the new source first is the sane way to go.
<jtaylor> I assumed that, thus I didn't sync yet :)
<infinity> Let me look at that after I've upgraded my kernel and rebooted. :P
<infinity> (I assume the new source is in the queue?)
<Daviey> infinity: I just did it.
<infinity> Oh.
<infinity> Did you new it to a sane component (ie: wherever it was before)?
<Daviey> I did indeed NEW it first, but perhaps i should have left a publisher run between it.
<infinity> Ahh, it's in universe anyway.  So, that's easy.
<Daviey> infinity: i don't believe anything needs python3-parsing yet in main, so universe is fine
<Daviey> ()the previous was also universe
<jtaylor> binary packages can be split between two components?
<infinity> jtaylor: Yep.
<jtaylor> is that new?
<infinity> No.
<jtaylor> oh, right but build depends must all be main for main packages
 * infinity actually accepts that sync. :P
<jtaylor> briefly though I split up fftw3 for nothing :)
<infinity> jtaylor: Right, the source can't be split, so needs to be in the lowest-common-denominator component.
<Daviey> It was planned to make it so some trivial build deps could remain in universe, but I believe that work was put on hold.
<Daviey> Whilst we are on that topic... infinity - Would you be able to work on bug 888665 soon.. we could really do with that...
<ubottu> bug 888665 in Launchpad itself "Backports can't build-depend on other backports" [High,Triaged] https://launchpad.net/bugs/888665
<infinity> Oh, did we finally come up with a critical use-case for that?
<infinity> Is said critical use-case in the archive now?  That'll make it easier to verify a fix.
<Daviey> infinity: Yes juju-core preicse backports
<Daviey> precse*
<Daviey> BAH.
<infinity> I suppose I can't get away with saying that not having those is a feature? :P
<Laney> Pretty sure there's been something in mumble-backports waiting on that for a while
<stgraber> couldn't it be worked around in nonvirt PPA + copy?
<infinity> Laney: Good old something in some series somewhere. :)
<stgraber> I thought we said that'd be the temporary workaround until we get LP fixed
<Daviey> And jamespage also wanted to do some java jenkins stuff
<Laney> infinity: I'm just saying that any new package doesn't make it more critical ;-)
<infinity> stgraber: That's a perfectly reasonable workaround for Canonical folk, yeah.
<Daviey> infinity: If it's not a ball breaker, i'd rather not use any bypasses.
<infinity> Daviey: Am I to assume that backport juju-core and golang to precise is because you intend to actually recommend that combination to your users?
<infinity> And do we then get to get into discussions of supportability, the insanity of static linking, etc? :P
<infinity> (But yeah, I can look at 888665 soon)
<Daviey> infinity: Yeah, Precise is very relevant to users of juju it seems.. and introducing whacking new features as SRU is bad mkay.
<infinity> I think the initial "this isn't quite perfect, but would be an acceptable workaround" solution won't be much hassle to jam in.
<Daviey> Yeah, that avoids blocking.
<Laney> Ah, could be the one in the description that I'm thinking of
<infinity> Daviey: Introducting new features as SRUs is bad, but if we're going to be semi-officially recommending people use those new features in parallel packages in a non-supported pocket, I'm not sure that's "better".
<Laney> which is natty and so definitly super critical :)
<infinity> Daviey: It's an end-run around policy that's in place specifically to protect users from what you're asking them to do. :P
<Daviey> infinity: 'Supported' in this case is very much in the eye of the beholder. :)
<infinity> jtaylor: Alright, new py3parsing source and binaries are in.
<jtaylor> great thx
<infinity> Daviey: I'm not sure I want to know what you mean by that.
<infinity> Daviey: If you mean that Canonical, who has committed to 5yr support in the LTS, is dropping upstream support for one of its own projects, I might have to be a bit miffed by that.
<Daviey> infinity: No, incorrect on 2 counts.
<Daviey> One, juju is not in main for 12.04.
<Daviey> Two, Supporting both is viable, and fixing bugs by SRU criteria for a universe package is also OK
<infinity> Okay, not in main, fair.  Though we push it pretty heavily as a pseudo-supported tech.
<Laney> Sounds like it's more of a new series thing
<Daviey> Which, unless i am mistaken, is what backports is precisely for?
<infinity> I've always felt "it's not good enough for main, but it's good enough for us to widely advertise and encourage use" is a pretty sad cop-out to avoid having to live by the rules of main.
<Daviey> Noted.
<infinity> Daviey: Is there a fundamental reason why juju-core can't be made to work with go 1.0, while we're on the topic?
<infinity> Daviey: backports has a policy of not allowing toolchain backports, but rather making the backported applications be modified to work with older toolchains.
<infinity> Daviey: I realize that go has far fewer users in the archive than GCC, but I'm not sure that should buy it a pass.
<TDO|Aquina> hy
<slangasek> cjwatson: so I've finally gotten the gnu-efi problems from raring vis-a-vis shim sorted out, if only by virtue of pulling a new upstream version of gnu-efi
<slangasek> which means I've also now uploaded shim 0.4
<slangasek> though before I send that off for signing, I think we should probably figure out what we're doing with MokManager and add that to the package
<slangasek> and as the catalyst for this has been an OEM bug, I'm going to have to figure out what to do for 12.04.3... not sure that pulling all of gnu-efi + shim back is a sensible SRU, not sure trying to cherry-pick from shim is sensible either
<slangasek> ah, fortunately shim FTBFS happily for me after upload even though it built fine here, so I guess I don't have to worry about *that* binary getting signed :P
<Daviey> infinity: If anything else depended on this compiler, then there is a risk of an issue.  I am not sure I have ever read this in policy, can you direct me to where that is?
<Daviey> The version of the compiler is too basic in the one in stock precise AIUI.  Doesn't have required features, but I can't speak authoritative about that.
<infinity> Daviey: To be fair, I'm not seeing the "no toolchains" explicitly mentioned in the backport docs, rather than it being, perhaps, one of those "well, duh" things, as it would apply to, say, eglibc and GCC.
<infinity> Daviey: It's true that very few things {build-,}dep on golang, which gives it a free pass in a lot of areas (backportability, static linking, etc), but it would be nice if we behaved AS IF it were widely-used and established sane policies around that.
<Daviey> I don't see how they are the same thing..
<Daviey> I agree, but that is not the situation we are currently in
<infinity> Daviey: You don't see how a compiler and standard library aren't the same as a compiler and standard library?
<Daviey> No, i don't see how a compiler that has a 1:1 mapping with a package, and gcc are in the same category
<infinity> Right, so you're taking the "no one uses Go, so it doesn't count as a toolchain package" argument.  Like I said, I can see that, in the short term.
<infinity> Long-term, it'll establish poor policy.
<infinity> Assuming other people write things in Go some day. :P
<Daviey> Naturally, it becomes more complex with increasing popularity
<Daviey> Go is still a young language, and the compiler has made radical differences since the version in 12.04
<infinity> Sure.  Intentionally targetting something to a newer language version *and* saying "oh, and we want this in precise" should have been a non-starter, but I understand you probably didn't have much say in that.
<Sarvatt> why not name the package different, and SRU it instead if backports is a problem? kind of like mesa lts backports and llvm-3.x updates directly in precise-updates for it
<infinity> Wouldn't be much different to someone writing something with shiny new C11/C++11 features and then demanding gcc-4.8 in precise.
<Daviey> So, we have a choice.. deliver a poor experience, because it looks clean to you.. based on an undocumented made-upon-the-fly policy, or do the best thing for a vobrant project and it's users.  Not to mention people wanting to have a packaged backport of an increasingly popular language
<infinity> Sarvatt: Backports isn't inherently a problem, I can fix the bug, or we can build in a PPA.  It's the principle of backporting toolchains that I'm arguing right now.
<infinity> Sarvatt: And the llvm thing is a horrible compromise for the HWE stack but, yes, versioning the compiler could work in this case.
<infinity> Wait a second.
<infinity> "In order to backport juju-core we'll need go 1.1"
<infinity> ^-- How can that be true, when we don't even have go 1.1 in raring or saucy?
<infinity> (Yes, it's in saucy-proposed, but that means that juju-core demanded that dep only a month ago...)
<infinity> If it needs 1.0.2, we could happily SRU that as a microrelease, if it's not completely insane.
 * slangasek looks at the shim build failure. wtfbbq
<infinity> slangasek: That could do with a bit more verbosity...
<slangasek> it rather could, couldn't it
<slangasek> apparently 'openssl' is needed at build time
<infinity> slangasek: You'll be happy(?) to know that it fails the same locally, at least.
<slangasek> yeah, not sure how openssl got into my scratch chroot
<infinity> slangasek: It used to be accidentally build-essential once upon a time, so you might have picked it up back then and never cleaned up.
<slangasek> ah, could be
<infinity> Someone should publish pitti's recipe for using sbuild backed by launchpad chroot tarballs.
<infinity> Comes pretty close to foolproof for debugging.
<Daviey> I'd like to see openssl in build-essential :)
<slangasek> oh eew, something must've gone really wrong with a snapshot
<slangasek> because cdbs is also in this chroot
<infinity> slangasek: PURGE WITH FIRE.
<infinity> slangasek: YOU CAN'T UNINSTALL EVIL.
<slangasek> infinity: E: Command line option --with-fire is not understood
 * infinity passes slangasek a lighter.
<slangasek> sudo apt-get purge --with-fire cdbs?
<Daviey> infinity: I will circle back to the juju team and find out more detail on why they need a more recent toolchain.  Note, that most of their development is happening in PPA's at the moment rather than saucy (they are working to fix this)... So.. don't work too much on dates.
<jbicha> slangasek: always use -f
<infinity> slangasek: http://www.penny-arcade.com/comic/1999/07/28
<slangasek> heh
<infinity> slangasek: The date on that comic makes me feel old.  That can't possibly have been 14 years ago.
<slangasek> infinity: yeah, that was like, pre-php
<slangasek> hardly seems possible
<Laney> I was 13
<Laney> xnox was probably about to be born
<slangasek> Laney: high-five for making infinity feel old
 * infinity sobs quietly in the corner.
<Laney> :-)
 * czajkowski hands infinity some cake 
<xnox> Laney: that year my 10th birthday party was in McDonalds
<adam_g> mterry, heya, is there anything i need to do to progress https://bugs.launchpad.net/ubuntu/+source/python-tidylib/+bug/1187185 ?
<ubottu> Launchpad bug 1187185 in python-tidylib (Ubuntu) "[MIR] python-tidylib" [Undecided,Fix committed]
<mterry> adam_g, feel free to have cheetah now depend on python-markdown, and an archive admin will promote as needed
<mterry> adam_g, oh wait
<mterry> adam_g, python-markdown itself isn't approved yet
<mterry> adam_g, bug 1187191
<ubottu> bug 1187191 in python-markdown (Ubuntu) "[MIR] python-markdown" [Undecided,New] https://launchpad.net/bugs/1187191
<mterry> adam_g, waiting on a security review
<adam_g> mterry, right. iw as gonna ping someone in security about that one
<adam_g> thanks
<mterry> adam_g, OK.  Once all the MIRs are fix-committed, just have something pull them into main.  Archive admins will see the mismatch (something wants to be in main and will promote if the paperwork checks out)
<tjaalton> is there a straightforward way for apt to use a usb stick as a source?
<tjaalton> bah, I'll just reinstall the machine
<tjaalton> no working networking hw on it which means no (easy) updates
<sarnold> hrm, there used to be a "sneaker net" package for apt..
#ubuntu-devel 2013-07-03
<adie> jamesh :O
<jamesh> hmm?
<adie> I had a question, and I was referred to you to ask about it, you got a minute?
<jamesh> sure
<adie> Okay ^_^
<adie> I am working on a simple script for IRC client hexchat which keeps track of unread message count in the unity launcher count
<adie> simple script: http://pastebin.com/GigD0P4t
<adie> My issue is that it works completely fine the first time, but I am unable to unload and reload the script; a reload causes an error, and just breaks
<adie> I have to restart hexchat commpletely to reload the script
<adie> do you know of anything that I need to/can reset that would allow me to reload the script without killing the hexchat?
<jamesh> what is the error?
<adie> upon unloading and reloading the script, I get this error: http://pastebin.com/raw.php?i=dzSafTK4
<adie> If I were to guess, it would have something to do with hexchat's unnity launcher icon having already been hooked once or something, and it crashes if you try to do it a second time
<adie> not sure though
<jamesh> that is a bit weird.
<adie> Additional, when I unload the script the last unity count number remains on the icon
<jamesh> I don't have much experience with xchat/hexchat's Python support, but when you say you are reloading it, does that mean the entire Python runtime, or just the script
<jamesh> ?
<adie> just the script I think
<jamesh> it seems a bit surprising that those modules would be initialised a second time then
<jamesh> i.e. after the first time you import gi.repository.Unity, future imports should just pick the module object from sys.modules['gi.repository.Unity']
<adie> hm
<adie> brb a second
<jamesh> also, it isn't obvious how your script would know when it is being unloaded, which might indicate why the read count doesn't change then.
<adie> hm.
 * adie huggles
<adie> yeah jamesh, I guess I misunderstood what the issue was
<adie> I thought it was an issue with the unity launcher API, but apparently I cant "from gi.repository import Unity, Gio, GObject, Dbusmenu" twice for whatever reason
<adie> strippingn it down to just importinng those modules prevents it fromm loading a second time
<adie> so I guess I was wastinng your time :< sorry
<jamesh> adie: it certainly sounds like hexchat is doing something weird when you try to reload your script then.
<pitti> infinity: my recipe? I'm using mk-sbuild + apt-cacher-ng + some symlinks to /tmp in /var/lib/schroot (I have /tmp on tmpfs), nothing that fancy
<pitti> infinity: but downloading sbuild schroots does sound like a nice idea
<infinity> pitti: Oh, it wasn't you who was using distro chroots, then.  Hrm.  I wonder who that was.
<sarnold> infinity: security team has distro schroots...
<infinity> sarnold: Backed by the LP tarballs, I mean.
<sarnold> infinity: is that tarballs of the distros pre-installed?
<infinity> sarnold: No, the tarballs used by LP buildds.
<infinity> sarnold: eg: https://api.launchpad.net/1.0/ubuntu/raring/amd64
<TheMuso> c
 * ScottK looks at lamont` and wonders what happened to the weekend.
<rsalveti> stgraber: xnox: ogra_: slangasek: seems there's sort of a regression with the latest upstart
<rsalveti> ofonod was started fine with mako before, and upstart-file-bridge is also running just fine
<rsalveti> after update, ofonod is never started (it works fine with maguro though, might be a race somehow), and upstart-file-bridge starts but dies later on
<rsalveti> from logs: upstart-file-bridge:string.c:396: Assertion failed in nih_str_split: str != NULL
<dholbach> good morning
<xnox> rsalveti: is it reproducible with a grouper device?
<seb128> pitti, hey, could you put https://code.launchpad.net/~peter.ahlgren/ubuntu/raring/obconf/fix-for-1179969/+merge/170065 as work in progress/needs work/rejected?
<xnox> rsalveti: as a work around it should be possible to change upstart job (with an override file) to run upstart-file-bridge in foreground (remove expect stanzas & --daemon)
<pitti> seb128: sounds like "rejected", done
<seb128> pitti, danke
<ogra_> rsalveti, bah
 * Laney just got a crash report for u-f-b in dist-upgrade ;-)
<infinity> Yeah, lots of us did, there are a few dupe bugs for that already.
<Laney> yep, just checked
<Laney> So probably not touch specific.
<infinity> xnox: https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1197214
<ubottu> Launchpad bug 1197214 in upstart (Ubuntu) "upstart-file-bridge crashed with SIGABRT in raise()" [Undecided,Confirmed]
<jodh> infinity: just fixed it
<infinity> jodh: That was quick.  Thanks.
<jodh> infinity: well, it's fixed upstream so next upload will include it.
<seb128> is that worth an upload to backport it?
<xnox> jodh: infinity: i have a workaround. On my system i was running upstart-file-bridge in foreground, switching to daemon triggered the bug.
<infinity> I suspect it's worth someone pushing an upload soon, yeah.
<xnox> seb128: infinity: I'll make one, after checking jodh's fix. I did TIL.
<infinity> xnox: Thanks.
<seb128> xnox, thanks
<jodh> xnox: https://code.launchpad.net/~jamesodhunt/upstart/bug-1197225/+merge/172762
 * xnox runs all of my bridges in foreground
<seb128> xnox, just backport that fix and install the update :p
<xnox> seb128: yeah, merged upstream, tested properly, now running full test-suite.... uploading soon.
<xnox> seb128: infinity: uploaded. Last night the delay between upload and migration to release was... 5 hours. I blame latency in reverse-testing of the $world via autopkgtests.
<seb128> xnox, thanks
<xnox> (as it only takes 30minutes to build upstart on armhf)
<infinity> It's not hugely urgent, just an annoying apport dialog.  But I could force it to skip rdep tests.
<seb128> Laney, stgraber, jodh: do you have an opinion on https://code.launchpad.net/~ted/gnome-session/upstart-unity/+merge/172664 ?
<Laney> not really; does it work?
<seb128> Laney, I didn't try yet, it was on my inbox this morning
<seb128> I didn't follow up the details on what processes are upstart started nowadays
<Laney> and the gnome-session-foo commands continue to work?
<Laney> In principle it seems ok to me
<Laney> I think the user session jobs were otherwise jiggled to make this work
<seb128> let me play with it here, I was mostly listing it for comments or in case you guys knew about any gotcha there
<Laney> unity's one will need patching too but I guess there will eb an MP for that
<Laney> no, lies, it will not
<Laney> grr, not getting applications returned in the home lens
<cjwatson> xnox: No, it wasn't genuine latency, it was false latency due to a known bug with virtual package handling
<cjwatson> xnox: I noticed at some point and forced it
<seb128> Laney, bug mhr3 about it on #ubuntu-unity please
<cjwatson> xnox: The actual autopkgtest only took a few minutes
<cjwatson> xnox: jibel is working on the underlying bug
<seb128> Laney, he will likely want a bustle log
<xnox> cjwatson: interesting. thanks.
<Laney> second
<Laney> oh wow, my PC hard locked
<jibel> xnox, I'm testing a fix that will land today.
<tseliot> pitti: sorry yesterday I forgot to ask you to approve nvidia-settings-319-updates (saucy, NEW, main) which goes together with the package you approved
<jodh> xnox/doko: any thoughts on https://code.launchpad.net/~jamesodhunt/upstart/fix-libupstart/+merge/172371 ? Possibly a gettext issue?
<pitti> tseliot: oh, we need an -updates for the settings as well? looking
<tseliot> yep
<pitti> tseliot: why does nvidia-settings-319 and -updates have a different orig.tar.gz?
<tseliot> pitti: well, it's the same code for now but it will change
<pitti> yes, I mean nvidia-settings-319_319.32.orig.tar.gz and nvidia-settings-319-updates_319.32.orig.tar.gz differ (gz timestamp or so)
<pitti> looks ok otherwise
<ogra_> didrocks, any idea when i can expect a build of https://code.launchpad.net/~phablet-team/phablet-tools/trunk ? seems the merge went in 4h ago
<tseliot> pitti: they are different tarballs yes. I didn't rename one adding -updates to it. I created the tarball again
<didrocks> ogra_: should be in tomorrow's dailies, any urgency?
<pitti> tseliot: hm, nvidia-settings-{304,319} are in main, -310 is in universe; is that really free software?
<ogra_> didrocks, it is the one thing blocking us from switching to flipped by default (which was due on monday)
<pitti> tseliot: I had assumed it was for restricted or multiverse
<didrocks> ogra_: ok, let me rerun a daily with this one then
 * ogra_ hugs didrocks 
<ogra_> thanks !
<tseliot> pitti: -310 should be a transitional package which we still want in restricted
 * didrocks hugs ogra_ back
<cjwatson> jodh: Look into why libintl isn't being built with -fPIC, I guess
<cjwatson> compiled, that is
<pitti> tseliot: oh, seems -settings is indeed GPL?
<tseliot> pitti: yes, settings is GPL
<pitti> none of the .c files have a copyright header, but there's a GPL2 COPYING
<tseliot> I thought you were referring to the drivers
<pitti> tseliot: so -settings should go into main?
<tseliot> pitti: yep
<pitti> tseliot: done
<tseliot> pitti: thanks a lot, now about 310
<tseliot> pitti: is it nvidia-310?
<pitti> tseliot: sorry, what?
<pitti> tseliot: I was exclusively talking about nvidia-settings-* here
<tseliot> pitti: ok, never mind then. Thanks again
<pitti> tseliot: heh, yay confusion :) thanks
<cjwatson> jodh: Can I see configure output for the 64-bit system in question?
<jodh> cjwatson: http://paste.ubuntu.com/5839892/
<marga> Hey all.  I prepared some patches for the heimdal package and got reprimanded for not following SRU directions :-/.  I understand most of the concerns except for one: "please could your review the versioning you are using". Could anybody here tell me what versioning I should use? https://bugs.launchpad.net/ubuntu/+source/heimdal/+bug/1191704
<ubottu> Launchpad bug 1191704 in heimdal (Ubuntu) "KDCs complain about not having enough file handles for /var/lib/heimdal-kdc/heimdal" [Undecided,New]
<xnox> marga: Under https://wiki.ubuntu.com/StableReleaseUpdates#Procedure, point 5.1. links to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging with examples of version numbers.
<xnox> marga: since heimdal is at the same version number in precise/quantal/raring, use the example that encodes ubuntu release version number from a debian version number
<marga> ok, thanks.
<marga> actually precise is different, quantal/raring are exactly the same and saucy has a different debian revision.  Still, I'll read the guidelines and follow them. Sorry for not finding them myself.
<xnox> marga: 1.6~git20120403+dfsg1-2ubuntu0.12.04.1   is probably gonna be the version number for precise SRU.
<xnox> marga: precise is indeed different =) getting cross-eyed looking at those version numbers.
<marga> So, should I leave it as it is for precise?
<xnox> marga: so precise could use "ubuntu0.1" suffix, and quantal/raring need to use ubuntu0.13.04.1 / ubuntu0.13.10.1
<marga> Ok, good.
<marga> I'll do this.  Thanks.
<xnox> np
<ogra_> didrocks, looking at the changelog at https://launchpad.net/ubuntu/saucy/+source/phablet-tools/0.14+13.10.20130703-0ubuntu1 ... does jenkins not use dch to append its  "automatic snapshot" message ? looks a bit messy ..
<ogra_> (not highly important indeed, but it looks a bit mangled)
<didrocks> ogra_: it does
<ogra_> weird
<didrocks> it does that for every content
<didrocks> every commit messages removes lines, one entry per commit
<didrocks> ogra_: I bet sergiusens added in his commit message multiple *
<ogra_> yes, since it were multiple commits merged into one
<didrocks> ogra_: see: http://bazaar.launchpad.net/~phablet-team/phablet-tools/trunk/revision/119
<didrocks> yep
<didrocks> and as the decision was to take only commit messages to trunk, that's what we end up with :)
<ogra_> right ... if i call dch here on such a file it simply appends to it
<didrocks> yep, no magic reformatting
<doko> jodh, why does it try to link with libintl.a, and not libintl.la (or the system one)?   Maybe first check the config.log why the tests have different outcome on i386 and amd64
<jodh> doko: ok
<cjwatson> jodh: That looks like configure was run with --with-included-gettext
<cjwatson> TBH, for projects that use gettext where I'm upstream, I switched to AM_GNU_GETTEXT_EXTERNAL a while back, and people can install gettext if they're really using a system that lacks it
<cjwatson> Way less hassle all round
<jodh> cjwatson: I think it must be distcheck that is adding --with-included-gettext, but seemingly only on 64-bit.
<cjwatson> Might just be something about the set of packages installed.  However, do you ever care about building upstart on a system that lacks gettext?
<cjwatson> I'd argue you don't and that sidestepping the whole issue with AM_GNU_GETTEXT_EXTERNAL is the right thing to do.
<bain> Hi i am trying to compile gtk+3.0 source package on raring
<bain> did build-dep install and apt-get source gtk+3.0
<bain> ./configure and make is resulting in these errors
<bain> undefinged reference to <various ubuntumenuproxy module api's>
<bain> can some one help did i miss  a configure switch? i can see that the code exists in the gtk/ folder... just not getting compiled
<cjwatson> the usual way to call the build system starts with 'debian/rules build', not ./configure and make
<cjwatson> (you may want to remove the source directory and unpack it afresh now, though)
<bain> ah ... ok will try and report ... thanks
<bain> cjwatson, it worked thanks...
<rbasak> When we sync from Debian, do we run dep8 tests? I have a failing dep8 test in puppet AFAICT - which is holding me back from introducing an unrelated delta (another test).
<xnox> rbasak: talk to #ubuntu-release, it can be hinted to ignore dep8 failure.
<xnox> rbasak: and yes, we run all autopkgtest =)
<rbasak> xnox: so we do normally do it?
<xnox> rbasak: no, but we do have facility to ignore autopkgtest failure and migrate packages to -release.
<cjwatson> Running DEP-8 tests is unrelated to where the package came from.
<rbasak> xnox: I wondered because I thought it might help me pin down the cause (ie. my environment vs. something broken elsewhere).
<rbasak> So in general we always run dep8 tests when we sync from Debian, right?
<cjwatson> It doesn't matter where the package came from.
<rbasak> I actually found the cause since I asked that question, but it'd still be useful to understand in the future.
<cjwatson> So "yes".
<cjwatson> However, I don't see puppet on either http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html or https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/ .
<rbasak> Here it was because apache2 is still on 2.2 in Ubuntu, and Debian have changed how it works in 2.4 and puppetmaster-passsenger won't work with the old one. It just so happens that zul did the merge yesterday but it hasn't gone through to saucy yet.
<xnox> rbasak: you can run autopkg test exactly as in the jenkins lab using scripts from lp:auto-package-testing
<cjwatson> Indeed, we're in the middle of the Apache 2.4 transition.  If this is causing trouble, your best bet is really to help move the transition along faster, since it's likely to need a number of hands.
<xnox> rbasak: apache2.4 is stuck in saucy-proposed with the rest of packages that are already using 2.4, until the remaining 2.2 ones are transitioned to 2.4 as well.
<rbasak> Is there a report for outstanding work?
<xnox> rbasak: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=661958
<ubottu> Debian bug 661958 in release.debian.org "transition: apache2 2.4" [Normal,Open]
<xnox> see all the blocked bugs.
<rbasak> xnox: thanks. What do we need in Ubuntu to get apache2 2.4 into saucy? All of those fixed, or a selection?
<cjwatson> Probably all
<cjwatson> Although I expect some will be removed rather than fixed - would prefer that to be as agreed with Debian though
<cjwatson> I plan to be following along with removals
<xnox> rbasak: so for apache2.4 to migrate, we need to well satisfy http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt see the last try to migrate apache2 together with a bunch of fixed packages.
<xnox> rbasak: that gives a concise list of packages that are blocking transition. Those that are in main, are probably betters targets to help write patches for in debian and/or ubuntu.
<rbasak> xnox: thanks
 * rbasak is struggling to understand that
<rbasak> * i386: 389-admin, 389-admin-console, 389-ds...
<xnox> rbasak: yeah britney output is criptic. Given a package, it checks how many package where uninstallable before and after introducing said package. The number should stay the same or go down. If it goes up, they are listed.
<rbasak> Is that the list? Are all the packages in that list blocking migration, so it'll shrink as packages are fixed?
<cjwatson> That means that promoting that set of packages (apache2 etc.) renders those packages uninstallable.
<cjwatson> Fix them and that list will indeed shrink.
<rbasak> Got it. Thanks!
<mterry> How does one download a package from debian NEW?  I can't find the link
<Laney> mterry: you can't, intentionally
<Laney> See if there's a VCS listed
<mterry> Laney, I thought that might be the case.  OK
<mterry> good idea
<rbasak> So the dep8 test for puppetmaster-passenger fails for me because it uses apache 2.2 out of saucy. But if it were to use -proposed, it'd work because it'll pull in apache 2.4, right? And go through to saucy?
<rbasak> (assuming there aren't any other issues)
<cjwatson> rbasak: you can always try it :)  the tests on jenkins.qa.ubuntu.com should use -proposed
<cjwatson> rbasak: indeed e.g. https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-apport/ARCH=amd64,label=adt/lastSuccessfulBuild/artifact/results/log shows it looking at -proposed
<rbasak> Thanks. I'll test against -proposed locally, and if that works then I'll upload. Worst case is that it'll end up stuck in -proposed, and I can guess it's no worse to wait if that happens.
<cjwatson> you're going to be waiting either way, it seems
<sladen> ogra_: Flipped Root Image ...  would be a more FRUITy name
<sladen> ogra_: Flipped Root Ubuntu Image for Touch
<ogra_> sladen, haha
<tedg> cjwatson, click is telling me I don't have ubuntu-sdk-13.10.  I swear I do.  How to I tell it so?  :-)
<cjwatson> tedg: --force-missing-framework
<cjwatson> tedg: I wasn't aware that any package delivered the necessary file in /usr/share/click/frameworks/ yet ...
<tedg> Ah, I thought it was checking the debian package
<tedg> ubuntu-sd
<tedg> ubuntu-sdk
<cjwatson> Nope
<cjwatson> Can't load the system package database
<tedg> Ah, okay.
<cjwatson> Plus I'm not sure there's any guarantee that the current version is actually "13.10" yet
<cjwatson> So for now, --force-missing-framework is rational
<tedg> Yup, that's fine with me.  I just thought it was user error :-)
<tedg> cjwatson, Is there a way to know that camera-app.desktop is the desktop file?
<tedg> cjwatson, I was expecting a manifest that'd either point to it, or a generic name.
<cjwatson> tedg: Not hooked up yet, but I'm expecting the manifest to declare a hook (something like https://click-package.readthedocs.org/en/latest/hooks.html) naming the desktop file
<cjwatson> So you might have "hooks": { "desktop": "camera-app.desktop" }
<cjwatson> tedg: If you want to tell me where the file ought to be linked to, I could start on figuring out whether the current hooks interface can properly express that
<cjwatson> (And whether any further actions need to be taken, or if it's just "make a symlink")
<smartboyhw> Hey guys, where is the source code of the bot that you guys use to sign-in patch pilots?
<tedg> cjwatson, I think we'll want to build a new desktop file.  i.e. replace the Exec line with something like "click-launch" or something so that we can add the apparmor profiles automagically.
<tedg> cjwatson, Where we wouldn't want applications doing that themselves.
<cjwatson> tedg: Ah.  I was hoping we wouldn't have to do that, but oh well
<xnox> smartboyhw: ask on #ubuntu-irc or check IRC topics on wiki.u.c, it's linked there somewhere.
<cjwatson> I've been trying to avoid having to build a templating language into click
<cjwatson> But we could use Exec lines to run sed over things, I suppose
<tedg> cjwatson, I don't think we'd have to do that.  I think we could just read the desktop format and modify it.
<tedg> Exactly.  Sed or a utility, or whatever.
<cjwatson> tedg: I thought the point was to hook this into application.upstart and have that apply the profile
<tedg> cjwatson, Sure that works for the Unity usecase, but I don't think we'll get other DE's doing that.  And it'd be nice if they could use Click as well.
<xnox> tedg: i would have hoped, that xdg-open file://*.desktop works which takes the desktop file, applies any necessory apparmor/upstartfication and launches the desktop file.
<cjwatson> tedg: OK, so if I can get a path-and-file-format-level spec for what I'm supposed to do here, I can have a go at implementing it
<xnox> tedg: and based on the current DE it could do less or more....
<cjwatson> tedg: I'm expecting that the first couple of hooks we write here will need modifications to the core, since it's pretty minimal at the moment
<xnox> tedg: cause inherently, launching a desktop file under upstart/apparmor is independent off using click package or .deb
<cjwatson> One problem is that the path to the executable is not known
<cjwatson> So either we need to substitute the installation path into the Exec field (could be hairy) or we need something that sticks the app's unpack directory on the front of $PATH before executing
<cjwatson> (which then means your executable has to be at the top level of the app)
<tedg> Yeah, that's why I was thinking something like "click-launch com.ubuntu.foo"
<cjwatson> Right, but that just moves the problem around
<cjwatson> It still needs to know what the entry point is
<jdstrand> tedg: couldn't this be a function of the sdk? iirc, it creates a desktop file. why can't it create it to use your launcher?
<cjwatson> jdstrand: That means that an app can be manually created to ignore the launcher, ignore apparmor profiles, etc.
<tedg> cjwatson, Yes, but it means that we do it in a place that is independent of the DE.
<cjwatson> jdstrand: Pretty sure your team would be unhappy about that
<tedg> It's all contained in "click packages"
<tedg> We could figure out the path that is relative to the right directory for the right version, etc.
<cjwatson> tedg: Even so, we'd still need something to hook that into the list of installed applications
<jdstrand> cjwatson: sure, but we could have an automatic check for that
<tedg> Sure, and that would be putting the desktop file in /usr/share/applications.  So that desktop file would be a generated one that would call back into the click system.
<jdstrand> well, manual check first, that is made automatic later
<cjwatson> jdstrand: The server isn't going to have any checks for 13.10
<cjwatson> jdstrand: So anything that can be mandated automatically rather than requiring checks is a very definite win
<jdstrand> cjwatson: I realize that. everything is gated on manual review. there will be tools though for those reviewers, that would grow into automatic checks
<cjwatson> tedg: Can't be /usr/share/applications/ - /usr will be read-only
<cjwatson> jdstrand: Honestly, I would rather have a design that doesn't require checking
<cjwatson> As a strong design principle
<tedg> cjwatson, heh, okay, /opt/com.ubuntu.click/desktop-files :-)
<cjwatson> tedg: Isn't there a ~/.local/share/applications/ or something?
<jdstrand> I appreciate that point, but I thought that click was supposed to be generally reusable in other places
<jdstrand> if it isn't, fine
<tedg> cjwatson, yeah, we could do that as well.
<cjwatson> tedg: We may end up having multiple click paths, so I'd like to avoid the dash/launcher/whatever having to know to look in click-specific paths
<cjwatson> jdstrand: well, it is, but saying "click packages must be launched using 'click launch com.ubuntu.foo'" doesn't seem to impede that
<tedg> cjwatson, Hmm, yeah.  Seems like it shouldn't have to be per-user for some cases though.
<cjwatson> jdstrand: And doing this kind of thing in the SDK means that it's hard to change
<cjwatson> jdstrand: If we need to change some bit of the app/launcher glue (hopefully it would never change, but ...), then we have to rebuild all apps and it all gets very boring
<tedg> cjwatson, I guess we could have the "installer" check to see if it's installed first.  And perhaps some cases the install is just creating that desktop file.
<tedg> cjwatson, What I worry about there though is that the hook effectively needs to run as the user then, not the click installer user.
<cjwatson> I'm still thinking of how per-user apps ought to work
<cjwatson> But I'm beginning to come round to the possibility that maybe most hooks actually want to run as the user
<cjwatson> Because if the system partition is read-only, most system hooks can't do much anyway
<tedg> Hmm, interesting.
<cjwatson> However there's the matter of packages preinstalled on the system partition
<tedg> Seems like those wouldn't be per-user, right?
<cjwatson> One option is to have a "register" kind of step where you register the system-installed packages in a user's list
<cjwatson> In bulk
<jdstrand> cjwatson: er read-only> this is something sbeattie and I have been thinking about with apparmor profiles too. I had figured that they would be tucked in /opt somewhere as writable be the click package user
<jdstrand> I don't have an implementation suggestion, but I'm not keen on loading user owned policy
<cjwatson> OTOH I think I've heard people say that at least some core apps shouldn't be entirely removable (i.e. if you remove them it just means it flips back to the version in the system partition)
<cjwatson> jdstrand: No, I agree on that part
<cjwatson> So maybe we need both user and system hooks
<cjwatson> Having to put things in /opt is annoying though, because /opt's layout is not really typically friendly to being loaded in bulk by the system.  Do we have any subdirectory of /var or something that's guaranteed to be on the user-data partition?
<cjwatson> (And that isn't transient, like something bind-mounted off /run)
<jdstrand> maybe /var/cache? I've not been part of these image layout conversations though
<tedg> I'm not sure, perhaps rsalveti has info there?
<jdstrand> fwiw, I was not suggesting the sdk handle it, I was just tossing the idea out there. the 'click launch' seems fine (feels slightly out of scope though...)
<ogra_> jdstrand, tedg, stgraber  is the person defining the image layout
<mterry> zul, for python-amqp, why run just that one test?
<ogra_> as he implements the image based updates and readonly filesystem stuff now
<zul> mterry:  havent figured out how to run the rest of the tests in a buildd yet
<cjwatson> I can see it as in scope; at least for demonstration purposes.
<mterry> k
<cjwatson> I could implement it without it necessarily having to be the way apps end up being launched.
<cjwatson> That said, "click launch" would run as a user, and the apparmor profile still has to have been generated and stashed somewhere first, so I don't think I can implement it yet.
<jdstrand> cjwatson: sbeattie will be starting on the click hook imminently
<jdstrand> cjwatson: the first cut for the demo may very well be putting it in /etc/apparmor.d, but we recognize that will need to change
<cjwatson> jdstrand: Incidentally, what's the specific reason why user-owned policy is bad?  I get that we don't want an app to be able to modify its own policy, but that's not quite the same as being user-owned
<cjwatson> My understanding of the security policy is that we're principally trying to defend the user against malicious apps
<jdstrand> cjwatson: you're right that they are different. loading policy is a privileged operation currently. one example of why it would be bad is that an unprivileged non-admin user would be able to modify one of these files and override system policy
<jdstrand> or write new system policy
<jdstrand> it is thorny. we don't have user profiles yet. we just can't allow it now
<cjwatson> If you can override system policy, I can understand the restriction
<jdstrand> user profiles are planned, but it is not for 14.04
<cjwatson> I just wanted to check that it wasn't actually a fig leaf - for example if you were trying to prevent the app from overwriting its own policy in the case of a policy leak, which could equally well be used to write a new desktop file for itself :)
<cjwatson> sbeattie: For the record, don't worry too much about polishing the edge of your code that interfaces with click
<jdstrand> it doesn't have to do with the app
<cjwatson> jdstrand: OK, good, I understand correctly then
<cjwatson> sbeattie: I more or less expect to have to munge the interface about a bit, and I'm happy to take a lump of code that does the policy-specific work and then deal with the integration
<cjwatson> (In fact it's arguably easier for me to deal with it that way, just at the moment)
<jdstrand> cjwatson: the desktop file is an interesting consideration though. where do we expect them to live? currently, we figure things in /opt will not be writable by the user (DAC would protect against that too, but this is another layer), and then app data is in XDG dirs.
<jdstrand> but we don't want the .desktop file to be modifiable
<cjwatson> jdstrand: This is one reason I'm hoping not to have to run any processing over them, because then the desktop file can just live in /opt
<jdstrand> (by the app-- the user could if desired)
<jdstrand>  /opt is great by me :)
<cjwatson> jdstrand: But, a desktop file in .local/share/applications/ wouldn't be modifiable by the app either, surely
<cjwatson> (Or whatever)
<jdstrand> .local/share/applications will not be allowed, and would be acceptable too
<jdstrand> so long as it isn't in .local/share/<app id> :)
<cjwatson> I am on board with the general principle that an app should not be able to modify itself.  We may have to argue about the details :)
 * jdstrand nods
<cjwatson> Oh, indeed, no, that wouldn't buy us anything even if I thought it were a good idea
<jdstrand> though I think we are in agreement :)
<cjwatson> I want to avoid anything where elements of the system have to iterate over lots of app directories, as much as possible
<cjwatson> That kind of code tends to be really tedious and doesn't usually fit well with existing facilities
<jdstrand> I don't particularly care on the implementation detail as long as it is cleanly separated from the app's writable area
<jdstrand> cjwatson: yep, cool
<cjwatson> I prefer models where bits of the app get linked or copied into single system- or user-owned directories
<cjwatson> Ideally linked
<jdstrand> cjwatson: I might mention, and I don't think this conflicts with anything we've said, we are trying to make it so apps can't enumerate what other apps are installed
<jdstrand> cjwatson: an app shouldn't need read access for /usr/share/applications, /opt/.../wherever or .local/share/applications anyway, but thought I'd mention the principle
<cjwatson> I guess then you need them not to be able to list either /opt/click.ubuntu.com or whichever directory we put the per-user links in, and you need them not to be able to execute /usr/bin/click
<cjwatson> Or talk to the relevant PackageKit API
<jdstrand> that's correct
<jdstrand> that is all handled by default
<cjwatson> Assuming that you're doing positive permissions rather than negative permissions, and I assume that because I believe you're generally sane :-), that shouldn't be a problem
<jdstrand> that's accurate
<jdstrand> well, sane is probably for discussion, but...
<cjwatson> Just remember that the ability to list any directory that's used as the target of a hook might permit implicitly enumerating at least a subset of apps
<jdstrand> I'm not up on "any directory that's used as the target of a hook"
<jdstrand> our current templates will do things like /opt/click.ubuntu.com/@{APPNAME}/@{APPVERSION}/
<jdstrand> where @{APPNAME} and @{APPVERSION} are declared in the manifest
<jdstrand> I also understand that the exact path may change, based on earlier discussions
<mdeslaur> we can't use .local/share/applications...it needs to be outside the home directory
<jdstrand> mdeslaur: why, I feel like I missed something?
<mdeslaur> since the home directory can be encrypted, click packages needs to be able to clean out unused versions of packages
<mdeslaur> to do that, it needs to be able to enumerate what each user has
<jdstrand> (ok, not the app confinement concern :)
<jdstrand> s/the/a/
<mdeslaur> no, not an app confinement concern
<mdeslaur> also, the launcher list is outside the home directory, and it presumably needs to fetch icons and stuff from the desktop files
<mdeslaur> because the lock screen launcher needs to work
<cjwatson> target of a hook> What I mean is that if there's a system-provided hook that says "apps which provide the 'foo' facility get a named file symlinked into this directory", then enumerating that directory gives you a partial list of installed apps
<jdstrand> mdeslaur: so, this is probably just chalked up to 'that will be handled via a system security update', but I hadn't really considered crafted/malicious icons
<cjwatson> mdeslaur: .local/share/applications/ won't be the registry of what each user has
<jdstrand> that could trigger stuff outside of confinement
<mdeslaur> jdstrand: meh, no different than anything else the app could provice
<mdeslaur> provide
<mdeslaur> cjwatson: oh, sorry, I misunderstood then
<cjwatson> mdeslaur: It seems unfortunate that encrypting one's home directory wouldn't imply encrypting the list of which apps one has installed
<cjwatson> mdeslaur: Existence proof: "pornview"
<mdeslaur> cjwatson: quite...but I'm not the one who decided to put your list of installed apps on the lock screen :P
<jdstrand> mdeslaur: well, yes and know. taking the kernel out of it, the app is providing an image that is displayed outside of confinement by unity. most of what an app can do is within confinement
<jdstrand> s/know/no/
<jdstrand> (weird typo)
<cjwatson> mdeslaur: Although I suppose the actual app is in /opt/ anyway
<cjwatson> mdeslaur: So I guess it should be somewhere outside /home, but in user-owned mode 700 directories, to at least discourage casual snooping
<cjwatson> mdeslaur: Then click running as root can still prune things
<mdeslaur> cjwatson: yes...I believe the plan at some point was to use accountsservice to store that
<cjwatson> mdeslaur: Huh, nobody told me.  Reference?
<mdeslaur> tedg: ?
<mdeslaur> ^
<cjwatson> I'd been planning something really high-tech like, you know, a directory
<mdeslaur> cjwatson: I blame either a rumour from ted, or my faulty memory :P
<cjwatson> And actually it would be a right pain to have to go and talk to some other service for click's registry of installed apps
<mdeslaur> cjwatson: oh, I was referring to the launcher items, not the list of installed apps
<cjwatson> Oh, right.  This is why I keep trying to get a spec out of Ted ;-)
<ogra_> squeeze harder :)
<mdeslaur> hehe
<cjwatson> mdeslaur: (Your ideal lock screen makes the device invisible, right?)
<mdeslaur> cjwatson: hehe, well, I think the launcher on the lock screen is cool....as long as the paranoid/enterprise users can enable a "safe" lock screen in the settings somewhere
<mdeslaur> I don't include myself in the list of paranoid people :P
<slangasek> cjwatson: so I can't think of any reason not to put MokManager in the existing shim binary package; can you?
<sergiusens> cjwatson: from the above conversation, the how to launch a click installed app from a DE is not solved, right? Do you know who owns that if so?
<cjwatson> slangasek: seems fair to me; I guess it needs a separately-signed EFI binary
<slangasek> yep
<slangasek> should the signed binary go to shim-signed?
<slangasek> implies we need to consistently get both binaries signed in a timely manner, I guess
<cjwatson> sergiusens: I think I own it, although it may involve me continuing to have lively debate with Ted ;-)
<cjwatson> sergiusens: It's a demo blocker so a high priority for me
<cjwatson> slangasek: Is there a reason we might want to handle them on different schedules, such as one changing much more frequently than the other?
<slangasek> cjwatson: given that they come from the same source, and updating the source will render any -signed package non-rebuildable until a new signed binary is available, I don't think so
<slangasek> I'm only (mildly) concerned about the prospect of one binary getting stuck in the SysDev submission queue
<cjwatson> Oh, because we take care that we're shipping signatures for current binaries
<slangasek> oh, but now I'm confused
<slangasek> the MokManager.efi in http://www.codon.org.uk/~mjg59/shim-signed/shim-signed-0.2.tgz isn't signed by Microsoft
 * slangasek rewinds and looks to see how this is actually being validated
<stgraber> slangasek: any reason we can't have MokManager.efi signed by the Ubuntu key and started by shim/grub instead?
<slangasek> stgraber: well, it looks like that might actually be how it's meant to work
<cjwatson> http://www.techrepublic.com/blog/australia/shim-delivered-to-allow-small-linux-distros-to-boot/1579 seems to imply that there's a separate ephemeral private key
<slangasek> yes
<slangasek> I know that there /is/ such an ephemeral private key, I just forgot how it was being used
<slangasek> so I guess the only thing is to make sure MokManager.efi ends up in the right place on the disk
<cjwatson> So have shim spit out a raw-uefi object in its build and suck the signed object into shim-signed, I guess
<stgraber> ah, ephemeral private key used to sign MokManager.efi with the public half in the valid key list in shim would do the trick too, then we don't need to do anything with the resulting .efi
<sergiusens> cjwatson: well if you own it I'm confident I can track the blueprint for click... not worried on who actually ends up doing the grunt work, just where I'm supposed to be looking at
<slangasek> stgraber: right, that seems to be how it's already wired up
<cjwatson> Unless it must be a separate key rather than the Ubuntu one
<slangasek> cjwatson: it doesn't /have/ to be a separate key, but the shim build already spits it out signed by the ephemeral key, so maybe that's simpler than resigning with the Ubuntu key?
<cjwatson> slangasek: Oh, right, even easier than
<cjwatson> *then
<cjwatson> sergiusens: I plan to get it done this coming week, one way or another
 * tedg is back
<tedg> cjwatson, mdeslaur, yeah the apps on the launcher would be in account service.
<tedg> But I'm not sure that means you need the desktop files if they were created in the user's home directory.
<tedg> For instance, we could pull the data out of /opt
<Kaleo> Trevinho: any news on https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1180402 ?
<ubottu> Launchpad bug 1180402 in Ubuntu UI Toolkit "qmlscene based apps are not recognised as separate apps by Unity (launcher and alt-tab)" [High,Confirmed]
<apachelogger> are there any plans to push alsa* 1.0.27 into saucy?
<jdstrand> sbeattie: what are your thoughts on moving /etc/apparmor.d/abstractions/ubuntu-sdk-base out of apparmor and into apparor-easyprof-ubuntu?
<jdstrand> sbeattie: (I would do it, just wondering what you think)
<jdstrand> sbeattie: another thought is to remove /etc/apparmor.d/abstractions/ubuntu-sdk-base and support abstractions in easyprof
<sbeattie> jdstrand: what do you mean by support abstractions in easyprof?
<jdstrand> sbeattie: I think in the short term moving the abstraction out to apparmor-easyprof-ubuntu makes some sense. I think easyprof support for abstractions needs thought
<sbeattie> I'm okay with moving it.
<jdstrand> sbeattie: something like /usr/share/apparmor/easyprof/abstractions(|vendor/version)
<jdstrand> sbeattie: the other option is to just treat policygroups like abstractions
<jdstrand> sbeattie: I'm just thinking that the ubuntu-sdk-base abstraction will likely needed frequent updates
<sbeattie> ah, that was the question I was just forming, was how you see them as different...
<jdstrand> maybe it is easier to shove them all into a policygroup and be done with it
<jdstrand> we'll get versioning for free then
<sbeattie> hrm, so that's a lifecycle question. as we iterate on policygroups and other easyprof bits, the generated policies will need to be updated.
<sbeattie> not just when the click package is initially installed
<jdstrand> sbeattie: yes, but that is different from what I am asking
<jdstrand> I added a work item to figure that out
<jdstrand> oh, I see what you mean
<jdstrand> if it is in an abstraction, we get reload for free
<sbeattie> well, almost for free, but yes.
<jdstrand> hmm
<sbeattie> (modulo when policy is reloaded versus the easyprof package upgrade)
<jdstrand> so, I figured we would have some sort of a hook that when apparmor-easyprof-ubuntu is updated, it would regenerate the policy
<jdstrand> (so we would have similar behavior as with apparmor upgrades)
<jdstrand> that is actually somewhat complicated
<jdstrand> cause of the readonly image
<sbeattie> yeah. hrm.
<jdstrand> well, I knew that was a complicated question, which is why I added a work item
<jdstrand> let's punt for now
<jdstrand> we can assume we have to be able to regenerate policy
<jdstrand> for when we update policy groups, etc
<jdstrand> so, pretend we are in a magical land where we have that
<sbeattie> alright. anyway, I have no issue with moving the abstraction to the ubuntu-easyprof package in the short term.
<jdstrand> sbeattie: right, but considering the magical land, does it make sense to just put it in a policygroup and remove the ubuntu-sdk-base abstraction?
<jdstrand> I think it does
<sbeattie> does easyprof support having a template incorporate a policygroup automatically?
<sbeattie> (I don't think so, but I'm not that versed in the details)
<sbeattie> It would be nice to have all the ubuntu-sdk templates (assuming qml, html5, etc get different templates) get a common base level of ubuntu-sdk policy without having to repeat themselves.
<jdstrand> sbeattie: not in the way you are thinking. but there are two ways of dealing with that: use a non-magicpath #include and just having the sdk pre-fill in templates
<jdstrand> sbeattie: s/templates/policygroups/
<jdstrand> ie, user doesn't pick those
<sbeattie> yeah, fair point.
<jdstrand> sbeattie: so, right now, I was thinking put all of ubuntu-sdk-base into qmlscene
<jdstrand> but I could also just add a sdk-base policy group
<jdstrand> sbeattie: this all came about because I was thinking about how fast I am updating this policy
<jdstrand> sbeattie: then it occurred to me, we will have versioned policy for templates and policygroups, but it will depend on non-versioned abstractions
<jdstrand> and that seemed like it would get messy quickly
<jdstrand> I'm not super-keen on an absolute path for an #include
<jdstrand> cause while unlikely to be a maintenance problem, it seems possible
<sbeattie> yeah. I think when I drew up the sdk-base abstraction, I was trying to leave open the possibility that we moved to a different interpreter than qmlscene, but I probably wasn't very fastidious about that.
<jdstrand> sbeattie: but as it is witht he email I sent to the SDK team/ubuntu-devel@, I recommended the sdk just add qmlscene to the manifest file automatically
<sbeattie> and I think the stuff I had pulled out was common to qmlscene and the other interpreter I was playing with.
<jdstrand> sbeattie: well, I think your instinct was correct-- it is how we profile after all and I certainly didn't think anything of it until recently
<jdstrand> I see
<jdstrand> well, so we can have an sdk-base policy group, and the SDK can add both sdk-base and qmlscene
<sbeattie> that works for me.
<jdstrand> I figure the SDK will do that sort of thing a lot once it gets smart
<jdstrand> it will pick qmlscene-sqlite automatically for regular QML apps and qmlscene-webview for html5
<jdstrand> ok, I'll do that then
<jdstrand> sbeattie: (add sdk-base as a policy group)
<sbeattie> jdstrand: excellent, thanks!
<jdstrand> I'll update the man pages/docs/etc too
#ubuntu-devel 2013-07-04
<pitti> Good morning
<dholbach> good morning
<xnox> cyphermox: I got a conf prompt from network manager upgrade..... not sure what to answer =)
<xnox> cyphermox: also, i'm not sure all ubuntu desktop users know what to answer.
<Laney> I doubt he'll be online for a few hours
<xnox> Laney: ok, filing a bug report with a..... screenshot! =)
<Laney> attach the relevant files
<Laney> blah.dpkg-whateveritis
<xnox> Laney: have you seen the new conf prompts? https://launchpadlibrarian.net/144145563/Screenshot%20from%202013-07-04%2010%3A26%3A58.png
<Laney> pfft, GUIs :P
<Laney> is that no-auto-default something you added though?
<Laney> I got no prompt
<infinity> xnox: Are you sure you didn't change that locally?
<xnox> Laney: after mpt, fixed the update-manager it's actually pleasant to use even for heavy traffic updates in saucy.
<infinity> xnox: I don't have the offending line, and I suspect there's no maintainer script that's jamming your MAC in there.
<xnox> infinity: editing network manager by hand no..... unless it's me poking in the network-indicator that results in that.
<mpt> xnox, that prompt design isn't changed afaik
<infinity> xnox: Maybe you added that at some point and forgot? :P
<Laney> I bet you added that at some point way back
 * xnox blames removing etckeeper from my machine.
<xnox> i wish I had that now =)
<mpt> xnox, if it had been changed it probably wouldn't have the lame title "update-manager"
<ogra_> well, the MAC address in there is surely not default
<infinity> ogra_: No, obviously not.  But he thinks a tool may have added it, I'm guessing he did it himself on the advice of someone telling him how to disable management of an interface and then forgot. ;)
<ogra_> yeah
<infinity> (I tend to configure an interface as 'manual' in interfaces(5) when I want NM to leave it alone, personally)
<ogra_> yeah, same here
<xnox> infinity: well manpages, describes that option as "NetworkManager shouldn't create default wired connections.." "When  the  default wired connection is deleted or saved to a new persistent connection by a plugin, the MAC address of the  wired device  is  automatically added to this list to prevent creating the default connection  for  that  device  again."
<ogra_> i even used that as a workaround for 3G data on the touch images (until NM is fixed to ignore the devices itself)
<xnox> Laney: infinity: are you using wired ethernet with VPN, with auto-connect and allow all users to use?
<infinity> xnox: The wording of that sure is suspicious.  If it really is mangling that file at runtime, either it needs to stop, or it needs to not be a conffile.
<xnox> "If you don't know why the file is there already, it is usually safe to replace it." Let's do what it says, right mpt?!
<ogra_> did you try something like
<ogra_> grep auto-default /var/lib/dpkg/info/*.postinst
<mpt> xnox, if it's usually safe to replace it, why is the default "Keep"?
<infinity> ogra_: Based on his manpage snippet, it sounds like NM *might* be mangling that at runtime, not in maintainer scripts.
<ogra_> oh, urgh
<infinity> xnox: It's safe to replace it if you have no idea what you're doing (cause you probably changed it by accident, or based on being a HOWTO-following zombie), for everyone else, keep is the safe default, cause we effin' edited it on purpose. :P
<infinity> mpt: ^ misfire.
<xnox> mpt: because otherwise, things get broken and I would be using a fine Merkel term to describe the situation: http://www.bbc.co.uk/news/world-europe-23142660
<mpt> xnox, keeping it by accident is as likely to be bad though, right?
<mpt> So if you're concerned about accidents, *neither* action should be default
<xnox> mpt: 3-way merge should be the default. Cause ofono got added, and other options should be preserved and they are non-conflicting.
<xnox> mpt: but it's hard to do such a thing generically....
<infinity> mpt: keeping by accident usually just means missing out on a maintainer's new features/defaults.  Except in the case of complete conffile overhauls from a very different new upstream version.
<infinity> mpt: And people not getting ofono (in this case) would hardly be desribed as "broken".
<infinity> *however*, if NM is editing a conffile *at runtime*, that's a bug.
<infinity> And the wording or default buttons on the dialog don't come into play here.  The bug should be fixed.
<infinity> The goal is to make sure that dialog only ever appears if a user actually edited the file, at which point defaults are slightly less important, cause you should know you edited it.
<infinity> In theory.
<infinity> If you're not a forum reader.
<mpt> xnox, most of the time when I've seen I've this prompt, it's because the maintainer has decided to reorder something. A three-way merge in that case would probably work but produce repetition.
<infinity> xnox: Saner merging of conffiles has been on the dpkg maintainer's TODO list for, like, a decade.  I wouldn't hold my breath on it happening without some force of will imposed.
<ogra_> mpt, just a maintainer reordering wont cause the prompt ... it is only triggered if the file was touched by you or a script
<Laney> or by bugs
<Laney> maybe that's covered by the latter though :P
<ogra_> nah, there are no bugs
<ogra_> :P
<mpt> ogra_, yes, so the diff shows both the part you changed and the maintainer's reordering
<ogra_> right
<infinity> Yeah, that sort of thing kinda demands a by-hand merge.
<mpt> Proximate cause and underlying cause. :-)
<infinity> But elimination of run-time editing of conffile bugs solves most of the problem, and the second thing is making sure most "normal" users should never need to edit a conffile.
<mpt> xnox, I reported bug 1197727 based on your screenshot.
<ubottu> bug 1197727 in aptdaemon (Ubuntu) ""Replace your changes in ... configuration file" prompt is unattractive" [Undecided,New] https://launchpad.net/bugs/1197727
<infinity> Then it's only the "power users" and server admins and such who edit conffiles, and if we can't do simple text merges, we suck at computers and should switch hobbies.
<infinity> ie: I think people screaming for better dpkg conffile handling and merging are solving the wrong problem.  Yes, it would be nice to present me with a prettier merge, but I'm not the user who needs that.
<xnox> infinity: i don't count myself a "power user" when it comes to default desktop configs. I couldn't care less what network manager is doing. I want to be a "normal user" for once =)
<infinity> xnox: Right, and if "normal use" is mangling that file behind your back, that'sa bug, please hunt, report, and optionally fix.
<ogra_> infinity, well, ideally the prompt would just prompt and only show the diff on demand though (have a button "show diff" would already improve it imho)
<infinity> xnox: And if you edited it yourself and forgot, it's a slightly more minor but still irritating bug that a "normal user" might need to edit that file to achieve what you did.
<ogra_> *having
<xnox> infinity: i replaced, and will check if i still have internets after reboot.
<infinity> ogra_: Well, that's what the text prompt does, though I'm not sure I agree.  I think once you're in a situation where there *is* a diff to ask about, hiding it behind a friendly "would you like to replace/keep this without knowing why" isn't actually helpful.
<mpt> agreed
<ogra_> thats what you have the "details" expander for :)
<mpt> There's little point having an expander if you nearly always need to expand it to have a hope of knowing what it's about.
<ogra_> i think you can beautify it without stealing functionality
<mpt> iTunes does it beautifully.
 * ogra_ never tried to upgrade iTunes on ubuntu :P
<xnox> mpt: i think it was expanded by default, i had to resize the window to fit the whole diff though.
<mpt> Not necessarily *efficiently*, but beautifully
<mpt> Example: http://www.flickr.com/photos/factoryjoe/1973866433/
<mpt> (a change in contact photo)
<xnox> mpt: it's much better than before.... these prompts used to not get throught to GUI at all, and instead be "displayed" in the terminal of the update-manager, hidden in details expander.....
<xnox> so, I'm not complaining per se =)
<mpt> http://jameslow.com/wordpress/wp-content/uploads/2009/11/syncconflict.png (a change in text)
<xnox> mpt: I'm still confused how the same guy, from same company can have two different faces..... identity theft? =)
<xnox> mpt: is it just me or they are the same?
<mpt> xnox, it's like that scene in "Man of Steel" where Superman leaves the buried ship. He is suddenly and mysteriously shaved.
<mpt> But otherwise the same guy.
<xnox> mpt: was buried ship sponsored by Gillette?
<mpt> xnox, I think in the notes example you'd need to scroll down to see the difference.
<ogra_> dude ! he is superman .... doesnt need to shave ...
<xnox> it must be fun going to movies with mpt - "look shaved again!"
 * infinity should get some sleep.
<xnox> infinity: or you can quickly tell me why my stage2 cross-compiler does not want to find target libc/cr from where it should =) somehow it searches ${gcc-stage-two-build-tree}/./gcc/ instead of like {path-to-stage-1-install}/bin/../lib/${target-triplet}/
<doko> jodh, did you make progress with that upstart pic issue?
<xnox> doko: kind of, opted to use external gettext instead of having included copy of code and thus "solving" the issue, by avoiding it.
<jodh> doko: right. does look like some sort of gettext bug though.
<xnox> doko: is there a way to pass alternative runtime library directory to second stage xgcc? something like LDFLAGS_FOR_TARGET but only during build...?!
<doko> jodh, xnox: ok, but the proper fix would be to build that with -fPIC, if you want to link it against the shared lib
<jodh> doko: the point is that the behaviour of the autools was different between 32-bit and 64-bit systems and we don't know why.
<xnox> doko: yeah, and I'd also expect gettext to do so by it self.... e.g. we get gettext from autoreconf -f -i without touching it.
<doko> xnox, not aware of that. why would you need that?
<xnox> doko: good point. I think I got prefix wrong. And i'm building without sys-root.
<doko> ahh, there is --wist-sysroot and --with-build-sysroot for that
<xnox> doko: that sounds like what I want. thanks.
<doko> xnox, there are patches needed if you want to set it to /
<xnox> doko: it builds and it boots =)
<xnox> \o/
<doko> ?
<xnox> doko: cross-toolchain built, using pure linaro sources, installled, then do full ubuntu touch build for grouper, flash to device and boot.
<doko> ahh, nice
<doko> so now trying to update binutils?
<xnox> doko: will clean up and push to ppa today. And will poke ogra_ to test builds of other devices & flipped.
<ogra_> whee !
<xnox> doko: after i make a "release" into ppa, i can work on using our binutils/gcc, yeah.
<xnox> ogra_: what's the best way? just me building locally for: mako,maguro,manta,grouper and tossing all .zip & .images onto people.canonical.com for folks to test?
<xnox> ogra_: do you have all 4? i only have grouper for testing.
<ogra_> that would eb a good start
<wookey> xnox: which arch? And which sources?
<ogra_> next you should talk to sergiusens
<ogra_> to get it into the build process
<jibel> hallyn, WRT. bug 1196518, I can reproduce it but only then 1rst time I start the container when /sys/fs/cgroup/devices/lxc/<NAME>/ doesn't already exist
<ogra_> wookey, bionic :)
<ubottu> bug 1196518 in lxc (Ubuntu) "lxc-start failed with lxc_cgroup - Invalid argument - write /sys/fs/cgroup/devices/lxc/<NAME>/devices.deny : Invalid argument with kernel 3.10" [High,Incomplete] https://launchpad.net/bugs/1196518
<jibel> hallyn, any idea how I can debug it further?
<wookey> ah :-(
<xnox> wookey: linaro-gcc and linaro-binutils based cross toolchain to androideabi. nothing interesting, armel v5......
<xnox> wookey: yeah, with bionic.
<wookey> I have a need to either munge linaro binary releases into a fake deb or rebuild to get a 'latest'
<wookey> not sure which will be least painful...
<xnox> wookey: unpack binary tarball. add a fake DEBIAN/ directory with control file. and then call: dpkg-deb -b . to create binary .deb.
<wookey> I cam ehere to ask who do I hassle about nobbling a problem with linaro-maintainers PPA uploads
<wookey> xnox: yes, and add some links to make it look about right
<xnox> wookey: you could make it a debian source package, which simply copies the binaries around. But that is against Launchpad PPA terms and conditions ;-)
<wookey> This .deb will only be used for CI, not for launchpad PPAs
<xnox> wookey: than either method is fine.
<xnox> wookey: can't checkinstall help here at all? Add a makefile that installs everyting into /usr and call checkinstall on it to generate a deb?
<wookey> My PPA issue is that http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu does not have sbuild_0.64.0.orig.tar.gz in it, but uploads there get 'Rejected': File sbuild_0.64.0.orig.tar.gz already exists in Linaro Tools PPA, but uploaded version has different contents.
<wookey> I don't know who to hassle to help work out what's wrong.
<xnox> wookey: download sbuild_0.64.0.orig.tar.gz from the ppa, take your package and rebuild source package against that tarball.
<xnox> wookey: reupload.
<doko> wookey, most likely it was there before, and removed
<wookey> a) it's not in the PPA - it's lying about that and b) such a build will _always_ fail as the configure gets added in a patch and so is not executable
<wookey> It has indeed been wrongly uploaded and removed
<wookey> but apparently the correct one can;t be re-uploaded even after removal
<wookey> (the original tarball had configure missing due to git-buildpackage not doing the right thing)
<wookey> and that can't be fixed in a diff
<xnox> ogra_: launched to build all 4 products. Off to lunch =)
 * ogra_ crosses fingers
<wookey> So, who knows about launchpad enough to get it to forget about the wrong one so a re-upload will be allowed?
<xnox> wookey: deleting it from ppa would be a good start
<xnox> wookey: https://launchpad.net/~linaro-maintainers/+archive/tools/+packages?field.name_filter=sbuild&field.status_filter=&field.series_filter=
<xnox> wookey: there should be delete button near "copy packages" link
<wookey> xnox: aha. How come it appears there but is not present in http://ppa.launchpad.net/linaro-maintainers/tools/ubuntu/pool/main/s/sbuild/ ?
<wookey> and if I use that 'delete packages' link it only shows sbuild - 0.63.1-1ubuntu2 , not sbuild - 0.64.0
<geser> not sure it's possible to let LP forget about the checksums for the latest uploaded versions (without using SQL)
<geser> can't you upload it as 0.64.0+repack1 or something?
<wookey> How do I tell dpkg-buildpackage to look for sbuild_0.64.0+repack1.orig.tar.gz? instead of sbuild_0.64.0.orig.tar.gz? I didn't think that the base tarball name could be changed?
<geser> you would have to change the version also in the changelog
<wookey> Ah I see. got it.
<mdeslaur> siretart: are you planning a libav 0.8.7 merge to saucy soon?
<siretart> mdeslaur: actually, I am hoping that we can go with libav 9 for saucy
<mdeslaur> siretart: ok, I'll push 0.8.7 out to the stable releases then
<siretart> mdeslaur: if we get a decision to not go for libav 9, then I would of course merge 0.8.7. however, I'd rather work on a 0.8.8 release upstream before that (which is scheduled for this weekend)
<mdeslaur> oh! I'll wait for it :)
<siretart> mdeslaur: yes, that makes very much sense to me :-)
<mdeslaur> siretart: thanks!
<siretart> mdeslaur: I am announcing new release intends to libav-devel. maybe it makes sense to copy these 'intentional' scheduling mails somewhere where you read it? what would be a good destination for that?
<mdeslaur> siretart: hrm, I was going to just subscribe, but it seems to be a high-traffic list
<mdeslaur> siretart: perhaps just cc security@ubuntu.com?
<siretart> mdeslaur: okay, I'll try to not forget that on the next releases :-)
<siretart> yes, libav-devel is quite high traffic
<mdeslaur> siretart: thanks
<cyphermox> xnox: I'm aware of the issue. you'll likely want to answer Y, to overwrite the file, but I'll be fixing this stuff permanently soonish
<ogra_> cyphermox, any idea wheer that MAC entry comes from though ?
<cyphermox> xnox: ultimately the actual answer is not a big deal, the addition was to add a plugin for ofono
<ogra_> (just out of curiosity)
<cyphermox> ogra_: yeah, if you changed your automatic ethernet connection, it writes it there to remember not to create a new automatic dhcp connection for the device
<cyphermox> ogra_: and *that* is the source of all the issues
<ogra_> yeah
<cyphermox> ogra_: and is what I'll move to somewhere else that users don't see/touch
<ogra_> thanks :)
<ev> ogra_, rsalveti: with the flipped chroot and the latest kernel (3.1.10-6-grouper), it looks like we're back at not being able to get core dumps at all.
<ogra_> ev, hmm, there were some config changes recently, you might need to talk to the kernel team to get it back i guess
<xnox> cyphermox: ok, sigh. You can close or mark as dupe my bug report then. bug #1197712
<ubottu> bug 1197712 in network-manager (Ubuntu) "0.9.8.0-0ubuntu13 is causing conf prompt" [Undecided,New] https://launchpad.net/bugs/1197712
<ev> ogra_: *nods*
<cyphermox> xnox: probably not a dupe
<ogra_> apw, ^^^ any idea if any debugging options were dropped from grouper ?
<ev> thanks
<ev> ah, it's disabled
<ev> debian.grouper/config/config.common.ubuntu:# CONFIG_ELF_CORE is not set
<ogra_> ah, yeah, that would be it ... apw  or rtg sould be able to help then
<ogra_> ev, so do i sense a whoopsie seeding in ubuntu-tuch soon ? :)
<ev> ogra_: as soon as we can get the kernel shovelling through the core pipe, yes :)
 * ogra_ is really eager to finally have ubuntu touch options at errors.u.c 
<ogra_> due to the fact that we still have PPA packages we are still not filing bugs in the normal tracker ... :(
<ogra_> that really needs to change
<ev> ogra_: that only prevents it from going to Launchpad
<ev> they should still send to daisy.u.c without issue
<ogra_> ah, cool
<jdstrand> zul: hey, I guess you are aware of apache2 breaking stuff: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html?
<zul> jdstrand:  yep
<jdstrand> zul: I'm handling apparmor atm
<jdstrand> zul: what is the plan for the rest?
<zul> jdstrand:  cool ill look at it this afternoon
<jdstrand> ok. there is a lot that is preventing migration afaics
<xnox> jdstrand: i wonder if it makes sense to send an email out to ubuntu-devel@ "apache2.4 transition is in progress please help out, here is how, or be patient with things not migrating"
 * xnox goes to draft something.
<jbicha> xnox: if it's just switching dependencies and checking if the package builds that's easy, but if we need to test whether obscure apache modules still work...
<xnox> jbicha: it needs switch to dh-apache helper, changes to packaging policy, change how modules are enabled, porting to apache2.4 api.
<xnox> so a bit elaborate.
<apw> ogra_, dropped no, wrong most likely
<apw> whats missing
<ogra_> apw, CONFIG_ELF_CORE
<ogra_> we used to have it set for a while
<apw> ogra_, in which kernel, they are not all the same for sure
<ogra_> apw, i would guess in all of them (we used to have it on in grouper before i think)
<ogra_> apw, since whoopsie needs it for bugreports
<apw> ogra_, well i was assuming someone had found it missing in something specific
<ogra_> apw, ev found it missing when trying to make whoopsie work on grouper
<ev> o/
<ev> I sent a mail to ubuntu-kernel@l.u.c about it
<apw> ev ack
<cjwatson> wookey: you could fix the configure-not-executable problem by just sticking chmod +x configure at the start of the build target in debian/rules.  That's probably the most pragmatic approach.
<wookey> cjwatson: right yes. I didn't think of that until after I'd uploaded a repack version
<wookey> also there _is_ a real sbuild 0.64.0 orig.tar.gz so having a broken version of that available anywhere seems like a bad plan
<jibel> hallyn, I commented on 1196518 but I'm blocked on finding out why write fails with "invalid argument"
<rsalveti> xnox: did you need any extra patch for the android sources to make it build with 4.8?
<xnox> rsalveti: so the cross-toolchain is 4.7 based, build with host's 4.8. A 4.8 cross-toolchain does build android sources, if a couple -Werror -Wall are removed in 2 or 3 modules (have a branch of those somewhere)
<xnox> rsalveti: so no patches at the moment.
<pitti> cjwatson: thanks for the very nice britney/autopkgtest announcement!
<cjwatson> yw
<xnox> rsalveti: atm for the host tools a prebuild toolchain is also used, and there were failures from moving that to gcc4.8.
<xnox> rsalveti: those will need fixing to package android as a debian package.
<ev> thanks for looking into it, apw
<rsalveti> xnox: alright, good
<rsalveti> thought we'd have more issues
<xnox> rsalveti: well, I am compiling using "-O2" without any standard ubuntu hardening flags, everything fails when building with those enabled.....
<rsalveti> sure, that's fine
<xnox> was there a script or something that can rebuild .pc directory given unpacked tree and quilt series?
<xnox> because the patches are "pre-applied"
<cjwatson> xnox: http://people.canonical.com/~cjwatson/dpkg-quilt-setup
<Laney> xnox: The way I know is to reverse apply using a loop over quilt series | tac and then reapply them
<Laney> yeah that
<xnox> cjwatson: can we like add that to quilt package in debian?! =)
<cjwatson> xnox: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=572204
<ubottu> Debian bug 572204 in dpkg-dev "dpkg-dev: maintainer workflow problems with 3.0 (quilt) and VCS" [Wishlist,Open]
<ev> apw: I think I've finally gotten to the bottom of why we're not seeing kernel oopses on https://errors.ubuntu.com. The version of apport we have deployed to production doesn't have the signature generation code for kernel oopses. Testing apport tip in a canonistack deployment, then I'll file an RT to get that out for all future crashes and work on a back population job to iterate and bucket the existing kernel oopses in the database.
<apw> ev, sounds good indeed
<apw> ev, how urgent is this ELF_CORE thing, it is enabled in the other three kernels, do you have one of those, would a test kernel do for now
<apw> ev, trying to work out if i really have to upload it right now or not
<ev> you mean in another device?
<ev> I only have the nexus 7
<apw> ok
<ev> getting something to test would be fine
<apw> ev http://people.canonical.com/~apw/grouper-saucy/
<ev> apw: I don't suppose you have linux-grouper-headers-3.1.10-6 as well?
<apw> ev,  on its way
<ev> thanks
<rbasak> Can someone with ruby packaging experience please look at bug 1197894 for me? I can't figure out why dh_ruby --test doesn't run the test suite. An override_dh_auto_test to call rspec works, but I'm not sure that's the right fix.
<ubottu> bug 1197894 in ruby-indentation (Ubuntu) "Test suite not run on build" [Undecided,New] https://launchpad.net/bugs/1197894
#ubuntu-devel 2013-07-05
<hallyn> jibel: (holiday today) saw the emails...  will look tomorrow.
<pitti_> Good morning
<dholbach> good morning
<Noskcaj> roaksoax, daily reminder, testdrive
<pitti> meh, https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-ubuntu-drivers-common/28/ regressed -- tseliot, could it be that the new kernel broke our nvidia/fglrx drivers?
 * tseliot looking
<pitti> tseliot: fglrx fails with
<pitti> AssertionError: 100 != 0 : update-alternatives: error: error creating symbolic link `/usr/lib/i386-linux-gnu/xorg/extra-modules.dpkg-tmp': No such file or directory
<pitti> tseliot: nvidia-304 seems to work, but 304-updates, 310 and 313 don't
<tseliot> pitti: I think I have a fix for the alternatives error
<pitti> tseliot: ah, great; those are always from a clean
<pitti> ... installation
<tseliot> pitti: I assume mesa is not being installed for the tests right?
<cjwatson> tjaalton: Your sssd/raring patch drops a linking fix (http://paste.ubuntu.com/5846034/).  Is that intentional?
<pitti> tseliot: no, unless the nvidia packages pull it in as a dependency
<pitti> tseliot: otherwise it's a minimal server install
<cjwatson> tjaalton: If so I think it needs some reasoning for why it's a good idea to drop it in an SRU ...
<tseliot> pitti: then it's bound to fail unless I add some directories in the debian/dirs files.
<tjaalton> cjwatson: hmm I'll check
<pitti> tseliot: so is there a missing dependency in the test case?
<pitti> tseliot: i. e. do these assume some Xorg-ish package to be installed now? (they didn't in the past)
<pitti> tseliot: I can add one easily
<tseliot> pitti: either libgl1-mesa-glx or libgl1-mesa-glx-lts-quantal should fix it
<pitti> tseliot: ok, running locally with that added
<tseliot> pitti: good, let me know how it goes
<tjaalton> cjwatson: good catch, must be some git fail by me.. reject and I'll reupload
<tjaalton> no wait
 * tjaalton runs a quick build-test
<tjaalton> cjwatson: yeah, reject. I'll sort out the local mystery of where it got lost and reupload
<tjaalton> "a oneliner apparmor rule change doesn't need a build check, right?"
<tjaalton> ..
<pitti> debdiff FTW
<infinity> tjaalton: Probably doesn't, but every upload needs a debdiff. :)
<infinity> pitti: Jinx.
<tjaalton> hmm yeah
<tjaalton> oh I see now
<tjaalton> branched raring from a commit too early :)
<ev> is there some trick to convincing ubuntu touch to use the newly installed kernel, beyond remounting /system rw?
<cjwatson> tjaalton: done
<ev> I've got a kernel from apw that I installed via dpkg, but uname -v is still reporting the build time of the previous kernel
<apw> ev, if it was my kernel running it would have a unique version string too
<apw> ev, did you only install the package
<apw> ie did you do anything after
<ev> apw: yeah, I just did dpkg -i on the three debs you gave me
<ev> and did a sudo reboot
<apw> hmmm no idea in container flip world if that works or not, before container flip it is definatly not enough
<ev> apw: any idea where I prod the bootloader from on this?
<apw> ogra_, ^^ does flash-kernel grok container flip yet or are we abootimg'ing still
<ev> ah, I remember that thing from the last time I toyed with all of this :)
<tjaalton> cjwatson: thanks, will upload again in a bit
 * ogra_ wonders why he writes instructions in announcements :P
<ogra_> apw, see the flipped container mail
<ogra_> :)
<ogra_> (and then use flash-touch-kernel)
<ogra_> (with path to zImage as arg)
<ev> I don't have an email that mentions flash-touch-kernel :), but fair enough
<pitti> tseliot: that seems to fix fglrx, but not the nvidia ones
<pitti> tseliot: expected?
<tseliot> pitti: err... let me check nvidia
<pitti> tseliot: I pushed that as f181e58e9cb8a204
<pitti> tseliot: oh, it's because nvidia-310 is now a transitional pacakge
<pitti> and so is nvidia-313-updates
<tseliot> pitti: correct
<pitti> tseliot: so I guess we want to update those to check 319 now?
<tseliot> pitti: 319 and 319-updates, yes
<pitti> running
<ev> wooo http://paste.ubuntu.com/5846078/
<ev> thanks apw and ogra_
<apw> ogra_, so you have somewhere to refer us to when we are being wallies ?
<tseliot> pitti: BTW how do you run those tests in ubuntu-drivers-common?
<ogra_> heh
<tseliot> pitti: the ones in debian/tests/system
<pitti> tseliot: you can just run them with sudo debian/tests/system, but I usually run them in a full VM with run-adt-test -sUS file://`pwd` ubuntu-drivers-common
<pitti> (to test my local changes)
<tseliot> ah, nice
<tjaalton> cjwatson: ok fixed version up
<pitti> tseliot: success! thanks for the hints, uploading now
<tseliot> pitti: excellent, thanks
 * pitti wants green dots again
<apw> ev, it would be good to know sooner rather than later if that test kerenl is any good, as i am considering an upload for grouper
<ev> apw: ^ see above. Works a treat
<ev> thanks!
<apw> ev, awsome, i'll rack it and stack it then
<cjwatson> tjaalton: thanks, accepted
<ev> apw: cheers
<ogra_> apw, ev, i'll add a kernel/postinst.d script so installing packages will DTRT
<apw> ogra_, sounds good indeed
<ev> ogra_, apw: fwiw the kernel packaging or something needs to remount /system rw since /lib/modules is a symlink to it
<ogra_> ev, well, the whole disk  will be readonly soon
<ev> ogra_: interesting. Why?
<ogra_> ev, we will drop apt support and switch to image based upgrades
<ogra_> (there will be a developer mode but it isnt clear yet what that will enable)
<ev> ah, but surely we'll be write able to write to /var/log and friends?
<ogra_> ev, security ... everything but the /data partition will be ro
<ogra_> heh. indeed, the system will go on to function :)
<ev> yay
<ev> as long as we arrange for /var/crash to be writeable, I'm happy
<ogra_> /run and /var/foo will indeed be tmpfses
<ev> or whatever we set APPORT_REPORT_DIR to
<ogra_> yeah, you might want the crashes persistent during the dev cycle, i guess using /data might be a good idea ... (we can then switch to a tmpfs after release)
<ogra_> s/after/at/
<ev> I'm not convinced they need to persist for too long, but it might be worth making them survive a reboot. I'd need to talk to pitti about it, but an upstart inotify watch that removed both the .crash and .upload* when .uploaded is present
<ev> but if it's going to make things difficult, we wont lose a ton by living on a tmpfs
<infinity> Having them survive a reboot is probably user-hostile on a shipping device anyway.
<infinity> Assuming there's going to be some process that, at boot, tries to report it all and grinds my phone to a halt like apport does to my laptop.
<ev> yeah, was just trying to consider the case where the device crashes in a way that causes the user to reboot it
<pitti> ogra_, ev: yeah, we have some things which need to survive, such as suspend failure reports; the others are probably not all that interesting
<pitti> (or in general kernel oopses)
<pitti> well, storing those in a persistent location doesn't imply that we necessarily have to send them all right after boot
<infinity> (Tell me that whatever is reporting crashes on the phone isn't going to be the system-killing mess that the current state of affairs is?)
<infinity> Cause on an i7 laptop, booting with a dozen pending crash reports basically means an unusable system for half an hour.
<infinity> Pretty sure that's a non-starter on an A9 phone.
<ev> infinity: so to some extent that's mitigated by not having a UI on top of this
<cjwatson> ogra_: /var/foo> do you know just how much of /var?  It would be helpful to know for click
<ev> also, we'll skip the (existing) hook paths
<ev> since there's no interactive UI (though not ruling out server-side hooks)
<cjwatson> Actually, tmpfses don't help me
<ogra_> ev, you can write to /dev/kmsg .... android uses a ram console by default, that means crashes going to that device (or actual kernel oopses) will persist in /proc/last_kmsg over reboots
<ogra_> cjwatson, well, i guess we define how much, stgraber designs this, so if you have specific needs make sure he knows
<ev> infinity: I'd happily rewrite it in C, but it's been deemed not a good investment of my time. We might be able to convince it to run under pypy though.
<cjwatson> ev: 'cos pypy works so well on ARM
<ev> I had not considered that :)
<cjwatson> (Well, it might work, but it hasn't built in ages)
<infinity> It builds, with sufficient resources.  Calxeda will save us all.
<cjwatson> When it happens ...
<infinity> Still have no idea how potentially awesome it is or isn't once it's built.
<cjwatson> I think any modules you need would need pypy-* packages too?
<cjwatson> Not quite sure how that stuff works
<infinity> ogra_: Note that last_kmsg only survives a warm reboot, not a hard-crash-and-battery-pull sort of situation.
<ogra_> not a battery pull but up to now it survived all crashes i needed data for :)
<ogra_> cjwatson, if a tmpfs isnt enough you need to use /data
<ev> infinity, pitti, others: if you have further suggestions as to how we can make this a less intensive experience on the phone, I'm all ears. One option would be a more aggressive compression of the report data, either by compressing more fields or switching to something that gives a better ratio (for the increased decompression cpu burden on daisy.u.c.)
<infinity> cjwatson: I assume click has a /var/lib/dpkg equivalent that it needs to write to?
<infinity> cjwatson: Probably best to just bindmount that to data/clickdb or something.
<ogra_> ev, more compression means more bttery draining and more CPU hogging
<cjwatson> infinity: Yeah, just wanted to know what my parameters are, and it would be nice to avoid lots of package-specific bind-mounts
<ogra_> if you have the diskspace i would go for extensive compression
<ogra_> *wouldnt
<ev> ogra_: okay, so then just compressing the core file as we do now is probably the way to go
<pitti> ev: more aggressive compression would probably be more CPU intensive? so that's a bandwidth/CPU tradeoff
<ev> yeah
<infinity> ev: Keeping it cheap on CPU is probably ideal.  Obviously, enormous reports over 3G data is also kinda crap, but hopefully they'll be smallish and infrequent...
<ev> we wont send them over 3g, but yeah
<ogra_> yeah, gzip with std options doesnt do much harm
<ev> wifi only. I don't want to get forwarded cell phone bills
<pitti> ev: but I guess if we really want to get a magnitude more performance out of this, we need to move from full core dumps and Python to something like minidumps and C/C++/vala..
<cjwatson> ev: Hopefully it's a bit more fine-grained that that; some of us have reasonably adequate 3G limits
<infinity> We won't?  Android sends reports over 3G (it asks me if I want to, first, mind you, and they're also not huge cores)
<ogra_> xz with highest compression rate definitely does ... i guess you even feel it on the UI
<cjwatson> *than that
<ev> cjwatson: how do you make the distinction?
<cjwatson> ev: ask
<cjwatson> ev: system preference kind of thing
<ev> https://wiki.ubuntu.com/ErrorTracker#Privacy_settings for what it's worth
<pitti> ev: but with client-side dupe detection we hopefully won't actually have to send so many cores?
<ev> mpt: ^
 * ogra_ wouldnt allow reports via 3G ... period
<ev> pitti: correct
<infinity> ev: Android is littered with "use 3G for scary data" app options.  We could probably go one better and make it a global "just do it" option.
<cjwatson> ev: I'd have expected this to be a system setting, not specific to errors
<pitti> ogra_: certainly not a bad approach to begin with -- send them when enabling wifi
<ev> we only ask for a core if we haven't already retraced it or don't already have it in the pipeline to be retraed
<ogra_> pitti, exactly ...
<cjwatson> Android's approach is pretty much right here IME
<cjwatson> infinity: It has a general system-level setting too, doesn't it?
<infinity> cjwatson: I'd argue Android's approach is a bit fragmented on the app level (I've had to tell several apps that it's okay to upload on 3G, had to tell VoIP apps that it's okay to make calls on 3G, etc... I'd love a system setting)
<ogra_> cjwatson, androids approach ends up in a million of options ... i dont think thats good
<infinity> cjwatson: If there's a system setting, that's new, which would explain all the apps also asking me. :P
<cjwatson> Maybe I'm imagining it
<infinity> (So, we should get it right the first time)
<ev> pitti: minidumps would be pretty cool
<pitti> ev: still a question of how useful they are going to be for actually fixing the crashes..
<cjwatson> There's things like Data usage -> ... -> Restrict background data
<pitti> knowing in which function a crash happens doesn't tell you taht much
<ev> pitti: are we not able to just pair them with a symbol server and get a full stacktrace out?
<infinity> cjwatson: Ahh, yeah, that's been there since 1.x
<cjwatson> Anyway, I thought I remembered seeing a spec for our 3G usage that included something plausibly system-level for this
<pitti> ev: no, minidumps don't have that information any more AFAIK; one really needs a core
<ev> ah, rubbish
<cjwatson> And of course Android has the mobile data limit thing
<xnox> infinity: i think mpt draw a setting for data, where all apps are listed and one can flick them on/off for 3G usage.
<xnox> mpt: shouldn't we have an upload service in addition to download service? u1, crash reports, files / photos.........
<pitti> ev: but again, hopefully with SAS we won't need to upload all that many cores..
<pitti> ev: perhaps we can dial down the aggressiveness of this for phones a bit, such as not requesting more cores until the first report (with matching SAS) finishes retracing and fails, and give up after three failures
<pitti> ev: not sure how agressively it collects cores right now, perhaps it already works that way?
<pitti> that still leaves the local processing, of course
<mpt> xnox, on the contrary, I just now mailed ubuntu-devel-discuss@ saying I doubted it would be useful to have OS-level control  over which apps access the Internet.
<xnox>  /o\ mpt I only have 500MB data plan, I want everything on WiFi only. But I want an app automatically start using 3G, if it's in the foreground - meaning I want it to have internet access over the scarce 3G
<mpt> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2013-July/014653.html
 * xnox should consider forking out 5GBP a month for unlimited 3G internet.....
<mpt> I get 1 GB/month :-)
<xnox> mpt: not ubuntu-phone mailing list? https://launchpad.net/~ubuntu-phone
<mpt> xnox, I didn't decide where the discussion started
<xnox> mpt: For me 0.5GB is fine, sitting at home/work on WiFi. But sometimes I am somewhere bored and decide to like pictures of all lolcats in my facebook newsfeed...... download a few games..... and it goes downhill from there.
<mpt> yep
<tjaalton> how evil would it be to ship an identical file in two binaries and adding Replaces: "the other" to them?
<tjaalton> this trying to match sssd packaging on fedora, where they can ship the same file on to packages and they won't conflict
<tjaalton> avoids creating a package which has just one file
<xnox> tjaalton: what's the file and why it's needed?
<tjaalton> it's a helper binary needed by ipa and ad backend
<tjaalton> s
<xnox> tjaalton: instead of conflicts it could be an dpkg-alternative file, than both packages can be installed. And if the file is the same, it doesn't matter which one is "active" and it will be guaranteed to be available if either of the two packages are installed.
<xnox> tjaalton: would be nicer to have it in one place. Or can both packages be used without the other one installed?
<tjaalton> yes
<xnox> tjaalton: and can both be installed simultaniously and used as well? if yes, please don't make them conflict....
<tjaalton> the backends got split into subpackages so you can only have what you need (ldap, krb5, ad, ipa)
<tjaalton> I didn't mean to make them conflict, but add Replaces
<cjwatson> identical + Replaces> that's really very evil and is a timebomb for later developers.  Use a -common package or something.
<tjaalton> ok, figured
<cjwatson> Using alternatives is also pretty confusing.  I wouldn't recommend that.
<infinity> tjaalton: Mutual Replaces is more than just confusing, it's broken.  If you install A, then B, then remove B, the overlapping file disappears.
<tjaalton> infinity: heh, ok.. didn't think of that
<infinity> tjaalton: A -common, or alternatives, or a dpkg-divert all work fine, for varying levels of user and developer confusion around each option.
<tjaalton> sssd-ad-common is least confusing
<tjaalton> and really not much work either to "maintain"
<tjaalton> or pac-common
<tjaalton> anyway..
<ev> pitti: yeah, it should already work that way (sorry for the delay - we're moving Cassandra to prodstack today).
<pitti> ev: ooh!
<ev> :) exciting times
<pitti> doko_: ah sorry, I didn't realize that postgresql-9.1 -2 (FTBFS fix) didn't autosync; I adjusted your tcl config change to work in Debian as well, and will upload now
<ev> Twelve 1 TB nodes to start with
<pitti> 11 TB! holy c***
<ev> :D we've got a lot of data
<pitti> ev: do we really have that amount of data for errors, or is that "for futureproof"?
<pitti> err, 12 TB, but whatever
<ev> pitti: we have 6 TB of actual data
<ev> with a replication factor of two
<ev> (we want to keep the node sizes down to about 1TB, since earlier versions of Cassandra deal better with 1TB or less)
<ev> pitti: it's part of the reason why I'm really keen on getting Hadoop running soon after we finish the move to prodstack (being on prodstack makes it much easier, since we can spin up a secondary cluster for just hadoop analytics)
<pitti> so we have more error data than archive size :)
<ev> errors.ubuntu.com will serve the common use case, but for real investigative work, having the whole dataset at your fingertips will be invaluable
<ev> lol, an interesting way to look at it, yeah
<ev> the nodes themselves will have 2TB of disk space each
<ev> we think we're the first people to use Ceph for this
<tunnelshade> Need some help in packaging
<cjwatson> Please ask your question directly, rather than asking to ask
<tunnelshade> I have to build a debian package which has to copy files and run postinst scripts. For this purpose I used debian/package.install. The install using deb was great. But when I tried to upgrade with the next version of .deb all the files previously copied are getting erased.
<cjwatson> Might be easiest if we could see the source package.
<cjwatson> At least the debian/* part.
<tunnelshade> https://anonfiles.com/file/6696ee30a49cde33f51c4d4bf14bcf81 <= If this can do
<cjwatson> tunnelshade: Can you give an example path which is erased?
<tunnelshade> Initially during install the whole source gets copied to /opt
<tunnelshade> so when I tried an update, there is no source folder in /opt
<cjwatson> Giving exact paths would help.
<cjwatson> (Bear in mind I'm unfamiliar with your package and am not planning to install it ...)
<tunnelshade> /opt/package/
<cjwatson> No matches for "/opt/package" in your debian/ directory.
<tunnelshade> I didnt build it, I gave you the folder before building
<tunnelshade> one second
<cjwatson> Generally speaking you should try to avoid your postinst fighting with the list of files shipped in your .deb
<cjwatson> So any files listed by 'dpkg -c foo.deb' you should regard as read-only
<cjwatson> Most problems of this kind are because the postinst is illicitly fiddling about with files shipped in the .deb
<tunnelshade> But I am just using them for reading
<cjwatson> Then I'd need to see 'dpkg -c' output for the old and new versions, I think
<tunnelshade> Almost same, with some new files
<cjwatson> Try cleaning everything out, installing the old version, then "dpkg --unpack owtf_newversion.deb", check whether the files are still there, "dpkg --configure owtf", check again
<cjwatson> That will allow you to tell whether it's dpkg itself or your postinst that's removing the files
<tunnelshade> The files are gone with --unpack itself
<cjwatson> Were they there before the --unpack?
<tunnelshade> yes
<cjwatson> *Which path*?
<cjwatson> Exact copy and paste.
<tunnelshade> /opt/owtf/
<cjwatson> (Incidentally, sudo in a preinst makes no sense; the maintainer scripts always run as root.)
<tunnelshade> that is just a draft, first I get things working, I can cleanup
<cjwatson> You mean that /opt/owtf itself is entirely absent?
<tunnelshade> yes
<cjwatson> Then it must be your postinst's fault
<tunnelshade> (Just to remind I am using install file inside debian folder for copying files)
<cjwatson> Assuming that those files are in owtf_oldversion.deb at all
<cjwatson> How you got the files into the .deb is irrelevant
<tunnelshade> So if I disable postinst you say that things should go fine
<cjwatson> They're being unpacked and then apparently deleted; the only thing that runs that has the opportunity to delete them is your postinst
<cjwatson> Well, if I were you I would fix the postinst, not disable it
<tunnelshade> Fixing means??? Not touching the files
<cjwatson> You might like to execute bits of it step by step to see where exactly it's going wrong
<cjwatson> Not removing the files!
<tunnelshade> ah
<cjwatson> I don't know exactly where it's doing that
<cjwatson> Because it's calling out to external scripts I don't have
<cjwatson> I can see that it's removing /opt/owtf/dictionaries/cms-explorer, which is almost certainly a bad idea
<cjwatson> But not where it's removing all of /opt/owtf
<cjwatson> However, nothing else has the opportunity to do that ...
<tunnelshade> I am also blown by what is happening
<tunnelshade> For information, what is the best place if I wish to run some scripts after installation and using the installed packages
<cjwatson> postinst
<cjwatson> There's nothing fundamentally wrong with doing post-installation steps in the postinst (although in general the less maintainer script code you can get away with writing the better), but from what you've told me your current code would appear to be somehow responsible for the deletions you're complaining about, so start there.  It doesn't run in a particularly magic environment or anything; you can just try stepping ...
<cjwatson> ... through your commands from there as root and seeing where things get blown away.
<tunnelshade> I completely removed the postinst, but still the same
<tunnelshade> By same I mean, the whole /opt/owtf got removed
<tunnelshade> Ah, please take a look, I think the error is in my postrm
<cjwatson> Ah!  Yes, indeed
<tunnelshade> removing files for upgrade as well
<cjwatson> That doesn't make a whole lot of sense.  Try to make it so that you only remove things created by the preinst/postinst.
<tunnelshade> Ok, so I have to remove postrm from the oldversion package as well right
<tunnelshade> Inorder to test
<cjwatson> postrm bugs can be awkward to recover from, yes.
<tunnelshade> Thanks a lot for your time cjwatson
<cjwatson> no problem
<tunnelshade> My problem is solved
<tunnelshade> Can you give me any suggestions other than above, to change in my package
<cjwatson> Generally you should try to depend on packaged Python modules rather than doing a load of pip install calls.
<cjwatson> I'm afraid I don't have time for a full review though
<cjwatson> (At least three urgent-ish things to do today of which I have started on about 0.5)
<tunnelshade> The python packages are outdated in the repos
<tunnelshade> so I have to depend on pip
<cjwatson> Or package new versions
<tunnelshade> I am a cyber security guy, just wanted to package a tool I develop :(
<tunnelshade> So I am not a debian guru
<mdeslaur> cjwatson: is there an example manifest file somewhere other than the file format document?
<A1Recon> Has 802.11ac gone beyond draft?
<cjwatson> mdeslaur: there's one inside http://people.canonical.com/~cjwatson/tmp/com.ubuntu.apps.camera_2.9.1daily13.06.13_all.click - possibly not hugely informative though
<mdeslaur> oh, sweet, and actual click package! :)
<mdeslaur> s/and/an/
<mdeslaur> cjwatson: thanks :)
<cjwatson> people kept asking me for one so I cobbled something together.  I don't promise not to break it
<mdeslaur> cjwatson: so, we don't seem to have a "display name" field in there...ie: "Camera"
<mdeslaur> cjwatson: is that something we want?
<dholbach> can somebody please reject https://code.launchpad.net/~malizor/ubuntu/saucy/ubuntu-wallpapers/fix-for-1177260/+merge/171911?
<mdeslaur> cjwatson: or is the "title" supposed to be that, but is a bad example in your click package?
<dholbach> hey mvo, does lp:~dylanmccall/update-manager/dialogs-refactor look all right to you?
<cjwatson> mdeslaur:     "title": "Camera application",
<mdeslaur> hrm
<cjwatson> mdeslaur: isn't that a display name?
<cjwatson> mdeslaur: title is meant to correspond to the first line of Description:, basically
<mdeslaur> cjwatson: ok, sounded like a short description to me
<cjwatson> mdeslaur: I think it would be OK to consider it as display-name
<cjwatson> It's basically convention
<mdeslaur> ok
<Guest33546> stgraber, hey, I haven't heard heard back from highvoltage yet, when he confirms which way we can do the call, I will kick it off
<Guest33546> weird, this is jono
 * Guest33546 restart XChat
<stgraber> jono_: I pinged him on IRC a few minutes ago but haven't heard back yet
<jono_> stgraber, same here
<jono_> stgraber, lets give him a few mins, and then if he doesn't respond maybe we can go ahead and I can talk to him later in a different call
<stgraber> jono_: ok. I had a chat with him a couple days ago about our position wrt Mir, so at least our views should be pretty much aligned :)
<highvoltage> jono_, stgraber: I' back
<highvoltage> *I'm back, even
<stgraber> hey highvoltage!
<jono_> oh hey highvoltage :-)
<stgraber> highvoltage: can you do g+?
<highvoltage> (ran a few minutes late with giving someone a lift)
<jono_> highvoltage, np
<highvoltage> yep, I'm logged in
<jono_> highvoltage, stgraber cool, I will set it up now and send a link
<jono_> highvoltage, stgraber https://plus.google.com/hangouts/_/e24720733bd142ef469692ef34939e0af9292a57?authuser=0&hl=en
 * highvoltage has not used hangouts in a while so might just have to configure a bit
<jono_> highvoltage, no worries :-)
<dholbach> @pilot out
<dholbach> (more piloting on monday :))
<dholbach> tsimpson, ^ do you know what happened with the bot?
<tsimpson> dholbach: look like it died when freenode exploded, I'm bringing it back
<dholbach> thanks!
<tsimpson> there it is
#ubuntu-devel 2013-07-06
<hallyn_> stgraber: creating saucy containers fails, becuase "chroot $rootfs /var/lib/dpkg/info/openssh-server.postinst configure" fails with "invoke-rc.d: initscript ssh, action "start" failed."  (reproducible by hand)
<stgraber> hallyn_: yeah, I saw that here too, something must have changed in the way ssh is restarted from the postinst, I'll try to figure out a patch this weekend
<cjwatson> stgraber: I fixed openssh-server's postinst a little while ago to be policy-compliant and use invoke-rc.d
<cjwatson> stgraber: So if you were relying on its policy-non-compliance then something might have broken
<cjwatson> OMG what on earth is lxc-ubuntu doing with ssh.conf - couldn't you folks at least sed the existing one or something? :)
<stgraber> cjwatson: oh, yeah, ignore the changes we do in trim(), nobody uses that anymore and I'm hoping to kill it for good by 14.04.
<stgraber> cjwatson: in the standard code path, what we do is move ssh.conf to ssh.conf.disabled, call the postinst then move it back
<stgraber> cjwatson: as it was the only easy way to deal with that back in 13.04, now that openssh respects invoke-rc.d, I'll just add a policy-rc.d (exit 101) and that should fix the issue (we still need the .disabled stuff until 12.04 EOL though...)
<cjwatson> stgraber: Yeah, policy-rc.d should do it.  In <13.10, though, you could have handled it by diverting initctl
<cjwatson> And maybe start-stop-daemon too
<infinity> cjwatson: Does remove-package commit in a single transaction, or is it doing a round-trip removal for each binary I list on the command-line?
<infinity> (Wondering if removing, say, kernel NBS, is being split across multiple publisher runs)
<infinity> Not that it matters, in practice, since NBS stuff shouldn't be needed anymore, but it feels a bit weirdly wrong if it ends up spanning runs.
<cjwatson> infinity: If you remove an entire source that's in one go, but if you're removing lots of binaries without removing their corresponding source (as in NBS) that's multiple API calls
<cjwatson> Since it's BPPH.requestDeletion
<infinity> Kay.
<infinity> I wonder if that could do with a batch mode API call.  Would also speed it up tremendously.
<infinity> (Today's multiple-kernels-plus-a-couple-libraries NBS run takes 10-15m with a high latency connection to LP)
<cjwatson> I wouldn't object, although I don't think it's the most important thing on the list or anything
<infinity> Nah, not dreadfully important.  I'm used to just watching it scroll slowly in the background, as it's doing right now. :P
<cjwatson> There's already PublishingSet.requestDeletion, which would be the right thing to export, but I'm not sure how to export *Set things
<infinity> I've just been doing some NBS-clearing uploads in my wind-down-to-travel lull overnight, so it was on my mind.
<cjwatson> At least in cases where there isn't an obvious collection
<cjwatson> Maybe it would have to be something artificial like a method on Archive; don't know
<infinity> I wonder if people naming their projects ever read them out loud.
<infinity> "kraptor" sounds like an 80s cartoon villian who lives in the sewers.
<infinity> Laney / xnox: You guys are TIL on vtk, do you happen to know what's gone wrong with that's making yade FTBFS now? https://launchpad.net/ubuntu/+source/yade/0.97.0-4
<infinity> Hrm, maybe that's a missing build-dep (or a missing dep)...
<infinity> Laney / xnox: Ahh, that's http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714935 ... I wonder why it didn't seem to pop up until now.
<ubottu> Debian bug 714935 in libvtk5-dev "libvtk5-dev: VTKTargets.cmake adds dependency to other packages (tcl-vtk, python-vtk and libvtk-java)" [Serious,Open]
<Noskcaj> roaksoax, It seems testdrive-gtk is broken in version 3.20
#ubuntu-devel 2013-07-07
<Noskcaj> roaksoax, PING
<Noskcaj> What is the best way to learn Qt as someone who has no knowledge of C, C++ or C#?
<res> hi, iam creating an app indicator.  is there a way to add a Gtk Scale to App Indicator menu item?
<res> in python
<tumbleweed> res: you want #ubuntu-app-devel. See the /topic
<res> tumbleweed: aw sorry. thanks.
<mlankhorst> YokoZar: did you upload wine yet?
<YokoZar> mlankhorst: no
<YokoZar> mlankhorst:  nevermind, yes, if you mean to PPA, then its at wine1.6 rc4, which is the most current
<mlankhorst> oh no release this week?
<mlankhorst> oh well I did an ugly hack to fix winegstreamer threading, did my work of wine for this week..
<mlankhorst> and I should probably cherry pick https://bugs.freedesktop.org/show_bug.cgi?id=47824 to mesa at some point
<ubottu> Freedesktop bug 47824 in Other "osmesa using --enable-shared-glapi depends on libgl" [Normal,New]
#ubuntu-devel 2014-06-30
<pitti> Good morning
<pitti> apw: mvo just ran into "lightdm not starting under systemd", and for him it was a simple reason; can you please again give me the contents of /etc/X11/default-display-manager?
<pitti> apw: the current value ought to be /usr/sbin/lightdm, but it seems older systems had /usr/bin/lightdm there (sbin vs. bin)
<mvo> pitti: seems to be working now
<pitti> mvo: thanks
<Saviq> mardy, hmm so apparently I'm still getting the password prompts for google accounts on login, any idea what could be causing those, and how could I get rid of them? anything I can do to debug?
<mardy> Saviq: I suspect that they might not be coming from online accounts, but from GOA
<dholbach> good morning
<mardy> Saviq: try "dpkg -l *evolution*" and see if there is something about GOA
<Saviq> mardy, not installed
<Saviq> mardy, lemme log in again and try and find out more about those prompts
<Saviq> mardy, hmm! it's gcr-prompter
<Saviq> bug #1044549
<ubottu> bug 1044549 in gcr (Ubuntu) "The "Access Prompt" randomly pop up!" [High,Triaged] https://launchpad.net/bugs/1044549
<rbasak> pitti: spamassassin needs a (trivial) merge, but what was the purpose of https://launchpadlibrarian.net/167650114/spamassassin_3.4.0-1_3.4.0-1ubuntu1.diff.gz ?
<rbasak> pitti: FTBFS or something else?
<rbasak> And is there a matching Debian bug?
<pitti> rbasak: it failed its tests as it ran the tests with python but didn't test-depend on it
<pitti> rbasak: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=740171
<ubottu> Debian bug 740171 in spamassassin "Fix autopkgtest missing dependency" [Normal,Open]
<pitti> yay for not applying simple patches in four months when uploading :/
<rbasak> pitti: ah - in debian/tests/control. I mistook that for debian/control. Thanks!
<rbasak> pitti: you want me to take the merge?
<pitti> rbasak: please :)
<geser> what's the current preferred fix for code linking with -lgfortran where gcc is 4.8 while libgfortran is 4.9 and gcc not finding -lgfortran? wait till gcc-4.9 is default again?
<rbasak> pitti: uploaded.
<Laney> @pilot out
<Laney> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: Laney
<Laney> good start
<Laney> ..
<LocutusOfBorg1> thanks infinity
<LocutusOfBorg1> appreciated a lot
<pitti> rbasak: thanks
<apw> pitti, $ cat /etc/X11/default-display-manager
<apw> /usr/sbin/lightdm
<pitti> apw: ok, so that wasn't it; thanks
<apw> will double check when i get my next kernel it is still there
<apw> b 3
<brendand> any core-dev around?
<pitti> brendand: probably better to just ask your question
<brendand> pitti, that's my question? i need to subscribe them to a merge proposal :)
<pitti> brendand: I can do that
<brendand> pitti, thanks - anyway it turns out i don't have permissions to do that at the moment, so i need to wait for someone to appear from the core apps team
<dholbach> seb128, do you think anyone can respond to https://twitter.com/WyllieChilunSGS/status/482131496254599168?
<Laney> dholbach: I will
<dholbach> thanks Laney
<pitti> mvo: did you see the "more PEP-8 fun" in https://jenkins.qa.ubuntu.com/job/utopic-adt-python-apt/27/ARCH=i386,label=adt/console ?
<mvo> pitti: no I haven't, let me have a look now
<jtaylor_> infinity, LocutusOfBorg1: sorry I did not check vtk properly
<jtaylor_> infinity, LocutusOfBorg1 you reverted the tcl 8.6 change
<jtaylor_> infinity, LocutusOfBorg1 that breaks a bunch of rdepends, please apply the trusty diff again
<jtaylor_> brb 30 min
<LocutusOfBorg1> mmm let me see
<mapreri> what's up with MoM? it says "Generated at 2014-06-24 21:44:15 UTC."...
<cjwatson> mapreri: I'm working on it
<cjwatson> It tends to have trouble when people manage to upload packages that don't unpack
<mapreri> ah, great
<Laney> jamespage: you interested in looking at bug #1251563?
<ubottu> bug 1251563 in net-tools (Ubuntu) "netstat command returns nozero even if successively executing" [High,Triaged] https://launchpad.net/bugs/1251563
<jamespage> Laney, can do - has the merge been done yet?
<Laney> Doesn't look like it
<jamespage> Laney, OK - on my list
<Laney> jamespage: thanks!
<jamespage> cjwatson, OK if I pickup the net-tools merge?
<cjwatson> jamespage: Fine from my point of view, though I believe it's technically doko's
<jamespage> cjwatson, oh - yes indeed it was :-) did not read far enough up...
<doko> mvo, could you have a look at https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-python-apt/lastBuild ?
<bluesabre> Greetings sponsors!  Please let me know if you are able to upload the following package to trusty-proposed so that we can begin SRU verification.  We'd like to deliver these fixes for 14.04.1
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1331871
<ubottu> Ubuntu bug 1331871 in lightdm-gtk-greeter (Ubuntu) "[SRU] Please backport lightdm-gtk-greeter 1.8.5 to trusty" [Undecided,New]
<bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
<ubottu> Ubuntu bug 1323405 in menulibre (Ubuntu Trusty) "[SRU] Please backport menulibre-2.0.4 to trusty" [Undecided,New]
<caribou> Laney: just saw your update regarding 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: the backport needs to be done from the Saucy package as it has an older version (3.0.1) than Trusty (3.1Â°
<Laney> caribou: saucy doesn't have the fix though
<Laney> or do you want #12?
<caribou> Laney: not yet as this is one of the tasks of this bug
<caribou> Laney: but it's been lo long in the waiting queue that now saucy is going EOL
<caribou> Laney: & Trusty has a more recent version & I'm not sure it can be backported as such
<caribou> Laney: so yes, #12 would do it
<Laney> well, it can if it'll work
<caribou> Laney: I need to recheck as I vaguely remember some dependancy issues b/w trusty & precise
<caribou> Laney: & I have another round of fixes for it lined up. Let me check first
<caribou> Laney: maybe it would be simpler just to backport 3.1
<Laney> caribou: I think so, if you're up for taking a look at the trusty package on precise and seeing what (if anything) needs changing to make that happen
<caribou> Laney: sure, doing it right now.
<Laney> let me know - we could still sneak in an SRU for 13.10 if this is too hard
<jtaylor_> doko:  you uploaded blt with tcl/tk 8.6 even though you know it breaks stuff? oO
<jtaylor_> in debian
<jtaylor_> we haven't even got a fix yet in utopic
<caribou> Laney: yep, got a failed dependancy on dh-python which is not in Precise
<caribou> Laney: hmm, this dh-python dep is going to be an issue going forward as after saucy we will no longer have a release to pull the source from other than trusty
<mvo> doko: yeah, done and fixed in git
<mvo> doko: its pep8 going wild
<doko> mvo, thanks!
<doko> jtaylor, no, I don't know
<mvo> doko: yw, I upload in a some minutes
<Laney> caribou: yeah, how long are you going to want to backport for?
<caribou> Laney: 12.04 lifetime :-/
<caribou> Laney: is there a "best practice" way to install python3 bits on Precise
<Laney> you could un-dh-python2 it, or look at backporting that to precise
<caribou> Laney: sosreport 3.1 is python3, hence it uses a --with python3 rule
<caribou> Laney: from what I can see, there is no dh_python3 on Precise. If there is an alternate way of installing python3 software on Precise I can adapt the rules file for it
<geser> doko: what's the current fix for code linking with -lgfortran where gcc is 4.8 while libgfortran is 4.9 and gcc not finding -lgfortran? wait for gcc-4.9 becoming the default again? (I was looking at some r-cran-* FTBFS over the weekend)
<doko> geser, waiting until tomorrow
<Laney> caribou: ah sorry I read dh-python2 there... I'm not totally sure about py3 on precise myself
<caribou> Laney: maybe the simplest approach for this specific bug is to fix saucy, then use it as a source for the backport
<Laney> if a backport would produce functional packages then we could look at that (Debian did this)
<caribou> Laney: a backport from a newer saucy would
<Laney> I mean of dh-python
<caribou> Laney: ah, I thought you meant sosreport
<Laney> saucy backport would be easy enough, but then we get this problem next time I guess
<caribou> Laney: gives me more time to figure out how to get sosreport 3.1 into precise, hence the backport would be from Trusty
<Laney> might give someone room to look at taking on the dh-python task
<Laney> so if you want, gather up all the fixes you want and propose a new saucy debdiff then I'll sponsor that for youe
<doko> tvoss, what's the status of the phone/4.9 transition?
<caribou> Laney: I will update the bug : let's get the current debdiff in saucy as it is now. I don't want it to wait any longer
<Laney> alright
<caribou> Laney: another -backports question : since you don't use debdiffs for backports, it means that the source package needed for the backport is directly pulled from the archive
<Laney> caribou: we download the source from the new release and then upload it to backports with a new changelog entry on top
<caribou> Laney: I mean, I have no other way than *not* using dh-python in Trusty as well
<Laney> caribou: We can do source change backports if it's necessary to make the package build or work
<Laney> in that case you attach a debdiff which is applied on top of the package to be backported
<Laney> https://wiki.ubuntu.com/UbuntuBackports#Building_a_Backport
<caribou> Laney: that is what I had in mind : keep the trusty pkg intact & add a minor modif to have it work in the backports archive
<caribou> Laney: thanks, I'll use that as a reference
<Mantas-Baltix> Hi all :)
<Mantas-Baltix> Could someone tell me why memtest86+ source code isn't imported from Debian into launchpad bzr (https://code.launchpad.net/debian/+source/memtest86+)? At http://package-import.ubuntu.com/status/ memtest86+ package is on section  "currently running" for at least 4 hours :(
<rbasak> Mantas-Baltix: a UDD import failure is not uncommon. Try the UDD list - address at the top of that status page.
<Mantas-Baltix> rbasak: Is there a failure when memtest86+ is under "currently running" for few hours ?
<michagogo> cjwatson: are you around? Mind a PM?
<cjwatson> michagogo: I don't mind, but if it's about bitcoin I think I've already helped as much as I'm able and I'm not going to have time to help more
<Laney> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<michagogo> cjwatson: well, the thing is that it seems like what I was told was wrong. I was under the impression that the next step was for someone to sponsor it and upload to -proposed, and then you guys (SRU team) would review and discuss it
<Laney> caribou: uploaded
<caribou> Laney: thank you very much
<Laney> sure
<Laney> when it hits -updates we can do the backport
<michagogo> But then stgraber seemed to disagree: 19:15:48 <stgraber> no, it's not. If someone was to upload that today, I'd reject it when it hits the queue because it doesn't meet our current SRU criteria 19:16:00 <stgraber> so if you don't want that to happen, this needs to be discussed prior to upload
<cjwatson> michagogo: Bring it up on the ubuntu-devel list, with context?
<michagogo> cjwatson: so I wanted to know, how does one start a discussion with the SRU team, since you don't appear to have an IRC channel nor a mailing lost
<cjwatson> We're all on ubuntu-devel
<michagogo> cjwatson: ah, that's the place for it?
<michagogo> Okay, thanks.
<Mantas-Baltix> could someone upload nautilus 1:3.10.1-0ubuntu9.2 from trusty-proposed to trusty-updates (see bug  #1184720 )
<ubottu> bug 1184720 in nautilus (Ubuntu Trusty) "Nautilus does not properly navigate symbolic links" [Low,Fix committed] https://launchpad.net/bugs/1184720
<Mantas-Baltix> VERIFICATION DONE one week ago, I also can confirm, that nautilus 1:3.10.1-0ubuntu9.2 from trusty-proposed works fine with symlinks
<rbasak> Mantas-Baltix: usually packages have to wait for at least a week to give all testers an opportunity to find regressions. Looks like that one's only 6 days old, so it won't be on the SRU team's radar yet.
<infinity> jtaylor_: I didn't revert anything, the sid upload that I synced had literally no diff against the utopic version except changelog.
<jtaylor_> infinity: then my diff was lost already by an earlier sync/merge :/
<infinity> jtaylor_: -15.1 was synced by Dmitry Shachnev
<infinity> jtaylor_: And it appears to have tk8.6 bits...
<infinity> Err, no.
<infinity> I can't read.
<jtaylor_> I think the underlinking patch was applied in debian
<jtaylor_> but debian uses 8.5 not 8.6
<infinity> jtaylor_: Yeah.  I'll fix this up.
<jtaylor_> this needs to be keept in ubuntu + the patch probably needs adapting
<jtaylor_> thx, I can maybe also have a look later today
<jtaylor_> vtk build unfortunately takes very long on my machine
<infinity> jtaylor_: Testbuilding this now: http://paste.ubuntu.com/7726421/
<jtaylor_> infinity: looks good thank you
<infinity> jtaylor_: NP, I had to do something with this whole "accidentally waking up way too early on a day off" situation.
<jtaylor_> :)
<jtaylor_> fwiw the patch should be forwarded to debian as it now too has a 8.5/8.6 mix which should be avoided. I'll do that this evening
<infinity> jtaylor_: Ta.  I suppose the other option would be moving forward with getting the experimental version in sid (though it also needs the 8.5->8.6 transition, it looks like, but doesn't need the patch).
<jtaylor_> right might be the better path
<jtaylor_> then there is also vtk6 where the tcl bindings don't seem to work at all due to multiarch :/
<doko> jamespage, could you have a look at debian-java ML, Merging maven-repo-helper and maven-debian-helper ?
<jamespage> doko, I can but not today
<jamespage> doko, but will do this week
<mapreri> pitti: thanks in advance :) (wrt the outgoing email to you)
<doko> jamespage, thanks, I assume that proposed merge would force maven into main
<jamespage> doko, it would
<Mantas-Baltix> It seems there are some problems with package's sources imports from Debian - at http://package-import.ubuntu.com/status/ same packages  (memtest86+, openscap, liferea, etc.) are on section  "currently running" for at least 7 hours :(
<Mantas-Baltix> I wrote an email to https://lists.ubuntu.com/archives/ubuntu-distributed-devel/2014-June/001215.html  , but got no answer :(
<cjwatson> xnox,wgrant: ^-
<Mantas-Baltix> And count of  "outstanding jobs" at http://package-import.ubuntu.com/status/  increases every 10 minutes...
<xnox> cjwatson: wgrant: something is wrong, despite not publishing any failure logs, there are for e.g. memtest86+ tracebacks from wadllib/application.py failing to parse xml
<xnox> hm.
<xnox> 166.414  safe_decode() called on an already-unicode string: u'Yann Dirson <dirson@debian.org>'
<vak> hi all
<vak> During initramfs phase $(ls /dev/sd* ) shows nothing... how come?.. what modules might have became missing?? could it be that udev rules are broken after HDDs were attached to the new SATA port positions??
<vak> everything was OK before i changed the SATA-ports (and i don't remember at which ports the HDDs were attached...)
<infinity> vak: Seems more likely that the ports you switched to are either nonfunctional or need another driver.
<ogra_> or probably a BIOS setting that you missed
<infinity> Or the drives aren't plugged in right, or, or...
<infinity> vak: Anyhow, that's more of a support question for #ubuntu, not a development question.
<xnox> Mantas-Baltix: it is running at the moment, monitoring the log, it probably is blowning up on the sid upload.
<xnox> vak: you can increase udev logging as a boot arg and/or config file options / command, to see which events udev is saying about hard-drives, et.al.
<xnox> Mantas-Baltix: http://paste.ubuntu.com/7727282/ and since debian import fails, it's out of date.
<vak> infinity: ogra_: everything is OK if i ran LiveCD.
<vak> xnox: changed to debug 2 hours ago, nothing interesting so far
<Mantas-Baltix> xnox: could you fix the import, at least memtest86+ 5.01-1 , please ;)
<vak> infinity: and the questions seems to be too deep for supporters on #ubuntu
<vak> s/questions/question
<vak> infinity: at least, asked there before coming here.
<xnox> Mantas-Baltix: the import errors out, why do you need an import, and how can I help you to unblock you without an import?
<xnox> Mantas-Baltix: possibly permanent, and/or requiring fixes in the import stack.
<Mantas-Baltix> xnox: I wanna create memtest86+ 5.0.1 packaging  recipe for my PPA - I need to have latest memtest release for Ubuntu Baltix derivative, see http://launchpad.net/baltix
<xnox> Mantas-Baltix: pull-lp-source, dput into ppa. Or even use a script from ubuntu-archive-tools to copy the version you want, into ppa/series you want.
<xnox> Mantas-Baltix: normal dput uploads are accepted into ppa. And since the branch import is out of date, you are out of luck.
<xnox> Mantas-Baltix: are you planning to modify memtest? or do you just want latest one in your ppa?
<xnox> E.g. $ ./copy-package -d ubuntu -s utopic --to-ppa xnox --to-ppa-name scratch --to-suite trusty memtest86+
<xnox> from lp:ubuntu-archive-tools.
<xnox> there is also backport-package script in ubuntu-dev-tools that can automate backporting package, lower the version & upload into ppa to have the right version number (e.g. higher than stable, but lower than next release)
<Mantas-Baltix> xnox: no, I just wanna to backport original memtest86+ 5.0.1-1 package from Debian to Ubuntu Trusty and Precise - I already created packaging recipe for memtest86 4.3.6, see https://code.launchpad.net/~baltix/+recipe/memtest86-debian
<Mantas-Baltix> xnox: I currently can't use dput, because today I don't have access to my private GPG key :(
<Mantas-Baltix> xnox: maybe you can upload unmodified memtest86+ 5.0.1-1 package to some PPA (or sources to some launchpad.net branch) and then I could copy package to baltix PPA or create packaging recipe :)
<xnox> Mantas-Baltix: pull-lp-source memtest86+; cd memtest86+-*; bzr init .; bzr commit -m "initial"; bzr push lp:~baltix/+junk/memtest86+ and create a packaging recipe as you wish.
<xnox> Mantas-Baltix: i'm guessing you do realise that not having access to your private gpg key is important =)
<Mantas-Baltix> xnox: I don't have access to private key only today ;)
<mapreri> Mantas-Baltix: and the upload can't wait a single day?
<Mantas-Baltix> mapreri: I'm building new Baltix GNU/Linux distribution release today ;)
<xnox> Mantas-Baltix: i gave you steps to make a branch, which can be "recipified" into a ppa build.
<hallyn> doko: hi, in netcf in trusty you pushed the change to "Build using dh-autoreconf." - i didn't notice that while pushing new versino to debian so it's not there.  Is that needed?  Should I change it in debian before syncing then?
<cjwatson> hallyn: Generally that class of fix is there to make it actually build on some subset of arm64/ppc64el
<cjwatson> hallyn: Even if it isn't needed right now (because the generated files in the orig.tar are new enough), it's good practice to add it anyway to help the next port
<hallyn> cjwatson: ah, ok, so then definately should be there.  ok, thx.  it's just the new dh-autoreconf dep and call in debian/rules right?
<hallyn> cjwatson: do you mind if i ask you to sponsor to experimental ? :)
<cjwatson> I guess ppc64el from the timing
<cjwatson> hallyn: Can do, but have evening things to do at the moment.  Mail?
<hallyn> cjwatson: great, thanks
<cjwatson> And yes, usually it's just build-dep + --with autoreconf, or dh_autoreconf / dh_autoreconf_clean in backward packages :)
<cjwatson> (or there's a cdbs version involving including something)
<juliank> Yep.
<juliank> Its creator agrees.
<hallyn> this one just did include /usr/share/cdbs/1/rules/autoreconf.mk;  not sur eif that makes it backward
<juliank> that's fine
<juliank> it's a CDBS package.
<juliank> also I'd count CDBS as backwards
<juliank> s/also/although/
<hallyn> yeah i think that was his point too :)  I'm a but unsure why I went with cdbs as that package isn't all that old
<Mantas-Baltix> xnox: thanks
<cjwatson> juliank: heh, me too ;)
<tvoss> xnox, so which libelf version am I meant to use? libelf1 or libelfg0?
<infinity> tvoss: libelf1 is the "new" hotness from elfutils, it's probably the one you want.
<infinity> tvoss: Very few things use libelf0g anymore.
 * infinity wonders why glib-bin does...
<tvoss> infinity, thanks
<dobey> infinity, slangasek: either of you want to fix bug #1323334 and eradicate ubuntu-purchase-service from the archive?
<ubottu> bug 1323334 in ubuntu-purchase-service (Ubuntu) "Remove ubuntu-purchase-service from archive" [Undecided,New] https://launchpad.net/bugs/1323334
<slangasek> let's have a look
<infinity> Done.
<slangasek> infinity: stop working
<infinity> slangasek: Removing packages is pleasure, not work.
<slangasek> also, stop sniping things I've said I was looking at
<infinity> slangasek: I did it before you responded. :P
<slangasek> infinity: then let me know you're looking at it maybe ;)
<infinity> 16:06 < infinity> Looking.
<slangasek> oh?
<infinity> (I just made that up)
<slangasek> :)
<dobey> heh
<dobey> infinity, slangasek: thanks :)
<vak> why could it happen that udev didn't create /dev/sd[abc] entries?
<wgrant> xnox: Were you able to make any progress on the package-import issue?
<wgrant> xnox: package-import fixed. The real error was the traceback after the safe_unicode line you quoted; the WADL cache was corrupt.
<sarnold> Trevinho: another 14.04 screenlock bug, not much in the way of details though: 1335835
 * Trevinho checks
<Trevinho> sarnold: I can't access to that bug... is it maybe private=
<Trevinho> ?
<sarnold> Trevinho: argh, sorry, I guess there's still a problem in my scripts :) thanks!
<sarnold> Trevinho: should be open now :)
<Trevinho> sarnold: it is, thanks
#ubuntu-devel 2014-07-01
<Noskcaj> infinity, Could you merge wxwidgets3.0 some time soon please? One of my merges is waiting for the new debian release
<ikepanhc> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ikepanhc
<pitti> Good morning
<rsalveti> diwic: thanks for sending the patch, I sent a similar one last friday but it still needs to be approved it seems (got blocked by the ml)
<rsalveti> so thanks for taking care of that
<diwic> rsalveti, aha, didn't know that
<rsalveti> it just accepts patches from subscribed members, was planning to send it again after subscribing with my canonical email, but you did that already
<rsalveti> so all good
<diwic> rsalveti, I talked to tanuk upstream last Friday and he seemed to prefer changing PA to 200 rather than changing rtkit
<rsalveti> yeah, I saw that, that's why I decided to push that patch forward
<diwic> ok
<dholbach> good morning
<doko_> tvoss, what's the status of the phone/4.9 transition?
<tvoss> doko_, in silo, not done yet
<doko_> tvoss, so no defaults change yet?
<tvoss> doko_, nope, sorry for that. Getting the upstreams aligned is more difficult than anticipated
<sil2100> dholbach: hi! A kind reminder to add me to the patch pilot calendar ;)
<dholbach> sil2100, I can't believe I missed to do that
<dholbach> sil2100, I'll take care of it once this call is finished :)
<sil2100> Thanks ;)
<xnox> wgrant: thanks. didn't recognise corrupt WADL cache. for pkg_importer is that in just that users ~/.launchpadlib/api.launchpad.net/cache, and since it was etree parse error on incomplete tokens some wadl+xml files would be incomplete/invalid there.
<xnox> hm. shouldn't wadllib invalidate and redownload representations, if it fails to load them?!
<brendand> mvo, cjwatson - you made it to the coverage dashboard :) http://162.213.34.64:8080/gaps/project/click/
<mvo> brendand: yeah
<mvo> brendand: I added the smoke test for building apps as part of the integration test too btw https://code.launchpad.net/~mvo/click/test-build-core-apps/+merge/225022
<cjwatson> brendand: Cool, thanks.  Don't know if you noticed but the most recent entry there has coverage of the C code as well
<brendand> cjwatson, i did, thanks!
<cjwatson> Just need to fix a few details per Francis
<brendand> cjwatson, i think the last step before we go green is for you to have a look at the numbers and see if there's anywhere coverage can be improved
<brendand> cjwatson, being sensible about it of course, so not just improving coverage for the sake of it
<cjwatson> Yeah, I'm sure there are a few places
<ochosi> hi bregma, as one of the light-locker uploaders, would you mind to take a look at this (packaging) issue? https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1336065
<ubottu> Ubuntu bug 1336065 in light-locker (Ubuntu) "Does not fail gracefully when lighdm isn't running" [Undecided,New]
<wgrant> xnox: yup, i just stopped, deleted, started, then requeued the failures
<mvo> brendand: the big one that needed improvement was the chroot coverage but that improved quite a bit
<mvo> brendand: but we will check for more :)
<dholbach> sil2100, better? ;-)
 * sil2100 looks
<sil2100> dholbach: better ;) Thanks!
<dholbach> :-D
<cjwatson> rbasak: Would you mind merging ming?  It's one of the last three automake1.10 users
<cjwatson> rbasak: (Now the last one left.)
<doko> mvo, python-apt ping
<jibel> mvo, just a confirmation, for bug 1311396 it's a translation fix and there is no change for this in u-r-u or update-manager, correct?
<ubottu> bug 1311396 in update-manager (Ubuntu Trusty) "broken translations results in traceback in new release notification" [Undecided,Confirmed] https://launchpad.net/bugs/1311396
<doko> tvoss, is duflu on irc?
<tvoss> doko, in #ubuntu-mir
<tvoss> doko, but he might well be offline
<apw> is compiz crashing on login on utopic a known issue
<doko> tvoss, ok, added my comment to the merge proposal (I think this is bikeshedding now)
<tvoss> doko, thanks
<apw> jodh, hey ... upstart as a user session, where are log job logs for those jobs ?
<jodh> apw: $XDG_CACHE_HOME/upstart/*.log (documented in init(5)).
<jodh> apw: or ~/.cache/upstart/ if var not set.
<jibel> mvo, bdmurray langpacks for ja, id, eo and ug must be refreshed and SRUed in Precise in order to verify 1311396.
<apw> jodh, great thats them, trying to work out why unit7 is just dieing in a heap on me
<seb128> Noskcaj, dholbach: hey, your libgtop update has a soname change without binary renaming, making rdepends not start, including unity :/
<seb128> shrug
<apw> ok ... yeah my desktop seems to be blank, because unity7 no longer starts, becase bamf-daemon doesn't start, because it depends on libgtop2-7, and
<apw> the latest migration replaces that with .10
<seb128> Noskcaj, dholbach_: is one of you around to sort that out? we need to get that resolved before more people upgrade and get a non working desktop, just wondering who should look at fixing it
<alexbligh1> I am trying to debug why debootstrap is doing something slightly different making a trusty image to a precise image. The symptom I'm seeing is /dev/net/tun does not exist after boot, yet it is mentioned in /var/log/udev, and udevadm trigger --action=add does not actually create it. Any ideas how /dev/net/tun is meant to be mknod'd and how to debug?
<Wiziledo> i need to know as a ubuntu user why nzoom.com tv on demand doesnt work
<seb128> k
<darkxst> Wiziledo, try #ubuntu
<Wiziledo> they won't give me voice because its not important as they put it
<seb128> I'm going to revert libgtop, fixing it the proper way would mean blocking the fix until all the rdepends are ported to 10
<seb128> Laney, ^ does that make sense to you?
<darkxst> Wiziledo, this channel is for development of ubuntu, not user support
<Wiziledo> ok
<Wiziledo> sorry :)
<Wiziledo> does mark shuttleworth come here?
<Laney> seb128: that seems fair
<seb128> k, doing that
<seb128> Laney, thanks
<xnox> Wiziledo: he holds qa sessions often during ubuntu online summits and user days, i don't think there is one comming up shortly, as we just finished online summit.
<Wiziledo> sweet, i look up to that guy
<Wiziledo> i get what he is doing
<seb128> Noskcaj, dholbach_: I uploaded a revert
 * Laney adds a hint to make it skip testing and get faster to release
<Wiziledo> Question, is ubuntu literally made in this channel?
<cjwatson> Most of the main developers are here, yes
<apw> seb128, and confirmed just reverting that library restored my desktop
<seb128> k
<seb128> https://launchpad.net/ubuntu/+source/libgtop2/2.30.0.is.2.28.5-0ubuntu1 is building
<apw> seb128, will test it once it has built
<seb128> thanks
<mvo> jibel: hm, is that somethat that pitti or dpm can help with? the langpack refresh for precsie for bug 1311396 i mean
<ubottu> bug 1311396 in update-manager (Ubuntu Trusty) "broken translations results in traceback in new release notification" [Undecided,Confirmed] https://launchpad.net/bugs/1311396
<Wiziledo> Are all developers paid?
<cjwatson> No
<milissa> http://adf.ly/pyduc
<Wiziledo> anyway I'm from NZ I'm a big fan of ubuntu just want to get our national TV website tv on demand to work lol
<Wiziledo> youtube works, just not national tv on demand
<Wiziledo> Also the desktop is dying
<darkxst> Wiziledo, many of the devs, like me are volunteers
<darkxst> Wiziledo, and as I said, this is not the channel for user support
<Wiziledo> oh thats awesome
<xnox> Wiziledo: there is a NZ ubuntu LOCO group http://loco.ubuntu.com/teams/ubuntu-nz/ there is an IRC channel #ubuntu-nz maybe you can find out more about the national TV website working on ubuntu there?
<pitti> mvo, jibel: yes, I can help with the SRU, if the translations fixed on LP for precise/saucy
<bluesabre> Hello sponsors, is anybody available to upload these packages to trusty-proposed to begin SRU verification?
<bluesabre> https://bugs.launchpad.net/ubuntu/+source/lightdm-gtk-greeter/+bug/1331871
<ubottu> Ubuntu bug 1331871 in lightdm-gtk-greeter (Ubuntu) "[SRU] Please backport lightdm-gtk-greeter 1.8.5 to trusty" [Undecided,New]
<bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
<ubottu> Ubuntu bug 1323405 in menulibre (Ubuntu Trusty) "[SRU] Please backport menulibre-2.0.4 to trusty" [Undecided,New]
<jibel> pitti, I checked indonesian and the fix is not in LP, so this SRU is invalid.
<dholbach> seb128, sorry - I was out for lunch
<dholbach> seb128, thanks a lot for your work on this - I'm sorry I didn't notice this when sponsoring :(
<seb128> dholbach, hey, no worry !
<dholbach> seb128, IIRC that's not the first time for them, right?
<seb128> dholbach, you mean not the first time Noskcaj has updates with issues?
<dholbach> no, libgtop not bumping the soname
<seb128> oh
<seb128> dholbach, they did bump the soname, Noskcaj just didn't rename the binary in the packaging to match the version
<dholbach> ohhhhh ok, then indeed I should have noticed this :-/
<seb128> like they did .7 -> .10 and the lib is still named lib7 and ships 10
<mlankhorst> dpkg -L libosmesa6 ;-) (on utopic, for historic reasons)
<bluesabre> hey dholbach, thanks for the endorsement :)
<dholbach> bluesabre, anytime
<bluesabre> if you get a free moment, do you think you can upload the lightdm-gtk-greeter and menulibre packages I have in the sponsor queue?
<bluesabre> (trusty-proposed_
<dholbach> bluesabre, I'm afraid I'm quite busy right now
<dholbach> ^ can anyone else help out a bit with sponsoring?
<bluesabre> ok, np. gotta run to work now, be back tonight
<shadeslayer> mvo: ping, I was wondering what the status of appstream is in ubuntu
<shadeslayer> and whether USC and Synaptic are going to move to it
<mpt> âDu har ikke lov til at redigere denne side.â
<mpt> I thought MoinMoin had stopped giving me error messages in random languages in 2009
<juliank> mpt: It just wanted to have some fun :)
<ev_> dobey: have you come across any good solutions for doing checkout rather than export in Tarmac's verify_command plugin, short of writing a new plugin? I'm just surprised no one has run into this as an issue before. Surely we can't be the only people populating version information from bzr?
<dobey> ev_: what issue?
<ev_> dobey: that tarmac does bzr export for verify_command, rather than bzr branch or bzr co. Our setup requires the branch information to be present, since we send that as part of a deployment of this code. Our tests then validate that.
<ev_> I could just bzr init as a hack around it, I suppose
<dobey> ev_: tarmac used to just run the tests in the checked out branch, but it was changed to doing an export to a temp dir for security, so that rogue branches can't commit themselves and such
<ev_> yeah, I can understand that motivation
<ev_> yeah, this bzr init should work
<ev_> sorry for disrupting you :)
<dobey> ev_: i think if the build system/tests requires .bzr to exist with valid data, then the build system/tests are broken. i'd have to look at what you're doing exactly to give better feedback/recommendation for how to do it better though.
<ev_> well, it's driving our integration tests
<ev_> which validate the deployment, which puts copies of the code under directories with the revno in the name
<ev_> so that we can switch between a few on production
<ev_> right now I have it running both the deployment and the tests under tarmac
<ev_> deployment to a temporary location, obviously :)
<dobey> i totally understand why you'd want to do that in an actual deployment
<dobey> hmm
<ev_> I don't think IS would like us doing CD with Tarmac
<ev_> sorry, continuous deployment. Hate acronyms.
<ev_> yeah, I'll hack around it for now
<dobey> i guessed that :)
<ev_> we don't have any tests that validate the bzr revno matches the other side
<ev_> so I can just fix this once we do :)
<ev_> though I guess we could just validate that as 0
<dobey> ev_: if you want to file a bug against the project this is for, and sub me to the bug, i can try to look at it sometime when i have some free time (which i have extremely little of lately)
<ev_> sure, will do
 * dobey wonders who to ping about debugging upstart jobs
<dobey> hmm, or maybe i can just stop the job and run it manually under gdb and it'll just do what i want to do
<alexbligh1> I'm having problems with systemd-udevd on 14.04 that didn't occur with udevd on 12.04. This is a debootstrap'd image. It appears not to be creating device nodes (specifically /dev/net/tun). As far as I can tell udev is matching the appropriate rule, but the node is not being created. udevadm test produces what I think is the expected result, but udevadm trigger does nothing. Details here: http://pastebin.com/4U
<alexbligh1> CGmXWx Any ideas?
<alexbligh1> Argh, URL is http://pastebin.com/4UCGmXWx
<Unit193> ari-tczew appears to have nuked the entire Ubuntu history in a changelog, and improperly re-enabled a feature by missing a build-dep: https://launchpadlibrarian.net/177154250/lightdm-gtk-greeter_1.8.4-0ubuntu1_1.8.5-1ubuntu1.diff.gz
<elopio> Hello!
<elopio> I need a core-dev to review a packaging change, here: https://code.launchpad.net/~elopio/address-book-app/qmltest1/+merge/221263
<xnox> elopio: looks good, can i use qmltestrunner against system installed address book app?
<xnox> elopio: are qmltests executed in jenkins with results publised on ci.ubuntu.com? if yes, then where?
<xnox> I wonder how to make that qmltests to be executed as dep8 test as well.
<elopio> xnox: you can't run against the installed because the qml import paths I'm using are like:
<elopio> ../../src/imports/ContactEdit
<elopio> xnox: and the tests are executed by jenkins on MPs, but not during the smoke tests, so not on ci.ubuntu.com
<elopio> xnox: I first tried making it an autopkgtest, but pitti recommended to it on the dh_auto_test
<elopio> xnox: on dep8, wouldn't it be better to run the autopilot tests?
<xnox> elopio: they way you did, it must be in dh_auto_test.
<xnox> elopio: dep8 would be in-addition, running against system app to satisfy the removal of the autopkgtests which are currently published on ci.ubuntu.com, until qmltests are also published there.
<elopio> xnox: I added an autopilot test that will be on ci.ubuntu.com and test the creation of a new contact.
<elopio> so I'm just removing the tests that are just duplicating some things from that more general test
<elopio> if on qml tests we check all the combinations that will enable the save button, on autopilot we can just assume that the save button will be enabled.
<elopio> but it will fail anyway if for some weird reason, this works while building the package but not while running the autopilot tests.
<xnox> elopio: i see.
<arges> slangasek: hey... trying to figure out bug 1274444. Do you know if there is a simple way to ensure that kernel messages with <N> n>=12 are logged with rsyslog/whatever? $ConsoleLogLevel 14 doesn't seem to do anything
<ubottu> bug 1274444 in linux (Ubuntu) "echo string to /dev/kmsg fails to appear on /var/log/syslog" [Medium,In progress] https://launchpad.net/bugs/1274444
<slangasek> arges: I really don't know, sorry
<slangasek> arges: maybe pitti knows the interfaces here?
<arges> slangasek: figured id ask before digging even more. i've been playing with the settings but not being very successful
<smoser> infinity, around ?
<smoser> some folks are interested in getting a d-i build with linux-keystone for trusty
<smoser>  https://launchpad.net/ubuntu/+source/linux-keystone
<smoser> expecting that to land at
<smoser>  https://code.launchpad.net/~smoser/maas/maas-ephemerals-v2
<smoser> er..
<smoser>  http://ports.ubuntu.com/ubuntu-ports/dists/trusty-proposed/main/installer-armhf/current/images/
<smoser> i'm not familiar with how that request is made or how that is done.
<smoser> oh. and its canada day, and you're not here. rightfully so.
<smoser> slangasek, ^ ?
<stgraber> smoser: do you have a d-i branch adding support for that?
<smoser> "i'm not familiar with how that request is made or how that is done."
<smoser> :)
<smoser> so, no.
<smoser> dannf, maybe has done that in the past?
<stgraber> smoser: adding a new ARM board/platform to d-i isn't extremely difficult (we reworked some of that last cycle to be simpler) but you typically want to send a merge proposal for d-i adding the required dependencies and code to generate a bootable image for your target and you likely also need a matching change to flash-kernel and the libdebian-installer
<stgraber> I'm not familiar with this specific target, so could be that some of those bits have been done but not others
<smoser> stgraber, thanks.
<stgraber> all of that is obviously better done by someone who has access to the actual hardware as all of those bits require some knowledge about how the bootloader is setup, what kind of storage it uses and its devicetree dtb file (and whether it needs to be appended to the kernel or resides in flash)
<dannf> smoser: manjo has MPs for that iirc - at least for the components, if not for d-i itself
<dannf> stgraber: ^
<smoser> dannf, thanks
<smoser> manjo, ^
<smoser> i just hit 'send' on the mail that started me bothering people. i'm going to be gone soon for a few days.
<dannf> well, i don't see a d-i MP - but i know he's produced one for testing
<manjo> smoser, I have a d-i building in a PPA for keystone ... I can submit to you ... install images are in http://ppa.launchpad.net/marcola-team/ppa/ubuntu/dists/trusty/main/installer-armhf/current/images/keystone/netboot/
<dannf> manjo: can you propose an MP for d-i? infinity said he'd take a look at MPs by next week, i owe him a list
<manjo> dannf, ack
<robert_ancell> kentb, do you know the correct URL for efibootmgr?
<robert_ancell> Is it https://github.com/vathpela/efibootmgr?
<kentb> robert_ancell, yep. that's  it.
<robert_ancell> kentb, ta
<kentb> np
<directhex> infinity, any idea on ppc64el mono status? upstream indicate they haven't seen anything relating to it
<directhex> (which could be an error)
<infinity> directhex: I'll have to talk to the IBMers about where their upstream submissions have (or haven't) gone.
<directhex> infinity, thanks
<infinity> dannf: If you get me d-i MPs (libdi and d-i itself), I can blind review them.  I've done more than enough new platforms in d-i by now to know if it'll work without even trying (that might be a bit of a sad statement...)
<dannf> manjo: ^
<dannf> the libd-i one is there- https://code.launchpad.net/~manjo/ubuntu/utopic/libdebian-installer/HP-m800 - https://code.launchpad.net/~manjo/ubuntu/trusty/libdebian-installer/HP-m800
<manjo> infinity, ack
<manjo> infinity, there is an MP For libdi already
<manjo> infinity, I will MP di soon
<infinity> dannf: Great.  Add it to that email full o' MPs that I asked for, so I don't lose it in holiday backscroll. ;)
<dannf> infinity: will do
<infinity> <3
<LeonBo> I've debbuild the libav package to add some extra encoders
<LeonBo> The original version is 6:9.13-0ubuntu0.14.04.1
<LeonBo> My version is 6:9.13-0ubuntu0.14.04.1~ppa1
<LeonBo> When installing the ~ppa1 version I get the warning: 'dpkg: warning: downgrading libavcodec54:amd64'
<infinity> LeonBo: That makes your version lower than the archive version.
<LeonBo> Yeah I thought so
<infinity> LeonBo: "~" means "just before".  As in, -1~foo is "just before -1"
<LeonBo> OK
<infinity> LeonBo: You might want something like -0ubuntu0.14.04.1+ppa1
<LeonBo> Should I just use +ppa1 then?
<LeonBo> infinity: you were quicker
<LeonBo> :)
<infinity> LeonBo: Or -0ubuntu0.14.04.1+leon1 so it's obvious to people where it came from.
<LeonBo> infinity: awesome, I'll use that then
<LeonBo> And is there a way to keep my version always higher?
<LeonBo> So If 9.14 of the package is released, my version isn't automatically removed
<infinity> LeonBo: Yeah, you could bump the epoch, but you may well not want that.
<infinity> LeonBo: Other packages that have versioned deps will break a bit in that case, and I wouldn't recommend it.
<infinity> LeonBo: Since you're building a package that *is* 6:9.13, if something in the archive depends on >> 6:9.14, you don't want you package to satisfy the dep by accident, you want to update your package.
<LeonBo> Yeah, you're right
<LeonBo> So release my + version
<LeonBo> And then pin it?
<infinity> LeonBo: That's the saner way to go, yeah.
<infinity> LeonBo: Then when apt starts whining about "Not upgrading 4 packages", you know you need to update your PPA. ;)
<LeonBo> Exactly
<LeonBo> Thanks a lot!
<ari-tczew> cjwatson: I guess there's existing problem again with M-o-M. It hasn't been updated since a few hours. "Generated at 2014-07-01 15:43:30 UTC."
<Unit193> ari-tczew: You seem to have nuked the Ubuntu changelog of lightdm-gtk-greeter (Used to be an Ubuntu package, later Debian picked it up.)  As well as missing a build-dep on ido.
<slangasek> arges: bug #1274444> what do you mean, "pending merge"?
<ubottu> bug 1274444 in rsyslog (Ubuntu) "echo string to /dev/kmsg fails to appear on /var/log/syslog" [Medium,In progress] https://launchpad.net/bugs/1274444
<cjwatson> ari-tczew: thanks, hopefully fixed
<ari-tczew> Unit193: I've dropped the whole changelog before initial release of Debian because I think it's not needed so much keeping a lot of changes in d/changelog as there are explanation of delta in newer releases.
<ari-tczew> Unit193: B-D on libido3-0.1-dev is dropped because the reason of that addition wasn't mentioned in d/changelog and package builds fine without this one.
<Unit193> It'll build fine without libindicator-dev too. :P
<ari-tczew> Unit193: can I ask, is there any special reason to that investigation?
<Unit193> ari-tczew: Normally some indicators need that, icon related.
<Unit193> By default it's enabled and checks for it.
<ari-tczew> Unit193: if this B-D is really needed, please fill a bug, attach a patch and subscribe to ~ubuntu-sponsors.
 * Unit193 sighs.
#ubuntu-devel 2014-07-02
<Bluefoxicy> you guys should publish something on Google Docs next time you need animal names
<Bluefoxicy> holy crap.
<Bluefoxicy> there are 42 people looking at my spreadsheet now
<Bluefoxicy> Anonymous aardvark
<Bluefoxicy> Anonymous ibex
<Bluefoxicy> what the hell is a Quagga?
<pitti> Good morning
<rsalveti> pitti: hey, maybe you know better and is also able to help me :-)
<rsalveti> basically, https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/ is failing for amd64
<rsalveti> seems like the same failure also happened on the testrun number 55
<pitti> rsalveti: hm, that looks like an "honest" failure, or do you think it's an infrastructure problem?
<pitti> rsalveti: I can retry the test, it just seems to be a bit flaky?
<rsalveti> pitti: yeah, seems so
<rsalveti> pitti: that would be nice, thanks
<pitti> rsalveti: looks better now
<rsalveti> pitti: great, thanks so much
<pitti> mvo: argh, one more :( https://launchpadlibrarian.net/179013440/buildlog_ubuntu-utopic-amd64.python-apt_0.9.3.8_FAILEDTOBUILD.txt.gz
<pitti> mvo: I gave up enforcing PEP-8 during builds (only run with || true); I run them on release, but found that one runs into eternal pain when doing backports, or with newly appearing pep8 versions
<dholbach> good morning
<mvo> pitti: thanks, let me have a look
<pitti> mvo: I suppose it built in Debian, so that's weird
<pitti> oh
<pitti>  pep8 | 1.4.6-1.1 | sid     | source, all
<pitti>  pep8 | 1.5.6-0ubuntu1  | utopic         | source, all
<pitti> we are ahead
<mvo> pitti: hrm, hrm, I will fix it, no big deal, but maybe pep8 could start with warning instead of errors for newly added checks
<mvo> and only make it a hard error after e.g. 6 month or so
<seb128> hum
<seb128> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-system-settings
<seb128> "autopkgtest for ubuntu-system-settings-online-accounts 0.3+14.10.20140530.1-0ubuntu1: Regression (Jenkins: public, private) "
<seb128> but the jenkins link has green tests?
<seb128> is that going to clear itself on next run?
<pitti> seb128: yes, I just retried it (flaky autopilot test)
<seb128> pitti, thanks
<pitti> seb128: see https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/71/ that's what it failed on
<seb128> some autopilot issues, I see
<pitti> it uses select_single(), probalby needs a wait_select_single() or so
<seb128> mardy, ^ is that a known issue?
<mardy> seb128: no, a bug report would be welcome :-)
<seb128> mardy, k, thanks
<seb128> pitti, you didn't open one I guess?
<smb> Hm, interesting... not at all related to anything said before. Just had this mild wtf moment when I accidentally (lack of caffeine I guess) tried to "apt-get install ^server" instead of "server^" in Utopic. The command did not respond an equivalent of "what the heck are you thinking" but offered to install apache.
<pitti> seb128: no, I didn't
 * seb128 opens one
<seb128> mardy, pitti: https://bugs.launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/+bug/1336650
<ubottu> Ubuntu bug 1336650 in ubuntu-system-settings-online-accounts (Ubuntu) "some autopilot tests seem to be flaky" [Undecided,New]
<mardy> seb128: thanks
<seb128> yw!
<pitti> xnox: I finally have some time again to work on sysvinit/systemd; sorry to ask again, but I didn't follow this at all: what's left to do for starpar? do you still have the list of tasks which need to be converted to jobs?
<LocutusOfBorg1> sil2100, you there?
<LocutusOfBorg1> is that "original maintainer" field really needed in lucene++?
<LocutusOfBorg1> you have a lintian warning
<sil2100> LocutusOfBorg1: hi! I can remove it, no problem - I guessed this wouldn't be a big problem?
<mardy> I have a serious issue with bzr (bug 1336682); are there any bzr experts online?
<ubottu> bug 1336682 in bzr (Ubuntu) "bzr crashed with KeyError in get_raw(): '66531594d8745e0ae7bdeeffea2a6c51c0506cf3'" [Medium,New] https://launchpad.net/bugs/1336682
<Noskcaj> mardy, #bzr might have better answers
<LocutusOfBorg1> sil2100, the package will go through the new queue, so keeping it lintian free avoids many headaches to ftp-masters ;)
<sil2100> LocutusOfBorg1: ok, let me remove it in a moment and re-push ;)
<LocutusOfBorg1> I already asked to a sponsor to upload it ;)
<LocutusOfBorg1> thanks!
<sil2100> btw. did you try this package? Since I had to rebase it on a newer version actually
<LocutusOfBorg1> (the sponsor will take some hours to upload BTW)
<sil2100> Since this was the easiest way to getting rid of waf
<LocutusOfBorg1> no, I didn't try it
<apachelogger> mvo, pitti, xnox: are there any plans to adopt appstream in the forseeable future? came just up for kubuntu https://lists.ubuntu.com/archives/kubuntu-devel/2014-July/008540.html
<sil2100> LocutusOfBorg1: the previous version had waf in its tarball, removing it on get-orig-source was really nasty - and they removed waf in the latest version
<xnox> pitti: here are the next steps required to enable startpar https://wiki.ubuntu.com/SystemdMigration
<xnox> pitti: i still think we shouldn't have task<->init in standard ubuntu
<mvo> apachelogger: we currently have no specific plans for this, there will be apt support to download additional indexes (like app-stream data) though
<LocutusOfBorg1> wonderful sil2100  ;)
<LocutusOfBorg1> I'm building it right now
<apachelogger> mvo: so the idea is to distribute the appstream data via the repo metadata?
<mvo> apachelogger: my understand is that this is the goal, yes. the data is gathered at the archive server via some mechanism (package inspection e.g. at build time). then a yaml file is generated and placed next to the Packages file. this is something that I want to support with apt, but there is no plan about integrating the generation of the data into archive.ubuntu.com right now
<mvo> apachelogger: I think noone is opposed and we would certainly welcome help, e.g. via support in apt-ftparchive or launchpad
<apachelogger> mvo: ok, thanks for the info :)
<mvo> yw
<LocutusOfBorg1> sil2100, my sponsor asks he can add me as uploader, so he is sure somebody will take care of the package ;)
<LocutusOfBorg1> Because I'm already a DM
<GunnarHj> Hi infinity
<LocutusOfBorg1> hi cjwatson is MoM broken again?
<LocutusOfBorg1> https://launchpad.net/ubuntu/+source/gccxml
<cjwatson> Amazingly, yes.
<LocutusOfBorg1> and insighttoolkit4 needs the new version ;)
<LocutusOfBorg1> thanks
<cjwatson> Although I don't know why you keep referring to Launchpad to support reports of MoM being broken.
<cjwatson> I've poked it.
<LocutusOfBorg1> where can I see MoM?
<cjwatson> merges.ubuntu.com
<cjwatson> In this case, it'll still need mitya57 to actually do the merge.
<LocutusOfBorg1> I know that page but where is the last run time?
<LocutusOfBorg1> just look at the time on the file?
<mdeslaur> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: ikepanhc, mdeslaur
<cjwatson> LocutusOfBorg1: End of https://merges.ubuntu.com/main.html
<LocutusOfBorg1> wonderful thanks
<ikepanhc> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: mdeslaur
<mdeslaur> caribou: have you managed to test your openssl098 package?
<caribou> mdeslaur: no, have no clue on how to do it :-/
<mdeslaur> caribou: yeah, not an easy thing to do...let me think about it a few minutes
<slickymasterWork> dholbach: ping
<dholbach> slickymasterWork, pong
<slickymasterWork> hi, I pinged you because of this -> https://code.launchpad.net/~ubuntu-branches/ubuntu/trusty/xubuntu-docs/trusty-201403200923/+merge/211890
<slickymasterWork> I'm Xubuntu Documentation Lead and am wondering why it didn't get merged
<slickymasterWork> can you cast any light on it?
<dholbach> slickymasterWork, I don't understand
<dholbach> the branch you're talking about has this as the content of d/changelog: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/trusty/xubuntu-docs/trusty-201403200923/view/head:/debian/changelog
<slickymasterWork> what in particular don't you understand dholbach?
<dholbach> so that's 14.04.0
<dholbach> current in trusty is 14.04.1
<dholbach> so what would you like to see in trusty?
<slickymasterWork> yes, but it seems it didn't get merged to 14.04.0, did it?
<dholbach> slickymasterWork, https://launchpad.net/ubuntu/+source/xubuntu-docs/+publishinghistory
<dholbach> slickymasterWork, 14.04.0 landed in trusty 2014-03-21 13:10:11 CET
<slickymasterWork> yeah, I see it
<slickymasterWork> so, that MP is to forget, right?
<infinity> Yeah.  I'll just delete it.
<slickymasterWork> ok, thanks for that infinity
<slickymasterWork> and thanks for the heads up dholbach
<dholbach> anytime
<brendand> is there any equivalent of paramiko in python3?
<geser> brendand: Python3 support was added to paramiko with release 1.13
<brendand> geser, but there's no python3-paramiko package in ubuntu
<geser> brendand: not yet, paramiko 1.14.0-2 is stuck in utopic-proposed with DEPWAIT till python3-ecdsa gets promoted to main
<brendand> geser, oh interesting, thanks
<brendand> now the question is who i need to follow up with to get python3-ecdsa promoted
<geser> someone needs to file a MIR for it (didn't happen yet)
<geser> brendand: https://wiki.ubuntu.com/MainInclusionProcess if you want to start it
<barry> pitti: ping
<pitti> hello barry
<brendand> should MIRs be filed against ubuntu itself?
<LocutusOfBorg1> sil2100, you don't seem to install Lucene.h headers file
<arges> slangasek: This one: https://merges.ubuntu.com/r/rsyslog/REPORT
<brendand> or against the package to MIR?
<geser> brendand: the package itself
<geser> brendand: see e.g. bug #1333686 as an example
<ubottu> bug 1333686 in python-rednose (Ubuntu) "[MIR] python-rednose" [High,Fix committed] https://launchpad.net/bugs/1333686
<LocutusOfBorg1> sil2100, also Config.h is missing
<brendand> geser, it says something about adding the package to a seed. do i need to do that?
<geser> brendand: I don't think so (in this case) as paramiko will keep it in main (once it gets promoted)
<GunnarHj> infinity: ping?
<infinity> GunnarHj: Pong?
<GunnarHj> infinity: Hi Adam. ubuntu-docs is in the trusty queue, and it needs to be built very soon to prepare for an update of trusty translations. Any chance you can approve it?
<slangasek> arges: well, that only means that there's a merge /outstanding/, not that it's /pending/ :)
<infinity> GunnarHj: Looks good.
<sil2100> LocutusOfBorg1: huh, ok, that's odd, let me take a look on what changed then
<arges> slangasek: ok, then outstanding is what I meant. So in this case, should I wait for that merge (or work on it), before applying that patch... and is that patch something that makes sense in your case?
<GunnarHj> infinity: Yeah, the same thing was successfully built in utopic so it should. ;)
<infinity> GunnarHj: Accepted.
<slangasek> arges: I don't think it should be tied to the merge at all; the fact that the merge is outstanding doesn't imply any particular timeline on it happening
<slangasek> arges: you can talk with xnox about whether he's planning to do the merge, or if you should take it over?
<arges> ok. xnox ^^^ are you planning on doing the rsyslog merge; I have a patch for rsyslog and want to know if I should wait/help out/or just patch the current version.
<GunnarHj> infinity: Thanks! Now, when I caught an SRU team member... Could you also read the last comment at bug 1308771 and give us your opinion?
<ubottu> bug 1308771 in openoffice.org-hyphenation (Ubuntu Trusty) "Update Swedish spellcheck and hyphenation dictionaries" [Low,Triaged] https://launchpad.net/bugs/1308771
<xnox> slangasek: arges: let me look.
<xnox> arges: i think you should upload the patch. Last proper merge was done by slangasek and that was a jump from 5.8.11-2 to 7.4.4-1ubuntu1. And it's now a jump all the way to 8.2.2-3
<xnox> it's defiantly not a pending merge.
<infinity> GunnarHj: I have no issues with the two new binaries.  New lang-specific binaries pop up all the time in SRUs of langpacks and firefox, for instance.
<infinity> GunnarHj: Does this affect any *other* packages though (like, say, langpacks) that need to adjust deps?
<xnox> slangasek: would you be interested in merging rsyslog ? =) (i can try asking, can't I?! =)))))) )
<arges> xnox: whats the difficulty wiht the merge? looking at the report didn't seem too bad
<slangasek> xnox: heh, not interested, no :)
<xnox> slangasek: ack.
<GunnarHj> infinity: No, it's not related to langpacks at all. It's language specific language aids for libreoffice. But thank, that's what we wanted to know.
<infinity> GunnarHj: In fact, how do these hyphen-* packages get installed?  I have hyphen-en-us installed, but nothing seems to depend on it.
<cjwatson> arges: last big merge broke the world in some interesting ways (see 7.4.4-1ubuntu2), so just be careful
<arges> cjwatson: gotcha
<arges> so probably be better to not do it at this point in the U cycle
<xnox> arges: newing or splitting new deps; figuring out splits of -doc packages; i think systemd support stayed the same but need re-verification; plus testing to not break the world after last time...
<GunnarHj> infinity: They are simply added to a location where libreoffice will find them.
 * xnox meant M.I.R.ing not newing
<infinity> GunnarHj: Err, what?  I mean, how do the packages end up installed.
<arges> xnox: ok. I'll just patch the version in U : ) thanks
<GunnarHj> infinity: They are pulled by pkg_depends in language-selector if that's what you mean.
<infinity> GunnarHj: Okay, so does language-selector need updating for this?
<GunnarHj> infinity: No.
<infinity> GunnarHj: Alright, that's what I was asking.
<infinity> GunnarHj: The new binaries aren't an issue at all, IMO.
<GunnarHj> infinity: Excellent, thanks!
<LocutusOfBorg1> sil2100, the first question was: can I comaintain the package? my sponsor would really like to see me as uploader
<bdmurray> pitti: I've updated bug 1336565
<ubottu> bug 1336565 in apport (Ubuntu) "apport-retrace generates a different StacktraceAddressSignature depending on retracing architecture" [Low,Fix committed] https://launchpad.net/bugs/1336565
<LocutusOfBorg1> sil2100, ---> https://github.com/luceneplusplus/LucenePlusPlus/commit/994f03cf736229044a168835ae7387696041658f
<pitti> bdmurray: ah ok, so it basically matters in that "rebuild broken/absent SAS" case
<pitti> bdmurray: so I believe that fix ought to suffice?
<bdmurray> pitti: why is part of uname included at all? wouldn't that create separate buckets for x86_64 and x86?
<pitti> bdmurray: yes, because addresses are necessarily different between architectures
<pitti> bdmurray: we don't want to accidentally identify an arm with an x86 signature (unlikely of course, but possible)
<pitti> bdmurray: but even without the arch you'll have separate buckets per arch
<pitti> in many cases even several buckets per error on one arch, as there's apparently some variability in them
<pitti> so we map many SAS to one error
<bdmurray> pitti: okay, understood. given this issue though it may be possible that we error tracker buckets that have a different SAS than the bugs in Launchpad, right?
<pitti> bdmurray: yes, that's possible
<pitti> bdmurray: but anyway, that fix to read it from the report's Uname field (if present) should help with that, right? I'll upload that ASAP
<pitti> as that's (hopefully) always present from the original device
<bdmurray> pitti: thinking about it more the error tracker was rejecting reports without a SAS so the count should be very small / not worth cleaning up
<pitti> bdmurray: oh, right
<bdmurray> pitti: so, yes switching to Uname sounds good to me
<sil2100> LocutusOfBorg1: sorry, had a meeting - anyway, I'm fine with co-maintaining it with you I guess ;) Let me incorporate this patch as a quilt patch then
<bdmurray> pitti: by the way did you check to see if your gdb change is still in the debian version of gdb?
<sil2100> LocutusOfBorg1: doing a test build of it now, will publish afterwards
<pitti> bdmurray: no, I didn't check yet
<LocutusOfBorg1> sil2100, I'm also testing it
<LocutusOfBorg1> and building
<mdeslaur> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<sil2100> LocutusOfBorg1: looks good to me
<infinity> pitti: Err, skimming backscroll, but uname shouldn't relate to backtraces at all.
<sil2100> -rw-r--r-- root/root      1845 2014-07-02 17:01 ./usr/include/lucene++/Config.h
<sil2100> -rw-r--r-- root/root      9534 2014-04-19 20:26 ./usr/include/lucene++/Lucene.h
<sil2100> LocutusOfBorg1: ok, I'm pushing the source package now :)
<pitti> infinity: not symbolic stack traces, but to the address signatures; they are already highly arch specific; this just makes it slightly easier to see which arch they are coming from
<pitti> (and avoids false identifications)
<infinity> pitti: Confusing dpkg/userspace arch and kernel arch is entirely wrong.
<pitti> infinity: ah, good point; so they should probably be preceded with the affected package arch
<infinity> pitti: If I have i386 packages crashing on an x86_64 kernel, they shouldn't be bucketed as x86_64 crashes.
<sil2100> LocutusOfBorg1: uploaded a new version with the patch - btw. should I also add you somewhere in case you want to co-maintain?
<infinity> pitti: I think the kernel arch is *interesting* supplementary data, but shouldn't affect the signature, if that makes sense?
<pitti> infinity: yes, it does
<infinity> pitti: ie: When I drill down, it'd be useful to note that a certain crash only happens on armhf *if* the kernel is actually aarch64, but generally, that won't be true, so shouldn't be involved in bucketing.
<LocutusOfBorg1> sil2100, yes please
<LocutusOfBorg1> Uploaders: Gianfranco Costamagna <costamagnagianfranco@yahoo.it>
<pitti> infinity: the bucketing only happens on the symbolic (retraced) stack traces AFAIK; the SAS is mostly just for client-side dupe detection, so it's not vitally important; but it's still cleaner that way, I'll change it
<LocutusOfBorg1> also the debian/control is wrong
<LocutusOfBorg1> there is a comma in the last dependency
<LocutusOfBorg1> and moreover if you build in a clean environment you get a missing subversion failure
<pitti> trailing commas are fine
<LocutusOfBorg1> trailing commas are "ugly" :p ;)
<pitti> they help to reduce diff noise when adding new build/bin deps
<sil2100> LocutusOfBorg1: they are? Oh, we're actually adding them on purpose ;) It makes the diffs smaller when you add new dependencies
<pitti> but matter of taste, I gues
<pitti> s
<LocutusOfBorg1> true ;)
<LocutusOfBorg1> yes, but you still have the subversion problem
<LocutusOfBorg1> I'm looking at it
<sil2100> LocutusOfBorg1: ok, let me build it in my chroot then to see the same
<LocutusOfBorg1> ./CMakeLists.txt:find_package(Subversion REQUIRED)
<LocutusOfBorg1> what the hell?
<sil2100> uh, now that's something I didn't expect - why does it need it suddenly?
<LocutusOfBorg1> looking at it right now, btw I sent two pull requests upstream with your changes (the two patches)
<LocutusOfBorg1> oh yes, CMakeExternal.txt
<LocutusOfBorg1> mmm we can add libgtest-dev as b-d
<bdmurray> stgraber: I'm looking at https://errors.ubuntu.com/problem/62db45e470d69292cef07c5bed380a0ddc24e13d which you'd emailed me about as it was identified as a regression.  Looking at a few of the instances in Dependencies they seem to have the new version of cgmanager.
<stgraber> bdmurray: hmm, yeah, I see that. That doesn't make any sense though...
<stgraber> bdmurray: are the dependencies captured at time of crash or time of report?
<bdmurray> stgraber: probably the latter, let me double check
<bdmurray> stgraber: at time of report
<stgraber> bdmurray: ok, that could explain it then. Because the only way we could get that crash with the right cgmanager being installed is if the cgmanager SRU was wrong and the symbol wasn't present, but if that was the case, it'd be failing for absolutely everyone...
<stgraber> ok, so it seems likely that those people upgraded the rest of their system between the time lxc-ls stacktraced and the time they sent the report to errors, meaning that those systems are now fine
<bdmurray> so then we'd expect to see a specific SystemIdentifier one time only?
<stgraber> assuming people upgrade the rest of their system when they hit the crash the first time around, yes
<sil2100> LocutusOfBorg1: doing a test build ;)
<sil2100> Thanks for the pointers! I've got so many things on my list today so it's taking a bit longer, sorry for that
<bdmurray> stgraber: okay, overridden
<dobey> seb128, mvo: hi, i'm wondering what i'm missing in my lxc for clicks to be installable there. i'm getting this error when i try to pkcon install-local a package:
<dobey> Fatal error: MIME type 'application/x-click' not supported /home/dobey/.local/share/ubuntu-download-manager/Downloads/com.ubuntu.developer.matiasb-testing.qr-code_0.3.1_all.click
<michagogo> What does "posting moderated" mean on https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel?
<sarnold> michagogo: emails to the list are quite often held for a human to review the post and make sure it isn't spam
<michagogo> Got it.
<michagogo> How long do messages generally take to get approved?
<sarnold> michagogo: it may be that ubuntu members are unmoderated or something, but all mine are moderated and normally it just takes a few hours before they go through :)
<milina> http://adf.ly/q1fx1
<mvo> dobey: do you have the packagekit-plugin-click installed?
<dobey> mvo: possibly not. i have aptcc installed
<dobey> that helped
<dobey> mvo: now i get Fatal error: Failed to obtain authentication.
<mvo> dobey: hm, thats odd, is there a policykit agent installed? just a bit of a stab in the dark (if that expression makes sense)
<mvo> dobey: clicks should be installable without though - and packagekit depends on policykit so that should be available
 * mvo scratches head
<dobey> mvo: i have policykit-1-gnome installed
<dobey> hmm
<dobey> installed policykit-desktop-privileges (since it's installed on the phone), but didn't help
<mvo> dobey: I haven't seen this error yet, I found /usr/lib/packagekit/packagekit -v helpful
<mvo> dobey: I assume you have "unity8-desktop-session-mir" installed also?
<dobey> i don't
<dobey> is that required?
<dobey> hrmm, didn't help to install it either though
<mvo> dobey: hm, so no :/
<mvo> dobey: anything useful from packagekitd -v ?
<dobey> nothing obvious
<dobey> 14:39:57	PackageKit          trying to open database '/var/lib/PackageKit/transactions.db'
<dobey> maybe that
<mvo> dobey: hm, so this is a lxc/utopic? I can try to create one and play around with that tomorrow morning (in ~10h or so) if the problem persists
<dobey> mvo: yes a utopic lxc
<mvo> dobey: ok, thanks. so please send me a short mail if the issue is found, otherwise I will look for it in my morning
<dobey> ok
 * mvo calls it a day
<dobey> xnox: seen http://pastebin.ubuntu.com/7738360/ before when cross-compiling in sbuild?
<cjwatson> dobey: Is it possible you're missing packagekit-plugin-click?
<dobey> cjwatson: i've since installed it
<cjwatson> dobey: Also see pk-plugin/README in the click source
<cjwatson> dobey: You might need to tweak the .pkla if policykit doesn't have enough of a connection to your desktop to be able to prompt you, which it might not
<manjo> cjwatson, is there bzr branch debian-installer for utopic ?
<dobey> cjwatson: all it should need is a DISPLAY right? though i'm not sure what it would prompt me for. i don't get a prompt on the phone
<cjwatson> manjo: lp:~ubuntu-core-dev/debian-installer/ubuntu
<manjo> ah
<manjo> thanks a ton!
<cjwatson> dobey: You don't get a prompt on the phone because of that .pkla
<cjwatson> I expect we shouldn't prompt, but we'll need to put the glue in place for that.  In the meantime you can hack it with a local pkla as per that readme
<cjwatson> adjusting the username
<dobey> cjwatson: is that some special tweak we do during the image build that isn't a part of the standard packages?
<dobey> oh it has the username in it? ok
<brendand> i'm trying to get a mir in and i've been asked to subscribe 'the team in Ubuntu which will look after the package' - how can i establish which team that should be?
<cjwatson> Yup, it's a phablet-specific hack in click for now, ugly
<cjwatson> Not proud
<dobey> ah, got past that error now
<dobey> thanks cjwatson
<dobey> but now i just get the apparmor hook failing, because apparmor
<jjohansen> dobey: what kind of lxc container are you running it in?
<dobey> jjohansen: utopic
<dobey> host is trusty
<jjohansen> dobey: okay, and its a bog standard lxc container?
<dobey> jjohansen: afaik yes. did a plain lxc-create to build it
<dobey> jjohansen: added bind mount for /tmp/.X11-unix so i could display things in X
<dobey> jjohansen: is nested apparmor supposed to work now?
<jjohansen> dobey: okay, so its using external confinement which is causing the problem. Nested apparmor does NOT work atm. It is being worked on but not ready yet
<dobey> jjohansen: right. that's what i thought
<jjohansen> dobey: you could remove or disable the lxc profiles
<dobey> jjohansen: anyway to just disable it inside the container?
<jjohansen> dobey: uhmm no, not yet. there are tests in the initscripts to not load profiles inside lxc, but other parts aren't that smart.
<jjohansen> dobey: it is possible to provide a custom kernel, but even that requires something setting up the apparmor policy namespace to tell the kernel it isn't there
<jjohansen> dobey: another option is to disable the lxc apparmor profile, and setup an apparmor policy namespace for the container. And then apparmor will work within the container
<dobey> i just put a sys.exit(0) in the script that was failing for now
<dobey> it let the package install at least
<Noskcaj> Is there any reason elementary hasn't been moved to -release?
#ubuntu-devel 2014-07-03
<hyperair> ooh, gnome-terminal recognizes "LP: #XXXXXXX" as a bug link!
<hyperair> wonderful!
<hyperair> â¥
<Unit193> 0_o
<hyperair> yeah so you can ctrl+click it to open the launchpad page
<hyperair> really nice
<hyperair> if only it recognized BGO as well
<pitti> Good morning
<Unit193> pitti: Hello!
<pitti> hey Unit193, how are you?
<Unit193> I'm alive, I checked.
<pitti> TheMuso: do you still use a BT headset? it seems mine still works with hifi playback (A2DP), but not any more with telephony duplex (HSP/HFP); I can configure the profile, but I don't hear anything and the mike is dead too
<RAOF> pitti: That's my experience also; I mentioned this to cyphermox_ at the sprint and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1324790 was the result.
<ubottu> Ubuntu bug 1324790 in linux (Ubuntu) "Bluetooth problem with Parrot Zik headphones" [Medium,Incomplete]
<pitti> RAOF: ah, thanks
<RAOF> pitti: My problem might be specific to my hardware, of course :)
<pitti> RAOF: yeah, I don't see these kernel error messages
<seb128> shrug, looking at unity8/ubuntu-system-settings in proposed, there is quite some transition ongoing with gnutls28
 * seb128 wonders why ubuntu-system-settings is blocked in there
<seb128> wth with http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-settings-components
<seb128> "qtdeclarative5-ubuntu-settings-components/i386 unsatisfiable Depends: qtdeclarative5-ubuntu-ui-toolkit-plugin (>= 0.1.48) "
<seb128> that version is in utopic
<seb128> let's see if it sorts out itself at the next run
<seb128> does anyone know if the source of queuebot is public?
<seb128> stgraber, ^
<popey> Laney: https://bugs.launchpad.net/ubuntu-website-content/+bug/933187 does that still need to be private?
<ubottu> Error: ubuntu bug 933187 not found
<seb128> (ignore my britney comments/questions from earlier, things sorted out by themself, seems to be down to "ubuntu-ui-toolkit-gles needs an update")
<doko> jamespage, I'm looking at the libunwind merge,
<doko> libunwind (1.1-2ubuntu2) saucy; urgency=low
<doko>   * d/patches/20130803-known_test_failure_to_XFAIL_TESTS.patch: Drop
<doko>     run-coredump-unwind and run-coredump-unwind-mdi from XFAIL_TESTS.
<doko> do you remember why you did drop these?
<doko> hmm, re-adding it, and I get an XPASS ... :-/
<Laney> popey: don't know, that is the default policy of the project
<Laney> ask the owner
<jamespage> doko, oh - there is a note in the README.source about that
<jamespage> doko, you can build in a local schroot without disabling apport first
<jamespage> can/can't rather
<doko> ahh, ok
<jamespage> doko, the test requires a core dump to be generated which gets caught :-)
<pitti> apport still writes core files though, is that broken somehow?
<pitti> (when ulimit -c enables them)
<xnox> dobey: it found pkg-config once, but not the second time. usually that happens if PkgConfig module is included multiple times, without multi-arch defining modules first.
<xnox> dobey: what project/package is that from?
<heftig-z> When maintaining a fork of an Ubuntu package, what should the version number look like? Should I just append another "~foo1"?
<heftig-z> Assuming I want it to be > the Ubuntu package but < the next release of that package
<seb128> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: seb128
<flexiondotorg> Morning.
<flexiondotorg> How often does utopic sync with Debian unstable at the moment?
<xnox> flexiondotorg: it's in continious autosync mode at the moment. But debian updates it's archive only 4 times a day. Are you after some particular package?
<seb128> mlankhorst, hey, could you review the change on https://code.launchpad.net/~albertsmuktupavels/xorg-server/lp-1209008/+merge/225162?
<flexiondotorg> xnox, Yes. We uploaded mate-desktop-environment meta package (1.8.0+6) earlier this morning. It has fixes for the Ubuntu gschema overrides.
<apw> doko, had any reports of internal compiler errors on gcc-4.8 with neon things ?
<xnox> flexiondotorg: it's not published in debian yet, thus it's not synced to ubuntu yet either.
<xnox> flexiondotorg: accepted in debian != published in the pool and available for ubuntu to sync and debian users to install.
<mlankhorst> seb128: xorg-server doesn't use bazaar
<xnox> flexiondotorg: $ rmadison -u debian -S mate-desktop-environment && rmadison -u ubuntu -S mate-desktop-environment
<heftig-z> hm, I'm a bit confused about the purpose of a ~ in version strings; deb-version(5) notes it sorts before anything else; what's it used for, though?
<seb128> mlankhorst, right, but that's UDD, if you look at the bug it's a request to backport http://cgit.freedesktop.org/xorg/xserver/commit/?id=29b1484bb9555e45067669cbfe68a3c40596f4ff
<mlankhorst> I'll take a look
<flexiondotorg> xnox, OK thanks for checking. I'll look out for when it lands. I've side ported the packed to a PPA but want to ditch that really.
<doko> apw, we are not using neon by default, so I don't know
<LocutusOfBorg1> sil2100, can we just add subversion in the meanwhile?
<sil2100> LocutusOfBorg1: just subversion as a build-dep? Let me do that (and test build)
<doko> apw, I assume this is armhf
<apw> doko, yes, armhf, kernel raid8 neon syndrome support, builds fine, change configs unrelated to this (seemingly) and these same unrolled files explode
<apw> doko, but of course there is no actual source to see, cause that would be to easy
<LocutusOfBorg1> sil2100, but debian buildd does not have access to internet
<LocutusOfBorg1> maybe the best way is to disable testing
<LocutusOfBorg1> or to use the debian gtest
<LocutusOfBorg1> (but there is no library so file, so linking is not possible unless we build the debian gtest library)
<xnox> LocutusOfBorg1: the only supported way to use gtest is to build-depend on it, and compile your own copy of it and link in the tests. There are make & cmake snipets shipped in the package to do so.
<xnox> LocutusOfBorg1: and there are a few packages in the archive that do that already.
<LocutusOfBorg1> xnox,
<LocutusOfBorg1> apt-cache rdepends libgtest-dev
<LocutusOfBorg1> libgtest-dev
<LocutusOfBorg1> Reverse Depends:
<LocutusOfBorg1>   libxorg-gtest-dev
<LocutusOfBorg1> just this one?
<zle_lisca> is it possible to add a new package to LTS repositories?
<xnox> LocutusOfBorg1: $ reverse-depends -b libgtest-dev | wc says 47 packages
<xnox> LocutusOfBorg1: it's a build-depends, not a depends.
<LocutusOfBorg1> ops sorry thanks
<Noskcaj> Could someone please merge telepathy-mission-control-5 soon?
<seb128> Noskcaj, why?
<Noskcaj> seb128, upower 0.99 transition
<seb128> Noskcaj, btw did you see that you screwed libgtop the other day, I had to revert
<Noskcaj> seb128, yeah
<seb128> Noskcaj, could you try to be a bit careful with your updates?
<Noskcaj> mistakes were made, i'll try and get a real version up later in the holidays
<Noskcaj> yep, sorr
<Noskcaj> *sorry
 * pitti retries ubuntu-system-settings-online-accounts autopkgtest for the nth tijme
<pitti> time
<Noskcaj> forgot to lintian the binary, only did the source
<seb128> Noskcaj, you stack a lot of changes, would be nicer to do less but in a correct way
<Noskcaj> yep
<seb128> Noskcaj, you didn't install/run it though, unity didn't start anymore after the update, neither debdiffed the debs
<seb128> soname changes are an important thing to be careful about
<seb128> pitti, thanks
 * Noskcaj makes note to triple-check everything
<Saviq> pitti, hey, thanks for keeping an eye on http://d-jenkins.ubuntu-ci:8080/view/Utopic/view/AutoPkgTest/job/utopic-adt-ubuntu-system-settings-online-accounts/
<darkxst> Noskcaj, its really worth testing your merges as well ;)
<Saviq> pitti, unfortunately it failed again
<pitti> Saviq: no worries; I get notifications about all failures, and retry the flaky ones
<pitti> Saviq: yeah, I kicked it like 2 mins ago
<Noskcaj> darkxst, That will be a lot easier in a few days time when my dev pc finally functions
<Saviq> pitti, yeah, it failed like 30s ago...
 * pitti kicks it harder
<Saviq> pitti, wonder if we should implement a policy on flaky autopkgtests, they seem to have the chance to be really disruptive...
<Saviq> pitti, do you know if there's a bug for that one?
<darkxst> Noskcaj, you have been saying that for about a year now?
<pitti> Saviq: bug 1336650, still the same as a few days ago
<ubottu> bug 1336650 in ubuntu-system-settings-online-accounts (Ubuntu) "some autopilot tests seem to be flaky" [Undecided,New] https://launchpad.net/bugs/1336650
<Saviq> pitti, yup, thanks
<Noskcaj> darkxst, It's down to software issue rather than hardware issue now
<Noskcaj> I just need to make a bunch of VMs and i'm done
<Saviq> mardy, are you aware of the above bug â?
<seb128> Noskcaj, you can debdiff on any machine...
<Noskcaj> seb128, Yeah. But i can't test install. And i've spent far too long using bzr that i forget to debdiff everything
<Noskcaj> end result = Noskcaj needs to be less lazy
<pitti> seb128: this time it worked
<seb128> pitti, \o/
<seb128> Noskcaj, that would be nice, lower quantity to raise quality ;-)
<pitti> I actually meant "Saviq"
<Saviq> pitti, yup, saw that, thanks
<seb128> pitti, well, I'm waiting for that to migrate as well, so still \o/
<seb128> ;-)
<Saviq> pitti, there's apparently a branch already https://code.launchpad.net/~elopio/ubuntu-system-settings-online-accounts/clean_tests/+merge/225437
<pitti> nice, so "adt-run <click> --- ssh -s ssh-setup/adb -- -r" now does a complete factory reset, configures the phone (wizards, aa-clickhook etc.), and successfully runs click tests
<Saviq> pitti, awesomes!
<pitti> (without any apt-get install or r/w)
<pitti> if we want, we can even unseed autopilot from the images
<pitti> (will need a slight adjustment for the aa-clickhook invocation)
<pitti> actually, why don't I do this right now, it's cleaner anyway and necessary for running in LXC (where autopilot-touch isn't installed)
<pitti> mdeslaur, jdstrand: ah, I finally figured out my woes with aa-clickhook, I filed bug 1337253; is calling aa-clickhook even the right approach, or should this work differently?
<ubottu> bug 1337253 in click-apparmor (Ubuntu) "Doesn't apply --include to newly installed clicks" [Undecided,New] https://launchpad.net/bugs/1337253
<DktrKranz> pitti: hi! I tried to launch adt-run (from autopkgtest 3.0.2) on a locally built package, and I received the following: http://paste.debian.net/plain/107937
<pitti> DktrKranz: ah, are you running this under C locale?
<pitti> apparently I forgot this open() with the "specify encoding everywhere", and it's an edge case
<DktrKranz> yes, C locale (it's actually run in a container)
<pitti> DktrKranz: mind filing a bug about it with that stack trace? (debian or LP, doesn't matter)
<DktrKranz> sure
<pitti> I'll get to it ASAP
<DktrKranz> thanks!
<pitti> and, FTR: Die, C locale, die!
<LocutusOfBorg1> sil2100, http://paste.debian.net/107942/
<LocutusOfBorg1> do you mind testing this?
<DktrKranz> :)
<pitti> If you really hate proper time and date  formats, "Use C.UTF-8, Luke"
<LocutusOfBorg1> thanks xnox for the hints
<LocutusOfBorg1> ops sil2100 I forgot to add libgtest-dev as b-d
<LocutusOfBorg1> fixed http://paste.debian.net/107943/
<pitti> DktrKranz: saw it, thanks
<DktrKranz> np :)
<apw> doko, ok after a bisect on the changes i am trying to apply, it seems to be function tracers/stack tracers which trigger it blowing chunks
<sil2100> LocutusOfBorg1: thanks! Looking, applying, testbuilding and pushing
<sil2100> LocutusOfBorg1: hm, it fails to build for me here, let me take a look what's up
<bluesabre> Good morning sponsors, please take a moment to upload this package to trusty-proposed so we can ship a fix before 14.04.1
<bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
<ubottu> Ubuntu bug 1323405 in menulibre (Ubuntu Trusty) "[SRU] Please backport menulibre-2.0.4 to trusty" [Undecided,New]
<mdeslaur> pitti: thanks for the bug. Can it wait until monday when jdstrand gets back from vacation?
<pitti> mdeslaur: absolutely; I use that workaround now; it's slow, but works
<mdeslaur> pitti: great, thanks
<mardy> Saviq: yes I am, will be fixed when I return from holidays :-)
<Saviq> mardy, go be on holidays then!
<mardy> Saviq: :-p
<LocutusOfBorg1> sil2100, I tweaked again the patch
<LocutusOfBorg1> I'm rebuilding, can I upload directly to mentors?
<LocutusOfBorg1> this one is the debdiff http://paste.debian.net/107957/
<LocutusOfBorg1> just commented few lines
<arges> @pilot in
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges, seb128
<DktrKranz> pitti: thanks for the quick fix, everything is working like a charm now!
<pitti> DktrKranz: yw :)
<pitti> DktrKranz: yeah, it came at the right time, I planned to do a release today anyway
<DktrKranz> I call this timing ;)
<dobey> xnox: it's pay-service
<dobey> ./CMakeLists.txt:find_package (PkgConfig REQUIRED)
<dobey> ./CMakeLists.txt:include (FindPkgConfig)
<dobey> xnox: ^^ that's all it has though, for "PkgConfig" string in .txt files, maybe a cmake module?
<xnox> dobey: find_package (PkgConfig REQUIRED) is correct
<xnox> dobey: i believe include (FindPkgConfig) is redundant and wrong, as instead of a module that file is processed directly. If i drop the "include (FindPkgConfig)" cross-compilation succeeds.
<stgraber> seb128: lp:~ubuntu-archive/+junk/queuebot
<dobey> xnox: hmm, ok, i'll try that
<xnox> dobey: there is also UsePkgConfig vs FindPkgConfig. I don't know if include triggers the old one to be used. find_pacakge(PkgConfig REQUIRED) should be all that's needed.
<seb128> stgraber, thanks
<xnox> nah, doesn't look like Use one is used, it provides different api not used in pay-service.
<seb128> stgraber, do you plan to add support for commands like "where"? (the other ci bot has that)
<stgraber> seb128: maybe, currently the next step is to make it less noisy (only report relevant information). Making it possible for users to query specific information would be nice (and would entirely eliminate the need for the SNCF bot) but would also need some rework of how queuebot works (because the plugin system currently doesn't allow user interaction)
<seb128> stgraber, the goal is to deprecate the other bot? if not, why do we need to have 2, the old one was working and is more complete
<ogra_> dobey, btw, pay-service cause a lot of new crashes in smoke testing ... could you poke tedg to fix ubuntu-app-launch to not fsail on it all the time ?
<ogra_> *fail
<dobey> ogra_: is it a SIGABRT? there's a branch of mine to fix an abort, that's waiting in a silo right now
<ogra_> dobey, pay-service gets an application entry in the "installed apps" scope ... since it doesnt ship an icon ubuntu-app-launch fails trying to find the icon and crashes
<dobey> ogra_: pay-service doesn't have an application entry. are you talking about the pay-ui click package?
<ogra_> so it either needs to vanish from the "installed apps", ship and icon ... or ubuntu-app-launch needs to learn to ignore it
<ogra_> dobey, oh, sorry, yes, i did
<dobey> ogra_: bug gatox about that in #ubuntu-touch
<dobey> ogra_: ubuntu-app-launch crashes, or pay-ui crashes?
<ogra_> ubuntu-app-launch
<ogra_> pay-ui crashes if you tap the launcher :)
<ogra_> but i guess thats expected since it most likely shouldnt even have one
<dobey> weird
<dobey> if pay-ui is crashing, then i guess the package that's installed is broken
<ogra_> https://jenkins.qa.ubuntu.com/job/utopic-touch-mako-smoke-daily/394/artifact/clientlogs/security/_usr_lib_arm-linux-gnueabihf_ubuntu-app-launch_desktop-hook.32011.crash/*view*/
<dobey> and ubuntu-app-launch isn't crashing for me when i launch payui with it
<ogra_> it fails in the desktoop-hook
<dobey> ah
<ogra_> "grapics/lock@8.png"
<ogra_> looks like a typo ;)
<dobey> not a typo, but that file might not be getting installed in the package
<dobey> it's in the source tree
<dobey> but looks like it should be changed to point to the other graphic anyway
<dobey> since the other graphic that is probably installed, is what is uploaded to the store
<brendand> mterry, for https://bugs.launchpad.net/bugs/1336783, did you mean to subscribe foundations-bugs to bug mail for that source package?
<ubottu> Ubuntu bug 1336783 in python-ecdsa (Ubuntu) "[MIR] python-ecdsa" [Undecided,New]
<mterry> brendand, yeah
<brendand> who's an admin for foundations-bugs? cjwatson?
<brendand> mterry, because i can't do that myself
<cjwatson> I can do that, one sec
<cjwatson> god I really must make the team picker widget sort the team names
<mterry> brendand, any member of the team can do it yeah, but cjwatson's on the case!  :)
<cjwatson> ridiculously painful to find anything
<mterry> cjwatson, yeah, it's the worst  :(
<mterry> designed for people with a few teams
<cjwatson> huh, can't actually find an LP bug for that, I'll file one
<cjwatson> ~>
<cjwatson> ~>
<cjwatson> sigh
<cjwatson> mterry: https://bugs.launchpad.net/launchpad/+bug/1337329
<ubottu> Ubuntu bug 1337329 in Launchpad itself "Structural subscription recipient picker shows unsorted list of teams" [Undecided,New]
<cjwatson> brendand: anyway, done
<brendand> cjwatson, thanks
<brendand> now to wait patiently for the security teams review
<dobey> mvo: oh, i didn't send you a mail, but cjwatson pointed me in the right direction last night for that last error i was getting with pkcon install-local foo.click
<mvo> dobey: what was it?
<dobey> mvo: the plug-in's config file has "phablet" hard-cocded in it
<mvo> dobey: ohhhhh
<dobey> and that isn't my user :)
<mvo> dobey: ok
<mvo> :)
<dobey> with that fixed, it was down to apparmor. so i tweaked the aa-clickhook script to just exit cleanly instead of do all the apparmor stuff, and install worked :)
<dobey> well, mostly worked. was installing a broken package that has metadata which doesn't match the package name
<pitti> tyhicks, mdeslaur: do you happen to know: apparmor's Vcs-Bzr: is way out of date; is there a different branch now, or did you move to UDD?
<pitti> https://code.launchpad.net/~ubuntu-core-dev/apparmor/master that is
<mdeslaur> pitti: one sec, let me try and figure out which one of the zillion trees is actually the right one *sigh*
 * tyhicks is trying to do the same
<mdeslaur> pitti: if you want to push a change, just upload a new package
 * mdeslaur is going to scream and rm -rf the zillion trees soon
<pitti> mdeslaur: ok; I'll upload them to a PPA for now, but I'd like to land them in the next days; it's just a simple change to debian/apparmor.upstart
<pitti> thus packaging only
<pitti> mdeslaur: so while I'm at that, shoudl I drop the Vcs-Bzr: header? or is it meant to still be used?
<tyhicks> mdeslaur: should it be lp:~apparmor-dev/apparmor/apparmor-ubuntu-citrain ?
<jjohansen> tyhicks: that looks right
<jjohansen> that is I think the name is right, I haven't poked at what is in it yet
<mdeslaur> pitti: please use the one tyhicks just mentioned, and change the vcs-bzr while you're at it
<mdeslaur> pitti: sorry for the confusion
<pitti> mdeslaur: no worries; but I can't push to that one
<mdeslaur> d'oh
<tyhicks> I think jdstrand has to accept the merge
<pitti> packaging branches are better owned by ubuntu-core-dev or a team containing u-core-dev
<pitti> ok
<pitti> I need to test all this first, I'll propose a merge then
<mdeslaur> pitti: I think that was the whole reasoning behind the move, not everyone was a core-dev :P
<mdeslaur> *grumble*
<pitti> mdeslaur: so, ~apparmor-packagers which has core-dev as a member?
<pitti> cjwatson: console-setup's Vcs-Bzr: is one upload behind; do you happen to have it locally and it just needs a bzr push, or want me to grab and push the debdiff from LP?
<mdeslaur> pitti: I'll talk to jdstrand when he gets back to see what the reasoning behind it all was
<pitti> cjwatson: ah nevermind, that was a no-chagne rebuild from xnox; I'll comit
<cjwatson> sure
<pitti> xnox: FYI, I uploaded some "task" fixes (those which affect a default install) into a PPA and updated https://wiki.ubuntu.com/SystemdMigration
<pitti> xnox: boot works fine now with startpar, just shutdown hangs
<xnox> pitti: fun. Cool, i'll look into it.
<xnox> thanks a lot!
<pitti> xnox: now I need to learn how to debug that (unless you have some hints)
<seb128> bdmurray, hey, on https://bugs.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/1312349 you wrote that you uploaded to trusty, do you plan to re-upload the fixed version as well?
<ubottu> Ubuntu bug 1312349 in HWE Next "Microsoft bluetooth mobile keyboard 6000 cannot be used" [Undecided,In progress]
<xnox> pitti: get a tty / serial console to be running on shutdown, and or add some of the jodh scripts to print what's hanging on shutdown. I presume it is still starpar hanging, thus i guess one can just execute it in the shutdown mode and check what happens.
<xnox> if it just blocks on waiting for notifications, maybe it is awaiting for "stopped" notifications or something
<pitti> xnox: ah, is there some "startpar shutdown --dry-run" thingy?
<jodh> pitti:
<jodh> pitti: lp:~jamesodhunt/ubuntu/trusty/sysvinit/log-open-files-on-shutdown
<LocutusOfBorg1> do you have any timeline for gcc-4.9 in ubuntu?
<LocutusOfBorg1> I ask because would be nice to prior merge wx 3.0.1-2
<xnox> pitti: not quite, when debugging boot hangs. I just traced how startpar is run, and just run it direct instead of hiding it in a subshell $() inside rc script. It's something like current & target runlevel and how much parallelism one wants.
<xnox> LocutusOfBorg1: gcc-4.9 is in ubuntu, it was default and then flipped back. If you want to merge wx now, you could add build-depends on gcc-4.9, but please remember to drop it after 4.9 is the default again.
<LocutusOfBorg1> yes, I know about the default problem
<LocutusOfBorg1> isn't better to remember to merge wx soonafter the gcc-defaults upload?
<LocutusOfBorg1> right?
<LocutusOfBorg1> (or maybe in the next archive rebuild somebody will notice the ton of build failures and will merge it lol)
<pitti> xnox: ah, at least mountall.conf was missing in your list (possibly due to the .sh suffix)
<xnox> pitti: no.
<xnox> pitti: there is no /etc/init.d/mountall.conf, there is /etc/init.d/mountall.sh with a matching /etc/init/mountall.sh.conf which is not a task.
 * xnox checks to make sure i haven't modified it locally
<pitti> xnox: ah, ok
<pitti> xnox: do you happen to remember how to specify previous and next runlevels? that's not on the manpage
<pitti> sudo startpar -t 5 -T 10 -M stop
<pitti> I tried with that
<pitti> oh, -P and -R
<xnox> that rings the bell
<pitti> xnox: hm, I get http://paste.ubuntu.com/7742398/ and an eternal hang
<xnox> pitti: i wonder if upstart goes away, before startpar completes though.....
<pitti> xnox: oh, there's still a running startpar after boot
<pitti> startpar -p 4 -t 20 -T 3 -M start -P N -R 2
<pitti> xnox: that might be what's blocking the socket?
<pitti> if I kill it, my startpar for shutdown stops having these errors, but now it just hangs around without doing or saying anything
 * pitti wants a --verbose
<pitti> anyway, 'nuff for today; /me should learn to sleep at night and not start at 5:30..
<seb128> pitti, 'night
<xnox> pitti: yeap. good night. Startpar is very quite thing.
<xnox> no logs/verbosity at all.
<xnox> caribou: subscription to debian-devel is not required by DDs. ;-)
<caribou> xnox: :-D
<seb128> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: arges
<shadeslayer> pitti: ping
<shadeslayer> pitti: I don't suppose you can tell me why my autopkgtest hook fails on not finding a /tmp/adt-* dir
<shadeslayer> full log http://paste.ubuntu.com/7742698/
<hallyn> infinity: hey, i was just pinged about docker.io 1.0 sru to trusty.  took a quick look at the packaging.  Confused.  paul tag mentioned rename from docker.io to docker, but i don't see that even in experimental's docker and docker.io pkgs, in debian/control or debian/changelog.
<hallyn> i.e. i interpreted the changelog to say that docker source pkg shouldve been renamed to wmdocker, and docker.io -> docker;  neither seemst o have happened.  do you know the status?
<infinity> hallyn: No, it's the binary on path that's renamed, not the package.
<infinity> hallyn: ie: /usr/bin/docker
<hallyn> oooh
<hallyn> gotcha, thanks
<hallyn> all right i'm planning to look into this on monday.  thanks - ttyl
<Saviq> popey, I'm worried there's an app that can kill stallboard in popularity...
<popey> Saviq: dekko? (email client)
<popey> or Hodor?
<Saviq> popey, the latter ;)
<popey> â»
<ogra_> oh
<ogra_> why didnt they keep the name ?
<ogra_> (for trojita)
<ogra_> ah, the description explains it
<ogra_> Saviq, nothing beats failsauce !
<Laney> arges: I'd already sponsored sosreport but I forgot to update the bug
<Laney> you could reject yours and process the SRU instead ^o)
<chrisccoulson> with /run/shm mounted, does anyone know what else might be missing to cause this: http://pastebin.ubuntu.com/7741085/
<sarnold> chrisccoulson: you do find the most interesting problems :)
<chrisccoulson> sarnold, aha, not me this time. it's psivaa-afk instead :)
<sarnold> chrisccoulson: oh! :)
<xnox> sigh, looks like thunderbird is broken. Trying to send smime ssl encrypted mail, and it just loops into "you need to setup one or more keys" which i have.....
<sarnold> it must just be shocked that someone has keys :)
<bdmurray> seb128: I'm on holiday until Monday but I could then
<xnox> sarnold: surprisingly, my certificate store has collected 24 people to date. But i need just this one person.
 * xnox tries evolution
<sarnold> xnox: wow that is surprising :) I always knew there were a few out there..
<xnox> haha i don't have evolution installed at all
<dobey> bdmurray: hi. do you know why some crashes on e.u.c don't have the "Create" link in the bugs column, but instead just a blank space?
<xnox> sarnold: sigh, evolution gets further and then ultimately fails to do smime encryption to target....
<sarnold> xnox: interesting. maybe try openssl verify on the keyfile?
<sarnold> s/keyfile/cert/
<xnox> Because "Cannot encrypt outgoing message: No encryption certificate set for this account", you may need to select different mail options.
<xnox> but i have....
<sarnold> why would you need to be able to receive encrypted mail in order to send encrypted mail..?
<bdmurray> dobey: because they failed to retrace
<dobey> bdmurray: what's the best way to get a bug filed with all the right info? this crash in particular is going to get a lot of reports i suspect (crash in mirclient whenever qml/qt app exits on the phone)
<sil2100> LocutusOfBorg1: hmm, I still seem to have problems building with this patch
<infinity> chrisccoulson: What's the state of /dev/shm in that setup?
<chrisccoulson> psivaa-afk ^
<arges> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<hallyn> oh, feh.  so i pushed a patch to match the kernel headers and glib headers wrt XATTR_CREATE define/enum, but it looks like the attr package has its own include file that also needs to be synced
<TheMuso> pitti: I did some testing with a BT headset but that was a few years back. I still have it around here somewhere, I'd need to recharge it, but I will see if I can reproduce your issue.
<sarnold> Trevinho: another screenlock issue: 1337601
 * Trevinho checks
<Trevinho> sarnold: that should be fixed, the change for trusty is going to be landed in the SRU that will hopefully go in in days
<sarnold> Trevinho: awesome :) thanks
<mwhudson> er
<mwhudson> debuild -S is asking me to sign using my old key
<mwhudson> pretty sure my new key is default, so i must have set this up somewhere
<mwhudson> anyone remind me where? :)
<jtaylor> ~/.devscripts?
<mwhudson> i thought that but
<mwhudson> $ cat ~/.devscripts
<mwhudson> DGET_VERIFY=no
<rbasak> mwhudson: $DEBSIGN_KEYID?
<mwhudson> unset
<jtaylor> two keys in the keyring?
<mwhudson> yeah i have two keys
<jtaylor> put the new keyid into .devscripts
<mwhudson> but i thought i'd told gpg to default to the new one
<mwhudson> i guess debsign isn't listening :)
<jtaylor> does it have a comment?
<mwhudson> yeah ok
<jtaylor> default doesn't work for me either
<mwhudson> how do i tell?
<rbasak> dpkg-buildpackage(1) says $DEB_SIGN_KEYID
<rbasak> Nice and consistent
<mwhudson> :)
 * mwhudson just runs debuild -k$KEY for now
 * rbasak goes to bed
<infinity> mwhudson: debsign doesn't care about the gpg default, it signs with "-k'Name in Changelog'"
<infinity> mwhudson: Which is why it explodes when sponsoring, without specifying another key.
<mwhudson> infinity: both of my keys have this name on them
<infinity> (Which is a feature I actually like)
<mwhudson> so i guess that's just 'eh, pick one'?
<infinity> mwhudson: It's the first that gpg spits out when asked for a key by that name.
<mwhudson> i should probably just drop my old key from the keyring i guess
<infinity> mwhudson: Which, if they have the same name and sort lexically identically, is usually the older one, I believe.
<mwhudson> it's been a few months and i can still just about remember the passphrase for the new one :)
<infinity> mwhudson: But yeah, having both keys on the same keyring isn't doing you any favours anyway, probably.  I'd split out the old one to secring-old.gpg
<cjwatson> I just use DEBSIGN_KEYID in ~/.devscripts
<infinity> So you have to actually explicitly invoke the old keyring when signing/decrypting with it.
<infinity> Which makes you very aware that you're using it.
<cjwatson> (I never use dpkg-buildpackage's signing)
<infinity> cjwatson: Yeah, that was the advice given by others already.
<infinity> Whoa, be still my beating heart, did IBM finally get their firefox patches upstream?
<infinity>  firefox | 31.0~b6+build2-0ubuntu1                  | utopic                  | source, amd64, arm64, armhf, i386, powerpc, ppc64el
#ubuntu-devel 2014-07-04
<robert_ancell> RAOF, if exiv2 is now in proposed (https://launchpad.net/ubuntu/utopic/+source/exiv2/0.24-2ubuntu1) and I upload new packages they'll build against that version right? I don't have to wait until it hits the release pocket
<TheMuso> I think you do need to wait till they hit release.
<robert_ancell> TheMuso, I tried building gexiv2 and the .deb it produces links against the new version so it seems to work
<TheMuso> Ok.
<ScottK> robert_ancell: That's correct. If you had to wait for it to get to -release then we'd never get a library transition done.
<robert_ancell> ScottK, cool, thanks :)
<michagogo> ScottK: hey, you're on SRU team, right?
<ScottK> I am.  I'm also about to go to bed.
<michagogo> ScottK: Ah. At some point, would you mind taking a loot at my message on the -devel list?
<michagogo> look*
<ScottK> Which one is that?
<michagogo> https://lists.ubuntu.com/archives/ubuntu-devel/2014-July/038389.html
<ScottK> At some point.
<michagogo> Fair enough.
<michagogo> TIA.
<michagogo> good night!
<pitti> Good mornin
<pitti> shadeslayer: what is that hook supposed to do? autopkgtest didn't even run yet in that log, and it cleans up its temp dirs afterwards?
<dholbach> good morning
<pitti> xnox: so I know why startpar never finishes the "start" part, it's waiting on pulseaudio; it's upstart job never starts (deliberately), but the init.d script wants to
<pitti> xnox: when I remove those (update-rc.d pulseaudio disable), startpar start correctly finishes, but still hangs on boot
<pitti> xnox: but remind me, why do we need to make startpar work at all? we are already using insserv now, so that ought to be enough?
<pitti> xnox: I'm also getting a race condition on start that lots of stuff tries to start before the root partition is mounted r/w
<pitti> xnox: i. e. we could certainly spend lots of time fixing all this, but that's not our ultimate goal anyway
<pitti> hey dholbach, wie gehts?
<pitti> xnox: i. e. we could probably merge to a recent sysvinit and still keep startpar disabled?
<wgrant> dpm, pitti: What are the plans for translations for RTM? Wondering how much I need to make Translations (and langpacks etc.) work for the derived distro.
<pitti> wgrant: I don't think we actually talked about that at all
<pitti> wgrant: but good point, we probably won't be able to build proper langpacks for the derived distro if it doesn't have its own set of templates/exports
<pitti> we could possibly just use the latest devel series ones, but that will get inaccurate if strings get dropped/changed
<wgrant> Exactly my concerns.
<pitti> so if we'll have significant delta in that distro (with string diversions), we probably need to treat it as a full release wrt. translations, too?
<dpm> that's what I'm starting to realise too
<wgrant> I think so. And I haven't yet checked how much the Ubuntu hardcodings in Rosetta will hurt.
<dpm> wgrant, would message sharing work between the derived distro and Ubuntu?
<wgrant> dpm: I don't think that would require too much work, but that would be the intent.
<dpm> yeah, that'd make sense
<LocutusOfBorg1> sil2100, for this time I think just remove the patch and add subversion as b-d is fine :(
<LocutusOfBorg1> I cannot build either
<LocutusOfBorg1> I have a problem injecting the LDFLAG for tweaking the build
<sil2100> LocutusOfBorg1: you think it won't cause any problems anywhere?
<LocutusOfBorg1> I think it won't cause any problem, but I'm not sure
<LocutusOfBorg1> anyway I'm discussing with upstream https://github.com/luceneplusplus/LucenePlusPlus/pull/65#issuecomment-48018656
<LocutusOfBorg1> I'm rebuilding
<LocutusOfBorg1> since upstream says tests are just useless and not even implemented (just one test) we can skip them!
<LocutusOfBorg1> I'll rebuild with tests disabled and push on mentors if you agree
<LocutusOfBorg1> sil2100, please review my changes
<Saviq> greyback, ricmm has a beer for you
<greyback> Saviq: beer for breakfast, if you say so
<Saviq> greyback, I'm just the messenger
<sil2100> LocutusOfBorg1: looking! Did you just add the subversion dependency or also some other changes?
<sil2100> LocutusOfBorg1: ah! I see the tests being disabled ;)
<sil2100> LocutusOfBorg1: ok, so it looks ok I guess, although won't this cause problems? I know that we basically don't have much other choices, but won't it get rejected because of disabled tests?
<sil2100> LocutusOfBorg1: I noticed that disabling tests is generally very aggressively frowned upon ;)
<sil2100> LocutusOfBorg1: anyway, if you as a DM accept this temporary state, then I'm +1 on it as well
<LocutusOfBorg1> sil2100, https://github.com/luceneplusplus/LucenePlusPlus/pull/65#issuecomment-48018656
<LocutusOfBorg1> is upstream telling that tests are almost useless at this moment ;)
<LocutusOfBorg1> so when and if they will make a good testsuite, and fix their cmake files we can enable them
<LocutusOfBorg1> I don't see particular issues with this
<sil2100> hah!
<sil2100> ;)
<LocutusOfBorg1> I see issues with lintian instead ;)
<LocutusOfBorg1> seems that doc package is using embedded jquery
<LocutusOfBorg1> I'm rebuilding from a clean directory, maybe I just run dpkg-buildpackage prior to clean up the build-dir
<LocutusOfBorg1> I tweaked dh_link to link jquery
<LocutusOfBorg1> and make doc depend on jquery package
<cjwatson> Use dh_linktree instead
<cjwatson> It's much better for this, sorts out the dependencies for you
<LocutusOfBorg1> syntax is the same?
<LocutusOfBorg1> I read it on debian-devel but slipped of my mind
<cjwatson> Similar but not identical - see its man page
<LocutusOfBorg1> yes
<LocutusOfBorg1> done
<LocutusOfBorg1> but I still need to override dh_install right?
<LocutusOfBorg1> dh_install --fail-missing -Xjquery.js
<cjwatson> No, you can run dh_linktree after dh_install and have it replace stuff with symlinks
<cjwatson> Well, you'll need to override it for --fail-missing
<LocutusOfBorg1> mmm ok
<LocutusOfBorg1> does it automatically run after dh_install? I create a file package-doc.linktree
<cjwatson> If you're using dh $@ --with linktree, then dh_linktree is sequenced to run after dh_link, which runs well after dh_install
<LocutusOfBorg1> wow a new helper ;)
<LocutusOfBorg1> mmm strange, I need to build-depend from dh-linktree?
<cjwatson> Yes
<michagogo> cjwatson: I don't know if you saw it, but I posted to the mailing list as you suggested
<michagogo> Thanks for your help!
<cjwatson> Yup, thanks
<xnox> slangasek: pitti: that has been in the back of my mind as well. Why can't we keep startpar disabled, given that we (a) have enabled update-rc.d (b) we have lsb initfunctions.d hook to keep everything sane
<xnox> sarnold: so thunderbird decided to allow me encrypting emails to target email after (a) setting up security smime signing & encryption certificates on the "account" (b) repeating same on the "Manage identities" the default and the one person is going to use.
<xnox> sarnold: none of which should be required to encrypt message to someone else....
<xnox> (just)
<xnox> sarnold: also it couldn't care less that FROM: identity email address did not match Subject / Alt Names on the certificate.....
<bluesabre> Good day Sponsors!  Please let me know if anybody is available to upload this package to trusty-proposed
<bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
<ubottu> Ubuntu bug 1323405 in menulibre (Ubuntu Trusty) "[SRU] Please backport menulibre-2.0.4 to trusty" [Undecided,New]
<bluesabre> It's been in the sponsors queue for a while now, and we would like to deliver the fixed package in time for 14.04.1
<bluesabre> It fixes some nasty bugs that completely break the program, and can corrupt user menus
<cjwatson> xnox: It's arguably correct not to care, since anyone can put whatever they like in From: :-)
<cjwatson> Well, maybe, not sure
<xnox> cjwatson: it's also entertaining how the target person uses Exchange, which appends & mangles the messages, hence the smime signature does not validate =)
<LocutusOfBorg1> cjwatson, is it correct? seems to work, but I would like to have a feedback if possible
<LocutusOfBorg1> http://anonscm.debian.org/gitweb/?p=pkg-sdl/packages/sdlgfx.git;a=commitdiff;h=568ac5acffec69eadb0c91bb745e01beddf7dee4
 * xnox wonders if my Latvian National Identity smartcard certificates can be used for SMIME signing & encryption
<cjwatson> LocutusOfBorg1: Looks OK, though I'd normally prefer "--with autoreconf,linktree"
<pitti> xnox: right, and I believe latest sysvinit still works well with just plain insserv and without startpar
<pitti> cjwatson: FYI, https://jenkins.qa.ubuntu.com/job/utopic-adt-click/9 failed (you didn't get the mail because it was bot-uploaded)
<pitti> mvo: unattended upgrades failed as well, argh PEP-8 :/
<LocutusOfBorg1> thanks cjwatson there is always to learn ;) fixed!
<mvo> pitti: *gih*
<mvo> pitti: what the link again? do you have it at hand?
<mvo> pitti: I broke it (click)
<mvo> sorry
<xnox> pitti: hm, wasn't that upload suppose to have "Sponsored for cjwatson" though?! ( i thought we had that enabled by didrocks before he handed ci-uploads over)
<pitti> mvo: you mean https://jenkins.qa.ubuntu.com/job/utopic-adt-unattended-upgrades/18 ?
<mvo> pitti: yes, thanks
<pitti> xnox: https://launchpad.net/ubuntu/utopic/+source/click/0.4.29 -> (sponsored by Ubuntu Archive Robot)
<mvo> cjwatson: I broke the click test, I will work on a fix while stearing the the citrain
<xnox> pitti: aha. I looked at the release pocket source publish record. Right. so that bit is in place.
<xnox> pitti: i guess with enough trickery jenkins could be sending the email to the right sponsored for people as well....
<xnox> priority: for later
<cjwatson> mvo: Thanks, I hadn't looked at the autopkgtest output yet
<mvo> cjwatson: I use os.environ["USER"] which is not available in adt it seems
<cjwatson> xnox: My name's there, it's just obscure.  See https://launchpad.net/ubuntu/+source/click/+publishinghistory
<pitti> mvo: actually, I thought I just fixed that a few days ago
<mvo> pitti: oh?
<mvo> pitti:     user = os.environ["USER"]
<mvo> KeyError: 'USER'
<cjwatson> OTOH, I didn't get the mail either
<mvo> pitti: is what I see in the test
<pitti> mvo: so if it's just that, let me roll out the latest autopkgtest to the machines and retry
<diwic> it's probably a USER error
<mvo> pitti: yeah, it is just that
<diwic> (sorry, couldn't help myself)
<mvo> diwic: lol
<pitti> mvo: does it depend on $USER just for the tests, or for actual operation?
<mvo> pitti: just for the tests iirc
<pitti> mvo: hm, still failed
<mvo> :/
<pitti> mvo: are these tests running as root or user?
<mvo> pitti: as root
<mvo> pitti: I could hardcode "root" there I guess :)
<pitti> oh, so $USER would be "root"?
<pitti> mvo: right, I just recently fixed it for tests that run as user
<mvo> pitti: aha, ok. so what should I do, just hardcode root here?
<pitti> mvo: I'm knee-deep in debugging a Mir/libudev issue, would you mind filing an autopkgtest bug about that? I can look at that on Monday
<mvo> pitti: no worries, I can also just fix it on my side, but I'm equally happy to file a bug. whatever is easier for you
<pitti> mvo: or environ.get('USER', 'root') perhaps
<mvo> (can do both of course)
<mvo> pitti: yeah, good idea
<pitti> mvo: yeah, but still appreciated, in case other tests need that as well
<pitti> I never ran into this, and TBH $USER is a rather bad idea IMHO
<mvo> pitti: fair enough
<mvo> https://bugs.launchpad.net/ubuntu/+source/autopkgtest/+bug/1337802
<ubottu> Ubuntu bug 1337802 in autopkgtest (Ubuntu) "Set $USER environment in the tests for root" [Undecided,New]
<pitti> ohe of these things people should have avoided 30 years ago :)
<pitti> mvo: thanks
<mvo> pitti: your welcome
<cjwatson> xnox: Could you merge dune-geometry, please?  Needed for a pending transition.
<pitti> dobey: ubuntuone-dev-tools failure> more PEP-8 fun!
<xnox> cjwatson: done.
<cjwatson> xnox: thanks :)
<bluesabre> xnox: would you mind uploading this package to trusty-proposed to begin SRU verification?
<bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
<ubottu> Ubuntu bug 1323405 in menulibre (Ubuntu Trusty) "[SRU] Please backport menulibre-2.0.4 to trusty" [Undecided,New]
<LocutusOfBorg1> sil2100, https://mentors.debian.net/package/lucene++
<LocutusOfBorg1> please check and I'll ask for upload
<psivaa> infinity: chrisccoulson_: sorry missed your ping last night about /run/shm & /dev/shm state
<psivaa> lrwxrwxrwx 1 root root 8 Jul  2 15:15 /dev/shm -> /run/shm
<chrisccoulson> that looks normal
<sil2100> LocutusOfBorg1: ok, browsing throught in a moment
<Bluefoxicy> so guys
<Bluefoxicy> what's going on with 14.10?
<Bluefoxicy> I sent to the dev list a while back that I'd like to see pam-tmpdir integrated by default this time, and no response
<Bluefoxicy> is anyone testing?
<Bluefoxicy> Everything's working on my end, has been for several releases.
<shadeslayer> pitti: http://paste.ubuntu.com/7747340/ is the hook
<pitti> shadeslayer: is cowbuilder somehow creating /tmp/adt-* ? (sorry, I don't know at all how that works, but it seems strange that it'd create an adt* dir)
<shadeslayer> hm, not that I know of, it's all very weird
<shadeslayer> this hook worked a few weeks ago
<shadeslayer> and now it doesn't
<pitti> shadeslayer: well, you might have had one from a previous run
<pitti> shadeslayer: but this looks like it expects the output before actually running adt-run..
<shadeslayer> pitti: do you have a autopkgtest hook for pbuilder?
<pitti> shadeslayer: no, I don't
<shadeslayer> https://gitorious.org/tanglu/jenkins-tanglu-buildkit/source/6694557e21cc163573338a3b21fd4757435af8e0:slave/pbuilder-hookdir/B20autopkgtest#L21 < does the same thing
<pitti> I usually just run adt-run on a .dsc or source tree, or on a .changes if I have a build already
<shadeslayer> hm ok, thx :)
<mvo> pitti: fixing the pep8 failure right now, kind of ironic to have a pep8 failure in test_pep8.py :P
<pitti> mvo: hehe; thanks
<shadeslayer> dpm: ping
<shadeslayer> dpm: are you in Barcelona next week?
<dpm> hi shadeslayer, yes
<Bluefoxicy> anyone?
<Bluefoxicy> pitti?
<infinity> Bluefoxicy: By "a while ago", do you mean October 2012?
<Bluefoxicy> wow that comes out of google
<Bluefoxicy> what the hell?
<Bluefoxicy> I swear I sent an e-mail to ubuntu-devel-discuss last week asking about doing this in 14.10
<Bluefoxicy> no evidence of any such e-mail exists anywhere
<infinity> Ahh, yes.  You did.
<infinity> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2014-April/014941.html
<Bluefoxicy> it's not in my gmail or anything
<Bluefoxicy> oh, there it is.  Wait, why don't I have it here?  o_O
<infinity> But I'm not sure the arguments really would have changed since mdeslaur responded two years ago to the same thing.
<Bluefoxicy> is that the "this should not be a problem, make apps behave properly" argument?
<Bluefoxicy> infinity:  my original concern (back in 2004) actually involved information leaks in the form of file names
<infinity> Bluefoxicy: Indeed.  Firefox and Thunderbird certainly should learn to use XDG_ locations.
<infinity> Bluefoxicy: I get the slight information leak concern.
<Bluefoxicy> infinity:  the FHS now specifies temporary files go in /run instead of /tmp?
<infinity> Adding things to the defauly PAM stack is always something that needs an audit and careful consideration, though.  "It works for me" isn't quite enough for something that runs as root on every new session.
<Bluefoxicy> i know
<Bluefoxicy> I've been doing this since 2004 and trying to get people to use it during development cycles as at least a bulk sanity check measure
<infinity> Bluefoxicy: If you're running it and happy with it, yay? :)
<infinity> I run a lot of things I don't think need to be the default for everyone else.
<Bluefoxicy> http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html wow
<Bluefoxicy> didn't know about this
<infinity> And this doesn't cover the other tmpdir (/var/tmp), which is where large files go.
<infinity> (In a traditional layout)
<Bluefoxicy> infinity:  curious, completely different topic
<Bluefoxicy> somewhere in 2003-2005 I started arguing that Linux needs a good replacement or interface for Active Directory, to attain feature parity with Microsoft networks in the ability to push security policies, configurations, installed applications, and have central authority for users and computers on the network
<Bluefoxicy> There are a few directory servers--FDS, RHDS, Mandriva has one, SuSE has one--but nobody seems to have actually tried to shape up client/server management for networks.  I haven't seen Ubuntu's cloud offering, which might do that.
<Bluefoxicy> Does anyone actually consider this a deficiency?  I've had several discussions which basically ended in, "That's stupid, businesses don't want or need that"
<Bluefoxicy> but I've never been able to look at corporate networks nad say, "You can do all that with Linux"
<infinity> People want different things.  Nothing's sane to ship "by default", but lots of different solutions could use work.
<Bluefoxicy> I did get as far as managing users in a central repository
<Bluefoxicy> infinity:  You've managed Windows networks?
<infinity> Pure UNIX/Linux networks tend to not want anything that looks at all like AD, but instead want puppet-like things, and users/groups distributed out-of-band (like ud-ldap), or other fun stuff.
<infinity> People trying to live in AD networks want tight integration with an AD controller.
<Bluefoxicy> yeah
<infinity> People trying to take over AD networks want to *be* an AD controller.
<Bluefoxicy> When I worked at Social Security, they said they've looked at switching to Linux desktops, but it's impossible to manage properly.
<Bluefoxicy> I've used Puppet.  One day, maybe I'll write something strikingly like it that actually works.
<infinity> There's software to do all of these things, some needs more love than others, none of it is suitable for a "default" install.
<Bluefoxicy> puppet's getting a lot of attention from dell and vmware and such, but, honestly... it's horrible.
<Bluefoxicy> we have a package manager
<Bluefoxicy> it's called apt.
<infinity> (Not because it's crap, but because everyone has differing views on what the defaults should be)
<Bluefoxicy> you can write modules in puppet to deploy roles... but if any of the needed packages overlap, it fails.
<Bluefoxicy> so then you break it down into smaller modules
<Bluefoxicy> until you eventually have a module for every individual package
<Bluefoxicy> and the only point of this is, essentially, to change the default settings in the packages
<infinity> Bluefoxicy: In a dpkg/rpm world, config management like puppet/chef should be used to enhance the package manager, not replace it.  ie: to roll out config changes on top of the packages defaults, not to mangle the packages and anger dpkg.
<Bluefoxicy> infinity: in puppet, if you define a package resource more than once, anywhere, it cries out because you're defining an already-defined resource
<infinity> Bluefoxicy: I dunno, we use it quite successfully with a lot of different roles.
<Bluefoxicy> infinity:  what if you have two different roles that both provide a web service via nginx
<Bluefoxicy> so you depend on nginx, and have it installed in both roles?
<Bluefoxicy> puppet fails when you put both roles on one server.  So you have to make a separate nginx role.
<Bluefoxicy> which is okay, until you realize there's 50 different nginx modules, written different ways, and, eventually, you have a custom module for nginx in this role or that role...
<infinity> We don't tend to do multiple roles per server.  Which, to be fair, is also how the rest of the world is going with cloudy things, juju, lxc, docker, coreos, etc.
<Bluefoxicy> I've gone both ways
<Bluefoxicy> hi ari
<infinity> I do multiple roles on home servers where I don't have a datacenter to play with, and don't want the overhead of even light virtualisation.
<infinity> But on the home or small business server scenario, you probably also don't give a crap about config management, I know I don't. :P
<Bluefoxicy> my only multi-role server is a web app server
<infinity> Cause it's usually one or two machines, not 100.
<Bluefoxicy> infinity:  i'm studying project management
<Bluefoxicy> let's not get into the merits of proper procedure in various situations ;p
<Bluefoxicy> there are some environments where an abridged process is the absolute best way to do it, others where you need full processes, and everything in between; there are no real general rules for this :)
<ari-tczew> hi Bluefoxicy
<ari-tczew> cjwatson: I'm sorry but I need to ask you what's gonna on with M-o-M :)
<Bluefoxicy> ari-tczew:  russian?
<ari-tczew> Bluefoxicy: nope, polish
<Bluefoxicy> ah
<Bluefoxicy> hmm.
<Bluefoxicy> I know an ari in moscow
<Bluefoxicy> russian is a pretty crazy language, but polish is insane
<Bluefoxicy> my grandfather speaks polish 'cause he came over from there on a boat
<ari-tczew> cool
#ubuntu-devel 2014-07-05
<ari-tczew> Unit193: The fix for lightdm-gtk-greeter (B-D on libido) has been uploaded.
<rubund> Hi, If a bug report contains several bugs, and I create a patch which fixes one of them. How should I proceed? Is it necessary to split the bug report by creating new reports for every one of them?
<cjwatson> It's generally best for a bug report not to contain multiple actionable items.
<cjwatson> Though it can reasonably enough be a single thing that needs fixes in multiple places before it's properly fixed.
<cjwatson> But if it's genuinely several disconnected problems, then I would split it.
<rubund> ok, and how would it then be linked back to the original bug report ?
<rubund> since the importancy will not be reflected by the new bug reports
<rubund> duplicate?
<cjwatson> Just put links to the new one in comments on the old one, and set the importance etc. of the new one as appropriate.
<rubund> ok, thank you very much
<cjwatson> You can only have one duplicate target so that doesn't really work.  I'd just close whatever's left of the old one with references to the split bugs.
<cjwatson> Unfortunately Launchpad doesn't have a "clone" operation on bugs.
<rubund> ok. So the bug I'm talking about is this one: (LP: 1315149). It basically just says that the package is unusable in trusty. Some of the things have already been fixed upstream and should probably go into trusty quite soon, while others are harder to fix (won't fix, not so important). I believe I just should create a new bug report with a more specific title if I fix parts of it then.
<ubottu> Launchpad bug 1315149 in kicad (Ubuntu) "kicad is mostly unusable out of the box, help doesn't work, footprints are missing" [Undecided,Confirmed] https://launchpad.net/bugs/1315149
<cjwatson> I have to go now so don't have time to look in any detail, I'm afraid.
<cjwatson> It's understandable that bug submitters can't always get things at the right granularity; sometimes it takes more understanding of the pieces involved to do so.
<rubund> that's fine, thanks for the help. It's clear for me now I guess
<rubund> have a nice day !
<shnatsel> Hello everyone! I see libdee received important fixes back in 2013 (e.g. https://bugs.launchpad.net/dee/+bug/1246263), and while Ubuntu ships packages with the fixes applied, there was no upstream release with them. I'm looking to package an updated libdee for Debian, and I obviously need these fixes, and it seems it would be much easier for everyone to just make an upstream release with them. Whom should I contact to request an upstream release?
<ubottu> Ubuntu bug 1246263 in dee "Race in DeeServer" [Medium,Fix committed]
<ari-tczew> Noskcaj: about bug 1334185, have you tested that package? I guess whether it works fine with upower 0.9.23
<ubottu> bug 1334185 in xfce4-power-manager (Ubuntu) "Please merge 1.3.0-1 from debian" [Undecided,New] https://launchpad.net/bugs/1334185
#ubuntu-devel 2014-07-06
<Whoopie> Hi, as you maybe already know there's a new skype version available. Where can I open a ticket for the partner repository? Thanks for your help.
<alexey> Hi all
<alexey> In my app I should receive SIGPROF signal in 2 threads by posix says that signal is delivered to random thread in process. So, how I can receive it in multiply threads
<popey> hm. Why is this red for over a month? http://ci.ubuntu.com/smokeng/utopic/desktop/
<bluesabre> Hello sponsors!  If anybody is around today, please take a moment to upload this package to trusty-proposed
<bluesabre> https://bugs.launchpad.net/ubuntu/trusty/+source/menulibre/+bug/1323405
<ubottu> Ubuntu bug 1323405 in menulibre (Ubuntu Trusty) "[SRU] Please backport menulibre-2.0.4 to trusty" [Undecided,New]
<bluesabre> Or if you have feedback, I will be available.
<parzzix> Hello, I was wondering on what was going on with Canonicals fork of Trojita? Is there a project pae?
<Guest28109> ØªØ­Ø°ÙØ±
<Guest28109> warning
<Guest28109>  you may be  watched
<Guest28109> do usa&israel use the internet(facebook,youtube,twitter, chat rooms ..ect)to spy??
<Guest28109> do usa&israel use the internet 2 collect informations,,can we call that spying??
<mwhudson> suppose there is an apt repository
<mwhudson> that only publishes lists for binary-amd64
<mwhudson> but all packages in the repository are actuall _all.deb
<mwhudson> is there some sneaky way i can add the repository anyway?
<mwhudson> (on a different arch)
#ubuntu-devel 2015-06-29
<pitti> Good morning
<Unit193> pitti: I have a wily hardware computer that uses this same kernel with kdbus, so I could do some testing there too if it'd help.
<dholbach> good morning
<hallyn> pitti: mbiebl_: hi, around?
<mbiebl_> I am
<hallyn> mbiebl_: cool!  i wanted to ask if there is default behavior for systemd oneshot units where anything started by them is killed when the job is done?
<hallyn> in particular,
<hallyn> lxc-net.service is a type=oneshot which runs a script which starts a dnsmasq.
<hallyn> that dnsmasq seems to just be disappearing;  but if i run the same command by hand as root it persists (as it should)
<mbiebl_> why is it oneshot if it starts a daemon?
<hallyn> well it sets up and configures a bridge
<hallyn> i didn't even consider making that a daemon, maybe it should...
<hallyn> https://github.com/hallyn/lxc/blob/testing/config/init/systemd/lxc-net.service.in  is the current job fwiw
<mbiebl_> and how does it start the dnsmasq daemon?
<hallyn> and https://github.com/hallyn/lxc/blob/testing/config/init/common/lxc-net.in is the script
<mbiebl_> hallyn: if it starts a daemon, it shouldn't be a oneshot type service
<hallyn> The dnsmsq command is:  Kdnsmasq -u lxc-dnsmasq --strict-order --bind-interfaces --pid-file=/run/lxc/dnsmasq.pid --conf-file=/dev/null --listen-address 10.0.3.1 --dhcp-range 10.0.3.2,10.0.3.254 --dhcp-lease-max=253 --dhcp-no-override --except-interface=lo --interface=lxcbr0 --dhcp-leasefile=/var/lib/misc/dnsmasq.lxcbr0.leases --dhcp-authoritative
<hallyn> mbiebl_: lemme try that.  so it should be 'simple'?
<hallyn> or, 'forking'?  /me reads
<mbiebl_> depends on what your daemon does
<hallyn> mbiebl_: so if i make it type=simple, and lxc starts After=lxc-net,
<hallyn> oh wait.  i've made it worse than you think.
<hallyn> so the dameon is started during the ExecStartPre
<mbiebl_> type=simple has one downside
<hallyn> because it needs to complete before lxc, which is After=lxc-net, starts
<hallyn> uh, "completes"
<mbiebl_> the service will be considered started as soon as the process has been spawned
<mbiebl_> it doesn't wait for the service "to be up"
<hallyn> right
<hallyn> so what does starting it in ExecStartPre do with respect to that?
<mbiebl_> hallyn: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778913 has some more details on that behaviour
<ubottu> Debian bug 778913 in openssh-server "openssh-server: init (at least systemd) doesn't notice when sshd fails to start and reports success" [Important,Open]
<mbiebl_> <hallyn> so what does starting it in ExecStartPre do with respect to that? â I don't quite understand that question
<hallyn> 1. wlil the daemon started during ExecStartPre get killed,
<hallyn> 2. will the service be deemed failed bc ther eis no ExecStart,
<hallyn> 3. will lxc then not start unitl the ExecStartPre script is complete
<mbiebl_> ExecStartPre is not supposed to be used to start long running daemon
<hallyn> maybe i'll just call the lxc-net start script from the 'lxc' execstartpre
<hallyn> that seems to make more sense
<mbiebl_> isn't that what you do today?
<mbiebl_> ExecStartPre=@LIBEXECDIR@/lxc/lxc-net start
<mbiebl_> that seems wrong to me
<mbiebl_> ExecStartPre is to to setup your daemon environment
<mbiebl_> the actual daemon should be started via ExecStart
<mbiebl_> from the systemd.service man page
<mbiebl_>            Note that ExecStartPre= may not be used to start long-running processes. All processes forked off by processes
<mbiebl_>            invoked via ExecStartPre= will be killed before the next service process is run.
<mbiebl_> hallyn: I suggest reading the systemd.service man page
<mbiebl_> hallyn: gotta run now
<hallyn> mbiebl_: thanks!
<hallyn> hm, that  still causes the dnsmasq to get killed
<hallyn> apparently ExecStartPre cannot start long-running daemons
<hallyn> hrmp.  "Note that ExecStartPre= may not be used to start long-running processes. All processes forked off by processes invoked via ExecStartPre= will be killed before the next service process is run."
#ubuntu-devel 2015-06-30
<pitti> Good morning
<Unit193> Howdy.
<robert_ancell> pitti, if you were looking to delete more packages I noticed that gnomescan is no longer in Debian and seems effectively dead upstream. So could be cleaned out of wily.
<pitti> robert_ancell: simple-scan FTW!
<robert_ancell> pitti, yeah, I feel a bit biased proposing deleting it... :)
<pitti> oh, gnome-scan
<pitti> robert_ancell: *flush*, it's gone
<pitti> hallyn, mbiebl: I replied to your patch on the lxc ML (might be moderated, but I CC'ed hallyn)
<dholbach> good morning
<jamespage> any chance an archive admin could accepted python-oslo.service into wily? its a sync from debian experimental
<pitti> jamespage: done; will check in a bit for the binaries
<jamespage> pitti, thankyou
 * jamespage goes to raise a MIR :-)
<GunnarHj> darkxst: ping?
<darkxst> GunnarHj, hey
<GunnarHj> darkxst: Sure, I can try to adapt the latest fixes in gnome-desktop3 to 3.16. Is the upstream code in a PPA somewhere?
<darkxst> GunnarHj, I uploaded it to gnome3-staging/wily
<GunnarHj> darkxst: Aha, now I see it. Will do it later today.
<darkxst> GunnarHj, was pretty calm this cycle for gnome-desktop, may just apply as is if your lucky ;)
<GunnarHj> darkxst: Yeah, hopefully I am. :)
<darkxst> GunnarHj, also g-c-c in bug 1466245
<ubottu> bug 1466245 in gnome-control-center (Ubuntu) "Update to 3.16" [Wishlist,Triaged] https://launchpad.net/bugs/1466245
<darkxst> that will be a little tricker I dropped a bunch of code from the languages patch
<GunnarHj> darkxst: Ack. Will look at g-c-c too.
<darkxst> GunnarHj, thanks!
<jamespage> cjwatson, hey - coreycb and I have started to document our workflow using git on launchpad here - https://wiki.ubuntu.com/ServerTeam/OpenStackPackaging
<jamespage> thought you might be interested
<cjwatson> jamespage: Definitely, thanks - looks largely sensible.  Any reason you're recommending named repositories (i.e. with the trailing /+git/liberty-1) for contributors?
<jamespage> cjwatson, that may just be us feeling our way through how things work
<jamespage> cjwatson, that's what coreycb did for his proposed changes for our first milestone this cycle
<cjwatson> You normally only need to use named repositories as a contributor if you have some unusual requirement that causes you to have to use multiple repositories for your contributions, rather than just lots of branches in one repository.
<cjwatson> We're expecting that just /~USER/TARGET is the normal case.
<jamespage> we can try that and see how it works
<jamespage> the awkward bit right now is having to propose three branches for a new upstream release
<coreycb> cjwatson, thanks. I think I got that from the Repository URLs section of https://help.launchpad.net/Code/Git
<cjwatson> coreycb: That documents all the available forms, but you don't have to use them :-)
<cjwatson> coreycb: It does explicitly say that the common case is the owner-default repository, although maybe we should make it clearer and less jargony ...
<cjwatson> (common case for contributors, that is)
<coreycb> cjwatson, ok I'll try it out shortly
<cjwatson> jamespage,coreycb: Anyway, this is a minor-ish point, glad the rest seems to be broadly OK for you.  Have you run into any other oddnesses with Git-based MPs?
<cjwatson> We aren't quite at the point of using them for Launchpad itself, but pretty close
<coreycb> cjwatson, just the bit on proposing a merge as jamespage mentioned.  something command line based would be nice, and having the ability to propose all branch changes in one command would be nice too.
<cjwatson> coreycb: That definitely gets into specific policy, but it should be easily doable using launchpadlib
<cjwatson> git_ref.createMergeProposal is exported
<coreycb> cjwatson, good to know, thanks
<pitti> chrisccoulson: https://launchpad.net/ubuntu/+source/oxide-qt/1.7.9-0ubuntu0.15.04.1 alert
<pitti> chrisccoulson: you SRUed a newer version into vivid without also updating wily, can you please do that too?
<chrisccoulson> pitti, yeah, I'm aware of that. I can't actually upload it myself
<pitti> chrisccoulson: ah, you got sponsored? do you still remember who did that?
<chrisccoulson> pitti, no, these are copied from the security PPA, which I can do
<chrisccoulson> The wily upload is being sponsored right now
<pitti> chrisccoulson: ah, thanks
<chrisccoulson> pitti, it's uploaded now :)
<pitti> chrisccoulson: thansk!
<cyphermox> ubuntu
<cyphermox> haah sorry :)
<ogra_> now we know your password !
<cyphermox> well, only the password to this VM that I keep reinstalling to test multipath :)
<ogra_> yeah, thats what i would say as well now :P
<cyphermox> at least I suffix this with an s to make it more secure on my desktop
<ogra_> heh
<highvoltage> lol
<mdeslaur> cyphermox: wth, you use my laptop password as your vm password?
<cyphermox> yup
<cyphermox> great minds thing alike.
<davmor2> cyphermox: ubuntu isn't the safest password here use mine Ubuntu see the capital U much safer with that there ;)
<jpds> davmor2: I use "ubunut' these days.
<davmor2> jpds: man you just the king of password
<ogra_> you could add double security and use "Ubunut"
<davmor2> ogra_: you're just trying to steal jpds 's password thunder
<ogra_> ssshhhh
<jrwren> people use passwords?
<jrwren> ah, nevermind. my ssh key has a password :)
<davmor2> I bet it is really secure something like hunter2
<davmor2> I'm so glad that IRC hides you're passwords and ogra_ told me all about it :)
<ogra_> yeah, the backlog above is full of ****** everywhere !
<mdeslaur> and here I just changed mine from "os2forever" not too long ago
<ogra_> even more ********** !
<davmor2> ogra_: hahaha nicely played good sir nicely played :)
<jrwren> http://shetterly.blogspot.com/2012/04/expanded-stephen-fry-on-being-offended.html
<davmor2> ogra_: be careful on how you copy and paste those ************* though you might not like what it says to you ;)
<jrwren> sorry, misdir
<tkamppeter> jdstrand, hi
<sarnold> tkamppeter: jamie's out for the week
<tkamppeter> mdeslaur, hi
<mdeslaur> tkamppeter: hi
<tkamppeter> mdeslaur, it is about bug 1455644, it is a MIR for ippusbxd, the IPP-over-USB printer daemon. I have posted it some weeks ago, jdstrand has assigned it to himself and then nothing happened any more.
<ubottu> bug 1455644 in ippusbxd (Ubuntu) "[MIR] ippusbxd" [Undecided,New] https://launchpad.net/bugs/1455644
<mdeslaur> tyhicks: that's for you ^
<tkamppeter> mdeslaur, probably he has taken it to check security aspects. Now jdstrand is on vacation. Can you have a look.
<mdeslaur> tkamppeter: tyhicks will assign it to someone
<tkamppeter> mdeslaur, thanks.
<tyhicks> sorry, I must have missed the irc notification
<tyhicks> tkamppeter: hi - I've now added that MIR to our backlog tracker
<tyhicks> tkamppeter: note that there are a few other MIR security audits (and some other work) ahead of it
<tkamppeter> tyhicks, thanks, but it will get done before FF?
<tyhicks> tkamppeter: hopefully but we can still promote packages to main after FF
<barry> cjwatson: you wouldn't happen to still be around would you?
<hallyn> is there a set of tools to script the updating of /etc/pam/* files from packages?
<sarnold> there's a pam-auth-update, I've never used it myself though..
<cjwatson> barry: yeah, sort of, late meeting
<barry> cjwatson: ah, thanks.  question: the order of entries in /etc/apt/sources.lists matters when searching for a package to install, with entries in /etc/apt.sources.d/* coming after sources.list... right?  do the ppas set those repos up to prefer packages from the ppa if the versions class with archive versions?  and if so, how?  (trying to reproduce locally)  or am i on crack?
<barry> *clash
#ubuntu-devel 2015-07-01
 * hallyn gets comfy with pam-configs
<pitti> Good morning
<Unit193> Howdy.
<dholbach> good morning
<pragomer> hello. why does this simple udev-rule not work when I plug my usbstick on: http://pastebin.com/r24CuJk1
<pitti> pragomer: is it actually sdc1? check with "udevadm monitor -e --udev" when you plug in the stick
<pitti> pragomer: and after it's plugged, "sudo udevadm test /block/sdc1"
<pragomer> yes it is always sdc because a and b are ssd harddisks
<pragomer> what should your 2nd syntax return?
<pitti> pragomer: it should show you that your rule is being executed
<pitti> .. or not, presumably
<pragomer> yes it is executed
<pragomer> so should this very simplified rule normally work ?   http://pastebin.com/r24CuJk1
<pragomer> work with "sdc1" ? or is this a wrong syntax?
<pitti> pragomer: yes, it should work
<pitti> (although that's of course nothing you'd ever put in production)
<pragomer> no.. not in production... its for finding the error in the rule I really want to create
<pitti> pragomer: so do you have a /tmp/folder1?
<pragomer> so.. you have an idea why this does not work?  changing the rule does not need a reboot, or?
<pragomer> no, no subfolder "folder1"... there is just the system-immanent folder /tmp
<pitti> pragomer: you just said that it is being run in udevadm test, so should be fine
<pitti> pgraner: you can try with sudo udevadm control --reload
<pitti> pgraner: sorry, tab error
<pragomer> at the end there is "read rules file: /lib/udev/rules.d/99-myownrule.rules"
<pragomer> but it outputs an error
<pragomer> unable to open device '/sys/block/sdc1'   unload module index
<pragomer> at the very end
<pitti> pragomer: do you actually have a /sys/block/sdc1? and a /dev/sdc1?
<pragomer> mm... I have , of course,  /dev/sdc and /dev/sdc1    but under /sys/block I have just sdc
<pragomer> not sdc1
<pragomer> dont know the meaing of /sys/block
<pitti> how very weird
<pitti> pragomer: /sys/ has the devices that the kernel sees
<pragomer> ah ok
<pitti> pgraner: please pull out the stick, run "dmesg -w", plug it in, and pastebin the output
<pitti> (the new output)
<pragomer> dmesg: UngÃ¼ltige Option -- w
<pragomer> (german for not valid option)
<pragomer> is -w correct?
<pragomer> pitti: dmesg -w is not a valid command?
<cjwatson> barry: Sorry, I didn't manage to answer last night after all ... all other things being equal apt will prefer earlier entries in sources.list; I haven't checked about sources.list.d but I assume it comes after sources.list.  It's never occurred to me to need to force a PPA to win despite version clashes; if I wanted to do so I think I'd use apt preferences to pin the PPA above the primary archive (and debug carefully with "apt-cache ...
<cjwatson> ... policy" because I usually get pinning wrong first time)
<Faux> I'm keen to see nginx 1.9 synced from Testing into Wily.  I understand that it's not as there's "customisation" on the ubuntu package (it has a 1.6.2-5ubuntu3 version number).  Where can I find out more about what this means, and what's the best non-coding way to get this unblocked, i.e. is there a type of bug I can raise, or mail a mailing list, or..?
<cjwatson> teward: ^-
<rbasak> Faux: you might want to read https://lists.ubuntu.com/archives/ubuntu-server/2015-June/007072.html - whether we're going to be going to 1.9 is still an open question right now.
<Faux> Ah, right, that's the kind of thing I was looking for.  Cheers.
<pitti> cjwatson, jibel, infinity: I'm trying to understand britney's autopkgtest integration; for testing that locally, merely running "./britney.py  -c britney.conf --dry-run" fails because data/SERIES/Sources does not exist -- what creates that?
<pitti> on snakefruit it looks like the concatenation of Packages_/Sources.gz of all components
<pitti> I suppose this comes from something like chdist, but I don't see how (chdist in particular isn't called anywhere)
<cjwatson> pitti: That's created by the britney1 scripts
<cjwatson> lp:~ubuntu-release/britney/britney1
<pitti> cjwatson: ah, ok; so for local testing of britney2-ubuntu, I'll just copy them from /var/lib/apt/lists, I figure?
<cjwatson> lp:~ubuntu-release/britney/britney1-ubuntu, sorry
<cjwatson> That used to contain the actual code, but then that all got rewritten separately, and now britney1 is basically just wrapper stuff
<cjwatson> pitti: That would be fine, yes
<pitti> cjwatson: ok, thanks!
<pitti> cjwatson: ok, got that; now it fails on IOError: [Errno 2] No such file or directory: 'data/wily-proposed/Blocks'
<cjwatson> See britney1-ubuntu :-)
<pitti> ok
<cjwatson> It fishes that out of Launchpad.  There are one or two other such files I think
<cjwatson> For Dates you probably just want to copy that off snakefruit
<pitti> ah, seems an empty file does just fine; now I'm at the point where it tries to call autopkgtest, which is where I want to be at :)
<pitti> cjwatson: thanks!
<cjwatson> YW
<pitti> ah, that's what the test suite does too (create empty Blocks, Dates, Hints)
<GunnarHj> darkxst: Hi Tim!
<GunnarHj> darkxst: You realize that those g-c-c changes have not been tested, right?
<darkxst> GunnarHj, no, but I will push them to the ppa tomorrow
<darkxst> its still blocked on g-o-a anyway
<GunnarHj> darkxst: That's what I mean - I couldn't build it for that reason.
<darkxst> g-o-a is in the ppa
<darkxst> though guess I am the only one with ppa enable sbuild
<darkxst> but if you upload to a ppa that depends on gnome3-staging it should work
<GunnarHj> darkxst: Is it? Missed that. Anyway, think it's better that you build in the PPA as a next step. Please let me know if there is a problem with 'my' part.
<darkxst> actually g-o-a is in proposed, so that shouldnt have cause a build failure anyway? anyway yes I will test build it before uploading to the ppa
<darkxst> not tonight though
<GunnarHj> darkxst: g-o-a i uploaded to -proposed but not built there - waiting for libwebkit2gtk-4.0-dev
<darkxst> GunnarHj, ah yes right, thats why I copied it to gnome3-staging
<darkxst> GunnarHj, anyway don't worry, I will deal with it in the morning
<GunnarHj> darkxst: Great, then I can sleep well tonight. ;) Thanks!
<darkxst> GunnarHj,I need sleep now, been a long day ;(
<GunnarHj> darkxst: Realize that. Sleep well.
<barry> cjwatson: thanks.  hadn't thought about pinning.  i bet it's usually not a problem, but in my case, since i'm copying packages from the primary archive, versions in the ppa can conflict, and it can matter when the ppa version has additional build artifacts (e.g. py35 .so's)
<barry> cjwatson: it *seems* like the ppa is doing the right thing, although i have no idea how :)
<cjwatson> barry: Ah, I didn't quite grasp that you were talking about builds within the PPA.
<cjwatson> barry: Launchpad writes out a custom sources.list for every build, and the context archive (i.e. the PPA in this case) is always placed first.
<barry> cjwatson: that makes perfect sense, thanks!  for "normal" ppas it probably doesn't matter and i can repro this behavior locally with a --chroot-setup-commands
<arges> hallyn: working on next libvirt upload for trusty. Merging fixes. So far I have: 1425619 (re enable migration patch), 1455608, and 1464175. Do you know of any others I should merge in there?
<hallyn> 1342083 and 1386465 ?
<hallyn> arges: are those all the ones which were in zul's pkg?
<arges> hallyn: sorry, this is an SRU upload for trusty
<arges> hallyn: i have the merge open in another tab... but getting this done first
<hallyn> arges: oh!  one sec,
<arges> ok
<hallyn> how did you do 1455608 ?
<hallyn> di dyo update the sysv script or take the whole init script update?
<arges> hallyn: i took the changes for both upstart and libvirt-bin.init
<hallyn> arges: list looks good - thanks!
<arges> np
<xnox> barry: apt-pinning etc. work but when all things are equal, the order of sources.list matters with first one winning.
<barry> xnox: yep, and although it's not documented, sources.list.d entries come after that.  i'm guessing that the order within s.l.d entries is either alphabetical or random.  so the only way to guarantee an order is to rewrite sources.list, which is easy enough
<xnox> barry: i bet it's readdir order
<mitya57> sil2100, hi, I have filed a couple of appmenu-qt5 MPs for you, please review them if you can
<mitya57> all that code will be removed in Qt 5.5, but I want these fixes a bit earlier :)
<mitya57> I'm also going to backport it to sni-qt
<sil2100> mitya57: oooh! Thanks, I still didn't find time to pick up some of my branches, maybe it's finally time to do that
<mitya57> these branches are to match the spec more closely
<sil2100> mitya57: excellent, I guarantee that those will be reviewed by tomorrow, I finally need to assign a day for desktop duties
<sil2100> And I guess it's time
<mitya57> sil2100: No need to hurry, but thanks anyway!
<sil2100> mitya57: thanks for the branches!
<seb128> stgraber, hey, I retried a desktop-next build from the iso tracker yesterday, that failed due to livecd-rootfs issues, but it seems that the tracker is stucked on "rebuilding" now and that new rebuild tries are not working?
<ogra_> seb128, i think you need to explicitly stop them on the tracker
<ogra_> (iirc ... its a while ago that i had to use that)
<seb128> ogra_, I guess I could try that, waiting for stgraber to confirm in case he wants to look at the current state first
<ogra_> iirc LP doesnt give feedback for failed builds (at least not to the tracker)
<seb128> ogra_, cancelling doesn't work
<barry> xnox: can you push lazr.restfulclient 0.13.4 to pypi?
#ubuntu-devel 2015-07-02
<seyeongkim> I found that the problem with "-Wl,-Bsymbolic-functions" option in autofs pkg. the other pkgs have no problem with this? https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1470687
<ubottu> Ubuntu bug 1470687 in autofs (Ubuntu) "Not working properly with compile options "-symbolic-functions"" [Undecided,New]
<dholbach> good morning
<Saviq> seb128, any idea where to file a bug about Compose not working?
<Saviq> actually /me tries in a guest account
<Saviq> crap, works in a guest account, wonder what breaks it in mine
<seb128> Saviq, not really, did you try to force set manually using setxkbmap?
<seb128> hum, so likely user config issue...
<Saviq> seb128, yeah, xev reports Multi_key correctly
<Saviq> but chars get typed in as usual regarless
<Saviq> +d
 * Saviq was thinking about busting $HOME, maybe it's time...
<Saviq> would be good to find the problem in any case...
<jamespage> wgrant, cjwatson: I've had a few packages in 14.04 main highlighted to me with "Supported: 9m" - is that a bug of some description?
<cjwatson> jamespage: That appears to be deliberate in the code for things that are merely in some ordinary kind of supported seed (or an extra binary that's just built from the same source as something seeded) rather than in something that's a child of {server-ship, supported-server, ship, supported-desktop, supported-desktop-extra}
<jamespage> cjwatson, ok - let me dig further
<jamespage> cjwatson, interestingly the first on the list is cliff-tablib - its a used for testing python-neutronclient so is a BD only
<cjwatson> Right, supportedness is pretty irrelevant there.
<cjwatson> We can't really fix this after the fact anyway :)
<jamespage> cjwatson, yeah - I gave the message back that this was not a problem
<jamespage> cjwatson, I've never seen anyone pick through those fields before :-)
<doko> jamespage, could you have a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777814 ?
<ubottu> Debian bug 777814 in src:ceph "ceph: ftbfs with GCC-5" [Serious,Open]
<jamespage> doko, yes
<doko> ta
<seb128> wgrant, dpm, pitti: what's the status of langpacks in wily? are translations open? can we get exports?
<dpm> hi seb128, I've not done anything with wily translations myself, let me ping the LP folks to see if the imports are set up before opening translations
<seb128> dpm, yeah, that's why I included wgrant in the ping ;-)
<seb128> but I guess cjwatson might know as well
<pitti> seb128: nothing yet on https://translations.launchpad.net/ubuntu/wily/+language-packs :(
<dpm> seb128, ah, yes, didn't notice. I asked Colin on #launchpad in the meantime
 * seb128 joins launchpad
<rbasak> I think I've finally pinned down an elusive bug.
<rbasak> logger(1) closes stdin if no log daemon is running, although only when not running systemd (presumably that listens to /dev/log or whatever)
<rbasak> mysql-server-5.6.postinst pipes various bootstrap commands to logger.
<rbasak> The bootstrap commands do not work when their stdout is closed, leading to future failure.
<rbasak> Is this a bug in logger, which should instead silently throw away stdin instead of closing it and exiting 0 or something, or a bug in the mysql bootstrap commands which should succeed even if they get stdout closed on them?
<rbasak> POSIX doesn't seem to have anything to say about this.
<rbasak> Though it doesn't define the stdin use at all, so the fact that we're using logger's stdin at all is an extension to POSIX.
<jamespage> doko, hey - can we run that against the ceph in experimental?
<jamespage> that being gcc-5
<doko> jamespage, not automagically
<jamespage> doko, I'll look to fix in 0.94.2
<wgrant> dpm, pitti, seb128: wily translations aren't copied yet. I can arrange that tomorrow.
<dpm> awesome, thanks wgrant
<seb128> wgrant, that would be nice, thanks
<pitti> bdmurray: http://d-jenkins.ubuntu-ci:8080/job/wily-adt-python3.5/?
<bdmurray> pitti: hmm?
<pitti> bdmurray: sorry, that was meant for barry
<pitti> bdmurray: I guess I saw you come into mumble and my brain somehow failed
<barry> pitti: dang, my vpn isn't up atm
<pitti> barry: same on public jenkins :)
<unixpro1970> can anyone recommend a free source code call flow viewer for c/c++ code for linux? Something like this https://scitools.com/
<pitti> slangasek, infinity: I'd appreciate a review on https://code.launchpad.net/~pitti/britney/britney2-ubuntu-amqp/+merge/263679
<pitti> barry: \o/ http://autopkgtest.ubuntu.com/packages/p/python3.4/wily/i386/
<pitti> barry: (2.7 and 3.5 had some tmpfail due to cloud limits, I'll work on those)
<barry> pitti: \o/
 * pitti waves good night
<Laney> stgraber: any chance you can look into why the tracker isn't cancelling the re-build status for failed desktop-next builds? (also cancelling them from the tracker doesn't stick either)
<ogra_> Laney, i dont think it ever did
<stgraber> Laney: did you try canceling from nusakan?
<Laney> stgraber: I did, it works
<stgraber> Laney: you can only cancel from the tracker in the first few minutes, once nusakan acknowledges the build, it can't be canceled anymore
<Odd_Bloke> Does anyone know the status of getting a more recent pip in to Debian/wily?
<Odd_Bloke> (barry?)
<Laney> stgraber: right, so that part isn't a bug then but I suppose that not noticing the build failed and clearing the state is
<bdmurray> rbasak: If you run apt-get update, then does apt-cache policy show different information in the Version table?
<stgraber> Laney: yeah, on failure the cdimage code on nusakan is supposed to set the state as failed
<odell> So what's the best way to get into developing for Ubuntu?
<tjaalton> should the installer know how to resize nvme partitions?
<tjaalton> I got a machine with windows preinstalled and would like to keep it, but the only option on the installer seems to be to wipe it out
<tjaalton> oh well, shrunk the ntfs volume from win10
<rbasak> bdmurray: no, but apt-get update largely fails because of the read-only filesystem and some 404 errors.
<rbasak> bdmurray: I want to keep this phone on stable and image-based updates and I don't really understand the implications of remounting read-write.
<bdmurray> rbasak: sorry, I sorted it out.
<rbasak> bdmurray: np. Thank you for looking!
<odell> exit
#ubuntu-devel 2015-07-03
<pitti> Good morning
<dholbach> good morning
<LocutusOfBorg1> hi cjwatson did you break anything on git import code? :)
<LocutusOfBorg1> https://code.launchpad.net/~blueyed/boinc/pkg-boinc
<LocutusOfBorg1> seems broken since yesterday
<LocutusOfBorg1> should I report a bug?
<smb> Oh, while I remember: could the person that accepted grub2 updates into Trusty proposed also add the grub-signed please?
<rbasak> tjaalton: ^^ - not sure of the process for the signed grub stuff.
<tjaalton> smb, rbasak: I'll check it out
<rbasak> tjaalton: thanks! If I'm supposed to have done something, please let me know.
<tjaalton> rbasak: well, I don't see grub-signed there
<smb> There is some manual step one has to do... not sure which exactly
<rbasak> I get the impression someone needs to upload a no change rebuild of grub-signed or something?
<smb> I only notice it everytime because I got proposed enabled and apt-get offers to uninstall my signed grub for me
<tjaalton> cjwatson: ^
<rbasak> Ah, Build-Depends bump too?
<tjaalton> maybe any core-dev can do that though
<rbasak> (and it's grub2-signed)
<tjaalton> cjwatson: unping :)
<tjaalton> also, it's been infinity doing the rebuilds, yay google search showing the precise pkg
<smb> rbasak, oops yeah, sorry omitted the 2
<tjaalton> rbasak: so, upload the rebuild and i'll ack it
<rbasak> tjaalton: OK, but I'd like to just make sure that this is the correct thing to do. Can cjwatson or infinity or someone confirm please?
<tjaalton> looking at the changelog I'd say yes
<rbasak> I agree from the changelog, but I'd just like to make sure I'm not missing some other step that isn't evident from the upload.
<tjaalton> ack
<cjwatson> LocutusOfBorg1: gpgsig in a new commit, you're out of luck now
<cjwatson> LocutusOfBorg1: https://bugs.launchpad.net/launchpad/+bug/1084403
<ubottu> Ubuntu bug 1084403 in bzr-git (Ubuntu) "no support for gpgsig tags" [High,Triaged]
<cjwatson> rbasak: rebuilding with a suitable version and bumping Build-Depends is fine
<LocutusOfBorg1> yes cjwatson I discovered the bug while trying to report a new one, sorry for the noise
<rbasak> cjwatson: thanks, I'll do that now then.
<Unit193> doko: I don't suppose you'd sponsor a QA upload for a gcc5 fix, would you?  http://mentors.debian.net/debian/pool/main/o/oidentd/oidentd_2.0.8-7.dsc
<rbasak> tjaalton: grub2-signed uploaded (precise, trusty, utopic, vivid)
<tjaalton> rbasak: thx
<smb> thanks
<rbasak> (for anyone who cares, I hacked up a script to save myself from mistakes and for next time: https://git.launchpad.net/~racb/+git/tools/tree/grub2-signed/go)
<doko> Unit193, the package still ftbfs
<Unit193> Really?  I may have broken my gcc5 chroot then.
<Unit193> Hrm seems fine..
<doko> no, it fails with the default gcc
<doko> you should mark the function with the inline attribute
<Unit193> doko: Read, updated, tested on gcc5 and gcc4 this time (sorry), re-pushed.
<Unit193> Thanks.
<ricotz> doko, hi :), what is up with "util-linux" which openjdk-8 depends on?
<ricotz> * the newer "util-linux"
<ricotz> pitti, hi :) ^
<pitti> I guess we need to merge it then :)
<doko> well, just using the mountpoint utility there
<pitti> ah, did stuff get moved around further?
<Unit193> doko: But, would the new oidentd be a QA upload you could sponsor? :)
<pitti> is it enough to merge this on Monday? (I'll make a note)
<pitti> as it probably involves a sysvinit merge/upload too, and I don't want to start on that on a Friday afternoon
<cyphermox> good morning!
<Unit193> Howdy, cyphermox.
<cyphermox> Unit193: how are you?
<Unit193> Bit tired and glazed.  You?
<cyphermox> good :)
<infinity> doko: util-linux is Essential, depending on it doesn't make much sense there, since we don't intend to retroactively fix the "mountpoint might not exist" bug in older releases, I assume.
<pitti> well, older releases just had it in sysvinit-utils, wasn't that also essential (or at least required)?
<infinity> pitti: It was required, but not essential, which was the bug.
<infinity> pitti: And, actually, it was in initscripts, IIRC, which was even easier to get rid of.
<infinity> pitti: Anyhow, I'm looking at these merges, since it should also come with a change to mac-fdisk that no one made in Debian.
<hallyn> arges: around?
<hallyn> (prolly not, but worth a check :)
<hallyn> will send an email
<infinity> pitti: How/where do I configure what systemd-timesyncd syncs against?
<infinity> pitti: Ahh, in a config file we don't ship.  So, follow up question, what does it do with no config?
<infinity> pitti: And debian/rules sorted that one for me.  No more questions. :P
<infinity> pitti: Also, took care of your util-linux and sysvinit merges.
#ubuntu-devel 2015-07-04
<RPiAwesomeness> Can someone take a look at my patch here: https://code.launchpad.net/~aeves-nate/ubuntu/trusty/mydumper/fix-for-1402381/+merge/263835?
<RPiAwesomeness> For whatever reason the diff is showing changes being made to 20 files even when I only removed 4 characters from one file.
<RPiAwesomeness> And I am confused.
<RPiAwesomeness> It's my first patch and I want to make sure I'm doing it right
<tarpman> RPiAwesomeness: it looks like you based your patch on a newer version than trusty has; perhaps you started from 'bzr branch lp:ubuntu/mydumper' instead of 'bzr branch lp:ubuntu/trusty/mydumper'?
<RPiAwesomeness> I did. Should I have started from trusty/mydumper?
<tarpman> RPiAwesomeness: depends. is the bug already fixed in utopic and later?
<TJ-> RPiAwesomeness: you need to fix the email address you've set, it is invalid (see debian/changelog)
<RPiAwesomeness> tarpman: I can't tell from the LP bug report: https://bugs.launchpad.net/hundredpapercuts/+bug/1402381
<ubottu> Ubuntu bug 1402381 in mydumper (Ubuntu) "Duplicate option -k" [Medium,Confirmed]
<RPiAwesomeness> It mentions vervet
<RPiAwesomeness> At least as a tag
<tarpman> RPiAwesomeness: the linked debian bug does not appear to be fixed yet; IMO the best way to solve this bug would be to post a patch to the debian bug, let it get synced from unstable into development, and then prepare stable update (SRU) patches
<tarpman> er, from unstable into wily
<RPiAwesomeness> tarpman: So, post the patch I made on the Debian bug tracker?
<tarpman> maybe even directly upstream, if the upstream code is also affected
<tarpman> point being, try to fix it as close to the source as possible in order to reach all affected users, rather than for example only ubuntu users
<RPiAwesomeness> Okay. So, where would I access the upstream code? This is my first time doing anything patch-related :P
<tarpman> the upstream project seems to be https://launchpad.net/mydumper
<tarpman> (lp:mydumper)
<tarpman> RPiAwesomeness: is https://bugs.launchpad.net/mydumper/+bug/1428608 the same as your bug?
<ubottu> Ubuntu bug 1428608 in MySQL Data Dumper "missing -K option in mydumper manpage" [Low,Fix committed]
<RPiAwesomeness> Nope, that's *adding* the -K option
<RPiAwesomeness> Actually, -k and -K
<RPiAwesomeness> Could be capitalization
<RPiAwesomeness> Hmm...
<RPiAwesomeness> Aha. Yup, it's been fixed upstream.
<RPiAwesomeness> Shucks. And I thought I was being useful :(
<RPiAwesomeness> One should be -K and the other -k, upper and lower case
<tarpman> RPiAwesomeness: ok, fixed upstream already is good. so if you just wait, eventually the debian maintainer will update it in debian, and ubuntu will pick it up automatically
<tarpman> RPiAwesomeness: if you want it in ubuntu sooner, you should propose a merge into the development release (wily), not a stable release
<tarpman> hope that makes (some) sense
<RPiAwesomeness> So, bzr branch lp:mydumper then bzr commit lp:~aeves-nate/ubuntu/wily/mydumper/fix-for-1402381 then bzr lp-propose?
<RPiAwesomeness> bzr commit AFTER cd-ing into the mydumper directory of course
<tarpman> bzr branch lp:ubuntu/mydumper
<tarpman> as you're proposing the fix for ubuntu, not for upstream
<RPiAwesomeness> Ah
<RPiAwesomeness> k
<RPiAwesomeness> Just to make sure I've got this, I run bzr branch lp:ubuntu/mydumper, make the patch, then commit to lp:~aeves-nate/ubuntu/wily/mydumper/fix-for-1402381?
<tarpman> sounds right. assuming "make the patch" means "add a new quilt patch in debian/patches" and not "patch the upstream source directly"  (I have lost the tab with your previous merge in it...)
<RPiAwesomeness> Yes, sorry.
<tarpman> personally I usually skip this bzr stuff and just post debdiffs to bugs, so I might be missing some details
<RPiAwesomeness> tarpman: Did I do it right? https://code.launchpad.net/~aeves-nate/ubuntu/wily/mydumper/fix-for-1402381/+merge/263837
<RPiAwesomeness> Because I feel like I didn't :P
<tarpman> RPiAwesomeness: per TJ-'s comment above, please fix your email address
<RPiAwesomeness> Sorry, will do that.
<tarpman> RPiAwesomeness: please don't include changes to .pc/ or to the upstream files
<tarpman> RPiAwesomeness: and the new patch itself was not included, looks like
<RPiAwesomeness> But the tutorial here: http://packaging.ubuntu.com/html/fixing-a-bug.html said to?
<RPiAwesomeness> I'm so confused right now :P
<RPiAwesomeness> Bother, this stuff is complicated
<RPiAwesomeness> The patch wasn't included? Bah.
<tarpman> oh, you're right. sorry, yes, that one does seem to be in bzr with patches applied. ok, ignore me on that one
<tarpman> file under "tarpman doesn't do bzr merges, usually" :D
<RPiAwesomeness> Phew :D
<RPiAwesomeness> Okay, I think I'm starting to see how bzr works. I've only ever used git before, starting to see what's the comparable things
<RPiAwesomeness> tarpman: But I did propose the merge to the correct lp repo?
<tarpman> I think so. can't double-check since you deleted it again ;)
<RPiAwesomeness> Yeah, going to re-propose it with the changelog changed
<RPiAwesomeness> https://code.launchpad.net/~aeves-nate/ubuntu/wily/mydumper/fix-for-1402381/+merge/263839
<RPiAwesomeness> Should be correct now
 * RPiAwesomeness crosses fingers
<RPiAwesomeness> tarpman & TJ-: Thanks for the help :)
<tarpman> one more, sorry: you haven't closed your bug in the changelog
<tarpman> that's easy, just add (LP: #1402381) at the end
<ubottu> Launchpad bug 1402381 in mydumper (Ubuntu) "Duplicate option -k" [Medium,Confirmed] https://launchpad.net/bugs/1402381
<RPiAwesomeness> Ooooh
<tarpman> iirc bzr also has some option that you should use to mark it as associated with that bug
<tarpman> --fixes lp:1402381 or something like that
<TJ-> correct
<RPiAwesomeness> TJ-: If I bzr commit and already have proposal going, will that proposal automatically reflect my newest push?
<RPiAwesomeness> bzr commit followed by bzr push to my launchpad that is
<TJ-> RPiAwesomeness: I'm not sure... I seem to recall it may do when I last did that, but I may be imagining it
<RPiAwesomeness> Okay. I think it does, just wanting to make sure.
<TJ-> Because I think the merge proposal tracks the branch
<RPiAwesomeness> That would make sense
<RPiAwesomeness> Anyways, thanks for your help. I need to go do something else other than stare at a screen filled with debian, bzr, and patch stuffs for a bit.
<RPiAwesomeness> O.O is mine eyes
<TJ-> I know the feeling... git doesn't have that effect on me thankfully :)
#ubuntu-devel 2015-07-05
<boodllebat> i have query regarding paste.ubuntu.com , does it support chunked http post cause i'm trying but it does not work accordingly
<TJ-> boodllebat: I've reported it with a test-case, but it's an internal Canonical project so not sure this is the correct channel to get attention for it: bug #1471570
<ubottu> bug 1471570 in Canonical Pastebin "500 Internal Server Error" [Undecided,Confirmed] https://launchpad.net/bugs/1471570
<boodllebat> TJ-: thanks :)
<xpheres> hi
<xpheres> I managed to import a web app to the ubuntu sdk in qt
<xpheres> I'm able to run it but not to build it
<xpheres> how can I build it and deploy and why is the build button not available?
<TJ-> boodllebat: You might want to ping the owner of the project directly, see https://launchpad.net/canonical-pastebin
<xpheres> hi
<xpheres> I'm stuck with qt, I can't add a kit neither build an app
<xpheres> hi
<xpheres> is it possible to run a ubuntu touch app from qt triggering the emulator?
<xpheres> or how can I run a click app in the emulator?
<LHG-Master> If I build a ubuntu package my debian/postinst script is simply ignored by "bzr builddeb -- -us -uc". If I look into the created .deb package (with gdebi-gtk) the contents of postinst is limited to "set -e + (dh_icons output)" but not my debian/postinst script. No error from lintian, no related error from "bzr builddeb". Also tried "bzr add postins" + "bzr commit postint" but did not help. Any idea?
<cjwatson> LHG-Master: The best thing would be to post the source package (the .dsc plus any files it references) somewhere people can see.
<cjwatson> I think "bzr builddeb -- -us -uc" builds one in the process, but if not, "bzr builddeb -S -- -uc -us" will.
<RPiAwesomeness> bzr buildeb -- -us -uc does
<LHG-Master> https://launchpad.net/~linux-hardware-guide/+archive/ubuntu/ppa/+packages
<cjwatson> LHG-Master: OK, so you said "bzr add postins" + "bzr commit postint".  Both of those are mistyped, and probably lacking a directory name too.  What did you actually type, exactly?
<cjwatson> debian/postinst indeed isn't in your source package anywhere.
<cjwatson> Which leads me to suspect that you didn't manage to add it.
<cjwatson> You should also check the output of "bzr status" to see if bzr thinks you have any uncommitted stuff in your source tree.
<LHG-Master> sorry those were typos. I think it has something to do with the following: if I am in my build dir and type "bzr status" is shows "unknown:[...]  debian/postinst". But  after "cd debian/" the file "postinst" is not shown when I type "bzr status"
<LHG-Master> but if I enter "bzr add postinst; bzr commit postint" in debian/ I get "bzr: ERROR: No changes to commit..."
<cjwatson> Why wouldn't you just do "bzr add debian/postinst" from the top level?
<RPiAwesomeness> ^
<LHG-Master> Maybe I messed up somehow my bzr repository
<cjwatson> It also sounds like you might perhaps have a debian/.bzr
<LHG-Master> also tried this: same error "bzr: ERROR: No changes to commit."
<cjwatson> "bzr add debian/postinst" and then "bzr status"
<cjwatson> And you don't need to give a file name to "bzr commit" unless you have other stuff in your tree you don't want to commit - it's just one more thing to typo
<LHG-Master> yes, there is a debian/.bzr. Is this a problem?
<cjwatson> It's going to confuse you mightily
<cjwatson> You shouldn't try to version-control the same directory in two different ways
<cjwatson> Decide whether you want to version-control the whole tree (this is my recommendation) or just debian/
<cjwatson> If the former, move debian/.bzr to some safe place
<cjwatson> I suspect if you try to version them separately then various tools are going to misbehave
<cjwatson> After moving it, "bzr status" to see what chaos exists
<cjwatson> In fact just generally "bzr status" liberally, it's handy
 * cjwatson â games
<LHG-Master> Ahh!  I removed debian/.bzr and now postinst changed from status "unknown" to "added" after "bzr add debian/postinst". Seems this fixed it
<cjwatson> Good good
<LHG-Master> I think this fixed it. Thanks!
<cjwatson> np
<xpheres> hello, does anyone have an ubuntu phone to test an app?
<Noskcaj> Can someone please retry clutter-gtk in wily-proposed?
<Noskcaj> also gnome-boxes, and maybe lxappearance-obconf
<cjwatson> Noskcaj: all done
<Noskcaj> ty
#ubuntu-devel 2016-07-04
<tjaalton> huh, xenial update shut down my desktop midway during upgrade
<pitti> Good morning
<smb> morning... *sigh* another week another partial upload for grub2 to trusty...
<ricotz> hmm, the gcc-5 upgrade in xenial-proposed is quite large, seems it wasn't properly stripped
<pitti> ricotz: oh, thanks for pointing out; that's a backporting error
<pitti> ricotz: doko often keeps debugging stuff on in devel, but that shouldn't happen in stable
<pitti> ricotz: err, is it?
<pitti> 8548582 vs. 8548494 bytes, that's not much difference
<pitti> oh, cpp-5
<ricotz> pitti, yeah, I was referring to the source package
<ricotz> so g++-5 and cpp-5 are not stripped
<pitti> ricotz: thanks, I adjusted bug 1586673
<ubottu> bug 1586673 in gcc-5 (Ubuntu Xenial) "Backport GCC 5.4.0 and binutils 2.26.1 to 16.04 LTS" [Undecided,Fix committed] https://launchpad.net/bugs/1586673
<pitti> jamespage: hey!
<pitti> jamespage: is the server team still interested in floodlight? it's been FTBFS for several cycles, not getting along with our current java
<pitti> it's not in Debian either
<pitti> infinity: yay, latest Debian dpkg now has the Test-Depends: stuff; do you want to do the merge (as you TIL), or want me to?
<infinity> pitti: I'll grab it.
<flexiondotorg> Morning.
<flexiondotorg> Can I request a little help progressing a few SRUs?
<flexiondotorg> They are intended for 16.04.
<flexiondotorg> I've got a couple of seemingly conflicting feedback. One bug I've been asked to open an additional but, which I'm happy to do although I don't understand what I'm being asked to do.
<flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1581168
<ubottu> Launchpad bug 1581168 in ubuntu-mate "SRU: GTK3 scrollbars in Radiant-MATE not styled like GTK2" [High,Fix committed]
<flexiondotorg> And bug I'm being asking to track the SRU in just one bug, not two. Again, happy to do that.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1577706
<ubottu> Launchpad bug 1577706 in ubuntu-mate-settings (Ubuntu) "SRU: ubuntu-mate-settings 16.05.5.2 bug fix" [Undecided,Invalid]
<flexiondotorg> I'd just like to better understand the correct way to progress SRUs in the future.
<infinity> pitti: Ooo, lots of reproducibility patches in this upload too.
<pitti> infinity: indeed, this looks like "want it"
<infinity> pitti: Yeahp, just going over the diff and merging now.  Keynotes don't need my full attention. :P
<pitti> infinity: ah, you're at debconf too? enjoy!
<infinity> pitti: *nod*
<pitti> infinity: our 119kB patch is almost exclusively teh changelog :)
<pitti> actual changes are fairly small these days, fortunately
<infinity> pitti: I know, I've been TIL for a long time, and I take pride in that diff.
<infinity> pitti: It was several MB when I took it over. :P
<pitti> *clap* *clap*
<infinity> pitti: Was there an LP bug for this, or did I make you file it upstream so we could avoid that?
<infinity> Oh, wait, found it.
<pitti> infinity: for what?
<infinity> https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/1491145
<ubottu> Launchpad bug 1491145 in dpkg (Ubuntu) "trigger tests for updated reverse test dependencies" [Medium,In progress]
<pitti> ah, yes, that
<pitti> the Debian bug is linked
 * infinity nods.
<infinity> pitti: Test-building, will upload during the next session.
<LocutusOfBorg> broken dpkg makes me saaaaaad
<LocutusOfBorg> :(
<LocutusOfBorg> infinity, please fix? :)
<LocutusOfBorg> hi btw
<LocutusOfBorg> https://anonscm.debian.org/cgit/dpkg/dpkg.git/commit/?id=383260e568cef224269ab19d4250f2a87177b778
<LocutusOfBorg> this patch is the fix
<LocutusOfBorg> getting failures such as https://launchpad.net/ubuntu/+source/mrpt/1:1.4.0-1build2/+build/10315241
 * LocutusOfBorg is sorry if it already is reported
<pitti> LocutusOfBorg, infinity: uploaded, since this is OMGkittens urgency
<pitti> I hope dpkg itself will build now :)
<LocutusOfBorg> I guess everywhere except for armhf
<LocutusOfBorg> some bootstrap might be needed
<LocutusOfBorg> damn I uploaded a fixed mrpt, that is making opencv migrate
<LocutusOfBorg> :(
<LocutusOfBorg> and it is ftbfs on armhf for this bug
<LocutusOfBorg> lets hope to finish the transition by some hours
<LocutusOfBorg> and thanks for the quick upload
<pitti> https://launchpadlibrarian.net/270800128/buildlog_ubuntu-yakkety-i386.dpkg_1.18.8ubuntu2_BUILDING.txt.gz
<pitti> crap
<pitti> "pull yourself out of a swamp"  situation
<LocutusOfBorg> sad
<pitti> ok, hang on; I'll try to remove the previous  dpkg
<LocutusOfBorg> oh... you not on -release
<LocutusOfBorg> I asked that some minutes ago
<pitti> dear remove-package,  I don't want to remove ubuntu2, but ubuntu1
<LocutusOfBorg> [12:33:55] <LocutusOfBorg> pretty please kick dpkg out of -proposed? :)
<LocutusOfBorg> [12:34:13] <LocutusOfBorg> rationale: debian bug 829542
<ubottu> Debian bug 829542 in dpkg-dev "dpkg-dev: dpkg-buildpackage misses import of Dpkg::Control::Info" [Grave,Fixed] http://bugs.debian.org/829542
<pitti> ok, done (I think)
<pitti> https://launchpad.net/ubuntu/+source/dpkg/+publishinghistory
<pitti> infinity: so I guess let's just re-merge 1.18.9?
<LocutusOfBorg> <3
<LocutusOfBorg> yes, I guess so
<infinity> pitti: D'oh.  I hope a test was committed with the fix.
<pitti> not in the same commit
<infinity> Not at all, actually.  Oh well.
 * infinity merges.
<pitti> cheers
<LocutusOfBorg> thanks you both
<pitti> yay for having a little bit of fun in devel :)
 * LocutusOfBorg goes back in his cave
<LocutusOfBorg> broken dpkg is always fun
<infinity> That'll teach me to go to lunch after an upload.
<pitti> LocutusOfBorg: btw, I suppose you need to wait ~ 30 mins for retrying your FTBFS, still needs a publisher run
<LocutusOfBorg> pitti, I guess so
<pitti> infinity: *shrug*, don't we all?
<LocutusOfBorg> but meh, I already retried :)
<pitti> Friday evening is ZE BEST time to upload systemd *whistle*
<Odd_Bloke> Doing `apt-get install python3.4` on xenial doesn't return a non-zero error code (despite the fact that it hasn't found such a package, and nothing has been installed): http://paste.ubuntu.com/18443198/
<Odd_Bloke> I'm not sure what I should file a bug for that against.
<LocutusOfBorg> pitti, possibly untested ;)
<pitti> Note, selecting 'libpython3.4-minimal' for regex 'python3.4'
<pitti> Odd_Bloke: apt itself, I suppose
<Odd_Bloke> (This is going to break people doing a t->x upgrade where they explicitly install python3.4; their automation isn't going to fall over because apt didn't report an error, and then they'll be unexpectedly running 3.5)
<pitti> apt's greedy "try to interpret everything as regexp" has gone on my nerves more than once already
<pitti> it's really not helping
<infinity> libpython3.4-minimal also isn't in xenial.
<pitti> yeah, I suppose it appears in some Breaks: or so
<Odd_Bloke> Yeah, it's in findutils' Breaks.
<pitti> I really wish apt-get install, apt-cache showsrc etc. would just stick to "do what I said", not "try to second-guess me by interpreting my package name as a RE and then desperately try anything that matches"
<smb> FourDollars, slangasek, Just to make sure, are you aware that the upload to grub2 in Trusty will also need a follow-up upload of grub2-signed? (proposed enabled threatens me with the removal of signed grub again)
<FourDollars> smb: yes, I am aware that.
<FourDollars> smb: Any concern?
<smb> FourDollars, ok. So there is hope that there soon will be one, I guess. My concern right now is more that I cannot dist-upgrade without loosing signed. :)
<FourDollars> smb: I see.
<infinity> pitti: That's weird.  dpkg-buildpackage worked on amd64...
 * infinity waits for the publisher to finish before retrying the rest.
<pitti> infinity: yeah, my previous ubuntu2 also worked on amd64, not sure why
<infinity> pitti: I'm tyring not to think about it.  I'm sure there's a reasonable explanation that will give me an aneurysm on the way to understanding it.
<pitti> +1 :)
<infinity> My not having .za power is going to get really old, really soon.
<FourDollars> pitti: Could you also help to update grub2-signed for https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1591818?
<ubottu> Launchpad bug 1591818 in OEM Priority Project "Add support for running a 64-bit Linux kernel on a 32-bit EFI." [High,New]
<pitti> FourDollars: err, tell me how?
<infinity> pitti: pull-lp-source grub2-signed, add changelog entry, change build-deps in debian/control
<pitti> ah, just a no-change upload?
<infinity> Well, no-change, except for debian/control. :P
<infinity> A not-much-change upload.
<pitti> right
<pitti> wow, current version is against 1.8, we have 1.11 in -proposed; what happened to .9 and .10
<pitti> and the build against 1.8 b-deps on >= 1.7
<infinity> 1.8 is in updates.
<infinity> Looks like proposed keeps getting overwritten.
<pitti> FourDollars, infinity: http://paste.ubuntu.com/18444168/ ?
<FourDollars> pitti: I am not sure if you can upload grub2-signed or not.
<infinity> Or something.
<infinity> pitti: Bad version number.
<infinity> pitti: Should be 1.34.10
<pitti> I can, its binaries will just land in unapproved for another archive admin inspection, AFAIK (at least linux-signed does)
<infinity> pitti: Otherwise fine.
<pitti> ack, thanks
<FourDollars> pitti: thx, it looks OK.
<infinity> Err, WTF?
<pitti> Rejected:
<pitti> File grub2-signed_1.34.10.tar.xz already exists in Primary Archive for Ubuntu, but uploaded version has different contents. See more information about this error in
<pitti> meh
<infinity> pitti: Hold on.
 * pitti checks publishing history and bumps
<infinity> pitti: Why did you accept that grub2 upload?
<infinity> pitti: It reverted what was in proposed.
<pitti> infinity: that's what I thought too
<pitti> infinity: and I rejected it
<smb> infinity, pitti The versions are missing for a previous attempt to update that got broken by some current softlink not correct and then taken back
<pitti> infinity: slangasek then told me that it was deliberately reverted, and that this was ok, so I re-accepted it
<infinity> Oh.
<infinity> Oookay.
<FourDollars> Oops
<pitti> ok, 1.34.13 it is
<infinity> I hope someone told cyphermox he got trumped.
<smb> infinity, I think he know (was some kind of "oh we don't need the grub2 changes after all" thing
<infinity> smb: Kay.
<pitti> it's diffy now in https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
<pitti> but I don't want to self-accept
<infinity> pitti: I already got it.
<pitti> cheers
<Bluefoxicy> lol... ternary DNS
<cyphermox> infinity: pitti: grub2> all is good
<infinity> cyphermox: Check.
<Odd_Bloke> pitti: infinity: Apparently not considered a bug in apt: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1598810
<ubottu> Launchpad bug 1598810 in apt (Ubuntu) "`apt-get install python3.4` on xenial exits 0 despite python3.4 not being available" [Undecided,Opinion]
<Odd_Bloke> In the classic vein of "I wrote and/or use this every day so I can't see that it's in some ways deficient" with a nice helping of condescension towards the bug reporter.
<LocutusOfBorg> pitti, please retry talloc and pptpd? :)
<LocutusOfBorg> I should have retried everything that was failing on universe/multiverse
<LocutusOfBorg> they are both in main and failed for dpkg
<pitti> LocutusOfBorg: done
<LocutusOfBorg> <3
<LocutusOfBorg> I'll look at them, thanks
<LocutusOfBorg> I don't know how to check which packages needs retry, but I think we should be good now
<LocutusOfBorg> I looked at excuses for missing builds
<LocutusOfBorg> but only to stuff uploaded/syncd today, older builds might have failed
<pitti> LocutusOfBorg: https://launchpad.net/ubuntu/yakkety/+builds?build_text=&build_state=failed&arch_tag=all isn't a too bad place to start
<pitti> actually, https://launchpad.net/ubuntu/yakkety/+builds?build_text=&build_state=failed&arch_tag=i386 is easier (it should have failed on i386)
<pitti> LocutusOfBorg: there are only a handful which failed today, I'll retry them all
<LocutusOfBorg> indeed thanks
<LocutusOfBorg> but I guess I already retried them
<LocutusOfBorg> I'm trying to understand something that was "given back" on a particular architecture only
<pitti> nope, that was it, no further victims
<LocutusOfBorg> wonderful
 * LocutusOfBorg leaves
<xnox> slangasek, should initramfs have valid /etc/passwd & /etc/group ? such that e.g.
<doko> jamespage, rbasak: python2.7 2.7.10 is now in -proposed. would be nice if you could give it a quick check (openstack)
<xnox> people can set non-default user names & groups in mdadm and expect it to work
<infinity> xnox: That's certainly never been a design goal.
<infinity> xnox: But if mdadm relies on that, it should figure out how to make it work.
<xnox> infinity, yes, that's what i'm trying to make work
<xnox> the default is "if no config found use: 0 (root), and 6 (disk)"
<xnox> the initramfs hooks write out CREATE user=root, group=disk -> which then fails to resolve lol
<infinity> xnox: Can the IDs be resolved at hook time, and used numerically at boot time?
<rbasak> doko: my team doesn't touch openstack any more. I'll leave to jamespage - not sure if he's in today or not.
<xnox> infinity, code does not support that in mdadm at the moment.
 * xnox ponders stuff
<rbasak> Or maybe beisner can help, but I expect he's on vacation today (US holiday)
<xnox> infinity, yeah i need your help =)
<infinity> xnox: What are you doing in the next session slot?
<xnox> infinity, no idea.
<infinity> xnox: Well, if you want to find somewhere to get hacky, we can.
<xnox> not doing much now either, would love to have your opinion.
<xnox> infinity, where are you?
<infinity> xnox: Listening to Vangrant talk about his reproducible build network.
<xnox> ack
<zyga> pitti: hey, what kind of extra reassurance do you need for snapd to migrate in xenial?
<pitti> zyga: 1597329 hasn't been verified, it's only been 4 days, and yakkety is still broken
<zyga> pitti: ok, I'm looking at why yakkety may be broken
<zyga> pitti: once I unbreak or understand yakkety, what's the next step, just verification?
<pitti> zyga: yes
<pitti> zyga: y> appreciated; it's been broken since 2.0.2
<zyga> pitti: this fits into my "make snappy work everywhere" goal :)
<zyga> ubuntu too :)
<sil2100> !dmbping
<sil2100> !dmb-ping
<sil2100> hmmm
<sil2100> Ah, no ubottu?
<sil2100> No, he's here
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
 * zyga runs autopackagetests for snappy on yakkety, trying to understand the issue
<rbasak> Laney, infinity: I added juliank to ~ubuntu-core-dev, which indirectly makes him a member of ~ubuntu-dev. So I don't need to explicitly add him to ~ubuntu-dev, right?
<rbasak> (also he was already an Ubuntu member anyway)
<infinity> rbasak: Yeah, the implicit membership should be fine.
<rbasak> OK, thanks.
<juliank> xnox: I'm a core-dev now, we should celebrate!
<xnox> yeah =)
<xnox> juliank, well done
<infinity> pitti: After fallout in several other packages was sorted, you have a dpkg.  Cheers.
#ubuntu-devel 2016-07-05
<cpaelzer> good morning
<pitti> infinity: ugh, there was more? thanks!
<pitti> good morning
<juliank> pitti: I am in the process of building a process for future APT SRUs via a PPA (release -dput> PPA -copy-package-> archive), and was wondering what it takes to get autopkgtests running on the PPA (if that is possible). I'm not sure how useful that would be, but it certainly would not hurt...
<RAOF> Urgh. It's really annoying to review SRUs from PPAs :(
<pitti> that ^
<pitti> juliank: we can run autopkgtests on PPAs and do it all the time
<pitti> juliank: for the CI train in particular
<pitti> juliank: the problem isn't running the tests, but presenting them -- you would need to set up a britney instance for the PPA to get something similar to https://requests.ci-train.ubuntu.com/static/britney/ticket-979/landing-065-xenial/excuses.html
<pitti> juliank: by default the machinery just gives you the raw results like in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-pitti-ppa?format=plain
<pitti> and have to trigger the tests manually
<juliank> RAOF: The PPA basically acts as the APT 1.2 upstream repository once APT 1.3 hits unstable. Currently we basically sync from unstable to xenial, that then changes to 1.2 PPA->xenial
<RAOF> juliank: It's perfectly sensible to do that, it's just that our tooling for reviewing sync-from SRUs is bad.
<juliank> (Yes, we did not really sync so far due to some minor technical issues, but that's the plan)
<pitti> juliank: but, I think we can make this easier -- i. e. I could envision a small CLI program which downloads all the results for a PPA and gives you a package | pass/fail | URL table
<RAOF> And when I say âbadâ, what I really mean is ânonexistentâ.
<pitti> RAOF: well, not *that* bad -- sru-review --no-diff
<pitti> RAOF: and having to click two or three times to the PPA to get the diff from there
<juliank> RAOF: Well, there will be nice detailed SRU bug reports...
<RAOF> pitti: True, assuming LP has managed to generate a diff against the right version...
<pitti> juliank: the trickier part is to create a CLI program which *triggers* the tests for all rdepends of your PPA -- this really should use britney
<pitti> RAOF: heh, true that
<pitti> I often see that with silos, they often have the wrong one
<juliank> pitti: True.
<juliank> The next APT SRU will be far too large again, as it's 3 versions in 1. (1.2.13, 1.2.14, 1.2.15), because of regressions in yakkety sort of preventing me from pushing the earlier ones.
<juliank> Although I suppose I could SRU 1.2.14 first and then do the 1.2.15 afterwards
<juliank> 1.2.15 is like 3 bug fixes; one of which is a buffer overflow, one is a null pointer dereferencing, and the other I have not looked at yet....
<mitya57> slangasek, hi, looks like your python-imagesize universe -> main override didn't actually workâ¦
<mitya57> According to https://launchpad.net/ubuntu/+source/python-imagesize/0.7.1-1/+publishinghistory it got moved to universe again
<mitya57> Can you please check that?
<pitti> juliank: when we moved the CI train to autopkgtests, I actually made it reasonably easy to set up your own britney, and there's documentation about it now
<pitti> juliank: so if you want to be the guinea pig, we could do a first manual run on your PPA, then improve the tools along :)
<juliank> pitti: Well, the 1.2 PPA is empty right now, as I don't have 1.3 in unstable yet. But we can play with https://launchpad.net/~deity/+archive/ubuntu/sid in the meantime.
<juliank> Which is our daily built PPA
<juliank> I think I'm going to drop the actual 1.2 PPA and make it a "stable" PPA, then I can upload different versions for different release series sensibly.
<juliank> On the other hand, maybe someone on an older release wants to try a newer apt.
<juliank> Difficult choices...
<infinity> juliank: I'd rather 1.2.15, than two rapid fire SRUs.
<juliank> infinity: aye, aye
<cjwatson> Odd_Bloke: Still apparently no recent images in https://cloud-images.ubuntu.com/xenial/ - do you know what's up there?
<Odd_Bloke> cjwatson: I've been looking at it this morning, I think we've just had a string of poor luck with builders dying for no apparent reason; there's a build appearing now: http://cloud-images.ubuntu.com/xenial/20160705/
<cjwatson> Ah, brilliant.
<cjwatson> Odd_Bloke: Hm.  No arm64-uefi1.img?
<Odd_Bloke> cjwatson: Something shonky must have happened with the sync; it's there on the source.
<Odd_Bloke> (And also the amd64-disk1.img should not be 84M :p)
<Odd_Bloke> Oh, that's fixed now, so perhaps it'll show up in a minute or two.
<pitti> well, it would be *nice* if it was 84MB :)
<Odd_Bloke> cjwatson: It's now there. :)
<caribou> xnox: I'm working on fixing LP: #1570775 which implies adding the crashkernel= mechanics into kdump-tools
<ubottu> Launchpad bug 1570775 in makedumpfile (Ubuntu Xenial) "makekdump should re-exec with cio_ignore on s390x" [Undecided,New] https://launchpad.net/bugs/1570775
<caribou> xnox: want me to remove the equivalent code from s390-tools ?
<caribou> xnox: i.e. the bits that add/modify crashkernel= in /etc/zipl.conf
<hjd> Hi, could someone please retry apache-directory-server and proguard on Yakkety? They are marked as build failures, but I was able to build both successfully. Might have been resolved as time has passed. Thanks i advance :)
<pitti> hjd: done
<cjwatson> Odd_Bloke: Current arm64 uefi1.img LGTM from the point of view of having initrd.img as a symlink etc.; do you have a way of conveniently test-booting a few arches?
<Odd_Bloke> cjwatson: We do in yakkety, I'm looking at porting that back to xenial now.
<techsayan> Hi, I am facing issues while apt-get update, how to get rid of these error? But somehow apt-get upgrade runs successfully. I am using ubuntu 15.04. Here is the log file -> http://pastebin.com/vxvCC64V
<techsayan> I have tried this solution but no use -> http://askubuntu.com/questions/135932/apt-get-update-failure-to-fetch-cant-connect-to-any-sources
<xnox> caribou, sure
<jtaylor> techsayan: 15.04 is not supported anymore you should upgrade
<dobey> techsayan: 15.04 is end of life
<rbasak> techsayan: http://askubuntu.com/a/91821/7808, https://help.ubuntu.com/community/EOLUpgrades
<techsayan> jtaylor: dobey: rbasak: So there is no way out for this?
<jtaylor> yes, upgrade
<cjwatson> techsayan: rbasak just gave you two links that explain a way out
<rbasak> There's no point "updating" but staying on 15.04, since there are no more updates available.
<dobey> techsayan: really you need to upgrade to 16.04, as even 15.10 will be end of life in a couple weeks
<semiosis> Odd_Bloke: i tested the new xenial vagrant box from cloud-images today, but it doesnt include my changes.  how's that going?
<pitti> cjwatson: just in case you happen to look at germanium, there's a loooong-running ddeb-retriever which re-downloads stuff since mid-April (to clean up after a few ddebs which had a HTML error contents)
<cjwatson> pitti: Ah, thanks, glad you sorted that out
<pitti> cjwatson: yesterday I collected the bits from the last month, and today for some longer history, just in case
<Odd_Bloke> semiosis: It'll need to be SRU'd back in to xenial, so it needs to land in yakkety first.
<Odd_Bloke> semiosis: But we have an unrelated yakkety build failure at the moment, so we're working on fixing that first.
<semiosis> Odd_Bloke: ok.  thanks for the update
<Odd_Bloke> cjwatson: We're seeing http://paste.ubuntu.com/18546366/ as the console log for the arm64 image.
<Odd_Bloke> cjwatson: (Worth noting we've never booted one of these in ScalingStack before, so we might be doing something stupid unrelated to image issues :)
<cjwatson> Odd_Bloke: I was going to say, may be worth trying the previous one as a control
<Unit193> Okaaaay, new lsb-releases (9.20160110ubuntu0.1) dropped python2 support, as an SRU to xenial.  That doesn't seem cool, moreso since it broke backportpackage.
<rbasak> Unit193: bug 1596638.
<ubottu> bug 1596638 in lsb (Ubuntu Xenial) "python2 cannot import lsb_release on yakkety and now xenial" [Critical,Triaged] https://launchpad.net/bugs/1596638
<rbasak> I think slangasek said he'd try to take a look today, but if you can do it, please feel free.
<Unit193> ...I have no idea how I missed that bug, but alright.  I'm not a core dev.
<mdeslaur> infinity: meeting?
<doko> mdeslaur, he's here at DebConf, probably already at the bar =)
<mdeslaur> ah :)
<mdeslaur> doko: thanks
<slangasek> mitya57: the python-imagesize override worked fine, and then someone reverted it
<slangasek> unfortunately there's no audit log of who does the component changes
<mitya57> slangasek, ok, thanks for re-promoting. As soon as I get the list of failed autopkgtests for sphinx, I'll look at them.
<cjwatson> Odd_Bloke: Incidentally I'm partly also interested in ensuring that my change hasn't somehow broken other architectures, so non-arm64 tests would be good too.  I've asked IS to try the LP builder case with the new cloud images.
<infinity> Odd_Bloke: Your arm64 console log is somehow magically powerpc?
<slangasek> nacc: php-monolog has turned up on my radar as a TIL merge, the only remaining change is nocheck/stage1 build profiles; can you forward that to Debian please?
<slangasek> nacc: (and dropping the delta in the meantime)
<nacc> slangasek: ack, will do!
<nacc> slangasek: sent
<slangasek> cjwatson, infinity: either of you recall the status of build-arch standardization in Debian?  seems we have a package that builds ok in Debian but FTBFS in Launchpad (https://launchpad.net/ubuntu/+source/ganglia/3.6.0-6.1ubuntu1/+build/10423092, Debian bug #821985)
<ubottu> Debian bug 821985 in ganglia "ganglia: Build arch:all+arch:any but is missing build-{arch,indep} targets" [Normal,Open] http://bugs.debian.org/821985
<slangasek> looks like "now mandatory" and perhaps the dpkg hacks have been phased out
<cjwatson> slangasek: I bet this is a change in dpkg 1.18.8; the successful Debian build was with 1.18.7
<cjwatson> slangasek: the changelog entry is confusingly written, but as I read the change (git commit ad94a98cf614e1c4129f8611080232d69d210a0a) it affects builds of any source package that has both Architecture: all and non-all binaries in debian/control
<nacc> cyphermox: is sg3-utils stuck in -proposed because we also need to merge up partman-multipath and multipath-tools?
<nacc> slangasek: weird issue i'm hitting with the php7.0 SRU. I just added -proposed in a container to see if I can reproduce LP: #1598489. But I get this rather confusing policy output: http://paste.ubuntu.com/18587507/ and apt wants to remove fpm (and I wonder if that's what broke that setup)
<ubottu> Launchpad bug 1598489 in php7.0 (Ubuntu) "package php7.0-common 7.0.8-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 10" [Undecided,New] https://launchpad.net/bugs/1598489
<nacc> bah, nevermind! configuration issue on my end!
<slangasek> nacc: do you have -proposed enabled in your sources for main but not universe?
<nacc> slangasek: yeah that was the problem :)
#ubuntu-devel 2016-07-06
<cpaelzer> good morning
<pitti> Good morning
<pitti> cyphermox: hey!
<pitti> cyphermox: can you please follow up on bug 1536008  and bug 1473903? these belong to trusty's parted update, but the tasks of the latter are completely off and psusi said that it's wrong, and the former is v-failed; as it stands, I'd just remove this SRU
<ubottu> bug 1536008 in parted (Ubuntu Trusty) "ISST-LTE: parted command shows "device-mapper: table ioctl on failed: No such device or address" error" [High,Fix committed] https://launchpad.net/bugs/1536008
<ubottu> bug 1473903 in multipath-tools (Ubuntu Trusty) "parted will generate two devices when adding one partition on mpath device" [High,Triaged] https://launchpad.net/bugs/1473903
<flexiondotorg> pitti, If you have a moment I need some advice regarding my SRUs.
<pitti> flexiondotorg: Guten Morgen; what's up?
<flexiondotorg> Morning.
<flexiondotorg> https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-settings/+bug/1574789
<ubottu> Launchpad bug 1574789 in ubuntu-mate-settings (Ubuntu Xenial) "SRU: xorg.conf.d/90-zap.conf destroys xorg keyboard settings" [High,In progress]
<flexiondotorg> That issue has been fixed in Yakkety.
<pitti> > +rm_conffile /usr/share/X11/xorg.conf.d/90-zap.conf 16.04.5
<flexiondotorg> But clearly I've not done something correctly to indicate that.
<pitti> was this removed in yakkety?
<flexiondotorg> Yes.
<pitti> as that's what caused the regression and reopened the bug
<pitti> ok, then  please say so and close the floating task
<pitti> so this just needs a follow-up upload to xenial then with the updated patch?
<flexiondotorg> So this is a term I need to understand the meaning of.
<flexiondotorg> What is a "task"?
<pitti> every line with a triangle in the table on the top
<flexiondotorg> And I did upload again, a couple of days ago, to Xenial.
<pitti> this bug has three tasks: "ubuntu-mate" upstream, u-m-s for "ubuntu" (called "floating" task as it usually applies to the current devel series, not to a particular series), and one task for "ubuntu xenial"
<pitti> this currently says that it's in progress in both the devel series and xenial
<flexiondotorg> Thanks for the explanation. I've marked the devel series task as Fix Released.
<flexiondotorg> pitti, So can you "see" the ubuntu-mate-settings 16.04.5.3 for Xenial?
<pitti> flexiondotorg: it's in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1 , I suppose you mean that?
<pitti> flexiondotorg: btw, please don't close/reopen tasks without a comment
<flexiondotorg> OK, I'll add an appropriate comment.
<pitti> flexiondotorg: thanks; I accepted the xenial update
<flexiondotorg> pitti, Thanks for the help.
<flexiondotorg> I have a similar issue with the SRU
<flexiondotorg> https://bugs.launchpad.net/ubuntu-mate/+bug/1581168
<ubottu> Launchpad bug 1581168 in ubuntu-mate-artwork (Ubuntu) "SRU: GTK3 scrollbars in Radiant-MATE not styled like GTK2" [Undecided,New]
<flexiondotorg> That is also fixed in Yakkety already.
<pitti> flexiondotorg: I added a xenial task; please close it for y then
<flexiondotorg> pitti, Thanks. I wasn;t able to add the Xenial task. Is that intended?
<pitti> flexiondotorg: you should be able to as a developer; bdmurray manages these
<pitti> flexiondotorg: on https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1581168, do you see a "Nominate for series"?
<ubottu> Launchpad bug 1581168 in ubuntu-mate-artwork (Ubuntu Xenial) "SRU: GTK3 scrollbars in Radiant-MATE not styled like GTK2" [Undecided,New]
<pitti> that's the one
<flexiondotorg> There was no option to target Xenial.
<pitti> you can click it, you should then get some check boxes for trusty etc. (not for xenial any more as I just did that)
<flexiondotorg> I've added a comment and marked as Fex Released for the dev task.
<pitti> thanks
<flexiondotorg> pitti, When I try to select a target the only tick box I see is Trunk
<flexiondotorg> And, thank you for helping out pitti. Very much appreciated.
<pitti> flexiondotorg: oh, then you have the upstream task selected, not the ubuntu task
<pitti> that's a bit icky indeed, there's no way to select it with clicking
<pitti> flexiondotorg: try on https://bugs.launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+bug/1581168,
<ubottu> Launchpad bug 1581168 in ubuntu-mate-artwork (Ubuntu Xenial) "SRU: GTK3 scrollbars in Radiant-MATE not styled like GTK2" [Undecided,New]
<flexiondotorg> Ahhh, penny drop :-)
<flexiondotorg> Right, understood.
<pitti> i. e. you have to get to the page via the "ubuntu" bug list, not the upstream bug list
<flexiondotorg> pitti, So can you see ubuntu-mate-artwork (16.04.6.2)?
<flexiondotorg> Is there anything more I need to do to progress that SRU?
<pitti> flexiondotorg: no, not in https://launchpad.net/ubuntu/xenial/+queue?queue_state=1
<flexiondotorg> Hmm, well I did upload it weeks ago.
<pitti> flexiondotorg: did you get a REJECT email?
<pitti> https://launchpad.net/ubuntu/xenial/+queue?queue_state=4&queue_text=mate
<pitti> not there eitehr
<flexiondotorg> I don't recall a rejection. I'll double check. I have the .upload file here:
<flexiondotorg> Successfully uploaded ubuntu-mate-artwork_16.04.6.2.dsc to upload.ubuntu.com for ubuntu.
<flexiondotorg> Successfully uploaded ubuntu-mate-artwork_16.04.6.2.tar.xz to upload.ubuntu.com for ubuntu.
<flexiondotorg> Successfully uploaded ubuntu-mate-artwork_16.04.6.2_source.changes to upload.ubuntu.com for ubuntu.
<flexiondotorg> OK, it was rejected on June 29th.
<flexiondotorg> pitti, So should I re-upload 16.04.6.2 or bump the version to 16.04.6.3 and upload?
<flexiondotorg> I'm assuming a rejection means 16.04.6.2 is not referenced in the archive anywhere and the same version can be re-uploaded?
<pitti> flexiondotorg: reupload .2 please
<flexiondotorg> OK
<pitti> flexiondotorg: https://launchpad.net/ubuntu/+source/ubuntu-mate-artwork/+publishinghistory
<pitti> flexiondotorg: it was never accepted indeed
<pitti> flexiondotorg: well, maybe call it 16.04.7 to have a slightly saner version number :)
<flexiondotorg> pitti, I've been getting conflicting feedback on the versions :-)
<flexiondotorg> I've re-uploaded 16.04.6.2
<flexiondotorg> But I much prefer a saner version.
<flexiondotorg> If another SRU is required I use .7
<pitti> flexiondotorg: so reupload it as 16.04.7 and I'll reject the .6.2?
<flexiondotorg> pitti, Wilco
<flexiondotorg> pitti, Done.
<cjwatson> Odd_Bloke: Did you notice infinity's comment to the effect that your arm64 image boot log looked more like a powerpc image?
<Odd_Bloke> cjwatson: I did, yeah; AIUI, we should register images with metadata {"architecture": "aarch64"} and OpenStack should work out that when we attempt to launch that image, we want arm64.
<Odd_Bloke> cjwatson: Which we are doing, so either my understanding is incorrect, or something strange is happening in bos01.
<cjwatson> Odd_Bloke: I wouldn't rule out the latter, although historically there's been some confusion between "arm64" and "aarch64" names too I think
<cjwatson> vbuilder-g-s-s-production-arm64 appears to set {'architecture': 'aarch64', 'hypervisor_type': 'kvm'}
<Odd_Bloke> OK, I'll try adding hypervisor_type.
<cjwatson> Oh, and I said "a powerpc image" above but I guess I actually mean a powerpc guest.
<cjwatson> Or ppc64el.
<cjwatson> Odd_Bloke: Could be a red herring as it sets that for all arches.
<infinity> Indeed, hard to say what the image was, but it was clearly a ppc64 guest.
<infinity> (powerpc or ppc64el is meaningless before the kernel boots)
<cjwatson> Odd_Bloke: https://jenkins.canonical.com/xenial-cloud-images/job/16.04-Perform-Pre-Publish-Testing/ARCH=arm64,TEST=basic-ubuntu/1/artifact/debug.log/*view*/ does seem to show a whole lot more metadata for other arches.
<cjwatson> Well, amd64 anyway.
<cjwatson> Ah, wait, those are buildd images I'm looking at.
 * cjwatson shoves through jq in the hope of being able to read it
<cjwatson> Odd_Bloke: Launching on floette though, which is definitely ppc64el.
<Odd_Bloke> cjwatson: The latest one _looks_ like it was put on swirlix03, with that hypervisor_type change.
<Odd_Bloke> And, yes, https://jenkins.canonical.com/xenial-cloud-images/job/16.04-Perform-Pre-Publish-Testing/ARCH=arm64,TEST=basic-ubuntu/4/artifact/debug/cloud-info/console-log/*view*/ looks more like it.
<Odd_Bloke> But I've just realised that we're attempting to launch the disk1 image here, not the uefi1 image.
<Odd_Bloke> So I'll go and address that next.
<cjwatson> Definitely an improvement.
<Odd_Bloke> It's booted and our tests have SSH'd in and everything. \o/
<infinity> \o/
<cjwatson> Oh, nice one.  That dnsdomainname test failure isn't particularly scary for this purpose I guess?
<cjwatson> Odd_Bloke: And sounds to me like I can reasonably tag the live-build bug v-done?
<Odd_Bloke> cjwatson: Yep, that's not a scary failure; looks like it's v-done to me. :)
<cjwatson> Done.
<Odd_Bloke> cjwatson: We're seeing https://bugs.launchpad.net/cloud-images/+bug/1598136 which would probably be fixed by building on a buildd with a post-trusty kernel; how close are we to having powerpc and armhf building on post-trusty buildds?  (I'm guessing that we'd already have it for armhf if we were require_virtualized=True?)
<ubottu> Launchpad bug 1598136 in cloud-images "Fails to produce a loop-mountable FS on powerpc/armhf" [Critical,In progress]
<cjwatson> Odd_Bloke: armhf is already on wily for virt, indeed.  The blocker for devirt was the xenial bug we just sorted out, followed by getting IS to switch scalingstack over to that, a bit of testing, and flipping the switch.  Probably not too far now.
<cjwatson> Odd_Bloke: powerpc is somewhat more work; it needs bos02 scalingstack to be deployed first.
<cjwatson> Odd_Bloke: infinity possibly could upgrade powerpc to xenial in advance of that.  I don't know what he thinks of that.
<infinity> deneed* and fisher* are running ltx-xenial kernels.
<infinity> lts-xenial, even.
<cjwatson> Also, amd64/i386 are on trusty at the moment, not xenial.
<cjwatson> Not even lts-xenial, I think.
<Odd_Bloke> infinity: So it's just sagari that isn't?
<infinity> Odd_Bloke: Indeed, sagari is stuck in the past.
<infinity> Distant past, at that.
<infinity> precise, I think.
<cjwatson> So yeah, notwithstanding what the error message says I think it's actually the precise kernel case that's the problem.
<cjwatson> kishi* are on precise, 3.2.
<Odd_Bloke> Yeah, I wouldn't be surprised if the trusty kernel was new enough to solve it.
<Odd_Bloke> (Especially given that it works on amd64/i386 :p)
<cjwatson> I'll comment on the bug.
<infinity> kishi could be upgraded to lts-trusty, I suspect.  I could steal one from the console and test, or ask a WeBop to proxy and play with me.
<infinity> And sagari should also be able to do the same now.
<infinity> The reason it was kept on precise is no longer valid.
<cjwatson> I'd really rather not mess with kishi.
<infinity> cjwatson: Well, I was just suggesting kernel upgrades, not full userspace.  But meh.
<cjwatson> But as for sagari, go nuts.
<infinity> I'd have done sagari months ago, if I had access to it.
<Odd_Bloke> cjwatson: infinity: This is currently blocking any new yakkety dailies; do you expect we'll be unblocked in the next couple of days, or should we get a workaround in place that we can remove once we are unblocked?
<cjwatson> Odd_Bloke: A workaround seems sensible.
<mwhudson> i have a package in xenial-proposed that's failed verification
<mwhudson> uh i guess i want to upload a new one that has a higher version number anyway, so never mind
<semiosis> Odd_Bloke: working on your feedback.  if the test goes well i should push the changes in a few minutes.
<semiosis> Odd_Bloke: do you know why the config management packages were removed?  where can I read up on that decision?
<Odd_Bloke> semiosis: Pretty much all of the changes were because Vagrant moved from being built as a special snowflake to just the base cloud image wrapped up in a Vagrant box.
<Odd_Bloke> semiosis: So "decision" is generous. ;)
<semiosis> Odd_Bloke: well it's unfortunate for the users that care was not taken to preserve the expected functionality of a vagrant base box, like synced folders and config management packages working out of the box.  i want to get the config management stuff added back without delay.
<Odd_Bloke> semiosis: I'm not convinced that we should be shipping all of the config management stuff, but I am convinced that we should get synced folders and hostnames working.
<Odd_Bloke> semiosis: Which is why I want to split those two conversations up.
<Odd_Bloke> semiosis: (I'm not saying I _couldn't_ be convinced, but I don't want to block behaviour that _is_ fundamental to Vagrant functioning for everyone because we're discussing behaviour that isn't fundamental)
<semiosis> Odd_Bloke: i dont mean to be argumentative, but it seems like you should have to justify removing stuff that has been in ubuntu's vagrant boxes for years.
<Odd_Bloke> semiosis: I don't disagree that we should have had to, and it wasn't a decision that I was involved in.
<Odd_Bloke> semiosis: But we have now released the Vagrant boxes the way they are.
<semiosis> Odd_Bloke: if people could've even booted the xenial boxes they would've reported that config management was missing, but the xenial boxes were so broken people couldn't even get that far
<Odd_Bloke> semiosis: And so we need to be aware that there are now users (including some in bug reports), who are using them as they currently are, and are happy with them.
<Odd_Bloke> semiosis: And so, again, I'm not saying that we won't or can't add in the config management tools.
<Odd_Bloke> semiosis: But I am saying that we are _definitely_ going to fix shared folders and hostname resolution problems.
<semiosis> Odd_Bloke: what do you want to do about config management packages then?
<Odd_Bloke> semiosis: I'd suggest pulling those lines out of your existing MP, filing a bug about them being missing and (once your current MP is merged) filing an MP with just these changes.
<semiosis> Odd_Bloke: this is highly frustrating, but you give me no choice
<semiosis> Odd_Bloke: i'll open that bug and see where it goes
<rbasak> Do we want to go down the route of the Vagrant box's behaviour being different from Ubuntu everywhere else?
<Odd_Bloke> rbasak: The Vagrant box pre-xenial already has all the config management bits included.
<semiosis> rbasak: that's how it's been for a long time.  were people complaining that the vagrant boxes had config management?  no, because that's expected of a vagrant base box.
<rbasak> What does "had config management" mean, OOI? A bunch of packages installed by default? Or something more?
<Odd_Bloke> rbasak: Yeah, puppet, chef etc. installed.
<semiosis> thats it
<rbasak> semiosis: I'd say that developers also probably expect similar behaviour between Vagrant boxes and production.
<rbasak> I mean - that's the whole point, isn't it?
<semiosis> rbasak: developers expect vagrant boxes to have config management
<Odd_Bloke> semiosis: There's no documentation to suggest that it's expected of a Vagrant base box; https://www.vagrantup.com/docs/boxes/base.html says "only a bare minimum set of software for Vagrant to function", and "Perhaps Chef, Puppet, etc. but not strictly required."
<rbasak> semiosis: refusal to look at the bigger picture isn't going to help here.
<semiosis> rbasak: whats the bigger picture look like to you?
<rbasak> I think there's a classic conflict here. "Vagrant" users expect the same "Vagrant" experience across all distros. "Ubuntu" users expect the same "Ubuntu" experience across all "Ubuntu".
<rbasak> I think both points of view have merit here. The difficulty is that it's generally not possible to meet both set of requirements.
<Odd_Bloke> semiosis: If I understand correctly (which is by no means guaranteed :), all we would really be requiring people to do is add a shell provider line with "apt-get install (vagrant|chef|...)" to their Vagrantfile; is that accurate?
<semiosis> the pre-xenial vagrant boxes had (for many years) met both sets of reqs
<rbasak> And a new release is the right point to make a breaking change, if indeed that is the right thing to do.
<rbasak> I bet the developers who use Vagrant and expect puppet to be installed there would also find it convenient for images on (eg. EC2) to also have puppet installed by default.
<rbasak> But if we extended that to everything, then we'd have another set of users complain about how bloated the images are.
<Odd_Bloke> (As a side note, we've already had one user comment on the size of my test Vagrant box with these packages added back in)
<semiosis> Odd_Bloke: i'll try the shell provider as you suggest and let you know
<semiosis> Odd_Bloke: are you aware of any complaints over the last few years about ubuntu's "bloated" vagrant boxes?
<Odd_Bloke> semiosis: If it does work, I expect not including them may actually lead to less downloading, because you'd only be pulling in the one config management tool you use.
<rbasak> Looking solely at complaints from existing Vagrant users is sampling bias. How many users are using different tooling because the current images didn't suit their needs? We don't hear from those.
<Odd_Bloke> Well, we also only introduced a single point to report Vagrant images earlier this year.
<Odd_Bloke> *Vagrant image bugs
<Odd_Bloke> So we don't really have a historical sense of it regardless.
<Odd_Bloke> But we do regularly get complaints about the size of all of our images. :p
<semiosis> i'm sure!
<rbasak> We always get complaints both ways. Users want less bloated images. Other users want their obvious thing in them by default :)
<semiosis> thanks for going through this with me Odd_Bloke & rbasak.
<semiosis> i'll open the bug and we'll see where it goes.
<cyphermox> nacc: sg3-utils> it's because sg3-utils should not have been synced, it should have been a merge.
<rbasak> semiosis: np. Sorry there's no easy answer. I hope you understanding my reasoning as to why.
<semiosis> Odd_Bloke: is there a link to open a vagrant bug?
<semiosis> rbasak: yes i do understand.  you're right about a new release being the place for a breaking change.  we'll see what people say in the bug comments.
<rbasak> semiosis: thanks. https://bugs.launchpad.net/cloud-images/+filebug might be a good starting place unless Odd_Bloke has somewhere else in mind. We can always move it later.
<cyphermox> nacc: fixed it.
<caribou> infinity: do you remember a discussion you had with tinoco & mdeslaur about ABI issues with libnss_winbind (samba) & requirement to statically link those two modules ?
<caribou> infinity: LP: #1584485
<ubottu> Launchpad bug 1584485 in samba (Ubuntu) "Upgrading samba to latest security fixes together with winbind in nsswitch.conf can harm entire OS" [High,In progress] https://launchpad.net/bugs/1584485
<caribou> I'm trying to figure out a decent way of linking them statically in the package
<semiosis> Odd_Bloke: i pushed the changes you requested to my branch.  test was successful.
<semiosis> Odd_Bloke: rbasak: config management bug as we discussed is here: https://bugs.launchpad.net/cloud-images/+bug/1599531
<ubottu> Launchpad bug 1599531 in cloud-images "Xenial vagrant box is missing puppet/chef/etc config management" [Undecided,New]
<rbasak> semiosis: thank you for filing that
<semiosis> rbasak: it's my pleasure!
<semiosis> i hope people comment there.  i'm really interested to see what people have to say.  Odd_Bloke's shell provisioner idea works great, so that is a suitable workaround (now documented in the bug) for people who need config management on the vagrant box.
<rbasak> Unfortunately bug discussion tends to suffer from sampling bias too, IMHO.
<rbasak> People affected are over-represented compared to everyone else.
<semiosis> thanks again for all your help with this stuff.  hope i wasn't too argumentative :)
<semiosis> time to head into the office.  bbl
<rbasak> semiosis: no problem. Thank you for caring :)
<nacc> cyphermox: thanks!
<sil2100> cjwatson, infinity: hey guys! Do we always have so many disabled amd64 builders? We just landed new langpack packages in the overlay and they're waiting for free amd64 builders since an hour
<michael-vb> Afternoon.  Not sure if this is the right place to ask, but someone will probably know what is.
<michael-vb> I have the following problem with my VirtualBox Ubuntu 16.04 guest with development Guest Additions installed: when I start the guest I get the message "The system is running in low-graphics mode" (on VT 2) even though the X server is running fine (on VT 7).
<michael-vb> I would very much like to know exactly what logic triggers that message so I can work out why I am triggering it and change whatever is responsible (I am the developer of the VirtualBox guest driver and Additions installer).
<michael-vb> (By the way, I am away from the keyboard for a bit, but experience says that answers usually take a while on IRC, so probably no problem.)
<michael-vb> Interesting - I just booted the guest system twice with a loaded host (rebuilding VirtualBox) and did not get the "low-graphics mode" message.
<cjwatson> sil2100: lcy01 often needs a good kicking
<cjwatson> sil2100: I've poked it
<michael-vb> CRITICAL: session_get_login1_session_id: assertion 'session != NULL' failed in the lightdm log file.
<michael-vb> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814760
<ubottu> Debian bug 814760 in lightdm "randomly fails to start" [Normal,Open]
<sil2100> cjwatson: thanks!
<kees> Totally up to us, except that I need to be there all day 25 and 26 (I imagine flights back would happen on the 27th, though ugh, the return flight leaves at 6:26)
<kees> pm
<kees> (the only direct)
<kees> yes! that was not meant for here
<nacc> slangasek: would you have any advice on how to handle LP: #1598489? again, it's marking php7.0 SRU as leading to a regression, but it's not clear to me how that's possible (in this case). And not enough info in teh bug. Is it appropriate for me to chagne the tags and just work the bug, or should I leave it in the current tags until I have a definitive answer?
<ubottu> Launchpad bug 1598489 in php7.0 (Ubuntu) "package php7.0-common 7.0.8-0ubuntu0.16.04.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 10" [Undecided,Incomplete] https://launchpad.net/bugs/1598489
<slangasek> nacc: exit status 10 is an exit value associated with debconf.  Does your SRU introduce any changes to maintainer scripts / debconf prompts?
<slangasek> nacc: if not, we should triage this as not-a-regression
<michael-vb> Ping, anyone around: the "low graphics mode" issue in a VirtualBox guest.
<michael-vb> See above.
<michael-vb> As I said, this may well be the wrong place to ask, but in that case I would love to know the right place (or person).
<nacc> slangasek: no, there should not be any maintainer script changes; i'll re-verify that, thanks
<fo0bar> infinity: btw, following up from a conversation earlier this year, I was able to successfully convert a G4 mini to use grub-ieee1275 instead of yaboot
<fo0bar> infinity: grub-install has no concept of non-prep setups, so I mostly adapted ideas from http://cynic.cc/blog/posts/running_grub2_on_powerpc_macs/
<fo0bar> the bootstrap partition was way too small for a full grub + modules, so I had to pare down the modules.  and "splash" messes up VT handoff (or lack thereof) and results in no video whatsoever
<fo0bar> but grub + pared modules + stub grub.cfg which searches for the root UUID partition and hands off to its grub.cfg, plus /etc/default/grub removing splash works
<michael-vb> Oh well, getting late.  Will try again tomorrow.  If anyone can answer, feel free to ping me by e-mail, at michael dot thayer at oracle and I will be very grateful.
<michael-vb> Good night.
<coreycb> arges, can you reject my python-oslo.concurrency upload for wily?  I need to upload a new version with an i386 patch for the cloud archive.
<arges> coreycb: ok
<arges> coreycb: done
<coreycb> arges, thanks
<jderose> tyhicks: did you have a chance to look at my revised ecryptfs-utils patch yet? if so, any thoughts on it?
<tyhicks> jderose: hey - I've been on holiday the last two days and actually just started looking at it a few minutes ago
<tyhicks> jderose: I'll leave comments in the merge request
<jderose> tyhicks: awesome, thanks! hope you had a great holiday :)
<tyhicks> thanks :)
<mwhudson> is there a reason a new source package in debian might not be synced to ubuntu by default
<mwhudson> ?
<mwhudson> https://launchpad.net/debian/+source/snap-confine <- this one, specifically
<Laney> mwhudson: Does http://people.canonical.com/~ubuntu-archive/auto-sync/current.log have anything to say?
<mwhudson> that version is only a few hours old but the older one didn't sync either
<mwhudson> Laney: ah, let's find out!
<Laney> (yes)
<mwhudson> yes
<Laney> :)
<slangasek> mwhudson, Laney: oh then I'll just accept it so it's no longer in NEW
<slangasek> (done)
<mwhudson> slangasek: aah
<mwhudson> slangasek: the package in NEW was the native one
<slangasek> mwhudson: yes.  1.0.34-1 > 1.0.34, so it'll still sync over it
<mwhudson> oh ok
<mwhudson> true
#ubuntu-devel 2016-07-07
<mwhudson> @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: mwhudson
<mwhudson> nacc: around still?
<pkern> .win 5
<cpaelzer> mwhudson: thanks for pinging again on even more clarification on bug 1546565 after pitti asked a few days ago
<ubottu> bug 1546565 in openvswitch (Ubuntu Xenial) "Ownership/Permissions of vhost_user sockets for openvswitch-dpdk make them unusable by libvirt/qemu/kvm" [High,Triaged] https://launchpad.net/bugs/1546565
<cpaelzer> mwhudson: TL;DR is please unsubscribe sponsors and SRU Verification
<cpaelzer> mwhudson: I putt a decent summary in the bug so that the next that might come by only need to read the last comment and knows about the overall state
<mwhudson> cpaelzer: ah ok :)
<mwhudson> sponsors unsubscribed, i'm not in ~sru-verification so can't unsubscribe them
<cpaelzer> mwhudson: thanks, this is one of the cases that became super urgent around release and then everybody kind of forgot about the open debdiff for the config example
<cpaelzer> mwhudson: pitti: thanks for continuously pushing to get this into a proper state
<cpaelzer> I think we are good now code- and bug-wise
<mwhudson> heh
<mwhudson> noone cares about poor yakkety, just xenial :-)
<mwhudson> (well, i exaggerate, but only a bit)
<mwhudson> RAOF: hey, i have an sru type question
<mwhudson> RAOF: there is an sru for docker in xenial, which has failed autopkgtests on i386
<mwhudson> RAOF: it's just a flaky test, now fixed in yakkety
<mwhudson> RAOF: should i upload the fix to xenial as well?
<mwhudson> well, upload the yakkety version + ~16.04
<mwhudson> eh that sounds silly when i say it out loud
<RAOF> mwhudson: If the yakkety version is just xenial-proposed + a fix for the flaky test, yes please.
<pitti> Good morning
<dholbach> hey pitti
<pitti> cpaelzer: thanks!
<pitti> hey dholbach, wie gehts?
<dholbach> sehr gut - wie geht's dir? :)
<pitti> dholbach: auch gut, danke; viele lange Fussball-Naechte, aber ist ja bald vorbei :)
<dholbach> am Wochenende waren wir auf einer Hochzeit in SÃ¼dtirol - da hatte das Fest dann doch etwas Konkurrenzveranstaltung, einige konnten dann doch nicht feiern, ohne immer wieder auf's Telefon zu schauen :-)
<pitti> haha
<cpaelzer> dholbach: gleiches Erlebnis auf einem 50sten Geburtstag - aber die hatten gleich einen Projektor aufgestellt
<dholbach> bei 'ner Hochzeit hÃ¤tte ich das jetzt schon etwas komisch gefunden :-)
<sladen> aber das war nicht Deutschland zu spielen zum Abend?
<sladen> (oder waren die Paren aus Portugal/Wales?)
<cpaelzer> bei mir war es Sonntag mit FRA/ISL - FuÃballverrÃ¼ckte brauchen wohl einfach alle Spiele :-)
<cpaelzer> aber Ich vermute Wochenendhochzeiten sind meist Samstags - also GER/ITA
<pitti> aka "lose 5 years of your lifetime and all your fingernails" :)
<cpaelzer> I'd so much would have liked to see what happens after all eleven players had shot their penality - I had fingernails left to stand it
<pitti> the captains balance the ball on their head, and who can do that longer wins?
<cpaelzer> do something for charity, they are all rich - the players spend personal money (secretly noted down), then they cound and the Team that spent most wins
<cpaelzer> that way the Teamthat really want to win wins
<michael-vb> Good morning.  I asked a question yesterday, but got no response.  See paste below:
<michael-vb> (17:09:06) michael-vb: Afternoon.  Not sure if this is the right place to ask, but someone will probably know what is.
<michael-vb> (17:09:06) michael-vb: I have the following problem with my VirtualBox Ubuntu 16.04 guest with development Guest Additions installed: when I start the guest I get the message "The system is running in low-graphics mode" (on VT 2) even though the X server is running fine (on VT 7).
<michael-vb> (17:09:06) michael-vb: I would very much like to know exactly what logic triggers that message so I can work out why I am triggering it and change whatever is responsible (I am the developer of the VirtualBox guest driver and Additions installer).
<michael-vb> (18:04:34) michael-vb: Interesting - I just booted the guest system twice with a loaded host (rebuilding VirtualBox) and did not get the "low-graphics mode" message.
<michael-vb> (18:27:01) michael-vb: CRITICAL: session_get_login1_session_id: assertion 'session != NULL' failed in the lightdm log file.
<michael-vb> (18:31:13) michael-vb: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814760
<ubottu> Debian bug 814760 in lightdm "randomly fails to start" [Normal,Open]
<sladen> michael-vb: https://irclogs.ubuntu.com/2016/07/06/%23ubuntu-devel.html#t15:09
<sladen> michael-vb: http://askubuntu.com/questions/141606/how-to-fix-the-system-is-running-in-low-graphics-mode-error
<michael-vb> Found that already.
<michael-vb> I am wanting to understand this as a developer, not as a user.
<michael-vb> sladen: it was following from that askubuntu question that I found the system log entry.
<michael-vb> The session clearly gets started just after lightdm checks whether it is running.
<michael-vb> As I said, this does not happen under high load.  I suppose the question is, who would understand this stuff well enough to tell me how I can avoid triggering it.
<michael-vb> Or what causes the session to start too late, or lightdm too early.
<michael-vb> I assume that some dependency is not specified well enough somewhere.
<sladen> michael-vb: apt-get source lightdm && grep -r "Error message"   is probably the most effective way of identifing the logic causing the error (if it is coming from lightdm)
<michael-vb> But it is annoying, because if it hits users they will blame us first, not you!
<sladen> michael-vb: I'm not too familiar with the inner workings of lightdm; the developer was Robert Ancell in the DX team
<sladen> michael-vb: if it's happening so of the time (seemingly randomly), then there's probably a race condition
<michael-vb> I'm sort of suspecting that it is related to the change to systemd which upset some expectation in lightdm.
<sladen> willcooke: if you're around later, could you get in contact with michael-vb (upstream developer of VirtualBox guest driver), about debugging and resolving the "The system is running in low-graphics mode" message.  https://irclogs.ubuntu.com/2016/07/07/%23ubuntu-devel.html#t07:52 onwards
<michael-vb> willcooke: and michael dot thayer at oracle if I am not on IRC at that time.
<michael-vb> sladen, willcooke: thanks.
<willcooke> Trevinho, is this something you can help with? ^
<willcooke> It looks like it's a problem with X rather than Unity though
<willcooke> "problem"
<willcooke> maybe tjaalton knows what triggers it? ^
<tjaalton> I don't, if lightdm is randomly not starting on debian (which doesn't have "failsafe-x")
<tjaalton> sounds like a lightdm bug to me
<willcooke> oki
<willcooke> thanks tjaalton
<willcooke> michael-vb, Hmm, I can't see anything obvious here.  Please log a bug in Ubuntu against lightdm if there isn't already one, and we take take a look.
<michael-vb> willcooke: to me it sounds like an init dependency problem.
<sladen> michael-vb: can we get as much of the (known good) information into a Launchpad bug report
<michael-vb> If I understood all this GNOME-systemd-login stuff better...
<michael-vb> sladen: sounds reasonable.
<sladen> michael-vb: and then get that linked to/from the debbugs and Askubuntu pages
<michael-vb> Oh how nice, for reasons unknown I can no longer trigger it.
<willcooke> \o/
<willcooke> fixed!
<willcooke> certainly smells like a race then
<michael-vb> I think that is clear enough from the Debian bug.
<michael-vb> I think that someone from the systemd camp would be best placed to solve it.
<michael-vb> But before I open a bug report I will at least try to track down the error in the lightdm sources.
<sladen> yes, it would be good to point in the bug report exactly where the origin of the assert is coming from, but if it can't be found, please file the bug report (and link to this IRC log and anytthing/everything that you've already found, so that we've got a trackable braindump in one place)
<michael-vb> The assertion is easy to find, I am trying to logically work out the callers.
<michael-vb> Ah, (about to show my lack of understanding of these things) is Ubuntu still using console-kit instead of systemd-logind?
<michael-vb> I see "console-kit-daemon" in that Debian bug logging.
<pitti> hell no
<pitti> michael-vb: we switched to logind in saucy, I believe
<pitti> oh, LXDE is still using it
<michael-vb> Ah right, logging from systemd-logind there too.
<pitti> (at least apparently)
<michael-vb> This is an absolute plain Ubuntu installation.
<pitti> then it shouldn't even be installed
<michael-vb> No "L", "K" or anything else.
<michael-vb> Got the error again.  Booting from power off did not produce it, clean rebooting did.
<michael-vb> Will open a bug.
<michael-vb> It would be good if I could find some way to at least avoid triggering the race, otherwise both we and you will have lots of annoyed users.
<mwhudson> RAOF: yeah
<cpaelzer> pitti: any hint where I do it wrong that my local adt is unhappy (http://paste.ubuntu.com/18689738/) while e.g. last build of the same looks good https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/amd64/c/clamav/20160706_174652@/log.gz
<cpaelzer> I get the issue even if I just pull-lp-source and adt-run it, or is that just another case of me having not the bleddiest-edge autppkgtest :-)
<pitti> cpaelzer: hm, curious -- this is certainly not related to the autopkgtest version
 * pitti runs autopkgtest clamav -- qemu /srv/vm/autopkgtest-xenial-amd64-cloud.img locally
<pitti> cpaelzer: hm, works fine
<pitti> cpaelzer: is that really the same clamav version in both cases? maybe your locally built package has some fancy/broken permissions on ./unit_tests/acc?
<raphink> E: Failed to fetch http://fr.archive.ubuntu.com/ubuntu/pool/universe/n/npm/npm_3.5.2-0ubuntu4_all.deb  503  OUT OF DISK SPACE
<raphink> looks like (one of) the French mirror  is out of space!
<raphink> or the proxyâ¦
<raphink> more likely ;-)
<cjwatson> yeah, that's a proxy somewhere
<cjwatson> apache is not going to care that it's out of disk space when serving static files
<cpaelzer> pitti: thanks for corss checking - I'll do a retest once more after it seems to work for you
<cpaelzer> pitti: the following line fails for me, which I guess excludes local modification from the list of potential issues
<cpaelzer> cd  /; rm -rf /tmp/test-adt-clamav; mkdir -p /tmp/test-adt-clamav; cd /tmp/test-adt-clamav; pull-lp-source clamav; adt-run --shell-fail --apt-upgrade --source clamav_0.99+dfsg-1ubuntu2.dsc --- adt-virt-qemu --cpus 4 --ram-size=2048 ~/work/adt-yakkety-amd64-cloud.img
<cpaelzer> throwing into a lxd env now to see if it is any different
<pitti> cpaelzer: oh, I tested xenial; as soon as my system load drops < 8 again, I'll re-test the y version
<cpaelzer> pitti: sure - but for me it fails X&Y
<cpaelzer> running with adt-virt-lxd adt/ubuntu/yakkety/amd64 triggers the same for me
<cpaelzer> hmm, pitti is this permission denied happening at the host or guest level i.e. would running with sudo make any difference?
<pitti> cpaelzer: no, that's something guest-level
<cpaelzer> pitti: even more interesting, when running with -ddd on adr-run and -d on adt-virt-lxd it works
<sladen> michael-vb: did you manage to work up a bug report?  Do you have the bug number in Launchpad so that it can be triaged?
<cpaelzer> pitti: I got it working by adding the debug flags, and now I can remove them and it still works with the lxd case
<cpaelzer> pitti: I'm running the kvm one just to be sure, but consider this strange issue resolved for now
<cpaelzer> pitti: thanks for your help
<cpaelzer> pitti: it keeps showing up in the kvm based adt - if your system load is low it would be nice to hear what happens for you if you just throw the same command I listed above at your system
<pitti> cpaelzer: running
<pitti> cpaelzer: my fingers protest about typing "adt-run", though :)
<pitti> cpaelzer: also, calling adt to build the package is annoying and unnecessary..
<pitti> but oh well, it's almost done now, doesn't take too long
<cpaelzer> pitti: I wanted to stick close to what failed initially for me - of course to test what is in the archive could be done way more efficient :-)
<pitti> cpaelzer: yep, get the same
<cpaelzer> oh really
<cpaelzer> pitti: bug report then?
<cpaelzer> I got around it by switching to LXD and you neither want nor have to solve it like "now" - so I'd create a bug for you - ok?
<pitti> yes (not sure whether against clamav or autopkgtest, but start with the latter -- reassinging is esay)
<pitti> thanks
<cpaelzer> ok
<pitti> curious that -d helps, that sounds like an odd race
<pitti> also, with -B it works fine, so the built package is somehow broken/strange
<cpaelzer> pitti: well it only did in the lxd case, I'll put it in the bug
<zyga> pitti: hey, how can I run autopkgtests from a source tree on 16.04 in a yakkety VM?
<zyga> mwhudson: still around?
<zyga> mwhudson: I broke my adt setup (it will be back in ~15 minutes) but have a look at this if you are around https://github.com/snapcore/snapd/pull/1504
<mdeslaur> doko: do we still need to keep blapi.h and alghmac.h in our libnss3-dev, or does openjdk-8 not use them anymore? (re: debian bug 754978)
<ubottu> Debian bug 754978 in nss "please install the blapi.h and alghmac.h header files" [Normal,Open] http://bugs.debian.org/754978
<mdeslaur> tjaalton: can you confirm we no longer need the shared cert and key databases in nss?
<doko> mdeslaur, please ask tdaitx, probably won't have time for that during DebConf (and current SRUs ...)
<mdeslaur> tdaitx: any idea? ^
<tdaitx> mdeslaur, don't know about that, let me take a look
<tdaitx> mdeslaur, openkjdk8 has no reference/includes to those files (in case it matters: openjdk 7 has a single reference to blapi.h)
<mdeslaur> tdaitx: ok, thanks, I'll stop adding them then
<tjaalton> mdeslaur: confirmed, freeipa-client uses a private one now
<mdeslaur> tjaalton: great, thanks
 * mdeslaur takes chainsaw to yakkety nss
<cjwatson> does anyone know whether user namespaces are supposed to work properly when using precise lxd guests on a xenial host?
<michael-vb> sladen: sorry, was away... #1599775
<michael-vb> https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1599775
<ubottu> Launchpad bug 1599775 in lightdm (Ubuntu) ""low-graphics mode" in VirtualBox guest, but X server running" [Undecided,New]
<michael-vb> Right, was wondering how to trigger your bot.
<michael-vb> sladen: thanks.
<pitti> cjwatson: do you still remember the context of https://git.launchpad.net/~ubuntu-release/+git/britney2-ubuntu/commit/?id=a3b7baf3e ?
<pitti> cjwatson: AFAICS this just matters when we have some self.options.fucked_arches, right? as otherwise the existing checks would already hold it back due to having missing builds
<pitti> cjwatson: btw, I just converted the bzr branch to git and I'm now in rebase/patch review hell :)
<pitti> as a precursor for merging to current britney, for getting support for versioned provides, etc.
<cjwatson> pitti: I remember it being excruciatingly delicate, but I don't think it was to do with fucked_arches, it was something subtle about the set of built binaries changing between sources I think
<cjwatson> I'm afraid I don't remember exactly
<pitti> cjwatson: ok; nevermind
<gQuigs> is the xenial archive fully locked for package removals?   just found out about "snappy" music player - our version is badly broken and it's been removed from Debian - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808518
<ubottu> Debian bug 808518 in src:snappy-player "Please port to clutter-gst-3.0" [Serious,Fixed]
<gQuigs> https://errors.ubuntu.com/?package=snappy&period=month
<cjwatson> IRC logs from around that time might be informative, if you're lucky
<gQuigs> it's also been removed from Yakkety already
<cjwatson> not possible to remove from xenial I'm afraid
<pitti> cjwatson: oh, turns out Debian actually has a  similar fix in http://anonscm.debian.org/cgit/debian-release/britney2.git/commit/?id=371ad0
<cjwatson> pitti: I think that just changes the excuse text
<gQuigs> cjwatson: k, just wanted to check, thanks!
<cjwatson> it won't change whether something is a valid candidate
<cjwatson> good luck working it out :)
<pitti> cjwatson: right, but I I meant that our patch could/should now use uptodatebins
<pitti> cjwatson: heh, thanks :)
<pitti> it's only 290 patches or so to review, how long can it take..
<pkern> .wub 8
<michael-vb> willcooke: not sure what "trello" is, is it normal that I should not be able to access the link you added to the bug?
<willcooke> michael-vb, yeah it's a task tracking system we are using
<willcooke> michael-vb, dont worry about it - all important updates will go in to the bug
<michael-vb> So short answer, yes it is expected.
<slangasek> mdeslaur: we missed a TB meeting this week, right?  I guess you didn't manage to un-break the calendar for it?
<mdeslaur> slangasek: yeah, we missed it, nobody showed up. infinity was supposed to fix the calendar.
<slangasek> ok
<slangasek> calendar event recreated
<slangasek> but need to get it on the fridge etc
<slangasek> there, fridge added
<mdeslaur> slangasek: thanks
<nacc> tjaalton: would you be able to explain to me how/when the xserver-xorg-video-intel driver version was chosen for 16.04? Reading the version string, it seems to be a git snapshot from a particular date? In the context of LP: #1078068
<ubottu> Launchpad bug 1078068 in xserver-xorg-video-intel (Ubuntu) "Video blinking blue during incoming call" [Undecided,Fix released] https://launchpad.net/bugs/1078068
<tjaalton> nacc: yes it is
<tjaalton> nacc: you need to bisect for that fix
<nacc> tjaalton: ack, i'll do that once i know what fixes it :)
<tjaalton> we're moving away from this driver in 16.10
<nacc> tjaalton: as it worked for me, but one user already said it didnt' for them
<tjaalton> to modesetting
<nacc> tjaalton: ah ok
<nacc> tjaalton: i'm afraid it's goign to be a large pile of changes (not just one) ... but will try and bisect later today
<tjaalton> because there hasn't been a stable release in three years
<nacc> tjaalton: i wondered :)
<nacc> tjaalton: is there a good guide of installing from git for this driver?
<tjaalton> clone debian packaging git
<tjaalton> add upstream remote
<juliank> pitti: http://autopkgtest.ubuntu.com/packages/a/apt/ lists a lost+found distribution...
<tjaalton> hack away
<juliank> I think we should have a Depends from apt on dpkg to have dpkg uploads trigger apt autopkgtest runs. Opinions?
<juliank> (I don't think it currently does, I have a feeling 1.18.9 breaks the tests, but not sure...
<nacc> tjaalton: thanks
<infinity> juliank: Artificial deps for the sake of tests are wrong.
<infinity> juliank: You can, however, make your *tests* depend on dpkg, and that'll end up in Test-Triggers.
<juliank> infinity: That works fine for me
<infinity> juliank: Which pitti hasn't yet implemented on the CI side, but it's on his TODO, I believe.
<infinity> juliank: Ironically, this feature depends on the version of dpkg that broke your tests. ;)
<slangasek> mitya57: how's the analysis going of the sphinx autopkgtest failures? I saw that breathe is a legitimate regression in -proposed; a re-test of the breathe package in yakkety passes, with sphinx 1.4.4-3 it fails
<mitya57> slangasek, I will fix breathe (texlive-generic-extra was added to Build-Depends, but it should be in tests depends too)
<zyga> h
<mitya57> slangasek, â¦ and we will be down to cryptography which has unrelated problems (something with python3-cffi-backend-api-{min,max})
<slangasek> mitya57: right, I've triggered a no-proposed retest of python-cryptography as well to get us a baseline
<mitya57> slangasek, breathe uploaded; thanks!
<nacc> tjaalton: sorry for being dense, first time trying to bisect a package; i have the remote upstream and the good/bad points. But as it bisects, it puts me (as expected) into the upstream tree, which has no debian/ directory. So would i bisect strictly in the upstream commits and just do a merge into the debian-unstable tree to build it?
<mwhudson> @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:
<tjaalton> nacc: or bisect manually creating a diff that you put in debian/patches
<tjaalton> diff between bad/good upstream, keep a record of the commits and bisect points
<tjaalton> hum, no need to diff between bad and known good upstrean, but something in between of course
<tjaalton> git diff a..b > d/p/bisect.diff; echo bisect.diff >>d/p/series; <build>
<tjaalton> easy
<tjaalton> maybe touch changelog so you know which is which
<infinity> pitti: libnss-resolve has a derpy idea of valid domain names.
<ogra_> caribou, congrats !
<infinity> pitti: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1600000
<ubottu> Launchpad bug 1600000 in systemd (Ubuntu) "libnss-resolve treats two trailing dots on a domain name incorrectly" [Undecided,New]
<infinity> Ooo, I got a round number!
<nacc> tjaalton: ah duh, thanks!
<ogra_> infinity, oooh, conrats too !
<nacc> general question, the version of cobbler shipped in 16.04 (and presumably for some time) doesn't work OOB. I believe it is worth SRU'ing the version from 16.10 to 16.04 (sync'd from Debian), which does work OOB (and builds fine in 16.04). I don't believe there will be a clean upgrade path for users, though. Can I add cobbler to the release notes post-release? Feels icky if so. Or should I just pursue a
<nacc> backport? Fixing the Cobbler version in 16.04 is not possible (the base version is so old that it's not worth doing, we're better of deleting it from the archive)
<jbicha> I think it's fine to improve the release notes after release
<rbasak> Yeah, Colin has said to me that it's fine too.
<jbicha> some serious bugs we don't know about it before release day!
<nacc> jbicha: rbasak: ok, cool, I'll propose the SRU then, given that
<nacc> jbicha: makes sense! :)
<rbasak> If the package in 16.04 is completely broken then an SRU carries no regression risk so is generally OK.
<rbasak> OTOH if it works, then I see what you're saying but it's up to the SRU team really.
<rbasak> (ie. if it can be made to work)
<nacc> rbasak: i just did a quick test and installed and started cobbler as packagined in 16.04. It throws a python exception immediately :)
<nacc> rbasak: the 16.10 version runs fine
<rbasak> nacc: then it sounds like an SRU should be fine :)
<nacc> rbasak: yeah, and i think it will close ... 10-15 bugs :)
<nacc> rbasak: verifying that now
<nacc> rbasak: what's the appropriate debdiff to provide in such a case? Or can I simply request we backport and version appropriately the 16.10 version? i have it in a ppa via requestbackport
<rbasak> nacc: yeah a debdiff probably doesn't make sense. Perhaps point to a PPA with instructions on what to do with the changelog (eg. drop a ~ppa suffix, etc). Or put a full source package up somewhere, eg. people.c.c.
<nacc> rbasak: ack, thanks; also, can i just close cobbler bugs not updated since 11.04/11.10? i'm 99% sure they simply don't apply anymore and no one cares
<rbasak> nacc: I would do that with an explanatory comment and an invitation for others to reopen if they think still relevant.
<nacc> rbasak: ack, thanks
#ubuntu-devel 2016-07-08
<nacc> rbasak: what is "Orchestra"?
<nacc> appears to be a precise-only thing? predecessor to maas?
<mwhudson> was that the old name for juju?
<nacc> mwhudson: hrm, could be :)
<mwhudson> er, no, i think that was ensemble
<mwhudson> ah no, i think orchestra became maas
<mwhudson> oh no, i don't know ;-)
 * mwhudson gets back to work
<rbasak> nacc, mwhudson: yeah, Ensemble got renamed to Juju, and Orchestra was superseded by MAAS, IIRC.
<nacc> rbasak: ack, makes sense, thanks
<rbasak> People used to confuse Ensemble and Orchestra quite a bit.
<pitti> Good morning
<pitti> juliank: heh, thanks for pointing out; noted
<pitti> infinity: right, I added a WI to add Test-Depends:; I'll do this after the britney Merge From Hell
<pitti> infinity: heh, three trailing dots don't work any more
<juliank> pitti: If I retry an autopkgtest, it retries in the original environment. How will I be able to get the apt autopkgtest rerun against dpkg 1.18.9ubuntu2 once that migrated?
<juliank> ubuntu1 breaks the APT test suite...
<pitti> juliank: if dpkg migrated, then the apt autopkgtest will run against htat
<pitti> it doesn't remember an "original env" and tries to reconstruct it with earlier package versions
<pitti> that would be fairly pointless, a lot of work, and totally not robust
<juliank> pitti: Oh, I misread the logs.
<juliank> OK, that's great then
<pitti> tinoco, infinity, xnox: aupkg01 (10.100.0.12) is still AWOL; can you please revive it? http://autopkgtest.ubuntu.com/running.shtml has a desperately long s390x queue.. :(
<juliank> pitti: apt/yakkety failed (?) with ERROR: Quota exceeded for cores: Requested 1, but already used 30 of 30 cores (HTTP 413) (Request-ID: req-83a86408-bde2-48fc-bb3c-3cd951790006)
<pitti> juliank: it didn't fail, it'll retry again in a bit
<juliank> OK
<pitti> juliank: the workers are hammered right now, so clouds run out of space
<juliank> I can believe that
<juliank> Damnit, the apt autopkgtests are failing
<pitti> they've been failing for a while
<pitti> (in y)
<juliank> pitti: Yeah, but those were weird.
<juliank> Maybe it's still a cause of the dpkg thing
<juliank> We'll see once dpkg has migrated...
<juliank> Not so sure about test-apt-tagfile-fields-order
<juliank> Yep, it's a "real" problem. We don't know the Testsuite-Triggers source field yet -> that fails the test
<juliank> I failed to notice that because I only upgraded dpkg, not libdpkg-perl
<juliank> But that only means we have no specified order that field when sorting
<juliank> The apport tests fail with the new apt which now raises E:The repository 'http://ddebs.ubuntu.com trusty Release' is not signed.
<juliank> :(
<pitti> I'll look into that
<juliank> Log https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety/yakkety/i386/a/apport/20160708_072803@/log.gz
 * juliank wonders why the python-apt tests fail
<xnox> doko, ha ha ha ha =)
<xnox> told you germany will play wales for the third place ;-)
<pitti> there actually is no game for the third place
<infinity> pitti: Any thoughts on my libnss-resolve bug?
<pitti> infinity: I don't know what the RFCs have to say about this, but I guess it's just a bug that needs fixing :) i. e. not much to think about it, just fwd it upstream and fix it
<pitti> as three dots don't work, there is no systematic "ignore trailing dots", so this just sounds like a too lax trailing dot check
<infinity> pitti: Any more trailing dots after the first are garbage.  One could take the "strict in what you produce, liberal in what you accept" argument, but differing from the resolver we've used for decades is a fair argument for it being a bug.
<pitti> agreed
<infinity> pitti: Anyhow, it was mostly a question of "should I just ignore the glibc failures for now, or can we fix it soon?"
<pitti> this doesn't look intended
<pitti> infinity: shouldn't take that long; but it doesn't appear so urgent to me that I should drop my brain state from the britney merge and move to that immediately?
<pitti> infinity: but  glibc built, didn't it? i. e. is that actually blocking you?
<infinity> pitti: Actually, wait.  Why is libnss-resolve in my autopkgtst chroot in the first place?
<infinity> pitti: glibc built, sure, cause libnss-resolve isn't in buildd chroots.  It's the autopkgtests that fail. :P
<pitti> it's certainly not in build chroots, yes; but we do install it by default now, because servers
<infinity> pitti: Sure, but autopkgtests are supposed to test against a minimal base, I thought?
<infinity> Or do we test against standard intentionally?
<pitti> infinity: more or less; it's a cloud image with the most obvious crap purged, but it's certainly far from minimal
<infinity> pitti: Hrm.  Kay.  Perhaps we can impove on that $later, but today, I'll just ignore that failure.
<pitti> but actually, testing stuff with the low-level plumbing things we install by default actually seems better
<pitti> infinity: yeah, no problem with hinting over that one, as we understand what it is
<infinity> pitti: I'm going to make the buildd chroots auto-built daily soon, would be trivial to turn those into bootable cloud images, so you'd have the same level of minimalness.
<pitti> also, queues are still uber-full anyway (particularly s390x)
<infinity> pitti: But yes, maybe minimal+standard is the better baseline, since that
<infinity> 's what we consider "Ubuntu".
<rbasak> pitti: why not start with debootstrap + tasks instead of cloud images - stuff?
<pitti> rbasak: the cloud images are all that I have in scalingstack
<pitti> I create my own images from those plus http://anonscm.debian.org/cgit/autopkgtest/autopkgtest.git/tree/setup-commands/setup-testbed which purges a lot away
<pitti> rbasak: minimal deboostrap-like images are being used with lxc/lxd, thouhg (on armhf/s390x)
<rbasak> pitti: could you access the (original) core tarballs for example?
<pitti> rbasak: no -- they aren't bootable at all
<pitti> you need a kernel, grub, cloud-init, etc.
<pitti> I don't want to get into the business of building cloud images from scratch
<pitti> also, that'd be too synthetic -- we want to test stuff in an env whose base/plumbing bits are what we actually ship
<rbasak> It just feels fragile to take the cloud images and then strip stuff away, that's all.
<pitti> well, having all this non-standard stuff installed breaks stuff (lvm2, command-not-found, lxc, etc.); but Priority: standard" should stay IMHO
<pitti> we don't have lean cloud images, we just have those chubby ones which are optimized for human usage, not for actual cloud "cattle" usage
<pitti> but I've given up on this :)
<rbasak> I believe the decision is to prefer to have a single image suitable for both uses.
<rbasak> So not too chubby, not too lean.
<pitti> yes, which I heavily disagree with, but as I said I've given up on this
<rbasak> Rather than confusing things by having two sets.
<rbasak> But unfortunately that makes them unsuitable for the autopkgtest case.
<pitti> we penalize millions of cloud instances/users for that, but *shrug*
<rbasak> Cloud users generally don't have to download an image. The cloud provider already hosts them.
<rbasak> And disk space is usually not the bottleneck.
<pitti> it's disk space (density), download and upgrade time
<pitti> plus excess runtime (having mdadm/lvm2 in the boot path, apt-xapian-index daily cron jobs, etc.)
<pitti> plus, as we also advertise them for lxd, it actually *is* download time too
<rbasak> If it's a choice of penalising that or penalising developers for not having stuff available, I'd prefer the former.
<rbasak> In the case of lxd, I *want* this stuff in the images.
<pitti> right, and that's what I disagree with -- most cloud images are not being used in an interactive way
<rbasak> True, but most engineering time on images is spent in an interactive way.
<pitti> and for the few ones that are, adding a "Human-Comfy: yes" thingy to cloud-init would be better than asking everyone to trim their cattle images themselves
<rbasak> And it is engineering time that is the most expensive.
<rbasak> That would slow down every image boot.
<rbasak> Finally, after my engineering, I want to deploy the same environment without changing it.
<pitti> the "classical human server" use case isn't that you re-create them often
<pitti> this was supposed to replace the ubuntu server image
<pitti> well, I made my point, let's agree to disagree
<rbasak> :)
<pitti> you won't convince me, and after discussing it several times I accept that I won't convince you
<Laney> I was thinking about something like this the other day
<rbasak> I used to work on a deployment that was "lean". I replaced it in the end.
<rbasak> It's too painful to deal with operational issues when nothing is available.
<Laney> Maybe super minimal is even an anti-goal
<Laney> in the real world people run with all sorts of crud installed, and things should still work
<pitti> rbasak: installing iscsi, lvm2, mdadm, and apt-xapian-index into every LXD container is not "lean" or even useful, it's just bloat
<pitti> no developer will ever need that
<Laney> or handle gracefully their lack of working
<rbasak> When I move my lxd container test stuff into prod, I don't want to deal with bugs that occur because stuff behaves differently.
<rbasak> Even though the incidence rate is low, the overall cost is still lower than the extra cost of having lvm2 and iscsi in lxd images.
<ppisati_> doko: wasn't there a way to switch toolchain (or in my case cross-toolchain)?
<rbasak> Maybe it makes a difference if I had 10,000 nodes. But in that case, I'm probably in a position to maintain a modded image well anyway.
<ppisati_> doko: the kernel i'm working on, doesn't compile with gcc-5 but it does with gcc-4.7
<ppisati_> doko: i installed the gcc-cross-...armhf-4.7
<doko> depends on the package you want to build ...
<ppisati_> doko: kernel
<doko> but CC=... CXX=... should work
<ppisati_> doko: nope, because you pass
<ppisati_> doko: export CROSS_COMPILE=arm-linux-gnueabihf-
<ppisati_> doko: and /usr/bin/arm-linux-gnueabihf-gcc -> arm-linux-gnueabihf-gcc-5
<doko> ppisati_, I don't build kernels, maybe apw can help?
<LocutusOfBorg> ppisati_, I usually end up in doing some symlinks
<LocutusOfBorg> I agree with you
<ppisati_> doko: it's not a building problem, it's 'how do i make toolchain X the default toolchain'
<ppisati_> yeah, but i've a vague memory
<LocutusOfBorg> the problem is that there isn't an "append" variable
<ppisati_> of script that you could run
<LocutusOfBorg> I mean, $CROSS_COMPILEgcc$CROSS_SUFFIX might be a nice idea
<ppisati_> and it would switch from toolchain-X to -Y
<ppisati_> LocutusOfBorg: right
<LocutusOfBorg> ppisati_, BTW there are trivial fixes for gcc 5 and kernel
<LocutusOfBorg> I ended up in adding them
<infinity> pitti: You can probably replace that hardcoded list of packages in the "bloat removal" with "apt-get purge server^"
<LocutusOfBorg> I'm pretty sure you are referring to the failures related to inline
<ppisati_> LocutusOfBorg: yep, but sometimes kernle's vendor X require only that toolchain Y, so i can't easily switch
<ppisati_> etcetc
<LocutusOfBorg> I suggest you a CROSS_SUFFIX feature request ;)
<LocutusOfBorg> I'll use it too ;)
<doko> ppisati_, I don't support making random toolchains the default. best thing then to create your own bin dir with new symlinks
<LocutusOfBorg> exactly what I did
<infinity> ppisati_: What's wrong with patching the Makefile for CC = gcc-4.7?
<LocutusOfBorg> infinity, no
<infinity> LocutusOfBorg: Because?
<LocutusOfBorg> cross compiling works differently
<LocutusOfBorg> they use something like
<pitti> infinity: nice, I'll try that
<infinity> LocutusOfBorg: I know how cross works.
<LocutusOfBorg> CC=$CROSS_COMPILE-gcc :)
<infinity> LocutusOfBorg: Fine, s/gcc/gcc-4.7/
<infinity> LocutusOfBorg: If it needs 4.7, it needs it natively and cross, so it should be reflected in the Makefile, not the environment.
<LocutusOfBorg> so, better is to s/gcc/GCC$CROSS_SUFFIX idea I told him :)
<LocutusOfBorg> this might be upstreamable
<infinity> No.  CROSS_SUFFIX is wrong.
<LocutusOfBorg> calling it GCC_VERSION?
<infinity> These kernels need 4.7 for native *and* cross.
<infinity> And none of this needs to be upstreamed in his case.
<LocutusOfBorg> I had the use case of a kernel that was segfaulting when built with 4.7, and not with gcc-4.3
<LocutusOfBorg> I would have used the feature
<LocutusOfBorg> sometimes you have to test different cross compilers, not just always the same
<LocutusOfBorg> but I agree with your solution :)
<infinity> But if you know you need 4.3, you change the Makefile.  Why is that hard to grasp?
<LocutusOfBorg> because 4.3 disappeared from the main repo :)
<LocutusOfBorg> so, sometimes people needs to move on
<LocutusOfBorg> and try newer toolchains :)
<infinity> Then the software becomes FTBFS.
<infinity> Until the Makefile changes.
<infinity> That's fine.
<LocutusOfBorg> yes, and I usually fix the FTBFS
<infinity> You don't claim "any gcc will work" when that's known to be untrue.
<LocutusOfBorg> but in the meanwhile, the software might not FTBFS but misbehave
<LocutusOfBorg> so, having a CROSS_COMPILE=arm-foo- GCC_VERSION=4.7 make
<LocutusOfBorg> is trivial and a nice way for testing different toolchains
<LocutusOfBorg> but ECHAN
<infinity> doko: Well, I fixed *a* bug in the cross-toolchain-base debian/rules, but it wasn't *the* bug.  Back to investigating, I guess.
<LocutusOfBorg> BTW the sed should be propagated in many places, e.g. gcc, ld, ar, as, nm in tools/* and so on
<ppisati_> i really didn't want to change symlinks, but it seems it's the only way
<infinity> ppisati_: Err, wat?  We have lots of kernels in the archive that build with non-default GCC.
<infinity> ppisati_: It's trivial, and doesn't require mangling symlinks.
<ppisati_> infinity: if i'm on a xenial box the default is gcc-5 but i want to use different one
<infinity> ppisati_: Yes, so change it in the Makefile.
<ppisati_> infinity: no, because i don't want to enforce a version
<infinity> ppisati_: But... You do.
<ppisati_> infinity: people should be able to pass it via the CROSS_COMPILE stuff
<ppisati_> infinity: no i don't
<infinity> ppisati_: If you don't want to enforce a version, why are you changing the version?
<infinity> ppisati_: That makes zero sense.
<mpt> bdmurray, hi, when I choose âShow Previous Reportsâ I see a list of error reports that definitely isnât mine. What info should I provide in reporting this bug?
<infinity> mpt: How is that a bug?
<ppisati_> infinity: ok so, i patch to use X, then there's another guy with another distro or whatver and it doesn't have X, but has Y that can compile it
<ppisati_> infinity: what does it do?
<ppisati_> infinity: does it patch the makefile locally himself?
<infinity> ppisati_: It fails until they alter the Makefile.  Sure.  *shrug*
<mpt> infinity, because the list header says âError reports sent from this systemâ and they arenât
<michael-vb> sladen: it never hurts to check an updated software version, but I admit I also looked at the changelog and had my doubts.
<ppisati_> ...
<infinity> mpt: Oh, I was thinking of a different UI elsewhere.  Nevermind.
<LocutusOfBorg> ppisati_, this is why I'm thinking about a GCC_VERSION suffix variable
<LocutusOfBorg> you can just export it, with the correct value
<LocutusOfBorg> I have collagues with older ubuntu, some others with debian
<infinity> ppisati_: You could also write a Makefile that looks for existence of 4.7, then not.  But why are you concerned about people compiling on RedHat?
<LocutusOfBorg> I face similar issues on a daily basis
<LocutusOfBorg> infinity, it doesn't really scale
<infinity> ppisati_: If you know it only works with 4.7, I'm a big confused about why you'd care if it tries to compile with other versions.
<LocutusOfBorg> nope, it doesn't build with gcc>=5
<LocutusOfBorg> this doesn't mean it only works with 4.7
<LocutusOfBorg> what I do in my company is to build yocto cross-toolhchains
<infinity> LocutusOfBorg: I'm assuming 4.7 because he's not using 4.9. :P
<LocutusOfBorg> and give them to my colleagues
<infinity> As for "scaling", neither do magic environment variables.
<infinity> And they lead to completely unreproducible build environments.
<LocutusOfBorg> actually they mostly do the trick
<LocutusOfBorg> +1 for the second sentence
<LocutusOfBorg> actually sometimes an use case is to test different environments :)
<infinity> Anyhow, linux-goldfish has "CC              = $(CROSS_COMPILE)gcc-4.7
<infinity> I'm curious why that's not doable for ppisati_'s other kernel.
<LocutusOfBorg> this fix is good for ubuntu, but e.g. won't be good anymore on the next ubuntu
<infinity> It's intentionally not good for the next Ubuntu.
<infinity> It's set to 4.7 because that's the compiler that works to build that kernel.
<infinity> If all GCCs worked, it wouldn't have the version appended.
<infinity> But I'm done talking in circles.
<apw> infinity, right we would expect him to do that linux-goldfish thing ... ppisati_ ^
<ogra_> eventually the phone guys need to lift the emulator to android 5 ...
<ogra_> which should hopefully come with a newer kernel
<ogra_> you shoudl poke them ;)
<infinity> ogra_: Not actually the concern here, but agreed, if you mean Android 6... Or 7. ;)
<ogra_> well, whatever the latest phones are on (iirc thats still 5)
<infinity> pitti: Why are the s390x queues doing so badly?  Did you lose a machine again?  Or never find anyone to rescue your dead one?
<pitti> infinity: yes, see my ping from yesterday and from this morning
<pitti> one machine is down
<ogra_> on a sidenote, the emulator hasnt worked for the last three OTAs or so
<infinity> ogra_: My Nexus 5 is on Android 6.0.1.  7.x comes out this fall.
<pitti> which is half of our capacity
<pitti> infinity: normally s390x is the fastest one :
<infinity> ogra_: Unless you meant the current Ubuntu phones.
<ogra_> infinity, yes, and victors team just works on porting hybris to 6 i think :)
<infinity> ogra_: In which case, that should be upgraded some day too. :P
<ogra_> infinity, indeed i do ... i'm talking about the emulator and your gcc issue :)
<infinity> xnox: Can you rescue pitti's lost s390x z/VM?
<xnox> infinity, let me see
<infinity> ogra_: Right, the GCC issue wasn't actually in goldfish, I was just using it as an example of precedent.  But totally agreed that we need to get with the program and move to a modern Android.
<ogra_> yep
<ogra_> which will move the gcc issue magically to a newer version (and bite again in a year or so :) )
<xnox> pitti, do you remeber the login name for the z/vm?
<xnox> AUTOPKG01?
<xnox> found it
<pitti> xnox: yes, aka 10.100.0.12
<xnox> AUPKG01
<infinity> Goldpackage.
<infinity> The new Bond villain.
<xnox> pitti, infinity: AUPKG01 is booting
<infinity> xnox: Ta.
<pitti> xnox: cheers
<xnox> pitti, do i need to revive AUPKG02 too?
<pitti> xnox: no, that's fine
<pitti> xnox: we installed crashdump on those back then
<infinity> xnox: Lunch?
 * infinity heads down from the lab.
<pitti> xnox: where would they be? (the crash dumps)
<pitti> there's just a /var/crash/kexec_cmd
<mpt> bdmurray, reported bug 1600178
<ubottu> Error: Launchpad bug 1600178 could not be found
<LocutusOfBorg> Adri2000, libfilezilla didn't have a soname bump
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=830474
<ubottu> Debian bug 830474 in filezilla "filezilla: Version 3.19 must depend on libfilezilla 0.5.3" [Normal,Open]
<LocutusOfBorg> damn, please bother upstream about that
<infinity> LocutusOfBorg: Added symbols aren't ABI breaks.
<infinity> LocutusOfBorg: Looks more like the shlibs need bumping (or a proper symbols file needs to be added).
<LocutusOfBorg> infinity, yes, indeed
<LocutusOfBorg> I didn't see any ABI breakage when sponsoring
<LocutusOfBorg> and indeed I missed to check new symbols on filezilla
<infinity> s/filezilla/libfilezilla/
<infinity> But yeah, that library could do with a symbols file.
<LocutusOfBorg> no, I mean, I didn't check if the new filezilla was using new symbols from libfilezilla
<infinity> Sure, but you shouldn't have to, if the lib is properly packaged. :)
<LocutusOfBorg> I leave the task to Adri2000 :)
<alexbligh1> On 14.04, /etc/default/bind9 has RESOLVCONF=yes|no to control whether bind9 modifies resolv.conf; as far as I can tell with systemd this doesn't work as systemd is used to start bind9 and doesn't run resolvconf. I'm new to systemd so am just looking in /lib/systemd/ (as well as observing the problem). Is this likely to be an issue with bind9 or is this my stupidity somewhere?
<alexbligh1> s/with systemd/with systemd on 16.04/
<sladen> alexbligh1: presumably an issue in the way that bind9 is wrapped/packaged.  Can you get a bug into launchpad/debbugs with as many details as possible
<alexbligh1> sladen, sure. Just checking it wasn't me being dumb.
<sladen> alexbligh1: yeah, even in the worst case, it should allow others to find the discussion (and then it won't feel so dumb :)
<alexbligh1> sladen, done - https://bugs.launchpad.net/ubuntu/+source/nbd/+bug/1600210 - but in general files in /etc/default should continue to work with systemd, yes?
<ubottu> Launchpad bug 1600210 in nbd (Ubuntu) "bind9 RESOLVCONF does not work" [Undecided,New]
<sladen> alexbligh1: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744304  may/may not give points.  That is talking the interaction of systemd and the "bind9-resolvconf.service" (which might imply it is separate?)
<ubottu> Debian bug 744304 in bind9 "bind9-resolvconf.service immediately stopped after starting" [Important,Open]
<alexbligh1> sladen, hmm, that service is showing as disabled.
<alexbligh1> sladen, ok, with a bit of poking around, and applying the fix in that bug, I got it to work - thanks!
<rbasak> alexbligh1: thank you for the report. I've marked it for assignment soon (I generally trust your reports to be high quality)
 * ogra_ shakes his head ... 
<ogra_> weird times where s3390x, ppc64el and arm64 are always buildingimages faster than any x86 arch
<pitti> cjwatson: is it intended that https://code.launchpad.net/~ubuntu-release/+git/britney2-ubuntu does not appear on https://code.launchpad.net/~ubuntu-release ? I. e. is the latter "only bzr" for some backwards compat reasons?
<infinity> ogra_: Not so werid for the first two.
<infinity> pitti: Not for backward compat reasons, just unimplemented features.
<sladen> kudos to both alexbligh1 and rbasak !
<cyphermox> good morning!
<alexbligh1> rbasak, sladen thanks!
<cjwatson> pitti: There are various awkwardnesses when both bzr and git are involved somewhere; I don't think we'd claim that what we have now is the best UI.  There's a "View Git repositories" link
<pitti> cjwatson: thanks
<pitti> infinity: good timing -- we actually did get a new perl right after glibc :)
<highvoltage> win 30
<marlinc> Is there anything I can do against gbp buildpackage running the tests as root in the chroot?
<rbasak> Use a container perhaps?
<rbasak> I'd like to see a schroot driver that uses lxd.
<dobey> doesn't it use fakeroot?
<dobey> or is it not using pbuilder/sbuild, which i thought dropped privs to do the actual build?
<marlinc> I'm actually unsure. This is the first time packaging something
<marlinc> I noticed that the tests are failing as Apache (its part of the tests) does not allow the WSGI module to run as root
<dobey> not sure, as i've not used gbp before
<marlinc> Interesting, all of the files in the chroot are owned by the pbuilder user but it appears the Makefile is being run as root
<marlinc> Actually, wait
<cjwatson> marlinc: If you're running tests from the wrong debian/rules target, it may be running them under fakeroot, which would cause the tests to see UID 0 even though they aren't actually running as root.
<rbasak> What I said makes no sense, sorry.
<rbasak> I was thinking of other things, not being root.
<pitti> marlinc: in some of my packages I run "env -u LD_PRELOAD make" in override_dh_auto_test: for that
<pitti> unfortunately dh_auto_test runs in the fakeroot part by default
<pitti> marlinc: err, "make check" of course, not just "make"
<cjwatson> pitti: err, it does?
<pitti> apparently so
<cjwatson> /usr/bin/dh seems quite clear that it runs in the build part
<infinity> Yeah, it shouldn't run in the binary bit.
<cjwatson> I think you have some other subtle bug if it's running under fakeroot; it doesn't by default
<cjwatson> I suspect marlinc may have a simpler problem if this is their first package though
<infinity> http://paste.ubuntu.com/18793505/
<marlinc> It  was running as root because I was being dropped into a shell which was root
<infinity> Note auto_test between build and testroot.
<marlinc> I switched to the pbuilder user and then it ran
<cjwatson> marlinc: ah, even simpler, I guess.
<marlinc> Now I'm running into another test that tries to run the Kerberos KDC but can't as it can't open 88 as lower than 1024
<pitti> maybe that got fixed in the meantime, but I had to add this hack to more than just one override_dh_auto_test in the past
<pitti> I'll try dropping them, thanks for pointing out
<marlinc> https://pagure.io/ipsilon/blob/master/f/tests/helpers/common.py#_327
<infinity> marlinc: So, you have a schrÃ¶dintest that wants to run both as root and not root?
<cjwatson> marlinc: I think you'll have to arrange to run it on some other (preferably non-fixed) port somehow.
<cjwatson> It's not totally uncommon for tests to be somewhat badly written until packagers get to them and fix them up. :-)
<marlinc> I guess so yes... I'm talking with the developer of the project. There's probably something the Fedora packaging thing does
<marlinc> They themselves run the tests as non root as wel
<marlinc> Brb
<cjwatson> Yeah, most distros build packages as non-root.
<tdaitx> slangasek, openjdk9 has been kind broken for a while (LP: #1550950), but as doko stated that since jdk9 has not been released yet this is not a problem and whoever wants can fix that... problem is I just got a new report (LP: #1600269) where jdk9 is being installed by default because due to openjdk-9-jdk's Provides:
<ubottu> Launchpad bug 1550950 in openjdk-9 (Ubuntu Xenial) "package openjdk-9-jdk 9~b102-1 failed to install/upgrade: trying to overwrite '/usr/lib/jvm/java-9-openjdk-amd64/include/linux/jawt_md.h', which is also in package openjdk-9-jdk-headless:amd64 9~b107-0ubuntu1" [Medium,Confirmed] https://launchpad.net/bugs/1550950
<ubottu> Launchpad bug 1600269 in openjdk-9 (Ubuntu) "package openjdk-9-jdk (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/jvm/java-9-openjdk-amd64/include/linux/jawt_md.h', which is also in package openjdk-9-jdk-headless:amd64 9~b114-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/1600269
<tdaitx> Provides: java-sdk, java2-sdk, java5-sdk, java6-sdk,
<tdaitx>   java7-sdk, java8-sdk, java-compiler
<tdaitx> slangasek, what would be the right approach? jdk9 is not ready, I don't think it should be replacing openjdk 8 in such a way... should we update/remove its Provides:? keep it on -proposed only? something else?
<tdaitx> note: openjdk-9 is available for both xenial and yakkety in universe
<infinity> tdaitx: Things are supposed to depend on default-jre as a preferred alternative, but I suppose we can't control random packages in PPAs.
<infinity> tdaitx: The file overlap bug should be fixed regardless.
<tdaitx> infinity, that package depends on java-sdk, it can't depend on a jre
<infinity> tdaitx: Well, default-jdk then. :P
<tdaitx> infinity, ugh, of course
<tdaitx> my bad
 * tdaitx needs more coffee
<infinity> tdaitx: Anyhow, questions of crappy PPA packages aside, there's no excuse for uninstallable packages.  "It's not done yet" would have been a great argument for not uploading it at all, but once it's in the archive, it should, y'know, install.
<tdaitx> infinity, I agree
<infinity> And there goes my kneecap.
 * infinity just dropped the heaviest combination of objects known to man (a UK power plug with a ZA adapter attached to it) on his knee.
<marlinc> cjwatson, I was told that they were using some kind of wrapper that allows those things to run as root. Some kind of virtual network stack
<marlinc> Ah libsocket_wrapper
<cjwatson> you could certainly LD_PRELOAD a thing that fakes up the socketry
<cjwatson> and I see libsocket-wrapper is even packaged for us as well; looks plausible.
<marlinc> Ah, they do that already
<cjwatson> maybe you just need to build-depend on it.
<marlinc> https://pagure.io/ipsilon/blob/master/f/tests/tests.py
<cjwatson> right, so that suggests you want to Build-Depends: libsocket-wrapper, libnss-wrapper
<cjwatson> though it would appear to fail right now if they're unavailable?
<cjwatson> oh, no, only if specifically requested
<cjwatson> so yeah, build-depends ought to improve your life.
<marlinc> Just added them, lets see what happens
<rbasak> infinity: stepping on a UK power plug is worse. The way they're designed the prongs stick up :-/
<infinity> rbasak: My shattered kneecap will send your punctured sole a get well soon card.
<cjwatson> IRTA soul
<cjwatson> Which made the comment considerably more goth.
<tdaitx> infinity, thanks for the help, and I wish your kneecap a good recovery
<rbasak> I did that too :)
<infinity> cjwatson: *smirk*
<infinity> Punctured Soul isn't a bad band name.
<nacc> rbasak: it might be a bug (in debian too), due to 0014-force_libmysqlclient_r.patch
<nacc> rbasak: well will be one in debian
<nacc> http://paste.ubuntu.com/18797503/
<infinity> Ahh, did _r finally go away?
<rbasak> Ah yes, that'll be it. Thanks.
<rbasak> _r was a symlink in 5.6. It's gone in 5.7.
<infinity> About time.
<nacc> rbasak: can you file a debian bug? i'm guessing we'll need 16.04 and 16.10 bug tasks? I can also file it
<rbasak> nacc: will do.
<nacc> rbasak: although debian hasn't gone 5.7 fully, right? so they might need some twiddling
<infinity> nacc: If, as rbasak says, it's a symlink in 5.6, backing out the patch now won't hurt.
<rbasak> That's a point. It's not strictly a bug in Debian yet. It will be soon.
<rbasak> But yes, the patch won't hurt.
<nacc> infinity: yeah
<rbasak> IIRC it's a symlink. I'm told by upstream that it's definitely unnecessary to use _r in 5.6 however.
<rbasak> Upstreams may have a little more trouble if they want to maintain build compatibility against older versions.
<nacc> rbasak: hrm, although if it's using `mysql_config`, --libs_r just aliases to --libs, it seems ('-L/usr/lib/x86_64-linux-gnu -lmysqlclient -lpthread -lz -lm -lrt -ldl')
<nacc> digging a bit further to see if i can extract what gets configured
<rbasak> nacc: I'm racing through some testing to get some MySQL/MariaDB changes pushed before I finish in 20 minutes, so I'm going to ignore PHP for now and switch back to that. Thank you for your help.
<nacc> rbasak: sure, np, i'll keep digging on this, thanks for bringing to my attention
<mitya57> slangasek, hi, you said that you triggered a no-proposed retest of python-cryptography, but there's no difference
<mitya57> It's now the only blocker for sphinx migration
<slangasek> mitya57: heh; I tried to trigger for the python-cryptography in yakkety, the tests unhelpfully ran for the version in proposed; so it doesn't actually give us a baseline result. http://autopkgtest.ubuntu.com/packages/p/python-cryptography/yakkety/amd64/
<slangasek> mitya57: I'll run the tests locally to verify whether python-cryptography in yakkety is broken, and if I confirm that it is, I'll mark the test bad
<mitya57> Thanks!
<mitya57> Actually I still don't understand what's wrong with that cffi-backend dependency (because of which python-cryptography itself can't migrate)
<jbicha> is python-crypto related to the versioned provides issue mentioned at https://lists.ubuntu.com/archives/ubuntu-release/2016-July/003798.html ?
<mitya57> jbicha, looks like it is, thanks!
<mitya57> (though python-crypto â  python-cryptography)
<nacc_> rbasak: practical question for you, there's a bug filed in debian to update to 2.6.11, and i'm finding htat the 2.6.6 packaged in yakkety, while significantly better, is hitting a number of bugs i know are fixed in 2.6.11. I'm backporting those fixes to my PPA for testing, but I wonder how/when we decide to pick up a new upstream ahead of Debian? `uscan` with the current package sees the new upstream
<nacc_> version
<marlinc> cjwatson, how can I check if OpenLDAP has a particular backend compiled in?
<marlinc> #    --enable-mdb         enable mdb database backend no|yes|mod [yes]
<marlinc> I guess that means that it is
<jrwren> unless configure is invoked with --disable-mdb in debian/rules
<tarpman> marlinc: if you're looking at the openldap package in ubuntu, the relevant configure.options line is --enable-backend=mod - we build all the optional backends as loadable modules
<marlinc> Ah mm okay
<tarpman> *enable-backends
<marlinc> I can't find any mdb package. I'm actually unsure what that backend is but it is required by unit tests run by Ipsilon which I'm trying to package
<tarpman> marlinc: no idea what Ipsilon is. are you looking for openldap's mdb backend, or the lmdb library itself? that's in a separate library package, src:lmdb
<marlinc> The mdb backend
<tarpman> marlinc: or do you mean ipsilon needs to configure and run a slapd instance
<marlinc> Ipsilon is a web identify provider for SAML, OpenID, etc
<marlinc> No, it just uses it in the unit tests to check whether it can work with a LDAP server as backend
<marlinc> And its unit tests set up a OpenLDAP server using the mdb backend
<marlinc> tarpman, https://pagure.io/ipsilon/blob/master/f/tests/slapd.conf#_16
<tarpman> yeah, looking at that
<tarpman> that slapd.conf is assuming the redhat/fedora openldap package layout
<tarpman> we have /etc/ldap, not /etc/openldap
<marlinc> Yea, I fixed most of that already
<tarpman> and you'll need to load the back_mdb module; redhat have linked it right into slapd
<marlinc> Ah, so its loadable?
<tarpman> yes
<marlinc> Interesting, let me see how I can do that
<tarpman> add 'moduleload back_mdb' somewhere near the top
<marlinc> Lets try that
<tarpman> before any of the database or access definitions
<slangasek> nacc_: regarding pulling a new upstream version before Debian, this is OK to do whenever you think it's justified in terms of Ubuntu's quality; the one caveat I have is that if upstream doesn't provide a release tarball that can be imported byte-for-byte, we can get into trouble later with syncing/merging when Debian ends up with a different tarball than we do
<marlinc> I thought I had to install a separate package for that
<tarpman> no, all the core plugins (backends/overlays) are included in the slapd package
<marlinc> Lets see what the tests do now ;)
<marlinc> Thanks a lot
<marlinc> The slapd based tests now succeed, thanks!
<tarpman> cheers
<nacc_> slangasek: ok, it shoudl be identical in this case
<nacc_> slangasek: (using uscan for obtaining it in both cases)
<nacc_> slangasek: i'm filing bugs against the debian version of cobbler too, but honestly, i'm hopefuly they'll just update too and we can sync
<nacc_> slangasek: thanks for the clarification!
<slangasek> nacc_: uscan can get fancy - if it's only downloading a fixed tarball, perfect.  If it's repacking things for you under the hood, not so perfect ;)
<nacc_> slangasek: right, i'll double-check that, thanks for the reminder
<nacc_> slangasek: that would normally be seen with a 'repack=' in debian/watch, right?
<nacc_> slangasek: i'll also of course check the orig.tar.gz it produced
<Unit193> That's interesting, it's 'dfsg' but nothing in d/copyright, no get-orig-source, and of course no watch magic..
<nacc_> Unit193: you're referring to cobbler? yeah, i was seeing the same thing :)
<Unit193> (Figured I'd take a quick look.)
<nacc_> also i dont' see how they can claim that it works for openstack in debian (from the original packaging bug). I've found at least two basic issues that prevent it from working at all :)
<nacc_> Unit193: thanks for taking a look and confirming what i was seeing!
<Unit193> nacc_: Sure, didn't do much.  And of course d/changelog has nothing so one would have to actually diff, wow..
<nacc_> Unit193: it might just be the jquery bits
<rbasak> nacc_: we can go ahead of Debian any time we like. The only real criteria is that we're prepared to look after it that way until we're in sync again.
<rbasak> It's nice to send them patches, of course, but it's not unusual for them to take time to pick that up and update when we want it sooner.
<nacc_> rbasak: yep, i'm hoping that debian will respond to the bug already filed there, but then again there hasn't been much movement on cobbler since 2.6.6 was pacakged (afaict). I'm happy to watch cobbler in ubuntu, but 2.6.11 is a big improvement in a lot of ways (especially for IBM's hardware, as that was why i was working on it :)
<marlinc> Someone with experience with characters and newlines not appearing in a terminal?
<marlinc> root@marlinc-laptop:/tmp/buildd/ipsilon-1.2.0# bash: aaaaaaaa: command not found
<marlinc> root@marlinc-laptop:/tmp/buildd/ipsilon-1.2.0
<marlinc> It happens every so often
<rbasak> nacc_: the risk is that if Debian is taking a while now, that may be an indication that you're looking after it for a long time before you can sync again.
<rbasak> nacc_: from a Canonical perspective I think we can spend time on returning it back to Debian, but I'm not sure that time spent maintaining it ahead of Debian is justified.
<nacc_> rbasak: yep, it's a tough balance
<nacc_> rbasak: but even the debian package as-is needs fixes (which i'm working my way through)
<nacc_> rbasak: most of which are fixed upstream already
<nacc_> rbasak: i would almost be willing to do this as a contribution to Ubuntu, rather than anything to do with Canonical, as what's shipped now is bad and i'm tired of telling users to build from source because debian & ubuntu have old/bad packages :)
<rbasak> nacc_: you're welcome to do that :)
<marlinc> Are non build dependencies also being installed when building a package?
<nacc_> marlinc: not sure i fully understand your question -- but i believe only the listed build-dependencies are installed to build a package; are you seeing a different behavior?
<marlinc> I was just wondering
<marlinc> I thought that it might actually install all dependencies for the package in the build environment
<nacc_> marlinc: it would depend on what 'it' is in your sentence; but i don't think that's generally true
<Unit193> nacc_: And yeah, that's never fun, nor when upstream does it because of getting bugs that've been long fixed. :/
<nacc_> Unit193: yep
<marlinc> Nvm nacc_
<marlinc> Does anyone know  of a particular way to run tests as a non root user? I'm using pbuilder using gbp buildpackage to build the package
<marlinc> Actually, let me check how the Makefile gets executed because its running as non root already but I'm getting a few permission errors
<marlinc> Mm actually, no
<marlinc> uid=0(root) gid=0(root) groups=0(root),1234(pbuilder)
<nacc_> marlinc: do you mean the debian/tests tests?
<marlinc> No, debian/rules is running the tests in the Makefile. (By default it appears)
<nacc_> marlinc: oh you mean during the build?
<marlinc> yes
<nacc_> marlinc: i've not used pbuilder, but sbuild should dtrt, in my experience (and it doesn't build as root)
<marlinc> The Makefile is being run by root which in turn causes the unit tests to be run by root as well
<marlinc> Mm okay
<nacc_> marlinc: builds should not be run as root generally (afaik)
<Unit193> nacc_: The build is run under fakeroot either way, sooo.
<marlinc> Ah Unit193 that could be it
<nacc_> Unit193: ah
<marlinc> Then I guess I will have to find a way to run a particular part without fakeroot?
<marlinc> In this case a Apache module that is used in the tests is not willing to run as 'root'
<nacc_> marlinc: what package is this? your own?
<marlinc> I'm trying to build a Debian package for Ipsilon
<marlinc> There's not package out for Debian yet
<sarnold> try prepending LD_PRELOAD=""  or "unset -v LD_PRELOAD" or something similar
<sarnold> (keeping in mind that every single line in a Makefile is run in its own shell)
<Unit193> https://wiki.debian.org/FakeRoot and yeah, don't think in pbuilder that'd be enough, though?
<marlinc> https://pbuilder.alioth.debian.org/#nonrootchroot
<marlinc> It appears I have to su to $BUILDUSERID?
<marlinc> That environment variable is not set however
<sarnold> Unit193: I suspect the pbuilder just runs something like "fakeroot make ..." and lets LD_PRELOAD propogate through all child processes; if you unset LD_PRELOAD before running a command in the middle, that should stop it..
<marlinc> It appears to be doing this
<marlinc> make: 'build' is up to date.
<marlinc>  fakeroot debian/rules binary
<marlinc> Let me see
<marlinc> Setting LD_PRELOAD="" in the Makefile appears to work
<marlinc> I see, dh_auto_build runs make -j1 which then starts the tests etc
<cjwatson> marlinc: If pbuilder is running the build target under fakeroot, it's buggy IMO.  Only the binary target should be run under fakeroot.
<cjwatson> marlinc: I don't think you should have to work around foolish tools running the build target under fakeroot.
<marlinc> I'm not sure what's up but the Makefile gets run from the binary target as far as I can see
<marlinc> cjwatson, do you know of a Python application that uses setup.py that I can look at as a reference?
<marlinc> openstack-dashboard doesn't use setup.py unfortunately
<cjwatson> marlinc: Perhaps you could pastebin your current debian/rules
<marlinc> https://gist.github.com/Marlinc/4e2bb7a5ba3d72ce4d200a051e53faef
<cjwatson> marlinc: and do you have a build log?
<cjwatson> marlinc: germinate is the first thing that comes to mind that meets your stated requirements, but it may be a bit overcomplicated.
<cjwatson> marlinc: you need to be more specific about what you mean by "the Makefile gets run from the binary target" - "make" will likely be run both from (indirectly) build and binary, with different arguments (make vs. make install, say)
<marlinc> cjwatson, just leave the root issue for now I guess. :)
<cjwatson> marlinc: I don't think you will be better off trying to sweep this under the carpet and ignoring it
<marlinc> I'm not planning on ignoring it
<Unit193> Disclaimer: I don't know pbuilder internals, though would presume it's not doing stupid things.
<cjwatson> marlinc: you're describing a behaviour which is alien to me (from 15+ years of building Debian-format packages), and my instinct is that this kind of thing is better off investigated early
<cjwatson> as otherwise you can end up wasting your time on knock-on effects
<marlinc> Okay, well lets start the build
<cjwatson> marlinc: it's also weird that you're having to explicitly log into the chroot and su and stuff
<cjwatson> marlinc: I thought you were meant to use pdebuild or whatever it is and have that do the whole thing for you
<cjwatson> (I use sbuild, but the principle should be the same)
<marlinc> I only had to because the tests were failing because of the root issue. Setting LD_PRELOAD="" worked around the issue
<marlinc> Let me remove the statements and see where it goes wrong
<marlinc> I'll Gist the output
 * cjwatson -> children's bedtime
<marlinc> Gn!
#ubuntu-devel 2016-07-10
<mapreri> cjwatson: too lazy to read everything, but pbuilder doesn't do anything weird with fakeroot, it just passes -rfakeroot to dpkg-buildpackage
<mapreri> marlinc: besides, that documentation is severely outdated, and I'm crawling to have somebody take care of that.  Since more years than I can remember pbuilder builds by default as non-root
#ubuntu-devel 2017-07-03
<chiluk> what would be the correct way to version mythtv if I'm goign to upload a fix for x-a?
<chiluk> z=0.28.0+fixes.20170206.03f4403-0ubuntu3.1 and a=0.28.0+fixes.20170206.03f4403-0ubuntu5 ... but what for x and y?
<hloeung> chiluk: guess that worked! Thanks for reporting this
<chiluk> x = 0.28.0+fixes.20160413.15cf421-0ubuntu2-16.04.0 ? y=0.28.0+fixes.20160413.15cf421-0ubuntu2-16.10.0?  I can't use ~ here because it will version below what's currently there..
<hloeung> err that was meant to be a PM
<chiluk> hloeung: still trying to figure out what's correct for x and y..
<chiluk> cyphermox_: ^^ when you wake up want to give me a little mentorship on the above?
<chiluk> arges may like to educate me as well. ^^  ..
<chiluk> and one last question.. when uploading should my changelog point at the <release>-proposed pocket or to the <release> pocket?
<cjwatson> chiluk: Either is fine - they're mapped to the same thing.  I normally go for just <release>
<cjwatson> chiluk: xenial should be 2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.04.1, yakkety 2:0.28.0+fixes.20160413.15cf421-0ubuntu2.16.10.1
<cjwatson> chiluk: (per the security team's practices - there are various possibilities but this will do)
<cjwatson> chiluk: you mustn't use a "-" to separate the last bit - that has surprising effects on how the version is parsed that you don't want
<cpaelzer> hi, it seems all LP build recipes for artful fail since over the weekend  - I see some apt complains about not signed Release files
<cpaelzer> https://launchpadlibrarian.net/326582597/buildlog.txt.gz
<cpaelzer> anybody seen similar recently?
<Unit193> Scollback here has some info on it, specifically from julian k and cj watson.
<cpaelzer> thanks Unit193 - will read back on this then
<Unit193> Basically, apt did it, "whoops"
<cpaelzer> That is => https://bugs.launchpad.net/launchpad-buildd/+bug/1701826 then
<ubottu> Launchpad bug 1701826 in launchpad-buildd "APT 1.5: E: The repository 'file:/home/buildd/work/apt ./ Release' is not signed. " [Critical,In progress]
<cpaelzer> thanks
<jamespage> o/
<jamespage> morning all
<jamespage> doko: hey - I'm blocked on a ceph upload for artful on https://bugs.launchpad.net/ubuntu/+source/gcc-6/+bug/1702044
<ubottu> Launchpad bug 1702044 in gcc-6 (Ubuntu) "arm64: segmentation fault during ceph build" [Undecided,New]
<jamespage> arm64 only afaict - would you have time to take a look?
<jibel> could someone help with bug 1700557 ?
<ubottu> bug 1700557 in linux (Ubuntu) "VM doesn't boot after installation until an input event is received" [High,Incomplete] https://launchpad.net/bugs/1700557
<jibel> xnox, ^ maybe ?
<juliank> cpaelzer: sorry
<juliank> Who imagined that apt migrated that fast?
<cpaelzer> migrations are only slow when you need/want them fast :-)
<juliank> cpaelzer: Oh, I wanted it fast for testing, but forgot to think about the LP implications
<cpaelzer> hehe
<juliank> or maybe I even only noticed them after the upload
<cpaelzer> you probably hit the best week you could to affect few people with the 4th of july ahead
<juliank> cpaelzer: I'm pretty sure that's a fairly US-centric point of view
<Unit193> mwhudson: Even given https://anonscm.debian.org/cgit/pkg-go/packages/golang-github-jacobsa-crypto.git/commit/?h=debian&id=f78d4a91ed54ec4ac3c70a8cd921858964f7ed71, not sure why armhf failed..
<mwhudson> Unit193: unaligned access? he says without actually thinking about anything at all, i just saw armhf in there
<Unit193> Interesting that s390x "moved" though.
<mwhudson> yeah that seems a bit fishy
<mwhudson> golang doesn't really support s390x on debian though
<mwhudson> (debian supports super old isas)
<Unit193> Maybe a mistake when he was correcting the 'le' â 'el' typo?
<mwhudson> um
<mwhudson> the golang arch is ppc64le
<mwhudson> so that's definitely a mistake :)
<Unit193> Meh, I don't know golang at all. \o/
<Unit193> So yes, no idea where the regression was for the one at least.
<mwhudson> Unit193: where did armhf fail?
<mwhudson> oh autopkgtest?
<mwhudson> oh build failed
<mwhudson> not unaligned access then
<mwhudson> i'm sure there should be something about _why_ the build failed in the log ...
<mwhudson> Unit193: uh that patch adds too many commas by far, i think
<mwhudson> it should just be // +build 386 arm  mips mipsel s390x
<Unit193> Seems very vague to me, but s390x failed tests during build.
<mwhudson> (well probably not x390x)
 * mwhudson is not here btw
<Unit193> OK, you do a very good ghost.
<xnox> jibel, =/ not me, i'm not at all sure what's happening there.
<chiluk> thanks cjwatson.. I had a feeling I was missing something there.
<cjwatson> slangasek: could you merge debconf, or do you want me to?  I'd like to get something based on 1.62 into artful so I can proceed with the next stage of splitting out python{,3}-debconf
<cjwatson> 1.5.62 that is
<cjwatson> slangasek: (also not having at least 1.5.61 is going to be very bad as soon as the next perl transition lands)
<seb128> speaking about debconf and perl is anyone working on replacing libgtk2-perl by something more modern?
<cjwatson> I'd be very happy to take a patch to convert it to GI but I don't think anyone's working on it at the moment
<cjwatson> (unless I missed a patch somewhere)
<seb128> ok, thanks
<seb128> everybody is busy so I doubt we have anyone at the moment to help on that
<seb128> but let's see if we can make space for it, I would really like to get gtk2 out of the iso this cycle or next
<sil2100> !dmb-ping
<ubottu> bdmurray, BenC, cyphermox, infinity, micahg, rbasak, sil2100: DMB ping.
<doko> jamespage: is it expected that ceph doesn't used parallel builds for it's subdirs?
<jamespage> doko: hmm
<jamespage> doko: that might be possible but I would expect a level of paralleism to some level
<jamespage> doko: on the lp builders, we quite often hit memory limits so the max parallel gets limited
<leitao> apw: I am currently installing 16.04.3 beta (http://ports.ubuntu.com/ubuntu-ports/dists/xenial-proposed/main/installer-ppc64el/current/images/hwe-netboot/ubuntu-installer/ppc64el) but it does not find kernel 4.10-27.
<leitao> it seems that kernel -27 is at proposed at this moment.
<leitao> I understand I should enable -proposed during the installation.
<leitao> I understand that the right way to do so is using "apt-setup/proposed=true".
<leitao> but I am not able to install this beta version.
<leitao> any recomendations?
<chiluk> can i have someone reject my upload of mythtv in the yakkety queue... apparently the original sources were never rebuilt for yakkety and it ftbfs's even without my changes... I'll upload a fix for all that shortly.
<juliank> infinity: in case you missed it: You can start removing apt-transport-https from the artful chroots :)
<chiluk> infinity: ... I'm not sure how you feel about the intel-microcode update,  but I put it on the x and y upload queues for your SRU perusal
#ubuntu-devel 2017-07-04
<slangasek> cjwatson: debconf merged.  What do you think about us getting that last delta upstreamed?  Seems appropriate enough in both Debian and Ubuntu
<manjo> other freenode channels are getting spammed .. just fyi .. pretty bad stuff
<manjo> seems to have started exactly at CST midnight
<cjwatson> slangasek: Thanks.  I was never entirely comfortable with upstreaming that delta - Joey had a middle-ground suggestion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=501767
<ubottu> Debian bug 501767 in debconf "[patch] hide cancel and close in the gnome frontend" [Normal,Open]
<hjd> When preparing an SRU, should the "target release" at the top of the changelog entry be (for instance) "zesty" or "zesty-updates"?
<klebers> hjd, at least for the kernel pkg, the release on the changelog would be always for instance "zesty"... which pocket the pkg will land on is determined by some tooling and manual reviews
<hjd> Ok, I saw some updates marked with "release-security", but couldn't find any equivalent "release-updates", is the security pocket a special case?
<cjwatson> "always"
<cjwatson> there's certainly some mapping that takes place
<cjwatson> "zesty-updates" would be wrong because the changelog defines the initial upload target, and SRUs are always tested before going into -updates
<cjwatson> either "zesty" or "zesty-proposed" is fine (the former is mapped to the latter); I personally prefer just "zesty"
<cjwatson> security is indeed a special case
<cjwatson> the kernel is unusual in a bunch of ways but not least because the initial upload target in that case is typically a PPA, so different rules apply
<hjd> Thanks :)
<hjd> Another, rather unrelated question, what is the preferred way to do a package merge from Debian these days?
<hjd> I seem to rememer using `bzr merge` at some point, but that was quite a while ago...
<hjd> *remember, even
<mitya57> hjd, either manually, or use grab-merge(1) from ubuntu-dev-tools.
 * hjd checks out grab-merge
<rbasak> hjd: the server team uses https://wiki.ubuntu.com/UbuntuDevelopment/Merging/GitWorkflow now
<dilip> Hi
<dilip> Can I make a request here ?
<dilip> Any chance to use a Cortana like Voice Assistant with Ubuntu ?
<mpt> dilip, that would be cool, but developing it would take years and be massively expensive
<dilip> @mpt , can I make a suggestion ?
<udevbot> Error: "mpt" is not a valid command.
<dilip> There are a few project available
<dilip> AskUbuntu guys were suggeting Jasper, Mycroft etc
<dilip> Also, Google has some library related to it.
<juliank> So, I'm about to do the first stable release for apt 1.4.y on the Debian side (1.4.7). This will essentially be synced into zesty, but I'd probably like to reduce the amount of work with the reuploading to Ubuntu.
<juliank> Would the easiest thing to just change the field in the changes to zesty then and upload here?
<juliank> I could syncpackage, but that means no diff for reviews
<mpt> dilip, yes, but the speech recognition and AI are just a small part of it. You also need things for the commands to do. And most Ubuntu apps and shell components arenât even scriptable with a perfectly-written text command, let alone a speech command.
<dilip> #mpt I see. No hope then ?
<mpt> dilip, well, you could start small. For example, many music players on Ubuntu work with the Mpris API. So a useful start would be training a program to understand commands like âPlayâ, âPauseâ, âNextâ, âStart againâ, etc, and issue the equivalent Mpris command. Since the vocabulary would be fixed, youâd need only speech recognition for that.
<dilip> Ok :)
<juliank> We really gotta get these apt SRUs done at some point, otherwise the queue just gets fuller, 1.4.7 is about to be released
<tdaitx> cyphermox_, trying to install a ubuntu desktop image (either zesty or artful current), but ubiquity gtk fails (some freetype failure according to stacktrace)... subiquity crashed as well with no meaningful message while I was entering the user data (name, username, etc) - it also didn't detect existing gpt or msdos partitions
<tdaitx> is there any way to install using the debconf frontend?
<tdaitx> maybe I will have better luck there
<tdaitx> btw, apport/whoopsie should have uploaded the report from the failures, they are the same I had on my notebook (I ended up using debootstrap at the time, but that is not optimal) - now I'm installing on another machine and facing the same issues o.O
<tdaitx> xnox, slangasek ^ in case there is someone besides matt that can give me some pointers here
<xnox> tdaitx, you can use server installer to install; and then install ubuntu-desktop
<xnox> tdaitx, you can use netinstaler / mini.iso to do network install and select ubuntu-desktop package
<tdaitx> xnox, that means zesty, or is there an artful somewhere?
<xnox> for all ubuntu releases since the dawn of time
<xnox> tdaitx, "debconf frontend" i hope you mean d-i, rather than "ubuntu debconf frontend, which I believe only works for oem preseed installs"
<xnox> tdaitx, do you need links?
<tdaitx> xnox, gah, no, just found the server image =)
<tdaitx> tks
<xnox> tdaitx, you can follow the netboot images from http://cdimage.ubuntu.com/netboot/ it's a bit smaller download - like under 100MB but then it downloads everything off the net to do bootstrap. I find server image install + install ubuntu-desktop afterwards faster, on slower networks.
<xnox> http://archive.ubuntu.com/ubuntu/dists/zesty/main/installer-amd64/current/images/netboot/mini.iso is only 58M
<tdaitx> server should work, just 3 more minutes to get it
<xnox> cool. good night
<tdaitx> tks, good night =)
<tdaitx> btw, yeah, I meant the d-i
#ubuntu-devel 2017-07-05
<jbicha> the autoimporter from sid appears to have got stuck yesterday around https://launchpad.net/debian/+source/gnome-settings-daemon 3.22.2-3
<elopio> Trevinho: it is. Sorry, super late reply. Go to http://ubuntuonair.com, it's still there.
<elopio> Trevinho: our most watched video so far. Thanks!
<jbicha> cjwatson: just making you saw my earlier comment about the autoimporter from sid getting stuck
<jbicha> let me know if there's someone else I should ping
<cjwatson> jbicha: William fixed that earlier; next run should work
<jbicha> thanks! maybe I'll ping him next time then :)
<Trevinho> elopio: yay :)
<coreycb> hello sru team, i have a few small libvirt uploads that I could use a review for if someone has a moment.  this is for bug 1644507.
<ubottu> bug 1644507 in libvirt (Ubuntu Zesty) "[SRU] virt-aa-helper denied access to qcow2 backing file running nova in a snap" [Medium,Triaged] https://launchpad.net/bugs/1644507
<cpaelzer> coreycb: I'll look at the change in general
<cpaelzer> coreycb: if possible in the future at least ping smb or me so we can make it part of the git as well
<cpaelzer> since libvirt is packaged via a git repo
<cpaelzer> otherwise things get lost too easily in e.g. a merge
<coreycb> cpaelzer: ah yeah will do, i know that is a pita.  i meant to look into that but forgot.
<cpaelzer> also the new "policy" is to try to upstream apparmor changes :-)
<cpaelzer> more pita but the only way to stop growing infinitely
<cpaelzer> I'll make the change also part of the continuous upstremaing efforts
<cpaelzer> might reference to you for discussion at some point in the future
<cpaelzer> coreycb: ^^
<coreycb> cpaelzer: ok thanks
<seb128> slangasek, hey, did you have any chance to look at that nplan autopkgtest/n-m/mtu issue?
<cpaelzer> coreycb: hmm isnt't that failing for snapshots?
<cpaelzer> coreycb: old rules for base  .../_base/**
<cpaelzer> old rules for snapshots .../snapshots/**
<coreycb> cpaelzer: maybe. we've only done basic deploy an instance testing.
<cpaelzer> and you add .../snap/nova-hipervisor/ in the path for base
<cpaelzer> I'm pretty sure it will need snapshots as well
<coreycb> cpaelzer: ok. i'll take a look.
<coreycb> cpaelzer: thanks
<cpaelzer> coreycb: do you mind if for now I carry it as http://paste.ubuntu.com/25025524/ ?
<cpaelzer> and take you as the author still
<cpaelzer> nacc: dpb1: will you be aroudn for the stanup?
<cpaelzer> +d
<dpb1> cpaelzer: yes
<coreycb> cpaelzer: sure np, i'll test that out today
<coreycb> cpaelzer: and will get back to you
<cpaelzer> coreycb: ok, I already added it to the coming merge for artful that way
<cpaelzer> coreycb: so let me know what/if needs to be modified
<slangasek> seb128: I have been looking, but have struggled to set up a proper reproducer environment; when I run the autopkgtests in a VM, the tests wind up clobbering the network config and then failing in unrelated ways.  Have you had better results?
<seb128> slangasek, no, I struggled as way  with the env and since cyphermox_ seems to have a better handle on how to test that I let it to him and stopped trying
<seb128> slangasek, I guess at this point we could wait for him to be back (but unsure how high it's going to be in his backlog/priority list then)
<slangasek> seb128: ok. I'll spend some more time on it today, and if I can't figure it out it'll wait for cyphermox_.  I think unblocking the desktop team's work and keeping p-m functioning correctly should be fairly high up the priority list
<seb128> slangasek, thanks
<rbasak> Bug 1693850: will adding -D_LARGE_FILES -D_FILE_OFFSET_BITS=64 cause any ABI break or similar?
<ubottu> bug 1693850 in libzen (Ubuntu Zesty) "libzen wasn't compiled with large file support" [Undecided,Triaged] https://launchpad.net/bugs/1693850
<juliank> slangasek: You're right, it seems we never really documented dir::etc::netrc somewhere - the path is /etc/apt/auth.conf
<juliank> that's not god
<juliank> s/god/good/
<slangasek> juliank: :)
<slangasek> it certainly seems like a good change, it just doesn't help us much if it's undocumented :-)
<juliank> slangasek: We have this since 2009, and nobody mentioned that before :)
<juliank> Despite us telling people since about 5 years or so to please use it instead of non-world-readable sources.list files, so that's a bit strange
<juliank> Should add that to sources.list(5) and apt.conf(5)
<juliank> slangasek: the request for that is in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=811181
<ubottu> Debian bug 811181 in apt "apt: Please document auth.conf" [Wishlist,Open]
<slangasek> juliank: awesome, thanks :)
<juliank> I gotta learn this snapcraft stuff.
 * juliank wants to build an apt snap just to be weird
<clivejo> anyone having issues with networking on Artful?
<clivejo> my DNS just seems to keep dying :/
<jbicha> clivejo: if you have dnsmasq or dnsmasq-base installed, I would uninstall them
#ubuntu-devel 2017-07-06
<LocutusOfBorg> Laney, can you please update src:agda? it can't build with new haskell stack
<LocutusOfBorg> should be trivial to do
<LocutusOfBorg> otherwise I can do it, with some permission
<LocutusOfBorg> I think I did the work
<Sonnenstrahlen> Hallo zusammen
<doko> infinity: now tracking as https://bugs.launchpad.net/ubuntu/+source/binutils/+bug/1702679, and reported upstream binutils for now
<ubottu> Launchpad bug 1702679 in binutils (Ubuntu) "binutils fails to build glibc-2.24 on aarch64-linux-gnu and arm-linux-gnueabihf" [High,Confirmed]
<xnox> jbicha, cyphermox_ looks like there is a genuine netplan regression with 1.8 network manager
<xnox> i will try to look into that, as I want 1.8 network manager to migrate
<xnox> it's tasty
<seb128> xnox, slangasek was looking at it a bit, unsure if you synced up with him (just mentioning to avoid work duplication)
<xnox> seb128, oh ok. nope, i'm in parallel to slangasek.
<seb128> k
<seb128> well he said he was having issues to set up an env to work on the problem but that he would try a bit more
<seb128> that was yesterday
<seb128> so unsure how much he did
<xnox> ack.
<xnox> cause i have resolved+nm+vpn bug to fix, and i think it would be nicer to fix it on top of v1.8 /after/ that migrates.
<xnox> to not coflate the upgrade.
<seb128> right, we would like n-m to migrate as well
<seb128> I discussed the issue with cyphermox before he was off, he said he would look at it but didn't manage to do that before being on vac
<rbasak> dh: unable to load addon systemd: Can't locate Debian/Debhelper/Sequence/systemd.pm in @INC (you may need to install the Debian::Debhelper::Sequence::systemd module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.22.1 /usr/local/share/perl/5.22.1 /usr/lib/x86_64-linux-gnu/perl5/5.22 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.22 /usr/share/perl/5.22 /usr/local/lib/site_perl
<rbasak> /usr/lib/x86_64-linux-gnu/perl-base .) at (eval 15) line 2.
<rbasak> Something changed from Xenial to Yakkety that makes this go away. ISTR something about this, but I don't see any different rdeps on dh-systemd.
<rbasak> Any pointers please?
<rbasak> Ah.
<rbasak> /usr/share/perl5/Debian/Debhelper/Sequence/systemd.pm moved to the debhelper package itself, and dh-systemd is now transitional.
<rbasak> So for a backportable package, I guess I want "Build-Depends: debhelper (>= 9.20160709) | dh-systemd".
<rbasak> Of course I need debhelper anyway, so would something like "Build-Depends: debhelper (>= 9.20160709) |
<rbasak> dh-systemd, debhelper (>= 9)" be acceptable?
<juliank> That sounds about right to me
<rbasak> Thanks!
<juliank> Of course, if you don't need backportability to older debhelpers, you could just use debhelper (>= 9.20160709)
<rbasak> I need backportability to Xenial, which only has debhelper 9.20160115ubuntu3
<juliank> OK. I wonder if the Depends should include a ~ in the version for backporting needs, not sure why there is none in dh-systemd
<rbasak> If you mean "Build-Depends: debhelper (>= 9.20160709~) | dh-systemd, debhelper (>= 9~)" then yeah I could do that.
<rbasak> I don't think the ~ in 9.20160709~ is really needed because falling back to dh-systemd in that case should always work, but might as well use debhelper in that case then I guess.
<juliank> I guess it's no problem anymore because dh backports are now higher-versioned anyway
<slangasek> xnox: I have not had much success reproducing that nplan failure however, because it's masked for me by lots of other failures
<xnox> slangasek, ack, ok. I assume i can take a stab at that.
<xnox> slangasek, btw the "split-dns-networkmanager-bug-not-work-right-with-vpn" is a bug in NM which missconfigures all of its dns backends.
<doko> infinity: https://sourceware.org/bugzilla/show_bug.cgi?id=21725 now has one additional update. could you have a look? but this one is for arm64 only
<ubottu> sourceware.org bug 21725 in binutils "[2.29 Regression] binutils fails to build glibc-2.24 on aarch64-linux-gnu and arm-linux-gnueabihf" [Normal,New]
<infinity> doko: That will certainly be an issue on arm64 (and maybe the only one there), but definitely not the same bit in the armhf log. :/
<doko> infinity: please backport e9177fba13549a8e2a6232f46080e5c6d3e467b1 as well, fixes the build on arm64. I cannot see in the build log, if something else fails before
<infinity> doko: Already done (it's haflway through the testsuite on rugby right now)
<infinity> doko: If that turns out happy, I'll look into armhf after I get some more point release HWE stuff sorted.
<infinity> doko: Confirmed arm64 happy, moving on to an armhf test build.
<ahasenack> hm, do-release-upgrade is upgrading a xenial desktop to yakkety instead of zesty
<ahasenack> I have "Prompt=normal" in /etc/update-manager/release-upgrades, not "lts"
<ahasenack> ah
<ahasenack> ok
<ahasenack> have to go step by step
<nacc> ahasenack: yeah, i think until yakkety goes eol (at least)
<ahasenack> so once Y is eol, xenial can't be upgraded anymore until the next lts is out?
<ahasenack> that thought never occurred to me before
<nacc> ahasenack: no, i think X -> Z will be possible (iirc)
<nacc> ahasenack: istr bdmurray mentioning this
<sarnold> there's old-releases too
<nacc> sarnold: true
<mitya57> jbicha, are you uploading qtbase yourself? I have already prepared my own upload to pushâ¦
<mitya57> oh, you already uploaded it :)
<mitya57> fine then
<jbicha> mitya57: were you planning to fix other stuff in your upload?
<mitya57> I saw your bug and prepared a merge with Debian unstable.
<mitya57> Anyway we have the large Qt 5.9 transition in progress, so all fixes from Debian will sooner or later get into Artful.
<jbicha> did you want to backport those other patches for zesty? the only issue that bothered me was the one gtk filechooser crash
<mitya57> For zesty, no.
<jbicha> mitya57: ok, I'll do the zesty SRU once I verify the artful package works for me
<mitya57> Ok, thanks for taking care of it!
<jbicha> I guess it's up to you whether you want to push the 5.7 merge or just wait for 5.9
<jbicha> I originally was going to ask you to do the upload but then I thought I've been annoyed by this bug for 6 months so maybe I can take care of it myself now :)
<mitya57> I will focus on 5.9 then.
 * mitya57 still waits for reply to his message on ubuntu-devel@...
<jbicha> mitya57: thanks for pushing my change to git, I think next time I'll just ask you to do the upload then :)
<mitya57> Ok, no problem :)
<jbicha> I forgot about the vcs
<mitya57> I wonder how you noticed that I pushed it so quickly.
<jbicha> I was just looking now for a vcs so lucky timing
#ubuntu-devel 2017-07-07
<hallyn> kees: hey - are you up for a ptrace question? :-)
<hallyn> kees: I'm wondering whether it's expected that PTRACE_O_TRACEEXIT not always catch all exits
<hallyn> I've got a testcase that fires off one child that spanws 100 threads, all are traced with PTRACE_O_TRACEEXIT .  2/3 times between 1-3 of the threads end exiting without a PTRACE_EVENT_EXIT
<hallyn> (i do get a WIFEXITED)
<kees> hallyn: that doesn't surprise me. the death handling for ptrace events is rather a mess :(
<kees> hallyn: IIRC Eric Biederman was working on some code to sort it out, but it has a lot of evil corner cases
<hallyn> kees: yeah i ran across a thread from earlier this year with Eric and Oleg...  drat.  reliability would be nice :)
<hallyn> i did see them asking "i wonder whether anyone uses this" :)
<hallyn> kees: but actually this i ran across in a testcase;  the more immediate but harder to reproduce case was one where i did get the PTRACE_EVENT_EXIT, i ptrace-detach, but then i get another waitpid event for it later
<hallyn> (and after the detach, /proc/pid/status shows still traced by the same task;  )
<tsimonq2> coreycb: Good morning. When you have a minute, could you please take a look at bug 1699426?
<ubottu> bug 1699426 in python-tornado (Ubuntu) "Merge 4.5.1-2 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1699426
<hjd> Hi, could someone please trigger a rebuild of node-magic-string in artful (https://launchpadlibrarian.net/327201368/buildlog_ubuntu-artful-amd64.node-magic-string_0.21.3-1_BUILDING.txt.gz). Failed to build intially, but works now that the latest version of node-es6-module-transpiler has been synced. TIA :)
<infinity> didrocks: Hey, apw just randomly Googled https://extensions.gnome.org/extension/413/dash-hotkeys/ for me.
<infinity> didrocks: I'm not sure what our goals are for painless migration, but that seems like a think Unity users might expect to work on upgrade.  Maybe.
<infinity> s/think/thing/
<didrocks> infinity: dash2dock (which we are considering) has a similar optional feature
<didrocks> I would be interesting to see that with an azerty keyboard btw :p
<infinity> didrocks: azerty keyboards are an abomination.
<didrocks> even in unity, it was all messed up before I patched it (yeah, number can be with Shift required on insane layouts!)
<didrocks> heh
<didrocks> I was waiting for that one :p
<didrocks> do you know there is a poll currently in France for standardizing it btw?
<didrocks> a mix between azerty + bepo
<didrocks> seeing the proposals, none are dev friendly though
<infinity> didrocks: Why not just standardize on qwerty + deadkeys, like normal humans.
<infinity> If it's good enough for the Japanese...
<infinity> And they have a whole lot more weird characters than you do.
<infinity> So suck it up.
<didrocks> because I guess we don't have a bunch of weird characters, so upfront cost for just a few ones
<infinity> Yeah. :/
<infinity> The "standard Canadian International" keyboard is a mess.
<infinity> And if I'm not careful, it's what lenovo.ca tries to ship me.
<didrocks> ahah "but it's all the same", right?
<infinity> Thankfully, they learned in their first year or so doing business here that most of us have never seen that layout and really don't want one.
 * didrocks googles
<didrocks> oh, looks yummy, indeed
<infinity> Yeah, it's qwerty, but very NOT PC101, and the differences matter.  A lot.
<infinity> Plus key shapes change to accomodate the madness, so even remapping it doesn't fix it.
<mdeslaur> eww, I hate that keyboard too
<infinity> mdeslaur: I assume it's more or less the standard for bulk consumer/office purchases in QC?  It would dive me nuts if I had to use it.
<mdeslaur> the language police mandate it
<xnox> cpaelzer, both debian and ubuntu packaging of systemd is managed in git, with shared history using gbp dch to manage the changelog and gbp pq to manage patches
<infinity> If only the PC world had discovered the Compose key.
<xnox> cpaelzer, i guess you simply want us to cherry-pick the serialisation / deserialisation patches for the cgoup units?
<infinity> Though deadkeys work well enough, once you train your fingers.
<xnox> cpaelzer, there is ./debian/git-cherry-pick script that does exactly that, and correctly injects patches in the right place for the patch series.
<mdeslaur> infinity: I don't get why they had to change the key sizes...the vertical enter and tiny backspace are insane
<infinity> mdeslaur: It's to accomodate extra keys.  It's fairly similar to the (equally broken, IMO) UK101 layout.
<xnox> cpaelzer, can you simply state the ids of the patches you are after; and series you want them in; and i can look into cherrypciking/backporting them and SRUing them throughout.
<xnox> cpaelzer, as i do manage systemd SRUs holistically, and there is always a queue of things that people want/need in the next upload.
<infinity> mdeslaur: The tiny left shift is what always trips me up.
<mdeslaur> ah yes, that too
<doko> mwhudson: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170706-zesty.html some python related failures
<doko> jamespage: http://qa.ubuntuwire.org/ftbfs/rebuilds/test-rebuild-20170706-zesty.html  some openstack related failures
<apw> didrocks, with that panel moved to the top and made the same size it was before ... it is pretty nice
<didrocks> apw: yeah, I guess we'll discuss soon about the ubuntu experience we can provide (but yeah, at worst, extensions)
<apw> didrocks, well if you make an ubuntu experience i guess it gets to be an extension ...
<apw> if you could make the alt do the menu like it did in ubuntu, across the top rather than in a button, that might be the best of all worlds
<jbicha> that's "global menus"
<jbicha> it wouldn't really make a difference for "native" GNOME3 apps that don't have traditional File Edit View menus
<coreycb> tsimonq2: hi, just commented. sigh.
<coreycb> jamespage: can you take a look at my comment on bug 1699426 and comment if you have an opinion?
<ubottu> bug 1699426 in python-tornado (Ubuntu) "Merge 4.5.1-2 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1699426
<jamespage> coreycb: we have both in main still?
<jamespage> that sounds wonky
<tsimonq2> coreycb: ack
<coreycb> jamespage: yeah
<powersj> slangasek: any idea why there are no daily amd64 or i386 daily server images? http://cdimage.ubuntu.com/ubuntu-server/daily/20170707/
<slangasek> powersj: good question
<slangasek> powersj: here's the i386 error from the log http://pastebin.ubuntu.com/25039610/
<seb128> xnox, slangasek, did you get anywhere with the nplan/n-m issue?
<slangasek> I have not
<slangasek> xnox seemed to believe it was a real regression introduced by NM
<apw> slangasek, when infinity was looking at iso issues this morning he found isolinux was unseeded, dunno if that could be the issue; he thought it was apt for a bit, which i would from that log there
<xnox> seb128, on my todo list
<slangasek> powersj: apparently this issue was identified and fixed last night for desktop; I'll retry ubuntu-server now
<powersj> slangasek: thanks
<slangasek> powersj: (discussion on #ubuntu-release)
<acheronuk> DNS on artful seems frequently broken
<acheronuk> ^^^ clivejo
<rbasak> nacc: the way I see "git ubuntu lint" working is a little like lintian - it'll act on HEAD by default, analyze, and print a load of warnings and errors.
<rbasak> Some stuff will need LP connectivity, which I think it should do by default, but have an offline option to turn that off (and lose some tests)
<nacc> rbasak: ack, are you ok with 'lint' as the subcommand? or 'review'?
<rbasak> nacc: I think review implies a human
<Unit193> nacc: Also, FYI I uploaded (to Debian) the package that recommends python3-parsedatetime.
<Unit193> (FSVO "I")
<nacc> Unit193: ok good to know
<nacc> rbasak: true, good point
<nacc> rbasak: i suppose we would eventually have two commands -- one for reviewing a MP and one for linting a current branch
<nacc> review could use lint then
<rbasak> Yeah
<slangasek> nacc, rbasak: you're not putting AIs in charge of your reviews? :)
<nacc> slangasek: one day :)
<nacc> All Interestedparties
<nacc> that's as clever as i can be on one cup of coffee
<rbasak> slangasek: we're working on it :)
<nacc> rbasak: around still?
<rbasak> nacc: just
<nacc> rbasak: your review comment, is 'branch_name' to pristine_tar_list meant to be the branch to use for querying pristine-tar?
<nacc> rbasak: just trying to understand the intended semantics of it
<rbasak> nacc: right - if pristine-tar ever grew that feature. Until then, the implementation needs to rename around
<nacc> rbasak: ok, but is the idea that the function will return *all* the pristine-tars? or just the ones for that branch (that is the caller will need to pass 'pkg/importer/ubuntu/pristine-tar' and 'pkg/importer/debian/pristine-tar'?
<rbasak> The latter
<nacc> rbasak: given you have a default value for branch_name, i'm not sure the intent
<nacc> got it
<rbasak> The default is only because that's pristine-tar's default so it follows logically.
<rbasak> Perhaps for us that's wrong though and we should have no default.
<rbasak> I'd never expect us to use it.
<nacc> yeah, i'd be more comfortable not using it (or not specifying it by default) and then handling the allow_override semantics as you listed
<nacc> that makes more immediate sense to me
<rbasak> OK
<rbasak> I'm fine with that
<rbasak> If I understand you correctly
<rbasak> I'm not sure I follow exactly
<nacc> basically, i think branch_name is meant to reflect, i want the pristine-tars from this branch. But given that 'pristine-tar' is sort of a reserved name, I'd rather we make that explicit in the caller and drop the default (i don't think we'd have any callers anyways  that don't pass branch_name)
<rbasak> Ah
<rbasak> Yeah that's fine
<nacc> rbasak: code will speak louder than words, I can implement it and you can review
<rbasak> OK thanks!
<nacc> rbasak: enjoy your w/e
<coreycb> hi all, could someone please reject my libvirt uploads for xenial and zesty? i have some changes to upload.
<coreycb> i've gone ahead and uploaded new versions of libvirt to xenial and zesty to the unapproved queues.  the older uploads of libvirt from 2017-06-27 are the ones that can be rejected.
#ubuntu-devel 2017-07-08
<Unit193> slangasek: Re: 1701746.  For some strange reason, I'm still able to log in as of today, and communicated with someone yesterday.  Zesty, both amd64/i386.  FWIW, seems vivid and precise are still listed as having it.
<Unit193> cjwatson: Hi, may I poke you about LP 1468476 and the possibility of getting the lp cache moved to under ~/.cache/ ?
<ubottu> Launchpad bug 1468476 in launchpadlib "$HOME/.launchpadlib the right place?" [Undecided,New] https://launchpad.net/bugs/1468476
<cjwatson> Unit193: I care less than zero about the XDG dotfiles religion
<cjwatson> if it's in place from the start, fine, whatever; but it's not worth the effort of moving stuff around and thus carrying extra code to handle the two locations, since extra code => extra bugs
<cjwatson> I'm not wontfixing it since somebody else might care enough to do it, but I won't contribute to it
<jbicha> if it's just cached data, maybe you don't need to worry about the old location?
<Unit193> OK, fwiw I was aiming for decluttering ~, not because "XDG said so!" :)
<cjwatson> jbicha: *shrug* I don't even want to have to spend any energy thinking about that for what I consider a non-goal
<cjwatson> Unit193: that does not interest me
<cjwatson> sorry
<Unit193> cjwatson: Sure, I really do appreciate the definite answer.
<cjwatson> I'm not totally convinced there aren't credentials cached in there in some modes - I might be wrong about that, but the code is quite twisty and it would take definite thought to establish whether that's the case or not
<cjwatson> (normally it'd use python-keyring, but there are several modes)
#ubuntu-devel 2017-07-09
<slangasek> Unit193: vivid and precise are both EOL, so I didn't bother to remove it from partner for those releases even though the archives are still open for each.  As for still being able to log in, hmm, I only know what willcooke told me as far as the EOLing
<Unit193> slangasek: I figured, wasn't sure if missed or not so mentioned it.  Yeah, it's very strange as I got an email from them and read a blog post of theirs, was fully expecting to no longer be able to login.
<Unit193> Mainly figured I'd mention it as you said not only would it not let you login, but also didn't launch.
<Unit193> slangasek: Do you know if you'll likely be able to get permission for the newer one?
<slangasek> Unit193: the "newer" one has been available for quite some time, and no sign yet
<Unit193> Yeah I saw the beta news, etc.  Just wondered if partner was going to get it.  Thanks for answering.
<cpaelzer> thanks for the hint on ./debian/git-cherry-pick xnox
<cpaelzer> xnox: I read that you just want "ids of the patches you are after; and series you want them in" - will let you know
<cpaelzer> xnox: I need to read through the bug updates (if any) in Debian/Ubuntu to see if there is more to do
<cpaelzer> xnox: I updated bug 1702823 accordingly
<ubottu> bug 1702823 in systemd (Debian) "Systemd fails to serialize tasks correctly on daemon-reload" [Unknown,Confirmed] https://launchpad.net/bugs/1702823
<aeoril> is there a community development effort on Ubuntu's side for Linux subsystem for Windows?
<xnox> aeoril, please explain what you mean?
<xnox> aeoril, Windows Subsystem for Linux (WSL) is a proprietary part of the Windows 10 kernel which allows executing linux elf binaries and provides a subset of compatibility syscalls to make elf binaries work.
<xnox> all of that work is done by Microsoft alone.
<aeoril> xnox: Oh, I thought it might be a joint effort between Canonical and Microsoft, and that there might be some work developers could do open source to contribute to it
<xnox> Ubuntu provides a tarball of Ubuntu chroot which is unmodified tarball as used for LXD/LXC etc and is from here: https://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64-root.tar.gz
<xnox> aeoril, that tarball is wrapped in a zip file, with a manifest file that says "ubuntu", and is registered with the WSL subsystem (literary one call to WSL api)
<xnox> the WSL apis are public in the latest insider builds of windows 10, not sure if the windows sdk with those dll/header files is out yet.
<xnox> aeoril, apart from wrapping existing chroot/tarball of the ubuntu container cloud image there was no futher work done by canonical. And none of the binaries are modified and/or recompiled at all - it really are just the same amd64 binaries as one executes on top of ubuntu kernel.
<aeoril> I see
<xnox> aeoril, there is community around WSL, which is mostly around testing various things one wants to run and reporting misbehaving syscalls / weirdness. https://github.com/Microsoft/BashOnWindows
<aeoril> xnox: thanks for that :)
<xnox> aeoril, with each update to insiders release there have been improvements in the windows kernel syscall faking thus more and more complex apps now work.
<xnox> aeoril, and the microsoft team working on this is active in gathering feedback via above project.
<aeoril> Do you know if Microsoft has any of their part open source?  I had heard something some while ago about Microsoft opening up parts of their OS development to open source developers
<aeoril> Not really sure about that
<xnox> aeoril, one could "fix" linux apps, by using fallbacks and/or lowering the syscall level that is required to run something. But that is not a long term solution and kind of not the point of WSL =) the idea is to have parity on windows side, rather than adding fallacks on the linux side.
<xnox> aeoril, i have no idea about that. Maybe use Microsoft developer forums / insiders community to ask about that. There are a lot of repositories at https://github.com/Microsoft and there is process around accepting external contributions e.g. for donet and the like. But I have not yet seen any more "core" services / subsystems / libc / kernel there.
<xnox> i guess some may class hacking on the next dotnet as os development.
<aeoril> xnox: thank you for getting me started on this.  You are very generous to help me with Microsoft OSS efforts, even though they do not really have much to do with Ubuntu OSS efforts.
<cpaelzer> We are over the millenium years - OSS spirit everywhere now
<cpaelzer> xnox: I see you updated the bug - let me know if you need anything else
<cpaelzer> xnox: otherwsie I'll wait to verify once the bug gets the usueal SRU update notice from moving to proposed
<xnox> there is currently inflight sru for xenial & yakkety.
<xnox> i will try to fix this in artful asap, and make the sru uploads into yakkety-zesty.
<xnox> i have networkd features to backport into xenial-yakkety-zesty as well.
<clivejo> how do I get uscan to repack and create a dfsg tarball?
#ubuntu-devel 2018-07-02
<xnox> infinity, smoser - please elleborate if I am dissolusioned about the btrfs-progs/tools bug.... i thought i went with smoser over this before, and it should be all fine with a (transitional-package -> provides), no?
<xnox> i don't believe i've done such a hack before, but i hoped it would be all fine like that.....
<ginggs> xnox: hi! i think there are some issues with boost and python3.7, did you see my message in #-release?
<ahasenack> hi guys,
<ahasenack> I see that ldb is in cosmic-proposed for quite some time
<ahasenack> I checked it out and all it needs is a samba rebuild
<ahasenack> I have a samba MP prepared to bump it to 4.8.2 (from 4.7.6), but I hit a regression in a test suite
<ahasenack> filed bug upstream and with debian, but can't tell when it will get some attention
<ahasenack> so if somebody could perhaps do a no-change rebuild/upload of cosmic's current samba, that should unblock libldb (which is a sync)
<ahasenack> better do that now than closer to the release I think
<ahasenack> upstream bug I opened: https://bugzilla.samba.org/show_bug.cgi?id=13486
<ubottu> bugzilla.samba.org bug 13486 in File services "CIFS guest connection can't read back file it just created in mode 0600" [Normal,New]
<ahasenack> debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902431
<ubottu> Debian bug 902431 in samba "samba: cifs guest connection can't read back 0600 file it just created" [Normal,Open]
<ahasenack> I also emailed samba@
<ahasenack> but no thread ensued
<ahasenack> this is one of the failing tests: https://git.launchpad.net/qa-regression-testing/tree/scripts/test-samba.py#n763
<ahasenack> it fails at https://git.launchpad.net/qa-regression-testing/tree/scripts/test-samba.py#n785 (when trying to write to the mkstemp file that was just created)
<lubuntuuser> anyone knows the command-line name for TUI installer?
<dmj_s76> Trevinho: Any chance to get the fix to https://bugzilla.gnome.org/show_bug.cgi?id=786929 backported for 18.04?
<ubottu> Gnome bug 786929 in general "Attaching a monitor to laptop while in suspend and then waking up laptop will reliably crash gnome-shell" [Major,Resolved: fixed]
<Trevinho> dmj_s76: would love to, althoug there's a bit of changes in mutter and g-s too, so I'd prefer to stay a bit on master then we'll backport to gnome-3-28 branch and thus we'll pick it from there
<dmj_s76> Thanks, want to make sure suspend works reliably for users :)
<Trevinho> I agree
<cybernout> does any one here know the command ( bash ) , that would do the same thing as , the "Clear All" on 18.04  messages tray : https://i.stack.imgur.com/VlcPe.png
<nacc> cybernout: i'm not sure there is necessarily anything exposed for that
<nacc> cybernout: you may want to ask #gnome?
<cybernout> thought ubuntu is using a modified version.. and not the default gnome one
<cybernout> but ok , i will try there ;)
<cybernout> by the way, there seems to be no limit the the messages that can get there, after a while it gets really clutterd
<cybernout> in that way its an ubuntu problem as well
<cjwatson> Generally when people ask you to talk to upstream they aren't denying that it's an Ubuntu problem too, just saying where the most effective place to solve the problem would be
<cybernout> no problem, i understand ..
<nacc> cybernout: what cjwatson said; i mean, yes, ubuntu is a downstream of gnome, but i'd imagine if there is a cli version of that tool, #gnome would know immediately :)
<cybernout> trying to write a wrapper to avoid problem, thanks for the feedback
<nacc> cybernout: why is that a problem, btw? If you don't acknowledge the messages there ...
<cybernout> public space computer, after a day running its eating resources
<nacc> cybernout: oh i see, if it's public, why even have the notification tray?
<nacc> i wonder if it's disable-able (maybe with tweaks, etc.)
<nacc> cybernout: but, tbh, i think you want #ubuntu at this point :)
<nacc> cybernout: or #gnome, as i mentioned
<cybernout> moving from 16.04 to 18.04 created some problems with lockdown scripts that also used desktop notifications to inform user about usage , any way thanks..
<cybernout> bye and keep up the good work
 * cybernout afk
<ahasenack> it looks like for exim4 debian only maintains the debian/ directory in git: https://salsa.debian.org/exim-team/exim4
<ahasenack> is that something each team decides, and how does one build a source package from that usually?
<ahasenack> I'm assuming scripts or tools exist, otherwise I'll just do it manually
<ahasenack> my motive is pushing an ubuntu delta up to debian, I want to make an MP there, but it's the first time I see this structure
<ahasenack> (in salsa)
<xnox> ahasenack, debuild can build that
<ahasenack> xnox: just plain debuild in that git checkout that only has debian/ ?
<xnox> ahasenack, it prints many warnings "ignoring deletion of <every single upstream file>" but otherwise it is fine.
<xnox> ahasenack, yes.
 * ahasenack tries
<xnox> ahasenack, one needs orig tarball in ../ e.g. with pull-debian-source -d exim4 for example
<ahasenack> yep
<xnox> and well, build a source package $ debuild -S, obviously =) it will fail to build binaries ;-)
<xnox> or like unpack tarball and move in '.git' and $ git checkout debian/
<ahasenack> xnox: worked, thanks
<infinity> xnox: Oh, I didn't notice the provides.  It's still generally not good practice to depend on a virtual instead of a real package, mind you, but you're right that the provides makes removal less dire.
<xnox> infinity, it will be easier once all the things with old name are dead =/
<xnox> infinity, if it makes things happier, we can change the dep in curtin; but the installer code will continue to install the old (virtual) package name
<xnox> (installer code inside curtin that is)
#ubuntu-devel 2018-07-03
<seb128> slangasek, who would be the right person to review https://code.launchpad.net/~cjwatson/livecd-rootfs/drop-lp-hostname-filtering/+merge/347962 ? that seems trivial and it sitting in the sponsoring queue (which I'm trying to clean up a bit)
<seb128> bdmurray, hey, could you have a look to https://code.launchpad.net/~azzar1/software-properties/fix-1768797/+merge/348460 ?
<bdrung_work> xnox, hi. can you help me debugging #1779721?
<xnox> bdrung_work, hey, sure.
<xnox> bug #1779721
<ubottu> bug 1779721 in systemd (Ubuntu) "systemd-networkd does not configure DHCPv4" [Critical,New] https://launchpad.net/bugs/1779721
<bdrung_work> what commands to i need for wireshark?
<xnox> bdrung_work, let me create a command line locally that should capture things and paste it to you.
<xnox> bdrung_work, $ sudo tshark -i eth0 -w /tmp/dhclient.pcap
<xnox> bdrung_work, install tshark first.
<xnox> that will capture all the traffic on the interface, then you can view that file with GUI wireshark, and filter on DHCP things
<xnox> digging into debug options of the systemd debug client
<xnox> ...
<xnox> for systemd-networkd debug
<xnox> $ systemctl stop systemd-networkd
<xnox> $ sudo SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd
<xnox> possibly you want to grep for DHCP
<xnox> DHCP CLIENT (0x58807593): OFFER
<xnox> DHCP CLIENT (0x58807593): REQUEST (requesting)
<xnox> DHCP CLIENT (0x58807593): ACK
<xnox> DHCP CLIENT (0x58807593): lease expires in 59min 57s
<xnox> DHCP CLIENT (0x58807593): T2 expires in 52min 28s
<xnox> DHCP CLIENT (0x58807593): T1 expires in 29min 57s
<xnox> and the like.
<xnox> bdrung_work, is that enough or no?
<xnox> (sorry for the delay)
<bdrung_work> SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd shows that the client complains
<bdrung_work> xnox, "received lease lacks address, server address or lease lifetime, ignoring"
<xnox> bdrung_work, paste all that into the bug report.
<xnox> bdrung_work, ideally i want the dhclient packet capture / lease too.
<xnox> bdrung_work, it is possible that we fail to support fixed-address 87.106.172.36;
<xnox> bdrung_work, it would be nice to find the config if this dhcp server; for me to reproduce everything locally and contribute an upstream test case.....
<bdrung_work> that is not a normal dhcp server, so you have to construct the config yourself
<bdrung_work> i tried "sudo env SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd 2>&1 | tee log" to capture the output, but it does not output anything
<xnox> bdrung_work, yeah, it's weird.
<xnox> bdrung_work, as if it detects pipe, and stops printing anything
<xnox> bdrung_work, it smells like a networkd bug, because there is address; there is server_address... and the lifetime stuff it calculates itself, and probably badly.
<xnox> i see no dhcp-renewal-time and dhcp-rebinding-time provided by the dhcp server; i wonder if that's what is confusing networkd ehre.
<bdrung_work> xnox, attached full log output and pcap file to bug report
<xnox> bdrung_work, awesome thanks!
<bdrung_work> xnox, i will be on vacation tomorrow. is there something that i could do before?
<xnox> bdrung_work, next steps for me; is to recreate a dnsmasq config that would generate leases similar to your one; until networkd crashes; fix networkd; provide you with a test ppa to validate.
<xnox> bdrung_work, i think you are good. hopefully this week, as i'm off next week myself.
<bdrung_work> okay. so i can hopefully test the fix after my vacation
<guest1524> where can i find the build logs for a specific package in bionic?
<bdrung_work> guest1524, go to https://launchpad.net/ubuntu/+source/$source_package
<bdrung_work> guest1524, e.g. https://launchpad.net/ubuntu/+source/distro-info-data and click on the version, then there are the builds log (e.g. https://launchpad.net/ubuntu/+source/distro-info-data/0.38/+build/14860865)
<guest1524> thank you very much bdrung_work!
<slangasek> seb128: https://code.launchpad.net/~cjwatson/livecd-rootfs/drop-lp-hostname-filtering/+merge/347962 merged
<cjwatson> thanks
<bdmurray> Has anybody seen something like bug 1779827?
<ubottu> bug 1779827 in Ubuntu "Started gnome display manager. dispatcher service" [Undecided,Confirmed] https://launchpad.net/bugs/1779827
<bdmurray> seems like a regression in bionic-updates
<seb128> slangasek, thanks for the livecd-rootfs merge :)
<seb128> bdmurray, what makes you think it's a regression? I don't think it's known by us (desktop) at least
<bdmurray> seb128: the fact that multiple people said it happened after a kernel update
<seb128> video driver issue?
<bdmurray> I asked as I was curious if there were any other reports of issues with the new kernel. jsalisbury is looking into the specific bug now though.
<slangasek> stgraber: are you chairing TB meeting today?
#ubuntu-devel 2018-07-04
<jamespage> doko: async being invalid syntax for an argument name with python 3.7 is biting us a bit
<jamespage> doko: do we have a cosmic rebuilt test that covers that yet?
<jamespage> i.e. with py 37 as part of python3-all
<doko> jamespage: no. so for now it's tracking upstream for these patches
<rbasak> nghttp2 is stuck in proposed. Valid candidate. update_output.txt reports: "* armhf: nghttp2-client, nghttp2-proxy, nghttp2-server". apt-get seems happy with each of those individually in an armhf cosmic-proposed chdist. Does it need hinting through?
<rbasak> Ah, it's tied to jemalloc.
<rbasak> Which I think is blocked on a bunch of other things on armhf.
<rbasak> Still, I think some attention might be needed to get jemalloc through
<Laney> Yep. jemalloc.
<danialbehzadi> Is there a problem with launchpad?
<danialbehzadi> my builds got fail with weird logs:
<danialbehzadi> https://launchpadlibrarian.net/377127491/buildlog.txt.gz
<danialbehzadi> And that happen only for artful and bionic. Cosmic is fine: https://code.launchpad.net/~dani.behzi/+recipe/traktor
<rbasak> ahasenack: so in your opinion bug 1766186 is ready for release to both Xenial and Artful?
<ubottu> bug 1766186 in apache2 (Ubuntu Artful) "IncludeOptional fails when a directory does not exist" [Low,Fix committed] https://launchpad.net/bugs/1766186
<ahasenack> rbasak: yes,and for the remaining (single) test failure, which is valid, I have an MP and associated sru bug
<rbasak> OK thanks
<ahasenack> and I have a run that it passes with my fix
<ahasenack> showing that*
<rbasak> jbicha: any opinion on bug 1778782 please? I'm not particularly familiar with ostree/flatpak from an SRU review perspective, and would appreciate your input.
<ubottu> bug 1778782 in ostree (Ubuntu Bionic) "[SRU] New upstream microrelease ostree 2018.6" [Low,In progress] https://launchpad.net/bugs/1778782
<rbasak> seb128: still around? On bug 1762595. The Cosmic fixed hasn't migrated yet. Not a problem for an SRU in itself, but the version in the Cosmic release pocket is still 1.36.1-0ubuntu1. If the version in proposed gets deleted, that would cause a problem.
<ubottu> bug 1762595 in gvfs (Ubuntu Cosmic) "Thunar incorrectly thinks USB storage device hasn't finished ejecting" [High,Fix committed] https://launchpad.net/bugs/1762595
<rbasak> I've not hit this case before. Not sure what to suggest.
<rbasak> Anyone have an opinion on how to handle this or whether we need to care? ^
<Laney> rbasak: gstreamer was/is in this case, and it was accepted to -proposed without any trouble. There was some debate as to whether it should be released to -updates while it wasn't in cosmic-release, but eventually it was.
<Laney> Agreed that it's easy to lose track of uploads in such a situation though.
<Laney> I have an SQL query in my UDD history that finds uploads where stable > dev, but it's not really surfaced anywhere.
<Laney> s/really //
<rbasak> Thanks.
<rbasak> We probably don't want to block SRUs for this in the general case.
<rbasak> But I'd like another SRU member +1 before accepting I think, seeing as I'm still quite new.
<Laney> https://paste.ubuntu.com/p/G6WMZqTMHD/
<Laney> that's bionic{-updates} > cosmic
<Laney> Most of them have an upload in -proposed, but not e.g. swauth
<seb128> rbasak, oh ok, thanks for letting me know but I don't think there is much I can do. I understand if you skip it, let's just hope that the cosmic version doesn't get stucked for too long and make us risk missing bionic .1
<mr_lou> Can someone tell me a fix for getting Ubuntu to detect my burner again?
<wxl> mr_lou: #ubuntu for support
<mr_lou> wxl, Well I asked there too, but last time I had the same problem, they referred me to this channel, which makes sense since it's obviously a bug that was introduced very recently.
<wxl> mr_lou: i'd start there, at least
<mr_lou> I had the same problem when kernel 4.4.0-98 came. But I could solve it back then by booting an earlier kernel, like 4.4.0-97.
<mr_lou> Can't do that anymore. No matter which kernel I boot on, my burner just isn't detected. :-(
<rbasak> seb128: I certainly think it's wrong for us to block Bionic over this. I just want to make sure that there isn't some other solution that is preferable.
#ubuntu-devel 2018-07-05
<jbicha> rbasak: I don't think I have anything additional to add for the ostree SRU bug. I know that Ken wanted to see flatpak 1.0 get into Ubuntu 18.04 LTS archives after it's released
<sil2100> rbasak: hey! The letsencrypt xenial SRU is stalled since over 300 days now, with some build failures blocking it (+ lack of verification)
<sil2100> rbasak: LP: #1640978
<ubottu> Launchpad bug 1640978 in python-certbot-nginx (Ubuntu Zesty) "[SRU] Backport letsencrypt 0.14.2" [Undecided,Fix committed] https://launchpad.net/bugs/1640978
<sil2100> rbasak: that's a lot of packages that would be a waste to just remove, but if no movement happens in this area I'll have to do that
<sil2100> rbasak: the developer raised concerns that the update is still needed, so that would be a shame
<xubuntu000> hey all. pulseaudio 12 has been available for several weeks now and it has some much needed patches
<xubuntu000> currently the most up to date pulse in repos is 11.1
<mdeslaur> xubuntu000: 12.0 is in cosmic-proposed
<xubuntu000> oh nice!
<xubuntu000> wow, as of yesterday even
<xubuntu000> thanks mdeslaur! you're awesome
<doko> bdmurray: are you currently the one looking at apport? seeing failing autopkg tests on amd64
<bdmurray> doko: I'll have a look today
<doko> ta
<bdmurray> jibel: Could you elaborate on how you recreated bug 1778817?
<ubottu> bug 1778817 in ubuntu-release-upgrader (Ubuntu Bionic) "release upgrade from xenial to bionic desktop: screen locks itself, password to unlock fails" [Critical,Triaged] https://launchpad.net/bugs/1778817
<jibel> bdmurray, I installed 17.10, set the screen lock timeout to 1 min, upgrade to 18.04 with the GUI, and the screen lock goes off before the inhibit command is issued.
<bdmurray> jibel: ah so, maybe setting it to 1 minute is the issue?
<bdmurray> slangasek: Do you know what period you had for the lock timeout?
<jibel> bdmurray, I don't think 1min is the issue, the issue is that the screen can lock between the moment the user proceeds with the upgrade and cannot cancel anymore and the moment the inhibit command is executed
<jibel> bdmurray, why not disabling the screen lock earlier?
<bdmurray> jibel: I'll have a look at where we can move it.
<slangasek> bdmurray: no, I don't know what the interval was, I could look that up with effort.  but as jibel says, ordering should be that the lock inhibition should take place before the user hits the button, not after
<bdmurray> Yeah, before they click "upgrade"
<tsimonq2> rbasak: Yesterday I implemented the mirroring of those imported USD repositories, and I was wondering... what's the difference between use of the <usd-importer-do-not-mail@canonical.com> email address and <ubuntu-server@lists.ubuntu.com> wrt the importer?
<rbasak> tsimonq2: I'm not sure we've pinned down the spec wrt. the addresses used. Where are you seeing each case?
<tsimonq2> rbasak: See https://phab.lubuntu.me/source/quassel-archive/history/debian%252Fjessie/ and https://phab.lubuntu.me/source/quassel-archive/history/importer%252Fdebian%252Fdsc/ (hovering over the name in each commit displays the email address).
<tsimonq2> rbasak: One is usd-importer and one is Ubuntu Git Importer.
<rbasak> tsimonq2: it might have been changed but those repositories not yet reimported
<rbasak> Or it could be that the dsc branch does it differently
<rbasak> tsimonq2: it's bug 1728685
<ubottu> bug 1728685 in usd-importer "Commit message format is not finalized" [Undecided,Triaged] https://launchpad.net/bugs/1728685
<rbasak> tsimonq2: we'll specify it, add tests to make sure the spec is followed. Before we reimport the world and leave experimental status.
<tsimonq2> rbasak: Gotcha.
<rbasak> The dsc and pristine-tar branches are a bit special mind. Really they contain data rather than commits. We might not force them a particular way and rely on the person running the importer's settings.
<nacc> right, in one case, the authoer and commitere are distinct, in the meta-branches, they are not
<tsimonq2> OK, thanks.
<nacc> tsimonq2: it's definitely a bug that they are different, and it will presumably be fixed by the above :)
<tsimonq2> nacc: Great. :)
#ubuntu-devel 2018-07-06
<rbasak> slangasek: I've been asked to look at the MAAS SRUs in the queue. What's the status of the MAAS SRU exception please? Is it approved? I found https://wiki.ubuntu.com/MAASUpdates but it doesn't seem to be endorsed or linked from https://wiki.ubuntu.com/StableReleaseUpdates
<rbasak> (I'm aware I could review, negotiate and approve myself, but I'd prefer to go with whatever is already being done rather than do it all again)
<slangasek> rbasak: correct, it has not been signed off on as a standing exception.  infinity has the ball on getting that done.  SRU Team always has the authority to make one-off exceptions, the standing exception just saves us time and avoids inconsistent handling
<slangasek> rbasak: that wiki page is not approved, but I'd say it's getting close, so maybe you want to review it yourself by way of assessing the SRU
<rbasak> OK
<rbasak> THanks
<tsimonq2> rbasak: How often do Git imports run?
<tsimonq2> (I'm asusming it's in a cronjob, right?)
<tsimonq2> *assuming
<rbasak> tsimonq2: there's a "daemon" that watches Launchpad publications
<rbasak> It's not currently very smart. In theory it should pick up on things in thirty minutes. In reality an actual import could take longer if it falls behind (eg. a large number of new publications). Right now it's recovering from an outage.
<tsimonq2> rbasak: Ah.
<tsimonq2> Thanks.
<andersk> I feel like there ought to be an automated check for version monotonicity across Ubuntu releases.  Having just written a script for this, I found:
<andersk> Older in trusty than precise: language-pack-hne language-pack-hne-base language-pack-hsb language-pack-hsb-base language-pack-ss language-pack-ss-base
<andersk> Older in xenial than trusty: dh-golang
<andersk> Older in artful than xenial: fuse-umfuse-ext2 libclc libdrm mesa patch python-pyvmomi snapcraft wireless-regdb
<andersk> Older in bionic than xenial: fuse-umfuse-ext2 linux-meta-azure mesa nvidia-graphics-drivers-384
<andersk> Older in bionic than artful: libvorbisidec nvidia-graphics-drivers-384
<andersk> Older in cosmic than bionic: firefox gnupg2 gst-plugins-bad1.0 gstreamer-vaapi imagemagick libarchive-zip-perl linux linux-meta-raspi2 linux-raspi2 linux-signed llvm-defaults perl php7.2 snapcraft swauth thunderbird
<andersk> The mesa discrepancy in particular seems to be interfering with upgrades on a machine with both xenial and bionic sources, and Iâd guess it might be causing upgrades to fail.
<Unit193> andersk: Every upgrade I end up with local packages because people can't keep the upgrade path intact, and while I wouldn't mind that in PPA's so much I do mind in the official Ubuntu archive.
<Unit193> andersk: I must ask though, what script did you write for this?
<Unit193> https://loki.unit193.net/test_versions.py is mine, but it's designed for other uses not specifically testing upgrade paths.
<andersk> Itâs a similar quick Python script: https://gist.github.com/andersk/72bf1e03fb5c8fff0b13e3dc497d85cd
<Unit193> Neat.
<LocutusOfBorg> tyhicks, hello, can we please have fscrypt merged / synced from Debian?
<LocutusOfBorg> maybe the new version fixes the testsuite
<LocutusOfBorg> (yes, it should fix it)
<xnox> doko, because boost upstream changed how they abi tag python-like libraries, i doubt anything in debian/ubuntu will know how to actually build against both 36 and 37 variants of the libs.
<xnox> doko, thus when i come back, i will work on fixing all of those.
<xnox> doko, as part of the 1.67 transition
<xnox> doko, it's in NEW queue for both ubuntu & debian.
<xnox> doko, (just the boost1.67, not the update to the defaults yet)
<tyhicks> LocutusOfBorg: hey - thanks for the ping - it looks like a merge and possibly a sync is possible
<tyhicks> general question for #ubuntu-devel... the fscrypt package that I uploaded directly to bionic (and that cosmic inherited) built the golang-github-google-fscrypt-dev binary package which is the source tree of the fscrypt project (many go package seem to do this)
<tyhicks> Debian fscrypt source package comments out that binary package from the control file: https://salsa.debian.org/go-team/packages/fscrypt/blob/debian/sid/debian/control#L57
<tyhicks> I'd like to simply sync the package from Debian but anyone with that package installed will be left with the old version
<tyhicks> I don't think that's a problem, especially considering what the binary package is, but can someone confirm that we can just not build that binary package in cosmic without any problem?
<mdeslaur> tyhicks: just make sure there are no reverse depends on it, then you can drop it, yes
<tyhicks> mdeslaur: ah, I hadn't thought about that (shouldn't be in this case but I'll make sure)
<tyhicks> thanks!
<mdeslaur> np
<mdeslaur> and reverse-build-depends
 * tyhicks nods
<tyhicks> all good
<ahasenack> doko: hi, what was that sssd /usr/local change? It is failing to build now: https://launchpadlibrarian.net/377463205/buildlog_ubuntu-cosmic-amd64.sssd_1.16.1-1ubuntu4~ppa1_BUILDING.txt.gz
<ahasenack> the change: https://launchpadlibrarian.net/370383936/sssd_1.16.1-1ubuntu2_1.16.1-1ubuntu3.diff.gz
<ahasenack> it's also adding an init file, not mentioned in the changelog
<Snow-Man> anyone know how to get at the unix username of the user building the package inside debian/rules..?
<elmo> Snow-Man: ... whoami ?
<Snow-Man> tried that
<Snow-Man> more specifically: "export USER=$(whoami)" at the beginning of debian/rules
<elmo> OK?
<Snow-Man> well, it didn't work..
<elmo> as in $USER is empty or wrong or what?
<Snow-Man> $(USER) ends up being empty
<Snow-Man> $USER just gives SER
<Snow-Man> specifically trying to fix this: https://buildd.debian.org/status/package.php?p=pgbackrest
<Snow-Man> essentially need to do: `sed -i 's/vagrant/$USER/g' /backrest/doc/resource/exe.cache`
<Snow-Man> also tried $(LOGNAME) but no joy there
<elmo> Snow-Man: it's been a while since I did make files, but don't you need it to write it as $$USER  ?
<Snow-Man> elmo: thought $(USER) would work (have been trying both $USER and $(USER)...), but lemme try $$USER...
<Snow-Man> ended up having to use $$(whoami), but that worked!  thanks much elmo!
<elmo> Snow-Man: no worries
<cjwatson> Snow-Man: $(USER) would work if it were a make variable rather than a shell variable, in which case it would need to be assigned using $(shell whoami) rather than just $(whoami).  FWIW
<cjwatson> Snow-Man: $USER works because it's pre-set in the build environment, which isn't a particularly robust assumption to make
<cjwatson> $$USER rather
<cjwatson> $$(whoami) seems like a reasonable approach though and is probably what I'd do if there's only one occurrence
<Snow-Man> yea, this is temporary
<Snow-Man> and there's only one case of it
<Snow-Man> We should be able to eliminate the need for it in the next version
<cjwatson> ack
#ubuntu-devel 2018-07-07
<doko> ahasenack: the /usr/local change can be reverted. it was a premature change in the python packaging. I'm not aware of the init file
<sladen> \
<no_gravity> Hello! I see that Ubuntu is based on Debian unstable. Does that mean 18.04 is a snapshot of a certain point in time of Debian unstable?
<Faux> It's closer to "everything that was building and passing tests before some point in time", not an actual snapshot.
<pavlushka> I need some help on dpkg-buildpackage issue, https://pastebin.com/jMkkFAdZ
#ubuntu-devel 2018-07-08
<tsimonq2> rbasak, nacc: Hm, is the importer still not back up?
<tsimonq2> This was uploaded two days ago and still isn't imported: https://launchpad.net/ubuntu/+source/nm-tray/0.4.0-0ubuntu1
<rbasak> tsimonq2: I think it might not be active with the latest whitelist yet, sorry.
<rbasak> I've been caught up with a bunch of CI failures.
<rbasak> My next step (yet to be done) is to bring the importer and snap store live with a newer build, which we finally have.
<zhsj> hi, where can I send request to remove my package synced from debian today, it simply doesn't work. It depends lxc 2, I though I set strict build-depends, but not. lxc version between ubuntu and debian are not aligned
<zhsj> it's anbox, https://launchpad.net/ubuntu/+source/anbox
<tsimonq2> rbasak: ACK, thanks.
<tsimonq2> zhsj: Please file a bug and subscribe ~ubuntu-archive.
<tsimonq2> (Optionally, link it in #ubuntu-release.)
<zhsj> tsimonq2: ta
<nacc> tsimonq2: sorry, rbasak is the one who would know about it now (and looks like you got the answer)
#ubuntu-devel 2019-07-01
<ahasenack> xnox: I got two +1s in https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1833039
<ubottu> Launchpad bug 1833039 in apache2 (Ubuntu Cosmic) "18.04/Apache2: rejecting client initiated renegotiation due to openssl 1.1.1" [Undecided,Confirmed]
<ahasenack> xnox: I'll prepare the sru
<ahasenack> I used https://git.launchpad.net/~ahasenack/ubuntu/+source/apache2/tree/debian/patches/disable-ssl-1.1.1-auto-retry.patch?h=bionic-client-cert-auth-fix
<ahasenack> just the first hunk of that upstream commit. The other bit is for tls v1.3 from what I could tell, which is not enabled in that apache version
<xnox> nice
<xnox> mvo:  do you have the power to approve subiquity.pot on https://translations.launchpad.net/ubuntu/+imports?field.filter_extension=pot&field.filter_status=NEEDS_REVIEW&batch=75&direction=backwards&memo=2400&start=2325 ?
<mvo> xnox: let me look
<xnox> i think ~katie can, and i guess the launchpad translator admins....
<xnox> mvo:  if you can't, i might need to invoke c j watson
<mvo> xnox: I just checked, I can't
<cjwatson> mvo: I'm pretty terrible with the translations app, but I think I've managed to do it
<mvo> xnox: -^
<sil2100> !dmb-ping
<ubottu> cyphermox, jbicha, micahg, rbasak, sil2100, slashd, tsimonq2: DMB ping.
<xnox> mvo:  cjwatson: thanks! it looks like it worked, because https://translations.launchpad.net/ubuntu/+source/subiquity now looks populated
<mitya57> infinity, doko: I get this error on arm64 and armhf when building qtquickcontrols-opensource-src in https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3709/+packages:
<mitya57> /usr/bin/ld: error: /usr/lib/gcc/aarch64-linux-gnu/8/../../../aarch64-linux-gnu/crti.o(.plt) section size (0xf20 bytes) is larger than file size (0x5a0 bytes)
<mitya57> Is it a bug in glibc?
<mitya57> Oh, now happens with qtwebengine too, with a different file name:
<mitya57> /usr/bin/ld: error: /usr/lib/gcc/aarch64-linux-gnu/8/../../../aarch64-linux-gnu/Scrt1.o(.plt) section size (0xa40 bytes) is larger than file size (0x6a8 bytes)
<mitya57> Did not happen on Friday 2019-06-28, so something recent broke it.
 * mitya57 blames today's binutils upload
<doko> mitya57: no, most likely https://sourceware.org/ml/binutils/2019-07/msg00019.html
<ubottu> sourceware.org bug 2019 in kprobes "Race in recovery of recursive probes" [Normal,Resolved: fixed]
<mitya57> doko: so ânoâ to my first guess (bug in glibc) but âyesâ to my second guess (blaming today's binutils upload), right?
<doko> yes, likely
<seb128> mitya57, thx for mentioning it, I had a similar error in activity-log-manager today and was wondering what it could be
<seb128> oh, and gnome-calendar is the same
<seb128> so looks like any armhf build?
<seb128> doko, should we remove the binutils from eoan-proposed meanwhile to unscrew archive builds?
<doko> seb128: if you remove all depending builds as well, sure
<seb128> why would that be needed?
<seb128> diff is missing on https://launchpad.net/ubuntu/+source/binutils/2.32.51.20190701-1ubuntu1 :-/
<seb128> doko, so what do you suggest doing? we should at least sent a fyi email to the mailing list so others don't waste time trying to understand what's going on
<doko> uploading a fixed binutils
<mitya57> By the way Debian experimental is affected too.
<vorlon> doko: does that mean you are suggesting someone else upload a fixed one, or are you saying that you are uploading a fixed one?
<doko> I am currently building
<seb128> doko, thx
<vorlon> doko: whoopsie still FTBFS w/ binutils 2.32.51.20190701-1ubuntu2
#ubuntu-devel 2019-07-02
<mitya57> Yeah, this is still failing too: https://launchpadlibrarian.net/431428141/buildlog_ubuntu-eoan-arm64.qtquickcontrols-opensource-src_5.12.4-1_BUILDING.txt.gz
<doko> yes, this was not the correct reversion
<seb128> doko, I guess you know that but it looks like your binutils revert/fix didn't fix armhf builds
<doko> well, you could read 10 lines above
<seb128> doko, I close IRC at night so no
<LocutusOfBorg> doko, is PR 24708 not enough than to fix the issue? can't we just ignore the change in bfd/compress.c?
<doko> I have the fix, the build needs finishing ...
<cpaelzer> doko: I'm looking at an odd case (FTBFS) where "-Xlinker --disable-new-dtags" fixes the issue
<cpaelzer> but I'd want to get rid of our Delta and therefore better understand
<LocutusOfBorg> thanks nice
<cpaelzer> the code has plenty of test binaries, and all work as-is except one needing that config tweak
<LocutusOfBorg> I have a bunch of stuff in debian uploaded today
<cpaelzer> I checked readelf and ldd - the bad binary really can't resolve its lib, but I fail to see why - are there any common places that would be good to check next?
<LocutusOfBorg> with the freeze for unstable finished... people are uploading so much
<cpaelzer> doko: here some notes that I've taken so far http://paste.ubuntu.com/p/dGQ9yhWk2y/
<cpaelzer> doko: I have found that it was an effect of our as-needed default; the test has no dependencies on its own, but depends on a local lib that then needs libnspr4
<cpaelzer> thier rpath magic  to resolve that for the tests doesn't work for the "second tier" on ldd/ld.so
<cpaelzer> BTW that is bug 925790 that you auto-opened for ggc-9 - I added details there
<ubottu> bug 925790 in OpenStack Core Infrastructure "template-gerrit-git-prep sometimes suffers from spurious rpc failure" [High,Fix released] https://launchpad.net/bugs/925790
<cpaelzer> hrml bot - debian bug please
<Unit193> Debian 925790
<ubottu> Debian bug 925790 in src:nspr "nspr: ftbfs with GCC-9" [Normal,Open] http://bugs.debian.org/925790
<rbasak> If a package depends on a virtual package as a _first_ alternative, how does apt behave? I'm not sure how to find such an example in the archive easily for a quick test, so hoping someone will know without me having to construct an example. I know that usually we'll specify a non-virtual package as a first alternative to define the default.
<rbasak> But I'm doing some analysis of the archive so I want to cover that case in case someone has done it.
<rbasak> Will apt pick an artibrary package to fulfil the virtual dependency or will it prompt the user?
<seb128> there is no such prompting existing in apt afaik, it just picks one iirc
<seb128> but juliank would probably reply better to that
<juliank> we maximize (Multi-Arch: same, installed, same name [real package], essential, xb-important, native, priority, -order in the cache)
<juliank> (in current apt, older versions might be different)
<rbasak> seb128: juliank: thanks - that's useful
<juliank> to be more clear, the multi-arch same thing prefers a multi-arch: same package if its already installed for another architecture
<juliank> So given a Depends foo with providers foo1, foo2:foreign, foo2:same, foo
<juliank> If you have foo2:foreign installed, it picks foo2:same (well, let's assume foo2:same is realyl the only provider...)
<juliank> If you have foo1 installed, it picks foo1
<juliank> If neither foo1, foo2* are installed, foo will be installed because it has the same name :)
<juliank> This is the comparison operator for two providers: https://salsa.debian.org/apt-team/apt/blob/master/apt-pkg/depcache.cc#L986
<juliank> oh nice, in case of multiple foreign architectures it prefers them in the order they are configured
<doko> apw, infinity: how do we go forward with the glibc autopkg test regressions? do you agree this is a kernel issue?  Asking because we probably will get into some trouble when changing the GCC default next week or so, and the packages are not migrating
<LocutusOfBorg> can anybody please set this bug to verification-done? https://bugs.launchpad.net/ubuntu/+source/youtube-dl/+bug/1831778
<ubottu> Launchpad bug 1831778 in youtube-dl (Ubuntu Disco) ""token" parameter not in video info for unknown reason" [Undecided,Fix committed]
<LocutusOfBorg> looks like I cant
<LocutusOfBorg> somewhat I could, but they got deleted
<LocutusOfBorg> meh
<seb128> LocutusOfBorg, I've hitting launchpad timeouts so maybe the same issue?
<seb128> try again, edits worked now for me
<seb128> launchpad is quite timeout-y nowadays sadly
<LocutusOfBorg> seb128, yes, that was exactly my issue
<LocutusOfBorg> I could change all of them at the end
<LocutusOfBorg> after many attempts
<seb128> good :)
<LocutusOfBorg> doko, I didn't say anything, but you might be good to upload in unstable now
<LocutusOfBorg> because we are in deep freeze, this means every unblock should now come from proposed-updates
<LocutusOfBorg> (sorry for ECHAN)
<cjwatson> Yeah I really must sort out the DB triggers refactor (i.e. first take like a day to understand the current triggers ...)
<tomreyn> https://wiki.ubuntu.com/ReleaseSchedule needs an update - should i?
<tomreyn> (current should point to) https://wiki.ubuntu.com/EoanErmine/ReleaseSchedule
<Laney> tomreyn: go for it
<tsimonq2> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots: tsimonq2
<tsimonq2> o/
<tsimonq2> â
<tomreyn> Thanks, Laney. I tried to clean it up, too. https://wiki.ubuntu.com/ReleaseSchedule?action=diff&rev1=48&rev2=49
<Eickmeyer> tsimonq2: pulseeffects requires lsp-plugins, not in debian. You can upload my package in https://launchpad.net/lsp-plugins to debian if you want to get that dependency.
<tsimonq2> Eickmeyer: My second point still applies, it is in a PPA somewhere that I can grab and inspect?
<Eickmeyer> tsimonq2: https://launchpad.net/~mikhailnov/+archive/ubuntu/pulseeffects
<Eickmeyer> Took me 10 seconds to find it.
<tsimonq2> Eickmeyer: Didn't the author say the PPA version is different from what should be uploaded?
<tsimonq2> Right, the versions aren't appropriate for upload.
<tsimonq2> The discrepancies between his versions and what should be uploaded need to be addressed.
<Eickmeyer> tsimonq2: it's already addressed on his github.
<tsimonq2> Eickmeyer: So you'll upload that to a PPA? ;)
<Eickmeyer> tsimonq2: He was supposed to do that. I was just trying to get the ball rolling.
<tsimonq2> Eickmeyer: Fair enough.
<Eickmeyer> tsimonq2: The only discrepencies deal with lintian warnings which are eliminated with the version on github.
<tsimonq2> Eickmeyer: ack
<Eickmeyer> tsimonq2: My point was you're not going to get it into Debian without lsp-plugins.
<tsimonq2> Eickmeyer: Wanna do both?
<Eickmeyer> tsimonq2: I suppose I could. I need to get my salsa account fully set-up, and then Ross was going to add me to the Debian Multimedia team, but I've been sidetracked.
<tsimonq2> Eickmeyer: I'm also a member of the Debian Multimedia Team, I don't know if I can add you though.
<Eickmeyer> Ross is, unfortunately, on vacation for the next 4 weeks and incommunicado.
<tsimonq2> Create a Salsa account and we'll see.
<tsimonq2> If I can add you, I will.
<tsimonq2> Perhaps you've forgotten that I am also a Debian Developer. :)
<Eickmeyer> tsimonq2: No, I haven't, but you've been quite busy.
<Eickmeyer> tsimonq2: My salsa account (I already had one) is eickmeyer-guest.
<tsimonq2> Eickmeyer: Keep bugging me, I won't get annoyed.
<tsimonq2> Added.
<Eickmeyer> tsimonq2: Thanks
<tsimonq2> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: Open | 19.04 Released! | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Disco | If you can't send messages here, authenticate to NickServ first | Patch Pilots:
<tsimonq2> https://lists.ubuntu.com/archives/ubuntu-devel/2019-July/040762.html
<Eickmeyer> tsimonq2: Are you going to be sticking around for a bit?
<tsimonq2> Yeah, ish.
<Eickmeyer> tsimonq2: I'm pushing all branches to https://salsa.debian.org/multimedia-team/lsp-plugins
<tsimonq2> ack
<Eickmeyer> I need to fix the changelog to target unstable, but other than that it should be good to go.
<tsimonq2> Can you check if an ITP bug has been filed?
<tsimonq2> If not, can you please file one?
<Eickmeyer> Sure.
<tsimonq2> Thanks.
<Eickmeyer> tsimonq2: ITP filed.
<Eickmeyer> er... filed.
<Eickmeyer> Wierd font, looked like fled. :P
<teward> weird font*
 * teward resets Eickmeyer's grammar and speech centers
<Eickmeyer> teward: ERR: 404 GRAMMAR NOT FOUND
<tomreyn> No bootable device -- insert disk and press any key
 * Eickmeyer drools in stupor
 * teward installs "ChaosOS" onto Eickmeyer's head
<teward> :P
<sarnold> ENOGRAMR
 * Eickmeyer reappears as endgame boss from original Final Fantsy
 * Eickmeyer *Fantasy
 * Eickmeyer ERR: TYPING NOT FUNCTIONING, TOO MUCH ChaOS
 * teward uses REISUB on Eickmeyer.  It's super effective!  Eickmeyer has shut down.
<teward> okay back to work.
<teward> :P
<teward> okay last one: tomreyn: remind me where we keep the obsolete 6.06 installers again?  ;)
<sarnold> teward,tomreyn http://old-releases.ubuntu.com/releases/
<tomreyn> i'm too slow to replace both sarnold and google.
<teward> heh
<tsimonq2> Eickmeyer: Link?
<Eickmeyer> tsimonq2: For the ITP or https://salsa.debian.org/multimedia-team/lsp-plugins ?
<tsimonq2> The ITP.
<tsimonq2> I'll go ahead and put your package through The Paces locally.
<Eickmeyer> tsimonq2: Can't find the ITP. I was supposed to get a bugreport, will check spam.
<teward> did you file it against wnpp?
<teward> or a nonexistent source?
<Eickmeyer> teward: Yes, I filed it against wnpp using the template in bugreport wnpp
<teward> Eickmeyer: what was the subject line ou used?
<Eickmeyer> teward: I don't remember. Should I just refile?
<Eickmeyer> ERR: COFFEE INEFFECTIVE
<tsimonq2> Eickmeyer: The Debian bug tracking system is slow.
<teward> ^ this
<tsimonq2> If you don't get confirmation one hour after you filed it, it isn't there.
<teward> might take some time for it to actually process
<Eickmeyer> That must be it then.
<teward> Eickmeyer: ERROR: YOU STOLE MY COFFEE
<cjwatson> The relevant cron job runs every three minutes.  An hour is surely effective but super-conservative.
<Eickmeyer> cjwatson: You saying it might... be a while?
<cjwatson> Either I'm missing a joke, or no.
<Eickmeyer> cjwatson: Nah, just trying to find my ITP and being unsuccessful.
<cjwatson> It's certainly not the instant people expect from typical webapps these days, but it's a few minutes plus however long email takes to get to you
<cjwatson> Then it was probably badly formatted in some way that it got rejected
 * Eickmeyer will refile
<cjwatson> It should have sent you a rejection, but maybe your email system ate it
<cjwatson> (Though also, I suppose it's possible that your email hit greylisting on the input side of the Debian BTS; I can't see that part of things)
<cjwatson> I don't immediately see your email anywhere, but it's quite a long time since I was involved in Debian BTS admin so I'm pretty rusty on how it's put together
<tsimonq2> cjwatson: Somehow I'm not surprised you have perms there. ;)
<cjwatson> I was an active admin from 2002 to 2006ish; I haven't done much to it since except occasional bits of support
<cjwatson> If I were working on it nowadays the priority would be to give it a decent database backend as a prerequisite for essentially everything else.  (Which I think somebody is in theory working on, maybe ...)
<Eickmeyer> Refiled.
<Eickmeyer> cjwatson: No rejection, but not receiving an email about it either.
<Eickmeyer> cjwatson: Rather, I have received nothing.
<cjwatson> Eickmeyer: OK, you'll need somebody actually active to look.  dondelelcaro might be around on some Debian channels (#debian-bugs or #debian-devel on OFTC maybe?) or you could try emailing owner@bugs.debian.org but don't expect a quick response there
<teward> Eickmeyer: if you can send to me on Telegram your contents I might be able to file the ITP and reassign owner thanks to some Control knowledge I picked up
<teward> assuming of course it still isn't picked up
<teward> or you can jsut wait
<Eickmeyer> teward: I'll work on it.
<teward> ack
<Eickmeyer> teward, cjwatson: I even tried to email it to submit@bugs.debian.org directly and I got hit with an "address not found" error.
<teward> o.O
<teward> from your mail server / service or from submit@bugs.debian.org?
<teward> (exact error plz)
<Eickmeyer> FROM my mail server (gmail-based) to submit@bugs.debian.org
<Eickmeyer> teward: I see what I did wrong. Redoing...
<cyphermox> cpaelzer: could I convince you to review a MIR for me when you have a moment?
<tsimonq2> Eickmeyer: What'd you do? :)
<Eickmeyer> tsimonq2: I manually sent it but to .com instead of .org
<Eickmeyer> tsimonq2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931347
<ubottu> Debian bug 931347 in wnpp "ITP: lsp-plugins -- LSP (Linux Studio Plugins)" [Wishlist,Open]
<Eickmeyer> Either way, it's good now. ^
<cpaelzer> cyphermox: you clearly can, but can I do that tomorrow after I slept?
<cpaelzer> or is it really urgent?
<cpaelzer> cyphermox: I see none as NEW in the queue
<cyphermox> no, it's not urgent, it certainly can be tomorrow. I haven't written it quite yet ;)
<cyphermox> I'm struggling with high latency and a busy CPU
<cpaelzer> I'll check the NEW MIR queue tomorrow then
<cyphermox> ta
<seb128> bdmurray, hey, I'm curious but what heuristic is used to comment on ubiquity bugs about integrity issues?
<seb128> I was expecting squashfs errors but just saw a case where the attach syslog doesn't have any of those but the bot commented on
<bdmurray> seb128: which bug was it?
<seb128> bug #1835059
<ubottu> bug 1835059 in ubiquity (Ubuntu) "install crash (ubiquity.install_misc.InstallStepError: Unable to install 'console-setup' due to conflicts.)" [Undecided,Incomplete] https://launchpad.net/bugs/1835059
<bdmurray> seb128: It looks at casper for this line "Identifying... [04ba3a6ca8a6d9e7f686a24ecf67ba43-2]"
<bdmurray> seb128: and checks to make sure it matches what the iso file should have
<bdmurray> seb128: there is a suspicous bit in casper and ubuqitysyslog - deb cdrom:[Ubuntu 18.04.2 LTS _Bionic Beaver_ - Release amd64 (20190210)]/ kali-last-snapshot contrib main non-free
<seb128> bdmurray, so non official iso?
<teward> that looks like it's referring to a Kali ISO
<teward> which isn't official :p
<seb128> is that Identifying number the md5 or something like that?
<seb128> I though you were checking for squashfs error in syslog, which is my usual hint for invalid images issues
<bdmurray> seb128: its the result of apt-cdrom ident on the iso
<seb128> ah, I see
<seb128> bdmurray, thx for the info, I learnt something new :)
<teward> seb128: wrt #1835077 you subbed Sponsors to, I'd be hesitant to put Sponsors on that until we know whether this is documented somewhere upstream - because this 'directory' they're referring to doesn't seem to be 'standard'
<seb128> unsure if that setup is weird
<teward> (I don't believe it's ready to even be considered for sponsors)
<seb128> teward, I think I disagree with other on what is useful to sponsors
<tsimonq2> seb128: I haven't had the chance to respond to your email yet, but yeah.
<tsimonq2> You make a good point.
<seb128> I'm personally interested in diff/suggestions that have enough sense to hit someone knowledgable on the way of making a fix available
<seb128> like if some contributor hint me enough that I can pick up the work and do a fix it's a win for me
<seb128> I don't need/require them to go the full way
<teward> tsimonq2: go read PMs
<teward> you have a dozen
<seb128> tsimonq2, no worry, sorry to be arguing
<seb128> we maybe need split queues
<bdmurray> Oh, look what was in my search history.
<bdmurray> https://pkg.kali.org/pkg/console-setup
<tsimonq2> seb128: I agree on split queues.
<seb128> one for things ready to be uploaded, one for detective work/hints that might be useful to the maintainer to get a fix uploaded
<teward> ^ that
<bdmurray> I thought we had that already
<bdmurray> https://launchpad.net/~ubuntu-reviewers
<bdmurray> ^ that's the one for detectives
<teward> then it should be a case of end users and triagers NOT subbing sponsors simply because a patch is attached :p
<bryce> detailed test cases can be quite helpful.  sometimes more useful than actual patches.  not sure how to detect bug reports with them, though.
<seb128> I think a but with a SRU description including test case/regression potential and a debdiff should qualify to stay in the queue though
<seb128> even if there is a question on whether that needs to be sent to Debian as well
#ubuntu-devel 2019-07-03
<sahid> sil2100: o/
<sahid> verification done https://bugs.launchpad.net/nova/+bug/1808951, if you can have a look when you have a moment
<ubottu> Launchpad bug 1808951 in tripleo "python3 + Fedora + SSL + wsgi nova deployment, nova api returns RecursionError: maximum recursion depth exceeded while calling a Python object" [High,Triaged]
<sahid> then we should be able to unblock for testing https://bugs.launchpad.net/ubuntu/+source/neutron/+bug/1831754
<ubottu> Launchpad bug 1831754 in nova (Ubuntu Disco) "[SRU] stein stable releases" [Undecided,New]
<sil2100> sahid: hey! Thanks! Let me try looking at that, but if I don't find time today I'll do it for sure tomorrow during my SRU shift
<sahid> sil2100: ok thank you, feel free to ping when i can start testing the SRU
<LocutusOfBorg> Unit193, hello, can you please forward the patch to this bug report? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=904660
<ubottu> Debian bug 904660 in src:opensips "opensips FTBFS with json-c 0.13.1" [Important,Open]
<LocutusOfBorg> btw, the real last blocker is syslog-ng, and there is an open Debian RC bug
<LocutusOfBorg> maintainer should deal with it soon(TM)
<Unit193> Well, the Debian maintainer is an upstream maintainer, seems there's new versions too...Also I'd kind of prefer to test a patch more before forwarding to Debian, but I guess I could..
<doko> tkamppeter: re cups ftbfs. of course this is still relevant. the test rebuild was done *after* the build in the archive
<doko> so citing the archive build doesn't help
<cking> any idea why  autopkgtest is failing with 'Can't exec "gcc": No such file or directory at /usr/share/perl5/Dpkg/Arch.pm line 126.' ,  see https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/z/zfs-linux/20190703_123021_5234a@/log.gz
<seb128> juliank, hey, could you look if we can maybe sync lz4 from Debian? It's unclear if the O3/s390x changes are still needed (and if they are, could we sent that to Debian?)
<juliank> seb128: I'd be more concerned with the other changes
<juliank> Not sure what V=1 does, it seems useless
<seb128> juliank, building with V=1? (why does that need to be an Ubuntu delta?)
<juliank> But the patch to the examples Makefile is not in Debian
<seb128> shouldn't it be upstreamed/sent to Debian?
<juliank> I'm very confused
<seb128> so we can get back in sync
<juliank> seb128: Well, we can just sync it, and if it FTBFS, we'll see what changes are still needed :)
<juliank> or rather, if changes are still needed
<seb128> that's one way indeed :)
<seb128> I prefer to ping before doing that though
<seb128> in case you wanted to have a look
<juliank> I synced, let's see what happens :)
<seb128> thx
<didrocks> cking: hey! thanks for following up on zfs 0.8 upload btw ;)
<juliank> I mean, with gcc 9 coming soon, things will probably break again anyway
<cking> didrocks, it would be even better if I can figure out why it's no passing the autopkgtests
<didrocks> cking: yeah, the error is puzzling, with your second upload, it should have been okâ¦
<cking> didrocks, exactly. and it works fine when I run the tests locally
<didrocks> ofc :/
<seb128> juliank, gcc9 is coming? good to know :)
<didrocks> maybe modifying the postinst to cat make.log, but an upload for this if it can't be reproduced (even in an autopkgtests vm)
<juliank> s390x built successfully, woohoo
<juliank> the arms are still testing, but hopefully succeed as well
<Laney> cking: This failure happens for me locally
<Laney> I don't think it's that 'Can't exec "gcc"' thing - that was present in the successful runs too.
<Laney> ...but rather zfs-dkms not being installable
<cking> Laney, message that concerns me is "configure: error: C compiler cannot create executables" - not sure if that's a tool chain thing or not
<Laney> I dunno, but for me the make.log contains:
<Laney> ubuntu@autopkgtest:/tmp/autopkgtest.4RB7XA/build.QMj/src/debian/tests$ more /var/lib/dkms/zfs/0.8.1/build/make.log
<Laney> DKMS make.log for zfs-0.8.1 for kernel 5.0.0-17-generic (x86_64)
<Laney> Wed 03 Jul 2019 03:46:22 PM BST
<Laney> make: *** No targets specified and no makefile found.  Stop.
<cking> ah, ok, that's useful
<Laney> autopkgtest-buildvm-ubuntu-cloud and the qemu runner should get you here
<cking> Laney, any hint on how you use that?
<Laney> http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test
<cking> ta
<Laney> the second to last example, but replace all package names with zfs-linux
<Laney> and add --shell-fail probably
<cking> Laney, so inside my autopkgtest environment, when I compile "int main(void) { return 0; }" - gcc x.c I get: /usr/bin/ld: cannot find Scrt1.o: No such file or directory /usr/bin/ld: cannot find crti.o: No such file or directory - this is on Eoan with the gcc 8.3 compiler
<cking> doko, any ideas why gcc 8.3 on amd64 is failing like that? ^^
<doko> cking: which binutils is this, the one from -proposed?
<cking> it was from the daily autopkgtest eoan cloud image, so I guess it may be old, not sure what to check
<cking> 2.32.51.20190614-0ubuntu1
<doko> that one should be fine. 20190701 was bad
<cking> hrm,ok, let me dig deeper
<Laney> cking: missing libc6-dev?
<doko> of course!
<cking> yep indeed
<Laney> surely something should have pulled that in
<cking> one would have thought so, but apparently not
<Laney> ok, I'll leave it up to you to work out where the right place to insert that is ...
<rbasak> vorlon: opinion on bug 1595358 please? I don't see any dep8 tests, so does that disqualify me from approving the SRU without a TB member's approval?
<doko> it's intended that gcc doesn't depend on libc6-dev, because you don't need it to build the kernel ...
<ubottu> bug 1595358 in lyx (Ubuntu Xenial) "[SRU] Update to maintenance release 2.1.5 in Xenial" [Low,New] https://launchpad.net/bugs/1595358
<rbasak> vorlon: on balance it seems reasonable to me (subject to review)
<cking> doko, so i need to explicitly require it for building a dkms module now? the dkms build does some autotool sanity checks, so it needs libc6-dev
<Laney> maybe dkms ought to have it?
<cjwatson> It has Depends: make | build-essential which is a bit WTF
<Laney> Yeah.
 * cking blinks
<cjwatson> I can't follow the chain of reasoning that would lead to doing that
<rbasak> Make has Build-Essential: yes.
<rbasak> Not that it makes a difference, but perhaps there's some inverted reasoning there?
<cjwatson> Not using build-essential is fair enough but what's the point of the alternative?  Should be make, libc6-dev | libc-dev anyway.
<cjwatson> (It shouldn't have build-essential since it doesn't need g++, and build-essential isn't really a good thing to depend on anyway.
<cjwatson> )
<doko> yep, make, libc6-dev | libc-dev looks like the right thing
<vorlon> rbasak: I don't think you need a separate TB approval to approve that SRU.  I do know that I looked at that SRU in the queue briefly and punted on it because it looked like a lot of work
<rbasak> vorlon: I mean the "For upstreams who have...it is also acceptable to upload new microreleases with many bug fixes without individual Launchpad bugs..." part of the policy. What would you expect to review in this case? That it all seems sensible, maybe the upstream notes of the changes, but not the code changes themselves, presumably?
<rbasak> (I'd also check the upstream tarball matches upstream's published one)
<vorlon> shrug, again, when I peeked at it it looked like too much work
<vorlon> to my understanding the TB has blanket delegated these questions to the SRU team
<rbasak> That's not how I read the policy
<rbasak> " In other cases where such upstream automatic testing is not available, exceptions must still be approved by at least one member of the Ubuntu Technical Board"
<rbasak> Where "such upstream automatic testing" is the bulleted list of four items.
<rbasak> Which I see as "and"-ed.
<vorlon> I'm not sure the delegation got captured on the wiki page when it was done
<rbasak> However as you are a TB member, I consider this conversation good enough :)
<vorlon> ok
<infinity> cjwatson, doko, Laney, cking: There's no reason dkms should depend on build-essential *or* on libc6-dev.  Kernel modules don't need libc6-dev to compile.  If zfs-dkms needs it, it should depend on it, but that's unique to that build system, not generic for all dkms modules.
<infinity> (agreed that the dkms alternat dep makes no sense, but it just shouldn't be there)
<cking> infinity, sounds fair to me
<infinity> cking: Though, I will say that autotools tests that rely on libc6 when setting up a kernel module build which will ultimately use kernel headers that are subtly different from userspace headers sounds daft. :)
<infinity> cking: (Or maybe the problem is just that they're using a few of the "does the compiler work" type tests and they should remove those and make it kernel only?)
<infinity> cking: Anyhow, simple downstream solution is to depend on libc6-dev.  A more comprehensive upstream solution to not actually need libc headers might be nice though, cause it clearly doesn't (or better not) need them to build the kernel module.
<cking> infinity, i believe it's a "is the compiler sane for this build" kind of check that is required because the driver is build on lots of diverse systems
<cking> *built
<infinity> cking: A third (again, downstream) option would be to preseed the autoconf values for any userspace tests because we know our compiler works and don't want to force everyone to install libc6-dev, but that point's vaguely moot since we ship zfs pre-built anyway and don't expect people to use the dkms package.
<infinity> cking: Which leads to the fourth option of not producing the dkms package at all on Ubuntu.
<infinity> cking: Pick one. :)
<cking> infinity, the dkms package is kinda useful for users to use their own kernels
<infinity> cking: Though, in Debian, it definitely looks like it should have the libc-dev dep.
<infinity> cking: Fair enough on the custom kernel thing.  So the dep it likely the path of least resistance, unless you feel like preseeding the poop out of autoconf or rewriting upstream's stuff to use kernel headers and -nostdlib
<cking> it's just easier if i add the deb, it's an explicit no-brainer
<infinity> cking: If you're pushing this back to Debian, remember that "libc6-dev" is spelled "libc6-dev | libc-dev" because it's not libc6 on all arches, irritatingly.
<infinity> It is on all of ours, though.
<cking> nice to know, thanks
<vorlon> I thought all the archs that were libc-dev instead of libc6-dev were also non-Linux
<vorlon> ... not counting those Linux archs that were libc6.1-dev
<mithrison> hi, I want to customize ubuntu server packages and create a bootable image for rasberry pi that includes those custom added packages in it
<CarlFK> mithrison: /j #timvideos and I'll point you to something that may be what you are looking for
<teward> Laney: alive?
#ubuntu-devel 2019-07-04
<Unit193> tsimonq2: Reminder about LP 1822672
<ubottu> Launchpad bug 1822672 in popularity-contest (Ubuntu) "popularity-contest is probably broken" [Medium,New] https://launchpad.net/bugs/1822672
<LocutusOfBorg> juliank, hello, what is your opinion wrt aptitude merge?
<juliank> LocutusOfBorg: useless atm
<juliank> it's just minor packaging clean up right now
<LocutusOfBorg> oh ok :)
<LocutusOfBorg> and what about libapt-pkg-perl?
<LocutusOfBorg> syncpackage -f?
<juliank> yeah
<tkamppeter> doko, hi
<LocutusOfBorg> juergh, will you sync or can I?
<juergh> LocutusOfBorg, wrong nick^?
<LocutusOfBorg> oops I meant juliank ^^
<LocutusOfBorg> sorry!
<juliank> Yes
<juliank> I'll sync
<juliank> I synced
<LocutusOfBorg> thanks
<juliank> Can I specifiy seccomp policies for lxd containers and use that to disallow fsync and friends?
<juliank> That could be useful for my ephemeral containers
<LocutusOfBorg> doko, I think the new dwz is breaking stuff, like verilator
<LocutusOfBorg> dh_dwz: dwz -q -mdebian/verilator/usr/lib/debug/.dwz/x86_64-linux-gnu/verilator.debug -M/usr/lib/debug/.dwz/x86_64-linux-gnu/verilator.debug -- debian/verilator/usr/bin/verilator_bin debian/verilator/usr/bin/verilator_bin_dbg debian/verilator/usr/bin/verilator_coverage_bin_dbg returned exit code 1
<ricotz> marcustomlinson, hi :), is libreoffice 6.2.5 on your list yet?
<Unit193> LocutusOfBorg: Unrelated to the new one, I've had issues with dwz before so I've skipped updating to 12. :/
<juliank> Maybe someone here knows this: I'm wondering if it's possible to have on dbus method, but different PolicyKit permissions
<LocutusOfBorg> Unit193, related to the new one
<LocutusOfBorg> I just downgraded dwz and it worked correctly a rebuild
<LocutusOfBorg> if you have issues with dh_dwz, please tell me, I fixed a bunch of them already
<juliank> Like a ManagePackages() method, and then ask a special permission if packages need to be removed
<LocutusOfBorg> e.g. usually they show when the package plays bladly with *FLAGS*
<doko> LocutusOfBorg: do you have the files in a bug report?
<LocutusOfBorg> doko, I just opened a bug report
<LocutusOfBorg> which files do you need?
 * juliank has not used policykit as a developer
<LocutusOfBorg> https://bugs.launchpad.net/ubuntu/+source/dwz/+bug/1835398
<ubottu> Launchpad bug 1835398 in dwz (Ubuntu) "dwz 0.12.20190703-1 breaks verilator build" [Undecided,Confirmed]
<LocutusOfBorg> I'm doing a new build with the new dwz (sorry, but I deleted it when I downgraded dwz to test if the build was good or not)
<Unit193> LocutusOfBorg: 'DWARF version 0 unhandled' with release pocket, 'Found compressed .debug_aranges section, not attempting dwz compression' with -proposed.
<Laney> juliank: you (the service) can decide when to invoke PK to check authorisation for an action
<juliank> Laney: thanks
<Laney> juliank: e.g. something like https://gitlab.freedesktop.org/bolt/bolt/blob/master/boltd/bolt-bouncer.c#L136 which I just happened to have open
<LocutusOfBorg> Unit193, I don't get what you are referring to
<Unit193> The aformentioned dwz issue I've run into?
<LocutusOfBorg> ok Unit193 but which package?
<Unit193> ruby-bcrypt-pbkdf
<LocutusOfBorg> Unit193, the first hack might be to add an empty dh_dwz override
<LocutusOfBorg> Unit193, I see one dwz bug... "-Wl,--compress-debug-sections=zlib" is the culprit
<LocutusOfBorg> this probably makes dh_dwz fails to read the info because its compressed
<LocutusOfBorg> I would try to make dwz smarter
<LocutusOfBorg> this with dwz from release
<Unit193> That's what it looked like to me as well.
<LocutusOfBorg> I tried to run dwz after doing manually the link without that flag and it worked
<LocutusOfBorg> can you please open a bug report?
<Unit193> I modified /usr/lib/x86_64-linux-gnu/ruby/2.5.0/rbconfig.rb and was able to run the build as expected.
<GunnarHj> Hi LocutusOfBorg, do you have time to sponsor bug #1728012? See that you did the latest merge, and this is a straightforward fix.
<ubottu> bug 1728012 in sane-backends (Ubuntu Bionic) "Many 3rd party scanner drivers are broken by a sane change" [High,In progress] https://launchpad.net/bugs/1728012
<doko> LocutusOfBorg: verilator_bin_dbg is missing :-/
<LocutusOfBorg> doko, it takes a couple of minutes to build...
<LocutusOfBorg> I can't upoload 70Mb of binaries
<LocutusOfBorg> GunnarHj, .
<GunnarHj> LocutusOfBorg: Still here. :)
<doko> LocutusOfBorg: then just upload the files needed for dwz
<LocutusOfBorg> doko, verilator_bin_dbg isn't needed?
<doko> LocutusOfBorg: why not?
<doko> I don't see anthing there about compressed debug sections
<LocutusOfBorg> doko, the problem about compressed debug sections was for ruby-bcrypt-pbkdf
<LocutusOfBorg> I'm doing a tarball right now
<LocutusOfBorg> I'll email to *yournick*@ubuntu.com
<doko> LocutusOfBorg: nm, I have it
<LocutusOfBorg> both verilator and ruby-bcrypt?
<LocutusOfBorg> GunnarHj, my "." meant "uploaded"
<doko> no ruby. put it on p.d.o
<LocutusOfBorg> doko, if you want to test yourself, just change debhelper-compat from 11 to 12
<LocutusOfBorg> I mean ruby, it takes some seconds to build
<doko> no, I want the files from the command line
<LocutusOfBorg> I don't get then
<doko> ?
<LocutusOfBorg> which files?
<LocutusOfBorg> verilator?
<LocutusOfBorg> verilator has nothing to do with compressed debug sections
<LocutusOfBorg> verilator shows some kind of regression in dwz
<LocutusOfBorg> while ruby-bcrypt-pbkdf seems to imply that dwz can't read compressed .debug_aranges sections
<LocutusOfBorg> but only verilator (what I reported as bug) is actually a regression to me
<marcustomlinson> ricotz: it is
<marcustomlinson> ricotz: now that you pointed it out ;)
<GunnarHj> LocutusOfBorg: Great, thanks! Is that "." some convention I have missed? ;)
<LocutusOfBorg> GunnarHj, It is used on #debian-ftp irc channel when somebody does what requested, not sure but I use it on lots of places, but probably only debian developers understand it
<rbasak> I've never heard of that. The only related thing I can think of is SMTP's end of message indicator.
<LocutusOfBorg> doko,
<LocutusOfBorg> -  if (debug_sections[DEBUG_INFO].data == NULL)
<LocutusOfBorg> +  if (debug_sections[DEBUG_INFO].data == NULL
<LocutusOfBorg> +      && !rd_multifile)
<LocutusOfBorg> http://launchpadlibrarian.net/431463266/dwz_0.12-3_0.12.20190702-1ubuntu1.diff.gz
<LocutusOfBorg> the diff shows clearly that they added a new statement about multifile...
<GunnarHj> LocutusOfBorg: I see. Useful when people know about it. Thanks for explaining!
<LocutusOfBorg> https://sourceware.org/git/?p=dwz.git;a=commitdiff;h=08becc8b33453b6d013a65e7eeae57fc1881e801
<LocutusOfBorg> doko, ^^^
<doko> LocutusOfBorg: please add your comments to the upstream issue
<LocutusOfBorg> .
<jamespage> doko: hey - so...
<jamespage> doko: do we have a general objective to drop all python-* packages this cycle?
<jamespage> we've had a few syncs from experimental where some early work has been done in Debian; its only very partial and has wedged a load of proposed migrations
<jamespage> and I'm having trouble working up an appetite to work through all of the reverse-depends(-depends)* to unblock things if this will be a general objective once Debian development re-opens
<doko> jamespage: no, it's up to you, however you'll probably have to maintain a delta with Debian for a while
<jamespage> doko: we looks at the first level reverse-depends and hit 84 packages...
<jamespage> I'm very tempted to *not* do this first in Ubuntu
<doko> then you'll have to wait for the Debian plan ...  we'll have a BoF at DebConf. So if you want to provide some information, please do
<jamespage> doko: we've already switch the openstack 'projects' to drop python-* but they are leaf packages; the module set is more intertwined with other things
<jamespage> infact we mostly did that last cycle.
<doko> jamespage: do you have a list of stage2 and stage3 modules as well?
<jamespage> doko: not yet - only just started looking
<jamespage> sahid is working the scope atm
<doko> jamespage: could you do that analysis on unstable, and then post to the debian-python ML?
<doko> jamespage: within the next two weeks
<jamespage> er
<jamespage> will try
<sahid> jamespage: any chance you look at https://code.launchpad.net/~sahid-ferdjaoui/ubuntu/+source/cinder/+git/cinder
<sahid> cinder was stuck in proposed and corey is out today i think
<sahid> https://launchpad.net/~sahid-ferdjaoui/+archive/ubuntu/bionic-queens/+build/17220986
<sahid> buildroot ^
<jamespage> sahid: is that change needed? i.e. I think its not something we would normally SRU
<Laney> bdmurray: did you just change something on your phased update emails? I just got a few of them which are listing *lots* of crashes that are not actually new in the upload you're pointing out.
<sahid> jamespage: SRU 1830341
<sahid> https://launchpad.net/ubuntu/+source/cinder/2:12.0.7-0ubuntu1/+build/17217605
<jamespage> caused by
<jamespage> dh_missing: usr/etc/cinder/resource_filters.json exists in debian/tmp but is not installed to anywhere
<jamespage> maybe we need to install that file  in a package instead?
<sahid> jamespage: let me double check
<tomreyn> Can you already tell when exactly (which day) 18.10 reaches EOL?
<ricotz> marcustomlinson, alright ;)
<Eickmeyer> tomreyn: It's exactly 9 months to the day. So, since 18.10 was released October 18th, its EOL is July 18th.
<tomreyn> Eickmeyer: oh, is this documented somewhere? because i always felt the "supported for nine months" statement to be imprecise. maybe just adding the word "exactly" there would help a lot.
<tomreyn> Eickmeyer: but indeed the distro-info command seems to support what you're saying:
<tomreyn> $ distro-info --days=eol --series cosmic
<tomreyn> 14
<rbasak> tomreyn: usually it's officially EOL only when the release team decides it is. AIUI, there are some actions associated with EOLing (certainly the announcement) so it tends to vary depending on who is busy with what at the time.
<tomreyn> rbasak: i see. but i guess the release team would not ever decide to set the factual EOL to a point that is earlier than the exact data calculated from the release announcement and what is reported by (ubuntu-)distro-info, right?
<tomreyn> s/data/date/
<aiena> Does anyone know if I can use distribution source pacakges to develop custom device drivers for the linux kernel
<aiena> I have a device I want to try my hands at driver programming for. I will take full responsibility for anything that goes wrong.
<CarlFK> aiena: there are no rules against it if that is what you are asking
<aiena> yes I want to eventually contribute it back.
<aiena> I looked up the basics and got some code up but I do not know how to use the distro's linux/init.h
<aiena> for example to build it
<aiena> currently it just has a few printk() statements which display stuff on loading and unloading the module.
<aiena> But I do not know how to use ubuntu's source packages to compile it
<aiena> I got wireshark to capture packets from the hardware with the usbmon driver
<aiena> can you guide me on how to pick up linux sources from the distro
<CarlFK> aiena: that is a huge subject that will take hours.  I have this in my history, it is 10 years old, but still relevant: https://slideplayer.com/slide/6865803/
<CarlFK> aiena: I have a page somwhere that has more details about that, having trouble finding it
<rbasak> tomreyn: I assume so
<CarlFK> aiena: https://github.com/timvideos/litex-buildenv/wiki/FPGA_Linux_module  - if you want to talk to me about this,  /join #TimVideos
<rbasak> aiena: there's usually a linux-headers-* package that corresponds to the linux-image-* that you have in use.
<aiena>  /join #TimVideos
<tsimonq2> Unit193: popularity-contest> ack
#ubuntu-devel 2019-07-05
<mithrison> hi
<mithrison> I'm having problem running snap and snapcraft on ubuntu 18 server on raspberry pi.. details and logs --> https://forum.snapcraft.io/t/multipass-on-raspberry-pi-3b/12162/2
<CarlFK> mithrison:  ask in  #ubuntu-server   (#u may have an answer too.  here isn't the place)
<mithrison> ok thanks
<bdmurray> Laney: Hi, yesterday was a US holiday. I did not change anything with the phased-updater and I've gotten the same emails and will be looking into the issue today. Its quite strange.
<Laney> bdmurray: ack, thanks
<ahasenack> is migration stuck? The https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html page shows a generated time of Generated: 2019.07.05 14:17:42 +0000
<ahasenack> it's close to 20UTC now
<vorlon> ahasenack: proposed-migration is running now; I don't know why it was delayed
<Odd_Bloke> vorlon: ahasenack: I believe Laney zapped it so that infinity could eat a taco.
#ubuntu-devel 2019-07-06
<cjwatson> ahasenack,vorlon: that sounds like a result of yesterday's network outage
<LocutusOfBorg> vorlon, I propose to sync iputils... what is your opinion? the only delta left is the cross-building hack, but debian revritten in dh clean rules... maybe it's fixed now?
<cjwatson> Debian claimed to fix my cross-building bug in that rewrite
<cjwatson> So it's possible
<LocutusOfBorg> soooo sync and see?
<cjwatson> err I hear it's possible to do local tests
<LocutusOfBorg> cjwatson, my problem is that I don't know how to reproduce what is written there https://bugs.launchpad.net/ubuntu/+source/iputils/+bug/872370
<ubottu> Launchpad bug 872370 in iputils (Ubuntu) "iputils fails to cross-build" [Undecided,Fix released]
<cjwatson> Pretty sure there's documentation somewhere on the Ubuntu wiki.  At any rate it is not IMO acceptable for an Ubuntu developer to say "I don't know how to reproduce this thing, so how about we just drop your work"
<cjwatson> https://wiki.ubuntu.com/CrossBuilding   oh look
<cjwatson> (the autobuilder linked there hasn't run for ages, but the rest is still AFAIK basically current)
<Unit193> IIRC, pdebuild -- --host-arch i386  for example.
<LocutusOfBorg> cjwatson, I wouldn't have asked if I was sure about how to do it... I also tried some way including using yocto arm sdk to setup the cross environment, but I failed
<LocutusOfBorg> Unit193, I guess I have to create an amd64 tar.gz and then use pdebuild passing i386?
<LocutusOfBorg> I'm not sure if this fixes the original issue, because arm* is more tricky when it comes to cross-build
<LocutusOfBorg> and doing "-m32" might even work without actually exposing the original bug
 * LocutusOfBorg tries a simple dpkg-buildpackage -a i386
<LocutusOfBorg> 	Renaming iputils-ping-dbgsym_20190515-1_i386.deb to iputils-ping-dbgsym_20190515-1_i386.ddeb
<LocutusOfBorg>  dpkg-genbuildinfo
<LocutusOfBorg>  dpkg-genchanges  >../iputils_20190515-1_i386.changes
<LocutusOfBorg> syncing, on an amd64 chroot, with :i386 stuff installed and forcing i386 arch worked
<LocutusOfBorg> there is a missing libcap2-bin dependency
<LocutusOfBorg> doko, verilator fixed.
<LocutusOfBorg> vorlon, I stole the lshw delta, uploaded in Debian and will autosync in 6 days
<Unit193> OK, so xfce4-sensors-plugin is stuck in proposed, fails on s390x, but in Debian there doesn't seem to be any issue and on my own test (qemu) pbuilder it passed too.  I'd guess that Debian's are virtual as well, and perhaps Ubuntu's are real?  Any ideas?
<Unit193> ...Also I wouldn't expect anyone to ever use this package there, sooo..
<Unit193> LocutusOfBorg: I presume you aren't around?
#ubuntu-devel 2019-07-07
<vorlon> Unit193: the problem should be reproducible that HAVE_SYSFS_ACPI is undefined
<vorlon> Unit193: s/that/anywhere that/
<vorlon> Unit193: which is the case if /sys/class/power_supply is absent from the build environment; which could be true based on kernel settings or virtualization type, I don't know
<Unit193> vorlon: Huh, OK.  Thanks.
<Unit193> Not precisely sure why they'd have it and Ubuntu not, but oh well.
<vorlon> it's definitely a bug in the upstream source, which means to have this code disabled with HAVE_SYSFS_ACPI unset but misses an #ifdef somewhere
<Unit193> Indeed.
<Unit193> Makes knowing if you've fixed it a bit more complicated.
<Unit193> Perhaps related to the dwz issue I was having http://sourceware.org/git/?p=dwz.git;a=commit;h=96eba5d6ffaf57d019287dcf908219e5eff741ab
<LocutusOfBorg> Unit193, I am now, but I'm leaving
<tomreyn> tsimonq2: regarding the calamares + secret key (not just initial but repeat) mkinitramfs umask issue, i noticed there is (also?) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931373
<ubottu> Debian bug 931373 in calamares-settings-debian "calamares-settings-debian: default permissions on initramfs is insecure for full-disk encryption" [Normal,Fixed]
<tomreyn> now this debian package creates /etc/initramfs-tools/conf.d/initramfs-permissions whereas upstreams' https://github.com/calamares/calamares/commit/c9b675cbc64ac5aab35ddd86a64311abd50f7720#diff-933952de88b4fa3e887c2f40385fb527 creates /etc/initramfs-tools/conf.d/calamares-safe-initramfs.conf - hopefully the debian maintainers don't end up with two configration includes now.
<cjwatson> xnox: You're TIL on debian-archive-keyring - please could you either merge it or say it's OK for me to do so?  We need to get LP's keys updated for Debian imports
<cjwatson> (And these days we normally do that by backporting it from Ubuntu devel)
<doko> he's away for ten days without laptop
<cjwatson> Oh, thanks.  Maybe I'll just steal TIL on that then
<cjwatson> (But tomorrow, probably)
<ginggs> cjwatson: already done by mapreri
<mapreri> cjwatson: in case you are interested, there is an open bug on that package asking to do SRUs of it.  maybe somebody could do that as well.
<cjwatson> Thanks.  I probably don't have the effort (or need) for SRUs though
<mwhudson> good morning
#ubuntu-devel 2020-06-29
<eoli3n> Hi
<eoli3n> As said few days ago : 14:40 +R0Ck3R
<eoli3n> 15:44 +mbond
<eoli3n> 16:33 -mbond
<eoli3n> 19:00 abbe_>abbe
<eoli3n> 19:35 +mbond
<eoli3n> sorry for this, wrong paste :/
<eoli3n> so as said few days ago about this : https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1882232
<ubottu> Launchpad bug 1882232 in chromium-browser (Ubuntu Focal) "Fresh install of chromium-browser during installer-like process, in a chroot fails (when preparing machines prior to first boot)" [Medium,Fix committed]
<eoli3n> snap packages can't work with mounted homes
<eoli3n> we use nfs homes
<eoli3n> cannot open path of the current working directory: Permission denied
<eoli3n> i think zyga said me that he could fix this
<zyga> eoli3n: o/
<zyga> I'm a bit indisposed lately
<zyga> eoli3n: can you please tell me where you mount nfs homes?
<eoli3n> under /home
<zyga> directly in /home/foo or in a deeper structure?
<zyga> eoli3n: can you show me how the mount is declared in either /etc/fstab or in a systemd mount unit please
<eoli3n> zyga its mounted with autofs
<eoli3n> prodpeda-samba.domain.fr:/home/p00000012366 on /home/p00000012366 type nfs4 (rw,relatime,vers=4.0,rsize=8192,wsize=8192,namlen=255,soft,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=162.38.80.24,local_lock=none,addr=162.38.151.4)
<zyga> eoli3n: can you paste the fstab line as well please
<zyga> this is what we use for detection
<zyga> *detection
<eoli3n> there is no fstab line
<eoli3n> i use autofs
<zyga> ah, I see
<zyga> I'm not familiar with autofs, how does it work?
<eoli3n> https://help.ubuntu.com/community/Autofs#Wildcard_characters
<eoli3n> but i don't get what information you need ?
<eoli3n> autofs mount a directory when it is accessed
<zyga> snapd has a global flag that indicates if NFS/CIFS workaround should be enabled
<zyga> we use two data sources for that
<zyga> we scan /etc/fstab
<zyga> and we scan actually mounted filesystems
<eoli3n> oh ok i get what you mean
<zyga> I'm looking for something that indicates that autofs is in use
<zyga> so the data is defined in /etc/auto.master?
<zyga> could you please pastebin /proc/self/mountinfo
<zyga> perhaps there's an automount mount point in place
<zyga> that would be useful to detect as well
<eoli3n> zyga: http://ix.io/2qtb
<zyga> aha
<zyga> 137 29 0:50 / /home rw,relatime shared:87 - autofs /etc/auto.master.d/home rw,fd=7,pgrp=22588,timeout=300,minproto=5,maxproto=5,indirect,pipe_ino=173399
<zyga> this is interesting
<zyga> so we can detect that
<zyga> I think that's enough for me to fix this now
<eoli3n> not really
<eoli3n> because filename could change
<eoli3n> there is no rules to be sure that autofs manage homes
<zyga> having an autofs on /home feels like a good enough flag
<eoli3n> yes
<zyga> and /etc/auto.master.d/home, does that mention nfs?
<eoli3n> is there anyworkaround to manually indicates to snapd that i use nfs homes ?
<zyga> no, not at present
<eoli3n> zyga see my first paste line
<zyga> ah, I see now, thank you :)
<zyga> I'm curious to ask about /net as well
<zyga> the /net directory is not something that will work with snaps
<zyga> is that a common convention?
<eoli3n> that's nfs installed applications
<zyga> I see
<zyga> eoli3n: I've updated https://bugs.launchpad.net/snapd/+bug/1784774 and marked https://bugs.launchpad.net/snapd/+bug/1821193 as duplicate
<ubottu> Launchpad bug 1784774 in snapd "snapd is not autofs aware and fails with nfs home dir" [Medium,Triaged]
<ubottu> Launchpad bug 1784774 in snapd "duplicate for #1821193 snapd is not autofs aware and fails with nfs home dir" [Medium,Triaged]
<eoli3n> thanks zyga
<zyga> eoli3n: fixed
<zyga> eoli3n: except github 500s
<zyga> eoli3n: I'll open the pull request once github is operational
<zyga> eoli3n: https://github.com/snapcore/snapd/pull/8936
<sil2100> cpaelzer_: hey! Looking at the removal of php-horde* packages - just making sure, we also want to remove those that migrated to the release pocket already, right?
<sil2100> Or does it make sense to leave them there as they migrated?
<sil2100> Since it seems 16 of those migrated successfully
<eoli3n> zyga: great, thanks a lot
<zyga> :)
<cpaelzer_> sil2100: you mean 1868281 I guess
<cpaelzer> yes I think that includes these
<cpaelzer> I'll also ask bryce in standup today to be sure
<rafaeldtinoco> cpaelzer: just as a fyi... if you're splitting the logical tags in versions because of me (when reviewing your big qemu merges), no need
<sil2100> cpaelzer: yeah, removing all of those now, we can always re-sync if needed
<kanashiro> hi o/ today I am starting my +1 maint shift and I started updating the "Things to pick" wiki page section, now I am going to check excuses and pick something to work on
<sil2100> kanashiro: excellent o/
<sil2100> kanashiro: I'm looking at the r-cran-httr test failures now - I see those regressed in the release pocket actually as well, but I want to check if they're reported upstream or not before I hint them
<kanashiro> sil2100: I am checking puppetdb, it is stuck in proposed for a while and it hasn't migrated in Debian for almost one year. I'll probably file a RM bug against it
<Unit193> ..If you were super ambitious, you could drop the upper limit in puppet-beaker. >_>
<kanashiro> Unit193: I feel the Debian maintainer is not having too much time to work on the package, I do not want to fix it now and then need to handle other bugs on my own. Better sync it again when it is well maintained
<kanashiro> btw it never landed in the release pocket
<Unit193> I only mention as it holds up net-scp
<kanashiro> Unit193: ah I see, did you try to relax the net-ssh version constraint in puppet-beaker?
<Unit193> net-scp*, no bug I figure it's what's needed.
<kanashiro> if not I can give it a shot
<Unit193> It's easier when all affected packages are in pkg-ruby. :/
<kanashiro> Unit193: agreed, one interested developer asked for help to work on puppet packages during the last debian ruby team irc meeting
<kanashiro> they lack manpower apparently
<Unit193> I mean, according to UDD same for -ruby...
<kanashiro> Unit193: after relaxing versions of net-s{sh,scp} the test passed, I'll submit a patch to Debian and upload it to Ubuntu
<Unit193> \o/
#ubuntu-devel 2020-06-30
<cpaelzer> xnox: did my qemu upload miss nettle/hogweed by 2 hours :-/
<cpaelzer> I was confused seeing "Build for superseded Source" after the 12h risc build job completed, but then found your ubuntu2 uploaded just slightly after it
 * cpaelzer exuses at the builders for twice the load to to this 2h miss - or if it wasn't for the 2h stares at xnox for not checking the build time of ubuntu1 :-P
<cpaelzer> hmm was even 6h TBH, so yeah mabye just unlucky timing and4 more hours to go for the new risc build
<seb128> I'm curious, why was that nettle rebuild for?
<seb128> '  * No change rebuild against new libnettle8 and libhogweed6 ABI.'
<seb128> but those are binaries from the same source package
<seb128> xnox, would it make sense to have a transition tracker set up for nettle?
<sil2100> I'll be looking at opensaml autohint right now
<xnox> seb128:  transition tracker => yes
<xnox> cpaelzer:  i looked at -release pocket to generate 40+ uploads =/ some of them may have been redundant.
<xnox> (i.e. if they were _building_ in -proposed)
<xnox> sorry
<seb128> xnox, could you set it up?
<xnox> seb128:  yes, doing
<seb128> xnox, thanks
<seb128> xnox, isn't the auto-tracker thing supposed to do that automatically?
<xnox> seb128:  auto-tracker is dimitri running rsync on dists, running the script, committing the trackers.....
<xnox> which is what dimitri is doing
<seb128> I see
<seb128> we should set a proper job so less work for Dimitri :)
<xnox> seb128:  i haven't worked out how ben is deployed on snakefruit, to automate =)
<Laney> xnox: we should get lxd installed there, and then we can try to get a modern ben in a tractable way
<Laney> vorlon / sil2100: opinions?
 * xnox pushes the autotrackers to the right branch....
<kanashiro> mwhudson: I am considering to upload the cadvisor debdiff attached in LP #1884663 at the end of the day (disabling containerd support) to unblock stuff in proposed, if you have any objection please let me know
<ubottu> Launchpad bug 1884663 in containerd (Ubuntu) "cadvisor/0.35.0+ds1-4 FTBFS in Groovy" [Undecided,New] https://launchpad.net/bugs/1884663
<ahasenack> good morning
<kanashiro> today I am going to keep working on ruby packages, a bunch of them are stuck in proposed
<eoli3n> zyga you're nfs detection has been merged into snapd, when will it be packaged for ubuntu ?
<eoli3n> your
<rafaeldtinoco> morning o/
<juliank> xnox, rbalint, ddstreet: It seems ddstreet dropped ondemand.service in systemd, causing system to boot in performance mode now, which means it runs in turbo all the time
<xnox> maybe we can resurrect it, fix it up for pstates and still drop down to something more sensible instead of performance?
<juliank> xnox: Well it works for pstates
<xnox> juliank:  note Wimpress was also asking for GUI toggles to do performance or not.
<juliank> xnox: It checks which governors are available, and then sets the best one
<juliank> xnox: And it only understands interactive,ondemand,powersave, and powersave is the only overlap with pstates, and the recommended governor
<xnox> imho we should drop interactive,ondemand, and just do performance or powersave, and do powersave by default after a delay?
<juliank> xnox: I also think this should not be static, e.g. we should always use powersave governor, but its preference ! should be balanced_performance on AC and balanced_power on BAT
<juliank> for pstates that is
<xnox> juliank:  so udev, when detecting ac/battery change should start governor@balanced_power / blaanced_performance?
<xnox> unit, or just write to the file
<juliank> xnox: Well maybe, or thermald should set it, or upower
 * xnox is not sure what is monitoring and reacting to ac/battery
<juliank> xnox: like I have tlp installed to do that stuff
 * xnox thought upower is dead?
<juliank> xnox: is it?
<juliank> it's still used!
<xnox> it's in main, and seeded, so i guess upower is being used =)
<xnox> is balanced_power the right thing to do on servers too?
<juliank> Settings should give you options to configure the governor (performance vs powersave, though, who really wants performance, it just keeps CPU at max turbo all the time)
<juliank> And then energy_performance_available_preferences = default performance balance_performance balance_power power
<juliank> I guess performance governor or powersave governor with performance preference is right for servers
<juliank> though if you run a home server and want to save watts while idle, you might want balance_performance
<xnox> balanced_power sounds right
<xnox> as a better default than current
<juliank> xnox: No I think you want balanced_performance as the default, balanced_power turns of turbo or something
<xnox> juliank:  wanna open a bug report against systemd, and ask to resurrect ondemand.service, and make it do new shiny things?
<xnox> i.e. "don't drop it, make it pick better thing on better hardware"
<juliank> With balanced_power, I max out at 2.4 GHz instead of 3.4 GHz which is not super useful
<juliank> (average across cores)
<seb128> juliank, xnox, we have gamemode since focal which is basically a service and api to ask the governor to the set to performance (which some games use now)
<juliank> I think other distributions set the default governor to powersave in kernel config, and hence don't need that systemd unit?
<seb128> there is also a gnome-shell-extension-gamemode which gives you an UI toggle for it
<juliank> seb128: I'd like this neatly integrated without being gaming specific really, like windows has the slide from performance - balanced perf - balanced power - power, we should have too
<xnox> juliank:  can we change kernel config to do balanced_performance? (CC apw bjf) and win?
<seb128> juliank, that's something we have been discussing doing next cycle in desktop
<xnox> juliank:  yeah, Wimpress is asking for that.....
<cpaelzer> LocutusOfBorg: hi, you merged devscripts 2.20.4 into groovy. But it now shows up in component mismatches
<juliank> xnox: balanced_performance is the default for the powersave governor, but we boot with the performance governor to make initial boot faster (because CPU cores run at max turbo constantly until we are booted up)
<cpaelzer> LocutusOfBorg: due to "Add pristine-tar to Recommends.  Closes: #961532"
<xnox> juliank:  seb128: but a slider/ui/etc to change the default, doesn't mean we don't need to have a sensible default, or can't have it already?
<juliank> xnox: I'm not sure this makes smuch of a difference
<xnox> hm
<seb128> xnox, juliank, sensible default always make sense
<juliank> xnox: having performance vs powersave x balanced_performance
<cpaelzer> LocutusOfBorg: would you mind uploading an ubuntu2 version which does revert this minor change, as otherwise this explodes into follow on dependencies at https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<juliank> xnox: seb128: context was wrong, I was replying to my previous message, not to the latest xnox once about sensible default
<xnox> juliank: well, we didn't have balanced_performance before. Have we measured if it is slower to boot, than performance=>then=>powersave?
<juliank> xnox: seb128: I do agree we need a sensible default (powersave x balanced_performance)
<juliank> xnox: Probably not?
<xnox> do we need to ask cking to like redo all of those measurements again?
<juliank> maybe?
<xnox> also performance inside VMs kills the host basically
<cpaelzer> kanashiro: you are on +1 duty this week right?
<kanashiro> cpaelzer: yes
<cpaelzer> kanashiro: I wanted to ask if I could "request" something from you that I've seen while prepping the MIR meeting
<cpaelzer> kanashiro: I ahve above asked LocutusOfBorg already, but I'm unsure if he's seen it and is available
<cpaelzer> kanashiro: the recent upload of src:devscripts brought in a debian cahnge to depend on pristine-tar
<cpaelzer> kanashiro: that is a component mismatch which blocks things in groovy-proposed
<cpaelzer> kanashiro: I wondered if you could set yourself a reminder and if LocutusOfBorg didn't get to it e.g. until tomorrow EOD then you might do that
<cpaelzer> kanashiro: in case you are ok
<rbalint> xnox, juliank, seb128, ddstreet please open a bug against systemd in LP, but i think we should not resurrect the service but let kernel and desktop sort governor out
<rbalint> we can document the reasoning in the bug if we decide one way or an other
<juliank> rbalint: ack
<kanashiro> cpaelzer: ok, I can take a look at devscripts
<seb128> rbalint, xnox, juliank, if we really default to performance now that seems like an important regression and worth fixing now while we figure out the right way to do that if we prefer to change
<juliank> yes
<rbalint> there is quite a bit of history here: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=65f46a7d14b335e5743350dbbc5b5ef1e72826f7
<rbalint> seb128, server and cloud is the highest priority for Ubuntu and ubuntu-desktop can pull in something to override the governor
<rbalint> seb128, if you don't have desktop you are probably not sitting next to the system, so noise is not an issue :-)
<seb128> rbalint, earth thanks human for such way of thinking right?
<rbalint> seb128, earth won't thank you if you buy one more server because 10 was not fast enough either
<rbalint> seb128, please check the bugs referenced in ddstreet's commit and possibly the new one and make your point in the new one
<rbalint> seb128, we should flip again only after we carefully explored the topic (again) and found that flipping is the right thing to do
<seb128> rbalint, sorry, we had our meeting at the same time
<seb128> rbalint, ddstreet, Wimpress I guess my main issue there is that the change was neither discussed/announced on devel or discourse nor anyone did reach out to other team to tell them they need to update their product if they wanted to keep the behaviour
<seb128> that's not how changes with a such impact should be handled
<rbalint> seb128, the change is only in devel (groovy) and arrived with a merge from Debian, we are well in time to handle it, no panic is needed
<seb128> rbalint, I'm not panicing, don't worry :)
<rbalint> seb128, on my scale, you do :-)
<seb128> rbalint, sorry, I just don't like having those topic coming just because someone did notice and raised it there, ideally such changes should be announced before upload / at upload time and discussed with the impacted flavors
<seb128> (you can tell me that was about to happen but I somewhat doubt it was)
<juliank> rbalint: I don't think this has been analysed carefully
<juliank> rbalint: Most of the bug comments are unrelated musings about pstate vs other solutions
<rbalint> juliank, ok, please open the LP bug and have a careful analysis there because only very few people look at irc logs
<juliank> rbalint: Like why is the bug 1806012 discussing pstate vs other drivers, when the bug report was about toggling the pstate governor from powersave to performance, it does not make much semse
<ubottu> bug 1806012 in systemd (Ubuntu Disco) "set-cpufreq: 'powersave' governor configuration sanity on ubuntu server" [Medium,Won't fix] https://launchpad.net/bugs/1806012
<rbalint> juliank, i don't know, i have not touched that bug, but i'll be happy to participate in the discussion in a new one
<rbalint> i think the default is better to be controlled by kernel, it can be ondemand and custom cloud kernels can switch it to performance
<sil2100> Looking at the migration of orcania and yder
<rbalint> but more on it in the bug, we have enough time to resolve situation in this cycle
<kanashiro> cpaelzer: re devscripts: version 2.20.4ubuntu1 migrated to the release pocket hours ago. At the moment, devscripts recommends pristine-tar, you mean we should downgrade it to suggests?
<juliank> rbalint: seb128 I reported bug 1885730 to track the ondemand stuff, at least the pstate stuff, I also subscribed desktop and server so both sides (so to speak) can give feedback
<ubottu> bug 1885730 in systemd (Ubuntu) "Bring back ondemand.service or switch kernel default governor for pstate - pstate now defaults to performance governor" [Undecided,New] https://launchpad.net/bugs/1885730
<seb128> juliank, thanks
<juliank> I also add a linux task for kernel team so we can look at why our default is performance in the kernel
<rbalint> juliank, thanks, i was about to do that, too
<cpaelzer> kanashiro: it is a current component mismatch
<cpaelzer> kanashiro: and I don't see anyone pulling in all the dependencies of it - see https://people.canonical.com/~ubuntu-archive/component-mismatches.svg
<bdmurray> xnox: I'm trying to sort out the ubuntu-release-upgrader autopkgtest failure and could use some help. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/u/ubuntu-release-upgrader/20200625_034545_a8ed9@/log.gz
<bdmurray> the call to apt-key verify for the xenial dist-upgrader is failing
<xnox> bdmurray:  groovy has removed 2012 key, and only trusts 2018 key. To verity xenial, from groovy, one may not use "just" apt-key with trusted.gpg/trusted.gpg.d keyrings, one has to use /usr/share/keyrings/ubuntu-archive-keyring.gpg
<xnox> bdmurray:  why do you care to verify that groovy can "dist-upgrade?" to xenial?
<xnox> bdmurray:  this is similar to when we removed the old 2004/2008 keys, in xenial. and then stopped dual signing.
<bdmurray> xnox: its testing an upgrade from trusty to xenial and I'm still curious why its broken and setting apt-key "Dir::Etc::Trusted" doesn't seem to work
<xnox> bdmurray:  ubuntu-keyring in groove _removed_ _all_ keys from trusted.gpg* that are used to sign xenial.
<xnox> bdmurray:  to test upgrade from trusty to xenial, you must have trusty's trusted.gpg* somewhere, and use those for the upgrade. I.e. by creating a small apt DIR with the right files.
<bdmurray> xnox: I get that and have added an old key with which I can manually verify using 'apt-file --key'
<xnox> bdmurray:  which key did you add, and where?
<xnox> where is the source code?
<xnox> there is $ apt-config dump | grep trust
<xnox> Dir::Etc::trusted "trusted.gpg";
<xnox> Dir::Etc::trustedparts "trusted.gpg.d";
<xnox> which are relative Dir::Etc "etc/apt";
<xnox> which is relative Dir "/";
<bdmurray>         #apt_pkg.config.set("Dir::Etc::Trusted",
<bdmurray>         #                   "%s/ubuntu-keyring-2012-archive.gpg" % self.testdir)
<xnox> normally, one creates custom Dir, and have things inside it.
<bdmurray> right the above didn't work
<xnox> bdmurray:  but what does Dir::Etc and Dir set to? cause it might be looking up /etc/apt/testdirname-inside-ubuntu-release-upgrader/ubuntu-keyring-2012-archive.gpg
<xnox> bdmurray:  it's best to create "trusty-apt-dir" with like etc/apt/trusted.gpg.d/ubuntu-keyring-2012-archive.gpg
<xnox> bdmurray:  nad set Dir option to absolute/path/to/trusty-apt-dir
<bdmurray> '/tmp/autopkgtest.GBtKE7/build.SIJ/src/tests/data-sources-list-test//ubuntu-keyring-2012-archive.gpg'
<xnox> bdmurray:  apt-config dump is useful to figure out what everything is set to.
<xnox> bdmurray:  close enough, but ti's relative the build dir, which is not relative the source dir. thus i guess that filepath does not exist?!
<bdmurray> that's from 'apt_pkg.config.get("Dir::Etc::Trusted") right before the verify call
<bdmurray> I'm in an autopkgtest --shell-fail environment
<xnox> ok
<xnox> and where is ubuntu-keyring-2012-archive.gpg ?
<xnox> can you do find/mlocate/locate/whatnot to find it?
<xnox> cause => /tmp/autopkgtest.GBtKE7/build.SIJ/ is that ADTMPT? or where the sources are unpacked? or like were copied to?
<bdmurray> ubuntu@autopkgtest:~$ file /tmp/autopkgtest.GBtKE7/build.SIJ/src/tests/data-sources-list-test//ubuntu-keyring-2012-archive.gpg
<bdmurray> /tmp/autopkgtest.GBtKE7/build.SIJ/src/tests/data-sources-list-test//ubuntu-keyring-2012-archive.gpg: PGP/GPG key public ring (v4) created Fri
<bdmurray>  May 11 14:15:36 2012 RSA (Encrypt or Sign) 4096 bits MPI=0xdf88bd4a3451d3e0...
<bdmurray> its right where it belongs
<xnox> that's good.
<xnox> $ gpg --no-default-keyring --keyring /usr/share/keyrings/ubuntu-archive-keyring.gpg  --verify ./xenial.tar.gz.gpg ./xenial.tar.gz
<xnox> gpg: Signature made Sat 16 Apr 2016 17:33:59 BST
<xnox> gpg:                using DSA key 40976EAF437D05B5
<xnox> gpg: Can't check signature: No public key
 * xnox ponders what the xenial upgrade tarballs are signed with
<bdmurray> xnox: use the the one from -updates
<xnox> oh, good point
<bdmurray> I know because I ran into that too. ;-)
<xnox> and what does the test use? release or updates?
<bdmurray> updates
<bdmurray> because that is what is in all the meta-release files
<xnox> bdmurray:  is the xenial.tar.gz somewhere?
<xnox> or it got removed?
<bdmurray> http://archive.ubuntu.com/ubuntu/dists/xenial-updates/main/dist-upgrader-all/current/
<xnox> i mean inside autopkgtest --fail-shell
<bdmurray> They have the same name but different content
<xnox> / test run
<bdmurray> its gets downloaded to a tempdir and removed
<bdmurray> also this passes
<bdmurray> "keyring = apt_pkg.config.get("Dir::Etc::Trusted")"
<xnox> bdmurray:  btw, instead of copying a snippet, you can access old keys in /usr/share/keyrings
<xnox> bdmurray:  https://paste.ubuntu.com/p/Z6VS47rbgV/
<xnox> seems to work for me
<xnox> bdmurray:  we used to ship keys in /etc/apt/trusted.gpg, then switched to /etc/apt/trusted.gpg.d frabments, and like pretty much deprecate apt-key usage directly.
<xnox> bdmurray:  however /usr/share/keyrings/ubuntu-archive-keyring.gpg remains unchanged.
<xnox> and has keys for the active series, and has the 2012 key even in groovy, because xenial is still alive.
<xnox> so above code is correct on any series.
<bdmurray> xnox: hmm okay, it still seems like something is wrong with setting "Dir::Etc::Trusted" but I'll submit a bug or something
<vorlon> Laney: +1 on having lxd, +0 on "modern ben" :)
<Laney> one which gets the levels right would be appreciated
<vorlon> oh is there one of those now?
<vorlon> then yes that interests me
<Laney> but +1 on the former is enough for me to file a ticket
<Laney> well, aiui yes
<vorlon> (I still don't /like/ the transition tracker, but as long as others are going to use it, I'd rather it not mislead them)
<bdmurray> xnox: Do you want me to upload that?
<xnox> bdmurray:  yes please.
<xnox> bdmurray:  i don't trust apt-key much =) and i have had pain using Dir:: options before too
<bdmurray> rafaeldtinoco: regarding the SRU for bug 1680224, why is "d/p/lp1680224-fix-and-double-quoting-in-auto_smb.patch" not included?
<ubottu> bug 1680224 in autofs (Ubuntu Focal) "auto.smb fails on Windows administrative shares" [Medium,Confirmed] https://launchpad.net/bugs/1680224
<rafaeldtinoco> bdmurray: we thought the & fix wasnt feasible as SRU
<rafaeldtinoco> ahasenack and I is "we"
<rafaeldtinoco> it isn't upstreamed yet (opened to discussion in mailing list)
<rafaeldtinoco> and original bug was about admin shares (with $) only
<rafaeldtinoco> so we thought about being conservative for & one
<bdmurray> rafaeldtinoco: the groovy changelog reads like that patch is also for the same bug
<rafaeldtinoco> its the same root cause perhaps
<rafaeldtinoco> not the original reporter intent though
<rafaeldtinoco> so I guess its okay as the discussion is all there
<rafaeldtinoco> and both issues come from the same place (smb.auto)
<rafaeldtinoco> auto.smb
<bdmurray> rafaeldtinoco: what do you mean by "I guess its okay"? do you want to redo the upload?
<rafaeldtinoco> bdmurray: https://bugs.launchpad.net/ubuntu/+source/autofs/+bug/1680224/comments/29
<ubottu> Launchpad bug 1680224 in autofs (Ubuntu Focal) "auto.smb fails on Windows administrative shares" [Medium,Confirmed]
<rafaeldtinoco> summarizes the situation
<rafaeldtinoco> its okay to have LP for both patches
<rafaeldtinoco> we opted to have the & fix only for groovy
<rafaeldtinoco> and fix the $ as SRU
<bdmurray> okay, if you decided to SRU the & fix then that'll require a new bug report
<rafaeldtinoco> no problem! I'll put a comment in that bug mentioning that
<rafaeldtinoco> bdmurray: added a comment and, if we ever decide to SRU & fix Ill open a new bug and refer to this one
<rafaeldtinoco> thanks
<mwhudson> kanashiro: argh i keep failing to get around to looking into that
<mwhudson> kanashiro: yes, that debdiff is fine for now
<kanashiro> mwhudson: thanks for taking a look at it. I will start to work on containerd 1.3.5 soon and try to follow what tianon suggested on the github issue regarding the library package
<mwhudson> kanashiro: heh they released 1.3.6 already but yes
<kanashiro> mwhudson: really?! So it will be 1.3.6 :)
<mwhudson> kanashiro: i think it's some trivial ci fix
<bdmurray> vorlon: How can I get my autopkgtest-cloud changes for scipy deployed?
<bdmurray> jibel: Did you see that bug 1856574 was reopened?
<ubottu> bug 1856574 in autopilot-gtk (Ubuntu) "removal of various autopilot packages" [High,Triaged] https://launchpad.net/bugs/1856574
<vorlon> bdmurray: scipy> is there an MP link I missed?
<bdmurray> vorlon: No, I just committed it. https://git.launchpad.net/autopkgtest-cloud/commit/?id=fc21a96fffc7cfac43c23150440d2a9b64c6518d
<vorlon> bdmurray: ah
<vorlon> bdmurray: it doesn't appear you are in the group for infra access despite having commit access, so I'll deploy it now
<vorlon> bdmurray: (done, you can retry the tests now)
<bdmurray> vorlon: thanks!
#ubuntu-devel 2020-07-01
<jibel> bdmurray, no I didn't
<LocutusOfBorg> thanks kanashiro cpaelzer for doing ti!
<LocutusOfBorg> *it
<cpaelzer> yw LocutusOfBorg
<kanashiro> LocutusOfBorg: o/ you're welcome
<LocutusOfBorg> mitya57, https://launchpad.net/ubuntu/+source/pyside2/5.15.0-2 please? :) (arm64 fails)
<LocutusOfBorg> can you please have a look?
<realtime-neil-> How does one build the ubuntu installer? https://wiki.ubuntu.com/Installer/Development talks about checking out source, but not how to build it. Compare/contrast  https://wiki.debian.org/DebianInstaller/Build
<juliank> realtime-neil-: which installer, I guess is the first question
<juliank> We have the old d-i / classic server, subiquity (the server installer), curtin (the backend behind subiquity amongst others), and ubiquity (the desktop installer)
<juliank> I guess there might be one or two more
<juliank> e.g. image based things like rpi get configured on first boot, and don't really have an installer
<Unit193> calamares too!
<juliank> well, calamares is not an ubuntu installer
<juliank> i guess a flavour uses it?
<Unit193> I thought Lubuntu did.
<juliank> i don't know, I'm just talking about insallers in main :)
<Unit193> And as a non-coredev, I don't care about main. :P
<Unit193> ...Except for when popcon has been broken since bionic, that's....fun.
<mitya57> LocutusOfBorg: argh
<mitya57> I don't have Ubuntu arm64 hardware so I can't even check what's the difference from Debian
<realtime-neil-> juliank, the old d-i one
<mitya57> LocutusOfBorg: ideally we need some glibc expert to fix this properly (what I did is just a workaround).
<LocutusOfBorg> blacklist again?
<mitya57> LocutusOfBorg: maybe, but that will only fix build, and it will be still impossible to use PySide2.QtWebEngine on arm64.
<mitya57> The real bug cannot be fixed in pyside2 itself: it also happens with pyqt5 and even with pure Python+ctypes code.
<mitya57> I already contacted glibc and mesa maintainers (in Debian) but got no replyâ¦ Maybe I should ask on debian-arm.
<LocutusOfBorg> jamespage, I uploaded the openstack-pkg-tools merge without the --subunit drop. Do you think its still needed?
<LocutusOfBorg> I'm upstreaming the Ubuntu delta to debian, and they don't see any reason to not use subunit
<LocutusOfBorg> coreycb, I'm syncing python-amqp, used for new kombu
<coreycb> LocutusOfBorg: sounds good, thank you
<bdmurray> xnox: Do you have any hints on how to recreate bug 1874953? I tried an upgrade from E to F and got a conffile prompt but my pager worked for me
<ubottu> bug 1874953 in less (Ubuntu Focal) "dpkg: conffile difference visualizer subprocess returned error exit status 127" [Critical,Triaged] https://launchpad.net/bugs/1874953
<xnox> bdmurray:  one has to install with split-usr, so install xenial upgrade to focal.
<xnox> bdmurray:  and the debconf prompt should be quite early, after less is upgraded, and in the same transaction.
<bdmurray> xnox: alright, that'll be a fun slog
<xnox> yes, sorry
<xnox> bdmurray:  usr-merged systems are unaffected.
<kanashiro> mwhudson: I was checking golang-github-miekg-dns and I was wondering if you do not want to submit the changes you proposed here in a PR: https://github.com/miekg/dns/issues/1129#issuecomment-648560142
<kanashiro> it might be easier to collect feedback from upstream
<mwhudson> kanashiro: i was hoping to get some feedback but yeah, maybe making that into a PR makes sense
<mwhudson> kanashiro: https://github.com/miekg/dns/pull/1130
<kanashiro> mwhudson: many thanks :)
#ubuntu-devel 2020-07-02
<RikMills> jibel: is a fix for LP: #1885414 likely to land soonish? I got new Plasma into groovy the other day, and some testers are being a bit blocked by that
<ubottu> Launchpad bug 1885414 in ubiquity (Ubuntu) "ubiquity: bootloader failed on /dev/vda" [Critical,Triaged] https://launchpad.net/bugs/1885414
<mantas-baltix> Hi, I need your advice for choosing metapackage creation technology - I'm developing Ubuntu-based distribution for schools and previously used simply repackaged ubuntu-meta as base, see https://bazaar.launchpad.net/~baltix-members/baltix-seeds/baltix-meta-packages/files
<mantas-baltix> but this way isn't effective - it seems Debian uses Tasksel-based Blends metapackages, see https://blends.debian.org/blends/apa.html#blends-dev and Ubuntu uses "Seeds"
<mantas-baltix> like https://code.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/+git/ubuntustudio
<mantas-baltix> I don't know which is better for long-term (at least 4-5 years) , it seems metapackages created with blends-dev depends on tasksel, while Ubuntu "Seeds" don't depend on tasksel and are easier to understand, see for example https://git.launchpad.net/~ubuntustudio-dev/ubuntu-seeds/+git/ubuntustudio/tree/desktop
<jibel> RikMills, once https://code.launchpad.net/~mwhudson/ubiquity/+git/ubiquity/+merge/386704 is merged and released
<juliank> mantas-baltix: So you've got your own seed like thing already, I'm not sure where full blown seeds would help you? what problem are you trying to solve?
<juliank> anyway, seeds might be the way to go
<juliank> personally i find germinate overkill for my use cases in metapackage building
<mantas-baltix> juliank: my thing is very hard to maintain, because I have separate files for depends and recommends and symlinks for different architectures :(
<juliank> I see
<juliank> I never implemented Recommends for my metapackage generator
<mantas-baltix> juliank: I never used germinate, could you point to some documentation?
<juliank> mantas-baltix: e.g. https://wiki.ubuntu.com/Germinate, https://manpages.ubuntu.com/manpages/cosmic/man1/germinate.1.html
<juliank> mantas-baltix: germinate is what reads the files, checks them for consistency, and outputs the substvars for debian packages, amongst other things
<juliank> (it can also like fully expand the seed, which in turns determines which packages end up in the live images)
<mantas-baltix> juliank: it seems Tasksel-based Blends metapackages, see https://blends.debian.org/blends/apa.html#blends-dev does the same but in different way :)
<mantas-baltix> cjwatson: hi, it seems you are germinate developer, could you advice me if I should use Tasksel-based Blends for custom ubuntu-based distribution metapackages (see https://blends.debian.org/blends/apa.html#blends-dev) or Germinate and "Seeds" ? ;)
<cjwatson> mantas-baltix: False dichotomy.  Seeds are in fact used to generate tasks in Ubuntu as well
<cjwatson> So they can be an input to tasksel
<cjwatson> mantas-baltix: Anyway, I have no experience with blends so can't advise you
<mantas-baltix> cjwatson: thanks, maybe you can tell if there are some plans to use blends in Ubuntu or metapackages will use only seeds in near future?
<cjwatson> mantas-baltix: although I maintain the germinate package, I haven't otherwise been involved in that sort of thing in Ubuntu for five years
<cjwatson> mantas-baltix: I'm pretty sure there are no plans to use blends.  Otherwise I couldn't tell you
<rbalint> kanashiro, doko happy +1 day, what are you working on and what is free to grab on update-excuses?
<rbalint> i'm going through the small stuck sets then will pick a big transition, so suggestions will be welcome
<doko> rbalint, kanashiro: working mostly from the bottom up on ftbfs
<rbalint> doko, kanashiro i'm finishing the small orcania transition
<AsciiWolf> kenvandine, hi, I am not sure if you are the one who is working on this bug or Robert is: https://bugs.launchpad.net/snap-store-desktop/+bug/1873040 - anyway, please let me know if there is anything I could do (test, debug, provide additional info etc.) to help getting this annoying bug fixed... :)
<ubottu> Launchpad bug 1873040 in snap-store-desktop "Source for deb apps in dropdown menu is empty" [High,Confirmed]
<AsciiWolf> some regular users that I recommended Ubuntu 20.04 to were already asking me how to install non-snap apps because they did not realize that the empty space is actually clickable :/
<ahasenack> good morning
<kanashiro> rbalint: doko I intend to finish my work on all ruby packages in proposed today. If I have time I'd like to start to work on some prometheus deps (golang packages)
<kanashiro> I'll keep you posted about the status here
<kanashiro> haskell packages need some love, hopefully I'll find some time until tomorrow to work on some of them
<mantas-baltix> AsciiWolf: hi, could you confirm if Snap Store launcher isn't translated in any language, see gug #1882929
<mantas-baltix> AsciiWolf: bug #1882929
<ubottu> bug 1882929 in snap-store-desktop "Ubuntu Software (Snap Store) desktop launcher Name isn't translated in Ubuntu 20.04" [Undecided,New] https://launchpad.net/bugs/1882929
<AsciiWolf> mantas-baltix, hmm, to be honest, I am not aware of this issue... I can't speak for other translations, but in our Czech translation, the "Ubuntu Software" and "Snap Store" strings are intentionally left in the original, untranslated, form :)
<kanashiro> mwhudson: as you should have noticed your golang-github-miekg-dns PR was accepted upstream, if you want I can prepare an upload with the patch. Please let me know
<ahasenack> go for it? He will only be online at our EOD
<kanashiro> I can but I also have other stuff to do, idk if he wants to handle this by himself
<mitya57> LocutusOfBorg: I filed Debian #964141 now, let's see what the glibc maintainers think about it.
<ubottu> Debian bug 964141 in libc6 "libc6: "cannot allocate memory in static TLS block" with some library combinations on arm64" [Normal,Open] http://bugs.debian.org/964141
<kanashiro> it's in my TODO list anyway
<LocutusOfBorg> thanks!!!
<realtime-neil> Is there a way to `apt --reinstall install` a package without re-downloading it? `--no-download` doesn't work.
<sarnold> popey: hmm -- I'm trying to use the matterhorn 'view' thing to view attachments and getting unexpected DENIED messages -- this worked yesterday? http://paste.ubuntu.com/p/NDfcbdJT6z/plain/
<sarnold> realtime-neil: if the package actually does exist in /var/cache/apt/archives, that sounds like a bug
<realtime-neil> sarnold, that sounds accurate
<xnox> realtime-neil:  are you sure it's the same? and has the same checksum/metadata etc?
<xnox> realtime-neil:  you can do $ sudo apt install --reinstall ./packages_*.deb
<xnox> with absolute path to the .deb, or like with './' prefix.
<realtime-neil> xnox, the problem I'm having is that, after the initial installation there is a process beyond my control that deletes the Debian archive from the apt cache.
<realtime-neil> Some nice folks in #debian have led me to believe that, once the archive is gone, it's impossible to reinstall without downloading again
<cjwatson> realtime-neil: that belief is correct
<cjwatson> It's not uncommon for things to run 'apt clean' or 'apt autoclean' or similar automatically on the basis that there's a very small amount of point in leaving large files around on the off-chance somebody might want to reinstall from them
<cjwatson> But if the files in question are still in the cache then IIRC they shouldn't be redownloaded
<realtime-neil> cjwatson, makes sense; my particular context is in the ubuntu installer --- after `pkgsel/include` does its thing, my package is very slightly broken. A reinstall fixes it, but by the time the `preseed/late_command` fires, the installer has already cleaned the cache.
<realtime-neil> cjwatson, you wouldn't happen to be this author, would you? https://wiki.ubuntu.com/Installer/Development
<cjwatson> Yes but I haven't worked on the installer for years
<cjwatson> So not likely to be much use to you now
<realtime-neil> If you remember anything about the patching debian-installer and/or the build process, I'd appreciate any words you can offer.
<cjwatson> I don't recall where there might be a clean call, but it should be visible somewhere ...
<cjwatson> This is a bit of a vague problem for me to page in memory of at 8pm I'm afraid
<cjwatson> Maybe tomorrow if you have more details and logs
<realtime-neil> I can accept the double download ... my overarching issue is that I don't know how to build the ubuntu installer
<realtime-neil> Or, really, how it differs from d-i
<xnox> realtime-neil:  there is a newish apt option to retain downloaded .debs and not delete them.
<xnox> realtime-neil: you can use that
<xnox> rafaeldtinoco:  when you say "ubuntu installer" => it is ambigious, as we have many.
<xnox> rafaeldtinoco:  unping
 * rafaeldtinoco hides
<xnox> realtime-neil:  and most of them use combination of preinstalled squashfs + pool of debs. With base system bootstraped, and no debs for those available during the install.
<xnox> realtime-neil:  which package are you trying to reinstall?
<xnox> realtime-neil:  i want to put a banner "obsolete" on https://wiki.ubuntu.com/Installer/Development
<tumbleweed> realtime-neil: you say "your package is very slightly broken" - best option is probably to fix it
<realtime-neil> xnox, I'm asking specifically about the d-i installer ... the one I can use to make installation media
<realtime-neil> well, I guess all of them can do that, but I'm interested in USB sticks to start
<realtime-neil> xnox, yeah, that page seems a little dated
<realtime-neil> tumbleweed, yes, I'm still trying to figure out how to fix a project that is broken when installed without grub
<sarnold> popey: oh. It was snap autorefresh :(
<kanashiro> I have been facing a ruby-http autopkgtest failure in s390x which seems that the testbed is broken, however, I re-triggered it a couple of times and it is still failing. Could someone give me any tip on how to fix this? https://autopkgtest.ubuntu.com/packages/ruby-http/groovy/s390x
<kanashiro> it is passing in the other architectures
<realtime-neil> kanashiro, I must know: where did you get that s390x system?
<kanashiro> realtime-neil: it is the Ubuntu autopkgtest infrastructure. The failure does not represent a real issue in s390x, it should be something related to the testbed setup I think
<cjwatson> realtime-neil: (I will defer to xnox who has spent a lot more time with the installer lately than I have)
<realtime-neil> cjwatson, 10-4; xnox is there any documentation you can point me at?
<xnox> realtime-neil:  i don't know what you are trying to do.
<xnox> so it's hard to help =)
<xnox> realtime-neil:  what is you project, and goal?
<realtime-neil> xnox, I want to remaster Ubuntu installers and make custom images for netinst and hd-media
<realtime-neil> debian has this https://wiki.debian.org/DebianInstaller/Build ... I'm wondering if Ubuntu has something similar
<xnox> realtime-neil:  which architectures are you planning to install on to? is it VMs or bare-metal? why remaster -> what do you want to include in them, and from where?
<xnox> is it going to be deployed with or without network access?
<xnox> realtime-neil:  note that vast majority of installations today do not use d-i, but use ubiquity-desktop isos, subiquity live-server isos, or the cloud-images that are booted in place, and self-customize on first boot => but also all of those can be booted over the network & locally.
<realtime-neil> arches: amd64 certainly, maybe armv7 in the distant future; UEFI firmware platforms, both virtualized and metal; remastered because I want to add packages gotten from private repositories; netinst images require network, but hd-media should avoid network
<xnox> realtime-neil:  and our .iso by default support airgapped deployment. I.e. without internet access.
<xnox> realtime-neil:  ack. sounds reasonable.
<realtime-neil> excellent
<xnox> armv7 has no boot protocol however => and we do not provide media for it, only preinstalled images for select targets
<realtime-neil> that's fine, i figured as much -- I'm not going to hold my breath waiting for UEFI on arm-anything
<xnox> realtime-neil:  if i were you, i'd prepare an offline pool of debs, write it as append track to existing .iso, and then boot it with extra paramemeters on the cmdline to enable that additional repository.
<xnox> realtime-neil:  we have multiple public clouds, server grade hardware and iot devices with ARM and UEFI.
<xnox> realtime-neil:  i.e. packet cloud, AWS Graviton instances, pi4 with uefi firmware flashed, etc.
<xnox> all enabled for ubuntu
<realtime-neil> xnox, I'll take that advice. Just for the sake of argument, how would I create images (including isos) from source?
<xnox> realtime-neil:  we build images from binaries, from debs.
<realtime-neil> xnox, granted, I'm talking about the initramfs contents that drive the installation
<xnox> realtime-neil:  the d-i artefacts, one can rebuild, with $ pull-lp-source debian-installer focal; sbuild -A -d focal ./debian-installer*.dsc
<xnox> is how the initrd, inside the /installer-*/ directories are built.
<xnox> realtime-neil:  it would produce the same layout, in a tarball.
<xnox> realtime-neil:  why do you need to modify the initrd?
<xnox> realtime-neil:  one can enable, extra local, repositories, keys, and install .udebs or .debs, from it, _without_ changing the initrd.
<realtime-neil> just in case I have to track down some dirty module
<xnox> realtime-neil:  i cannot help, if you don't tell me what you want to do. and things i say, may be misused, as you are not sharing context.
<realtime-neil> ah, okay, understood; I'll leave the initrd alone.
<xnox> realtime-neil:  the initrd itself, has very little things. most things are installed from udebs dynamically after the initrd has found a way to fetch udebs (from internet or from local locations)
<xnox> realtime-neil:  and inside debian-installer there is LOCAL_UDEBS, and config files, if you must replace things in the initrd. But it's unlikely that you do.
<xnox> having custom pool, and enough apt-source/* things specified via backed-in preseed on the cmdline should be enough to force the installer to always use your extra pool, for things.
<xnox> (both udebs during d-i, and debs for in-target)
<xnox> realtime-neil:  note, you don't need to rebuild initrd to append preseed to it, as initrds are appendable.
<realtime-neil> understood ... this all great stuff ... is there no documentation for this?
<xnox> realtime-neil:  do not modify shim, grub, kernel, kernel modules => if you want to boot with secureboot on UEFI firmware. If you don't care about secureboot, anything goes.
<xnox> realtime-neil:  we have removed documentation, as focal is the last release that ships with d-i.
<xnox> realtime-neil:  and the server guide is updated, on how to netboot the new installer, or boot in place, and it is mostly driven by cloud-init to customize on first boot.
<realtime-neil> xnox, ouch. so the successor is documented in the server guide?
<xnox> with a simply yaml autoinstall preseeds, that allow to declaratively install servers.
<xnox> and there is any cloud-init to e.g. enable local/custom, or remote repositories, install things from there.
<xnox> realtime-neil:  the nice thing about the new installer, is that it is just a cloud-image repacked as netbootable or local .iso. And everything is build from debs, without any .udebs
<xnox> realtime-neil:  meaning it's a live server environment with regular cloud-init / apt / ssh all working, during live-session, and post install.
<realtime-neil> xnox, where can I learn everything about this new mechanism? Which releases does it support?
<xnox> realtime-neil:  https://ubuntu.com/server/docs see installation in the overview, and the detailed installer sections.
<xnox> realtime-neil:  bionic and focal, that is 18.04 and 20.04
<realtime-neil> I picked the wrong release to start with a d-i preseed :D
<xnox> realtime-neil:  which one did you pick?
<realtime-neil> I've been following the debian d-i documentation and trying to adapt it to bionic
<realtime-neil> This may have been a colossal waste of time.
<xnox> realtime-neil:  less than 5% of ubuntu installs use d-i. The vast majority use preinstalled ubuntu server images, that are booted in place (or like initrd+kernel booted over the network, to them do remote root to again boot in place) and self customize on first boot with cloud-init.
<xnox> why customize installer, install, and reboot. When one can use stock images to boot, straight away, and apply necessory customization on first boot.
<xnox> and like for IoT stuff, mostly people use Ubuntu Core to use one of the hundreds existing models, to add custom snaps, and boom you have your product enabled on any armhf/IoT boards.
<realtime-neil> A. Because I was completely ignorant of this. Better late than never, I guess.
<xnox> including private/custom/propietary snaps.
<xnox> like all of the ROS things are build on top of snaps with Ubuntu Core without any installers at all.
<xnox> realtime-neil:  debian, doesn't build as many custom, target/platform specific, presintalled images as we do.
<realtime-neil> Don't the snaps use containers or something?
<xnox> realtime-neil:  no
<xnox> realtime-neil:  the run on bare-metal....
<xnox> they use a lot of kernel features to do so securely, with strict upgrade / isolation, but there are no hypervisors/docker/k8s or similar invovled.
<xnox> i.e. they use AppArmor, seccomp filters, firewalls, signature checking, etc.
<realtime-neil> in my limited experience, playing with dkms modules inside of that kind of isolation doesn't work very well.
<xnox> Ubuntu Core has kernel as a snap. Why do dkms builds on target, when you can prebuild a kernel snap, with all the dkms modules you want once, and just deploy it.
<xnox> i.e. ubuntu-image can be trivally be used to rebuild any ubuntu-core image, with a tweaked kernel snap.
<realtime-neil> You make have just sold me on this.
<realtime-neil> You may have just sold me on this.
<xnox> and one can even skip rebuilding kernel snap from scratch and append a kernel module to it.
<xnox> realtime-neil:  maybe you should join #snappy channel and like talk to ogra who build a lot of custom things.
<xnox> realtime-neil:  for ROS, robots / kioks / smart screens, etc.
<realtime-neil> Just when I thought I was getting good with dpkg-buildpackage, everything changes. XD
<xnox> realtime-neil:  https://snapcraft.io/ https://snapcraft.io/docs https://forum.snapcraft.io/
<xnox> realtime-neil: ultimately, if one is building a product, one wants to be able to have reproducible images, that are easy to build, have stock components reused (i.e. core, snaps, gadget to boot the thing, etc) have extra stuff on top (i.e. a snap, that reuses ROS snapcraft plugin, and adds one more thing), and be able to quickly build images for any model, and deploy them in a reproducible manner.
<xnox> with quick, boot in place, self-configure / initialize.
<xnox> and snapcraft / ubuntu-image tooling deliver all of that. such that one can focus just on customization, whilst reusing "common" platform for the rest. (pick & mix)
<xnox> or like derive from it, by staging existing component, and patching it as needed.
<realtime-neil> I'm coming from a hard-core Debian packaging assumption --- control files, maintscripts, etc. --- what kind of learning curve can I expect with this new methodology? How many weeks until I'm good enough to be dangerous?
<xnox> realtime-neil:  there are shit tone of examples, which are simplier to modify or write your own.
<xnox> realtime-neil:  unlike debian packaging, it's mostly just a single snapcraft.yaml file per component you try to modify. Possibly gadget.yaml and a model. So learn a 4 files, and build them. and at that point one is dangerous.
<realtime-neil> xnox, this is going to change everything; thanks very much.
<xnox> realtime-neil:  i think we have a lot of recorded snapcraft webinars pre-recorded, and tutotrials / docs. I think people manage to build a custom ROS image, as a workshop in less than 5h as a tutorial / classroom thing?
<xnox> realtime-neil:  maybe Wimpress has some links for you. Cause we ran contests for those sort of things too.
<xnox> as fun/hack events
<xnox> realtime-neil:  https://snapcraft.io/blog/your-first-robot-a-beginners-guide-to-ros-and-ubuntu-core-1-5 ?
<xnox> there is alot on https://ubuntu.com/robotics
<realtime-neil> xnox, I'm noticing a tangible emphasis on ROS --- do you work with robots?
<xnox> it seems popular.
<xnox> but there are other things too, non-robotic.
<xnox> realtime-neil:  https://ubuntu.com/appliance
<xnox> it's more about having purpose build things, on top of a common reliable core, that is trivially deployable to a variety of architecutres/forfacotrs.
<xnox> cause "what" "where" and "how" are all separated.
<xnox> realtime-neil:  for example, vendors often provide kernel snaps and gadgets, for others to build images with their "appplication snap" to deploy something.
<xnox> ROS mostly provides plugins/frameworks/parts which others embed inside their application snaps (aka middlewear/drivers/etc)
<xnox> realtime-neil:  i mostly build base snaps, which everyone bases their rootfs on. The 50-odd MB that everything operates on.
<ogra> realtime-neil, this is pretty old and very arm centric but should give you an idea https://ograblog.wordpress.com/2019/01/07/291/ ...
<ogra> (there are newer tutorials for each of the bits on snapcraft.iðdocs somewhere, but i'm not sure there is one document that summarizes the single bits like this post)
<ogra> *geez ... that emoji plugin ...*
<ogra> the docs category on snapcraft io
<realtime-neil> ogra, nice, thanks!
<ogra> and regarding ROS you probably want to talk to kyrofa ð
<mwhudson> kanashiro: happy for you to upload it, i'll do it in my +1 shift on monday if you don't get to it!
<kanashiro> mwhudson: good, I can do it tomorrow :)
<mwhudson> ugh why are libraries on arm64 built with ie tls-model?
<mwhudson> oh they're not but the surplus tls space gets used for gd libraries
<mwhudson> that seems bonkers
#ubuntu-devel 2020-07-03
<ricotz> hello, could someone take a look at freetype in groovy/proposed, it is missing a dep on libbrotli-dev
<ricotz> which causes failures like:  0:19.96 ERROR: Package 'libbrotlidec', required by 'freetype2', not found
<LocutusOfBorg> mitya57, FYI https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+sourcepub/11405805/+listing-archive-extra
<LocutusOfBorg> I'm testing the patch, lets see if it builds or not (your test program and pyside)
<mitya57> LocutusOfBorg: thanks! I didn't have time to do it :)
<Unit193> LocutusOfBorg: I've been meaning to ask, in Debian do you build changelogs as you go or gbp dch?
<mitya57> LocutusOfBorg: note that the patch already had some comments on glibc ML, which the author promised to fix (but didn't do yet)
<LocutusOfBorg> Unit193, gbp dch
<LocutusOfBorg> mitya57, not sure why, but on your example code on the glibc debian bug, if you load libsystemd, libglapi and then libavformat it works...
<mitya57> Yes, I noticed that too.
<mitya57> LocutusOfBorg: I even mentioned that in the bug report: "When swapping second and third blocks, it works fine."
<mitya57> But can't explain itâ¦ To be honest I even didn't find any TLS usage in libavformat code (i.e. __thread variables).
<LocutusOfBorg> mitya57, http://51.15.138.76/patch/37618/ ?
<LocutusOfBorg> lol I didn't read the whole bug then :p
<ricotz> LocutusOfBorg, hi :)
<ricotz> LocutusOfBorg, did you see my message above about freetype?
<LocutusOfBorg> nope...
<LocutusOfBorg> mapreri, ^^
<LocutusOfBorg> <ricotz> hello, could someone take a look at freetype in groovy/proposed, it is missing a dep on libbrotli-dev
<LocutusOfBorg> <ricotz> which causes failures like:  0:19.96 ERROR: Package 'libbrotlidec', required by 'freetype2', not found
<LocutusOfBorg> ricotz, in any case, Debian is having a ton of failures too, somebody will look at it for sure
<mitya57> LocutusOfBorg: ah, thanks for the link, v5 of that patch did not show up on the mailing list for some reason
<LocutusOfBorg> ricotz, <BTS> Opened #964185 (serious) in libfreetype6-dev 2.10.2+dfsg-1 by Mike Hommey <mh+reportbug@glandiu...> Â«freetype2.pc depends on libbrotlidec.pc without a dependency on the libbrotli-dev packageÂ». https://bugs.debian.org/964185
<ubottu> Debian bug 964185 in libfreetype6-dev "freetype2.pc depends on libbrotlidec.pc without a dependency on the libbrotli-dev package" [Serious,Open]
<LocutusOfBorg> I don't think just adding that dependency is ok to let the package migrate, e.g. cairo seems to suffer of something different
<mitya57> Ah, it did, just the title changed: https://sourceware.org/pipermail/libc-alpha/2020-June/115284.html
<ubottu> sourceware.org bug 2020 in translator "probe kernel audit hooks" [Normal,Resolved: wontfix]
<mitya57> No review for v5 yetâ¦
<LocutusOfBorg> I uploaded both in two different ppas
<mitya57> I think v5 (two patches) is enough, no need to test v4 anymore :)
<LocutusOfBorg> ack
<LocutusOfBorg> ricotz, fix uploaded
<ricotz> LocutusOfBorg, thanks for looking into it!
<LocutusOfBorg> mitya57, no error anymore
<LocutusOfBorg> with v4 patch
<ahasenack> good morning
<rafaeldtinoco> just as a fyi, im working in merging a new version of open-iscsi (already did in debian) => just so there isn't a duplicate of efforts if anyone thought about it
<rafaeldtinoco> now im working in debhelper postinst (etc) to guarantee things like iscsi root (and other delta we have) are working, and will suggest back to debian
<rbalint> kanashiro, have you got to the golang packages yet? i'd start from the bottom from update excuses
<kanashiro> rbalint: not yet but I'll do it this morning, I am just trying to finish a puppet merge which will fix the ruby-puppet-syntax FTBFS
<kanashiro> ruby-puppet-syntax is also at the bottom of update excuses page
<rbalint> kanashiro, how about i leave the golang packages around prometheus for you and work on the rest?
<kanashiro> rbalint: sure, I'll take care of prometheus deps anyway
<niub> o/
<niub> I'm having some issue trying to build edk2
<niub> I imported the source from this dsc https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/edk2/0~20191122.bd85bf54-2ubuntu3/edk2_0~20191122.bd85bf54-2ubuntu3.dsc
<niub> when I start the build it fails right away while patching (output here https://paste.ubuntu.com/p/pjwbPkHk3x/)
<niub> am I doing something wrong or one of the patches is dodgy?
<rbalint> niub, dget works ok, the patches are good enough for it
<rbalint> niub, probably the gbp import went wrong
<niub> rbalint mhh I'm using this command gbp import-dsc --pristine-tar -v https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/edk2/0~20191122.bd85bf54-2ubuntu3/edk2_0~20191122.bd85bf54-2ubuntu3.dsc
<niub> and it doesn't return any error
<niub> FTR: https://paste.ubuntu.com/p/r3Gh48h5sz/
<rbalint> niub,seems ok withoug pbuilder
<rbalint> without
<niub> Oo
<niub> rbalint which command are you using?
<LocutusOfBorg> niub, did you delete the .pc directory?
<kanashiro> ahasenack: cpaelzer seems unreachable from here, could you please take a quick look into my puppet MP?
<ahasenack> you promise it's quick? :D
<niub> LocutusOfBorg yes, the outcome doesn't change :\
<kanashiro> ahasenack: if you believe on what cpaelzer already did review, the changes are small :)
<ahasenack> kanashiro: this one? https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/puppet/+git/puppet/+merge/386777
<ahasenack> kanashiro: you need to fix the target, it should be debian/sid
<kanashiro> ahasenack: ah, yes, sorry :)
<kanashiro> ahasenack: fixed
<kanashiro> https://code.launchpad.net/~lucaskanashiro/ubuntu/+source/puppet/+git/puppet/+merge/386827
<LocutusOfBorg> niub, it would be nice to have a log of your build procedure
<LocutusOfBorg> e.g. mine is: gbp import-dsc --pristine-tar -v https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/edk2/0~20191122.bd85bf54-2ubuntu3/edk2_0~20191122.bd85bf54-2ubuntu3.dsc
<niub> LocutusOfBorg I'm doing:
<niub> 1. gbp import-dsc --pristine-tar -v https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/edk2/0~20191122.bd85bf54-2ubuntu3/edk2_0~20191122.bd85bf54-2ubuntu3.dsc
<niub> 2.  https://paste.ubuntu.com/p/pjwbPkHk3x/
<niub> pastebin contains also the output of that command
<LocutusOfBorg> niub, I don't see this line gbp:info: Creating /tmp/build/edk2_0~20191122.bd85bf54.orig.tar.xz
<LocutusOfBorg> can you please delete that file?
<LocutusOfBorg> it might have been wrongly created
<niub> LocutusOfBorg do you mean delete debian/gbp.conf ?
<LocutusOfBorg> no, delete edk2_0~20191122.bd85bf54.orig.tar.xz
<LocutusOfBorg> btw I use pbuilder, cowbuilder is somewhat old stuff :D
<LocutusOfBorg> pull-lp-source edk2 focal && pbuilder-dist focal build edk2_0~20191122.bd85bf54-2ubuntu3.dsc
<LocutusOfBorg> if you need to create it, pbuilder-dist focal create
<LocutusOfBorg> mitya57, https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/19541929
<LocutusOfBorg> pyside2 is fine
<niub> LocutusOfBorg so I cleaned up and started over, this is the output https://paste.ubuntu.com/p/vtWX76gVfc/
<niub> the error is still there
<ahasenack> kanashiro: that file was added a year ago? https://salsa.debian.org/puppet-team/puppet/-/blob/master/debian/puppet-master.NEWS
<ahasenack> and forgotten in -4? Poor file :)
<kanashiro> ahasenack: yeah :)
<kanashiro> that's what happen when people forget to git push their changes
<ahasenack> kanashiro: and 5.5.10-4 disappeared from d/changelog now in the merge?
<ahasenack> ah, it disappeared from debian too
<ahasenack> oh well
<kanashiro> yep
<niub> LocutusOfBorg so, it seems with 'pbuilder-dist focal build' the build works, however I need to build it with cowbuilder (jenkins I have uses that one :\)
<mantas-baltix> Hi
<mantas-baltix> is  ubuntu-defaults-image from ubuntu-defaults-builder still recommend tool for building a custom Ubuntu derivative from the command line?
<mantas-baltix> ubuntu-defaults-builder isn't updated since 2017 :(, see https://launchpad.net/ubuntu/+source/ubuntu-defaults-builder
<ahasenack> I don't know, I have never used it
<mantas-baltix> ahasenack, which tool do you use?
<ahasenack> I don't, sorry if that wasn't clear
<ahasenack> I just didn't want to leave you hanging without an answer, even if it wasn't one that would help you much
<mantas-baltix> :(
<mitya57> LocutusOfBorg: \o/ I will follow up on my bug
<mitya57> LocutusOfBorg: can you retry https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/costamagnagianfranco-ppa/+build/19541934 too?
<mantas-baltix> pitti, it seems you are developer of https://launchpad.net/ubuntu/+source/ubuntu-defaults-builder - could you tell where is the dev git branch?
#ubuntu-devel 2020-07-04
<LocutusOfBorg> mitya57, :) done
<mitya57> I see you already said that v5 works, but confirming it won't hurt :)
<LocutusOfBorg> it worked by installing on arm64 chroot and testing your main example
<LocutusOfBorg> but yes, I forgot to click retry
<LocutusOfBorg> now we *just* have to convince somebody to pick up that patch on the next glibc upload
<mitya57> LocutusOfBorg: another good idea will be pinging upstream about this. I can do that.
<LocutusOfBorg> mitya57, good that one too
<mitya57> doing right now
<mitya57> LocutusOfBorg: https://sourceware.org/bugzilla/show_bug.cgi?id=25051#c3
<ubottu> sourceware.org bug 25051 in dynamic-link "aarch64, powerpc64 uses surplus static tls for dynamically loaded dsos" [Normal,New]
<mitya57> Unfortunately Carlos is not on CC list of that bug, but I hope he still receives that comment
<LocutusOfBorg> mitya57, https://github.com/opencv/opencv/issues/14884
<LocutusOfBorg> searching for that error gives lots of stuff on github
<mitya57> LocutusOfBorg: I saw that, yes
