#ubuntu-devel 2005-07-11
<comadreja> I mean, I compiled the basic mplayer from sources without sv support
<comadreja> but then how could it be that dvd's can't be played ?
<daniels> it could be an mplayer bu
<daniels> g
<daniels> the only way to find out if mplayer is decoding it correctly is to not use xv
<comadreja> mplayer, xine, and totem...
<daniels> if you use x11, and that works, then it's decoding it correctly
<daniels> yes, a lot of them use common code for decoding stuff
<daniels> what you need to do, is find a video where, with the very same media player, plain x11 works, and xv fails
<comadreja> I see, then it's gotta be that
<comadreja> no, don't misunderstand me, I don't want it to be an X problem :)
<comadreja> I prefer it to be an mplayer one
<comadreja> and it's more reasonable
<comadreja> I'll try to debug mplayer... also much easier :D
<comadreja> to whom should I report progress on this ?
<ogra> comadreja, if you make progress, attache the information to the bug
<comadreja> cool, thanks
<comadreja> daniels, still there
<Kamion> lamont__: yo - was your ping here already sorted in /msg?
<lamont__> dealt with, thanks
<lamont__> mvo: it'd be nice if apt had an option that said to retry apt-get update N times, or until the gpg checks pass
<mvo> *ick* 
<lamont__> setting that to 2 or 3 would eliminate lots of the current transient errors we sometimes ee.
<mvo> oh, I see
<mvo> we would need atomic update :)
<lamont__> likewise, having apt just start all the fetches at once would tend to have the same effect, since they'd all be open files on the server system that way... but that's not as nice...
<mvo> but just keep retrying is a workaround we may try
<lamont__> mvo: that's a hacky attempt at atomic update-esque behavior...
<lamont__> mvo: and if you do it in apt, then I don't have to add it to buildd... :-)
<mvo> lamont__: heh :) I'll be away for two weeks for my summer vacation. but I can have a look when I come bug. 
<lamont__> cute freudian slip there.
* mvo blushs
<lamont__> Keybuk: ping
<Keybuk> 'sup?
* ogra would rather think of *radiates* with all thia atoms around
<mvo> lamont__: think of it as some kind of outlandish accent ;)
<daniels> comadreja: yo
<lamont__> Keybuk: other window...
<comadreja> daniels : it's an xv problem :(
<comadreja> daniels : I downloaded ubuntu sources, and compiled myself
<comadreja> daniels : with xv and x11 support
<comadreja> daniels : output is in an attach on the bug
<daniels> ok.  i have some xv updates for i810 in the pipeline, so we'll see if that fixes it.
<comadreja> daniels : awesome
<doko> elmo: is OOo2 for i386 hanging in NEW?
<mdke> he's not here right now
<Kamion> doko: yes, it is, I'll deal with it
<ogra> doko, where is ooo2 for amd64 hanging ? :P
<Kamion> ogra: not in NEW :P
<ogra> heh
<doko> ogra: unlikely that it will build for breezy
<ogra> :(((
<ogra> ((
<ogra> (
<thom> ))))))
<hubH> thom: I've got my log for the NM crqsh
<hubH> s/crash/misfunction/
<thom> cool, mail me it? (thom@ubuntu.com)
<thom> i'm going to bed now
<hubH> thom: where shall I report the bug ?
<hubH> ok I'll mail
<thom> thanks
<Kamion> doko: openoffice.org2-l10n-pt-br needs to depend on language-support-pt, not language-support-pt-br
<doko> Kamion: fantastic idea ... did pitti make a list of mapping from locales to language pack names?
<Kamion> just s/-.*// on the locale part
<hubH> is it me or gaim crashes ?
<hubH> I reported the bug, but I wanted to make sure
<jmjones> hubH: when does it crash for you?
<jmjones> i've been using it for months and haven't experienced a single crash.....
<doko> Kamion: is that true for zh-cn and zh-tw as well?
<doko> ahh, yes
<Kamion> doko: yes
<Kamion> I'll new them anyway, you can fix those next upload
<jmjones> has anyone in here taken a look at gtkwifi?
* Kamion gets confused by -base being a database module
<hubH> jmjones: when launching it
<jmjones> sweet!
<jmjones> it'll be in the next release?
<hubH> https://bugzilla.ubuntu.com/show_bug.cgi?id=12428
<Kamion> it's not in the distro yet
<Kamion> lrwxr-xr-x root/root         0 2005-07-05 18:26:55 ./usr/share/man/man1/oobase2.1.gz -> openoffice2.1
<Kamion> doko: should that be -> .1.gz?
<\sh> Kamion: sorry for holding up...
<mdke> np \sh 
<Kamion> \sh: np
* \sh will sponsor a 1he thingy to freenode :)
<doko> yep, I didn't look at the bug reports yet, current state is getting it built and running (java based parts don't work yet very well)
<Kamion> doko: firefox vs. mozilla-firefox dependencies from mozilla-openoffice.org are a bit random
<Kamion> doko: (yup, I'm just queueing the problems I see up here in lieu of firing up a web browser to file bugs :P)
<Kamion> doko: accepted
<wasabi> Hmm. Oddly beagle isn't installable at home.
<wasabi> Seems to require "dbus-1" which makes a lot of stuff get removed
<daniels> sounds about right
<daniels> dbus-1 -> old dbus
<wasabi> GOt it installed at work just fine though
<wasabi> Ahh there it goes
<doko> Kamion: fixed the firefox dep's
<Kamion> thanks
<doko> thom: could libnss and libnspr be built from the firefox source as well? Is one package generally preferred for building these binary packages?
<daniels> fabbione: right, got the xserver-xorg problem
<jp> gnome-pilot
<mxpxpod> jbailey: ping
<jp> hijbailey evo bug =)
<jp> jbailey evo bug =)
<jp> hhahah
<jp> :P
<jbailey> mxpxpod: Hey, I'm back.
<jbailey> managed to get locked out of my place. =)
<mxpxpod> jbailey: let's figure out this error I'm getting
<jbailey> I haven't assembled any furniture yet. =(
<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
<mxpxpod> oh
<jbailey> I was waiting for my mother in law to come back with the housekeys
<mxpxpod> heh
<jbailey> This is current breezy, right?  So probably not alot of ppc testers.
<mxpxpod> jbailey: right, current breezy
<jbailey> Best thing is for me to get my machine setup and see if I can replecate it.
<mxpxpod> ok
<mxpxpod> and I upgraded from  hoary
<jbailey> I've moved from being on the floor to sitting ona bench with my laptop balanced on a box.
<mxpxpod> haha
<jbailey> On the upside, I found a curry house that when I asked for "spicey" beleived me.
<Amaranth> *shudder*
<mxpxpod> nice
<Amaranth> i can't stand spicy food
<jbailey> It didn't *quite* get past my tollerance, but my stomach "could'na take any more, captain!"
<jbailey> Amaranth: I'm a vegan - much of the cooking in the world that I can eat has spice as an integral part of it.
<Amaranth> ah
<Amaranth> otherwise there is no flavor at all :p
<mxpxpod> jbailey: do you want the bug number?
<jbailey> mxpxpod: Not at the moment - I can't do much useful with it in this setup, and I think my time is best spent making sure that I can be productive from the beginning of the day tomorrow.
<jbailey> Actually, hmm.
<jbailey> Are you able to assign the bug to me?
<jbailey> If not, I can go in and take.
<jbailey> +it
<mxpxpod> jbailey: I can assign it
<mxpxpod> jbailey: jbailey@ubuntu.com?
<hubH> crap
<hubH> gaim still not working and debug build not helpful
<mxpxpod> hubH: go into your config and remove the loading of gaim-encryption
<mxpxpod> that made it work for me
<jbailey> mxpxpod: Please.
<hubH> mxpxpod: ah
<hubH> mxpxpod: abi issues ?
<mxpxpod> hubH: no clue
<mxpxpod> hubH: did that work?
<mxpxpod> jbailey: is that your bugzilla id?
<hubH> mxpxpod: wait. my machine is superslow
<jbailey> mxpxpod: Yes.
<mxpxpod> gah, my cat is being a pain
<hubH> mxpxpod: work way much better
<hubH> mxpxpod: thanks for the tips
<mxpxpod> hubH: no prob
<hubH> I forgot about thses
<hubH> no one use gaim-encrypt anyway
<mxpxpod> jbailey: I can't reassign... I'll CC you
<jbailey> I can do then.
<jbailey> Got a bug #?
<jbailey> Just that if you had it open anyway and could do it.
<mxpxpod> 12241 
<jbailey> Matt said he was locking permissions down and I haven't had the chance to figure out what that means people can do.
<jp> jbailey evo bug =)
<jbailey> jp: I see that you said that earlier in the channel.  I haven't a clue what you're talking about at the moment.
<jp> jbailey really dude?
<jbailey> jp: As I said earlier, I have spent the last 4 days or so moving from one province to another.
<jp> so now I know why evo crashes yet on breezy, thanks.
<jp> jbailey, https://bugzilla.ubuntu.com/show_bug.cgi?id=12188 that's what I've been saying you =)
<jbailey> Oh.  Do you know if someone has repoted this to upstream bugzilla?
<jbailey> If youhave a chance to look at that, it would be very useful - I don't have an exchange server handy to test against, so with evo-exchange bugs, I usually wind up working with upstream.
<jp> jbailey no, I don't, I'll search on gnome bugzilla
<jp> ok
* jbailey checks to see if ximian bugzilla is still separate.
<jbailey> Yup, looks like it is.
<jbailey> bugzilla.ximian.com
<calc> is network magic going to include wpa supplicant?
<jp> ok jbailey 
<jbailey> calc: That's the new version of wep that there isn't a free software implementation for yet? 
<calc> thats built into hardware?
<calc> wpasupplicant is currently in universe/net
<calc> and is GPLed
<calc> and BSD, hmm dual license GPL/BSD it appears
<calc> http://hostap.epitest.fi/wpa_supplicant/
<jp> jbailey uhmm Im not finding nothing :/ but I follow the seek :)
<jp> the search (:
<jbailey> thanks!
<seth_k> calc, NetworkMagic works with wpasupplicant iirc
<calc> seth_k: ok, it doesn't mention it on the udu wiki page
<seth_k> calc, I remember somebody talking about it here in -devel
<calc> good integration with wpasupplicant will make linux a lot easier to use with wireless
<seth_k> you know it
<seth_k> I want better roaming
<seth_k> with profiles that switch on the fly
<seth_k> I travel so much and am always having to change my wireless config
<calc> i may not have it set up exactly correct right now, but it seems i have to hardcode the ssid now if i want to connect to a ap that doesn't broadcast it
<calc> and its certainly not mom friendly yet ;)
<seth_k> Aunt Tillie, jah
<fabbione> morning
<seth_k> tch, 11 pm here. How about "Happy 0400 GMT"?
<seth_k> :P
<bddebian> heh
<bddebian> Hello fabbione 
<bddebian> Wow, I guess it's morning here too..  12:04am
<jsgotangco> its lunch on my side :)
<fabbione> you all live in weird timezones :P
<bddebian> Heh
<jsgotangco> hmm what is the "one true timezone" then?
<fabbione> ehehhe
<fabbione> of course
<HrdwrBoB> jsgotangco: mine
<HrdwrBoB> :)
<jsgotangco> *grin*
<seth_k> HrdwrBoB, do you have ops in #ubuntu ?
<seth_k> we need somebody in there
<HrdwrBoB> seth_k: if I did, I'd have done something already :(
<seth_k> blah
<seth_k> i couldn't remember if you did
<seth_k> I only have ops in #kubuntu
* seth_k grumbles
<seth_k> now he's /query'ing everybody
* seth_k is away: sleepytime
<KaiL> Burgundavia: so bugs which are fixed in breezy should "resolved fixed", or only if they can be tolerated in hoary?
<daniels> resolved/fixed
<Burgundavia> is there a good reason to backport the fix?
<Burgundavia> ie, major crasher or security hole?
<Burgundavia> looks like a minor issue to me
<KaiL> uhm, yes - esp. as you see the arrow
<Burgundavia> if a bug is fixed in Breezy, it can marked fixed (this is my assumption)
<KaiL> ..except it's something critical
<Burgundavia> if you wish to get is backported, the best place to convince somebody would probably be here or ubuntu-devel
<Burgundavia> so, to answer your question, yes to the first part and non-serious crasher/security bugs are tolerated in hoary
<pitti> Good morning
<Amaranth> jdub: Can nalioth be added to the #ubuntu access list?
<Unfrgiven> hi all. is anyone able to run totem, xine or mplayer on breezy atm?
<daniels> look, possibly a stupid question, but are any of dpkg/apt/archive tools going to run into problems with a 4627-character Depends line?
<daniels> hm, of course elmo and Keybuk aren't here
<daniels> Kamion: ?
<Lathiat> heh, what has a 4627-character depends line
<Lathiat> xorg?
<fabbione> hey pitti
<fabbione> Kamion, mdz, elmo: what happened to my redhat-cluster-suite upload?
<pitti> fabbione: you lost uploads as well?
<pitti> fabbione: I already started to wonder whether I'm completely dumb
<fabbione> pitti: looks like it...
<sladen> daniels: it's 7am in the UK.  and keybuk only logged off 5 hours ago...
<pitti> fabbione: the whole incoming queue is crowded with hppa uploads since yesterday
<fabbione> ahhh
<fabbione> but that's no problem...
<fabbione> i am uploading _sparc binaries.. and they get ACCEPTED
<pitti> fabbione: right, I see sparc as well
<fabbione> so i don't really see why sources shouldn't be processed
<pitti> fabbione: and indeed my uploads from yesterday night are mentioned for hppa, but not the source package or anything else
<fabbione> probably the mailq is still flushing
<pitti> fabbione: it's not the mail, I think
<pitti> serpentine | 0.6.1-0ubuntu1 |        breezy | source, all
<pitti> I uploaded 0ubuntu[23]  yesterday
<pitti> redhat-cluster-suite | 1.20050704-0ubuntu1 |        breezy | source
<daniels> Lathiat: xserver-xorg
<fabbione> pitti: yeah.. i uploaded 1.20050706
<infinity> Yeah, I lost two source uploads as well.
<infinity> Thought I was losing my mind, so I reuploaded them.
<fabbione> infinity: just reupload?
<fabbione> i mean i think we should wait for elmo to look at it
<infinity> <shrug>... reuploading doesn't seem to have done any good.
<pitti> infinity: I did the same :-/
<infinity> I assume elmo needs to poke it, yes.
<infinity> I didn't realise it was a widespread issue until now.
<daniels> there down to a far more reasonable 3183 lines
<daniels> christ.  i really don't want to write descriptions for all these packages.
<daniels> shit, I don't even know what half these input drivers *are*.
<Mez> siretart: ping
<siretart> Mez: pong
<Mez> aha :D
<Mez> mind adding me to REVU?
<Mez> you have my email with key and stuff in it ;)
<Mez> and if you want help with REVU -I wouldnt mind helping
<siretart> Mez: just a moment
<pitti> fabbione: I finally found the cause of the esound hang
<pitti> fabbione: sometimes draining the PCM device seems to trigger a race condition which makes the driver hang
<pitti> fabbione: according to alsa's upstream changelog, this should be fixed in 1.0.9a
<pitti> fabbione: can you please upgrade the alsa driver to 1.0.9b in the next kernel?
<siretart> Mez: are you already an uploader for ubuntu?
<Mez> er... no
<fabbione> pitti: it's already 1.0.9b
<Mez> not that I kow of :D
<Mez> I've had all my uploads sponsored
<pitti> fabbione: oh? thanks
<siretart> no problem, just need to know
<pitti> fabbione: well, I upload a workaround for now
<fabbione> ok
<Mez> (going for MOTU/Backports thgouh - well alrady backports - but need to go on REVU and do stuff to start with backports!)
<Mez> s/with backports!/with MOTU/
<daniels> mdz: so, dude
<pitti> Hey mdz
<daniels> mdz: do you know of any issues apt or such would have with a 3183-line Depends?
<daniels> mdz: any fixed buffers I'd be smashing?
<mdz> daniels: apt doesn't care about lines, but there are some byte limits
<tepsipakki> anyone using rbscrobbler on breezy? stopped working for me.. maybe some bonobo-issue
<pitti> daniels: which package is supposed to have so many deps?
<mdz> daniels: what's this breakage with xkb about; is there a workaround?
<daniels> mdz: 'kay
<daniels> mdz: what xkb breakage?
<siretart> Mez: ok, I added you to the keyring. you may upload now
<mdz> daniels: (EE) Error loading keymap /usr/X11R6/lib/X11/xkb/compiled/server-0.xkm
<mdz> is it only me?
<mdz> pitti: morning
* Mez tries uploading
<mdz> daniels: .../compiled is a symlink to /var/lib/xkb, which is empty
<fabbione> morning mdz
<mdz> fabbione: morning
<mvo> morning mdz
<fabbione> it sounds strange to have you around at this time of the day
<fabbione> ;)
<mdz> indeed
* fabbione is almost ready to give InstallerVolumeManager a nice working upload
<mdz> daniels: I also have /usr/bin/X11 as a directory containing a symlink 'bin'
<daniels> mdz: right.  if nothing has landed in /var/lib/xkb, then xkbcomp has failed to produce anything.  what sort of layout are you ... oh.
<daniels> mdz: yeah, nuke /usr/bin/X11 and make it a symlink to /usr/bin
<daniels> infinity: you were saying you knew how to do the /usr/bin/X11 migration properly?
<mdz> daniels: nothing failed during the upgrade, though
<daniels> mdz: it just failed silently
<mdz> where does xkbcomp get called?
<daniels> mdz: from within the server
<mdz> oh, sweet
<daniels> mdz: it puts the compiled keymap in /var/lib/xkb, and the server then open()s that
<daniels> yeah, it's fucking nasty, to be blunt
<daniels> there are about ten shell injections and buffer overflows you could trigger there to get root under the right set of circumstances
<hunger> pitti: Just playing with luks... does that really need ~600k to store one key?
<pitti> hunger: it probably allocates much space for the keyring
<pitti> hunger: you can have multiple keys
<pitti> hunger: that makes sense for /home e.g.
<hunger> pitti: Yes... but 600k is room for LOTS of keys!
<pitti> yes
<daniels> mdz: (that figure isn't an exaggeration, BTW)
<pitti> I didn't look at the exact space requirements so far
<daniels> bbiab, making dinner
<hunger> pitti: I am trying to do a keystore in a file. The loopback device is 1MiB, the filesystem has only 495k free.
<mdz> X starts now, going back to the modern era with graphical user interfaces
<pitti> wb, mdz :-)
<mdz> pitti: with an X server, this time!
<pitti> how l4m3 :-)
<infinity> daniels : Yes, re-poke me when you're done dinner.
<pitti> mdz: now that we have a working esound as emergency fallback again, I'd like to switch to polypaudio as default to get more widespread testing. Are you opposed to that?
<mdz> pitti: it's very difficult for us to switch back due to the dependency issues; are you fairly confident we will be able to release with polypaudio?
<pitti> mdz: it has worked stable for over a week on my laptop now, however, I'd like to see more testing
<mdz> pitti: ok, let's do it
<pitti> mdz: why is it difficult to switch back?
<pitti> we did it in Hoary as well
<pitti> mdz: if I get more testing and bug reports, then we can certainly fix the remaining crashes; it's not totally broken any more at least
<pitti> mdz: switching would mean: change desktop seed and regenerate ubuntu-meta?
<mdz> pitti: if you look at a sample of systems which were running hoary during development, you'll find that many of them still run polypaudio unless the user explicitly switched back
<mdz> pitti: yes, seeds and ubuntu-meta
<pitti> mdz: uh, becuase they deleted ubuntu-desktop?
<mdz> pitti: no, because polypaudio Provides: esound
<pitti> ah
<infinity> If ubuntu-deskto had a versioned dep on esound, you could force that.
<mdz> pitti: even if we add an explicit dep which only matches polypaudio, apt will generally prefer to remove ubuntu-meta rather than disturb so many other packages
<pitti> crap
<mdz> breakfast, bbiab
<pitti> mdz: well, then I rather ask for more testing on u-devel first
<pitti> Hey seb128 
<mdz> pitti: it is a development branch; we don't need to clean everything up perfectly
<mdz> if you feel there is a reasonable chance to get it working well, let's do it
<pitti> yes, I feel so
<pitti> on my desktop I experienced some crashes occasionally
<seb128> hi pitti 
<pitti> but we should be able to fix them
<pitti> seb128: esound works again :-)
<seb128> pitti: what have you changed?
<pitti> seb128: snd_pcm_drain() sometimes triggered a race condition in the kernel driver
<pitti> seb128: I disabled the call for now; that might cause a few sound hickups, but at least it doesn't hang your desktop
<pitti> seb128: it's a workaround, not a real bugfix, but since it is so important, I wanted a quick solution
<seb128> pitti: k
<seb128> hey carlos 
<carlos> morning
* fabbione shrugs at p-a-l
<daniels> infinity: i'm sort of done now
<infinity> daniels : Oh, I'm sort of not ready to be useful to you yet. :)
<infinity> daniels : THe short answer to dir -> symlink transitions is "ship the symlink, test if it's a link in postinst, if not, make it one"
<infinity> daniels : Doing it in preinst does VERY bad things.
<daniels> oh?
<infinity> daniels : The long answer is that you'll have to now cover some extra corner cases you've accidentally created cause you have files in that directory (unless you're positive those files can go away, then just rm -rf the thing)
<seb128> mvo: around?
<daniels> infinity: gnur
<mvo> seb128: yes
<\sh> daniels: libXi is now referenced by libxi-dev as b-d?
<seb128> mvo: there is a new gnome-system-tools version upstream, do you work on it or should I?
<daniels> \sh: what?
<mvo> seb128: I won't be able to before I leave for vacation I think
<\sh> something failed cause of missing libXi.so* 
<\sh> so i need to include libxi-dev as b-d for this package..:(
<seb128> mvo: k, so I'll do it. I'm just making sure to not dup the work
<mvo> seb128: thanks!
<seb128> np
<seb128> mvo: have you done any work on desktop files/sudo? 
<seb128> mvo: since you do some work on gksudo and so
<mvo> seb128: what kind of work exactly? converting gksu -> gksudo in .desktop files?
<daniels> \sh: yeah, always has (at least, since 4.3.0)
<seb128> let's grab that somewhere else
<daniels> \sh: if it failed, then it's never properly worked
<\sh> daniels: hmmm
<Kamion> fabbione: I can't quite see what happened to redhat-cluster-suite ... it may be in progress
<\sh> http://people.ubuntu.com/~lamont/buildLogs/libk/libkexif/0.2.1-2ubuntu1/ <- worked without
<\sh> http://people.ubuntu.com/~lamont/buildLogs/libk/libkexif/0.2.1-2ubuntu2/ <- didn't build :(
<daniels> \sh: must've been an impliclt dependency, then
<daniels> e.g. libkfoo-dev depended on libxi-dev
<\sh> kdelibs4c2
<\sh> so we have to have a look there
<doko> carlos: pong
<Kamion> mdz: apparently the live CD rootfs-building script adds xresprobe and laptop-detect to all live CDs
<Kamion> mdz: should we just put those in the seed?
<carlos> doko, libcpp and libstdc++ have .po files but Debian and Ubuntu are not installing .mo files for them, only for gcc. How is that?
<mdz> Kamion: yes, and remove them from the script
<daniels> fabbione: dude, can you remember how to parse m-i-r output?
<daniels> i'm looking at it now, and it makes no frigging sense
<fabbione> Kamion: don't worry... apparently a bunch of packages upload has been queued with a long delay.. it's pretty strange.. but well
<fabbione> daniels: not at all...
<daniels> ok, think I've sorted it out now
<daniels> there was a bug in m-i-r, some completely backwards code which totally broke the purpose it was put there for in the first place and made no sense whatsoever
<fabbione> Kamion: p-a-l should have never existed...
<Lathiat> whats m-i-r?
<fabbione> Kamion: all the stuff is already in partman-auto and partman-lvm...
<daniels> that and some behaviour which I think shouldn't be there at all
<daniels> Lathiat: manifest-install-reconcile
<fabbione> Kamion: p-a-l is just a badly copy&paste of the 2 above...
<daniels> Lathiat: some absolutely crack script which is meant to tell you what is and isn't being installed in the xorg package
<daniels> Lathiat: i.e. files make install installs, but aren't in any packages
<fabbione> Kamion: definetely it is worth a redisign from scratch, but the changes required in partman-auto and partman-lvm are big to make it for breezy....
<Kamion> fabbione: I think it was a prototype of recipe parsing
<Kamion> fabbione: but dude, talk to Anton about this, I so don't know anything about it
<fabbione> Kamion: yeah.. 
<doko> carlos: libstdc++ only contains yes/no. IIRC these po files are not the final word. libcpp has the po files in gcc-4.0-locales.
<carlos> doko, does it means libstdc++ is not used at all?
<carlos> pitti, Yesterday I started fixing the review-* potemplates I hope all those will be killed at the end of this week
<carlos> pitti, seb128: Is the gnome-panel's 'About Ubuntu' string supposed to be inside the gnome-panel's .pot file?
<seb128> carlos: that's a desktop file ...
<carlos> pitti, seb128 if the answer is 'yes' we have a problem with the Hoary's .pot file
<carlos> seb128, oh!
<seb128> carlos: no, that's a debian/....destkop not listed by POTFILES
<carlos> seb128, we need it inside POTFILES if you want to get it translated with Ubuntu
<carlos> seb128, or as its own .pot file
<seb128> I know, but I did a lot of translations hack before hoary
<doko> carlos: only in the testsuite
<carlos> doko, https://launchpad.ubuntu.com/distros/ubuntu/hoary/+sources/gcc-4.0/+pots/libstdc++/de/+translate
<seb128> carlos: there was no point to hack that before hoary, keeping translation updates with bugzilla was already some good work
<carlos> doko, ok, I will mark it then as 'ignore' or is it useful to get other transaltions for the test suite?
<seb128> pitti: DOH, bug flood since yesterday
* seb128 reads the bugs mailbox
<carlos> seb128, hoary does not supports .desktop translations so it's ok, but please fix that for breezy (if it's not already) so we can get those translations if we get .desktop support in place on time
<doko> carlos: ignore is ok, unless you want to extend the testsuite ;-P
<seb128> carlos: sure
<carlos> doko, ok
<carlos> seb128, thanks
<seb128> np
<pitti> back from breakfast
<carlos> pitti, how should we handle the packages I detect that does not have a .pot file?
<carlos> pitti, is a bug report against it ok for you?
<pitti> carlos: we have to fix them for breezy
<pitti> carlos: no need for a bug, I monitor them
<carlos> pitti, universe included?
<pitti> carlos: http://people.ubuntu.com/~pitti/langpacks/dload-strippedtar.txt
<pitti> carlos: that's the report from the automatic daily import
<pitti> carlos: no, not universe
<carlos> pitti, should we get anyone from Universe to take care of those packages?
<carlos> I mean, any universe maintainer
<pitti> carlos: it would be nice to have a list
<pitti> yes, of course
<pitti> might even be better to ask Debian maintainers
<pitti> lots of my "generate pot file" patches were already adopted in Debian
<carlos> oh, cool
<carlos> pitti, is it too difficult to create the same .txt for universe?
<pitti> carlos: no, actually not
<carlos> pitti, please, do it then so we can know which upstream packages should be bugged about it :-)
<carlos> it's not urgent
<pitti> alright, I add it to my todo list
<carlos> so do it when you have some spare time
<carlos> pitti, thank you
<sabdf1> carlos: i have a very nice surprise for you today
<sabdf1> last night's late work
<Kamion> mdz: I think I'd better mail ubuntu-devel@ about UVF ...
<mdz> Kamion: agreed
<carlos> sabdf1, is it related to a suggestion language selection?
<carlos> sabdf1, or a new one? :-P
<sabdf1> carlos: new one, part of rosetta that's been ugly for a while (i wrote the ugly bit too, but it's been nagging at me)
<Kamion> mdz: I'll move the merge deadline out a week on the release schedule, like we discussed
<mdz> Kamion: thanks
<carlos> sabdf1, cool
<seb128> Kamion, mdz: can one of you promote docbook2x (approved by pitti for gnome-doc-utils) and libexchange-storage1.2-dev (lib for evolution-exchange moved) to main the corresponding ftbfses?
<seb128> to fix the ftbfses
<jordi> seb128: btw, we should fixup all the evo-data-server mess in Debian
<jordi> we have two e-d-s' now, thanks to takuo
<seb128> jordi: that doesn't hurt
<seb128> they are versionned
<jordi> it's a messa nyway.
<jordi> we only want one
<Kamion> seb128: done
<seb128> Kamion: thanks
<jordi> when are you taking over evolution for Debian anyway? :)
<seb128> jordi: we have enough to do without taking over eds
<seb128> jordi: no way
<jordi> seb128: yeah, someone needs to package ephy
<seb128> jordi: I'm not the one doing NMUs on it :p
<jordi> heh
<pitti> seb128: so libgnome is the library that is responsible for playing sound events?
<pitti> seb128: I'd like to make them work with polypaudio
<seb128> pitti: yep
<mjg59> mdz: Around?
<mdz> mjg59: yes, but in a meeting
<mdz> mjg59: coming to london today?
<mjg59> Yup
<mjg59> Where/when would be good?
<mdz> mjg59: fieldwave office / the sooner the better
<mjg59> mdz: Where's the fieldwave office?
<sabdf1> mjg59: axiscross house, mossop st, off draycott ave
<sabdf1> between the admiral codrington and the australian, in pub coordinates :-)
<mdke> you guys go by pub coordinates eh...
<mdke> now I know why Ubuntu is such a smooth successful distro
<pitti> daniels: dangling /etc/X11/X symlink is a known issue?
<pitti> it did not just bite me
<mjg59> mdz: Ok, ought to be there shortly before 1
<mdz> mjg59: wonderful, see you there
<fabbione> hmmm food time
<fabbione> maswan: if you are around.. buttercup died again
<mpt> mako: ping
<mpt> mako: deping
<maswan> fabbione: I'll try to remember that within the next couple of hours
<fabbione> maswan: thanks.. there is no rush..
<fabbione> it died one or two days ago
<fabbione> i think there is one package (always the same) that manage to crash the box at build time
<maswan> well, if i don't get to it before friday, I'll be in HEL instead of here
<fabbione> maswan: that's ok.. don't make it a high priority thing
<fabbione> thanks a lot!
<fabbione> time to start cooking :)
<terrex> follows Malone the same numeration of bugs that Bugzilla?
<sabdf1> jamesh: which was that branch of yours with the fix? can i just merge it directly fro you? need it before i can add the page tests :-)
<Kamion> terrex: no
<sabdf1> oww
<jamesh> sabdf1: the +ubuntupkg one? james.henstridge@canonical.com--2004/launchpad--smallfixes--0
<sabdf1> jamesh: thanks. sorry, ww :-)
<jamesh> :)
<Kamion> mdz: debconf-communicate needs some more fixing to work the way you're using it
<Kamion> mdz: (namely, it doesn't currently autoflush STDOUT - working on it)
<Mez> ogra: ping
<ogra> Mez, ?
<Mez> any chance of getting k3b bugs auto-assigned to me?
<Mez> I asked kiko - he said to get it cleared with you
<Mez> ogra, I mean for bugzilla, in case you hadnt figured... seeing as I'm now maintaining K3b :D (even if it is through sponsored uploads)
<Mez> lol @ ogra...
<Mez> crash ?
<ogra_> Mez, riddell seems to be happy with it, if he approves i'm fine to have them assigned to you and him for now, but i'd like you having upload rights first before you get them alone...
<ogra_> nope, daily disconnect :)
<Mez> ogra... I'll poke riddell then :D
<Mez> and I'm working towards upload rights, as you darn well knoe :D
<ogra_> :)
<ogra_> yep, i know :)
* Riddell feels poked
<Mez> riddell - that cool with you?
<Mez> k3b bugs assigned to us both ?
<Riddell> Mez: sure
<Mez> there yo go ogra ;)
<Kamion> I don't think bugs can have multiple assignees
<mako> mpt: i'm here.. although quite scrambling
<Kamion> you can have an assignee and a QA contact
<zyga> hello
<Kamion> but the QA contact should probably just be kubuntu-bugs@?
<Mez> well... wouldnt it make sense to have me as asignee and riddell as QA?
<Mez> but /me shrugs
<Mez> tis up to ogra
<mpt> mako: Sorry, "deping" means "cancel that ping" -- I had a question about Condorcet, but found the answer myself
<Riddell> kubuntu-bugs should remain as QA
<mdz> pitti: language-pack-en seems to be removed on dist-upgrade due to openoffice.org-thesaurus-en-us
<ogra_> Riddell, with this address you get them on your desk ? 
<Lathiat> mpt: heh you say 'deping' too
<Riddell> ogra_: yes
<ogra_> Riddell, ok, just want to make sure youre seeing what goes on in your universe ;)
<Mez> is kubuntu-bugs on gmane ?
<Riddell> Mez: no idea
<doko> mdz, pitti: we don't have the thesaurus for oo2 yet.
<Mez> nah it isnt
<Mez> Riddel... can I add it?
<Riddell> Mez: sure
<zyga> file roller crashes when extracting files from zip archive with incorrect filename encoding 
<Mez> whats the permissions for it?
<Mez> read only?
<Mez> posting allowe?
<zyga> should I file a bug/
<Riddell> Mez: read only
<pitti> mdz: you mean the support package?
<ogra_> Mez, i cant edit components in bugzilla... we probaby need mdz
<mdz> pitti: ah, yes
<Mez> kiko can and will
<ogra_> Mez, ok
<Mez> or msz...
<Mez> seeing as he's here
<zyga> http://pastebin.com/308280
<zyga> It crashes in glib so I think it's relevant
<mdz> doko: where is the conflict with the oo.o1 thesaurus?
<mdz> ogra_: what do you need?
<ogra_> mdz, Riddel and Mez want to share the bugload for k3b, so Mez should be added as asigee to k3b... QA contact for kubuntu-bugs shall remain
<doko> mdz: there is no conflict, it's not yet built for oo.o2. afaik, the format did change as well, so you cannot use the oo.o1 thesaurus with oo.o2
<mdz> ogra_: ok, will do
<ogra_> mdz, thanks 
<mdz> doko: installing openoffice.org2-base removes openoffice.org-thesaurus-en-us
<Mez> mdz, thanks
<mdz> doko: there is a conflict somewhere
<mdz> Mez,Riddell: done
<Mez> cool
<Mez> well I should go and get my eyes checked now really
<doko> mdz: it's a direct conflict in openoffice.org2-core. Suggest openoffice.org2-thesaurus; conflict against
<doko>       openoffice.org-thesaurus once we have a solution to let both co-exist
<doko>       with the "normal" dictionaries-common system.
<doko>       (They are incompatible and The OOo1 Thesauri make OOo2 crash..) [RE] 
<doko>     - add openoffice.org2-officebean [RE] 
<Treenaks> yay for OOo
<mdz> doko: ah, I see
<doko> did somebody see my openoffice.org2_1.9.113-0ubuntu2 getting accepted? I didn't get a message
<ogra_> Treenaks, i cant even open ooo2 stuff here :/ so it seems with breezy amd64 is incompatible with the rest of the world :(
<Treenaks> ogra_: I had to install 512M of extra memory to be able to even /boot/ OOo2 on my work box
<Treenaks> ogra_: ok, it's SuSE, but that's no excuse
<ogra_> heh
<doko> Treenaks: yes, OOo2 with less than 512MB sucks
<Treenaks> doko: are "they" working on that?
<doko> Kamion, mdz, elmo: is my openoffice.org2_1.9.113-0ubuntu2 getting accepted? I didn't get a message, but got one for a later upload
<zyga> #12437 if anyone would like to review
<doko> Treenaks: did you ever see an application shrink?
<pitti> doko: some uploads silently disappeared since yesterday
<Treenaks> doko: yes.
<ogra_> doko, sure... after a rewrite :)
<Treenaks> ogra_: gnome is shrinking...
<ogra_> Treenaks, thats not an app :)
<doko> pitti: try a re-upload?
<Treenaks> ogra_: it's a collection of apps
<pitti> doko: I already did, it didn't help
<pitti> doko: that's really an elmoish problem
<hunger> new gnome-doc-utils depend on libxml2-python2.3 for some reason.
<Riddell> is it possible to explicity ignore a package from shlib:depends?
<Kamion> doko: I can't see it anywhere ...
<Kamion> ug, there's a load of stuff in queue/unchecked
<Kamion> doko: your upload's there; I think something's crashing
<pitti> Kamion: do you also see two serendipity and redhat-cluster-tools uploads?
<pitti> Kamion: s/serendipity/serpentine/
<Kamion> E: libsigcx-gtk-0.6-1c2 in breezy is in the overrides more than once.
<Kamion> pitti: two serpentine, one redhat-cluster-tools
<pitti> right
<pitti> so they were not competely lost
<Kamion> don't worry, it's almost certainly all there
<Kamion> I'll fix
<pitti> Kamion: oh, you can? great
<Kamion> should be able to, yes
<Kamion>     section    | priority |   name
<Kamion> ---------------+----------+----------
<Kamion>  universe/libs | optional | main
<Kamion>  universe/libs | optional | universe
<Kamion> ok, what the hell happened here
<pitti> ouch
<mako> mpt: cool :)
<mako> mpt: i think i read that "reping"
<mpt> !ping
<mpt> unping
* mako got it :)
<mpt> good good
<Kamion> mdz: <lock> on katie overrides
<mdz> Kamion: ack
<Kamion> </lock>
<fabbione> Kamion: while you are at it, could you also fix gnome-alsamixer to be really in universe?
<zul> Emmanual, as he will have to give you some guidance as to
<zul> what time to come in on Monday, etc.  I will prepare an
<zul> Employment Agreement for you to sign - I'll email it later
<zul> today.
<zul> Lynn
<Kamion> fabbione: it already is
<fabbione> zul: you keep surprising me :)
<zul> frig...stupid xchat
<Kamion> gnome-alsamixer |    0.9.6-1 | breezy/universe | source, amd64, i386, powerpc
<fabbione> Kamion: yes.. but for some reasons wanna-build keeps trying to fetch it from main.. or consider it so
<doko> firefox constantly crashes, when I try to edit the BreezyGoals page ... :-(
<Kamion> queue/unchecked is emptying now
<fabbione> Kamion: do we need to reupload or it has been processed?
<Kamion> Rejected: 'dpkg-source -x' failed for openoffice.org2_1.9.113-0ubuntu2.dsc [return code: 6400] .
<Kamion>  [dpkg-source output:]  dpkg-source: error: file openoffice.org2_1.9.113.orig.tar.gz has size 195858972 instead of expected 196996782
<Kamion> doko: ^--
<Kamion> fabbione: no, existing uploads were just sitting there, it's fine
<fabbione> ok thanks
<Kamion> redhat-cluster-suite_1.20050706-0ubuntu1_source.changes
<Kamion> ACCEPT
<fabbione> DANKE
<doko> Kamion: argh, yes, thanks, I remember ...
<fabbione> Kamion: i dunno the changes that elmo did to katie.. but the new redhat-cluster-suite will add 2 new binaries..
<fabbione> not sure if you need to do more than what you already did
<Kamion> fabbione: they'll hit NEW once the buildds build the binaries
<fabbione> ok thanks
<fabbione> Kamion: if you will be the one processing them.. the 2 new bins can just go and float in universe..
<Kamion> ok
<Kamion> they would anyway
<fabbione> just to be sure :)
<lifeless> is elmo around at the moment ?
<Kamion> lifeless: moving house
<lifeless> or is someone filling for him ?
<Kamion> depends which role
<Kamion> I'm doing urgent Ubuntu archive maintenance when necessary
<lifeless> mail to team@bazaar.canonical.com is timing out contact the server
<Kamion> can't help you there ...
<lifeless> ok
<lifeless> I'll sms him
<doko> hmm, please could somebody try to verify a firefox crash, that pressing the left cursor key, when editing the http://udu.wiki.ubuntu.com/UbuntuDownUnder/BreezyGoals page (line OpenOffice2) ?
<ogra_> doko, is your ff upto date ? i had this bug with the last version but its gone quite a while now
<carlos> ogra_, I think I filed that bug and it was with hoary
<ogra_> carlos, i had it on amd64 with breezy... but only til last update
<ogra_> doko, mozex.mozdev.org/
<doko> I see it on i386 and amd64
<doko> current breezy
<camilotelles> mdz, hi there.
<carlos> pitti, breezy transaltions are being imported into production today
<carlos> pitti, I think it will take a while (easily, a couple of days)
<carlos> pitti, just in case you want to check anything
<pitti> yay
<pitti> carlos: indeed, that outcome will decide the direction of language packs
<pitti> carlos: do you have an estimation of how many of breezy's po files are actually changed by rosetta? I. e. received new translations?
<carlos> pitti, no easy way to know that, why?
<carlos> pitti, at the moment I doub we have any change
<carlos> as the .po files are still being imported
<pitti> carlos: but we already received many hoary updates
<carlos> and the changes done to hoary are not yet automatically applied to breezy
<pitti> carlos: oh, but they certainly will in the future?
<carlos> pitti, they appear as suggestions, someone needs to select them
<carlos> pitti, yes
<pitti> I mean, as long as the strings don't change, they can be reused?
<pitti> ok, fine
<carlos> pitti, yes, that's the plan
<carlos> I hope we will have that done before breezy release or at the same time
* carlos -> lunch
* fabbione goes offline for a little while
<mdz> camilotelles: hello
<camilotelles> mdz, how is going UE? we can help in anything?
<camilotelles> mdz, i saw in the wiki that you are working in the backend.
* fabbione &
<lamont> Kamion: redhat-cluster-suite is Uploaded on i386,amd64,ia64, needs-build on the other 3
<Kamion> lamont: yep, already NEWed
<lamont> Kamion: actually, since it links with ld (violates gcc spec), it's FTBFS on hppa
<tvo> is there actually any difference between tla and baz, except the latter being writting in C and the first not?
<Kamion> tvo: your "except" is not true
<Kamion> baz is a branch of tla aiming at user interface improvements
<Kamion> it is written in C
<Kamion> as is tla
<tvo> ah because I don't see any differences yet, but I'm still learning....
<Kamion> better mirror support and better signed-archive support are perhaps the most obvious
<Kamion> along with various UI cleanups
<Kamion> the release notes are on bazaar.canonical.com, you could look there
<Kamion> under Downloads
<Kamion> oh, and better URL support, mesh-merging, conflict marking, diff, switch
<tvo> Kamion: thanks for the info
* tvo installs bazaar-1.4 and continues the tutorial at http://regexps.srparish.net/tutorial-tla/arch.html
<zyga> is baz compatible with tla?
<zyga> totally compatible I mean
<lamont> zyga: baz can use tla archives, you can tell it to create a tla-compatible archive
<zyga> lamont: good enough
<Kamion> it's not completely command-line compatible in the sense that you can't take scripts that call tla and s/tla/baz/g
<lamont> but some of the improvements have required archive internal changes
<zyga> hmm I see
<Kamion> but it wasn't meant to be - tla is staying in basically its current command-line form as a scriptable reference client
<zyga> I use tla ATM and I'm about to move another project without any vms to tla
<zyga> but I've heard about baz recently
<Kamion> since much of what was awful in tla was the command-line interface, breaking that was OK :-)
<Kamion> all the same, most of it should be familiar to you
<zyga> tla is okay once command line verbosity/obscurity is through one's head
<Kamion> not having to do ultra-strange things to set up signed archives is very nice
<Kamion> you might only do them once yourself, but every time you have to explain it to somebody else ...
<zyga> hmm? strange things
<zyga> --signed and =default stuff 
<Kamion> ~/.arch-params/signing/blah
<zyga> ;)
<zyga> both are onle liners
<Kamion> baz doesn't require any of that
<Kamion> no-liners better than one-liners
<zyga> :)
<Kamion> well, --signed yes
<zyga> well good reading is still required since tla is totally different from cvs/svn
<thom> is it just me or is OOo utterly hosed on amd64 - looks like ia32-libs is very unhappy
<lamont> Kamion: I thought --signed was the default these  days
<doko> thom: ia32-libs wasn't updated for breezy.
<mdke> where is elmo these days?
<thom> doko: /usr/lib32/ is a symlink to /emul/<something> (my amd64 is off atm) which doesn't exist
<thom> mdke: moving
<lamont> mdke: I'm betting he's in london
<mdke> aha
<mdke> everyone is moving house right now
<mdke> :)
<doko> thom: breezy or unstable?
<thom> doko: breezy
<doko> upgraded from debian, or fresh install?
<thom> upgraded from hoary
<tseng> thom: should i remove networking script from my runlevel, or will it do something useful with nm?
<tseng> in the future
<doko> thom: remove it, then reinstall ia32-libs*, lib32*
<thom> tseng: i'd leave it; in the future there might be something clever done
<thom> doko: ok
<doko> Mithrandir: does this need a better upgrade procedure? ^^^
<doko> hmm, he's not there
<thom> doko: given that it utterly horks OOo, yes, i'd say it does
<hunger> debian has sdparm (hdparm for scsi disks) now... how about importing it into ubuntu?
<seb128> pitti: thanks for the work on serpentine
<pitti> seb128: you're welcome :-) does it work for you now, too?
<pitti> seb128: I happily burned 3 CDs with it yesterday
<seb128> pitti: not tried, waiting to get the updates
<pitti> although the backend design is utter crack, it at least works
<pitti> seb128: yeah, the upload was not accepted until Kamion fixed the queue some hours ago
<ogra> hum, i should have mentioned the update in my mail
<pitti> ogra: btw, since putting bugs in bugzilla for already solved issues is not really sensible, and some patches are more like workarounds than proper fixes, can you forward the patches upstream?
<Kamion> lamont: make-archive --help doesn't suggest so but the help isn't always 100% accurate
<KaiL> is there any known problem big with hal on breezy?
<ogra> pitti, i'll mention them in my mail
<pitti> KaiL: what do you mean in particular?
<KaiL> well, for me it doesn't see partitions on USB-Sticks, for Riddell no (internal) cdroms :)
<zyga> seb128: thanks for the quick reply on my bug report
<pitti> KaiL: please file a bug and send along dmesg and lshal outputs
<zyga> seb128: will hoary ever get that update?
<seb128> zyga: what bug is yours? I've replied to like 40 bugs since this morning
<zyga> seb128: file-roller
<seb128> oh, no, no new version
<seb128> a small patch could be a candidate for an hoary-updates upload
<zyga> seb128: I see, the current version is just 'too' new, right?
<seb128> nop, we just don't change versions on a stable distro
<seb128> we patch for issues, but that needs some investigation/work to get the patch, etc
<seb128> I'm pretty busy, better to fix some crasher on the current version than tackling a bug already fixed which doesn't happen a lot
<davyd> did breezy recently get a new major libc6 version?
<mjg59> ogra: mdz asks if I can be given access to the hwdb
* davyd bings happily at mjg59 
<mdke> mjg59, mdz, just saw the new laptop pages, is it cool if i do some formatting, maybe add titles etc?
<mjg59> mdke: Sure, no problem
<mjg59> ogra: Also, is there a list of MOTU members anywhere?
<mdke> cool
<ogra> mjg59, see /msg and the MOTU list is on wiki.ubuntu.com/MOTU
<Lathiat> mjg59: suggestion fo rthe laptop testing spec, see if the laptop suspends and resumes a second time
<mjg59> Lathiat: Sure - add it to the wiki
<tepsipakki> latest rhythmbox broke rbscrobbler because something in the bonobo-interface has been changed. How do I find the new hooks in rb?
<tepsipakki> (of course rb-applet broke as well)
<mxpxpod> jbailey: ping
<jbailey> mxpxpod: pong
<mxpxpod> jbailey: any progress on my bug?
<jbailey> mxpxpod: I've got my machine almost completely apt-get upgraded now.
<mxpxpod> awesome
<mxpxpod> jbailey: I'm anxious to see if it's isolated to my machine
<jbailey> Looks like I'm updated, rebooting.
<Kamion> davyd: not recently; some time back
<mgalvin> hi all, how do i determin which packages dep on other package...
<Lathiat> mgalvin: apt-cache rdepends
<mgalvin> for example, is there a way to find out if any packages depend on cegui
<mgalvin> Lathiat, thnx
<lamont> Kamion: coreutils/procps both delivering kill.1 manpage - I thought you said that was fixed???
<Kamion> lamont: no, I sent patches
<lamont> ah, ok.
<Kamion> 'cos it needed dbs changes too
<lamont> ew
<Kamion> (ideally)
<Riddell> can I upload a package with section of non-free/doc ?
<Kamion> dbs ships dpkg-arch.mk, you see ...
<lamont> and hence we're not sure how it'll really get fixed, so it's best to wait for debian for a day or 6, yes?
<Kamion> Riddell: technically yes; it'll probably go to multiverse
<Kamion> lamont: right, pretty much, I thought I'd give the dbs maintainer a chance to decide
<lamont> is it true that dbs is being rewritten in php4?
<Kamion> !
<Riddell> Kamion: this is FDL licenced stuff, should I change the section to just doc?
* lamont ducks
<Kamion> Riddell: leave the section as it is, that's what archive overrides are for
<mxpxpod> jbailey: so, how's it working?
<jbailey> It's libwnck that you're seeing it in, yes?  Lemme fire up a gnome terminal then.
<mxpxpod> jbailey: yessir
<jbailey> What app are you showing up the error in?
<mxpxpod> /usr/lib/gnome-panel/wnck-applet
<mxpxpod> this is from memory, so that may not be right
<jbailey> No error.
<mxpxpod> what????
<mxpxpod> damn
<mxpxpod> so now I have to figure out what's frelled on my system
<mxpxpod> this isn't fair :)
<Riddell> malex: how come scribus-doc includes both the GNU FDL and open publication licence?
<lamont> Kamion: I only mention it because it blocks gcc-4.0 :-(
<mxpxpod> jbailey: when I get home tonight, can you help me figure this out?
<jbailey> mxpxpod: Start with "ldd /usr/lib/gnome-panel/wnck-applet" and make sure everything points to /usr/lib
<jbailey> mxpxpod: When is tonight for you? =)
<mxpxpod> jbailey: 6:00 PM CST
<lamont> Kamion: well, gcc-4.0/hppa at least
<jbailey> mxpxpod: CST, like north america?
<mxpxpod> jbailey: yes, like Iowa
<jbailey> Ah, I had forgotten you were american.
<jbailey> Yes, I should be around a bit after that.
<mxpxpod> jbailey: cool
<mxpxpod> jbailey: this is just really frustrating
<jbailey> mxpxpod: I understand.  I'm setup to actually help you now, though.
<mxpxpod> jbailey: I've considered re-installing all my packages :)
<mxpxpod> jbailey: my lunch is in 2 hours... can you help me then?
<mxpxpod> my boss wouldn't think it too keen to work on my laptop and get paid for it
<jbailey> mxpxpod: Not really - that's about my lunch break too and I need to buy a fridge.
<mxpxpod> :)
<mxpxpod> suckage
<jbailey> Well, it's certainly interesting.
<mxpxpod> you're telling me
<Kamion> lamont: ok, I'll do a quick hack-fix in coreutils/ubuntu
<lamont> Kamion: any time in the next 24 hours or so would be wonderful. :-)
<lamont> hppa has a pretty large hysteresis 
<mxpxpod> jbailey: well, I would pull out my laptop and work on this, but my boss is right across the hall from me right now :)
<jbailey> *lol*
<jbailey> Please don't get fired on my account. =)
<mxpxpod> jbailey: :D
<mxpxpod> jbailey: how long will it take to buy a fridge?
<lamont> mxpxpod: that depends on the "kill vs shop mentality" decision
<lamont> ISTR buying a fridge once with < 30 minutes in the store
<mxpxpod> :D
<lamont> Kamion: that is, even without the fix, hppa has plenty to do for a while yet.  So stalling another day or 2 won't really hurt me.  Once it hurts main, then we have an issue.
<lamont> but I think that requires that coreutils or procps get uploaded
<jbailey> Part of the trick to fridge shopping is to get a reasonable price.
<jbailey> Picking the fridge will take 2 or 3 minutes.
<jbailey> "Has freezer.  Is frost-free"
<jbailey> Stove: "Has self clean"
<jbailey> Washer/dryer: "Is cheap"
<lamont> jbailey: sometimes picking the fridge is 2-3 hours.  depends on wife's mood
<jbailey> lamont: Right.  But you see, I have some leverage.
<Kamion> lamont: I'm just testing the fix now
<jbailey> We don't have a fridge at all right now, and we just spent $1000 or so to move between provinces.
<jbailey> So there's incentive to just pick the first one we see. =)
<lamont> jbailey: and who's choice was it to move?
<lamont> yeah
<lamont> kill-mentality
<jbailey> Depends if you're with revenue canada or not.
<mdz> does anyone remember why we didn't add the bluez stack to the default desktop?
<jbailey> If you are, then I was moving to be closer to Bjorn and Brad.
<jbailey> (Thus making the move for work)
<lamont> jbailey: good answer
<lamont> mdz: that's bluetooth?
<ogra> mdz, because it was the job of the guy responsible for the goal ? 
<ogra> ah, and its a bounty now
<ivoks> khm... iproute has one nasty bug, fixed in 3.1, but not in hoary
<ivoks> causes 100% proc usage
<ivoks> by user, not root
<ogra> ivoks, good catch, bug it :)
<ivoks> it allready is
<ogra> great
<ivoks> should i fix it?
<ivoks> :)
<ogra> sure
<ivoks> it's in main
<ogra> fix it, attach the patch to the bug ;)
<ivoks> ok
<Riddell> "Failed to fetch http://gb.archive.ubuntu.com/ubuntu/dists/breezy/main/binary-i386/Packages.gz  MD5Sum mismatch
* seb128 kicks mvo
<Riddell> "
* ogra kick moodle... (inspired by seb128 ) 
<pitti> seb128: now this trouble also exists in sid
<ivoks> hm..
<seb128> pitti: esound?
<pitti> seb128: my sid pbuilder failed horribly because of that md5sum mismatch thingy
<ivoks> it's kernel related patch
<pitti> seb128: no, apt
<seb128> oh
<ogra> ivoks, #ubuntu-kernel to discuss it ;)
<mxpxpod> jbailey: ok, so if everything in my ldd of /usr/lib/libwnck-1.so.16 points to /usr/lib, then what?
<pitti> seb128: I thought you kicked mvo because of Riddel's apt message :-)
<seb128> pitti: I don't kick mvo about that :p
<pitti> well, then *I* do :-)
<pitti> seb128: Advanced Pain Tool :-)
<seb128> pitti: I kick him because he has dropped all the references to the Ubuntu patches while syncing gnome-system-tools with Debian, so now to guess what patches are Ubuntu specific and what they do
<jbailey> Well, let's stick to the binary that we're using rather than the library.
<jbailey> In case the error message is wrong.
<mxpxpod> jbailey: oh, right
<pitti> seb128: we still have all earlier changelogs
* mvo runs from seb128 
<seb128> pitti: right, but that would be good practice to mention what patches are used
<pitti> mvo: fear the wrath of a furious French man!
<mxpxpod> someone shoot me... I have to figure out visual foxpro
<seb128> mxpxpod: still having your wnck issues?
<mxpxpod> seb128: yes :(
<jbailey> mxpxpod: Email me the output of this please: ldd /usr/lib/gnome-panel/wnck-applet | grep '=>' | awk '{ print $3 }' | sort
<mxpxpod> seb128: but jbailey is going to help me out
<jbailey> err
<jbailey> sha1sum $(ldd /usr/lib/gnome-panel/wnck-applet | grep '=>' | awk '{ print $3 }' | sort)
<Kamion> lamont: done
<mxpxpod> jbailey: that's going to be difficult until I get home :)
<mvo> seb128: if it's too anoying, I can do the merge (and fix the naming along the way)
<pitti> thom: firefox having *one* static copy of zlib in the code is painful enough, but *two*?
<jbailey> Ah, no command line mail?
<thom> pitti: um? seriously?
<mxpxpod> jbailey: no, I have to disconnect this computer to plug in my laptop
<pitti> thom: in security/nss/cmd/zlib and modules/zlib/src
<jbailey> mxpxpod: *lol*
<seb128> mvo: nop, I'm done with it
<pitti> thom: luckily both versions are old enough to not be affected by the recent issue
<thom> pitti: hahaha
<seb128> mvo: just it FTBFS now, seems you have dropped the relibtoolize patch
<pitti> thom: but that might not be true for future vulns
<mvo> seb128: yes, that's very possible
<thom> pitti: good luck with that then
* seb128 kicks dpath which is b0rked
* mvo wonders if seb128 is in kicking mood today 
<seb128> mvo: bah :p
<ogra> mvo, i join him happily with all this educational alpha state php crap here... 
<mvo> guys, releax, take a bit of vacation :)
<ogra> mvo, GRRRRRRRRR
<lamont> Kamion: thanks muchly
<lamont> morning elmo
<elmo> hey lamont
<pitti> mvo: good idea, I think I pick Prague at Friday :-)
<mvo> pitti: sounds like a good plan to me :) 
<malex> Riddell: I just read your question about scribus-doc. It has GNU FDL-covered tutorials and the main docs are under OPLv1. They are written by different authors who licensed them differently.
<Riddell> malex: how come it's in non-free but templates isn't?
<ogra> Riddell, i'm looking for a way to unite KDE and gnome help files.... do you know of any project that tried it... ? (edubuntu will have a mixed desktop and khelpcenter doesnt allow me to suppress non installed apps from the tree)
<Riddell> ogra: ubuntu-docs have tried havn't they?
<ogra> Riddell, good point... i didnt think about that... thats for pointing out :)
<mdke> we are shipping docs as html
<mdke> so any browser should be able to open em
<malex> Riddell: OPLv1 and FDL are not DFSG-free. scribus-template(1.2.1 only as there hasn't been an update for 1.2.2) is GPL.
<mdke> yelp/khelpcenter
<ogra> mdke, yes, but i'd have to hack up the apps (or at least the libs calling the help viewer) 
<mdke> ah
<mdke> btw, does anyone have some convenient webspace for the documentation team to host preview versions and status reports of their books?
<ogra> mdke, i want the docs to show up either in the helpviewer of the currently used desktop or in a globally defined one.... using the KDE helpcenter seems not appropriate with this tons of links that point to nowhere
<ogra> i'm wondering why they built it that way
<mdke> ah i c
<ogra> should be easy to shouw only apps in the tree that are actually installed
<mdke> what happens with ubuntu at the moment?
<mdke> if both kubuntu-desktop and ubuntu-desktop are installed
<ogra> kubuntu just uses khelpcenter as is afaik... but Riddel might prove me wrong
<ogra> Riddell even
<Riddell> malex: scribus-template/debian/copyright says it's part public domain and part FDL
<ogra> mdke, curretnly it happens as i described it above...
<mdke> ogra, so any solution would maybe be best applied to ubuntu as well as edubuntu?
<ogra> yep
<ogra> ubuntu is my upstream, so finding a solution there would be the main target
<Riddell> ogra: surely khelpcentre just doesn't show non-installed apps?
<ogra> Riddell, if i click on help, the tree on the left is fully populated...
<malex> Riddell: My mistake - you are right about the scribus-template. If it will be updated for 1.2.2 then I will upload an update into Debian/non-free.
<Riddell> malex: ok, I was just checking that it wasn't me getting confused
<mdke> ogra, i'm afraid I don't know much about how docs are registered, but you could mail our list, someone will know
<ogra> mdke, i'll do... 
<mdke> any takers on the request for webspace?
<Lathiat> request for web space?
<ogra> mdke, elmo is moving houses :) 
<mdke> yeah
<Riddell> malex: success so far http://people.ubuntu.com/~lamont/buildLogs/s/scribus/1.2.2.1-1ubuntu1/
<ogra> so let him take a deep breath :)
<ogra> mdke, and then poke again :)
<mdz> jbailey: can we use the same approach you did in initramfs-tools to replace PCI coldplugging on boot?
<mdke> ogra, i'm not asking for anything from elmo. Basically we are waiting on a server, until then, I was just looking for some space to host the docs temporarily. A kubuntu dev has provided some for the kde docs
<mdz> jbailey: I assume it would be faster
<malex> I'm trying to set up hoary and breezy chroots for building Scribus cvs packages, but debootstrap seems to be looking for "main" at http://archive.ubuntu.com/ubuntu and fails. Is there a different archive or a different option to debootstrap?
<ogra> mdke, ahh, i thought you mean the upcoming infrastructure
<malex> Riddell: That's great that it builds fine. 
<mdke> ogra, i'm sure one of us can do it if necessary
<mdke> ogra, ah no we can be patient for that :D
<Riddell> Kamion: the package with section non-free/doc got rejected
<Riddell> malex: what's the failure?
<Riddell> malex: there's currently some md5sum issue with the archive
<malex> Riddell: E: Invalid Release file, no entry for main/binary-386/Packages
<malex> Riddell: I run it as debootstrap --arch 386 hoary /chroot/hoary/ http://archive.ubuntu.com/ubuntu/
<malex> Riddell: There is a /usr/lib/debootstrap/scripts/hoary script...
<mdke> mako, around?
<Riddell> malex: --arch i386 
<Riddell> add an "i"
<jbailey> mdz: I'd like to yes - that way we have consistancy of HW detection everywhere.  I'm just reading over some new udev/hotplug stuff that md poked at me.
<malex> Riddell: you are right. Thank you.
<malex> Is there a /usr/lib/debootstrap/scripts/breezy script somewhere?
<malex> Or should I stick to warty/hoary for upstream package building?
<Riddell> malex: http://wiki.ubuntu.com/DebootstrapChroot
<Riddell> malex: you need the package from breezy, grab my recompile there
<Kamion> Riddell: I think you need to get it synced from Debian first
<malex> Riddell: Debian is 0.3.1.4 and your build is 0.2.45.
<Riddell> Kamion: bah, we're too impatient for that :)
<Kamion> Riddell: (AFAIK we handle components a bit differently for syncs from Debian and for packages introduced directly to Ubuntu)
<malex> Riddell: Can I just grab the breezy script from your debootstrap package or are there more changes?
<malex> I am creating all chroots on a sid system.
<malex> hoary chrooted fine
<Kamion> malex: you can't just use the breezy script without new debootstrap as well
<Kamion> it relies on new features in core debootstrap
<Kamion>  scribus-template (1.2.1-1ubuntu1) breezy; urgency=low
<Kamion>  .
<Kamion>    * Ubuntu build
<malex> Kamion: I have the debian debootstrap from sid 0.3.1.4
<Kamion> Riddell: what does that mean? it doesn't say anything about what's changed
<Kamion> malex: should be OK, then
<malex> Kamion: 1.2.1 is the old one.
<malex> Kamion: Riddell has just gotten the 1.2.2.1 built
<Kamion> malex: I'm inquiring about Riddell's changelog entry, which is uninformative.
<Kamion> if it's just a merge, then one should use the -v option to dpkg-buildpackage / debuild in order to include older changelog entries so that readers of the -changes lists can tell what's going on
<Riddell> malex: grab latest debootstrap and recompile http://packages.ubuntu.com/breezy/admin/debootstrap
<malex> Riddell: I just copied the breezy scripts from your 0.2.45 package and the current debian bootstrap is getting breezy seemingly fine so far.
<Kamion> dexconf: error: cannot generate configuration file;
<Kamion> xserver-xorg/config/inputdevice/keyboard/layout not set.  Aborting.
<Riddell> Kamion: there's no changes, I havn't heard of the -v option
<mdz> jbailey: if we're going to do that for breezy, now would be the time
<Kamion> daniels: ^-- on fresh install
<Kamion> Riddell: what was the upload for then?
<malex> Should I set up a warty chroot and build packages for warty for my upstream repositories or forget warty and only do hoary/breezy?
<Riddell> Kamion: hmm, I didn't realise it was already in breezy
* malex has no idea of the rate of obsolescence of older releases in Ubuntu
<Riddell> checked scribus and scribus-doc but must have missed checking that one
<infinity> Riddell : But if there were no source level changes, why upload with an *ubuntu1 version, rather than request a sync?
<Riddell> infinity: because there are changes in the other two scribus packages, I was just incompetant with that one
<Kamion> Riddell: even if it weren't already in breezy, the correct way to get a package into the distribution that's already in another distribution is to request a sync
<Kamion> that way we don't carry the no-op changelog diff
<Riddell> Kamion: no-op changelog diff?
<infinity> Riddell : MOM will now be picking up that package for merges, because of the *ubuntu* version number, and will be patching the tiny changelog diff in (and automatic syncs will stop)
<Kamion> right, what infinity said
<infinity> Riddell : Of course, all of this is easily fixed by requesting a manual sync the next time Debian revs their version.
<infinity> Riddell : You just have to remember to do so. :)
<Riddell> infinity: ok, who's the person to request that from?
<Kamion> elmo
<Kamion> as with all sync
<Kamion> s
<Riddell> right
<Kamion> daniels: (that kills the install)
<Riddell> infinity: do you know why kexi is dep-wait on libmysqlclient-dev when it has a dependency on libmysqlclient12-dev?
<infinity> Riddell : I suppose it's been like that for ages.  Ancient bug I fixed in the auto-dep-waiter.  Lemme clear it.
<infinity> (Or is this a recent upload?)
<infinity> If so, then it's a new and fun bug.
<Riddell> infinity: no it's been there for a good while
<infinity> Riddell : Kay, should be happy now.  Unless it's not for other reasons.
<Riddell> infinity: I don't need to upload do I?  just wait for it to build?
<mdz> Kamion: did you promote docbook2x?
<infinity> Riddell : Just wait, yes.
<Kamion> mdz: yes
<Kamion> 10:17 < seb128> Kamion, mdz: can one of you promote docbook2x (approved by pitti for gnome-doc-utils) and libexchange-storage1.2-dev (lib for evolution-exchange moved) to main the corresponding ftbfses?
<Riddell> infinity: cool, thanks
<mdz> Kamion: I've rearranged https://wiki.ubuntu.com/UbuntuMainInclusionQueue to help keep track of that processing; remember to update it when you promote things
<infinity> Riddell : I stand corrected, an upload will be required.  Missing build-dep.
<infinity> Riddell :
<infinity> collect2: ld returned 1 exit status
<infinity> make[5] : *** [libkexidbparser.la]  Error 1
<infinity> Erm.
<infinity> Stupid BitchX.
<infinity>  /usr/bin/ld: cannot find -lXi
<infinity> collect2: ld returned 1 exit status
<infinity> make[5] : *** [libkexidbparser.la]  Error 1
<infinity> Better.
<Riddell> infinity: ah well that wasn't a required build-dep when I uploaded before :)
<infinity> Picky, picky.
<Riddell> I presume there's no way to find out a list of packages that need the xi-dev build-dep added?
<infinity> grep the build logs for -lXi, or we fire up the auto rebuilding mojo.
<Kamion> mdz: ok
<infinity> (The lattor of which I assume I'll be turning on shortly after upstream freeze, as things settle)
<infinity> s/lattor/latter/
<infinity> I'm betting a fair number of packages have become FTBFS since the X modualrisation began, so the rebuild tests will be somewhat critical this time around.
<xTina> Is there a configuration file for apt-ftparchive available anywhere that will simply recreate all Contents, Packages and Release files on a Ubuntu mirror?
<mdz> xTina: I don't know of one, but it stands to reason that one might
<mdz> the one used for the master archive has a bunch of other stuff in it that I expect you wouldn't want
<mdz> I wrote a small script which would regenerate Packages and Release files, for use with CD customization
<xTina> mdz: It probably doesn't deal with different architectures being available, does it?
<mdz> xTina: no, since I created it for CDS
<mdz> CDs
<xTina> I can't figure out what to do in order to put only arch packages in the ...-arch/Packages files. If I use the samples that are floating around the net for modifying CDs I have all architectures in my index files. The only thing I found was the Architectures option which didn't change anything.
<mdz> xTina: you need to give it separate file lists
<siretart> hi
<jordi> mdz: what happened to you? Suddenly... you appear so... unreal!
<siretart> how should I understand Kamions mail concerning the release update? when will autosyncing for packages in universe/multiverse from debian stop? tomorrow or on 21 July?
<siretart> hi mark!
<sabdfl> hey guys
<mdz> jordi: are you looking at me?  I thought you went home! ;-)
<jordi> *g*
<ogra> hey jordi 
<ogra> hi sabdfl 
<jordi> hi ogra!
<eruin> anyone in here know of any reported bugs ala "gnome only starts on second try" ?
<eruin> and, is bugzilla or malone preferred for reporting?
<ogra> eruin, bugzilla for main bugs, malone for universe
<eruin> ah, silly me
<eruin> ;)
<mdz> eruin: I've seen some of that sort of behaviour
<eruin> yeah, this is on current breezy, and I'm not sure how to debug it properly
<eruin> the session just doesn't load, although after a gdm restart I can login fine though I get an error about gnomepanel already running
<eruin> that was a bad sentence, I know :P
<sabdfl> hey ogra
<eruin> ohwell, I'll be back when I've got something usable to report
<{SebPayne}> chrisstiturm: are you around?
<{SebPayne}> chrissturm told me that i had to make a new link after upgrading Xorg on breezy
<{SebPayne}> any idea what the link for /usr/bin/X11/X should be?
<jordi> mdz: have you got patches for apt 0.6 to mark a few strings for translation?
<xTina> mdz: How would I get those file lists?
<mdz> xTina: find
<mdz> jordi: no, I don't think so.  are there strings which should be marked but are not?
<xTina> mdz: find in 'pool' according to the architecture of the .debs?
<jordi> I just found one in apt-get.cc
<jordi>       c2out << _("Authentication warning overridden.\n");
<jordi> mdz: line 691
<jordi> and I'd swear I have another one
<jordi> let me look
<mdz> jordi: that string looks like it is marked for translation :-P
<jordi> mdz: I did :)
<{SebPayne}> does anyone any idea when the next X version is coming?
<Kamion> siretart: autosyncing stops tomorrow/Friday/thereabouts; the 21st July deadline is for merges of uploads to Debian that happened up to tomorrow
<jordi> mdz: see it?
<mdz> jordi: see what?
<mxpxpod> jbailey: when you get back, let me know
<Kamion> elmo: speaking of, ready to stop syncing end of tomorrow?
<mdz> Kamion: yeah, we talked about it a short time ago
<siretart> Kamion: oh, I see. then my questions I posted to the mailing lists still stand
<jordi> mdz: the string that isn't marked for translation
<jordi> What I pasted included my modification, the current package has no markers
<mdz> jordi: I saw the string you pasted
<mdz> I didn't look in the source for more
<malex> Is "deb http://archive.ubuntu.com/ubuntu/ hoary main restricted universe" the main ubuntu archive? 
<Kamion> malex: yes, depending on what you mean by "main"
<malex> Kamion: master archive?
<jordi> mdz: gpgv.cc: "The following signatures couldn't be verified..." untranslated.
<malex> Kamion: I am looking for the main archive or a fast mirror for hoary and breezy packages for my pbuilder chroots.
<mdz> jordi: a patch would be great
<Kamion> malex: yes, that's the primary mirror
<mdz> or a baz branch if there are a lot
<jordi> i feared. I will send one :)
<Kamion> malex: (the master archive is not accessible to the world, only to a few internal mirrors)
<Kamion> malex: we recommend you use $COUNTRY_CODE.archive.ubuntu.com, so if you're in France you'd use fr.archive.ubuntu.com, for instance
<malex> Kamion: "primary mirror" is just what I was looking for.
<malex> Kamion: I'm in the us, so us.archive.ubuntu.com for me...
<Kamion> malex: some of those country mirrors are actually just aliases for archive.ubuntu.com, but may not always be so
<Kamion> I think us.archive.ubuntu.com currently == archive.ubuntu.com, but that's a temporary situation
<malex> Kamion: I will use us.archive... to be on the safe side.
<Kamion> yep, that would be sensible
<Kamion> I think most of the country mirrors pull every six hours or so
<jordi> mdz: when you do returns and have something to mark for translation, is that when you use string()?
<jordi> ie, here?
<jordi>       return "At least one invalid signature was encountered.";
<mdz> jordi: _() should be fine there; it returns a const char*, right?
<malex> So, breezy doesn't have an en_US.ISO-8859-15 locale at all?
<jordi> mdz: yes
<Kamion> malex: no, ISO-8859-15 doesn't make much sense for the US
<Kamion> hm, actually, I tell a lie
<Kamion> malex: yes, it's there, you have to enable it with 'dpkg-reconfigure locales'
<jordi> Kamion: what about poor americans wanting to express Euro? :)
<malex> Kamion: no, it's not in the list.
<Kamion> I suppose it was added for financial interoperability or something
<Kamion> huh, you're right, I was looking in sid
<Kamion> jordi: they can use UTF-8
<Kamion> strange that it was removed, perhaps it was a Debian patch or something - upstream don't normally remove locales
<malex> Kamion: Debian still has it
<malex> Kamion: So, it was a Ubuntu breezy patch, most likely, as hoary still has it.
<Kamion> malex: breezy's glibc is based off Debian experimental
<Kamion> malex: if you're not looking at the latter, you aren't getting an accurate picture
<malex> Kamion: So, what is the proper procedure of building a Ubuntu package from a debian package? I have a hoary/breezy chroot installed, got the build-deps for my package, got my source package. What should I do with the changelog/version?
<Kamion> nothing, unless you need to change the source package for some other reason
<Kamion> debuild -b
<Kamion> hmm, so there is a locales-supported.dpatch in the glibc source package which adds en_US.ISO-8859-15; upstream does not have it
<Kamion> however, that patch is disabled
<Kamion> jbailey: ?
<malex> Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/d/devscripts/devscripts_2.8.6_i386.deb  MD5Sum mismatch
<jbailey> -15 is latin 1 with a euro sign isn't it?
<jbailey> mxpxpod: I'm back. =)
<Kamion> jbailey: yes
<mxpxpod> jbailey: I figured it out
<Kamion> +#locales-supported     # g: untilsarge
<mxpxpod> I reinstalled libxext6 and libxext-dev and now all is fine
<mxpxpod> seb128: you know that gconf error I was getting the other day?
<Kamion> same comment in Debian experimental
<Kamion> jbailey: I'd venture to suggest that sarge has happened ;-)
<jordi> mdz:          return (string("Internal error: Good signature, but could not determine key fingerprint?!"));
<jbailey> Kamion: Right, I think that's why it's commented out now.
<jordi> mdz: I assume this also needs marking, right?
<jordi> jbailey!
<jbailey> Heya Jordi!
<jordi> jbailey: I updated your blog url for planet
<malex> What's up with the md5sums for hoary?
<jbailey> jordi: Eh?
<Kamion> jbailey: it seems a slightly strange decision to have added that locale, but now that it was added I don't think it should have been removed ...
<mxpxpod> jbailey: pretty strange, eh?
<Kamion> hm, us.archive.ubuntu.com != archive.ubuntu.com at the moment
<jordi> jbailey: when you switched to phpblosxom, your rss url changed and it broke your planet subscription
<Kamion> so perhaps it synced badly
<jbailey> Kamion: I'd have to look at that locale specifically, but I suspect that we decided that once Sarge released that we would drop all of the locales that upstream had refused to give everyone (.. What's the formula?  each release cycle doubles in length?) N time to adjust.
<malex> Kamion: probably a bad sync, as breezy packages are fine, only hoary has the md5 problem.
<jbailey> mxpxpod: Whacked.  Ah well, I'm glad it's working.
<mxpxpod> jbailey: me too :)
<jbailey> mxpxpod: Did you just reinstall each piece one by one?
<Kamion> jbailey: hm. removing en_GB.ISO-8859-15 was a bit fucked, though
<mxpxpod> jbailey: no, I did the ldd thing and then figured out where the Xext* symbols would be and reinstalled that package
<jbailey> Isn't that an upstream locale?  I would've thought it was...
<Kamion> nope
<jbailey> Harumph.
<Kamion> looks like upstream have an overly legalistic viewpoint
<jbailey> Kamion: that's a polite way of talking about needing a boot to the head, but ah well.
<Kamion> true, the UK is not one of the Euro countries (bah), but that doesn't mean UK people don't have to deal in Euros an awful lot
<Kamion> at least businesses
<Kamion> but I suspect Ulrich would say "just use UTF-8"
<jbailey> Mhm
<jbailey> I wish that character set could be more trivially separated from everything else.
<Kamion> $ bzcat Packages.bz2 | grep-dctrl -P devscripts -nsMD5sum
<Kamion> 1d3b5e583cdacf3dd2c2f752b710c8bf
<Kamion> $ md5sum devscripts_2.8.6_i386.deb
<Kamion> 2b21c93ea612f3f29d10318ce42111d7  devscripts_2.8.6_i386.deb
<Kamion> hmm
<Kamion> the Packages file is right; that file is corrupt on the mirror
<Kamion> the master is fine
<malex> Kamion: just as you suggested
<tvo> does breezy come with an inotify-enabled/patched kernel?
<chrissturm> anyone aware of a flash plugin that works with the gcc4 compiled firefox?
<ogra> Kamion, UVF for universe ??
<ogra> we didnt do that for hoary
<Kamion> ogra: MOTU was only just getting started for hoary, and hadn't had time
<Kamion> for breezy, there has been plenty of time to get things into shape
<ogra> Kamion, but it worked quite well..
<Kamion> not really, there was a huge panic at hoary release and various people wanted to update hoary after release because you hadn't had time to stabilise it beforehand
<Kamion> anyway, I have to go out now, sorry
<ogra> Kamion, not really, Cxx transition is still ongoing and missing ~500 packages
<Kamion> ogra: that's not affected by UVF
<ogra> Kamion, but it postpones other things
<Kamion> and this is not a hard freeze, it just means you have to get approval
<Kamion> which is not intended to get in your way, it's an extra review step, as I said
<ogra> Kamion, but might steal your time
<Kamion> right, I really have to run, Kirsten is waiting
<Kamion> ogra: talk to mdz
<ogra> oki, have fun :=
<ogra> :)
<Seveas> jdub, around..?
<seb128> ogra: I'm going to package gnome-screensaver if you don't work on that
<mxpxpod> seb128: ok, so I fixed that gconf issue I was having
<seb128> mxpxpod: cool, how?
<mxpxpod> seb128: I had a ~/.gconf/schemas/apps/workspace_switcher_applet for some reason
<ogra> seb128, jdub already asked me to do it, but go ahead if you want to grab it
<mxpxpod> so I removed it, shut down gconf, and it worked
<seb128> ogra: as you want, I have planned to give a shot of the packaging now but if you want to work on it no problem
<seb128> mxpxpod: ~/.gconf/schemas/apps/workspace_switcher_applet is an user setting ... what's wrong with it?
<ogra> seb128, then we'd have to wait until edubuntu leaves me some free time again... so go ahead :) i want to see it :)
<mxpxpod> seb128: I think the values in there on my system were messed up
<seb128> k
<seb128> mxpxpod: and that makes this symbol errors??
<mxpxpod> seb128: oh, no... that was something with libxext-6
<ogra> i have to package some real crack here before i can move on to something more funny...
<mxpxpod> seb128: when I reinstalled libxext6 and libxext-dev, it fixed the problem
<seb128> mxpxpod: k, cool
<mxpxpod> I'll go close the bug
<mxpxpod> seb128: bug closed
<seb128> thanks
<mxpxpod> thanks for all the help
<seb128> np
<jammcq_office> hey guys, we'll be showing Ubuntu at our LTSP.org booth at LinuxWorld in SanFran again this year, who should I talk to about getting a box of cds to hand out?
<elmo> jammcq_office: mako
<jammcq_office> k, thanks, sorry for the interruption
<mgalvin> elmo, ping
<Keybuk> meh
<Keybuk> openwrt doesn't have "watch" on it
<elmo> quick, someone give me a small package that has a newer version in breezy
<elmo> heh, I know, let's test backports with... DPKG!
<ogra> haha
<wasabi_> "eclipse"
<jbailey> ajmitch: awake yet? =)
<elmo> dpkg_1.13.10~hoary1_source.changes
<elmo> ACCEPT
<elmo> lalalalalalalalala
<wasabi_> haha
<mgalvin> elmo, i know ur busy, svn account? would you possibly have some time to set it up soon?
<elmo> mgalvin: yeah, in a sec
<mgalvin> elmo, ok thanks
<siretart> mgalvin: I just rechecked your update to cegui
<siretart> mgalvin: currently 17 packages (mostly xfce) is build depending on cegui
<siretart> mgalvin: did you check that all packages still build with that new version? why do you think that update is necessary?
<ajmitch> jbailey: of course I was ;)
<mgalvin> siretart, cegui has nothing to do with xfce (i don't think), this is ceguimk2 (libcegui-mk2-0, libcegui-mk2-dev, -doc, -dbg), NOT libxfcegui
<mgalvin> siretart, its a lib for game ui's
<mgalvin> ogre uses it
<siretart> mgalvin: oh, you're perfectly right..
<mgalvin> siretart, the update is necessary to get the new (working) version of ogre3d which many games use
<siretart> mgalvin: ic. what about ogre? does ogre still build with the new version?
<mgalvin> long story short, ogre3d from cvs builds with this new version of cegui-mk2-0.3.0
<mgalvin> the latest ogre release is broken, so it has to be the cvs version
<mgalvin> but they work together
<mgalvin> plus iirc the version of ogre in debian FTBFS on breezy (and hoary for that matter)
<siretart> mgalvin: ok, so you checked that there are no visible regression. ok, then I don't have further objections :)
<mgalvin> siretart, correct. great :)
<mgalvin> siretart, before you advocate it...
<mgalvin> i did notice that the build deps in breezy changed, i would like to verify those deps before you approve it. I will check this an upload a new version when i get home
<siretart> mgalvin: I just checked, it FTBFS because of some libdevil-dev
<mgalvin> right, thats the one
<mgalvin> there are some glut deps that seem to have changed that i need to fix
<siretart> all right. I added a comment about this in revu. just upload a new version when it's ready
<mgalvin> ok, i will do
<siretart> mgalvin: what about libcwd? is this case solved?
<mgalvin> sync it from debian, its already there
<siretart> so I may nuke it from revu, ok?
<mgalvin> siretart, its been there for weeks
<mgalvin> yup
<mgalvin> boom
<siretart> :)
<Mez> hey seth
<seth_k> hi mez
<mgalvin> gotta run, l8r all
<elmo> lamont/infinity: it's entirely possible I'm about to break your buildds or already have done
<elmo> if either of you are around that'd rock ;-)(
<seb128> pitti: around?
<pitti> seb128: yep
<seb128> pitti: do you know who has sudo rights nowadays on a default installation? An user or the admin group?
<pitti> seb128: the admin group
<seb128> k
<pitti> %admin	ALL=(ALL) ALL
<seb128> pitti: and is there any way for an user process to know if the user has sudo rights?
<pitti> seb128: none that I know of, apart from just trying
<seb128> pitti: lllmanulll is working on the GnomePanel spec, we want to hide menu entries which require sudo for non-sudo users
<pitti> seb128: ah, that would be indeed nice
<pitti> seb128: if you just check for admin membership you will miss upgraders from warty
<seb128> we can't ask to an user to enter his password on startup to know if he has sudo rights :p
<pitti> no, right
<siretart> how about doing an $(groups $(user) ) and grepping for 'admin'?
<pitti> see above
<seb128> for the reason pitti just said
<seb128> in fact I ask because my install has 
<pitti> would certainly work for the majority of users
<seb128> user ALL=(ALL) ALL
<pitti> but unrealiable
<seb128> and an admin can change whatever he wants
<pitti> right, even partial rights
<siretart> right.. hm
<pitti> seb128: I guess we need a small setuid wrapper for that
<seb128> pitti: any opinion on what would be a good approch for this?
<seb128> hum, maybe
<pitti> seb128: a reasonably good heuristics for Ubuntu would be ingroup(admin) || uid == 1000
<pitti> seb128: but that's neither suitable for upstream nor a really good solution
<pitti> but the only one that doesn't need root rights
<seb128> lllmanulll: do a function with that to start maybe, we can still figure and another way later
<lllmanulll> ALl right
<seb128> pitti: thanks
<pitti> seb128: a setuid wrapper could check /etc/sudoers and return the result in its exit code
<pitti> seb128: we should use sudo's existing parser for that, of course
<seb128> pitti: that would be a better option probably
<pitti> seb128: it would work reliably and it is cleaner, but requires setuid root, so it should be very small and auditible
<seb128> right
<seb128> thanks
<pitti> geez, why must unix mail servers be so complicated...
<ivoks> ?
<ivoks> they are pice of cake :)
<ivoks> specialy postfix :)
<pitti> ivoks: I try to setup SSMTP+SSL authentication in exim4
<ivoks> i have that in postfix :(
<pitti> ivoks: this has worked once, but now I just get a "connection refused" for all but localhost connections
<ernstp>  found a bug on the colony 2 install cd, and a daily installer two days later
<ernstp> both cd's checked out ok on integrity test
<ernstp> they both hard lock right after the "Would you like to download additional language support"
<pitti> ivoks: I didn't find any good docs for postfix either, so I just kept the exim4 install
<ivoks> pitti: if you want, i could tutor you... you need 5 minutes :)
<pitti> ivoks: this is my production system...
<pitti> primary mail hub for five persons...
<ivoks> :)
<ivoks> ok
#ubuntu-devel 2005-07-12
<ompaul> whats the eta on colony 3?
<mdke> we only just had colony 2
<ompaul> mdke, this is true, but august is really close, I was going to wait till after the weekend if it was due out between now and Monday
<usual> is X borked in breez?
<ernstp> usual, X is great in breez
<seth_k> sort of
<seth_k> takes some fixing but works fine
<usual> which s it
<usual> ok
<seth_k> i'm running it right now on two machines
<usual> I get errors about X not exisiting
<mdke> usual, did you update?
<usual> mdke, not today but todays updates for me were nothing but openoffice
<usual> mdke, I updated yesterday and X went south
<mdke> i think it should be fixed either now or very soon
<usual> k
<usual> no biggie of course I expect it with the unstable but if there was a fixI would certainly want it :)
<seth_k> usual: what error do you get?
<mdke> i think its a sym link needed
<mdke> but not sure
<mdke> best to check bugzilla and see if there is a fix
<usual> seth_k, not exactly sure at the moment as I am not on that box but it was something along the lines of X can't be found or doesn't exist
<usual> k
<seth_k> usual: the only problems I'm seeing this week are "X not executable" errors, which can be solved with:
<seth_k> sudo ln -sf /usr/X11R6/bin/Xorg /etc/X11/X
<seth_k> ymmv
<usual> k
<usual> lemme try that
<usual> thanks
<lamont> pitti: best SASL/postfix docs are bugs filed against postfix/postfix-tls asking me to automate it, in the debian bts... a couple of them have the steps required... :(
<pitti> lamont: thanks for the hint :-)
<pitti> lamont: so far I successfully converted from exim to postfix on my server
* lamont misses elmo by ~ 8 minutes, grumbles
<mrd`> Anyone else having problems with linux-image-2.6.12-3-k7?  Whenever I boot it, top shows 80+% of my CPU time being used and powernowd steps up my processor to full speed, but no apps actually seem to be using anywhere near that much CPU time.  linux-image-2.6.12-2-k7 works fine, however.
<seth_k> mrd`: I'm using that exact version (k7 even), and I'm having issues with my system clock running about 20x too fast
<mrd`> Hm.
<seth_k> I went back to 2.6.10 for now
<seth_k> the funny thing is my laptop is running 2.6.12 and has no issues
<seth_k> just the desktop
<mrd`> Is the laptop running 2.6.12-3-k7 or a different 2.6.12 kernel?
<lamont> pitti: and I'm a slacker... it's on my list of things to try to have done for breezy (selfsigned cert for SASL/TLS, config by default, with debconf questions to DTRT)
* mrd` 's laptop handles 2.6.12-2-k7 fine, just something between that and -3-k7 broke.
<seth_k> oy, true. the laptop is running -686
<seth_k> they are both running -3
<mrd`> Hm.
* mrd` wonders where in bugzilla you report kernel problems.
<mrd`> There doesn't seem to be a linux-image package.
<lamont> mrd`: you might try linux-image-386...  there should be a linux-image-k7 as well
<mrd`> lamont: I don't see anything prefixed with linux-image.
<mrd`> In Ubuntu's bugzilla.
<lamont> ah, for that you may want to just use linux-source-2.6.12 or so
<lamont> worst case, you file it against unknown
* lamont must run
* mrd` didn't think he saw any linux-source packages either... but I'll look again.
<ivoks> that reminds me...
<chrissturm> isnt the package just "linux"?
<ivoks> we should configure Maildir/ not mbox for ubuntu
* mrd` looks for a 'linux' package then.
<mrd`> Oh, d'oh.
* mrd` wonders how he missed that.
<Burgundavia> seb128, services-admin appears to use it own authentication dialog
<seb128> Burgundavia: right, the desktop is not patched to use gksudo ... I'll fix that
<Burgundavia> seb128, cheers
<Burgundavia> is the us.archive still having md5 sum issues?
<seth_k> Burgundavia: nalioth says yes
<seth_k> Burgundavia: I haven't had any recently, but maybe some packages?
<Burgundavia> ok
<seth_k> Burgundavia: somebody just had one with audacity as I was typing :P
<Burgundavia> ok
<seth_k> nalioth reports GB archive also experiencing issues
<Burgundavia> hmm
<Burgundavia> I have had no issues with the CA archives
<seth_k> try Audacity
<seth_k> CA == US, and somebody just reported that package had a mismatch on US
<doko> fabbione: OOo2 1.9.113-1ubuntu2 will be built using g++-3.4 on sparc. please retry
<mgalvin> hey all, has any else noticed this
<mgalvin> Failed to fetch http://us.archive.ubuntu.com/ubuntu/pool/main/libs/libsndfile/libsndfile1_1.0.10-2_i386.deb  MD5Sum mismatch
<seth_k> indeed
<seth_k> us mirror is having issues
<mgalvin> ah, ok, thnx
<seth_k> you can switch to http://archive.ubuntu.com in /etc/apt/sources.list if you want
<seth_k> e.g., remove all the "us."
<mgalvin> at least its not just me
<mgalvin> i will do that for now, thnx
<ogra> 
<Burgundavia> 
<Burgundavia> oh, you can do that
<mgalvin> ah thats wicked slow 3000B/s 10 min to d/l Packages file, ouch
<pitti> night, guys
<shackan> night pitti boy :D
<tiglionabbit> hello.  I am not part of development, but may I suggest that there be implemented a way to use the gui file browser with admin privileges in a later version?  Some ubuntu users want to edit their config files using the gui, as they do not know how to use the terminal properly
<mrd`> Why does the file browser need to run as root to edit config files?
<tiglionabbit> something like an entry in applications -> system tools for "Root File Browser" ( gksudo nautilus )
<crimsun> they already can using gksudo $app
<tiglionabbit> crimsun: what if they don't know to type that, and do not want to open a terminal?
<tiglionabbit> perhaps better then, add an entry to the right-click menu in nautilus for "Edit as Root" or something?
<crimsun> tiglionabbit: they can still use the Run menu entry
<mrd`> That's probably a better choice than running all of nautilus as root.
<tiglionabbit> true.  Seveas tells me that running nautilus as root will screw up Xauthority and cause a user to not be able to log in
<tiglionabbit> hm, I suppose run application would work.  I could just advise people to type "gksudo gedit" and the absolute path to the config file
<tiglionabbit> or just have them open it from gedit.  Anyway thanks
<chrissturm> it would be cool if i could just drag some file to some folder, nautilus would see that it cannot copy there, and ask if i want to copy with gksudo
<seth_k> chrissturm++
<tiglionabbit> chrissturm: I think what would be the best possible solution is, if there were a way the standard editors like gedit could call gksudo when they reach a permissions problem, rather than just saying it couldn't be written
<tiglionabbit> but the root file browser would be good just to be able to create directories and touch files
<bddebian> Standard editors like nano you mean? ;-P
<tiglionabbit> gui editors.  If they already can use nano, then they already know how to use the terminal, so there's no problem telling them to sudo that
<tiglionabbit> I'm talking about waaay newbies
* bddebian is a waay n00b :-)
<chrissturm> tiglionabbit, can unix processes sudo themselves, or is it just possible to start new processes as root?
<tiglionabbit> hm, the latter
<tiglionabbit> wow, I hadn't experimented with gedit.  It doesn't even let you mess with the file at all, does it
<chrissturm> tiglionabbit, so they would need to copy the file to tmp, and then move it with a new process
<HrdwrBoB> there is a wrapper for it
<HrdwrBoB> sudoedit I think
<HrdwrBoB> it starts $EDITOR iirc
<mrd`> It would be relatively simple to do something like fork a new process, and exec in that process "gksudo tee $file" and then write your data into that process's stdin.
<tiglionabbit> oo, sudoedit runs nano for me
<mrd`> (Though, I don't know if it's possible to tell if/when gksudo succeeded.)
<tiglionabbit> Hmm, perhaps in breezy you could add sudoedit as one of the default context menu items, and set the editor to something gui users would like?
<tiglionabbit> and also, instead of having the create directory/folder items greyed out, have them call gksudo mkdir and such
<HrdwrBoB> better off to make gedit ask you for sudo
<HrdwrBoB> rather than a secondary option
<tiglionabbit> and add the $EDITOR to "preferred applications"
<HrdwrBoB> f.e. [ This file is not editable by you, it's likely this is a system file and editing may change or damage your system. To open it, enter your password and hit ok, to close, hit cancell
<tiglionabbit> alright, however you want to handle it.  I'm just finding the joy of Ubuntu here, I can actually recommend it to people who prefer to use gui interfaces
<daniels> pittyeah
<daniels> Kamion: yah, will be fixed in -35
<chrissturm> what can be the reason if xorg throws a signal 11 at startup?
<HrdwrBoB> buggy radeon binary drivers
<chrissturm> it works with my radeon drivers, but on my notebooks i810 it signal 11s
<daniels> huh
<daniels> chrissturm: you're running dual-head, aren't you?
<chrissturm> daniels: nope. strange thing is it works now after i removed xserver-common, and reinstalled it
<daniels> ... errr
<Keybuk> daniels: why doesn't 3d work on my radeon?  *stamps foot*
<daniels> Keybuk: because it hates you, and wants you to die
<Keybuk> :'(
<bddebian> eeks
<bddebian> Brutal group :-)
<Keybuk> it's all about the CYCLONE
<Keybuk> THE CYCLONE OF HATE
<bddebian> Sheesh
<Keybuk> you don't believe me?
<bddebian> Keybuk: I believe EVERYTHING you say ;-)
<Keybuk> heh
<daniels> bddebian: you fool
<rob^> whats the Java (J2SE) package called in Breezy?
<rob^> just java-common?
<Keybuk> Once upon a time at the foot of a great mountain, there was a town where the people known as Happy Folk lived...
<wasabi> rob^, j2se package?
<bddebian> java-sucks?
<wasabi> You mean a java virtual machine?
<wasabi> We have a number.
<wasabi> java-gcj-compat is what we're going with right now
<rob^> yes, java virtual machine
<rob^> for apps
<wasabi> Depends which app
<rob^> azureus for one
<wasabi> We can't run it.
<wasabi> Get Sun's.
<rob^> just need some info for the FAQ
* bddebian feels no love :-)
<wasabi> You mean on a wiki?
<rob^> no, in the svn repo
<wasabi> FOr azureus itself?
<rob^> no, the official ubuntu one
<wasabi> Somebody made that.
<wasabi> I don't have an opinion on it at all.
<rob^> we are rewriting parts of it with the idea that it will be released with Breezy, so I just need to know if any sought of Java VM style package is included or do we still need to download Suns one
<tiglionabbit> say, is there any gui way to "Move" or "Copy" admin files?
<tiglionabbit> or any in plans
<wasabi> rob^, no Sun JVM package will ever be included.
<wasabi> Unless Sun changes their license.
<wasabi> But we have a number of free alternatives which are rapidly improving. We have Eclipse running.
<rob^> ok
<wasabi> And work on Azureus is proceeding (you will be able to apt-get install it probably breezy+1)
<rob^> I will add that people need to download it from sun
<rob^> thanks
<wasabi> I won't ever personally recommend you download anything from Sun.
<wasabi> However it's an option. :0
<rob^> :0
<rob^> :)
<bddebian> What about blackdown?
<wasabi> Blackdown is no differnet from Suns.
<wasabi> In fact it is Suns.
<bddebian> Oh. Hmm
<rob^> does it work?
<wasabi> No idea.
<daniels> ugh
<daniels> Kamion: ping
<whiprush> jdub: ping.
<jdub> whiprush: pong
<whiprush> I've been playing with the new nautilus side panel thinger. thoughts?
<whiprush> wrt. what we discussed at UDU?
<jdub> places? yeah. very happy to see it.
<bddebian> Anyone know if us.archive.ubuntu.com has problems?
<seth_k> it does indeed
<seth_k> fairly large ones
<seth_k> i've been recommending a switch from us.archive to archive.
<bddebian> It seems this has been ongoing.  What gives?
<seth_k> note that CA archive is the same machine as US
<seth_k> dunno what gives
<bddebian> mwuhaha
<bddebian> Better not tell those Canuks that.. ;-P
<robitaille> seth_k: for a while (1-2 weeks ago?) us.archive DNS  was pointing to archive. (just after the last set of problems with the mirror).  Obviously that DNS change was reverted at one point...
<seth_k> robitaille: thanks for the heads up. what causes the md5 errors?
<robitaille> I have no idea...
<bddebian> Usually corrupt package files but I'm not sure that is what's happening here.  Unless the files are getting corrupted on the download?
<robitaille> Interestingly I just noticed that ca.archive is pointing to archive tonight; not at us.archive as it is usually the case.
<robitaille> That explains why the 2   packages I just installed didn't generate any errors
<bddebian> Hmm, odd
<rob^> !w32codecs
<rob^> oops
<bddebian> heh
<daniels> gar, xorg is snowballing again :\
<bddebian> snowballing?
<daniels> ending up in one huge release
<bddebian> Ah
<daniels> daniels@brainfreeze:~/canonical/xorg% debdiff old/xorg_6.8.2-34.dsc xorg_6.8.2-35.dsc | diffstat | tail -1
<daniels>  194 files changed, 1734 insertions(+), 4063 deletions(-)
<seth_k> oy
<seth_k> release of doom
<daniels> even better than that is the post-hoary stat
<daniels> daniels@brainfreeze:~/canonical/xorg% debdiff hoary/xorg_6.8.2-10.dsc xorg_6.8.2-35.dsc | diffstat | tail -1
<daniels>  435 files changed, 189075 insertions(+), 36648 deletions(-)
<daniels> which isn't counting all the work that's gone on in the external packages
<luis_> time-based release!
* luis_ runs
<bddebian> hehe
<daniels> luis_: ha
<luis_> seriously, though, that does help prevent that exact problem
<daniels> luis_: sure, but even if I upload it a day later that I hope (which may well happen), that's still only been since monday
<daniels> modularisation helps more, really
<daniels> xorg uploads are frigging unwieldy at the moment
<daniels> and I feel guilty about having done 24 since hoary
<calc> daniels: good job with the updates :)
<calc> daniels: so is the source itself going to be split out as well?
<daniels> calc: totally
<calc> istr something about that with 6.9?
<daniels> nah
<daniels> 6.9 and 7.0 will release in parallel with the same code
<calc> ah ok
<daniels> but 6.9 will be an imake monolith, 7.0 will be autotooled and modular
<daniels> i've been nibbling at the tree from the bottom
<calc> great
<calc> oh btw -34 didn't seem to fix the /etc/X11/X symlink it was left dead
<calc> iirc it was pointing to /usr/bin/X11/Xorg
<calc> i manually pointed it at /usr/bin/X11/bin/Xorg
<daniels> /usr/bin/X11/bin/Xorg is quite obviously broken
<daniels> /usr/bin/X11 should be pointing at /usr/bin; if it's not, that's a separate issue
<infinity> That issue exists because /usr/bin/X11 didn't properly get turned into a symlink, so the ln -s ../bin /usr/bin/X11 landed in the directory, rather than replacing it.
<infinity> (I really hate thast ln behaviour, BTW... Very inintuitive)
<infinity> "Of course I wanted a link called "bin" in that directory, thanks!"
<bddebian> Aye
<infinity> I guess it's intuitive from the "behaves like cp and mv" perspective, but who uses ln "as if they were copying a file"?
* infinity waits for someone to say that they do just that.
<bddebian> I just do that
<bddebian> Happy now? :-)
<infinity> Thrilled.
<infinity> daniels : Still want me to fix x-common, or have you done so already?
<infinity> daniels : I can do it in the next hour or so.
<daniels> infinity: there's another ULI in ti for you
<infinity> Hot diggity.
<daniels> infinity: make it two if you want to finish modularising the server
<bddebian> ULI in ti?  Eeks
<daniels> 'ultimate long island in it'
<daniels> (incidentally, for shits and giggles, try googling for 'clueless noob', with or without quotes)
<infinity> I want it finished, but I don't want to finish it. :)
<daniels> i need to sort it on the weekend
<daniels> no idea when, thought
<bddebian> daniels: Are you trying to tell me something? :-)
<daniels> between stuff on friday night, stuff on saturday afternoon, stuff on saturday night ...
<infinity> daniels : Is that my cue to recompile my entire system against a different libc?
<daniels> infinity: different libc?
<fabbione> morning
<infinity> daniels : The 'clueless noob' -> drepper connection.
<daniels> oh, right
<daniels> not really, just entertaining
<daniels> the power of Planets and all that
<infinity> Does anything actually install files in /usr/bin/X11?
<infinity> Oh, yay.  xserver-xorg does.  (why?)
<daniels> nothing in breezy does, no
<daniels> uhm, not any more.  Contents needs updating.
<daniels> i fixed that particular brain damage in -34.
<infinity> Ah.  Xorg moved to /usr/bin, then?
<daniels> (i just zgrepped Contents as well)
<daniels> well, it's still in /usr/X11R6/bin, but the symlink moved to /usr/bin
<infinity> Check.
<infinity> So, why do we even care about having the directory/symlink at all?
<daniels> fhs, more or less
<daniels> x shit is defined to be available in /usr/bin/X11
<daniels> \o/
<infinity> Joy.
<fabbione> humpf.. this piece of crap is a catch 22
<infinity> Yeargh.  When did debdiff stop working for native packages?
<infinity> Feh.
<daniels> gar
<daniels> no keybuk, either
<daniels> anyone know how to do funky inclusion with automake?
<infinity> daniels : http://lucifer.0c3.net/~adconrad/x-common.diff
<infinity> Erm, but ignore debian/bar.
* infinity goes to remove that.
<daniels> i need to generate a Makefile with a shell-script at build-time (either ./configure or from within the Makefile), but I can't seem to get an include in
<infinity> (was a test file)
<infinity> daniels : If you're positive nothing should ever be living in /usr/bin/X11 on a user's system, then you can just rm -rf it, but the warning should be harmless if 99.9% of people won't ever see it anyway.
<infinity> (Have we accidentally created any files in /usr/bin/X11 along the way, other than "bin"?
<infinity> )
<daniels> infinity: not that I'm aware of -- rm -rf should be safe
<daniels> btw, I can't connect to lucifer.  chuck it on rookery, willya?
<infinity> Oh, duh.
<infinity> http://cerberus.0c3.net/~adconrad/x-common.diff
<infinity> Using an A record with a private address is smart, Adam.  Yes.
<daniels> heh
<mae> what do you all use as a development environment for GTK+ apps
<infinity> rm -rf is safe from the POV of dpkg (ie: we don't ship any files there), but users may prefer not to lose stuff they dropped there with "make install" at some point.  Hence the warning instead.
<daniels> infinity: looks good to me
<infinity> If you're pretty sure users won't have shit there anyway, then we can toss it.  Then again, if users wouldn't ever have stuff there, why is it in the FHS? :)
<infinity> (WHich leads me to believe someone might)
<daniels> mmm, probably safer just warning and/or bombing
<infinity> Yeah.  I like the warning, since bombing the postinst doesn't really help anyone.
* daniels giggles.
<infinity> So, I'll just upload this.
<daniels> a shell script that generates a huge chunk of a Makefile, that gets read into a variable in ./configure, and substituted in-place to the generated Makefile
<infinity> You're still not sleeping properly, are you?
<daniels> never better
<infinity> Oh.
<infinity> Well, shame about your drug habit, then.
<daniels> worship the crack, dude
<daniels> gah, it's really not liking these newlines
<daniels> hm, found a slightly less crackful way to master this
<fabbione> AHGHHHHHHHH
<fabbione> GOT IT !
<Lathiat> daniels: xlibmesa-gl-dev: Depends: x11proto-gl-dev but it is not going to be installed
<Lathiat> daniels: what do i need to play with to fix that?
<Jimbob> jdub: re: the "root terminal" thing, you could (as an interim solution) have the desktop exec "gnome-terminal --execute sudo -s -p 'Enter your password to run a root shell: '"
<fabbione> FINALLY!
<daniels> Lathiat: you need to install x11proto-gl-dev :P
<daniels> Lathiat: sudo apt-get install x11proto-gl-dev, see what it conflicts with
<Lathiat> heh ok
<Lathiat> that was in a buildd but
<Lathiat> but i suppose i can see what it does locally
<fabbione> GRRR...
<whiprush> hey fabbione 
<fabbione> hi whiprush 
<whiprush> may I trouble with you with a kernel question?
<fabbione> whiprush: if you feel lucky :)
<whiprush> heh
<whiprush> the pptp driver in hoary doesn't work with bsd-based firewalls like monowall.
<whiprush> a friend of mine bugged me with it but hasn't told me specifics yet
<fabbione> it's a bsd problem :P
<whiprush> apparently some distros are pulling the pptp driver right from the guys CVS even though he hasn't made a release.
<whiprush> how shall I proceed?
<fabbione> we don't pull from CVS
<fabbione> i am pretty sure about it...
<whiprush> ok, so the right answer is "ask the guy to release?"
<fabbione> whiprush: how to proceed is a good question... does it work with other distros?
<whiprush> it works with fc4 just fine.
<fabbione> whiprush: no, my point is that we don't pull from CVS.. should we?
<fabbione> whiprush: if it works with other distros, it might as well be a problem with bsd...
<whiprush> but, the one thing that caught my attention is the original patch was for 2.6.23
<fabbione> too many vars in the middle
<whiprush> er, 2.6.2
<whiprush> which led me to ask "why isn't in mainline yet?" if it's been so long
<fabbione> if nobody push the patch, it will never go mainline
<fabbione> + the code needs to be clean
<fabbione> and probably it's not
<whiprush> I agree.
<whiprush> My bsd-based router is a new release of m0n0wall, which is pretty popular around my group of friends. But this kernel patch seems to be wonky.
<whiprush> last update I can tell is for 2.6.2
<fabbione> mppe                    http://free.polbox.pl/h/hs001/                                          mppe-mppc-(.*).patch.gz         1.3                     linux-
<fabbione> 2.6.11-[] 
<fabbione> is this one the patch you are talking about?
<whiprush> anyway, I'll get more specifics on the patch itself, I've had like 3 of my friends patch their kernels to "make it work" but none of them seem to know any specifics.
<whiprush> I'll file a bug, I was just wondering if you happened to know anything about it off the top of your head.
<whiprush> 2 of them just enabled ipsec and worked with that instead if filing a bug (grrr!!!!)
<fabbione> whiprush: i might as well be a BSD problem
<fabbione> i really have no idea
<whiprush> ok, I'll get more specifics on it then
<fabbione> i don't use bsd and tbh i don't have machines to test it and knowledge to debug it
<fabbione> it works linux2linux so for me it's ok
<whiprush> It really sucks when people fix their stuff and tell no one. 
<fabbione> ok = it can be bsd ;)
<whiprush> "Oh hey, ubuntu won't work with this pptp setup, and no I can't help you, but I like the naked girls."
<whiprush> story of my life. 
<whiprush> but hey if it makes you feel better, inotify has been pretty solid this cycle. :D
<infinity> Oh, wow.  My laptop might actually show up on my doorstep tomorrow.  Finally.
<ivoks> :)
<fabbione> OHHH now it works
<whiprush> infinity: wotcha get?
<daniels> damn it, the cursor generation has defeated me for today.
<whiprush> hmmm, since I spoiled my cool points on fabbione, daniels, may I trouble you for a question?
<daniels> go nuts
<whiprush> this zach rusin thing?
<daniels> exa?
<whiprush> yeah
<whiprush> worth it (will it be in breezy?) or are we waiting for Xegl?
<daniels> exa is more than worth it.  you can't do some of the cool tricks you can do with gl (e.g. desktop-on-a-cube), but it makes most other uses of composite very performant.
<whiprush> man, I don't even know if that's a right question.
<daniels> it'll be in breezy for radeon and i810 at least
<daniels> oh, and sis
<whiprush> So, is it bling for breezy? or ... ?
<daniels> bling-for-breezy, but not by default
<whiprush> good good.
<daniels> in any case, I need to go clean up; got a landlord's inspection tomorrow.  blah.
<whiprush> daniels: get a haircut, and maybe a new shirt.
<whiprush> :)
<daniels> whiprush: hah.  nah, this is in the house that I'm moving out of, but others are staying on, so I have to make it all slick and shiny.
<daniels> i look presentable whereever I go, so houses that *I* inspect aren't a worry :P
<whiprush> good plan
<ivoks> pitti: morning :)
<pitti> Morning
<pitti> ivoks: good luck for your exam!
<ivoks> heh, i will not take it :(
<ivoks> i'm not 100% ready, so no point in doing it bad...
<pitti> Hey JaneW
<fabbione> hey guys
<pitti> Hi fabbione 
<JaneW> morning pitti
<fabbione> hey JaneW 
<JaneW> hey fabbione
<fabbione> YAY
<fabbione> we will soon able to install on LVM :)
<fabbione> i finally got a working package
<Treenaks> fabbione: cluster-lvm?
<fabbione> JaneW: that'd be InstallerVolumeManager
<fabbione> Treenaks: nothing to do with clustering
<Treenaks> fabbione: there is clusterlvm right?
<fabbione> Treenaks: that's clvm.. and it's only an extra layer (sort of plugin) to make lvm work in a clusterized env
<fabbione> but that won't be in the default install
<JaneW> fabbione: excellent
<tepsipakki> hi, I've tested gnome-screensaver on breezy, and it seems to work for the most part
<tepsipakki> just not the "popsquares"-screensaver ;)
<tepsipakki> gnome-screensaver-dialog needed to be setuid-root, otherwise locking didn't work
<mae> hey guys, gnome baker is looking quite promising, maybe we should include in breezy?
<mae> i built the CVS and it supports automatic decoding of flac for audio cd's  :D
<tepsipakki> mae: it is in universe
<mae> tepsipakki, yes i know , but i think its good enough to include as a general purpose burner tool, don't you?
<tepsipakki> yes
<mae> in the main distro
<mae> _on_ the cd :)
<pitti> elmo: please sync ipsec-tools
<pitti> Hey sivang
<sivang> pitti: Hi Martin, how are you?
<pitti> fine, thanks
<sivang> pitti: oh, I need to quit and login again, after I Have activated screen :-)
<elmo> pitti: done
<pitti> thanks
<sivang> pitti: back
<tepsipakki> I'm not getting the launchpad-registration mails
<tepsipakki> I've tried a couple of times.. checked all the spam folders etc ;)
<fabbione> Kamion: ping?
<sivang> seb128: morning
<sivang> seb128: have you heared from jamesh ? I discussed with him a bit the creation of a helper lib, but after that I didn't get in touch with him
<pitti> Hey seb128 
<seb128> hi
<seb128> sivang: I pinged him yesterday, he's busy but will try to have a shot on patching gtk today
<seb128> sivang: what helper lib?
<sivang> seb128: helper lib , he is not going to patch Gtk
<sivang> seb128: the helper lib will contain the action group for the launchpad integration stuff,
<sivang> seb128: and will will patch applications to use it
<sivang> seb128: (to the best of my understanding)
<sivang> seb128: He said patching Gtk would be a bad idea anyways
<seb128> jamesh: around?
<sivang> seb128: btw, on the app list I see gnome-system-manager, I can't find a package for it..
<seb128> where?
<sivang> seb128: under gnome-media
<seb128> ??
<sivang> seb128: sorry, under UIManager
<seb128> probably a typo for the package name
<sivang> seb128: ok, maybe you meant gnome-system-monitor?
<seb128> probably
<sivang> seb128: k
<seb128> are you going to patches stuff not using gtkuimanager?
<fabbione> seb128: gnome-doc-utils is uninstallable...
<seb128> fabbione: I know
<sivang> seb128: I don't mind doing anything you'd feel like assigning me to :-) if you like me to do that, I'll start with it, might be easier to me since I am not so much familiar with UIManager inner workings
<fabbione> seb128: ok :)
<seb128> will fix it soon :)
<fabbione> i know :) i just wanted to be sure you knew
<seb128> sivang: yes please, this spec has to move now
<sivang> seb128: ok, then I'll have a pathcie weekend :-)
<seb128> fabbione: sombody bugzilla-ed about it, I read the mail just before going to bed
<seb128> sivang: thanks
<sivang> seb128: I might however, need your help here and there, so be redy to get pinged :-)
<fabbione> i guess it's time to downgrade ipw2x00
<Lathiat> fabbione: whys that?
<torkel> to make it work on 2.6.12?
<Lathiat> new ones work for me shrug
<seb128> sivang: np
<fabbione> Lathiat: not the ipw2100
<Lathiat> fabbione: ah
<fabbione> Lathiat: and the ipw2200 has problems with the firmware
<Lathiat> well, i havent had any problems with my 220
<Lathiat> 0
<Lathiat> but i guess if 2100 is broken, well, bugger
<fabbione> the only sensible solution is to downgrade to something that's know to work
<torkel> Lathiat: 2100 oopses on 2.6.12 :-(
<Lathiat> torkel: suck
<fabbione> i could actually do an attempt to fix it
<fabbione> but i need volunteers to test it
<fabbione> but there will still be the 2200 firmware problem
<Lathiat> well, its just later versions of the driver fix the 2200 stuff from dying randomly
* chmj raises his hand 
<Lathiat> i can test the 2200 
<torkel> and I can test 2100
<fabbione> ok.. is it the -686- flavour good enough for both of you?
<torkel> sure
<Lathiat> yeh 686 works for me
<Lathiat> i can try 386 if you want
<Lathiat> do the colony install cds work?
<fabbione> Lathiat: can you check #12417?
<fabbione> Lathiat: for me it's enough one flavour works..
<fabbione> the others will follow :)
<elmo> fabbione: cvd has a very temperemental 2200 that isn't fixed by breezy 2.6.12 FWIW; I'm happy to randomly install new kernels on her laptop
<fabbione> elmo: can you check what's in dmesg and if it matches what's in #12417?
<Lathiat> fabbione: i get nothign like that, all works fine
<elmo> fabbione: noting in kern.log like that
<elmo> nothing
<fabbione> hmm apparently the breakage was between 1.0.3 and 1.0.4
<fabbione> we might be lucky..
<JaneW> ogra: ping
<ogra> JaneW, pong
<JaneW> ogra: are you ready to go for a tested/implemented shade of green on BreezyGoals yet? ;)
<ogra> JaneW, i'll go through them today again, but i fear i cant change colors very much yet
<ogra> AudioCDBurning could get a little greener... 
<elmo> fabbione: http://people.ubuntu.com/~james/tmp/ has a dmesg and kern.log, if it's useful
<fabbione> elmo: checking
<fabbione> [4294695.281000]  ieee80211: eth1: Unknown management packet: 0
<fabbione> elmo: this seems to be the culprit
<ogra> Kamion, gnome-power got approved for main, could you shuffle the seeds ?
<fabbione> elmo: apparently the ieee80211 layer is broken.. making both ipw2100 and 2200 crap
<JaneW> ogra: ok, thanks :)
<fabbione> anyway.. i need some lunch now..
<pitti> fabbione: maybe that's even the reason for the crash I experienced with netapplet and my wireless`
<ogra> seb128, how likely is it that services-admin will be ready in time ? its crashing badly over here
<fabbione> pitti: do you have ipw2100 or 2200 =
<fabbione> ?
<pitti> fabbione: no, prism2
<pitti> fabbione: but that uses the 80211 layer as well
<fabbione> pitti: i don't think the prism2 uses that set of modules.. they come specifically with ipw2x00
<pitti> oh, ok
<pitti> fabbione: btw, I deinstalled netapplet, now I don't get crashes any more
<fabbione> iirc the prism2 has it's set of ieee80211 modules
<fabbione> because clearly there are something like 23298392 copies of the same code
<pitti> :-/
<fabbione> each one crashes in a different spectacular way
<chmj> oh dear 
<fabbione> breezy+1 won't have this problem
<seb128> ogra: it works fine here
<Lathiat> whys that?
<fabbione> all this stuff is going upstream
<Lathiat> heh
<fabbione> anyway.. food
<fabbione> later
<seb128> ogra: if you don't send bugs for your issue they are not going to be fixed
<ogra> seb128, i cant start samba.... (i once removed the link in rc2.d)
<seb128> if you messed stuff by hand ...
<ogra> .... same for apache
<ogra> it should deal with that and not just crash ;)
<seb128> send a backtrace
<ogra> i'll do
<seb128> it doesn't crash here
<seb128> describe what to do to get the crash
<seb128> and send a bt
<torkel> food sounds like an good idea
<ogra> seb128, sure, i'll open a bug...
<ogra> seb128, nice to know it works for you... i just have to know if it doesnt make it, because i have a bounty student for that ;)
<pitti> elmo: please sync strace
<seb128> ogra: DOH on duplicated work :/
<seb128> ogra: that's a bounty waste
<ogra> seb128, nope :)
<seb128> ?
<seb128> what is the student doing?
<ogra> seb128, its called GraphicalConfigTools, not service manager ;)
<ogra> and we already postpned the services app.... since we both belive in garnachos work *g*
<seb128> k
<seb128> what is the guy doing?
<ogra> so now we'll get a ndsiwrapper tool to select your inf file via file selector, a scheduled task tool... and probably something for a basic LAMP setup
<ogra> but i doubt the latter will be ready in time (to big task)
<ogra> seb128, in any case google pays it...
<seb128> k
<retrix> :) im the lucky bounty student btw
<Lathiat> i was going to play with that ndiswrapper thing but i havent been able to get my hand on some hardware to play with it
<ogra> seb128, if you got other suggestions for needed tools... just say :)
<ogra> hey retrix 
<pitti> elmo: please sync exim4
<retrix> hi ogra
<ogra> :)
<elmo>      exim4 |     4.52-1 |        breezy | source
<elmo> nothing to sync
<pitti> oh, then somebody didn't close the merging bug
<pitti> thanks anyway
<seb128> elmo: can you get gnome-screensaver out of NEW?
<seb128> ogra: do we have any dsl config tool?
<seb128> s/dsl/adsl/
<ogra> seb128, you mean a gui for pppoeconf ?
<seb128> by example
<ogra> that would be a good addition, yes
<seb128> something to configure your internet
<ogra> retrix, what do you think ? 
<ogra> sounds more achievable then a LAMP gui...
<retrix> i could probably manage that
<ogra> retrix, have a look at it and come back to me if you like to do it, i dont wont to get you under pressure ;)
<retrix> ok ill look into it ogra
<ogra> great :)
<Kamion> daniels: pong
<Kamion> fabbione: pong
<Kamion> ogra: you should learn how to edit the seeds yourself; see SeedManagement on the wiki
* Kamion glares at openssh
<ogra> Kamion, i'm on it for edubuntu :)
<mdz> daniels,Kamion: install from yesterday's Breezy fails in X configuration
<mdz> xserver-xorg/config/inputdevice/keyboard/layout not set . Aborting
<Kamion> mdz: yes, I already mailed daniels about it, he's fixing it for -35
<mdz> ok
<Kamion> sent me a workaround as well which I might apply if it's urgent
<Kamion> (preseed xserver-xorg/autodetect_keyboard=true)
<fabbione> Kamion: i uploaded p-a-l 2ubuntu1.. it works here for me...
<fabbione> Kamion: if you want to give it a shot too it would be nice
<ogra> pitti, ping
<pitti> Hey ogra
<ogra> pitti, jdub asked me to package gnome-screensaver (which seb128 already did now) and to come to you for a security review
<ogra> (it just got synced)
<pitti> so it's in universe soon?
<ogra> looks like... if it builds :)
<pitti> could you please prepare an intitial report? with debian and upstream bug tracker review, security history, and so on?
<ogra> yeps...
<pitti> ... and of course a test :-)
<ogra> sure... as soo as its available....
<pitti> I'll look at the packages and critical parts of the code
<pitti> ogra: btw, does it have any elevated privs?
<Kamion> fabbione: ok, but I doubt it will be soon at this rate :(
<Kamion> fabbione: cool, though
<fabbione> Kamion: eh ok :)
<ogra> pitti, dunno, havent looked myself yet... but it should work in the user-session as xscreensaver does
<ogra> pitti, so i douubt it...
<pitti> yes, I assume that :-)
<seb128> ogra: it's not synced, I've packaged it for Ubuntu
<fabbione> Kamion: the only hack left around is how we need to round up the lvm overhead at lvcreate time, that might create the last partition a bit bigger than usual.. but for the other stuff it's ok
<ogra> seb128, oh
<fabbione> Kamion: we still miss all the goodies like the progress, but that's not high priority
<mdz> is gnome-screensaver based on xscreensaver, or is it entirely different?
<fabbione> hey mdz
<mdz> fabbione: morning
<jsgotangco> hey> - include a PDF poster (e.g., A0 size) that can be downloaded and
<jsgotangco> > printed. I'll start with the one we had in Sydney (the Hoary CD cover)
<jsgotangco> > but over time we may be able to get approved ones from the Art Team
<jsgotangco> > - include a link to shipit for ordering CDs (with info about delivery
<jsgotangco> > time & planning ahead!)
<jsgotangco> > - a link to the Ubuntu stuff on Cafe Press (we're in the process of
<fabbione> sabdfl morning 
<jsgotangco> > updating these items with better logos)
<jsgotangco> > - a link to a page to share tips/experiences
<mdz> daniels: did you determine what should be done about /usr/bin/X11?
<jsgotangco> > - a list of conferences where people plan to hand out Ubuntu CDs
<sabdfl> fabbione: hi
<jsgotangco> > 
<jsgotangco> > We'll also try to find a reasonable way to make & provide some other
<jsgotangco> > collateral (stickers, other giveaways, etc) and we'll add this info to
<mdz> jsgotangco: please don't do that
<jsgotangco> > the page when it's available.
<jsgotangco> > 
<fabbione> Kamion: i also published all the patches.. one by one in the usual dir
<jsgotangco> acck
<jsgotangco> sorry
<jsgotangco> jeezz
<jsgotangco> mdz, sorry my bad
<Kamion>      - Ubuntu branding for the master template file.
<Kamion> fabbione: huh? what was that?
<Kamion> -2 killed that requirement I thought
<fabbione> Kamion: to change the default VG name from Debian to Ubuntu
<tepsipakki> gnome-screensaver needs one component to be setuid-root, as I said earlier
<fabbione> Kamion: it is still a one line change
<tepsipakki> otherwise I couldn't get it to lock the screen
<Kamion> fabbione: aha, ok
<tepsipakki> see: http://bugzilla.gnome.org/show_bug.cgi?id=309613
<Kamion> righto, I'll have a look over the changes when I get a chance, thanks dude
<elmo> fabbione: cvd's laptop did get that nasty firmware crap - I've had to downgrade to hoary kernel now
<fabbione> Kamion: no problem.. just keep in mind one thing.. i did produce the patches in the same order as i was fixing bugs or changing things.. so to get a working package you still need all of them in the right sequence...
<fabbione> elmo: ok.. i am working on it right now
<seb128> grrr
<fabbione> Kamion: including changes to changelog and stuff :)
<seb128> I could kick this Vincent Trouilliez guy
<ogra> mdz, gnome-screensaver is essentially a fork of xscreensaver
<tepsipakki> ogra: fork?
<jsgotangco> seb128, haha
<tepsipakki> isn't it written from scratch?
<ogra> mdz, bt i havent looked yet how far they forked
<ogra> tepsipakki, http://live.gnome.org/GnomeScreensaver_2fFrequentlyAskedQuestions
<tepsipakki> ah
<Lathiat> ah xembed, cute solution
<Kamion> fabbione: sure
<jdthood> pitti: I have been thinking about set-default-soundcard...
<pitti> Hi jdthood 
<jdthood> pitti: The utility sets the card _number_.  This depends on the order in which the drivers are loaded, unless the module loader configuration contains options that enforce certain index numbers for certain drivers.
<jdthood> pitti: Have you considered using card _names_?
<pitti> jdthood: well, they are harder to map and error prone
<jdthood> pitti: How so?
<pitti> but if it can be done robustly, that would of course be possible as well
<pitti> jdthood: how is that specified in asoundrc?
<jdthood> pitti: Generally you can use names anywhere you can use numbers.
<jdthood> $ cat /proc/asound/cards
<jdthood> 0 [CS46xx         ] : CS46xx - Sound Fusion CS46xx
<jdthood> $ cat /proc/asound/cards
<jdthood> 0 [Dummy          ] : Dummy - Dummy
<jdthood>                      Dummy 1
<jdthood> 1 [CS46xx         ] : CS46xx - Sound Fusion CS46xx
<ogra> jdthood, i'm the guy from the hwdb.... i built in a check for the soundcard name... you cant imagine how many kernel modules only report [rev0]  as the name, you cant distinguish it with the name (yet)
<jdthood> If I load another snd driver first, my principal sound card gets a different index (1 instead of 0) but it retains the same name ('CS46xx').
<jdthood> ogra: Ah.
<ogra> jdthood, so a check for both would probably the way to go
<jdthood> ogra: Yes.  Would it be possible to set the soundcard on the basis of the name, if the name is something "valid", and fall back to the number?
<ogra> why not ? its only code ;)
<ogra> the question is, does pitti have time to implement sich things.... else i'd go with the numbering scheme for now and think about a more fine grained solution for breezy+1 :)
<jdthood> ogra: On second thought ... the program is run from System|Preferences|Sound|Default and this _has_ to display a useful name in order for the user to be able to make an informed choice.
<ogra> s/sich/such
<pitti> jdthood: it does already
<pitti> jdthood: but we can assume that the name is valid at that moment
<jdthood> pitti: Does what already?
<pitti> jdthood: yes, that's done in gnome-sound-properties
<jsgotangco> brb
<jdthood> pitti, orga: So why not change set-default-soundcard to write the name (as displayed to the user) instead of the index number into .asoundrc?
<jdthood> Sorry if I am missing something?
<pitti> jdthood: unfortunately I just lost my second audio device three days ago, so I cannot test that right now
<pitti> jdthood: but I didn't know that you can put names as values of defaults.pcm.card
<jdthood> pitti: I believe you just put the name instead of the numeral.  Probably you have to protect it with quotation marks if it contains spaces.
* jdthood tests this
<pitti> jdthood: next week I get a shiny new desktop box again, then I can have two sound cards again
<pitti> jdthood: right now I only have my laptop, pretty hard to add a second pci soundcard :-)
<pitti> jdthood: btw, are you at debconf5?
<jdthood> pitti: Nope
<jdthood> pitti: Well, just replacing the numeral with the name does _not_ work.  :/
<pitti> jdthood: well, IIRC I read a bit about that, and I never heard that you can use names
<jdthood> pitti: I have found that, in general, alsa-lib can work with names just as easily as with index numbers.
<pitti> jdthood: maybe libasound can be easily *made to* accept names as a value :-)
<pitti> elmo: please sync libapache2-mod-auth-pgsql and strace
<zyga> is any ubuntu dev currently in london
<zyga> ?
<ogra> zyga, our office is there....
<ogra> zyga, but everybody is well
<zyga> I just heard about the attacks
<elmo> libapache2-mod-auth-pgsql |  2.0.2b1-6 |        breezy | source, amd64, hppa, i386, ia64, powerpc, sparc
<elmo> pitti: nothing to sync?
<elmo> strace done
<jdthood> pitti: Ah, I figured it out
<pitti> elmo: bah, if somebody asks for sync, they should close the merging bug. Sorry
<Kamion> zyga: all Canonical employees are safe at least, don't know about other developers
<ogra> W: squeak-vm: binary-has-unneeded-section ./usr/lib/squeak/3.7-7/vm-display-fbdev .comment
<ogra> is it possible dh_stip, install -s and strip -s are broken ?
<ogra> i cant get this warning go away it seems... with neither of the tools
<Kamion> you have to explicitly do strip --remove-section=.comment
<chmj> zyga: what attacks ?
<Kamion> chmj: news.bbc.co.uk
<ogra> Kamion, wow, thnks
<zyga> chmj: bombs in the subway and in several buses
<chmj> Kamion: thnx 
<ogra> Kamion, lintian -i tells something different ;)
<Kamion> ogra: dh_strip does this for files it knows to be shared libraries or executables
<ogra> Kamion, yes, the squeak plugin mechanism is a bit strange
<Kamion> ogra: RTFS :)
<ogra> :)
<Kamion> it's fair enough for lintian not to go into quite all the details I think
<ogra> if i give -i it should show details ....
<Kamion>                 if ($type=~m/.*ELF.*(executable|shared).*/) {
<ogra> thats why i do this
<Kamion> ogra: they're implementation details of dh_strip
<Kamion> anyway if 'file' on /usr/lib/squeak/3.7-7/vm-display-fbdev matched that regex, it would have .comment and .note stripped
<ogra> N:   The binary or shared library is stripped, but still contains a section
<ogra> N:   that is not useful. The utilities (install -s and dh_strip) are
<ogra> N:   patched to remove the .note and .comment sections.
<Kamion> yes, and they do
<torkel> zyga: is it confirmed that it was bombs?
<Kamion> for sensible binaries
<ogra> so i assume install -s does this....
<JanC> torkel : 3 busses don't explode on themselves...
<ogra> torkel, yes
<torkel> k
<zyga> torkel: it seems so
<zyga> torkel: buses dont blow to bits out of thin air
<Kamion>       execlp ("strip", "strip", "--remove-section=.comment", "--remove-section=.note", path, NULL);
<zyga> many people died apparently, it's a sad day :-(
<Kamion> install -s does that unconditionally if built with ELF support
<Kamion> so perhaps your binary is too broken for strip to be able to handle it?
<ogra> Kamion, lets see... just compiling again....
<pitti> elmo: cdrtools sync, please
<elmo> pitti: done
<pitti> thanks
<ogra> Kamion, --remove-section worked... many many thanks, this is a weird source making me rip my hair out
<ogra> now on to all these rpath errors
<Kamion> ogra: hm, I certainly don't understand why install -s would have failed then
<pitti> ogra: gnome-screensaver ftbfs
<ogra> Kamion, it did...
<ogra> pitti, oki
<ogra> pitti, thanks for reporting :)
<elmo> pitti: assigned the lib32z1 bug to you at mdz's request (you touchedit last)
<pitti> elmo: odd, I only changed one line in the code...; I'll look at it
<pitti> elmo: please sync adduser 
<pitti> elmo: ... and bsdmainutils
<elmo> pitti: done
<pitti> elmo: I think I'll cumulate the next requests...
<HiddenWolf> seb128, you've got 2 different email adresses on the new upload of gnome-screensaver, is that intentional?
<seb128> yep
<seb128> I use my debian email for the Maintainer and my Ubuntu one for the uploads
<seb128> why?
<HiddenWolf> seb128, just wondering
<seb128> pitti: do you read utopia-list?
<fabbione> chmj, elmo, ipw2x00 testers....
<fabbione> i have a test image for you guys
<fabbione> http://people.ubuntu.com/~fabbione/linux-image-2.6.12-3-686_2.6.12-3.4_i386.deb
<fabbione> NOTE that it breaks the ABI
<fabbione> that it is NOT reflected in the package name
<fabbione> so if you use some of your own compiled drivers they will break to death
<chmj> :(
<fabbione> chmj: they might actually work.. but keep an extra eye ;)
<davyd> so, it would be really swell if I could use update-alternatives to select my version of gcc
<fabbione> only ipw2100 and ipw2200 should be affected
<mjg59> fabbione: Should this fix the oops?
<fabbione> mjg59: yes.. but i need people to test it
<fabbione> mjg59: i need at least an ipw2100 and an ipw2200
<mjg59> fabbione: Ok, I'll give it a go later
<fabbione> mjg59: ok thanks
<fabbione> mjg59: what chipset do you have of the above?
<mjg59> ipw2100
<fabbione> ok
<torkel> fabbione: at least it does not oops when doing a 'iwlist eth1 scan' with ipw2100
<lifeless> davyd: you can, if you install an alternative 
<lifeless> davyd: its a shame its not in the package though
<fabbione> torkel: it should work without any problem now
<fabbione> torkel: it's exactly the same as upstream :)
<fabbione> torkel: can you put the interface in traffic?
<fabbione> torkel: and see if it works as it should?
<pitti> seb128: yes, I do
<fabbione> pitti: check /. article about ICMP from today
<fabbione> Developers: Examining ICMP Flaws
<Treenaks> fabbione: is that not just some more Theo De Raadt FUD?
<fabbione> Treenaks: i only read the subject...
<fabbione> one thing at a time ;)
<seb128> pitti: k, bastien was asking on the GNOME list on reply to a mail from Jeff speaking about your audiocard selector
<pitti> seb128: that is sitting in the gnome bts for weeks now... has there been any progress?
<fabbione> Treenaks: no.. it doesn't look like
<torkel> fabbione: seems to be working. Anything special you want me to test?
<fabbione> torkel: not really...
<seb128> pitti: I'm quite upstream for that ... I'll point the bug to Bastien
<fabbione> you know what the driver can/cannot do
<seb128> pitti: maybe Jeff knows who is to ping for that though
<pitti> fabbione: *wonderful* 
<fabbione> pitti: we can still switch to DECnet IV :)
<fabbione> "or download the Linux version of the older DECnet IV and bask in the Security Through Obscurity."
<mjg59> fabbione: What change did you make? (It doesn't seem to be in the changelog)
<fabbione> mjg59: reverted ipw2200 to 1.0.1.
<Simira> tseng: ping
<mjg59> fabbione: Ah, ok
<fabbione> mjg59: that also brings back the ieee80211 to 1.0.1 that's the same as ipw2100 1.0.0 upstream
<fabbione> oh the ipw2200 firmware downgraded too
<fabbione> to match the driver version
<fabbione> mjg59: i didn't add any changelog becuase i am not sure it works yet..
<fabbione> ipw2100 seems fine..
<fabbione> so i am waiting somebody to test ipw2200
<davyd> woot, my laptop sleeps
<davyd> although I did rewrite the suspend script to do less stuff
<mjg59> Did it not sleep before?
<davyd> atheros didn't power down cleanly
<davyd> seems to be fixed
<davyd> something in your suspend script seems to be blocking on my machine too
<davyd> you can ctrl-c it, I should add the -x so I can see what it is
<hunger> pitti: Just mailed you the latest and greatest cryptodisks script.
<pitti> hehe, thanks :)
<hunger> pitti: I have messed with my mail setup again... so please tell me if it got through;-)
<pitti> hunger: might very well be that this has to wait until the week after debconf5
<pitti> hunger: I still have some other stuff to do, and I'm leaving tomorrow
<hunger> pitti: No problem... I am using the latest and greatest version of the script anyway;-)
<pitti> ogra: hey, g-screensaver built :-)
<ogra> pitti, yes... seb128's work :)
<pitti> ogra: will it be as nice as your hoary modifications to xscreensaver? :)
<pitti> ogra: oh, and btw, any news wrt. the hdwb hal changes?
<ogra> hopefully
<davyd> is this the one that abuses xembed?
<ogra> pitti, after UVF ?
<ogra> davyd, yep
<pitti> ogra: certainly enough, but the architecture is not going to change any more anyway
<davyd> it's a pretty clever idea
<seb128> grumpf
<davyd> better then my one of extending Xlib
<pitti> ogra: however, today *is* UVF, apart from merges
<seb128> dh_make sets
<seb128> Cpu: any
<seb128> System: any
<ogra> pitti, i know :)
<pitti> seb128: argh, type-handling
<seb128> and it doesn't put an "Architecture:" 
<seb128> WTF
<pitti> seb128: type-handling fills the architecture value in
<seb128> doh
<pitti> seb128: there's certainly a control.in
<seb128> I hate this stuff
<seb128> yep
<pitti> me too :-)
<seb128> I've dropped it to start
<seb128> jdub: apt-get install gnome-screensaver
<seb128> jdub: is the upstream guy on IRC?
<jdub> seb128: dunno
<seb128> k
<seb128> the current package has no user switching, it looks for a gdm.conf for that
<jdub> yeah
<seb128> and Build-Depends on gdm is not an option, installing 72 packages to get a config file is plainly wrong
<luis_> seb128: he is sometimes
* luis_ tries to remember the nick
<bob2> jbailey@u.c goes where you'd think, right?
<tseng> Simira: yes?
<elmo> bob2: jeff.bailey will for sure
<bob2> ah, good point, thanks elmo
<seb128> luis_: k, let me know if you get his nickname :)
<luis_> I can't remember
<luis_> and AFAICT he isn't online
<mdz> Kamion: I've added the ltsp bits to ship; I don't think it should be very heavy, but just so you know in case it blows up unexpectedly
<Kamion> thanks
<seb128> luis_: k, I'll mail him rather, he seems to be quite fast to reply to bugs
<bob2> lamont-away: did you ever end up getting the kernel to like your cell phone?
<ogra> hmm, gnome-screensaver is very strict if you lock the screen.... very strict.... you dont even get a unlock dialog ....
<mdz> Diziet: welcome
<elmo> fabbione: d2adef1f0f4d271026096b13eae86dc4  ../linux-image-2.6.12-3-686_2.6.12-3.4_i386.deb
<elmo> fabbione: that what i want?
<Diziet> mdz: Hello.
<fabbione> elmo: the one from people.. there is only one 3.4
<mdz> Diziet: so I wanted to catch up regarding NetworkMagic
<ogra> Diziet, hi...
<fabbione> elmo: note the ABI thing i wrote above
<Diziet> mdz: Yes, please !
<mdz> Diziet: thom mentioned he had received mail from you, but hadn't replied yet (at the time I spoke to him)
<Diziet> That's still true.
<mdz> Diziet: but in any case the first step is getting network-manager into shape
<Diziet> At least AFAICT.  I haven't checked my logs.
<Diziet> OK.  Is there a list somewhere of what's wrong with it ?
<elmo> fabbione: abi doesn't matter if I'm just using that image .deb and nothing else, right?
<Diziet> Or will it be obvious ? :-)
<elmo> well, assuming reboot-after-install
<fabbione> elmo: right
<ogra> Diziet, bugzilla ?
<Diziet> I haven't looked at it yet; my testbed machine is installing as I write.
* Diziet goes to look.
<jbailey> mdz: ping?
<mdz> Diziet: if you install it, a few things jump out
<fabbione> elmo: yes.. that will make it easier
<mdz> Diziet: for instance, it depends on bind9
<Diziet> Cripes.
<mdz> Diziet: and it mangles /etc/resolv.conf in some very interesting ways
<fabbione> elmo: otherwise you need to unload all the ipw and ieee802* modules and reload them
<Diziet> I can see the argument for having a local proper cache, actually.
<mdz> I suggest installing it in a few places (most interestingly a laptop with wireless + wired interfaces) as a start
<Diziet> OK.  I've got one of those with enough disk for an install.
<mdz> Diziet: sure, but bind9 is a bit heavy and its default configuration is not suitable for that
<Diziet> Quite so.
<jbailey> mdz: Was just talking with fabionne about the best way to handle that older udev's don't like 2.6.12, and newer udev's require newer kernels.  Trying to figure out if depends'ing on Linux >> 2.6.12 would work and if we can assume that the kernel version provided there will be present on next boot.
<Diziet> Do we have an opinion about our preferred cache ?
<mdz> so NM is pretty rough around the edges and needs to be polished up to integrate smoothly with the rest of the system
<Diziet> I'll have a play with it and see what looks like needing fixing.
<mdz> Diziet: lwresd seems like the right idea, though I confess to never having actually used it
<ogra> especially its working very bad with pcmcia here ....
<jdub> mdz: NM runs BIND with its own configuration; i've been talking to upstream about the nscd switch - sounds like that's the way to go
<mdz> the key use cases are documented in the spec
<Diziet> mdz: Right.
<Diziet> But they're largely obvious.
<mdz> jbailey: elmo would hate you
<jbailey> mdz: The catch is arch's that don't provide 'linux' because there's no default kernel, but those could just depend on, say, linux-hppa32 | linux-hppa64 and trust that the user already has at the right kernel installed courtesy of the installer.
<Diziet> nscd ?  Surely that can't be the right answe.r
<elmo> jbailey: dude, that's horrid - I don't think we can assume our users are running kernels we provide
<mdz> they may be obvious, but they don't work yet, and it's not clear whether there are still pieces missing after we get NM in
* jbailey bats his eyes at elmo and tries to look cute.
<Kamion> jbailey: depending on kernel packages is awful
<elmo> esp. when kernel-package built packages don't produce packages with the same name
<mdz> at this point we need to get as quickly as possible to the point where we can add NM to the default install
<jdub> Diziet: well, colour this knowing that drepper has been the, ah, "hard place" in the decision making process :)
<mdz> without it doing anything insane
<mdz> because currently it isn't getting anywhere near the level of testing that it needs
<jbailey> elmo: We have to in terms of providing a supported configuration anyway.  If someone touches their kernel and it breaks, we can't help them anyway.
<Diziet> mdz: Right.
<jbailey> elmo: What we would be doing then is basically saying that as of a given release you have to have a minimum kernel version if you want to play at all.  Mark it in the release notes, enforced through a package dependancy.
<Diziet> What's Drepper got to do with it ?  I mean, um.  Just use normal dns and no nscd.
<Diziet> nscd is EBW.
<Kamion> jbailey: making our udev package not be usable unless you're using our kernels is just so bad
<jbailey> Kamion: It's more fragile than I like, but we don't have any way of depending on kernel features available on next boot.
<Kamion> jbailey: happy with release notes, but not the dependency
<jbailey> Kamion: Not based on our kernel version, based on 2.6.12
<elmo> jbailey: what's the danger here, partial upgrades of udev?
<jdub> Diziet: the reason why BIND/lwresd/nscd come up is because NM requires fast, reliable reconfiguration of DNS sources
<jbailey> udev 0.60 requires kernel 2.6.10.  2.6.12 requires udev 0.56
<elmo> why can't udev just check in the preinst?
<elmo> at runtime?
<jbailey> udev-0.61 will require kernel 2.6.1
<jbailey> 2.6.12
<Kamion> jbailey: yes, but as elmo says e.g. kernel-package produces differently-named packages by default, etc.
<Diziet> jdub: Quite so.
<jdub> Diziet: and interesting customisations for VPNs and so on, beyond what resolv.conf can do
<Kamion> jbailey: so what you're in fact saying is "you may not hack your kernel and use udev"
<Diziet> resolv.conf is not the answer.  A sensible cache is the right answer.
<jdub> Diziet: (this is the major reason why it uses a custom bind configuration, tweaks it, realoads it, etc)
<Kamion> unless you're extremely familiar with making kernel-package DTRT
<jdub> Diziet: yeah, thus bind :)
<Diziet> BIND8 is quite broken in this respect.  I imagine BIND9 will be worse, but I've not used BIND9.
<jbailey> Kamion: Not at all.  I'm saying "hack your kernel, but use the upstream version that we support".
<mdz> Diziet: is that enough of a concrete starting point to keep you busy for the present?
<jbailey> Ideally, newer ones will work, udev upstream has already broken this once.
<Diziet> `BIND9 lightweight resolver protocol' ?  These people are on crack.
<Kamion> jbailey: a preinst check would provide that *much* better than a package dependency
<jdub> Diziet: worth reading the mailing list for background
<Diziet> mdz: Yes, I think so.
<jbailey> Well, upstream kernel rather broke it so that older udev no longer worked.
<jbailey> Kamion: Preinst check assumes you're running the kernel already.
<Diziet> I should have finished my own nameserver really.  Then we could use that :-).
<Kamion> jbailey: package dependency assumes you have an Ubuntu-packaged kernel
<jbailey> Right now, running 2.6.12 on a warty system won't work.  The interface changed and udev hangs while walking /sys
<Kamion> we seem to be talking at cross-purposes here ...
<Diziet> Right now it just coredumps mainly.
<jbailey> Kamion: Well, it assumes you have it installed.
* fabbione will let people figure this out.. 
* fabbione really needs to rest
<mdz> jbailey: why do newer udevs require newer kernels?  is there no way to maintain backward compatibility?
<jbailey> Kamion: It also offers the ability to quickly check what version we think you ought to have installed with dpkg -l linux
<jbailey> mdz: sysfs structure changed.
<Kamion> cjwatson@jackass:~$ dpkg -l linux-image\* | grep ^ii
<Kamion> cjwatson@jackass:~$
<Kamion> for example
<Diziet> I think the right answer for now is probably to use BIND8 and restart it (not just reload it) when the config changes.
<mdz> jbailey: also, what's the target date for making initramfs the default configuration?  that needs _gobs_ of testing
<Kamion> jbailey: just for a start, that doesn't work on powerpc
<mdz> Diziet: preferable would be to disable that whole piece of the mess and use existing DNS infrastructure while we sort it out
<Kamion> jbailey: and it's hopelessly unreliable - it's very easy to update just linux-image-whatever without updating the metapackages too
<jbailey> Kamion: Right, that's  why the 'linux' package would depend linux-power3 | linux-power4 | linux-powerpc64-smp
<mdz> the more piecewise we can bring NM in, the less painful it will be
<Kamion> jbailey: people won't keep it up to date reliably
<Diziet> mdz: That would make sense too.
<Diziet> Just messing with resolv.conf is probably sanest.
<jbailey> Kamion: Yeah.  More fragile than I like, but a run-time test doesn't work here.
<Kamion> jbailey: seriously, the dependency doesn't work either
<bob2> note that things like firefox more or less ignore changes to resolv.conf
<Kamion> jbailey: I'd rather have a preinst *warning*, and then have udev bomb out at run-time if it's still wrong
<jbailey> Kamion: 'warning:  If you're not running 2.6.12 by the time you restart udev, it won't be able to run' type of thing?
<Kamion> jbailey: right, if it's not possible to make udev tolerate the old structure
<Kamion> jbailey: perhaps the udev init script could check the running kernel version before (re)starting udev
<Kamion> jbailey: so that you don't break your system if you do '/etc/init.d/udev restart'
<Kamion> Diziet: Have you looked at the Ubuntu new-maintainer process yet? We should look at getting you through it soon.
<jbailey> Kamion: That's doable.  I'm just wishing for some way of doing a more certain dependancy on the kernel version that will be installed next.  Apparently the next version of hal will want the next version of udev which will require 2.6.12.  Having the user have an old kernel will break alot of things. =(
<Diziet> kam: No.
<Diziet> I just did what it said in NewStaffTasks under Ubuntu.
<Diziet> So my key is in the keyring but I haven't done an upload or anything.
<ogra> Diziet, you are DD ?
<mdz> yes
<uniq> are there known issues with udev/kernel in breezy (ppc)? after updating from hoary to breezy loading the correct sound modules doesn't create the correct /dev entries.
<jbailey> mdz: Lemme give you an accurate answer to the initramfs default in a few hours.
<Kamion> Diziet: oh, your key's there already? No problem then.
<Diziet> Oh, good :-).  Well, it was on the list so I did it (got James to do it).
<Diziet> bob2: Yes, which is why a local cache would be better.  But.
<Diziet> I suppose you could do some kind of nightmare iptables forwarding hack.
<Diziet> But I have an aversion to nightmare hacks :-).
<pitti> elmo: please sync nagios
<Kamion> God, I hate and despise non-unified diffs.
<Treenaks> Kamion: patch diff to exclude the other methods
<chmj> Kamion: unified should be set as default
<Diziet> patchutils seems to have something called `filterdiff' which converts.
<Kamion> I wonder if it can convert .rej files
<Diziet> Not, I just did google and grepping; I didn't actually run it or anything.
<Diziet> http://linuxcommand.org/man_pages/filterdiff1.html
<Diziet> .rej's are context diffs, aren't they ?
<mdz> yes
<Diziet> Why oh why oh why oh why must everyone put grub or LILO in the MBR ?  I want the nice Debian MBR.
<Kamion> sadly it seems not to be able to handle .rej
<Kamion> Debian doesn't use the mbr package by default any more either
<Diziet> k: Presumably it was too simple and useful.
<Diziet> </cynic>
<bddebian> heh
<Kamion> it's entirely possible it simply got lost in the installer rewrite; I wasn't around ...
<Diziet> Oh well, I have rescue media if it comes to that.
<jbailey> mxpxpod: Did you system stay working?  Any idea how you got a corrupted install?
<mxpxpod> jbailey: yeah, everything works now
<mxpxpod> jbailey: no clue... it took me a couple of days to do the install, so that might have been a problem
<mxpxpod> jbailey: I have a slow connection at home
<jbailey> mxpxpod: =(  I guess.  It shouldn't have mattered, though.
<mxpxpod> no, it shouldn't have
<mxpxpod> oh well, it's fixed now :)
<mxpxpod> and I figured out how to issue linux-wlan-ng commands from /etc/network/interfaces
<mxpxpod> so I have my prism2 usb card working the ubuntu way
<davyd> daniels: alive?
<davyd> your new X seems to have broken my laptop
<mxpxpod> jbailey: now, if there was only a way to store configs in a database and have it go thru the db looking for ap's that it knows about...
<mxpxpod> oh well, I have to go paint
<jbailey> mx|gone: There was an udu spec on something like that, but I haven't followed it at all.
<seb128> pitti: around?
<jdub> mx|gone: networkmanager does that
<seb128> pitti: could you have a look on http://cvs.gnome.org/viewcvs/eggcups/cups-dbus.patch?rev=1.7&view=markup ?
<seb128> considering this comment 
<seb128> "Random note to CUPS distributors who may be running it as non-root:
<seb128> You'll probably need to remove the bit in cups-dbus.patch that checks
<seb128> getuid() to use the session bus.  Yes...it's an evil hack and should
<seb128> probably go away anyways :)"
<seb128> 
<mx|gone> jdub: but does nm work with linux-wlan-ng?
<seb128> pitti: that's a patch for cups/dbus, so we can package eggcups (http://mail.gnome.org/archives/gnome-announce-list/2005-June/msg00033.html)
<mdz> linux-wlan-ng isn't needed anymore in ubuntu, is it?
<Kamion> mdz: it was last I checked
<seb128> pitti: http://mail.gnome.org/archives/desktop-devel-list/2004-July/msg00126.html too
<Kamion> for prism USB devices
<mdz> prism2_usb is in the default kernel
<Kamion> but the userspace control bits are not
<mx|gone> mdz: prism2 usb devices don't take a lot of iwconfig commands
<Kamion> we have this conversation every time :-)
<mx|gone> haha
<mx|gone> wland is not needed
<mx|gone> and all the wlan.agent stuff
<mx|gone> because ubuntu has an ifup-post.d (or something like that) script that handles all the stuff
<mdz> Kamion: and the outcome of the conversation is usually "let's just seed it"
<Kamion> mdz: the outcome of the last conversation was me saying "my device didn't work; I installed linux-wlan-ng and it just worked"
<mx|gone> :)
<bddebian> heh
<Kamion> I have one of these devices, it doesn't work without linux-wlan-ng in hoary
<Kamion> unless you think the situation has changed in breezy
<mx|gone> same with in breezy
<pitti> mdz, Kamion: at least for my device it didn't change, I still need l-wlan-ng
<mx|gone> but you can use wlan_ng_* in /etc/network/interfaces to set your wlan-ng settings
<Kamion> you need wlanctl-ng and the /etc/network/if-*.d/ scripts, IIRC
<mx|gone> right
<pitti> mx|gone: you can, but that still needs the package
<mx|gone> pitti: correct
<davyd> gah
* mx|gone has a prism2 usb device and linux-wlan-ng installed
<davyd> why is my X.org broken again?
<Treenaks> it is?
<mx|gone> it'd be nice if the wlan-ng guys would just make it so that iwconfig would work with prism2 usb devices
<mx|gone> but oh well
<mx|gone> gotta go paint
<pitti> seb128: right, the patch would use the session dbus with our cups, it should use the system bus
<bddebian> It'd be nice if USB just went away for anything except mice and keyboards. :-)
<davyd> I'm also not getting any EE in my error log
<mx|gone> bddebian: yeah, tell that to broadcom (I wouldn't have to use a prism2 wlan device if they'd release the specs for the airport extreme)
<bddebian> mx|gone: :-)
<bddebian> mx|gone: PowerBook?
<davyd> hmm, does anyone know of recent X.org breakage?
<davyd> or is this something to do with whatever fix Daniel put in for my laptop
<Treenaks> davyd: it was fixed for me this morning
<davyd> this is a 3rd of July build it says
<davyd> it simply refuses to start
<Treenaks> davyd: that might be b0rken then, yes
<davyd> but logs no obvious error
<davyd> this is whatever the latest thing that came from apt is
<Treenaks> davyd: I think gdm can't find X
<mx|gone> bddebian: ibook
<davyd> Treenaks: I symlinked that back together
<davyd> Treenaks: /usr/X11R6/bin/X or whatever it is
<Treenaks> davyd: x-common of today fixed the mess
<Treenaks> or at least
<bddebian> mx|gone: Ah.  I had a Lucent working fine in a couple of PowerBooks :-)
<Treenaks> a partof the symlink mess
<davyd> Treenaks: I have 1.02
<Treenaks> me too
<davyd> Treenaks: where does your /etc/X11/X point to?
<Treenaks> lrwxrwxrwx  1 root root 17 2005-05-24 20:18 /etc/X11/X -> /usr/bin/X11/Xorg
<davyd> hmm, it just bails out
<davyd> there is no error logged in my log
<davyd> a few warnings, but nothing that looks important
<davyd> what driver are you using?
<Kamion> mx|gone: I just use a PCMCIA card in my PowerBook, but it's one of the models that actually *has* PCMCIA, unlike some
* bddebian should never have given away all his NewWorld PowerBooks.. :'-(
<elmo> Preparing to replace libdevmapper1.01 2:1.01.00-4ubuntu2 (using .../libdevmapper1.01_2%3a1.01.03-1ubuntu1_amd64.deb) ...
<elmo> update-rc.d: /etc/init.d/libdevmapper1.01 exists during rc.d purge (continuing)
<elmo> why is it doing purge on upgrade?
<elmo> who Touch It Last(tm)?
<pitti> elmo: me
<pitti> elmo: the init script is not necessary any more
<elmo> ok, so it's just a scary-but-harmless msg?
<pitti> elmo: so Debian removed it
<pitti> elmo: yes; I can try to quiet it down
<pitti> elmo: it first calls upgrade-rc.d remove and then rm -f's the script
<pitti> elmo: should probably be done the other way round then
<elmo> pitti: it's not a big deal, but might be nice to clean it up
<pitti> right, will do
<Kamion> having an init script in a sonamed library package is still crazy
<Kamion> glad it got cleaned up for the future, at least
<Diziet> I have a keyboard here where the rubber end on one of the little fold-out feet has _melted_ leaving a gungy patch on the desk !
<pitti> Kamion: yes, that's why I wanted to merge that version :-)
<Treenaks> Diziet: I had that with my laptop
* Kamion hides his blowtorch
<Treenaks> Diziet: it even came with spare rubber feet
<Diziet> This is just a normal n-years-old desktop keyboard in a sensibly-temperatured spot.
<ogra> cosmic rays or air pollution, pick as you like ;)
<bddebian> Maybe it's biodegradeable? :-)
<hunger> Diziet: Which hell did you raise from that you consider keyboard melting environments to be sensibly-temperatured?!
<mjg59> Diziet: Some of them liquify under pressure
<Kamion> mdz: any opinions on where to publish non-primary-architecture CD builds? I'm currently thinking http://cdimage.ubuntu.com/ports/daily/ etc.
<Diziet> liquify under pressure ?!  A _foot_ ?  But I suppose that's the only explanation other than that some chemical I used to clean the desk (some time ago, I'm afraid) ate it.
<mdz> Kamion: something like /ports/ sounds sane
<mjg59> Decstation 3000s were dreadful for that
<mjg59> If you left them in one place for long enough, the feet would run
<hunger> mjg59: Great... running feet on a keyboard!
<Diziet> This keyboard was made by Cherry.  And only one of the two feet has melted.
<davyd> mjg59: w00t for dodgy DEC rubber!
<Keybuk> why is it always the package with 130 patches that fails, and not the one with 3 ?
<bddebian> Moore's Laws?
<fabbione> Keybuk: otherwise it would spoil the fun?
<Diziet> keybuk: Patches are not a sign of good software, unfortunately.  And all too often they don't improve it, either.
<Kamion> I suspect the failure is an import failure rather than a failure of the software itself
<Keybuk> well, the software I'm currently battling with is "vim"
<Keybuk> so I think both points are valid ;)
<Keybuk> though this one looks like a Keybuk brain failure
<zyga> Keybuk: what's wrong with everyone's favourite editor?
<Keybuk> emacs?  nothing, why? :)
<zyga> no, no
<zyga> I said editor
<zyga> not operating system 
<zyga> what's wrong with vim? :)
<Keybuk> currently?  it doesn't have anything in its .orig.tar.gz other than tarballs, but my OH SO CLEVER import stuff tries to branch it anyway
<Keybuk> and breaks
<lamont> moof
<Keybuk> the fact that this is a pretty common occurance, and that the code that's broken is new, probably explains a lot
<zyga> Keybuk: what's an .orig.tar.gz? original source tarball? like the one everyone can fetch from vim.org? 
<Keybuk> part of a Debian source package
<Keybuk> is "supposed" to be the original source tarball
<zyga> mhm
<Keybuk> but the vim maintainer thinks he's clever, and the original tarball is actually inside this one
<lamont> Keybuk: unless upstream has RFC's or such. :-(
<pitti> Keybuk: he probably just tries to get features that dpkg should have *duck* :-)
<Keybuk> but it _does_ :o)
* Keybuk points at Wig & Pen
<lamont> Keybuk: I thought you preferred people no patch source, but rather unpack a tarball...
<pitti> Keybuk: sure, I'm looking forward to use that new format
<pitti> Keybuk: is there dpkg-source -b support for that?
<Keybuk> not yet
<Keybuk> want to write it? :)
<pitti> Keybuk: well, how do I test the new format then?
<zyga> Keybuk: so .orig.tar.gz actually contains one .tar.gz with source? that makes no sense
<Keybuk> zyga: .tar.bz2 inside a .tar.gz
<pitti> zyga: it does make some sense
<zyga> oh joy, compression
<pitti> zyga: that way, you can build your software in a directory build-tree/
<zyga> pitti: e17n me 
<pitti> zyga: so whatever you mess up in the build tree (experimental changes, autofuck tools changes, etc) will not mess up your source package
<zyga> pitti: like glibc does for egzample?
<Keybuk> glibc also has three upstream source tarballs
<pitti> zyga: glibc does multi-build, i. e. build the same source in different ways
<Keybuk> so has to tar them up
<zyga> hmm
<pitti> zyga: otherwise you have to play dirty hardlink tricks or bluntly copy around files, which is error prone
<zyga> pitti: I copy files but then again the trees are small
<zyga> pitti: still I cannot see the point of doing two archives 
<pitti> zyga: if it weren't for the tarball-in-tarball oddness, a tar'ed original source and a build-tree is really a good solution
<zyga> build-tree could be made with just one, correct?
<pitti> zyga: well, you could recursively copy files from the top level dir into build-tree
<pitti> zyga: but this is still ugly IMHO
<zyga> I'll see how vim's sources look
<zyga> I still don't get it frankly :/
<pitti> zyga: try gnome-volume-manager if you want to see something small
<zyga> ok
<pitti> zyga: or sysfsutils, even smaller and much less build deps
<Keybuk> what difference does top-level or build-tree make?
<Keybuk> out of interest
<pitti> Keybuk: debian/rules clean just rm -rf build-tree and is done
<Keybuk> sure, but that's just out-of-directory builds
<pitti> Keybuk: with top-level, you have to reverse-apply all patches, autofoo stuff, and so on
<Keybuk> ah, but you don't have to reverse-apply patches with W&P
<zyga> BTW, I've recently started using one tool that made reading obscure code a bliss
<zyga> :>
<pitti> Keybuk: sure, W&P is the solution we all waited for
<zyga> I've put indent into my lessopen certain files
<pitti> Keybuk: it's just that cdbs tarball.mk, dbs, etc. existed much earlier, so the folks got accustomed to these
<Keybuk> yup
<zyga> all the code I've got from work is readable now :)
<Keybuk> hopefully I'll get some time at debconf
<tseng> zyga: eh?
<pitti> Keybuk: I basically want to be able to play with the source without spending much effort into not destroying source pkgs
<zyga> tseng: I've made .indent.pro-file 
<zyga> tseng: and then I run indent -st "$1" in lessopen
<zyga> tseng: this way I can read the code the way I like
<jbailey> Keybuk: When you're asking what's the difference, do you mean why not untar it in place/
<jbailey> Keybuk: with cdbs, I did it because the clean target then gets reduced to rm -rf build-tree.
<zyga> why can't the clean target ... clean 
<zyga> not remove everything?
<zyga> does build-tree contain any source?
<jbailey> zyga: Upstream makefiles often suck and clean poorly.
<jbailey> There's alot of Debian packages that you can't do "debuild; debclean; debuild" to because they leave crap lying around.
<zyga> hmm
<jbailey> zyga: In a tarball build, yes.
<jbailey> Usually something libc build-tree/glibc-2.3.5
<zyga> jbailey: I'm startting to get this
<jbailey> Then we have build-tree/libc-i386 build-tree/libc-i686
<jbailey> And when you want to clean the whole thing, rm -rf build-tree takes care of it all.
<jbailey> You just need to make sure all your patches re in debian/patches correctly.
<pitti> zyga: also, I often play around with the source, insert some printfs here and there, apply some experimental patches which partly fail, etc.
<pitti> zyga: I can compile and re-compile in the build-tree, and am always able to get to a clean and consistent state
<zyga> hmm then the build tree *does* contain source
<zyga> okay I've built g-v-m
<jdthood> Will Breezy have udev 0.060, or will it stay with 0.056?
<mx|gone> bddebian: what did you give away all your pb's for?
<bddebian> mxpxpod: Because I'm dumb?  I gave them to Debian, Hurd, and Grub hackers
<tseng> bddebian: did you save me one?
<bddebian> tseng: I have one OldWorld left but I think I gave away the AC adapter. :-(
<tseng> heh
* tseng wonders where you got so many
<bddebian> tseng: When I worked at a big company I used to "borrow" the older models that just sat on the shelf.  A couple of them I bought off of e-bay.
<zyga> what are pbs?
<Simira> who was it that wanted me to bring Ubuntu t-shirts for sale on Debconf? *packing*
<bddebian> zyga: ?
<zyga> what are pb's?
<pitti> PowerBook?
<zyga> ah
<zyga> :)
* zyga wonders if old powerbooks become 50% cheaper once intel based mac laptos happen
<pitti> zyga: I really regret apple's decision
<pitti> zyga: my complete iBook takes about 10 W right now
<pitti> zyga: with pentium & co, this is certainly going to go up considerably
<zyga> pitti: mine takes zero - it's too pricy to buy
<pitti> hehe :-)
<Mithrandir> pitti: why do you think so?  My x40 uses about 10W.
<zyga> pitti: I agree that intel is a power hog
<zyga> but centrino is not prescott
<pitti> Mithrandir: that's good, ok :-)
<Mithrandir> but then, IBM are _good_
<jdthood> I thought that one of Apple's reasons for switching to Intel was that the mobile versions of Intel's chips used less power.
<pitti> huh?
<ivoks> jdthood: yeah, one of reasons
<pitti> interesting
<ivoks> intel developed great wifi, but only for pc
<bob2> x40s use special low-voltage pentium ms, tho
<tseng> all pentium m's are low voltage
<lu|away> jdthood: vastly, vastly less power
<mjg59> They're still faster than any Powerbook you're likely to find, though...
<hunger> Mithrandir: My ibm uses a bit more.... about 12W.
<ivoks> pitti: how's MTA? :)
<pitti> ivoks: runs fine, thanks again :-)
<ivoks> doh... no problem, really
<dilinger> pitti: thanks for the dm patches; i'll get around to looking at it at debconf, when i actually have some of that oh-so-elusive free time
<pitti> dilinger: great, we'll meet there any way :-)
<pitti> brb
<mxpxpod> bddebian: well, those sound like good causes
<bddebian> mxpxpod: I thought so :)
<mxpxpod> bddebian: now, if HURD could only get on track...
<mxpxpod> :D
<bddebian> mxpxpod: I'm working on that too :-)
<mxpxpod> sweet
<Keybuk> oh, good, vim also has a .svn directory in one of its patches
<zyga> Keybuk: you woundn't want to miss it, would you ;)
* Keybuk wonders whether Norbert will be at debconf
<Keybuk> if so, I'm having words
* Keybuk packs the clue-by-four
<bddebian> hehe
<mdz> wasabi: eclipse is looking spiffy
<mdz> takes ages to start on my laptop, but looks good when it gets there
<mxpxpod> mdz: kind of like oo.o2?
<lu|away> early ooo2 builds were actually faster than ooo1
<lu|away> not anymore, jeez
<Keybuk> oh, look, another keybuk-being-an-idiot bug here too
<Keybuk> *sigh*
<mdz> mxpxpod: no, eclipse takes _much_ longer to start than oo.o2
<mdz> oo.o2 starts in a reasonable amount of time for me
<mxpxpod> dang
<ogra> oh, i386 only...
<ogra> sad
<mxpxpod> mdz: it takes forever for me... it didn't used to and now it uses some java stuff that slooooows it down
<mdz> Kamion: can we easily add memtest86 as a boot option on both install and live?
<mdz> Kamion: in isolinux, I mean
<Kamion> good question; I suppose I could just sellotape memtest86+.bin into the CD's filesystem somewhere
<Kamion> nothing else is needed, is it?
<mdke> elmo, around?
<Kamion> mdz: doing
<mdke> mako, around?
<Kamion> mdz: done, assuming I didn't screw it up; haven't documented it yet
<mdz> Kamion: fantastic, thanks
<mdz> yeah, only memtest86+.bin is needed
<Kamion> called it 'memtest'
<mdz> Kamion: what would be involved in adding a media-check option?
<mdz> I guess it would need to ask the language question still
<mdz> unless we can manage to move that out to the boot loader after all...infinity?
<Kamion> not necessarily
<Kamion> if it were just an English media check, it could just boot with that main-menu option preselected
<mdz> well, it would be nice to be able to display the success/failure message localized
<mdz> though it is in color, I suppose, and so reasonably clear
<Kamion> if it makes any difference, I suspect it will be an order of magnitude less work this way :)
* Kamion goes to see whether it works
<Kamion> mdz: small main-menu hack required I think, but not too bad
<shwiiing> anyone working on the live-cd?
<mdz> yes
<shwiiing> yes shwiiing or yes Kamion ?
<Zomb> sounds like a vorlon-style YES (as in b5, not Steve)
<Kamion> shwiiing: it was to you
<shwiiing> oki, i have some expirience with livecd devel. need any help?
<hunger> shwiiing: I bet they can take some help. Ubuntu has surprisingly few people.
<Kamion> note that the Ubuntu live CD is rather different from other live CD systems; it's almost entirely built out of the regular system
<Kamion> the piece that makes it into a live CD is casper ('apt-get source casper')
<Kamion> which mdz maintains
<shwiiing> i made one just like a normal distro, just wrote my own linuxrc and loaded the knoppix-autoconf script, and i was up and running
<shwiiing> used unionfs and squashfs
<shwiiing> writeing the linuxrc file was realy tricky
<Kamion> we're very keen on sticking with the current broad outline since it provides many maintainability benefits, but improvements to the detail are of course very welcome
<Kamion> we tried the Morphix approach for Warty and had many problems
<shwiiing> i know
<Zomb> btw, the Ubuntu hw detection is crashing the kernel on my system while Sarge and Knoppix run fine
<Zomb> who does care?
<Kamion> Zomb: I'd care if given details ...
<Kamion> although I'm not a kernel hacker, fabbione would be better
<Kamion> Zomb: the Ubuntu hardware detection is basically just hotplug
<Zomb> then I would ask fabbione 
<Kamion> if that's crashing your kernel then it would be better described as your kernel crashing your kernel :-)
<Zomb> I think I have Cc'ed him already in some discussion about that
<Zomb> hehe
<shwiiing> Kamion, is there a website where i can get up to date with what you are working on?
<Kamion> udu.wiki.ubuntu.com is the development website from our last conference, with goals and plans
<Kamion> (although it'll be merged into wiki.ubuntu.com soonish)
<Treenaks> Kamion: any idea when the next conference will be?
<Kamion> Treenaks: I believe current plans are for October, shortly after the Breezy release; the business of having a conference very early in the release cycle worked out well this time
<shwiiing> ill take a look then
<Diziet> This network-manager package, erm, is it a package somewhere ?  Or did people who've tried it just `make install' ?  Or am I looking in the wrong places ?
<zanaga> Diziet: it's in universe
<Diziet> Oh, here it is.
<Diziet> I could swear I looked for it under `n' in pool but obviously I must have been wrong.
<Diziet> Ah, and the package search didn't get it 'cos I didn't spot that only hoary was selected.  I definitely need this coffee I have here.
<Lathiat> daniels: blah, x-common tries to overrwite /etc/X11/X which si also in xorg-common but xorg-common cant be upgraded until x-common is 
<Lathiat> daniels: doing a dpkg -i of xorg-common first gets around it, apt wont due to dep issues
<thom> Diziet: also, the package code is kept in the pkg-utopia svn repo on alioth
<thom> Diziet: when you need commit privs for that, please let me know and i'll get that sorted
<thom> Diziet: and, sorry for not having yet replied to your mail
<zanaga> seb128: am i missing something with bug #12336 why are you trying to load the html in totem?
<infinity> Lathiat : The file moved from xorg-common to x-common, you mean?
<Lathiat> infinity: i think so,a dn that x-common is being installed first
<Lathiat> the X dependencies are in quite a mess actually
<Lathiat> im having to randomly apt-get -f install, upgrade, dist-upgrade and manually install things to get this all to install
<Lathiat> without wanting to do something like remove libxll-6
<seb128> zanaga: you said "usually the files just fail to play, even if the file
<seb128> is supported in standalone totem.", I thought that was a redirection to the file or something
<zanaga> seb128: ah, no.. it's just a html wrapper to force the media to play in firefox.. the real media is named test.ogg
<infinity> Lathiat : Erm, x-common doesn't contain any files in /etc...
<Lathiat> also installing say, ttf-punjabi-fonts (and lots fo other similar packages) i get lots of cannot exec /usr/X11R6/bin/mkfontdir from defoma stuff
<Lathiat> infinity: well uh, tahts the error i got
<Lathiat> infinity: if you want to try, install hoary, then try dist-upgrade to breezy
<infinity> Default desktop install?
<Lathiat> yep
<seb128> zanaga: thanks, playing test.ogg from totem works fine ... now I can bug upstream
<azeem> http://people.debian.org/~mbanck/photos/lsm_2005/img005.jpeg.html <- that's what happens if gentoo dudes need to quickly fix their machines
<infinity> Alright, I'll play tomorrow when the new laptop gets here.  It'll need an OS anyway. :)
<Lathiat> infinity: :)
<Lathiat> whatcha gettin?
<jbailey> Nice, I googled for 'rsync' cd image, and Ubuntu is #2.
* lamont lunches
<infinity> T43, 2GHz Pentium-M, 2GB of RAM, some other toys.
<zanaga> seb128: great, i just wanted to file it in ubuntu bugzilla so that it doesn't get missed when breezy is released
<Lathiat> infinity: nice
<Lathiat> infinity: what size, gfx?
<seb128> zanaga: np, that's fine like this, thanks
<Lathiat> my laptop is a 2ghz pentium-m
<Lathiat> it needs more ram
<Lathiat> but its very nice
<infinity> Lathiat : Smallish (the T43 is sorta the middle road, size-wise, between tiny laptops like the X series and big desktop replacement stuff)
<Lathiat> infinity: so, 15"
<Lathiat> ?
<Lathiat> mines 15.4" widescreen
<Lathiat> 1680x1050
<Lathiat> very nice
<infinity> Graphics is just an X300.  And yeah, 15" 1400x1050.
<Lathiat> sweet, same as mine then
<Lathiat> just not widescreen
<Lathiat> i find this a nice size
<Lathiat> i couldnt deal with less
<infinity> THe laptop's too small to be a widescreen.
<Lathiat> its only 3.3kgs, so its portable
<infinity> Which is fine by me, I don't want something massive.
<Lathiat> wouldnt want any bigger
<Lathiat> the thign for me, is i dont have a desktop, this is my only machine
<infinity> Anyhow.  Severly off-topic we are, and I should go to bed.
<Lathiat> hehe ok night :)
<pitti> does anybody know how to get back PostScript fonts?
<pitti> I can't display any pdf or ps file, everything is just empty...
<Lathiat> hm, openoffice.org2 is unisntallable
<JanC> I upgraded it yesterday?  (twice, in fact)
<JanC> this new OOo2 beta starts slower than the old OOo2 alpha though  :-/
* lu|away is glad to hear it isn't just me
<highvoltage> any ubuntu guys still in london?
<mdke> lots
<mdke> all well apparently
<highvoltage> ah, good.
<JanC> highvoltage : canonical has offices in london
<highvoltage> i know, sorry, should've been more specific with the question.
<highvoltage> is matt still there? i think he said he was leaving today.
<Diziet> I was supposed to be meeting mdz there.  I got as far as buying a ticket at Cambridge (looking at the departure displays thinking `well, it's a bit disrupted but I'lll just be half an hour late') before they told us there were no trains to London today.
<highvoltage> that's hectic.
<mdz> highvoltage: (yes, I'm here until tomorrow and am alive)
<highvoltage> mdz: cool.
<highvoltage> egh. not having an internet connection is killing me.
<comadreja> 
<Kamion> mdz: tomorrow> that's what YOU think. it's all a plot to keep you locked in London.
<ogra> hehe
<ogra> Kamion, did vedran talk to you about the installer ? he's one of my students doing the lightweight desktop
<highvoltage> Kamion: this is starting to sound like a humorix conspiracy
<Kamion> ogra: no
<ogra> hmm
<ogra> ok
<Kamion> ogra: or at least not that I remember
<highvoltage> good to see everyone is still alive. i need to go back home now, cheers!
<doko> pitti: ping
<carstenh> doko: he is not here
<ogra> doko, ! how is finland ?
<doko> ogra: just arrived. nice.
<ogra> have something to shade your eyes to get some sleep ? 
<ogra> :)
* ogra remembers bergen had only 3h darkness per night
<Simira> hehe
<Simira> were you in bergen in june, ogra ?
<ogra> yep
<ogra> lots of rain :)
<ogra> but you have a wonderful country over there :)
<jdthood> thom: Is there somewhere I obtain a network-manager deb?
<ogra> jdthood, its in the archive
<ogra> jdthood, try http://packages.ubuntu.com/
<jdthood> ogra: ooo, so it is.
<ogra> :)
<ogra> but beware it still has issues
<ogra> (like running a local bind9 server for caching)
<jdthood> ogra: If you can read this then it's working.
<ogra> heh
<ogra> sure it works... but who wants to run a nameserver on a desktop :)
<tseng> i do, if it means not opening consoles and playing with iwconfig all day
<jdthood> ogra: There are good reasons for running a caching nameserver, at least.
<ogra> jdthood, bind9 ??
<jdthood> ogra: I have used dnsmasq for a long time.  it is excellent.
<ogra> yes, thats a well sized solution for a desktop/laptop ....
<jdthood> ogra: bind9 might be appropriate for some applications.  The point is that n-m should be able to integrate with either bind9 or dnsmasq.  or pdnsd.
<ogra> yes
<jdthood> ogra: Even before n-m, we had correct handling of bind9, dnsmasq and pdnsd through resolvconf.
<ogra> yup
<ogra> thats what i meant with "it still has issues"
<jdthood> So I am not sure that it will be necessary for n-m to continue to drag in bind9.
<Keybuk> \o/  vim imported at last
<ogra> new vim ?
<mxpxpod> what do I do if I get an warning when resolvconf loads that resolv.conf isn't a symlink?
<jdthood> ogra: Maybe n-m and bind9 are doing things together that are more intimate than we're aware of.
<Keybuk> ogra: no, breezy vim, into baz
<ogra> jdthood, they do, but its possible t oimprove it :)
<zwnj> hi there
<jdthood> mxpxpod: You are the victim of some package that has overwritten /etc/resolv.conf.  Using network-manager by any chance?
<zwnj> any reason to not redirecting bugs.ubuntu.com to bugzilla.ubuntu.com?
<jdthood> mxpxpod: resolvconf Conflicts with every package in Debian that writes to /etc/resolv.conf.  resolvconf doesn't Conflict with network-manager (yet) because the latter isn't in Debian.
<ogra> Keybuk, ah.. 
* Keybuk moves onto the next failure in the list ... unsermake!
<jdthood> mxpxpod: However, I have heard rumors that n-m is being modified to cooperate with resolvconf.
<jdthood> mxpxpod: To answer your question, what you need to do is remove the offending package and then "ln -sf /etc/resolvconf/run/resolv.conf /etc/resolv.conf"
<Lathiat> seb128: the drivemoutn applet is having issues lately, it goes over the panel size, notably with cdroms, although tis doing it now without
<Diziet> Oh, people talking about network-manager.  Hello.
<malex> So, restricted == contrib and multiverse == non-free?
<wasabi_> multiverse == contrib and non-free
<wasabi_> restricted ~= both
<malex> ooer, ok. Thanks wasabi!
<mdke> smurfix, ping?
<smurfix> mdke: 
<mdke> rocket fast as always
<smurfix> heh
<mdke> smurfix, actually can you give me 5 mins?
<smurfix> 5 mins before you say something, or 5 mins during which?
<mdke> the first one
<smurfix> NP
<mdke> ty
<mdke> smurfix, okay here i am
<mdke> smurfix, ubuntu-it would like to take you up on the hosting offer
<smurfix> OK
<smurfix> email me an SSH pubkey please (gpg-signed)
* lamont looks around for daniels, decides it's still mid-sleep-period for him
<mdke> smurfix, i will see what I can do, I'm a bit inexperienced with ssh keys
<smurfix> man ssh-keygen ;-)
<mdke> will do
<mdke> smurfix, any requirements as to the type of key or length?
<smurfix> dsa is standard and the default 1024 bits probably sufficient
<mdke> okies
<jp> hi guys, I installed colony cd 2 and I updated, and gdm doesn't start, who have resolved it? Thanks guys :/
<jp> :(
<jp> I did some symlinks, but it doesn't start :/ says /usr/bin/X11/X cannot execute :/
<wasabi_> Hmm. Ooo2 still dislikes my theme.
<jp> I did ln -sf /etc/X11/ /usr/bin/X11/ but it doesn't work too :/  who can say me what symlinks did to use xserver? :)
<torkel> jp: try ln -s /usr/bin/Xorg /etc/X11/X
<jp> torkel: that didn't work, thanks btw
<torkel> jp: do you have a /usr/bin/Xorg ?
<torkel> jp: you can also try with ln -sf /usr/X11R6/bin/Xorg /etc/X11/X
<jp> ok torkel let's do
<jp> no :'(
<jp> torkel, yes I have a /usr/bin/Xorg
<torkel> and it still complains that it cannot execute /usr/bin/X11/X?
<jp> yes :'(
<jp> /usr/X11R6/lib/X11/xinit/xserverrc: line 2: /usr/bin/X11/X cannot execute
<jp> :/
<mdke> smurfix, still around?
<smurfix> mdke: yo
<mdke> smurfix, can i fire some questions at you in PM?
<mdke> or here i guess
<daniels> sudo rm -rf /usr/bin/X11 && sudo ln -s /usr/bin{,/X11}
<jp> let's do it daniels thanks :)
<jp> uhmm daniels: X: unable to open wrapper config file /etc/X11/Xwrapper.config /etc/X11/X is not executable :) things have changed =)
<jp> I chmod it and now it only says: /etc/X11/X is not executable :)
<TerminX> what's the "accepted" fix for the xkbcomp problem?
<Mez> siretart: ping
<jp> hi jbailey, did you find some relations to the evo exchange bug? :/
<jbailey> jp: I haven't been working on that, sorry.  
<jbailey> jp: You mentioend that you were going to check upstream bugzilla.  Did you find anything?
<jp> jbailey I find but I didn't found :/
<jp> so let's report it? I'll find again, and then I'll report it there jbailey :)
<Burgundavia> jdub, new nautilus look for breezy
<tseng> Burgundavia: eh?
<Burgundavia> both jdub and I like the look for thunar
<Burgundavia> which can now be done with nautlius
<tseng> the spatial tree view?
<Burgundavia> this one: http://thunar.xfce.org/wiki/media/ui/suggestion-20050320/shortcuts_buttons.png
<tseng> oh yes
<tseng> bookmark sidebar
<Burgundavia> and the top row of buttons, ala gtk file chooser
<wasabi_> I wouldn't mind that.
<tseng> does nautilus have the later?
<Burgundavia> yes
<wasabi_> I think the bookmars might be a bit annoying after awhile
<Burgundavia> new plugin just merged
<Burgundavia> http://gnomedesktop.org/node/2312
<Burgundavia> specifically --> http://mail.gnome.org/archives/nautilus-list/2005-July/msg00026.html
<Burgundavia> it would be single window, ala the OS X finder
<Burgundavia> tseng, do you like the idea?
<wasabi_> Should just make Nautilus itself the FileOpenDialog like MS did
<tseng> Burgundavia: sure
<Burgundavia> wasabi, that was my next crazy thought
<tseng> wasabi_: ...
<wasabi_> WHy ...?
<wasabi_> Code resuse.
<wasabi_> reuse
<tseng> thats bogus
<wasabi_> It makes absolute sense to reuse nearly all of hte visual elements.
<wasabi_> MS hit that point too.
<Burgundavia> consistent interface?
<wasabi_> Everybody always whines about that.
<wasabi_> But the fact is, it only makes sense technically.
<Burgundavia> it does make sense from a design pov as well
<Burgundavia> and a usability one
<wasabi_> Yup.
<wasabi_> The file browsing interface becomes a generic library with a view component and hooks to plug in special features
<wasabi_> nautilus becomes a consumer, as does the FileOpen dialog
<wasabi_> In MS's case they wanted to put HTML in both, and so IE came in too.
<Burgundavia> oh joy
<wasabi_> =)
<Burgundavia> can we leave out that part?
<wasabi_> You haven't seen the Office WebDAV interface.
<wasabi_> It's pretty slick.
<tseng> wasabi_: except that the gtk team and the nautilus team would be working on the same code
<tseng> wasabi_: with different release cycles
<Burgundavia> the outlook web stuff in IE is pretty slick too
<wasabi_> tseng, the curse of not working in the same building on the same project.
<tseng> it doesnt make that much sense in real life
<tseng> as it does in theory
<Burgundavia> the gtk people are trying to sync their releases to gnome, from what I understand
<jp> jbailey, Evolution bugs have been migrated to bugzilla.gnome.org. So I'll search there..
<wasabi_> http://akita.larvalstage.net/~wasabi/webdav.png
<wasabi_> WebDAV interface.
<Burgundavia> ugh
<wasabi_> Heh.
<jbailey> jp: Oh?  Cool.  I didn't think they'd get aroudn to that.
<wasabi_> The webdav server serves the interface as HTML.
<Burgundavia> sorry, that is butt ugly and completely different from any other interface
<wasabi_> Oh yeah, I agree.
<Burgundavia> but the idea may be workable
<jp> jbailey yep :/
<wasabi_> I think the specific implemenation may suck.
<Burgundavia> as usual with MS, they have great ideas, but their implementations suck
<wasabi_> Basically though, if the webdav serves HTML in the right way, office can save to it.
<wasabi_> And it has a special server-delivered interface
<wasabi_> We use it for document management stuff.
<Burgundavia> I once read a thing about board game designing (but it applies here). I was about good ideas and how cheap they are
<jp> jbailey, :) http://bugzilla.gnome.org/show_bug.cgi?id=307956
<wasabi_> Notice the special additions.
<wasabi_> "Checked Out Too"
<jp> there's the bug :P
<Burgundavia> that can be done within an existing interface
<Burgundavia> without needing to completely redesign the open dialog window
<wasabi_> Yeah, it can be done with gtk and nautilus using the same interface.
<wasabi_> Supporting the same plugins.
<wasabi_> etc
<wasabi_> All the explorer plugins that I have installed, such as TortoiseSVN, which allows me to deal with SVN working copies, are all present anywhere a file tree is.
<wasabi_> Explorer, Open/Save, most tree views in apps.
<jbailey> WTF?  ephy is so confused.
<jbailey> jp: I'll add myself to the cC: list as soon as I can convince it to let me log in.
<Burgundavia> wasabi, MS has a history of completely redesigning interfaces, seemingly for the sake of doing so
<wasabi_> What do you call what we do?
<wasabi_> Heh.
<jp> jbailey ok :)
<wasabi_> As time goes on, changes are though up which may increase usibility. Some don't, some do.
<wasabi_> (spatial anyone?)
<wasabi_> (new nautilus interface discussed 5 minutes ago)
<Burgundavia> spatial is a good idea
<Burgundavia> we just are not complete there yet
<wasabi_> Dude.
<Burgundavia> ly
<wasabi_> I think spatial blows goats. =)
<wasabi_> And I think MS's HTML interface blows goats.
<wasabi_> But apparerently some people like it.
<Burgundavia> ok
<wasabi_> I shall not insult either group.
<Burgundavia> did you see my rant about XP on p.u.c?
<Burgundavia> to think I used to use windows 100% of my day
<jdthood> thom: ping
<wasabi_> one sec reading
<wasabi_> First complaint you list is one that is not considered a bad thing by a lot of people.
<wasabi_> Myself included.
<Burgundavia> one giant menu?
<wasabi_> second thing.
<wasabi_> =)
<wasabi_> I go to www.superprogram.com, download SUper Program 3.0 and install it. It appears in my menu as Super Program 3.0, not "Generic Program That Does Something". I know what to look for before I get there.
<wasabi_> And everytime I go there, I know it by name.
<Burgundavia> that works if you know what you are looking for
<Burgundavia> and is very application centric
<wasabi_> When I pay for it, it shows up on my bill as SuperCompany.com
<Burgundavia> it falls apart when you have no idea what you are looking for, but know what you want to do
<wasabi_> Exactly. Both things are valid.
<Burgundavia> which I would say is more important
<wasabi_> MS and Apple solved it fairely reasonably.
<wasabi_> MS called their text editor notepad. Which is fairly obvious as to function.
<Burgundavia> yes
<wasabi_> Mail is pretty clear too.
<Burgundavia> outlook? evolution?
<Burgundavia> evince?
<Burgundavia> these are not clear application names
<wasabi_> You're right, the problem with them is one of our community.
<wasabi_> We have 4 PDF viewers.
<Burgundavia> we know have one
<wasabi_> And a billion mail readers.
<Burgundavia> evince
<wasabi_> Okay, good.
<Burgundavia> windows has just as many mail readers
<wasabi_> Yeah, and they're known by name.
<wasabi_> I like Apple's idea. THe bundled stuff becomes generic.
<wasabi_> And it becomes pruned down.
<wasabi_> But third party stuff stays as it is.
<Burgundavia> that is what gnome is also trying to do
<Burgundavia> the only place the word evince appears anywhere in the interface is in the about box
<Burgundavia> oh wait, it appears in the menu item as well
<wasabi_> Rhythmbox was a specific complaint I had, but that's been addressed.
#ubuntu-devel 2005-07-13
<Burgundavia> the non-gnome intergrated stuff tends to be bad
<Burgundavia> like audacity, nvu and others
<thom> jdthood: pong, kinda
<Burgundavia> wasabi, I think the 3 menus is more usuable, because 95% of the time you go to the start menu, you are not looking for hte control panel, and yet there it is
<jdthood> thom: Any new thoughts about n-m and resolvconf?
<jdthood> thom: I was thinking about network-manager and bind9...
<thom> jdthood: Diziet (iwj) has been looking at that too
<wasabi_> Yeah I like the 3 menus.
<thom> jdthood: will you be at debconf?
<jdthood> thom: If n-m uses resolvconf to update resolv.conf then it gets integration with bind9, dnsmasq, pdnsd and nscd for free.
<thom> nod
<jdthood> thom: No, I don't plan to be at debconf.
<thom> ah, shame
* thom is packing currently, and has about a gazillion things to do :(
<jdthood> What is needed, though, is for all nameserver addresses to be sent to resolvconf, not just 127.0.0.1.  Those obtained via DHCP should be stored is separate records.
<jdthood> Probably.
<jdthood> thom: Anyway, I am using n-m now and it is working well!
<jdthood> thom: BTW, how does n-m update bind9's configuration?
<lamont> mdz: http://archive.ubuntu.com/ubuntu/pool/main/d/dpkg
<lamont> thom: there's also a bug outstanding against bind9 to not force 127.0.0.1 as the resolver when bind9 starts
<Burgundavia> that is the ugly bug that bites you with n-m in recovery mode?
<lamont> Burgundavia: that's the "I'm running a nameserver, but it has a totally diff config than what my resovler needs" bug
<lamont> specifically, if you disallow recursion on the nameserver, you probably don't want to point the resolver at it...
<thom> jdthood: it writes a config file and starts an instance of bind9 with that config
<thom> lamont: nod
<jdthood> thom: Where's the file?
<thom> jdthood: /var/lib/NetworkManager/NetworkManager-named.conf
<jdthood> thom: Was /var/lib chosen over /var/run for some reason?
<thom> me forgetting the specifics of the FHS for /var at the time?
<thom> ;-)
<jdthood> thom: resolvconf writes /var/run/bind/named.options.  This is /etc/bind/named.conf.options with the forwarders statement changed and everything else left alone.
<thom> right
<jdthood> I see that n-m uses its own template at /usr/share/NetworkManager/named.conf.  I am not sure which way is better.
<jdthood> thom: In any case, dnsmasq will be a better choice for many people.  It handles dynamic updating of the forwarders list much less clunkily.
<jdthood> thom: resolvconf writes dnsmasq's list at /var/run/dnsmasq/resolv.conf.
<thom> the issue is really having something that NM can control. at the moment that's really just bind; going forward hopefully more options are available
<thom> anyhow, must go pack
<jdthood> OK, catch you later
* maswan sighs, anyone with ops over at #ubuntu wouldn't be available? a couple of rather upsetting people there now.
<maswan> ah, nevermind. thanks ajmitch 
<mae> is glade3 dead?
<malex> I am trying to build a package of mine in a breezy chroot. For some reason the configure fails to find the /usr/include/X11/Intrinsic.h from libxt-dev in this chroot though it finds it fine in a Debian testing or unstable chroots. Neither I or upstream devz can find any differences. Any idea?
<malex> http://scribus.tagancha.org/download/config.log.breezy
<malex> http://scribus.tagancha.org/download/config.log.testing
<malex> Riddell: ping
<superted> will hoary see GNOME 2.10.2 ?
<calc> breezy already has 2.11.4 if you want new toys :)
<superted> hehe
<schweeb> what's the current method for bug reporting?  go to malone exclusively, or cross post?
<schweeb> (w/ bugzilla)
<wasabi> jdub, do I ask you to be on planet ubuntu? :)
<jdub> wasabi: you're an ubuntu member?
<jdub> (i imagine so!)
<wasabi> I'd hope so!
<wasabi> Somehow I can upload to main!
<jdub> got an rss url and maybe hackergotchi?
<jdub> haha
<wasabi> no hackergotchi...
<wasabi> http://www.larvalstage.net/index.php?/feeds/categories/4-ubuntu.rss
<jdub> 'sok, you can appeal for one :)
<wasabi> I don't actually have a good real picture of any kind.
* jp has rss and hackergotchi jdub ;)
<jp> hahah
<jdub> wasabi: http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fwww.larvalstage.net%2Findex.php%3F%2Ffeeds%2Fcategories%2F4-ubuntu.rss
<jp> :)
<jdub> ^ nothing important
<wasabi> neato page
<jdub> jp: are you an ubuntu member?
<wasabi> what
<jp> jdub no, but I was just joking :-P
<wasabi> that error is stupid.
<wasabi> a postiive integer?
<wasabi> I see. It shouldn't be included if 0?
<jdub> guess so
<seth_k> wasabi: did you know that http://larvalstage.net goes somewhere different than http://www.larvalstage.net ?
<lamont> wo bissen daniels
<lamont> yeah, he's plural now.
<lamont> :-)
<wasabi> does it? probably.
<wasabi> oh heh.
<bob2> lamont: did you ever get ubuntu to like your cell phone?
<wasabi> i left an A on it back in the day for jabber
<wasabi> wonder if jabber fixed that
<lamont> bob2: no
<lamont> hrm... ubuntu seems to be missing slang2
<lamont> but has lots of stuff build-dep libslang2-de3v
<bob2> my hardware karma is getting worse
* lamont wanders off
<lamont> heh
<bob2> a second switch just stopped working
* lamont makes a note to never invite bob2 over to view the computer cluster.
<bob2> nah, it's not contagious, it only affects things I buy
<lamont> anyway, short night tonight.
<bob2> adios, lamont
<jdub> wasabi: i've committed, will have to wait on an update from elmo
<wasabi> oh? I have no idea how that stuff works.
<wasabi> you having to commit something and wait for elmo seems pretty damned weird though
<tseng> it needs a manual push to the server
<tseng> giving jdub direct access would make elmo cry
<wasabi> I was expecting that there was a "login" button.
<wasabi> To an "admin" page.
<wasabi> Which let you add new feeds.
<tseng> its a flat file
<Amaranth> jdub: can nalioth be an op in #ubuntu? he has been a lot of help and seems to fit into a gap in the coverage
<Amaranth> btw, is the us mirror having problems?
<mxpxpod> does anyone here have network-manager working with linux-wlan-ng?
<mxpxpod> network-manager seems to report my wlan-ng card as a wired network interface
<bob2> where was "backports are official" announced?
<rob^> was it ever?
<bob2> it was on the forums
<schweeb> bob2: ubuntu-devel
<schweeb> the mailing list
<fabbione> morning
<fabbione> Setting up x-common (1.02) ...
<fabbione>  /usr/bin/X11 still contains files (are they locally installed?)
<fabbione> Please examine the following list and either delete these
<fabbione> files, or relocate them to /usr/bin, then reinstall x-common:
<fabbione> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
<fabbione> wtf is this??
<fabbione>  /usr/bin/X11/cpp-4.0
<fabbione> ??????
<schweeb> whoa
<schweeb> definitely haven't gotten that one
<fabbione> (clean install btw)
<infinity> fabbione : ...
<fabbione> infinity: fix that crap. kthxbye
<fabbione> infinity: i got that in a buildd chroot
<infinity> fabbione : /usr/bin/X11 is a directory?
<fabbione> clearly cpp-4.0 is not in X11/
<infinity> fabbione : Or is it a symlink, and I'm a shell crackwhore.
<fabbione>  /usr/bin/X11/X11:
<schweeb> chris@schweeb-x41:/usr/bin/X11$ pwd
<schweeb> /usr/bin/X11
<fabbione> ls -asl X11
<fabbione> 0 lrwxrwxrwx  1 root root 6 Jul  8 03:56 X11 -> ../bin
<infinity> Right, I'm an idiot.
<fabbione> schweeb: pwd is useless in that case
<schweeb> chris@schweeb-x41:/usr/bin/X11$ ls -l cpp*
<schweeb> lrwxrwxrwx  1 root root     7 2005-06-30 19:29 cpp -> cpp-4.0
<schweeb> -rwxr-xr-x  1 root root 86192 2005-06-22 09:46 cpp-3.3
<schweeb> -rwxr-xr-x  1 root root 85712 2005-07-06 13:09 cpp-3.4
<schweeb> -rwxr-xr-x  1 root root 89784 2005-07-01 22:48 cpp-4.0
<infinity> [ -d ]  is true for symlinks to directories as well as real directories.
<infinity> Fixing now.
<schweeb> fabbione: redundancy is good :)
<fabbione> schweeb: usually i don't lie to infinity :)
<fabbione> inflicting pain is more fun :P
<schweeb> lol
<schweeb> infinity sleeps with the fishes?
<daniels> infinity: yeah, was planning to harass you about that and get you to upload it for me when I came over
<daniels> infinity: even better
* daniels lurks for a day or two.
<rob^> has anyone installed daemontools before? which is the recommended approch, the djb format or fhs?
<rob^> probably better to ask here
<infinity> rob^ : I tend to recommend not installing them.
<rob^> I wanted to have a look at djbdns is all
<rob^> maybe I might stick to bind
<rob^> why do they make all the non-standard directories?
<tiglionabbit> hey guys, I found a predictable way to crash kaffeine
<tiglionabbit> or is that more of a kubuntu thing?
<tiglionabbit> anyway, it has an odd behavior of continuing to run after a control-C at terminal.  After that, clicking on certain features will cause it to die
<rob^> thanks
<JaneW> when does debconf5 end?
<jvw> JaneW: when it's ready ;)
<jvw> (17 july)
<fabbione> hmm the new udev isn't exactly user friendly....
<fabbione> Kamion: http://people.ubuntu.com/~fabbione/partman.diff
<fabbione> Kamion: mind if i upload+
<fabbione> apparently the new udev is more picky about device creations...
<fabbione> change is trivial and not intrusive
<fabbione> (and it fixes the problems i am getting here)
<JaneW> jvw: hehe, thanks
<doko> good morning
<ivoks> morning
<Kamion> fabbione: how about I just do that upstream now
<fabbione> Kamion: that works for me, but take into account we need it very fast
<fabbione> otherwise part* fails to format the partitions :)
<fabbione> Kamion: i also uploaded p-a-l 2ubuntu2 to fix the partition size calculation...
<fabbione> Kamion: and i splitted the patches..
<fabbione> http://people.ubuntu.com/~fabbione/pal/2_to_2ubuntu1/ <- old patches
<fabbione> http://people.ubuntu.com/~fabbione/pal/2ubuntu1_to_2ubuntu2/ <- new ones
<Kamion> fabbione: committed upstream, but go ahead and upload it to Ubuntu, we're branched anyway
<fabbione> Kamion: ok thanks
<fabbione> done...
<fabbione> morning mdz
<mdz> fabbione: mroning
<mdz> morning
<mdke_> morning all
<Ferry|Teched> lol Microsoft is using ubuntu in a teched presentation
<Ferry|Teched> to demonstrate the new scm in visual studio team system
<Mez> how did you find that out
<Ferry|Teched> well im in the presentation now
<Ferry|Teched> using wifi
<Mez> lol - take pictures :D
<Ferry|Teched> if all goes well i will get the demo on video
<Mez> lol
<Mez> kool
<Mez> ;)
<mdke_> nice one Ferry|Teched 
<Mez> afternoon Scott
<Keybuk> morning
<mdke> smurfix, reping
<mdz> infinity: did elmo talk with you about the current status of -backports?
<mdz> lamont,infinity: something about sbuild/wanna-build/etc. being tilde-intolerant
<Mez> lol
<seb128> herzi: around?
<herzi> yo
<seb128> herzi: should I go with mclasen's update patch for the font capplet?
<seb128> or you are still both discussing changeS?
<smurfix> mdke: re
<mdke> smurfix, sorry to disturb, i have a couple of questions
<smurfix> mdke: shoot
<mdke> smurfix, i've made an ssh key for ubuntu-it and signed it with my gpg key. question 1 is do you need it encrypted with your key too? question 2 is, is it possible for more people than me to use it? we had intended giving access to the website to our web group, access to the wiki to our wiki group, access to the forum to the forum group etc. You think this is gonna be possible?
<herzi> seb128: just go with it, we had some discussions, i will them later
<smurfix> mdke: You don't need to encrypt public keys, they're public ;-)
<smurfix> If somebody else want access too, I need their pubkey
<mdke> k
<smurfix> don't share private ssh keys
<mdke> smurfix, k
<mdke> smurfix, is there any possibility of giving different people access to different things? or is that too complicated?
<smurfix> wiki/forum/... access control is usually done through the web, I don't envision people logging in with ssh for that
<mdke> smurfix, ok for forum, but for wiki we're hoping to copy files across from the current wiki
<mdke> actually ditto for forum database
<smurfix> that should be a one-time-only job, right?
<mdke> yes
<smurfix> so just trust people on that day not to step onto each other's feet (or worse)
<mdke> smurfix, ok that should be fine
<mdke> smurfix, sending key now
<mdke> smurfix, oh btw my gpg key is not in the trusted set, is that going to be a problem?
* smurfix grumbles
<smurfix> what's the fingerprint?
<mdke> AF99 4F01 E749 720E 0C3B  1CC7 B526 85D3 0E6B 06FF
* smurfix waits for the email
<mdke> henrik has signed it, but that's all
<mdke> he's not trusted yet ;)
<smurfix> biglumber.com is your friend ...
<Mez> mdke, you dont have a pg key in the strong set ?
<mdke> not yet
<Mez> and I thought you had upload!
* Mez shrugs
<mdke> to what?
<Mez> ubuntu
<Treenaks> I'll be in Berlin at the beginning of September.. so if anyone there needs a sig :)
<mdke> erm... no
<Mez> some people here give the impression they're devs :D
<Mez> I always thought you were a dev already
<Mez> mdke - where you based?
<mdke> that doesn't sound like a complement
<mdke> london
<fabbione> Kamion: i think we can start somehow to include p-a-l as part of the install path.. tough that breezy can't install today
<mdke> smurfix, got the email?
<Mez> mdke: if you live in london - just check out biglumber, there's a few people there who'll sign
<mdke> Mez, yeah i know
<Mez> mdke: so whats the trouble getting it signed :D
<smurfix> mdke: no. Where'd you send it to?
<fabbione> Kamion: the last version fixes handling of some recipes...
<fabbione> hi elmo
<mdke> smurfix, smurf@smurf.noris.de
<fabbione> elmo: concordia is dead again, but i guess you alredy know that
<thom> elmo: last minute data centre fun? :_
<thom> )
<elmo> thom: yeah, I figure leaving 2 pallets worth of gear upstairs but outside our area for a week while I'm in debconf might not make me many friends at mnet
<thom> heh, maybe not
<mdke> elmo, if you can find time to do some docteam svn accounts we would love you forever
<fabbione> elmo: send them here :) i will give them a lot of love
<fabbione> elmo: i can even sing them a goodnight song ;)
<smurfix> mdke: you got smapfiltered on account of 212.74.114.48 being listed in a bunch of RBLs
<smurfix> spamfiltered
* fabbione -> food
<mdke> smurfix, ah shit i'll try again from another account shall i?
<smurfix> mdke: Now please throw away your SSH key, generate a new one, and send me the *public* part. :-/
<smurfix> no, I got it, that's not the real problem. ;-)
<mdke> eh?
<mdke> i followed a guide...
* mdke starts again
<smurfix> you need to send the file "id_dsa.pub", not "id_dsa"
<mdke> ok will start again, thanks
<Kamion> fabbione: that's entirely controlled by its priority - just bump that to standard and it'll be used
<Kamion> fabbione: shall I do that?
<mdke> smurfix, resent
<Mez> what's he mean to resent
<mdke> haha
<Mez> ooh
<Mez> shineh
<Mez> http://archive.ubuntu.com/ubuntu/dists/hoary-backports/
<mdke> do we have a summary of the backports meeting yet?
<fabbione> Kamion: 12392.. do you realize that ppc64-di is created on the base of ppc-di.. same file.. i make no difference
<mdke> or any copy of the rules for backports?
<Mez> we have a copy of the rules :D
<Kamion> fabbione: well I'm just looking at the diff
<Mez> but not a summary of the meeting
<mdke> Mez, have you got a url for me?
<Kamion> I'm checking out the source now to look
<Mez> just finding it mdke 
<fabbione> Kamion: nic-modules:drivers/net/sungem.o
<fabbione> it's there and mandatory
<Mez> http://ubuntuforums.org/showthread.php?t=40291
<Kamion> is sungem build for -powerpc64-smp-di?
<Kamion> er, let's try that again
<Mez> i's in there under Can I ask for packages to be backported?
<Kamion> is sungem built in the powerpc64-smp config?
<fabbione> powerpc64-smp:CONFIG_SUNGEM=m
<fabbione> yes
<fabbione> let me check also the build-log
<fabbione> but i am sure
<fabbione> it's there
<mdke> Mez, ok thanks, that should probably be on the wiki. Who applies those rules?
<fabbione>   CC [M]   drivers/net/sungem.o
<fabbione>   CC [M]   drivers/net/sungem_phy.o
<Mez> how do you mean "applies" them
<mdke> Mez, who ensures they are complied with?
<Mez> the BP team .
<mdke> ok
<mdke> is there any interaction with -devel?
<Mez> mdke :D jsut had a chat with mdzz about this all actually
<Mez> anything that doesnt auto-backport will have to be fixed upstream (aka in breezy)
<Mez> so that'll mean wotking with -devel and -motu
<mdke> sure
<mdke> so will you guys use the same mailing list? or carry on using the forum?
<Mez> that hasnt been discussed yet
<fabbione> Kamion: amen.. this is a bug.. a weird one
<Kamion> * from archive cached: kernel-team@ubuntu.com--2005/kernel-debian--pre1--2.6.11.91--patch-33
<Kamion> * Applying 85 revisions: .....................
<Kamion> hmm, this is going to take a while :-/
<Kamion> you guys need to cacherev more often
<fabbione> Kamion: i think it's a bug in kernel-wedge
<fabbione> because the powerpc and powerpc64 shares the same d-i file lists
<fabbione> and the driver is definetely built and shipped
<fabbione>  essbee [~sb@nat-pool-brisbane.redhat.com]  has joined #linux-cluster
<fabbione> ops
<fabbione> linux-image-2.6.12-3-powerpc64-smp_2.6.12-3.3_powerpc.deb
<fabbione> -rw-r--r-- root/root     68297 2005-07-04 18:32:18 ./lib/modules/2.6.12-3-powerpc64-smp/kernel/drivers/net/sungem.ko
<fabbione> -rw-r--r-- root/root     23887 2005-07-04 18:32:18 ./lib/modules/2.6.12-3-powerpc64-smp/kernel/drivers/net/sungem_phy.ko
<fabbione> and it's listed...
<fabbione> but it doesn't appear in any udeb
<fabbione> Kamion: i got it...
<fabbione> don't worry..
<fabbione> i will need to cleanup nic-* and scsi-* asap
<Mez> hmm
<Mez> what's colin watson's IRC nickname/
<fabbione> Kamion: apparently kernel-wedge doesn't error anymore if a module is missing
<mdke> Kamion
<Treenaks> Mez: Kamion 
<fabbione> and it creates half empty udebs
* Treenaks reads -announce
<Mez> aha :D
<fabbione> Kamion: i think the same problem is with all the other arches
<Kamion> I thought you ignored those errors
* Mez nenver remembers that
<fabbione> Kamion: no.. remember a long time ago that i was ignoring them.. we had this exactly same issue?
<fabbione> Kamion: i did revert that behaviour so that the kernel would FTBFS if the modules were missing..
<tseng> thom: does breezy not have the cisco vpn n-m stuffs?
<tseng> thom: i cant find it
<fabbione> Kamion: but apparently it has been done in kernel-wedge...
<fabbione> Kamion: nullifing my checks...
<thom> tseng: not yet, no
<tseng> thom: ..there it is
<thom> oh, you mean vpnc?
<fabbione> Kamion: ok.. let's do this way.. upload kernel-wedge 2 when you have time
<tseng> nm-vpn-properties
<fabbione> Kamion: and i will switch to it and finish the cleanup in one go
<thom> tseng: there's a tonne missing from that, it won't work
<tseng> ok
<Kamion> kernel-wedge hasn't changed much, and it *looks* like it should error
<Kamion> but ok, I'll work on that
<fabbione> Kamion: i am 100% sure i am not | true anymore :)
<fabbione> Kamion: so if kernel-wedge doesn't fail.. i don't as a consequence
<Kamion> it's all set -e
<Kamion> weird
<fabbione> what is weird is why it does include the module for ppc and not for ppc64
<fabbione> ah well.. no
<fabbione> sorry.. forget the last line
<mdke> smurfix, did you get the mail this time?
<mdke> smurfix, i tried a different account
<smurfix> mdke: looks slightly more sensible this time ;-)
<smurfix> mdke: You can now login to ubuntu-it@ubuntu-it.org
<mdke> smurfix, ok trying that
<mdke> smurfix, sorry for being thick, but its asking for a password. Shouldn't it be asking for the key passphrase?
<smurfix> if it finds / knows about the private key
<smurfix> where did you store that?
<infinity> mdz : Yes, I'm on it.
<Kamion> quickest way to debug that is generally to try with ssh -vvv
<mdke> smurfix, ~/.ssh/ubuntu-it_dsa
<Kamion> are you using ssh -i ~/.ssh/ubuntu-it_dsa ?
<mdke> Kamion, trying, thanks
<Kamion> you can configure that in .ssh/config
<Kamion> so:
<Kamion> Host ubuntu-it
<Kamion>         HostName actual.name.of.host
<Kamion>         IdentityFile ubuntu-it_dsa
<mdke> Kamion, awesome the -i option worked, will sort config now, thanks a lot!
<smurfix> there's no(t much) need for a separate private key however -- I'd just move it to .ssh/id_dsa[.pub] 
<mdke> smurfix, sorry for noobness, i can just use mv?
<smurfix> sure. I assume you don't actually have a .ssh/id_dsa file yet
<Kamion> actually IdentityFile needs an absolute path, I think
<Kamion> but anyway
<mdke> Kamion, i'll check the docs
<smurfix> Will you need a mysql database?
<mdke> smurfix, yes for the forum i think. I will ask the forum guys
<mdke> smurfix, actually I have an id_dsa but I can scrap it and use the new one
<smurfix> if you don't actually use it for anything, sure
<mdke> i use it for logging into a machine on my local network, but i will replace it will the new one
<mdke> smurfix, the other thing was, we'd be interested in finding out what it takes to become an official locoteam
<smurfix> mdke: commitment, basically. Let me look at your entry
<smurfix> mdke: thought so ;-) you still don't have a team contact person. Fix it and show up at the next Community Council meeting
<mdke> yes we decided on a contact only yesterday
<smurfix> mdke: So add a wiki page ;-)
<mdke> the wiki page is there, its ItalianTeam
<Mez> how do i make a new page in the wiki?
<mdke> its linked at LoCoTeamList, should it be linked elsewhere?
<mdke> Mez, make a link then click on it, then click on "create page"
<Mez> ah :D
<mdke> Mez, there are some good docs if you click on Help or go to HelpContents
<Mez> nah I just ahvent mad a new one yet :d
<Mez> I've come across the "not found page" loadsa times never noticed the "create this page"
<mdke> ;)
<Mez> godamn this is taking ages
<mdke> i can help if you like
<mdke> wassup?
<Mez> who would have thought uplaoding acroread would tak ethis long
<Mez> no ... I'm trying to upload acroread to backports
<Mez> it's just taking foreVER
<Mez> well t would
<Mez> it's 38 meg
<Mez> o_O @ the Ubuntu Foundation thing
<nomed> hi all
<nomed> in debian there is a file pmount.allow
<nomed> is there something like that in hoary 
<uniq> you can create it yourself.
<nomed> uniq, i solved now adduser nomed disk
<nomed> but is that file still needed in this way
<Kamion> pmount in Debian comes from Ubuntu
<nomed> umm... well Error: device /dev/hda3 is not removable
<nomed> Kamion, i know .. but how to pmount not removable devices 
<nomed> adduser nomed disk ... still not working
<Kamion> ogra: you followed up to ubuntu-users@ rather than sounder@
<thom> nomed: user support questions in #ubuntu, please
<ogra> Kamion, oh, sorry :)
<ogra> i'll regard it next time....
<fabbione> Kamion: sorry to be repetitive, did you see my message (above) about p-a-l ? can we start to include it for testing?=
<fabbione> (i didn't see any answer )
<nomed> thom, ok but  they seems to don't know .. i would just know if pmount.allow file is used by pmount
<Kamion> 11:21 < Kamion> fabbione: that's entirely controlled by its priority - just bump that to standard and it'll be used
<Kamion> 11:21 < Kamion> fabbione: shall I do that?
<Kamion> fabbione: ^--
<fabbione> ops
<fabbione> i missed that .. sorry
<fabbione> is an upload enough?
<fabbione> or do we need to edit the override?
<Kamion> no upload needed
<fabbione> ok..
<fabbione> i can't edit the overrides
<fabbione> so there isn't much of a choise :)
<fabbione> sure go ahead.. it needs testing
<Kamion> I: Will change priority from optional to standard
<Kamion> done
<fabbione> thanks
<fabbione> Kamion: last thing.. we should look together 2 minutes to InstallerVolumeManagement specs in regards of the UI
<fabbione> you tell me when you have time....
<Kamion> sure - I'll have to look at what's there now first
<fabbione> even monday would be fine...
<fabbione> ah cool
<fabbione> sure
<Kamion> ooh, d-i upstream gets raid/lilo fixes
<Kamion> daniels: do you have a fix pending for #12205?
<seb128> elmo: gnome-games-extra-data sync please
<fabbione> Kamion: i am heading to bed.. i am not feeling too good.. sorry.. can you add comments to the specs if you have any?
<Kamion> sure
<fabbione> thanks
<hunger_>  /dev/input/mice went missing today.
<Mez> Failed to fetch http://security.ubuntu.com/ubuntu/dists/hoary-security/restricted/binary-i386/Packages.gz  This HTTP server has broken range support [IP: 82.211.81.151 80] 
<Mez> broken range support?
<jbailey> hunger_: Current breezy?
<hunger_> jbailey: Yeap.
* jbailey checks
<hunger_> jbailey: I updated udev today, maybe that is the culprit.
<jbailey> I did a udev update last night.
<hunger_> jbailey: Did you reboot?
<jbailey> Hmm, I have /dev/input/mice here.
<jbailey> hunger_: Yes. =)
<hunger_> jbailey: Damn:-(
<chrissturm> hunger, do you run the .12 kernel? the udev releasenotes said that it only works well with the .12 kernel
<hunger> jbailey: I got mouse0 and mouse1, so something is working.
<hunger> chrissturm: I am on breezy... that has a .12 kernel:-)
<jbailey> chrissturm: It works best with .12, It should work with everything from .10 on.
<hunger> chrissturm: 2.6.12-3-686.
<jbailey> hunger: Gimme a sec.
<jbailey> hunger: Can you hop into /sys/class/input ?
<chrissturm> hunger, i run breezy with .10 because wep is broken for ipw2100 on .12
<jbailey> Is there a directory there called "mice"?
<jbailey> chrissturm: If the next update of udev is allowed (It might be to allow boot-time speedups) it will require 2.6.12
<jbailey> It's going into Debian this weekend, so we might wind up inheriting it.
<hunger> jbailey: Yeap. Contains a file called dev with the device numbers.
<jbailey> Did you plug in your mouse after the computer was running, or was it always plugged in?
<jbailey> (Checking to see if we missed an event, or if coldplugging missed it for you)
<hunger> jbailey: The touchpad/stick is build into the laptop.
<hunger> jbailey: And both mouse0 and mouse1 are there. it is just mice that is missing.
<jbailey> Right, but I don't know the input layer that well - I don't know if the creation of 'mice' is a separate event, I assume it is.
<jbailey> Have you reboooted more than once to see if its a transient problem?
<hunger> jbailey: Possible... but since sysfs has mice udev should have created it.
<hunger> jbailey: I booted twice.
<jbailey> Cool, so it's reproducable. 
<torkel> chrissturm: fabbione built a new kernel yesterday with ip2x00 fixed. It is not uploaded, but you can fetch it from http://people.ubuntu.com/~fabbione/linux-image-2.6.12-3-686_2.6.12-3.4_i386.deb if you want to try it
<Mez> fecking great
<jbailey> If you run 'udevstart' as root, does it create it now?
<Mez> my paypal account's been locked
<jbailey> Mez: It's what happens when you ignore the emails that they get telling you to update your account ;P
* jbailey hides.
<hunger> jbailey: Yes, that creates it.
<Mez> jbailey: I updated it, even though i had to update if by fone.
<Mez> bastards
<hunger> torkel: Do you happen to know whether that contains the fixes for tpm as well?
<chrissturm> thanks torkel
<Mez> sorry for my language
<jbailey> hunger: Hmm.  Lemme do a test here.  I suspect there's still just an event that's being missed somewhere.
<jbailey> hunger: Will you be online for a bit?
<hunger> damn... those static device numbers were so easy to use.
<Lathiat> assumedly mousedev is actually loaded?
<hunger> jbailey: Yeap.
<hunger> Lathiat: mousedev and psmouse are loaded (psmouse is in /etc/modules)
<Lathiat> Mez: hahahaha
<Lathiat> Mez: how mjuch money is in it? ;p
<Mez> *Shrugs* I've no idea
<Lathiat> nothing substatial then?
<hunger> Lathiat: it did work till yesterday. I did not change anything (I think:-)
<torkel> hunger: probably not. It was just a quick build to solve the ipw2x00 problems
<hunger> torkel: Well, I can always build my own kernel with the fixes I need. If only I weren't so damn lazy:-)
<torkel> hunger: or you can file a bug and he will probably get to it sooner or later :-)
<hunger> torkel: I did, I even attached the necessary fix.
<Mez> doubtful lathiat.
<lool> w00t, I wonder whether debootstrap / pbuilder can cross-debootstrap breezy from sid
<lool> I failed with sid's, and breezy's debootstrap+pbuilder
<torkel> hunger: then you just have to sit back and wait :-)
<lool> /usr/bin/apt-get: error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
<hunger> torkel: unfortunately that is somewhat big and changes the ABI somewhat. So fabbione said he must test it and might not be able to include it at this time at all.
<Lathiat> hunger: include what?
<lool> (this was possible for warty, and hoary)
<Mez> oh my god: the thing says to contact them by email - then it tells you in the autpo-respond to go use a fecking web form! GRR@ PAYPAL
<hunger> Lathiat: The patch I grabbed from the TPM module CVS to fix detection of said chip in thinkpads and some other devices.
<Lathiat> ah
<Lathiat> what is that?
<hunger> Lathiat: Trusted Platform Module. Crypto thingy build into new devices.
<Lathiat> ah
<Lathiat> whats it do?
<hunger> Lathiat: The basis for TCPA/Paladium.
<Lathiat> isnt that that evil stuff?
<hunger> Lathiat: Basically it provides a secure key storage.
<hunger> Lathiat: TPM provides a secure storage for keys... building on that you can do evil stuff.
<Lathiat> how is it different to a crypto disk?
<hunger> Lathiat: It does not encrypt the disk:-)
<Mez>  What is Error 3018?
<Mez>  If you receive a Error 3018 message when attempting to access your PayPal account, it may have been frozen due to information submitted that is believed to be inaccurate.
<Mez> GRR
<Lathiat> i mean like, if i had a crypted disk and threw my keys on that, how is it different
<hunger> Lathiat: seriously: TPM is more like a smartcard: It stores keys only.
<Lathiat> and what, you need some kind of passphrase to unlock it?
<hunger> Lathiat: Yeap.
<jbailey> hunger: 'kay, I'm firing up my laptop to test this.  It might be that my main system mouse is usb so is seen different.
<Lathiat> so could i stuck my ssh key in there?
<hunger> Lathiat: And the proper chip... or you can bind the key to a certain configuration (like BIOS version, etc.)
<hunger> Lathiat: You can not get to the keys outside the TPM module... you might transfer them, but they can not exist in a decrypted state outside of the chip.
<Lathiat> hunger: oh so you send data to the tpm module and it decrypts it fo ryou?
<Lathiat> hunger: so it literally is like a smartcard
<hunger> Lathiat: Yes, it can do that. But only small chunks (like other keys) and it does so slowly.
<Lathiat> right
<Lathiat> so what the hell is the point of that? :)
<hunger> Lathiat: Smartcard + configuration registers.
<Lathiat> just an inbuilt smartcard i guess
<hunger> Lathiat: configuration registers are used to examine the state of the computer (basically hashes of BIOS, bootrecord, etc.).
<hunger> Lathiat: So the bootloader can check that the device wasn't tampered with.... and cause the TPM to check other files like the kernel, etc which in turn could check the modules, ...
<hunger> Lathiat: The infrastructure is not there with linux yet of course.
<Lathiat> right
<Lathiat> so what can you do with it now?
<hunger> Lathiat: Store keys. Nothing a smartcard can't do.
<Lathiat> right
<Lathiat> can i use it with ssh and its smartcard type stuff?
<hunger> Lathiat: Not yet.
<Lathiat> so basically
<Lathiat> in theory
<Lathiat> i could authorize this laptop to ssh somewhere
<Lathiat> if not tampered with
<Lathiat> if you took the disk, it wouldnt work
<hunger> Lathiat: in theory you could allow this laptop (provided it was not tampered with) to ssh in all other untampered computers in your company.
<hunger> Lathiat: There is a remote assestation protocol which allows to figure out that a device is untempered with remotely.
<Lathiat> ah, interesting
<Lathiat> bah
<hunger> Lathiat: The whole concept is to allow for "secure" distribution of stuff.
<Lathiat> mjy laptop broke
<Lathiat> i blame network manager
<Lathiat> is ate my dns
* Lathiat reboots
* hunger does not use network manager as he does not understand it.
* hunger is stupid.
<Kamion> the basic idea of TPM is not that bad; it's just a shame that the actual protocols are dreadful designed-by-committee things
<hunger> Kamion: The actuall TPM related stuff is actually rather well thought out.
<Kamion> the core specification is hundreds of pages long, and you have to read more multi-hundred-page specifications to get to anything useful
<jdthood> Lathiat: What's the problem (more precisely)?
<Kamion> hunger: I've studied all the specifications in a previous life at a crypto company; I respectfully disagree
<hunger> Kamion: No idea how the higher levels of the TSS look like though.
<Kamion> hunger: I *think* it's sound, but it's so overdesigned that it's very difficult to tell, which is a poor property for a security-critical protocol to possess
<Kamion> it could have been much simpler and provided the same level of security with more useful features
<Kamion> (basic crypto ops)
<hunger> Kamion: I studied them as well and rather liked them. But I am not a security expert, so my oppinion does not count.
<hunger> Kamion: Plus I read the CORBA security service spec, so I might just be used to worse stuff;-)
<Kamion> quite possibly ...
<Kamion> CORBA was design-by-committee too
<Kamion> though I don't know it nearly as well
<hunger> Kamion: Sure... but I think they were afraid of not being allowed to export the chip. So everything that is actually useful had to be moved off-chip.
<hunger> Kamion: CORBA is bad... but its security service is way worse than the rest.
<Kamion> er I don't see how that applies, they already have plenty of basic crypto ops in there
<Kamion> and a sufficiency of algorithms. I'm just talking about making the available methods more orthogonal and easier to use without creating barmy container structures and such
<hunger> Kamion: Only for very limited amounts of data and extremly slow.
<Kamion> sure, but the design means you aren't supposed to use them for bulk ciphering
<Kamion> so that doesn't matter much
<jbailey> hunger: Hmm, I can't reproduce on my laptop here either.
<hunger> jbailey: Too bad.
<hunger> jbailey: How could I debug this?
<elmo> lamont/infinity/pitti: ?
<jbailey> hunger: Still thinking on that way.
<jbailey> s/way/one/
<seb128> daniels: around?
<jbailey> hunger: What's the second mouse on your system?
<hunger> jbailey: mouse0 is the touchpad, mouse1 the stick thingy IBM insists on having.
<Kamion> fabbione: oh, I think new upstream kernel-wedge indeed fixes the exit code lossage; it was being lost in the first part of a pipeline, it seems
<jbailey> hunger: Can you check the output "cat /proc/sys/kernel/hotplug" please?
<hunger> jbailey: the usual /sbin/udevsend
<jbailey> hunger: I'm just tracking through to see if there's any chance that the hotplug handler wasn't set when udevstart got called so something might have gotten missed.
<jbailey> hunger: I think I'll need to find a way of logging the hotplug events at startup and compare you system to a known working one.
<hunger> jbailey: udev is not really logging all that much:-(
<lamont> elmo: sup?
<seb128> elmo: gdesklets sync please
<HWolf> seb128, got a bit of time? I thought up an idea, and want to hear how stupid it sounds.
<seb128> HWolf: sure
<infinity> elmo : ?
<HWolf> seb128, I read that discussion going on about all the applets and the UI discussion that followed from that on gnome-hackers, and that made me wonder if it'd be an idea to ship a sort of bug-buddy like system, but put it in the UI at least during development versions. This would be a button that the user could press if he encountered something that seems awkward to him, in the interface or when something doesn't behave as expected by the use
<HWolf> r. 
<jdub> HWolf: the "wtf" button
<ogra> ui-bugbuddy ?
<HWolf> something like that
<HWolf> Something that's handy every time you get annoyed by something. - press the button, it then asks you to click on the offending program/menu/button, traces it, and allows you to give a comment about why it is annoying, didn't behave as expected, or bugs you.
<seb128> HWolf: http://udu.wiki.ubuntu.com/LaunchpadIntegration ?
<ogra> yes, sounds like that... 
<HWolf> save for the fact that that handles translation, and bugs. - expand it to allow people to tell us why the interface isn't optimal.
<seb128> ?
<seb128> how is that different of a bug?
<HWolf> Because the user doesn't see it as a bug. They encounter something weird, and next time, just work around it.
<HWolf> Every OS has it's little weird things, but the user takes note, and adjusts his behavior.
<tseng> so if they want to report it, they use the same bug tracker as everyone else
<seb128> bug != crasher
<tseng> and attach a screenshot
<seb128> you can bug about and UI issue
<seb128> s/and/an/
<HWolf> I know, but it's an extra hurdle. and for the casual user, he's not interested in 'bug' - he's interested in the annoyance factor, that it doesn't do *exactly* as he likes it.
<doko> elmo: please sync python-imaging, linda, java-gcj-compat from unstable
<seb128> he doesn't know that's a "bug"
<seb128> he describes an issue
<doko> seb128: when starting the gnome session, then I get the message that the panel was started twice
<seb128> doko: known, bugged on bugzilla.ubuntu and upstream
<HWolf> Right, and while the backend can be identical, you'll have to start it off with "this annoys me" and not "file a bug"
<HWolf> seb128 ^
<seb128> that's just a title ...
<seb128> you want to discuss for hours just for a title?
<HWolf> No, I want to go off, and play a game, and go out tonight. :)
<seb128> I agree that the bug sending stuff should use "send a bug" title if that's what you are arguing
<seb128> s/should/should not/
<HWolf> But it's not just a title, it's an approach. Make it easier, remove bumps, allow the user to tell you what annoys him rather than file a bug in the traditional sense.
<seb128> grrrr
<seb128> you get a window "describe your issue"
<seb128> what's wrong with that?
<HWolf> Nothing much, but it'd probably be more userfriendly to pop up a window with a radio button list, and start off with "this annoys me" - "this doesn't work" - "this doesn't work as expected" and ask for input/action accordingly.
<HWolf> This is the last I'll say of it tho, just think about it.
<Treenaks> HWolf: people will lie on that
<Treenaks> HWolf: and things person A likes, person B will hate
<seb128> Treenaks: no need to think about it, what you describe is an UI to send a "bug"
<seb128> up
<seb128> s/Treenaks/HWolf
<HWolf> anyhow, night.
<Hieronymus> Treenaks: how do you mean, they would lie about it?
<doko> carlos: oo loc ping
<HWolf> And, Treenaks, lying wouldn't matter, because it'd still serve to tell you about what fires people up, just by the amount of reports.
<Treenaks> Hieronymus: People don't know what they like. They THINK they like one thing, but once they have it they'll say they like the old thing better
<HWolf> seb128, true, to a certain extent, but I don't see someone filing a bug about the name of the system menu, or it's layout. And if they do, they're powerusers or devels, not john does.
* HWolf is off
<Hieronymus> Treenaks: so we should stop them from filing bugs? Makes no sense
<carlos> doko, pong
<carlos> doko, sorry, I was really busy with some bugs
* Kamion wonders how to test kernel-wedge nowadays without building the entire kernel
* carlos goes to answer that email before he forgets it....
<Treenaks> Hieronymus: no, we should not ask for a judgement of value
<doko> carlos: thanks
<Hieronymus> but we could ask what doesn't work as expected etc.
<Treenaks> Hieronymus: everybody expects different things, that's the point
<Treenaks> Hieronymus: I prefer spatial, you don't. I prefer few options, you prefer KDE
<Hieronymus> I don't prefer kde :)
<Treenaks> Hieronymus: just an example
<Hieronymus> but I mean things like a button "close application" in app y, while the rest of ubuntu uses "close", that is not expected
<Hieronymus> and it's a bug
<Treenaks> random users dont' know that
<Hieronymus> but if they *do* they should have something easy in the menu to report it
<hunger> Outch... up to 5 years support for ubuntu 6.04. That is a *long* time to fix stuff!
<Lathiat> bags not me
<Kamion> incentive to make 6.04 really good ;-)
<wasabi_> Oh geeze.
<wasabi_> That is a long time.
* wasabi_ stares at Eclipse
<Hieronymus> they'd better test it heavily then
<Lathiat> i hear redhat have some contracts for 10+
<Hieronymus> well, Breezy Badger is 'breezy', fresh, so 6.04 should be stable seahorse or something
<Treenaks> Lathiat: I guess you could do that on a per-customer basis
<Treenaks> Hieronymus: Sinkin' Seahorse?
<Hieronymus> Hieronymus: :)
<Treenaks> Hieronymus: talking to yourself again? :P
<Treenaks> no, 6.04 should just be called "Woody Revisited"
<Lathiat> no
<Lathiat> woody didnt have an option to upgrade
<Treenaks> Lathiat: no?
<Lathiat> but i guess essentially
<Hieronymus> 5 years is like longer than Debian
<Lathiat> yeh but debain is still supporting woody till may 06
<Lathiat> which brings it about on par
<Hieronymus> 2011 :/
<ogra> Hieronymus, whats wrong with 5 years of support 
<ogra> ?
<Hieronymus> nothing, it's just really long
<Hieronymus> and probably very expensive
<Treenaks> ogra: it's more than 1/3 of his current life ;)
<lu|away> s/probably// :)
<Treenaks> ogra: even XP hasn't existed for that long
<ogra> but it will also gain a lot...
<Treenaks> Hieronymus: large companies love long support
<Treenaks> Hieronymus: as upgrading costs money
<Treenaks> Hieronymus: and needs to be tested thoroughly
<Hieronymus> Treenaks: I know
<Treenaks> Hieronymus: and they can test more often with the intermediate released (that will go on), and then switch when the next "designated release" rolls around
<Treenaks> so everyone wins :)
<ogra> Hieronymus, you wont get at the enterprise level if you dont offer such support cycles, so its good .... we dont use our 6 months release cycles with it... its only gaining us something... :)
<ogra> s/use/loose/
<Hieronymus> ogra: I read the announcement
<ogra> so whats wrong with it, let mark spend his money for it if he likes ;) 
<Hieronymus> ogra: It's an investment
<ogra> and in the end he will get contracts with big companys who pay the foundation :)
<Hieronymus> he can cash in if/when ubuntu becomes the standard os
<dieman> heh
<dieman> i need to find out what other .edu's use ubuntu
<Treenaks> dieman: or make them
<dieman> heh
<ogra> dieman, www.edubuntu.org ;)
<dieman> well, we're more of a good whitepaper in the end :)
<Hieronymus> ogra: why would they? It seems more logical that big companies get support from Canonical and pay them for it, and that Canonical pays the foundation to ensure companies 5 years of support which makes more businesses buy support from Canonical -> more money to the foundation etc etc.
<dieman> I ment edu as in universities/colleges :)
<Treenaks> Hieronymus: Canonical is not the only support organisation
<Treenaks> Hieronymus: You could start your own
<Treenaks> Hieronymus: if you wanted
<Hieronymus> Treenaks: but the main support organisation
<dieman> I am my own ubuntu support organisation. :)
<Treenaks> Hieronymus: for now... they might not be in say, 10 years
<dieman> along with a few student workers
<Hieronymus> which helps other organisations (If I understand the website correctly)
<ogra> Hieronymus, but still, the money will flow back...
<dieman> ogra: edbuntu is cool for turnkey
<ogra> ;)
<dieman> ogra: but in the university environment usually its integration
<dieman> making it painless for solaris/irix/etc users to use it
<dieman> and integrating with nis/afs/kerberos/etc.
<ogra> dieman, its only our first release, we'll get there ;)
<dieman> its different goals :)
<dieman> heh
<ogra> its a far goal
<dieman> automating 'site' configuration is hard.
<jdub> dieman: tried cfengine?
<dieman> (missed ldap in that list)
<dieman> jdub: yea
<ogra> the near goals are to start from a classroom.... conquer the school and in the end support the whole district... over 3 releases
<dieman> i use it for running scripts and doing some file edits and copies.
<dieman> its grouping engine rocks when used alongside a netgroup map
<ogra> dieman, so our fourth or fifth release could target the university enterprise level then :)
<dieman>         debian3xconsole = ( +@debian3 -gibson.cs.umn.edu )
<dieman> like that sort of stuff rocks
<dieman> well, im not at the 'enterprise' lever.
<dieman> level
<ogra> you just talked about it
<dieman> but still, for curricular labs and the research boxes its all about making it work with existing infrastructure because its usually already there.
<dieman> ahh.
<dieman> when people say 'enterprise' here its talking about peoplesoft. :)
<doko> fabbione: how far did the last OOo2 build get on sparc?
<dieman> and the budget stuff
<ogra> university environment is enterprise in my eyes
<dieman> and payroll
<dieman> and the central email server
<hunger_> This damn 2.6.12 kernel is so damn crashy!
<fabbione> doko: it was FTBFS but i didn't really dig into it.. want the logs?
<ogra> when i say enterprise, i mean 100+ servers and 10000+ workstations....
<doko> fabbione: yes, for -ubuntu2
<ogra> thats what big unis have, dont they ? 
<fabbione> doko: in a second..
<doko> fabbione: no haste
<fabbione> doko: it's people.. usual place
<doko> fabbione: k, thanks
<jbailey> ogra: I'd set enterprise starting at 25 servers and 100 desktops on the small side.
<fabbione> doko: thanks to you
<ogra> jbailey, yes, i sometimes tend to small exaggerations ;)
<jbailey> ogra: Right.
<jbailey> ogra: Although..  If you're willing to take up sales, you're welcome to take on that market. ;)
<ogra> *gg*
<ogra> sadly i dont look god with a tie ;)
<Mez> ogra, what do you think of maybe packaging Enemy Territory ?
<ogra> Mez, how free is that ?
<Mez> free as in free beer
<ogra> <-- not a gamer at all
<Mez> I think
* Mez goes and checks what licence it's under
<Hieronymus> Mez: free as in beer, yes
<Hieronymus> source is available but not free
<Mez> huh?
<Mez> It is free ;)
<Mez> ET is a full free multiplayer first person shooter game. The game was originally going to be a retail expansion pack for Return To Castle Wolfenstein but the project was cancelled and the good folks at Activision decided to give it to us for free!
<Hieronymus> they mean beer
<Mez> ??????
<ogra> no costs...
<ogra> but that doesnt rule the distributability
<Hieronymus> a long, long, time ago, I used to play that game
<Mez> they're godamn run files
<Hieronymus> there's an EULA included
<carlos> doko, mail sent
<tseng> ogra: its not distributable
<tseng> ogra: iirc
<ogra> tseng, i thought so
<tseng> not that i would mind a secret .deb installer on some random website outside the US
* tseng shuts up
<ogra> heh
* Mez looks around some stuff
<doko> carlos: we still do have the 220 pot files. is this a problem?
<carlos> doko, Rosetta will not be too user friendly with 220 pot files
<carlos> doko, is it a problem to collapse them into one single file?
<doko> carlos: I think, it doesn't make sense. it's getting too big. you maybe want to have different people be responsible for one app. I'll look how to split these at the first dir level
<carlos> doko, we have a plan to help people to contribute with huge .pot files
<carlos> doko, and we have already .pot files that are bigger than OOo2 one
<carlos> doko, https://launchpad.ubuntu.com/products/ddtp-ubuntu/05.10/+translations
<elmo> doko: linda violates UVF - is it a pre-UVF pending merge where debian took our changes?
<carlos> doko, we are not talking about 4-5 .pot files but 220 .pot files, that's too much
<doko> elmo: yes, I was too late. debian uploaded on June 23
<doko> carlos: no, toplevel are about 15
<carlos> doko, toplevel?
<doko> carlos: did you _look_ at the tarball?
<carlos> doko, yes, but not all subdirectories... let me check it again
<doko> carlos: from that page I can only see, how many are missing, not how much are available. OOo2 currently has 65.000
<doko> (including the help)
<carlos> hmm
<carlos> ok, then we are handling already 32000 (universe)
<doko> at least you should split out helpcontent2
<carlos> I don't know why I thought oo was smaller
<carlos> doko, if that's possible, that's ok
<carlos> doko, I mean, I don't mind if we have 2 or 4 .pot files
<carlos> but 220 ....
<carlos> it's too much
<doko> ok, but for doing a reasonable split, we have to do some manual work
<carlos> doko, so you propose to create one .pot file per toplevel directory?
<doko> yep, if you think that these are not too many files
<carlos> that's 36 .pot files
<doko> too many?
<carlos> it's a high number, but we could do some testing to import them and see how Rosetta looks with that amount of .pot files
<carlos> doko, isn't it a problem to get the translations back from several .po files using the 36 .po layout?
<doko> ok, let's see if we can reduce these as well. maybe it's a good idea to have a common dir, a helpcontent2 dir and for each of the apps (writer, calc, impress, base, ...) one
<doko> carlos: it's not a problem for the 220
<Ska> hi ppl
<carlos> doko, I know, I mean with the 36 file layout we are talking about now
<Ska> if someone is interested in vector graphics development , i've recently released my framework in c++ (take a look to www.amanith.org)
<doko> carlos: I didn't try. but a patch to oo2po and po2oo should be doable
<carlos> ok
<carlos> doko, I will play a bit with OO.org2 this weekend 
<wasabi_> Man I still never received my hoary cds
<carlos> wasabi, did you ask Mako?
<wasabi_> No. Didn't know I was supposed to
<carlos> wasabi, well, he's on charge of cds distribution
<carlos> and he's behind the contact email you have at the website
<mdke> wasabi_, i haven't got em yet, those of us who had warty cds have to wait a bit!
<carlos> mdke, there were an error in our order
<carlos> mdke,but Mako told me that it's fixed now (I had the same problem)
<mdke> :)
<lamont> dpkg: error processing /home/buildd/build-breezy/chroot-breezy/var/cache/apt/archives/gettext_0.14.5-1ubuntu1_hppa.deb (--unpack):
<lamont>  trying to overwrite `/usr/share/info/dir.gz', which is also in package gzip
<lamont> what was the fix for that again, I wonder?
<Kamion> fabbione: colin.watson@canonical.com--2005/kernel-wedge--ubuntu--0, testing would be good
<bddebian> Hello
<jsgotangco> hi
<mdke> jsgotangco!
<jsgotangco> hello
<sivang> hi all
* sivang is waiting for his breezy to dist-upgrade
* Mez giggles
<Mez> enjoy the breakage
<sivang> Mez: what brakage are we talking about ? :-)
<Mez> I avent tried it myself, but X breaks a lot :D
<Mez> apparently
<sivang> ouch
<sivang> Mez: well, all sorts of stuff broke for me, but thinkg "killall gnome-*" cannot fix
<sivang> s/thinkg/nothing/
<Mez> lol
<Mez> or a restart of X
<sivang> Mez: yep
<sivang> Mez: I'm a bit outdated with current stuff and poeple on Ubuntu, may I ask if you're a user/developer/moving from other distro?
<sivang> Mez: (I now have a day job which consumes too much of my time :-)
<Mez> sivang a bit of all :D
<Mez> lol
<Mez> I've just bcome a member... on my way to maintainer :D
<Mez> https://wiki.ubuntu.com/MartinMeredith
<sivang> hey mdz , 'sup?
<Mez> hey mr Ubuntu CTO :D
<Mez> :P
<sivang> Mez: strange, mdz usually has some sort of a cable provider hostname, unless he's out of the US
<Kamion> .fi might be a clue ;-)
<sivang> Mez: (one that is common around his region, adelphia or somethign)
<sivang> Kamion: debconf ?
<sivang> Kamion: Hello to you too , how are you ? ;-)
<Mez> yeah, mdz said he had to catch a plane when I was speaking to him earlier :D
<Mez> lol - Kamion - I finally got it to install
<Simira> hehe
<sivang> Mez: how early was it? (ooo we're getting OT )
<Kamion> sivang: fine, thanks
<Kamion> Mez: good-oh
<Mez> had to set my nameservers itself to the upstream ones instead of the local proxy/caching ones
<Mez> btu... it installe
<Mez> then I wiped it.
<Mez> I prefer ubuntu :D
<wasabi_> So if breezy is supported for 5 years.
<wasabi_> that means, we will have to support 10 releases at a time.
<Kamion> not breezy
<wasabi_> oh breezy+1
<wasabi_> i see
<Kamion> and not every release will be supported for 5 years, only selected ones
<wasabi_> ahh
<sivang> wasabi_: are you also part of the canonical crew now?  Seeing you talk as in "we will have to.." :-)
<wasabi_> no.
<sivang> wasabi_: eh, so that was more of, communal thinking :-)
<Kamion> the announcement said that *Ubuntu* would be supporting releases for five years
<wasabi_> yeah
<Kamion> it's not expected that that will be just Canonical
<Kamion> although obviously there'll be considerable involvement from Canonical employees / Foundation employees / whatever
<sivang> Kamion: right, since things that need to get done sometimes must be attended to by employees, and not rely on cummunity to take care of it
<jsgotangco> hey sivang
<sivang> hey jsgotangco , what are you doing here in this fine friday after noon?
<jsgotangco> oh its already saturday 1:11AM
<jsgotangco> heh
<jsgotangco> my laptop just died and they gave me a loaner
<jsgotangco> took me a while to have things running thoujgh
<{Seb}> i've just installed colony 2 on my ibook
<{Seb}> are all the i386 packages available for PowerPC
<mjg59> {Seb}: All of the ones that are tagged as building on ppc
<{Seb}> great
<{Seb}> i am correct in saying that AirPort exteme won't work>
<mjg59> Yes
<jsgotangco> yeah
<jsgotangco> oh well sleep time good night everyone
<{Seb}> btw, the new system tools in breezy are great
<{Seb}> the GRUB configurator, services manager are great
<{Seb}> will there be an Xorg configuration programme though?
<Hieronymus> {Seb}: yeah, cool huh :-)
<{Seb}> they are really good
<{Seb}> now those idoits on Linux Format have no reason to slag off Ubuntu
<Hieronymus> wow, I hadn't seen the services manager yet
<Hieronymus> {Seb}: that magazine.. it's sort of stupid
<Hieronymus> bought one once
<{Seb}> you need the latest breezy updates
<Hieronymus> {Seb}: I have it, just hadn't *noticed* it yet
<{Seb}> my mum knowing i like linux got me a subscription ;-)
<Hieronymus> haha
<{Seb}> has the nice KISS theory of ubuntu in it
<{Seb}> just hope they do an Xorg one
<Hieronymus> WOW!
* Hieronymus is exploring administration
<Hieronymus> Disk is cool :)
<Hieronymus> *disks
<Hieronymus> awesome
<{Seb}> they have certainly been listening to feedback
<Hieronymus> but it think My floppy drive (I don't have one) is /dev/hdd
<{Seb}> and the new places pain in nautilus
<Hieronymus> I haven't noticed anything in nautilus (but I use browser-mode)
<{Seb}> oh come on!
<{Seb}> i use browser mode
<{Seb}> in the pain down the left hand side
<{Seb}> the standard setting is now Places rather than Information
<{Seb}> it works like Mac OS X's Finder
<Hieronymus> {Seb}: oh, I always set it to info
<{Seb}> try Places
<netdur> people, I'm developing something to help ubuntu, but kinda I face problems... can I mail ubuntu-devel?
<ogra> sure, why not ?
<netdur> good :)
<sivang> ogra: hi !
<sivang> ogra: 'sup
<sivang> ogra: you have any clue about bonnobu ui by any chance?
<ogra> nope
<ogra> sorry 
<netdur> sivang, I heard that GNOME poeple moving away bonobo thing!!!
<sivang> netdur: that's true. THe intent is to move to use UIManager solely,
<sivang> netdur: but until this happens, we have to face apps that were written using other APIs..
<mdke> mako, ping?
<Simira> ogra: aren't you in HEL?
<ogra> Simira, i'm no DD ;)
<Mithrandir> ogra: so? :-)
<ogra> next time... currently i'm happy the traveling is done for some weeks :)
<ogra> i was every second weekend away since udu
<Simira> ogra: neither am I.... ;p
<Treenaks> Simira: you just tag along ;)
<Treenaks> I'm not in HEL either
<Simira> yay! I'm a groupie!
<ogra> hehe
* Treenaks will be in Berlin 03-09 - 06-09 though
<Mithrandir> Treenaks: why aren't you here? :-)
<Treenaks> anyone there who needs signing?
<Simira> Treenaks: the t-shirts have arrived, and will be out for sale after debconf
<Treenaks> Mithrandir: Budget constraints (i.e. I bought an EOS 350D + a crapload of addons)
<Treenaks> Simira: coolness
<Treenaks> woohoo
<Treenaks> working networkmanager \o
<Treenaks> \o/ even
<mako> mdke: yes
<siretart> does anyone know whats wrong with tdb-dev? bogofilter is tried to be build like crazy, but the build log says, that tdb-dev was not installable
<siretart> ah, I see: tdb-dev is in universe, but bogofilter is build-depending on it
<SuperLag> tseng: how goes it?
<tseng> SuperLag: good thanks
<SuperLag> long time no talk
<mdke> ah hi mako 
<mdke> mako, i was thinking, do you think there is any chance of getting http://people.ubuntu.com/~mako/docteam/ going again? we are desperate for a place to host previews and status reports of our work
<siretart> filed #12536 about this
<tseng> mdke: there are some virtual servers available
<tseng> mdke: i imagine it wouldnt be much trouble to allocate one to docteam
<mdke> tseng, we have been waiting for one, but i understand they are not available yet. This would be a temporary solution before we get a linode server
<tseng> mdke: i can help you with "temporary"
<mdke> one of the kubuntu devs provided some space for the kubuntu docs, but the ubuntu docs don't have any
<tseng> mdke: just for team use?
<mdke> tseng, yes purely for some html status and preview pages
<mdke> tseng, that would be wonderful
<mdke> mako, tseng has set me up :D
<mako> mdke: killer
<Speedy2> Hey all.  I'm seeing a strange problem -- I compiled myself a 2.6.12-2 kernel (from kernel.org), added support for my NIC and that works.  But for some reason, eth0 is no longer brought up on boot.  Any ideas which scripts I should check?
<Speedy2> Hot plug has been compiled into the kernel
<Speedy2> Any ideas?
<sivang> Simira: who else is on debconf? :-)
<Simira> sivang: everyone ;)
<sivang> Simira: I envy you guys ...how is the weather?
<Simira> sivang: warm and nice. Well, not everyone is here, yet. But I'm having a good time, so far.
<sivang> Simira: you there with tollef?
<Simira> sivang: yup. 
<subjectdenied> i have a problem with login into gnome
<subjectdenied> the gnome session doesn't start, but instead gives me a dialogbox showing "ihre" (german, should mean "your" in english) an only gives me a terminal
<subjectdenied> from there i'm able to start gnome by typing "gnome-session" into the terminal
<subjectdenied> i'm on breezy
<ivoks> wrong channel
<Speedy2> Realizing that many of the devels are busy or may not be here, can someone shed some light on the network bring-up process in Ubuntu?
<Simira> Speedy2: what is the problem? btw, there's a lot of wiki-pages on it.
<Speedy2> Simira: I compiled my own kernel (2.6.12-2), and added support for my NIC.  However on boot, the interface isn't brought up.  After logging in, if I type "ifup eth0", then all is normal
<ivoks> ok, that's trivial to fix
<ivoks> just add "auto eth0" to /etc/network/interfaces
<Speedy2> ivoks:  Any idea why this occured?
<Speedy2> ivoks:  And thank you for the suggestion, I'll add it
<ivoks> Speedy2: you were playing with netwok-admin
<ivoks> but -devel isn't a good place to discuss this
<Speedy2> ivoks: I didn't make any changes to network-admin
<Speedy2> ivoks: Ok, where should I discuss?
<ivoks> #ubuntu
<Speedy2> (I didn't knowingly make any changes to network-admin)
<ivoks> this is development chan
<tseng> mako: just got the hhk lite2
<tseng> mako: its pretty awesome, need to adjust a bit
<tseng> mako: to a few keys
<mako> tseng: awesome dude :)
<mako> tseng: i am traveling with mine here :)
<tseng> mako: i knew it was small, but wow
<tseng> do you have the one with the arrow keys?
<tseng> or the pro
<lu|away> do they make a cordless one yet?
<tseng> lu|away: heh :P
<tseng> im keeping my cordless mouse
<lu|away> well, seriously, I've got a box that I'd like to shove in a closet with only the monitor cable coming out
<lu|away> and a cordless hhk would be *perfect* for it
<tseng> hm true
<tseng> the xfce muine box?
<chrissturm> hmm automounting stopped working today for me. anyone else seeing this?
<lu|away> yeah
<lu|away> though no longer xfce
<lu|away> it's mostly pretty stock hoary now, with a simplified panel setup
#ubuntu-devel 2005-07-14
<lu|away> ATM it has a big-ass old MS natural keyboard
<lu|away> with a wire
<tseng> well
<tseng> i have a similar setup in my parents basement for mythtv
<tseng> i find that the normal "cordless" rf keyboards dont have a really great range
<tseng> sitting on the couch its hard to get a signal across
<tseng> if i had an unlimited budget id try ir, bluetooth etc
<lu|away> w00t
* lu|away didn't like having a browser anyway
<seb128> lu|away: gtk 2.7.2 announce
<chrissturm> wasabi, what would be the correct way to package eclipse plugins?
<chrissturm> damn
<chrissturm> tseng, bluetooth has a really wiiiideee range
<tseng> chrissturm: well, it can
<lu|away> seb128: yeah, couple of hours ago, I told you :)
<tseng> some stuff cuts out at 10m
<seb128> gtk?
<lu|away> yeah
<tseng> (by design)
<seb128> lu|away: is the ftp list b0rked or something?
<lu|away> oh, maybe
<seb128> I use it to know what to package
<lu|away> commits-list is borked
<seb128> and I don't get mails
<seb128> bah
<lu|away> I was looking at dtk-devel
<seb128> k
<lu|away> which had it 2 1/2 hours ago ;)
<seb128> anyway time to sleep
<seb128> I'll package it tomorrow
<lu|away> yeah
<lu|away> hopefully i'll just use it from CVS soon
<lu|away> night!
<seb128> thanks
<seb128> later
<chrissturm> does eclipse run with gcj or does it need a sun jdk?
<Speedy2> chrissturm: I think they make both versions
<Speedy2> chrissturm:  Some has compiled with Eclipse with gcj, but it may not be the latest version
<chrissturm> ok, but the version in breezy needs a sun jdk?
<Speedy2> chrissturm:  I think that is correct
<chrissturm> i would really like to package some eclipse plugins as debs
<whiprush> tseng: welcome to the hhk2 club!
<tseng> whiprush: woo
<siretart> chrissturm: the eclipse package in breezy is running with gcj
<chrissturm> siretart, how do i configure it to use gcj?
<siretart> chrissturm: just apt-get install it
<chrissturm> i have it installed, and running
<chrissturm> and in about / config i see that it used the sun jdk
<siretart> hm then you should ask wasabi about this. I don't know how to switch
<siretart> gn8
<chrissturm> thx
<chrissturm> ah /etc/jvm.d/eclipse
<sabdfl> hey lamont - just got back from beers with bdale :-)
<Mez> sabdfl, any news on backports?
<sabdfl> Mez: incoming
<Mez> ..?
<Mez> incoming?
<dmk> just asked this question in ubuntu-motu and no one answer - I think everyone is asleep. maybe you guys can help
<dmk> I have been trying to build a few deb packages but I am not sure if I have done them right
<sabdfl> thought we would have it this week, i guess it just needs a little love from infinity and lamont
<dmk> they install fine, but just wanted to be sure
<dmk> when I was doing packages for Slackware we used to have a script that verified everything
<Mez> ah fair enough... I'm just wondering how we're going to get the thing to build the packages thats all
<dmk> sorry if this is the wrong place to ask
<lamont> evening sabdfl
<Mez> I'm just not sure how the process would go if we're not making the source uploads (plus apparently the sbuild doesnt like ~'s in the version)
<Mez> lamont, hows backports going on your bit of it?
<lamont> backports is there, btw
<lamont> see archive.ubuntu.com/ubuntu/pool/main/d/dpkg
<Mez> I noticed the repository was there...
<lamont> having said that.  wanna-build needs a little bit more love, and then i think all should just be happy
<lamont> (I can't give things back, because wanna-build gets confused about that ~)
<sabdfl> hi lamont
<lamont> sabdfl: I'll hammer on wanna-build some more this evening, and then we should be good to go.  (all the buildd's are currently trying to build it, etc.)
<sabdfl> lamont: cool. how's the bandwidth holding up at home these days?
<lamont> sucky
<lamont> I've taken to freshening a USB drive at work from time to time, from the local mirror here in fort collins
<lamont> sabdfl: and otherwise, I'm running right around my quota for high-bw usage
<sabdfl> lamont: wimax?
<lamont> sabdfl: I get all I want if the average is < 56kbps.  for >= 56kbps, I get ~100MB/day
<lamont> max is around 400-500kbps
<lamont> which isn't terribly bad, given everything
<Speedy2> <ivoks> #ubuntu
<Speedy2> <Speedy2> (I didn't knowingly make any changes to network-admin)
<Speedy2> <ivoks> this is development chan
<Speedy2> err, sorry
<chrissturm> wasabi, are there instructions how to package eclipse plugins as debs for ubuntu?
* lamont scratches his head, noting that w-b is actually happy
<Mez> lol @ lamont
<wasabi_> chrissturm, no, but there needs to be
<wasabi_> I am trying to figure it out for CDT currently.
<chrissturm> wasabi, i would like to try webtools
<wasabi_> Please give it a go.
<chrissturm> webtools rock big time
<wasabi_> I really want to see it take off.
<wasabi_> I am making some big changes to Eclipse right now, which will probably effect you in the long term.
<chrissturm> does it work well with gcj? i am running eclipse with gcj for the first time today
<wasabi_> Does web tools? Don't know.
<wasabi_> Eclipse works for the most part. Debugging doesn't.
<wasabi_> But Eclipse launches an external VM to run.
<chrissturm> how does the performance compare?
<wasabi_> It's slower than Sun's, but better than interpreted.
<chrissturm> thats very good news for non intel platforms
<wasabi_> chrissturm, I am preparing to move Eclipse to /usr/lib/eclipse from /usr/sahre/eclipse.
<lamont> fabbione: somehow I expect you're not around?
<wasabi_> Most stuff will be in /usr/share, with symlinks in /usr/lib pointing to it.
<wasabi_> Basically it's the only way I can get FHS compatibility out of it.
<chrissturm> wasabi_, is there also a per-user plugin directory?
<wasabi_> chrissturm, there will be.
<wasabi_> chrissturm, RedHat has a nice patch for that I will be applying.
<chrissturm> eclipse had always supported that
<wasabi_> RedHat has some mods.
<wasabi_> bbl =)
<wasabi_> please help 
<Speedy2> Is there any benefit to putting eth0 in the "hotplug" interface on /etc/network/interfaces ?
<Speedy2> (why does Ubuntu do it that way?)
<lamont> Speedy2: lets you auto-up interfaces without always trying to bring them up (and failing when the PC card isn't plugged in)
<Speedy2> lamont: Ok .  For some odd reason, with my own kernel hotplug fails to bring eth0 up.  Does hotplug use hal ?
* lamont shrugs
<Speedy2> lamont: I'm using a PCI NIC.  The only thing I can think of is that PCI hotplug wasn't compiled in
* lamont hasn't played with that part of things much.. hal and dbus are both certainly involved in hardware detection/config
<chrissturm> how does that compare to network manager?
* lamont gets back to the paying job
<jasoncohen> where are breezy's packages stored after they are built by the automated build system but before they enter the pool directory? is their an incoming server like incoming.debian.org?
<jasoncohen> *is there
<jsgotangco> j #ubuntu-motu
<jsgotangco> salut
<tseng> hi jsgotangco 
<daniels> Kamion: yeah
* davyd wanders in
<davyd> daniels: does X work yet?
<daniels> davyd: of course it does
<davyd> mine stopped working with -34
<daniels> i810?
<davyd> i915
<daniels> will be fixed in -35
<davyd> daniels: what broke?
<davyd> also, how long till -35?
<tseng> davyd: when daniels blesses you with it
<davyd> tseng: well, this biatch left me without a working X server
<tseng> :/
<davyd> I also couldn't see how one would obviously downgrade X, I know it's meant to be modular, but there are things like xserver-common and x-common and such
<davyd> and I just don't know the dependancy tree
<lamont> "Ubuntu is calling it a 82845G/GL[Brookdale-G] /GE Chipset Integrated Graphics Device" - any clues daniels?
<lamont> (actually, iz driver on intel's site)
<daniels> lamont: i845, which uses the i810 driver
<daniels> davyd: code which made it start segfaulting in breezy
<daniels> davyd: downgrading xserver-xorg alone from -34 to -33 should be safe
<lamont> daniels: ah, ok.  should hoary correctly detect that, or does one have to force i810, and if so, how?
<davyd> daniels: ok... it seems that gdm doesn't correctly relay that there was a segv
<daniels> davyd: sounds about right
<davyd> that's why I was feeling confused
<daniels> lamont: um, hoary will detect and use it fine.  but is this a desktop where the resolution is capped at 640x480?
<davyd> also, startx didn't seem to work
<lamont> yes
<daniels> lamont: if so, XORG_SYNC_RANGES=yes sudo dpkg-reconfigure -phigh xserver-xorg
<daniels> will be fixed in a hoary-update
<lamont> daniels: thanks - that'll get my brother off my back... and then there's my _other_ question.....  but you know what that is.
<daniels> lamont: yeah, the answer to that is in your other IRC client
<daniels> i'm still trying to work out a way to plug in and meaningfully use my desktop
* lamont reads his other desktop, feels sympathy for daniels
<squinn> welcome back, mgalvin 
<mgalvin> :)
<mgalvin> had to restart gnome a few time after install new apps to refresh menus
<mgalvin> working on the gnome docs
<squinn> what gnome doc in particular?
* squinn moves conversation to #ubuntu-doc
<mgalvin> well, mostly the gnome faq guide, but i am modify the menu entities to reflect the breezy menus
* lamont --> home
<Mitario> hello everyone
<bddebian> Hello Mitario 
<Mitario> little question here.. i'm finishing update manager for a new release and since i'm not a native english speaker.. is it 'There are x  packages available for updating.'?
<bddebian> Sounds correct to me
<|QuaD-> anyone around?
<lamont> emacs21: error while loading shared libraries: libXaw3d.so.6: cannot open shared object file: No such file or directory
<lamont> hrmpf
<mgalvin> are direct upgrades from wary to breezy supported or at least possible?
<jasoncohen> mgalvin, it's recommended that you upgrade incrementally
<jasoncohen> mgalvin, each release has changes in dependencies (pacakges with new names, new dependencies, removal of old dependencies etc.). to resolve this, there are virtual dummy packages to aid in the upgrade process.
<jasoncohen> however, this is meant to work between releases - from warty to hoary- not from warty to breezy
<jasoncohen> anyways, breezy is in no shape to be used as a stable distribution. if you didn't want to upgrade to hoary, your surely not going to want to use breezy at this time. why not upgrade to hoary now and wait until breezy is released in october?
<mgalvin> jasoncohen, i ask b/c i am working on the ubuntu documentation, i was just wondered if it was possible and worth putting in the docs
<mgalvin> its not a good idea, i figured as much, but wanted other opinions
<jasoncohen> it'll probably lead to upgrade problems
<mgalvin> right
<mgalvin> it's just that people asks those kinds of questions :)
<rob^> been buisy mgalvin?
<rob^> busy^
<mgalvin> rob^, yea :)
<rob^> :)
<rob^> I've been trying to figure out lufs ftpfs all day..
<rob^> it wont mount my xbox
<rob^> :(
<mgalvin> i never tried that, no xbox
<rob^> I have about 45gig of mp3s on it I want to access from my pc
<bob2> why not just use a real network filesystem?
<rob^> without copying them across
<rob^> on the xbox?
<rob^> what like?
<bob2> ?
<bob2> smb, nfs, afs, coda ...
<rob^> the xbox has a smb server without running one of the various Linux distros for it?
<rob^> whats it called?
* seth_k is away: sleep
<rob^> pfft.. kernel module?
<bob2> you want to continue running windows on it? ah
<rob^> well..
<rob^> I want to be able to still play games on it
<rob^> it IS an xbox after all
<mdz> morning
<whiprush> mdz: far from home?
<daniels> so, while there are arguments over how to behave on, say, 5 minutes of idle time:
<daniels> a) do nothing
<daniels> b) throw up a screen saver
<daniels> c) blank the screen
<daniels> d) go into S3
<daniels> i think we can all agree that D is completely wrong
<davyd> daniels: yes, I think so too
<davyd> daniels: you could always do what the mac does
<daniels> screen saver after 5, S3 after 50?
<daniels> er, 60
<Mithrandir> daniels: on battery or in general?
<davyd> it also dulls the screen after 5 or so minutes
<daniels> Mithrandir: in general
<daniels> davyd: right, dimming the backlight is a top plan
<Mithrandir> daniels: I would be majorly pissed off if a machine I left off suddenly went to sleep for no apparent reason.
<daniels> Mithrandir: you too, hey?
<daniels> never mind the SSH session you had running, or the huge downloads you had going
<daniels> fascists
<davyd> daniels: some of the power management stuff in ubuntu is crack
<Mithrandir> so S3 after 60 minutes is just crackful.
<davyd> I rewrote a lot of mine today
<daniels> davyd: acpi-support?
<daniels> Mithrandir: it does that on desktops, dude
<davyd> daniels: yeah
<davyd> it might be worth considering acpi-support-ibm and acpi-support-toshiba
<davyd> and lots of that stuff
<daniels> davyd: file a bug :)
<daniels> mmm, we used to have acpi-support-x40
<daniels> then we realised everything in the x40 is fine
<davyd> because I have non-shit ACPI
<Mithrandir> daniels: uh.  So it crashes any desktop with SATA and other niceties like that?
<daniels> what we really need to do is have portable interfaces for 'dim the backlight', 'enable bluetooth', 'disable the wireless radio', et al
<davyd> all the workarounds break my machine
<daniels> and then have system-specific binaries, where we autodetect which one to use
<daniels> Mithrandir: dunno, this was in the 10.1 days
<daniels> haven't used OS X since
<davyd> daniels: sounds like a similar solution
<Mithrandir> daniels: oh, OS X.  I thought this was about what we were doing/going to do.
<davyd> daniels: I think you still can configure it to sleep
<daniels> Mithrandir: shit no
<davyd> from memory it doesn't with mounted external disks
<davyd> it's an interesting feature
<davyd> also, I only have one Squire left
<davyd> and I haven't managed to read chapters 2, 3 or 5 of the story
<davyd> I knew I should have bought a case
<ogami1972> HEY DEVELOPERS! thank you!
<daniels> sladen: any word on usplash?
<siretart> wasabi: ping
<sivang> bah, source only packages, anyone has any idea how I increment patch such package?
<daniels> what do you want to do?
<daniels> if you need a rebuild, just bump the version number and add 'no changes' or such to the changelog
<sivang> daniels: I need to patch it bits, and then test build
<sivang> daniels: where do I drop the diffs? :-)
<daniels> oh, you mean DBS?
<sivang> daniels: (I'm used to working with dpatch enabled packags)
<daniels> where you dpkg-source -x something, and it has a tarball in the root directory?
<daniels> fakeroot debian/rules setup is the generally-accepted way to unpack it, although source.make might be used intsead
<sivang> daniels: I think so...not sure :-)
<daniels> then put your patches in debian/patches
<sivang> daniels: it's gedit package, let me look again, I may be wrong wrt the source pkg thingy
<sivang> daniels: I have a /debian folder under the root, however it contains no "patches" dir
<daniels> sivang: might vary
<sivang> daniels: so that's not a source based pakcage? (the one with only the source tarball and a path tarball )
<sivang> s/path/patch/
<sivang> daniels: it's using cdbs, and simple-patchsys , but I can't see the pathces dir
<daniels> sivang: then it probably doesn't have any patches being applied
<sivang> daniels: oh, so it's a new upstream release maybe?
* sivang ponders the changlog
<sivang> weird, it has a -2 modifier, so it can't be new upstream
<daniels> maybe it just has no source patches?
<vedran> hello
<vedran> who is packager for icewm?
<sivang> daniels: right, only chnages to the debian portions. silly me
<vedran> i'd like to ask them something :)
<vedran> ah sorry - there's name in deb - ignore :o
<Duck_Happy> ogra: coin ?
<doko> ubuntu on www.spiegel.de: http://www.spiegel.de/netzwelt/technologie/0,1518,364354,00.html
<vedran> q: is it possible to do a network install of ubuntu?
<vedran> i have a computer with no cd...
<tseng> https://wiki.ubuntu.com/LocalNetInstall
<tseng> you can do it with netboot
<tseng> next time you want to ask #ubuntu, see topic.
<vedran> ok tnx... sorry
<JanC> you can do it from an existing linux install too
<JanC> read the ubuntu/debian installer manual
<JanC> apt-get install debian-installer-manual
<vedran> tnx to all
<zyga> is there any ubuntu-translators # ?
<mdke> zyga, there is a mailing list if that helps
<mdke> zyga, if your problem is launchpad related, you can try #launchpad
<mdke> or rosetta-users@lists
<zyga> I'm trying to import my gpg key
<zyga> but rosetta crashes
<mdke> zyga, that is not rosetta, its launchpad, you can file a bug or ask in #launchpad
<mdke> zyga, btw is your key on the keyservers?
<zyga> mdke: no ;)
<zyga> mdke: but It shouldn't have borked on me
<mdke> zyga, yeah i know, i think that is a known issue
<siretart> jbailey: ping
<Gandalfar> hello, can anyone hint me how to build ubuntu cdimage?
<zyga> Gandalfar: search the wiki AFAIR there is some info on this topic there
* HWolf grins. "ubuntu-driven conspiracies to kill debian" phrase found on planet debian
<Treenaks> HWolf: Oh noes!
<HWolf> nice, isn't it.
<Treenaks> ja :)
<Treenaks> uh.. wrong channel.. "yeah" :)
<mxpxpod> daniels: ping
<Kamion> Gandalfar: the scripts we use are in arch; http://people.ubuntu.com/~cjwatson/archives/colin.watson@canonical.com--2005, colin.watson@canonical.com--2005/cdimage--mainline--0; baz build-config configs/devel
<Gandalfar> thank you :)
<Kamion> Gandalfar: that's probably too brief for you to actually build images from, but I'm about to go out to a wedding
<Gandalfar> it's a start, creating a derivate will be a long term task anyway
<mxpxpod> Kamion: heh, I have a wedding this morning too :)
<mxpxpod> jdub: ping
<Mez> lamont: ping
<lamont> Mez: sup?
<Mez> PM
<lamont> PM?
<Mez>  /query :P
<Mez> wondering why http://people.ubuntu.com/~lamont/buildLogs/s/sdlperl/1.20.3-1ubuntu5/ is bombing out even though all dependencies are there
<siretart> there is something weird going on with gl and glu in xorg
<siretart> I dont get it either
<Treenaks> Let's all poke daniels to ask!
<siretart> is it possible/allowed to build depend on a virtual package?
<infinity> siretart : Yes, but if you want to be sure you get a specific version on the buildds, use "real | virtual"
<lamont> siretart: it's real simple... anything that build-depends xlibmesa-glu-dev is b0rked
<siretart> lamont: its about sdlperl, yes
<lamont> siretart: also note that if you build-dep on a virtual package, and it's not in the archive, then it requires a manual whack by infinity or I to clear the depwait...
<siretart> ok, will upload then a package build depending on libgl-dev-xorg and libglu-dev-xorg, then. ok?
<jdub> mxpxpod: pong
<lamont> well, given that libgl-dev-xorg doesn't seem to exist yet.....
<siretart> oh
<lamont> O
<siretart> :/
<lamont> I'd probably just use libglu-dev-xorg. :-)
<siretart> ok. testing that in pbuilder now
<lamont> daniels: updating the binaries line or such to make xlibmesa-glu-dev go away would be a good thing...
<mxpxpod> jdub: did gnome-gpg change? it used to be that I could call gnome-gpg and it would pop up a dialog asking me for a password... now it tells me it can't determine the key id to use
<jdub> no changes to gnome-gpg; perhaps you've added a key and aren't defining it? i don't know the answer.
<mxpxpod> jdub: not defining it?
<Treenaks> mxpxpod: usually it means that either you have no secret keys, or you have more than one
<mxpxpod> hmm
<siretart> ok. libglu-dev-xorg seems to work. uploading package now
<mxpxpod> Treenaks: aw man, something is messed up in my keyring
<mxpxpod> Treenaks: I get invalid packets
<jsgotangco> mxpxpod: probably your secret key
<mxpxpod> jsgotangco: what do you mean?
<mxpxpod> Treenaks: is there a way to rebuild my keyring?
<mdke> backup?
<Treenaks> mxpxpod: I have those too. I _think_ it's Alexander Schmehl and/or Andreas Mueller
<Treenaks> gpg: buffer shorter than subpacket
<Treenaks> gpg: signature packet without timestamp
<Treenaks> that stuff right?
<mxpxpod> no
<Treenaks> mxpxpod: then there's gpg --rebuild
<mxpxpod> gpg: checking the trustdb
<mxpxpod> gpg: [don't know] : invalid packet (ctb=00)
<mxpxpod> gpg: keyring_search failed: invalid packet
<mxpxpod> gpg: failed to rebuild keyring cache: invalid packet
<Treenaks> mxpxpod: but that's for rebuilding the signature caches
<Treenaks> mxpxpod: try #gnupg
<mxpxpod> Treenaks: ok, so why can't gnome-gpg determine the key to use?
<Treenaks> mxpxpod: can gnupg?
<mxpxpod> I think so
<mxpxpod> I don't get that message when using gpg
<Treenaks> then I don't know, as I don't use gnome-gpg
<mxpxpod> hrmm
<mxpxpod> Treenaks: yeah gpg finds my key just fine
<Treenaks> you fixed your ring?
<mxpxpod> yeah, there was a pubring.gpg~ that I copied into pubring.gpg
<Treenaks> ah ok
<mxpxpod> pubring.gpg was full of junk
<mxpxpod> oh, you know what...
<Treenaks> how did it get that way?
<mxpxpod> no clue
<mxpxpod> Treenaks: this is strange
<mxpxpod> jdub: it's strange... I have to specify --local-user now with gnome-gpg
* lamont considers filing a bug against oo.o2 saying it should be broken up into pieces that are only big enough to choke elephants
<Mithrandir> lamont: since elephants are easier to choke than lamonts?
<lamont> they have much bigger mouths
<lamont> 195812895 bytes of orig.tar.gz is a bit excessive
<lamont> and the 14741694 byte diff.gz doesn't really help matters....
<Mithrandir> oh, I'll need to put more stuff into ia32-libs, then?
<lamont> yeah - you're not even in the same ballpark there... :)
<lamont> 3 hours into the download, only 172e6 bytes to go. :-(
<lamont> but I have over 12% of the file
* lamont drops oo.o2 from his mirror
<davyd> who mirrors?
<davyd> isn't caching the cool new thing?
<lamont> not when you have to shape your bandwidth
<lamont> caching at 30kbps sucks.  mirroring a partial mirror doesn't suck quite so much
<lamont> that's kbits/sec
<wasabi> =( X move broke eclipse
<wasabi> Actually that was pretty damned weird. I was missing /usr/include/X11/X.h
<wasabi> But I *reinstalled* x11proto-core-dev and now I have it
<Jhair> running apt-get --purge remove python2.3 leaves two symbolic links which triggers:
<Jhair> dpkg - warning: while removing python2.3, directory `/usr/lib/python2.3/site-packages' not empty so not removed.
<Jhair> system: breezy
<Jhair> is this a bug?
* lamont goes off for the day
<Mithrandir> arrrr
<Mithrandir> evo crashes when trying to add a new (http) calendar.
<Nafallo> Mithrandir: evo crashes on LOTS of things ;-).
<Nafallo> Mithrandir: like trying to add another account ;-).
<Lathiat> yeh
<Lathiat> mutt++ :)
<Nafallo> hehe
<Mithrandir> Lathiat: mutt doesn't do ical feeds.
<Lathiat> ical sucsk
<Lathiat> ;p
<Mithrandir> Lathiat: got any better alternative?
<Mithrandir> why do people assume that I want to use evo as a mail client?  I have a way better mail client already.
<Lathiat> read it with vim
<Mithrandir> I don't use vim, 'cept once in a while to edit my .emacs. ;-P
<Mithrandir> and vim is really shitty about giving notfications of events and stuff. :-P
<Lathiat> your just not trying nhard enough
<thierry> when I start breezy that I installed, I get to the login and after gnome start, and all the panel are blank and I only see the wallpaper...
<thierry> is it that way with ebery computer or is it just mine?
<wasabi> just yours
<wasabi> today
<thierry> oh ok...
<wasabi> you're not going to get much help
<thierry> and with the live-cd, it doesn't recognize any ethernet device
<wasabi> what type of device do you have?
<thierry> wasabi, is there a way to fix thoses thing for a newbie like me?
<wasabi> thierry, no. WHy are you using breezy again?
<thierry> well I have a nvidia (inside my mother board) and an other with a strange company name but that works with hoary
<thierry> wasabi, I just was curious... I don't want support, I want to help
<wasabi> Well, the best I can tell you is that you need to figure out hte model of your nic, make sure the module loads and that it works right.
<wasabi> Then determine if the issue is with teh installer or the drivers. ;)
<wasabi> I don' thave any familiarity with the nvidia nics, so I can't be of much assistance with that
<thierry> ok... how can I make sure the module loads ? wich modules are needed?
<wasabi> Make sure that the module is listed in lsmod. I don't know what module
<thierry> k...
<thierry> thanks
<daniels> lamont: erm?
<Hieronymus> Why are the icons in Breezy for Firefox and Evolution different from those in Hoary?
<tseng> Hieronymus: because gnome-icon-theme includes new ones?
<Hieronymus> tseng: okay, but I thought there was an issue with the Firefox logo
<tseng> there is
<Hieronymus> it can only be used for official Mozilla releases
<Hieronymus> so, has Ubuntu gotten permission?
<tseng> go file a bug at bugzilla.gnome.org if you are concerned
<Hieronymus> tseng: I'm not concerned, but curious
<tseng> i told you where the icon came from, it was an intentional change by ubuntu
<hmh> I am going to start some groundlaying work for dependency-based initscripts here at debconf5. Anyone from ubuntu also working in this?
<hmh> (i.e. integrate stuff like serel/runit with the system)
<bronson> Why on earth is php4 compiled --without-pgsql?
<bronson> And since it is, why does Ubuntu include the apparently useless php4-pgsql package?
<bronson> Very, very strange.  This is on Hoary of course.
<KaiL> maybe there's php4-pgsql?
<Treenaks> bronson: sounds like a bug?
<KaiL> as there's php4-mysql afaik...
<bronson> KaiL: there is a php4-pgsql package.
<bronson> But it's useless because the Ubuntu php4 package disables all postgres support.
<bronson> Treenaks: I sure think so.  Should I file one?
<sivang> bronson: we should probably have php5 packages already...
<sivang> bronson: too bad it's delaying alot
<bronson> sivang: i agree.  :)
<infinity> bronson : Did you try installing php4-pgsql before reporting a bug?
<bronson> infinity: of course.
<bronson> infinity: I downloaded the php4 source package and verified that --without-pgsql is in debain/rules.
<infinity> bronson : It DOES work, despite the configure line.
<bronson> Really?  Not for me.
<bronson> phppgadmin complains that php has no pg support.
<infinity> bronson : Yes, it is in debian/rules.  All that means is that pgsql isn't built with the php4 source.
<infinity> bronson : Is pgsql.so in your php.ini?
<infinity> bronson : dpkg-reconfigure php4-pgsql
<bronson> infinity: that was it.
<bronson> Weird!  I just installed it.
<bronson> Dunno why it works after the reconfigure, but it does.
* bronson is off to mark his bug NOTABUG...
<bronson> infinity: thanks!
<infinity> I already closed it NOTABUG half an hour ago.
<bronson> Ah.  Thanks, Adam Conrad.  :)
<bronson> I added a quick note in case anyone else is stranded where i was.
<bronson> infinity: thanks again.
* infinity commits a patch to remove "Configure Command" from phpinfo to the packaging CVS for php4 and php5.
<comadreja> I'm looking for any of the members of the ubuntu/gnome team
<lu|away> comadreja: quite a few are around/in channel, if you have a specific question you should just ask and wait and see if anyone can answer
<comadreja> oh, thanks, I just thought there was a specific channel/mailling-list for them alone
<comadreja> bug 627, what is the dbus transition ?
<lu|away> probably refers to the transition from dbus 0.2x to dbus 0.3x
<lu|away> and I presume you mean some other bug #?
<comadreja> malone
<comadreja> it doesn't say too much more...
<lu|away> ah
<lu|away> presumably screem depends on dbus 0.2
<lu|away> and they want/need a patch to make screem build against dbus 0.3
<lu|away> though admittedly it is sort of hard to tell from the page that it is against screem
<comadreja> ok, I'll work on that
<thierry> I'd like to fix ubuntu bug 9145 . How do I get the source of rsync?
<carstenh_> apt-get source $package
<thierry> ok and to create a patch?
<carstenh_> apt-get install diff?
<thierry> k thanks
<ivoks> diff -ur
<comadreja> could it be that bug 627 talks about using dbus-glib instead of dbus ?
<ivoks> 627?
<comadreja> ivoks : in malone
<thierry> ok I have the rsync folder where I made my changes on the rsync packages... now how can I get the patch?
<ivoks> err...
<comadreja> thierry : I'm not at all the person to tell you, but I think you have to do an dpkg-buildpackage -S *.dsc and send the source package to revu 
<comadreja> thierry : what I mean is that I don't really know the procedure
<ivoks> thierry: #ubuntu-motu for revu
<thierry> ok but all I want is a patch to send on the ubuntu bugzilla
<ivoks> comadreja: 627 is screem
<ivoks> thierry: diff -ur new-source old-source
<comadreja> ivoks : yes, and screem uses libdbus-1
<thierry> k thanks
<thierry> and the old source is the orig.tar.gz file?
<ivoks> uh...
<comadreja> thierry : I think thats the upstream source
<ivoks> comadreja: i don't understand this bug at all :))
<thierry> k
<comadreja> ivoks : neither do I :). I just know that screem uses dbus
<comadreja> and that problably should be using dbus_glib
<comadreja> I thought that could be the transition...
<infinity> thierry : As rsync is in main, it'll need a main uploader to fix it anyway.
<infinity> thierry : And as the bug is a) very simple, and b) already assigned, you can assume it'll probably get fixed before breezy.
<infinity> thierry : (By the guy it's assigned to, even, which is me)
<cmatheson> hey we got a bunch of friends here and we're wanting to work on the ubuntu-express stuff... what work has been done already?
<ivoks> :)
<thierry> infinity : so I can forget it?
<thierry> infinity : or sending my patch would a good idea?
<infinity> thierry : It's a one-line patch, and the bug already has the fix in it (though not in patch format)
<infinity> thierry : Also, in the time it took you to ask me that, I fixed it and uploaded the fixed package.  And closed the bug.
<thierry> thanks :) anyway I've learned something!
<infinity> thierry : Learning is always good.
<thierry> yep
<infinity> thierry : The cleanest way to get your aptch, btw, would be to "dpkg-buildpackage -uc -us -S", then in .., you'll see you now have two source packages.  The old and new.
<infinity> thierry : debdiff *.dsc will give you a nice diff of the pair.
<thierry> cool
<ivoks> :))
<thierry> infinity : I'll try it on bug 11459, don't steal it this time ;)
<infinity> thierry : I didn't steal it, it was assigned to me. :)
<infinity> thierry : Try to pick bugs that are assigned to "debzilla@ubuntu.com"
<thierry> infinity : ho ok! yeah I'll try
<thierry> infinity : I don't have the debdiff command and sudo apt-get install debdiff doesn't work
<infinity> thierry : devscripts.
<thierry> infinity : thierry@modemcable050:~/dev/ubun$ debdiff irssi-text_0.8.9-1ubuntu3.dsc > 11459.patch
<thierry> debdiff: fatal error at line 205:
<thierry> Need exactly two deb files or changes files to compare
<seb128> hi
<seb128> is jdthood@yahoo.co.uk on IRC?
<infinity> thierry : debdiff old.dsc new.dsc
<infinity> thierry : Though the error message seems pretty self-explanatory there.
<thierry> infinity : ho! I didn't know I needed a .dsc before and after the changes! thanks
<lamont> daniels: ??
<infinity> thierry : Your new one would have overwritten the old if you didn't update the changelog before building.  You did update the changelog, right? :)
<infinity> thierry : (hint: "dch -i" in the source directory.  hint2: read the debian new maintainer's guide)
<seb128> is there somebody around with the sync from Debian magic? :)
* lamont wanders off again
<thierry> infinity : do I need to change the package version number? If so to what?
<seb128> is there any bugzilla master than can stop somebody to make changes?
<carstenh_> thierry: 23:49:10 < infinity> thierry : (hint: "dch -i" in the source directory.  hint2: 
<carstenh_>           read the debian new maintainer's guide)
<carstenh_> you should read hint 2 :)
#ubuntu-devel 2005-07-15
<thierry> thanks it worked fine my patch is posted now
<Mez> can someone tell me what wer the libglu changes?
<Mez> lamont explained ewarlier but I forgot
<tseng> so scroll up
<Mez> It was a while back and I've rebooted a few times
<Mez> pulling up logs and scanning is a pain in the ass
<tseng> 08:15 < lamont> I'd probably just use libglu-dev-xorg. :-)
<tseng> like this?
<Mez> yeah 
<tiglionabbit> hey guys, I have a user interface improvement to propose
<tiglionabbit> in synaptic, remove that checkbox that determines whether disabled repositories are shown or not, and make it always true.  It just makes things more confusing for people
<daniels> lamont: !!
* davyd pokes daniels with a stick
* daniels stares at davyd.
<davyd> daniels: where is xorg -35 ?
<daniels> davyd: it's with the beer you bought me
<daniels> hey, wait, you haven't bought me any beer ...
<davyd> heh, you haven't made it work yet ;)
* davyd wonders if there is an online beer ordering service based in Melbourne
<schweeb> feel free to send some beer my way too :)
<rob^> does anyone know what the release after breezy will be called?
<schweeb> don't think that's really decided upon until closer to the release of breezy
<schweeb> there is going to be grumpy, which is going to be a highly unstable branch, I believe
<tiglionabbit> Grumpy what?  Giraffe?
<rob^> ah ok. thanks.
<schweeb> groundhog
<tiglionabbit> hehe
<wasabi> So... when upgrading from one package version to another, how does dpkg handle it? Does it extract the new one on top of the old, or clean the old files out of the way first?
<infinity> wasabi : policy has a description of how unpack works, but essentially, the new package is unpacked, then any old files that exist in A but not B are removed.  This leads to some rather interesting effects, if you're tying to do crazy things.
<Saba_Z> whois Saba
<dholbach> hi
<Treenaks> hi dholbach 
<dholbach> does anybody know why wxwidgets2.5 packages show up on http://archive.ubuntu.com/ubuntu/pool/universe/w/wxwidgets2.5/ but are not accessible via apt?
<Treenaks> dholbach: when were they compiled?
<dholbach> argl: 29-Mar-2005 - that's hoary
<jsgotangco> dholbach!
<dholbach> hey jerome!
<jsgotangco> what are you doing this fine sunday morning on irc?
<dholbach> i was asking if somebody knew the state of wxwidgets
<dholbach> but i need to get back to some thesis hacking :)
<dholbach> (and dog walking)
<dholbach> how are you?
<jsgotangco> ahh
<jsgotangco> oh i finally got my laptop back and just finished rebuilding my system
<dholbach> you have it all working?
<jsgotangco> oh yeah good thing i made a backup last friday
<jsgotangco> other than that, i'm with daughter watching this crazy kiddie vcd we bought yesterday
<dholbach> hehe
<dholbach> sounds like you're having fun
<jsgotangco> its claymation
<jsgotangco> and it also has a Penguin for a character
<dholbach> *snigger* :)
<jsgotangco> its called "Pingu"
<jsgotangco> i even used it as my hostname heh
<dholbach> :)
<dholbach> *dog walking*
<jsgotangco> i'll brb as well
<tiglionabbit> I'm having a really weird problem with Totem
<siretart> does anyone know what could be the problem why NMU's in Debian are not autosync'd?
<tseng> nothing is being autosynced at this poing
<tseng> point
<siretart> tseng: the NMU was pre sarge, but has not shown up in breezy
<tseng> is there an ubuntu version?
<tseng> XubuntuY
<siretart> no, there isnt
<siretart> it's "wmaker"
<siretart> breezy has 0.91.0-7, debian sarge has 0.91.0-7.2
<daniels> tseng: hm, I thought mom was active
<tseng> beats me
<tseng> daniels: uvh was days ago, id imagine not
<siretart> according to http://changelog.debian.net/wmaker, I think we should import the debian version
<tseng> siretart: you need elmo, then
<siretart> ok
<tseng> and possibly freeze approval
<daniels> tseng: er, good point.  but it would've been active before then ...
<tseng> (thumbs up from mdz)
<daniels> well, mdz or kamion
<siretart> btw for bugfixing/merging, #12329 is about merges in package diveintopython, I had a look at it, no real changes necessary, package at http://siretart.tauware.de/revu/details.py?upid=97, if anyone cares to upload... ;)
<siretart> and, ah, diveintopython is main
<tiglionabbit> hey guys.  I have a very bizarre problem with totem, and I was wondering if any of you could help me sort it out
<tiglionabbit> or at least help me understand why this happens
<tiglionabbit> When I run totem, the video appears very bright and low quality.  Then, any media player I launch after that (gxine, xine-ui, mplayer, vlc) gets the same problem, until I kill my X session and log in again.  Firefox+mozilla-mplayer is not affected by this problem
<sivang> hey all
<siretart> hi sivang 
<sivang> hey siretart , I eventually succeded setting up my pbuilder
<siretart> sivang: cool! :)
<sivang> siretart: now to roll on with the xorg transaction, should I just attemp to install apps and see if they breaks to the lib change?
<siretart> sivang: I think this would be best.. ye
<siretart> s
<sivang> siretart: but a stupid question :-) how do I know which packages supposed to fail? 
<siretart> sivang: I not sure, either. I would try with dctrl-grep searching for packages build depending on the old mesa packages and then checking lamont's buildlogs
<tiglionabbit> can anyone figure out or explain to me what could be happening with totem?  Sorry to bother the devs with this..
<siretart> sivang: but lets move to #ubuntu-motu
<sivang> siretart: sure :-)
<dholbach> siretart: you won't need freeze approval for a universe package
<dholbach> hey tseng, daniels, sivang, siretart :)
<siretart> huhu dholbach 
<siretart> dholbach: perhaps you can help us out, do you know what should the build dependencies look like for opengl applications?
<dholbach> siretart: what's the build error message?
<siretart> dholbach: http://people.ubuntu.com/~lamont/buildLogs/b/bzflag/2.0.2.20050318ubuntu1/
<siretart> as an example
<siretart> it builds with build depending on libglu-dev-xorg, but this seems to me a bit too strict
<siretart> looking at other packages "xlibmesa-gl-dev | libgl-dev, libglu-dev-xorg | libglu-dev" seems to be a safe bet
<siretart> hi Mez 
<Mez> hey siretart
<siretart> Mez: I just tried frozen-bubble, it works without any rebuild
<Mez> does it /
<siretart> for me, in my breezy chroot
<Mez> must have just been what would have been a deopwait then
<dholbach> xlibmesa-gl-dev and xlibmesa-glu-dev are of different version and source packages - they conflict
<dholbach> at least that's what i see on first glance
<siretart> there seems to be quite a big confusion about these dependencies
<dholbach> siretart: try removing the gl crack, wait for the build error message and add a new build-depends based on that (missing headers or linking error) ;-)
<siretart> dholbach: I already uploaded sdlperl with only build depending on libglu-dev-xorg and no alternatives
<siretart> hi Kamion 
<dholbach> Mez: it was libsdl-perl - frozen-bubble didn't need a rebuild
<siretart> dholbach: this works, but I'm not sure if thats not too strict
<dholbach> i guess it depends on the package
<vedran> anyone care to help a packaging newbie :)
<dholbach> vedran: #ubuntu-motu is the place you want to be :)
<ogra> hey vedran
<vedran> ok tnx
<dholbach> hey ogra 
<ogra> hi dholbach 
<mpt> tiglionabbit: thanks for the synaptic suggestion
<mpt> siretart: does frozen-bubble have sound in Breezy?
<tiglionabbit> oo yay, thanks for reading that.  I said that ages ago though
<mpt> tiglionabbit: I'm slow.
<siretart> mpt: for me, yes. I tried it half an hour ago
<tiglionabbit> ages meaning 12 hours
<mpt> siretart: Awesome, that's the killer reason for me to upgrade
<tiglionabbit> anyway, can anyone help me understand why totem is screwing up my video players?
<ogra> mpt LOL
<tiglionabbit> frozen bubble has sound for me right now
<HiddenWolf> mpt, LOL
<siretart> mpt: I started it in a chroot, though!
* tiglionabbit wonders if he should wait another 12 hours for someone to talk to him about his totem problems
<tiglionabbit> would anyone like to hear about it?
<dholbach> tiglionabbit: why don't you write it to the mailing list? nobody here seems to have an idea
<tiglionabbit> I put something on the forums
<tiglionabbit> which mailing list?
<thom> anyone know how to make ant use gcj as the compiler?
<dholbach> thom: wasabi or doko will know for sure
<dholbach> tiglionabbit: ubuntu-users@lists.ubuntu.com
<thom> dholbach: nod; but wrong time for wasabi and i've not seen doko yet today
<dholbach> thom: jbailey maybe?
<ogra> thom, he's around occasionally... 
<ogra> (doko)
<thom> ogra: he's also at debconf; when i say "haven't seen him", i mean it literally ;-)
<dholbach> hehe
<Kamion> siretart: morning
<dholbach> Kamion: hi Colin
<Kamion> hey
<siretart> huhu
<rubenv> say, euh, are the daily cd images for breezy broken?
<rubenv> looks like only powerpc got generated
<Kamion> entirely possible, I'll look
<Kamion> it happens
<ogra> thom, heh
<Kamion> huh, it *looks* OK ...
<Kamion> oh, I know, I think two CD builds collided
<ogra> Kamion, vedran is working for us on the lightweight desktop side, he wants to make it possible to run a minimal ubuntu on pI 133/32MB, any chances for a lighweight installer that makes this possible ? 
<Kamion> ogra: more details required
<ogra> Kamion, up to vedran ;)
<Kamion> ogra: may be able to do lowmem tweaks, sure
<ogra> Kamion, i just wanted to get you two in connection....
<ogra> vedran, ?
<Kamion> 32MB isn't considered lowmem by Debian, but 2.4 is a bit lighter on memory consumption
<Kamion> I think I tried to get 32MB working on Ubuntu a while back and failed
<ogra> yes, but we dont ship 2.4
<Kamion> but I didn't spend much time on it
<Kamion> ogra: dude, I know that :)
<ogra> heh
<dholbach> :)
<Kamion> rubenv: I've kicked off a new build, thanks for the note
<Kamion> the live build before that spent overly long trying to fetch filesystem images
<Kamion> I'm shunting it back half an hour in the crontab
<rubenv> Kamion: great, thanks :-)
<ivoks> ubuntu works on 40MB, but it's not possible to install it
<Kamion> vedran: there are probably a few memory leaks in the installer that can be fixed to help with that
<vedran> Kamion: ok what do you suggest?
<Kamion> I spotted another one in cdebconf recently, I think
<vedran> I'm now trying to acquire a 32 MB machine to test
<Kamion> boot with mem=32M
<Kamion> or something along those lines ...
<vedran> ok...
<Lathiat> yeh thats right
<Lathiat> or use qemu or vmware
<Kamion> waste of time for installer testing IMHO, if you have a spare machine
<Kamion> if you don't have a spare machine, sure
<Kamion> vedran: have a poke about in the lowmem source package
<vedran> qemu might help us with memleaks, but i didn't work with it
<Kamion> cdebconf can be run on the host system, so you can use valgrind
<Lathiat> well, qemu is an easy way to test 32M
<Lathiat> is my point
<Kamion> there are only a few places in the installer where memory leaks matter, because there are only a few processes that run for long enough
<Kamion> Lathiat: I find it too painfully slow to work with; YMMV of course
<Lathiat> Kamion: right, i didnt find it overly painful
<Lathiat> Kamion: vmware is good
<Lathiat> Kamion: also qemu with the accelerator is nice
<Kamion> yeah, not really an option when one is on powerpc though ;)
<Lathiat> haha
<Kamion> I used to use vmware but don't use it any more on principle
<Kamion> I have enough real hardware that I don't need to ...
<vedran> Kamion: but what about pcs with no cdrom? (like the laptop i own)
<Kamion> vedran: netboot
<Kamion> or smart boot manager
<Kamion> or USB boot
<vedran> i was thinking more in line of: gzipped image of partition
<Kamion> ?
<ogra> initrd ? 
<vedran> with a first-time wizard
<Kamion> that's UbuntuExpress
<Kamion> but the live CD will not run on the kinds of hardware you're talking about
<Kamion> it's not a memory win
<vedran> yeah...
<vedran> perhaps its easier to fix the livecd
<Kamion> make GNOME run in 32MB? :-)
<Kamion> not easy
<vedran> ;)
<ogra> Kamion, lightweight desktop is the target ;)
<Kamion> ogra: please stop telling me things I already know :P
<vedran> we put icewm instead of gnome
<ogra> heh
<vedran> that is the easy part
<vedran> the hard part is unbreaking the system once installed ;)
<Kamion> unbreaking?
<vedran> well
<Kamion> oh, undoing live CD customisations you mean?
<vedran> yes
<Kamion> s'easy, UbuntuExpress does that
<Kamion> only a prototype as yet, but ...
<ivoks> bye all
<Kamion> I do think a traditional installer will be better for low-memory systems
<Kamion> it's just fundamentally running less stuff
<vedran> could we write a small shell script
<vedran> that just unpacks the ubuntuexpress iso image
<Kamion> since a live CD needs working space somewhere, it's either got to use memory, or it's got to use swap
<vedran> onto hard disk partition?
<Kamion> no
<Kamion> not maintainably anyway
<Lathiat> installing off a livecd is unclean anyway :)
<ogra> Lathiat, its the future
<Kamion> debootstrap is not the part that takes memory
<Kamion> the peak of memory use in the installer is during partitioning
<Kamion> (which suggests cdebconf improvements, since that's pretty UI-heavy)
<vedran> Kamion: "not maintainably anyway" - why do you think?
<Kamion> vedran: well, not in breezy timeframe
<vedran> with Knoppix it works :)
<vedran> the loopback file is just compressed image of hard disk
<Kamion> remember you have to do partitioning too
<Kamion> ah, so it works only on one type of computer ...
<vedran> nope - you get all the knopix hardware detection and stuff
<Kamion> consider powerpc
<vedran> basically like running the cd from your hard disk
<Kamion> the partition table layout is not even the same between different machines
<vedran> the installer should include qtparted
<Kamion> !
<Kamion> talk about memory use!
<vedran> ok then cfdisk :)
<Kamion> how about just the traditional installer?
<vedran> ok its definitely better
<Lathiat> really?
<vedran> but we need to hunt memleaks... which is the second most boring thing
<Kamion> I quite enjoy that kind of thing
<Kamion> just a matter of available time
<Lathiat> cant be that big a peak
<vedran> also: i once installed linux on a computer with nothing but floppy or serial port
<vedran> no cdrom no network
<vedran> s/or/and/
<Lathiat> need ssh mdoe over slip :)
<Lathiat> how do you start up that ssh mode?
<vedran> no it was much easier
<Kamion> mm, we have a problem at the moment because 2.6 is too fat to let us get enough stuff onto one floppy to know how to get more stuff off the next floppy
<vedran> there was a zip file that you unpack in C:/LINUX under windows
<vedran> and use loadlin.exe :)
<Kamion> being worked on upstream with initramfs
<Lathiat> heh
<vedran> well obviously not applicable to ubuntu, 
<vedran> but my proposed shell script would be easily portable to dos
<Lathiat> well, it can be
<vedran> Kamion: or to 2.4 kernel :)
<Kamion> we don't intend to support 2.4
<Kamion> we did consider it
<vedran> Kamion: no just boostrap installer from 2.4 then switch to 2.6
<dholbach> i'm away again... :/
<vedran> but i'm having wet dreams now so please stop me ;)
<Kamion> that would require supporting 2.4
<Kamion> and brings in very complex hardware detection issues
<Kamion> because devices have different modules, interface names, etc. in 2.4 vs. 2.6
<vedran> you're right...
<Kamion> vedran: (also, ubuntu-express is being written in python - to be maintainable, one would have to share code with it, and thus be in the same language)
<Lathiat> whats the model ubuntu express works in
<Lathiat> does it largely just copy the livecd contents to / ?
<Kamion> yes, plus tweaks; see the wiki design doc
<Lathiat> like i said, largely
<Kamion> http://udu.wiki.ubuntu.com/UbuntuExpress
<Lathiat> are we going to continue to have a normal installer?
<Kamion> yes
<ogra> yes
<Lathiat> good :)
<Kamion> http://udu.wiki.ubuntu.com/GraphicalInstaller
<ogra> Lathiat, but probably not shipped anymore
<ogra> i.e. only as iso download....
<Kamion> not shipped in shipit, you mean
<ogra> yep
<Kamion> I still regard it as "shipped"
<vedran> i've read some very convincing articles that all distros should switch to livecd
<rubenv> Can I request a resync on trac (universe)? The current breezy version is highly broken, but appears to be fixed in debian.
<vedran> as an installer
<Kamion> vedran: it's not feasible for big deployments
<rubenv> or should I send that to the mailing list?
<ogra> rubenv, we have a bug about it
<Kamion> those articles are just propaganda I'm afraid
<rubenv> ogra: great, i'll check it out
<ogra> rubenv, i'm waiting for elmo to finish his moving and show up again to request it...
<ogra> rubenv, so just be patient :)
<Kamion> I'm very unimpressed with articles that only consider one installation use case
<vedran> Kamion: yeah but it's cool to "try before buy" (repartition hard disk)
<rubenv> ogra: no problem, I have to deploy it tomorrow, but I could as well go with hoary
<Kamion> vedran: that's one case - now try deploying 2000 desktops armed with a bunch of live CDs, and watch the guy who's doing automatic installations over netboot get the job done in a tenth of the time and go down the pub :)
<Kamion> both are valuable
<Lathiat> hrm, im not sure "Computer Activity Logger" is the best description of syslog
<vedran> Kamion: knoppix has netboot with two clicks
<ogra> rubenv, you deploy breezy ?
<rubenv> ogra: on the development server
<ogra> ah, ok
<rubenv> no, I'm not completely braindead ;-)
<ogra> heh.... 
<Kamion> shipping a live CD's fine, using it by default even is fine, but the traditional installer won't go away
<vedran> Kamion: i'm with you on that one... i once tried netboot deployment of knoppix
<vedran> Kamion: 20 users lost their work because one cd was scratched :s
<Kamion> ah yes, that's where it was, confmodule_communicate() doesn't bother freeing 'in'
<Kamion> though I suppose that isn't a huge issue actually, oh well
<sivang> has anyone seen jamesh online lately?
<sivang> or, responsive for that matter :-)
<Treenaks> sivang: he made blog posts
<Nafallo> someone at debconf should film Mithrandir's speech :-)
<bob2> yes!
<dholbach> what is he going to talk about?
<ogra> stream it.... where is fluendo nowadays ?
<Nafallo> dholbach: multi-arch iirc :-)
<dholbach> ah :)
<davyd> is Matt Garrett around?
<davyd> I want to share complaints about ACPI with him
* ogra guesses he's at debconf
<davyd> good point
<ogra> davyd, but if you urgently need to share your experience, just shout at the channel ;)
<ogra> ...if that helps :)
<Treenaks> davyd: why not shout at postmaster@acpi.info ?
<dilinger> anyone know if fabbione's going to be around soon?
<\sh> hmmm..is anybody working with vmware on breezy?
<davyd> I need to buy a new license first
<\sh> i have a trial one first..if it's not running with breezy right now, I will forget it
<davyd> there is no reason it shouldn't work
<davyd> the application starts for me, I just don't have a license
<\sh> actually it is...compiling the modules for 2.6.12-3-i386
<\sh> with gcc-3.4 works fine
<davyd> yeah, the installer shell is quite useful
<davyd> all kernel things have to be built with gcc-3.4
<davyd> else they won't link into your running kernel
<\sh> yeah...but vmware is not starting, says it's not configured properly
<davyd> have you run the vmware-config perl script?
<\sh> 5 times now
<davyd> ok
<davyd> do the modules load?
<\sh> actually the drivers are loading and bridging failed
<\sh> and I can't sudo anything anymore :(
<\sh> and now I have to reboot again damn
<\sh> brb
<\sh> grmpf
<\sh> ok...vmware is not working as expected :(
<davyd> no?
<Treenaks> \sh: try qemu ;0
<Treenaks> ;)
<\sh> treenaks: I know qemu is working
<\sh> I just removed networking from the vmware-config stuff, and now it's starting
<\sh> *wonder*
<sivang> \sh: qemu has a new kernel module , so it's even faster now then in the past
<\sh> sivang: yeah...but I want to know if vmware is working...so I can order a license for the office
<sivang> \sh: I'm using it under hoary, works fine
<davyd> sivang: it works nicely on hoary
<davyd> err, \sh
<sivang> :-)
<davyd> \sh, it might be a 2.6.12 thing
<davyd> in which case, there might be an update in the works
<Lathiat> yeh its a 2.6.12 thing
<Lathiat> theres an update somewhere
<Lathiat> altho, the stock ones work for me
<Lathiat> i just had it do soe weird shit once
<Lathiat> rbeooted and worked ok
<sivang> Lathiat: I'm acutally having problem with 2.6.12 wrt LVM
<sivang> Lathiat: it can't find the lvm devices , for some reason
<sivang> Lathiat: any idea?
<Lathiat> haha that sucks
<Lathiat> nope
<sivang> Lathiat: so I revert each time to 2.6.10-5
<Treenaks> what should "md5sum -v" do?
<Treenaks> I have a package that doesn't build because my md5sum doesn't understand -v
<rubenv> be verbose?
<eruin> I think my 2.6.12 is having issues with hotplug/ipw2200
<Lathiat> works for me
<Lathiat> i heard some people had some issues tho
<Lathiat> it was being worked on
<Lathiat> have you updated recently?
<eruin> staying current every day
<eruin> my poor laptop just powers down at or rather just after hotplug gets started... havent gotten any further in debugging it
<Treenaks> rubenv: yes, well, my md5sum doesn't understand it
<Lathiat> ouch that sucks
<eruin> yeah
<eruin> good thing I had 2.6.10 around :)
<Treenaks> "Hey you hotplugged a power button.. you must have pressed it"
* Lathiat grins
<eruin> got any info on the update?
<Lathiat> nope
<eruin> I wonder where the run dialog went to
<Lathiat> eruin: alt+f2
<eruin> aaaah
<eruin> thanks ;)
<\sh> ah...found an update
<jsgotangco> salut
<cv> #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team 
<cv> #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team 
<cv> #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team #fazlamesai Turkish Linux Team 
<\sh> vmware is running ... just found the solution
<Lathiat> \sh: which was?
<tvo> what's the use of fam in ubuntu? since apt wants to remove kde and gnome and all graphical apps before installing it?
<\sh> Lathiat: http://knihovny.cvut.cz/ftp/pub/vmware/ there is vmware-any-any-update92
<Lathiat> \sh: ah yes,
<Lathiat> \sh: thats what i thought
<\sh> Lathiat: this helped for the network driver
<davyd> tvo: probably because fam conflicts with gamin
<davyd> and gnome-vfs and such depend on gamin
<davyd> just a guess
<\sh> and strange thing is...windows xp runs faster then a native install
<Lathiat> \sh: i found that
<Lathiat> \sh: i think its to do with disk caching
<tvo> davyd: yeah probably. for breezy, is gamin going to be used again?
<\sh> lathiat: I have my virt hd now on an usb2.0 hd...incredible :) and even fullscreen with 1024x768 is working out of the box with the vmware tools
<Lathiat> neat
<tvo> nm same api
<\sh> and now my upstream provider will kill me with the daily iso image download story ,-)
<Lathiat> whats that?
<bob2> rsync.
<\sh> ubuntu daily iso snapshots :) download, try to install, writing bugzilla notes
<HiddenWolf> who is in charge of irc / #ubuntu?
<Simira> the community council, or something?
<HiddenWolf> Simira, :(
* HiddenWolf wants that bot gone from #ubuntu
<Simira> HiddenWolf : which?
<HiddenWolf> uboto
<Simira> I think it's an official Ubuntu bot, why?
<HiddenWolf> Because, quite frankly, I find it disrespectful to newbs to serve their run-of-the-mill awnser with a bot.
<HiddenWolf> And I see it as the first step of the attitude that is now gripping #debian, and their RTFM-approach
<Simira> hm
<HiddenWolf> How much harder is it to write "please google for that" as opposed to "bot, tell $user of sudo"
<LinuxJones> Can someone please pop into #ubuntu and deal with dabaR, he's being rude && annoying
<HiddenWolf> If you piont them in the direction of a wiki, google, forum, mailing list, whatever, that is fine. But to not even acknowledge the person, and just have the awnser served by a bot, I'd say is distasteful
<HiddenWolf> Simira, do I have a piont, or not?
<jdub> HiddenWolf: we certainly haven't encouraged bots
<jdub> oddly enough, the owner is an aussie
<HiddenWolf> jdub, why is that odd? :)
<jdub> 'cos i tend to know the aussies who get involved
<HiddenWolf> ahuman01, right
* HiddenWolf wonders
<HiddenWolf> jdub, ah, right
<Lathiat> Bots however, are usefull
<Lathiat> because they can provide good responses
<HiddenWolf> Yeah, but at a cost.
<Lathiat> rather than $random person spewing up something
<Lathiat> and lots of people oftne go unanswered
<Lathiat> being helped by a unpersonal repsonse by a bot
<Lathiat> beats not being helped at all
<HiddenWolf> True, but being pionted to a wiki by a person beats a bot any time
<Lathiat> sure but that person has to keep a list of wiki links
<Lathiat> where that can be kept in a bot database
<Lathiat> i actually quite liked the #debian bots
<Lathiat> i could even ask it questions myself
* jdub shows off hardcore question answering skillz on #ubuntu
<HiddenWolf> Lathiat, I have no problem with a newb asking a question of the bot. I have a problem with people serving newbs with botted anwsers, because it is unfriendly
<Lathiat> i stopped joining #ubuntu cus three hours later im still there
<Lathiat> HiddenWolf: I disagree, because I think its more likely to result in more people getting helped with better answers
<Lathiat> you have a collectiction of knowledge, rather than 1 person
<Lathiat> if we had enogh people to help everyone
<Lathiat> who knew everything
<Lathiat> sure, it would be more friendly to help them personally
<Lathiat> but like, i dont have time to sit here looking up specific wiki urls all the time
<Lathiat> i just remember what i can
<HiddenWolf> While we're at it, why don't we have a bot send a /msg to every join in #ubuntu. "Hi, I'm the automated helping system, if your question goes unawnsered, maybe I can be of service"
<jdub> 'cos that's even more annoying that a bot in channel :)
* HiddenWolf grumbles
<HiddenWolf> ofcourse it is
<HiddenWolf> well, nm then.
<jdub> i tend to think the only polite way of having a bot on the channel is to call it something really obvious
<jdub> HelpBot
<jdub> :-)
<jdub> like
<HiddenWolf> yeah, and make sure it's response is civil
<Lathiat> yeh, that would help i guess
<HiddenWolf> Not $user wants to you to know: $bla
<HiddenWolf> if you can't tell, that debian bot always annoyed me.
<HiddenWolf> and the day i'll see something like "dpkg /topic /topic /topic /topic /topic /topic *READ IT*READ IT* /topic /topic /topic /topic /topic /topic /topic *a shaaame it's a shaaame that Leon_ didn't read the* /topic /topic /topic /topic..." in #ubuntu, I'll switch distro
<Lathiat> Thats nice
<HiddenWolf> that's the dpkg bot in #debian, fyi
<HiddenWolf> "* dpkg runs jeffro. over with a steamroller and shoves the corpse off the fire escape."
<Lathiat> HiddenWolf: yes, you see, thats the dpkg lart command
<HiddenWolf> if a bot could be a troll, that'd be it's role-model
<ivoks> guys...
<ivoks> problems in #ubuntu
<HiddenWolf> Someone ban that guy
<LinuxJones> argh jackk is a spammer
<HiddenWolf> LinuxJones, powerful observation, that
<wasabi> morning
<LinuxJones> HiddenWolf, thank you for that
<HiddenWolf> LinuxJones, my pleasure
<eruin> fabbione, can I get info on the upcoming kernel update I keep hearing about?
<eruin> scrool needs a ban in #ubuntu
<eruin> and fast
<eruin> and krall
<fabbione> eruin: uh what do you mean?
<fabbione> eruin: (about the kernel update)
<eruin> someone told me an update is imminent, and I was wondering what exactly is going to get updated (ie if anything related to my complete inablility to boot with it atm)
<eruin> I think mine might be related to hotplug or the ipw2200 module, though not at all certain
<trulux> bonjour
<Panzerboy> bonsoir :)
<pitti> Hi folks
<trulux> hey pitti 
<trulux> pitti: howya!!?
<pitti> trulux: had a nice long weekend in Prague, wonderful
<trulux> pitti: I'm ready for the bounty thing, going to prepare the proposal
<trulux> pitti: ah, Prague is a nice place.
<trulux> I'm just abck from France
<trulux> LSM 2005
<pitti> trulux: cool; I'll be at debconf5 the next week, I should be online fairly often
<trulux> what a nice event...
<trulux> pitti: ah, where's it?
<pitti> trulux: Helsinki
<trulux> pitti: nice place
<trulux> pitti: I didn't meet a lot of people at LSM 2005
<trulux> ;(
<mxpxpod> ok, for some reason, network-manager thinks my wlan-ng usb card is a wired connection... does anyone know why?
<mxpxpod> thom: ping
<monk> i think there may be a bug in kino
<monk> when i launch it, I get the following errors:
<monk> >>> Registering plugin /usr/lib/kino-gtk2/libkinoplus.so
<monk> >>> Image Filter: DV Titler 0.1.1
<monk> (kino:4260): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion `quark > 0' failed
<monk> (kino:4260): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion `quark > 0' failed
<monk> (kino:4260): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion `quark > 0' failed
<monk> (kino:4260): GLib-GObject-CRITICAL **: g_object_set_qdata_full: assertion `quark > 0' failed
<monk> >>> Image Filter: Color Hold
<monk> >>> Image Filter: Blur
<monk> i think the problem is with either the kino-dvdtitler package or the kinoplus package...
<monk> probably the former
<siretart> infinity: ping
<wasabi> This totem browser plugin is pissing me off
<wasabi> Last thing I want when I click on an AVI link is for it to open in a new browser window full screen and play. I want it to open totem. =/
#ubuntu-devel 2005-07-16
<eruin> wasabi, actually, the plugin wouldnt be that bad if you could actually do something with it
<eruin> like going fullscreen, saving the stream, etc
<wasabi> it more often than not locks up the browser
<wasabi> I just want totem to open.
<eruin> that hasn't happened here yet
<wasabi> No reason to do silly plugin stuff for a direct link
<eruin> that's true
<eruin> it's a lifesaver for my favourite webtv site though
<eruin> I can finally view it properly in linux ;)
<daniels> heh.  on a freshly-cleaned xorg tree:
<daniels> daniels@brainfreeze:~/canonical/xorg/xorg-6.8.2/debian% find ./ -type f | wc -l
<daniels> 817
<eruin> thank you thank you and thank you for adding rbox with cdburning in breezy :)
<syndicate> So is there an initiative or something for supporting Kerberos in all base packages?  As it stands now, most stuff is compiled without kerberos support (like ssh and mozilla)
<daniels> i don't know of any organised movement, no
<syndicate> It would be nice to have one
<wasabi> syndicate, feel free to start one. ;)
<wasabi> I'm all for that.
<dilinger> syndicate: would pam_krb5 suffice?
<wasabi> pam_krb5 misses the vast majority of hte point of kerberos.
<wasabi> It's not about auth... it's about passwordless auth.
<wasabi> pam_krb5 is just the door
<dilinger> ah, so you're talking about gssapi
<wasabi> Among other things.
<dilinger> i'd like to see pam support credential passing
<wasabi> Yeah.
<dilinger> for krb5 and ssh keys
<wasabi> But pam is sort of not really about that.
<dilinger> i know, but it could be
<wasabi> That's SASL.
<wasabi> me->away
<lamont> daniels: sup?
<daniels> lamont: got the library packages down pat, now just need to battle f**king xcursorgen
<lamont> woot
<daniels> and I think the xserver-xorg split is currently OK, too
<daniels> lamont: http://people.ubuntu.com/~daniels/xorg/changelog-35
<daniels> need to go to the supermarket, though.  1009, haven't eaten, and I'm ravenous.
<lamont> opuch
<lamont> ouch, even
<lamont> quite the changelog
<daniels> yeah
<daniels> it's pretty much the only version that's managed to balloon like that lately
<daniels> i'd forgotten just how much that sucked
<daniels> anyway, -> purchasing food
<syndicate> well, how do you start an intiative, create a spec or something on the wiki
<syndicate> I'd be happy to do so
<Megacid> hello folks
<Megacid> cjwatson is around sometimes ?
<lamont> Megacid: frequently
<Megacid> thks
<Megacid> he is my guru
<schweeb> Megacid: he goes by the nick Kamion on irc
<Megacid> thks for the info :)
<daniels> lamont: fwiw, -35 will also fix the tetex build loop
<lamont> awesome
<lamont> btw, how's lunch?
<daniels> breakfast is good :) lunch is in the oven
<bob2> more muphins?
* lamont wanders off for much of the evening
<daniels> bob2: muffins are PENDINGUPLOAD
<daniels> bob2: nachos are in the oven
<bob2> wtf
<bob2> nachos are microwave food, dude
<daniels> proper nachos are oven food
<tseng> yeah
<tseng> but oven is way too much work
<daniels> no way dude
<tseng> i drive down the road and let real mexicans cook it for me
<tseng> that way it doesnt suffer from my extreme whiteness
<tseng> or make me touch an oven
<schweeb> tseng: you are truly worthless as a mexican
<tseng> schweeb: so true.
<schweeb> make me some nachos anyways.
<jp> hi all
<jp> :)
<lamont> from the missing-depends department: /usr/include/php4/main/php_network.h:78:25: openssl/ssl.h: No such file or directory
<tseng> schweeb: if you inventory all the food in my apartment, we have a multitude of drinks, and some assorted popsicles
<tseng> schweeb: cooking is for suckers
<schweeb> hah
<schweeb> you are a sucker anyways
<schweeb> grilling is good.
<schweeb> no cleanup, and delicious food
<jp> tseng wtf with you, i'm professional chef :)
<tseng> grilling on the third floor doesnt work
<bob2> you could do it in a griller
<bob2> instead of on the 3rd floor
<schweeb> you're a sucker for moving in on the third floor, tseng
* schweeb shakes his head
<tseng> ill get you later schweeb 
<schweeb> :)
<daniels> tseng: cooking is rad
<jp> cool
<schweeb> whoever mentioned nachos gets a cookie
* schweeb just made a plate of heart attack super death nachos from hell
<thierry> hi, I'd like to help with ubuntu bug 8786 but I can't find the hal module in rosetta...
<thierry> https://launchpad.ubuntu.com/rosetta
<jp> servers are cool
<jp> hahahahah
<thierry> yeah
<mpt> thierry: What language is that?
<mpt> thierry: https://launchpad.ubuntu.com/distros/ubuntu/hoary/+sources/hal/+pots/review-hoary-hal-1/fr/+translate?offset=20
<mpt> (I found hal by finding "hal" on https://launchpad.ubuntu.com/distros/ubuntu/hoary/+translations)
<daniels> SHIT
<daniels> ah, phew
<daniels> my obscure scp-to-chinstrap-then-ftp upload method saved me
<fabbione> daniels:
<fabbione> pool/main/libx/libx11/libx11_6.2.1+cvs.20050711-1.dsc
<fabbione> pool/main/libx/libx11/libx11_6.2.1+cvs.20050711-1.tar.gz
<fabbione> native package?
<daniels> oh, for fuck's sake
<daniels> that's the second time I've done that today
<daniels> (*ahem*)
<daniels> isn't the new dpkg supposed to reject that?
<fabbione> it would have fail on your box if there was something wrong?
<daniels> well, it's not supposed to accept native version numbers with non-native packaging and vice-versa
<fabbione> it unpacked here fine
<fabbione> blame scott :)
* daniels stares at his tax.
<daniels> the first set of figures has me paying $8k, on top of what I've already paid.  second set has me getting $2k back.  third set has me paying $200k.
<daniels> er, $200, not $200k.
<fabbione> daniels: these are peanuts :)
<robitaille> personally I would take the 2nd option :)
<infinity> daniels : Time for some creative math.
<fabbione> hi infinity 
<infinity> daniels : I get money back, but I can't file until Zofia's slack-ass ex-employer send us her pay summary, so I can claim her as a dependant.
<infinity> fabbione : Morning.  Or afternoon.  Or whatever it is.
<fabbione> Inconsistency detected by ld.so: rtld.c: 1075: dl_main: Assertion `_rtld_local._dl_rtld_map.l_libname' failed!
<fabbione> does anybody have any idea of what that error message means?
<fabbione> (amd64 breezy chroot)
<infinity> Nope, but there's an open bug on glibc about that very message.
<fabbione> ok
<fabbione> this must be new... but i don't think it's glibc realted
<fabbione> there hasn't been a glibc update for a while
<fabbione> i think it's more gcc-3.4 related.. in any case it makes the kernel FTBFS
<infinity> Has there been a new binutils recently?
<infinity> I tend to blame all my deeply obscure toolchain bugs on binutils, until provne otherwise.
<fabbione> no idea...
<fabbione> can somebody kindly write an uppersend so that i can copy&paste ???
<fabbione> my X keyboard is somehow fucked...
<fabbione> daniels: we will have to look at it sometime soon
<infinity> I'd have to know what an "uppersend" was before I could type one for you...
<fabbione> the one you use in grep to match the first word
<fabbione> the opposite of $
<infinity> ^
<fabbione> (in a regexp)
<fabbione> thanks
<HrdwrBoB> a caret?
<daniels> fabbione: what's wrong with it?
<fabbione> daniels: i have lost a bunch of chard
<fabbione> chars
<fabbione> backspace doesn't work in less
<fabbione> i can't make the above char
<fabbione> tilde
<fabbione> if you can find a pic of a dk keyboard i can show you
<fabbione> otherwise gimme the time to take a pic of mine
<daniels> fabbione: are they accessed via alt-gr, or via shift?
<fabbione> that too
<fabbione> but not only
<daniels> http://en.wikipedia.org/wiki/Image:KeyboardLayout-Danish.png
<fabbione> daniels: ok.. let's start from the backspace
<fabbione> it works in xterm, but not less
<fabbione> and in another case i can't remember
<fabbione> the key immediatly on the left of backspace
<fabbione> the 2 apostroph don't work
<fabbione> pipe does
<daniels> ' and ` ?
<fabbione> ' <- this is on another key
<fabbione> ` <- this one and the opposite
<daniels> oh, so you actually have separate ` and  keys?
<daniels> right
<fabbione> right
<fabbione> down to the tilde key
<fabbione> none of the 3 symbols on it are available
<daniels> if you start up xev, what output does it give you for typing with those?
<Mithrandir> ^~  you mean?
<daniels> yeah
<fabbione> yup
<daniels> why is  on a separate key?  is it a dead key?
<fabbione> the rest of the keyboard seems ok
<fabbione> daniels: i really have no clue if it's a dead or alive key
<daniels> oh right, it is dead
* fabbione doesn't know anything about xkb
<daniels> fabbione: according to wikipedia, it's dead
<fabbione> ok
<daniels> so, you do u to get , f.e.
* fabbione prepares a funeral
<daniels> deadkeys are crack
<daniels> compose keys are the way of the future
<fabbione> well whatever :)
<fabbione> can you try to fix it please?
<fabbione> i don't mind at all to do testing
<daniels> i'll do what i can, but lacking more information or a danish keyboard ...
<daniels> would need to know what happens when you try typing with those into xev, for a start
<fabbione> daniels: sure.. hold on
<fabbione> daniels: any preferred way?
<daniels> /msg?
<fabbione> to grab the output of xev i mean
<fabbione> sure
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<Speedy2> Are either HAL or hotplug involved in the creation of IDE devices in /dev ?
* netjoined: irc.freenode.net -> kornbluth.freenode.net
<Treenaks> wb all :)
<fabbione> hey elmo
<fabbione> elmo: can you please dist-upgrade the following chroots? (concordia: breezy - breezy-i386 davis: breezy halley: breezy)
<fabbione> elmo: i need to get in the latest kernel-wedge to fix some udeb creation stuff
<elmo> fabbione: I can't do davis while you're building ...
<fabbione> elmo: ops.. will stop immediatly
<fabbione> elmo: done :)
<elmo> concordia/halley done - davis running
<fabbione> elmo: thanks :)
<elmo> fabbione: davis done too
<fabbione> elmo: rocking thanks
* fabbione needs to re-read all the maintainer scripts calls...
<fabbione> does anybody have handy the if [ $1.. line to call some stuff only on first install and reconfigure, but not upgrades?
<sivang> hey fabbione 
<fabbione> hi sivang 
<elmo> ogra: ?
<Treenaks> elmo: did you see my mail re: cannot upload ?
<elmo> Treenaks: not yet, I'm having trouble keeping up with my mail load without a server at home
<Treenaks> elmo: np
<daniels> fabbione: $1="configure" $2="", IIRC
<fabbione> daniels: yeah i figured to test it runtime.. it's faster :)
<Clint> elmo: you're missing madduck trolling
<ogra> elmo, whats wron ?
<ogra> g
<Mithrandir> ogra: elmo's afk atm.
<ogra> ah, ok
* ogra now sees elmo's mail
<fabbione> bah... brown paper bag upload
<fabbione> hey seb128
<lifeless> seb128_: jdub suggested you might like to package 'barter' - a baz python nautilus plugin
<seb128_> "plugin"?
<seb128_> hi fabbione 
<fabbione> seb128_: a very low priority task for you and only if you have time.. could you fix gnome-alsamixer in breezy?
<fabbione> (it's in universe and gcc-4.0 FTBFS)
<fabbione> (i think at least...)
<seb128_> fabbione: builds fine on i386, I'll have a look
<lifeless> seb128_: yes, it gives context menus in baz checkouts
<lifeless> seb128_: think 'tortoise svn for baz on nautilus'
<fabbione> seb128_: hm ok...
<fabbione> seb128_: it fails here tho...
<seb128_> lifeless: any webpage, pointer, ... ?
<doko> good morning
<fabbione> hi doko
<ogra> seb128_, google for apotheke
<lifeless> http://www.dur.ac.uk/j.r.c.geldart/projects/barter/
<ogra> we already had this for cvs
<seb128_> ogra: he's not speaking about apotheke
<seb128_> lifeless: thanks
<ogra> seb128_, but something similar....
<lifeless> ogra: check that web site out, screen shots n all ;)
<ogra> seb128_, apotheke was a cvs bonobo plugin afaik
<seb128_> ogra: and I asked for a page/name, not easy to package something without these informations
<seb128_> ogra: I don't care about apotheke :p
<highvoltage> anyone have elmo's e-mail address?
<ogra> seb128_, me neither :) i never did :)
<seb128_> so why do you keep speaking of it? :p
<ogra> seb128_, you sounded like you wanted to know about it *g*
<seb128_> ogra: read the discussion again maybe?
<ogra> seb128_, probably i had not enough coffee yet :)
<ogra> hmm, but barter looks cool
<dholbach> good morning
<dholbach> could it be that   http://people.ubuntu.com/~lamont/buildLogs/s/streamtuner/0.99.99-5ubuntu1/streamtuner_0.99.99-5ubuntu1_20050711-0950-amd64-failed.gz  comes from a hiccuping buildd?
<Mithrandir> is dpkg on utter crack for the time being?
<Mithrandir> dpkg-source: error: unrecognised file suffix `-0.tar'
<Mithrandir> internal error: error occured during execution of dpkg-source in /tmp/d8QniJ0EHx/source/nxcomp:
<Mithrandir> internal error: could not unpack package to desired level: Ingen slik fil eller filkatalog
<Mithrandir> (Ingen slik fil eller filkatalog = No such file or directory)
<dholbach> hi Mithrandir 
<Mithrandir> hiya daniel
<rob^> Mithrandir, what package did you try to install?
<dholbach> so you're moved now?
<tseng> rob^: dpkg-source
<daniels> Mithrandir: sounds like native packaging with a non-native version number
<rob^> weard
<Mithrandir> daniels: uhm, no?  But the upstream version is 1.4.0.2-31
<Mithrandir> rob^: none, it's dpkg-source.
<Mithrandir> dholbach: I'm in Finland now. :-)
<daniels> Mithrandir: so what file is it trying to unpack?
<rob^> yes
<Mithrandir> daniels: libxcomp0_1.4.0.2-31-0_i386.deb or the -dev package.
<dholbach> Mithrandir: hehe, but you moved already? how's life now? :)
<Mithrandir> dholbach: yeah, moved to Oslo now.  It's icky living in boxes, but we're surviving.
<daniels> Mithrandir: you're trying to dpkg-source a deb?
<jsgotangco> bye everyone
<jsgotangco> night time for me :)
<Mithrandir> daniels: no, I'm running debuild. :-P
<Mithrandir> dpkg-source -x /home/tfheen/external/nx/pkg-nx/nxcomp/nxcomp_1.4.0.2-31-0.dsc
<Mithrandir> dpkg-source: error: unrecognised file suffix `-0.tar'
<dholbach> Mithrandir: that's how life will be for me too in 6-7 weeks  :)
<Lathiat> Mithrandir: i didnt realise that you where tfheen
<Mithrandir> hm, yeah, native package.  That's wrong.
<Lathiat> heh
<fabbione> infinity: is there anybody working on the amd64 error i did past this morning?
<dholbach> fabbione: problems installing packages on it?
<dholbach> fabbione: (build-depends)
<fabbione> dholbach: no, the ld.so assertion failure
<fabbione> that brings to uninstallable pkgs too
<fabbione> but that's a consequence
<fabbione> not the root of the problem
<dholbach> ah ok... then make it two
* daniels uploads xorg 6.8.2-35.
<fabbione> daniels: what are you going to break today?
<Treenaks> daniels: does it fix stuff? :)
<daniels> fabbione: the WORLD.
<daniels> Treenaks: yeah, and hopefully breaks more stuff too
<Mirv> smurfix: i got two e-mails with subject:"Ubuntu Suomen keskustelualueet: SMF Database Error!" (ubuntu-fi forums).. do you think that's something to worry about?
<Treenaks> daniels: uhm.. like?
<daniels> Treenaks: lots of i810 goodness in there, now installs from scratch, more stuff modularised, no more build dependency loops, ...
* Lathiat hides from xorg
<daniels> Treenaks: http://people.ubuntu.com/~daniels/xorg/changelog-35
<daniels> it's a biggie :)
<Treenaks> ooooohhh
<Treenaks> display driver separation goo
<Lathiat> nice release name
<Mirv> smurfix: ok, I get connection timeout too so something is wrong, yes..
<Mirv> smurfix: and anyway, are there backups of the databases in case something goes wrong?
<daniels> lathi	thanks
<Lathiat> whats libice
<Kamion> Mithrandir: upgrade dpkg-dev?
<daniels> fwiw, the binary line is 2926 characters now
<Lathiat> and the b-d line?
<Lathiat> daniels: does this mean if i dist-upgrade from hoary it wont fuck up?
<daniels> Lathiat: i hope so
<daniels> Lathiat: b-d is actually shorter
<Lathiat> neat
<Lathiat> and more neatness
<daniels> Lathiat: a mere 1151 characters
<Lathiat> whough
<Lathiat> wasnt it like 4000 before? ;p
<Lathiat> also why no lbxproxy?
<Treenaks> wb
<daniels> Lathiat: because it's crap
<Lathiat> daniels: howso?
<daniels> Lathiat: nah, the xserver-xorg Depends line was about 4200 characters.  it's only around 3100 now.
<daniels> Lathiat: less performant in almost every situation (both with latency and throughput) than ssh, and definitely far less than nx
<Lathiat> righto
<Mithrandir> Kamion: ii  dpkg-dev       1.13.10        Package building tools for Debian
<Mithrandir> yay, now it complains about: dpkg-source: error: unrecognised file suffix `-0.diff'
* Mithrandir kicks dpkg
<fabbione> Kamion: https://bugzilla.ubuntu.com/show_bug.cgi?id=10189
<fabbione> Kamion: i think there is something wrong with modprobing in d-i
<fabbione> this bug is very similar to another one reported by Mithrandir 
<fabbione> in both cases d-i doesn't probe what's in drivers/messages/*
<fabbione> and both the drivers are hotplug "ok"
<fabbione> specially this bug.. i did talk with the submitter..
<Kamion> d-i isn't doing the probing, hotplug is
<Kamion> depmod's called at the beginning of each hardware detection run
<Kamion> so I'm generally puzzled
<fabbione> Kamion: after the hotplug run.. do we give enough time to udev to create the devices?
<Kamion> yes, hw-detect runs udevstart
<fabbione> the submitter told me on irc.. that once he installs with some manual tricks.. the generated initrd is ok
<fabbione> and contains the proper drivers that are loaded correctly
<fabbione> or at least it boots fine once installed
<fabbione> so the combination kernel <-> hotplug <-> udev seems fine
<fabbione> i am quite puzzled too tbh
<fabbione> but i can see from the generated modules.pcimap on an installed system.. that they are ok
<fabbione> in terms that the pci ids are exported properly
<Kamion> might be good to check modules.pcimap in the installer, right after the failure
<Kamion> *not* just after boot or whatever
<Mithrandir> Keybuk: could you please pull in tfheen@err.no--2005/dpkg--devel--1.13--patch-1 ?
<fabbione> Kamion: right.. anything else do you think i can ask him?
<fabbione> Kamion: we also have Mith with the same problem on his amd64 of death
<fabbione> so we have 2 people that can actually testy
<fabbione> Kamion: what priority is scsi-extra-modules ?
<Kamion> standard
<Kamion> both hoary and breezy
<fabbione> so it gets pulled in automatically... or it should at least
<Kamion> /var/log/syslog would be useful too
<fabbione> hey mdz
<maswan> fabbione: buttercup has gotten a powercycle now
<fabbione> maswan: cool!
<fabbione> thanks
<mdz> morning
<daniels> mdz: back home already?
<mdz> at debconf
<daniels> oh, right, i thought you were ircing from there
<fabbione> mdz: do you have 686 kernel on your laptop?
<mdz> daniels: I would be, but they filter outbound 6667
<mdz> fabbione: yes
<fabbione> mdz: i am preparing a fix for the tpm stuff.. mind to give it a test?
<mdz> 2.6.12-3-686
<fabbione> mdz: ok :)
<mdz> fabbione: the bandwidth is not so good on this wireless network, but if I can get it I will test
<daniels> mdz: sensible
<fabbione> mdz: ok.. uploading now to people...
<fabbione> mdz: linux-image-2.6.12-4-686_2.6.12-4.4_i386.deb <- on http://people.u.c/${tilde_thanks_to_fucked_dk_kbd_inX}fabbione/
<Kamion> fabbione: (%7e works)
<fabbione> Kamion: ehe ok :)
<Treenaks> hibye sivang
<Hieronymus> I think there's something wrong with the new OOo2 packages
<Hieronymus> which just came in
<Hieronymus> openoffice.org2-core: Depends: openoffice.org2-common (> 1.9.114) but 1.9.113-0ubuntu2 is installed
<Lathiat> yeh theres issues
<Hieronymus> forcing it gives dpkg issues
<syndicate> gnome-panel depends on libwnck16, but I have a libwnck17, is something being updated (amd64) 
<syndicate> i.e. ubuntu-desktop is broken
<trulux> anyone knows why transcode is not installable in Ubuntu Hoary?
<daniels> because marillat's repository doesn't work with hoary.  this is an #ubuntu question, and an faq.
<ogra> trulux, why should it ? we dont ship it
<trulux> daniels: sorry, just wondering
<trulux> ogra: because most users back-up their DVDs
<ogra> trulux, so complain at the guy who broke it ;)
<trulux> ogra: who's him? :)
<ogra> dunno, i dont use illegal software
<ogra> and use growisofs for dvd backups
<Lathiat> sif use transcode anyway
<Lathiat> gstreamer is where its at
<trulux> ogra: transcode illegal? I'm talking about private copies of DVDs I own, if someday I go out with my laptop, I won't take my DVDs box with all of them
<trulux> ogra: I won't share my private copy with no one else, that's the point where it's wither legal or illegal
<Lathiat> trulux: thats not legal everywhere
<Lathiat> but transcode has other uses
<trulux> well, knifes have many uses. I can cut my food with them or your head off
<trulux> right?
<trulux> ;)
<Lathiat> however, alot of the code for various codecs is dodgy
<trulux> you know, it's because such type of non sense excuses and reasons that some governments and concretely, certain commercial agencies, want to make private copies illegal
<trulux> and personal privacy, and P2P networks, and a long etc
<trulux> it's also because certain commercial agencies want to bring software patents to Europe...
<trulux> "becase open source has other uses"
<trulux> s/becase/because/
<Hieronymus> well, use free software then
<trulux> OK, better then: they argue "free software makes no benefit, it's viral and any one else can re-use your work with no warranty of copyright laws"
<trulux> just read, even if it's a painful thing, Steve Ballmer's interviews
<Lathiat> dude
<Lathiat> way off topic
<Lathiat> forge tit already
<trulux> well, you started it, I'm just following up and trying to bring some sense to the conversation
<trulux> no worries, if someone asks, I will try to prepare a transcode package for Hoary
<Lathiat> trulux: ubp has one
<trulux> Lathiat: ubp?
<Lathiat> backports
<Lathiat> in hoary-extras
<trulux> ah
<trulux> ok
<Lathiat> their evil, but the extras arent so evil
<trulux> thanks
<trulux> ;)
<Lathiat> now #ubuntu next time kthxbai
<trulux> great then
<trulux> sure, I apologize
<Lathiat> nps
<dholbach> syndicate: there'll be an updated package soon
<whiprush> morning dholbach, thx for fixing streamtuner. 
<dholbach> whiprush: hey! no problem - it's still "missing" on amd64, but that's a buildd problem
<daniels> bah, xorg ftbfs on powerpc.  two outta three ain't bad.
* daniels -> bed
<dholbach> see you later
<ogra> elmo, so what do you need additionally for squeak ?
<jbailey_> Does anyone have a *simple* testcase that shows off the amd64 bug at program start time?
<jbailey_> Reducing from python is a bit difficult...
<Mithrandir> jbailey_: what amd64 bug?
<jbailey_> Mithrandir: ld.so detects an inconsistancy when installing python2.4
<jbailey_> Fabio said he saw it in the kernel build, but I can't reproduce it (I have a segfault with mv, but I think I'd rather chase one fault at a time)
<Mithrandir> uh, uh.
<Mithrandir> I'm not at home, so I can't really help you, I'm afraid.
<seb128> elmo: glib2.0 (experimental) inkscape hardware-monitor meld  syncs please
<jbailey_> Mithrandir: No worries.  It's motivation for me to get around to buying amd64 hardware, I guess. =(
<jbailey_> Or I wonder if bochs does amd64 yet.  I know they were talking about adding it.
<Mithrandir> jbailey_: I thought that was supported for years already?
<Mithrandir> jbailey_: if you can do it in just a breezy chroot, ravel's always around
<jbailey_> Is ravel that machine I was on before that had hardware errors of some sort?
<jbailey_> Actually, there's a few machines I should try now that I have a better net connection overseas.
<jbailey_> My previous provider use to just suck for connecting to some people.
<Mithrandir> ravel is pre-production newisys equipment, so it dies once in a while, yes.
<seb128> ajmitch: around?
<thierry_> how can I make a change for a package to change the place it appears in the gnome menu?
<thierry_> like for ubuntu bug 4069
<mdke> edit the .desktop file in the package i believe
<thierry_> k going to try this...
<ogra> thierry_, copy the .desktop file for this app from /usr/share/applications to  ~/.local/share/applications/
<ogra> and edit the Categories line
<thierry_> ogra, it's not for me, it's for fixing a bug
<ogra> thierry_, ah, ok, i thought for your desktop
<ogra> thierry_, could you elaborate how that related to #4096 ? 
<ogra> relates
<Kinnison> Hi, is there an ETA on linux-restricted-modules-2.6.12 ?
<ogra> Kinnison, poke daniels....
<ogra> Kinnison, he seems to have been quite busy recently, regarding the last xorg changelog :)
<thierry_> ogra, well ubuntu bug 4069 says that emacs should be in the programming folder of applications (in the gnome menu) so I wanted to make the changes and submit a patch
<ogra> thierry_, you mean this 4096 ? https://bugzilla.ubuntu.com/show_bug.cgi?id=4096
<ogra> for me it says "PHP mail() function does not work by default"
<thierry_> ogra : not 4096! it's 4069 : https://bugzilla.ubuntu.com/show_bug.cgi?id=4069
<Kinnison> ogra: ta
<ogra> ah
<ogra> sorry, my fault
<thierry_> ogra : but do you think I should let it as Text Editor?
<thom> also, oo2 is fucked. HTH hand
<ogra> i think the decision once was not to have emacs and gvim in the manu at all
<ogra> menu
<ogra> but that might have changed over time....
<thierry_> k...
<thierry_> dpkg-buildpackage -uc -us -S doesn't work on the emacs21 package
<ogra> thierry_, with fakeroot ? 
<Kamion> thierry_: exact error
<\sh> und ich hoffe nicht, dass der besitzer nicht der ist, dem auch das gentoo-forum.de gehoert
* mdke coughs
* Lathiat mumbles
* mdke scrambles for his German dictionary
* Lathiat scrambles for a google translator
<ogra> mdke, Lathiat its not worth the fuss :) 
<ogra> totally out of context ;)
<mdke> ;)
<Lathiat> beh
<Lathiat> i want to learn german
<Lathiat> it se
<Lathiat> ems like a cool langauge
<Lathiat> all the other languages seem boring
<ogra> "cool" is a good match *g*
<ogra> cold woud even fit better
<ogra> would
<thierry_> Kamion, ogra : thierry@modemcable050:~/dev/ubun/emacs21-21.3+1$ dpkg-buildpackage -uc -us -S
<thierry_> dpkg-buildpackage: source package is emacs21
<thierry_> dpkg-buildpackage: source version is 21.3+1-8ubuntu8
<thierry_> dpkg-buildpackage: source maintainer is thierry <thierryn@videotron.ca>
<thierry_>  debian/rules clean
<thierry_> debian/rules:15: /usr/share/dpatch/dpatch.make: Aucun fichier ou rpertoire de ce type
<thierry_> make: *** Pas de rgle pour fabriquer la cible  /usr/share/dpatch/dpatch.make . Arrt.
<thierry_> sorry for the french stuff...
<Treenaks> thierry_: uh...
<thierry_> yeah I know im flooding too sorry
<Treenaks> thierry_: apt-get install dpatch
<Treenaks> probably
<thierry_> k going to try
<Treenaks> if that means "FIle not found"
<ogra> nope, build-depend on it :)
<Treenaks> ogra: I had the same problem yesterday
<Treenaks> ogra: I let pbuilder handle the build-deps
<ogra> Treenaks, the clean solution is to build-depend on it... the quick solution is sudo apt-get install dpatch ;)
<Treenaks> ogra: so dpatch wasn't installed when I tried to dpkg-buildpackage -S
<Lathiat> if its doesnt b-d on it it will probably fail in the buildd anyway
<ogra> yep
<ogra> exactly
<thierry_> Treenaks : yeah thanks it works
<ogra> Treenaks, workaround vs. solution ;)
<Treenaks> ogra: so yes, there was a build-depends, but I don't like installing 600.000 build-deps for lots of stuff when I have pbuilder
<Treenaks> ogra: so dpatch was enough to build the diff/dsc
<Treenaks> ogra: and pbuilder took care of the rest
<ogra> Treenaks, dpatch is called from debian/rules above
<Treenaks> ogra: yes, same with lirc
<ogra> so it wouldnt work in a pbuilder without build-dependency
<Treenaks> ogra: lirc build-depends on dpatch BUT I don't install build-deps: pbuilder installs them inside the chroot when building
<ogra> Treenaks, yes
<Treenaks> ogra: so I had to install dpatch OUTSIDE my chroot to be able to build the source package
<Treenaks> ogra: which I then gave to pbuilder
<Lathiat> but it should whinge if build-deps arent satisfied?
<Lathiat> mine did
<ogra> Treenaks, so dpatch is called from the clean target ? 
<ogra> Treenaks, thats not nice
<Treenaks> ogra: yes
<Lathiat> ah
<Treenaks> Lathiat: -S works always
<Lathiat> right
<smurfix> Does anybody know if/when elmo will show up again?
<Treenaks> "When time permits" ?
<smurfix> "Time is an illusion. Lunchtime doubly so."
<Treenaks> smurfix: I wish
<lamont> daniels: so I see -35, are we waiting for NEW love on the new packages?
<CavalierBob> Hi all.
<CavalierBob> Sorry to bother the dev list with this, but I'm seeing a MD5Sums mismatch on a package in Main for 2 days now. Can someone here look at it or should I file a bug?
<Hieronymus> CavalierBob: not using us.archive.ubuntu.com are you?
<CavalierBob> Hieronymus: As a matter of fact, I see I am...problem there?
<lamont> CavalierBob: sounds like a mirror bug
<lamont> rather than an ubuntu bug
<CavalierBob> Right, I'll switch mirrors and give it a try again. Thanks!
<sabdfl> jbailey: schnaaaake!
<sabdfl> hey anibal, how do you get the .biz from .fi?
<anibal> sabdfl, by using dircproxy
<sabdfl> anibal: cute!
<Lathiat> You can have your reverse dns at anything
<Lathiat> my aussie dsl is penguins.squaa.org
<jbailey> sabdfl: heyhey
<seb128> elmo: glib2.0 (experimental) inkscape hardware-monitor meld anjuta syncs please
<jbailey> hmm.
<jbailey> Oh yeah, debuild clears the path.
<jbailey> whups, ECHAN
<pitti> Hi
<ogra> oh, the finnish ubuntu security team is around :)
<ogra> pitti, how is HEL ?
<pitti> ogra: nice indeed; much hotter and greener than I expected
<seb128> hey pitti 
<pitti> Hi seb128, how are you
<aio> is there a problm with libstdc++6_4.0-0pre6ubuntu7_i386?
<seb128> pitti: a bit overloaded (new GNOME version this week, bug flood, and specs to move this week) but fine :)
<aio> i keep getting an MD5Sum mismatch error on it.
<crimsun> aio: use a different mirror.
<Kamion> aio: if you're using us.archive.ubuntu.com, try a different mirror
<zyga> hello
<zyga> symphony os makers have released an interesting document about UI design
<zyga> I thought that someone might be interested: http://homepage.mac.com/jasonspisak/Mezzo/Menu3.html
<rob^> I'm getting this when trying to find and import my gpg key in Lauchpad: Key was claimed, sending email to :.At least one UID should be validated to get the key imported as yours.
<rob^> any ideas?
<Hieronymus> you need to be part of web of trust I think.
<ogra> yes, your key should be on a keyserver and valid
<rob^> which keyserver does it use?
<ogra> rob^, ask in #launchpad ?
<rob^> ok
<sebest> hello, anyone knows the name of the package that contains the "notification area" applet?
<Lathiat> sebest: gnome-applets i suspect
<seb128> gnome-panel
<Lathiat> ahah, yes
<seb128> /usr/lib/gnome-panel/notification-area-applet
<sebest> i'm trying to find why it doesn't handle panel transparency
<Lathiat> sebest: part of thats probably due to the icons being xembedded
<Lathiat> hrm, the patch for the window list should go in
<sebest> lathiat, you mean embeded in the code?
<Lathiat> and clearlooks needs som elove on its handles
<Lathiat> sebest: nah like, when an application displays an icon
<Lathiat> sebest: aiui, its an X windows from another application
<Lathiat> so i dunno if you can fix that within notif applet or if its due to the implementation
<sebest> ah, i see
<Lathiat> feel free to poke..
<sebest> oki, i'm :)
<hughsie> ogra:ping
<ogra> hughsie, pong.... soryy, havent packaged yet
<hughsie> ogra: don;t bother, i have new things... :-)
<hughsie> let me run these past you as an ubuntu'er
<ogra> ok
<hughsie> package "pmscripts" contains /usr/sbin/pm-shutdown pm-hibernate, pm-suspend. It's designed for distros to tweak to what they want.
<hughsie> package powermanager contains simple dbus server that lets ordinary users execute just these scripts according to polict in /etc/dbus
<hughsie> package gnome-power contains all the gui and configuarion, and the session daemon
<ogra> so we have a backend server now ?
<ogra> who listens for the dbus messages ?
<hughsie> not really a server, it just lets normal users do things like echo "disk" > /sys/power/state
<hughsie> in a safe way of course
<ogra> how is this safe way designed ? how do you work around using suid ?
<hughsie> ogra: how do I do a private chat in x-chat?
<hughsie> using the permissions in dbus
<hughsie> not suid.
<hughsie> suid bad ;-)
<mdke> is the website down?
<mdke> i can't connect
<mgalvin> mdke, which site?
<mgalvin> i can hit ubuntu.com
<mdke> hmm
<mdke> i can't
<mdke> weird
<mdke> whats the ip address?
<mgalvin> i do know there have been some dns issues in th uk...
<mgalvin> over the past few days
<lamont> Kamion/elmo: binutils-hppa64 universe->main please
<mdke> ah
<mgalvin> thats why i have had such bad speeds to site over there
<mgalvin> coming from the us
<mgalvin> anyway
<mdke> okies
<mgalvin> 82.211.81.130
<mdke> i can't ping it
<mgalvin> hmm, i can
* mdke shrugs
<lamont> Kamion/elmo: gcc-* kinda build-dep it for hppa
<Kamion> lamont: leaving that to elmo, I don't know the policy on main stuff for hppa
<lamont> Kamion: np.  one more thing for elmo's list. :)
<lamont> some other stuff has moved (gcc-3.4-hppa64, I believe), but the scripts don't do it automatically
<lamont> otoh, none of the gcc uploads for hppa have made hte archive, so that's a bad example
<lamont> well, all the hppa-specific kernel packages are in main anyway...
<lamont> but enough for now... /me ->work
<mgalvin> hey guys, what installation types/methods will be supported in breezy (cdrom, smb, tftp, etc...)?
<Kamion> mgalvin: no additional methods currently planned over hoary
<mgalvin> Kamion, ok and what are the "Officially Supported" types now
<Kamion> mgalvin: http://archive.ubuntu.com/ubuntu/dists/hoary/main/installer-i386/current/doc/manual/en/ch02s02.html
<mgalvin> need to know for docs
<mgalvin> Kamion, thanks!
<Kamion> you should already be referring to that manual
<ogra> pitti_, ping
<mdke> i still can't hit ubuntu.com
<pitti_> Hi ogra
<pitti_> Hi doko :-)
<Mez> :'( you say hi to them but not me :'(
* Mez slaps pitti_  meanie
<doko> hi pitti
* pitti_ whishes Mez a really great evening and hugs him heartily
<Mez> :P
* Mez glares at pitti anyways
<pitti_> Mez: ENOREALNAME
<pitti_> ogra_: ping2
<Mez> pitti_, huh?
<carstenh> "ircname  : Mez" vs. "ircname  : Martin Pitt"
<hughsie> pitti_ : can you join g-p-conspiracy plz
* Mez shrugs
<Mez> people IRL call me Mez...
<Mez> so that's my name
<carstenh> thats your nich, but not your realname
<carstenh> nick
<carstenh> it's not your nick that is wrong, it's the ircname-field. try /whois somenick
<neiras> Hello - Is there a MOTU present? We're having a package problem
<neiras> The Hoary package 'ruby1.8' is two days older than the stable ruby1.8 - it's actually a pre-release. Some ruby applications are requiring the stable edition and refusing to run.
<srbaker_> yo
<neiras> Seems like a pretty good candidate for a hoary update, since there were some important fixes to ruby in that time
<crimsun> neiras: sorry, we MOTUs aren't in charge of that. It's a package in main.
<neiras> okay. How should we proceed?
<ogra> crimsun, ECHAN ? 
<ogra> ;)
<crimsun> ogra: I thought too, but he asked in here ;)
<srbaker_> oh for fuck sakes
<srbaker_> there's more energy wasted talking about which chan to talk in than sovling the fucking problem
<crimsun> chill, srbaker_ 
<JanC> srbaker_ : the MOTUs *can't* solve this
<srbaker_> JanC: i know.
<JanC> so don't yell at them, you might need them later  ;)
<crimsun> keep in mind that quite a few of the developers are at DebConf, so resources are limited
<neiras> So who can?
<neiras> Should I be filing a bug on this or what
<srbaker_> jbailey: is this soemthing you can deal with?  i know you're home :)
<JanC> a bug report is always good
<crimsun> neiras: the easiest resolution at this point would be to adjust the version check in whatever application
<neiras> I can do that, but we need this working yesterday and a lot of people will be experiencing the issue shortly... It'd be good to have an official fix asap
<jbailey> srbaker_: Is there a bugzilla entry filed for it with the exact text of an error message?  Nothing will get into Hoary now without a decent bug report and some information as to why the bug is important.
<srbaker_> crimsun: the check isn't what depends on the new ruby.  it's the code that will break that depends on the new version
<neiras> crimsun, the fixes were critical.
<ogra> important == dataloss or big security hole
<crimsun> then jeff has the correct resolution, which is to file a bug with the proper details
<srbaker_> crimsun: they wouldn't have added a version check if it didn't require the new version
<srbaker_> good
<neiras> I've added https://bugzilla.ubuntu.com/show_bug.cgi?id=12613 if anyone is interested or knows who should see it.
<Amaranth> neiras: That's sick.
<Amaranth> neiras: ruby apps make you upgrade to a version released on an exact day?
<neiras> Amaranth, 1.8.2 is stable - why is prerelease code being shipped in Hoary anyway?
<Burgundavia> neiras, didn't make the code freeze
<Burgundavia> I gues
<neiras> Burgundavia, true, but that's what updates are for :/
<Amaranth> no
<Amaranth> hoary-updates is for crashers and/or very serious bugs
<Amaranth> this might qualify, but i have a feeling it'll be like firefox
<neiras> Amaranth, it's not like this is an everyday occurrence for Ruby apps. The fixes that went into Ruby in that timeframe were for serious bugs
<Amaranth> in two days they fixed a bunch of serious bugs and released?
<neiras> Apps that are checking this would otherwise be affected.
<neiras> It was caught late.
<Amaranth> if so, i don't think i want to trust ruby
<neiras> That's up to you, but some people have to :)
<Amaranth> if the bugs are as serious as you make it sound and were hard to find, they should have taken more than 2 days to get fixed and QA'ed
<neiras> there's a time for purism, and a time for pragmatism
<neiras> shoulda/coulda/wouldas aren't useful right now :)
<Burgundavia> neiras, this post to the Ubuntu devel mailing list making your case
<neiras> Burgundavia, shall do, thanks.
<srbaker_> Amaranth: shipping pre-release software is stupid at best, and is certainly cause for an update
<lamont> doko: you around?
<doko> lamont: yes
<doko> where does gcc fail? ;-)
<fabbione> doko: any news about the gcc ICE's ?
<fabbione> specially the one on ppc i am interested in
<doko> fabbione: no, not yet. sorry. distracted with gcc-4.0 FTBS on alpha.
<fabbione> doko: ok.... 
<doko> and I use the time to pester goto, as long as he's here ;)
<ogra> poor guy
<ogra> :)
<doko> lucky ogra until I don't have time for him
* ogra looks for a good photo of doko for the new xscreensaver lockwindow background he is just compiling
<ogra> doko, be careful ;)
* doko is changing the oogra splash screen
<ogra> heh
<ivoks> ;)
<doko> well, better not, ubuntu is about humanity ...
<fabbione> doko: ahaha
<doko> just got a grappa from enrico, and it's thom's birthday
<fabbione> ohi
<fabbione> grappa is good, isn't it?
<doko> sweeet
<fabbione> ehehe
<ogra> happy b-day thom !!
<fabbione> i really wish i could have come
<doko> ogra: I'll tell him
<ogra> thanks
<thesaltydog> ogra, ?
<mdke> hey thesaltydog!
<ogra> thesaltydog, ?
<thesaltydog> here I am oliver. A m inute?
<ogra> yep
<thesaltydog> i have not yet installed breezy, but a friend told me there is a BUM mini-clone in it.. What is?
<ogra> thesaltydog, its the service manager from gnome-system-tools
<thesaltydog> are you including the whole GST?
<ogra> we had it always in... only disabled the things that were not stable enough....its a part of gnome
<thesaltydog> ogra, yes. So you "downgraded" the service tool..:-)
<ogra> no, we just didnt compile it... it was always in the source but what you see now is a rewrite without the dangerous parts and a easier ui...
<ogra> i admit it looks a bit like a dumbed down bum 
<ogra> but its C
<ogra> with the default gst perl backend ....
<thesaltydog> I have rewritten Baobab in C. A couple of days it will be online.
<ogra> great :)
<ogra> looks really neat
<thesaltydog> a couple of debian mainainers asked me to get BUM in debian main inclusion...
<ogra> yay
<ogra> thats great
<ogra> you should definately do that 
<thesaltydog> yes I will, even if I designed it for ubuntu..
<ogra> and i guess you learned eough about packaging the last months to apply for maintainership yourself ;) 
<thesaltydog> booooring
<ogra> hehe
<thesaltydog> once finished the C verison of Baobab, could I upload it in REVU?
<ogra> sure
<thesaltydog> I'll send you a memo, then.
<ogra> yep :)
<thesaltydog> thanks Oliver, bye.
<ogra> bye :)
<slomo> hi... i've created an updated faad2 package which now uses the original upstream source (which wasn't the case with the package currently in breezy). it's uploaded here http://siretart.tauware.de/revu/details.py?upid=88 now the question is what to do with the changed tarball as there is no new upstream version and the two would collide when uploaded
<Kamion> slomo: there's no way to do that other than to invent a version for the changed upstream tarball that you're confident won't collide with any other upstream release
<slomo> Kamion: maybe something like faad2-2.0.0.ubuntu.orig.tar.gz for the tarball?
<Kamion> "ubuntu" implies that the changes to the upstream source originated with Ubuntu, which apparently isn't accurate here
<Kamion> I'd go with something more like 2.0.0real
<Kamion> what are the changes in the .orig.tar.gz currently in breezy versus what upstream released?
<slomo> at least all the files created by autoreconf and a config.log
<Kamion> 2.0.0clean would be an option too
<slomo> ok, i'll take 2.0.0clean then :) thanks
<slomo> the current version is 2.0.0-0.5... would the new one be 2.0.0clean-0ubuntu1?
<slomo> Kamion?
<Kamion> slomo: yes - but please co-ordinate with the Debian maintainer so that we don't get into a state where the Debian maintainer uploads 2.0.0clean as well and then we're unable to sync it because it's a different .orig.tar.gz
<Kamion> (which would be a pain)
<sabdfl> hy guys
<Kamion> hi Mark
<sabdfl> err... hey
<slomo> Kamion: there is no debian maintainer... this package was imported from marillat's repository
<ogra> hey sabdfl 
<Kamion> slomo: oh, er, eek
<Kamion> slomo: co-ordinate with Marillat then if you can :-)
<Kamion> .orig.tar.gz desyncs are a nightmare
<ogra> Kamion, do we actively import from there ? 
<sabdfl> hiya ogra
<ogra> i thought that was a one time thing
<ajmitch> hi
<sabdfl> ogra: sync before release too, i think
<ogra> sabdfl, ah
<ogra> sabdfl, looks bad for squeak, did elmo talk to you ? 
<sabdfl> ogra: notyet, i'll ask him tomorrow
<Kamion> ogra: there's support in katie for doing so; it's currently commented out so it looks like something elmo does periodically
<Kamion> sabdfl: we should be doing that sometime around now for breezy I think, since upstream-version-freeze was end of last week
<ogra> sabdfl, great... 
<slomo> Kamion: i've rewritten the complete package because of this and added me as maintainer... i've written marillat before and his answer was to talk to ubuntu to solve this
<Kamion> hoary was a rush and would ideally not be repeated :)
<Kamion> slomo: ok, typical unhelpful response from him there
<sabdfl> Kamion: ok, dholbach did it last time
<sabdfl> he'd likely be happy to do it sooner this time
<dholbach> erm
<dholbach> what are you guys talking about? ;)
<slomo> Kamion: so it's ok the way i did it?
<sabdfl> you!
<Kamion> dholbach: syncs from non-Debian sources
<Kamion> slomo: probably about the best you're going to get
<dholbach> Kamion: yeah, that was funny, especially the wiki-bit ;)
<dholbach> i think i'll have the lists of packages-to-be-imported ready 2 weeks for release
<slomo> kafeine: ok, fine... thanks for your help :)
<dholbach> that should suffice, shouldnt it?
<slomo> hum, i meant Kamion... sorry
<ogra> dholbach, Kamion wants UVF for universe too....
<Kamion> ogra: not just me, I checked that with mdz first
<dholbach> i'm going to cry
<ogra> dholbach, Kamion and mdz want UVF for universe too
<ogra> :)
<Kamion> obviously UVF would be applied to universe rather more leniently than to main
<dholbach> i'll have time for this 6 weeks before release
<ajmitch> Kamion: UVF being last week?
<dholbach> and we have millions of new packages to get in
<Kamion> ajmitch: right
<ogra> ajmitch, yep
<Kamion> remember guys, there will be more releases; there's always a newness/stability trade-off
<dholbach> (MOTUNewPackages, REVU, UniverseCandidates, AptGetOrg, ...)
<ajmitch> how will UVF affect new packages coming in?
<dholbach> and we're lagging so much behind review wise
<Kamion> of course entirely new packages don't have the same constraints, since they're clearly not liable to break stuff that people are already using
<dholbach> ajmitch: they won't come in
<Kamion> ajmitch: not clear exactly what the rules are for those, haven't talked to mdz
<dholbach> Kamion: that's nice :)
<Kamion> but I think the above is roughly sensible ...
<dholbach> yeah
<ajmitch> Kamion: sounds good
<dholbach> ok, if we're able to get the new crack in shortly before release, i'm happy
* siretart agrees with Kamion that we should not do any transitions like the libaa transition in universe for breezy
<ogra> dholbach, NEW is not very much... 
<dholbach> because i already feel bad for not doing enough reviews and letting lots of people wait on their good work
<dholbach> ogra: ?
<ogra> dholbach, is all apt-get.org new ? 
<ogra> i doubt it
<dholbach> ogra: of course not, but think of all the new packages
<dholbach> ogra: and the annoyed motu hopefuls
<dholbach> ogra: the new packages would be their chance to get in (and rewarded for their work)
<dholbach> but oh well... i think we don't have to discuss this
<ogra> dholbach, sure, but we still have about 500 C++ packages to gain fame with....and idontknowhowmany broken x dependencys through the modularization
<ajmitch> we've got > 20 new packages waiting for review on revu
<dholbach> ogra: sure
<Kamion> siretart: mm, there's probably some awkward slang2 stuff pending
<dholbach> ajmitch: don't forget MOTUNewPackages and MOTUToReview
<Kamion> not quite sure what to do about that as it affects the installer
<ogra> ajmitch, thats nothing compared to the broken stuff
<dholbach> ogra: i'll try to set up UniverseUnmetDeps in the next days - that'll be a start to sink our teeth in
<ajmitch> ogra: so what's the current motu todo list that people really need done?
<siretart> Kamion: uuh. sounds annoying. how difficult will be the transition? just a few build depends or porting work?
<Kamion> siretart: bit of both
<siretart> :/
<ogra> ajmitch, C++ (still, sigh) ... xorg depending packages ....
<Kamion> siretart: it's mostly done in Debian though
<Kamion> I think just before UVF
<dholbach> ajmitch: reviewing, MOM merging, fixing packages, malone/bugzilla :)
<Kamion> at least all the installer-relevant stuff should be done
<ajmitch> dholbach: fun
<ogra> yes, what dholbach said
#ubuntu-devel 2005-07-17
<dholbach> good night everybody
<jp> night 
* terrex se va a mimir, tamn
<syndicate> dholbach: ping
<syndicate> bah, he left
<syndicate> whiprush: ping
<hub> hi
<hub> is there a way, as upstream maintainer, to be CC by default on some component in ubuntu bugzilla ?
<schweeb> hub: I know you can add yourself to notifies for a certain bug
<hub> schweeb: yeah; but I'm thinking about all new bugs for a component I'm upstream
<hub> I know you can do that with admin rights in bugzilla
<schweeb> hub: ask mdz, probably
<ficusplanet> Will the hal patches for cups make it into breezy?
<wasabi> Wouldn't a LTSP port to Ubuntu be NEAT?
<wasabi> (thin clients boot Ubuntu over the network which autodetects hardware using current liveCD tech)
<wasabi> (but then mount remote nfs /)
<Kamion> that would be what mdz's currently doing
<wasabi> Oh. Really?
<wasabi> I'm smrt.
<Kamion>       ltsp |       0.43 |        breezy | source
<Burgundavia> wasabi, the future versions of LTSP are going to be built on Ubuntu
* Kamion steals and waves mdz's retroactive feature request satisfaction wand
<wasabi> Burgundavia, that's what I mean.
<wasabi> Burgundavia, that's slick. One of my current complaints with LTSP was that it was like a little seperatly maintained chroot thingy.
<wasabi> But having that itself be Ubuntu is pretty cool.
<Kamion> it still has to be a separately-maintained chroot, but it gets easier to maintain
<Kamion> ideally, you automate the maintenance
<daniels> Kamion: shit man, can I borrow that wand?
<lamont> daniels: you're not getting out of xorg work that easily
<daniels> damnit!
<daniels> i uploaded -35, what more do you want from me?
<daniels> blood??
<lamont> Kamion: 675,844,096.... I wonder if maybe it's time to reset the i386 images.. 
<lamont> or better yet, maybe I should really deploy sladen's hack
<lamont> er, code
<daniels> -36 is coming as soon as I've fixed symlink.sh to put Xvlib.h and XvMClib.h in the right spots
* lamont puts that on his todo list for this week
<lamont> daniels: it's rude to upload faster that we can build, you know...
<lamont> then again, my buildd is walking through the gcc-* landmine field, should take it most of the day
<daniels> lamont: funny, I could've sworn you were on my case all week to upload NOW, DAMNIT :P
<Kamion> lamont: i386 images don't need reset, surely?
<lamont> daniels: the first time
<lamont> Kamion: doh
<lamont> only the 64-bit images ever need reset
<wasabi> Does LTSP handle session reestablishment?
<wasabi> Oh, LTSP is remote X server isn't it.
<wasabi> Which doesn't even have that.
<wasabi> =(
* lamont grumbles
<bob2> xmove.
<lamont> help me kamion-kenobi.
<lamont> hrm... actually, I can just fetch the tarball myself.
<daniels> xmove is the way of the future
<wasabi> haha xmome is cool
<wasabi> but way to hard to use.
<wasabi> And it screws so much up
<Kamion> lamont: ?
<bob2> it does?
<wasabi> You are talking about the little xmove app right? not some new extension or something, right?
<daniels> oh my god, I love zsh
<lamont> Kamion: nm.. braindead here
<lamont> thought something wasn't mirrored, turns out I can't type pathnames in correctly
<wasabi> I'd like some sort of cool LTSP roaming thing... where you logged into LTSP desktop, it went out and found current login sessions on terminal servers across the network and dropped you at your current one.
<daniels> wasabi: about the little app, yeah
<wasabi> Me and a friend are talking a lot abouta  business plan to build and sell thin clients and server setups.
<wasabi> So I'm talkative.
<daniels> but even zsh can't protect me from stupidity
<daniels> it should know that when I type "cvs diff -u 'Add Xvlib.h, change soversion to 1.0.0.'", I mean "cvs ci -m '...'"
<bob2> haha
<lamont> daniels: at least it didn't involve rm -rf *
* bob2 only ever uses shell history for that
<daniels> lamont: it prompts me on that :
<daniels> :)
<daniels> 'dude, are you *sure* you want to remove everything?'
<daniels> bob2: shell history is a wonderful thing
<bob2> except when I do the same commit 3 times in a row, with no changes between them
<daniels> heh
* bob2 blames bzr somehow
<Amaranth> does X work today? :)
<Amaranth> haven't updated anything in two weeks, this is going to be fun
<daniels> i *think* it works
<daniels> no-one's bitched incessantly at me yet
<daniels> so I assuem so
<AndyFitz> http://andy.fitzsimon.com.au/screenshot.png   - I love the new nautilus
<lamont> Kamion: any clue what kernel we're putting in the d-i install image for ia64?
<Burgundavia> daniels, for -36 you should build a remote terminate button in, so that when people complain about it not working, you can press the big red button
<lamont> anyway, time for this one to go home
<bob2> wow
<bob2> that nautilus looks nice
<Amaranth> AndyFitz: hot
<daniels> Burgundavia: good plan
<tseng> having it in list/tree view
<tseng> and have the location bar that the same time seems a bit busy
<Burgundavia> http://thunar.xfce.org/wiki/media/ui/suggestion-20050320/shortcuts_buttons.png
<Burgundavia> that is what I want
<AndyFitz> yeah I don't use the location bar at all by default
* lamont -> home
<Burgundavia> almost there with nautilus
<AndyFitz> I just use the go menu
<bob2> yeah
<tseng> Burgundavia: you can do that
<bob2> but it's an imrpvoement
<AndyFitz> its there for bling status
<Burgundavia> tseng, not in spatial
<tseng> Burgundavia: uh, of course not
<Amaranth> the new nautilus looks better than thunar
<Burgundavia> tseng, that is spatial within the window, but with the places and toolbar
<AndyFitz> Amaranth,  agreed.  good that they picked up the ball
<tseng> Burgundavia: eh
<Amaranth> AndyFitz: So how are the new icons coming along?
<tseng> Burgundavia: if im using spatial i dont need all that crap
<Burgundavia> tseng, basically similar to the mac os X one
<tseng> i guess
<tseng> i look at this as a thing for first time users
<tseng> not for me.
<Burgundavia> that is why I love the thunar stuff
<Burgundavia> so clean
<tseng> windows converts expect browser behvarior
<Burgundavia> not really
<tseng> novell usability study says yes really
<Burgundavia> have they put that video up yet?
<tseng> no, i asked them to do it for mono live
<tseng> and anna said, browser mode dudes
<AndyFitz> I agree with tseng.  nautilus is feature full enough to give most types of file navigation  ( aside from OSX column view.    
<Burgundavia> anyway, I have to run
<tseng> k
<Burgundavia> but we need a way out of the current spatial swamp
<tseng> the only swamp i know of is ubuntu spatial
<Burgundavia> that is what I mean
<tseng> well it seems pretty non-controversial that we will trade that for this: http://andy.fitzsimon.com.au/screenshot.png
<tseng> or reasonable facsimilie of
<tseng> places + location bars
<tseng> on browser
<Burgundavia> that isn't bad
<Burgundavia> but that with spatial would be nicer, IMHO
<tseng> i think alot of people dont "get" spatial
<Burgundavia> I think they do
<tseng> I do get it, and i see no reason to clutter my windows with that stuff
<Burgundavia> this would be single window spatial
<Burgundavia> to be clear
<Burgundavia> and the window would no resize
<Burgundavia> or move
<tseng> the who what?
<tseng> so just spatial placement
<Burgundavia> yes
<Burgundavia> sorry
<tseng> not navigation
<tseng> I see.
<tseng> then we are in agreement (i think all windows should be spatial)
<Burgundavia> that isn't clear from the thunar screenshot
<tseng> in that respect
<AndyFitz> if we had sexy transitions as new windows popped up .  maybe spatial would be good.    but the visual noise created by popping those windows up suddenly  with no viaul link to where they came from is irritating and in my opinion  unusable
<Burgundavia> well, that makes jdub, you and I that like that
<Burgundavia> AndyFitz, we are talking single window now
<tseng> seb liked it
<Burgundavia> need some hacking
<Burgundavia> to do single window spatial placement
<Burgundavia> but not much
<Burgundavia> you want to fire a message of to the -devel list about it?
<tseng> i dont like list view as default still
<tseng> andy's setup w/ icon view
<Burgundavia> you mean you do like?
<AndyFitz> tseng yeah default should be icon view  
<tseng> Burgundavia: no
<AndyFitz> and no places bar on the side 
<Burgundavia> ok
<Burgundavia> AndyFitz, the places bar is quite nice
<Burgundavia> tseng, ok
<Burgundavia> AndyFitz, part of the "where was I yesterday" stuff
<Amaranth> here goes the upgrade
* Amaranth weeps
<AndyFitz> I guess its a preference thing.  I don't use the places often enough to not want to compromse that left space for what I coulg get by going to the go> menu
<Burgundavia> anyway, I really have to go now
<tseng> Burgundavia: http://tseng.ath.cx/images/Screenshot-1.png like so
<AndyFitz> I'm kinda cut that the finder in nautilus doesn't use the 22x22 icons like it should
<AndyFitz> it resizes the 24x24 ones  .. grrr
<tseng> yeah
<tseng> why doesnt it just show the full 24
<AndyFitz> I agree.  its a very dickie move
<tseng> AndyFitz: i get the same thing if i set nautilus default zoom to 75%
<tseng> AndyFitz: resizes :/
<Amaranth> it's possible to have an icon theme change the little foot icon on the applications menu, right?
<tseng> Amaranth: yes
<tseng> er
<tseng> the "menu" one, not the "menu bar" one afaik
<AndyFitz> amaranth:  want me to send you the pixmap to replace the gnome foot with ?
<daniels> infinity: could you please kick libx{fixes,damage,composite} to rebuild?
<Amaranth> sure
<Amaranth> btw, the show desktop icon is too wide
<Amaranth> or something, it's odd
<tseng> i disagree
<tseng> wide = easier to press
<AndyFitz> its a bug.  I don't know how to fix it  ( you are talking about the icon in the applet right ?
<Amaranth> it's getting cut off vertically though
<tseng> um
<Amaranth> yeah, it's not getting resized
<Amaranth> let me screenshot
<tseng> looks ok on mine afaik
<Amaranth> http://dev.realistanew.com/show_desktop.png
<AndyFitz> Amaranth,  sent 
<Amaranth> if my domain name still works...
<AndyFitz> amaranth,  yeh its scaling the icon in a weird way
<AndyFitz> I've got 16x16 22x22 24x24  and scalable sizes  for that icon
<AndyFitz> but still the applet warps it 
<Amaranth> shit
<Amaranth> my domain name is registered with an email address that doesn't exist anymore with an street address i don't live at anymore and with a credit card that expired
<bob2> call NSI and ask them politely to transfer it to you
<bob2> and get google.com while you're at it
<Amaranth> haha
<Amaranth> these icons don't really go with anything other than human
<infinity> daniels : Sure.
<daniels> ta
<ajf2> whoa
<ajf2> IRC on IPv6. Heh.
<Lathiat> heh
<infinity> daniels : xorg -35's MANIFEST was broken on powerpc (but only powerpc?)
<daniels> infinity: yeah, already fixed in -36, which I'm going to punt up if libxevie builds ok
<daniels> which it just did
<infinity> Mmkay.  xfixes looks okay, the other two are dep-waiting on it, so it'll take a dinstall or two to see them build.
<daniels> right
<wasabi> uh. ok
<wasabi> so my shift key and capslock don't work
<wasabi> and ctrl and alt
<wasabi> this just happened while closing a program that could have caused it 9vmware0
<wasabi> however, one would think that with vmware gone, my keyboard would work again
<daniels> awesome
<infinity> It remapped it on the way out?
<wasabi> because it would be silly for one program to be able to permanently do that.
<wasabi> advice/ heh
<wasabi> heck.
<wasabi> b rb
<mxpxpod> ok, with breezy, bitstream vera sans at 9 point font doesn't have much difference between bold and regular
<mxpxpod> daniels: is there a reason for that?
<daniels> i dunno
<mxpxpod> want to see a SS?
<daniels> i'm not the fonts guy :)
<mxpxpod> who is?
<daniels> erm
<daniels> good question, actually
<daniels> but I really don't have in-depth knowledge of fonts
<mxpxpod> heh, nice
<mxpxpod> in hoary, it looked fine... breezy, it's strange
<daniels> try downgrading libfreetype6
<mxpxpod> daniels: to what version?
<daniels> um
<daniels> hoary's?
<schweeb> fonts are a complicated beast
<mxpxpod> daniels: http://www.reigndropsfall.net/images/fonts-issue.png
<mxpxpod> daniels: wait, let me upload it again
<mxpxpod> my connection is being flakey tonight
<mxpxpod> daniels: ok, check it now
<mxpxpod> schweeb: you too
<schweeb> mxpxpod: my solution, fix your dpi and/or don't use fonts smaller than 10 ;)
<schweeb> and what are your hinting settings?
<schweeb> I'd use best shape... slight hinting
<vidz> Is there any way to formally request that eog be removed from ubuntu main and gthumb replace it?
<HrdwrBoB> seconded
<mxpxpod> schweeb: I've got my dpi at 75... is that bad?
<schweeb> that's what I use on my laptop
<schweeb> at 1024x768
<schweeb> 12"
<schweeb> probably want something better at more reasonable resolutions
<vidz> eog is the default image preview program for ubuntu and DOESN'T even support printing the picture!
<schweeb> something more in the range of 90
<Lathiat> vidz: whats better
<Lathiat> gthumb wont open a file right up if you open it with it
<Lathiat> it opens the directory
<mxpxpod> schweeb: yeah, I've got a 12" 1024x768 too...
<schweeb> mxpxpod: looks fine for me, albeit I don't  use evo
<vidz> Lathiat: yes it will
<mxpxpod> schweeb: what size font do you use?
<vidz> Lathiat: Thats how I set this computer up
<schweeb> 10
<schweeb> for everything
<schweeb> Bitstream Vera
<vidz> Lathiat: Right click on a jpg -> Properties -> Open With -> Add. type gthumb and then it will open all jpgs up. Not the directory
<mxpxpod> schweeb: aha! if I set Hinting at medium, bold works fine
<mxpxpod> thanks for that tip
<schweeb> np
<mxpxpod> haha, yahoo mail is messed up tonight
* daniels points Excessive Ephemera at the archive and fires away.
<daniels> lamont-away: sorry dude
<infinity> daniels : You need to tighten build-deps in xcomp, it looks like.
<infinity> daniels : If it requires a specific xdamage...
* daniels boggles at his own stupidity.
<daniels> thanks
<fabbione> morning
<fabbione> daniels: + Hardware support for motion compensation (i.e., libI810XvMC) has
<fabbione>        disappeared for the time being.  Not that anything used it anyway.
<fabbione> meh dude...
<fabbione> do you realize that there are a bunch of pkgs using it?
<fabbione> but they fail to find it at configure time because of all the changes between xfree86 and xorg?
<lamont-away> daniels: feh
<fabbione> hey lamont
<lamont-away> howdy
<fabbione> daniels: iirc almost all the players that can use XvMC are able to recognize the i810 extension.. or at least they try to :)
<daniels> fabbione: ah well.  it'll come back soon enough.
<jc_c> hello
<jc_c> is there any chance that the current sk98lin driver in the kernel would be replaced by the newer skge? That would be a cool thing since sk98lin doesn't support link detection, and therefore may not work peacefully with NetworkManager...
<jc_c> oh nevermind, I just noticed that breezy does indeed use skge :p
<seth_k> so did anyone ever decide, do we use malone or bugzilla?
<lifeless> seth_k: motu is malone
<lifeless> main is stull bugzilla
<seth_k> gotcha
<seth_k> thank you
<fabbione> daniels: what's you ETA to complete Xorg split?
<daniels> fabbione: completely?
<fabbione> daniels: we have tons of pkgs that are FTBFS due to the split and i think the MOTU's will like to know when they can start fixing the B-D
<daniels> they can start any time they like?
<fabbione> probably some pkgs in main are in the same status
<daniels> i'm doing most of the rest of the libs now
<fabbione> daniels: most of the FTBFS are due to missing includes and linking libs... so it needs to be done after you have finished with the libs :)
<daniels> it's always been that if you add -I/usr/X11R6/include and make sure your includes are <X11/foo.h> or <X11/extensions/foo.h>, then everything will work
<daniels> both now and when I'm totally finished
<daniels> but, that being said, I hope to be done with most of the libs that everyone uses very soon
<fabbione> ok
<daniels> i've done about 8 in the last couple of days, and hoping to get through another 5 today
<fabbione> than it's worth to wait a couple of days
<daniels> probably
<Mitario> mornin'
<pitti> Morning
<fabbione> hey pitti
<tepsipakki> marilize: hi
<tepsipakki> marilize: I asked you about those hoary-cd's
<Amaranth> daniels: you're making symlinks back to /usr/X11R6/?
<daniels> Amaranth: huh?
<Amaranth> daniels: symlinking things to where they used to be in /usr/X11R6/
<daniels> Amaranth: not if I can help it
<Amaranth> oh ok, i must have misunderstood
<marilize> tepsipakki: hi
<Amaranth> so the goal is to completely remove /usr/X11R6/
<marilize> tepsipakkiL
<marilize> tepsipakkie:email address?
<Amaranth> daniels: is /usr/bin/X11/ the final destination for X binaries or are they going straight to /usr/bin/?
<daniels> Amaranth: straight to /usr/bin; /usr/bin/X11 is a symlink to /usr/bin
<daniels> so they'll be accessible via /usr/bin/X11
<Amaranth> ah
<tepsipakki> marilize: tjaalton@cc.hut.fi
<Amaranth> daniels: is there a wiki or something that explains all of this?
<Amaranth> the end goal was a 1:1 mapping between modules and distro packages, right?
<daniels> Amaranth: 'my head'
<daniels> Amaranth: yeah
<Amaranth> well, don't leave your house
<daniels> ?
<Amaranth> your head doesn't accept input after it's been hit by a bus :P
<daniels> heh
<daniels> crucially, it doesn't output at all
<Amaranth> heh
<Amaranth> no output is better than garbage output
<marilize> tepsipakkie: ok, see it
<Amaranth> daniels: is there a wiki that explains what X.org is doing?
<Amaranth> daniels: I think you've sent me to it before.
<marilize> tepsipakki: do you want to adjust QTY
<Amaranth> i mean what they're roadmap is
<Amaranth> err, their
<tepsipakki> marilize: yes, but don't have them now. You haven't sent them yet?
<daniels> Amaranth: http://xorg.freedesktop.org/wiki/ModularizationProposal, IIRC
<Amaranth> "You no longer have to build and install the entire tree just to work on one small part of it." <--yay!
<daniels> you no longer have to build and upload the whole frigging tree to fix a single typo <- HOLY CRAP YES
<marilize> tepsipakki: will go out within the next day or two.....
<Amaranth> daniels: exactly
<Amaranth> daniels: that right there is reason enough to do it
<daniels> i did a bit of work on the debian xorg packaging today
<daniels> i'd forgotten how much building the fonts sucked
<daniels> (ironically, the bug I was fixing was in building Xprint -- go figure)
* Amaranth doesn't know why that's ironic
<Amaranth> but let's pretend i laughed
<daniels> because I've been working on killing Xprint, and did in Ubuntu
<daniels> and now we get xorg into Debian, the first bug I have to fix is about XPrint
<Amaranth> heh
<Amaranth> can't kill Xprint in debian?
<daniels> no, sadly
<daniels> can't make the same kinds of arbitrary decisions I can in Ubuntu
<daniels> even though it's only semi-arbitrary (it really, really sucks)
<Amaranth> Why is it needed then?
<Burgundavia> daniels, that is simultaneously the biggest flaw and the biggest asset of debian
<Amaranth> Burgundavia: a fiefdom?
<Burgundavia> not being able to make arbitrary decisions
<Amaranth> that's because it's a fiefdom though
<Burgundavia> not really
<Amaranth> well, maybe not in this case
<Amaranth> but if i own a package i can shut down anything you'd ever want to do with it
<Amaranth> which is great but also awful
<Burgundavia> yes
<Burgundavia> more group ownership is needed
<Amaranth> need some way to override package owner
<daniels> Amaranth: xprint isn't needed at all -- hence why it's not in ubuntu
<Amaranth> daniels: someone somewhere _might_ want it so it stays in debian?
<daniels> pretty much
<fabbione> infinity: you around?
<daniels> infinity: nevermind, just realised the binaries need NEWing.
<\sh> wow...what gras did daniels smoke when god created xorg?
<tepsipakki> who is hosting backports.ubuntuforums.org? it seems to be down
<\sh> tepsi: we don't have to do anything with bugports..please ask on this forumwebpage
<Burgundavia> or in #ubuntuforums
<daniels> \sh: hm?
<Lathiat> heh bugports
<\sh> daniels: the comments are quite weired...flying cars, largest binary ,-) looks like my "koelsch" moved into your finger ;)
<\sh> and now I'm searching the ip address of the netapp
<sivang> moring all
<sivang> morning, even
<Simira> morning
<fabbione> infinity: piiing?
<daniels> \sh: they probably make more sense if you're a native English speaker
<ogra> http://www.ubuntuguide.org/#changeportnumberapache
* ogra scratches his head
<ogra> morning
<Burgundavia> ogra, it is the ubuntuguide, what do you expect?
<ogra> heh
<Nafallo> ogra: morning :-)
<sivang> morning ogra 
<ogra> Burgundavia, but thats information i really wouldnt expect there....and i'm wondering about the usecase...
<Burgundavia> someone needed it
<ogra> heh
<Burgundavia> some it got rit
<Burgundavia> so it got rit
<fabbione> infinity: unping
<\sh> daniels: can be
<ogra> "Usually when I fill crap bug reports, Sbastien is there
<ogra> to correct me, maybe he sent you ?! ;o)"
<ogra> LOL
<ogra> ubuntu-users is to funny today ...
<\sh> ogra: dilys is for malone what?
<ogra> \sh, did you already meet her ?
<ogra> \sh, /join #ubuntu-bugs and wait....
<ogra> she tells you nice things about new bugs ;)
<\sh> ogra: wonderful...red hair, green eyes and reporting new bugs..she's married? ;)
<ogra> \sh, dunno, kiko knows her personally, but i heard she looks very good *g*
<Simira> \sh : to malone, maybe?
<ogra> yeah
<ogra> heh
<jsgotangco> hmm
<ogra> seb128, sad, now i have to qoute again, didnt know you werent here yet
<ogra> "Usually when I fill crap bug reports, Sbastien is there
<ogra> to correct me, maybe he sent you ?! ;o)"
<jsgotangco> lol
<seb128> ah ah
<seb128> who said that ?
<ogra> seb128, vincent trouilliez in ubuntu-users ;)
<jsgotangco> oohhh
<\sh> wonderful
<ogra> ivoks bashed him a bit because he expected a bug to be fixed after 3 days, that was his answer....
<\sh> I'm deleted all my effords to build ace for gcc4
<\sh> s/ed/ing/
<ogra> \sh, nothing at redhat ?
<daniels> seb128: i think you need to be more nice to our users
<\sh> ogra: debian maintainer is working on new packages with new upstream
<ogra> \sh, so with luck we get them into breezy then...
<\sh> ogra: but he's busy now, cause he's moving from a to b next to c and doesn't have time to work on it
<\sh> and ace is a piece of package crap...
<ogra> hmm, we should have better local presence... then we could just send out a team of MOTUs doing the moving and he could fix the package *g*
<\sh> ogra: not a bad idea..MOTUSports will be created ,-)
<ogra> hehe.... but with a big note that it is not about sports games :)
<jsgotangco> awww
<jsgotangco> *snaps fingers*
<seb128> daniels: he, I'm nice with users!
<daniels> seb128: apparently not :P
<seb128> bah, this guy ... :)
<daniels> seb128: really I love you
<daniels> seb128: i just also want my panel to work
<seb128> the issue is still here with the current version and dropping the .session ?
<daniels> haven't seen it in a while, to be honest
<ogra> Burgundavia, thatnks for closing the backports bug for me :)
<Burgundavia> ogra, np
<Burgundavia> ogra, I like to stomp on backports users filing bugs, it is fun!
<ogra> heh
<seb128> daniels: ah, nice
<ajmitch> hi
<ogra> hey ajmitch 
<seb128> daniels: "/usr/bin/xvfb-run: line 146: Xvfb: command not found" ... is that a xvfb bog, or just me using it wrong ?
<sivang> seb128: any news from jamesh ? He hasn't responded to my email yet
<seb128> sivang: nop
<seb128> jamesh: ping?
<ajmitch> seb128: you asked if I was here, a number of hours ago?
<seb128> ajmitch: yeah, I don't get what you synced from Debian for anjuta
<seb128> ajmitch: according to the diff, nothing out a changelog entry
<ajmitch> let me check, I did a few of them quite awhile ago
<seb128> s/a changelog/of a changelog/
<ajmitch> seb128: right, so the changes should have been dropped, my mistake
<seb128> ajmitch: k, so I can ask a sync, thanks
<daniels> seb128: gnar
<daniels> seb128: i mean, that's really awesome
<seb128> ?
<daniels>   * Add proper paths to xvfb-run (thanks, Sbastien Bacher).
<daniels> your name's correct, yeah?
<seb128> yep
<seb128> thanks :)
<daniels> word
<Amaranth> does IRC not allow  in NAME?
<Treenaks> Amaranth: no
<Amaranth> oh, it's USER
<Amaranth> but yeah
<sivang> has anyone seen pitti ?
<ogra> sivang, he's in HEL
<ogra> sivang, only around for short periods from time to time
<Burgundavia> ogra, your answer was very word
<Burgundavia> y
<ogra> Burgundavia, yes, it starts to annoy me...
<Burgundavia> but you got the info across, so that is all that matters
<Burgundavia> been thinking about the ubuntu device database UI
<Burgundavia> the first page could use some help
<ogra> yes
<Burgundavia> should I file bugs or just email you?
<ogra> file bugs... i'll start the new client soon and grab them all to work along
<Burgundavia> cool
<daniels> seb128: p.fd.o: http://blogs.sun.com/roller/page/alanc?entry=can_gnome_startup_time_be
<daniels> HOLY SHIT
<daniels> seb128: PLEASE PACKAGE COWBELL NOW
<daniels> seb128: http://www.more-cowbell.org/
<TerminX> is the alsa mixer settings not being restored on boot a known issue?
<sivang> daniels: phee, looks cool
<sivang> ogra: HEL ?
<ogra> sivang, debconf
<sivang> ogra: oh
<seb128> daniels: we use LDFLAGS optimizations for most of the GNOME packages
<seb128> daniels: and rhythmbox is better :p
<daniels> seb128: cool
<daniels> seb128: er, dude?  rhythmbox doesn't do tagging
<seb128> it does if you turn the configure option for that
<seb128> it's known to have some issues, but I'm considering turning it on and bugging upstream to get these issues fixed
<ogra> yay
<daniels> ah, crazy
<daniels> but cowbell is lovely anyway
<daniels> can we please have it? :)
<seb128> daniels: and the current Ubuntu version does audio CD recording :)
<daniels> come on, I fixed your xvfb-run bug in like thirty seconds
<daniels> seb128: awesome!
<ogra> daniels, put it on UiverseCandidates, we'll find a MOTU for it :)
<ogra> Universe even
<daniels> bah, it needs main lovin'
<daniels> hm
<daniels> apparently I had 30GB of hoary chroots
<thomasvs> anyone here have an idea why current hoary gtk-doc is back to accessing the network when building docs ?
<Lathiat> thomasvs: iirc it grabs some schemas or whatever their called
<Lathiat> for xml style stuff
<seb128> thomasvs: you have a DTD on http which is not listed by the local xml catalog?
<Lathiat> thats what i was trying to say
<thomasvs> seb128: well, it's one of our buildslaves, administered by someone.  does he need to install a dtd package ?
* Lathiat mumbles
* daniels stares at seb128.
<daniels> ------- Additional Comments From seb128@ubuntu.com  2005-07-12 10:46 UTC -------
<daniels> This bug is fixed with this upload which uses "Manuel Pages":
<daniels> are they from barcelona?
<seb128> daniels: hum, I kind of made a typo here :p
<seb128> the upstream version is correct :)
* daniels gets a vision of XvGetPortAttribute(3) going 'please, Mr. Fawlty!'.
<bob2> hahaha
<daniels> win 23
* Lathiat passes daniels a /
<ogra> win 23  ?
<ogra> is that catch 22 +1 ?
<Lathiat> ogra: he left out a / for /win 23 which in irssi take syou to window 23...
<highvolt1ge> or a dyslexic win32?
<Treenaks> highvolt1ge: no, it's an older version of win32
<ogra> from 1880 ?
<Treenaks> ogra: no, win16 is from 1990
<ogra> ah, yep, i forgot :) its so long ago
<Mithrandir> www/win 31
<Mithrandir> argh
* daniels applauds.
<ogra> heh
<Mithrandir> wpasupplicant fucks up my network here
<Mithrandir> when I'm doing large rsyncs
<Treenaks> Mithrandir: get ALL devs to fix it together!
<highvolt1ge> i find it nicer in irssi to press <esc>32 instead of /window 32
<Amaranth> * libbeagle, a C library for querying the beagle daemon.
* Amaranth dances
<azeem> highvolt1ge: eh, doesn't that jump to window 3?
<highvolt1ge> azeem: quite right. i only have a few windows (never been to 23 in irssi).
<azeem> I can access the first 20 or so via alt+[1-9]  and alt+[qwerty]  and so on
<daniels> right, that's what I do
<hughsie> ogra: ping
<bob2> then s-l, then through esp/xml-rpc
<ogra> hughsie, pong
<hughsie> ogra: nice one. I've added your prelim. man sgml pages to g-p-m last night, hope you don;t mind
<ogra> hughsie, not at all... i'll send you the update from the new package then
<hughsie> ogra, cool, agaist cvs. I re-organsied them a bit too
<ogra> hughsie, oki
<hughsie> they still say ogra@.... for debian, but makes them a bit more neutral if you know what i mean
<ogra> hughsie, feel free to wipe my name or debian from them, i really dont care ;) its only a manpage :)
<hughsie> ogra: no, credit's where credits due!
<ogra> heh, ok...
<hughsie> ogra: now, the complicated bit.
<hughsie> how do I add them into the makefile.am bit?
<hughsie> and the clean and distclean bits?
<ogra> hmm, good question... i do that in the package, never cared for manpages in Makefiles....
<hughsie> is that a rule, or a preference?
<ogra> but i guess something like docbook-to-man debian/gnome-power-preferences.sgml > \
<ogra>                         gnome-power-preferences.1
<hughsie> in Makefile.am?
<ogra> and a install -m 644 gnome-power-preferences.1 should do it
<ogra> hmm
<hughsie> if i was using a Makefile, i would agree, but makefile.am makes it more complicted
<hughsie> Would i use install-data-local: ?
<ogra> yep
<ogra> sounds good
<pef> hello
<\sh> hmmm....did anybody test todays breezy install iso?
<Kamion> not yet
<Kamion> broken?
<\sh> looks like...initrd-tools it stops at install stage
<Kamion> generally signals debootstrap failure, errors don't seem to be caught quite properly earlier
<Kamion> I'll sync up and have a look
<Kamion> which arch?
<\sh> i386
<Amaranth> wow, bram cohen's blog is awesome
<Amaranth> http://www.livejournal.com/users/bramcohen/
<pef> If I correct a bug in a package, then I upload it's source to revu, the .deb will be automatically make ?
<pef> s/make/made/
<hughsie> ogra: gnome-power-manager.1: gnome-power-manager.sgml
<hughsie> 	docbook2man $? && mv gnome-power-manager.1 $@
<hughsie> ogra: easy when you know how!
<infinity> Ugh.  What's a polite way to say "your stuff is utter crap"?
<infinity> Also, -EWIN.
<infinity> Yay!
<Lathiat> "your stuff is utter crap"
<infinity> Lathiat : Thanks.
<Lathiat> no problems
<Lathiat> glad to be of service
<mdke> Mez, Seveas, ping
<seb128> kubuntu guys, any reason to not assign KDE bugs to kubuntu-bugs@lists.ubuntu.com ?
<Seveas> mdke, pong
<Mez> mdke: sup?
<seb128> that would make easier to list unassigned bug (debzilla ones)
<mdke> Seveas, Mez hang on one moment, i'll be with ya
<Mez> siretart: ping
<Mez> brb
<\sh> argl
<Seveas> \sh, is that a long argc?
<\sh> why someone is filing a bug for a main package in malone 
<Seveas> :)
<Seveas> \sh, because the whole main/universe and bugzilla/malone separation is not intuitive and not clear for new users
<\sh> yeah...and I'm uploading main stuff cause I'm thinking it's universe stuff.../me is a noob too
<Seveas> :)
<\sh> lets see
<Mez> siretart: ping
<\sh> if malone is so nice...I can click here and have a new bug in bugzilla??
<Mez> and mdke: repong
<mdke> Mez, Seveas, have a read of this: http://ubuntuforums.org/showthread.php?t=47739
<Mez> #FYI: Seveas wrote the guidelines
<mdke> ????
<mdke> this is not about blame
<Seveas> mdke, the forums people like to separate themselves from the rest of the community it seems
<mdke> Seveas, i disagree
<Seveas> using their own wiki section for instance
<mdke> it is up to us to integrate
<mdke> Seveas, that wiki section was designed by Henrik and the docteam together with the forum moderators and users
<mdke> it is a good initiative
<\sh> anyone with main rights: https://bugzilla.ubuntu.com/show_bug.cgi?id=12631 can u do the fix..it's trivial and upload?
<Mez> mdke, we're working on our own guide - but - I have no problems with UbuntuGuide - I direct people to there.
<bob2> wow, way to fly off the handle
<Seveas> mdke, I don't think having a separate wiki section is a good idea, why not just use the wiki as is?
<\sh> i included the debdiff..so it's easier for u :)
<mdke> Seveas, there are good reasons, I'll point you to them in a sec
<Seveas> mdke, please do
<Seveas> Mez, a new guide won't be that useful
<mdke> no
<Seveas> since docteam is working on things like that
<mdke> we need to aim at integration rather than the opposite
<Seveas> indeed
<Mez> Seveas ;D I know that -wich is why we'll be working with the docteam :D
<bob2> so doc unification is still going to happen?
<bob2> good work guys :)
<siretart> Mez: pong
<Seveas> bob2, afaik the docteam is working on this
<Mez> siretart: I need to send you a new public key for REVU - my comp went kaboom and I lsot all my data - had to make a new key
<bob2> Seveas: yeah, but then there's the wiki people, and now it seems the forum people, in addition to using the forums to publish documentation, have their own wiki corner
<mdke> Seveas, http://ubuntuforums.org/showthread.php?t=33898&page=1&pp=10
<siretart> Mez: boy, you better make backups. your key is important, man
<bob2> Mez: did you have a revokation cert?
<Mez> siretart : my gf wiped my USB key with my backup on.
<mdke> bob2, the forum section on the wiki is in order to allow forum users who do not necessarily know how to use the wiki to paste information, which then gets integrated into the main wiki
<mdke> that is the plan
<Mez> bob2, yes with the backup :'(
<siretart> Mez: so, go on, revoke your old key and send me a new one
<bob2> Mez: before you send anyone else your new key, go print the cert out
<siretart> b
<Mez> bob2 - I'm sorting backups etc etc etc out wight now :D
* Seveas has 3 backups of his gpg+ssh key
<Seveas> all in cryptollops on different servers
<Seveas> cryptoloop*
<siretart> lets please move to #ubuntu-motu
<mdke> Mez, Seveas, we can move to #ubuntu-doc if you like
<Kamion> \sh: chage: can't open shadow password file
<Kamion> \sh: that seems to be what's killing it
<ogra> Mez, burn your key on a CD and lock it away anywhere.... if its signed once, you dont wanna loose it ever again, its hard to get all the signs again
<Mez> mdke - #ubuntu-nun
<Kamion> and indeed, there's no shadow password file
<\sh> Kamion: ah..good to know...I wasn't sure if it was something with my virtual machine
<Mez> ogra: I know that now :D had Phil and Riddell Sign it- I dont anymore :D
<Kamion> that should be impossible though, base-passwd configuration is supposed to create /etc/shadow
<ogra> \sh, djvulibre ftbfs on amd64
<\sh> ogra: hmm...ubuntu1 not...strange
<mdke> Mez, *sigh*
<\sh> ogra: logs?
<ogra> GString.h:163: error: expected ',' or '...' before '&' token
<ogra> GString.h:163: error: ISO C++ forbids declaration of 'GBaseString' with no type
<\sh> hahahaha
<\sh> ogra: will take care about it...moment
* Mez is going to burn his whole stuff to a DVD
<\sh> oh man...sometimes internet is difficult
<mpt> \sh: Keep trying, eventually you'll beat it
<mpt> \sh: The big monster at the end is hard, though
* \sh is running with his sword towards the end of the internet....he can see the dragon...spitting fire..but \sh will do his job...customer^Wdragon killed...you gained 99999999 Exp for this. You reached Gods Level.
<\sh> And now I can explain him how the DNS works..
* \sh needs a new job
<ogra> ha ha
<ogra> i thought you love it ?
<ogra> *g*
<\sh> I love my tru64...I love my solaris, I love my linux, even windows I will love, if there is no call center who will bug me with questions like "The customer said, that his domain moved since last week to a new IP address, but he can't reach it.." Yes, dear call center and customer, you should choose the right provider...a provider who knows how to update a domainname zone...first thing: increase serialnumber, second thing: don't use confixx
<ogra> heh
<\sh> I should test setop box software or byting smartcards...
<\sh> ogra: https://bugzilla.ubuntu.com/show_bug.cgi?id=12631 <- new diff please test :)
<ogra> i'll do
<\sh> thx
<netdur> people, see this http://www.netdur.info/tmp/SagatOnAction.png
<netdur> its something I'm developing for ubuntu... I could make it run for first time today
<Amaranth> err
<Amaranth> what does it do?
<netdur> bash glade wrapper!
<Amaranth> o_O
<netdur> you don't think it's cool? shell scripts have GUI?
<\sh> yeah..it's called VisualBasicScript
<ogra> nope, its called zenity
<JaneW> who deals with blender?
<schweeb> netdur: use perl or python or any other scripting language that has gnome/glade/other gui  bindings
<ogra> JaneW, MOTU ?
<JaneW> and more specifically a python interface to belnder
<JaneW> blender
* JaneW fwds mail to ogra... (i.e. the default) ;)
<ogra> hmm, we could aks ajmitch 
<ogra> hehe
<ogra> oki
<Amaranth> netdur: It's a neat hack, but I don't see much of a use for it.
<netdur> Amaranth, imagine all scripts in ubuntuguide.org have GUI
<Amaranth> anytime you need a GUI the overhead from running python or something instead of bash isn't worth much
<ogra> netdur, thats easy done with zenity, whats the advantage of our wrapper ?
<ogra> your even
<netdur> zenity do dialogs only
<netdur> mine let you use glade
<ogra> ah
<ogra> ok, that makes a difference...
<Amaranth> hmm, odd
<Amaranth> GtkFileChooser is showing my empty cdrw drive, my floppy drive, and ld-linux.so.2 as shortcuts in the left list
<netdur> ogra, "our wrapper"!!! are zenity you developer?
<ogra> nope, it was a typo ;) 
<ogra> i meant your wrapper
<netdur> okay
<Amaranth> wtf
<Amaranth> when can root not overwrite a file?
<seb128> Amaranth: ?
<Amaranth> oh, when the dir is marked read-only
<mr-russ> Amaranth: when +i is set.
<torkel> Amaranth: when writing on a nonlocal filesystem
<mr-russ> chattr.
<bob2> when the disk is screwed
<Treenaks> or a combination of the above
<\sh> JaneW will become a MOTU?
<\sh> or did I understand something wrong? ,-)
<JaneW> \sh LOL
* JaneW gets out whip...
<JaneW> that's me 'Mistress Of The Universe' ;)
<\sh> oh uh....don't do it...I like it ,-)
<ogra> LOL
<ogra> JaneW, you know such names have glue on them ? 
<ogra> and they get stick very fast :)
<ogra> sticky
<JaneW> ogra: *grin*
<Amaranth> you mean you think we're all going to call her mistress now?
<\sh> JaneW: welcome on board :) i think dholbach will write a nice announcement
<ogra> yeah
<Amaranth> nah, i'd never call mistress that
<Amaranth> err
<Amaranth> JaneW: 
<JaneW> no  no ... I'll leave the leather pants to you guys... ;)
<\sh> Amaranth: actually, we know our new mistress likes kids...so we're the best community for her at all ;)
<Amaranth> lmao
<Treenaks> JaneW: \sh is german... Germans like leather pants
<\sh> hahahha
<ogra> *grin*
* JaneW smiles at ogra
<\sh> only bavarian guys..and bavaria != germany and munich is not the main capital of germany ,-)
<ogra> munich is outer space
<Treenaks> \sh: I heard it's that way in/around Leipzig as well
<\sh> oh yeah and ogra likes some special kind of leather pants :) 
<Treenaks> \sh: and Leipzig != Bavaria
<\sh> leipzig?
<\sh> that's behind the wall...,-)
<Treenaks> \sh: so?
<ogra> Treenaks, way more south
<ogra> Treenaks, nearly bayern ;)
<\sh> I've never been to the eastern part of germany...it's a black hole on my map of germany
<Amaranth> damnit
<Amaranth> i spent the money for harry potter on my domain name
<Amaranth> stupid domain name
<ogra> \sh, its really beautiful
<\sh> ogra: yeah...I want to go to Usedom someday...
<Treenaks> \sh: maybe because of your age :P
* Treenaks is going to Berlin in September
<Treenaks> \o/
<\sh> Treenaks: honestly speaking: it was a real problem for me to accept this change in our (german) history...but finally, I know now some really nice people out there :)
<ogra> Treenaks, helping dholbach to find a flat ?
<\sh> Treenaks: really? when? beginning or end of septembre?
<Treenaks> ogra: well no.. but he said he'd be there in the same weekend
<Treenaks> \sh: very beginning (3-6)
<Treenaks> ogra: and maybe sivang too
<\sh> wooo...I know where I'm staying some days :)
<ogra> Treenaks, yes, i heard sivang wants to visit germany
<\sh> Treenaks: I have some free days, 14 days actually
<Treenaks> mini-meet! ;)
<\sh> mini-meet with mini-meat? :) currywurst ,-)
<Treenaks> \sh: und Bier :)
<\sh> Treenaks: hehehe...for sure...and I think dholbach will join and forget his move easily ,-)
<Treenaks> \sh: ;)
<\sh> ogra: think u have to visit berlin as well ;)
<ogra> \sh, unlikely
<ogra> \sh, you dont know dholbach :)
<\sh> ogra: so expensive?
<Treenaks> ogra: what's unlikely? the forgetting or the visiting part?
<ogra> \sh, yes, i'll have to... my best friend lives there, but we didnt meet for 7 years now
<ogra> Treenaks, the forgetting
<Treenaks> ah :)
<\sh> ogra: so this is setteled
<\sh> ogra: so..we need a barrel?
<ogra> but i doubt edubuntu will leave me time for travelling before release
<Treenaks> \sh: yes, but which day (I want to do some touristy things as well, such as walk around on the Pariser Platz etc.
* ogra was last time in berlin when christo wrapped the reichstag
<\sh> Treenaks: i will join u...the last time I went to berlin, it was 1995
<\sh> Treenaks: and I didn't see anything only the fair and a austrian restaurant next to our hotel...and from those tourist things I saw only the girls from the hostess services which were booked by the fair administration
<\sh> so berlin is a black hole, too
<Treenaks> \sh: let me guess, inside the hotel room?
<\sh> Treenaks: no...there was a party sponsored by fair administration...
<Treenaks> \sh: ah ok
<\sh> Treenaks: ah...*ping* now :) sorry...I think hostess services is the wrong word
<Treenaks> \sh: well, I really want to see the "landmarks", and just walk around aimlessly ;)
<pef> could someone have a look to http://siretart.tauware.de/revu/details.py?upid=118 please , thanks !
<trulux> pitti: heya
<trulux> pitti: how's debconf5?
<pitti> trulux: great
<Amaranth> pef: wrong channel :)
<trulux> pitti: tell us :D
<pitti> trulux: many people, nice uni and nice wheather
<pef> Amaranth: #ubuntu-motu is more adequate ?
<trulux> pitti: take photos :)
<Amaranth> pef: yeah
<pef> ok ;)
<pitti> trulux: I have been very lazy wrt taking photos so far, but I'll do some :-)
<trulux> pitti: I have some of LSM 2005
<trulux> http://pearls.tuxedo-es.org/photos/lsm-2005/
<trulux> pitti: http://pearls.tuxedo-es.org/photos/lsm-2005/img030.jpeg.html <- Misery Bar :D
<trulux> pitti: http://pearls.tuxedo-es.org/photos/lsm-2005/img042.jpeg.html <- on the police station building wall :)
<trulux> doko: hey
<trulux> doko: SSP got mainline
<trulux> doko: now we don't have reasons to be against it's deployment
<trulux> pitti: did you know such great news?
<pitti> trulux: SSP is in gcc head now?
<pitti> coool
<Treenaks> what's SSP?
<pitti> Treenaks: compile-time stack buffer overflow protection
<Treenaks> pitti: cool
<pitti> Stack Smash Protector IIRC
<trulux> pitti: yeah, lemme get you the link
<trulux> just a sec
<trulux> pitti: http://gcc.gnu.org/ml/gcc-patches/2005-07/msg00069.html
<trulux> pitti: libssp is now Red Hat's approach too
<pitti> trulux: that's just great news - apparently there's both ssp and fortify
* pitti pokes doko to package it :-)
<trulux> pitti: I'm also going to send the bounty prop. as soon as I finish a patch for SELinux I've been working for a month or so
<trulux> pitti: also I hope to work on some vsec stuff and contact back the dude from Singapore who was working on some vsec improvements
<seb128> cool, wxwidgets2.6 has been uploaded to Debian
<ogra> yay
<ogra> i just talked to JaneW about SPE packages.....
<luis_> spe?
<ogra> they are lying on my disk since ages... waiting for wx 2.6
<ogra> luis_, a python IDE
<seb128> luis_: is libgnomeservice something that should be packaged now?
<ogra> with obviousy great blender support
<luis_> seb128: I didn't get a chance to build it last night
<luis_> seb128: so I can't say
<seb128> luis_: k
<seb128> luis_: if that's something we want to consider for GNOME 2.12 I'll put packages with a patched gnome-session on my webpage
<luis_> seb128: it certainly resolves a big management problem
<luis_> in that it (in theory) allows you to drop one file in one place and get it started with the session
<luis_> which gnome has (pathetically) never really supported
<seb128> luis_: yeah, I know, that would be great for distribution for stuff like update-manager
<seb128> luis_: just have to ship the .desktop with the package
<luis_> yup
<luis_> yupo
<Firetech> I just found a thing that would be great for newbies if it came with ubuntu by default... GNU Source Installer: http://www.gnu.org/software/sourceinstall/
<luis_> so it seems like if rodrigo thinks that it will be ready for that purpose, you guys might want to consider shipping it regardless of whether or not it is officially in 2.12
<seb128> luis_: right
<seb128> I'll ping jdub about this
<carstenh> Firetech: and who patches it to generate packages and call dpkg -i packagename?
<Firetech> carstenh: it is made to have it's own source "repository", it doesn't have to use .deb's
<Firetech> That would be a good idea though... patch it to use checkinstall or something...
<carstenh> Firetech: i don't think encouraging newbies^someone to install software without using the package-system provided by the distribution they use i a good idea
<infinity> Firetech : I'm not sure how "tool to manage compilation and installation of source packages" could ever possibly be "a good thing to include by default for newbies".
<infinity> Firetech : We provide a binary packaged system that Just Works specifically so users DON'T have to do this.
<infinity> (not that it isn't perhaps a cool tool/idea, and something I'd like to see tossed in Universe)
<Firetech> infinity: there are packages that arent in the repositories...
<carstenh> Firetech: and newbies don't knbow them normally
<infinity> Firetech : Yes, there are, and having a tool in main, installed by deault, that encourages users to install those source packages is NOT a good idea.
<\sh> Firetech: you're invited to join MOTU and help us to increase 15000 packages to the highest ammount ever
<infinity> Firetech : It's unsupportable, and can lead to serious breakage.  But it would be a great tool in Universe.
<carstenh> Firetech: as infinity already siad, it may be usefull in universe
<\sh> infinity: what tool do u mean? portage is for gentoo ,-)
<Firetech> \sh: I haven't learnt myself how to make deb's without an existing debian folder yet :/
<\sh> Firetech: well...dh_make :) helps and #ubuntu-motu :)
<pef> Firetech: they are very cool ;)
<Firetech> pef: the MOTU guys?
<\sh> yes we're 
<Firetech> :P
<pef> Firetech: yep, very helpfull with beginners
<infinity> Much more so than grumpy people like me, I'm sure. :)
<Firetech> sourceinstall is more a cool idea than a tool, because it's not very nice to look at ;)
<infinity> GNU is not known for their pretty GUIs...
<\sh> infinity: u would make a really good MOTU :) and with JaneW as Mistress Of The Universe...those whip producers will increase their income easily ,-)
<Firetech> it works pretty well and has a GUI control for the ./configure phase
<ajf6> just look at their website
<infinity> Though, others have been known to take GNU tools and make them look less crap.
<Firetech> :)
<\sh> autoconf/automake as an example ;)
<Firetech> how do I know if a packagse shopuld be single or multiple binary?
<Firetech> *should
<ajf6> multiple binary will set you up to generate several packages
<infinity> Firetech : If it's a client/server that should be logically split up, if it's a binary and libraries that should be split up, blah blah.
<ajf6> for something like SSH, it'll do ssh-client and ssh-server debs
<infinity> Firetech : If there are multiple libraries that don't share a common SOVERSION, always split them up (or you'll end up having to do so later, with much hassle)
<Firetech> it's for sourceinstall, I don't think it has anything else than one binary and a symlink to that binary
<infinity> Well, then it's pretty obviously a single binary package.
<Firetech> what is a multi binary package then?
<infinity> One source package that produces multiple binary (.deb) packages.
<infinity> Linke, mysql-dfsg produces mysql-server, mysql-client, libmysqlclient12, mysql-common, etc.
<infinity> (For instance)
<infinity> s/Linke/Like/
<Firetech> aha
<Firetech> ok
<Firetech> what file contains the dependencies?
<Firetech> nm, found it
<infinity> Note that you shouldn't hardcode dependencies on libraries, dpkg-shlibdeps will magically figure those out for you at build-time.
<Firetech> it depends on some packages that it doesn't seem to find...
<Firetech> "expectk" is required and "ncompress" is recommended
<infinity> Oh, yeah, it won't magically find non-library packages.  Those, you need to specify. :)
<Firetech> didn't read your post correctly :P
<Firetech> how do I know if it needs some more packages?
<Firetech> I need to get a clean chroot, right?
<\sh> Firetech: http://wiki.ubuntu.com/PbuilderHowto
<infinity> Ideally, you should try building in a clean chroot (to get the build-deps right), then installing/running in a clean chroot (to make sure the deps are alright)
<infinity> You can use pbuilder for the former, but it's not so easy for the latter.  I prefer to just debootstrap a chroot to work in.
<infinity> bindmount /tmp into your chroot, and you can run X apps in the chroot, connecting to the X server in the base system.
<Firetech> well... sourceinstall doesn't require much building... make didn't do anything...
<Lathiat> fabbione: is it ok to file bugs for 2.6.12
<Lathiat> mjg59: this is relevant to you too, my usb stops working when i suspend (worked in .10 and i think earlier.12) 
<mjg59> Lathiat: Hmm. Ok.
<nomed> hi .. just a question
<nomed> why alsaconf is not in hoary ?
<Lathiat> whoah
<Lathiat> or not
<Lathiat> thats fully weird
<Lathiat> specifically my wireless mouse dongle doesnt work
<mjg59> Ha
* Lathiat uh
<mjg59> Interesting
<Lathiat> if i reboot.. it works
<Lathiat> let me try that agian.. brb
<Lathiat> it just doesnt show up in dmesg at all
<Lathiat> the other stuff does tho
* Lathiat puzzles
<Lathiat> and i tried swapping ports
<Lathiat> mjg59: might have something to do with usb1.1 vs usb2.2
<Lathiat> s/2.2/2
<Lathiat> cus it works after reboot
<Firetech> how much space should I make for a clean hoary chroot?
<Kamion> about 350MB for base system, plus whatever development packages and scratch space for building things you think will be necessary
<Lathiat> mjg59: yeh that would seem to be th emagic
<Lathiat> mjg59: if i plug it into my usb hub, which come sup under ehci (rather than uhci)
<Lathiat> mjg59: it then works (and ehci reports the mouse too)
<Lathiat> mjg59: if that helps..
<Firetech> Kamion: about 500 then?
<mjg59> So it works with the hub, but not with the internal sockets?
<mjg59> Weird
<Lathiat> mjg59: yeh, on the internal sockets
<Lathiat> uhci seems to handle it
<Lathiat> perhaps cus my dongle is usb1.1 where as my hub is usb2 and ehci handles that
<Lathiat> not that i know the difference between ehci and uhci
<Lathiat> but if i plug the usb1.1 mouse dongle into the usb2 hub it comes up as low speed under the ehci driver
<Lathiat> so assumedly the uhci driver is going splat
<mjg59> Ok, so run this past me again
<mjg59> If you suspend/resume, it only works if it's plugged into the hub, not the internal sockets?
<Kamion> Firetech: really just depends on how much you're going to do in it. My Breezy development chroot on this machine is 1.7GB, but I did an LTSP chroot build inside that ...
<mjg59> If you rmmod/modprobe uhci-hcd, does it redetect it?
<Firetech> infinity: you said something about bindmounting. how to do that?
<Firetech> Kamion: It's LVM, so it doesn't really matter right now ;)
<Lathiat> mount -o bind /source /target
<Lathiat> mjg59: yep
<Lathiat> mjg59: so uhci driver is just broken on mjy hardware and not re-initing after suspend properly
<Lathiat> fairly sure it worked in .10 and earlier 2.6.12, i can test that later on if you like
<Lathiat> fwiw, im suspending to ram
<jbailey> Kamion: ping?
<Kamion> jbailey: pong
<jbailey> Kamion: Where's the best place to report the an install from last night's daily on i386 fails for me?
<Firetech> should I use "--variant=buildd" for debootstrap if I plan to use it to check build-dep's and dependencies for new deb's?
<Kamion> jbailey: under "known bugs"? :-) Did it fail on debootstrap?
<jbailey> Configuring 'base-installed' failed with error code 1
<jbailey> So probably.
<Kamion> Firetech: you can if you like but it doesn't really matter, just install build-essential after building the chroot
<Firetech> okidoki
<Lathiat> i wish what ever writes to .xsession-errors wouldnt stop logging 
<Kamion> jbailey: right, I think my shadow merge should've fixed that, I'm just waiting for cron.daily to build a new set of CDs
<Lathiat> when too much data is in there
<Lathiat> wonder if i can change that
<Kamion> jbailey: not 100% sure though
<Kamion> jbailey: it's down to adduser now requiring /etc/shadow to be present
<infinity> <blink>
<infinity> And why on earth does it do that?
<infinity> Systems without shadow passwords are perfectly valid.
<jbailey> Kamion: Ah, cool.  Do we really produce new CDs at each cron.daily run? 
<jbailey> (Isn't that like 24 times a day)?
<Lathiat> cron.daily is daily... once a day.
<Kamion> jbailey: no no, I meant "I'm just waiting for cron.daily before I build a new set of CDs"
<infinity> No, the daily cron.daily, not the katie cron.daily. :)
<Lathiat> cron.hourly is hourly
<Kamion> Lathiat: not on the archive it's not
<Lathiat> Kamion: ah
<Lathiat> who thought of that up?
<jbailey> Kamion: ah, okay. =)
<Kamion> Lathiat: it's cron.daily in Debian; we run the same things more often
<infinity> Lathiat : The Debian archive runs certain tasks in cron.daily.  Ubuntu does it more often, but the nomenclature stuck.
<Kamion> Lathiat: if you like, you can look at it as a 30-minute-long day
<jbailey> Kamion: Anything I can usefully help with?  I'm getting lvm on my laptop so that I can beat it with initramfs.  Otherwise I can go onto another task until the next dailies show up.
<Kamion> well, on this particular task, a debootstrap of really-really-current breezy from after the next archive.ubuntu.com pulse would be a good check, I suppose
<Kamion> I should start switching d-i over to initramfs
<jbailey> Kamion: I can easily do ppc or ia64.  My i386 breezy laptop needs to wait until it works before I get much further. =)
<jbailey> Unless there's a netinst option on the CDs that I can use?
<Kamion> there are netboot mini.isos
<jbailey> Ah, cool.  I hadn't seen those in the daily list.
* jbailey remembers that he has to update the miniisos in Debian for a few archs too.
<Kamion> infinity: it calls chage to fiddle with password expiry; password expiry information is only stored in shadow
<Lathiat> Kamion: heh, 30-minute day :)
<Kamion> jbailey: they're only in the {daily-,}installer-* bits of the archive, not on cdimage
<infinity> Kamion : adduser has default password expiry now?
<infinity> Hrm.
<Kamion> infinity: no, it was a bug fix - apparently adduser --system accounts used to expire if you had password expiry set up
<lamont__> daniels: ping
<Kamion> infinity: so adduser --system now cranks the expiry time back up
<infinity> Kamion : But this means that adduser now depends on shadow always being enabled.  What happens in the case when a user explicity disables shadow passwords?.. adduser just blows up?
<lamont__> Lathiat: more to the point, the name of the katie script that debian runs every day is 'cron.daily'
<lamont__> and that script runs at :03 and :33
<lamont__> (in ubuntu)
<Lathiat> yeh, i got it :)
<lamont__> it's all part of ubuntu's secret to success... you see, with a 30 minute day, we actually release every 12 years, not every 6 months. :-)
<Kamion> infinity: I think chage is being fixed
* Lathiat grins at lamont__ 
<infinity> Kamion : Before we release? :)
<Kamion> infinity: hope so :)
<lamont__>  /usr/bin/ld: cannot find -lssl3
<lamont__> bad thundermug
<fabbione> hey lamont
<lamont__> sim?>
<fabbione> lamont__: i got willy to install the packages i needed in the breezy chroot on f11
<fabbione> but there is some gcc screw up
<lamont__> you mean like gcc not being in the archive yet for breezy/hppa?
<fabbione> it looks like gcc-3.4-hppa is completely missing all the new -gnu- symlinks
<fabbione> apparently all the B-D are there...
<lamont__> well, it _is_ a hoary gcc-3.4-hppa64....
<fabbione> dpkg-buildpackage doesn't complain
<fabbione> did add pinpoint to hoary?
<fabbione> (i didn't check personally)
<lamont__> pretty sure it's fixed in the current gcc-3.4
<fabbione> and that's not uploaded yet...
<lamont__> the USB disk my full archive was living on died last night (need to investigate that...)
<lamont__> fabbione: the current gcc-* in the archive are all either dep-wait or ftbfs
<fabbione> ah
<fabbione> ok
<lamont__> but we now have xorg there, so we can build gcc-4.0
<lamont__> and 3.4
<fabbione> lamont__: as a workaround, can i get kernel-wedge 2.0 in the hoary chroot?
<fabbione> lamont__: up to you the way you prefer...
<fabbione> i can wait 
<lamont__> can I bother with it tonight/tomorrow?
<lamont__> (12-36 hours from now, that is)?
<fabbione> 2.6.12-4.4 builds fine.. i only need to che udebs creation
<fabbione> sure.. 
<fabbione> lamont__: i really have no rush :)
<lamont__> you know, we could use -4.1 :-)
<lamont__> hrm.. or maybe we can't.
<lamont__> nm
<fabbione> no we can't :)
<fabbione> don't confuse the ABI with the version....
* fabbione run away screaming because people don't know what abi is in the kernel
<fabbione> so i just keep incrementing the last one...
<lamont__> hehe
<fabbione> and we don't have to make extra branches :)
<fabbione> baz is slow enough for what we have
<lamont__>  /build/buildd/pike7.6-7.6.27/src/interpret.c:1287: error: PIC register 'ebx' clobbered in 'asm'
<lamont__> SCORE!
<fabbione> lamont__: we should also look at the linking with gcc problem when you have time and NOT today...
<fabbione> and see why it creates non-PIC code when not using ld
<fabbione> but that part of the toolchain is really a black hole for me
<lamont__> sure - np
* fabbione will wait for lamont to cut his veins and start painting walls with blood after looking at that Makefile mess
<lamont__> donde esta elmo, huh?
<fabbione> .fi? ;)
<lamont__> fabbione: tell me that jbailey didn't write _those_ makefiles too!??
<fabbione> oh no.. he did try to help me instead to clean them up
<fabbione> that's why i know that linking with gcc brings to non-PIC code :P
<lamont__> hrm.. not much fun trolling jbailey when he's not around
<fabbione> ehehhe
<jbailey> I'm like the moat monster.
<jbailey> You can never tell when I'm here.
<jbailey> iputils uploaded, patch sent upstream.
<fabbione> jbailey: i got iptables fixed this morning :)
<lamont__> basically, if you can make it say 'gcc -shared' instead of 'ld -shared', with -Wl, in front of the linker specific opts for like soname, it should just DTRT
<fabbione> lamont__: that's what we did...
<fabbione> and it didn't DTRT
<lamont__> fabbione: yeah.  hrm.
<lamont__> iz gtk bug
<fabbione> lamont__: ehehhehe
<jbailey> fabbione: Thanks.
<jbailey> fabbione: That was going to require a serious infusion of vodka.
<fabbione> jbailey: no problem...
<jbailey> (Which I will provide you with next time you and I should happen to have the occasion)
<fabbione> jbailey: no really.. i remember iptables is an interesting package...
<jbailey> Interesting like "May you live in Interesting times"
<fabbione> (no vodka for me..)
<lamont__> hrm... I wonder if it would be possible to isolate the C2H5 from the OH, and thereby avoid the PH issues that occur with excess C2H5OH intake...
<lamont__> that'd make fabbione happy, I expect...
<fabbione> jbailey: vodka for me is like garlic for vampires....
<jbailey> lamont__: If you can still do chemistry, you need to consume another sample.
<lamont__> or maybe jbailey.
<lamont__> reminds me of an old rumcake recipe.
<fabbione> hmm i am not too much into chem...
<fabbione> but that looks like alchool
<lamont__> c2h5oh == ethanol
<fabbione> close enough ;)
<fabbione> last time i opened a chem book was around 14 years ago
<lamont__> too much and you change the PH of your blood a bit more than the body likes...  and then there's the aldehydes that are created by the preferred metabolic path for dealing with it.
<Kamion> if it's still blood rather than blood-tinted alcohol, you're doing it wrong
<fabbione> Kamion: you mean that if you still have spurious traces of blood in the alchool you are not driking enough?=
<Kamion> right
<lamont__> actually, the highest BAL I've heard of was .55%, which was a _coherent_, angry man in the emergency room one night - he wanted to leave, was quite happy being a little bit drunk
<lamont__> very scary
<Lathiat> yeh my aunty works in the emergency department
<Lathiat> shes had something similar
<poningru> um dont you pass out way before that
<Lathiat> poningru: not if your a hardcore alcoholic
<lamont__> poningru: that's why it was scary
<poningru> wow
<lamont__> .25 is very serious 'acute poisoning'
<Lathiat> get to .7 or so and your dead
<poningru> yeah
* fabbione goes offline
<lamont__> otoh, I don't think this guy's BAL ever got _below_ .20
<poningru> how can the liver handle shit like that
<poningru> rofl
<Lathiat> poningru: it cant, he'll live a short life
<lamont__> liver? what liver?
<fabbione> cya tomorrow fellas
<Lathiat> exactly
<lamont__> actually - with extremely high loads like that, the body runs out of the preferred enzyme for digesting alcohol and goes down gentler paths
<lamont__> 20 years ago, the treatement for methonol poisoning was IV injection of ethonol
<lamont__> now there's a synthetic that has a high affinity for the enzyme, without the intoxicating side effects
<lamont__> (the preferred enzyme turns methanol into formaldihyde - which isn't really good for living tissue...)(
<Lathiat> heh heh
<lamont__> so the really scary part about this guy was that at .55 he was _COHERENT_
<Lathiat> yeh
<lamont__> hrm... OTOH, that's kinda more off-topic than normal
<tsume> why can't ubuntu's kernel load faster on startup like Fedora?
<tsume> Loading the kernel for Ubuntu takes _forever_ 2 lines of .'s
<tsume> while as I noticed fedora only loads about 6 dots before it starts loading. What is ubuntu building in the kernel which makes it so fat?
<Lathiat> anyone with xorg clue about?
<Lathiat> xnest is b0rk cus it cant find the fixed font
<Lathiat> assumedly it hasnt got an updated config.. wherever it gets that
<lamont__> Lathiat: assuming the fixed font is installed on the system....
<Lathiat> well, X wont start without it
<Lathiat> and my main X is running
* lamont__ has no clue, and his xorg-bitch is sleeping
<lamont__> (to use the technical term)
<jbailey> Lathiat: There was a problem with font paths awhile ago that caused startup problems.  Are you maybe seeing the same thing?
* tsume pokes mdke 
<tsume> oops
<Lathiat> jbailey: i think so but with Xnest as opposed to the main server
<mdke> tsume, y0
<Lathiat> jbailey: xnest says it has its own font paths in the man page
<Lathiat> so i assume its wrong somewhere
<mdke> ah np
<Lathiat> cant find where but
<tsume> mdke: sorry :P
<mdke> heh no problem
<tsume> mdke: I was going to poke mdz, but hes not here
<lamont__> tsume: gotta type _3_ characters before you hit tab... :)
<tsume> lamont__: =]  I knoq
<lamont__> hehe
<cartman> anyone having problems with latest udev on breezy?
<cartman> seems like cdrom/dvdrom devices no longer created
<hughsie> ogra: ping (got a minute?)
<ogra> hughsie, sure
<hughsie> ogra: cool, hi. I see mjg59 is about.
<hughsie> pitti said anything to you abou tthe daemon?
<ogra> hughsie, he wants to look at it if i made a package
<hughsie> gotcha.
<doko> ogra: how do I close a bug report in malone?
<hughsie> mjg59: ping?
<ogra> doko, this special case didnt occur to me yet :-P
<hughsie> also, ogra, what you guys think of libnotify?
<ogra> hughsie, i heard seb128 wanted to package it soon... havent looked at it yet
<hughsie> cool, i've just packaged it for FC4
<hughsie> reason: http://news.gmane.org/gmane.comp.gnome.powermanager.devel/cutoff=266
<hughsie> sorry, http://article.gmane.org/gmane.comp.gnome.powermanager.devel/266
<ogra> hughsie, looks cool :)
<hughsie> ogra: does looking cool justify a new dependency?
<ogra> i think so... but i'll have to discuss it with pitti again for the main inclusion then (i guess i'll have to do it anyway since so much changed)
<hughsie> sure, thanks. It's pretty modular, so if you start with pmscripts we can work from there
<hughsie> but then thats a mjg59 thing
<hughsie> PowerManager is a pitti thing...
<ogra> yep... main inclusion/security reviews too... libnotify would need a extra review...
<hughsie> ogra: sorry :-)
<ogra> seb128, do you plan the libnotify package you talked earlier about today for main inclusion ?
<ogra> oh, that was libgnomeservice , i muddled it...
<ogra> :(
<ogra> hey doko you stole my package... i'm just done with the djvulibre testbuild, grrr
<hughsie> does ubuntu have an extras equiv? what about putting it in "universe" ?
<ogra> hughsie, i cant depend on universe stuff with a package in main... i want g-p-m to be the default interface for our powermanagement... so it must be in main to enter the CD
<ogra> ...and its dependencys too
<hughsie> ogra: gotcha
<hughsie> ogra: nice one
<seb128> ogra: I've planed both
<ogra> seb128, yay
<seb128> libgnomeservice and libnotify
<seb128> and probably main both
<ogra> great
<hughsie> cool
<seb128> gnome-applets already has some code for libnotify
<ogra> saves me one extra main inclusion report :)
<seb128> and maybe gnome-session will use gnomeservice for 2.12
<hughsie> gnomeservice... hmmm... somebody got a url
<seb128> what about djvulibre?
<ogra> seb128, nothing... i'm fiddling on \sh's bug since this morning, every time my pbuilder has some time to build it... now doko just uploaded it.. just some lost time
<seb128> bah
<seb128> we want a new version for evince
<doko> ogra: it was a two character change ...
<hughsie> dinner calls, thanks guys.
<seb128> if somebody wants to ping the Debian maintainer
<ogra> doko, it was ftbfs on amd64
<doko> ogra: your bug again ...
<ogra> seb128, who ever touched it last ;)
<ogra> doko, btw, did you note the watches in 979 ?
<doko> ogra: yes, I wondered why I cannot click on it ...
<ogra> hmm, yes, you can only edit it... a direct link would be nice
<ogra> doko, btw, you can only colse bugs in malone if you're the asignee...
<ogra> i just checked
<sladen> mako: how the naach do you get a LINX t-shirt?
<Mirv> are there many ubuntu people at the debconf currently?
<Kamion> Mirv: a fair number, don't know exactly
<sladen> Mirv: for some value of 'many' the answer is probably yes
<Burgundavia> seb128, ping
<seb128> pong
<Burgundavia> did a patch get dropped with the new nautilus? My desktop icons showed up again
<seb128> since when?
<Burgundavia> reboot this morning
<seb128> and you have rebooted ... 6 months ago previous time?
<Burgundavia> no idea
<Burgundavia> 2.11.4, very odd
<seb128> not that odd
<seb128> but the previous changes are 10 days old or something like that
<seb128> have you restarted nautilus for 10 days?
<Burgundavia> just installed 2.11.4 yesterday
<seb128> yeah, but when have you restarted nautilus before ?
<Burgundavia> nope
<seb128> is this bug since yesterday, or could it be 10 days old but you have not restarted it before?
<Burgundavia> I suspect it is 10 days old
<seb128> bah, anyway the new hal code for gnomevfs use /system/storage/ gconf keys
<seb128> there is granularity on the volumes to list here
<seb128> maybe you want to change these keys with gconf-editor
<Burgundavia> I won't bother filing a bug unless I hear about someone else having the issue, cheers
<seb128> k
<seb128> anyway these keys are new, maybe we want to change some default here
<pitti> seb128: how did the cups-hal patch work out?
<seb128> pitti: seems to work fine but I've not played a lot with it, just like 1 hour the day we talked about it and I've skiped to other stuff waiting for upstream discussions
<Mirv> Kamion/sladen: yes, I just though if any are going to go the Rantasauna tomorrow evening after the Suomenlinna trip
<Mirv> (I can't really attend to much anything because of a hectic time at work, but I thought I could drop by at the sauna:)
<Mez> sladen's buggered off ~D
<\sh> doko: ping
<wasabi> Is there a bug someplace to centralize mozilla between firefox and epiphany and whatever?
<wasabi> libmozilla or something
<\sh> doko: did u use my second debdiff patch? with the gcc4 patch included?
<doko> ?
<\sh> doko: Jul 12 Matthias Klose  (  49) Accepted djvulibre 3.5.14-5ubuntu2 (source)
<\sh> doko: I patched it to work with gcc 4
<doko> no, that's just the wrong dependency
<\sh> to compile ;)
<\sh> doko: it won't compile
<\sh> i provided a patch and asked ogra to upload
<\sh> https://bugzilla.ubuntu.com/show_bug.cgi?id=12631
<\sh> actually I know how busy u guys are at debconf
<Kamion> fabbione: there's a parted release coming down the pipe with Mac RAID and LVM support; it beat UVF
<Kamion> oh, no, it didn't beat UVF, I'm on crak
<Kamion> +c
<Kamion> I might ask for an exception for that
<Burgundavia> seb128, which is that bug about eject and dragging to the trash?
<Burgundavia> seb128, nev mind
<jbailey> quit
<jbailey> Feh, wrong window
* jbailey wants focus follows eyes.
<wasabi> Hshs
<diamond> jbailey: alan cox spent a bit of time playing with an old gaming headset with motion tracking on it. not _quite_ focus follows eyes, but with a bit of training it could work -)
<diamond> (of course, he could still be doing so, but it's much harder to tell since his diary switched to welsh ,-)
<jbailey> diamond: Huh, cool.  The tech exists to do it - when I was doing a VR seminar, they were talking about the pilot system in aircrafts noticing when the pilot was looking at and providing context sensitive information on the HUD.
<diamond> jbailey: of course you have to remember to do the info display whereever they're looking, otherwise when they glance away to see the info, it all goes away.... -)
<diamond> jbailey: would be fun to play with tho
<jbailey> Given that the TD bank is apparently about to move their retinal scanners so that you can simply pass through the doorway and not have to look into the machine, it seems probably within easy grasp.
* jbailey phears the viruses stealing peoples bio information off of the webcams.
<diamond> jbailey: wow. scary stuff.
<mdke> you could use your head to move the mouse I suppose
<ogra> jbailey, wearing your tinfiol hat again ?
<jbailey> ogra: The long hair covers it nicely, don't you think?
<ogra> hehe
<havoc> jbailey: would have to be a very hi-res webcam
<jbailey> havoc: Sure, but how far away are those?  Given that sex and killing people drives the technology envelope, both are likely to have demands for high-res cameras done cheap.
<azeem> havoc: are you the famous the-other-havoc from LWN?
<havoc> azeem: nope
<azeem> ah, ok
<havoc> jbailey: sooner or later, yes
<seb128> elmo: glib2.0 (experimental) inkscape hardware-monitor meld anjuta syncs please
<Simira> dilinger :)
<dilinger> i love it when i reboot the wrong machine :)
<tsume> all you damn specicist sicken me! :P
<poningru> hi I wanted to throw out an idea that this guy came up with
<poningru> how about during a dual boot installation giving people the choice of transfering their stuff in windows transfer over to the linux partition
<Burgundavia> poningru, they are working on it
<poningru> this is ofcourse only for the files in My Documents
<poningru> are you serious?
<poningru> any docs on that?
<Burgundavia> there is spec
<Burgundavia> a spec, even
<Burgundavia> just a sec
<poningru> nice that rimed
<Burgundavia> http://udu.wiki.ubuntu.com/MigratingToUbuntu
<poningru> ok another suggestion this time mine own
<poningru> why not integrate something like a qtparted in the intallation process
<ogra> poningru, a version of gparted just gets modified
<Burgundavia> http://udu.wiki.ubuntu.com/GraphicalPartitioningTool
<Burgundavia> google bounty
<ogra> nope
<ogra> thats actually a ubuntu bounty
<poningru> hehe
<poningru> I guess great minds think alike is true
<poningru> ooh High Priority
<ogra> it will get integrated into http://udu.wiki.ubuntu.com/UbuntuExpress
<Burgundavia> ogra, you are right, my bad
<daniels> lamont__: pong
<Kamion> unfortunately MigratingToUbuntu is a "vote for more money" spec (much as I hate to borrow a phrase from asuffield)
<Kamion> a lot of it is very difficult stuff and there's nothing that comes close to an implementation plan
<Burgundavia> Kamion, are not all specs a "vote for more money|time" spec?
<tsume> `/win 12
<Kamion> Burgundavia: no, the specific meaning of that phrase is that one writes down a wishlist for an arbitrary Good Thing without having anyone to implement it or any plan for doing so
<ogra> Burgundavia, most of them are "bringmrthisfeature" specs
<ogra> s/mr/me/
<Kamion> it means you get to point to the spec whenever people bring up the wishlist, but that's about it
<Burgundavia> yes
<Kamion> which tends to stifle progress because people think somebody's already working on it when they aren't
<Burgundavia> true
* lamont__ tries to remember what daniels stuff he was going to pester him about
<neiras> Hello - what is the status of usplash? Will it be in Breezy?
* lamont__ tries an ia64/desktop install, given how well the server install went
<lamont__> gives me something to do while I finish downloading the breezy install image
* Mez pokes lamont around a bit and thanks him for the backports stuff
<lamont__> doh.  lunchtime. back in a bit
<pef> bye !
<jbailey> Kamion: The various groups not existing when things think they should is the bug in the installer you were talking about earlier right?
<Kamion> jbailey: right
<Kamion> jbailey: I'm not at home at the moment so I can't really test the fix
<jbailey> Kamion: I have need to install my laptop, can I be your bitch?
<Kamion> jbailey: yay for bitches
* jbailey goes and finds a proper collar.
<mdz> lamont,infinity: how goes the backports/tilde battle?  are we ready to light it up?
<lamont__> mdz: have been on our side for most of last week
* lamont__ points at archive.ubuntu.com/ubuntu/pool/main/d/dpkg
<mdz> lamont__: last I heard from elmo was that sbuild/wanna-build needed attention to deal with ~-versions
<Kamion> which incidentally is SO WRONG
<Kamion> can we purge dpkg from hoary-backports before sending it live? :)
<mdz> ...and that dpkg was his test case ;-)
<lamont__> -rw-rw-r--  1 archvsync archvsync  607228 Jul  9 00:25 dpkg_1.13.10~hoary1_amd64.deb
<lamont__> -rw-rw-r--  1 archvsync archvsync  579154 Jul  7 20:05 dpkg_1.13.10~hoary1_i386.deb
<lamont__> -rw-rw-r--  1 archvsync archvsync  609070 Jul  9 00:25 dpkg_1.13.10~hoary1_powerpc.deb
<Mitario> mdz, hi :) did you get my message about python-apt?
<lamont__> so 3 days ago we uploaded the last 2
<mdz> looks like it's there for all architectures
<lamont__> but the changes were there on all 12 buildd's on the 7th
<mdz> great
* lamont__ notes that dpkg is the only thing in w-b for hoary-backports, as of when he last looked 2 days ago or so
* lamont__ watches his hoary/ia64 desktop system boot for the first tiem
#ubuntu-devel 2006-07-10
<zul> need to get dinner bbl
<mdz> zul: backing out your patch and building with gcc-4.0 still gives me a broken grub (this one with weird corruption of the menu commands)
<mdz> oddly enough, I can boot fine with this one if I use the grub command line rather than the menu
<jdub> mdz: current edgy grub is b0rk, or is this pre-upload testing?
<mdz> jdub: the former
<zul> have you tried removing the diskless boot stuff?
<jdub> mdz: thanks 8)
<mdz> zul: not yet
<mdz> zul: I'm trying dapper grub + your quiet patch with gcc-4.0
<mdz> zul: ok, that works
<mdz> so your patch does not appear to be at fault
<zul> well thats a good thing ;)
<mdz> zul: did you test this whole package before uploading it?
<zul> yes i did...i didnt have the same problems
<mdz> that is, did you test your patch with the merged grub
<zul> yes
<mdz> but you can confirm the problem now, yes
<mdz> ?
<zul> correct...but i didnt run update-grub before i ran grub-install
<mdz> I didn't try 0.97-11ubuntu1
<mdz> zul: surely that shouldn't matter
<mdz> it breaks in the same way regardless of whether the quiet option is used or not
<zul> hold on a  sec..
<zul> i just want to try something
<mdz> I'm trying reverting cvs-sync
<mdz> then I'll try disabling netboot
<mdz> one of those should be at fault
<zul> mdz: i have modified quiet.diff so the GNU/GRUB is in the menu reverted the diskless client and i was able to boot
<zul> and i reverted the change from the update-grub as well
<mdz> zul: looks like it was the netboot stuff
<zul> correct
<zul> ill revert the netboot stuff after i come back from dinner is that ok?
<mdz> zul: now we just need to do something about the fact that update-grub will break the boot
<mdz> zul: I'll take care of reverting the netboot stuff
<zul> ok
<zul> i reverted the update-grub for quiet as well..but i need to go out since my wife is starting to get upset, bbl
<mdz> zul: should be all set now
<jdub> mdz: shouldn't you be out enjoying the last sun you'll see for a long time? :)
<bddebian> heh
* jdub figures it's not actually sunny atm
<mdz> jdub: it is sunny and 93F
<mdz> and I'm 20 minutes late for a barbecue
<jdub> oh, it's mid afternoon
<mdz> but I knew that if grub wasn't fixed, there would be a kernel upload or something which would stop nearly all edgy systems from booting
<jdub> heh
<mdz> this would be widely recognized as a bad thing
<mdz> except by the powerpc users, who would have a nice chuckle
<mdz> all 5 of them
* jdub hugs mdz 
<jdub> stuck fixing grub merges on sunday, and suffering the torment of going to a barbecue but not eating meat - horror!
<mdz> it turned out it wasn't the merge, but an opportunistic feature enhancement bundled with the upload (enabling diskless support)
<mdz> which used to work fine, but now seems to completely break grub
<jdub> heh
<jdub> http://blogs.gnome.org/view/rbultje/2006/07/10/0
<jdub> ^ macbook isight on linux :)
<jsgotangco> wow
<bddebian> Who is responsible for the merges pages?
<tseng> keybuk
<bddebian> I was afraid of that
<bddebian> BTW, Hi tseng :)
<tseng> hi.
<jdub> hrm, how do i request an ignore-my-merge sync? ping elmo?
<bddebian> You just want a straight sync?
<jdub> yeah
<bddebian> Just file a sync request on LP
<jdub> hrm, ok
<jdub> is there a wiki page about this?
<bddebian> Not that I know of.  Just file a bug on LP request sync of <package> <version> from Debian <unstable,experimental> and subscribe ubuntu-archive
<slomo_> jdub: https://wiki.ubuntu.com/DeveloperResources
<slomo_> there's a section about syncs
<jdub> slomo_: thanks
<sladen> jdub: file a bug against the package and subscribe ubuntu-archive
<bddebian> I get no respect :-)
<jdub> slomo pointed me to Actual Documentation
<thierryn> hi, I'm looking at https://wiki.ubuntu.com/PbuilderHowto and I see some big mistake in it... and it doesn't work for me... anyone could help me a bit?
<bddebian> thierryn: What's the problem?
<bddebian> Though I am apparently unqualified to answer :-)
<thierryn> I'm on dapper, I do "sudo pbuilder create" then "sudo pbuilder build my-app.dsc" and it output this :
<zul> mdz: sorry about that
<thierryn> W: /home/thierry/.pbuilderrc does not exist
<thierryn> pbuilder-buildpackage/i386 $Id: pbuilder-buildpackage-funcs,v 1.16 2005/06/03 12:07:39 dancer Exp $
<thierryn> $Id: pbuilder-buildpackage,v 1.113 2005/06/25 06:27:42 dancer Exp $
<thierryn> Current time: Mon Jul 10 00:23:46 UTC 2006
<thierryn> pbuilder-time-stamp: 1152491026
<thierryn> Building the build Environment
<thierryn>  -> extracting base tarball [/var/cache/pbuilder/base.tgz] 
<thierryn> E: failed to find /var/cache/pbuilder/base.tgz, have you done <pbuilder create> to create your base tarball yet?
<thierryn> sorry for the spam
<bddebian> Wow, hey infinity
<bddebian> thierryn: Does the base.tgz exist?
<bddebian> And have you checked your /etc/pbuilder/pbuilderrc?
<thierryn> ho ok found the problem
<thierryn> when I do pbuilder create I get:
<thierryn> The following packages have unmet dependencies:
<thierryn>   aptitude: Depends: libsigc++-2.0-0c2a (>= 2.0.2) but it is not installed
<thierryn>   gnupg: Depends: libreadline5 (>= 5.1) but it is not installed
<thierryn>   libsasl2: Depends: libdb4.2 but it is not installed
<thierryn>   whiptail: Depends: libnewt0.52 (>= 0.52.2) but it is not installed
<bddebian> You get that error on create?
<thierryn> yeah
<bddebian> Do you have debootstrap installed?
<thierryn> yeah
<bddebian> What happens if you do 'sudo pbuilder create --distribution dapper' ?  Anything different?
<thierryn> E: No such script: /usr/lib/debootstrap/scripts/dapper
<thierryn> ho im in a chroot<
<bddebian> hmm
<thierryn> but its been a long time since a used it, dont know if its edgy or dapper chroot
<bddebian> Check your sources.list?
<thierryn> where?
<bddebian>  /etc/apt/sources.list
<gnomefreak> thierryn: those look like edgy errors not so much dapper
<bddebian> thierryn: Did we lose you? :-)
<thierryn> no no fixing sources.list
<bddebian> Ah :-)
<thierryn> ha great, the chroot was breezy, that was the problem 
<thierryn> is edgy repositories ready? I mean, can I create a edgy chroot
<thierryn> &?
<jdub> thierryn: yes
<jdub> (no idea if debootstrap will successfully create one though)
<infinity> It should.
<thierryn> jdub : k
<bddebian> thierryn: Can't you just dist-upgrade your existing chroot?
<jdub> hi infinity 
<jdub> infinity: how was your break?
<infinity> jdub: Good until it wasn't.  See warthogs.
<jdub> infinity: suck! :|
<infinity> jdub: I'm just trying to kill a few thousand messages of email backlog before I go back to bed. :/
<bddebian> heh
<Hobbsee> hi all
* imbrandon prods to see if any canonical employees are alive , got justa quick question
<jdub> yeah?
<Hobbsee> heya jdub!
<jdub> morning Hobbsee 
<imbrandon> moins jdub, hey i was wondering whom to prod about getting skype 1.3 pkg in ubuntu-commercial repos ? or if there even WAS someone to prod about it
<jdub> skype has their own repository
* jsgotangco shoots jdub
<imbrandon> i realize this but a uniform place for commercial software would be nice since they ahve obviously started it
<neuralis> jdub: http://solarsail.hcs.harvard.edu/~krstic/jdub.jpg
<Hobbsee> haha
<Hobbsee> neuralis: loosk just like him to me :P
<neuralis> Hobbsee: it captures the essence of jdub well.
<Hobbsee> hehe, indeed
<jsgotangco> oh my
<Eleaf> hi ;p
<Hobbsee> hey Eleaf 
<Eleaf> hi
<Eleaf> I need to know what gtk method or widget is used whenever you change the volume with the keyboard and that volume item comes up in the middle of the desktop and how it is called ;p.
<neuralis> Eleaf: this is not the appropriate channel. try #gtk.
<Eleaf> there is 8 people there, I cannot expect a response in my timeframe
<neuralis> Eleaf: that doesn't mean this channel becomes any more appropriate for your question.
<jdub> Eleaf: try #gnome-hackers on gimpnet
<jdub> neuralis: try to give helpful redirection dude
<Eleaf> ;o)
<neuralis> jdub: #gtk was all that came to mind.
<jdub> neuralis: the underlying toolkit five levels down from the item the question was about? not wildly useful
<jdub> Eleaf: gnome-settings-daemon handles those keys - #g-h for more discussion would be best
<Eleaf> Thanks to both of you
<Eleaf> okay jdub 
<neuralis> jdub: huh? he wanted help identifying a gtk widget; i'm not sure how you see this as five levels removed from gtk
<jdub> neuralis: the developers of the toolkit are not going to be entirely helpful with an implementation detail from one of their user's applications
<neuralis> jdub: 'how do you draw a small floating window with gtk' seems pretty generic to me. anyway, doesn't matter.
<fabbione> GOOOOOOD MORNING!
<Hobbsee> hey fabbione!
* Hobbsee throws some icecubes at fabbione 
<fabbione> Hobbsee: intercontinental icecubes?
<Hobbsee> fabbione: of course :)
<sbalneav> night all
* raphink opens an eye and waves
<Hobbsee> hey raphink 
<raphink> hi Hobbsee
* Hobbsee wont throw icecubes at raphink.  she wants something from him :P
<raphink> :p
<Hobbsee> raphink: please approve https://launchpad.net/distros/ubuntu/+source/netatalk/+bug/52488
<Ubugtu> Malone bug 52488 in netatalk "[Edgy MoM]  Please sync netatalk 2.0.3-4 from Debian Sid" [Untriaged,Unconfirmed]  
<Hobbsee> :P
<Hobbsee> that's all, for the moment :)
* raphink 's brain is not awaken enough to do anything yet
<Hobbsee> raphink: bleh.  maybe those icecubes do need to be thrown at you then.
* fabbione sighs 
<fabbione> bug #52431
<Ubugtu> Malone bug 52431 in libxrender "libXrender.la" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52431
<fabbione> this is so no
<Hobbsee> fabbione: mind pointing me to somewhere as to why it isnt?  i'm curious
<fabbione> Hobbsee: google for why .la files should die
<Hobbsee> fabbione: will do
<fabbione> there have been several threads/flamewars/nuclearexplosions
<Hobbsee> fabbione: hehe, right
<fabbione> holy crusades started because of .la files!
<Hobbsee> oh scary!
<raphink> the main problem in .la is .hollywood
<raphink> Hobbsee: there, done
<Hobbsee> raphink: thankyou :)
<pitti> Good morning
<Hobbsee> hey pitti!
<pitti> hi Hobbsee 
<pitti> fabbione: do you remember why squid only suggests the snakeoil SSL cert in the documentation and does not actually use it by default?
<fabbione> pitti: i think because squid can do some ssl operations but there is no real gain with the snakeoil
<pitti> fabbione: I'm currently writing a debian bug (since this documentation change is our only diff), so I'd like to write some justification :)
<fabbione> pitti: i will need to look into it again
<fabbione> pitti: do you think it can wait a bit or is it urgent?
<pitti> fabbione: ok, thanks!
<fabbione> i am in the middle of merging xorg-server
<pitti> fabbione: no, not urgent at all; I just postpone the mail
<pitti> ooooh
<fabbione> ok thanks
<pitti> xorg> rock :)
<fabbione> this is so going to blow up
<fabbione> who was doing mesa merge?
<pitti> fabbione: I'm not (it's assigned to me, but I only fixed the POT file; I have no clue about the package)
<fabbione> pitti: ok
<fabbione> i can workaround it for now, but once that merged we need to remember to do another xorg-server uplaod
<fabbione> it changes a B-D
<sivang> morning
<Hobbsee> hey sivang 
<sivang> hey Hobbsee 
<pygi> sivang, :)
<sivang> hi pygi 
<dholbach> good morning
<pygi> mornin' dholbach 
<dholbach> hey pygi
<pitti> sivang: hey
<sivang> pitti: Hi Martin! how are you ?
<pitti> sivang: pretty fine, and you?
<pitti> sivang: the weekend was full of soccer watching and b-day celebration (of my grandma)
<pitti> sivang: do you think you can merge and test culmus?
<sivang> pitti: I talked about it with Colin, he told me that we should better wait for when x-sync/merge is over, since then culmus will turn into just a sync, but if you want me to do it now, I can ofcourse.
<pitti> sivang: oh, no, that makes sense
<sivang> pitti: he said that once X is done, it could get synced no fuss, since he checked and the changes are due to X stuff changing (paths, etc)
<pitti> sivang: *nod*
* pitti grabs logcheck merge
<sivang> pitti: re Weekend, although not much soccer watching (no TV in my apartment) we went out for some walking around the city, and watched a DVD, and prepared French Onion soup :)
<madduck> pitti: are there any ubuntu changes in logcheck you want in debian?
<pitti> madduck: no, I just requested a sync
<madduck> ok
<pitti> madduck: our only change (creation of /var/lock/logcheck in init.d) has been adopted
<pitti> hi madduck 
<madduck> hi. ok. great.
<seb128> Mithrandir: around?
<dholbach> hey el
<Mithrandir> seb128: hiya
<seb128> Mithrandir: yeah
<seb128> Mithrandir: that's something weird with xkeyboard-config
<Mithrandir> seb128: how so?
<seb128> Mithrandir: xkb-data is empty and xkeyboard-config has the content ... shouldn't it be the other way around?
<seb128> Mithrandir: and data are still installed to /etc instead of /usr/share ... is that on purpose?
<Mithrandir> seb128: both is on purpose.  The transition isn't done yet.
<seb128> ok
<seb128> so I fix libxklavier for now
<seb128> it's build with /usr/share as xkb path atm :p
<pitti> hey Keybuk 
<sivang> morning Keybuk 
<pitti> Keybuk: FYI and to avoid duplicate work, I grabbed some of your merges
<pitti> Keybuk: logcheck and mtools so far
<pitti> Keybuk: and I am going to do sane-backends and netkit-base unless you want to
<seb128> Keybuk: you should rather grab merges from people not being around like mvo no? :)
<pitti> Keybuk: oh, and I already did nis
<pitti> seb128: you mean me?
<seb128> ups
<seb128> yep
<seb128> pitti: you should rather grab merges from people not being around like mvo no? :)
<pitti> seb128: yep, I just did some packages I was familiar with
<Keybuk> pitti: I'd prefer to do netkit-base
<seb128> pitti: you seem to be looking for something to do and trying to take work from other people for a week, I've a whole stack of GNOME bugs to track if you fancy it :p
<pitti> Keybuk: sure, I do not have a particular attachment to it :)
<pitti> seb128: I have heaps of work to do for myself, but we need to kill the merges
<Keybuk> otherwise no objection, I've also been grabbing merges from other people (Adam and Lamont mostly)
<seb128> pitti: right, "we", you don't need to do them for everybody then :)
<pitti> seb128: so I did Charles' merges and Adam's so far
<pitti> seb128: sure :) (just trying' to help, sorry)
<seb128> pitti: no need to be sorry, but I'm just pointing that other people will do their merge if you let them some time (I know I'll do mines for sure :p) ;)
<Mithrandir> I'll grab the discover1 merge since I doubt daniels is going to do it. :-P
<seb128> pitti: though I'm sure than MOTU guys would be happy if you do their ~490 merges to do ;)
* sivang is grabbing subversion, if no-one has grabbed it already.
<Mithrandir> fabbione: so, did it work?
<dholbach> and i'd be happy if somebody did  scim  - really happy
<pitti> sivang: I'd let infinity do this
<pitti> sivang: he has access to Debian's svn and might have ubuntu in svn, too
<sivang> pitti: ah, I see, okay then :)
<pitti> dholbach: ok, I'll do that
<fabbione> Mithrandir: yes.. first shot.. and we don't need to do fonts transition. The DEbian path is hardcoded as optional in the server binary
<Mithrandir> fabbione: oh, excellent.
* dholbach hugs pitti ecstatically
* pitti beams
<fabbione> Mithrandir: at least as upgrade from dapper.. i have no idea if it works on clean installs yet
<sivang> dholbach: any ohter mergers you'd be hapy for someone to help you with? :)
<dholbach> ogra wanted to do gpm and pitti wanted to do scim
<dholbach> i think thoses were the ones i wasn't happy with
<pitti> dholbach: scim-{anthy,chewing,etc.} too?
<dholbach> hum, i didn't touch them
<Chipzz> dholbach: s/gpm/g-p-m/ ;)
<dholbach> lemme look whose merges those are
<dholbach> Chipzz: yeah, probably :)
<Chipzz> dholbach: gpm is an actual package and probably not what you're referring too ;)
<dholbach> pitti: hum, not sure, if Hou ZhengPeng wanted to do them
<dholbach> Chipzz: i know
<Chipzz> anyway, enough nitpicking :P
<dholbach> :)
<el> hey dholbach :)
<dholbach> el: how's it going?
<dholbach> el: when are we going to go for some ice cream? i feel like it now already ;)
<dholbach> *melt*
<el> dholbach, hehe, too hot to work
<el> dholbach, this week is very busy -> we have to do 40 tests :-|
<dholbach> el: i can't say, I'm not busy :-)
<dholbach> but not too busy to get some of the best icrecream around :)
<el> dholbach, hehe 
<el> dholbach, wednesday evening maybe? 
<el> some feierabend icecream (instead of feierabend beer)
<dholbach> el: sounds good
<el> yammm
<dholbach> (that doesn't stop me of getting some later on) :-p
<el> dholbach, you are lucky to live almost next door
<dholbach> el:i think it's the same distance for both of us, no?
<dholbach> (from your work place)
<el> dholbach, from home yes, but not from my work office ;-)
<dholbach> oh, hm
<el> dholbach, the new workplace (starting september) is next door
<dholbach> ahhhh
<dholbach> rock on :-)
<el> that's gonna be great :)
<el> ice cream every day
<dholbach> woohoo
<el> hehe
* el is getting breakfast
<pitti> Keybuk: do you want to merge dhcdbd together with n-m or shall I merge it?
<dholbach> el: bon appetit
<jsgotangco> he el
<Keybuk> pitti: I will merge it, as I said last week
<pitti> Keybuk: oh, I forgot; thank you!
<Keybuk> Kamion: morning
<ivoks> hi
<sivang> hey ivoks 
<ivoks> pitti: ping
<pitti> hi ivoks 
<ivoks> hi sivang ; how are you?
<ivoks> pitti: you've heard about that bug in 1.2.1? :)
<pitti> ivoks: yep, I read it this morning
<sivang> ivoks: fine, thanks.
<pitti> ivoks: I was just about to turn my attention to it :)
<pitti> ivoks: I'll also add something to postinst to /^RunAsUser/d 
<ivoks> pitti: there's debdiff that fixes it
<ivoks> pitti: nice :)
<pitti> ivoks: (and grrr @upstream to silently break his own configuration file format...)
<ivoks> pitti: it's a bug
<pitti> ivoks: I mean RunAsUser, not the IP parsing
<ivoks> ah, that
<ivoks> s/^RunAsUser/# RunAsUser - this option isn't available in CUPS 1.2.1/ would be nicer... imho
<pitti> ivoks: *nod*
<sivang> ivoks: FYI I did the merge for etherape, was just a sync.
<ivoks> sivang: etherape? /me confused
<pitti> ethereal?
<HrdwrBoB> etherape is a graphical tool
<HrdwrBoB> maps your network connections
<HrdwrBoB> it's seperate
<sivang> EtherApe is an etherman clone. It displays network activity
<sivang>  graphically. Active hosts are shown as circles of varying size,
<sivang> pitti, ivoks : ^^
<ivoks> i know what they both are, bu i don't remeber saying anything abou ti
<ivoks> s/ti/it
<sivang> ivoks: you were the last uploader on the MOTU merge list ;)
<ivoks> ah... :)
<sivang> so it's courtesy and good practice to let the last person know you are taking his merge :)
<ivoks> sivang: right, thanks for info
<sivang> ivoks: np
<doko> pitti: 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
<ivoks> see you later today, bye
<fabbione> go SSP!
<pitti> doko: ugh, I thought it only affected mono
<pitti> doko: so maybe we should disable it on ppc until upstream has a fix?
<doko> first looking at it ...
<seb128> is there any massive builds retry planned?
<seb128> most of GNOMEish stuff have not built on !i386 for a week apparently
<fabbione> seb128: what's the blocker?
<fabbione> can you see it from the logs?
<fabbione> or is it just random?
<fabbione> x libs have been finished friday
<Keybuk> seb128: I did a retry on Thursday/Friday ... what's the problem ?
<seb128> fabbione: for one GTK 2.10 didn't built due to xorg borkage and didn't get retried since
<fabbione> seb128: oh ok
<fabbione> it should be settled by now
<fabbione> libs are all done
<fabbione> hopefully they also work
<seb128> Keybuk: let me look to be sure
<Keybuk> seb128: could you give me a list of things that need giving back
<seb128> it looked like a "GTK failed because pango was not installable due to xft"
<seb128> Keybuk: sure, a min
<seb128> Keybuk: gtk+2.0 to start :)
<seb128> hum
<seb128> http://librarian.launchpad.net/3279966/buildlog_ubuntu-edgy-amd64.gtk%2B2.0_2.10.0-0ubuntu1_FAILEDTOBUILD.txt.gz
<seb128>   linuxdoc-tools-text: Depends: groff but it is not going to be installed
<seb128> ah
<seb128> it got retried, that's a new error 
<Kamion> Keybuk: hi
<seb128> hum
<Keybuk> Kamion: good weekend?
<seb128> anybody with an amd64 to looks if groff is installable now, and if it's not why?
<Kamion> yep, much beer
<Kamion> seb128: what's wrong with edgy_probs?
<Keybuk> Kamion: I got slightly sunburnt at goodwood on saturday
<Kamion> edgy_probs currently says that groff is installable everywhere
<fabbione> pitti: ping?
<pitti> fabbione: pong
<seb128> Kamion: nothing, so gtk+2.0 probably need a retry only
<seb128> Kamion: I was looking at http://librarian.launchpad.net/3279966/buildlog_ubuntu-edgy-amd64.gtk%2B2.0_2.10.0-0ubuntu1_FAILEDTOBUILD.txt.gz
<fabbione> pitti: do we have anything pending on xorg-server by anychance?
<Kamion> sure, just saying you can look at the automatic list rather than asking for people to check manually
<fabbione> (dapper to be more specific)
<seb128> Kamion: right
<Kamion> also looking at just the last of a huge pile of "is not going to be installed" from apt is not very helpful IME
<Kamion> because it's usually just that apt's problem resolver got bored
<Kamion> note that groff depends: libx11-6 and above apt said that it was unhappy with libx11-6
<pitti> fabbione: if http://xorg.freedesktop.org/releases/X11R7.0/patches/x11r7.0-setuid.diff is already applied in edgy, then not
<pitti> fabbione: oh, that one is not yet applied in dapper
<fabbione> pitti: ok perfect thanks
<pitti> fabbione: it's not really urgent (I regard it as bug fix rather than a vulnerability)
<fabbione> pitti: i am about to apply it to edgy via debian sync
<fabbione> pitti: if you think it's only bug fixes i will prepare a dapper-updates
<fabbione> pitti: i need to upload xorg-server because well.. hmm one package in dapper is kind of empty by mistake
<pitti> fabbione: -updates is fine for me
<fabbione> pitti: ok thanks
<fabbione> pitti: what's the approval procedure for -updates now? open a bug with debdiff and sub ubuntu-release?
<seb128> Keybuk: gtk+2.0 (which should unblock libgnomeui which is dep-waiting) then when libgnomeui is built: ubuntulooks gucharmap gcalctool gnome-python totem gnome-system-monitor evince gossip tsclient file-roller glabels glade nautilus-sendto nautilus-cd-burner epiphany-browser
<fabbione> -ETOOMANYPROCEDURES
<pitti> fabbione: unless there is already a bug, just mail mdz
<pitti> fabbione: if there is a bug, sub'ing him and asking for approval works fine, too
<fabbione> pitti: ok. i don't recall a bug about it
* pitti neither
<Keybuk> seb128: gtk+2.0 rebuilding now (this had already built on i386)
<seb128> Keybuk: has said before, that's on !i386
<seb128> Keybuk: i386 is fine
<Keybuk> ok
<seb128> i386 libs built just before the xorg b0rkage probably
<tseng> moin seb128 
<Keybuk> will they not need rebuilding with the new X11 libs?
<seb128> hi tseng
<seb128> Keybuk: I don't think so
<seb128> Keybuk: anyway GNOME 2.15.4 this week so we will rebuild a good part of the stack anyway
<fabbione> Keybuk: no, there are no relevant changes to the libs other than being installable again
<fabbione> Keybuk: it was a merge only but some of them had the (in)famous epoch versioned depends *
<Keybuk> seb128: dep-wait on ia64: libglib2.0-dev (>= 2.12.0)
<sivang> Keybuk: will you have time today to review SystemCleanUpTool so we can get it approved ?
<seb128> Keybuk: hum, right, glib FTBFS on ia64 ... I need to investigate that, thank you for pointing it
<Keybuk> sivang: possibly
<sivang> Keybuk: oh, that would make me happiest man alive :)
<Kamion> seb128: goffice in NEW seems to drop back from libgoffice-1-2 to libgoffice-0-3; is that intentional?
<seb128> dholbach: do you know about goffice?
<Kamion> Gloubiboulga: ^--
<seb128> Kamion: there might be 2 versions to NEW?
<Kamion> there are not
<seb128> Kamion: I think somebody synced the unstable version first, and dholbach figured we need the experimental one
<seb128> ok
<Kamion>   * [debian/*]  Follow upstream versioning change for the development version.
<seb128> I'll let dholbach or Gloubiboulga comment then
<Kamion> hmm, may be deliberate
<dholbach> seb128: for gnumeric 1.7.0 we need goffice 0.3.0
<Kamion> we have the version from experimental, yes
<dholbach> and the package name was crafted in debian (the soname really changed)
<Kamion> I'm fine with it if it's intentional, just wanted to check
<Kamion> (accepted)
<dholbach> thanks Kamion
<pitti> seb128, dholbach: do you plan to update gimp to 2.2.12 in the next time? I currently do the security update for stables and wonder whether I should update edgy, too (and merge with Debian on this occasion)
<seb128> pitti: I don't intend to touch gimp for now, maybe dholbach do though :)
<pitti> (it's mvo's merge ATM)
<dholbach> seb128: let's get the experimental gimp in :)
<dholbach> seb128: debian has 2.3.9-1 in experimental
<hmrocha> hello, when i press alt+f2 and run gconf-editor gnome-panel crashes
<Kamion> pitti: do we want linuxprinting.org-ppds in main?
<seb128> dholbach: I've too much to do already but feel free to do it
<hmrocha> can you try in your computer please?
<seb128> hmrocha: do you use a11y feature?
<pitti> dholbach: this also needs the security patch, btw (it's only fixed in 2.2.12)
<hmrocha> seb128: what's that?
<dholbach> seb128, pitti: might be safer to do the 2.2.12 update
<dholbach> pitti: i set it on my list
<seb128> hmrocha: try #ubuntu, that's not an user chan, but that might be a known issue
<pitti> Kamion: hm, sounds useful for printers which speak Postscript
<hmrocha> seb128: ok, sorry
<pitti> Kamion: but I never looked at it or saw a request for it
<dholbach> seb128, pitti: not sure how stable experimental gimp is
<seb128> dholbach: stable enough for edgy probably ;)
<Kamion> nor I, I just noticed the name while looking through the hplip changelog while doing NEW processing
<dholbach> seb128: word up :-)
<Kamion> Keybuk: btw, I'm bored of archive admin for now, your turn :)
<hmrocha> seb128: are memory leaks appropriate for this channel?
<pitti> dholbach: ok, great (Debian has the fix in unstable already, CVE is in their changelog)
<seb128> hmrocha: no
<seb128> hmrocha: cf topic
<seb128> hmrocha: you really want to use the bug tracker for issues like that
<dholbach> pitti: i'll have a look if 2.3.10 fixes it
<Keybuk> Kamion: heh, if you'd waited just 30s, I would have done it anyway
<Keybuk> I was just about to start the syncs, when you did the first one
<Kamion> ah, heh, ok
<Kamion> sucks to be me
* sivang searches for any more main merges he can do.
<Keybuk> sivang: UNIVERSE NEEDS YOU! :D
<Keybuk> (though I guess their deadline is a lot further away)
<sivang> Keybuk: I already helped some merges there , and wil do more , but yeah, main's deadline is annoyingly close :)
<Mithrandir> doko: would you care to do the syck merge as it's a python transition thing?
<ogra> pitti, you have a logitech udb 250 headset, right  
<ogra> ?
<ogra> *usb
<dholbach> ogra: and another g-p-m release: 2.15.4 :)
<ogra> dholbach, is the stack ready now ? 
<dholbach> ogra: i386 seems happy
<ogra> when i tried it last time, it ftbfs because of missing pango stuff
<ogra> ok, then i'll try today again
<dholbach> rocknroll
<doko> Mithrandir: ok
<Mithrandir> doko: cheers.
<doko> Mithrandir: bah, now we're in sync with python, we have a php4/php5 divergence
<Mithrandir> doko: we've had that since hoary or breezy, so that's nothing new.
<slomo_> Keybuk, Kamion: could you please accept metacity and nautilus-cd-burner from NEW? i'm waiting for them for gnome-python-desktop upload which is currently blocking most of gnome
<Keybuk> slomo_: I'll be processing the NEW queue once I've finished processing syncs
<Keybuk> you shouldn't need to block an upload for a NEW processing, the build will dep-wait
<slomo_> Keybuk: i wanted to testbuild it before... but ok, i'll just upload it and hope that it builds fine :)
<Keybuk> you can test build it by building metacity and nautilus-cd-burner
<doko> Selecting previously deselected package libc6-i386.
<doko> Unpacking libc6-i386 (from .../libc6-i386_2.4-1ubuntu6_amd64.deb) ...
<doko> Selecting previously deselected package lib32gcc1.
<doko> Unpacking lib32gcc1 (from .../lib32gcc1_1%3a4.1.1-2ubuntu5_amd64.deb) ...
<doko> dpkg: error processing /home/buildd/build-224804-172430/chroot-autobuild/var/cache/apt/archives/lib32gcc1_1%3a4.1.1-2ubuntu5_amd64.deb (--unpack):
<doko>  trying to overwrite `/usr/lib32', which is also in package libc6-i386
<doko> Selecting previously deselected package lib32z1.
<doko> Unpacking lib32z1 (from .../lib32z1_1%3a1.2.3-12ubuntu1_amd64.deb) ...
<doko> dpkg: error processing /home/buildd/build-224804-172430/chroot-autobuild/var/cache/apt/archives/lib32z1_1%3a1.2.3-12ubuntu1_amd64.deb (--unpack):
<doko>  trying to overwrite `/usr/lib32', which is also in package libc6-i386
<doko> Mithrandir: ^^^ from the gcc-4.1 build log, works fine for me, is this a problem with the buildd?
<Mithrandir> doko: do you have force-overwrite or something in dpkg.conf?
<doko> /usr/lib32 is a directory ...
<infinity> It bloody well better be, yes.
<Mithrandir> oh, true.
<Mithrandir> that's interesting, then..
<infinity> Can someone mail me to investigate that tomorrow when I'm in and not sick?
<infinity> I've had this argument with dpkg and glibc a few times already, so there may be a real bug somewhere.
<infinity> s/may be/almost certainly is/
<Mithrandir> infinity: sent.
<infinity> Thanks.
<Mithrandir> I just C&P the IRC log, I presume that works.
<infinity> Works for me, yes.
<Keybuk> doko: usually happens when two different packages think /usr/lib32 is a symlink to different places
<Keybuk> the annoying thing is that the error will occur on a package that thinks /usr/lib32 is a directory
<infinity> It should be a directory everywhere, but I'm looking.
<doko> Keybuk: that could be a wrongly merged lib32* package, which still has /usr/lib32 pointing to /emul/something. but looking at the changelog, the first lib32 packages unpacked are libc6-i386, and then lib32gcc1. so maybe it's a leftover symlink on the buildd?
<janimo> hi all
<zul> hey
<jsgotangco> hey
<Keybuk> doko: leftover from what?>
<Keybuk> chroots are fresh for each build, not re-used
* infinity is looking into it...
<infinity> root@crested:~# dpkg -S /emul
<infinity> fakeroot: /emul
<infinity> doko: The fakeroot merge is what did it.
<infinity> doko: Fix that and we're back on track.
<infinity> doko: (and fix your preinst to be less scary too)
<Kamion> hmm, doc-base <- fun merge
* Kamion dusts off his perl to excise the use of Unicode::String
<sivang> seb128: Would you mind if I did vino? ; no new  upstream version, and only one patch to reapply (01_no_client_on_hold_loop.patch) and only autotools version change (1.9.6) they are using. So needs putting the patch in, and possible rebuild with changed autoconf version.
<sivang> seb128: ah also, dropping avahi build deps
<infinity> doko: Of course, given fakeroot's build-deps, I may need to manually bootstrap that when I wake up, but if you upload fixed source, I can sort it on the binary end.
<doko> infinity: ok, will do
<ogra> pitti, ping
<doko> infinity: err, fakeroot 1.5.9ubuntu1 does have /usr/lib32 ...
<seb128> sivang: do what? I asked for a sync of vino and it has been done
<infinity> doko: Oh, hah.  It failed to build with the same problem.
<infinity> doko: So if I bootstrap the current one, everything will be fine?
<doko> infinity: yes, looks so
<infinity> doko: Okay, thanks.  Will do.
* infinity pulls some tricks to make this happen quicker.
<sivang> seb128: ah, okay, probably MoM was not updated yet :) 
<seb128> sivang: you can probably help MOTU guys, they have an impressive list of merges to do
<doko> iwj: will xulrunner be in main for edgy?
<infinity> doko: Err, I'll fix it when soyuz stops arguing with me about what I'm trying to do.
<dholbach> doko: unfortunately not, seems upstream has no firefox-without-xulrunner source, so we'd have the source in the archive two times
<seb128> dholbach: what about xulrunner?
<dholbach> seb128: doko asked, if we'll have xulrunner in main for edgy
<seb128> ah, k
<seb128> probably not 
<dholbach> pitti: gimp uploaded
* dholbach goes out now
<pitti> ogra: pong
<pitti> ogra: yes, I have a logitech usb headset, not sure about the model
<seb128> dholbach: later
<sivang> seb128:  Is the synced vino already in edgy ?
<seb128> sivang: you don't know how to look that by yourself that you have to ask?
<seb128> sivang: I've read the mail on edgy-changes, let me have a look on the ftp since that seems to be to complicate for you to do it :p
<gnomefreak> vino 2.13.5-0ubuntu6   is in edgy atm
<seb128> http://archive.ubuntu.com/ubuntu/pool/main/v/vino/vino_2.13.5-1.diff.gz
<seb128> 2.13.5-1 has been synced
<seb128> looks like it didn't build yet though
<sivang> seb128: so I can get the source only after it's been built ? 
<sivang> seb128: (I apt-get source and it gave me the odl one)
* sivang checks his mirror
<seb128> the URI I just copied
<seb128> you know you can wget it
<seb128> but why do you need the new version anyway?
<ogra> pitti, does your headset work for more than 1-1.5 mins with the current powerpc kernel ?
<seb128> that's only a sync from Debian, it has nothing useful
<ogra> for me it just dies
<sivang> seb128: I don't, I just wanted to know what made me be stupid and think it was not sync'd yet, sorry :)
<pitti> ogra: hm, I don't know; I have to upgrade my laptop to current edgy and check
<seb128> sivang: that's not exactly the right chan for that :p
<sivang> seb128: never trust apt-get source then :p
<seb128> sivang: rather wait for the index update
<sivang> seb128: I agree, and apologize deeply :)
<seb128> sivang: but users questions on #ubuntu
<ogra> pitti, for me it doesnt even play music for more than the above timeframe
<seb128> np
<ogra> seems either the driver or alsa
<pitti> ogra: I haven't used it very extensively so far, but I'll check on next possibility
<ogra> it works well on my amd64 lappie with the dapper kernel though
<Hobbsee> hi all
<Riddell> Keybuk: are you still playing at being infinity today?  could you give back komba2?
<iwj> doko: I wasn't planning to do anything do with about by from or pertaining to xulrunner.
<Keybuk> Riddell: I am
* Keybuk hugs give-back.py :p
<Hobbsee> Keybuk: thanks for fixing MOM :)
<Keybuk> fixing?
<Hobbsee> Keybuk: how it wasnt updating, even though the merges had gone thru
<Keybuk> when wasn't it updating?
* Mithrandir kicks mom in the, er, nuts.  Or something.
<Keybuk> Mithrandir: ?
<Douglas77> hi! Do you know how to customize a Ubuntu-ISO so it uses a self-compiled kernel? https://help.ubuntu.com/community/LiveCDCustomization/6%2e10 doesn't talk about that...
<Hobbsee> Keybuk: a couple of days ago?  there was talk about it, people were confirming it - i thought you were too...
<Mithrandir> Keybuk: it doesn't do magic stuff to fix mismatched orig.tar.gz files between Debian and Ubuntu.
<Keybuk> Mithrandir: it can't do anything ?
<Keybuk> Hobbsee: *shrug* not that I'm aware of
<Mithrandir> it could magically give me a new unsigned .dsc with the correct .dsc.
<Mithrandir> uh, orig.tar.gz
<Keybuk> Hobbsee: the archive was fucked a lot last week, maybe it was that
<Keybuk> (which I was fixing)
* Mithrandir is clearly getting tired.
<Hobbsee> Keybuk: it also borked the kid3 merge - said two files were different, but they werent.
<Keybuk> Mithrandir: for which, Debian?
<Hobbsee> Keybuk: ah, may well have been
<Keybuk> Hobbsee: bet they were
<Hobbsee> Keybuk: bet they werent. StevenK and myself checked that with diff.
<Hobbsee> s/diff/whatever it was - my brain's dying!
<Keybuk> Hobbsee: did you md5sum them?
<Mithrandir> Keybuk: it'd make sense for it to give me a source package with what's in Ubuntu, but with Debian's diff, yes.
<Keybuk> Mithrandir: but that wouldn't be the source of the merge ...
<Hobbsee> Keybuk: didnt try that, no.
<Keybuk> Mithrandir: it could give you a .src.tar.gz of the Debian unpacked tree
<Keybuk> Hobbsee: binary files, I assume?
<rodarvus> iwj: do you have any idea on how hard would it be to have xulrunner on main for Edgy? Could be useful for Edubuntu (possibly for other reasons too)
<Hobbsee> Keybuk: po files.
<iwj> rodarvus: Hi.  As I said to doko, I'm afraid I haven't looked at that at all.
<iwj> So I don't really know the answer.
<Hobbsee> Keybuk: unfortunately, i dont have it anymore.
<iwj> rodarvus: Wouldn't this be the kind of thing that should be in a spec ?
<Keybuk> Hobbsee: oh, those always do odd things
<Hobbsee> Keybuk: ah okay
<Keybuk> Hobbsee: usually means msgmerge core dumped
<Keybuk> (yay, gettext)
<Hobbsee> hehe great, we say!
<seb128> rodarvus: we discussed it basically during the summit, xulrunner to main is not a good idea
<Kamion> msgmerge sometimes issues complaints about strange encodings or whatever
<seb128> rodarvus: since we have to ship firefox xulrunner would be only code duplication
<seb128> rodarvus: we have nobody wanting to work on maintaining it and enough bugs without that anyway
<rodarvus> seb128: oh, that is partially bad news, as we'd like to research the possibility of having Epiphany on Edubuntu (but I agree it will probably won't be done in Edgy timeframe)
<Kamion> epiphany's already in main
<seb128> rodarvus: we would like to use xulrunner for GNOME too ....
<seb128> Kamion: but it uses firefox, not xulrunner atm
<Kamion> yes
<rodarvus> Kamion: yes, but it uses firefox
<seb128> the discussion is about xulrunner here
<seb128> if they have to ship firefox anyway, no point to ship a second browser (epiphany)
<seb128> it would be nice to ship epiphany based on xulrunner and no firefox for them though
<seb128> anyway, I don't think it'll happen before having firefox using xulrunner ...
<iwj> And the point of this is just to get the redundant firefox code off the install cd ?
<ogra> seb128, we have to ship epiphany 
<Kamion> iwj: right, epiphany doesn't produce a gain unless its firefox dependency is removed
<ogra> and will do so, regardless of the rendering engine
<ogra> but xulrunner would indeed be a size advantage (a major one)
<seb128> ogra: why? because of kioske mode?
<ogra> yep
<rodarvus> iwj: for us, the point is to have Epiphany as default browser on low-memory situations, and also because epiphany is kiosk-able (using sabayon)
<seb128> hum, k
<ogra> and because we want to ship pessulus and sabayon by default
<iwj> rodarvus: Those things can be done even if you still ship firefox.
<iwj> You just turn it off in the menus etc.
<ogra> which both have browser features included
<iwj> Kamion: Quite so.
<seb128> iwj: the edubuntu CD is fighting to spare 1M usually, so dropping firefox would probably be a good win for them
<ogra> adding epiphany will cost us only some MB ...
<rodarvus> seb128: exactly
<iwj> seb128: Mmmhm.
<ogra> but dropping firefox and replacing it with xulrunner willl rather go into the 10MB area
<iwj> I think though that you're going to have real problems with dual maintenance of lots of the code.
<seb128> that's why we don't want xulrunner to main :p
<ogra> i think its only a security updates issue ... but there its a major one 
<seb128> I think the plan for upstream is to make firefox use xulrunner at some point, but that's not for now :/
<rodarvus> Kamion, Keybuk: in the next few yours we'll be uploading a dozen+ xserver-xorg-video-* packages as NEW - hopefully later today, they'll replace all old xserver-xorg-driver-* packages
<Keybuk> rodarvus: ok
<ogra> maintaining a source twice works if you have two people caring for it during development ... but it would give pitti grief if he'd have to do security patches for both
<pitti> BenC: ping
<rodarvus> (later a upload of xorg to satisfy xserver-xorg-video-all will be done to satisfy the dependency too)
<iwj> seb128: Yes.
<mhb> good afternoon to you, mighty developers
<mhb> perhaps one of you knows (and could tell me) when we unworthy translators will be able to translate Edgy ... (surely after Jul 13th, but when?)
<seb128> mhb:  #launchpad might be a better place to ask that
<seb128> mhb: carlos probably knows about it
<seb128> mhb: why "unworthy"?
<Kamion> mhb: with regard to your inkscape query from the weekend, 0.44 has already been uploaded to Edgy, but just hasn't built yet. That will be sorted out.
<mhb> seb128: a bit of drama never hurts :o)
<pitti> carlos: any idea when we can get edgy translation tarballs?
<seb128> mhb: not sure if it hurts but it can bother people :p
<ogra> mhb, telling that to seb128 might not be the right thing, he had his drama yesterday evening :)
<seb128> lol
<ogra> (he's french)
<seb128> ogra: that's only sport, I don't really care about it :)
<ogra> seb128, btw, any words from zidane in the french press ? 
<seb128> nop
<thom> there's not much he could really say... "i suck, it's been fun, kthx"
<jsgotangco> he got to be man of the match though
<ogra> thom, well, i'd be curious to hear about the reason ...
<mhb> should I wait here for a response from carlos or should I ask in #launchpad?
<mhb> Kamion: thanks
<carlos> mhb, seb128, pitti: I'm finishing some migration code for Edgy
<carlos> it's my main task atm so I guess really soon
<seb128> cool
<pitti> carlos: cool
<seb128> mhb: carlos replied :p
<mhb> seb128: noticed :o)
<mhb> carlos: thanks for the answer
<ogra> seb128, dholbach, does ekiga offer any kind of plugin mechanism ? i'd like to write a script that notifies all my desktops if a call comes in ...
<mhb> carlos: really soon is a matter of days? one week? two weeks?
<carlos> mhb: days to finish some code to open it even better than dapper
<seb128> ogra: no idea, I've not used ekiga (yet)
<Treenaks> ogra: afaik it doesn't..
<carlos> mhb: after that I will test it and try to move it into production... I guess we could say one week or so
<ogra> room for improvement then :)
<carlos> between testing and deployment 
<Treenaks> ogra: yeah, it also doesn't notify anything/anyone when a connection to a SIP server drops
<Treenaks> ogra: (so you can't get incoming calls..)
<ogra> Treenaks, well, i see if my account is connected or not in th eUI
<Treenaks> ogra: yes, but it doesn't notify you if it gets disconnected for (some|no) reason
<Keybuk> ogra: adding libnotify support would be better ?
<ogra> Keybuk, surely
<bddebian> Morning folks
<bddebian> Thanks Kamion
<Keybuk> Mithrandir: I don't think we should even attempt to merge bootchart
<Keybuk> the Debian package is _completely_ different
<Mithrandir> Keybuk: iirc you and whoever packaged it in Debian did it in parallell?
<Keybuk> yup, and they've taken a totally different direction with it
<Keybuk> we integrated it into the initramfs and used java-gcj-compat
<Keybuk> they've made it use kaffe and replace init
<Mithrandir> ew, ok.
<Mithrandir> try dropping the maintainer a mail asking if he could switch to our approach?
<bddebian> Must be because of you damn non-cooperative Ubuntu types
* bddebian hides
* Keybuk blinks at the cdrdao merge
<Keybuk> general observation: merges are much easier if you don't reindent the entire source coed
<seb128> Keybuk: could you bump the gnome-python-desktop build priority? :) That would unblock the gnome-applets sync and new version and some other packages probably too
<sivang> heh
<Keybuk> seb128: ok
<gnomefreak> was it decided to keep xorg 7.0 for edgy?
<seb128> Keybuk: thank you
<seb128> gnomefreak: no
<Keybuk> gnomefreak: no decision was made
<gnomefreak> ok
<seb128> Keybuk: hum, has nautilus-cd-burner been accepted yet (soname change)? because it's required for gnome-python-desktop
<Keybuk> no, it has not
<seb128> ok, so sorry for asking to bump the build priority, it'll be of no use for now :)
<Kamion> doko: by the way, in case you're going round converting stuff to new python policy, please ignore oem-config*; oem-config itself is converted in bzr and the rest are going away
<doko> Kamion: ok, thanks
<slomo_> doko: gcc-4.1 4.1.1-8ubuntu1 FTBFS on ppc :(
<doko> slomo_: yes, I see. looks like gnat doesn't like ssp ...
<fabbione> so does amd64
<doko> fabbione: no, something else
<fabbione> so does amd64 + fail
<bddebian> Kamion or Keybuk: gcl needs a rebuild.  Can you guys throw it up or should I just pull it add a build1 version and throw it back up?
<Keybuk> bddebian: on which architectures?  I'm showing a successful build on i386, amd64 and sparc
<bddebian> Keybuk: It built successfully, it just needs a rebuild against some newer libs
<dholbach> ogra: no idea, sorry
<Keybuk> bddebian: then you will need a new upload
<dholbach> ogra: isn't 'ringing' enough? :)
<bddebian> Keybuk: OK, thanks
<ogra> dholbach, not in this house :) my office is upstairs and i like to work in the garden or in one of the balconies :)
<dholbach> ogra: the laptop speaker will ring
<ogra> dholbach, if i get a call on the desktop machine ? 
<fabbione> ogra: can't you just close ekiga from the ws and open it on the laptop?
<dholbach> ogra: you won't have run back in time, so you'd want to use ekiga on the laptop
<bddebian> Damn, I swore I sent lightspeed up already..
<ogra> sigh, ok, then i have to find out whats wrong with 2.6.17's usb-sound driver :)
<Treenaks> *something about scratching one's own itch* :P
<Gloubiboulga_> hello janimo 
<bddebian> Hmm, I wonder how gcl built.  It FTBFSs for me
<janimo> Gloubiboulga_: hi :)
<janimo> Gloubiboulga_: I'll start on the xfce packages as I said on the list
<Keybuk> raphink: note, it's generally a bad idea to set an importance on a sync request ;)
<ogra> janimo, !!
<ogra> welcome back !
<Keybuk> raphink: we tend to just assume those on the bottom are the new ones
<Gloubiboulga_> janimo, ok :)
<Keybuk> raphink: setting a higher importance means that we miss them unless we're concentrating
<janimo> ogra: thanks
<raphink> Keybuk: ah ok :)
<raphink> ic
<raphink> so I just confirm it and subscribe you
<raphink> thank you for the 3 syncs Keybuk :)
<Gloubiboulga_> hm, the new goffice is built on LP but is not on the repos yet (it's been uploaded last week)
<Gloubiboulga_> is there a problem somewhere?
<slomo_> Gloubiboulga_: it's on binary NEW
<Gloubiboulga_> ah ok, thanks slomo_ 
<Keybuk> fabbione: X query, if you're there?
<Keybuk> (or anyone, for that matter)
<Keybuk> we have an xterm patch to put the manpage in 1 not 1x
<Keybuk> do we still want that?
<Keybuk> oh, ignore me, it changed upstream anyway
<Keybuk> hmm, but Debian still has a patch to put it in 1x
<Keybuk> ok, so do we want to keep Debian's 1x patch, or our (and upstream's) 1 ?
<Kamion> Gloubiboulga_: I processed it through NEW this morning
<Kamion> Keybuk: "put it in 1x" is ambiguous
<Keybuk> Kamion: section
<Kamion> Keybuk: there are (still) two things that could mean - either the directory (/usr/share/man/man1 is correct, /usr/share/man/man1x is wrong) or the filename (xterm.1.gz or xterm.1x.gz; I'd lean towards the latter but it's not critical)
<Keybuk> filename
<Keybuk> we and upstream call it xterm.1.gz
<Keybuk> but Debian call it xterm.1x.gz
<Keybuk> and it's a patch we deliberately dropped, fwict
<Keybuk> I was wondering whether we still drop that
<crimsun> I've been dropping it.
<Kamion> Debian is arguably more correct here, though it's a nicety
<Gloubiboulga_> Kamion, thanks, I shouldn't trust packages.u.c :)
<Kamion> the directory is worth worrying about (and diverging from Debian if they get it wrong); for the filename, just going from minimal diff from our immediate parent is probably most sensible
<Kamion> Gloubiboulga_: (on the one architecture where it built ...)
<Kamion> https://launchpad.net/distros/ubuntu/+source/goffice/0.3.0-1ubuntu1
<Kamion> the others were probably transient problems though
<janimo> Gloubiboulga_: tried mailing goffice debian maintainer?
<Kamion> janimo: what for?
<janimo> so we don't carry the -gtk patch?
<Gloubiboulga_> janimo, not yet, I was waiting to get goffice/gnumeric uploaded
<janimo> Gloubiboulga_: ok, as he said he'd take it if it works in ubuntu.
<Kamion> ah
<Chipzz> so
<Chipzz> is anyone bothering with evolution-exchange ?
<Chipzz> apt-get dist-upgrade has been threatening me to remove it for over 3 days :P
<Keybuk> Chipzz: define "bothering"
<Hobbsee> Chipzz: is there a bug filed for it?
<Hobbsee> heh
<Keybuk> if you're complaining about a mere 3-day breakage in edgy, you're going to be ignored
<Hobbsee> Keybuk: does "bothering" happen to include removing it from the archive?  that could be fun.
<Hobbsee> Keybuk: break X on Chipzz in punishment hehe :P
<Keybuk> Hobbsee: X isn't broken anyway?
<gnomefreak> not yet
<Chipzz> Keybuk: I think it needs a rebuild
<Hobbsee> Keybuk: no, kdelibs4-dev is still installable today, so it cant be...
<Chipzz> Keybuk: I assumed that no-one had noticed the breakage
* Hobbsee needs to install edgy sometime.  she's putting it off!
<Keybuk> Chipzz: edgy is mid-merge ... you're lucky if anything works
<Hobbsee> Chipzz: --> launchpad and file a bug, if there's not already there == quickest and most useful way to tell someone.
<Keybuk> Chipzz: you clearly don't need evolution-exchange, because you wouldn't run edgy on a box you need
<Chipzz> Hobbsee: probably
<gnomefreak> i think i saw a bug on it already
* Hobbsee snorts
<Hobbsee> well with logic like that.... :P
<gnomefreak> Chipzz: this your issue too? https://launchpad.net/distros/ubuntu/+source/evolution-exchange/+bug/49142
<Ubugtu> Malone bug 49142 in evolution-exchange "Could not connect to Evolution Exchange backend process" [Untriaged,Unconfirmed]  
<Chipzz> # apt-get install evolution
<Chipzz> The following packages will be REMOVED: evolution-exchange*
<tseng> evolution-exhcange is built again "old" evolution
<dholbach> Chipzz: that's edgy?
<tseng> it needs rebuilt
<Chipzz> tseng: that's what I said
<Chipzz> dholbach: idd
<Keybuk> tseng: it currently FTBS completely
<tseng> Keybuk: *unsuprised8
<tseng> Keybuk: took months to get evolution-sharp updated
<Keybuk> this is a completely pointless discussion
<Keybuk> it's edgy
<Chipzz> the reason I'm "whining" is because in most cases breakage gets noticed and fixed really fast
<tseng> yes, it really is
<Keybuk> Chipzz: EDGY ... MERGES ... STFU :p
<tseng> it is completely obvious to the developers
<Chipzz> nm :P
<dholbach> Chipzz: the whole stack is broken atm, and its being fixed - don't use edgy, if you can't live with breakage... sorry
<Keybuk> Chipzz: we're not making any attempt to make anything build or be installable until after UVF
<Chipzz> guys, I was merely pointing out that the package was broken in case no-one noticed yet; I really don't want this whole discussion ;P
<infinity> doko: Did you drop the syck change that turned off optimisation in the testsuite?
<infinity> Mithrandir: That was the fix for amd64, right?
<doko> infinity: hmm, apparently
<infinity> doko: Kay, I'm going to kill the amd64 build that's been spinning for the last hour, if you can upload a fix for me.
* Hobbsee advises Chipzz to be quiet, or risk the wrath of keybuk.  $mypetbugs only get fixed by accident during merging - they're not the highest priority at the moment.
<bddebian> ohh, hamlib failed to build, no wonder
<Hobbsee> bddebian: ah, and that's why i cant seem to get to it.  excellent.
<bddebian> Hobbsee: Aye :-)
* Hobbsee makes a note to ignore ktrack for a while longer  :P
<bddebian> Hobbsee: I'm going to look at it now
<Hobbsee> bddebian: cool :)
<ogra> mumble, mumble ... 
* ogra drops his unuploaded kino merge
* bddebian curses python->2.3 dependent packages
<Keybuk> ogra: you weren't the last to touch it, so stop grumbling ;P
<ogra> Keybuk, well, i listed it on my "to merge" packages the last two meetings :P
<Keybuk> ogra: any particular reason?  I made the changes to it
<ogra> Keybuk, its in main for edubuntu, but i'm fine that you merged it 
<bddebian> Is python2.3-dev borked in Edgy?
<Kamion> ENOCONTEXT
<bddebian> The following packages have unmet dependencies:
<bddebian>   python2.3-dev: Depends: python2.3 (= 2.3.5-9ubuntu1) but it is not going to be installed
<ogra> we have python 2.3 stuff in edgy ? 
<Keybuk> bddebian: I believe your paste answers your own question
<bddebian> Keybuk: Aye but I can't do anything about it
<Kamion> bddebian: general method for investigating that kind of problem is to 'apt-get install' the thing(s) that it's complaining about explicitly, and iterate until you get to the thing that's actually broken
<sivang> bddebian: all packages should use 2.4-dev, AFAICT, at least, all the apckages I have touched had patches to use 2.4-dev instead of 2.3-dev
<mdke> pitti: in case you haven't seen it yet - https://lists.ubuntu.com/archives/ubuntu-translators/2006-July/000724.html
<Kamion>  python2.3 |   2.3.5-14 | edgy/universe | source
<Kamion> ^-- not built yet
<bddebian> sivang: Agreed but hamlib specifically build-conflicts python2.4
<sivang> bddebian: ah, then just wait for it to be built I guess
<Kamion> doko: python2.3 2.3.5-14 ftbfs looks like a bug
<sivang> bddebian: or build it yourself in the meanwhile..
<Kamion> e.g. http://librarian.launchpad.net/3288053/buildlog_ubuntu-edgy-i386.python2.3_2.3.5-14_FAILEDTOBUILD.txt.gz
<bddebian> Kamion: I know but I don't have an Edgy machine and pbuilder login is a pita :-)
<Kamion> bddebian: that's nice
<sivang> bddebian: use edgy :) I use it on my laptop
<Hobbsee> bddebian: pbuilder login isnt *that* bad :P
<bddebian> Hobbsee: No, works good it's just slow to setup/etc for a quick test :-)
<Hobbsee> bddebian: that is true
<Hobbsee> also
<doko> Kamion: known, low prio at the moment
<doko> pitti: tetex-extra fails to configure in dapper-updates
<Kamion> doko: fair enough
<Kamion> iwj: can your dpkg symlinks-to-same-directory file conflict patch go up to Debian, or is it too experimental/doubtful/broken?
<iwj> Kamion: I think I already submitted it to the BTS with a note saying `please apply this'.
<iwj> Let me check.
<iwj> Hmm.  I can't seem to find a record of that.
* iwj looks some more.
<pitti> mdke: yep, I investigated this today, and it's a complete miracle; build-langpacks.sh and apt-ftparchive DTRT when I run it manually, but fail when running from cron
<pitti> mdke: I added some debug code to the script and will see what breaks tomorrow
<pitti> mdke: but thanks for pointing out
<pitti> doko: oh, with the tetex-bin in d-updates? is there any bug report for that?
<iwj> Kamion: No, I seem to have omitted to do that.  But it should go to Debian and given the testing it's had since I invented it I'm confident in it.
<iwj> Kamion: Do you want me to submit it ?
<iwj> Sorry for not doing that sooner.
<Kamion> iwj: sounds like a good idea; it's our last diff versus Debian
<Kamion> (I just merged 1.3.22)
<iwj> Right.
<iwj> I'll do that now.
<Kamion> thanks
<Kamion> makes more sense coming from you than from this humble merge-monkey
<iwj> *snort*
<iwj> You mean `you have a chance of remembering what on earth it was all about'.
<Kamion> that too ...
<bddebian> merge-monkey?
<doko> pitti: bug 52555
<Ubugtu> Malone bug 52555 in tetex-base "tetex-extra failts to configure" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52555
<pitti> doko: thanks, I'll check that in a clean chroot
<gnomefreak> who maintains xservwer-xorg-core?
<Hobbsee> gnomefreak: apt-cache show?
<Kamion> ubuntu-x-swat
<bddebian> Anyone know of a POSIX compliant version of this?  rm -f $${$@%.rm}
<bddebian> Seems to fail on dash
* Kamion scratches head
<Kamion> what does that even mean in bash? :)
<Kamion> $@ being the positional parameters
<bddebian> No freakin' clue :-)
<bddebian> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=376806
<Kamion> looks like garbage to me; can you point me at the context?
<Kamion> ah
<Ubugtu> Debian bug 376806 in gcl "Subject: gcl: FTBFS: bashisms in debian/rules" [Important,Open]  
<Kamion> oh, it's within a makefile
<iwj> Ahhhh.
<bddebian> Kamion: debian/rules to be precise
<mdke> pitti: cool, thanks
<iwj> ${<filename>%.rm}
<Kamion> use make's own text-handling functions if you're working on a make variable
<bddebian> iwj: rm -f $${$@%.rm} -> rm -f ${<filename>%.rm}  ?
<iwj> bddebian: It's transformed like that by make.
<pitti> bddebian: that won't work, you need $$ to escape the $ from make
<bddebian> Hmm
<iwj> You can see that in the bug report you reference.
<Kamion> rm -f $(patsubst %.rm,%,$@)
* pitti always thought that ${var%suffix} was posix sh
<iwj> ${...%...} is supported by SuSv3.
<Kamion> pitti: it is, but var has to actually be a variable not random text
<pitti> oh, heh, true
<iwj> Oh, duh!
* iwj bangs his head.
<bddebian> Why not just rm -f debian/control.rm since that is all that is passed to it?
<iwj> Don't ask me.
<pitti> bddebian: maybe it's not 31337 enough?
* Kamion extracts the package to loo
<Kamion> k
<iwj> Why write what you mean in a makefile when you can make it (a) complicated, (b) wrong and (c) unportable all in one go ?
<Kamion> $ echo ${foo.rm%.rm}
<Kamion> -bash: ${foo.rm%.rm}: bad substitution
<Kamion> bash does that too ...
<LaserJock> iwj: lol
<bddebian> Kamion: I know, it ftbfs'd for me to with bash :-)
<bddebian> I wonder how it built on the buildd
<pitti> bddebian: btw, this would be 'rm debian/control' (without the .rm), but this looks fishy, too :)
<bddebian> Oh
* bddebian starts to wonder again why he is here :'-(
<Kamion> debian/control.rm:
<Kamion>         rm -f $${$@%.rm}
<Kamion> debian/control: debian/control.rm
<Kamion>         cp debian/control.$(EXT) debian/control
<Kamion> personally I'd do the patsubst thing and pray I never have to look at that makefile again
<ogra> bddebian, as some buddhists say, to raise your karma ;)
<bddebian> ogra: Well I'm stupid, I have too much going on in RL and I seem to piss -devels off :-(
<pitti> Kamion: does it modify debian/control at all after copying it? on-the-fly debian/contol's are so evil...
<Kamion> pitti: no idea, don't want to find out
<sivang> pitti: I so much agree , they are EVIL
<bddebian> So what should I do?
<sivang> iwj: to win a write-once read-never content? :)
<sivang> s/content/contest/
<Kamion> bddebian: 17:19 < Kamion> personally I'd do the patsubst thing and pray I never have to look at that makefile again
<bddebian> Kamion: OK, thx
<pitti> bddebian: IMHO, the best would be to just create a static control and throw away all the rewriting stuff, if that's reasonable
<pitti> bddebian: (depends on what this actually does to the .rm file to produce d/control)
<bddebian> pitti: I will ask Debian maintainer to do so :-)
<pitti> bddebian: yep, file a serious bug, that helps getting attention :)
<Kamion> pitti: the .rm thing is just a magic target to arrange for debian/control to be removed (why bother? but hey); control.$(EXT) is the thing that actually gets copied
* pitti stops thinking about it before his brain starts to revolt
<pitti> (... starts revolting?)
<bddebian> This freaking thing takes forever to build too :-(
<bddebian> OK, can I ask another question without getting lynched? :-)
<Kamion> nobody lynched you
<pitti> bddebian: no, we can't /msg you an ice cream, sorry
<bddebian> heh
<bddebian> Kamion: No, not on this, thank you all for the help, BTS
<bddebian> Err BTW
<bddebian> hamlib builds fine with python2.4 however it has a binary package python2.3-hamlib2.  Can I make that python2.4-hamlib2 or should I just wait for python2.3 to get fixed?
<Kamion> python2.4-hamlib2 should be fine, but it should also be converted to the new python policy (which would make it python-hamlib2 once all the other necessary changes are made)
<Kamion> but if you don't feel up to that, python2.4-hamlib2 is fine; just check reverse dependencies
<bddebian> Well I would need to check reverse-deps if I did python-hamlib2 anyway wouldn't I?
<Kamion> yes
<bddebian> So if I did that, build-deps should just be python-dev and python not versioned right?
<Kamion> bddebian: it's not that simple - see the new python policy
<Kamion> it is not a cut-and-paste conversion
<ogra> pitti, hmm, very intresting, my headset doesnt work with 2.6.15 either, seems gnome-sound-properties is automatically set back to the internal soundcard after 1-1.5mins
<bddebian> OK, well this starts to lead into my issues.  How much do we stray from Debian?  This is always puzzling to me
<Kamion> we want to convert everything to the new python policy; however there is a team in Debian actively doing the conversion so it may not be worth your while to learn how to do this one
<sivang> Kamion: wouldn't be able to just sync up from debian once they have finished the conversoin?
<pitti> ogra: the only thing that resets the default card known to me is gnome-volume-manager, when it sees that you just removed the default device
<Kamion> sivang: yes
<bddebian> sivang: Yes but it's holding up other merges/syncs
<pitti> ogra: can you check whether the settings in ~/.asoundrc.asoundconf change after that time?
<ogra> pitti, nope, they dont change
<pitti> ogra: hm, then it's not g-v-m
<ogra> !defaults.pcm.card Headset
<ogra> defaults.ctl.card Headset
<ogra> defaults.pcm.device 0
<ogra> defaults.pcm.subdevice -1
<pitti> ogra: g-s-p reads the default card directly from alsa normally
<ogra> g-s-p shows "Snapper"
<pitti> ogra: anything helpful in dmesg?
<ogra> nope
<ogra> neither in .xsession-errors
<pitti> ogra: oh, Snapper? that's the internal card
<ogra> yeah
<ogra> it flips back to that after the time 
<ogra> i can select the headset and hear sound again ...
<ogra> then after 30sec up to 1.5mins it flips back again
<sivang> bddebian: maybe we can just wait with those and stack them up, and then do them in mass once the transition is over?
<pitti> ogra: do you have esd running?
<pitti> ogra: do you get the same behaviour without esd?
<dholbach> seb128: woohoo - seems like the 'themes' problem gets solved for us: some of the unmaintained themes were stripped from 2.15.4 :-)
<pitti> ogra_: did esd kill your session? :)
<ogra_> grmbl
<ogra_> i hate hate hate broadcom
<ogra_> no my regular 2h network crash happened
* pitti pats ogra_
<ogra_> thats definately my last apple
<pitti> ogra_: it works just wonderfully here since pre-dapper...
<ogra> pitti, hmm, now the headest is selected all the time if i start g-s-p but sound only comes out of the speakers ...
<ogra> funny
<ogra> aha
<pitti> ogra: well, without esd you have to restart the player
<ogra> but i get errors now 
<pitti> ogra: esd can switch on the fly, but not apps using libasound directly
<ogra> ALSA lib conf.c:3479:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory
<ogra> ALSA lib conf.c:3947:(snd_config_expand) Evaluate error: No such file or directory
<ogra> ALSA lib pcm.c:2146:(snd_pcm_open_noupdate) Unknown PCM dmix:CARD=Snapper,FORMAT=S16
<ogra> /usr/bin/esd: Kein Prozess beendet
<ogra> funnily snapper is selected and plays sound :)
<ogra> i see that error if i try to switch cards in g-s-p
<ogra> not using esd doesnt change the bahavior btw, it still flips back to snapper
<ogra> (oh and i'm using totem-gstreamer as player ... esd shouldnt affect that at all)
<fabbione> Keybuk: i don't care.. personally. i would prefer to drop as much Ubuntu custom as we can and go Debian and iirc in dapper i did a last minute merge that was taking us very close to that
<fabbione> Keybuk: *probably* we can just sync
* bddebian dist-upgrades his machine at works and crosses his fingers :-)
<Keybuk> fabbione: we have a bug-fix patch so we can't sync
<fabbione> Keybuk: ok :)
<Keybuk> and I got the patch from the Debian BTS in the first place, so it's not a candidate for pushing to Debian :p
<bddebian> Boy that sounds familiar
<fabbione> Keybuk: hehe
<glatzor> ping doko
<DaSkreech> Hello
<DaSkreech> Who was working on the usplash for dapper?
<glatzor> DaSkreech: artowrk or code?
<glatzor> artwork
<DaSkreech> Ermm code I should think
<doko> glatzor: just speak up
<DaSkreech> I wanted to find out why the countdown on shutdown was repalced with a countup
<glatzor> Hi doko. I worked on gnome-app-install, that is written in python. I finally tested the app with atk enabled and it crashes with "Illegal instruction"
<DaSkreech> Where can I find the changelogs so I can see if a reason was given?
<doko> glatzor: nice :)
<LaserJock> DaSkreech: http://changelogs.ubuntu.com/changelogs/pool/main/u/usplash/
<glatzor> doko: I am on a dapper powerpc. Do you have got any idea? I found some older bug reports using google. But either they haven't been answered at all or wer closed with "we think the new version of python fixes this"
<DaSkreech> LaserJock: Thanks
<pitti> G0SUB: ping
<doko> glatzor: are you able to verify on a non-powerpc architecture?
<glatzor> doko: No :/
<glatzor> But I could send the packages to anybody who is willing to help :)
<doko> glatzor: then please submit a bug report, with a reduced testcase, if possible
<pitti> mdz: ok to upload the cups regression (bug 52390) to dapper-updates?
<Ubugtu> Malone bug 52390 in cupsys "cupsys 1.2.1-0ubuntu1 doesn't support 11.22.33.* network masks" [High,In progress]  http://launchpad.net/bugs/52390
<glatzor> doko: I cannot locate the error exactly.
<doko> mdz: https://wiki.ubuntu.com/OpenOfficeL10n is still open should be done.
<Keybuk> pitti: ping? (re hal derooting)
<pitti> hey Keybuk 
<Keybuk> pitti: did we or Debian de-root hal?
<pitti> Keybuk: I did the initial derooting back in warty
<pitti> Keybuk: the current architecture (small master instance as root, main process as haldaemon) was done by Debian (sjoerd)
<Keybuk> ok
<Keybuk> so that would explain why n-m doesn't work properly a lot of the time :)
<Keybuk> <policy user="hal">
<Keybuk>      <allow send_destination="org.freedesktop.NetworkManager"/>
<Keybuk>      <allow send_interface="org.freedesktop.NetworkManager"/>
<Keybuk> </policy>
<Keybuk> ^ DanW says we need that
<pitti> Keybuk: ooh
<pitti> Keybuk: s/hal/haldaemon/
<Keybuk> right
<pitti> Keybuk: but the current derooting behavior is upstream since hal 0.5.7 (for quite a while now)
<mdz> pitti: why does that patch use pointer arithmetic instead of simple array subscripting?
<Keybuk> pitti: RH could be using older or re-rooted hal?
<pitti> mdhow do you mean?
<pitti> mdz: how do you mean?
<seb128> dholbach: I know, that's a part of the changes we spoke with Thomas during GUADEC
<seb128> dholbach: he wants to move the accessibility themes to the a11y capplet too
<mdz> pitti: 
<mdz> ++    unsigned val[4] ; /* IPv4 address values */
<pitti> Keybuk: hm, RHEL certainly does, but fedora 4 should have the latest hal, too
<mdz> ++    ipcount = sscanf(value, "%u.%u.%u.%u", val + 0, val + 1, val + 2, val + 3);
<pitti> mdz: you mean &val[1]  instead of val+1?
<mdz> pitti: yes
<mdz> I see it is just renaming the variable and preserving the style of the old code
<pitti> should be perfectly equivalent
<pitti> mdz: I don't know the reason
<mdz> it is, it's just a bit weird
<mdz> doko: does oo.o use hunspell or myspell now?
<pitti> mdz: uploaded, thanks for review; can you ack it in the queue in some minutes?
<doko> mdz: hunspell, but myspell dicts still work
<mdz> slomo_: is bug #52561 related to your changes?
<Ubugtu> Malone bug 52561 in dbus "E: removing Assembly /usr/lib/mono/gac/dbus-sharp/0.60.0.0__9eef2692033670f5/ failed" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52561
<ogra> grrr
* ogra kicks edgy badly
* tseng watches edgy kick back
<ivoks> it's not edgy's fault! don't
<ogra> it is !
<ivoks> :)
<DaSkreech> So that's why it's called kicking the bleeding edge habit
<ogra> well, indeed i could blame the single apps ... like evo wiping my gpg keys 
<ogra> or gstreamer or whatever for flipping soundcards all the time
<ogra> or broadcom for building crappy wlan cards ...
<ogra> but its so much easier to just blame edgy :P
<pitti> ogra: the card is fine, curse at them for not releasing drivers or specs :)
<ogra> pitti, well, i seem to be the only one where the card causes reboots and hardlocks
<pitti> ogra: hm, true, maybe your's is indeed broken physically
<slomo_> mdz: do you have mono-gac 1.1.13.8-1ubuntuX and cli-common 0.4.3?
<ogra> intrestingly it doesnt work at all with the firmware of our fwcutter package 
<ogra> i have to use the one from my os X cd
* ogra had to bear the HDD check twice today already because of the amount of reboots ...
* pitti hands ogra an ethernet cable
<slomo_> mdz: and does the dll still exist?
<ogra> pitti, no wired ethernet yet in this house
<ivoks> ok, anyone interested in syncing inkscape from sid?
<ogra> ivoks, didnt that happen last week already ? 
<ogra> i think it ftbfs
<ivoks> 0.43 is in edgt
<ivoks> ah, source is 0.44
<ivoks> hm
<ivoks> sorry for distraction :)
<ivoks> looks like libpango error
<ogra> pitti, bug 52552, is there a way to get these .xml files into the langpacks ? 
<Ubugtu> Malone bug 52552 in gcompris "only english or german descriptions displayed" [Untriaged,Rejected]  http://launchpad.net/bugs/52552
<slomo_> mdz: also what was updated before in the same apt run?
<pitti> ogra: no reasonable one ATM; why not just ship them in the application deb?
<ogra> pitti, afaik they are in there ...
<pitti> ogra: ah, I think the locales are just missing
<pitti> ogra: you can't select Catalan if you don't have ca_ES.UTF-8 locale
<ogra> yes
<ogra> but the base language pack should have generated them
<ogra> or am i wrong ? 
<pitti> ogra: only if he actually had l-p-es installed
<pitti> erm, l-p-ca, of course
<ogra> what about his last comment ?
<pitti> ogra: that sounds like a bug in gcompris proper
<ogra> do we still support crappy UTF-8@euro stuff ? 
<pitti> ogra: no, UTF-8@euro is evil
<ogra> yeah
<ogra> but he was offered it in gdm apparently
<ogra> pitti, btw, if i use xmms to listen to music with direct alsa output, the sound stays at the headset, so i blame the gstreamer layer 
<ogra> but why do we have a debian skin in xmms by default ? 
<xhaker> ogra: looks kinda integrated in the distro.. nobody was poked to do a Human kin
<xhaker> skin*
<pitti> mdz: can you please release cupsys for dapper-updates?
<ogra> xhaker, well, if i'd like blue and brushed metal i'd probably not use ubuntu :)
<ogra> but i know there was a ubuntized theme for it ... i wonder where its gone
<xhaker> ogra: http://anka.org/henrik/humanxmms/
<xhaker> look nice
<ogra> thats old, there was an updated one as well ..
<ogra> but its ccbysa licensed, so we could include it ...
<xhaker> bugger
<bddebian> Damn, where'd everybody go? :-)
<jjesse> we left
<LaserJock> we are ignoring you
<zul> all i hear is the basoon playing
<HiddenWolf> sivang: ping: system-cleanup-tool, will you make sure it takes a look at ~/.thumbnails, please?
<bddebian> LaserJock: Well that I would expect :-)
<LaserJock> bddebian: lol, you know we love you ;-)
<bddebian> LaserJock: YOU only love me 'cause I hit your Science packages ;-P
<DaSkreech> Science Biology or science chemistry?
<LaserJock> DaSkreech: Science science, but I prefer the chemistry kind ;-)
<DaSkreech> Well as long as it's Science Fiction :)
<LaserJock> bah
<LaserJock> bddebian: how has the .desktop battle been going?
<bddebian> LaserJock: Actually better than I expected.  Though I did have 1 DD ask "What is a desktop file?" :-)
<seb128> bddebian: you do push .desktop patches to Debian?
<bddebian> seb128: Yes, should I not be?
<sivang> HiddenWolf: could you please add something about it to the spec proposal so I can merge and not forget about it? :)
<seb128> bddebian: as said by mail I still think you lower the quality of the distribution because you ship something that works only for english people
<seb128> bddebian: are you an english native speaker? or using an english locale?
<HiddenWolf> sivang: sure
<bddebian> seb128: Why do they only use English?  Desktop files can have translations
<bddebian> I am a native English speaker btw
<seb128> so you don't notice what you break
<seb128> bddebian: for the reasons I mentionned by mail, it would require translators to open a bug every time they have an update, would force the maintainer to update the package everytime a translation needs to be changed
<bddebian> seb128: As opposed to what?
<seb128> bddebian: few people do track packages specific strings to translate them
<seb128> opposed to people commiting to the upstream CVS which has a translation team
<seb128> and having all the translations changed rolled with the new tarballs
<seb128> system were translated can work directly
<seb128> by opposition to opening 48 bugs and doing 48 uploads if you want to get 48 translations for your package 
<seb128> by shipping a .desktop with the package you usually say you don't care about non-english desktops which will have that non-translated entry
<seb128> because I doubt any maintainer is wanting to do receive a bug every time a translator has a typo to fix or a new translation
<bddebian> seb128: No, by adding a .desktop file I say it can have a menu entry in Gnome or KDE instead of having to be started from a terminal session
<seb128> let me start again
<seb128> seems you missed the point
<seb128> the place for that is *upstream*
<seb128> upstream which has translations team
<seb128> upstream where translators can work without opening bugs for the maintainer and requiring a new upload
<bddebian> And if there is a new upstream "release" because of translations would it not require a new upload?
<seb128> if you read upstream changelog you will notice "translations update" 
<seb128> translations are updated with every new version
<seb128> that's a part of the deal
<seb128> translators can work between versions to fix whatever they want
<slomo_> and normally there are no new versions just for new translations
<bddebian> So are you also suggesting I should not be including them in Ubuntu packages until they come from Upstream?
<seb128> right
<bddebian> Works for me
<bddebian> So I won't merge my desktop files from Dapper either?
<seb128> have you read my mail on the list?
<seb128> the decision is up to you, but I don't think that worth having to create a diff from Debian, especially because it's a non-translated item
<seb128> that should be sent upstream and waiting for the next version is probably fine usually
<bddebian> seb128: Then why did we have such a big push for desktop files?  Or was the intent from the get-go to get them upstream and I somehow missed that?
<seb128> bddebian: because some MOTU guy decided that was a good idea
<seb128> and made a wiki page
<seb128> and other people decided to run with him on that
<seb128> I already pointed the translations and diff work from Debian issues when you guys started
<seb128> after that people do what they want ...
<seb128> you can discuss than a non translated menu item is better than no menu item
<bddebian> Well I somehow missed that so I apologize
<seb128> but in any case such patches should go directly upstream
<LaserJock> seb128: I was unaware of that (though it makes sense) but to a certain extent I feel it is bad for us to ship apps that don't show up in a menu
<seb128> LaserJock: so send patches upstream
<LaserJock> seb128: well, for some that might work, others unlikely
<seb128> you work at the wrong place
<LaserJock> seb128: your translation argument only works if upstream will translate it
<seb128> no reason upstream would not accept it if that's a good idea
<LaserJock> and is alive
<seb128> if they don't you might ask yourself if you really need it
<seb128> right
<seb128> if you don't send it upstream so send it to Debian
<seb128> so you don't create hundred of packages diffs due to that
<LaserJock> right
<seb128> and you make Debian people happier by sending back
<seb128> and your reduce the MOTU workload
<LaserJock> sure, that's what we are trying to do
<pitti> slomo_: can you please commit your hal modifications into bzr?
<seb128> LaserJock: cool then
<LaserJock> I guess it's a matter of "get it in quick to Ubuntu, then send upstream and wait to sync" or "send upstream and wait for it to trickle down to Ubuntu"
<seb128> some MOTU seem to not bother to "send upstream"
<LaserJock> that, we are trying to correct, for sure. It is a bit of a learning process for some
<seb128> cool :)
<darius_> Alright, it's been over a month - must bring up bug # 30557 again
<Mez> !bug 30557
<Ubugtu> Malone bug 30557 in linux-source-2.6.15 "cpu idle time in /proc/stat wrong" [Medium,Confirmed]  http://launchpad.net/bugs/30557
* bddebian crawls back in his hole
<mdz> pitti: will do
<pitti> mdz: thanks
#ubuntu-devel 2006-07-11
<ritvik> I hibernated the system .... after resume my usb keyboard was working but usb mouse was got stuck any idea what logs should I include while filing this bug? 
<jsgotangco> good morning
<Burgwork> jsgotangco, what is the addy for the fridge people?
<jsgotangco> i dunno they have a private list though
<jsgotangco> fridge-devel?
<mdz> jsgotangco: yes, that's the one
<jdub> mdz: would you be comfortable with pulseaudio being setuid (so it can grab realtime priority)?
<jdub> mdz: or would you want to attack that a different way?
<jdub> mdz: noting that it drops all privs (apart from the realtime capability) on startup... but can also be network-visible
<mdz> jdub: if it drops privileges immediately, it shouldn't be a problem
<jdub> see #11 in the faq here: http://pulseaudio.org/wiki/Documentation#FrequentlyAskedQuestions
<wasabi> What's the current plan with all that stuff, seeing as alsa has dmix now?
<Lathiat> i thought dmix had been around for a long time, and was generally kindof working but often broke?
<jdub> there are plenty of interesting problems that dmix doesn't solve
<jdub> so it's nice that it's there
<jdub> but ultimately it is poo
<wasabi> caching sound bytes, etc?
<jdub> *cough*
<jdub> source volume mixing, caching, smart mixing, desktop integration, etc., etc.
<wasabi> True. Wondering what the plan is for Pulse AND Alsa/OSS at the same time though.
<wasabi> Pulse doesn't seem to fix that on it's own. Looks like it's super smarter about closing devices though.
<jdub> directly in ubuntu, no plan
<wasabi> Unless you send alsa through pulse... that sounds kinda iffy though
<jdub> in general in the desktop community, that is being worked on (and includes pulse in the recipe)
<jdub> alsa -> pulse and fus[ed]  for /dev/dsp
<wasabi> Is Pulse able to take advantage of hw mixing support if available?
* wasabi reading the FAQ
<Hobbsee> morning all
<Lathiat> crazy, you can have multiple senders and receivers multicasting with this RTP stuff
<Lathiat> thats pretty nuts
<_ion> Huh? Isn't that pretty much the point of multicasting?
<Lathiat> _ion: yeh but with audio :)
<Lathiat> and you can combine two stereo sound cards into a virtual surround.. heh
<_ion> They will run out of sync eventually.
<Lathiat> "Please keep in mind that PulseAudio will constantly adjust the sample rate to compensate for the deviating quartzes of the sound devices. This is not perfect, however. Deviations in a range of 1/44100s (or 1/48000s depending on the sampling frequency) can not be compensated. The human ear will decode these deviations as minor movements (less than 1cm) of the positions of the sound sources you hear."
<rodarvus> sladen: ping
<rodarvus> I'm merging our X drivers to their Debian counterparts
<rodarvus> I noticed you created a half dozen patches for xserver-xorg-driver-i810
<rodarvus> but these patches do not apply cleanly to the new version (1.5.1.0)
<sladen> rodarvus: most of those are pulls from upstream CVS, they /should/ all be in new upstream pulled via Debian
<rodarvus> oh, thats nice
<sladen> rodarvus: if any of the issues are still around later in the release cycle I'll approach them again
<rodarvus> sladen: I propose we sync from Debian (1.5.1.0) and from there, we can apply patches that are still relevant, if any
<sladen> rodarvus: yes, I'd prefer a straight sync, stabilise that and work from there
<rodarvus> sladen: nice! thanks a lot!
<sladen> rodarvus: if any of our patches haven't gone back to xorg, we've screwed up
<rodarvus> :)
<sladen> rodarvus: how are you coping with cleaning up the mess left by the package renaming?
<rodarvus> sladen: adding Conflicts/Replaces to each of our previous drivers, syncing when possible, merging otherwise
<rodarvus> after we are done syncing/merging the drivers, its just a matter of updating xorg to ship xserver-xorg-video-all, instead of xserver-xorg-driver-all
<rodarvus> sladen: almost there, btw - I've done 39 drivers today, only two missing (i810 included)
<rodarvus> (most of them were almost-sync cases, though)
<sladen> rodarvus: oooh, excellent.  
<rodarvus> mdz: ping
<mdz> rodarvus: pong
<rodarvus> mdz: are you able to reject two packages in NEW for me?
<mdz> rodarvus: sure
<rodarvus> I uploaded xserver-xorg-video-mga and xserver-xorg-video-rendition to NEW, with stripped source code (this code was stripped from Debian version but not from ours)
<rodarvus> mdz: thanks
<rodarvus> binary blobs which are not dfsg compliant but which we can distribute
<Eleaf> hmmmmm
<bluefoxicy> agh
<bluefoxicy> If anyone cares, I am trying to convince the GCC devs that it is useful to pass function and file to the stack smash protection catch functions so that distro-side we can nab the data as soon as the bug is first triggered and patch the bug as early as possible
<bluefoxicy> they do not believe that this is useful, apparently either A) the end user should debug it with a debugger (NOT GOING TO HAPPEN); or B) the developer should debug it with a debugger (IF HE CAN REPRODUCE THE PROBLEM)
<bluefoxicy> I am fairly certain there are times when bugs actually get triggered very rarely and are hard to reproduce, so I think we need to be able to opportunisticly collect this data.  How that code gets used is up to distro patching (you could patch libssp0 to log to syslog() for example and then have a daemon watch syslog() and ask the user to send a report back to Ubuntu)
<bluefoxicy> anyway.
<bluefoxicy> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28328 and http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28334 (I am more interested in 28328; we can easily do 28334 distro-side but doing 28328 distro side causes BREAKAGE AND INCOMPATIBILITY)
<Ubugtu> gcc.gnu.org bug 28328 in other "Stack smash protection non-verbose" [Normal,Unconfirmed]  
<bluefoxicy> If anyone is interested.
<jsgotangco> \o/
<Burgundavia> Seveas: ping
<Mithrandir> infinity: (re syck), yes, -O0 makes the testsuite not fail, iirc.  It's the wrong fix, but the code is messy and I don't really care enough to fix the test suite properly.
<pitti> Good morning
<Kagou> hi
<sivang> Good morning
<pitti> hi sivang 
<sivang> hey pitti , what's up?
<freeflying|away> pitti: hi
<pitti> hi freeflying|away 
<pitti> sivang: yesterday, my first crash report saw the light of the day (or, rather, the space of /var/crash/ :) )
<freeflying> pitti: would you mind review a package, it's in main, I do some improvement for it(scim-chewing)
<sivang> pitti: heh
<sivang> pitti: was it related to SSP on PPC ? :-)
<pitti> freeflying: sure, if you send me a debdiff, I can upload it
<pitti> sivang: no, just some test crashes to try my new crash-reporter agent
<freeflying> pitti: thx, I'd send you soon
<pitti> freeflying: I can't judge the functionality, though, I trust you for that :)
<sivang> pitti: oh nice, have you uploaded it already so it can be tested?
<sivang> pitti: how do you know when a crash has happened also ?
<pitti> sivang: no, not yet; it's in bzr if you want to play with it
<pitti> sivang: but I still need to add packaging bits so that it works OOTB
<pitti> sivang: pure magic :)
<pitti> dholbach!
<pitti> dholbach: Guten Morgen
<dholbach> heyy pitti, good morning everybody
<jsgotangco> hello
<dholbach> heya jsgotangco
<sivang> pitti: :-)
<sivang> dholbach: !
<sivang> yo jsgotangco 
<dholbach> hey sivang
<jsgotangco> sivang: hi!
<\sh> moins
<pitti> hi \sh 
<seb128> dholbach: do you know if janimo knows he's supposed to do syncs with Debian for xfce too?
<dholbach> seb128: i suppose so, he's on a trip atm - gloubiboulga knows more (and might want to do some of the syncs)
<seb128> dholbach: I'm asking because he's doing uploads to edgy atm and those have no sync mention
<dholbach> seb128: gloubiboulga, right?
<seb128> no
<seb128> Changed-By: Jani Monoses <jani@ubuntu.com>
<dholbach> hu?
<seb128> cf edgy-changes list
<dholbach> hum
<Seveas> Burgwork, pong
<freeflying> pitti: it's not decided by I only, I have talked this with other guys in ubuntu-cn
<pitti> hi doko
<doko> pitti moin
<dholbach> ogra: how is gnome-power-manager coming along?
<freeflying> pitti: sent debdiff to you
<dholbach> ogra: and yet another gnome-screensaver! :-)
<Mithrandir> ogra: are you going to release knot-1 too soonish? 
<Mithrandir> Riddell: are you going to release knot-1 too soonish? 
<ogra> Mithrandir, end of the week was the planned date, no ?
<Mithrandir> ogra: it is, but that means looking at http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html is becoming a better idea by the hour.
<ogra> Mithrandir, fixing the seeds is on my list for this week... i *only* have the g-p-m megre to finish  :)
<dholbach> ogra: you want to do the gnome-screensaver update?
<dholbach> oh
<dholbach> seems we didn't do that merge either
<ogra> dholbach, how should we merge that :) debian is behind in versions
<ogra> i carried the patches over that were not applied upstream yet
<dholbach> hu?
<dholbach> should be no trouble to merge it, no?
<ogra> we have g-s-s 2.15
<seb128> ogra: like we did for everything GNOMEish?
<ogra> they still have 2.14
<seb128> and?
<seb128> get their package
<seb128> and update to 2.15 from it
<ogra> and i merged the patches into 2.15
<ogra> additionally i sent most of them upstream (modulo the gconf changes he didnt want)
<seb128> job easier for you if everything is upstream
<seb128> take the Debian package
<seb128> run dch
<ogra> so i hope one of the newt version will carry them upstream
<seb128> write your changelog
<seb128> upload
<ogra> we never had a package that was even near the debian one 
<seb128> if there is some Ubuntu changes required use them
<seb128> that's why we do merges from Debian
<seb128> to get packages nearer of them
<ogra> we shipped g-s-s one release ahead of them and they packaged it completely differently
<seb128> and?
<seb128> it there any interest to keep a different packaging?
<ogra> since that wont change i we'll have to merge it anyway
<seb128> so why do you discuss it?
<ogra> i dont see the advantage ...
<seb128> I can merge it if you want ...
<seb128> I know how to do :p
<ogra> i have to merge it *every* release and have to look at their packaging anyway
<seb128> why every release?
<ogra> so why should we not keep the packaging we have
<seb128> I don't get your question
<ogra> because we'll be ahead one version in every release
<seb128> we try to be near of Debian, i.e: base the packages on Debian when we can
<seb128> grumpf
<dholbach> anyway we can take good packaging changes, that's not a matter of a version number
<ogra> so it doesnt really matter since its every time a manual merge
<seb128> let me make it clear for you
<seb128> - take the debian package
<seb128> - apply the ubuntu changes to it
<seb128> - update the package for 2.15
<seb128> then you have a 2.15 package merged from Debian
<ogra> *sigh* thats so pointless
<seb128> and you can update than one when the new version come
<seb128> you can argue than merges have not useful
<ogra> i have to merge it manually *anyway* 
<ogra> whats the point here ? 
<seb128> but we decided to merge on Debian
<seb128> enough discussion with you, feel free to do whatever you want, if you think your packages should not be merged with Debian that's up to you
<dholbach> the point is that we want to stay close to debian and if you're concerned about too much upstream changes, you can run a diff on the debian/ dirs only
<ogra> dholbach, my point is that we cant stay close to debian with packages we package a version ahead
<Mithrandir> ogra: yes, we can.  The packaging shouldn't be much different.
<Mithrandir> it's just a different orig.tar.gz
<ogra> especially with packages that are known to be like that *every* new release
<dholbach> ogra: we did that for *all* gnome packages
<ogra> so why wasnt g-s-s and g-p-m packaged in debian first then ? 
<Mithrandir> ogra: that's irrelevant.  Now that they are, they should be merged.
<Kamion> ogra: seb128 is kind of an expert in packages that are packaged a version ahead, you know
<ogra> i dont think it matters and i'm not really after merging packages with debhelper cdbs mixes and the like
<Kamion> ogra: so maybe you shouldn't discount stuff he's saying about that
<ogra> yes, i'll merge them *sigh* !
<dholbach> ogra: seb128 and I can think of more enjoyable tasks as well :)
<Mithrandir> dholbach,seb128 : I realise you guys are insanely busy, as always, but if you'd have any chance of clearing any of your stuff out of http://people.ubuntu.com/~cjwatson/testing/edgy_probs.html , I'd be very, very happy.
<ogra> dholbach, i just dont like the extra work for packages that mostly live from our patches
<seb128> Mithrandir: if people could process NEW it would really help
<dholbach> Mithrandir: gnome 2.15.4 release is just in progress -- ~25 tarballs ahead
<seb128> Mithrandir: stuff like new n-c-b blocking python-gnome-desktop breaks a stack of packages for GNOME
<Kamion> seb128: I'm working on it
<seb128> thank you
<Mithrandir> dholbach: ok, coolie.  I hope that'll clear up a bit, then.
<seb128> Mithrandir: I'll work on clearing that this afternoon, I'm almost done with my 2.15.4 packages list
<Kamion> archive admin is unpleasantly close to a full-time job ATM
<Mithrandir> seb128: excellent, thanks.
<seb128> np
* seb128 hugs Kamion for his work on that
<Kamion> nautilus-cd-burner needs a give-back on !i386 though
<Kamion> or something
<Kamion> I've accepted it on i386 but that will only buy you so much
<Kamion> (and it'll hit NEW again on the other architectures due to an annoying quirk of soyux)
<Kamion> soyuz
<Zdra> will gnome-mount be integrated in edgy ? I want to test some of my nautilus patch and it's easier if gnome-mount is packaged in edgy :p
<pitti> Zdra: I doubt it
<pitti> Zdra: it's quite useless in its current state
<pitti> Zdra: and it requires cvs head hal, which is quite crackful ATM
<Zdra> pitti: ok didn't know that it's experimental :)
<Zdra> will try compiling it myself so
<Mithrandir> \sh: you broke intlfonts.
<Mithrandir> \sh: as in, it calls update-fonts-dir with unsupported arguments.
<\sh> Mithrandir: then I have to fix it somehow...
<Mithrandir> \sh: make it depend on a version of xfont-utils that actually have --x11r7-layout
<\sh> Mithrandir: lemme check
<seb128> Kamion: ok, I'll have look on that, thank you
<StevenK> Mithrandir: Surely xfonts-utils?
<Mithrandir> StevenK: yes, typo.
<Kamion> \sh: (I recommend leaving it alone until xfonts-utils is merged, so that you can actually test it)
<\sh> Kamion: kk
<Mithrandir> doko: ooo is utterly uninstallable on amd64 and sparc.  Care to investigate?
<Riddell> Mithrandir: yes, I'd like to release Knot 1. I've not tested any CDs yet and I'd like to have all of KDE 3.5.3 compiled first but it should be doable
<Mithrandir> Riddell: half the distro is in pieces, so it's not just you who might have problems releasing on time, though. :-P
<Riddell> I can imagine
<doko> Mithrandir: a library pulled away?
<Mithrandir> doko: ooo-common (2.0.2) depends -core >> 2.0.2, maybe that should be >= ?
<pitti> Mithrandir: but 2.0.2-2ubuntu12-1 >> 2.0.2
<tseng> shuold all these new python packages have Replaces: and cleanly upgrade?
<Mithrandir> pitti: hm, true dat.
<tseng> instead of being held back
<Mithrandir> pitti: I wonder why it blows up
<Kamion> anyone care to help with a mysterious SSP explosion?
<dholbach> can somebody give back librsvg on amd64?
<tseng> Kamion: it isnt in libgcc is it?
<pitti> Kamion: in libgcc?
<Mithrandir> doko: oh, it's libc-i386 conflicting with ia32-libs << 1.5 and we have 1.4ubuntu19.
<Kamion> actually, no, never mind, valgrind is saying somewhat interesting things too
<Kamion> nah, in chpasswd
<seb128> dholbach: did GTK 2.10 built?  
<seb128> dholbach: because librsvg requires it to build
<tseng> moin pitti 
<Mithrandir> doko: any chance you could steal that merge from Adam?
<pitti> hey tseng
<dholbach> seb128: yes, it did, i just did a dist-upgrade which removed 2467924674296426 packages, to check what's going on
<dholbach> seb128: with librsvg built we should be a bit better on the track again
<seb128> dholbach: like it removed libgnomeui-0 ? :)
<dholbach> seb128: then we have a bunch of pygtk apps depending on py2.4-something
<dholbach> seb128: no, not that, that built too
<seb128> hum
<seb128> so it should not remove that many packages then ...
<dholbach> maybe it was some less package ;)
<seb128> dholbach: python issues are due to gnome-python-desktop waiting on new n-c-b
<doko> Mithrandir: and it's gcc-4.1/gcj-4.1 FTBFS ... I love ssp ...
<pitti> doko: so maybe we should build gcc-4.1 itself without ssp for now on ppc
<pitti> doko: leaving -fs-p enabled on powerpc in the spec file should be fine, TTBOMK it only breaks if gcc itself is built with ssp
<tseng> pitti: it is pretty specifically the stack unwinding code in libgcc
<pitti> tseng: right
<tseng> pitti: which i am guessing fails to properly calculate what part of the stack it is in after adding ssp header/trailer
<doko> pitti: yes, figuring out how to do that ;)
<tseng> and touchs something it shouldnt
<pitti> doko: there are no CFLAGS in the gcc-4.1 source?
<Kamion> the problems I'm seeing here seem to be to do with fputs() fetching word-at-a-time from the given string and overflowing buffers by <4 bytes
<Mithrandir> doko: oh, joy. :-/
<dholbach> can somebody give back devhelp, librsvg on !i386?
<Mithrandir> doko: trying not to AWTY; any idea when you'll have it fixed?
<Kamion> you need Keybuk or infinity for give-backs
<pitti> Kamion: would that be our first bug discovered by ssp then?
<doko> Mithrandir: a quick fix would be to just disable ssp on powerpc
<pitti> (for gcc-4.1)
<Kamion> pitti: shouldn't bugs in fputs() have been discovered before now?
<pitti> Kamion: I would expect so...
<tseng> alot of people have been using ssp for years, im finding it hard to believe as well
<Kamion> I'm not asserting that fputs() is bug-free but it's not my first suspect
<Kamion> but at the same time the code looks ok - I'm digging
<doko> pitti: the compiler is bootstrapped with itself; so you have to make sure that it defaults to -fstack-protector, the runtime libraries are built using it, but not the compiler itself.
<Kamion> ah, maybe valgrind is misleading me here
<tseng> doko: the runtime libraries are the trouble
<pitti> doko: oh, is libgcc a runtime library?
<pitti> doko: maybe it's easier to just enable -fno-stack-protector for libgcc?
<pitti> (or all runtime libs)
<doko> pitti: yes. hmm, looking at it
* pitti loves it when sources from stable releases FTBFS
<slomo> at least for the exception thingie it is only libgcc
<tseng> morn slomo 
<slomo> hi tseng :)
<dholbach> can metacity be given back on !i386 too?
<Kamion> interesting, the ssp failure in chpasswd is actually on exit from main() ...
<Mithrandir> does it have any atexit handlers or similar registered?
<Kamion> good thought, but not that I can see
<ogra> dholbach, you didnt want to keep the patched icons in g-p-m iirc ?
<dholbach> ogra: i need to double check if the new version does gtk icon theme look up properly
<Kamion> aha! got it
<dholbach> ogra: safer to keep them in, for the mo
<Kamion> a local char[]  was one byte too small
<ogra> dholbach, ok, will do ...
<dholbach> ogra: merci beaucoup
<sivang> hmm, interesting
<sivang> Errors were encountered while processing:
<sivang>  /var/cache/apt/archives/libscim8c2a_1.4.4-4ubuntu1_i386.deb
<sivang> E: Sub-process /usr/bin/dpkg returned an error code (1)
<sivang> but hen I did apt-get -f install, and then manually dpkg -i from the cache , it just worked.
<sivang> s/hen/when/
<slomo> probably missing conflicts
<slomo> or replaces
<sivang> ah
<doko> infinity, Mithrandir, fabbione: gcj-4.1 should be retried on powerpc, sparc, amd64
<dholbach> hey Gloubiboulga
<Gloubiboulga> hi dholbach, I was /querying you
<dholbach> Gloubiboulga: oh? please send again
<dholbach> seems i didn't get it
<dholbach> Gloubiboulga: you were identified with the network?
<Gloubiboulga> dholbach, I am now
<slomo> hm, and hal needs a give-back
<Riddell> Kamion: do you have enough powers to give back qt4-x11 for recompiling?
<Kamion> Riddell: n
<Kamion> o
<Kamion> Riddell: you need a member of launchpad-buildd-admins
<ogra> does pbuilder-satisfydepends take ages for anyone else or is that my edgy over here ?
<ogra> (about 1min for every dependency)
<Riddell> ogra: doesn't take that long for me
<ogra> weird
<slomo> ogra: same for me
<Riddell> although it's certainly longer than apt-get
<ogra> anyone of you using ppc ?
<Riddell> nope
<dholbach> the new dependency resolver in apt is slower
<dholbach> mvo is aware of it
<slomo> ogra: it is slow on x86/ppc for me :)
<dholbach> it's slower on amd64 too
<ogra> slomo, oh, fine then, i'm not feeling so alone anymore :)
<pitti> ogra: is it that much better than apt-get build-dep foo?
<slomo> ogra: for most of my builds this takes longer than actually building the package ;)
<ogra> dholbach, i noticed generl apt slowness, but that pbuilder thing is really extreme :)
<ogra> pitti, apt-get build-dep works faster
<imbrandon_> ogra, i'm on pcc , need something ?
<ogra> imbrandon_, nope, i' on ppc as well :)
<ogra> *i'm
<imbrandon_> ahh ok
<imbrandon_> s/pcc/ppc ;)
<Riddell> smurf: are you going to update gnupg2 in debian?  there's a new version out
<dholbach> did somebody give back librsvg and devhelp on !i386?
<ogra> fun, my system just rebooted out of the blue, half of my HDD content is missing, gnome doesnt work anymore apart from the panels, evo starts an empty window with no widgets ... and my clock is set to 1904
<dholbach> ogra: set the date to a proper time and you should be fine again
<dholbach> at least gnome should start again fine
<ogra> nope
<dholbach> hm?
<ogra> indeed i set the clock when gdm didnt start 
<ogra> which fixed that 
<ogra> but i have a ton of bonobo errors
<ogra> and it seems half of /usr/bin is missing anyway
<dholbach> urg
<dholbach> how did you manage to get rid of half of /usr/bin?
<ogra> no idea
<ogra> the lappie "just rebooted" out of the blue ...
<ogra> after the reboot the system was in this condition
<dholbach> anything interesting in /var/log/syslog?
<ogra> the fun is that it booted fine this morning and i didnt do any upgrades, so there should be any difference 
<ogra> nope, already looked
<ogra> *shouldnt
<ogra> at least my pbuilder seems to work :)
<Kamion> 1904 is the Mac epoch; if battery power to the clock fails then it tends to reset to that
<ogra> Kamion, but both were ok
<ogra> indeed that was the first i checked :)
<ogra> (battery is at 100% and power was plugged in)
<ogra> i'm not really worried about the timestamp ... my HD worries me ... 
<ogra> but apparently all stuff in /home isnt touched
<Kamion> battery power to the clock could fail due to a loose connection or something, not necessarily just "out of battery"
<ogra> true
<ogra> sigh, not even the schema patches apply to the new g-p-m
<ogra> grmbl ... pbuilder taking 45mins for the build deps doesnt help either ...
<Riddell> pitti: would you be able to do main inclusion review for gnokii and gnupg2 today?  they're blocking large parts of KDE
<Hobbsee> ogra: ouch?  why so long?
<ogra> Hobbsee, no idea
<Hobbsee> ogra: how many MB of updates does it need?  that seems just a bit extreme
<ogra> its only the parsing that takes ages ... installing them and setting them up is done in 2 mins
<Hobbsee> ah...yeah...i've noticed that
<slomo> ogra: build it locally or do pbuilder login and do everything there
<ogra> slomo, yes, thats what i will do the next run ... 
<ogra> argh
<ogra> seb128, dholbach, where is the clealooks engine binary gone ? 
* jsgotangco pats ogra take a rest first =)
<ogra> *clearlooks
<seb128> ogra: gtk2-engines-clearlooks package?
<seb128> /usr/lib/gtk-2.0/2.10.0/engines/libclearlooks.so on your disk
<ogra> hmm
<ogra> i just got a bugreport that its not existent anymore after debian made namechanges
<seb128> we are not Debian but Ubuntu :p
<ogra> so we'll keep it 
<seb128> we didn't did the sync with Debian yet for it because they unsplitted the package
<ogra> yeps ...
<seb128> not sure if we will keep it splitted, no
<ogra> if you consider unsplitting please notify me, because i have to redo parts of ldm then 
<seb128> I'll unsplitte this week
<seb128> so you are notified
<seb128> the new gtk2-engines from today is on the TODO list
<seb128> and we will sync with Debian too
<ogra> ok
<ogra> do we have any slim theme left in a separate package in main ? 
<seb128> or do you have a good reason to keep they splitted?
<ogra> its smaller
<ogra> space is an issue on some thin clients
<seb128> that's not like the few themes engines were taking a lot of space
<ogra> well, we're talking about 32 to 64MB machines keeping the filesystem in memory :)
<ogra> so the less i have in their root the better :)
<seb128> right, but we are speaking about something like 200k 
<ogra> indeed ...
<ogra> but that sums up :)
<ogra> just tell me if its done or not ... if its done i have to at least adjust the ldm dependencys
<seb128> that's 0.625% of 32M
<seb128> I'm not sure that's not worth the extra splitting
<ogra> having 10 such packages is 6% already :) 
<seb128> which is still not that much
<seb128> and you don't have 10 packages changing
<seb128> if some k are such an issue just use the stock GTK theme
<seb128> install no theme engine at all
<ogra> how do you know ? i have the whole of X changing and no idea yet if it grows or shrinks through that 
<ogra> so i'm cautious about every byte atm :)
<seb128> as said, use no theme engine but stock GTK theme
<seb128> it's faster and lighter
<ogra> and no, i wont ship a theme in ldm thats based on the default one :)
<seb128> so stop complaining
<ogra> (or would you ship gdm with the gnome default ?)
<seb128> if you really need to space anyway that's easy to make ldm-theme package and include the theme you want to it
<seb128> I would be fine shipping the GNOME theme, it's nice :)
<ogra> we're talking about what i see if gnome-settings-daemon isnt running ? or is there something else now ?
<seb128> gdm theme? I'm speaking about the gdm login screen
<seb128> the GTK theme is the greish one but it should be better since GTK 2.8 that it used to be
<ogra> i'm speaking about the gtk theme used in there
<ogra> the ldm theme itself is just a fullscreen gnomecanvas with some colors
<seb128> ah, k
<ogra> if python-cairo is ever production ready i'll switch that ... :)
<seb128> python-cairo works fine
<seb128> and it's in sync with cairo
<seb128> what is your issue with it?
<ogra> ah, great ...
<ogra> it didnt in dapper when i looked 
<seb128> it's used by pygtk
<ogra> (very early)
<seb128> dapper pygtk uses it
<seb128> maybe you don't know how to use it? :p
<ogra> :P
<seb128> pygtk works on dapper or we would have noticed I think :)
<ogra> yep
<ogra> i or rodarvus (who will implement the ldm changes) will look into it ...
* rodarvus reads the backlog
<ogra> s/ldm changes/specced ldm changes/
<ogra> rodarvus, currently ldm uses a fullscreen gnomecanvas window to theme rendering of that gets quite slow if people add customized themes with fullscreen wallpapers 
<ogra> s/theme/theme./
<ogra> rodarvus, would be nice to drop canvas in favor of cairo
<rodarvus> *nods* you told me that in Paris :)
<ogra> oh, right 
<ogra> :)
<ogra> but its not mandatory for edgy ... its only a nice to have ...
<rodarvus> right
<ogra> (i doubt we'll have time for such stuff and the current themeing works)
* Kamion takes a deep breath and dives head-first into the debian-installer merge
<bddebian> Hello
<ogra> slomo, does your panel menu work on ppc ? 
<slomo> ogra: does it open and close and open and close and so on very fast for you?
<ogra> yep
<ogra> do you know a workaround ? 
<slomo> works fine for me ;)
<slomo> but two friends have the same bug on x86 notebooks
<ogra> oh, i thought it was ppc specific
<Keybuk> rodarvus: ping?
<rodarvus> Keybuk: pong
<Keybuk> rodarvus: so, I have a whole bunch of X source packages that are "blacklisted" because they appeared in Debian, and hadn't yet appeared in Ubuntu
<Keybuk> xbase-clients, xdebconfigurator, xfonts-100dpi, xfonts-75dpi, xfonts-base, xfonts-cyrillic, xfonts-encodings, xfonts-scalable, xfonts-utils, xfree86-driver-synaptics, xprint-utils, xprintidle, xspecs, xutils, xutils-dev
<Keybuk> are these all in Ubuntu yet?
<rodarvus> no, not yet - Mithrandir is working on the fonts-related packages, the others haven't been dealt with yet
<Keybuk> ok
<Keybuk> *-video-* have been dealt with now, yes?
<rodarvus> *nods*, finally
<rodarvus> I'm working on *-input-* for the next hour, likely
<Keybuk> ok
<Mithrandir> rodarvus: I want to do a bunch of tests, etc on the fonts, so I won't get to that today, sorry.
<rodarvus> oh, ok
<rodarvus> I still plan to do deal with Mesa later today, so I'm not sure we'll get to these packages today
<seb128> iwj: around?
<iwj> Hi.
<Mithrandir> rodarvus: mesa is independent, though.
<seb128> iwj: hey
<seb128> libnss
<iwj> Yes ?
<seb128> libnss3 has no shlibs, which break e-d-s by example which doesn't get its depends on libnss3
<rodarvus> Mithrandir: yes, but also a requirement for xorg, and (afaik) a lot of trouble to deal with
<seb128> is that on purpose?
<iwj> No shlibdeps you mean ?
<Mithrandir> rodarvus: you might want to ask infinity about the merge, he said he was going to do it, but turned ill.
<seb128> iwj: right
<iwj> That's wrong.  Is it broken in Dapper too do you know ?
<seb128> iwj: something that would make the packages building with it getting a libnss3 Depends automagically
<seb128> iwj: I don't remember having to hack GNOME packages to get the Depends by hand so I supposed it was not broken with dapper
<iwj> Hmmm.
<seb128> let me check
<iwj> How urgently do you need it fixed ?
<rodarvus> Mithrandir: oh, thanks - I will
<seb128> iwj: we have a good part of GNOME ftbfsing now because packages using libnss3 don't trigger it ... I can workaround e-d-s by forcing the Depends by hand though
<rodarvus> last time I talked with him on this subject (last week) he didn't mentioned he would do this merge
<iwj> seb128: You mean "quite urgently" :-).  I'll see what I can do .
<seb128> iwj: ie: I want to get that fix this week but I'm fine by workarounding for now
<seb128> s/by/with
<seb128> thank you
<iwj> Doesn't gnome use pkgconfig for everything ?
<seb128> iwj: it does, why?
<iwj> ISTR pkgconfig having some machinery for package dependencies BICBW.
<seb128> iwj: e-d-s itself builds fine, the issue is that the shlibs:Depends doesn't list libnss3 ... so the package Depends is missing
<iwj> Right.
<seb128> iwj: ups, sorry, it was broken for dapper too apparently but we had a "Depends: ${shlibs:Depends}, libnss3" which got dropped during the sync with Debian
<sharms> is security.ubuntu.com supposed to be down for maintenance or anything now?
<seb128> iwj: I'll put that Depends back for now but it would be nice to get it fixed one day anyway ;)
<seb128> same for libnspr4
<iwj> seb128: Aha.  Right.  OK.  I was about to say that I couldn't find the change.
<iwj> I don't think the version numbers are going to change any time soon so it can safely stay the way it is for now.
<seb128> ok
<sharms> anyone want to direct me to the proper channel to report security.ubuntu.com is down?
<elmo> sharms: it's coming back momentarily
<sharms> thanks
<Keybuk> rodarvus: btw, these new xserver-xorg-video-* binaries ... they should go in main, yes?
<rodarvus> Keybuk: correct
<rodarvus> they will replace xserver-xorg-driver-*, as soon as we have all them finished building
<Keybuk> we'll need to remove those xserver-xorg-* source and binaries, yes?
<Riddell> Keybuk: can you give back a bunch of KDE stuff for me?
<rodarvus> Keybuk: actually, if any of the *-driver-* is in universe, then the corresponding -video- should be there too
<Riddell> Keybuk: kdeedu, adept, ktorrent, skim, avahi, kscope, kflog, kphone, python-qt3, libkexif
<rodarvus> Keybuk: correct
* rodarvus <- lunch (I'll be right back)
<Keybuk> rodarvus: ok, make sure that list is kept around :)
<Riddell> pitti: I guess that's a no to my main review request? :)
<rodarvus> Keybuk: sure :)
<pitti> Riddell: why? I saw the wiki change, but I'm still busy with security stuff
<pitti> Riddell: you mean for gnupg2?
<Riddell> pitti: and gnokii
<Riddell> pitti: whenever you can, but it's blocking lots of KDE bits
<pitti> Riddell: oh, is it
<pitti> ok, I'll see to it
<pitti> Riddell: I tried gnokii with my Nokia mobile, and it worked reasonably; I hope the KDE integration is better than xgnokii :)
<jono> hey
<slomo> hi jono 
<tseng> hi jono 
<jono> hi slomo, tseng - hows tricks?
<tseng> jono: good, you?
<jono> tseng, cool thanks :)
<mdz> rodarvus: you may be able to get a launchpad DBA to help you move all of the bugs in launchpad to the new package names
<rodarvus> mdz: good you mentioned this, I had this question noted locally here - do I need to do something else besides contacting the LP DBA?
<mdz> rodarvus: either that, or write a script
<mdz> rodarvus: stub is probably the best person to talk to
<rodarvus> mdz: I'll contact stub as soon as *-driver-* is built (and udpated xserver-xorg is uploaded) - thanks for the info!
<stub> rodarvus: If I'm not around, open it as a support request on Launchpad
<rodarvus> stub: *nods*, thanks
<mdz> rodarvus: we don't need for the binaries to be built; malone works with source packages
<rodarvus> so this time looks as good as any to request :)
<rodarvus> stub: do you want me to send the package list via a LP request?
<stub> Sure. I haven't been following the conversation :)
<pitti> Riddell: ah, qt4 is back? :) are there actually apps that use it now?
<Riddell> pitti: yep
<Riddell> speedcrunch for one
<Riddell> hwdb will I expect
<pitti> Riddell: ok, for 18 months of support this should be good; I was just hesitant for dapper
<pitti> Riddell: I'll do qt4, gpg2, and gnokii now; anything else that is urgent?
<Hobbsee> pitti: the rest of kde?
* Hobbsee ducks :P
<pitti> (I'm still buried in pending security updates, so I don't want to spend too much time with reviews)
* Hobbsee is kidding.
<Hobbsee> really.
* pitti hugs Hobbsee 
* Hobbsee hugs pitti, surprised that she didnt get smacked or somethign for that comment :P
<ivoks> hug time? :)
<Hobbsee> ivoks: sure, but you have to fix a bug first :P
<Hobbsee> isnt that the rules for the hug day?
* pitti tickles Hobbsee in the side while hugging her :-P
<Hobbsee> hey now!
* Hobbsee stomps on pitti's foot
<Riddell> pitti: nothing else urgent no
<Hobbsee> pitti: you be careful of my steel toe capped boots!
<pitti> Hobbsee: tsk, you wear them in this heat?
<Hobbsee> pitti: what heat?  it's winter here.
<pitti> Hobbsee: I'm barefoot, so be careful :)
<pitti> Hobbsee: oh, wrong side of the planet then
<Hobbsee> ooh, so i could break your toes.  that would get you out of security stuff for a bit :P
* pitti ducks
<ogra> pitti, .au has no heatwave, its always hot there
<Hobbsee> pitti: yeah...
* ogra pokes his lag
<Hobbsee> pitti: it's a bit of a pain - timezones are so crazy.
* Hobbsee pokes ogra 
<Hobbsee> ogra: dont poke the lag!  you might hurt it!
* ogra giggles
<ivoks> Hobbsee: is there any snow downunder? :)
<pitti> Hobbsee: yes, I never understood Kolumbus -- a flat world would have been *so* much more practical wrt. timezones
<Hobbsee> ivoks: a bit further south, yeah.  it's ski season :)
<Hobbsee> pitti: LOL!
<ogra> ivoks, there were olympic winter games in melbourne once
* Hobbsee likes that idea.
<ivoks> Hobbsee: ski season... /me drools
<Hobbsee> ivoks: i hear NZ is good for skiing, too
* Hobbsee hasnt been skiing for a few years :(
* pitti fetches two icecreams, one for his brain and one for his computer's CPU
* ivoks doesn't care for skiing and skiers, but snowboarding... ummmmmm
* ogra has never been skiing
<dholbach> temperature: 30,0 C, feels like: 31,5 C
<Hobbsee> pitti: can i have one too please?  MOTU rights, while you're at it?
<Hobbsee> :P
<ivoks> dholbach: lol
<Hobbsee> dholbach: nice :)  
<dholbach> ivoks: it's what gweather tells me
* pitti /msg'es Hobbsee an icecream
<ogra> dholbach, pffz, you havent been outside :)
<Hobbsee> pitti: hehe thanks
<dholbach> ogra: ?!
<sivang> Keybuk: when you have time, I've applied your last two comments into SystemCleanUpTool, let me know if it's done or you have more reservations.
<dholbach> ogra: i was just out for lunch and took the dog outside :)
<ivoks> it was 36 here today :/
<sivang> dholbach: here as well! /me melts
<ogra> dholbach, feels like 45C here and the air feels liquid
<dholbach> ogra: murphy jumped into a small pond - i should head to a lake or something ;)
<ogra> heh, yeah ... a wlan equipped one ;)
<Hobbsee> ogra: maybe if you got out of the spa, then you'd find that wasnt the case
<ogra> Hobbsee, hmm ... good hint :P
<Hobbsee> ogra: hehehe
<ogra> (as if i had a spa (yet))
<Hobbsee> hehe.  yet
* Hobbsee thinks she's goign a bit crazy
<pitti> Riddell: gnupg2 report says 'No binaries running as root or suid/sgid.', but that's a lie ;)
<Hobbsee> must be the thought of 6am meetings to be at.
<ogra> Hobbsee, i'm planning a sauna and a spa for this winter in the cellar i just have to finish the move...
<Hobbsee> ogra: nice!  
<pitti> Riddell: in fact, I believe it's suid root for the same reason that gnupg was (getting locked memory), but that should be unnecessary since kernel 2.6.8
<pitti> Riddell: can you please kill the postinst, postrm, and lintian override and do some tests?
<ogra> yay, finally i have a g-p-m package (even without any of our patches but it builds at least) ... now to the patches
<ivoks> ok, when did we drop skiing subject and turn over to IT subjects? :)
<Riddell> pitti: hmm, the rules file had the setuid setting commented out, didn't look in the postinst script, let me see
<Hobbsee> ivoks: you're saying that IT cant be discussed on the skifields?
<ivoks> Hobbsee: trust me, it can :)
<ivoks> Hobbsee: but with all that snow, only thing on my mind is "leave the trace" :)
<Hobbsee> hehe
<mdz> does anyone know what's at the root of the pygtk dependency mess?
* ogra tries out what the unpatched g-p-m does 
<pitti> Riddell: TBH I'm not really happy about gnokii; supporting it is tough since it needs particular hardware and there are a lot of bugs in Debian's BTS which look a bit troublesome; can it be made optional?
<mdz> ah, it's python-gnome2-desktop
<slomo> mdz: you mean pygtk itself or gnome-python*? the latter are broken because they're on dep-wait currently because n-c-b is in NEW
<mdz> slomo: I mean python-gnome2-desktop / python-gnome2-extras (which are part of ubuntu-desktop)
<ogra> grrr ...
<Riddell> pitti: it needs to be built with it to support it, but if you're not happy with it I can remove support
<mdz> I think it's a matter of something needing rebuilding for the python transition
<mdz> doko?
<slomo> mdz: yes, exactly... most of gnome is FTBFS because of them atm but it only needs libmetacity and n-c-b accepted from NEW and we're fine again
<slomo> or is it building now again? let me check...
<pitti> Riddell: do you feel it would be a major crippling?
<mdz> slomo: neither of those are in the new queue
<slomo> mdz: ok, then i assume that they were accepted a short time ago... p-g-d is now again on needs build, should be fine after it build
<Riddell> pitti: I've had a couple of requests for it but nothing major
<Riddell> I've had more requests for gpgsm
<pitti> that makes more sense and is much better supportability-wise
<pitti> and once the suid root madness is fixed, it's good to go
<doko> mdz: pong
<mdz> doko: python-gnome2-desktop and python-gnome2-extras  cannot be installed together; do you know why?
<doko> mdz: no, didn't look yet. let me have a look
<pitti> Riddell: qt4-x11 fine for promotion
<Riddell> pitti: gpg2 works fine without the setuid bit for me
<Riddell> I'll upload a version without that
<pitti> Riddell: I expect it just wants it for doing mlock() on 2.4 kernels
<pitti> Riddell: that's what gpg 1 used it for
<bluefoxicy> * Synchronise with Ubuntu.
<bluefoxicy> <3 changelog for apmd
<pitti> tseng: ndoc approved for main
<siretart> pitti: whats the policy regarding packages, which have some binaries in main and others in universe/multiverse? would it be acceptable to have, say, things like ffmpeg in a sourcepackage in main, but keeping the resulting code in multiverse?
<tseng> pitti: thanks.
<pitti> siretart: in general, we would like to have all debs of a main source package in main
<pitti> siretart: the exception is if some deb pulls in dependencies we do not want in main
<siretart> pitti: I'm currently talking about xine. I'd like to merge the 2 source packages, because this split is a real PITA
<pitti> siretart: wrt. patents I don't feel qualified enough to answer that
<siretart> pitti: who is qualified enough for this? mdz? the TB?
<pitti> siretart: jdub or elmo might be good persons to ask
<pitti> siretart: personally, I wouldn't mind having one source and two binaries (xine-main and xine-extracodes as debs from one main source)
<siretart> pitti: this is what I'd like to do
<pitti> siretart: but IANAL, and although I do not believe that a judge would make a difference in which directory on archive.u.c. we place a deb, I defer patent stuff to Jeff or James
<pitti> siretart: s/deb/source package/
<siretart> jdub: elmo: around? see 3 lines above..
<pitti> siretart: the alternative would be to make KDE and xfmedia not use xine, but I don't know whether they have an alternative
<siretart> pitti: I don't think they have alternatives. AFAIK they rely on xine
<siretart> but if we could just demote the resulting binaries, it would help quite a bit
<doko> mdz: gnome-python-desktop is uploaded, needs building
<mdz> doko: thanks
<slomo> doko, mdz: and it needs libgnome-media-dev binary promoted to main now
<doko> mdz: dep-wait, needs libgnome-media-dev
<mdz> siretart: main needs to be completely clean, and that includes source packages
<mdz> siretart: regardless of where the binaries go
<mdz> slomo,doko: done, will be in the next publisher run
<mdz> doko: ping me if it doesn't automatically retry
<slomo> mdz: thanks :) while at it could you also promote libvisual, libgdiplus and ndoc (source + all binaries)? main inclusion reports are all approved by pitti and stuff is already waiting on it
<mdz> slomo: done
<slomo> mdz: thanks again :)
<mdz> Riddell: which binaries in kdeedu are new?  it's not obvious from the queue output; it shows them all
<Riddell> mdz: ogra updated kdeedu.  it's not a major version change so I expect it's just kdeedu-dbg
<Kamion> mdz: I use 'm -s edgy -S kdeedu; q info kdeedu' to work it out
<Keybuk> Kamion: I use "M -S kdeedu" :p
<Keybuk> (M == m -s edgy)
<mdz> Kamion: I used apt-cache showsrc|grep-dctrl -sBinary
<mdz> the new thunar looks a bit weird
<mdz> libthunar-vfs-1 -> libthunar-vfs-1-2
<mdz> though, libthunar-vfs-1 contains /usr/lib/libthunar-vfs-1.so.2.1.0 so I guess it's a bug fix
<mdz> how did that get into main with the soname not matching the package name?
<Kamion> Mithrandir: could you rebuild cdebconf-keystep against the new newt (0.52), please?
* Kamion -> kid's concert
<Keybuk> mdz: we inherited it from Debian
<mdz> Keybuk: we still review stuff for main which comes from Debian
<mdz> it's possible that it was changed since the review
<Keybuk> mdz: we do?
<Keybuk> I just sync them all :)
<pitti> Riddell: libifp and kdea11y approved
<Keybuk> so afaik do Colin and Adam
<Riddell> pitti: thanks pitti :)
<Keybuk> mdz: we seriously do not have the time to check every new source and binary from Debian when we do syncs
<Keybuk> mdz: there's hundreds of them a day
<Keybuk> (though I guess it could have been correct at the MIR point, and then broken by sync)
<mdz> Keybuk: new sources go into universe by default, and we only promote them to main with an MIR
<mdz> https://wiki.ubuntu.com/MainInclusionReportThunar says it met the library packaging policy as of 2006-01-19
<Keybuk> mdz: yup, I see what you mean now :)
<mdz> pitti: ping
<Riddell> mdz: could you promote a few things to main that pitti approved today?
<Riddell> gnupg2: gpgsm
<Riddell> kdeaccessibility: kbstate kde-icons-mono kdeaccessibility kmag kmousetool kmouth ksayit kttsd
<Riddell> libifp: libifp-dev libifp4
<Riddell> and qt4-x11: libqt4-core libqt4-dev libqt4-gui libqt4-qt3support libqt4-sql qt4-doc
<Riddell> hmm, gnupg2 has a bunch of build-depends that need looked at
<slomo> Riddell: oh, qt4 in main... i'll reenable the dbus and avahi bindings later :)
<mdz> Riddell: gnupg2 and kdeaccessibility binaries done
<mdz> Riddell: libifp is listed as unreviewed
<Riddell> mdz: the wiki page says it's approved https://wiki.kubuntu.org/MainInclusionReportLibIfp
<mdz> pitti: please confirm that ifp is approved and just not moved on the wiki page
<pitti> mdz: yep, sorry, my network broke down at the right moment
<mdz>  o type-handling: type-handling
<mdz>    [Reverse-Depends: Edgy supported seed] 
<mdz> errr
<pitti> *shock*
<mdz> Riddell: libifp done
<mdz> Riddell: and qt4-x11
<pitti> mdz: oh, wiki page already said it was approved
<mdz> pitti: yes, just wanted confirmation
<Riddell> thanks mdz 
<mdz> pitti: btw, it looks like libthunar-vfs-1 was improperly packaged (soname vs. package name) but the inclusion report said that it met the library policy (https://wiki.ubuntu.com/MainInclusionReportThunar)
<mdz> type-handling certainly isn't seeded; must be a germinate weirdness
<mdz> Kamion: ^^^
<Keybuk> mdz: iz germinate bug
<Keybuk> type-handling Provides linux
<pitti> mdz: thunar> sorry for that
<mdz> pitti: doesn't lintian catch that?
<pitti> I don't know, but a test for that seems easy
<slomo> lintian catches this normally
<mdz> Kamion: this shadow upload creeps me out a bit
<pitti> mdz: a USN is underway, if you mean that
<mdz> pitti: I assume janimo prepared the original report?
<pitti> mdz: yes
<mdz> pitti: I mean the fix creeps me out :-)
<pitti> mdz: h4ck, h4ck :-P
<bddebian> h4ck iz g00d
<sivang> pitti: security fix which is a h4ck ? :)
<rodarvus> any FreeType and (prererably) libxfont wizards around?
<rodarvus> I needed to use the following patch -> https://bugs.freedesktop.org/attachment.cgi?id=6033
<rodarvus> to get libxfont to compile with libfreetype6-2.2.1-2
<rodarvus> it appears to work correctly locally, but I'd like to hear from an experienced voice before uploading it
<mdz> rodarvus: no, cleaning up after a security bug in the installer
<rodarvus> mdz: *nods*, thanks anyway :)
<mdz> rodarvus: is this all xserver-xorg-video-* or are there more to come?
<tseng> Keybuk: can you please give back nant, ndoc, nunit2.2, mono-tools everywhere?
<rodarvus> mdz: no, all set
<mdz> rodarvus: OK, I'll promote them once the publisher is finished
<rodarvus> I have a xserver-xorg update ready to upload xserver-xorg-video-all (announced it on #ubuntu-x one hour ago)
<rodarvus> mdz: just waiting for the promotion and to check if someone else has valid points against the migration
<mdz> rodarvus: go ahead with the upload; it will take two publisher runs before it goes in, and the binaries for xserver-xorg-video-* will be published by then
<rodarvus> ok, I'll upload it now, then
<rodarvus> upload done
<pitti> rodarvus: can I bribe you to do the mesa merge, too?
<rodarvus> pitti: I wanted to do this merge today, but I was informed infinity was working (or would work) on it
<pitti> oh, ok
<rodarvus> but I was unable to find him yet, so I'm unsure on what to do
<rodarvus> btw, mesa is apparently one of the packages holding X to be cleanly upgraded
<pitti> rodarvus: he's still ill
<rodarvus> *nods*
<pitti> sladen: are you going to merge linda, or do you want one of us to do it (I'd be fine with merging it)
<mdz> rodarvus: infinity mailed warthogs saying he was ill
<mdz> ah, pitti mentioned already
<maswan> pitti: thank you, nice USN: http://www.acc.umu.se/technical/statistics/ftp/monitordata/index.html.en
<pitti> maswan: yes, kernel updates suck... :(
<maswan> pitti: Thanks though, we get to test our new cluster, and it seems release-capable without much human intervention. :)
<pitti> maswan: when running debmirror today, my quota sighed loudly at me, too
<pitti> maswan: glad to be of help :-p
<maswan> pitti: :)
<slomo> Keybuk: please give-back hal everywhere... builds now
<mdz> rodarvus: don't forget to update xserver-xorg to depend on xserver-xorg-video-all
<rodarvus> mdz: that was done on my upload, thanks for remembering me, though!
<mdz> rodarvus: ah, didn't see it on -changes
<rodarvus> mdz: oh, sorry, I must have forgotten to note this specific change :/
<rodarvus> s/note/write on changelog/
<Kamion> mdz: I know about the germinate weirdness but I haven't had time to investigate it properly yet
<Kamion> mdz: suggestions for other approaches to shadow welcome; I couldn't think of any others
<mdz> Kamion: cry?
<Kamion> did that already
<Keybuk> hal 0.5.7-2ubuntu4 - powerpc sparc ia64 i386 amd64
<Keybuk> slomo: ^
<Keybuk> rodarvus: you missed one
<Keybuk> rodarvus: xserver-xorg-video-v4l
<slomo> Keybuk: thanks :)
<mdz> jdub: UWN issues #2-5 seem to be missing from the fridge
<Keybuk> tseng: cannot give back nant or ndoc
<rodarvus> Keybuk: let me check
<Keybuk> nunit2.2 2.2.0-3ubuntu1 - i386
<Keybuk> mono-tools 1.1.11-4 - i386
<tseng> Keybuk: what does that mean?
<Keybuk> tseng: which bit?
<tseng> should i upload a new build?
<tseng> "cannot give back"
<Keybuk> tseng: nant doesn't have a failed build to give back
<Keybuk> the only build is for i386, and it's in "needs building" anyway
<Keybuk> ndoc is already successfully built
<tseng> ok
<rodarvus> Keybuk: indeed, you're right
<tseng> Keybuk: thanks.
<Keybuk> tseng: if you want ndoc *rebuilt*, you do need to do a new upload
<rodarvus> I was merging/syncing the *-video-* drivers based on http://people.ubuntu.com/~fabbione/x-pkgs
<tseng> Keybuk: I don't, I will stop believing things slomo says now
<rodarvus> Keybuk: I'll do -v4l *now*
<tseng> Keybuk: or I misunderstood and he didnt want to give back ndoc
<tseng> *shrug*
<Keybuk> rodarvus: -v4l is only in Debian -- but will probably still need some touching for the provides, no?
<slomo> tseng: i meant you should care for all of them to be fine :) i didn't know which ones needed a give-back or not but i knew that all of them should be fine now
<tseng> oh
<Keybuk> rodarvus: sorry, ignore that, it's in Ubuntu too (I looked for -video- in ubuntu <g>)
<rodarvus> Keybuk: no, actually you're right, I didn't worked on a -v4l packages
<rodarvus> (and don't think someone else did)
<Keybuk> right -- it needs a merge
<Keybuk> pitti: all the ndiswrapper packages moved around and I haven't had a chance to figure out how yet
<Keybuk> so if anyone bitches that it's back in universe, that's why
<pitti> Riddell: qt4-x11-kdecopy?
<Keybuk> they'll probably need another MIR, given the scale of change
<Riddell> pitti: what about it?
<Riddell> ooh, it's passed new
<Riddell> pitti: it's the version of qt4 needed to build kde 4.  I get daily requests from KDE developers for it, thus I supply
<Keybuk> Riddell: yeah, I couldn't find any reason to reject it :(
<Keybuk> and believed me, I tried
<Keybuk> <g>
<Keybuk> I guess KDE no longer works with qt3?
<Riddell> Keybuk: KDE 4 doesn't
<Riddell> but KDE 4 is still hardcore developers only area
<Keybuk> KDE 4 being newer than what we currently have>?
<Keybuk> why do we need qt4 in main though?
<Riddell> Keybuk: some non-KDE application already use qt 4
<Riddell> Keybuk: and any new applications should use qt 4 and avaid having to port later
<Riddell> avoid
<rodarvus> Keybuk: xserver-xorg-video-v4l_0.0.1.5-1ubuntu1_source.changes is NEW
<Keybuk> so KDE users will have two different widget sets mapped into memory?
<Keybuk> does that work?
<rodarvus> Keybuk: I'd be forever thankful if you could Accept it ASAP :)
<Riddell> Keybuk: yes.  just like how gnome users had to have gtk 1.2 and gtk 2 for a good length of time
<Keybuk> rodarvus: checking now
<Keybuk> Riddell: right, I just mean in the sense have the Qt people thought of that?
<Keybuk> given the symbol clash headache
<pitti> Riddell: it just smells like code duplication :)
<rodarvus> Keybuk: thanks!
<Riddell> Keybuk: qt 3 and 4 have completly different filenames, libqt3-mt.so against libqt4-core.so,libqt4-gui.so etc
<Riddell> Keybuk: and different symbol names to match
<Riddell> pitti: there's very little duplicated between qt 3 and 4 if that comforts you :)
<Keybuk> Riddell: filenames doesn't make a difference, the linker just picks the first one it finds
<Riddell> Keybuk: sure, but I'm yet to hear of any linker getting confused between the two, they're very different and not backward compatible
<Keybuk> Riddell: ok
<Keybuk> I guess they're C++ libraries anyway, so almost certainly have different symbols
<pitti> Riddell: I mean duplication of code in qt4-x11 and qt4-x11-kdecopy
<Keybuk> pitti: that's a good thing, surely
<Keybuk> it'd me much easier if every application included it's own copy of xpdf's code
<Keybuk> then we wouldn't have so many upgrade headaches
<Keybuk> <g>
<pitti> *cough*
<Riddell> pitti: oh yes lots, qt4-x11-kdecopy won't get near main though, and the two packages conflict
<pitti> Riddell: ah, for universe only? *phew* :)
<pitti> Riddell: still confused, if KDE needs it, it'll certainly need to be in main?
<Riddell> pitti: qt4-x11-kdecopy is qt 4.2-preview plus some random patches, qt4-x11 is the released 4.1.  KDE 4 will get into sync with stable qt long before we need kde 4 in main
<pitti> Riddell: ah, so they are ABI compatible and you can switch between them?
<pitti> Riddell: ok, then I love you again :)
<crimsun> elmo: ping
<seb128> Keybuk, mdz: could you give a retry to the builds for control-center evolution-exchange epiphany-extensions and gnome-panel?
<Keybuk> control-center 1:2.15.3-0ubuntu1 - powerpc ia64 sparc i386 amd64
<Keybuk> evolution-exchange 2.7.4-0ubuntu1 - powerpc ia64 sparc i386 amd64
<Keybuk> epiphany-extensions 2.15.1-0ubuntu2 - powerpc ia64 sparc i386 amd64
<Keybuk> gnome-panel 2.14.2-1ubuntu1 - powerpc ia64 sparc i386 amd64
<Kamion> Mithrandir: never mind, I've done the cdebconf-keystep upload now
<Kamion> Mithrandir: feel free to pull from the .bzr directory in the source upload
<seb128> Keybuk: thank you
<Keybuk> pitti: two rejected syncs out of two requested
<pitti> Keybuk: uh, bad luck today
<pitti> Keybuk: gtimelog and myspell-sk?
<Keybuk> yeah
<pitti> Keybuk: what's wrong with gtimelog?
<pitti> we have the current Debian version (I alrady wondered why it doesn't autosync)
<Keybuk> pitti: it's already up to date?
<Keybuk> it does autosync
<pitti>   gtimelog | 0.0+svn65-1debian1 | http://archive.ubuntu.com edgy/universe Packages
<pitti> Debian has 1debian2, which brings back the nice report formatting
<Keybuk>   gtimelog | 0.0+svn65-1debian1 | edgy/universe | all
<Keybuk>   gtimelog | 0.0+svn65-1debian2 | edgy/universe | source
<Keybuk> it just hasn't built
<pitti> Keybuk: hm, I did my last apt-get update at the time when I filed the sync request, sorry
<Keybuk> it only arrived from Debian today, and the buildds are doing X things
<pitti> ah, ok
<pitti> Keybuk: and myspell-sk?
<Keybuk> pitti: different orig.tar.gz sizes
<Keybuk> merge it, I'm afraid
<pitti> 'k
<Keybuk> rodarvus: and as for you ... we can't sync packages that don't exist in Debian <g>
<bddebian> heh
<rodarvus> Keybuk: oh, sorry, I didn't noticed the package had different name (xfree86-driver-synaptics in debian)
<rodarvus> Keybuk: I use a local script to download packages from ubuntu & debian automatically
<rodarvus> and "apt-get source xserver-xorg-input-synaptics" (on debian) works just fine - only grabs a package with different name :P
<mdz> seb128: why are you uploading a package with a dependency on a newer version of another package that you know doesn't exist yet? ;-)
<seb128> mdz: because configure requires it? :)
<seb128> mdz: speaking about totem, right?
<mdz> seb128: alacarte is the one I noticed
<seb128> ah
<seb128> hum
<seb128> ah, speaking about the changelog
<mdz> is totem going to be uninstallable also?
<mdz> that's going to make it hard to do a milestone
<seb128> the "New version" is the upstream NEWS entry :)
<Amaranth> oh, i left that in? :)
<seb128> no, alacarte is installable, we have gnome-menus 2.15.4.1, I got vuntz to roll a tarball today before packaging alacarte
<seb128> and for totem xine-lib 1.1.2 got uploaded today
<seb128> so it's all good :)
<mdz> ok, good
<Amaranth> i actually didn't change the configure.ac to require 2.15.x, i couldn't get a package for it built :P
<seb128> Amaranth: I made the package require 2.15.4.1 ;)
<Amaranth> of course
<seb128> mdz: is there any CD rolling planned for this week?
<mdz> seb128: knot CD 1 was tentatively scheduled for Thursday (see EdgyReleaseSchedule)
<seb128> hum, k
<seb128> we are almost done with GNOME 2.15.4, only 5-6 tarballs to do tomorrow
<seb128> and then we will work to get everything building fine and stabilized
<seb128> so GNOME should not been an issue
<Kamion> basically as soon as everything works ...
<Kamion> well, FSVO "everything"
<Kamion> I suspect a mass give-back will clear a lot of issues
<seb128> it should
<mdz> doko: do you know what the problem is with hpijs vs. foomatic-filters-ppds
<mdz> ?
<mdz> oh, it's hplip-ppds
<mdz> foomatic-filters-ppds pulls in hplip-ppds, and hpijs conflicts with it
<mdz> er, s/hpijs/foomatic-db-hpijs/g
<mdz> ah, hplip-ppds has been renamed to hpijs-ppds
<Kamion> yes, I adjusted the seeds
<Kamion> although I didn't do a metapackage upload
<mdz> yeah, I just discovered that
<mdz> would have saved me some time if you had ;-)
<mdz> Kamion: any reason for me not to update ubuntu-meta now?
<mdz> in fact it sent me on a wild goose chase trying to figure out what I missed when I grepped the seeds for hplip-ppds and found nothing ;-)
<Kamion> mdz: go for it
<Kamion> I've just been doing seed updates based on changes in NEW
<mdz> Kamion: do you think it would be any faster to ship a bzr checkout in ubuntu-meta and only have to update it?
<mdz> it takes ages to pull the seeds from bzr
<mdz> I bet rsync would be faster than sftp
<bddebian> scp
<bddebian> :-)
<Kamion> I guess that would be reasonable, although please arrange for it not to be called .bzr so that I don't have to adjust my debuild configuration to explicitly include it every time I upload ubuntu-meta
<Kamion> can we rsync from bazaar.launchpad.net though?
<Kamion> I think an sftp update of an existing checkout should be pretty fast
<Keybuk> Kamion: shall I do a mass give-back?
<Kamion> Keybuk: please do
<Evaso2> Keybuk: hi Scott any plan to sync network-manager with the debian version 0.6.3?
<Keybuk> Evaso2: yes
<Evaso2> Keybuk: there are many bugs solve especially now the pptp vpn plugin works fine
<Keybuk> no it doesn't
<Keybuk> it's still broken
<Evaso2> Keybuk: what version have u tried 0.6.9 of pptp plugin?
<Evaso2> Keybuk: or 0.7.0 version?
<Keybuk> Evaso2: I haven't tried any of them
<Keybuk> I just can see they've not fixed the fundamental problem
<Evaso2> Kebuk: mppe or the usernam and password?
<Keybuk> neither
<Keybuk> DNS
<Evaso2> Keybuk there is the option to keep the dns from the peer or not
<Keybuk> Evaso2: I will talk to you in ~10 minutes
<Evaso2> Keybuk: o i'm waiting u will come back
#ubuntu-devel 2006-07-12
<Keybuk> Kamion: ok, all given back
<Keybuk> Evaso2: the basic problem with the VPN plugins is that there's no way to handle DNS for them
<Evaso2> Keybuk: take a look here: http://www.flickr.com/photos/onlymee/161934943/
<Keybuk> because they don't use DHCP, you'd have to spam over resolv.conf, and make sure it gets put back, etc.  and n-m has no infrastructure to do that
<Keybuk> *shrug* that's a screenshot
<Keybuk> not proof of any working code
<Evaso2> There is the code to keep dns from the peers or not
<Keybuk> you're just not listening, are you?
<Keybuk> it's not the plugins that's the problem
<Keybuk> or what they support
<Keybuk> it's the fact that it breaks the _system_
* Kamion sends a love note to gtkmm
<Kamion> with a brick attached
<Evaso2> but the actual version 0.6.2 how gets dns?
<Keybuk> we talked a bit about n-m in Paris, and we came up with the idea that it might be the right thing to do to have network-manager Conflict with things like ifupdown and the gnome-system-tools
<Keybuk> so if you install network-manager, you just don't have the "traditional" system configuration there
<Keybuk> that way we don't have to worry about it
<Keybuk> Evaso2: 0.6.2 doesn't support VPN
<Keybuk> for normal connections, it calls dhclient which sets up the DNS based on DHCP responses
<Keybuk> there's no dhclient involved in VPN
<Evaso2> How the dns is offered by the vpn peers?
<Keybuk> Evaso2: aiui it's part of whatever VPN protocol is being talked
<Burgwork> Keybuk, conflicting with gnome-system-tools means you would rip out ubuntu-desktop at the same time, no?
<Keybuk> Burgwork: conflicting with netbase would mean you had to rip out EVERYTHING :p
<Keybuk> so, as a plan, it needs work
<Keybuk> edgy+1, definitely
<Keybuk> our edgy n-m plan is just "sync with Debian and largely ignore it"
<Evaso2> Keybuk: but userpeerdns is only an option of pppd
<Burgwork> Keybuk, the nm people also have no plans for static address setting
<Evaso2> Keybuk: and i think that the pptp vpn plugin use this pppd option to keep dns peers on point to point
<Evaso2> Keybuk: why you not disable also this pppd feature?
<Keybuk> Burgwork: if you install n-m, you don't care about static dns
<Keybuk> Evaso2: because ppp works correctly out of the box
<mdz> Kamion: sftp updates of the checkout that I keep locally take forever, even if there are few revisions to update
<Keybuk> Evaso2: I haven't yet looked at the evolution ppp vpn plugin in detail recently, if it now just calls ppp and doesn't futz about, then it might be ok
<Evaso2> Keybuk: are u on dapper now?
<Keybuk> Evaso2: dapper and edgy
<Evaso2> Keybuk : i'm on debian, can u try this  man pppd | grep usepeerdns
<Keybuk> Evaso2: why would I check that?
<Keybuk> we're not talking about pppd
<Keybuk> we're talking about network manager
<Evaso2> Because the pptp vpn plugin and other software already in ubuntu like (kvpnc) use this option of pppd to keep pptp peer dns
<Kamion> mdz: really? they're very quick for me
<Kamion> a couple of seconds at worst
<mdz> Kamion: I'm using bound branches, you/
<mdz> ?
<mdz> bzr update  0.57s user 0.07s system 4% cpu 13.702 total
<mdz> that's typical for ~1 revision
<Kamion> hmm, it does seem to be a bit longer now you mention it
<Kamion> real    0m17.621s
<Kamion> user    0m2.048s
<Kamion> sys     0m0.400s
<Kamion> but still doesn't seem worth stressing about
<mdz> it's long enough that I can't wait for it, and go off to do something else
<Evaso2> Keybuk: from the pptp vpn source code
<Evaso2> Actually there is one exception... Many distros have an ip-up script which imple ments usepeerdns functionality thus replacing resolve.conf... This conflicts wit h NetworkManager's actions so may need to be removed. Sadly there appears to be no way to tell pppd NOT to execute /etc/ppp/ip-up if it exists!
<Evaso2> so this is a problem about ip-up and pppd about the usepeerdns pppd option
<Keybuk> Evaso2: interesting how you start to see the problems when you read the code, isn't it :p
<Keybuk> all of the vpn plugins suffer similar problems
<Evaso2> but also pppd connection in general that use usepeerdns option
<Surak> I just took a quick look to gnome-system-tools, and as far as I can see, it communicates with some perl backends, right?
<Keybuk> Evaso2: the fundamental problem is that if we have to support network-manager, we want it to behave correctly and interoperate with the rest of the system
<Keybuk> Evaso2: we can therefore choose to either disable those parts that cause problems, or we can choose to not support it at all
<Keybuk> where not support ~= put it in universe
<Evaso2> Keybuk: ok... like Kvpnc
<Evaso2> because kvpnc in dapper use the usepeerdns option
<Keybuk> at the moment we have an amount of legacy crud in the system to support networking
<Keybuk> ifupdown, netbase, etc. upwards
<Keybuk> all of which are pretty bad, but at least have the virtue of working and being understood
<Evaso2> Keybuk: the problem is about coordinate static and dynamic network
<Keybuk> n-m breaks them all, which is fine if all you want is n-m, but people come up with creative ways of having problems by trying to use n-m *and* static networks, etc.
<Keybuk> and we'd rather have that impossible, than get the bugs
<mdz> Kamion: the supported seed is a joy now with Extra-Include
<Evaso2> Keybuk: yes of course but imho is a profile use problem
<Kamion> mdz: I am much happier with it
<Kamion> doing it found a few seed bugs too (as expected)
<Evaso2> if an user choiche dynamic network could not use static and vice-versa
<mdz> Kamion: have you ever seen this?
<mdz> W: http://archive.ubuntu.com/ubuntu/dists/edgy/main/binary-amd64/Packages.gz was corrupt
<mdz> I got it on sparc as well
<mdz> I've made three attempts and at least one architecture has failed in that way each time
<Keybuk> Evaso2: at some point in the future, we'll want to have a replacment networking stack that all just works
<Keybuk> Evaso2: and I strongly suspect that n-m will be that replacement stack, once it's mature enough
<Kamion> mdz: yes, I get it occasionally, but retrying usually clears it up. Perhaps you're behind a transparent proxy?
<mdz> Kamion: I'm behind a non-transparent proxy, but even when I disable that, it happens
<mdz> has debootstrap always checked md5sum against the Release file?
<mdz> Kamion: the annoying thing is that it doesn't fail, so I don't notice until everything is finished and I have to start over
<Evaso2> Keybuk: what are the interaction of /etc/ppp/ip-up.d/0000usepeerdns with the pptp vpn plugin?
<Kamion> mdz: that should be fixable ...
<Kamion> dunno about always but it's been there for a long time
<mdz> I've never had this happen when I don't use my local proxy
<sladen> pitti: I think upstream took the patch to fix the paths, so maybe a sync, I haven't checked yet.
<mdz> until now
<mdz> err
<mdz> Added pbbuttonsd to desktop-i386
<mdz> oh, I guess that's sensible no
<mdz> w
<Surak> I'm asking this because gnome cvs now uses liboobs, which is not in ubuntu yet. So I just quite didn't get the exact point where the G-S-T communicates with that perl backends
<ogra> ogra@edubuntu:/mnt/devel/packages/gnome-power-manager-2.15.4$ apt-cache madison liboobs
<ogra>    liboobs | 0.1.0-0ubuntu1 | http://archive.ubuntu.com edgy/main Sources
<ogra> its there ...
<ogra> just no binary yet
<mdz> https://launchpad.net/+builds/+build/223659
<Surak> hm, dapper here. was taking a look at bug #14774
<Ubugtu> Malone bug 14774 in gst "Shared folders requires a login" [Unknown,Unconfirmed]  http://launchpad.net/bugs/14774
<mdz> Kamion: binaries which aren't built anymore are producing a lot of noise in anastacia; does germinate already have enough information on hand to trivially exclude those?
<mdz> er, I guess it'd be anastacia and not germinate
<mdz> and anastacia wouldn't
<Surak> creating a sub{} to call smbpasswd in /usr/share/setup-tool-backends/scripts/share.pl and a user/password field for it in the G-S-T in the 'general windows sharings settings' would fix this bug.
<Kamion> mdz: archive-cruft-check reports on those; I'll do a removal pass at some point soon
<Kamion> mdz: I don't really want to deal with them somewhere else as well
<Kamion> mdz: pbbuttonsd can be made [powerpc]  if we don't want it on i386; it was added for MacBooks though
<LaserJock> is the ubuntu-archive team interested in packages in the wrong section or wrong component?
<Kamion> LaserJock: wrong component we have a report on (anastacia)
<mdz> Kamion: for some reason, gnutls11 is showing up for promotion to main in anastacia
<Kamion> LaserJock: wrong section, sure, if you like
<mdz> maybe something to do with gnutls-bin moving around
<Kamion> ship.build-depends:libgnutls11                | gnutls11            | libxmlsec1-gnutls                  | Matthias Urlichs <smurf@debian.org>                                    |          407344 |            1204
<Evaso2> Keybuk: so actually pptp n-m plugin seems to rely on pppd so there is any addictive problem then simply creating a manually pppd connection
<Kamion> ship.build-depends:libxmlsec1-gnutls          | xmlsec1             | libxmlsec1-dev                     | John V. Belmonte <jbelmonte@debian.org>                                |           41416 |             164
<Kamion> supported+build-depends:libxmlsec1-dev                      | xmlsec1                         | openoffice.org (Build-Depend)                | John V. Belmonte <jbelmonte@debian.org>                                               |         1074206 |            6300
<pygi> Kamion, !!! :P
<mdz> urgh
<Kamion> or http://people.ubuntu.com/~cjwatson/germinate-output/edgy/rdepends/ALL/libgnutls11 for that matter
<mdz> it build-depends on libgnutls-dev though, which is gnutls13
<Kamion> Package: libxmlsec1-gnutls
<Kamion> Version: 1.2.9-1ubuntu1
<Kamion> Depends: libc6 (>= 2.3.4-1), libgnutls12 (>= 1.2.5), libxml2 (>= 2.4.24), libxmlsec1 (>= 1.2.9), libxslt1.1 (>= 1.0.20), zlib1g (>= 1:1.2.1)
<Kamion> Package: libxmlsec1-gnutls
<Kamion> Version: 1.2.9-3ubuntu1
<Kamion> Depends: libc6 (>= 2.4-1), libgnutls11 (>= 1.0.0), libxml2 (>= 2.6.12), libxmlsec1 (>= 1.2.9), libxslt1.1 (>= 1.0.20), zlib1g (>= 1:1.2.1)
<Kamion> it appears to have regressed lately
<Kamion> mdz: libgnutls-dev isn't the relevant arc in the graph
<bluefoxicy> o.o my screan is full of noise
<mdz> Kamion: http://librarian.launchpad.net/3309974/buildlog_ubuntu-edgy-i386.xmlsec1_1.2.9-3ubuntu1_FULLYBUILT.txt.gz clearly shows libgnutls13 being installed, then ending up with a gnutls11 dependency anyway
<mdz> and the library is in fact linked with libgnutls.so.13
<anibal> Kamion, could you please review busybox 1.1.3-2ubuntu1, bug #52706
<Ubugtu> Malone bug 52706 in busybox "please merge busybox 1.1.3-2ubuntu1" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52706
<mdz> debian/shlibs.local:libgnutls 13 libgnutls11 (>= 1.0.0)
<mdz> O.M.G.
<mdz> I have got to see the changelog for that one
<mdz> oh I bet it's this
<mdz> "  * Adjust gnutls dependency (Closes: #335771)"
<Kamion> anibal: ok, in the morning
<Kamion> (for the record, I usually find that reviewing merges is about as time-consuming as just doing them ;-))
<Kamion> but thanks
<anibal> Kamion, it's 08:57, Wed morning already :)
<Kamion> for you maybe ...
<sladen> anibal: ...and now it's Wednesday morning for Kamion too
<anibal> Kamion, what process should I go through to upload them directly?
<Kamion> anibal: you would need to be approved for ubuntu-core-dev
<Kamion> (I'd really prefer non-installer people didn't upload busybox though - it's very core and sometimes needs to be coordinated carefully)
<Kamion> (though if you were doing installer hacking, it would be fine)
<mdz> anibal: http://www.ubuntu.com/community/processes/newdev
<anibal> Kamion, during debconf6, frans show us how easy is to do d-i hacking
<Kamion> anibal: for the record please don't subscribe ubuntu-archive to merge bugs
<anibal> mdz, thanks
<Kamion> ubuntu-archive only needs to know about syncs
<anibal> Kamion, okay
<Kamion> (i.e. unmodified sync)
<mdz> Kamion: I was thinking, is there even any reason for ubuntu-archive to be involved in syncs, where the requestor has upload privileges for the relevant component?
<mdz> I suppose it's convenient with larger packages not to have to download and upload again, but in general it would be quicker and more convenient
<Kamion> mdz: when soyuz can make it happen by letting you press a button, there will be no reason
<Kamion> and that is the eventual plan
<Kamion> in the meantime, the current sync policy removes a lot of human error possibility
<Kamion> it's very easy to accidentally upload the wrong thing, or think that it's ok to download the package and re-dpkg-buildpackage, or whatever
<Kamion> this way, we know that we're getting what it says on the tin and don't have to double-check
<mdz> Kamion: we have a tool for it, and there's no particular reason why that tool needs to be run by the archive admins rather than any developer
<mdz> it shouldn't be any more error-prone
<Kamion> I'm not sure I agree - "ask somebody experienced to do it for you" has a much lower error rate than "download random script, upload the result"
<Kamion> especially if we discover bugs in that script
<Kamion> and it seems valuable to have the manual-sync process be essentially the same as the auto-sync process
<mdz> it would be more like "run script that you already have installed with dpkg-dev" or similar, not random
<mdz> and the upload would be part of the script, it would be a one-step process
<Kamion> it gives me the shivers
<mdz> I see no reason for it to be a "run this tool to spit out something, then deal with it" process
<mdz> why?
<mdz> what's the failure case you have in mind?
<Kamion> because syncs are an extremely cast-iron process at the moment
<Kamion> we are very sure indeed about their results, precisely because they're centralised
<Kamion> I don't really see the value of losing that useful guarantee that when we think we've synced to Debian, we really have
<Kamion> otherwise we have to have something run around checking that 1.0-1 here == 1.0-1 Debian
<mdz> Riddell: gnokii looks ancient; is it really something we want to use in kdepim?
<Kamion> and additionally once soyuz learns to sync directly from Debian by copying publishing records around, a process involving dpkg-dev would become obsolete anyway
<mdz> Kamion: I don't see how it makes any difference in our certainty
<mdz> the soyuz-based process definitely would
<mdz> but you running the tool vs. doko running the tool doesn't
<Riddell> mdz: I've had a couple of requests but it's not a major feature so I'll leave it out
<Kamion> how about me running the tool vs. inexperienced MOTU running the tool (and perhaps thinking that it's ok to stop it in the middle and fiddle)?
<LaserJock> iwj: ping?
<Kamion> now, if the tool were something that checked lp auth in the relevant team and somehow asked drescher to run the sync-source backend, that would be ok; that's effectively just the existing sync process with ubuntu-archive out of the loop
<Kamion> (apart from *meep* security concerns with having stuff being able to request that code be run on drescher as lp_archive)
<Kamion> but to preserve the certainty of syncs I do think it's valuable to have the packages all stay on the archive machine rather than being shunted out to a developer machine and then shunted back again after who-knows-what-modifications
<Kamion> not to mention the upload time concerns for big packages, as you alluded to earlier
<jdub> hooooly crap, upgrade-o-rama this morning
<mdz> Kamion: the tool wouldn't let them do anything they couldn't do by hand, and in fact, it would discourage doing so through automation
<mdz> Kamion: I really don't see the concern for who-knows-what modifications; these are folks who have upload privileges
<mdz> it's no different than apt-get source
<Kamion> I guess I just don't see the urgent reasons why it must change
<mdz> Riddell: oh, I hadn't even looked at the main inclusion review; I just saw it in anastacia and took a look
<jdub> hrm, xephyr/xnest don't do alternatives
<mdz> Riddell: noticed it because it was pulling in an ancient postgresql
<Riddell> mdz: I've uploaded a new kdepim without gnokii
<mdz> Riddell: noticed, that's where I saw your comment about main inclusion
<mdz> was there a report for it?
<mdz> Kamion: it's not urgent
<mdz> but it would reduce overhead significantly
<Riddell> mdz: https://wiki.kubuntu.org/MainInclusionReportGnokii
<Riddell> mdz: pitti rejected it earlier
<mdz> oh
<mdz> my gut agreed with pitti then
<jdub> Kamion: do we still require dselect? :)
<jdub> Kamion: could it be removed from u-s? :)
<mdz> Riddell: what change has resulted in amarok-engines wanting to go into main?  seems like the sort of thing which would have been there in the first place
<Kamion> jdub: whatEVAH
<Kamion> </elmo>
<jdub> heh
<Kamion> ok, is c++ exception handling buggered in edgy?
<jdub> Kamion: i just care about the little people, y'know?
<Burgwork> jdub, is the dcc alliance dead?
<Kamion> $ cat t.cpp
<Kamion> #include <iostream>
<Kamion> int main() { try { throw "foo"; } catch (...) { std::cout << "test" << std::endl; } }
<Riddell> mdz: looks like the Depends have changed on amarok to have amarok-engines | amarok-engine not amarok-xine | amarok-engines
<Kamion> $ g++ -g -Wall -o t t.cpp
<Kamion> $ ./t
<Kamion> test
<Riddell> mdz: amarok-engines is all the obscure backends aren't used.  I'll fix that
<Kamion> but in edgy, that gives SIGSEGV
<jdub> Burgwork: no, not at all
<mdz> Riddell: ok, so we don't need/want amarok-engines?
<jdub> Burgwork: it's obviously not dead
<Riddell> mdz: no
<jdub> Burgwork: it's... pining
<mdz> ok
<Kamion> Riddell: have you noticed exception handling problems like the above?
<jdub> for the fjords.
<crimsun> Kamion: with g++ 4.1.1-8ubuntu1?
<mdz> jdub: I was just looking at that the other day actually
<mdz> it ought to move out to supported, under "elmo"
<Riddell> Kamion: no, but KDE uses very little exception handling
<jdub> mdz: dselect, or dcca? :)
<mdz> jdub: dselect
<mdz> I don't think elmo is interested in official support for the dcca
<Kamion> crimsun: 4.1.1-2ubuntu5
<jdub> though it would be fun to give it to him, and see what he does with it
<Kamion> newest version on powerpc at present
<Burgwork> jdub, right. But for amusement: http://lists.dccalliance.org/pipermail/dcc-devel/2006-June/000704.html
<crimsun> that sounds an awful lot like the segfault on exception handling on ppc issue that slomo/tseng were seeing
<jsgotangco> lol
<jdub> it's actually really lame that they're just letting it hang on for grim life like that
<jdub> kinda like userlinux
<Kamion> crimsun: is that fixed in -8ubuntu1? if so I'll ignore it for now and upgrade tomorrow
<crimsun> Kamion: can't confirm, no ppc hardware
<tseng> crimsun: doko says he cant reproduce
<tseng> er, @ Kamion 
<Kamion> tseng: is there a bug number?
<tseng> last i heard from slomo_ gcc wasnt built there in the archive
<tseng> Kamion: yes, moment
<tseng> https://launchpad.net/bugs/52465
<Ubugtu> Malone bug 52465 in gcc-4.1 "[libgcc1]  segfault on ppc when unwinding stack (c++ exceptions, mono exceptions)" [Critical,Confirmed]  
<Kamion> yeah, just found it
<tseng> pitti and doko spoke about it earlier today
<tseng> here.
<Kamion> ah, he says he can't reproduce with -8ubuntu1 so I'll try that tomorrow
<tseng> or was it yesterday?
<bddebian> Howdy
<Riddell> mdz: could you move libqt4-debug-dev to main?
<mdz> Riddell: it should be pulled in automatically as part of Kamion's new germinate magic
<mdz> or does something depend on it?
<Riddell> mdz: speedcrunch build-deps on it
<mdz> Riddell: ok, done
<Kamion> Riddell: you need to undo the KDE-specific Extra-Excludes in supported for your seeds
<Kamion>  * Extra-Exclude: libqt4-debug-dev
<Kamion> for one
<Kamion> you may need GNOME-specific Extra-Excludes, conversely - although it's not a huge deal
<Riddell> right
<Kamion> those excludes are just there because Ubuntu build-deps on stuff like doxygen and I didn't want to pull in effectively all of KDE into Ubuntu supported
<bddebian> Heya imbrandon
<imbrandon> heya bddebian
<Riddell> Kamion: why does doxygen end up pulling in KDE?
<Keybuk> mdz: my concern with giving random joes the sync tool is that nothing stops them modifying the source before they upload it
<Keybuk> they have to sign it anyway, so there's actually an incentive for them to fix whatever bug they had, and forget to do the ubuntuX on it
<bddebian> Oh, can I have it? :-)
<Kamion> Riddell: hmm, may not have been doxygen actually
<Keybuk> in fact, I suspect they have to not only sign it, but change the changelog to be able to upload it
<Keybuk> (right now, we have a special hammer to slam them into the archive)
<Kamion> Riddell: I think it was debconf Build-Depends-Indep: libqt-perl Build-Depends: libsmokeqt-dev which comes from the kdebindings source which Build-Depends: kdelibs4-dev
<Kamion> there was probably something else too, I remember kdebase-dev being extra-included
<bddebian> Damn, who knew cutting out paper doll clothes could be so freakin' time-consuming :-(
<Kamion> basically I went through the before->after germinate output diff and made sure I could justify every addition to all
<Kamion> you might not want to go that far - I did it because I also needed to ensure that my germinate changes were correct
<mdz> Keybuk: nothing stops them from modifying source they get from apt-get source either
<Kamion> but if they upload that, it'll be with a different version, generally
<mdz> Keybuk:  the tool would be a one-shot deal; we wouldn't give them the opportunity to modify the source
<Kamion> and if they don't upload that, who cares
<mdz> Kamion: why in one case and not the other?
<Kamion> because psychologically, they're doing a sync
<Keybuk> mdz: that involves tool development time ... I don't see the point in spending the effort developing a "sync and upload" tool
<Kamion> it would be very tempting to "just clean it up a little"
<mdz> I don't see the difference between "they might modify without changing the version number after getting source with the sync tool and interrupting it partway through" and "they might modify without changing the version number after downloading source with apt-get source"
<mdz> Keybuk: I'll add the debsign && dput to the end myself ;-)
<Keybuk> mdz: they can't upload the source they get with apt-get source without changing the version number
<mdz> Keybuk: what stops them?
<Keybuk> mdz: will you also remove sync-source's dependencies on launchpad's code, and direct database access
<Keybuk> mdz: or will you give everybody a copy of launchpad and open the database to all?
<Keybuk> mdz: the fact the source already exists in the archive with that version, and the basic upload checks go "version must be greater" ?
<Kamion> mdz: what stops them> you can't upload something with a version that's already in the archive
<mdz> Keybuk: I thought that it was changed to use Packages files as part of the porting process
<Keybuk> mdz: HAHAHAHA
<mdz> Kamion: we're talking about source obtained from Debian
<Kamion> no, it was ported to LP properly
<Kamion> mdz: oh that's not apt-get source on Ubuntu :-P
<mdz> Kamion: I get source from Debian with apt-get source on Ubuntu all the time
<Keybuk> mdz: I would bet that there are maybe two people in all of Ubuntu who have Debian deb-src lines in their sources.list
<Keybuk> mdz: probably you and Kamion
<mdz> in fact it's usually the default, because Debian is newer
<jdub> i added one recently 8)
* bddebian has them
* Seveas has them
<Keybuk> and yes, nothing does stop them doing that
<Kamion> there was a period when people were uploading fake-syncs got that way, when the sync tool was nonfunctional
<bddebian> other than the wrath of core-devs :-)
<Kamion> I never did get round to going through and verifying all of the syncs thus uploaded
<Keybuk> mdz: seriously, if freeing up the half an hour a day ubuntu-archive spend doing syncs is important ... please hassle the LP team to make clicky-syncs a reality
<mdz> the fact that the sync tool would need de-LP-ifying is a better argument
<Kamion> we won't get any development time from the LP team to de-LP-ify things either - whereas at present we do at least theoretically get support from them
<Keybuk> most of my "sync time" is actually spent working out why the sync tool is refusing to do its job, and rearranging the archive appropriately
<mdz> Keybuk: it will be a long time before launchpad does everything we want in the ideal way; that won't stop us from having interim solutions where it makes sense
<mdz> the current sync tool is an example of such a situation
<Keybuk> what's wrong with the current sync tool?
<Keybuk> you have a serious hate for it, yet don't use it that often
<Keybuk> it works just fine
<mdz> Keybuk: you and Kamion are blowing this way out of proportion
<mdz> read the beginning of the conversation where I started musing
<bddebian> I have to admit that with Keybuk AND Kamion doing syncs, it has been very expeditious
<mdz> I'm not criticising either of you in the work you are doing on syncs
<Kamion> actually that wasn't my concern; I had (and remember espousing) the same opinion when it was elmo doing all the syncs
<Keybuk> I didn't believe you were
<Keybuk> I'm just raising my concern that we'll lose a lot of confidence in a sync if everybody does them by hand
<Keybuk> also the by-hand syncs annoy the hell out of mom
<Keybuk> I had to code around that this time round
<Keybuk> because by-hand syncs need the top changelog entry modified to say "edgy" and an author in ubuntu-{core-,}dev
<Keybuk> whereas those ubuntu-archive do can be injected into the queue after the signature checking, so have the same top changelog as Debian
<Kamion> actually, that's not a real restriction; you just need to hack up a new .changes file
<Keybuk> Kamion: does LP not reject them now?
<Kamion> by-hand syncs are often like that because people don't know how to or (quite reasonably) don't want to hack the .changes
<Keybuk> I thought Soyuz got upset somewhere in the mailing when changelog and changes disagreed
<Kamion> oh, it might do I *suppose*, katie never used to
<Keybuk> (where reject = throw an exception)
<Kamion> seems like an odd check to add
<Keybuk> it's not a check, but a bug, I think ... worth trying again at some point
<Kamion> the reason why we inject syncs into the queue after the sig check is that we didn't want to have a sync signing key on drescher
<Kamion> katie's syncs used to be signed
<Keybuk> there'd definitely be a temptation to fiddle with the sync though
<Keybuk> "here's a source package to upload" => try and build it => fix a bug => upload
<Keybuk> and then there's the packages which, when built, rewrite their source package
<Keybuk> hell, I've been tempted to fiddle with a sync before
<Keybuk> in fact, as recently as today
<Kamion> mm, I take mdz's point that it would just upload for you, but the tool would have to have a debug mode so that you could see what it was going to do, and the best way to implement that debug mode would be to have it spit out the package so you could check it
<Keybuk> Kamion: upload using which tool?  what about ftp proxies?  etc.
<Kamion> and at that point I know I'd be seriously tempted to always use the debug mode :-)
<mdz> what is there to check?  it's just downloading a source package and re-uploading it verbatim
<Keybuk> e.g. I don't use dput
<Keybuk> and where would it get the gpg configuration from?
<Kamion> right, same reason basically that I have -uc -us set in my debuild configuration
<Kamion> I want to do the signing *after* I've diffed, tested, etc.
<Keybuk> mdz: download, unpack, generate changes file, sign changes and dsc, upload again
<Kamion> I would be scared to sign something that a random tool spat out for me and didn't let me check
<Keybuk> at each point, making sure to honour the user's apt choices, signing key choices, correct e-mail address, upload procedure, etc.
<mdz> there is nothing random about the tool
<Kamion> mdz: every package I sign, I diff against the last version, and generally eyeball the whole diff
<mdz> Keybuk: that's what debsign is for
<Keybuk> mdz: so if I gave you a tool that asked to sign something as part of its operation, you'd happily enter your GPG key? :p
<Kamion> you're proposing I sign something that I'm not allowed to look at
<Keybuk> mdz: debsign still needs arguments/options
<Kamion> because it won't spit it out anywhere
<mdz> Kamion: I'm not; I expect you would continue to use sync-source.py
* Keybuk contemplates a quick "yes, you may have a pay rise and an extra month's holiday" tool
<Kamion> mdz: let's pretend ...
<mdz> Kamion: my point is that yours is not a typical use case
<Kamion> mdz: I don't think that reasonable paranoia implies member of ubuntu-archive
<Keybuk> mdz: actually, I think it is -- we've instilled a sufficient sense of professionalism into our community that most of them will feel unhappy about signing their name to something they haven't at least _checked_
<mdz> Keybuk: people are not reading the entire diff when requesting a sync
<mdz> we implicitly trust Debian
<mdz> we import things from them without looking at them all the time
<Keybuk> mdz: I do
<Kamion> why not? mom gives it to them to check
<Keybuk> every sync I've ever processed, I've read the diff
<Keybuk> and most sync requests come from people who've just been reading the mom output
<Kamion> they should at least be eyeballing it to ensure it contains the Ubuntu changes
<Keybuk> (manual sync, anyway -- I don't read the "every day" ones)
* bddebian test builds all his sync requests
<Hobbsee> morning all
<bddebian> Hi Hobbsee
<mdz> Kamion: I often just look at the ubuntu changes and check that they're present without reading the rest of the diff
<mdz> especially if it's a new upstream
<Kamion> if there's a trust path back to somebody's GPG key for a sync, I expect that they have at minimum checked that the md5sums are the same as the source package in Debian
<Kamion> at present we know this because we trust drescher
<mdz> apt checks that when it downloads the source
<Kamion> I don't trust developer's machines not to have a subtly trojaned sync tool; I do trust them not to be trojaned in such an AI-complete way that diff produces reassuring output even on trojaned uploads
<mdz> Kamion: dude, they already have upload privileges
<Kamion> yes, and they'd better be using diff when they upload
<mdz> Kamion: that is no defense
<Kamion> it raises the bar to a casual hacker a hell of a lot
<mdz> in fact my first choice if I were writing a trojan targeting Ubuntu developers would be dupload and dput
<Keybuk> mine would be apt ;)
<Kamion> (surely debsign)
<Keybuk> give them the wrong source in the first place
<mdz> devscripts, dpkg-dev...
<mdz> debdiff!
<Kamion> my point is, if you're being halfway diligent about reading the damn changes you're uploading, it's very hard to convince you to sign the wrong thing
<Keybuk> oh, I trojan'd dpkg-dev a long time ago ;)
<mdz> show them a correct diff and then modify it ;-)
<Keybuk> dupload/dput wouldn't be very useful, because they get run after the signing
<Kamion> how does the hacker know what "correct" is (if you diff the package *after* signing it too, which I randomly often do)?
<Kamion> I suppose you could stash an unmodified diff somewhere before your evil modifications to the package
<Kamion> starting to sound increasingly detectable at that point though
<mdz> Kamion: this is silly; if you're that concerned about whether people review the changes, then have the tool run debdiff for them
<mdz> I think that's completely orthogonal
<Keybuk> mdz: and then, at that point, you increase the incentive for them to fix problems before they upload
<Keybuk> which leads us to having syncs that don't match Debian
<mdz> that is such an invented problem
<Kamion> sorry to sound really anal but I don't think good checking practices are silly considering how many production machines run Ubuntu
<Keybuk> mdz: dude, _I've_ been tempted to fix syncs before that I know are going to be broken
<mdz> the developer would have to try very hard to browbeat the tool into letting them upload a modified package
<mdz> it would be easier for them to use apt and dput
<Keybuk> I can't believe other developers will resist that temptation
<Kamion> I realise we trust Debian and that there's more coming through than we can in practice review, but I don't think that's a reason not to review things when we can
<Keybuk> mdz: yeah, they'd have to edit it and stick sys.exit(0) in the right place ...
<mdz> Keybuk: which is more typing than apt-get source
<mdz> which is what they'd be crippling the tool into
<Kamion> so in practice folks will end up using apt-get source. doesn't seem like an improvement ;)
<mdz> except that they won't
<Kamion> (actually, it's apt-get source plus .changes mangling)
<Keybuk> also I'm vaguely worried about pushing Debian deb-src onto every developer's machine ... we'll end up with all manner of random versions being uploaded by accident
<mdz> they'd do exactly what they're doing today, only with a command line which does the sync instead of a command line which files a bug report
<Keybuk> if "apt-get source foo" always gives our developers the Debian source, not the Ubuntu source, that's a bad thing
<mdz> Keybuk: I wasn't suggesting modifying their sources.list at all
<Keybuk> if the tool reads Debian's Sources.gz by hand, then it _is_ doing something different for them
<Keybuk> and thus is "more than apt-get source"
<Kamion> as bddebian says, a lot of people aren't just doing "command line which files a bug report", they're downloading the package and test-building it first
<Kamion> which seems like something we want to encourage
<bddebian> Oh, you actually "heard" me? :-)
<mdz> Kamion: the part of the process where they download and test it is *exactly the same* regardless of the sync partof the process
<Kamion> given that many people won't want to download the same thing twice, they'll want to pick the package out of the sync tool's output
<mdz> it makes no difference
<Kamion> it does, see immediately above
<mdz> I think people are lazier than you give them credit for
<Kamion> it makes perfect sense for people to want to go "sync, except don't upload yet while I test it"
<Kamion> I don't think that's lazy, seems sensible to me
<bddebian> May I make comments?
<mdz> I re-download things all the time
<Kamion> saving bandwidth is often the opposite of lazy ;)
<Keybuk> bddebian: of course
<mdz> I use squid
<mdz> I routinely blow away the output of apt-get source and run it again to ensure that I have what I think I have
<mdz> squid deals
<bddebian> I have had a couple of packages so far where the ubuntu changes could be dropped but the package still FTBFSs so I personally think a test build is required/recommended when synced a previously merged package
<mdz> bddebian: I agree with you one hundred percent
<Kamion> perhaps we should take a straw poll of how many developers have a local squid ... I suspect it's not huge outside perhaps core-dev
<mdz> bddebian: but that is one hundred percent irrelevant to how syncs are processed
<Keybuk> Kamion: proxies are evil
<mdz> I expect most folks are behind a cache whether they know it or not
<Kamion> actually that's a good point, I have a local squid but I often turn it off to avoid some problem or other and forget to turn it back on
<Keybuk> mdz: varies depending on the ISP ... certainly in the UK "proper" ISPs actually list "no transparent proxy" as a feature
<mdz> Kamion: I expect more developers have caches than diff their packages again after signing ;-)
<Kamion> so the bits generally have to come down my ADSL which is the slow bit
<mdz> Kamion: and don't you have a local mirror anyway?
<bddebian> mdz: My only point was, if I could just sync, maybe I would just synck, let the buildd do the work, then if it fails re-pull it and "fix" it?
<Kamion> mdz: not of universe
<Kamion> but yes, I do
<mdz> bddebian: why?
<Keybuk> must get around to setting a local mirror up at some point
<bddebian> I wouldn't but I am saying if I'm "lazy"
<Keybuk> though I'd suspect I'd still use archive.ubuntu.com to ensure it's up to date :)
<Kamion> mdz: having to ask a person to do the work means that people feel guilted into testing it first rather than afterwards :-)
<mdz> Kamion: now that I buy
<bddebian> Kamion: Exactly :-)
<Kamion> the effect is really noticeable
<Hobbsee> really, why *wouldnt* they test that something is buildable and installable before they sync it?  besides laziness, of course
<mdz> "having to request a sync from an archive admin puts the fear into them" is a stronger argument than "they might modify a local sync tool to do bad things"
<Kamion> compare syncs where people test-build in pbuilder and the works before they request them, to ordinary uploads where people throw six in a row at the buildd until one sticks
* Hobbsee cant imagine how people do the latter have upload rights.
<Kamion> it's interesting, and sort of depends on the tools you use on a regular basis
<Keybuk> mdz: s/bad/good/
<Kamion> for instance I have to do a lot of weird things with translations
<Keybuk> six in a row?  that few?
<Kamion> so I often have locally-modified versions of the gettext and po-debconf toolset kicking around
<Hobbsee> Keybuk: you mean people really do that?  intentionally?  ouch!
<Kamion> after a while, you sort of get inured to having to hack things locally until they work, and you don't always necessarily get around to pushing things back to the distro
<Kamion> anyone who disputes this gets to show off the contents of their ~/bin/ :-)
<jdub> moreutils!
<Kamion> $ ls bin | wc -l
<Kamion> 129
<Keybuk> Hobbsee: well, not so much intentionnally.  People do upload things they think should work, and then fix them, and then fix them harder, and then go and fix them even harder still, etc.
<Kamion> "this time it'll work for sure, I see the problem, don't need to test that"
<Keybuk> Kamion: amusingly, my bin contains a modified debsign, a modified dupload, a modified dch, etc. :p
<Kamion> etc.
<Hobbsee> Keybuk: ah.  right.  which for the most part could still be avoided by testing in a pbuilder.
<Hobbsee> bleh, okay.
<Kamion> Hobbsee: right, it's a trade-off between definitely spending the effort now and maybe spending the effort later
<Kamion> I can understand why it happens
<Keybuk> and then there's those people that are allergic to pbuilder
<Hobbsee> Kamion: yeah, fair enough
<Kamion> not saying it's good practice, but I can understand it
<Hobbsee> yeah
<Hobbsee> Keybuk: now they do need to be trained better.  actually, more people seem to be allergic to the MOM.
<Keybuk> Hobbsee: I think most people didn't *know* about MoM
<Kamion> I have to say I don't really trust MOM to merge some of my weirder packages :-)
<jdub> well, MOM just tells you to clean your room (packages)
<Hobbsee> Keybuk: there are still a fair few people who refuse to use it
<Keybuk> well, no, if you know a package intimately, the chances are you can do a far better job than MoM
<Kamion> this is no particular reflection on MOM - debian-installer is kind of a corner case for instance
* Hobbsee has seen a few weird bits from MoM, that just dont look right.
<Keybuk> Hobbsee: meh, I've just never really got pbuilder to work without feeling sick
<Hobbsee> Keybuk: really?
<Keybuk> really
<Hobbsee> Keybuk: you're one of those chroot people, i guess (ack)
<Keybuk> nah
<Keybuk> I just build it on my usual machine
<Keybuk> and every month or so, go round and purge all the accumulated build-deps
<Kamion> Hobbsee: if you usually work down near the bottom of the software stack, it's a lot easier
<Hobbsee> hehe.  does that end up working, or do you get packages thrown back?
<mdz> that's what I do too
<Hobbsee> Kamion: that is true
<Kamion> GNOME upload du jour doesn't make a lot of difference to whether udev works
<Keybuk> Hobbsee: I have an almost 100% build rate <g>
<Hobbsee> Keybuk: ah right :P
<Keybuk> Kamion: though, sadly, the same cannot be said the other way around <g>
<mdz> Keybuk: we should collect stats on that
<Keybuk> mdz: LP does
<mdz> Keybuk: really? where?
<mdz> I mean actually cook them and display them
<mdz> LP has the data
<Keybuk> it doesn't graph them
<Keybuk> they're supposed to affect your karma though
<Hobbsee> mdz: in a locked filing cabinet in the disused lavitory with a big sign on it sayign "beware of the leoppard"  :P
<Hobbsee> so you could get reverse karma that way, hmmm...
<mdz> Keybuk: no need for a graph; stats for the current release would be good enough
<Kamion> Keybuk: I was particularly impressed to see the proposal in the soyuz-karma spec that archive admins should get lots of karma for processing NEW ;-)
<mdz> I have no idea where my karma comes from
<mdz> I don't do that much in LP
<Kamion> spec tracking is grossly weighted upwards
<Kamion> indeed, /people/mdz/+karma says you have 143545 points from spec tracking
<Kamion> it's probably nearly all from the pre-UDS spec juggling
<Keybuk> Kamion: also, more pointedly, it's not really possible to test sysvinit changes in a chroot
* bddebian doesn't use MoM
<Keybuk> that's the main thing that annoyed me about pbuilder, actually
<Keybuk> it was harder than I'd prefer to keep the chroot around so you can actually run what you just built
<Kamion> there's an obvious difference between core-dev and dev on this; if a core-dev runs edgy, and their system blows up, chances are they can probably fix it and get the fix in the archive post-haste, unless it's something requiring really specialist knowledge like the kernel
<Keybuk> and it didn't do the most obvious test of "build a new version while the old version is already installed" which an amazing number of source packages used to (and probably still do) fail on
<Kamion> the same is not necessarily true (and shouldn't have to be true) of developers working in more specialised less core areas
<mdz> rodarvus: xserver-xorg-input-elographics is in main but not depended upon by anything or seeded
<mdz> Kamion: interesting, I didn't know about /+karma
* bddebian 's karma is falling :-(
<mdz> though it's apparently important enough to be the very first thing in the navigation portlet
<zul> meh...karma..
<Keybuk> Kamion: the shiniest part of LP always tends to give the most karma points
<mdz> but not important enough for the karma display to have a hyperlink
<Keybuk> usually whichever bit Mark touched last
<zul> it would be nice if uploads were counted
<Keybuk> then an LP dev goes around and decreases it all
<mdz> they aren't?
<mdz> hmm, apparently not
<zul> nope
<Keybuk> soyuz doesn't do karma, there's a spec for it
<bddebian> zul: Aye
<Kamion> "soyuz-karma" in fact
<Keybuk> Kamion: at least it's not "edward"
<Keybuk> \o/  25 merges left, and over 24 hours to do them in
<Hobbsee> Keybuk: get going then :P
<Keybuk> tomorrow I have dhcdbdbdbdbdbdbdbdbdb and n-m
<Hobbsee> ah, n-m should be fun
<Keybuk> Hobbsee: meh, not especially;  today I did courier, that was fun
<Kamion> tomorrow I have more debian-installer and more gparted
<Keybuk> in a soul-destroying kind of way
<Hobbsee> hehe
<jdub> Keybuk: courier -> universe! yay!
<Kamion> both of which are soul-eating monsters although at least I have debian-installer done bar the shouting
<Keybuk> I suspect I'll need to beat BenC up a little more to do kernel-wedge and kernel-package
<zul> Keybuk: yeah you might
<Kamion> elmo: at this point it would be really convenient to have some way to get packages from the master archive as opposed to ftp.acc.umu.se :-/
<BenC> Keybuk: almost ready to upload both
* BenC has made a day of kernel-*
<Keybuk> BenC: oh, well done that man
<bddebian> Keybuk: Anything I can help with?
<Kamion> might get installation-guide done tomorrow if I'm very lucky
<Keybuk> bddebian: I'm so sorely tempted to say "ia32-libs" ... but I wouldn't wish that on my worst enemy
<Kamion> hopefully Mithrandir will get xfonts-utils done tomorrow
<Keybuk> there's about a dozen X things outstanding still
<bddebian> I started to do some X stuff but by the time I woke up when you all woke up, they were uploaded :-(
<Kamion> Keybuk: how come xfonts-utils isn't in main-manual.html?
<bddebian> s/all woke up/all were awake/
<bddebian> Well my offer stands if I can do anything for anyone
<Kamion> Keybuk: maybe a public page with the blacklisted packages would be good ...
<Keybuk> Kamion: because it's not a source package?
<Keybuk> Kamion: mom doesn't have a blacklist
<Kamion> Keybuk: it is in Debian
<Keybuk> though I agree the sync blacklist should be public, though I've yet to get that pushed further (I put it in bzr)
<Keybuk> Kamion: right ... but not in Ubuntu
<Kamion> yeah, a list of those cases would be good
<Keybuk> so it's not something MoM can even see
<Kamion> the sync blacklist is public
<Keybuk> it is now?
<Kamion> I did that in Paris
<Kamion> http://people.ubuntu.com/~cjwatson/sync-blacklist.txt
<Keybuk> oh, cool
<Keybuk> I'll have to remember to be not rude in that file now :p
<Kamion> I de-rude-d the existing contents before publishing :-)
<Keybuk> Kamion: I don't know how we'd define those cases ... MoM only deals with source packages
<Kamion> it has the list of source packages in Debian though, doesn't it?
<Keybuk> aww, I'm sure Marco and Branden wouldn't have minded <g>
<Keybuk> Kamion: yes
<Keybuk> but I'm not sure how that helps?
<Keybuk> those generally need syncs, not merges
<Kamion> actually there are sort of two cases - "never sync ever again" and "don't autosync just yet"
<Kamion> xfonts-utils is an example of the latter, and needs a merge
<Keybuk> right, those are the things at the top of the sync-blacklist
<Kamion> yeah
<Keybuk> the very top is "keybuk hasn't yet drunk enough coffee to understand these"
<Kamion> (Debian - Ubuntu) - "never sync ever again" is approximately what we want
<Keybuk> the middle is "other people are dealing with them"
<Keybuk> and the bottom is "never sync" :p
<bddebian> hehe
<Keybuk> if we split sync-blacklist into a temporary and permanent blacklist
<Keybuk> then we could easily generate the list on drescher
<Kamion> anyway, why am I still awake ... night all
<Keybuk> it's output of "new-source"
<bddebian> gnight Kamion
<Hobbsee> night Kamion 
<Keybuk> heh, indeed, night all also
<bddebian> Bums ;-P  Gnight Keybuk
<bddebian> fsck'n a skippy, maxima built
<sbalneav> Evening all
<Hobbsee> hi sbalneav 
<sbalneav> Have some unsigned packages made it into the dapper archive, or is ca.archive.ubuntu.com having problems?
<bddebian> Is mesa on the blacklist?
<bddebian> Oh, NM, it's on the main merges page
<bluefoxicy> meh.  I wish I knew more about apt internals.
<bluefoxicy> a mirror system like gentoo had would be great
* bluefoxicy idly puts massive load on one server with constant updating
<bddebian> reprepro
<bddebian> rsync
<bluefoxicy> bddebian: ?
<bddebian> apt-cache show reprepro
<bluefoxicy> bddebian:  no not emerge sync; I mean how it would use mirror://gentoo which would use a mirror list, which you updated with a script that pinged every known mirror and picked the 3-5 closest ones, then it'd round robin through those to distribute load... looking at reprepo
<bddebian> Ahh
<bluefoxicy> reprepro looks nice, I was thinking about how to get a local repository for a network (i.e. enterprise network, 1 gazillion machines, do you want to hear a story about an idiot that scheduled an ENTIRE school district to update to WinXP SP2 directly from windowsupdate or can you guess what happened?)
<bluefoxicy> but I'm currently more concerned that practically everyone who installs Ubuntu is pointing at us.archive.ubuntu.com
<bddebian> Oh I can guess, I maintain Windows servers at work
<bluefoxicy> yes see smart people sync windowsupdate down to some kind of MFPSomething server I can't remember what it's called and then push patches that way ;)
<bluefoxicy> because 3 days without internet sucks.
<bddebian> I think it's SPS now but it keeps changing
<bluefoxicy> bddebian:  What kind of load DOES us.archive.ubuntu.com experience anyway?
<bluefoxicy> more importantly
<bluefoxicy> what happens if tomorrow we have 90% market share and MS is dead?
<bluefoxicy> update-manager runs apt-get update every day
<bluefoxicy> it downloads but doesn't install packages in the background, security packages can be auto-installed........
<sharms> well us.archive.ubuntu.com isn't just one server right
<sharms> it should be multiple servers using round-robin dns?
<bluefoxicy> sharms:  us. seems to imply a specific subset of servers
<bluefoxicy> but yes it should, lemme ping it a bunch of times.
<bluefoxicy> yes it is.
<sharms> just because it is a subset of servers doesn't mean there are not a bunch of them :)
<sharms> and you have to remember dns caching will prevent you from hitting all of them via ping
<bluefoxicy> yeah, aren't there also canadian and europe and korean servers though?
<elmo> sigh
<bluefoxicy> PING us.archive.ubuntu.com (82.211.81.182) PING us.archive.ubuntu.com (82.211.81.151) 
<elmo> $cc.archive.ubuntu.com => $cc == country code
<elmo> so not "practically everyone" who installs ubuntu will get us.archive.ubuntu.com, just people with a US locale
<bluefoxicy> hmm.  It automatically picks based on locale?
<elmo> and the load on those servers is fine.  and we're not going to get a 90% market share tomorrow
<bluefoxicy> I only speak english so I never tried chinese ;)
<elmo> you'd get a better response from people if you didn't invent insane and unrealistic hypotheticals like that
<sharms> actually he does have a point though
<jsgotangco> try it out
<bluefoxicy> elmo:  I'm a security guy, I'm thinking in terms of business continuity now or something.
<sharms> security isn't regionally set is it elmo?
<elmo> security isn't, no
<sharms> right
<elmo> and the load on that server isn't a problem either
<bluefoxicy> no, but the "What do we do if load spikes by 300 times" scenario is a business continuity thing.
* jsgotangco computer is set to gb and ph
<sharms> elmo: it was today for almost an hour
<sharms> or atleast the dns
<sharms> and we are at .00001% marketshare
<bluefoxicy> in security classes they teach you about what you need to do to make sure you can keep a business going if the building it's in burns down.
<elmo> sharms: no, it wasn't
<sharms> elmo: it was functional and online all day today?
<elmo> I took it offline for a very deliberate reason, it wasn't down due to load
<elmo> so please, stop with the FUD already
<sharms> done :)
<bluefoxicy> sharms, elmo:  That brings me to an odd question.  why is it on some days I can get 100K/s from there and on others I get like 800k/s  o_O
<bluefoxicy> it's not my end, when my net seems slow I try mozilla, sourceforge, and ubuntu CD image download mirrors to see if I can get over 300k/s from any of them
<bluefoxicy> I'd assumed it was load
<bluefoxicy> eh.  I guess that's a mystery that'll never be solved.
<bddebian> I'd blame elmo if I were you :-)
<bddebian> And with that, I will say adeu.  Gnight folks
<sharms> same here, take it easy
<bluefoxicy> does anyone on edgy know if man 2 open is correct?
<bluefoxicy>        int open(const char *pathname, int flags);
<bluefoxicy>        int open(const char *pathname, int flags, mode_t mode);
<bluefoxicy> this part inparticular.
<bluefoxicy> looks like it is.  Thought that was a C++ thing.
<fabbione> it is correct.
<dholbach> good morning
<siretart> Riddell: thanks for handling xine!
<fabbione> siretart, slomo_ : ping?
<siretart> fabbione: yes?
<fabbione> siretart: is it just me or some audio codecs in mplayer are bad?
<siretart> fabbione: which ones? I didn't notice regressions yet
<fabbione> i need to check..
<fabbione> one sec
<fabbione> oh meh.. go find the url again..
<fabbione> siretart:
<fabbione> Opening audio decoder: [mp3lib]  MPEG layer-2, layer-3
<fabbione> AUDIO: 22050 Hz, 2 ch, s16le, 40.0 kbit/5.67% (ratio: 5000->88200)
<fabbione> Selected audio codec: [mp3]  afm: mp3lib (mp3lib MPEG layer-2, layer-3)
<fabbione> '
<fabbione> siretart: getting a sample for you
<fabbione> siretart: see /msg
<dholbach> can somebody please promote libnet-dbus-perl to main?
<siretart> dl'ding..
<siretart> fabbione: I don't have problems playing that file
<fabbione> i do
<siretart> I'm on dapper, but I'm using mplayer_0.99+1.0pre8-0ubuntu0, which is a local prerelease of whats in edgy
<fabbione> siretart: i assume you are on latest edgy
<fabbione> nah
<fabbione> it could be anything else like a shared lib
<siretart> I prepared the ubuntu1 upload, there are no code changes to ubuntu1
<siretart> thats not unlikely, that some linked lib does foo
<siretart> MPEG-PS file format detected.
<siretart> VIDEO:  MPEG1  176x112  (aspect 12)  29.970 fps  200.0 kbps (25.0 kbyte/s)
<siretart> hm. nothing spectacular though..
<siretart> Opening video decoder: [libmpeg2]  MPEG 1/2 Video decoder libmpeg2-v0.4.0b
<siretart> Selected video codec: [mpeg12]  vfm: libmpeg2 (MPEG-1 or 2 (libmpeg2))
<fabbione> looks about the same here
<siretart> doesn't mplayer use an internal libmpeg2?
<fabbione> you are the maintainer and should know..
<fabbione> it's only the audio that's crippled
<fabbione> the video is good
<fabbione> it's like a lot of static noise
<siretart> aha?
<siretart> I also maintain xine, which I concentrated the last days more
<siretart> and xine does have an internal copy.
<siretart> but I keep on mixing the 2, they are both a mess to maintain :/
<siretart> audio codec is Selected audio codec: [mp3]  afm: mp3lib (mp3lib MPEG layer-2, layer-3)
<fabbione> siretart: audio with xine is good
<siretart> fabbione: you mean, you get sound, but it is only a lot of noise?
<fabbione> siretart: video 100% good
<fabbione> audio in xine is good
<fabbione> audio in mplayer a lot of noise
<fabbione> so yes i get audio but it's bad
<siretart> fabbione: can you perhaps try an other audio backend, like, say, oss instead of alsa and vice versa?
<fabbione> siretart: i did try to use -ao oss or -ao alsa or -ao esd
<fabbione> no changes
<siretart> interesting
<siretart> the audio stream seem to me to be plain mp3
<siretart> you get this as well?
<siretart> Selected audio codec: [mp3]  afm: mp3lib (mp3lib MPEG layer-2, layer-3)
<siretart> so it does use the same codec for you?
<fabbione> Selected audio codec: [mp3]  afm: mp3lib (mp3lib MPEG layer-2, layer-3)
<fabbione> yeps
<jdub> is there any info on building custom kernels pre-edgy? (i konw it's scary and bad, but i'd like an answer for people who demand it)
<Burgundavia> jdub: there might be something in the help wiki
<siretart> fabbione: do you have a chance to try on another machine? I suspect problems in your sound card driver
<fabbione> siretart: it did work with the last kernel and stuff right before the last update of mplayer
* jdub growls about having to search in multiple places
<fabbione> that means the sound card driver is good
<Burgundavia> jdub: all of that should now be on the help wiki
<jdub> Burgundavia: 'that' -> dude, there is mountains of stuff on the real wiki
<siretart> fabbione: so downgrading to dapper's mplayer does fix things for you?
<Burgundavia> jdub: yes, but if it was documentation, it should have moved
<Burgundavia> jdub: if it didn't, please tell us
<jdub> Burgundavia: what *isn't* documentation on the real wiki?
<jdub> edgy stuff: https://wiki.ubuntu.com/KernelCustomBuild
<fabbione> siretart: i didn't check that yet. I did watch movies 2 days ago or so.. it was good... yesterday upgrade no good.. so i assume a downgrade will do.
<fabbione> siretart: gimme 2 minutes to try it
<jdub> Burgundavia: two wikis is a terrible hassle
<Burgundavia> jdub: so was one wiki
<sivang> morning
<jdub> Burgundavia: two is worse
<mdke> jdub: it's a bit late for this. You had 9 months to comment on the spec for splitting them.
<jdub> mdke: it's not really something for me to contribute to directly, but now that it's happened (and given my comments about exactly this in the distant past), i'm seeing problems
<mdke> jdub: it's 3 wikis we have
<mdke> don't forget www.ubuntu.com
<mdke> if you look at them as websites with different functions, it works.
<Burgundavia> mdke: that is not really a wiki, perse
<jsgotangco> its not like the public has access to the website
<jdub> mdke: i don't regard that as a wiki (but the content seepage between all three (plus docs.u.c) isn't helpful
<mdke> my point is not to get hung up on the "wiki" thing
<jdub> i'm not hung up on the wiki thing
<mdke> you need to see that there is a documentation website, and it is separate from the community development place for a good reason
<jdub> i wish i could see it that way
* mdke shrugs
<mdke> It's really working well, I think
<fabbione> siretart: yes, downgrading works fine
<jdub> but you've got plenty of inertia to battle
<Burgundavia> jdub: I notice since the move we have been getting lots of new people helping out
<jdub> and wuc is easier to contribute to
<mdke> no
<mdke> people hated contributing to the old wiki, simply because of the confusion and the fact it was terrible to get help on
<jdub> Burgundavia: i am not convinced that could not have been done with a clear editorial team on wuc (who could provide some actual content management)
<Burgundavia> jdub: we were drowning in non-doc stuff
<siretart> fabbione: hm. damn. can you perhaps file a bug, mentioning the codec in question and you audio hardware and driver?
<siretart> fabbione: I need to find some hours to trace the code changes since the last release (and there are a lot of changes!!)
<jdub> mdke: it has been split now, but i do think that the same goals could have been achieved by managing the existing wiki
<mdke> jdub: they couldn't.
<jdub> mdke: huc seems a bit like picking up the shovel and bucket and making a new sand castle :-)
<jdub> mdke: it seems we strongly disagree on that point, then ;-)
<mdke> dunno about strongly
<mdke> it's a documentation website. All documentation is now in the same place, hardly a new sand castle
<mdke> reinforcing the old one, more like
<jdub> mdke: what happens if i link JeffWaugh on huc?
<pitti> Good morning
<Burgundavia> jdub: that is an issue we have not yet resolved, but can be fairly easily (we can link names to the old wiki)
<mdke> jdub: it links to JeffWaugh
<jdub> (categories are a good way to layer structure on top of an existing moin wiki - you can limit searches to them, etc.)
<jdub> mdke: but JeffWaugh doesn't live in that sand castle ;)
<mdke> true
<mdke> is it likely that your name will be used in documentation?
<jdub> i hope so
<jsgotangco> lol
<jdub> i would like to be famous some day
<Burgundavia> jdub: but then what do you have default search as? what about the in-svn documentation?
<fabbione> siretart: meh i just gave you all the info, but it's not a hw/kernel issue
<mdke> jdub: use "wiki:Ubuntu/JeffWaugh"
<jdub> mdke: hopefully you get my point :)
<Burgundavia> jdub: moving the help wiki was not really like creating a new site, it was merely moving the help wiki stuff to the same place that the in-svn stuff was
<mdke> it's a non-point, for me
<Burgundavia> like mdke, reinforcing, not creating
* mdke has to get to work
<jdub> Burgundavia: heh, "not really like creating a new site", although you happened to be... creating... a... new... site...? :)
<mdke> jdub: nope, it was there already
<Burgundavia> indeed
<mdke> it had the docs from the distro on it
<mdke> now it has all docs
<jdub> it was there already, but it wasn't a separate wiki
<mdke> here you go again with the wiki thing
* mdke runs off to work
<jdub> considering that it is a wiki, i don't think that's an obscene idea to muse upon :)
<Burgundavia> jdub: like the main ubuntu webpage, the help website is a help website, helped along by the wiki, rather than a wiki first
<jdub> Burgundavia: i understand the theory
<fabbione> siretart: 52279 for you
<siretart> Ubugtu: bug #52279
<Ubugtu> Malone bug 52279 in gnome-games "AisleRiot crash by select other game variants" [Unknown,Fix released]  http://launchpad.net/bugs/52279
<fabbione> ehm
<fabbione> 52729
<siretart> Ubugtu: bug #52729
<Ubugtu> Malone bug 52729 in mplayer "[EDGY]  Regression: broken audio playing certain movies" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52729
<fabbione> siretart: if you need more speak now :)
<siretart> fabbione: may I attach the file you gave me?
<fabbione> siretart: you should check the copyright before you do so
<fabbione> siretart: i don't remmeber the origin of it
<fabbione> it was on some funny web site
<fabbione> siretart: people can ask me for the file
<fabbione> it's not an issue
<siretart> ah ok
<siretart> I'm checking on my edgy laptop
<fabbione> edgy with dapper mplayer is good
<chmj> elmo: ping 
<fabbione> i wonder if it might be due to miscompilation
<siretart> fabbione: I'm trying now with 0.99+1.0pre8-ubuntu3 on recent edgy
<siretart> fabbione: sound driver: i810 internal on thinkpad r50e, no problems :(
<fabbione> it happens reliably here and i can ensure you it's not a kernel issue
<fabbione> otherwise the dapper version wouldn't work at all
<siretart> what sound hardware do you use?
<siretart> fabbione: and can you perhaps check/compare your /etc/mplayer/* against the versions in the package?
<siretart> I suspect codecs.conf
<fabbione> i didn't customize it
<fabbione> Setting up mplayer (0.99+1.0pre7try2+cvs20060117-0ubuntu8) ...
<fabbione> Installing new version of config file /etc/mplayer/mplayer.conf ...
<fabbione> Installing new version of config file /etc/mplayer/codecs.conf ...
<fabbione> Installing new version of config file /etc/mplayer/input.conf ...
<fabbione> Installing new version of config file /etc/mplayer/menu.conf ...
<fabbione> downgrading/upgrading
<fabbione> so i am using the defaults
<siretart> 66d11846722498ed54bf5ddc766a95ab  /etc/mplayer/codecs.conf
<siretart> 32924d4067d6307a107393834015fa9a  /etc/mplayer/input.conf
<siretart> md5sums on my machine.. for you as well?
<fabbione> new or old ones?
<siretart> the new ones
<pitti> slomo_: can you please check the new hal revision into bzr?
<fabbione> 66d11846722498ed54bf5ddc766a95ab  codecs.conf
<fabbione> 32924d4067d6307a107393834015fa9a  input.conf
<fabbione> yeah they match
<bluefoxicy> hi pitti
<pitti> hi bluefoxicy 
<bluefoxicy> pitti: mail me a gcc hacker
<pitti> bluefoxicy: I always have difficulties squeezing them through the ethernet cable
<bluefoxicy> pitti:  ;)
<bluefoxicy> pitti:  Did you see my post on -devel?
<pitti> bluefoxicy: yes, I saw it, but I didn't have time yet to answer
<pitti> Kamion: I want to fix some stuff in anastacia (just did redland-bindings for php4 and will do backuppc for wwwconfig-common), but there are some things I don't understand
* bluefoxicy sleeps
<pitti> Kamion: do you have an idea why python-jabber wants python2.2?
<slomo_> fabbione: pong?
<slomo_> pitti: sure, one moment... sorry
<siretart> slomo_: see bug #52729
<Ubugtu> Malone bug 52729 in mplayer "[EDGY]  Regression: broken audio playing certain movies" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52729
<dholbach> can somebody please promote libnet-dbus-perl to main? :)
<pitti> dholbach: not without ssh logins
<dholbach> pitti: urg, true
<pitti> darn, I can't even upload
<mdz> pitti: maybe because of this
<mdz> pyversions: missing XS-Python-Version in control file, fall back to debian/pyversions
<mdz> pyversions: missing debian/pyversions file, fall back to supported versions
<pitti> oh, hi mdz
<pitti> mdz: hm, I'd expect it to fall back to 2.4.., I'll check that
<mdz> my @python_allversions = ('1.5','2.1','2.2','2.3','2.4','2.5');
<pitti> mdz: it builds fine here locally, and uses 2.4
<mdz> pitti: my local build gets the 2.2 dependency from python:Depends
<pitti> ah, right
* pitti fixes
<mdz> pitti: what's wrong with ssh logins?
<mdz> dholbach: I'll promote libnet-dbus-perl once cron.daily finishes
<fabbione> mdz: known issue at the DC
<dholbach> mdz: "chinstrap (-> all DC) logins down - known problem, no ETA currently"
<dholbach> mdz: merci beaucoup
<siretart> slomo_: fabbione: i just upgraded my edgy laptop, still no problems. I'm off for uni now, cu later!
<fabbione> siretart: later
<mdz> dholbach: I have a shell open which seems to work fine; I'll try to remember not to logout ;-)
<dholbach> mdz: hehe :)
<slomo_> siretart: everything i tested with the new mplayer worked fine here too
<fabbione> slomo_: do you want the file i have issues with?
<slomo_> fabbione: sure
<crimsun> fabbione: which arch?
<fabbione> crimsun: i386
<crimsun> k
<mdz> pitti,dholbach: has anyone looked at libcairo-perl yet (MIR)?
* pitti didn't
<fabbione> slomo_: /msg
* dholbach neither
<slomo_> fabbione: thanks
<fabbione> slomo_: np
<slomo_> fabbione: woohoo... sounds nice ;) weird...
<slomo_> and works fine in totem... hm
<fabbione> it works in xine too
<fabbione> and it works with dapper mplayer
<fabbione> it doesn't work with edgy mplayer
<fabbione> so that's why i am pretty sure it's mplayer regression
<slomo_> ok, noted on my todo list...
<crimsun> slomo_: http://svn.mplayerhq.hu/mplayer/trunk/mp3lib/dct64_3dnow.c?r1=18837&r2=18946
<slomo_> crimsun: good catch :) thanks, i'll test it
<fabbione> crimsun: to add or to revert?
<slomo_> add
<fabbione> sladen: i can test it locally...
<fabbione> slomo_: ^^
<slomo_> fabbione: ok, feel free to upload mplayer with that patch if it works :)
<pitti> doko: bah, I have no idea how to teach jabber.py to not create a dependency on python2.2; do you have any idea? I added debian/pyversions and played with the build deps, but no luck
<fabbione> slomo_: no :) i will tell you if it works..
<crimsun> slomo_: fabbione: I haven't eyeballed the diff history further back, so it may require additional the mmx changes
<crimsun> the additional ^
<fabbione> slomo_: i am not going to adopt mplayer ;)
<fabbione> crimsun: ok thanks don't worry :)
<fabbione> crimsun: 3d now?
<fabbione> might be
<fabbione> this is an amd64 cpu running i386
<pitti> doko: ah, got it; nevermind
<pitti> doko:  one shipped example used #!/usr/bin/python2.2
<fabbione> slomo_: you need to get a new cvs snapshot probably.. that patch doesn't apply
<mdz> pitti: aha
<pitti> mdz: I'll upload a fix as soon as ssh works again and send the patch to debian bug 377813 
<Ubugtu> Debian bug 377813 in python-jabber "Subject: Uninstallable due to unmet dep on python2.2" [Serious,Open]  http://bugs.debian.org/377813
<mdz> pitti: you shouldn't need ssh to upload it
<pitti> mdz: I do, I can't ftp from here
<mdz> pitti: yuck, why not?
<pitti> mdz: so my upload script scp's to chinstap and calls ssh dput
<pitti> mdz: braindead configuration of my ISP
<pitti> mdz: bah, I'll just do a Debian NMU
<\sh> moins
<mdz> do we really want cyrus21 in the server seed?
<fabbione> mdz: wasn't common agreement to kill it?
<seb128> mdz: "gnome-applets is next uploaded and rebuilt" ?
<pitti> mdz: if we want cyrus, then 2.2
<seb128> mdz: why "new uploaded"?
<pitti> (I'd say)
<mdz> dunno about that, but it is an old version
<seb128> s#new#next
<mdz> seb128: "new uploaded"?
<ogra> dholbach, g-p-m will still take a while ... the codebase for Kinnison's most important patches that enable suspend doesnt exist anymore and i found out why the icons didnt work, they are all renamed and 24x24 doesnt exist anymore as size (and there are twice as much icons now)
<fabbione> mdz: kill it, kill it!
<mdz> I thought we already had a cyrus imapd in main
<pitti> mdz: but as long as we don't receive requests to include it, we can maybe drop it alltogether
<pitti> mdz: we kicked it out of dapper
<seb128> mdz: ups, I said nothing, it got stucked because of the gnome-python-desktop borkage and I forgot to upload it then ...
<seb128> mdz: thank you for the reminder, fixing that now ;)
<dholbach> ogra: then please drop the icon patch - i'm going to fix it up once it's in the archive - that's nothing to be blocked on
<mdz> pitti: I don't see it in breezy though
<pitti> cyrus21-imapd | 2.1.18-1ubuntu1 | http://archive.ubuntu.com breezy/main Sources
<mdz> never mind,there it is
<mdz> heh
<ogra> dholbach, i know, i didnt say i was blocked :) but there is a lot of icon work on the hirizon for you 
<mdz> dholbach: promoted libnet-dbus-perl and friends just in time
<pitti> mdz: oh, the binary is in universe
<ogra> *horizon
<dholbach> mdz: rock on!
<mdz> dholbach: Connection to chinstrap.ubuntu.com closed by remote host.
<dholbach> urg :(
<dholbach> ogra: i can't wait for it...
<dholbach> :-)
<mdz> pitti: ok, I've committed it to my local seeds
<ogra> haha
<mdz> oh, I should be able to still ssh to the supermirror probably
<pitti> mdz: jabber.py NMUed to Debian, so we'll get it this evening
<pitti> doko, Kamion: ^ so please don't bother fixing it in Edgy
<pitti> oh, tomorrow evening rather
<Kamion> you might need to request a special sync for that, UVF being tomorrow and all
<pitti> oh, true
<pitti> Kamion: ok, I'll ask Keybuk to sync from incoming then
<fabbione> what's the official time for UVF to start?
<mdz> when we sleep
<fabbione> that means never...
<ogra> heh
<pitti> fabbione: if 'we' == mdz and Europe :)
* fabbione is having a little discussion with cluster suite update
<pitti> mdz: I'm confused why libxmlsec1-gnutls wants to pull in gnutls11 - the package is in universe and depends on libgnutls13
<mdz> pitti: I uploaded a fix
<mdz> probably anastacia is out of date
<pitti> ah
<pitti> ok, I uploaded redland-bindings
<pitti> that should solve apache and php4
<pitti> mdz: dictionaries-common b-deps on links, but that's provided by elinks; the buildds manage to resolve that
<pitti> mdz: nevertheless, I'll upload a fix for that, we modified the package anyway
<Kamion> infinity: when you're bringing up hppa, could you make sure to build newt before cdebconf? thanks
<fabbione> bootstrapping hppa is going to be real fun
<fabbione> glibc/kernel/kernel-headers/gcc in an endless loop for ssp
<fabbione> and then all the rest of the world
<ogra> ogra@edubuntu:/mnt/devel/seeds$ bzr checkout sftp://ogra@bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.edgy
<ogra> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<ogra> meh, LP doesnt like me today :(
<pitti> ogra: ssh to chinstrap is broken
<ogra> ooh
<ogra> but that must have happened between tzhe two checkouts
<ogra> i checked out the edubuntu seeds a second before i first tried the ubuntu ones
<Kamion> ssh to bazaar.launchpad.net doesn't normally go through chinstrap, so ...
<ogra> ah, k, hmm ...
<elmo> it's been taken down too, I'm working on it
* ogra leaves the seeds alone then and goes back into power manager hell 
<Hobbsee> ogra: it's not being kind?  doesnt leave me much hope for the kde side then...
<elmo> ogra: should work now then
<elmo> s/then//
<ogra> Hobbsee, the merge is evil
<Hobbsee> ogra: :(
<ogra> elmo, not yet
<elmo> ogra: what error?
<ogra> elmo, ssh: connect to host bazaar.launchpad.net port 22: Connection refused
<elmo> oh, blah
<ogra> (with a paramiko backtrace afterwards indeed)
<ogra> Hobbsee, three way megre of the special kind ... we have an old package, debian has one and the upstream source changed completely (not to mention our package has 13 patches included that need merging)
<Hobbsee> ogra: *ouch*
<Hobbsee> that's nasty
<ogra> i could drop 4 of them though and have only 3 left ... but these three are huge and there is no upstream code anymore for them to apply to
<ogra> sadly they are the ones that make everything work :)
<sivang> anybody else lost some panel functionality and applets after dist-upgrading today?
* sivang tries to identify if it's local to his machine
<Zdra> sivang: me too
<sivang> Zdra: thanks, /me goes to see if I can fix it
<Zdra> :)
<janimo> dholbach: hello, FYI latest xfce has ctrl-esc for menu that you missed 
<dholbach> janimo: ahhhh nice
<dholbach> hey janimo - good to see you back :)
<sivang> hey janimo 
<pitti> hi janimo, how's it going?
<janimo> pitti, sivang hi guys
<dholbach> janimo: i'm used to use alt-f1, but ctrl-esc is better than nothing ;-p
<janimo> I am egtting busy agains since xfce just released a new beta
<janimo> dholbach: it is settable :)
<iwj> LaserJock: pong
<dholbach> doko: if you have no objections, I'm going to drop CxxLibraryList, FinishedUniverseLibraries ,CxxLibraryResync, UniverseCxxTransition?
<dholbach> doko: ... from the wiki
<doko> dholbach: fine
<dholbach> doko: thanks
<Gloubiboulga> janimo, hi, I have some issues with the mcs manager on edgy
<crimsun> janimo: are we proceeding with xfmedia>gxine? If so I'll prioritise the merge today for UVF.
<dholbach> Riddell: safe to drop KubuntuCXXtransition from the wiki?
<Gloubiboulga> janimo, it can't load the modules which hasn't been built against the last mcs version
<janimo> crimsun: I agree with going gxine
<janimo> Gloubiboulga: I'll have a look, do you have the latest mcs-manager and mcs-plugins?
<janimo> Gloubiboulga: I remember upstream did that to prevent duplicates showing up
<Gloubiboulga> janimo, yes, updated a few hours ago. A rebuild fixes everything (I've rebuilt exo, orage, xfce4-session, xfdesktop and xfwm4)
<janimo> latest session has not yet been uploaded as we have a big HAL patch
<janimo> the rest I'll do uploads again, thanks for noticing
<janimo> due to broken debuild I worked from dapper and only now started testing the built stuff in edgy
<seb128> janimo: are you doing syncs with Debian for xfce?
<Mithrandir> is merges.ubuntu.com down?
<janimo> seb128: nope
<seb128> janimo: why not? 
<seb128> Mithrandir: connection refused
<janimo> seb128: several reasons
<seb128> janimo: everybody else is doing his merges and a stack of xfce are listed on the merge list for main
<janimo> seb128: our packages are diverged
<seb128> janimo: and they have to be done for tomorrow
<janimo> seb128: a stack? (you mean 3 packages)?
<pitti> Mithrandir: doesn't work for me either
<seb128> janimo: dunno, the list is down atm :p
<seb128> janimo: but things like xarchiver are listed iirc
<janimo> seb128: oh by merges you mean not necessarily sync from debian, but just get newer versions so the merges do not show up?
<seb128> janimo: one of the goal for those merges is to be near of Debian ... 
<janimo> in this case yes I have been 'merging'
<janimo> seb128: could you talk to debian xfce maintainers?
<seb128> janimo: no, I mean doing an update based on the Debian package
<Kamion> you should be merging packaging from Debian as appropriate too
<pitti> janimo: you should use the Debian packaging as long as possible
<Kamion> this means that the Ubuntu packages are not just dependent on a single guru who knows how they all work
<seb128> janimo: like taking the Debian package, updating for the new version and reapplying Ubuntu changes you need over Debian
<janimo> guysm I know this. However xfce deb mainatiners are 'not friendly' to put it mildly, and they have not much time keeping xfce up to date in debian
<elmo> ogra: fixed, really.
<seb128> janimo: that's not a matter of "uptodate"
<seb128> janimo: that's having packaging near of the Debian one
<janimo> seb128: they're mostly uptodate now, but not the same as in debian
<seb128> the goal of merging is to be near of Debian
<seb128> not to be uptodate :)
<ogra> elmo, confirmed :)
<seb128> is there any reason than the Debian packaging can't be use for Ubuntu?
<janimo> seb128: really? tell that to gnome/kde/X/kernel maintainers in ubuntu :)
<seb128> janimo: we did merge almost the whole GNOME from Debian since previous week
<Kamion> janimo: the Ubuntu X folks have been spending the last week or two merging packaging from Debian, so I'd pick a better example if I were you
<sivang> janimo: we could also do it like we do for GNOME , merge debian changes, and then import new upstream.
<janimo> seb128: yes, they do not use cdbs all over - I am sure this convinced you ;)
<seb128> janimo: even when they use debhelper, we don't have any reason to change the packaging system over them
<Kamion> janimo: there are cases for individual divergence, but the default is to do what Debian does
<mdz> seb128: gaim seems to honor GNOME proxy settings now, but I am not sure this is a good idea
<seb128> we have some GNOME package using debhelper
<slomo_> doko: what's the status of the gcc/libgcc breakage on ppc?
<seb128> mdz: why not?
<janimo> Kamion:, seb128: that is nice. There are 5 debian xfce packagers I ahve repeatedly approached them about friendly merging and sharing
<mdz> seb128: it uses CONNECT, and squid by default doesn't allow that for arbitrary ports
<doko> slomo_: needs infinity for bootstrapping
<Kamion> janimo: we're just saying that the Ubuntu XFCE packages should be incorporating packaging bugfixes from Debian
<Kamion> janimo: not that you must be in exact sync with Debian
<Kamion> the standard way to indicate that you have incorporated packaging bug fixes is to do a normal merge
<Kamion> even if that merge then includes an update to a new upstream or whatever
<seb128> mdz: the account preference have a "use the global parameter", you can set it to something else
<slomo_> doko: ok... was there a real fix now or only disabling ssp in libgcc on ppc?
<janimo> Kamion: I am watching their packages and pick up stuff that is worth it. They don;t do the opposite though
<mdz> seb128: oh good
<seb128> mdz: do you think we should change the default value to "none"?
<Kamion> janimo: ok, but that's unrelated to the point of this merge session
<mdz> seb128: I think so; I imagine most proxies do not allow this by default
<mdz> seb128: where is that preference? I don't see it under network
<seb128> mdz: ok, I'll do speak with upstream about it and change it with the next upload ... could you open a bug on launchpad about it? :)
<Kamion> janimo: we have plenty of packages elsewhere in Ubuntu whose Debian maintainers are hostile to us, but we merge from them anyway
<janimo> Kamion: I have done a few uploads yetsreday. Even if they no longer show up in the merges list, the fact they still have deltas means it's not as good as it should be right?
<seb128> mdz: pick the account you want, edit it, the advanced tab
<mdz> seb128: I can tomorrow; it's almost 0300
<mdz> seb128: oh, it's per-account
<seb128> ok, thank you
<tseng> anything with XubuntuY is a "delta"
<seb128> some upstream are subscribed to launchpad for gaim
<tseng> you should just try to keep it as small as possible
<seb128> so we can have the discussion on launchpad :)
<Kamion> janimo: sure, but we don't care right now - the point of the merge session is to ensure that we have merged everything from Debian at least once since the dapper release, where possible
<Kamion> janimo: still having a delta does not mean the merge session was useless
<janimo> Kamion: sure I work on that as well
<Kamion> lots of us still have deltas to packages
<janimo> Kamion: what I was saying is that beacuse I want near 0 delta, and I know how to get it, I cannot do it w/o debian and they are not interested, hence the divagations
<mdz> seb128: more importantly, when I open a conversation, the input box is black on black
<mdz> I'll make a note to file thatt one tomorrow also
<Kamion> janimo: ok, but as I said, that's orthogonal to what seb is asking for
<ogra> wow, seed merges are so much fun ... 6 files 6 conflicts .... sigh
<seb128> mdz: ah, I had that issue when I updated to gaim2.0 beta1 some time ago I think, I bugged upstream but didn't reproduce it later
<janimo> which channel is heno most likely to be found?
<seb128> (I tried to remove my .gaim, install gaim 1.2 again and upgrade)
<seb128> mdz: I'll ping upstream about that again then, you can change the colors to the preferences dialog
<heno> janimo: hi
<mdz> ogra: there was a major seed reorganization during and after the sprint
<ogra> mdz, i know :) i'm just in ranting mode, you know ... (i'm merging g-p-m since yesterday morning ... that needs a valave ;) )
<janimo> heno, hi the latest xfce has the accessibiliy keyboard dialog
<ogra> *valve
<janimo> heno: I have not tried it yet though
<heno> jamesh: yep I saw the changelog on OSnews or somewhere. Cool!
<heno> janimo: is 4.4 on track for edgy inclusion?
<heno> or will it be too late?
<janimo> heno, it was for dapper too :) but upstream is not in a hurry. we now have 4.4beta2 hopefully we'll have final by edgy
<heno> I guess we are at UVF now (!)
<janimo> depends on when we freeze
<doko> dholbach: ssp is pitti's pit
<StevenK> steven@jaded:~% TZ=UTC date
<StevenK> Wed Jul 12 10:03:08 UTC 2006
<janimo> heno: yes but I think xfce is in the same category as gnome, or at least it was excepted semi-offically for dapper
<doko> s/pit/pet/ ;-P
<heno> ok, cool
<dholbach> doko: ok, good to know :)
<StevenK> Not for another 14 hours, it looks like.
<pitti> dholbach: re ssp, what's up?
<janimo> as xfce is only going towards RC and release I think it is reaosnable to have post UVF  uploads
<heno> janimo: right
<janimo> pitti: do you know if ivoks or anyone else had a look at the RH printing tool?
<pitti> janimo: ivoks had, but it's difficult to adopt, since it uses a lot of RH-specific libs
<dholbach> pitti: sealne had a problem with it on #ubuntu-motu (afflib, something he wants to package)
<heno> janimo: I see new themes appearing too. Have you seen any high contrast ones?
<janimo> pitti: so gnome-cups-manager is staying?
<pitti> janimo: ivoks is currently working on a replacement
<janimo> heno: no but I was going to ask you this as well. If there are good high contrast themes I'll add them to xubuntu-desktop
<pitti> janimo: but g-c-m will remain the default until we have a suitable replacement
<janimo> pitti: is it targetted for edgy?
<pitti> janimo: might not make it
<janimo> pitti: I'll need to talk to ivoks to keep in mind gtk only stuff
<heno> janimo: the art team has started on updating the high viz icon set. I'm sure that can be used in xfce as well
<janimo> heno, yes, anyting that is a gtk-theme can be  used, so anything from gnome
<janimo> bbl
* StevenK wishes g-c-m wouldn't suck so much CPU.
<StevenK> Or gnome-cups-icon, anyway.
<monomaniacpat> does ubuntu support 1360x768? I have it specified in my xorg.conf
<Riddell> dholbach: sure
<seb128> I've just uploaded a new control-center which builds a gnome-control-center-dev, it's required by the new gnome-session to build so if somebody could accept and promote it later that would be nice :)
<seb128> anyway, lunch time for now, bbl
<heno> seb128: I was just looking at the code for that. I'd like to discuss some possible changes to the accessibility config window in the next few days. I'll send you an email with an overview
<Kamion> [ Uploading job debian-installer_20060711ubuntu1_source
<Kamion> woo
<StevenK> I bet that's a fun merge.
<ogra> fear my changelog ....
* ogra laughs evlish
<Kamion> StevenK: oh yes
* StevenK pokes merges.u.c
<fabbione> Kamion: SCORE!!!!!!!
<fabbione> new installer
* fabbione kneels down in front of the d-i all mighty
<Kamion> fabbione: save the kneeling for if it builds first time
<fabbione> Kamion: i am sure it will everywhere != sparc :P
<StevenK> So we should know by this time tomorrow.
<Kamion> I've only tested on powerpc
<Kamion> sigh, gcc-4.1 FTBFS on powerpc
<elmo> LP is going down in 13 minutes, ETD is 10 mins
<fabbione> Kamion: gcc on ppc needs bootstrapping
<elmo> LP's back
<sladen> pitti: I think there was a slightly different patch that debian may have taken for 'linda' that achieves the same aim as the current Ubuntu patch (teaching it about our langpack locations)
<StevenK> Yes.
<StevenK> sladen: I didn't agree with your patch, and I had already been bugged about localepurge killing Linda's ability to speak.
<rodarvus> wow, #ubuntu-devel had gigantic talk this evening
<rodarvus> it seems fabbione is feeling better today, given the amount of times he talked :P
<dholbach> grmbl help-ubuntu wiki two wikis fullsearch() does not work grmbl
<sladen> StevenK: did the other patch that somebody else sent to you (make linda just use gettext rather than trying to do its own thing) make it anywhere?
<sladen> StevenK: since that one avoids the need to patch in the extra patch as the lower-level C libraries are already twiddled for Debian
<StevenK> Oh, the mygettext thing.
<sladen> s/Debian$/Ubuntu$/
<StevenK> I was waiting for Debian to hit Python 2.4
<StevenK> Since I moved .mo files, I don't think the twiddle in mygettext is needed.
<elmo> *.ubuntu.com, launchpad.net etc. are disappearing for a couple of minutes for some essential maintenance
<pitti> sladen: I saw the sync; thanks
<fabbione> rodarvus: ahaha
<doko> slomo_: Debian's 4.1.1-8 didn't show the failure with -fstack-protector, so maybe a problem fixed already upstream; but libgcc now is built with -fno-stack-protector by default
<slomo_> doko: ok... i could do some tests with a ssp enabled libgcc in the next week to see if we could enable it again
<zul> hey
* netjoined: irc.freenode.net -> brown.freenode.net
<Riddell> Kamion: could you move libqt4-debug to main?
<janimo> how can I find out what's keeping a package in 'needs building' ?
<janimo> ex: https://launchpad.net/distros/ubuntu/+source/thunar-archive-plugin/0.2.0-0ubuntu2
<pitti> janimo: it just says what it says, the buildds need to catch up
<pitti> janimo: oops, https://launchpad.net/+builds looks like if there's a problem
<janimo> pitti:  I uploaded last night, I thought it got stuck on something else
<pitti> Keybuk: https://launchpad.net/+builds looks bad
<gnomefreak> what product would the man page mount.smbfs be? im thinking samba?
<pitti> gnomefreak: smbfs package AFAIK
<gnomefreak> i tried that
<gnomefreak> it wouldnt accept it
<pitti> oh, product - well, that would be samba
<gnomefreak> i was afraid of that ty
<Keybuk> pitti: I think elmo rebooted all of the data centre last night
<Keybuk> or even is doing so today
<janimo> what's the best place to check what changed between various debian policy versions? i.e from 3.6 to 3.7
<janimo> the policy manual does not seem to have a history or changelog
<Keybuk> janimo: changelog.gz and upgrading-checklist.txt.gz in the debian-policy package
<janimo> Keybuk: ok. I looked at the changelog but missed the other, thanks
<Mithrandir> Keybuk: can you give-back totem on amd64, please?
<Keybuk> Mithrandir: also given back on sparc and ia64
<Mithrandir> Keybuk: cheers
<Kamion> Riddell: done
<Riddell> thanks
* ogra wonders if anastacia is confused ... it wants to demote ltsp-manager to univers ... that has never been in main
<Keybuk> ltsp-manager |    0.0.1-1 |          edgy | source
<Keybuk> the source is in main
<Kamion> ltsp-manager |    0.0.1-1 |          edgy | source
<Kamion> ltsp-manager |    0.0.1-1 | edgy/universe | all
<Kamion> oh Keybuk already said that
<Kamion> ogra: anastacia doesn't get confused in that kind of way
<ogra> thats intresting ...
<Kamion> BTW see https://launchpad.net/distros/ubuntu/+source/ltsp-manager, "Component: main"
<ogra> how did that end up there ... i never promoted it 
<Kamion> the person NEWing it probably just thought "oh it's ogra, he's going to want it in main eventually anyway"
<Kamion> it should be demoted for now
<ogra> yep
<sivang> anyone knows who  Michael T. Richter  is ?
<ogra> its not ready and the spec wasnt finished or approved since its a pet project of mine 
<ogra> so it may slowly move to main over time with added features :)
<Hobbsee> sivang: https://launchpad.net/people/ttmrichter
<Keybuk> Kamion: it was me, I think
<Keybuk> and I'm reasonably sure ogra _asked_ me to NEW it into main at the time
<Kamion> heh
<ogra> Keybuk, dont worry, it will end up in main at some point ... but since the spec wasnt handled at all univers is the right place for now ...
<ogra> hmm, i cant remember asking explicitly for main 
<sivang> Hobbsee: interesting, he's even an Ubuntu member so LP says
<ogra> especially since i fear the wrath of pitti :)
<pitti> ogra: hm?
<Hobbsee> sivang: very
<ogra> pitti, for movig stuff to main past your back ;)
<pitti> ogra: oh, ltsp-manager ;) (well, that doesn't sound particularly fearsome)
<pitti> oh, well, that :)
<ogra> it isnt ...
<ogra> only a gui to existing scripts that are in main already
<pitti> but it should have a certain level of quality for main
<ogra> yep
<rodarvus> ltsp-manager has a rootkit - or so ogra told me in private :D
<Kamion> iwj: you should be able to do that gsfonts-x11 merge RSN
<ogra> and its still in development ...
<rodarvus> oh, I was not supposed to say this in public :P
<ogra> rodarvus, shhh
<ogra> damn ...
* ogra moves the rootkit directly into ltsp ... so nobody sees it
<Keybuk> rodarvus: bit of luck nobody uses edubuntu anyway
<ivoks> :)
<ogra> Keybuk, hey, we're place 58 (or so) on distrowatch !
<zul> heh...ogra owns you
<rodarvus> world domination is coming!
<sivang> Keybuk: if you have 5 minutes and have something I can bribe you with, I'd really really appriciate it if you went over SysteCleanUpTool and see if you have any more commments, or otherwise promote it to pending approval :-)
<ogra> yay
<ogra> Keybuk, and dont forget X is in edubuntu hands now :P
<Keybuk> ogra: which puts you below "Pentoo", "SLAX", "Puppy", "GeeXboX", "VideoLinux", etc.
<ogra> as all the important projects (like ltsp and tuxmath)
<Keybuk> though, amusingly, above Novell ... so rock on
<tseng> I know some novell employees who would start frothing at the mouth if you mentioned that
<tseng> and start pointing at reviews claiming their upcoming release is "even better than ubuntu"
<Keybuk> tseng: and in various areas, they're probably right
<sivang> Hobbsee: you know him ?
<tseng> Keybuk: there are alot of good things to be sure
<Keybuk> they've spent a huge amount of money on software development for NLD
<tseng> usability testing
<zul> tseng: so ubuntu is the touchstone for novell now? pretty sweet ;)
<Keybuk> and I don't think that's a bad thing
<tseng> while we pave new usability frontiers by breaking gnome in interesting ways
<tseng> and Launchpad
<Keybuk> heh
<ivoks> i find it funny that someone spends lots of many and then came up with "start button", something others allready discovered before then :)
<ivoks> them
<Keybuk> it's something I've talked to jdub about a lot -- the fact that we don't _want_ to seriously dent Novell or RHEL's market yet ... because we don't spend any money on software development, and they spend HUGE amounts
<janimo> Kamion, with the seeds kept in bazaar.lp.net what's their relation to the seeds in ~cjwatson? And is there still a need to mirror my local xubuntu seeds there? I see the cronjob is getting every 15 minutes still
<tseng> ivoks: its quite a bit more elegant than "a start button"
<iwj> Kamion: Aha.  RSN != now ?  I have it sitting around here I think.  Err, unless I cleaned it up.  Anyway, it was easy.
<Keybuk> if we made them disinterested in their Linux distros, we'd lose a lot of our upstreams (like gcc, glibc, most of GNOME, etc.)
<mjg59> Keybuk: Right. In a lot of ways, we're as dependent on Novell and RH as we are on Debian
<Kamion> janimo: ~cjwatson is a pulled copy of bazaar.lp.net now, for convenience
<ivoks> tseng: at least something :)
<tseng> Keybuk: totally.
<Kamion> janimo: a need to mirror your local xubuntu seeds where?
<mjg59> Keybuk: Interestingly, this is something that Sun claim as well
<tseng> ivoks: its in the same spot and it launches programs is about the only similarity
<ogra> lol
<Keybuk> mjg59: in which sense?
<sivang> mjg59: they do have some code in GNOME no ?
<janimo> Kamion: you had a script which still seems to be running to mirror my local xubuntu seeds on people.u.com (since I did not commit there)
<mjg59> That is, their aim is to ensure a thriving market that they can happily live in rather than to utterly dominate it
<ivoks> tseng: and what else should it do? :)
* sivang notices at least a dozen files with people from Sun copyrighted
<ogra> pitti, wwwconfig-common is listed fro main inclusion ? 
<tseng> ivoks: try it.
<mjg59> (At least, this is what certain people in Sun claim)
<pitti> ogra: no, I fixed backuppc
<Kamion> janimo: it's pulling from bazaar.lp.net, like the others
<pitti> ogra: anastacia is just lagging behind
<tseng> ivoks: it borrows from ideas from Gimmie
<ogra> pitti, ah, cool :)
<Kamion> janimo: it's just for convenience - you can ignore it if you like
<Keybuk> mjg59: *nods*  I think that's the right thing for Ubuntu -- be the lead of the community distros, and let RHEL and NLD take the corporates ... but certain people would disagree, I'm sure
<Kamion> (since bazaar.lp.net doesn't give a web-viewable working copy)
<tseng> ivoks: and ties in beagle
<mjg59> Ubuntu has done wonders in bringing Linux to people who'd never consider RHEL or SLED
<ivoks> tseng: i don't see how beagle is good, but that could be only me :)
<tseng> ...
<tseng> ivoks: go sit in the corner :)
<mjg59> There's absolutely no requirement for us to try to bring Linux to people who are already using Linux
<janimo> Kamion: but can I remove my branch on the local server which is mirrored to rookery every 15 minutes? since seeds are on LP now
<ivoks> mjg59: yet
<mjg59> ivoks: Ever
<Kamion> janimo: that was only for dapper - I've just changed the branch there to pull from bazaar.launchpad.net rather than from startx.ro
<tseng> ivoks: ever?
<jjesse> mjg59:  there is a group in the documentation team that is trying to help out with a switching from windows to *ubuntu guide
<pitti> funny, http://security.ubuntu.com/ubuntu has a star trek favicon now :)
<Kamion> janimo: so yes, you can remove it now
<janimo> Kamion: ok, thanks
<mjg59> jjesse: That sounds absolutely excellent
<ivoks> mjg59: oh, i have misread you :)
<tseng> so I worked with a guy at work about building an ubuntu server in another data center
<tseng> as a result he installed kubuntu at home and loves it
<jdub> mjg59, Keybuk: grmmmphrrm
<tseng> and is totally excited about putting xubuntu on old hardware
<tseng> and it being useful.
<mjg59> jdub: I'm a pretty firm believer that it's better to get free software to as many people as possible, rather than worry about whice specific free software they're going to use
<mjg59> Obviously I have preferences about which free software they should be using, but...
<zul> we are converting our servers at work from redhat to ubuntu 
<tseng> zul: thats taking me forever
<Kamion> iwj: when xfonts-utils is up. Mithrandir seemed to think it would just be a sync; were there other local changes?
<zul> tseng we only have like 10 servers though
<ivoks> i allready did that :)
<tseng> yeah, lucky you
<ivoks> + i have left the company that didn't want to do that :)
<janimo> ivoks: hey, I heard you're working on a printer config tool? is it pygtk based?
<ivoks> janimo: yes, pygtk, but atm i'm occupied with my exams, so i'll continue the work trough summer
<iwj> Kamion: I don't remember.  I'll look at it tomorrow; I've got a head full of dpkg dependency tangle today.
<jdub> mjg59: you'll be pleased with me - there is now a PlasticAnalFlamingDeath page on the gnome wiki
<janimo> ivoks: I am interested in such a tool for xubuntu, so just wanted to make sure you try using no gnome libs :)
<Kamion> iwj: UVF is *start* of Thursday I believe, so perhaps we can go with Mithrandir's opinion that it can be synced.
<dholbach> jdub: i can only find http://live.gnome.org/GiveMeUtf8OrGiveMeDeath on the wiki :-p
<pitti> Keybuk: can you please sync jabber.py_0.5.0-1.3.dsc from Debian incoming to clean up some anastacia mess?
<ivoks> janimo: no gnome libs... plain simple pygtk
<iwj> *start* of Thursday> Oh, bugger.
<janimo> ivoks: and gtk2.10 printing stuff instead of libgnomeprint?
<iwj> I'll go and read it now.
<Keybuk> pitti: in the middle of a daily sync atm
<Mithrandir> iwj: gsfonts-x11 is syncable so unless you have something apart from the merge bits of it, I'll ask for a sync.
<pitti> Keybuk: want a bug report instead?
<Keybuk> pitti: please
<ivoks> janimo: i just want the tool that will add/remove/config printers, nothing else
<Riddell> tseng: cool stuff
<iwj> Mithrandir: There's one change that gets dropped if you just sync.  http://merges.ubuntu.com/g/gsfonts-x11/gsfonts-x11_0.17ubuntu4.patch search for remove_old_fontpath, the change to the value of XF86CONFIG.
<Mithrandir> iwj: hm, indeed.  Is that filed in the Debian BTS?
<Mithrandir> iwj: also, AIEE at changing xorg.conf/XF86Config with grep.
<sivang> ivoks: you said you wanted to talk about backup stuff? 
<iwj> I don't think it's reported in the BTS.  But it wasn't clear to me whether we want to keep it since it's probably messing about with things that were only relevant in old config files.
<ivoks> sivang: hm...? could you remind me?
<Mithrandir> iwj: I think so, and so dropping that change should be fine.  IMO, at least.
<iwj> Yes, and editing it is a bit grim.
<sivang> ivoks: no idea, you just wante to talk about it , and I had to go :-/ I guess youve forgotten
<Mithrandir> iwj: ok, so you're fine with me asking for a sync, then?
<iwj> Right.  I thought it wasn't needed but I wasn't sure so my upload was going to keep the change but if you also agree it should be dropped then we should sync it.
<iwj> Yes.
<ivoks> sivang: heh, i really don't remeber :/
<Mithrandir> iwj: great, sync requested, thanks.
<pygi> sivang, ^_^
<iwj> Mithrandir, Kamion: Thanks.
<mjg59> jdub: Shame I'm not allowed to read it
<jdub> mjg59: sorry.
* iwj goes back to fixbyrm->clientdata->istobe et al.
<Kamion> swap you for gparted
<iwj> Kamion: No way :-).
<Kamion> hate hate hate random whitespace changes *all the time*
<Kamion> it would be ok if the result were something sane rather than a different horrible mish-mash each time round
<maswan> pitti: http://security.ubuntu.com/conspiracy/ ;)
<pitti> maswan: :) I saw the redirection to your mirror, I just found it funny
<Lathiat> haha
<Hobbsee> hehe
<ivoks> it would be nice to see python-lcms
<maswan> pitti: security updates is almost as taxing as releases, we've been bumping into our 2Gbit/s networking limit several times, http://www.acc.umu.se/technical/statistics/ftp/monitordata/
<jdub> maswan: ooh.
<jdub> hooray for the swedish conspiracy infecting ubuntu as well :-)
<maswan> :)
<jsgotangco> hahaha
<Lathiat> maswan: they ubuntu security updates?
<maswan> Lathiat: We're hosting security.u.c a while, that's where all the bandwidth use comes from
<Lathiat> ah right, you dont usually host it?
<maswan> Nope
<Lathiat> ah right
<Lathiat> damn thats a lot of traffic
<Lathiat> perhaps from the kernel update?
<maswan> Normally we just host the se.* stuff, but we step in and help out with a few other DNS names now and then.
<Lathiat> theyd be quite large
<maswan> ooffice is no light-weight either
<Lathiat> when did that come out?
* Lathiat can't see a USN for OOo
<maswan> USN-313-1
<maswan> Date: Wed, 12 Jul 2006 15:09:24 +0200
<Lathiat> oh id gone past it
<Lathiat> heh
<Lathiat> righto
<doko> Kamion, Mithrandir: can anybody else than infinity hand-build a package on a buildd?
<Mithrandir> doko: ttbomk, no.
<janimo> TheMuso: hi
<ogra> janimo, have you seen the changes to the edubuntu-xfce spec ? 
<fabbione> doko: probably cprov can.
<janimo> TheMuso: do you know if orca is planned for edgy (it's in universe now)
<janimo> ogra: I am subscribed to it
<ogra> oki
<janimo> ogra: but do not remember details, are you thinking about anything in particular ?
<ogra> janimo, it will cause some extra work on your side the way it was finalized
<Keybuk> Kamion: what's the netdev group on Debian for?
<janimo> ogra: it's not yet decided how to make metapackages and seeds right?
<ogra> janimo, its approved
<janimo> ogra: ok, I'll take a look now
<ogra> take your time ... i just wanted to notify you
<ogra> (we wont be able to jump on it right away anyway)
<janimo> ogra I would have preferred gnome-desktop-core + edubuntu-packages instead of splitting xubuntu-desktop but should have commented earlier :)
<janimo> as there is an xfce metapcakge already which could be a drop-in for gnome-desktop metapackage
<ogra> janimo, its based on mdz's suggestions as it is now
<janimo> so are you planning abiword/gnumeric as well or other apps besdies xfce core?
<ogra> we'll have a common base and either of us has a toplevel package
<janimo> I thought OOo was a requirement for certification exams so should stay in edubuntu
<ogra> which gets you into the situation that you have to maintain two seeds indeed ...
<ogra> yep
<seb128> Keybuk: any idea of why the control-center gnome-applets gnome-session uploads made some hours ago are not published? 
<ogra> thats what we'll solve in the toplevel package in edubuntu
<janimo> so you only need xfce desktop no other additional apps?
<ogra> yep
<ogra> we'll ship thunar only idf there is space on the CD for example 
<janimo> and adjusting the existing xfce metapackage (it's close already) and getting that on the edubntu CD without doing anything with seeds is not possible?
<Keybuk> seb128: probably stranded or lost
<janimo> and split edubuntu-desktop in gnome desktop +edubuntu specific
<ogra> we'll need a topleven package that adds the missing bits ... but the xfce package should be our common base
<ogra> *toplevel
<janimo> right
<ogra> edubuntu-desktop will stay as is
<Keybuk> seb128: will investigate in a minute
<ogra> we'll add a edubuntu-xfce-desktop package that depends on xfce-desktop and adds the missing pieces
<seb128> Keybuk: thank you
<janimo> so you can just have a new edubuntu-xfce-desktop which is xfce4 plus missing pieces (which overlap edubuntu desktop a lot)
<ogra> yep
<janimo> but in this case nothing xubuntu needs to change as I see it
<janimo> you just use the existing xfce metapckage and build a new edubntu around it
<ogra> if the xfce package has the suffuicient bits no...
<ogra> anyway, its up to rodarvus to implement it :)
<janimo> cool, as xfce4 is not used by xubuntu (it's the old debian xfce all-in-one desktop) and we specify every dep explicitely in xubuntu-desktop I think we're fine
<ogra> janimo, then ewe cant use it
<ogra> janimo, what we want is the base of xubuntu
<ogra> i thought you use the xfce4 package
<janimo> but the base of xubuntu is xfce core (which is in xfce4) + non-xfce apps which you said you wont use
<Kamion> doko: lamont mind be able to
<Kamion> s/mind/might/
<janimo> ogra, more or less overlap but don;t use it directly, it's in universe
<janimo> but yes we can make a common core to make sure we do not diverge or have other surprises
<ogra> janimo, yeah
<janimo> I just wanted to be sure  I don't need to split or add extra stuff to xubuntufor this, as a metapackage would do
<Kamion> Keybuk: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=352713
<Ubugtu> Debian bug 352713 in base-passwd "Subject: base-passwd: Please add netdev and powerdev groups" [Wishlist,Closed]  
<ogra> and to make sure that we dont duplicate meta packages .i.e pulling xfce4 to main would be silly
<gnomefreak> tomorrow it he last day for accepting new versions of programs right?
<gnomefreak> s/he/the
<Kamion> Keybuk: I was planning to ignore that user-setup change for edgy unless told otherwise
<janimo> ogra so now xubuntu-desktop directly depends on each xfce component and non-xfce app. xfce4 metapackage depends on xfce components and is in universe
<janimo> any xfce meta package that brings xfce core components to edubuntu is fine with me
<janimo> and does not need xubuntu seed changes
<ogra> janimo, the point of the spec is that you maintain the corfe package and we maintain the add-on package
<ogra> *core
<janimo> I am happy to help with any other xfce issue though :) if some gnome-like bits are missing or anything that need coding
<ogra> since xfce is your domain
<janimo> ogra, ok sure I maintain that, only not via seeds. Ok?
<janimo> so I keep an uptodate metapackage of xfce core
<gnomefreak> atm xubuntu-desktop depends on a gnome app that isnt around yet
<ogra> no, i think mdz will object if you dont do it via seeds
<doko> lamont: ping ^^^
<Keybuk> Kamion: yeah, I just encoutered netdev via dhcdbd
<janimo> hmm, will have to see why then. Is it needed for the CD boot menu?
<Keybuk> Kamion: we can always add them later if we want
<gnomefreak> nvm looks like it was fixed
<ogra> janimo, but lets wait until rodarvus and mdz are around ... i'm not the guy who will implement that spec 
<ogra> (i'll likely maintain the seeds on the edubuntu side, but thats all=
<ogra> )
<Keybuk> seb128: dude, you'll have to be more specific
<Keybuk> WHICH builds are missing?
<Keybuk> or are sources missing?
<seb128> Keybuk: not builds, but new versions listed
<seb128> Accepted gnome-session 2.15.4-0ubuntu1 (source)
<seb128> Accepted gnome-applets 2.15.1.1-0ubuntu1 (source)
<seb128> Accepted control-center 1:2.15.4-0ubuntu1 (source)
<seb128> https://launchpad.net/distros/ubuntu/edgy/+source/gnome-applets by example list 
<seb128> 2.14.1-0ubuntu3
<Keybuk> seb128: they're not missing?
<seb128> not 2.15.1.1-0ubuntu1
<seb128> hum
<Keybuk> see, this is why you need to be more specific <g>
<seb128> k
<seb128> the example I just gave is clear? :)
<seb128> https://launchpad.net/distros/ubuntu/edgy/+source/gnome-applets claims "Current version:  2.14.1-0ubuntu3"
<Keybuk> 2.15.1.1-0ubuntu1 has not yet been published, likewise the others
<zul> Keybuk: cam you see if vmware-player i did for security actually went to security yesterday?
<Keybuk> zul: no, ask pitti
<seb128> Keybuk: ok, any idea of why? ;)
<zul> pitti: ping
<pitti> hi zul 
<Keybuk> seb128: what time did you upload them?
<seb128> Keybuk: around 3-4 hours ago
<zul> hi pitti can you check vmware-player for me?
<pitti> zul: I released it some time ago, but security updates seem to have trouble trickling trough the mirrors
<zul> ah ok...thanks
<pitti> zul: I'll wait after next cron.daily and check again
<ogra> zul, dont forget about the modules package :)
<Keybuk> -rw-r--r--  1 lp_upload lp_upload 2402 Jul 12 11:25 ../ubuntu-queue/accepted/upload-20060712-113230-000626/control-center_2.15.4-0ubuntu1.dsc
<Keybuk> that's the one?
<zul> ogra: it is the modules package :)
<seb128> yep
<seb128> one of them
<ogra> zul, heh, ok :)
<seb128> gnome-session and gnome-applets around the same time too
<seb128> I uploaded them before lunch
<Keybuk>    70490 | S- | control-center       | 1:2.15.4-0ubuntu1    | 3 hours 50 minutes
<Keybuk>          | * control-center/1:2.15.4-0ubuntu1 Component: main Section: x11
<Keybuk> it's in accepted
<ogra> the buildds are slacking :P
<seb128> so that's just the launchpad UI lagging?
<Keybuk>    70498 | S- | gnome-applets        | 2.15.1.1-0ubuntu1    | 3 hours 40 minutes
<Keybuk>          | * gnome-applets/2.15.1.1-0ubuntu1 Component: main Section: gnome
<seb128> good too
<Keybuk>    70500 | S- | gnome-session        | 2.15.4-0ubuntu1      | 3 hours 30 minutes
<Keybuk>          | * gnome-session/2.15.4-0ubuntu1 Component: main Section: gnome
<Keybuk> those three?
<seb128> yep
<Keybuk> publisher is dead
<ogra> there were many reboots in the DC today ...
<Keybuk> yeah
<seb128> Keybuk: which would explain why they have not been published :p
<Keybuk> LP never comes back from a reboot
* Keybuk gets the gloves and lubricant out
<sivang> oh dear...
<sivang> that sounds nasty
<seb128> I'm sure you can get it back to life, thank you :)
<sivang> :)
* ogra goes mowing the lawn ... 
<seb128> ;)
<ogra> i cant bear seeing Keybuk doing that
* sivang turns away his sight
<Petaris> Is there a doc that will tell me how to compile glibc-2.3.4 for ubuntu?
* Lathiat wonders why you would want to do that
<Petaris> I have searched the wiki at www.ubuntu.com but found nothing
<Petaris> Lathiat: I need glibc-2.3.4 to satisfy a pesky app, I want to compile and install it in /opt/lib
<Keybuk> why won't the app work with 2.3.6 ?
<Petaris> so the system can use 2.3.6 but I can LD_PRELOAD that app with 2.3.4
<Keybuk> Petaris: you'd be better off reading the glibc docs
<Petaris> Keybuk: I don't know, tech support didn't elaborate
<Keybuk> it's pretty much ./configure --prefix=/opt/lib && make && sudo make install
<Keybuk> with a couple of days of waiting in the middle
<Petaris> Keybuk: Yeah, I have been, but I didn't know if there was anything speacial that had to be done for ubuntu
<Keybuk> Petaris: only if you want an Ubuntu glibc package ... which clearly you don't
<Petaris> oh, ok
<Petaris> also it complains that I am trying to build in the source directory
<Keybuk> then don't build in the source directory -- see the glibc docs
<Petaris> seems to want to be built in a seperate build directory but I'm not sure how I should move the object files
<Petaris> is it as simple as just coping them?
<Keybuk> mkdir build && cd build && ../configure --prefix=/opt/lib && make && sudo make install
<Keybuk> quite frankly though, if you don't know how to do this, you really shouldn't be doing it ;)
<Keybuk> seb128: right, so that's the buildd slave and queue resurrected
<sivang> be back later
<Petaris> Keybuk: Last time I built glibc I was using Gentoo, and I've never had anything complain about being built in a source dir before
<Keybuk> that's a glibc thing, I'm sure
<Petaris> oh
* seb128 hugs Keybuk
<seb128> Keybuk: thank you ;)
<Keybuk> seb128: still got to resurrect the publisher yet :-/
<pitti> Keybuk: that sounds like my security updates could eventually appear, too
<Keybuk> 14:39:14 INFO    After paring out any builds for which we lack source, 2443 NEEDSBUILD
<Keybuk> right
<cpercy> Is jeff bailey here ?
<iwj> Well, I haven't changed a line of code yet and I've already found three bugs so far ...
<Keybuk> iwj: dpkg?
<iwj> Yes.
<Amaranth> ...
<iwj> Admittedly I think two of these bugs are from the same patch.
<iwj> But I'm not doing archaeology now to find out.
<iwj> Oh, they're generally too complicated and obscure to bother explaining.
<iwj> The best one is that if A conflicts with B and you say dpkg --install A.deb B.deb with neither installed it works.
* Keybuk writes a quick RpmPackageManager spec
<Kamion> Keybuk,iwj: which reminds me, did I point you guys to http://kitenet.net/~joey/blog/entry/rpm_hell.html ?
<Keybuk> yeah you've mentioned that before
<Kamion> "RPM uses a "best effort" algorithm when doing upgrades. What actually happened here is that the previous versions were removed as part of the upgrade process, and the newer versions were installed. At least as much as possible. :-) As many files as could be removed from the old install were, and that install was removed from the RPM DB. As much of the new stuff as could be installed was, but the install of some items f
<thom> yeah, that bug is really special
<Keybuk> RPM famously doesn't bother to check the return value of syscalls
<msw> oh that
<msw> Keybuk: at least most of the exit() calls in librpm are gone now
<msw> (yes, but not all)
<Keybuk> their reasoning was that RPM implements a "verify" function, which is more reliable
<msw> wow, that bug is _still_ getting comments?
<Evaso2> Keybuk: hi, i have talked with tony the n-m pptp plugin developer
<fabbione> doko: ping?
<Evaso2> Keybuk: the problem is The default installation of pppd on most
<Evaso2> distros however, provides an ip-up script which is called by pppd directly
<Evaso2> when an IP connection is established
<Keybuk> right, making n-m's VPN plugins work properly involves breaking our default installation
<Keybuk> n-m works at the cost of "no n-m" working
<Evaso2> keybuk: i see that the /etc/ppp/ip-up/ip-up.d/000-usepeerdns use an env variable [ "$USEPEERDNS" ]  || exit 0
* Hobbsee wonders who did wpa_supplicant.
<Evaso2> Keybuk: we can workaround nm-plugin controlling this env variable so ip-up doesn't modify resolv.conf
<Keybuk> Hobbsee: we just sync'd that, why?
<fabbione> sfllaw: ping?
<Keybuk> Evaso2: feel free, if you can get a working NM VPN setup which doesn't break the system working without NM, we'll gladly accept the patches
<Keybuk> fabbione: sick today
<fabbione> oh right
<Hobbsee> Keybuk: i havent checked the debian version, but the wpa_supplicant parameter for ndiswrapper changed to be wext, instead of ndiswrapper. 
<Hobbsee> i'm assuming debian version picked it up
<Evaso2> Keybuk: ok i talk with the upstream author if it would integrate this feature so all ip-up distro could work around this resolv.conf issue
<Hobbsee> because i cant seem to force my ndiswrapper card to use the wpa encryption via knetworkmanager in dapper, and we probably dont want to have that problem in edgy too.
<Hobbsee> bleh.  my brain died.  feel free to ignore that.
<fabbione> Hobbsee: do you feel like doing 2 merges in main? i will sponsor them
<Hobbsee> fabbione: which ones?
<fabbione> Hobbsee: wvdial and wvstreams please.
<fabbione> Hobbsee: sfllaw is sick so if somebody can take care of those it would be lovely
* Hobbsee will look at them.  no more commitment than that at the moment.
<fabbione> Hobbsee: ok i recall the changes to wmdial to pretty simple. dunno about wvstreams
<Kamion> er, I thought I synced xfonts-utils - what happened to it?
<Kamion> oh, no, Mithrandir uploaded it
<Kamion> Mithrandir: still here?
<siretart> Hobbsee: all wifi drivers should be forced to work with wext
<Hobbsee> siretart: right...
<Kamion> Mithrandir: you forgot to use -sa
<Kamion> oh, he's gone - I'll fudge together the upload
<fabbione> Kamion: can you get the diff.gz and dsc out of the queue?
<fabbione> yeah exactly
<Kamion> yup
<doko> fabbione: pong
<Hobbsee> fabbione: in all honesty, i dont think my brain will get around those merges well enough tonight.  it's about 1.30am at the moment
<Hobbsee> fabbione: if i merged it now, i'd be guessing, without a clue of what i was doing - and i dont think that's what you want
<fabbione> Hobbsee: ok thanks. Fair enough
<Hobbsee> fabbione: usually, i'd say yes.  or give it a shot at least.  but i think tonight, my brain's a bit far gone :P
<fabbione> Hobbsee: no problem
<pitti> fabbione: I can look at wvdial, I think I roughly know what we changed
<Hobbsee> pitti: probably a good idea - i dont see anyone else volunteering for it
* pitti grabs wvdial then
<fabbione> pitti: ok
* Hobbsee looks at wvstreams
<Hobbsee> ah ha - this one looks doable (i think)
<fabbione> pitti: you can also drop the sparc bit
<Keybuk> pitti: you still have mesa on your list, no?
<fabbione> pitti: it was wrong
<fabbione> Keybuk: mesa -> Robot101 
<pitti> Keybuk: yes, but no clue about it
<fabbione> hem
<fabbione> Keybuk: mesa -> rodarvus 
<Keybuk> ok
<Kamion> WTF
* Robot101 runs away :D
<fabbione> Keybuk: he is already looking at it
<Kamion> STUPID XSF BUILD SYSTEM
<Keybuk> Kamion: ?
<Kamion>         rm -f debian/*.config \
<Kamion>               debian/*.postinst \
<Kamion> ...
<fabbione> Kamion: you need to call it postinst.in and add a call to genscripts in debian/rules
<pitti> fabbione: wvdial? sparc? hmm?
<fabbione> note that the postinst needs some special stuff in it
<fabbione> Kamion: let me find a snippet for you
<Hobbsee> fabbione: tackling wvstreams
<fabbione> Hobbsee: good :)
<Kamion> fabbione: an example package would be fine
<fabbione> Kamion: xorg-server has one very simple postinst.in and one call to genscript
<fabbione> Kamion: i was digging it from there
<Kamion> thanks
<fabbione> Kamion: all the keywords at the beginning are mandatory
<Mithrandir> Kamion: bah, sorry.  Also, thanks.
<Hobbsee> fabbione: yep, i can do this one.  MoM's weirded out again - saying that a section of debian/rules that look the same to me are, in fact, different.  besides that, in both versoins, they're commented out.  heh.
<thom> Robot101: that's some pretty unfortunate delegation right there
<fabbione> Hobbsee: perfect.. let me know when you are done and i will upload for you
* Hobbsee considers throwing it at the builds without testing...no...no...i cant do that...
<Hobbsee> fabbione: got a quick place to build it, by any chance?  my machines already building kopete...
<fabbione> Hobbsee: yeah send the source here
<fabbione> Hobbsee: can you upload to main?
<fabbione> f not just send it here
* Hobbsee raises an eyebrow at fabbione 
<Hobbsee> fabbione: i'm going for MOTU at the next meeting, actually
<zul> Hobbsee: yay!
<Kamion> fabbione: only if you're using shell-lib ;)
<fabbione> Hobbsee: cool
<Hobbsee> fabbione: assuming i wake up.
<fabbione> Kamion: yes, but it's a good idea to keep it consistent.. really...
<Robot101> thom: :)
<Hobbsee> fabbione: grabbing a debdiff for you now 
<fabbione> Hobbsee: thanks
<Kamion> I guess
<Kamion> seems like massive overkill for this postinst, but ok
<Hobbsee> fabbione: brain freeze - debdiff would be the new version versus the old ubuntu version?  or the current debian?
<fabbione> Hobbsee: debdiff oldversion newversion
<fabbione> | mail -s'debdiff' fabbione@ubuntu.com
<fabbione> Hobbsee: one of the good things about unix.. it's always $command $from $to
<fabbione> or at least should be...
<Hobbsee> fabbione: i'm more asking which the "oldversion" would be - the old ubuntu, or the old debian?
<Hobbsee> i'm assuming the old ubuntu
<fabbione> old ubuntu
<pitti> fabbione: bah, merging was easy, but Debian's package doesn't build on current edgy (some obscure C++ error); I'm afraid we need to merge wvstreams first
<Mithrandir> Hobbsee: that depends on whether you want a reverse diff or not. :-P
<Hobbsee> Mithrandir: heh
* Hobbsee tickles Mithrandir before he can run away!
<fabbione> pitti: getting therre...
<pitti> maswan: ping
<maswan> pitti: pong
<pitti> maswan: http://archive.ubuntu.com/ubuntu/pool/main/s/shadow/ now has shadow_4.0.13-7ubuntu3.2.dsc, but security.u.c doesn't yet have it
<pitti> maswan: is that a problem on our or your end?
<Hobbsee> fabbione: sent
<fabbione> Hobbsee: got it thanks
<Hobbsee> fabbione: :)
<maswan> pitti: We sync hourly, apparenlty it wasn't there at :13 this hour. I can send off a new sync though, if you want.
* Hobbsee waves to pitti, but doesnt stomp on his feet today
<pitti> maswan: it's a fairly 'OMG the sky is falling' update, I just need it fairly quickly since i have to leave soon
<Keybuk> Hobbsee: usually they're different in whitespace
<Keybuk> I'd be using -w everywhere, if it wasn't for Python
<Hobbsee> Keybuk: yeah, good point
<maswan> pitti: Ok, working on getting it here ASAP.
<Keybuk> maswan: the archive system wasn't working 30 minutes ago <g>
<Keybuk> if you sync now, it will be there
<Hobbsee> Keybuk: who's on the tech board meeting this week, approving people?  you?
<Keybuk> Hobbsee: there is no tech-board meeting this week
<Hobbsee> Keybuk: s/this/next
<Hobbsee> i'm glad there isnt, otherwise i'd have to live in the past.
<Keybuk> Hobbsee: I'm not sure I understand the question
<maswan> Waiting for the rsync, donig a quickie so Packages* will be outdated until pool/ updates (normally we do the two-stage thingie)
<Keybuk> I actually won't be present for next week's TB meeting
<Hobbsee> Keybuk: right, that answers half of it.  the other half is "who will be?
<Keybuk> Hobbsee: I cannot answer for who will be
<Hobbsee> Keybuk: okay
<Keybuk> why?
* Hobbsee was curious, that's all
<Keybuk> the TB is mdz, mjg59, sabdfl and I
<Keybuk> sabdfl rarely turns up
<Hobbsee> true
* maswan mumbles about samba updating slightly before shadow and drums fingers impatiently
<Hobbsee> Keybuk: actually, i probably should tell you - applying for upload rights to universe, and was wondering who id' be up against
<imbrandon> BenC, ping 
<BenC> imbrandon: pong
<pitti> maswan: oh, cool, then I can release the other two USNs as well :)
<imbrandon> BenC, i got a quickie question about the linux-source-* packaging, specificly is there a reson it dosent show as an upgrade when a new one is avail , like when the kernel is updated ? ( this is a problem for those of us that use non included nic drivers like nvidia nforce )
<BenC> imbrandon: it's because you don't have the meta package installed, I would guess
<imbrandon> just wondering if there was a specific reason its not upgraded with dist-upgraed also i guess is my question )
<BenC> imbrandon: sudo apt-get install linux-686, or linux-386, or whatever flavour it is you use
<BenC> same reason
<imbrandon> ahh right i do that but also install linux-source-*
<BenC> the meta package is the only thing that will keep you up-to-date
<imbrandon> right but the kernel does update just not the source
<BenC> ah, ok, so there's no linux-meta package for the source
<BenC> hmm
<BenC> why do you need the source?
<imbrandon> right right
<BenC> why not use the linux-headers packages, which do have meta-packages?
<imbrandon> me specificly i have to recompile my nic drivers against it every update ( but vmware server and other things need it too )
<imbrandon> hrm
<BenC> the headers provide exactly that
<maswan> pitti: pool/main/s/shadow/shadow_4.0.13-7ubuntu3.2.dsc
<imbrandon> hrm yea , is there a meta for the headers so they get updated ?
<BenC> the source isn't meant for compiling modules
<maswan> pitti: can you verify everything got there properly?
<pitti> maswan: thanks a lot!
<Mithrandir> maswan: my apt seems happy at least.
<iwj> Four.
<BenC> linux-headers-$flavour
<fabbione> pitti: new wvstreams is up
<BenC> same as the linux-image metapackage
<imbrandon> ahh nice BenC , ok thanks sorry to bother you for something so trivial i'm sure you got lots of wrok to do ;)
<pitti> fabbione: yay; I looked at the debian diff, that was the reason for the build failure; however, I'll still test before I upload
<fabbione> pitti: ok
<elmo> does busybox not have job control or something?
<Kamion> ogra: mind if I take care of xfonts-terminus? I think it can be synced
<Kamion> elmo: depends on the config
<imbrandon> s/wrok/work
<BenC> imbrandon: no, but in the future, questions like this belong in #ubuntu, or if it's kernel specific, you can try #ubuntu-kernel
<BenC> s/no/np/
<ogra> Kamion, fine with me ... i still have a long night ahead with g-p-m
<imbrandon> sure thing
<imbrandon> ;)
<Keybuk> ok
<Keybuk> MoM output should be up to date again now
<maswan> Mithrandir: well, if you needed samba stuff from universe, it wouldn't be getting happy until about now
<Kamion> Keybuk: please unblacklist xfonts-scalable; you have it open
<Kamion> it => sync-blacklist
<Keybuk> Kamion: ok
<Petaris> Keybuk: Would it be detramental to downgrade binutils?
<Keybuk> Petaris: dude, you're so going to fuck your system :p
<Keybuk> is the rogue app *really* worth it? :p
<Petaris> Keybuk: Wouldn't be the first time
<Petaris> Keybuk: Orginiztions backup system
<Petaris> :/
<Keybuk> why not just run breezy instead?
<Petaris> Its also an ltsp server and was recomended that I run dapper
<Petaris> it seems that this version of binutils issues
<Petaris> http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/e0661bd5e211edf4/46305f3dd0c2266a%2346305f3dd0c2266a
<Petaris> But I don't know what about it is causing the issue
<Petaris> so I guess I can't say for sure that it is a binutils issue
<Keybuk> anyone doing speech-tools ?
<Keybuk> ok, done it myself (easy -- just a sync)
<Kamion> iwj: can I take ttf-freefont from you?
<Kamion> I believe it's a sync - the optional-priority business doesn't actually matter because that's overridden anyway
<Hobbsee> sigh.  horrid connection tonight, laptop isnt behaving.
<Kamion> and honestly, who cares whether a udeb is optional or extra
<Keybuk> Hobbsee: probably mdz and mjg59, though you'd have my blessing too
<Hobbsee> Keybuk: okay.  i'd have your blessing?
<Keybuk> Hobbsee: for ubuntu-dev
<Hobbsee> Keybuk: ah :)
<Hobbsee> Keybuk: wish you could have an impromtu meeting so i wouldnt have to wake up early for the proper one.
<Hobbsee> and be mostly incoheratnt
<bluefoxicy> If it's before noon, Hobbsee isn't really awake.  Typing, yes, but not awake.  :)
<Hobbsee> bluefoxicy: at 6am though?  
<Hobbsee> heh
<bluefoxicy> .... ouch.
<Hobbsee> very ouch
* bluefoxicy is barely awake and it's 12:03
<Keybuk> Hobbsee: you're in .au?  the problem there is when you're awake, the TB are all asleep <g>
<Hobbsee> Keybuk: yes, exactly
<Hobbsee> Keybuk: currently it's 2am - i'm a night person, not a morning person
<Hobbsee> Riddell can testify to that
<bluefoxicy> hold the meetings at 3am on a saturday, that way it'll be like 11pm there for hobsee and nobody will really care because we all stay up ungodly late anyway
<Hobbsee> haha
<Hobbsee> 11pm is 1300UTC - it's not bad.  that's when our kubuntu meetings are now
<bluefoxicy> (you may laugh, but I know like 6 people on another network, in the same channel, that are all in my city, that are all still up at 4am x_x)
<Keybuk> Hobbsee: which is 6am for mdz
* Hobbsee effectively said "you're going to have to move it, or you're goign to have to lose me off your committee, because i cant make these meetings anymore)
<Hobbsee> Keybuk: yeah, ouch.  there's nothing that suits everyone, i know
<bluefoxicy> can't you move the meetings around?
<bluefoxicy> some people will miss this month's, some will miss next months, but at least you won't torture the same people over and over or lose them off the comittee
<Hobbsee> bluefoxicy: could do.  not that many people absolutely must attend - quorums only 3 people, iirc.
<Kamion> 2
<Hobbsee> Kamion: 3 for kcc.
<imbrandon> bluefoxicy, and as small as the kcc is one missing is sometimes a pita
<Hobbsee> out of 6 people
<Kamion> Hobbsee: oh right, I thought you meant TB
<Keybuk> the problem we have with the TB is that 3 of the board are in the same timezone, and soon, all 4 will be
<Hobbsee> Kamion: ah, well, i could be, but as far as i know, i'm not suddenly on the TB, making it mandatory for me to be at all meetings :P
<Keybuk> which means if we rotate the meeting, then you have meetings without Q
<imbrandon> Keybuk, and thats a problem ?
<iwj> Kamion: Yes, do.
<iwj> I think they took my patch, yes.
<Hobbsee> Keybuk: yeah, that's the problem we face too
<Keybuk> imbrandon: it's a problem if the meeting time is rotated
<iwj> I reported it and they said they would, anyway.
<imbrandon> Keybuk, ahh yea
<iwj> Kamion: (^ all re ttf-freefont)
<bluefoxicy> split meetings
<iwj> Must go and catch train to go climbing now.  Talk to you tomorrow morning :-).
<imbrandon> bluefoxicy, those suck
<Hobbsee> iwj: enjoy!
<bluefoxicy> imbrandon:  heh, don't want to hold half this morning and half this afternoon?  :P
<Hobbsee> bluefoxicy: urgh, no thanks.
<Kamion> iwj: yeah, the Georgian thing was taken AFAICS
<bluefoxicy> at least then the people who are still around from the morning can relay things, or in the afternoon there are meeting logs everyone can review
<Hobbsee> bluefoxicy: they did that once.  it was very pointless.
<bluefoxicy> Hobbsee:  the people that needed to talk with eachother weren't on at the same time?
<Hobbsee> bluefoxicy: no, more that they decided everything on the first meeting, and the second was just a rehash of the first
<Hobbsee> besides, with people applying for things, it's a bit nasty to leave them hanging for half a day.
<Hobbsee> bluefoxicy: you'll understand that, once you go up for membership or something.  they're big and scary :P
<bluefoxicy> Hobbsee:  ever applied for a driver's license?
<Hobbsee> bluefoxicy: yeah, twice.
<bluefoxicy> "Please take this number and wait in this chair.  We'll call you... in about 18 hours."
<Hobbsee> bluefoxicy: nah, licencing here is better than that.  and i think i made the guy laugh too hard to pay much attention to my driving for the practical test :P
<Keybuk> ok, bluez-utils done
* Hobbsee is good at stuff like that :P
* bluefoxicy did parallel parking in 5 minutes, failed the test 3 times before they just conferred him a license to get rid of him.
<Hobbsee> bluefoxicy: hah.  /me got told she did one of the best parallel parks he'd seen all day.  and then i havent had to do one since.  anyway, this is kinda offtopic
<bluefoxicy> yes I was waiting for the topic to go back to normal
<Hobbsee> heh
<Hobbsee> there is such a thing as normal?
<Hobbsee> and why am i still up?
<bluefoxicy> because you aren't asleep
<Hobbsee> i should be though.  
<bluefoxicy> drink some catnip tea?
<Hobbsee> night all.
<Hobbsee> nah, mroe that i'd just get yelled at a lot.  nothing major.
<bluefoxicy> heh no I mean it's a nerve relaxant in humans, it makes you sleep.
<bluefoxicy> anyway what were we talking about, meetings... udebs.... 
<Hobbsee> yes, meetings
<bluefoxicy> yes but you were talking about meetings and you're about to pass out
<bluefoxicy> so that topic is kind of dead.
<Hobbsee> no, not about to pass out - not too dizzy yet.
<pitti> fabbione: can you put the wvstreams diff.gz/dsc somewhere for me to download?
<Hobbsee> pitti: did you want me to send you the debdiff?
<pitti> Hobbsee: between current Debian and your merged version would be nice, yes
<Hobbsee> pitti: you're pitti@ubuntu.com?
<pitti> Hobbsee: yes
<Hobbsee> what the...that doesnt look right
<dholbach> Kamion: you merged gparted! woohooo! :-)
<Kamion> aye, god knows whether it'll work
<Hobbsee> pitti: http://rafb.net/paste/results/ABpbzC62.html
<Kamion> I started it up and played a bit, though not in installer mode
<Hobbsee> hey dholbach 
<dholbach> hey Hobbsee
<pitti> Hobbsee: that's base to current ubuntu; I need current Debian to your merged version :)
<Hobbsee> ah crud, i knew something had screwed up there!
<Petaris> hrm, maybe I can run it on my Gentoo box instead
<Petaris> I'll need to add the drivers of course
<Kamion> dholbach: wasn't so much a merge as a recreate-from-scratch, btw
<Hobbsee> pitti: that look better?  http://rafb.net/paste/results/QLEbtu85.html
<fabbione> pitti: 4.2.2-1ubuntu2 	4.2.2-2.1 	4.2.2-1 <- wvstream.. same upstream version
<dholbach> Kamion: i noticed - i hope it wasn't too painful
<fabbione> pitti: if the patch doesn't do i have the diff and the dsc
<Hobbsee> hehe, thanks fabbione 
<pitti> Hobbsee: it'll do, thanks
* Hobbsee really only has 3 ways to do that patch - one surely is right :P
<Hobbsee> or would be if i was awake
<Hobbsee> night all!
<Kamion> dholbach: could have been worse ...
<Kamion> $ zcat gparted_0.1-0ubuntu9.diff.gz | wc -l
<Kamion> 1927
<Kamion> $ dscdiff gparted_0.2.5-1.1.dsc gparted_0.2.5-1.1ubuntu1.dsc | wc -l
<Kamion> 904
<ogra> you dropped the 1000 lines that made it work ?  :)
<fabbione> seb128: are you still editing the DistroMeeting page?
<seb128> fabbione: I've clicked on that page like 10 secondes ago, so yep, let me time to commit the change
<fabbione> seb128: sure :)
<seb128> people are wiki addict, that's incredible
<seb128> I edit a wiki page like once a month
<fabbione> seb128: that's my first edit in AGEEES on that wiki
<seb128> and every time after 10 seconds somebody ping me to know if I'm still working on it :p
<seb128> me too :)
<seb128> fabbione: done
<sivang> re
<fabbione> seb128: thanks :)
<seb128> np ;)
<jdub> seb128: !!!!!!!!!!!!11111111111
<seb128> jdub: gnome-vfs on dbus now? ;)
<jdub> :-)
<seb128> jdub: lot of dbus love this week, between gnome-vfs, gnome-settings-daemon, gnome-session ;)
<jdub> :)
<pitti> fabbione: bah, Hobbsee's patch is still broken; can you put diff.gz/dsc somewhere? I don't have time any more to wait for the next cron.daily
<fabbione> scp wvstreams_4.2.2-2.1ubuntu1.d* chinstrap:.
<fabbione> pitti: they are there
<sivang> seb128: could this love have anything to od with unloaidng applets, ALT-TAB broken, CTRL-ALT + arrows broken etc? :)
<sivang> (or lack, there of ;-) )
<pitti> fabbione: merci
<seb128> sivang: no, applets have nothing to do with gnome-session or gnome-settings-daemon and the new gnome-vfs has just been uploaded
<seb128> neither with keyboard
<ogra> sivang, the applets are 2.14 ... wait for the updated ones :)
<sivang> ogra: or I'll grab the src pkg from ftp and build myself until it's built on LP, I am so used to ALT-F2 :)
<ogra> ALT-F2 are surely not the applets :)
<ogra> thats either gnome-panel or gnome-menus
<dholbach> gnome-panel
<ogra> Amaranth, haha, i just checked out the latest revisions for willowng 
<ogra> "almost look like a real project" is a nice changelog entry :)
<Amaranth> :D
<Amaranth> it has an installer
<Amaranth> although if you install it it probably won't run, i don't have path stuff setup
<ogra> and a .desktop file, wohoo
<ogra> doesnt matter, lets see that we get a package in asap 
<ogra> i.e. tomorrow is UVF ...
<Keybuk> which means upload must happen today
<Amaranth> so if i release a new version a week from now it doesn't get in?
<Keybuk> it doesn't get in without an exception, no
<ogra> Amaranth, no, since its developed for us 
<ogra> but the initial package should be in the archive before UVF
<Amaranth> ok
<Amaranth> well, i don't know how to package a daemon so... :)
<ogra> i prepared some package stuff already, just havent pushed it up, wait a sec
<Amaranth> ok
<ogra> thats all stuff we can solve later ... for now it should just be there :)
<ogra> Amaranth, http://people.ubuntu.com/~ogra/bzr-archive/willowng/ merge that ...
<ogra> should have basic packaging stuff
<Keybuk> ok, I've switched MoM's status reporting to UVF mode now
<Keybuk> so any new merges that show up with the next cron.daily are obvious, and we can easily decide whether to consider them outstanding or not
<Amaranth> ogra: that's a stock dh_make run :P
<Amaranth> i can make a cdbs package
<ogra> bah
<ogra> but as you like
<ogra> Amaranth, its your project, i'm only helping :)
<Amaranth> heh
<Amaranth> the only thing i need help with is the init script and /etc/defaults stuff
<ogra> so make your decision sinc you will maintina it 
<Amaranth> and iptables
<ogra> god, i should learn to type
<ogra> iptables is for later 
<ogra> make it cdbs then :)=
<bddebian> Heya folks
<jjesse> hiya bddebian
<bddebian> Hi jjesse
<bddebian> Sorr for the OT question but any PKI experts around I could talk to offline?
<Burgwork> bddebian, PKI as in gpg keys?
<bddebian> Well digital signatures, yes
<Burgwork> hmm, maybe Kinnison?
<bddebian> BTW, hi Burgwork
<rodarvus> mdz: how many hours do we have before UVF?
<mdz> rodarvus: unspecified
<rodarvus> *nods*
<mdz> rodarvus: roughy end of the day tomorrow
<mdz> roughly
<rodarvus> ahn, plenty of time, then
<Keybuk> mdz: let's not make it end of day tomorrow
<rodarvus> i'm build-testing mesa right now, but was worried that UVF was in practice by midnight today
<Keybuk> let's make it 0000UTC
<Keybuk> end-of-day-tomorrow means we'll take in two more debian days
<rodarvus> Keybuk: thats what I'm afraid of :D
<janimo> rodarvus, mdz :  I have talked to ogra earlier about edubuntu-xfce. Does it necessarily need new seeds, is a simple metapackage to cover xfce core apps not enough?
<mdz> Keybuk: we can shut off the sync prior to UVF
<mdz> I assumed rodarvus wanted to know how much time he had to get merges and new versions in
<hunger> Is it known that gsfonts-x11 and xfonts-intl-european are broken in edgy right now?
<rodarvus> mdz: right
<rodarvus> mesa just finished building, I'll finish tests now
<Keybuk> mdz: we can't shut off the mom merge sync though
<rodarvus> so hopefully even midnight today won't be a problem
<Keybuk> we're in the best situation _now_ merge and sync wise
<Keybuk> I'd rather we looked at what comes in from Debian in an hour's time, and make a judgement call then whether to declare us frozen or take the new day
<fabbione> hunger: yes. all X fonts are broken atm
<mdz> Keybuk: sure
<gnomefreak> they are?
<mdz> but I'm happy for rodarvus to merge mesa tomorrow morning
<gnomefreak> ah i see the new updates nvm
<mdz> to upload it, that is
<mdz> fabbione: upgrading considered harmful?
<fabbione> gnomefreak: no, but given that nobody either read topic or understand what is happening, it doesn't really make any different if they are not
<janimo> is bumping our version to match debian's even though we have different packages considered a good thing, just to get the packages off the list?
<fabbione> mdz: no X upgrade is safe.
<gnomefreak> fabbione: true
<Keybuk> mdz: yup, it doesn't seem sensible to declare that any outstanding merges have missed the boat
<fabbione> mdz: only fonts will be holded-back.
<mdz> fabbione: "no, it is safe to upgrade X" or "no X upgrade is ever safe"?
* gnomefreak hasnt had an issue in a while other than the gnome-applets
<Keybuk> however it does seem sensible to draw the line between outstanding merges and "new stuff"
<fabbione> mdz: the former.
<mdz> ok
<Keybuk> today is good because Debian is conveniently rather switched off <g>
<fabbione> Keybuk: mind to check if the fonts stuff Kamion/Mith uploaded are building or need a kick?
<Keybuk> fabbione: latest by-hand publisher run just finished
<Keybuk> about to kick the build sequencer
<fabbione> mdz: the -driver -> -video transition is completed
<fabbione> mdz: all stuff except secondary apps have been merged. 
<fabbione> mdz: the list was just too long for 2 weeks of work..
<Keybuk> https://launchpad.net/+builds/+build/227834
<Keybuk> fabbione: ^ built
<fabbione> mdz: and fonts are sorting themselves out in these cron.keybuk
<Keybuk> https://merges.ubuntu.com/main.html
<Keybuk> ^ that is now accurate
<mdz> nice
<gnomefreak> edgy is gonna have ff 1.5.0.4 as final?
<Keybuk> Colin's asked for a UVF exception for installation-guide given it's doc only
<Keybuk> jbailey is doing initramfs-tools at the moment, and should be uploaded today
<Keybuk> rodarvus is doing mesa right now
<Keybuk> I'm going to do n-m in a bit
<Keybuk> g-p-m is allegedly "tricky" and involves an upstream version update
<Keybuk> mvo is on holiday, and the only person who knows gdebi well enough
<Keybuk> enigmail was a messy one, and really needs someone who knows Mozilla stuff
<Keybuk> xfce4-* no idea, ask janimo :)
<janimo> working on it now
<janimo> just asked a few lines above if it's ok to bump the version no to match debian's even though we are not that much in sync
<sivang> Keybuk: there's also gdebi and enigmail
<Keybuk> sivang: I mentioned those above
<Keybuk> janimo: I've tended not to (cf. bootchart) ... it's enough to know we're not keeping in sync
<mdz> seb128: gnome-applets ftbfs
<mdz> http://librarian.launchpad.net/3387554/buildlog_ubuntu-edgy-i386.gnome-applets_2.15.1.1-0ubuntu1_FAILEDTOBUILD.txt.gz
<fabbione> mdz: i will also need an exception for the redhat cluster suite as i noted also for the meeting update
<fabbione> mdz: the stuff is changed too much upstream
<sivang> Keybuk: oh right, scary merges...
<Keybuk> fabbione: source package name changed in Debian?
<fabbione> Keybuk: it doesn't exist in Debian
<fabbione> Keybuk: they have some (unmaintained) bits in Debian
<Keybuk> hmm?
<Keybuk> there's a redhat-cluster package in Debian
<Keybuk> which has roughly the same set of binaries as our redhat-cluster-suite
<fabbione> the what?
<Keybuk> http://packages.debian.org/src:redhat-cluster
<Keybuk> even the package descriptions roughly match ours
<fabbione> Keybuk: i am ready to bet it's a package that Debian stole from me and forked
<fabbione> without even telling me
<fabbione> it's not the first or the last time i see that happening on these kind of stuff
<Keybuk> might be worth comparing them
<jdub> haha
<fabbione> Keybuk: already did
<fabbione> it's the old -stable suite we had in dapper
<fabbione> and highly buggy btw
<Keybuk> so it should stay blacklisted?
<fabbione> waldi didn't add a lot of the fixes i did with upstream
<fabbione> yes please
<Keybuk> should we not change our source/binary package names to match, so it has the potential to be sync'd later?
<Keybuk> and just keep our version > ?
<fabbione> Keybuk: i won't bother.. their package is trash
<Keybuk> *nods*
<Keybuk> right, gonna get some food, bbiab
<ogra> Keybuk, i'm on g-p-m (since yesterday already
<ogra> )
<ogra> so dont bother
<fabbione> Keybuk: clearly that package was never tested at all :) i can tell you from some stuff in there ;)
<janimo> jdub: hi, did you manage to get any info on the GnomeClient API future at guadec?
* tseng makes funny faces at the latest Burgwork post
<rodarvus> merged mesa is available at -> http://people.ubuntu.com/~rodarvus/mesa/ - it would be nice if someone could review this merge before I upload it
<rodarvus> debdiff from debian is http://people.ubuntu.com/~rodarvus/mesa/mesa_6.4.1-0ubuntu8-to-mesa_6.4.2-1ubuntu1.patch.gz
<rodarvus> debdiff from ubuntu is http://people.ubuntu.com/~rodarvus/mesa/mesa_6.4.2-1-to-mesa_6.4.2-1ubuntu1.patch.gz
<rodarvus> (second one is rather large, though, as its a different upstream version)
<seb128> mdz: thank you, I will fix that
<mdz> seb128: is there any information I should file with my gaim bugs?
<seb128> mdz: I don' think so, if upstreams need something I'm sure they will ask
<rodarvus> fabbione reviewed mesa (there was one Conflicts/Replaces/Provides missing for mesa-swrast-source -> mesa-swx11-source)
<rodarvus> fabbione: thanks!
<rodarvus> I'll upload mesa *now*
<rodarvus> :)
<profoX`> good day
<profoX`> where can I find the stuff for the on screen display when I press the volume up/down button on my laptop ? I need to change something there for IBM laptops (because they have hardwaredriven volume adjustment)
<xpotato> i have a thinkpad at home, but i've never fiddled with the volume control buttons with ubuntu
<fabbione> rodarvus: nice...
<fabbione> ok i call this a day
<xpotato> profoX`: try http://ibm-acpi.sourceforge.net/
<fabbione> good night
<rodarvus> fabbione: good night
<sivang> night fabbione 
<profoX`> xpotato: i have that, by default, but that doesn't take care of things on the ubuntu side, in acpi everything works perfectly, but i want it to work like it has to in ubuntu so i'd like to create a patch, but i don't know where to find the thing that drives the on screen display for the volume etc. (and i will also add one for brightness for IBM)
<xpotato> profoX`: oh...well you're farther along than I thought you were
<xpotato> does anyone know the status on the development of the apache 2.2.x packages for debian?
<Keybuk> the GNOME bit is just gnome-settings-daemon somewhere
<Keybuk> it responds to key press events
<xpotato> or ubuntu*
<ogra> xfonts-scalable postinst warning: update-fonts-scale --x11r7-layout Type1 failed; font directory data may not be up to date
<ogra> usage error: unrecognized option
<ogra> Usage: update-fonts-alias DIRECTORY ...
<ogra>        update-fonts-alias { -h | --help }
<sivang> ogra: I got that today for gsfonts-x11
<profoX`> xpotato: yea... i guess no one knows where i would need to look ?
<ogra> shouldnt that depend on the right version to have --x11r7-layout ?
<rodarvus> ogra: all font packages are failing right now
<msw> Keybuk: the volume/brightness bits on thinkpad aren't keysyms
<rodarvus> Mithrandir already uploaded xfonts-utils
<rodarvus> which should take care of this
<rodarvus> but its not in the archive
<ogra> rodarvus, why ? i thought that why we waited with the fonts
<ogra> ah, k
<rodarvus> ogra: font packages triggered this before than expected, due to dh_xinstallfonts (or someting like this, I forgot now)
<ogra> dh_installxfonts, yep
<xpotato> profoX`: which thinkpad do you have?
<profoX`> xpotato: T40
<rodarvus> Keybuk: most of my xserver-xorg-input-* builds are not completed in sparc|powerpc|ia64 - and they have been uploaded ~24 hours ago
<rodarvus> are xserver-xorg-input-* so low priority to build, or anything happened to the build daemons?
<xpotato> profoX`: you may have already seen this, but here's some more information on the T40 https://wiki.ubuntu.com/LaptopTestingTeam/ThinkpadT40
<xpotato> profoX`: if I was at home, I might be able to help you out a little more
<xpotato> does anyone have any idea on the status of the apache 2.2.x packages?
<xpotato> or if there are going to be any packages?
<profoX`> xpotato: they didnt even make a note about the hardware volume
<profoX`> I just want to improve ubuntu so that it works like it actually should when edgy is here ;)
<profoX`> (yea, it is starting to annoy me on my laptop :X)
<rodarvus> oh, btw - the mesa upload has some (four, I think) new packages
<xpotato> profoX`: about a quarter of the way down the page: Hardware volume switch - Tested OK
<rodarvus> I suppose they'll go through NEW, right?
<Keybuk> rodarvus: yeah, they will
<mdz> I thought pitti fixed python-jabber
<profoX`> xpotato: that doesn't mean anything, yes, the "buttons" do work, but ubuntu doesn't handle it like it should, most volume switches just send a command to raise or lower volume to the software, but in IBM Thinkpad it changes volume itself (from 0 to 15) so sometimes I see volume: 0 in alsa and I still hear sound, and stuff like that, in this case alsa volume and hardware volume should be seperated
<mdz> profoX`: bug 46230
<Ubugtu> Malone bug 46230 in hotkey-setup "ThinkPad T42 mute button does double duty" [Low,Rejected]  http://launchpad.net/bugs/46230
<xpotato> profoX`: sorry, I just realized what you were looking for; I had that same problem in Mac OS X when I tried it out on my thinkpad (volume could be set to 0 and I'd still hear sound, hardware keys did not bring up the OSD like it should)
<profoX`> lol rejected so i can work on it anyway
<profoX`> mdz: like i said, the hardware should be seperated from the software, that causes this issue too
<mdz> profoX`: you'll notice that I reported the bug and said the same thing
<profoX`> I just have to patch the code that brings up the OSD to read in the volume from /proc/acpi/ibm/volume if its there
<mdz> profoX`: and now you know who to talk to about it, and where to follow up
<profoX`> mdz: yes thanks i'll read it in a second, it's in my next vdesktop :)
<mdz> rodarvus: it looks like x11proto-print needs review for main
<mdz> rodarvus: unless we can move libxp to universe, which would be better
<Kamion> ogra: xfonts-utils didn't make it through quite as quickly as I expected it to, due to the soyuz breakage
<Kamion> but never mind, it'll clear up
<mdz> I think it's deprecated upstream
<Kamion> mdz: libxp is explicitly seeded for third-party apps IIRC
<ogra> Kamion, ta ... g-p-m will keep me busy enough :)
<Kamion> also a few stray dependencies elsewhere
<mdz> Kamion: yeah, Java I think
<Kamion> ogra: a versioned depend would be correct, I agree
<ogra> yeps, but now we have the breakage anyway :)
<mdz> I think it's only java, and we do have a better answer for that these days
<mdz> well, for sun
<mdz> not IBM
<Kamion> ogra: the new xfonts-utils is in the archive now
<rodarvus> mdz: x11proto-print was not done by me, but I can take a look at this issue later today
<rodarvus> (in a few minutes, actually)
<mdz> rodarvus: libxp depends on it now
<mdz> Keybuk: what are 'new merges'?
<Keybuk> mdz: ok, so this is the "post-UVF mode"
<rodarvus> mdz: I'll take a look at it now
<Keybuk> updated is as before, packages which have had an upload to edgy and where the Debian version is still higher
<Keybuk> new are packages which have not been uploaded to edgy yet, and where the Debian version is higher
<rodarvus> Keybuk: do you know if is there any problem with the upload queue? I haven't received any email feedback from my mesa upload (and it happened ~40 minutes ago)
<Keybuk> (where uploaded to edgy does not include syncs, btw)
<mdz> ok, that makes sense except for the bit where UVF hasn't actually started yet ;-)
<rodarvus> not even a rejection email
<Keybuk> and outstanding merges is as new, except driven by a text file list
<Keybuk> right, see ^^
<slomo_> rodarvus: uploaded with "unstable" as distribution by accident maybe? at least i never got a rejection mail for that in the past ;)
<Keybuk> I switched on the mode early so it's obvious which things turn up when Debian's cron.daily runs
<mdz> rodarvus: it failed
<Keybuk> and then we can decide whether to take them or not
<Kamion> slomo_ is correct
<Kamion> http://librarian.launchpad.net/3390302/goyJX0fqm6A5LxH4KXYqEEUNKsJ.txt
<mdz> rodarvus: Distribution: unstable
* rodarvus sighs
<Keybuk> new merges show up under "new", and if we decide that we want it for UVF, I'll just add it to outstanding-merges.txt
<rodarvus> mdz: thanks
<mdz> is there a bug open about the fact that soyuz doesn't send mail in that case?
<mdz> slomo_: ^?
<sivang> mdz: I'm checking
<Kamion> mdz: yes
<Kamion> I whined about it ages ago
<Kamion> https://launchpad.net/products/qprocd/+bug/35965
<Keybuk> there did used to be a mail
<Ubugtu> Malone bug 35965 in qprocd "exceptions in process-upload not communicated to uploader" [Medium,Confirmed]  
<Keybuk> but then they got rid of it
<Keybuk> you used to get an "upload made it out of main loop" mail
<Kamion> Keybuk: really? AFAIK Soyuz has never mailed for that since it went into production
<Kamion> interesting
<Keybuk> they disabled them because they contained python exception tracebacks or something
<Keybuk> or maybe it was because they didn't contain any useful exception traceback
<pygi> sivang, poke? :P
<rodarvus> Keybuk: any info on the xserver-xorg-input-* issue I mentioned above?
<Keybuk> rodarvus: could you be more specific?
<givre> hi guys, i have an urgent request to ask, i don't know how to put so i just ask it there. It's could be great if you could change the description of the server install CD
<Keybuk> ie. give me a proper source package name, for a start ;)
<givre> many people are confuse by the description:Server install CDThe server install CD allows you to install Ubuntu permanently on a computer.
<Kamion> Keybuk: for the record I'd like new mdcfg + partman-lvm + partman-md from this Debian cron.daily
<rodarvus> sure
<Kamion> givre: file a bug on launchpad.net/products/ubuntu-cdimage/+filebug
<Kamion> givre: also explain why this is urgent
<Keybuk> Kamion: *nods*
<rodarvus> https://launchpad.net/distros/ubuntu/edgy/+source/xserver-xorg-input-spaceorb/1:1.0.0.5-2ubuntu1 , https://launchpad.net/distros/ubuntu/edgy/+source/xserver-xorg-input-summa/1:1.0.0.5-2ubuntu1 and https://launchpad.net/distros/ubuntu/edgy/+source/xserver-xorg-input-tek4957/1:1.0.0.5-2ubuntu1 , for instance
<Keybuk> right :)
<Keybuk> I picked -mouse and that was up to date
<Keybuk> *shrug*
<Keybuk> it's just not built on the three slowest buildds
<rodarvus> -mouse was done by Mithrandir two days ago :)
<Keybuk> and they have relatively low priorities
<rodarvus> right, that was my question :)
<Kamion> aww, 4/5 successfully built for debian-installer
<Keybuk> urgently needed?
<Kamion> close but no cigar
<givre> and so lot's of people come in the forum why they don't have a gui after the install
<rodarvus> all xserver-xorg-input-* appear to have incredibly slow priority :)
<Kamion> not bad considering I only tested 1/5
<rodarvus> Keybuk: no, not really
<givre> *asking
<Keybuk> rodarvus: that's probably why they have a low priority then <g>
<Kamion> givre: ok, file a bug and I can change that
<Keybuk> sparc is about the slowest buildd (even slower than ia64)
<rodarvus> heh
<Keybuk> and also those three were the ones that were down longest during the kernel updates
<givre> ok, thanks  you
<givre> and thank you for all, you are doing a great job ;)
<Keybuk> rodarvus: in general, as long as the build is "Needs building" (and not "No build info recorded") and https://launchpad.net/+builds doesn't show any errors for the buildd, it's in the queue somewhere
<rodarvus> *nods*
<Keybuk> https://launchpad.net/distros/ubuntu/edgy/+builds?build_state=pending
<rodarvus> sparc currently has 631 packages on the queue
<Keybuk> ^ top priority in that list is 1055
<Keybuk> those have priority of 355  (meaning no real dependencies on them)
<rodarvus> mesa upload was accepted directly into Accepted
<rodarvus> shouldn't it go into NEW, due to the new packages it builds?
<Kamion> rodarvus: source was, binaries will hit NEW
<rodarvus> oh, good
<rodarvus> Kamion: and I suppose the other binaries are held until these packages in NEW are accepted?
<Kamion> rodarvus: nope
<Kamion> each upload is independent
<rodarvus> right
<Kamion> as in, each .changes file
<Kamion> the test is "does this .changes file contain components not currently in the overrides?"
<rodarvus> the reason I was wondering is because subpackages inside the same source can depend on packages still on NEW
<Keybuk> right
<rodarvus> (and thus leave the archive in an inconsistent state for awhile)
<Keybuk> those will just dep-wait on the buildds
<Keybuk> (assuming build-dep)
<Kamion> or be uninstallable for a bit, depending
<Keybuk> or as you say, leave the archive uninstallable
<Keybuk> but that's ok
<rodarvus> yup
<rodarvus> one feature I'd like to see, in the future, is the ability to "automagically rebuild" packages that depend, or build-depend on another package (such as a library) - on request, of course
<Keybuk> in practice, this isn't much of a problem
<Keybuk> rodarvus: 9/10 they need more than just a rebuild
<rodarvus> say, I uploaded a new, incompatible version of mesa, and when it is uploaded and built, go to some launchpad page, and instruct the packages to rebuild themselves
<rodarvus> Keybuk: I don't think its 9/10, but still, you have a valid point
<Keybuk> in particular, it's usually wise to add/increment version in the build-depend line to make sure you hit dep-wait or build against the thing you actually meant
<Keybuk> and, in true honesty, if the package doesn't work just as well with the new as well as the old, the chances are there's a code change required
<Keybuk> we used to do "meta-builds" at Demon for this kind of thing, and in the end abandoned it because they were nearly always useless
<rodarvus> heh :)
<Keybuk> if the library doesn't change soname, the packages don't need to rebuilt
<Keybuk> if the library does change soname, the packages almost always need code changed ... after all, there was a reason the soname changed
<Keybuk> bbiab - asda trip
<rodarvus> Keybuk: tell that to freetype developers :)
<msw> (and tons of other people who don't manage their DSO ABIs)
<rodarvus> but in general, I agree with you
<rodarvus> msw: right
<msw> which is one reason our (rpath) standard build mode is to build everything from scratch -- a full bootstrap build
<FunnyLookinHat> mdz, You around?  Was hoping you could tell me how to find a contact address for Christian Marillat?  his launchpad account profiles are a bit empty  ^_^;;
<jdub> marillat@debian.org
<FunnyLookinHat> jdub, thanks!
<seb128> FunnyLookinHat: what do you want to mail him?
<FunnyLookinHat> seb128, it's concerning rebuilding the packages for MythTV.  mdz passed his name along in a chain of comments today on a bug related to the issue.
<seb128> ok, because he doesn't work on Ubuntu afaik
<FunnyLookinHat> seb128, that's what I thought  ^_^;;   But I figured mdz knew more than me
<seb128> and he's not always nice about bugs or by mail ... just so you know
<jdub> take a kevlar vest
<jdub> and maybe some rations
<FunnyLookinHat> lol
<seb128> FunnyLookinHat: good luck ;)
<FunnyLookinHat> Lol he just replied
<FunnyLookinHat> "
<FunnyLookinHat> I'm sorry but I'm not the responsible for Ubuntu packages, even if my
<FunnyLookinHat> name is in the Maintainer field."
<seb128> you will need some :p
<FunnyLookinHat> Looks like I'm on my own, w00t.
<seb128> ah, he has been nice ;)
<crimsun> FunnyLookinHat: coordinate with the motu-media team
<Keybuk> msw: you don't have mirrors :)
<jdub> yeah man, you got out lucky
<Keybuk> a full rebuild to us is (in the worlds of the great elmo) "HERE'S JOHNNY!"
<jdub> last time i mailed marillat it was like apocalypse now
<msw> Keybuk: sure we do!
<jdub> but they were *MY* ears he was wearing
<FunnyLookinHat> crimsun, motu-media...   ok, sounds good.  I have to still officially try to join the team.
<msw> Keybuk: ;-)
<Keybuk> msw: how do you cope with the full rebuild pumping gigabytes a day in their direction?
<msw> Keybuk: one sec
<seb128> jdub: did you mail him about GNOME, Debian, and GNOME Team? :)
<msw> Keybuk: the mirror process goes through the same changeset process that clients use to apply relative updates
<msw> Keybuk: so, when we do a rebuild of the same software, generally very very little changes.
<Keybuk> msw: it's still got to be a large churn though, no?
<jdub> seb128: yeah, back then ;)
<Keybuk> msw: a library change like libc6 is going to affect change binary on the system
<msw> Keybuk: we've done a rebuild and had, oh, maybe 300 MiB of new contents to push out
<seb128> he sent some really non-friendly mails around that time
<msw> Keybuk: true, true
<seb128> Keybuk: could you get control-center out of NEW? It adds a gnome-control-center-dev new binary package which is required by gnome-session to build
<Keybuk> seb128: it's only NEW for i386?
<seb128> Keybuk: the -dev is arch: all (it's only a .h and a .pc)
<Keybuk> yeah
<seb128> Keybuk: dunno if that class it as NEW on i386 only
<Keybuk> it does
<Keybuk> Soyuz doesn't know about _all, it thinks they're i386
<ogra_> seb128, what was the command to clear out gconf user settings ? gconftool-2 --recursive-unset /apps/gnome-power-manager seems not to suffice
<seb128> ogra_: it should ...
<ogra_> hmm
<seb128> ogra_: rm -rf .gconf/apps/gnome-power-manager and send a SIGHUP to gconfd-2 then
<ogra_> then i probably have cruft in the schema ...
* ogra_ tries
<seb128> ogra_: that's easy other way, use gconf-editor, go on the key and unset it .. unset == revert to system default
<ogra_> yes, but it seems theer are some keys without owner in the g-p-m settings for me ... 
<ogra_> urgh
<seb128> what?
<ogra_> intrestingly they work, even they are not assigned to g-p-m
<ogra_> i just dimmed my display to 0
<seb128> a key doesn't need to be "assigned" to work
<seb128> everybody is authorized to read a gconf key
<seb128> it's not only the app owning the key
<ogra_> yes, but usually the keys from a schema are assigned to an app
<seb128> yeah, if the schemas is correctly done
<ogra_> (key owner field that is)
<seb128> that's declared by the schemas itself
<seb128> $ xvfb-run echo
<seb128> kill: 158: No such process
<seb128> bouh
<ogra_> ok, then i'm fine, i was suspecting old keys lying around
<seb128> xvfb-run breaks pygobject build
<ogra_> but it seems they are valid just the schema is buggy
<seb128> ogra_: look to the schemas file:
<seb128>     <schema>
<seb128>       <key>/schemas/apps/gedit-2/preferences/editor/font/use_default_font</key>
<seb128>       <applyto>/apps/gedit-2/preferences/editor/font/use_default_font</applyto>
<seb128>       <owner>gedit</owner>
<seb128> by example
<seb128> do they use <owner>  for it ?
<Keybuk> seb128: random question you may know the answer to
<Keybuk> does Debian's hal daemon run as a different user to ours?
<seb128> Keybuk: no idea, would be a question for pitti
<seb128> changelog mentions "Rename system user 'hal' to 'haldaemon' to be compatible with upstream"
<seb128> and apparently the Debian changelog has no such change
<seb128> looks like they are different yep
<Keybuk> right
<Keybuk> just thought you might more familar than me
<seb128> not really no, pitti does a good job for it so I didn't have to look to hal for a while now ;)
<seb128> s/for it/with it
<Keybuk> given I officially no longer care about n-m, I'm almost completely reverting to the Debian packaging
<Keybuk> which is made somewhat easy by the fact they've almost completely stolen our changes anyway :)
<Keybuk> just needed to work around the whole netdev/hal/haldaemon thing
<seb128> ok :)
<jdub> Keybuk: because you think it's cock, or you don't want to deal with it?
<Keybuk> jdub: because I think it's cock at the moment
<jdub> heh
<Keybuk> right now it's cock that's covered in cheese
<Keybuk> but once it's cleaned up, and had some time to grow, it'll be good cock
<Keybuk> my general n-m feeling is "it doesn't work yet, but one day will be the one true network stack"
<mdz> implying that cheese-covered cock is bad cock?
<jdub> Keybuk: i guess that using 'cock' as an adjective can be ambiguous in certain contexts... ;)
<ogra_> pitti, do we plan to support polkitd in hal ? 
<jdub> fabbione: I WANT UBUNTU ON THUMPER!!!111 :-)
<jdub> fabbione: only i also want zfs on ubuntu :-(
<ogra_> (for edgy that is=
<ogra_> )
<pygi> jdub, do it !!! :P
<ogra_> zfs ? 
<ogra_> zoom filesystem - for extremly small files ? 
<jdub> ogra_: http://www.google.com.au/search?q=zfs+filetype%3Apdf
<jdub> read that
<pygi> ogra_, Solaris ^_^
<jdub> (but read the pdf, not google's html)
<ogra_> hmm, snapshots with rollback builtin ...
<jdub> Keybuk: so n-m in edgy should suck less on b0rky atheros (with rml's patch)?
<pitti> ogra_: this policy kit seems utterly crackful to me, and there is still some upstream discussion about it
<mjg59> edgy's going with madwifi-ng anyway
<Keybuk> jdub: hmm?  we always had rml's patch
<pitti> ogra_: I would like to postpone it to edgy+1
<Keybuk> that's why it doesn't use teeth when it sucks on dapper
<jdub> hrm, i thought rml did some funky "don't scan when associated" foo
<Keybuk> it scans about once a minute
<Keybuk> rather than every 10s
<jdub> pitti: oh?
<ogra_> pitti, seems new g-p-m somewhat relies on its existence 
<Keybuk> what's polkitd?
<jdub> davidz's policy kit
<ogra_> enbles hal to do evil things
<jdub> for better google words
<mjg59> Provides a framework for providing fine-grained access to hal objects and so on
<seb128> gnome-system-tools is going to use it too
<ogra_> oh, really ? 
<mjg59> Also deals with the problem of keeping status when no user is logged in
<ogra_> in edgy already ? 
<seb128> might be
<seb128> carlos showed some code during GUADEC using it
<gnomefreak> what version ill let you know if it in edgy
* jdub wishes harder for gnome-vfs builds to be complete
<mjg59> We probably want it in edgy, otherwise the divergence to FC6 is going to be irritating
<pitti> seb128, ogra_: <rant> why do these things rely on features which aren't even in a stable hal release yet???</rant>
<ogra_> mjg59, it would make a painful g-p-m merge delightful
<Keybuk> pitti: "shiny"
<ogra_> pitti, i didnt make the decision
<pitti> ogra_: packaging and auditing policy kit daemon and all the crack in it, and packaging hal cvs head is not a simple task either
<seb128> pitti: because they are not stable versions neither?: p
<jdub> pitti: upstream sets the agenda :)
<mjg59> pitti: hal should be releasing in the next few days
<ogra_> +and i'm sure i could work around it by getting Kinnisons patch in, but that means i'll have to revert parts of the code to the former version
<pitti> well, if we need it, and you want me to, I'll package it
<pitti> but so far noone told me that it's necessary, so I didn't :)
<seb128> pitti: by the time GNOME 2.16 is available a new hal will probably be too
* jdub blinks.
<jdub> The following NEW packages will be installed: pbbuttonsd
<pitti> jdub: for apple intel
<jdub> pitti: oh! of course. BONG!
<ogra_> well, that would leave us not much time for testing
<ogra_> jdub, yeah, for your macbook :P
<ogra_> (which you dont own yet, but we install in advance :P )
<jdub> i hope pbbuttonsd is a no-op on my machine tho ;)
<jdub> yay gnome-vfs packages
<mjg59> pbbuttonsd is needed for apple intels?
<mjg59> Really?
<mjg59> How does that work?
<ogra_> it was included because of them ...
<ogra_> (no idea if its needed :) )
<ogra_> (in the i386 seed that is)
* mjg59 boggles
<mjg59> Doesn't it only interface with /dev/pmu?
<ogra> i think so 
<mjg59> Who asked for it to be added to the seed?
<ogra> do macbooks have that ? 
<mjg59> No
<ogra> heh
<ogra> no idea who asked for it ... i think Kamion added it
<mjg59> There's a completely different interface to the hardware
<mjg59> Kamion: ^?
<ogra> intrestingly there is no changelog entry in the seeds
<Kamion> mjg59: we didn't explicitly add it; we just never made it architecture-dependent
<ogra> mdz, oh, wow, thanks for adding mknbi to supported :)
<Kamion> so when pbbuttonsd started to be built on i386, it automatically appeared
<jdub> heh
<Kamion> mjg59: if you think it shouldn't be there (though perhaps investigating the code first would be a good plan?), feel free to make a seed commit to change ' * pbbuttonsd' to ' * pbbuttonsd [powerpc] '
<mdz> Kamion: surely it should be Architecture: powerpc if it can't work with macbooks
<Kamion> mdz: it was, but was then deliberately made Architecture: powerpc i386 by the Debian maintainer
<mdz> ogra: I didn't want it to be forgotten, since it didn't get a spec
<mdz> ogra: please get someone to test it
<Kamion> I assumed he vaguely knew what he was doing and haven't yet got round to investigating
<Kamion> there was a changelog comment about it
<Kamion> ogra: I did not add it, for the record
<mdz> there was no human involvement
<Kamion> except insofar as I probably added the original seed entry
<Kamion> but that was before germinate had architecture-specific seed entries anyway
<ogra> Kamion, yes, i see that now
<mdz> Kamion: how far out of sync is it possible for anastacia and your germinate-output to be?
<mdz> when did ndiswrapper-utils move from main to universe?
<ogra> mdz, our mknbi is broken currently but jammcq and me are on it
<ogra> mdz, when Keybuk demoted it because of security ambiguity (as he said)
<mdz> Keybuk: ?
<mdz> rodarvus: what's to be done about xserver-xorg-input-elographics? it still wants to move to universe; presumably some -all package should depend on it
<Keybuk> mdz: it's an entirely new version
<Keybuk> so needs MIRing again
<Keybuk> comes from a different source package too
<Keybuk> what we used to have is ndiswrapper-1.8 or something
<Keybuk> like I said when I did it, I haven't had chance to actually figure out what's going on
<Keybuk> so I NEW'd it all to universe
#ubuntu-devel 2006-07-13
<mjg59> Kamion: I don't think I have access to the seeds, or has that changed?
<crimsun> all core-dev have access to the seeds
<mjg59> Ah, right
<Keybuk> mjg59: bzr checkout sftp://mjg59@bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/ubuntu.edgy
<Keybuk> you'll need to give launchpad your ssh public keys using the link at /people/mjg59
<bddebian> Bye folks
<mjg59> Ok, the change looks like crack
<mjg59> I'll talk to the debian maintainer
<Keybuk> mdz: ok, that Debian day brought us no new merges
<mdz> Keybuk: unsurprising considering the day
<Keybuk> indeed
<Keybuk> that's why I thought today would be a good day to declare UVF :p
<sladen> Keybuk: is that in 65minutes, or 1505 minutes?
<Keybuk> sladen: eh?
<Keybuk> oh
<Keybuk> Debian's days are 1440 minutes
<Keybuk> ours are 60 minutes
<sladen> Keybuk: when does UVF actually kick in given I've been off-net with weddings and et al and still need to do merges
<Keybuk> sladen: which merges do you still need to do? :p
* sladen thought ours were 30minutes, or did that change
<sladen> Keybuk: I haven't even looked ;-)
<Keybuk> https://merges.ubuntu.com/main.html#outstanding
<Keybuk> no Paul Sladen there
<Keybuk> (I did several of yours myself)
<sladen> oooh, excellent, 
<Keybuk> ours haven't been 30 minutes since LP
* sladen hands Keybuk a bunch of pweety flowers
<Keybuk> LP is slower than Katie
* sladen thinks about applying grease to launchpad and katie
<Keybuk> mdz: so the only two outstanding merges we don't know what's happening with are gdebi and enigmail
<sladen> ...think katie would be more fun
<Keybuk> mdz: shall we declare UVF?
<mdz> Keybuk: gdebi is of ubuntu origins so I'm not concerned
<mdz> and enigmail only has packaging changes, I'll have a look at it
<mdz> the only interesting thing in the enigmail changelog is a build failure fix for amd64/powerpc
<mdz> if it fails, we'll fix it then
<mdz> Keybuk: so yes
<Keybuk> ok, you want to send the mail to u-d-a, or should I?
<mdz> Keybuk: I shall
<Keybuk> ok
<mdz> ubuntu-desktop still isn't installabe but I think the two remaining fixes are in the pipeline
<mdz> gnome-applets and xorg
<Keybuk> *nods* gnome-applets is from GNOME not Debian, and xorg is at least sync'd
<mdz> gnome-applets built on i386 but nowhere else
<mdz> looks like it might need retries
<Keybuk> gnome-applets 2.15.1.1-0ubuntu2 - powerpc ia64 sparc amd64
<Keybuk> done
* Keybuk -> food -- bbiab
<jdub> 09:12  * mclasen already has libdbus in /lib
<jdub> 09:12 < mclasen> fedora leads the way...
<jdub> 09:13 < mclasen> I also have glib in /lib...
<jdub> :-)
<mdz> the new jabber icon in gaim looks a little bit like a Debian swirl
<mdz> mesa is dep-waiting on lesstif2-dev
<mdz> which is in universe
<mdz> rodarvus: it looks like your merge reintroduced that dependency; it had been dropped
<Keybuk> jdub: and this is considered a good thing because ... ?
<rodarvus> mdz: yes, debian mesa has libGLW built in
<rodarvus> mdz: should I rebuilt mesa with this disabled? (but this way we would diverge from them)
<Keybuk> mdz: "With the With the upstream churn in Edgy settling down, we can start to introduce our own breakage."
<Keybuk> been on the red wine, have we? :)
<rodarvus> mdz: regarding xserver-xorg-input-elographics, I'm afraid I'm not in position of saying if it should be promoted to main (and be included in xserver-xorg-input-all) or just stay in universe
<rodarvus> there are other X input drivers already in universe so I'd leave it there
<mdz> Keybuk: vi failure
<mdz> rodarvus: it's already in main
<mdz> rodarvus: regarding mesa, we made a decision some time ago to not support lesstif, and did some work to eliminate dependencies on it (including mesa)
<mdz> rodarvus: one way or another, we want the core to be installable tomorrow so that we can roll a milestone.  disabling the lesstif support seems the most expedient way to do that
<rodarvus> *nods*
<rodarvus> mdz: it shouldn't be much trouble to remove lesstiff support again, I just need your approval to go ahead, then
<mdz> rodarvus: please do
<rodarvus> doing it now
<mdz> thanks
<crimsun> mdz: does universe have the same UVF date (today), or is it in late Sept as noted on the schedule?
<mdz> crimsun: the latter
<crimsun> mdz: thanks
<mdz> I should have qualified the announcement
<mdz> hmm, gnome-applets still failing on !i386
<zul> hey
<ogra> mdz, ok to upload g-p-m ?
<mdz> ogra: merge?
<mdz> does it install and work?
<ogra> merge and new upstream version 
<ogra> wont suspend and hibernate without polkitd from hal, pitti is aware
<ogra> (policy kit is also used in control center now according to seb)
<ogra> but the rest works ... (lock on lid close, battery state changes etc)
<ogra> mdz, http://people.ubuntu.com/~ogra/g-p-m-changelog.txt
<mdz> ogra: I think breaking suspend and hibernate entirely will get us a lot of unnecessary bug reports from knot 1
<mdz> ogra: better to land it with the necessary hal changes
<ogra> mdz, so shall i keep it back
<ogra> ?
<ogra> ok
<mdz> yes
<ogra> i can forward it to dholbach then, he wanted to care for the icon stuff anyway
<mdz> ogra: ok, go to sleep :-P
<ogra> heh, i just opened a bottle of merlot ... its nice and quiet here in the garden in the dark :) but i'll go soon, promised :)
<mjg59> Any alsa-type people around?
* ogra points mjg59 to crimsun
<zul> i think crimsun might be around
<Keybuk> ogra: heh, I have a bottle of cabernet here :)  a toast ? :p
<ogra> sure :)
<Keybuk> dunno what to
<ogra> may we still see many UVFs together :)
<ogra> (nut the next ones later in the cycle please)
<ogra> *but
<Keybuk> hehe :)
<Keybuk> may they all be as easy as this one was
<Keybuk> right, bed or I shall miss the meeting
<Keybuk> nite
<ogra> yeah !
<ogra> wow, initramfs-tools changelog has an impressive length
<jdub> yeah, i can almost taste the sweat dripping off it
<crimsun> mjg59: hi
<mjg59> crimsun: So, bluetooth headphones are driven with a userspace plugin
<mjg59> crimsun: What's the right way to configure this? Have a bluetooth configuration program fiddle with .asoundrc?
<crimsun> mjg59: aside from the hciconfig/btsco stuff, it's probably best to invoke asoundconf to alter ~/.asoundrc.asoundconf
<mjg59> crimsun: The setup stuff will be dealt with via hal
<Lathiat> mmm http://lists.grok.org.uk/pipermail/full-disclosure/2006-July/047831.html
<mjg59> So the UI should call asoundconf when the user chooses to connect?
<Lathiat> is that what th ekernel update from yesterday was for?
<crimsun> mjg59: referring to the equiv of a2play/a2recv?
<Lathiat> ah yeh, was
<mjg59> crimsun: Not exactly
<mjg59> crimsun: So there'll be a GTK application which will show available bluetooth devices
<crimsun> ok
<crimsun> if the app has facilities to connect, etc., it shouldn't touch asoundrc
<mjg59> If a user chooses to bind to an a2dp device, we should just pair and then call asoundconf?
<mjg59> This is for session-wide setup
<mjg59> Rather than per-application setup
<crimsun> let me read the parameters for a2*
<mjg59> pcm_a2dp.c is the appropriate code in the btsco tree
<crimsun> I love sf.net
* crimsun tries another method
<crimsun> mjg59: ok, does this session-wide setup involve setting a default device?
<crimsun> mjg59: default -> system-wide, which would affect all sound
<bddebian> Howdy folks
<mjg59> crimsun: Nope
<crimsun> mjg59: if not (and I don't see why it would need to set default for the system), no setting of ~/.asoundrc* is necessary. At the most you'd need to pull the necessary info from ``asoundconf list'' to pass to whatever alsa app is handling the playback (aplay, gst, etc.)
<mjg59> crimsun: How does asoundconf know about the bluetooth device?
<crimsun> mjg59: it doesn't, it only parses /proc/asound/cards
<mjg59> crimsun: Right. So, how does that help? :)
<crimsun> mjg59: I'm just saying it doesn't have to touch ~/.asoundrc* at all :)
<mjg59> crimsun: But if it doesn't touch .asoundrc, nothing knows about the bluetooth device
<crimsun> mjg59: it doesn't need to touch .asoundrc to be available to other apps
<mjg59> crimsun: How do other apps know about it?
<crimsun> mjg59: the same way gst would handle it
<mjg59> crimsun: I'm afraid I don't understand
<mjg59> crimsun: I'm trying to work out how to pass this information to other applications
<crimsun> mjg59: ok. ``asoundconf list'' will enumerate the alsa device name strings, and you could pass one of them to whatever alsa-native app/lib is handling the connect
<mjg59> crimsun: But it gets device name strings from /proc/asound/cards?
<mjg59> If so, the bluetooth device isn't going to be in there
<crimsun> err, why not? It's an alsa device...
<mjg59> It's a userspace device
<mjg59> libalsa calls the plugin, it doesn't go through any kernel driver
<crimsun> so you want to know how to enumerate the addresses?
<mjg59> I have a bluetooth address that I know corresponds to a device that can be driven via alsa.
<mjg59> By putting something like:
<mjg59> pcm.headphone { type a2dp bdaddr 00:0D:44:2A:14:66
<mjg59> }
<mjg59> in .asoundrc, pcm.headphone is a valid alsa output
<crimsun> ah, and then you'd use headphone.
<crimsun> right.
<mjg59> Yes
<mjg59> So, should my application be doing that?
<crimsun> well, ideally it should be calling asoundconf, which means we need to extend asoundconf
<mjg59> Ok
<mjg59> Effectively, I just want to be able to add and remove headphone devices as necessary
<mjg59> And get the list of currently defined ones
<crimsun> ok, the caveat is that .asoundrc is only parsed per-startup
<mjg59> Application startup?
<crimsun> so I'm not sure how to handle the dynamic case
<crimsun> yes
<mjg59> Right. We'll worry about that later.
<mjg59> The docs seem to suggest that there's a different API for applications to get a list of asoundrc defined devies
<mjg59> So are any applications actually going to list the headphones?
<crimsun> yes
<mjg59> Ok, that's good
<bddebian> Heya Hobbsee
<Hobbsee> morning all
<Hobbsee> bddebian: :)
<zul> everning
<Hobbsee> hey zul :)
<bluefoxicy> Hobbsee:  wb.
<Hobbsee> hey bluefoxicy 
<Hobbsee> bluefoxicy: see, i'm awake!  and it's still before noon!
<Hobbsee> just
<bluefoxicy> haha
<bluefoxicy> I wouldn't know, it's 9pm here now :P
<Hobbsee> heh
<bluefoxicy> I am still fishing around for gcc developers trying to get one to walk me through altering this stack smash protection code
<Hobbsee> bluefoxicy: are they likely to be here?
<zul> good luck :)
<bluefoxicy> Hobbsee:  I have no idea, I've tried #gcc on oftc
<zul> i though there was a conference going on?
<bluefoxicy> I dunno.  What's a conference?
<bluefoxicy> Like when your teacher calls your parents and then you get a spanking later?
<zul> gcc developers summit
<bluefoxicy> oh.  Crud.  That means they're all too busy.
<zul> oops nope that was on the 30th never mind
<bluefoxicy> lol
<crimsun> err, d'oh, the [Ubuntu] Patches link on http://packages.qa.debian.org/$srcpkg is invalid. Need to ping keybuk about that.
<bddebian> bluefoxicy: Talk to drepper, I'm sure he'd be helpful :-)
<bluefoxicy> bddebian:  Ulrich?  I'm afraid he'll bite me.  He's from redhat, the thing I'm trying to put in they took out in the first place >:O
<bddebian> That was sarcasm :-)
<bluefoxicy> oh o.o
* Hobbsee notes that there's a patch she wants to get into main now, but UVF is in a few hours.  damn.
<Hobbsee> i wonder if the package got thru NEW anyway
<Hobbsee> ah, it has.  i have no sponsor.  dammit.
<bddebian> We have sponsors?
<Hobbsee> bddebian: to upload to main?  well, last i knew, i couldnt do it
<rodarvus> Hobbsee: what package and patch do you need sponsored?
<Hobbsee> rodarvus: looks like crimsun is sponsoring it.  thanks :)
<rodarvus> *nods*
* Hobbsee waves to rodarvus 
<rodarvus> :)
<crimsun> rodarvus: thanks for kicking ass with X.Org
<Hobbsee> crimsun: it's installable, go for it :)
<rodarvus> crimsun: believe it or not, I'm actually enjoying it :)
<bddebian> Heh
<Hobbsee> rodarvus: are you insane then?
<Hobbsee> :P
* bddebian doesn't mention fabbione 's sodomotron
<rodarvus> the sodomotron is passed from generation to generation
<zul> must...hold...tongue
<rodarvus> haha
<bddebian> Gah, mesa hasn't built yet :-(
* jsgotangco imagines rodarvus in leather with sodomotron in hand
<jsgotangco> *ickk*
<bddebian> "Bring out the gimp"
<Hobbsee> rodarvus: didnt notice that'd it'd been NEW'd to universe, and wasnt in main yet.  i should put my glasses on :P
<rodarvus> bddebian: mesa will start being built in the next few minutes (in some of the archs, at least)
<bddebian> rodarvus: thx
<rodarvus> bad news is that it takes 25 minutes to build mesa on i386
<bddebian> Aye
<stub> Launchpad will be going down in 15 minutes for its regular code update (delayed two days). Estimated down time is 10 minutes.
<bluefoxicy> refueling the oxygen tanks?
<Hobbsee> ah, just when i was going to request a sync.
* Hobbsee requests it anyway - it's not down yet.
<sharms> anyone read me -devel message?
<raphink> mdz: hi mdz
<raphink> if I'd like to request the sync of a package that is not in Ubuntu yet, how should I do it?
<raphink> (given that the package doesn't exist on LP yet)
<Hobbsee> raphink: where's it from?  debian experimental?
<raphink> nope, unstable
<raphink> but it was added only recently
<raphink> and I'm wondering if the automatic syncer is still on
<Hobbsee> raphink: it didnt autosync?  is it going into main, or what?
<Hobbsee> raphink: a few days ago i had that too - just request  a sync as normal, and subscribe the archive
<raphink> Hobbsee: we are in UVF, so the autosync shouldn't be on
<raphink> Hobbsee: and how do I request a sync on a package that is not in ubuntu yet?
<Hobbsee> raphink: yeah, just....
<crimsun> raphink: /j #launchpad, ask for the source package name to be added, then file the bug as usual
<Hobbsee> say please sync version this from here, it builds and installs fine on ubuntu, etc.
<raphink> crimsun: ok
<Hobbsee> (like in the developer docs)
<raphink> Hobbsee: you don't get the problem... there's no entry for this package on LP ;)
<Hobbsee> ah, yeah, that would work too
<Hobbsee> hehe - that's why i used "file a bug" link, and did it under generic ubuntu
<raphink> Hobbsee: and what package did you put it on?
<Hobbsee> raphink: https://launchpad.net/distros/ubuntu/+filebug from https://wiki.ubuntu.com/DeveloperResources
<raphink> ok
<raphink> ok thank you 
<fabbione> morning
<Mithrandir> morning, Fabio
<Hobbsee> hey fabbione, Mithrandir 
<mdz> raphink: automatic syncs were happening daily until today
<mdz> raphink: so unless it landed today, it's probably in the queue
<Mithrandir> morning, Hobbsee
<sivang> morning
<raphink> mdz: is there a place where we can see the autosyncs queue?
<raphink> shalom sivang
<Hobbsee> hi sivang 
<sivang> boker tov raphink 
<raphink> :)
<sivang> hey Hobbsee 
* sivang goes to dist-upgrade
<Hobbsee> sivang: good luck!
<sivang> Hobbsee: luck has nothing to do with it :)
<sivang> morning pygi 
<Hobbsee> heh, true
<sharms> Will the compromise of the debian core dev server gluck (http://lists.debian.org/debian-devel-announce/2006/07/msg00003.html) put a hold on syncs until damage is researched?
<Mithrandir> sharms: gluck is not part of the archive infrastructure in Debian, so I would be very surprised if so.
<StevenK> The archive has never been on gluck, from memory.
<StevenK> It's been auric, raff and merkel, right?
<sharms> Just was curious since if they compromised that machine if the collateral could reach out to archive
<Mithrandir> StevenK: not merkel, afaik.
<StevenK> The copy is on merkel
<Mithrandir> StevenK: there are copies all over the place, but that's hardly relevant. :-P
* StevenK nods.
<Mithrandir> there's a mirror on gluck too, afaik.
<StevenK> Ah
<StevenK> I certainly don't usually keep track as to what's on the d.o machines.
<StevenK> That's what we don't pay the DSA for.
<Mithrandir> sharms: most debian developers can't log in to spohr, aka ftp-master.debian.org so the chance of said machine being compromised is slim.
* ..[topic/#ubuntu-devel:Mithrandir] : Ubuntu Development (not support, even with edgy) | #ubuntu for support and general discussion | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/DeveloperResources | http://wiki.ubuntu.com/HelpingWithBugs | It's Merge Time! http://merges.ubuntu.com/ | Knot-1 freeze in effect - uploads to main frozen, ask Mithrandir for exceptions
<crimsun> Mithrandir: may I upload alsa-lib with the following patch applied?  http://tinyurl.com/qx92k
<crimsun> (it's used now that we have snd-aoa in the Edgy kernel)
<Mithrandir> crimsun: looks good, feel free to upload.
<crimsun> Mithrandir: thank you
<sivang> hmm
<sivang> Setting up xfonts-scalable (1.0.0-4) ...
<sivang> warning: /usr/lib/X11/fonts/Type1 does not exist or is not a directory
<fabbione> sivang: what's the first word?
<sivang> fabbione: /me checks
<sivang> fabbione: http://paste.ubuntu-nl.org/17894
<fabbione> sivang: in the message you did paste here in the channel.. what's the first word :)
<sivang> fabbione: "Setting" ? :-)
* sivang is not sure he follows
<Mithrandir> sivang: next line.  First word. :-P
<sivang> fabbione: "warning:" 
<pitti> Good morning
<fabbione> sivang: score....
<ivoks> pitti: 'morning
<sivang> fabbione: heh
<fabbione> sivang: warning != error...
<pitti> hey sivang 
<sivang> fabbione: indeed, you have a way of prooving people like the army here commanders here do :p
<sivang> s/here///
<sivang> Hi pitti !
<Hobbsee> hey pitti!
<fabbione> sivang: it's an effect of 3 years of air force
<sivang> fabbione: hehe
<mdz> raphink: there isn't a separate queue for it; they go into the normal upload queue(s)
<mdz> raphink: and no, those are not publicly viewable at present
<Kamion> mdz: my germinate output on rookery runs every hour at :02 based on the archive mirror on rookery (which IIRC updates every six hours); cron.germinate runs on drescher at :30 and anastacia updates at :35
<Kamion> mdz: so they can get sufficiently out of sync to be confusing, certainly
<pitti> hey dholbach 
<ogra> yo dholbach 
<dholbach> hey pitti - good morning
<dholbach> hey ogra
<jdub> mdz: interesting initramfs discussion in lwn this week
<mdz> jdub: interesting but inaccurate
<mdz> talk about it after the meeting
<ogra> dholbach, g-p-m will not be uploaded before polkit is in hal (mdz request), so there is plenty of time to fix the icons ... i'll move the package to rookery after the meeting
<jdub> mdz: cool
<dholbach> ah ok - cool
<Mithrandir> ogra: note that main is frozen ATM.
<ogra> Mithrandir, yes, i know ... adding plicy kit will take some days i guess 
<ogra> *policy
<ogra> so dont worry about the knot :)
<seb128> fabbione: 
<seb128> $ xvfb-run echo
<seb128> kill: 158: No such process
<seb128> fabbione: is that you I should bug about that? It breaks pygobject build by example ...
<fabbione> seb128: on what arch?
<seb128> i386
<fabbione> only? or is it everywhere?
<seb128> I don't have any one arch to try on
<seb128> that's on my desktop
<fabbione> it's probably due to the fonts breakage but please file a bug.. i will look at it either tomorrow or monday
<seb128> ok, thank you
<fabbione> seb128: that assume that i will still be around.. so please just subscribe the X SWAT to it
<fabbione> so that somebody else can look at it if my wife decides to give birth all of a sudden
<seb128> fabbione: ok, I might have a look myself on it after meeting, I'll let you know
<fabbione> seb128: xvfb-run is a perl wrapper script that passes some args and opts to the real xvfb
<fabbione> seb128: i suggest you just unroll what you are trying to do
<fabbione> and get to the real cmd line call to see
<seb128> ok, will do that, thank you
<fabbione> and from there get the error
<fabbione> also.. iirc xvfb expects an X client.. echo isn't
<pitti> moin carlos 
<carlos> hi
<seb128> fabbione: 
<seb128> "# Kill Xvfb now that the command has exited.
<seb128> kill $XVFBPID"
<seb128> that is the issue
<seb128> the Xvfb it tries to kill is not running
<fabbione> seb128: that's why you need to understand why it's not running
<Kamion> Keybuk: OOH queue has been fixed to tell us which items are new!
<Kamion>    70752 | -B | gfxboot (i386)       | 3.2.23-2ubuntu1      | 14 hours
<Kamion>          | * gfxboot/3.2.23-2ubuntu1/i386 Component: main Section: utils Priority: OPTIONAL
<Kamion>          | N gfxboot-theme-nld/3.2.23-2ubuntu1/i386 Component: main Section: utils Priority: OPTIONAL
<Kamion>          | N gfxboot-theme-sles/3.2.23-2ubuntu1/i386 Component: main Section: utils Priority: OPTIONAL
<Kamion>          | N gfxboot-theme-suse/3.2.23-2ubuntu1/i386 Component: main Section: utils Priority: OPTIONAL
<Kamion>          | * gfxboot_3.2.23-2ubuntu1_i386_translations.tar.gz Format: ROSETTA_TRANSLATIONS
<Keybuk> Kamion: they changed their rollout day?
<Kamion> dunno, but there it is
<fabbione> rodarvus: no you can't install parallel LP instances for other reasons. it's not just a matter of ports
<rodarvus> locking, I guess?
<Keybuk> I don't really see why you can't
<Keybuk> buildd slave isn't big
<rodarvus> all that should be configurable somewhere inside buildd (but of course I might be missing something obvious here)
<fabbione> Keybuk: different running users? path to chroots?
<Keybuk> fabbione: you could use the same chroots
<fabbione> Keybuk: the sbuild chroot inherits some stuff from the running user
<Keybuk> probably even run as the same user
<fabbione> Keybuk: no you can't. sbuildd will go nuts
<Keybuk> no it won't
<Keybuk> chroots are unpacked anew for each build in LP
<Keybuk> not reused
<fabbione> if you want to run 32 instances of sbuild as the same user in LP, you will have issues
<fabbione> stuff needs to be designed to do so
<pitti> doko: that's the fixed gcc for powerpc? :)
<doko> pitti: yes, so slomo__ could check as well
<pitti> slomo__: ^ this could interest you as well (deb http://people.ubuntu.com/~doko/gcc-powerpc/ ./)
<pitti> doko: so this is just blocked on infinity now
<lucas> I'm preparing an announcement to ask users to participate in popcon
<lucas> can somebody review https://wiki.ubuntu.com/LucasNussbaum/PopconDraft ?
<lucas> (feel free to edit it)
<ogra> seb128, can you tell me what to do to debug gstreamer stuff (bug 52815)
<Ubugtu> Malone bug 52815 in gst-plugins "logitech usb headset sound output dies after 1 minute" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52815
<ogra> seems the documented way doesnt work
<seb128> ogra: GST_DEBUG_NO_COLOR=1 GST_DEBUG=*:5 app ?
<seb128> maybe try with DEBUG to 3 first if that's enough
<seb128> 5 tends to be really verbose
<ogra> ah, env vars ... didnt think of that :) will try, thanks
<seb128> np
<pitti> ogra: I use something like: gst-launch-0.10 --gst-debug=autodetect:5 filesrc location=/usr/share/sounds/generic.wav ! wavparse ! autoaudiosink
<pitti> Pausiere Leitung ...
<ogra> pausiere ?
<ogra> lol
<pitti> ogra: --gst-debug and its help are pretty helpful
<pitti> ogra: (sorry, too much pasted)
<ogra> i laughed about the translation :)
<seb128> pitti: GST_DEBUG=*:5 does the same ...
<pitti> yep
<pitti> Mithrandir: sorry for the squid upload 10 minutes after the freeze begun, I saw it too late; however, it doesn't affect the CDs
<Mithrandir> pitti: np.
<Kamion> Selecting previously deselected package initramfs-tools.
<Kamion> Unpacking initramfs-tools (from .../initramfs-tools_0.69ubuntu1_all.deb) ...
<Kamion> cp: target `/etc/initramfs-tools/' is not a directory: No such file or directory
<Kamion> dpkg: error processing var/cache/apt/archives/initramfs-tools_0.69ubuntu1_all.deb (--unpack):
<Kamion>  subprocess pre-installation script returned error exit status 1
<Kamion> can somebody fix that please? affects edgy debootstrap
<fabbione> score
<Kamion> (so that's on fresh install)
<Keybuk> Kamion: I'll fix it in a little bit
<hendry> is it possible to downgrade from edgy to dapper?
<Mithrandir> hendry: not supported.  Might work.  But this is not a support channel, sorry.
<Kamion> pitti: I've promoted libpci2 to main because pciutils depends on it; it was just split out from pciutils so I didn't think it needed a MIR
<pitti> Kamion: agreed
<\sh> hmm..bugfixes don't need an upload approval, right?
<hendry> Mithrandir: sorry, wrong channel.
<pitti> \sh: right now they do
<Mithrandir> \sh: uploads to main need approval.
<\sh> Mithrandir: ok..I need to upload a fix to ktorrent
<Mithrandir> \sh: well, I need to see the diff to evaluate it.
<\sh> Mithrandir: I'll send an email or should I file a bug report to LP for it?
<Mithrandir> just putting the diff somewhere and asking me is the, by far, quickest way.
<rodarvus> iwj: gmail (and other sites) won't recognize current firefox - is this a known issue, or is happening only to me?
<\sh> Mithrandir: cool...
<iwj> rodarvus: I don't know.
<iwj> I don't use any sites that do any of that kind of nonsense.
<rodarvus> :)
<iwj> rodarvus: But I wouldn't rule out having broken it; there was some tangle in merge in the area of the browser id string.
<Kamion> Keybuk: actually I'll do it now unless you've already started it
<Kamion> it's blocking me and I see the fix
<rodarvus> iwj: how do I check the browser id string locally? (and if it is "valid"?)
<pitti> rodarvus: try 'about:'
<iwj> In the help menu.
<pitti> or that
<rodarvus> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Ubuntu/edgy Firefox/1.5.0.4
<rodarvus> I suppose its correct?
<rodarvus> can't find anything strange there
<Mithrandir> mdz: so, what do we do about infinity being ill and fakeroot/gcc needing manual bootstrapping?
* dholbach has Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060608 Ubuntu/dapper-security Firefox/1.5.0.4
<iwj> Hmm.  Lack of Gecko.
<mdz> Mithrandir: we create a backup for him, which we needed to do anyway
<iwj> rodarvus: I'll look into it.
<rodarvus> iwj: thanks!
<Kamion> so where did initramfs-tools 0.69 come from?
<ogra> jbailey ?
<mdz> Kamion: from jbailey
<Kamion> it's not in Debian or Debian incoming, and I can't see it anywhere on spohr
<mdz> unexpectedly
<Kamion> no, 0.69ubuntu1 came from jbailey
<mdz> oh, maybe from revision control then
<Kamion> must've been
<lucas> What's the procedure for sending stuff to ubuntu-devel-announce ?
* Kamion trudges off to svn.d.o
<Kamion> lucas: it's a moderated list, just mail it; it should be relevant to a fairly wide swathe of the development community
<lucas> ok
<lucas> can you have a look at https://wiki.ubuntu.com/LucasNussbaum/PopconDraft ?
<Kamion> looks reasonable for u-d-a to me
<lucas> thanks
<sivang> Keybuk: any chance you might have time to read my fixes to the system clean up tool and see if you're happy with it today?
<sivang> Keybuk: (to the spec, that is(
<Kamion> ah, initramfs-tools is in bzr, good
<mdz> doko: do you know what's going on here? http://librarian.launchpad.net/3376004/buildlog_ubuntu-edgy-i386.gnucash_2.0.0-1_FAILEDTOBUILD.txt.gz
<Keybuk> sivang: yes, I will have time today
<pitti> funny, with every dist-upgrade my fonts look a magnitude worse
<sivang> Keybuk: thanks again :)
<pitti> now I get a 6 pt Courier font in gnome-terminal
<lucas> somebody know something about planet.ubuntu.com ? the website says jdub is responsible for it, but he didn't answer my email. is he still the one in charge ?
<doko> mdz: hmm, the build-deps install fine for me at the moment, maybe the hardcoded python2.3-dev b-d? hmm, universe anyway
<jdub> lucas: sorry for not replying straight away - i've added you to my local config, but not updated the site (i'm upgrading it atm)
<lucas> jdub: oh ok
<lucas> jdub: (I mailed you 3 weeks ago, that's why I wondered)
<heno> jdub: is that planet you're referring to?
<jdub> heno: yeah - same for you :-)
* heno is lined up too :)
<heno> jdub: ok, thanks :)
<fabbione> Keybuk: dpkg-shlibdeps: warning: unable to find dependency information for shared library libvolume_id (soname 0, path libvolume_id.so.0, dependency field Depends)
<lucas> Kamion: popcon message sent to u-d-a ; held waiting for approval
* fabbione will bbl
<Mithrandir> Kamion: if a distrorelease is set to frozen as per MilestoneRhythm, what happens with uploads?  Have to be processed manually by you or scott?
<Keybuk> Mithrandir: right
<seb128> Keybuk: could you give a build retry to  gnome-python-desktop 2.15.4-0ubuntu1 on !i386?
<Mithrandir> but how do I (or somebody else) mark it as frozen?
<Keybuk> Mithrandir: only TB can mark it frozen
<Keybuk> and, frankly, right now, I'd rather we didn't
<Keybuk> afaik, frozen means even binaries have to be approved
<Keybuk> and the buildds are still doing the last mass give-back
<Mithrandir> we should, according to milestonerhythm.
<Mithrandir> ew, ok.
<Keybuk> seb128: gnome-python-desktop 2.15.4-0ubuntu1 - powerpc ia64 sparc amd64
<seb128> Keybuk: thank you
<Keybuk> Mithrandir: tbh, if you ask me, now is not a good time to be trying to do a milestone ;)
<Mithrandir> Keybuk: it's never a good time to do a milestone.  We still need to do them.
<Kamion> Keybuk: for the record I'm pretty sure binaries go through despite frozen status
<seb128> Mithrandir: not really true, we don't always have that many changes running and installability issues on the same time
<Kamion> I believe it only affects sourceful uploads
<dholbach> Mithrandir: sorry, I didn't ask. I just uploaded metacity to fix an upgrade issue and liboobs, which will make the new gnome-system-tools stack installable
<Mithrandir> dholbach: ok, that's good, but please ask next time. :-)
<dholbach> yeah
<Mithrandir> seb128: there are bad and very bad times, agreed. :-)
<pitti> Mithrandir: if you need a hand with fixing edgy_probs, feel free to ping me
<pitti> Mithrandir: I do some security updates now, but they aren't particularly urgent, so I can help a bit with fixing installability issues if needed
<Keybuk> Kamion: actually, that would make sense ... we don't need to manually approve dapper's binaries, do we?
<fabbione> re
<Keybuk> hmm
<Keybuk> I can't find where to mark it frozen anyway
<Keybuk> maybe it's an lp_admin thing
<pitti> crimsun: did you ever reupload openvpn for -security? it's not in the queue
<crimsun> pitti: I did, and it was failed
<pitti> crimsun: oh, ok; let me upload it then to get this out
<crimsun> pitti: same key issue, waiting for key to be refreshed (same key that I use for Edgy uploads)
<fabbione> Mithrandir, Kamion: FYI: i am looking at mesa fix right now for Knot-1
<Kamion> Mithrandir: need a base-installer fix for the moved initramfs-tools configuration directory; ok to upload?
<pitti> crimsun: ok, uploaded; I'll release it later today when it's built
<crimsun> pitti: many thanks.
* dholbach hugs crimsun and pitti
<Mithrandir> Kamion: please.
<Mithrandir> fabbione: coolie.
<slomo__> doko: fixes the mono breakage for me :)
<Keybuk> doko: so, 64-bit OO.o for edgy?
<doko> slomo__: just by installing libgcc1, or by rebuilding?
<doko> Keybuk: are you volunteering?
<slomo__> doko: installing... but rebuilding against it works too (but mono has to be give-back nontheless on ppc)
<doko> Keybuk: it currently builds, but without java support
<Keybuk> doko: FC are allegedly shipping it
<pitti> hi janimo 
<janimo> pitti hi
<janimo> pitti, thanks for merge of pcre3
<pitti> janimo: no problem
<janimo> Kamion: can you move thunar-archive-plugin to main? I put it in the xubuntu desktop seed yesterday, but does  not show up in anastacia. thanks
<crimsun> janimo: darren salt released 0.5.7 and advised us to use that with additional patches from hg; I prefer to wait until he NMUs 0.5.7 into Debian so we can avoid the mismatched orig.tar.gz issue
<crimsun> janimo: (RE: gxine)
<janimo> crimsun: I agree. thanks for taking care of this :)
<janimo> xfmedia has seen some patches today, but still better to bet on gxine for now
<crimsun> ok
<Kamion> janimo: done
<ogra> seb128, g-s-t doesnt find its dbus service, known bug ? 
<seb128> ogra: g-s-t?
<ogra> gnome-settings-daemon
<seb128> what version do you have? what -admin are you running?
<ogra> -admin ?
<seb128> g-s-t = gnome-system-tools for me
<ogra> ah
<seb128> g-s-d = gnome-settings-daemon
<ogra> eek, sorry, indeed
<ogra> g-s-d is in gnome-session, right ? 
<seb128> ogra: do you have a /usr/share/dbus-1/services/org.gnome.SettingsDaemon.service ?
<seb128> ogra: no gnome-control-center
<seb128> capplets-data should ship /usr/share/dbus-1/services/org.gnome.SettingsDaemon.service
<ogra> nope, its missing
<seb128> ogra: what version of capplets-data do you have?
<Kagou> hi
<seb128> lu Kagou
<Kagou> lu seb128 
<ogra> seb128, 2.14.2-0ubuntu1
<seb128> ogra: upgrade to 2.15.4 ?
<ogra> wasnt offered, i just upgraded
<seb128> ogra: what version of gnome-control-center do you have?
<ogra> (ppc here)
<ogra> the matching version
<ogra> 2.14.2-0ubuntu1
<seb128> interesting 
<seb128> that version doesn't use dbus :p
<ogra> hmm
<seb128> the message might be from gnome-session
<seb128> what version of gnome-session do you have?
<seb128> gnome-session and gnome-control-center should be updated together
<ogra> that was updated ... one sec
<seb128> ok, that's the issue then
<ogra> 2.15.4-0ubuntu1
<ogra> oki
<ogra> then i'll just wait for LP :)
<seb128> we really need that Breaks dpkg feature :p
<ogra> heh, yes
<seb128> new gnome-session run gnome-settings-daemon by dbus instead of using libbobono for it
<Mithrandir> doko: did you see my msg?
<pitti> Mithrandir: ok to upload a libtunepimp security update? (no api changes, just fixing array size)
<ogra> seb128, wow, cool
<seb128> atm you have a gnome-session speaking dbus and gnome-control-center not
<Mithrandir> pitti: please go ahead
<ogra> yup
<seb128> will be fixed when you upgrade g-c-c
<seb128> note that gnome-vfs speaks over dbus now too ;)
<Kamion> ok, most painful debootstrap ever, but I think it's working now
<ogra> oh, intresting ... i can upgrade g-c-c ... its just not in apt-get upgrade 
<seb128> what does it want to break?
<ogra> nothing, it adds three new packages
<Kamion> E: Tree walking failed - ftw (38 Function not implemented)
<ogra> libgnome-window-settings1 libxklavier11 metacity-common
<Kamion> wtf
<seb128> ogra: upgrade should not stop due to new packages to install, no?
<Amaranth> apt-get upgrade won't install new things
<seb128> ogra: ah, libxklavier11 will remove libklavier10 no?
<ogra> seb128, as Amaranth says
<seb128> Amaranth: are you sure?
<ogra> dunno, i didnt get that far :P
<ogra> metacity-common is missing a conflicts
<doko> Mithrandir: no?
<seb128> I thought it would not remove things, no reason to not install a new -common
<Kamion> seb128: he's right
<Kamion> read the docs
<seb128> ogra: already fixed
<ogra> seb128, /usr/share/man/man1/metacity-theme-viewer.1.gz ?
<Kamion> "under no circumstances are currently installed packages removed, or packages not already installed retrieved and installed"
<Amaranth> upgrade is "safe" :)
<ogra> yeah
<seb128> Amaranth: installing a new -common is something I consider as "safe"
<ogra> for some (very small) value of safe
<seb128> Kamion: right, thank you for pointing it ;)
<Kamion> you want apt to special case strstr(package_name, "common")? :-P
<seb128> ogra: 
<seb128>  metacity (1:2.15.8-0ubuntu3) edgy; urgency=low
<seb128>  .
<seb128>    * debian/control.in:
<seb128>      - fixed upgradeability again.
<ogra> oki :)
<Amaranth> Do It:)
<seb128> Kamion: no no, I just use dist-upgrade and I'm fine with it ;)
<ogra> seb128, a "yes" would suffice, no need for a whole copy/paste and digging in changelogs :)
<seb128> ogra: thanks to dholbach who fixed it ;)
<dholbach> (and broked it in the first place) :-p
<seb128> ogra: it was not really "digging", it's on the first screen of edgy-changes mails atm :p
<ogra> *g*
<ogra> trhats what edgy is for :)
<Kamion> oh, apt-ftparchive needs /proc mounted
<seb128> it was to indicate the fixed version too ;)
<seb128> dholbach: gnome-python-desktop built on amd64 now ;)
<ogra> Kamion, everything seems to need proc mounted nowadays ...
<dholbach> seb128: nice
<ogra> chroots, pbuilder ...
<seb128> Keybuk: could you give a retry gnome-applets and gedit on !i386 when  gnome-python-desktop 2.15.4-0ubuntu1 is available for them?
<dholbach> hum, lp says that the new system-tools-backends is published, but it's not up for grabs, making liboobs wait on it, which is needed for gnome-system-tools
<Kamion> janimo: anastacia not listing thunar-archive-plugin was my fault; I'd forgotten to add it to the list of stuff pulled to ~cjwatson/seeds/
<Kamion> (ok, so that's not quite entirely informational - germinate still defaults to pulling stuff from there)
<Kamion> fixed now
<ogra> did anybody elses pbuilder break with the last upgrade ? 
<ogra> E: failed to find /var/cache/pbuilder/base.tgz, have you done <pbuilder create> to create your base tarball yet?
<ogra> and its right, apparently base.tgz is gone :(
<pitti> me, dchroot broke after current update
<crimsun> are ia64 and sparc known to be failing to build stuff currently?
<janimo> Mithrandir: exception request for two xfce upload to main (a bugfix and including a new app in the default desktop)
<ogra> grumble, grumble ... it apparently ignored that /var/cache/pbuilder is a symlink on my system and just overwrote the dir 
<Mithrandir> janimo: diff?
<janimo> Mithrandir: a second
<janimo> Mithrandir: http://bugzilla.xfce.org/attachment.cgi?id=661&action=view this is against the xfce wm from upstream
<Kamion> Mithrandir: ok to upload d-i amd64 build fix, I assume?
<janimo> the diff for xubutu-desktop is adding thunar-archive-plugin
<Kamion> is just s/8000/16000/ on the netboot boot.img size
<Mithrandir> janimo: ok, go ahead.
<Mithrandir> Kamion: absolutely, go ahead.
<doko> Mithrandir: prepared schoolbell/schooltool to make them installable again (needed for edubuntu main). ok to upload?
<Mithrandir> doko: please
<janimo> Mithrandir: ok, uploading the fix now, the xubuntu-desktop will take a while
<ogra> yay !!
<ogra> doko, thanks so much :)
<Mithrandir> I need to go out for a little bit to pick up a new monitor.  The postal service was unable to deliver it yesterday 'cause of "address not found".
<pitti> Mithrandir: stop writing your IP address on parcels then :)
<ogra> lol
<ogra> pitti, they would probably find the ipv4 one, but he always uses v6  :)
<pitti> ogra: PLZv6?
<fabbione> hehe
<ogra> lol
<pitti> (for the non-German ones: PLZ = postal code)
<ogra> I: Unpacking wpasupplicant...
<ogra> W: Failure while installing base packages.  This will be re-attempted up to five
* ogra cries 
<imbrandon> lol
<\sh> Mithrandir: http://archive.linux-server.org/ktorrent_1.2-1ubuntu2-to-1.2-1ubuntu3.debdiff can you have a look for ktorrent debdiff? thx :)
<ogra> pbuilder wipes itself ... and is not able to create a new chroot ... oooohhh fun
<Kamion> ogra: I've uploaded fixes for all the problems I'm aware of; I suggest waiting a bit
<Kamion> if that's edgy
<ogra> Kagou, yep, thanks
<Kamion> it's not pbuilder's fault
<ogra> Kamion, that my base.tgz disappeared after an upgrade ? 
<Kamion> "and is not able to create a new chroot"
<Kagou> ogra: you'r welcome :)
<ogra> Kagou, heh, sorry :)
<ogra> Kamion, btw it complained about aptitude (missing libapt-pkg-libc6.3-6-3.11), ubuntu-minimal (initramfs-tools) and udev (initramfs-tools (>= 0.40ubuntu30)) in case anything of these isnt on your radar yet
<fabbione> Mithrandir: ping?
<pitti> iwj: ping
<fabbione> oh he went out
<fabbione> Kamion: perhaps you can help me instead.. other than the lesstif B-D in mesa.. is there anything else that needs to be done for it?
<fabbione> Kamion: if not, i am ready to upload ubuntu2 with the lesstiff fix
<ogra> hmm, looks like i have sivangs bug ... no ALT key combos seem to work ...
<janimo> Kamion: could the update scripts in the ubuntu-meta packages not use the http instead of the sftp url? asking for passwd is I minor annoyance :)
<tseng> janimo: ssh keys are the way of the future.
<sivang> ogra: sudo gconf-schemas --register /usr/share/gconf/schemas/metacity.schemas
<sivang> ogra: just when I thought I was going crazy :)
<Mithrandir> \sh: looks innocent enough to me, feel free to upload
<\sh> Mithrandir: thx
<fabbione> Mithrandir: ah here you are
<fabbione> Mithrandir: ^^^ about mesa
<Mithrandir> fabbione: what's the lesstif fix?
<Keybuk> seb128: gnome-python-desktop still FTBFS on ia64
<fabbione> Mithrandir: it's removing the B-D and Depends: and one line that tells debian/rules to build the libGLw target. Ported from the dapper package
<fabbione> 3 lines change
<Kamion> ogra: aptitude is powerpc-specific, and I'm guessing it's due to the gcc breakage which needs manual bootstrap by a buildd admin
<seb128> Keybuk: looks like lot of things are not happy on ia64
<Mithrandir> fabbione: ok, go ahead.
<fabbione> Mithrandir: oh well to drop B-D on lesstif-dev basically.. as required by mdz and policy to not have lesstif in main
<ogra> Kamion, ok
<Kamion> fabbione: not to my knowledge, but I don't know much in this case
<fabbione> Kamion: ok.. just making sure.
<Keybuk> if only APT gave useful output, instead of it's "oh, I give up" style
<fabbione> thanks 
<Kamion> janimo: not until the 15/20-minute delay on sftp->http propagation on bazaar.launchpad.net is fixed
<Kamion> janimo: in the meantime, use an ssh-agent
<Kamion> ssh-agent is probably already running for you, so just type 'ssh-add'
<lifeless> Kamion: it may get reduced, will never be eliminated
<seb128> http://librarian.launchpad.net/3391601/buildlog_ubuntu-edgy-ia64.pygtk_2.9.3-0ubuntu1_FAILEDTOBUILD.txt.gz
<seb128> "checking for /usr/bin/python2.4 extension module directory... ${exec_prefix}/lib/python2.4/site-packages
<seb128> checking for headers required to compile python extensions... not found
<seb128> configure: error: could not find Python headers
<seb128> make: *** [build-2.4/configure-stamp]  Error 1"
<seb128> weird, it does that only on ia64
<Kamion> lifeless: I see no reason why it couldn't notice a push and do the propagation straight away
<Kamion> in principle
<seb128> any chance that's python being bugged on ia64? :p
<seb128> python-dev is installed
<Keybuk> seb128: gnome-python FTBS on ia64 too?
<seb128> Keybuk: pygtk
<seb128> looking at gnome-python, sec
<lifeless> Kamion: that would still be a delay ;)
<seb128>   python-gtk2-dev: Depends: python-gtk2 (>= 2.9.3-0ubuntu1) but it is not going to be installed
<seb128> right
* Keybuk looks on hooker
<dholbach> Mithrandir: ok to upload liboobs (added build-dep)?
<seb128> pygtk not building breaks gnome-python
<seb128> and gnome-python-desktop
<Keybuk> http://librarian.launchpad.net/3391601/buildlog_ubuntu-edgy-ia64.pygtk_2.9.3-0ubuntu1_FAILEDTOBUILD.txt.gz
<Keybuk> pygtk failed too
<Kamion> lifeless: negligible, though
<seb128> Keybuk: what I copied 10 lines up
<Keybuk> right
<Keybuk> Setting up python-dev (2.4.3-5ubuntu1) ...
<Kamion> lifeless: (and, in theory, bzr push could be made to block until it's finished, if it were happening immediately)
<seb128> python-dev is being installed
<seb128> I blame python
<lifeless> Kamion: well, for concurrency sanity, and also security, the http mirror pulls into it
<seb128> Keybuk: having the config.log from an ia64 build could be useful
<seb128> or an ia64 chroot with the Build-Depends for pygtk installed to try
<Keybuk> seb128: I don't have access to the buildds
<lifeless> so you have record the commit on the sftp side, queue a pull, wait for the next cron instance, then pull, record the pull, then notice the pull and unblock the client
<lifeless> I think thats a bad thing
<lifeless> overly complex.
<Mithrandir> dholbach: didn't you do that three hours ago?
<dholbach> Mithrandir: no, i didn't add the build-dependency that time.
<seb128> Keybuk: I'll mail rt@admin.canonical.com then
<Mithrandir> dholbach: ok, please upload.
<Kamion> lifeless: I was not aware you were doing the http pull as two different users, but you could use something like userv to request that the pull happen immediately rather than doing silly cron tricks
<Kamion> as a different user, I mean
<lifeless> Kamion: two different machines
* Kamion introduces lifeless to ssh
<dholbach> Mithrandir: gracias. done.
<Keybuk> seb128: what headers does that look for?
<lifeless> Kamion: meet the separation of concerns I raised.
<Kamion> even easier
<dholbach> when it has built, we need to give back gnome-system-tools and should be fine then
<Kamion> lifeless: xmlrpc or whatever. anyway, you're raising implementation details. it doesn't seem fundamentally impossible.
<seb128> Keybuk: configure.in uses "AM_CHECK_PYTHON_HEADERS(,[AC_MSG_ERROR(could not find Python headers)] )"
<Keybuk> seb128: right, but what does AM_CHECK_PYTHON_HEADERS do?
<janimo> tseng ssh keys need passwords (and I know about ssh-agent too), but still plain http is easier, not to mention non-core devs can play with their own versions of the metapackages
<lifeless> Kamion: its a non trivial thing to balance all the considerations.
<seb128> Keybuk: #include <Python.h> apparently
<Keybuk> -rw-r--r-- root/root      4178 2006-07-04 21:22:40 ./usr/include/python2.4/Python.h
<Keybuk> that's in the ia64 python2.4-dev
<lifeless> Kamion: unless/until we rate the latency problem as hugely higher priority than it is now, its not going to happen.
<seb128> we need the config.log
<Keybuk> where does it get the -I from?
<Kamion> janimo: that would be why seed_base is configurable in update.cfg
<Keybuk> seb128: I don't know of any way of getting the config.log, except trying it on an ia64
<seb128> PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
<Kamion> so that non-core-devs can play with local versions
<janimo> Kamion: ok, must have missed that
<Kamion> lifeless: and therefore we will continue to use the sftp url for the foreseeable future
<lifeless> Kamion: sure, thats completely fine by me. I never suggested that you should not.
<seb128> Keybuk: right, that's why I want to mail rt@admin.canonical.com to get the Build-Depends on ia64 dchroot to try it :)
<Keybuk> right
<seb128> Keybuk: configure does that
<seb128> py_prefix=`$PYTHON -c "import sys; print sys.prefix"`
<seb128> py_exec_prefix=`$PYTHON -c "import sys; print sys.exec_prefix"`
<seb128> PYTHON_INCLUDES="-I${py_prefix}/include/python${PYTHON_VERSION}"
<Kamion> janimo: but I recommend you leave it at sftp by default, otherwise we'll have weird issues of the form "but I already made that seed commit, why doesn't update notice it?"
<Kamion> up to you though
<Keybuk> seb128: where does it get PYTHON_VERSION from?
<Keybuk> oh, NM, it says 2.4 in the build log anyway
<seb128> Keybuk:   am_cv_python_version=`$PYTHON -c "import sys; print sys.version[:3] "`
<seb128> right
<Kamion> Keybuk: please give-back xfonts-base, xfonts-75dpi, xfonts-100dpi - they should build now that we have the newer xfonts-utils
<janimo> Kamion: well commits are from a seed checkout while update runs form a package souyrce, they should not be easily mixable
<iwj> pitti: pong
<seb128> Keybuk: ah, nice, halley has the required Build-Depends, no need to mail :)
<janimo> assuming the 15 minutre lag is fixed of course
<Keybuk> seb128: could that they've been found, but fail to #include, of course
<Kamion> janimo: sounds like the lag won't be fixed though
<seb128> Keybuk: /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
<Keybuk> seb128: yup
<seb128> breaks on that
<Keybuk> just noticed that myself
<Keybuk> and I've seen that error before earlier
<Keybuk> it's why most builds are failing on ia64 atm
<Kamion> janimo: it's common enough to do a commit and then almost immediately go and do a metapackage update
<seb128> I've noticed that on some other GNOME buids too
<seb128> ok
<Keybuk> xfonts-base 1:1.0.0-3 - i386
<Keybuk> xfonts-75dpi 1:1.0.0-2 - i386
<Keybuk> xfonts-100dpi 1:1.0.0-2 - i386
<Keybuk> Kamion: ^
<Kamion> Keybuk: yes, also unifont 1:1.0-3 i386
<Keybuk> seb128: I blame jbailey
<Keybuk> unifont 1:1.0-3 - i386
<janimo> well in that case it's an improvement over dapper when I was used to wait until the seeds got mirrored on rookery. It's just that got used to running update and going away until it finishes and now it asks for pwd. I'll get used to it or use the agent.
<seb128> Keybuk: me too
<Kamion> using an agent does generally make my life enormously easier I find
<Keybuk> seb128: all of /usr/include/asm is missing
<Kamion> but if you don't mind waiting, change the seed_base in the edgy/bzr section
<seb128> Keybuk: you are going to fix it or should we wait for jbailey?
<Kamion> the supermirror sftp->http delay is approximately the same as the commit->rookery-mirror delay
<seb128> I would prefer not to touch that package if not required :p
<Kamion> not the same cron job, but similar frequencies
<Keybuk> seb128: jbailey did very nasty things with this l-k-h release
<Keybuk> he basically dropped all our patches
<Keybuk> I elect to wait for him to wake up, which won't be too long
<seb128> works for me :)
<crimsun> ah, that explains the ftbfs on sparc and ia64 for alsa-lib
<seb128> I'll have lunch for now then
<Keybuk> crimsun: yeah, it's broken on sparc too
<Keybuk> crimsun: I actually don't understand why it's not broken on i386
<pitti> iwj: got my /msg? (no hurry, just want to make sure that /msg works)
<iwj> pitti: Yes.
<fabbione> crimsun: what package is failing?
<fabbione> (on sparc)
<Keybuk> oh
<Keybuk> it is broken on i386
<Keybuk> fabbione: all.
<fabbione> Keybuk: is it at the -m64 stage that breaks?
<fabbione> because i noticed something strange building libcman 64bit on sparc that includes where missing or broken
<Keybuk> fabbione: /usr/include/asm is missing
<Keybuk> I think this isn't l-k-h related though
<Keybuk> but toolchain
<fabbione> score
<Keybuk> the l-k-h packages look correct
<fabbione> jbailey will be around soon enough to ask
<Keybuk> /usr/include/ia64-linux-gnu/asm exists
<fabbione> iirc there should be a symlink from usr/include
<Keybuk> no, there shouldn't
<Keybuk> multi-arch, innit
<fabbione> than something else is wrong
<Keybuk> like I said, toolchain
* Keybuk tries to remember how to get gcc to reveal the default -I path
<Kamion> is ia64-linux-gnu actually the triplet?
<fabbione> probably gcc default -I paths?
<Kamion> just checking ...
<Keybuk> Kamion: that's what gcc is using for the lib search path
<Kamion> Keybuk: gcc -v
<Kamion> except not
<Keybuk> Kamion: right, it's not there :p
<Keybuk> Target: ia64-linux-gnu
<Keybuk> though
<Keybuk> it's not in -print-search-dirs either
<Kamion> gcc -v -xc -E /dev/null
<Kamion> oh ok
<Keybuk> cpp -v obviously
<Keybuk>  /usr/local/include
<Keybuk>  /usr/lib/gcc/ia64-linux-gnu/4.1.2/include
<Keybuk>  /usr/include
<Keybuk> ignoring nonexistent directory "/usr/lib/gcc/ia64-linux-gnu/4.1.2/../../../../ia64-linux-gnu/include"
<Keybuk> it's missing /usr/include/$triplet
<Kamion> was that ever in there?
<Kinnison> Not on dapper i386 it's not
<fabbione> it is on i386
<fabbione>  /usr/include/i486-linux-gnu
<fabbione> (edgy)
<Mithrandir> Keybuk: can you give-back gcj-4.1 on sparc and amd64, please?
<Keybuk> Mithrandir: this is all your fault :p
<Kamion> powerpc has:
<Kamion> lrwxrwxrwx root/root         0 2006-07-12 04:27:48 ./usr/include/ppc64-linux-gnu/asm -> ../powerpc-linux-gnu/asm
<Keybuk> Kamion: right, that's fine
<Kamion> oh no that's just powerpc/ppc64
<Keybuk> Kamion: amd64 looks fine too
<Keybuk> I can't login to faure for some reason
<Mithrandir> Riddell: you might want to do a MIR for apt-index-watcher so debtags becomes installable again.
<Riddell> Mithrandir: I actually had this in my irssi edit line ready to press enter   Kamion: could you move apt-index-watcher to main?  source is already in main, needed for debtags/adept
<Mithrandir> Riddell: heh, ok
<pitti> Mithrandir: permission to upload a new l-r-m to add the missing /usr/lib32/nvidia directory to the nvidia-glx package? that will fix the ia32-libs uninstallability if nvidia-glx is installed
<Kamion> sure, after this publisher run
<Mithrandir> pitti: please.
<Mithrandir> Keybuk: please give-back epiphany-browser on amd64 and sparc (and maybe ia64, but ia64 seems busticated)
<Keybuk> actually, I'm not sure about amd64
<Keybuk> gcj-4.1 4.1.1-8ubuntu1 - powerpc amd64
<Keybuk> Mithrandir: YES, AND IT'S ALL YOUR FAULT
<Keybuk> you and your oh-so-shiny "multi-arch" :p
<Keybuk> epiphany-browser 2.15.4-0ubuntu1 - ia64 sparc amd64
<Mithrandir> Keybuk: how is fakeroot being broken on amd64 some days ago my fault?
<Keybuk> Mithrandir: linux-kernel-headers being broken => your fault
<Kamion> he means ia64
<Keybuk> "ia64 being busticated"
<Mithrandir> Keybuk: *shrug*; I don't care much about ia64 ATM.
<Keybuk> Mithrandir: do you care about amd64? :p
<Mithrandir> it's a port architecture which nobody seems to care much about.
<Mithrandir> Keybuk: yes, I do.
<Keybuk> Mithrandir: that one's broken too
<Keybuk> afaict
<Riddell> Kamion: why would kdelibs-bin appear in edgy_probs.html?  it's a package that no longer exists in edgy and kdelibs4c2a Provides it
<Mithrandir> Keybuk: it seems to build most stuff fine, thoug.
<Keybuk> Mithrandir: do you have an up to date edgy chroot?  if so, can you run cpp -v and give the include search path?
<Mithrandir>  /usr/local/include
<Mithrandir>  /usr/lib/gcc/x86_64-linux-gnu/4.1.2/include
<Mithrandir>  /usr/include/x86_64-linux-gnu
<Mithrandir>  /usr/include
<Mithrandir> looks fine to me?
<Keybuk> ok, the "/usr/include/x86_64-linux-gnu" must have been added recently?
<Mithrandir> no idea; ask doko?
<Keybuk> doko appears to be hiding <g>
<Mithrandir> Keybuk: please give-back evolution-exchange on amd64, sparc
<Keybuk> oh, interesting
* Keybuk wonders what the last version of gcc that actually _built_ on ia64 and sparc was
<Keybuk> ../../../src/libiberty/cplus-dem.c:1: warning: -fstack-protector not supported for this target
<doko> Mithrandir: won't help, we really need to fix fakeroot first.
<fabbione> Keybuk: sparc is the same as all the others.. 
<fabbione> libstdc++6_4.1.1-8ubuntu1_sparc.deb
<Keybuk> ../../../src/libiberty/cplus-dem.c:55: error: conflicting types for 'malloc'
<doko> Keybuk: yes, warnings only
<Keybuk> doko: gcc-4.1 FTBFS on ia64 and sparc
<doko> fabbione: but you did test ssp on sparc?
<Mithrandir> doko: infinity claimed that he fixed that?
<fabbione> doko: i am running edgy on one machine...
<elmo> what the hell did someone do to apt?
<Keybuk> sorry
<Keybuk> s/sparc/powerpc/
<Keybuk> powerpc buildd aborted
<fabbione> elmo: dselect update is borked.. 
<elmo> fabbione: so I'm discovering :-/
<Keybuk> doko: there actually seems to be a physical compilation failure here
<Keybuk> http://librarian.launchpad.net/3391545/buildlog_ubuntu-edgy-ia64.gcc-4.1_4.1.1-8ubuntu1_FAILEDTOBUILD.txt.gz
<fabbione> elmo: i noticed only yesterday evening. all other apt stuff are ok or so it seems
<fabbione> elmo: and without mvo there isn't much to do..
<doko> Keybuk: right, turned off ssp on ia64 in -8ubuntu2
<doko> Mithrandir: fixed what?
<Mithrandir> doko: fakeroot
<Keybuk> doko: if you could upload that, that'd be nice
<Mithrandir> uh, please not a new gcc for a ports architecture, no.
<doko> Keybuk: I'll recheck if it's buildable using the current gcc
<Mithrandir> after knot-1, sure.
<Keybuk> Mithrandir: I thought we pretended to officially support ia64?
<doko> Mithrandir: IMO it doesn't make sense to release knot-1 with a broken libgcc1 on powerpc
<elmo> Keybuk: no
<Mithrandir> Keybuk: not according to https://launchpad.net/distros/ubuntu/edgy
<elmo> Keybuk: it's on ports.ubuntu.com => it's not supported
<Kamion> Riddell: because I haven't done a removals pass
<Mithrandir> doko: that'll be fixed when gcc is by-hand bootstrapped on ppc, won't it?
<doko> Mithrandir: yes
<Mithrandir> doko: good, that means we just have to make sure that happens before we release.
<Kamion> ../../../src/libiberty/cplus-dem.c: In function 'squangle_mop_up':
<Kamion> that's the best function name ever
<Keybuk> mmm, squangles
<Kamion> I think I shall start using squangle as a metasyntactic variable
<ogra> heh
<pitti> Keybuk: what the heck is a squangle? dict.leo.org doesn't know it
<Kamion> pitti: I think you're making the mistake of assuming it's actually an English word
<Riddell> Kamion: who does?
<ogra> pitti, a square angle ? 
<Kamion> Riddell: who does what?
<Keybuk> pitti: compressed identifiers for gcc
<Keybuk> apparently
<Keybuk> (according to the docs for -fsquangle)
<Riddell> Kamion: you said you didn't have a removals pass
<Kamion> Riddell: no, I said I *haven't done* a removals pass
<ogra> pitti, or a squished triangle :)
<pitti> Keybuk: thanks :)
<Keybuk> Kamion: there should be an entire family
<Kamion> Riddell: I will, I just haven't yet
<Keybuk> squangle, squengle, squingle, squongle
<ogra> what do you want to you squongle today ?
<Kamion> Riddell: in the meantime, just ignore stuff that you know is removed
<Riddell> Kamion: right, my mistake, thanks
<Kamion> Riddell: apt-index-watcher promoted
<Mithrandir> Keybuk: actually, the amd64 chroots seem to be fucked. :-/  Can you update them?
<Mithrandir> Keybuk: the fakeroot in them is old and br0ken.
<fabbione> oh btw..
<fabbione> did we actually get to remove -drivers- from edgy?
<Kamion> fabbione: not yet, but I noticed it and it's on my list; is it safe to do it now?
<Keybuk> Mithrandir: no, I have no access
<fabbione> Kamion: it should be safe..
<Mithrandir> Keybuk: grr, ok.  Do you know who is able to?
<Keybuk> Mithrandir: infinity
<Mithrandir> Keybuk: apart from him?  cprov?
<fabbione> Kamion: all pkgs have been converted to video and dependencies updated
<fabbione> Mithrandir: no, only infinity is
<Keybuk> Mithrandir: I don't think so...  we've generally preferred LP people *not* to muck around in there
<Mithrandir> hmm
<Kamion> fabbione: done
<fabbione> Kamion: thanks
<fabbione> hey robertj 
<fabbione> MAH
<fabbione> hey rodarvus 
<fabbione> rodarvus: did you sleep well?
<pitti> moin rodarvus 
<rodarvus> fabbione: I didn't :)
<rodarvus> was taking care of wife and daughter
<Mithrandir> what will sbuild do if we make lib32gcc1 1:4.1.1-8ubuntu1 conflict with fakeroot (< some version) and it's told that it should keep fakeroot installed?
<fabbione> rodarvus: ok :)...
<rodarvus> its amazing how hard/tiring it can be to dress a little girl :)
<fabbione> rodarvus: mesa is done.. just waiting for propagation
<rodarvus> fabbione: nice, thanks!
<ogra> iwj, will it be possible to not use the new firefox icontheme ? i.e. it wouldnt look well with edubuntus default theme
<fabbione> rodarvus: that's because you are dressing her ... that's a mother's task ;)
<rodarvus> fabbione: tell that to my wife :D
<fabbione> rodarvus's wife: that's your job
<rodarvus> I also either shower her, most of the days
<rodarvus> my wife prepares her school bag, check agenda, etc
<rodarvus> we mostly divide all baby-related tasks
<Kamion>  * casper_1.59+debian-1 builds: casper
<Kamion>       but no longer builds:
<Kamion>         o 1.57: ubiquity-casper
<Kamion> Mithrandir: please put ubiquity-casper back
<Kamion> you might want to see what else we lost in that sync ...
<rodarvus> is mdz still online?
<sivang> rodarvus: make sure to distribute them equally, that way she won't tend to prepfer any of you on the other :)
<dholbach> ogra: maybe you can modify the script to ship edubuntu icons
<dholbach> rodarvus: he went to bed a while ago
<rodarvus> oh
<Mithrandir> Kamion: can you add it to the blacklist too?
<dholbach> rodarvus: ~1h30m ago
<rodarvus> Kamion: are we still able to (manually) merge X apps, or UVF is already in practice?
<doko> Mithrandir: fakeroot already was fixed, as long as the chroot doesn't have an /emul anymore, everything should be fine
<ogra> dholbach, meh, that means i'd need icons first 
<rodarvus> dholbach: he deserved it - it was quite late on his timezone by then :)
<dholbach> ogra: it could build-depend on gartoon something
<Mithrandir> doko: fakeroot in the chroots is old so we need to force it to be upgraded or something.
<fabbione> rodarvus: UVF is in place. i think we can have exceptions fro X apps.
<rodarvus> fabbione: *nods* good
<fabbione> rodarvus: at least that's the feeling i had when talking with mdz yesterday evening
<ogra> dholbach, sure, but i'm not sure gartoon has everything needed for a firefox theme
<Mithrandir> doko: I'm pondering evilness like making lib32gcc1 conflict with the broken fakeroot or depending on the newer fakeroot..
<dholbach> ogra: it could then use gartoon's fallback
<fabbione> rodarvus: i suggest you start on that, and pile them up for a day. Once mdz is back we can discuss it properly
<doko> Mithrandir: sure, lib32gcc1 could be used for that
<ogra> dholbach, also i dont think its a good idea to ship a hardcoded theme
<Kamion> rodarvus: what fabbione said
<rodarvus> fabbione, Kamion: sure, thanks!
<Kamion> Mithrandir: no, Keybuk has it open
<Kamion> Keybuk: please blacklist casper
<Kamion> (sync-blacklist)
<dholbach> ogra: i can change the theme in my firefox
<ogra> dholbach, hmm
<Mithrandir> doko: another alternative is to make gcj-4.1 build-depend on fixed fakeroot or build-conflict broken fakeroot.
<ogra> dholbach, anyway, i think thats another reasoin to switch edubuntu to epiphany ;)
<ogra> *reason too
<Keybuk> Kamion, Mithrandir: done
<Kamion> thanks
<iwj> ogra: In principle you can change the theme but we don't have any sane way of having other packages change the ff default profile.
<Keybuk> is the Debian version that crackful?
<doko> Mithrandir: yes, a b-d sounds nicer
<ogra> iwj, well, currently it removes the world if i try to remove firefox-themes-ubuntu ... is that hard dep needed ?
<Keybuk> why did we sync casper, anyway?
<Mithrandir> doko: ok, can you add a build-depends on a fixed version of fakeroot and upload gcj-4.1?
<iwj> ogra: If our stuff supports Recommends then it could be a Recommends instead but removing the package won't help.
<doko> Mithrandir: but why gcj-4.1, not gcc-4.1?
<iwj> Unless again you're just trying to save disk space.
<Kamion> Keybuk: our version didn't have *ubuntu* so we didn't notice
<Mithrandir> doko: because it's gcj that ftbfs?
<Keybuk> Kamion: oops
<Kamion> (we're upstream ...)
<Keybuk> see, this is why it's generally a good idea to leave "ubuntu" in *anyway*
<Keybuk> so we don't get fucked by Debian
<doko> Mithrandir: I would suggest to make the b-d hack with a package, that doesn't install anything in /usr/lib32
<ogra> iwj, well, we will need to ship epiphany as default browser in edubuntu, so that dep is a bit of wasted diskspace ... 
<StevenK> Keybuk: That statement makes for disturbing mental images.
<iwj> OIC.  Without that if you launch firefox it will fail to start.
<Mithrandir> doko: lp doesn't save the chroot afterwards, so we can't play the same tricks as in Debian where we then wouldn't have the problem again.
<iwj> In the default setup.
<Keybuk> StevenK: depends which members of Debian, really;  there are some I wouldn't object to
<iwj> I can't remember whether it actually tries to start and gives you a totally dysfunctional thing or whether it doesn't do anything at all.
<doko> Mithrandir: or can we assure that fakeroot is upgraded before some ia32 / libc6-i386 stuff uis unpacked?
<StevenK> Keybuk: Me either, but I suspect my wife will.
<ogra> iwj, hmm, k, xulrunner would be really helpful ... sad we dont have it :)
<doko> Mithrandir: ok, so we do need the b-d on fakeroot _and_ the dependency on fakeroot in lib32gcc1.
<iwj> ogra: I don't think we'll have it until upstream ff uses it.
<Mithrandir> doko: if so, we just need the dependency in lib32gcc1.
<ogra> iwj, yes, sadly ... 
<Keybuk> Mithrandir: that's EVIL
<fabbione> Mithrandir: 
<Mithrandir> Keybuk: no shit.
<fabbione> Changes: 
<fabbione>  linux-restricted-modules-2.6.17 (2.6.17.1-4) edgy; urgency=low
<fabbione>  .
<fabbione>    * Provides: xserver-xorg-video instead of xserver-xorg-driver.
<Mithrandir> fabbione: go ahead.
<fabbione> ^^ it's a 3 lines change to debian/control
<fabbione> ok
<fabbione> thanks
<Keybuk> Mithrandir: why do we need the dependency there?
<mjg59> pitti: Why is my "Default sound card" greyed out in dapper?
<Mithrandir> Keybuk: we want fakeroot to continue being installed, but we want to force an upgrade.
<Keybuk> Mithrandir: it gets upgraded anyway, no?
<Mithrandir> Keybuk: apparently not.
<Keybuk> Mithrandir: it so does
<Keybuk> The following packages will be upgraded:
<Keybuk>   apt base-files bash bsdutils build-essential cpio cpp cpp-4.1 debconf
<Keybuk>   debconf-english debianutils dpkg dpkg-dev e2fslibs e2fsprogs fakeroot
<fabbione> Mithrandir: because the new version of fakeroot is FTBFS due to the old being broken?
<Mithrandir> Keybuk: can you point to that on http://librarian.launchpad.net/3374978/buildlog_ubuntu-edgy-amd64.gcj-4.1_4.1.1-8ubuntu1_FAILEDTOBUILD.txt.gz ?
<Mithrandir> fabbione: no?
<Mithrandir> : tfheen@golem ~ > (apt-cache showsrc fakeroot ; apt-cache show fakeroot )| grep ^Vers
<Mithrandir> Version: 1.5.9ubuntu1
<Mithrandir> Version: 1.5.9ubuntu1
<fabbione> hmm weird..
<fabbione> infinity must have fixed that
<Keybuk> Mithrandir: probably means it was already up to date in the chroot
<fabbione> pitti: !!!!!
<fabbione> pitti: you beated my -4 upload for l-r-m
<doko> Mithrandir, Keybuk: could you check, if /emul still exists in the chroot?
<fabbione> pitti: can you please do a -5 upload with a 3 lines change to debian/control?
<Riddell> Keybuk: could you give back kdeaddons and kdesdk please
<Mithrandir> doko: I don't have access to the chroots, sorry.
<Mithrandir> Keybuk: well, it works splendidly in a pbuilder chroot for me.
<Keybuk> doko: that's what I suspect ... fakeroot is up to date but /usr/lib32 is still a symlink
<Keybuk> not-quite-updated-hard-enough chroot
<Keybuk> but I can't tell myself
<Mithrandir> probably needs to be rebuilt rather than updated due to dpkg not changing symlink to dirs?
<Kamion> fakeroot.postinst could clean that up
<Kamion> and probably should
<Kamion> or whatever.postinst of the package that had /emul
<Keybuk> Kamion: nothing in there
<doko> ok, I'll prepare a fakeroot upload
<fabbione> Mithrandir: i need to delay the l-r-m upload. pitti and i clashed on versions and i need to get his changes here
<Mithrandir> fabbione: ok.
<Mithrandir> doko: thanks.
<ogra> Mithrandir, i'll upload a new edubuntu-meta soon to pick up the ubuntu changes, ok with you ?
<Mithrandir> it'd be the preinst that would need to fix it, no?
<fabbione> that is hopefully in the next publisher run
<Mithrandir> ogra: upload away.
<Kamion> Mithrandir: one of them :)
<Kamion> yeah, probably preinst
<Keybuk> http://www.theregister.co.uk/2006/07/13/fish4_goes_down/
<Keybuk> d'oh
<sivang> Keybuk: hah
<doko> if [ "$1" = configure ]  && [ -d /emul ]  && [ -h /usr/lib32 ]  && [ $(uname -m) = x86_64 ] ; then
<doko>         rm -f /usr/lib32
<doko>         mkdir /usr/lib32
<doko>         mv /emul/ia32-linux/usr/lib/* /usr/lib32/ || true
<doko>         rm -rf /emul
<doko> fi
<dholbach> bug 39846: "if you fill up your free space from behind, ..."
<Ubugtu> Malone bug 39846 in gparted "creates partitions in wrong order" [Medium,Unconfirmed]  http://launchpad.net/bugs/39846
<doko> Mithrandir, Kamion: does the look ok for the fakeroot.postinst?
<Kamion> as Mithrandir says, probably needs to be preinst
<Mithrandir> I'm slightly worried about the rm -rf /emul
<Kamion> and then it would be "$1" = upgrade rather than configure
<StevenK> Shouldn't "upgrade" be quoted?
<Mithrandir> doesn't matter.
<Kamion> StevenK: no
<Mithrandir> but it often is, for stylistic reasons.
<doko> Mithrandir: find /emul ! -type d || rm -rf /emul
<Kamion> the comedy thing I see is people doing stuff like $1 = "upgrade"
<Kamion> which betrays a total lack of understanding of shell quoting
<StevenK> Heh, ouch
<Kamion> quote precisely what doesn't need to be quoted :P
<doko> Kamion: upgrade in postinst?
<Kamion> doko: 12:30 < Kamion> as Mithrandir says, probably needs to be preinst
<Keybuk> Mithrandir: \o/
<Kamion> if preinst is definitely wrong then ignore my upgrade comment
<Mithrandir> doko: why not find /emul -type -d -empty -delete ?
<doko> find /emul -depth -type -d -empty -delete
<doko> trying to find a reason, why it needs to be in the preinst
<Mithrandir> -delete turns on -depth automatically
<doko> ahh, didn't know
<Keybuk> Package: fakeroot
<Keybuk> Version: 1.5.9ubuntu1
<Kamion> my preinst comment was based on the feeling that it's usually best to fix up the filesystem before you unpack the new filesystem archive
<Keybuk> ok
<Keybuk> Mithrandir: the amd64 chroot has the updated fakeroot
<Mithrandir> Kamion: yeah, mine too.
<Keybuk> that's why it doesn't get updated
<Mithrandir> Keybuk: ok.
<pitti> fabbione: lrm clash> oh, sorry
<pitti> fabbione: want my debdiff?
<Kamion> in case dpkg unpacks through the symlink
<Keybuk> Mithrandir: it also does NOT have /emul
<Keybuk> so we're barking up the wrong tree, here
<fabbione> pitti: it's easier if you just change the 3 lines in debian/control
<pitti> oh, the package is already in LP
<fabbione> pitti: search for xsrever-xorg-driver and change that to xserver-xorg-video in 3 Provides
<StevenK> Heh, xsrever-xorg
<fabbione> ok
<doko> Keybuk: so just try to build it again?
<Mithrandir> Keybuk: do you have a copy of the chroot?
<fabbione> pitti: never mind i will do it
<Mithrandir> Keybuk: or are you looking at the package?
<Keybuk> Mithrandir: I have a copy of the chroot
<fabbione> StevenK: that's just my typo here
<Mithrandir> Keybuk: what does ls -ld  /usr/lib32 look like?
<StevenK> fabbione: I know, I was chuckling over it.
<pitti> fabbione: hm, but I shall not rename the -driver-fglrx etc. packages themselves?
<Keybuk> drwxr-xr-x root/root         0 2006-01-26 14:46:57 chroot-autobuild/usr/lib32/
<Keybuk> drwxr-xr-x root/root         0 2006-07-10 16:50:21 chroot-autobuild/usr/lib32/libfakeroot/
<Keybuk> -rwxr-xr-x root/root     22728 2006-07-10 15:29:10 chroot-autobuild/usr/lib32/libfakeroot/libfakeroot-sysv.so
<Keybuk> -rwxr-xr-x root/root     23580 2006-07-10 15:29:10 chroot-autobuild/usr/lib32/libfakeroot/libfakeroot-tcp.so
<Mithrandir> then why does it end up with a file conflict?
<Keybuk> because dpkg is special
<Keybuk> something ELSE must think that /usr/lib32 is supposed to be a symlink to /emul
<fabbione> pitti: don't worry.. i will take care of that..
<pitti> fabbione: ok, as you wish; thanks
<fabbione> pitti: it's in LP i can grab it
<fabbione> pitti: no there is no need to rename because Debian doesn't have/will never have that package
<Mithrandir> Keybuk: can you give me the url to it so I can poke it too?
<fabbione> al lthe -driver -> -video rename was to be able to sync easily
<Keybuk> Mithrandir: the chroot?
<pitti> fabbione: ok; just for the sake of consistency, but now is not the right time to break names again :)
<Mithrandir> Keybuk: yes, please.
<StevenK> Keybuk: And figure that out how? Grep dpkg -c of every deb?
<fabbione> pitti: exactly
<Mithrandir> Keybuk: I know it's in the librarian somewhere, but I don't have the URL
<Keybuk> are the middle bits alias or content?
<fabbione> StevenK: a chroot doens't have that many package.. it's easier to do a grep on dpkg -c
<Keybuk> http://librarian.launchpad.net/3325242/chroot-ubuntu-edgy-amd64.tar.bz2
<Keybuk> ^ try that
<Mithrandir> Keybuk: thanks
<fabbione> Keybuk: is the publisher in manual mode?
<Keybuk> fabbione: no
<fabbione> ok
<fabbione> is it just slower than usual?
<Keybuk> fabbione: no
* pitti misses libtunepimp security updates on archive.u.c, too
<Keybuk> fabbione: perhaps we should start with a question that involves package names and version numbers? :)
<fabbione> l-r-m-2.6.17 -4 accepted at 13:00
<fabbione> it should have made this run
<fabbione> and according to LP is done
<fabbione> s/done/published
<Keybuk> fabbione: not in accepted
<fabbione> https://launchpad.net/distros/ubuntu/+source/linux-restricted-modules-2.6.17/2.6.17.1-4
<Keybuk>    71675 | S- | linux-restricted-mod | 2.6.17.1-4           | 48 minutes
<Keybuk>          | * linux-restricted-modules-2.6.17/2.6.17.1-4 Component: restricted Section: misc
<Keybuk> it's in DONE
<Keybuk> LP says it's published
<Keybuk> so, dude, WTF?! :)
<Kamion> fabbione: archive.u.c is in .se at the moment - takes a while to mirror
<Kamion> oh, hang on, that was yesterday, it's back in the DC today apparently
<Kamion> check DNS though
<Keybuk> right
<fabbione> yes
<Keybuk> and it's bloody well on archive.uc :)
<fabbione> it's not on the mirror yet
<Keybuk> http://archive.ubuntu.com/ubuntu/pool/restricted/l/linux-restricted-modules-2.6.17/linux-restricted-modules-2.6.17_2.6.17.1-4.dsc
<fabbione> it's appearing now
<fabbione> WTf
<fabbione> bah
<Keybuk> it's not "appearing now"
<Kamion> at :45, when you asked, it was probably still mirrorinng
<Keybuk> it appeared about 10 minutes ago
<fabbione> Kamion: yeah
<Kamion> these days, wait until :50 before wondering if something is wrong :)
<Keybuk> heh
<Keybuk> 30-45 is pretty much "mirror"
<fabbione> Keybuk: no, because i did trigger an rsync 5 minutes ago and it was not there
<Keybuk> fabbione: dude, AYT!
<Keybuk> AWTY even
<Keybuk> I tend to do anything involving a published day at :05
<fabbione> Keybuk: dude.. usually at :45 the mirror is finished and since it's not the first time that the mirroring breaks down, i was wondering where the hell the package was.
<Keybuk> bah
<Keybuk> you're lucky if the publisher has finished at :45 some days
<fabbione> Keybuk: that's why i was also asking if it was slower than usual
<Keybuk> "slower than usual" => "taking more than an hour"
<Keybuk> as long as the publisher finishes before :50 or so, I figure it's fine
<janimo> Mithrandir: another exception fort xarchiver. Install a bash script in /usr/lib/thunar-archive-plugin/ instead of /usr/libexec so it is found by thunar.
<Kamion> Keybuk: can you get at the livefs buildds?
<Mithrandir> janimo: go ahead.
<Kamion> as in log into them
<Keybuk> Kamion: no, elmo won't let me
<sivang> has anyone else noticed a slow down downloading from archive.ubuntu.com ?
<Kamion> elmo: could you change STE=dapper to STE=edgy in /usr/sbin/livecd.sh on the livefs buildds please?
<sivang> dropped to 13kb for me comapred to 160kb last night
<Kamion> elmo: or tell me if /home/buildd/bin/BuildLiveCD will let me override it (livecd.sh has a -d switch, if I can get at it from the trigger)
<Mithrandir> doko: I'm not sure why this blows up on the buildd, but installing the build-deps in the chroot gives:
<Mithrandir> sh-3.1# dpkg -S /emul
<Mithrandir> lib32asound2, lib32asound2-dev: /emul
<Mithrandir> but I have no idea why that should break anythin
<Keybuk> Mithrandir: found it!
<Keybuk> bah
<Mithrandir> Keybuk: hum?
<Keybuk> I found it almost exactly the same time you did :p
<Keybuk> lib32asound2_1.0.11-7ubuntu1_amd64.deb
<Keybuk> drwxr-xr-x root/root         0 2006-07-03 13:57:15 ./emul/
<Keybuk> drwxr-xr-x root/root         0 2006-07-03 13:57:15 ./emul/ia32-linux/
<Keybuk> drwxr-xr-x root/root         0 2006-07-03 13:57:15 ./emul/ia32-linux/usr/
<Keybuk> drwxr-xr-x root/root         0 2006-07-03 13:57:18 ./emul/ia32-linux/usr/lib/
<Keybuk> -rw-r--r-- root/root    778500 2006-07-03 13:57:18 ./emul/ia32-linux/usr/lib/libasound.so.2.0.0
<Keybuk> lrwxrwxrwx root/root         0 2006-07-03 13:57:18 ./emul/ia32-linux/usr/lib/libasound.so.2 -> libasound.so.2.0.0
<Keybuk> lrwxrwxrwx root/root         0 2006-07-03 13:57:19 ./usr/share/doc/lib32asound2 -> libasound2
<Keybuk> libasound2-dev_1.0.11-7ubuntu1_amd64.deb
<Keybuk> lib32asound2-dev_1.0.11-7ubuntu1_amd64.deb
<Keybuk> drwxr-xr-x root/root         0 2006-07-03 13:57:15 ./emul/
<Keybuk> drwxr-xr-x root/root         0 2006-07-03 13:57:15 ./emul/ia32-linux/
<Keybuk> drwxr-xr-x root/root         0 2006-07-03 13:57:15 ./emul/ia32-linux/usr/
<Keybuk> drwxr-xr-x root/root         0 2006-07-03 13:57:19 ./emul/ia32-linux/usr/lib/
<Keybuk> -rw-r--r-- root/root   1317808 2006-07-03 13:57:18 ./emul/ia32-linux/usr/lib/libasound.a
<Keybuk> -rw-r--r-- root/root       851 2006-07-03 13:57:15 ./emul/ia32-linux/usr/lib/libasound.la
<Keybuk> lrwxrwxrwx root/root         0 2006-07-03 13:57:19 ./emul/ia32-linux/usr/lib/libasound.so -> libasound.so.2.0.0
<Keybuk> lrwxrwxrwx root/root         0 2006-07-03 13:57:19 ./usr/share/doc/lib32asound2-dev -> libasound2-dev
<doko> Mithrandir, Keybuk: wrong merge, will fix it ...
<Kamion> Mithrandir put it considerably more concisely :P
<Keybuk> he did
<Mithrandir> Keybuk: well, but do you have any idea why it breaks stuff?
<Keybuk> but I don't understand why that breaks it yet
<Mithrandir> doko: thanks.
<Mithrandir> me neither; I can't break it in the chroot
<doko> crimsun: ^^^
<Keybuk> Mithrandir: did you compare the versions of everything against those in the log?
<Mithrandir> Keybuk: doing so now
<Keybuk> if [ ! -h /usr/lib32 -a -d /usr/lib32 -a -d /emul/ia32-linux/usr/lib ] ; then
<Keybuk>   rm -rf /usr/lib32
<Keybuk>   ln -s /emul/ia32-linux/usr/lib /usr/lib32
<Keybuk> fi
* Keybuk looks at doko pointedly
<Keybuk> would sir care to revise sir's bullshit preinst? :p
<Keybuk> dpkg-deb -I ubuntu/pool/main/*/*/lib32gcc1_4.1.1-8ubuntu1_amd64.deb preinst
<doko> Keybuk: yes, that crept in from unstable, didn't hurt as long as we had not an /emul ... it's removed in -8ubuntu2
<Riddell> doko: has the gcc bug that caused ruby1.8 to fail on powerpc been fixed?  it seems to compile fine for me locally (http://librarian.launchpad.net/3371361/buildlog_ubuntu-edgy-powerpc.ruby1.8_1.8.4-5ubuntu1_FAILEDTOBUILD.txt.gz)
<Keybuk> doko: right, so asound's bad merge gave us an emul, and your preinst of death wiped /usr/lib32 and replaced it with a symlink, leading to the package breaking
<Mithrandir> oh, joy.
<Keybuk> so we need a new asound and a new gcc
<doko> Mithrandir: please let me upload gcc-4.1 4.1.1-8ubuntu2 ...
<Keybuk> the chroot itself is fine, so that doesn't need updating
<Mithrandir> doko: go ahead.
<Mithrandir> doko: is this the only change or is there more in there?
<doko> alsa-lib already uploaded
<doko> I don't know, but lib32z1 is fine.
<Mithrandir> doko: as in, are there any other changes in gcc-4.1?
<doko> Mithrandir: yes, but bootstrapped on powerpc several times
<Mithrandir> doko: ok, let's cross our fingers, then.
<doko> Mithrandir: will wait for an ia64 build, at least until the stage3 compiler is built
<Keybuk> will any chroots need updating/
<dholbach> can somebody please give back gnome-system-tools?
<Keybuk> dholbach: eh?  no failed build
<dholbach> Keybuk: it was waiting on liboobs
<Keybuk> dholbach: yes, so?  that means the buildd has it ... it doesn't need giving back
<Mithrandir> doko: before uploading the source, you mean?  Any idea when that is?
<Riddell> the names of these gnome libraries are getting worse...
<dholbach> Keybuk: will it automatically retry?
<Keybuk> dholbach: yes
<dholbach> Keybuk: ok cool :)
<Keybuk> Riddell: the inevitable liboom hasn't happened yet :p
<Keybuk> dholbach: a give back is when the buildd has failed a build and isn't going to attempt it again ... you give it back to try again
<Keybuk> dholbach: if the build is in needs building, dependency wait, etc. it means the buildd will get around to it
<dholbach> ok, super
<Riddell> Keybuk: did you see my request to give back kdeaddons and kdesdk?
<Keybuk> Riddell: no
<Riddell> Keybuk: please give them back
<Keybuk> kdeaddons 4:3.5.3-0ubuntu2 - powerpc ia64 sparc i386 amd64
<Keybuk> kdesdk 4:3.5.3-1ubuntu2 - powerpc ia64 sparc i386 amd64
<doko> Mithrandir: 2h?
<doko> hmm, can upload it now as well, it's a community arch anyway
<Keybuk> doko: will we want a chroot update for the new gcc, or is it ok for it go be updated the old fashioned way each time?
<Kamion> Mithrandir: ok for ubuntu-meta upload to make pbbuttonsd powerpc-specific?
<Riddell> Keybuk: could you give back ruby1.8 on powerpc too?
<Mithrandir> Keybuk: the regular update should be fine.
<doko> Keybuk: just make sure that /emul doesn't exist.
<Keybuk> ruby1.8 1.8.4-5ubuntu1 - powerpc
<Mithrandir> doko: hmm, ok.
<Riddell> thanks Keybuk 
<doko> Keybuk: could you hand-bootstrap the powerpc build?
<Keybuk> doko: possibly, do we need to then?
<doko> Keybuk: yes, it's definitely broken
<Keybuk> meh
<sivang> ogra: did you manage to sort out the ALT keys combos ?
<Keybuk> doko: what needs to be done?
<ogra> sivang, the gconf command you gave me solved it
<sivang> ogra: I am thankful to seb128 who told me it in the first place, I just wonder if this is a bug or normal dist-upgrade stuff while merging stuff..I couldn't find in the metacity package where it registers it schems after shipping them there.
<Kamion> Riddell,ogra,janimo: could you merge/upload-meta my recent seed change?
<Riddell> Kamion: ok
<janimo> Kamion: ok
<Kamion> thanks
<Kamion> oh, hell, xfonts-{75,100}dpi need NEWed
<Kamion> me prods
<Kamion> (done)
<Kamion> dholbach: liboobs isn't through NEW yet, I'm checking that now
<Mithrandir> Kamion: any idea why memtester now seems to be in universe?  It used to be in main and sysutils depends on it.
<Kamion> Mithrandir: no - re-promoted
<Mithrandir> thanks
<pitti> hi ivoks 
<ivoks> pitti: hi
<ivoks> pitti: i'm just working on a fix for pnm2ppa
<ivoks> pitti: adding # won't be enough, and it would be wrong
<pitti> ivoks: oh, the file format doesn't understand comments?
<ivoks> pitti: that would mean that when someone configures it trough debconf, he's configs wouldn't reflect his choice :)
<ivoks> pitti: so if RET is empty then sed version with #version
<ivoks> pitti: otherwise version = RET :)
<ivoks> pitti: you'll see whent i finish :)
<Hobbsee> sivang: ping?
<doko> jbailey, fabbione: linux-kernel-headers are probably broken on ia64 and sparc
<Keybuk> doko: why do you say that?
<Keybuk> doko: they look fine to me
<doko> Keybuk: alsa-lib build failures
<doko> and gcc-4.1 build failure
<doko> gcc-4.1 -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../src/libiberty/../include  -W -Wall -pedantic -Wwrite-strings -Wstrict-prototypes ../../../src/libiberty/fnmatch.c -o fnmatch.o
<doko> In file included from /usr/include/bits/errno.h:25,
<doko>                  from /usr/include/errno.h:36,
<doko>                  from ../../../src/libiberty/fnmatch.c:46:
<doko> /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
<doko> make[3] : *** [fnmatch.o]  Error 1
<Keybuk> doko: that's because /usr/include/ia64-linux-gnu is not in cpp's search path
<Keybuk> which is because the toolchain failed to build
<Keybuk> which is because you had stack protector turned on for ia64
<sivang> Hobbsee: pong
<Hobbsee> sivang: i'm just reading the CC meeting - you should be able to set to auto identify yourself in your client, if you wanted to.
<Keybuk> doko: there does, however, appear to be a bug for sparc
<Keybuk> /usr/include/sparc64-linux-gnu contains an asm directory without all of the headers
<doko> Keybuk: hmm, however I cannot find a relation between ssp and the include path for ia64
<Keybuk> doko: ssp was added at the same time the include path was added
<Keybuk> so ia64 never got a compiler that had the include path
<sivang> Hobbsee: sure, I Know, I just never bothered to do so :)
<Hobbsee> sivang: ah, irssi.  shouldnt be that hard
<doko> Keybuk: we had this include already in dapper
<sivang> Hobbsee: should save some keystrokes.
<Keybuk> doko: well, the gcc installed on halley doesn't have it
<Keybuk> you may have dropped it, of course
<Keybuk> in which case there's a gcc bug
<Keybuk> halley% gcc test.c
<Keybuk> In file included from /usr/include/bits/errno.h:25,
<Keybuk>                  from /usr/include/errno.h:36,
<Keybuk>                  from test.c:1:
<Keybuk> /usr/include/linux/errno.h:4:23: error: asm/errno.h: No such file or directory
<Keybuk> halley% gcc -I/usr/include/ia64-linux-gnu test.c
<Keybuk> halley%
<Keybuk> halley% cpp -v
<Keybuk>   :
<Keybuk> #include <...> search starts here:
<Keybuk>  /usr/local/include
<Keybuk>  /usr/lib/gcc/ia64-linux-gnu/4.1.2/include
<Keybuk>  /usr/include
<Keybuk> End of search list.
<doko> $ gcc -v -E - </dev/null Using built-in specs. Target: ia64-linux-gnu
<doko> Configured with: ../src/configure -v --enable-languages=c,c++,java,fortran,objc,obj-c++,ada,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --ena
<doko> ble-mpfr --with-system-libunwind --enable-checking=release ia64-linux-gnu
<doko> Thread model: posix
<doko> gcc version 4.1.2 20060613 (prerelease) (Ubuntu 4.1.1-2ubuntu4)
<doko>  /usr/lib/gcc/ia64-linux-gnu/4.1.2/cc1 -E -quiet -v -
<doko> ignoring nonexistent directory "/usr/lib/gcc/ia64-linux-gnu/4.1.2/../../../../ia64-linux-gnu/include"
<doko> #include "..." search starts here:
<doko> #include <...> search starts here:
<doko>  /usr/local/include
<doko>  /usr/lib/gcc/ia64-linux-gnu/4.1.2/include
<doko>  /usr/include
<doko> End of search list.
<doko> # 1 "<stdin>"
<doko> # 1 "<built-in>"
<doko> # 1 "<command line>"
<doko> # 1 "<stdin>"
<doko> so it does have it
<Keybuk> no, it doesn't
<Keybuk> your paste proves it doesn't :p
<Keybuk> no /usr/include/ia64-linux-gnu there
<Keybuk> iz gcc bug
* Keybuk goes for lunch, really this time
<StevenK> Keybuk: Convince us. :-)
<Kamion> http://cdimage.ubuntu.com/daily/current/
<Kamion> getting there ...
<pitti> Kamion: rock!
* Kamion will update bzr for the new python policy
<doko> ouch, the multiarch include patch is only applied for biarch architectures ... so it will ftbfs with on ia64 and hppa
<sivang> hmm, that's okay for initrafms-tools ? update-initramfs: Generating /boot/initrd.img-2.6.17-4-686
<sivang> cpio: ./lib/udev/path_id: No such file or directory
<Kamion> udev bug iirc
<sivang> Kamion: what could be it's effect? some devices not operating ? (/me goes to serch for a bug and file one if not already filed in the meanwhile)
<Kamion> no idea
<Kamion> ask Keybuk
<sivang> right
* sivang finds the bug report and confirms.
<Kamion> wow, UTF-8 display in the installer is excitingly hosed
<Kamion> but only some characters, weirdly
<Mithrandir> borken font?
<Kamion> Mithrandir: http://people.ubuntu.com/~cjwatson/tmp/d-i-weird.png - you tell me
<Mithrandir> freaky, but I'd think it's missing fonts.
<Kamion> /lib/unifont.bgf is there though
<Mithrandir> does it have  for instance?
<Kamion> I have a feeling installation-locale needs to be rebuilt
<Kamion> note the extra "locale: Cannot set LC_ALL to default locale: No such file or directory" in http://librarian.launchpad.net/3404510/buildlog_ubuntu-edgy-i386.debian-installer_20060711ubuntu2_FULLYBUILT.txt.gz versus http://librarian.launchpad.net/3003995/buildlog_ubuntu-dapper-i386.debian-installer_20051026ubuntu36_FULLYBUILT.txt.gz
<ivoks> pitti: ping
<pitti> hey ivoks 
<ivoks> pitti: i'm kind of confused atm :)
* Kamion tries to verify
<ivoks> pitti: grep ^version /etc/pnm2ppa.conf, please? :)
<pitti> ivoks: 'version  710'
<ivoks> doh
<Kamion> hmm, no, must be more complicated than that
<ivoks> why does someone has 710, and someone ""
<pitti> ivoks: hm, that file has lots of '#foo' comments, btw
<ivoks> pitti: that file is different from one computer to other..
<ivoks> pitti: and debconf defaults hould be version 710
<ivoks> pitti: but this morning i had just version, wihtout 710
<ivoks> pitti: now, after reinstall of package, it's version 710
<ivoks> and i didn't touch debconf :/
<dholbach> Kamion: gracias
<pitti> ivoks: so sometimes there is an uninit'ed variable apparently
<ivoks> pitti: could be
<Keybuk> sivang: means /dev/disk/by-path doesn't exist in the initramfs
<Keybuk> but that's ok, we don't use that
<sivang> Keybuk: so that's not a bug then?
<Keybuk> yeah, it's a bug
<Keybuk> just a little one
<Keybuk> there were more important things to do
<Keybuk> and udev will need another upstream update anyway for the sysfs change
<fabbione> Kamion, Keybuk: could you be so kind to check if mesa binaries are still sitting in NEW?
<Keybuk> fabbione: i386 and amd64 are
<seb128> Keybuk: could you give a build retry to gnome-applets and gedit?
<Keybuk> seb128: ANOTHER retry?!
<fabbione> Keybuk: could you please let them in
<fabbione> ?
<seb128> Keybuk: looks like the new gnome-python-desktop was not available when you retried this morning
<Keybuk> gnome-applets 2.15.1.1-0ubuntu2 - powerpc ia64 sparc amd64
<Keybuk> gedit 2.15.4-0ubuntu1 - powerpc ia64 sparc amd64
<seb128> Keybuk: or it's not installable for another reason ... but the log looks like arch any,all not in sync
<seb128> thank you
<Keybuk> fabbione: ok
<dholbach> ahh another new network-manager
<fabbione> Keybuk: thanks
<fabbione> Keybuk: sparc/ppc/ia64 are FTBFS... so it might take another upload to get them there
<sivang> Keybuk: k, noted
<Kamion> hmmmm
<Kamion> localedef is generating an LC_COLLATE locale that glibc doesn't like
<janimo> Gloubiboulga: hi
<Kamion> methinks belocs-locales-bin needs an update
<janimo> Gloubiboulga: I don;t get the thunar crash
<dholbach> Mithrandir: i'm sorry to pester you again. I forgot the depends of the liboobs-1-dev package, that's why gnome-sytem-tools ftbfs - if that's ok, I'd proceed with the upload now.
<seb128> Keybuk: do you know what happened to libbonobo 2.15.0-0ubuntu1 binaries on i386? it built yesterday but no sign of the debs for it (where amd64, sparc  and powerpc are published)
<Keybuk> seb128: yeah, we've seen that before
<Kamion> so are people still having locale problems in edgy, with specific reference to collation order?
<Kamion> 'cos I'm pretty sure I know why
<seb128> Keybuk: and you can fix it? :)
* Keybuk performs the rite of AshkEnte and summons a Soyuz developer into the circle
<Hobbsee> hmm...scary.
<Keybuk> Hobbsee: ?
<Hobbsee> Keybuk: the idea of you performing an AshkEnte rite :P
<Kamion> actually, bizarrely, I can't get it to affect a real system, but it affects installation-locale, so go figure
* Hobbsee ducks
<Keybuk> Hobbsee: I'm running low on mouse blood though, and the buggers haven't come back since I last thwarted their squatting attempts
<Hobbsee> Keybuk: ahh.  hehe
<Gloubiboulga> janimo, it happens every time I use it here
<janimo> Gloubiboulga: weird
* Hobbsee sends Keybuk many dead mice, thru his letterbox.
<Keybuk> :'(
<Hobbsee> Keybuk: well, it would mean that you werent running low on mouse blood anymore :P
<Keybuk> they'd dry up in the post
<Hobbsee> mdz: ping?
<Keybuk> Hobbsee: slightly too early for mdz
<Hobbsee> Keybuk: i realise that, i may end up having to pass on a message.  it's 1am here now.
<dholbach> http://wiki.ubuntu.com/GenBunToo
<Hobbsee> hi dholbach 
<dholbach> hi Hobbsee
<Keybuk> "It would also install a step-by-step "setup wizard" that autodetect your processor type based on CPUID function, and let you confirm your processor type, and recommend optimizations that will benefit you."
<Keybuk> yeah, because /proc/cpuinfo is TOO EASY
<ogra> haha
<seb128> Mithrandir: ok to upload a gnome-vfs2 which makes libgnomevfs2-dev Depends on libdbus-glib-1-dev? gedit ftbfs due to that at the moment
<Hobbsee> Keybuk: mdz is really the one i need to talk to about getting a fix into dapper updates?  it's just a rebuild, universe package
<Keybuk> Hobbsee: kamion would be just as good
<Hobbsee> right, i was told mdz
<zul> dholbach: yeah GenBunToo is crack
<Hobbsee> 09:49	mdz	To do
<Hobbsee> 09:49	mdz	* Thank people for merging WvDial and WvStreams
<Hobbsee> haha.  not a problem :)
<ogra> zul, but a funny read :)
<zul> ogra: makes me all feel tingly then i want to run away
<Riddell> Mithrandir: can I rebuild some kde packages?  there's no changes
<pitti> $ gdb /usr/bin/gdb `pidof gdb`   ... meta-debugging at its finest
<fabbione> Kamion: not too long ago i did ask mdz permission to upload a xorg-server to dapper-updates and he did agree to it but i haven't seen it unleashed in the archive... 
<fabbione> Kamion: do you think you can give it some love?
<Keybuk> fabbione: cc response to ubuntu-archive
<fabbione> Keybuk: ubuntu-archive@lists. ?
<Keybuk> aye
* ogra wonders why libkiten1 can trigger anything for main inclusion ... on anasatcia ...
<ogra> it was never in main afaik ...
<fabbione> <minirant>this stuff is becoming too burocratic</minirant>
<ogra> fabbione++ 
<Keybuk> it's a released distro, you need to get the RM's permission
<Hobbsee> Kamion: ping?
<Keybuk> this has never changed
<Kamion> fabbione: I may just not have got round to processing it; I'll see if I have the mail
<Kamion> Hobbsee: yes?
<ogra> Keybuk, but the communication channels change 
<fabbione> Kamion: thanks dude
<ogra> there is less and less personal interaction ...
<Kamion>  o libkiten-dev libkiten1                                             {kdeedu}
<Kamion>    [Reverse-Depends: Rescued from kdeedu, libkiten-dev] 
<Hobbsee> Kamion: can i get http://revu.tauware.de/details.py?upid=2699 uploaded to dapper-changes please?  it's just a rebuild, which allows kcemirror to be removed without breaking
<ogra> Kamion, ah, damned, i always forget about supported 
<Riddell> ogra: it's the new magic that ucks in -dev packages
<Kamion> ogra: you need an Extra-Exclude: libkiten-dev in your seeds (and/or maybe kubuntu seeds as well) to avoid that getting sucked in by the general "include all *-dev" rule, if you don't want it.
<Keybuk> ogra: that's only because we have more people in roles to avoid the "kamion would love to answer you, but he's currently got 1,500,000 things on his TODO list since this morning" problem
<Keybuk> so it's a mailing list, not a person
<ogra> Kamion, no, its fine edubuntu has kdeedu in supported, but only very less of it in ship/desktop
<ogra> i just forgot to look in there :)
<Kamion> Hobbsee: sure; please get somebody to upload it, and mail this IRC snippet to ubuntu-archive@lists.ubuntu.com so we have a record
* Hobbsee looks around.  okay then.
<Kamion> ogra: kdeedu yes, but did you definitely intend to have libkiten-dev there? it's currently in universe
<ogra> Keybuk, i know *why* it is this way ...
<ogra> Kamion, no, not really 
<Kamion> fabbione: do you happen to know the subject line?
<ogra> i'll add the exclude
<Keybuk> ogra: and it's not a major change, really;  and means that you have grounds to complain a few days later when things haven't been done ... there's a mail in a list archive recording the approval
<ogra> Keybuk, yes, i dont say its all bad ... but it has its disadvantages ... it keeps people more distant than before
<fabbione> Kamion: xorg-server update for dapper
<fabbione> Kamion: i did send it a couple of days ago or so
<fabbione> probably more
<Kamion> ok, I don't have it, please forward
<Keybuk> ogra: I don't necessarily disagree with you ... I don't think things like Malone are a substitute for inter-personal communication
<fabbione> Kamion: sure thanks
<Keybuk> mailing lists are inter-personal communication though, it just lets you send to a group of people
<Keybuk> 'tis one of the reasons we dropped using Malone for MoM, works better if you just /msg the guy who did it last and see whether they want a lock, or have useful information
<ogra> yep
<ogra> we should be careful to not slip into to much "tooleritis" and keep up good communication in areas where its possible
<Kamion> fabbione: I'm particularly impressed that every single file touched in that diff needs a different error handling function :-)
<Kamion> oh, huh, that was cced to me
<Kamion> I wonder where I put it
<fabbione> Kamion: that's from upstream.. don't ask me.. i don't want to know :D
<Kamion> anyway, accepted, thanks for the nudge
<Kamion> except for the way somebody apparently beat me to it
<Keybuk> YOU TOO SLOW
<Kamion> unless queue has started lying in its accept messages, which is always possible
<Kamion> Keybuk: you're just trying to make me paranoid. you and the men in black lurking outside my house
<Keybuk> Kamion: I told them to wear different colours, grr
<Hobbsee> Kamion: metho and firelighters in hand, yes.
<fabbione> Kamion, Keybuk: thanks
<janimo> Kamion: is it enough if pbbuttons is removed from the i386-desktop? the other non-PPC ones seem not to be touched
<janimo> after running update I mean
<mxpxpod> are the vmware modules on the queue to be compiled for the new kernel in dapper?
<Kamion> janimo: yes, pbbuttonsd is built for i386 and powerpc
<Kamion> s/built/only built/
* fabbione commits suicide
<fabbione> who did subscribe me to ubuntu-bugs without telling me?
<zul> yippe!
<fabbione> specially.... keeping the same list headers of the old bug list for bugzilla
* Hobbsee revives fabbione.  none of that is allowed until X is all fixed. :P
<fabbione> my imap server does time out to open a 1.5GB IMAP FILE!
<fabbione> I HATE YOU ALL
<zul> now now fabbione calm blue ocean
* fabbione sighs
<fabbione> ok ok...
* fabbione adopts drastic solution
<fabbione> doesn't help... 
<fabbione> dovecot is too good
<seb128> Mithrandir: I've uploaded it
<Kamion> ok, I think that'll be the installer's locale fixed, after a couple of publisher runs and a d-i rebuild
<fabbione> Hobbsee: anyway X is good as a couple of hours ago for at least x86*
<Kamion> two hours for THREE LINES of changes
<Hobbsee> fabbione: ah, fair enough, i've not tried it yet.
<Kamion> hell, an alternate CD installer run even finished!
<gnomefreak> fabbione: x is fine atm just libgl1-mesa-glx is non-existent
<dholbach> is it safe to do liboobs upload now, which adds depends to the -dev package?
<pitti> BenC: do you have a minute to discuss the kernel crash helper?
<seb128> dholbach: go for it
<seb128> dholbach: Mithrandir seems to no be around and we still have many installability issues atm so I don't think it'll stop CD building
<seb128> dholbach: and we need to get g-s-t working anyway
<dholbach> what I thought
<Hobbsee> night all
<sivang> night Hobbsee 
<janimo> <OT: does anyone know about a newsreader that can use folders to groups various lists (t-bird does this for mail but apparently not for nntp) /OT>
* hunger waits for a new kernel image.
<jpatrick> janimo: akregator
<janimo> jpatrick: thanks
<BenC> pitti: yeah
<pitti> BenC: I'm currently typing an email with the details, that will be better
<hunger> Any estimation on when a kernel with fixed libata will be available in edgy?
<BenC> depends on what you mean by fixed
<seb128> Keybuk: did you figure about libbonobo 2.15.0-0ubuntu1 binaries for i386? do you know when it'll be fixed?
<Keybuk> seb128: -v
<seb128> Keybuk: 
<seb128> <seb128> Keybuk: do you know what happened to libbonobo 2.15.0-0ubuntu1 binaries on i386? it built yesterday but no sign of the debs for it (where amd64, sparc  and powerpc are published)
<seb128> <Keybuk> seb128: yeah, we've seen that before
<Keybuk> oh, that
<Keybuk> did they not turn up yet?
<seb128> no
<seb128> and that break gnome-python atm
<Keybuk> probably in this publish run
<seb128> ok, cool
<seb128> thank you
<Keybuk> I have a recipie for rescuing those now
<seb128> what is happening to them in the first place?
<Keybuk> various failures between them being built and reaching the archive
<Keybuk> they're not lost, they just get stuck
<seb128> is there some sort of notifications of that issues happening or should you ping somebody to get it fixed when that happens like that? :)
<seb128> s/you/we
<pitti> BenC: I mailed you about the problem
<BenC> pitti: ok, thanks
<Keybuk> seb128: HAHAHAHAHAHAHA
<Keybuk> NOTIFICATIONS!
<Keybuk> BWAHAHAHAHAHAHA
<Keybuk> SOYUZ!
<Keybuk> geeeez
<Keybuk> *breathe*
<Keybuk> *breathe*
<pitti> BenC: I hope it's not too hard to fix, would be unfortunate to drop the idea with the kernel hook
<seb128> hum, ok, I'll keep pinging people when something not normal happens then ;)
<seb128> driving soyuz seems to be a lot of fun :p
<Kamion> ok, who buggered grub? or initramfs. or whatever it i.
<Kamion> is
<BenC> Kamion: edgy kernel?
<Keybuk> Kamion: hmm?
<Kamion> BenC: fresh edgy install
<Kamion> disnae boot
<BenC> Kamion: kernel-package was buggered, and latest edgy kernel doesn't create an initramfss
<Keybuk> Kamion: I'm frankly not surprised
<Keybuk> though, a little more -v please :)
<BenC> uploading a new kernel in an hour or so
<Kamion> yeah, my wife just nicked that machine so it'll be a moment
* mjg59 misreads kamion as keybuk there, and gets very confused
<Keybuk> though, given what BenC says, I suspect that's the problem
<Keybuk> which reminds me, must read up on what this kinit thing is
<BenC> pitti: you're going to have to get snazzy with this thing
<BenC> pitti: the oddness is that basically the crash dump helper is being called in a kernel context where the program is on it's way down the tubes, and it stops that process to call this program
<BenC> pitti: you really need to fork(), start gdb, detach from the dump helper, and let the dump helper die
<Amaranth> would the kernel have anything to do with my multimedia keys suddenly breaking?
<Amaranth> i can't think of anything else that changed in dapper recently that would do it
* Amaranth will boot in old kernel to find out
<ogra> Amaranth, for me the right/middle mousebutton emulation on the keyboard stopped 
<ogra> bah, to slow
<Kamion> Keybuk: I guess you probably don't care, but the devfs rules in udev are well buggered
<ogra> Amaranth, for me the right/middle mousebutton emulation on the keyboard stopped on my ibook ...
<Keybuk> Kamion: really?  I didn't change them
<Amaranth> ogra: my play/pause, stop, prev, and next buttons died
<ogra> i suspect the kernel but have fond no evidence yet :)
<Amaranth> ogra: they worked fine once i rebooted with -25
<Kamion> I have /dev/discs/disc0 -> ../sda1, /dev/discs/disc14/disc -> ../../sdb, /dev/discs/disc15/disc -> ../../sda, /dev/disc{3,5,7,9} -> sda1
<Keybuk> sweet
<Kamion> I hadn't been planning to move implementation of no-more-devfs quite far enough forward to be there for knot-1, so a fix would be nice ;-)
<Kamion> what do you need?
<Keybuk> tbh, I have absolutely no idea
<Keybuk> Kamion: could be worth changing storage_enum.sh to be #!/bin/bash and seeing whether that helps
<Kamion> ENOBASH
<Kamion> this is in d-i rescue mode
<Keybuk> good point, won't be that then
<Keybuk> you really have /dev/discs/disc0 -> ../sda1 ?!
<Kamion> aye
<Keybuk> with the "../sda1" as the real symlink target
<Kamion> yeah - /dev/sda1 does exist
<Keybuk> no, I mean that's what readlink() returns?
<Keybuk> ls -l /dev/discs
<Kamion> yes
<Kamion> disc0 -> ../sda1
<Kamion> disc14
<Kamion> disc15
<Kamion> the latter two being directories
<Keybuk> and no disc3,5,7,9 ?
<Kamion> those are directly in /dev
<Keybuk> fruity
<Kamion> oh also /dev/disc{11,13} -> sda1
<Keybuk> udevinfo -q symlink -n sda1
<Kamion> discs/disc0 disc3 disc5 disc7 disc9 disc11 disc13 disc15/part1 disk/by-uuid/eb48b2bb-5c67-4925-bbdf-d21b18f728dc
<Kamion> /dev/disc15 has part1 -> ../sda1, part2 -> ../sda2, part5 -> ../sda5
<Keybuk> sh -x /lib/udev/storage_enum sda
<Kamion> BTW, is udev supposed to be a native package?
<Keybuk> Kamion: no, that was an accident
<Keybuk> I couldn't spell orig right that day
<Kamion> aiee libnss-*-udeb must be funted too
<Keybuk> hmm?
<Kamion> can't scp
<Keybuk> is the last line an echo ?
<Keybuk> or an each near the last line, anyway
<Keybuk> what's that say?
<Kamion> hang on, trying to extract the full trace for you
<Kamion> Keybuk: http://paste.ubuntu-nl.org/17935
<Kamion> had to copy/type that but I think it's accurate
<Keybuk> can you do the same with sda1 ?
* Kamion notes [ disk = disc ]  there, maybe some confusion?
<Keybuk> yeah that might be the bug
<Keybuk> but it doesn't explain the really wacky symlink names
<Kamion> Keybuk: http://paste.ubuntu-nl.org/17936
<Keybuk> oh, now that does explain the wacky names
<Keybuk> yeah
<Keybuk> it's the disk = disc thing
<Keybuk> that must be a bug in dapper too :p
<Kamion> certainly never showed up in the same way
<Kamion> the installer totally wouldn't have worked
<Kamion> Keybuk: anything else you need from me? I'm being called away
<Keybuk> just approval for a new udev upstream version that fixes a few bugs
<Keybuk> notably that path_id one
<Keybuk> I can bundle this in with that
<Kamion> mail the changelog to me and mdz?
<Kamion> I'll look at it tonight if he doesn't beat me to it
<Keybuk> this is udev
<Keybuk> it doesn't have useful changelogs
<Keybuk> I can mail you the diff
<Kamion> Keybuk: ok
<Kamion> I thought udev had RELEASE-NOTES
<Kamion> but the diff is fine
<Keybuk> actually, I'll just upload a fixed 093 for now
<Keybuk> this drags in a messy change which might break out network device renaming
<Kamion> ok
<Kamion> thanks
<LaserJock> did the development team meeting already happen?
<Keybuk> LaserJock: this morning, yes
<LaserJock> Keybuk: darn
<Keybuk> 0700 UTC
<LaserJock> yeah, it was midnight last night for me :/
<LaserJock> got confused
<AlinuxOS> mjg59, hi.
<AlinuxOS> mjg59, have got some time ?
<pitti> BenC: fork() the crashed program, you mean?
<pitti> BenC: ah, I see; fork() the crash-helper, setsid(), and quit the original instance
<pitti> BenC: and take care that the forked crash-helper calls gdb before the orginal crash-helper quits?
<mdz> seb128: I find the new gaim message received sound much more pleasing
<pitti> (it's a bit like lifting yourself out of a marsh by pulling on your hair :) )
<pitti> mdz++
<seb128> mdz: yeah, new sounds are nice :)
<mdz> woo, ubuntu-meta all installable on i386
<mdz> do we have livefs builds then?
<pitti> BenC, zul: do you have some minutes to join #debian-security on OFTC?
<zul> i think i can
<Kamion> mdz: I've just kicked some off, although they so much won't work sanely :)
<Kamion> I think Mithrandir needs to put our casper back together first
<Chipzz> Keybuk: I doubt this is in the right context, but kinit is the kerberos 'login' program
<ogra> argh ... bashism in ltsp-build-client ...
<Keybuk> Chipzz: nah, wrong context
<pitti> doko: your gcc upload almost sounds like if it would avoid the manual bootstrapping
<mdz> Kamion: which machine does CD builds now?
<Keybuk> kinit is the things that are in the kernel at the moment, but are become a initrdspace utility that you run instead
<Keybuk> I don't yet understand why it's referred to as a single binary, and not just a collection of useful things
<Kamion> mdz: lithium
<Kamion> most of the livefs build attempts failed quickly; logs should be available soon
<Kamion> terranova (i386) is still running
<mdz> do we still have that python-gnome2-desktop installability issue?
<doko> pitti: no
<Kamion> and is managing to install the desktop
<mdz> that would kill non-i386 pretty quickly
<Kamion>   ubuntu-desktop: Depends: deskbar-applet but it is not going to be installed
<Kamion>                   Depends: evolution-exchange but it is not going to be installed
<Kamion>                   Depends: gedit but it is not going to be installed
<Kamion>                   Depends: gnome-app-install but it is not going to be installed
<Kamion>                   Depends: gnome-applets but it is not going to be installed
<Kamion>                   Depends: openoffice.org but it is not going to be installed
<Kamion>                   Depends: serpentine but it is not going to be installed
<Kamion>                   Depends: totem but it is not going to be installed
<Kamion> that's amd64
<Kamion> powerpc is more spectacular, but we know it's bust due to needing a gcc bootstrap (which infinity has started)
<Kamion> damn, can't upload glibc until I get that gcc bootstrap, I think
<bluefoxicy> Kamion:  personally I get annoyed with "upgrade will remove gnome-something-perl, ubuntu-desktop" because ubuntu desktop depends on a perl module for unknown reasons
<Kamion> bluefoxicy: unknown to you
<bluefoxicy> yes that's generally what 'unknown' means when someone says it
<Kamion> the comment in the seeds explains it perfectly well
<bluefoxicy> there's comments in the seeds?
<Kamion> and I don't know why you suddenly brought this up, it's irrelevant here
<Kamion> y4es
<Kamion> yes
<Kamion> desktop: * libgnome2-perl          # for synaptic
<bluefoxicy> ah -- ..... why does removing that not remove synaptic?
<dholbach> bluefoxicy: because ubuntu-desktop depends on it, not synaptic
<Kamion> it's not a dependency, but if you don't have it then debconf doesn't display its GNOME frontend which means that synaptic would have to open a terminal
<bluefoxicy> aha!
* Kamion improves the comment
<bluefoxicy> ChangeLog:  * Improve the comment for libgnome2-perl -- Kamion
<Keybuk> \o/
<Keybuk> I now have a task-by-task project plan
<pitti> Keybuk: for init-goes-on-crack?
<Keybuk> aye
<bluefoxicy> this reminds me, I would immensely enjoy no-op upgrades in dpkg, re those times when I gotta download say 100 megs of OpenOffice.org because somebody fixed a typo in the description in debian/control or something silly like that
<bluefoxicy> one of the ChangeLogs I saw was in its entirity fixing debian/watch or something silly like that, warranting an entire new binary package download and install
<bluefoxicy> and I was like, "Wait... the program is the same.. some of the irrelavent meta-data in the package changed... this won't affect anyone's system... why the hell am I downloading this?"
* bluefoxicy guesses that can be ignored until Edgy+5 or something
<msw> bluefoxicy: that's one conary feature I love - the upstream sources aren't downloaded when you're editing the build control files (maybe no more source packages can get there in the future)
<Keybuk> conarubuntu
<ogra> sigh 
<ogra> dash bites back ...
<bluefoxicy> msw: Yes but do you get to notice a new updated package that has only build-deps changed, and not download and install the upgrade?  :>
<ogra> the replacement for x-window-system-core is just xorg ?
<Kamion> bluefoxicy: 'cos build-deps NEVER influence the content of the package :-P
<bluefoxicy> Kamion:  do they ever?  :P
<dholbach> can gnome-system-tools please be given back?
<tseng> dholbach: keybuk is gone.
<Mithrandir> Riddell: you're free to rebuild KDE as much as you like, yes.  If you break the rest of the distro, I might be angry with you, but as long as you only change KDE, it should be safe enough. :-)
<mdz> oh NO, text selection in gnome-terminal is completely broken
<dholbach> hmm, somebody else with give-back supahpowah? if not... Mithrandir: can I do a rebuild-only-upload of gnome-system-tools?
<tseng> dholbach: ive been told only keybuk, infinity can give back, i think you are talking to yourself
* dholbach thinks tseng is making fun of him
<tseng> I'm serious!
<dholbach> i'm just kidding - i guess i'll have to do a no-changes upload then
* tseng hugs dholbach 
* dholbach hugs tseng back
<Mithrandir> dholbach: I can't give-back, but feel free to upload a no-change.
<tseng> dholbach: did anyone fix up gnome-power-manager?
<dholbach> Mithrandir: gracias
<dholbach> tseng: ogra is still working on it
<tseng> ok, cool
<dholbach> and on gnome-screensaver
<tseng> im not sure what is up with 2.15
<tseng> it wont let me suspend
<seb128> needs hal policekit?
<tseng> maybe
<tseng> policykit
<tseng> i definately saw it think it was available in configure
<tseng> good guess.
<profoX`> hi
<profoX`> Does anyone know what program is in charge for displaying the OnScreenDisplay and changing the volume, when you press volume keys on your media keyboard / laptop ?
<smorsony> Can I ask questions about wmi here?
<jdub> profoX`: gnome-settings-daemon
<jdub> smorsony: wmi?
<profoX`> jdub: thank you :) was looking for ages
<smorsony> Looking for a way to get the system model info as I can with wmi on windows.
<HWolf> smorsony, please try #ubuntu or your local ubuntu channel
<jdub> smorsony: dmidecode might help
<profoX`> jdub: is it part of gnome-control-center ? i have to download the source package
<smorsony> Thanks jdub :)
<jdub> profoX`: yes (btw, dpkg -S is handy for working that stuff out)
<profoX`> jdub: oh yes thanks for the tip
<profoX`> when i apt-get source, do i need to patch with the included diff to get the ubuntu package? or is that already done?
<profoX`> ubuntu sources *
<ogra>   ldm: Depends: openssh-client but it is not going to be installed or
<ogra>                 ssh but it is not going to be installed
<ogra> hmm
<ogra> that doesnt look like we'll have a working ltsp soon ... all deps for ltsp-cliennt fail :(
<LaserJock> profoX`: apt-get source unpacks and applies the diff
<profoX`> LaserJock: ok thanks
<mdz> rodarvus: did you find out about xserver-xorg-input-elographics?
<mdz> rodarvus: it's been in main since it first existed in breezy
<mdz> rodarvus: so unless it's been deprecated upstream, I think it should probably be depended upon or seeded
<stratus> ogra: hi. something wrong with the ltsp packaging or the deps?
<ogra>  aptitude: Depends: libapt-pkg-libc6.3-6-3.11 but it is not installable
<ogra>   discover1: Depends: libdiscover1 but it is not going to be installed
<ogra>              Depends: discover1-data (>= 1.2004.09.24) but it is not going to be
<ogra> GRUMBLE !!!
<ogra> stratus, we just changed to debians xorg ... ltsp will need adjustment there and i only have ppc here, my amd64 work machine dies yesterday 
<ogra> *died
<ogra> currently ppc is the worst you can use for development 
<ogra> (in ubuntu)
<stratus> ogra: hmm, but the ltsp (in debian) works with our xorg. i only have ppc here now too and without hard disk atm.
<ogra> i'm happy i can type at least ... 
<jdub> can we still do sync requests for universe stuff, or should we just upload?
<ogra> jdub, universe is open until sept ...
<tseng> jdub: request a sync
<tseng> file a bug
<tseng> *subscribe* ubuntu-archive
<tseng> not assign
<zul> later
<ogra> stratus, but debian didnt just break half the world deliberately ... and debian doesnt want to release a milestone CD the next days ...
<jdub> rad, 'cos one of my mission critical apps needs some love :-)
<jdub> tseng: i jsut use pitti's script ;)
<tseng> cool
<ogra> i fear edubuntu has to skip that one, i wont be able to fix that in time :/
* ogra will buy a new amd64 laptop tomorrow and we'll see ...
<stratus> ogra: heh ok then.
<msw> bluefoxicy: if the user asks to update something, we'll calculate differences between what they have installed and the new version.  in cases of build deps changed, normally the actual changes are very small.  don't know if that addresses the question, though...
<bluefoxicy> msw: so if you ship openoffice.org-writer 2.0.2-ubuntu17 to fix a build-dep inaccuracy in -ubuntu16 it won't redownload a 36 megabyte package and the other 15 10-20 meg packages that got rebuilt with it and install it?
<crimsun> eek
<crimsun> doko: sorry about that, thanks for fixing
<msw> bluefoxicy: it would download the new (hopefully smaller than 36 MiB) -ubuntu17 package.  As for the other packages, it depends on what the user asked to do.  One important thing about what we do with our distro is how we control the individual package versions through groups.  "update everything" usually means "update group-os".  If group-os doesn't include OOo-2.0.2-ubuntu17, it won't get updated.  Once the new group is updated, everything gets updated (th
<msw> bluefoxicy: (I'm not explaining it well at the moment)
<bluefoxicy> msw:  okay, well whatever.  I'm going to McDonalds.  I'm rather sure I don't understand how this works.
<msw> bluefoxicy: enjoy.
<rodarvus> mdz: xserver-xorg-input-elographics is not deprecated upstream, lets fix it, then
<Kamion> ogra: can you please quit complaining about the powerpc situation? :-) we know what it is, it needs the gcc bootstrap which infinity is doing
<rodarvus> mdz: I'm working on it, now
<mdz> rodarvus: thanks
<rodarvus> mdz: who do I ask to seed -elographics? (I suppose either you or Kamion?)
<mdz> rodarvus: if it shouldn't be a dependency of -input-all, you can seed it yourself
<mdz> rodarvus: https://wiki.ubuntu.com/SeedManagement explains how
* rodarvus reads it
<siretart> Mithrandir: I have a quite big update for lib-xine. is it okay to upload, or shall I wait until after knot 1 release?
<fabbione> mdz: -elographics is not deprecated. it was moved to main in dapper for some IBM hw. There was a specific Depends: in xorg
<fabbione> mdz: it might happen that it got lost in the merge
<Kamion> anyone who cares to figure out why glibc won't build any more on powerpc would be welcome ...
<mdz> fabbione: it was in main in breezy too
<mdz> fabbione: but it was never seeded before
<mdz> Kamion: I'm puzzling out amd64 at the moment
<mdz> it's in pretty bad shape from the look of it
<fabbione> mdz: we did demote -input- stuff only in dapper
<fabbione> before it was all in main
<mdz> fabbione: it's not seeded in dapper either; something must have depended on it
<fabbione> mdz: yes i did add the Depends: in source xorg 
<fabbione> mdz: it might have been lost in the merge (that i did not do or check)
<mdz> rodarvus: ^^
<fabbione> mdz: i alreayd told him
<fabbione> he is checking
<mdz> ok then
<fabbione> nothing to panic about. it's a quite special piece of equipment anyway
* fabbione heads towards bed for real now
<mdz> there is no panic
<fabbione> there is no cabal
<fabbione> ;)
<fabbione> good night fellas
<rodarvus> xorg is updated - I'm just testing it locally before upload
* sivang is looking forward for the xorg upgrade
<jbailey_> sivang: Why, your internet connection too speedy these days?
<jbailey_> =)
<sivang> jbailey_: Jeff! :-)
<sivang> jbailey_: actually the cable guy was here the afternoon, and net seems to be quite fast. almost utilizing my whole bandwidth
<rodarvus> mdz: done
<rodarvus> I checked the seeds, and no -input driver is mentioned manually (with exception of -synaptics)
<rodarvus> the others are included via xserver-xorg-input-all->xserver-xorg->xorg
<rodarvus> also, I have just uploaded xorg_7.0.22ubuntu4, with xserver-xorg-input-all depending on -elographics (for i386 only, though)
<Chipzz> rodarvus: local upgrade here didn't work
<Chipzz> are not like intended
<rodarvus> Chipzz: what didn't work?
<Chipzz> I had xserver-xorg-driver-i810 installed
<Chipzz> that and only that
<Chipzz> well no
<rodarvus> Chipzz: when did you upgraded?
<Chipzz> xserver-xorg-driver-i810 and xserver-xorg-driver-vmware
<Chipzz> but for all intents and purposes, that's the same
<rodarvus> xserverx-xorg requires xserver-xorg-video-all | xserver-xorg-video (the second one is provided by all -video drivers)
<Chipzz> ie I did not have xserver-xorg-driver-all
<rodarvus> brb
<Chipzz> it pulled all the *-video-* packages
<rodarvus> Chipzz: anyhow, later today I'll hack a local installation just to have -i810 here, and test the upgrade path
<Chipzz> rodarvus: lemme copy/paste
<Chipzz> just a sec
<rodarvus> Chipzz: note that the upgrade is only supposed to happen if you have xorg 7.0.22 >= ubuntu3
<Chipzz> http://chipzz.studentenweb.org/xorg-up
<Chipzz> this should *not* have pulled in xserver-xorg-video-all
<mdz> rodarvus: does -synaptics need to be explicitly seeded, or is it an indirect dependency of -desktop now?
<rodarvus> mdz: I don't know why it is explicitly seeded - as it is included as an indirect dependency
<mdz> rodarvus: ok, then please remove it
<mdz> rodarvus: it probably wasn't at the time
<rodarvus> will do
<rodarvus> xorg is accepted
<rodarvus> mdz: desktop seed is updated
<rodarvus> I'll need to leave for 2-3 hours, but will be back later today to check if everything is ok, or if there is any extra interaction needed urgently
<rodarvus> Chipzz: also as soon as I get back I'll make sure everything is ok WRT drivers upgrade (should be)
<mdz> vcdimager promotion is blocking xine, which is blocking totem, which is blocking gnome-python-extras which blocks THE WORLD
<Kamion> Chipzz: looks like you had removed stuff with --force-depends, or had a locally rebuilt version of xserver-xorg
<Kamion> Chipzz: in the first case, that's not supported, sorry; in the latter case, rebuild it again based on the new version
<siretart> mdz: err, how can vcdimager (universe) block xine (main)?
<mdz> siretart: exactly
<mdz> xine grew a build-dep on vcdimager
<siretart> oh
<Kamion> Chipzz: but honestly, being able to remove drivers was never a particularly important goal of modularisation; the important goal was being able to update them and hack on them separately
<siretart> right.. hrmpf
<mdz> Kamion: the dependencies do allow it, though I"m not convinced they should
<Chipzz> Kamion: I have neither
<Chipzz> Kamion: the command I issued should have upgraded fine
<Kamion> oh, as mdz points out the dependencies do allow it
<Kamion> but you will have to tweak it with a package manager more sophisticated than apt-get, probably
<Kamion> I do not expect that the dependencies can/will easily be fixed for your situation
<Kamion> the logic is not something that we can really express
<Kamion> and you can always go and remove the ones you don't want again, so no big deal
<Chipzz> Kamion: the command I issued should not have pulled in xserver-xorg-video-all
<Kamion> *shrug*
<Chipzz> the upgrade path should have worked (I think)
<Kamion> there's nothing wrong with the dependencies; it would require an apt change
<Kamion> (retroactively, in dapper)
<jdub> Kamion: you got latest edgy apt?
<jdub> or anyone else
<jdub> deb http://people.ubuntu.com/~jdub/edgy /
<siretart> mdz: I think I could disable vcd support in xine, in order to work around the vcdimager dependency
<jdub> add this guy, see if you get a 404 on Packages.gz when doing update
<siretart> temporarily, that is
<jdub> (the source only has bz2)
<Kamion> jdub: no, can't upgrade it on powerpc yet without removing aptitude
<mdz> siretart: I'm doing a review of vcdimager, seems fairly sane so far
<mdz> siretart: hmm, hasn't had an upload since November
<mdz> no new upstream releases since then either
<mdz> siretart: is it easy to disable?
<mdz> if so, please go ahead; it's blocking a lot of builds
#ubuntu-devel 2006-07-14
<siretart> looking at configure.ac, it seems just a matter of droppen build-deps. I'm checking that
<mdz> i386 got lucky and built totem before the new xine-lib
<Kamion> mdz: http://people.ubuntu.com/~cjwatson/livefs-build-logs/edgy/ubuntu/current/livecd-20060713-i386.out
<Kamion> FYI, seems to have worked
<mdz> Kamion: nice; if you want to roll a CD I'll give it a whirl
<Kamion> I've kicked off an i386-only CD build
<mdz> for giggles
<Kamion> good luck :)
<Kamion> I'm off to bed
<mdz> night
<Kamion> mdz: there are amd64 and i386 alternate CD builds up already, BTW
<Kamion> they sort of work if you fudge the localechooser bug I fixed earlier today
<Kamion> (edit /usr/bin/localechooser, put || true after all the db_unregister commands)
<mdz> Kamion: report.html is not very encouraging
<Kamion> it seems to manage to install anyway; I tried it in vmware
<Kamion> not exactly sure how
<Kamion> though that was i386
<mdz> ooh, hierarchical cdimage logs
<Kamion> I assume X has managed to hit a corner case that confuses britney and not apt
<Kamion> yeah, got bored of the mess and did that today
<mdz> Kamion: X or python*
<mdz> python* is confusing apt right now in many situations
<Kamion> right, really bed
<siretart> mdz: ok, I have now a xine-lib package prepared, which builds fine in my main/restricted only sbuild/amd64. vcd support is unclear, but at least it builds!
<siretart> mdz: okay to upload? (I read in topic that uploads are restricted)
<beeblebrox> hi, i was looking at the edgy repository and it seems that there is no trace of xorg 7.1 and gnome 2.15. any reason? isn't edgy supposed to be released in just 2.5 months with state-of-art packages?
<msw> beeblebrox: rodarvus is doing testing before uploading updated xorg stuff
<slomo> beeblebrox: and gnome 2.15 is there
<mdz> siretart: yes, please
<jbailey_> _kylem: Heya kyle.
<kylem> hi.
<kylem> pay no attention to the man with the underscore.
<jbailey_> kylem: That's one way to tell me you're going to ignore me ;)
<kylem> heh.
<kylem> not quite what i meant... :)
<siretart> Hello kylem!
<kylem> hi reinhard
<siretart> mdz: xine-lib (main) and xine-extracodecs (multiverse) accepted
<siretart> gn8 folks
<mdz> thanks, night
<slomo> siretart: gn8 and thanks for xine :)
<rodarvus> beeblebrox: GNOME 2.15.4 is already in Edgy
<rodarvus> XOrg 7.1 will (very likely) start being uploaded after Knot 1 is released
<rodarvus> (but please don't take this as an official statement :) )
<bluefoxicy> Knot?  wtf isa knot
<beeblebrox> rodarvus: thanks :)
<jbailey_> bluefoxicy: The rodents are into bondage, apparently. =)
<rodarvus> bluefoxicy: Edgy development milestones
<sivang> heh
<rodarvus> same as "flight" for Dapper
<bluefoxicy> jbailey_:  err.. yeah you could say a LOT worse if you want to go that route.
* jdub hugs jbailey_ 
<bluefoxicy> but we won't go into that.
<jbailey_> bluefoxicy: True.  I'm really looking forward to the openning quotation for the milestone releases.  I have some I could offer, but I think they might not be accepted... ;)
<rodarvus> haha
<bluefoxicy> I'm sure if I said anything about it they would change the name.
<sivang> jbailey_: anything close to the lymmrick would be cool :)
<bluefoxicy> just because the devs would not be able to look at it without cringing.
<jbailey_> sivang: My limerick was pure angst.  I'm feeling much better now that I'm at home. =)
<sivang> jbailey_: maybe, but it's driven *hours* of pure un adolterated laughter =)
<sivang> jbailey_: and I'm glad you're feeling better.
<jbailey_> sivang: hours?  Oh dear.
<sivang> jbailey_: oh well, hours is too much, but certainly some parts of some hours :)
<bluefoxicy> jbailey_:  This is humorous.
* LaserJock chuckles for a while
<bluefoxicy> sivang:  limmerick?  I missed this.  Rafb please.
<LaserJock> jbailey_: I think that was definately one of the highlights of the trip ;-)
<jsgotangco> ahhh
<LaserJock> made a long week of specs seem a whole lot better
<bluefoxicy> jbailey_:  what are they talking about?
<jsgotangco> i agree
<sivang> LaserJock+++++
<jbailey_> bluefoxicy: I had a brief moment where I forgot that I was an introvert at the UDS-Paris final dinner.
<bluefoxicy> jbailey_:  and this is funny how?
<jbailey_> bluefoxicy: When this sort of thing happens, it's apparently worthy of attention.
<jbailey_> bluefoxicy: I'm not exactly objective, I'm not the right person to ask.
<jsgotangco> you have to know/meet jbailey_ personally
<LaserJock> bluefoxicy: sorry, I think you had to be there
* jsgotangco remembers the scenes at the hotel lobby at dawn
<LaserJock> bluefoxicy: jbailey_ had a wonderful limmerick full of angst, amongst other things :-)
<bluefoxicy> LaserJock:  it's not something I can google for is it?  :>
<LaserJock> nope
<sivang> jbailey_: you're use of words...oh man, it is a master piece, what made it so funny for me , was, that I couldn't have put it better. It had much of the truth in it :)
<bluefoxicy> also jeff
<sivang> bluefoxicy: and better not find it there :)
<bluefoxicy> do you have any relation to Justin Bailey?
<bluefoxicy> (this guy on another channel's real name was that!)
<jsgotangco> oh goodie no email for me
<sivang> anywya, slipping out from my timezone again, night all
<slomo> sivang: gn8 :)
<sivang> night slomo :) 
<DB2> hi, can anybody explani me gaim-dev?
<tseng> whats to explain?
<DB2> if i wanna make a gaim plugin, what do i need ?
<tseng> gaim-dev, and possibly others.
<tseng> depending on the package
<DB2> is there a documentation on how do i use it ?
<jsgotangco>  If you are creating a gaim plugin package, please be sure to read
<jsgotangco>  /usr/share/doc/gaim-dev/README.Debian.dev after installing gaim-dev.
<jsgotangco> aptitude show gaim-dev
<DB2> yeah, it doesnt say anything
<jsgotangco> DB2: ^^
<jsgotangco> ahh
<DB2> i've seen that
<jsgotangco> gaim site doesn't have documentation?
<DB2> pretty useless of instruction of how to compile a plugin
<zul> have you checked gaims website?
<DB2> trying
<DB2> where do i d/l the gaim source used in ubuntu?
<DB2> nm
<Hobbsee> hi all
<theCore> vuntz: do you know where the script for the logout dialog is located?
<bluefoxicy> http://www.killernic.com/KillerNic/  Edgy should have drivers for this
<zul> open up a bug in lp
<Hobbsee> hi zul 
* Hobbsee wonders why it's so quiet
<jdub> zomg that is the dumbest crack ever
<bluefoxicy> zul:  take some advice from jdub, go actually look ;)
<_ion> Haha, funny.
<zul> im too tired to
<pitti> Hi everyone
<crimsun> 'morning pitti
<Burgundavia> morning pitti
<Hobbsee> hey pitti!
<Hobbsee> hi Burgr
<Hobbsee> hi Burgundavia 
<Hobbsee> gah, cant spell
<Burgundavia> Hobbsee: comes from using KDE :)
<Hobbsee> Burgundavia: heh
<Burgundavia> I guess I should say "It komes from using KDE"
<Hobbsee> heh
* Burgundavia turns his troll mode off
<crimsun> err, someone in #ubuntu thinks that having /root mode 0755 is a security hole.
<bluefoxicy> crimsun:  depends on what's stored in /root
<bluefoxicy> crimsun:  in general there is no reason to have /root world readable though
<bluefoxicy> arguments made for world-readable /home aside
<crimsun> I think arguing for it to be mode 000 is hardly a preventive measure.
<bluefoxicy> yeah
<bluefoxicy> 700 I would more say
<Laser_away> I guess if you put all your passwords in clear text in /root you might have a problem ;-)
<bluefoxicy> theoretically there's nothing sensitive in root though
<bluefoxicy> I mean it has what, synaptic's configuration?
<crimsun> yep, but that's mode 700.
<bluefoxicy> nothing sensitive really.  You don't browse the web from /root
<bluefoxicy> crimsun:  ~/.mozilla is 700 right?
<Laser_away> oh heck, how do you do the numbers again? I've never been able to remember
<bluefoxicy> 4 read 2 write 1 execute
<Laser_away> 7 is rwx, right?
<crimsun> bluefoxicy: yes
<bluefoxicy> Laser_away:  they're bits
<bluefoxicy> r w and x are all 1
<bluefoxicy> and - is 0
<bluefoxicy> so rwx is 111 is 7
<Laser_away> ah makes sens
<bluefoxicy> r-x is 101 is 5
<Laser_away> e
<Hobbsee> ah...now that is clever.  requires people to be able to count in binary though.
<bluefoxicy> the guys who wrote this thing were all hackers, read into it a bit, the design makes programmatic sense if you know C and assembly.
<Laser_away> Hobbsee: well, I had an instrumental analysis class were we had to get decent with binary
<Laser_away> so I can do ok
<bluefoxicy> crimsun:  I still want a power user's applet that lets me change things like that 8)
<Hobbsee> Laser_away: same here, i topped those yr 11 info processes and technology exams without any study at all - which included binary/octal/decimal/hex conversions
* bluefoxicy should fix his pam.d so that his session gets 0077 umask
<bluefoxicy> octal dec hex is easy.
<bluefoxicy> err.  octal bin hex
<bluefoxicy> decimal is not related.
<Chipzz> Hobbsee: octal, actually :)
<Laser_away> ack, what the 4 number, ugo and ?
<bluefoxicy> 2 8 16
<bluefoxicy> Laser_away:  what are you asking?
<Laser_away> in 0077 what is the 4th number for?
<bluefoxicy> Chipzz: counting in octal is not meaningful.  Convenient since each set of permissions is 3 bits, but not meaningful
<Laser_away> I always use ugo etc
<bluefoxicy> Laser_away:  the last one is for setuid, setgid, sticky, etc.
<Laser_away> ah yes
<bluefoxicy> I don't know what bits those are.
<bluefoxicy> I know sticky is 1
<Laser_away> I don't understand what exactly setuid is used for
<bluefoxicy> the file is owned by a user yes?
* Laser_away is showing his lack of CS training
<bluefoxicy> and it's in a group
<bluefoxicy> ls -l a file and it has like "Laser users"
<StevenK> setuid is used to exec a file as the owner.
<bluefoxicy> well if the file is executable, the user owning it is the effective UID of the process when the file is execve()'d
<Laser_away> so what happens if it is 0? and 1?
<bluefoxicy> su is setuid, so is sudo.  Run those, they're root.
<bluefoxicy> Laser_away:  if setuid is set, then when you run the program the user owning the file is the user it's run as.
<bluefoxicy> when you run sudo, it's run as root.
<bluefoxicy> this gets it permission to transition to a different user :P
<bluefoxicy> setgid does the same thing for egid
<StevenK> setuid is set on the highest order bits of the permissions.
<StevenK> 4755 is setuid
<Laser_away> so if it isn't set then it is run as the user how excecuted it?
<bluefoxicy> StevenK:  figured as much.  User, Group, Other... SetUID, SetGID, sticky
<bluefoxicy> Laser_away:  if it's not set then the user running it is the one that the EUID is set to
<bluefoxicy> that's why people should go to great lengths to reduce the number of setuid programs on the system
<bluefoxicy> for example in Ubuntu's init scripts we could have a wrapper script in the networking script that drops capabilities except for CAP_NET_ADMIN, switches users to nobody, and then executes the relevent networking configuration.
<bluefoxicy> hmm.. I don't know if dhcp needs CAP_NET_RAW.  It may need that as well.
<bluefoxicy> Anyway
<bluefoxicy> this would allow dhclient to be run as not root... and this has nothing to do with setuid.
<bluefoxicy> come on
<bluefoxicy> I know I've seen a handfull of setuid programs go to thin wrappers that drop caps
<bluefoxicy> Laser_away:  ANYWAY
<bluefoxicy> MOST programs on the system are owned by root
<bluefoxicy> (pretty much ALL of them)
<bluefoxicy> so every time you run a setuid program you get free root access for a very short time, in a very specific code path
<bluefoxicy> why am I talking about this
<bluefoxicy> does anyone care anymore
<bluefoxicy> my screen is 85% my own text, I'm getting lonely.
<Burgundavia> bluefoxicy: blah
<bluefoxicy> Burgundavia:  New topic.  What's going on in Edgy tomorrow.
<Burgundavia> no idea, I don't code
<Hobbsee> Burgundavia: you dont?
<Hobbsee> Burgundavia: which bits are you involved in?
<bluefoxicy> I'm waiting to play with the knot
<Burgundavia> despise it
<Hobbsee> hehe
<Burgundavia> Hobbsee: doc team, marketing, etc.
<Hobbsee> Burgundavia: ahh, nice :)
<Burgundavia> the soft stuff
<Laser_away> whatever
<Burgundavia> I do sales in my day job
<Laser_away> I've been to the doc side, and I've worked with your boss
<Burgundavia> Laser_away: btw, have you been paid?
<bluefoxicy> Burgundavia:  do you know anyone who's familiar with gcc's internals that I might be able to pry maybe a half hour out of?
<Burgundavia> nope, sorry
<bluefoxicy> damn.
<bluefoxicy> I am still trying to find someone to do that side of the compiler work
<Laser_away> Burgundavia: yes, thanks for asking, Tim said there was a snafu or something but I got it
<Burgundavia> Laser_away: perfect, glad that got sorted
<bluefoxicy> I got paid for my prelink article the other day ^o.o^
<Hobbsee> bluefoxicy: edgy+1,anyawy
<bluefoxicy> Hobbsee:  hm?
<Laser_away> me too, it helped offset my little "incident" in Paris
<Hobbsee> bluefoxicy: the compiler stuff would have to wake edgy+1, i take it
<bluefoxicy> Hobbsee:  it would, but the chunk i need written has to go to mainline anyway.
<bluefoxicy> Hobbsee:  it involves modifying the code in gcc/targhooks.c (i think it's called) for 2 functions, to change an emitted function call to pass an argument
<Hobbsee> fair enough
<bluefoxicy> I am trying to change __stack_chk_fai(), the handler called when a stack buffer overflow is detected, to __stack_chk_fail2(const char *fctn) (__stack_chk_fail() needs to stay for legacy support)
* Hobbsee knows nothing about such thinsg, and is happy to remain in ignorance
<bluefoxicy> that way we can derive the exact function that a stack smash happened in when an overflow occurs.
<bluefoxicy> My eventual goal is to get a slight hack onto glibc into Ubuntu that replaces the handler on our end (this part is in no way touching mainline) with one that collects this information, to improve reaction time wrt security vulns (because we can detect their existence earlier)
<pitti> bluefoxicy: but that would require instrumenting the code with function names
<pitti> bluefoxicy: and I do not see why this would give us more information than a gdb backtrace?
<bluefoxicy> pitti:  yes.  There is code in some places in the compiler that does this.  The preprocessor can turn __FUNC__ into the current function name
<bluefoxicy> pitti:  does every end user run every program in gdb?
<pitti> bluefoxicy: right, I'm aware of that, but that would mean to blow up the code with additional strings
<bluefoxicy> pitti: see https://wiki.ubuntu.com/GccSspEnhancements specifically.
<fabbione>  ls -las /bin/sh
<bluefoxicy> pitti:  ProPolice used to do function and source file name
<pitti> bluefoxicy: with the spec I'm working on, we will automatically get backtraces for every crashed (packaged) program
<fabbione> 0 lrwxrwxrwx  1 root root 4 Jan  4  2006 /bin/sh -> gdb
<bluefoxicy> pitti:  automatically?  You do ask the user, right?
<pitti> bluefoxicy: we'll ask the user about what to do with it, of course
<bluefoxicy> pitti:  do the backtraces contain function names?  We have address space randomization, if we just get addresses it's kind of useless.
<pitti> bluefoxicy: but we'll automatically get /var/crash/blabla report
<bluefoxicy> also how are you getting a back trace?
<pitti> bluefoxicy: yes, even stripped programs still have enough symbols to get the function names usually
<pitti> bluefoxicy: of course it's better to have debug symbols installed
<bluefoxicy> how DO you get the function names?
<pitti> bluefoxicy: we thought of that, please see wiki.ubuntu.com/AutomatedProblemReports
<bluefoxicy> pitti: won't work.
<pitti> bluefoxicy: if we don't have symbols, we can save a (reduced) core dump and restore the bt later
<bluefoxicy> "Create a small library libcrashrep.so whose init function installs a signal handler for the most common types of crashes (segmentation violation, floating point error, and bus error). The handler will catch all signals that the application does not handle itself. When a crash is detected, the library calls an external program. The library is put into /etc/ld.so.preload."
<bluefoxicy> pitti:  in the case of a stack buffer overflow, the signal handler will not run.
<pitti> bluefoxicy: that's not what we are using
<bluefoxicy> oh, sorry, I'm skimming too fast.
<pitti> bluefoxicy: we're using the kernel hook
<bluefoxicy> pitti:  I'm still seeing signal handlers
<pitti> I'm currently at making this actually work
<pitti> bluefoxicy: ?
<pitti> bluefoxicy: if the kernel is about to send a sigseg/ftp/bus/ill to a process, it calls this hook before, and stalls the crashed process
<bluefoxicy> pitti:  in the case of a stack smash the program calls _exit() I think.
<bluefoxicy> let me examine glibc a little okay?
<pitti> sure
<pitti> bluefoxicy: right, if SSP hits, this could be circumvented
<bluefoxicy> pitti:  Right.  I wanted to send a stack dump, the function name, and the module it occurred in.
<bluefoxicy> I am rather certain that given the proper handler I can discern all of this information.  If you think you can do it with just an address in the library, I can also make a good try there; but be wary, unless you can get the EXACT function that ANY .text is associated with, this will not work.
<pitti> fabbione: erm, /bin/sh -> gdb?
<bluefoxicy> I know for a fact that looking in the symbol table and comparing addresses will fuzz around with static functions and inlines
<fabbione> pitti: :)
<Hobbsee> hi fabbione!
<bluefoxicy> but if the debugging data has them correct, and you have that information on your end, then we're good.
<fabbione> hey Hobbsee 
<pitti> bluefoxicy: maybe we can just modify __stack_chk_fail() to also call the crash report agent
<bluefoxicy> however this is fragile, it REQUIRES you have the debugging data for that specific version of that library.  In other words, only ubuntu shipped things.
<pitti> bluefoxicy: so that we can get the same report, and then let the program die as usual
<bluefoxicy> pitti:  yes, that is what I was going to do.  "I am rather certain that given the proper handler I can discern all of this information.  If you think you can do it with just an address in the library, I can also make a good try there"
<pitti> bluefoxicy: well, of course we need to save the stack frame (core dump or similar) to reconstruct a bt post mortem
<bluefoxicy> pitti:  I'll get to work on that, it'll require a slight glibc modification though.  Don't preload this stuff, for the love of all that is holy and good.
<bluefoxicy> pitti:  Be wary of stack dumps.
<pitti> bluefoxicy: no, the preloaded library was just for some initial experiments
<bluefoxicy> A back trace will NOT work by the way
<pitti> bluefoxicy: why, does __stack_chk_fail() already unwind?
<bluefoxicy> remember with a stack smash the stack has been scribbled over.  I can tell you where the last executing address fell before we detected it -- what function was borked up -- but beyond that it's up to the mercey of whatever junk was written past that buffer.
<pitti> I thought it doesn't even return from the function and immediately dies
<bluefoxicy> __builtin_return_address(0) will tell me the function that the current function was called from; __builtin_return_address(1) will tell me the function that the caller was called from, right?
<pitti> bluefoxicy: right, I'm aware of that
<bluefoxicy> well, the caller's retp is destroyed.  backtrace() also uses the stack, so that's kindo f screwed too.
<pitti> bluefoxicy: well, the topmost function should still be correct, right?
<bluefoxicy> yes, it should.
<pitti> so, I think that's about as much as we can figure out in case of a stack smash
<bluefoxicy> as I said, I can get you the calling address in the function that the smash was detected from.
<bluefoxicy> pitti:  that being said a stack dump is useful. It shows the damaging data
<bluefoxicy> so you know what buffer data will cause a smash.
<bluefoxicy> however it *may* contain passwords and gpg keys and god knows what
<pitti> bluefoxicy: that's true for non-ssp dumps as well
<bluefoxicy> yeah
<pitti> bluefoxicy: that's why we have to be careful about them and ask the user, and all that
<pitti> we didn't yet spec out the further process
<bluefoxicy> Application contents are very very sensitive.  I would love to send the __builtin_return_address(0) and force the user to manually review and send stack dumps in ascii/hex side by side, but that will result in a lot of dumps not being sent.  I don't want dumps auto-sent ever, it'd be hell if one day mozilla crashes and we have someone's credit card number.
<pitti> they won't
<bluefoxicy> but I may be being very picky here
<bluefoxicy> return address is harmless.
<bluefoxicy> pitti:  I'll get to work on that.  I'm actually almost there.
<pitti> bluefoxicy: what we'll probably do is to ask the user whether he wants to send us the core (defaulting to off) and add some explanatory text about potential disclosure
<bluefoxicy> pitti: http://bluefox.kicks-ass.org/stuff/bluefox/ssp_patches/  <-- last few days.
<pitti> and never publish the core anywhere
<pitti> bluefoxicy: we only need the core to reassemble a good trace (on a separate server), then we can throw it away anyway
<bluefoxicy> yeah
<pitti> well, it might be useful for other debugging, too, but that might get too sensitive
<bluefoxicy> pitti:  warn the user not to send it if he was entering passwords, credit card numbers, using PGP/GPG keys, or using other sensitive information in the application maybe?
<pitti> bluefoxicy: the reason we go through this fuss is to avoid requiring the user to download all the debug symbols on a crash
<pitti> bluefoxicy: yep
<bluefoxicy> pitti:  I would not mind the option to reduce to the last 64k of stack data; and then visually grep it and "expunge" certain information i.e. hey that's my password ;)
<bluefoxicy> but that would be a very advanced option
<pitti> bluefoxicy: wrt to that, I did some experiments with reducing the core dump file size by throwing out sections we do not need
<pitti> however, that requires more work and research
<bluefoxicy> dude reduce the coredump size by using bzip2
<pitti> bluefoxicy: if you are interested in that, feel free to ping me ::)
<bluefoxicy> not particularly.
<pitti> bluefoxicy: that's what I'm going to do anyway
<bluefoxicy> pitti:  I am worried about the handler though.  It is good to avoid using external functions in it.
<pitti> bluefoxicy: but if we throw out e. g. code sections, it'll shrink even further
<bluefoxicy> that's why I wrote my own strcpy() and strcat()
<pitti> well, strcpy() in C is easy :) while(*dest++ = *src++)   /me <3 C 
<bluefoxicy> the whole lib needs to be self-contained.  Some libraries even supply their own read() that overrides glibc, that isn't what I want to deal with.
* bluefoxicy is currently trying to figure a way to get glibc to pass something to let the ssp library get *its* handlers, or something.
<pitti> bluefoxicy: that gets trickier if you want to call the crash-reporting agent
<bluefoxicy> pitti:  I am considering the 'agent' be connected to a daemon
<pitti> bluefoxicy: oh you want to use IPC to talk to it? hmm
<bluefoxicy> and my job be to write the data to something-- named pipe, some file in some directory, anything I can do with minimal code-- and get out of the dead program
<pitti> I'd rather have it spawned by the crash handler or the kernel
<bluefoxicy> I want as little code running in the dead program as possible after it's been smashed
<pitti> bluefoxicy: right, that's why we came up with the kernel helper
<pitti> so that we do not need any code at all in the crashed process
<bluefoxicy> right, but stack smashed programs exit cleanly.
<bluefoxicy> ... for the most part.
<pitti> true, we have to add a hook there
<pitti> and that'll get tricky
<bluefoxicy> you're going to need something on that end
<pitti> bluefoxicy: however, it's not the common crash case anyway
<pitti> so if we add that later, that'll be fine
<bluefoxicy> yeah
<bluefoxicy> it doesn't even have to operate the same way, just as long as it's not totally insane
<pitti> right, it would just be nice to reuse our crash agent, since it collects so much valuable information
<pitti> (not only the bt, but also package versions, dependencies, /proc status, etc.)
<bluefoxicy> it can be reused.  Can you trigger a program to core dump?
<pitti> bluefoxicy: kill(x, SIGSEGV) :)
<pitti> bluefoxicy: yes, in fact that's what stack_chk_fail() could (ab)use :)
<bluefoxicy> like I said, in a stack smash you're not getting a back trace.  You're getting whatever address the handler would "return" to (if it returned) and a stack that's scribbled over garbage ;)
<bluefoxicy> the data you need to build a back trace is most likely destroyed
<pitti> bluefoxicy: I know, but we'd still know the package, version, OS version, dependency versoins, /proc etc.
<bluefoxicy> SIGSEGV can be trapped.
<bluefoxicy> yeah
<pitti> bluefoxicy: I know it can be trapped, we have to make sure that the process doesn't continue to run afterwards
<pitti> maybe by resetting the segv handler or so
<bluefoxicy> hmm.
<bluefoxicy> SIGKILL can't be trapped, I can send that simply enough from within the program but i can do it from bash too
<pitti> bluefoxicy: right, but we shouldn't trigger the crash handler on KILL
<bluefoxicy> I can send sigsegv from bash but that's not common.
<bluefoxicy> pitti:  well, hold on.
<bluefoxicy> I would be sending the kill to myself.
<bluefoxicy> PID 1000 -> PID 1000
<pitti> yes
<bluefoxicy> that is clearly a not normal situation.
<bluefoxicy> You can detect this in the kernel, I'm sure.
<pitti> hm, I'm not sure whether we should special case that in our kernel hook
<pitti> bluefoxicy: maybe we should check if a process sends a SIGSEGV to itself
<pitti> well, then we don't need the 'to itself' special case
<bluefoxicy> uh
<bluefoxicy> processes can catch sigsegv and handle it safely
<pitti> bluefoxicy: do you see a reason why signal(SIGSEGV, SIG_DFL) won't work?
<bluefoxicy> they can NOT catch a stack smash and handle it safely
<pitti> oh, true, right now we do allow programs to trap segv, just to not trample over existing crash handlers
<bluefoxicy> Etoh DID however clear the signal handler on sigsegv, but I am not comfortable doing this in a multithreaded environment because I am paranoid another thread might race me.
<bluefoxicy> it's theoretically possible
<pitti> no, you are right, that's too crackful and unsafe
<pitti> bluefoxicy: so what we need is a simple kernel API to say 'please call the crash handler on me', and then just _exit()
<bluefoxicy> I don't see a harm in catching a sigkill to self, why a program would do such a thing is beyond me; the normal way to exit is _Exit() (calling atexit() handlers) or _exit() (exiting immediately without running any more code)
<pitti> bluefoxicy: ok, we should consider this special case
<bluefoxicy> at the very least I am 100% sure that POSIX mandates sigkill can never be trapped
<pitti> that's true
<pitti> that's the whole point of kill over term :)
<bluefoxicy> the gcc guys have _exit(127) as their last ditch effort of 3 things they try to do to exit
<bluefoxicy> pitti:  also if you change the handler to straight out _exit() you have to collect the crash data yourself, you have to do the backtracing yourself, which means you have to figure out the stack frames up to the damaged ones
<bluefoxicy> err. to kill self, exit, or whatnot.
<pitti> bluefoxicy: what I meant is:
<pitti> bluefoxicy: right now, __stack_chk_fail() prints/logs a blurp and _exit()'s, right?
<bluefoxicy> yes, pretty much.
<pitti> bluefoxicy: so, my idea is to insert a __sys_call_crash_handler() or whatever between the print and the _exit()
<bluefoxicy> in glibc (the one we use) it uses __libc_message(1, "...", program_name)
<bluefoxicy> (before the print)
<pitti> bluefoxicy: similar to the do_coredump() hook we changed in the current kernel, this could trigger callign the crashdump helper from the kernel and suspend the program in the meantime
<bluefoxicy> pitti:  do you want to do this in an external library, or hack it straight into libc?
<bluefoxicy> interesting.
<pitti> bluefoxicy: I thought about a kernel interface, if that's possible
<pitti> to avoid execve() and similar stuff from the crashed process
<bluefoxicy> yes I mean we have to modify the crash handler
<bluefoxicy> the __stack_chk_fail() function
<pitti> bluefoxicy: oh, the actual crash handler is a separate process (currently in python)
<bluefoxicy> alright
<pitti> bluefoxicy: oh, that's in glibc right now, and I think that's a good place
<bluefoxicy> alright.
<bluefoxicy> What has to be inserted before glibc bails out
<pitti> bluefoxicy: in Debian it is in libssp0, but glibc 2.4 has it natively
<bluefoxicy> yes
<bluefoxicy> I was thinking to alter glibc to read /etc/libc.ssp.conf on start-up, dlopen() the library mentioned in there, and get a symbol for __stack_chk_fail(); and in the stack smash handler in glibc, call that address if it actually existed, otherwise default behavior
<bluefoxicy> this would add an extra library to each load of each program however
<bluefoxicy> but would allow us to basically do whatever we want in this realm without rebuilding glibc
<bluefoxicy> I guess if you can collect ALL the data you need from outside the process though, then all we really need is for glibc to kill itself in a not so graceful manner
<bluefoxicy> which is one line of code.
<pitti> bluefoxicy: it's not entirely unlike my first ld.preload appraoch :)
<bluefoxicy> not entirely, but ld.preload I have issue with:)
<pitti> right
<pitti> although it's not that evil IMHO
<bluefoxicy> unless you have multilib
<bluefoxicy> and suid
<pitti> bluefoxicy: setuid programs do respect /etc/ld.so.preload, they just don't respect $LD_PRELOAD
<bluefoxicy> if an ld.so.preload can't load, then a suid program refuses to run.  You NEED a livecd to fix this.  So we would not be able to ld.so.preload for any 32 bit programs (openoffice is probably our last one though)
<bluefoxicy> found that one out trying to do two libsafes on gentoo.
<bluefoxicy> err, *32 bit programs on amd64
<pitti> oh, good point
<bluefoxicy> besides that it just feels like a fragile approach, I don't know why
<bluefoxicy> but that's irrelavent
<bluefoxicy> pitti:  what can be gathered without any help from the program?
<bluefoxicy> Can you figure out the absolute last stack frame, and what function was executing?  Can you figure out the return address that function would have gone to?
<bluefoxicy> If you can, then everything I could pass you from the handler is moot, the handler just needs to die in a way that triggers the crash handler.
<pitti> bluefoxicy: with gdb you can figure out quite much, and I would like to collect all data externally
<pitti> bluefoxicy: we might be able to extract a dump of the stack frame in the crashed process itself, that would avoid the huge core dump, but that feels fragile
<bluefoxicy> alright, and gdb can attach to a running process if it has CAP_SYS_PTRACE?
<pitti> bluefoxicy: yes, the kernel crash handler is always called as root
<pitti> I currently drop permissions to the target process, but we can tweak that however we like
<bluefoxicy> let's not do root, let's do CAP_SYS_PTRACE and whatever other caps you need
<pitti> see above :)
<bluefoxicy> yeah
<bluefoxicy> also, make a note
<bluefoxicy> in the future it may become fashionable to block access to /proc/PID/maps and friends
<pitti> bluefoxicy: also, if the target process has the 'pink' bit, i. e. has privileges above the average, then I'd rather not gdb it
<bluefoxicy> You should develop a strategy for specifically granting a process permissions to access /proc/PID/maps eventually, but it's not necessary right now.
<pitti> bluefoxicy: if a process started as suid root and then setuid(getuid()) it is not ptrace()able from that uid
<pitti> bluefoxicy: and my feeling is that we should respect that
<bluefoxicy> pitti:  nods.
<pitti> I'd favor a missing backtrace over an information disclosure
<pitti> bluefoxicy: anyway, let's get that thing going for the basic cases
<pitti> then we can refine it
<pitti> bluefoxicy: (interesting discussion, thanks!)
<bluefoxicy> pitti:  this is dead simple, what do you need to kill the process with?
<pitti> bluefoxicy: context?
<pitti> a slashaxe? :)
<bluefoxicy> haha
<bluefoxicy> I mean in __stack_chk_fail(), what kind of thing needs to happen?
<pitti> bluefoxicy: <pitti> bluefoxicy: so, my idea is to insert a __sys_call_crash_handler() or whatever between the print and the _exit()
<pitti> bluefoxicy: of course we do not have this kernel API right now
<bluefoxicy> do you NEED that kernel API for anything else?
<pitti> it was just a random idea
<pitti> bluefoxicy: actually not
<bluefoxicy> if not a simple kill(getpid(),SIGKILL) and catching SIGKILL to current will probably be less invasive and we won't have to worry about securing a syscall number
<pitti> true
<bluefoxicy> the backtrace will be like, kill <- __stack_chk_fail() <- whatever_vuln_function()
<pitti> bluefoxicy: I agree that this is the easiest idea so far
<bluefoxicy> I still gotta figure out what to do about libc.  It simultaneously reports and kills self in same line of code.  I may just have to change a 1 to a 0 though
<bluefoxicy> also I am looking at the gcc stack smash protector library
<bluefoxicy> oh I get it
<bluefoxicy> teh compiler would optimize out half the code if they did it a simple way.
<pitti> bluefoxicy: I'm not sure about the semantics of signal()
<pitti> bluefoxicy: we have to make sure that it blocks at least until the kernel has the chance to call the crash helper
<bluefoxicy> pitti:  signal() sets up a signal handler
<pitti> erm, I mean kill()
<pitti> sorry, brain still sleeping
* pitti woke up veeery early after only 4 hours of sleep
<Mithrandir> siretart: please hold it off.
<bluefoxicy> oh good point
<Hobbsee> hi Mithrandir 
<pitti> bluefoxicy: otherwise we will kill ourself before crash-agent has the chance of examining
<bluefoxicy> pitti: yeah, unless a core dump can be used as effectively as gdbing the process
<pitti> bluefoxicy: well, if we have a core dump available, then we WON
<pitti> bluefoxicy: but a firefox core dump is ~ 130 MB
<pitti> even bzip2'ed it's still several MB
<bluefoxicy> ahshit.
* pitti doesn't dare to create an OO.o core
<bluefoxicy> yeah and we can't stop the process
<pitti> moing ogra
<bluefoxicy> that would make sigkill work like sigstop
<bluefoxicy> which would be bad.
<Mithrandir> morning, Hobbsee
<pitti> bluefoxicy: well, it's not going to STOP, the process is in state 'D' (uninterruptible kernel sleep) while the crash helper runs
<bluefoxicy> pitti:  and when the crash helper exits it goes away?
<pitti> bluefoxicy: then I have to jump through some hoops to make it go into state T while tracing it, and then I let it die
<pitti> I'm still working on this
<bluefoxicy> what happens when the program gets a sigkill during state T
<pitti> bluefoxicy: I can't directly gdb from the crash helper since you cannot trace or waitpid() a process in D state
<pitti> bluefoxicy: interesting question
<bluefoxicy> i.e. I gdb ls, then kill -9 ls
<pitti> martin    8207  0.0  0.0   3948   792 pts/3    T+   08:36   0:00 cat
<bluefoxicy> it goes to T+?   :P
<pitti> kill -9
<pitti> martin    8207  0.0  0.0      0     0 pts/3    Z+   08:36   0:00 [cat]  <defunct>
<pitti> haha
<bluefoxicy> hah, can you still stack dump it?
<pitti> bluefoxicy: no
<pitti>  bt
<pitti> #0  0x00002b4fcde99460 in read () from /lib/libc.so.6
<pitti> Cannot access memory at address 0x7fffdcde9468
<pitti> detach -> 'ptrace: No such process.'
<bluefoxicy> pitti:  okay, how about
<pitti> ouch, quitting gdb in that state is ... interesting
<pitti> bluefoxicy: but that should be fine
<bluefoxicy> pitti:  how about before the kernel actually sends the signal, you incur.... wait()
<pitti> bluefoxicy: our crash handler will run *before* the KILL is actually 'executed'
<bluefoxicy> so
<bluefoxicy> kill(getpid(),SIGKILL) -> kernel -> fork() -> child: execve(crash handler) -> parent: wait(child) -> child does its thing -> crash handler exits -> as per the function of wait(), program execution continues -> signal kill is sent to the process -> process dies
<bluefoxicy> pitti:  question:  Can we sleep the process in the kernel via wait() from kernel space
<pitti> bluefoxicy: no idea
<bluefoxicy> if we can, then this progression naturally puts the entire process to sleep until the crash handler exits
<bluefoxicy> pitti:  nothing indicates it can't.
<bluefoxicy> pitti:  also I don't think we need to worry about printing the ***stack smash detected*** message to the user from the handler.  That's largely irrelavent, POSIX doesn't care, and I'm sure the user is WELL AWARE something just happened.
<pitti> bluefoxicy: however, it's nice to have it in syslog
<bluefoxicy> it doesn't go to syslog()
<pitti> does it not? it should ;)
<bluefoxicy> is syslog() stack smash protected?
* pitti would like to see it in auth.log
<bluefoxicy> hey
<bluefoxicy> you can call syslog() from your crash handler process
<pitti> indeed
<bluefoxicy> I would really rather not.
<bluefoxicy> plus the unique kill(self) indicates that it's a stack smash
<pitti> right
<bluefoxicy> pitti:  this is down to a one-line change, glibc/debug/stack_chk_fail.c, insert a line at 29, "  kill(getpid(),SIGKILL);", remove the rest of the function if you want
<pitti> bluefoxicy: debian/patches/commit_suicide.dpatch :)
<ivoks> :)
<pitti> hi ivoks 
<ivoks> hi pitti 
<pitti> ivoks: (talking about kill(getpid(),SIGKILL))
<ivoks> for what? :)
<bluefoxicy> stack smash detection
<bluefoxicy> the protection exits nice and cleanly
<pitti> ivoks: long story, read ubuntulog if you are interested (short story: calling our crash handler for ssp violations)
<bluefoxicy> https://wiki.ubuntu.com/AutomatedProblemReports  This won't trigger
<bluefoxicy> so we want a nice and clean self-kill that will indicate that something is clearly wrong and trigger it.
<ivoks> oh, i didn't met a user who likes that "your program crashed, what do you want to do?"
<bluefoxicy> kill -9'ing yourself is one of the more obvious ones, and pretty special case
<bluefoxicy> ivoks:  we can get really good data though.
<pitti> ivoks: no, but we developers like it :)
<ivoks> i know we/they do, but OS is for users, not developers :)
<pitti> ivoks: eventually, users are better of if we actually have a chance of fixing bugs than ignoring them forever due to insufficient information
<ivoks> i know and i understand the goal
<ivoks> this is just my view on things, feel free to ignore it :)
<pitti> ivoks: also, we'll provide different frontends for crash reports
<bluefoxicy> it could be majorly automated.
<pitti> ivoks: a gtk one that pops into your face is just one alternative :)
<bluefoxicy> it should be possible on the user's end to figure out where in the program the crash happened exactly
<ivoks> if everything could be places in background, then great
<bluefoxicy> that information and a notice that says 'Firefox crashed' and we can figure out what exact function it crashed in
<ivoks> placed
<bluefoxicy> so the user can get asked once what to do and allow this much to be automated at least
<bluefoxicy> pitti:  also, the /proc/pid/maps for that address is extremely important and doubly useful:  it reveals the exact code module we crashed in so we know if it was i.e. Firefox or LibPng that fucked up.
<ivoks> bluefoxicy: what about single place for crash handling with one checkbox "send crash information to developers"
<ivoks> if you do that for every app, then users will ask why does this happen for firefox, but not for gedit
<pitti> bluefoxicy: *nod*
<pitti> ivoks: dangerous
<bluefoxicy> ivoks: I'm thinking teh first app crashes "Hi what should we do?"  "[X]  Always send minimal crash information to the developers"
<pitti> ivoks: you'll likely expose sensitive data to us that way
<pitti> ivoks: and if we leave out the potentially sensitive bits, then we also leave out the bits that help us to find the bug
<ivoks> ok
<bluefoxicy> pitti:  we can send:  1)  Return address from __stack_chk_fail() (this should be unaltered, so is just an address, nothing sensitive here); 2) /proc/pid/maps line indicating what code module (library) that address is in (kernel space, not damaged, not sensitive); 3) name of the application that crashed
<bluefoxicy> pitti:  That can be sent quite harmlessly if the user agrees to it, no sensitive data
<pitti> bluefoxicy: true, but eventually deveopers want stacktraces, not just the library a crash occured in
<bluefoxicy> the user only needs to agree with it because (omg) we don't want to turn spyware on by default
<bluefoxicy> pitti:  a stack dump of the last 64K will be useful; an actual call trace is not gatherable because the information is destroyed
<pitti> bluefoxicy: do you have an idea how I can get a stack dump from an external process?
<bluefoxicy> pitti:  but a stack dump, 10 bytes or the whole stack, may contain sensitive information; I don't want that automated ever.
<bluefoxicy> pitti:  well... you can locate the [stack]  in /proc/pid/maps and read it?
<pitti> bluefoxicy: me neither, that's why we have to ask
<pitti> oh, indeed
<pitti> bluefoxicy: and then we can use gdb dump to save that part into a file
<bluefoxicy> pitti:  nods.  Like I said, the user can store those for later review, purge say every month or every 3 months or such, and send them later.
<pitti> bluefoxicy: we just cannot use gdb then to create a symbolic stack trace from that, or can we?
<bluefoxicy> pitti:  you can't do a symbolic stack trace, because the function may be a static function or an inline function
<bluefoxicy> the symbols won't be there
<pitti> bluefoxicy: gdb has a load command (or so) to restore a memory region from a file, but to do a bt it needs more
<bluefoxicy> even if the library isn't stripped the symbols aren't there, you need real debugging information.
<pitti> bluefoxicy: we will have them
<bluefoxicy> you need to keep the debugging information on your end, the user sends you the address, and you turn that into a function.
<pitti> bluefoxicy: that's the point: on an external server, we want to put the stack dump and the symbols together to get a good bt
<bluefoxicy> hell you can turn it into a source file ;)
<pitti> bluefoxicy: with a core file that's damn easy, gdb exe core, symbols-file, bt
<bluefoxicy> pitti:  anything but a stack smash will give you a good back trace.
<pitti> but if we only have a stack frame dump, we have to generate this somehow
<pitti> hi dholbach 
<bluefoxicy> mmm.
<bluefoxicy> the stack dump is enough to show you what data caused the overflow
<bluefoxicy> or whatnot
<bluefoxicy> in any other case it'd be rather useless on its own I'd think
<pitti> bluefoxicy: you see, we eventually want the result of 'bt full' with symbols
<pitti> this is nice, compact, and obvious to read for developers
<bluefoxicy> can you do a 'bt full' and get addresses
<bluefoxicy> and then send those and turn them into symbols?
<pitti> bluefoxicy: we have the addresses, yes
<pitti> bluefoxicy: but no function arguments, nor local stack variables
<pitti> bluefoxicy: of course they can be figured out from the stack trace
<pitti> in theory
<bluefoxicy> hm
<pitti> but we need a tool that actually does that
<bluefoxicy> write one :)
<pitti> and I'm not sure how gdb can be poked to do it
<bluefoxicy> hire someone to write one?  :)
<pitti> bluefoxicy: would make a good bounty, yes :)
<ivoks> see you later guys
<bluefoxicy> I must sleep for it is 3am
<bluefoxicy> pitti:  if all else fails, you would not believe how immensely helpful a function name is, because you can get back to source file and function that the problem is in.
<bluefoxicy> I say worry about getting the tool working first.
<sivang> morning
<bluefoxicy> Collect some information, get a symbolic stack trace as far as you can, get a full /proc/PID/maps
<bluefoxicy> pitti:  also
<bluefoxicy> proc information (/proc/pid/{cmdline,environ,maps,status})
<dholbach> good morning
<sivang> morning dholbach :)
<sivang> yay, new fglrx
<dholbach> hi sivang
<bluefoxicy> absolutely no automated reporting of cmdline and environ
<bluefoxicy> I see that mine is exposing my user name, not really important but in general it's considered not a good idea to publish a list of usernames on the system
<bluefoxicy> (this is why we say "bad username and password combination" and not "user does not exist" vs "password is wrong")
<bluefoxicy> cmdline on the other hand well... some stupid apps like to take passwords on the command line
<bluefoxicy> I've used a few.
<bluefoxicy> pitti:  this is never really going to be practical, but it would be wonderful if there was a way for users to volunteer their time by giving us contact information so that we could get in touch with them over anything we need more info on
<bluefoxicy> including IRC handles on freenode and OFTC, or e-mail addresses, or IM screen names maybe
<bluefoxicy> with the standard "Be advised if we need more information about a crash you report, we will contact you" notice to ward away users that do not want to talk to us
<bluefoxicy> that way if we got an interesting, stackless crash we could e-mail the user and say "Hey can you give us some help..."
<bluefoxicy> I do know several people who would opt in but they're all geeks :P
<dholbach> I'd rather like to have all the information in bug reports and in one central place
<bluefoxicy> dholbach: https://wiki.ubuntu.com/AutomatedProblemReports
<bluefoxicy> dholbach:  some of the most useful information that can be gathered can get rather sensitive
<dholbach> I wouldn't like to have to IM/mail/jabber/whatever people to get information about a crash
<dholbach> it's more useful to have all the information in one place, where not only i have that information
<bluefoxicy> dholbach:  the useful information we can get consists of executable name, stack dump, addresses of functions on the crash path, /proc/pid/maps so we know what library what address goes with and can identify the function names from our debugging info
<bluefoxicy> dholbach: /proc/pid/cmdline and /proc/pid/environ and /proc/pid/status, and perhaps a core dump if it's small enough.
<dholbach> i was referring to " including IRC handles on freenode and OFTC, or e-mail addresses, or IM screen names "
<bluefoxicy> dholbach: Unfortunately, cmdline, environ, core dump, and stack dump may contain passwords, DECRYPTED GPG KEYS, credit card numbers, logins, etc.
<bluefoxicy> dholbach:  I would prefer that we ward users who honestly don't know what they're doing AWAY from submitting any of that, and just gather loads of executable:addresses:proc-pid-maps:proc-pid-status
<bluefoxicy> users have to send the other stuff on a case by case basis, mandatory.
<dholbach> hm
<bluefoxicy> now this is all well and good for those of us who both A) know enough to fiddle with this stuff, and B) have time and actually care to go fiddling.
<dholbach> hey Gloubiboulga
<bluefoxicy> me, I will likely on a good day go looking when I see a crash; if it says "HI I detected a stack smash" I am definitely looking and making sure you get whatever data you need to fix it
<Gloubiboulga> hi dholbach, hi all
<bluefoxicy> non-technical users are likely to click the "send non-sensitive data about crashes automatically" button and coast
<bluefoxicy> normally, I'll fall into (A) but not (B), which means you'll get automatic non-sensitive data from me but no stack dumps or cores.
<bluefoxicy> However i have no problems with someone e-mailing me and asking for a little help if they need more information
<bluefoxicy> when it comes down to that, it's a last resort measure; but if you have to come and get me, then you obviously REALLY need the help.
<bluefoxicy> the point of it being completely voluntary and opt-in is that only users that really want you to come get them should opt in.  Try to ward them off gently; if they're persistent enough to come along anyway, then they know what they want
<bluefoxicy> at any rate
<bluefoxicy> I need sleep.
<dholbach> good night
<ogra> pitti, hey, thanks for the hwdb review :) (even though we went through the same scripts before :) )
<pitti> ogra: yes, when I looked at it it was quite familiar :)
<ogra> :)
<Kamion> Mithrandir: can I upload this gfxboot-theme-ubuntu change?
<Kamion>   * Make "lang" file work with locales that require _CC (pt_BR, zh_CN,
<Kamion>     zh_TW).
<Kamion>   * Use the new "locale" alias for debian-installer/locale.
<Mithrandir> Kamion: go ahead.
<Mithrandir> Kamion: how did your d-i testing work out yesterday?
<Kamion> thanks
<ogra> pitti, the other one is a bit more evil inside, i think you havent seen that yet, but it has the same input check so no way to intrude code
<Kamion> Mithrandir: found/fixed the locale bug, waiting for kernel upload to come through before uploading d-i again
<Kamion> otherwise it miraculously seems to have mostly worked, aside from some weird udev fuckage that Scott's fixed
<Mithrandir> Kamion: ok, thanks.  It'll require unifdef to be promoted, but you know that already.
<Kamion> yep, waiting for the publisher
<Mithrandir> then I just want Scott or Adam to appear so we hopefully can get the livefs-es to build today.
<Kamion> still concerned about the boot problem, but Ben reckons that's a kernel bug
<Kamion> "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
<Kamion> "
<Kamion> Mithrandir: er - we built livefses last night
<Mithrandir> full ones?
<Kamion> yeah
<Kamion> mdz said the live CD had weird I/O errors on boot though, on several different machines
<Mithrandir> uh, I thought -desktop wasn't installable or was that a figment of my imagination?
<Kamion> it appeared to work well enough. I think we've hit a corner case that confuses britney but not apt
<Mithrandir> ok, goodie, then we "just" need to test and release.
<Mithrandir> there are both dapper and edgy .iso-s in http://cdimage.ubuntu.com/daily-live/current/ ; we should probably nuke the dapper ones.
<Mithrandir> and it seems we just have i386?
<Mithrandir> and no alternate ppc or sparc.
<Mithrandir> afk for a little bit
<Kamion> powerpc's still hosed
<Kamion> (needs gcc-4.1 bootstrap and then a big pile of builds)
<ogra> totally ...
<ogra> i cant even bootstarp a thin client here ...
<Kamion> Mithrandir: nuked the dapper .isos
<Kamion> thanks
<ogra> edgy_probs looks a lot better today though
<Kamion> yes, bootstrapping won't work because aptitude is uninstallable. we know.
<infinity1> Kamion: Hrm.  Do you know any tricks to completely delete a queue item, rather than rejecting it?
<crimsun> janimo: user request in #xubuntu
<janimo> crimusn, thanks
<infinity1> Kamion: 'queue -Q rejected info 72147' <-- Due to a lovely race in the builddmaster.  Argh.
<infinity1> Kamion: I rejected that and then got the gcc/ppc upload in properly (so that should hit the next publisher run), but it leaves gpass/sparc kinda hosed, since I can't push it through a second time without things exploding.
<infinity1> Kamion: I figured if I was oging to break one, some random universe package seemed slightly less important.
<Kamion> can a queue item not exist more than once in rejected?
<Kamion> I thought it could
<Kamion> if not, that's a bug ...
<Kamion> bug 52938 <- sigh, TEAM SOYUZ, QUIT MESSING WITH STUFF THAT WASN'T BROKEN
<Ubug2> Malone bug 52938 in qprocd "change-override.py -S doesn't move binaries any more" [Untriaged,Unconfirmed]  http://launchpad.net/bugs/52938
<Mithrandir> infinity1: any chance you could give me a give-back of gcj-4.1 on amd64?
<infinity1> Kamion: If I go to reprocess the upload (with just the gpass binaries), it just revives the old broken queue item (with gpass and gcc in the same upload), which is pretty hideously broken.
<Mithrandir> we should just be able to do a no-change upload of gpass, shouldn't we?
<Kamion> infinity1: ! is there a bug filed about that?
<slomo> oh, someone please give-back mono on ppc... should build fine now that gcc built again
<infinity> Kamion: No idea.  Not really here enough to go looking.
<Kamion> infinity: anyway, you need a soyuz person, I think - I'll go ask
<infinity> Kamion: There is a bug about the builddmaster race condition that can lead to multiple binary uploads getting stuck together, but that's not been addressed because it can (in theory) only happen when doing manual upload processing.
<siretart> Mithrandir: already uploaded (was authorized by mdz)
<Mithrandir> siretart: ok
<ogra> pitti, would you mind having a look at the ttf-dustin main inclusion report (no brainer font report) ? it keeps khangman and thus edubuntu-desktop uninstallable atm
<pitti> ogra: sounds easy enough, a minute
<ogra> no hurry ...
<ogra> just before knot 1 :)
<pitti> ogra: approved
<ogra> thanks ! :)
<Kamion> infinity: still around?
<Kamion> infinity: Kinnison wants to know if you were manually running process-upload at any time
<infinity> Kamion: Well, yes, I thought I made that clear.  Though the error comes from having two things in incoming/ when the builddmaster runs process-upload in a very silly fashion.
<Kinnison> mdz: ping?
<Kinnison> mdz: I have a one line fix for process-upload which will finally squash this nasty race condition
<Kinnison> mdz: I'd like to monkey it directly in on drescher so that this kind of problem doesn't occur again
<Kinnison> mdz: According to the peace treaty of '06, I need your say-so :-)
<mdz> Kinnison: pong
<mdz> Kinnison: I'm not familiar with the problem you're referring to; is there a bug#?
* Kinnison goes to find the bug
<Kinnison> mdz: bug 36468
<Ubugtu> Malone bug 36468 in launchpad-buildd "builddmaster appears to batch process by accident?" [Medium,Unconfirmed]  http://launchpad.net/bugs/36468
<Kinnison> mdz: it tickled this morning and the info this time led us to actually track down the bug
<mdz> Kinnison: can I see the patch?
<Kinnison> Sure, one sec and I'll ask bzr for it
* Kinnison suspends workrave before it manages to restbreak me right now
<Kinnison> mdz: https://chinstrap.ubuntu.com/~dsilvers/paste/fileJ7lspg.html
<mdz> Kinnison: patch seems straightforward enough, though from the bug report this doesn't sound like a common situation.  did infinity say otherwise?
<mdz> it seems like it would be fine to roll into the next update
<Kamion> mdz: I don't think it's *that* common, but it happened - see above
<Kinnison> mdz: It is a race which can happen if manual processing is going alongside the normal buildd processing
<Kinnison> mdz: I.E. most common during port bringup
<mdz> Kinnison: it's OK with me if it's important to the archive team
<Kamion> I think the db corruption in the queue should lead us to consider this important, yes
<mdz> Kamion: has anyone else tried the edgy live CD of doom?
<Kinnison> Right, I'll patch that on drescher. I've updated the bug already
<Kamion> mdz: I'm 44% of my way through a wget
<Kamion> I don't think anyone else has tried yet
<mdz> it's very odd
<mdz> I hope my burner isn't dying
<Kamion> BenC seemed to think the kernel was a bit bust, and that his recent uploads would be happier
<Kamion> although that was with respect to another bug
<crimsun> mdz: is the debdiff attached to bug 46776 suitable for dapper-updates?
<Ubugtu> Malone bug 46776 in apt-proxy "Incompatible with full URL HTTP requests from recent apt versions" [Unknown,Unknown]  http://launchpad.net/bugs/46776
<mdz> crimsun: strange report there
<mdz> I don't know much about apt-proxy; is it used transparently or as an explicitly-configured proxy?
<StevenK> It's explicity configured.
<mdz> it's quite normal to send the full URL in the GET when talking to a proxy
<mdz> I'd be surprised if mvo changed that
<StevenK> I suspect that apt-proxy doesn't think it's a proxy, though.
<StevenK> It gets a request, it looks up it's config, it slaps the front part of the URL on and tries to retrieve it.
<mdz> oh, it's not configured as a proxy, it's configured in sources.list
<Mithrandir> mdz: you just point your sources.list at the apt-proxy host and it does its magic from there, so it's not a standard proxy.
<StevenK> It's a bit naive.
<StevenK> mdz: Correct.
<StevenK> I've stopped using it, because I was sick of it breaking all the time.
<StevenK> And apt-proxy v2 is much worse.
<tseng> StevenK: oh jeez apt-proxy
<mdz> I'd be fairly surprised if apt suddenly started sending GET <url> rather than GET <path>
<mdz> I didn't even think that was valid for non-proxies
* StevenK has scary memories of running apt-proxy v1 through sh -x (yes, it's written in shell) because it didn't work and I was trying to fix it.
<Mithrandir> mdz: it's valid for HTTP 1.1
<Mithrandir> iirc
<StevenK> Mithrandir: Correct.
<mdz> ok, I believe you
<mdz> however, I've just sniffed, and apt doesn't do that
<StevenK> mdz: Which apt, though?
<mdz> StevenK: edgy
<StevenK> mdz: What about the magical pdiff version in Debian?
<mdz> which is identical to dapper
<Mithrandir> Kamion: how do you feel about adding "generate sort list for squashfs" to the milestonerhythm tasks?
<mdz> StevenK: see the bug; they're claiming that dapper is behaving this way
<Kamion> Mithrandir: for every milestone?
* StevenK re-reads it.
<Kamion> I still feel that if we have to do that by hand, we're doing something wron
<Kamion> g
<Mithrandir> Kamion: it's quite easy to do, so yes.
<Mithrandir> Kamion: it requires a boot + grabbing the list + putting it somewhere the build can get at it.
<Kamion> Mithrandir: if it's documented how to do it ...
<crimsun> mdz: err, dapper and edgy don't appear to have the same versions of apt, or did I misparse?
<Mithrandir> Kamion: obviously, that'd be a requirement so it's not just documented in my ~/.zsh_history..
<mdz> crimsun: oh, you're right
<mdz> but they're close enough
<Kamion> Mithrandir: ok then
<Mithrandir> Kamion: if you can come up with a way to get to it automatically, I'm all ears, but I can't see a way which works and doesn't require booting the cd.
<StevenK> mdz: Colour me as confused as you, then.
<Kamion> infinity: please give-back aptitude 0.4.1-1.1ubuntu2 on powerpc
<Kamion> siretart: could you fix libxine-dev's dependencies, please? it depends on libxine1 which doesn't exist
<Kamion> siretart: (you could fix libxine1-dbg at the same time then, before knot-1)
<mdz> gah, totem still isn't building
<mdz> ah, Kamion noticed already
<Kamion> yeah, I've been tracing that
<Kamion>   libsdl1.2-dev: Depends: libglu1-mesa-dev but it is not going to be installed or
<Kamion>                           libglu-dev
<Kamion> ^-- xine-lib build failure on ia64 powerpc sparc
<Kamion> ia64 also has:
<Kamion>   libgnomevfs2-dev: Depends: libgnomevfs2-0 (= 2.15.2-0ubuntu1) but it is not going to be installed
<doko> Keybuk: the new dejagnu breaks all the biarch testsuites, running with something like --target_board=unix\{,-m32\} :-(
<mdz> Kamion: mesa ftbfs on those architectures
<Kamion> yeah, just got that far
<mdz> rodarvus: http://librarian.launchpad.net/3405259/buildlog_ubuntu-edgy-powerpc.mesa_6.4.2-1ubuntu2_FAILEDTOBUILD.txt.gz
<Mithrandir> doko: Scott's not around ATM.
<Kamion> ia64 looks like l-k-h/gcc damage, best ignored
<Mithrandir> Kamion: jbailey has a fix for that, but it's post-knot.
<Kamion> powerpc and sparc failures are basically the same
<Kamion> I'll try building it on powerpc with the new gcc
<mdz> powerpc seems like it could be a glibc bug
<Mithrandir> do we have anybody who can actually do give-backs around ATM?
<mdz> it has -D_GNU_SOURCE which should give it dprintf
<doko> Mithrandir: did jbailey talk to you about a lkh update?
<mdz> Mithrandir: I can do 'Reset build's, not sure if that's the same thing or not
<Mithrandir> doko: yes, it's post-knot-1.
<Kamion> mdz: should be, techboard is a member of launchpad-buildd-admins
<Mithrandir> mdz: ok.  Can you then give-back gcj-4.1?
<Mithrandir> mdz: (on amd64 and powerpc)
<mdz> Mithrandir: amd64 says currently building
<Kamion> and aptitude on powerpc, per above
<Mithrandir> mdz: oh, ok.  Great, then. :-)
<mdz> Mithrandir: powerpc reset
<Mithrandir> cheers
<mdz> also done
<fabbione> mdz: the mesa FTBFS is known but it seems to be a problem with the headers and not mesa. If you notice it fails only on big endian machines
<fabbione> mdz: i already spoke with jbailey yesterday about it and he has a reduced test case to find a fix
<Kamion> can it be a candidate for a workaround in mesa if possible? it's blocking a big load of stuff on those arches
* Kamion can't build ubiquity until that's sorted
<fabbione> Kamion: i don't know.. 
<Kamion> I'm test-building it here, will see what's possible
<fabbione> thanks
<Kamion> well, until that's sorted and about half a dozen other things build, but who's counting
<StevenK> Hah
<fabbione> Kamion: i am pretty sure jb will show up soon and we can ask him if he has a solution already
<StevenK> I did that at work today. "Steve, if I can borrow you for the nth time?", "The sixth, but who's counting."
<Kamion> fabbione: that's fine, I just want to have multiple lines of attack in case one fails
<fabbione> Kamion: yup...
<Kamion> I can't do a lot else until I clear this up anyway
<Kamion> s/I clear/we clear/ obviously, hubris--
<fabbione> Kamion: :D
<mdz> kernel is still building
<thom> mdz: any idea why debian #213465 was never merged?
<Ubugtu> Debian bug 213465 in apt "Subject: HTTPS support (Progeny)" [Wishlist,Open]  http://bugs.debian.org/213465
<mdz> thom: yes, openssl license conflicts and massive source code conflicts
<siretart> Kamion: I'm on it
<thom> gnar openssl
<thom> ok, thanks
<mdz> I think mvo sorted the source conflicts later on
<mdz> but we needed an explicit exception from someone for openssl and didn't get it
<thom> bah, ok. so it's just licensing and not a technical objection?
<thom> "just"
<mdz> there may have been issues with the code as well; I don't remember
<mdz> but  we could fix those at any rate
<thom> mdz: nod
<mdz> how is it that this xine-lib breakage isn't reported in Debian yet? odd
<thom> why the heck did they use stunnel? 
* thom gibbers
<Kamion> siretart: thanks
<Kamion> mdz: nobody ever ported it to gnutls then?
<thom> Kamion: doesn't look that way - i think the problem is that they use stunnel to do the ssl connection itself, and stunnel is built against openssl
<Mithrandir> doko: hmm, it seems like pytho-gnome2-extras isn't updated to the new python policy?
<Mithrandir> dholbach: or do you know anything about that?  It seems to block a fair bit of the gnome stack on amd64.
<doko> Mithrandir: it is
<Mithrandir> doko: doesn't seem to be:
<Mithrandir> Depends: python (<< 2.5), python2.4-gnome2-extras, python (>= 2.4)
<Mithrandir> ?
<doko> but it looks like the packages don't have a XB-Python-Version included. I will fix that, but maybe dholbach and seb128 should forward that to Debian ...
<Mithrandir> doko: what does XB-P-V imply?
<doko> Mithrandir: it allows us to see, which python versions a package supports, just by looking at the Packages file, not into the package itself. 
<Mithrandir> doko: hmm, but that shouldn't make it uninstallable?  Apt doesn't care, does it?
<doko> correct
<doko> Mithrandir: which architecture?
<Mithrandir> doko: amd64
<doko> hmm, failed to build on all archs
<doko> Mithrandir: totem is requred, but not installable
<Kamion> Mithrandir: it didn't build, this all traces back to the mesa breakage
<Kamion> ... eventually
* fabbione raises his fists in sign of almost victory..
<fabbione> only init scripts are left to be merged for the cluster suite
* fabbione starts installing a cluster or two...
<ThunderStruck> i still have python* hold backs is it safe to install them (had to do it with X
<Kamion> ThunderStruck: if trying to install them removes packages you want to keep installed, then no.
<ThunderStruck> ok didnt know the staus of them atm thats why i ask
<Kamion> that's basically why apt holds packages back (well, one of the possibilities, anyway, and the likely one here)
<doko> Kamion: how do we best remove the outdated binaries? can you find out about binaries which aren't built anymore from a source package?
<Mithrandir> gnr, ok.
<dholbach> Mithrandir, doko: slomo looked into the gnome python packages and merged them - maybe he has an idea.
<slomo> dholbach, doko: XB-Python-Version is really missing in that package in debian and for us. i'll fix it with next upload and file a bug in debian...
<dholbach> slomo: but that's not the reason why the gnome python world is in limbo atm, is it?
<doko> slomo: be prepared for accusations and other stuff ...
<slomo> dholbach: nope... that's because build-depends were failing on some archs
<Mithrandir> siretart: did you upload a fixed xine?
<dholbach> slomo: ok
<slomo> dholbach: the same as for most parts of gnome unfortunately :) but i thought that this was fixed already
<zul> hiho
<Mithrandir> ok, I'll do a new xine-lib upload so we can get totem to build so we can get python-gnome2-extras so serpentine will be installable.  Hopefully.
<Kamion> doko: yes, and I will do it AFTER the world has settled down
<slomo> doko: hm, the policy only says that this field "should" be there
<doko> slomo: that's enough for a bug report :)
<slomo> doko: yes... but this imho qualifies only as wishlist, not as important as i first thought ;)
<siretart> Mithrandir: not yet, just a sec
<siretart> Mithrandir: I'm still testbuilding :/
<Mithrandir> siretart: too late, I'll do it.
<siretart> shall I give you my branch?
<Kamion> oh I see - mesa defines a clashing version of dprintf
<Mithrandir> siretart: have you done anything but changing the libxine-dev depends?
<Kamion> there's a libxine1-dbg fix too
* Mithrandir urges his test build to build faster.
<Hobbsee> hehe
<Hobbsee> good luck Mithrandir!  once you find out how to do that, do tell me
* Hobbsee starts her package going too, come to think of that.
<siretart> Mithrandir: yes, here is my patch http://paste.debian.net/9027
<Mithrandir> siretart: ok, please upload.
<Mithrandir> Hobbsee: if I really meant it, I'd probably just have built on a faster machine.
<Hobbsee> Mithrandir: true
<Mithrandir> it's not like this old amd64 is the fastest one around here.
<Hobbsee> hehe
<Mithrandir> siretart: please try to make this cron.daily.
<Kinnison> Which means in the next 3 minutes please :-)
<siretart> Mithrandir: uploaded
<Mithrandir> siretart: you didn't confirm, so I uploaded my fixes.
<Mithrandir> siretart: well, we raced.  We'll see who wins.
<siretart> :)
<Mithrandir> siretart: according to https://launchpad.net/distros/ubuntu/edgy/+queue?queue_state=2&queue_text=xine-lib, I beat you with six seconds.
<siretart> Mithrandir: I just got an Accepted email from launchpad
<slomo> both are accepted ;)
<Kamion> Mithrandir: the second one wins, though
<siretart> let's see what ends in the archive
<siretart> lol
<Mithrandir> well, that's just as good, since siretart seemed to have more fixes.
<Kamion> ok, I should have a mesa fix for the next publisher (not this one)
<Kamion> though dear god the fix is nasty
<Kamion> what's a good test for whether libGLU is working?
<mjg59> /usr/lib/xscreensaver/morph3d
<sladen> Kamion: glxgears
<sladen> Kamion: what particular functions from libGLU are you needing to test?
<Kamion> sladen: libGLU
<Kamion> (basically ...)
<Kamion> nothing in particular, I just want to make sure it like runs
<Kamion> I'll try those two once the binaries have built
<sladen> functions like  gluOrtho2D  are used by lots of things as most people can't be bothered to set up their own matrices directly
<Kamion> also, I have a heavingly enormous pile of housework to do, so I'll be away for effectively a long lunch. I'll be working late to make up for it, which is probably going to be better timing anyway.
<Kamion> Keybuk: good timing
<Keybuk> Kamion: oh?
<Kamion> Keybuk: please shuffle linux-source-2.6.17 and xine-lib binaries through NEW as they arrive
<Kamion> I've done some of the former
<Keybuk> sure
<doko> mdz, Kamion: please requeue ecj-bootstrap on powerpc
<Keybuk> doko: do you mean give back on the buildd?
<doko> Keybuk: yes, but wait, gcj-4.1 needs to be given back first (if nobody did that already)
<infinity> doko: If it failed because gcj is uninstallable, that's not going to magicall resolve itself until gcj-4.1 can build ( which won't happen until l-k-h is fixed)
<Keybuk> hmm, ecj-bootstrap looks built to me
<doko> infinity: no, gcj-4.1 doesn't b-d on gcj
<infinity> doko: No, but ecj-bootstrap does.
<infinity> doko: No?
<infinity> doko: But Keybuk's right, ecj-bootstrap is built anyway.
<infinity> doko: gcj-4.1, on the other hand, won't build on powerpc until l-k-h gets love.
<doko> infinity: so gcc-4.1 did have the same problem, and you worked around it?
<infinity> doko: gcc-4.1 "just worked"...
<doko> infinity: so why shouldn't gcj-4.1 "just work"?
<infinity> doko: Hell if I know, but the build log looks pretty angry to me.
<infinity> http://librarian.launchpad.net/3415235/buildlog_ubuntu-edgy-powerpc.gcj-4.1_4.1.1-8ubuntu1_FAILEDTOBUILD.txt.gz
<doko> infinity: I'm really wondering how you did succeed building gcc-4.1 then ...
<infinity> doko: Either I forgot to upgrade the chroot (possible, I was only half alive), or... I have no idea.
<doko> ohh wait, I know ...
<infinity> No, wait, I definitely upgraded the chroot before I built it.
<infinity> Cause I added your bootstrap debs to sources.list before I started, then did an upgrade.
<doko> hmm, no I don't know ...
<Keybuk> I like this
<Keybuk> you're actually investigating why a build *worked*
<doko> Keybuk: no, it didn't work: FAILEDTOBUILD ;-P
<Keybuk> oh, pardon me
<Kamion> ok, there goes mesa
<infinity> doko: Well, the point being that gcc and gcj should have either both worked or both failed.  So either we're investigating why gcj failed, or why gcc didn't.
<infinity> doko: Oh, no.  I assume it's because gcc bootstrapped with an old gcc, and gcj bootstrapped with the new gcc... Or something.
* infinity 's head explodes.
<doko> infinity: no, gcj-4.1 still had the fixed multilib/multiarch mapping
<doko> needs unfixing until glibc and lkh are fixed
<jbailey> doko: What glibc problem are you thinking of?
<jbailey> doko: I have an lkh that undoes the multiarch for ia64 and parisc like you asked, and has sparc64 headers fixed.
<jbailey> What else do you need?
<doko> installation in /usr/include/powerpc64-linux-gnu instead of ppc64-linux-gnu
<doko> or is this just lkh?
<jbailey> Oh, right.  glibc fails to build at the moment with a gcc newer than 4.1.1-2ubuntu4
<Kamion> Keybuk: mesa might need NEW-shuffling on non-x86 arches too
<Kamion> though that probably won't arrive for a couple of hours yet
<doko> jbailey: the consequence of installing into /usr/include/TARGET_ALIAS is that you cannot build an unpatched compiler anymore. Ok, it's edgy, but I have to fix it in every compiler version, and you cannot build an upstream gcc anymore
<pitti> mdz: FYI, I cleaned up the field names and their documentation in https://wiki.ubuntu.com/AutomatedProblemReports
<ogra_> Mithrandir, i'll need an exception for ltsp as soon as i have my new amd64 laptop running and am able to fix the breakages 
<ogra_> is there already an ETA for the CDs ?
<janimo> Gloubiboulga: I had not updated xfce4-session and xfce4-utils yet to beta2 as not much happened since the svn snapshot we have and more importantly we have some big patches with touch configure
<janimo> Gloubiboulga: just so you know I did not forgot about those :)
<janimo> forget
<Gloubiboulga> janimo, ok :)
<jbailey> doko: Doesn't gcc have a way of specifying additional directories to use for system headers?
<doko> jbailey: no, not for biarch, the extension I did write does map the multilibdir to one multiarchdir, not more
<Kamion> ogra_: no
<ogra_> great :)
<ogra_> gives me hope to make it in time ...
<ogra_> if only this edgy upgrade would finish ...
* ogra_ taps his foot
<jbailey> doko: I'm not sure what the best solution is then.  I guess probably to get this in upstream with some configury magic so that it can be easily specified.
<jbailey> Or try and get it LSB'd or something so that they'll just do it automatically.
<ogra_> hmm, lots of locale errors on upgrade 
<doko> Mithrandir: ok to upload gcj-4.1 to fix the build failure on powerpc (and ia64, but that requires a fixed gcc-4.1 as well)
<Mithrandir> doko: please.
<ogra_> Keybuk, what about the kino breakage ?
<ogra_> any idea what causes that ?
<Keybuk> "the kino breakage" ?
<Keybuk> 0v
<ogra_> http://librarian.launchpad.net/3416008/buildlog_ubuntu-edgy-i386.kino_0.90-1ubuntu1_FAILEDTOBUILD.txt.gz
<ogra_> its only i386, ut holds back edubuntu-desktop
<ogra_> *but
<Keybuk> kino_common.h:319: error: previous declaration of 'KinoCommon* common' with 'C++' linkage
<Keybuk> preferences_dialog.cc:55: error: conflicts with new declaration with 'C' linkage
<Keybuk> *shrug*
<Keybuk> bug
<Keybuk> likely missing extern "C" in the header file
<ogra_> strange that it builds flawless on all other arches
<dholbach> debian bug 377174
<ogra_> dholbach, thanks !
<ogra_> could somebody promote ttf-dustin to unbreak khangman, Keybuk, Kamion ?
<Keybuk> ogra_: done
<ogra_> ta !
<snorre> I know this is not the right place to ask for support, but I've been trying to get help with building driver modules in the main channel to no avail
* ogra_ reboots to edgy to see if the new install survived
<snorre> I'm trying to build a driver based on a partial source code that I received directly from the manufacturer, but the driver module can't be inserted in the latest Ubuntu 6.06 Server kernel (2.6.15-23-server)
<zul> pitti: ping
<ogra> hmm, that didnt work so well 
<ogra> apparently i have no fixed font in any fontpath after the upgrade 
<Kamion> damnit
<Kamion> http://librarian.launchpad.net/3416581/buildlog_ubuntu-edgy-powerpc.mesa_6.4.2-1ubuntu3_FAILEDTOBUILD.txt.gz
<Kamion> please fix the toolchain kthxbye :p
<ogra> rodarvus, seems like mkfontdir or update-fonts-dir isnt run properly on dapper->edgy upgrades
<ogra> i guess from xfonts-base, since the fixed font wasnt found
<Kamion> BenC: <urgent> you need to include asm-generic in linux-kernel-headers on all arches
<Kamion> I think practically everything that builds anything in C or C++ will FTBFS until that's fixed
<fabbione> BenC: and please apply jbailey patch or sparc is extra doomed
<doko> BenC: and please add an *additional* /usr/include/powerpc64-linux-gnu dir with an asm symlink/dir
<Kamion> bug 52990
<Ubugtu> Malone bug 52990 in linux-source-2.6.17 "asm-generic missing from linux-kernel-headers" [High,Unconfirmed]  http://launchpad.net/bugs/52990
<BenC> doh!
<BenC> how could I forget asm-generic
* Kamion goes to mega-time-shift the rest of his working day to a time when it will be more useful. :-)
<pygi> Kamion, :)
<Hobbsee> Kamion: you mean you dont already?  wow
<Kamion> I'm normally about 9:30am until whenever I fall over
<Hobbsee> hehe
<Hobbsee> Kamion: i thought you werent supposed to fall over
<BenC> fabbione: what's the sparc patch? I didn't see anything in jbailey's email
<fabbione> BenC: it's in his second email
<Kamion> doko: previous linux-kernel-headers didn't have powerpc64-linux-gnu?
<fabbione> BenC: see /msg
<doko> Kamion: no, but that should be DEB_HOST_GNU_TYPE, but we need to keep the wrong ppc64-linux-gnu until the compilers are rebuilt
<Kamion> ah
<doko> BenC: and please don't use /usr/include/<target-alias> for ia64 and hppa yet
<BenC> doko: ok, I was just copying what was in linux-kernel-headers proper
<BenC> I noticed ia64 was already broken
<ogra_> shriek
<ogra_> /usr/include/i486-linux-gnu/asm/errno.h:4:31: error: asm-generic/errno.h: No such file or directory
<ogra_> whats that ? 
<Keybuk> ogra_: ya know, if you looked, oh, at the previous lines on this channel ... 
<ogra_> Keybuk, meh, sorry, i'm blind :)
<rodarvus> ogra_: there was a problem with font packages recompiled before we had new xfonts-utils in place
<rodarvus> (but I believed these to be fixed by now)
<Keybuk> nothing will compile at the moment
<rodarvus> ogra: you mean update-fonts-dir is failing for *all* font packages, or just a few?
<ogra_> rodarvus, i havent digged deeper than getting X to work here to be able to do some work 
<ogra_> there was no fonts.dir in /usr/share/fonts/X11/misc
<ogra_> but since it was a plain new install that i upgraded it seems to be broken
* ogra_ looks in the postinst
<rodarvus> ogra_: which package(s) is(are) failing upgrade?
<ogra_> i think the fixed font is in xfonts-base or so ...
<ogra_> hmm line 436 in /var/lib/dpkg/info/xfonts-base.postinst disagrees ...
<Keybuk> https://lists.ubuntu.com/archives/ubuntu-patches/2006-July/000001.html
<Keybuk> \o/
<ogra_> Keybuk, nice !
<BenC> I have a linux-source-2.6.17 that fixes all the lkh breakage...anyone help me in getting it built (considering lkh is broken)?
<BenC> pretty much I need linux-kernel-headers from dapper installed just for this build
<doko> BenC: isn't linux-source-2.6.17 supposed to use the included headers and don't use the system headers? then it should just build
<BenC> not for things like HOSTCC
<BenC> check the ia64 build failure, and you'll see what I mean
<Keybuk> see, if Linus had accepted CML2 ...
<BenC> things like modpost and gen* scripts are C, and wont compile
<Keybuk> this will only get worse once klibc is in the kernel
<BenC> once klibc is in the kernel, then the kernel wont depend on any userspace libs/headers to compile :)
<Keybuk> true, actually
* Keybuk hugs klibc
<Keybuk> I had another read of it this week, and remembered again why I liked it so much at Montral
<BenC> so does anyone have the power to brute force the build systems to using dapper's lkh?
<Keybuk> infinity can
<BenC> I only have the power to break things, not fix them
<Keybuk> I'm glad it's not me this cycle
<BenC> I could so something evil like copy the headers in place just this one build :)
<BenC> actually...a simple -I$(PWD)/include added to the host cflags might make it work aswell
<ogra_> rodarvus, 
<ogra_> ii  xfonts-utils                   1.0.0-6ubuntu1                 X Window System font utility programs
<ogra_> ogra@edubuntu:/usr/share/fonts/X11$ sudo update-fonts-alias --x11r7-layout misc
<ogra_> warning: /usr/lib/X11/fonts/misc does not exist or is not a directory
<ogra_> seems it ignores the new fontpath
<BenC> ok, 5.10 kernel uploaded with a temporary -Iinclude in the hostcflags, so things should get back to normal soon
<ogra_> yay
<rodarvus> ogra_: I'll see if I can reproduce this here
<rodarvus> but note that I have a semi-broken environment right now (halfway X 7.1)
<rodarvus> so I'm not sure I'll be able to reproduce things as desired :)
<ogra_> well the fix is easy 
<ogra_> as long as the new packages have it fixed there will only be a few thousand people knock on your door :)
<ogra_> before the fix is there ;)
<Keybuk> so that's kinda interesting
<Keybuk> atheros card doesn't work in currnet lrm
<Keybuk> (and man, aptitude got slow!)
<ogra_> yeah
<ogra_> hmm ? why am i running 2.6.15-23 ?
<ogra_> heh, no menu.lst entry ...
<bluefoxicy> Is it okay if I make some comments on https://wiki.ubuntu.com/AutomatedProblemReports ?
<bluefoxicy> mainly "Providing minimal symbols in binaries" I want to point out that symbols in packages won't point out to you when inline and static functions are used (having debugging information gives you the line of code responsible for an address); and point out which data is sensitive and why.
<bluefoxicy> Just tagging them at the end below Superseeded Discussion
<Kamion> BenC: any reason your -5.10 changelog isn't just the changes from -5.9 to -5.10, btw? :)
<BenC> Kamion: mainly because I'd have to get all the ABI files and put them in there if I start a new changelog entry
<BenC> this way, I just keep the 4.6 abi files, and the build is happy
<bluefoxicy> can someone explain to me what 200 megs of abi files are for
<Kamion> BenC: yum, weirdo build system. :)
<bluefoxicy> BenC:  I have a 64 bit system but sometimes a 64-bit ubuntu isn't so hot, re no flash.
<BenC> it's like one of those things you'd find if there was such a thing as kernelbuild.cheatplanet.com :)
<bluefoxicy> BenC: Any chance of a 64-bit kernel on i386?  It'd be the 64-bit kernels you have now, just marked to be able to install on i386
<BenC> bluefoxicy: where do you have 200megs of ABI files?
<bluefoxicy> oh, I dunno.  I don't remember how big they were, I just felt like poking you :)
<BenC> bluefoxicy: that's a little harder than it sounds
<BenC> but I've considered it
<BenC> thing is, USB printing is broken on when running 64-bit kernel and 32-bit userspace, so I've been reluctant
<bluefoxicy> BenC:  Specific issues I can think of are that your host suddenly becomes like x86-64-pc-gnu-linux (which borks up compilation sometimes, re openssh; at least on Gentoo it has a fit when you try to 32-bit with a 64-bit kernel); and... huh.
<bluefoxicy> why would usb printing break.
<BenC> 32-bit ioctl thunking isn't supported with usblp
<bluefoxicy> aha.
<bluefoxicy> that's possible to add though right?
<bluefoxicy> Might not be trivial but in the future it can happen..
<Kamion> proper multiarch is probably easier :P
<BenC> I think fabbione looked at it once because it's inherently broken on sparc64
<bluefoxicy> inherently broken == can't be fixed?
<BenC> inherently broken meaning sparc64 will always be 64-bit kernel on 32-bit userspace
<BenC> they have no choice :)
<bluefoxicy> why am I reading the changelogs in update manager... I always do this, like there's some useful information in there that I would actually benefit from
<BenC> I only read them to see if there's anything funny
<dholbach> haha
<bluefoxicy>   * Added xserver-xorg-input-elographics to debian/scripts/i386.vars, to let xserver-xorg-input-all on i386) to Require it correctly
<bluefoxicy> well, I see bad grammar and a stray ), that's kind of funny.
<bluefoxicy> Or at least it got a pause out of me trying to figure out what in the hell it's saying in english.
<bluefoxicy> BenC:  I am still waiting for liboobs-1-0 to get a changelog "Applied an optimization for a 30% size reduction that makes it 20% faster"
<tseng> bluefoxicy: could you please direct random comments elsewhere?
<bluefoxicy> alright wel I'm gonna tack my comments to the end of this spec since nobody seems to care
<bluefoxicy> tseng:  hi.
<tseng> hi.
<tseng> jdub: interesting topic at oscon
<jdub> tseng: my talk?
<tseng> jdub: yes.
<jdub> ahr
<tseng> what direction is it going?
<jdub> yeah, now i'm also doing a brief ubuntu thingy at tim's radar executive briefing day
<jdub> that ought to be fun
<jdub> haha
<jdub> UP!
<jdub> THE ONLY WAY IS UP!
<tseng> AND AWAY
<tseng> pants off.
<tseng> no one says that anymore
<mjg59> Jeff does
<tseng> i havent heard it in ages
<bluefoxicy> if tseng was a starship captain he'd rig the beaming thing so on peoples' birthdays you'd show up on the planet with no pants on.
<tseng> uh, right.
<tseng> way to miss the mark by about 1000 miles
<sivang> bluefoxicy: if you look at my changlog entery for notification daemon, you'd see some meniton of a Mao phrase :)
<Keybuk> thank gods I took my birthday off
<bluefoxicy> tseng:  I have no idea what you're talking about so I improvised.  it's why I have no real social life.
<sivang> Keybuk: took it off from where ?
<Keybuk> sivang: as in am taking a day's leave
<BenC> so are the build systems disabled right now? My .10 upload isn't even showing in the package list
<tseng> sivang: vacation.
<Keybuk> bluefoxicy: you need to get a hair cut, a muscle top, and head down those night clubs and shake your booty on the dance floor at pretty ghings
<Keybuk> things too
<Keybuk> BenC: -10 of?
<BenC> linux-source-2.6.17
<BenC> 5.10
<Keybuk> let me check
<Keybuk> ---------|----|----------------------|----------------------|---------------
<Keybuk>    72260 | S- | linux-source-2.6.17  | 2.6.17-5.10          | 51 minutes
<Keybuk>          | * linux-source-2.6.17/2.6.17-5.10 Component: main Section: devel
<Keybuk> ---------|----|----------------------|----------------------|---------------
<bluefoxicy> Keybuk:  I am about 98.7% sure you do not want me to do that.
<Keybuk> you uploaded it roughly 1 minute too late for the last publisher run ;)
<Keybuk> bluefoxicy: oh, why?
<BenC> ah, heh
<bluefoxicy> Keybuk:  ask tseng
<tseng> er what?
<Keybuk> tseng: can John not dance?
<tseng> Keybuk: i narrowly escaped actually meeting him in person
<sivang> Keybuk: ah, I see. Anyway I know this is becoming annoying, and I'm reminidng it to you only if you forgot :) re: SystemCleanUpTool 
<Keybuk> hmm, did I not change the status on that?
<sivang> Keybuk: not that I noticed, or either received a notification from LP
<Keybuk> I did mean to approve it yesterday
<Keybuk> maybe I didn't do it hard enough
<tseng> bluefoxicy: i have an idea what you are talking about, which is kind of more ironic than either of you realize.
<bluefoxicy> :P
<tseng> bluefoxicy: but i really have no interest in being involved in clearing it up.
<bluefoxicy> okay so I'm not so sure then :P
<bluefoxicy> tseng:  I'm interested in figuring out how to get a random .so file relocated to a specific address... I'm currently prodding elfsh to see if it can.
<tseng> that sounds like a pretty bad idea
<bluefoxicy> no, not really.  If I can get gdb to debug something like elfsh; relocate random lib to a specific address; and then have gdb compare code at address <$foo> to debugging info on the library; then I can pseudo-debug the library even though it's not in the program it used to be in
<bluefoxicy> then again I can probably just let it relocate wherever and adjust the address accordingly.  why the heck am I doing this.
<Tonio_> hi there, is it the good place to discuss proftpd issues ? I just found a hudge one...
<tseng> yeah...
<sivang> Keybuk: thanks for all the commnetns. YOu helped make it a better spec. I'm happy to hear more if you have , before you approve it.
<Keybuk> is approved already :)
<sivang> Keybuk: ah, so even if you have points that are worth thinking of and not just spec approval blockers , they are welcome as well =)
<BenC> I think I missed the seeing on the calendar that today was "see how many kernel uploads we can do in one day" day
<Keybuk> 24
<bluefoxicy> it doesn't matter to me, I'm refraining from rebooting for a while because I don't know where my X video drivers went.
<bluefoxicy> they were suddenly "local or obsolete" so I removed them all.
<bluefoxicy> and I can't find any kind of *vesa* files anywhere so I am not convinced that Xorg has video drivers anymore o_o
<Keybuk> bluefoxicy: renamed to xserver-xorg-video-*
<LaserJock> did we have issues in dapper kernel upload with people getting the new -image but not restricted-modules?
<bluefoxicy> Keybuk:  ah thanks.  Indeed none installed!
<Keybuk> bluefoxicy: yeah, we've mentioned this one to the X SWAT TEAM
<Keybuk> but they didn't seem to see the problem
<Keybuk> there should be transitional packages
<bluefoxicy> the problem.. how to describe.. if you install ubuntu-desktop from an ubuntu-minimal install you probably won't have video drivers.  8)
<bluefoxicy> Keybuk:  thanks, I feel much safer now.
<ogra_> jdub, did you notice that the fridge calendar is gone ?
<jdub> ogra_: the website moved host without my knowing; i hadn't had time to check everything yet - thanks for pointing that out
<ogra_> :)
<LaserJock> jdub: and fridge rss doesn't seem to be working right now, if you didn't know already
<Kamion> E: Couldn't find package nic-firmware-2.6.17-5-386-di
<Kamion> damnit, soyuz, that's a dep-wait :-P
<Kamion> c.f. https://launchpad.net/+builds/+build/228676
<robitaille> jdub,  is there a problem with the fridge?  I can't seem to be able to access any pages except the main page
<jdub> robitaille: yeah
<jdub> robitaille: it magically changed hosts, and lots of stuff is broken
<jdub> robitaille: i haven't had time to climb in and find out what's up yet 
<robitaille> ah magic.  The source of so many computer problems :)
<jdub> it still has its blue smoke though :)
<sladen> ooh, working again
<Kamion> Keybuk: could you give-back debian-installer 20060711ubuntu3 on amd64, i386, and powerpc, please?
<elmo> yeah fridge is fixed, sorry about that, my bad
<robitaille> thanks elmo  jdub 
<ogra_> thanks elmo 
<jdub> elmo: rock, thanks!
<jdub> elmo put the magic back in :-)
<Keybuk> debian-installer 20060711ubuntu3 - powerpc ia64 i386 amd64
<sladen> oooh, now that's fixed, time for an update!
<sladen> hint hint, prod prod, /me looks in jdub's direction
<Kamion> Keybuk: ok, ia64 didn't need it, but it can always fail again ;-)
<Keybuk> Kamion: heh, I haven't given my tool any smarts to exclude or include arches
<Keybuk> it just gives back any build that failed
<Keybuk> I still want to know what "Blind" and "Consult" mean on my phone
<mhb> hello everyone
<mhb> I have a tiny little question - is it too late to post specs for Edgy?
<Keybuk> it depends, is it a spec you want to implement yourself, or is it one you want somebody else to implement?
<mhb> I think I could handle it myself, if someone allows me to
<Keybuk> well, you're free to do anything you like :)
<mhb> my spec could get rejected
<Keybuk> it's too late for a spec to be considered a "feature goal" for edgy ... but that doesn't mean that if your spec were implemented before feature freeze that it could not be part of edgy
<Keybuk> right, that's always true though
<mhb> to be exact: I want to make some changes in gdm and kdm to enable Gnome and KDE to shutdown even with the "inappropirate" session manager
<mhb> do you think it could get approved?
<Keybuk> I don't see a reason why not, draft a spec
<Keybuk> obviously I can't review a spec I haven't read yet
<BenC> clearly I'm going to need infinity's help to get a kernel build to succeed today
<zul> heh
<mhb> Keybuk: I'll do it as soon as I have some free time (on Monday) - I wanted to make sure that it isn't too late
<BenC> mhb: it's never too late if you have connections, and monetary contributions always help with that
* BenC could use a few extra bucks
* mhb too
<Keybuk> BenC: here's a nickel, buy yourself a REAL internet connection :p
<BenC> gonna need a lot of nickels to get that last .8 miles of coax to my house
<Keybuk> jbailey did an amusing impression of VoIP over your connection earlier
<BenC> probably not too far off from when you watch cnn/bbc and their reporters are talking to each other over a sat link :)
<BenC> probably need to use ham or cb lingo to make it useful..."The development cycle will not adversely affect our stability...OVER", "10-4, I'll not that on the weekly progress...OVER"
<LaserJock> lol
<LaserJock> throw in some police codes and you could probably get away with Morse code
<Keybuk> aha!  Blind and Consult are methods of call transfer
<BenC> "Soyuz has a 220 in progress...OVER"
<Keybuk> 220 ... hmmm, oh, "running under cron.keybuk due to publisher taking ages again"
<LaserJock> "Code Blue, the kernel is going down"
<BenC> "Team Admin responding to 220, request backup...OVER"
<BenC> "Roger that, Team Admin, The Elmo is en-route, and will aide in the apprehension...OVER"
<BenC> I need a spotlight with a cool symbol to shine in the sky so I can summons infinity
<tseng> an.. infinity symbol
<tseng> and a silloette of elmo the muppet
<BenC> hehe
<Keybuk> BenC: it's like 8am there ... he's probably only just gone to bed! :P
<msw> tseng: people might mistake it for the fedora logo
<msw> tseng: http://people.redhat.com/dfong/icFedora/060712/060712.jpg
<tseng> yes i am familiar
<bluefoxicy> msw:  I mistake the RedHat logo for Carmen Sandiego all the time
<LaserJock> haha
<LaserJock> that's the first thing I thought of when I saw it
<msw> bluefoxicy: heh, yea.  when the design firm first showed Red Hat the shadow man logo, that was the immediate response.  it nearly killed it being accepted
<bluefoxicy> LaserJock:  I could rant on it, since I just saw those guys jump up and blatantly claim they invented something that some other guy came up with on the binutils mailing list; but I'll leave that for another time and place
<bluefoxicy> msw:  seriously?
<LaserJock> I always thought it was cool, though a little mobsterish
<bluefoxicy> LaserJock:  I find it fitting.
<msw> bluefoxicy: no joke
<bluefoxicy> RWX --- ---   /usr/bin/lame
<bluefoxicy> Irony.  Total irony.
<tseng> ?
<tseng> you are an odd bird
<msw> lifeless: I just ran bzr vis on a new branch we've been working on -- the results are *MUCH* better than hgk
<bluefoxicy> tseng:  executable stack == lame; and lame has an executable stack.  It doesn't make you chuckle?
<tseng> bluefoxicy: no, its a pretty obvious (And childish) pun
<tseng> lame, even
<LaserJock> yikes
<bluefoxicy> LaserJock: ?
<ThunderStruck> was libonobo updated in dapper?
<crimsun> ThunderStruck: ?
<msw> ThunderStruck: https://launchpad.net/distros/ubuntu/+source/libbonobo
<crimsun> it hasn't been updated since release, why?
<ThunderStruck> libonobo was updated for edgy the other day now someone on dapper is complaining about that stpping him from booting ubutnu (same issue on edgy) but rebooting fixed that
<ThunderStruck> ok ty just making sure i didnt think it was updated in dapper
#ubuntu-devel 2006-07-15
<lifeless> msw: thank you
<Kamion> ThunderStruck: libbonobo wouldn't be able to stop you booting. It might stop the desktop coming up properly.
<ThunderStruck> Kamion: correct well thats what bothered me than he said due to no net connection he couldnt boot i threw up my hands on him
<ThunderStruck> libbonobo caused panels to not show up
<Kamion> that's certainly possible in edgy
<ThunderStruck> it did it to me today but only once
<Kamion> (in the sense that anything's possible in edgy. I don't know anything about this specific issue.)
<ThunderStruck> i have a feeling its related to a few icons breaking but havent looked into it yet
<mdz> totem still doesn't build, even with fixed xine-lib
<mdz> http://librarian.launchpad.net/3419820/buildlog_ubuntu-edgy-i386.totem_1.5.4-0ubuntu1_FAILEDTOBUILD.txt.gz
<mdz> the error doesn't make much sense though
<mdz> /usr/include/i486-linux-gnu/asm/errno.h:4:31: error: asm-generic/errno.h: No such file or directory
<mdz> those are both in linux-kernel-headers
<mdz> what's worse, it builds fine for me locally
<mdz> oh, wait, linux-kernel-headers may have changed since I upgraded
<ThunderStruck> they were updated today
<Seveas> mdz, there are other things missing from l-k-h too according to malone
<mdz> Seveas: I filed bug #53028
<Ubugtu> Malone bug 53028 in linux-source-2.6.17 "linux-kernel-headers regressions" [High,Unconfirmed]  http://launchpad.net/bugs/53028
<mdz> marking bug #51369 as a duplicate even though it's older because mine is more complete ;-)
<Ubugtu> Malone bug 51369 in linux-source-2.6.17 "Changes root device path without migrating fstab" [High,Confirmed]  http://launchpad.net/bugs/51369
<Seveas> mdz: bug 52990
<Ubugtu> Malone bug 52990 in linux-source-2.6.17 "asm-generic missing from linux-kernel-headers" [High,Unconfirmed]  http://launchpad.net/bugs/52990
<mdz> right I meant bug #52990
<Ubugtu> Malone bug 52990 in linux-source-2.6.17 "asm-generic missing from linux-kernel-headers" [High,Unconfirmed]  http://launchpad.net/bugs/52990
<Kamion> mdz: meh, BenC knew the problem from mine anyway ;)
<Kamion> mdz: he tried to upload to fix it already, but unfortunately since the kernel uses the host compiler for a few userspace programs during the build it needs a manual bootstrap
<Kamion> (he did try to hack around that requirement but it apparently didn't work)
<mdz> gar
<Kamion> infinity: you aren't around yet by any chance are you?
<mdz> it's infinisaturday
<mdz> meanwhile, my laptop freezes up hard while loading gdm for some reason
<mdz> the X server on its own starts fine
<mdz> now I know how I'll spend the evening before my next flight
<Kamion> anyway, until the kernel bootstrap happens, edgy is basically wedged solid
<mdz> indeed
<mdz> one might even say "fux0red"
<mdz> oh, good, 2.6.17-5.9 fixes my laptop freeze
<mdz> hmm, or not.  it fixed it in single-user
<bluefoxicy> You know what would be nice?
<bluefoxicy> http://neosmart.net/gallery/v/os/ROS/Booting.png.html  If we had a boot screen like this
<bluefoxicy> The Ubuntu bootsplash theme is very light, simple, easy on the eyes.. I wonder if there's any merit to being a little flashy about it some time down the road.
<Burgundavia> bluefoxicy: the issue is older machines
<bluefoxicy> Burgundavia:  well, I'm thinking a static image, not i.e. Xubuntu pops up and there's 6 mice running in hamster wheels and rolling around with eachother on the screen fully 3D accelerated :P
<Burgundavia> still run into older machines
<bluefoxicy> not enough color display?
<bluefoxicy> Burgundavia:  how old are we talking about btw?
<Burgundavia> I don't know
<bluefoxicy> I've used Ubuntu Dapper on a 350MHz K6-2 with 192 megs of ram
<Kamion> new laptops - use anything but vga16fb and you break suspend/resume
<Kamion> it's not really an old-machines issue at all
<bluefoxicy> it took about 6 tries to get it installed, it takes it 15 minutes to boot the install livecd, the installation kept failing (I had to kill off all of gnome and then get X to start with just a terminal, kill some startup services), took it about half an hour to copy all files, and about 2 minutes to load openoffice.org once I rebooted into the system.
<bluefoxicy> Kamion:  nods
<bluefoxicy> so only want to display 16 colors
<bluefoxicy> Kamion:  the current is only vga16fb though right?
<Kamion> yes
<bluefoxicy> mmm.  I miss Kdrive, did that project die?
<bluefoxicy> Kdrive was great for doing little hacks like full X11 boot screens ;)
<bluefoxicy> (since it fit in ... oh.... 300k, and pushed most everything it could into video memory before XFree86 started doing that)
<bluefoxicy> More stuff that'll never happen.
<johanbr> bluefoxicy: I think the GPE graphical environment for handheld devices still uses Kdrive.
<jdub> kdrive definitely didn't die
<Viper550> Hello everyone
<Viper550> I've got a great new spec for your examination today!
<Viper550> anyone>
<Viper550> ???
<Lathiat> Viper550: just fire away 
<Viper550> https://launchpad.net/distros/ubuntu/+spec/desktop-slab
<Viper550> So, your thoughts?
<bluefoxicy> johanbr:  I was thinking of an Ubuntu Kdrive package, with a rescue mode that tries to get gtk+ kdrive Xlibs working
<bluefoxicy> johanbr:  in VESA only of course.  I figured compressed all the needed libs come under 2 megs, minus glibc and busybox
<johanbr> bluefoxicy: Ah, okay. Don't know anything about its current status in ubuntu.
<bluefoxicy> I do that a lot, there's a lot of neat ideas bouncing around in my head that'll never go anywhere.  And I think Kdrive doesn't even have a Debian proper package in sid, much less Ubuntu universe package.
<bluefoxicy> tseng has recommended numerous times that I get a blog
<tseng> if only so I could filter it out
<bluefoxicy> tseng:  as noisy as I am, I do try to be quiet when there's actual useful conversation around :)
<zul> tseng: you need the charlie brown bassoon
<tseng> zul: im not familiar
<zul> tseng: when peppermint patty always talk to the teacher in peanuts its a basson
<tseng> oh right
<tseng> wamp-wa-wamp-waa
<bluefoxicy> and they always talk back to her like normal
<bluefoxicy> that was the first time I got smacked as a child, you know that?
<bluefoxicy> I said "what the hell?" and my daddy smacked me.
<bluefoxicy> (no not really)
<bluefoxicy> anyway /me goes back to trying to do something useful.
<bluefoxicy> .... unless anyone wants to explain to me why hitting "ok" in network-admin results in a 64-bit Athlon 3000+ with 512 megs of ram, freshly booted, sitting around for over a minute and not actually setting my gateway until the end of that time, just for a default gateway device change.
<zul> no not really
<whiprush> jdub: hey did you get my response to fridge-devel wrt. silbs' email?
<Hobbsee> how close is the knot 1 cd?
<orpheus> hookay, so I've got a question:
<orpheus> say i have a package
<orpheus> and i want to play with the source of that package
<orpheus> 'cause there's a thing or two I'd like to chance
<orpheus> *change
<anibal> busybox 1:1.1.3-2ubuntu1 and swapspace 1.6-2 FTBFS similarly on ia64 and sparc, I've compared the failed build logs with the i386 one to no avail, could someone have a look at this problem? Alternatively, how can I get access to both sparc and ia64 devel machines?
<orpheus> and i'd like to play with it the source 'the ubuntu way' ('the debian way' )
<orpheus> what magic do i need to know?
<orpheus> i'm presented with a source package with 30-some patches
<orpheus> and as i understand it, the patches are applied .. in order... and thus... depend on being applied only in that order
<orpheus> so if i play with any of the source before dpkg-buildpackage'ing it, no matter how minor the change, one of those patches is bound to fail
<orpheus> and then i get a source tree with some patches applied and some not, and it gets rather broken
<orpheus> soo... what's the right way to play with the source of a package?
<Hobbsee> anibal: create a chroot with ia64 or sparc architecture?
<infinity> Hobbsee: You should probably re-read what you typed and think about that for a second. :)
<infinity> anibal: Try not to ask the same question in multiple channels, so I don't have to answer you twice. ;)
<Hobbsee> infinity: oh bleh.  yeah, probably.
* Hobbsee is fighting with pbuilder.
<Hobbsee> dont pick on me :P
<anibal> infinity, sorry, ta anyway :)
<anibal> Hobbsee, for the record: from infinity to anibal: It's a known bug in linux-kernel-headers and gcc, it's being sorted, don't worry about it.
<Hobbsee> anibal: okay then
* Hobbsee curses pbuilder.
<Hobbsee> wonder why my --update-config parameter doesnt work
<Hobbsee> er, override-config
<fabbione> morning guys
<jdub> mdz: ping
<Hobbsee> hi fabbione, jdub 
<Hobbsee> jdub: isnt it too early for that?
<fabbione> hey Hobbsee 
<jdub> probably
<Burgundavia> very much so, unless mdz is still up (midnight here)
<Hobbsee> heh
<Hobbsee> hi Burgundavia 
<Burgundavia> hey Hobbsee
<Hobbsee> jdub: seems that you lost that interview from your hard drive - yay!
<jdub> Hobbsee: ha ha, no
<Hobbsee> jdub: damn!
<Hobbsee> jdub: whyever not?
<jdub> for some reason it was saved as penis.spx
<Hobbsee> only because you saved it like that.
<StevenK> jdub: Will this interview be made public?
<jdub> StevenK: probably
<Hobbsee> unless you happen to accidently delete it
<jdub> seriously
<jdub> who is going to accidentally delete a file called penis.spx?
* Hobbsee would
* Hobbsee runs rm -rf * sometimes.
<Tmob> any acpi-support devs around?
<Hobbsee> Tmob: it's a saturday. most unlikely.
<Tmob> Hobbsee, geeks have holidays?
<Hobbsee> Tmob: they have weekends sometimes
<Tmob> heh.. just made a patch for sleep.sh for acpi event jitter.. was curious if anyone can comment
<Tmob> Hobbsee, any idea who is the maintainer?
<jdub> Tmob: you're looking for mjg59, pretty much
<Hobbsee> there you go :P
<Tmob> okeydok
<Tmob> anyway.. posted a bug report and on -devel list.. will wait
<ogra> ugh
<ogra> plese dont abuse -devel for bugs
<Tmob> ogra, hm? bug-fixes?
<ogra> we have a bugtracker
<Tmob> awww :/
<Tmob> well i tought patches are posted on the devel list
<Hobbsee> hi ogra 
<Tmob> whats the devle list for then
<ogra> https://launchpad.net/distros/ubuntu/+filebug
<ogra> development related discussion
<ogra> hey Hobbsee :)
<Hobbsee> ogra: i've been killing things again :)
<ogra> Hobbsee, i just saw your kid was accepted ... :)
<Hobbsee> ogra: yeah, finally.
<ogra> Mithrandir, around ? my ltsp fixes would be ready for upload ...
<hunger_>  Yeah! kernel 2.6.17-5-686 boots again! Any chance of getting the restricted modules and stuff for that soonish?
<ogra> hunger, its weekend ... 
<ogra> give us a chance to recover :)
<Hobbsee> ogra: doesnt give you guys the excuse to take a holiday
* Hobbsee cracks her whip
* Hobbsee thwaps ogra with it.
<Hobbsee> ogra: how'd you get back out of /dev/null?
<ogra> more more!
<jsgotangco> doh!
<Hobbsee> um, scary.
* ogra is missing JaneW's regular whipping
<ogra> :)
<jsgotangco> would you rather want RichEd to do that to you?
<ogra> Hobbsee, i crawled indeed ... holding tight on a stream coming from /dev/zero
<Hobbsee> ogra: hehe
<hunger> ogra: Oh, I thought all those things get rebuild automatically nowadays...
<hunger> ogra: Sorry, I was not implying that you boys (and girl) are lazy:-)
<ogra> jsgotangco, well, lets see :)
<ogra> hunger, i know :)
<Hobbsee> hunger: heh.  the one girl, all alone.
<Hobbsee> hi lifeless_
<hunger> Hobbsee: Yeap, I was refering to you;-)
<Hobbsee> hunger: i figured that :P
<Hobbsee> hunger: although, does ogra count as vaguely girly with his ponytail?
* Hobbsee ducks
<infinity> A lot of us have pony tails, not sure that counts for much.
<hunger> Hobbsee: See, this time I remembered you were on of those mysterious other kinds of human beings rumored to exist somewhere.
<ogra> Hobbsee, i'm way to beardy to be counted as a girl today :)
<Hobbsee> hunger: heh
<Hobbsee> ogra: haha
<Hobbsee> infinity: i know, i was teasing :P
<Hobbsee> oh shoot - glad i didnt hit y!
<Hobbsee> Sure you want to delete all the files in /home/sarah [yn] ? n
<ogra> y
<ogra> *g*
<infinity> That prompt really needs to be [ynm] 
* Hobbsee thwacks ogra with the whip again.  now get to work!
<infinity> Indeterminate computing rules.
<Hobbsee> hehe
* hunger sighs. Now I finally got suspend to ram back with 2.6.17 and then the wlan drivers are not there yet:-(
<sivang> re dudes
* ogra wonders why schooltool still shows up on edgy_probs ... doko uploaded the fixed package on thursday or so ... 
<ogra>   File "setup.py", line 52, in ?
<ogra>     from zope.app.locales import extract
<ogra> ImportError: No module named zope.app.locales
<ogra> grmpf
<Hobbsee> hi sivang 
<sivang> hey Hobbsee 
<sivang> ogra: schooltool ? :-)
<Kamion> infinity: any chance of a mass give-back now that l-k-h is fixed?
<infinity> Kamion: Define "fixed".
<Kamion> "it is possible to compile C programs again"
<infinity> Kamion: sparc/ia64 still seem buggered, and linux-source is now FTBFS.
<Kamion> yeah, but mesa and xine-lib would be worth a shot at least
<infinity> Kamion: doko's uploading yet another lkh fix.  Not sure what that will un-fuck.
<Kamion> powerpc should be happier, and it has some serious problems
<Kamion> s/has/had/
<infinity> Well, I can certainly do a mass-give-back.
<infinity> I'm sure we'll need another this weekend.
<Kamion> yeah - just want to see if we can get up to python-gnome-based stuff being installable on powerpc
<Kamion> which should (I think) be possible now and would help matters a lot
<doko> Kamion, infinity: please wait a bit, it looks like linux-source -5.11 "fixes" the include dir, but our compilers don't know about it
<doko> and working on the ia64 fix now
<infinity> Kamion: Nevermind, can't do a mass-give-back.
<Kamion> doko: what's wrong with the current l-k-h on powerpc?
<infinity> Kamion: Requires direct DB access.
* Kamion doesn't want to wait a bit for ubiquity to be buildable :-P
<infinity> Kamion: But we can cherry-pick a few things you think might be in better shape.
<doko> Kamion: doesn't have a /usr/include/powerpc64-linux-gnu
<Kamion> wow, https://launchpad.net/distros/ubuntu/+source/xine-lib is confused
<Kamion> doko: what does that actually break?
<infinity> Kamion: Oh, cool.  Looks like the ACCEPTED clash led to no build records for the upload that won..
<infinity> \o/
<doko> Kamion: AFAICS linux-source -5.11 changes that from ppc64 to powerpc64, breaking all our compilers
<infinity> Or, at least, ones I can't get to from the web UI...
* infinity looks for them another way.
<infinity> https://launchpad.net/distros/ubuntu/edgy/+builds?build_state=failed&build_text=xine-lib
<infinity> That'll do.
<Kamion> doko: -5.11 hasn't built anywhere
<Kamion> so that doesn't matter
<Kamion> https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.17/2.6.17-5.11
<Kamion> infinity: mesa/amd64 and mesa/powerpc would be nice, certainly
<infinity> Yeah, working on those.
<Kamion> noting doko's concerns but it really can't hurt to try
<infinity> Just watches xine-lib fail because of those being out of sync.
<infinity> s/watches/watched/
<Kamion> if mesa builds, xine-lib then totem then gnome-python-extras, iirc
<doko> In file included from scripts/mod/../../include/linux/input.h:19,
<doko>                  from scripts/mod/file2alias.c:40:
<doko> include/asm/types.h:31: error: redefinition of typedef '__u8'
<doko> scripts/mod/file2alias.c:34: error: previous declaration of '__u8' was here
<doko> include/asm/types.h:34: error: redefinition of typedef '__u16'
<doko> scripts/mod/file2alias.c:33: error: previous declaration of '__u16' was here
<doko> include/asm/types.h:37: error: redefinition of typedef '__u32'
<doko> scripts/mod/file2alias.c:32: error: previous declaration of '__u32' was here
<doko> make[4] : *** [scripts/mod/file2alias.o]  Error 1
<doko> make[3] : *** [scripts/mod]  Error 2
<doko> make[2] : *** [scripts]  Error 2
<doko> hmm, powerpc, with Ben's fixed lkh ...
<Kamion> yeah, but that's in the kernel and IIRC is due to the extra -I he put in as a workaround
* Kamion wonders if anything new is going to appear on https://lists.ubuntu.com/archives/ubuntu-patches/2006-July/thread.html
<infinity> Kamion: How quickly is mesa expected to fail if it does?
<Kamion> infinity: either as soon as it tries to compile something written in C, or about 20 minutes in
<infinity> Okay, well the former hasn't happened.  Let's sit back and wait for the latter.
<Kamion> before my recent fix, it took 27 minutes to fail
<Kamion> https://launchpad.net/+builds/+build/228411
<infinity> I'm offended that we have packages that take 27 minutes to build at all.
<Kamion> it's a hell of a lot slower on my laptop :(
<Kamion> took hours to build far enough for me to test the fix
<sivang> Kamion: is this a new mailing list?
<Kamion> sivang: yes
<infinity> I'm registering a spec for edgy+1 to remove all sources that can't be built in the space of a publisher run.
<Kamion> ask Keybuk for the details
<infinity> Hopefully that doesn't turn into an LP spec to make the publisher slower.
<sivang> Kamion: cool, thanks
<infinity> Kamion: Which laptop is this that's that slow?  Mine's gnerally faster than the buildds (except on really disk-intensive stuff)
<infinity> Of course, I specced it to be "faster than a buildd" intentionally, noting what I do for a living.
<infinity> Hunting build failures on slow hardware is teh suck.
<Kamion> my G4. I think it mostly needs more RAM.
<Kamion> its processor may not be brand new but it isn't THAT bad
<Kamion> and the disk is newish so it's probably not that, though I do give it quite a beating
<infinity> Although, there is something to be said for the skills acquired through using REALLY slow hardware.
<doko> hmm, no access to chinstrap again?
<infinity> m68k failure tracing has led me to be able to wrest all sorts of info from build logs that surprises even me.
<infinity> doko: /topic in #canonical
<Kamion> you mean "no, don't run a full build from scratch when you change one file"?
<doko> infinity: ok, seen
<infinity> Kamion: I mean "don't rebuild at all, just read logs and divine the problem, as if by magic or sheer luck".
<infinity> Kamion: Well, then the "don't rebuild the whole bloody thing, argh" bit follows. :)
<Kamion> ah yeahh
<infinity> Kamion: But the Adam of 3 years ago would look at the Adam of today as if he was some kind of mind-reading wizard.  Necessity may or may not be the mother of invention, but she certainly gives birth to rapid learning of bizarre skillsets.
<Kamion> you do have a tendency to glance at build logs and go "oh yeah, it's that bug"
<ogra> Kamion, i see the same slowness on my ibook ... pbuilder-satisfydepends takes 45min for gnome-power-manager here
<Kamion> it's quite distressing until one works out that that's because it's the 175th instance of that problem you've seen
<Kamion> ogra: mine is not that slow
<ogra> well, yours is a bit more powerfull :)
<Kamion> I would strace it if I were you; 45 minutes is obscene
<ogra> it only happens on ppc
<Kamion> then again strace is my hammer I apply to all problems, regardless of the cause
<ogra> same build on i386 is done in 4 min
<ogra> well, i tooke the easier way and bought a new laptop :P
<ogra> -e
<doko> hmm, maybe I should use the time until BenC gets awake for the gcc include dir fixes, once and forever ...
<Hobbsee> doko: or just call him and make him fix the world now, immediately :P
<infinity> Okay, mesa failes in ia64 due to the known lkh/gcc disagreement.  That's no surprise.  Still going on amd64/i386/sparc (I assume sparc will fail too?)
<doko> infinity: new lkh uploaded, which should fix that
<infinity> s/failes/failed/
<infinity> doko: Oh, keen.  I'll retry it later, then.
<doko> I don't know much about the sparc failures
<infinity> Where "later" is "when I pass by my laptop again"...
<Kamion> er - mesa/i386 didn't need rebuilding
<infinity> Err, amd64/powerpc/sparc
<infinity> Brain wrong, soyuz right.  Honest.
<infinity> (This time)
<Kamion> not sure about sparc - it hit the same mesa-specific problem as powerpc earlier
<infinity> Ahh, cool.  Then maybe it'll complete too.
<Kamion> depends exactly how broken l-k-h is there at the moment
<infinity> It had "some breakage", but I'm slipping in my old age and illness.
<infinity> And maybe it's happy with the current version.
<infinity> amd64 successful.
<doko> hmm, looking at sparc now ...
<siretart> Kamion: re: launchpad beeing confused by xine-lib, shall I do another upload?
<infinity> siretart: No, it's just the UI that's confused.
<infinity> siretart: The archive and the queues seem fine.
<siretart> allright
<infinity> powerpc successful
<siretart> infinity: i'm a bit confused that it still hasn't been built
<infinity> siretart: Working on that now.
<Kamion> siretart: build-wise, the whole world has been very confused since then
<siretart> oh darn..
<Kamion> but should be more sorted now
<Kamion> infinity: sparc's got past the previous failure
<infinity> Siffy.
<infinity> spiffy, too.
<infinity> Looks successful even.
<infinity> Now to go do girly things like dye my hair and shower while I wait for publisher goodness.
<doko> infinity: so sparc looks fine, or does it still need some fixes?
<infinity> doko: Looked happy building mesa.  If it needs fixes, I'll let people argue about it on Monday.
<Kamion> let's just hope that mesa doesn't hit NEW on those arches
<infinity> Oh, ugh.
<Kamion> hasn't seemed to on powerpc, anyway
<infinity> We still can't actually manipulate the queue via the web UI, can we?  Only view it?
<Kamion> right
<infinity> Dang. :)
<infinity> Here's hoping, then.
* ogra wonders if Keybuk has booted without "splash quiet" since the switch to dash 
<jono> hey
<sivang> hey jono , what's cracking?
<jono> sivang, nothing much, just catching up on mail before I run out
<sivang> jono: planning to do some stuff out and about? :-)
<jono> sivang, walk dogs, watch superman, have bbq - thats the sum of today :P
<jono> sivang, you up to much ?
<ogra> dogs ? 
<ogra> you have multiple ?
<sivang> ogra: he has few of that :)
<ogra> cool 
<sivang> jono: Watching some DVDs, maybe some walks outside we'll see :-)
* ogra has only one left
<jono> ogra, two mini-daschunds :)
<sivang> ogra: I have a boxer mixed with a cocer spinal at my parent's house :)
<sivang> he's a mad-dog! was crazy like hell when he was a pupp
<ogra> jono, heh
<ogra> jono, but youre not a secret german, are you ? ;)
<jono> ogra, not that I am aware of :P
<ogra> heh
<ogra> in germany the dachshund owners are the guys who mow their lawn with a nail scissor :)
<ogra> i only met sane non german dachhund owners in my life :)
<infinity> doko: Oh, the sparc issue is missing sparc64/asm stuff.  See the build failure for gcj-4.1:
<infinity> http://librarian.launchpad.net/3421827/buildlog_ubuntu-edgy-sparc.gcj-4.1_4.1.1-8ubuntu2_FAILEDTOBUILD.txt.gz
<doko> infinity: yes, that was the old lkh, should be fixed now.
<infinity> doko: Fixed as of -5.10.1?
<doko> -5.10 
<infinity> That build used -5.10
<doko> hmm 
<doko> starting a test build. it *should* work
<Hobbsee> Launchpad will be going offline for maintenance in nine minutes.
<elmo> *.ubuntu.com, launchpad.net etc. are going offline for a couple of minutes for some necessary maintenance
<elmo> (back)
<mjg59> Would people please stop assigning bugs to "acpi"?
<mjg59> apt-cache show acpi should give you a clue as to why this is a bad idea
<Lathiat> heh
<ogra> hmm, with ohci_hcd loaded my lappie only does usb 1.1 ... with ehci_hcd loaded it does 2.0 ... with both loaded it does 1.1 only and ignores the ehci driver completely ... weird  
<sladen> ogra: which order did you load them?
<ogra> sladen, the kernel (or udev ?) did
<ogra> i didnt load them at all ... but if i remove both and load ehci it works fine ...
<ogra> seems i'm not alone 
<ogra> http://www.linuxquestions.org/questions/showthread.php?t=446472
<ogra> same laptop, same prob
<ogra> intrestingly *everything else* on this laptop works, even the hotkeys etc .. out of the box in edgy... the above actually seems to be the only problem
<sladen> ogra: have you had a peek in the kernel to see if any of the other HP's already have workarounds 
<ogra> nope
<ogra> not yet ... 
<ogra> doko, any thoughts about http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227#c8 ? kino suffers from it ... will it be reverted in gcc or do we have to wait for a kino rewrite ? 
<Ubugtu> gcc.gnu.org bug 27227 in c++ "[4.0 Regression]  rejects valid code with some extern "C"" [Normal,New]  
<ogra> Keybuk, 
<ogra> good afternoon :)
<Keybuk> hidihi
<ogra> did you ever boot with splash and quiet options turned off since the switch to dash ? 
<ogra> i have a ton of "open: failed" messages here
<Keybuk> "failed" ?
<ogra> havet dug deeper yet
<ogra> something like that
<Keybuk> I fixed the last round of "No such file or directory" errors, I thought
<ogra> i havent got the original message here
<ogra> but it seems to affect every bootscrpt
<Keybuk> yeah. it'd be usplash_write bitching
<ogra> so i suspect something like the lsb functions that is in every script
<ogra> or usplash :)
<Kamion> ahh, totem/i386 built finally
<Kamion> so after this publisher run, gnome-python-extras/powerpc can be given back
<ogra> sigh, and i still dont know what to do about kino
<Kamion> is it that hard to fix?
<ogra> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27227
<Ubugtu> gcc.gnu.org bug 27227 in c++ "[4.0 Regression]  rejects valid code with some extern "C"" [Normal,New]  
<Kamion> yes I know
<ogra> its not a kino bug imho
<Kamion> that's not my reading of the bug
<Kamion> the point being made there is that gcc point releases shouldn't reject previously working code
<ogra> well, the bug is to introduce breaking changes in a minor version bump
<Kamion> nobody is suggesting (AIUI) that the rejection is invalid
<Kamion> so it is BOTH a gcc and a kino bug
<ogra> sure
<ogra> but at the moment my reading is that gcc is at fault
<infinity> So fixing kino is still worth the effort anyway.
<Kamion> fastest course of action from your point of view is to fix kino
<Kamion> and that's also the best long-term action
<infinity> gcc is not at fault for the code being broken, only for the FTBFS happening a few months sooner than you'd hoped.
<Kamion> ogra: no, BOTH gcc and kino are at fault
<ogra> yes
<ogra> but if we use gcc we shouldnt introduce that "feature" 
<ogra> we reverted stuff in other areas before because of this ... i.e. the next-server option in dhcpd
<Kamion> I'm not arguing that the gcc change shouldn't be reverted - I don't have enough knowledge there really - but you should definitely fix kino, and there should be no harm in just doing it now
<infinity> Err, even if the change gets reverted in gcc-4.1.2, it WILL land in 4.2.0
<Kamion> ogra: there's no excuse for not bothering to fix stuff like this near the start of a release cycle, honestly
<infinity> So either way, kino needs to get fixed.
<Kamion> if it were near the end, I'd agree with you
<ogra> Kamion, i dont say kino should stay buggy :)
<Kamion> yes you do, repeatedly
<Kamion> you keep saying it's gcc's fault, and that it should be reverted, and that you don't know what to do
<infinity> You seem to be implying that gcc should get reverted, and you should sitck your head in the sand about the kino bug until upstream deals with it.
<infinity> I'm saying that both should get fixed.
<infinity> I'm sure doko will revert the gcc change, but that's no excuse for not fixing kino.
<Kamion> it's 13 packages according to tbm, that's easy to blitz
<Kamion> then no more problem when gcc 4.2 arrives
<ogra> sure
<ogra> what i meant is that i'd prefer upstream to dea with it (kino upstream is usually responsive) instead of introducing a patch we dont need *yet*
<ogra> sure kino should also be fixed
<Kamion> the big blocks of code inside extern "C" in kino are a bit weird, I must say
<ogra> yep
<Kamion> my C++ is not what it used to be, but that's not the way I'd have done it ...
<Kamion> hmm, I wonder what to do about libfam0 showing up in anastacia output
<Kamion> it's because gamin's shlibs got changed to say libfam0 for linkage against libfam
<ogra> do any KDE parts still use it ?
<ogra> ah
<Kamion> maybe change the shlibs to say libgamin0 | libfam0?
<Kamion> it can sort of be worked around in the seeds but not really - fam would still get pulled into main due to build-depends
<Kamion> (just tried that)
<mjg59> Oh argh.
<mjg59> New hal needs new udev = pain
<Kamion> Scott's working on new udev
<ogra> oh fun
<mjg59> Yeah
<Kamion> but post-knot-1 I think
<mjg59> I was sort of planning on doing upstream hal hacking, but that looks awkward right now
<ogra> Kamion, wasnt there some corner case with nfs mounted home or something wheer you needed fam for nautilus instead of gamin ?
<Kamion> dunno ...
<mjg59> If you want notifications for file alterations over nfs, you need fam
<Kamion> I suppose getting gnome-vfs2 to explicitly use libgamin would work too, maybe, but I don't know enough for that
<mjg59> On both server and client
<ogra> yep, thats what i remember ... there was a reason for fam in main ...
<Kamion> fam isn't in main
<Kamion> it hasn't been in main since warty
<ogra> oh
<mjg59> Oh, maybe I can just get away with volumeid
<ogra> the i remember wrong i guess ...
<Kamion> no symbol differences between libfam.so.0 and libgamin-1.so.0
<Kamion> I'll wait until seb128 is around and ask him, I guess
<Kamion> anyone doing l-r-m for -5?
<fabbione> Kamion: gamin and fam exports the exact same API/ABI
<Kamion> yeah
<fabbione> only the underneath code is different
<fabbione> i am 100% sure about it
<Kamion> well, I've filed a bug, seb128 can look when he's back
<Kamion> (l-r-m> I just realised it's blocking d-i)
<Kamion> oh well, sucking down the source package ...
<fabbione> iirc l-r-m only needs one change in the debian/rules for the ABI
<Kamion> nod
<fabbione> i didn't touch that stuff in ages tho
<fabbione> there are some scary things like control.stub control.in and control
<Laser_away> hmm, these Debian .pdiffs seem to make update'ing significantly longer if you have updated for a while
<Kamion> ok, l-r-m source uploaded
* Kamion -> WEEKEND DAMNIT
<HiddenWolf> Kamion, so get offline, like sensible people do
<HiddenWolf> Kamion, check out the sun, you know
<AlinuxOS> mjg59, hello
<AlinuxOS> mjg59, ping (can I disturb you in private?)
<doko> hmm, BenC did wake up sooner than I thought ...
<doko> ogra, infinity, Kamion: 27227 is reverted for the next upload, will wait for the new linux-kernel-headers first
<ogra> doko, that means before the CD ?
<doko> well, Mithrandir is not online, we're technically frozen ... so maybe Kamion could give an opinion ...
<BenC> is there a quick fix for the missing "fixed fonts" x problem?
<sladen> BenC: for breezy->dapper it was just the case of a symlink;  the same should probably work
<sladen> BenC: I think it's just down to the fonts landing in a different location 
<ogra> BenC, run mkfontdir in /usr/share/fonts/X11/misc/
<ogra> sladen, nope
<ogra> its a missing font.dir file 
<sladen> ogra: ooh, even simpler.
<BenC> ogra: yay, that worked...thanks
<ogra> update-font-dir ignores the new paths
<BenC> time to switch to X
<doko> hmm, that was short ...
<doko> BenC: does the linux-source upload include the /usr/include/{ppc64,powerpc64}-linux-gnu directories?
<Kamion> doko: go ahead if that's the only change
<BenC> doko: no, for ppc there is only asm/
<BenC> since it's all the same directory, that's the way hdrinstall creates it
<doko> BenC: so there's nothing installed in /usr/include/{ppc64,powerpc64}-linux-gnu ? ok.
<doko> and on ia64 and hppa?
<BenC> the only arches that have multiple asm is x86_64, i386 and sparc
<doko> BenC: and sparc includes all headers this time?
<BenC> yeah
<doko> cool
<BenC> hdrinstall actually uses the stub asm files like sparc used to, where asm/foo.h will include asm-sparc/foo.h or asm-sparc64/foo.h depending on a compiler define
<BenC> same for x86_64/i386
<BenC> it builds the files like that and i just copy {asm*,linux} to get everything needed
<doko> Kamion: there are other changes, I'll test-build the compiler on sparc, ppc64 and amd64 first.
<BenC> 4 arches building, and no failure yet, so I'm hopeful this will be good :)
<doko> BenC: not for now, but I would like to see lkh still built as a separate source package, so I don't have a kernel dependency when bootstrapping the toolchain. would that be doable?
<BenC> doko: if we split the source, then we should have stuck with the lkh package we had, but I'm not opposed to something build-dep'ing on linux-source-2.6.17 .deb and using that to create it
<BenC> it's easy to do something like "make -C /usr/src/linux-source-2.6.17 O=build-tmp/ ...", which is how I'm creating the stuff now (you could rip my make rules for linux-kernel-headers and use them standalone)
<doko> BenC: ok. not for now, just in the case we want to rebuild the archive with a clean/new toolchain
<doko> I thought that the current lkh packages were built not directly from the linux-source package, but were modified
<ThunderStruck> BenC: i opened that kernel panic bug up cause its happening on 2.6.17-5 but following the instructions you gave on it worked again ;) ty
<ThunderStruck> bug 52416
<Ubugtu> Malone bug 52416 in kernel-package "Kernel panic on startup" [Untriaged,In progress]  http://launchpad.net/bugs/52416
<BenC> Thunder: ok, thanks
<mdz> ubuntu-desktop ought to be installable on amd64 again after this publisher run
<mdz> working on powerpc now
<Fjodor> Has anything been changed in update-grub lately? It seems to disregard my defaultopts and set it back to quiet and splash. Has a report been filed about that?
<mdz> Fjodor: make sure you've read the comments in the file
<mdz> bug 21412
<Ubugtu> Malone bug 21412 in grub "Default update-grub behaviour is not intuitive" [Medium,Confirmed]  http://launchpad.net/bugs/21412
<Fjodor> Hmmm, this time no foul. Could it be related to the fact that I build edgy kernel packages? As the comments say, I edit #defoptions, which should stay the same, and be applied to all default entries
<Fjodor> So, what I gather from the bug reports is, that most (me at first too) edit the entries directly. I don't (anymore)
<Fjodor> Anyway, I'll report back, when  my next kernel build is done and installed, since the problem didn't arise on a random update-grub with no new kernels installed. Thanks so far
<Fjodor> Hmmm, seems like the problem disappeared again. How about that, huh. But thanks for your help
<danny> hello how to find the maintainer of a package if the one referenced is the wrong person e.g. the original debian developer
<Riddell> danny: we don't have maintainers, the changelog is a good indication of people with experience
<danny> where i find the changelog ?
<sladen> danny: debian/changelog in the package  or   http://changelogs.ubuntu.com/
<sladen> did the linux-headers issue get fixed, and if so what's the best way to force a rebuild of a package so that it doesn't FTBFS now?
<sladen> upload a   ...build1 ?
<ogra> ask a ubuntu-archive admin to give it back ?
<Riddell> sladen: ping keybuk or infinity, or upload build1 if they're not around and you can't wait until monday
<ogra> (if it doesnt get retried automatically anyway, LP has fancy new features there iirc)
<danny> well the chanlogs also reference allways the debian maintainer and reflect also the new versions which seem not availible through apt
<sladen> danny: what package are you looking at?
<danny> grsync
<ogra> thats only maintined in debian ... its not been touched by any ubuntu deveoper
<ogra> *developer
<danny> well but it is in an ubutu repository and only with an old version
<ogra> 0.4.3-2 is the latest we have
<crimsun> new version will be synced in. We've been blocked on kernel+libc+lkh issues, so I wouldn't hold my breath for the new version to be available in Edgy quite yet.
<ogra> https://launchpad.net/distros/ubuntu/+source/grsync shows that it isnt built yet
<ogra> oh, no, i'm wrong it is
<danny> I see only 0.1.2
<ogra> https://launchpad.net/+builds/+build/225389
<ogra> dapper has only 0.1.x
<danny> is there any problem updating this?
<ogra> which the above url tells you 
<ogra> well, we usually dont upgrade packages in a release without a very hard reason ... (i.e., the current versin wipes your HD)
<ogra> but you can ask the backports team 
<crimsun> file a bug on the source package, subscribe ubuntu-backports
<ogra> https://lists.ubuntu.com/mailman/listinfo/ubuntu-backports
<ogra> or mail them ;)
<danny> well if dapper has support for the next 5 years, i don't understand why not the repository is constantly updated... this is what i would expect
<crimsun> LTS != constantly updated.
<danny> and what does the term backport mean? I would expect features which hae exist in older ubuntu versions to be backported to the new... what has this to do with normal software matureing processes?
<BenC> danny: You can't keep something stable by constantly updating it
<ogra> danny, backporting == building a package from a newer version for an older system
<BenC> danny: our normal development cycle is for people that want "new features", LTS is for people that want a stable and consistent platform for a long term commitment
<danny> hmm... doesn't 0.4.3 sound better than 0.1.3?
<BenC> we don't have "sounds good" as a reason in our bug reporting system
<danny> when I install grsync 0.1.3 and want to have 0.4.3 - can i yust try to compile myself (and overwirting the 0.1.3 files with make install)?
<BenC> you could get the 0.4.3 package and recompile on your system
<BenC> that's basically a backport
<ogra> i'd rather take the source package from edgy and build that
<danny> how to do that?
<crimsun> #ubuntu-motu can help with that
<BenC> there's lots of docs in ubuntu and debian on how to rebuild packages
<danny> what is this motu channel for?
<crimsun> packaging software in universe and multiverse components
<danny> ok... thanks for now
<JanC> danny: there is a manual for (re)building packages on help.ubuntu.com
<Kamion> http://librarian.launchpad.net/3426551/buildlog_ubuntu-edgy-i386.linux-restricted-modules-2.6.17_2.6.17.1-6_FAILEDTOBUILD.txt.gz <-- gar
<Kamion> similarly amd64
<BenC> where did that build come from?
* BenC didn't upload it
<crimsun> Kamion did
<BenC> I'll check it out
<BenC> oh wow, that's an ugly build
<Kamion> I did, but it was just s/4/5/ on the abinum
<BenC> ok, I'll do a build here and see what's up
<Kamion> /build/buildd/linux-restricted-modules-2.6.17-2.6.17.1/debian/build/2.6.17-5-386/madwifi/ath_hal/../include/compat.h:71:22: error: asm/page.h: No such file or directory
<Kamion> is the first failure
<Kamion> I also believe that's the largest number of compiler errors I've ever seen on a single file
<crimsun> wow.
<sladen> ...all from just   #include <linux/module.h>
<Kamion> ogra: re kino, it builds fine if you just stick extern "C" { ... } around the KinoCommon *common declaration in src/kino_common.h; I don't know if that's the best fix and it should certainly go upstream for comments, but that fix should be workable for now
<Kamion> (oh, you should test that it works too after that - I haven't)
<ogra> Kamion, ok, will fix it if i arrive in the old house ... i'll do my weekly drive through the country soon ...
<Kamion> mdz: damn, if you'd said, I'm pretty sure I could have resurrected gnome-applets on powerpc
<Kamion> unfortunately I didn't notice until after your upload, so never mind now
<Kamion> it's sitting in /srv/launchpad.net/builddmaster/accepted/20060713-160720-227962-183933/
<doko> Kamion: please requeue gcc-3.4 on powerpc and sparc, xulrunner on amd64
<sladen> Kamion: and wxwidgets2.6 on all
<mdz> Kamion: that's odd; locate on drescher didn't find it
#ubuntu-devel 2006-07-16
<mdz> Kamion: argh, it's using GNU locate, not slocate. that's why it didn't find it
<Kamion> doko,sladen: I can't, I'm not in launchpad-buildd-admins
<doko> Kamion: oops, ok. infinity, Keybuk: ^^^
<doko> Kamion: gcc-4.1: powerpc and i386 bootstraps did succeed, sparc seems ok (now in the build of the runtime libs), I've put the debdiff on chinstrap:~doko/4.1.diff
<Kamion> doko: debian/lib32gcc1.preinst is normally generated, I assume?
<doko> Kamion: yes
<Kamion> doko: yes, ok if the bootstrap tests finish
<doko> Kamion: ok, I assume that will be Sunday morning
<Kamion> should be ok ...
<mdz> Kamion: I triggered new i386 and amd64 livefses; I didn't check if i386 succeeded but built i386 and amd64 desktop CDs anyway
<BenC> yay. 5 successful builds
<mdz> my mysterious I/O errors went away with the latest live CD as well
<BenC> Kamion: Working on lrm right now
<BenC> would have had it done earlier, except I've been hunting rabid foxes all day
<TheMuso> 
<Tmob> mjg59, ping
<fabbione> ubuntulog is going down for maintainance
<fabbione> it will take approx one hour or so
* Starting logfile irclogs/ubuntu-devel.log
* Starting logfile irclogs/ubuntu-devel.log
* #ubuntu-devel  [freenode-info]  please register your nickname...don't forget to auto-identify! http://freenode.net/faq.shtml#nicksetup
* Starting logfile irclogs/ubuntu-devel.log
(imbrandon/#ubuntu-devel) wb ubuntulog 
<fabbione> Seveas: yeah as i imagined.. 
<fabbione> server confuses /join as floods
<fabbione> anyway
<fabbione> solved
<Seveas> fabbione, technically a flood of /joins is also a flood ;)
<fabbione> Seveas: yes i don't completely disagree, but once you grant a client the option to join more than 20 chans (or whatever is the watermark) it doesn't really make sense to detect /join floods from it ;)
<Seveas> sounds reasonable
<fabbione> Seveas: specially because the clients did have a certain amount checks before this options is granted
<Seveas> i'll still poke freenode staff
<fabbione> well just raise it a nice-to-have
<fabbione> it's workaroundable.. just really annoying
* fabbione goes back to his rack upgrade
<Seveas> fabbione: 
<Seveas> <BearPerson> "excess flood" is a technical thing independent of join or anything floods 8)
<Seveas> <BearPerson> what triggers excess flood is having more than 1500 bytes of commands in the server's recvQ, unprocessed
<Seveas> <BearPerson> it doesn't matter if they are "JOIN" commands or "FUBAR" ;P
<fabbione> Seveas: whatever.. that thing doesn't change the problem :)
<Seveas> fabbione, pm (didn't want to flood the channel)
<doko> hmm, can anybody tell me, what b-d dejagnu is missing?
<jdub> hrm
<jdub> what's a good way to version cvs/svn builds?
<jdub> based on a debian version, upgraded to current svn
<jdub> 0.11.5-9 -> ?
<StevenK> 0.11.5+20060716.svn-1
<StevenK> Or some such.
<StevenK> Honestly, most version numbers based on dates look like arse anyway.
<jdub> right, so 0.11.6 would replace it, but not 0.11.5-10
* StevenK checks
<StevenK> jdub: Correct.
<jdub> thanks
<tseng> jdub: you could also use the svn revision number
<jdub> ah, good call
<jdub> i'm doing this a bit q'n'd though
<jdub> jsut doing a new build of mpd
<jdub> so i can have icecast support
<jdub> i think this will improve my music experience
<tseng> brb, Xgl is killing me
* jdub mourns tseng 
<tseng> jdub: i have a geforce 4 ti, hardly a shit card
<tseng> jdub: and it plays movies under xgl at 1/10th speed
<tseng> i dont see how people use this all the time
<mjg59> tseng: And you've enabled the Xv acceleration
<tseng> mjg59: never heard of.
<mjg59> Oh
<tseng> is that in xgl, or the nvidia driver
<mjg59> Xgl -accel xv:pbuffer
<mjg59> Or somehting like htat
<jdub> mjg59: what's the intel mac mini support like?
<bluefoxicy> yay normal operation again.  *clicks update manager*
<bluefoxicy> the other day I was sitting here typing on irc and update manager suddenly popped itself up in my face like HI2U INSTALL THESE
<mjg59> jdub: Acceptable, though slightly fiddly to install
<robertj> has anyone with an ear to the ground re: firefox heard if there are any plans to allow Firefox passwords to be stored on the gnome keyring?
<floam> does anyone know why there doesn't seem to be an initrd in edgy's kernel? are they not using it anymore? (that wouldn't make much sense to me)
<tseng> initrd.img-2.6.17-4-386 < like this one?
<floam> tseng: yeah, like that one. what the heck.
<floam> I've got a vmlinuz-2.6.17-4-k7 yet no matching initrd, must be an issue in the -k7 build or maybe they split the initrd into another package
<tseng> its built at install time
<tseng> dpkg --reconfigure it?
<floam> I reinstalled it a few times. maybe it's failing somehow.
<floam> and I assume you meant dpkg-reconfigure 
<floam> which seems to work /way/ too quickly, it must be failing silently
<floam> I'll play with it for a couple hours and report a bug if I can figure it out
<wasabi_> Anybody considered packaging telepathy yet?
<jdub> wasabi_: i believe dholbach was doing it
<wasabi_> k
<wasabi_> Thanks
<sladen> Robot101: any chance you could just package telepathy directly for Ubuntu rather than having wasabi_/dholbach do it?
<sladen> Robot101: since it's your dev platform, it might make sense </excuse> ;-)
<jdub> takes time away from hacking on it
<wasabi_> dholbach doing farsight too?
<wasabi_> I'm doing the gst plugins right now, because I want to play with them.
#ubuntu-devel 2007-07-09
<Nergar> hello
<Nergar> where can i file a complaint against an IRC op?
<minghua> Nergar: maybe #ubuntu-ops
<Nergar> thnx
<hikenboot> can anyone give me an example of apt-get remove used in a for loop where the input is a kicklist from a file?
<Fujitsu> hikenboot: #ubuntu for support, thanks.
<therealnanotube> could someone please tell me about ubuntu package versioning conventions. e.g, if i have something with Version: "4.19-1ubuntu2.1", i understand that 4.19 is the actual software version, but what's the 1ubuntu2.1 stand for?
<therealnanotube> i want to package my software into an ubuntu deb, and i want to know how the versioning stuff goes...
<therealnanotube> i hope this is a good place to ask... :)
<ion_> Try #ubuntu-motu
<persia> therealnanotube: 1 is the debian revision, and 2.1 is the ubuntu revision.  This probably means Ubuntu made two uploads after the last Debian upload, and then there was a security release (or the like).  #ubuntu-motu may be a better place to ask about packaging.
<therealnanotube> persia: ion_: thanks, i'll try motu :)
<khermans> "E: Couldn't configure pre-depend coreutils for debianutils, probably a dependency cycle."
<khermans> http://lists.debian.org/debian-devel/2006/09/msg00135.html
* Hobbsee waves
<Hobbsee> right, aptitude and debtags uploaded
* ion_ sinewaves
<Hobbsee> :)
<RAOF> Hobbsee: Yay!
<Hobbsee> waiting on python-apt to checkout, will upload that too, then will upload adept and synaptic
<Hobbsee> oh grrr.  apt never got built.
<Hobbsee> therefore, those two uploads are worthless.
<Hobbsee> but one got rejected anyway
* mode/#ubuntu-devel [+o mneptok]  by ChanServ
* mode/#ubuntu-devel [+ct]  by mneptok
* mode/#ubuntu-devel [-o mneptok]  by mneptok
<superm1> Hi guys, anyone available for sponsorship for a package from main?
<Hobbsee> depends what it is
<superm1> Hobbsee, lirc
<Hobbsee> mneptok: why +t?
<superm1> Hobbsee, bug: #124842
* mode/#ubuntu-devel [+o Hobbsee]  by ChanServ
* mode/#ubuntu-devel [-t]  by Hobbsee
* mode/#ubuntu-devel [-o Hobbsee]  by ChanServ
<Hobbsee> superm1: i'd prefer not to
<superm1> Hobbsee, why is that?
<Hobbsee> because i'm doing various things here already, and that looks big
<superm1> oh okay :)
<superm1> getting all our apt toys fixed is more important anyhow :P
<Hobbsee> superm1: well, yeah.  i'd like to be able to fix that, but i cant.
<superm1> Hobbsee, what happened?
<Hobbsee> superm1: before, or now?
<Hobbsee> superm1: now, i'm waiting for cjwatson and co to wake up
<superm1> ah okay
<Hobbsee> so they can fix soyuz up with a bit more string
<Hobbsee> superm1: the problem now is that soyuz is accepting the sources, but isnt actually allocating the binaries to be built
<superm1> why do things like this where soyuz gets a little quirky happen?
<Hobbsee> well, when soyuz breaks...the stuff that it does also breaks...
<Hobbsee> i dont understand your question, beyond that
<Fujitsu> superm1: Because Soyuz is nice and buggy and likes to have fits over weekends, I guess.
<superm1> of course :)
<Fujitsu> And doesn't seem to be able to restart the build queuer without manual intervention.
* TheMuso hates to imagine how big the build queue is.
<Fujitsu> TheMuso: It's empty at the moment :P
<Fujitsu> That's the whole problem.
<TheMuso> Fujitsu: ah.
* persia wonders about the potential build queue once it starts being fed again
<Hobbsee> nwo that will be evil
<Fujitsu> Whatever it is that's meant to create builds from published sources and stick them in the queue has got some issues.
<Fujitsu> At least it isn't eating uploads.
<persia> Fujitsu: That may not be a good thing.  It's too easy to upload something that build-depends on something else that changed with a significant build/release delay.
<Hobbsee> persia: well, of course soyuz breaking is not good...
<Hobbsee> we're still a week and a half away from our next tribe, anyway
* Hobbsee isnt concerned yet
* Fujitsu is concerned that there are so many regressions after each release.
<StevenK> Ubuntu, Launchpad, or both?
<Fujitsu> (as well as the all too common complete failures over a weekend)
<Fujitsu> Launchpad
* Hobbsee is wondering why it died now, though
<Fujitsu> Well, cjwatson killed cron.daily last night because it had been hanging for a couple of hours.
<Fujitsu> It seemed the build queuer came down with that, and never came back up.
<Fujitsu> *smees.
<Fujitsu> Bah.
<Fujitsu> **seems
<Mithrandir> Hobbsee: hm, what is b0rken today?
<Hobbsee> Mithrandir: soyuz.  apt source has been published, but the binaries havent been built
<Hobbsee> Mithrandir: good morning, btw :)
<Hobbsee> Mithrandir: how is london?
<Mithrandir> morning
<Mithrandir> nice and warm
<StevenK> The binaries haven't even been registered yet.
<Mithrandir> I went for a run which ended up being a bit short.
<Hobbsee> warm.  hmmm.
<Fujitsu> Mithrandir: Builds aren't registering for published sources since cjwatson killed cron.daily 24 hours ago.
<Mithrandir> StevenK: give me the name of a source which should build?
<StevenK> Mithrandir: kwave
<Hobbsee> early run, seeing as current time there is 7am
<Hobbsee> Mithrandir: apt!
<StevenK> Hobbsee: Beat you. :-P
* Hobbsee beats StevenK 
<Fujitsu> Take your pick from DONE in the last 24 hours.
<StevenK> Ouch! That tickles.
<Hobbsee> StevenK: dont enjoy it too much :P
<Mithrandir> debugging python with strace++
<StevenK> Oh twitch. I've done that more often than I care to recall.
<StevenK> Perl is a little more insane, given it's internals.
<Sp4rKy> hi
<Sp4rKy> is there someone to review my initramfs-tools update ?
<Sp4rKy> s/update/merge
<TheMuso> Sp4rKy: Is the main sponsors team subscribed to the bug?
<Sp4rKy> TheMuso: i've not yet open the bug
<Sp4rKy> as i would someine check debdiff before
<TheMuso> Sp4rKy: It might be an idea.
<TheMuso> Attach the debdiff to the bug, and subscribe ubuntu-main-sponsors.
<Sp4rKy> k
<Sp4rKy> Bug #124855
<ubotu> Launchpad bug 124855 in initrd-tools "please merge initramfs-tools from Debian (unstable)" [Undecided,New]  https://launchpad.net/bugs/124855
<Hobbsee> Mithrandir: any luck?
<persia> Sp4rKy: You may wish to set the bug to be against the initramfs-tools package, so as to get the attention of the appropriate parties.
<Sp4rKy> oh yes
<Sp4rKy> done :)
<Mithrandir> Hobbsee: not really. :-/
<Hobbsee> Mithrandir: :(
<Mithrandir> but I need some fod
<Mithrandir> food
<Hobbsee> mmm...food.
* Hobbsee ponders breakfast
<TheMuso> Hobbsee: lol
* Fujitsu had breakfast some 10 hours ago.
* StevenK didn't have breakfast at all today
<Hobbsee> oh yay, now apt says "needs building"
<Fujitsu> Yay, thanks Mithrandir.
<Hobbsee> uh, what?
<Hobbsee> why are people subscribing ubuntu-release to bugs?
<Hobbsee> hi cprov
<cprov> Hobbsee: morning.
* persia thinks that bug 58410 might need a per-group configuration flag
<Fujitsu> bug #58410
<Fujitsu> !ping
<persia> Fujitsu: It's about limitations to "subscribe someone else".
<Fujitsu> Ah, right.
<Fujitsu> That's the only way to go about it, IMO.
<persia> Fujitsu: Depends.  It breaks current U-U-S, U-M-S, and U-A workflow to completely restrict, but not all groups are like that.
<Hobbsee> i was about to say that
<Fujitsu> It needs to be an option linux restricted/moderated/open/ondemand is now.
* persia notes that if ubotu were here, it would all have already been said :)
<Fujitsu> Uh, s/linux/like
* Hobbsee glares at the apt build
<persia> Fujitsu: If you've got a plan - comment on the bug :)
* Hobbsee notes the usefulness of being able to build on multiple arches
<Hobbsee> works on i386,w hich is what i tested on.  dies on ppc, sparc
<Fujitsu> Are sparky and intrepid still around?
<Fujitsu> And can someone look at the build logs for libfilesys-diskspace-perl and work out why it fails on the buildds but nowhere else?
* Hobbsee watches it fail on amd64 too
* Hobbsee grumbles at telemarketers
<Fujitsu> Heh. That's all telemarketers are good for.
<Hobbsee> actually, wasnt a proper telemarketer
<Hobbsee> seeing as they're on the do not call list
<siretart> Hobbsee: you uploaded aptitude earlier today? I hope I didn't confuse you with mine ;
<siretart> ;)
<Hobbsee> siretart: my upload for that is waasted
<Hobbsee> it'll need another rebuild anyway
<siretart> Hobbsee: oh :(
<Hobbsee> Mithrandir: can you giveback apt on all arches that didnt build (ie, !i386) please?  this just built on amd64 too
<Hobbsee> siretart: did you upload aptitude before or after me?
<siretart> Hobbsee: I uploaded it about 14hours ago
<Hobbsee> siretart: right.  so mine was way after
<Hobbsee> siretart: i rebuilt whatever was in the archive, so...
<siretart> you's was 14h ago as well: https://launchpad.net/ubuntu/+source/apt
<Hobbsee> oh.  that's why it failed!
<Hobbsee> i wondered why i got an error about it, but then discovered that apt hadnt built anyway
<Hobbsee> siretart: it needs to be rebuilt on the new apt nayway, so...
<siretart> Hobbsee: I'll let you handle this then ;)
<Hobbsee> siretart: was yours a rebuild too?
<siretart> Hobbsee: yes, rebuild only
<Hobbsee> right, cool.  ok
* Hobbsee is going to rebiuld the world when apt works
<siretart> I wanted to dist-upgrade and noticed that aptitude was held back (for about 2 days)
<Fujitsu> Hobbsee: That's a fairly large world.
<siretart> indeed
<Hobbsee> true
<StevenK> Mis-spelt world, too
* StevenK ducks
* Hobbsee throws Fujitsu at StevenK 
<StevenK> Eww, Melbourne germs!
<Fujitsu> Yay, other Ubuntuers.
<Hobbsee> siretart: so is anything else depending on libapt
<siretart> Hobbsee: speaking of apt, any chance we get ept-cache soon?
<StevenK> apt != libept
<siretart> Hobbsee: from the changelog I see that adept is blocking the new libept version
<siretart> StevenK: I know
<siretart> StevenK: I've seen demonstration about ept-cache at debconf. I very much liked ept-cache
<Hobbsee> siretart: no idea, ask manchicken
<TheMuso> 0/c
<TheMuso> ugh
<TheMuso> ugh
<StevenK> Geez. Give i386 another hour and it'll be saying, "What backlog?"
<dholbach> good morning
<simira> morning
<simira> dholbach: you are going to guadec, right? When do you go to Birmingham?
<dholbach> simira: nope
<dholbach> simira: won't go there - mvo and seb128 are going to
<simira> oh :(
<dholbach> I'll be at the sprint now and ubuntulive and after that on holidays
<dholbach> so that's going to be enough time away from my desk at home
<simira> sounds nice :)
<dholbach> sorry, I would have liked to go guadec too - maybe next one :)
<simira> I'm not really going there - only to Birmingham :p
<simira> for the weekend
<dholbach> right - have a good time there then :)
<simira> I will
<simira> dropping by London on Friday as well, btw
<Keybuk> evand:
<Keybuk> http://forums.opencompositing.org/viewtopic.php?f=40&t=522
<sabdfl-afk> howdy all
<calc> sabdfl: hello :)
<sabdfl> upgrades on my laptop are currently wedged on somthing to do with libcurl3-gnutls
<sabdfl> is that a known issue, or something i should help debug specially?
<calc> sabdfl: openoffice probably, doko i believe uploaded a new version of it yesterday
<stgraber> sabdfl: OpenOffice + libcurl3-gnutls work here on amd64, but IIRC build failed on i386
<sabdfl> ah, that could be it
<StevenK> calc: Which failed on i386, if I recall.
<evand> thanks Keybuk, I'll give that a try
<stgraber> failed on sparc, powerpc and i386, succeeded on amd64 and ia64
<calc> StevenK: lovely
<StevenK> sabdfl: openoffice.org is the last cog in the chain of this libcurl4{,-{openssl,gnutls} mess.
<StevenK> calc: Enjoy. :-P
<calc> StevenK: openoffice fails in strange and mysterious ways depending on the phase of the moon ;)
<StevenK> calc: I'm well aware of that, I've read enough of the failures. :-)
<stgraber> 27 hours for a fail :)
<doko> calc, yes the OOo version should have fixed that; didn't see the build failure yet. it's not obvious with parallel builds :-/
<StevenK> fabbione: Is London hot enough for you? :-P
* simira could use some warmer outside temperatures...
<fabbione> StevenK: no women are hot enough for an iTalian :P
<simira> how is London?
<fabbione> warm
<fabbione> but not hot
<StevenK> fabbione: Could you repeat that, I have your wife on the other line ...
<stgraber> fabbione: I updated the ISO Testing Tracker yesterday, now we have a single DB with all test results (even Feisty), here : https://isotesting.stgraber.org/isotesting/archive/Ubuntu (for Ubuntu)
<fabbione> stgraber: great thanks but what I got was enough
<fabbione> StevenK: sure.. i tell her all the time :)
* StevenK chuckles.
<calc> stgraber: our i386 buildd takes 27+ hr to build ooo?
<StevenK> Depends if palmer grabbed it or not.
<StevenK> Given that palmer is twice as fast as rothera.
<calc> takes about 4hr on my desktop machine, maybe buildds need an upgrade ;)
<StevenK> Hold on, don't you use ccache?
<calc> get some of those nice shiny Q6600 chips (~ 250 USD) at the end of the year for amd64 and i386 buildd
<calc> StevenK: yea, but iirc 3-4hr is for uncached build
<calc> StevenK: with hot ccache i can do it in ~ 30m from what i recall
<StevenK> I recall a friend of mine porting OO.o to AIX. The machine they gave him access too would build it in about 2 weeks...
<calc> actually iirc 3-4hr is for uncached build without nogsi, i think was able to build with nogsi uncached in about 1.5-2hr
<calc> i have a C2D E6300
<calc> i think it may already be discontinued now, but was ~ $160 USD
<ScottK> keescook: Please let me know if there is anything else that needs to be done on my end for the gnupg updates.  The updated debdiff (geser figured out my problem) is in Bug #76983.
<nysosym> hi there
<dholbach> nixternal: what do you think about setting the maintainer address of tapioca-qt and decibel to kubuntu-devel@lists.ubuntu.com or something?
<nysosym> does gutsy use the madwifi driver from svn?
<Riddell> dholbach: isn't our policy to set everything to -motu ?
<dholbach> Riddell: no, we set ubuntu-desktop@lists.ubuntu.com for a couple of packages too
<dholbach> ubuntu-motu@ and ubuntu-devel-discuss@ are a fallback for everything else
<Riddell> dholbach: it seems like a good idea, but then we have lots of kde packages that might be best set to kubuntu-devel
<dholbach> Riddell: also... I meant Maintainer + XSBC-Original-Maintainer
<beuno> nysosym: the versioning doesn't suggest it does, no, porbably a sync from debian
<dholbach> I'm happy if nixternal and other Kubuntu folks take care of it,
<nysosym> beuno, thx, hmm ok, i hope this driver will used, because my macbook doesn't have wifi out of the box and ndiswrapper is very crappy
<keescook> ScottK: cool, thanks!  I'll get to it :)
<ScottK> keescook: Great.  He added one more bug to the mix.  I've no opinion on that.
<Hobbsee> hi simira
<KnowledgEngineer> hellp
<KnowledgEngineer> hello
<KnowledgEngineer> this is the good channel for ask everything about programming under ubuntu?
<ion_> Please read the topic.
<KnowledgEngineer> there is a channel good for me?
<ion_> Programming isnt really different under Ubuntu or any other similar environment, so you probably should look for generic channels about the thing youre programming with.
<persia> KnowledgEngineer: For proper development, you'll get better support from a channel dedicated to your programming language or target libraries, rather than one for the distribution you'll be using.  For packaging, #ubuntu-motu might help.
<KnowledgEngineer> my problem is related to lisp and asdf-install
<KnowledgEngineer> asdf-install is a program for download and install lisp extensions
<KnowledgEngineer> example graphic library .....
<KnowledgEngineer> on lisp channel nobody helped me
<evand> mvo: http://www.vmware.com/community/thread.jspa?messageID=677688
<evand> and the any-any 110 update
<shawarma> When adding an argument at the end of a function's prototype (in C), is a SONAME bump required. It seems to work, but is that just a coincidence?
<shawarma> "is a SONAME bump required" was a question, not a statement.
<infinity> Addind an argument at the end of a prototype doesn't break backward compat.
<shawarma> infinity: Great. Thanks.
<infinity> From the POV of Debian shlibs, though, you need to bump the shlibdeps.
<infinity> Cause anything using the new interface won't work with the old lib, obviously.
<seb128> infinity: you sort of break compatibility because programs that used to build fine will not
<infinity> Not on the planet I live on...
<ogra> planet ubuntu ?
<ogra> or pizza planet ?
<infinity> Well, assuming this new argument is optional.
<seb128> infinity: how do you define an optional argument?
<infinity> If it's mandatary then, yes, you broke builds.
<infinity> It's also possible that I'm half asleep and thinking in the wrong language. :P
<broonie> infinity: You can't do optional arguments in C except via varargs.
<infinity> See?
<broonie> (well, and struct sizing tricks too)
<infinity> Doesn't help that I've just been staring at apt source (thanks, mvo), which could be causing temporary insanity.
<shawarma> seb128: You you put a #define API_VERSION to the header files, you can check that.
<Sp4rKy> is there some main sponsor ?
<persia> Sp4rKy: Best to use the ubuntu-main-sponsors queue, rather than hunting people.
<Sp4rKy> persia: i already subscribe them :)
<Sp4rKy> subscribed*
<nixternal> dholbach: that is fine with me
<dholbach> nixternal: so will you do that?
<Hobbsee> dholbach@
<Hobbsee> !
<dholbach> hey Hobbsee!
<nixternal> Hobbsee@
<nixternal> !
<Hobbsee> :)
<nixternal> dholbach: sure
<Hobbsee> !nixternal
<ubotu> Oh no!  The pointy-clicky Vista lover has arrived!  He's rumoured to be giving out free money, too!
<nixternal> I will put.....omg no you didn't!
<nixternal> ;)
<dholbach> nixternal: rock on
<Keybuk> mvo: compiz enhancement request (file appropriately)
<Keybuk> if a window grabs the keyboard, compiz should fade out all other windows and the background to a dull grey
* Hobbsee waves to Keybuk 
<Chipzz> is there a way of, when filing a bug, indicating that the bug applies to the development release, and if possible should be triaged sooner or not at all?
<Chipzz> I have received first replies on bugs that are over 6 months or a year old
<Chipzz> at which point the bug doesn't matter anymore
<Hobbsee> Chipzz: you can either mention it in the bug, or make a gutsy task for it.  it really depends if people are actually looking at the bugs, though
<Hobbsee> as in, it's assumed that all bugs are for the development release
<Chipzz> uhu
<Chipzz> I'm not saying those bugs were important
<Chipzz> because they were not
<Chipzz> quite the contrary, really small issues (pollish if you want) that could be fixed really fast
<Hobbsee> Chipzz: the problem there is in not enough people triaging bugs.  not that "the bugs didnt contain 'this is in the development version' so didnt get looked at"
<Chipzz> uhu
<Chipzz> but nagging someone on irc about it would also not be correct I guess
<Chipzz> :P
<Hobbsee> true.  but then, the right person, especially if you've provided a patch, is helpful
<Hobbsee> and making sure that if the package is directly from debian, you file the bug in debian too, and link it.
<Hobbsee> it really depends
<simira> Hobbsee: isn't it late night for you now?
<Hobbsee> simira: it's about 1am.  not that bad.
<Hobbsee> :)
<Mithrandir> she's trying to move .au closer to europe by staying up all night.
<Hobbsee> simira: i tend to live european days, i think
<Hobbsee> exactly
<simira> Hobbsee: oh, so no work tomorrow morning? ;)
<Hobbsee> simira: no.  not to my knowledge.  although they tried to call me twice tonight
<Hobbsee> simira: i've already had my roster completely changed once this week
<StevenK> Oh damn, I didn't think it was this early.
<simira> early? Not really.
<simira> didn't you guys just have lunch?
<StevenK> 1 *am*, not pm
<Hobbsee> simira: actually...where lunch == second meal of the day...yes i did.
<simira> uhm, StevenK, I thought you were in London
<Hobbsee> simira: wrong IP for that
<StevenK> simira: Oh, right. It seems I wasn't invited. :-)
<simira> Hobbsee: uh, what does an ip on irssi say anyway? Check Tollef's :p
<Hobbsee> simira: excluding those who are ssh'ing out of london, into their machines in their homes / their offices
<simira> Hobbsee: I mostly ssh from anywhere I go...
<Hobbsee> you are lucky enough to have a server to do that.
<Mithrandir> IPs are overrated anyway. :-P
<StevenK> Heh
<StevenK> I usually ssh home and screen in for IRC.
<StevenK> Except in cases where the link is dreadful for real-time traffic.
<Hobbsee> simira: i was thinking in the case of [01:05]  [Whois]  fabbione is i=fabbione@nat/canonical/x-670f3c1f0d7cb4c8 (Fabio Massimo Di Nitto)
<Hobbsee> simira: but yes, it doesnt cover those who ssh
<Hobbsee> simira: i'll just admit to being wrong, and go back into hiding.  that sound good?   :P
<infinity> Admitting to being wrong is a sign of weakness.  Just do what I do, and pretend you don't understand the language.
<zul> heh
<Hobbsee> infinity: heh
<Hobbsee> hiya pitti_!
<simira> hehe
<pitti> hey Hobbsee
<simira> Hobbsee: you might consider going to bed?
<simira> ;)
<simira> infinity: how's London?
<Hobbsee> simira: i might.  i'm more tempted to just hide from irc.
<infinity> simira: Same as always.  They didn't move the river or anything.
* StevenK has been considering going to bed for the last 30 minutes.
<Hobbsee> simira: or behind some other alias, indefinetly.
<simira> infinity: last time I heard, they expanded it?
<StevenK> infinity: What, they just aren't putting the effort in? :-P
<infinity> simira: Looks vaguely similar to me.
<infinity> simira: I'll admit to not being an expert on the width of rivers around the world...
<Hobbsee> infinity: get a longer tape measure, then.
<simira> infinity: I'd guess. But the place where the sprint is, is nice?
<alex-weej> does anyone know anything about spontaneous xorg crashes today? :E
<infinity> simira: The new offices are nice, yeah.
<simira> alex-weej: sounds like a real distro-sprint :D
<desrt> guadec guadec guadec
<alex-weej> it's happened to me three times today while browsing the web... absolutely stumped
<alex-weej> anyone know how i debug?
* desrt notes a high gnome presence
<Hobbsee> desrt: no guadec for you!  NOT YOURS!
<alex-weej> i haven't had an Xorg crash since i used Gentoo :P
<desrt> guadec for me.  no guadec for hobbsee.
<Hobbsee> desrt: oh well.  no one trying to break me then, if i'm not at guadec
<desrt> no akademy for hobbsee either
<desrt> sucks to live in .au, eh?
<desrt> alex-weej; guadec this year?
* Hobbsee wants to know who introduced the "everyone try to break hobbsee while she's at a conference" rule, and why.
* desrt has heard of no such rule
<alex-weej> desrt: hopefully, awaiting charity for accommodation
<Hobbsee> desrt: seems a fair few others had
<thom> this could be a somewhat fight-club esque situation...
<alex-weej> i have no laptop so it's going to be an interesting week hehe
* desrt will see alex-weej Mithrandir simira at guadec, but not Hobbsee 
<Hobbsee> thom: hm?
<Hobbsee> desrt: i'm sure you'll cope
<desrt> alex-weej; :)
<desrt> Hobbsee; i see it as a positive thing, really :)
* Hobbsee thinks simira should just come to au, instead
<Hobbsee> hah.  thanks a lot.  :P
<simira> desrt: I'm not going to guadec, I just pretend to
<desrt> oh.
<thom> Hobbsee: the first rule of Hobbsee-breaking is...
<desrt> thom; DON'T TALK ABOUT HOBBSEE BREAKING
<simira> desrt: but I might meet up with some poor volunteers for dinner and beer on saturday night. I leave sunday 2 pm
<Hobbsee> thom: is probably something to the effect of "go for the bits that break the easiest"
<alex-weej> GRR
<alex-weej> stuff keeps crashing, i think i have proper issues :(
<desrt> simira; drop by the conservatoire
<desrt> simira; it's always a fun crowd :p
* Hobbsee wonders if she can take in a large spade or something, for the next UDS>
<desrt> Hobbsee; just don't try and put it in your carryon bags
<simira> desrt: where is that? Pretty central anyway, I guess. And yes, I probably will.
<StevenK> Buy one there, much simpler
<Hobbsee> right, right.
<desrt> simira; it's the conference venue
<desrt> simira; very close to the train station
<simira> desrt: ah. Well, I might hang around until  my train leaves.
<simira> *sigh* no one wants to play with me :-/
<Hobbsee> simira: play what?
<desrt> simira; you just have to be in the right places
<simira> carcassonne
<desrt> nobody wants to play at the train station
<simira> I AM in the right place
<ogra> carcassonne ? oh envy
<desrt> no guadec for ogra
* ogra was twice there and once in narbonne ... its the most beautiful part of france :)
<Hobbsee> hiya ogra
<simira> ogra: the German game
<ogra> hey Hobbsee
<desrt> i guess we get seb, dh, mvo and maybe scott?
<simira> desrt: for guadec, yes
<ogra> desrt, dh is on holiday that time
<desrt> wow.  that's creepy.
<Keybuk> asac:
<Keybuk> Jul  9 16:22:28 wing-commander NetworkManager: <info>  starting...
<ogra> no, well deserved
<Keybuk> Jul  9 16:22:28 wing-commander NetworkManager: <info>  nm_netlink_monitor_event_handler :: dev: lo, ifi_flags: 65609, IFF_RUNNING: 64, IFF_VOLATILE: 199770
<desrt> "scott"
<Keybuk> Jul  9 16:22:28 wing-commander NetworkManager: <info>  nm_netlink_monitor_event_handler :: dev: eth0, ifi_flags: 4098, IFF_RUNNING: 64, IFF_VOLATILE: 199770
<desrt> *joins scott
<Keybuk> Jul  9 16:22:28 wing-commander NetworkManager: <info>  nm_netlink_monitor_event_handler :: dev: irda0, ifi_flags: 128, IFF_RUNNING: 64, IFF_VOLATILE: 199770
<Keybuk> Jul  9 16:22:28 wing-commander NetworkManager: <info>  nm_netlink_monitor_event_handler :: dev: eth1, ifi_flags: 4098, IFF_RUNNING: 64, IFF_VOLATILE: 199770
<seb128> ogra: he's not
<desrt> seb128; did you vendor patch that compositing fix yet? :p
<seb128> ogra: he just take a non travelling week before Ubuntulive
<seb128> desrt: what composite fix? ;)
<desrt> seb128; the one that landed upstream a few days ago :p
<seb128> desrt: did it get commited to git now?
<Keybuk> asac: in fact, let me grep and paste you the entire thing, there's a lot here
<seb128> desrt: do you have the git revision handy?
<desrt> no.  but it's recent.  i'll find it.
<seb128> thanks
<ogra> seb128, ah, i thought his vacation would extend to that as well...
<desrt> http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=commit;h=866f092ca0160a366add01b48ad03438926c4d16
<Keybuk> asac: http://people.ubuntu.com/~scott/syslog.nm
<StevenK> dholbach: Can you not get dh_iconcache to print "Warning: Please use dh_icons instead. dh_iconcache is going to go away." in a loop? sbuild will kill building processes that print the same thing over and over to prevent busy-loop spinning on the buildds. Worse, it gives the build to another buildd so they can do the same thing. BAD.
<seb128> desrt: thanks
<desrt> seb128; honestly, you can probably just wait
<dholbach> StevenK: hu?
<seb128> wait for what?
<desrt> next release, i guess?
<dholbach> StevenK: what happens? how does it happen? I didn't see that happening?
<desrt> unless that's not going in gutsy....
<seb128> desrt: right ...
<StevenK> dholbach: http://launchpadlibrarian.net/8340553/buildlog_ubuntu-gutsy-i386.kwave_0.7.7-3ubuntu1_NEEDSBUILD.txt.gz
<desrt> ya.  better do it now, then :p
<nixternal> dholbach: what about telepathy-qt? do the same thing with or just leave that one alone?
<dholbach> nixternal: yeah, sounds like a good idea
<nixternal> roger dodger
<desrt> it'll be nice if people at guadec can sample the bling :)
* desrt wants to get some stuff going on with mirco
<dholbach> StevenK: I have no idea what's happening there :-(
<nixternal> my laptop has spinners! does that count for bling? :)
<dholbach> StevenK: dh_iconcache just calls dh_icons now
<StevenK> I know why it happens.
<StevenK> print "Warning: Please use dh_icons instead. dh_iconcache is going to go away.\n
<StevenK> ";
<StevenK> Recursion much?
<StevenK> system("dh_iconcache @ARGV");
<StevenK> dholbach: Shall I upload a fix?
<infinity> StevenK: Still around?
<dholbach> StevenK: yeah, that would be great
<StevenK> infinity: Yup
<infinity> StevenK: I have over 8000 dh_iconcache processes on my buildd.  Plsfixkthx.
<StevenK> infinity: ^
<infinity> Kay.  I'm going to kill the builds, and assume your fix is imminent.
<dholbach> sorry, that was my fault
<StevenK> infinity: Yup, give me a few minutes.
<dholbach> great that I'm sharing room with infinity - I will be murdered in my bed
<StevenK> Muahahaha
<StevenK> dholbach: It was nice knowing you.
<ogra> dholbach, any plans who will get your laptop ?
<StevenK> Haha
<dholbach> ogra: my brother, he needs it more than you do
<Hobbsee> dholbach: i suggest you attempt to find another room.  pronto
<ogra> dholbach, heh :)
<pitti> Mithrandir: (CC: dholbach, cjwatson): I added some stuff to https://wiki.ubuntu.com/NewPackageRequirements; do you have any further ideas?
<dholbach>  P R O N T O
<dholbach> pitti: checking it
<Mithrandir> that's the first time I've seen Ccs on IRC. :-P
* ogra just thought the same
<dholbach> pitti: thanks - that looks good
<StevenK> dholbach, infinity: Uploaded.
<dholbach> StevenK: thanks a lot
<StevenK> If the buildds have a heartache between now and the time the binaries get published is another story.
<Mithrandir> pitti: prefered => preferred;  Also, whether an editor exists or not is actually not relevant to whether we're allowed to distribute it.
<Mithrandir> pitti: the problem is when we get something which is not in the preferred form of modification, and I'd like it if you put something about PDF files as an example.
<pitti> Mithrandir: ok, I'll tweak the 'common errors' point about PDF
<Mithrandir> pitti: the GFDL is in /usr/share/common-licenses as of gutsy
<pitti> ah, sweet
<Mithrandir> pitti: and the openssl linking clause could use an "directly or indirectly".
<Mithrandir> apart from that it looks fine to me
<Hobbsee> pitti: an exhaustive list of things that are and are not allowed might be useful
<Hobbsee> at least, the most common ones
<MidMark> hi guys
<MidMark> are there problems with Feisty and Santa Rosa platform that someone knows?
<MidMark> because I have this problem and if you have some time to help me will be much appreciated
<MidMark> https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/124187
<ubotu> Launchpad bug 124187 in linux-source-2.6.20 "cdrom recognized with alternate installation after installation is disappeared" [Undecided,New] 
<MidMark> I have provided as many informations as I can
<geser> infinity: Hi, have you had a chance to look on bug #87077?
<ubotu> Launchpad bug 87077 in launchpad-buildd "The build of xmms2 fails because of HASH(0x82db558)="" in the environment" [Undecided,New]  https://launchpad.net/bugs/87077
<geser> xmms2 doesn't use scons any more but other packages still use it and probably FTBFS for the same reason
<pitti> Mithrandir: page updated with your feedback, thanks
<Mithrandir> Hobbsee: exhaustive list would require a lot of work, and people seem to be able to come up with too many ways to do crackful things for us to make a good list. :-P
<wwoods> pitti: hey, got some apport stuff to talk to you about
<pitti> hey wwoods, long time no see
* wwoods trying to write a tubogears crashdb, among other things
<wwoods> yeah, had to do a bunch of other stuff before I freed up enough time for apport
<pitti> wwoods: I did a lot of abstraction work on apport since we talked last
<wwoods> I saw!
<pitti> so it should be much easier to adapt to bugzilla and such
<wwoods> actually I have a really small patch for you that relates to that
<pitti> wwoods: do you see any major obstacles left?
<wwoods> well, I was thinking we should get both of us using the same method for gathering info from the core
<wwoods> I should give you the elfcore.py code
<wwoods> it seems your kernel patch is unlikely to make it upstream, so..
<pitti> wwoods: oh, is it?
<wwoods> the major thing ATM is the crashdb bit - you mention on the wiki that you want to have a separate crashdb
<pitti> wwoods: I would really be happy if it would make it, to avoid writing the dump to disk temporarily
<wwoods> pitti: avoid writing to disk temporarily? I'm not sure we're talking about the same patch
<pitti> wwoods: separate crashdb> for Launchpad, right
<wwoods> I need to figure out all of the diffs in core_pattern support between vanilla and ubuntu kernels
<pitti> wwoods: elfcore.py sounds like you extract the pid and signal from the core file instead of getting it from the environment?
<wwoods> pitti: right - as it comes over the pipe
<pitti> wwoods: there aren't that many, I can point them to you
<wwoods> now that you mention it.. yeah, when using core_pattern I end up with a crash report *and* a corefile
<wwoods> that should probably be configurable
<wwoods> we actually started work on a kernel coremonitor generic netlink socket
<wwoods> so you could connect to this netlink socket and get headers + corefile when a program dumps core
<wwoods> but.. I realized.. it's almost exactly the same as reading the core over a pipe and extracting that info from the headers
<pitti> wwoods: ah, so you wrote code to extract pid, signal, and exename from the first few kB of the core?
<wwoods> pitti: yep
<pitti> wwoods: that sounds indeed cool
<wwoods> it could be extended to get further info
<wwoods> depending on what you want from the ELF headers
<pitti> those three are enough, I think
<wwoods> but those are the only ones I was interested in
<pitti> wwoods: that still leaves the ulimit overriding
<wwoods> http://pastebin.ca/610661 has a patch you should take
<wwoods> the patch is obvious
<wwoods> but.. in RPM-land it's possible to have versions that aren't identical strings but *are* equal
<wwoods> e.g. "0:2.1-4.fc7" versus "2.1-4.fc7"
<wwoods> hence.. gotta use compare_versions any time you're comparing versions
<pitti> wwoods: ah, I see
<Mithrandir> wwoods: you have that in dpkg-land too
<pitti> wwoods: in fact that's true for .deb, too, although noone explicitly writes 0:
<Mithrandir> : tfheen@thosu ~ > dpkg --compare-versions 0:1 eq 1 && echo true
<Mithrandir> true
<wwoods> it's rare in rpmland but it happens. I was getting apport refusing to create a report because it thought I had obsolete packages
<Mithrandir> and more surprisingly, maybe:
<Mithrandir> : tfheen@thosu ~ > dpkg --compare-versions 1-0 eq 1 && echo true
<Mithrandir> true
<wwoods> there's a bunch of perl packages that have an explicit 0:
<wwoods> anyway.. as for the ulimit override
<wwoods> it seems sensible that writing to a pipe should override ulimit
<wwoods> but on the other hand, it means that we need to trust userspace process to honor it
<pitti> right, of course
<wwoods> I'm not sure if that's a security problem or not
<pitti> wwoods: not a security problem
<pitti> wwoods: but of course it creates a potential bug
<wwoods> the kernel guys were kind of wary, but then.. that's exactly the problem we'd have with the netlink socket
<pitti> wwoods: i. e. if the program you specify in core_pattern does not honor it, it'll clutter your disk and such
<wwoods> indeed
<evand> bryce: bug 124913
<ubotu> Launchpad bug 124913 in linux-restricted-modules-2.6.22 "glxinfo segfaults with nvidia-glx-legacy" [Undecided,New]  https://launchpad.net/bugs/124913
<pitti> if you specify random crack in core_pattern, you have more to worry about :)
<wwoods> so yes, I'm not sure how we should pass the real rlim to the crash handler
<wwoods> could you point me to the kernel patches you've got?
<pitti> wwoods: so I have a lot of test cases for this, since I'm aware that it is a sensitive spot
<wwoods> naturally
<wwoods> oh, so how long have you been using apport in Ubuntu? is it on by default?
<wwoods> I'm getting the feeling that devs are unhappy with it filing a bug for every crash
<pitti> wwoods: hm, I don't see them in the history of http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-gutsy.git;a=history;h=dbd5c7f140e0b48bdfc0272d065cb5246260811f;f=fs/exec.c, I'll generate it manually
<wwoods> which makes me want to avoid doing so for Fedora
<wwoods> ..I should make my bzr branch public somewhere
<pitti> wwoods: we have used it for edgy, feisty, and gutsy development cycles, but disabled it in final releases (edgy and feisty)
<wwoods> so you can see what changes I've made
<wwoods> interesting
<pitti> wwoods: with the recent improvements we plan to leave it on
<Hobbsee> Mithrandir: [01:47]  <Mithrandir> Hobbsee: exhaustive list would require a lot of work, and people seem to be able to come up with too many ways to do crackful things for us to make a good list. :-P  <--true that.  i was hoping for the *most* common.  like, top 10 or so
<wwoods> one problem we have is that bugzilla doesn't seem to have an RPC for attaching a file
* Hobbsee shrugs, goes back to hiding
<pitti> wwoods: I recently implemented https://wiki.ubuntu.com/CrashReporting and https://wiki.ubuntu.com/ApportCrashDuplicates, that helped a lot
<wwoods> which is why I was thinking of having a separate crashdb, which allows authorized people to link a crash to a new bugzilla/etc bug
<pitti> wwoods: so in particular, we left apport itself on, so it continues to generate crash reports in stables; but we disabled the automatic notifications about them
<pitti> wwoods: so that community members can still call the UI manually
<wwoods> interesting
* Mithrandir rattles the bush Hobbsee is hiding under
* Hobbsee screams, and runs away
* Hobbsee hides under a rock
<pitti> wwoods: right; right now we (ab)use private bugs for crash reports, but eventually LP will get a real crash db concept
<wwoods> "avoid exposing potentially sensitive data to the public and avoid sending unwanted bug email to developers" is the thing that made me start work on this
<pitti> wwoods: that's what we mitigated with CrashReporting
<wwoods> basically each uploaded crash gets a UUID, which can be used to look up your crash report. only authorized fedora devs / QA people would be able to browse the crashdb
<mneptok> Hobbsee: moo.
<Hobbsee> hiya mneptok!
<pitti> wwoods: your patch> 'avail' is not defined, the test suite fails now
<mneptok> Hobbsee: -devel is -t?
<wwoods> hrm?
<Hobbsee> mneptok: yes.
<mneptok> k
<mneptok> sowwy
<wwoods> avail = packaging.get_available_version(pkg)
<pitti> wwoods: right, that's what happens now for our crashes
<Hobbsee> mneptok: no problem
<pitti> wwoods: ah, I recently modified the code :)
<wwoods> maybe that patch got reformatted..? oh raths
<wwoods> err rats
<wwoods> heh
<wwoods> it's only been 3 days since my last pull. slow down!
<pitti> :)
<wwoods> oh, here's one thing - apport-retrace is only useful for deb/apt implementations
<wwoods> so I might just add a bin called apport-retrace-fedora and install that instead
<wwoods> but both can be kept in the source
<pitti> wwoods: right, apport-{retrace,chroot} are the two remaining tools which do not use the abstract packaging interface
<wwoods> oh, so you're planning on changing them to use the abstracted interface?
<pitti> wwoods: I'm happy to rename mine to *-apt
<pitti> wwoods: I'm not sure, TBH; it would basically mean to move 90% of their code into the packacing interface
<wwoods> right, I think it's OK to have separate implementations per-distro
<pitti> wwoods: it's on my wishlist, though
<wwoods> since, like you said, 90% of the code in there is distro-specific anyway
<pitti> wwoods: I'm fine with having -apt and -rpm versions in the upstream trunk and mangle debian/* to install the right one
<wwoods> sure - we already do that with packaging_impl anyway
<pitti> wwoods: python report.py -v is happy now; committing
<wwoods> oh, I wrote packaging_fedora.py as a subclass of a semi-abstract packaging_rpm.py, so someday we can go bother the SuSE/Mandriva folks to join us
<wwoods> JOOOIN USSSSS
* pitti feels some progress in his world domination plan
<Hobbsee> pitti: but i'm dominating the world!
<Hobbsee> or will be
<pitti> hm, /me did not consider that :)
<Hobbsee> pitti: combine forces. :P
<kagou> hi
<wwoods> pitti: so, every crash is still a new bug? doesn't that generate huge amounts of mail?
<pitti> wwoods: http://people.ubuntu.com/~pitti/patches/apport-exec.c.diff
<pitti> wwoods: email> not any more, since those are now private bugs with a 'black hole' team email address
<wwoods> ahhh
<wwoods> so (in bugzilla terms) it gets assigned to its own special component for crash dumps
<pitti> wwoods: the plan is to use canned searches and automatically generated reports now
<wwoods> and then gets moved to the right place by the retracer?
<pitti> wwoods: i. e. sorting by number of duplicates, or packages which have the most crash reports, etc.
<pitti> wwoods: please take a look at the wiki page, it explains our setup
<pitti> wwoods: but please note that CrashReporting is both Ubuntu specific and also a temporary hack until we get a real crash db
<pitti> wwoods: so every distro/bug tracker has to find its own workflow which works best
<wwoods> right, which is why I was thinking about hacking up a proper crash db webapp-type thing
<wwoods> so I spent this weekend wrestlin' with turbogears trying to do that
<pitti> wwoods: not sure, maybe the google breakpad already provides that?
<wwoods> haven't looked at the server-side breakpad stuff, but doesn't that require linking in breakpad libs?
<pitti> I don't know
<pitti> wwoods: recently I talked to the upstream bug-buddy Gnome guys
<pitti> wwoods: they use the client-side stuff for generating a minidump etc.
<pitti> wwoods: but they still use bugzilla for the crashes
<wwoods> "Breakpad provides client libraries for each of its target platforms."
<pitti> I haven't looked at it for a long time, it just might be worth checking out
<wwoods> yeah, it's basically a cross-platform reporter, like talkback (or whatever firefox/mozilla used)
<pitti> wwoods: but in any case it's easier for us to integrate it into LP than to maintain a second system, since LP already has the users, their teams and privileges, etc.
<wwoods> we want something linux-specific that doesn't require extra libraries to be linked in
<pitti> doesn't even need to be linux specific
<pitti> wwoods: I recently wrote a documentation about the data format
<pitti> wwoods: after discussing joining efforts with the Gnome guys
<pitti> wwoods: it's in doc/, so maybe you are interested in taking a look
<pitti> wwoods: I kept platform independence in my mind when writing this, but because I'm slightly biased :)
<pitti> wwoods: did you get the kernel patch?
<pitti> wwoods: it's a bit hard to tell apart the changes for the environment passing and the core limit overriding, since both use the same mechanism
<wwoods> pitti: I did
<wwoods> so really it's just CORE_REAL_RLIM that tells the process what's up
<pitti> right
<pitti> wwoods: and the if (core_pattern[0]  == '|') { .. } bit, of course
<wwoods> I'll talk to the kernel dudes about this and see if they think it's sensible
<pitti> wwoods: I'm not stuck with this particular patch, I'm happy to adapt apport to a different solution
<wwoods> right - but this seems sensible.
<pitti> it's a seb128!
<seb128> hey pitti!
<Hobbsee> hiya seb128
<seb128> hey Hobbsee
<pitti> wwoods: I'm curious about your elfcore.py (or what was it called like?), that seems to make it a bit more independent from the kernel patch
<wwoods> pitti: hang on, I'll construct a patch
<pitti> wwoods: do you have that in your branch?
<wwoods> yep
<wwoods> hrm. can bzr use webdav, I wonder?
* wwoods tries to find a public place to push his branch 
<pitti> hm, I'm not sure
<pitti> wwoods: Launchpad :)
* wwoods tries to remember his launchpad password
<mvo> mdz_: I think the problem you experience is: bug #103306
<ubotu> Launchpad bug 103306 in compiz "compiz or aiglx breaks fitt's law with scrollbars in a maximized window, or panels" [Medium,Triaged]  https://launchpad.net/bugs/103306
<pitti> wwoods: did you add your public ssh key? bzr push to lp needs that (it won't accept the password)
<wwoods> yeah, I've added my key but.. I'm not sure how or where I'd push my branch
<pitti> wwoods: bzr push sftp://yourlogin@bazaar.launchpad.net/~ubuntu-core-dev/apport/fedora
<Mithrandir> bzr push sftp://bazaar.launchpad.net/~yourusername/productname/branchname
<pitti> wwoods: the last component is the branch name
<wwoods> gotcha
<Mithrandir> pitti: uh, he's not member of core dev, is he?
<pitti> wwoods: you can also call it 'rpm-backend' or similar
<pitti> wwoods: oh, good point, hang on
<pitti> wwoods: s/~ubuntu-core-dev/~yourlogin/
<pitti> Mithrandir: thanks
<pitti> wwoods: if it's your first push, it will remember the URL, otherwise you can call it with --remember
<wwoods> pitti: cool! it's pushing! heh
<pitti> \o/
<wwoods> chugga chugga. go little bzr branch go.
<pitti> https://code.launchpad.net/apport has it now
<wwoods> so yeah. apport/elfcore.py is the elfcore class, and there are changes in bin/apport to use it
<dholbach> thanks nixternal
<nixternal> no problem :)
<wwoods> http://rdr.to/aa <-- that's the changes to bin/apport
<pitti> wwoods: ah, just looking at it
<aruiz> hi there
<aruiz> could anybody tell me if its possible that a package can substite another package as a dependency?
<aruiz> let's say package A depends on package B and I want package C to satisfy that dependency so I don't need package B?
<jumpula> provides
<jumpula> package c provides package b
<aruiz> jumpula, thanks!
<aruiz> jumpula, how flexible is it?
<Mithrandir> you can't have versioned provides, but apart from that it, well, works.
<aruiz> Mithrandir, I'm thinking about splited package cases
<jumpula> for example, text editors in debian
<jumpula> package vim provides editor
<aruiz> Mithrandir, where half of the package is provided by one package and the other half by the other one
<aruiz> is there any solution to that?
<Mithrandir> aruiz: uh, what is the problem you are trying to solve?
<aruiz> Mithrandir, I have a collection of packages, and I want to rename them, some of them might be splitted, some of them merged, but I want to keep backwards compatibility to the current naming
<aruiz> on merging, there is no problem
<Mithrandir> usre transitional packages, then
<aruiz> how does that works?
<Mithrandir> s/r//
<Mithrandir> have an empty package with the old name that depends on the new one
<aruiz> that's a good idea
<mdz_> mvo: that bug needs a better title I think :-)
* mdz_ gives it one
<mvo> mdz: thanks :)
<geser> keescook: can you look over bug #124725 and bug #124629 if they are ok?
<ubotu> Launchpad bug 124725 in fireflier "[CVE-2007-2837]  Unsafe tmp file handling" [Undecided,Confirmed]  https://launchpad.net/bugs/124725
<ubotu> Launchpad bug 124629 in gsambad "[CVE-2007-2838]  Unsafe tmp file usage" [Undecided,Confirmed]  https://launchpad.net/bugs/124629
<roger25> is usplash known not to work with lilo ?
<mjg59> It works fine with lilo
<roger25> well i got blank and buggy consoles (big green pixels) after having set up lilo to lunch usplash, did i missed something
<roger25> just added append="quiet splash" and vga=791
<roger25> sort of the reset of the console is not performed
<mjg59> Don't pass vga=791
<roger25> hmm ... and i get a 640x480 console then
<mjg59> Yes
<roger25> that's not what i call working fine
<mjg59> Using vesafb tends to cause a variety of issues
<roger25> damn i miss my bootsplash, i had a cute console a cute startup and a cute lilo then (and a lot of blinking screen until i get the desktop)
<roger25> btw the timeout blank screen on console doesn't erase colored text... that's ... too bad
<pygi> hey ho pitti
<pitti> hi pygi
<pygi> pitti, how is it going? :)
<pitti> pygi: just came back from dinner, and finally got a room wifi access voucher :)
<pygi> pitti, great ^_^
<ajmitch> hello pitti
<pitti> hi ajmitch
<pygi> hey seb128
<seb128> hi pygi
<calc> seb128: hi
<seb128> Hi calc
#ubuntu-devel 2007-07-10
<TheMuso> cjwatson_: Are you ok with me merging festival?
<cjwatson_> TheMuso: sure
<Hobbsee> morning cjwatson
<cjwatson> good morning
<cjwatson> excellent, apt upgrades without complaints this morning
<Hobbsee> indeed.  thank mvo for that one
<Hobbsee> cjwatson: is henrik there with you?
<cjwatson> Hobbsee: I did a chunk of it yesterday, actually ... ;)
<cjwatson> Hobbsee: haven't seen him yet this morning, but he is here this week, yes
<Hobbsee> cjwatson: okay, and yousrelf then.  i just saw his name on the changelog :)
<Hobbsee> cjwatson: when he comes, if you remember, could you ask him to contact me?
<Hobbsee> morning bryce
* mvo waves to cjwatson
<Hobbsee> morning mvo
<cjwatson> Hobbsee: ok
<Hobbsee> cjwatson: thanks
<cjwatson> mvo: guten Morgen
<mvo> guten morgen Hobbsee
<Hobbsee> morgen mvo.  Wie gehts?
<mvo> Hobbsee: danke, gut
<Hobbsee> :)
<LaserJock> ... and you've tapped out my knowledge of German ;-)
<Hobbsee> hehe
<Hobbsee> mine's quickly dying.  although i was reminded of a whole heap of it, going thru frankfurt airprot
<siretart> Yay, deutsche Kabal bei der Arbeit :)
<siretart> morning *
<Hobbsee> arbeit...arbeit....
<Hobbsee> come on brain, give me the translation...
<Hobbsee> ah :)
<LaserJock> Hobbsee: more like "come on Google, give me the translation..."
<StevenK> Heh
<Hobbsee> LaserJock: the brain recognised the word, so it had a chance at the translation
<Hobbsee> morgen ogra
<ogra> hey Hobbsee
<ogra> training german ?
<Hobbsee> ogra: we decided english was too boring, and switched to german today
<ogra> sehr gut :)
<Hobbsee> ogra: i actually learned german for about 5 years.  unfortunately, never very much of it.
<ogra> Hobbsee, you should visit german then :)
<Hobbsee> ogra: clearly you didnt hear me defaulting to german when people would speak to me in spanish, while at UDS.
<StevenK> I did 2 years of German in high school. I never picked up much, and that was 13 years ago.
<Hobbsee> ogra: i plan to.  will probably move there, actually.  somewhere in the future.
<thom> *giggle* glad i'm not the only person who does that
<Hobbsee> thom: :)
<Hobbsee> "if it's not english, then it must be german.  oh wait"
<LaserJock> Hobbsee: I kept mixing French and Spanish
<tepsipakki> I did 5 years in school, but never used it much.. besides my wife is teaching in Deutsche Schule Helsinki so there hardly is need for it either :)
<Hobbsee> LaserJock: nice...nice...
<thom> "je voudrais dos cervesas por favor"?
<ajmitch> heh
<Keybuk> my German has degraded so much that I'm not sure I could tell it from Spanish
<Hobbsee> ogra: just convince them to hold another UDS or something in somewhere german-speaking, please.
<Hobbsee> haha
<thom> we could do the netherlands and really confuse things for you
<LaserJock> Hobbsee: they'll probably do it someplace silly ... like London ;-)
<Hobbsee> LaserJock: well, i would like to visit london, so no problems ther.e
<LaserJock> I *think* I might be able to translate ok there
<Hobbsee> morning calc
<Mithrandir> hm, am I the only one who get BADSIG on http://archive.ubuntu.com gutsy Release?
<Hobbsee> greetings Mithrandir, dholbach
<dholbach> hiya Hobbsee
<Mithrandir> hello, Hobbsee
<calc> Hobbsee: hi :)
<Hobbsee> :)
<calc> no more jet lag for me (i hope)
<Hobbsee> heh
<Hobbsee> but jetlag is oh so fun!
<calc> heh, yea right
<calc> doko: did ooo fail due to those two empty de.po files (that is what i got from reading the log anyway)
<doko> calc: yes
<doko> calc: if you do want to investigate on your laptop, run debian/rules gsi-export
<doko> maybe the new version of translate-toolkit is the cause
<calc> doko: ok
<calc> hmm yea it jumped from 0.10.1-1 to 1.0.1-1 on july 5
<calc> should be relatively easy to determine if it is the cxause
<Hobbsee> erk, cjwatson appears to be going thru teh ubuntu-devel moderation queue
<calc> does FOO+=bar in make automatically add a space before the added item?
<calc> and is there a way to keep it from doing that?
<cjwatson> calc: yes, see 'info make Appending'
<cjwatson> (it automatically adds a space)
<calc> ok
<cjwatson> I don't see a way to keep it from doing that, unless you can get away with using 'FOO := $(FOO)bar'
<cjwatson> see that info node first though, as that's a little different
<calc> the particular issue is PATH+=:/usr/sbin in this case
<calc> which seems to cause issue since path then contains a space
<cjwatson> ah, PATH := $(PATH):/usr/sbin ought to be a reasonable answer then
<calc> cjwatson: ok
<calc> yep that worked, thanks
<mvo> is someone here who uses evms? if so, could you please put the content to a pastebin for me?
<dholbach> mvo: which content?
<dholbach> (not that I use it, ...)
<mvo> *cough*
<mvo> the content of /proc/mounts please :)
<mvo> thanks dholbach
<Mithrandir> bryce: could you please get the xserver with the composite patch needed for mobile in?
<StevenK> Mithrandir/pitti: Would you mind giving kwave back on sparc when you have a spare second? Thanks.
<pitti> StevenK: done
<StevenK> pitti: Thanks!
<pitti> cheers :)
<StevenK> pitti: NBS has exploded with 2.6.22-7 stuff, by the way
<ScottK> keescook: Thanks for taking care of gnupg.  That completes the code changes for S/MIME by default (and GPG as a bonus) in kmail for Gutsy.  Now documentation ...
<Yagisan_> doko, ping
<Yagisan> doko, I was told to point you at this -> https://bugs.launchpad.net/ubuntu/+source/gcc-4.1/+bug/125031
<ubotu> Launchpad bug 125031 in gcc-4.1 "defines BIG_ENDIAN on little endian machines" [Undecided,New] 
<Keybuk> iwj: I'm dropping the udev suppress-syslog patch
<Keybuk> Kay agreed that it made no sense to use syslog() if --verbose is given
<Keybuk> so udevd --verbose will now do exactly what you want
<iwj> Keybuk: Excellent.
<StevenK> Hrm. It looks like sejong hates the world.
<pitti> StevenK: sparc FTW!
<StevenK> Heh
<Keybuk> In fact, all our patches to udevd can be dropped \o/
<calc> Keybuk: udevd won't turn into network manager when the patches are dropped will it? ;)
<ogra> oh now that would be fun :)
<ogra> i'D be curious how the udevd-applet would look like then ;)
<infinity> StevenK: sejong and artigas both, interestingly... Both rescued now.
<StevenK> infinity: Great, thanks
<Keybuk> calc: no
<seb128> TheMuso: no need to open bugs about new desktop package versions, they are listed on desktop todo wiki already
<TheMuso> seb128: ok
<tkamppeter> pitti, ping
<pitti> tkamppeter: pong
<tkamppeter> pitti, can you have a look at bug 41267, it seems that CUPS still does not log for some people.
<ubotu> Launchpad bug 41267 in cupsys "cupsys cannot create error_log" [Medium,Fix released]  https://launchpad.net/bugs/41267
<tkamppeter> pitti, another problem is bug 112803, could probably not be reproduced upstream and so never got fixed.
<ubotu> Launchpad bug 112803 in cupsys "MASTER [Feisty]  cupsd leaking file descriptors (was: Multiple jobs are not printed)" [Medium,Incomplete]  https://launchpad.net/bugs/112803
<keescook> ScottK: rockin'!  thanks (to you and geser) for getting things gathered and pinging me.  :)
<pitti> tkamppeter: it's still on my radar, but no time yet; maybe you can have a look? I probably won't have time this week during the sprint
<ScottK> keescook: BTW, we will now have S/MIME and GPG sigining and encryption by default for Kmail for Gutsy.  This was the last piece.
<keescook> nice indeed.  :)
<ScottK> Now that pinentry is in Main, it might be possible to do that with other MUAs (but since I don't use them, I've no idea).
<seb128> TheMuso: oh, you worked on updates?
<ScottK> keescook: Did you see my ping on #ubuntu-motu yesterday about libnet-dns-perl?
<seb128> TheMuso: https://wiki.ubuntu.com/DesktopTeam/WeeklyTODO you can update the wiki to claim update you work on
<TheMuso> seb128: Yeah, sorry I should have summarised a bit better.
<seb128> TheMuso: add links to the packages and we will review them
<TheMuso> seb128: Ok.
<tkamppeter> pitti, then I will move all this stuff over to after the sprint. When it is over?
<pitti> tkamppeter: just this week
<pbn> d
<pkl_> dent
<StevenK> pitti: No fair showing glew and parrot in NBS if the new binaries haven't made it past NEW. :-)
<sivang> is pitti around at all?
* lamont wonders when ${source:Upstream-Version} came into the default vars for dpkg-gencontrol
<keescook> ScottK: I may have missed it; I was tracking that bug (I think I requested the gutsy sync already).
<ScottK> keescook: http://lwn.net/Alerts/240438/ is a libnet-dns-perl security issue that we appear to have in all released versions.
* ScottK is curious how significant you think that is.
<keescook> I think it needs to be fixed, but it was low on my personal list of things to do.
<ScottK> OK.  Thanks.  I'll look into it if I have time.
<keescook> very cool; thanks.
<geser> keescook: I'll update the patches for the gsambad CVE. I wonder why Debian didn't create a dpatch.
<persia> geser: Some members of the debian security team don't like dpatch for several reasons.
<imbrandon> BenC, ping ( kernel issue )
<keescook> geser: yeah I'm not sure either; it's kind of odd -- especially given that the fix isn't a full fix.  I haven't had a chance to ask the uploader.
<geser> keescook: the code touches the tmpfile and redirects the output from smbstatus into it, so it needs a filename
<geser> does it work if mkstemp generates the file and also opens them?
<Riddell> mr_pouit: what's the method behind all your sync requests?
<keescook> geser: yeah, the fact that the fd is open is no problem; frequently one can just mkstemp and close the fd.  The file (with good name and permissions) will remain.
<pitti> StevenK: heh, will happen soonish :)
<tsmithe> hi - i was wondering if an archive admin could check out the ubuntustudio-look package in binary NEW; thanks :)
<geser> keescook: does mkstemp generate better file names than tempnam?
<keescook> geser: it's the fact that mkstemp actually _creates_ the file, rather than just generating a name.  there is (a very hard but possible) race condition between the mktmpname, the touch, and the chmod.
<keescook> mkstemp basically handles all three operations (name, touch, chmod) in an un-raceable way.
<geser> and the template given to mkstemp contains the created filename?
<geser> the manpage is a little bit short on that part
<keescook> right.  So, for example "gsambad-XXXXXX" which could result in gsambad-jX6f42
<keescook> it literally expects the argument to have 6 trailing "X" characters.  (kinda odd)
<geser> ok, will prepare an updated debdiff
<keescook> very cool!  thanks, I'll propose it to debian as well when you're done.  :)
<geser> have you had also time to look on the fireflier debdiffs?
<keescook> I was actually looking at them right now.  :)
<keescook> I was trying to figure out why the debdiff has two changelogs.  :)
<keescook> aaaand, this update from Debian is "unsafe" too.
<pitti> seb128: NO_PKG_MANGLE=1
<keescook> they should be doing    oldmask=$(umask); umask 0077; mkdir -p /var/run/fireflier; umask "$oldmask"
<keescook> in the maketmpdir function.
<keescook> geser: ^^
<seb128> pitti: thanks
<geser> keescook: doesn't the chmod 700 sets the dir permissions to safe values?
<keescook> geser: correct, but in the time between the mkdir and a chmod, someone can enter the directory.  It's a very very very minor race, but if it's being corrected, it should be corrected fully.  :)
<geser> good, will prepare updated debdiffs too
<geser> the debdiff for edgy has some problems with gnomeclient/configure.ac which makes it FTBFS
<keescook> mathiaz: https://help.ubuntu.com/community/SbuildLVMHowto
<cjwatson> keescook: I believe mkdir -m 0700 would be safe as well
<cjwatson> and is less effort than messing with umask
<keescook> cjwatson: ah! right, yes, that would be cleaner.
<keescook> shawarma: we just had a short discussion about ebox+sudo.  it has been suggested that it switch from using sudo to using userv...
<kent> ebox?
<ogra> keescook, let me guess who suggested *grin*
<keescook> ogra: I bet you'll win.  :)  cjwatson seemed to agree, though, so without having used userv or looking at the ebox, I agreed too.  ;)
<keescook> *the ebox source
<cjwatson> really just because editing /etc/sudoers from a maintainer script is a bit of a nightmare
* ogra wasnt aware they rovide any source for it :) http://www.compactpc.com.tw/ebox-2300.htm
<Mithrandir> we could have /etc/sudoers.d
<cjwatson> and liable to make experienced sysadmins crap themselves
<Mithrandir> :-P
<ogra> *provide
<cjwatson> ogra: not that ebox
<ogra> heh, indeed :)
<xxxxx1> algum core-dev de florianpolis aqui no #?
<geser> keescook: here is the updated debdiff for gsambad: http://launchpadlibrarian.net/8357940/feisty.debdiff
<geser> I've also reopened the bug as gutsy has also this suboptimal patch
<geser> keescook: re the fireflier patch: is "mkdir -m 0700 /var/run/fireflier" really enough? what if the attacker creates that dir before the init-script and puts a symlink there?
<evand> seb128: http://rookery.ubuntu.com/~evand/uploaded/
<evand> thanks again
<seb128> evand: thank *you* for doing the update ;)
<shawarma> keescook: userv?
<geser> keescook: ah, /var/run/fireflier/fireflier.rules gets removed before the output is redirected there, so it should be safe, right?
<seb128> evand: uploaded
<asac> pitti: http://paste.ubuntu-nl.org/29386/ ... this doesn't stop from activation to be redone, but the interface should be teared down anymore
<geser> can someone explain me why dict-wn build from word-net (universe) is in main?
<Keybuk> gnargh, my kernel didn't compile
<cprov> siretart: Fujitsu: shawarma: could you, please, check the PPA UI prototype:
<cprov> https://dogfood.launchpad.net/ubuntu/+ppas
<cprov> https://dogfood.launchpad.net/~shawarma/+archive
* cprov goes afk
<siretart> cprov: sweet!
<cprov> siretart: thanks
<siretart> cprov: I assume you want feedback on the ui. What form do you prefer? irc, email, malone?
<cprov> siretart: malone (product -> soyuz, tag -> ppa)
<mr_pouit> Riddell: bugs listed on this page: http://ajmitch.net.nz/~ajmitch/missing-fixes-rc.html, which are also in ubuntu (ftbfs...)
<siretart> okay. willdo
<cprov> siretart: check what pitti did -> https://dogfood.launchpad.net/~ubuntu-langpack/+archive :)
<siretart> wow!
<cprov> 1606 langpacks ?
<siretart> busy martin :)
<siretart> cprov: btw, are you aware that the certificate on dogfood has expired?
<cprov> siretart: yes, I know. I will file a RT now before I forget
<cprov> siretart: done
<siretart> cjwatson: why is live-initramfs blacklisted from syncing from debian? AIUI the ubuntu live system is handled in casper, and live-initramfs is the debian fork? (bug #124600)
<ubotu> Launchpad bug 124600 in live-initramfs "Please sync live-initramfs (universe) from Debian unstable (main)" [Undecided,Invalid]  https://launchpad.net/bugs/124600
<Keybuk> *bounce*
<pitti> Keybuk: kernel finally works now? :)
<Keybuk> nope :-/
<Keybuk> just bouncing anyway
<Keybuk> annoyingly pretty sunset
* pitti cannot see it from this side of the hotel, how bad
<mjg59> Wow. You're managing to get back to the hotel for 9?
<pitti> yeah, we just had some pizza :)
<ion_> Dont remind me of food, please. ;-)
* pitti throws a cake at ion_ 
<ion_> catch :cake do yield end
<Keybuk> pitti: I need to find out which header declares a structure I'm using to reference another :-/
<pitti> Keybuk: happy grepping then
* pitti commits the final apport bit of the server team's wishlist
<ion_> keybuk: happy cscoping then
<Keybuk> cs?
<ion_> apt-cache show cscope
<geser> !info cscope
<ubotu> cscope: Interactively examine a C program source. In component universe, is optional. Version 15.6-2 (feisty), package size 148 kB, installed size 608 kB
<Keybuk> cscope on the kernel seems drastic
<pitti> wwoods: here?
<hardwarehank> hello
<Keybuk> yay it built; unfortunately it means my patch is no longer one line :-/
<hardwarehank> neverblue: i have an ext3 partition with a bunch of data on it in a dir called 'old'.  I want to install ubuntu on that partition without losing the '/old' directory in a format. How?
<hardwarehank> -neverblue
* wwoods is here
<pitti> wwoods: hi! I was just looking at the bzr merge of your branch; that looks manageable, so I'll merge it into trunk; unless there's something that doesn't work yet?
<wwoods> I think pretty much everything works
<wwoods> IIRC there's no obvious STUB / FIXME lines
<pitti> cool
<wwoods> oh wait - get_available_version() is a stub (I lie and say that every package is already up-to-date)
<wwoods> and get_source_tree() is a stub but.. I think maybe apport-retrace-fedora won't use it
<wwoods> get_available_version is actually a really easy fix, I've just been working on getting everything else working first
<wwoods> but yeah, I think it's OK to commit that stuff to trunk
<geser> Mithrandir: have you an idea why dict-wn build from word-net (universe) ended in main?
<Kmos> !info wine-doors
<ubotu> Package wine-doors does not exist in feisty, feisty-seveas
<Kmos> http://www.wine-doors.org/releases/wine-doors_0.1-1_all.deb
<Kmos> v0.1 is out =)
<Kmos> geser: this one is for you :) when u've time
<cromo> hi. I was about to install flashplugin today under feisty and couldn't because of md5sum mismatch. this is due to recent flash plugin update (to 0 9.0.47) - the package for feisty is still 9.0.36 IFRC. Any ideas? This is my girlfriend's desktop, I am archlinux guy so don't really know what is going on under ubuntu :)
<cromo> It seems that this has not been reported yet
<cromo> (I looked in launchpad, but not very precisely to be honest)
<cromo> I tried to ask at #ubuntu, but all the answers pointed on how to install it manually, which is not the proper way out
<gnomefreak> cromo: the newest flash is broken thats why we havent updated it in gutsy and as for feisty im not sure it will be upgraded for feisty
<cromo> ok, but there's still a md5mismatch
<cromo> the script downloads the newer version and expects the older
<gnomefreak> cromo: it does?
<cromo> indeed
* gnomefreak wonders why i dont see this on gutsy
<cromo> I tried many times and it was all the same
<cromo> e.g. md5 mismatch
<cromo> I guess that the link inside the script points to the neweset tarball version available at macromedia's
<gnomefreak> flashplugin-nonfree 9.0.31.0.2ubuntu1 [15.4kB] 
<gnomefreak> works fine here
<gnomefreak> cromo: do you have automatix or 3rd party repos that might have it in it
<gnomefreak> oh hold that thought
<cromo> nope, clean feisty install
<gnomefreak> cromo: it still installs the right version but yes that is weird
<cromo> hold on a sec
<cromo> I'll ask my gf to show the output of the console
<gnomefreak> im wondering if adobe didnt drop the 9.0.31
<gnomefreak> if they dropped it and used same link for the newest version
<cromo> it seems so
<gnomefreak> the flash source just grabs the generic named tarball
<cromo> gnomefreak: what's even more weird, it does install the package despite md5 mismatch
<gnomefreak> cromo: it did here
<cromo> but the package doesn't contain the plugin itself
<cromo> gnomefreak: it did at my gf's, too
<gnomefreak> policy shows it installed here
<cromo> right, but the plugin files are not there
<gnomefreak> im grabbing source see if i can find something that jumps out slaps me in face
<cromo> sure
<cromo> btw. I was really, really impressed with feisty. I previously used badger before switching to archlinux (needed something more "hackish"), and the progress is _immense_
<gnomefreak> cromo: we should move this to #ubuntu-motu
<cromo> ok
<cromo> let's do
<Mithrandir> geser: probably because I suck
<geser> so I should add to bug #124626 that dict-wn should be moved to universe before the sync?
<ubotu> Launchpad bug 124626 in wordnet "[Sync Request]  Sync wordnet  (1:3.0-2)  from Debian unstable (main)" [Undecided,Incomplete]  https://launchpad.net/bugs/124626
<Mithrandir> geser: no, fixed.
<Mithrandir> I just did it now.
<geser> thanks
<Mithrandir> happy to help
#ubuntu-devel 2007-07-11
<mneptok> Mithrandir: go to bed
<Mithrandir> mneptok: it's not even midnight here.
<pitti> and the hotel wifi is really good tonight, too :)
<Mithrandir> yeah, seems to be
<mneptok> i thought you were UTC+3 at the moment ...
<pitti> no, +1
<mneptok> oh, you're in .uk
<Mithrandir> we are
<Mithrandir> even so, I'm going to bed soonish
<Mithrandir> just not right now
<seb128> pitti: don't burn your laptop or the good wifi will be of no use for you ;)
* mneptok goes back to killing his brain with rum and Usenet
<Mithrandir> mneptok: mm, rum
<seb128> mneptok: should try rum and compiz for a change
<pitti> then the windows will wiggle even with metacity
<mneptok> Mithrandir: i got Monty@MySQL a *really* nice bottle of Kentucky bourbon this weekend. it will be hard to ship it and not drink it. :)
<Mithrandir> mneptok: I should be moved into a more customer-facing position so I get to buy alcohol for company money too. :-P
<mneptok> Mithrandir: oh, this is all between us as friends.
<mneptok> no company money involved
<Mithrandir> oh, ok.
<pitti> good night everyone
<shawarma> Oh, Ian actually *wrote* userv.
<ion_> Oh, wow. I thought he transfers the code to the computer telepathically.
<mneptok> ion_: no, that works in the opposite direction. Ian's machine tells him things. Bad things.
<jikanter> anyone have any idea why security.ubuntu.com is down? usually I wouldn't ask such a question here but I figure if someone knows the answer, it probably would be someone in here.
<poolie>  the ubuntu datacentre is having network problems; our sysadmins are working on it
<StevenK> poolie: Thanks for the heads up.
<poolie> n.
<poolie> np
<poolie> thom, ping?
<lifeless> hiya folk; I hate power-greyouts
<poolie> lifeless, also the DC is having trouble
<lifeless> yeah
<lifeless> not my problem to fix though; from vilnius :)
<mneptok> it's dark. hold me.
<poolie> well, lucky for them it's almost a decent time in london
<lifeless> mneptok: ;(
<mneptok> does anyone have any ruby slippers?
<poolie> i have ugg boots
<mneptok> there's no place like ~/
<csj> hello, I try to write a resolution switcher and I use xrandr to list supported resolutions, max = 800x480, but some window larger than 800x480, how to set X to 800x600 and compressed vertical resolution?
<csj> or another mode when mouse move clear the sceen brink, screen will scrolling
<csj> I see the switcher in Intel Classmate PC, and try to implement it
<poolie> csj, as far as i know you can't set the virtual desktop size through xrandr
<poolie> if that's what you're trying to do
<csj> hmm, I try to look for something else like mergedfb, thanks, poolie :)
<shirish> guys has upstart completely replaced sysvinit or not?
<poolie> shirish, in feisty and onwards, yes
<poolie> i believe so
<shirish> ubotu upstart
<ubotu> Upstart is meant to replace the old Sys V Init system with an event-driven init model.  For more information please see: http://upstart.ubuntu.com/
<shirish> poolie: Is there a way to know if I'm using sysvinit or upstart or not?
<shirish> meant if I'm using sysvinit or upstart, how to know the difference?
<pbn> if you have problems with the shutdown command, it means you're using upstart
<pbn> heh :)
<pbn> see bug 74139
<ubotu> Launchpad bug 74139 in upstart "shutdown missing -F (force fsck) option" [Low,Confirmed]  https://launchpad.net/bugs/74139
<poolie> shirish, dpkg -S /sbin/init maybe
<shirish> poolie: ok yes, shirish@ubuntu:~$ dpkg -S /sbin/init
<shirish> upstart: /sbin/init
<shirish> poolie: so BUM works or doesn't work anymore, any ideas?
<shirish> ubotu bum
<ubotu> Boot options: https://help.ubuntu.com/community/BootOptions - To add/remove startup services, you can use the package 'bum', or update-rc.d - To add your own startup scripts, use /etc/rc.local - See also !grub and !dualboot - Making a boot floppy: https://help.ubuntu.com/community/GrubHowto/BootFloppy - Also see https://help.ubuntu.com/community/SmartBootManagerHowto
<poolie> i have no idea what BUM is
<shirish> poolie: look up, bum=Boot Up Manager, a GUI for stopping & starting services in universe
<thom> poolie: hey?
<Tonio_> asac: ping ?
<Keybuk> thom: happy birthday!
<asac> Tonio_: ping
<asac> pong :)
<Tonio_> asac: hey ;)
<Tonio_> asac: just wanted to tell you I'm adding back the changes for n-m and the applet for the nm-vpn-properties
<asac> he?
<Tonio_> asac: there is a bunch of gnome dependancies on network-manager actually, that I'd got ridd of for kubuntu
<Tonio_> asac: mbiebl is doing the same for the debian packages
<asac> ah ... you want to develop against the coredev bzr branch?
<Tonio_> asac: that's due to bad source splitting, the bug has already been reported
<Tonio_> asac: yeah, I'm testing the packages now and I'll commit on bzr, but I wanted to let you know about the changes
<thom> Keybuk: dank je wel!
<Tonio_> asac: so the point is just to patch the applet for the nm-vpn-properties path and fix network-manager to install the binary in /usr/lib and tell to dh_shlibsdeps to ignore it
<asac> Tonio_: remember there have been updates to bzr branch yesterday ...
<Tonio_> asac: are you okay on rationale ?
<Tonio_> asac: just doing the branch update :)
<Tonio_> asac: I will not commit the changes, just commit on bzr so that you can revies them before uploading the packages, are you okay with this ?
<Tonio_> s/revies/review/
<asac> Tonio_: maybe push up bzr and let me know
<Tonio_> asac: that's the plan, yes
<asac> Tonio_: the perfect way would be to push to some private branch ... get review, then merge over to mainrelease core-dev branch
<Tonio_> asac: is there a branch for the applet ?
<asac> Tonio_: yes
<Tonio_> hum okay
<cjwatson> siretart: I think you answered your own question about live-initramfs; since it's branched from casper, it needs to be merged, not synced
<asac> Tonio_: might be too much to use this kind ... however in the long run thats the benefit we get from bzr ... e.g. get reviews before publishing officially
<cjwatson> siretart: I have no idea why they changed the name, and when I asked at Debconf I didn't get a good explanation from anyone
<Tonio_> asac: well the changes were already tested with the initiall upload as working but yeah I can push them to another branch if you want
<cjwatson> siretart: I feel we should keep our name the same and merge back useful changes from Debian
<Tonio_> asac: yup
<mathiaz> seb128: I've uploaded the new evince packages: http://people.ubuntu.com/~mathiaz/packages/
<asac> Tonio_: which initial upload are you talking about?
<Tonio_> asac: was in the 0ubuntu2 upload in fact, not the first ;)
<Tonio_> asac: when you reworked my package, you miss that change, which caused the breaking of nm-vpn-applet as the applet was still patched, then siretart removed that patch
<Tonio_> asac: I'm just adding the changes back since that causes lots of problem to release a kubuntu cd, too many gnome deps
<asac> Tonio_: ok just show the changes so I understand :)
<asac> Tonio_: should be straight forward i guess
<Tonio_> asac: sure, I just commited the changes for the backend, now doing the applet
<asac> cool
<asac> Tonio_: ok i try to look here every 30 minutes ... while being mostly offline in between, testing other network-manager stuff :/
<Tonio_> asac: changes are on the applet branch too, which I synced with the current published version. the bzr content was outdated
<asac> Tonio_: ok
<asac> Tonio_: so where did you push nm to review?
<asac> Tonio_: hmmm thought you push to private branch :) to take a glance ... lets hope ;)
<bryce_> dholbach, I have a few more packages ready for upload if you have time for more packaging reviews?
<dholbach> bryce_: sure
<bryce_> dholbach, http://people.ubuntu.com/~bryce/Uploads/
<bryce_> three packages:  xrandr, xserver-xorg-input-evdev, and xauth
<Tonio_> asac: no I just pushed in bzr the unpublished stuff
<Tonio_> asac: so that you can review, let me know and eventually build the packages
<Tonio_> asac: or ask me to do so :)
<asac> Tonio_: he?
<bryce_> dholbach, all are fairly small changes
<dholbach> bryce_: alright - will take a look
<asac> Tonio_: i see the changes about vpn-propertiers on release branch now
<bryce_> dholbach, cool thanks!
<asac> Tonio_: sowhat happens on kde ifyou run vpn-properties ?
<Tonio_> asac: the applet patch was still there btw, so I just synced with the current package and updated the changelog
<Tonio_> asac: doesn't work of course, that's why I made it a hidden binary
<asac> Tonio_: the applet branch is ok ... i thought about pushing network-manager to private branch, discuss and if changes are good, just merge over
<Tonio_> asac: it is not on purpose to use manually btw
<asac> Tonio_: so wherefrom is nm-vpn-properties invoked?
<Tonio_> asac: knetworkmanager is doing differently, it doesn't need the vpn-properties
<Tonio_> asac: it is invoked by the applet, that's why I patched the applet to use the good path for it
<Tonio_> asac: the point in making it a hidden binary is just to avoid bug reports since it won't work on kde
<Tonio_> asac: I hope that's clear ;-)
<Nafallo> fabbione: I have a friend who tries to setup grub on raid -> lvm -> ext3, is that possible?
<asac> Tonio_: ah ok ... sounds dirty though.
<asac> Tonio_: but i guess we can take it for now ;)
<siretart> cjwatson: err, now I'm a bit perplexed. I have been asked by panthera (one of the initramfs-tools ppl) to have live-initramfs updated, because he commited some fixes there.
<asac> Tonio_: have you verified that network-manager-applet will always bring in all needed dependencies?
<siretart> cjwatson: last he told me he tried to bring his changes to ubuntu, bug nobody seemed really interested in that. so he decided to fork and leave the ubiquity hooks aside, since he couldn't test them anyway
<fabbione> Nafallo: no idea. when  i do raid lvm and stuff, i usually keep a small /boot on a raid1 and the rest on Lvm and it works fine with lilo. I heard that grub works too in that setup but i never did it myself
<siretart> cjwatson: now you say me that we don't want his bugfixes (to a package we already have in universe), because we rather want them merged back into our casper package
<Nafallo> fabbione: oki, thanks
<siretart> Tonio_: I removed a patch?! err huh?
<fabbione> Nafallo: no provlem
<fabbione> problem even
<cjwatson> siretart: err, I never saw him trying to bring his changes to Ubuntu so I cannot comment on that
<asac> Tonio_: can you please wait a bit with the next upload ... i am trying to fix another thing first
<Tonio_> siretart: you did, but not on bzr :)
<Tonio_> asac: sure
<cjwatson> siretart: I wasn't aware that live-initramfs was already in universe; I think that's a mistake to be honest
<siretart> Tonio_: not on purpose
<cjwatson> siretart: I suppose I can unblacklist it and sync it
<siretart> cjwatson: well, there are already other packages like live-helper and fai actively using live-initramfs
<siretart> cjwatson: removing live-initramfs would break them
<cjwatson> but I am really disappointed that it's forked because I don't think there's a clear reason to do so
<Tonio_> siretart: I'm just ensuring that the path will work this time by fixing the nm-vpn-properties installation path, that was the issue you fixed
<siretart> cjwatson: as said, I think there is a lack of communication here. I would be sad if we removed live-initramfs, because it would break reverse dependencies
<siretart> and I do try to work on fai
<cjwatson> siretart: oh, we can't sync it
<cjwatson> # ... due other reasons:
<cjwatson> # E: casper is in main but its source (live-initramfs) is not
<cjwatson> live-initramfs
<cjwatson> siretart: syncing that would break our live CD
<cjwatson> because they made it generate a casper.deb
<siretart> aaah
<siretart> I'll talk to daniel
<siretart> can I send him to you about merging the changes back to casper?
<cjwatson> so either merge to casper, or branch live-initramfs for Ubuntu and make it not generate casper.deb
<cjwatson> siretart: I'm a bit concerned about me being his point of contact, because I suspect I will not have a lot of time
<cjwatson> siretart: but I guess I can try
<dholbach> bryce_: uploaded :)
<siretart> cjwatson: who would be a better point of contact?
<bryce_> dholbach, excellent, thanks
<cjwatson> unfortunately nobody else who would be good has any more time ;-)
<cjwatson> so I guess it'll have to be me for the moment; Tollef is very busy with mobile
<siretart> well, that seemed to be the problem of daniel last time he tried to merge his changes
<siretart> lack of time on the ubuntu side
<cjwatson> I don't understand why that precluded calling it casper though ...
<cjwatson> it's taking basically the same approach after all, AIUI
<cjwatson> I can understand a renaming if it's a big rewrite
<cjwatson> I did that myself for ubiquity after all
<siretart> the casper binary package seems to be a transitional package
<siretart> for 'upgrading' purposes from etch
<cjwatson> yeah, syncing it will still screw us though
<siretart> yes, its empty
<cjwatson> particularly since he removed ubiquity-casper
<siretart> I think I can drop that and reupload to ubuntu
<cjwatson> that would work for now
<siretart> ok. doing that for now
<Riddell> enrico: your upload of adept to debian seems to miss adept-batch from debian/control, is that deliberate?
<enrico> Riddell: definitely not deliberate: I have no idea what's adept-bach
<enrico> Riddell: I just did apt-get source adept, fixed things, built, uploaded
<enrico> Riddell: I don't think I changed debian/control at all
<Riddell> enrico: curious, maybe petr never put it in debian for some reason
* Riddell asks mornfall
<ogra> mjg59, do you plan to drop by at the distro sprint this week ? i saw there is an agenda item for you, me and amitk about power management maintnance
<Mithrandir> ogra: thursday and friday
<ogra> cool :)
<ogra> Mithrandir, thanks
<mjg59> ogra: Yes, I should be there tomorrow
<iwj> doko: AYT ?  I'd like a word about your lpia changes in dpkg 1.14.4....ubuntu3.
<tepsipakki> what to blame when quota doesn't work right (feisty)?
<axxo> software
<tepsipakki> ah ah
<tepsipakki> seriously, it's trying the wrong paths
<tepsipakki> dapper is fine
<seb128> tepsipakki: try filing a bug?
<tepsipakki> seb128: yes, but where?
<tepsipakki> which package
<tepsipakki> it's not quota the package
<seb128> no idea
<tepsipakki> kernel?
<tkamppeter> Is there any chance that OpenOffice,org will get installable again in Gutsy soon?
<tepsipakki> I'll try searching there..
<tkamppeter> For a week or so I get things like
<tkamppeter> openoffice.org-core: Depends: libcurl4-gnutls (>= 7.16.2-1) but it is not going to be installed
<cjwatson> calc: ^--
<tkamppeter> Hi, pitti
<pitti> hi tkamppeter
<siretart> tkamppeter: known as bug #124377
<ubotu> Launchpad bug 124377 in openoffice.org "[gutsy]  Trouble with package dependency (libcurl4-gnutls)" [Undecided,Confirmed]  https://launchpad.net/bugs/124377
<calc> cjwatson: yes, the new 5ubuntu1 build failed, looking into why
<tkamppeter> pitti, seems that your patch for the separation of the authentication (10_external_pam_helper.dpatch) does not close the pipes for tranfering the credentials. See my last comments on bug 112803 and on http://www.cups.org/str.php?L2438.
<ubotu> CUPS bug 2438 in Core CUPS Software "CUPS still leaking file descriptors" [Priority low,Pending] 
<ubotu> Launchpad bug 112803 in cupsys "MASTER [Feisty]  cupsd leaking file descriptors (was: Multiple jobs are not printed)" [High,Triaged]  https://launchpad.net/bugs/112803
<calc> cjwatson: failed due to some missing german translations (apparently)
<pitti> tkamppeter: ah, cool
<calc> anyone here familiar with how pkgstriptranslations works?
<tkamppeter> siretart, thanks.
<calc> i'm trying to duplicate the failure on my laptop so i can verify it isn't one of the "usual" transient ooo buildd failures :\
<pitti> tkamppeter: thanks for tracking this down
<pitti> tkamppeter: I agree about SRU worthyness
<Nafallo> calc: pitti wrote it AFAIK :-)
<calc> pitti: ping
<pitti> calc: hi
<Nafallo> morning btw
<calc> pitti: if i install pkgstriptranslations in a chroot and build ooo will it be used as on a buildd?
<pitti> calc: let me come over
<calc> pitti: ok i'm near elmo
<Nafallo> lol. right. you're on a sprint :-)
<calc> Nafallo: yep :)
<sivang> distro sprint? :)
<calc> sivang: yea
<sivang> oh cool
<Nafallo> I was a bit amazed pitti would travel for that question before I remembered you were ;-)
<sivang> heh
<calc> Nafallo: hehe
<calc> Nafallo: he's superman, fast as a bullet
<calc> :)
<Nafallo> calc: I know. he's amazing :-)
* pitti warps back to his laptop
<Nafallo> calc: take a photo for me ;-)
<sivang> heh
<Nafallo> pitti: :-)
<pitti> well, admittedly it was just some 20 meters :)
<calc> hehe
<Nafallo> pitti: I'm still sure your feet barely touched the floor ;-)
<Nafallo> carpet or something :_P
<Nafallo> :-P
<pitti> Nafallo: indeed we are on the 27th floor here, gravity is significantly weaker
<Nafallo> I hope you will have sprints in London after I've moved there ;-)
<calc> Nafallo: london is amazing :)
<Nafallo> calc: sure hope so. will be living there in the middle of august if everything goes as planned :-)
<tkamppeter> siretart, this bug report really helped, I am reinstalling OOo now.
<calc> Nafallo: move into the nice glass apt building next to the london eye
<Nafallo> calc: will need to be in Docklands, close to most of the DCs the company have customers on :-)
<Nafallo> will be able to WALK to 11 of them hopefully ;-)
<calc> i think i may have to get an apt here when i retire, heh
<Nafallo> :-)
* calc notes he isn't quite old enough to retire just yet
<Nafallo> :-)
<sivang> the Docklands area is wonderful, and you can always take a river service to Greenwich
<sivang> Nafallo: lucky you for moving there :)
<Nafallo> sivang: :-)
<calc> in make a line beginning with a : is a comment right?
<cjwatson> no ...
<gnomefreak> # is comment i thought in make
<calc> hmm i am seeing it used as what looks like a comment delimiter /me looks in make manual
<cjwatson> a command line in a rule that begins with a : is (almost) effectively a comment, but only because : is the same as /bin/true and that discards all its arguments
<cjwatson> it's sometimes used that way to get around weird parsing
<calc> hmm so maybe its used here to make it display the comment in the makefile during build more effectively (not really sure)
<calc> cjwatson: i think i have a fix for the ooo build failure, about to kick it off locally to make sure it works right
<ajmitch> great, confirmed that coreutils really does FTBFS with the version we're using in gutsy
<pitti> thom: happy birthday!!!
<tepsipakki> the quota-problem I had is in the kernel and also in gutsy (works with 2.6.17 from edgy) -> files a bug
<cjwatson> calc: neat, thanks
<thom> pitti: danke schon!
<seb128> thom: happy birthday ;)
<thom> merci bien!
<ogra> oh, happy b-day thom :)
<thom> :)
<pitti> evand: gpontecek
<Tonio_> pitti: may I ping you concerning MainInclusionReportKioUmountWrapper ?
<Tonio_> pitti: we intend to use this for gutsy so it'd be nice to get it in main quite soon for testing :)
<pitti> Tonio_: ah, I see; well, I think next week I'll have some time for it
<LucidFox> what exactly is gtkpod-aac?
<LucidFox> is it gtkpod compiled with AAC support?
<LucidFox> and in this case, why is orig.tar.gz different?
<Tonio_> pitti: great thanks :)
<LaughingMan> hi
<xxxxx1> can someone take a look at bug #123582 ? it have a pending verification-motu-needed for Feisty task.
<ubotu> Launchpad bug 123582 in gnochm "[missing dependency]  python-gtkhtml2" [Undecided,Fix committed]  https://launchpad.net/bugs/123582
<LucidFox> I need help with testing if kipi-plugins builds on gutsy with libgpod 5.2 from Debian (bug #124900)
<ubotu> Launchpad bug 124900 in libgpod "Please sync gtkpod-0.99.10, libgpod-0.5.2 from debian unstable" [Wishlist,Incomplete]  https://launchpad.net/bugs/124900
<agoliveira> I'm getting a "http://archive.ubuntu.com/ubuntu/dists/gutsy/main/binary-i386/Packages.gz was corrupt" when using debootstrap. Can anyone explain/fix that?
<Hobbsee> greetings all
<bryce__> https://bugs.launchpad.net/bugs/111257
<ubotu> Launchpad bug 111257 in xserver-xorg-video-intel "totem crashes with 'BadAlloc (insufficient resources for operation)' when using compiz and xserver-xorg-video-intel driver" [Undecided,Confirmed] 
<seb128> hi Hobbsee
<Hobbsee> hey seb128!
<sivang> what's henrik's nick?
<pygi> sivang, a lot of henrik's around :)
<Hobbsee> sivang: heno
<sivang> thanks Hobbsee :)
<Hobbsee> :)
<sivang> pygi: right, but I needed a special one :-)
<pygi> Hobbsee, you shouldn't have told him that! :p
<Hobbsee> heh, why?
<elkbuntu> sivang, you're going to tell all the other henrik's that they're not special now?
* sivang runs away
* elkbuntu throws Hobbsee after sivang
<Hobbsee> ouch!
<elkbuntu> um, Hobbsee, you do have the stick with you, right?
<Hobbsee> nightrose has it
<sivang> hehe
<elkbuntu> hey, you never lend it to me!
* elkbuntu feels dejected and goes off to cry and eat worms.
<ogra> if yu dry worms they become sticks, no ?
* elkbuntu imagines Hobbsee carrying around a dried worm.
<sivang> elkbuntu: save some worms for me as well
<Hobbsee> heh
<elkbuntu> sivang, you can have them. im too busy laughing at hobbsee carrying around a dry one
<asac> pitti: Tonio_ ... can you give this testbranch a spin and see if you get any regression when using network-manager?
<asac> pitti: Tonio_ http://bazaar.launchpad.net/~asac/network-manager/ubuntu.0.6.x-lp90267.test
<Hobbsee> hi asac
<asac> pitti: Tonio_ the patch needs some cleanup, but i would like to have a few people running it before it do that :)
<asac> Hobbsee: hi!
<Hobbsee> :)
<Tonio_> asac: I'm getting a 404
<seb128> Tonio_: you want to bzr get it
<ion_> Worksforme
<Tonio_> seb128: hum true..... I'm tired ;)
<Tonio_> asac testing
<Tonio_> asac: looks like working correctly here
<Tonio_> asac: btw I use kde, I can't test if that fixes the problem with the gnome applet
<asac> Tonio_: gnome applet is not what matters ... what kind of things are you testing?
<asac> Tonio_: can you do a reboot and stuff like that? pluggin in and out multiple network interfaces?
<Tonio_> asac: sure, but it'll take a moment, I can't reboot right now
<Tonio_> asac: I'll give you feedback toonight
<asac> Tonio_: no problem i try to get feedback from a few more as well
<asac> Tonio_: as this patch is not a one liner
<asac> :)
<Lure> asac: does it fix "no network after reboot" issue?
<asac> Lure: do you have a bug?
<Lure> asac: not really - just noticed that sometimes after reboot I need to restart n-m in order to get wired connection
<asac> Lure: if you can reproduce that problem, maybe you can try that branch? there are other not-yet released patches in there that might help for some cases
<Lure> asac: otherwise it thinks it is offline
<Lure> asac: ok, will try it out
<asac> Lure: do you have something in your /etc/network/interfaces ?
<Lure> asac: everything is on auto
<asac> you can paste somewhere?
<pitti> asac: downloading
<Lure> asac: http://paste.tonio.homelinux.org/323
<Lure> asac: eth0 is wired and when I am plugged in it is listed as shaded (disabled?) after reboot
<Lure> asac: n-m restart does reenable interface and gets IP from dhcp
<asac> Lure: ok ... maybe its related to the race condition fix i added
* Lure is not sure when I got all these interfaces - I only have eth0 (tg3) and eth1 (ipw2200)
<asac> Lure: especially if you cannot reproduce always it might indeed be some race condition
<asac> Lure: actually you should not need any entry for eth0 et al in interfaces for it to work
<Lure> asac: it is not always but very often (75%)
<asac> Lure: yeah ... so you should be able to see if its gone by doing a few reboots :)
<Lure> asac: I know, I am just suprised where I got eth2, ath0 and wlan0
<macbeth> Hi everyone!
<macbeth> Todays openoffice update, from 2.2.0-1ubuntu3 to 2.2.0-1ubuntu4 broke it...
<Tonio_> Lure: you should ping mbiebl when he is arround about that issue, he was looking forward to fix it last time we discussed
<macbeth> Anyone has the same problem?
<asac> Lure: no idea where those entries might have come from
<Lure> Tonio_: that is different issue: knetworkmanager does not re-connect to wpa network and the fix is already in knetworkmanager sources I think
<Lure> Tonio_: so it should be in 0.2 release
<Tonio_> Lure: hum interesting...... shouldn't we try the fix ?
<Tonio_> Lure: I can rebuild from svn
<Hobbsee> please do
<Lure> Tonio_: we could - fix is in svn , I just checked: http://websvn.kde.org/branches/extragear/kde3/network/knetworkmanager/src/knetworkmanager-encryption.cpp?view=log
<Tonio_> Lure: let's go ;)
<cjwatson> pitti: do you care if I dump livecd-rootfs into main, seeing as we're already running it on our buildds? :-)
<pitti> cjwatson: can you see me?
<cjwatson> pitti: yes
<asac> Lure: let me know when you have tested :)
<cjwatson> iwj: http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/gutsy/ubuntu/
<Lure> asac: still same issue with your test package
<Lure> asac: but at least there are no gnome depends anymore (Tonio_'s fix works)
<Lure> asac: will report proper bug now
<login_> Hi guys , i have a question for the developers, I am making an ubuntu deriative but i came into troubles when i compiled my own kernel . My pc needs to do acpi=off to boot but ounce i boot , no usb slots are detected . This happens on every other OS except ubuntu , I wanted to ask what patches are you added t othe kernel or what did you do to it to make it not have to do acpi=off or make it detect my usb 2.0
<login_> slots?
<login_> anyone have an anwser to my  problems?
<ScottK> login_: There's a developer sprint this week, so no one may be paying attention.  You should probably be in #ubuntu-kernel, but the same people are probably too busy to answer you there too.
<Tonio_> Lure: knm fix works, uploaded
<Lure> Tonio_: cool
<login_> thanks , i wil lask there too
<login_> Hi guys , i have a question for the developers, I am making an ubuntu deriative but i came into troubles when i compiled my own kernel . My pc needs to do acpi=off to boot but ounce i boot , no usb slots are detected . This happens on every other OS except ubuntu , I wanted to ask what patches are you added t othe kernel or what did you do to it to make it not have to do acpi=off or make it detect my usb 2.0
<login_> slots
<persia> login_: Didn't you ask the same question an hour ago?  Also, this week is probably not good for these things.  You may get a better response from sending an email.
<xxxxx1> algum ubuntu-dev brasileiro aqui? se tiver favor me chamar em private. obrigado.
<RickH> Where can I find GTK+ documentation?  Like to learn about "gtk_window_new()" and GtkWidget*, etc.?
<oni> hi is this the right channel to ask why vim is not installed by default?
<ScottK> oni: Because they need every byte they can squeeze out to fit on the CD so they just install vim-tiny.
<superm1> vim-tiny is a dependency of ubuntu-minimal, so even a minimum console install will install it
<minghua> RickH: libgtk2.0-doc package.
<RickH> minghua:  Thanks.
<RickH> Is there a FAQ somewhere about beginning development with GTK+
<RickH> ?
<oni> ok thanks
<ScottK> RickH: It's really not an Ubuntu specific development question.  I suggest Google.
<RickH> ScottK:  I'm surprised at that.  I would think developing under Ubuntu would encompass all of the tools available for developing in Ubuntu.
<ScottK> RickH: See the topic.
<RickH> ScottK:  I think that's misleading (having a channel named like this, and only doing physical development of Ubuntu).  I think that confusion is backed up by the fact that the topic has to clarify the same. :(
<RickH> ScottK:  where should I go for doing developing under Ubuntu, but not of Ubuntu?
* ScottK doesn't work here, so isn't the right person to discuss it with.  In your case I'd look for a gtk specific channel.
* RickH nods
<cprov> Can I have some help with https://bugs.launchpad.net/ubuntu/+source/ghostscript/+bug/125316 ?
<ubotu> Launchpad bug 125316 in ghostscript "Ghostscript is eating all my memory when opening the attached file " [Undecided,New] 
<cprov> 'eating' is disturbing ... edited ...
<lamont>  /usr/bin/ld: e-map/libemap.a(libemap_a-e-map.o): relocation R_PARISC_DPREL21L can not be used when making a shared object; recompile with -fPIC
<lamont> BAD gnome-panel
#ubuntu-devel 2007-07-12
<Tonio_> asac: just did a lots of tests with network-manager, everything's fine here
<calc> ooo build sucks
<calc> i made like a 2 line change and it fails to build on amd64
<calc> 5ubuntu1 passed on amd64 and failed on 5ubuntu2
<calc> there must be some kind of timing screw up in the build system when used in make -j# mode
* ScottK had a package build in both Sid and Gutsy pbuilders, build on the Debian buildd, and then FTBFS on the Ubuntu buildd today.  
<calc> cool someone already threw it back to retry
<calc> ScottK: which package?
<ScottK> pypolicyd-spf
<ScottK> It's fixed now.
<calc> ScottK: is it fairly simple build wise?
<ScottK> Very.
<Mithrandir> spf is crack anyway. :-P
<calc> hmm i wonder if there might be something slightly wrong with the buildds then, of course ooo is so complicated it is hard to tell when it fails if it is a buildd issue or a ooo build system problem
<calc> i'm thinking its mostly due to ooo being crack
<ScottK> Mithrandir: Sure it is, but the alternatives are currently worse.
<Mithrandir> calc: it's probably just the ooo build system not being good; the buildds break every now and then, but they're not generally broken.
<Mithrandir> ScottK: DK might be good.
<calc> true
<ScottK> My problem was due to taking a stupid shortcut that apparently usually works.
* calc is talking to Mithrandir on irc while sitting 2 feet from him, lol
<Mithrandir> you're not sitting.
<Mithrandir> especially given that what the buildds do is, by definition, correct.
<ScottK> Mithrandir: In my testing DK is VERY implementation depenent.  DKIM Is more robust, but currently lacks a policy component to make it generally useful.
<Mithrandir> ScottK: maybe; I haven't actually tried them.  I've just read the specs and, well, spf doesn't really win you anything.
<ScottK> In the end I think the right answer will be a combination of the two approaches.  It happens that DKIM works well where SPF is weak and vice versa.
<ScottK> Mithrandir: In my case it got my personal spammers to quit forging my domains.
<calc> turning on the two flags on my debian mail seemed to help reduce spam some (forgot what they were now though)
<ScottK> It's more of a benifit for the sender than the receiver.  That's one of the challenges.
<Mithrandir> ScottK: then just use bounce address signing.
<ScottK> Mithrandir: Where do I apt-get install stuff to do that?
<calc> the best part was just moving my debian email to a separate forward address and unsubscribing from all the high traffic lists
<calc> so i have only gotten 2200 emails from them in 3-4 months
<ScottK> That's a solution to not see the bounces, but doesn't do much for getting the spammers to leave your name alone.
* ScottK needs to go cook dinner.  See you later.
<calc> a lot of the "spam" i get to my debian email address is bounces from stupid servers that don't know that they should be dropping the emails instead of rejecting them at initial receive time
<Mithrandir> ScottK: http://tldp.org/HOWTO/Spam-Filtering-for-MX/exim-sign.html
<ScottK> In short, SPF sucks, but nothing better is mature.
<Mithrandir> SPF requires the other end to care, sender signatures doesn't
<ScottK> True, but in practice enough receivers care to provide some deterrent effect.
<ScottK> The current bounce address stuff only works if MSA is also the MX.  It's not a scalable approach yet.
<ScottK> Gotta run.
<Mithrandir> MSA?
<ScottK> Mail Submission Agent (sending MTA).
<Mithrandir> or you give it a key which is valid
<calc> Mithrandir: envelope sender helps you to not get spam, or to not be marked as spam?
<Mithrandir> calc: to not get joe-jobs.
<calc> Mithrandir: ah ok
<Mithrandir> so you don't end up getting bounce spam, or at least less of it.
* calc wishes webhosts would use more of this stuff
<calc> if cpanel would implement it then webhosts would just roll it out automatically
* enyc just interested... not wishing to create an argument...  ;-) --  if anybody had considered  supporting some more modern (than bind) better-design-practices  FOSS  dns programs in main,  e.g.  pdns-recursor, nsd...  ;-)
<calc> http://cpanel.net/index.html is what most webhosts (at least in the US) use for their servers
<calc> not sure about what is used internationally
<ScottK> Interesting you say in the US since it's developed in Russia.
<calc> ScottK: eh?
<calc> ScottK: they have their main office in Houston (afaik)
* enyc not sure how things go main>universe and universe>main ...
<ScottK> Maybe I'm thinking of one of the others.
<calc> ScottK: saw job offers for them a few months ago
<calc> ScottK: it may be they have offices other places as well
* ScottK remembers.  It's plesk I was thinking of.
* enyc waits ;-)
<calc> ah yea plesk is the other big competitor
<Mithrandir> enyc: I think bind9 is fine, tbh
<enyc> Mithrandir: hrrm its complicated and situation-dependant ;-) really
<enyc> Mithrandir: I can tell you why i dont like bind9 if you would like. or not, ;-)
<Mithrandir> enyc: I don't care deeply, but I think calling bind9 "not modern" is kinda wrong.  It's in no way obsolete, it's very much used for many, many hosts and compared to the other DNS servers, lots more people know how to configure it.
<ScottK> enyc: There's https://launchpad.net/ubuntu/+source/pdns
<calc> but... it runs on linux which is a kind of unix which is not modern either... ;-P
<calc> lol
<Robot101> pdns is an ass
<Mithrandir> hiya little robot
<Robot101> bleep :)
<enyc> Mithrandir: sure.. its also "been around a long time" and hence has lots of features
<enyc> Mithrandir: by "modern" I think I am thinking of the design decision sort of methodology
<ajmitch> enyc: and your suggested replacement is?
<enyc> Mithrandir: i am sure that separate recursor and authoritative is almost always the "right way" to design your dns architecture... and ''never designed'' dns tools seem to keep recursor and auth separate procceses entirely....
<enyc> ajmitch: as usual in the world  there is no "right answer" for every situation ;-)
<Mithrandir> enyc: I don't see a big point in separating authorative and recursive servers.
<Mithrandir> they're 90%+-ish the same code
<enyc> ajmitch: bind9 is rather less DoS prone if 'recursion' is off entirely...  Also many exploits have required recursion to wkr...    if you dont need views nsd works well imho  ... but its only my opinion
<enyc> pdns-recursor has  neither the "no query restart" bind-recurisor problem nor the "try to find all the nameserver addresses before querying them" problem... and notices ICMP unrches
<enyc> but there you go
<enyc> long story ;-)
<enyc> Mithrandir: its usually a matter of security.. if you have a separate listen IP that is only reacable to authorized clients... stops others using your recursor to bounce "large packet replies"  ... also much reduces the chance of an exploit/attach poisoning/affecting data in the "other direction"
<enyc> Mithrandir: also note bind will reply (even from a SOURCE ip not allowed recursion) with anything it *knows* about... and hence you can snoop on if the other end is looking up things etc...
<enyc> Mithrandir: which you may or may not care about
<Mithrandir> enyc: no, it doesn't.
<Mithrandir> enyc: if you set up your views correctly, it doesn't do that.
<enyc> Mithrandir: you can setup a view with "recursion no"....
<Mithrandir> which is what you'd do for external networks
<enyc> Mithrandir: how do you set it to not reply with anything non-authoritative at all?
<enyc> Mithrandir: do you have an example server set as such ?
<Mithrandir> yes, but I'm firewalled out of it from my current physical location
<enyc> Mithrandir: anyway...how do you setup a view such that bind9 will not actually ansower with 'anything it knows about' under 'recursion no' ?
<Mithrandir> views have different caches in modern bind9 versions
<Mithrandir> if not, split-horizon would be very hard to set up
<enyc> Mithrandir: right... makes sense
<Mithrandir> iirc it was shared for a while, then I told lamont how bad an idea that was and it was fixed
<calc> dnsreport.com will tell you if you are configured way off as far as being open, etc
* keescook <3 dnsreport
<enyc> Mithrandir: yes... the horizon whatnot would have to be very careful about which zones have different data.......
<enyc> Mithrandir: bug prone mess
<Mithrandir> hence why it makes much more sense to just not share it
<enyc> Mithrandir: hrrm... i wonder if bind devs are ever going to take the 'compiled zone-data' idea of pdns+nsd+tinydns  in never versions....
<ScottK> Of course if you want "Only the RFCs I feel like implementing DNS", there's djbdns.
<ScottK> keescook: Did you see my clamav question on #ubuntu-motu?
<enyc> currenly a syntax error causes (in by experience) bind to SERVFAIL queries on a zone.... rather than complaining at 'compile time' without disrupting service
<enyc> but maybe theres some workaround to this i dont know about
<enyc> ScottK: ;-)  ... which is also not FOSS  really
<ScottK> Well, that too.
<enyc> anyway
<ijuz_> i don't want to make advertisement... put powerdns is the one! you should throw bind out of the repository :)
<enyc> i didnt really want to talk about dns for ages ;-)
<enyc> I wanted to know if anybody had considred any of these "more modern designed" (but not so long in use)  FOSS dns tools  like NSD/pdnsd  for main rather than univers...  ive never really understood how the main>universe  universe>main  moves work anyway q-)
<enyc> ;-)
<enyc> ijuz_: I dont think anything fits all circumstaces perfuctly....
<keescook> ScottK: ah, yeah, I'd go for the highest upstream version, they have other non-security updates in their micro-versions.
<Fujitsu> Mithrandir: Can you please give back hdbc-{odbc,postgresql,sqlite3} on all archs?
<ScottK> keescook: OK.  Thanks.
<Hobbsee> greetings
<ScottK> Greetings earthling.
<Fujitsu> Morning.
<Fujitsu> Hm, afternoon.
<Hobbsee> :)
<Fujitsu> Has anybody ever struck something being synced, and then vanishing? seb128 synced r-base yesterday, but the source seems to have been eaten...
<sbalneav> Something going on with libcurl3-gnutls vs libcurl4-gnutls?
<Hobbsee> yeah.  it's dead.
<persia> sbalneav: Not anymore: libcurl4 is dead.
<sbalneav> Hm
<sbalneav> but if I try to install libcurl3, it's going to yank out all the openoffice suite
<Hobbsee> ooo has to actually build, to fix that
<Fujitsu> OOo has been FTBFSing.
<Fujitsu> As it does.
<Fujitsu> It is pure evil, but does build occasionally.
<sbalneav> ah, ok
<sbalneav> so ditch -4, go back to three, and OOo will come back....
<sbalneav> ... eventually :)
<Fujitsu> The libcurl[34]  thing was a bit of a disaster... you're not meant to pull out transitions half-way, generally.
<Fujitsu> *pull out of
<sbalneav> thanks Hobbsee, Fujitsu and persia
<Hobbsee> no problem
<Fujitsu> No problem.
<sbalneav> np, I'm just plunking away on the ltsp specs, but I try to keep my devel box here as u
<sbalneav> p to date as possible :)
<sbalneav> "return to your work, citizens.  All is well"
<StevenK> Fujitsu: Not our fault, though. :-/
<mneptok> wait. libcurl3 breaks ooo-build?
<ScottK> mneptok: Don't ask.
<Fujitsu> mneptok: No. OOo breaks OOo-build.
<Hobbsee> greetings, mneptok
<Fujitsu> It only builds when the planets are perfectly aligned, and it needs to be rebuilt for the untransition.
<mneptok> ok, so this is not the month to mess with mmeks :)
<mneptok> *mmeeks
* mneptok coats Hobbsee in molassess and ennui
<Hobbsee> yummy!
<mneptok> it tastes good, but ... whatever.  ;)
<TheMuso> haha
* netjoined: irc.freenode.net -> kubrick.freenode.net
<superm1> hi guys, is there some certain level of magic to using the debconf python module?
<superm1> every time i try to initialize it, it spits back a "VERSION 2" on the console and hangs
<StevenK> I presume it's waiting for input, actually.
<superm1> that assertion seems to be right
<superm1> how can it work non interactively then?
<Mithrandir> Fujitsu: given-back
<Hobbsee> morning Mithrandir!
<Fujitsu> Mithrandir: Thanks, and morning.
<Mithrandir> morning, Hobbsee!
<Fujitsu> Mithrandir: Are you able to look at the r-base sync? It seems to have jumped into the Soyuz black hole.
<Mithrandir> Fujitsu: can it wait until I am a) out of bed, and b) at the office?
<Fujitsu> Mithrandir: Ah, of course.
<Hobbsee> heh, Mithrandir's picked up the nasty habit of IRCing from bed now?
* Hobbsee wonders just how many people started doing that in spain
<Mithrandir> Hobbsee: I used to do it a long time ago, but then stopped for a while
* Fujitsu does it when it's winter and it's too darn cold to not be in bed.
<Hobbsee> heh
<seb128> pitti_: https://bugs.launchpad.net/ubuntu/+source/openoffice.org/+bug/125400
<ubotu> Launchpad bug 125400 in openoffice.org "[MASTER]  package openoffice.org-common 2.2.1-5ubuntu2 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [High,Confirmed] 
<Fujitsu> seb128: Any idea what went wrong with bug #124816?
<ubotu> Launchpad bug 124816 in r-base "Please sync r-base (universe) from Debian unstable (main)" [Wishlist,Confirmed]  https://launchpad.net/bugs/124816
<seb128> Fujitsu: looking
<Hobbsee> morning seb128, pitti
<Fujitsu> seb128: Thanks.
<pitti> hey Hobbsee
<seb128> hey Hobbsee
<Fujitsu> Morning pitti.
<StevenK> Morning pitti.
<StevenK> pitti: Can I stea^Wborrow some of your time for NBS'ing a bunch of stuff?
<pitti> StevenK: sure
<pitti> StevenK: I just gave back d-i, once that built, I can kill all the 2.6.22-7 stuff
<StevenK> Ah, cool.
<StevenK> pitti: Firstly, I have dealt with libflac++5, so it can be killed.
<Hobbsee> die libflac++5, die!
<StevenK> pitti: I was going to get you to kill everything that's empty on NBS/, but that can wait until d-i is built.
* Mithrandir chews libflac++5's leg
<Mithrandir> mmm, software
<Fujitsu> Mithrandir: Yummy.
<Mithrandir> not as good as brains, but still quite good
<Hobbsee> Mithrandir: i thought there was real food in london...
<StevenK> Braaaaaains
<Hobbsee> mmmmmm.....brains.....
<Hobbsee> *eyes turn red*
<Mithrandir> Hobbsee: there is
* Fujitsu runs.
<Hobbsee> Mithrandir: just that you still want to eat libflac++5's leg too
* Hobbsee spears Fujitsu with the Long Pointy Stick of DOOM!!!!!!!!!!!!!!! 
<Fujitsu> Aw...
<StevenK> pitti: Secondly, I've done everything I can for libflac7, but ecasound and scummvm are still listed as deps for ia64 - this is due to ghostscript SEGV'ing on ia64 and causing the build to fail - do I/we care?
<StevenK> pitti: And mythmusic is on sparc, due to mythtv now appearing in P-a-s and being excluded on sparc.
<Hobbsee> morning dholbach
<dholbach> hi Hobbsee
<Fujitsu> Thanks seb128 (I presume)
<pitti> StevenK: so we need to remove mythtv from sparc?
<seb128> Fujitsu: you're welcome, I don't know why it didn't work yesterday
<StevenK> pitti: Presumably. I'm not certain why it was added.
<StevenK> pitti: d-i just failed to build on all arches.
<pitti> again?
<StevenK> Yup. The latest try was 13 minutes ago.
<pitti> fabbione: ^
<StevenK> Building dependency tree...
<StevenK> E: Couldn't find package ubuntu-modules-2.6.22-8-generic-di
<StevenK> make[7] : *** [stamps/get_udebs-netboot-stamp]  Error 100
<pitti> aah, I just newed that
<pitti> not on all arches, though
<fabbione> pitti: did you new ubuntu-mods?
<fabbione> eh ok
<Fujitsu> Why was -image NEWed when -ubuntu-modules wasn't?
<pitti> Fujitsu: lum b-deps on the headers
<Fujitsu> Oh, I didn't realise it was a separate source.
<fabbione> pitti: sorry i thought you already NEW?ed lum stuff
<pitti> fabbione: however, i386 lum is still missing
<fabbione> pitti: mind to ride the beast?
<pitti> fabbione: I think BenC is at it
<fabbione> pitti: uh?...
<asac> Tonio_: ok thanks ... will clean a bit up and upload then
<fabbione> pitti: i am in the other room, can you poke Ben?
<BenC> fabbione: it's not lum that's the problem
<BenC> the xen custom binary in linux-source-2.6.22 didn't build for some reason
<fabbione> feh
<fabbione> so it?s another kernel upload?
<fabbione> pitti: how painful is it for you to still let the sparc installer to build once lum is in?
<pitti> fabbione: not at all
<fabbione> pitti: there is a kernel feature i need to test in combo with the installer
<fabbione> pitti: that?d be lovely
<fabbione> pitti: thanks
<Fujitsu> fabbione: What's eating your quotes?
<fabbione> Fujitsu: ?
<Hobbsee> calc: OOPS, YOU BROKE IT!!!!
<calc> Hobbsee: eh?
<Hobbsee> calc: you currently have 13 dupes.
<calc> Hobbsee: what did i break?
<Hobbsee> calc: what you uploaded.
<calc> hmm what i uploaded was just a small fix for what doko previously uploaded the day before, bug #?
<Mithrandir> Setter opp openoffice.org-common (2.2.1-5ubuntu2) ...
<Mithrandir> Updating OpenOffice.org's dictionary list... done.
<Mithrandir> No theme index file in '/usr/share/icons/locolor'.
<Mithrandir> If you really want to create an icon cache here, use --ignore-theme-index.
<Mithrandir> dpkg: Feil ved behandling av openoffice.org-common (--configure):
<Hobbsee> Mithrandir: yeah, that's the one
<Mithrandir> you failed to test your change.  Bad calc!
<Mithrandir> :-P
<calc> Mithrandir: i think that is "fixed" now by a new debhelper upload
<calc> Mithrandir: it installs on my box just tried this morning
* calc thinks dh_iconcache might have been buggy
<Mithrandir> uh, debhelper isn't going to change what's in the archive already.
<calc> hmm yea that is true, so why did it work for me? :\
<Mithrandir> and this is from about 30 minutes ago
<calc> ii  openoffice.org-common             2.2.1-5ubuntu2                             OpenOffice.org office suite architecture ind
<calc> installed fine on this box
* ajmitch should probably rigourously test coreutils before uploading this evening
<calc> got to run to the distro meeting, bbl
<pitti> calc: amd64 retry worked, btw \o/
<pitti> calc: I retried it on powerpc
<Tonio_> asac: please do ;)
<Tonio_> asac: I can't be sure to have tested everything, but switching between several networks, using wep or wpa, rebooting, and performing an openvpn connection works like a charm
<Tonio_> asac: I just hope there is not a hidden regression I missed
<asac> Tonio_: Tonio_ ok uploaded
<asac> Tonio_: branch is updated as well
<pygi> seb128, around?
<seb128> pygi: sort of, in the middle of a meeting, just ask your question ;)
<pygi> seb128, ah, everyone's in the meeting, I'll bug later then
<seb128> pygi: just ask
<pygi> seb128, I need sponsoring :)
<seb128> pygi: I might reply now if that's a quick one
<seb128> k, so for later ;)
<pygi> hehe, indeed
<Hobbsee> pygi: what for?
<pygi> Hobbsee, brasero
<pygi> Hobbsee, working on k3b as we speak
<Hobbsee> neat
<seb128> pitti: could you run the NBS update now?
<pygi> Hobbsee, you'r gonna sponsor that, righ?
<Hobbsee> pygi: i think there's dinner, adn i dont know anything about brasero codebase.
<pygi> Hobbsee, I thought k3b ^_^
<Hobbsee> ah right
<Hobbsee> should do.  Tonio_'s also around
<pitti> seb128: yep
<seb128> pitti: danke
<Tonio_> pygi: good point, debian k3b maintainer is okay to merge all my packaging changes and switch to cdbs :)
<Tonio_> pygi: we'll probably maintain it together now
<pygi> Tonio_, rok on :)
<pygi> rock*
<pygi> Tonio_, so I'm useless from now on :)
<pygi> Tonio_, if you want tho,  I can still help around :)
<Tonio_> pygi: sure :)
<Hobbsee> Tonio_: rock on!
<Hobbsee> pygi: that means you can still patch the debian package.  nothing wrong there
<pygi> Tonio_, yay!
<pygi> Hobbsee, I know, I know, but still ... :)
<Hobbsee> :)
<Hobbsee> go on
<pygi> patch 111!
<pygi> Hobbsee, Tonio_ : who wants the debdiff and how? Mail?
<Hobbsee> Tonio_: does.
<Hobbsee> i need to actually get my butt into gear and do stuff like a resume.
<Hobbsee> and dinner
<pygi> Hobbsee, oki
<pygi> Tonio_, poke
<pygi> :)
<cjwatson> superm1: if you're using debconf.py in a context where there might not be a frontend already running, you need to call debconf.runFrontEnd() at the top of your script
<Hobbsee> morning cjwatson
<Riddell> keescook: don't forget strigi :)
* Hobbsee watches the dupe count rise
<cjwatson> morning
<Hobbsee> yay, people who clearly havent heard of the search button
<pitti> seb128: NBS done, btw
<pygi> hey pitti
<seb128> pitti: yeah, I've noticed, the list ist shorter now
<pitti> hi pygi
<seb128> pygi: where is the brasero package to sponsor?
<pygi> seb128, persia is on it now, I assigned the ubuntu-universe-sponsors
<pygi> subscribed*
<seb128> pygi: ok, good
<pygi> Tonio_, k3b is subscribed to u-m-s
<calc> back
<calc> pitti: thanks! :)
* calc built a new chroot to see if ooo fails to install a second time
<calc> dholbach: i have a freshly built chroot than installed ooo fine, and shows no errors, not sure if you are interested in looking at the machine?
<calc> s/than/that/
<dholbach> calc: does /usr/share/icons/locolor contain anything?
<dholbach> calc: which version of debhelper was used in that build chroot?
<calc> no index.theme
<calc> neither does /usr/share/icons/gnome though
<calc> actually for that matter neither does hicolor
<dholbach> calc: might be interesting to see if the .postinst files contain dh_icons or dh_iconcache
<calc> none of the three have an index.theme
<dholbach> you don't have {hicolor,gnome}-icon-theme installed?
<calc> # Automatically added by dh_icons
<calc> if which gtk-update-icon-cache >/dev/null 2>&1; then
<calc>         for dir in /usr/share/icons/hicolor /usr/share/icons/locolor /usr/share/icons/gnome; do
<calc>                 gtk-update-icon-cache --force --quiet "$dir"
<calc>         done
<calc> fi
<calc> # End automatically added section
<calc> icon-themes are not installed
<calc> i did a fresh chroot and just did an apt-get install openoffice.org
<dholbach> right, that's why - kubuntu does not seem to want to install them
<dholbach> ahhh!!!
<calc> huh?
<dholbach> you don't have libgtk2.0-bin installed
<dholbach> so you don't have gtk-update-icon-cache
<dholbach> if which gtk-update-icon-cache >/dev/null 2>&1; then
<dholbach> ^ FALSE
<calc> oh, oops!
<dholbach> :-)
<dholbach> there you go
<calc> should there be some kind of replacement dep in control so that gets added automatically?
<dholbach> no no
<calc> ok
<dholbach> the icon cache is only of use for gnome / xfce (people who use gtk)
<calc> i'll retry with libgtk2.0-bin installed and see how it goes
<dholbach> so kde people don't need libgtk2.0-bin installed
<calc> ok
<calc> yipee i made openoffice not install on my test system too! :)
<calc> now i need the Contents files for the whole repo so i can look through them for locolor stuff
<Riddell> calc: why on earth is openoffice using locolor?
<StevenK> pitti: If you're waiting for the kernel/d-i stuff to get sorted out being cleaning out NBS, could you at least kick parrot and glew out of NEW?
<Nafallo> pitti: could you please tell apport so use a sane webbrowser? I use epiphany as default and it tries to use firefox.
<Nafallo> pitti: which doesn't respond since my LA is currently VERY high.
<Nafallo> so you miss out on bugreports atm ;-)
<pitti> hm, I thought I fixed that ages ago
<pitti> Nafallo: gconftool --get /desktop/gnome/url-handlers/http/command
<pitti> Nafallo: ^ for you?
<pitti> Nafallo: it starts that one if it exists
<Nafallo> epiphany --new-tab %s
<pitti> Nafallo: what does "gnome-open http://www.ubuntu.com" do for you?
<StevenK> Oh, drat. qa.debian.org is down because Fort Collins is off the Intraweb
<Nafallo> pitti: new tab in epiphany
<pitti> Nafallo: hmm
<pitti> Nafallo: it's supposed to use that
<Nafallo> well. it isn't
<Tonio_> pygi: yes, please don't merge it
<Tonio_> pygi: as I said, k3b will merge ubuntu changes in the next days, so please don't sync with debian
<pygi> Tonio_, I wasn't merging with debian?
<pygi> I just created a patch for k3b ubuntu-specific
<Riddell> mvo: i get /usr/bin/compiz.real (core) - Error: Can't load plugin 'ccp' because it is built for ABI version 20070606 and actual version is 20070706
<ogra> Riddell, replacing kwin ? :)
<Riddell> ogra: trying to
<ogra> wow, really ?
* ogra wasnt serious
<Riddell> ogra: not by default, but I want compiz/kde integration to be nice and smooth
<ogra> cool !
<Amaranth> Heh, I can't help with problems like that
<hunger> openoffice.org-common does not install here.
<gnomefreak> hunger: its known
<hunger> gnomefreak: Great, then I do not need to use launchpad;-)
<gnomefreak> hunger: assuming you are on gutsy ;)
<mvo> Riddell: right, it needs later compiz-fusion-plugins-main, those are build now, should be available shortly
<gnomefreak> mvo: they are available already i think
<gnomefreak> yep
<pitti> fabbione: d-i/sparc is happy, btw
* Hobbsee wonders if this openoffice bug will end up having mroe dupes than the dapper security X breakage bug ever did
<Hobbsee> one thing's for sure - we need auto duping!
<pitti> Hobbsee: right, no autoduping for package install failures yet
<Hobbsee> pitti: damn
<Hobbsee> pitti: 29 dupes.
<StevenK> Niiice
<persia> Hobbsee: 29 for each package, or 29 total?
<Fujitsu> Hobbsee: Bug number?
<Hobbsee> Fujitsu: bug 125400
<ubotu> Launchpad bug 125400 in openoffice.org "[MASTER]  package openoffice.org-common 2.2.1-5ubuntu2 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [High,In progress]  https://launchpad.net/bugs/125400
<StevenK> pitti: d-i/ia64 failed again.
<Hobbsee> persia: 29 total
<ogra> Hobbsee, thats nothing :)
<Hobbsee> no, but there will be more on update-manager
<ogra> right
<StevenK> There was some Gnome bug during Feisty development that had like 113 dupes.
<Hobbsee> ogra: that's just in half a day.  and it's gutsy, so we shouldnt have that many users
<Hobbsee> and most of the bugs are crap anyway - they'd all need more info
<ogra> we had bugs before that were in the hundrets after a days (like StevenK said)
<ogra> *a day
<pygi> Hobbsee, did you look at bug?
<Hobbsee> pygi: at which bug, sorry?
<Hobbsee> ogra: true
<pygi> Hobbsee, https://bugs.launchpad.net/ubuntu/+source/k3b/+bug/121877
<ubotu> Launchpad bug 121877 in k3b "K3b doesnt prompt the user to install kubuntu-restricted-extras for codecs" [High,Confirmed] 
<Hobbsee> mvo: i'm not sure if i told you - you are right
<Hobbsee> @ the metapackages for universe/multiverse
<Hobbsee> pygi: and i thought Tonio_ was uploading all that to debian.  although that bit would require a merge, i guess
<pygi> Hobbsee, ah, ah, yes, indeed
<pygi> Hobbsee, o well
<Tonio_> Hobbsee: yup, in fact the debian k3b maintainer wants to swtich the packaging to cdbs as I did, so we'll probably maintain it together on alioth
<Tonio_> Hobbsee: so the idea is to NOT merge with debian at the moment :)
* thom struggles with the idea of anyone wanting to use cdbs, as usual
<Tonio_> concerning the bug, I'm adding this to my todo, that would be usefull, indeed
<persia> thom: Why?
<Tonio_> Hobbsee: I'll do that this WE
<pygi> Hobbsee, ignore then :)
<Hobbsee> Tonio_: right
<Hobbsee> Tonio_: i can upload it, if you're busy.
<Tonio_> Hobbsee, pygi:in fact I'm doing this right now ;)
<Hobbsee> Tonio_: just didnt want to give you more stuff to merge/deal with, i fyou didnt want to
<Hobbsee> ahh, okay, excellent
<Tonio_> Hobbsee: I already launched the build, don't mind :)
<Hobbsee> :D
<Tonio_> Hobbsee: I hope you synced my changes with kdelibs
<Tonio_> Hobbsee: are you able to commit now ?
<Hobbsee> Tonio_: havent even looked - was off having dinner
<Tonio_> Hobbsee: oki :)
<Hobbsee> Tonio_: do you have more stuff that you want to add?
<pygi> Tonio_, whatever you want, as long as this fix is in :P
<Tonio_> Hobbsee: nope, except the zoom effect speed change from 5 to 3, that's all :)
<Hobbsee> Tonio_: which is the one committed, right?
<Tonio_> Hobbsee: and of course _Stefans_ patch for kdesudo
<Tonio_> Hobbsee: true
<Hobbsee> Tonio_: yep, yep, got them :)
<Hobbsee> will pick them both up
<Tonio_> Hobbsee: great :)
<Hobbsee> Tonio_: i'm procrastinating again, cant you tell?  :)
<Tonio_> Hobbsee: would be nice to have kdesudo not only working better than kdesu, but also blinking a lot more hehe
<Hobbsee> Tonio_: but, i do want to go thru the bugs at some point, too
<Tonio_> prowhat ?
<Hobbsee> indeed!
<Hobbsee> procrastinating
<Tonio_> which means ?
<Hobbsee> try "dict procrastination"
<Hobbsee>   procrastination
<Hobbsee>        n 1: the act of procrastinating; putting off or delaying or
<Hobbsee>             defering an action to a later time
<Hobbsee> 2: slowness as a consequence of not getting around to it
<Tonio_> Hobbsee: oki ;)
<Hobbsee> Tonio_: blob wars calls :P
<Tonio_> that's an ugly word, for sure :)
<Hobbsee> nah, it's a lovely word!  so's antidisestabilishmentarianism.
<Riddell> mvo:   compiz-fusion-plugins-main: Conflicts: compiz-compcomm-plugins-main (< 0.0.0+git20070622-0ubuntu1) but 0.0.0+git20070612-0ubuntu1 is to be installed
<pitti> mathiaz: http://dehs.alioth.debian.org/
<pitti> http://dehs.alioth.debian.org/no_updated.html
<Riddell> mvo: I have new compiz-fusion-plugins-main but it still gives me Can't load plugin 'ccp' because it is built for ABI version 20070606
<seb128> Riddell: what version do you have?
<Riddell> seb128: compiz-fusion-plugins-main 0.0.0+git20070711-0ubuntu2
<seb128> mvo: ^
<seb128> mvo told me this version was supposed to fix it
<WorkingGeier> hi
<fabbione> pitti: yes i noticed.. thanks. waiting for mirrors to propagate
<WorkingGeier> what is the best way to create a (minimal) Ubuntu mirror covering all releases that is sufficient for debootstrapping?
<pitti> WorkingGeier: => #ubuntu; hint: debmirror and filtering on priority
<WorkingGeier> pitti, that's what I did, however required+standard is not enough
<WorkingGeier> (vim is missing for instance)
<asac> pitti: what about dbus 1.1 ?
<pitti> WorkingGeier: vim is not necessary for debootstrap
<evand> anyone use listadmin?  What do you use for (base64) encoded messages?
<WorkingGeier> it tries to load it though
<bryce_> seb128: could you also sync xserver-xorg-video-amd?  There is a new release yesterday that debian has packaged.
<pitti> WorkingGeier: only warty and hoary required vim
<wwoods> pitti: hey, about the server-side bits of apport - do the crash reports go into a (searchable) database at all, or are they just unpacked into files?
* wwoods was trying to insert the crashes into a DB
<pitti> wwoods: that entirely depends on the crashdb implementation, of course
<wwoods> system locked up for like 20 minutes when I tried to upload an evo crash :/
<pitti> wwoods: for Ubutnu they become Launchpad bugs
<wwoods> right, but I'm curious about the "reference implementation"
<wwoods> heh
<StevenK> pitti: That typo sounds like how my sister says Ubuntu
<wwoods> I'm thinking that inserting core files into the bugzilla db (as bug attachments) is a bad idea
<bryce_> seb128: (it is xserver-xorg-video-amd_2.7.6.5+git20070711-1)
<pitti> wwoods: look at bug 125101
<ubotu> Launchpad bug 125101 in totem "totem crashed with SIGSEGV in gst_object_get_parent()" [Undecided,New]  https://launchpad.net/bugs/125101
<pitti> wwoods: I just reviewed it and marked it as public, so that you can see it
<bryce_> seb128: the one change we had in ubuntu was taken upstream by debian (restricts architecture to i386)
<pitti> wwoods: so, we now file all bugs as private (i. e. only subscribers can see them)
<pitti> wwoods: initially only the apport retracer is subscribed
<wwoods> okay, so when it gets uploaded, where does the corefile go?
<pitti> wwoods: the bot picks up the new bug, retraces it, removes the CoreDump.gz attachment, and subscribes ubuntu-qa
<pitti> wwoods: initially it is a normal bug attachment
<wwoods> so initially you *do* have the entire core dump in the bug database as an attachment?
<wwoods> dunno how the bugzilla admins will like that. hmm.
<pitti> wwoods: right
<fabbione> pitti: installer is good.. can?t be better!
<pitti> wwoods: we do not have a proper crash db in LP yet; we will in the future
<fabbione> F I R S T   L D O M   I N S T A L L out of archive!
<pitti> wwoods: for now we use the workaround with private bugs
* pitti hugs fabbione 
<zul> fabbione: congrats
<wwoods> right, I'm prototyping a crashdb as a turbogears app but.. still trying to figure out whether that's worth the effort
<pitti> wwoods: bz has private bugs, too, AFAIR?
<wwoods> yep
<Hobbsee> argh.  we need some basic bug reporting lessons...
<wwoods> yeah the only tricky thing is making sure I don't overload bz by uploading enormous chunks of data
<pitti> wwoods: we figured that we need to restrict access to those bugs anyway, since the stacktrace/traceback could have passwords, CSS keys, etc., too
<pitti> wwoods: right, this needs to be considered, of course
<Hobbsee> "if your bug is a dupe of all these other bugs, please do not file a bug saying "this is a dupe of bug x, y, z".  thankyou"
<zul> Hobbsee: or people having conversations in bug reports
<Hobbsee> zul: that too.
<Hobbsee> https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/125528 is my favorite so far
<ubotu> Launchpad bug 125528 in update-manager "package update-manager failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): E:Sub-process /usr/bin/dpkg returned an error code (1) (dup-of: 125400)" [Undecided,New] 
<ubotu> Launchpad bug 125400 in openoffice.org "[MASTER]  package openoffice.org-common 2.2.1-5ubuntu2 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [High,Fix released] 
<wwoods> pitti: the crashdb implementation I was working on gives each crash a UUID.. so if you know the UUID you can view your bug
<wwoods> err crash
<broonie> Hobbsee: Perhaps also point out that people can subscribe to bugs to get updates.
<wwoods> but only authenticated people can view/browse/search the database of crashes
<Hobbsee> broonie: feel free.
<pitti> wwoods: right, that's the idea
<broonie> Hobbsee: Where?
<Hobbsee> broonie: on that bug
* WorkingGeier throws hardware at the problem and just mirrors everything
<broonie> Hobbsee: Which one (sorry, missing context)?
<Hobbsee> broonie: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bug/125528
<ubotu> Launchpad bug 125528 in update-manager "package update-manager failed to install/upgrade: ErrorMessage: SystemError in cache.commit(): E:Sub-process /usr/bin/dpkg returned an error code (1) (dup-of: 125400)" [Undecided,New] 
<ubotu> Launchpad bug 125400 in openoffice.org "[MASTER]  package openoffice.org-common 2.2.1-5ubuntu2 failed to install/upgrade: subprocess post-installation script returned error exit status 1" [High,Fix released] 
<asac> anyone can try flashplugin-nonfree on amd64? should be on your mirror ... in case not: http://launchpadlibrarian.net/8448248/flashplugin-nonfree_9.0.31.0.4ubuntu2_amd64.deb
<asac> thanks!
<asac> mathiaz: ^^
<mvo> pitti: the session problem you see with compiz, does it help if you downgrade compiz to the previous version?
<pitti> mvo: hm, I have to restart my session for that
<pitti> mvo: can do, though
<mvo> pitti: no rush, would be nice to know though
<pitti> mvo: what is the 'previous' version? there are a gazillions of them :)
<mvo> pitti: https://launchpad.net/ubuntu/+source/compiz/1:0.5.1+git20070703-0ubuntu3
<pitti> mvo: I have 1:0.5.1+git20070712-0ubuntu1
<pitti> mvo: let me try whether it still happens with that one
<asac> http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_9_linux.tar.gz
<soren> http://fpdownload.macromedia.com/get/flashplayer/current/install_flash_player_9_linux.tar.gz
<soren> Could someone else please fetch that file and paste the md5sum here?
<Hobbsee> soren: grabbing
<soren> asac and I get different md5sums...
<Hobbsee> 821cc72359a937caef85bb4cc74ef5cd  install_flash_player_9_linux.tar.gz
<pitti> 76b38231a68995935185aa42dfda9db7
* pitti suspects mirror rotation
<calc> so how does the flash player work on 64bit some kind of shim?
<asac> just works :)
<pitti> ia32-libs?
<calc> hmm ok
<calc> sounds cool :)
<calc> now i just need to take my laptop over to mjg to get him to look at the no suspend in 64bit issue
<calc> bbl
<realist> 821cc72359a937caef85bb4cc74ef5cd
<soren> I get the same as pitti and realist.
<realist> I suspect geographical based cache/proxying
<realist> soren: mine was the same as Hobbsee's, not pitti's
<realist> G'night
<soren> realist: Yes, I'm an idiot. :)
<realist> soren: I still knew what you meant :-)
<doko> bdmurray: it's unlikely that #125485 is python2.5 ... reassigned to exaille
<wwoods> pitti: do you have any rough numbers on how many core dumps you get and how much disk space they take?
<pitti> wwoods: I can only guesstimate
<pitti> wwoods: on my last count we had a magnitude of 3000 bugs filed in about 6 months (only from development releases)
<pitti> wwoods: and a core is between 50 kB and 10 MB
<pitti> wwoods: so a couple of GB, I figure
<pitti> wwoods: however, that was from the time when we did not automatically delete core  dumps
<wwoods> hm, okay
<wwoods> 10MB? really? I had an evo core dump that I was using as a testcase that seemed much bigger than that
<pitti> wwoods: might be; NB that I'm talking about the compressed ones
<pitti> wwoods: uncompressed cores are huuuge (evo: some 300 MB or more)
<wwoods> ahh
<wwoods> that's right, you upload them compressed. duh
<wwoods> that's the bit I forgot
<wwoods> heh
<bdmurray> doko: makes sense sorry about that
<evand> seb128: I updated evolution-exchange and uploaded gcalctool to revu.
<seb128> evand: cools, thanks. Looking
<pitti> doko: please have a look at bug 125551 and ack it
<ubotu> Launchpad bug 125551 in gcc-4.2 "Support for gcc ICEs" [Wishlist,Triaged]  https://launchpad.net/bugs/125551
<Hobbsee> anyone got any idea why we'd still have ndiswrapper-utils-1.8 seeded on the live cds? that should be ndiswrapper-utils-1.9, like the alternate cds
<Hobbsee> more to the point, anyone got any objections if i change it?
<Mithrandir> Hobbsee: doit
<Hobbsee> Mithrandir: great :)
<wwoods> pitti: if the apport-reported bugs are sent anonymously, how do the reporters ever get feedback about them?
<pitti> wwoods: they aren't
<pitti> wwoods: they are normal bugs
<pitti> and a bug submitter is always subscribed
<wwoods> when do you get the submitter info?
<pitti> wwoods: it's mentioned at the top of the bug page
<Hobbsee> Mithrandir: do i need to update the metapackagse too, or will they be redone before we go to build cds?
<wwoods> I guess I'm confused about something... oh - the reporter app grabs your login cookie, and that's how it files bugs as you?
<pitti> wwoods: no, it opens your default webbrowser and lets you type some additional info about the bug
<wwoods> And if you don't have a login cookie?
<pitti> wwoods: in particular, it uses the normal /+filebug page, but with some magic to automatically attach the collected info to the bug
<wwoods> ahhhh
<pitti> wwoods: it'll ask you for your lp login/password
<pitti> wwoods: "it" -> the LP ui
<wwoods> so the bug is pre-filled-out but not actually *filed* by the client-side program
<pitti> wight
<pitti> right, even
<pitti> wwoods: we considered that, but it's a bit tricky to do
<pitti> wwoods: it'll just happen when LP gets a crash db
<wwoods> so - apport-filled-in crash reports don't get filed anonymously?
<pitti> wwoods: nope, not ATM
<Hobbsee> cjwatson: you're modifying seeds as well, then?
<cjwatson> Hobbsee: yes, d-i version bump
<cjwatson> Hobbsee: all done now
<Hobbsee> cjwatson: okay, but i take it you didnt merge my ndiswrapper changes in :)
<cjwatson> Hobbsee: to which branch?
<cjwatson> I mean to which branch did you commit your changes
<Hobbsee> cjwatson: ubuntu.gutsy, then merging across
<cjwatson> oh, right
<Hobbsee> i was a couple of mins after you
<cjwatson> no, I didn't notice that, I just merged up to my change
<Hobbsee> it's fine, i'll fix it here :)
<Hobbsee> yeah
<Hobbsee> i only noticed when i got an error about my tree out of date, and went "hang on...there's something weird going on here..." :)
<Hobbsee> cjwatson: were you going to respin the metapacakges, or assume that they'd be redone before the cds went in?
<cjwatson> Hobbsee: do we need to still support ndiswrapper-utils-1.8 for backward compat?
<cjwatson> Hobbsee: I only really cared about the installer seed change, which doesn't require a metapackage update
<Hobbsee> cjwatson: ah right
<cjwatson> I hadn't been planning to do one right now, although it's true that there are some changes (ubufox) that should be reflected in there eventually
<Hobbsee> cjwatson: um - it doesnt exist in gutsy.  i'm not sure how we handle packages that have dropped out of the archive, between releases
<Mithrandir> well, I want one for mobile-dev soonish anyway
<Mithrandir> so I'll be fine to upload the metapackage itself
<cjwatson> Hobbsee: oh, right, not supported then
<cjwatson> no problem
<Hobbsee> cjwatson: well, it's not suddenly dropped to universe no.
<cjwatson> Mithrandir: remember to update build-dependencies on the metapackage sourrce
<cjwatson> source
<Mithrandir> cjwatson: yup
<Mithrandir> 0.30?
<Hobbsee> hm, this is cool.  bzr doesnt trash your changes, when doing an update.
<Mithrandir> no, should it?
<Mithrandir> git pull doesn't either.
<Mithrandir> nor does svn up
<Hobbsee> oh.
<Hobbsee> i dont tend to work with revision control much, so i have no idea.
<Hobbsee> gah.  more dupes.
<Hobbsee> including more saynig "this is a dupe of x, please check this bug" and they file it anyway
<sladen> echo 0 | sudo tee -a /sys/devices/system/cpu/cpu1/online   .  Never realised that actually worked
<Mithrandir> the tee trick, or turning off CPUs?
<sladen> dismembering cpus.
<cjwatson> Mithrandir: yes
<Hobbsee> is it sad that i've now memorized the master bug number for all the open office bugs?
<sladen> I memorised the number for bug number one
<Hobbsee> heh
<Hobbsee> then again, this one is only 6 digits.
<Hobbsee> the sunday papers at work are much more fun - and get you looked at very strangely.
<Hobbsee> "it's only 13 digits, what's the problem?"  "OK, you're insane."  "I know.  and?"
<ScottK> cjwatson: Do you have a moment to discuss a source backport for Dapper?  jdong said it was appropriate and I should talk to you.
<geser> how is the Changed-By field computed for sponsored syncs?
<Hobbsee> it's the name in debian/changelog, iirc
<geser> for syncs?
<pitti> geser: you specify it on the sync-source command line
<pitti> geser: sync-source -b <launchpad ID>
<seb128> geser: any problem with it?
<geser> no, I just wondered why I got a mail for a sync request I didn't even looked at
<seb128> geser: which one?
<geser> https://lists.ubuntu.com/archives/gutsy-changes/2007-July/004571.html
<geser> bug #125416
<ubotu> Launchpad bug 125416 in java-package "Please sync java-package 0.31" [Wishlist,Fix released]  https://launchpad.net/bugs/125416
<persia> That's mine
<seb128> geser: I probably did a bunch of syncs requests filed by you and did one extra without changing the id
<geser> np
<Hobbsee> bah.  i need a faster connectoin.
<shirish> pitti: can you please look at bug 125563
<ubotu> Launchpad bug 125563 in apport "apport giving wrong message" [Undecided,New]  https://launchpad.net/bugs/125563
<Hobbsee> shirish: did you file 2 or 4 bugs about the openoffice stuff?
<Hobbsee> shirish: please learn to search for bugs before randomly filing bugs on the same thing, repeatedly.
<shirish> Hobbsee: 3-4 bugs which were given by openoffice different components
<shirish> pifff.... again 3-4 bugs which were given by apport when openoffice failed to update/upgrade
<Hobbsee> shirish: which are all in the same source package, and, had you looked at the bug reports, you'd note that they all failed in the same place, with openoffice-common
<Hobbsee> well, people are supposed to look at what they're filing, and use some thought, seeing as this is still in development
<shirish> Hobbsee: true but I was not sure whether it was the same packages
<shirish> same source package
<Hobbsee> shirish: apt-cache showsrc openoffice.org | grep Binary
<Hobbsee> it is.  had you read it, you would have seen that
<shirish> hang on, checking
<Hobbsee> shirish: mark https://launchpad.net/bugs/125568  as a dupe of 125400.  call it karma.
<ubotu> Launchpad bug 125568 in openoffice.org "Open Office update failed - Gutsy Tribe II" [Undecided,New] 
* Hobbsee is sick of marking the darned things, for people who arent checking.
<shirish> done
<shirish> Hobbsee: can you tell me what apt-cache showsrc somepackage | grep Binary does, does it show all the packages it depends on or what?
<Hobbsee> shirish: i'd suggest you run man <term> for each of the terms there
<shirish> oh ok
<Hobbsee> shirish: not enough info on that bug, and the problem is already vaguely known about
* Yagisan looks at the time then at Hobbsee - you should be in bed
<Hobbsee> shirish: that's a dupe of 96503
<shirish> erhm...... showsrc doesn't have a man page
<Hobbsee> shirish: about firefox not opening
<Hobbsee> Yagisan: it's not that late
<shirish> Hobbsee: which one are you talking about?
<Hobbsee> shirish: it's in apt-cache
<Hobbsee> shirish: the bug you just asked pitti to look at - it's a dupe
<geser> Yagisan: she is training for her move to Europe :)
<shirish> Hobbsee: nope, it didn't say firefox isn't opening, it gave a wrong message, FF was already open
<Yagisan> geser, poor girl
<Hobbsee> shirish: i beleive it's the same bug.
<Yagisan> geser, where are you sending her ?
<Hobbsee> shirish: it's not passing the gnome equivalent of kfmclient foo properly
<geser> Yagisan: I don't send there, she wants to come
<shirish> Hobbsee: if you are sure, although I have come across that bug, when apport says firefox is not responding
<Adam> do you think that making two wings of Ubuntu (open-close, and fully open) will speed up making the Windows rival? i think here about open-close version
<Hobbsee> Yagisan: i have plans to move to europe at some point
<Yagisan> Hobbsee, really ? I think I told you I'm off to Japan as soon as practical
<Hobbsee> Yagisan: yeah :)
<Hobbsee> Yagisan: do you know when that is?
<Hobbsee> shirish: fairly sure
<shirish> Hobbsee: ok if you say so, marking it duplicate
<mrsno__> could anyone kindly explain how backporting fixes found in gutsy will be applied to feisty please? im talking of an xorg update released for gutsy https://launchpad.net/bugs/109703
<ubotu> Launchpad bug 109703 in xorg "[nvidia-glx]  X module Int10 fails to initialize - Feisty" [Medium,Fix released] 
<Yagisan> Hobbsee, I have 8 uni subjects left to do, and I've taken 4 of them right now, so if things go well and I get some more money - very soon
<Hobbsee> Yagisan: nice!
<Hobbsee> mrsno__: it probably wont be done in an update
<Hobbsee> !sru | mrsno__
<ubotu> mrsno__: Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates for main and restricted, while https://wiki.ubuntu.com/MOTU/SRU is for universe and multiverse.
<Hobbsee> unless it fits ^
<Yagisan> Hobbsee, no not nice! the full time guys only have 3 subjects :'(
<mrsno__> Hobbsee thanks :-)
<mrsno__> i will pass that on
<Hobbsee> Yagisan: heh.   there's 4 here. it seems normal
<Hobbsee> Tonio_: did you eyeball that kdesudo patch, btw?
<Yagisan> Hobbsee, I took computer graphics hoping for 3d - I've got 1970's 2D, and I had to port the graphics library they insist on using to linux myself.
<Hobbsee> Yagisan: heh.  fun :)
<Hobbsee> oh well, i dont want to upload that tonight.
<Tonio_> Hobbsee: not yet, I'm waiting for kdelibs to be published to attempt to build it
<Hobbsee> not when i'm falling asleep.  darn work early in the morning
<Hobbsee> Tonio_: i meant the patch to kdelibs, sorry
<Yagisan> Hobbsee, no not fun - gcc hates it (rightly so - is really a piece of - well I was gonna say shit - but that would insult shit) - I want to gouge my eyeballs out with a fork after looking at it
<Hobbsee> haha
<Hobbsee> oh dear :)
<Hobbsee> gouging people's eyes out with a fork sounds like fun, though.
* Yagisan hands Hobbsee a fork
<Tonio_> Hobbsee: well I need to build kdesudo to test it actually :)
<Hobbsee> Tonio_: heh.
<Hobbsee> Tonio_: i dont have more changes - looks like mine are in bzr.
<Hobbsee> i just checked here
<Tonio_> Hobbsee: oki did you published it ?
<Hobbsee> either that, or i havent documented them - which would be rare
<Tonio_> did you merge _Stefans_ patch ?
<Hobbsee> as in, did i upload it to the archive?
<Tonio_> in case no I'll do it
<Hobbsee> no, havent yet
<Tonio_> oki
<Tonio_> want me to take that in charge ?
<Hobbsee> was about to, then realised i how tired i was :P
<Hobbsee> Tonio_: yes please
* Hobbsee is alergic to mornings, and 3 hours of sleep.
<Hobbsee> shirish: https://launchpad.net/bugs/125575 too please
<ubotu> Launchpad bug 125575 in openoffice.org "package openoffice.org-java-common 2.2.1-5ubuntu2 failed to install/upgrade: dependency problems - leaving unconfigured" [Undecided,New] 
<Hobbsee> shirish: watch #ubuntu-bugs for more of them
<Tonio_> Hobbsee: oki let's build this one
<shirish> Hobbsee: get your sleep, would watch them for few hrs. btw isn't the new one out about an hr. ago ?
<Hobbsee> shirish: it got reported 2 minutes ago to -bugs.
<Hobbsee> shirish: so, unlikely.  just silly people are filing them, without checking first, so they all look almost exactly the same
<Tonio_> Hobbsee: can't see your changes in kdelibs, just updated the bzr branch
<Tonio_> Hobbsee: did you fill the changelog ?
<Hobbsee> Tonio_: i didnt commit
<Hobbsee> Tonio_: yeah, i did previously
<Tonio_> Hobbsee: can you commit so that I build the package ?
<Hobbsee> i thought i had more
<Hobbsee> my last commit is the latest (0ubuntu7)
<Hobbsee> i think
<Tonio_> 1ubuntu7
<Hobbsee> whatever it is
<Hobbsee> it ends in ubuntu7
<Tonio_> Hobbsee: we are possibly at version ubuntu9 now :)
<Hobbsee> Ton
<Hobbsee> Tonio_: this is true
<Hobbsee> Tonio_: on second thoughts, are you around in ~12 hours?
<Tonio_> 14 hours :)
<shirish> darn, I want to help & my fav. fav. most watched movie coming, a hindi musical
<Tonio_> Hobbsee: I can wait for you to commit your changes
<Hobbsee> Tonio_: even better.
<Tonio_> yup
<Hobbsee> Tonio_: my changes *should* already be committed, but i'll check then
<Hobbsee> Tonio_: if you see me, and are around, please poke me on irc, and we can figure out how to do things sanely with bzr
<Tonio_> Hobbsee: oki, I'll build the package tomorrow, there is no emergency reguarding to kdesudo on that point as I'm still waiting for mhb latest improvement
<Hobbsee> Tonio_: as the current lot is...not the smartest setup in teh world.
<Hobbsee> Tonio_: fair enough
<Hobbsee> Tonio_: i do want to see if it builds here without binary corrupting, though
<shirish> Hobbsee: https://beta.launchpad.net/ubuntu/+source/openoffice.org/2.2.1-5ubuntu3
<Tonio_> Hobbsee: why would binaries be corrupted ? because of _Stefans_ changes ?
<Tonio_> Hobbsee: ho yeah I saw he redefined a class, can cause troubles indeed
<Hobbsee> Tonio_: binary changes, when i use an ordinary dpkg-buildpackage, with a .bzr/ dir
<Tonio_> hum okay, that's another problem :)
<Hobbsee> Tonio_: which means i need to use bzr-buildpackage, yeah
<Tonio_> Hobbsee: bzr export && pbuilder is nice too
<Hobbsee> true
<Hobbsee> Tonio_: oh.  i *do* have more to commit.
<Hobbsee> Tonio_: i knew there was something else
<Hobbsee> yay, deaded brain.
<xxxxx1> someone here use dpatch-get-origtargz?
<sivang> xxxxx1: what is that?
<xxxxx1> dpatch-get-origtargz gets the upstream tarball
<xxxxx1> useful for get-orig-source target
<xxxxx1> i am trying the method to get upstream from watch file... but i think dpatch-get-origtargz have a bug dealing with .tar.bz2
<sivang> ah, I see
<Amaranth> bryce: if anything bug 60726 should be closed as invalid
<ubotu> Launchpad bug 60726 in xorg-server "GL_ARB_fragment_program support" [Medium,Incomplete]  https://launchpad.net/bugs/60726
<Amaranth> That patch tells programs fragment_program is supported but doesn't seem to actually make it work. Also, compiz doesn't require fragment_program
<franck78> Hello *, I would like Networkmanager be updated from 0.64 to 0.65 because it solves issues 'wpa key not correctly used with wpa_supplicant';  Recompiling & installing manually is painfull ;-) Merci
<sits> hi there
<sits> what is the procedure for wiki conflicts?
<ScottK> sits: What page?
<sits> ScottK: https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia
* ScottK looks
<sits> I've toiled away on that page for months trying to carefully make it so that it lists information concerning the installation of Ubuntu provided binary drivers
<sits> after someone added a huge manual install section to the middle I went away and improved
<sits> https://help.ubuntu.com/community/NvidiaManual
<ScottK> OK
<sits> and made links to it more prominent and included a warning in the edit page that the manual installation was described on the NvidiaManual page
<sits> now the thing is people clearly want manual instructions...
<sits> Am I being daft? If so I wouldn't mind if the non manual information were removed entirely as it took ages to compile
<sits> I don't want a war
<sits> if the manual stuff should be there so be it but I don't want people thinking that it is the "supported" method and all the links and background information to launchpad
<ScottK> Maybe find the contact info of the person adding the manual info and e-mail them?
<sits> I've tried
<sits> I couldn't find an email address
<sits> I tried to leave an explanation in the history
<sits> but clearly that person wants it there and my comment saying see NvidiaManual was ineffective
<sits> I was happy to see someone else editing the page I'm just at odds with their style I guess
<ScottK> sits: I'm looking at it.
<mdke> sits: we can fairly easily get hold of someone's contact details - did you try a search in launchpad using the wikiname?
<sits> mdke: that's an excellent idea. Trying it now
<mdke> found him, no email though. We'll ask the LP team if they can give it to you
<sits> ScottK, mdke: Basically I'm wondering if I'm making a mountain out of molehill
<ScottK> Cool because other than finding out he's prominant in "Overclockers of Guatemala", Google wasn't much help.
<ScottK> sits: Do both ways of doing it work?
<mdke> sits: sounds like you are totally right. And we need a procedure for resolving these things. Feel free to carry on in -doc if you like
<sits> ScottK: sort of. It's not that simple
<sits> if you go the manual route you get newer drivers but every time a new kernel or mesa update comes out you have to recompile the binary drivers
<ScottK> OK.  Well I'd follow up as mdke says in #ubuntu-doc then.  Goog luck
<ScottK> Goog/Good.
<sits> also the binary drivers overwrite the debs files on the system
<sits> this can cause huge problems later on as debs are upgraded (e.g. if you move the next +1)
* ScottK can see that.
<sits> ok "carrying on" ( : ) over in -doc
* ScottK uses Intel with good Free drivers.  That's the real solution.
<tormod> ScottK: bug #43322: are you sure it can not go into backports? that sounds a little bureaucratic...
<ubotu> Launchpad bug 43322 in eog "EOG crashes when stopping slideshow" [Medium,Fix released]  https://launchpad.net/bugs/43322
* ScottK looks
<ScottK> Not for bug fixing.  The Ubuntu Tech Board gave very strict guidelines about backports when it was created.  It's really MUCH better to find the patch for that bug and do an SRU.
<ScottK> Backports are not enabled by default, but updates are, so everyone will get the fix that way.
<tormod> ScottK: upstream says: there a deep design problem which blocks us from fixing it.
<ScottK> Hmmm
<tormod> ScottK: http://bugzilla.gnome.org/show_bug.cgi?id=320206#c85
<ubotu> Gnome bug 320206 in collection "Crash when canceling slide show" [Critical,Resolved: fixed] 
<ScottK> Well then maybe a rewritten backports request that asked for all the new shiny features (and oh by the way won't crash) would work.
<vignatti> hi, is there some Xorg maintainer here?
<vignatti> well, I would like to know some status of the xkeyboard-config (or xkb-data)
<ScottK> tormod: That bug has a pretty small patch attched to it.  Are you sure it can't be backfitted into the existing verions?
<ScottK> vignatti: All the likely suspects are at a development sprint this week in London and so they aren't online much and it's late where they are.
<ScottK> Gotta run.
<vignatti> ScottK: okay dude, thanks for the tip
<tormod> ScottK: the patch in comment 21? reported to not fix by comment 22.
<tormod> ScottK: that patch actually went upstream in comment 25 as a partial fix.
#ubuntu-devel 2007-07-13
<jsgotangco> good morning
* mneptok grumbles at Novell
<mneptok> commit the damned Evo patch, ya bastards!
<mneptok> raar. sorry.
<RAOF> bug #123664 is annoying me :).  I pushed it upstream, and there's a (fairly small) patch to fix it which will be in 2.19.6.  Should I prepare a debdiff against our current g-p-m, or just wait for 2.19.6 to be released & (help) package that?
<ubotu> Launchpad bug 123664 in gnome-power-manager "Should not count time suspended in battery profile" [Undecided,Confirmed]  https://launchpad.net/bugs/123664
<minghua> I say don't bother patching.  gnome-power-manager should be included in the final GNOME 2.20 release, shouldn't it?
<RAOF> I believe so
<Fujitsu> 2.19.6 should come in with the rest of GNOME 2.19.6.
<Fujitsu> That shouldn't be far off.
<RAOF> Fair enough.  I'll see if I can help package the new uv then.
<minghua> Well, 2.19.5 was released yesterday, so maybe a while.
<zul> hey mneptok
* minghua wants to thank RAOF for fixing that bug.  It annoys me as well.
* RAOF didn't fix it.  Just report it upstream
<minghua> RAOF: Thank you for reporting, then. :-)
<RAOF> That I'll lay claim to :)
<mneptok> zul: heya
<mneptok> There is no Dana. Only Zul.
<Pici> mneptok: http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul
<sbalneav> Mithrandir: Hey, did you ever get a sql representation of ical going?
<elpargo_> hi anyone here knows how can I call the "open with" functionality in the content menu of nautilus?
<Burgundavia> elpargo_: what do you want to do?
<elpargo_> Burgundavia, I want to call the correct program to handle a file from code.
<Burgundavia> you want to open a file with an external app?
<elpargo_> Burgundavia, no no from my code I want to execute the same function.
<Burgundavia> try in #gnome-hackers on gimp.net
<elpargo_> Burgundavia, yes but I'll like to delegate that to the nautilus system, i find it very good, and there is no need to redo the wheel
<Burgundavia> no, I am saying talk with the GNOME developers on that channel
<Burgundavia> they will tell you how and that is a better channel for that
<elpargo_> ok thanks
<Burgundavia> no worries
<superm1> Hobbsee, would you be able to look over another lirc upload (promise this one is smaller than the request the other night)?
<Sp4rKy> fabbione: ping
<Sp4rKy> fabbione: i just merged afbinit, can you check the final debdiff at http://paste.dunnewind.net/256 and say me if you're agree with it
<fabbione> Sp4rKy: looking
<fabbione> Sp4rKy: looks ok, can you please make sure to send our diff to the debian maintainer? at least the include stuff... he can?t really merge the section
<Sp4rKy> fabbione: ok
<Sp4rKy> so i request a merge on lp and mail the debdiff to the debian maint ?
<fabbione> hm? just send a mail to the maintainer with the diff for the includes
<fabbione> and upload the package to ubuntu
<fabbione> i don?t see the need to open an lp request
<Sp4rKy> hu ?
<Sp4rKy> i don't understand well ^^
<Sp4rKy> it should be a merge process, no ?
<fabbione> yes but a merge process does not require an LP request
<fabbione> just upload it to the archive
<Sp4rKy> i can't upload myself :)
<fabbione> ok, then ask for a sponsorship... or give me a few minutes and I will do it
<gnomefreak> do all backports have to be pushed by a core-dev?
<fabbione> just need to power up my sparc to test it
<Sp4rKy> fabbione: ok :)
<Sp4rKy> i wait your test
<Sp4rKy> and then i'll mail the debian maint
<Fujitsu> gnomefreak: core-dev can upload directly to backports, but most are requested as sync are.
<Fujitsu> *syncs
<Fujitsu> (ie. archive admins do them)
<gnomefreak> someone backported hal and i thought that was one of the no no packages to backport
<gnomefreak> its borked anyway in feisty backports
<Fujitsu> Hi pitti.
<pitti> Hi Fujitsu
<gnomefreak> morning pitti
<fabbione> Sp4rKy: can you put the debdiff somewhere wget?able?
<Hobbsee> morning pitti
<Sp4rKy> fabbione: of course
* StevenK waves to pitti
* gnomefreak kind of worries about that backport TBH
<gnomefreak> ill keep looking to see who did it
<pitti> hey Hobbsee, hi StevenK
<Sp4rKy> fabbione: http://people.dunnewind.net/maxence/afbinit_debdiff
* pitti kills the NBS list, now that the kernel bits built
<StevenK> Yay!
<Hobbsee> gnomefreak: blame pitti
<StevenK> pitti: NBS everything out of the archive that's zero size, plus you can probably kill libcegui-mk2-0c2a.
<gnomefreak> Hobbsee: i would but he was removed from maintainer feild
<gnomefreak> field
<Hobbsee> gnomefreak: he's uploaded it
<fabbione> Sp4rKy: thanks
<Hobbsee> gnomefreak:
<Hobbsee> https://launchpad.net/ubuntu/+source/hal/0.5.9-1ubuntu2~feisty1
<gnomefreak> pitti: isnt hal one of those packages that shouldnt be backported?
<StevenK> pitti: And can you puhlease kick glew, parrot and libgeda out of NEW?
<pitti> StevenK: seb128 is looking at NEW
<Sp4rKy> fabbione: np
<pitti> gnomefreak: why?
<StevenK> pitti: Fair enough.
<pitti> gnomefreak: I did backport a gutsy hal to feisty, because it fixes stuff for quite a lot of people
<StevenK> pitti: Okay, will you regenerate the list after you kill everything zero-sized?
<pitti> StevenK: yep
<StevenK> pitti: Cool, thanks.
<pitti> StevenK: in an hour, after next publisher run
<StevenK> Sounds fine.
<gnomefreak> pitti: i thought due to depends it shouldnt have been. btw its broken in feisty
<gnomefreak> pitti: bug 125717
<ubotu> Launchpad bug 125717 in feisty-backports "No initscript in hal 0.5.9" [Undecided,New]  https://launchpad.net/bugs/125717
<pitti> gnomefreak: --verbose, please
<pitti> gnomefreak: that's weird
<pitti> gnomefreak: oh, it is not supposed to have one
<gnomefreak> pitti: im not running it in feisty i am hearing about this
<pitti> gnomefreak: /etc/dbus/event.d/20hal
<pitti> hal *never* had an init script until recent gutsy
<simira> speaking of which, where can I get a gutsy-cd in this office?
<Hobbsee> simira!
<gnomefreak> pitti: hes gonna comment on bug i hope
<simira> Hobbsee :)
* simira waves from London
<Hobbsee> simira: your'e in london now, hey?  nice!
<Riddell> simira: how's the view?
<elmo> simira: download it? the net connection doesn't suck, especially not to *.u.c
<fabbione> Sp4rKy: uploaded
<Sp4rKy> fabbione: ok thx
<Sp4rKy> so i mail the dd
<fabbione> Sp4rKy: np..
<Riddell> Mithrandir: could you give back kde4graphics and kde4network?
<Mithrandir> Riddell: backgegibt
<Riddell> Mithrandir: pardon?
<Mithrandir> Riddell: given-back
<Riddell> thanks
<Mithrandir> cjwatson: you were right last night, your fix works and I am a muppet.
* Hobbsee waits for /nick MithrandirMuppet
<simira> elmo: true. Then I just need to find someone nice person to give/lend me a cd :)
<Hobbsee> guten morgen, mvo
<mvo> hey Hobbsee
<Mithrandir> cjwatson: http://err.no/tmp/mobile/mobile-dev ; it looks fairly sane to me, what do you think?
<StevenK> pitti: Poke, regenerate NBS. :-)
<StevenK> seb128_: Can you puhlease kick glew, parrot and libgeda out of NEW, so the older libraries can be NBS'd when they have no rdepends?
<pitti> StevenK: as I said, I need to wait for the publisher to finish
<StevenK> Oh duh, it isn't instant.
<StevenK> Sorry
<seb128_> StevenK: looking
<StevenK> seb128_: Thanks.
<seb128_> StevenK: parrot didn't build on ia64
<StevenK> Wierd. No idea why, or how to fix it.
<StevenK> It fails the same way on Debian, so I'm comforted by that.
<seb128_> well we try to NEW on all the arches in the same time
<StevenK> I can file a nastygram in Debian, but I doubt I know enough about Parrot internals to attempt to fix it.
<StevenK> Or have access to an ia64
<Mithrandir> seb128_: as long as it FTBFS, it should be fine.
<seb128_> Mithrandir: ok
<StevenK> Mithrandir: It runs itself during the build and blows up. So it's impressive.
<infinity> mvo: Your custom apt works perfectly for me.  You're a rock star.
* mvo hugs infinity
<StevenK> seb128_: And if you process bug 125586, we can kill rt3.6-apache off the NBS list.
<ubotu> Launchpad bug 125586 in request-tracker3.6 "[Sync request]  Sync request-tracker3.6 (3.6.4-1) from Debian unstable (main)" [Undecided,Confirmed]  https://launchpad.net/bugs/125586
<infinity> mvo: Although, it took me about 5 minutes of confusion and a diff of the source to realise you'd renamed the variable. :P
<pygi> fabbione, around by any chance?
<cjwatson_> Mithrandir: germinate 0.31 synced for the next publisher run
<fabbione> pygi: yes?
<pygi> fabbione, brasero built properly on sparc & ppc now ;)
<fabbione> pygi: ok cool
<seb128_> StevenK: synced
<fabbione> whops
<StevenK> seb128: Thanks!
<seb128> StevenK: thank you for doing most of the work ;)
<pitti> 'k, time to crank NBS
<StevenK> pitti: Hurrah!
<StevenK> pitti: Ping me when it's finished smashing drescher?
<pitti> sure
<mvo> infinity: uhhh, sorry for that, I thought I had told you about it
<Hobbsee> mvo: got any current plans for fixing the metapackages from any component cant install recommends bug?
<infinity> mvo: No one tells me anything.
<seb128> infinity: or maybe you just don't listen what people say? ;)
<StevenK> Could be both.
<Hobbsee> mvo: what would the fix be?  just hardcode the universe/metapackages, and multiverse/metapackages, in there too, like you have with multiverse?
<mvo> Hobbsee: yes, but I have no timeline yet, please keep naging me about it so that I get to it eventually
<mvo> Hobbsee: I think the fix would be either to suppoer regexp there or to allow a list of sections
<infinity> seb128: I suspect it's a bit of both. :)
<Hobbsee> mvo: right.  more things are missing this, now, not just *-r-e
<Hobbsee> mvo: how often do you wish to be nagged?  :P
<simira> infinity: no one ever tells you anything so you don't bother to listen? :p
<infinity> simira: Did you say something?
<mvo> Hobbsee: once a day is enough ;)
<Hobbsee> mvo: :D
<simira> infinity: nothing important
<pitti> StevenK: NBS updated
<simira> seb128: how do I reduce the font size in the gutsy gnome menus? (I managed to reduce all other in Appearance-settings)
<simira> &j ubuntu-gnome
<simira> uh
<Fujitsu> simira: You probably want to change the DPI setting in Appearance->Fonts->Details
<seb128> Fujitsu: it's not going to be menu specific
<simira> Fujitsu: we (Scott) tried.... no effect
<seb128> simira: it should follow the applications font
<simira> who changed and blew up the fonts anyway...
<simira> seb128: it definitely doesn't
<seb128> simira: no idea then, looks like a bug
<seb128> works fine on my laptop
<simira> seb128: a gnome- og x.org-bug?
<seb128> simira: would need to be debugged to say, but it's only the gnome-panel not changing I would say a GNOMEish bug
<seb128> s/it's/if it's
<simira> seb128: yes, seems to me like it is
<seb128> does restarting it makes a difference?
<Mithrandir> cjwatson: thanks; committed
<simira> seb128: logout/login seemed to fix it. Should I still report a bug for it, or does it have to be that way?
<seb128> simira: you can open a bug but since it doesn't happen on my box it's likely to stay open until somebody getting the bug look at it
<simira> seb128: ok
<simira> mjg59: you have absolutely nothing to do today, have you?
<Arcer> hi all
<Arcer> excuse me for my english
<Arcer> someone known a gui kde-like for developing in C
<Arcer> ?
<Arcer> like devc in Windoes
<pitti> Arcer: kdevelop is fairly good
<Arcer> oh thank :D
<Arcer> i'll install see later :D
<calc> maybe eclipse also
<Arcer> I use eclipse for java programming in Windows
<asac> crimsun: ping
<asac> crimsun: unping
<Riddell> seb128: https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/125748
<ubotu> Launchpad bug 125748 in compiz "compiz-{kde,gnome} does not depend on compiz-plugins" [Undecided,New] 
<StevenK> Riddell: Why are kde4libs-data, kdepimlibs4 and kdepimlibs4-dev all marked as NBS? What replaces them?
<Riddell> StevenK: where is that listed?
<Riddell> StevenK: kde4libs-data -> kdelibs5-data
<StevenK> http://people.ubuntu.com/~ubuntu-archive/NBS/
<Riddell> kdepimlibs4 -> kdepimlibs5
<Riddell> kdepimlibs4-dev -> kdepimlibs5-dev
<Riddell> I may well have forgotten to put in Replaces: on various of those
<persia> pitti: Thank you ever so much for the binary removals.
<simira> Hobbsee: are you asleep yet?
<StevenK> simira: She is probably dinner'ing
<simira> oh
<calc> simira: kylem does a pretty good hiding act
<pitti> persia: no problem :)
<simira> calc: he might be busy then....
* StevenK prepares to rip binaries off libgeda20.
<Fujitsu> StevenK: Why?
<Fujitsu> Oh, NBS?
* StevenK nods. libgeda20 is NBS.
* Fujitsu is guilty of having that synced. Want me to handle it?
<StevenK> No, it's fine. It's 5 packages, and I
<StevenK> 'm just about half-way through it.
<StevenK> And it all scripted/scriptable.
<Fujitsu> Thanks.
* StevenK fires off 5 builds.
<StevenK> pitti: I'm unclear why nic-firmware, scsi-firmware and ubuntu-modules are listed in NBS. I'm probably missing something.
<pitti> StevenK: I'll have a look later
<StevenK> Hrm. Been a while since I heard this.
<StevenK> Frame# 38870 [118037] , Time: 00:13.66 [68:05.14] 
<StevenK> Typical. Out of the five builds, one failed, and it's one with Ubuntu changes.
* StevenK blames Fujitsu.
* Fujitsu is blamed.
<Fujitsu> Which?
<Fujitsu> geda-gschem?
<StevenK> Yup
<Fujitsu> StevenK: The rest of geda is in DEPWAIT at the moment.
<Fujitsu> And I haven't merged that yet.
<StevenK> So I just uploaded four rebuilds for nothing?
<Fujitsu> Um, possibly.
<StevenK> geda-gattrib built.
<StevenK> As did geda-utils.
* StevenK suspects the four rebuilds are completly pointless.
<StevenK> Yup.
<StevenK> pitti, Mithrandir: Can you reject geda-* please?
<Fujitsu> Yay, unaccepting.
* StevenK plots against Fujitsu.
* Fujitsu apologises for not making the connection.
<StevenK> If they do or don't, it isn't too important, just pointless and a waste of buildd time.
<Fujitsu> Right.
* StevenK moves onto silc, and plotting a short trip to Melbourne.
<Fujitsu> Hah.
<StevenK> :-P
* Fujitsu runs.
<Keybuk> why can I find no OpenOffice documentation on creating presentation templates?
<Hobbsee> simira: nope, was at dinner.
<jordi> fabbione: ping ping
<Hobbsee> Keybuk: does anyone actually create presentation templates in ooo anyway?
<ijuz_> i'm always using the "empty presentation" template it's great stuff ;)
<ijuz_> Keybuk: looks like it's nothing special such a template http://openoffice.blogs.com/openoffice/2006/03/templates_makin.html
<pitti> doko: https://wiki.ubuntu.com/ArchiveCleanupStatus
<siretart> is there currently some congestion in the (source) NEW queue?
<seb128> no
<seb128> why?
<seb128> it was empty like one week ago
<siretart> I wonder if there is a problem with the emacs22 package, it was uploaded on 07/07
<seb128> pitti wants to use the debian version
<ScottK> pitti: I got a reject notification for my evolution-python sync, but no reason.  Do you have time to discuss or should I e-mail you?
<seb128> we just discussed it briefly though
<siretart> pitti: why? mwolson is doing a great job on the package!
<seb128> ScottK: I did already synced it yesterday
<pitti> siretart: I don't see why we should have two parallel packagers?
<ScottK> Ah.  That'll do it.  Thanks seb128.
<pitti> siretart: we should just sync Debian's and put the doc in main
<siretart> pitti: because debian strips off documentation and such. there is no need for this in ubuntu
<siretart> pitti: emacs without the manual is close to worthless
<siretart> seriously
<seb128> siretart: there is a package with documentation though
<seb128> siretart: we can just make emacs22 depends on the other package
<siretart> seb128: in non-free. we don't want documentation to be seperate in ubuntu
<pitti> siretart: Depends: -doc :)
<pitti> siretart: Recommends:, though
<siretart> pitti: so you want to tell mwholson that all his work on https://code.launchpad.net/~ubuntu-elisp/emacs/ubuntu was for nothing?
<seb128> siretart: why should be work to divert from Debian when not required?
<seb128> siretart: we tend to sync when we can
<siretart> seb128: have you looked at the branch history? please do
<siretart> anyways, it would be really nice if some archive admins could reposond to Michaels verbose emails to his emacs22 plans in ubuntu he posted to the mailing list
<siretart> we shouldn't let him in the dark with these decisions
<siretart> s/let/leave/
<pitti> (later, presentation here)
<seb128> siretart: will do, quite busy at distro sprint this week though
<seb128> siretart: and emacs22 is not easy to review, would be easier for everybody to base on Debian
<siretart> and therefore we reject very good and enthusiastic contributions to ubuntu?  :/
<seb128> we said we reject anything?
<siretart> well, in some ways you said so before
<seb128> you want to stop syncing only to not drop work done aside from Debian?
<seb128> every time we sync we drop some Ubuntu contribution
<seb128> I agree we should not discourage contributions so might want to accept the emacs22 from NEW and sync from Debian later
<siretart> that's what I'm basically suggesting
<siretart> we of course want to regularily merge with debian
<seb128> so it's going to takes sometime because emacs22 is not trivial to review
<siretart> I know
<pitti> siretart: hm, I didn't see anything on ubuntu-devel@; which ML was it on?
<seb128> ScottK: evolution-python is not distributable btw, not sure if we will accept it
<seb128> ScottK: you might want to open a bug on Debian saying they should ship the GPL text in the tarball
<siretart> pitti: ubuntu-motu for sure, not that sure for ubuntu-devel
<ScottK> Ah.  I will do so.
<ScottK> Thanks seb128.
<seb128> np
<ScottK> Interesting.  debian/copyright says: "License (note that upstream accidentally ships the LPGL, but the files say GPL)"
<seb128> right
<seb128> so it's GPL
* ScottK makes a note to make fewer assumptions about the thoroughness of Debian
<seb128> and the license text should be in the tarball
<ScottK> Yes.
<ScottK> ...Debian's NEW reviews.
<azeem> ScottK: Debian's NEW review actually looks at the copyright boilerplate in the various source files rather than COPYING, I think
<asac_the_2nd> pitti: high latency ... yes the mirrors should after all be updated now or really soon
<asac_the_2nd> pitti: i was not sure if the main bug means: gutsy task
<seb128> azeem: still the tarball should ship a copy of the license
<azeem> sure
<seb128> it doesn' in this case
<pitti> asac_the_2nd: 'development release'; I closed it now, thanks
<asac_the_2nd> ok cool
<seb128> brb
<Riddell> doko, pitti: kdebindings uploaded without gtk1.2
* pitti hugs Riddell 
<doko> nice!
<pitti> calc: do you prepare an oo.o-l10n upload as well? that one still b-deps on the old portaudio (18), but that's in universe now in favour of 19
<calc> pitti: hmm yea i probably should do that
<pitti> zul: libvirt is uninstallable because it depends on xen 3.0; can you please have a look at this?
<pitti> fabbione: ^ actually, that's your baby, isn't it?
<fabbione> pitti: it?s one of my B-D but i didn?t package it
<zul> pitti: sure
<fabbione> pitti: would be nice if somebody could update it... with Xen knowledge even better
<fabbione> zul: thanks
<pitti> fabbione: ok; seems that zul is at it
<pitti> zul: cheers!
<fabbione> pitti: yeps.. thatnks
<zul> no probs
<pitti> that also explains cman uninstallability and such
<fabbione> pitti: yes.. it?s all connected..
<persia> pitti: Regarding REVU packages rejected during NEW processing: Do you have any objections to using REVU for communication between sponsorees and sponsors?
<Hobbsee> persia: if revu actually had the same login as lp...
<pitti> persia: no, I don't, and I'm not familiar with the revu procedures
<Hobbsee> persia: and if it actually kept cookies...
<persia> pitti: OK.  Thanks.  There was just some confusion.
<pitti> persia: it just seems to me that a package which just had a license problem which got fixed needs to be REVUed again
<pitti> persia: erm, needs *not*
<persia> Hobbsee: Yeah - those would be neat, but it's still a handy dget'able place.
<Hobbsee> true
<pitti> persia: if that's common practice, it should be done, of course :)
<persia> pitti: I totally agree.  In that case, I only think REVU is a handy place to upload, and that a single advocate (probably the original sponsor, but perhaps anyone else) should be able to upload after checking.
<pitti> ok
<persia> pitti: Thanks for the feedback.
<pitti> F**K
<pitti> https://launchpad.net/ubuntu/+source/openoffice.org/2.2.1-5ubuntu3/+build/357598
<pitti> I hate hate hate OO.o
<StevenK> Hrm. Why did glew get demoted 8 minutes ago?
<pitti> StevenK: it does not have any reverse dependencies and the library was already in universe
<Hobbsee> pitti: it probably hates you too
<StevenK> pitti: It has reverse Build-depends in main: rss-glx
<pitti> infinity: is adare maybe the wrong buildd to build OO.o? It failed three times in a row now with a timeout error
<pitti> StevenK: hmm, then checkrdepends is stupid
<infinity> pitti: I may have the technology to fix that.
<Mithrandir> infinity: and appropriately-sized hammer?
<pitti> infinity: cover it with your special buildd admin magic hat?
<StevenK> pitti: Actually, maybe not. glew builds libglew1.4-dev which provides libglew-dev, which is what rss-glx wants.
<Hobbsee> Mithrandir: you and hammering poor objects....
<Mithrandir> Hobbsee: buildds are not poor objects.  They _like_ being hammered.
<Hobbsee> heh, right then
<StevenK> No, I agree with Mithrandir.
* Hobbsee concludes that Mithrandir might be a buildd as well, and therefore hammers Mithrandir 
<StevenK> They *liked* it when I threw 62 rebuilds at them.
<pitti> *munch* *munch*
* StevenK mutters "Bloody curl" under his breath.
<Hobbsee> StevenK: does this mean you'll never touch curl again?
<StevenK> Hopefully.
* persia gleefully imagines a migration to a new libcurl4 next week
* StevenK hangs persia up by his hair
<pitti> StevenK: I cleaned gutsy_probs, anastacia, and NBS a bit harder, next publisher run should have some light
<StevenK> pitti: Which hopefully isn't an on-coming train. :-)
<StevenK> pitti: So what do we do about rss-glx?
<Hobbsee> what's wrong with rss-glx?
<StevenK> glew was demoted
<pitti> StevenK: oh, I moved glew back to main
<StevenK> Ah, right.
<ogra> StevenK, huh ?
<pitti> StevenK: it was just due to my stupidity, after all
* ogra wasnt aware
<calc> pitti: dumb ooo failed on ppc again :(
<pitti> checkrdepends <- does not know about virtual packages
<pitti> calc: I just noticed, and asked infinity to treat it with some special love
<calc> pitti: for the same reason too, sig 15 after 149mi
<pitti> calc: adare is apparently unsuitable
<calc> pitti: ok thanks! :)
<calc> hmm ooo reminds me of NKOTB song ;)
<StevenK> Oh good God
* StevenK kills calc
<calc> lol
* calc wishes for play music over irc function, so he could torture everyone with the same song ;)
<StevenK> For those who can't expand NKOTB, consider yourself lucky.
* Hobbsee wishes for a stab people through their computers function, to use on calc
<jsgotangco> haha
<infinity> pitti: Should be fixed.
<Hobbsee> hi spam
* StevenK kills calc again, *harder*
<jsgotangco> hey
<pitti> infinity: yay you
<calc> StevenK: hehe
<calc> for anyone who doesn't know what i was talking about, here you go, if you look don't blame me for gouging your eyes out later ;) http://www.sing365.com/music/lyric.nsf/You-Got-It-The-Right-Stuff-lyrics-New-Kids-On-The-Block/9CD3256205EB3F62482568B90022130B
* StevenK plans a trip to London.
<StevenK> Evidently, killing over IRC isn't giving the right impression.
<calc> hehe i leave tomorrow, i'm safe for now ;)
<calc> you can get me in Boston at UDS
<StevenK> Is that a promise?
* Hobbsee suspects that this might be a fun song to add to her myspace page....
* StevenK grins evilly
<calc> Hobbsee: lol yea
<StevenK> Hobbsee: Your myspace page is already evil enough without a pre-boy band boy band polluting it.
<calc> i'm pretty sure you would have to be a teen in the early 90s to get the full torture part of the joke ;)
<StevenK> I was a teen in the early 90s
<calc> StevenK: i'm sorry ;)
<StevenK> Yes, so I am.
<StevenK> am I, even
<StevenK> See, I'm so cut up!
<calc> as was i, hence the constant reminder of that song anytime i see reference of ooo
<StevenK> I had managed to all but forget about NKOTB ...
<StevenK> calc: So, eat flaming death! :-P
<calc> StevenK: muhahaha >:-)
<Hobbsee> StevenK: now, i dont know about that...
<thom> StevenK: it could be worse, it could be kris kross
<StevenK> AAAAAAAARRRGGH!
* StevenK kills thom
<infinity> Don't talk smack about Kriss Kross.
<Mithrandir> I think we should all stab calc for starting this conversation.
<thom> or salt'n'pepa
<StevenK> Agreed
<StevenK> GAAH
<infinity> thom: Zofia and I were dancing to SnP, no less than two weeks ago...
<thom> Mithrandir: defenestration from the 27th floor would do the job admirably
* StevenK twitches
<infinity> (At a metal club, no less...)
<thom> infinity: post-ironic!
<seb128> doko: new ant doesn't want to build on amd64
* StevenK convulses
<Mithrandir> thom: true.
<StevenK> (While Slayer plays)
<doko> seb128: seen, but builds in debian unstable :-/
<calc> Jump! Jump! ;)
<Hobbsee> Mithrandir: no, i suggest just locking him in a basement indefinetly, so the only thing he can do is fix ooo
<thom> jump up jump up and get down
<StevenK> calc: GAH! DIE!
<calc> Hobbsee: hmm i'm glad Mithrandir is leaving tonight then ;)
<Hobbsee> calc: he can still harm you before then.
<seb128> doko, pitti: http://launchpadlibrarian.net/8471718/buildlog_ubuntu-gutsy-amd64.ant_1.7.0-1_FAILEDTOBUILD.txt.gz
<calc> thom: hmm thats another group, that i forgot who it is
<thom> calc: house of pain?
<seb128> "GC Warning: Out of Memory!  Returning NIL!"
<calc> thom: hmm probably so
<thom> hey, bad 90s rap
<thom> hammertime!
<StevenK>  /part
<calc> wasn't that 80s
<StevenK> Hammer was early 90s
<StevenK> And I don't know how or why I remember that.
* StevenK bashes calc's and thom's heads together. Now shush!
<calc> hmm right at 1990
<calc> thats why i thought it was in 80s
* Hobbsee blames mvo 
<thom> mvo: afternoon
<nny> Hello, I am interested in hosting a repository for a specific set of packages. I plan on doing this in combination with re-authoring a live cd  stripped down specifically with a particular purpose in mind. I also think it would be wise to allow others to use the version of ubuntu I have created. I know about naming conventions that are not allowed, but want to make sure I am going about this the correct way. Any advice is a
<nny> ppreciated. I can be specific if asked
<geser> pitti: Hi, do you have an idea why the crash bug team for universe is subscribed to a crash report for a package in main?
<pitti> infinity: I just kicked ubuntu livefs builds; on king it works, but on terranova it failed due to obsolete apt (failure to install tasks); is that just a mirroring race condition? BuildLove.out is not very helpful since it does not show any versions
<pitti> infinity: s/Love/Log/ (erk)
<zul> pitti: fixed
<pitti> zul: thanks
<infinity> pitti: I'd assume the chroot auto-updating hasn't/hadn't happened yet.  It's daily.
<infinity> pitti: I can do it manually, if you need to test.
<pitti> infinity: ah, ok; I just wondered why it was done on amd64 already (current live images should be good)
<pitti> infinity: nevermind, it'll settle over the weekend
* bryyce introduces scislac and seb128
<seb128> hi ScislaC
<bryyce> seb128: http://pastebin.ca/617871
<ScislaC> hi seb128
<ScislaC> note that all updates are generally done via synaptic on my system
<ScislaC> but dpkg with forcing or purging don't scare me if you need me to do it
<ScislaC> don't = doesn't ;)
<seb128> ScislaC: do you get the same error if you run sudo gtk-update-icon-cache /usr/share/icons/hicolor?
<ScislaC> seb128: yes... the "bad image index" and "The generated cache was invalid."
<seb128> ScislaC: does it work if you move /usr/share/icons/hicolor/icon-theme.cache somewhere else and then retry?
<ScislaC> seb128: same error
<seb128> weird
<ScislaC> heh... that's not to reassuring :)
<seb128> you likely have something installed there that confuse the cache
<shirish> seb128: I have similar issue but with openoffice stuff. please see http://paste.ubuntu-nl.org/29798/ & if there is a specific bug no. associated with it , the icon theme stuff it would be nice.
<seb128> shirish: this one is an openoffice bug and fixed version has been uploaded yesterday
<ScislaC> to=too (damn fingers)
<seb128> that's due to the lack of index.theme
<shirish> seb128: I just updated to the fixed version now.
<seb128> ScislaC: for some reason your cache seems to be corrupted, dunno why
<ScislaC> seb128: any way to clean it out and make it happy?
<simira> desrt: are you in London?
<seb128> ScislaC: maybe you have installed a package which put a broken image to /usr/share/icons/hicolor, not sure how to figure if that's the case and which one though
<ScislaC> seb128: the thing is, this all started with official updates... as I haven't installed anything "new" in at least a month (by new I mean other than what ubuntu-desktop adds itself)
<seb128> ScislaC: when did it start?
<ScislaC> seb128: roughly a week ago
<seb128> ScislaC: did you open a bug?
<ScislaC> but I figured it was all part of the normal testing/upgrade woes
<azeem> W 2
<ScislaC> seb128: it started with packages that there were known issues with, so I didn't file anything new
<azeem> oops, sorry
<seb128> ScislaC: ls /usr/share/icons/hicolor ?
<ScislaC> but it spread from there
<seb128> ScislaC: well, you icon cache gets corrupted for some reason, there is one bug about somebody else getting similar problems but lot changed in a week and it's better to report issues when they start
<ScislaC> seb128: http://pastebin.ca/617889
<seb128> ScislaC: dpkg -S /usr/share/icons/hicolor/autopackage-installer.png ?
<seb128> ScislaC: does it work better if you remove that file
<shirish> -S is for show?
<ScislaC> seb128: if it hadn't have started with packages that others said they had issues with, I would have... given that I work with bryyce on Inkscape, I hate going through the tracker and dealing with closing tons of dupe reports.
<Hobbsee> shirish: search.  man dpkg
<ScislaC> seb128: said not found on that dpkg line
<seb128> ScislaC: yeah, looking at open bugs and try to not send a duplicate is a good idea usually ;)
<seb128> ScislaC: does removing it makes things better?
<ScislaC> seb128: hmmm... that seemed to help it... it generated the cache successfully
<shirish> Hobbsee: thanx :)
<seb128> ScislaC: ok, so you installed something out of the packaging system
<seb128> which installed this icons at the wrong place
<seb128> and break the cache generation
<seb128> might be some autopackage crack
<seb128> not an Ubuntu bug ;)
<seb128> though GTK+ should deal better with those
<ScislaC> seb128: I haven't touched my autopackage stuff in over 6 months though
<ScislaC> so this just surfaced due to other things getting better and seeing the issue?
<bryyce> scislac, could that bad icon have come from an inkscape build?
<seb128> ScislaC: maybe GTK+ was not so sensitive about it
<shirish> Hobbsee: the lo color KDE1 (icon stuff) is also part of 125400 or is there a different bug filed for that? I ask as I have only GNOME & XFCE so that icon stuff should not be there. http://paste.ubuntu-nl.org/29798/ for reference
<Hobbsee> shirish: i believe calc answered that?
<ScislaC> bryyce: I would sure hope not... I compile myself and the AP was for something from forever ago
* ScottK wonders about maybe another package being corrupted by the same debconf (was it debconf) problem that bit OOO?
<shirish> Hobbsee: he said that upstream should remove it, If somebody has filed a bug in launchpad about it giving some reference to a bug filed upstream, I would like to subscribe to it.
<Hobbsee> shirish: then i suggest you search for said bug.
* Hobbsee is not the walking dictionary, particularly on bugs that are not in kde* packages
<seb128> ScislaC: thanks for the bug report and the help debugging it ;)
<shirish> Hobbsee: I'm not trying to be difficult, I dunno what to search for, is there a package named locolor or what?
<Hobbsee> shirish: apt-cache search locolor will tell you that, apt-cache madison will show you what the source package is.
<shirish> oh ok, I need to get a hang of both this things
<Hobbsee> i dont know much about locolor, iconcache, and the like
<ScislaC> seb128: hey, thank YOU for helping solve that :)
<shirish> Hobbsee: both things returned empty :(
<Hobbsee> shirish: then it's not a package
<ScislaC> maybe I'll finally be able to get back into Gnome once the packages get right...
* ScislaC crosses fingers
<Hobbsee> shirish: as in, the first will find the binary packages, and the latter will tell you the source package, among other things
<simira> where's the nearest place to get smoe chocolate here?
<Hobbsee> simira: haha
<Hobbsee> simira: no chocolate for you!
<simira> Hobbsee: oh, yes. I'll just have to wait until after dinner ;) And that's in an hours time.
<Hobbsee> simira: awwww
<Hobbsee> simira: darn you.  i'm wanting some chocolate now!
<simira> can someone push Tollef in my direction?
* Hobbsee hands simira a large lassoo
<mikmorg> cjwatson: Hello
<ubuntuEdgy> helooo
<simira> Hobbsee: yihaa!
<Hobbsee> simira: :)
<Hobbsee> simira: now, i'll need that back, before i next have to go into work
<simira> Hobbsee: sure, here you go. Hope I won't need it in Birmingham
<Hobbsee> :)
* Hobbsee ponders bed.
<jcole> anyone here own a gps device and use it on linux? is there any drive by turn gps software in ubuntu?
<mjr> this is not the channel you're looking for
<mjr> you may go about your business
<jcole> ya, sorry, i posted in #ubuntu
<ScislaC> seb128: I hate to bug you... so now that I can finally get back in Gnome (yay!), it doesn't looks like gtk themes are working... no matter what I choose it doesn't change anything... any command-line way to debug this?
<jcole> ScislaC: try running gnome-settings-daemon
<ScislaC> jcole: whoa... that got everything back to normal... any ideas as to why that didn't start? (going to check my sessions now)
<jcole> ScislaC: are you running something funky like XGL
<ScislaC> jcole: yes... but this didn't happen before
<jcole> ScislaC: there you go... gnome-settings-daemon needs to run on the same DISPLAY as gnome is running on
<jcole> ScislaC: XGL is an evil hack that does not work well
<jcole> ScislaC: if you are using ati, use the open source driver with aiglx and regain sanity
<ScislaC> jcole: agreed... and ATI sucks for not letting me use AIGLX ;)
<ScislaC> my current card isn't supported by the radeon driver
<ScislaC> jcole: but I'm curious as to why this changed... seems weird because as of last week gnome-settings-daemon launched on the correct display. Eh, either way... thank you for clearing that up for me :)
<jcole> ScislaC: maybe check your gdm script
<jcole> ScislaC: an ubuntu update might have set it "back"
<wasabi> hmm, do we have a prefered inetd?
<geser> does Ubuntu install a inetd at all by default?
<wasabi> don't think so
<Rod> Hi
<Rod> i read the topic. ... but still :p You people have the knowledge to help me here
<Rod> wireless network works under 7.07, under gutsy it doesnt. I copied over the old interfaces file but that isnt enough. Module is the same. What else do i have to copy over to have the exact same network settings ?
<ScottK> Rod: Try #ubuntu+1
<Rod> thanks ScottK , wasnt aware of that one :)  Goodday'
<munckfish> slomo: have you got time to chat about https://bugs.launchpad.net/ubuntu/+source/service-discovery-applet/+bug/96433?
<ubotu> Launchpad bug 96433 in service-discovery-applet "[apport]  service-discovery-applet crashed with GError in connect()" [Undecided,Fix released] 
<mikmor1> cjwaston: ping
<cjwatson> mikmor1: offline until Monday in about one minute
<cjwatson> got your mail though
<mikmor1> cjwatson: Thanks
<cjwatson> mikmor1: ... and you have mail now. I hope it works :-)
#ubuntu-devel 2007-07-14
<nysosym> hi there
<nysosym> does gutsy use the madwifi driver from svn out of the box actually?
<okaratas> hello
<crimsun> pong.  I saw your update for flashplugin-nonfree (please remember to update debian/config, too), thanks!
<crimsun> err, asac ^
<Nafallo> :-)
<okaratas> hello
<Arcer> hi al is there someone?
<Arcer> *all
<geser> !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.
<Arcer> :)
<Arcer> i work every day also in the weekend
<ion_> I wonder whether it would be feasible to use the graphics card memory as swap space?
<Nafallo> haha
<persia> ion_: http://hedera.linuxnews.pl/_news/2002/09/03/_long/1445.html (and many others)
<Nafallo> :-)
<ion_> persia: Thanks :-)
<minghua> Wow, I thought it's just a crazy idea.
<ion_> Well, the video RAM is obviously faster than HDDs.
<ion_> And with recent GPUs, theres a *lot* of it.
<persia> minghua: It's arguably not very useful, as there's only a little VRAM, but with the right priority settings for swap, and limited texture usage, it can certainly improve performance for low-memory situations.
<minghua> persia: I am not expecting it to be very userful.  I just appreciate the hack value. :-)
<minghua> I'll by more RAM (or a new computer, for that matter) if I really encounter low-memory situations too frequently.
<ion_> For instance, i only have 384 MiB of memory in my desktop box, and rather than buying expensive DIMM, ill try to save for a completely new computer. However, my GPU has 128 MiB of memory. I could envision using 64 MiB of that as fast swap space, which would already make a nice difference.
<persia> ion_: Just don't try for a full immersive 3D environment while you've got the swap on :)
<jetole> hey guys, I know this is may not be the right room but developers always know more, I myself am I light weight C guy, and typical #ubuntu room seems full of simple questions and no one who has answered yet, I have two ubuntu feisty x86_64 machines, I am trying to do luks based encryption on my laptop and after many errors + wen searching + trial and error I found that /dev/.static/dev was empty where on my other ubuntu box it had 1962 entries, r
<jetole> ight now I only need /dev/.static/dev/mapper but as a tmpfs file system I know it will be gone after each reboot, is there a package I need to install or an error I need to file because this has seemed a little difficult to google
<jetole> also if there is a man page I sure as hell don't know where it is
<AggieSawDust> can anyone point me to some good docs on setting up a cross-compiling env in Ubuntu?
<Hobbsee> ***anyone who is bored, please fix stuff on http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html - there are various main people around who can sponsor changes ***
<jetole_> hey guys, I hate to ask, but I asked a question earlier that no one responded to, long story short I solved it to the next level but I am a little confused, /dev/.static/dev didn't exist on my computer because basically I have traced it down to mount --move was failing with the "wrong fs type, bad option, bad superblock" etc error, now I have tried it with several different test directories and I cannot get --move to work howev
<jetole_> er I tested it with test directories on another computer, bith x64, both 7.04 and it works fine, does anyone know what cause mount --move to fail or how I may be able to fix it?
<jetole_> again, I don't typically ask questions in this room and rarely in any room but #ubuntu seldom seems to have any answers and I seldom seem to have any questions
<Hobbsee> hi seb128
<seb128> hey Hobbsee
<StevenK> seb128: Back home again?
<seb128> StevenK: no, going to GUADEC today, still in London
<Hobbsee> seb128: i suppose it's technically the weekend, but do you have a list of highlights for ubuntu, for tribe 3?
<seb128> Hobbsee: "highlights"? you mean what's new since tribe-2?
<Hobbsee> seb128: yes
<Hobbsee> seb128: i dont really follow ubuntu that much, you see :)
<seb128> GNOME 2.19.5
* Hobbsee has just been asked to go pick up dinner, but will read the scrollbakc
<seb128> I don't think so much changed this week
<seb128> there is the new GNOME
<seb128> Hobbsee: enjoy
<Hobbsee> right
<Hobbsee> will do :)
<Hobbsee> new kde packages, too
<Hobbsee> seb128: thanks :)
<calc> i'm stuck in gatwick, flight delayed 2.5hr :(
<Hobbsee> calc: oh dear :(
<Hobbsee> calc: you didnt want to go anywhere, did you?
<wolfeon> ugh
* Hobbsee --> Dr Who
<calc> Hobbsee: heh, home would be nice
<calc> by the time i get home i will have been up ~ 19hr
<calc> on ~ 5hr sleep, not enough for me :\
<calc> i wish i knew the flight was delayed before i went to the airport
<ion_> Using video RAM as swap space seems to work fine. :-)
<persia> ion_: Now launch vegastrike :)
<TheMuso> Video ram as swap space? Never thought that could be done.
<persia> TheMuso: It's been an experimental feature for a few years now, but it requires careful balance, and a good reason (VRAM is typically more expensive than DRAM)
<TheMuso> Ah.
<ion_> My servers VRAM only gives FFFFFFFF, even if i try to write stuff there.
<mjr> bah, there were old, old patches to swap onto a gravis ultrasound in circulation in the mid-90s already, similar stuff :] 
<ion_> The nice thing is that this worked with the default Ubuntu kernel image+modules. :-)
<jbailey> Where is the Ubuntu package policy kept?  I remember that I'm supposed to twiddle the maintainer field when uploading a -ubuntu version, but I can't for the life of me remember what I'm supposed to do.
<Hobbsee> jbailey: w.u.c/DebianMaintainerField? looking
<jbailey> Is there some sort of a unified policy document like Debian's where I can find all the things that I'm supposed to remember in one place?
<Hobbsee> jbailey: https://wiki.ubuntu.com/DebianMaintainerField
<Hobbsee> but the mailing list post says it more clearly than that, i'll have to find it
<Hobbsee> jbailey: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2007-February/000249.html
<jbailey> Hobbsee: Thanks!
<Hobbsee> jbailey: no problem :)
<Mithrandir> desrt: you at guadec yet?
<pitti> hi Mithrandir
<Mithrandir> hiya Martin
* Hobbsee waves to Mithrandir and pitti 
* pitti hugs Hobbsee 
* Hobbsee hugs pitti 
* simira waves from Birmingham
<pitti> simira: have fun at guadec!
<Hobbsee> hi simira
<simira> pitti: I won't attend guadec, actually, just dropping by here as well :)
<Hobbsee> i dont suppose anyone around here has moderation rights to ubuntu-devel-announce?
<Mithrandir> Hobbsee: you're wrong. :-P
<Hobbsee> Mithrandir: oh good.  please approve my post then
* Hobbsee was vaguely hoping that she was wrong
<Mithrandir> done
<Hobbsee> thanks :)
* Hobbsee hugs Mithrandir 
<Mithrandir> np :-P
<Mithrandir> s/P/)/
<Hobbsee> :)
* Hobbsee decides to poke about the greasemonkey scripts from UDS later, it being a sunday and all
* ..[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 |  Main will freeze on Tuesday for Tribe 3
* ..[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 |  Main will freeze on Tuesday for Tribe 3 preparations
<Hobbsee> oh $%&&*
<Hobbsee> Mithrandir: okay, can you approve the new mail please?
* Hobbsee notes that writing important mailing list posts at 2.30am isnt the smartest idea in the world!
<Mithrandir> Hobbsee: *cough*. :-P  Will do
<Mithrandir> would you care to strip out the bits you're not correcting there?
<Hobbsee> Mithrandir: was wondering about that.  figured people would want to read the entire mail in one hit.  *shrugs
<Hobbsee> Mithrandir: and :P back to you.
<Hobbsee> Mithrandir: not sure on mailing list protocol there - i just went on the basis that i'd find it helpful to have the entire mail in one place, so that people could use it for reference
<Hobbsee> er, *and* so that....
<Hobbsee> ze brain is gone.  who stole my brain!
* Mithrandir munches on Hobbsee's brain
* Hobbsee goes on a hunt for the brainstealer.
<Hobbsee> YOU!!!!
* Hobbsee pokes Mithrandir 
<Mithrandir> I'm innocent!
<Hobbsee> no you're not.
<Mithrandir> I found it lying about, all by itself
<Hobbsee> why dont i beleive you?
<Hobbsee> sure sure...
<Mithrandir> people have traditionally done otherwise, but *shrug*; since you want it that way. :-P
<Hobbsee> Mithrandir: next time i'll get the link right, first time :P
<Mithrandir> Hobbsee: sure, no worries.
<Hobbsee> Mithrandir: thankyou again.  i hope to find no more errors in them :)
<kylem> is dh_iconcache/dh_icons still broken?
<ScottK> It's supposed to be fixed.
<ion_> Why was dh_iconcache replaced with dh_icons?
<tritium> The recent upgrade on flashplugin-nonfree (9.0.48.0.0ubuntu1~7.04.0) actually _removed_ flash support for me, as an md5sum mismatch occurred, the plugin did not install.
<ScottK> tritium: Known issue that's being worked.
<tritium> ScottK: okay, thanks
<tritium> Didn't see indication on that on Launchpad, but good.
<gnomefreak> tritium: i have it fixed
<gnomefreak> tritium: should be in feisty soon
<gnomefreak> i hope
<gnomefreak> tritium: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/125986
<ubotu> Launchpad bug 125986 in firefox "No flash after update of flashplugin-nonfree" [Undecided,In progress] 
<aquo> hi
<aquo> i use feisty and have a question
<aquo> my syslogd has a pid of over 4000
<aquo> i am just asking myself if everthing is right with the boot process of my machine, or if any of the inital scripts eats my pids
<mjg59> A lot of processes get run in the initramfs
<aquo> more than 3000? i think kernel reserves pid under 1000, but and then they go up step by step ...
<mjg59> Why's it a problem?
<tritium> nice, gnomefreak ;)
<gnomefreak> tritium: :)
<aquo> mjg59: it is no problem, i'm just analyzing the bootup process
<aquo> mjg59: i am curious which process are getting started
<ijuz__> there is some tool that can produce graphs of the boot process and shows what process runs when
<aquo> ijuz__: i know, i am consultant for embedded linux and and used that for performance analysis
<aquo> ijuz__: it is bootchart
<ijuz__> good
#ubuntu-devel 2007-07-15
<dieguito> hey everyone, any kernel hacker around? I could use some help getting one of ubuntu's patches, I'm a little lost on how to do it
<crimsun> which "one of ubuntu's patches"?
<dieguito> there's a wireless driver called rtl818x, I happen to have this card, I was looking for getting this patch on a debian custom kernel, but I don't know how to get the patch from ubuntu's kernel git (that I recall is where I tried getting it)
<dieguito> this driver is not maintained anymore upstream, so ubuntu's patch is the best working version out there
<crimsun> so you need to clone ubuntu/ubuntu-gutsy-lum.git, and look in /ubuntu/wireless/rtl818x
<hunger> My ubuntu box (gutsy) keeps sending broadcasts to port 8765 every 3s. Any idea what might be causing that?
<ynezz> tcpdump it :)
<jdong> ynezz: won't tell what program did it.... :(
<ynezz> maybe there is some text inside those packets
<hunger> ynezz: google says that port is used by ultraseek-http (whatever that is).
<jdong> hunger: you wouldn't have installed icecream, would ya? ;-)
<hunger> jdong: Possible...
<jdong> because it announces its availablity via 8765/udp
<jdong> :)
<hunger> jdong: That probably is it then!
<jdong> rather, finds the scheduler by broadcasting on 8765
<hunger> jdong: Thanks! I was already getting worried:-)
<jdong> :)
<jdong> np
<jdong> http://gentoo-wiki.com/HOWTO_Setup_An_ICECREAM_Compile_Cluster#Icecream_and_firewalls
<hunger> jdong: Yes! It was icecream!
<jdong> yay!
<mjg59> Mithrandir: How much of the osso environment are we supposed to have packaged?
* Hobbsee waves
* geser waves back
<Hobbsee> :)
<geser> Hobbsee: what's your impression for bug #114855? should it perhaps be milestoned?
<ubotu> Launchpad bug 114855 in linux-ubuntu-modules-2.6.22 "prism54 and other wlan drivers missing in kernel 2.6.22" [High,In progress]  https://launchpad.net/bugs/114855
* Hobbsee --> dinner
<geser> I'm biased as the bug affects me and the reason why I still run the feisty kernel on my gutsy system
<Hobbsee> geser: i would.    i'll ask benc about it when he's online
<Hobbsee> if not, then i'll either unmilestone it, or change the milestone
<Hobbsee> it's his call, though, eventually
<Hobbsee> (i'm not srue if we get another kernel before this tribe)
* Hobbsee --> really off at dinner
<geser> thanks
* Hobbsee comes back
* Fujitsu sends Hobbsee away.
* TheMuso seconds Fujitsu.
<Hobbsee> hah.  that's nice of you
<TheMuso> You know what I mean.
* bluefoxicy notices upgrading directly from fresh Feisty to Gutsy requires .. so far... apt-get dist-upgrade; apt-get -f install
<bluefoxicy> gedit breaks.  It goes "ONOES WRONG GEDIT INSTALLED HELP" and apt goes "Well.... install the upgraded version dumbass"
<siretart> mjg59: around? What do you think about the patch in bug #119052?
<ubotu> Launchpad bug 119052 in initramfs-tools "[gutsy] ibm-acpi -> now thinkpad_acpi possibly causing problems" [High,Confirmed]  https://launchpad.net/bugs/119052
<Hobbsee> hiya siretart
<siretart> heyho Hobbsee :)
<Hobbsee> :)
<Keybuk> mjg59: you know we were talking about the lack-of-association-event?
<Keybuk> mjg59: it appears that problem still does exist
<Keybuk> but is somehow masked by the use of WPA
<Keybuk> on my home network, I still have to prod it
<Hobbsee> BenC_: do you plan to push another kernel revision before gutsy tribe 3?
<BenC_> Hobbsee: not planning to, but doesn't mean it wont happen
<Hobbsee> BenC_: okay.  how much of http://people.ubuntu.com/~ubuntu-archive/testing/gutsy_probs.html is your domain?  (vs the xen stuff, which i believe is zul's?)
<mjg59> Keybuk: Could well be the case
<mjg59> That may not have got re-merged yet
<BenC_> Hobbsee: xen stuff is pkl's (Phillip Lougher)
<Hobbsee> BenC_: oh right.  even better then, thanks :)
<Hobbsee> BenC_: wasnt aware that the person had changed.
<mjg59> siretart: Unless we merge more recent ibm-acpi code, it's as good as it's going to get
<BenC> Hobbsee: but xen is universe for now, so it doesn't apply to tribe-3, IMO
<BenC> if the bugs get fixed and it is proven stable, then it moves to main :)
<Nafallo> mjg59: you're pushing everything from that powertop-thingie to Ubuntu I guess? :-)
<Hobbsee> BenC_: okay, stupid question then - why's it showing on gutsy_problems, which i thought was main only?
<Hobbsee> or does that do sources in main, whihc can include binaries in universe?
<BenC> Hobbsee: ah, linux-image-xen is uninstallable because that meta package should be in universe
<mjg59> Nafallo: Right now I'm trying to write a thesis
<BenC> Hobbsee: backports-modules will get uploaded before tribe-3 as well
<Nafallo> mjg59: aha. that's where you went :-)
<mjg59> I'll work on this stuff as much as possible
<mjg59> But I'm moderately time limited right now
<BenC> Hobbsee: all the kernel related sources are in main, but some binaries go in universe, and the meta packages didn't get there
<Hobbsee> BenC: ah, right, i see.
<Nafallo> understandable :-)
* Hobbsee will ask pitti or someone to demote the xen stuff, then.
<BenC> Hobbsee: same for the lrm and lum -xen packages, they should go into universe as well
<Hobbsee> yep
<BenC> mjg59: hey, you still in london, or back home now?
<mjg59> BenC: Cambridge until Tuesday
<mjg59> Then Birmingham until Saturday, then Portland
<Hobbsee> ...and libvrt, it looks like.  as well as getting a rebuild.
<siretart> mjg59: I see. do you want me to upload acpi-support with that, or do you have other changes in the pipe?
<mjg59> siretart: Feel free
<siretart> k
<regis> hello, can anyone tell me how to warn the maintainer of flash that their package has a problem(md5sum mismatch install_flash_player_9_linux.tar.gz)
<Arby> regis: the usual way would be to file a bug in launchpad but I'm pretty sure that's already a known issue
<regis> Arby, ok thanks
#ubuntu-devel 2008-07-07
<pwnguin> ScottK: it's my intuition that releasing 8.04 on time was imperative in "proving" that the cycle worked; certainly shuttleworth couldn't have written a slightly daring piece declaring victory for the schedule and asking other distros to try it
<pwnguin> ScottK: a more comprehensive review of the SRUs for hardy might demonstrate the point; I know some people irate about the kernel scheduler
<ScottK> pwnguin: I won't speculate in advance of the facts.  I think additional analysis would be useful.
<greg-g> if a program, to be fully useful it must be called from the CLI (some options only available when starting with various -switches) should it have a .desktop file?
<greg-g> this is probably a "depends" questions question, so, I'm looking at bug 243776
<ubottu> Launchpad bug 243776 in japa "No Desktop file in japa" [Low,Confirmed] https://launchpad.net/bugs/243776
<persia> greg-g: Looking at the manpage, there seem sane defaults.  Whether to call `japa -A` or `japa -J` in the .desktop file is a matter for debate.
<persia> Personally, I'd advocate -J, as I believe the goal is to abstract ALSA, and move to JACK and pulse clients for the most part.
<greg-g> persia: agree
<greg-g> persia: but, personally, -J doesn't work on my machine
<greg-g> so, my inclination is to say "no" to a .desktop file right now
<persia> greg-g: Did you start JACK before calling that?
<greg-g> persia: no :)
<greg-g> I have no experience using/starting JACK
<persia> greg-g: Install qjackctl, run JACK Control from the menu, click Start.
<persia> I like to use Patchage to manage the connections.
<persia> Anyway, that shouldn't block the .desktop file.  There are several applications that fail to start without a running Jack that ship .desktop upstream.
<greg-g> persia: ahh, didn't know that
<greg-g> persia: so is your opinion to create the .desktop file with "japa -J" as the command?
<persia> greg-g: Yes, although I anticipate that this will generate a bug that japa doesn't work with ALSA by default, and a bug that japa ought detect and start JACK if not previously running.
 * greg-g nods
<persia> Of these, I'd consider the former wontfix, as I expect most users who need that would do better with JACK than ALSA.  The second would be a real bug, but the appropriate solution hasn't been determined (and several strategies to make it "just work" have been shown to not be ideal)
<greg-g> sorry, one moment
<greg-g> persia: (phone interruption) ok. so I'll then learn the syntax of a .desktop file and attach a diff to that bug report, and we'll deal with the real bug as it comes
<persia> greg-g: Sounds good.
<greg-g> persia: thanks for the advice
<saivann> Can a ubuntu developer consider merging available branch in bug 66760 for usplash to the current intrepid development release?
<ubottu> Launchpad bug 66760 in usplash "palette indexes in eft-theme.c should not be prefixed with 0x" [Low,Confirmed] https://launchpad.net/bugs/66760
<dholbach> good morning
<ion_> Hi
<dholbach> hi ion_
<Hobbsee> hey dholbach!
<dholbach> hi Hobbsee
 * calc upgraded to 6GB ram, 1TB hd :)
<TheMuso> calc: nice.
<calc> i should have plenty of room for a mirror now :)
<TheMuso> heh
<pitti> Good mornin
<pitti> g
<ion_> Hi
<Hobbsee> hey pitti!
<dholbach> can sombody please unsub ubuntu-archive from 245706
<Hobbsee> dholbach: i'm not sure that's possible
<dholbach> everybody who's in the team can unsubscribe the team
<Hobbsee> yes, but how?
<dholbach> https://bugs.launchpad.net/ubuntu/+source/hnb/+bug/245706/+subscribe
<Hobbsee> do i need to switch to production to be able to unsubscribe people?
<ubottu> Launchpad bug 245706 in hnb "Please sync hnb 1.9.18-4 (universe) from Debian unstable (main)" [Undecided,New]
<dholbach> it's not very obvious and I talked to the LP folks about it
<dholbach> it's the "subscribe ... yourself" link
<Hobbsee> oh, you have to manually type +subscribe
<Hobbsee> oh, i tried the subscribing other people link
<dholbach> no, click on the "yourself" link
<dholbach> yeah
<Hobbsee> hm, that worked.
<dholbach> gracias
<Keybuk> don't suppose anyone know the last known xserver-xorg-video-intel to work?
<Hobbsee> Keybuk: the current intrepid one?
<Keybuk> IT DOESN'T WORK
<Keybuk> oops, the caps were not deliberate, but nonetheless warranted
<pitti> Keybuk: compiz breaking for you as well? (white screen)
<RAOF> You know, I sometimes wonder if I run the same devel release as everyone else...
<pitti> happens for me with both the hardy and intrepid kernel
<Hobbsee> RAOF: yeah...
<RAOF> That'll be something in the new mesa stack, right?
<pitti> RAOF: it's pretty broken for me anyway (usplash horribly mangled, suspend broken, X black with usplash, compiz breaks with just white screen)
<Hobbsee> Keybuk: hm, maybe i haven't tried the most recent version then.
<Keybuk> pitti: yup
<Hobbsee> RAOF: yeah, me as well.  particularly with things like graphics, and wifi cards not working.
<RAOF> pitti: That wasn't a comment on this particular issue (I don't _have_ an intel card), just my general lack of development problems.
<RAOF> Nothing ever seems to go wrong.  At least, not so that I notice and remember :)
<pitti> RAOF: lucky you :)
<RAOF> Indeed.
<Hobbsee> Keybuk: i'm hoping to avoid yelling here, but i've had 2:2.3.2-1ubuntu3 working here with no problems earlier.
<Hobbsee> that being said, i probably don't have the rest of the new X stack installed yet
<RAOF> Has it made it out of NEW yet?
<Iulian> Good morning.
<tjaalton> RAOF: I'll upload a new mesa/xorg-server soon, should fix sparc/hppa/ia64 FTBFS's
<tjaalton> so after that we'll be able to rebuild the drivers etc
<tjaalton> the stack is not ready yet
<RAOF> Right.  I wasn't sure whether it had settled yet.
<RAOF> Our X isn't getting built with dri2 support, right
<RAOF> ?
<tjaalton> no, needs TTM
<tjaalton> ie. libdrm from master
<tjaalton> er, modesetting-101
<RAOF> Right.  Suspected as much.
<RAOF> Or, presumably, the gem branch?
<tjaalton> that could work too
<Amaranth> I thought the consensus was that DRI2 would make GEM calls since it only does some base things and DRI2 needs a stable API to call
<Amaranth> TTM could be used on top of GEM for drivers where it makes sense
<tjaalton> Amaranth: could well be, I've given up hope of understanding where we stand currently ;)
<Amaranth> I just tried to catch up today
<Amaranth> Still completely lost
<tjaalton> if libdrm 2.4.0 has GEM support in it, we can revisit DRI2
<tjaalton> hehe :)
<Amaranth> But hey, I have intel hardware now so I want me some GEM :)
<tjaalton> me too :)
<tjaalton> and yes, seems like radeon uses some TTM-GEM hybrid
<tjaalton> er, will use. there's a branch on airlied's git
<Amaranth> Next person to invent a memory manager gets stabbed with a spork
<tjaalton> Amaranth: slow and painful ;)
<RAOF> I think there's been some work in nouveau, somewhere, with TTM, too.
<RAOF> Amaranth: A mutant, 1/16 fork 15/16 spoon?
<tjaalton> http://en.wikipedia.org/wiki/Spork
 * RAOF was referring to the xkcd.
<Amaranth> RAOF: That's 1/4 spoon 3/4 spork
<Amaranth> They crossed a spoon with a spork
<RAOF> Right.  But they _could_ get to 1/16 fork, 15/16 spoon.
<RAOF> And it wasn't their spoon/spork cross that ran rampant, anyway :)
<Amaranth> I think it needs more fork to be stabby
<ion_> raof: I heard theyâre doing that at CERN, but there are concerns the process might start a chain reaction that destroys the entire universe as we know it.
<RAOF> ion_: Nah.  They're just planning to kill pideons with a relativistic proton beam.
<Amaranth> ion_: Does it make the universe run on happy thoughts?
<ion_> Iâd like to have a quantum spork. The spoon/fork proportion of one collapses when observed.
<ogra> who does NEW today ?
 * ogra has usb-imagewriter sitting in intrepid waiting for a friendly hand ....
<pitti> ogra: Monday is Steve's archive day
<ogra> ok
<ogra> then i'll ask later again :)
<pitti> tjaalton, bryce: xdmx{,-tools} and xserver-xfbdev -> main or universe?
<tjaalton> pitti: I think universe will do
<pitti> tjaalton: oh, xdmx-tools was already in ubuntu universe since gutsy, then apparently removed in hardy, and now it comes back? :)
<tjaalton> pitti: right, it was brought back in the 1.5rc packaging
<tjaalton> apparently the build was broken for 1.4
<kantor> hi, if the SCSI sg driver SG_IO ioctl returns with error (not a 0 value) that means that in the status, masked_status, . . .  bytes nothing is stored (no useful information) ?
<kantor> so I check for the masked_status only if that ioctl returns with 0
<kantor> no ?
<Nubae> hi... asac quick question...
<Nubae> ï»¿do you know how the firefox app-id is created?
<Nubae> ï»¿ the id u have in ~/.mozilla/extensions/<browser-id>
<asac> Nubae: if you need a new one, you can use whatever you want
<cjwatson> uuidgen
<Nubae> ok, so for a new browser, one would just create it using uuidgen?
<asac> Nubae: uuid's have been used in the past. another way is to use a domain-scoped id like: superbrowser@yourdomain.org
<Nubae> ok thanks a lot
<Nubae> asac - ï»¿once we create the id - how do we tell our browser to use it?
<asac> Nubae: is that supposed to be xul application?
<asac> Nubae: if so, look at /usr/lib/firefox-3.0/application.ini
<jc-denton> i know this is not the place to ask
<jc-denton> https://bugs.launchpad.net/ubuntu-doc/+bug/235236
<ubottu> Launchpad bug 235236 in ubuntu-doc "ATI Driver Page needs updating" [Low,Confirmed]
<jc-denton> but i have the same problem
<jc-denton> and no idea what Lrun a dkms build for kernel 2.6.24-16-rt (i686) first." means
<jc-denton> because dkms build is for a specific module as far as i understand..
<jc-denton> so what shall i do?
<jc-denton> switch to windows?
<jc-denton> i'm using radeonhd right now but my laptop gets too hot
<jc-denton> http://rafb.net/p/Owo6cw84.html
<pitti> tjaalton: hm, now xserver-xorg-core is held back, and upgrade removes all video/input drivers; I take it this can be resolved by tomorrow? (alpha-2 soft freeze)
<Iulian> Riddell: Giver is in unstable so we can sync now.
<tjaalton> pitti: should be resolvable, all video/input drivers need to be rebuilt
<tjaalton> pitti: I'm just waiting for ia64 to catch up..
<pitti> tjaalton: ah, want me to bump a build score?
<tjaalton> pitti: that would be nice, yes
<pitti> which source?
<tjaalton> xorg-server
<tjaalton> hppa is currently building
<pitti> done
<tjaalton> thanks!
 * pitti hugs tseliot
<pitti> tjaalton: ah, ia64 buildds are still busy with gcc and subversion
<tjaalton> pitti: hum, ok
 * tseliot hugs pitti
<pitti> tseliot: looking forward to your reply
<tseliot> pitti: I'm reading your email right now ;)
<tjaalton> pitti: debian has three flavours of nvidia, but the sources are named differently
<pitti> are they using dkms, too?
<tjaalton> nope
<pitti> hrm, no, dkms isn't even in debian
<tjaalton> they have 'nvidia-graphics-drivers' (the latest version) and 'nvidia-graphics-drivers-legacy-{71xx,96xx}'
<tjaalton> which then produce nvidia-glx, nvidia-glx-legacy-{71xx,96xx}
<tjaalton> etc
<Mirv> pitti: your v4l-dvb dkms is the best thing since sliced bread
<pitti> Mirv: :-)
<pitti> Mirv: I was actually surpised that it flawlessly built on the intrepid kernel as well
<pitti> Mirv: hm, I don't even need that package any more on intrepid, the upstream drivers are recent enough
<Mirv> pitti: there are plenty of us around here using it for Anysee DVB support (to be included in 2.6.27)
<pitti> nice :)
<Mirv> dkms seems like ideal for things like v4l-dvb which needs updates constantly as new devices are bought by users and support added by v4l-dvb developers
<pitti> Mirv: indeed it is; I really like it
<tseliot> pitti: email sent ;)
<pitti> tseliot: replied again
<tseliot> pitti: ok
<pitti> tseliot: ... to the other mail, too
<tseliot> pitti: ah, ok, thanks
<tjaalton> duh, why doesn't 'dch -l foo' work when the version does not have 'ubuntu' in it?
<Hobbsee> tjaalton: because you actually want to use dch -Ul?
<Hobbsee> oh, hmm
<Hobbsee> scratch that
<ligemeget> Can someone explain to me why https://translations.launchpad.net/ubuntu says " The current translation focus for Ubuntu is 7.10 (Gutsy), and we encourage you to translate it first." ?
<cjwatson> ligemeget: thanks for the note; fixed to 8.04
<ligemeget> nice. thanks
<cjwatson> (I don't think intrepid is open yet, but even if I'm wrong it's still undergoing substantial skew)
<jdstrand> kees: fyi-- ruby1.9 built today in my schroot, so I pushed it to intrepid (not sure what changed in there, but the tests now complete without hanging)
<jdstrand> (in my up to date intrepid schroot that is)
<Kopfgeldjaeger> a new rhythmbox version will come out today
<YokoZar> pitti: *poke*
<pitti> eek
<ScottK> pitti: Would you please have a look at Bug #246118 and advise us on how to proceed.
<ubottu> Launchpad bug 246118 in wine "Wine 1.0 as a stable release update for Hardy" [Undecided,New] https://launchpad.net/bugs/246118
<ScottK> I'm comfortable with copying to hardy-updates, from hardy-backports.
<pitti> tjaalton: argh, still building; at this point I'd say, screw ia64 and build it later on that arch
<pitti> ScottK: in a minute, still having some three conversations going on, sorry
<ScottK> pitti: Thanks.
<pitti> ScottK: no library SONAME changes and the like, I figure?
<pitti> ScottK: I'm fine with that, given hardy's LTSness
<pitti> ScottK: however, I'd be a bit more comfortable with copying it to -proposed first, and/or getting some testimonials from other users first
<pitti> oh, it doesn't build a library any more, nevermind me
<pitti> ScottK: bug updated
<ScottK> pitti: Thanks.
<ScottK> YokoZar: ^^^ There you go.
<YokoZar> pitti: Thank you :)
<tseliot> cjwatson: can I have a word with you in private?
<cjwatson> tseliot: I'm afraid I'm just about to leave for some hours; feel free to leave me an IRC message, or e-mail me
<tseliot> cjwatson: I'll send you an email. Thanks
<kees> jdstrand: yay heisenbugfixes :)
<pitti> good morning kees
<kees> hi pitti! :)
 * ogra wonders if slangasek is around for a NEW package ...
<LucidFox> pitti, since you accepted f-spot, maybe you could review the gnome-keyring-sharp MIR?
<pitti> LucidFox: looking
<pitti> LucidFox: done, that was an easy one
<LucidFox> thanks!
<mkrufky> whats up with launchpad karma dropping all the time by itself?
<mkrufky> thats discouraging
<lamont> Function `ephy_window_get_active_embed' implicitly converted to pointer at seahorse-extension.c:242
<lamont> bad seahorse
<calc> the extra ram didn't do that much, but at least it will be helpful for vm's etc
<calc> er do much to speed up OOo i mean
<infinity> calc: Nothing speeds up OOo.
<Iulian> Riddell: Please don't sync giver yet. I am preparing another upload to Debian. I will let you know when it's ready to sync.
<calc> infinity: true, though its not too bad i guess, 55m35s real
<calc> i think it might have shaved about 9m off between the hd and ram upgrade
<tjaalton> pitti: hmm, that would mean another round of rebuilds just for ia64?
<_MMA_> slangasek: Should I add "vorbis-tools" to bug 201291 as packages are being added to it that generate vorbis files with the .ogg extension and not .oga. Maybe I'm reading it wrong?
<ubottu> Launchpad bug 201291 in mime-support "Add ogv (video) and oga (audio) as recognized extension for Ogg Theora and Ogg Vorbis, respectively" [High,Fix released] https://launchpad.net/bugs/201291
<scobby> hi everyone
<scobby> i am using hardy with new kernel from intrepid (because of wlan) after i rebootet my sound is a little bit buggy. i think sound output goes out of my system bell(not the speaker)
<scobby> but not every sound output
<scobby> when i start kvpnc the sound is crackling
<lamalex> scobby: /topic
<calc> 146m18 without cache, 55m35 with cache
<calc> still pretty slow :\
 * calc needs a quad core cpu
<Pupeno> What's the package for the Keyboard Layout configuration tool?
<enrico> Riddell: Hi.  It looks like in Hardy there's a version of Debtags with bug #472911 (Data files are embarassingly created in the wrong place)
<geser> kees, jdstrand: Hi, I'm not sure if you are the right persons but do you know which is a secure default for mode (3rd parameter) when calling open(..., O_CREAT, mode)?
<kees> geser: well, if it's only going to be used by the program itself, then just 0700 should be right
<kees> geser: or rather, S_IRWXU
<kees> or perhaps  S_IRUSR|S_IWUSR
<kees> since the file is likely not executable.  :)
<cjwatson> mkrufky: you should ask in #launchpad if you actually want to know, but I suspect that it decays somewhat over time so that karma gives current strong contributors preference over retired strong contributors
<kees> so, I guess I should add that to the wiki.
<mkrufky> yeah, i figured.  instead, it just made me not care
<mkrufky> i'll fix a bug if i can
<mkrufky> btu im not going to loko at the "karma" points anymore ... fump dat!
<geser> kees: there is a wiki page with suggested fixes for the error from the hardened gcc like "error: call to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments"?
<cjwatson> mkrufky: I'm afraid this is the wrong place to rant
<kees> geser: right, that's what I'm updating now.
<cjwatson> mkrufky: also, is it worth getting het up about a number? :-)
<mkrufky> cjwatson: im not ranting ...   i am still happily fixing bugs.  no problem
<wgrant> mkrufky: https://help.launchpad.net/YourAccount/Karma
<mkrufky> chill -- it;s all good.  i just asked why the points drop, i got my answer, gave a tiny commentary, and now i am back to fixing bugs again -- nobody is upset
<infinity> mkrufky: I'm sure your karma is better than mine, and I use launchpad more than most people do, so... Y'know... Don't complain. :)
<geser> kees: where is that page?
<wgrant> infinity: No karma for kicking buildds? Aw.
<kees> geser: https://wiki.ubuntu.com/CompilerFlags
<infinity> wgrant: No karma for anything soyuz-related.
<mkrufky> wgrant: thanks for that link
<geser> kees: thanks
<wgrant> infinity: This is true. Though it is meant to eventually be happening. ANd was targetted to 1.1.9.
<kees> geser: np.  I added the mode recommendations to it now.
<emgent> heya
#ubuntu-devel 2008-07-08
<tjaalton> archive admins available? xserver-xorg-video-cyrix can be removed from the archive. it doesn't build against the latest xserver, and it's deprecated anyway. the geode driver will/does replace it
<gnomefreak> tjaalton: ah i guess you saw the issue already
<tjaalton> gnomefreak: about cyrix?
<tjaalton> via should also be synced
<gnomefreak> tjaalton: no about X in general it looks like xserver-xorg-core is broken
 * RAOF thinks gnomefreak is talking about "the {video,input} ABI changed, so everything's uninstallable".
<gnomefreak> most likely respinning is all it is
<gnomefreak> ABI changed?
<gnomefreak> uninstallable hell it wants to remove everything
<tjaalton> input and video ABI
<tjaalton> don't force it
<gnomefreak> i dont
<tjaalton> just wait until it allows an upgrade
<RAOF> Wait until the world's been rebuilt
<gnomefreak> dist-upgrade wanted to remove it
<tjaalton> hm, it shouldn't upgrade
<tjaalton> ok, well don't :)
<gnomefreak> i know
<gnomefreak> just wanted to make sure you were aware of it
<tjaalton> of course
<tjaalton> was just waiting that all the archs had the latest xorg-server
<tjaalton> (and a bit occupied during the evening, but..)
<gnomefreak> no rush atleast for me
 * gnomefreak has alot fo work i can do as long as i dont use dist-* ill be fine
 * TheMuso thinks staying on hardy is a safer bet. :p
<RAOF> gnomefreak: Well, nouveau should now be installable, at least :)
<gnomefreak> TheMuso: stable is always safer just not so much fun ;)
<calc> does anyone know if there is a good debian/ubuntu mirroring program that acts as a proxy (that actually works)
 * calc is considering writing one in his spare time
<RAOF> You mean an apt-proxy?
<calc> RAOF: i guess
<calc> RAOF: iirc i used apt-proxy before but maybe not
<calc> i know approx doesn't work very well
<calc> it seems to nuke the archive for unknown reasons
<RAOF> There are a couple; apt-proxy, apt-something-else, apt-zeroconf.  But I'm using squid.
<calc> ok i'll have a look i have plenty of room for a full mirror but would rather it pull stuff as needed
<calc> but in the past the ones i have used seemed to not work correctly :\
<RAOF> apt-zeroconf (when it works) is pretty cool at that.
<calc> what package is it in? i don't see it in hardy
<RAOF> It's not yet packaged, at least officially.
<calc> ah
<calc> hmm i think i have used apt-cacher and approx before
<calc> approx definitely didn't seem to work right
<RAOF> I've used apt-proxy; that seemed to work pretty well.
<calc> i'll give apt-proxy a try
<RAOF> apt-zeroconf, if you're interested: http://trac.phidev.org/trac/wiki/AptZeroconf
<calc> thanks for the tips :)
<calc> the desc on the apt-proxy page leads me to believe it should work well and also why i thought it didn't (i think i tried it last back when it was unstable)
<RAOF> apt-zeroconf would be cool, particularly for laptops, if it were a bit more stable.
 * TheMuso uses apt-mirror, with a post mirror script to mirror other bits.
<TheMuso> Since I mirror 3 architectures, and have several boxes that need to download updates every day.
<TheMuso> Yow! Xorg flud! >)
<RAOF> TheMuso: As in "broken" or as in "every single Xorg package has been rebuilt"? :)
<TheMuso> RAOF: The flood of xorg related packages on intrepid-changes. I know why, but still, thats a lot.
<kirkland> slangasek: ping
<kantor> hi, I have renamed all the SCSI subsystem drivers (so Linux can't load them) and all the SCSI subsystem drivers are compiled as modules, but strangely the SG_GET_VERSION_NUM ioctl returns the sg driver version, how is that possible if the sg (and all the SCSI subsystem) driver was renamed and it is not loaded ??
<calc> i see one minor issue with apt-proxy already, it uses the name you put in your sources.list for its cache dir
<calc> so if you have different names on different machines it won't all pull from the same place
<TheMuso> calc: Ouch.
<superm1> slangasek, can you promote the mythbuntu alt disks to the right place now?
<calc> it appears apt-proxy doesn't handle versions kept properly for ubuntu 'distributions'
<calc> iow it deletes them once it reaches the limit number across distributions
<calc> gah apt-proxy has huge number of open bugs on b.d.o
<calc> it appears no partial mirror program works as i had found out before :\
<TheMuso> calc: I think you might be better off investing time into debmirror or apt-mirror, however I'd recommend apt-mirror svn over the hardy package.
<calc> TheMuso: ok
<TheMuso> calc: You don't have to, but thats what I think works better.
<calc> TheMuso: so is apt-mirror svn better than debmirror?
 * calc wishes one of them would just work properly, grr
<calc> from what i recall i wrote one myself about 8 years ago but never actually uploaded it anywhere
<calc> apt-proxy is probably a good place to work to get a partial one going properly, but seems to need lots of work
<TheMuso> calc: heh. I find apt-mirror from svn more flexible, as your configuration file is similar to sources.list. Debmirror has to be called multiple times if you need to pull from more than one source. For example, I would have to call debmirror twice, one for ports.ubuntu.com, and one for archive.ubuntu.com.
<TheMuso> Apt-mirror on the other hand does it all at once.
<TheMuso> However, apt-mirror doesn't yet support rsync.
<calc> oh ok
<calc> apt-proxy would really be ideal for me since i don't have much need for a full mirror but its too buggy :-\
<calc> so i'll have to try out apt-mirror after i sleep :)
<calc> midnight here now, so about time for bed
<dholbach> good morning
<TheMuso> Hey dholbach.
<dholbach> hi TheMuso
<Hobbsee> hey dholbach, TheMuso
<TheMuso> Hey Hobbsee.
<dholbach> hi Hobbsee
<pitti> Good morning
<dholbach> hi pitti
<pitti> tjaalton: if you set proper build-deps, they will just dep-wait until it is built on ia64
<nxvl> pitti: hi!
 * pitti hugs dholbach
<pitti> hey nxvl
<tjaalton> pitti: I noticed that it was built on ia64 after all, so went ahead and uploaded what I had
<pitti> ah, finally
<pitti> tjaalton: thanks!
<tjaalton> and bryce did the rest :)
 * bryce waves
<tseliot> cjwatson: I've just sent you the email which I should have sent you yesterday. Thanks in advance :-)
<kantor> hi, ubuntu uses the ide-scsi driver to load ATAP cd devices as SCSI devices ?
<Q-FUNK> what would be the correct package for bug #245500 ?  was reassigned from"jigdo-file" but the real issue is that 8.04.1 jigdo templates point to an older version of a package that is not what ships with hardy+1
<ubottu> Launchpad bug 245500 in xserver-xorg-video-geode "Jigdo cannot build ubuntu-8.04.1-alternate-i386.iso: .jigdo file refers to missing package" [Undecided,Confirmed] https://launchpad.net/bugs/245500
<tjaalton> who's on archive admin duty today? I know it's not mon/wed/fri, but since alpha2 is about to release..
<pitti> tjaalton: Riddell usually
<pitti> I did some small bits today and yesterday, but not a lot
<cjwatson> tjaalton: http://wiki.ubuntu.com/ArchiveAdministration
<cjwatson> Q-FUNK: no package, but it should be on the ubuntu-cdimage project
<cjwatson> Q-FUNK: your diagnosis is incorrect though - I'll handle it
<tjaalton> cjwatson, pitti: thanks, bookmarked
<Q-FUNK> cjwatson: thanks
<cjwatson> Q-FUNK: incorrect> because actually the jigdo files *do* point to the version in hardy.1
<Q-FUNK> cjwatson: so why does their build fail, I'm wondering?
<cjwatson> Q-FUNK: because -updates has moved on from 8.04.1
<cjwatson> Q-FUNK: see my explanatory comment in the bug
<Q-FUNK> ok
<Q-FUNK> does ubuntu ever move packages from release-updates to release, after it's out?
<cjwatson> no
<cjwatson> if we did, that would solve this problem but create others
<Q-FUNK> ok
<amitk> where might I find the edgy release? I need to look at a package in there but can't find it at http://archive.ubuntu.com/ubuntu/dists/
<persia> amitk: There are images available from http://cdimages.ubuntu.com/releases/6.10/release/
<persia> amitk: I don't expect that you'll find archives or updates in any sane place.
<pitti> amitk: old-releases.ubuntu.com has both the archive and CD images
<pitti> persia: ^
<persia> pitti: Thanks!
<amitk> pitti: aah great, thanks
<cjwatson> don't rely on that cdimage URL - it's a bug that it's still there
<pitti> <jedi wave>Edgy is not the release you are looking for</jedi wave>
<jscinoz> any plans on backporting the newest openjdk/icetea? i hear it passes the TCK
<cjwatson> jscinoz: see the discussion on ubuntu-devel
<jscinoz> thanks cjwatson
<ogra> apachelogger, could you add hardy tasks before closing all the kdeedu bugs with pointers to kde4 ? we dont ship it in hardy and there is still opportunity to fix them through SRUs ...
<ogra> (in kde3.x)
<apachelogger> ogra: well, I am done with kdeedu
<ogra> hrm
 * apachelogger hunts through it again
<ogra> thanks :)
<ogra> sorry for that, be we ship kdeedu3 in edubuntu so i dont wat to lose them ...
<apachelogger> ogra: very reasonable, I didn't think about that, sorry :S
<ogra> if we ever meet, remind me to pay you a beer :)
<apachelogger> yay :)
<jscinoz> blarg icedtea is a huge buil
<jscinoz> build*
<cjwatson> tjaalton,bryce: xserver-xorg-video-geode still seems to be built against xserver-xorg-video-2, despite the rebuild
<cjwatson> looks like it's hardcoded in debian/control
<tjaalton> cjwatson: yep, a new version on the way to debian-experimental
<tjaalton> and we can sync that
<cjwatson> please let me know when it's in and I'll do the sync - it's blocking live CD builds
<tjaalton> cjwatson: yep, will do
<cjwatson> I don't see it in incoming
<cjwatson> but it'll be sufficient to have it uploaded, I don't have to wait for the Debian archive to process it
<tjaalton> I could upload a fix if that's faster
<cjwatson> it would be faster, certainly
<cjwatson> same goes for xserver-xorg-video-imstt
<tjaalton> imstt should be removed
<tjaalton> like cyrix
<cjwatson> oh, that failed to build
<tjaalton> they shouldn't block anymore
<tjaalton> magictouch too
<cjwatson> ah, I was reading the wrong xserver-xorg-video-all control file
<tjaalton> bug 246525
<ubottu> Launchpad bug 246525 in xorg "Please remove from the archive" [Wishlist,Confirmed] https://launchpad.net/bugs/246525
<cjwatson> blink, what a confusing bug
<tjaalton> heh
<cjwatson> it should be filed on the individual source packages
<tjaalton> I know, but too many..
<tjaalton> of those
<tjaalton> I'll edit the title
<cjwatson> how about xserver-xorg-video-via?
<tjaalton> synced
<tjaalton> *should be
<tjaalton> bug 246454
<ubottu> Launchpad bug 246454 in xserver-xorg-video-via "Please sync xserver-xorg-video-via 1:0.2.2-6 (main) from Debian unstable (main)." [Wishlist,Confirmed] https://launchpad.net/bugs/246454
<cjwatson> aha
<jcristau> tjaalton: via isn't pciaccessed
<tjaalton> jcristau: oh right..
<tjaalton> so remove from the archive (yay!), openchrome is used by default anyway
<cjwatson> err, I just synced it
<tjaalton> hmm, maybe video-all needs adjusting too
<tjaalton> hmm :)
<cjwatson> shouldn't matter, it's the RHS of an |-dep
<jcristau> tjaalton: i changed -all to openchrome | via a while ago
<tjaalton> jcristau: yeah, that's covered but I thought that | should matter in this case
<cjwatson> it shouldn't
<tjaalton> geode uploaded
<cjwatson> is xserver-xorg-video-openchrome still needed on lpia? it has an outdated package there
<tjaalton> probably not
<tjaalton> right, the current version is only built on i386/amd64
<pitti> tseliot: related to that ^ discussion, the nvidia-glx-* packages need to be rebuilt against the new X, too
<pitti> tseliot: current dist-upgrade wants to remove them
<tjaalton> so the lpia version can be deleted
<cjwatson> mm, looks intentional
<pitti> tseliot: would be nice to test them in the PPA with the new X
<tseliot> ï»¿pitti: tjaalton has suggested a way not to hardcode the server abi
<tjaalton> one caveat with mesa/intel.. compiz doesn't work with it, so it should be blacklisted until the mesa driver is fixed..
<tseliot> pitti: as, for example, the intel driver does
<pitti> tseliot: hardcode in the source, or in the .debs?
<pitti> tseliot: most of the -video packages were mere rebuilds, no source changes
<tseliot> pitti: in the source
<pitti> right
<tjaalton> mvo is on leave?
<pitti> tjaalton: GUADEC
<tjaalton> pitti: ah right
<tseliot> pitti: I have implemented this and all the other changes which you suggested. I'm about to reboot and try them in Intrepid 64bit
<pitti> tseliot: yay you rock!
<pitti> tseliot, tjaalton: WDYT, should we try to squeeze the new nvidia-glx-* into multiverse for alpha-2? it can hardly get much worse anyway :)
 * tseliot reboots
<cjwatson> mythtv still build-deps on libchromexvmc(pro)1 - I'll file a bug
 * tseliot changes his mind on rebooting
<tseliot> ï»¿pitti: does it mean that the packages should be ready today?
<pitti> tseliot: we won't put them on the CDs, at least not for alpha2, so thursday would actually suffice
<pitti> tseliot: I'm not trying to rush you, I'm just asking about what you feel what we should do :)
<pitti> since they would make a nice paragraph in the alpha-2 release notes
<tjaalton> heh
<tjaalton> pitti: I'm ok with it
<tseliot> pitti: if so, then it's ok. I'm working full-time on this ;)
<pitti>  * Unfuck nvidia users, thanks to Alberto Milone
<cjwatson> tjaalton: http://people.ubuntu.com/~ubuntu-archive/NBS/mesa-swx11-source says that vnc4 and xserver-xgl still build-dep on mesa-swx11-source - can you please either file bugs or fix them?
<tjaalton> cjwatson: uh, ok. will do
<cjwatson> ta
<tseliot> pitti: LOL
<pitti> well, maybe with some slight editorial changes :-P
<tseliot> pitti: unless there's something else which you would like to tell me I'll reboot now
<pitti> tseliot: good luck!
<cjwatson> tjaalton: I think that's all the X-related archive actions done now
 * tseliot finally reboots
<tjaalton> cjwatson: yep, should be fine now
<mdz> pitti: I see lrm-envy seems to have been uploaded.  my desktop at the office is hungry for an nv->nvidia migration, if you let me know when it's appropriate to test jockey
<ogra> tsk ... these GL addicts ...
<pitti> mdz: is that hardy or intrepid?
<pitti> mdz: jockey doesn't control l-r-m-envy, that's envy-ng in hardy
<pitti> mdz: tseliot an I will unify envy-ng and jockey at some point, but it's not there yet in hardy :(
<pitti> and in intrepid it's a large construction site ATM; nvidia-glx-* can be tested from PPA (they WFM), but no jockey integration yet
<mdz> pitti: intrepid
<mdz> pitti: would it be more useful to test what's in the PPA now or wait to test jockey integration?
<pitti> mdz: I think testing the drivers now would be very useful -- https://launchpad.net/~lrm-intrepid/+archive
<pitti> mdz: once they are in the archive, I'll have a go at modifying the jockey handlers appropriately
<mdz> tjaalton: xserver-xorg-video-all and some of its dependencies were removed for me on upgrade to intrepid.  are some of them still waiting to rebuild or something?
<mdz> pitti: ok, I'll have a look tomorrow
<mdz> ish
<pitti> mdz: NB that they don't work with the very latest X.org yet, tseliot is currently testing the new version; should be uploaded today (to the PPA)
<pitti> mdz: if you didn't dist-upgrade to all the new drivers and xorg yet, you can use them
<tjaalton> mdz: yes, geode is still without the correct abiver
<mdz> pitti: I'm at home today anyway, so don't have access to the machine atm
<tjaalton> mdz: should be fixed RSN
<pitti> mdz: I think for alpha-2 we should have working drivers in the archive, and shortly after that, a fixed jockey
<mdz> tjaalton: for me it was -geode, -newport, -via, -imstt and -cyrix
<mdz> (none of which I need, so I just let it upgrade anyway)
<cjwatson> mdz: we were just dealing with that lot in scrollback
<cjwatson> half an hour ago or so
<tjaalton> mdz: hmm ok, I haven't tested dist-upgrade yet, but the latest video-all should not depend on cyrix, imstt, newport anymore
<tjaalton> so maybe the archive was a bit behind
<cjwatson> xserver-xorg-video-newport seems to have source but no binaries in the archive in intrepid, which is odd to say the least
<cjwatson> tjaalton: the geode problem confused apt
<tjaalton> ok..
<pitti> current dist-upgrade just wants to kill -cyrix and -via here
<jcristau> cjwatson: newport is Architecture: mips now
<cjwatson> aha
<cjwatson> ok, that makes sense, I'll just leave it there
<cjwatson> removing -cyrix and -via is fine
<cjwatson> I've demoted -via to universe to clarify
<soren> cjwatson: I think I asked you about this before, but I coulnd't find it in my logs: How would you feel about moving openssh's host key generation into the init script instead of postinst?
<soren> cjwatson: If we're building virtual appliances, it would be handy to be able to ship them without keys and just have them generated on first boot.
<cjwatson> I'd accept a patch to make it generate host keys mentioned in the configuration file if they don't exist
<cjwatson> I'd like to leave the existing configuration in the postinst though
<cjwatson> i.e. copy not move
<soren> Oh? Why?
<cjwatson> reason being that it's all bound up with configuration file generation and that belongs in the postinst
<cjwatson> I'm not absolutely sure I can articulate it, I'm just more comfortable with it being in the postinst for most uses
<soren> Hmm.. Ok. That seems a bit pointless to me, though. The postinst starts the daemon anyway, so in the process of postinst'ing, they'll be generated anyway.
<cjwatson> ok, but I have to maintain this so I'd like it to be something I'm comfortable with :)
<soren> *g*
<soren> Sure. Ok, I'll copy the code and send you a patch.
<cjwatson> oh, one good reason - it wouldn't surprise me in the least if a number of people used entirely custom init scripts rather than the one we ship, e.g. for starting multiple sshds
<pitti> soren: not really -- policy-rc.d :)
<cjwatson> so I'd prefer the postinst to do all the configuration by default
<soren> pitti: I deliberately didn't mention that :)
<pitti> I actually use that for chroots
<soren> pitti: I use it in ubuntu-vm-builder, too.
<soren> ...so it would actualy save me the trouble of having to have the postinst generate the key and then remove it afterwards.
<soren> *shrug*
<soren> Just another quirk to the pile.
<emgent> morning
<soren> it's not
<soren> cjwatson: http://people.ubuntu.com/~soren/regen_host_keys.diff
<soren> cjwatson: Or would you rather have it in a bug report?
<soren> cjwatson: I don't know if the postinst changes are silly, though.
<soren> I left them out of the init script to not confuse regular users who wouldn't know what a postinst script is, but still would like to fiddle with the init script.
<cjwatson> soren: bug report, please
<cjwatson> soren: alternative would be to introduce /usr/share/ssh/config-library.sh or something
 * mdz reboots another system into intrepid
<soren> cjwatson: Yeah, I thought about that. Hm.. Ok, I'll give it a shot.
<cjwatson> any objections to xcb-util being promoted to main? new cairo needs libxcb-render-util, and it seems fairly unobjectionable
<mdz> that did not go well at all
<mdz> gdmgreeter is crashing, xfailsafedialog is crashing
<mdz> nautilus and gnome-panel are crashing
<mdz> but somehow gnome-terminal and xchat-gnome work
<tjaalton> yay, x-x-video-all is now installable
<tjaalton> ..again
<mdz> tjaalton: do you think my mess is related to the X updates?
<tjaalton> mdz: I doubt it, I've been using these for a week now
<Mirv> mdz: compiz at least doesn't work with intel with the newest mesa
<mdz> tjaalton: (gnome-terminal:8546): Gdk-CRITICAL **: get_monitor: assertion `monitor_num < screen_x11->n_monitors' failed
<mdz> looks incriminating
<tjaalton> mdz: well, gdm doesn't work here so I can't get that far now, after a reboot :)
<mdz> Mirv: running metacity here (which only barely runs)
<tjaalton> yes, compiz should blacklist intel for now
<mdz> my gdm is broken, but I think for the same reasons as everything else
<Mirv> tjaalton: I don't see cyrix, imstt, via hitting the archive yet? synaptic would like to remove -all:s and xorg because of those
<tjaalton> Mirv: update..
<mdz> gnome-terminal segfaults after the above error; gnome-panel segfaults in panel_multiscreen_width
<mdz> both behave as if they aren't getting what they expect from the X client libraries
<mdz> gnome-terminal somehow manages to render its initial window, but clicking any menu segfaults it
<mdz> likewise for metacity
<mdz> this is running with vesa; -intel doesn't even get this far
<Mirv> tjaalton: yep, archive.ubuntu.com
<cjwatson> Mirv: cyrix and imstt have been removed; via is broken but doesn't block xserver-xorg-video-all so you can let it be removed
<cjwatson> Mirv: as of a few minutes ago -all is now fine for me
<Mirv> cjwatson: right.
<Mirv> looks like the rest is just a synaptic problem when not using smart method but marking the packages manually
<mdz> tjaalton: with -intel, my X server crashes in libfb.so
<mdz> but there is so much wrong at this point that I'm not sure where the fault is
<tjaalton> mdz: yes, seems that intel fails here as well
<tjaalton> I'll try the previous kernel
<mdz> tjaalton: tried that, didn't help
<mdz> I am getting some mtrr errors, don't know if they're related
<mdz> [   60.432466] mtrr: no MTRR for e0000000,770000 found
<mdz> [   63.459226] mtrr: base(0xe0000000) is not aligned on a size(0x770000) boundary
<mdz> this is back on 2.6.24-19
<mdz> saw the same on 2.6.26
<mdz> tjaalton: what would I need to downgrade in order to try the old -intel?
<tjaalton> mdz: quite a lot.. I'll try to rebuild something
<nxvl> good morning everyone!
<mdz> tjaalton: doesn't build with the intrepid libdrm-dev
<tseliot> pitti: shall I make the nvidia driver conflict and replace nvidia-kernel-common now or shall I wait?
<tjaalton> mdz: the old intel? no, it needs a fix in configure.ac
<mdz> tjaalton: fixed that, it wants xf86mm.h
<mdz> which was in the old libdrm-dev but not the new
<pitti> tseliot: if you want to use n-k-c for the bits we discussed (config, debconf, modalias lists), and having the current package installed doesn't hurt, just leave it for now
<mdz> it builds after downgrading libdrm
<mdz> tjaalton: fails in the same way as before though
<mdz> segfault in libfb.so
<tseliot> pitti: ok. BTW if your Intrepid X crashes, is because of the /etc/init.d/nvidia-glx-<VER>. I'll make sure that it's removed in the postinst, just in case
<tjaalton> mdz: looks like EXA is broken
<tjaalton> Option "AccelMethod" "XAA" seems to work
<tjaalton> VT's are broken though
<mdz> tjaalton: confirmed here
<tjaalton> I'm not sure anymore, but the xserver I had running before was a vanilla debian one
<mdz> let me see if that affects my segfault issues
<tjaalton> so a patch of ours broke it
<mdz> tjaalton: confirmed, I can login to GNOME with XAA
<mdz> tjaalton: so my segfault issues seem somehow related to vesa
<mdz> I'll try to confirm that
<Mirv> tjaalton: I wonder if it's the greedy patch, which is usually not endorsed/supported by upstream
<tjaalton> Mirv: could be..
<tjaalton> a rebuild it is
<tseliot> pitti: another thing: which section should I set in the control files? multiverse/misc?
<mdz> tjaalton: I've confirmed GTK clients segfaulting if I run with the vesa driver, which presumably doesn't use exa, so that seems to be a separate problem
<tjaalton> mdz: yeah it's separate.. vesa was updated too (1.3.0 -> 2.0)
<mdz> tjaalton: on which package should I file the bug about exa?  -intel or -core?
<tjaalton> mdz: core, but I'll rebuild the server to see if commenting out a single patch makes it work again
<tjaalton> 15:53 < tjaalton> so a patch of ours broke it
<tjaalton> (most likely)
<Mirv> vesa 2.0.0 + xserver 1.5 works under virtualbox for me. but I haven't yet tried all these on real hw.
<mdz> tjaalton: filed as bug 246581
<ubottu> Launchpad bug 246581 in xorg-server "X server crash in libfb.so when EXA is enabled" [Undecided,New] https://launchpad.net/bugs/246581
<soren> cjwatson: I'm about to look into creating the infamous server seed, but I'm not sure where it belongs, really. Off the top of my head, I'm guessing just separate file in ubuntu.intrepid?
<tjaalton> hm, it's not the greedy patch
<cjwatson> soren: for now, it would be best as a separate file in ubuntu.intrepid, yes
<cjwatson> soren: though I'd like it and the other *-server seeds to move out to a separate server.intrepid seed collection at some point
<soren> cjwatson: Right. The fact that each of {ubuntu,kubuntu,xubuntu,mobile}.intrepid have a server-ship is a bit confusing to me.
<persia> "seed collection"?  Is the term "seed pot" now deprecated?  (I'm hoping to hear "yes").
<Lrrr> now that's a cool name...
<cjwatson> I think the suggestion was "seed pod", actually
<soren> That makes more sense :)
<persia> Ah.  I misheard then.  "seed pod" makes more sense.
<cjwatson> I don't think I've bothered to settle on anything "officially", although I did use the term "collection" in germinate(1) recently
<persia> I'm willing to consider the documentation in germinate to be the official source of nomenclature for seed management.
<cjwatson> soren: server-ship> I definitely regard that as a bug
<cjwatson> but it's easier to fix when we can point to somewhere and say "look, this is the final home"
<soren> cjwatson: Indeed.
<mdz> Mirv,tjaalton: vesa issue is bug 246585
<ubottu> Launchpad bug 246585 in xserver-xorg-video-vesa "GTK applications crashing reproducibly when using vesa" [Undecided,New] https://launchpad.net/bugs/246585
<soren> mount
<soren> nice
<tjaalton> mdz: the intel bug was not on the server after all. it's the "force greedy exa" patch on intel
<mdz> tjaalton: I've updated the bug accordingly
<tjaalton> mdz: oh, thanks
<emgent> hello there
<pitti> tseliot: how did the testin go?
<tseliot> pitti: I'm still testing. They seem to work well. I'll bump the release for my PPA but we'll have to remove it for Intrepid, so that it's ubuntu1
<pitti> tseliot: let me know when you uploaded, I'll test it here as well
<tseliot> pitti: sure
 * tseliot logs out to try the new drivers
<tjaalton> the first uploaded version can be 0ubuntu2..
<tjaalton> no need to change IMHO
<tseliot> tjaalton: ok, let me fix the changelog then
<tjaalton> tseliot: oh you already did it, nevermind then
<tseliot> tjaalton: I haven't uploaded anything yet
<geser> pitti: have you an idea why many build logs have a line "sh: gcc: not found" in them?
<pitti> ugh, no; infinity, do you? ^
<ogra> gcc is overrated ... write more scripts !
<cjwatson> it's harmless, whatever it is
<pitti> tjaalton: hm, on my laptop I only have -intel installed, and purged all the other drivers; dist-upgrade now wants to install all of them again, and I don't seem to be able to keep just -intel; any idea what's wrong there?
<pitti> tjaalton: i. e. is -all strictly depended on now?
<ogra> by xorg, no ?
<geser> pitti: no, just "force" the upgrade of -intel
<tjaalton> pitti: xserver-xorg depends on video-all
<ogra> ah, its xserver-xorg ...
<pitti> well, I can force it, of course, but ideally it would just work?
<cjwatson> xserver-xorg Depends: xserver-xorg-video-all | xserver-xorg-video-2, xserver-xorg-input-all | xserver-xorg-input-2
<tjaalton> uh no, it should be enough to have just one driver which provides video-2.9
<cjwatson> those need to get bumped for the new ABI version
<tjaalton> crap
<pitti> ah, it's -2.9 now
<tjaalton> hmm no, they are fine here
<tjaalton> heh
<pitti> tjaalton: so the metapackage's depends: just need fixing, ok
<pitti> tjaalton: want a bug for that, or shall I do it myself, or do you want to?
<tjaalton> pitti: it's fixed already by the latest version?
<geser> pitti: xserver-xorg 1:7.4~0ubuntu1 has the correct one already
<cjwatson> geser: the Dpkg::Arch perl module (invoked by dpkg-source) uses gcc, which is where that comes from - no idea why it isn't present though
<cjwatson> Package: gcc
<cjwatson> Build-Essential: yes
<pitti> geser: hm, indeed; apt-get doesn't seem to grok that
<cjwatson> err, so it does, I missed that
<geser> and the build logs also show that gcc got upgrade so it should be really there
<cjwatson> pitti: version of -intel?
<cjwatson> geser: in e.g. http://launchpadlibrarian.net/15890222/buildlog_ubuntu-intrepid-i386.cairo_1.6.4-6ubuntu1_FULLYBUILT.txt.gz, gcc-4.3 gets upgraded but gcc doesn't. Note that /usr/bin/gcc is in gcc not gcc-4.3
<pitti> cjwatson: 2:2.3.2-2ubuntu1 (available)
<pitti> cjwatson: the depends: and provides: really do seem ok, but apt-get doesn't seem to notice that if you upgrade both, the virtual pacakge dependency is still fulfilled, or so
<geser> cjwatson: http://launchpadlibrarian.net/15667866/buildlog_ubuntu-intrepid-i386.libgnupg-interface-perl_0.36-1_FAILEDTOBUILD.txt.gz has that line too but there is also "Setting up gcc (4:4.3.1-1ubuntu2) ..."
<cjwatson> geser: how confusing. buggered $PATH?
<geser> while talking about this build log, does somebody have an idea why gnupg was not found (leading to a FTBFS) while there is output from gpg for the signature check?
<cjwatson> (can't see why that would be though)
<cjwatson> geser: it might be that dpkg-source is run outside the chroot
<cjwatson> or it might be that the configure script is on hopeless crack
<geser> cjwatson: that package builds inside a pbuilder without problems
<geser> cjwatson: do you know how many chroots are involved during a package build? I assumed it happens all in one chroot
<calc> a chroot isn't guaranteed to be the same as a current install of the same dist
<calc> you have to make sure your build-depends and build-conflicts are tight enough
<thebishop> are official ubuntu releases built from source using APT?
<calc> i ran into that problem myself with OOo java build on ppc a few months back
<calc> i ended up just disabling java since i didn't know what was wrong with the buildd version of the build
<Lrrr> thebishop: You can't really build anything with apt...
<thebishop> Lrrr, so is it traditional build scripts then?
<calc> thebishop: probably built with sbuild
<Lrrr> thebishop: No really it's a bit more complex than that, but it's pretty much built from source every release yeah
<thebishop> the reason i ask is i'm interested in working on a PS3 port of Ubuntu Mobile
<thebishop> i'm trying to get an idea of how big an undertaking it will be
<calc> thebishop: you need dpkg-dev to build stuff generally
<Lrrr> thebishop: did you ever build a package, like manually?
<thebishop> Lrrr, yeah, i've built kernels on ubuntu.  I used to ./configure/make/makeinstall everything when I ran slackware
<Lrrr> thebishop: You should initiate yourself to the intricates of Debian/Ubuntu packaging.
<calc> http://www.debian.org/doc/manuals/maint-guide/
<Lrrr> thebishop: but that'll give you just part of the answer.  There is a part of the work that will probably means porting some software to the PS3.  I don't really know how hard that part could be.
<pitti> BenC: hm, installing v86d changed my boot from "usplash horribly distorted" to "not booting at all any more"
<BenC> pitti: hmm...what version of v86d?
<pitti> ugh, after dist-upgrade, X doesn't start at all any more (intel GMA945)
<tjaalton> pitti: yes..
<pitti> BenC: 0.1.5-1ubuntu1
<tjaalton> pitti: maybe I should just upload a fix..
<tjaalton> and not wait for bryce :)
<pitti> tjaalton: seems it tries to use the vesa module
<tjaalton> pitti: that's because intel makes the server segfault, so bulletproof-x kicks in
<pitti> ah, that would be it
<pitti> -vesa doesn't work either, though
<tjaalton> right, that's another bug
<tjaalton> mdz filed those
<pitti> tjaalton: right, I have a backtrace here, do you need it?
<tjaalton> pitti: those are already on the respective bugs
<pitti> ok, thanks
<pitti> tjaalton: if it's known, all is well
<BenC> pitti: is uvesafb causing a problem with X?
<pitti> BenC: I don't think they are related
<BenC> ok
<pitti> well, at least X breaks equally well when booting without splash
<mdz> pitti: bug 246585
<ubottu> Launchpad bug 246585 in xserver-xorg-video-vesa "GTK applications crashing reproducibly when using vesa" [Undecided,New] https://launchpad.net/bugs/246585
<BenC> pitti: what video mode are you passing to the kernel?
<mdz> pitti: and bug 246581
<ubottu> Launchpad bug 246581 in xserver-xorg-video-intel "X server crash in libfb.so when EXA is enabled" [High,Triaged] https://launchpad.net/bugs/246581
<mdz> pitti: you're correct that uvesafb is not related, though I noticed that problem as well
<mdz> it seems to depend on v86d, which isn't installed
<pitti> BenC: dmesg has "uvesafb: Getting VBE info block failed" and "vbe_init() failed with -22", and "probe of usesafb.0 failed with error -22"
<mdz> installing it didn't particularly help things, though
<pitti> mdz: right, I just tried that, and it seems to make it worse
<pitti> mdz: scrambled usplash -> black screen
<pitti> BenC: those messages are with v86d installed; without it, I got some "/sbin/v86d not present blabla"
<mdz> pitti: I think it did the same for me, but I ended up going back to 2.6.24 anyway
<mdz> pitti: I got a black screen where not even magic sysrq worked
<pitti> mdz: ctrl+alt+del worked for me
<pitti> BenC: video mode> how can I tell?
<BenC> pitti: was scrambled usplash a new problem, or is that expected?
<BenC> pitti: cat /proc/cmdline
<mdz> I wasn't sure whether it was a side effect of the X issues or framebuffer-related
<mdz> BenC: scrambled usplash was new for me
<pitti> BenC: scrambled> happens with the intrepid kernel, works with hardy kernel
<BenC> mdz: when did that start occuring?
<mdz> I have notes from upgrading my laptop which I haven't posted yet
<mdz> BenC: intrepid
<pitti> intrepid + hardy kernel> works, intrepid + -26.3> scrambled
<pitti> BenC: you can still see text, but the progress bar jumps around, and text appears at wrong positions, etc.
<pitti> i. e. it's not a total noise, but pretty distorted
<pitti> BenC: no particular video mode
<BenC> pitti, mdz: Do you know what framebuffer is loaded when that happens (vg16fb?)
<BenC> *vga16fb
<tseliot> pitti,tjaalton,superm1: I have just uploaded the drivers to my PPA. Just FYI. I'll have to adapt nvidia-settings so that it doesn't install the old drivers.
<BenC> pitti: and btw, I've also noticed the "Getting VBE info block failed"...seems to be racey
<pitti> tseliot: yay!
<BenC> pitti: weird, uvesafb shouldn't get loaded unless you have a specific video mode set
<mario_limonciell> tseliot, great, i'll take a look sometime today
<mario_limonciell> tseliot, does this include the dynamically detecting the ABI version of the provides?
<pitti> BenC: I think it happens if you boot with usplash, that sets the native video mode (1280x800)
<pitti> BenC: now I booted without splash, and have the standard 80x25 text console
<pitti> (well, it *might* be a 640x400 framebuffer, hard to tell)
<mdz> BenC: uvesafb I believe
<BenC> pitti: cat /proc/fb
<pitti> BenC: anyway, when booting without splash, I have "uvesafb" kmod loaded
<BenC> pitti: if that doesn't exist, then no fb is loaded
<pitti> BenC: exists, empty
<mdz> BenC: I'm going to reboot later to test 2.6.26 again now that my X problems are fixed.  what do you want me to try?
<cjwatson> usplash should just be using svga rather than *vesafb
<tjaalton> fixed intel uploaded
<pitti> tjaalton: yay
<pitti> tjaalton: "Since compiz is not usable on intel anyway..." ugh, since when?
<BenC> mdz: do you also have v86d installed?
<mdz> BenC: yes, I installed it when I saw that error
<mdz> nothing depends on it
<BenC> mdz, pitti: Ok, then I just need to find out why uvesafb is getting loaded for no reason
<cjwatson> right, it only got promoted to main very very recently
<pitti> BenC: I can try and blacklist it, shall I?
<pitti> and then boot with usplash again
<BenC> pitti: yeah, don't forget to rerun update-initramfs -u
<tjaalton> pitti: since mesa 7.1
<pitti> BenC: if it isn't loaded, v86d shouldn't make a difference, should it?
<BenC> pitti: right
<tjaalton> pitti: there are two bugs that have been for some time
<cjwatson> is anyone else seeing occasional little bits of screen corruption in usplash in intrepid?
<tjaalton> cjwatson: yep
<cjwatson> it's mostly fine, but every so often, usplash decides to draw something a little bit above or below where it should be
<cjwatson> roughly two text lines' worth
<tjaalton> pitti: so, someone should kick the intel guys to fix those
<pitti> cjwatson: I also saw the progress bar jump, yes
<pitti> BenC: so, with uvesafb blacklisted, I get a reasonably clean usplash up to some 15%, then it completely freezes
 * pitti boots again with usplash and verbose
<pitti> BenC: blacklisted and no splash works fine
<mdz> tjaalton: what was that 'greedy' patch fixing?
<mdz> pitti: I was the progress bar jump as well
<mdz> along with some random 1-pixel lines of garbage in a couple of places
<Chipzz> soren, cjwatson: wrt openssh key generation: how will that work in upstart?
<tjaalton> mdz: the driver uses EXA acceration thingy by default, but it's slow in some operations, so greedy tries to bypass some of that
<pitti> BenC: hm, now it booted fine with usplash and the module blacklisted; still screen corruption, but a bit better
<Chipzz> does upstart support such complex scenario's?
<pitti> all very mysterious, though
<tjaalton> mdz: but apparently with xserver 1.5 EXA is better, so the patch might be obsolete anyway
<pitti> BenC: well, plenty of stuff to try next week :)
<cjwatson> Chipzz: upstart supports bits of shell that you run before the daemon starts. I don't see how it would be a problem in the slightest
<tseliot> mario_limonciell: would you mind if I removed the Recommends and the Conflicts from nvidia-settings?
<pitti> tjaalton: yay, new -intel works, thanks!
<mario_limonciell> tseliot, what are they currently right now?
<pitti> http://launchpadlibrarian.net/15891896/xserver-xorg-video-intel_2.3.2-2ubuntu2_i386.deb if someone wants to test it before it gets published
<tseliot> mario_limonciell: Recommends: nvidia-glx (>= 1:96.43.05+2.6.24.9-8.22) |  nvidia-glx-new (>= 169.09+2.6.24.9-8.22) | nvidia-glx-legacy (>= 71.86.04+2.6.24.9-8.22)
<tseliot> same for Conflicts
<mario_limonciell> tseliot, yeah i say remove them
<Chipzz> cjwatson: ah ok I mistakenly thought it was less advanced
<tseliot> mario_limonciell: ok.
<mario_limonciell> tseliot, you might consider making nvidia-settings recommends for all the different driver packages though
<tseliot> ï»¿mario_limonciell: I would like something like Jockey or EnvyNG to deal with hardware detection
<tseliot> mario_limonciell: and install the right driver
<tjaalton> pitti: as designed ;)
<mario_limonciell> tseliot, yeah it will
<mario_limonciell> but i'm saying nvidia-settings should be a recommends for each of those driver's packages
<mario_limonciell> so that when you install the driver, you get nvidia-settings too
<BenC> pitti, mdz: If the screen corruption occurs without v86d installed (or uvesafb loaded), then we may have a vga16fb problem...I'll check into it (I noticed it too, but thought it was local to me)
<tseliot> mario_limonciell: ah, ok. I agree then
<mario_limonciell> tseliot, i recently committed something to fglrx so similar happens with the amdcccle
<pitti> BenC: yes, I purged v86d and blacklisted uvesafb; the machine boots now (no black screen and hang), just with some corruptions
<pitti> BenC: it's of course entirely possible that it is a bug in usplash, but it looks ok on the hardy kernel; might be a coincidence, of course
<tseliot> ï»¿mario_limonciell: great, let's be consistent then ;)
<cjwatson> BenC: the screen corruption happens to me both with and without v86d installed
<pitti> so the only remaining problem now is broken suspend
<cjwatson> BenC: however, I just read through the hardy->intrepid diff to usplash, and there seem to be no relevant changes
<BenC> cjwatson: ok, thanks
<slangasek> _MMA_: if vorbis-tools cares about file extensions, then it probably makes sense to open a task for it on bug #201291, yes
<ubottu> Launchpad bug 201291 in mime-support "Add ogv (video) and oga (audio) as recognized extension for Ogg Theora and Ogg Vorbis, respectively" [High,Fix released] https://launchpad.net/bugs/201291
<slangasek> superm1: mythbuntu alt disks published as 8.04.1 now, cheers
<_MMA_> slangasek: Sorry. I dug into this further with the guys @ #vorbis and even though they made these new extensions they have no plans to push them and still recommend using .ogg because of breakage downstream.
<_MMA_> slangasek: This is with vorbis-tools/oggenc that is.
<ogra> hmm, why cant i find any code for using hardy-updates in livecd-rootfs ?
 * ogra would have expected it to use updates ...
<cjwatson> ogra: it does, it's there
<cjwatson> search for 'updates' in livecd.sh, second hit
<ogra> hmm, grep updates gains me nothing in the hardy package
<cjwatson> ogra: oh, it's only in intrepid
<cjwatson> just pull from bzr
<ogra> right ...
<ogra> (we should sru the package with the patch though)
<ogra> so people building their own CDs dont end up with the wrong ssh client :)
<cjwatson> ogra: that would make sense
<slangasek> _MMA_: er, that directly contradicts the information in the xiph.org wiki page pointed to in that bug...
<_MMA_> slangasek: Ill PM you.
<slangasek> i.e., they may not currently be recommending that the default extensions be changed when generating, but there's MIME standardization being pushed here, which means that applications that /read/ oggs need to know the new extensions, for sure
<_MMA_> Yes.
<_MMA_> Awareness of the MIMEs but thats it.
<_MMA_> Which seems silly to me but oh well.
<slangasek> well, presumably we could make a change down the line to the choice of extensions at creation time, once it's been widely adopted
<slangasek> soren: is bug #187048 something that can be fixed in intrepid for alpha 2?  (the milestone pitti originally set for it)
<ubottu> Launchpad bug 187048 in virt-manager "virDomainCreateLinux() failed Timed out while reading console startup output" [Medium,Fix committed] https://launchpad.net/bugs/187048
<pitti> slangasek: those were all hardy SRUs, so I'd think so
<pitti> those just mean "get it uploaded to intrepid NOW", since technically it was already violating SRU rules
<slangasek> pitti: right, and this is my pre-alpha2 nag for milestoned bugs :)
 * cjwatson gets going on a version of debian-policy for Ubuntu
<liw> cjwatson, yay
<bryce> tjaalton, mdz, I've pushed up an -intel with that greedy patch disabled
<bryce> sorry, we should have caught that earlier yesterday, we knew -intel's behavior with greedy was going to change with the new xserver
<geser> did somebody also seen in intrepid that a key is repeated like you would hold it down? it happens here sometimes when the system is under load
<ogra> sounds kernelish
<geser> might by true as I started seeing this after upgrading to intrepid kernel
<slangasek> geser: I've heard of that bug, yes, but I'm afraid I can't be any more specific than that
<kirkland> slangasek: hey, i'm off the phone with dendrobates now
<kirkland> slangasek: dendrobates feels strongly that AuthClientConfig is the proper place to solve this problem for our purposes, pam_ecryptfs.so munging into the pam stack
<kirkland> slangasek: I'm curious about your proposed solution
<kirkland> slangasek: do you have anything in writing yet about how you'd like to tackle it?
<cjwatson> geser: bug 218516? however, the patch that fixed that seems to be in the intrepid kernel
<ubottu> Launchpad bug 218516 in linux "[hardy] key events are delayed under circumstances" [Low,Fix committed] https://launchpad.net/bugs/218516
<cjwatson> geser: (probably best not to reuse that bug)
<dendrobates> kirkland slangasek: to be clear, I just want the logic in that package, not to solve the problem with templates
<slangasek> kirkland: yes; let me push it into a wiki page
<slangasek> dendrobates: eh, once the PAM stuff is done, the auth-client-config package should be obsolete
<slangasek> because it needs to be done in the pam package itself
<kirkland> slangasek: is that for Debian Policy reasons?
<slangasek> kirkland: it's because it should be part of the core of how the pam packages work, there's no reason for it to be a separately-maintained package at that point
<mdz> bryce: I thought tjaalton already had
<geser> cjwatson: thanks, that's seems to be the problem I also see
<slangasek> kirkland: auth-client-config might still be useful on an upgrade basis for those who already have it installed, but that's all it should be doing in the New World Order
<bryce> mdz, yup he did
<cjwatson> geser: perhaps best to file a new bug and refer to it rather than piggy-backing on it; it's potentially quite a general problem so may be unrelated
<slangasek> kirkland, dendrobates: oh, correction; I guess auth-client-config would still be relevant for the NSS bits, which are so far down the line I shy away from thinking about it :/
<dendrobates> slangasek: the long term plan is to allow pam/nss configuration from a template stored in ldap.
<kirkland> slangasek: how much time/effort is there in implementing your suggested pam-config scheme?
<slangasek> dendrobates: um, well, the Debian packages are going to implement this using debconf; if you can use the debconf ldap backend, then great, but otherwise ldap isn't going to be a good fit for what actually needs to be done in any case
<slangasek> kirkland: depends on how fast you code, perhaps? :)
<kirkland> slangasek: i'm trying to put the ecryptfs-related development behind me so that I can focus on a couple of other things dendrobates has me assigned to for intrepid (booting degraded raid, iscsi on installation)
<slangasek> dendrobates: wanting to pre-configure everything via LDAP is only one of a variety of use cases that should be supported.  Single-user desktops also have need for a configuration framework for PAM, and that implies debconf.
<kirkland> slangasek: the two biggies i have left for ecryptfs-private-dirs are (1) the main inclusions for 4 packages, and (2) the pam config
<slangasek> kirkland: right, give me two shakes to finish dumping my notes to the wiki
<kirkland> slangasek: sure, no problem
<tseliot> pitti,mario_limonciell: I have uploaded the new nvidia-settings and the nvidia drivers so that they recommend nvidia-settings
<slangasek> kirkland: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
<kirkland> slangasek: reading....
<slangasek> kirkland: as a spec, it's currently terrible, but I think most of the core design is there
<slangasek> saivann: heh, 220631 bumped to alpha-3 without even trying to get it fixed? :)
<saivann> slangasek : Was it a bad move? You said that we would not have enough time for alpha 1 (that was before I realised that this bug might not exist anymore in intrepid :) )
<saivann> s/alpha 1/alpha 2/
<slangasek> saivann: oh, I didn't say that we wouldn't have time, I only said that /if/ there's not time it should be re-targeted
<slangasek> but it's fix-released now, so ok :)
<saivann> slangasek : Oh, my fault, I didn't read the "*if* that's not feasible", sorry
<alex_dinamo> guys... hello to all
<alex_dinamo> I've got a problem
<alex_dinamo> I am in a urge to get subversion 1.5 running
<alex_dinamo> when tryng to compile, it can't find libneon.la
<thom> alex_dinamo: way, way offtopic for this channel, sorry
<alex_dinamo> seems like neon is not compiled with libtool support, something like that
<ion_> We have a problem, too. To prevent it, weâve set the topic.
<alex_dinamo> bump
<alex_dinamo> yes
<alex_dinamo> sorry
<alex_dinamo> where can I ask?
<saivann> Is there a developer who knows usplash a bit that can help me fixing bug 55159 and bug 139363
<ubottu> Launchpad bug 55159 in usplash "[edgy] usplash prevents passwords from being not echoed on the console" [Undecided,Confirmed] https://launchpad.net/bugs/55159
<ubottu> Launchpad bug 139363 in cryptsetup ""Enter passphrase" for LUKS/cryptsetup breaks usplash" [Low,Triaged] https://launchpad.net/bugs/139363
<thom> alex_dinamo: please see the topic
<ion_> alex_dinamo: #ubuntu or https://answers.launchpad.net/ubuntu/+addquestion
<_MMA_> saivann: I can get you in touch with someone who knows the ins and outs of its themeing (they might know something) but I have no clue who actually *works* on usplash anymore.
<saivann> _MMA_ : Thanks, if possible, if you can show him/her the bug reports, it would greatly helps me
<slangasek> kirkland: page updated, I dug up my draft of the config file format & preliminary stack examples
<kirkland> slangasek: cool, i was going to ask for examples of your syntax
<slangasek> the draft config file format still needs refined, as you'll see from the notes; there are a couple of points where I think I've got a bit of redundancy
<slangasek> hmm, apparently I need to do some wiki formatting though
<slangasek> fixed
<kirkland> slangasek: you thinking python?  perl?  shell?  C? for the implementation?
<ogra> R
<ogra> to add something new :)
<slangasek> kirkland: I would like python, but that poses implementation problems for Debian since libpam-runtime is transitively essential and python is not part of base
<slangasek> kirkland: so realistically, one of perl or C
<kirkland> slangasek: Well fwiw, I'm about 2x faster programmer in perl than python.  Considering the string parsing involved, I think perl would be kinder than C.
<slangasek> kirkland: that's ok with me. :)
<kirkland> slangasek: I'd like, though, to get some input from dendrobates and jdstrand before starting down this route
 * slangasek nods
<kirkland> slangasek: dendrobates is pretty strongly behind enhancing auth-client-config to have it do what we want, rather than writing something from scratch
<jdstrand> kirkland: what input do you need/want?
<MtJB> will ubuntu issue a patch for the DNS design flaw today?
<laga> what DNS design flaw?
<mouz> laga: http://lists.debian.org/debian-security-announce/2008/msg00184.html
<MtJB> multi vendor patches coming today from bind, ms, sun, cisco, and other
<jdstrand> MtJB: it's being worked on
<pitti> BenC: hm, any idea why /dev/rtc doesn't exist any more? (vmware complains); I have a /dev/rtc0 now, but it has a radically different major/minor
<BenC> pitti: we aren't using the legacy rtc subsystem anymore
<BenC> pitti: with 2.6.26, you can't enable the legacy and standard rtc interfaces at the same time anymore
<pitti> BenC: ah, thanks; so itz vmware bug
<thebishop> is there a monolithic source tree for the various flavors of Ubuntu?  For instance, is there one place where I can check out all the source for the packages in xubuntu or ubuntu mobile?
<LaserJock> thebishop: no
<Lrrr> sadly no
<Lrrr> thebishop: apt has the source packages
<Lrrr> thebishop: check the apt-get source command
<thebishop> is that how Ubuntu is able to produce usable builds daily?
<LaserJock> thebishop: we don't rebuild from source package daily
<Lrrr> thebishop: No that's quite a bit more complex than that.  Still, the sources are  there.
<LaserJock> thebishop: there are scripts/programs that build the CD from the existing binary packages
<LaserJock> thebishop: generally what you want to read up on is germinate (and seeds ) and debiancd
<thebishop> LaserJock, I see.  So only a few packages are built daily
<LaserJock> thebishop: whenever a new version is uploaded it is built
<thebishop> the reason i ask (Lrrr knows) is that I'd like to port Ubuntu Mobile to the Playstation3
<LaserJock> and it's not rebuilt (generally) until a new version is uploaded
<LaserJock> thebishop: yeah, saw that from a few hours ago :-)
<LaserJock> thebishop: so basically you want to get a list of the packages involved, and build the source packages on PS3
<thebishop> LaserJock, I assume Ubuntu also has a ton of its own scripts and config files to make everything more cohesive
<ScottK> Note that for Hardy, Ubuntu Mobile is not 100% built from the official Ubuntu mirrors.  They have an additional one of their own.  I don't know where it is.
<thebishop> not to mention art assets
<slangasek> they have a ppa, but I wouldn't be able to tell you the name of it offhand
<thebishop> ScottK, what about Intrepid?  May as well start working on the latest version
<ScottK> It is my understanding that they intend to work out of the official repos.  I don't know if they have transitioned yet.
<LaserJock> thebishop: everything is in source packages, you just got to find them :-)
<thebishop> heh
<LaserJock> thebishop: have you looked at the Ubuntu PS3 isos?
<LaserJock> seems like it wouldn't be too far to go from there to Ubuntu Mobile PS3 port
<thebishop> I don't know, isn't Ubuntu Mobile designed to be fast and light?
<LaserJock> thebishop: well, it uses a different package selection, but the basics would be similar I'd think
<LaserJock> thebishop: the Intrepid mobile seed is at https://code.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/mobile.intrepid I believe
<LaserJock> thebishop: that should help you get a list of packages
<Mirv> tjaalton/bryce: definitely some progress now with intel performance with xserver 1.5 EXA (without greedy). not completely great yet, but hopefully the greedy patch can now be left disabled.
<bryce> Mirv: yeah
<Mirv> the compiz broken on intel 965 with mesa 7.1 is https://bugs.freedesktop.org/show_bug.cgi?id=14441 - there's a one-line fix but I guess intel should do it in a proper way
<ubottu> Freedesktop bug 14441 in Drivers/DRI/i965 "Compiz shows only black screen on i965" [Normal,Assigned]
<Keybuk> black screen?
<Keybuk> I get a white screen!
<Mirv> Keybuk: white screen is usually that LIBGL_ALWAYS_INDIRECT is not set, see the last two comments
<Mirv> after setting it you get a black screen :)
<tjaalton> I get a corrupt screen
<tjaalton> but the same bug most likely
<YokoZar> What is Ubuntu "Complete Edition" ? http://www.bestbuy.com/site/olspage.jsp?a=8888563&type=product&tab=1&id=1211587312374#productdetail
<Mirv> tjaalton: oh yes, as mentioned in the bug report, it at least used to be corrupt screen without TTM (like intrepid now), or black screen with TTM. I guess it hasn't changed.
<tjaalton> Mirv: yep, the desktop and windows mostly black, decorations corrupt
<Mirv> if it really looks like intel is not doing anything about it soon, one may consider having the one line patched in the intel driver
<tjaalton> yep..
<Mirv> YokoZar: hopefully something being agreed between this "valusoft" and canonical, since it's on sale on best buy...
<YokoZar> Mirv: branding Ubuntu trademarks, no less
<Mirv> looks like they also have "office suite 2007", but at least they dont use openoffice.org name
<bryce> Mirv: I've emailed Intel support about those two issues this morning to try to raise visibility on these regressions
<bryce> Mirv: hopefully we'll see some progress made on them soon
<Mirv> bryce: oh great, hopefully so
<bryce> I worry the answer's going to be something like, "You need GEM to make it work"
<bryce> ;-)
<Mirv> yep, gallium + gem + dri2 + xserver 1.6 ;)
<Mirv> but Eric indicated in the bug report that the code in mesa should be simply disabled or fixed, so I'd guess the compiz fix is very much doable for mesa 7.1
<bryce> hope so
<Mirv> Michel, that is, not Eric
<kirkland> doko: hi, are you around?
<kirkland> doko: i have a bug/patch for lsb.  you sponsored my last one, though you might review/sponsor this one too.
<ogra> Keybuk, would you have time for a question ?
<cjwatson> YokoZar: could you please mail trademarks@ubuntu.com about that?
<cjwatson> it's not clear to me that it falls within the trademark policy
<YokoZar> cjwatson: done
<Mirv> cjwatson: usage of Ubuntu logo, name etc. in any commercial way. "Restricted use that requires a trademark license" ... "Any commercial use" (http://www.ubuntu.com/aboutus/trademarkpolicy)
<YokoZar> cjwatson: "Complete Edition" to me sounds like a box that would have multiple dvds with every package (universe included), sorta like Debian's 14-discs series
<_MMA_> Take a peak. Looks like 1 disk.
<_MMA_> http://princessleia.com/journal/?p=1262
<Mirv> YokoZar: thanks
<geser> there is also a Ubuntu Satanic Edition? http://ubuntusatanic.org/news/
<_MMA_> geser: Old joke. Parody. ;)
<Mirv> they do state they are "Official Re-Distributor" and that Canonical recognizes them as such, so maybe they've a deal. http://princessleia.com/images/ubuntu/box_back.jpg
<kirkland> slangasek: hey, question for you, regarding soft freeze
<kirkland> slangasek: regarding https://lists.ubuntu.com/archives/ubuntu-devel-announce/2008-July/000446.html, I have a non-disruptive, minor change to lsb that's gating a stack of other patches.  I'm curious if it's a candid for upload during soft freeze, or if not, when the archive will open again for upload?
<soren> slangasek: re bug 187048> I checked that off my list long, long ago. It's not in intrepid?
<ubottu> Launchpad bug 187048 in virt-manager "virDomainCreateLinux() failed Timed out while reading console startup output" [Medium,Fix committed] https://launchpad.net/bugs/187048
<slangasek> kirkland: the archive will open again on Thursday; if the lsb change isn't going to break installabilities and is holding up progress elsewhere, go ahead
<slangasek> soren: according to the bug state, it's not
<soren> That's a fair point. :)
<kirkland> slangasek: it's not.  though I'll need a sponsor, as I don't have upload privs.
<calc> I switched over to approx 3.3.0 to see how it works, apt-proxy is too incomplete to be useful
<calc> it doesn't support more than one distribution (eg dapper/intrepid)
<calc> apparently the issues i had with approx may be fixed now
<ogra> apt-proxy is ingenious for image building ...
<ogra> but beyond that pretty useless
<slayton> has anybody here used xdg-desktop-menu install before? I've got some weird errors... the Name=<value> is being ignored in my .directory files...
<slayton> oops wrong channel
<doko> kirkland: please file a report and patch and subscribe me
<kirkland> doko: thanks, it's https://bugs.edge.launchpad.net/ubuntu/+source/lsb/+bug/246735
<ubottu> Launchpad bug 246735 in lsb "status_of_proc() calls pidofproc() which calls kill, requiring ownership privileges on the process" [Medium,In progress]
<kirkland> doko: i think kees was going to sponsor it, but i haven't seen it yet
<kees> kirkland: sorry, got caught up in bind9 update paperwork
<TheMuso> slangasek: Ubuntustudio is still nowhere near an alpha, due to still unresolved kernel issues.
<slangasek> TheMuso: ok. is anyone actively working on those?
<kirkland> kees: yeah, i bet that's consuming you, sorry for this nagging, then
<TheMuso> slangasek: I belive our kernel guy is, but haven't heard any status on this as yet.
<kantor> hi, how makes ubuntu to use ATA and ATAPI (hdx) devices as SCSI devices (sgx, scdx) ?
<cjwatson> Mirv: er, yeah, I think you read my sentence the wrong way round
<cjwatson> Mirv: my sentence meant "it seems likely to me that it doesn't fall within the trademark policy"
<cjwatson> Mirv: I'm surprised that Canonical would have approved something called "Ubuntu Complete Edition", thereby implying that normal Ubuntu is incomplete
<cjwatson> I'll ask around
<cjwatson> ah, well, Fabian's comment on princessleia's blog would be authoritative on that I suppose
<Keybuk> ogra: what's up?
<ogra> Keybuk, hey ... i'm working with ion_ on the compcache spec ...
<ogra> https://wiki.ubuntu.com/Compcache
<ogra> if you look at the code snippet in there, there is a modprobe followed by a swapon
<ogra> the loading of the compcache module is slow though ... which means the swapon will catch a race
<ion_> ogra: My patch is about ready, iâll post it in a bit.
<ion_> Itâs using udev.
<ogra> Keybuk, all the core stuff will be added to initramfs-tools for compcache ... to avoid the race ion_ proposed a udev script like http://revu.ubuntuwire.com/revu1-incoming/compcache-0807071820/compcache-0ubuntu1/debian/compcache.udev
<ogra> Keybuk, my simple question is where to put something like that in the initramfs-tools source :)
<ogra> we dont have any rules scripts there yet ...
<ion_> My patch handles that as well. :-P
<ion_> Kind of
<ion_> Iâll see whether you approve.
<Keybuk> in the debian/ directory ?
<ogra> ah, k i didnt know that yet :)
<infinity> ogra: Should land in /etc/udev, like any other udev rule...
<ogra> infinity, in the package source ?
<ogra> (of initramfs-tools)
<ogra> well, lest wait for ion_, i dont know his solution yet :)
<Keybuk> wherever seems sane
<Keybuk> I'd argue you should put it in the compcache source package
<kees> kirkland, doko, slangasek: lsb 3.2-12ubuntu2 has been uploaded
<infinity> Yeah...
<ogra> i dont want a compcache source package
<ogra> its a core feature like framebuffer or thremal
<Keybuk> otherwise how do you disable it?
<ogra> initramfs.conf
<kirkland> kees: much thanks!
<ogra> its disabled by default
<Keybuk> thermal shouldn't be loaded by the initramfs
<ogra> (see the spec =
<ogra> :)
<ogra> well, you know what i mean
<kees> kirkland: no problemo :)
<infinity> Keybuk: thermal probably shouldn't, but it is, because we had nowhere else to put it.
<ogra> its a kernel module and gets the config from initramfs.conf
<Keybuk> infinity: udev loads it
<ion_> ogra, keybuk: heh.fi/tmp/initramfs-tools-compcache.diff
<infinity> Keybuk: And PowerMacs explode if you don't load fans early and often.
<Keybuk> (it didn't at the time we put it in there, but it does now)
<kirkland> kees: would you mind pinging me when bind9 is done?  I'll hold off on posting the init script patch until you've updated Intrepid
<ion_> Whoops, http://heh.fi/tmp/initramfs-tools-compcache.diff
<infinity> Keybuk: Yeah, well.  Point's still valid, even if the implementation has since gone away. :)
<kees> kirkland: well, it's mostly done now.  still issues with glibc that need to be sorted, but not by me yet.
<ogra> ion_, eeek, i thought we had agree on standadizing for percent only
<ion_> Uh, i thought we didnât. :-) Me wants 50 %.
<ion_> The overhead of the percentage code is neglibigle, and any of it doesnât go to the initramfs if a percentage isnât used.
<ogra> i just dont like the massive amount of options
<ion_> 50 %, 65536 k, 256 M, 1 G. Is the number of suffix choices really that massive?
<ogra> also its missing the change from my patch to auto_add_modules ...
<Keybuk> isn't it K ?
<ion_> force_load does that.
<ion_> keybuk: Nope. If weâd use kibits, itâd be Ki.
<ogra> hmm
<Keybuk> ion_: everywhere else in Ubuntu uses KB
<Keybuk>           RX bytes:2960 (2.8 KB)  TX bytes:2960 (2.8 KB)
<infinity> Keybuk: I surely hope not.
<infinity> Ick.
<ion_> Kelvinbytes :-)
<Keybuk> so you should match
<infinity> Keybuk: There's no such SI prefix.
<Keybuk> infinity: bytes aren't SI units
<infinity> Keybuk: Matching incorrect prefixes isn't sane.  Where else is "everywhere"?
<Keybuk> nor are bits
<Keybuk> and you can't argue for them to be SI units either, because a tenth of a byte is meaningless
<ogra> Keybuk, infinity optioions on the amount of options ?
<Keybuk> and SI units must, by definition, be equally divisible as they are multiplicable
<ogra> i'm not really happy with so many
<infinity> ogra: The number of options are fine.
 * ogra would have gone with MB only or alterantively with %
<ogra> its not that it will be used by standard users or so
<infinity> Keybuk: You can argue until you're blue in the face, but the units are "kB and KiB", we can argue what they MEAN, but there is no "KB" documented anywhere that I know of.
<ion_> infinity: It would be worse: in Finland, operating systems and computer magazines have switched to using t instead of B, because byte happens to be tavu in Finnish.
<Keybuk> infinity: it's certainly documented in the Oreilly style guide ;)
<ion_> Itâs as if nobody learned in school that you donât translate units, period. :-)
<Keybuk> and KB is used everywhere else in Ubuntu
<ogra> ion_, can you drop the export  ?
<ogra> . "${CONFDIR}/initramfs.conf" in mkinitramfs conf should take care
<Keybuk> and has been the conventional way people on the street have written it for years
<ion_> ogra: Will do.
<infinity> Keybuk: Does "KB" in the output of ifconfig mean "1000 Bytes" (kB) or "1024 Bytes" (KiB)?
<Keybuk> infinity: 1024 bytes
<Keybuk> as its meant to everyone since the dawn of time, before other people decided to be silly
<infinity> Keybuk: I'd argue that if it means "1000", it should be a lower-case k, and if it means 1024, then fine, KB == KiB works for me.
<wgrant> Oh dear, this debate is going nowhere good (though I side with infinity)
<lamont> and this is what happens when marketing and pedants get near specificiations
<ogra> heh
<calc> just send all of the people who like si bytes to siberia ;)
<Keybuk> I have scientists on my side ;)  a byte cannot be an SI unit
 * calc wishes the installer used real units instead of the si crap
<Keybuk> no matter how hard the strange people wish
<calc> i end up partitioning my system with fdisk and bc
<lamont> calc: and while we're at it, lets put an upper limit of 70MB on a package source. :-p
<Keybuk> calc: it should use real units, we deliberately patch software in Ubuntu to eradicate KiB where we find them
<calc> lamont: heh :)
<calc> lamont: even the diff.gz is bigger than 70MB ;-)
<lamont> I know
<Keybuk> (though partitioners have their own strange problems, since disk manufactures use multiples of 1000 blocks of 1024 bytes
<Keybuk>  or is it the other way around?)
<lamont> if your diff.gz is bigger that 50MB, it's time to bump the version and make a new orig.tar.gz :)
 * ogra dances ... finally got the cmpc image back under 800M
<calc> Keybuk: fdisk was good until the author decided to switch it to 1000 bytes
 * LaserJock yells "SI FTW!!" and runs to hide behind a laser
<Keybuk> lamont: isn't that forking?
<Keybuk> calc: fdisk is correct
<lamont> Keybuk: diff.gz is forking
<Keybuk> disk manufactures really do use 1000 bytes as their base
<Keybuk> but then usually use powers of two to multiply that
<calc> yes but filesystems really use 1024 bytes
<ion_> ogra etc: http://heh.fi/tmp/initramfs-tools-compcache.diff
<lamont> Keybuk: that's marketing getting involved... it's all SI base now
<ogra> ion_, i'm not sure i actually like the approach of using modprobe.d here vs using a normal initramfs script
<wgrant> And disk manufacturers don't do it for innocent reasons.
<calc> in particular 4096 byte blocks, etc
<calc> bc
<calc> oops
 * Keybuk wants a 4 mb disk
<ion_> ogra: I can change that. I just thought force_load and modprobe.d would be the right thing to do.
<ogra> ion_, ond that it looks good to me ...
<ogra> *beyond
<ion_> Anyone else have comments about that?
<Keybuk> and a 23 nB USB key
<calc> i assume that means nautilus is supposed to show disk sizes by SI bytes then as well
<infinity> ion_: If it works, I honestly don't care how it's done.
<calc> since it claims my 32GB partition is 34.4GB
<ion_> keybuk: At least we have gb disks now since they introduced the VWBS technology.
<Keybuk> calc: nautilus uses 1024 multiples, iirc
<infinity> ion_: The current implementation that write files out during mkinitramfs is a bit unreadable, mind you...
<calc> Keybuk: it doesn't appear to here
<calc> 33551721 blocks for ntfs shows up as 34.4GB in nautilus
<infinity> ion_: On the flip side, it's unreadably located in one script, instead of being readably located across 3 or 4 files, so I guess it's a tossup.
<ogra> ion_, well, i like the approach, dont get me wrong, its just unconventional and totally different from anything we do in intramfs-.tools
 * lamont cries a little at 1:9.5.0-P1.dfsg-0build1 <= 1:9.5.0.dfsg-4
<Keybuk> (it'd be a neat project for someone to sanify all our usage of byte multiples -- as long as they don't use wankibytes)
<ion_> infinity: Originally i had the computation of the kilobytes in a script that goes into the initramfs, but ogra prefered that no extra computation or lines go to the initramfs, for instance parsin /proc/meminfo when using a percentage.
<calc> (33551721*1024)/2^30 = 31.997 GB
<infinity> lamont: s/-P1/.P1/
<lamont> yeah
<infinity> lamont: Dashes in upstream version numbers are vile anyway.
<ion_> keybuk: gb, VWBS: http://johan.kiviniemi.name/blag/2005/12/31/gb/ :-)
<ogra> ion_, right because the module dtrt and uses 25% if you dont supply a value
<lamont> upstream did it, not me.
<lkj> hello
<infinity> lamont: Yeah, I know. :)
<Keybuk> ion_: what's "gb" ?
<calc> it doesn't bother me too much that they renamed GB to GiB, etc but it should be displayed in computer units instead of braindead SI/HD Manufacturer units
<ion_> keybuk: Please see the page :-)
<calc> since filesystems don't use those screwed up units
<calc> and ram doesn't etc
<calc> so if you want to be certain you have enough swap to suspend you have to convert from real 8GB to SI 8GiB which shows up as 8.6 GB now
<Keybuk> ion_: wouldn't that be bits-per-gram?
<calc> big freaking mess all due to some greedy marketing people
<lamont> Keybuk: gb is where you live
<Keybuk> if you wanted a new unit, you can't just smash two units together and hope
<Keybuk> calc: I've never seen anyone use KiB
<Keybuk> or GiB
<Keybuk> especially not marketing people
<Keybuk> the only time I ever see it is when people with IRC adenoids start sticking their oar in and whinging
<cjwatson> partitioner> it uses disk marketing units because otherwise people complain that it doesn't match the advertised size of their disk. The topic is closed; I have no interest in debating it back and forward until the end of time, sorry.
<ion_> So, which ones shall i do? 0) Make the hook clearer by putting the kilobyte calculation to a separate script that is installed VS. let them stay in the hook, making it a bit unclear. 1) Use force_load and modprobe.d VS. do modprobe $parameters directly in a script.
<Keybuk> cjwatson: but it doesn't use "GiB" ?
<lamont> Keybuk: 4.7GB on a dvd...
<cjwatson> Keybuk: er, no, it uses disk marketing units, i.e. 1000 not 1024
<Keybuk> cjwatson: right, that's exactly what I understood
<norsetto> state the size in binary and let them convert it to whatever units they like
<Keybuk> which, in a partioner, is entirely correct
<lamont> norsetto: grandma won't like you
<norsetto> lamont: should I say what I think of grandma?
<lamont> she is the ubuntu user base
<norsetto> lamont: I love her :-)
<ion_> ogra? infinity?
<ion_> ogra: Oh! Sourcing /e/i/initramfs.conf isnât enough. We forgot /e/i/conf.d and /u/s/i/conf.d
<ion_> ogra: Should i source the files in them as well, or just export the variable in mkinitramfs?
<ogra> no
<ogra> thats all done already
<ogra> nothing you need to take care of
<ion_> ogra: Wait... mkinitramfs sources everything, but with the latest change, it doesnât export the variable, i do . /etc/initramfs-tools/initramfs.conf as you suggested. But that fails to read the files in /etc/initramfs-tools/conf.d etc, in which COMPCACHE_SIZE may be overridden.
<ogra> err
<ogra> i didnt suggest you to add that line
<ogra> its already in mkinitramfs :)
<ion_> Ah, i misread. Sorry.
<ogra> nothing to do with that on your side
<calc> Keybuk: which makes the partitioner useless
<calc> Keybuk: since it is important in several cases that your partition match whatever you want to call real *B's
<calc> for the past 4-5 years (whenever he got on crack) I have had to use bc and cylinders to partition systems
<calc> perhaps a good solution for users would be to suggest the GB size to make their swap to actually match their ram size for suspend
<calc> since they don't match if you use marketing crap for partitioner
<cjwatson> no, it does not make the partitioner useless
<infinity> ion_: Remove the source from your hook script, and add an export to mkinitramfs.
<cjwatson> I think you'll find that plenty of people manage to use the partitioner quite successfully
<calc> also some fs like fat32 change cluster size based on GB boundaries
<Keybuk> calc: isn't that exactly what the partioner already does?
<calc> cjwatson: oh it works as in it creates a partition of course
<cjwatson> the partitioner already suggests sensible swap sizes based on RAM size, yes
<infinity> ion_: Well, export it if you need it during mkinitramfs.
<calc> Keybuk: it does? i don't recall seeing it tell me that, maybe i was installing in a mode that didn't show it
<infinity> ion_: If you need it on boot, it needs to end up in a conf file.
<cjwatson> if you're doing autopartitioning
<infinity> ion_: (See, for instance, the line with: echo "DPKG_ARCH=${DPKG_ARCH}" > ${DESTDIR}/conf/arch.conf")
<cjwatson> and seriously, it does not matter if your swap partition size differs by a factor of 1.024
<cjwatson> there are more important things to worry about
<cjwatson> the autopartitioner suggests bigger than RAM anyway ...
 * calc got called in to finish cooking dinner
<cjwatson> that said, it would make sense to have a warning if swap is smaller than RAM, and I'd appreciate a bug on partman-basicfilesystems for that
<Chipzz> 00:06 < ion_> It's as if nobody learned in school that you don't translate units, period. :-)
<Chipzz> ion_: tell THAT to the French :P
<cjwatson> (sorry, I didn't see "suspend" in calc's comment at first)
<Chipzz> damn "octets" :P
<ion_> chipzz: Well, o is at least a standard.
<Chipzz> ion_: it is? outside of France, I mean :P
<ion_> Hm, at least i was under such an assumption.
<ion_> I may be wrong.
<cjwatson> one option would be to set up ubiquity such that hovering over the partition would pop up a tooltip with exact size
<Chipzz> I wonder how "octet" can be a standard when the concept of byte was invented by an English speaker :P
<Chipzz> anyway, offtopc :P
 * lamont finds it amusing that engineers of back-when said KB, knowing full well that there was a 2.4% error, and just not caring.  If you want precision, then you're kind of stuck with the actual SI units...
<Keybuk> lamont: except that a byte cannot possibly be an SI unit
<Keybuk> if you want precision, you can simply type out, in full, what you mean
<lamont> except that the same computer engineers co-oped si for their new "unit"
<Keybuk> since if you're rounding by a factor of one million, or even a thousand million, you really really aren't getting any kind of precision anyway
<Keybuk> lamont: what use is a nanobyte?
<Keybuk> or a millibit?
<lamont> Keybuk: exactly.  if you use the SI unit prefixes, then you mean 10^3.
<Keybuk> why not just write that, if that's what you mean?
 * lamont has heard of networks with millibits per second of throughput
<Keybuk> if you have exactly that number of bytes
<infinity> lamont: Yours?
<lamont> Keybuk: right.
<lamont> infinity: meh
<lamont> no.  someone implemented IP-over-bongo-drums.
<lamont> 140second ping time
<Keybuk> if you have 8 x 10^3 + 47 bytes, you're not being precise anyway
<Keybuk> so who cares?
<lamont> Keybuk: remember that engineers come from a world where the models they use are off by 10% or more
<lamont> Keybuk:  marketing
<Keybuk> marketing don't use wankibytes
<lamont> and so they reduced the error when it became 4.9 and 10% to being .1%
<Keybuk> (not that I've ever seen, anyway)
<lamont> marketing uses KB and they mean 10^3
<lamont> everyone means 10^3
<lamont> then there are the pedants who _think_ they mean 2^19
<lamont> 2^10 even
<calc> cjwatson: its not a factor of 1.024 its a factor of 7.3% for GB
<Keybuk> disk marketing use 10^3
<Keybuk> RAM still use 2^10
<calc> will be a factor of 10% for TB
<Keybuk> calc: ?! it's a constant factor
<lamont> calc: and that's why marketing decided that they wanted to advertise the extra space, and that the error was becoming significant enough to care
<Keybuk> calc: it's always a constant factor of 1000:1024
<cjwatson> Keybuk: no, he's right
<calc> 1 TB hard drives are 1,000,000,000 Bytes
<Keybuk> he is?
<cjwatson> Keybuk: 1024*1024*1024 vs. 1000*1000*1000
<lamont> Keybuk: yes
<calc> they round off decimal all the way
<ogra> ion_, let me sleep a night over the modprobe.d thing ... beyond that i'm fie with the patch
<Keybuk> oh, of course
<Keybuk> it's nearly 2am here
<ogra> *fine
<calc> it will continue to increase the difference as sizes go up
<calc> so for PB whenever they come around it will be 13% difference
<cjwatson> I'm still not going to change the unit expression in the partitioner. Sorry. People will complain either way round. I'm willing to make improvements to make it clearer what's going on.
<lamont> Keybuk: and the most amusing part is that those of us who say GB when the pedants would say we need to use GiB, really just don't care about being off by 10%
<cjwatson> and just noticed that there's no way to force it to enter an exact number of bytes at the moment, so can fix that one
<pwnguin> well, as long as dd doesnt use anything but bytes, i think we'll live
<lamont> cjwatson: clearer == better, I think
<lamont> and yeah, there are much bigger fish to fry
<infinity> cjwatson: Just change it to measure everything in UU (uber units) with a footnote explaining what that is, and why it's superior to kB, KB, and KiB combined.
<lamont> infinity: reminds me of SWU.
<Keybuk> lamont: my theory goes that as soon as you round to a GB, you no longer care about lost KB
<lamont> Keybuk: exactly
<Keybuk> the only thing I care about is that what our user interface states matches what the user sees on the box
<Keybuk> thus disk sizes should be reported in KB, MB and GB which are multiples of 1,000
<Keybuk> and RAM sizes reported in KB, MB and GB which are multiples of 1,024
<Chipzz> 00:27 < calc> perhaps a good solution for users would be to suggest the GB size to make their swap to actually match their ram size for suspend >> if you try to match those exactly, I think you've already lost anyway, since a swap partition includes a signature
<cjwatson> Chipzz: it would make sense for there to be a check though
<cjwatson> with appropriate fudges for such details
<lamont> Keybuk: my RAM size is reported by bios units of 10^b
<emgent> hello
<lamont> see also maretroids
<Chipzz> cjwatson: check as in checkbox?
<Keybuk> lamont: but it is bought in boxes with units of power-of-two bytes
<Keybuk> you still buy a 2GB RAM stick, and it means 2*1024*1024*1024 bytes
<Chipzz> cjwatson: the issue gets more hairy with filesystems, where the overhead is not of a fixed size
<lamont> Keybuk: and then you boot he computer, and it tells you some other number of bytes
<Chipzz> and to add up to that, you need to specify the size of the partition before you specify the type
<lamont> and you wonder where the extra 100MB of space came from
<cjwatson> Chipzz: hi, I'm grandma, perhaps you'd like to teach me to suck eggs ;)
<Keybuk> lamont: I don't see this as our problem
<Chipzz> I don't think my grandma cares :)
<cjwatson> Chipzz: a check as in a check, confirmation, if statement to confirm that swap is big enough to suspend into. I don't care about the tedious details for this purpose
<Chipzz> in fact, we tried to explain on her on numerous occasions how to program a VCR, even written it down for her, and she still fails to do it :P
<cjwatson> Chipzz: "teach grandma to suck eggs" => "explain in tedious detail to somebody who already knows"
<lamont> Keybuk: eventually, someone in marketing will win an argument, and some memory maker will start selling 4.2GB sticks
<Chipzz> cjwatson: ah yes :)
 * calc would be appeased if he could tell it somehow the exact size he wanted in bytes or GiB or whatever, GB is not exact when sectors are not in x^10 power
<lamont> I predict it'll hit when it's 128GB vs 131GB, if not sooner
<calc> or change sectors to be 10^3, 1000 byte per sector would work fine
<Chipzz> anyway, my opinion on the matter is we should use 2^n, and the hard disc manufacturers can go **** themselves ;)
<calc> don't need pages anymore :)
<calc> lamont: maybe, but eventually it will stop unless someone releases a new decimal based cpu
<Chipzz> actually I think some hard disc manufacturers already got sued over using 1000 instead of 1024
<lamont> calc: decimal-based-cpu?  just use COBOL
<calc> lamont: well yea since pages, etc are binary sized
#ubuntu-devel 2008-07-09
<calc> Chipzz: iirc they did which was what sparked this stupid renaming GB -> GiB and giving the hd marketing people their GB back
<Chipzz> marketing stinks :P
<kirkland> slangasek: hey, I have a question about this comment of yours... https://bugs.edge.launchpad.net/ubuntu/+source/lsb/+bug/203169/comments/12
<ubottu> Launchpad bug 203169 in sysklogd ""status" function for init scripts" [Wishlist,In progress]
<ion_> ogra, infinity: How about http://heh.fi/tmp/initramfs-tools-compcache.diff
<ogra> he return of the export line :)
<ion_> ke012817 < infinity> ion_: Remove the source from your hook script, and add an export to mkinitramfs.
<ion_> ke012858 < infinity> ion_: Well, export it if you need it during mkinitramfs.
<ion_> Iâm hearing two opposite instructions here. :-)
<ogra> huh ?
<ogra> well, i use conf.d with te ltsp scripts and it gets sourced correctly without adding any extra export commands
<ogra> and i see initramfs.conf being sourced by mkinitramfs
<ion_> To hooks?
<ion_> mkinitramfs only seems to export specific variables for hooks.
<ion_> If you set one of those variables in conf.d, it works in hooks.
<ogra> and why did you switch to m4 now ?
 * ogra would really prefer a set of plain shell scripts
<ion_> To make the hook script clearer. Having templates for shell scripts in a shell script was a bit nasty, having to do stuff like '"$foo" ... '"'"'bar'"'"' ... "$baz"' etc.
<ogra> and i must admit i liked the former aproach a lot more
<ogra> even though it breaks with every setup we have in that tree the modprobe.d looked extremely clever ... i just didnt like how you created it and that it isnt a script like we have for everything else
<ion_> ogra: How about http://heh.fi/tmp/initramfs-tools-compcache.diff
<ogra> why not just use shell commands ?
<ogra> instead of m4
<ogra> just use a here document
<nxvl> pitti: around?
<ion_> I can do that. I just though itâs a bit annoying and error-prone having to escape the sed stuff to a shell variable.
<ion_> t
<ogra> i dont think you need "mkdir -p "$DESTDIR"/scripts/init-top"
<ogra> thats a structure you can rely on being there since we're inside the package that carries this dir
<ogra> make <<E being <<EOF .... we usually use EOF everywhere makes it easier to keep the overview :)
<ion_> ogra: http://heh.fi/tmp/initramfs-tools-compcache.diff
<ogra> and infinity might be right that the export is needed ... which i'd consider a bug though, but i see the functions clling the hooks are sourced before the config
<slangasek> kirkland: what's the question?
<kirkland> slangasek: i think lamont helped solve it with me in #ubuntu-server
<slangasek> hmm, ok :)
<kirkland> slangasek: i think something like this will work: status_of_proc /usr/sbin/named bind9 && exit 0 || exit $?
<ion_> kirkland: status_of_proc /usr/sbin/named bind9; exit $? should be equal
<slangasek> kirkland: er, usually you would just do "status_of_proc /usr/sbin/named bind9" when the script is running under set -e
<ion_> Oh, sorry. Didnât consider set -e.
<slangasek> hence the comment that it's redundant
<ogra> ion_, i like it a lot :)
<kirkland> slangasek: right, but only 1 of the 9 packages i've touched has the init script running set -e
<ion_> Iâm squeamish about the kâK change, but oh well...
<lamont> slangasek: relying on -e to catch you is also bad
<kirkland> slangasek: ideally, i'd like to keep the construct/call as identical as possible for consistency
<lamont> I'm a proponent of being explicit
<ogra> ion_, <nitpick>can you add some linebreaks to: +if [ "\$1" = prereqs ]; then exit 0; fi</nitpick>
<slangasek> lamont: why is it bad when writing init scripts and good when writing maintainer scripts?
<ion_> ogra: Will do. How about the equivalent thing in the generated script?
<ogra> heh
<lamont> slangasek: there's a specific difference between "we got an error" and "we're supposed to return non-zero status now"
<slangasek> kirkland: ok, then I suppose that works, but I just think it shows up how all code that's not set -e is inherently ugly, and the lsb init script spec is therefore evil for forbidding its use :)
<slangasek> lamont: well, there's that, yes
<lamont> not in the value returned, but in the scratch my head figuring out if it's an error or not case
<ogra> i missed the one at the top, that *was* the generated script one :)
<slangasek> right, so in this case that construction makes a certain amount of sense
<ogra> ion_, so yes, that too
<ion_> ogra: Diff updated.
<ogra> (either put all ifs in one liners or none of them :) )
<ogra> ion_, perfect ... now compare that with what we had in the beginning ... thats simple, clean and beautiful code :)
<kirkland> slangasek: here's the samba one... http://pastebin.ubuntu.com/26066/
<ion_> Yeah
<slangasek> kirkland: is this status_of_proc being pushed up to Debian, so I can commit that to the Debian Samba package too? :)
<ogra> sooo ... lets see what we can do about the export .... if i can get infinity's attention :)
<ion_> A modprobe.d file could be generated exactly alike, but iâm okay with generating a script instead. :-)
<ion_> ogra: Iâll reboot now and check that it actually works. :-)
<kirkland> slangasek: being pushed, yes... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=483285
<ubottu> Debian bug 483285 in lsb-base "lsb-base: lsb status_of_proc() function" [Wishlist,Open]
<ogra> ion_, thats actually a god idea :)
<ogra> *good even
<slangasek> kirkland: ok, cool
<kirkland> slangasek: maintainer agreed to it in principle, cites "adding functionality would break the spirit
<kirkland> of the freeze, but I'll plan on getting status_of_proc() into unstable
<kirkland> soon after that migration happens (hopefully soon)"
<kirkland> slangasek: i'll ping him again and see how that's coming along...
<kirkland> slangasek: as a DD yourself, what freeze is he talking about, and when might that freeze end?
<slangasek> that would be the freeze for lenny
<slangasek> which is going to last, um, a fair few months
<slangasek> but I don't think this change should be a problem under the freeze
<slangasek> mathiaz: dunno if you follow pkg-openldap-devel, but the source package name in Debian has just (and finally) switched from openldap2.3 to openldap; I suggest we follow suit for intrepid
<Nubae> ï»¿ hmmm, anyone know how to discover the firefox-default-profile, as in this path for example: ~/.mozilla/firefox/83lemdbc.default/extensions/{000a9d1c-beef-4f90-9363-039d445309b8}
<ion_> ogra: Yeah, it works.
<kirkland> slangasek: good, i was kinda thinking the same thing...  just a new function, no modified existing functionality
<ogra> ion_, wonderful
<kirkland> slangasek: let me update the debian bug with an updated patch
<Nubae> I want to install the components of an extension manually via a .deb and a .rpm but not sure how to discover the firefox profile
<ogra> can you try again with dropping the export
<slangasek> mathiaz: i.e., get it done while the merge is still otherwise trivial
<kirkland> slangasek: if you think adding a comment in support would help, I'd appreciate it
<mathiaz> slangasek: yop - I followed that
<slangasek> mathiaz: cool
<mathiaz> slangasek: you renamed it to openldap \o/ - it has been accepted today IIRC - so we can merge it soon
<mathiaz> slangasek: also noticed that samba 3.2 has been uploaded to unstable
<slangasek> mathiaz: how are things going on the cn=config front?
<slangasek> mathiaz: eh, if 3.2 is anywhere other than experimental right now, then I screwed up badly :)
<mathiaz> slangasek: hm - good question - I've started to look at the code and wraped by around it
<ion_> ogra: Nope, doesnât work.
<ion_> % zcat /boot/initrd.img-2.6.26-3-generic | strings | grep compcache
<ion_> # An empty value - compcache isn't used, or added to the initramfs at all.
<mathiaz> slangasek: hm - I must have overlooked the samba upload then
<mathiaz> slangasek: I noticed that things were commited to the experimental branch
<slangasek> we have one bug in 3.0 (the security-update-regression that jdstrand identified) that we want to get pushed into testing before dropping 3.2 in unstable, and I think upstream also has a bug in how they're putting together libsmbclient.a that I want to fix
<ogra> ion_, ok, imho it should
<mathiaz> slangasek: wrt to openldap, I've got some working code, but I'm kind of not sure how to structure the whole thing
<mathiaz> slangasek: so I'd like to have your feedback on it
<ion_> ogra: Perhaps just add export -a to mkinitramfs.
<ogra> no
<slangasek> mathiaz: ok - should we schedule some time to sit down for that?
<mathiaz> slangasek: which brings another question - what is the impact on the lenny freeze on that work ?
<mathiaz> slangasek: definitely
<ogra> can you try moving the two lines below "# For dependency ordered mkinitramfs hook scripts." under the config stuff
<ogra> in mkinitrmafs
<mathiaz> slangasek: is there a chance that the cnconfig stuff will accepted in lenny (which means in the intrepid timeframe IIUC) ?
<ogra> that way the functions shooud have access to the vars
<slangasek> mathiaz: because openldap builds library packages, it will need to go through the Debian release team as a freeze exception, but I believe this is only nominally an exception at this point
<slangasek> mathiaz: if we could get something into unstable this month, that would certainly be ok wrt the lenny timeline, I think
<ion_> ogra: How about the equivalent of for hook in hooks/*; do ( . "$hook" ); done? That is, source all hooks in a subshell.
<mathiaz> slangasek: ok - I plan to submit my work to the debian maintainer list as soon as I've got something
<ion_> ogra: Ok, iâll take a look at that.
<mathiaz> slangasek: to get some feedback
<ogra> ion_, i think thats what run_scripts does
<mathiaz> slangasek: one of the thing I'd like to get done is to be able to ship slapd.scripts-common in the package and provide scripts to perform common config operations
<mathiaz> slangasek: such as loading new schemas or adding a new directory database
<mathiaz> slangasek: that's the whole point of having the cn=config backend enabled
<ion_> ogra: Moving those lines below the config stuff didnât make it work.
<ogra> ok
<ogra> then we need to keep the export :/
<mathiaz> slangasek: but then things get complicated really quickly
<mathiaz> slangasek: that's why I'd like to discuss that and get your input on that
<slangasek> mathiaz: well, slapd.scripts-common still has to be embedded in the preinst, because shipping it in the package doesn't make it available until after the package is unpacked
<slangasek> mathiaz: so if you have a use case for calling those functions from outside maintainer scripts, shipping it is fine, just as long as you don't expect to refactor too aggressively :)
<slangasek> (for my part, I want to see the shell library shrink down to nothing over the next few releases, which is one reason I want cn=config in lenny :)
<mathiaz> slangasek: ok - I try not to refactor to much
<mathiaz> slangasek: I've taken the approach of adding cn=config support to existing functions in slapd.scripts-common
<ion_> ogra: Nope, call_scripts doesnât use .
<ogra> run_*
<ogra> oh, right, call_
<ogra> sorry
<ion_> It would be a bit hairy, though, since hooks check $1 for prereqs.
<mathiaz> slangasek: I think I'll keep working on the scripts this week and we should schedule a call at the begining of next week to go over my work
<slangasek> that sounds good
<ion_> Could be done with something like ( set -- prereqs; . $hook ) for prereqs and ( set --; . $hook ) for running the hook, though.
<Chipzz> mathiaz: what about the cn=config thing?
<Chipzz> mathiaz: I'm using that feature in debian for munin monitoring
<ogra> right, i was expecting the scripts to inherit the vars from the calling script if we re-order ... the export is the best thing otherwise
<ogra> so lets just keep it
<mathiaz> Chipzz: I'm working on adding cn=config support to the package
<mathiaz> Chipzz: so that a default install of slapd in intrepid will use cn=config instead of slapd.conf
<mathiaz> Chipzz: and we'll also support upgrading from slapd.conf to cn=config
<Chipzz> ah k
<Chipzz> mathiaz: could you look into getting this into munin? http://wiki.ruberg.no/index.php/Munin_LDAP_plugins
<mathiaz> Chipzz: you'd better file a bug about this
<mathiaz> Chipzz: the chance this get lost will be higher here ;)
<Chipzz> can do
<Chipzz> file a bug in debian, ubuntu or both?
<mathiaz> Chipzz: debian is the best place IMO
<ogra> ion_, so how about making a debdiff from that so your name is in the changelog ... ?
<ion_> ogra: Will do.
<kirkland> slangasek: patch for samba status attached to: https://bugs.edge.launchpad.net/ubuntu/+source/sysklogd/+bug/203169
<ubottu> Launchpad bug 203169 in sysklogd ""status" function for init scripts" [Wishlist,In progress]
<kirkland> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/sysklogd/+bug/203169/comments/27
<savvas> ok this channel looks more appropriate for this :)
<savvas> does this patch look good? http://launchpadlibrarian.net/15898720/python-apt_0.7.4ubuntu7.2.debdiff
<emgent> Bug #244093
<ubottu> Launchpad bug 244093 in python-apt "Checking security repository in Updates adds deb line to Third-Party Software" [Undecided,In progress] https://launchpad.net/bugs/244093
<savvas> oh, sorry, forgot to mention that
<emgent> savvas: debdiff is attached. Security Team will see it.
<savvas> that was quick, thanks emgent!
<savvas> i don't have to do anything for the moment right?
<savvas> *anything else
<emgent> savvas: just subsribe in this bug last uploader.
<savvas> emgent: to subscribe the maintainer of the package?
<emgent> savvas: you can subscribe ubuntu-main-sponsor
<emgent> but Michael Vogt is APT Master :)
<savvas> it said it will notify the maintainer
<savvas> ah ubuntu-main-sponsor, I'll do that
<savvas> - ubuntu-main-sponsors Ubuntu Sponsors for main
<savvas> this one emgent ?
<emgent> savvas: true.
<emgent> but i suggest to subscribe Michael Vogt too..
<savvas> done and done!
<emgent> now wait :)
<savvas> I think his nick is mvo at launchpad, hopefully that's correct
<emgent> him will review it
<emgent> mvo, sure.
<savvas> this package fixing is fun! :)
<slangasek> kirkland: you may wish to tie that in to Debian bug #488275
<ubottu> Debian bug 488275 in samba "samba and winbind: initscript miss 'status' option" [Wishlist,Open] http://bugs.debian.org/488275
<kirkland> slangasek: sure, you bet
<emgent> i go to sleep, night people
<ion_> ogra: Is the comment i added to the COMPCACHE_SIZE documentation ok? http://heh.fi/tmp/initramfs-tools_0.92bubuntu3.debdiff
<ion_> ogra: I uploaded a version of compcache package that handles the initramfs-tools change correctly: it doesnât include an initramfs hook anymore and it puts the setting to /usr/share/initramfs-tools/conf-hooks.d/compcache
<ion_> ogra: ...to REVU
<ogra> you should (sorry for tht) probably rename it again
<ogra> like compcache-tools ...
<ogra> i.e. take fuse as example here
<ion_> Hm, tools/utils is a bit strange for a package that doesnât contain anything in $PATH. But i guess thereâs no better choice.
<ion_> Should i go with tools or utils? :-)
<ogra> compcache-config ?
<ogra> no idea ... but just calling it compcache somewhat doesnt seem to fit
<ion_> I think iâll go with -config, even though it contains modprobe.d and udev/rules.d files in addition to the debconf stuff.
<ion_> And an init script.
<ion_> Unless there are better ideas. :-)
<ogra> probably LaserJock has one :)
<LaserJock> ogra: one what?
<ion_> laserjock: A name for the package compcache-FOO, which contains debconf magic to configure the size as well as init, modprobe.d and udev/rules.d scripts. :-)
<ion_> tools? utils? config? None of them seems to fit exactly. :-)
<LaserJock> compcache-setup?
<ion_> Not bad.
<ion_> Iâll use -setup.
<ogra> yeah, i knew it :)
<LaserJock> ogra: so I haven't gone to uni for 10 years for nothing?!?! :-)
<ogra> you can cut out little presents to sell on flea markets with lasers and the like as well, i know :)
<ogra> LaserJock, so how is life ?
<LaserJock> ogra: hmmm, busy :-)
<ogra> yeah, same here
<LaserJock> ogra: getting closer to being done though
<ogra> heh, me too ...
<LaserJock> should be done before next UDS
<ogra> i'm just building whats supposed to become the final cmpc image for hardy
<LaserJock> (yeah, my calendar revolves around Ubuntu development cycles)
<ogra> hey and its even in the US
<LaserJock> ogra: oh awesome, newer kernel?
<ogra> so we'll meet :)
<LaserJock> I hope
<ogra> -19.something yes
<LaserJock> I'll try it out once you're finished
<ogra> i'm still struggling with the display driver though
<LaserJock> :(
<ogra> they insist on using their hacked up i810
<LaserJock> ah
<ogra> but thats two versions behind ours (which is outdated as well)
<LaserJock> I just have problem with wanting to download all kinds of goodies and filling the drive
<ogra> yeah, not much i can do about that though
<ogra> i could do the sme as metasys if i were evil ...
<LaserJock> no, it's already quite amazing how much you've shrunk it
<ogra> they link /usr/bin/rpm to /dev/null there
<jdstrand> kees: I know that -rt kernels are in universe, but I kinda thought we get -security updates for free with them.  seems -19 for -rt doesn't exist. will it?
<LaserJock> ogra: umm, ewww
<ogra> well, you wont fill up the system with apps :)
<LaserJock> I suppose
<ogra> no idea about -rt, sorry
<kees> jdstrand: uhhhh... I thought they were part of the upload?
<LaserJock> ogra: Windows had a good way of doing that, just run out of memory so the installer dies
<jdstrand> kees: apt-cache search linux-image|grep 19
<jdstrand> linux-image-rt still points to -18
<ogra> LaserJock, well, but kill the device a minute in advance by trying to bring up a ppup about low diskspace :)
<ogra> *popup
<kees> Package: linux-image-rt
<kees> Depends: linux-image-2.6.24-19-rt, linux-ubuntu-modules-2.6.24-19-rt
 * jdstrand scratches head
<kees> jdstrand: I mean, I see the older package info to, but -19 is there for me
<jdstrand> what's with my local debmirror...
<kees> me too
<kees> jdstrand: I see three versions of linux-image-rt in my hardy repo: 2.6.24.16.18 2.6.24.18.20 2.6.24.19.21
<jdstrand> kees: hmm, I see it on all the machines except the one actually using -rt. sorry for the noise
<kees> np.  I wonder what that machine is doing?
<ion_> ogra: Ok, http://heh.fi/tmp/initramfs-tools_0.92bubuntu3.debdiff updated and compcache-setup uploaded to REVU.
<jdstrand> meh, -updates for main and restricted, but not universe. I'm a dolt
<ogra> ion_, err, updated ?
<ogra> ion_, i uploaded it 10mins ago :)
<ion_> ogra: â< ion_> ogra: Is the comment i added to the COMPCACHE_SIZE documentation ok?â â updated the comment.
<ogra> oh, k
<jdstrand> kees: fun-- looks like ruby1.9 did not build on i386 or lpia-- test_copy_stream_rbuf() hung :/
<jdstrand> (intrepid)
<jdstrand> kees: all other archs built fine
<jdstrand> kees: I'll try to see what's happening tomorrow
<jdstrand> heh: Build killed with signal 15 after 150 minutes of inactivity
<ion_> I think there was a discussion about that here some time ago. Didnât really follow it, though.
<jdstrand> ion_: if you are responding to me, I was the last person to talk about it in here :)
<ion_> Heh, ok
<lamont> if I send email to launchpad to update a bug, does it have to be signed?
<lamont> and where does it go, and all that
 * lamont goes off to find the right wiki page
<TheMuso> lamont: If you are changing status/assignments etc, I think it has to be signed. For general comments only, no it doesn't need to be signed.
<lamont> I wanna make it say FixCommitted
<TheMuso> lamont: Then you need to sign the message.
<lamont> and then drop that into a commit hook
<lamont> and if I have to sign it, maybe I don't care enough yet
<Hobbsee> er, you rpobably need to sign all mails, no?
<Hobbsee> why not set it up to sign by default?
<Hobbsee> lamont: https://help.launchpad.net/BugTrackerEmailInterface
<lamont> Hobbsee: hence the maybe I don't care enough... I have to sign tags, not every commit
<slangasek> kirkland: oh, I didn't realize you were using pidof, or else I hadn't thought through the implications at the time I knew this; if you read the bug log, you'll see that I'm vetoing that as an implementation for the Debian Samba package
<lamont> slangasek: ah - what was the objection
<lamont> ?
<kirkland> slangasek: i recently switched to using /bin/pidof
<kirkland> slangasek: i was previously using pidofproc() which has a more sophisticated mechanism for obtaining the pid from pidfiles
<slangasek> lamont: that it doesn't respect PID files
<kirkland> slangasek: however, pidofproc() uses "kill -0" to see if a daemon is active
<slangasek> it violates the spirit of Debian policy's guidelines on init scripts
<slangasek> (but not the letter, since the letter says nothing about a 'status' arg :)
<kirkland> slangasek: which only works if you're the process owner or root
<lamont> kirkland: not respecting pid files is bad
<ion_> Upstart will void the need for pid files. \o/
<lamont> not respecting pid files would be a bug against the status function for at least some packages, which would be therefore a bug against lsb-release
<lamont> ion_: bullcrap
<lamont> or how will you handle having two instances of a daemon?
<ion_> How about having two Upstart job instances? :-)
<lamont> maybe
<kirkland> :-/
<lamont> now tell me how the control command that uses signals tells how to communicate with the daemon?
<lamont> IOW. where did you move the pid file with upstart?
<ion_> Doesnât the daemon provide a socket you can talk to, or a D-Bus API or something equivalent?
<lamont> (there are admins who prefer to run bind without the control port, and just have rndc use kill to talk to it...)
<lamont> for those admins, the API is "kill"
<ion_> Theyâre free to use PID files.
<ion_> Or query the PID from Upstart, or whatever.
<lamont> kirkland: anyway, I'll take the fix we put together, and if you switch to ignoring pidfiles, I'll either remove status, or file a bug against lsb-release
<lamont> and I don't see that there's a need for non-root to query a daemon status
<kirkland> lamont: um....
<lamont> well, it's a bug
<lamont> or maybe I'll just not admit to 'status' being there in the usage.
<kirkland> lamont: http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=30;filename=lsb.483285.diff;att=1;bug=483285 ... that doesn't yet respect pidfiles
<lamont> yeah - I know
<kirkland> i can add that tomorrow
<kirkland> i'm absolutely burnt out on this one today :-S
<lamont> it was a "please fix it before he accepts it, or it'll be broken and you'll be back begging him to take another change..."
<lamont> kirkland: understood
<lamont> I'm about to crawl into bed myself
<kirkland> lamont: okay...  i'll ping you tomorrow then
<lamont> hrm... time to go read up on how to get procmail to delete a header from certain mail messages that it receives
<lamont> because reply-to: $LIST is just plain stupid and wrong
<lamont> (and no, not an ubuntu list)
 * TheMuso kicks dmraid upstream. 1) *PLEASE* include Makefile.am/configure.in/ac files in your tarball 2) Even though you statically link a library, *PLEASE* use a soname in the event the library is built as a dynamic library!!
<TheMuso> Hrm I take it b ack, configure.in is included, but no Makefile.am files. :S
<lamont> if I upload a ...-2~build1 version, will the autosyncer simply overwrite it with -2 once that shows up in debian?
<Hobbsee> lamont: for intrepid, or?
<lamont> yeah
<Hobbsee> lamont: isn't that a moot point?  the autosyncer has already been turned off for intrepid
<lamont> trying to hop-skip around the fact that it's NEW in debian
<lamont> true
<lamont> 'twas more one of making sure that MoM wouldn't object. :)
<TheMuso> hrm ok it does have a soname.
<LaserJock> TheMuso: so, umm, why are you kicking upstream again? :-)
<lamont> there.  bind9_9.5.0.dfsg.P1-2~build1 uploaded to intrepid.  g'night.
<TheMuso> LaserJock: No Makefile.am files is enough::) The shared library is not named/symlinked properly when copied into place, and its easier to change Makefile.am than hack Makefile.in to do it.
<ion_> Note to self: read the tens of previous notes to self about buying an UPS.
<dholbach> good morning
<TheMuso> Morning dholbach.
<dholbach> hi TheMuso
<dholbach> TheMuso: thanks for your reply
<TheMuso> dholbach: You're welcome
<pitti> Good morning
<ion_> Howdy
<pitti> tjaalton, tseliot: new nvidia-glx working perfectly here with current intrepid (new X.org)
<pitti> (-173)
<tseliot> ï»¿pitti: great :-)
<seb128> hey pitti
<pitti> good morning seb128!
<bryce> pitti: :-)
<tseliot> bryce: hi ;)
<tjaalton> pitti: great, I'll install it too
<tjaalton> ..shortly
<bryce> tseliot: heya
<dholbach> hi seb128!
<seb128> hey dholbach
<seb128> dholbach: getting ready for your holidays? ;-)
<dholbach> yeah :)
<dholbach> lots of other stuff left to do still :)
<dholbach> how's Istanbul?
<seb128> great, I'm sure you would like it
<dholbach> definitely :)
<dholbach> seb128: the night they stole my camper bus I was looking at the map and figuring out how best to get to Istanbul with the bus :-)
<seb128> lol
<dholbach> so... yeah - I'd love to go there at some stage
<seb128> a bit warm in the afternoon to my taste
<dholbach> but I very much look forward to India :)
<seb128> but otherwise lot of typical places, sunny weather, GUADEC is great
<seb128> and nice to see everybody there again
<dholbach> seb128: does mvo get any vegetarian food? :)
<seb128> he seems to be happy so far
<seb128> we had to go to several restaurants to find something good for him but we managed
<dholbach> seb128: talking about vegetarians always reminds me of this one Tintin comic where Captain Haddock uses "Vegetarian" as an insult :-)
<seb128> dholbach: mvo sends you a hug
<seb128> ;-)
<dholbach> hug him back for me :)
<dholbach> http://www3.sympatico.ca/brooksdr/haddock/main.htm :-)
<liw> dholbach, is there a word of more than three syllables that Haddock didn't use as an insult? :)
<ion_> Billions of blistering barnacles!
<seb128> hey
<seb128> is there any known intel issue on intrepid?
<seb128> the user gets an error about dri2 which couldn't be loaded
<seb128> and then a stacktrace
<seb128> X and then libfb.so
<seb128> and then libexa.so
<seb128> let's try XAA
<pitti> seb128: dist-upgrade harder :)
<bryce> dri2 is not enabled yet due to lack of memory manager in libdrm
<pitti> seb128: I had the same yesterday (I think, anyway), X.org crashed
<seb128> pitti: tricky to connect to wireless network using only command line tools
<pitti> seb128: do you have 2:2.3.2-2ubuntu2?
<seb128> pitti: not sure but he switched to XAA and that works, I guess he will upgrade next
<tjaalton> the error is cosmetic
<tjaalton> um, the DRI2 error..
<seb128> alright
<seb128> thanks guys, have to go now, see you later
<tjaalton> it's already fixed upstream so that it won't complain if the xserver is built without dri2
<tjaalton> ie. it won't try to load it
* slangasek changed the topic of #ubuntu-devel to: soft freeze for intrepid alpha-2 | 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
<asac_the_3rd> ArneGoetje, i saw that the new language pack export is there. did you already upload new langpacks to PPA that i can test or should i do my QA on the langpack tarball?
<pitti> asac: you can use the PPA; they get new packages as soon as Rosetta exports them
<pitti> asac: theoretically it should have built new ones last night
<undef> hello
<ArneGoetje> pitti: for hardy the cronjob runs on thursday and sunday
<pitti> 0 2 * * 3,0
<pitti> doesn't that mean 2am on Sunday and Wednesdays?
<ArneGoetje> pitti: oh, sorry... :)
<siretart> slangasek: I have a new xine-lib upload ready (new upstream version, but no so-bump) that contains 2 security issues. I assume that security fixes do not qualify to break the freeze, is that right?
<slangasek> siretart: if they're severe security issues, I think it probably should break the freeze
<siretart> they are LP: #235904 and LP: #218652
<siretart> bug #235904 and bug #218652
<slangasek> it's 2am, you won't get a very good analysis from me of whether they're severe, sorry :)
<ubottu> Launchpad bug 235904 in xine-lib "[CVE-2008-1878] Inadequate bounds checking in the NES Sound Format (NSF) demuxer" [Undecided,Fix committed] https://launchpad.net/bugs/235904
<ubottu> Launchpad bug 218652 in xine-lib "CVE-2008-1686: Multiple speex implementations insufficient boundary checks" [Undecided,In progress] https://launchpad.net/bugs/218652
<siretart> okay. then I'll stay better on the safe way and wait until the alpha-2 release
<asac> pitti: somehow the langpacks from last night didnt update the mozilla.tar.gz
<asac> at least looking at install.rdf suggests that its not from the new tarball
<pitti> what's the version?
<asac> pitti: oh sorry
 * pitti looks at the logs
<asac> let me check something else
<pitti> asac: hm, the log looks good
<cjwatson> woo! live CD built, even if it's 80MB oversized. now I can stand a chance of debugging ubiquity
<pitti> 80!
<pitti> cjwatson: ah, due to recommends, I suppose?
<asac> pitti: do you still have the the sources lying on rookery or somewhere?
<asac> especially the unpacked translation dir?
<pitti> asac: yes, they are always there, /srv/language-packs.ubuntu.com/hardy-proposed/
<pitti> those are the language-pack-* source packages unpacked
<pitti> asac: which translation dir?
<asac> pitti: yes, but where is the unpacked translation tarball you used?
<pitti> asac: I don't keep that, I remove it after processing
<pitti> just download it again on rookery if you need it, it's fast
<asac> pitti: i have the one here locally
<asac> pitti: its just that the install.rdf in the mozilla.tar.gz is still the old one ... which i cannot find anywhere in the new tarball :(
<asac> e.g. the tarball i locally downloaded has <maxVersion>1.9.0.*</maxVersion>
<asac> but the langpacks in PPA have 1.9
<asac> let me check the sources you pointed me too ... not that i grabbed the wrong ones from ppa
 * asac runs xpi processor manually on rookery
<cjwatson> pitti: yes
<cjwatson> (almost certainly)
<ogra> cjwatson, so, i set the compcache spec to imlemented ... the initramfs chages landed yesterday night, what value would you suggest to use for the start ? (i think we should start to use it on the liveCD asap to determine the best value for it there)
<ogra> *implemeted even
<asac> pitti: i have the feeling that you didnt use the latest update tarball
<asac> pitti: the result are good here
<asac> https://translations.edge.launchpad.net/ubuntu/hardy/+language-packs
<asac> which one did you pull?
<asac> Delta language pack:  2008-07-08 23:01:42 CEST
<pitti> I always wget https://translations.launchpad.net/ubuntu/hardy/+latest-delta-language-pack
<asac> pitti: look at the page
<asac> maybe its broken?
<asac> under current language packs
<asac> there is Delta pack: none yet
<pitti> 1:8.04+20080705
<asac> hmm ... no the one i get through that url is good
<pitti> hm, that's indeed not the most current one
<asac> strange
<pitti> seems that +latest-delta-language-pack gave me the second-latest :-(
<asac> the latest url redirects to:
<asac> https://launchpadlibrarian.net/15901351/ubuntu-hardy-translations-update.tar.gz
<asac> the direct link gives:
<asac> http://launchpadlibrarian.net/15901351/ubuntu-hardy-translations-update.tar.gz
<pitti> that seems correct
<asac> thats the same .... maybe a delay?
<pitti> apparently not so at 2 am
<asac> yeah ok.
<lool> Is someone from the intrepid alpha 2 release team up?
<asac> pitti: let me blacklist a few more before you rerun ;) ... let you know in a few minutes
<pitti> lool: please just toss concrete questions to slangasek and me
<lool> xkeyboard-config's upstream prepared a patch for LP #246834 and wants me to try to get it in alpha 2
<ubottu> Launchpad bug 246834 in xkeyboard-config "No support for for Mac-like keyboard layouts with extra characters" [Undecided,Fix committed] https://launchpad.net/bugs/246834
<lool> pitti: Wasn't sure whom to ping at this time of the day
<pitti> asac: ok, I was just about to rerun; standing by then
<lool> pitti: Upstream says the attached debdiff is safe as it only adds a new keyboard implementation behind a mode which was already defined anyway
<lool> And pushes to try to get the fix in alpha 2
<lool> I don't think it should affect anyone, but since we're in soft freeze, I'm checking whether it's reasonnable to upload
<pitti> lool: looks ok to me
<lool> Ok, will push
<ogra> why oh why dont we have an upstream bzr branch anywhere for initramfs-tools (or am i just blind)
<asac> pitti: ok. i think the blacklisting is good now. its amazing how many new translations have been started :)
<asac> pitti: i am doing one test run here now and let you know
<pitti> ArneGoetje: the builds should have been settled now, so call for testing can go out
<cjwatson> ogra: http://code.google.com/p/compcache/wiki/CompilingAndUsing says "default size of 25%" so how about that?
<cjwatson> ogra: I agree it's a good idea to start using it as soon as possible
<ogra> cjwatson, well, 256M + 25% = 320M ... does that sound like it suffices ?
 * ogra doesnt know the current ubiquity reqs
<ion_> Thatâs not what the 25% means.
<ogra> its adding 64M swap, no ?
<ogra> at least it does that here using the default
<ion_> Say, it happens to compress whatever pages are swapped to the compcache with a ratio of 2:1. In that case, a full compcache of 64 MiB has allocated 32 MiB of RAM. Thus, youâve gained 32 MiB of extra capacity.
<cjwatson> ogra: bear in mind that ubiquity currently starts up with no swap; it surely won't make it worse :)
<ogra> yeah, indeed its a matter of data and compression rate
<lool> Hmm I can't branch casper
 * cjwatson tries to find the bugs that have been filed on the subject
<lool> On hardy I get: KnitCorrupt: Knit 9e/x_%254datt_%255aimmerman_%253cmatt.zimmerman%40canonical.com%253e_%2553un_%254dar_13_00%253a51%253a19_2005_1366.38 corrupt: line-delta from stream for version mdz@mizar-20051205230117-c327e75be767f237 references missing parent Arch-1:matt.zimmerman@canonical.com--2004%casper--main--0--patch-21
<ion_> On a swapless system, you might even consider something like 100% or 150%.
<lool> I guess I can check it out instead
<ogra> ion_, but with the default i geta 64M swap device on a 256M system here ...
<cjwatson> lool: I think I've seen that before, but not been able to solve it. Could you ask the bzr guys for help as to what we should do?
<lool> Sure
<cjwatson> ogra: bug 193552 suggests cache size of 128000
<ubottu> Launchpad bug 193552 in ubiquity "Support 256MB machines in Ubiquity." [Undecided,Confirmed] https://launchpad.net/bugs/193552
<ogra> ok
<ogra> lets start with that  ...
<cjwatson> I'm reassigning that bug over to livecd-rootfs for now, but maybe it's casper?
<cjwatson> I guess it should be casper, re-reassigned
<ogra> nah, livecd-rootfs should create te conf.d file
<ion_> conf-hooks.d file, i think
<ogra> nope
<cjwatson> ogra: you sure? I don't like having too much stuff in livecd-rootfs
<ion_> Judging from comments in mkinitramfs
<ogra> /usr/share/initramfs-tools/conf.d/
<cjwatson> why not have casper output that?
<ogra> because you need to regenerate the initramfs for it to take effect
<ion_> conf.d: for boot scripts, they land on initramfs. Deprecated for hook config.
<ion_> conf-hooks.d: for, well, hooks :-)
<asac> pitti: ok ... please rerun
<cjwatson> ogra: which casper does
<pitti> asac: started
<ogra> ion_, we made it a initramfs.conf option ... the system dir for the overrides is /usr/share/initramfs-tools/conf.d/ (the admin override dir would be /etc/initramfs-tools/conf.d/)
<ion_> ogra: mkinitramfs sources all of /e/i/conf.d, /u/s/i/conf.d and /u/s/i/hooks-conf.d. Please see the comments in mkinitramfs.
<ion_> It seems very clear to me that youâre supposed to use hooks-conf.d for something that a hook uses, not a script.
<ogra> ion_, well, i will stick to the implementaition :)
<ogra> which currently uses initramfs.conf
<ogra> lets not make it extra complicated :)
<ion_> Huh?
<ion_> Youâre supposed to override initramfs.conf options affecting hooks in hooks-conf.d and ones affecting scripts in conf.d. As simple as that. :-)
<ogra> the feature is documented in intramfs.conf
<ogra> the override dirs for that file apply
<ion_> The manpage seems to be out of sync with the implementation.
<ogra> we made it a global var so lets use the global config
<ogra> (hooks-conf.d would come into play if you wouldnt have the export i think)
<ion_> Both are sourced by mkinitramfs the same way currently, but hooks-conf.d files arenât copied to initramfs because they only affect hooks.
<ion_> If you use conf.d, you just end up with an unnecessary file in the initramfs.
<ion_> Otherwise the behavior is exactly the same.
<ogra> i dont end up with an unnecessary file
<ogra> if that file is there i *use* compcache ...
<ogra> if its missing i dont
<ion_> If the file overrides COMPCACHE_SIZE, itâs unnecessary in initramfs.
<ogra> very easy
<ogra> COMPCACHE_SIZE in initramfs.conf is only for manual user edits and for doumentation ... no tool or imagebuilder we use will modify it directly
<ion_> None of the files installed to the initramfs by the hook use COMPCACHE_SIZE.
<ogra> a tool creating an image is supposed to drop a one liner file into one of the conf.d dirs that just contains COMPCACHE_SIZE with a value
<ion_> No, hooks-conf.d :-)
<ogra> ion_, feel free to use hooks-conf.d in compcache-setup
<ion_> I am.
<ogra> fine with me :)
<ArneGoetje> pitti: already went out
<pitti> nice, thanks
<ion_> Iâm just pointing out that if you donât, you just end up using a deprecated feature and having an extra, unneeded file in the initramfs.
<ogra> ion_, i dont
<ogra> the file is needed if i want to use compcache ... it wont exist if i dont want to use compcache
<ogra> so there is no unneeded file
<ion_> You put conf.d/foo which contains âCOMPCACHE_SIZE=...â into initramfs. NOTHING within the initramfs uses that variable.
<ogra> the compcache hook does as soon as the initramfs is regenerated
<ion_> The hook uses it outside initramfs while creating an initramfs.
<ogra> which is done by either the image build tool or in liveCD case by casper at package install time
<ion_> The hook is not installed to the initramfs, or called from within the initramfs.
<ogra> it is if the var is set
<ogra> as soon as you regen the image with it
<ogra> which is exactly what we do
<ogra> casper will drop the conf.d file in place and run update-initramfs
<ogra> after that compcache is used
<ogra> cjwatson, i actually prefer livecd-rootfs simply due to the fact that UME or UNR might use it but not use casper, so we have a guaranteed central place o set it up
<ogra> s/o/to/
<ogra> for all kind of imagebuilds we do
<ion_> update-initramfs calls mkinitramfs, which sources initramfs.conf, conf.d and hooks-conf.d, all of these from the *filesystem*, not *initramfs* and then runs the hooks. The compcache hook parses COMPCACHE_SIZE and installs a script to initramfs that loads the compcache module with a precomputed kilobyte amount. That script doesnât use COMPCACHE_SIZE, this installing the conf file to initramfs is useless. Whenever update-initramfs is called, the compcache ...
<ion_> ... hook gets COMPCACHE_SIZE from the normal filesystem, not from within the initramfs. I donât know how to put this any clearer: thereâs absolutely no need to install the conf.d file to the initramfs, and putting the COMPCACHE_SIZE to conf.d instead of hooks-conf.d is deprecated, as the comments within mkinitramfs clearly say.
<ion_> A future version of mkinitramfs might very well stop sourcing conf.d
<ogra> ion_, all scripts we use i have ever seen use conf.d for consistency i want to eep it there it doesnt make *any* difference where the file is as long as the var is there during update-initramfs
<ogra> ion_, we are upstream of initramfs-tols
<ogra> *tools
<cjwatson> ogra: it's still the wrong place, I'm afraid; livecd-rootfs should do as few things as possible itself - it's just supposed to copy all the bits in place and do the minimum necessary tweaks
<cjwatson> ogra: we *were* upstream of initramfs-tools, but that is not realistically the case any longer
<ogra> cjwatson, hmm, k
<ogra> cjwatson, so who is ... Keybuk is stating that every time i talk to him and advised me often to give that as answer to debian people
<cjwatson> functionally, Debian is the upstream
<ogra> ok
 * ogra makes a mental note about that :)
<cjwatson> this is clear from the current changelog
<cjwatson> I have no problem with us making our historical contributions to initramfs-tools prominent, but we don't gain anything by claiming we're doing something we aren't
<ion_> âAdd /usr/share/initramfs-tools/conf-hooks.d for hook options on mkinitramfs run. Do not land in initramfs.â maks@debian.org in initramfs-tools 0.91
<ion_> mkinitramfs: # FIXME: deprecated those settings on mkinitramfs run
<ion_> #        these conf dirs are for boot scripts and land on initramfs
<ogra> ion_, as long as both works i really dont care but i want to keep consistency with othe scripts (ltsp drops the config into conf.d as i belive other netboot setups do as well)
<ion_> Theyâre obviously intending to *fix* sourcing conf.d within mkinitramfs. :-)
<ion_> When they do, everything that drops settings for *hooks* to conf.d breaks.
<ogra> they dont atm, right ?
<ion_> At the moment, conf.d are still sourced in mkinitramfs.
<ogra> right
<ion_> To future-proof the files, better move them to conf-hooks.d
<ogra> if they drop that and we merge that we will have more to fix
<ogra> cjwatson, sorry i tend to look at the wrong changelog ... the curse of being stuck on hardy :/ i see what you mean looking at intrepid ...
<lool> cjwatson: #246880 and http://launchpadlibrarian.net/15905205/bzr.txt for the log of the IRC conversation trying to recover this branch; didn't succeed sadly
<lool> cjwatson: If you need access to the bzr tree, you might be able to work on it using alioth's bzr
<lool> I prefer not touching it though
<lool> I only had a trivial typo to fix which doesn't solve any real life bug
<cjwatson> lool: no, I've already got it and it works fine for me
<cjwatson> though I think that might be a checkout
<cjwatson> lool: sorry, I see I implied that it was preventing me from working on it - it isn't
<cjwatson> lool: a checkout works just fine
<cjwatson> lool: any reason why you would ever not want to use a checkout for it? I hardly ever use real branches of trunk-type things on bazaar.launchpad.net
<lool> cjwatson: I almost always branch things from LP
<cjwatson> why?
<cjwatson> that just means you have to remember to push :)
<lool> It allows me to act consistently from all my bzr repos
<pitti> cjwatson: interesting; I almost never use checkouts
<lool> I simply never think "is this a checkout or a branch?" I always act on them like it's a branch
<cjwatson> checkouts are brilliant, I use them all the time
<lool> I know I have to push and pull
<cjwatson> when I create a branch, I try to push it somewhere and bind it as soon as possible
 * TheMuso prefers branching, in the event he has to uncommit/revert a revision./
<cjwatson> thereby turning it into a checkout
<Mithrandir> thekorn: you can uncommit from checkouts too
<lool> Yeah, I also tend to do "commit commit commit test push"
<pitti> I like the speed of local branches, and the possibility to uncommit without punishment, as well as saying "this becomes real work now, let's redeclare this as a branch"
<lool> Not "test commit test commit"
<TheMuso> Mithrandir: Right, wasn't aware of that.
<cjwatson> I've been annoyed too many times by "other developer forgot to push"
<cjwatson> so I intentionally structure my workflow to avoid even accidentally inflicting that on others, as far as possible
<lool> Perhaps that's something to solve at the "building a package which has a .bzr" level?
<lool> For instance we could check whether the current tree is a .bzr, whether it's bound or not, and if not whether it's up-to-date
<siretart> lool: do you know an example package that creates several binary packages, some of them containing shared libs and each of them has a seperate shlibs file? (and preferably uses debhelper)
<lool> siretart: Don't use .shlibs file, simply call dh_makeshlibs with -V on each package
<ogra> cjwatson, how do you uncommit in such a setup ?
<lool> (don't use -V alone of course)
<siretart> you mean like: `for p in ${packages; do dh_makeshlibs -p${p} ....; done`?
 * ogra os a typo prone person and likes to be able to roll back changelog entries to fix a typo ...
<ogra> :)
<ogra> s/os/is/
<lool> siretart: Something like this, yes
<cjwatson> ogra: (a) test and diff carefully before commit so I generally don't have to (b) if it's quick, hope that nobody happened to have pulled/updated in the few seconds between commit and "oh shit" (c) you can always just commit a correction
<cjwatson> but (a) is the most important. Apply care!
<lool> siretart: If it's for ffmpeg, you need separate calls as the binary package names are not standard and differ per binary package name you act on
<ogra> i do for the code ... but often dont for the commit entry
<cjwatson> if you know you're typo-prone, that's the first step
<lool> IOW it's not a shlib dep on the current package
<cjwatson> also I use debcommit so I generally write commit text in debian/changelog, not in bzr ci -m
<siretart> lool: okay. I'm just reading dh_makeshlibs, and I wanted to check if my conclusions are right. thanks
<pitti> I just often seem to recognize too late that I shuold have started a feature branch instead of doing large work in trunk
<ogra> pitti, same here
<ogra> but as you say then its to late anyway ... do better next time :)
<pitti> yeah, debcommit FTW
<siretart> (and yes, of course it is ffmpeg ;)
<lool> Makes me think that another reason I use branches is to allow me to bzr branch the tip which I might not have commit access to or might not want to commit to, then push to my own lp:~lool namespace and tell someone to pull from it
<lool> siretart: The last dh_makeshlibs example is the one you want
<lool>        dh_makeshlibs -V âlibfoobar1 (>= 1.0)â
<lool> Wow I just tried to work from a bzr lightweight checkout and even bzr diff required network UI
<lool> *IO
<lool> debcommit -n will hence also wait for IO
<cjwatson> oh, I don't use *lightweight* checkouts
<cjwatson> that seems like excessive self-inflicted-pain in most cases
<lool> I can't checkout casper in any other way sadly
<lool> You might be luckily reusing an older checkout you had around
<cjwatson> yes, I've had this for years
<cjwatson> right, intrepid desktop fails to boot. /me cracks knuckles and dives in
<pitti> cjwatson: shot in the dark> current kernel doesn't ship unionfs, might that be it?
<cjwatson> nothing to do with unionfs afaics
 * pitti crawls back into his hole then
<tjaalton> pitti: about nvidia; how should the latest "current" nvidia-glx-xxx be upgraded to nvidia-glx-{xxx+N}?
<tjaalton> by apt I mean
<pitti> tjaalton: I thought we didn't want to ship arbitrary names any mroe?
<tjaalton> pitti: they have versions now (-71, -96, -173, -177)
<pitti> i. e. once you install a version, you stay wit it?
<tjaalton> but shouldn't the latest one be just 'nvidia-glx' then?
<pitti> tjaalton: right, but wasn't the precise idea of those to avoid automatically upgrading to newer versions?
<tjaalton> pitti: ah, ok. maybe :)
<ogra> pitti, cjwatson err, didnt we switch to aufs anyway ?
<cjwatson> ogra: yes.
<cjwatson> (hence why unionfs is not important)
<tjaalton> pitti: it would make sense for the "legacy" versions, but for those who want the latest..
<ogra> good ... i was worried i had misunderstood :)
<cjwatson> in any case debugging without seeing the errors is a bit of a mug's game :)
<pitti> tjaalton: well, if something like this still makes sense, I see those options: (1) build a -latest metapackage, (2) if N+1 is compatible, just keep the package name (slightly confusing, I know), or (3) call the latest version "-latest" instead of -VERSION
<pitti> tjaalton: but since upstream keeps breaking compatibility, users shouldn't *want* to always get the latest, no?
<pitti> tjaalton: however, I do see that we need some mechanism to deprecate a particualr version; we can't maintain all of them forever
<pitti> tjaalton: I think that's where the update-manager hook kicks in (or the debconf note for those using apt-get)
<pitti> tjaalton: this suspiciously reminds me about the PackageSeries: discussion I had for kernel modules... (https://wiki.ubuntu.com/DesktopTeam/Specs/KernelAbiPackageHandling)
<tjaalton> pitti: the only problem I see with not having VERSION in the latest package is that the libs and modules could get out of sync. but, that's solved by dkms right?
<tjaalton> since it builds the modules for all the kernels the users happens to have
<tjaalton> it's just that on upgrade the user has to be notified that a reboot is in order
<tjaalton> and these are mainly issues during development
<ogra> http://bazaar.launchpad.net/~ubuntu-core-dev/casper/trunk/annotate/519?file_id=x_Matt_Zimmerman_<matt.zimmerman%40canonical.com>_Sun_Mar_13_00%3A51%3A19_2005_1366.40
<cjwatson> pitti: can we make it Kernel-Version instead? that's already in use for udebs
 * ogra scratches head
<ogra> (thats what i get clicking casper.init in the web UI on the casper LP branch)
<ogra> hmm, the same for the whole caspermon subdir ...
<ogra> i wonder if thats a branch issue or LP bug
<cjwatson> the branch is dodgy, see lool's problems above
<ogra> ah, k ... was on my way to #launchpad already :)
 * ogra ponders how to add compcahe to casper ... we surely dont want it on all casper sessions by default 
<ogra> (which would indeed be the easy task)
<cjwatson> ogra: I'd have thought it should depend on the amount of system memory somehow
<cjwatson> if you have 1GB, you probably don't want it
<stgraber> ogra: what about something like: amount of memory RAM+SWAP must be = 512MB for the Live environement. Then use compcache to achieve that (if possible)
<ogra> stgraber, compcache in intramfs as we implemented it is en/disabled at initramfs generation ... if you disable it we dont want any traces of it in the initramfs to save space ... so i need to enable it by default and dynamically set or unset the var in an extra script ...
<ogra> i'm wondering about the extra script atm :)
<ogra> i know what to do in there  :)
<ogra> the prob is that we need compcache as early as possible (init-top) so the casper detection has to happen before init-top ... casper itself only starts at premount to process scripts ...
<ion_> Btw, since udev currently starts at premount, thatâs when compcache actually gets running. udev could be moved to an earlier state, or anything in premount that requires compcache to be running could just prereq udev.
<cjwatson> there is nothing to stop casper installing an init-top script
<ogra> i think as soon as udev is run by upstart that will change
<cjwatson> and it seems to make complete sense to me to have casper do this in init-top, since it's fiddling with initramfs configuration
<ogra> cjwatson, apart from my resistance to add so much code :)
<ogra> i dont want to add bloat ;)
<cjwatson> this isn't bloat
<cjwatson> and it should be very little code
<ogra> ion_, ouch, we need a sequence number for the init-top script
<ogra> its currently just called compcache ....
 * ogra goes fixing and makes that 20compcache
<ion_> ogra: Huh? zcat /boot/initrd.img-2.6.26-3-generic | cpio -t | grep init-top doesnât print any number prefixes.
<ogra> cjwatson, well, my initial idea was a one liner :) compared to that everything is bloat ... but i didnt take dynamic detection into account for casper here
<ion_> I thought the prereqs functionality was used instead of a static ordering.
<ogra> ion_, look at casper :)
<cjwatson> ogra: more relevantly, look at /usr/share/initramfs-tools/scripts/init-top/
<ogra> we'll add init-top as dir to it and have a 10compcache_detect or so .,..
<cjwatson> -> no sequence numbers
<cjwatson> at some point initramfs-tools might change upstream to require that, but it's not there yet
<ogra> ah, k
<cjwatson> better to be consistent within the directory than consistent with other directories
<ogra> well, casper uses it all over the place
<lamont> and it doesn't do sequence numbers because it actually does dependencies, and doens't need them
<lamont> (them == sequence numbers)
<cjwatson> ogra: in its own directories; but it shouldn't do so in init-top, right now
<ogra> right ... still, we have them everywhere in casper ... seems sane to me to follow the general plot ... and if only for better readability
<cjwatson> I don't know how to make this any more clear
<cjwatson> follow the existing practice for init-top
<cjwatson> not for scripts/casper-*
<ogra> ok
<cjwatson> you don't want to mix two different means of resolving ordering within the one directory
<cjwatson> that way lies utter madness
<ion_> Seems to me that if the sh running the initramfs code *happens* to return the entires in a numerical order on init-top/* and the dependency ordering doesnât *happen* to shuffle their order either, youâre lucky that day. :-)
 * ogra sighs ... thats making it a lot more complicated :/ the compcache scrit wnt know anything about casper ... 
<ogra> so we need to dynamically create the PREREQ line
<ogra> during initramfs build :(
<ion_> Are you going to move udev to init-top, btw?
<ogra> udev will move to upstart soon as i understood scott
<ion_> Alright, it will be awesome if we already have upstart-in-initramfs for intrepid.
<ion_> âll
<ogra> thats the plan ...
<ogra> i also think in casper its not overly important to have it as early as on 48M systems ... since our main obective is to make room for the desktop session so whenever udev runs in initramfs wil be fine for a start
<ogra> it will get more important on 32M ltsp clients or other devices on teh edge with low ram etc ... where you actually require it for booting
<tjaalton> pitti: would it be ok to fix the intel problems with compiz for alpha2?
<tjaalton> pitti: a patch for mesa & intel
<doko> is there a reliable way to add/remove a slave link to an alternative with changing the default for the alternative itself?
<tjaalton> pitti: sorry, only mesa should be changed. there's also bug 246835 which means that one patch against intel should/could be dropped
<ubottu> Launchpad bug 246835 in xserver-xorg-video-intel "Check pitch patch should be removed, done differently in upstream source already" [Undecided,New] https://launchpad.net/bugs/246835
<cjwatson> soft freeze, so it's at your discretion
<tjaalton> cjwatson: ok, I think it's worth it. thanks
<sja> hello, all! may be its offtop. exists driver for webcam logitech eye312 ? thanx
<azeem> sja: please ask in #ubuntu
<sja> azeem, its no real :) 1312 members... okey
<sja> please, say who i can install driver PATA for Geode AMD. my sysmet is not bootable.
<Pici> sja: This channel is for development, not for support, please ask in #ubuntu, thanks.
<cjwatson> we don't ship drivers in separate packages (at least mostly, and certainly not in this kind of case) - if it's not shipped as part of the kernel, it's a kernel bug
<cjwatson> sigh
<bluefoxicy> BenC:  ping, are you ben collins?
<bluefoxicy> https://blueprints.launchpad.net/ubuntu/intrepid  <-- shows compcache as 'implemented' and compcache-usage as 'Drafting', yet both seem to describe the usage of compcache ... ?
<BenC> bluefoxicy: heh, yes
<BenC> bluefoxicy: Well, compcache is in the kernel now, but I'm not sure if it's being used on the CD yet
<ogra> BenC, i'm just fixing the intiramfs scripts
<ogra> bluefoxicy, ^^^
<ogra> a patch to use compcache according to the spec landed yesterday
<pitti> tjaalton: hm, how intrusive is it? if you tested it on an intel and perhaps an nvidia card and it works, I'm fine with it
<tjaalton> pitti: actually it proved to be harder than I thought so it'll have to wait a proper fix which means post-alpha2
<pitti> tjaalton: you still dropped the patch, so that was independent from the mesa fix?
<tjaalton> pitti: yes, that was independent
<pitti> infinity: rejecting your procps upload from hardy-proposed, there is no bug reference in the changelog
<ion_> benc: Whatâs the status of getting rid of versioned kernel packages, btw?
<cjwatson> I thought that was just the source packages, which are done
<ion_> I mean the last-known-boot thing.
<ion_> Uh, last-good-boot
 * dholbach couldn't boot any of the new kernels in KVM yet :-(
<dholbach> so I couldn't check out the new shiny feature yet
<stgraber> dholbach: just use real HW :) (or VirtualBox with i386 isos)
<dholbach> other than that I'm fairly happy with KVM :)
<BenC> ion_: after some testing of last-good-boot, hopefully within a few weeks
<ion_> benc: Neat
<ion_> benc: Is there going to be a mechanism that keeps the modules of the currently running kernel available until the next reboot even though the kernel image is upgraded?
<kirkland> slangasek: regarding the issue that you raised about the lsb-base status_of_proc() function not accounting for pidfiles, I have a new patch that addresses this.  i'd appreciate your review, when you get a chance.  see: https://bugs.edge.launchpad.net/ubuntu/+source/lsb/+bug/246735
<ubottu> Launchpad bug 246735 in lsb "status_of_proc() calls pidofproc() which calls kill, requiring ownership privileges on the process" [Medium,Fix released]
<pitti> dholbach: I'm accepting the kvm SRU for hardy right now (which claims to enable booting of .26)
<ion_> benc: Something like... have the kernel image package install the modules to /lib/modules/blah.new; have the postinst replace /lib/modules/blah with if the ABI matches and do nothing otherwise; have a very early init script move /lib/modules/blah.new over /lib/modules/blah if blah.new exists.
<dholbach> pitti: ah! :)
<pitti> dholbach: testing appreciated, please give feedback to bug 243677
<ubottu> Launchpad bug 243677 in kvm "intrepid kernel 2.6.26-2-generic (amd64) won't boot as kvm guest" [High,In progress] https://launchpad.net/bugs/243677
 * dholbach hugs pitti and soren
<dholbach> sure will
<dholbach> has it built already? has it built already? has it built already?
<pitti> dholbach: no! not yet! still no!
<BenC> ion_: that's something I haven't considered yet...on non-abi updates, that doesn't matter much, but for ABI bumps, it gets tricky
<ion_> benc: Or perhaps copy /lib/modules/blah to /lib/modules/current (with hardlinks) on startup and do something to make the system use /lib/modules/current from that point on.
<ion_> benc: Perhaps patch modprobe to try /lib/modules/current first and then fallback to /lib/modules/whatever-the-package-installs, and have an early init script rm -fr /lib/modules/current.temp, cp -al /lib/modules/whatever-the-package-installs /lib/modules/current.temp and bind-mount current.temp as current (to make sure a âcurrentâ of another kernel doesnât exist at /lib/modules/current at any time).
<ion_> benc: Iâm just throwing random ideas around as they come, there probably are much better solutions. :-)
<BenC> ion_: way to complicated, especially for lrm/third-party modules/dkms
<ion_> Yeah...
<ion_> benc: Perhaps have the package install the modules to /lib/modules/2.6.xx-ABIVER while making sure 2.6.xx-the_previous_ABIVER is not automatically deleted on upgrade, and have a maintenance script (an init script or a cron job) delete the older trees from /lib/modules that arenât running.
<ogra> ion_, so i have ade the code changes to the init-top script that it accepts a global COMPCACHE_PREREQ variable (that we can export from casper) for filing the prereq value and added a SKIP_COMPCACHE variable as well that makes the script die if nonzero ... since you seem to be good in finding out stuff and i'm out of ideas, any idea how to get the SKIP_COMPCACHE value handed over from one init-top script to the other ?
<ogra> s/ade/made/
<BenC> ion_: That's slightly complex too...and racey
<ogra> just exporting seems to be ignored
<ion_> ogra: Write it to a file and source it from the other scripts perhaps?
<ogra> uh, ugly
<ogra> but could work indeed :)
<ion_> Iâll hibernate. Have been awake for >22 hours. (Thatâs 66 millifortnights for our friends using the imperial units.)
 * ogra had a 3h nap in the last 48h :)
<ion_> Heh
<jdstrand> slangasek: maybe I missed it, but what is the mechanism to update the pam conffiles (in PAMConfigFrameworkSpec)?
<jdstrand> eg, pam-foo gets installed, drops its input file into /usr/share, then what?
<slangasek> kirkland: aiee, you sent me to edge and everything is mirrored! :)
<kirkland> slangasek: ?
<cjwatson> yeah, they flipped the UI around recently
<kirkland> slangasek: oh, hmm, sorry
<slangasek> kirkland: your url for the lsb bug; it's to edge, which I don't normally use, and I can't find anything in the UI :-)
<kirkland> i think i'm going to drop from launchpad-beta
<kirkland> it's a PITA to edit every LP url I paste every day
<cjwatson> I wonder if it's possible to write a firefox extension that munges the URLs on the way out
<kirkland> or, rather, the LP guys should have edge detect that you're not a member of launchpad-beta-testers and redirect to the normal site
<kirkland> bah
<jdstrand> slangasek: oh-- I did miss it: "...multiselect debconf interface, invoked by means of a script..."
<slangasek> jdstrand: ok :-)
 * slangasek backspaces over his explanation, since it's apparently a repeat :)
 * kirkland says adios to edge.launchpad.net
<jdstrand> slangasek: I might add that auth-client-config does a pretty good job of handling user changes. I don't know if that is something you'd like to use, or maybe look at the logic and see if there is something there for you to get inspired from
<slangasek> jdstrand: that sounds like it might be useful, thanks.  Though given the language constraints, I guess it'd have to be transcribed for use
 * jdstrand notes that the script of which slangasek speaks of is likely going to be pretty similar to auth-client-config
<jdstrand> slangasek: right
<jdstrand> slangasek: and why is python installed by default in Debian? you should *totally* work on that ;)
<jdstrand> s/is/isn't/
<slangasek> jdstrand: because perl is Enough? :)
<Tm_T> I thought dash is enough
<slangasek> ... ew?
<jdstrand> I used to be a perl addict, but I;ve seen the light
<slangasek> kirkland: well, if you're happy with returning 100 when the process exists and you can't kill it, then I'm happy too, though it seems to me that using ps would be a more robust solution for addressing your own concerns
<ogra> Amaranth, merci
<kirkland> slangasek: can you give me your suggested ps|grep line?
<Amaranth> ogra: you removed my tabs :(
<ogra> i did ?
<Amaranth> you changed it all to 4 spaces :P
<slangasek> kirkland: "ps `cat $pidfile` >/dev/null; echo $?" should do it, shouldn't it?
<kirkland> slangasek: and would you suggest that in addition to the kill check?
<ogra> Amaranth, yeah, thats how proper py code looks like :)
<kirkland> slangasek: in place of the grep for "Operation not permitted" ?
<slangasek> kirkland: that covers all the cases that kill -0 does, as well as the case where the process exists but isn't killable
<slangasek> kirkland: I would suggest that as a complete replacement for the kill -0 check; is there some reason kill -0 is useful?
<slangasek> i.e., something that it checks for that you can't check with ps?
<kirkland> slangasek: i'm not a fan of the kill -0, but i'm apprehensive about changing something so fundamental and pervasively used as pidofproc()
<slangasek> (the one caveat is that ps is in the procps package)
<cjwatson> tabs vs. 4 spaces> http://www.python.org/dev/peps/pep-0008/
<slangasek> right, then using kill -0 with ps as a fallback is probably safer
 * cjwatson wonders if that should be referenced from policy
<kirkland> slangasek: right <enter mumbly complaints about how much lsb sucks here>
<slangasek> heh
<Amaranth> cjwatson: 4 spaces is still evil :P
<liw> it's evil, but its' the RIGHT kind of evil
<kirkland> slangasek: i'll redraft the patch with the ps fall back
<kirkland> slangasek: it'll be a few minutes, as I'm otherwise occupied at the very moment
<cjwatson> consistency > *
<kirkland> slangasek: i'll pass it by your review again
<ogra> it should be the initial question at MOTU application reviews :)
<cjwatson> (yes yes hobgoblin of little minds etc.)
<liw> hobgoblins are cute
<slangasek> kirkland: it doesn't suck /generally/, just the "let's use redhat as a model for init scripts" part :)
<cjwatson> liw: yes, the little 'o' character is nice and rounded, and they're easy to kill
<savvas> why does debdiff always attach a /tmp/something/ path in the changelog diff?
<cjwatson> probably because that's where it unpacks them to diff, and it doesn't pass the right options to trim that off
<sistpoty|work> savvas: that iirc only happens for new upstream versions (or native packages), where there is no common base path
<savvas> bug? :)
<savvas> ah
<savvas> ok
<mdz> pitti: around?
<pitti> mdz: for another 5 minutes or so, yes
<mdz> pitti: I am trying to debug bug 246585, and the simplest way to do so seemed to be to use apport to gather a crash report (since the console and X were unusable for gdb)
<ubottu> Launchpad bug 246585 in xserver-xorg-video-vesa "GTK applications crashing reproducibly when using vesa" [Undecided,Incomplete] https://launchpad.net/bugs/246585
<mdz> pitti: but apport-retrace chokes on the .crash file because it is lacking a Package: field
<mdz> I don't see why it should be missing; it has a correct ExecutablePath which is clearly part of the gdm package
<pitti> mdz: right, Package:, Dependencies:, etc. are only added in the UI
<pitti> mdz: since they are expensive to generate (same like all the Gdb fields)
<mdz> pitti: I hand-hacked it back in.  do you expect the auto-retracer will accept it?
<mdz> pitti: I'd like to attach it to the existing bug report
<pitti> mdz: so either run apport-gtk -f /var/crash/... on it, or call apport-retrace manually with -R, --rebuild-package-info
<mdz> pitti: I'd rather just give it to the server to retrace, and not download all the debug symbols, if that will work
<pitti> mdz: ah, no apport retracers for intrepid yet, I'm afraid, and unfolding the blob to an existing bug isn't possible yet either (long-standing LP wishlist bug)
<mdz> pitti: oh, ok. I'll retrace locally then.  thanks
<pitti> ATM, p-lp-bugs is yet again broken with current LP, and I need to set up intrepid chroots
<pitti> it's a constant chase :/
<mdz> pitti: LP 2.0 is supposed to give us APIs to back p-lp-bugs...
<pitti> yeah, I'm craving for that :)
<savvas> when there are two packages listed in debian/control, do I have to add XSBC-Original-Maintainer twice?
<ogra> tere are surely not two source packages listed
<ogra> that field applies to the source package
<savvas> Package: htcheck
<savvas> Package: htcheck-php
<mdz> bryce: around?
<bryce> mdz, yep
<emgent> hello
<mdz> bryce: I've attached what you requested to 246585, though it only seems to get weirder
<bryce> ok looking
<mdz> bryce: I noticed along the way that X server crashes don't seem to trigger apport; is that intentional?  i thought it used to
<mdz> (this particular problem isn't an X server crash, but in the course of events it's crashed on me a few times in the past day)
<bryce> mdz: hrm, it *should* be triggering them.  Might be my own lack of apport-fu is making them not work
<sladen> come to think of it; I haven't had anything trigger apport for quite a while
<laga> sladen: are you on a stable release?
<Tm_T> hi sladen :)
<bryce> I recently in Intrepid changed how the xserver apport stuff is hooked up based on pitti's advice, but it may still not be right yet
<sladen> laga: ah, _this_ machine is
<laga> sladen: see /etc/default/apport
<laga> i need to enable it on my laptop because kded crashes frequently
<mdz> bryce: in which package does the magic live?
<mdz> ah, -core
<bryce> mdz, I stuck it in the xorg package, but am wondering if it needs to live in xorg-server
<mdz> bryce: I think it needs to be in the same package as the binary in order to be triggered
<bryce> mdz, that's what I suspected...  I'll try moving it over to xorg-server then
<bryce> I also need to investigate if we can get richer stacktraces when xserver crashes; currently what it puts into Xorg.0.log generally proves insufficient for troubleshooting
<mdz> bryce: I don't think the package hook is the problem; apport never gets invoked at all
<mdz> I assume it's because the X server is handling the signal itself
<mdz> though, it does rethrow it I guess, so it should work
<mdz> bryce: I've attached gnome-panel and gnome-terminal crash reports to the bug as well.  you should notice a pattern...
<mdz> they're all falling over in the course of inquiring about screen geometry
<bryce> ok
<mdz> apport should do a much better job of decoding the stack trace than the X server does
<mdz> if you let it do its thing
<bryce> mm, definitely an error in xrandr-ish stuff
<mdz> mako: dude
<bryce> if I were to guess at this point, I'd guess it to be that gdk's xrandr bindings are bugged
<mdz> bryce: re: X server crashes, /var/log/apport.log has this to say:
<mdz> ValueError: Invalid process ID: [Errno 2] No such file or directory: '/proc/21945'
<mdz> it seems the process has already exited before apport gets its paws on it
<jcristau> mdz: does gdk_screen_get_n_monitors() return 0?
<bryce> mdz, also attach your .xsession-errors.  Since it's looking like this might be somewhere in the gnome stack, that might have useful info
<ogra> haha
<mdz> jcristau: is there an easy way to get to that from PyGTK?
<ogra> if you find it in there at least
<mdz> bryce: there's nothing on stdout or stderr except what I already put in the bug
<Amaranth> .xsession-errors wouldn't be so bad if you didn't have 10 things writing to it at once
<Amaranth> everything kind of...merges
<Amaranth> "ok, here is the first line of compiz-manager output, where is the second? oh, i see it, 50 lines down..."
<mdz> jcristau: not sure if I'm using the API correctly, but:
<mdz> >>> gtk.gdk.Screen().get_n_monitors()
<mdz> __main__:1: Warning: invalid cast from `GdkScreen' to `GdkScreenX11'
<mdz> 1946711135
<Amaranth> that looks...bad
<mdz> it returns the same sort of random garbage when I try that on a working X server, though, so I don't think I'm asking the right question
<Amaranth> mdz: try gtk.gdk.screen_get_default().get_n_monitors()
<mdz> Amaranth: returns 0
<mdz> returns 1 on my healthy X server
<bryce> jcristau: from the panel_multiscreen_width() routine, it looks like it only reaches the line it crashes on if gdk_screen_get_number(screen) returns 0 or higher
<Amaranth> jcristau: ^
<jcristau> sounds like XineramaIsActive() or XineramaQueryScreens() bugginess
<Amaranth> that's as far as I can help from a mac
<jcristau> mdz: what's the output of xdpyinfo -ext XINERAMA?
<bryce> from the vesa Xorg.0.log:  (II) Initializing built-in extension XINERAMA
<mdz> jcristau: http://paste.ubuntu.com/26264/
<bryce> jcristau: is -vesa still set up to use xinerama?
<mdz> it prints output, but then the X server crashes
<mdz> number of screens:    1
<jcristau> bryce: vesa doesn't do xinerama, no. so XineramaIsActive() is supposed to return false. Xinerama is inactive.
<jcristau> .. in the xdpyinfo output suggests that it does
<mdz> xrandr --verbose: http://paste.ubuntu.com/26265/
<jcristau> the crash looks like a wacom bug
<mdz> the crash during server shutdown is presumably a separate issue
<mdz> I'll report it to LP
 * mdz starts using -noreset
<bryce> jcristau: why do you think it's related to wacom?
<bryce> jcristau: the wacom error messages that appear in Xorg.0.log have generally proven non-fatal with gnome
<jcristau> so if XineramaIsActive() returns false then i have no idea why gdk's get_n_monitors() doesn't return 1
<mdz> bryce: because it's crashing in 2: /usr/lib/xorg/modules/input//wacom_drv.so [0xb7b3c0fc]
<mdz> GTK seems to set n_monitors based on either XineramaQueryScreens or XRRGetScreenResources
<bryce> ah
<mdz> both of which seem to be behaving
<mdz> bryce: have you tried this yourself?
<bryce> mdz, no I haven't
<mdz> bryce: does vesa work on your hardware?  have a go
<bryce> ok I'll give it a shot
<tjaalton> it doesn't work on mine, and I don't have anything wacom related in the conf
<mdz> tjaalton: two separate issues, vesa and wacom
<tjaalton> mdz: oh, ok
<mdz> not too concerned about wacom right now, since the server is going down anyway at that point
<tjaalton> heh
<mdz> bryce: I'm using sudo -b X :1 -ac -noreset -config xorg.conf.test
<mdz> for convenience, though it definitely happens when it's the only X server running as well
<savvas> can someone take a look at the patches listed here: http://tinyurl.com/58dgl3
<savvas> or the huge link :) https://bugs.launchpad.net/~medigeek?field.searchtext=fixed+maintainer+debian+control+field&orderby=-datecreated
<mdz> savvas: the changelog says hardy, but should probably say intrepid
<savvas> darn, true
<geser> savvas: and subscribe ubuntu-universe-sponsors for packages in universe and ubuntu-main-sponsors for packages in main
<savvas> will do, have to run though, I'll change them to intrepid and subscribe the sponsors later :\
<bryce> rats, networking is busted on my dev box at the moment.  -vesa is working on it but it's running xserver 1.4
<bryce> (so I'll set up another box)
<mdz> bryce: what's wrong with the box you're on?
<sbeattie> slangasek: is there a reason the kubuntu-kde4 i386 alternate image is 403?
<sbeattie> slangasek: nevermind, brain not working today
<bryce> mdz, ah, it's the one I use for mail services and such and is still on hardy.
<mdz> bryce: so what are you using for testing your intrepid uploads? ;-)
<kirkland> slangasek: hey, sorry, got drawn away for longer than I expected.  Updated patch on https://bugs.edge.launchpad.net/ubuntu/+source/lsb/+bug/246735 using ps
<ubottu> Launchpad bug 246735 in lsb "status_of_proc() calls pidofproc() which calls kill, requiring ownership privileges on the process" [Medium,Fix released]
<kirkland> slangasek: mdz made the same suggestion ;-)
<bryce> mdz, long story, but basically last weekend I started some machine shuffling, and the machine I set up for testing currently has a network support issue (getting workaround from tim).
<slangasek> kirkland: my suggestion was not altogether independent of his :)
<kirkland> slangasek: :-D
<slangasek> kirkland: I guess I would expect that if you find the process with 'ps', you would still return 0, not 100
<slangasek> otherwise, why look with ps at all?
<kirkland> slangasek: hmm, well i didn't want to disturb pidofproc()'s non-zero return code in the kill -0 fails case
<slangasek> hum
<slangasek> I don't think pidofproc is documented as returning non-zero in the case you don't own the process, is it?
<kirkland> slangasek: i'm still treating this status gathering business as a special case, allowable as a non-owner/non-root user
<slangasek> if it's not a documented feature, sucks to be whoever assumed this was an ok way to check for ownership of the process :P
<kirkland> slangasek: good point.... if no pid file is found, and /bin/pidof runs, it doesn't check ownership either
<slangasek> right
 * kirkland programs conservatively and he gets smacked for it...  programs more liberally and gets smacked for it :-)
<kirkland> :-P
<slangasek> heh :)
<Mithrandir> kirkland: it's called "You can't win", aka the second law of thermodynamics.
<slangasek> Mithrandir: first law; the second law is "you can't break even" :)
<Mithrandir> slangasek: true.
<gp> hi
<gp> is there a vunerbaility in ubuntu 8.04 ?
<gp> all my systems in office started behaving strangely around 8 pm ist
<kirkland> slangasek: okay, patch updated at https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/246735
<ubottu> Launchpad bug 246735 in lsb "status_of_proc() calls pidofproc() which calls kill, requiring ownership privileges on the process" [Medium,Fix released]
<slangasek> gp: if you mean the initial release of Ubuntu 8.04, there are multiple vulnerabilities that have been fixed since the release via security updates; http://www.ubuntu.com/usn/ has a complete list
<geser> gp: can you be more verbose on "strangely"?
<slangasek> you should definitely be tracking the "important security updates", as they're called in the admin interface, for any Ubuntu release
<gp> they were in network and was able to ping each other but any services like ssh , ftp , databse server disconnected or timed out
<gp> machines were able to ping each other at very low lan latency
<gp> i thought there was problem with switch intially so replaced the switch
<gp> but again same problem
<gp> now stuff like ssh takes too much time
<gp> or time outs on all machines
<slangasek> well, you're the only one that I've heard reporting such a problem, I'm afraid.  If you haven't installed all of the security updates, it could very well be because of one of those.  If you have installed the security updates, it's likely to be a local problem (perhaps a DNS configuration problem?) since no one else is reporting it
<kirkland> slangasek: if you're satisfied with the latest version of that patch, could I trouble you for a sponsor/upload?
<kees> gp: there was a significant DNS update happening for all vendors yesterday and today.  it could be related, but as slangasek says, this is the first we've heard of anything like this.
<slangasek> kirkland: sure, I can do that
<gp> these are unpatched systems
<kirkland> slangasek: cool, after that happens, i'll send it over to Debian.  they accepted the last one (sans pidfile support) yesterday
<kees> gp: right, but other infrastructure may be getting updated was my point.
<mako> mdz: dude
<gp> maybe my office is under some attack ?
<savvas> attack of the Huns! :)
<gp> but i also tried to disconnect from router and but any service like ssh , db was taking to much time to connect
<gp> i did nmap scan
<gp> only ssh and db server port show one in namp
<gp> how to find if systems are hacked ?
<gp> my entire office is down
<gp> office which runs solely on ubuntu
<gp> and which i installed :-(
<gp> tomm if its now fixed I will be blamed
<Lrrr> gp: is there anything showing in logs?  You don't seem to have much informations about what is actually happening.
<gp> syslog?
<Lrrr> syslog, kernel log, whatever log...
<sbeattie> ssh delays tend to be DNS related.
<gp> i am using ip in lan
<gp> not by host name
<gp> even on local computer
<gp> if i ssh localhost its quite fast
<gp> but if i ssh my local computer by ip it takes lot of time
<Keybuk> it's because if you ssh to your IP, it first has to go all the way to your ISP and back
<Keybuk> no, I can't keep a straight face ;)
<Lrrr> gp: Please gather more informations than simple network delays.
<Keybuk> in reality, it's almost certainly that you don't have reverse DNS for your IP
<Keybuk> or that it doesn't match the forward
<Keybuk> or that your DNS resolver is slow
<kirkland> slangasek: http://pastebin.ubuntu.com/26288/
<kirkland> slangasek: that's the bug report + patch I'm sending to Debian
<gp> Lrrr: which info i should look for
<kirkland> slangasek: includes the patch as you've seen it, plus two minor diff's between Debian/Ubuntu lsb-base that I've dealt with before on merges
<kirkland> slangasek: should clean up our merge, which I'll do for intrepid again, as soon as he accepts this
<Lrrr> Keybuk has a good point there.
<slangasek> gp: as Keybuk says, a slow DNS resolution does perfectly explain slow ssh connections when connecting by IP, because the /server/ has to identify the client even if the client uses an IP when connecting to the server
<Mithrandir> providing network traces often shows this very clearly, if things take exactly 30s to time out for instance.
<gp> Mithrandir: u mean traceroute ?
<Mithrandir> no, I mean tcpdump/tshark logs
<gp> http://pastebin.ubuntu.com/26291/
<gp> i am sorry to disturb u guys with my problems
<gp> am i no security / network guru only developer
<gnomefreak> did we do away with gtksu/gtksudo?
<Lrrr> there seem to be a name resolution error there
<Mithrandir> gp: well, it doesn't look like any of your DNS servers are actually answering?
<gp> http://pastebin.ubuntu.com/26292/
<gnomefreak> sorry typo
<gp> when i dig yahoo.com it responds pretty quickly
<Mithrandir> gp: can you install moreutils and then pastebin the output of dig +trace err.no | ts ?
<slangasek> 2>&1 >/dev/null
<slangasek> kirkland: ^^ doesn't the above redirect the fds in the wrong order?
<Mithrandir> usually, yes.
<gp> http://pastebin.ubuntu.com/26294/
<kirkland> slangasek: i wrote/read that as "stderr to stdout, then stdout to /dev/null"
<slangasek> kirkland: so you meant for the stderr output to not be suppressed?
<kirkland> slangasek: i mean to suppress EVERYTHING
<Mithrandir> kirkland: then it's the wrong order.
<kirkland> slangasek: and only operate on the $?
<slangasek> kirkland: then that needs to be >/dev/null 2>&1
<slangasek> kirkland: because 2>&1 means "clone the current fd1 as fd2"
<slangasek> and if you do that before stdout is repointed at /dev/null, it's basically a no-op :)
<kirkland> wow, i've been screwing that up for years, then
<slangasek> I can fix that here if you're happy with that, no need for a patch reupload
<kirkland> please
<kirkland> slangasek: i'll update the patch I sent to Debian
<slangasek> ok
<kirkland> slangasek: thanks.
<gp> Mithrandir: http://pastebin.ubuntu.com/26294/ ->>> output of  dig +trace err.no | ts
<Mithrandir> gp: yeah, that looks nice and fast.
<slangasek> kirkland: hrrrm, status_of_proc() also still doesn't actually give you a way to *pass* a pidfile argument to pidofproc :)
<slangasek>  pidofproc $daemon  -- I need it to be able to call pidofproc -p $pidfile $daemon :)
<kirkland> slangasek: pidofproc() sort of autodetects that
<slangasek> hmm
<kirkland> slangasek: but i guess it would be good to explicitly state that
<gp> Mithrandir: why my ssh is slow in lan
<slangasek> well, for completeness it should be possible to override the autodetection
<gp> eralier it was instaneius
<kirkland> slangasek: actually, you're right, it's a problem with cron...  the daemon is /usr/sbin/cron, but the pid is /var/run/crond.pid
<slangasek> kirkland: right, not guaranteed to match :)
<kirkland> slangasek: k, i'll spin a new version
<gp> all services super slow in lan
<slangasek> kirkland: indeed, for samba the pid files are down a level, so my omgkittens use case isn't addressed by the current implementation :-)
<slangasek> kirkland: sorry for not catching this in earlier reviews, I guess I had tunnel vision
<kirkland> slangasek: no problem, i had thought about it, but figured i'd rely on pidofproc()'s autodetection (which in retrospect was poor)
 * kirkland has a habit of underestimating problems :-)
<kirkland> too optimistic, i suppose
<Mithrandir> that's a fairly common disease affecting programmers.
<Mithrandir> remember to multiply by Ï
<kirkland> slangasek: what did you think of mdz's suggestion of just removing the kill -0 statement and using ps exclusively?
<kirkland> slangasek: also, is this construct correct?  it's used elsewhere in that file:             elif ps "${pid:-}" 2> >/dev/null; then
<infinity> pitti: Sorry about the missing bug number, reuploaded with fixed changelog.
<kirkland> infinity: aw, admit it....  adding the bug number screwed up your fully justified changelog :-)
<infinity> kirkland: *cough*
<infinity> kirkland: No, I've just always been slack about Ubuntu bug numbers in changelogs, since I left the distro team before we finally got auto-closing of bugs in soyuz/malone.
<slangasek> kirkland: well, I commented to the bug that if we use ps exclusively, that sorta implies a dep on procps for the lsb-base package; that might be ok, I can't think of a specific reason right now that it wouldn't, but I think the idea should be shopped around more before committing to it
<Lrrr> gp: Can we speak in private?
<kirkland> slangasek: k, sounds good
<kirkland> slangasek: and about  ps "${pid:-}" 2> >/dev/null ?
<slangasek> kirkland: 2> >/dev/null is not correct.  2> /dev/null is ok (i.e., you're allowed to have a space between the operator and the arg), but incomplete
<Lrrr> Couldn't gp problem be related to mdns?
<slangasek> kirkland: >/dev/null 2>&1 is the traditional method
<kirkland> slangasek: okay.  in that case, there are issues elsewhere in that script
<slangasek> kirkland: in init-functions? they're eluding my gaze
<kirkland> slangasek: blah...meh.  sorry, i've gone crosseyed
<slangasek> mental note, Canonical USA needs to get a health plan that includes optical ;)
<kirkland> slangasek: +1!
<liw> also, bigger monitors so you can use bigger fonts
<Lrrr> gp: please, look at https://bugs.launchpad.net/ubuntu/+source/avahi/+bug/94940
<ubottu> Launchpad bug 94940 in avahi "mdns listed in nsswitch.conf causes excessive time  for dns lookups" [Undecided,Confirmed]
<kirkland> slangasek: try this one... http://pastebin.ubuntu.com/26298/
<kirkland> slangasek: i made pidfile an optional, 3rd parameter to status_of_proc()
<kirkland> slangasek: if it's found, i add a "-p $3" to the pidofproc() call
<slangasek> kirkland: the -p syntax would be more consistent with the interface of the other functions provided, so I think it would be better to have status_of_proc() support -p $pidfile the same way pidofproc does
<slangasek> kirkland: but I'd be happy to sponsor this revision, all the same
<kirkland> slangasek: i can make that change easily enough
<kirkland> slangasek: personally, i think "-p $pidfile" is kinda ugly
<kirkland> slangasek: i don't like mixing -param and positional parameters
<slangasek> 10:03 < cjwatson> consistency > *
<slangasek> :-)
<kirkland> slangasek: say the magic word and I'll go change it to use -p ....
 * liw would vote for everyone using GNU getopt (_long) option parsing...
<slangasek> kirkland: yes, please
<kirkland> slangasek: k...
<slangasek> kirkland: I'm off to lunch now anyway, which I need to squeeze in before the platform meeting
<kirkland> slangasek: i'll bug you shortly then....
<kirkland> slangasek: i'd like to put a nail in this coffin today, if possible
<slangasek> right :)
<kirkland> slangasek: https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/246735/comments/11
<ubottu> Launchpad bug 246735 in lsb "status_of_proc() calls pidofproc() which calls kill, requiring ownership privileges on the process" [Medium,Fix released]
<kirkland> slangasek: patch updated there, with pidfile support
<kirkland> slangasek: ping me when you come back around, review, and potentially commit
<kirkland> slangasek: I want to push the patch back to debian, but I'll refrain from spamming Debian's bts until we settle on something for ubuntu's lsb-base
<slangasek> mathiaz: "why use the dovecot implementation instead of cyrus" - because everyone hates the cyrus SASl implementation :)
<slangasek> I don't know to what extent this is inherent in sasl, and to what extent it's the result of cyrus's strange configuration semantics
<mathiaz> slangasek: right - OTOH dovecot sasl implementation is only supported by postfix and exim
<slangasek> mathiaz: right, and postfix doesn't even depend on it, it only depends on libsasl2-2
<mathiaz> slangasek: so from a practical pov, if we want to support SASL correctly cyrus implementation is the only option for the time being
<slangasek> I agree
<mathiaz> slangasek: another option would be to add support for dovecot to other services :)
<slangasek> I've never looked at the dovecot implementation myself, so I don't know whether that's really as great an idea as people make it out to be
<ScottK> For postfix it's definitely easier to configure correctly.
<lamont> I don't mind having postfix Suggest: either dovecot or cyrus...  Recommends? dunno.  Depends: no way
<ScottK> Since dovecot is our preferred delivery agent, it makes sense to focus on it for SASL too.
<ScottK> lamont: I'd say Suggests both.
<lamont> do they conflict?
<lamont> because suggesting two conflicting packages strikes me as kinda strange
<soren> ScottK: Suggest... both?
<soren> ScottK: Why would you want both dovecot and cyrus?
<ScottK> Suggest them alternatively.
<soren> Now, *that* makes sense.
<ScottK> dovecot|cyrus
<slangasek> lamont: postfix already depends: the cyrus sasl implementation, it's a shlibdep
<slangasek> we're discussing the SASL libs, not the POP servers :)
<lamont> ah, ok
<soren> Oh.
<slangasek> kirkland: latest patch looks good, should be uploaded shortly
<kirkland> slangasek: outstanding!
<lamont>  1  7 277680  57036   3968 942264    2    0 28688 24519 2487 14540 18 14 38 30
<lamont> scary vmstat output
<kirkland> slangasek: here's the caller patch for samba: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/247087
<ubottu> Launchpad bug 247087 in samba "samba init script status action" [Low,In progress]
<kirkland> slangasek: see how that guy looks to you
<slangasek> kirkland: hmm, there are some comments in the thread on the Debian bug that are probably relevant; i.e., it's not safe to assume that the status of "samba" as a whole is always dependent on the status of both nmbd and smbd, there are cases where one or the other is legitimately configured not to run
<kirkland> slangasek: your recommendation?
<slangasek> kirkland: present in that bug log; sorry, platform meeting just started now, split attention
<kirkland> slangasek: okay, i'll dig deeper
<slangasek> that's Debian bug #488275, if you don't have it to hand
<ubottu> Debian bug 488275 in samba "samba and winbind: initscript miss 'status' option" [Wishlist,Open] http://bugs.debian.org/488275
<kirkland> slangasek: thx
<kirkland> slangasek: see https://bugs.launchpad.net/debian/+source/samba/+bug/247087/comments/3
<ubottu> Launchpad bug 247087 in samba "samba init script status action" [Low,In progress]
<kirkland> slangasek: updated to test for $NMBD_DISABLED and $RUN_MODE
<kirkland> slangasek: is this sufficient, or are you thinking something more complex will be required?
 * kirkland recognizes that slangasek is active in #ubuntu-meeting at the moment ;-)
<slangasek> kirkland: hmm, what should the status be if 'disable netbios' is set *and* smbd is run out of inetd? :-)
<slangasek> (i.e., I think we need the default status to be 'undefined')
<kirkland> slangasek: which is what in sysv return codes?
<slangasek> sysv, or lsb?
<kirkland> slangasek: ah, good point.  lsb.
 * kirkland goes to the spec....
<Riddell> pitti: fancy looking to see if ew can get policykit-kde to do anything next week?
<kirkland> slangasek: according to http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html, 4="program or service status is unknown"
<slangasek> kirkland: sounds good to me :)
<slangasek> so yeah, lots of fun - the return code needs to be 4 if neither daemon is configured to run, 0 if at least one is configured to run and all those that are configured to run are running, otherwise whatever error status_of_proc returned
<kirkland> slangasek: i was drawing it on paper, actually :-P
<slangasek> :-)
<stgraber> erk, encrypted lvm seems to fail on current Intrepid alternate :(
<slangasek> bryce: well, everything past the 'milestone' column is lost screen real estate to me... it really would be nice to have those columns hidden, so that more rows can fit on a screen without wrapping
<cjwatson> stgraber: oh?
<ogra> stgraber, sure its not just slow ?
<slangasek> kirkland: I think the easiest is to just check the two vars at the end, and if we don't hit either case, set status=4
<kirkland> slangasek: right
<stgraber> big red screen, so not it's not just slow .)
<stgraber> doing manual partitioning with encryption + lvm
<stgraber> my usual advanced manual testcase :) boot + encrypted partition containing LVM with / and /home
<bryce> slangasek: ok, I can probably add a 'shrink columns' option.
<stgraber> standard: erase-disk + encrypted LVM worked though
<cjwatson> stgraber: can I get logs?
<stgraber> cjwatson: sure
<cjwatson> kees: you sure about closing Debian bug #403718? the 'if (int_value > 19) int_value = 19;' bit I saw still isn't accompanied by a similar bound-from-below
<ubottu> Debian bug 403718 in pam "pam: pam_limits fails to bound RLIMIT_NICE from below" [Normal,Closed] http://bugs.debian.org/403718
<cjwatson> am I missing something
<cjwatson> ?
<cjwatson> kees: oh, hmm, maybe I'm confused because debian/patches-applied/ in fact isn't
<cjwatson> yeah, I'm just confused. never mind me
<kees> cjwatson: heh, okay, no problemo.  Yeah, from the testing I did during the 0.99 updates a while back, that was all taken care of.
#ubuntu-devel 2008-07-10
<stgraber> cjwatson: http://www.stgraber.org/download/ubuntu/lvmcrypto/
<cjwatson> ta, looking
<cjwatson> "Mounted filesystem?", huh
<stgraber> What's weird is that in /dev/mapper I have : sda2_crypt and sda2_cryptp1
<stgraber> IIRC I never had things like _cryptp1 on Hardy and I don't really see what it's
<cjwatson> p1 sounds like something treating sda2_crypt as a disk-like block device with one partition
<cjwatson> parted has been known to make that kind of mistake in the past although I'm not sure whether it would be the thing creating the device node
<kirkland> slangasek: https://bugs.launchpad.net/debian/+source/samba/+bug/247087/comments/4
<ubottu> Launchpad bug 247087 in samba "samba init script status action" [Low,In progress]
<kirkland> slangasek: i think this is what you suggested
<slangasek> kirkland: I think what I meant was this:
<cjwatson> stgraber: not much to go on in the logs - I'll see if I can reproduce from your test case
<slangasek> +		status="0"
<slangasek> +		NMBD_DISABLED=`testparm -s --parameter-name='disable netbios' 2>/dev/null`
<slangasek> +		if [ "$NMBD_DISABLED" != 'Yes' ]; then
<slangasek> +			status_of_proc -p $NMBDPID /usr/sbin/nmbd nmbd || status=$?
<slangasek> +		fi
<slangasek> +		if [ "$RUN_MODE" != "inetd" ]; then
<slangasek> +			status_of_proc -p $SMBDPID /usr/sbin/smbd smbd || status=$?
<slangasek>  		fi
<slangasek> +		if [ "$NMBD_DISABLED" == 'Yes' -a "$RUN_MODE" == "inetd" ]; then
<slangasek> +			status="4"
<slangasek> +fi
<slangasek> kirkland: i.e., still only check each process if you're supposed to (otherwise status_of_proc will spit out a useless message, no?), and then set the status appropriately at the end if nothing's been done
<kirkland> slangasek: ah, okay, so keep the checks
<kirkland> slangasek: and conditionally override status=4, if deemed necessary
<slangasek> that's my thought
<slangasek> you're allowed to have different ones, of course :)
<kirkland> slangasek: that certainly makes sense
<cjwatson> ps [ == ] is a bashism
<slangasek> erk, yes :)
<kirkland> slangasek: i'm fixing that too
<slangasek> <-- tunnel vision again
<cjwatson> stgraber: so "physical volume for encryption" for sda2?
<stgraber> yes
<elmo> what's R550 support like in Hardy and/or Intrepid?
<stgraber> cjwatson: then use it as physical volume for LVM and it'll break when starting LVM configuration
<kirkland> slangasek: http://launchpadlibrarian.net/15925572/samba.status.debdiff
<kirkland> slangasek: or, rather: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/247087/comments/5
<ubottu> Launchpad bug 247087 in samba "samba init script status action" [Low,In progress]
<cjwatson> stgraber: it does indeed
<slangasek> kirkland: looks pretty good to me
<kirkland> slangasek: *pretty* good????
<kirkland> slangasek: :-)
<kirkland> slangasek: shall I send it to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=488275 as well?  (cleaning out the changelog bits, of course)?
<ubottu> Debian bug 488275 in samba "samba and winbind: initscript miss 'status' option" [Wishlist,Open]
<slangasek> kirkland: I see no bugs at all in the code - I'll give it a B+ ;)
<kirkland> slangasek: or shall I expect you to handle the Debian side of this?
<slangasek> kirkland: it would be helpful to me if you would also send it to the Debian side
<kirkland> slangasek: and what's it going to take to get it to an "A"?
<slangasek> I would /eventually/ handle it there as well, but it would take longer :)
<ion_> Cool, i have a time machine. Jul 10 02:27:20 heh dovecot: Time just moved backwards by 1 seconds. I'll sleep now until we're back in present. http://wiki.dovecot.org/TimeMovedBackwards
<kirkland> slangasek: okay, i'll do that shortly
<slangasek> kirkland: that's the question, isn't it?  maybe I'm just such a jerk that an A is impossible :)
<kirkland> slangasek: :-P
<kirkland> slangasek: couldn't be the case.... you've had patience enough with me so far
<kirkland> slangasek: okay, i think i'm done with this for the day...  on to Alpha2 iso testing
<slangasek> ok, cheers :)
<slangasek> kees: hum, you're really sure those rlimit_nice bugs are fixed in 0.99.7.1?  I thought I only saw the fixes for them committed in later upstream versions
<cjwatson> slangasek: that's partly what confused me too, I think he meant "fixed in later upstreams and in current Debian"
<stgraber> ogra: around ?
<stgraber> ogra: LTSP install just failed
<ogra> nearly dying, but still somewhat awake
<slangasek> cjwatson: well, I'm pretty sure I didn't fix it in Debian :)
<ogra> stgraber, known, i didnt have the time yet to check what it is in a VM
<stgraber> Failed getting release file file:///cdrom/dists/intrepid/Release
<ogra> there is a bug somewhere, let me check
<ogra> https://bugs.launchpad.net/bugs/246615
<ubottu> Launchpad bug 246615 in ltsp "LTSP client installation ended abnormally" [Undecided,New]
<ogra> mean
<ogra> i guess we suffer the same issues of d-i unmounting the CD as debian has in lenny
<stgraber> as ltsp-build-client is started with in-target I guess you should bind mount /cdrom to /target/cdrom
<ogra> can you check if your CD is mounted at all ?
<stgraber> CD is mounted in /cdrom
<ogra> you shouldnt need to bind mount
<ogra> at least you didnt until hardy :)
<ogra> i'll inspect that further by end of the week
<stgraber> well /cdrom is fine but /target/cdrom is empty so as ltsp-build-client is start after chrooting to /target it won't be able to read the cd-rom
<ogra> yeah, but d-i used to care before
<ogra> i'd like to inspect that side first
<cjwatson> slangasek: ... oh
<ogra> but surely not today anymore
<cjwatson> I thought I'd stopped d-i doing that for our CDs
 * ogra had some pretty hard days ... and just managed to fianlly get a working 8.04.1 cmpc release 
<ogra> so i'll just crash now as soon as the upload is through ...
<ogra> cjwatson, it can as well be that ltsp simply runs to late
<ogra> stgraber, the bug above indicates that there are also other errors, i doubt it would even work with CD mounted
<cjwatson> oh, yeah, definitely solve problems in order
<stgraber> ogra: I haven't tried ltsp-build-client in Intrepid other than that ISO testing so I don't know what would have happened if it didn't fail with that missing cd-rom error
<cjwatson> ogra: I don't think it should be too early
<cjwatson> stgraber: but it looked like it was the other way round, "Failed getting release file" after the cp error
<cjwatson> anyway, can't unpick this and dm-crypt at the same time
<ogra> cjwatson, no hurry, i wont touch it tonight anymore and there are definately more issues
<emgent> nixternal: Thanks for your vote :)
<nixternal> emgent: no problem, you deserved it!
<emgent> nixternal: hehe thanks :)
<emgent> nixternal: solved problem with copy/paste ? :)
<nixternal> I will shortly by going back to Mutt :)
<emgent> hehe nice :)
<jdong> nixternal: ugh I've been stuck using evolution and gmail.com this summer; my job is keeping me so busy I've had no time to configure a muttrc
<jdong> and it's down to my last straw of patience now
<jdong> by the way, hi everyone, long time no see. I'm not dead, I just have been swamped with work...
<jdong> *goes disappear for another 3 weeks*
<RAOF> jdong: Howdie.  Have fun! :)
<jdong> btw, vorian , while I'm here, congrats. You deserve it!
<vorian> thanks man :)
<vorian> jdong: don't work too hard
<vorian> and don't get fired
<jdong> lol, trying not to. On both counts. but I think that's somehow mutually exclusive
<vorian> haha
<LaserJock> hi jdong
<jdong> hey LaserJock :)
<nixternal> jdong: ya, I am using Evolution now for work email and switched my home/personal/ubuntu/kde/debian email to Kontact KDE4
<nixternal> I just hate setting up Mutt again, it takes so long to get down
<nixternal> Evolution has one good thing, and that is decent Exchange via OWA support, but the rest of it is just garbage
<jdong> nixternal: yeah the only good thing for me about evolution was that it responds faster than gmail over my weak wifi and was set up in 4 clicks
<orbisvicis> what package tool downloads .dsc files ?
<TheMuso> orbisvicis: dget
<orbisvicis> thanks
<Awsoonn> are we on track for an alpha 2 today?
<Awsoonn> anyone with insight?
<Hobbsee> are the ~motu memberships supposed to expire?
<orbisvicis> when i need to edit source of a package with patches, i need to create a diff .. is that a diff of my revision with the original, or the original with all the previous patches applied ?
<orbisvicis> and then drop it into patches
<LaserJock> Hobbsee: how do you mean?
<Hobbsee> LaserJock: as in, am i supposed to ask someone to renew them, or is it deprecated?
<LaserJock> Hobbsee: no, I believe you want to renew it
<LaserJock> individual membership in ~ubuntu-dev is what was deprecated
<LaserJock> in favor of holding ~motu and ~ubuntu-core-dev
<Hobbsee> oh
 * Hobbsee already renewed that one
<LaserJock> :-)
<Awsoonn> orbisvicis: when you make your patch, it should generally not require the other patches to be already applied, otherwise you will need to make special notes about what patches need applying first
<orbisvicis> Awsoonn, that makes life easy. are there any requirements when running diif, say -ruN etc
<Awsoonn> That is out of my memory right now
<LaserJock> I generally use diff -aurN
<orbisvicis> as long as there isnt a standard i have to adhere to
<orbisvicis> ok, thanks
<orbisvicis> ill patch it tomorrow
<dholbach> good morning
<Hobbsee> hey dholbach
<Hobbsee> dholbach: can you renew my membership in ~motu please?
<dholbach> Hobbsee: you should be able to do that yourself - wasn't there a link in the mail?
<dholbach> I got a mail saying that you already renewed it?
<dholbach> Hobbsee: ^
<dholbach> Hobbsee: expires 2009-07-17
<Hobbsee> dholbach: oh, sorry, ~ubuntu-dev
 * Hobbsee got both today
<dholbach> ubuntu-dev you can let expire
<dholbach> in the end only ubuntu-core-dev and motu will be member of ubuntu-dev
<Hobbsee> ah
<LaserJock> Hobbsee: what I said ;-)
 * LaserJock is glad to find he's not totally lost touch :-)
<Hobbsee> heh
<Hobbsee> LaserJock: i thought we were depreciating the term "motu".  oh well
<LaserJock> no, I don't think so
<LaserJock> eventually the Main/Universe split will probably go away, but I think MOTU may even survive that
<dholbach> soren, pitti: the kernel boots in kvm now, but X doesn't start (uses 100% CPU)
<dholbach> X starts with the old kernel though
<dholbach> and the mouse in KVM only works if I remove the /etc/X11/xorg.conf (on the other hand only 800x600 now)
<dholbach> intrepid is fun :-)
<Awsoonn> does this mean progress for vbox too?
<dholbach> ara: just commented on your ldtp patch - let me know once you updated it and I'll take a look at it again :-)
<ara> dholbach: ok, i'll have a look
<ara> thanks
<soren> dholbach: Figures. :(
<dholbach_> doko: what do you think about bug 240884?
<ubottu> Launchpad bug 240884 in binutils "-g and compiling via assembly fails" [Undecided,Confirmed] https://launchpad.net/bugs/240884
<dholbach> it seems to be important for bug 237175
<ubottu> Launchpad bug 237175 in darcs "Please sync darcs 2.0.0-5 (universe) from Debian unstable (main)" [Undecided,In progress] https://launchpad.net/bugs/237175
<ara> dholbach: maybe this is no longer needed anymore. they have release the ldtp 1.2 and the debian maintainer has already fixed the dependency problem. once he uploads the debian pkg we could just sync with it
<dholbach> ara: ah excellent - could you update the bug report once that has happened?
<ara> dholbach: sure, i will :)
<dholbach> ara: gracias!
<seb128> sbeattie, kees: just read your mail about glib, I just copied the upstream NEWS as usual, it's still using the system pcre, is that an issue for you?
<dholbach> hi seb128
<seb128> (not replying to the mail because they are filtering smtp at GUADEC)
<seb128> hey dholbach
<seb128> pitti: doh about gtkhtml, can't fix it this week but the updates fix a low priority issue
<Hellow> Hello
<seb128> dholbach: I can have a look at the sponsor queue while you on holidays
<dholbach> seb128: that'd be awesome!
 * dholbach hugs seb
 * seb128 hugs dholbach
<pitti> Good morning
<pitti> dholbach: X doesn't start> try without usplash
<pitti> dholbach: or try blacklisting the 'uvesafb' module
<pitti> seb128: thanks
<seb128> pitti: ups, "the update fixes a low priority security issue" it was supposed to be
<seb128> pitti: I'm a bit annoyed that it was waiting for a week and has been rejected, no big deal I'll upload monday using the right bug number
<Hobbsee> heya pitti!
<seb128> hello Hobbsee
<Hobbsee> hey seb128!
<tseliot> ï»¿pitti: did you upload the drivers to Intrepid?
<superm1> pitti, is it possible to yank something out of hardy-updates that is causing some bad breakage for people (but the proper fix is in hardy-proposed waiting to enter hardy-updates)?
<pitti> tseliot: no, shall I?
<pitti> superm1: ugh! which package, which bug?
<superm1> pitti, bug 243930
<ubottu> Launchpad bug 243930 in linux-restricted-modules-2.6.24 "restricted driver wl fails to load" [Undecided,Fix committed] https://launchpad.net/bugs/243930
<tseliot> ï»¿pitti: you told me that you wanted to include them in time for Alpha 2
<pitti> superm1: ah, *phew*, that's at least not a grave regression from hardy final, since wl wasn't present at all
<pitti> tseliot: right, I just wasn't sure who would upload them
<superm1> pitti, well i'd like to understand how it even got introduced though
<superm1> because there was one lrm upload before it, specifically that touched 'wl'
<superm1> it must not have been tested
<superm1> pitti, it is going to break anyone who gets a factory image from dell with a broadcom card though
<tseliot> ï»¿pitti: I would be glad if you could do the upload for me
<superm1> (since the expectation is that the updates are in hardy-updates when they update for the first time)
<pitti> superm1: right, it's still bad, no doubt
<pitti> superm1: so, the bug got an overwhelming amount of positive feedback
<superm1> pitti, yeah from what i see
<pitti> superm1: I feel we shouldn't wait for 7 days to push it to -updates
<superm1> i was just made aware of this earlier this evening
<superm1> pitti, yeah
<pitti> tseliot: sure, I will
<tseliot> pitti: thanks :-)
<pitti> superm1: the diff was trivial (one-liner in Makefile), so it didn't touch anything else than wl
<pitti> superm1: I'm going to copy it to -updates now
<superm1> pitti, wonderful, thanks
<superm1> pitti, i'll talk to the kernel guys tomorrow about how/why this happened then to make sure it doesnt ever happen in the future
<pitti> superm1: thanks, that would be nice
<tjaalton> stupid, stupid emacs... disabling the splash works only if you set it in your own .emacs
<pitti> hah, sticky branding :)
<pitti> tjaalton: but well, that can certainly be patched :-P
<tjaalton> pitti: I bet, but for hardy?-)
<pitti> PPAs FTW
<tjaalton> ugh, maybe I'll write a wrapper which uses --no-splash
<pitti> tseliot: nvidia-settings as well? was it tested?
<pitti> tseliot: do I need to change anything in the source or can I just copy it verbatim from your PPA?
<tseliot> ï»¿pitti: superm1 told me that he has sponsored nvidia-settings for intrepid: https://edge.launchpad.net/ubuntu/+source/nvidia-settings/1.0+20080304-0ubuntu3
<tseliot> ï»¿pitti: the rest can be copied as it is
<pitti> ah, nice
<tjaalton> tseliot: I tried installing another version of nvidia-glx, and X fails to start after that. debugging why
<tseliot> ï»¿tjaalton: which version?
<tseliot> I have tried them all (except for 71)
<tseliot> which builds though
<tjaalton> I had another version installed, then installed another one and then it fails to start
<tseliot> tjaalton: can you tell me which versions then?
<tjaalton> 173 ->96
<tseliot> ï»¿tjaalton: what does the /var/log/Xorg.0.log says?
<pitti> tseliot: all copied; some builds started very soon and thus will fail to upload, but I'll care for them (retrying them)
<tjaalton> tseliot: failsafe.. need to kill that first
<pitti> tseliot: (that was unavoidable due to some soyuz restrictions, sorry)
<tseliot> pitti: thanks
<tseliot> ï»¿tjaalton: ok, let me know
<tjaalton> tseliot: ah, maybe just because the other drivers don't work with 1.5?
<tjaalton> undefined symbol
<tjaalton> so it fails to load nvidia_drv.so
<pitti> tseliot: hm, bah; can you please check your email and tell me what soyuz complains about?
<tseliot> pitti: nothing has arrived yet. I'll let you know
<tseliot> ï»¿tjaalton: does DKMS fail when it tries to build the module?
<tjaalton> tseliot: no, it's not the kernel module but X driver that fails
<tjaalton> the module loads fine
<tseliot> ï»¿tjaalton: when did you upload xserver 1.5
<tseliot> ?
<tjaalton> last week, but it was usable by tuesday
<tjaalton> *on tuesday
<tseliot> tjaalton: can you give me the line with the error?
<tjaalton> (II) Loading /usr/lib/xorg/modules/drivers//nvidia_drv.so
<tjaalton> dlopen: /usr/lib/xorg/modules/drivers//nvidia_drv.so: undefined symbol: miZeroLineScreenIndex
<tjaalton> (EE) Failed to load /usr/lib/xorg/modules/drivers//nvidia_drv.so
<tjaalton> see http://www.nabble.com/xorg-server-problem-td15226827.html
<tseliot> tjaalton: the xserver ABI might be the cause of your problem
<tjaalton> that's what I meant
<tjaalton> nvidia should release new version of the legacy drivers
<tjaalton> versions
<tseliot> tjaalton: read this: http://www.nvnews.net/vbulletin/showpost.php?p=1461694&postcount=4
<tseliot> and this: http://www.nvnews.net/vbulletin/showpost.php?p=1456802&postcount=2
<tjaalton> funny that 173 supports it
<tjaalton> those are old posts btw
<doko> dholbach: -g shouldn't be used both for cc and as
<tjaalton> fedora9 shipped with this, so it's not like there was no demand
<tseliot> tjaalton: can you try setting RenderAccel to Off in the Device section of your xorg.conf and starting x with startx -- -ignoreABI
<tseliot> ?
<pitti> tseliot: ah, all built and in NEW now, processing
<tjaalton> tseliot: ok, a sec
<tseliot> pitti: good
<pitti> E: nvidia-glx-71-dev: maintainer-script-calls-init-script-directly postinst:9
<pitti> tseliot: hm, they still have an init script?
<tseliot> pitti: let me check
<pitti> tseliot: hm, seems they don't
<tjaalton> tseliot: 'Option "RenderAccel" "false"'? Still fails with -ignoreABI
<tseliot> tjaalton: sigh
<tseliot> pitti: it's true, it calls /etc/init.d/nvidia-glx-71 start in the postinst of the -dev package o_O
<tseliot> pitti: I'll see if the that init file is called from somewhere else, remove it and repackage the whole thing. I'll let you know
<tseliot> ï»¿tjaalton: at least 2 packages out of 4 will work...
<tjaalton> tseliot: yep..
<pitti> tseliot: another nitpick: I don't think that the i386 -kernel-source needs to ship nv-kernel.o.x86_64, and the amd64 one nv-kernel.o
<pitti> tseliot: would save 10 MB in the packages
<pitti> tseliot: ok, NEWed
<tseliot> ï»¿pitti: I'll look into that too
<dholbach> doko: do you think you could follow up on the bug report about that?
<gp> hi
<gp> all my systems in office started behaving strangely around 8 pm ist
<gp> all services super slow in lan
<gp> but if i ssh my local computer by ip it takes lot of time
<beuno> gp, this is *still* the wrong channel to ask for support
<gp> tomm if its now fixed I will be blamed
<Hobbsee> support in #ubuntu, no?
<Hobbsee> beuno: wasn't this guy here last night, asking for support?
<beuno> Hobbsee, he was  :)    and good evening to you
<Hobbsee> beuno: evening :)
<gp> yeah but the problem presists
<beuno> gp, well, this being the wrong channel to ask for support still persists
<gp> oks
<beuno> you should head to #ubuntu, or try mailing lists/forums
<gp> i hope its not  bug in ubuntu or something
<gp> its happens in 100% ubuntu network in office
 * beuno sighs
<gp> windows box was working fine
<Hobbsee> and, again, it's still the wrong channel.
<gp> ok bye
<Hobbsee> and you won't get support here.
<RAOF> Given that nvidia discussion up there, I'd like to jump on the tail end:  I'm going to need to update xserver-xgl, since mesa no longer builds one of it's build-deps.
<RAOF> While I'm at it, I'd like to blacklist all the drivers that running Xgl no longer makes sense for.  This essentially means: every driver but the 7-series nvidia driver.
<tseliot> pitti: see if the new source looks better
<Hobbsee> RAOF: pre or post alpha?
<RAOF> Hobbsee: Post alpha.
<tjaalton> RAOF: woo!
<Hobbsee> ah, right
<RAOF> tjaalton: No.  It'd be "Woo" if I was saying "Please remove xserver-xgl from the archives" :)
<tjaalton> RAOF: hehe :)
<Hobbsee> oh, -xgl.  that's that universe crack anyway, isn't it?
<RAOF> Damn straight.
<gp> #unbuntu == newbeee ??
<RAOF> I can at least minimise the accidental damage, though, with only one minor problem: how do you detect the old'n'crusty driver?
<Hobbsee> gp: #ubuntu == support channel.
<gp> hehehehe
<RAOF> Hm... alternatively I suppose I could check for t_f_p, and refuse to start if t_f_p is available.
<RAOF> Now that I think of it, that seems a much better idea.  Test for the feature, not the driver version!
<gp> i better ask google for support then
<RAOF> I wonder if there's been a xgl commit in the last, say, 12 months...
<savvas> how do you apply debdiffs?
<RAOF> Oooh, a mere 4 months ago!
<RAOF> Oh, and it looks like it doesn't misreport it's xrandr version anymore.  Joy!
<RAOF> savvas: With 'patch'
<dholbach> emgent: congratulations!
<savvas> RAOF: patch < file.debdiff ?
<nekostar> sup all ^^
<RAOF> savvas: Pretty much.  You may want -p0 or -p1 or something.
<savvas> hm.. ok, i'll read about that, thanks
<RAOF> savvas: But debdiffs are just a normal, everyday diff.
<nekostar> i've an honest non-fanboy question. do the group of you here consider hardy a truely successful release? compair say to edgy or fiesty
<tjaalton> nekostar: wrong place for that
<nekostar> tjaalton i was just curious as to how basic this is all gonna get is all tjaalton
<nekostar> as i'm just walking in ;)
<Hobbsee> nekostar: they're all successful.
<Hobbsee> at least, have been so far.
<nekostar> i would differ as to hardy and feisty, but apparently thats offtopic.
<nekostar> anyway how does this work? i've not participated here before, sorry.
<RAOF> Yup.  On-topic for #ubuntu-devel currently is: nvidia driver fun, bitching about Xgl, and... stuff.
<RAOF> :)
<Hobbsee> nekostar: as you'll see in the /topic, it's a channel to discuss development of ubuntu.  it's not a soapbox.
<nekostar> heh sup RAOF ;)
<nekostar> Hobbsee lets not fight today, i'm just not in it. i've already looked in the topic, thus the back to business question.... RAOF thanx.
<savvas> RAOF: and if the patch involves a directory renaming (package version change) it does that automatically?
<RAOF> tjaalton: There's nothing which replaces mesa-swx11-source, is there?
<tjaalton> RAOF: nope.. does it still need that for something?
<RAOF> tjaalton: Yes.  Xgl symlinks mesa source into its build tree.
<tjaalton> yuck
<RAOF> Hell, yes.
<RAOF> I think Suse still use it.  I don't know how; it's never been released, and has had about 20 commits in the last year.
<RAOF> Maintained by that famous recluse, David Reveman.  Maybe they've got some private repository where Xgl doesn't suck.
<tjaalton> vnc4 is another user of mesa-swx11-source
<tjaalton> and probably just as painful to migrate
<RAOF> Why does vnc include mesa sources??
<tjaalton> it includes xorg sources too, so why not?-)
<RAOF> Heh.
<RAOF> Man, that must be fun to maintain.
<_max_> anyone happen to know what ubuntu 8.04 uses under the hood of "remote desktop"
<emgent> dholbach: big thanks :)
<nekostar> _max_ vnc via vino?
<soren> _max_: In terms of...?
<_max_> well i used the gui, set a password, worked fine,.. some jackass at work wanted another password since he cant memorize more than 1 pass, so i changed pass, and now neither of the passwords (old or new) works to login.
 * gnomefreak not seeing nvidia fun :(
<_max_> i couldn't find the daemon it was using so i rebooted the machine, and now the service doesn't even seem to have started.
<_max_> ssh works so wanna edit config via ssh and restart daemon.
<tjaalton> sheesh, the debian version of vnc4 still has xfree4.3.0 in it
<RAOF> Surely there have been some security holes found in that?
<tjaalton> but our version is not any better, with xserver-1.0.2
<asac> RAOF: did you test gnash?
<RAOF> asac: Yes.  It works, except for video.
<asac> RAOF: yeah. same here. not sure, but the crash looks gstreamer related
<RAOF> asac: Also, our flashplugin alternatives system is weird.
<asac> pitti: could you let in nspr/nss SRU that fix regression introduced by current -proposed package (#245122)?
<asac> pitti: i attacted the diffs on top of current -proposed packages to that bug
<asac> pitti: ok, the current langpacks in ppa look good for proposed too
<asac> ArneGoetje: ^^
<pitti> asac: thanks, will do
<pitti> nice
<asac> RAOF: the alternative system is dumb yes.
<_max_> okey "vino" seems really easy to setup, when it works.
<tjaalton> RAOF: the reason why vnc4 build-deps on mesa source is that the old xorg-server it includes needed that.. sigh, I'll try to update vnc4
<_max_> but trying to fiddle with it when it doesn't works is a friggin nightmware
<_max_> *mare
<RAOF> tjaalton: Rock on!
<RAOF> Man, the brokenness exposed by a simple change :)
<tjaalton> yeah :)
<RAOF> Is there any chance of the mesa-source package making a comeback?
<RAOF> Or should I be exploring different options?
<tjaalton> could be, need to ask the debian guys
<tjaalton> drop xserver-xgl?-)
 * RAOF can just see and apt-get source command as a part of xserver-xgl's new get-orig-source target :)
<RAOF> That'd be very nice, yes.  But there's still some hardware that it's useful on, and I don't particularly want to break that.
<gnomefreak> doesnt new ati drivers fix the -xgl issue AFAIK that was the last one to be fixed
<tjaalton> RAOF: you mentioned some nvidia chips? the blob doesn't work?
<RAOF> gnomefreak: No.  nvidia-glx-legacy (or whatever it's called now) doesn't have t_f_p, and never will.
<RAOF> I hear we have _yet another_ nvidia blob?
<gnomefreak> ah yeah they wouldnt change it now i forgot legacy
<tjaalton> yes, -173. -177 will drop support for GF5
<RAOF> They're obviously aiming for the "most annoying to support" award of 2008.
<gnomefreak> gf5 as in like 5200 5500?
<tjaalton> yes
<gnomefreak> crap
<gnomefreak> i have 5200 :(
<RAOF> gnomefreak: You've dropped of the "currently supported list"? :)
<RAOF> Hah.
<tjaalton> RAOF: ok, so the new nvidia-glx-71 doesn't work with t_f_p
<RAOF> Man, they're not even ancient.
<tjaalton> gnomefreak: we have maybe 200 machines (on linux) with 5200
<gnomefreak> i have 3
<gnomefreak> so this means i wont be using -173 or -177?
<tjaalton> gnomefreak: -173 works
<tjaalton> the last one
<gnomefreak> ah cool
<RAOF> At least when AMD drop support they're dropping support for cards with good open-source support.
<RAOF> Uuur.
<gnomefreak> should i bother with the PPA builds of nvidia or are we looking at a fix soon?
<tjaalton> gnomefreak: they are in NEW
<gnomefreak> ah sweet thanks
<pitti> emgent: oh, welcome to the MOTU ranks!
<emgent> pitti: thanks :)
<pitti> gnomefreak, tjaalton: no, I NEWed them an hour ago, they should appear on archive.u.c. in about 10 minutes
<tseliot> ï»¿pitti: did you have a look at the ubuntu4 revision?
<pitti> tseliot: not yet, sorry
<tseliot> ï»¿pitti: or are you referring to ubuntu3?
<tseliot> ah, ok
<pitti> ubuntu3 is in the archive for now
<pitti> I'll look at ubuntu4 after finishing SRU processing
<tseliot> pitti: by the way the init file would be called only if it existed. The postinst of nvidia-glx-ver removes it
<tseliot> it's all fixed in ubuntu4
<pitti> nice, thanks
<jordi> crimsun: ping?
<nekostar> pong?
<nekostar> oo 51000 msec response... lively day ;)
<pitti> tseliot: hm, isn't kernel.o.x86_64 needed on amd64?
<pitti> tseliot: seems it's now gone from both i386 and amd64?
<tseliot> pitti: ok, but nv-kernel.o is there right?
<pitti> tseliot: right
<pitti> well, it should be anyway, I just read the source debdiff, haven't checked the binaries
<tseliot> pitti: that file will be taken from either the 32bit or the 64bit folder according to arch
<pitti> +       #cp $(CURDIR)/$(dirname_x86_64)/usr/src/nv/nv-kernel.o $(CURDIR)/debian/temp/modules/nvidia-kernel/nv/nv-kernel.o.x86_64 || true
<tseliot> pitti: the name of the file has to be nv-kernel.o
<pitti> tseliot: I meant that
<pitti> tseliot: shouldn't that be enclosed in some "if [ "`uname -m`" = ... ]" like test?
<tseliot> pitti: it takes the name of the folder from the upstream_info
<tseliot> which tests the arch
<tseliot> pitti: it does something like if [ "$DEB_BUILD_ARCH" = "amd64" ] ; then
<pitti> tseliot: ah, nice
<tseliot> DIRNAME=NVIDIA-Linux-x86_64-${RELEASE}-pkg2
<tseliot> pitti: by the way, I have almost finished the kernel postinst.d hook
<pitti> nice, you made debconf work for that?
<tseliot> pitti: debconf is called from a shell script /etc/kernel/postinst.d
<slytherin> ï»¿archive-admins: Please clear xml-commons-external from ï»¿NEW to allow review of an update of batik. :-)
<tseliot> pitti: the template is filled out according to the output of my Python script
<tseliot> ï»¿pitti: it works well :-) I'll send you the code ASAP
<Caponetta> Hi
<Caponetta> can someone help me. Im tryign to contact the developers of Moblin. Ive got ideas and i want to help and learn.
<ln-> don't forget to use apostrophes.
<cjwatson> Caponetta: #ubuntu-mobile
<ogra> Caponetta, #ubuntu-mobile would probably be the better channel for his
<Caponetta> Ok thank you
<Caponetta> and ln i am pressing the apostraphe key its not showing..
<ln-> i bet you are pressing the wrong key...
<ln-> nevermind
<ogra> punctuation is overrated anyway :)
<soren> I've got a /dev/mapper/1ATA_ST3250620AS_6QE1D4GB2... Where might that be coming from?
<soren> Oh, I know. Never mind.
<pitti> tseliot: copied
<tseliot> pitti: thanks a lot
<pitti> tseliot: you deserve the thanks :)
<pitti> tseliot: I see one major problem ATM: the -modalias packages are in multiverse, too, ATM
<pitti> tseliot: so until we move everything to restricted, we can't ship/install them by default
<pitti> tseliot: I put them into multiverse for now, due to alpha-2 freeze and everything
<tseliot> ï»¿pitti: ah, ok
<pitti> but after alpha-2, l-r-m should just stop building nvidia-glx* and we can drop those and move the new ones into restricted
<pitti> tseliot: can we talk about jockey/modalias/nvidia-glx-XXX integration at some point next week?
<tseliot> pitti: sure. In the meantime, have a look at this: http://albertomilone.com/updater.png
<norsetto> tseliot: do you know anything about dkms failing to build ati modules in intrepid?
<pitti> tseliot: rocking!
<tseliot> norsetto: it might depend on either the kernel (2.6.26) or on the new xserver ABI
<tseliot> ï»¿pitti: I'll send you the package later
 * tseliot goes to lunch
<norsetto> tseliot: don't eat too many orecchiette ...
<tseliot> ï»¿norsetto: ok, spaghetti then :-P
<tseliot> later
<norsetto> tseliot: hmmm, which reminds me that its lunch time for me too ;-)
<pitti> mmm pasta
<asac> pitti: will the langpacks go to intrepid directly?
<pitti> asac: we don't build intrepid packs yet, since we don't have Rosetta exports yet
<asac> pitti: right. just wondered if you copy the -proposed upload to intrepid
<pitti> asac: yes, we can do that
<asac> great
<pitti> well, hm, not any more actually
<asac> oh no :(
<pitti> since intrepid got fresh builds, due to the recommends->suggests changes
<asac> ok. i think intrepid users have then to chew an untranslated firefox for ... not sure how long :)
<pitti> tseliot: the modalias lists don't have a package name ATM; so I need to fix that in jockey itself to use the modalias file name? tricky, but doable
<norsetto> asac: so, is there life after death?
<pitti> asac: hm, works fine for German, at least; is it special, or are the intrepid packs just recent enough?
<asac> pitti: no ... ill upload 3.0.1 today ... which will disable the langpacks for you
<pitti> ah
<asac> pitti: the new langpacks mitigate that in future
<pitti> asac: ABI breakage?
<asac> i wasnt just brave enough to open up maxVersion in the 3.0.0 upload
<pitti> in the 2.0 and 1.5 eras, older langpacks worked well with newer versions
<asac> pitti: no. i intentionally kept 3.0 as maxVersio nin last upload because i feared that mozilla might change strings
<asac> the new langpacks have 3.0.*
<pitti> ah, ok
<asac> (which is why i needed those in the first place)
<pitti> asac: hm, "today"> keep alpha-2 in mind
<asac> pitti: hmm
<pitti> might not be entirely suitable at this point
<impi226> hi... i am here because i want to take part in the development of ubuntu... but i don't know how to start... is there anyone here who can give me a good starting point?
<asac> pitti: when are images done?
<pitti> impi226: https://wiki.ubuntu.com/ContributeToUbuntu is a good starting point IMHO, with a wide range of things you can help with
<norsetto> impi226: https://wiki.ubuntu.com/MOTU/GettingStarted is a good starting point
<pitti> impi226: if you are particualrly interested in package development, you should give #ubuntu-motu a visit
<impi226> i already read this articles
<pitti> great!
<norsetto> impi226: so, what is the problem? Perhaps we should move to #ubuntu-motu since that channel is more appropriate
<asac> norsetto: you mean life after mplayer?
<impi226> but okay
<norsetto> asac: lol
<asac> norsetto: i'll do them in the same batch that I'll do the debian security uploads
<asac> which should happen really soon :/
<asac> given that i manage to unbreak my etch/sid chroots
<norsetto> asac: ok, I think you haven't read my last email yet then :-)
<asac> norsetto: when send?
<norsetto> asac: Monday 16:46:04
<asac> i should have read that by now
<asac> let me check
<asac> norsetto: Jul 2 is last mail i got
 * norsetto hopes this is not another joke :-(
<asac> I'd love so say that its a joke, but i dont see that mail
<norsetto> asac: ok, I'll resend it, you gave me once another email address but I think I lost that, do you mind giving it to me again?
<norsetto> asac: anyhow, in a nutshell the question was: for mplayerplug-in and gecko-mediaplayer, should we make the transition to xulrunner-1.9 for intrepid (and break things for 1.8 based browsers) or not?
<asac> norsetto: ill have to think about it
<norsetto> asac: I can imagine ;-) danke!
<slytherin> archive-admins: Please clear xml-commons-external from ï»¿NEW to allow review of an update of batik. :-)
<asac> norsetto: we can use 1.8 as as long as its still in intrepid
<norsetto> asac: ok, makes sense to me
<asac> norsetto: do you build depend on iceape-dev in debian?
<norsetto> asac: yes
<asac> fine
<norsetto> asac: to be clear, the packages as they are build and work out of the box in both ubuntu and debian, there is no ubuntu specific bit which needs to be added to the debian packages
<asac> ok good
<asac> norsetto: not even flip build-depends?
<norsetto> asac: nope :-) We are luky that libxul-dev is no more in Debian
<asac> norsetto: hmm. how do the build-depends look like?
<norsetto> asac: for gecko-mediaplayer? libxul-dev | iceape-dev
<asac> norsetto: i guess that will fail on the buildds
<asac> i think buildds dont try fallback build-depends
<asac> at least i had a similar issue with enigmail
<norsetto> asac: will it? It works on my unstable pbuilder
<norsetto> asac: what? They just look for the first one and if not found bail out? Why bother with the fallbacks then!?!?
<cjwatson> Debian and Ubuntu differ in this respect
<asac> norsetto: as far as i understand its because the buildd cannot tell whether the primary build-depend is missing intentionally or if it should just wait for it
<cjwatson> Debian doesn't try fallback build-dependencies; Ubuntu does
<cjwatson> (IIRC, anyway)
<asac> cjwatson: ubuntu does?
<cjwatson> this is because in Ubuntu's case the fallback one might be in universe and there might be a working one in main
<asac> norsetto: if so, flip them ... e.g. make libxul-dev secondary
<norsetto> cjwatson, asac: oh gosh (/me bump his head against the wall)
<cjwatson> (now lamont will turn up and tell me I have hideously misremembered)
<asac> ok cool. i can then do enigmail in this way too ;)
<lamont> huh!??
 * norsetto bump Deb and Ian heads against the wall too
<pitti> it definitively did that in the past, and allowed us to sync some packages and avoid a pointless delta
<pitti> not sure whether it's still true, though
<pitti> but it worked for stuff like "b-deps: links | elinks"
<asac> cjwatson: even if its wrong, you gave us hope for a while :). which is a good thing.
<cjwatson> yay, a successful invocation
<norsetto> asac: we can't reverse, or it will use iceape-dev in Ubuntu too as a build-dep
<asac> norsetto: we dont have iceape-dev
<asac> norsetto: if we had that, we wont have a problem at all
<lamont> cjwatson: debian always only tries the first one.  this uber-perl-hacker I know (thanks cjwatson) wrote a nice sbuild patch to try all of them for existance and take one if found, specifically because of main build-dep: universe | main
<norsetto> asac: last I checked, we did have it !?
<asac> norsetto: i think only in gutsy
<norsetto> asac: iceape-dev | 1.1.9+nobinonly-0ubuntu1 | intrepid/universe | all
<asac> norsetto: oh. so it came back ;)
<asac> fine
<lamont> cjwatson: so yes, you misremembered :-p
<asac> norsetto: hmm. thats a transitional package for seamonkey
<asac> norsetto: we have to fix seamonkey first, before we can use that
<cjwatson> lamont: erm, I did? that matches the description I gave above
<cjwatson> and I was about to say "yay, I remembered correctly"
<asac> damn
<asac> quite a short time of happiness ;)
<cjwatson> except I meant to say "in Ubuntu's case the primary one might be in universe but there might be a working fallback one in main"
<soren> cjwatson: FYI: https://lists.ubuntu.com/archives/kernel-team/2008-July/002701.html  <--- Fixes Intrepid guests in kvm.
<cjwatson> ooh, thanks!
 * soren bows
<soren> Happy to be of service.
<lamont> cjwatson: right.
<lamont> so yeah, you remember.
<tmmoyer> I am trying to do some custom work with the installer, and was wondering if anyone could tell me what I need to add to /etc/apt/sources.list to be able to fetch packages like finish-install and other udebs used by the installer?
<Lrrr> tmmoyer: lemme see
<Lrrr> tmmoyer: If you do apt-cache showsrc finish-install, do you get any output?
<tjaalton> asac: shouldn't ff3 read a site-wide config from /etc/ff-3.0/pref/*
<tmmoyer> Lrrr: yes it does show the information for finish-install
<asac> tjaalton: it should
<tjaalton> asac: also, ff3 doesn't seem to use /usr/share/ubuntu-artwork/home/*index.html anymore
<Lrrr> tmmoyer: the you can fetch the source to it, so you don't need to add anything particular in your sources.list
<asac> tjaalton: install ubufox to get the best homepage experience
<tjaalton> asac: is there a way to debug the startup?
<asac> tjaalton: the startup`
<asac> ?
<asac> is there a bug?
<Lrrr> tmmoyer: But installer development is done through launchpad.  You can fetch the last version of the individial installer packages there.
<tjaalton> asac: ubufox is installed.. I'll check it out. startup meaning that what it loads on startup
<asac> tjaalton: 1st. check that the default home page is really the default ;)
<asac> in preferences -> Content (iirc)
<cjwatson> tmmoyer: regular 'apt-get source' will work; actually installing udebs on a normal system is a very bad idea
<asac> err, Main :)
<cjwatson> tmmoyer: http://wiki.ubuntu.com/InstallerDevelopment
<tmmoyer> cjwatson: I'm not installing them on my system, I am getting the source and modifying some of the packages
<tjaalton> asac: yes, it shows the ubufox page, but I'd like to change that :)
<cjwatson> tmmoyer: right, so Lrrr's answer is correct, i.e. "nothing"
<tmmoyer> Lrrr: Since I am customizing to a specific release, I would prefer to use the same packages as are already being used by the installer
<asac> tjaalton: then whats the problem?
<cjwatson> tmmoyer: so if you have the appropriate deb-src lines for that release then you'll be just fine
<tmmoyer> cjwatson: thanks
<tjaalton> asac: system wide..
<asac> good point ;)
<asac> tjaalton: what you could do is introducing a locked pref
<asac> tjaalton: that should prevent it from being overwritten
<tjaalton> asac: the problem is that users should be able to change it. we used to have a locked pref because there was no alternative, until I noticed the ubuntu-artwork stuff
<ScottK> slangasek: Debian claims to have fixed Bug 138189 - Should that wait until after alpha2 or do you want a fix nowish?
<ubottu> Launchpad bug 138189 in pykdeextensions "application tries to dlopen /usr/lib/libpython2.5.so (only found in the -dev package) " [Medium,Confirmed] https://launchpad.net/bugs/138189
<asac> tjaalton: ill think about the options
<tjaalton> asac: cool, thanks
<lamont> dear firefox.  if I switch to a different tab while you're fetching a page, I really _DO_NOT_WANT_ you to automatically yank me away from what I'm doing to visually smack me in the face with the finally-fetched web page.  I'll get back to it, honest.
<lamont> no love
<liw> lamont, firefox does that? ugh
<lamont> yeah.
<lamont> laggy links for the los
<lamont> s
<tedg> I hate that too.  Epiphany.
<liw> tedg, hmm, my epiphany doesn't do that
<tedg> Now that FF redid their search bar to make it more like Epiphany it's one of the biggest reasons I still use Epiphany.
<tjaalton> asac: maybe I can modify ubuntu-mods.js and distribute it
<asac> tjaalton: we should add preferences for "other" homepages in ubufox imo
<asac> so admins can add their ubufox.online.homepage and ubufox.offline.homepage and ubufox.always.offline settings in /etc/
<tjaalton> asac: ok, that would be nice
<asac> the other thing is that firefoxs load order should not do 1. package, 2. /etc/ 3. extensions, 4. profile, but 1. package, 2. extensions, 3. /etc/, 4. profile
<tjaalton> yeah...
<asac> i think thats a bug - which might be not-so-easy to fix
<asac> tjaalton: #247281
<tjaalton> asac: ok, so actually, it _did_ load my file from /etc/ff-3.0/pref, but only those settings that hasn't been set by ubufox :)
<norsetto> asac: ok, we now have iceape-dev only as a b-d for gecko-mediaplayer (a small delta for us but a big leap for humankind, etc. etc.)
<asac> tjaalton: yeah. thats what the bug is about ;)
<asac> norsetto: does it build with iceape-dev?
<asac> norsetto: and more important: does it work in xulrunner-1.9 still
<norsetto> asap: in Debian you mean, or in Ubuntu?
<norsetto> asap?
<tjaalton> asac: ok, so I'll change what I can in ubuntu-mods.js
<tjaalton> directly
<norsetto> asac: in Debian you mean, or in Ubuntu?
<norsetto> asac: it builds in both, but we don't want to build with that in Ubuntu, we will have to change it everytime
<asac> norsetto: in ubuntu
<asac> norsetto: we want to build with that in the end
<asac> norsetto: i think it just doesnt work atm
<asac> norsetto: please confirm that it breaks in xulrunner-1.9 if build with current iceape-dev
<norsetto> asac: to builds it builds, I know because I tested that already, I can check to see if the plugin works with firefox-3.0
<asac> tjaalton: maybe we should fix firefox extension manager to read a syspref directory for every extension as well
<asac> that might be simple
<asac> tjaalton: for now you can dump a link ZZsystem-config.js to your /etc/firefox-3.0/pref/myprefs.js in the ubufox defaults/preferences directory
<asac> tjaalton: does that help?
<norsetto> asac: back to square 0, with latest iceape-dev in intrepid it doesn't even build, I could try to see if I can patch the configure stuff
<tjaalton> asac: ok, I'll try
<asac> norsetto: ok. makes sense. I will take that into account when i fix seamonkey
<asac> norsetto: so for now we have to change the build-depends i guess
<norsetto> asac: so far yes, everything else should still be cool for Debian
<tjaalton> asac: yeah, that works :)
<asac> tjaalton: good
<norsetto> asac: its looking for iceape-plugin.pc and iceape-xpcom.pc
<asac> norsetto: yes. i think we will ship compatibility links in the iceape-dev package
<norsetto> asac: hmmm, there is something fishy in there, there was a check for seamonkey already, but was misspelled as seamokey, but even correcting that it still doesn't find the .pc files
<asac> norsetto: strange
<norsetto> asac: ahhh, I see why, libnspr-dev its not a depends of seamonkey-dev
<asac> norsetto: add libnspr4-dev then. shouldnt hurt in debian
<norsetto> asac: yes, its already dragged in by iceape-dev in any case for them
<norsetto> asac: ok, now it fails because it doesn't find the xpidl compiler
<asac> norsetto: hmm. yeah. i think we need libxul-dev until i fix seamonkey to ship the complete sdk
<norsetto> asac: yes, alas there is no xpidl in seamonkey-dev
<sladen> what's Agostino Russo's latest IRC nick?
<evand> sladen: xivulon
<norsetto> asac: I'm just amazed at how you guys can manage to keep a brain sane with all this iceape/seamonkey/firefox/xulrunner/xulrunner-1.9 stuff
<wereHamster> Hardy doesn't use xorg autoconfiguration, and uses the xkb keyboard driver. Are there any plans to change that in the next release?
<Kano> hi, what is scrollkeeper and why does it take ages when i install some packages while registering documents with scrollkeeper?
<wereHamster> Kano: have you tried asking google?
<persia> Kano: Insufficient implementation of dpkg-triggers
<Kano> persia: when will it be fixed?
<persia> Kano: Sometime after someone builds a working trigger for scrollkeeper, and submits patches for all packages that use scrollkeeper.
<Kano> persia: how to disable that man-db trigger
<ogra> persia, upstream works on a scrollkeeper replacement i was told
<ogra> so with a little luck scrollkeeper will die soon :)
<kirkland> cjwatson: could have you a look at the patch for https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/247103 at your earliest convenience?
<ubottu> Launchpad bug 247103 in openssh "ssh init script should support the 'status' action" [Wishlist,In progress]
<persia> ogra: Excellent news!
<ogra> persia, http://live.gnome.org/Yelp/Spoon
<ogra> for reference
<persia> http://rarian.freedesktop.org/
<seb128> what is the discussion about?
<ogra> seb128, just a question about scrollkeeper slowness
<seb128> alright
<seb128> we will switch in intrepid soon
<ogra> yay
<seb128> not this week though, I'm busy at GUADEC
<ogra> bah, slacker
<ogra> :)
<ogra> how is istanbul ?
<seb128> great
<seb128> the weather is a bit too hot during the day though
<Hobbsee> how hot?
<seb128> over 30Â°C
<seb128> which is probably nothing for you
<StevenK> Can we swap?
<Hobbsee> yummy!
<Hobbsee> that's still reasonably warm.  people here would be complaining at that sort of temperature.
 * Hobbsee would actually be warm at that temperature, though :P
<seb128> on holidays that's alright
<Lrrr> I'd complain.  It is humid?
<seb128> 62% humidity apparently
<seb128> looking quickly on a weather website
<Hobbsee> ouch.
<Lrrr> that's less than where I live can deliver.
<seb128> alright, enough IRC for now, see you later
<ogra> seb128, enjoy :)
<cjwatson> stgraber: fix for your encrypted LVM bug in progress
<cjwatson> stgraber: did you file a bug for it? (if you didn't, don't worry, just want to know so I can close it)
<cjwatson> hmm, except that it created /dev/mapper/system-root and then randomly removed it. odd
<Hobbsee> strange.  since when does networking not work in an intrepid chroot?
<Hobbsee> (when the host does)
<soren> What doesn't work?
<Hobbsee> apt-get update
<StevenK> How doesn't it work?
<Hobbsee> (if you're meaning me)
<soren> Hobbsee: I did.
<StevenK> Hobbsee: Perhaps /etc/resolv.conf didn't get copied?
<Hobbsee> Err http://ppa.launchpad.net intrepid Release.gpg
<Hobbsee>   Could not resolve 'ppa.launchpad.net'
<soren> Hobbsee: Do you have a resolv.conf in there?
<Hobbsee> StevenK: it was working when i last booted there...
<soren> That's what they all say.
<StevenK> Heh
<Hobbsee> yes, it's blank.
<Hobbsee> # generated by NetworkManager, do not edit!
<ogra> StevenK, since whne does it get copied automatically ?
<StevenK> Which would explain why it can't resolve names ... :-)
<soren> Unblank it.
<Hobbsee> apart from ^
<StevenK> ogra: I thought debootstrap did that ...
 * ogra definately never had a resolv.conf in the ltsp chroots
<soren> Nope.
<ogra> i have a plugin in the chroot builder for that
<Hobbsee> oh, so if n/m's not running on the system, it all falls over and dies?  great.
<soren> How do you get into the chroot?
<soren> pbuilder, schroot or just plain chroot?
<Hobbsee> chroot
 * Hobbsee copies the host system version in.  there we are.
<cjwatson> StevenK: yes, it does
<cjwatson>         conditional_cp /etc/resolv.conf "$TARGET"
<StevenK> Hah, I win.
<StevenK> :-P
<ogra> cjwatson, hmm ? how do i trigger that ?
<ogra> its not done by default for me
<ogra> and never was
 * ogra would love to drop that plugin from ltsp
<cjwatson> (since forever, I think)
<ogra> hmm
<cjwatson> it's done by default. perhaps when debootstrap runs for you /etc/resolv.conf doesn't exist
<ogra> ltsp-build-client by defalt uses network packages ...
<ogra> so indeed it exists on the server i run it on
<cjwatson> in d-i, you run ltsp-build-client chrooted into /target, yes?
<Hobbsee> cjwatson: if you're talking to me, i doubt that's the case, as this is a proper intrepid system, on another partition
<cjwatson> at one point in the past, /etc/resolv.conf wasn't copied by that point
<cjwatson> Hobbsee: was talking to ogra
<Hobbsee> cjwatson: ah, sorry.  couldn't tlel.
<ogra> cjwatson, yes, but i'm talking about a normal manual run of ltsp-build-client
<cjwatson> Hobbsee: in your case it looks like NM was confused at the time
<ogra> i see that function should also copy /etc/hostname
<ogra> which definately doesnt happen either here
 * soren concurs
<cjwatson> ogra: afraid I don't know, you'll have to dig into it
<ogra> yeah, just looking at the code ...
<ogra> but all we do is call debootstrap ... no special stuff there
 * cjwatson suggests set -x in debootstrap
<ogra> hmm, its run from first_stage_install and i acually have all changes that function does ...
<ogra> intresting ... in my development chroots its actually correct, just not in ltsp client chroots
 * soren tries a vm-builder run with sh -x debootstrap
<ogra> ogra@osiris:~/Devel/ltsp$ grep debootstrap ltsp-trunk/server/plugins/ltsp-build-client/Ubuntu/010-debootstrap
<ogra>         debootstrap $DEBOOTSTRAPOPTS --arch $ARCH $DIST $ROOT $MIRROR
<ogra> DEBOOTSTRAPOPTS is usually empty ....
 * ogra scratches head
<stgraber> cjwatson: hi, no I didn't file a bug for it, just reported it as a failed for Manual partitioning on the ISO tracker.
<orbisvicis> when patches are numbered 000 to 030, etc does that mean anything when i create my patch, 031 ?
<cjwatson> orbisvicis: it's just ordering, that's all
<orbisvicis> cjwatson, i still patch my changes against the original /sources/file.c ?
<tseliot> does anybody know who approves the messages in the ubuntu-devel mailing list?
<cjwatson> orbisvicis: depends on the patch system
<cjwatson> orbisvicis: with dpatch, for instance, you should read the documentation for dpatch-edit-patch and use it
<cjwatson> tseliot: me and others. Why?
<ogra> orbisvicis, use a patch tool like dpatch-edit-patch or wahtever your package uses ... it might be that other patches touched the file before
<orbisvicis> ogra, thats what i worried about
<orbisvicis> howeverm i only see 30 patches, no config files for anypatch systems
<tseliot> cjwatson: I sent a message to the mailing list to add useful information on the drivers in Intrepid but I received as a reply that it's a moderated list
<cjwatson> tseliot: that is correct
<cjwatson> orbisvicis: https://wiki.ubuntu.com/MOTU/School/PatchingSources
<evand> approved
<cjwatson> tseliot: there is no need to ask about moderation - we're pretty well on top of the queue
<cjwatson> it's generally processed several times per working day
<orbisvicis> cjwatson, ty. any links like that for pbuilder ?
<cjwatson> orbisvicis: the wiki has an excellent search feature
<tseliot> ï»¿evand: thanks
<cjwatson> (sorry, apparently I should have pointed to https://wiki.ubuntu.com/PackagingGuide/PatchSystems instead)
<tseliot> ï»¿cjwatson: sorry, it was my 1st message in the mailing list
<orbisvicis> cjwatson, id like to know why pdebuilder doesnt need to be root to build a package when the base dir is /var/cache/pbuilder and owned by root. and how i can tell the difference between fakeroot and other files
<cjwatson> orbisvicis: the only reason root is required to build a package is to get file ownerships right, and fakeroot simulates enough stuff to allow that to work without root. Most uses of pbuilder only *read* the base tarball from /var/cache/pbuilder and unpack it elsewhere; they don't write to /var/cache/pbuilder.
<cjwatson> orbisvicis: please take further questions like this to #ubuntu-motu
<orbisvicis> cjwatson, thanks
<slangasek> ScottK: 138189> better after alpha2; how was it fixed in Debian?
<ScottK> slangasek: Changed the name of the .so that it links to.  I swear I tried the same thing and it didn't work.
<slangasek> ScottK: as in, libpython2.5.so -> libpython2.5.so.1.0?
<ScottK> Yes.
<slangasek> that is the right fix, but kde-guidance still has to be rebuilt after the change is made in pykdeextensions
<ScottK> Yes.
<ScottK> Also need to drop the libpythonize-dev dependency too (I think that was it, I have notes).
<ScottK> slangasek: We are close to dropping the KDE front ends for that package (for KDE4 alternatives).  Once the KDE specific stuff is gone, I intend to rename the source package to not have kde in the name.
<slangasek> so did the Debian maintainers do anything about ensuring smooth upgrades? (conflicts with old versions of kde-guidance?)
<ScottK> No.  We're ahead of them in the transition.  For guidance-power-manager (which was ported to KDE4 and is in a separate package) we've done that.
<ScottK> For the display stuff, it's yet to be done.
<ScottK> Debian will get this fun post-Lenny.
<alex-weej> in light of the recent mails on devel-discuss, i filed this bug with the "regression" tag
<alex-weej> https://bugs.launchpad.net/ubuntu/+source/linux-meta/+bug/247335
<ubottu> Launchpad bug 247335 in linux-meta "S3 suspend sometimes fails" [Undecided,New]
<alex-weej> did i do it right?
<cjwatson> http://people.ubuntu.com/~cjwatson/ubuntu-policy/ - work in progress
<soren> cjwatson: Interesting.
<soren> cjwatson: We talked about renaming Vcs- headers to XS-Debian-Vcs- a while back... Will that be mentioned?
<cjwatson> XS-Original- actually
<cjwatson> like XSBC-Original-Maintainer
<cjwatson> Vcs-* isn't mentioned yet, so I'm unsure about doing that
<soren> cjwatson: Sure?
<cjwatson> BTW, for those who weren't in the UDS session, the plan is to get something vaguely right and then open it up for group maintenance, so you send a patch to ubuntu-devel, get somebody to second it, then get it applied
 * soren looks for the thread on the ml..
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/debian-policy/debian-policy>$ grep -i vcs policy.sgml
<cjwatson> <cjwatson@sarantium ~/src/ubuntu/debian-policy/debian-policy>$
<soren> Oh, they're not even mentioned in Debian's..
<cjwatson> there is a changelog entry mentioning adding Vcs-Browser and Vcs-Git, but it's talking about the debian-policy package's own control file
<norsetto> soren: they are in the maintainers guide IIRC
<soren> https://lists.ubuntu.com/archives/ubuntu-devel/2007-March/023366.html You suggested it yourself, and mdz seconded it... I've been renaming them to XS-Vcs-Debian myself. :/
<soren> "it" being using "Debian" rather than "Original".
<cjwatson> hmm, yeah
<cjwatson> I don't seem to have adopted that myself yet, but fair point
<soren> It's worth considering.
<cjwatson> XS-Vcs-Debian definitely seems irregular, should be XS-Debian-Vcs if anything
<soren> Did I say XS-Vcs-Debian? That was certainly a mistake if I did.
<cjwatson> the only major thing in UbuntuPackagingChanges that I haven't applied yet is the LSB init script stuff
 * soren wanders off to the store..
<BenC> is there a param to pass on the kernel command line to tell the livecd which xorg driver to use?
<ogra> you could boot in commandline mode and fiddle with the config
<ogra> it has a textmode option iirc
<hwilde> where is the src for the /sbin/init  binary ?
<ogra> hwilde, totally depends on your distro ;)
<ogra> for recent fedora and ubuntu its in upstart ... for others likely in some sysv-init package
<hwilde> why is it called upstart this is so confusing
<ogra> hwilde, whoops ignore that
<ogra> i thought i was in #ltsp :)
<ogra> its indeed in upstart :)
<hwilde> lol
<hwilde> I usually am in ltsp too
<hwilde> just not right now
<ogra> its called like that because its creator picked that name ... its a new concept and that the binary is called init is just for compatibility reasons i guess
<ogra> if you dont do that all apps relying on it to be called like that will have to be patched
<hwilde> ok so umm I have the src now
<laga> eg the kernel ;)
<ogra> (i.e. if you would call it /sbin/upstart instead)
<hwilde> upstart-0.3.9
<hwilde> but where is the src for /sbin/init
<hwilde> oh maybe in the init directory
<hwilde> man... rough day
<ogra> :)
<hwilde> ok now here is what I don't understand
<hwilde> if /sbin/init calls /etc/init.d/rc.local
<hwilde> where is rc.local referenced in the upstart src ??
<james_w> hwilde: see /etc/rc2.d/S99rc.local
<hwilde> james_w, ok fair enough, but what calls /etc/rc2.d/S99rc.local
<ogra> hwilde, init is dumb, it just walks the rc dir of the initlevel
<hwilde> so init runs through every file in /etc/rc2.d
<hwilde> /etc/rc2.d/S99rc.local calls /etc/init.d/rc.local
<ogra> what exactly are you trying ?
<hwilde> and /etc/init.d/rc.local calls /etc/rc.local ?
<hwilde> I'm just trying to unravel the boot sequence
<ogra> right, if /etc/rc.local is executable the initscript calls it
<cjwatson> /etc/rc2.d/S99rc.local *is* /etc/init.d/rc.local (symlink), it doesn't call it
<cjwatson> /etc/init.d/rc walks through the runlevel directory
<ogra> ah right
<cjwatson> /etc/event.d/rc[0-6] calls /etc/init.d/rc
<cjwatson> upstart reads /etc/event.d/* natively
<ogra> not init on its own
<cjwatson> however, it might be less confusing to walk through that the other way round if you're trying to understand the boot sequence: rather than taking a script and trying to figure out what calls it, start from init and figure out what it calls
<hwilde> except init doesn't really exist, it's called upstart
<hwilde> and it doesn't actually reference anything, it walks through the entire /etc/rcX.d directory
<hwilde> and those files doesn't actually exist, they are simlinks
<hwilde> other than that it's really straightforward
<cjwatson> nothing there is especially non-straightforward
<cjwatson> packages often provide binaries that are not identical to the name of the source package
<cjwatson> walking through directories is completely standard for extensible programs
<cjwatson> symlinks are trivial Unix functionality
<cjwatson> you only find it difficult to unpick because you're working from the bottom up :)
<cjwatson> don't do that, and it will be easier
<hwilde> the real problem is some noob copied /etc/rc.local to /etc/init.d/rc.local
<hwilde> then things didn't work the way they expected
<hwilde> then they started editing things
<ogra> yay, fun
<hwilde> now I have to untangle it
<hwilde> but i'm not even sure how it was supposed to be in the first place
<hwilde> never had to look into that bc i've never messed it up
<ogra> reinstalling initscripts should give you the original /etc/init.d/rc.local back ...
<cjwatson> err
<ogra> not ?
<cjwatson> only if you use the dpkg --force-confnew option
<cjwatson> it's a conffile - you only get a resolution prompt if it has changed on both sides
<cjwatson> personally, if I didn't know the tools inside out, I would find another system running the same version of Ubuntu and 'diff -ru' the two /etc directories
<ogra> meh, indeed
<cjwatson> then you will be able to see the differences in files you know got clobbered, and undo them
<cjwatson> (DO NOT JUST BLAT A NEW /etc OVER THE OLD ONE)
<sbeattie> BTW, is there a way to get dpkg to report which files are marked as conffiles?
<cjwatson> they're all in Conffiles: fields in the status file
<pitti> sbeattie: dpkg -s <packagename> shows them for a particular package
<cjwatson> 'dpkg -s' on a given package name will show them
<cjwatson> snap
<pitti> sbeattie: /var/lib/dpkg/status has a list of all known ones, too
<sbeattie> ah, there we are. Thanks pitti and cjwatson
<cjwatson> rather than reading /var/lib/dpkg/status directly, install dctrl-tools and run: grep-status -sPackage,Conffiles -rFConffiles .
<cjwatson> that'll show everything
<cjwatson> (the dot at the end is part of the command, not a full stop)
<sbeattie> ah, regex for any char
<Lrrr> bzr shelve is fiiine
<cjwatson> way ahead of you :-): http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/2006-01-09-bzr-shelve.html
<Lrrr> I'm a Mercurial guy.
<Lrrr> hg record sucks a bit compared to that.
<sbeattie> Lrrr: do you use mqueues?
<Lrrr> sbeattie: Not really.
<cjwatson> the problem with 'hg record' (and the similar 'darcs record') is that you end up committing something that has never existed in isolation, and therefore by definition cannot have been tested in isolation, in your working tree
<Lrrr> sbeattie: I've used it though.
<Lrrr> sbeattie: But I see you might mean that you can use mq in way similar to shelve.  If so, you are probably right.
<sbeattie> Well, maybe.
<sbeattie> I'm a longtime quilt user and found shelves counterintuitive, though the hunk-by-hunk nature of shelve is nice.
<sbeattie> but I haven't tried the bzr loom plugin yet, either.
<Lrrr> My discovery of hg record is rather recent, so I have not grown use to anything yet.
<pitti> speaking about bzr, "bzr rebase" FTW, too
<Lrrr> bzr has so much nice things but still feels slower than Mercurial
<slytherin> asac: is xulrunner-1.9-dev supposed to libxul-dev?
<Lrrr> cjwatson: Germinate question again.  I want to manager 2 distributions sharing seed names in a single meta-package.  Is there some kind of way to make the seed outputs not overwrite each other or do I need to patch germinate again?
<asac> slytherin: ?
<geser> asac: add a "replace" to his question
<slytherin> asac: I was trying to merge classpath from debian. Debian doesn't have xulrunner-1.9-dev yet so the package compiles fine there. When I replace libxul-dev with xulrunner-1.9-dev the gcjwebplugin fails to build. Reason seems to be that plugin related header files are in wrong path.
<Amaranth> anyone know what the heck is going on with xorg? something broke compiz
<kirkland> So I'm writing an MIR for a source package that produces multiple binaries, of which the *only* one I actually need in main is the library/headers one
<kirkland> Can I propose that only that binary package be promoted to main?
<asac> slytherin: doesnt debian have xulrunner-dev instead?
<slytherin> kirkland: why do you want it that way?
<kirkland> slytherin: b/c i only need the library as a build dependency for another MIR.  the other binary packages have daemons, open network ports, etc.
<_MMA_> slytherin: Because like he said he only cares about 1 of the binaries.
<_MMA_> gah. too late.
<cjwatson> Lrrr: I'd just run germinate-update-metapackage twice in two different temporary directories
<cjwatson> or maybe not even temporary
<slytherin> asac: yes, didn't see it. But the problem remains that headers files nsIPlugin*.h are in path /usr/include/xulrunner-1.9/unstable/ instead of /usr/include/xulrunner-1.9/stable/ in case of xulrunner*-dev
<cjwatson> e.g. (cd ubuntu && germinate-update-metapackage --bzr); (cd kubuntu && germinate-update-metapackage --bzr) and then use ubuntu/desktop-* and kubuntu/desktop-* as sources for substvars
<cjwatson> kirkland: yes, you may, although the source package will go into main
<Lrrr> cjwatson: Oh I think I see what you mean thank you.
<ScottK> kirkland: I just did that for sendmail so I could get libmilter-dev into Main.
<asac> slytherin: well. you need to use libxul-unstable.pc to get unstable headers.  doesnt debian use that?
<slytherin> asac: AFAIK, classpath is still using libxul-dev as build depends. It hasn't been ported to build with xulrunner*-dev
<Lrrr> cjwatson: no, not really, I need to run it from the root of the package source tree so I can't have seperate directories
<cjwatson> Lrrr: why do you need to run it from the root?
<cjwatson> oh, debian/control check
<cjwatson> how about I add an --output-directory option
<asac> slytherin: not sure what classpath does. maybe the port would just use libxul-unstable.pc
<Lrrr> cjwatson: well, yeah, that would suit me, but do you want me to add it since it's not immediately useful to you?
<cjwatson> well, I'd already started, but you can if you like ...
<cjwatson> (go for it)
<cjwatson> calc: the installer should now let you enter raw byte values by suffixing 'B'
<slytherin> asac: classpath looks for pkg-config in following order, mozilla-plugin, firefox-plugin, xulrunner-plugin, mozilla-firefox-plugin, seamonkey-plugin, iceape-plugin. So the first one it finds is I guess mozilla-plugin which doesn't include path for unstable directory.
<Amaranth> can any of you confirm bug 247088
<ubottu> Launchpad bug 247088 in compiz-fusion-plugins-main "expo allows bypass of screensaver" [Undecided,New] https://launchpad.net/bugs/247088
<cjwatson> so '2147483648B' == 2G(i)B
<cjwatson> should at least help work around problems even though it's not all the way there yet
<asac> slytherin: mozilla-plugin is just basic plugin api. nsIPlugin should be xpcom are there tests for mozilla-xpcom?
<Lrrr> good python practice for meee
<slytherin> asac: No, there are -xpcom tests for everything else except mozilla
<_MMA_> Amaranth: I can't here.
<kirkland> cjwatson: good, thanks.  i've tried to indicate such in https://wiki.ubuntu.com/MainInclusionReportTrousers
<asac> slytherin: huh? whatelse would require xpcom if not mozilla?
<asac> or do you mean firefox-xpcom etc.?
<slytherin> asac: yes, the tests are like firefox-plugin, firefox-xpcom, then next xulrunner-plugin, xulrunner-xpcom etc.
<_MMA_> Amaranth: I can't reproduce any way I try. I'm always asked for my password.
<slytherin> asac: leave it now. It is midnight for me. I will try to debug tomorrow.
<Amaranth> _MMA_: same here
<Amaranth> dunno what is going on there
<_MMA_> Amaranth: I actually *tried* to do this about 6 months ago. No luck then either.
<_MMA_> Amaranth: Tried to bypass a locked screen with various Compiz effects that is.
<cjwatson> kirkland: should be fine
<kirkland> cjwatson: thanks.
<cjwatson> kirkland: (remove question marks when you've answered questions, e.g. "vigorous ?" -> "vigorous")
<kirkland> cjwatson: okay
<kirkland> cjwatson: fwiw, i think the particular build dependency in question is not necessary.  i've email the debian maintainer about softening it.
<kirkland> cjwatson: so that particular MIR may be null and void
<cjwatson> I didn't look at the report all that hard :)
<Amaranth> _MMA_: did you bind a plain mouse button to expo?
<Amaranth> _MMA_: so just hitting button 3 will activate it
<kirkland> cjwatson: ;-)  btw, did you catch my ping earlier about an openssh-server init script patch?
<cjwatson> kirkland: uploaded a few minutes ago ...
<_MMA_> ï»¿Amaranth: Oh. I see. I mis-read that. I tried with keybindings and screenedges.
<kirkland> cjwatson: ah, nice.
<Amaranth> _MMA_: I remember trying this when we had a hack in compiz to prevent such things but now that we rely on the X server it may have broken
<kirkland> cjwatson: shall I open a Debian bug after the  updated library function makes it into Debian?
<Amaranth> and I'm on OS X right now so...
<_MMA_> Amaranth: Ok. Tried with button3 on 2 boxes. 1 Intel, the other nVidia. No dice. Asks for password.
<cjwatson> kirkland: no need, I sync from time to time anyway
<kirkland> cjwatson: cool, thanks.
<Amaranth> _MMA_: did you make the password dialog pop up then try to activate expo or try to activate expo and it popped up the password dialog instead?
<_MMA_> Both
<Amaranth> _MMA_: alright, thanks
<kirkland> slangasek: I think that only leaves the init script patch for samba awaiting sponsorship/upload (bug #247087)  ;-)
<ubottu> Launchpad bug 247087 in samba "samba init script status action" [Low,In progress] https://launchpad.net/bugs/247087
<slangasek> kirkland: after the alpha, yes. :)
<kirkland> slangasek: ah, gotcha ;-)
<Lrrr> cjwatson: I've pushed the change to my personnal Germinate branch.  There is 2 or 3 changesets you might want to see there too but nothing that important.
<kirkland> is it possible within launchpad to set a bug as a blocker for another bug?
<pitti> kirkland: no, it isn't
<kirkland> hrm
<cjwatson> Lrrr: where's that?
<jcole> can someone enlighten me of why we dont also rebuild mini.iso everytime a new kernel is released -> /ubuntu/dists/hardy/main/installer-i386/current/images/netboot/mini.iso
<jcole> s/we/ubuntu
<jcole> lol
<jcole> it cannot find the modules for d-i since the kernel is newer
<cjwatson> jcole: /ubuntu/dists/hardy-updates/ - enjoy
<cjwatson> note that the kernel is in hardy-updates too
<cjwatson> so match them up
<jcole> cjwatson: i would kiss you, but im both straight and too far from you
<cjwatson> perhaps that is just as well ;-)
<rgb> Hello.
<rgb> A question.  Is it already known that the last update seriously screwed up audio?
<slangasek> rgb: that's a little vague, but there haven't been any major reports of audio regressions that I'm aware of, no
<greg-g> rgb: to report a new sound bug, see this page: https://wiki.ubuntu.com/DebuggingSoundProblems
<greg-g> the section titled "Reporting Sound Bugs" is what you want to follow
<rgb> No, I'd rather just know if anyone else has stopped by who also have music and video playback stop after x ammount of seconds.
<rgb> Ranging from 10 to about 25 seconds.
<slangasek> rgb: no, and since you're the only one so far experiencing it, reporting a bug is the only reliable way to see that it gets fixed; so far, you haven't even said which update this happened with
<rgb> The latest.
<slangasek> sorry, that means nothing; the latest what?  the latest release, the latest point release, the latest package added to -updates, the latest kernel in intrepid?
<slangasek> you'll have to give us a reference point that lets us understand what "latest" means to you
<rgb> The latest updates of all the packets, how am I supposed to know what that update is called?  They're all rolling.
<rgb> Today, last 24 hours, huge ammount of new packets.
<greg-g> rgb: honestly, the best thing to do is to report a bug following the instructions on the page I linked.
<rgb> I will, it's just that I'm severely pissed since even after completely reinstalling Hardy and then running the updates, it's still fucked.
<slangasek> ok, so you're running hardy; that's a starting point
<greg-g> Sorry for your issues, and that sounds like a bug that should be reported.  however, I am not experiencing the same issue so I can not report it for you.
<slangasek> do you have hardy-proposed enabled in your software sources, or only hardy-updates? ("Pre-released updates" vs. "Recommended updates")
<Chipzz> rgb: not that you're doing so currently, but slight hint: if you want to take out your anger on someone, #ubuntu-devel is not the place to do it
<rgb> I know, don't worry, I already vented most of my anger.
<Chipzz> rgb: there have been people who did such things before; as such ;)
<rgb> Lessee, before reinstall I had selected Multiverse and Universe next to the default iirc.
<rgb> Lemme check the standard setting for repositories.
<rgb> Main, Universe, Restricted and Multiverse are selected by default.
<rgb> Which I used since this reinstall.
<Chipzz> rgb: that shouldn't matter (I think)
<rgb> Chipzz, I can understand.
<Chipzz> though you're right that universe and multiverse are not officially supported
<rgb> Hardy-proposed and hardy-backports are not selected under the updates slangasek.
<rgb> So Security and Updates only.
<stgraber> rgb: if you run "aplay /usr/share/sounds/login.wav" from a terminal, do you get any sound ?
<slangasek> ok; there have been some packages moved from hardy-proposed to hardy-updates in the last couple of days, but I don't remember that any of these were sound-related
<slangasek> the only one that I guess might be would be the kernel itself
<stgraber> (just trying to find the package that could have caused the regression)
<slangasek> hmm, no, that's not recently-moved
<stgraber> slangasek: -19 was a long time ago IIRC
<slangasek> right
<stgraber> any pulse update recently pushed to -updates ?
<slangasek> no, there have been no pulse updates at all
<slangasek> nor alsa updates
<rgb> slangasek: I thought it was the kernal also, so did a bunch of degrades to the oldest version.  No success.
<stgraber> bah, would have been too easy :)
<rgb> stgraber: Probably, will test now.
<slangasek> rgb: really, filing a bug should be your next step; given that there are no obviously-guilty packages that have been updated in the past couple of days, you'll need the help of someone who knows the sound packages closely, and not just people like me trying to guess based on what they see in the archive
<crimsun> instead of beating around the bush, run the alsa-info.sh script referenced at wiki/DebuggingSoundProblems.
<rgb> Atm I cannot play it, but I have a video running in the background for testing purposes.  It keeps dying every random 10 to 30 seconds and continues another (greater) random ammount of seconds later.
<_MMA_> There was a restricted modules update yesterday. Are the nVidia drivers only for GFX or do they apply to nForce boards as well?
<rgb> I don't have an nForce board.
<_MMA_> k
<crimsun> _MMA_: graphics.
<rgb> So that doesn't apply to me.
<stgraber> _MMA_: AFAIK the nvidia chipset has its drivers in the kernel
<_MMA_> nm me then. :P
<norsetto> rgb: is that a laptop or you have external speakers?
<rgb> It's a desktop.
<crimsun> (nforce audio is provided by i810_audio, snd-intel8x0, or nvsound - plus the associated ac'97 codec driver, respectively.  Only when dealing with nvsound is it irrelevant.)
<rgb> Connected to my stereo.
<norsetto> rgb: check your cable then
<rgb> norsetto: I can get sound.
<rgb> I hear sound.
<rgb> The problem is the sudden and random stopping.
<rgb> And after a while continuing.
<crimsun> also, why is this discussion occurring here?
<norsetto> rgb: you said comes and go, that typically a cable problem
<rgb> norsetto: You would think so.  But when also the video stops I doubt it's a cable problem.
<rgb> And I have done nothing about my cabling in months.
<norsetto> rgb: then its not just a sound problem, which is what you have reported so far
<rgb> And seeing as everything worked fine 2 days ago.
<rgb> Possibly.
<rgb> But it also happens in audacious where there's no video.
<rgb> Hence my main hunch was that the sound was destroying everything.
<crimsun> nice one, but no.
<crimsun> and if you continue to rant without actually providing useful debugging info, it's pretty futile.
<rgb> Sorry that I'm not able to do everything at once n_n
<crimsun> again, multiple have pointed you to the wiki/DebuggingSoundProblems page.  I specifically mentioned the alsa-info.sh bash script that you need to download invoke via bash in a terminal.
<alex_mayorga> hello all devs, can somebady take a quick look at my last comment on bug #121111 please?
<ubottu> Launchpad bug 121111 in linux-source-2.6.22 "Gutsy Tribe 3 CD don't load on Dell Inspiron 1501" [Medium,Fix released] https://launchpad.net/bugs/121111
<rgb> http://pastebin.ca/1068602  <<< Utils script uploaded that.
<alex_mayorga> I hadn't renamed the bug, but seem to be recurring on Intrepid alphas, thanks in advance
<rgb> crimsun: I had read it, I was already reading the Wiki but did not wish to keep people here waiting too long.  Hence the delay in numerous things.
<crimsun> rgb: I'm happy to help you in #ubuntu.  This channel isn't appropriate.
<rgb> I was there, too loud and didn't get through.  Will go there again.
<slangasek> alex_mayorga: I recommend that you open a new bug; even with the same symptoms and the same workaround, it may not be the same issue anymore, and it's easier for developers to merge two reports that are the same than to winnow out information from two unrelated bugs being reported in the same bug number
<alex_mayorga> slangasek, thanks will do
<Lrrr> cjwatson: lp:~fdgonthier/germinate/fdg
#ubuntu-devel 2008-07-11
<calc> cjwatson: cool :)
<calc> yipee i managed to get OOo to properly build under intrepid now
 * milli applauds calc
<mathiaz> slangasek: I'm about to upload the openldap merge from debian - considering that the package has been renamed from openldap2.3 to openldap, is there anything to special to do in LP ?
<slangasek> mathiaz: hum, the QA folks might have a better idea in that regard than I do; I think they dealt with the similar case of the linux package renames
<slangasek> mathiaz: I imagine that all the bugs with open intrepid/openldap2.3 tasks should also have tasks opened for openldap/intrepid, but the doing is tedious without some script help :)
<mathiaz> slangasek: I was planning to move all bugs related to openldap2.X package to openldap
<slangasek> right, then that's the only special thing I can think of
<mathiaz> slangasek: well - there aren't so many of them
<slangasek> ok
<mathiaz> slangasek: I was more thinking about soyuz
<slangasek> nah, we just need to be sure to remove the package as obsolete after openldap has gone through source NEW
<slangasek> feel free to file a bug to that effect and subscribe ubuntu-archive
<calc> how do you properly branch from bzr.d.o to launchpad?
<calc> do i just go into a bzr.d.o checkout and push it to lp?
<slangasek> calc: sounds right to me...
<calc> ok thanks
<calc> i get this error:
<calc> bzr: ERROR: Transport operation not possible: http does not support mkdir()
<calc> should i be doing something special other than "bzr push lp:~openoffice-pkgs/openoffice/3.0-intrepid"
<slangasek> hmm, is your launchpad user ID configured?
<slangasek> 'bzr launchpad-login'
<slangasek> (I don't know if that makes a difference in how lp: uris are parsed, but it's worth a try)
<calc> it seems that using the bzr+ssh bit works but not sure if i have launchpad-login setup right
<calc> my local username and lp match though
<cjwatson> Lrrr: debian/changelog entries would be appreciated
<cjwatson> Lrrr: also would prefer newline-indent after colon as a general rule, rather than packing onto one line
<cjwatson> Lrrr: the ".It Fl o Fl Fl output-directory" bit in the man page is wrong formatting - see germinate.1 for examples of how to do that properly (search for .It Xo)
<cjwatson> Lrrr: expect I'd be happy to merge after those fixes
<Lrrr> cjwatson: noted, I'll fix that tomorrow.
<jdong> hmm, anyone know of bug #'s for USB HID devices not working in initramfs
<jdong> my macbook internal keyboard is USB, and it's annoying that it doesn't work in initramfs
<jdong> i.e. where my encryption passphrase needs to be entered
<RAOF> Oh, awkward.
<jdong> after udev starts post-rootmount it works, and also one of 3 boots work
<jdong> I think it must be a race condition where upon activating the USB bus the keyboard doesn't connect for a second or two
<jdong> just enough to miss the point that udevsettle is done during initramfs
<jdong> *considers hacking some sleep calls*
<jdong> is there a way to inject a premount command rather than dropping to a prompt? break=premount does me no good if I can't actually type anything :D
<ion_> Hack /usr/share/initramfs-tools/scripts/init-premount and update-initramfs -u
<jdong> well.... that actually requires a livecd so I can have a working keyboard AND a decrypted / :D
<jdong> oh well, weekend project
<ion_> So, a prompt is shown, but for some reason the keyboard doesnât become available because itâs discovered after udevsettle? That sounds a bit strange. Youâd still expect udev to load the module and the keyboard to start working.
<ion_> Are the necessary modules installed to the initramfs for sure?
<jdong> right, the symptoms are exactly as you state
<jdong> except one of every 3 or so boots, it actually works
<ion_> Huh.
<jdong> something racy seems t be taking place
<jdong> whether that's because of initramfs, or by luck legacy peripheral emulation is still active by apple BIOS emulator...
<jdong> the HID modules are definitely in initramfs
<TheMuso> jdong: I guess the best way to track that one down is to boot into the initramfs with debugging enabled.
<bluefoxicy> BenC:  hey
<bluefoxicy> I guess Alpha 2 isn't out yet
 * bluefoxicy found some flaws with the current implementation of compcache, but isn't sure the exact impact; thinks it's still overall positive
<ion_> What kind of flaws?
<ion_> Other than that the newest version (the one that is in the Ubuntu kernel) seems to like to crash on my box. :-)
<bluefoxicy> ion_:  Well I haven't been in ANY code for a while, much less kernel code; but at a glance I don't like the memory eviction policy, mainly.
<ion_> 0.3 didnât.
<bluefoxicy> lemme get the current code
<BenC> bluefoxicy: hey
<bluefoxicy> Hi BenC :)
<bluefoxicy> (isn't this particular issue assigned to you?)
<bluefoxicy> http://code.google.com/p/compcache/source/browse/trunk/compcache.c is what I'm looking at.
<bluefoxicy> Lines 185-193 seem to handle freeing a page... which basically entails, "If the kernel just wrote a NEW memory page to that spot in the swap device, then the old one was probably gotten rid of ages ago, so we can safely free it from memory now"
<bluefoxicy> so, let's say you kill -9 a process that uses, say, 1000 pages (4MB) of the compcache device for swap?  Those pages will remain in memory, compressed, until something else swaps out overtop of them
<bluefoxicy> It makes sense for disk based swap devices:  when you free a page you just note it's no longer used in kernel memory.  The disk doesn't know or need to know about this.  Compressed cache does need to know, but doesn't.
<bluefoxicy> I'm GUESSING the impact is going to be that long term usage will cause a chunk of memory to get tied up needlessly; but that it will still be an improvement over not having it.  There's a "worst case" that just simply fills up the compcache device and doesn't use it ever again; I think this WILL occur if the compcache device doesn't have the highest priority (i.e. if you favor filling up a disk-based swap device first, and e
<bluefoxicy> nd up spilling over into compcache)
<persia> Doesn't the very nature or compcache encourage using it as highest-priority swap?  "disk" i/o is likely to be slower, even when the "disk" is in fact SDRAM.
<bluefoxicy> persia:  yes it does.
<bluefoxicy> persia:  the very nature of compcache actually encourages it to be an intermediary cache though, i.e. CPU registers > L1 > L2 > L3+ > RAM > compcache > disk swap
<bluefoxicy> however, it's lumped in as a disk swap; you'll fill up compcache and then start putting further pages on disk, instead of pushing them out of compcache under the observation that they really haven't been used in a long time (LRU policy on compcache would be more optimal)
<persia> Hmm.  Makes sense.  Might be a slot for VRAM swap in there at some point, but that's not heavily used (and compiz discourages it).
<RAOF> As far as I'm aware, any form of graphics acceleration discourages it (at least the naieve implementation I've seen on the gentoo wiki)
<bluefoxicy> I've actually got a small list that I sent to Nitin; but the eviction issue seems important to me just because you could seriously bone yourself by adding compcache as lowest priority swap
<bluefoxicy> other issues included it not being an intermediary cache; compressing one page at a time (the sweet spot, based on tests I did years ago, was groups of between 4 and 8 pages); and not compressing page cache (which effectively "swaps" against the on-disk copy of the data)
<ion_> The initramfs stuff for compcache uses -p 100, as well as the compcache-setup package waiting in REVU. Iâm not sure users are going to manually swapon it, forgetting to use a high priority. That doesnât mean the issue is not there, of course.
<persia> RAOF: I thought there were some better implementations sorted, but it does require that you've lots more VRAM than you need, and most graphics accelleration wants local textures.
<pwnguin> am i crazy, or is this arizona package manager vuln wrong on the details?
<bluefoxicy> ion_:  nods.  With it being the first device used, it's a gain over not having it; however, do note that when you fill it up and then "empty" it, it's still holding a chunk of RAM as used, so you'll start swapping to it earlier than you need to.
<ion_> Yeah
<bluefoxicy> IN THEORY this is PROBABLY not an issue, since that particular operation is cheap.
<bluefoxicy> aside from effectively decreasing the amount of physical ram available to things like page cache, which aren't swapped out
<pwnguin> Question: does HTTPS really matter for the official -security repo?
<foka> freeflying, Hi!
<bluefoxicy> pwnguin:  you can MiM stuff and replace packages, but they're signed.
<freeflying> foka: hi
<bluefoxicy> so I don't really think so :P
<foka> freeflying, I think I'm a REVU now.  So, I can already upload packages directly?  What's the procedure?
<pwnguin> thats what i was thinking; you dont need an https cert when the metadata and packages are gpg signed themselves by the repo
<freeflying> foka: #ubuntu-motu
<pwnguin> unless you think https itself is safe but apt-get or gpg is not...
<foka> freeflying, Go there?  :-)
<freeflying> foka: yes
<pwnguin> granted, the author does point out that apt will happily fill your filesystem if the other end just sends you /dev/random
<pwnguin> well, at least the paper is intelligent
<philsf> does ubuntu releases point releases in a fixed schedule, or when updates get big enough (or the min of those)?
<slangasek> point releases for LTS releases are scheduled in advance
<slangasek> for 8.04, they're planned at 6-month intervals
<philsf> I thought it was strage that https://wiki.ubuntu.com/HardyReleaseSchedule ends at the just release .1
<philsf> so the next is due Jan09, right?
<slangasek> approximately, yes
<slangasek> it hasn't been scheduled precisely yet
<philsf> fair enough, thanks for the info
<bluefoxicy> yesterday's Intrepid Alpha 2 release is also approximate
<ionstorm> was it released?
<bluefoxicy> not as of a couple hours ago <_<;
<bluefoxicy> or if it was I sure as hell can't find it
 * persia comments that the definition of "yesterday" is geographically variable
<persia> Someone in UTC +10 and someone in UTC -8 might have very different views of when Thursday happens.
<slangasek> it's not released yet because we haven't been getting ISO tests in
<slangasek> so it's slipping a day; email to u-d-a will be sent soon
 * bluefoxicy somehow tempted to use compcache for a file system, since it doesn't have any code that prevents it from being used as a plain old block device.
<bluefoxicy> persia:  where is sabdfl?
<bluefoxicy> and is it still thursday there :)
<persia> bluefoxicy: Unfortunately, it appears that shoes have been changed since I last emplaced a microdot transmitter: I can't answer that with any confidence.
<bluefoxicy> lol
<gnomefreak> i guess X is still having issues after i installed nvidia-glx-173 and now i cant get a X session after using nvidia-config
<gnomefreak> nevermind its fixed so far
<dholbach> good morning
<dholbach> hi ara
<ara> hey dholbach
<pitti> Good morning
<asac> pitti: ffox 3.0.1 / xul 1.9.0.1 require your approval ;) (hardy-proposed)
<pitti> noted
<asac> security-updates through -proposed, yay!
<pitti> thekorn: hm, p-lp-bugs broken again, on BugReport.__nickname parsing; known already?
<thekorn> pitti: yup, working on it, bug 247498
<ubottu> Launchpad bug 247498 in python-launchpad-bugs "Recent rollout of edge.launchpad.net broke py-lp-bugs" [High,In progress] https://launchpad.net/bugs/247498
<pitti> thekorn: great, thanks
<stgraber> Who broke my fglrx ? :)
<pitti> cjwatson, thekorn: btw, any idea about the difference of the main and intrepid.merge branches? someone flipped the default branch to intrepid.merge on drescher
<stgraber> I had to spend half an hour and 3 hard reboot to get a working X server again :)
<pitti> stgraber: hardy or intrepid?
<stgraber> intrepid
<pitti> *phew*
<stgraber> don't worry, Hardy works fine (including suspend to ram) :)
<pitti> thekorn: oh, nice, that looks like test suite output
<pitti> thekorn: ok, then I'll just wait with sync processing until it is fixed
<thekorn> pitti: yes, py-lp-bugs now has some unittests
<ondrej> hi ppl, while it's fine that you removed edgy from mirrors (hmm, what about announcement?), there should be a way how to download update-manager-core for edgy, so people can upgrade long forgotten servers.
<persia> ondrej: old-releases.ubuntu.com
<pitti> ondrej: edgy and others are still on old-releases.ubuntu.com
<pitti> ondrej: also, why do you need u-m for edgy? you certainly don't want to upgrade a dapper to edgy, you want to upgrade it to hardy...
<ondrej> pitti: I have server on edgy and it's stuck because I cannot download d-r-u
<pitti> d-r-u?
<ondrej> do-release-upgrade
<ondrej> ie. update-manager-core
<pitti> hm, weird; I had always thought that update-manager would download the tarball for the target release
<ondrej> it propably would, but since it was minimal install I don't have update-manager{,-core} installed at all
<persia> ondrej: http://old-releases.ubuntu.com/ubuntu/pool/main/u/update-manager/ (I don't think -core was split out back then)
<ondrej> persia: sure, thanks...  I can handle it from now...  I was just trying to explain problem in more detail (and I will update FeistyUpgrades wiki page to mention that)
<persia> ondrej: Thanks for updating the documentation
<ondrej> persia: just FYI: update-manager-core is available for edgy
<persia> Odd.  I wonder why it wasn't in the same pool directory.  Maybe something special about that package.
<ondrej> persia: I think it wasn't part of the same source back then...  anyway this upgrade is non-trivial, you have to change old-releases to archive in sources.lists in the middle of do-release-upgrade script.
<ondrej> ok, done, upgraded to feisty, thanks to all
<pitti> wonderful
<pitti> oh, gone already
<slytherin> Can any archive admin please clear xml-commons-external from new queue? An update to batik is dependent on it.
<pitti> I'll get to NEW processing in a bit
<slytherin> pitti: thanks. :-)
<mdz> why does compiz suddenly think it would be a good idea to map my mouse wheel to switching workspaces?
<tseliot> ï»¿mdz: Compiz does it on Hardy too, when you have the mouse cursor on an empty area of the desktop and use the mouse wheel.
<mdz> tseliot: this was on top of firefox
<mdz> but I can't seem to reproduce it now
<mdz> it was very surprising though
<thorwil> mdz, sure you didn't hover the workspace switcher?
<mdz> thorwil: yes
<mdz> hovering over the switcher doesn't seem to do that when I try it
<pitti> ^ that WFM in metacity
<mdz> ahh, the keypad state on my keyboard was activated
<pitti> (compiz doesn't want to start on -intel apparently ATM)
<slangasek> s/start/be useful/?
<thorwil> mdz, maybe some modifier-key -weel combo?
<pitti> well, whatever it thinks; I just get metacity
<slangasek> ah; I thought you meant the bug that I'm seeing here, which is that compiz doesn't fall back to metacity, I just get a blank screen in intrepid
<slangasek> (installer testing)
<pitti> does anyone know why so many linux-{,headers,image,restricted-modules}-$FLAVOR metapacakges are NBS?
<pitti> linux-meta only builds a small subset of the former hardy set
<slangasek> because the kernel team has split everything out of the main package
<pitti> is that on purpose?
<stgraber> tseliot: just wondering, there is currently no fglrx driver working with 7.4 right ?
<slangasek> it's on purpose, though I still wonder about the wisdom of it seeing how none of those other packages have gotten done yet
<tseliot> ï»¿stgraber: no, the xserver broke the ABI compatibility
<pitti> slangasek: ATM I'm not sure whether I should kill those NBS or not; I left them last week, and I'm inclined to leave them today, too
<slangasek> pitti: yes, I was about to say I think they should be left where they are as a pointed reminder
<slangasek> and perhaps we should schedule some time next week to sync up with the kernel team about exactly whose responsibility it is to recover those other packages, so we know who to bug
<stgraber> tseliot: ok, so that'll be radeonhd and hoping ATI's next driver will include Xorg 7.4 support :)
<tseliot> stgraber: you can try something like this but success is not guaranteed http://www.linuxinsight.com/running-nvidia-display-drivers-with-xorg-7.3.html
<tseliot> (to ignore the ABI, I mean)
<soren> slangasek, pitti: At least amitk and myself will be taking care of getting the virtual and lpia builds going. I imagine we'll have our own meta packages as well.
<soren> Next week, that is.
<slangasek> ah, next week, that's good to know
<pitti> slangasek: let's, yes
<pitti> whoops, I forgot to actually cron the NBS script, doing
<stgraber> oh, interesting option I'll give it a try and see how broken it'll be :)
<stgraber> thanks tseliot
<pitti> soren: virt-viewer wants to pull xen-3.1 into main, but main already has xen-3.2; I hope that can be fixed?
<pitti> tjaalton, bryce: xserver-xorg-video-via source is in main, binary is in universe, -all depends on it; shall I promote the binary, or does -all need to be fixed?
<mdz> thorwil: my keyboard is a kinesis and has a keypad lock (the numeric pad shares keys with the alphabetic keys)
<mdz> thorwil: when that is activated, the mouse wheel switches workspaces
<mdz> pitti: nvidia-glx-173 works fine for me, modulo bug 247523 and bug 247527
<ubottu> Launchpad bug 247523 in dkms "Fails silently if kernel headers are not available" [Undecided,New] https://launchpad.net/bugs/247523
<ubottu> Launchpad bug 247527 in nvidia-graphics-drivers-173 "Kernel headers dependency could be more specific" [Undecided,New] https://launchpad.net/bugs/247527
<soren> pitti: Certainly.
<cjwatson> pitti: I switched it to intrepid.merge because at the time that was what worked
<pitti> Riddelll, nixternal: FYI, I removed the python-kde4 source, because it seems to be superseded by kde4bindings; however, python-kde4 is still in Debian; what's the plan for this?
<cjwatson> pitti,slangasek: agreed, I've been avoiding removing those NBS packages too
<thekorn> pitti: py-lp-bugs should be fixed now
<pitti> thekorn: yay you
<pitti> cjwatson: ok, I updated the main branch for this ^ and flipped back, since main works ATM (for syncbugbot anyway)
<pitti> bryce, tjaalton: also, xserver-xorg-video-vga wants to go to universe; are we exclusively using -vesa as a fallback now? i. e. is this deliberate?
 * pitti tries to reduce the insane size of component-mismatches a bit
<cjwatson> pitti: ok, cool
<tjaalton> pitti: -all should not depend on it anymore
<tjaalton> and vga is dead
<tjaalton> it's not included in X7.4 katamari
<pitti> tjaalton: ok, so I demote vga, and wait with the -via demotion until -all gets fixed?
<tjaalton> pitti: actually, you could just remove via, since it's deprecated upstream, and openchrome is the default anyway
<tjaalton> there should be a bug about it too..
<pitti> tjaalton: I just don't want to break installability of -all at this point (alpha 2 tomorrow)
<tjaalton> via doesn't build against 1.5
<pitti> unless you want to fix -all right now
<tjaalton> it doesn't break it
<tjaalton> openchrome | via
<pitti> ah :)
<tjaalton> :)
<tjaalton> it will be removed completely in the next upload, but that shouldn't be necessary for alpha2
<pitti> tjaalton: it's still in Debian, though; will someone file a removal bug there as well, or shoall I blacklist it?
<slangasek> pitti: kdesudo-kde4 is missing from the kubuntu desktop images because it's a recommends and has yet to be promoted to main
<slangasek> pitti: could we do a quick main promotion of it?
<tjaalton> pitti: yes, they don't have the new stuff available yet
<slangasek> (breaks ubiquity rather badly)
<pitti> slangasek: yep, will do right now
<tjaalton> pitti: so it'll get removed when 1.5 hits unstable
<pitti> tjaalton: ok, removed; thanks
<pitti> slangasek: kdesudo is already in main, so I guess the package should eventually just be renamed
<slangasek> perhaps
<slangasek> hrm, but kdesudo-kde4 installs its binary under /usr/lib/kde4/bin, what good is that supposed to do? :/
<pitti> and kdesudo is still KDE 3 AFAICS
<slangasek> yes
<slangasek> anyway, kdesudo-kde4 is the one that's seeded, so I guess we should at least get that fixed for now
<pitti> slangasek: kdesudo-kde4 hasn't been uploaded in intrepid yet, so I guess that simply needs some work
<slangasek> pitti: well, I wonder how burying the binary in /usr/lib was ever supposed to work... it won't work for ubiquity, AFAICS
<cjwatson> is there an equivalent in some other package? a lot of the -kde4 packages got replaced
<pitti> Tonio_: do you have some insight wrt. kdesudo?
<slangasek> I think the equivalent would be kdesudo, but that's the KDE3 version
<pitti> how did it work in alpha1? or didn't that have kde CDs?
<pitti> slangasek: so, kdesudo-kde4 is derived from kdesudo (one upload) with porting to kde4; I have no problem to quickly promote it at this point, but I have doubts that it will fix the problem?
<slangasek> we didn't have desktop CDs
<slangasek> pitti: correct, that alone won't fix the problem
<cjwatson> we need a ubiquity upload anyway; I'm happy to do a quick path tweak
<cjwatson> though I won't be able to test it
<slangasek> cjwatson: /usr/lib/kde4/bin, then
<pitti> promoted
<pitti> lool, StevenK: hm, why does hildon-control-panel{,-l10n} want to go back to universe?
<pitti> slangasek: ah, and rightfully kdesudo wants to go to universe; demoting that
<pitti> StevenK: and libhildonhelp, too
<pitti> in fact, half of the mobile stack is there
<cjwatson> pitti: mobile has moved to separate seeds which LP isn't yet taking into account, which probably influences that
<pitti> oh, I see
<pitti> cjwatson: so component-mismatches is very misleading ATM then
<pitti> I guess some of the demotions I just did were wrong them (some were correct, though)
<cjwatson> yes, sorry :-/
<pitti> s/them/then/
<pitti> well, eventually they will pop back
<cjwatson> just be careful about mobile things
<lool> Hmm
<pitti> yes, I didn't demote the obvious ones
<ogra> dont we build mobile with universe enabled anyway atm ?
 * ogra thought we did
<lool> ogra: Ultimately we'd like to change this
<cjwatson> ogra: the target is for that stuff to move to main
<ogra> right, but for alpha2 it should be ok :)
<cjwatson> I'll sort out a bug report about this in a bit - I'm knee-deep in ubiquity at the moment
<lool> pitti: (StevenK is in holidays this week BTWÂ°
 * lool launches a rope to pull cjwatson out
<ogra> asac, could you take a look at https://bugs.launchpad.net/cmpc/+bug/247478
<ubottu> Launchpad bug 247478 in cmpc "Classmate PC fails to connect a wired LAN." [Undecided,New]
<ogra> i'm not sure what i should tell them
<ogra> what they do there (playing with roaming mode on a wired connection) seems very weird
<asac> ogra: err, if he turns of "roaming mode", then its not network manager anymore
<asac> turns off
<cjwatson> gar, crash on switch to vt
<asac> ogra: the bug is quite hard to read. is that china?
<ogra> yep
<asac> ogra: what are they trying to achieve? static IP configuration?
<asac> ogra: i dont understand why they "check roaming off" in step 2. and do the same in step 3. again :/
<asac> i think either 2 or 3 should be "check roaming on"
<ogra> hmm
<ogra> now that i read it again i dont even understand point 1
<asac> yeah ... what is a wired AP?
<asac> a hub/router?
<ogra> 1. Keep roaming mode enabled and plug in a network cable connected to an AP.
<ogra> heh
<ogra> they dont say *wired*
<asac> ogra: does "click.Click unlock" mean: double click?
<laga> maybe ask them for clarification?
<ogra> asac, no, the dot ends the forst sentence :)
<ogra> *first
<asac> ah ;)
<asac> ogra: i think they should make more steps out of it:
<ogra> could you comment  ?
<ogra> so they see that its valuable to use LP :)
<ogra> istead of sending spreadsheets around :)
<asac> ogra: valuable like: "i mark your bug as invalid" ;)
<ogra> no, ask for more or vclearer info
<asac> ogra: whats the name of the gnome network admin package again?
<ogra> network-admin iirc
<pitti> ogra: usb-imagewriter> why not add an option for an alternative output file? -o /tmp/test.img
<pitti> ogra: hardcoding that upstream isn't nice either
<pitti> ogra: also, please don't use shell=True, just split the args into components (trivial here); better for weird file names
<ogra> pitti, ergh, that was fixed upstrem indeed it picks the device from the pulldown menu
<pitti> ogra: I have to reject it anyway, I'll mail you
<ogra> pitti, plan is to make dd go away completely
<ogra> ok
<pitti> (sent)
<ogra> pitti, there is only one actual application file in there and that has a GPL header ... i thought that suffices
 * ogra adds a general license ...
<pitti> ogra: thanks
<ogra> pitti,  and i suspect debian wouldnt be happy about the branding ;)
<ogra> http://people.ubuntu.com/~ogra/ImageWriter/main.png
<persia> ogra: That's loaded at runtime, no?  A sufficiently imaginative debian/rules ought be able to allocate the right branding :)
<pitti> ogra: nice :)
<ogra> pitti, dont wait for it ... just had a discussion with persia, we'll look at it next week at the sprint and rip out dd as well
<laga> ogra: what's the replacement for dd?
<laga> python magic?
<ogra> no idea, persia has one we didnt discuss yet  (next week) .... but i would assume python, yes
<_MMA_> ogra: That branding there actually needs a little help. :P I'll help if you want or tap kwwii. Unless he did that one. Then I'll have to have a word with him. ;)
<pitti> it should be interesting whether a read()-write() Python loop is significantly slower than dd
<cjwatson> so, is it just me, or is klibc's chroot.c on crack?
<cjwatson> it does chroot() then execve(), rather than chroot() chdir() execve()
<ogra> pitti, speed doesnt really matter ... i took dd because i know for sure it DTRT and isnt buggy :)
<cjwatson> unlike every other chroot in existence
<ogra> saftey first
<pitti> cjwatson: the chroot(2) manpage claims the same (chdir necessary)
<pitti> ogra: well, for copying 700 MB speed should matter a bit...
<pitti> yay, NEW empty
<cjwatson> right, this is why the crackful PATH=/root/stuff was added to casper, I think
<persia> I have a solution for dd?
<ogra> _MMA_, i wrote that app (including the branding) in less than 8h its only a first shot and was more a fingertraining weekend project .... https://code.launchpad.net/usb-imagewriter has the xcf in the source feel free to do what you like with it :)
<ogra> i'll happily merge branches and patches
<ogra> pitti, really, doe it mater if it takes 4 or 5 mins ? its slow in any case :)
<ogra> *does
<pitti> ogra: no, but it would if it takes 4 vs. 20, that's why I'm curious
<ogra> ah, yeah, indeed
<cjwatson> of course, we could just rip out klibc chroot and use busybox for that instead
<cjwatson> since busybox also correctly uses execvp rather than execve
<Tonio_> pitti: still writing the code.... should be done this WE...
<_MMA_> ogra: Sure. Ill have a go at it.:)  Mind if I mention it on the art list?
<ogra> i not at all :)
<_MMA_> Cool
<nixternal> pitti: I don't know te whole reasoning behind separating pykde4 from the kde4bindings in the past
<pitti> Tonio_: so is it the right thing to use kdesudo-kde4 for alpha-2?
<ogra> _MMA_, my personal plan was to have fun with it, produce something minimally usable and then throw it at the community ;)
<nixternal> Tonio_: do you know why pykde4 was separated from kdebindings?
<pitti> (it's still in Debian, apparently)
<nixternal> it could have been due to the rest of the bindings not being ready in the past
<_MMA_> ogra: Cool. Maybe Ill ask for one with Debian branding also. Maybe it will make it easier to go to them as well.
<ogra> feel free ... we should really make more use of the art team for non desktop art
<ogra> (that struck me yesterday when we were discussing presentations in the mobile meeting)
<ogra> there is so much enthusiasm and so many other areas than the desktop where good artwrok makes sense ... but i only see theme discussions on the artwork ML
<Tonio_> nixternal: no idea concerning pykde4.... I still didn't do much on the kde4 side...
<Tonio_> pitti: yeah we can make use of it right now, except it has a few bugs fixed in the kde3 version, that I have to fix in the kde4 one
<pitti> Tonio_: ok, thanks
<Tonio_> pitti: but as kdesu in kde4 is built without sudo support, we have to use kdesudo in any case
<cjwatson> Tonio_: is it going to be moved to a more sensible filesystem location?
<Tonio_> cjwatson: yeah kde4 will go in /usr afaik
<Tonio_> cjwatson: Riddelll would know more on that point, but moving to /usr was decided uring the UDS
<Tonio_> s/uring/during
<emgent> hello
<Karnaugh> is the startup splash graphics stored in the initrd on the livecd?
<TheMuso> Karnaugh: Yes they are.
<Karnaugh> TheMuso: I see usplash has something to do with it, wandering through the docs for that atm
<TheMuso> Karnaugh: Thats correct.
<Karnaugh> cool that seems quite trival
<Karnaugh> *trivial
<DktrKranz> pitti, I think syncs from bug 247481 and bug 247482 were not processed. Packages left incoming this morning and probably didn't reach mirrors in time.
<ubottu> Launchpad bug 247481 in helpviewer.app "Please sync helpviewer.app 0.3-6 (universe) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/247481
<ubottu> Launchpad bug 247482 in lusernet.app "Please sync lusernet.app 0.4.2-4 (universe) from Debian unstable (main)." [Wishlist,Fix released] https://launchpad.net/bugs/247482
<cjwatson> can we make syncbugbot not close bugs when that happens?
<cjwatson> pitti: so did you promote kdesudo-kde4 in the end? I just made ubiquity depend on it ...
<cjwatson> (I don't seem to have much option)
<ogra> cjwatson, seeing all this effort above, do you actually try to get a desktop CD ready for alpha2 ? (i refrained from adding the compcache stuff to casper because we seemed to have none)
<cjwatson> ogra: Steve seems to want to try, anyway
<cjwatson> and I think it would be good if we could
<doko> pitti, kirkland: how much functionality is going away from ecryptfs-utils when removing the two build-deps?
<kirkland> doko: hey, we were just talking about this with zul on #ubuntu-server
<kirkland> zul: -> move over here
<kirkland> doko: libltspi is a library with support for TPM chips on modern motherboards
<doko> at least we should document that in the MIR
<kirkland> doko: pitti: how about I do that, and ping back here once it's in writing?
<kirkland> doko: pitti: on the other hand, shall I just file the MIR for the other build deps, and only remove the deps if there's a problem moving them to Main?
<doko> yes, at least libltspi doesn't sound like a problem
<kirkland> doko: opencryptoki contains support for some cryptographic accelerator hardware
<kirkland> doko: mostly IBM stuff, I think
<kirkland> doko: might be nice to have on the server
<kirkland> doko: I've already written the MIR for libltspi: https://wiki.ubuntu.com/MainInclusionReportTrousers
<kirkland> doko: no bug filed yet
<kirkland> doko: see the top of that...  we need library out of trousers, but not necessarily the daemons and such (trousers)
<doko> hmm, I don't see a b-d on trousers ..., but on libopencryptoki-dev
<kirkland> trousers provides libltspi-dev
<doko> isn't this chip in the thinkpad notebooks as well?
<kirkland> doko: the TPM (libltspi, trousers) -- yes.   opencryptoki stuff -- no.
<kirkland> doko: although we don't have userspace to exploit it, ecryptfs could use a TPM to cryptographically lock a mounted filesystem to a TPM chip (ie, a particular motherboard/machine)
<kirkland> doko: or using a keyring, a set of machines
<pitti> cjwatson: I did promote kdesudo-kde4, yes
<kirkland> doko: also, it looks to me like opencryptoki would also mean an MIR for freetype1
<pitti> DktrKranz: sorry, reopened
<cjwatson> pitti: ok, cool, thanks
<pitti> cjwatson: kdesudo could be demoted, so that seemed like an adequate deal :)
<doko> kirkland: freetype1 should be avoided
<kirkland> doko: hmm, sorry, i can't find it now...  i swear one of these needed to pull libttf2 for a build dep
<kirkland> doko: and it escapes me
<pitti> cjwatson: I also promoted gtk-qt-engine-kde4 in exchange for gtk-qt-engine (c-mismatches wanted that)
<pitti> cjwatson: but just now, so it will take a while to propagate
<tseliot> pitti: can you upload revision ubuntu5 of the nvidia drivers from my PPA to Intrepid (when you have the time), please? It fixes a bug reported by mdz
<kirkland> doko: okay, trousers (libltspi): https://bugs.launchpad.net/ubuntu/+source/trousers/+bug/247590
<ubottu> Launchpad bug 247590 in trousers "main inclusion request: trousers" [Undecided,New]
<cjwatson> pitti: ok, thanks
<cody-somerville> slangasek, ping
<davmor2> cody-somerville: shhh sleeping ;)
<cody-somerville> ah ;]
<pitti> tseliot: hm, the diff changes some i386 to x84_64 paths again; is that just build noise?
<tkamppeter> Riddell, ping
<pitti> tkamppeter: Riddelll is on holiday, FYI
<tkamppeter> pitt, until when?
<pitti> this week, AFAIK
<tkamppeter> pitti, thank you.
<kirkland> doko: okay, i created a MIR for Opencryptoki too... https://bugs.launchpad.net/ubuntu/+source/opencryptoki/+bug/247593
<ubottu> Launchpad bug 247593 in opencryptoki "main inclusion request: opencryptoki" [Undecided,New]
<tseliot> pitti: I haven't touched the debian/rules and that line is still commented out
<pitti> tseliot: I looked at http://launchpadlibrarian.net/15962949/nvidia-graphics-drivers-173_173.14.09-0ubuntu4_173.14.09-0ubuntu5.diff.gz
<tseliot> pitti: I don't see any reference to rules there.
<pitti> tseliot: but changed paths
<pitti> debian/nvidia-glx-173.examples
<pitti> -NVIDIA-Linux-x86-173.14.09-pkg0/usr/share/doc/XF86Config.sample
<pitti> +NVIDIA-Linux-x86_64-173.14.09-pkg2/usr/share/doc/XF86Config.sample
<tseliot> pitti: the other changes in .sample, etc. were generated automatically and they are harmless
<pitti> same in .docs and copyright
<pitti> tseliot: it sounds like you generated that tarball from the 64 bit download instead of from the 32 bit one?
<tseliot> pitti: I have generated the source with debuild -S on my Intrepid 64 os
<kirkland> doko: okay, i think that's all that's needed for ecryptfs-utils
<kirkland> doko: if we can get libtspi-dev and libopencryptoki-dev into main, we won't have to carry a delta against Debian
<tseliot> pitti: I can apt-get source the version in Intrepid and start from scratch if you wish
<pitti> tseliot: well, I primarily want to understand why a mere package rebuild changes debian/copyright, or debian/*.docs
<tseliot> pitti: I did a dpkg-buildpackage -rfakeroot && debclean in order to test the packages. This changed those files.
<pitti> weird
<tseliot> pitti: such files will change again according to the arch of the machine which builds the packages
<pitti> tseliot: if the orig.tar.gz didn't change, then it looks like that black magic will break the package?
<pitti> debian/*.docs have file paths where to install documentation from
<pitti> so if you change that path to a different directory, it will break
<tseliot> pitti: no, nothing should break. The nvidia-173-kernel-source.docs.in is a template used to generate a .doc file according to the arch when the packages are built.
<tseliot> each path is like #DIRNAME#/usr/share/doc/NVIDIA_Changelog
<tseliot> and DIRNAME changes according to the arch in the upstreaminfo file
<pitti> tseliot: oh, ugh
<pitti> tseliot: ok then
<dholbach> somebody please moderate my 'harvest' post through u-d-a
<dholbach> thanks in advance
<pitti> dholbach: doing
 * dholbach hugs pitti
<pitti> shouldn't you be in India already? :-)
<dholbach> I'll be off in a few minutes
<pitti> dholbach: nothing in the queue yet, I'll look again later
<dholbach> flight is sunday early, but we'll drive to my parents place tonight to drop off the dog there
<tseliot> dholbach: enjoy your vacation then ;)
<dholbach> thanks a lot tseliot
 * pitti hugs dholbach, enjoy your holidays!
<pitti> dholbach: ah, acked now
<dholbach> ROCK
<pitti> tseliot: do you still have the source.changes files somewhere?
<Lrrr> cjwatson: I've fixed my germinate branch as you asked.
<pitti> tseliot: copying the package into intrepid proper is always a pain, since it always goes to main first, and then fails to upload
<pitti> tseliot: so I'd rather upload it the manual way
<pitti> copy-package.py should have a field for the destination component... (the existing option is fairly useless)
 * pitti hugs cprov
<tseliot> pitti: would you like me to upload all the changes and dsc to my website?
<pitti> tseliot: just the .changes are enough
<pitti> tseliot: (the ones matching the .dsc in the ppa)
<tseliot> pitti: yes, of course
<pitti> cprov: filed as bug 247602 now
<ubottu> Launchpad bug 247602 in soyuz "copy-package.py's -c option does not work" [Undecided,New] https://launchpad.net/bugs/247602
<tseliot> pitti: here are the links http://albertomilone.com/ubuntu/newlrm/pitti/links.txt
<pitti> tseliot: thanks; all uploaded
<tseliot> pitti: thanks :-)
<pitti> thanks to you
<cjwatson> Lrrr: thanks; for future reference please use UNRELEASED in the changelog rather than intrepid if you aren't doing the upload
<Lrrr> cjwatson: t-y
<cjwatson> Lrrr: merged
 * freeflying 
<freeflying> sorry, type wrong
<kirkland> anyone familiar with get_current_dir_name()?  http://ubuntu.dustinkirkland.com/manpages/intrepid/man3/get_current_dir_name.html
<kirkland> it should return a char *, but my test program compiles saying that it's returning an int
<sistpoty|work> kirkland: are you defining __GNU_SOURCE?
<kirkland> sistpoty|work: ah, good catch
<kirkland> sistpoty|work: i am not
<sistpoty|work> kirkland: you better should then ;)
<kirkland> sistpoty|work: thanks for the quick silver bullet ;-)
<sistpoty|work> np
<Riddelll> tkamppeter: pong
<tkamppeter> Riddelll, back from vacation?
<cjwatson> kirkland: also sounds like you aren't using -Wall
<Riddelll> tkamppeter: for now
<cjwatson> k.c:4: warning: implicit declaration of function âget_current_dir_nameâ
<tkamppeter> Riddelll, I have filled in the GSoC mid-term questionnaires on your behalf, as pitti told that you are on vacation.
<Riddelll> tkamppeter: oh, great, thanks
<tkamppeter> Riddelll, can you please look at them and edit or correct if you want?
<Riddelll> tkamppeter: ok
<tkamppeter> The most important is that I have answered the last question with "Yes" to assure that the students are not kicked off the projects.
<ogra> oook .... so "pm-suspend -h" suspends my computer .... great !
<ogra> (especially great if you wanted to find out about the available quirks because it hardlocks on resume, *sigh*)
<ogra> (and even better that only root can read the help if --help is used )
<pitti> ogra: manpages FTW then :)
<ogra> well
<ogra> one could have programmed that a bit saner :)
<ogra> grrrr, and i810 support is deliberately disabled
 * ogra wants acpi-scripts back !
<ogra> superm1, do you know who currently maintains dkms ?
<mario_limonciell> ogra, that would be me actually as of a week or two ago
<ogra> (the package, not upstream)
<mario_limonciell> the package, that's also me
<ogra> great, thanks
<mario_limonciell> why?
<alex-weej> who's been hacking on NewHuman?
<alex-weej> i have my 2p to add
<alex-weej> the little stripe at the top of the window frame is way too close to the title text
<alex-weej> feels cramped
<_MMA_> alex-weej: Go to #ubuntu-artwork.
<ramvi> Hi, I'm making Ubuntu eee. I used reconstructor for the last release, but it's not really doing it for me. What's a good way of remastering the ubuntu live iso? What's the "correct" way?
<K^> auto-sync is turned off, or only for alpha-2 release?
<ramvi>  /ignore ramvi
<evand> https://help.ubuntu.com/community/LiveCDCustomization
<evand> ramvi: ^
<ogra> ramvi, i'm abandoning that code soon, but that can be used to build an image for small notebooks https://code.launchpad.net/~ogra/cmpc/cmpc-gen1-installer
<ogra> pfft, to slow
<laga> he wants to customize the squashfs i guess
<K^> Is auto-sync is turned off, or only for alpha-2 release?
<cjwatson> K^: it's turned off. https://help.ubuntu.com/community/Debian/ImportFreeze
<K^> cjwatson: thanks
<cjwatson> and https://wiki.ubuntu.com/IntrepidReleaseSchedule
<cjwatson> K^: by the way, you're evading a ban
<cjwatson> I'd have answered you in /msg if you'd been a little more patient
<K^> cjwatson: I thought you're not here..
<K^> =)
<MeniShevitz> hi all
<MeniShevitz> is this the place for a noob with a umpc to try and get his ubuntu mid groove going?
<MeniShevitz> :)
<Lrrr> what...?
<MeniShevitz> i have a gigabye u60 UMPC and would love to try out ubuntu mid edition
<MeniShevitz> but i haven't a clue where to start
<MeniShevitz> it's a via vx700 c7m machine
<cjwatson> MeniShevitz: #ubuntu-mobile would probably be better
<MeniShevitz> just what i was looking for, didn't see it in the /list :)
<MeniShevitz> thanks cjwatson!
<cjwatson> you're welcome
<mario_limonciell> cjwatson, persia had mentioned that you had initially drafted the proposal that pre-empted bug 134456.  could you comment on the status of the other parts of it, for the UI and for the approval process, what's the plan for now?
<ubottu> Launchpad bug 134456 in soyuz "Soyuz needs package-specific uploaders" [Medium,Fix released] https://launchpad.net/bugs/134456
<persia> I'm not sure about pre-emption, but related.
<cjwatson> mario_limonciell: as persia says, my proposal is related to that and somewhat depends on it, but as far as I know does not block implementation at all
<cjwatson> mario_limonciell: you'd have to ask the Soyuz team about the rest of it
<cjwatson> mario_limonciell: as far as the approval process goes, -> tech board
<persia> cjwatson: Aren't we waiting on the TB to determine how to authorise the per-package stuff as well, even in the absence of a UI?  Alternately, are we at the chicken-and-egg stage?
<cjwatson> (since it's a matter of granting upload privileges)
<cjwatson> persia: snap ;)
<cjwatson> a UI would help; the TB probably doesn't want to authorise things that will require somebody to go and poke at the LP database with psql
<mario_limonciell> cjwatson, so you think just send a request to TB and until TB decides that they are the wrong set of folks to determine who gets rights where, they decide?
<cjwatson> yeah
<persia> Heh.  That's one way to define the process :)  I like to write them up first, but...
<sistpoty> bryce, tjaalton: from current upgrade: are these fixed already? http://paste.ubuntu.com/26713/ (/me is behind a little bit, due to using a german mirror)
<slangasek> cody-somerville: pong
<dirker> Hello, I hope this is the right channel. I'm struggling to port the transmission package from debian to hardy, dh_clean complains that 6 is the highest level it supports.
<dirker> I have already modified debian/control to my best knowledge and now I dont know where to look for further information
<kirkland> dirker: you might do better with packaging questions in #ubuntu-motu, fwiw
<dirker> kirkland: thanks, will try
<savvas> kirkland: seen mvo around? bug 244093 is still waiting approval :\
<ubottu> Launchpad bug 244093 in python-apt "Checking security repository in Updates adds deb line to Third-Party Software" [Undecided,In progress] https://launchpad.net/bugs/244093
<kirkland> savvas: you looking for me, or someone else?
<savvas> kirkland: i think you mentioned in that bug report that mvo (michael vogt?) should take a look at that debdiff code
<savvas> sorry, *in the comments* :)
<kirkland> savvas: nope, that was kees
<savvas> woops
<savvas> i need a new pair of glasses :P
<savvas> ah what the heck, he'll see it sometime
<slangasek> bryce: in https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/245888/comments/12, you write that there's a known issue causing compiz to fail on intel - is that a known compiz or mesa issue? (bug #245823, trying to figure out if the dup'ing was correct)
<ubottu> Launchpad bug 245888 in mesa "Intrepid, on latest updates (mesa updates - 7.1~rc1-0ubuntu1), compiz no longer works and gives white screen on login" [High,In progress]
<ubottu> Launchpad bug 245823 in compiz "[intrepid] After apt-get upgrade, Desktop Effects Cause Blank Brown Screen On Boot (dup-of: 245888)" [High,Confirmed] https://launchpad.net/bugs/245823
<ubottu> Launchpad bug 245888 in mesa "Intrepid, on latest updates (mesa updates - 7.1~rc1-0ubuntu1), compiz no longer works and gives white screen on login" [High,In progress] https://launchpad.net/bugs/245888
<ogra> slangasek, "Blank Brown Screen" sonds a lot more like a gnome-session issue to me than compiz
<slangasek> it's not
<slangasek> everything is started, and killing compiz makes it visible
<bryce> slangasek:  "Compiz shows only black screen on i965"
<bryce>  http://bugzilla.freedesktop.org/show_bug.cgi?id=14441
<bryce>  "full screen is white when use compiz"
<bryce>  http://bugzilla.freedesktop.org/show_bug.cgi?id=15477
<bryce>  (Also see LP: #245888)
<ubottu> Freedesktop bug 14441 in Drivers/DRI/i965 "Compiz shows only black screen on i965" [Normal,Assigned]
<ubottu> Freedesktop bug 15477 in General "full screen is white when use compiz" [Normal,Reopened]
<slangasek> bryce: so, where does brown screen fall into this?  different bug, or same bug? :)
<bryce> heh
<lamalex> slangasek: probably different bugs
<bryce> hmm, in this case if its a different color I'd guess different bug
<slangasek> bryce: so I should un-dupe 245888?
<bryce> looking
<lamalex> the full white/black is probably a graphics driver issue, the brown is GNOME failing to load properly
<ogra> light bron is usually the leftover of gdm and gnome-session being stuck on something... the white compiz screen is different, but indeed the OP says its the same ... so he probably mixed up the colors
<bryce> or he could be confused
<ogra> yeah
<ogra> thats what i first thought
<bryce> I'd say leave it a separate bug, but it needs to be more fully reported - Xorg.0.log, maybe backtraces if there's a crash going on
<slangasek> who could be confused?
<slangasek> note that I confirmed the brown screen bug
<bryce> tenof26
<ogra> .xsession-errors for gnome-session helps too
<ogra> slangasek, but he agreed in his last comment
<bryce> there's a variety of things that break that can lead to the brown screen, so that symptom alone is generally not sufficient for proving dupe bugs.  Usually need an error message or backtrace to be sure
<sistpoty> bryce: FYI reported bug #247681
<ubottu> Launchpad bug 247681 in xserver-xorg-video-r128 "missing conflict against xserver-xorg-driver-ati" [Undecided,New] https://launchpad.net/bugs/247681
<slangasek> bryce: well, I checked for .xsession-errors when I had this, and I don't remember seeing anything at all; and compiz doesn't crash it just never gives me any windows until I kill it; would a backtrace of compiz wherever it is at the time be helpful?
<slangasek> s/don't remember seeing/remember not seeing/
<slangasek> bryce: in the meantime, if this problem isn't affecting you, perhaps you'd like to try an install with the liveCD so that /someone/ is able to validate that it works :)
<bryce> it might; I'm not up on compiz debugging procedures.  You've verified it boots correctly when compiz is disabled I take it?
<slangasek> bryce: how do I disable compiz to verify that? (this is all in the liveCD for me)
<bryce> slangasek: unfortunately my flight is this afternoon so I'm about to head out in an hour
<slangasek> mmk
<ogra> slangasek, boot with textmode option, remove compiz, start gdm
<bryce> hmm, a brute force method would be to chmod a-x /usr/bin/compiz ;-)
<ogra> or that :)
<ogra> cheaper than removing for sure
<slangasek> ogra: is 'textmode' a literal option name?
<lamalex> you don't need to reboot
<ogra> i think so
<lamalex> just control+alt+f1 into a terminal
<lamalex> remove execute from the compiz binary, and then ctrl+alt+f7 back to X and login
<ogra> if zapping works with that bug, yeah, thats an option
<ogra> though i think steve boots the livecd newly anyway
<persia> Or just disable compiz in gconf rather than removing the binaries or chmod -x ing them.
<ogra> persia, gconf on the commandline is painful
<persia> ogra: OK.
<ogra> chmod -x is a very good way if its a livecd anyway i guess
<lamalex> oh this is a cd
<ogra> right and it boots into the bug since it starts a session right away
<lamalex> yeah but cant' you restart X and go back to gdm?
<ogra> probably
<cjwatson> textmode> I think it's 'textonly'
<cjwatson> (cf. bug 65818)
<ubottu> Launchpad bug 65818 in casper "Add support to disable GDM/X configuration and startup." [Low,Fix released] https://launchpad.net/bugs/65818
<ogra> ah, crap my mind tricked me
<ogra> hmm, thats funny ... i have an image build running, run a tail -f on the build log and if i get to mksquashfs i get the percentage bar while building ...
<ogra> if the terminal loses focus the progress just stops
<ogra> (mksquashfs still running though, i can see the image grow)
<ogra> i wonder if thats because of ssh or if its tail's fault
<slangasek> bryce, ogra: disabling compiz before the boot, the desktop comes up fine.  As soon as I enable compiz, that's when things go pear-shaped
<slangasek> bryce, ogra: and .xsession-errors is entirely empty
<ogra> and is it white or brown ?
<ogra> white is compiz acting up with the video driver in any case
<ogra> brown might not necessarily be video related
<slangasek> no, it's brown
<slangasek> as it has been all along for me
<norsetto> infinity: do you think we could do something about bug 225741 ?
<ubottu> Launchpad bug 225741 in mysql-dfsg-5.0 "/usr/bin/mysql_config --libs_r reports incorrect link flags" [Medium,Confirmed] https://launchpad.net/bugs/225741
<slangasek> I get some error output from compiz on the console; let me see if I can save this somewhere
<ogra> slangasek, hmm ... i would rather look in compiz startup procedure then
<sistpoty> ogra: based on a color? :P
<ogra> yep
<sistpoty> heh
<ogra> ;)
<ogra> sistpoty, my therory is that compiz holds up gnome session from starting but that it isnt a video driver vs compiz issue
<YokoZar> kees: *poke*
 * sistpoty just giggle at the hint to bug triagers: for compiz/gnome session bugs, please ask the reporter for the color of the screen
<ogra> heh
<slangasek> ogra: it has nothing to do with gnome-session, compiz breaks the same way if you try to have it replace metacity.
<ogra> ok
<mathiaz> slangasek: I've got a preliminary patch for the cn=config migration for slapd I'd get some feedback on. Should I file a bug in Debian or can I just send it to the pkg-openldap maintainer list ?
<slangasek> mathiaz: sending to the list is fine for starters
<slangasek> (or probably, altogether, unless we end up having to defer it for some reason and need a bug to track it)
<mathiaz> slangasek: I'll send the patch to the list
<kees> YokoZar: heya, what's up?
#ubuntu-devel 2008-07-12
<YokoZar> kees: Do you remember that initial memory access stuff we talked about at UDS-boston?
<YokoZar> kees: I think you looked over my shoulder and saw a bug report ~ Wine and being unable to nab the early memory range (https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/114025)
<ubottu> Launchpad bug 114025 in wine "Problem with wine preloader: Warning: failed to reserve range 00000000-60000000" [Medium,Confirmed]
<YokoZar> Well, now that the kernel change is in Hardy...it's breaking Wine (namely 16 bit apps).  I'm still trying to figure out a good way to fix it without disabling the setting entirely when Wine is installed (I just put out an email to ubuntu-devel) about it.
<YokoZar> kees: Forgive me if I'm confusing you with someone else, by the way ;)
<kees> YokoZar: you've got the right person.
<kees> YokoZar: basically, 16bit apps shouldn't all need that memory space.
<sistpoty> heh, I just wanted to write that this sounds like the crack kees is into ;)
<kees> :)
<YokoZar> kees: I'm not exactly sure how Wine handles that memory space, or if there's some sort of virtual memory workaround upstream could eventually do
<kees> YokoZar: and 32bit apps should almost never need it
<YokoZar> kees: yes, even without the setting running 32 bit apps still works in Wine just fine
<kees> YokoZar: I think it can be worked around, but it's a little painful.  My thought has been that if someone needs to run a 16bit app that actually needs that memory area, just turn off the protections.
<YokoZar> kees: I believe the trouble is Windows never made a proper separation in some instances, and a lot of 32 bit programs will invoke 16 bit instances of things, causing a potential crash in the middle rather than refusal to run outright.
<sistpoty> kees: are we talking about virtual addresses there? if so, any pointer why it's disable in the first place?
<YokoZar> kees: The other trouble, of course, is that it's still hard to turn off protections and we have no easy way of doing it (or, for that matter, figuring out if it will be needed before running the application)
<kees> sistpoty: unfortunately while it is technically virtual (i.e. not mapped to physical location), the kernel and userspace tools use the same memory address space.
<kees> YokoZar: I'm not aopposed to turning it off if someone install wine in general.  Just finding a good way to manage it I think is the key.
<sistpoty> kees: ah thanks
<kees> YokoZar: I think newer procps (the package that does /etc/sysctl.conf) has an /etc/sysctl.d directory now, so maybe we can do something with that.
<YokoZar> kees: Yeah.  my thought was to have an (optional) "turn-it-off" package that turns it back on when removed
<kees> sistpoty: yeah, I find it confusing and slightly alarming, but that's how it is.  :(
<YokoZar> And then have Wine depend (or I guess recommend that)
<sistpoty> kees: I always though kernel would use quite a high address space, but tbh I never looked nor cared *g*
<kees> sistpoty: it does, it uses (on i386) the range from 3 to 4G
<kees> YokoZar: yeah, let me check on procps and get back to you about how we might best approach it.
<YokoZar> kees: Thanks a lot :)
<kees> YokoZar: np, thanks for poking me about it.  :)
<sistpoty> kees: oh, but where is it shared then?
<kees> sistpoty: it's the address space that's shared.  i.e. memory address 0x0 is visible to the kernel.
<kees> so if it gets mapped by a userspace process, the kernel may access it on a NULL deref.
<sistpoty> kees: I, I see, thanks for the insihgt
<sistpoty> (h<->g)
 * kees nods
<emgent> hello people
<tiglionabbit> with python-xml moved, I can't use Gogh.  The workaround isn't working for me
<LaserJock> tiglionabbit: what package is that from?
<tiglionabbit> python-xml
<tiglionabbit> is the package I want to use
<tiglionabbit> Gogh is not in the repositories
<tiglionabbit> https://bugs.launchpad.net/ubuntu/+source/python-xml/+bug/215723
<ubottu> Launchpad bug 215723 in python-xml "[Hardy] ImportError: No module named ext" [Undecided,New]
<LaserJock> ah, that's why I couldn't find it
<LaserJock> :-)
<tiglionabbit> http://www.goghproject.com/
<tiglionabbit> I tried the workaround in the terminal, but I still can't import xml.dom.ext.  What am I to do?
<LaserJock> tiglionabbit: hmm, maybe you could email the gogh author?
<LaserJock> unless some smart Python person has any better ideas
<LaserJock> ScottK: you around?
<tiglionabbit> well, considering it works on any other distribution...
<tiglionabbit> I was hoping there would be a solution to this
<tiglionabbit> I asked in #python and they thought ubuntu was silly for doing this
<LaserJock> hehe
<LaserJock> I don't have any specific knowledge of the python-xml stuff
<LaserJock> but my guess would be that the gogh author might have some idea of what specifically is going on
<cody-somerville> Hey
<tiglionabbit> urk, how do I import this
<pwnguin> well, languages are in motion; if you dont tread water, the project will drown
<pwnguin> drownd
<tiglionabbit> you don't have to throw away code just because it's old
<pwnguin> sure, you can port it forward
<pwnguin> assuming it wasnt built on a philosophy the language depricates
<tiglionabbit> I just want to know how to import it on ubuntu
<pwnguin> i have no specific python knowledge, but often times development stuff is stored in -dev packages?
<cody-somerville> tiglionabbit, If you send me an e-mail I promise to look into the issue for you.
 * cody-somerville has to jet atm.
<tiglionabbit> what's your email?
<pwnguin> somerville32@ubuntu.com?
<cody-somerville> cody-somerville@ubuntu.com
<grandy> hello, has anyone written upstart config for a custom daemon?  just looking for some advice
<pwnguin> Is there a way to query the HW database or ubuntu.com weblogs for information on display sizes and DPI?
<emgent> slangasek: ping
<slangasek> moo
<emgent> slangasek: take a look Bug #247612
<ubottu> emgent: Bug 247612 on http://launchpad.net/bugs/247612 is private
<slangasek> emgent: seen it
<emgent> slangasek: thanks.
<slangasek> emgent: given that all the relevant folks are already gone for the weekend (some of them traveling), I think this will probably wait until Monday
<emgent> i think so
 * emgent love mod-security
* cjwatson changed the topic of #ubuntu-devel to: intrepid alpha-2 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
<cjwatson> (pp Steve, at least as far as I can tell :-) )
<slangasek> oops, yes :)
<halex> win 25
<halex> Oh, grrr.
<jpds> halex: /script exec for (1 .. 200) { Irssi::command("/alias $_ window goto $_") }
<halex> jpds: oh, neat. Danke.
<jpds> halex: Bitte.
<gnomefreak> tseliot: if you are around, why does the new nvidia-glx-173 (im sure not only that version) once modules are built system plays the gnome login sound but never restarts gnome session? is this a bug or a feature?
<tseliot> ï»¿gnomefreak: it's a bug but not in the driver or in the package
<tseliot> and it's not supposed to restart anything
<gnomefreak> tseliot: oh ok thanks. i only notice it after friver update thats why i thought it was nvidia drivers
<gnomefreak> it doesnt restart it but it plays the sound as if you loged in
<tseliot> yes, I know. It would be interesting to find the cause of the problem.
<gnomefreak> tseliot: agreed
<gnomefreak> if i knew what package triggers it than i might beablet to track down the cause but finding the package is hardest part
<bigon> shoudn't v86d be installed by default as it seems to be needed by the uvesa driver?
<cjwatson> bigon: yes, there's a bug on (I think) linux-meta about it
<bigon> oh ok
<cody-somerville> cjwatson, I'm having some trouble regenerating the xubuntu meta package.
<cody-somerville> cjwatson, for some reason it seems to be skipping i386 and amd64, lol
<cjwatson> cody-somerville: can you send me mail describing the problem? I'll certainly look at it
<cody-somerville> cjwatson, thanks
<cody-somerville> cjwatson, odd, I've seemed to have managed to fix it but I'm not sure what I did, lol
<sjoerd> 89/topic
<sjoerd>        
<emgent> good morning
<savvas> if I want to create i386 package using a ubuntu amd64 I just use debuild -us -uc -a ?
<savvas> -ai386 *
<savvas> ?
<cjwatson> savvas: no, not reliably and not without some other setup (32-bit development libraries etc.). It would be better to create an i386 chroot.
 * ogra sighs about ubuntu-users 
<cjwatson> savvas: debootstrap --arch=i386, or pbuilder --debootstrapopts --arch=i386
<wgrant> ogra: Anybody installed XFree86 lately?
<cjwatson> (in the latter case, just at the create step)
<savvas> thanks cjwatson
<ogra> wgrant, nah, a guy who doesnt manage to stop insulting people ... he triggered https://lists.ubuntu.com/archives/ubuntu-users/2008-February/137100.html in feburary and just starts over to call people assholes, wankers and tells then STFU
<ogra> s/then/them/
<wgrant> Oh dear.
<alex-weej> any ideas how i've managed to get a "(now)" available version for a package in synaptic when it isn't even installed?
<alex-weej> i've a feeling something has broken in my dpkg database
<cody-somerville> lovely, the new flash likes to crash my firefox
<laga> how is that different from the old flash?
<cody-somerville> laga, it just rendered transparency as opaque
<cody-somerville> now it crashes
<laga> heh :)
 * highvoltage can't wait for free flash to mature
<alex-weej> it won't happen
<alex-weej> both gnash and swfdec have like 0.1 developers
<laga> adobe needs to.. oh, is this channel logged?
<laga> ;)
<highvoltage> alex-weej: gnash actually has quite a few full-time, paid developers
<alex-weej> but it's GNU
<highvoltage> alex-weej: and recently Adobe has released a substantial amount of free-flash specs
<highvoltage> alex-weej: and?
<alex-weej> and... like... they have beards
<IntuitiveNipple> When versioning for a PPA package upload, should the version number increment? E.g. with package-1.2.3 should it be package.1.2.3~ppa1 or package.1.2.4+ppa1. I ask this because a while back I found that Update was offering to replace installed package-1.2.3~ppa1 with package-1.2.3 but the docs I read at the time didn't make it clear
<tormod> IntuitiveNipple: 1 < 2~ppa < 2 < 2+ppa
<cjwatson> IntuitiveNipple: well, at the risk of stating the obvious, it depends whether you want the PPA to supersede what's in the regular archive or not :-)
<cjwatson> IntuitiveNipple: usually you'd want it to be newer than anything in the release it's targeted for - so if 1.2.3 is in hardy and you're uploading to a hardy PPA, you'd want to use 1.2.3+ppa1, whereas if 1.2.3 is in intrepid and you're uploading to a hardy PPA, you'd want to use 1.2.3~ppa1
<IntuitiveNipple> Thanks... I just found the answer in my launchpad-users mail folder from an email by Martin Schwenke on May 17th... his suggestions now added to the PPAQuickStart guide which, last time I'd looked this up, didn't have his updates
<cjwatson> IntuitiveNipple: try to avoid making it greater than the expected next version in the normal archive
<cjwatson> (hence 1.2.3+ppa1 rather than 1.2.4+ppa1)
<IntuitiveNipple> cjwatson: I was mostly confused because logic seemed to say 1.2.3 < 1.2.3ppa lexically at least
<cjwatson> and you can use dpkg --compare-versions to ask "is this version greater than that version?"-type questions
<cjwatson> IntuitiveNipple: it is - "~" is magic though
<cjwatson> $ dpkg --compare-versions 1.2.3 lt 1.2.3ppa && echo yes
<cjwatson> yes
<IntuitiveNipple> cjwatson: Yeah... hence the confusion... but my main reason for asking is, I'm trying to figure out how to do a custom kernel build on the PPA and get the versioning correct... the prepare-ppa-source does its own thing with the versioning specific for the 'main' kernel PPA
<cjwatson> ah, now, the kernel is kinda weird with versioning
<IntuitiveNipple> Yes, you see now why I'm trying to understand it!
<cjwatson> although bear in mind that prepare-ppa-source may be partially intended for use by Ubuntu kernel team members who are preparing preview versions of the next kernel version along
<cjwatson> personally, unless it was a backport from a later release, I'd just append "ppa1" or "+ppa1" and not worry about it too much
<IntuitiveNipple> Yes, it is, I'm trying to figure out how others have managed to upload and build kernels correctly
<cjwatson> the only real weirdness in the kernel versioning scheme is that it's UPSTREAM-ABI.REVISION
<IntuitiveNipple> the entire kernel source preparation process is different to a regular package
<cjwatson> so as long as you don't screw up ABI then it shouldn't make too much difference
<IntuitiveNipple> yeah.. breaking the ABI is something I'm trying to avoid
<IntuitiveNipple> The bug-fix works! I'm just trying to find a 'nice' way to make it available for testing
<cjwatson> how to seriously confuse yourself by mistake: go to https://launchpad.net/ubuntu/+source/python-gtk2 rather than https://launchpad.net/ubuntu/+source/pygtk
<cjwatson> "uh, hoary? what?"
<IntuitiveNipple> lol yeah... there's a lot of 'legacy' stuff that often confuses me too
<cjwatson> infinity: http://launchpadlibrarian.net/15978774/buildlog_ubuntu-intrepid-hppa.pygtk_2.12.1-6ubuntu1_FAILEDTOBUILD.txt.gz - is xvfb known-broken on hppa?
<savvas> cjwatson: thanks for the pbuilder tip, building with it is increbidly easy and wonderful to manage cleaning up :)
<cjwatson> you're welcome
<savvas> one tiny problem though, could be neglected, but i used "--buildplace ." and it still made the resulting .deb packages in /var/cache/pbuilder/result/
<cjwatson> afraid I don't know, I was just quoting the pbuilder equivalent to what I knew to work for debootstrap
<cjwatson> if you think it's a bug, file it
<savvas> I'll try it again a bit later, thanks
<cjwatson> (I don't actually use pbuilder myself)
<savvas> it's good for a playground :)
<wattazoum> hello everyone
<wattazoum> I am trying to use apport for non Ubuntu package (the project is hosted on Launchpad but not registered on the Ubuntu Distribution) . Is it possible ?
 * bluefoxicy grabs alpha 2 to see if it's got compcache in it, and if it works.
<cody-somerville> bluefoxicy, let me know what you find out
<bluefoxicy> cody-somerville:  have you looked at the code?
<cody-somerville> bluefoxicy, not since UDS
<bluefoxicy> Coming from someone who could never read kernel code like this, it looks like a vanilla block device that self-initializes to swap space but doesn't enforce that.
<bluefoxicy> so, I'll tinker with it.  Then swapoff and put a file system on it :p
<bluefoxicy> also, imagine suspending with this thing active... XD
<bluefoxicy> <kernel> resuming ................... wtf?
<cody-somerville> <g>
<bluefoxicy> (actually in theory it would store the kernel memory for the device somewhere; however, it might realize it's SOMEHOW out of swap space during the suspend process)
<cjwatson> bluefoxicy: ogra tested it and found that suspending with compcache active worked fine
<cjwatson> I assume for hibernate there are the usual constraints of requiring a big enough swap partition
<bluefoxicy> yeah
<bluefoxicy> anyway trying to not kill myself while feeling around for voltage levels inside live high-voltage vacuum tube power amps, ttyl
<ScottK> LaserJock: I'm around for a few minutes now.  More later today.
<bluefoxicy> kernel panic - not syncing, attempt to kill the idle task!
 * bluefoxicy rolls back to -17 in Hardy in virtual box so he has vboxadd.ko, because without it the damn thing locks up X on the host as soon as he starts playing a video.
<cody-somerville> Can someone block the flash update? Firefox is crashing like crazy :/
<savvas> in backports?
<savvas> looks like i'm the only one not using backports :)
<cody-somerville> savvas, seems like it :P
<savvas> cody-somerville: sudo aptitude forbid-version flashplugin-nonfree :P
<savvas> a person in ubuntuforums said that he was having problems with a flash site, and claimed backports were great and ok, when he reverted back to version 9 i had a good laugh when he said it was fixed :)
<LaserJock> ScottK: nvm, it was a python-xml question somebody had last night
<cody-somerville> There doesn't seem to be a regression policy for backports
<cody-somerville> Should I just e-mail the TB like I would an SRU?
<LaserJock> cody-somerville: I'd just talk to jdong or another backporter
<cody-somerville> jdong, hey you :P
<cody-somerville> Ugh... the phone calls have started :(
<LaserJock> cody-somerville: dude, it's backports, it's expected to not work much of the time :-)
<cody-somerville> LaserJock, Thats absolutely untrue
<cody-somerville> On the wiki page it says:
<cody-somerville> "A great deal of work goes into testing backports and it's highly unlikely for a backport to be a severe regression from the version it replaces."
<cody-somerville> And I'm looking at the bug report for the backport (haven't read it all yet) but even before it was uploaded there were reports of the crashing.
<LaserJock> right, well, that's why I don't run it
<cody-somerville> Furthermore, the status of the bug doesn't indicate it was approved but I should know what happened in a second - lots of comments to go through
<LaserJock> my understanding is that when you run development release packages on the stable release you should expect it to run roughly like the development release
<tritium> cody-somerville: /etc/apt/sources.list words it differently
<cody-somerville> tritium, what are you trying to say?
<tritium> cody-somerville: what you pasted said a great deal of work goes into testing, whereas /etc/apt/sources.list contradicts that.  I'm not trying to say anything.  I'm pointing out the difference.
<cody-somerville> tritium, Well, it almost seemed like you were suggesting that the comments in /etc/apt/sources.list would be common knowledge
<tritium> cody-somerville: nope, I wasn't suggesting anything
<LaserJock> well, presumabely they should be
<cody-somerville> LaserJock, why would a user (for the common use case) read the contents of /etc/apt/sources.list over /user/include/getopt.h ?
<LaserJock> I'm not saying they should read it
<LaserJock> but *presumably* what is in sources.list should be common knowledge and consistent with what people are documenting
<cjwatson> so is the problem that libflashsupport is in -backports?
<LaserJock> i.e. sources.list should represent a fairly canonical source of information on the repos
<cjwatson> seems to be what bug 235135 suggests
<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
<cody-somerville> cjwatson, no, I don't think so
<cjwatson> cody-somerville: so is Alexander wrong in that bug?
<cjwatson> hmm, seems to be inconsistent between users
 * cody-somerville nods.
<cjwatson> ScottK: should I remove flashplugin-nonfree and libflashsupport from -backports? I've only skimmed the bug and would like your say-so
<cjwatson> ScottK: note that the only way to deal with users who have already upgraded is to upload a higher version, though
<cjwatson> so this is purely prophylactic
<cody-somerville> cjwatson, In his e-mail to -devel he says yes
<cody-somerville> "I am aware (I approved the backport) and as soon as I get somwhere that
<cody-somerville> lends itslef to a stable IRC presence (less than an hour) I intend to hunt
<cody-somerville> down an archive admin and deal with it."
<cody-somerville> Well... I suppose thats not exactly what he says, heh.
 * cody-somerville is off to take a nap.
<cody-somerville> Oh, luckily it appears Firefox already has a patch :)
<YokoZar> cjwatson: can I trouble you to take a peak at https://bugs.launchpad.net/bugs/246118  ?  It got tagged verification-done but hasn't hit the archive yet
<ubottu> Launchpad bug 246118 in wine "Wine 1.0 as a stable release update for Hardy" [Undecided,Fix committed]
<ScottK-laptop> Is there an archive admin in the house?
<cjwatson> ScottK: hi
<cjwatson> ScottK-laptop: you too
<cjwatson> ScottK-laptop: so what should be done with flash?
<ScottK-laptop> Hello
<ScottK-laptop> My intent (if you agree) is to upload the hardy release versions to backports with a higher number so users naturally upgrade back to where they were.
<ScottK-laptop> i.e. libflashsupport-1.9-0ubuntu2~hardy2~really1.9-0ubuntu1
<cjwatson> ScottK-laptop: I think that's theoretically the best action, although the version number is going to be truly unfortunate
<ScottK-laptop> Yes.
<ScottK-laptop> I need a little time for testing.
<cjwatson> just libflashsupport, or flashplugin-nonfree too?
<ScottK-laptop> Both
<cjwatson> more confusing for the latter, really
<ScottK-laptop> nixternal reported that removing libflashsupport was not sufficient
<cjwatson> 10.0.1.218+10.0.0.525ubuntu1~hardy2~9.0.124.0ubuntu2? oh man
<ScottK-laptop> Yep.
<ScottK-laptop> I don't see a better option though.
<cjwatson> can we do hardy1+really, at least?
<ScottK-laptop> OK.
<cjwatson> just to reduce ~-confusion
<ScottK-laptop> Fair enough.
<cjwatson> no, I don't see a better option either - I said something similar above, but you may have been offline
<cjwatson> 20:32 <cjwatson> ScottK: should I remove flashplugin-nonfree and libflashsupport from -backports? I've only skimmed the bug and would like your say-so
<cjwatson> 20:32 <cjwatson> ScottK: note that the only way to deal with users who have already upgraded is to upload a higher version, though
<cjwatson> 20:33 <cjwatson> so this is purely prophylactic
<ScottK-laptop> Will you be around for a bit so I can ping you after I've tested.
<cjwatson> ScottK-laptop: so, I'm about to be away for a week, so I'd like to go spend some time with my wife
<cjwatson> ScottK-laptop: estimated time?
<ScottK-laptop> ~30 minutes?
<cjwatson> ok, I can check back in then
<ScottK-laptop> Great.  Thanks.
 * ScottK-laptop gets to work...
<cjwatson> YokoZar: done
<YokoZar> cjwatson: *hugs*
<ScottK-laptop> cjwatson: They are both waiting for approval.
<ScottK-laptop> 27 minutes instead of 30.
 * ScottK-laptop tries to remember what he had planned to do with this free time with a laptop and wifi.
<cjwatson> ScottK-laptop: accepted, thanks
<cjwatson> if they build before :55, they'll be published by about 90 minutes from now
<ScottK-laptop> cjwatson: Thank you.  Have some good time with your wife.  I'll keep an eye on them.
#ubuntu-devel 2008-07-13
<crimsun> asac: RE: 245122, both libnspr4 and libnss3 have epochs, so you'll need to adjust the versioned C+R
<ScottK> We had discussed getting the patch in mozilla Bug 440840 in after mozilla had approved it.  They have now.
<ubottu> Mozilla bug 440840 in File Handling "mailcap handling may fail due to race conditions between thread waiting and system()" [Normal,Resolved: fixed] http://bugzilla.mozilla.org/show_bug.cgi?id=440840
<ScottK> asac: ^^^
 * nxvl waves
<ogra> ScottK, what did the libflashsupport package in backports contain ? it should have only been a transitional package (if flash 10 even has it as dependency which i dont think and which shouldnt be)
<ogra> (it shouldnt be installed alongside flash10 )
<crimsun> ogra: it wasn't transitional; it contains a conflicts with hardy's flashplugin-nonfree to force being removed with Flash 10 betas
<asac> crimsun: indeed. how could i have missed that :(
<Bubulle> hello, is that a good place to discuss the proposed-updates branch of Ubuntu?
<Bubulle> A new firefox package was pushed to Hardy proposed-updates last night. Unfortunately, I discovered it removed french localized firefox3 without notice. Updates should not remove components unless it is replaced by very same fonctionnality.
<laga> Bubulle: i suggest you look at the changelog of that firefox. there should be a bug report number in there for the last upload. go to that bug report and post a comment there
<asac> Bubulle: you shouldn thave run dist-upgrade
<asac> err, sorry. which version does your language-pack-XX have?
<Bubulle> just regular update pulled it from proposed-updates. I now I did enable the proposed branch to test new versions without jumping to the ubuntu devel branch. I just like to make it know that, sometimes it can break things :)
<Bubulle> language-pack-fr 1:8.04+20080527
<asac> too bad
<asac> Bubulle: i thought the language pack bump was done long time ago
<asac> Bubulle: get your lang pack from https://edge.launchpad.net/~ubuntu-langpack/+archive
<asac> ffox obviously will have to wait for that getting uploade
<Bubulle> The firefox upgrade that pulled out french localization is 3.01+build1+nobinonly-Ubuntu0.8.04.1
<asac> i am aware of that
<asac> thats all ok. its just that the langpacks were forgotten to be uploaded
 * wgrant would like to point out that -proposed is permitted to break things - that's the point.
<asac> right.
 * Bubulle agree
<asac> well. at least temporarily ;)
<asac> ArneGoetje: can you please get the langpacks updates in as soon as possible?
<Bubulle> I know about the proposed-updates risks of breaking things. I know I may help with feedback on purose as well :)
<asac> Bubulle: thats fine. thanks for the update
<asac> if you want to get lang packs now use the langpack PPA i posted above
<Bubulle> asac, just did it. As it is installed outside of repos, will it update next time?
<asac> Bubulle: should work.
<Bubulle> got version 20080708, and should I upgrade language-pack-xx-base to match?
<asac> Bubulle: shouldnt hurt
<Bubulle> Got back french locale on my Firefox. Many thanks for the tip.
<emgent> heya
<Rocket2DMn> question for you all, i'm triaging bug 248163 but before i go through and mark it as triaged/critical, i need to know that i'm not missing something very obvious
<ubottu> Launchpad bug 248163 in ubuntu "Network menu item missing in Intrepid Alpha 2" [Undecided,New] https://launchpad.net/bugs/248163
<Rocket2DMn> has this been intentionally removed?  if so, what is its replacement?
 * ScottK-laptop has a hard time imagining a missing menu item being critical regardless.
<Rocket2DMn> i understand, but it won't load from terminal either, running network-admin doesnt work
<ScottK-laptop> Then at the very least the bug needs a better title.
<Rocket2DMn> so there is only the applet for configuring the network
<Rocket2DMn> i agree, i didnt file the bug report though
<nxvl> hi
<nxvl> is there any build admin here?
 * ScottK-laptop is a Kubuntu user/dev so has no actual opinion on Gnome problems.
<Rocket2DMn> i guess i can mark it as High importance if you think Critical is too much.  Having network control seems critical to me though, but you're the devs in here
<Rocket2DMn> can somebody please help me confirm that this is actually a bug and wasn't done on purpose?  it just seems a rather large problem to be an accident
<ScottK-laptop> There is still a way to do it, right (via the applet)?
<Rocket2DMn> nm-applet is still there
<ScottK-laptop> I'd say High at most since there's still A way to do it.
<Rocket2DMn> alright, Triaged/High it is
<Rocket2DMn> ok thanks ScottK , it is done
<hunger> Could somebody please look into getting the fix from https://bugs.launchpad.net/debian/+source/cmake/+bug/239451 into intrepid?
<ubottu> Launchpad bug 239451 in cmake "ccmake missing?" [Unknown,Fix committed]
<hunger> Thanks!
<nxvl> pitti: around?
<nxvl> pitti: we have a little doubt in pbuilder's FTBFS issue
<nxvl> pitti: and you make help
<nxvl> geser and i have investigated on the source of the problem
<nxvl> and it's that texlive-xetex (main) depends on dvipdfmx (universe) which make it fail to build
<nxvl> also i have researched
<nxvl> and the why of this dependency is described here: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430373
<ubottu> Debian bug 430373 in texlive-xetex "texlive-xetex: no configuration file for xdvipdfmx (was: Accessing mathmatics symbols within XeTeX)" [Normal,Closed]
<nxvl> so i think moving to recommends will be enought for fixing the issue, but also a MIR may be what it's needed
<nxvl> pitti: what do you think?
<ScottK-laptop> nxvl: If you move it to recommends, it still needs a MIR.
<nxvl> i hate the install-recommends-by-default change
<nxvl> it such a PITA
<nxvl> it will need a MIR for tetex-base too
<geser> isn't tetex gone?
<geser> nxvl: if I looked correctly all (build-)dependencies are already in main
<nxvl> geser: i'm talking about dvipdfmx dependencies
<geser> nxvl: me too
<jcristau> nxvl: texlive-base-bin is in main
 * nxvl rechecks
<nxvl> mm weird, now it says it is
<nxvl> ok, so we just need a MIR for dvipdfmx
 * nxvl starts writing
<geser> thanks
<nxvl> ScottK-laptop: where is the MIR writing doc?
<nxvl> ScottK-laptop: did you have it on hand?
<ScottK-laptop> Yes.
 * nxvl HUGS ScottK-laptop 
<nxvl> ScottK-laptop: can you give me the link please :D
<ScottK-laptop> Yes.  Was getting.
<geser> https://wiki.ubuntu.com/MainInclusionProcess
 * ScottK-laptop hands nxvl https://wiki.ubuntu.com/MainInclusionProcess
<ScottK-laptop> ;-)
<nxvl> :D
<nxvl> geser: thank you!
<nxvl> ScottK-laptop: you too!
<ScottK-laptop> nxvl: After you get that one done, please do some on https://wiki.ubuntu.com/ClamavSpamassassinInMain
<nxvl> ScottK-laptop: yes, it's on my ToDo
<nxvl> ScottK-laptop: and about to reach the top
<ScottK-laptop> Great.
<pitti> nxvl: dvipdfmx appears in component-mismatches; right, it just needs an MIR
 * ScottK-laptop waves at pitti.
<nxvl> pitti: :D
<nxvl> pitti: thank you
<pitti> hey ScottK, greetings from London
<stgraber> hey pitti, how's London ?
<pitti> stgraber: sunny, surprisingly :)
<pitti> it was raining heavily in Dresden when I left
<ScottK-laptop> Doesn't it always rain in Dresden?
<pitti> now I'm VOIPing a bit and catch up with some mail
<pitti> ScottK-laptop: no, that was London :)
<ScottK-laptop> See you later.
<stgraber> pitti: also raining here so I wondered if London would then be in some kind of storm :) As they get worse weather most of the time.
<hunger> pitti: Could you sync cmake from debian/unstable? The ubuntu deb is missing a rather important binary (ccmake) which is in the debian package.
<hunger> pitti: See bug #239451
<ubottu> Launchpad bug 239451 in cmake "ccmake missing?" [Unknown,Fix committed] https://launchpad.net/bugs/239451
<pitti> hunger: that cmake is in intrepid, so the bug should be fixed?
 * pitti checks
<pitti> ah, it's not, pending in Debian
<pitti> hunger: so we should sync when it's fixed in Debian
 * pitti -> off, cu tomorrow
<hunger> pitti: Just got the debian sources from cmake 2.6.0-4 and build them: The generated deb does contain ccmake.
<hunger> pitti: That is why I suggested syncing it.
<hunger> pitti: It does not contain cmake-gui... but that is a different matter;-)
<ScottK> hunger: The bug is still marked pending in Debian, not fixed.
 * hunger checks the bugtracker.
<hunger> ScottK: I do have the deb installed and I definitely have ccmake!
<ScottK> Odd.
<hunger> ScottK: With "the deb" I am referring to the debian sources version 2.6.0-4.
 * ScottK just checked the bug tracker.
<hunger> ScottK: Well, the debian bugtracker says that the source builds do work fine... seems to be a problem with the buildsystem?
<ScottK> Note that 2.6.0-4 was uploaded to Debian before that bug was filed.
<ScottK> And debian/changelog in -4 has nothging to do with it.
<hunger> ScottK: Seems like the dependencies are broken... My ccmake is linked against libncurses while the build-dep is libncursesw...
<hunger> I guess I just happen to have some working ncurses around when doing debuild:-)
<ScottK> This is mentioned in that bug too. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=481392#15
<ubottu> Debian bug 481392 in cmake "cmake: missing ccmake" [Normal,Open]
 * hunger grumbles that the debian maintainer is not moving... last entry in that bug is may 24th.
<hunger> cmake is essential for kde4 work:-(
<Nafallo> meeh
<Nafallo> I read coke rather than cmake :-P
 * laga hands Nafallo some pepsi
 * Nafallo gives the pepsi backs to laga and asks for some coke instead
<Nafallo> :-)
<cody-somerville> Nafallo, a coke or some coke? : P
<laga> some coke, of course. 330ml is a common serving size here
<cody-somerville> laga, odd, they measure it in grams here :P lol
<Nafallo> cody-somerville: are there a difference? :-)
<Nafallo> dooh
 * cody-somerville fails.
<Nafallo> cody-somerville: some cans of coke ;-)
<Nafallo> cody-somerville: http://www.kitti.co.uk/wp-content/uploads/2007/04/failed-please-die.jpg ? ;-)
<cody-somerville> lol
<Nafallo> I need to print that one in A4 or something and put up on some wall somewhere :-)
<cody-somerville> In other news, I think you should see this: http://youtube.com/watch?v=EwL0G9wK8j4
<johanbr> Reminds me of the time I was standing in the soft drink aisle at Safeway and my friend proudly proclaimed "I'm a coke addict." :)
 * Nafallo clives
<Nafallo> lol. funny add :-P
<Nafallo> ad even
<cody-somerville> Nafallo, This one impressed me: http://youtube.com/watch?v=PLHjT5-XM9o
<cody-somerville> Nafallo, There seems to be a number of nice linux commercials/ads on youtube.
<Nafallo> I can imagine :-)
<Nafallo> wow. that one is awesome.
<Nafallo> I need to facebook that one.
<cody-somerville> :)
<__stress___> ï»¿I ï»¿ accidentally deleted some of my /home/"user" config files and now when I type "sudo any_command" and "tab" the command so that it can be auto-completed it does not complete....otherwise when I just type the comand and tab it, it auto-copletes...what can I do?
#ubuntu-devel 2009-07-06
<lifeless> RAOF: so, is there a bug yet ?
<RAOF> lifeless: About GTK?  Um, no.
<RAOF> Let me fire up gdb.
<lifeless> step 1, file a bug on launchpad.
<lifeless> step 2, look at the gtk+2.0 package
<lifeless> RAOF: bug 391398
<ubottu> Launchpad bug 391398 in gtk+2.0 "Applications segfault with gtk+ version 2.17.2 when selecting listbox values" [High,Confirmed] https://launchpad.net/bugs/391398
<RAOF> Yeah, just found that.
<RAOF> I'll see if my backtrace is anything not already there.
<danny1> i need help connecting my home wireless to ubuntu. can anyone please help me
<RAOF> danny1: #ubuntu is where you want to be.  If that's too noisy, launchpad answers or Ubuntuforums are good places for support.
<danny1> okay. thank you
<ebroder> What happened to /udev/vol_id in karmic?
<ebroder> Err.../sbin/vol_id
<ebroder> What's the best next step for bug #395321?
<ubottu> Launchpad bug 395321 in xen-3.3 "incomplete patch to curses module in python2.5" [Undecided,Invalid] https://launchpad.net/bugs/395321
<ebroder> Subscribing ubuntu-main-sponsors?
<ajmitch> yes, at least for the karmic stage
<ebroder> Is that better than trying to get doko's attention?
<ajmitch> could be, I'm not sure how busy he is
<ebroder> (debian/control has a Vcs-Bzr of LP:~doko/python/pkg2.5)
<ajmitch> subscribing the sponsors team is the usual route for getting the fix in, at least
<ebroder> I guess I'm just not clear on how the procedure changes when a package seems to have an owner in Ubuntu
<ScottK> ebroder and ajmitch: As I understand it, doko is on a 6 month rotation with Canonical OEM services so doesn't have a lot of Ubuntu time at the moment.
<ajmitch> ScottK: ok, that'll explain why I haven't seen him around as much :)
<ebroder> ubuntu-main-sponsors it is, then :)
<ebroder> Thanks, ScottK
<ajmitch> the patch looks small enough to review quickly
<ebroder> Is there a known issue with ifup and /var/run/network/ifstate?
<ajmitch> I haven't heard of any
 * ebroder sighs. Time to go digging
<ajmitch> karmic?
<ebroder> Yeah. I'm getting "ifup: failed to open statefile /var/run/network/ifstate: No such file or directory" when I try to ifup eth0
<ebroder> This is also a Xen dom0, though - I can't tell yet if that's affecting things
<ajmitch> odd, I see some mentions of it in the ifenslave changelog (from a google search)
<ebroder> (the issue is that /var/run/network/ doesn't exist)
<ajmitch> it exists on my karmic machine that I rebooted yesterday, fwiw
<ebroder> i'll try without the Xen hypervisor
<ajmitch> my karmic box is also a desktop, so it runs NM which fiddles with that file
<ebroder> Huh - doesn't happen when I'm not running with Xen
<ebroder> Probably has something to do with how Xen plays dumb games with bridges
<ajmitch> that would be strange
<ebroder> Xen renames eth0 to peth0 at boot, and then creates a bridge called eth0 and adds peth0 to it
<ebroder> It's kind of gross, really, but so is all virtualized networking
<ajmitch> more than just a bit messy
<ebroder> And...that time it seemed to come up fine. I <3 software
<ebroder> Or maybe update-grub just didn't put the Xen entry back in
<ebroder> So yeah, if I run under the Xen hypervisor, then ifup eth0 fails because /var/run/network doesn't exist
<ebroder> But this doesn't happen if I run the normal karmic -server kernel
<Sarvatt> thats been around since jaunty, made me scratch my head for some time trying to figure it out
<Sarvatt> i had to add [ -d /var/run/network ] || mkdir -p /var/run/network to my /etc/init.d/networking script on my openvz vps
<ebroder> Sarvatt: Did you ever figure out what's supposed to create /var/run/network?
<Sarvatt> udev which is disabled
<Sarvatt> in my case
<Sarvatt> /etc/init.d/loopback used to create it but they moved it
<ebroder> Looks like I'm running udev
<Sarvatt> /lib/udev/rules.d/85-ifupdown.rules now
<Sarvatt> it was real fun debugging that one remotely :)
<ebroder> I guess this is more or less bug #367171
<ubottu> Launchpad bug 367171 in ubuntu "/var/run/network not created soon enough" [Undecided,New] https://launchpad.net/bugs/367171
<ebroder> Oh wait...I think this is kernel version incompatibility for me or something
<ebroder>  * Starting kernel event manager...
<ebroder> error getting signalfd
<ebroder> udevd[3412]: error getting signalfd
<ebroder> Aha - "To be able to use signalfd(), udev depends on kernel version 2.6.25 now."
<Sarvatt> just stick that command in /etc/init.d/networking on a new line after start)  :D
<ebroder> That works, but it's a terrible fix
<ebroder> Ugh. I think at this point I'm just going to give up on maintaining Xen in anything after Hardy
<alkisg> asac: hi - just notifying that I'll be here for the next hours, in case you want feedback on this: https://bugs.launchpad.net/bugs/391040
<ubottu> Ubuntu bug 391040 in network-manager "When eth0 is unmanaged, system connections for other NICs aren't displayed nor used" [Medium,Triaged]
<hyperair> fta: thunderbird-3.0 ftbfs, just to let you know =p
<billybigrigger> is there a gnome-do ppa on launchpad that anyone is aware of?
<billybigrigger> errr
<billybigrigger> gnome shell i should say
<Sarvatt> ubuntu-desktop
<billybigrigger> say again?
<Sarvatt> the ubuntu-desktop team ppa
<billybigrigger> http://ppa.launchpad.net/ubuntu-desktop
<billybigrigger> ?
<Sarvatt> launchpad.net/~ubuntu-desktop.....
<billybigrigger> ahh, i see it
<billybigrigger> http://ppa.launchpad.net/ubuntu-desktop/ppa/ubuntu/pool/main/g/gnome-shell/gnome-shell_0.0.1~git20090702-0ubuntu0.1_amd64.deb
<billybigrigger> is anyone running this on karmic yet?
<billybigrigger> i've never seen a 0.0.1 package before :P
<Sarvatt> yep
<Sarvatt> you're not going to be  able to just install a deb for it though
<billybigrigger> oh
<Sarvatt> need the other things in there
<ion> Itâs not even 0.0.1, itâs 0.0.1~ :-P
<TheMuso> 8/c
 * ion tries to parse the emoticon
<mcasadevall> *sigh*
<mcasadevall> Is there a good way to get a crash-report on apport when it segfaults?
<mcasadevall> ^-- pitti
<fabbione> soren: ping?
<pitti> Good morning
<pitti> mcasadevall: you mean when apport segfaults? it should catch its own segfault; if that happens recursively, you lose, though
<StevenK> Morning pitti
<mcasadevall> pitti, I lost :-/
<pitti> mcasadevall: python crashes?
<mcasadevall> pitti, I posted a crash report from another machine, but I haven't bothered to setup a retracer on the ia64 porting box yet
<pitti> mcasadevall: /var/log/apport.log?
<mcasadevall> pitti, looks like it
<mcasadevall> pitti, empty
<pitti> mcasadevall: you could /etc/init.d/apport stop, ulimit -c unlimited, and call it from a shell (if it crashes that way, too)
<mcasadevall> pitti, yeah, it did, I submitted that crash report
<pitti> mcasadevall: it doesn't crash in gdb?
<mcasadevall> pitti, I haven't setup the ddebs yet to try it
<mcasadevall> (the last dist-upgrade hosed gdm on me, I'm trying to fix that first)
<mcasadevall> pitti, mind looking at https://bugs.edge.launchpad.net/ubuntu/+source/libpango-perl/+bug/388980 (I can't request a sync on libgtk2-perl until this goes through)
<ubottu> Ubuntu bug 388980 in libpango-perl "Main Inclusion for libpango-perl" [Undecided,New]
<StevenK> mcasadevall: Or we demote libgtk2-perl?
<pitti> mcasadevall: is ubuntu-mir subscribed? I don't have mail for it
<mcasadevall> pitti, ubuntu-mir is subscribed
<geser> good morning
<mcasadevall> StevenK, then we loose libgnome2-perl in main (I think)
<pitti> done
 * StevenK grumles at how mcasadevall didn't use the MIR template.
<mcasadevall> StevenK, I was given permission by pitti not to when I filed the bug
<mcasadevall> pitti, StevenK, https://bugs.edge.launchpad.net/ubuntu/+source/libgtk2-perl/+bug/372106 - care to process the sync request ;-)
<ubottu> Ubuntu bug 372106 in libgtk2-perl "Sync libgtk2-perl 1:1.220-2 (main) from Debian unstable (main)." [Wishlist,Confirmed]
<pitti> mcasadevall: will be done during normal archive day batch processing
<mcasadevall> sweet
<mcasadevall> ugh
<mcasadevall> I think GDM broke because the xubuntu-artwork package is hosed on ia64
 * mcasadevall grumbles
<dholbach> good morning
<mcasadevall> morning dholbach
<dholbach> hi mcasadevall
<mcasadevall> how goes it dholbach
<dholbach> good good - how 'bout you?
<geser> Hi dholbach
<NCommander> dholbach, trying to figure out why GDM is hanging on ia64
<dholbach> hey geser
<NCommander> (and why python is broken; I think I need to setup an ia64 apport retracer at some point ...)
<dholbach> NCommander: good luck! :)
<NCommander> dholbach, indeed. I'm hoping to have both desktop and server CDs for ia64 building today actually, and be releasable with karmic again
<NCommander> (SPARC server is also something I'm working on as well, I still need to dehose its kernel)
<StevenK> NCommander: It's kernel needs cryptoloop enabled, and then it will probably build
<NCommander> StevenK, the sparc64 config is very sparse; I think its just a defconfig. I need to sitdown and fix that
<NCommander> Then I need to talk with the kernel team with transitioning the ia64 and sparc, and powerpc kernels to remove the -smp variants, and going to -generic
<NCommander> (and what we want the min. requirements for ia64 to be, ATM, it needs an Itanium2 processor or greater, but thats because the kernel built requiring that)
<StevenK> NCommander: And Colin, since d-i will need to be fixed.
<NCommander> StevenK, d-i was only broken due to a bug int he kernel packaging that caused kernels to be installed uncompressed
<StevenK> NCommander: If you change the names, d-i needs to know
<NCommander> StevenK, oh, right (and the seeds, and a bunch of other crap.)
<NCommander> Ugh
<NCommander> That's why I want to fix everything before I start playing transition the ports kernel
 * StevenK finds himself using the word 'handwave' in an MIR again
<NCommander> StevenK, do you plan to use Ubuntu on your SPARC box if it gets to the point where its installable again?
<StevenK> NCommander: My Sparc box has been decomm'd and is sitting in a corner, powered off
<NCommander> oh
<NCommander> that answers that
 * NCommander wonders if he's the only one to use Ubuntu/ia64 as a desktop OS ...
<StevenK> It's a fairly slow thing, but I could be convinced to fire it up
<NCommander> My sunfire is a freakign antique
<NCommander> :-/
<StevenK> It's an Ultra5, and has (ugh) non-DMA IDE
<NCommander> Bah, even my Ultra10 is newer than that
 * NCommander has an Ultra 10, Netra T1, Netra X1 (which I think has a faulty processor and a sunfire v120)
 * TheMuso winces at StevenK's sparc having non-DMA IDE.
<NCommander> the sunfire is freaking load though
<NCommander> TheMuso, BTW, any luck w/ running down the issues w/ powerpc?
<TheMuso> NCommander: No, I didn't look at it on the weekend. I don't know where to continue looking.
<NCommander> TheMuso, We need to get the xserve's in the data centre updated to hardy :-/
<NCommander> The problem is that the last time that was tried, the machines themselves panicked
<Ryan52> NCommander: hm...libgtk2-perl's tests are still ran, you know that, right? just a few of the tests are disabled.
<NCommander> Ryan52, ?
<NCommander> And powerpc defaults to power off when power cycled
<TheMuso> NCommander: Yeah, but we kinda need something more short term I think.
<NCommander> TheMuso, *sigh*
<NCommander> TheMuso, let me go poke infinity, maybe he has an idea, or I can beg him to update the userland and pin the kernel
<Ryan52> NCommander: your sync request made it sound like you didn't know this.
<NCommander> Ryan52, the changelog you posted for the Debian upload said they were disabled :-/
<Ryan52> I said "disable the failing tests"
<Ryan52> I didn't say "and disable the suceeding ones too"
<Ryan52> :)
<Ryan52> NCommander: so if you do need special xvfb flags, you still need to patch.
<Ryan52> NCommander: or you can ask nicely and I integrate it into my rules file too so that you don't have to maintain the patch...whichever way you prefer. :P
<NCommander> Ryan52, when I test built -2 on all architectures, it successfully built
<NCommander> Ryan52, so no patch is needed as of yet :-) (I remember I pinged you on this in d-perl awhile ago, then found out it wasn't needed)
<Ryan52> then I guess you don't need special options to xvfb-run anymore. *shrug*
<Ryan52> okie doke.
 * RAOF would really prefer it if gdm didn't keep logging him out seemingly at random.
<StevenK> RAOF: "Feature"
<Hobbsee> RAOF: yeah, so would I!
<Hobbsee> at least it respawns
<RAOF> StevenK: "Any sufficiently obscure bug is really a feature"?
<TheMuso> thats consolekit I think.
<TheMuso> Or is it not...
<RAOF> Whatever it is, it seems like it _might_ be triggered by excessive typing.
<RAOF> Just the trigger you want for a dataloss bug!
<TheMuso> Well thats not quite what happens for me. I start a session, then randomly I loose my session, have to log in, and then it doesn't crash again for the rest of the session until I restart.
<soren> fabbione: Dude!
<fabbione> soren: hey man
<fabbione> soren: got a minute or 5 for an old fart^friend? ;)
<soren> fabbione: Sure. What's up?
<fabbione> soren: need some help with hardy kvm :/
<pitti> bryce: could you please check bug 377090 again? Eric says that the userspace tasks are not fixed yet
<ubottu> Launchpad bug 377090 in linux "[i945gm] (Needs kernel 2.6.31) DRI2 swapbuffers" [High,Fix released] https://launchpad.net/bugs/377090
<daurnimator_> hi all
<daurnimator_> how to make a package and get it included in ubuntu repos?
<pitti> daurnimator_: https://wiki.ubuntu.com/PackagingGuide
<pitti> daurnimator_: and https://wiki.ubuntu.com/MOTU/Packages/REVU for getting it into Ubuntu
<\sh> moins
<Hobbsee> RAOF: where "excessive typing" is "two charactes, but only sometimes".  I seem to keep triggering it by typing on irc.
<wgrant> Hobbsee: Same.
<wgrant> It seems to particularly like doing it in the first couple of minutes of my first session.
<wgrant> And there's nothing in the X log.
<wgrant> And it's certainly triggered by typing, but not by the amount.
<\sh> guys....when something like the jaunty kernel is complaining about acpi tables ... what do you need from the sysadmin to get it eventually fixed? mjg59 seems not to be here anymore ;)
<geser> wgrant, Hobbsee: same here. and it seems to be prevented if ones does the re-login oneself
<geser> wgrant, Hobbsee: seems to be bug 395595
<ubottu> Launchpad bug 395595 in gdm "gdm 2.26.1-0ubuntu2: Random logouts" [Low,Incomplete] https://launchpad.net/bugs/395595
<wgrant> geser: Looks like it.
<Hobbsee> geser: yeah, that'd be it.  I guess I should stop auto-logging in, then
<ogra> hmm, so that upgrade went rather bad
<geser> Hobbsee: just log out once after booting, auto-login will log you in automatically again
<Hobbsee> oh
<Hobbsee> logging out doesn't wok fo me - or at least, logs me back in again without a prompt
 * ogra sighs ...
<geser> yes, but after that you don't get kicked anymore (at least I doesn't get kicked after that)
<ogra> so my gdm initscript was completely replaced by some weird wine binary
<Hobbsee> oh, right
 * ogra wonders whats going on here
<Hobbsee> ogra: wine is obviously taking ove the wold.
<ogra> grrr, and someone enabled the keyboard bell in pluse again
<ogra> Hobbsee, well, i wouldnt mid a good merlot or rioja .... jut not on my disk !
<Hobbsee> hehe
<Hobbsee> indeed
 * ogra sighs and reboots once again
<\sh> hmm? gdm initscript replaced by wine binary?
<ogra> mumble
<ogra> so why does gdm suddenly show me systm users ... i surely dont want to log in as approx
<ogra> and why does it default to the userlist
<ogra> sigh
<ogra> and why is my console kbd set to US again
 * ogra thinks new gdm hurts more than it gains us
<geser> ogra: the keyboard layout should be fixed now (in -0ubuntu2)
<ogra> ii  gdm                               2.26.1-0ubuntu2                   GNOME Display Manager
<ogra> it was fine in ubuntu1 for me
<ogra> it just broke with the last reboot
<geser> oh, right. the console layout is also broken (just checked) :(
<ogra> ogra@osiris:~$ sudo hddtemp /dev/sda
<ogra> /dev/sda: Hitachi HTS722012K9SA00: 41Â°C
<ogra> humm, and that used to be around 30-35Â°C before
<geser> ogra: listing your system user in gdm could be bug 395281
<ubottu> Launchpad bug 395281 in kerneloops "gdm 2.26 criteria for which users shown in greeter list are bad" [Undecided,Invalid] https://launchpad.net/bugs/395281
<ogra> intrestingly its only the approx user
<ogra> and i installed approx weeks ago
<ogra> or reinstalled
<ogra> so i wonder, if its the ck bug, why does it show up now and not before
<wgrant> ogra: Did gdm 2.20 use CK for that? I remember it being more staticly defined in the config file.
<ogra> i think the old gdm just didnt use uid's below 1000
<wgrant> Right.
<ogra> what really bothers me is that replacing of the initscript, thats not supposed to happen
<pitti> ogra: right, I see the realtimekit user in gdm
<pitti> ogra: keyboard layout works for me now, though
<ogra> pitti, on console ?
<ogra> it works fine under X
<pitti> oh, haven't tested that
<pitti> (with German layout)
<pitti> gdm changes the console keymap? bad gdm
<ogra> its simply wrong in tty
<pitti> please file a bug then
<pitti> /etc/default/console-setup is right?
<ogra> well, it doesnt, thats the point :)
<ogra> it did until last upgrade
<pitti> gdm isn't supposed to set the console keymap
<pitti> that's /etc/default/console-setup
<pitti> and X reads it from there
<ogra> XKBMODEL="pc105"
<ogra> XKBLAYOUT="de,us"
<ogra> XKBVARIANT="nodeadkeys,"
<ogra> XKBOPTIONS="grp:alts_toggle"
<ogra> hmm
<pitti> "de,us"??
<ogra> where does the us come from there ...
<ogra> i never touched that file
<pitti> it should be written by the installer
<ogra> must be the gnome tool
<ogra> well, when my X keymap was gone you suggested i should set it in the gnome keyboard tool, that has an US map by default
<ogra> i didnt delete the us one but added the german one and clicked on "set systemwide"
<ogra> so i guess its gnome-systemtools fault
<pitti> ah, that would be it
<pitti> mvo: what would be the right package for this? ^
<pitti> (AFAIK you did the "system wide" stuff, didn't you?)
<mvo> pitti: ubuntu-system-service
<pitti> ogra: ^
 * ogra removes the us kbd in the kbd properties and reboots once more
<ogra> hey
<mvo> but it sounds to me like we should teach console-setup about layout="one,two"
<ogra> someone promised the system menu would have the reboot item back
<ogra> bah
<ogra> i only have logout here
<pitti> it does
<pitti> gnome-panel version?
<ogra> lock screen and logout...
<ogra> no idea, upgraded 20min ago
 * ogra checks
<ogra> 1:2.26.2-1ubuntu4
<pitti> mvo: does console-tools actually understand several layouts? it doesn't make sense, it should just do the default one
<ogra> ++
<pitti> ogra: hm, that should be the fixed one
<mvo> ok
 * mvo fixes
 * pitti pokes gdm for the "shows system users" issue, thanks to james_w for analyzing
<ogra> pitti, i *had* the shutdown option yesterday, it must have been gone with todays upgrade
<mvo> pitti: hm, so for me de,us in the console works just fine, switching keymaps with alts works too
<mvo> ^-- ogra
<pitti> mvo: wow, I wasn't aware that VTs could do that
<pitti> mvo: is "both alts" hardcoded there?
<mvo> I think it reads it from xkboptions
<pitti> ah
<mvo> XKBOPTIONS="grp:alts_toggle"
<pitti> nice
<mvo> yeah
<mvo> so gdm does not do anything to the keymap? or does it read the /etc/default/console-setup file?
<pitti> mvo: gdm really shouldn't
<pitti> if it does (by default), it's a bug
 * mvo pokes it a bit
<pitti> mvo: hal reads /etc/default/console-setup, and X.org reads it from hal
<ogra> console-setup is right now
<ogra> the keyboard isnt though
<pitti> gdm doesn't even have an UI for setting the keymap
<pitti> so it shouldn't mess with it
<ogra> XKBMODEL="pc105"
<ogra> XKBLAYOUT="de"
<ogra> XKBVARIANT="nodeadkeys"
<ogra> XKBOPTIONS="grp:alts_toggle,altwin:menu"
<ogra> still US kbd on tty
<mvo> ogra: so on the console you also got us?
<mvo> hmm
<ogra> mvo, *only* on ttys
<ogra> its right in X
<pitti> ogra: you rebooted after this? or restarted whichever init script reads it?
<ogra> rebooted
<mvo> ogra: does it work if you run /etc/init.d/console-setup start manually?
 * ogra tries
<pitti> console-setup:# Short-Description: Set console font and keymap
<pitti> hmm
<ogra> mvo, yes
<ogra> race ?
<mvo> ogra: I suspect its run too late then for some reason
<ogra> yep
<ogra> i dont know if it still runs from initramfs (it once used to)
 * ogra does an update-initramfs and reboots
<saispo> hi
<mvo> ogra: I think that is the problem, for me LAYOUT=de,us seems to work fine
<saispo> have you planned to sync the kernel git with the latest update ?
<TheMuso> saispo: 2.6.31-rc2 was uploaded a few hours ago.
<saispo> TheMuso: for hardy LTS excuse me :)
<TheMuso> saispo: oh ok then. :)
<ogra> initramfs -> didnt help
<ogra> so the initscript needs to move
<ogra> though thats run in rcS
<ogra> i dont get how it can be to late
<saispo> TheMuso: you think, it will be sync soon ? :)
<ogra> TheMuso, please disable the keyboard bell in terminals again in pulse, the "clonk" if i reach the beginning of a line makes me mad
<ogra> ugh ... /etc/rc2.d/S12915resolution how did that get there
<ogra> ogra@osiris:~$ LANG=C sudo apt-get remove --purge 915resolution
<ogra> ...
<ogra> Package 915resolution is not installed, so not removed
<ogra> ...
<ogra> ogra@osiris:~$ ls -l  /etc/rc2.d/S12915resolution
<ogra> lrwxrwxrwx 1 root root 23 2008-04-10 17:26 /etc/rc2.d/S12915resolution -> ../init.d/915resolution
<ogra> i'm pretty sure i *never* had 912resolution installed on this machine
 * ogra cries ... whats going on with my laptop
<pitti> /usr/share/initramfs-tools/scripts/init-top/console_setup:if [ -f /etc/console-setup/cached.kmap.gz ] && type loadkeys >/dev/null; then
<pitti> ogra: ^
<pitti> it seems that it does really weird things in initramfs
<pitti> it doesn't use setupcon, etc.
<ogra> its only a fallback so you have your keyap in busybox
<ogra> iirc
<pitti> right
<ogra> cjwatson would know more
<pitti> ogra: so calling the init script manually works for you, right?
 * ogra doesnt get where that 915resolution comes from
<ogra> yeah, that changes the font and makes the kbd work right
 * ogra doesnt get either why purging it doesnt remove the initscript
<pitti> ogra: you have /etc/rcS.d/S49console-setup ?
<ogra> yes
<pitti> ogra: could you try booting with "text", to not start gdm at all? just to check whether gdm messes it up again?
<ogra> ok
<pitti> rescue should also work
<ogra> i'm not sure its gdm related at all though
<ogra> might just be Keybuk's fault anyway :P
<icarus901> it's new style kernel mode setting for the intel graphics, rather than leaning on the userspace xorg driver
<icarus901> nastiness
<ogra> same issue in text mode
<mvo> ogra: do you have "Setting up console font and keymap" at all in the boot log?
 * ogra sighs and reboots again without splash ... 
<ogra> indeed i only added text
<mvo> :)
<ogra> oh
<ogra> my shutdown item in the menu is back
<ogra> intresting
<apw> slangasek, james_w, would either of you be able to cast your eye over a kernel hanging out in binary new for me
 * ogra curses about unstoppable fsck without splash
<ogra> mvo, it does the right thing without splash ... BUT ... i have no Ã¤Ã¶Ã¼ or any other special chars at the login prompt
<ogra> which is kind of weird
<ogra> though the delay through fsck might indeed have hidden the race
<ogra> (since when do we check after 20 mounts btw, it used to be 30)
 * ogra reboots once again without splash to make sure the fsck didnt influence it
<ogra> ok, its definately usplash related
<ogra> i reproduced it twice with and without splash makes the difference
<ogra> (though the behavior of the login prompt is intresting)
<ogra> hrm
<silidan> guys what needs to go wrong to have working system except that dpkg, apt-get and synaptic segfault?
<ogra> compiz stopped working as well
<ogra> and cant be enabled again
<cjwatson> ogra: I'm aware that console-setup isn't setting up ttys properly right now - it's nothing to do with the new gdm, as the bug has been open for a couple of weeks
<cjwatson> ogra: workaround: 'sudo setupcon' from a virtual console after boot
<ogra> yeah, i noticed its not gdm
<ogra> it was just my first shot since gdm messed with my kdb settings in X before
<cjwatson> ebroder: vol_id was replaced by blkid
<ebroder> cjwatson: I saw that. Thanks
<ogra> mvo !
<ogra> /etc/xdg/compiz/compiz-manager: 1: /dev/sda1: Permission denied
<ogra> /etc/xdg/compiz/compiz-manager: 2: tmpfs: not found
<ogra> /etc/xdg/compiz/compiz-manager: 3: proc: not found
<ogra> /etc/xdg/compiz/compiz-manager: 4: sysfs: not found
<ogra> /etc/xdg/compiz/compiz-manager: 5: varrun: not found
<ogra> /etc/xdg/compiz/compiz-manager: 6: varlock: not found
<ogra> whats THAT !?!
<ogra> (from my .xsession-errors)
<ogra> ERR
<ogra> /usr/bin/compiz: 456: /usr/local/bin/compiz: not found
<RAOF> Looks like you might have some crazy stuff in /etc/xdg/compiz/compiz-manager
<ogra> (no, i never compiled compiz in my life ... to prevent the question)
<ogra> yes, i seem to have the content of mtab in there
<RAOF> That's not going to go well :)
<ogra> obviously
<ajmitch> ogra: that's interesting...
<ajmitch> COMPIZ_BIN_PATH="/usr/local/bin/" # For window decorators and compiz
<ajmitch> in /usr/bin/compiz
<ogra> well, still
<ogra> i shouldnt have my mtab in /etc/xdg/compiz/compiz-manager
<ajmitch> it looks a bit funny :)
<silidan> yesterday i properly shutdown my system today i booted and now i wanted to start some system tools (synaptic, apt-get, dpkg, some from system->administration) but all seem to segfault
<RAOF> ajmitch: No, that's what's meant to be in there; the config from /etc/xdg/compiz/compiz-manager overwrites that default.
<ogra> no filesystem errors anywhere though
<ogra> ogra@osiris:~$ sudo ls /lost+found/
<ogra> #524291  #560422  #688923
<ogra> hmm
<ajmitch> RAOF: right, /etc/xdg/compiz/compiz-manager looks normal on here
<ajmitch> time for that emergency backup?
<ogra> i only got one of my home
<silidan> yesterday i properly shutdown my system today i booted and now i wanted to start some system tools (synaptic, apt-get, dpkg, some from system->administration) but all seem to segfault,  how can i find out whats going wrong?
<mvo> silidan: did you try rm /var/cache/apt/pkgcache.bin
<ogra> no need for backups of the system, i just reinstall if needed
<ogra> but i'd like to find the reason
<silidan> mvo: no yet will try
<silidan> segfault too
<silidan> mvo: segfault too
<silidan> means i also get a segfault for rm command
<cjwatson> if dpkg is segfaulting then /var/cache/apt/pkgcache.bin is not at fault on its own
<cjwatson> you probably have a corrupted library file on your disk
<silidan> no
<silidan> it seems sudo segfaults
<silidan> rnm works in home dir
<cjwatson> two choices: (a) you're experienced enough to figure out which file is broken and restore it from a rescue CD or whatever (b) back up your data and reinstall
<silidan> yep sudo segfaults
<silidan> so it may not be synaptic or dpkg but sudo itself
<silidan> yep synaptic wihtout sudo works
<silidan> so what can cause sudo to segfault?
<cjwatson> broken executable file, broken library file, or code bug in any of those
<cjwatson> a segmentation fault happens when a program attempts to access memory which is not mapped for its use; it can happen for all kinds of reasons but they are always either bugs or file corruption
 * ogra has a translation question for mvo "FÃ¼r Ihr System ist kein composite-fÃ¤higer Grafiktreiber verfÃ¼gbar, oder der aktuelle unterstÃ¼tzt es bereits."
<cjwatson> sudo *always* segfaulting is probably filesystem corruption though
<cjwatson> please visit #ubuntu for recovery help
<silidan> i had these kind of issues before but they magicaly fixed themselves after reboot, and they also magically appear from time to time after bootup
<ogra> so either i dont have a composite capable driver or the current one already supports composite ?!?
<cjwatson> then you have hardware trouble ...
<cjwatson> with those symptoms I'd personally suspect bad RAM. use the memory test from an Ubuntu CD
<silidan> ok
<silidan> ill be back
<cjwatson> please not here
<cjwatson> this is a #ubuntu kind of thing
<silidan> ok
<mvo> ogra: urg, I have to look what is causing this message, but I think the tool we use to querry for the composition support in the driver is rather limited
<ogra> it could just say "might or might not work" :)
<ogra> shorter but says the same :)
<ogra> /sbin/ldconfig.real: /usr/lib/libopcodes-2.19.51.20090704.so is not an ELF file - it has the wrong magic bytes at the start.
<ogra> ohg
<ogra> probably time to downgrade binutils
<ogra> [    1.261079] ACPI Warning: \_SB_.PCI0.SATA.PRT0._GTF: Return type mismatch - found Integer, expected Buffer 20090521 nspredef-940
<ogra> hmm
<souphorn> Is there any way that I can write actionscript and release swf file?
<souphorn> in ubuntu
 * ogra goes to #ubuntu-kernel
<wgrant> souphorn: You probably want #ubuntu.
<TheMuso> Is it just me, or is LP not currently closing bugs?
<TheMuso> with uploads.
<geser> TheMuso: examples?
<TheMuso> meh don't mind me, I know why.
<roshan08> hi all, i am writing a desktop app for blogging, how does a deb gets included in the ubuntu repo
<TheMuso> roshan08: You might be better asking in #ubuntu-motu.
<roshan08> TheMuso, ok
<pitti> cjwatson: would you kill me if I told you that you need to modify the installer for autologin again?
<pitti> cjwatson: just found bug 395861, and I'd rather fix it to use /etc/gdm/custom.conf (which is what upstream uses
<ubottu> Launchpad bug 395861 in gdm "gdm 2.26 custom configuration file: wrong filename" [Low,Incomplete] https://launchpad.net/bugs/395861
<ogra> pitti, oh, doesnt that imply that all the gdm-cdd.conf files need fixing too ?
<pitti> ogra: no, that just overrides /etc/gdm/gdm.conf
<ogra> right, but they surely need adjustment to the new gdm
 * Hobbsee cheers pitti on
<pitti> cjwatson: I added an oem-config task and assigned it to you
<TheMuso> ogra: From what I have heard, gdm uses gconf for settings now.
<pitti> it still reads gdm.conf and custom.conf for stuff like autologin, etc.
<TheMuso> pitti: Right, thats kinda surprising, but kinda not either. :)
<cjwatson> pitti: fine
<\sh> damn...now even ubuntu-devel ML is being crowded by this mono issue
<pitti> mvo: any idea what needs to happen in bug 368580? just update a .desktop file?
<ubottu> Launchpad bug 368580 in app-install-data-ubuntu "aMule should be offered instead of aMule AdunanzA" [Medium,Triaged] https://launchpad.net/bugs/368580
<pitti> mvo: (but I guess these .desktop files are autogenerated)
<mvo> pitti: yes, a update to the desktop file and/or a override in the generation
<pitti> mvo: for a SRU, fixing the .desktop file would probably work, but you wouldn't do that for the dev release, I guess?
<mvo> pitti: do you think we want to sru that?
<mvo> pitti: yeah, for the dev I will add a override
<mvo> pitti: I can do that once I finished fighting with vte
<pitti> mvo: I'm inclined to, WDYT?
<mvo> pitti: if aMule isa important app (I guess it is for a lot of users) then yes
<cjwatson> pitti: should I just overwrite any existing custom.conf, or does the code need to take care to account for an existing file there?
<cjwatson> hmm, apparently the package ships a file
<cjwatson> probably need to be careful to put it back, then
<pitti> cjwatson: the package ships a default skeleton
<pitti> cjwatson: didn't the jaunty gdm do the same?
<cjwatson> yes but we were just editing gdm.conf then
<pitti> just named gdm.conf-custom ?
<pitti> OIC
<cjwatson> so it was pretty obvious that we needed to keep a copy
<pitti> brb, testing new gdm
<Q-FUNK> howdy!  what do I need to do to get someone to look into bug #194140 ?
<ubottu> Launchpad bug 194140 in cyrus-sasl2 "Dependency cycle prevents upgrade of libsasl2-2" [Low,Confirmed] https://launchpad.net/bugs/194140
<Q-FUNK> this bug has been present since way before Hardy.
<Q-FUNK> it's a mere dependency cycle between two binaries from the same source package.
* pitti changed the topic of #ubuntu-devel to: gdm breakage: read https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-July/000586.html | 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/HelpingW
<ion> pitti: Iâd just run the upgrade from X in screen, relogin when needed and attach back to the screen. :-)
<ion> pitti: In fact, i run every single upgrade in screen anyway.
<pitti> that works, too
<pitti> but I didn't want to give ten different options
<ion> Isnât screen installed by default?
<azeem_> no
<ion> Ah, ubuntu-desktop depends on it, not ubuntu-standard. Scratch that, then.
<soren> kees: What ended up being the replacement for "chpasswd -e"?
<mvo> pitti: I uploaded a fixed package for #368580
<pitti> mvo: thanks! *hug*
<pitti> mvo: was your last comment really meant for this bug?
<pitti> it's not an upgrade issue at all
<ion> Cool, the crashkernel thing works. (The crash is probably not worth even reporting, since itâs the proprietary bcmwl driver hacking the system with a dwarven war axe, though.)
<mvo> pitti: greasemonkey
<mvo> pitti: I added a comment that the previous comment was bogus :)
<mvo> pitti: and added a test-case etc
<mvo> pitti: should be good now, karmic is getting it with the next data extraction (running now)
 * pitti hugs mvo
<NCommander> doko, kees, ping? I need some assistance on a toolchain issue involving custom ldscripts, and I was hoping you might be able to give me a hand
 * mvo hugs pitti
<doko> NCommander: well, if I can help ... didn't write one yet
<NCommander> doko, we're having issues with redboot building against our toolchain, specifically libc.a wants a lot of sections involving .tbss and the other threaded bits of the ELF headers which wasn't an issue w/ earlier glibcs
<NCommander> doko, is there a sane way to build against newlib with our existing toolchain?
<NCommander> which is possibly the only way to get a sane end-result
<NCommander> doko, brb, phone call
<doko> NCommander: we do build cross compilers as part of our toolchain packages as well, e.g. binutils-hppa64, gcc-hppa64, or -spu. you could do that for a newlib target configuration as well
<Keybuk> pitti: you realise your instructions won't work if they're on a WPA wireless network? :)
<pitti> Keybuk: does nm shut down WPA on session stop?
<Keybuk> pitti: of course
<Keybuk> pitti: the key comes from the user's session
<pitti> sure, that's for starting it
<ion> System settings in n-m ftw.
<pitti> but I wasn't aware that nm tears down the connection
<Keybuk> it seems to
<pitti> hmm; screen FTW then
<ion> setsid apt-get ... from the X session? :-)
<pitti> sudo rm /var/lib/dpkg/info/gdm.prerm
<pitti> before the upgrade
<Keybuk> ion: shouldn't matter overly
<Keybuk> apt might get killed
<Keybuk> but dpkg will carry on
<ion> --download-only dist-upgrade under the session, dist-upgrade from virtual console might work as well.
<pitti> jdstrand: FYI, firefox-3.5 was verified in jaunty-proposed, so it's good to go now
<jdstrand> pitti: ok
<pitti> jdstrand: shall I copy that to -updates, or you to -security?
<pitti> (I guess we want to do both)
<jdstrand> pitti: I'll do both, just to make it easier
<pitti> 'k, thanks
<asac> thanks folks!!
<jdstrand> np
<soren> I have a gzip'ed file I'd like to extract. It
<soren> Whoops
<soren> I have a gzip'ed file I'd like to extract. It extracts to a huge file, with big gaps in it, so I'd like to make sure it's stored sparsely. How to do?
<NCommander> doko, I'm trying to avoid that if at all possible; hence the question on using the standard toolchain against newlib
<jdstrand> pitti, asac: copied xulrunner-1.9.1 1.9.1+nobinonly-0ubuntu0.9.04.1 and firefox-3.5 3.5+nobinonly-0ubuntu0.9.04.1 to -security and -updates
<asac> ack
<jdstrand> pitti: will you handle the closing of the bug?
<jdstrand> (I don't remember which it is off hand...)
<NCommander> doko, basically, the issue is that we can't statically link against glibc in a case where we did because it mucks things up. We were only linking against libc because libgcc had symbols that were dependent on it
<pitti> jdstrand: that should happen automatically, but I'll look
<jdstrand> oh ok, I wasn't sure about the -proposed -> -updates bit in LP
<cjwatson> soren: google gunzip sparse, first hit
<soren> cjwatson: Ah, "cp /dev/stdin"! Of course. I was trying to use tar with very little success. Thanks!
<asac> jdstrand: i think the xulrunner one wasnt properly marked in changelog. i will close it manually now
<liw> soren, that'd be a cool option to have in gzip (or a cool utility to write for moreutils, actually)
<cjwatson> gzip yes, certainly. I'm not sure there's much point in wrapping cp --sparse=always /dev/stdin $foo in moreutils, though
<asac> done
<jdstrand> asac: thaniks
<jdstrand> thanks
<liw> cjwatson, hmm, assuming /dev/stdin works in all environments, yeah (and all environs have gnu cp, of course)
<cjwatson> though admittedly an adverbial version (sparse gunzip ...) would be neat-ish
<liw> for perfomance, gunzip --sparse would be great,though: no point in piping terabytes of NUL bytes to another tool that will just ignore them
<cjwatson> yeah
<NCommander> doko, if we need a cross-toolchain, then newlib must be built as part of the build, else the C++ toolchain FTBFS'es
<NCommander> doko, (--with-newlib must be passed, and the newlib and libgloss symlinks will have to be setup)
<cjwatson> especially since it's probably coming from about half a dozen bytes of the compressed file anyway :-)
<doko> NCommander: well, we have the newlib package. so maybe just build a cross compiler from a new source package, build-depending on newlib-source, binutils-source and gcc-4.4-source?
<NCommander> doko, that's what I currently wanted to do, but it was shot down as unacceptable.
<NCommander> (and my current package does :-/)
<NCommander> Well, more specifically, redboot-imx builds it as part of its rules, and then uses the newly built cross-compiler to spit out the proper binary
<doko> NCommander: why was it shot?
<NCommander> doko, its preferable to build w/ the in-archive toolchain
<NCommander> (which is what we did for jaunty, but the hack to make that work broke miserably)
<NCommander> doko, due to changes in how the symbols used between libgcc and libc.a changed, it causes the binary to bloat from 160kb to 1.2MB even after the ELF headers are stripped with objcopy
<NCommander> doko, (the resulting binary doesn't work either)
<pitti> lool: thanks for fixing dk-p
<pitti> lool: I'll test the patch now, and apply it to the Debian package (I'm about to do an upload anyway)
<geser> pitti: just curious: will postgresql-8.4 make it into karmic?
<pitti> geser: I planned to, yes
<ogra_> doko, would newlib be suitable for main ? in case NCommander gets that working it would become a build-dep of redboot
<ccheney> which program regenerates the config.sub/config.guess symlinks?
<ccheney> i thought it was libtoolize but it doesn't seem to do it
<liw> ccheney, autotools-dev?
<ogra_> cjwatson, the ltsp guys were nagging me, is there any ETA when we will see mount --union ? (stgraber is pretty unhappy with the slow boots)
<cjwatson> ogra_: ask the kernel folks, not me ...
<ogra_> ok, well, i though since you are affected as well you might know ... pure lazyness, sorry :)
<cjwatson> ccheney: automake does it if your program uses automake; otherwise copy manually
<cjwatson> ogra_: sorry, I've seen it being worked on but don't know the exact current status
<ogra_> yeah, i'll ask the the source ;)
<doko> ogra_: why not? we would only keep newlib-source in main
<ccheney> thanks guys :)
<ccheney> i had to use --add-missing which is what i forgot earlier
<ogra_> doko, great, just wanted to be sure ...
<NCommander> ogra_, bust on using newlib
<NCommander> ogra_, stack-protector gets in the way; /usr/lib/gcc/arm-linux-gnueabi/4.4.0/libsupc++.a(eh_alloc.o): In function `global constructors keyed to eh_alloc.cc':
<NCommander> (.text._GLOBAL__I_eh_alloc.cc+0x90): undefined reference to `__stack_chk_guard'
<NCommander> ogra_, so using an alternate libc just got shot down :-/
<NCommander> (just for reference sake, -fno-stack-protector is passed and used, the problem is the internally GCC libraries use it; that only matters when trying to change libcs)
<NCommander> ogra_, I'm out of ideas again, unless doko or kees can figure out how to make the linker script happy
<ogra_> hmm
<kees> NCommander: sorry, I've never played with linker scripts before.  :(
<NCommander> bust 2.0 :-/
<ogra_> do you have a full build log you can upload ?
<ogra_> s/upload/pastebin/
<doko> NCommander: configure with --disable-ssp
<doko> NCommander: or does linking with -lssp_nonshared help?
<NCommander> doko, that isn't the problem
<NCommander> doko, oh, right, no, this is using the stock GCC in archive (we're trying to avoid rebuilding GCC if at all possible)
<cody-somerville> superm1, Is the Ubuntu DVD a live cd or d-i based installer or just provide a pool of packages or what?
<NCommander> -rwxr-xr-x 1 mcasadevall mcasadevall 2.8G 2009-07-06 12:30 redboot.bin
<NCommander> ogra, ^
<NCommander> I think I won the worlds largest redboot contest ...
<ogra> well, e just need to ask the SoC vendors to add a bit more flash space :)
<cjwatson> cody-somerville: it's both
<cjwatson> cody-somerville: you get to choose at boot time
<superm1> cody-somerville, it's a live cd
<cjwatson> superm1: it's both
<Keybuk> eep.  I just came up with a valid reason to use both sigsetjmp() and a nested function in the same place
<Keybuk> I feel dirty
<NCommander> doko, ping
<NCommander> doko, basically, is it possible without excessive amounts of pain to add a new cross-compiler to gcc-4.4, targeting arm-none-gnueabi, being built on only i386, and building the C, C++, and newlib compilers in single-pass mode?
<NCommander> doko, (that is to say, setting up the necessary symlinks)
<doko> NCommander: just leaving for today. why would that be simpler than a separate source package build-depending on gcc-4.4-source?
<NCommander> doko, it doesn't seem acceptable based on what I've been told, hence the problem
<spotter> new gdm is really broken, right?
<liw> spotter, see ubuntu-devel-announce@lists.ubuntu.com
<spotter> is one of the known bugs "restarting your session" in the middle?
<cjwatson> spotter: yes, see the -devel-announce post liw alluded to
<spotter> I did, didnt' see any reference to bugs people have
<spotter> though for some reason I only get kicked out once, pretty quickly
<spotter> after that its stable
<spotter> albiet weird as it moved from vt1 to vt7
<cjwatson> the announcement refers to bug 395302
<ubottu> Launchpad bug 395302 in gdm "kills X session during upgrade" [Critical,Fix released] https://launchpad.net/bugs/395302
<cjwatson> https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-July/000586.html
<spotter> cjwatson, right, but this isn't on upgrade
<spotter> this is every time I use it
<cjwatson> oh, right. I don't know then
<spotter> I upgraded w/o a problem from console
<spotter> also on "restart" it seems to mess up my vt's
<cjwatson> but session dying isn't necessarily gdm of course
<spotter> they are a mash of colors now
<spotter> like half my display
<spotter> could be an ati bug I guess
<akos_> Hi! The GNOME 2.26 release notes says that there is a new Volume Control app (http://library.gnome.org/misc/release-notes/2.26/#rnusers.volume), however I can find only the old one (I'm using Jaunty).
<Caesar> bryce: I think you just used your canned response on the wrong bug (#393503)
<bryce> Caesar, thanks, the scripts have trouble distinguishing non-bug-reports from worklist/wishlist bugs unless they're formatted in a machine readable way
<Caesar> No worries
<Caesar> You wanna remove those tags you added or shall I?
<bryce> go ahead, I've set to Triaged/Wishlist which should prevent further automated handling of it
<bryce> fwiw, if you start a subject with "Please..." it is interpreted by the scripts as a workflow bug and ignored
<Caesar> Noted
<lool> pitti: Sorry I couldn't coordinate the dkp upload with you as the bandwidth is too crappy for ssh (and so IRC for me); I changed the Vcs stuff because I couldn't ask you to merge it in Debian first
<lool> pitti: Thanks for testing it and pushing it to Debian then
<lool> pitti: I'm in utopia BTW
<lool> pitti: But I didn't do any packaging on dk yet
<ion> pitti: Oh, btw, when upgrading from gdm 2.26.1-0ubuntu2 to 2.26.1-0ubuntu3, gdm never came back up automatically. The old versionâs prerm: â* Stopping GNOME Display Manager...â, the new versionâs postinst: â* Reloading GNOME Display Manager configuration...â âinvoke-rc.d: initscript gdm, action "reload" failed.â (gdm reload after gdm stop just fails).
<Kano> hi Sarvatt , is there a current iso with all xorg git updates
<Sarvatt> nope, its going through some flux right now so i havent made one
<olof_> I'm planning to start migrating software-properties-gtk to use policykit instead of sudo (as it is used in update-manager, and in one of the karmic blueprints), but I would need some assistance. Where should I turn to? ubuntu, software-properties-gtk or policykit?
<Kano> Sarvatt: i need something with 2.6.31 and latest intel git
<Kano> if you like let me know when you have got something like that
<Kano> i am usually on that irc server
<Kano> bye
<Sarvatt> the packages are on edgers, why dont you do it yourself?
<Sarvatt> even the livecd build scripts are on there
<Sarvatt> ah he left
<glatzor> olof_, hello. I worked on s-p-gtk some time ago.
<glatzor> olof_, Currently I am writting aptdaemon which allows to install/remove packages using policykit. I plan to also add support for installing signatures and enabling/disabline repositories
<glatzor> olof_, aptdaemon would already provide you a working dbus service that you could enhance.
<olof_> glatzor: Oh, cool, I have little experience of policykit and python, but I found the first obstacle. software-properties-gtk need to access some keyrings and /etc/apt/trustdb.gpg. I don't know what to do now? Allow it to be read as root? Rewrite the fetching of keys?
<olof_> glatzor, What is aptdaemon? Can I find info somewhere?
<glatzor> olof_, https://launchpad.net/aptdaemon
<olof_> glatzor, Just found it :)
<glatzor> olof_, software-properties-gtk makes use of python-software-properties and aptsources
<glatzor> glatzor, basically you could just call the methods of software-properties directly in the aptdaemon
<olof_> glatzor, I did some digging in the source code and found that it uses gpg directly. Does aptdaemon provide an API for that instead?
<glatzor> olof_, so you don't have to worry about the level things
<glatzor> olof_, no. not yet. you would have to just "import SoftwareProperties"
<glatzor> in aptdaemon
<glatzor> olof_, it doesn't make sense to duplicate work.
<ogra_> glatzor, tell that microsoft ...
<ogra_> they duplicate our work all the time instead of invesing into ubuntu ;)
<olof_> glatzor, Which package do I need for the SoftwareProperties module?
<glatzor> olof_, python-software-properties, but it should be installed on every desktop system
<glatzor> by default
<glatzor> https://launchpad.net/software-properties
<glatzor> There you can also find the source code
<olof_> glatzor, I have python-software-properties installed, and tried import SoftwareProperties in a testprogram, but python can't find it
<glatzor> olof_, sorry. the package name is softwareproperties
<olof_> glatzor, That worked better. I will check out the source code a bit, and probably return for more questions
<glatzor> "pydoc softwareproperties.SoftwareProperties" will give you a short overview
<olof_> glatzor, Thanks, I'm quite new to Python, so I feel a bit lost
<glatzor> olof_, no problem. the redesign of software-properties was also one of my first Python projects :)
<olof_> glatzor, I just noticed that this was my starting point. I will try to be more specific. In AptAuth.py in the softwareproperties module, there is a call to /usr/bin/gpg. My idea was to use policykit to run only this command (as a starting point). Is that the way to do it, or does aptdaemon you talked about, provide a wrapper to work around this syscall?
<glatzor> olof_, there is no need for caring about the low level system calls. softwareproperties is already a wrapper.
<glatzor> you would have to add functions to aptdaemon which can be called by dbus. in these functions you would call the functions of software-properties
<glatzor> policykit is only a framework to manage privileges.
<glatzor> simplified: you can only ask the policykit service if a given user is allowed to do a given task
<glatzor> aptdaemon already makes use of policykit and provides a rough python api for policykit
<glatzor> olof_, at first you should take a look at the python dbus tutorial to understand how it can be used
<olof_> glatzor, I can't find anywhere to check out the aptdaemon code.
<glatzor> olof_, you don't need to understand dbus completely, since aptdaemon already provides all the basics for you
<glatzor> bzr branch lp:aptdemon
<glatzor> olof_, take a look at the aptdaemon/core.py file: The AptDaemon class provides the dbus service
<glatzor> olof_, you don't need to use the the transaction/queuing mechanism for the repository handling
<glatzor> olof_, GetTransactions is a very basic function that you could use as a starting point
<olof_> glatzor,Reading the source now. Guess it will take a while to get into it :)
<glatzor> olof_, you could try to start adding keys at first
<olof_> glatzor, Does aptdaemon provide a method for that? Are there any example files?
<glatzor> olof_, you can use every gpg key
<glatzor> olof_, try to add a new function to the daemon and the client. it doesn't need to do more than just print "hello world"
<glatzor> olof_, D-Bus methods use camel case names. So you could create a method InstallKey which accepts a file path
<olof_> glatzor, Still trying to fit the pieces together.. do I need to run aptdaemon as a daemon, and then write a client program to interact with it?
<glatzor> olof_, right.
<olof_> Can I run it directly from the directory I checked out with bzr, or do I need to install the daemon first?
<glatzor> olof_, but luckily there is already a client :)
<olof_> glatzor, Hurray!! :) ...where?
<glatzor> olof_, aptdaemon/client.py and aptdaemon/console.py
<glatzor> client provides an abstraction for the client side of aptdaemon
<glatzor> in console you can find the command line client
<olof_> console can't find aptdaemon.. never installed python stuff by hand in ubuntu, which I guess I need to do. What to do?
<glatzor> olof_, you can run all commands directly from the source code repository
<glatzor> but you need to add some configuration files for dbus
<glatzor> perhaps it is the easiest way to install the aptdaemon package
<glatzor> https://launchpad.net/~aptdaemon-developers/+archive/ppa
<olof_> Does setup.py have something to do with this, or do I need a .deb to install it correctly?
<glatzor> olof_, install the aptdaemon package from the ppa
<glatzor> olof_, afterwards you can run the daemon from the bzr directory: sudo ./aptd -td
<glatzor> the client command line tool is aptdcon: "./aptdcon install xterm" would install xterm
<daurnimator> is there someone that can make a libbrary into a deb for me?
<olof_> glatzor, I'm getting dbus.exceptions.DBusException: org.freedesktop.DBus.Error.AccessDenied: Connection ":1.127" is not allowed to own the service "org.debian.apt" due to security policies in the configuration file, when trying to start the daemon
<glatzor> olof_, do you run the daemon as root?
<glatzor> sudo ./aptd -td
<glatzor> the aptdaemon package is installed?
<ScottK> daurnimator: Probably not.  You can ask packaging questions on #ubuntu-motu, but you're not very likely to find someone to just do it for you.
<olof_> glatzor, yes
<glatzor> olof_, "sudo /etc/init.d/dbus reload"
<TheMuso> daurnimator: You might be better asking in #ubuntu-motu.
<olof_> glatzor,sorry, just installed python-aptdaemon. Now it's installed, and it works
<glatzor> olof_, ./gtk-demo.py is a small graphical demo application
<olof_> glatzor, gtk-demo looks like a good starting point.
<glatzor> olof_, you get earlier results with the console client
<glatzor> olof_, it is less complex, and you don't have to care about the gui
<glatzor> it is just "print result" :)
<olof_> glatzor, yes... tried it to install a package. Worked just fine. Will take a look at the source code. Think I'm starting to get the hang of this. Just need to confirm a few things again :)
<glatzor> olof_, feel free to mail me.
<olof_> glatzor, That's probably the best way. I think I saw your address at launchpad
<glatzor> glatzor at ubuntu dot com
<olof_> Thanks for the help. I will try to get something together. This is probably the closest I have come to actually doing some community work after 10 years of using linux :)
<billybigrig> anyone know how i go about finding who maintains gspca?
<pochu> billybigrig: the webcam drivers?
<billybigrig> yeah
<billybigrig> .31 has broken mine
<billybigrig> and i want to know if there's a workaround or something
<pochu> billybigrig: the kernel team
<pochu> billybigrig: there's #ubuntu-kernel
<billybigrig> no answers :P everyone must be sleeping
<pochu> :)
<pochu> billybigrig: you could also try the mailing list if nobody replies there
<billybigrig> i guess
#ubuntu-devel 2009-07-07
<superm1> cjwatson, cody-somerville right. well at least in the context that cody-somerville was referring to, it's more relevant that it is a bootable live disk
<billybigrig> pochu: .31-2.16 doesn't seem to have an gspca fixes either
<james_w> slangasek: hey. Is there any way for cron to use common-session in PAM, but not the pam_ck_connector that is declared within?
<james_w> or is that question too crazy to even contemplate?
<slangasek> james_w: yeah, that's too crazy; the mechanism for selecting different modules based on service is to configure /etc/pam.d/$service :)
<james_w> yeah :-)
<james_w> but, but... https://bugs.edge.launchpad.net/ubuntu/+source/consolekit/+bug/287715/comments/5
<ubottu> Ubuntu bug 287715 in consolekit "Trying to shut down or restart falsely suggests others are logged in" [Medium,Triaged]
<slangasek> "This PAM module should be used with caution; only local login managers such as login should use this."
<james_w> (the new GDM has further increased the priority of this somewhat)
<slangasek> hrm?  how would that be an issue for GDM?
<james_w> it's a bit baroque
<slangasek> this is basically a manifestation of the "we need to distinguish between interactive and noninteractive sessions in PAM" bug
<james_w> GDM now tries to be clever with the user selector by showing users in frequency order
<james_w> to do this it calls ck-history --frequent
<slangasek> ah, so it sees cronjobs, haha
<james_w> that in turn parses /var/log/ConsoleKit/history
<james_w> we've fixed it so that it only shows non-system users
<james_w> but if you have a */10 cronjob say, you appear to log in a lot
<slangasek> right; so the right thing is that we need to *split* /etc/pam.d/common-session, for this reason and others
<james_w> the more sever issue is that with cron running so often /var/log/ConsoleKit/history is huge, and --frequent requires parsing the whole thing
<james_w> so it takes a few seconds after getting to GDM to actually get any users listed
<pochu> billybigrig: I have no clue about that, sorry
<james_w> I'm adding logrotate to consolekit to keep the size limited, and considering a new mode for ck-history that is a frequency/recency measure, but fixing this would still be good
<james_w> is the split something that is planned, or just needed?
<slangasek> james_w: Debian bug #169930, fwiw; I don't have anything more than the roughest notion of what the split needs to look like, at this point
<ubottu> Debian bug 169930 in pam "pam: Default usage of pam.d-include-files" [Wishlist,Closed] http://bugs.debian.org/169930
<james_w> ok, thanks
<james_w> I guess it's unlikely to be done this cycle?
<james_w> in that case, is just waiting for the correct fix the right thing to do, and just work on the other fixes to the symptoms?
<directhex> cjwatson, looks like the TB can see into the future
<slangasek> james_w: if this log scales poorly, presumably terminal servers are going to have the same problem, right?  So the symptom should still be addressed, one way or another
<james_w> yeah, that should still be fixed
<james_w> I don't see another fix for that original bug though
<slangasek> huh, where did ubottu get that wrong description and bug state?
<james_w> I'm thinking of using logrotate's behaviour to involve recency in the frequency calculation
<slangasek> yeah, I can't offer much for that bug right now; any workarounds would be fussy and make the path to a correct fix longer
<james_w> parse the first file, emit the frequency-based user list from that, then parse the first rotated file, and emit any further users from that in frequency order, etc.
<james_w> so that the GDM list can fill asynchronously in still a useful order
<james_w> ok, thanks, I await a true fix
<TheMuso> So 2.6.31-rc2 fixes one thing for me, but breaks another. :)
<RAOF> Hurray!
<TheMuso> yeah, but I've just found that what seems to be broken as a user, seems to work as root./
<TheMuso> Seems some ioctls for talking to DVD/CD drives only work as root.
<TheMuso> i.e the eject command as a user doesn't work, but as root works fine.
<ion> Seems to work for me.
<TheMuso> ion: You on 2.6.31-2-generic?
<TheMuso> And what arch?
<ion> Linux hapatus 2.6.31-2-generic-pae #15-Ubuntu SMP Mon Jul 6 02:33:43 UTC 2009 i686 GNU/Linux
<TheMuso> ok I am on amd64.
<ion> If the multiarch thing were already in place, i could simply switch this system to amd64 and give results soonish. :-P
<TheMuso> heh
<slangasek> doko: do you know why build-essential no longer has a direct dependency on gcc?  The most recent changelog entry still talks about it
<slangasek> doko: looks like a bug in the patch for build-essential 11.4, which doesn't match the changelog entry
<Kage_Jittai> persia: They still have not backported our project :\
<Kage_Jittai> persia: https://bugs.launchpad.net/ubuntu/+source/tmw/+bug/393724
<ubottu> Ubuntu bug 393724 in tmw "Please Backport tmw 0.0.24.1-1 in Hardy with tmw 0.0.29.1-1 in karmic" [Undecided,New]
<Kage_Jittai> see this is they type of unresponsiveness we have to deal with
<slangasek> Kage_Jittai: that's not the correct procedure for requesting backports.  https://help.ubuntu.com/community/UbuntuBackports#How%20to%20request%20new%20packages
<Kage_Jittai> slangasek: I was told it would work
<slangasek> you were told incorrectly, then; the page I've linked you to documents how to request backports
<Kage_Jittai> slangasek: I don't have time to read that page
<slangasek> filing a bug on the package isn't going to be noticed by the backports team
<Kage_Jittai> https://bugs.launchpad.net/dapper-backports/+bug/396317
<ubottu> Ubuntu bug 396317 in dapper-backports "Please Backport tmw 0.0.24.1-1 in Hardy with tmw 0.0.29.1-1 in karmic" [Undecided,New]
<Kage_Jittai> will that work?
<slangasek> should have been filed against the hardy-backports project rather than dapper-backports, but that should show up on the backport team's radar anyway, yes
<Kage_Jittai> slangasek: *sigh* Dapper needs to be backport too prolly
<Kage_Jittai> but Hardy is the most used out of date
<slangasek> doubtful, given that dapper desktop support expires in a few short days
<Kage_Jittai> ok
<Kage_Jittai> I remember when dapper was new :P
<Kage_Jittai> slangasek: ok, well, I hope this doesn't vanish with it
<Kage_Jittai> slangasek: well see if the backport team picks up on it this time
<Kage_Jittai> *sigh*
<ajmitch> some people have no patience
<wgrant> Indeed.
<ajmitch> 220 open hardy-backports bugs, I doubt they'll find time to backport some game client in the next couple of hours
<ajmitch> good to see backport requests open for stuff that hasn't even landed in karmic yet
<slangasek> I see tmw 0.0.29.1-1 in karmic
<ajmitch> slangasek: sorry, I was referring to a bug for php 5.3
<ajmitch> it seems that a few people want that version
<slangasek> ah
 * slangasek uploads php 5.3 as a dummy package depending on python
<TheMuso> heh
 * wgrant likes that idea.
<ajmitch> you'd probably make a lot of sysadmins very happy
<TheMuso> ...or mad.
<wgrant> No, you'd make developers mad.
<persia> Well, and those few sysadmins that already got bullied into isntalling some unofficial php5.3 package.
<ajmitch> because their developers needed goto?
<persia> well, because their developers are mad and interrupting their sleep
<TheMuso> pitti: Ok, I have found which event device is for my touchpad using lsinput and input-events, so its fine at the kernel level. Seems hal is not picking it up properly, here is the lshal block for the touchpad. http://paste.ubuntu.com/211657/
<Sarvatt> does it work when you rmmod psmouse && modprobe psmouse?
<Sarvatt> i've been having to boot with i8042.reset=1 since around 2.6.30-git13 for mine to get detected as a touchpad instead of a generic mouse every other boot
<Sarvatt> they added a quirk to always do that for my machine in dtor's input tree but it hasnt hit linus' yet
 * ScottK opines we could use some new developer with the energy for reviewing backports requests ...
<Sarvatt> http://git.kernel.org/?p=linux/kernel/git/dtor/input.git;a=commit;h=9230ccb1071d2d7e4ecb6314e67203b9f7f08140
<TheMuso> Sarvatt: Its USB.
<TheMuso> psmouse is PS/2 only.
<TheMuso> Sarvatt: And, I wouldn't even get feedback from my finger on the touchpad using input-events if the driver weren't loaded or loaded properly.
<cody-somerville> Wow.
<cody-somerville> Whoever sponsored network-manager-openvpn did not test it at all.
<ajmitch> cody-somerville: does it take out NM?
<cody-somerville> ajmitch, The binary is almost empty
<cody-somerville> ajmitch, Just has the /usr/share/doc/ stuff
<ajmitch> that's a bit odd
<ajmitch> though the problem with sponsoring is usually how much you can test things are sane
<cody-somerville> They should have atleast done dpkg-deb -c on the deb
<StevenK> Although, when I sponsor I will at least check things built correctly
<TheMuso> pitti: Seems I can't use suspend/hibernate from the logout menu, or run the gpm preferences as well. Not sure what I am looking for in lshal's output unfortunately, so more guidence will be needed. :)
 * cody-somerville fixes network-manager-openvpn.
<ajmitch> cody-somerville: looks like it may be something as simple as debhelper compat level
<cody-somerville> ajmitch, That was my first thought
<cody-somerville> Its actually DEB_DESTDIR in rules
<ajmitch> at least the build log shows files going into debian/tmp, so it's just not picking them out of there
<ajmitch> ok
<cody-somerville> ajmitch, There is no $package.install file
<ajmitch> a minor omission
<cody-somerville> so DEB_DESTDIR needs to be $(CURDIR)/debian/network-manager-openvpn/ and not DEB_DESTDIR = $(CURDIR)/debian/tmp/
<StevenK> debian/tmp is debhelper compat level 1 and 2!
<persia> Hrm?  I get stuff in debian/tmp with debhelper 7, if I do it right.
<ajmitch> StevenK: it's come back to haunt you
<ajmitch> StevenK: the debhelper manpage lists it as a new fallback in 7
<StevenK> Argh!
<StevenK> Noooooo!
<ajmitch> StevenK: embrace the evil
<StevenK> Noooooo!
<cody-somerville> If I don't have commit access to a universe package that is managed in bzr, does that mean I'm not allowed to upload?
<cody-somerville> I've created a branch merge proposal
<ajmitch> you're technically allowed to, I suppose, but it'd be polite to at least do a merge proposal
<ajmitch> which you've done
<persia> cody-somerville, Rather it means you should complain to whoever controls the bzr resource.  I'd suggest uploading, and submitting a merge request
 * cody-somerville nods.
<wgrant> No point trying to fix access rights now, as everything will change with package branches.
<persia> What?  Why?
<wgrant> Package branches are meant to get a flag to grant write access to uploaders.
<pitti> Good morning
<TheMuso> Morning pitti.
<pitti> lool: thanks, no prob
<pitti> ion: see /topic and u-d-a@; gdm upgrade is known to fail, unfortunately there's nothing to fix :(
<gnomefreak> does that include losing the app bubbles on lower gnome pane by chance pitti
<pitti> gnomefreak: it breaks gdm pretty much completely
<gnomefreak> s/pane/panel
<pitti> you _need_ to install it in screen, or a VT
<gnomefreak> oh
<gnomefreak> pitti: thanks
<ajmitch> but it's only breakage for those of us silly enough to run karmic on our desktops already :)
<pitti> TheMuso: can you please ubuntu-bug hal and add lsinput output? I'll take a look then and fix it upstream (please assign the bug to me)
<pitti> TheMuso: no suspend/hibernate is a separate problem; sounds like gnome-power-manager isn't running; I uploaded a new one last night, does that work?
<TheMuso> pitti: Probably haven't got it yet, due to keeping local mirror whic updates daily. I'll refresh it and try again.
<pitti> TheMuso: is gnome-power-manager running? (pidof)
<TheMuso> pitti: ok will file a bug ASAP.
<TheMuso> pitti: Machine is currently not runing, just a sec.
<TheMuso> *running
<pitti> ah
<TheMuso> its my notebok
<TheMuso> gah bad typing this afternoon.
<TheMuso> pitti: no its not running.
 * TheMuso refreshes his local mirror.
<pitti> TheMuso: if you start it from a shell with --verbose, what does it say?
<ion> pitti: I was commenting about the link in the topic. It says âPress Ctrl+Alt+F7 to get back to the graphical login managerâ where it should say âRun sudo /etc/init.d/gdm start to get back to the graphical login managerâ. :-)
<pitti> TheMuso: do you have devicekit-power 009?
<persia> ion, Ctrl+Alt+F7 also works...
<pitti> ion: oh, ok; thanks
<pitti> but it should start automatically (did for me)
<ion> persia: Not very well if gdm isnât running.
<TheMuso> pitti: yes I have that version of devicekit-power
<TheMuso> just a sec I'll pastebin the gnome-power-manager output.
<pitti> TheMuso: and gnome-power-manager 2.27.1-0ubuntu4?
<persia> Ah.  I have an issue with gdm running too much, rather than not enough,  Perhaps slightly different.
<TheMuso> pitti: gpm is ubuntu3, I'll refresh and try again.
<TheMuso> s/refresh/update/
<ion> pitti: 2.26.1-0ubuntu2 prerm ran gdm stop, 2.26.1-0ubuntu3 postinst ran gdm reload. gdm reload doesnât seem to start gdm if itâs not running in the first place.
<pitti> persia: after an upgrade from 2.20? should also be fixed now
<pitti> TheMuso: right, known; 0ubuntu4 should fix it
<persia> pitti, Hrm.  Wasn't fixed about 5 hours ago, but I'll admit not to having logged in again since then.
<TheMuso> pitti: ok thanks.
<pitti> persia: I only fixed 2.20 (jaunty) -> 2.26 upgrade
<pitti> persia: if you have a different problem about "running too much", we need a new bug report, I think
<persia> Right.  I'll upgrade, and try a new login test in an hour or so.
<TheMuso> Gdm for me dies a random time after I log in, based on the amount of activity. Once I log in for a second time, things don't die till I reboot.
<persia> That's close to my bug, but my death was always within a second or two.
<persia> (or at least a fresh invocation occurred within that time)
<TheMuso> persia: Right.
<StevenK> pitti: So, this UNR MIR bug is getting confusing. I'd like to set the packages to a status when I've commented with a MIR, but it hasn't been checked yet -- what Status do you suggest? (And could you check one or two of the simple ones, like go-home-applet) ?
<pitti> StevenK: I'd use "incomplete" for the ones which still need an MIR
<pitti> StevenK: yes, we discussed how to handle the backlog and assign it to MIR folks, I'll do that today
<StevenK> pitti: So, Incomplete if they need one written, and New if they're good?
<StevenK> pitti: Do I need an MIR for unr-meta itself? :-)
<pitti> StevenK: unr-meta> nope, just add a task
<pitti> StevenK: right (states)
 * pitti -> i915 debugging, brb
<TheMuso> Hrm. I think update-grub needs to be made a dpkg trigger.
<StevenK> pitti: What about ubuntu-netbook-remix-default-settings? It's trivial, effectively a bunch of gconf defaults
 * TheMuso files a bug
<persia> TheMuso, There's some trickiness in handling update-grub and/or update-initramfs singly and in combination: it may be a bit before anyone can fix it (it's not as simple as one might think)
<TheMuso> persia: Right, but I'll file the bug anyway.
<TheMuso> So its on the radar.
<TheMuso> pitti: Yep, latest gpm works fine.
<StevenK> TheMuso: gpm, or gdm?
<StevenK> They are two different things :-)
<TheMuso> StevenK: gnome-power-manager to be precise.
<StevenK> TheMuso: Ahhh. I was thinking the console mouse thingy
<pitti> StevenK: for stuff like this, just add a task and set it to "new"
<TheMuso> StevenK: ah ok.
<StevenK> pitti: Already done.
<dholbach> good morning
<pitti> StevenK: do you guys still need bug 219087  (moblin-applets)?
<ubottu> Launchpad bug 219087 in libmokoui2 "MIR for moblin-applets" [Undecided,Fix released] https://launchpad.net/bugs/219087
<pitti> hey dholbach
<dholbach> hiya pitti
<StevenK> pitti: Nope.
<StevenK> pitti: Kill it.
<pitti> StevenK: done (timed out)
<StevenK> pitti: Hehe, answer quickly or your MIR gets it?
<pitti> StevenK: where "quickly" is "within half a year", yes :)
<pitti> and you can always reopen if you still want/need it
<pwnguin> is there a reason turnkey linux and ubuntu/canonical websites look nearly identical in theme / layout?
<StevenK> pitti: Fix Commited for unr-meta makes it nervous, it means component-overrides will explode.
<StevenK> s/it/me/
<pitti> StevenK: c-mismatches doesn't look at MIR bug states
<pitti> StevenK: it means "approved, but not promoted yet"
<StevenK> pitti: Oh, right. I'm happy to go through and promote things in one huge lump after it's all done
<pitti> StevenK: I think we should move them over in one batch, with unr-meta
<StevenK> pitti: Works for me.
<persia> pitti, My apologies.  While I could reproduce the gdm-appears-twice issue, I've just had a disk failure on the affected machine, and can't file the bug with ubuntu-bug.  GIven the other issues, it may be that the problem is not software-specific.
<pitti> persia: good to hear from a gdm perspective, but I'm sorry for your broken hw; good luck with getting it fixed!
<doko> slangasek: depends on g++, and g++ depends on gcc
<SiDi> directhex: can you tell me where in http://www.microsoft.com/interop/cp/default.mspx is ECMA 334 listed please ? Cant find it
<geser> pitti: re the jinja2 mir: sorry that I missed the pybabel reverse-recommends. should it be dropped from jinja2 as jinja2 is mostly used as a build-dependency and recommends don't get installed during build or should I add a mir for pybabel?
<geser> I did a quick try to use jinja2 in pygments but failed at first, perhaps I should try a little bit harder
<ojwb> mvo: I have a question about the DH_PYCENTRAL=include-links change in the xapian-bindings package
<ojwb> mvo: I was going to slot it into the Debian packaging, to avoid having an Ubuntu diff, but I'm unsure exactly what it does, and so what it should be conditional on, if anything...
<pitti> geser: pybabel> not sure what it is used for, does python-ninja2 import it?
<geser> pitti: skimming through the source jinja2 has an i18n extension which can use gettext or pybabel for translating a webpage
<pitti> geser: ah, the pygment Debian maintainer replied, he'll do the transition
<pitti> geser: sounds like it could become a suggests then
<geser> pitti: should I do an upload with this change? recommends -> suggests
<pitti> geser: please do
<pitti> geser: closed python-babel task
<StevenK> % tail -n 1 data/desktop-switcher.desktop.in
<StevenK> X-Ubuntu-Gettext-Domain=desktop-switcher
<StevenK> pitti: ^
<pitti> \o/
<pitti> StevenK: that's hardcoded upstream? (eww)
<StevenK> pitti: Therefore, I have nothing to do.
<pitti> StevenK: ok, please set back to new then
<StevenK> pitti: Upstream is effectively njpatel. :-)
<pitti> it should at least be X-GNOME-*
<pitti> anyway, good enough
<StevenK> pitti: I can get s/Ubuntu/GNOME/ to happen upstream, easy enough
<StevenK> pitti: desktop-switcher task thrown back to New
<pitti> thanks
<asac> StevenK: webfav. who will take care that this will work with ffox 3.5?
<StevenK> asac: I'll talk to Bill Filler about that.
<asac> StevenK: ok so he is the primary contact?
<mvo> ojwb: hi! the include-links means that python-central does less magic in its maintainer scripts by doing all the symlinking at build time instead of install time
<StevenK> asac: Yes, he's who I would talk to about it.
<asac> StevenK: ill open a bug and assign it to him
<mvo> ojwb: so it adds robustness and it also means that the package is immediately useful when installed/upgraded (as opposed to the default behavior where the .py files are only available after --configure and not in --unpack)
<ojwb> mvo: OK, but should that only happen for Ubuntu?  and if so, should it only be for Ubuntu karmic and newer or what?
<mvo> ojwb: I think it would be a good addition in debian too, personally I think include-links should the default
 * ojwb saw something about it requiring rebuilds for newer python versions
<mvo> for all of python-central
<ojwb> though that's clearly not a frequent issue
<mvo> yeah, that is the drawback
<mvo> but for me (robustness + available on unpack) > a rebuild every  ~18 months :)
<ojwb> seems reasonable to me
<mvo> ojwb: thanks! (and thanks for the backport of the set_data() change from 1.1 to 1.0  for enrico)
<pitti> cjwatson: FYI, the other day you asked me about disabling automount of internal disks; I located the problem now (bug 396448), working on it now
<ubottu> Launchpad bug 396448 in devicekit-disks "internal partitions get automounted on startup" [High,Triaged] https://launchpad.net/bugs/396448
<ojwb> mvo: no problem - let me know if it throws up any issues
<StevenK> asac: Oh, subscibe me to the bug?
<ojwb> if not, it should be in 1.0.14
<ojwb> mvo: hmm, presumably that wants to go in karmic...
<geser> pitti: could you please sponsor http://www.bienia.de/tmp/jinja2.debdiff ? I wasn't fast enough to upload it before it got promoted.
<pitti> oh, sorry
<ojwb> ah, feature freeze is aug 27th, so that's ok
<mvo> ojwb: when is 1.0.14 scheduled?
<ojwb> this month
<mvo> for what date  I mean
<mvo> great
<mvo> that should work then :)
<ojwb> yeah
<ojwb> it could slip to august, but not by all of august
<pitti> geser: done, thanks
<mvo> ojwb: is the patch isolated enough to put it into the ubuntu 1.0.13 so that we can give it some early testing ? would that help you guys?
<ojwb> it's isolated enough, and probably would
<ojwb> esp if you're happy to nursemaid 1.0.14 in, since it would then have an ubuntu diff to resolve
<pitti> Keybuk, Hobbsee: what did you do to get gdm started on vt1?
<mvo> ojwb: ok, that should be fine, I have a look at the upstream svn log
<Hobbsee> pitti: i turned on the machine, selected the kenel in gdm, and waited for it to boot.  ie, nothing different.
<Keybuk> pitti: when I did the demo hack?  a cross hack?
<Keybuk> but that was old gdm code
<pitti> Keybuk: in the context of bug 396226
<ubottu> Launchpad bug 396226 in gdm "GDM logs out after some minutes of typing on the keyboard" [Medium,Incomplete] https://launchpad.net/bugs/396226
<pitti> seems everyone there has gdm start on vt1 initially, and on vt7 the second time
<mvo> ojwb: its r12994?
 * ojwb looks
<ojwb> no, that's the trunk version, which won't apply to 1.0.x
<ojwb> http://oligarchy.co.uk/xapian/patches/xapian-flint-lazy-update-backport-for-1.0.patch
<ojwb> I haven't commited that to the 1.0 branch yet
<ojwb> that's the patch Enrico tested
<mvo> ojwb: ok, thanks!
<Keybuk> pitti: oh, it just does that by default
<pitti> hmm
<Keybuk> we want it on tty1 by default though, don't we? :)
<pitti> well, sure, but we didn't do that switch yet, anywhere I could see?
<Keybuk> I suspect new gdm simply behaves that way out of the box
<Keybuk> anyway, I bet I can guess what causes the crash now
<pitti> FirstVT=7
<asac> StevenK: filed, assigned upstream to bfifller and packaging task to you. 396453
<pitti> ^ in /etc/gdm/gdm.conf for me
<pitti> Keybuk: do you have "1" there?
<pitti> Hobbsee: ^
<Keybuk> pitti: no, 7 - but that's the old gdm configuration file, no?
<enrico> mvo: comments on my reply?
<mvo> enrico: I'm just in the middle of writing it :)
<pitti> Keybuk: current gdm still ships it, and settings like autologin still work
<enrico> mvo: \o/
<Keybuk> pitti: it doesn't mean it supports vt allocation, etc.
<Keybuk> I expect what's causing that bug is
<Keybuk> gdm is on tty1
<pitti> so it could be the missing ConsoleKit patch in bug 375877
<Keybuk> getty is on tty1
<ubottu> Launchpad bug 375877 in consolekit "Move *dm to VT1" [Undecided,In progress] https://launchpad.net/bugs/375877
<Hobbsee> pitti: 7 here too
<pitti> Keybuk: so getty and gdm collide?
<Keybuk> so getty will get random raw input as you type
<Keybuk> which getty will interpret as a klingon trying to login
<pitti> right, that'd explain the weird characters people saw
<Keybuk> after a few minutes, it'll timeout that login and exit()
<Keybuk> upstart will respawn getty on tty1
<wgrant> Ahaha. That explains everything.
<Hobbsee> that would do it
<Keybuk> at which point getty will call TIOCSCTTY to claim ownership of the tty
<Keybuk> and X will lose control of the tty
<pitti> Keybuk: so we just need to drop the getty on vt1?
<Keybuk> and shamelessly exit
<Keybuk> pitti: my hunch is that if you reboot, and quickly "sudo stop tty1" - you won't get auto-logged out
<mvo> enrico: be patient with me :) I want to try some of the code (like the different scan-the-database code) in order to figure out what performance charackteristis to expect
<pitti> so I still wonder why gdm starts on vt7 for me right away
<pitti> I'm using xorg-edgers, but this hardly sounds like something that X itself would do?
<Keybuk> pitti: interestingly, AutoLogin is broken for me
<Keybuk> I had auto-login enabled
<Keybuk> but after upgrading to new gdm, it doesn't work anymore
<mvo> enrico: but I really hope we can get something like "--quick-update" method that takes around the order of ~4s (on my system) so that ideally we could just run it after every apt-get update
<mvo> (or at least daily)
<pitti> Keybuk: try moving /etc/gdm/gdm.conf-custom to /etc/gdm/custom.conf ?
<seb128_> pitti, how do you see where gdm is starting with autologin?
<pitti> Keybuk: current package does that automatically, but if you had ubuntu[23] installed that migration was broken
<Keybuk> pitti: how will that help?
<Keybuk> the AutomaticLogin=scott is in /etc/gdm.conf for me
<pitti> Keybuk: gdm reads custom.conf now, not gdm.conf-custom
<seb128_> Keybuk, the autologin option is set there
<pitti> seb128_: well, I do ctrl+alt+f1 -> VT with getty, ctrl+alt+f7 -> gdm
<geser> Keybuk: auto-login still works for me with the new gdm
<Keybuk> geser: how/where is it configured?
<Keybuk> my /etc/gdm.conf has AutomaticLoginEnable=true \n AutomaticLogin=scott
<Keybuk> and it doesn't
<pitti> oh, it could be a race condition
<seb128_> pitti, I've gdm on no vt with autologin it doesn't seem to keep a greeter after login
<pitti> both gdm and getty are started on boot, and whichever gets there first gets it, I suppose
<pitti> Keybuk: ^ would that work?
<Keybuk> weirdly, I have TimedLoginEnable=true as well
<geser> Keybuk: http://pastebin.ubuntu.com/211805/ that's my /etc/gdm/custom.conf
<seb128_> my session is on vt7
<Keybuk> geser: why is it in custom.conf not gdm.conf?
<pitti> seb128_: right, but if nobody is logged in
<pitti> Keybuk: because the new gdm sucks wrt. backwards compatibility :(
<geser> Keybuk: I put it there (had it in gdm.conf-custom till now)
<Keybuk> pitti: right, but I'm confused
<Keybuk> there are THREE configuration files
<geser> as I didn't want to change the gdm.conf
<Keybuk> you're tell me to move it from config file A to B
<Keybuk> and I'm saying my config is in config file C
<Keybuk> not A or B :)
<seb128_> Keybuk, we used to use gdm.conf-custom and pitti renamed to custom.conf now
<Keybuk> which are both identically empty
<seb128_> which is the upstream naming
<pitti> Keybuk: gdm should really also read gdm.conf indeed
<enrico> mvo: ok, I like that. Forcing it to be fast, and if anything would hint at too much work to do, just do nothing
<Keybuk> seb128_: again, you're not listening
<seb128_> Keybuk, gdm.conf is upstream default, custom.conf your user changes
<Keybuk> my AutomaticLoginEnable=true is not in gdm.conf-custom *OR* custom.conf
<Keybuk> it's in gdm.conf
<Keybuk> I'm wondering why it's there
<seb128_> because you did edit it at some pointÂ§?
<pitti> Keybuk: you selected that in the installer?
<Keybuk> pitti: yes
<pitti> ubiquity used to set it in gdm.conf directly
<seb128_> iz ubiquity bog
<Keybuk> this was installed with "Automatic Login" checked in the installer
<Keybuk> ah
<Keybuk> now
<Keybuk> could *this* be causing the problem?
<Keybuk> has the config migration ended up with a mangled config file that gdm isn't reading anymore?
<pitti> Keybuk: I suppose that's it; gdm is not reading these settings from gdm.conf
<seb128_> it could
<pitti> right, what I said above
<Keybuk> and thus gdm isn't reading VTallocation=true
<Keybuk> so this would explain both why autologin doesn't work
<Keybuk> and why gdm is on tty1 ?
<pitti> gdm.conf:FirstVT=7
<pitti> gdm.conf:VTAllocation=true
<pitti> but I have exactly the same here
<Keybuk> pitti: yes, I have that
<Keybuk> what I'm suggesting is that the gdm.conf changes have been mangled in such a way that gdm is refusing to read *the entire file*
<pitti> d6e74831651b44a9fee800f3af7e2093  gdm.conf
<Keybuk> yeah, my md5sum is different, obviously
<pitti> argh
<Keybuk> pitti: interestingly, gdm's package doesn't contain gdm.conf
<pitti> dpkg -L is naughty
<Keybuk> and lists it as obsolete
<pitti> gdm does not *actually* ship gdm.conf any more
<pitti> Keybuk: heh, snap
<pitti> so it seems it only sees custom.conf
<Keybuk> so that would be another problem ;)
<pitti> and that the package update should auto-migrate the settings from gdm.conf to custom.conf
<seb128__> gdm.conf should not have settings set
<pitti> Keybuk: would you mind attaching your gdm.conf to a bug and assign it to me?
<seb128__> gdmsetup always edited gdm.custom-conf
<pitti> seb128__: right, but ubiquity set it there
<Keybuk> seb128__: but the installer *didn't*
<seb128__> hum, right
<Keybuk> seb128__: and it seems that the important VTAllocation=true is being set in gdm.conf, and not used :p
<pitti> I'll invent some crappy postinst seddery
<pitti> (for autologin migration)
<pitti> Keybuk: what does VTAllocation do?
<Keybuk> pitti: makes gdm use VTs rather than /dev/console <g>
<pitti> Keybuk: so we should set that by default in gdm itself?
<pitti> Keybuk: but either way, we do want it on vt1
<pitti> so should we just stop getty on vt1 by default?
<Keybuk> we do, but not while a getty is there ;)
<Keybuk> right
<Keybuk> though that'll annoy server people
<pitti> Keybuk: could init.d/gdm do "upstart fiddle stop vt1"?
<pitti> (even if getty@vt1 is started later?)
<pitti> phone, brb
<Keybuk> pitti: no, it only works if tty1 is started first :-;
<Keybuk> ok
<Keybuk> so I removed my gdm.conf entirely
<Keybuk> and I added the AutomaticLogin bits to custom.conf
<Keybuk> and I get auto-login
<Keybuk> and I'm still on tty1
<Keybuk> now, I've stopped the getty on tty1
<Keybuk> will see if I get a logout
<tseliot> mpt__: ping
<Keybuk> pitti: bug #396459
<ubottu> Launchpad bug 396459 in ubiquity "auto-login settings not migrated" [Undecided,New] https://launchpad.net/bugs/396459
<pitti> Keybuk: hm, gdm diverting /etc/event.d/tty1? (*shudder*)
<cjwatson> seb128_: waz, not iz
<cjwatson> oh, well, ubiquity hasn't had an upload since that change
<cjwatson> so yay for bug paperwork I guess
<a|wen> hey pitti. I have an SRU that looks like it got stuck/forgotten after verification, is that something you can take a look on? bug 362537
<ubottu> Launchpad bug 362537 in kile "[SRU] Kile crashes with SIGSEGV on entering a double quote if "abstract" is commented out" [Undecided,Fix committed] https://launchpad.net/bugs/362537
<Keybuk> cjwatson: plus we can't exactly fix this in u6y's postinst ;)
<Keybuk> pitti: move gdm to an upstart job, "stop on starting gdm" .. "start on stopping gdm" :)
<cjwatson> Keybuk: indeed
<pitti> Keybuk: ubiquity postinst> hm? the upgrade should be done by gdm.postinst, no?
<Keybuk> pitti: exactly
<Keybuk> pitti: thus my use of the word "can't" :p
<pitti> Keybuk: and "starting gdm" can only be provided if gdm itself is an upstart job?
<seb128> pitti, btw there is a new gpm tarball (not sure if you track GNOME ftp uploads)
<pitti> seb128: chrisccoulson is on it
<Keybuk> pitti: maybe
<seb128> pitti, ok good
<pitti> Keybuk: but if gdm starts first and does "stop tty1", and then rc2 finishes and triggers "start tty1"?
<pitti> (i. e. exactly what seems to happen on your and Hobbsee's box?)
<Keybuk> pitti: that's just a race
<Keybuk> but yes, I think that trying to solve this is the wrong approach
<Keybuk> instead gdm should stay on tty7
<Keybuk> since it clearly respawns there
<Keybuk> and we should only move it to tty1 when we can fix this problem properly
<pitti> okay
<SiDi> directhex: ping ?
<directhex> pong
<mr_pouit> is there a plan to split gnome-session as in unstable? (http://packages.debian.org/sid/gnome-session-bin)
<mr_pouit> Otherwise Xubuntu (for example) will end up with GNOME in the sessions' list in gdm (but since gnome isn't installed, it'll probably confuse users at best...)
<pitti> mr_pouit: no plan from our side, but if you guys need it, feel free
<pitti> ah, seems that just needs a merge then
<mr_pouit> pitti: ok, thanks, I'll try to propose a debdiff soon
<pitti> a|wen: ah, because the changelog has an invalid refrence to LP
<cody-somerville> Those Debian folks are clever cookies.
<lool> pitti: "MIR" ? "[MIR]": what about using a tag "ubuntu-mir" or "mir"?
<pitti> lool: I don't particularly mind, I just like titles to have a standard format
<pitti> easier to search and spot in your bug list, etc.
<pitti> lool: they are already at ~ubuntu-mir/+subscribedbugs
<dpm> StevenK: can I assign bug 396492 to you?
<ubottu> Launchpad bug 396492 in webfav "Once in main, webfav should be translatable in Launchpad" [Undecided,New] https://launchpad.net/bugs/396492
<lool> pitti: I prefer tags because it doesn't clutter the title and they seemed like the best tool to well tag the bugs but I'm good enough without [MIR] or tags in all cases  :)
<pitti> lool: fine for me; please add tags if they help you
<c_korn> after a kernel update in karmic there is this message that I should restart the computer now. however when I click restart then I am just logged out.
<ogra> c_korn, one of the plenty bugs with new gdm ... just reboot at the gdm screen
<c_korn> ok
<chrisccoulson> heh. the restart issue is because the new gdm doesn't ship a /usr/bin/gdm-signal anymore, which update-notifier still tries to use, I think
<chrisccoulson> not sure if anything replaces that
<ogra> i dont think /usr/bin/gdm-signal was shipped in jaunty (it was in powermanagement-interface which was dropped pre jaunty)
<ogra> i might be wrong though
<asac> cody-somerville: thanks for the vpn fixed - merged.
<cody-somerville> asac, I also fixed pptp and vpnc
<asac> cody-somerville: i mistyped: s/fixed/fixes/
<asac> :)
<cody-somerville> :)
<asac> _all_ merged
<chrisccoulson> ogra - no, you're right
<chrisccoulson> the issue is that update-notifier is still using the old GDM protocol
<ogra> i thought it was ported to dbus in jaunty
<chrisccoulson> update-notifier?
<ogra> well, the reboot notifier
<chrisccoulson> it doesn't seem like it uses dbus
<cody-somerville> mvo, does update-manager no longer have a partial dist-upgrade process? It just lists new packages to be installed as updates?
<mvo> cody-somerville: it still has this
<cody-somerville> mvo, For me it just lists new packages to be installed as updates
<cody-somerville> mvo, making it seem like they're already installed
<mvo> cody-somerville: if there are no removals, then that is its default behaviour
<cody-somerville> mvo, Is this new behaviour?
<mvo> cody-somerville: oh, you want them to be clearly labeled as new?
<mvo> cody-somerville: its the default for some time now, its required on a stable system for e.g. the kerel abi upgrades
<cody-somerville> ah
<cody-somerville> mvo, Well, it would be nice for it be clearly labelled as I was confused when it said I had updates for gnome-panel, metacity, gnome-session, etc.
<cody-somerville> mvo, when in reality the new update to gdm wants those things installed
<mvo> cody-somerville: right, makes sense
<cjwatson> mvo: FWIW if you look back a few revisions in ubiquity you'll find the port to d-bus I did there
<mvo> cjwatson: cool, thanks. I port update-notifier to it now
<mvo> s/now/next/
<c_korn> eh, firefox 3.5 is already in jaunty and karmic? why doesn't the firefox meta package depend on it, yet?
<mvo> cody-somerville: hm, I wonder what the best way to present this to the user is - just appending " (New install)" after the package name, or a alternative background, or a new heading
<cody-somerville> mvo, Since disabling one of the new packages or disabling the package that is pulling them in will disable the others, maybe the new packages should be indented under the package responsible for pulling in the new packages?
<cody-somerville> mvo, and then you could use a slight background tint and note that this package is new and being pulled in by X in the Changes tab.
<mvo> a interessting idea
<StevenK> dpm: I guess so.
 * mvo plays with it
<StevenK> dpm: I took the webfav task
<dpm> StevenK: thanks
<mvo> cody-somerville: btw, what is the plan for xubuntu with gdm? wil it move too the new gdm too?
<StevenK> asac: You'll review maximus today?
<cody-somerville> mvo, We don't have much of a choice
<cody-somerville> mvo, I'm hoping gnome-session will get split like it is in debian
<mvo> cody-somerville: right, so I can rely on the presence of the dbus interface for the reboot action in update-notifier?
<cody-somerville> mvo, Its provided by gnome-session or gdm?
<mvo> cody-somerville: I think its gnome-session, but I'm not 100% positive
<cody-somerville> mvo, I think its safe to rely on it
<cjwatson> mvo: the one I used is provided by gnome-session
<mvo> so far I kept the old way (without dbus) around for compatibility with xfce, but if that is using gnome-session too, then I can remove that code now
<pitti> mvo: not really a guide, AFAIK, but the libgudev API is quite easy and obvious
<pitti> mvo: http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/index.html is the API doc
<pitti> mvo: I can also recommend reading some example patches which port hal to gudev
<pitti> mvo: https://wiki.ubuntu.com/Halsectomy links to three for gvfs and one for network-manager
 * pitti RTFS
<pitti> mvo: so update-notifier.c just initializes the hal context, and src/hal.c works with it?
<pitti> mvo: you can just drop the stuff in update-notifier.c; you need a different method to pass the UpgradeNotifier object to src/gudev.c, though
<mvo> pitti: thanks for the links
<pitti> mvo: basically, you need to write an on_uevent() handler which listens for "block" subsystem devices (connect the "uevent" signal of the GUdevClient object to your handler, see http://www.kernel.org/pub/linux/utils/kernel/hotplug/gudev/GUdevClient.html#GUdevClient-uevent)
<pitti> mvo: and in that device handler you check for ID_CDROM property
<pitti> mvo: probably most of the code will just disappear, all the reconection/filtering stuff
<pitti> hal_mainloop_integration, etc.
<mvo> pitti: excellent, thanks
<pitti> mvo: let me know if you have any questions, I'm happy to help out
<pitti> mvo: http://bugzilla.gnome.org/attachment.cgi?id=137066&action=view has an on_uevent() handler which looks for audio CDs
 * pitti hugs mvo for hal-slaughtering
 * mvo hugs pitti for his help
<pitti> mvo: I didn't check, but it might be easier to use gvfs instead of gudev? merely looking for data CDs is easy, but if you need file/fs operations like monut/umount, you might be better off with gvfs
<mvo> pitti: I just need it to get hints on what kind of media got inserted to show the upgrade/addon CD available dialog
<mvo> so all the mounting was done already at this point
<pitti> mvo: right, what I meant is that gudev will tell you about new and changed devices, not when they get mounted/unmonuted
<pitti> so u-m could pick up the device change event before gvfs can mount it
<mvo> isee
<pitti> that's why I meant that gvfs (or e. g. /usr/include/gnome-disk-utility/gdu/gdu-device.h) might be easier
<pitti> mvo: I haven't used the gdu API myself
<pitti> mvo: but e. g. /usr/include/gnome-disk-utility/gdu/gdu-pool.h defines a GduPool    *gdu_pool_new(), which has a device_added signal
<pitti> and hal-like volume/drives
<pitti> mvo: and then you can do all the volume operations in /usr/include/gnome-disk-utility/gdu/gdu-device.h
<mvo> ok, thanks
 * mvo pokes around in gdu-dev
<geser> TheMuso: are you working on liblouis? I'd like to upload a fix to make liblouis-dev installable again (and while I'm at it also some fixes from your MIR)
<cjwatson> mvo: oh, thinking of this, how do you think a dynamic equivalent of apt's current reliance on /cdrom might work? I'd love to not have to add that fstab entry in the installer any more
<cjwatson> mvo: e.g. how evil would it be for apt's cdrom method to link against dbus? would you want that to be a separate helper instead?
<cjwatson> I think for Debian at least it would need to be able to try a few different methods rather than just relying on DK-disks
<mvo> cjwatson: I would prefer to have a seperate helper for now
<cjwatson> mvo: if it's in the same package, of course, it wouldn't make a lot of difference :)
<cjwatson> maybe it could dlopen dbus
<pitti> well, it would merely link against libdbus
<pitti> it doesn't need to depend on d-bus itself
<mvo> having it optional would be really nice, I have a look
 * mvo is almost finished with dropping libgnome from update-notifiers dependencies
<higuita> Hi... i just check that the key in the pt.archive.ubuntu.com seens to be reporting as invalid, can anyone confirm if that is the correct key?
<ogra> we still dont have a bzr branch for initramfs-tools, right ?
<cjwatson> no
<cjwatson> pitti: that's what I meant
<ogra> thanks
<NCommander> http://launchpadlibrarian.net/28640480/buildlog_ubuntu-karmic-armel.kdebase-workspace_4%3A4.2.95-0ubuntu2_FAILEDTOBUILD.txt.gz - anyone what could cause pkgstriptranslations to hang (or at least take so long that the build times out?)
<brettalton> I'm editing a release timeline for Ubuntu on Wikipedia (http://en.wikipedia.org/wiki/Template:Timeline_Ubuntu_Linux)
<brettalton> and I'm having trouble finding when the start development date of any release is.
<brettalton> e.g. Development of Hardy Heron 8.04 started on YYYY/MM/DD
<brettalton> The best resource I can find is: https://wiki.ubuntu.com/HardyReleaseSchedule but it doesn't give me an exact date
<brettalton> Does anyone have a better resource I can use?
<mido> Hi. I'm looking for the kernel config file of the Jaunty Install-CD kernel. Any idea where I could find it? It doesn't seem to be in the casper directory with all the other stuff.
<asac> StevenK: what wm did UNR use before?
<Ampelbein> brettalton: i think it's safe to assume that work on a specific release began on the day the toolchain was uploaded.
<NCommander> mido, the live CD uses the same config as the normal kernel
<brettalton> Ampelbein: exactly, do you know how I can find out those dates?
<mido> NCommander: Ah! Thanks. I wasn't aware of that. This makes things easy for me...
<NCommander> mido, (its the same kernel, just a different initramfs)
<cjwatson> brettalton: well, depends what you mean by "work"
<mido> Perfect.
<Ampelbein> brettalton: it's on the page you mentioned for Hardy. Look at the "notes" field
<cjwatson> brettalton: (I'm not being entirely facetious here, bear with me)
<cjwatson> brettalton: for quite a few releases now, we've been working on the next release along since the very day the previous release happened
<cjwatson> brettalton: in fact, toolchain preparation work usually starts earlier
<ogra> pitti, is it ok with you if i just add the four lines to check for a chroot from start to restart in hal's initscript, or do you prefer a check_chroot() function ?
<cjwatson> brettalton: we usually send a mail to ubuntu-devel-announce once the archive is open for developers in general to upload, so if that's what you mean, you should be able to mine the list archives for that information
<cjwatson> but I'm not sure it's accurate to describe that as the starting development date - for that as worded, I'd just give the previous release date myself
<pitti> ogra: OK for me, I don't particularly care
<ogra> good, i'm lazy ... just copy paste it is then :)
<brettalton> cjwatson: thank you. Sorry, the HardyReleaseSchedule was a mistake to give you, I meant to give you ones like Warty, Breezy, etc. I'm just trying to think of the best way to represent the beginning of development in a chart without making the dates up in my head. But I agree the release of one version constitutes the beginning of the next.
<pitti> Keybuk: I just updated bug 396226; what would you recommend, should I add a hack to gdm to always forcibly start X on vt7? or should we change /etc/event.d/tty1 to not start if gdm or kdm are running? or fix getty to not allocate the VT if it is already taken by X?
<ubottu> Launchpad bug 396226 in gdm "GDM logs out after some minutes of typing on the keyboard" [Critical,Triaged] https://launchpad.net/bugs/396226
<pitti> Keybuk: (right now, gdm doesn't have any code for VT handling; it entirely relies on X to grab the next free one)
<Keybuk> pitti: how would we detect whether gdm are running, etc.
<Keybuk> it all worked when X started on tty7
<pitti> pidof gdm-binary
<Keybuk> so we should just fix that bit first as a short-term solution
<Keybuk> and then look into better solutions
<pitti> right, it's just quite intrusive, so I wanted to check if you see another option
<Keybuk> pitti: that wouldn't cause the getty to *go away* if X was started on tty1
<pitti> Keybuk: we don't need that
<ogra> pitti, pushed
<pitti> we need getty to fail if X is on vt1 already (ideally)
<Keybuk> pitti: yes you do, it's when getty times out the login that it kills X
<pitti> since getty starts later than X
<Keybuk> no, it doesn't ;)
<pitti> it does
<Keybuk> if getty started later than X, then getty starting would kill X
<Keybuk> so because X isn't getting killed before it even gets started, it must be actually starting after X
<pitti> well, getty is started at the end of rc2.d/*, isn't it?
<Keybuk> bear in mind that when X starts is not when gdm starts
<enrico> mvo: I don't feel much about "full reindex of more than X changed"
<cjwatson> brettalton: well, I was thinking of in practice as well as in a sort of constitutional sense :-) I'm usually one of those working on the next release more or less from the moment the last one's done ...
<mvo> enrico: ok, I can just add a ~20% value in then or something
<mvo> (or leave it out entirely, I don't really mind :)
<cjwatson> brettalton: in earlier cycles we weren't quite so quick to get restarted, and usually had a few days of break, although even then I believe folks were working on initialising the new archive (I just wasn't involved in that stage back then)
<Keybuk> pitti: I would much rather fix this properly later than implement some dirty gross hack now
<enrico> mvo: I have't read your patch yet, but from reading the mail, I was thinking: what if with --quick we only update data that is tied to versions
<Keybuk> that will only make my life harder when I actually try and fix it properly
<enrico> mvo: and all the other data, we update it weekly
<mvo> enrico: that sounds like a nice and simple way of doing it
<enrico> mvo: therefore, with --quick we don't need to do that thresholding
<enrico> mvo: also, for those packages whose version changed, we can still update the non-version-specific data
<brettalton> cjwatson: well if you're curious to see what I was working on, here it is:
<brettalton> cjwatson: previous chart: http://en.wikipedia.org/w/index.php?title=Template:Timeline_Ubuntu_Linux&oldid=298580025
<brettalton> cjwatson: updated chart: http://en.wikipedia.org/w/index.php?title=Template:Timeline_Ubuntu_Linux&oldid=300800384
<enrico> mvo: which, as a side effect, turns a --quick into a full update if the index is empty
<pitti> Keybuk: right, that's what I'm discussing
<pitti> Keybuk: I don't know how to tell X "don't use vt1"
<Keybuk> pitti: so just revert whatever bit caused X to suddenly think tty1 was a good place to be
<ogra> gah, cjwatson was faster than me with initramfs-tools ... /me redownloads the latest source and starts over
<Keybuk> pitti: it's not X is it, it's gdm
<pitti> Keybuk: that would mean to revert to gdm 2.20 :)
<mvo> enrico: excellent, I think my patch pretty much implements this behaviour :) the switch just needs to be renamed from --update to --quick
<pitti> Keybuk: the old gdm had lots and lots of code, including VT handling, and passing the vt to X
<enrico> mvo: I'm happy to keep it to --update
<pitti> Keybuk: the new one dropped all that and just relies on X autodetection
<mvo> enrico: \o/
<Keybuk> pitti: but X doesn't do any VT detection either
<Keybuk> X just starts on whatever console it's given
<pitti> Keybuk: I tried adding a chvt 7 to gdm's init script, and then it started on vt8
<pitti> Keybuk: ok, I'll try to find a hack within gdm; just wanted to check whether you see an easier method; thanks!
<cjwatson> brettalton: can we get it not called "Ubuntu Linux", since that isn't what the distribution is called? :)
<Keybuk> pitti: all the easy methods involve disabling tty1 if gdm is installed ;)
<cjwatson> brettalton: yours is certainly a lot closer to reality though
<cjwatson> ogra: I uploaded that hours ago ...
<pitti> Keybuk: are you sure about X not doing autodetection? If I start "X" on vt1 in a bash, it starts on vt9
<Keybuk> pitti: I bet it it's something simple in X
<Keybuk> like if you start X when the current tty has a framebuffer, it uses it
<ogra> cjwatson, yes, i pulled the source this morning ... thats what you get if you get distracted by a ton of other stuff :)
<Keybuk> otherwise it starts a new vt and then switches to that
<pitti> Keybuk: so starting getty implies losing the fb?
<ogra> ... and dont monitor -changes close enough
<pitti> s/starting/having/
<Keybuk> pitti: ?
<pitti> Keybuk: well, all VTs have a KMSified fbcon
<pitti> so I wonder what makes a VT different whether or not getty is running
<brettalton> cjwatson: No problem, I just took it out now. The timeline was previous done by another user (who is Spanish I believe) and has had some problems translating. But I thank him very much for his work as he has created extensive timelines for almost all major distributions
<pitti> since if it isn't running, apaprently X grabs vt1, otherwise vt7
<Keybuk> pitti: entry in utmp?
<pitti> and I think I need to understand this in order to figure out how to fix it
<Keybuk> hmm
<Keybuk> better question for you
<Keybuk> why does X end up on vt7 after gdm respawns it ? :)
<pitti> Keybuk: ah, ./hw/xfree86/os-support/linux/lnx_init.c, xf86OpenConsole() detects it
<tgpraveen> can someone tell me whether delta debs are being worked on for karmic?
<pitti> Keybuk: because then getty is running and "takes" the vt, AFAIUI
<tgpraveen> it would be really useful to have and the sooner the more helpful to testers.
<pitti> Keybuk: but after boot with usplash, getty isn't running yet when gdm/X start
<Keybuk> pitti: getty doesn't really "take" anything
<Keybuk> it does claim ownership of the console device
<Keybuk> and that's what kills X
<Keybuk> which is why I'm puzzled that it doesn't happen on boot
<Keybuk> if it's because getty isn't running, then when getty starts, X will get killed
<Keybuk> which is precisely what we see on timeout
<cjwatson> brettalton: looks like he was (a) not counting beta->final as development (which has its merits as a viewpoint but was confusingly presented) (b) unclear on how much development we'd done before going public with warty ;-)
<pitti> ok, if that's the case, then I have no explanation what maes the first getty different from the following one
<cjwatson> tgpraveen: not deltas as such, but https://blueprints.launchpad.net/ubuntu/+spec/rsync-based-deb-downloads
<pitti> Keybuk: I tries to open(ttyN, O_WRONLY) until it succeeds
<pitti> Keybuk: meh, s/I/X/
<pitti> so apparently "taking" a vt means that opening for writing fails
<Keybuk> err
<Keybuk> why would opening /dev/tty1 for writing fail?
<pitti> crw------- 1 martin tty     4,  1 2009-07-07 16:43 /dev/tty1
<pitti> crw--w---- 1 root tty 4, 9 2009-07-07 16:27 /dev/tty9
<pitti> could have somethign to do with the missing tty write privs, not sure?
<pitti> I'm just reading the code in X
<brettalton> cjwatson: lol, very true. I'm a heavy editor of the Ubuntu Wikipedia page (at least the releases part) so I have many of these dates documented and even memorized (!)
<pitti> Keybuk: but I rather suspect that you can just open it for writing once, and getty already did?
<pitti> (since neither X nor gdm have a particular affiliation to the tty group)
<Keybuk> I just set my tty to 666
<Keybuk> X still went to 7
<pitti> would be interesting to see the errno for that open()
<brettalton> cjwatson: Here is the colour scheme that I copied: http://www.markshuttleworth.com/wp-content/uploads/2008/05/ubuntu-release-cycle.png... thank you sabdfl
<enrico> mvo: mind if I remove the obsolete packages before doing the rest of the indexing? That should give Xapian a chance to reuse the disk space freed
<brettalton> cjwatson: I was also the nerdy one who put 4.10 to 8.04 in a virtual machine to take consistent screenshots of the dektop + nautilus as seen here: http://en.wikipedia.org/wiki/List_of_Ubuntu_releases
<Keybuk> pitti: oh
<Keybuk> I see the code you're confusing
<Keybuk> it's not opening all of the ttys
<pitti> open("/dev/tty0", O_WRONLY)             = 7
<Keybuk> it's opening all of the different names for the _current_ tty
<pitti> open("/dev/vc/9", O_RDWR|O_NONBLOCK)    = -1 ENOENT (No such file or directory)
<Keybuk> (/dev/tty0)
<pitti> open("/dev/tty9", O_RDWR|O_NONBLOCK)    = 7
<pitti> open("/proc/mtrr", O_WRONLY)            = 8
<pitti> aah
<Keybuk> and then it's doing a VT_OPENQRY on it
<enrico> mvo: I like your patch a lot!
<_lemsx1_> will the next release of Ubuntu support ksplice?
<mvo> enrico: sure, please shuffle it around as you like (and what is best for xapian)
<pitti> Keybuk: ok, so there are two methods AFAICS: either allocate the vt earlier (with getty) or supply a "vt" argument to X for the first time
<mvo> enrico: thanks :)
<Keybuk> pitti: do we run usplash on tty1 now?
<pitti> Keybuk: should be on 8
<pitti> not sure, though
<pitti> Keybuk: nothign in usplash itself changed since jaunty, though (except KMS detection)
<Keybuk> right, but why would VT_OPENQRY suddenly return 1 instead of 7
<brettalton> cjwatson: Anyway, keep up the good work! I hope to join you once I'm done my CS degree :)
<tgpraveen> cjwatson: thx for the link. what is the difference between delta debs and what this blueprint says?from the blueprint it seems they are both same
<cjwatson> brettalton: cool :)
<pitti> Keybuk: what does "start on stopped rc2" mean?
<pitti> Keybuk: when all rc2.d/S* are done?
<Keybuk> yes
<cjwatson> tgpraveen: as I've heard them described, delta debs would require precomputing the difference to the current package in the archive from any of various different versions which the user might have installed
<Keybuk> pitti: I think there's something else going on here still
<pitti> Keybuk: sure, then getty just starts after gdm
<Keybuk> my test program just returned 7 at the point gdm is started
<Keybuk> not 1
<cjwatson> tgpraveen: zsync is more flexible - it can, in principle, cope with any currently installed version, although of course the greater the difference the more it has to download
<Keybuk> *something* is telling gdm or X to start on tty1
<Keybuk> not 7
<tgpraveen> cjwatson: ok.thx for clearing that up.
<cjwatson> liw: ^- (just in case you want to chip in since you're the spec assignee)
<liw> cjwatson, you're correct
<Keybuk> pitti: either that or the definition of ownership of a console has changed
<Keybuk> oh, wait
<Keybuk> I was thinking "otherwise why didn't X get started on tty1 before?"
<Keybuk> but it didn't get started there because gdm had lots of insane code to do the VT allocation for X
<Keybuk> new gdm doesn't have that code
<pitti> right, all of that went away
<Keybuk> so it's new gdm making X start on vt1 by virtue of losing all the smarts
<pitti> that's what I meant with "go back to 2.20"
<pitti> we could pass a "vt7" argument to Xorg in gdm for the first time as a hack
<Keybuk> and until getty creates it, there is no tty1
<Keybuk> adding "start on runlevel 2" to /etc/event.d/tty1 makes X go to vt 7 :p
<Keybuk> interestingly
<pitti> finally believe me? :-)
<pitti> anyway
<Keybuk> it's not that I don't believe you
<pitti> I wonder whether there's a way for getty to "see" X on vt1
<pitti> and just exit
<Keybuk> pitti: I was just thinking that
<pitti> Keybuk: (just kidding, sorry)
<Keybuk> and pulling up the getty source to see
<Keybuk> I'm actually interested to why getty only sometimes kills X
<Keybuk> if I start a getty on tty7 it doesn't
<pitti> as a last resort I'll add a "vt7" to gdm's XOrg invocation the first time, but that's not a robust solution
<pitti> Keybuk: getty just exiting, wouldn't that cause an eternal loop in the upstart event.d?
<pitti> ("respawn")
<Keybuk> pitti: it'd hit the respawn limiter
<pitti> ah, nice
<Keybuk> but we could just add a magic exit code to make that not respawn
<Keybuk> exit (60) if the VT is in use
<pitti> can you say "respawn until exit with 99" or so?
<Keybuk> and put "normal exit 60" in the tty1 file
<Keybuk> yes
<pitti> cool
<pitti> \o/
<pitti> â¥ upstart :)
<enrico> mvo: ok. The first --update run done in a system with an existing database will rebuild everything because there is no version information in the database
<enrico> mvo: and it'll take all the time of a full rebuild
<enrico> mvo: the subsequent updates, should be very fast indeed
<Keybuk> I wonder what it is about getty that kills X
<enrico> mvo: if you want to avoid this, I can change the code in "if there is no version info in the xapian db, consider it unchanged"
<enrico> mvo: that way, the first --update will do nothing, until the weekly rebuild will rebuild with version info
<enrico> mvo: from that moment on, --update will DTRT
<enrico> mvo: which one do you prefer? Rebuild everything at first --update, or enable --update only after the first weekly rebuild?
<mvo> enrico: I like rebuild everything on first update (slightly) better
<enrico> mvo: ok
<enrico> mvo: I found a way to speed up database read *considerably*. It's "only print progress every 5000 packages instead of every 200" :)
<mvo> heh :)
<mvo> really? excellent!
<enrico> mvo: at least when using --verbose, and I didn't do timing, just my feeling
<enrico> mvo: I'll tweak it for another bit, then I'll push it
<mvo> enrico: great, thanks
<enrico> mvo: any idea of speed improvements in using a set for 'unchanged' instead of a dict, and a list (or set) of docids for obsolete instead of a dict?
<enrico> well, I should just test it
<mvo> enrico: I guess its just very small, but measuring it makes sense - you can try the ExecutionTime object, so having "with ExecutionTime("building dict"): block-of-code
<mvo> enrico: that will print how long this particular block ran (within the limits of the precision of time.time() of course :)
<enrico> mvo: it's... SLOWER
<mvo> enrico: that is ... suprising :)
<enrico> mvo: it's very tiny differences, maybe it's just all under the tolerance of the measurement tools
<enrico> mvo: I'm just testing with time ./testrun, because I only want to bother with measureable performance gains
 * mvo nods
<enrico> mvo: I prefer to have a function that returns 3 dicts than a function that returns a set a dict and a list, if there is no relevant difference in terms of performance
<mvo> enrico: absolutely, the other would be confusing
<mvo> pitti: gdu is a thing of beauty! src/hal.c             |  245 ++++++++------------------------------------------
<pitti> mvo: :-)
<enrico> mvo: gdu?
<mvo> enrico: gnome-disk-utils
<mvo> enrico: a new lib that replaces (parts of) hal
<enrico> mvo: --update properly falls back to showing the progress of an existing full update run
<enrico> mvo: I give up. I can't find anything else to improve on your patch, I'll just have to release it :)
<pitti> mvo: hm, but with gdu instead of devkit-disks you probably need to write a KDE counterpart? or don't they use update-notifier any more?
<mvo> enrico: haha - wonderful
<mvo> pitti: they have something on their own in python now
<pitti> ah
<enrico> mvo: how do you plan to invoke it with --update? Be careful of #516728
<mvo> enrico: initially it will replace the code in synaptic that tries to figure out when is a good time to run it. I will have to think a bit more how to integrate it into apt, but it should certainly be part of the daily apt cron job IMO (that is optional to the user to enable that or not)
<enrico> mvo: right. It can be left out of apt and delegated to those package managers that use apt-xapian-index
<enrico> mvo: also, since running --update does nothing if nothing has changed, package managers can just call that at startup or after every apt-get update
<enrico> mvo: did you do anything like post-update apt hooks in the end?
<enrico> mvo: I recall an idea of an experimental patch, but I don't recall if it went anythere
<enrico> mvo: (btw, I pushed your patch and my small changes to collab-maint)
<mvo> enrico: (sorry I was on the phone) - yeah, there is a post-update hook now in libapt (that is run after apt-get update)
<enrico> mvo: is there documentation about it? I'd like to run a debtags thing on it
<enrico> mvo: that extracts tags from packages
<enrico> mvo: I don't know if it'd be worth running update-apt-xapian-index --update in it as well, with a hook that detects if it's in a chroot (but maybe it's still too slow at this stage)
<enrico> mvo: I was also thinking: when downloading PDiffs, how hard would it be for apt to generate a list of package names/versions affected by the changes? It could be fed to debtags and apt-xapian-index to speed up incremental updates even more
<dholbach> can I interested somebody in giving a Packaging Training session at 09th July, 12:00 UTC?
<mvo> enrico: I have to look into that for the pdiffs (but dinner is calling)
<enrico> mvo: if from pdiffs apt can generate a list of (pkg, version) for added and upgraded packages and (pkg, "") for deleted packages, update-apt-xapian-index can have an even quicker update that avoids doing a full scan of both the apt and the xapian databases
<enrico> mvo: ok, guten apetit!
<ion> I thought we werenât going to use pdiffs because apt-sync would be so much better.
<a|wen> pitti: yeah, managed to mess up that changelog entry a bit :/ ... but thx for taking care of it
<gigabytes> hello
<gigabytes> are there plans to port synaptic to policykit?
<ion> There are plans to replace Synaptic AFAIU.
<gigabytes> uh really?
<ion> https://wiki.ubuntu.com/AppCenter
<gigabytes> thanks
<gigabytes> will it use polkit?
<ion> That page answers your question. :-)
<gigabytes> yes it is XD
<kirkland> pitti: ping
<kirkland> pitti: regarding https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/359447
<ubottu> Ubuntu bug 359447 in kvm "kvm segfaults" [High,Fix committed]
<kirkland> pitti: there's a package that's been in -proposed for a very long time
<kirkland> pitti: there's one more patch that i need to add to the package, related to this problem
<kirkland> pitti: actually, critical to solving this problem
<kirkland> pitti: i'd like to upload that to -proposed, with the new patch
<kirkland> pitti: can I go ahead and do that?  or should i wait for the previous upload to be migrated?  or propose a new sru?  or what?
<pitti> kirkland: no, the first patch doesn't seem to have really solved it, so no point moving that first
<pitti> kirkland: just upload a newer version to -proposed
<pitti> kirkland: it's the same bug#, right?
<kirkland> pitti: thanks
<kirkland> pitti: yes
<pitti> kirkland: if not, please build with -v<version in updates for final> to include the previous changelog, too
<pitti> ok, should be fine then
<kirkland> pitti: i have verification from users testing the package in the ppa
<kirkland> pitti: so i'll push to proposed
<Sarvatt> any way g-p-m can be made less chatty so as to not fill .xsession-errors with 10MB of spam every day? :D
<pitti> Sarvatt: what does it say?
<pitti> $ grep power .xsession-errors
<pitti> Checking for non power of two support: present.
<pitti> and that's from compiz startup, I think
<Sarvatt> its filled with the output that you get running gnome-power-manager from the command line, i'll pastebin a portion of it
<pitti> Sarvatt: I guess it's the same message over and over?
<Sarvatt> http://pastebin.com/d86b87c3
<Sarvatt> yeah
<Sarvatt> 10MB worth for 22 hours uptime
<pitti> WTH?
<ogra> looks like lshal output over and over
<Sarvatt> g-p-m eventually crashes with this same error ever since the switch to devicekit-power too
<Sarvatt> (gnome-power-manager:3275): GLib-GObject-CRITICAL **: g_value_get_uint: assertion `G_VALUE_HOLDS_UINT (value)' failed
<Sarvatt> (gnome-power-manager:3275): GLib-GObject-CRITICAL **: g_object_get: assertion `G_IS_OBJECT (object)' failed
<ogra> that one i got too
<ogra> but nt the noise you have
<ogra> *not
<Sarvatt> well its the same output i get running g-p-m in a terminal, just getting routed to .xsession-errors for some reason
<pitti> Sarvatt: are you sure that you have gnome-power-manager 2.27.1-0ubuntu4?
<Sarvatt> ahh pitti I'm really sorry, it could be my package messed up, I forgot I wasn't using the ubuntu one because I was testing newer versions to see if it was fixed
<Sarvatt> 2.27.2-0ubuntu0sarvatt
<pitti> ah
<pitti> Sarvatt: you need a no-change rebuild against current devicekit-power
<pitti> or use latest upstraem version, that should fix it as well
<Sarvatt> indeed, it doesn't flood .xsession-errors with the ubuntu g-p-m, sorry again
<tormod> ogra, the initramfs-tools upload was pretty broken, I guess you noticed when testing it?
<ogra> tormod, ?
<Sarvatt> (gnome-power-manager:3339): devkit-power-gobject-WARNING **: No 'lid-is-present' property errors now though
<ogra> tormod, can you elaborate ?
<tormod> ogra, the patch introduced a grep which 1) has no input 2) has a broken RE
<ogra> meh, i relied on lool having tested it its a very old patch
<tormod> ogra, there's a missing : in the last [] and probably a missing filename
<cjwatson> that'll break all architectures then
<ogra> works fine here
<cjwatson> oh, if grub/lilo is installed then it'll return from the function before hitting it
<ogra> right
<cjwatson> will probably break in chroots without a bootloader, in that case
<tormod> I have a bootloader and I get the error message: grep: Unmatched [ or [^
<ogra> hmm, that code shouldnt be run for you
<ogra> did you modify kernel-img.conf ?
<tormod> no
<ogra> it surely doesnt get run for me
<ogra> i see the error though
 * ogra fixes
<tormod> ogra, the reason that I reach this code is that I have no grub executable
<ogra> ah
<ogra> colon and filename added, thanks a lot for the heads up
<tormod> you're welcome. should I have a grub exe now that I use grub2?
<ogra> well, i use grub2 here and the code isnt run
<ogra> but i dont have any grub i can execute
<tormod> did you upgrade from grub to grub2?
<ogra> yes
<ogra> did you freshly install ?
<tormod> you have menu.lst left behind?
<ogra> i think i wiped that manually at some point
 * ogra checks
<ogra> ah, no, still there
<tormod> that's why you don't reach the code
<ogra> yeah
<ogra> i guess that needs updates for grub2
<ogra> heh, someone really liked awk in the mbr_check() function
<chrisccoulson> mr_pouit - just looking at bug 396657
<ubottu> Launchpad bug 396657 in gnome-session "Please split gnome-session (binary // scripts files)" [Undecided,New] https://launchpad.net/bugs/396657
<chrisccoulson> i'm currently doing a gnome-session update, so i can do the split too
<cjwatson> grub-pc indeed does not ship /sbin/grub
<cjwatson> perhaps checking for /usr/sbin/update-grub would be appropriate
<mr_pouit> chrisccoulson: ah, that would be better (I don't use GNOME), thanks. I've already some minimal changes in a bzr branch if you want them.
<chrisccoulson> thanks, i can take a look at those
<chrisccoulson> mr_pouit - so, the issue is that gnome-session currently pulls in things like gnome-settings daemon and gnome-panel is it?
<chrisccoulson> (just so i fully understand)
<mr_pouit> chrisccoulson: yeah, something like that, some testers reported that they had gnome instead of xfce on the isos
<chrisccoulson> mr_pouit - i'll take a look at that then. i'd already taken a look at the debian split, but we've stopped syncing gnome-session with debian for now because they're introducing too many other wierd changes with it at the moment
<chrisccoulson> but this split looks ok
<mr_pouit> (probably because of a dependencies/recommends chain with gdm 2.26 & gnome-session)
<mr_pouit> ok, thanks.
<mr_pouit> chrisccoulson: I pushed to lp:~mrpouit/gnome-session/ubuntu-split-bin-scripts
<chrisccoulson> thanks
<ogra> cjwatson, well, lool had the idea to just rely on kernel-img.conf's postinst_hook entry directly and drop the whole if/then litany, it was pretty elegant but requireds discussion with debian-boot i guess
<ogra> *requires
<cjwatson> debian-boot doesn't maintain initramfs-tools, but sure
<ogra> oh, i thought it did
<cjwatson> the list name is historical - debian-kernel maintains initramfs-tools
<cjwatson> debian-boot maintains the installer
<ogra> ah
<ogra> well, it was mentioned in the bug i puled the patch out
<ogra> *pulled
<Riddell> pitti: how come apport isn't enabled?
<ogra> Riddell, not yet :)
<Sarvatt> theres pretty huge differences between ubuntu's and debian's initramfs-tools
<ogra> Sarvatt, well, we still pull from debian, just not everythin
<ogra> g
<Sarvatt> 0.92b is over a year old, they've had 17 releases since then
<cjwatson> sure, we haven't merged in some time
<cjwatson> largely because now it's a big hairball of a merge
 * ogra must say he hasnt missed anything either 
<cjwatson> I'm not too worried about it - we have some different goals
<cjwatson> though obviously it'd be good to get merged up
<ogra> indeed, would save lots of work
<Sarvatt> http://git.debian.org/?p=kernel/initramfs-tools.git;a=commit;h=254a54d61d3e2c5463798fa29280c3d1d24c49bf
<Sarvatt> ?
<cjwatson> heh, yeah
<ogra> thouh i suspect it will change a lot again with the boot speedup stuff
<cjwatson> ogra: if you're fixing your upload, could you cherry-pick the above commit please?
<ogra> my fix is already up, but i got it open in front of me ...
<pitti> Riddell: so far it was still too early and shaky to do so; new versions get uploaded every day, fixing crashes, etc.
<pitti> Riddell: so far the plan was to enable it for alpha-3; you want it earlier?
<ogra> oh, i didnt even know about comand -v
<Riddell> pitti: I just wondered what our policy was.  currrently we have some experimentalish KDE stuff that has bugs going upstream when they should come to us
<Riddell> pitti: but this'll give me something to talk about in my GCDS session tomorrow :)
<pitti> Riddell: we don't really have a policy so far, just "gut feelings"
<ogra> uploaded
<tormod> ogra, I think you meant "previous" and not "next" in the changelog :)
<Sarvatt> the i915 fixes in debian's initramfs-tools would be nice to have, i've seen alot of bug reports from people just adding i915 to /etc/initramfs-tools/modules and it doesnt work with our version because it doesnt automatically load intel_agp before it
<Sarvatt> but its not that big a deal now with how things are in karmic, was just an issue before
<Sarvatt> oh theres an update to that commit i linked earlier
<Sarvatt> http://git.debian.org/?p=kernel/initramfs-tools.git;a=blobdiff;f=update-initramfs;h=8c085a57eae76aa4f1f22c00fd9d29d903a907fb;hp=2eed8cb7d37285383d9c3807f8182bc037bd776b;hb=89257a84d0bfcd46d5514c65245b7b3f57f67ddf;hpb=ff34476ecd5de0da1104b13e6b42e6cc9eff8792
<ogra> tormod, yes, i'm tired
<ogra> tormod, i have quickly hidden it with another upload :)
<Sarvatt> update-initramfs: Generating /boot/initrd.img-2.6.31-rc1-sarvatt
<Sarvatt> dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead.
<Sarvatt> dpkg: warning: obsolete option '--print-installation-architecture', please use '--print-architecture' instead.
<ogra> Sarvatt, wow, how do you get these warnings ?
<ogra> (i see the code and have '--print-installation-architecture' here as well, but never get such warnings)
<Sarvatt> probably related to the fact i'm using kernel-package 12.014 I guess
<ogra> sounds rather like a newer dpkg
<ogra> karmic has 1.14.24ubuntu2
<Sarvatt> it started with initramfs-tools 0.92bubuntu35 that says something about checking kernel-img.conf thats part of kernel-package is why i was guessing that
<Sarvatt> dpkg                                                 1.15.3ubuntu1?
<tormod> dpkg --print-installation-architecture complains here also, 1.15.3ubuntu1
<ogra> hmm, i didnt upgrade today, when did we get dpkg 1.15
<Sarvatt> 15.2 and 15.3 both today
<ogra> oh, i see, cjwatson was busy today
<Sarvatt> wow now that is a _monster_ of a changelog
<Sarvatt> on 15.2
<superm1> bryce, hmm.  why is a karmic sbuild (on PPA) failing to setup xserver-xorg as a  build depend because of starting hal?  http://launchpadlibrarian.net/28771398/buildlog_ubuntu-karmic-amd64.mythtv_0.21.0%2Bfixes20810-0ubuntu0%2Bmythbuntu4_FAILEDTOBUILD.txt.gz
<superm1> is hal really needed in the xserver-xorg postinst in the first place?
<ogra> superm1, try with the new hal
<ogra> i just uploaded a fix
<superm1> ogra, ah well that was a PPA, so i'll just wait for the PPA to update I suppose
<ogra> 0.5.12+git20090626-0ubuntu3 is what you want
<bryce> aha
<slytherin> can any of the archive admins please give preferential treatment to doxia-sitetools in new queue? I am waiting for it to fix some other maven related packages.
<c_korn> can compiz related questions be asked here or is there a special channel?
<slytherin> c_korn: is it about use of compiz?
<c_korn> it is about a bug that can be fixed by changing the compiz settings. I don't know if the problem is with compiz, the apps or drivers.
<c_korn> see this bug 384582
<ubottu> Launchpad bug 384582 in vlc "vlc-1.0.0~rc2: Wallpaper is shown when compiz enabled, fullscreen and moving mouse" [Undecided,Invalid] https://launchpad.net/bugs/384582
<chrisccoulson> mr_pouit - how does the file-manager and panel start in xubuntu? the only reason i ask is because even with the gnome-session split, gnome-session will try and run gnome-panel, nautilus and metacity, because they are listed as required components in the default gconf settings. Obviously, they won't run if they aren't installed, but gnome-session will spit out a warning on each session start
<Xhema> who can approve my translation queue here? https://translations.launchpad.net/shqipoffice/+imports
<mr_pouit> chrisccoulson: they are started by xfce4-session
<chrisccoulson> thanks:)
<slytherin> c_korn: try asking on #compiz, check if it is a known problem.
<chrisccoulson> i might download the xubuntu live CD and have a play around with it
<c_korn> slytherin: ok, thanks
<cjwatson> Sarvatt: our initramfs-tools should automatically load intel_agp and i915 all by itself
<kees> pitti: \o/
<ogra> cjwatson, given that i seem to have initramfs-tools day today, want me to change the two occurences of --print-installation-architecture to --print-architecture to quieten down the new dpkg ?
<cjwatson> ogra: yes please
<slangasek> bryce: I'm puzzled that xserver-xorg-input-all (and therefore xserver-xorg-input-synaptics) is no longer pulled in by default - is this intentional?
<cjwatson> Xhema: maybe try #ubuntu-translators?
<cjwatson> Xhema: or possibly #launchpad, not sure
<cjwatson> Xhema: actually yeah, I'd think more likely #launchpad in the first instance, since it's not in the Ubuntu namespace
<Xhema> thanks
<Xhema> cjwatson, i am waiting now. i think it will take time
<Xhema> but translators is a good idea
<cjwatson> Xhema: you could also try https://answers.launchpad.net/rosetta if you don't get a quick answer on IRC
<Xhema> i can wait
<Xhema> it is ok
<Xhema> we can also translate with po edit
<Xhema> its ok!
<bryce> slangasek, one sec
 * ogra feels ignored on Bug #391094
<ubottu> Launchpad bug 391094 in glibc "the "stale NFS file handle" error should be reworded" [Undecided,New] https://launchpad.net/bugs/391094
<mterry> cjwatson, evand, Heyo, I think the oem-config->ubiquity branch is pretty decent these days.  What's the best way to start reviewing it and testing it (beyond the testing I've done)?
<tjaalton> slangasek, bryce: seems like a merge goof to me; xserver-xorg Depends on -evdev first, then -input-all | -input-5
<tjaalton> make that -input-4
<bryce> slangasek, I don't see a lot entry about it
<tjaalton> so evdev satisfies the latter already
<bryce> tjaalton, has the input version number changed?
<tjaalton> bryce: no, but what I said :)
<tjaalton> I'll poke jcristau
<bryce> comparing current xorg to jaunty's, I don't spot a change here
<bryce> tjaalton, thanks
<evand> mterry: I can have a look over it tomorrow.  I imagine cjwatson will want to check it out as well before we merge it into trunk.
<mterry> evand: for sure.  lots of changes
<mterry> evand: it's lp:~mterry/ubiquity/oem-config-merge
<evand> indeed, thanks.  Perhaps propose it for merging into trunk so we can have a recorded conversation of any further needed changes.  We haven't used that part of launchpad much in the past, but this would be a good opportunity to start.
<mterry> evand: will do, good point
<evand> great, thanks
<cjwatson> mterry: I'll check it out and have a look, thanks
<tjaalton> slangasek, bryce: a fix uploaded
<bryce> sweet
<mvo> cjwatson: I poked around a bit about the dynamic cdrom method for apt and it seems like libudev is the natural choice for this, I guess a addional dependency on this should not really hurt
<slangasek> tjaalton: ah, cheers :)
<kirkland> james_w: around?
<james_w> aye
<kirkland> james_w: would you mind proofreading this for me?
<kirkland> http://pastebin.ubuntu.com/212258/
<kirkland> james_w: i'm about to send that to kvm, qemu, and libvirt mailing lists, cc'ing ubuntu-devel
<james_w> kirkland: looks good to me
<kirkland> james_w: thanks
<james_w> though you might want to tell them how to "point a user at it"
<james_w> if there is a wiki page or something with instructions then it would be easy for them to pass the user on
<billybigrig> hey all, is anyone alive?
<billybigrig> i need to ask a question, brand new alpha 2 install today, and now im getting 1:06 boots, because of a hung devkit-disks-pa
<billybigrig> i know this isn't the place for support but could someone give me a heads up on where to start troubleshooting? no one in +1 can seem to help out
<billybigrig> http://imagebin.ca/view/aJcM-F.html
<billybigrig> is my bootchart
<billybigrig> i can't find anything pertaining to devkit-disks in my logs
<Ampelbein> billybigrig: what version of devicekit-disks do you have installed?
<billybigrig> apt-cache policy devkit-disks
<billybigrig> can't find it
<billybigrig> but devkit-disks --dump will output info, so i know its installed
<Ampelbein> billybigrig: the package is named devicekit-disks. not devkit-disks.
<billybigrig> devicekit-disks:
<billybigrig>   Installed: 005-0ubuntu1
<billybigrig>   Candidate: 005-0ubuntu1
<billybigrig> thanks
<ion> billybigrig: https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/384579 perhaps
<ubottu> Ubuntu bug 384579 in linux "Linux thinks thereâs a floppy drive when thereâs not. Probing slows down bootup by almost a minute." [Medium,In progress]
<billybigrig> hmm
<billybigrig> \blacklist floppy module i guess
<billybigrig> :P
<ion> Which computer is it, btw?
<ion> A Thinkpad?
<billybigrig> no
<billybigrig> desktop
<ion> If blacklisting the floppy driver helps, please report that (saying itâs not a Thinkpad) to the bug report, so itâs clear Thinkpads arenât the only computers affected by it.
<billybigrig> k
<ion> Attaching /var/log/dmesg (when the floppy driver is not blacklisted) to the bug report would be nice as well.
<billybigrig> added blacklist floppy to blacklist-floppy.conf and rmmod floppy
<billybigrig> rebooted, still getting the slow boot
<billybigrig> anyone care to take a look at my bootchart?
<ion> Run update-initramfs -u, perhaps the initramfs still loads the floppy driver.
<billybigrig> k lsmod doesn't show it
<billybigrig> rebooting now
<billybigrig> http://imagebin.ca/view/KnkS5il.html
<billybigrig> 0:19
<billybigrig> :)
<billybigrig> :D
#ubuntu-devel 2009-07-08
<Snova> The link at the end of the topic is broken, probably because you seem to have hit the limit. :)
* cjwatson changed the topic of #ubuntu-devel to: gdm breakage: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-July/000586.html | 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.
<cjwatson> blink, pitti's client obviously allows a longer length than mine
* cjwatson changed the topic of #ubuntu-devel to: gdm breakage: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-July/000586.html | Archive: open | DebianImportFreeze in effect | Development of Ubuntu (not support, not app development on Ubuntu) | #ubuntu for support and general discussion for dapper-jaunty | #ubuntu-motu for getting involved in development | http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://wiki.ubuntu.com/HelpingWithBugs
<cjwatson> hopefully gdm won't be an issue by the time alpha-3's released
<slangasek> any bug numbers for that which ought to get milestoned?
<coolbhavi> hello team if nobody has any objections I ll prepare diffs for some packages affected by https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/391165
<ubottu> Ubuntu bug 391165 in dpkg "Dpkg::Deps mishandles newlines in Build-Dependencies" [Undecided,Fix released]
<lifeless> how do you choose login language now?
<RAOF> Down the bottom of the GDM screen there's a listview.
<RAOF> A _dreaded_ listview :).  Maybe we can make gdm crash :)
<RAOF> This only appears when you've selected a user to log in as, though.
<lifeless> not with todays gdm :P
<lifeless> OTOH I'm getting other errors all over the place
<RAOF> Heh.  I think I might still have gdm -ubuntu3 here, so...
<wgrant> RAOF: Do you know of a bug about the listview crasher?
<RAOF> wgrant: Yeah; it's...
<RAOF> bug #391398
<ubottu> Launchpad bug 391398 in gtk+2.0 "Applications segfault with gtk+ version 2.17.2 when selecting listbox values" [High,Confirmed] https://launchpad.net/bugs/391398
<wgrant> RAOF: Thanks.
<RAOF> It's apparently gtk using deprecated APIs internally, and missing the crucial difference between an int and a pointer.
<wgrant> Haha.
<wgrant> It's also incredibly annoying.
<RAOF> Yes.
<wgrant> I can't *quite* work out how to trigger it.
<RAOF> There are some git commits referenced in that report, and, of course, sizeof(int) == sizeof(void *) for IA32.
<RAOF> wgrant: Evolution is the best way of triggering it that I've found.
<wgrant> RAOF: Some listboxes only do it when you manipulate them in a particular way.
<wgrant> The OS selector in virt-manager, for example.
<RAOF> Yeah.
<wgrant> It's usable unless you use it wrong.
<RAOF> Which is why I haven't rolled a local gtk package with those git commits added; it's insufficiently annoying.
<RAOF> It's _just_ easy enough to work around :)
<wgrant> Yep.
<maxb> There'd be a PPA one by now, if the buildds weren't supersaturade
<maxb> *supersaturated
<wgrant> Yes...
<wgrant> All those daily builds, and only three guaranteed buildds per arch...
<ajmitch> wgrant: be glad it's not daily builds of bigger packages
<wgrant> ajmitch: They are pretty big...
<ajmitch> it shouldn't be so easy to cause a permanent backlog
<maxb> I suppose it could be worse. It could be dailies of OOo :-)
<ajmitch> maxb: I was thinking of that one, as well as ooo-l10n :)
<Sarvatt> just hoping noone is trying to build 3 gcc's in there or else we'll be out another entire day :D
<wgrant> Or a Linux or three.
 * maxb wishes for bug 155758
<ubottu> Launchpad bug 155758 in soyuz "Global PPA +builds would be useful" [Medium,Triaged] https://launchpad.net/bugs/155758
<wgrant> Unfortunately that wouldn't be reliable now.
<Sarvatt> i'd put $10 on theres at least 10 linuxes lined up in that i386 queue
<wgrant> As there are lots of P3As.
<Sarvatt> its the new fad :D
<wgrant> That bug has a nice activity log.
<maxb> Unless P3A builds just vanish the builder from the builders page, there don't seem to be that many P3A builds
<wgrant> maxb: The builders appear with a red X next to them. Sometimes there are lots, but sometimes there are none.
<maxb> ok - I've not seen that for PPA builders very often
<maxb> So I think a PPA +builds would still be adequately useful
<wgrant> Maybe I just look at it at bad times.
<wgrant> It would certainly still be useful.
<dholbach> good morning
<dholbach> pitti: can you merge  ~chrisccoulson/gnome-power/2.27.2-update  into  ~gnome-power-manager-team/gnome-power/trunk ?
<dholbach> (I should have checked before, but I thought "it's going to be a ~ubuntu-desktop branch I can push to")
<pitti> Good morning
<pitti> cjwatson: hm, /topic looks fine for me indeed
<pitti> but I think we can remove the gdm link tomorrowish
<pitti> dholbach: pulled, and debcommit -r'ed; thanks!
<dholbach> pitti: thank chrisccoulson :)
<pitti> I will (and did yesterday), but not online ATM :)
 * TheMuso sees that keyboard backlight devices/ambient light sensor support was removed, and wonders why, since the git log doesn't go into any detail.
<TheMuso> from gnome-power-manager that is
<pitti> TheMuso: this is currently a bit in flux
<pitti> TheMuso: we don't use hal any more, and devkit-power doesn't have/isn't supposed to have that
<pitti> the correct solution is to have this in X itself (XBACKLIGHT)
<TheMuso> ah ok
<pitti> http://lists.freedesktop.org/archives/devkit-devel/2009-July/000268.html FYI
<TheMuso> tah
<pitti> asac: did you see the "also introduces a bug" report in bug 220628 ?
<ubottu> Launchpad bug 220628 in libxcb "[MASTER] firefox-3.0b5 received an X Window System error: 'BadIDChoice'" [Medium,Fix committed] https://launchpad.net/bugs/220628
<pitti> sbeattie: thanks for all the vm-builder tests! I think it's good enough to move to -updates now
 * mvo hugs sbeattie too
<sbeattie> pitti|mvo: thanks, and I agree, it should go to -updates.
<pitti> nice, 335 days in -proposed
<TheMuso> ...oh and wow, what an argument. :)
<\sh> moins
<pitti> TheMuso: was pretty heated indeed :/
<\sh> dear devs, please get rid of klibcs ipconfig for kernel nfs root mounts...it's really a pain in the a** *gnarf*
<\sh> ipconfig + low cost table switches == works like a charm, but using cisco switches with spanning trees and portfast configs etc. it gives you really nightmares
<\sh> the timeframe between bringing the NIC up and the first dhcp request from ipconfig is too fast and then it failes mostly with a kernel error: can't mount nfs rootfs , setting the timeout up to 180 secs (which should be more then enough to have ipconfig retry it's request) is not even enough...-t 240 to -t 360 is the only way to force ipconfig to redo the request...but that's far too long
<YokoZar> jcastro: who is in charge of the web server?  there's a bug with videos.ubuntu.com
<YokoZar> (it's showing wrong MIME type, labeling the videos as text/plain, so this happens (except in Firefox): http://i41.tinypic.com/14ub8xz.png
<persia> YokoZar, You might try a bug against ubuntu-website (although it may be different)
<YokoZar> persia: yeah i just had that thought
<YokoZar> thanks
<dholbach> are there bugs open for gdm-login-twice and gdm-gnome-session-can't-remember-bla?
<pitti> dholbach: for the latter, yes
<pitti> dholbach: for the former, what do you mean?
<dholbach> the popup I get after logging in
<dholbach> gnome-session couldn't save your bla something gdm-simple-greeter
<dholbach> hiya chrisccoulson
<pitti> dholbach: right, that's "the latter", and has a bug
<pitti> dholbach: I mean "login-twice"?
<dholbach> ah sorry :)
<chrisccoulson> hi dholbach
<pitti> hey chrisccoulson
<dholbach> when I log in, it starts doing something, then I get the login window again
<chrisccoulson> hi pitti
<dholbach> so I have to log in twice
<persia> dholbach, I had that, and TheMuso had that.  I had a hw failure when reproducing, and haven't filed.  If you do file, please subscribe me.
<dholbach> hm, no /var/log/gdm?
<dholbach> pitti: clearer now?
<ion> Iâm sorry, but i snickered at âI had a hw failure when reproducingâ.
<pitti> dholbach: ah, bug 396226
<ubottu> Launchpad bug 396226 in gdm "GDM logs out after some minutes of typing on the keyboard" [Critical,Triaged] https://launchpad.net/bugs/396226
<pitti> dholbach: that was extensively discussed, and the problem is understood, but not quite trivial to solve
<pitti> dholbach: workaround: disable "splash"
<dholbach> pitti: I'm not sure I have that problem - it's not several minutes
<pitti> well, it depends what you are doing
<dholbach> I boot, get gdm, log in, it does something for 1-2 seconds, then gives me the login window again
<pitti> dholbach: and then it never crashes again?
<dholbach> no, then I can go ahead and do my stuff
<pitti> ok, sounds like that bug then
<pitti> dholbach: try booting without splash, that should fix it
<dholbach> ok, I'll try with the next reboot
<dholbach> thanks pitti
 * pitti hugs dholbach
<dholbach> more power to the pitti!
<geser> dholbach: is your other problem bug #395324?
<ubottu> Launchpad bug 395324 in gdm "'These windows do not support "save current setup"....' metacity warning when logging in with gdm 2.26" [Medium,Triaged] https://launchpad.net/bugs/395324
<dholbach> geser: yes, I guess so
<persia> pitti, just with nosplash on the kernel cmdline?
<pitti> persia: drop "splash"
<persia> OK.  Booting with "nosplash" fixed it for me.  Trying again without any mention.
<ajmitch> pitti: interesting, which gdm versions does that problem affect?
<pitti> ajmitch: >= 2.26
<ajmitch> I'm guessing it only affects some people, since I haven't had a problem since rebooting
<persia> Booting without any mention of splash fixes it as well.
<geser> ajmitch: check on which tty you currently are on: tty1 or tty7
<ajmitch> persia: I know I have splash set, I had to wait through a fsck of 450GB
<ajmitch> geser: X reports being on tty7
<geser> ajmitch: then you are lucky
<persia> ajmitch, Dunno then.  Just started happening to me yesterday on karmic.  Doesn't happen anymore without splash.
<geser> it only happens when gdm and getty fight for tty1 and gdm loses
<ajmitch> sounds like a fun bug to solve
<persia> geser, Amusingly, I have X on tty7, once it works.
<persia> Well, easy way to fix it is just to get the boot fast enough that we don't need splash, which I understood to be the goal.
<geser> yes, it only happens to the first gdm, after one gets kicked gdm takes tty7
<chrisccoulson> pitti - would you like to review the changes in https://code.edge.launchpad.net/~chrisccoulson/gnome-session/ubuntu ? It splits gnome-session in to 2 packages now. With the current single package, the new GDM dependency on gnome-session causes a broken gnome to be started on Xubuntu instead of xfce
<pitti> chrisccoulson: right, this was discussed yesterday; is this a Debian merge? (they did the split)
<chrisccoulson> the split is basically taken from debian, with a couple of minor changes. they also moved all the autostart files from /etc/xdg/autostart to /usr/share/autostart, which hasn't been copied across
<chrisccoulson> and i put the helpers in gnome-session instead of gnome-session-bin, although these need splitting some more, as GDM requires the g-s-d helper it seems
<chrisccoulson> and i've just noticed the gnome-settings-daemon dependency needs to move from gnome-session to gnome-session-bin, as that seems to be required by GDM too
<ogra> cjwatson, please merge (once again) https://code.launchpad.net/~ogra/debian-cd/ubuntu ... for the armel kernel version bump
<ogra> i'D really like to find a way to automate that ... even if its only screen scraping the d-i changelog
<chrisccoulson> mr_pouit - i merged your changes on the gnome-session split last night
<chrisccoulson> this would still leave you with 2 session managers on the default install though wouldn't it?
<pitti> mvo: btw, did you see my reply in bug 392074?
<ubottu> Launchpad bug 392074 in apport "better client side apport_kernelcrash support" [Low,Incomplete] https://launchpad.net/bugs/392074
<dholbach> pitti: confirmed (gdm-login-twice)
<mvo> pitti: I had this spec on hold until some linux-meta fixes, sorry - I will answer in the report, but the summary is that its (or seems to be) useful if the user wants to do a local retrace
<pitti> mvo: it shouldn't; well, let's discuss it in the bug repor
<pitti> t
<mvo> pitti: maybe I don't understand apport well enough, but its seems to me that adding the information right away is cheap and useful.  it shouldn't means that it should not include this information?
<mvo> we can as well talk here, its probably quicker :)
<pitti> mvo: no, but the information you want (and more) is already collected
<mvo> so fater a reboot the vmcore is converted to a crash file. at this point not a lot of info is there
<pitti> right, you need to process it through apport
<mvo> now if the user wants to run apport-retrace on this that will fail until it got processed further
<pitti> (... UI)
<mvo> so this should not be a supported use-case? or should apport-retrace add the info? or should it be first go through the UI and then do a local retrace?
<pitti> mvo: phone, bbl
<mdz> dholbach, happens to me too
<mdz> is there a bug report for gdm-login-twice?
<Laney> bug 396226?
<ubottu> Launchpad bug 396226 in gdm "GDM logs out after some minutes of typing on the keyboard" [Critical,Triaged] https://launchpad.net/bugs/396226
<dholbach> mdz: the workaround is to disable 'splash'
<persia> Laney, That's not the same bug.
<dholbach> persia: pitti said it was
 * persia rereads the bug again
<persia> Hrm.  I'm not sure how the race could persist for minutes, but perhaps.
<ogra> hmm, isnt gdm supposed to run on tty1 with the latest upgrade ?
 * ogra still has it on tty7
<cjwatson> ogra: merged that debian-cd branch, thanks. The way to automate it is to get the kernel fixed so that we don't need it
<ogra> cjwatson, indeed, but i was looking for an interim solution
<ogra> the prob is that i only notice it a day after the builds failed
<dupondje> damn gotto love flash :( NOT :(
<ogra> and i dont want to trigger .1 builds ... just because i forgot once again to notice the d-i upload on -changes
<ogra> though i'm starting to care for armel builds again, shouldnt be that often anymore if i'm really caring
<cjwatson> ogra: ok, I've killed off the hardcoding
<cjwatson> (though haven't tested the new code straight-through)
<ogra> oh !
<ogra> wow, thanks
<ogra> i also noticed that someone already added the subarchitecture (armel+imx51) code to make-web-indicies :)
<highvoltage> wow, switching between a VT and X on karmic is super fast.
<StevenK> And that's one reason KMS is win
<highvoltage> StevenK: totally :)
<pitti> re
<pitti> ogra: no, it's not really supposed to run on vt1, since it conflicts with getty there
<pitti> mdz: ^
<pitti> mvo: re
<pitti> sorry, that was a long phone call
<ogra> i though getty was gone in favour
<enrico> mvo: any news on pdiff? Did you test the curret git of a-x-i? Can I just go ahead and upload?
<pitti> mvo: (answered)
<cjwatson> Keybuk: I have a udevd here which appears to be refusing connections from udevadm - I don't know if I'll be able to reproduce this, so is there anything I can do to debug things before I reboot?
<cjwatson> (this is in d-i)
<cjwatson> Keybuk: actually, they don't even seem to be getting the message from udevadm at all, judging from strace
<cjwatson> it's like they've fallen off the Unix socket namespace or something
<mdz> pitti, hmm?
<cjwatson> ah, a udevd segfaulted somewhere ...
<Keybuk> cjwatson: that's odd, normally it tends to go away on a segfault ;)
<cjwatson> I guess some bit of it did but the rest hung around in a broken state
<cjwatson> Keybuk: well, bug 396957, I don't know if there's anything useful that can be done with that but just in case
<ubottu> Launchpad bug 396957 in udev "udevd segfault after "worker did not accept message" and "worker unexpectedly returned with 0"" [Undecided,New] https://launchpad.net/bugs/396957
<Keybuk> cjwatson: I wonder whether the daemon died and left some workers?
<cjwatson> yes, it looks like it
<Keybuk> do you have a copy of "ps" at the time?
<cjwatson> at which time?
<Keybuk> at the time you thought "oh, this has died"
<Keybuk> also, no core dump?
<Keybuk> have you looked in /var/crash?
<cjwatson> it's got four "udevd --daemon --resolve-names=never" processes
<cjwatson> do you need the whole thing?
<Keybuk> sure, but the details of those four would be quite interesting
<cjwatson> no /var/crash in d-i
<Keybuk> ah, in d-i
<Keybuk> damn
<Keybuk> no /core ? :)
<cjwatson> no, sorry :-/
<Keybuk> can you attach dmesg to that bug report (not dmesg log)
<Keybuk> oh, it's ok
<cjwatson> done, and ps output too
<cjwatson> I think dmesg all just goes to syslog though
<Keybuk> yeah looks like it
<cjwatson> Keybuk: if it's relevant, it's possible that udevadm trigger may be involved here, since the point where it failed is shortly after d-i installs extra udebs into memory which may contain new kernel modules
<cjwatson> that may just be coincidental though
<cjwatson> hmm, I don't suppose we keep separated debugging symbols for udebs anywhere ...
<cjwatson> we do! bloody hell
<cjwatson> pitti++
<cjwatson> pitti: is there any way to get back from "udevd[663]: segfault at 4 ip 00959fbc sp bfbe7b78 error 6 in udevd[94f000+1c000]" to a line of source, assuming that I have the corresponding udevd with debugging symbols loaded in gdb?
 * pitti scratches head
<cjwatson> I assume relocation is going to screw me over somehow
<Keybuk> yeah you need a core file
<Keybuk> of course, "segfault at 4" is a bit damning in of itself ;)
<cjwatson> oh, is that an address? :)
<Keybuk> yes
<Keybuk> well
<Keybuk> it's _supposed_ to be the address ;)
<Keybuk> "info symbol" might help
<cjwatson> so it is
<Keybuk> I assume it's karmic?
<cjwatson> yes
<cjwatson> udev-udeb 143-8
<cjwatson> (i386)
<pitti> list *(address) could also help
<cjwatson> info symbol what?
<pitti> would the IP be a valid address?
<cjwatson> it doesn't like either 0x00959fbc or 0x1c000
<pitti> list *(00959fbc) ?
<Keybuk> cjwatson: i386 or amd64?
<cjwatson> 11:56 <cjwatson> (i386)
<cjwatson> pitti: nope
<pitti> I used that for kernel panics and traces
<cjwatson> 0x00959fbc - 0x0094F000 == 0xAFBC
<cjwatson> which is apparently udev_list_node_remove + 11
<cjwatson> that being 0x0000afbc <udev_list_node_remove+11>:  mov    %edx,0x4(%ecx)
<cjwatson> and udevd.c:handle_signal calls udev_list_node_remove right after the last error message from udevd in the log
<Keybuk> that sounds totally plausible
<Keybuk> where did you get the 94f00 from?
<cjwatson> udevd[94f000+1c000]
<Keybuk> interesting
<cjwatson> I guessed that that was a relocation base address
<cjwatson> indeed it's vma->vm_start in the kernel
<Keybuk> the next one being the size, I assume?
<cjwatson> vma->vm_end - vma->vm_start
<cjwatson> so yes
<cjwatson> (this is print_vma_addr in mm/memory.c)
<Keybuk>         next->prev = prev;
<Keybuk> would be the crashing line then
<cjwatson> or prev->next = next; ?
<Keybuk> no, that one
<Keybuk> info line *0xafbc
<Keybuk> Line 76 of "../../udev/libudev/libudev-list.c" ...
<cjwatson> ah, good call
<cjwatson> Keybuk: is there anything more that might be extractable from the running image, or can I reboot it?
<Keybuk> cjwatson: I don't think so :-/
<cjwatson> bit of an exercise in telepathy
<cjwatson> ok, let's see if it happens again ...
<liw> mvo, python-apt is deprecating some stuff; is there a transition guide to convert them to new stuff?
<cjwatson> Keybuk: oho, it happened again
<cjwatson> let me see if I can make it happen a third time but this time with a core dump
<Keybuk> cjwatson: neat
<cjwatson> hmm. lots of workers unexpectedly exiting, but the daemon isn't crashing after ulimit -c unlimited ...
<cjwatson> damn! I reproduced it and then alt-f4'ed kvm by accident
<cjwatson> hate that keybinding
<Keybuk> doofus
<cjwatson> while :; do update-dev; kill -HUP $udevd_pid; done # seems to trigger it eventually
<ion> pkill -HUP udevd? :-)
<cjwatson> d-i
<ion> Alright
<cjwatson> thanks but there's no need to educate me in tools that I know about and also know are not available in this context ;-)
<cjwatson> and in any case I explicitly don't want to kill the udevd children, only the parent
<ion> Right
<mvo> enrico: no news on pdiffs, sorry. but I tested it and it looks fine
<cjwatson> gotcha
<mvo> liw: no formal one afaik, but julianK may be preperaring one. its bascily "installVersion" -> install.version
<liw> mvo, ok, I'll how that works for me
<cjwatson> Keybuk: core dump on the bug now, though I'm having no luck at getting gdb to take it here
<enrico> mvo: ok, then I'll just upload it as it is, and we can do an extra improvement step if the pdiff way is viable
<evand1> cjwatson: Do you not use -no-quit?
<evand1> in KVM, that is
<mvo> enrico: excellent
<cjwatson> evand1: I may do from now on :)
<cjwatson> I didn't know about that
<evand1> I think we all find out about it the hard way
 * Keybuk weeps about how needlessly hard utmp/wtmp is
<ion> Yeah
<Keybuk> at least I finally figured out why "last" thinks all rebooted Upstart-based machines "crashed" :-)
<Keybuk> cjwatson: mind applying http://people.ubuntu.com/~scott/d-i-udev-crash.patch and trying again?
<tjaalton> is it ok to rebase an SRU candidate with the stable debian version, if the packages are derived from the same version?
<cjwatson> Keybuk: thanks - rebuilding
<cjwatson> tjaalton: not usually - keep the change minimal
<tjaalton> cjwatson: ok, I
<tjaalton> hrm
<tjaalton> I'll just snatch the patches then
<Keybuk> cjwatson: at the very least, this will add a message saying why it's about to crash :p
<djsiegel_> pitti: ping
<pitti> hey djsiegel_
<djsiegel_> pitti: sorry, as soon as I contact you I get interrupted...
<djsiegel_> 2 minutes...
<djsiegel_> pitti: ok
<djsiegel_> pitti: openSUSE, Jolicloud, and now moblin are integrating Do
<djsiegel_> pitti: I have a lot of feedback from UNR users who installed Do and put it to great use
<djsiegel_> I think it's even being considered for UNR already
<djsiegel_> Mark asked me 8 months back about putting in main, and I said -1 because it's kind of an advanced user app
<djsiegel_> but I am getting a lot of pressure from GNOME at GCDS to put it in GNOME (I think they are determined to)
<djsiegel_> so, I think we should talk about shipping it with karmic
<pitti> djsiegel_: hm, I haven't used it myself, but it seems to me that gnome-shell does a lot of this as well?
<djsiegel_> pitti: no, it's very different
<djsiegel_> pitti: and are we shipping gnome-shell in Karmic?
<pitti> djsiegel_: not by default, but it'll be available
<ogra> we would if upstream did
<djsiegel_> Do is tested, translated, and has millions of installs
<djsiegel_> gnome-shell will not be on in 2.28
<djsiegel_> it indexes your online contacts, docs, twitter friends, etc etc etc
<pitti> using tracker?
<djsiegel_> no, its own indexer
<pitti> uh
<djsiegel_> Mark said he was for it, and to talk to you, Keybuk and Ivanka
<pitti> we made lots of bad experience with tracker and beagle
<pitti> is gnome-do more lightweight in indexing all your files?
<djsiegel_> Tracker doesn't index your online life
<Laney> how do we make do discoverable to new users?
<pitti> (and it seems utterly hard to get file indexing right)
<djsiegel_> pitti: it's not file search
<pitti> djsiegel_: right, I know; does gnome-do index your local files?
<pitti> ah, ok
<djsiegel_> pitti: yes, you can set it to
<djsiegel_> for example, index just your desktop, or your docs folder 2 levels deep
<Keybuk> djsiegel_: my main concern is how long it'd take to start
<ogra> pkgmaintainermangler: Not overriding Maintainer for domain lists.ubuntu.com
<ogra> dpkg-deb: warning: 'debian/libgl1-mesa-dri-dbg/DEBIAN/control' contains user-defined field 'Original-Maintainer'
<ogra> dpkg-deb: ignoring 1 warnings about the control file(s)
<djsiegel_> Keybuk: I don't suggest turning it on by default
<ogra> hrm, whats that ?
<djsiegel_> just putting it in Accessories
<pitti> djsiegel_: I'm pretty much against indexing your files by default, but anything other than that I'm open (CD space constraints apply, of course)
<djsiegel_> pitti: it doesn't index by default
<Keybuk> djsiegel_: if you start it from Accessories, how do you configure it to start on startup if you like it?
<djsiegel_> just your apps
<djsiegel_> by default
<djsiegel_> Keybuk: in the Do prefs, you check the "Start at login" checkbox
<Keybuk> djsiegel_: ok, easy enough then :)
<Keybuk> I'm all for it
<ogra> Session terminated, killing shell...make: *** [binary-arch] Terminated
<ogra>  ...killed.
<ogra> Build killed with signal 15 after 150 minutes of inactivity
<ogra> mumble
<Keybuk> ogra: why did your build have a terminal session open? :)
<ogra> Keybuk, ask infinity :P he maintains the armel buildds ...
<djsiegel_> I am not crazy about it, I don't think it's the future of the desktop or the perfect app or great for all users, but EVERYONE seems to be shipping it and making at least some of their users happy, so it seems like we should have it too.
<ogra> Keybuk, i was always suspecting he secretly sits in the DC and plays nethack on the armel builder consoles to interfere with the builds :)
<djsiegel_> I mean, if GNOME Do is being used to make any linux offering more attractive, it should be the linux offering of the company I work for and believe in.
<pitti> djsiegel_: ok, then it seems the remaining question is to find a maintainer for it
<djsiegel_> pitti: find a maintainer?
<Keybuk> djsiegel_: for the packaging
<djsiegel_> pitti: Chris Halse Rogers
<ogra> no, but honestly, why does pkgmaintainermangler hang for 150 min
<djsiegel_> pitti: RAOF on freenode
<pitti> djsiegel_: for keeping up with the bugs, packaging, testing in Ubuntu, etc.
<djsiegel_> yes, basically our entire project targets ubuntu
<Laney> it's maintained in the CLI apps team :)
<cjwatson> RAOF does Ubuntu stuff
<djsiegel_> we have 5 core contributors, all use ubuntu, and we target all of our releases to land in ubuntu
<Keybuk> ok, easy next step then
<Keybuk> one of them should write a MainInclusionReport for it
<pitti> that sounds good
<Keybuk> and they should talk with Colin or Steve about CD sizes requirements
<pitti> apt-get install gnome-do pulls in 6.7 MB
<pitti> that's very heavy
<cjwatson> *choke*
<Keybuk> yeah, that may need to be addressed
<pitti> gnome-do-plugins is 5.7
<cjwatson> perhaps drop gnome-do-plugins to Suggests?
<cjwatson> half a megabyte for gnome-do itself still probably means one fewer language on the CD, but is a bit more tolerable
<pitti> (one MB)
<Keybuk> pitti: really, what else is it depending on that f-spot and tomboy don't already?
<pitti> libevolution5.0-cil libgdata1.4-cil libgnomedesktop2.20-cil librsvg2-2.18-cil libwnck2.20-cil
<djsiegel_> we could drop some plugins
<tgpraveen> in the gnome 3 work flow. do might not be required just my 2 cents
<pitti> libgnomedesktop2.20-cil should disappear anyway
<pitti> it's deprecated
<djsiegel_> split out the community plugins should drop 3-4mb
<Keybuk> djsiegel_: even 3MB is a lot of ask for the CD
<Laney> there is a plugins split waiting for a Debian upload
<Keybuk> djsiegel_: the CD is full, any new thing added means something comes off
<pitti> right now, it's really oversized
<pitti> because we removed all langpacks
<pitti> but that's a temporary hack
<pitti> (we have some better solutions up our sleeve, though)
<djsiegel_> :) of course you guys do
<cjwatson> tgpraveen: as indicated in the discussion above, this is being discussed for the time being rather than as a permanent addition
 * ogra always wondered if these solutions are less in summer where the sleeves are shorter ... or do the sleeves just get wider ?
<kenvandine> pitti, how do you feel about making python-distutils-extra put files in ./bin into /usr/bin?
<djsiegel_> cjwatson tgpraveen, this is definitely a temporary move to satisfy user demand
<djsiegel_> I did not want to push this at all, but I am now being pushed
<tgpraveen> djsiegel_: so have it in karmic and then not in karmic+1(if gnome 3 is included with it)? wouldnt it be better to include this just in in UNR
<pitti> kenvandine: that should already happen
<tgpraveen> it seems to have more use in that situation
<kenvandine> nope...
<kenvandine> it takes any scripts in the current dir and installs them in /usr/bin/
<kenvandine> not stuff in ./bin/
<djsiegel_> tgpraveen: well, Do's advantage is made clearer on netbooks
<pitti> kenvandine: hm, it should be exactly the other way round
<djsiegel_> tgpraveen: I am heard it's going into UNR, I am talking about Desktop
<pitti> kenvandine: all exectuable scripts in ./bin, and ./<projectname>, nothing else
<djsiegel_> I have heard*
<seb128> what is the discussion about there?
<Laney> putting Do in the default desktop
<pitti> seb128: including gnome-do to the default install
<seb128> hum
<kenvandine> pitti, oh... i figured it out
<seb128> need to think about that but I'm not sure how the GNOME people would take that
<kenvandine> quickly created a script of the same name in the current dir
<kenvandine> the same name as what i had in bin
<kenvandine> so nevermind :)
<djsiegel_> seb128: GNOME is pushing me really hard for GNOME inclusion
<seb128> djsiegel_, does it fit with the gnome-shell vision?
<djsiegel_> seb128: I was told they already discussed it and want it
<djsiegel_> seb128: I don't know if it's going to be a part of the long term shell vision
<seb128> ah ok
<seb128> I guess it makes sense meanwhile
<djsiegel_> I am just being overwhelmed at GCDS by Novell, Moblin, GNOME, jolicloud to integrate Do
<seb128> not sure about how gnome-shell and gnome-do woult fit together though
<djsiegel_> yeah, me neither
<cjwatson> Keybuk: with Kay's patch, the initial 'udevadm settle' on d-i startup just sits there and never seems to terminate
<seb128> the thing is that we pretty much planned changes for karmic now
 * cjwatson attempts to get some debugging
<seb128> and a lts is not the best cycle for such changes
<seb128> maybe we should try to push it for karmic if we want it before the next lts
<djsiegel_> yes, I am talking about karmic
<seb128> interesting ;-)
<seb128> pitti, should be discuss that next week during the meeting
<seb128> be -> we
<cjwatson> Keybuk: "handle_ctrl_msg: udevd message (SETTLE) received" and then it just sits there
<pitti> seb128: I think so
<pitti> it's not very intrusive in terms of planned specs
<pitti> just for CD space, but that can be solved first
<Keybuk> cjwatson: could you add that to the bug
<cjwatson> sure
<cjwatson> sorry, need to curb my debug-on-IRC habits :)
<seb128> re, sorry karmic crashed when pluggin power and closing lid
<Laney> the recommends get bigger with the new docklets package that comes with 0.8.2
<directhex> question
<directhex> are we still shipping an rdesktop client by default?
<ogra> tsclient iirc
<persia> At least there was one on my karmic install, although I haven't done a new install in a few weeks.
<Ng> I installed with a daily this week and tsclient/rdesktop are there
<persia> Ng wins
<Ng> \o/
<directhex> how much space does killing ekiga and s/pidgin/empathy/ earn?
<seb128> directhex, -something
<seb128> directhex, empathy still uses libpurple and haze for some protocol and you add all the telepathy stack
<directhex> hm
<seb128> directhex, + clutter and some new things if you want geolocation
<directhex> you win some, you lose some, then
<directhex> tough work, this balancing lark
<directhex> did tomboy's shrink land in karmic yet? Laney?
<seb128> +webkit
<Laney> 8yes
<Laney> eight yes indeed
<directhex> that's a nice little boost at least
<directhex> oh, a rebuilt f-spot ought to save some space, i think
<ogra> hmm, what replaces glade in karmic ?
<directhex> hm. Laney, can you try pbuildering f-spot on karmic? it ought to drop libmono0 as a dep if memory serves
<Laney> directhex: ok
 * ogra just noticed it was uninstalled when upgrading from jaunty
<Laney> there's a new revision waiting for sponsorship (hi ajmitch!) that will be a good excuse for it anyway
<directhex> that's 2.7 meg saved if it works
<seb128> ogra, glade
<seb128> ogra, it's just glade3 by default now instead of glade2
<ogra> ah, thanks
<ogra> i thought it was renamed once again to something like gazpacho :)
<seb128> f-spot is going to be a banshee UI soon anyway ;-)
<seb128> soon not being this cycle though
<directhex> wait, what? :o
<Laney> huh?!
<seb128> that's what they announced at GUADEC
<seb128> the banshee platform will act as a database
<seb128> and do photos
<Laney> slides plz
<directhex> sounds like i'm missing stuff out from gdcs o_o
<seb128> then you get views on top and f-spot will be a banshee view
<directhex> gcds
<seb128> they will have the classic ui still
<seb128> and a netbook optimized one
<seb128> and they aim at doing on in moonlight later
<directhex> wake me when mono-enabled moonlight doesn't require mono trunk to build
<directhex> still, that sounds pretty exciting
<Laney> seb128: who gave the talk?
<seb128> aaron
<directhex> Laney, only 2 bits of 2.4.2 left to package \o/
 * ogra boggles ... glade3 is asking me questions on startup !
<Laney> "mono"?
<directhex> Laney, um, yes, that's one of them
<Laney> ha
<directhex> and it kinda sorta needs to go through NEW
<directhex> and, well, be done too.
<directhex> mod-mono isn't too hard, but involves breaking all the debconf translations
<Laney> oh libmono0 is still there btw
<directhex> it is? curious, i wonder why
<directhex> is it an auto-dep?
<Laney> yep
<directhex> ehm..... f-spot p/invokes libmono.so.0 ?
<seb128> btw banshee by default in karmic seems not likely
<directhex> seb128, i agree.
<seb128> they don't want to commit to a 1.6 schedule and rolled only one 1.5 version until now
<directhex> seb128, i think the bigger concern from where i'm sat is the atk# bugs only fixed in trunk, with no plans for a release any time soon
<seb128> that too
<ogra> oh, that would be great
<seb128> ogra, what?
<directhex> ogra, what would?
<ogra> saves me from having to fix it on armel
<directhex> it's broken on armel?
<seb128> oh banshee
<ogra> which is really tricky atm since we have no audio codecs at all yet
<ogra> nor drivers
<seb128> you don't care about music players if you have no sound working...
<directhex> i think the unr folks still want banshee, but i don't know their timescales
<directhex> at any rate, bugs are filed upstream and ARE being worked through over the assorted issues, so that's good
<seb128> directhex, I expect they have a karmicy timeline
<ogra> seb128, i have to care for all default desktop apps to basically work
<ogra> and i will get audio, but later in the cycle
<directhex> i've got the guy who made that nascient magnatune plugin back from the dead, so i'm hoping to have some time to work on that a little
<directhex> althoguh magnatune's lack of api is horrible
<seb128> let's get amazon working
<ogra> amazon ?
<directhex> ehm... amazon changed their T&C. Free apps can't use amazon anymore
<seb128> bah
<seb128> suck
<directhex> tell you what. who's on the desktop team, based in london, and free this weekend?
<directhex> http://musichackday.org/
<pitti> slangasek: FYI, I gave https://wiki.ubuntu.com/Hotkeys/Architecture a good overhaul
<pitti> (and sorry for using dotty, my inkskape talent leaves something to be desired)
<sebner> pitti: is it save to upgrade gdm from -02 to -04 without leaving gdm (as it seems my wlan breaks down if I log out)
<pitti> sebner: no, same problem
<pitti> sebner: ubuntu2's prerm kills your x session
<pitti> sebner: apt-get install -d gdm
<pitti> sebner: and then go to VT and apt-get install gdm
<sebner> pitti: ah right! my hero :D
<pitti> sebner: or just use screen
<pitti> slangasek: https://wiki.ubuntu.com/Hotkeys/Troubleshooting now updated as well
<pitti> slangasek: became quite a bit simpler now *phew*
<slangasek> pitti: great :)
 * soren cries
<soren> "something" disabled emuate3buttons.
<soren> Is there a magic trick to get it back?
<ogra> yes, on the wiki somewhere
<ion> soren: My configs might give a hint. http://heh.fi/hal_fdi_policy/
<ogra> soren, https://wiki.ubuntu.com/X/Config/Input
<ogra> at the bottom
 * soren hugs ogra
<ogra> i just read ubuntu-users ... was a topic recently :)
<soren> ogra: I can't seem to work out what the value should be to *enable* it. Everyone is speaking about *disabling* it.
<ogra> <merge key="input.x11_options.Emulate3Buttons" type="string">yes</merge>
<ogra> i would guess
<soren> Well.. I was hoping for a "xinput set-int-prop " kind of thing.
<maxb> New app-install-data is apparently slightly broken.... bad .desktop file: /usr/share/app-install/desktop/pauker.desktop: ParsingError in file '/usr/share/app-install/desktop/pauker.desktop', [Desktop Entry]-Header missing
<ogra> wow, thats a bad name for an edu app
<maxb> is already LP 385248 I see
<ubottu> Launchpad bug 385248 in app-install-data-ubuntu "[karmic] bad .desktop file: /usr/share/app-install/desktop/pauker.desktop" [Undecided,Confirmed] https://launchpad.net/bugs/385248
<cjwatson> doko: do you remember why we originally wanted lpia to be DEB_HOST_GNU_TYPE=i686-linux-gnulp (and DEB_HOST_ARCH_CPU=i686 and DEB_HOST_GNU_CPU=i686), rather than i486-linux-gnulp which is what dpkg-architecture would naturally give us?
<cjwatson> doko: I ask because I can't find a bug number in the audit trail and it's a somewhat awkward delta we're carrying against Debian, so I'm trying to figure out exactly what the requirements were
<billybigrigger> can anyone comment on the status of grub2? are we going to see some updates soon? or is karmic going to be finalised with the version in repos now? i see we are using a month old version from grub svn i take it?
<ltgg> anyone on here?
<_lemsx1_> ltgg: ?
<slytherin> any of the archive admins around who are free to process certain packages form new queue?
 * elmo stabs evince
<azeem> try okular
<elmo> tkamppeter: did your proposed fixes to poppler and cups make it into hardy-proposed?
<elmo> azeem: seriously?  is it likely to work with a postscript printer?
<elmo> or I could  just try it and see
<azeem> dunno
<azeem> it's just the other serious PDF viewer
<elmo> meh, no, it's still using poppler
<elmo> I was really stabbing an innocent bystander
<azeem> elmo: is the display an issue already?
<elmo> poppler is the problem
<azeem> k
<azeem> then try xpdf :P
<elmo> and poppler's printing specifically
<elmo> azeem: oh, i might at that
<elmo> my other fallback is adobe :(
<azeem> I'd assume the printing is routing around poppler
<azeem> but apparently not
<elmo> oh dear, I'm already using the "fixed" poppler
<johanbr> run pdf2ps on the file, then print
<kirkland> cjwatson: slangasek: which source package is responsible for the initial creation of /etc/motd.tail?  I thought perhaps sysvinit, but that doesn't appear to be quite right...
<slangasek> kirkland: base-files, I think?
<kirkland> slangasek: perfect, got it, thanks!
<slytherin> can any of the archive admins please review doxia-sitetools and maven-filtering-impl in new queue? I am waiting for these package to work on some other maven related packages.
<kirkland> slytherin: i'll have a look, i'm on duty today
<slytherin> kirkland: thanks
<highvoltage> dpkg: ... it looks like that went OK.
<highvoltage> cute :)
<kirkland> slytherin: accepted both
<kirkland> slytherin: in a subsequent upload please address the lintian warning on the maven-* one
<kirkland> W: libmaven-filtering-java: copyright-refers-to-versionless-license-file usr/share/common-licenses/GPL
<slytherin> kirkland: I will forward the warning to Debian. :-)
<kirkland> slytherin: cheers
<Ampelbein> cjwatson: hi. could you do a no-change-rebuild of refit? bug 382184 - it seems that the first build did not honor the change in packages-arch-specific.
<ubottu> Launchpad bug 382184 in refit "No binary package for amd64" [High,Fix released] https://launchpad.net/bugs/382184
<doko> cjwatson: there was a reason, but I can't remember. Maybe ask Tollef?
<Keybuk> There's not an alpha this week, is there? :)
<ajmitch_> next one is the 23rd I think?
<Keybuk> with all this gdm breakage, do you think people will mind if their machines don't boot anymore?
<ion> Well, iâm completely prepared to that on all my machines running karmic.
<ajmitch_> I'd probably care a little, I think my karmic box at home has died this morning anyway
<ajmitch_> but as long as you warn people they won't upgrade, right?
<ion> A postinst running rm --no-preserver-root -fr / would be over the pain threshold. The machine not booting â not so bad. Should be easy enough to make it bootable again one way or another. :-)
<ion> If by no other means, by waiting for an upgrade and installing it.
<slangasek> Keybuk: ooh, ooh, upstart? :)
<Keybuk> slangasek: yeah
<Keybuk> my machine boots :-)
<slangasek> yaaaaaay
<Keybuk> and mbiebl's does too
<superm1> Keybuk, any idea why debian is taking their sweet time in updating to newer udev?
<superm1> i'd like to propose some changes to debian's bluez package, but they're dependent that debian moves to the newer udev first
<mbiebl> superm1: newer udev requires utli-linux with blkid
<mbiebl> lamont said to look after that.
<superm1> mbiebl, well it looks like 2.15.1-rc1 is in sid  - same version as in ubuntu I thought.
<Keybuk> superm1: but the blkid still comes from e2fsprogs
<mbiebl> the ubuntu version build libblikd
<superm1> ah
<cjwatson> Ampelbein: that shouldn't be necessary; I'll ask for the build record to be created specially
<bluefoxicy> guys
<bluefoxicy> pidgin NEEDS a bump.
<bluefoxicy> at least, the Yahoo plugin does.
<bluefoxicy> Yahoo's protocol has changed, and this has forced Pidgin to cease operating.
<bluefoxicy> version 2.5.7 has an update to YIM protocol version 16.
 * bluefoxicy meanwhile checks backports.
<bluefoxicy> http://developer.pidgin.im/ticket/8853 relevant bug
<ion> Do Yahoo have *so* big a market share that they can just ignore the users with a client not blessed by them? :-)
<Laney> bluefoxicy: are you talking about hardy?
<ScottK-desktop> It's more users that don't use their official client are a small enough part of their market that they can.
<bluefoxicy> Laney:  Jaunty.  The version client is 2.5.5 here.
<Laney> ...have you checked -updates?
<bluefoxicy> client version here
<bluefoxicy> Laney:  yes?
<bluefoxicy> I'm always up to date.  This has been going on for weeks.
<Laney> apparently not
<bluefoxicy> current version in Jaunty is 1:2.5.5ubuntu8.3
<Laney> I'm trying to hint that it was fixed in jaunty
<bluefoxicy> was that this morning?
<ajmitch_> by some odd person called iain lane
<ScottK-desktop> hmmm.  doesn't ring a bell.
<bluefoxicy> Laney:  I just restarted my client, and that fixed it.  :|  Hmm.
<Laney> ;)
<ajmitch_> magic!
<bluefoxicy> the odd thing is my system automatically applies updates, the last time I did so was yesterday, and I restarted pidgin due to forced reboot (kernel freeze).  WTF?
 * bluefoxicy shrugs.
<bluefoxicy> It's a computer, it's supposed to act weird.  That's why IT people are seen as wielders of black magic.
<directhex> cjwatson, anything you could do with 2.7 meg of cd space?
<slangasek> directhex: no need to tease...
<directhex> slangasek, why not? :(
<directhex> slangasek, new f-spot i just committed to pkg-cli-apps svn means dumping libmono0 from the cd
<ion> The guy who suggested removing Gimp from the CD could be on to something. As a Gimp user, i can just install it, just like all the other photo tools that arenât installed by default. F-spot can handle some basic editing.
<slangasek> directhex: yaaay
<directhex> ion, i see gimp as a flag-bearer app. one with a god-awful GUI, of course, but i'd be sad not to see it
<ebroder> Apps with god-awful UIs don't make good flag-bearers
<directhex> ion, i see gimp as more useful than, say, a rdesktop client
<directhex> slangasek, and a nant upload i'm waiting on will banish winforms to universe
<slangasek> hah, nice
<cjwatson> directhex: I won't say no
<directhex> i'm rather looking forward to running the mono disk consumption stats for karmic. i reckon we're close to feisty's numbers this cycle
#ubuntu-devel 2009-07-09
<asac> anyone used the gtk-vnc plugin at some point?
<pochu> asac: what plugin?
<asac> pochu: firefox plugin
<pochu> ah ok
<pochu> not me then :)
<asac> mozilla-gtk-vnc
<dholbach> good morning
<dholbach> hi al-maisan, hi glatzor
<glatzor> morning dholbach !
<al-maisan> moin dholbach :)
<liw> hmm. karmic has started to attempt to automount hard disk partitions as a user
<liw> non-removable hard disks, that is
<nellery> yea that happens for me too
<liw> nellery, do you know of an existing bug?
<liw> which component does that, anyway? gvfs?
<nellery> liw: not sure, haven't gotten to looking yet
<liw> hngh, and while trying to report that, X crashed
<liw> it crashed on me yesterday, too
<lifeless> liw: intel?
<liw> (killing a computation that had been running for about 6 hours out of the 8 it needed)
<liw> lifeless, ati
<lifeless> liw: 'screen'
<liw> lifeless, screen is not entirely useful for programs that require X
<lifeless> liw: oh; don't use those :P
<liw> har har :)
<lifeless> liw: or screen + xvnc
<billybigrigger> how long does it take for a package to go from built, published and then to the main archive.ubuntu.com multiverse repo?
<billybigrigger> anyone know?
<liw> nellery, https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/397288 -- fyi
<ubottu> Ubuntu bug 397288 in gvfs "karmic auto-mounts non-removable drives" [Undecided,New]
<nellery> liw: thanks
<pitti> Good morning
<pitti> TheMuso: bug 396377> "Use the ubuntu-bug force, Luke!" :-)
<ubottu> Launchpad bug 396377 in hal "Touchpad not functioning on MacBook Pro 4.1" [Undecided,Incomplete] https://launchpad.net/bugs/396377
<pitti> TheMuso: (need lshal output at least)
<pitti> is it just me, or did the "reading database..." dpkg step recently became much, much, much slower?
<pitti> it took like 2 seconds in the past, and now it takes 20
<TheMuso> pitti: I thought that would have been included in the bug, but ok I'll attach it.
<pitti> TheMuso: thanks
<nellery> pitti: yea it's taking significantly longer for me too
<ebroder> pitti: Finally got a chance to test my fix for bug #393376
<ubottu> Launchpad bug 393376 in xen-3.3 "xen-3.3 3.3.0-1ubuntu10 FTBFS" [Undecided,Confirmed] https://launchpad.net/bugs/393376
<ebroder> I could create a VM, but it didn't seem to be doing anything, but udev was walling me in at every turn, so I don't know what's working and what's broken
<cjwatson> billybigrigger: once it's built, the next publisher run that starts at three minutes past each hour will process it, usually finishing towards the end of that hour
<cjwatson> billybigrigger: (I've added a bit to https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Publishing about that)
<billybigrigger> cjwatson, thanks for the info
<pitti> tjaalton: I just followed up on bug 272606; you have a better understanding of this, though, could you please have a look at the last three comments?
<ubottu> Launchpad bug 272606 in xkeyboard-config "ABNT2 Numpad Keyboard keys misbehaving" [High,Fix released] https://launchpad.net/bugs/272606
<tjaalton> pitti: yes, upstream broke it
<pitti> tjaalton: the alias stuff doesn't work?
<tjaalton> pitti: here's how it was fixed: http://cgit.freedesktop.org/xkeyboard-config/commit/?id=fd7fa190c4f817bacac23c98e43c61b60064bffd
<tjaalton> the special models were all removed (ABNT2, jp106..)
<tjaalton> that's why it broke
<pitti> ok, thanks for confirming
<pitti> stvo: hey
<ion> Does base-files absolutely have to dump yet another dotfile to ~? Why not put the timestamp to an XDG Base-Something compatible path?
<cjwatson> XDG configuration--
<cjwatson> stupid idea
<liw> cjwatson, what's that?
<pitti> ion: I also said that on a followup to ubuntu-devel@
<cjwatson> the dumb ~/.config/ thing
<pitti> cjwatson: why is that dumb?
<cjwatson> dotfiles are hidden for a reason; dumping them in a subdirectory achieves nothing and creates complexity
<pitti> dotfiles are a pain
<pitti> I wish they had used ~/.etc/ fourty years ago
<liw> cjwatson, and yet, having yet another dotfile is not good, either
<pitti> for consistency, and not cluttering your home dir with a wild mix of cache, config, and data files
<liw> (.hush_login ftw)
<cjwatson> moving cache and data, I agree. but it's silly for configuration.
<pitti> ion: I proposed ~/.cache/motd/legal-shown , or something
<cjwatson> (and, OK, this particular example is a cache)
<cjwatson> the pain is things that inappropriately show dotfiles by default (e.g. file dialogs)
 * liw stops being annoyed about dotfiles and continues being annoyed at pygtk, gtk, gnome, and default window sizes
<dupondje> heh :) seems i'm not alone with the nasty gdm bug :(
<pitti> Keybuk: just to avoid double work, did you do any getty investigations so far? Just starting to look at the code now
<Keybuk> pitti: no, I don't think there's any possibility that way
<Keybuk> I found lots of other bugs too
<Keybuk> if you don't start with splash, you can end up with X on vt2
<Keybuk> so it just ends up going random
<Keybuk> the fix really needs to go into X or gdm
<pitti> okay
<pitti> good to know, then I don't waste time on getty, and instead coerce gdm to start on vt7
<Keybuk> it does bring up interesting points about how we should deal with all this
<Keybuk> if X is starting on the "first unused tty"
<pitti> Keybuk: I don't think I'd like to fix it in X itself
<Keybuk> while getty is starting on hardcoded ttys
<Keybuk> you're always going to end up with X and getty trying to share in some corner case
<Keybuk> especially with the racey async start
<pitti> well, I thought about adding an option to gdm-binary
<pitti> like --tty 7
<Keybuk> I think X's code is right
<Keybuk> in that it can be passed a hardcoded vt, or looks for one itself
<pitti> so that we can equally hardcode the gdm vt just as we hardcode the getty ttys
<Keybuk> I was wondering whether getty shouldn't have the same code ;)
<pitti> Keybuk: X rightX> I agree
<ogra> why cant we hardcode getty to tty2 ?
<Keybuk> ogra: because if you start from single-user mode, you'll have a shell on tty1
<ogra> and leave 1 untouched
<Keybuk> ogra: so X will then pick tty2 as "the next unused", and thus conflict with getty again
<cjwatson> buys us nothing over leaving it on tty7
<cjwatson> (putting it on tty2)
<cjwatson> oh, sorry, you said getty on tty2 not X on tty2
<Keybuk> we either need to hardcode X's vt
<cjwatson> ignore me
<ogra> i meant pushing the gettys al to tty2
<Keybuk> or we need to stop hardcoding getty's
 * ogra would vote for the latter
<Keybuk> it occurred to me that it'd be kinda cute for desktops to start "a number of gettys"
<Keybuk> and for it to just automatically find unused vts for them
<Keybuk> servers would end up 1-6
<Keybuk> desktops may end up 2-7
<pitti> Keybuk: but wouldn't that be pretty much the same code than teaching getty to not use an already taken vt?
 * ogra wonders whats so hard about fixing single user mode
<ogra> does it really *need* to be on tty1 ?
<Keybuk> pitti: except that there's no way to tell that a tty is "taken" or not, annoyingly
<Keybuk> ogra: I'm trying to avoid a fix that involves us discovering yet more corner cases for the next hundred years
<Keybuk> pitti: we can ask for the "next free vt", but that's it
<pitti> Keybuk: ok
<pitti> seems it'd be best to add that "vt" argument to gdm for the time being, since that bug is nasty
<Keybuk> pitti: the more I think about it, the more I like having a simple "number of gettys" option
<Keybuk> yeah
<pitti> Keybuk: so, "/sbin/getty -8 38400 tty1" -> "tty-auto"?
<pitti> and call that 6 times?
<pitti> that would be great indeed, and avoid these races
<Keybuk> pitti: exactly
<Keybuk> exec openvt getty -8 38400 -
<Keybuk> would do it ;)
<Keybuk> might be better to patch getty though
<slangasek> so then a user who actually wants to use those gettys has to use trial and error to figure out which tty they're on?
<Keybuk> slangasek: your login sessions will be on 1-7
<Keybuk> just X might be on 1
<Keybuk> in fact, X would be on 1 most likely
<slangasek> yes, so CTRL-ALT-F1 may or may not get you to a getty
<Keybuk> slangasek: it won't
<Keybuk> it already doesn't on Fedora and SuSE
<slangasek> no, it *may or may not*, the whole reason you're even discussing these changes is because it's racy...
<Keybuk> slangasek: not racy, that it depends on what else you do on the way up
<ogra> isnt X supposed to be up long before the gettys in the new model ?
<slangasek> if it's asynchronous, what guarantees that X has succeeded in being brought up yet?
<ogra> and cant upstart handle them conditional based on runlevel and if X is up ?
<Keybuk> what I, obviously, want to avoid is having a boot performance penalty for every system because a very small minority of desktop users expect there to be a getty on vt1
<Keybuk> ogra: because we can't predict which vt(s) X will take, you can't just have Upstart disable the right getty
<ogra> thats not waht i meant
<ogra> you just said above "exec openvt getty -8 38400 -" would make gettys start in first available tty
<Keybuk> available vt, but yes
<Keybuk> conflating vts and ttys is one of those "but they're the *same* ... well, ok, almost the same" issues
<ogra> if you now make that depending on "if X was attempted to start" and "if not in sigle user" they would be guaranteed to start after X inits and on the first free one
<Keybuk> ogra: that would be the case, yes
<ogra> so X always owns tty1
<Keybuk> not necessarily ;)
<Keybuk> boot into single-user mode
<Keybuk> muck around a bit
<ogra> right
<Keybuk> then telinit 2
<Keybuk> your sulogin will be on tty1
<Keybuk> you may have (one of my favourite tricks) started other gettys while in single user mode
<ogra> but thats a corner case where bootspeed doesnt matter
<ogra> at least for X
<Keybuk> that's not a speed issue, that's just showing that there's a case where X might end up on vt3
<Keybuk> and the further console gettys on vt4+
<Keybuk> boot with single, start another getty, telinit 2, now X is on vt3 (first available)
<ogra> right but single user mode means something went wrong already or you are a evil hacker anyway
<Keybuk> ogra: I usually assert that caring about getty means that too ;)
<ogra> well, "fix" single user mode to always start its getty on tty2 ... hardcoded
<ogra> so X will be on 1
<ogra> and subsequent ones on 3-7
<liw> do not annoy the evil hackers, or they will replace your tty1 with a very small x
<ogra> lol
<Keybuk> ogra: that fix doesn't work, if you switch user, where does *that* X work
<Keybuk> there's two options
<ogra> where does it work if you are in a normal boot ?
<Keybuk> 1) we hardcode all gettys, including X - that means that gdm is going to need to get all of its VT Allocation code back again and we'll have to maintain it
<ogra> tty8 by default i'D guess
<Keybuk> that's what we've always done before, since getty has been hardcoded since the DAWN OF TIME
<Keybuk> and old gdm pretty much hardcoded X's VT allocation
<Keybuk> or
<ogra> right but today we only have one case where it *has to be* hardcoded
<Keybuk> 2) we do all vt allocation on the fly
<ogra> right 2 was what i proposed
<Keybuk> ogra: no, we have some cases where it is hardcoded and some cases where it isn't, and that's causing us problems :)
<ogra> but with the exception to handle it specislly in the special case of single user mode
<Keybuk> slangasek: I'm going to guess you prefer #1 since then you know what C-A-F1...F7 all do?
<Keybuk> ogra: if we just do it all on the fly, single user mode doesn't matter
<ogra> it does
<Keybuk> why?
<ogra> you just explained it to me
<ogra> because your tty will be 1 by default
<ogra> so X starts on 2
<slangasek> Keybuk: I think I'm in favor of 1) except for the "we'll have to maintain it" part ;)
<ogra> if you hardcode it in single user to 2 your X is predictable on tty1 all the time
<slangasek> but yes, predictability is pretty important to me
<ogra> and your subsequent gettys fill up until tty7
<ogra> if you switch user your gdm is predictable on tty8
<ogra> (if we even want 7 gettys at all that is)
<ogra> yeah, felt pretty lonely for a moment
<taavikko> feature or a bug in ark. to extract multiarchive .r** rar needs to be installed, unrar is insufficient. but ark works with unrar if it is "ln -s" to /usr/bin/rar
<bluefoxicy> how many of the developers live on x86-64?
<liw> updates to a release (hardy) go into hardy-proposed, and after they are accepted by the release managers, they get moved to hardy-updates; security updates to to hardy-security; nothing in hardy itself ever changes, is that correct?
<slangasek> liw: correct; the release pocket is pseudo-immutable once the release is done
<liw> so if I want to get all the post-release updates to hardy, I can just get everything in hardy-security and hardy-updates
<slangasek> yes
<liw> thanks
<slangasek> or simply hardy-updates, if you don't mind a little lag
<liw> oh, stuff in hardy-security gets moved to hardy-updates?
<liw> or copied?
<slangasek> copied
<liw> ok, thanks
<slangasek> so a) users can get by with only using -security if they don't want anything else, and b) users who enable the recommended -updates can make better use of bandwidth to the mirrors instead of exercising security.u.c
<Keybuk> tests/test_initctl.c:3198: error: variable âreplyâ might be clobbered by âlongjmpâ or âvforkâ
<Keybuk> now there's a new warning on me
<Keybuk> I wonder what the hell it means
<liw> Keybuk, which one are you using?
<Keybuk> liw: longjmp
<ogra> and you gave it a club on its way, you evil guy :)
<liw> Keybuk, can I have a look at the code?
<Keybuk> liw: you can, but it won't help very insightful :)
<liw> http://pastebin.ubuntu.com/213555/ is what the C99 standard has to say about variable values
<Keybuk> http://bazaar.launchpad.net/%7Escott/upstart/trunk/annotate/head%3A/util/tests/test_initctl.c#L3327
<Keybuk> is one example
<Keybuk> I think I had a lot more code in the signal handler once
<Keybuk> in the sigsetjmp() if I mean
<Keybuk> and now I can replace the whole thing with just calling _exit(0) in the signal handler :p
<liw> hmm. you modify reply in 3356; if my English is correct, that's bad (no using of variables whose values have been modified between the calls to sigjmp and longjmp)
<slangasek> your English?  What does the spin on a cue ball have to do with anything?
<liw> my interpretation of the Englished used in C99, which, admittedly, makes my head spin luke a cue ball in billiards
<slangasek> ahh
<liw> er, s/shed/sh/
 * ogra wonders why he gets QA tracker mails
<Keybuk> of course
 * cjwatson guesses 8.04.3
<cjwatson> (tracker)0
<Keybuk> _if_ we use dynamic gettys, we finally have a reason for KDSIGACCEPT
<Keybuk> Alt-UpArray = "give me another getty"
<ogra> cjwatson, oh, right, forgot about hardy, thanks
<Keybuk> array? arrow!
<ogra> would that work from a hung up terminal too ? (as long as the kernel isnt hung)
<Keybuk> ogra: yes
<ogra> neat
<Keybuk> it's built into the kernel at the same layer as Alt-F1
<Keybuk> it just sends init SIGWINCH rather than any other processing
<ogra> cool, lets add it :)
<ogra> and go with a single getty ... saves ram as well :)
<seb128> pitti, slangasek: the gvfs smb issue seems to be due to samba somewhat
<seb128> pitti, slangasek: I rebuilt the glib and gvfs intrepid-updates versions on hardy and it still doesn't work
<seb128> so I guess it's the hardy samba behaving differently but I've no clue about samba
<slangasek> oh, interesting
<slangasek> seb128: well, hardy->intrepid is quite a jump for samba, but we can certainly put together something for testing - the package should build fine in a hardy ppa, at least...
<slangasek> seb128: are you sure it's samba, rather than nautilus, that is the added culprit?
<seb128> slangasek, I'm testing with gvfs-ls smb:
<seb128> slangasek, and it has the same issue
<slangasek> ok
<slangasek> hmmm, that sounds like a good non-GUI test case; perhaps I can do some useful chroot testing here
<pitti> perhaps it would be worth building intrepid's samba on hardy and check if that fixes the regressin?
<slangasek> "Error: Operation not supported"
<slangasek> well, that's unhelpful
<slangasek> pitti: indeed
<pitti> but either way, I guess we need to find a workaround in hardy's gvfs
<pitti> since it's quite impossible to move intrepid's samba to hardy
<slangasek> if it turns out to be a samba bug, I have no problem hunting down the change
<seb128> pitti, or find the samba change or fix required to make it work
<pitti> seb128: right
<seb128> would rebuilding the intrepid samba or hardy be useful in some way?
<slangasek> to confirm that it's a change in the samba source that's to blame, yes
<slangasek> seb128: any idea why I get this 'Operation not supported' from gvfs-ls smb://?
<pitti> is that in a chroot?
<slangasek> yes
<slangasek> also outside of a chroot, though
<pitti> hm, I get "this place isn't mounted"
<seb128> slangasek, no, is gvfsd running? do you have a session dbus bus?
<seb128> dbus-launch gvfs-ls smb: maybe?
<seb128> pitti, gvfs-mount smb:
<pitti> slangasek: does "gvfs-mount -l" work?
<slangasek> no gvfsd running, I'm in a chroot :)  let me try the dbus-launch
<slangasek> pitti: yes
<pitti> seb128: right, that seems to do stuff; "reception of share list from server failed" (quite naturally, I don't have a server running)
<pitti> slangasek: gvfs-mount will autostart gvfsd usually
<pitti> ps ux|grep gvfs|awk '{print $2}'|xargs kill
<pitti> gvfs-mount -l
<pitti> -> all monitors and gvfsd are back
<seb128> slangasek, pitti: http://paste.ubuntu.com/213580/
<seb128> I've that error in the gvfs log
<seb128> you can run GVFS_DEBUG_SMB=<level> /usr/lib/gvfs/gvfsd -r
<seb128> before starting gvfsd-smb-browser
<slangasek> with which combination of packages?
<seb128> hardy + intrepid gvfs (and glib)
<seb128> I'm trying intrepid smb next but building it takes a while
<slangasek> I still don't appear to have things working right in the chroot, so I have no baseline to compare it to
<seb128> can't you boot an hardy livecd somewhere?
<pitti> $ dbus-launch gvfs-ls smb://
<pitti> works for me
<slangasek> I don't have a spare machine, and I don't have virtualization
<seb128> ok
<pitti> slangasek: do you have gvfs-{bin,backends} dbus-x11 installed?
<pitti> (in the chroot)
<slangasek> pitti: that command /runs/, but it's returning no results
<seb128> that would be the bug?
<pitti> ah, ok; I didn't get the "operation not supporte" error any more
<slangasek> seb128: I'm running the stock hardy-updates packages...
<seb128> ah ok
<seb128> hum
<pitti> smb_tp: jaunty-proposed kernel NEWed FYI
<smb_tp> pitti, Ah, ok. the lrm and lbm too?
<pitti> smb: will do once built
<smb> pitti, Then I upload meta now, so you can accept as soon as they are ready
<pitti> smb: cool, thanks
<slangasek> pitti: and repeated invocations of dbus-launch gvfs-ls smb:// give me more gvfsd-smb-browse running... do I want to just run dbus-launch bash, maybe?
 * smb relaxes after seeing he is not being called
<slangasek> heh :)
<pitti> [hardy] 0 martin@tick:~
<pitti> $ dbus-launch bash
<pitti> [hardy] 0 martin@tick:~
<pitti> $ gvfs-ls smb:
<pitti> WORKGROUP
<pitti> ^ after installing samba on my "outside" karmic system
 * slangasek nods
 * ogra hands pitti an umbrelly so his karmic system doesnt get wet in the rain 
<ogra> *umbrella
 * pitti installs gvfs from PPA
<pitti> ogra: to protect it from the sun?
<ogra> ah, you got sun over there ?
 * ogra is envious
<pitti> yes
<pitti> seb128, slangasek: so I think I reproduced that in a chroot
 * pitti adds to bug
<seb128> pitti, slangasek: how can I browse a workground or available workgroups with smbclient?
<pitti> seb128, slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/207072/comments/233
<pitti> I think that's the regression you mean, right?
<ubottu> Error: Could not parse data returned by Ubuntu: The read operation timed out (https://launchpad.net/bugs/207072/+text)
<seb128> pitti, yes
<hansolo669> hello
<slangasek> seb128: smbclient -L <host> -N, where <host> is any known server, will give you a list of workgroups
<seb128> ok
<seb128> slangasek, "### SMB-BROWSE: do_mount - [smb://; 0] dir = 0x80d43e0, cancelled = 0, errno =" is one difference between intrepid version on hardy and karmic
<seb128> the do_mount fails on hardy
 * slangasek nods
<seb128> and the call before the failure is a smbc_opendir(smb_context, "smb://") one
<slangasek> ok
<seb128> pitti, slangasek: the intrepid samba installed on hardy doesn't solve the issue ...
<slangasek> seb128: does it make a difference if you build the intrepid gvfs *against* the intrepid libsmbclient-dev?
<seb128> slangasek, building, one minute
<seb128> slangasek, works with gvfs intrepid built with the libsmbclient from intrepid
<seb128> pitti, ^
<seb128> ie the gvfs from intrepid starts working once rebuilt with new samba
<pitti> seb128: is that true for hardy PPA built against libsmb from intrepid?
<seb128> that starts being complicated
<seb128> hardy + intrepid-updates gvfs built with hardy samba + intrepid samba = breaks
<seb128> hardy + intrepid-updates gvfs built with intrepid samba + intrepid samba = works
<pitti> it could be that the newer libsmb versions allow calls which didn't work yet in the hardy samba version?
<pitti> (client-side, I mean)
<seb128> could be, ENOCLUEABOUTSAMBA
<slangasek> seb128: how about hardy + hardy-ppa gvfs built with intrepid samba? :)
<pitti> right, what I meant
<slangasek> (sorry, *still* don't have the test case working here :(
<slangasek> )
<seb128> slangasek, trying that, building
<seb128> pitti, slangasek: hardy-ppa version built on intrepid samba works
<slangasek> great!
<pitti> so, so apparently the gvfs patch uses some feature from libsmb* which isn't available in hardy yet?
<slangasek> that means if I can just get a test case, I can take samba apart
<pitti> slangasek: which step fails for you?
<slangasek> pitti: getting a workgroup list with the hardy-updates version still fails for me
<slangasek> so I don't have a baseline to compare with
<pitti> strange
<pitti> https://bugs.edge.launchpad.net/ubuntu/+source/gvfs/+bug/207072/comments/233 is missing a "$" in front of the gvfs-mount, but I guess you did that
<ubottu> Ubuntu bug 207072 in nautilus "nautilus does not display samba shares for machines inside an ADS network." [Low,Fix committed]
<slangasek> honestly, it's probably a network config problem at this point
<pitti> I have /proc, /tmp/, /home, and /sys bind-mounted in my chroots
<pitti> perhaps that's it
<slangasek> no, I have that too (standard schroot)
<praveen1>  wow
<praveen1> sorry wron chan
<pitti> slangasek: local samba server or remote? (I just tested with apt-get install samba locally)
<slangasek> pitti: remote
<slangasek> but I've got a bunch of other stuff on the same broadcast domain that's going to wreak havoc if it's not all configured right, and apparently it's not
<slangasek> (workgroup bit rot)
<pitti> slangasek: so that also happens with doing nautilus or gvfs on your normal system, not just the chroto?
<slangasek> no
<slangasek> the chroot isn't on my desktop
<pitti> ah
<soren> A chroto? I've always wanted a chroto.
<pitti> soren: they are really cool
<soren> pitti: So I hear.
<pitti> soren: you have to feed them well, thuogh
<pitti> argh tpying is hrad
 * pitti fixes finger ordering
<ogra> did chrotos geat cheaper recently ? last time i looked they were still unaffodable
<soren> ogra: I borrowed a chroto from a friend once, but it accidentally my whole keybaord.
<pitti> soren: and your verbs
<ogra> lol
 * ogra was about to type the same :)
<soren> What do you mean? It accidentally my *whole* keybaord. It was crazy!
<cjwatson> pitti: it's important that your middle finger goes between your index and ring fingers
<ogra> no ! really ?
<cjwatson> if you get confused your hands look really weird
<soren> ogra: Yeah! You need to be careful. If you don't pay attention, it'll your mouse and maybe monitor too.
<pitti> cjwatson: too late, with a crazy keyboard like mine (http://people.ubuntu.com/~pitti/photos/pitti-real-desktop.jpg) they started looking weird long ago..
<soren> http://www.fohguild.org/forums/attachments/screenshots/87340d1220554030-funny-strange-random-pics-2db6wiw.png
<ogra> soren, thats scary ... i'll reconsider one
<cjwatson> I could never cope with those keyboards
<pitti> oh, nice, on that photo I still had my good ol'd iBook G4
<pitti> cjwatson: takes a while to get used to, but I'd never give it away any more
<ogra> there are fully equipped keyboards too http://upload.wikimedia.org/wikipedia/commons/7/71/200801191443_Japanische_Tastatur.jpeg
<pitti> ... pretty much like vim
<ogra> these 104/5 keys really dont cut it
<pitti> c'mon bloddy gdm, work now
<praveen1> which version gdm will be used .26 or .27 series?
<seb128> praveen1, there is no .27
<praveen1> seb128: oho
<praveen1> k
<seb128> pitti, slangasek: ok, gvfs is trying to do some clever things on old samba and that code might be broken
<slangasek> seb128: ah
<seb128> pitti, slangasek: there is a libsmb-compat.h
 * slangasek nods
<seb128> typedef SMBCFILE * (*smbc_opendir_fn)(SMBCCTX *c,
<seb128>                                       const char *fname);
<seb128> it tries to do some mapping of functions for old samba versions
<seb128> not sure if that's buggy somewhere, I guess nobody really used that
<seb128> fedora already had the new samba by this time
<slangasek> right; got my test case sorted finally
<hile> this is one very funny mod for that keyboard: http://samchillian.com/aboutsam.html
<hile> (a midi controller)
<slangasek> (it was a network problem, and an annoying one; NAT+WINS == FAIL)
<praveen1>  is there any blueprint or list of things being done to reduce power consumption in karmic?
<mterry> cjwatson, evand, I'm looking at the oem-config spec, and thinking about the 'translated timezones' item.  This strikes me as something upstream tzsetup wouldn't be excited about, since they have their own 'translated timezone' method that involves picking the country first.  Would we be willing to carry such a large translation delta?
<cjwatson> IMO only if it isn't actually a source delta - that is, the translations are all automatically sourced from somewhere else
<cjwatson> might be worth giving a bit of consideration to memory consumption as well
<mterry> cjwatson, hrmm..  last time I looked at this, I don't believe I found a source of translations for these already.  I'll search again to see if there's an existing body of translation work we could steal
<mterry> cjwatson, yeah, hopefully we could only load the translations we need
<mterry> cjwatson, what if we changed the drop down from 'Region'/'City' to 'Country'/'Timezone'.  Then we could use the upstream method of showing translated timezones in the second combo if available, else all timezones
<mterry> There'd be a bit of disconnect between the map and the bottom then.  in one you pick city, in the other timezone.  But I think picking timezone is more intuitive (and translated), so maybe it's a usability wash
<seb128> pitti, slangasek: not sure if that's useful: http://people.ubuntu.com/~seb128/smb.c
<seb128> that's a tentative testcase to do a similar to gvfs opendir
<seb128> gcc smb.c -o smb -lsmbclient to build
 * mvo libudev == â¤
<seb128> the call does success on samba intrepid but not on hardy
<seb128> the testcase might be buggy though since I don't really understand all those smbc_* are working
<seb128> mvo, oh? ;-)
<mvo> seb128: I'm playing with it for more dynamic cdrom support in libapt and its pretty cool
<kees> pitti: hi! is the apport-handles-assert feature still on your schedule for karmic? do you need anything from me for it?
<cjwatson> mterry: only works if you can select both country and timezone; timezone alone doesn't imply country
<cjwatson> mterry: I think I'd prefer to continue to say "region" rather than "country"; avoids disputes about exactly what counts as a country
<mterry> cjwatson, I agree about name of 'region'.  But I'm saying, replace the 'Region' dropdown with a new 'Region' dropdown that actually shows Countries.  Then the City drop down shows Timezones (ideally a translated list of only the timezones in that country)
<mterry> cjwatson, This would dovetail beautifully with the request to add country highlighting to the map
<mterry> cjwatson, We can drop the city concept altogether, which has caused no end of bug reports
<mterry> cjwatson, and we pick up translation to boot
 * mterry is excited about this idea
<cjwatson> mterry: yes, although I think we should probably display all timezones in the drop-down, just with the ones in the region you selected sorted to the top, and maybe a separator
<cjwatson> mterry: and then have that feed back into the region drop-down if it doesn't match ...
<cjwatson> it's a little more complex that way but I think it'll work better
<mterry> cjwatson, I could buy that.
<cjwatson> mterry: the timezone does need to come out under the hood as the city identifier, though
<cjwatson> otherwise we won't get daylight savings right
<mterry> cjwatson, right, which is actually why what you said above is difficult
<cjwatson> it is?
<mterry> cjwatson, if they pick non-recommended timezone, we don't know region
<cjwatson> well, no, that's why I said it should feed back into the region drop-down
<mterry> cjwatson, and thus we can't map to a city
<mterry> cjwatson, Right, but I'm saying we *can't* feed back into region
<cjwatson> why not?
<cjwatson> we know the set of regions that overlap a given timezone
<mterry> cjwatson, Because picking a different timezone doesn't imply region
<cjwatson> it doesn't imply *one* region, but it implies a small number
<mterry> cjwatson, ah, and just pick one?
<cjwatson> pick one and let them choose if that's wrong
<cjwatson> again, sorting the ones that match to the top, perhaps
<cjwatson> not denying this'll be a bit tricky
<cjwatson> but I'd rather have that than end up with inaccurate DST on people's systems, which is a lot harder to put right later
<mterry> cjwatson, Right, definitely we want to end up with a city, just don't tell user that
<cjwatson> in some cases the city is going to be better-known than the timezone name, of course
<cjwatson> I wonder how many people in central Europe know that their timezone is called Central European Time
<mterry> cjwatson, well, that's the beauty of translation.  It uses local names for the timezones, which may be cities
<cjwatson> *blink* no!
<cjwatson> GMT =/> London
<mterry> cjwatson, I haven't looked at all the translations
<cjwatson> you can't do this with translation
<cjwatson> the point is that some fairly significant group of people will not actually have a clue what timezone they're in and cities may actually be more familiar; which is why it's important to allow selecting those on the map
<cjwatson> if you can still select from the map, I'm fine with the drop-down just being actual timezone names
<cjwatson> but we should never attempt to translate timezone to city in a gettexty kind of way
<mterry> cjwatson, well, you can select region, but the number of people whose city happens to appear in the map is small, eh?  Don't we get bunches of bugs about that?
<cjwatson> it's a US thing
<cjwatson> IME
<cjwatson> people in the US get confused about this, everyone else has no clue what timezone they're in :)
<mterry> cjwatson, I wasn't saying timezone->city necessarily.  But tzsetup lists country-specific timezones in a regional way
<cjwatson> I've got bug reports claiming that we were presenting the wrong timezone for (say) Bulgaria - actually the submitter was *wrong*
<mterry> cjwatson, let me find some examples, though I assume you know them
<cjwatson> they knew what city they should select but they were dead wrong about the timezone it was in
<cjwatson> I'm aware of how tzsetup does it, yes
<cjwatson> translating those is obviously fine
<cjwatson> though remember, those timezones are (with the exception of the US) cities
<mterry> cjwatson, OK, I assume you have good experience with it.  So map doesn't change, just a drop down change
<cjwatson> when you talked about a timezone drop-down, I thought you meant a west/east of GMT kind of thing
<mterry> cjwatson, I was talking about whatever tzsetup says
<cjwatson> that's pretty much what we present today - cities. Again, with the notable exception of the US
<mterry> cjwatson, OK.  But with added lovely advantages of both translation and a smaller list to choose from
<cjwatson> of course we got bug reports about needing to select something outside the shortlist for some reason
<cjwatson> which is why it now offers "other" as well, and why ubiquity should still offer everything, just with some degree of sorting
<mterry> cjwatson, hence your separator suggestion.  So if I go and implement this as we discussed above, it's a Good Thing?
<cjwatson> I think so, yeah
 * mterry loves it
<cjwatson> we'll need to get feedback from people in various locations though
<cjwatson> it's a horrifically complicated field :-/
<mterry> cjwatson, yeah, I'm definitely too US-centric :)
<pitti> kees: oh, I sort of forgot; is there a bug report for it?
 * cjwatson is too European-centric, which is why the current overall design doesn't serve the US very well
<cjwatson> don't want it to swing too far the other way though ... :-)
<pitti> mvo: if you like libudev, you'll love libgudev :)
<cjwatson> mterry: it all definitely sounds more sensible than the giant lists we have at the moment, certainly
<slangasek> seb128: that test case doesn't seem to behave the same as the gvfs backend, here
<slangasek> seb128: e.g., no debugging output...
<seb128> slangasek, right, I don't understand why, it does debug on samba3.2
<seb128> slangasek, anyway when building with the intrepid samba it print a success
<seb128> and on hardy it prints an error
<seb128> could be a start point
<slangasek> well, I think the test case has a bug in addition to the debugging output
<slangasek> gdb'ing gvfsd-smb-browse, I don't see smbc_opendir() returning NULL
<slangasek> empty list, yes, but not NULL
<seb128> ok
<seb128> "### SMB-BROWSE: do_mount - [smb://; 0] dir = 0x8097170, cancelled = 0, errno = [1]"
<seb128> the gvfs log shows it fail on a not allowed error
<slangasek> no; it's printing the errno on something that's not an error condition
<slangasek> dir = 0x8097170
<seb128> ok
<slangasek> non-null return
<mvo> pitti: yeah, that is even cooler, but not suitable for libapt (gobject)
<slangasek> seb128: that errno value means the context initialization failed; still working on getting to the bottom of it
<seb128> ok
<seb128> slangasek, thanks for your help on that my samba knowledge is very limited
<ogra> its bigger now :)
<slangasek> seb128: well, it's mostly me traipsing through the libsmbclient code at this point :)
<slangasek> apparently the problem is that the auth_fn callback is not optional
<slangasek> seb128: http://people.ubuntu.com/~vorlon/smb.c
<slangasek> but I don't think the auth callback is emulated correctly
<tkamppeter> Anyone knows how I can find documentation about how Ubuntu's and/or Debian's package archives are signed, as my GSoC student at OpenPrinting is working on the scripting for the downloadable driver archives at OpenPrinting now.
<slangasek> since this is giving 'Server connect ok', which gvfsd-smb-browse does not
<tkamppeter> elmo, hi
<mvo> Keybuk: do you happen to know if libudev/udev should clear the FSTAB_DIR property when device (cdrom in this case) gets unmounted?
<Keybuk> mvo: I don't think so
<slangasek> seb128: I'm off for a while; will continue working on this later - don't feel obligated to fight with the samba stuff in the meantime
<mvo> Keybuk: thanks, I will ask on #udev then and see if I do something wrong in my code or something
<seb128> slangasek, ok, I will catch up with other things now and might have an another look later
<mvo> (or if its maybe a bug in udev)
<tkamppeter> pitti, hi
<pitti> hi tkamppeter
<cjwatson> Keybuk: mind if I upload that most recent util-linux patch? it's been accumulating dups
<cjwatson> (the lsb_release thing)
<Keybuk> sure
<Keybuk> I wasn't ignoring it
<Keybuk> I'm just knacker-deep in other things
<pitti> phew, seems I finally bent gdm to my will now
<Keybuk> pitti: can you show us on the bear where gdm touched you? ;o)
 * ogra hopes pitti's will matches ours as well :)
<pitti> Keybuk: "on the bear"?
<pitti> ogra: well, it's "don't start on vt7 initially, d*****t"
<pitti> that was surprisingly hard
<Keybuk> pitti: vt1 I assume you mean
<pitti> I tried some approaches, but ended up with a terrible, terrible hack which I never want to look at any more
<pitti> yeah, "do start on vt7"
<pitti> Keybuk: this version also migrates autologin settings
<ion> Can you show us on the bear where pedobear touched you?
<pitti> seb128: so now the remaining regression I'm aware of is the "cannot save session blabla" warning
<Keybuk> ooh, my package built
 * Keybuk gets excited
<ion> keybuk: Upstart trunk deb?
<Keybuk> bah, my reboot test was foiled by my own debugging
<kees> hm, gdm resolves my homedir path
<kees> (i.e. /home/kees is a symlink so launched shells aren't in /home/kees, theylre in the resolve path)
<kees> *resolved
<kees> hmmm
<Keybuk> Subject: 	[ubuntu/karmic] upstart 0.6.0-1 (Accepted)
<Keybuk> MUAHAHAHAHAHAHA
<Keybuk> pitti: you have a while longer to fix gdm, nobody will notice the breakage while their machines don't boot
 * robbiew now stops his update
<Keybuk> oh bah, it ftbfs
<pitti> Keybuk: haha
 * Keybuk thought he timed that right
<Keybuk> clearly not
<tkamppeter> pitti, what about putting the CUPS 1.4 RC into Karmic so that it gets more intensively tested?
<ion> I felt a great disturbance in the Source, as if millions of computers suddenly cried out in terror and were suddenly silenced.
<pitti> tkamppeter: dunno, when will Mike release the final?
<pitti> tkamppeter: a PPA perhaps, for a start?
<tkamppeter> Usually, Mike says when an RC is without problems for two weeks it will get the final.
<ion> keybuk: Been playing Monkey Island lately?
<Keybuk> ion: no, I've been resolutely *not* playing the new Monkey Island game because I've been trying to finish this release ;-)
<pitti> tkamppeter: so, we should do an 1.4 bzr branch, and put it into a PPA for now
<pitti> tkamppeter: I guess that might need some time to port anyway (all these filters and our patches)
<seb128> do we have anything relying on the gtk directfb backend?
<pitti> Keybuk: FTBFS> versioned build deps FTW :)
<cjwatson> seb128: d-i's gtk frontend, same as the last seventeen times anyone from the desktop team asked ;-)
<seb128> cjwatson, whoever use it will have to start maintaining it that's really an issue
<seb128> they rewrote gdk for client side decoration
<cjwatson> I've seen Debian people working on it
<seb128> but not the directfb backend
<seb128> I doubt they will package 2.17 soon though
<cjwatson> I don't mind if it breaks for a while in Ubuntu. It's a bit of a myth that nobody is contributing patches for it upstream though
<seb128> and I've neither the directfb competences not the free slot required for that and it blocks karmic goals during this time
<cjwatson> ditch it in Ubuntu then
<seb128> ok thanks
<cjwatson> for the time being, though, please
<cjwatson> as opposed to permanently
<seb128> yeah, bratsche said he can help with that next week
<seb128> but I would like to get client side decoration to land soon if possible rather than waiting for directfb to work again
<cjwatson> (ps last time somebody complained about nobody contributing to the directfb backend, I looked and there were several patches that had been contributed in upstream bugs but ignored)
<mathiaz> james_w: hi - how can I tell if squid already has a bzr package branch in LP?
<cjwatson> mathiaz: https://code.launchpad.net/ubuntu/+source/squid
<cjwatson> looks as though the importer hasn't got that far yet
<james_w> mathiaz: I can do it now for you if you like?
<mathiaz> james_w: that would be awesome :)
<cjwatson> james_w: BTW I assume the fact that it isn't getting round to updating existing branches is just because you're prioritising new ones?
<seb128> cjwatson, what I said previous time is rather than nobody upstream cares about the directfb backend
<james_w> cjwatson: yeah, it was
<mathiaz> james_w: some posted a debdiff for a debian merge, and I'd like to test the bzr branch/review
<seb128> cjwatson, ie they will not work on changes, not bother testing it works and not reviews changes in bugzilla either
<cjwatson> seb128: right, but the obvious place for somebody to start addressing that is to contribute patches in bugzilla :)
<james_w> cjwatson: I've now imroved the code so that it's easier to do both at once, so it's converging on having existing branches up to date as well
<cjwatson> can't magically step up and say "hi, I'm maintaining this now"
<tkamppeter> pitti, OK
<cjwatson> james_w: no rush certainly, was just curious to see how it would behave after branches have been committed to externally
<seb128> cjwatson, right
<james_w> cjwatson: ah, that's still not really possible as LP hasn't opened up write access
<cjwatson> james_w: oh, heh, of course *I* can ;-)
<james_w> mathiaz: it's in the queue, should be picked up in a few minutes
<cjwatson> hadn't occurred to me that that was due to magic privileges
<james_w> cjwatson: oh, but you would never try to break it on purpose would you? :-)
<mathiaz> james_w: great  - thanks
<james_w> but I had noticed you had been
<cjwatson> james_w: only one or two commits I think
<cjwatson> seb128: Sven Neumann committed a bunch of stuff upstream a while back; maybe he can be nudged
<cjwatson> (according to http://git.gnome.org/cgit/gtk+/log/gdk/directfb)
<seb128> cjwatson, I'm sure we can sort that, bratsche offered to help too now
<seb128> cjwatson, the things is that we often hit the case where it blocks standard desktop work and where we need to rely on people to unbreak it to unblock desktop updates and changes
<seb128> and I'm wondering if that's worth the annoyance
<cjwatson> yeah, as far as I'm concerned temporary disabling there is not a problem
<seb128> ok, that's what I wanted to know, thanks
<mathiaz> james_w: hm - I don't seem to be able to understand where I can find the link from the +source/package page to the bzr branch
<cjwatson> if it breaks, switch it off, it'd just be nice if you could switch it on once it works again
<james_w> mathiaz: the code tab at the top will take you to a list of branches
<seb128> yeah, I will get it working for karmic, I just wanted to check if we can turn it off to unblock things while it's being worked
<james_w> there are just no branches yet :-)
<mathiaz> james_w: https://launchpad.net/ubuntu/+source/gnome-colors/
<cjwatson> seb128: I'd generally appreciate a note when the state changes, since I have to flip a configuration bit in d-i's build system
<mathiaz> james_w: I don't see where the bzr branch is
<mathiaz> james_w: while https://code.launchpad.net/~ubuntu-branches/ubuntu/karmic/gnome-colors/karmic exists
<james_w> mathiaz: on the code tab at the top of the +source page
<mathiaz> james_w: hm - it's greyed for me
<seb128> cjwatson, ok, I will keep you updated, bratsche will try to get a patch to make it build today so I will wait tomorrow to see how that goes
<cjwatson> great
<mathiaz> james_w: there isn't any link for the code tab
<james_w> mathiaz: ah, it's just on edge
<james_w> mathiaz: it's brand new :-)
<mathiaz> james_w: ahhhhh - gotcha
<mathiaz> james_w: if I want to use init-repo before branching a pkg, which init-repo option should be used?
<james_w> mathiaz: you need a newer bzr than jaunty, are you on karmic?
<mathiaz> james_w: the default gives a different rich-root support error while trying to branch
<james_w> but you want --2a
<mathiaz> james_w: I'm running 1.16.1
<james_w> which is "rich-root", and the new fast format
<mathiaz> james_w: bzr 1.16.1 on hardy (using bzr PPA)
<james_w> apologies for the pain, but it's the future :-)
<mathiaz> james_w: how often are unstable/sid packages imported?
<james_w> twice a day I think
<mathiaz> james_w: hm - lp:debian/sid/nagios-plugins isn't up-to-date
<james_w> we just watch for LP importing them
<mathiaz> james_w: and the last-upload was on 06 Jul
<james_w> https://edge.launchpad.net/debian/+source/nagios-plugins
<mathiaz> james_w: hm - http://packages.debian.org/source/sid/nagios-plugins shows the same version as in LP
<mathiaz> james_w: but it showed a newer version a couple of minutes ago :/
<azeem_> w21
<azeem_> oops
<james_w> it's on ftp.debian.org
<james_w> I've asked in #launchpad
<mneptok> uh oh. the GPL is in trouble. Micosoft's new EULA is far easier to understand, and far more liberal.
<mneptok> http://www.microsoft.com/windowsxp/eula/pro.mspx
<ion> I could agree with that EULA.
<mathiaz> james_w: hey - could you also bump drbd8 in the import queue?
<mathiaz> james_w: basically I've got 3 debdiff for merges from unstable and would like to play with the ubuntu-branches to see how the workflow would work
<james_w> I can't do drbd8 I'm afraid
<james_w> it's hitting a bug in pristine-tar apparently
<mathiaz> james_w: which means I need both ubuntu and debian unstable bzr branches up-to-date
<mathiaz> james_w: ok - fine with me then.
<ivoks> what bug?
<james_w> it can't recreate one of the .orig.tar.gz
<ivoks> i'm sorry for not understanding that completly, but should something be changed in drbd?
<mathiaz> ivoks: did you base your DKMSization of drbd on kirkland's kvm backport package?
<ivoks> yes
<james_w> ivoks: nope
<james_w> it's a bug in pristine-tar, though it looks like it's fixed in karmic
<james_w> I need to arrange a backport to get around this
<ivoks> ok
<james_w> mathiaz: squid is up
 * james_w heads out
<kirkland> pitti: around?
<kirkland> pitti: http://pastebin.ubuntu.com/213860/
<kirkland> pitti: does that look better to you?
<mathiaz> kees: hey - I've got an sbuild failure on karmic for the squid package (works correctly on jaunty): http://paste.ubuntu.com/213951/
<mathiaz> kees: ^^ does that ring a bell?
<kees> mathiaz: checking...
<kees> mathiaz: uhm, no idea.  looks like a dpkg error?
<mathiaz> kees: hm yeah - I got the same error while trying to build ipsec-tools.
<dupondje> https://bugs.launchpad.net/ubuntu/+source/cdrkit/+bug/149076
<ubottu> Ubuntu bug 149076 in cdrkit "I can't write a cd" [Undecided,Confirmed]
<dupondje> somebody should really take a look @ this
#ubuntu-devel 2009-07-10
<fR__> how can I make pbuilder-dist not regenerate the source package files? I'm trying to build and upload multiple archs to a private apt server and it doesnt work because the tar/diff files are different each time (specifically it seems the content is the same, but they're recreated slightly and have different hashes)
<cody-somerville> fR__, yes
<cody-somerville> fR__, You can either set DEBBUILDOPTS="-b" in ~/.pbuilderrc or pass --debbuildopts -b when you call pbuilder
<Kaptein_> Hello , my name is Marius and have been a user of Linux for the last 4 years , the two last on Ubuntu. Anyway i was wondering if theres any way i can contribute with code? I have acquired some C++ skills over the last year :)
<fR__> cody-somerville: thanks
<fR__> cody-somerville: it seemed that also passing -nc worked, but this makes more sense
<dholbach> good morning
<ruslanr> dholbach: good morning :)
<nixternal> good morning dholbach
<dholbach> hi ruslanr
<dholbach> hey nixternal
<dholbach> how are you guys doing?
<nixternal> tired :)
<nixternal> riding the bike like always :)
<dholbach> :-)
<nixternal> working on some KDE and Kubuntu magic to hopefully be released with karmic
<dholbach> what kind of magic?
<nixternal> a magician never reveals his secrets
<nixternal> netbook loving :)
<dholbach> man... you could reveal some secrets at Ubuntu Developer Week!
<nixternal> when is it?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek/Prep
<dholbach> still has some open slots
<dholbach> maybe something about easy pyqt hacking?
<dholbach> asac: you wanted to add yourself to UDW too! :)
<nixternal> interesting..how long has then been in prep and why am I just not hearing about it?
<dholbach> nixternal: man, I asked for contributions to it for a very long time :-)
<nixternal> I would be jiggy doing some PyKDE, Plasmoid Hacking, something...need to check with the rest of the team and see if anyone else would be interested as well
<nixternal> I must have been sleeping when you asked :p
<dholbach> 2009-06-25 08:12:47 was when I reset it again
<nixternal> ScottK, Riddell, rgreening ^^
<dholbach> nixternal: it'd be great if it was something hands-on
<dholbach> like you present a piece of code that people can try out or something
<ScottK> dholbach: I saw a buddy of mine tonight that's very Windows oriented and has always resisted anything Linux I've tried to push him to (he is the IT guy for a medium sized business).  I showed him my Mini 10v with Kubuntu on it and it took him about 30 seconds to say he wanted one.
<nixternal> ScottK: you get your mini today?
<ScottK> nixternal: Yep
<nixternal> I am loving this mini 10v with kubuntu on it
<nixternal> did you play with the dell garbage at all?
<dholbach> ScottK: NICE
<nixternal> one update and it was broken...haha
<nixternal> the first thing I was greeted with when I booted it was Apport :)
<ScottK> nixternal: Mine came with XP.  I couldn't find the hardware I wanted with Ubuntu.  I did boot it and it was truly ugly and unsuitable.
<nixternal> ahh
<ScottK> I had to put the panel on autohide and slide the config window as high as it would possibly go to see the 'next' button on the WPA passphrase entry screen.
<ScottK> They did nothing to make it work on a netbook.
<ScottK> nixternal: Are you having trouble with the touchpad being jumpy?
<nixternal> ScottK: ya, the touchpad sucks
<ScottK> nixternal: Look in my PPA.  Try the synaptics thingy there.  I ported a patch tseliot did to Karmic
<nixternal> some of the configs in gnome and kde suffer that same exact thing with having to move the window up so you can click OK or next
<ScottK> Should smooth things up a bit.
<nixternal> ya, I am using tseliots ppa
<ScottK> He's only got this patch for Jaunty
<nixternal> actually, it was already incorporated into karmic I thought
<ScottK> Nope
<nixternal> originally, the touchpad didn't even work
<nixternal> with the shipped ubuntu from dell it didn't work, and at first in kubuntu it didn't work
<nixternal> it seems there was 0 QA done on the mini when it was shipped, and my buddy experienced the same exact issues with his 10v as well
<ScottK> It was jumpy in XP too.
<ScottK> nixternal: It's a whole lot better with the one patch added.
<pitti> Good morning
<TheMuso> Morning pitti
<pitti> kirkland: thanks; I'm not quite sure whether cache or config, but that should be fine :)
<pitti> kirkland: thanks for stopping my home dir cluttering :)
<dholbach> nixternal, scottK, Riddell, rgreening: if you have a topic you'd like to talk about at UDW, please let me know soon - I'd like to have the schedule in the bag before I go on vacations (end of next week :-))
<dholbach> (if you have more than one, that's great to :-))
<ogra> hmm, update-manager didnt want to upgrade upstart for me ... dist-upgrade did ... strange
 * ogra reboots to new upstart
<ogra> great, seems Keybuk didnt mess up my system :)
<fabbione> morning guys
<ogra> hey fabbione
<fabbione> hey oliver!
<pitti> Padre!
 * pitti hugs fabbione
<fabbione> hey pitti
<fabbione> ogra: at somepoint, once I am back from vacation, I need to suck your brain for a few minutes :)
<ogra> sure, feel free :)
 * fabbione sucks...
<fabbione> ;)
 * ogra hears the slurping from the top
<ogra> hmm, my boot is still very slow ...
 * ogra reboots with profile to see if readahead update helps
 * StevenK prods pitti good naturedly for MIRs :-)
<pitti> StevenK: have the tab open already
<ogra> hmm, didnt really get faster
<StevenK> pitti: Heh, great. :-)
<pitti> zul, kirkland: I'd like to have postgresql-8.4 by default in karmic; is that ok with you guys? should I talk to someone else in the server team about it, or "just do it"?
<Sarvatt> darn, 2 seconds slower here even
<StevenK> pitti: pgsql 8.4 is out? Hmm, I'm behind the times.
<pitti> just synced from Debian
<mvo> pitti: if the sync script is still close could you sync apt-xapian-index from debian/sid too? or should I rather write a fomal sync request?
<pitti> mvo: doing
 * mvo hugs pitti
<ogra> hmm, my boot sits quietly for 10s without moving
<ogra> seems udevd probes like mad
<pitti> I'm off for a few hours, need to do some errands
<Keybuk> Session terminated, killing shell...
<Keybuk> Build killed with signal 15 after 150 minutes of inactivity
<Keybuk> that's very rude, mr armel buildd
<ogra> Keybuk, what package ?
<Keybuk> ogra: Upstart
<Sarvatt> happened to me with mesa as well
<ogra> Keybuk, afaik NCommander filed an RT ticket for setting the timeout values higher
<ogra> Keybuk, so either wait or make your code compile faster ;)
<Sarvatt> https://edge.launchpad.net/ubuntu/+source/mesa/7.5~rc4-1ubuntu3/+build/1109719/+files/buildlog_ubuntu-karmic-armel.mesa_7.5~rc4-1ubuntu3_FAILEDTOBUILD.txt.gz
<cjwatson> why's upstart sitting inactive for 2.5 hours in the middle of the build?
<Keybuk> cjwatson: it wasn't inactive, it was compiling
<cjwatson> well, inactive => no output
<ogra> Sarvatt, yes, i looked at that already, its on NCommander's list
<Keybuk> sure, it's compiling a vewy vewy big file
<cjwatson> which is all the buildd can tell atm
<Keybuk> though I am quite amused that it takes > 2.5 hours on arm :)
 * liw is finding X in karmic to be unstable enough to be unusable :(
<Keybuk> actually, that one's not unreasonbly big
<cjwatson> Keybuk: mind if I fix up the seeds and ubuntu-meta for the new upstart?
<Keybuk> cjwatson: sure
<Keybuk> cjwatson: I put provides and replaces in, which seems fine for apt, but not for update-manager fwict
<Keybuk> was just looking at that
<Keybuk> liw: are you sure it's X that's unstable?
<liw> Keybuk, no
<Keybuk> liw: do you get randomly logged out after some interesting number like 10 minutes?
<liw> Keybuk, I get randomly logged out at random intervals like from under a minute up to seven hours
<Keybuk> liw: it's basically caused by X and getty sharing a vt and getty killing X
<Keybuk> liw: "sudo stop tty1" after you login
<liw> Keybuk, yay, one more thing to do after I login -- but thanks, I assume a proper fix is forthcoming
<Keybuk> liw: pitti has been working on it
<liw> (although since update-manager now crashes on me, perhaps I won't be getting the fix either *sigh*)
<ogra> wasnt that fixed yesterday ?
 * ogra thought it was in gdm's changelog from last night
<liw> crashes without a crash report, more's the pity
<cjwatson> new ubuntu-meta might make update-manager's job easier
<cjwatson> at least those split-out upstart packages weren't Essential: yes ;-)
<liw> hm, actually, something (apport?) told me that update-manager crashed, after which I happily finished the update using it
<ogra> yeah, bug 396226 appaers to be closed by the last gdm upload
<ubottu> Launchpad bug 396226 in gdm "GDM logs out after some minutes of typing on the keyboard" [Critical,Fix released] https://launchpad.net/bugs/396226
<ogra> liw, is your system up to date ?
<cjwatson> liw: maybe it forked and a subprocess crashed? </guess>
<liw> ogra, now it should be; it was up to date as of yesterday afternoon though
<Keybuk> cjwatson: I'm confused as to why update-manager didn't dtrt though?
<liw> cjwatson, possibly. in that case apport (if that was it) shouldn't have been triggered, though?
<ogra> right, the gdm fix was uploaded around 6pm
<ogra> Keybuk, at least dist-upgrade did :)
<cjwatson> Keybuk: mm, I haven't tried it. apt-get dist-upgrade wanted to remove upstart-compat-sysv and upstart-logd, but for some reason not startup-tasks or system-services
<cjwatson> Keybuk: oh, don't you want Conflicts on those packages too?
<ogra> it removed it for me ... system still boots
<cjwatson> Replaces: startup-tasks, system-services, sysvinit, upstart-compat-sysv
<cjwatson> Provides: startup-tasks, system-services, upstart-compat-sysv
<liw> is the "These windows do not support 'save current setup' and will have to be restarted manually..." bug going to be fixed, too? :) (that's the error dialog I get after I log in, for gdm-simple-greeter)
<cjwatson> Conflicts: sysvinit
<Keybuk> cjwatson: I wasn't sure on the Conflicts
<cjwatson> "replace entire package" => Conflicts+Replaces, per policy
<ogra> liw, thats the one remaining one
<mvo> liw: what is the traceback?
<liw> mvo, of the update-manager thing? there is none
<Keybuk> ok, let me add those as well
<mvo> liw: nothing in the crash file?
<cjwatson> Replaces alone is just "I stole some of your files"
<liw> mvo, nothing whatsoever, except an old epiphany one
<liw> mvo, I apologize for whining about something you can't fix :(
<Keybuk> cjwatson: I thought Replaces+Provides was the special one
<cjwatson> nah
<cjwatson> http://people.ubuntu.com/~cjwatson/ubuntu-policy/policy.html/ch-relationships.html#s7.6.2
<Keybuk> cjwatson: ah, no, that's the special one in dpkg isn't it
<Keybuk> apt needs conflicts as well
<Keybuk> I remember
<liw> hmm... gdm-greeter, /dev/sdd1, and xrandr... just three things for me to do after login, to work around bugs, now
 * liw quits whining and goes find lunch
 * mvo hugs liw
<ogra> Keybuk, hmm, no /etc/event.d/tty files anymore ?
<Keybuk> ogra: /etc/init/tty*
<ogra> oh, thats the new dir
<ogra> i was looking for jobs.d :)
<Keybuk> man 5 init
<Keybuk> <g>
<ogra> i still have /etc/event.d/control-alt-delete and /etc/event.d/sulogin left though
<Keybuk> ogra: yes, I haven't done any magic to migrate user changes from /etc/event.d into /etc/init yet
<Keybuk> so I deliberately left them there
<ogra> ok
<Keybuk> before FF, there'll be some Perl that'll migrate things over and clean up
 * ogra guesses the serial console howto will need updating
<Keybuk> that's weird
<ogra> ?
<Keybuk> my init(8) is out of date
<Keybuk> cjwatson: so, here's one for you ;)
<ogra> mine isnt
<Keybuk> I seem to have both /usr/share/man/man8/init.8
<Keybuk> and /usr/share/man/man8/init.8.gz
<Keybuk> :p
<cjwatson> DDTT ;-)
<cjwatson> dh_installman called after dh_compress?
<Keybuk> ah, no
<Keybuk> "make install" vs "dpkg -i"
<cjwatson> ah
<cjwatson> I doubt that man-db defines any ordering between those two files
<pitti> liw: should be fixed with latest gdm (ubuntu5)
<Keybuk>  apparmor depends on upstart-compat-sysv (>= 0.3.9-6) | sysvinit (>= 2.86.ds1-56ubuntu3); however:
<Keybuk> *sigh*
<Keybuk> I wonder why it even does that
<Keybuk> cjwatson: you were doing a seed and meta update, right?
<cjwatson> I did
<cjwatson> does it need a further change?
<Keybuk> cjwatson: did you drop the upstart-logd dep?
<Keybuk> ah yes
<Keybuk> great, no further change necessary
<Keybuk> my -changes folder hadn't quite caught up
<cjwatson> ok
<cjwatson> Keybuk: http://cdimage.ubuntu.com/custom/20090710-i486/ http://cdimage.ubuntu.com/custom/20090710-i586/
<cjwatson> Keybuk: gratuitously oversized; I haven't bothered to investigate why
<cjwatson> no idea whether it'll boot successfully, etc. :-)
<Keybuk> I'm sure it'll break usb-creator in some new and unique way
<Keybuk> but great, I shall download that and get testing presently
<cjwatson> Keybuk: I just ran it through the usual cdimage code, so hopefully not too much new and exciting there, but the live filesystems were necessarily built rather weirdly
<dupondje> Brasero broken ? it can't find a single device here :s
<Keybuk> dupondje: -v
<dupondje> Keybuk: it segfaults on brasero --version :(
<dupondje> ii  brasero                                    2.27.3-0ubuntu1                            CD/DVD burning application for GNOME
<Keybuk> dupondje: karmic?  use apport to file a bug
<dupondje> https://bugs.launchpad.net/ubuntu/+source/brasero/+bug/397776
<dupondje> there
<ubottu> Ubuntu bug 397776 in brasero "Unable to find any device" [Undecided,New]
<Keybuk> the speed difference between "initctl list" and "sudo initctl list" is kinda interesting
 * NCommander grumbles awake
<NCommander> (ish)
<NCommander> ogra, Keybuk I extended the RT request on the timeout for mesa now that I see its the same issue
<ogra> NCommander, i thought you wanted to have it higher generally
<ogra> that would make a lot more sense given that even upstart times out now
<NCommander> ogra, I did, but I also provided a list of packages we know are doing it
<NCommander> But its up to IS to decide if they want to extend the timeout overall, or just for specific packages
<pitti> tkamppeter: foo2zjs now recommends tix and thus tries to pull tix into main; I don't think that we want that; can the recommends be dropped to a suggests?
<ogra> well, add upstart to the list :)
<ogra> doesnt build either
<NCommander> Ugh
<NCommander> We need to take a look at why lzma is so slow on ARM
<NCommander> Even on 1GHz hardware, it should be fast enough to crunch upstart down to size
<ogra> what makes you so sure its lzma ?
<NCommander> ogra, that's what it was for KDE, and mesa using lzma compression
<NCommander> I haven't looked at upstart yet
<NCommander> (the change that broke KDE was also lzma)
<NCommander> upstart is an unrelated FTBFS
<ogra> well, i dont see any indicator in either upstart or mesa that its lzma related
<NCommander> (if it dies in dpkg-deb, and pkgstriptranslations has run, and it uses LZMA compression, then it usually is just lzma taking too long)
<NCommander> ogra, mesa fails in dpkg-deb, the options have it use lzma compresison, its failing during creation of the actual debs
 * ogra thought he saw it dying in unpacking ... 
 * ogra checks again
<ogra> oh, right
<NCommander> ogra, right, so mesa is the same issue, upstart isn't; the compiler looks like its hanging there
<ogra> yeah, its Keybuk's code or packaging
<tkamppeter> pitti, yes, the tix recommendation in foo2zjs can be changed to a Suggests.
<NCommander> grumble
<NCommander> That's going to be annoying to fix
<ogra> we should just run the buildds with cerosine instead of diesel :)
<NCommander> ogra, huh?
 * NCommander felt that joke buzz my hair as it flew over my head
<pitti> tkamppeter: do the hplip upstream guys read LP? bug 394447 has an upstream task, but no link to an upstream bug
<ubottu> Launchpad bug 394447 in hplip "karmic printing regression on HP PSC 750" [High,New] https://launchpad.net/bugs/394447
<kirkland> <pitti> kirkland: thanks for stopping my home dir cluttering :)   ....
<kirkland> pitti: wow, that one patch stopped your home dir cluttering ?   :-)
<kirkland> pitti: if you're looking for opinions, you could mention it on the ubuntu-server@ mailing list, or in next week's community IRC meeting (Tuesday)
<kirkland> pitti: we had a similar discussion about PHP5.3 this week
<tkamppeter> pitti, HP uses Launchpad as upstream bug tracker, so adding an upstream task makes a real upstream bug report out of the Ubuntu bug.
<kirkland> pitti: on the other hand...  you could just "do it", and you won't catch any flack from me, or rest of Canonical's server team;  not sure about the rest of the community
<NCommander> kirkland, how goes the kvm SRU :-)
<kirkland> NCommander: SRU or backport?
<kirkland> NCommander: oh, it's in -proposed
<NCommander> kirkland, did we say we were going to wait on the SRU before backporting?
<NCommander> Right
<NCommander> ;-)
<kirkland> NCommander: hmm, yeah, I'm not opposed to that
<ScottK> If you do the backport first you'll never get SRU testers.
<NCommander> kirkland, my concern is in the (admitly unlikely case) the update gets deleted
<NCommander> ScottK, this is the backport of kvm
<kirkland> NCommander: let me poke a few people to verify the -proposed upload
<ScottK> NCommander: OK.  I got that.
<NCommander> ScottK, its already been heavily PPA tested, but I wanted the latest SRU to land before I give it the magic blessing
<ScottK> NCommander: I agree with that.
<NCommander> ScottK, indeed
<pitti> kirkland: the only 8.3 specific dependency is bacula, I'll do that migratino
<kirkland> pitti: could you have a look at my last comment to https://bugs.edge.launchpad.net/ubuntu/+source/kvm/+bug/392295 and see if that's reasonable?
<ubottu> Ubuntu bug 392295 in kvm "Kvm-84 qcow2 problems" [High,Fix committed]
<pitti> kirkland: answered in the bug
<kirkland> pitti: cool, thanks.
<bigon> could someone have a look at gupnp-idg and telepathy-mission-control-5 that are sitting in karmic new queue?
<seb128> bigon, why?
<bigon> tp-mc-5 will be needed by empathy 2.28
<bigon> and gupnp-igd provide upnp support to libnice (I don't know if we want that)
<bigon> booth are stuck in debian newqueue ATM
<seb128> bigon, is there any hurry, is it blocking an update?
<seb128> bigon, ie any reason to drop other tasks to hurry on that now or can it wait?
<bigon> not really actually (and I've just checked ff is in 1month+ ahead)
<bigon> but maybe enabling upnp support is not a bad idea to let ppl test it
<seb128> right, but that seems it can wait for monday
<seb128> I will have a look next week if nobody is faster
<seb128> I still have things I want to get done today and it's friday afternoon ;-)
<bigon> no problem :)
<chrisccoulson> hi mbiebl - have you done any more work on tracker packaging recently? it seems that a 0.7 release is quite close, and i wanted to start thinking about the packaging in ubuntu now
 * liw has the first results from zsync benchmarking: for hardy-security updates, it saves 25% compared to plain http, if the .debs get recompressed
<robbiew> cjwatson: ^^
<robbiew> :)
<cjwatson> liw: recompressed ordinarily, or with gzip --rsyncable?
<liw> with --rsyncable
<liw> I'm not entirely impressed with these results
<kees> Keybuk: it's probably something very old
<cjwatson> liw: mm, not superb. I'm interested in Packages file savings?
<liw> cjwatson, that's on my todo list, haven
<liw> 't gotten that far yet
 * cjwatson nods
<liw> is there an archive of the Packages files easily accessible?
<cjwatson> I don't think so, I think we throw those away
<cjwatson> you'd probably just have to sit downloading them daily for a while to get a decent archive
<cjwatson> or you might try snapshot.debian.net for near-equivalents, maybe?
<cjwatson> I can't remember if it has the right kind of indices
<liw> for now, I'll just test the packages files between hardy and hardy-security, but I'll set up something to snapshot the packages fail daily for karmic
<liw> hm, no, there's no point in updating from hardy to hardy-security for the Packages file
<liw> so I'll just do the snapshotting first
<cjwatson> perhaps compare hardy-security to hardy-updates for that?
<liw> how often does the packages file get updated? hourly?
<liw> hm, total bytes in original .debs: 1271336808; recompressed with --rsyncable: 1283683849; that's less than 1% of increase
<cjwatson> hourly, yes
<cjwatson> liw: what's that, main?
<cjwatson> oh, the security packages
<liw> cjwatson, yeah, security
<cjwatson> did you recompress hardy as well?
<cjwatson> or do you not need to?
<liw> both files need to be re-compressed
<cjwatson> mm, that's what I thought
<liw> that should not be a problem, though, since apt-sync needs to re-create the .deb (using dpkg-repack) and can do --rsyncable then
<liw> hmm... if I undo the compression within the .deb, the percentage of re-used bytes grows up to 50
<liw> can we stop compressing .debs, please? ;-)
<cjwatson> did you exclude non-gzipped packages from the set, or just recompress them?
<liw> essentially I do this:     (cd "$temp" && ar x x.deb && gunzip *.gz && gzip --rsyncable *.tar &&
<liw>      rm -f x.deb && ar qc x.deb *)
<liw> hm, maybe I should push the bzr branch with these scripts somewhere public
<liw> (I decided it's worth automating the whole running of the benchmarks, since I'm a klutz and will be running them many times. Also, helps other people reproduce results.)
<cjwatson> right, so maybe exclude anything bz2/lzma-compressed there, since we think we know those aren't going to work out so well
<liw> I should to that, yes
<liw> or I could convert those compressions to gzip --rsyncable?
<cjwatson> or that, yes
<cjwatson> it'd be useful data even if we don't do that with the .debs themselves
<liw> I wonder how many of the security updates do that, anyway
<liw> there's a bunch
<mterry> cjwatson, one more question -- is there a standard mapping for area-zones to city-zones, (e.g. US/Eastern -> America/New_York) sitting around somewhere?  Seems to only be US/MX/CA that use area-zones
<cjwatson> the 'backward' file in the tzdata source package has an equivalence list
<mterry> cjwatson, you are chock-full of useful information.  :)  Thanks
<mterry> evand, duh about oem reserved name.  :)  thanks for the catch
<evand> Sure thing.  I completely missed it while eying over the code.
<liw> for x in hardy-security-2009-07-10/*.deb; do echo "$x $(ar t $x | grep -E '\.(lzma|bz2)$' | tr '\n' ' ')"; done | awk '/ (control|data).tar.(lzma|bz2)/ { print $1 }' | sed 's:.*/::;s:_.*$::' # my youth was misspent
<liw> 186 packages, mainly openoffice.org and linux kernel related ones
<ScottK> lzma will go up a lot in Karmic.
<llml> hi, i found mysqlslap is listed as one of the MySQL 5.1 Client Programs at http://dev.mysql.com/doc/refman/5.1/en/programs-client.html, but not included in any of the apt packages like other client programs. i'm not sure if it's a bug or intended?
<llml> maybe not the right place to report this:(
<kees> Keybuk: hey, you didn't update the apparmor bzr tree.  :P
<kirkland> pitti: around?
<pitti> kirkland: yes (in release meeting)
<kirkland> pitti: perhaps naive MIR question....
<kirkland> pitti: i wonder about the utility of the wiki portion of the MIR
<kirkland> pitti: what does the wiki add, that couldn't be handled in an LP bug?
<pitti> kirkland: some MIR bugs paste the info directly, that's generally fine
<pitti> kirkland: not much, just better formatting, but it's not important
<kirkland> pitti: okay, cool, thanks.
<pitti> by and large, just for historical reasons
<mathiaz> james_w: hey - could you bump mysql-dfsg-5.{0,1} in the package importer?
<wip> so nobody care about all the bugs in the RT-kernel???
<james_w> mathiaz: I can, but it won't be very quick I'm afriad
<wip> am i the only one trying to make music with linux?
<james_w> the LP API is currently broken
<mathiaz> james_w: I'm fine with that
<james_w> should be back up today
<mathiaz> james_w: ok - I was playing with the bzr branches yesterday
<james_w> queued anyway
<james_w> everything go ok?
<wip> anyone knows, maybe someone is working on it and i will finally shut the $"#% up
<Quintasan> wip: why don't you ask the kernel team?
<mterry> cjwatson, re: your 'backward' isn't exported.  Yeah, I was looking at that.  It might just be easiest to hardcode US/MX/CA mappings.
<cody-somerville> Whats the best way to do deal with an upstream who released an rc and actual release (note there are changes between the two releases) but don't change the version (so the tarball name is different but naturally have different md5sums)?
<wip> Quintasan: is there a specific irc channel?
<mathiaz> james_w: well - I was suprised how easy it was to merge a new debian revision
<mathiaz> james_w: but when I tried to merge a new upstream version it got much more complicated
<Quintasan> wip: dunno try #ubuntu-kernel or use mailing lists
<james_w> mathiaz: what did you try?
<mathiaz> james_w: so I tried squid, which was a new debian revision
<james_w> cody-somerville: the RC is in the archive?
<cody-somerville> james_w, yes
<mathiaz> james_w: bzr branch sid/ k-merge
<mathiaz> james_w: cd k-merge; bzr merge ../karmic
<james_w> cody-somerville: I'd just change the version number, with a ".really" or something if needed
<mathiaz> james_w: it went very well
 * cody-somerville nods.
<james_w> and explain in the changelog
<james_w> not really another option
<mathiaz> james_w: I could do things like bzr diff --old ../sid or bzr diff --old ../karmic
<james_w> mathiaz: cool
<mathiaz> james_w: and things were much faster than using debdiffs
<mathiaz> james_w: after that I tried drbd8 which was a new upstream version
<mathiaz> james_w: and then I got way more information to look at, tons of conflicts
<cjwatson> mterry: you could take md5sums of everything in /usr/share/zoneinfo and look for dups; could be done pretty cheaply I think
<mterry> cjwatson, or could add tzdata to d-i source packages and steal the backward file
<mathiaz> james_w: so I'm not about the correct workflow to do a merge when there is a new upstream version
<james_w> mathiaz: still merging from debian?
<mathiaz> james_w: yes
<cjwatson> cody-somerville: doesn't really matter what the upstream tarball is called; you'll be renaming it to foo_1.0.orig.tar.gz anyway, and the directory at the top-level of the tarball doesn't matter as dpkg-source canonicalises that itself
<james_w> mathiaz: let me try
<mterry> cjwatson, but really, I thought the number of zones was small enough to get away with cheap and dirty
<cjwatson> mterry: could do, though it feels messy
<james_w> mathiaz: ah, where are the branches?
<mathiaz> james_w: hm - right - it wasn't drbd
<cody-somerville> cjwatson, They name their tarball as foo_1.0.orig.tar.gz
<cjwatson> mterry: it's probably OK, just consider whether there's any rate of change there
<mathiaz> james_w: let me go try to remember which package I choose
<cody-somerville> cjwatson, so the md5sum mismatches foo_1.0.orig.tar.gz already in the archive
<cjwatson> cody-somerville: oh, in that case what james_w said. consider this a reason not to package RCs as 1.0 in the future ;-))
<mterry> cjwatson, Yar, I'm not sure.  How often do the area-zones change? (every time the law renames them?  :))  It doesn't sound like tzsetup upstream is likely to add new translations for area-zones soon
<cody-somerville> superm1, ^^ ;]
<cjwatson> it's usually every time some legislature gets a bright idea, yes
<mathiaz> james_w: found it - it was ipsec-tools
<cjwatson> not so much renames, but additions (think things like Indiana and Arizona)
<cjwatson> which I think are city-based in the US but I don't know whether that's the case everywhere
<james_w> mathiaz: thanks, pulling, I'll get back to you in a minute :-)
<mathiaz> james_w: great - so what I did was branch sid/ k-merge; cd k-merge; merge ../karmic
<james_w> you were merging ubuntu in to Debian?
<mathiaz> james_w: and I end up with 68 conflicts
<mathiaz> james_w: well - I was trying to merge debian in ubuntu
<mathiaz> james_w: ie - upload a new version of ipsec-tools to ubuntu based on the debian package
<mathiaz> james_w: if I do the other way around (branch karmic/ k-merge; cd k-merge; merge ../sid) I end up in the same situation
<mathiaz> james_w: with 68 conflicts to resolve
<ogra> doko, is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39501 fixed in our gcc 4.4 ?
<ubottu> gcc.gnu.org bug 39501 in target "-O -ffinite-math-only gets min(x,y) optimization wrong for soft-float on arm-*-gnueabi" [Normal,Assigned]
<ogra> (the bug sadly only talks about 4.3.x)
<james_w> mathiaz: I think that it's because the Ubuntu history is more complete than the Debian one
<james_w> mathiaz: I need to spend some time looking at it though
<james_w> could be annoying if this affects a lot of packages
<doko> ogra: yes, and 4.3 as well
<mathiaz> james_w: ok
<james_w> mathiaz: thanks for testing
<ogra> doko, yes, i saw 4.3 ... i have some werid stuff going on the the ogg gstreamer plugin and digging got me to that bug, thanks for the info
<mathiaz> james_w: now the last block I stumbled upon was how to construct the final src package.
<mathiaz> james_w: in the case of the squid package, bzr merge worked perfectly well
<mathiaz> james_w: and I ended up with (almost) the same debdiff as posted in LP
<mathiaz> james_w: but when I tried to bzr bd -S it failed as there wasn't any .orig file.
<mathiaz> james_w: IIUC in the long term it won't matter anymore as we would just push to the LP branch
<mathiaz> james_w: but in the short term I'd still need to download the .orig file from somewhere
<james_w> it should have extracted it
<james_w> mathiaz: ah, it's possibly a bug that I fixed the other day
<mathiaz> james_w: so bzr bd is supposed to rebuild the .orig file from the bzr tree?
<james_w> mathiaz: if you still have the branch around then the output of "bzr bd -S" would allow me to confirm
<james_w> yeah
<lool> evand: Just a note that I merged the guadalinex branch except for s/Ubuntu/distribution changes in lp:usb-creator (#310804) will unsub main sponsors now
<mvo> pitti: did you had a chance to look at my apport branch yet (not urgent, just curious)?
<mathiaz> james_w: http://paste.ubuntu.com/214923/
<james_w> mathiaz: yup, stupid bug, sorry
<james_w> http://bazaar.launchpad.net/~bzr-builddeb-hackers/bzr-builddeb/trunk/revision/342 is the fix
<james_w> I should do an SRU
<mathiaz> james_w: well - this is running in a karmic chroot
<james_w> ok, I should upload :-)
<sbeattie> slangasek: you have a thinkpad, are you seeing bug 395358?
<ubottu> Launchpad bug 395358 in acpi-support "thinkpad fn+f5 regression now toggles wifi and bluetooth at once" [Undecided,New] https://launchpad.net/bugs/395358
<slangasek> sbeattie: I can confirm that the rfkill interface no longer shows up under /sys/class/net/wlan0/
<slangasek> sbeattie: the behavior I see is that it *only* toggles bluetooth
<sbeattie> hunh, interesting.
<slangasek> pitti: hrm, what's this about dpkg not complaining about conffile conflicts?
<pitti> slangasek: dpkg complains about "normal" file conflicts, but not for conffiles, AFAIK; it just re-owns the file
<pitti> slangasek: if you have some doubts, I'm happy to test that again
<slangasek> pitti: that would be a bug, surely; I've never noticed this behavior, though, can you point to an example?
<lfaraone> james_w: heh, I'm still looking for a sponsor of that PPP-pam package if you happen to know anyone, btw.
<james_w> lfaraone: in Debian?
<lfaraone> james_w: at this point I'd settle for either, but Debian is preferable.
<james_w> 'fraid not
<james_w> you can obviously put it up on REVU and keep posting to debian-mentors@
<pitti> slangasek: nice, dpkg properly fails now; thanks for checking
<pitti> kirkland: ^ ignore me then, conffiles do generate conflicts
<slangasek> pitti: ok, phew :)
<pitti> I was pretty surprised when I tested that in the past
<cjwatson> ScottK: kubuntu-netbook live images fail to build, but that's upstart (i.e. not your problem) and should get resolved fairly soon
<ScottK> cjwatson: That's actually great news.
<cjwatson> ScottK: I bodged together some extra cdimage changes to cope with different seed locations and such
<ScottK> cjwatson: Thanks for looking into it.
<cjwatson> ScottK: if you ever want non-live images, those will likely require additional bodging
<cjwatson> ScottK: do you want to be auto-mailed about kubuntu-netbook build failures? it probably won't be terribly useful until the live filesystems start building, as we don't have a system for mail notifications of failures there yet (unfortunately)
<ScottK> cjwatson: OK.  We'll cross that bridge when I think we have enough people that would test it.  Thanks.
<cjwatson> if so, let me know what address(es) to use
<ScottK> cjwatson: Probably a good idea.  Please use ubuntu at kitterman dot com.
<cjwatson> ok
<ScottK> Thanks.
<cjwatson> you may get a bit of junk towards the start ...
<cjwatson> hopefully not too much
<cjwatson> let me know if you need it turned off again :)
<cjwatson> Keybuk: are you fixing apparmor, or is somebody else?
<cjwatson> oh, heh, Kees already did
<jdstrand> cjwatson: kees has committed it to the bzr tree and I believe will upload soon if he hasn't already
<cjwatson> he has
<cjwatson> YKYBHOUTLW you can type bugs.launchpad.net/ubuntu/+source/util-linux/+bugs?orderby=-datecreated without pausing for breath
<jdstrand> excellent :)
 * lool has a blpus => https://bugs.launchpad.net/ubuntu/+source/%s keyword
<maxb> Hmm... should the new upstart also Conflict+Replace upstart-logd ?
<cjwatson> lool: oh, I have keywords too, but in this case firefox was being slow and I just gave it to w3m
<ogra> lool, blpus ?
<cjwatson> maxb: I suspect it may not actually include equivalent functionality; I don't think logd's properly implemented
<lool> ogra: bugs.launchpad.net/ubuntu/+source => blpus
<jdstrand> cjwatson: btw, mass-sync.py worked very well for me
<ogra> lool, lol
<lool> You can easily guess what bgo, lpus, or bfo are for
<dupondje> somebody knows how to debug gvfs ?
<dupondje> cause copying files seems broken
<dupondje> on Karmic
<cjwatson> jdstrand: oh good
<cody-somerville> directhex, Do you happen to know the cause of "ERROR:mini-amd64.c:199:amd64_patch: assertion failed: (amd64_is_imm32 (disp))"? It occurs on amd64 but not i386.
<kees> cjwatson: actually Keybuk did, then I fixed it harder.
<kees> cjwatson: and it's been uploaded
<cjwatson> yeah, the livefs build I was attempting just predated binaries being published
 * kees nods
<maxb> cody-somerville: Is that in Xen, perchance?
<geser> does somebody know if apparmor is supposed to work on karmic amd64? because for me the init script exists with a failure
<jdstrand> geser: open bug-- it is going to be fixed super soon now
<cody-somerville> maxb, aye
<jdstrand> geser: bug #375422
<maxb> cody-somerville: something to do with LP 237724 possibly then
<ubottu> Launchpad bug 375422 in linux "apparmor fails to load at startup" [High,In progress] https://launchpad.net/bugs/375422
<geser> jdstrand: does apparmor need a kernel module? because it seems to be missing for me
<ubottu> Launchpad bug 237724 in linux "linux-image-2.6.24-18-xen breaks mono" [High,Fix released] https://launchpad.net/bugs/237724
<jdstrand> geser: yes it needs kernel support (and LSM)
<jdstrand> geser: the forward porting is almost done and it is being tested
<cody-somerville> maxb, looks promising. Thanks! :)
<geser> jdstrand: thanks
<dupondje> https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/393012
<ubottu> Ubuntu bug 393012 in gvfs "smb: Error while copying file, "Invalid argument"" [Low,New]
<dupondje> gvfs broken on samba it seems :s
<dupondje> anyone can confirm ?
<cody-somerville> Is anyone familiar with gconftool-2? I'm wondering what possibilities there are to speed up 'gconftool-2 --makefile-install-rule <schema files>'
<mathiaz> jdstrand: is ApparmorProfileMigration still needed?
<mathiaz> jdstrand: ie can I drop changes related to ApparmorProfileMigration from karmic packages?
<ScottK> pitti: Yesterday I did a fresh Karmic install (Kubuntu) on a Dell Mini 10v which needs bcmwl-kernel-source to make wireless work.  Is Jockey supposed to automatically work that out for the user (this is the first time I've needed non-free wifi since Edgy)?
<superm1> ScottK, jockey is supposed to depend upon bcmwl-modaliases
<superm1> so depends on how recent of an image you were using
<ScottK> superm1: That was installed.
<ScottK> It was yesterday's live snapshot
<superm1> then it should be offering broadcom to you in jockey
<ScottK> It didn't.
<ScottK> When I ran jockey manually it just said I had no proprietary drivers installed.
<superm1> did you have an up to date apt cache?
<ScottK> I'm not sure.
<superm1> jockey won't offer it unless it knows about the package from your apt cache
<ScottK> OK.  I'll see that next time I do an install.
<superm1> and i dont believe kubuntu cds offer it in their pool, so it wouldnt be in the default apt cache from the CD
<ScottK> Ah.
<ScottK> So I need to add that ....
<superm1> if you want it to be able to install it without needing internet access, you'll want it in the seed at least
<ScottK> Yes.
<pitti> ScottK: it's supposed to work; testing appreciated
<ScottK> pitti: OK.  Well I think superm1 just pointed out the problem (no package on the CD to offer).
<pitti> ah, right
 * ScottK will fix and then try again.
<pitti> before they were in l-r-m
<pitti> so I guess it's fair to include it
<ScottK> I think it clearly falls into the catagory of make common hardware work.
<superm1> its on the ubuntu cd and ubuntu dvd's pool already, just kubuntu and others don't have it
<ScottK> superm1: OK.  Which seed is it in?
<superm1> ubuntu.karmic
<superm1> pitti, reminds me, were you intending to upload jockey again before a3?  was hoping jockey-text would be available in a3
<pitti> superm1: yes, will do
<superm1> thanks
<pitti> superm1: I still want to fix that rmmod/modprobing
<superm1> ah yeah, almost forgot about that too.
<jdstrand> mathiaz: yes, why would you want to drop it?
<ScottK> Found it.  ship-lave
<ScottK> live even
<mathiaz> jdstrand: I'm looking at mysql-5.0 merge from debian
<mathiaz> jdstrand: and it seems that the code taking care of putting the profile in complain mode will never be run in karmic
<mathiaz> jdstrand: I'm looking at the mysql-server-5.0.prerm script
<ScottK> pitti and superm1: Seeded now.  Thanks.
<jdstrand> mathiaz: prerm?
<mathiaz> jdstrand: hm - debian/mysql-server-5.0.preinst rather
<ScottK> cody-somerville: You might want review the discussion between superm1 and myself above and consider seeding bcmwl-kernel-source for Xubuntu.
<jdstrand> mathiaz: sorry, someone came to the door
<mbiebl> chrisccoulson: did you actually succeed in running a recent 0.7?
<mbiebl> I tried a couple days ago, and the tracker-miner process immediately segfaulted
<ion> âSoftware you want, as long as you want shoddy packaging and no security updatesâ
<mathiaz> jdstrand: np - another related question is whether the force-complain directory is still needed
<jdstrand> mathiaz: seems that steps 2, 3 and 5 can be skipped
<jdstrand> mathiaz: notice step 4 has changed, and since you are doing the merge, it would be great if you could update the package during the merege
<jdstrand> (I plan to update all the packages to use the new reload during this cycle)
<mathiaz> jdstrand: ok
<ScottK> jdstrand: I'm probably doing a clamav upload this weekend, so if you can provide a diff, I can include it.
<jdstrand> ScottK: sure, thanks
<c_korn> is firefox 3.5 in jaunty a beta or the final release? http://packages.ubuntu.com/jaunty/firefox-3.5
<c_korn> the file list suggests that it is the beta 4. http://packages.ubuntu.com/jaunty/amd64/firefox-3.5/filelist
<jpds> Anyone know why apparmor is broken in Karmic?
<Pici> c_korn: Its the final.
<c_korn> Pici: ok, thanks.
<jdstrand> jpds: bug #375422
<ubottu> Launchpad bug 375422 in linux "apparmor fails to load at startup" [High,In progress] https://launchpad.net/bugs/375422
<jjohansen> jpds: because it has been waiting on a rewritten apparmor
<jpds> jdstrand: Thanks, subscribed
<jjohansen> the new apparmor will be in alpha3 but I am not sure if it will be turned on by default
<jpds> jjohansen: Considering the related blueprints, I hope so.
<jdstrand> jpds: not to speak for jj, but not turned on by default for Alpha 3, not all of karmic
<jpds> jdstrand: Ah, so it will be in final?
<jdstrand> jpds: that's the plan
<jjohansen> jpds: it could very well be turned on for alpha3, I am just not sure it will be
<jpds> Groovy, thanks.
<jdstrand> jpds: testing is ongoing and want to make sure the big bugs are shaken out first
<jjohansen> jpds: if it isn't on by default adding security=apparmor to the boot line will do it
 * jdstrand speaks as if he has participated in that testing :)
 * jdstrand will as soon as he has the new kernel ;)
<chrisccoulson> mbiebl - hi, sorry i didn't respond. i've only just got back
<jjohansen> jdstrand: I can point you at a kernel
<chrisccoulson> i'm running 0.7 here, although tracker-miner-fs doesn't crash immediately
<chrisccoulson> it does crash eventually though ;)
<mbiebl> chrisccoulson: how old?
<jdstrand> jjohansen: yeah, I know kees has it going. I likely won'
<chrisccoulson> mbiebl - 7-July i think
<jdstrand> t be able to do anything with it til next week anyway
<jjohansen> jdstrand: okay, np
<jdstrand> jjohansen: and excellent work! :)
<jjohansen> jdstrand: just don't want to hold you up anymore than I already have
<chrisccoulson> sorry, 6-July. a day older ;)
<mbiebl> chrisccoulson: no luck for me :-/
<chrisccoulson> hmmmm. anyway, i wanted to talk to you about the packaging split if you have some time
<jdstrand> jjohansen: no complaints here. I know it was a lot of work and am really looking forward to it
<mbiebl> chrisccoulson: do you plan any changes?
<chrisccoulson> now it's possible to have tracker-store independently of any indexing, i think that tracker-miner-fs should split off in to it's own package
<jdstrand> jjohansen: I've been doing my AA profiling work on jaunty in the meantime, so I am not blocked
<mbiebl> chrisccoulson: is there already an application out there, which only uses tracker-store?
<mbiebl> I'd do it on a as-needed basis
<chrisccoulson> mbiebl - not sure yet, but the idea is that people can write applications that store data in tracker-store
<chrisccoulson> so it would be nice to let people have the metadata store without the indexing
<mbiebl> sure. but as long as there aren't such applications yet
<mbiebl> ...
<chrisccoulson> yeah, i suppose. i just wanted to get your thoughts on it;)
<mbiebl> I agree that it makes sense mid to long term
<mbiebl> I just don't see the need yet
<chrisccoulson> yeah, no problem
<mbiebl> let's see how things evolve
<mbiebl> and give it some time to stabilize
<chrisccoulson> mbiebl - you can check out the packaging in my PPA - https://edge.launchpad.net/~chrisccoulson/+archive/tracker
<chrisccoulson> that contains a split, although it's not 100% ideal
<mbiebl> thanks, bookmarked
<chrisccoulson> it still installs the push modules in the same package as tracker-store
<chrisccoulson> mbiebl - what version of evolution do you have in debian now?
<mbiebl> 2.26.2-2
<chrisccoulson> cool, so you can enable them too. the evo module is actually working quite well
<mbiebl> you mean for 0.6.95?
<chrisccoulson> the tracker search tool isn't working yet, but you can inspect the store with tracker-explorer, and i can see my email data in the store now
<chrisccoulson> no, only in 0.7
<chrisccoulson> the push modules don't work at all in 0.6.95
<chrisccoulson> i'm going to try and start giving 0.7 some extensive testing this week though, to hopefully find some bugs and help speed up the 0.7 release;)
<mbiebl> chrisccoulson: are you still planing to go for 0.7 in karmic?
<chrisccoulson> the crash you experience is interesting though. can you see it crashing on any particular file or not?
<chrisccoulson> i was hoping for 0.7 in karmic, but i'm not sure yet
<chrisccoulson> it depends how long it takes for the search tool to be re-written
<chrisccoulson> there's not much point in uploading it until that works, otherwise users will just report lots of bugs for functionality that is known to not work yet
<mbiebl> chrisccoulson: bt: http://paste.debian.net/41565/
<ion> I fail at finding whatâs new with Tracker 0.7.
<chrisccoulson> mbiebl - i havent seen that one before
<chrisccoulson> ion - what do you mean?
<ion> I was trying to learn the major changes from 0.6 to 0.7, but didnât find the information by skimming through the project website. http://live.gnome.org/Tracker/Roadmap wasnât helpful either.
<chrisccoulson> hmmm, yeah, it's not easy to see whats new from the roadmap. you should have a look at the changelog in git though ;)
<chrisccoulson> there are major architectural changes.
<chrisccoulson> filesystem indexing has been split off in to a stand-alone entity now, meaning it is possible to remove filesystem indexing functionality and use tracker as a generic RDF metadata store
<ion> Neat
<chrisccoulson> which you can store anything in really;)
<ion> Yeah
<chrisccoulson> it also makes it very easy to write your own data providers to push data in to the store
<chrisccoulson> eg, the new evolution module is a plugin inside of the evolution process which goes through your emails and sends the data to the tracker store
<ion> Alright
<chrisccoulson> also, QDBM has gone completely now, which should close a lot of old bugs
<chrisccoulson> such as index corruption and the inability to search for incomplete words
<chrisccoulson> 0.6.9x has been a nightmare in ubuntu;)
<mbiebl> pvanhof has some nice posts on his blog
<mbiebl> like eg. http://pvanhoof.be/blog/index.php/2009/07/02/tracker-experimental-merged-to-main-development-tree-ivans-presentation
<mathiaz> kees: hm - my sbuild karmic schroot are broken
<mathiaz> kees: same error like yesterday: http://paste.ubuntu.com/215063/
<mathiaz> kees: are you karmic sbuild schroot working?
<mathiaz> kees: are *your* karmic sbuild schroots working?
<mathiaz> kees: this time I've tried to build a package that has already been published in the archive
<mathiaz> kees: and not used a local source build package
<jdstrand> ScottK: debdiff added to bug #397988
<ubottu> Launchpad bug 397988 in clamav "clamav should only reload individual AppArmor profiles" [Undecided,In progress] https://launchpad.net/bugs/397988
<ScottK> jdstrand: Thanks.  This can just go in Karmic, right?
<jdstrand> ScottK: yeah, I'd upload it, but thought you had more to do
<jdstrand> ScottK: no reason to backport it
<ScottK> jdstrand: Does it hurt if I do?
<jdstrand> ScottK: no
<jdstrand> ScottK: but it is more of an optimization than a problem
<ScottK> I've got one more set of updates for 0.95.2 in Karmic before I think it's mature enough for jaunty-proposed.
<jdstrand> ScottK: it'll becoming increasingly important to not reload all of AppArmor as more and more profiles are added
<ScottK> I may not get away with it, but I'd like to keep the packaging as much the same as possible.
<jdstrand> *shrug*
<jdstrand> doesn't bother me any :)
<ScottK> Right.  It's not you I'm worried about.
<jdstrand> heh
<kees> mathiaz: let me try, one sec
<mathiaz> kees: which version are you running on your build host? jaunty?
<chrisccoulson> mbiebl - thanks, that's useful
<kees> my host is karmic and I build in schroot/sbuild
<mathiaz> kees: right - my host is still hardy
<mathiaz> kees: and thus I'm using sbuild from hardy
<kees> I can't say I've tested that :)
<mathiaz> kees: there was a change in sbuild about not parsing dpkg-source output anymore
<mathiaz> kees: it may be related to the issue I'm running into
<kees> mathiaz: could very well be.  perhaps upgrade you machine to karmic?  :)
<mathiaz> kees: ok - I'm hitting debian bug 471747
<ubottu> Debian bug 471747 in sbuild "sbuild: must not parse dpkg-source's output" [Important,Open] http://bugs.debian.org/471747
<kees> mathiaz: yeah, looks like it.  can you move your build system to jaunty at least?
<mathiaz> kees: well - I'm gonna try to apply the patch to hardy sbuild
<mathiaz> kees: and see if it fixes the issue
<ScottK> Updated my mini 10v to the new upstart and it seems to run fine.
<superm1> Keybuk, ping.  I'm having a hard time figuring out something going on with a udev rule.  [ACTION=="add", SUBSYSTEM=="bluetooth", RUN+="/usr/sbin/bluetoothd --udev"] is the rule.  it works fine if the device is hotplugged, but not if the system boots up with the device plugged in.  Any ideas?
<robbiew> superm1: it's 10:26pm on a Friday night in the UK...so Keybuk may not be around
<ion> Iâm sure iâve seen Keybuk online even after midnight (in UK). :-P
<robbiew> yep
<davmor2> ion: it's only 10:29
<ion> Thatâs what robbiew said.
<ion> Anyway, IRC generally works even with huge delays between messages and responses, as long as people donât have their awaylog functionality crippled... AFAIR Keybuk has, though. :-P
<cjwatson> yeah, Keybuk doesn't tend to read IRC scrollback. mail him
<robbiew> superm1: ^
<ion> One doesnât even need to read scrollback per se, as long as the client is able to give a short list of highlighted messages since the last time online.
<mbiebl> chrisccoulson: tried your packages on karmic
<mbiebl> get the same segfault
<chrisccoulson> very strange. it might be worth having a chat with martyn then. i'll see if i can reproduce it at some point though
<mbiebl> chrisccoulson: do you also see this warning:
<mbiebl> (tracker-miner-fs:3536): Tracker-WARNING **: could not create proxy
<chrisccoulson> mbiebl - i've just started it back up again, so i'll see if it appears
<chrisccoulson> yeah, i see that warning
<mbiebl> hm, doesn't /usr/share/dbus-1/services/org.freedesktop.Tracker.Miner.FS.service belong into tracker-miner
<chrisccoulson> yeah, it should do
<chrisccoulson> i'm trying to figure out where that warning is triggered from
<mbiebl> Interesting:  tracker-explorer
<mbiebl> tracker-explorer: error while loading shared libraries: libgee.so.0: cannot open shared object file: No such file or directory
<chrisccoulson> hmmmm, does it not depend on libgee?
<mbiebl> nope, does tracker-explorer miss a {shlibs:Depens}
<chrisccoulson> heh
<chrisccoulson> it does ;)
 * chrisccoulson hides
<mbiebl> chrisccoulson: is there a bzr branch where I can see the packaging files?
<chrisccoulson> i'll sort that out
<chrisccoulson> i havent put the packaging in bzr yet. i can do that though
<chrisccoulson> i might not be able to do it tonight though
<mbiebl> oh, no hurry
<mbiebl> chrisccoulson: looks like a c&c error
<mbiebl> both tracker-mine-fs and tracker-explorer have python:Depends
<mbiebl> instead of shlibs:Depends
<chrisccoulson> yeah, that sounds right. i'll fix that in a minute
<chrisccoulson> that warning looks bogus by the way
<chrisccoulson> if (!proxy)
<chrisccoulson> g_warning ("could not create proxy");
<chrisccoulson> but nothing sets up proxy
<chrisccoulson> at least i can't see where that happens
<chrisccoulson> in libtracker/tracker.c
<mbiebl> we should also prod upstream about moving libtracker-module and libtracker-common to /usr/lib
<mbiebl> if they want to see it used by 3rd party apps
<chrisccoulson> yeah, i agree. not sure what the plan is for those
<chrisccoulson> mbiebl - i've uploaded a fixed version now
<chrisccoulson> fta - i'm not sure what is causing the status icon in xchat to disappear
<chrisccoulson> i tried running the jaunty version on karmic and it does the same
<chrisccoulson> i tried running it with the jaunty version of gtk on karmic, and it still does the same
<chrisccoulson> :-/
<jdstrand> didrocks: fyi-- committed bash completion to ufw
<jdstrand> didrocks: I made it so I didn't need to change ufw code though-- ie I update /etc/bash_completion.d/ufw to parse 'ufw --help'
<jdstrand> didrocks: it'll be in the next upload to Debian
<jdstrand> didrocks: thanks for you work on it :)
<maxb> xchat status icon? Seems happily there in Karmic for me
<pochu> maxb: when started automatically by gnome-session
<maxb> ah, right. No, I'm not doing that
#ubuntu-devel 2009-07-11
<TheeMahn> Colin Watson can I get your attention?
<ScottK> TheeMahn: Probably not right now.  It's the middle of the night in his TZ and the odds of him being awake and at the keyboard are rather small.
<TheeMahn> Thanks, I was here to point our errors & yes I know launchpad is there.
<Seeker`> TheeMahn: why not report them on launchpad then?
<TheeMahn> He wiped out 1 he shold have re-considered, I was testing it as he did his hanywork.
<Seeker`> "wiped out"?
<TheeMahn> Well you won't find on launchpad anymore ;)
<ScottK> Wiped out what?
<Seeker`> what was the error?
<TheeMahn> I also build an alternative
<TheeMahn> search my name
<Seeker`> what was the error?
<TheeMahn> 33## he fixed, I think it is wrong he removed it from launchpad
<TheeMahn> it introduced another error
<TheeMahn> I wanted to speak with him personally
<Seeker`> 33##?
<TheeMahn> I will not fill in the blanks
<Seeker`> why not?
<TheeMahn> It does not exist on launchpad
<Seeker`> why not explain what the actual problem is instead of being cryptic
<TheeMahn> That is between him & I
<Seeker`> TheeMahn: you wont say what the bug you think was introduced was?
<TheeMahn> sure I could tell you, are you theUbiquity man
<Seeker`> is there any reason not to tell me?
<TheeMahn> I know what is going on
<TheeMahn> it is between me & him
<TheeMahn> I won't "try" to help you again is that the attitude I need to have?
<Seeker`> pardon?
<TheeMahn> are you a dev?
<Seeker`> no, just interested
<TheeMahn> yeah, sit in those shoes just once.
<Pici> Um. okay then.
<Seeker`> WHAT. THE. ....
<ScottK> Unfortunately he left before I could warn he he was about to get thrown out.
<wgrant> He's the Ultimate Edition guy.
<ScottK> Ah.
<wgrant> Ultimate Edition and Ultamatix
<wgrant> That should give an example of the sanity we should expect.
<ScottK> Right.  Got it.
<wgrant> Colin is powerful indeed to remove bugs from Launchpad.
<pam> asac: Is a non stripped version of firefox available somewhere? (trying to debug a segfault on Jaunty)
<wgrant> pam: Debug symbols for most Ubuntu packages are on ddebs.ubuntu.com.
<pam> wgrant: yeah, I just saw that on https://wiki.ubuntu.com/MozillaTeam/Bugs
<pam> I got confused because firefox-3.5-dbg is present in the normal repos
<pam> But https://lists.ubuntu.com/archives/ubuntu-mozillateam-bugs/2008-June/047318.html says you don't bulid them anymore?
<wgrant> So it seems.
<wgrant> There's little (but not no) reason to have -dbg packages now we have automated symbol extraction.
<pam> oh - not aware of that
<peerless> hello any one here?
<ubuntuella> Hey peerless.
<asac> pam: we build them again because dbgsym was a mess ;)
<asac> xulrunner-1.9.1-dbg + firefox-3.5-dbg
<pochu> asac: what's the problem with dbgsym?
<asac> pochu: bit problem: we dont get any for security updates (and i think also not for -proposed/-updates bits)
<asac> so for firefox they are in general useless for stable releases ;)
<asac> s/bit/big/ ;)
<wgrant> asac: That'll be fixed soon...
<pochu> asac: oh I see
<asac> the other reason is that we use ppa quite heavily for dailies etc
 * Keybuk is starting to think there's a gcc armel bug
 * Keybuk got the 150 minutes of inactivity on the exact same source file again
<ScottK> Keybuk: About half the KDE packages hit that too.  In our case it turns out that lzma compression takes a LONG time on armel.  NCommander rebuilt some of them by hand and they do eventually finish.  There is some discussion about raising the timeouts.
<Keybuk> scottK: this is just gcc compiling a C file
<Keybuk> it's only 16,000 lines too
<ScottK> OK.  So maybe its slow and bugged then.
<ogra> Keybuk, i also dont think its actually the lzma stuff, especially since there is no output at all during these timeouts and there is definately no uncompressing involved at that time in some of the packages
<ogra> Keybuk, i'm doing an upstart testbuild locally now ...
<Laney> Hrm
<Laney> has something happened to the dm_snapshot module in karmic?
<Laney> like... it disappearing? "FATAL: Module dm_snapshot not found."
<ogra> Keybuk, seems you are right ... http://paste.ubuntu.com/215454/
<ogra> though the build goes on afterwards here (using dpkg-buildpackage)
<Keybuk> heh
<ogra> and rolls a deb :)
<ogra> Â»upstartÂ« in Â»../upstart_0.6.0-3_armel.debÂ«.
<ogra> :)
<Keybuk> the build should continue, it's just the test suite :)
<ogra> i dont get why the buildd produces a timeout though
<Keybuk> I || true it, but it's useful to have the results in the log
<Keybuk> dunno, assumedly nothing reaped gcc's attempt to crash
<ogra> its true that it takes a while especially in that test that the former one
<ogra> but neither took more than 5 min here and my system is very slow (running off a micro SD card)
<ogra> *that test 'and' the former one
<jacquesdupontd> hi
<jacquesdupontd> i have a question someone is available for me ?
<jacquesdupontd> ok i see :)
<jacquesdupontd> still nobody awake ?
<Ampelbein> jacquesdupontd: just ask, maybe someone knows the answer.
<jacquesdupontd> ok the thing is i'm on jaunty and have an old ati 7000 igp card
<jacquesdupontd> the opensource drivers are working perfectly except it doesn't have 3d
<jacquesdupontd> as you all know i think
<jacquesdupontd> i know we are far from the time ati release something for us, but there's patch here and there
<jacquesdupontd> may someone know more about this
<Ampelbein> bryce: ^^ can you look at jacquesdupontd's comments?
<jacquesdupontd> thx Ampelbein
<ScottK> jacquesdupontd: There is also an #ubuntu-x channel where you might get a better result.
<jacquesdupontd> thx
<jacquesdupontd> i go smoke a cig
<jacquesdupontd> (i know that's very bad)
<ogra> hrm, through upstart not building but having the seed change /sbin/runlevel is missing on armel systems :(
<ion> Ouch. ubuntu-minimal probably should have had a versioned dependency.
<ogra> yeah
<ogra> well
<ogra> its no issue for already installed systems
<ogra> and i have a selfbuilt package for my freshly bootstrapped ones
<ogra> but indeed its an issue
<pam> asac: heh :) thanks
<jetienne> q. im doing a livecd, compressing squashfs use a significant time at each try, is there a way to avoid this ? like booting on it without this compression
<cjwatson> jetienne: mksquashfs has various options to control compression, although you may find the work is dominated more by the I/O time to write out the single big file (which you do have to do, one way or another) than it is by the CPU time of compression; you'd have to experiment to determine that
<cjwatson> jetienne: man mksquashfs
<jetienne> cjwatson: thanks i will look
<Keybuk> I like it when the Upstart test suite finds kernel bugs
<legend2440> hi does jaunty support acpi 2.0?
<legend2440> is there another channel i should ask in?
#ubuntu-devel 2009-07-12
<slangasek> I don't understand the purpose of ubuntu-devel being moderated, if "please put a browser on the Linux kernel and call it Ubuntu" makes the cut
<pochu> I guess it's psychological
<pochu> many people don't probably mail -devel because it's moderated :)
<slangasek> perhaps
<ScottK> slangasek: Maybe someone should ask Barry Warsaw for a "No, send this to devel-discuss" button for the moderator in mailman.
<Keybuk> slangasek: indeed
<Keybuk> clearly a browser on top of the Linux kernel should be called "ChromeOS"
<slangasek> Keybuk: that's *GNU*/ChromeOS
<ScottK> Back will it have emacs?
<ScottK> Back/But
<directhex> ScottK, *insert tasteless yet topical joke involving emacs virgins here*?
<ScottK> Yeah, well I figured people would get that without me having to actually say it.
<billybigrigger> are we going to end up with packagekit in karmic?
<directhex> i never got the jumping up & down people do about packagekit
 * ScottK neither.  We're using kpackagekit in Kubuntu and it's really unsuitable.
<emma> oh yeah?
<ScottK> Yeah.
<wgrant> ScottK: How does that work with debconf?
<ScottK> wgrant: It doesn't.  That's one chunk of the unsuitableness.
<wgrant> ScottK: It's not the primary package manager, then?
<ScottK> wgrant: It is.
<wgrant> .... huh?
<ScottK> Our choices were Adept which was still beta and only barely being developed, kpackagekit which had some people behind it, or no GUI package management.
<ScottK> Personally, I'd have gone with choice 1 or choice 3, but it wasn't my decision.
<ScottK> It doesn't do any cryptographic verification of packages either (this may get fixed in Karmic).
<ScottK> It crashes a lot.
<ScottK> It doesn't notify about new packages reliably.
<ScottK> There's no way to do the equivalent of dist-upgrade.
<ScottK> Other than that, it's not too bad.
<wgrant> Um, how did it get away with not verifying signatures?
<wgrant> That sounds like about the worst possible kind of bug.
<ScottK> Well Adept 3 didn't do it either, so it wasn't a regression.
<ScottK> (Adept 2, the KDE3 one we had in Hardy did do this)
<ScottK> If it sounds like I'm grumpy about it, then your on track.
<wgrant> I'm very scared now.
<ScottK> Yeah, well except for this netbook that I'm about to reinstall, I've never installed a package using it.
<Hobbsee> slangasek: i don't think new subscriptions get moderated :(  perhaps they should
<tracyanne> I'm looking for help to create a custom Ubuntu installer, that will create 3 partitions by default root swap home instead of the standard root swap that is the default Ubuntu install
<cjwatson> (I answered tracyanne's question on #ubuntu-installer)
<didrocks> jdstrand: thanks for merging it :)
<jetienne> q. i am building livecd, building the md5sum.txt consumes time, can i skip it if i am ready to give up the possibility to check the cd
<Keybuk> slangasek: GNU/kLinux/ChromeOS
<ogra> geez ... upstart fails totally random places if i try to build it
<ogra> hmm and gcc-snapshot ftbfs on armel too ... bad
 * ogra tries to build it himself
<Sarvatt_> see you in 48 hours :)
<Sarvatt_> oh just snapshot
<ogra> well, 4.4 definately has issues, i want to see if they go away with snapshot
<ogra> and my armel build system here is as fast as the buildds ...
<Sarvatt_> is it failing making the lzma debs, or during the build/test runs?
<ogra> its segfaulting during builds, sometimes it spills "internal error" during the tests ... totally random
<ogra> bug 398403
<ubottu> Launchpad bug 398403 in gcc-4.4 "gcc-4.4 fails to build upstart 0.6 on armel due to an internal compiler error" [High,New] https://launchpad.net/bugs/398403
<Sarvatt_> how much memory do those builders have?
<ogra> 512M
<Sarvatt_> (just curious)
<Sarvatt_> i get random failures compiling gcc in 512MB on my OpenVZ VPS
<ogra> well, i didnt get failures compiling gcc :)
<ogra> i did get failures compiling upstart
<ogra> gcc segfaulting or dying with internal error
<Sarvatt_> never could figure out why, can compile it from upstream source fine but rebuilding the packages fails in random spots
<cjwatson> jetienne: yes
<jetienne> cjwatson: thanks
<Sarvatt_> thats exactly the error it fails out with too not that it says alot
<Sarvatt_> gcc: Internal error: Killed (program cc1) that is, not failing in that specific spot.. some kind of ulimit problem maybe?
<ogra> we'll see if it goes away if building with -snapshot
<ogra> (once i have built that :) )
<ogra> well, i doubt that since i also get random segfaults
<ogra_> grr
<ogra_> gcc -c  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../src/gcc -I../../src/gcc/. -I../../src/gcc/../include -I../../src/gcc/../libcpp/include  -I../../src/g
<ogra_> cc/../libdecnumber -I../../src/gcc/../libdecnumber/dpd -I../libdecnumber    genrtl.c -o genrtl.o
<ogra_> cc1: internal compiler error: Segmentation fault
<ogra_> Please submit a full bug report,
<cjwatson> isn't that basically classic gcc FAQ symptoms of bad RAM?
<cjwatson> particularly when intermittently reproducible
<cjwatson> or I suppose that you're short on memory
<cjwatson> http://www.bitwizard.nl/sig11/
<cjwatson> I mean, obviously segfaults are often programming errors. But intermittent random-appearing segfaults in something like gcc that has known input and processes it in a deterministic way ... well, go figure
<cjwatson> a gcc bug would not be the first thing I'd suspect for that, myself
<pochu> pitti: hi, what space do you need for the ddebs archive? ISTR it was around 5GB/arch/release, counting main+restricted+universe+multiverse?
<gimpuzmani> Hello
<gimpuzmani> I want to interview with Ubuntu developer
<gimpuzmani> for e-magazine
<pochu> pitti: hmm, seems to be 12GB for main+universe on karmic/i386 ?
<geser> jdstrand: re bug 398445: it's already fixed but the fix didn't land yet on edge
<ubottu> Launchpad bug 398445 in soyuz "getPublishedSources dies with Internal Server Error on karmic distro_series (dup-of: 397732)" [Undecided,New] https://launchpad.net/bugs/398445
<ubottu> Launchpad bug 397732 in soyuz "Getting an SPPH through the API crashes if the SPR is unsigned" [High,Fix committed] https://launchpad.net/bugs/397732
<geser> jdstrand: getPublishedSources() OOPSes currently for every synced package
<jdstrand> geser: ok, cool. thanks :)
<Carroarmato0> is it normal for an Ubuntu server to ask me to reboot the system juist when I logged in?
<Carroarmato0> do I have to worry? :|
<|Baby|> anyone with a Nvidia graphic card might want to help me test a game package?
<tgpraveen2> Carroarmato0: wrong channel
<tgpraveen2> try ubuntu-server or something
<Carroarmato0> tgpraveen2, sorry about that
<laga> ping pitti - hey. do you know if devicekit-power is already used in karmic? i'm wondering because i don't see support for quirks in the code
<ion> i   ubuntu-desktop      Depends gnome-power-manager, i A gnome-power-manager Depends devicekit-power (>= 009)
<laga> ion: yeah. but i think HAL is still used for some stuff (or at least it can be used by devicekit-power.. from what i read on their mailing list). so i'm not sure if the quirks are available or not
<realo> hiho
<realo> we develop http://dooble.sf.net --- currently making the linux release
<realo> the idea is, to maybe later add an linux kernel, so to have the browser as the gui
<realo> anyone insterested to join or help to create a deb. file for the linux release?
<pochu> a browser on top of a kernel? that sounds familiar :)
<mok0> realo: no one here right now, probably better to post a message to udd
<realo> uud?
<realo> yes a browser on top of a kernel
<realo> dooble has a desktop integrated for that
<pam> What is the best way to work on a merge issue when a package is assigned to Ubuntu Core Developers? (to check we are not duplicating work)
<mok0> pam, contact last uploader
<pam> mok0: ok. Thanks
<lifeless> realo: 'udd' == 'ubuntu distro development' list, I think
<Laney> ubuntu-devel-discuss
<pam> cjwatson: Do you know if anyone is looking at the gfxboot patches for syslinux (merge issue)? Not sure https://bugs.launchpad.net/ubuntu/+source/syslinux/+bug/270822 is the official bug. Otherwise, I'd be happy to give it a shot (we already talked a bit about it with hpa).
<ubottu> Ubuntu bug 270822 in syslinux "please upgrade syslinux from debian to 3.80" [Low,Triaged]
<ion> (offtopic) realo: Dooble seems to contain RetroMessenger, which seems to be based on RetroShare. The last time i looked, RetroShare was horribly insecure. It used an ancient version OpenSSL (â´ many unpatched security holes) with a RetroShare-specific patch (that appears to be a pain to rebase against a newer version of OpenSSL).
<lifeless> Laney: ah thanks
<cjwatson> pam: probably not for karmic
<cjwatson> pam: seems like a heck of a lot of work in a critical component, would rather do it at the start of a release
<cjwatson> pam: if somebody wants to do it, I guess I can review it, although I expect that reviewing it might actually be as much work as just doing it myself ;-)
<pam> heh
<cjwatson> pam: although it *is* good news that the gfxboot patches are merged upstream
<loois> is it possible to upgrade the kernel + intel drivers to jaunty without all the other upgrades?
<loois> oops maybe i'm in the wrong channel :(
<cjwatson> pam: so, I don't have time, but feel free to suggest patches in the form of a diff against the current package in Debian unstable. Please test them with current CD images
<pam> cjwatson: getting rid of the old suse patch would be great
<pam> okay
<pam> cjwatson: Just wanted to double check you are not actively working on it right now ;)
<cjwatson> I am not
<cjwatson> I've commented on the bug. Depressed as usual about bugabundo's rather direct attitude
<maco> is there a mini iso for karmic yet?
<pam> Thanks for the comment. Will ping hpa about it as soon as he is back.
<cjwatson> maco: always was
<maco> apparently cdimage is not the right place to look...got a hint for me?
<cjwatson> pam: why hpa? I know he's upstream, but I wouldn't expect him to be involved in Ubuntu packaging
<cjwatson> oh, no links on cdimage/netboot/, bah
<cjwatson> maco: look at /netboot/jaunty/ on cdimage, do the obvious URL substitution :-)
<cjwatson> I'll sort out cdimage now
<maco> ok
<cjwatson> oh, actually
<cjwatson> maco: http://cdimage.ubuntu.com/netboot/karmic/ does exist, it's just not linked from /netboot/
<maco> yeah, i see that
<pam> cjwatson: we talked about reducing the amount of changes between distro and upstream a while ago. Just want his take again.
<cjwatson> (fixeD)
<maco> i keep trying to look in cdimage.ubuntu.com/karmic/
<maco> thanks
<cjwatson> pam: that's usually best done by forwarding patches :-)
<pam> Forwarding? Meaning forward-porting your patches or submitting them upstram?
<pam> +e
<cjwatson> the latter
<cjwatson> what I mean is, there's little point in agreeing some kind of joint position statement with upstream that we think we should be shipping the same thing :-P
<cjwatson> developers are practical people - just send patches around if you want to get things in sync
<pam> Yeah, IIRC he didn't like the overall approach and had ideas about improving that.
<cjwatson> anyhow, I think the only patches we have against syslinux aside from gfxboot are pure packaging, not anything to do with upstream
<pam> That should be easy.
<cjwatson> so if gfxboot exists upstream as a module now then there's nothing else to be done with hpa
<pam> Anyway, there is a lot of work being done with gsoc this summer (ext4, hdt, ...) and upgrading ubuntu package would really benefit the distro
<cjwatson> but it *does* need to be smoke-tested (preferably in at least isolinux and syslinux modes) before just dropping it into Ubuntu
<pam> definitively
<cjwatson> that should be fairly straightforward for somebody with time who more or less knows their way around; have at it ;-)
<pam> heh
<realo> bug created: https://bugs.launchpad.net/ubuntu/+bug/398575
<ubottu> Ubuntu bug 398575 in ubuntu "[needs packaging] Dooble Web Browser" [Undecided,New]
<cjwatson> pam: (oh, and thanks in advance. not enough hours in the day ...)
<pam> cjwatson: You're very welcome.
#ubuntu-devel 2010-07-12
<ryan22> all packages that pass testing will be pushed to stable on wednesday. this is also when i will be checking the ppas and uploading any new packages to testings
<ryan22> i have  system worked out just cuz ive been doing this so long with my old linux distro :P
<fagan> ryan22: well I dont think the system is for me but each to their own :)
<ryan22> eh. time will tell.
<fagan> yep
<ryan22> its radical, but i think it is needed. which is why i created it ;)
<ryan22> ill keep in touch
<spikeb> software center gets its descriptions from the control file in the package, right?
<RAOF> I believe so, yes.
<RAOF> I'm pretty sure it also scrapes some information from the .desktop file the package ships.
<spikeb> ok
<pitti> Good morning
<pitti> cjwatson: libusb> will do
<pitti> kees: sourceful retracing> no, since it causes trouble with some packages; this needs some time to figure out
<solid_liq> does anyone know what an application has to support for it to be able to be restarted from its last state when you boot gnome? (The Remembered Running Applications)
<solid_liq> is that part of the free desktop specification?
<RAOF> solid_liq: It needs to register with the session manager.
<RAOF> solid_liq: That's the session-management protocol, via DBus.
<RAOF> Actually... it might not be exclusively dbus.  I forget :)
<solid_liq> RAOF, any idea of where I can find any docs for it?
<solid_liq> RAOF, I'd like to add that capability to xchat
<RAOF> I believe http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBIQFjAA&url=http%3A%2F%2Fwww.xfree86.org%2Fcurrent%2Fxsmp.pdf&ei=DKg6TMamLYu4ca_HifwO&usg=AFQjCNG_yk4ra0Lk4JZC4-nrV09wjO4mrg&sig2=y1Vjp0xpmYnRYm8qXkK6cA is still current
<solid_liq> cool thanks!  :)
<RAOF> http://live.gnome.org/SessionManagement/GnomeSession might be better
<solid_liq> RAOF, oh sweet, thanks!
<pitti> cjwatson: libusb update for bug 595650 uploaded; can you review/accept, please?
<ubottu> Launchpad bug 595650 in libusb (Ubuntu Lucid) "After the last updates HP printer stopped working" [Critical,In progress] https://launchpad.net/bugs/595650
<pitti> or slangasek
<dholbach> good morning
<dholbach> bryceh, tjaalton, RAOF: there's a bunch of X related stuff on http://qa.ubuntu.com/reports/sponsoring/ - just wanted to let you know
<dholbach> can an archive admin please process the open syncs?
<bryceh> dholbach, hmm, I paged through that but didn't see anything, just a few sync requests?
<dholbach> bryceh: yeah, I wasn't sure if it was a good idea to sync that stuff from experimental so I thought I'd leave that to you guys
<bryceh> dholbach, the titles for those sync requests indicate they're sync'd from unstable, which should be just fine
<bryceh> dholbach, even for experimental that'd probably be fine
<dholbach> bryceh: oh sorry, then it was some sync request last week I think
<bryceh> ah yes
<dholbach> in any case: just wanted to let you guys know
<RAOF> Thanks.
<dholbach> :)
<bryceh> heya RAOF
<RAOF> bryceh: Howdie.
<RAOF> 40FAA7E1T: Your robotic nature is outed at last?
<ricotz> slomo, hello, is there some progress packaging gdk-pixbuf 2.21.5 and gtk 2.21.4?
<40FAA7E1T> RAOF, oh was it in the closet?
<slomo> ricotz: nope, but seb128 wanted to do it
<bryyce> -NickServ- You are now identified for bryce2.
<bryyce> --- 40FAA7E1T :Nick collision, forcing nick change to your unique ID
<bryyce>  You are now known as 40FAA7E1T
<bryyce> wild
<ricotz> slomo, ok, is there a package name structure for gdk-pixbuf set yet? the old one is pretty outdate and might be updated to meet the structure of glib or atk?
<ricotz> slomo, https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1229696/+listing-archive-extra
<ricotz> this package still misses some installation scripts out of the gtk package
<slomo> yes, all these scripts are the most work ;)
<slomo> the package names look good btw
<ricotz> slomo, i know, but for now there is where my knowledge ends to properly update it, would take me much more time to go through it than for you :(
<slomo> ricotz: maybe tell seb128 about it later today when he's here, i'm quite busy in the next days
<ricotz> yes, the names should be good which matches the other gnome lib package well
<ricotz> slomo, ok, and hopefully there will be a gtk+3.0 package soon ;-)
<apw> cjwatson, ubuntu policy document ... 1) is the version in your people the offical version and 2) can you remind me where the 'what to check when updating from x.y.z to x.y.z+1' list is for it?
<pitti> StevenK, lool: is hildon-desktop something that we still actually want/need in maverick? it hasn't been updated since karmic, and not a lot since hardy
<pitti> StevenK, lool: same question for libosso (not updated since hardy)
<lool> pitti: It certainly has "diminishing returns"
<pitti> we could sync them from Debian, or remove them
<lool> pitti: It's not used in any of our images anymore, and the version we had was patched in a very complex way
<lool> So in theory we have some nice patches in there, but the changes are complex to look at
<pitti> those are part of Colin's "stale merges" list
<lool> Yes, guessed that, I saw it too and was scared
<lool> I wouldn't mind a sync personally; people can extract the patches from older source packages if they really want them
<pitti> so they weren't appropriate for upstream, etc?
<pitti> seb128: wrt. the "stale merges" list, I'm looking at libgtop2
<seb128> pitti, ok, it's basically a can sync one I think, but there is no interest change so we went "who cares" until now
<seb128> pitti, but if you feel like versions should be updated feel free ;-)
<pitti> it's a new upstream series now (2.28)
<pitti> seb128: yes, better to keep in sync IMHO
<seb128> well we are mostly in sync I think
<pitti> I'll check/sync
<seb128> ok
<geser> Could an archive admin 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 gcj-native-helper. For tex4ht bug
<geser> #603101 awaits sponsoring. Thanks.
<dupondje> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/603919 => this is also a cool one :)
<ubottu> Launchpad bug 603919 in pygobject (Ubuntu) ""python packages" crashed with ImportError in <module>()" [High,Confirmed]
<bdrung> geser: referring to the java bug, look at the comment from nthykier on the related debian bug
<geser> bdrung: I saw that comment but I don't know enough about java packaging to know what to do with it :( I prefer to wait on the DD with the proper fix. I just proposed to drop the version from the build dependency as it's the only package with one.
<geser> and as long the stale default-jdk-builddep deb is in the archive, any package build-depending on default-jdk-builddep can't get build as the buildd try to install the stale default-jdk-builddep and fail because of depends
<pitti> geser: removing, thanks for pointing out
<cjwatson> pitti: thanks, will look
<cjwatson> apw: yes, the version I have is the official one, though you can use the package in the archive too.  install the ubuntu-policy package and look at /usr/share/doc/ubuntu-policy/upgrading-checklist.txt.gz
<apw> cjwatson, ahh thanks
<apw> cjwatson, seems we are a little behind debian in the policy version, but it also seems to be a sync'd package from them.  do we have a policy on when we update the policy ?
<cjwatson> apw: same as other merges, when I get round to it :)
<cjwatson> apw: it's not that vitally important
<cjwatson> apw: if you want to update to debian-policy 3.9.0, feel free
<cjwatson> ubuntu-policy basically has additions rather than any significant number of changes
<apw> ok makes sense
<pitti> cjwatson, ev: after oem-config has run, is it supposed to purge itself and the dependencies (ubiquity, libicu42, reiserfsprogs, etc0
<pitti> ?
<ogra> pitti, yes
<ogra> (and it does that on our omap images)
<pitti> ogra: thanks
<dupondje> I dunno if somebody can take a look @ https://bugs.launchpad.net/ubuntu/+source/pygobject/+bug/603919 ? Its a quite important bug, as ALOT of python packages are broken because of it (check duplicate bugs it has already)
<ubottu> Launchpad bug 603919 in pygobject (Ubuntu) ""python packages" crashed with ImportError in <module>()" [High,Confirmed]
<apw> cjwatson, do you know where the chvt occurs in the boot process is that before or in plymouth ?
<cjwatson> apw: I think it's in plymouth itself
<seb128> dupondje, I'm about to upload a fix
<apw> cjwatson, could well be, it knows how to for sure.  how it knows where to go to i have no idea
<seb128> dupondje, you are sure they are broken? it seems it triggers apport but softwares work
<cjwatson> apw: hardcoded, I imagine
<baptistemm> hello
<apw> cjwatson, i am struggling to work out how to tell whether i have maintained the screen till the vt switch as i don't really know when it occurs :/  does the world work if i strip plymouth out ?
<dupondje> seb128: dunno really about apport-gtk, but for example pybootchartgui doesn't even start ...
<dupondje> and alot of other packages are affected
<seb128> dupondje, well lot trigger apport but I doubt that break softwares
<cjwatson> apw: it's in debian/rules
<cjwatson>                 --with-boot-tty=/dev/tty7 \
<cjwatson>                 --with-shutdown-tty=/dev/tty7
<baptistemm> StevenK, hi, could you renew my membership to bluetooth group
<seb128> dupondje, it's an error in the introspection that nothings is using
<cjwatson> apw: plymouth is required; at least some things will very likely break without it
<apw> cjwatson, so it is ... bah thanks
<cjwatson> apw: a plymouth splash is not required, though
<cjwatson> important distinction, plymouth doesn't imply a splash screen
<apw> cjwatson, but presumably if its there, it will VT switch
<apw> as even without 'splash' X is on 7
<apw> (but hearing you)
<cjwatson> apw: I don't recall for certain, but I think that it only VT-switches when showing the splash
<cjwatson> X does its own chvt if it needs to
<dupondje> seb128: can't test more atm, as i'm on another computer atm :) but ah well, if its getting fixed we are happy  :)
<apw> cjwatson, ahh hrm
<dupondje> you can for sure see it triggers apport lol, all those duplicate bugs
<cjwatson> apw: you can boot without the 'splash' argument to test
<apw> yeah i think that is working and telling me i am broken
<cjwatson> yeah, it's the splash plugin that calls ply_terminal_activate_vt
<doko> micahg: to fix the xulrunner-1.9.2 build failures on sparc, you may want to build with -mcpu=v9
<micahg> doko: thanks, is that for the previous releases?  It seems to build in Maverick
<doko> micahg: I thought you did do the mozilla-security-ppa uploads
<micahg> doko: chrisccoulson did the uploads there
<doko> jaunty & karmic. lucid and maverick default to ultrasparc
<chrisccoulson> doko - ok, thanks. i hadn't had a chance to look at those yet
<ricotz> hi, any chance to see thunderbird 3.1 in maverick
<micahg> ricotz: yes
<doko> chrisccoulson: I don't know yet the cause for the armel build failure in jaunty
<ricotz> micahg, nice, is there a timeframe yet, i think 3.1.1 will be out soon
<micahg> ricotz: before beta 1, 3.1.1 should be out sometime next week
<ricotz> micahg, ok
<seb128> ricotz, hi
<seb128> ricotz, slomo said you worked on gdk-pixbuf packages, do you have those somewhere?
<ricotz> seb128, hi
<ricotz> seb128, https://edge.launchpad.net/~ricotz/+archive/staging/+sourcepub/1230542/+listing-archive-extra
<seb128> ricotz, you don't work in a vcs?
<seb128> ricotz, would make easier to review changes and contributes fixes etc
<ricotz> seb128, sorry no
<seb128> ok, thanks anyway
<seb128> do you work to get those in debian?
<seb128> or should I try to get those there?
<ricotz> seb128, i want to have a gtk+3.0 package for g-s ;-) so gdk-pixbuf is needed
<ricotz> seb128, feel free to use it and get it in debian
<ricotz> seb128, it still needs some work
<seb128> ricotz, what does it need?
<ricotz> seb128, idno yet, it is work in progress, i might missed some files and some debian policies like the copyright file
<seb128> ricotz, ok, thanks
<YokoZar> seb128: ~ https://bugs.edge.launchpad.net/ubuntu/+source/wine/+bug/604415  -- I remember we talked a long while back about how Wine should declare itself as the default handler on double click once it's installed, but that wasn't possible at the time since archive manager was the default... is this fixable now?
<ubottu> Launchpad bug 604415 in wine (Ubuntu) "nautilus tries to open windows executables with file roller instead of wine" [Undecided,New]
<seb128> YokoZar, hi, no that didn't change I think
<seb128> YokoZar, but neither nautilus nor our default list changed since lucid
<seb128> so if something changed I guess that's on the wine side
<YokoZar> seb128: No, you still have to right click->open with wine.
<YokoZar> seb128: The real solution sidesteps the question anyway since the default action should be the exe-handler I describe at the wine integration spec (which would have different behavior if wine was installed/not installed)
<YokoZar> Thanks
<juliank> mvo: https://bugs.edge.launchpad.net/ubuntu/+source/sessioninstaller/+bug/604577
<ubottu> Launchpad bug 604577 in sessioninstaller (Ubuntu) "Sync sessioninstaller 0.20-1 (universe) from Debian unstable (main)" [Undecided,New]
<juliank> Needs an ACK
<mvo> thanks juliank
<mvo> juliank: doing that now
<juliank> mvo: I had to create a tarball from bzr, because glatzor's was broken
<mvo> juliank: the ftbfs in python-apt (in debian) should also be fixed in bzr, if you have a amd64 chroot availalbe it would be nice if you could do a test-build to be sure
<mvo> juliank: aha, ok
<mvo> james_w: if you have a moment, it would be great if you could sync bug #604577
<ubottu> Launchpad bug 604577 in sessioninstaller (Ubuntu) "Sync sessioninstaller 0.20-1 (universe) from Debian unstable (main)" [Medium,Confirmed] https://launchpad.net/bugs/604577
<juliank> mvo: Seems you forgot the status file: http://paste.debian.net/80258/
<ogra> seb128, there is something wrong with your libgtop2 sync
<seb128> ogra: iz pitti sync
<mvo> juliank: *cough* sorry. fixing
<seb128> ogra: what is wrong with it?
<juliank> mvo: Moving the data for the test into data/test_debs would also be a good idea
<ogra> seb128, whoops, mixed maintainer with changed-by
<ogra> seb128, seems it doesnt build the -common package at all
<seb128> they dropped it?
<ogra> oh, wait, it built it on x86 but it doesnt get synced to the ports archive
<seb128> ogra: it should be built on i386
<ogra> (indeed its arch all)
<seb128> ogra: ok, now it makes some sense ;-)
<ogra> http://ports.ubuntu.com/ubuntu-ports/pool/main/libg/libgtop2/ has the armel binary but not the arch all one
<ogra> s/one/ones
<ogra> -dev is missing as well
<ogra> seb128, could it be hanging in NEW ?
<seb128> ogra: yes, it's in binNEW
<ogra> ha, great, so i'm not brian-molten yet :)
<ogra> *brain even
<mvo> juliank: please update to r432, should be better now
<juliank> mvo: I still get AssertionError: Unexpected result for package 'gdebi-test3.deb' (got False wanted True)
<juliank> mvo: Because it tests against the system (amd64) cache which contains no i386 packages.
<juliank> mvo: Removing apt_pkg.config.set("APT::Architecture","i386") fixes it
<mvo> juliank: hm, odd, it should use the fixture status file that is pre-populated with i386 packges with the right dependencies (well, no dependencies :)
<juliank> mvo: OK, I missed that.
<juliank> mvo: You probably need an apt_pkg.init_system() after setting the status file.
<juliank> As the system stores the location internally during init().
<mvo> juliank: for me (with the current code) print len(self.cache)  print "3" (that is the amount of fixture data I put in)
<juliank> mvo: Running test_debfile directly gives me http://paste.debian.net/80260/
<mvo> juliank: thanks, let me improve the test failure output a bit
<james_w> mvo: the new version isn't visible on the mirror used by cocoplum yet, so I can't sync yet
<juliank> james_w: Yes, it's at http://incoming.debian.org/sessioninstaller_0.20-1.dsc until dak ran.
<smoser> zul, ping
<zul> smoser: yo
<smoser> i think free was expecting you were going to push on https://bugs.launchpad.net/landscape-client/+bug/594594 a bit.
<ubottu> Launchpad bug 594594 in landscape-client (Ubuntu Karmic) "Update jaunty, karmic, lucid and maverick to landscape-client 1.5.2" [Undecided,New]
<zul> smoser: yeah its waiting to be accepted
<zul> cjwatson: ^^^
<smoser> its waiting on https://bugs.launchpad.net/landscape-client/+bug/597000
<ubottu> Launchpad bug 597000 in landscape-client (Ubuntu Karmic) "get_active_interfaces reports duplicated interfaces" [High,New]
<smoser> (see last comment in that bug)
<smoser> cjwatson, you can ignore zul's ping above
<mvo> juliank: what do you get from r433? anything more useful? I added the error message in the assert failure output
<james_w> mvo, juliank: done
 * mvo hugs james_w
<juliank> mvo: Adds Dependency is not satisfiable: pkg-that-does-not-exists|apt when run via test_all
<hallyn> hm, daily maverick installer cd doe snot have an 'ok' button in the 'Where are you' panel, so i can't get past choosing a time zone :)
<juliank> mvo: My system is a bit broken
<mvo> juliank: thanks, let me add a check for this as well, its rather silly that it break in test3 in a case like this :)
<juliank> mvo: I had old code in my build/ directory which was used.
<mvo> juliank: aha, ok. many thanks for this info. is it working when that is fixed?
<juliank> mvo: http://paste.debian.net/80261/ fixes it
<juliank> The init_system() is needed everytime Dir::State::status changes, because the system copies the value of Dir::State::status
<mvo> juliank: great, thanks. if it works now, I upload a new version
<juliank> mvo: test works, but sphinx is causing the build to fail currently.
<juliank> (for me)
<juliank> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559572
<ubottu> Debian bug 559572 in python-sphinx "python-sphinx: doesn't remove python-central leftovers" [Serious,Open]
<juliank> might be it
<juliank> or not
<ScottK> LucidFox: (I didn't see where your odd licensing question got answered): It's probably undistributable due to conflicting licensing terms.
<juliank> mvo: http://bugs.debian.org/588807
<LucidFox_> So...
<LucidFox_> Are the CSD/RGBA patches going to be re-enabled later in the Maverick cycle?
<seb128> yes
<seb128> rgba at least
<seb128> csd likely not
<LucidFox_> so windicators(R) are going to be pushed until maverick+1?
<seb128> dunno
<seb128> they could be made in the decorator as well
<seb128> they will need in any case since not every software is gtk
<dholbach> slangasek, seb128, apachelogger: all set? :)
<apachelogger> dholbach: aye
<seb128> dholbach, yes
 * dholbach still needs to prepare :-P
<ScottK> pitti: Would you please rescore kdebindings (just affects ia64)?
<LucidFox> Is Maverick going to include GTK3?
<vish> LucidFox: nope
<LucidFox> hmmm
<LucidFox> so which GNOME version is it going to ship with?
<vish> LucidFox: as far as the desktop pacakges , the team is assessing each package and updating/backporting as required.. so it depends
<vish> the desktop team*
<arand> Mostly not 3.0 afaik. Migration is supposed to happen in two releases, likely conservatively..
<zul> is it possible to use locakfile-create with upstart/
<smoser> I need archive admin help. need to get 'grub-legacy-ec2' approved here : https://launchpad.net/ubuntu/maverick/+queue?queue_state=0&queue_text=cloud-init
<mdeslaur> pitti: do you know what happened to the jaunty packages on http://ddebs.ubuntu.com/dists/?
<lool> ev: Hey
<lool> ev: LP #603299 is the perl FTBFS assigned to you
<ubottu> Launchpad bug 603299 in perl (Ubuntu Maverick) "[amd64] perl FTBFS in maverick" [High,Confirmed] https://launchpad.net/bugs/603299
<lool> ev: I just uploaded perl earlier today with a fix for the Linaro issue (unrelated I think), and it built
<lool> ev: Did you reproduce yourself?  Shall we close for now?
<lool> Hmm thinking about it, I wonder whether it could be under PPA buildds
<lool> ev: ^
<lool> the virtual kernel behaving differently from the Ubuntu one or so
<ev> lool: I've been unable to reproduce it
<ev> I think we should close it
<lool> ev: Agreed; let's close it for now, and if someone reproduces, we shall ask more about the environment
<ev> done, thanks!
<lool> ah done too
<lool> I had marked it incomplete, but will move back to fix released
<ev> okay
<lool> done
<ev> cool, thanks
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 12 minutes in #ubuntu-classroom
<LucidFox> Okay, just updated to Maverick, went better than I expected in general
<LucidFox> something's wrong with GTK, though, theme rendering is screwed up
<LucidFox> let me try disabling RGBA...
<LucidFox> from the custom PPA
 * apachelogger giggles
<apachelogger> JontheEchidna: btw, I need a fanclub for widgetcrafting
<pitti> ScottK: it's currently building
<pitti> mdeslaur: jaunty was cleaned up the other day, I think
<ScottK> pitti: I thought you had rescored it once I saw that.  Thanks for checking.
<mdeslaur> pitti: ah, I see. was just wondering...
<scar_> hi, what's the chances that mavrick daily wil work if alpha 2 didn't want to boot im my pc?
<scar_> I've tried lucid with kernel-ppa just downloaded 2.6.35-2-generic-pae and 2.6.35-7-generic-pae, not one of them boots
<scar_> not even in recovery mode
<smoser> i see a 'quilt-setup' entry in debian/rules of openssh package.  This is needed to set up the .pc directory of quilt to convince it that all patches have already been applied.
<smoser> this seems to be infrastructure needed by all quilt 3.0 format packages.  is there anything that is being done to make it common ?
<cjwatson> smoser: 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]
<smoser> cjwatson, thanks
<geser> Could a core-dev please give-back: libxerces2-java. The problem got resolved today so it builds again. Thanks
<pitti> geser: doing
<tkamppeter> pitti, hi
<smoser> ok. so i'm looking at bug 43574. which says xinetd should be an upstart job.  what upgrade cases do i need to handle ? If i add xinetd.upstart and it gets pulled in, do I need to attempt to read the previous defaults/xinetd.conf?
<ubottu> Launchpad bug 43574 in xinetd (Ubuntu) "Needs Ubuntu-style init script" [Wishlist,Triaged] https://launchpad.net/bugs/43574
<smoser> per upstart design, the upstart doc, should not read /etc/defaults/xinetd.conf .  but if i ignore it, and move the existing /etc/init.d/xinetd to an upstart job, then  the xinetd server may then start with different options for a user who had modified xinetd.conf
<slangasek> smoser: while there's no policy that requires you to continue honoring /etc/default when converting from sysvrc to upstart, I consider it bad form to not do so in some fashion
<smoser> er... who had modified default/xinetd.conf
<slangasek> dholbach: yep, I'm ready :)
<smoser> slangasek, so what would you recommend ? i surely dont want to modify etc/init/xinetd.conf based on contents of /etc/defaults/xinetd .  should I just source it if it exists, generally honor the old behavior but not lay a new one down
<smoser> ?
<slangasek> smoser: source if it exists, but set sensible defaults within the upstart job itself; don't ship the defaults file in the new package; on upgrade, remove /etc/defaults/xinetd iff it's unmodified, using the standard conffile runes for this
<smoser> slangasek, thanks.
<smoser> and i think dh_installinit does most of that.
<slangasek> it doesn't help you with any of that, AFAIK :)
<slangasek> oh, and the standard runes for obsolete conffiles move the file aside if it's modified, so you have to take care not to do that
<LucidFox> gah... I've been reading news about Pinta 0.4, and all the vitriol-laden comments about how Mono is the work of the Devil really irritate me
<LucidFox> some users don't give the program a try just because it's Mono-based
<zul> can someone from the foundations team review ntpd upstart conversion for me? https://bugs.edge.launchpad.net/ubuntu/+source/ntp/+bug/604717
<ubottu> Launchpad bug 604717 in ntp (Ubuntu) "Please convert init script to upstart" [Undecided,New]
<ryan22> LucidFox: the best thing the mono team could do is reboot pinata on vala
<ryan22> mono isnt that bad, but there is no real reason for a runtime when you can can compile into c
<ryan22> though, the monodevelop guys do need to get around implementing things like supporting breakpoints in the external console and input in the internal console
<ryan22> ive got my compu sci dept pretty much sold on dual-booting with a thin-client based version of ubuntu, but i can't even think going any furthur until they implement those features ;)
<porthose> jono ping see pm
<joaopinto> ryan22, right, like if C was the best language for every purpose :)
<ryan22> it is damn fast
<ryan22> and bashee takes 5 -10 sec to load
<ryan22> though i do love it anyways :)
<joaopinto> ryan22, not from a development perspective for certain type of apps
<ryan22> nah. well im certianly not pushing it for my uni
<ryan22> but it does make more sense for desktop apps
<ryan22> and desktop search engines *cough* beagle *cough*
<porthose> Jono_ ping please see off topic pm
<jono_> porthose, on the phone, won't be long
<porthose> jono_ k
<ryan22> joaopinto: perfection is paralysis. linux has tried to be perfect for too long ;)
<ryan22> it just needs to *work*
<smoser> in "upstarting" a daemon, should i basically ditch the pidfile ?
<smoser> and instead just rely on upstart to track it.
<slangasek> smoser: upstart doesn't care about pidfiles; I wouldn't include anything in the upstart job to specifically create / manage one
<slangasek> smoser: perhaps you want to come to the 'authoring upstart jobs' session at 2000 UTC? :) https://wiki.ubuntu.com/UbuntuDeveloperWeek
<smoser> indeed i would
<smoser> slangasek, well, the reason i asked aobut pidfiles is that xinetd kills with sigquit, not sigkill in the existing init.d script.
<smoser> so i thought i'd kill similarly in pre-stop
<smoser> but needed to determine pid
<slangasek> kills what?
<slangasek> you should definitely not be killing the xinetd process in pre-stop
<smoser> hm... ok.
<smoser> kills the xinetd daemon
<slangasek> yeah, don't do that.
<smoser> i thought of doing that per man page:
<smoser> pre-stop ...
<smoser> It is typically used to send any necessary shutdown commands to the main process...
<slangasek> smoser: upstart sends sigterm, waits, then sends sigkill.  As long as xinetd handles TERM sensibly, you don't need any other special handling
<tkamppeter> pitti, hi
<smoser> hm... so with xinetd , as i'm reading its man page, sigquit quits the daemon. sigterm takes all running servers, then quits
<smoser> so if i can't deliver a sigquit, i'll be changing behavior. and a stop to inetd would kill all its sub-servers.
<slangasek> well, you /can/ send -QUIT in pre-stop.  I'm not sure which behavior should be considered correct
<slangasek> or what happens if xinetd receives the -TERM while the -QUIT handler is still running
<smoser> how would i send -quit ? with kill ?
<slangasek> yes
<smoser> right. its going to be busted anyway
<slangasek> busted?
<smoser> busted as in different behavior than before
<smoser> as i undertsand it, if you were using the /etc/init.d script, and someone had started a long running ftp download that was initiated via xinetd
<smoser> and you did /etc/init.d/xinetd stop
<smoser> the ftp download would continue
<slangasek> correct
<smoser> but with upstart if the TERM is sent, it will be gone
<slangasek> yes
<smoser> and we can't think of a way to keep the old behavior
<slangasek> yes we can
<smoser> ok, then i missed something
<slangasek> 11:41 < slangasek> well, you /can/ send -QUIT in pre-stop.  I'm not sure which behavior should be considered correct
<slangasek> if that's the behavior you want, that's the way to do it
<smoser> well right. but then the sigterm is going to come through after pre-stop exits
<smoser> so i must be missing how you're suggesting to send -QUIT
<slangasek> no, I'm suggesting that you should make sure xinetd's signal handlers are correct
<smoser> yeah, i am confused.
<smoser> sorry for killing your imte on this.
<smoser> i dont necissarily care what is "correct"
<smoser> more concerned with what is consistent
<smoser> and consistent is sending a single SIGQUIT
<slangasek> you don't have that choice
<slangasek> you need to make sure xinetd's signal handlers are correct instead
<slangasek> and that a -TERM after -QUIT won't cause the subprocesses to be killed
<slangasek> anyway, here's the script you want:
<slangasek> pre-stop script
<slangasek> kill -QUIT $(status | awk 'stop\/pre-stop/ { print $NF }')
<slangasek> end script
<smoser> well, yes. which is what i was initially going to try, but my guesss is that sigterm is going to come right after that and xinetd will then take out all the servers.
<smoser> and i somewhat would consider it incorrect if it didn't do that
<smoser> but oh wel.
<smoser> thanks for your time sla
<smoser> slangasek,
<slangasek> why would that be incorrect?
<slangasek> if the process has already been told to exit without killing servers, why should a later signal telling it to kill the servers override that?
<smoser> same question can be asked in reverse.  if a process has been told to quit and kill the servers, why would it not do so?
<smoser> but i'll look
<slangasek> because it was already told to exit without killing the servers, and shouldn't have been around to receive that signal at all except that there's a race condition! :)
<smoser> well thats a very good point
<smoser> :)
<smoser> thanks again
<slangasek> sure :)
<johnc4510> jcastro: ping
<johnc4510> amber graner said you might help me with the beta fonts problem i have
<johnc4510> Failed to fetch http://ppa.launchpad.net/ubuntu-font-beta-testing/ppa/ubuntu/dists/lucid/main/binary-i386/Packages.gz  404  Not Found
<jcastro> yep, one sec
<johnc4510> thx
<jcastro> johnc4510: you need the sources.list information from here: https://launchpad.net/people/+me/+archivesubscriptions (click on the view link)
<jcastro> johnc4510: it will be something like "deb https://yourusername:(randomstuff)@private-ppa-blah blah"
<johnc4510> jcastro: i added those two links to my sources.list via nano
<johnc4510> i reset my password too thinking it might need that
<johnc4510> but that was over an hour ago and still no luck
<johnc4510> lol
<jcastro> launchpad will regen you a password
<jcastro> but it's not your launchpad password btw
<johnc4510> sure
<jcastro> may I pm you?
<johnc4510> it's just for the ppa's as i understand it
<johnc4510> sure
<bigon> mmm it seems that tracker has been demoted to universe, but brasero still build-dep on it
<bigon> didrocks: ^ as you made the last upload
<tkamppeter> pitti, still there?
<squarebracket> is there a reason the wacom.ko kernel module wasn't in the -23 release?
<smoser> slangasek, around ?
<smoser> i read some of your session, will read more later. it looked very informative.
<smoser> i was playing with the 'kill -QUIT $(awk '/stop\/pre-stop/ { print $NF })' in a pre-stop script.
<smoser> that seems to end up in a losing battle withi 'respawn' keyword in place.
<smoser> even though, as far as I can tell 'kill -QUIT <pid>' will cause xinetd to exit 0.
<Nevon> Hey guys. I seem to be having a bit of problems with DesktopCouch. I'm pulling my hair out trying to read some values from a record I have created.
<Nevon> Does anyone here have experience with DesktopCouch?
<smoser> by losing battle i mean that it gets restarted on 'stop xinetd'
<resmo> hi
<bigon> is there any particular rules on virt-viewer sync?
<slangasek> smoser: oh, heh - then perhaps it needs to not be respawn?
<bigon> because version is Ã¼ber old and doesn't appears in merge.u.com
<bdrung> bigon: probably a merge is required (because there are changes made in ubuntu).
<tumbleweed> bdrung/main sponsor: I reviewed Bug #603681 by mistake, looks good to go
<ubottu> Launchpad bug 603681 in virtinst (Ubuntu) "Please merge virtinst (0.500.3-2) main from debian unstable" [Wishlist,Confirmed] https://launchpad.net/bugs/603681
<ari-tczew> slangasek: have you got 5 minutes for sponsoring?
<bigon> I will do the merge of virt-viewer then (still wondering why it's not in the merges web page)
<slangasek> ari-tczew: what's up?
<ari-tczew> slangasek: bug 604795
<ubottu> Launchpad bug 604795 in slang2 (Ubuntu) "Merge slang2 2.2.2-4 (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/604795
<slangasek> ari-tczew: ok; will take me a bit to grab the branches, but I'll look at it, yes
<ari-tczew> slangasek: thanks
<smoser> slangasek, but i want it to be respawn.
<smoser> for the reasons that you'd have 'respawn'
<slangasek> smoser: sure; but I'm afraid I don't know any way to reconcile those two requirements
<smoser> i tihnk its a bug in upstart that a 'exit 0'  ends up causing a respawn.
<BlackZ> slangasek: could you look at bug #554823 ?
<ubottu> Launchpad bug 554823 in logrotate (Ubuntu) "Please merge logrotate 3.7.8-6 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/554823
<slangasek> smoser: maybe
<smoser> oh. maybe not.
<smoser> "Tasks may exit with a zero exit status  to  prevent  being respawned"
<smoser> i read that as "daemons"
<smoser> don't know if that was intended or if it truely was limited to 'tasks'
<slangasek> smoser: I don't either - you could file a bug against upstart and see what Keybuk thinks
<slangasek> BlackZ: hmm, I can't promise that I'll get to it today - you might ask on #ubuntu-motu generally?
<smoser> yeah. thanks for your input,sl
<BlackZ> slangasek: it's in main, I think it's offtopic there ;)
<slangasek> BlackZ: well, I don't think it's offtopic there, I think we agreed several cycles ago that #ubuntu-motu is a bad name for the channel :)
<bdrung> tumbleweed: uploaded
<BlackZ> slangasek: but MOTUs can't upload to the 'main' component
<bdrung> BlackZ: MOTUs, which are core-devs, can upload to main :P
<BlackZ> bdrung: right but not all MOTUs are core-devs
<bdrung> just kidding.
<BlackZ> yeah :p
<tumbleweed> bdrung: thanks
<bdrung> yw
<BlackZ> bdrung: BTW, if you have some time could you look at it?
<bdrung> BlackZ: i doubt that i have time today. you could ping me tomorrow.
<BlackZ> bdrung: sure, thanks
<Laney> is it urgent? or is the sponsor queue somehow not working?
<bdrung> BlackZ: i can offer a free sponsorship if you find the reason for this FTBFS:  https://launchpad.net/~eclipse-team/+archive/debian-package/+build/1865773
<BlackZ> Laney: no, it's not urgent and the sponsor queue is working perfectly
<bdrung> Laney: the sponsor queue lacks man power as usual
<Laney> ok, I just get concerned when I see people pinging sponsors directly
<BlackZ> bdrung: I'm not very good with java stuff but I could have a look
<bdrung> BlackZ: i have to warn you, it won't be easy
<ari-tczew> notice from me: I'm not impatient. just my merge has latest upload by slangasek and I want to got sponsorship by slangasek, so I think that ask slangasek for sponsoring my patch is accurate.
<Laney> I don't think it's a problem if a package is regularly touched by a person
<Laney> as they are likely to be interested in it
<ari-tczew> Laney: I don't understand?
<Laney> which part?
<ari-tczew> [23:39] <Laney> I don't think it's a problem if a package is regularly touched by a person
<ari-tczew> what do you mean? that I shouldn't touch a package?
<Laney> no
<Laney> that asking isn't a problem in that situation
<ari-tczew> ah
<ari-tczew> okay, got it
<slangasek> ari-tczew: this branch doesn't appear to have used bzr merge-package?
<slangasek> ari-tczew: so it doesn't show up as an actual merge of the Debian package changes
<ari-tczew> slangasek: I don't like to use this method. In bug you'll see diff ubuntu-to-ubuntu.
<slangasek> ari-tczew: if you're going to provide a branch, it should be a branch that can be merged without losing information
<ari-tczew> slangasek: which informations are be losing?
<slangasek> ari-tczew: the bzr revision history for the Debian uploads
<ari-tczew> slangasek: should do I merge with this branch? https://code.launchpad.net/~ubuntu-branches/debian/squeeze/slang2/squeeze
<ari-tczew> then we should see a diff debian-to-ubuntu
<ari-tczew> ?
<slangasek> ari-tczew: following https://wiki.ubuntu.com/DistributedDevelopment/Documentation/Merging gives a branch that is the result of merging the Debian branch into the Ubuntu branch, with full bzr history, and can be diffed against both the Debian and Ubuntu branches as needed
 * tumbleweed hates UDD (bzr) for merging new versions from Debian. It requires a lot of work to see exactly what's going on
<ari-tczew> slangasek: in this case I think that my method is enough. what's the decission?
<slangasek> ari-tczew: I will not commit a merge that discards bzr history
 * micahg should try UDD again for my next merge
<slangasek> if you're not following the UDD merge process, it doesn't make sense why you would push a branch at all instead of just providing a debdiff?
<maco> how do you get on the list of people who get merge proposal emails anyway?
<slangasek> ari-tczew: I've re-done the merge locally with your changelog entry now and will commit that
<ari-tczew> debdiff in bzr is like a new patch viewer
<ari-tczew> slangasek: and without my key signed?
<slangasek> key signed?
<tumbleweed> micahg: I scripted most of a udd-grab-merge (not that it's hard). But kept running into udd branches that were out of date
<slangasek> maco: hmm, I guess that's answered somewhere in the ubuntu-devel thread james_w drove?
<ari-tczew> slangasek:  -- name surname  <e-mail@adress> date -R
<slangasek> ari-tczew: that's included in the changelog entry I used
<ari-tczew> aha
<micahg> tumbleweed: need help finishing it?
<micahg> tumbleweed: s/need/want
<tumbleweed> micahg: this is what I was using: http://paste.ubuntu.com/462711/
<tumbleweed> (i.e. not much)
<tumbleweed> the big issue I'be been seeing recently is 3.0 (quilt) interacting badly with bzr. People can't see that their merge will generate an auto-quilt-patch
<micahg> tumbleweed: maybe file a bug against the udd project
<tumbleweed> micahg: it's not udd's fault. rather, something that's hard to see unless you test building a source package
<ari-tczew> going to asleep, bye
<micahg> tumbleweed: maybe it could get documented at least so people are aware
<Laney> how is that a problem of udd/bzr?
<tumbleweed> micahg: yeah. Oh, re the outdated udd branch problem, I guess the best solution is to run rmadison in udd-grab-merges and throw an error if a branch is out of date
<tumbleweed> Laney: it's not a problem with udd/bzr, but with a workflow that doesn't involve generating source packages that get read / diffed
<tumbleweed> they'd be obvious if the merge was in debdiff format (although even then people miss them)
<Laney> isn't there a lintian warning for this?
<tumbleweed> Ubuntu mergers read lintian output? :)
<Laney> I would expect uploaders to
<Laney> anyway it was an actual question: I don't know if there is one
<tumbleweed> Laney: doesn't appear to be
<Laney> it's along the lines of the patch system but changes in diffgz one
<Laney> 3.0-quilt-but-debian-changes
<tumbleweed> I find it a big misfeature in 3.0 (quilt) I'd prefer an error to an auto-generated patch. But I can understand why it's like that :/
<Laney> it matches the historical behaviour of dpkg-source
<tumbleweed> yup. What's really fun is when it generates an anti-patch, reversing one of the quilt patches
<Laney> tumbleweed: just reported debian #588873
<ubottu> Debian bug 588873 in lintian "lintian: [new check] Warn if using 3.0 (quilt) and there is a debian-changes-xxx patch" [Wishlist,Open] http://bugs.debian.org/588873
<tumbleweed> Laney: thanks. we are starting to see quite a few packages coming from Debian with them, too
#ubuntu-devel 2010-07-13
<slangasek> lamont: hmm, remind me why 'inet protocols = ipv4' is still the default in postfix? :)
<lamont> because
<lamont> any bug from lintian telling me that I'm not using quilt will cause me to go back to version 1.0 packaging
<slangasek> huh?
<lamont> sorry.  just reacting to ubotu
<slangasek> ah
<lamont> but then, hey, that's what lintian overrides are all about, right?
<cjwatson> honestly?  I think if you aren't actually making use of quilt, then for the most part it makes more sense to use 1.0 packaging; otherwise you're basically just doing 1.0 transliterated into 3.0 (quilt) and it doesn't really help all that much
<slangasek> unless you want to use it for the bz2 support
<slangasek> or the binary diff support
<slangasek> :)
<cjwatson> the exception is if you want to have binary files in the Debian delta, in which case a 3.0 format is useful
<lamont> cjwatson: well, I got this really nicely worded bug asking me to switch to 3.0(quilt)
<cjwatson> or that
<lamont> which I promptly tagged wontfix, and then reconsidered
<lamont> I have a vcs.  I don't need another vcs in the source package
<cjwatson> I find them to be usefully complementary, but I guess I can't really be bothered to get into a religious debate. :-)
<cjwatson> but briefly, the quilt approach lets me store evolving information about a logical patch (which may change over time) without having to rebase my history to death and render it incomprehensible
<lamont> I like to have my source where I can bisect it, and do other useful diff-like things, without needing to delve through patch files to notice things
<cjwatson> uh
<lamont> but yeah, it's at least largely religious.  as long as you don't modify an older patch which patches files that are in later patches (that'd be a rebase of the parent branch, and that's just evil)
<cjwatson> so do I, and 3.0 (quilt) is the first patch-system format to give me that property
<cjwatson> because I store the package with patches applied
<lamont> that does have some potential
<slangasek> lamont: so ipv4-only is just a 'because'?
<lamont> I do admit that I interpreted "quilt" as that old piece of crap that implements about 1/2 of a 1980s VCS and (correctly) claims to be better than dpatch as its only selling point
<lamont> slangasek: ipv6 is real.  people are using it.  I got tired of the complaints.
<slangasek> that setting is going to cause an increasing amount of grief over the next couple of years :)
<slangasek> whu?
<slangasek> yes, ipv6 is real, and I am using it, which is why I'm asking about the default to *not* allow it in postfix
<lamont> or are you saying ipv4-only is the current default?
<slangasek> yes
<lamont> oh, that's total crack
<lamont> I should fix that
<slangasek> which caused me to accidentally drop mail from Patty's laptop on the floor over the weekend when I reorganized the ipv4 network, oops
<lamont> meh.  actually, ipv4-only is an upstream default.  I guess I get to poke wieste about it
<slangasek> because I thought nothing cared about the ipv4 IP of that server anymore :)
<cjwatson> quilt is certainly not exactly a brilliant vcs - I don't really think of it in that category
<lamont> and lack of testing caused you marital grief?  ouch
<slangasek> no, she's on percocet this week for wisdom tooth post-op
<slangasek> so she's happy - I'm the one unhappy about unreliable mail ;)
<lamont> cjwatson: the use model of dpatch that evolved into quilt was 100% around what basically amounts to a VCS.  and then I had a task of importing quilt/dpatch patches into SVN, and we discovered the pain that is gratuitous rebases
<lamont> slangasek: when she's done being high, that's when you're in trouble... :-p
<cjwatson> it's a patch queue, which is not quite the same as a VCS
<lamont> cjwatson: except in how people used it
<cjwatson> in particular it makes no pretence of being able to retrieve older versions of things (assuming you don't regard patches as static)
<lamont> but yeah, it led to a kneejerk reaction to any sentence involving "patch system" or "quilt"
<cjwatson> http://www.chiark.greenend.org.uk/ucgi/~cjwatson/blosxom/debian/2010-03-25-thoughts-on-3.0-quilt-format.html is a summary of my initial experiences
<cjwatson> as a historic patch-system-hater
<lamont> ah, added point: my pain was from the debian kernel package, which _did_ endeavor to do exactly that...every past verison of the package was recoverable from the current version
 * slangasek is reminded again that he needs to work on getting the patch delta down so he can move pam to 3.0 (quilt)
<lamont> at least in the then-time
<slangasek> well, that's a special case
<slangasek> :)
<lamont> slangasek: special in the committed sense
<slangasek> "you need to be GPL compliant and you're doing *what*?!"
<cjwatson> (also, the most common complaint about quilt is answered by 'quilt shell'
<cjwatson> )
 * ScottK is sure he'll get over it eventually, but unpacking with patches applied does not work at all well with his mental model of a package.
<cjwatson> unpacking with patches unapplied was the reason I was a conscientious objector to patch systems. ;-)
<cjwatson> I feel very strongly that users should not have to run funny commands (and run untrusted code from a package they just downloaded, often!) in order to see what code is going to be compiled
<flupke> hello, what is the trick in ubuntu's alsa that makes flashplugin use pulse ? I'd like to keep this functionnality with the latest alsa drivers
<TheMuso> flupke: As long as you don't remove/modify any files in /usr/share/alsa then it will continue to work./
<flupke> TheMuso, thanks for the info, alsa-lib sources do write files in /usr/share/alsa, I'll try to keep the ubuntu package that owns these files
<TheMuso> flupke: Ok. The files in hte Ubuntu package have been modifed to load an extra file which checks to see if pulse is running. If pulse is running, then the default device is created that redirects alsa apps to pulse.
<flupke> TheMuso, works like a charm by just keeping /usr/share/alsa/alsa.conf, thanks a lot
<TheMuso> np
<pitti> Good morning
<pitti> tkamppeter: hello
<pitti> tkamppeter: I'm on an early shift this week
<ion> Morning
<pitti> tkamppeter: nice work on the fingerprint additions to the printing DB!
<pitti> hey ion
<LucidFox> If I'm making an -Xubuntu1 upload, but not going to include any of the previous Ubuntu changes, do I need to include previous Ubuntu debian/changelog entries, or can I leave in just the Debian changes?
<micahg> LucidFox: is it currently -XubuntuY?
<LucidFox> yes - to be more precise, it's pinta 0.3-2ubuntu1, and I'm going to upload 0.4+dfsg-1ubuntu1, which is -1 with a new patch, and the old Ubuntu changes merged upstream and dropped
<micahg> LucidFox: so why does it need an ubuntu1 upload?
<LucidFox> Because the Debian version is broken on Maverick as is
<LucidFox> needs a patch for cairo 1.9.x
<LucidFox> (for that matter, the current version in Maverick is broken too, but it wasn't discovered before Debian packaged a new release)
<micahg> LucidFox: ah, ok, so I would think it won't hurt to keep the changelog since we're keeping an Ubuntu change
<LucidFox> micahg> But we aren't keeping the existing Ubuntu changes, only introducing a new one
<LucidFox> The Ubuntu changes in -2ubuntu1 were merged upstream.
<micahg> LucidFox: right, but as long as we're carrying any changes, why not keep the history in the changelog?
<TheMuso> c
<didrocks> bigon: re:brasero-tracker. on it, thanks
<dholbach> good morning
<pitti> hey dholbach, good morning
<dholbach> hey pitti
<baptistemm> hi there
<baptistemm> StevenK, around ? I would you to renew my membership to bluetooth group
<bilalakhtar> Can someone please get https://edge.launchpad.net/ubuntu/+source/krename/4.0.4-2ubuntu1/+build/1864396 rebuilt?
<bilalakhtar> Can someone please get https://edge.launchpad.net/ubuntu/+source/krename/4.0.4-2ubuntu1/+build/1864396 rebuilt?
<micahg> bilalakhtar: you should ask in -motu
<pitti> bilalakhtar: done
<micahg> or maybe not :)
<bilalakhtar> pitti: thanx again, apporty!
<pitti> lol
<pitti> that's the first time someone calls me that
<bilalakhtar> .query pitti
<bilalakhtar> sorry
<tkamppeter> pitti, hi
<tkamppeter> pitti, thanks for uploadfing the Epson key, seems that the Epson guys are firewalled out of the public key server network.
<pitti> tkamppeter: good morning
<tkamppeter> pitti, now the OpenPrinting web server is ready for automatic download, and it is your turn to fix/update Jockey, once to let Jockey only search and download the printer driver when a printer is detected and second, the signature support.
<pitti> I saw the bug, thanks
<bilalakhtar> pitti: it appears that the armel build failed again. What could be the direct solution? Package builds fine in other architectures.
<tkamppeter> pitti, early shift? Does Canonical establish a 24/7 developer presence now?
<pitti> tkamppeter: heh, no; I just have to get up at 6 this week, so I can just as well start early
<pitti> tkamppeter: but given how we are distributed around the planet we have that round-the-clock coverage anyway
<apw> i have a recently upgraded maverick system in which the cursor is being turned off after approx 1s everywhere on the screen ... like it used to do inside an gnome-terminal only
<cjwatson> ditto
<apw> i also think its causing a flickering cursor over gnome-terminal and menu items after approx 1s of stationaryness
<pitti> this is from the unclutter package, I think
<pitti> it was added right before alpha-2
<apw> pitti, hrm ... any idea if it has any configuration?
<pitti> no, I never used it so far; I'm still on lucid
<apw> as it seems to be turned on without my permission
 * pitti redirects complaints seb128wards
<cjwatson> for me it mostly causes a problem in evince, where it spikes CPU activity
<cjwatson> which is bug 385034 I guess
<ubottu> Launchpad bug 385034 in unclutter (Ubuntu) "unclutter: cursor flashes repeatedly over GTK apps., takes 100% CPU" [Undecided,Confirmed] https://launchpad.net/bugs/385034
<pitti> hm, I'm on lucid, no unclutter, and the mouse cursor still disappears in gnome-terminal after some seconds
<pitti> (which is good IMHO)
<apw> cjwatson, confirmed ... killall unclutter sorts out the issue
<pitti> but I'm not sure where I configured this
<pitti> or _if_ I did
<apw> right ... thats a default i think, but configurable.  unclutter is busted poo which is halving my battery life ... grrr
<pitti> ah, it disappears as soon as I start typing in a terminal
<pitti> apw: it might just have been an experiment; I think there were more complaints
 * pitti summons seb128
<cjwatson> adding -noevents to /etc/default/unclutter gets rid of the flicker
<cjwatson> (EXTRA_OPTS)
<apw> cjwatson, eah i see that mentioned in the bug ... hrm
<apw> i want to know how to configure it, as turnign off my mouse cursor everywhere is new behaviour i may not want
<cjwatson> man unclutter
<apw> cjwatson, current install is utter garbage ... joy
<apw> plymouth is triggering a kernel panic
<cjwatson> apw: on mode switch?
<cjwatson> or on something else?
<apw> cjwatson, looks to be closing something, the framebuffer from the stack trace ... so perhaps when its quitting
<apw> removing splash sorts it out
<cjwatson> but kernel bug rather than X bug?
<apw> cjwatson, yep kernel should never panic :)
<cjwatson> ... that's what I thought
<cjwatson> was it triggered by GRUB starting the kernel in graphics mode?
<apw> cjwatson, no this is a vanilla grub
<cjwatson> apw: https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/030995.html
<cjwatson> if it's 1.98+20100710-1ubuntu1, it may be starting in graphics mode by itself
<apw> ahh i see, i susepct the issue is not grubs fault though.  the panic is pretty severe, using this mutex the one at 0, bang
<pitti> seb128: good morning
<pitti> seb128: cjwatson and apw have some problems with unclutter
<seb128> like flickering and cpu use?
<apw> seb128, i would describe it as wholy broken :/
<apw> yep and eating my battery yes
<pitti> seb128: at least in gnome-terminalaand gedit the mouse cursor already disappears when typing; this is on lucid without unclutter; shouldn't this be enough?
<seb128> https://launchpad.net/bugs/16492
<ubottu> Launchpad bug 16492 in gtk+2.0 (Ubuntu Maverick) "Mouse pointer should disappear when keyboard is in use and mouse isn't" [High,Triaged]
<seb128> comment on this bug
<pitti> will do
<seb128> don't blame the messenger, I don't agree with the change but it was a sabdfl request
<seb128> basically
<apw> seb128, so is someone going to fix the fact it eats ones machine ?
<cjwatson> I don't particularly care about the change as such, FWIW
<cjwatson> it's only the implementation problems
<apw> even if we ignore the fact its a rather gratuitous change without a graphical ticky to turn it off
<seb128> apw, I guess we will either fix it or roll it out of the default installation
<seb128> depending of the ressources we have to fix issues
<seb128> but it's nice to have feedback and know about its issues to start
<apw> well its a very severe effect, it halves my battery life
<seb128> I can't confirm that
<pitti> seb128: subscribed and commented, thanks for the pointer
<apw> do you not see it on your maverick installs ?  which of course all your machines should be by now
<seb128> pitti, you can install it on lucid btw
<seb128> pitti, if you want to test
<pitti> sure, but I'm actually quite happy as it is now
<seb128> apw, no, my laptop and mini don't have that issue
<pitti> I could install it to test flicker/battery life, sure
<seb128> apw, they both are intel boxes though if that makes any difference
 * apw wonders how that can be
<apw> seb128, mini ?  mini 10v ?
<seb128> yes
<apw> seb128, on my mini10v i am seeing 500 wakeups per second with 100% occupancy of max MHZ, which all stops when i hit killall unclutter
<seb128> well to be fair I don't watch battery use
<seb128> and that box doesn't have a fan to tell you there is something eating cpu
<seb128> but I don't notice flickering
<apw> the flickering over gnome-terminal is impossible to miss.  i also see it on menu items after 1 sec
<seb128> how do you see the wakeups?
<apw> powertop
<apw> it appears as rescheduling interrupts
<seb128> well no flickering there
<apw> do yo uhave the degfault config for unclutter?  -noevents is slated to fix it
<cjwatson> seb128: I don't use gnome-terminal, but I noticed flickering in evince
<seb128> https://bugs.edge.launchpad.net/ubuntu/+source/unclutter/+bug/385034
<ubottu> Launchpad bug 385034 in unclutter (Ubuntu) "unclutter: cursor flashes repeatedly over GTK apps., takes 100% CPU" [Undecided,Confirmed]
<cjwatson> yes, I found that bug during this discussion today, see scrollback
<apw> yep thats sounds like the bug
<cjwatson> ah, I guess you joined after that
<seb128> right
<cjwatson> and that option does indeed work around that problem, as I also said in scrollback
<seb128> it doesn't happen to everybody for sure and I can't confirm it there
<seb128> but it might be trigger by some external factor or other running software
<apw> ok
<apw> so does one
<apw>  o
<apw> f
<apw> of the affected users need to fix it then?
<seb128> apw, I will try to debug a bit but could be something we can work on next week during the sprint
 * apw takes his test box off his keyboard :(
<apw> seb128, ok
<apw> cirtianly i can reproduce it at will with a gnome-terminal, as i can use that to run the two options and show the difference
<seb128> apw, did that start today?
<seb128> we have unclutter on since before alpha2
<seb128> I'm wondering if something triggered the issue for people who didn't have it before
<seb128> I've no upgraded yet today so maybe it will start being buggy as well after updates ;-)
<cjwatson> I noticed it a couple of days ago, I think
<apw> seb128, this machine was updated to maverick this morning, so all new to it
<DreadKnight> i get some lame internet laging in 10.10
<DreadKnight> it occurs often
<crankyadmin> Hey, does anybody have any idea when Ruby1.9 will become default in 10.04 LTS?
<dupondje> dholbach: https://bugs.launchpad.net/ubuntu/+source/pybootchartgui/+bug/596475 -> it does have the change from -3 ?!
<ubottu> Launchpad bug 596475 in pybootchartgui (Ubuntu) "Upgrade to upstream version r141" [Wishlist,New]
<dholbach> dupondje: http://launchpadlibrarian.net/50625726/pybootchartgui.debdiff
<dholbach> dupondje: not in the changelog - it does not apply
<dupondje> ah the changelog indeed :) tought the change in the code :)
<dupondje> wasn't clear :)
 * mvo stares at pyhon-support and wishes it would be less silly. why - oh why - does it try to byte-compile gnome-codec-install on python2.4
<geser> is there a reason that sync requests are processed slowly in the recent days?
<tumbleweed> geser: ack-sync them yourself?
<Laney> I've noticed this actually
<geser> tumbleweed: if it's expected now that we upload our syncs now oneself, I can do it, but isn't the syncpackage script is some "grey zone"? It works but the archive admins prefer not to see it used.
<BlackZ> bdrung: ping
<tumbleweed> geser: oh, I wasn't aware of that - I've been using it
<Kano> hi, when will http://packages.ubuntu.com/ work for maverick?
<geser> Kano: it's in the work, the hard part is to find someone who has access to it
<Kano> also when will libdrm 2.4.21 be in maverick? thats required for libva for intel
<Kano> you can update nouveau too then
<geser> Kano: if you don't get here an answer, try asking in #ubuntu-x
<dholbach> shadeslayer, dpm, Riddell, Laney: ready for later on?
<shadeslayer> dholbach: go go UDW :D
 * shadeslayer just started on notes
<Laney> somewhat!
<dholbach> :-)
<dholbach> awesome - I' m so looking forward to it
<dpm> dholbach, not yet, but I'll be! :-)
<shadeslayer> dholbach: you didnt ping Rhonda :P ... well.. shes not here anyways :P
<dholbach> and zyga neither :)
<shadeslayer> yeah :D
 * shadeslayer looks up super secret ninja links in kubuntu wiki
<dholbach> does anybody know where this comes from?
<dholbach>  E: Invalid Release file, no valid components
<dholbach>  E: debootstrap failed
<dholbach> it's with maverick's debootstrap (used by pbuilder)
<dholbach> mvo, cjwatson: ^ do you have an idea about my question above?
<ogra> dholbach, http proxy ?
<ogra> or any broken local archive
<dholbach> ara: ^ do you know which mirror it uses?
<ara> dholbach, I am using de.
 * ara changes to the main archive to see what happens
<ara> ah, no, I was using the main archive
<dholbach> hrm
<mvo> dholbach: seems to be working for me (tm)
<mvo> no idea what is going on
<mvo> dholbach: if its reproducable, have you tried with --verbose
<ara> it is me who is having the issue, I will try that
<ara> dholbach, sudo debootstrap --verbose --variant=buildd maverick /var/chroot/maverick
<ara>  worked just fine
<ara> it seems to be an issue in pbuilder
<micahg> can I please get an SRU ack for a Mozilla security upload? bug 563535
<ubottu> Launchpad bug 563535 in thunderbird (Ubuntu) "thunderbird -g fails due to invoking "$LIBDIR/$META_NAME" instead of "$LIBDIR/$META_NAME"-bin" [Medium,Triaged] https://launchpad.net/bugs/563535
<dholbach> ara: I hope you get a chance to work on your original problem now :-P
<ara> dholbach, hehehe, first I need to see if their is such a bug reported in pbuilder and, if not, report it ;-P
<jdstrand> micahg: fyi, I'm not on the ubuntu-sru team, but that bug is not formatted according to StableReleaseUpdates and therefore won't show up on their reports. perhaps I am missing something?
<micahg> jdstrand: no, I thought we just need an ack for the ones that go through -security?
 * micahg can format it
<jdstrand> micahg: I have no context here. there isn't a formal policy for putting SRU material through -security. we did it in the past as an exception
<jdstrand> micahg: if this is a regression caused by the recent tbird security update, we just fix it in -security
<micahg> jdstrand: no, this was a problem in 3.0 release version
 * jdstrand is still lost
<jdstrand> maybe I am dim
<jdstrand> micahg: this is an upstream bug?
<micahg> jdstrand: no, this is a bug in our wrapper script that I added for 3.0 in Lucid
<jdstrand> micahg: so that sounds like a regular SRU then. is there a pending upstream security update that you are just trying to fix along the way?
<micahg> jdstrand: yes, 3.0.6 next week
<jdstrand> micahg: I see. I would either format the bug so that it ends up on their radar or ask a member of the ubuntu-sru directly
<micahg> jdstrand: k
<dupondje> dholbach: https://bugs.launchpad.net/ubuntu/+source/pybootchartgui/+bug/596475 I attached new debdiff
<ubottu> Launchpad bug 596475 in pybootchartgui (Ubuntu) "Upgrade to upstream version r141" [Wishlist,New]
<dholbach> dupondje: I'll have a look tomorrow if nobody else beats me to it
<dupondje> fine :)
<bigon> the "new" version (v4) of dhcp client/server is in debian , will maverick have it? or are we still use the v3?
<cjwatson> I guess Caesar should advise on that
<ari-tczew> slangasek: thanks for sponsoring
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 2 starts in 24 minutes in #ubuntu-classroom
<doko> asac, fta: are there thunderbird-3.1 packages somewhere?
<asac> micahg: ^^
<fta> doko, there're use to be one in the mozilla-daily ppa, but it's staled. micahg will work on it
<fta> doko, i'm no longer an active mozilla maintainer btw
<doko> fta: ahh, ok
<dholbach> zyga: ready for later on? :)
<dholbach> Riddell: all set for later on?
<Riddell> dholbach: yes I am now
<dholbach> yeeehaw
<Riddell> dholbach: people should install qt4-qmlviewer, is there a place to advertise that?
<dholbach> Riddell: https://wiki.ubuntu.com/UbuntuDeveloperWeek/Sessions
<micahg> doko: I'll try to have TB3.1 in the PPA this weekend
<Caesar> bigon: there's some divergence between the Ubuntu and Debian versions of DHCP
<Caesar> pitti has patched it in the past
<Caesar> I'd love to see it in Maverick, but I personally dislike some of the patches that have been added in Ubuntu
<Riddell> slangasek: you blacklisted sabayon from syncs, could you comment on bug 598380 ?
<ubottu> Launchpad bug 598380 in sabayon (Ubuntu) "Sync sabayon 2.30.0-1 (main) from Debian unstable (main)" [Wishlist,Triaged] https://launchpad.net/bugs/598380
<joaomello_> Hi guys, i want to help developing ubuntu, i know python and a little C language, where should i start?
<arand> joaomello_: The currently ongoing ubuntu developer week might be of interest? https://wiki.ubuntu.com/UbuntuDeveloperWeek
<joaomello_> thanks for the link
<slangasek> Riddell: IIRC, sabayon was blacklisted because it had been removed from Debian, no?
<Riddell> slangasek: that's what the comment says
<slangasek> Riddell: in which case it's fine to unblacklist now that it's available again
<slangasek> shall I go ahead and do that?
<Riddell> slangasek: please do
<Riddell> I'll do the sync then
<slangasek> Riddell: blacklist updated
<Riddell> groovy, sorted
<mdz> neat: [ 1181.314999] chromium-browse[3502]: segfault at 42ddd671 ip 42ddd671 sp 42ddd671 error 4 in DejaVuSans.ttf[aca0a000+9b000]
<mdz> I never saw a segfault in a font before
<ion> heh
<slangasek> ttx: regarding your change to samba-common.postinst - rather than throw a message telling users to copy the default smb.conf over when the file is missing, why not do this for the user?
<ttx> slangasek: ISTR someone raised a policy argument against that solution, lemme check the bug
<slangasek> well, the policy argument is weak :)
<ttx> slangasek: then I misunderstood you back then: https://bugs.launchpad.net/ubuntu/+source/samba/+bug/312449/comments/6
<ubottu> Launchpad bug 312449 in samba (Ubuntu) "samba-common fails to upgrade if smb.conf is deleted" [Wishlist,Fix released]
<slangasek> ttx: or perhaps I'm being inconsistent!
<ttx> slangasek: I wouldn't suggest anything like that :)
<slangasek> ttx: tried to dig up context for that comment from me and failed.  Policy does say that local changes to config files must be preserved during a package upgrade (Policy 10.7.3), but it's debatable whether nuking the config file and rendering the package uninstallable should count...
<slangasek> ttx: btw, is the comment accurate?  Does the install actually fail now, or does it just complete with a non-existent config?
<slangasek> heh - it looks like 'start smbd' returns success, and then smbd dies afterwards :/
<slangasek> darn foregrounded process supervision
<Laney> ping re: the sync queue â looks like it hasn't been processed for a while
<geser> Laney: looks like Riddell is processing it right now
<Riddell> that I am
<Laney> ah, sexy
<Riddell> although I'm about to stop for a bit to do an exciting talk on declarative UI programming in #ubuntu-classroom
<ttx> slangasek: it fails. The message allows for easy spot of duplicated and we have a canned response to handle those now
<slangasek> ttx: are you sure it still fails since the conversion to upstart? :)
<ttx> slangasek: ah
<slangasek> because my testing says it doesn't
<ttx> slangasek: well, no
 * Laney does love a bit of declarative programming
<slangasek> (and that this is a bug)
<ttx> slangasek: you tested it more recently than I did.
<ttx> slangasek: about context for the comment: I took it back then from one of the multiple duplicates of this bug, that's all I remember
<slangasek> ok
<YokoZar> could someone on Lucid with ATI open source drivers please echo $LIBGL_DRIVERS_PATH  for me
<YokoZar> (on amd64)
 * Laney sees 8 new LP mails :)
<Laney> syncs be good
<asid> hello me and my friends are 4 people in need of a project to work on, and all seem to suffer from ideas block.....we've have limited experience in using linux(but a few months time to familiarise with it) .....could you  guys suggest some ideas for  a project (perhaps a feature you want to implement in linux)
<Laney> asid: there are many many ideas on brainstorm.ubuntu.com
<asid> thanks for the link......am looking at it .....if you guys have any idea for a project for ppl please give suggestion
<ari-tczew> now on maverick, update-manager shows description instead package name. is it a bug or new feature?
<sladen> asid: thank you for your interest.  Work in Ubuntu is generally done either in response to fixing a bug report requiring the change ( https://bugs.launchpad.net/ubuntu/+bugs ), or planned via specifications
<ari-tczew> asid: I think that you can start with Ubuntu development - syncs, merges, security updates :)
<asid> thanks for replies.....well bug fixes really doesnt sound like an idea for a project...also we do not need it to be automatically incorporated into the next release of  Ubuntu, we just need  an idea for a  reasonably sized project to work on that could be useful in Ubuntu
<apachelogger> pitti: ping
<highvoltage> anyone else having trouble accessing Canonical's website?
<apw> cjwatson, ok this is a prototype of a new approach: http://people.canonical.com/~apw/misc/fbcon-handoff2.ogv
<ion> highvoltage: Worksformeâ¢
<apw> cjwatson, this one works on the assumption that the empty areas of the VT are transparent and not updated
<ion> Looks nice
<BlackZ> bdrung: ping
<bdrung> BlackZ: pong
<BlackZ> bdrung: do you have the time to look at bug #554823 ?
<ubottu> Launchpad bug 554823 in logrotate (Ubuntu) "Please merge logrotate 3.7.8-6 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/554823
<ccheney> is there a format for the preseed file documented anywhere?
<cjwatson> ccheney: in the installation-guide
<cjwatson> appendix b
<ccheney> ok thanks
<bdrung> BlackZ: slangasek already commented the merge request.
<BlackZ> bdrung: oh, I'm not subscribed there, sorry
<BlackZ> subscribing now
<BlackZ> thanks slangasek
<bdrung> BlackZ: you need to subscribe ubuntu-sponsors once address slangasek's questions
<BlackZ> bdrung: yes, I will. I didn't see the bzr branch, sorry. However I emailed Daviey to see if he still wants to do the merge
<hv> is the "blank screensaver" broken? if you happen to click or press a key when it starts fading to black, it does not stop.
<ccheney> cjwatson, it keeps popping up asking me for the country, isn't that supposed to be resolved with the following?
<ccheney>  - d-i console-setup/ask_detect boolean false
<ccheney>  - d-i console-setup/layoutcode string us
<ccheney> it seems to not be enough :-\
<ccheney> and is there anything i can look at source-wise to be able to determine what i need to override if I see something like this again?
<slangasek> country != keymap ?
<ccheney> hmm maybe so, i see at the bottom of the docs it tells how to dump all questions that should help i suppose
<ccheney> slangasek, i tried adding more and it still gets stuck at the question asking 'origin of the keyboard' http://pastebin.ubuntu.com/463202/
<slangasek> ccheney: what's the source for those preseed values?  I wasn't aware that there were any keyboard layouts called 'USA'
<slangasek> but I'm generally not current when it comes to d-i preseeding info, sorry
<ccheney> i tried running: debconf-get-selections
<ccheney> but perhaps i need the --installer variant which seems to not work on my box due to cdebconf being missing
 * ccheney wonders if just installing that package would show me the needed info
<ccheney> hmm, no
<ccheney> debconf: DbDriver "di_questions": could not open /var/log/installer/cdebconf/questions.dat
<ccheney> perhaps i need to run that off a cd
<bigon> Caesar: regarding dhcpv4 it brings ipv6 support both on server side and client + in networkmanager
#ubuntu-devel 2010-07-14
<cjwatson> ccheney: I think you need to read the preseeding guide in more detail.  you need to preseed early questions on the kernel command line.  don't use debconf-get-selections for this, or look at questions.dat - it will only be confusing.
<cjwatson> (so e.g. console-setup/layoutcode=us on the command line)
<cjwatson> and don't preseed console-setup/layout or console-setup/variant at all; I don't think the guide advises that?
<Caesar> bigon: I know, I'm the Debian maintainer of it
<ccheney> cjwatson, ah ok, thanks
<ccheney> cjwatson, it appears i had a seeded answer on the kernel command line but that it was wrong, oops
<j1mc> hi all. the ubuntu doc-team is going to update the packaging guide.  if you have a bit of time, please complete our packaging-guide survey: http://is.gd/dr5Ef
<RAOF> cjwatson: Are you still planning to merge console-setup from Debian?  If you are planning to do it soon I can drop some Ubuntu delta to the xserver.  If not, no worries.
<un214> apt-get source sysvinit-utils gets sysvinit, which is missing the sysvinit-utils.install and related packaging files
<pitti> Good morning
<pitti> apachelogger: pong
<pitti> there, all SRU queues empty
<jdong> pitti: ah, it's a good feeling :)
<jdong> pitti: whooo! Always a great feeling
<dholbach> good morning
<dholbach> can an archive admin please process the sync requests?
<apachelogger> pitti: good morning :) is it save to assume that pot files only get imported from i386 builds?
<pitti> apachelogger: pkgbinarymangler imports them from all architectures
<pitti> but I'm not really sure how that works in Rosetta
<pitti> dpm: ^
<apachelogger> The thing is, since we are creating pot files at build time it adds quite some load, which we really should avoid on armel and the likes.
<dpm> hey pitti, good morning, let me have a look
<pitti> apachelogger: my guess is that it's enough to build it on one arch only
<apachelogger> must be, because kde-l10n-* is arch: all :)
<pitti> the interesting question is what would happen if different arches produce different pots
<apachelogger> *nod*
<pitti> whether rosetta will merge them, or randomly select one
<geser> pitti: Thanks for the gnupg2 SRU upload. I somehow got the impression that I need an SRU ack first before seeking for sponsorship.
<dpm> I can only confirm what pitti is saying: pkgbinarymangler uploads a tarball for each arch - I'm not sure what Launchpad does with them. Let me ask the Launchpad guys
<pitti> geser: both approaches were in use until now; jdong just proposed the "always upload directly" approach or everyone now (which will help to speed up things)
<dpm> the LP guys are on a sprint, I'll try to reach them later on
<TimStarling> what happens if you have a package in two different distro versions, and the source hasn't been updated so the package has the same version, but you need to recompile it?
<TimStarling> do you just bump the revision number?
<joaopinto> TimStarling, assuming it's an universe package, #ubuntu-motu is a better channel for that question
<TimStarling> it's not, but I might try there anyway
<joaopinto> mvo, hi, is there a good reason for the APT's mirror: method to have the 6h Acquire::Mirror::RefreshInterval by default ? None of the other methods has such refresh, and it defeats the usual "sudo apt-get update" purpose
<TimStarling> it's for our own APT repository that holds our in-house software, but I'm happy to adopt conventions from anyone who has thought about the issue
<mvo> joaopinto: no, no good reason, initially it was meant to be a protection for the server, but that is silly
<cjwatson> RAOF: I'd been putting it off because it's painful, but I guess I should queue it up for next.  Working on syslinux/gfxboot at the moment which is interesting in its own right
<mvo> joaopinto: fixing that in trunk to make it 1min only
<RAOF> cjwatson: That's cool.  gfxboot certainly sounds more fun!
<wrinkliez> hey guys, im making my changelog for my application now.  what if it doesnt matter what distribution my program is for? do i put "all" in the changelog?
<joaopinto> mvo, great, on getdeb we are evaluating to switch from http redirects to the mirror method, for the current release we will need to distribute a apt .conf to set the refresh to 0
<mvo> yeah, in maverick that is oing to get fixed
<joaopinto> for a web interface with frequent updates is crucial to have the cache refreshed from an updated mirror
<joaopinto> so the mirror list will built from scanning a pool of mirrors
<joaopinto> be
<joaopinto> mvo, is there some documentation about the 'Packages' diffs support ? I think I have seen it on some archive, apt already supports them right ?
<mvo> joaopinto: apt supports them, they are called "pdiffs" and you can get examples for this on the debian archive
<mvo> joaopinto: but they are only useful if there is not too much churn in the packages files, as they are "sequential" (basicly just patches) and if your packages file is generated 10 times a day the user needs to download 10 patches
<mvo> joaopinto: that may well be not efficient anymore
<mvo> joaopinto: for stuff that is big and changes slowly they are great
<joaopinto> right, not very useful for volatile repositories
<cjwatson> RAOF: ... maybe
<cjwatson> RAOF: current state is that kvm falls over with an internal error trying to run it, so I'm sitting here tracing through assembly code ... depends what you call fun
<dmart> amitk: Hi, do you have a moment?
<amitk> dmart: sure
<dmart> Hi there... just wondering where you were on the arm-m-missing-security-features stuff?
<dmart> amitk: Were you able to push your SECCOMP patch yet?
<amitk> dmart: I'd gotten distracted with Linaro PM work, but I've just resurrected the patch today and will test it
<dmart> Was there any difficulty there, or is it just a question of pushing the patch?
<amitk> dmart: no difficulty, just too many balls in the air
<amitk> I should have something this week
<dmart> OK, cool - thanks.  Sounds like that will fit well within the proposed milestones
<pitti> lamont: https://edge.launchpad.net/ubuntu/+source/mozart/1.4.0-5build1/+build/1776421 seems stuck (building for 4 days without any log), maybe this should be killed?
<Keybuk> pitti: argh, could you NAK the -proposed upload of ureadahead from rtg please?
<pitti> uh, there's not even a bug associated
<Keybuk> indeed
<pitti> ah, just wrong syntax
<pitti> bug 501715
<ubottu> Launchpad bug 501715 in ureadahead (Ubuntu Maverick) "Kernel trace buffer should be cleared and size restored after profiling" [High,Triaged] https://launchpad.net/bugs/501715
<Keybuk> and the patch is about as wrong as tedg in a mankini
<Keybuk> the upload, as is, will simply stop it from working entirely
 * tedg sends photos in private message
<pitti> *chuckle*
<pitti> Keybuk: can you please elaborate on the bug? I'll set it to v-failed
<Keybuk> sure
<pitti> Keybuk: so it's bad enough that I should pull it from -proposed?
<Keybuk> yes
<Keybuk> it will truncate or wipe the buffer before even parsing it
<asid> hello...we're 4 students looking for some idea for a project ....if anyone could suggest an idea for some feature\software that  you would like to see in linux, it would be great
<pitti> Keybuk: done, bug updated
<pitti> Keybuk: and hello BTW!
<jussi> asid: which languge do you want to write in?
<asid> at this stage we're open to just about anything....C\C++, web based, Java
<jussi> asid: and how big of a project?
<Keybuk> pitti: hello :-)
<pitti> Keybuk: unrelated question, is anything wrong with the udev in bzr head? robert_ancell was asking about it, since the new bluez needs it
<pitti> (well, at this point we should update to 160, but I wasn't sure whether you held it back intentionally)
<Keybuk> pitti: it didn't boot
<pitti> details!
<pitti> :)
<Keybuk> I didn't get as far as details ;)
<Keybuk> it didn't boot, I didn't upload it
<asid>  we're 4 college students (amateur coders) and this is for a major project ...perhaps 3-6 months
<Keybuk> will investigate more probably at the sprint
<pitti> Keybuk: no, I mean, that's such a small bug
<pitti> sorry, that didn't quite come across as intended
<Keybuk> ah
<Keybuk> lol
<ion> keybuk: Any in-progress Upstart 0.10 code you could publish? :-)
<jussi> asid: do you have any things that you are particularly interested in?
<asid> well actually we're amazingly  blank about what to do(on the day before an exam, I am usually bursting with ideas of better things i would rather do) ...
<jussi> asid: hehe, well Im sure we can find something.
<asid> we've been juggling ideas as random as MMOGs, browser-based 3d modelling tools, home automation etc....
<lamont> pitti: buildd    7227  6.1  0.0   2136   536 ?        R    Jul10 388:29      |                                                               \_ /bin/sh /build/buildd/mozart-1.4.0/doc/utilities/latex2png /tmp/file0yXDun apptut-html 1 2 3
<lamont> I'm guessing you're right
<lamont> pitti: 787137711 bytes of logfile
<cjwatson> could an archive admin review syslinux and gfxboot in NEW, please?
<StevenK> cjwatson: Certainly
<dholbach> nigelb, pedro_, JFo: ready for UDW later on?
<pedro_> dholbach, yeah!
<JFo> I am indeed :)
<StevenK> cjwatson: Since syslinux is in main, where would you like extlinux to end up?
<nigelb> dholbach: oh yeah! :)
<dholbach> woohoo
<cjwatson> StevenK: extlinux can go in universe for the time being, IMO
<cjwatson> it shouldn't be dangerous in main, but there'll be nothing pulling it in there
<StevenK> cjwatson: Okay, same question for gfxboot-dev
<cjwatson> needs to be in main, it'll be a build-dependency of gfxboot-theme-ubuntu
<StevenK> cjwatson: Accepted.
<cjwatson> thanks
<lamont> pitti: so I think it had a build log, it's just newlines after about line 4100 or so..
<lamont> killed, fwiw
<Keybuk> apw: apply! apply! apply!
<apw> Keybuk, ok on my list ...
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 3 about to start in 19 minutes in #ubuntu-classroom
<ManDay> Can anyone tell me why the wacomutils have been taken out of the repos?
<c_korn> ManDay: what is the package name ?
<LucidFox> Oh great, the latest post on Planet Ubuntu says Twitter in huge letters
<LucidFox> there is no escape, you can run but you can't hide...
<azeem> wow, planet ubuntu has excessive drop shadows now
<Keybuk> LucidFox: you would prefer it to say LucidFox in large letters?
<LucidFox> No, I'm just sick of Twitter mentions everywhere, to the brink. Wrong place for me to rant about it, though
<maco> azeem: has had for a while
<Keybuk> you're sick of people mentioning micro-blogging on their blogs?
<Keybuk> that's a bit like being sick of people mentioning their cameras on flickr isn't it?
<LucidFox> Keybuk> Well, blogging and microblogging are... different things
<LucidFox> one makes sense to me, the other doesn't
<LucidFox> (or well, I can understand why *some people* would use it, but a) I can't understand why it's so massively popular to the point that every single site has button links with the T-word, and b) I don't use it myself, don't see the point, can't see why I ever would, etc.
<Keybuk> lots of things don't make sense to me: Religions, Al Murray (The Pub Landlord), Wearing sunglasses in nightclubs, Fish, etc.
<highvoltage> Keybuk: some people just have sensitive eyes!!!
<davmor2> Keybuk: you missed off sysvinit :)
<Keybuk> that makes sense
<nuovodna> hi, will gtk 3.0 be in maverick repo ??
<highvoltage> robbiew: is https://wiki.ubuntu.com/MaverickReleaseSchedule still acurate?
<highvoltage> robbiew: sorry, I read step 24 as October 24. nm :)
<robbiew> highvoltage: ;)
<SpamapS> hmm, so why isn't rrdtool listed here: https://merges.ubuntu.com/main.html  if it is grossly out of sync w/ debian and has been since 2010-01-22?
<cjwatson> SpamapS: bug in merge-o-matic, triggers when some Debian architectures are out of sync
<cjwatson> SpamapS: Debian's archive software changed a while back to keep all the versions in Sources that correspond to any architecture, and hurd-i386 is way out of date (as usual)
<cjwatson> SpamapS: I have half a patch for MoM to fix this but haven't had time to test it
<SpamapS> cjwatson: Ahh, so is the fix to request a sync?
<SpamapS> I mean, workaround
<SpamapS> The dbi capabilities of the latest version are particularly appealing for some stuff I've been playing with. :)
<cjwatson> SpamapS: you can request a sync or merge as appropriate regardless of what merge-o-matic says
<cjwatson> there's a single change in Ubuntu; look at it and check whether it's still appropriate
<cjwatson> if it is, prepare a merge (not hard to do by hand - fetch the base version from ftp.debian.org or snapshot.debian.org or whatever, diff Debian->Ubuntu, apply diff to new Ubuntu package, resolve conflicts, create new changelog entry at the top)
<cjwatson> otherwise, request a sync
#ubuntu-devel 2010-07-15
<electrofreak> why is there the lack of the kernel config in /proc/. I swear it was there in previous versions of ubuntu
<TheMuso> electrofreak: Because its found in /boot
<electrofreak> TheMuso: ah, that'll work. thanks for pointing that out
<TheMuso> np
<pitti> Good morning
<diwic> Good morning pitti
<pitti> hey diwic
 * pitti NEWs the new kernel
<diwic> pitti: For Lucid, Maverick, or what?
<pitti> maverick
<TheMuso> Ah that explains linux-generic etc being kept back on update a little earlier.
<TheMuso> Didn't even think to consider that. :)
<pitti> right, and why today's images failed to build
<diwic> Good morning to TheMuso as well, although I guess it's evening in Australia.
<TheMuso> diwic: Mid afternoon to be more precise.
<hdon> !!!!
<hdon> i found a security vulnerability in sudo!
<micahg> hdon: please file a private bug against the sudo package and flag it security vulnerability
<micahg> hdon: on launchpad under ubuntu
<hdon> i am creating a ttyrec to demonstrate the problem
<DreadKnight> 10.10 is fail for me.... the internet connection fails for about 10-20 seconds every 5 minutes or so, not cool
<micahg> DreadKnight: please seek support in #ubuntu+1
<DreadKnight> ok
<hdon> micahg, perhaps it is not a bug,  but it is not the behavior i expected
 * hdon reads the man page
<hdon> oh
<hdon> i guess it's not the sudo man page that it woudl be in
<hdon> but gnome-terminal
<sbeattie> hdon: if it's not already covered by https://wiki.ubuntu.com/SecurityTeam/FAQ#Sudo perhaps you could add it there.
<kees> we should really add sudo -K to .bash_logout and gnome-session to avoid this :)
<hdon> sbeattie, thanks for the tip
<sbeattie> kees: heh, yeah.
 * hdon adds
<hdon> kees, thanks
<hdon> sbeattie, doesn't seem to do the trick
 * sbeattie also wants to resurrect the patch to sudo he was working on to add an option to kill all cached sudo tokens
<hdon> sbeattie, ~/.bash_logout is not being executed when i exit bash and/or close the terminal
<sbeattie> hdon: ah, gnome-terminal is not starting bash as a login shell.
 * sbeattie discovers he already had "/usr/bin/sudo -k" in his .bash_logout
<sbeattie> ... though whether the shell is started as a login shell is configurable under gnome-terminal's profile settings.
<dholbach> good morning
 * hdon looks
<hdon> sbeattie, there's a check box
<hdon> that worked
<ravibn> Hi!
<ravibn> Any one here?
<apw> as package sets _still_ don't confer nomination accept rights ... i wonder if someone could accept the nom for lucid on bug #601192
<ubottu> Launchpad bug 601192 in linux-meta (Ubuntu) "linux-image-virtual installs PAE kernel instead" [Undecided,New] https://launchpad.net/bugs/601192
<smb> cjwatson, pitti I have another question on SRU able changes. In l-b-m we got backported drivers. At the moment the same source package produces l-b-m-wireless and l-b-m-alsa so people do not have to opt in for all backported modules. Is it allowed to add additional binary packages when new types of modules should be required. The might be need for l-b-m-input or l-b-m-wwan soon.
<pitti> smb: we usually don't allow new packages in SRUs, but since this is really more like -backports, it sounds fine from my side; it's what lbm is for, after all
<smb> pitti, Right, it is backports for what its worth. I just wanted to be sure this is ok. And not needs a MIR (I would think this is only needed for new source packages but I just might be plainly wrong)
<pitti> smb: correct, MIRs are source based
<pitti> the new binary will just go to main as well
<smb> pitti, ok, perfect. Thanks. :)
<wgrant> pitti: pkgstriptranslations is mangling Installed-Size badly.
<pitti> wgrant: version 70 you mean?
<wgrant> It assumes that du splits the size and path with a space -- it in fact uses a tab.
<wgrant> Right.
<wgrant> This is causing rejections.
<pitti> wgrant: and you tell me that 5 seconds after I upload version 72 :)
<pitti> wgrant: hm, odd; do you have a build log?
<wgrant> pitti: http://launchpadlibrarian.net/51966247/buildlog_ubuntu-maverick-sparc.gnome-power-manager_2.30.1-1ubuntu2_BUILDING.txt.gz and http://launchpadlibrarian.net/51966250/upload_1871365_log
<wgrant> (geser pointed me at them)
<pitti> http://launchpadlibrarian.net/51966250/upload_1871365_log is 404
<wgrant> Er, add a .txt, sorry.
<pitti> wgrant: thanks for pointing out; will fix immediately
<wgrant> Thanks to geser for pointing the upload failure out in the first place.
<pitti> geser: thanks
<pitti>     self.assert_(re.match('^Installed-Size: \d+$', l))
<pitti> AssertionError
<pitti> wgrant: ok, added to test suite
<wgrant> Great.
<wgrant> Now, hopefully pkgbinarymangler doesn't itself have translations!
<pitti> wgrant: no, it builds itself with NO_PKG_MANGLE for reasons like this :)
<wgrant> Heh, fortunate.
<pitti> meh, you can test however much you want, *something* in this bloody beast will fail
<pitti> sorry about that
<pitti> wgrant: uploaded
<wgrant> Great.
<pitti> is there a way to get a list of recent FTBFSes?
<pitti> so that I can retry them in two hours
<wgrant> It's an upload failure, not a normal build failure, so https://edge.launchpad.net/ubuntu/+builds?build_text=&build_state=uploadfail should do it.
<wgrant> Looks like there's only been a couple.
<pitti> wgrant: thanks, I'll go through that once the fixed version is in
<pitti> just three for now
<pitti> oh noes
<pitti> it seems that they now fail to build because apt gets confused by an extra output line of dpkg-deb; I reverted that in version 72, but seems that's causing it to fail now
 * pitti shoots himself
* pitti changed the topic of #ubuntu-devel to: ALL PACKAGES FTBFSing due to pkgbinarymangler | 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
<doko_> pitti: is this the same? http://launchpadlibrarian.net/51973452/buildlog_ubuntu-maverick-i386.pylirc_0.0.5-2_FAILEDTOBUILD.txt.gz
<pitti> elmo, lamont: I'm sorry, seems that the recent pkgbinarymangler confuses apt, causing everything to FTBFS
<pitti> elmo, lamont: apparently it stumbles over an "INFO: version" line; I reverted this, but now we again have the situation that I can't pull myself out of the swamp
<geser> pitti: as far as I can see on https://edge.launchpad.net/ubuntu/+builds?build_text=&build_state=uploadfail only 3 builds got hit by it till now
<pitti> seems we need a manual build of current pkgbinarymangler; after that I can give back everything that failed
<pitti> doko_: presumably
<wgrant> geser: Different issue.
<wgrant> An easy fix is to just restore the buildd chroots from yesterday, I suppose... they have pkgbinarymangler held.
<cjwatson> apw: approved the nomination.  can you poke bdmurray about the nominations / package sets bug, to see if he can get that fixed?
<apw> cjwatson, yeah i regularly poke at them on tha tone, but they say its not important in essence
<apw> i tend to !concur with that position
<pitti> wgrant: I guess that needs lamont/elmo powers, though?
<cjwatson> apw: that's why I suggested specifically bdmurray; he's seconded to Launchpad from platform, and I understand is putting some effort into fixing things important to platform
<apw> ahh very good, nice, liking your thought process :)
<wgrant> pitti: Ah, maybe, not sure if anyone else can do that.
<cjwatson> wgrant: if I had the previous chroots, I think I could probably stuff them back in
<cjwatson> I believe I can do that with manage-chroot.py on cocoplum; I certainly used to be able to, though I don't remember whether that's before or after archive-master stopped being builddmaster
<wgrant> cjwatson: http://launchpadlibrarian.net/50312513/chroot-ubuntu-maverick-i386.tar.bz2
<wgrant> (link retrieved from dogfood, but it's the old production one)
<cjwatson> can I have the links for all architectures?
<pitti> we only need i386, no?
<pitti> pkgbinarymangler is arch:all
<pitti> we just need to get the new version built and into the archive
<wgrant> Roght, that's whatI was thinking.
<cjwatson> ah
<cjwatson> let me see then
<pitti> in fact, I have the .deb right here, but I guess we can't manually upload that
<elmo> you know chroot management is done on cesium now, right?
<elmo> it's possible cocobanana still has DB access to do it, but I'd hope it doesn't
<cjwatson> elmo: as I said above - I wasn't sure whether it was still possible from cocoplum
<cjwatson> mm, yeah, ident auth failed for fiera
<cjwatson> 2010-07-15 10:28:34 INFO    Creating lockfile: /var/lock/launchpad-mangage-chroot.lock
<cjwatson> classy, btw
<elmo> I'll do it
<cjwatson> thanks
<pitti> cjwatson, elmo, lamont: I set all main builders to manual, to avoid further FTBFSes
 * apw throws pitti a stought rope
<wgrant> Hmm, not building yet?
<pitti> wgrant: I set everything to manual
<pitti> I'm waiting on the word to retry pkgbinarymangler
<pitti> i. e. when elmo/cjwatson say that the old chroot has been enabled again
<cjwatson> not I
<wgrant> It appears to be.
<pitti> oh
 * cjwatson wonders what magic check wgrant is using
<pitti> wgrant: trying then
<wgrant> cjwatson: I exported the chroot URL via the API a couple of months back. https://edge.launchpad.net/api/devel/ubuntu/maverick/i386 handily shows it now.
<cjwatson> aha
<wgrant> Yay, building. You caught buildd-manager at just the right time...
<wgrant> Ah, or all the PPA buildds have vanished again.
<pitti> yohoo, works
<pitti> i386 buildds back to manual
<wgrant> Phew.
<geser> wgrant: do you know if downloading such a chroot tar would work with pbuilder? that would save me some time to setup my own for i386
<wgrant> geser: The sources.list is different, but apart from that it should be OK.
<wgrant> (the buildd chroots use ftpmaster.internal rather than a.u.c)
<pitti> wgrant: hm, seems oem:common PPA has its own chroot?
<wgrant> pitti: Impossible.
<pitti> wgrant: hm, it failed again there, same error
<pitti> https://edge.launchpad.net/~oem-archive/+archive/common/+build/1873638/+files/buildlog_ubuntu-lucid-i386.pkgbinarymangler_74common1_FAILEDTOBUILD.txt.gz
<pitti> wgrant: (not sure whether you can see this)
<wgrant> I can't, no.
<wgrant> Is it possible that they've overridden the hold somehow?
<pitti> it's a nonvirtual PPA
<wgrant> Also, that's lucid.
<pitti> ah, right
<wgrant> So maybe yu just need to delete pkgbinarymangler from the PPA for a few minutes.
<pitti> wgrant: I can't
<wgrant> :(
<pitti> elmo: is it possible that you can restore the lucid chroot as well for a minute?
<wgrant> The lucid chroot isn't broken, is it?
<pitti> but the oem:common PPA is now (same problem)
<apw> pitti, would someone have access to delete the package from the PPA ?
<pitti> apw: cody-somerville perhaps
<wgrant> pitti: Oh, has the lucid chroot just had it unheld too?
<apw> there must be an elmo equivalent for PPA's i recon
<pitti> cjwatson, elmo: maverick pkgbinarymangler built, so the chroot can be swapped back
<elmo> (sorry, hotel called me away)
<pitti> wgrant: right
<elmo> but it's been done
<elmo> oh
<wgrant> pitti: Don't we want to wait for publication?
<elmo> pitti: surely if I swap it back it'll add the old/broken pkgbinarymangler, no?
<pitti> wgrant: well, we can, but all buildds are on manual
<wgrant> Oh, I guess swap back, then unmanual.
<elmo> or will it get upgraded as part of the build?
<wgrant> Right.
<pitti> elmo: the problem is that builds upgrade to the broken one
<YokoZar> Is there a way to change the email address of my bzr commits without un/recommitting (not yet merged) ?
<wgrant> elmo: It gets upgraded.
<elmo> ok
<wgrant> YokoZar: No.
<pitti> elmo: version 70 was still fine
<pitti> Preparing to replace pkgbinarymangler 70 (using .../pkgbinarymangler_71_all.deb) ...
<elmo> pitti: lucid swapped back
<pitti> that's when things started to go wrong
<elmo> pitti: and maverick rolling forward now
 * pitti waits on buildd-queue to kick in
<geser> pitti: luckily you didn't these uploads on a friday short before you leave for the weekend
<pitti> geser: deliberately
<apw> pitti, won't we still need to wait for the new version to publish before putting any builds thorugh?
<elmo> pitti: mavrick back on the 'new' chroot
<pitti> apw: correct
<pitti> elmo: thanks
<pitti> lucid oem:common mangler building now
<pitti> apw: I'll wait for this and then mass-retry
<pitti> (and set buildds to auto again)
<elmo> pitti: let me know when lucid can roll forward again
<pitti> elmo: will do; ETA 2 mins
<pitti> elmo: done; please switch back lucid chroots
<pitti> elmo: thanks so much, and sorry for the hassle!
<elmo> pitti: done
 * pitti makes a mental note to add apt testing should he ever change dpkg-deb again
<cjwatson> is anyone seeing bug 605614 on a system that *doesn't* have an ATI graphics card?
<ubottu> Launchpad bug 605614 in grub2 (Ubuntu) "Maverick's grub-pc package (1.98+20100710-1ubuntu1) causes unbootable system " [Undecided,New] https://launchpad.net/bugs/605614
<cjwatson> apw: ^- I'm thinking that this might be a straightforward kernel bug; mjg59 did warn that there might be some cases where KMS drivers fail to go from VESA->native
<cjwatson> (cf. http://irclogs.ubuntu.com/2010/04/08/%23ubuntu-kernel.txt)
<apw> cjwatson, from the panic there i'd say so yes, its a gpu lockup it seems
<cjwatson> I'll clone off a kernel tas
<cjwatson> k
<geser> apw: have you an idea why with the -8 kernel in maverick X only detects one of my two monitors while with the -7 kernel both are detected? /me goes to file a bug about it
<apw> geser, no specific info on that no ... obviously the kernel has been rebased on mainline so anything can and does happen
<seb128> is there an easy way to reinstall grub from a livecd? ie running update-grub or something
<seb128> it's on a box where a winxp reinstalled kicked grub out of the mbr or something
<geser> seb128: I'd try dpkg-reconfigure grub-pc in the chroot with the system
<seb128> ie, on the installed partition there?
<seb128> I've tried to run update-grub there without success
<geser> update-grub only updates the grub config file
<seb128> install-grub hd0 didn't work either
<seb128> geser, ok, wiki was helpful, https://help.ubuntu.com/community/RecoveringUbuntuAfterInstallingWindows
<seb128> grub-install works you just have to mount the install you want to restore and give it as an option
<pitti> seb128: I usually mount and chroot into the installed partition and run sudo grub-install /dev/sda
<pitti> ah, seems you figured this out
<seb128> pitti, yes, thanks
<cjwatson> seb128: also https://help.ubuntu.com/community/Grub2#Reinstalling%20from%20LiveCD "METHOD 3 - CHROOT", which is what we usually refer people to upstream
<cjwatson> (I would steer clear of the other methods - I need to find time to do some redrafting on that page
<seb128> cjwatson, that's what I did yes
<cjwatson> the problem with the grub-install --root-directory= approach is that it gives you the grub images from the live CD rather than those on the system, which isn't always necessarily desirable
<seb128> right
<seb128> in this case that's lucid on both systems so that's ok ;-)
 * pitti cautiously tries a new package build, now that the new pkgbinarymangler has been published
<towolf> something's wrong with new freetype.
<towolf> http://i.imgur.com/sR2hO.png
<towolf> looks like its limited to opentype.
<towolf> should i take that to freetype upstream or file in launchpad first?
<pitti> yay, maverick builds working again
 * pitti opens the floodgates and sends annoucnement
* pitti changed the topic of #ubuntu-devel to: 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
<seb128> hum
<seb128> had somebody see "fb: conflicting fb hw usage inteldrmfv vs VESA VGA"
<ricotz> hello, please let builds like these stop if there are older than 100 days or so - https://edge.launchpad.net/~patrick-hetu/+archive/ppa/+build/739056
<seb128> bugs on maverick?
<seb128> not sure where to report the bug
<cjwatson> ricotz: we don't manage PPAs here, try #launchpad
<smoser> cjwatson, so if i have a 'default X' in my menu.lst, that will trump 'savedefault' ?
<cjwatson> smoser: so 0.97's stage2 does read /etc/grub/default, and in the once-only case it writes a modified block back to disk before booting
<smoser> yeah, so i really have no stage 2
<cjwatson> let me check
<cjwatson> pvgrub will be the stage2 equivalent, I expect
<cjwatson> smoser: you have to have "default saved", or the saved default won't be used
<smoser> ok. i have some things to test here. i'm fairly sure now that i need to have 'saved' in menu.lst
<smoser> yeah
<cjwatson> let me ask a Xen developer I know
<smoser> so i'm confused as to why grub-reboot calls grub (with set-default and --once) where grub-set-default just writes the entire 'default' file itself.
<cjwatson> smoser: the savedefault patch is apparently in pvgrub, so you should at least not be entirely doomed
 * cjwatson curses smoser for making him dredge up 0.97 memories
<ricotz> cjwatson, i already done this, but i was hoping to find some supporters
<smoser> cjwatson, i shouldn't really be wasting time on this, so i definitely should'nt be wasting yours.
<smoser> i'd like to have boot once behavior, as in a ec2 instance-store instance, if you boot into a bad kernel you're 100% hosed otherwise.
<cjwatson> smoser: I'm not entirely sure why it bothers with that either.  I think you could just write out the file directly.
<smoser> but i have this same work to do for grub2, so I'll pester you (and #grub) with those questions which wont have the bad memories.
<cjwatson> that's all the implementation of savedefault --once seems to do.
<geser> ricotz: I've read recently about this problem, but I can't find where right now, still looking. It is because debhelper 7 is in hardy-backports and the script which checks the debwait that debhelper >= 7 is available but doesn't consider that your PPA doesn't use hardy-backports and retries anyways
<smoser> cjwatson, i thought it might be in order to work with an older grub or something.
<smoser> one that didn't just write 0:1, but did something else.
<cjwatson> smoser: no, I think the reason it's done in C is because it needs to parse out the previous default from /etc/grub/default, and there was already C code to do that
<cjwatson> because grub-reboot is "read previous default from /etc/default/grub, then write $prev_default:$new_default"
<smoser> well, certainly that would be almost impossible to do in shell :)
<smoser> thanks cjwatson .
<cjwatson> if you don't want to rewrite it, can you just call grub?  It doesn't actually have to be the running grub
<cjwatson> as long as the installed bootloader has support for parsing the $previous:$new syntax in /etc/grub/default, which apparently pvgrub does
<ricotz> geser, yes, they get started like every hour and with the current ppa queue situation it is waste of resources
<smoser> well, at the moment, my legacy-grub-ec2 conflicts with grub and doens't have the grub binary. i can rewrite that easy enough if it is a win for --once.
<smoser> oh, and grub moans when running it on ec2 anyway, because it can't get the bios drives sorted out
<cjwatson> smoser: might be easier to just write a standalone program to do the parsing.  can't be that hard.
<smoser> sh -c 'IFS=: read default once < /boot/grub/default'
<smoser> but it seems at this point like its for naught
<smoser> as
<smoser> $ grep ^default /boot/grub/menu.lst
<smoser> default         saved
<smoser> $ head -n 1 /boot/grub/default
<smoser> 0:1
<smoser> rebooted, came up in '1'
<smoser> but that file still has '0:1'
<smoser> rebooted again just for kicks
<smoser> still in '1'
<smoser> and file still the same.
<smoser> i'll have to get the amazon folks to help me.
<Daviey> Is anyone ACK'ing SRU's today?
<pitti> I did some processign today
<Daviey> pitti, would you mind looking at bug #605358 , please? :)
<ubottu> Launchpad bug 605358 in asterisk (Ubuntu) "Cannot make outgoing calls, "address family not supported by protocol"" [Medium,Confirmed] https://launchpad.net/bugs/605358
<pitti> Daviey: not now, sorry
<Daviey> pitti, thanks anyway
<cjwatson> smoser: it could be that pvgrub is writing to /etc/grub/default in the dom0 rather than in the domU or something
<cjwatson> (if that makes sense.  I never did get my head around Xen.)
<smoser> well if it was in the dom0, that would be quite bad !
<smoser> :)
<cjwatson> apw: hm, the original reporter of bug 605614 has quite a different crash from the one that geser reported.  Do you think geser should file a separate bug?
<ubottu> Launchpad bug 605614 in linux (Ubuntu) "[ATI] GPU lockup with gfxpayload=keep" [Undecided,New] https://launchpad.net/bugs/605614
<apw> cjwatson, definatly if they look differnet, we can always dup them back
<cjwatson> ah, well, there is a GPU lockup in there
<cjwatson> also weird stuff like "*ERROR* invalid framebuffer id" before that
<cjwatson> I'm not quite sure, somebody more qualified would need to check
<achiang> for upstart debugging (http://upstart.ubuntu.com/wiki/Debugging) where it says add "--debug" after init=.... ; just want to confirm that means unpacking the initrd to modify that command, right?
<cjwatson> achiang: no, it goes on the kernel command line.  If you're using GRUB then you can edit that on the fly from the boot loader menu.
<cjwatson> (You may not have an init= item there; that doesn't matter.
<cjwatson> )
<achiang> cjwatson: hm, do i need to specify the init= as well? or does just a plain old '--debug' anywhere on the kernel cmdline magically work?
<cjwatson> the latter.  you don't need to specify init=, that's just for people installing upstart in some non-default location.
<achiang> ah, thx
<cjwatson> dunno why that page talks about it at all.
<achiang> i'll clean it up in a bit
<ari-tczew> mvo: question about update-manager: is it a new feature? previously I could see a package name, not I can see only package's description. it's not good idea (IMHO).
<mvo> ari-tczew: its a new feature, the pkgname is still there, just second instead of first.
<geser> cjwatson: comparing the both Xorg crash call traces from the both logs in that grub2 bug, they look pretty similar
<cjwatson> geser: ok
<cjwatson> geser: did you have the "*ERROR* invalid framebuffer id" as well?
<dholbach> Day 4 of https://wiki.ubuntu.com/UbuntuDeveloper Week starts in 23 minutes in #ubuntu-classroomDay 4 of https://wiki.ubuntu.com/UbuntuDeveloper Week starts in 23 minutes in #ubuntu-classroom
<cjwatson> maybe not relevant since I've sometimes seen that too
<geser> cjwatson: no
<hv> Hi. I am having trouble changing the X11 cursor theme: The change does not propagate to all places.  For instance, try resizing a window after you change the X11 cursor theme, and see if the new theme is used.
<dholbach> didrocks, vish, ttx, charlie-tca, beuno-lunch: all set for UDW sessions later on?
<didrocks> dholbach: ready to roll :)
<dholbach> fantastico
<dholbach> :)
<vish> hey .. :)
<vish> yup
<dholbach> :-D
<vish> damn it i got stuck after didrocks ! a tough act to follow :s
<didrocks> vish: ahah ;)
<vish> :)
<ttx> dholbach: yes
<ttx> dholbach: I even got my DSL fixed
<charlie-tca> ready as I can be
<beuno> dholbach, not really, have been flooded today  :(
<dholbach> beuno: you still have some time :)
<beuno> yeah, I have an outline in my head, but haven't managed to bring it down to bytes
 * dholbach hugs beuno
<smoser> cjwatson, around ?
<smoser> I'm considering providing a grub-set-default in legacy-grub-ec2 that would divert /usr/sbin/grub-set-default and wrap it.  it would then call both grub-set-default.real and grub-set-default-legacy-ec2. so that a user who just expected to run 'grub-set-default' would get the end result independent of which loader was used.
<smoser> the only negative i can think of the above is that the user may read the wrong config file (ie, menu.lst instead of grub.cfg) and have the wrong entry (in the case they are not alighed).
<LucidFox> Okay, if anyone's interested, I've fixed the white buttons bug with Murrine/Ambiance/Radiance and Cairo 1.9
<LucidFox> just need a core developer to sponsor it
<LucidFox> bug #605979
<ubottu> Launchpad bug 605979 in gtk2-engines-murrine (Ubuntu) "Buttons rendered wrong (with white background) with nvidia-current" [Undecided,Confirmed] https://launchpad.net/bugs/605979
<ari-tczew> TheMuso: did you comment on MoM "Please do not touch this." on jack-audio-connection-kit  ?
<maxb> bdrung: Hi, those Eclipse code imports you requested - The layout of the svn repository would seem to imply that they should be imported as one branch, not three.
<bdrung> maxb: i need them separately, because the two -config and -feature repositories needs to be nested into the eclipse-build repository.
<maxb> Hmm. Well I won't presume to assume that Eclipse buildsystems are sane :-)
<bdrung> maxb: they aren't same ;)
<bdrung> sane
<maxb> This is probably going to mean bzr-svn won't really understand branches and tags in svn for these, is that ok?
<bdrung> maxb: the problem is that these three are all eclipse projects and eclipse projects can be nested
<bdrung> maxb: yes, that's ok
<bdrung> maxb: the next step is to import the complete eclipse project. IIRC there was a bug preventing it
<blink_> alright, I need to rebuild gnome-volume-control-applet from source because the volume step by mouse wheel is hard coded instead of referencing the value in gconf. where I can I find the build settings that were used in creating the package in apt so I can replicate it on my own machine (with the change in source to fix this); I  have the apt sources for gnome-media here...
<blink_> or should I just report this as a bug here or upstream and hope somebody picks it up
<cjwatson> smoser: I'd really prefer that you didn't divert grub-set-default.  My hunch is that that will get really messy.
<cjwatson> smoser: stuff that has different implementations between legacy and 2 already gets pretty complicated
<TheMuso> ari-tczew: Yes, because I will be taking care of it shortly, and there is some other jack related stuff that needs taking care of, before that can be merged.
<ari-tczew> TheMuso: ok. I won't touch it.
<shadeslayer> any bughugger devs around?
#ubuntu-devel 2010-07-16
<maco> highvoltage: you online right now? americas rmb isnt making quorum. can we borrow you?
<highvoltage> maco: I really wish I could but I need to leave right now
<bitshuffler> Hi guys. I have some trouble with deps & packaging. What is the proper name for depending on e.g. libboost-filesystem1.38-dev - as in 9.10 has 1.38, 10.04 has 1.40 and so on ... What canonical name can I use to require those on all versions?
<micahg> bitshuffler: libboost-filesystem-dev?
<bitshuffler> micahg: thanks, I'm currently trying libboost-dev perhaps that works
<bitshuffler> Another question is that "libboost-dev" doesn't work on debian 5.0 cause I need 1.35 but the default is 1.34 or so. Is there some %if version = 1.2.3 for packaging debs?
<bitshuffler> So I can explicitly require libboost_1.35 on Debian 5.0 and use whatever the distro provides for the rest of the stuff?
<micahg> bitshuffler: you might want to look at this: http://www.debian.org/doc/debian-policy/ch-relationships.html
<bitshuffler> micahg: so I e.g. could do something like "Depends: libboost_1.35-dev | libboost-dev" and Debian would take the first while later Ubuntu version would take the later?
<bitshuffler> (assumed that Debian 5.0 has libboost_1.35-dev and alter Ubuntu libboost-dev)
<micahg> bitshuffler: no, "Depends: libboost-dev (>= 1.35)" would probably be better, Debian would just pull in 1.34 in your example
<micahg> bitshuffler: oh really
<bitshuffler> micahg: "oh really?"
<micahg> bitshuffler: then your solution is better :)
<micahg> bitshuffler: I didn't realize lenny had multiple 1.35 also
<bitshuffler> micahg: ah, so I can rest assured that it will take the first if available and the other stuff only as fallback?
<bitshuffler> micahg: cheers, thanks a lot, you helped me out of my misery ;D
<micahg> bitshuffler: it should, yes, it should go left to right to install if none of them are installed
<bitshuffler> it has 1.35 I'm just not sure about the package name but it was just for the sake of having an example.
<bitshuffler> micahg: great, thanks a lot :)
<micahg> bitshuffler: np
<bitshuffler> Ok, hope fully the last one :D How do I add some "Prefer" for stuff like "have choice for libstdc++-dev: libstdc++6-4.1-dev libstdc++6-4.2-dev libstdc++6-4.3-dev" - as in I need libstdc++-dev and for some reason there are 3 libs providing this?
<bitshuffler> as in does .deb know some Prefer tag or how do you deal with that?
<micahg> bitshuffler: separate with | with the favorite on the left
<bitshuffler> micahg: like in "Depends: libstdc++-dev | libstdc++6-4.3-dev" ?
 * bitshuffler scratches head
<bitshuffler> on thinking about it it makes sense
<bitshuffler> micahg: Thanks a lot once again :)
<micahg> bitshuffler: yeah, I think so
<micahg> bitshuffler: np
<bitshuffler> Comming from rpm packaging that is like having to wrap your head around nosql after you got used to relational dbs ;D
<RAOF> bitshuffler: It looks like you're going about this the hard way - why are you manually populating the Depends field, anyway?
<bitshuffler> RAOF: I have to. I am not running Ubuntu / Debain but using OBS to create package for 0ad and there are some version "differences" if you try to create the stuff for Debian, Fedora, Mandriva, openSUSE and Ubuntu from 2 files ;D
<bitshuffler> so I'm used to packaging rpms but with debs I often encounter "unseen land" ;D
<RAOF> Won't OBS rebuild the source package for each of the different targets?
<bitshuffler> RAOF: yes, of course, but for that to succeed you have to provide proper packaging info for whatever distro version you use.
<RAOF> I mean, we've got a nice robust infrastructure for populating the Depends field from the libraries the package actually links to.
<RAOF> Right.  So, you Build-Depend on libstdc++-dev, the package gets built against whatever version of libstdc++ that target has, and then use ${shlibs:Depends} to automatically populate the Depends field with the appropriate dependency.
<bitshuffler> oh, you mean something like autorequires? That works there fine too for the binary but for the source package it is a bit harder (at least if you have to satisfy every supported debian & ubuntu version)
<bitshuffler> given for debian 4 and your old lts version (6.x or so iirc) it wont work anyways so I just target debian 5 and the latet 3 Ubuntu versions.
<bitshuffler> s/3/2/
<RAOF> So far you've got Build-Depends: libboost-dev (>= 1.35), libstdc++-dev
<bitshuffler> heh, gimme a sec, I'm trying it currently locally and setting up the chroot takes ages :)
<micahg> RAOF: mutiple libboost-devs are required since debian 5.0 has 1.34 by default
<RAOF> micahg: Ah, so that needs to be libboost-dev (>= 1.35) | libboost1.35-dev, right.
<micahg> RAOF: yeah
<bitshuffler> RAOF: yes, on debian 5.0 I can use libboost-dev since that installs 1.34 but I apparently need min 1.35 and later Ubuntu versions just work with libboost-dev since that is 1.38+
<bitshuffler> *on debian 5.0 I can _not_ use libboost-dev
<micahg> bitshuffler: that's why you have the minimum version specified libboost-dev (>= 1.35)
<RAOF> And have the alternative â | libboost1.35-devâ
<bitshuffler> micahg: yes, that prolly is the cleanest solution
<bitshuffler> otoh I get now "unresolvable: nothing provides libboost-signals-dev, nothing provides libboost-filesystem-dev" for 10.04 (_without_ univers) Does that make sense?
<micahg> bitshuffler: yes
<bitshuffler> micahg: in what way?
<micahg> bitshuffler: well, if your chroot doesn't have universe enabled, then you can't get those packages
<bitshuffler> micahg: well, I have libboost-filesystem1.40.0_1.40.0-4ubuntu4_i386.deb on 10.04 i586 but apparently it doesn't "provide" (dunno the dep name for that) "libboost-filesystem-dev". That's correct or am I mixing something up?
<bitshuffler> *deb name
<bitshuffler> er, make that "libboost-filesystem1.40-dev_1.40.0-4ubuntu4_i386.deb" obviously
<micahg> bitshuffler: yes, well, the metapackage is in universe and the versioned package is in main
 * bitshuffler facepalms
<bitshuffler> micahg: what is the reasoning behind that?
<micahg> bitshuffler: the binary was probably needed for something in main
 * micahg supposes the correct versioned package should provide the metapackage
<bitshuffler> (on rpm packages just would do "Provide: libboost-filesystem-dev" and I could happily do "Depends: libboost-filesystem-dev". Don't you guys have something similar?
<bitshuffler> micahg: could you look that up please with apt-get or whatever you folks use please?
<micahg> bitshuffler: yes, I checked, it doesn't seem to do it
<micahg> bitshuffler: we have a provides as well
<micahg> bitshuffler: I'm going to suggest we move to #ubuntu-packaging since that channel is specifically for packaging issues
<bitshuffler> micahg: hm, so the only way to make me happy without relying on universe (which is no option) is to make some "Depends: $libboost_ubuntu9.10 | $libboost_ubuntu10.04" line?
<bitshuffler> micahg: sure, thanks :)
<pitti> Good morning
<micahg> pitti:  if a retracer bug hasn't been retraced after a month, is that an issue?
<pitti> micahg: uh, yes; the maverick/lucid ones are working quite well
<micahg> pitti: this is for karmic
<pitti> ah, right; no retracers for that one
<micahg> pitti: is there a way to let people know that when they file bugs?
<micahg> pitti: what other supported versions are there no retracers for?
<pitti> not currently
<micahg> pitti: even hardy?
<pitti> people are not really meant to file crashes on stables in the first place :)
 * micahg should stop asking for them then
<pitti> micahg: we do have hardy retracers still, but they are rather unstable (too old launchpadlib/apport stack)
<pitti> micahg: I still have karmic chroots, but ATM I can't quite remember why I disabled karmic
<pitti> I guess it was that gdb/glibc breakage again
<micahg> pitti: well, I'd like to let the bugsquad know what the status is/should be
<pitti> micahg: what's the particular bug #?
<micahg> pitti: bug 596321
<ubottu> Launchpad bug 596321 in pidgin (Ubuntu) "pidgin crashed with SIGSEGV" [Undecided,New] https://launchpad.net/bugs/596321
<pitti> micahg: I can re-add the karmic one, and we'll see how far it gets
<pitti> (done)
<micahg> pitti: thanks
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<rock> ?
<micahg> pitti: the problem with the eclipse/xulrunner issue is actually a xulrunner/cairo issue which actually affects Seamonkey as well, but I haven't had a chance to fix it yet, where do you think the breaks should go now?
<pitti> micahg: it seems to me that 1.9.2 should conflicts:/replaces: 1.9.1, so that the old 1.9.1 package is cleaned up for everyone (not just eclipse users); WDYT?
<pitti> I wonder why this isn't done already
 * micahg forgot why we didn't do that...IIRC, we did it for karmic
<pitti> wouldn't users pile up xulrunner versions right now?
<micahg> apparently we didn't have a transitional package in karmic...
<micahg> pitti: yes
<micahg> pitti: yeah, it makes sense, I'll discuss with chrisccoulson_
<pitti> micahg: thanks; in this case we should reopen the xulrunner-1.9.2 tasks and close the eclipse ones
<micahg> pitti: well, the actual bug was fixed in xul192
<pitti> micahg: right; but we need a xulrunner task if we want to change/SRU that
<micahg> pitti: k
<dupondje> pitti: https://bugs.launchpad.net/ubuntu/+source/aegir-provision/+bug/543662 added debdiff :)
<ubottu> Launchpad bug 543662 in aegir-provision (Ubuntu Lucid) "Crashes due to wrong permissions of sudoers file." [Undecided,Triaged]
<pitti> dupondje: please get it uploaded
<dupondje> ah it first needs to get in maverick with ubunu1 tag ?
<pitti> dupondje: no, upload to lucid
<dupondje> i'll spam some motu :) don't have upload perms
<geser> pitti: I just sponsored dupondje ; it should be now in the SRU queue
<pitti> thanks
<ev> anyone mind giving a spot check of this patch to sphinxsearch that packages the library and language bindings? http://paste.ubuntu.com/464472/
<ev> http://paste.ubuntu.com/464475/ - updated; I failed to mention the build failure patch in the changelog
<cjwatson> zul: could you merge gpib?  you're the last uploader, and it's on my list of packages not merged since karmic
<zul> cjwatson: sure
<cjwatson> thanks
<cjwatson> StevenK: did you have a plan for hildon-desktop and libosso?  I seem to remember something going past on IRC
<StevenK> cjwatson: I had no plan, no
<seb128> cjwatson, I think pitti investigated those some days ago, he was speaking about them on IRC
<StevenK> To be brutally honest, we can probably lose the Ubuntu changes for both and just sync them
<cjwatson> StevenK: could you either file bugs for those or do it?
<cjwatson> I just want them off my list :-)
<StevenK> cjwatson: I still have privs, so I can JFDI if you wish
<cjwatson> that's fine by me
<cjwatson> that'll be down five today, out of 18
<seb128> getting there ;-)
<ScottK> cjwatson: Thanks for the stale merges initiative.  I think it's a very valuable exercise.
<StevenK> cjwatson: Synced, thanks for the prod.
<cjwatson> ScottK: I think we'll probably have to do it every cycle (except perhaps LTS cycles?)
<ScottK> It might be worth investing some time in automation then.
<seb128> cjwatson, is there so much value doing those? we have some desktop packages where we decided it's often not worh the work
<seb128> ie hours of work to not get any value changes
<seb128> valuable
<cjwatson> seb128: the threshold is that they haven't been done for well over a year
<cjwatson> seb128: I think it's reasonable enough to at least look at them by that point
<seb128> right, my comment was rather on about doing it every cycle
<cjwatson> well, the threshold would still be two cycles back from whenever we were doing it
<seb128> I'm wondering if we should claim that we stop merging that few sources
<cjwatson> something that people just don't bother with for one cycle don't register
<cjwatson> seb128: if you read the spec, it has several alternatives other than doing the merge
<cjwatson> I excluded anything in the sync-blacklist, for instance
<cjwatson> all I ask is that some active decision be taken, rather than simply letting it fester
<seb128> I've read your email, I guess I don't feel we never want to merge those again, it's just lot of work for little benefit so we tend to just not do it
<StevenK> cjwatson: While I'm actually on cocoplum, am I okay to NBS out -7?
<cjwatson> StevenK: leave it another day, please - CD builds failed today
 * StevenK removes a few NBS binaries, sadly, only 4 or so
<psurbhi> hie ! i can see in git://git.debian.org/debian-ha/redhat-cluster.git references to upstream? what is upstream location for this git?
<psurbhi> the ubuntu redhat-cluster package needs to be updated. The git patch for this update is huge
<psurbhi> so wanted to look at a possible smaller patch.
<didrocks> dholbach: "the audience even forgave him to try to make French the official language of Ubuntu Development." <- ahah :)
<dholbach> "ahah" :)
 * dholbach hugs didrocks
 * didrocks hugs dholbach back
<lool> pitti: Hey
<lool> pitti: Do you know why armel apparenlty misses .ddebs?
<pitti> lool: no, they're supposed to be there
<lool> pitti: For some reason, eglibc for instance is missing
<lool> pitti: How would I dive into the issue?
<pitti> hmm; /me looks
<pitti> lool: hm, not sure; everythign seems alright with ddeb-retriever, it does collect for armel
<pitti> http://ddebs.ubuntu.com/dists/maverick/main/binary-armel/Packages
<pitti> that seems quite complete
<pitti> ddebs@macquarie:/srv/ddebs.ubuntu.com/public_html/pool$ find -name '*_armel.ddeb'|wc -l
<pitti> 12845
<pitti> lool: so, not sure; must be bad luck with eglibc
<pitti> this stuff isn't very reliable
<lool> pitti: Hmm ok
<pitti> sometimes apache on the buildds hangs forever, and thus blocks the retriever for hours or days
<lool> Ah
<pitti> I guess the ultimate answer is "wait until we enable ddeb support in soyuz" :/
<asac> mterry_: poke bug 592640
<ubottu> Launchpad bug 592640 in avogadro (Ubuntu) "[MIR] avogadro" [Undecided,New] https://launchpad.net/bugs/592640
<mterry_> asac, getting to it.  I noticed it got removed from debian testing because of python2.6 issues...  i know we worked around them in ubuntu, but still
<asac> mterry_: so that one is stuck not because you are overloaded? e.g. does it mean you have slots for two or three more?
<asac> mterry_: i guess you like cloud stuff?
<mterry_> asac, heh.  I just worked through most of my mir queue.  I don't like this reward  :)
<mterry_> asac, I'm still working on avogadro, just wanted to finish investigation
<mterry_> asac, I could take more, if you're willing to suffer a delay to review
<asac> mterry_: ok. i will give you one more for today ;) ... and leave you alone for a week to give you air to breath ;)
<asac> mterry_: i think 1-2 weeks is ok (unless its blocking alpha3)
<JontheEchidna> avogadro is an optional build dep, but we shipped with avogadro support in the past when the library was part of kdeedu. So it won't block alpha 3 for it to not be in main, but is a priority to us to get in before final as to prevent a feature regression
<asac> JontheEchidna: lets not remove pressure from that MIR then ... just fix whatever mterry_ wants you to fix
<asac> :)
<JontheEchidna> :)
<mterry_> JontheEchidna, plus, I believe it was already promoted and the review is an after-the-fact deal
 * ogra wonders why calling reboot from an init-bottom initramfs script doesnt do anything
<LucidFox> Gah, so many magic numbers in Murrine
<cjwatson> chrisccoulson_: could you look at bug 601009?  I see you were the last uploader
<ubottu> Launchpad bug 601009 in swt-gtk (Ubuntu Maverick) "swt-gtk fails to build from source in maverick" [High,Confirmed] https://launchpad.net/bugs/601009
<chrisccoulson> cjwatson, yeah, will try and look at that later
<cjwatson> chrisccoulson: thanks, can I assign it to you?
<chrisccoulson> cjwatson, yeah, feel free to
<cjwatson> done, thanks
<bvleur> Anyone know where I can learn more about btrfsck output? I've got lots of lines ending in "errors 400", but I can't seem to find what that means
<cjwatson> bvleur: #btrfs is more likely to be able to give a good answer than here, I think
<bvleur> cjwatson: Thanks!
<dholbach> Last day of https://wiki.ubuntu.com/UbuntuDeveloperWeek starting in 33 minutes in #ubuntu-classroom
<dholbach> warp10, BlackZ: ready? :)
<BlackZ> dholbach: of course! \o
<dholbach> excellent
<jdstrand> cjwatson: hi! so, micahg just asked me to handle bug #605453
<ubottu> Launchpad bug 605453 in weave (Ubuntu) "Please add to the Mozilla Package Set" [Undecided,New] https://launchpad.net/bugs/605453
<jdstrand> cjwatson: he was told that AAs would be able to do this, but I don't know how and there isn't anything in ArchiveAdministration that I can see that deals with this
<jdstrand> cjwatson: a) is this something AAs should be doing and b) is there a wiki page describing the process?
<cjwatson> jdstrand: if they all look mozilla-ish to you, then that's fine; use an up-to-date lp:ubuntu-archive-tools, and ./edit_acl.py -P mozilla -S maverick -s foo -s bar -s baz ... add
<cjwatson> no docs for this that I'm aware of, sorry
<jdstrand> cjwatson: do you mind if I add it to the wiki?
<cjwatson> that's OK - just don't add permissions for *people* using that tool without the approval of the TB/DMB as appropriate
<cjwatson> in general assigning packages to package sets is much like assigning them to components in terms of privilege level, i.e. yes it's something AAs can and should be doing
<jdstrand> cjwatson: I'll be sure to mention that this is for established teams
<cjwatson> that wasn't quite what I meant
<cjwatson> but yes, I guess that's close enough :)
<jdstrand> yeah, I guess there could be individuals that already have access
<cjwatson> edit_acl.py can also grant a person access to a package set, and that sort of thing
<jdstrand> anyway, I'll add something about being careful
<jdstrand> k
<cjwatson> and there are also some permissions for individuals that it's OK to extend; for instance till-kamppeter has general approval to upload printing packages, although at present there's no package set for that since it's just him
<jdstrand> cjwatson: are these permissions that the TB has approved listed somewhere?
<jdstrand> I could refer to that
<cjwatson> jdstrand: probably not :-/
<jdstrand> k
<jdstrand> cjwatson: thanks for the info
<geser> jdstrand: I guess you should ask for a link to the minutes where it was approved if you want to be sure
<jdstrand> cjwatson: I added https://wiki.ubuntu.com/ArchiveAdministration#Adjusting%20Launchpad%20ACLs
<jdstrand> cjwatson: though, the command doesn't work for me:
<jdstrand> $ ./edit_acl.py -P mozilla -S maverick -s instantbird  addThere was an error:
<jdstrand> (<lp.soyuz.model.packageset.Packageset object at 0x2aaab6a60b10>, 'addSources', 'launchpad.Edit')
<jdstrand> that didn't paste right
<jdstrand> ./edit_acl.py -P mozilla -S maverick -s instantbird  add
<jdstrand> There was an error:
<jdstrand> (<lp.soyuz.model.packageset.Packageset object at 0x2aaab6a60b10>, 'addSources', 'launchpad.Edit')
<geser> IIRC only TB members can do it
<geser> bug #562451
<ubottu> Launchpad bug 562451 in Soyuz "developer-membership-board should be able to edit ArchivePermissionSet" [High,Triaged] https://launchpad.net/bugs/562451
<jdstrand> a
<jdstrand> h
<jdstrand> geser: ok, thanks
<jdstrand> wiki adjusted
<geser> jdstrand: I looked at the LP code and *if* I understood it correctly, then LP admins and the owner of a packageset can edit it. The owner of all (except two) package sets it the TB (the owner of the remaining two is DMB).
<jdstrand> interesting
<micahg> cjwatson: jdstrand was stopped by bug 562451, what should I do (if anything)?
<ubottu> Launchpad bug 562451 in Soyuz "developer-membership-board should be able to edit ArchivePermissionSet" [High,Triaged] https://launchpad.net/bugs/562451
<dieki> If a screenshot in the software center is out of date or incorrect, where do I report a bug? Against the package? Against the software center?
<JontheEchidna> dieki: submit a new one at screenshots.debian.net
<JontheEchidna> (this is where the screenshots come from)
<dieki> JontheEchindna: I did. Months ago. Nothing ever happened with it.
<dieki> It was for the package gimp, so I'm sure other people have submitted screenshots as well. However, the current screenshot still shows GIMP 2.4.
<dieki> JontheEchidna: Since that failed, what should I do next?
<JontheEchidna> wait, I guess
<JontheEchidna> filing a bug report won't really help, since we have just about as much controll over screenshots.debian.net as you do
<dieki> Okay.
<dieki> I wish Canonical/Ubuntu would handle screenshots themselves...
<maxwellian> Does anybody have a link to a good explanation of how fakeroot works?  I've read the part about wrapping standard library functions, but how does it keep track of the changes it's pretending to make?  Why do other utilities believe these changes took place?
<maxwellian> It seems like black magic to me.
<geser> jdstrand: if you agree that the request from bug 605453 is valid, I could try if being the owner of the package set is enough to edit it add those packages (the mozilla package set is owned by DMB)
<ubottu> Launchpad bug 605453 in weave (Ubuntu) "Please add to the Mozilla Package Set" [Undecided,New] https://launchpad.net/bugs/605453
<jdstrand> geser: I was fine with instantbird, nspluginwrapper and weave. the other three are all in universe, but it wasn't clear why they should be in the package set (gxine and mongodb build depends on xul, but mediatomb is unclear)
<chrisccoulson> jdstrand, mediatomb is using spidermonkey
<chrisccoulson> as are gxine and mongodb
<micahg> jdstrand: sorry, I should have specified more about those
<chrisccoulson> instantbird looks pretty neat
<jdstrand> does just using those packages mean that they should be in the mozilla package set? forgive me, but I am new to these acls
<hdon> hi all. i am using jaunty on x86_64 platform. apparently the glibc has gnu ifunc but the gdb does not. is there a repo somewhere that has the correct gdb? i cannot do simple things in gdb like: call strlen("test")
<micahg> jdstrand: I was trying to add stuff that I'd be likely to maintain
<chrisccoulson> jdstrand, that was the idea for this packageset (it would contain the packages that the mozillateam regularly touches)
<jdstrand> well, I can't actually do anything about it. geser can make the call on those, but I imagine he would like an email/wiki reference
<geser> micahg, jdstrand: Added weave, instantbird, nspluginwrapper (being owner of the package set works)
<micahg> geser: thanks, but what about the other ones ( the mozjs packages)?
<geser> checking what exactly got approved by the DMB and if those package match it
<jdstrand> geser: thanks for working on this :)
<micahg> geser: here's the package set if it helps: http://qa.ubuntuwire.com/multidistrotools/mozilla.html
<chrisccoulson> geser - things like gnome-shell and gjs have been approved (as an example of other spidermonkey applications)
<geser> micahg, chrisccoulson: sorry for being extra cautious, it's the first time I edit a package set. mongodb and gxine have a xulrunner-dev build-dependency => so they are ok (xulrunner rdepends). But where is the connection from mediatomb to xulrunner?
<micahg> geser: no problem, mediatomb js was disabled, but I was going to add it back since people wanted it
<geser> chrisccoulson, micahg: added the three other too
<micahg> geser: awesome :) thank you very much
<chrisccoulson> thanks geser :)
<micahg> jdstrand: thanks to you too
<jdstrand> geser: thanks
<geser> cjwatson: adding packages to the mozilla package set is done
<micahg> geser: how should I go about these requests in the future?
<geser> micahg: good question, I don't think there is process for it yet. But filing a bug looks good, subscribe the DMB to it (as the DMB is owner of the Mozilla package set and can edit it) and poke a DMB member (I don't believe the DMB looks at bugs regularly yet)
<micahg> geser: ok
<micahg> geser: I was also wondering if the package set could be allowed for Lucid
<geser> micahg: don't know, perhaps cjwatson can answer that
<cjwatson> jdstrand: hm, drat, I thought you had access but obviously not
<geser> in any case, the owner of a package set can edit it, but only TB members can create them
<cjwatson> geser: thanks for handling that
<micahg> cjwatson: I was wondering if the package set could be allowed for Lucid
<cjwatson> micahg: I haven't generally been doing them for stable releases, no, because it takes ages to sync everything up and stable uploads require special approval anyway
<micahg> cjwatson: ok, thanks
<cjwatson> each series has a different instance of the package set ... this is necessary, but it does mean things are painful to do retroactively
 * achiang can't seem to wrap his head around GRUB_HIDDEN_TIMEOUT and GRUB_TIMEOUT
<achiang> if the former=10, and the latter=10, my impression was that the menu is supposed to be hidden for 10 seconds, and then we boot into whatever the default menu option was
<achiang> other documentation makes it seem like the only way to turn off the menu is to set GRUB_TIMEOUT=0
 * ccheney forgot the syntax to push a branched bzr repo to his own area on lp
<ccheney> anyone happen to know where to point me?
<ccheney> i thought it was something like: bzr push lp:~ccheney/+branches/uec-provisioning  but that appears to not be quite right
<ccheney> ah managed to get bzr to tell me
<ccheney> bzr push lp:~ccheney/uec-provisioning/branch
#ubuntu-devel 2010-07-17
<dCrim> Hey.
<dCrim> Does anyone know why the insight GDB GUI disappeared?
<wgrant> I'm confused.
<wgrant> I'm sure I've seen two 2700-build Python 2.7 rebuilds use up days of build farm time.
<wgrant> But neither PPA exists any more.
<Sarvatt> looks like theres a fourth starting up now.. https://edge.launchpad.net/~pythoneers/+archive/py27stack4
<soren> You must be kidding.
<soren> Dear god, no.
<Sarvatt> guess that explains the 3-4 day queues for the past week
<soren> I see the PPA, but the build queue hasn't exploded yet.
<soren> 1233 jobs is as good as it's been all week.
<wgrant> At least we're heading for an empty queue in the next 48 hours.
<wgrant> Possibly 24, depending on how things go, but I'm not holding my breath.
<wgrant> Although given the recent track record, there will probably be an archive rebuild and three Python rebuilds starting on Monday....
<wgrant> And a day into that, 90% of the builders will disappear for 24 hours.
<Sarvatt> i'm guessing it's just calmed down because they need to wait for the early deps to build too before they dump the other 1500 packages in the PPA :)
<wgrant> Sarvatt: Ah, fair point.
<wgrant> I must convince people at some point that we need a better queue discipline.
<Sarvatt> cjwatson: how recently did gfxpayload=keep get re-added to grub? I'm noticing widescale bustage on all KMS configurations today without something like vesafb=sucks getting added to make it not load or dropping it
<SandGorgon> hey guys.. if new symbols are being included into the Unicode character map - is it possible to update the character map of an install ? or does it come implicitly with a Pango update ?
<cjwatson> Sarvatt: I posted to ubuntu-devel about it
<cjwatson> Sarvatt: this time, I want to debug these problems rather than just ignoring them
<cjwatson> Sarvatt: what kind of problems are we talking about?
<achiang> hm.
<achiang> GRUB_TIMEOUT=0 ; GRUB_HIDDEN_TIMEOUT=10
<achiang> i hit the shift key during boot, and i see GRUB Loading. but no menu
<achiang> is that expected behavior?
<achiang> cjwatson: ^^
<cjwatson> pretty sure you need a positive GRUB_TIMEOUT to see the menu.
<achiang> hm
<achiang> i really want the menu to be hidden, unless i press a key so i can do some debugging
<achiang> maybe that's not possible
<cjwatson> GRUB_TIMEOUT=<positive> doesn't unconditionally show the menu
<cjwatson> if no key is pressed during the GRUB_HIDDEN_TIMEOUT phase then it won't show
<achiang> alright, i'll try that, thanks
<Sarvatt> cjohnston: have you not booted twice using KMS since updating it? I've got 6 machines all broken the same way and have been getting a bunch of reports of it in #ubuntu-x. plymouth dies like this - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/606393 and on intel X wont start at all unless you press escape to switch away from the broken splash before it starts, on my nouveau machines its not loading the modules until after X start
<Sarvatt> s since there's already another framebuffer device i'm guessing and having the ddx load the module doesn't actually work
<ubottu> Launchpad bug 606393 in linux (Ubuntu) "BUG: unable to handle kernel NULL pointer dereference at 00000000000003c0" [Undecided,New]
<Sarvatt> sorry, cjwatson :)
<cjwatson> Sarvatt: yes, I have
<cjwatson> Sarvatt: works fine on my system
<achiang> cjwatson: should i be seeing a blinking cursor when the menu is hidden though?
<cjwatson> Sarvatt: there are some kernel bugs which we definitely need to shake out, but if I just leave gfxpayload=text then we'll never get rid of them
 * Sarvatt nods
<achiang> cjwatson: i also have GRUB_GFXMODE=640x480
<cjwatson> achiang: we don't manage to turn it off quite everywhere yet
<cjwatson> achiang: so right now, yes, that's expected behaviour
<cjwatson> it's not how I ultimately want it to be
<achiang> cjwatson: was that possible with grub1?
<cjwatson> achiang: I've purged my memories of grub1
<achiang> heh.
<Sarvatt> the intel ones that dont work are odd
<Sarvatt> [    3.075685] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
<Sarvatt> [    3.075722] Console: switching to colour dummy device 80x25
<Sarvatt> [    3.528337] Console: switching to colour frame buffer device 128x37
<cjwatson> achiang: grub2 does try to turn off the cursor - grep for grub_term_setcursor
<achiang> cjwatson: thanks
<cjwatson> Sarvatt: my working system shows that too
<cjwatson> that just means the KMS driver is replacing vesafb
<Sarvatt> the screen stays blank after that, and I can't do anything but use sysrq
<Sarvatt> well, it goes grub - vesa fb (i see splash here at 640x480) - screen turns off, turns back on with a blank black screen - stuck unless I press escape fast enough before X starts
<cjwatson> that means that the KMS driver is failing to go VESA->native.  Matthew Garrett did warn us that it was likely that that would happen in some cases, although said it was still worth us giving it a try
<cjwatson> we need to be figuring out how to upstream those bugs effectively
<Sarvatt> i think udev might need some fixing to not assume vesafb means the actual graphics device modules were added too, since when it does kind of work (nouveau) it doesn't even try to load nouveau before X starts and the DDX ends up loading it every time here
<cjwatson> Sarvatt: no reason for that to be in udev; any such interpretation of udev events belongs in higher layers IMO
<cjwatson> Sarvatt: and then, it's necessary to think about how this ties in with splash screen requirements in https://blueprints.launchpad.net/ubuntu/+spec/foundations-m-grub2-boot-framebuffer
<Sarvatt> so you want xf86LoadKernelModule() to actually work? if you build all the agp modules into the kernel it *might* but that's still going to be a nightmare of racyness
<Sarvatt> outside of intel that always uses intel_agp theres no way to ensure the platform agp driver gets loaded before drm which is required otherwise since drm can't depend on the platform agp modules, there are all kinds of bugs about that one. we're probably the only distro not building those into the kernel now and its expected for them to be unable to be built as modules soon
<cjwatson> Sarvatt: I don't understand how you got there from what I said
<Sarvatt> letting x load the video modules pretty much guarantees drm won't work the first start after boot
<cjwatson> but that wasn't what I said.
<tjaalton> Sarvatt: iirc airlied wanted to make the modules mandatory in the kernel
<Sarvatt> ah sorry, what do you mean by higher layers then?
<cjwatson> upstart
<cjwatson> or upstart jobs, more accurately
<cjwatson> if you special-case it in udev then you can't deal with machines that only have vesafb
<Sarvatt> gotcha, sorry, I thought you meant you wanted X to load them like is happening now
<cjwatson> not at all
<cjwatson> or rather, I don't have the necessary expertise to offer an opinion either way there
<cjwatson> have our kernel team given a reason for building agp modular, or is it something that hasn't come up?
<Sarvatt> never gotten an answer outside of not wanting to build things in that could be modular, i've brought it up on the list and in bugs a bunch of times but couldn't make it to UDS to discuss it there
<Sarvatt> just curious, what gpu do you have that works?
<Sarvatt> it worked with efifb before too unlike all of mine
<cjwatson> intel
<cjwatson> mjg59 was very clear that we must not use efifb
<cjwatson> (on non-EFI systems, anyway)
<cjwatson> sorry, specifically a GM965, specifically 8086:2a02 rev 0c
<cjwatson> I've only had a relatively small number of regression reports so far; before you, most of them were on Radeon cards
<Sarvatt> thanks, was wondering because you didn't have problems last time with the gfxpayload=keep either. i don't have anything with a GMA x3100/GL960 like yours
<Sarvatt> the bugs are getting filed against x since it isn't starting up is probably why, I just saw your post and will try to move things over to grub2 as I see them
<cjwatson> no!
<cjwatson> they're not grub2 bugs.  the kernel needs to fix them, aiui
<cjwatson> if you reassign them to grub2 I'll just have to reassign them away again. :)
<Sarvatt> alrighty :) well here's one - https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/606244
<ubottu> Launchpad bug 606244 in linux (Ubuntu) "X doesn't find a screen and is not starting due a race condition" [High,Confirmed]
<cjwatson> I suggested that people file new bugs on grub2 so that I can look them over, but if they're already filed somewhere appropriate then reassigning them to grub2 is a waste of effort
<cjwatson> maybe tag them grub-gfxpayload or something
<Sarvatt> will do
<rsavoye> slacker_nl: the sources for brasero in bzr don't match the same sources I get with apt-get
<rsavoye> oops, slangasek  the sources for brasero in bzr don't match the same sources I get with apt-get
<rsavoye> silly tab completion...
<rsavoye> slangasek: also the axis2c in bzr appears to also be out of sync with the source tarball
<dupondje> anyone noted that grub2 isn't counting down sometimes ?!
<SevenMachines> dupondje: i think i get this the next boot after going to recovery mode
<SevenMachines> i didnt check, i just thought about it in passing
<dupondje> it could be after a unclean shutdown also it seems indeed
<SevenMachines> it could have been that, that might of been why i booted into recovery :)
<dupondje> lets hope https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606244 is fixed asap :) most crappy bug atm :)
<ubottu> Launchpad bug 606244 in linux (Ubuntu) "X doesn't find a screen and is not starting due a race condition" [High,Confirmed]
<SevenMachines> luckily/sadly, its all quite boring over here. you wouldnt notice it was in development if it wasnt for the host of updates every day
<SevenMachines> though i may have just cursed things by saying that out loud :)
<dupondje> well its the first real bug I noted since dev of maverick started :)
<SevenMachines> X crashes are fun :)
<SevenMachines> well, now i've finally found a working sasl plugin for xchat.... i'm off for the weekend!
<maxwellian> Can anyone tell me how to add a .desktop file to a package?  The packaging guide tells me where it should end up, but I don't know how to get it there.
<maxwellian> Errr, sorry, I think this is the wrong channel.  Going to -motu.
<shadeslayer> maxwellian: uh.. make a patch?
<maxwellian> Oh, sweet.
<shadeslayer> not sure .. but thats i would do
<maxwellian> shadeslayer: Well before you make a patch, you change something that patch can report...right? :)
<shadeslayer> there might be some debhelper magic that lets you put files in debian/ and then carry ot over
<shadeslayer> maxwellian: not necessarily ;)
<shadeslayer> oh.. i think
<nigelb> maxwellian: you want to know how to create a new .desktop file?
<shadeslayer> maxwellian: what can also be done is to make a file in debian/ and then add a cp command to rules
<maxwellian> nigelb: Yes.  I have the file, I just want to add it to the package so it gets installed.
<maxwellian> shadeslayer: I've seen that done, but the rules file as it stands is very terse.  I'm new to packaging, but most of the stuff seems to be handled automatically CDBS.
<nigelb> sheslayer, who just turned evil, guided you right
<nigelb> *shadeslayer
 * maxwellian trembles
<evilshadeslayer> muwhahaha :D
<maxwellian> This is the current rules file: http://paste.ubuntu.com/465111/
<maxwellian> It doesn't say anything about the install process, just after installing.  I guess the rest is implied somehow.
<maxwellian> Ack, sorry, there were a couple of includes at the top as well.
<Amaranth> maxwellian: stick a `mkdir -p debian/plt-scheme/usr/share/applications && cp debian/foo.desktop debian/plt-scheme/usr/share/applications` in the binary-post-install/plt-scheme:: section
<Amaranth> maxwellian: or a similar binary-post-install section for whatever package needs the .desktop file
 * evilshadeslayer was about to say taht
<Amaranth> I wonder why they remove the files then remove the directory instead of just doing rm -rf
<maxwellian> Wow, a consensus even. :)  Okay, great, thanks.  I'm a noob and it's hard to figure out how to go from the simple examples in the packaging guide to dealing with real packages.
<maxwellian> Amaranth: Dunno.  This would be the third time that a .desktop file has been added to this package, so something screwy is going on somewhere. :P
<cjwatson> cdbs' greatest weakness is that it's hard to see how to extend it, and the syntax for extensions isn't particularly regular
<Amaranth> cjwatson: dh 7 has the same problem
<Amaranth> It sure does make things simple when you know how it works though
<cjwatson> Amaranth: it does not have the latter problem.  The syntax for extensions is regular
<maxwellian> cjwatson: When you say "extensions" you mean something beyond daily use, right?
<Amaranth> Oh, right, I meant how to extend it
<cjwatson> maxwellian: I mean things like binary-post-install/* rule
<cjwatson> s
<Amaranth> It's hard to figure out how to go from a one line makefile that does everything to something useful :)
<cjwatson> there's some documentation in /usr/share/doc/cdbs/cdbs-doc.html
<maxwellian> Amaranth: Exactly!!
<maxwellian> cjwatson: Thanks, I will check that out.
<maxwellian> cjwatson: So it's not faux pas to do more install stuff in the "post-install" section? :P
<cjwatson> cf. http://kitenet.net/~joey/talks/debhelper/debhelper-slides.pdf
<cjwatson> maxwellian: why not just put 'debian/foo.desktop usr/share/applications' in debian/foo.install?  that's more idiomatic
<maxwellian> cjwatson: Yes, that kind of idiom to add a file is something I've seen, but then there were several other lines that only had one path in them.
<maxwellian> cjwatson: Like /usr/bin
<cjwatson> man dh_install
<cjwatson> for the syntax of that file
<cjwatson> similarly man dh_installdirs for the syntax of debian/*.dirs, etc.
<cjwatson> 'man debhelper' has an index
<cjwatson> Amaranth: (appendix B of that slide deck is what I'm referring to, in particular)
<Amaranth> Wow, I forgot all about the .install file trick
<maxwellian> cjwatson: Yeah, I've read the man page for dh_install, but it says that each line contains a file or files to install, and where to install them.
<Amaranth> Too much magic :)
<maxwellian> cjwatson: But then the example simply list destination paths, without specifying what goes there.
<cjwatson> maxwellian: read the section under --autodest
<Amaranth> maxwellian: If you stick /usr/bin in there it'll include everything the package wants to install to /usr/bin
<nigelb> g33
<nigelb> grr
<cjwatson> (including the last sentence, which applies even if that option isn't given)
<maxwellian> Amaranth: Unless I'm reading the page wrong, it's saying that /usr/bin would be the source file, and that it's destination would be automatically determined.
<Amaranth> Wow, someone needs to turn that slide deck in to a wiki page for documentation
<Amaranth> maxwellian: Eh, I forget, haven't looked in a while
<Amaranth> maxwellian: That's probably right
<vish> Amaranth: hi, got a min to review an alacarte patch?
<maxwellian> Amaranth: Thanks though.  I shouldn't have taken so much time in here, but when so much is done automatically it's hard to figure out where the magic is happening and how to change something. :P
<Amaranth> vish: It's not really maintained anymore, I think someone else was taking over on the GNOME side for a while
<Amaranth> vish: If you mean to add to the ubuntu package you'll want to talk to the folks on the desktop team
<vish> Amaranth: oh , ok..
<Amaranth> vish: Although if I was maintaining it and the patch adds UI I'd reject it :)
<cjwatson> Amaranth: it's basically all in the man pages
<vish> Amaranth: not UI , the drag n drop: https://bugzilla.gnome.org/show_bug.cgi?id=608221
<ubottu> Gnome bug 608221 in general "Drag-and-drop of items downwards is off by one" [Minor,Unconfirmed]
<Amaranth> vish: GNOME 3.0 won't include alacarte so it's not really important anyway
<vish> Amaranth: hmm , the patch is on LP too.. not sure what to do with it.. Bug #395692 , seb128 is the best person to decide?
<ubottu> Launchpad bug 395692 in alacarte (Ubuntu) "Drag-and-Drop behavior in the menu editor is inconsistent and confusing" [Low,Triaged] https://launchpad.net/bugs/395692
<Amaranth> vish: yeah, see if seb128 will add it to the ubuntu package
<dupondje> cjwatson: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/606244 seems like caused by grub2 video mode setting?
<ubottu> Launchpad bug 606244 in linux (Ubuntu) "X doesn't find a screen and is not starting due a race condition" [High,Confirmed]
<vish> Amaranth: could you make a comment about that.. I'll talk to seb128 , else its tough to catch you again ;)
<Amaranth> vish: I don't even remember what that code was doing
<maxwellian> cjwatson: Is there a way besides building the whole package to test if the .desktop file gets installed properly?  This build on my machine is taking a couple of hours. :\  (I'm just hoping against hope there's a better way.)
<cjwatson> maxwellian: if you've already got to the end of the build, you can rerun individual debhelper commands with DH_VERBOSE=1
<cjwatson> so DH_VERBOSE=1 dh_install # or whatever
<maxwellian> cjwatson: So that would just try the install part, and I could see if the file ended up where it should?
<cjwatson> dupondje: already had a discussion with Sarvatt about that earlier today - grub2 video mode setting is the proximate cause, yes, although it's still a kernel bug
<cjwatson> maxwellian: right
<maxwellian> cjwatson: Awesome, thanks for your time.
<cjwatson> with DH_VERBOSE=1 it'll echo the commands it runs
<maxwellian> cjwatson: Right, good for debugging.
<vish> Amaranth: cool , alteast a comment that it aint maintained upstream would do.. :)
<cjwatson> in fact, when you're working on this kind of thing, it's often useful to just do a full build under DH_VERBOSE=1, and then you can retroactively inspect the whole log
<dupondje> cjwatson: hÃ©hÃ© ok :) thx for the info
<cjwatson> if you're making several changes
<maxwellian> cjwatson: Yes, that would have been a good idea.  Help me to get a sense of all the magic being done for me automatically!
<cjwatson> I used that when converting grub2 from CDBS to dh recently
<cjwatson> that was quite a difficult conversion job
<maxwellian> cjwatson: I don't doubt it.  It seems to me that CDBS is using debhelper in this case, but I don't know.
<cjwatson> yes
<cjwatson> CDBS is a system of Makefile fragments wrapping debhelper
<maxwellian> cjwatson: So the conversion to debhelper means...unwrapping it?
<cjwatson> what I'm loosely referring to as "dh" is a system with similar expressive power to CDBS built into newer versions of debhelper
<cjwatson> man dh
<cjwatson> essentially trying to replicate the good bits of CDBS while avoiding at least some of its design flaws
<maxwellian> cjwatson: Oh, sorry...I thought that was just an abbreviation for all of the dh_* commands.
<cjwatson> anyway, this isn't terribly relevant to you if you're just extending an existing CDBS package
<hyperair> cjwatson: i think dh7 is the more commonly used term, to avoid confusion.
<maxwellian> cjwatson: It's very relevant to me, since I would like to be competent at working with packages in general at some point.  Again, thanks a lot for your time, it saves me a lot of head scratching.
<cjwatson> hyperair: also confusable with debhelper 7 in general, unfortunately
<cjwatson> I guess dh(1) is unambiguous
<hyperair> maxwellian: most (including me) would recommend using dh7 over cdbs, considering how poor cdbs documentation is that you'll need a high level of make-fu and the ability to read CDBS's makefile fragments while maintaining sanity.
<cjwatson> also dh(1) use is growing more or less linearly right now while cdbs use is stagnant
<hyperair> cjwatson: but dh(1) is the single most prominent feature of debhelper 7, so it's almost certain that you're referring to that feature when you say dh7. =p
<cjwatson> mm
<slangasek> rsavoye: neither axis2c nor brasero are in the import failure list; which bzr branch are you grabbing, and which release are you downloading from with apt-get source?
#ubuntu-devel 2010-07-18
<preet> I'm having trouble trying to talk to a device through an FTDI USB-to-Serial connector. I've tried talking to the device through various packages, but only one, which uses a Java serial comm library works. I read there was a semi-recent fix for FTDI drivers [http://www.spinics.net/lists/stable-commits/msg07180.html]. I'm trying to figure out whether the problem that I'm experiencing is related to the aforementioned bug or I'm doing 
<preet> Or does this question belong in app-devel?
<kitallis> I get a couchdb.client.ServerError: (500, '')
<kitallis> while trying to run gwibber on lucid?
<kitallis> ok, nvm, deleted a buncha cache files and it works
 * slangasek trawls for LOSAs
<mantiena-baltix> Hi all
<mantiena-baltix> It seems there are some problems with Ubuntu 10.04.1 daily builds - there are no new daily-live images since yesterday, see http://cdimage.ubuntu.com/lucid/daily-live/
<mantiena-baltix> Maybe someone can tell me where I should report issue about missing lucid daily-live cdimages?
<jml> RAOF, http://mitpress.mit.edu/catalog/item/default.asp?ttype=2&tid=12156
<RAOF> Hah.
<RAOF> jml: Wireless exists downstairs.
<jml> RAOF, will join you in a second.
<cjwatson> mantiena-baltix: it's just due to language packs being mid-processing, it'll resolve itself
<cjwatson> mantiena-baltix: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/lucid/ubuntu/20100718/livecd-20100718-i386.out
<mantiena-baltix> cjwatson: thanks for info
#ubuntu-devel 2011-07-11
<RAOF> Is there a work-around for the sbuild breakage?
<ScottK> Use pbuilder?
<ScottK> AFAIK pbuilder works, you just can't create a brand new chroot now.
<ScottK> (You could be able to make one in natty and upgrade it)
<RAOF> I think I'll defer that work until sbuild has been broken for longer :)
<RAOF> Oh, hey.  Look!  A natty-proposed queue.
<TheMuso> RAOF: Yeah hit the same thing myself.
<RAOF> Yeah, I saw.  Which is why I'd hoped someone mighmt have magically fixed it for me :)
<pook1e> can anyone here help me with a pbuilder dependency?
<lifeless> !ask | pook1e
<ubottu> pook1e: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-)
<pook1e> i'm trying to build indicator-network with pbuilder, but it's telling me pbuilder-statisfydepends-dummy depends on libnotify-dev (>= 0.7.0), but i have 0.5.0-2ubuntu1 installed, and so pbuilder-satisfydepends fails
<pook1e> does anyone know how i can fix this?
<pook1e> ls
<mwhudson> pook1e: which series are you trying to build for?
<micahg> that's libnotify from natty
<micahg> or maverick for that matter
<pook1e> how can i get the newest version?
<pook1e> i used --extrapackages libnotify-dev when i was creating
<TheMuso> t/c
<RAOF> pook1e: Unless you're building for oneiric the version of libnotify-dev is insufficient to satisfy that dependency.
<pook1e> I'm trying to build for natty.
<RAOF> Then that won't work unless you backport libnotify.
<RAOF> (At least)
<pook1e> How can I do that?
<pook1e> I'm creating my pbuilder environment with pbuilder-dist natty create --extrapackages libnotify-dev
<RAOF> What is your actual goal here?
<pook1e> I'm fixing a bug in indicator-network
<pook1e> And now I'm trying to build the modified version to test it out.
<RAOF> Then you probably need to test it on oneiric; I think the indicator stack is sufficiently different to make backporting stuff to natty and testing there not very worthwhile.
<RAOF> It should be easy enough to set up oneiric in a VM if you don't want to install it bare-metal.
<pook1e> So pbuilder-dist oneiric create --extrapackages libnotify-dev, then pbuilder-dist oneiric build?
<RAOF> You don't need the --extrapackages; pbuilder will automatically install the build-depends for you.
<RAOF> Apart from that, yes.
<pook1e> Alright, I'll try that out.
<pook1e> Thanks for your help RAOF, much appreciated.
<mwhudson> maybe this is a crazy question
<mwhudson> but if i require a package to be able to run debian/rules clean
<mwhudson> is there some way i can build it in pbuilder?
<RAOF> mwhudson: You can pass --extrapackages to pbuilder.  Isn't that a packaging bug, though?
<RAOF> Oh, or do you want to build a *source* package from the current tree, and can't install that package?
<mwhudson> RAOF: yes, debuild -S is failing
<RAOF> Hawkward.
<mwhudson> also with an extra p
<mwhudson> (well, i just installed the package, in this case)
<mwhudson> but i was wondering more generally
<RAOF> There's no technical limitation on that as far as I'm aware, but I've never really wanted it so I haven't investigated whether it's implemented at all; I'd guess the answer is ânoâ
<StevenK> mwhudson: You can run pbuilder login, install packages there and run debuild -S inside the chroot
<mwhudson> StevenK: ah yeah, i guess that works
<mwhudson> (kinda what building recipes does on lp)
<StevenK> Hacky, but some packages require it
<mwhudson> after a mere 4 and a bit years at canonical, i'm finally learning stuff about packaging :)
<StevenK> mwhudson: Plenty of people in your timezone who are happy to help :-)
<ajmitch> plenty of people even in your loco channel who can help out :)
<mwhudson> well, if you guys could just stop inventing new ways to package python projects.....
<ajmitch> this is the last change, honest...
<StevenK> Haha
<mwhudson> (and/or backport dh_python2 to lucid)
<mwhudson> i suppose waiting for the next LTS is the lazy way to make that problem go away
<ajmitch> I think that had been done somewhere, just not in lucid-backports
<ScottK> mwhudson: I think barry is supposed to do that.
<ScottK> ajmitch: If there's a good backport done, I'd be glad to have it in lucid-backports, I just don't care to do the work to package it myself.
<ajmitch> the main problem is more the number of things it could potentially break
<lifeless> + pkgme
<ScottK> Shouldn/t
<ScottK> It should only affect stuff that's build with it, so that's limited to -backports
<ScottK> lifeless: +stdeb
<lifeless> indeed
<lifeless> and there is a python make-deb thing as well upstream
<ScottK> That's different then stdeb?
<ScottK> Automatic packaging of python stuff seemed like a really odd problem for pkgme to take on since it was already solved about as well as it could be with automation, IMO.
<pitti_> Good morning
<TheMuso> pitti: Do you have powers to re-enable cd image builds? Seems they are still disabled after the alpha 2 release.
<pitti> TheMuso: they are enabled, but have failed to build ever since due to libc6
<pitti> i. e. debootstrap failure
<TheMuso> oh ok
<infinity> I need to do some image mangling this week, so if debootstrap remains sad, I might do something about it.
<infinity> (Happy to heave others beat me to it)
<infinity> s/heave/have/
<rsalveti> pitti: infinity: 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
<pitti> rsalveti: thanks
<rsalveti> pitti: if you just enable var/run and var/lock at base-files it works fine again
<rsalveti> pitti: https://code.launchpad.net/~rsalveti/ubuntu/oneiric/base-files/run-transition/+merge/67444
<rsalveti> but then don't know exactly why this was removed
<pitti> it's /run/ now
<rsalveti> and how ubuntu is supposed to deal with /var/run
<pitti> so I guess something in eglibc needs to be updated
<rsalveti> pitti: I know, but why remove the directory?
<pitti> /var/run/ should presumably become a symlink now?
<rsalveti> pitti: not only eglibc, but I guess we have similar packages at the archive
<rsalveti> pitti: should be a bind mount
<rsalveti> at least this is how fedora is doing
<pitti> I still have /var/run/ here, but this is an upgrade
<rsalveti> to have a bind mount, it makes sense to have the directory there
<pitti> either way
<rsalveti> so that's why for me it's wrong to just remove it from base-files
<rsalveti> as it's going to be bind mounted later
<rsalveti> but yes, the libc6 package is also wrong
<Chipzz> rsalveti: maybe that's just the slightly sadistic side of me speaking, but on the bright side, having the dir missing will make a lot of software that yet needs to be fixed show up, and bugs can be filed
<pitti> but for the final release we'll have a /var/run/ either way
<pitti> we can't break the world in just one cycle
<slangasek> moreover, /run is not a standard (yet) - things that don't have a strict need for writing during early boot shouldn't be forced to switch yet
<slangasek> the missing /var/run is a bug, plain and simple
<rsalveti> slangasek: shouldn't /var/run be a bind mount of /run?
<rsalveti> like fedora is doing
<rsalveti> instead of a syslink?
<Chipzz> hrrrm, s/having the dir missing/having the dir missing for a couple of days/ ...
<slangasek> rsalveti: that's an implementation detail
<rsalveti> but easier to do the transition, I believe
<Chipzz> slangasek: but since it's a bind mount you might as well make everything write to /run
<slangasek> easiest is to follow Debian's lead on this; the transition has already been done in unstable
<slangasek> Chipzz: no
<Chipzz> I see little point in having 2 dirs with the same purpose
<slangasek> the FHS governs where things are supposed to write, and until there's a new FHS with clear and consistent guidance for the use of /run vs. /var/run, anything that uses /var/run today should be staying there
<rsalveti> yeah, agree
<buxy> Are there known kernel problems that could result in #807619 ? It's really weird
<dholbach> good morning
<Satoris> What package do I need to install to get the "bzr mu" command?
<nigelb> Satoris: er, what does it do?
<Satoris> It's used to update packaging when a new source release happens.
<nigelb> probably bzr-buildeb I think
<Satoris> That did it. Thanks.
<nigelb> :)
<sladen> slangasek: thanks for the icons.  Was that your doing? (Should I cancel the RT?)
<slangasek> sladen: yes, I updated them; cdimage.u.c / releases.u.c contents are managed by the Ubuntu team, not by IS
<Amoz> dholbach, morning!
<dholbach> hey Amoz
<panda|ac100> dholbach: ow
<dholbach> hi panda|ac100
<Amoz> is it appropriate to attach a patch to a bug in the reportbug utility?
<Amoz> I'm trying to send a bugreport and fix upstreams.. and I'm kind of lost
<Quintasan> cjwatson: ping
<cjwatson> Quintasan: yes?  (best to include content with your pings to save on round-trips)
<Quintasan> cjwatson: Oh, sorry for that. I was wondering if kde-baseapps is in kubuntu packageset since I still can't upload it (I am a Kubuntu Developer), is there any way I can check this without bothering you?
<cjwatson> Quintasan: ScottK was due to give me a list of stuff to fix
<cjwatson> Quintasan: lp:ubuntu-archive-tools, the edit_acl.py program there can answer queries like this
<Quintasan> cjwatson: Thanks, if it's okay with you I think I can complete this list instead of having ScottK do it
<cjwatson> Quintasan: sure - see http://irclogs.ubuntu.com/2011/07/09/%23ubuntu-devel.html#t21:24
<cjwatson> Quintasan: I've kicked an auto-update now, which should help too (though it didn't touch kde-baseapps)
<seb128> cjwatson, hey, just a question following the other day when I asked if you did autosyncs, during other cycles we used to have an email on u-d or u-d-a saying that the freeze is in effect, do you know if those are supposed to be announced?
<nigelb> aa
<nigelb> ~/
<nigelb> ~/
<nigelb> err, sorry for the spam
<seb128> cjwatson, it was somewhat useful for me since I don't know the cycle calendar in details and don't always think to go and check there
<seb128> I guess the reminder was useful for others as well
<Quintasan> cjwatson: http://paste.kde.org/94267/ -> Here is what I got is missing, I will give you some more later since I assume you can't add non-existing packages yet to packageset
<cjwatson> seb128: I guess we should have done, seems a bit late now though
<seb128> cjwatson, ok
<cjwatson> Quintasan: your assumption is correct, yes
<seb128> (well at least I know we are in DIF now which I didn't realize before you said it ;-)
<cjwatson> Quintasan: what previous packages do those replace?
<Quintasan> cjwatson: kde-workspace would replace kdebase-workspace
<Quintasan> kde-runtime replaces kdebase-runtime
<Quintasan> kate was orginally a part of kdesdk
<Quintasan> kwordquiz was a part of kdeedu (now separate source package)
<cjwatson> kwordquiz was already in the package set (I think I only just added it though)
<cjwatson> done the rest, thanks
<Quintasan> cjwatson: Thanks
<mvo> apachelogger: I'm just looking at your dbusworker software-properties stuff and I would like to work on this a bit, I noticed you use "slip.dbus" - what packages does provide that?
<Amoz> dholbach, I've done some more markup stuff on the UPG
<dholbach> Amoz, oh nice!
<apachelogger> mvo: I think we did not have it packaged when I worked on it
<dholbach> Amoz, sorry, I didn't get around to having a look at it, I just became too busy - today I won't have time for this either :-/
<apachelogger> it's some redhat polkit helper IIRC
<Amoz> dholbach, no worries
<mvo> apachelogger: aha, ok. would you mind if I leave it out for now then in my branch?
<apachelogger> nope
<dholbach> Amoz, do you think you can push to   lp:~fougner/ubuntu-packaging-guide/retheming  and propose a merge when you're happy with it?
<dholbach> Amoz, that'll give everybody a chance to have a look at it and comment
<mvo> thanks!
<dholbach> Amoz, I'll make sure I'll add all the boring bits (links to where everything is from, explain what was the actual changes and what was borrowed from somewhere else)
<Amoz> dholbach, I'm not happy with it but...
<dholbach> Amoz, it'll be a work-in-progress
<dholbach> and give others a chance to help out and make it even prettier
<dholbach> it's a GREAT start already
<Amoz> dholbach, uhm, the branch is stacking on my "old" branch, does it matter?
<dholbach> Amoz, no, that should be fine
<Amoz> dholbach, well in that case it's up and kicking
<dholbach> fantastic
<dholbach> did you propose it for a merge?
<Amoz> oh
<Amoz> I will
<Amoz> dholbach, proposed
<dholbach> awesome
<dholbach> it should be in my inbox soon and I'll do my best to tend to it soon
<Daviey> talking of email, is thunderbird in a bad way for everyone else?
<dholbach> Daviey, it's fine for me
<dholbach> Daviey, oh, I assume you're talking oneiric - I still use it in a vm, ignore me :)
<Amoz> cool, will the new theme be showing at your ppl.ubuntu.com site then?
<davmor2> dholbach: so no shrinking filters window that is un-resizeable or 186% cpu usage then?
<dholbach> Amoz, that's the plan once it's merged - also once it looks good and works nicely for all of us, we'll move it to a more official home
<dholbach> davmor2, at least not on natty - no idea about oneiric
<Amoz> nice
<davmor2> dholbach: no in natty I get none of that behaviour when I've tested it, only on my oneiric test box
<dholbach> davmor2, ignore me then :)
<davmor2> which is admittedly my old netbook
<Amoz> mmm..I wonder if the new asus u36jc plays well with ubuntu..
<lifeless> mvo: sbeattie: btw, conflict-checker seems rather unhappy :)
<mvo> lifeless: I'm checking it out currently
<lifeless> \o/
<mvo> lifeless: should be fine again
<lifeless> what was it?
<mvo> lifeless: dapper is end-of-life
<lifeless> ahha
<mantiena-baltix> Hi all, I have question about using aptd in postinst or configure script of debian package (now I creating deb package, which should add new repositories to /etc/apt/sources.list.d folder and seeking the best way how to do this)
<mantiena-baltix> could I use aptd --add-repository "deb http://additional.repository.com ubuntu natty" in postinst or configure script of debian package or maybe someone know better way how to add add new repositories to /etc/apt/sources.list.d/ folder ?
<mantiena-baltix> I mean aptdcon  --add-repository
<directhex> mantiena-baltix, you can just put a file in that folder. i.e. your package includes /etc/apt/sources.list.d/moo.list as a regular file
<mantiena-baltix> directhex: there is one problem during upgrades if my package simply includes /etc/apt/sources.list.d/moo.list as a regular file - user often  gets a message about changed config file, because /etc/apt/sources.list.d/moo.list automatically becomes a conffile when a deb package is built
<mantiena-baltix> directhex: also I wanna make this package installable on different versions of ubuntu, so I wanna generate repository line "on the fly" during package installation, thats why I think to use aptdcon --add-repository "deb http://additional.repository.com ubuntu $codename" in postinst or configure script of debian package
<mantiena-baltix> Maybe this is a crazy idea, maybe I should do in another way, I'm not sure
<mantiena-baltix> Current realization of my package uses static *.list files, see http://bazaar.launchpad.net/~baltix-members/baltix-default-settings/ubuntu/files/head:/etc/apt/sources.list.d/
<geser> mantiena-baltix: do you use the same package for all Ubuntu releases? and how do you plan to handle upgrades of the package (or is aptd intelligent enough to not create duplicate entries?)
<mantiena-baltix> geser: yes, aptd is smart enough :)
<mantiena-baltix> geser: thats one of reasons why I wanna use aptd
<mantiena-baltix> So, are here some developers against using aptdcon --add-repository "deb http://additional.repository.com ubuntu $codename" in postinst or configure script of debian package?
<mantiena-baltix> s/some/any
<Laney> what file does that touch? what happens if I edit said file?
<cjwatson> does that require dbus to be available from the postinst?
<cjwatson> if so that could easily cause problems in chroots
<jpds> How is it different from add-apt-repository ?
<tkamppeter> pitti, hi
<pitti> hey tkamppeter
<tkamppeter> It is about bug 799442
<ubottu> Launchpad bug 799442 in cupsys (Ubuntu) "Canon's printer driver package tries to pull in "cupsys-common" package by dependencies" [Undecided,Invalid] https://launchpad.net/bugs/799442
<pitti> cups*ys* oh my, that's old
<tkamppeter> pitti, the problem is here that a manufacturer-supplied printer driver is still based on the package name "cupsys" which was abolished 2 years ago.
<pitti> we renamed it more than 3 years ago
<tkamppeter> pitti, now the user is not able to make this driver work.
<pitti> does a three year old driver even still work?
<pitti> tkamppeter: I guess it's time for Canon to do a rebuild?
<tkamppeter> pitti, I do not know why manufacturers offer so old drivers and do not update them.
<pitti> tkamppeter: a workaround for this guy might be to use equivs to generate a "fake" cupsys package
<pitti> so that apt is satisfied
<tkamppeter> pitti, seems that I have to recommend to this user to buy a new printer, HP or Epson.
<pitti> heh
<pitti> no free driver for this at all?
<tkamppeter> pitti, can you add instructions to that bug report for the user to use equivs so that he can make his printer work?
<mantiena-baltix> jpds:  "aptdcon --add-repository" is smarter than "add-apt-repository", because aptd doesn't add duplicate lines, it's very important for my, because sometimes users already have some of repositories, which my package wanna add
<mantiena-baltix> cjwatson: AFAIK aptd requires dbus, I'm not sure, you should know better than I :)
<pitti> tkamppeter: done
<tkamppeter> pitti, thanks.
<cjwatson> mantiena-baltix: I don't know offhand, you're the one proposing this so you should check
<cjwatson> mantiena-baltix: I don't think postinsts should depend on being able to talk to a running dbus-daemon in the appropriate filesystem context
<Riddell> dholbach: what's the plan for completing the ubuntu packaging guide?
<cjwatson> mantiena-baltix: perhaps you should try to use the relevant backend parts of aptdaemon directly, rather than via aptdcon, if aptdcon is expecting to talk to a dbus backend
<cjwatson> it's all in python so it shouldn't be too hard to call just the relevant bit
<mantiena-baltix> cjwatson: it's ok to use python scripts in postinst?
<cjwatson> sure
<dholbach> Riddell, there is a number of bugs filed where we track how we massage the old content we have (like from the wiki) into usable articles
<dholbach> Riddell, we'll hopefully soon move it to a more official place soon, getting it themed in ubuntu colours is something that's currently being worked on (among other things)
<dholbach> not sure if that answers your question
<tkamppeter> pitti, can you have a look at bug 807261? For some time now s-c-p asks for the user's password, even if he is in lpadmin.
<ubottu> Launchpad bug 807261 in policykit (Ubuntu) "system-config-printer asks for password without necessity" [High,New] https://launchpad.net/bugs/807261
<tkamppeter> pitti, I had an interruption, did you answer my last message?
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 1 to kick off in 10 minutes in #ubuntu-classroom
<Riddell> dholbach: I think the main issue is if bug 792381 is to be fixed or won't fixed because that needs a fair amount of restructuring
<ubottu> Launchpad bug 792381 in Ubuntu Packaging Guide "Not really an "Ubuntu Packaging Guide"" [Undecided,New] https://launchpad.net/bugs/792381
<dholbach> Riddell, I have UDW starting in a bit, so not much time to discuss it right now - I'll get back to you about it - can you subscribe to it?
<Riddell> k
<doko> bdmurray: thanks for cleaning up the -fsys-tarfile issues. how many are these?
<bdmurray> doko: about 100
<bdmurray> pitti: I want to include the casper package version from apport bug reports with LiveMediaVersion in them.  Is the generic.py hook the best place for that?
<pitti> bdmurray: /usr/share/apport/general-hooks/ubuntu.py would be, as that has the ubuntu specific bits
<pitti> tkamppeter: need to run, will look at the bug and reply there
<mpt> sladen, hi, did you see this? https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2011-June/012686.html
<sladen> mpt: ta
<debfx> pitti: the kubuntu seed branch has been changed to ~kubuntu-dev/ubuntu-seeds/kubuntu.oneiric
<RoAkSoAx> pitti: howdy!! I just upgraded to the latest udev (as was the last package i need to upgrade in oneiric) and have lost keyboard/mouse in an x201
<RoAkSoAx> any ideas?
<RoAkSoAx> pitti: never mind, seems to be something with lightdm
<thebishop> is there any plan to get synaptics clickpad support in 11.10?  It doesn't work as of Alpha2
<thebishop> apparently it's been in xorg upstream for a whlie
<james_w> pitti, https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/gnome-keyring/oneiric-201107080812/+merge/67292 <- seems your upload didn't actually change the watch file as the changelog stated?
<bambee> who did upgrade xorg recently? http://paste.ubuntu.com/642125/
<Laney> any AA around to quickly sync tangerine? bug 808723
<ubottu> Launchpad bug 808723 in tangerine (Ubuntu) "Sync tangerine 0.3.3-2 (universe) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/808723
<Laney> need it to start the lib transition
<infinity> Laney: I can poke at it before I lunch.
<Laney> infinity: thanks
<Laney> the library transition should hopefully go much faster
<cnd> I've got a daily build recipe for a package, but it says "No suitable builders": https://code.launchpad.net/~utouch-team/+recipe/libgrip-daily
<cnd> what's going on?
<Laney> they are down for a minute apparently
<cnd> Laney, ok
<cnd> thanks
<ScottK> cnd: Generally #launchpad is a better place for such questions.
<cnd> ScottK, ahh, I see
<seif> any idea why the keyboard and mouse on my thinkpad stopped working on oneirick with the last update
<hyperair> bad kernel update?
<ion> seif: Dunno, but if you can disconnect and reconnect input devices after starting X, thatâs a workaround. :-P
<bryceh> seif, I do
<seif> i found a bug
<bryceh> seif, it's the new /run directory
<seif> bryceh, yeah
<seif> there is a workaround
<bryceh> try sudo rm -rf /run
<bryceh> it's bug #807306
<ubottu> Launchpad bug 807306 in udev (Ubuntu Oneiric) "[oneiric] Keyboard & mouse not working in X" [High,Confirmed] https://launchpad.net/bugs/807306
<bryceh> which basically is a dupe of bug #807974
<ubottu> Launchpad bug 807974 in eglibc (Ubuntu Oneiric) "debootstrap fails to install libc6 installing oneiric from natty" [Critical,Triaged] https://launchpad.net/bugs/807974
<ion> Hmm, that might also be the reason for pulseaudio not finding audio devices from udev.
<bryceh> or at least sudo rm -rf /run/udev
<bryceh> that might be a better workaround
 * slangasek wonders why he's not seeing any of these problems locally
<bryceh> slangasek, Sarvatt couldn't reproduce on 6 systems either, but cnd did
<cnd> slangasek, I haven't "fixed" my system yet
<cnd> I can help you prod a broken system
<bryceh> ok, enough for me on that bug... pilot time
<cnd> my machine also is an upgrade from maverick development through natty development to oneiric development
<bryceh> @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: bryceh
<bdmurray> RAOF: could you comment on bug 797894 please?
<ubottu> Launchpad bug 797894 in update-manager (Ubuntu Natty) "update-manager bug reports would benefit from an apport-hook" [Medium,Incomplete] https://launchpad.net/bugs/797894
<Laney> infinity: thanks a lot
<Laney> here comes the lib uploads
<kirkland> slangasek: howdy, around?
<kirkland> slangasek: nevermind, I'll take it to email
<bryceh> slangasek, seen https://code.launchpad.net/~rsalveti/ubuntu/oneiric/base-files/run-transition/+merge/67444 ?
<bryceh> slangasek, want me to merge that?
<slangasek> bryceh: if you test that it dtrt, sure :)
<infinity> slangasek: It just adds the directories back, which is a reasonable stop-gap for now.
<infinity> slangasek: I'll admit that I'm failing to understand why we can't just symlink and call it done.
<infinity> (crazy talk of bindmounting and such...)
<slangasek> yeah, I can't think of any way that readding the directories will break things
<rsalveti> guess we can just create a symlink, but don't know if the transition is that simple
<slangasek> still, should be tested
<slangasek> rsalveti: the distinction between symlink and bind mount is generally moot, except in the case where you're poking a chroot from outside and get bitten by wide links
<slangasek> but a symlink is a lot easier to code up
<rsalveti> sure
<infinity> rsalveti: The way dpkg treats symlinks to directories makes it a meaningless distinction (assuming anything still ships something in /var/run, which they shouldn't have been doing for years now)
<slangasek> regardless, I'm not inclined to own an implementation of any /run code here - I want us to do what Debian did :)
<rsalveti> :-)
<infinity> Yeah, I'm happy with that, so long as "what Debian did" actually works smoothly for us before release. :P
<rsalveti> slangasek: and what is the remaining merge at sysvinit you said it's complicated?
<slangasek> workin' on it
<slangasek> initscripts merge is a pain
<rsalveti> guess we'll also have to remove the remaining directory and create the symlink while updating the package
<broder> rsalveti: the debian update covered that too
<slangasek> rsalveti: some 36-odd conflicts from the initial branch merge; half of these due to reorg of the source package (so, contents conflicts that require merging by hand); I'm about 3/4 way through the merge now
<rsalveti> slangasek: oh, ok
<rsalveti> so guess we can get both directories back for now, so we can make debootstrap to work again
<rsalveti> and once you merge sysvinit we can then finally remove it
<rsalveti> properly
<slangasek> yep
<infinity> Working debootstrap would make me a cappy hamper.
<infinity> I was going to do that today if no one beat me to it. :P
<barry> kirkland ping
<kirkland> barry: pong
<serge_afk> RoAkSoAx: have you looked at the udev changelog?
<barry> kirkland, hi.  do you have a little time to help me with an ecryptfs problem?
<kirkland> barry: sure, what's up?
<barry> kirkland, this is on a natty box that has been working great for a long time.  just today i rebooted (after probably 2-3 weeks of uptime) and my encrypted home dir will no longer mount
<barry> ecryptfs-mount-private says "encrypted private directory is not setup properly"
<kirkland> barry: hmm, okay
<barry> kirkland, um, i have no idea what's wrong or how to fix it
<kirkland> barry: are you on the box as root now?
<barry> yep, in a vt
<kirkland> barry: or at least on the box as a user
<barry> well, it's a different box than i'm typing on :)
<barry> kirkland, yep, root on a vt
<kirkland> barry: cool, grep sysfs /etc/mtab
<barry> kirkland, non /sys sysfs rw,noexec,nosuid,nodev 0 0
<barry> kirkland, s/non/none/
<kirkland> barry: okay, so it's not that issue
<RoAkSoAx> serge_afk: yes
<kirkland> barry: hmm, well, i just dist-upgraded my natty box today for the first time in 3 weeks
<kirkland> barry: and i haven't rebooted yet
<barry> kirkland, this is still natty ;)
<kirkland> barry: give me a minute, and let me see if i reproduce the issue here
<kirkland> barry: yeah, i'm still natty on this box too
<kirkland> barry: rebooting ...
<barry> kirkland, thanks
<kirkland> barry: i'm not sure if I want to reproduce it, or not :-)
<barry> ;)
<kirkland> barry: okay, I'm up, no problem
<kirkland> barry: let's drill down into what might be wrong with yours
<barry> kirkland, cool, thanks
<serge_afk> RoAkSoAx: wait, the system is failing in oniric, or in uptodate natty?
<kirkland> barry: as your non-root user, clear your keyring with 'keyctl clear @u'
<RoAkSoAx> serge_afk: oneiric
<serge_afk> ok
<barry> kirkland, done
<serge_afk> the bzr tree is, alas, not uptodate :(
<infinity> cjwatson: Was there a reason (other than CPU usage) to have p.c.c/~u-a only run germinate every 4 hours?
<kirkland> barry: and sh -x /usr/bin/ecryptfs-mount-private
<kirkland> barry: should prompt you for your password
<cjwatson> infinity: I think mostly CPU usage.  It takes a fair while to run and it seemed unfriendly to run it every hour.
<barry> kirkland, it did not, it just failed with the previous error
<cjwatson> infinity: germinate is packaged, so people in a rush can always run it locally
<kirkland> barry: does that -x output give you any indication where that failure was?
<barry> kirkland, it looks like it's failing at the [ -f /home/barry/ecryptfs/wrapped-passphrase ... ] test
<infinity> cjwatson: True.  I'm looking at in-DC use (livefs builds), where I'd prefer pulling from a pre-generated source, if I can get away with it.
<RoAkSoAx> serge_afk: i had the same issue as this: bug #807306 but followed advivce of moving /run/udev to /run/udev.old and mouse/keyboard working again, so I'm presumming it might be related as i think it all happen at the same time more or less
<ubottu> Launchpad bug 807306 in base-files (Ubuntu Oneiric) "[oneiric] Keyboard & mouse not working in X" [Critical,Triaged] https://launchpad.net/bugs/807306
<barry> kirkland, it looks like .ecryptfs -> /home/ecryptfs/barry/ecryptfs but that file doesn't exist
<barry> er, /home/.ecryptfs/barry/.ecryptfs
<barry> kirkland, the only thing in /home/.ecryptfs/barry is .Private
<kirkland> barry: hmm, there should definitely be a ".ecryptfs" and a ".Private" in that directory
<barry> kirkland, ls -la turns up only .Private :(
<kirkland> barry: http://paste.ubuntu.com/642227/
<kirkland> barry: whoa
<kirkland> barry: sudo find /home -type d -name .ecryptfs
<barry> kirkland, should i panic? :)
<kirkland> barry: not if you have your mount passphrase written down (as you were reminded several times)
<barry> kirkland, and if i know where i put it :(
<kirkland> barry: do you have it in /home/barry/.ecryptfs ?
<barry> kirkland, that find turns up nothing
<kirkland> barry: or is that just a symlink?
<kirkland> barry: where the heck has it been getting your ecryptfs configuration from?
<barry> kirkland, it's just a symlink
<kirkland> barry: do you have a /var/lib/ecryptfs?
<kirkland> barry: that's where we put it in Jaunty era
<barry> kirkland, excellent question, and i have no clue where the real file went
<kirkland> barry: but it hasn't been there in eons
<barry> kirkland, no /var/lib/ecryptfs
<kirkland> barry: yeah, i did not expect a /var/lib/ecryptfs
<kirkland> barry: but you damn well should have a /home/.ecryptfs/barry/.ecryptfs ...
<serge_afk> RoAkSoAx: so mv /run/udev /run/udev.old works for you?
<barry> kirkland, i'm guessing that a wrapped-passphrase file from another machine wll not help me, right?
<RoAkSoAx> serge_afk: I did that and keyboard/mouse worked for me, but still networking for KVM is not
<kirkland> barry: no unless the 128 bits of randomness inside are identical ...
<kirkland> barry: is there any way possible that dir could have just disappeared?
<RoAkSoAx> serge_afk: it is as if I cant find the DHCP server
<kirkland> barry: there's no ecryptfs updates published in https://launchpad.net/ubuntu/+source/ecryptfs-utils
<barry> kirkland, i can't think of how that could have happened.  certainly nothing that i did explicitly (that i know of or remember)
<kirkland> barry: fwiw (and it's too late now), I escrow my keys at keyescrow.net
<barry> kirkland, i suppose of course, that a hardware failure is possible, but nothing that i've noticed or seen in the log files
<kirkland> barry: yeah, you grepped /var/log?
<kirkland> barry: do permissions and ownerships look right in /home/.ecryptfs ?
<barry> kirkland, /var/log grep turns up nothing
<kirkland> barry: let me check the ecryptfs bugs in launchpad and see if there's an outbreak of something
<barry> kirkland, should /home/.ecryptfs/barry be owned by me or root?
<kirkland> barry: you
<barry> kirkland, it's owned by root
<kirkland> this is when /me wishes the bug "heat" indicator was worth a damn in LP
<barry> kirkland, heh, yeah
<Sarvatt> serge_afk: mv /run/udev /run/udev.old only works until udev gets updated again and recreates /run/udev because /run exists thanks to base-files and it uses that over /dev/.udev in that case
<kirkland> barry: http://paste.ubuntu.com/642231/
<kirkland> barry: did you encrypt all of $HOME, or just $HOME/Private ?
<barry> kirkland, all of home iirc, and yeah, my /home/.ecryptfs doesn't look like that at all
<barry> 755 perms on . .. and barry, root:root on all
<barry> kirkland, the only thing i can think of is that i've done some schroot updates today before the reboot, and updated some of my virtual machines, but none of that should have leaked out into my host environment
 * barry is starting to get a bad feeling
<kirkland> barry: hmm ... i think there's an open bug against schroots and ecryptfs, let me check
<kirkland> barry: https://bugs.launchpad.net/ubuntu/+source/ecryptfs-utils/+bug/769595
<ubottu> Ubuntu bug 769595 in schroot (Ubuntu) "Encrypted home not mountable under chroot" [High,Triaged]
<serge_afk> RoAkSoAx: it might be interesting to see if the cmds at http://paste.ubuntu.com/642236/ work for you under natty and oneiric
<cjwatson> infinity: the germinate-output stuff on people.c.c is explicitly only informational - for example, it's only run for one architecture (i386).  I'd really rather that anything else do its own germinate run rather than relying on it.
<barry> kirkland, is it possible that a bug caused an oneiric chroot update to screw the host $HOME?
<rsalveti> bryceh: what's the udev bug?
<rsalveti> have the bug number?
<kirkland> barry: i'm pondering how that could possibly hurt you
<barry> kirkland, i'm just pulling this out of my butt, what if an oneiric bug in ecryptfs somehow caused the perms and contents of ~/.ecryptfs/barry to get hosed, but because of some mount problem it didn't affect the chroot but instead the host fs
<kirkland> barry: do you have an bind mounts right now?
<Sarvatt> rsalveti: https://launchpad.net/bugs/807306 its a different bug than the one you were trying to fix though, this one is caused by udev using /run over /dev/.udev if /run exists which it does because base-files created it and is breaking things. debian fixed it in udev 167-2 (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620995)
<ubottu> Ubuntu bug 807306 in base-files (Ubuntu Oneiric) "[oneiric] Keyboard & mouse not working in X" [Critical,Triaged]
<ubottu> Debian bug 620995 in udev "udev is making use of /run when this is not yet supported" [Important,Fixed]
<kirkland> barry: i think some schroots do a bind or an rbind of /home, don't they?
<kirkland> barry: sorry I don't know more about schroots, as I rarely use them
<barry> kirkland, i think they do, but there's nothing in effect right now afaict
<barry> kirkland, so, am i f*cked?  if i can't find the passphrase, is there no way to recover from a livecd?
<kirkland> barry: :-(  there wouldn't be much security to ecryptfs if you could recover with a livecd and no passphrase
<barry> kirkland, i guess my question was, knowing my password isn't enough, right?
<rsalveti> Sarvatt: oh, ok, it's fixed at udev
<kirkland> barry: it's possible that that wrapped-passphrase file is still somewhere in your filesystem
<kirkland> barry: if the bits haven't been overwritten yet
<barry> kirkland, ah good point.  i can't do much more harm searching for it
<kirkland> barry: i don't know how big your disk is, but a dd image of it to an nfs share would be the next thing I'd do
<kirkland> barry: so that you could do some forensics on it without peturbing it further
<kirkland> barry: you can regenerate everything else in .ecryptfs;  you really just gotta find wrapped-passphrase
<barry> kirkland, it's only 277G used out of a1.5T drive.  i can mount a usb drive and dd it there.  on the fortunate side, this was purely a dev box so nothing unrecoverable is on it.  just a pita to rebuild
<kirkland> barry: or find a copy of the written down, decrypted contents of it
<kirkland> barry: understandable;  i really need to figure out how/why that dir got removed
<kirkland> barry: in case it's systemic
<barry> kirkland, okay cool.  thanks for the help.  if i can't find it then i guess it's oneiric time for me
<kirkland> barry: please record if you reinstall :-)
<barry> kirkland, yep, and i'm happy to help.
<kirkland> barry: and use keyescrow.net ;-)
<kirkland> barry: or email it to yourself
<kirkland> barry: or something :-)
<barry> kirkland, most definitely
<kirkland> barry: good luck;  let me know if i can help further
<barry> kirkland, but i am suspecting some bad interaction between sbuild/schroot/oneiric
<kirkland> barry: do some deep finds on your filesystem for that file
<barry> kirkland, will do, thanks for your help
<kirkland> barry: hmm, you might also talk to jdstrand
<kirkland> barry: i *think* he might have seen something like this once before
<kirkland> not sure why i'm thinking that
<kirkland> barry: but check with him
 * kirkland heads to dinner
<barry> kirkland, will do
<bryceh> slangasek, btw the merge proposal I pointed to earlier didn't actually fix it.  (probalby still a good idea, just not sufficient)
<bryceh> slangasek, really I just noticed that branch while patch piloting; I'm not going to be chasing the /run bug down any further.  I do think it could use a short term fix, as a lot of people are losing their keyboards and mice.
<rsalveti> bryceh: I believe for that we should have the same fix as debian
<rsalveti> don't know how hard would be to merge the debian changes into our udev, didn't look
#ubuntu-devel 2011-07-12
<bryceh> rsalveti, yeah
<rsalveti> bryceh: for the debootstrap issue I published my test result with multstrap at the merge request
<rsalveti> this will at least make it possible to create images again
<bryceh> @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:
<slangasek> bryceh: right, we should certainly fix this ASAP, but if that doesn't fix it I don't know what will do the job
<pook1e> I'm trying to create an oneiric environment using pbuilder, but I keep getting stuck at "W: Failure trying to run: chroot /var/cache/pbuilder/build/1422/. dpkg --force-depends --install /var/cache/apt/archives/libc_2.13-9ubuntu2_amd64.deb"
<pook1e> Has anyone else experienced this problem?
<nigelb> I think pbuilder on oneiric is currently broken. I remember someone saying that yesterday.
<ScottK> It's actually base-files that's broken, but that's not unexpected.
<RoAkSoAx> serge_afk: it was the kernel
<pitti> Good morning
<pitti> debfx: kubuntu seed branch> oh, did I commit something to the wrong place?
<ajmitch> morning pitti
<pitti> RoAkSoAx: nothing to do with udev, it's because there's an incomplete /run transition -- just remove /run/*, and it will work again
<slangasek> pitti: to the contrary, people have been saying today that removing /run is insufficent
<slangasek> er, no, I may have that wrong
<slangasek> people have been saying that adding /var/run and /var/lock compatibility links doesn't fix it
<slangasek> I guess the advertised workaround is to remove /run/udev
<slangasek> so, why does that work?
<slangasek> that would seem to have *everything* to do with udev :)
<pitti> slangasek: worked for me
<pitti> sudo rm /run/* and rebooting helps
<pitti> then udev consistently uses /dev/.udev/ again
<pitti> slangasek: I followed up to bug 807306 explaining what happens
<ubottu> Launchpad bug 807306 in base-files (Ubuntu Oneiric) "[oneiric] Keyboard & mouse not working in X" [Critical,Triaged] https://launchpad.net/bugs/807306
<slangasek> pitti: ok, ta
<pitti> I hit it myself yesterday
<slangasek> pitti: we do want udev to be using /dev/.udev/ though, so I'd like to get this properly fixed
<pitti> slangasek: it's because the initramfs starts its own udev instance, which uses /dev/.udev (as initramfs doesn't have a /run yet)
<slangasek> ok, so it's initramfs-tools where we need to fix it?
<pitti> slangasek: do we? why does base-files create a /run then?
<slangasek> sorry
<pitti> if we want to move to /run, initramfs needs to have it as well IMHO
<slangasek> I mean "we don't want udev to be using /dev/.udev" :)
<pitti> ah :)
<pitti> slangasek: do you know if someone is already on this? or shall I have a look?
<slangasek> pitti: I think it's best if you do - bryce and rsalveti were looking but hit a dead end when readding /var/{lock,run} to base-files didn't fix it
<slangasek> I'm taking care of sysvinit already fwiw
<pitti> oh, is there another problem with /var/lock and /var/run, too?
<rsalveti> I thought this was fixed at debian already
<slangasek> yes, that's the bug that prevents oneiric from bootstrapping at the moment
<pitti> rsalveti: oh, does Debian use /run/ already?
<slangasek> yes
<rsalveti> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=620995
<pitti> slangasek: ah, much appreciated; that'll fix the libc6 install error?
<ubottu> Debian bug 620995 in udev "udev is making use of /run when this is not yet supported" [Important,Fixed]
<slangasek> pitti:
<rsalveti> let me check what was the fix
<slangasek> pitti: yes
<slangasek> pitti: and I'll probably need to do coordinated uploads of sysvinit+mountall+base-files, at least
<pitti> * [259ad09] mkinitramfs: creat /run initramfs directory.
<rsalveti> pitti: https://code.launchpad.net/~rsalveti/ubuntu/oneiric/base-files/run-transition/+merge/67444
<rsalveti> this is for the debootstrap issue
<pitti> yeah, I wasn't quite sure why Keybuk did it that way -- we create /run, but nothing actually makes it a tmpfs
<pitti> that would be mountall, I figure?
<pitti> (and might be covered in slangasek's work)
<slangasek> keybuk *didn't* do it that way, someone else uploaded changes he had partially staged in bzr ;)
<rsalveti> ouch :-)
<slangasek> yes, mountall will need to take care of the tmpfs mounting
<rsalveti> debian includes a fix at udev that makes it only use /run when it's a tmpfs
<rsalveti> seems the right fix even during the transition
<pitti> right, I'll check that
<rsalveti> that will cover bug 807306
<ubottu> Launchpad bug 807306 in base-files (Ubuntu Oneiric) "[oneiric] Keyboard & mouse not working in X" [Critical,Triaged] https://launchpad.net/bugs/807306
<rsalveti> pitti: http://paste.ubuntu.com/642376/, but you can just merge/check the patch from the debian src package
<rsalveti> problem is that udev will always use /run if the directory is there
<rsalveti> even if it's not a valid /run (not mounted as tmpfs)
<rsalveti> as we had the directory there, when udev restarted, it got broken
<pitti> rsalveti: right, trying to find the udev patch; thanks for the pastebin!
<rsalveti> pitti: so to make it all work again we'll need both fixes
<rsalveti> the bootstrap related one, and this udev update
<e_t_> Why does ubuntu-minimal depend on iputils-ping?
<infinity> Why shouldn't it?
<infinity> It certainly fits with the package description.
<e_t_> I mean, why does it depend only on that implementation? inetutils-ping works the same, though it has a much nicer --help.
<infinity> e_t_: because inetutils-ping is in universe.
<infinity> e_t_: File a bug on ubuntu-meta, we could conceivably mangle it to depend on "iputils-ping | ping", which would still get the supported one by default, but let you swap without losing the metapackage.
<e_t_> infinity: Thank you.
<rsalveti> pitti: to fix the debootstrap issue we also need the base-files fix
<pitti> rsalveti: right
<rsalveti> at least while slangasek is merging the sysvinit package change
<pitti> rsalveti: I understood slangasek was going to handle that
<pitti> I'm currently working on merging initramfs-tools
<pitti> to get proper /run handling
<rsalveti> cool
<pitti> the udev bandaid fix is uploaded
<rsalveti> yeah, just saw it
<rsalveti> thanks for fixing it
<pitti> np, thanks for pointing it out
<pitti> slangasek: hm, initramfs 0.99 already creates a /run tmpfs and mounts it over to the running system; do we actually need that in mountall still?
<slangasek> pitti: for the tmpfs-less case, yes
<slangasek> er
<slangasek> initramfs-less case
<pitti> ah
 * pitti tests initramfs merge
<dholbach> good morning
<pitti> hey dholbach
<dholbach> hey pitti
<geser> good morning dholbach, pitti
<pitti> hey geser
<dholbach> hey geser
<evfool> ping barry
<mvo> hey evfool, he is probably still sleeping (us timezone)
<evfool> thanks mvo, didn't know that
<evfool> mvo: do you know anything about update-manager in natty-proposed with the apport-hook (bug 797894)
<ubottu> Launchpad bug 797894 in update-manager (Ubuntu Natty) "update-manager bug reports would benefit from an apport-hook" [Medium,Incomplete] https://launchpad.net/bugs/797894
<mvo> evfool: let me check
<evfool> barry and raof have been talking about that, but now it's not in proposed, not in updates, and the bug's still there
<mvo> evfool: thankss for your update-manager merge btw :)
<mvo> evfool: eh, branch I mean
<evfool> mvo: just trying to check for useful patches attached to bugs and convert them into merge requests, because patches attached tend to get lost
<mvo> evfool: yeah, that is unfortunately true :/ thanks a bunch for going throught them, I find this really helpful
<mvo> evfool: it looks like the u-m proposed version got uploaded without bzr-buildpackage so it includes the .bzr dir, I will do a reupload
<evfool> thx mvo
<pitti> yay, workign /run/udev/
<pitti> slangasek: initramfs-tools working well now, thrown oneiric-wards
<ogra_> GRRR
<ogra_> who brike update-manager
<ogra_> *broke
<seb128> ogra_, wfm
<ogra_> partial upgrade ?
<seb128> ogra_, without details on what is broken it's hard to say
<seb128> ogra_, try #ubuntu for "doesn't work" questions ;-)
<ogra_> i'm getting a partial upgrade offered which then starts fine ... during "preparing to upgrade" a white contentless window pops up
<pitti> works fine here
<seb128> oh, I didn't try to do partial upgrades
<ogra_> sadly without and windo buttons too ... so i cant close both windows (second one seems transiaent)
<ogra_> all i can do is kill from cmdline
<ogra_> its reliably reproducable but doesnt spit out a thing if i fire u-m off from cmdline
 * ogra_ goes back to apt being not able to get any debugging info
<pitti> hm, I just did a full upgrade cycle with current u-m for testing
<seb128> can't try here, I've no "partial upgrade"
<seb128> normal upgrades work fine
<seb128> there might be a bug in the gir transition with the partial upgrade dialog dunno
<seb128> check with mvo
<ogra_> might be arm specific or so, in any case i dont get any debugging output
<pitti> seb128: currently there's a partial upgrade, as the evo binaries are held back
<ogra_> on arm there are the new indicators
<seb128> ogra_, oh, we had that transition a week ago on other archs
<seb128> pitti, it already built on i386 ;-)
<seb128> but not published yet, I guess I will have the partial upgrade as well if I refresh, let's try
<ogra_> seb128, yeah, you had json-glib :)
<mvo> ogra_: hmmm, that is probably the gtk3 port, if the window is still there, could you please do a ps afx and paste the output?
<ogra_> mvo, phew, thats timing, apt-was just ready downloading :)
<mvo> apachelogger: software-properties trunk has your dbusworker stuff now (plus tests for them). thanks again for the initial work, no changes on the ui yet though
<ogra_> mvo, http://paste.ubuntu.com/642494/
<mvo> ogra_: hm, looks pretty normal, so there is a white window? could I see a screenshot maybe? any activity still? anything interessting in one of the logs /var/log/apt/{term.log,history.log} ?
<RAOF> evfool: That package got rejected pending a new upload without the .bzr and .bzr-builddeb cruft.
<evfool> thanx RAOF
<ogra_> mvo, "Log ended: 2011-07-08  18:37:07" ... doesnt seem to get to apt
<ogra_> history.log ends also at that time
<mvo> ogra_: anything /var/log/dist-upgrade/* that looks relevant?
<seb128> does anyone know where is usb_dev_handle is defined in the linux sources?
<ogra_> mvo, hmm, now i cant reproduce it anymore, the "partial upugrade" window just closes, let me check that logfile
<cjwatson> e_t_: FWIW I've always wontfixed bugs asking for alternative dependencies in ubuntu-* metapackages - the *purpose* of those metapackages is to make opinionated choices
<cjwatson> e_t_: people can always remove the metapackages if they want to make a different choice
<cjwatson> I appreciate that that doesn't make everyone happy
<cjwatson> mvo: working on https://code.launchpad.net/~cjwatson/launchpad/multiarch-translations - wgrant asked whether we should be generating Translation-C rather than Translation-en.  What does apt do in the LANG=C case?
<e_t_> cjwatson: Since ubuntu-minimal recommends not to remove it, I was hesitant to do so.
<ogra_> mvo, there we go http://paste.ubuntu.com/642501/
<mvo> cjwatson: it will not download anything for LANG=C currently
<mvo> ogra_: woah
<ogra_> yeah, looks evil
<cjwatson> mvo: should it?
<mvo> cjwatson: I'm not really sure if it makes sense to have Translations-C, conceptual its nice because it means we can have "real" description in -C and "translated" description in -en (translated in the sense that it allows out-of-band description overwrites and typo fixes). but it would also mean that the -C would have to be downloaded all the time in addition to the -en one
<cjwatson> I'm not sure why you'd have to download it in addition
<cjwatson> just the translated one would be fine
<mvo> the -en one?
<cjwatson> sure, if it had basically all the same data
<mvo> right, that would be fine. the only remaining issue is that the ddtp stuff is (much) less often updated at least currently
<cjwatson> my concern is for sysadmins who use LANG=C and still want 'apt-cache show' to be useful
<mvo> so -C would be more fresh then -en most of the time
<mvo> yeah, the LANG=C is a good point
<mvo> we could simply provide both (even via a symlink)
<cjwatson> a symlink could work, yes
<cjwatson> though that gets me into more complicated bits of the publisher :-/
<mvo> :(
<cjwatson> so far my patch is fairly straightforward
<mvo> alternateively I can make it download Translations-en if you run LANG=C as a fallback
<mvo> cjwatson: uhh, sorry, I was wrong, its actually already taking care of this
<mvo> cjwatson: so "C" will simply queue Translations-en for download
 * mvo notes that it helps to look at the right spot of the codeâ¦
<cjwatson> mvo: oh, excellent
<cjwatson> mvo: can you point me to the right spot?  I did look but failed to find it
<mvo> apt-pkg/aptconfiguration.cc, there is a envShort == "C" test in it
<mvo> cjwatson: in getLanguages()
<mvo> cjwatson: the code is a bit hard to follow unfortunately
<cjwatson> mvo: perfect, much appreciated thanks
<mvo> yw
<cjwatson> this will require downtime to deploy AIUI, but the wheels are now in motion
<mvo> great, thanks a bunch for driving this :)
<cjwatson> mvo: I think we'll need a backport of apt to lucid to add LongDescription support.  Could you take care of it?
<cjwatson> mvo: if it isn't appropriate for lucid-updates (I guess it might not be), https://launchpad.net/~launchpad/+archive/ppa ought to be fine
<cjwatson> mvo: so I guess that's at least 1327.52.28, 1327.52.29, 1327.65.10, and maybe 1327.84.57?
<davmor2> hey guys I had the same issue as before with the kernel update last night on oneiric in that the keyboard and mouse don't function once x is started,  works fine if I go into safe mode from grub but stops the minute I start lightdm or startx
<ara> mvo, the page about verifying SRUs: https://wiki.ubuntu.com/StableReleaseUpdates#Verification
<ara> mvo, it says that the SRU team will test the -proposed packages
<ara> but I guess that actually anyone can test them, am I wrong?
<ara> if that's the case, the wiki is a bit confusing
<mvo> cjwatson: hi, I just came back from lunch. apt> I need to check, but I'm happy to do it (unless you cherry-picked the patches already
<mvo> ara: yeah, anyone can
<cjwatson> mvo: I haven't, hands still a bit full with LP bits
<cjwatson> trying to set up to QA your python-apt backport
<mvo> cjwatson: great, I will do the cherry pick now then
<cjwatson> thanks - I think I have a basic setup suitable for validating it
<cjwatson> though outside the context of P
<cjwatson> LP
<RAOF> davmor2: bug #807306 is your winner.
<ubottu> Launchpad bug 807306 in mountall (Ubuntu Oneiric) "[oneiric] Keyboard & mouse not working in X - incomplete migration to /run" [High,Triaged] https://launchpad.net/bugs/807306
<cjwatson> mvo: hmm, I wonder if it'll break anything that this causes 'apt-cache show' to display Description-en fields rather than Description
<davmor2> RAOF: Thanks
<soren> I thought there was supposed to be a /var/lock symlink to /lock for backwards compatibility in Oneiric?
<pitti> soren: ITYM s/lock/run/; that's what slangasek is working on
<soren> My sbuild complains: E: Can't create lock file /var/lib/schroot/mount/oneiric-amd64-abf2953c-aa36-4fa9-bd6a-311004445b44/var/lock/sbuild: No such file or directory
<soren> Hmm...
<pitti>   * debian/1777-dirs: remove /var/lock (replaced by /run/lock on tmpfs)
<pitti> ^ base-files 6.3ubuntu3
<pitti> i. e. this transition is incomplete
<pitti> soren: sorry, you are right
<pitti> soren: same answer, though
<soren> Ah :)
<soren> Had me confused there for a little bit.
<RAOF> soren: Yeah; just create /var/run in your chroot and it'll work again.
<soren> Ok, if the fix is in the works, that's great. I'll ninja my way out of it for now.
<soren> Yay. sbuild is all smiles and giggles again now. \o/
<kirkland> barry: ping
<barry> kirkland, pong
<kirkland> barry: so i dug through all the Ubuntu code I have in my /local/source/* directory
<kirkland> barry: the *only* way i could see that an .ecryptfs dir *might* have been removed is if you tried to deluser with the --remove-home option
<kirkland> barry: i don't know if you would have done that in your chroot
<kirkland> barry: but your report bothered me sufficiently that I had to do some digging
<barry> kirkland, no, i definitely didn't do that.  thanks for digging into it though.  very strange.  i'm going to rebuild the machine today
<barry> kirkland, but i found a spare disk, so i'll make a backup.  i can't see submitting a bug report since i don't even know for sure it's a bug (or where)
<kirkland> barry: cool
<mvo> cjwatson: https://launchpad.net/~mvo/+archive/apt-ftparchive-lucid <- that ppa has the backport, should work, I verified it with lp:~mvo/+junk/apt-ftparchive-testsuit
<RoAkSoAx> pitti: yeah did that already! Thanks!
<davmor2> Man thunderbird is heavy on CPU  90-132% usage :(  on oneiric
<dupondje> 2 - 4% here
<dupondje> average
<davmor2> dupondje: I think it's just the importing, I'm going to check it again, once it's finished.
<mdeslaur> pitti: hi! did you get my email about ubuntu-sru?
<pitti> hey mdeslaur
<pitti> mdeslaur: I did, just didn't answer yet, sorry; the queues are empty right now, so we need to let them fill again
<pitti> before we can do some examples
<mdeslaur> pitti: ah, cool...no rush :) thanks!
<dupondje> http://paste.ubuntu.com/642025/ => could this be a kernel bug? Or surely hw issue ?
<cjwatson> mvo: looks like we need 1327.95.5 as well for data.tar.xz support (bug 619152)
<ubottu> Launchpad bug 619152 in Launchpad itself "Add data.tar.xz support" [Low,Triaged] https://launchpad.net/bugs/619152
<cjwatson> actually I guess that's bug 805389
<ubottu> Launchpad bug 805389 in python-apt (Ubuntu Lucid) "Support xz compression inside debs" [Medium,Fix committed] https://launchpad.net/bugs/805389
<mvo> cjwatson: hm, the python-apt bits I uploaded to lucid-proposed iirc
<cjwatson> mvo: yes, but there's a bit in apt-inst too
<cjwatson> I have your python-apt bits installed
<mvo> cjwatson: ok, I have a look now
<cjwatson> this is at least going faster now that I have a working LP dev VM
<tomreyn> does it qualify for a bug if a process exits instead of either refreshing its configuration files or ignoring the signal on 'kill -1'?
<cjwatson> tomreyn: I would say a wishlist bug.  It might be convenient, but there's no rule for what processes must do on SIGHUP
<cjwatson> and the default for SIGHUP is to terminate the process, which is appropriate for things that aren't long-running
<tomreyn> thank you.
<Sweetshark> somebody knowing by chance the deeper meaning of --dynamic-list-cpp-new --dynamic-list-cpp-typeinfo?
<ahasenack> hi guys, quick recipe question if I may: can a recipe file work with local branches or do they have to be lp: style branches? I tried putting a local path in there instead of an lp: branch and it failed
<ahasenack> I'm using bzr dailydeb
<dholbach> ahasenack, abentley and james_w probably know best
<james_w> ahasenack, it should work with local branches
<james_w> ahasenack, but obviously such a recipe isn't suitable for LP :-)
<ahasenack> james_w: oh, I think this is a pbkac
<ahasenack> james_w: dholbach; sorry, I had the wrong paths in my recipe
<ahasenack> and jumped to conclusions
<dholbach> no worries :)
<dholbach> as long as you figured it out now it's all good :)
<ahasenack> ofcourse, I'm getting another error now, but I will really read through it before posting it here :)
<cjwatson> mvo: your previous ftparchive backport for LongDescription looks good
<ahasenack> so bzr build doesn't actually build, it just puts the requested branches in place, ready for a build
<mvo> cjwatson: great, I'm looking into the xz stuff now
<ahasenack> I don't know what it does to the version/release the recipe specified, the debian/changelog is pristine from the branch
<mvo> cjwatson: I suppose you want the full support, right? including everything that ftparchive is doing?
<cjwatson> I think LP might need that yes
<mvo> ok
<mdeslaur> pitti: is there a way to bypass the apport "This is not a genuine Ubuntu package" error for testing purposes?
<pitti> mdeslaur: a slightly hackish one: let it complain, then edit the .crash file and remove the UnreportableReason:, then run the crash file through apport-bug again
<mdeslaur> pitti: ah, cool, that'll work thanks
<pitti> mdeslaur: package hooks can decide to skip the check, too
<pitti> if that's closer to your use case
<pitti> by setting somethign like report['CrashDB'] = 'ubuntu'
<mdeslaur> pitti: thanks
<ahasenack> james_w: hi, sorry to ping directly, I'm getting this error: bzr: ERROR: Invalid deb-version: {debupstream}+14-0ubuntu0+2: Could not parse version: {debupstream}+14-0ubuntu0+2    Pastebin here: http://pastebin.ubuntu.com/642701/
<james_w> I think your bzr-builder is too old for {debupstream}
<ahasenack> oh
<ahasenack> I got it from the ppa
<ahasenack> dailydebs-team-bzr-builder
<ahasenack> only oneiric has 0.7
<james_w> hmm
<ahasenack> but I'm on lucid, yes
<ahasenack> my bzr is 2.4.0~beta4-1~bazaar1~lucid1
<james_w> I thought that newer versions also told you want the valid substitutions were, and your error message doesn't contain that
<ahasenack> (also from a ppa)
<james_w> hmmm
<james_w> I don't know why the ppa wouldn't have got a newer version
<ahasenack> james_w: what is launchpad using, do you know?
<ahasenack> eventually I want to try this out there, I'm just ironing out some obvious bugs locally first
<james_w> it's using something recent enough, I don't know the exact version thoguh
<ahasenack> I remember using recipes in LP several weeks ago, and I used debupstream without problems
<ahasenack> maybe I have some typo or subtle syntax error here
<mvo> cjwatson: I uploaded a new version with the cherry pick of the xz stuff to https://launchpad.net/~mvo/+archive/apt-ftparchive-lucid please let me know if it looks good, did only very light testing this time
<ahasenack> james_w: I now tried with just "deb-version 0.1.0-1~{revno}", and got:
<ahasenack> bzr: ERROR: No such tag: upstream-0.1.0
<dholbach> https://wiki.ubuntu.com/UbuntuDeveloperWeek Day 2 starting in 23 minutes in #ubuntu-classroom
<james_w> ahasenack, double odd, as I think that's a brand new bit of code that would give that error :-)
<ahasenack> james_w: the tag one?
<james_w> yeah
<ahasenack> james_w: maybe it leaked into that ppa then
<ahasenack> james_w: fwiw, I uploaded the recipe to lp and am building there now, it seems to be working: https://code.launchpad.net/~landscape/+recipe/landscape-txstatsd-daily-test
<ahasenack> james_w: except for the "2h to build" part :(
<ahasenack> that's why I wanted to try locally too
<james_w> ahasenack, yeah, it's on trunk, so should be in the PPA, but it's odd that one error suggests you are using really old code, and the other error suggests really new code :-)
<james_w> I must be misremembering
<james_w> ahasenack, try with --allow-fallback-to-native to get around the "no upstream tag" error
<ahasenack> james_w: worked with 0.1.0-1~{revno}: https://pastebin.canonical.com/49640/
<james_w> cool
<james_w> should work on LP then
<ahasenack> james_w: but broke again once I used {debupstream}
<ahasenack> bzr: ERROR: Invalid deb-version: {debupstream}-1~14: Could not parse version: {debupstream}-1~14
<james_w> hmmmmmmmm
<james_w> and it doesn't say "here are the valid substitutions?"
<ahasenack> same cmdline, with --allow-stuff
<ahasenack> james_w: full output: http://pastebin.ubuntu.com/642724/
<ahasenack> I just replaced 0.1.0 in the recipe with {debupstream}
<james_w> ok, give me two minutes
<ahasenack> ok
<james_w> ah debupstream is excluded from the "here are the valid substitutions" code for some reason
<apw> cjwatson, who is the right person to talk to to figure out why a package is getting built on architectures not mentioned in its control file; its causing issues with our tooling
<apw> (that is building in a PPA)
<james_w> ahasenack, try {debupstream:packaging}
<ahasenack> ok
<ahasenack> james_w: no go: bzr: ERROR: Invalid deb-version: {debupstream:packaging}-1~14: Could not parse version: {debupstream:packaging}-1~14
<slangasek> apw: abstractly, #ubuntu-devel :-)
<ahasenack> still using that --allow switch
<cjwatson> apw: what issues does it cause?  it should just harmlessly fail
<james_w> ahasenack, ok, please file a bug
<ahasenack> james_w: ok
<apw> cjwatson, yeah but the tooling is seeing the errors and reporting the failure back instream of moveing the package on, now we could bodge the tools but it'd be nice to fix it if we can
<cjwatson> apw: (but anyway, LP, perhaps bigjools)
<james_w> probably two in fact, one about you not being able to get {debupstream} to work, and the other about the error not being at all helpful
<ahasenack> james_w: do you know the project name by memory perhaps?
<james_w> ahasenack, bzr-builder
<ahasenack> of course :)
<infinity> apw: Out of curiosity, which PPA and package?
<apw> infinity, the canonical-kernel-team PPA and the lts-backports-* packages
<apw> cjwatson, thanks will ask in that direction
<infinity> Architecture: any
<infinity> apw: ^-- Not seeing how you expect LP to do what you want there.
<cjwatson> ha
<apw> infinity, Architecture: any mean arch-independant doesn't it ?
<infinity> That would be "all".
<apw> which means essentially 'i386' no ?
<apw> oh have we borked it ?
<infinity> What you want is "amd64 i386", if that's all you support.
<infinity> "any" means "build on everything".
 * apw looks foolish and goes figure out why thats not either i386/amd64 or all ... thanks
<infinity> It definitely shouldn't be all.
<infinity> Unless lts-backports has no compiled code. :P
<cjwatson> we haven't borked anything, any and all have always had these meanings
<ahasenack> james_w: #809412 files, thanks for the debugging session :)
<ahasenack> filed
<infinity> cjwatson: I think he meant "we" as "the kernel team".
<cjwatson> aha
<apw> cjwatson, no i meant ... yeah what he said
<apw> thanks all
 * ahasenack -> lunch
<cjwatson> yep, sorry, misread
<Laney> can someone do a no-change rebuild of gmime2.4 please?
<Laney> for mono transition
<seb128> Laney, should we just sync the current version from debian?
<Laney> seb128: no, that got accidently made native
<seb128> Laney, ok, can do the no change rebuild
<Laney> thanks
<seb128> yw
<pitti> skaet: seems the natty-backport lucid kernel got acked by kernel team (https://bugs.launchpad.net/bugs/806586) -- want to try?
<ubottu> Ubuntu bug 806586 in linux-lts-backport-natty (Ubuntu) "linux-lts-backport-natty: 2.6.38-10.46~lucid1 -proposed tracker" [Medium,In progress]
<skaet> pitti,  yes,  lets see what happens this time.
<skaet> pitti,  same failure on the assert, I'm afraid.
<pitti> skaet: weird -- I'm afraid that requires a launchpad guru at this point :/
<skaet> pitti,  ack, will go and see if someone can help figure it.
<seb128> janimo`, thanks for the gnome-utils build fix, do you plan to send it to upstream as well?
<Phr3d13> the vt6410 pci raid/ide card doesn't work in ubuntu 10.10
<pitti> good night everyone
<dupondje> nite
<patrickmw> mvo: ping
<Phr3d13> has anyone ever gotten a pci vt6410 raid/ide card to work in ubuntu 10.10?
<dupondje> Phr3d13: whats not working? Tried 11.04 ? Do you find anything on google about it ?
<Phr3d13> ubuntu sees the card, but not any drives attached to it, and i have googled, but can't find any confirmed or unconfirmed fixes
<Phr3d13> any info i found is really ol
<Phr3d13> d
<dupondje> can you pastebin info of lspci -vvv ?
<Phr3d13> http://pastebin.com/pRSx2w6a
<Phr3d13> line 213 is the controller
<dupondje> it is supported ?
<dupondje> pata_via is loaded for it
<Phr3d13> i'm not totally sure
<Phr3d13> another reason i'm asking in the devel room
<dupondje> can you pastebin dmesg ?
<dupondje> cause card seems supported
<Phr3d13> i couldn't get it all
<janimo`> seb128, filed https://bugzilla.gnome.org/show_bug.cgi?id=654498
<ubottu> Gnome bug 654498 in libgdict "casting error on ARM" [Normal,Unconfirmed]
<Phr3d13> http://pastebin.com/9wAr6Jkt
<dupondje> Phr3d13: and there are how many disks attached ?
<Phr3d13> just to make it clear, it's a pci addon card, not onboard
<Phr3d13> two, a hard drive and a dvdrw
<Phr3d13> the other two hard drives are connected to the on board connector that works
<Phr3d13> and it works when i boot into windows
<Phr3d13> dunno if that info helps
<mvo> patrickmw: hello
<dupondje> Phr3d13: weird, as its supported by pata_via
<dupondje> I would try to upgrade to newer version 11.04
<Phr3d13> but last time i tried that unity borked on me
<Phr3d13> are some of the unity bugs fixed? cause i couldn't even use the gnome classic as unity would run there too
<dupondje> most should work
<Phr3d13> ok, one last question, should i go with the update manager update, or boot an 11.04 cd and update from there
<seb128> janimo`, thanks
<seb128> janimo`, btw better to attach the patch to bugzilla that to point to an ubuntu diff.gz
<seb128> janimo`, you might get a sneaking comment asking you to add a proper patch if they reply this way
<seb128> janimo`, i.e bugzilla will not mark the bug as having a patch since it doesn't, it just has an url as a comment so it's likely that they will overlook it, and if they don't it's likely that they will not be wanting to clean an ubuntu debdiff to get the patch and will ask you to update with a proper one
<dupondje> Phr3d13: do-release-update normally
<dupondje> :)
<Phr3d13> do-release-upgrade?
<janimo`> seb128, I am not sure I mean this as a real patch against upstream, just one of the possible workarounds. They could as well disable -Wcast-align, or use some other code changes. I filed it mostly they get notified and maybe ask for details. I am not sure this fix is the best that can be done
<Phr3d13> dupondje, fingers crossed, process started
<seb128> janimo`, ok, your description doesn't make that clear
<seb128> janimo`, let's see what they do, thanks anyway for sending it there ;-)
<janimo`> seb128, np, I hope they react in some way
<janimo`> I wish LP did this whole thing with a single click both for Debian, GNOME and other upstreams
<serue> NMinker: hi.  i was compiling open-vm-tools by setting up a oneiric schroot as per https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment, and doing fakeroot debian/rules build
<serue> doh
<barry> kirkland, so i was thinking.  why not store wrapped-passphrase in U1?
<kirkland> barry: you could back it up there, of course
<kirkland> barry: but you might not want it exclusively there, like maybe when you're on a plane
<barry> kirkland, true.  could still be a helpful prompt once you set up u1
<barry> kirkland, that's all you'd need though, right, just the wrapped-passphrase file?
<kirkland> barry: right
<barry> kirkland, and that's encrypted with your login passphrase, so it should be safe-ish to just copy that there
<kirkland> barry: some users might not trust their wrapped-passphrase to U1
<kirkland> barry: so it'd need to be opt-in, i suspect
<kirkland> barry: exactly, safe-ish
<kirkland> barry: which is fine by most people, i suspect
<barry> kirkland, yep.  i guess if you're really paranoid, you could gpg encrypt that file locally before copying it to u1
<kirkland> barry: for a better experience, it would be good to sync all of ~/.ecryptfs
<kirkland> barry: exactly
<barry> kirkland, cool.  i'll play with that and maybe file a wishlist to u1
<kirkland> barry: sounds great
<kirkland> barry: excellent idea, btw
<barry> kirkland, as the tai chi masters say: invest in loss ;)
<kirkland> barry: funny you say that ...  that's actually *why* i got invovled in ecryptfs in the first place :-)  loss of a laptop
<barry> kirkland, :-D
<barry> well, not about your lost laptop
<kirkland> barry: i knew what you meant ;-)
<barry> kirkland, phew!
<barry> kirkland, bug 809549
<ubottu> Launchpad bug 809549 in Bindwood "sync ~/.ecryptfs to U1" [Undecided,New] https://launchpad.net/bugs/809549
<kirkland> barry: subscribing ...
<seb128> infinity, hey, you are not interested by take the current telepathy-glib versions for debian and reapply your armel workaround by any chance? I synced whatever was current but today updates was not ready to sync yet it seems, and it still fails on armel it seems
<seb128> infinity, is there any chance you could get your armel workaround upstream or in debian otherwise? would be nice to be able to sync directly ;-)
<slangasek> if I recall the bug, it's not really suitable for upstream
<slangasek> and probably not needed in Debian unless the toolchain there has the exact same bugs
<seb128> slangasek: the natty -O1 workaround was dropped since the toolchain got fixed, the current diff is a "increase the timeout of a test in the testsuit because the builders are slow"
<slangasek> oh, ok
<seb128> which would probably be fine for debian...
<slangasek> true
<slangasek> I'm surprised if they haven't needed it already
<seb128> yeah, not sure ;-)
<jamespage> cjwatson: sorry - the situation was entirely my fault - I was aware that 0ubuntu1 was in the NEW queue and had requested its removal prior to requesting the sync from Debian
<jamespage> however I neglected to ensure that had actually happened
<infinity> slangasek: Meh, seb left, but yeah, the current Ubuntu local patch isn't suitable for upstream.  It relates to lp_buildd being slow, not armel.
<infinity> slangasek: (I upstreamed a patch with slightly increased timeouts for armel, which works fine for Debian, and then had to include a ridiculously long timeout patch just for us)
<infinity> slangasek: There's a bug against lp-buildd to fix our own local problem.
<slangasek> heh, ok
<cjwatson> jamespage: ah, right, we maybe weren't quite responsive enough to all the archive requests in sequence then :-/
 * infinity goes about reapplying his patch to the current package...
<jamespage> cjwatson: a note on the sync request would have helped tho :-)
 * jamespage makes a mental note just in case this crops up again
<cjwatson> jamespage: yeah, I probably should have done
<cjwatson> .orig.tar.* in-sync-ness is a general thing people need to be ultra-careful of when uploading new upstream versions, unfortunately - easy to shoot oneself in the foot
 * infinity engages in cranial-furniture violence as he sees telepathy-glib succeed on every Debian architecture, and fail to build in Ubuntu.
#ubuntu-devel 2011-07-13
<serue> anybody here able to tell me where debian/<binary_pkgname>.debhelper.log comes from?
<RAOF> serue: The dh tool creates that.
<serue> RAOF: can i stop it?  :)
<serue> i don't see it in the previous build, and SpamapS didn't want to push a new version bc of it...
<serue> (and it seems superfluous)
<RAOF> It should be removed by the clean target.  How is it making it into your source packages?
<serue> not sure what you mean by how, but after i do 'bzr bd -S -- -sa' and then dpkg-source -x *.dsc on the result, it's there
<serue> it is not in my bzr tree
<broder> serue: can you pastebin your rules file?
<serue> broder: it's http://bazaar.launchpad.net/~serge-hallyn/ubuntu/oneiric/lxc/lxc-0.7.4.2-cleanup-patches/view/head:/debian/rules
<broder> serue: don't see anything at first glance that would break cleanup, but there's a dh_lintian, and it gets called by debhelper.mk
<broder> it looks for $PACKAGE.lintian-overrides
<serue> and if that doesn't exist?
<broder> ...then it doesn't do anything? i don't understand what you're asking
<serue> just wondering what it's doing :)
<broder> anyway, i'm suggesting you could move debian/lxc.overrides to debian/lxc.lintian-overrides and remove the cp call in the rules file
<serue> ok thanks, that gives me something to look into
<serue> ah
<serue> idont' even know where that came from or what it was meant to do :)  i'll try that, thanks
<broder> i think i blame autoreconf.mk for the superfluous debhelper.log file
<broder> ah - maybe try moving the autoreconf.mk include *above* the debhelper.mk include?
<serue> ah yes, that autoreconf.mk include might be new
<serue> ok, lemme try
<serue> is there a recommended order somewhere?
 * broder shrugs
<RAOF> That's a CDBS package; why is it calling dh *at all*?
<broder> well, that too
<RAOF> serue: If you just delete that file does it get regenerated?
<broder> RAOF: including autoreconf.mk after debhelper.mk causes it to get appended to the clean step
<broder> which means dh_autoreconf_clean will run after dh_clean
<broder> and dh_autoreconf_clean generates .debhelper.log files
<serue> broder: that worked, thanks!
<RAOF> broder: Of course!
<serue> as for calling dh at all, i dunno.
<broder> i do think you have to call dh_installinit by hand if you want to use multiple --name arguments with cdbs
<serue> comes from the debian package
<broder> the dh_install calls are almost certainly superfluous, though
<serue> oh,
<serue> that doesn't work like the override_dh_install rules?
<broder> no, with cdbs you change how dh_* work by setting magic variables
<broder> usually something like DEB_DH_INSTALL_ARGS
<broder> but really, the only way to know is to go rummaging through debhelper.mk
<serue> i know i'm confused on dh vs cdbs vs others, so i'll put trying to clean up that rules file on my list
<serue> and hoepfully learn a thing or two
<serue> broder: thanks again
<pitti> Good morning
<doko> rsalveti: is it that urgent to apply the -mfloat-abi-soft work arounds?
<dholbach> good morning
<rsalveti> doko: don't think so, but was done already
<rsalveti> doko: I just moved the bug status
<doko> ahh, ok
<rsalveti> ScottK: ^
<rsalveti> package libkdcraw
<ScottK> rsalveti: AFAIK only for one of the affected packages.
<ScottK> Not the one doko originally filed the bug about.
<doko> if it can wait, wait for the compiler fix expected next week
<ScottK> Already did the workaround for libdkcraw so we could keep working on getting KDE 4.7 uploaded.
<ScottK> I'll rebuild without it once the compiler fix is in.
* mthaddon changed the topic of #ubuntu-devel to: Launchpad down/read-only from 08:00-09:30 UTC for a code update | 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:
<BigWhale> Right, launchpad down... Thanks for the topic. :)
<jml> morning
<jml> BigWhale: fwiw, you can also always check http://identi.ca/launchpadstatus or https://twitter.com/#!/launchpadstatus
<BigWhale> jml, I'll follow it right away :) Thanks
<davmor2> Guys I've notices on my oneiric install the system locks up if I try and alter the volume.  The volume up and down keys don't work and if I use the slider it lock up the system I'm assuming it's known is there any info that would be useful to you?
<BigWhale> davmor2, you should open sound settings and set volume there... that's what I do. :)
<BigWhale> For now...
<davmor2> BigWhale: Thanks
<dupondje> missing launchpad :(
<dupondje> :P
<BigWhale> yeah, me too... I was just about to do some work (which is long overdue) now launchpad killed the mood :/
<dupondje> I wanted to fill the sponsor queue a bit more ^^
<BigWhale> davmor2, err, the volume keys on my keyboard are working now.
<davmor2> BigWhale: mine work in that they send a signal they just don't do anything, Although I haven't done an update this morning so pass
<BigWhale> yeah for me it started working after todays update.
<dupondje> Launchpad is back !!
<dupondje> :D
<BigWhale> yay \o/ now every developer will hit bzr pull ... :>
<davmor2> and kill LP again
* mthaddon 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:
<pitti> mthaddon: seems it's still not officially back?
<pitti>   Uploading py3cairo_1.10.0-0ubuntu1_source.changes: 2k/3k426 Transfer aborted.
<mthaddon> pitti: in what sense?
<pitti> during the RO time it failed right away
<pitti> now it uploads everything until it comes to the sources.changes, and then aborts
<mthaddon> pitti: it should be back - I'll look into it
<pitti> also, I'm trying to change the status of bug 802486 and only get timeouts
<ubottu> Launchpad bug 802486 in pygobject (Ubuntu) "Provide a Python3 package" [Medium,Triaged] https://launchpad.net/bugs/802486
<pitti> ah, only adding a comment seems to work
<wgrant> pitti: Bug timeouts we're working on.
<pitti> but not opening the expander and clicking "save changes"
<wgrant> Testing the fix right now.
<pitti> wgrant: reminds me of the performance regression from the last rollout
<pitti> wgrant: thanks for the heads-up
<wgrant> It is exactly the same thing.
<pitti> oh
<pitti> it seems the dput actually worked, just got a NEW email
<pitti> (two of them, actually)
<pitti> mthaddon: ^ so it seems it's just a wrong error message
<wgrant> pitti: I think I know what it is.
<wgrant> pitti: Could you try the bug change again?
<wgrant> Should be fixed now.
<pitti> wgrant: works now
<pitti> thanks!
<dupondje> wgrant: attachments works also
<dupondje> :)
<wgrant> dupondje, pitti: Great, thanks.
<wgrant> pitti: poppy is fixed now too.
<pitti> wgrant: rocking, thanks!
<maks_> pitti: hey, thanks for the initramfs-tools merge
<maks_> added your fix in debian too http://anonscm.debian.org/gitweb/?p=kernel/initramfs-tools.git;a=commit;h=780bc4ad484dd2dbe2b3a784f4d245ed43c7bed6
<maks_> one thing that you overlooked in the Ubuntu merge is that cjwatson 0.98.8ubuntu3 change is no longer necessary.
<maks_> ldconfig is run inside of initramfs *before* cpio invocation.
<pitti> maks_: oh, thanks; I thought it doesn't affect Debian, as we changed that part of the code
<pitti> maks_: I thought the Debian version installed busybox as bin/sh directly?
<MacSlow> seb128, what usually triggers glib-compile-schemas? A packages post-install script?
<seb128> MacSlow, right, a dpkg drigger
<seb128> MacSlow, i.e any package installing a schemas in the schemas dir will get it for free
<pitti> maks_: ah, thanks; I'll revert that then and test it again
<MacSlow> seb128, ah... autofoo-macro-magic I guess then
<maks_> pitti: well Debian was affected to, so proper motivation to get rid of the symlink mess.
<maks_> pitti: rechecking busybox hook.
<cjwatson> mvo: thanks for the apt/python-apt uploads; could you upload a new version of the LongDescription backport to your PPA as well?  then I can test that all together
<MacSlow> seb128, notify-osd is then nearly fully GSettings-ified
<BigWhale> Can someone point me in the direction of gnome, introspection and python documentation?
<BigWhale> I'm stuck at the "from gi.introspection import ..." :>
<maks_> pitti: thank you, allways getting ln syntax wrong, fixed to match ubuntu behaviour, less diff is better.
<seb128> MacSlow, excellent
<seb128> MacSlow, was your compile schemas question a packaging one or an upstream makefile one?
<MacSlow> seb128, well initially I assumed it needed some work on the packaging side... but it turns out my (upstream) changes to the makefile cover everything already
<seb128> MacSlow, right
<seb128> MacSlow, I will deal with the packaging, don't worry
<MacSlow> seb128, just did a test here and the NotifyOSD keys show up when looking for them with the gsettings commandline-tool
<seb128> MacSlow, btw feel free to ping me for review before rolling the tarball if you want
<seb128> MacSlow, you probably want a .convert as well to migrate the gconf keys values to the new gsettings ones
<MacSlow> seb128, sure... just migrating the code now
<MacSlow> seb128, I've created a .gschema.xml file for notify-osd already
<seb128> MacSlow, the .convert are trivial, see in /usr/share/GConf/gsettings
<seb128> MacSlow, those are text format describing what keys to migrate and where, GNOME runs an utility at session start which will apply those conversion one and flag them done
<MacSlow> seb128, I remember having read about something like that in the GConf-to-GSettings migration guide
<seb128> MacSlow, right, just pointing it ;-)
<MacSlow> seb128, yep... thanks... but I'm all over it :)
<seb128> MacSlow, excellent ;-)
<mvo> cjwatson: the version in the ppa (0.7.25.3ubuntu9.5+mvo2) should have both the xz and the LongDescripton fix, I will still upload with the new version to ensure that its newer then the -proposed version
<cjwatson> mvo: right, that's all I meant; thanks
<mvo> cjwatson: thanks. new upload is uploaded in the PPA now
<mvo> cjwatson: I also killed of the duplicated compression list in python-apt, it uses the data from apt now instead of duplicating it
<cjwatson> mvo: ok, we don't need that for lucid though right?
<mvo> cjwatson: for lucid we are fine, I just wanted to kill the duplication as its ugly
<mvo> (so that in the future its just one place to add support)
<cjwatson> right
<jdstrand> @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: jdstrand
<debfx> cjwatson: could you please update the kubuntu package set again? a lot of packages are still missing (e.g. libkexiv2, libkipi, marble, ...)
<cjwatson> debfx: I've done an auto-update.  http://paste.ubuntu.com/643259/
<ScottK> Looks good.
<debfx> yep, thanks
<jdstrand> didrocks: hey. I uploaded the fix for unity for bug #805938. I could not apply to the Vcs branch because bzr kept crashing on me. I put my debdiff in the bug if you want to apply it to your tree
<ubottu> Launchpad bug 805938 in unity "Totem set as default music player after install instead of Banshee" [Undecided,Confirmed] https://launchpad.net/bugs/805938
<Riddell> barry: what's the "Version number suggests Ubuntu changes" issue at the bottom of http://people.canonical.com/~dholbach/packaging-guide/html/udd-working.html ?
<soren> Riddell: What do you mean?
<soren> Riddell: You mean you've never seen that?
<Riddell> soren: I have but the guide suggests it's an issue with UDD and can be worked around
<Riddell> (as I read it)
<soren> Well, it can certainly be worked around.
<Riddell> but better to fix it by setting the correct Maintainer address
<barry> Riddell: in a meeting...
<soren> I see that mentioning it there suggests it's about UDD, but OTOH it's not an uncommon problem to stumble on, so having the solution right there is kind of handy.
<micahg> yes, but Riddell's point is valid, the wording makes the workaround more desirable than the proper fix
<barry> Riddell: right, it's not a udd thing.  it would really be better in the general packaging part of the guide, but that needs some reorg to get it all consistent
<Riddell> barry: ok I'll remove it from there and file a bug to remind myself to add it back elsewhere
<barry> Riddell: +1
<Riddell> barry: in http://people.canonical.com/~dholbach/packaging-guide/html/udd-uploading.html "Uploading a change made by you" seems to miss the commit step
<Riddell> it also does a dput before a tag/push, I'd expect that to be the other way around
<barry> Riddell: missing commit, looks like you're right
<maco> dear people who have scripts that make graphs and such in their people.ubuntu.com/~you/  -- how are you doing that?
<maco> python? php? what's available?
<barry> Riddell: order of steps, yes, i think you're right too, but double check w/ jelmer i think there was a discussion about that recently
<barry> (Riddell, terse due to meeting ;)
<Riddell> barry: thanks, I'll make those changes
<Riddell> if jelmer agrees
<Riddell> maco: Excel? :)
<maco> Riddell: automated ones :P
<Laney> we do code review for the packaging guide
<Laney> so please push to a branch and do a mp
<Riddell> Laney: yes I will (I don't even have commit access)
<Laney> Riddell: you do (via ~ubuntu-dev)
<Riddell> ooh, I am powerful!
<Laney> http://2.bp.blogspot.com/_muBQl8yh4Q0/SzpiCnYTSXI/AAAAAAAAASc/UrqtYFtOOtg/s400/spideyquote.jpg
<Cas07> anyone here used debhelper7 and dh-translations with desktop files?
<pitti> barry, doko: I'm currently building a python3-gobject package
<pitti> barry, doko: the thing that breaks is:
<pitti> W: dh_python3:231: renaming _gobject.so to _gobject.cpython-31mu.so
<pitti> (and similar renamings for the other extensions)
<pitti> barry, doko: why is it -31? I'm building with python 3.2
<barry> pitti: only for py3.2?
<pitti> if I rename the installed file to _glib.cpython-32mu.so, it works
<pitti> barry: well, that's what py3versions says for --supported
<pitti> I don't have 3.1 installed
<barry> pitti: that sounds like a dh_python3 bug
<pitti> I'm building against python3-all-dev and iterate over `py3versions --supported --version`
<barry> pitti: well, another question is why _gobject.so doesn't get written as _gobject.cpython-32mu.so in the first place
<pitti> right
<pitti> for some reason dh_python3 seems to think it's a 3.1 library
<pitti> how does it detect the version that it built with in the first place?
<pitti> I don't specify any version or so
<pitti> just dh_python3 -a
<barry> pitti: how is gobject built?  with distutils or outside of that build system?
<pitti> barry: distutils plus some extra autotools for other stuff
<dupondje> jdstrand: thx for the sync's :)
<barry> pitti: py3.2's distutils should dtrt
<pitti> $ dh_python3 -v
<pitti> D: dh_python3:286: package python3-gobject details = {'compile': True, 'requires.txt': set(), 'shebangs': set(), 'private_dirs': {}, 'ext': {(3, 1)}}
<pitti> that (3,1) might have something to do with it?
<pitti> I build it with PYTHON=python3.2 ./configure ...
<barry> pitti: indeed.  i had a system crash this week so i cannot do any local builds atm to debug further
<pitti> hm, I wonder when it calls setup.py in the first place
<pitti>     if vers == '3':
<pitti>         # assume .so files without tag in /usr/lib/python3/ are build for Python 3.1
<pitti>         vers = '31'
<pitti> ^ in dh_python3
<pitti> so I guess the upstream build system doesn't "tag the extension", whatever that means
<barry> pitti: that means adding the 'cpython-32mu' bit
<pitti> oh, are upstream build systems supposed to name the libs that way?
<pitti> upstream it just comes out as _glib.so
<pitti> that's why it is a warning?
<barry> pitti: well, they don't *have* to in the sense that python will still import them under the old name, but dh_python3 is apparently not prepared to handle untagged so's for python >= 3.2
<pitti> barry: well, something needs to tell dh_python3 which version the library was built with
<barry> pitti: but the build system *should* tag the files so they don't collide and we don't have to play stupid symlink games
<pitti> right
<barry> pitti: which is what dh_python3 is trying so hard to be helpful with ;)
<pitti> barry: ok, so it would be better/correct for upstream "make" to build _glib.cpython-32mu.so instead of _glib.so?
<barry> pitti: i think dh_python3 shouldn't assume untagged == py3.1
<barry> pitti: yep
<barry> pitti: but only for python >= 3.2
<pitti> barry: ok, thanks! then I'll look into fixing the upstream build system accordingly and then backport the patch
<barry> pitti: doko back ported that support so for debuntu, tagged sos works for python 3.1 also, though you don't care :)
<barry> pitti: awesome.  i do think a bug report on dh_python3 would be helpful.  it should not assume untagged == py3.1
<barry> pitti: could you file that bug (i'm technically still in a meeting :)
<pitti> barry: ok
<barry> pitti: awesome, thanks
<pitti> barry: bug 809951, I hope I included everything
<ubottu> Launchpad bug 809951 in python3-defaults (Ubuntu) "assumes untagged extensions are built for Python 3.1" [Undecided,New] https://launchpad.net/bugs/809951
<barry> pitti: subscribed
<pitti> barry: wow, what I believed to be an hour hack has now become a solid day's work :)
<barry> :)
<pitti> (had to fix a bunch of other stuff upstream first, and a 6 package multibuild is rather messy)
<apw> cjwatson, ok ... finally can get to my own code branches, the casper changes i am proposing for overlayfs are here: https://code.launchpad.net/~apw/ubuntu/oneiric/casper/overlayfs
<pitti> barry: is the .cpython-32mu suffix a firm convention, or is there a tool which computes it?
<apw> cjwatson, have tested this with both normal kernels and overlayfs enabled ones and it seems to work, you may argue about order of course, ie about preferred union system
<barry> pitti: both, in a sense ;)
<barry> pitti: http://www.python.org/dev/peps/pep-3149/
<pitti> $ python3-dbg -c "import sysconfig; print(sysconfig.get_config_var('SOABI'))"
<pitti> cpython-32dmu
<pitti> barry: that's what I was lookinf for, I think :)
<barry> pitti: yep, and if you run it with python3, you'll see cpython-32mu (no 'd')
<pitti> right, checked that
<dholbach> UDW (https://wiki.ubuntu.com/UbuntuDeveloperWeek) day 3 starting in 23 minutes in #ubuntu-classroom
<mvo> silly(?) question, but livebuild seems to be not working for me, any hints if I use it wrongly? http://paste.ubuntu.com/643344/ (this is on oneiric)
<infinity> mvo: Isn't that just the ongoing "debootstrap is broken due to the /run transition" thing?
<cjwatson> yup
<cjwatson> huh, but you're doing --distribution natty
<infinity> Oh, indeed.
<mvo> and it seems to be the natty version of libc if I'm not mistaken
<cjwatson> check the debootstrap log?
<cjwatson> should be /debootstrap/debootstrap.log inside the chroot, probably
<mvo> cjwatson: thanks! that was the missing clue :) http://paste.ubuntu.com/643352/ - its my kernel version , iirc this got fixed with the update three digest number.
 * mvo updates on this box
<pitti> barry: ah, so upstream apparently installs into versioned directories, like /usr/lib/python3.2/
<pitti> barry: we'll look into it after the invoke-rewrite branch lands, but until then I just fix it up in debian/rules
<cjwatson> mvo: aha, yes, use >= 3.0.0-4
<mvo> thanks!
<pitti> look, ma! pygi gtk3 working with python3 \o/
<pitti> barry: ^ :)
<pitti> good night everyone
<fishor> hallo all, what version of cheese will be as target for ubuntu 11.10
<fishor> ?
<fishor> or how can i find it
<slangasek> mvo: so you asked if my update-manager math problem was on amd64... does that mean you've seen this before?
<bdmurray> pitti: could you review https://code.launchpad.net/~brian-murray/apport/casper-version/+merge/67579 ?
<seb128> ev, hey
<seb128> ev, do you know if keyboard layouts are set differently if you select "try ubuntu" on the text mode menu from a liveCD compared at if you let it boot and select "try ubuntu" on ubiquity?
<seb128> ev, using the second option leads to bug #800561
<ubottu> Launchpad bug 800561 in gnome-control-center (Ubuntu Oneiric) "No way to add other keymap than english on Live CD" [High,Triaged] https://launchpad.net/bugs/800561
<ev> seb128: you have to select French as a language before the indicator shows you the French keymap
<seb128> ev, GNOME somewhat get all english keyboard variant configured
<ev> that's by design
<ev> every keymap under the sun would be a lot to pack into a menu
<seb128> ev, no, you select english (or let it this way) and click "try ubuntu"
<seb128> the session you get has a load of english variants
<seb128> see the screenshot on the bug
<seb128> ev, where the live session if started from the text mode menu has only 1 selected layout
<seb128> i.e "english"
<ev> right, because they had the english language selected in ubiquity
<ev> are you suggesting that it should clear the list of layouts when the user presses "try ubuntu", regardless of their language selection?
<seb128> ev, well if you select the english layout on the text menu you get when pressing a key on boot you get only 1 layout
<ev> right, that's a different code path
<ev> a
<seb128> ev, I suggest selecting a locale from the text mode and from unity should lead to a similar result
<seb128> either way
<mvo> slangasek: I have not seen it before, but we had problems in the past with the data types in the aptdaemon dbus code, I was wondering if it might be releated. the bad news is that we thought we fixed it
<seb128> ev, the current ubiquity way leads to an interesting issue that xorg doesn't like have that number of layouts configured so it doesn't let you add a new non english one
<slangasek> mvo: ok; will file a bug then
<slangasek> mvo: btw, I also just had an aptdaemon crash, filed the report on that
<slangasek> dunno if it's related
<mvo> slangasek: thanks, that could well be
<seb128> ev, i.e bug #640774
<ubottu> Launchpad bug 640774 in collective.amberjack "ComponentLookupError" [Undecided,Fix committed] https://launchpad.net/bugs/640774
<seb128> ev, i.e x11 limits you to 4 keyboard groups
<seb128> ev, so having that stack of english layout makes it impossible to add a non english layout before clearing the list first
<seb128> ev, well, I'm not sure what the right way, I'm just trying to understand why we land with that stack of layouts configured to start
<ev> that's fairly arbitrary
<ev> 4 keyboard layout groups are enough for anyone? :)
<seb128> ups
<seb128> gnome bug #640774
<ubottu> Gnome bug 640774 in Region & Language "For some reason I can't add more than 4 layouts" [Normal,New] http://bugzilla.gnome.org/show_bug.cgi?id=640774
<seb128> ev, no, "x11 design limitation"
<seb128> ev, will be fixed the day we move to !x11 I guess
<ev> x11's entire design is a limitation
<seb128> right
<seb128> well in that case the limitation is coming from x11
<ev> right
<seb128> I'm not sure what's the best way forward now for that bug though
<seb128> is that wanted that picking english gets you all of existant english layout variants as configured?
<seb128> could we just pick one and assume users who want other ones can add them using the control center?
<ev> seb128: mpt suggested picking the top X layouts for that language
<ev> we'd have to build that data into ubiquity/casper
<ev> problem is, I'm not sure where we get that data
<ev> because, alas, we don't measure these things yet
<cjwatson> shouldn't we undo all the work that ubiquity does if you go through to the live session?
<cjwatson> it should be as if you never went through ubiquity-m
<cjwatson> *ubiquity-dm
<ev> bug 810003 for consistency between ubiquity and casper on this
<ubottu> Launchpad bug 810003 in casper (Ubuntu) "breaking into just the live CD, skipping ubiquity, should add keyboard layouts relevant to the language selection" [Undecided,New] https://launchpad.net/bugs/810003
<cjwatson> you could pick the top one layout for that language, that being the information that's already built into console-setup
<cjwatson> for the time being
<ev> hmm
<cjwatson> if we can't do the other thing without breaking stuff
<seb128> ev, cjwatson: I reassign bug #800561 to ubiquity, is that ok with you? there is not a lot we can do from the ui side with the x11 limitation
<ubottu> Launchpad bug 800561 in ubiquity (Ubuntu Oneiric) "No way to add other keymap than english on Live CD" [High,Triaged] https://launchpad.net/bugs/800561
<seb128> it's also not really practical to have an indicator keymap list going over the screen
<ev> seb128: sure, I was just adding these notes in there
<seb128> ev, thanks
<kirkland> sladen: are there Ubuntu monospace web fonts yet?
<sladen> kirkland: in Beta.  Alledgedly the hinting on the Regular was finished a couple for days ago (the Hinting is what is needed to generated bitmaps)
<sladen> kirkland: https://launchpad.net/~ubuntu-typeface-interest/+join  if people are interested
<zyga> dholbach, hi, where will the developer week take place exacly? #ubuntu-classroom?
<ricotz> infinity, hello, are you investigating the build failure of telepathy-glib?
<dholbach> zyga, yes
<infinity> ricotz: I am, but juggling with a few other things, so if someone beats me to it, they're welcome to. :P
<infinity> ricotz: I have a bug filed upstream too, just as a personal reminder to get it fixed.
<ricotz> infinity, ok, i will wait then
<infinity> https://bugs.freedesktop.org/show_bug.cgi?id=39183
<ubottu> Freedesktop bug 39183 in tp-glib "dbus/account-channel-request test fails consistently on Ubuntu/oneiric" [Normal,New]
<ricotz> thanks
<selvakumaran_>  Hey All., i wish to add a change in UI of Update mgr., can i code for that..?
<selvakumaran>  Hey All., i wish to add a change in UI of Update mgr., can i code for that..?
<smoser> wonder if someone python aware could answer:
<smoser> is this expected for some reason:
<smoser> $ python -c 'import pkg_resources'
<smoser> -c:1: UserWarning: Module paste was already imported from None, but /usr/lib/python2.7/dist-packages is being added to sys.path
<smoser> (i'm getting that from another module that imports pkg_resources, not just typing that command line for fun)
<nigelb> heh
<kirkland> sladen: okay, thanks.
<infinity> mvo: Is it intentional that update-manager's release upgrade tool lost support for local mirrors?
<infinity> Err, and if he were here, he might be able to answer. :P
<sladen> kirkland: what are you after inparticular?
<kirkland> sladen: i'm giving a class in #ubuntu-classroom in 30 minutes;  i'm doing a live demo/webcast at http://bit.ly/uclass
<kirkland> sladen: username/pass = guest/guest
<kirkland> sladen: that's an ajaxterm
<kirkland> sladen: jcastro mentioned that it would be nice if our ajaxterm package used the ubuntu colors/font
<kirkland> sladen: it's pretty easy to hack the css/html
<kirkland> sladen: i hacked it a few minutes ago to use the serif font, but without monospace, the terminal looks terrible
<sladen> kirkland: bad idea, leave it at 'UbuntuBeta Mono, monospace' at the moment
<sladen> kirkland: ah, I was talking to soren about this yesterday too
<sladen> kirkland: and looking into possibly patching the SeaBIOS source (soren was assuming it'd be webbrowser-based VNC for openstack in the future)
<sladen> kirkland: looks lovely from there, but I have 'UbuntuBeta Mono' installed
<kirkland> soren has an interest in ajaxterm?
<kirkland> sladen: hmm, not sure i understand your directions
<sladen> kirkland: I want Ubuntu Mono to be used whenever an adminstrator is accessing an Ubuntu/Cloud server from a web-interface.  I don't mind what the technology used to do that is
<kirkland> sladen: okay
<kirkland> sladen: but it's not in the google web fonts yet, right?
<sladen> kirkland: no.  Ubuntu Mono isn't finished.  it's currently betaing.  We'll probably release it this mnth
<sladen> kirkland: once the engineering is done.  But that's still later than I'd like, so it would be good to get the infrastructure all lined-up for Web/etc
<kirkland> sladen: okay, no problem;  so not a candidate for this presentation;  will check back with you later
<kirkland> sladen: i'd be glad to see you change the css shipped with ajaxterm, though
<sladen> kirkland: not unless people already have installed (about 1,400 people, so it might be worth setting the CSS anyway)
<kirkland> sladen: whatever you say, mate
<jdstrand> @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:
<vikapi> i really missed lvm support while installing kubuntu (using kubuntu for the very 1st tie).. will this feature be added in any future release.??
<vikapi> *time
<slangasek> cjwatson: whee; I just looked in my oneiric dev chroot and find that /lib/init/rw is not a symlink to /var/run like it's supposed to be.  I guess this is because I continuously upgraded, and it's a chroot so init scripts never ran... I wonder if this matters
<slangasek> vikapi: lvm support is available when installing kubuntu using the alternate CD image instead of the desktop one
<slangasek> vikapi: lvm support for the desktop installer has been on the Would Be Nice list for years, but it requires some dedicated effort to get there so it's never happened; I think the installer folks would heartily welcome community contributors who were willing to work on this
<vikapi> slangasek, aha..i should ve known this bfore..alright, wats the difference between alternate and desktop??
<vikapi> slangasek, i would love to contribute, but im a very newbie in developement..:)
<vikapi> slangasek, and my contribution (if any) wud be so insignificant
<slangasek> vikapi: the desktop CD gives you the graphical, X-based installation (plus the try-before-you-buy live desktop environment); the alternate CD boots straight into a fullscreen text interface (specifically, debian-installer)
<vikapi> slangasek, ok tats the only difference??anythng else relatd to default packages selectd.. like wat we have for desktop vs server editions??
<slangasek> vikapi: no, the packages you get installed at the end are meant to be 100% identical in the default case (though obviously, if you use lvm from the alternate installer, you'll have lvm tools installed at the end that you wouldn't using the desktop CD)
<cjwatson> slangasek: I suppose we could deal with that in the mountall run_migrate stuff too
<cjwatson> apw: thanks, looks good, I'll merge that
<vikapi> slangasek: ok..
<smoser> i opened bug 810019 to address my issue above.
<ubottu> Launchpad bug 810019 in distribute (Ubuntu) "UserWarning printed on import pkg_resources'" [Undecided,New] https://launchpad.net/bugs/810019
<slangasek> cjwatson: do we even need to, though?
<slangasek> cjwatson: normal case: /lib/init/rw is only used by things coordinating with initscripts itself (for sendsigs); /lib/init/rw is already a symlink to /var/run in Ubuntu, with /var/run becoming bind mounted to /run on upgrade; so there's only one sendsigs list on upgrade of a non-chroot, and it's in the right place
<slangasek> continuously-upgraded chroot case: /lib/init/rw is still a directory because the reboot code has never switched it over; but it's a chroot so sendsigs is irrelevant and who cares
<slangasek> newly-installed chroot case: /lib/init/rw is a symlink to either /var/run or /run depending on which version it was bootstrapped with, and will stay that way forever, so that's fine both for chroots that will become booted systems after the install finishes, and for chroots that will remain chroots indefinitely
<Phr3d13> something is wrong regarding via vt6410 pci raid/ide card, the pci card is detected by the system (ubuntu 11.04) but none of the hard drives show up
<Phr3d13> not trying to set up a raid array, just trying to get individual ide drives working
<bryceh> slangasek, on https://launchpad.net/ubuntu/+source/wayland seems to be stuck in pending publication; I merged my package with debian's and that resulted in some changes to binary packages, wondering if that is what's got it blocked?  Any ideas on what I need to do to get it unblocked?
<slangasek> bryceh: yeah, it's in the binary new queue :/  sec, let me hit it with the mallet
<slangasek> bryceh: accepted.  BTW, why are libwayland-client and libwayland-server shipped in a single lib package?  Are they guaranteed to have soname bumps in lockstep?
<bryceh> slangasek, should be, yes.
<slangasek> fair enough
<slangasek> bryceh: in that case, I would suggest adding a lintian override for this, with an explanatory comment to that effect :)
<cjwatson> slangasek: OK, you're right, since it becomes irrelevant we can just not care
<cjwatson> slangasek: it would only be if there are other things in /lib/init/rw that are actually relevant in a chroot, which I'm having trouble imagining
<bryceh> slangasek, ok... I didn't spot an error to this effect when I built the package, what are you seeing?
<slangasek> cjwatson: I've just noticed another wrinkle, which is that the /lib/init/rw symlink migration only happened in maverick so will still be a separate directory by the time /etc/init.d/sendsigs runs on first reboot; but I've convinced myself this doesn't require anything more elaborate than what rleigh already has in place (checking both dirs)
<slangasek> bryceh: $ lintian wayland_0.1.0~0-1ubuntu1_i386.changes
<slangasek> W: libwayland0: package-name-doesnt-match-sonames libwayland-client0 libwayland-server0
<slangasek> W: libwayland-dev: binary-without-manpage usr/bin/wayland-scanner
<cjwatson> slangasek: yes, ISTR there are already places where we check both dirs anyway for similar reasons
<cjwatson> or used to be
<slangasek> cjwatson: eh, "in upgrade from LTS" belongs in that sentence somewhere, but you get the idea :)
<slangasek> yep
<bryceh> slangasek, ah
<cjwatson> I filled that in for myself :)
<Phr3d13> trying to get a vt6410 pci ide card working on ubuntu 11.04
 * Kreative` is away: Away
<ion> !away
<ubottu> Please do not use noisy away messages and nicks in Ubuntu channels. It is annoying and unnecessary. Use the command "/away <reason>" to set your client away silently. See also Â«/msg ubottu GuidelinesÂ»
<seb128> bigon, why a no source change upload rather than a retry build on launchpad?
<bigon> euh the pkg was already built no?
<bigon> d'oh
<seb128> bigon, no, it needed a retry
<seb128> ok, seems an overlook, it's ok ;-)
<soren> kirkland: Sort of.
<soren> kirkland: It's used under certain circumstances in OpenStack.
<kirkland> soren: neat
<slangasek> cjwatson: heh, something has created /run/motd prematurely in my chroot, so that's fun
<slangasek> postinst fails to link the dirs
<slangasek> courtesy of base-files, of course
<bryceh> slangasek, thanks for kicking wayland.  It appears amd64 and armel have gone through, but i386 appears to still be pending.  Do you know what might be blocking it?  https://launchpad.net/ubuntu/+archive/primary/+sourcepub/1817225/+listing-archive-extra
<slangasek> bryceh: probably that it landed after I accepted the other two :) accepting now
<bryceh> thanks
<slangasek> can anyone here tell me if they see a /var/run/run -> /run symlink on their oneiric system?
<seb128> slangasek, not there
<slangasek> ok
<bryceh> slangasek, none here either
<slangasek> then I'll consider it a one-off and wait for the screaming :P
<bryceh> updated yesterday though; I'll update again
<bryceh> (now that I can install wayland on it... yay)
<Phr3d13> any driver developers in here? i can't get my vt6410 pci raid/ide card to work, even though it looks 'supported'
<Phr3d13> any driver developers in here? i can't get my vt6410 pci raid/ide card to work, even though it looks 'supported'
* slangasek changed the topic of #ubuntu-devel to: Archive: publisher on auto, slangasek botched initscripts | 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:
* slangasek changed the topic of #ubuntu-devel to: Archive: publisher on manual, slangasek botched initscripts | 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:
<slangasek> not auto, the other thing
<cjwatson> slangasek: /var/run/run> maybe we should use ln -nsf rather than ln -sf for the sake of paranoia
<directhex> hm. i wonder why libubuntuone is ignoring a configure flag
<slangasek> cjwatson: maybe - but ATM I have bigger concerns, / isn't guaranteed to be mounted rw at the time the /run mounted event fires
<cjwatson> oh, ouch, whoops
<directhex> oh, moot point, the builders have exploded
<cjwatson> I'm not at a proper computer right now - how late is the rw mount?
<slangasek> working that out now
<slangasek> publisher stopped to buy me some breathing room
<bdmurray> Is it just me or would a package installation failure with an Out of memory message in dmesg be suspect?
<cjwatson> depends on what the OOM killer killed
<ogra_> bdmurray, hmm, i had that too today but i blamed arm and my actual low ram
<cjwatson> worth looking a, but doesn't necessarilly invalidate a failure
<cjwatson> *at
<ogra_> dmesg should have some info :)
<cjwatson> you might have had some kind of oom event and then run an upgrade after it had run its course
<directhex> hooray oom killer
<cjwatson> if the oom killer took out dpkg or something, then yeah, not likely to be a valid bug :)
<bdmurray> cjwatson: or something like lzma
<cjwatson> yep.  the more general the thing it killed, the more likely you are to have to pair it up with where the terminal log falls over
<cjwatson> lzma being killed would probably go with something like "dpkg-deb: short read in buffer copy" or whatever that message is
<bdmurray> cjwatson: what the keyboard-configuration post-inst and lzma being killed?
<cjwatson> bdmurray: not sure I see an immediate connection there
<bdmurray> cjwatson: it calls update-initramfs?
<cjwatson> oh yeah
<cjwatson> on live media that would involve lzma
<slangasek> cjwatson: mounted-var isn't as safe as we thought it was, because some of the things under /var/run are sockets... :)
<slangasek> er, wait
<slangasek> no, it's just as safe (and unsafe) with sockets as anything else
<slangasek> vila, james_w: can you explain why the package importer kicked https://code.launchpad.net/~ubuntu-branches/ubuntu/oneiric/sysvinit/oneiric-201107132118 aside?
<slangasek> vila, james_w: I intend to clobber the UDD branch with the original one, which was there for a reason :)
<james_w> slangasek, did you push/merge that branch back to lp:ubuntu/sysvinit?
<slangasek> james_w: yes - that was pushed (immediately) before I uploaded the package
<slangasek> I've now repushed it with --overwrite
<james_w> ok, I'll have to find the old head then to compare
<slangasek> ok
<james_w> it thought that .bzr-builddeb/default.conf and the script you changed were different in the branch and the upload
<slangasek> hmm
<slangasek> that's true since I deleted the .bzr-builddeb/default.conf after tagging - but I didn't think that got included in the upload anyway with bzr bd
<james_w> I can't tell you how they were different right yet, as I'd just be comparing something with itself
<james_w> slangasek, I can't see the revision that you push --overwrote
<slangasek> oh?
<james_w> well
<slangasek> did I get clobbered again? ;)
<slangasek> doesn't look like it
<james_w> if we're being truthful I can
<james_w> just keeping you on your toes
<james_w> or not reading properly
<james_w> one of the two
<slangasek> ;)
<james_w> http://paste.ubuntu.com/643614/
<james_w> that's -importer's +yours
<james_w> but that still doesn't explain it to me
<slangasek> infinity: do you have buildd chroot mangling access these days?
#ubuntu-devel 2011-07-14
<slangasek> james_w: heh
<james_w> slangasek, so, I think it's that you deleted .bzr-builddeb/default.conf and left .bzr-builddeb, and similar for if-up.d
<slangasek> james_w: ah, hmm
<james_w> and the source package didn't conatin the dirs either
<slangasek> because the package won't contain empty dirs, I guess
<james_w> yeah
<james_w> I think this can go in the "immaterial differences" pile
<infinity> slangasek: Sure, and so do you.
<james_w> bug 810218
<ubottu> Launchpad bug 810218 in Ubuntu Distributed Development "spurious collisions when empty dirs are left in the branch with dpkg-source v1" [Undecided,New] https://launchpad.net/bugs/810218
<slangasek> infinity: I mean the kind of mangling that lets you recover from a broken chroot; I obviously have access to do the frontend mangling ;)
<infinity> slangasek: Well, do you mean "kicking buildd hardware violently" (if so, then no), or "abusing chroots in unpleasant ways"?
<infinity> slangasek: If the latter, we can both do it, even if you weren't entirely aware you could. ;)
<slangasek> infinity: abusing chroots to recover from sysvinit-utils being broken in some fashion I have yet to discern
<slangasek> infinity: heh
<infinity> Then yes, we both can do that. ;)
<infinity> But I'm happy to drive for you once you figure out what you want done.
<infinity> (After I eat some food)
<slangasek> infinity: lamont is on it at the moment, but he has a hard cutoff in 2h; maybe you can grab him after food for him to bring you in the loop?
<slangasek> infinity, lamont: sysvinit 2.88dsf-13.10ubuntu3 is the package we need to get build to unbreak the chroots; and sysvinit-utils needs to be put on hold in each of them to get it built
<directhex> will builds which failed due to chroot problems automatically be rescheduled?
<ScottK> All except yours, since you asked.
<lamont> infinity: you wanna come hang in -release for a bit?
* slangasek 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:
<chowder> hi, I know this isn't the place for support but I've been asking the same question on various Ubuntu related channels and no one seems to have a straight answer. Is it at all possible to have Ubuntu 11.04 running as a dom0 vm under xen?
<persia> It ought be, if not, please file a bug.  Precisely how is not something likely to be answered here.  If you aren't getting realtime support, try askubuntu.com
<infinity> chowder: Yes, but not with Ubuntu kernels.
<chowder> infinity, so I'd have to compile my own kernel? wouldn't that cause a lot of issues or make Ubuntu behave in weird ways?
<infinity> chowder: Not so much.  Get some sources with the Xen patches applied, apply the Ubuntu config to it, flip on Xen bits, build, profit.
<infinity> chowder: The hypervisor and tools are packaged in the archive, just not a usable dom0 kernel.
<infinity> chowder: Thankfully, this should not be the case from oneiric and onward, now that Xen is mainline.
 * infinity crosses his fingers.
<chowder> I wish there was a how-to on this. I've messed with the kernel config before and I just remember it being this monstrous collection of options. Enough options to make your head spin
<infinity> chowder: Simplest way is to copy your running config (/boot/config-`uname -r`) to your source tree as ".config", and then run "make menuconfig".
<infinity> chowder: Don't touch anything except to find the Xen stuff and enable it.
<infinity> chowder: Then either "make; make install" if you're old skool and hate package managers, or read up on make-kpkg to roll it into a reasonably usable deb.
<chowder> infinity, that sounds simple enough. I'm on a fresh install and I was dreading having to install another linux distro
<infinity> I really should roll dom0 kernels in a PPA or something.
<infinity> But I've just been doing dom0 on hardy, and waiting on the glory of Linux 3.0 in oneiric.
<chowder> the thing is that I need windows for my uni but virtualbox is about as fast as taffy. So here I am.
<infinity> (And that's another option, if you don't mind using "old" software on your dom0, hardy is still a supported LTS, with perfectly workable dom0 kernels in the archive)
<infinity> Isn't virtualbox just a wrapper around kvm?
<persia> No, it's a separate virtualisation implementation
<infinity> Or maybe I'm thinking of something else.  I dunno.
<infinity> chowder: But that's option 3.  KVM is less hip and cool than Xen with people like me, but it's fast and works on any modern machine.
<chowder> infinity, would I be able to run windows as efficiently on KVM as xen?
<infinity> Should do.
<infinity> And there should be a ton of HOWTOs and guides and such dealing with KVM on the Ubuntu wiki and docs site.
<infinity> Since it's what all the young'uns are using.
<infinity> And no kernel futzing.
<chowder> idk, I'm doing all of this for school so I'm basically building a production environment. I don't wanna use KVM and then regret it for w/e reason
<infinity> Plenty of people use KVM in production.
<infinity> I'm just not one of them. :P
<persia> Every virtualisation environment is annoying for one reason or another.  Today, kvm probably has the best documentation available.
<infinity> persia: Xen's not annoying to anyone who grew up on IBM kit.
<chowder> I'm looking into kvm now. its like an epic battle between KVM and Xen. THERE CAN BE ONLY ONE!
<persia> infinity, Not annoying in *any* way?  Not even a little?
<infinity> persia: Well, it fails to annoy me.  And everything annoys me.
<persia> infinity, Given comparative search results for "virtualbox annoying", "xen annoying", and "kvm annoying", I think you're special.
<infinity> Hahaha.
<nigelb> heh
<infinity> persia: They're all close enough to discount variance as statistically insignificant. :P
<persia> Right, so if you find one more annoying than another, then you're not following statistical norms, hence "special"
<infinity> persia: Besides, I also had the "if you grew up with IBM VM" qualifier, which is a pretty small subset of people.
<infinity> persia: Most of whom likely don't blog.
<lifeless> internet, whats that?
<infinity> Ed Zachary.
<persia> That could be interpreted to indicate that "Xen annoying" is underrepresented, but I choose not to so interpret it, as I don't believe you'd undermine your argument that way.
<infinity> persia: Other way around; I'd say that old farts who don't blog are likely to find virtualbox and kvm annoying, but not whine about it publically.
<persia> Oh my.  With "IBM VM $virtualisation_tool Annoying", KVM loses by a factor of two, compared with Xen and virtualbox.
<infinity> Besides, we all know the Internet is just for IRC: http://www.youtube.com/watch?v=O2rGTXHvPCQ
<nigelb> infinity: Oh god, is that the num3rs one?
<nigelb> hah, yes.
<infinity> Yup. :)
<nigelb> The 1337 bits in that annoys me more than the "primite chat program" bit :/
<infinity> Luckily, I speak l33t!
<nigelb> *primitive
<bryceh> whew, they got a screenshot
<infinity> bryceh: It was touch and go there for a bit.
<pitti> Goodm orning
<RAOF> Good morning, pitti
<bryceh> pitti, orning to you too
<pitti> bryceh: 'ow are you?
<pitti> hey RAOF
<bryceh> pitti, ood!
<pitti> meh, what happened to the Windows key?
<pitti> ah, nevermind, keyboard fail
<RAOF> Heh.
<pitti> bdmurray: will do, thanks!
<pitti> slangasek: impressive sysvinit merge changelog!
<slangasek> pitti: s/impressive/eye-bleeding/ :)
<pitti> ah, just recovered from a reboot
<pitti> slangasek: it seems to break ecryptfs once again :/
<slangasek> oh, really?
<slangasek> how does it do that?
<pitti> slangasek: it stumbles upon -EACCESS on /dev/shm/
<slangasek> hmmm
<pitti> it seems that /dev/shm is now root:root 755
<pitti> moving it to 777 temporarily fixes things again
<pitti> was it 777 before?
 * pitti boots an older live CD to check
<slangasek> pitti: eh, it was meant to be a symlink to /run/shm
<pitti> hm, /run/shm/ looks fine indeed
<pitti> the other thing that I found is
<pitti> none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
<pitti> none on /run/shm type tmpfs (rw,nosuid,nodev)
<pitti> tmpfs-on-tmpfs, but that's merely a curiosity right now
<pitti> slangasek: do you know what is responsible for setting up /dev/shm? udev, initramfs, mountall?
<slangasek> deliberate
<pitti> ah, /run/shm needs to be "exec"?
<slangasek> does it?
<slangasek> do you have /dev/shm as a symlink to /run/shm, or is it still a real directory for you?
<pitti> I don't know, but different mount options seems like the reason for doing this?
<slangasek> ah
<slangasek> no, the reason is the different write perms
<pitti> it's a real dir
<slangasek> /run/shm is world-writable, as is /run/lock for historical reasons; /run must be root-only to avoid DoSes
<slangasek> right, I see what went wrong with /dev/shm
<slangasek> it should be in the initscripts umountroot script... I failed to include that when I migrated stuff from mountall startup to initscripts shutdown
<pitti> (phone, brb)
<pitti> slangasek: well, mere access permissions wouldn't need a mount-on-mount, but different mount options certainly do
<pitti> e. g. /run/shm/ needs "dev", while /run/lock certainly should be "nodev" as it's world writable
<slangasek> pitti: no, they absolutely do need mount-on-mount because there's no quotas on tmpfs
<pitti> anyway, so the mount-on-mount seems to be on purpose then
<slangasek> uploaded a fix for the /dev/shm bit
<slangasek> (sysvinit ubuntu4)
<pitti> merci beaucoup! that was fast
<slangasek> pitti: well as soon as you asked me what's responsible for setting it up, I realized my bug ;)
<slangasek> hmm, actually, that's an incorrect/incomplete fix... I need to poke mountall
<slangasek> pitti: ok, now I'm really puzzled... I just realized /dev/shm is a symlink here and I don't know *how*
<slangasek> so I may be piling on irrelevant kludges at this point
<pitti> sheer willpower from your side?
<slangasek> that seems unlikely, since I largely ignore /dev/shm anyway :)
 * pitti snatches the built debs from LP and installs
<slangasek> but /dev is not persistent, being a devtmpfs
<slangasek> so something is creating the directory for you at boot time
<slangasek> and something created a *symlink* for *me* at boot time
<slangasek> and I can't find what the 'something' is in either case
<pitti> I'll reboot with new sysvinit, and if it still doesn't work, go through my system with a fine comb and see what creates /dev/shm
<pitti> ok, so sysvinit ubuntu4 didn't help
<slangasek> right
<slangasek> it "helps" in the unusual case that /dev is not actually a devtmpfs
<slangasek> ... which is unsupported, so
<slangasek> pitti: you have mountall 2.29 as well?
<pitti> yep
<pitti> oneiric up to date
<pitti> ok, so the only match of "shm" in /etc/init/ is ecryptfs-utils-*, which only touches files in /dev/shm/
 * slangasek nods
<pitti> oh, wait
<pitti> ./schroot/buildd/fstab:tmpfs/dev/shmtmpfsdefaults00
<pitti> no, that's only for within a schroot
<slangasek> so, if you had the old mountall installed, that would account for /dev/shm being mounted with the traditional perms (rwxrwxrwxt)
<slangasek> with the new packages, I can't account for *anything* creating /dev/shm, as either a symlink or a dir
<pitti> might it be possible that it's just part of a standard devtmpfs?
<slangasek> that seems unlikely to me
<pitti> sudo mount -t devtmpfs none /mnt
<pitti> $ ls -ld /mnt/shm/
<pitti> drwxrwxrwt 2 root root 120 2011-07-14 07:20 /mnt/shm/
<pitti> so it is part of devtmpfs, but with correct permissions
<slangasek> hmm
<broder> ugh, that sounds like a race condition waiting to happen...
<pitti> devtmpfs tries to be "clever" enough to provide everything you need even in an init=/bin/bash session
<slangasek> "with correct permissions" - nah, permissions on the symlink don't matter
<pitti> slangasek: no, it's a dir in standard devtmpfs
<pitti> so we now need to look for what changes the permissions
<slangasek> pitti: oh, actually, I think mounting multiple copies of devtmpfs just gives you a mirror of the same fs :)
<pitti> ah, perhaps
<slangasek> pitti: because when I mounted it *here*, I got shm -> /run/shm again :)
<pitti> slangasek: ok, rebooting again into init=/bin/bash and checking it there
<slangasek> broder: what race condition?
<broder> slangasek: if there's a window between when /dev/shm exists and when it gets changed to a symlink
<slangasek> broder: yeah, there's not meant to be one because it's not meant to exist except as a symlink
<pitti> ok, no /dev/shm/ with just init=/bin/bash
<pitti> it's not created in the initramfs either
<broder> i wonder if, like, libc somehow creates it or something equally hideous
<pitti> doesn't seem to be udev, just grepped its source
<pitti> slangasek: which bit would make it a symlink to /run/shm?
<slangasek> pitti: that's just it, I don't see one anywhere
<slangasek> I don't see what creates it as a directory either
<pitti> I'm done checking /etc/ and /lib
<pitti> and udev sources
 * persia thought /dev/shm was a virtual directory provided by the kernel
<slangasek> well, http://en.wikipedia.org/wiki/Shared_memory tells me the kernel provides it by default on Ubunut
<slangasek> Ubuntu
<slangasek> so if wikipedia says so... :P
<pitti> hm, maybe it's created by a module, which isn't loaded yet in init=/bin/bash?
<slangasek> persia: except that mountall was previously set up to mount /dev/shm as a tmpfs on boot
<persia> slangasek, Do you happen to know *when* that was introduced?  /dev/shm used to be a tmpfs, but I don't think it has been since at least maverick.
<persia> Hrm, but my memory doesn't match the output of `mount` on a natty system :(
<slangasek> persia: when what was introduced?  the mountall handling?
<pitti> persia: /dev/ itself is a devtmpfs, so it doesn't need to be a mount on top of it
<pitti> I upgrade my oneiric VM, to avoid having to reboot so often
<pitti> and snapshots FTW
<pitti> persia: you are right indeed
<pitti> none on /dev/shm type tmpfs (rw,nosuid,nodev) in alpha-2, so it was indeed mount-on-mount
<persia> That's the mount from mountall
<pitti> right
<slangasek> frankly, I can't work out from this why we have /dev/shm at all
<slangasek> the justification I've always heard was "filesystem exposure of SHM for IPC"
<slangasek> but I see nothing that ties this to the POSIX SHM APIs
<RAOF> Doesn't libc use it to provide the SHM API?
<broder> glibc's implementation requires /dev/shm to be a tmpfs for shm_open et al to work
<slangasek> ah
<broder> also for the semaphore API to work, i think?
<broder> but it turns out that shm_open(foo) is actually just open("/dev/shm" foo)
<slangasek> right, I wasn't thinking that the mapping would happen in libc; I thought there were syscalls for shm/sem
<persia> "everything is a file" :)
<lifeless> even things that really shouldn't be
<persia> So, I could be mistaken, but I believe that mm/shmem.c triggers the creation of /dev/shm when devtmpfs is initialised (assuming that SHM support is configured in the kernel)
<slangasek> hmm
<slangasek> why the blazes did Debian move this to /run at all then
<broder> persia: if that's the case then why did mountall need to mount /dev/shm?
<persia> Right, and ./drivers/base/devtmpfs has dev_mkdir("shm", 01755); in __init int devtmpfs_init(void)
<persia> broder, I think that predated devtmpfs, but that's just a guess.
<persia> broder, And it has been a bug since we started using devtmpfs, but nobody cared in practice, because it doesn't really matter *why* /dev/shm is a tmpfs
<broder> huh, i guess that's an ubuntu special? i have lxr pulled up and was skimming upstream and don't see that mkdir
<pitti> I upgraded my clean alpha-2 instlal oneiric VM, and I also get /dev/shm 755 as a dir
<pitti> not 1755
<persia> broder, It's from <1241097822.2516.3.camel@poy>, from linux-kernel@vger
<pitti> so it seems our previous mountall just papered over the broken devtmpfs permissions then?
<broder> persia: uh, that's not in our kernel
<slangasek> persia: but it does matter that the perms aren't 755...
<broder> http://paste.ubuntu.com/643796/ is Ubuntu-2.6.38-9.43:drivers/base/devtmpfs.c
<broder> (easiest tag to grab)
<persia> slangasek, Found it: in Debian kernels, # CONFIG_DEVTMPFS_MOUNT is not set and in Ubuntu kernels CONFIG_DEVTMPFS_MOUNT=y (at least on a randomly selected pair of my systems)
<pitti> yes, and that's fine IMHO
<slangasek> persia: I also can't find this dev_mkdir() call in the current kernel
<persia> pitti, Should be fine, but it might explain why things are different in Ubuntu/Debian
 * persia grabs current kernel sources, rather than trusting memory and mail logs
<pitti> so you reckon devtmpfs creates /dev/shm the first time a program tries to access devtmpfs?
<slangasek> I don't see how it would
<broder> CONFIG_DEVTMPFS_MOUNT affects automatically mounting of /dev itself, not /dev/shm
<pitti> still doesn't explain why slangasek gets a symlink for it
<slangasek> fwiw, the timestamp on the symlink exactly matches that of the other nodes created at boot
<slangasek> created 3 seconds before /dev/sda, actually
<pitti> oh, that's an interesting point
<pitti> in my VM, all nodes are from 2011-07-14 07:55, i. e. when I booted
<pitti> but /dev/shm is from 2011-06-28 19:12
<pitti> which might be when I created that VM
<broder> devtmpfs doesn't bleed through what's under it, does it?
<pitti> perhaps it does something crazy like that?
<pitti> either that, or an init script "restores" /dev/shm from somewhere else
<slangasek> well, I checked for that with mount -obind / /mnt
<slangasek> /mnt/dev/ was completely empty here
<pitti> mine isn't, I have a fairly well populated one
<pitti> but there /dev/shm is root:root 0755 (same perms) but 2011-07-05 11:30
<pitti> i. e. yet another date, which is in between
<slangasek> right, no idea then
<broder> wait, what do you guys have in /lib/udev/devices?
<pitti> broder: you rock
<pitti> /lib/udev/devices/shm 2011-06-28 19:12 0755
<pitti> that very timestamp, that permission
<broder> the udev package ships /lib/udev/devices/shm
<pitti> slangasek: ^ is that a symlink for you by any chance?
<slangasek> pitti: nope :/
<pitti> broder: I thought I got rid of all these a while ago, apparently I missed some
<pitti> udev (093-0ubuntu13) edgy; urgency=low
<pitti>   * Make sure that net, pts and shm sub directories exist under
<pitti>     /lib/udev/devices in the package.  Ubuntu: #57436.
<broder> that still doesn't explain where slangasek's symlink is coming from, of course
<pitti> no, but at least explains the other half of the story
<persia> slangasek, Have you had a /run/shm/shm directory?
<pitti> when I remove /lib/udev/devices, I now don't have a /dev/shm/ at all any more
<slangasek> let's chalk my symlink up to somnoclavicism for the moment
<pitti> and with devtmpfs /lib/udev/devices should be entirely obsolete
<slangasek> pitti: after a reboot, or it disappears immediately?
<pitti> slangasek: after reboot
<slangasek> persia: no
<pitti> slangasek: udevd does that on startup
<pitti> (copy /lib/udev/devices/* to /dev/)
<jbicha> y'all's shm problems broke my Chromium! ;-)
<slangasek> pitti: k
<pitti> I'd prefer to fix udev to remove /lib/udev/devices/ entirely; it's time to get rid of this hack
<pitti> question is now, what should create /dev/shm -> /run/shm ?
<slangasek> pitti: well, /etc/init/mounted-dev.conf probably should
<pitti> (or why did we move it in the first place)
<slangasek> I was halfway to uploading that when I realized I didn't know what was going on
<pitti> oh dear, this thing _also_ copies /lib/udev/devices
<broder> looks like /etc/init.d/mountdevsubfs.sh does it in debian-land? so mounted-dev seems like it makes sense
<slangasek> oh, hah
<pitti> slangasek: as udevd already does that, this bit should go away then
<pitti> slangasek: but will that be early enough? i. e. initramfs stuff trying to use /dev/shm ?
<slangasek> pitti: tell you what, it's late here, how about if I leave it in your hands to decide what to do with it :)
<broder> pitti: it would have to be - nothing would mount /dev/shm in the initramfs previously, right?
<pitti> broder: correct
<pitti> it only works now because of that /lib/udev/devices/ uglyness, and as the initramfs is all root processes, they don't midn the permissions
<pitti> slangasek: ok, will do; sleep well then!
<slangasek> thanks :)
<slangasek> pitti: eh, where would it get /lib/udev/devices inside the initramfs though?
<slangasek> I think it's more likely that nothing in the initramfs has ever cared about shm
<pitti> $ zcat /initrd.img | cpio -t|grep udev/devices
<pitti> indeed, nothing copies it
<pitti> slangasek: so much the better :)
<broder> and if anything ever was expecting there to be a /dev/shm that early in the boot, it'd be a poster child for why we need /run in thef irst place
<slangasek> pitti: btw, if you get that licked, I have one other bug I've noticed... I think the udev/initramfs-tools changes have broken the use of /dev/.initramfs to transfer pid info from the initramfs to the rootfs for upstart
<pitti> ah, that seems to be in the code
<persia> Aha.  So the kernel used to, and no longer generates /dev/shm (apparently there was some dispute about whether everyone wanted it that way).  The current kernel devtmpfs stuff only creates 0755 directories for things that define devnode sensibly, for real nodes, meaning that distributors are required to create /dev/pts and /dev/shm manually
<pitti> persia: thanks!
<persia> (the rest of /lib/udev/devices ought be obsolete with devtmpfs, as those have real nodes)
<pitti> ok, so I think I now have everything together to fix this
<pitti> - remove /lib/udev/devices/ for good, and clean up on upgrades (udev)
<pitti> - remove the copying in /etc/init/mounted-dev.conf (mountall)
<pitti> - have mountall upstart script create the symlink to /run/ (mountall)
<persia> pitti, And mountall mounts /dev/pts (devpts), and /run/shm (tmpfs)?
<broder> mountall upstart script> you mean mounted-dev.conf, right?
<pitti> broder: I'm not actually sure, as /dev/ already gets mounted by the kernel
<pitti> ideally mounted-dev.conf wouldn't even run, except for a kind of "coldplugging" run
<broder> pitti: mountall emits mounted events for fs's that were mounted before it runs
<pitti> persia: yes, see /lib/init/fstab
<persia> Also compatibility for folks who don't have devtmpfs for some reason.
<pitti> broder: it's easy enough to test
<pitti> persia: does that even work still?
<broder> pitti: look at mark_mounted in src/mountall.c
<persia> pitti, That says "/dev/shm": should it say "/run/shm"?
<pitti> /lib/init/fstab:none            /run/shm                  tmpfs           nosuid,nodev
<persia> pitti, I haven't tested it, but /etc/init/mounted-dev.conf still has compatibility code in it.
<pitti> /lib/init/fstab:none            /dev/pts                  devpts          noexec,nosuid,gid=tty,mode=0620   0 0
<pitti> persia: yes, I'll keep that minimal bit
 * persia updates that chroot
<broder> hmm...actually, should the /dev/shm symlink get created on mounted MOUNTPOINT=/run/shm ?
<pitti> broder: in theory that'd race with mounting of /dev
<pitti> in the case when devtmpfs isn't mounted by the kernel
<pitti> Ubuntu kernels do, so it's not a problem there
<broder> bah. fine - mounted MOUNTPOINT=/run/shm and mounted MOUNTPOINT=/dev
<pitti> but I think it's safer to create the link in mounted-dev
<persia> I don't think we care if /run/shm is mounted when the symlink is created.
<pitti> right
<broder> hmm...i'm not actually convinced that glibc will handle /dev/shm-as-a-symlink correctly. i wonder if anybody's tested this
<pitti> I fixed my vm with /dev/shm -> /run/shm, and /run/shm/ has the pulse stuff now
<broder> i'm probably just misreading the code
<pitti> but for the sake of avoiding the symlink lookup every time, eglibc should probably be changed to use /run/shm/ right away?
<broder> based on http://wiki.debian.org/ReleaseGoals/RunDirectory#Packages_using_.2BAC8-dev.2BAC8-shm it looks like debian isn't planning to change eglibc yet
<broder> "If we do eventually deprecate /dev/shm in favour of /run/shm"
<pitti> ah, good
<cjwatson> symlink lookups will be lost in the noise, I expect
<pitti> cjwatson: good morning
<pitti> cjwatson: while I'm at it, would you mind if I change udev-udeb's lib/debian-installer/start-udev script away from mounting a tmpfs on /dev and doing mknod?
<pitti> cjwatson: as the kernel mounts a devtmpfs anyway, and in the installer environment we can rely on an Ubuntu kernel, we could in theory drop it altogether
<pitti> but I'm happy to do a "mountpoint /dev || mount -t devtmpfs devtmpfs /dev" kind of thing instead
<pitti> or if "mountpoint" availability is questionable, just
<pitti> [ -e /dev/null ] || mount ...
<pitti> cjwatson: http://paste.ubuntu.com/643841/
<infinity> pitti: Pretty common when bootstrapping on weird new subarches to not always have an Ubuntu kernel handy, pretty please don't assume the kernel will DTRT based on Ubuntu configs. :)
<pitti> infinity: right, see pastebin: it still mounts it manually
<tjaalton> cjwatson: re: grub blacklist> is it necessary to run update-grub after adding a new entry, and does it matter which device is listed there? (I'd assume it's checking the graphics chip)
<pitti> broder: ... and ecryptfs seems happy with the symlink, too
<pitti> (if it weren't, I couldn't talk to you in the first place :) )
<cjwatson> pitti: you're guaranteed not to have 'mountpoint' in the installer
<cjwatson> pitti: shrug, I guess - seems plausible enough
<pitti> http://paste.ubuntu.com/643841/ uses [ -e /dev/null ]
<pitti> cjwatson: ok, thanks; I'll upload that, and test tomorrow's alternate
<cjwatson> tjaalton: you need to run update-grub-gfxpayload, but not update-grub.  It matches any PCI device with class 3
<tjaalton> cjwatson: ok, thanks
<pitti> kirkland: if you get reports about ecryptfs breaking today, please point people at udev 172-0ubuntu3 and mountall 2.30
<pitti> $HOME, sweet $HOME
<dholbach> good morning
<pitti> hey dholbach *hug*
 * dholbach hugs pitti back
<MacSlow> anybody with some Mono/autotools experience here?
<MacSlow> I wonder why NotifyOSD's configure can find "Mono 2.0 GAC Mono.Posix.dll" although it's certainly installed
<RAOF> MacSlow: Got a pastebin?  It's likely that it should instead be trying to find a 4.0 GAC Mono.Posix.dll.
<MacSlow> RAOF, just tired the same with 4.0... didn't fix it
<MacSlow> RAOF, what do you want to see pasted... configure.in, error-message, config.log?
<RAOF> error message and configure.{in,ac}, I guess.
<RAOF> Or I could just grab the source package, I guess - is it in the archive?
<MacSlow> RAOF, bzr branch lp:notify-osd
<MacSlow> RAOF, make sure to call it with like ./autogen.sh --with-examples=mono
<MacSlow> RAOF, I've both (2.0, 4.0) version of libmono-posix-cil installed
<RAOF> I suspect you need to install libmono-cil-dev; that's what contains mono.pc.
<MacSlow> RAOF, there' no corresponding -dev for libmono-posix2.0/4.0-cil
<RAOF> That's correct; it's a mono corelib.
<MacSlow> RAOF, I'll try installing all mono-related -dev packages
<RAOF> You should *only* need libmono-posix$SOMETHING and libmono-cil-dev.
<RAOF> I'm just hunting down the other build-depends that I don't have, like libwnck-3-dev :)
<MacSlow> RAOF, libnotify0.4-cil and libnotify-cil-dev you'll need too
<RAOF> So, it works for me with libmono-cil-dev and libmono-posix2.0-cil.
<MacSlow> RAOF, here too now
<MacSlow> RAOF, at least it compiles... I'll to my usual testing then... thanks!
<pitti> cjwatson: fixing yelp binary overrides (last CD build failure)
<pitti> jbicha: thanks for this!
<jml> what ho!
<apw> i have just updated oeniric as of this morning and libyelp0 installation breaking colliding with libyelp ?
<apw> is this a known issue, or do i need to report same
<jbicha> apw: known issue, bug 810258
<ubottu> Launchpad bug 810258 in yelp (Ubuntu) "package libyelp0 3.1.1-0ubuntu1 failed to install/upgrade: trying to overwrite /usr/lib/libyelp.so.0.0.0, which is also in package yelp 3.0.3-0ubuntu2" [Undecided,Confirmed] https://launchpad.net/bugs/810258
<persia> apw, Yelp was last pushed 3 days ago, and I don't see anything listed in NBS that should still need the old one.
<Daviey> apw: Out of interest, have you rebooted following the update?
<apw> Daviey, nope, i have just apt-get install -f 'd my way to a completed install
<apw> Daviey, should i be scared, as i would now reboot
<Daviey> apw: so, i hit the same yelp bug.. but didn't -f install.. power died, and not it's failing to boot.
<Daviey> It's not registering as a successfull boot after waiting, as hard powercycle is showing grub menu.
<Daviey> (not a kernel issue tho, as prior ones are working)
<Daviey> are NOT working rather
<jbicha> yelp being broken won't mess up your boot
<apw> Daviey, wekk t
<apw> Daviey, well the first two things it did after the -f were mountall and libdbus
<Daviey> jbicha: well yes.. but the reason i was asking was because i thought apw would be running the same archive snapshot as me.
<apw> so i'll reboot and see if the completed install works
<apw> its a machine i can live without
<Daviey> wish i could say the same :)
<jbicha> oh, I've had trouble with installs not completing and it can break things pretty badly, apt-get -f install fixed it though
<apw> Daviey, ok so mine rebooted and logged in just fine, so you will need to complete the install
<apw> Daviey, can you select recovery boot from the menu?  that should give you the option to fix it i think
<Daviey> apw: reovery isn't working either... nor networking.  It's not getting that far, but userspace does seem to start.  I'll chroot in.
<apw> yeah i suspect its mountall
<Daviey> super
<pitti> jdstrand: do you have some time to look at the apparmor part of bug 810270? should that go into some upstream-ish vcs? (affects Debian, too)
<ubottu> Launchpad bug 810270 in isc-dhcp (Ubuntu Oneiric) "AppArmor profiles need updates for /var/run â /run" [High,Triaged] https://launchpad.net/bugs/810270
<brendand> doing dist-upgrade today:
<brendand> Errors were encountered while processing:
<brendand>  /var/cache/apt/archives/libyelp0_3.1.1-0ubuntu1_i386.deb
<brendand> E: Sub-process /usr/bin/dpkg returned an error code (1)
<cjwatson> brendand: see scrollback
<brendand> just upgraded my Oneiric and now I can't log in
<anthony_dev> how I can make image in project to be embedded in my app? (currently I load it using gtk_image_new_from_file)
<brendand> trying to roll back lightdm, but struggling to figure out the Pin: version i need to give
<cjwatson> brendand: more precise symptoms?
<brendand> there's this https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/810271
<ubottu> Ubuntu bug 810271 in lightdm (Ubuntu) "lightdm user list disappears when a user is clicked" [Critical,Confirmed]
<brendand> the reporter worked around it by using xdm
<brendand> which i haven't tried yet, but if i try gdm then it complains about ICEauthority
<cjwatson> if I wanted to roll something back, I'd download the .deb from Launchpad and dpkg -i it, rather than using pins (which likely won't help given that the old version will probably have been garbage-collected)
<cjwatson> brendand: bug 809776 too, perhaps
<ubottu> Launchpad bug 809776 in lightdm (Ubuntu) "needs tighter dependency on liblightdm-gobject-0-0" [Medium,Triaged] https://launchpad.net/bugs/809776
<cjwatson> brendand: is your liblightdm-gobject-0-0 package at an older version than lightdm?
<cjwatson> or rather, than lightdm-greeter-example-gtk
<brendand> cjwatson - no
<brendand> all at 0.4.3-0ubuntu1
<cjwatson> ok, don't know then
<cjwatson> 0.4.3-0ubuntu1 worked for me, might be some deeper problem
<cjwatson> with no logs, who can say
<Riddell> from the new packaging guide "Note however that it is considered bad practice to add a patch system
<Riddell> to a package that does not already have one." this seems incorrect to me, I'd rather add a patch system than have to edit files directly
<Riddell> dholbach: agree?
<cjwatson> Riddell: that's been standard advice in Ubuntu for as long as I've been around.
<brendand> where should i look for older versions of lightdm?
<cjwatson> it's inherited from the best practice in Debian that you don't muck about with packaging when NMUing; and the reason to carry that over into Ubuntu is that it makes it easier to forward patches to Debian
<dholbach> Riddell, I'd personally try to go with whatever the package already has
<cjwatson> brendand: https://launchpad.net/ubuntu/+source/lightdm
<brendand> .deb files
<pitti> Riddell, cjwatson: hopefully more and more obsoleted with 3.0 (quilt) packages these days
<cjwatson> (and makes Debian developers less likely to flame us when they look at the diff in Ubuntu)
<cjwatson> pitti: yes
<cjwatson> 3.0 (quilt) is nearing 50% adoption now
<pitti> oh, wow
<pitti> incidentally, I'm just converting cups from dpatch to quilt :)
<pitti> bit of an exercise, as we have two ubuntu specific patches
<pitti> debian/patches/ubuntu.series is not quite what I need
<pitti> I'm pondering an extra quilt call in debian/rules for dpkg-vendor --is ubuntu
<cjwatson> ubuntu.series is awkward IME, you have to duplicate the whole series
<pitti> right
<cjwatson> tempting to autogenerate it somehow ...
<cjwatson> (but I have seen packages that make use of the fact that you can leave out Debian patches from ubuntu.series)
<kirkland> pitti: hum, okay; is that about the /dev -> /run change?
<pitti> kirkland: yes
<dpm> hi cjwatson, shall I approve the live-helper.pot and live-build.pot templates in LP? Are they supposed to be delivered through language packs?
<cjwatson> dpm: I believe so
<dpm> cjwatson, thanks, approved and marked as translations in langpacks
<dupondje> https://launchpad.net/ubuntu/+source/gnome-shell/3.0.2-1svn2build1
<dupondje> could somebody rebuild this ?
<dupondje> should build fine now
<dupondje> (just tested in pbuilder and its fine)
<micahg> dupondje: given back, thanks
<dupondje> thanks micahg
<dupondje> Installing my new laptop, and gnome3 refused to install :P
<dupondje> mmm
<dupondje> but it failed again on i386
<ogra_> use arm
<jdstrand> pitti: the /var/run -> /run symlink has caused a big mess with apparmor beyond isc-dhcp
<jdstrand> (and cups)
<jdstrand> pitti: I'm going through all the profiles now and adding them to the bug
<dupondje> The following packages have unmet dependencies: gir1.2-clutter-1.0 : Depends: gir1.2-json-1.0 but it is not going to be installed
<dupondje> but WHY oh WHY :)
<pitti> jdstrand: yeah, the /run transition has been "fun", breaking keyboards/mouses, ecryptfs, apparmor, etc :)
<pitti> but Debian already did it, so I hope it's not too much left
<jdstrand> it just would have been nice to coordinate it. I hadn't planned on fixing all these today and am having to juggle a bunch of things as a result...
<pitti> jdstrand: yeah, I'm not sure what happened exactly; from what I heard, there were staged changes in base-files, which someone uploaded prematurely, and then the rest of it was by and large done "under the gun"
<jdstrand> meh
<jdstrand> ok
<dupondje> the launchpad builders always have up-to-date packages no? or is there some lagg ?
<pitti> dupondje: they (by and large) see what archive.u.c. has, i. e. they are also subject to publisher runs
<dupondje> weird it can't find gir1.2-json-1.0 :s
<pitti> it does
<pitti> it's just uninstallable
<pitti> or, rather, was
<dupondje> https://launchpadlibrarian.net/75228082/buildlog_ubuntu-oneiric-amd64.gnome-shell_3.0.2-1svn2build1_FAILEDTOBUILD.txt.gz
<pitti> probably unfortunate timing
<pitti> as it's not on http://people.canonical.com/~ubuntu-archive/testing/oneiric_probs.html right now, I'd just try a rebuild
<dupondje> well micahg did that 14:21 :s
<pitti> oh, hmm
<ogra_> publisher race ?
<dupondje> would be cool if it builded :) then I could install gnome3 again.
<jdstrand> pitti: this is going to need a release note
<jdstrand> pitti: for people upgrading who have custom profiles
<jdstrand> pitti: has one been started?
<pitti> yes, a change of that magnitude should go there indeed
<pitti> jdstrand: AFAIUI, it's derived from TechnicalOverview at beta/release time
<pitti> before that we track news and upgrade issues in one document
<jdstrand> skaet: ^ where should we add this?
<pitti> jdstrand: hm, was going to snatch some updates from you, but apparently with the new LP I can't reassign ubuntu tasks any more
<pitti> ah, nevermind, just the ajaxy thing; the task expander still works
<jdstrand> pitti: this is the change I did for gdm-guest-session:
<jdstrand> -  /var/run/** rmwkix, # necessary for writing to sockets, etc.
<jdstrand> +  /{,var/}run/** rmwkix, # necessary for writing to sockets, etc.
<pitti> ah, you did already? assigning back then
<jdstrand> pitti: well, I haven't uploaded yet, but was going to very soon
<jdstrand> pitti: I think I've got a handle on it
<jdstrand> pitti: thanks
<pitti> jdstrand: I can help out with some other packages; just toss me some?
<pitti> since I got sucked into that /run thing anyway, may just as well finish it off :)
<pitti> cups built, upload coming
<pitti> tkamppeter_: ^ that also updates to 1.4.7, FYI
<jdstrand> pitti: well, libvirt needs code changes. how about I take apparmor, libvirt, isc-dhcp and clamav, and you take the rest?
<jdstrand> (I'll also take gdm-guest-session)
 * pitti grabs bind9, ntp, openldap for now
<pitti> can do mysql as well after these
<jdstrand> pitti: fyi: sed -i 's#/var/run#/{,var/}run#' <profile>
<pitti> but let's start with the smaller ones
<pitti> yep
<pitti> jdstrand: var/lock, too, right?
<jdstrand> pitti: yes, it is: sed -i 's#/var/lock#/{run,var}/lock#' <profile>
<micahg> jdstrand: don't forget about /run/shm in apparmor/libvirt (should I add that to the bug)?
<ximion> hi! Could someone please restart the builds of "easymp3gain" on Oneiric for me? (builds FTBFS due to dependency issues months ago)
<jdstrand> micahg: hmmm, good point
<jdstrand> micahg: yes please
<pitti> (FTR, checking for shm as well)
<jdstrand> pitti: it looks like /dev/shm is still hagning around, but as 0755. should this point to /run/shm as well?
<Riddell> dholbach: ok if I set bug 702006 back to confirmed?  the guy hasn't done anything since february
<ubottu> Launchpad bug 702006 in Ubuntu Packaging Guide "Add article "Packaging from Scratch"" [Undecided,In progress] https://launchpad.net/bugs/702006
<pitti> jdstrand: right; bug which breaks ecryptfs, I fixed it this morning
<pitti> jdstrand: latest udev and mountall
<jdstrand> k
<micahg> jdstrand: updated title
 * jdstrand looks for /dev/shm as well
<Riddell> mok0: is bug 704845 still in progress?
<ubottu> Launchpad bug 704845 in Ubuntu Packaging Guide "Add article explaining how to work with Debian/Upstream" [Undecided,In progress] https://launchpad.net/bugs/704845
<brendand> pitti - ecryptfs got broken?
<pitti> brendand: well, it failed with -EPERM on /dev/shm/
<pitti> brendand: that's fixed now
<pitti> no data loss or anything of that sort :)
<pitti> http://cdimage.ubuntu.com/daily-live/20110714.1/
<pitti> hooray! and it only took 10 days
<pitti> jdstrand: ^ (another victim of /run transition :) )
<jdstrand> heh
 * ogra_ hugs pitti 
<pitti> but 30 MB oversized now (a2 was 15)
 * pitti sighs deeply
<pitti> how hard can it be to not grow fat!
 * ogra_ looks down and notices he would like to know that too 
<pitti> 35 MB oversized, even
<pitti> meh, and something broke isoinfo on antimony
<pitti> ah, nevermind, that was user error
<pitti> just a confusing error message ("cannot open SCSI driver" - meh?)
<dholbach> Riddell, sounds good, yes
<dupondje> dunno if somebody could have a look at https://launchpad.net/ubuntu/+source/gnome-shell/3.0.2-1svn2build1 . It doesn't build on launchpad for some obvious reason. In a local pbuilder it builds fine.
<pitti> dupondje: did you try retrying the build already?
<sladen> dupondje: "The following packages have unmet dependencies:"
<pitti> before doing anything else, I'd do that after the next publisher finishes..
<pitti> when we have such transient uninstallability
<sladen> dupondje: do have a locally-built dependency that isn't yet built/in the archive?
<dupondje> pitti: micahg tried it an hour ago. Maby we can try again, but I don't have such permissions :)
<pitti> dupondje: kicked
<dupondje> sladen: nope, pbuilder-dist which is up-to-date
<pitti> if it fails again, someone needs a oneiric chroot and investigate
<pitti> but it installed here just fine
<pitti> and g-shell is universe, so it's not a component-mismatches issue
<dupondje> failed again :(
<sladen> "invoke-rc.d: policy-rc.d denied execution of start." ... is that anything to do with slangasek breaking initscripts yesterday?
<dholbach> Riddell, thanks for the update on merge proposal - if barry can give his go-ahead, feel free to merge
<dholbach> (I'm not 100% up to date it seems :-))
<pitti> sladen: sorry for the obvious question, but is that a chroot? do you actually have a policy-rc.d?
<pitti> sladen: or is the error message just horribly wrong?
<dholbach> barry, I was talking about Riddell's ubuntu-packaging-guide MP
<sladen> pitti: https://launchpadlibrarian.net/75228003/buildlog_ubuntu-oneiric-i386.gnome-shell_3.0.2-1svn2build1_FAILEDTOBUILD.txt.gz
<pitti> yeah, failed again
<pitti> sladen: oh, you mean that error message? that's fine, buildd chroots have an "all-no" policy-rc.d
<sladen> pitti: the message about the denied execution appears about halfway down
<sladen> pitti: ah, groovy
<dupondje> its really weird
<dupondje> can't try with sbuild tho locally
<maxb> Hello. Yesterday the UDD package-to-branch importer was changed to use its own launchpad account rather than freeloading on james_w's credentials. Unfortunately no-one thought to make the robot account, ~package-import, a member of ~ubuntu-branches.
<james_w> oops
<maxb> Please could a member of the Ubuntu Technical Board remedy that omission?
<maxb> (pitti?)
<pitti> maxb: should I remove james_w, or keep him?
<pitti> well, james should already have the rights now by way of u-core-dev membership of ~package-import
<maxb> I think a rollback of the importer configuration is unlikely, but I'll let james_w clarify whether he should be in there for other reasons
<pitti> same as cjwatson
<pitti> but I leave it at this for now
<anthony_dev> I'm sorry for asking this question here, but #ubuntu-app-devel is not answering... guys, if in windows we had resource files, what we have in linux? how images, icons and all data stored in linux apps?
<james_w> it's useful for the occasional fixup, but not crucial
<pitti> james_w: oh, nevermind, I read it wrongly; ~package-import is a core-dev
<pitti> it's not a team which includes core-dev
<maxb> Thanks, the importer is back in business and processing the backlog successfully
<james_w> thanks pitti, maxb
<dupondje> mmm sbuild seems also broken on natty
<pitti> cjwatson: sorry to bother you, but I don't know where else to look: why is ibus-pinyin still on the CD, and for that matter, in main?
<smoser> i'm looking at a watch file for python-boto
<smoser> using google code redirector
<smoser> http://googlecode.debian.net/p/boto
<pitti> cjwatson: checkrdepends has zero rdepends in main, grepping http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.oneiric/ has no hits at all
<smoser> uscan thinks that boto-2.0rc1.tar.gz > boto-2.0.tar.gz
<smoser> how can i mangle that so that its right
<pitti> cjwatson: and yet it lands in the current desktop squashfs
<dupondje> damn :)
<pitti> smoser: it is -- it should have been named 2.0~rc1.tar.gz :(
<smoser> uscan has some way to mangle things .. but it wasn't obvious if this case would be covered.
<smoser> the ~ is a hint though
<pitti> jdstrand: meh, mysql failed to build as it fails some tests :/
<pitti> SpamapS, zul: ^ halp, please?
<skaet> jdstrand,  I'll switch the Tech Overview to the A3 context in the next couple of days,  then putting a note in there is probably a reasonable way to make sure its communicated.
<pitti> I was doing an upload to quick-fix the armada of broken apparmor profiles for the /run transition, but apparently mysql doesn't like me :(
<jdstrand> pitti: wild guess-- something related to 0.9.x to 1.0.0 openssl. probably need the server team involved
<jdstrand> Daviey: ^ would you mind looking at (or having someone) look at the mysql-5.1 ftbfs ^
<pitti> jdstrand: given the plethora of "SSL Connection error", that seems likely
<jdstrand> skaet: ack
<pitti> it's the first oneiric upload
<pitti> presumably mysql-5.1 needs some merging with Debian
<jdstrand> cool
<jdstrand> well, not cool, but 'ok'
<jdstrand> :)
<pitti> as Debian's demonstrably builds against openssl 1.0.0
<jdstrand> zul: do you typically do mysql merges? ^
<zul> yep
<jdstrand> zul: when you have time, could you do/coordinate a mysql merge (be sure to snag ubuntu5 from oneiric)
<jdstrand> ?
<zul> jdstrand: yeah sorry just got off the phone
<jdstrand> zul: thanks! :)
<zul> jdstrand: we were going to merge mysql 5.5 but i think it might be too late and it seems to be stuck
<Daviey> jdstrand / zul: So SpamapS was looking at the merge intially... but we were looking to get 5.5 into Debian (from our work), as the DM is overwelmed aiui.
<micahg> dupondje: gnome-shell fixed, BTW
<Daviey> jdstrand: so we hadn't sync'd before that, as we were expecting 5.5 to be in already.
 * jdstrand has no opinion other than that we need a buildable mysql :)
<Daviey> SpamapS: What is the current progress with 5.5?
<zul> Daviey: i think we should merge the mysql 5.1 now because its getting kind of stale and then wait again for 5.5
<zul> Daviey: it was having some debian/copyright issues last time i saw
<Daviey> zul: How long did the last merge that you did take?
<zul> Daviey: the actual merge doesnt take too long its just running the testsuite
<Daviey> zul: Okay.. shoot for it then! :)
<bdmurray> pitti: I'm working on tagging apport-kerneloops reports with information regarding the driver where the Oops occurred.  In apport it looks like data/kernel_oops is the right place to do this.  Is that correct?
<dupondje> micahg++
<dupondje> :)
<dupondje> didn't notice that build-dep :)
<pitti> bdmurray: I think so, but please check with the kernel team; as we now also have kerneloops, oopses might actually be caught by that one now
<bdmurray> pitti: if you mean the kerneloops package they are piped from it to apport
<pitti> ah, bood
<pitti> "goodÃ
<pitti> bah, keyboard fail
<pitti> "good"
<cjwatson> pitti: http://people.canonical.com/~ubuntu-archive/livefs-build-logs/oneiric/ubuntu/latest/livecd-20110714.2-i386.out doesn't mention ibus-pinyin - are you sure it's still on the CD?
<cjwatson> pitti: cdimage@antimony:~/cdimage/www/full/daily-live/current$ grep ibus-pinyin *.manifest
<cjwatson> cdimage@antimony:~/cdimage/www/full/daily-live/current$ grep ibus-pinyin *.list
<cjwatson> cdimage@antimony:~/cdimage/www/full/daily-live/current$
<SpamapS> Daviey: 5.5 needs an updated copyright file and then should be accepted into Debian
<SpamapS> ah, as zul explained.. ;)
<SpamapS> agreed that we should at this point merge 5.1, as 5.5 is lagging and the transition will take quite a while.
<brendand> seems like ecryptfs-mount-private no longer wants to work for me
<brendand> i get permission denied when running it
<brendand> open: Permission denied
<brendand> just like that
<brendand> this is after upgrading oneiric today
<brendand> pitti - is that what you were talking about earlier?
<cjwatson> that'll be the apparmor problems I expect
<brendand> aha - any workaround?
<brendand> or bug number?
<cjwatson> bug 810270
<ubottu> Launchpad bug 810270 in apparmor (Ubuntu Oneiric) "AppArmor profiles need updates for /var/run â /run and /var/lock â /run/lock and /dev/shm â /run/shm" [High,In progress] https://launchpad.net/bugs/810270
<jdstrand> actually, aiui, that is a result of the /dev/shm -> /run/shm change
<brendand> so i have to update something in apparmor.d?
<jdstrand> brendand: you should just be able to dist-upgrade and get the new mountall, etc
<brendand> jdstrand - i'm all upgraded out
<jdstrand> I am fixing the apparmor stuff, but ecryptfs isn't confined by apparmor, so that shouldn't be it
<jdstrand> brendand: ecryptfs may need code changes for /dev/shm -> /run/shm
<jdstrand> brendand: I'd file a new bug on that
<jdstrand> well, actually
<jdstrand> brendand: yes, a new bug
<pitti> brendand: correct, that's the bug fixed by latest udev and mountall
<pitti> related to /dev/shm/ permissions (or, being the wrong one)
<pitti> brendand, jdstrand: the ecryptfs prob has nothing to do with apparmor
 * jdstrand nods
<brendand> pitti - my udev is at 172?
<pitti> brendand: you need udev 172-0ubuntu3 and mountall 2.30
<brendand> i don't
<brendand> been dist-upgrade'ing
<pitti> brendand: workaround:
<pitti> sudo rm -r /dev/shm
<pitti> sudo ln -s /run/shm /dev/shm
<pitti> (works until reboot)
<brendand> pitti - ok , thanks
 * brendand is wondering why he's not getting the new udev and mountall yet
<brendand> are the deb packages somewhere?
<pitti> outdated mirror?
<pitti> brendand: they are on archive.u.c.
<brendand> i'll check sourcs.list
<brendand> s/sourcs/sources/
<brendand> thank you pitti :)
<pitti> you're welcome; sorry for the breakage
<pitti> came a bit unexpected
<brendand> i'm quite happy i don't need to re-install
<pitti> nah, it's not that broken, and it wouldn't even have helped
<bdmurray> pitti: https://code.launchpad.net/~brian-murray/ubuntu/oneiric/apport/tag-oopses-with-driver/+merge/67979
<dholbach> Ubuntu Developer Week Day 4 starting in 25 minutes in #ubuntu-classroom (https://wiki.ubuntu.com/UbuntuDeveloperWeek)
<SpamapS> pitti: I'd love to get your guidance on the libreoffice upload to natty-proposed. It seems rather large for an SRU ...
<SpamapS> mvo: on the recent upload tof software-center to natty-proposed, the RELEASE was changed from 11.04 to 11.10, I don't think that was intentional...
<mvo> SpamapS: indeed, sorry for that. could you please reject?
<SpamapS> mvo: no problem. Done.
<pitti> SpamapS: right; I discussed that with Sweetshark before; it's essentially a new upstream microrelease
<pitti> SpamapS: it fixes three handful of rather important bugs, like a broken -base, crashes, etc.
<SpamapS> pitti: I didn't see anything "scary" .. its just a ton of tiny tweaks..
<pitti> yeah
<SpamapS> pitti: but I wanted to confer w/ you... as its not a "slam dunk" :)
<pitti> I don't expect this to go into -updates after just 7 days, it'll need some thorough testing
<pitti> SpamapS: the libreoffice-build/NEWS diff is probably the best summary
<pitti> I sponsored it, but didn't want to accept it just by myself, as with being desktop team I might be a bit biased
<SpamapS> pitti: the only other concern I had was that it fixed a ton of bugs but there were only two launchpad bugs mentioned.
<pitti> SpamapS: but it looks bearable to me; I think we should have it in -proposed, and then gather some people for testing
<SpamapS> pitti: alright, given that context, I'll give it another look.
<pitti> ok, thanks
<pitti> bdmurray: nice one! doing the merge now
<bdmurray> pitti: great, thanks!
<didrocks> jdstrand: hey, it seems that you didn't push the unity upload to lp:~ubuntu-desktop/unity/ubuntu (see the Vcs-Bzr tag), can you please fix this and ensure it's upstreamed as well?
<jdstrand> didrocks: I didn't, I also mentioned this in irc to you yesterday:
<jdstrand> 09:03 < jdstrand> didrocks: hey. I uploaded the fix for unity for bug #805938. I could not apply to the Vcs branch because bzr kept crashing on me. I put my debdiff in the bug if you want to apply it to your tree
<ubottu> Launchpad bug 805938 in unity "Totem set as default music player after install instead of Banshee" [Undecided,Confirmed] https://launchpad.net/bugs/805938
<mvo> SpamapS: fixed and re-uploaded
<didrocks> jdstrand: I was at some conferences, hence the fact I wasn't connected on IRC. Can you ensure there is a branch proposed for njpatel?
<jdstrand> didrocks: well, that gets back to bzr crashing
<didrocks> jdstrand: I try to avoid messing up the branch (as we use merge-upstream with upstream vcs) and push fixes upstream first, the bzr merge :)
<didrocks> jdstrand: right, just ensure that njpatel is aware of the bug to merge
<didrocks> (if it's not already the case)
<jdstrand> didrocks: I think between my bug comments and all his references here, njpatel is probably aware :)
<jdstrand> njpatel: please see https://bugs.launchpad.net/ubuntu/+source/banshee/+bug/805938/comments/14
<ubottu> Ubuntu bug 805938 in unity "Totem set as default music player after install instead of Banshee" [Undecided,Confirmed]
<didrocks> jdstrand: we never ping Neil enough :-) Thanks a bunch!
<jdstrand> sure!
<jdstrand> didrocks: sorry I couldn't do it myself
<didrocks> jdstrand: no worry ;-)
<SpamapS> mvo: ack, will re-check shortly
<mvo> thanks
<chrisccoulson> jdstrand, i guess your bzr crash is the same as the one i see (which is bug 807076)
<ubottu> Launchpad bug 807076 in Zeitgeist Framework "raptor2 not supported" [Low,In progress] https://launchpad.net/bugs/807076
<lamont> ok.  wtf does natty hate my daughter's wireless?
<infinity> ath9k?
<lamont> 03:00.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02)
<infinity> Oh, then no idea.  Maybe natty's just sexist.
<lamont> went the system -> admin -> additional drivers route, it claims "no proprietary drivers"
<directhex> isn't that wired, not wireless?
<lamont> bah
<infinity> directhex: Sure looks like it, yeah.  :P
<lamont> 0c:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN [Kedron] Network Connection (rev 61)
<lamont> let's go with that one
<infinity> lamont: Well, now I'm even more confused then, because IPW is usually insanely well-supported (and, in fact, I have that very same wireless in this laptop)
<lamont> iwlist scan sees aps, but network mangler declines to believe in wireless, now that I dig deeper
<infinity> lamont: Define "hate"... Oops, panic, randomly just stops being useful?
<lamont> declines to configure
<jpds> lamont: You could check the NM bits with cyphermox.
<infinity> lamont: No manual configs in /etc/network/interfaces that are making NM ignore/skip the interface, I assume?
<cyphermox> lamont: /var/log/syslog will tell everything we need
<lamont> wtf.  thanks infinity
<lamont> (static config in interfaces, for reasons unknown)
<lamont> oh haha.  reasons suspected
<cyphermox> oh
<cyphermox> lamont: glad to know it's under control then :)
<infinity> lamont: "because it's been near lamont" or "because lamont's daughters are even more hackish than he is?"
<lamont> infinity: because at one specific magic point in the past, wlan0 was the default-route possessing interface, and some automagic happened
<slangasek> sladen: the new invoke-rc.d message is a change merged from upstream (Debian); the only delta was a more verbose error message, it shouldn't cause any failures.  If it does, yell. :-)
<lamont> infinity: IOW, I know what the root cause is now, and it's (unfortunately) me.
<cjwatson> pitti: general thoughts on lp:~cjwatson/ubuntu/oneiric/ubuntu-defaults-builder/image ?  it's really mostly a sketch right now - it does successfully build a squashfs, but the ISO image build step will fail until we have syslinux-themes-ubuntu-* packages, and keyring handling is pretty bustsed
<cjwatson> *busted
<mdz> pitti, hi! do we have a TB meeting in 15m as my calendar says, and are you chairing?
<cjwatson> mdz: that's my belief, at least for the former
<mdz> cjwatson, I see apologies from pitti, sabdfl and Keybuk in https://lists.ubuntu.com/archives/technical-board/2011-July/000973.html
<mdz> kees, around?
<mdz> cjwatson, unless kees is attending, we won't have quorum
<cjwatson> mdz: I shan't complain, I have an appointment with the pub
<cjwatson> but much though I love beer I suppose the TB needs to take precedence :-)
<cjwatson> $ sudo strace -etrace=umount,oldumount umount `pwd`/proc
<cjwatson> oldumount("/proc")                      = -1 EBUSY (Device or resource busy)
<cjwatson> dear util-linux, what exactly do you think you're doing?
<cjwatson> (no, `pwd` is not /)
<geser> mdz: "kees | heya, i'll be a few minutes late..." (from #ubuntu-meeting)
<mdz> geser, oh thanks, hadn't seen that
 * SpamapS bites the bullet and upgrades main laptop to oneiric..
<Daviey> cjwatson: Did you see bug #806231?  Is this a bug that can be fixed, considering it's valid to configure to run these daemons on different ports?
<ubottu> Launchpad bug 806231 in openssh (Ubuntu) "Conflicts with lsh-server" [Undecided,New] https://launchpad.net/bugs/806231
<dupondje> weird
<dupondje> I just installed oneiric, but gnome3 doesn't start
<dupondje> can't find applications.menu, but gnome-menus is installed
<dupondje> but the file doesn't exist
<dupondje> aha
<dupondje> that looks like a bug :)
<micahg> how did the SRU for libreoffice for natty get in w/out the dev release getting updated?
<micahg> SpamapS: ^^
<infinity> micahg: Because it's only in -proposed right now?
<infinity> micahg: When it makes it to -updates, it'll be copied to oneiric if it's still newer.
<micahg> infinity: yes, but that's generally only done at the beginning of the cycle, also, it doesn't build it with the newer toolchain
<infinity> micahg: Well, if you're asking for a different source version, that's a different request.
<infinity> micahg: But to the other concern, no, we can (and do) copy from natty-updates to oneiric any time.
<micahg> infinity: I know it can be made right :), was just wondering why it wasn't built with the oneiric toolchain in the first place (hasn't been yet), it also impacts transitions in oneiric
<infinity> micahg: (Which is exactly what happened for the last libreoffice upload)
<infinity> 1:3.3.2-1ubuntu5 went to natty-proposed, then to natty-updates and oneiric in May.
<dupondje> lool: Does Xterm icon gets updated? It really looks .. well UGLY :)
 * micahg retracts the part about transitions, but it's still weird WRT not using the new toolchain
 * micahg retracts his retraction :)
<bdmurray> cjwatson: did you write a wiki page regarding bug 442941?
<ubottu> Launchpad bug 442941 in ubiquity (Ubuntu Lucid) "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,Fix committed] https://launchpad.net/bugs/442941
<bdmurray> cjwatson: and actually isn't bug 349469 related to 442941?
<ubottu> Launchpad bug 349469 in debconf (Ubuntu) "debconf: DbDriver "config": /var/cache/debconf/config.dat is locked by another process: Resource temporarily unavailable" [Medium,Triaged] https://launchpad.net/bugs/349469
<SpamapS> micahg: we're allowed to accept into -proposed before the dev release is updated. Its just not going to go into -updates
<micahg> SpamapS: then it's not versioned correctly
<SpamapS> micahg: right, I understand what you mean, it should be 5.1 instead of 6 ... this can be handled by making sure the oneiric upload (if there is one) is 7.
<dupondje> Are we going to have something like Bumblebee in 11.10 ?
<micahg> SpamapS: the upload is for a new upstream version, ubuntu1 was used instead of either ubuntu1~natty1 or ubuntu0.11.04.1
<SpamapS> micahg: yes, I understand. The oneiric upload can still supersede it, even if dch -i won't do it automatically.
<micahg> SpamapS: yes, I know it's possible, just wondering why it happened to begin with...
<SpamapS> micahg: its a *slight* issue in a very complicated and important bugfix release that needs testing ASAP.
<infinity> SpamapS: Yeah, I'm inclined to agree with micahg that if you intended to do two source uploads, the versioning is "wrong".  I assumed you just intended to copy from -updates to oneiric (which would be fine).
<infinity> Though the argument for building with the current toolchain supports two uploads.
<micahg> SpamapS: I'm just wondering if it was an active decision at acceptance time or it wasn't flagged as problematic
 * infinity shrugs.
<SpamapS> micahg: I flagged it but not as an egregious error since there had been no actual upload to oneiric yet.
<infinity> Yeah, if the oneiric upload is -1ubuntu2, we can just pretend -1ubuntu1 was done long ago. :P
<ohsix> nm
<ohsix> oops
<micahg> SpamapS: ok, just wanted to make sure it wasn't slipping through the cracks :)
<v1z_> hi there
<v1z_> I would like to develop focus follows mouse in unity
<v1z_> do you know if this has already been done *fully*?
<v1z_> b/c it becomes impossible to access the menu for an application if the mouse hits a window behind it
<v1z_> ?
<v1z_> a more direct queston: what would you read to do this? gnome devel docs and gtk tutorials? any good refs?
<v1z_> assuming I already know c very well, autotools, git
<v1z_> thanx anyways
<persia> v1z_, It's a more systemic issue: what *should* happen for FFM with indicator-appmenu installed?  It needs design work before coding.
<persia> Most of the FFM users I know have removed that package, and use menus embedded in the applications.  This is less ideal if there are few pixels on the screen.  Finding the right answer for everyone is hard.
<v1z_> persia: ok cool.. removing ffm gives menus embedded in the apps
<v1z_> yes, i imagine it to be hard to find the right answer for everyone, that is why configuration exists
<v1z_> btw I really believe the default in ubuntu 11.04 is very good for most ppl
<v1z_> and the space saving is great
<v1z_> perhaps there is a design idea for ffm plus unity
<v1z_> (sorry I meant removing unity not ffm above)
<v1z_> persia: "removing the above package" refers to unity?
<v1z_> so you mean like logging to ubuntu classic?
<v1z_> so I am willing to put some real dev and design effort into this if needed
<v1z_> unless its already being taken care of etc
<v1z_> okay so I might be thinking out loud, I apologize,
<v1z_> but rereading what persia said, uninstalling indicator-appmenu should do it for FFM users
<v1z_> right? I will give it a try tomorrow
<v1z_> thanks!
<persia> v1z_, Removing indicator-appmenu
<persia> I don't know of anyone engaged in the design work.  The only idea I heard on the subject was to have another package that would only give the  indicator-appmenu behaviour if a window was maximised.
<persia> But that was from someone who didn't code much.
<persia> Anyway, once you've done the design work, you probably want to look at indicator-appmenu as a basis for how such a thing could be implemented.
<persia> Then you probably want to discuss your ideas with the folk in #ubuntu-desktop for help on how to allow your new package to be an alternate way to handle menus in the indicator, and how to integrate most smoothly with the rest of the unity experience.
<v1z_> persia: thanks a lot.. i will keep this possible contrib in mind
<v1z_> seems like indicator-appmenu is simple enough; small code and just make install it
<v1z_> (I keep talking cuz the channel is quiet anyways)
<lool> dupondje: Eh at least I can distinguish it easily  ;-)
#ubuntu-devel 2011-07-15
<kees> archive admins around?
<kees> FAIL: ABI mismatch in lucid Updates: 33 != 32 (linux-meta 2.6.32.33.39 vs linux-backports-modules-2.6.32 2.6.32-32.32)
<kees> FAIL: ABI mismatch in lucid Updates: 33 != 32 (linux-ports-meta 2.6.32.33.25 vs linux-backports-modules-2.6.32 2.6.32-32.32)
<kees> slangasek: around to fix this? ^^
<slangasek> kees: hrm
<slangasek> kees: I copied all those packages over together; did I hit the publisher at the wrong time?
<slangasek> kees: linux-backports-modules-2.6.32 | 2.6.32-33.33 | lucid-proposed | source
<kees> slangasek: perhaps... this is why I've recommended doing everything except meta for 1 publisher cycle, then meta on the next cycle. I will re-run the check (this one was from cron)
<kees> is there are archive-admin alias I can send email to? right now I just CC pitti on these warnings
<slangasek> ah, I guess I may not have gotten that memo :)
<slangasek> there's an ubuntu-archive mailing list
<kees> okay, cool, looks like it was a publisher cycle split or something. the re-run check sees no problems.
<slangasek> ok, good
<kees> *whew*
<kees> okay. thanks!
<kees> slangasek: actually, wait... it's not in -security...
<slangasek> is it supposed to be?
<kees> slangasek: it should have gone to security (along with all ABI packages)
<slangasek> ok; skaet asked me to copy it to -updates, wasn't sure what was meant to happen wrt -security
<kees> slangasek: yes, the tracking bug (807175) shows "Security-signoff" as "Fix Released" which means "Promote-to-security" is Confirmed.
<kees> both need to be done
<slangasek> ok, copying
<kees> see https://wiki.ubuntu.com/Kernel/kernel-sru-workflow
<kees> thanks!
<kees> slangasek: you have now had a crash-course in kernel workflow publication. ;)
<slangasek> so I see :)
 * slangasek notes that the interface between this workflow and the pending-sru page leaves something to be desired
<slangasek> copying done
 * slangasek makes a face at d-shlibs
<infinity> kees: There's the mailing list, there's also abusing members of ~ubuntu-archive in turn? :)
 * persia has always been a fan of the archive-admin-of-the-day model
<infinity> persia: That only works during work hours for said admin.
<StevenK> Timezones tend to defeat that a bit.
<infinity> persia: I doubt any of us want to sign up for 24h on-call.
<infinity> Well, for 24h in a row, that is. :P
<infinity> But we get good coverage between many of us.
<persia> I suppose.  Most of the AAotD are generall cooperative as long as it's their day *somewhere*.
<persia> y
<micahg> infinity: I've never worried too much about hours when pinging the AA of the day :)
<infinity> Often, but I wouldn't bank on it. ;)
<persia> But asking the AAotD is better than randomly selecting someone from ~ubuntu-archive and abusing them
<micahg> worse case, they say no, and you go find someone else
<StevenK> I'd suggest not abusing them if you want to actually *do* something. :-)
<lifeless> depends on the aaotd :P
<infinity> persia: Sure, it was more of an "if the AAotD happens to be eating/sleeping/urinating" thing.
<persia> infinity, And after checking the list, there's a significant number of listed AAotDs who don't generally do archive work during their working hours.  Not quite the majority, but getting close.
<infinity> persia: Which some of us do. ;)
<persia> If you want to use "us" in that context, go sign up as an AAotD :p
<infinity> I was using "us" to refer to archive admins. :P
<TheMuso> Can anybody clone a repo from gitorious? I am getting connection reset. Seems the website is ok though.
<broder> TheMuso: same for me, though the http transport seems to be working
<TheMuso> broder: Hrm right, thats certainly an option.
<TheMuso> although that doesn't want to work with the repo I am trying to pull.
<TheMuso> git://gitorious.org/qt-at-spi/qt-at-spi.git via http gives a fatal error.
<TheMuso> Ah the http transport URLs are slightly different.
<pitti> Good morning
<ion> that.
<pitti> cjwatson: nice! so that assumes that $PACKAGE is already apt-gettable, right? that's fair enough, I just wondered if it would be possible for testing to build it with a local deb
<pitti> cjwatson: but I guess for that it could create a temporary file:// apt repo
<pitti> cjwatson: but anyway, these are refinements I'm able to do :)
<pitti> cjwatson: thanks!
<dholbach> good morning
<cjwatson> Daviey: mm, I don't know, commented on the bug to the effect that maybe Conflicts is too heavyweight - I'm not sure really
<cjwatson> bdmurray: 442941 wiki> sorry, not yet, still on my to-do; I'm not sure I see how 349469 could be related to that
<Daviey> cjwatson: thanks.
<dholbach> @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: dholbach
<cjwatson> pitti: heh, I abused --ppa a bit in my initial version for that, and created a temporary repository
<cjwatson> pitti: it should be perfectly possible to support a local .deb; live-build supports that
<cjwatson> pitti: I believe it works by dropping .debs into config/chroot_packages/
<pitti> cjwatson: ah, so an extra --deb option would probably be handy
<pitti> cjwatson: do you want to work on the script further, or do I take it from here?
<cjwatson> boggle, that actually creates *and signs* a temporary repository with a temporary key
<pitti> thorough :)
<cjwatson> pitti: depends how fast you want it to happen :-)  I think I need to deal with the syslinux-themes-ubuntu packages
<cjwatson> which is unfortunately not a five-minute job
<pitti> cjwatson: OOI, why does that block local CD builds, but works with the official daily ones? isn't that also using live-build?
<cjwatson> no, the official ones only use live-build for the squashfs, not for the entire iso
<pitti> cjwatson: I think I'll need today for the remaining /run stuff, and release meeting etc., but I should have time to continue working on this stuff on monday
<pitti> ah
<cjwatson> how about I get this to the point where it can actually build workable images (possibly not today, I need to work on 10.04.3) and then hand it over to you?
<pitti> so for testing it's sufficient, as I can just inspect the squashfs
<cjwatson> right
<pitti> cjwatson: sounds great
<cjwatson> I did the bare minimum of making sure that it actually contained the defaults package and its dependencies
<cjwatson> mostly I just wanted to check on the interface with you, before it gets published and set in stone
<pitti> cjwatson: I need to implement some extra things into defaults-builder anyway for the one remaining thing in the qin spec which it doesn't support yet
<pitti> cjwatson: your --ppa is really like "--apt-source", right? i. e. I could use it to point to a file:// mirror on an alternate CD, to avoid downloading the entire thing for each test run
<cjwatson> well, live-build does its own caching
<cjwatson> but yeah
<pitti> ah, so much the better
<cjwatson> I don't actually like the --ppa interface right now; special-casing stuff starting with 'deb' is a massive hack :)
<cjwatson> but it was temporarily convenient
<pitti> oh, sure; but hacking that is easy
<cjwatson> I'd rather just support --ppa user/ppaname and have some other interface for extensions
<pitti> *nod*
<pitti> but it's great to have a script which does the live-build invocation right, it would have taken me quite a bit to figure that out
<pitti> but it actually seems to be delightfully easy
<pitti> seems all the hard work is already in livecd-rootfs
<pitti> jhunt: hey James, how are you?
<jhunt> pitti: hi! good thanks.
<pitti> jhunt: part of the /run transition is the move from /dev/.initramfs/ to /run/initramfs
<pitti> jhunt: we need a small change in upstart for this, in bug 810956
<ubottu> Launchpad bug 810956 in upstart (Ubuntu) "/dev/.initramfs/ â /run/initramfs transition" [Medium,Triaged] https://launchpad.net/bugs/810956
<pitti> jhunt: we have a compatibily symlink now, so it shouldn't be broken, but it would be good if we could do the transition before the next lts
<pitti> jhunt: it just affects one small part of the code, and is a simple string substitution
<pitti> however, it would break stuff if you tried to backport the package to natty
<pitti> so perhaps a more involved fix would be to check both directories and ignore /dev/.initramfs/ if it is a symlink?
 * Riddell nudges barry into looking at https://code.launchpad.net/~jr/ubuntu-packaging-guide/fixes/+merge/67951
<jhunt> pitti: sure, np. we could always get upstart to check for the existence of both directories and use the first it finds for safety.
<pitti> jhunt: ah, then it should prefer /run/initramfs/, and fall back to /dev/.initramfs
<pitti> that indeed seems to be safe
<jhunt> pitti: sure. this whole chunk of code can of course go away once upstart has full state passing :)
<pitti> jhunt: can you do this right in the upstream branch, or do you want me to go through the merge proposal/cherrypick steps?
<jhunt> pitti: the upstream doesn't have this initramfs+pid file feature - it's Ubuntu-specific.
<pitti> ah, handy
<jhunt> pitti: I've assigned the upstart part of that bug to me and will try to look at that today/monday.
<pitti> jhunt: thanks
<Amoz> hi all :)
 * Amoz hugs dholbach 
<apachelogger> cjwatson: is there going to be a germinate version that can handle kubuntu seeds branches being owned by kubuntu-dev soon?
<cjwatson> apachelogger: why dodes germinate need to change?  you tell it where seeds live
<cjwatson> *does
<apachelogger> cjwatson: -S also works for bzr?
<apachelogger> --seed-source= that is
<cjwatson> apachelogger: yes
<cjwatson> or you can just use the default non-bzr mirror which is the default
<cjwatson> er, tautology, but YKWIM
<cjwatson> the mirror at http://people.canonical.com/~ubuntu-archive/seeds/ points to kubuntu-dev for >= oneiric now
<cjwatson> and has done for a month or so
<apachelogger> ok, thanks :)
 * dholbach hugs Amoz back :)
<dholbach> Amoz, mvo uploaded your patch :)
<mvo> thanks Amoz creating the patch
<Amoz> dholbach, which one?
<dupondje> Who maintains http://qa.ubuntuwire.com/ftbfs/ ?
<dholbach> Amoz, sessioninstaller
<dholbach> dupondje, geser and gaspa judging by the source
<persia> dupondje, The ubuntuwire team.  I believe geser does most of the updates.
<Amoz> dholbach, ah. speaking of bugs, I wish to find a small project (preferably C) where I can dig a little deeper than just spelling mistakes
<Laibsch> anybody else having trouble with "sudo pbuilder-dist unstable create" on either lucid or natty?
<Amoz> could also be python and such, just as long as I learn something about the debian eco system
<dholbach> Amoz, you could try having a look at bugs tagged with "patch-needswork" - maybe there's a problem with an existing patch that just needs some fixing?
<persia> Amoz, Have you looked at crash bugs?  Those tend to be small fixes most of the time, but interesting to investigate.
<Laibsch> Amoz: are you more interested to package stuff or to code software?
 * Laibsch winks at persia, ä¹ãã¶ã
<Amoz> Laibsch, packaging is new to me, and I'd love to learn how to package stuff. Even though I read manuals/tutorials, they rarely prepare one for the real world packaging errors =) However, I guess I'll do more good in the coding field for now
<Amoz> persia, thanks, I will try to find some!
<dupondje> geser: Would it eventually possible to add the newest debian version in the ftbfs page ?
<dupondje> this way we can easly see if there is a new version in debian, which in alot of cases fixes the ftbfs
<Laibsch> Amoz: Great.  I maintain a couple of packages and I think I lack some of the skills you seem to have.  We could learn from and help each other if you are interested to co-maintain packages.  private chat?
<Amoz> dholbach, will investigate that too
<dholbach> geser, do you track bugs for the ftbfs page somewhere?
<Amoz> Laibsch, uuh, what skills do you refer to? I'm just a beginner ;)
<Satoris> I try to upgrade from natty to oneiric alpha. The update manager starts but then fails with an error stating some packages can't be downloaded due to "403 forbidden". Should it work?
<Laibsch> Satoris: try #ubuntu+1 channel
<Satoris> Will do, thanks.
<dupondje> I dunno if there is any chance of getting permissions to push a rebuild on launchpad ?
<cjwatson> dupondje: the permissions for that are identical to upload permissions
<dupondje> oh ok
<cjwatson> dupondje: what package/version?
<dupondje> https://launchpad.net/ubuntu/+source/4store/1.1.3-1ubuntu2
<cjwatson> dupondje: so you're saying that simply retrying those builds will work now?
<dupondje> yep
<dupondje> just tried locally :)
<cjwatson> dupondje: OK, retried
<dupondje> thx
<dupondje> going tru the ftbfs list now :)
<cjwatson> pitti: could you have a quick look at my debian-installer upload to lucid-proposed?  skaet says we want the 2.6.32-33 kernel for 10.04.3
<pitti> cjwatson: looks straightforward, accepted
<geser> dholbach: not yet, I plan to try to move the code to the ubuntuwire project (after that filing bugs should be possible)
<dholbach> geser, awesome
<geser> dupondje: you mean to show if Debian has a newer version? code-wise it should be possible. Do you have any suggestion where to display it?
<dupondje> geser: yea indeed, show if there is newer debian version. I would put it next to the ubuntu version?
<persia> Maybe just have a small display indicator, which presents a link to the PTS if there is a new version?
<persia> That page is already very information rich.
<dupondje> or a color ?
<dupondje> Think its just usefull to see quickly if there is newer version in debian
<cjwatson> pitti: ta
<persia> dupondje, Colour where: on the package name?
<dupondje> persia: or on the PTS field ?
<dholbach> jdstrand, were you happy with https://bugs.launchpad.net/ubuntu/+source/sox/+bug/809619?
<ubottu> Ubuntu bug 809619 in sox (Ubuntu) "Please merge sox 14.3.2-1 (universe) from debian unstable" [Undecided,New]
<persia> dupondje, Colour on the PTS field sounds reasonable.
<dupondje> http://pastebin.ubuntu.com/644718/ => anyone has an idea ?
<jhunt> pitti: I've got a fix for upstart+/run/initramfs in my stuff-and-nonsense ppa, but it might need a prod to get it built any time today :)
<pitti> jhunt: a "prod"?
<pitti> jhunt: ah, you mean PPA builders are congested?
<jhunt> pitti: yeah :)
<pitti> jhunt: there, that should be better
<jhunt> pitti: I'm having some pbuilder issues over here (including a bug I just found relating to /run :) so would like to build it in the ppa.
<jhunt> pitti: thanks
<pitti> patch looks fine to me, thanks!
<jdstrand> ls
<jdstrand> dholbach: I was yes. I thought I uploaded it. apparently I forgot. let me do that now
 * dholbach hugs jdstrand
<mdeslaur> ls: cannot access .: No such file or directory
<jdstrand> hehe
<jdstrand> mdeslaur: you caught that huh? :P
<mdeslaur> jdstrand: busted :)
<jdstrand> :)
<jdstrand> dholbach: while I have you. there is a work item for me: "coordinate with dholbach on developer initiatives and create a weekly or monthly list of packages 10-15"
<jdstrand> dholbach: I worked on my other work item for developing a process to identify these
<jdstrand> dholbach: and have decided to suggest 5 packages per week in our weekly meeting
<dholbach> jdstrand, that sounds great
<jdstrand> dholbach: I need to find another place besides the meeting minutes to have those
<jdstrand> dholbach: is there somewhere that you would suggest?
<dholbach> jdstrand, if you give me the link to them or mention them to me, I'm happy to put them into my weekly update about ubuntu development
<dholbach> (ubuntu news, omg!ubuntu! and other places)
<jdstrand> dholbach: cool. I think I can add them to our GettingInvolved page too
<jdstrand> dholbach: thanks! :)
<dholbach> sweet - just let me know and I'll include them
<jdstrand> dholbach: expect to here from me on monday (our next meeting)
<dholbach> excellent
<jdstrand> actually, we can have these be 9 days.... you might here from me today again :)
<jdstrand> s/here/hear/
<jdstrand> dholbach: oh, one other thing, I wrote https://wiki.ubuntu.com/PackagingGuide/Recipes/PackageSecurityUpdate and added it to https://wiki.ubuntu.com/PackagingGuide/Recipes. a) was that the type of thing you had in mind for packaging guide integration, and b) would you mind reviewing it for me?
<dholbach> jdstrand, I'm happy to have a look at it, sure - I'll add a TODO item
<dholbach> for the future it would be nice to get it into lp:ubuntu-packaging-guide
<jdstrand> dholbach: ah, I was unware of that
<jdstrand> dholbach: I might have missed it-- I looked at the Maintenance pages, but didn't see it
<dholbach> but getting the content right is the most important thing :)
<jdstrand> dholbach: shall I check it in now?
<dholbach> jdstrand, it'd require a bit of reformatting (moin vs. ReStructured text)
<jdstrand> dholbach: is moin autogenerated from the ReStructured text?
<dholbach> no, at some stage in the future we want to retire the Wiki pages
<jdstrand> I see
<dholbach> http://people.canonical.com/~dholbach/packaging-guide/html/ is the current guide
<jdstrand> well, I can check it in
<dholbach> I think I even filed a bug for it
<dholbach> if you don't mind doing it, I could review the MP
<jdstrand> let's do it that way
<dholbach> you are a hero
<jdstrand> dholbach: heh
<jdstrand> dholbach: so, this is what generates the pdf?
<dholbach> html, pdf, epub and a whole lot of other things
<jdstrand> dholbach: huh, the branch doesn't see to coincide with the pdf I downloaded yesterday
<dholbach> oh?
<dholbach> do you remember where you got the pdf from?
<jdstrand> dholbach: well, yes, for example, "Welcome to the Ubuntu Packaging Guide
<jdstrand> " is not in the introduction-to-ubuntu-development.rst
<jdstrand> ah, it is in index.rst
<jdstrand> ok, clearly this will take me a moment
<dholbach> take your time
<dholbach> thanks a lot already for getting the content together
<jdstrand> dholbach: ok. I grepped for 'Recipes' (as is in the table of contents) and GnuPrivacyGuardHowto (which is in the 'Updating an Ubuntu Package
<jdstrand> ' recipe), but couldn't find it
<jdstrand> dholbach: where are the recipes?
<dholbach> it's a different structure - let me for now just file a bug and review the wiki pages
<jdstrand> dholbach: (sorry if I am being dense)
<jdstrand> heh
<dholbach> you're not, don't worry
<jdstrand> dholbach: I'm happy to do the work :)
<dholbach> ok - for now you could just make it a separate article and we link to it from the knowledge base and from other articles
<jdstrand> ok, so something like 'update-package-security.rst' and then jam that into knowledge-base.rst
<Laibsch> anybody else having trouble with "sudo pbuilder-dist sid create" on either lucid or natty? I need a Debian unstable build environment.
<dholbach> exactly
<jdstrand> I can do that
 * dholbach hugs jdstrand
<dholbach> awesome! :)
 * jdstrand hugs dholbach 
<dholbach> alright, I'll take the dog for a walk now - let me know if there's anything else I can do
<cyphermox> cjwatson: using libpipeline, how would I go about getting both stdout and stderr from the output of commands?
<kenvandine> @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: dholbach, kenvandine
<cjwatson> cyphermox: I think you need an extension to libpipeline.  Could you file a bug report describing what you need, and I'll add support for it?
<cyphermox> cjwatson: sure, thanks
<jibel> pitti, buxy , about bug 541595, a way I've been able to reproduce during a dist-upgrade was to modify update-mime to always exit 1 and cause a failure during a release upgrade.
<ubottu> Launchpad bug 541595 in dpkg (Ubuntu) "[Master] package failed to install/upgrade: package is already installed and configured" [High,Incomplete] https://launchpad.net/bugs/541595
<jibel> pitti, buxy this made the trigger fail and cause the 'already installed' error
<pitti> jibel: oh, nice
<jibel> not a dist-upgrade, during a release upgrade
<jibel> but that may work with a dist-upgrade too
<pitti> shouldn't really matter; anything which triggers the dpkg error message should suffice to test the bug pattern
<buxy> jibel: but there are other cases that will trigger this error (other than just a failing trigger)
<buxy> Like this one recently: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/809223
<ubottu> Ubuntu bug 809223 in apt (Ubuntu) "package startupmanager 1.9.13-5 failed to install/upgrade: package startupmanager is already installed and configured" [Undecided,New]
<buxy> and where there's no obvious error at all
<pitti> buxy: hey
<pitti> buxy: the pattern is in place, just need to find/run a local test to verify that it's working
<buxy> pitti: I saw your mail, unfortunately I don't have one to provide you, I don't know if mvo got further since we discussed it but he had troubles reproducing it as well
<tkamppeter> mpt, hi
<mpt> hello tkamppeter
<tkamppeter> mpt, I did not see anything of g-c-c starting s-c-p or parts of it. I updated the system several times this week, and now I updated again and what I get is the new g-c-c printer setup tool and no button to add a printer.
<mpt> tkamppeter, ok, but at UDS you had a list of things that the g-c-c one didn't do.
<mpt> tkamppeter, I don't know enough about each of them to report meaningful bugs about them, but you do. :-)
<mvo> buxy: I have not looked into this paricular one, but apt never does dpkg -i directly, always unpack/configure. it might be that the ordering code is confused and its configuring it at the wrong spot (or too early)
<tkamppeter> mpt, so the step of getting access to s-c-p in Oneiric is not started yet?
<pitti> tkamppeter: still underway, yes
<mpt> tkamppeter, my message wasn't about Oneiric. It's about 12.04 and 12.10 and so on.
<mvo> buxy: actually this one looks like one of the apt recovery code kicked, I commented in the bug
<tkamppeter> mpt, what you need from me now is a list of bugs to work through to make g-c-c having all features of s-c-p, so that someone can so-to-say rewrite s-c-p in C, as far as it is needed?
<pitti> FWIW, that sounds like a step backwards to me
<barry> pitti: ping
<pitti> s-c-p is hardly performance critical, so the python overhead hardly matters
<pitti> an exception is the daemon which always runs in the user session
<pitti> hey barry; I'm talking, so I'm obviously here :)
<buxy> mvo: what represents the grouping between Log started/Log ended ? is this not equivalent to a call to dpkg ?
<mpt> pitti, I don't really care *how* the printer settings end up inside the System Settings window, whether that's by rewriting them or allowing Python panels or whatever else.
<pitti> mpt: so you prefer keeping the control panel, as opposed to a unity lens?
<barry> pitti: :)  hi!  do you have any good references for starting to learn about pygi and g object introspection?  i'm looking at bug 806574, which leads me there, and i need to learn more about it anyway.  well, *is* there any good references? ;)
<ubottu> Launchpad bug 806574 in computer-janitor (Ubuntu Oneiric) "computer-janitor-gtk crashed with AttributeError in reorder(): 'ListStore' object has no attribute 'reorder'" [Medium,Triaged] https://launchpad.net/bugs/806574
<mpt> pitti, I don't understand the question
<mpt> What does this have to do with Unity lenses?
<pitti> mpt: so right now we use the c-c shell, i. e. a window with all possible options
 * brendand has the same question as barry
<brendand> seems not well documented
<pitti> mpt: in earlier releases we had the "System -> Preferences" menu instead; personally I preferred that, but in natty this was impractical due to the new unity
<tkamppeter> mpt, I could report a bug for each feature, telling for what the feature is good for and how to visualize it/try it out?
<pitti> mpt: but similar to the old menus which went into unity, the settings bits could move there as well?
<mvo> buxy: a full operation of apt-get, this is why I'm puzzled, there is also no "commandline" information there, I wonder if its something like aptdaemon or packagekit that kicks in here actually violating some locking or something like this
<mpt> tkamppeter, I think the g-c-c developers would find that very helpful.
<pitti> tkamppeter: do you know what Tim thinks about this? it seems like an exceptional waste of developer time to port and bugfix s-c-p to a control center applet written in C..
<tkamppeter> mpt, should I do these bug reports upstream or on LP?
<mpt> tkamppeter, bugzilla.gnome.org
<barry> brendand: indeed
<pitti> barry: I recently wrote https://live.gnome.org/PyGObject/IntrospectionPorting which is a fairly detailled braindump
<mpt> pitti, <mclasen_> we're actually working with twaugh to reasonable features shared between s-c-printer and the printer panel
<barry> pitti: awesome, thanks.  i'll go digest that
<buxy> mvo: maybe it would be useful to add which libapt user is generating the log indeed
<tkamppeter> pitti, mpt, I am completely against rewriting the features of s-c-p in C. What I like to have is that the Python code of the s-c-p features gets something like a library or plug-in which various printer setup tools (also of KDE) can use.
 * pitti shakes head.. that's what FOSS needs, rewriting everything that's alrady written in sensible languages in C..
<pitti> barry: hmm, gtk_list_store_reorder() actually exists in C..
<barry> pitti: yep, this code worked fine before the switch to pygi
<mvo> buxy: yeah, we have a CommandLine tag for this in history.log now
<pitti> barry: ah, there we go
<mpt> tkamppeter, fair enough.
<pitti> barry:
<brendand> pitti - i've seen that, it seems the best resource available atm
<pitti>       <method name="reorder"
<pitti>               c:identifier="gtk_list_store_reorder"
<pitti>               introspectable="0">
<mpt>  So on the one hand we have language purity from developers of an OS that has ~0 users, and on the other hand practicality from an OS that does ~0 upstream development.
<pitti> barry: so this needs to be fixed in GTK
<barry> pitti: that was my suspicion based on something else i read.  where did you find that bit of xml?
<brendand> if someone was a beginner to gtk completely they'd sort of need to mix that with another tutorial
<pitti> barry: in the gir -- /usr/share/gir-1.0/Gtk-3.0.gir
<pitti> brendand: so the fact that this part doesn't work is a bug, not a documentation issue
<barry> pitti: thanks.  i'm sure there's a good reason why that's currently non-introspectable, but i don't know enough about this stuff yet.
<mpt> tkamppeter, but even if that library existed, each of its features would still need to be exposed in g-c-c *somehow*.
<brendand> pitti - sorry, i'm going off on a tangent here
<dholbach> @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: kenvandine
<barry> pitti: interesting, i don't have that file
<pitti> barry: libgtk-3-dev
<mpt> pitti, I'm surprised you liked the old Preferences menu. :-) I regard the System Settings window as not perfect, but a massive improvement, for several reasons, including less scrolling and less closing of windows.
<pitti> barry: my initial hunch is that it's because it passes an array of ints of unknown size
<barry> pitti: ack.  /me apt-gets
<pitti> mpt: I like being able to do windows + "mouse" to get to the settings I want
<pitti> now, that already works today
<pitti> but sometimes it's indeed useful to have a collection of all preferences
<pitti> it's just that upstream control-center now makes this exceptionally har
<mpt> pitti, there's no reason g-c-c can't be searchable, apart from a lack of planning
<pitti> d
<mpt> searchable from the Dash, I mean
<pitti> mpt: it is
<tkamppeter> mpt, so I will report all the features as separate upstream bugs and after that create a master bug which depends on all these bugs. In each bug I will also paste in a piece of text telling to not try to rewrite s-c-p in C or to freely invent this described functionality. I will also CC Tim Waugh and other people (tell me who) to all these bug reports to let them discuss and agree on a solution. WDYT?
<mpt> pitti, so what do you mean by "makes this exceptionally hard"? (I'm in 11.04 right now, installed Ocelot on another partition yesterday)
<pitti> mpt: my worries are that g-c-c has become pretty much a locked fortress now, and we aren't able to and don't want to rewrite all our configuration bits to be an upstream control center capplet in just a cycle or two
<pitti> aside from the fact that this would be completely impractical
<pitti> so it'll be a hack either way
<mpt> pitti, rewriting them all in Nux and C++ would be even *less* practical!
<pitti> mpt: c-c in 3.0/3.2 now forbids external/distro specific settings
<pitti> mpt: ?
<mpt> pitti, I know, I organized the UDS session about that.
<pitti> mpt: and embedded panels pretty much require in-process code and C
<pitti> mpt: who said we'd need to?
<mpt> pitti, and it was Ubuntu's patch to override that which sparked the discussion about printer settings in #gnome-os this morning.
<mpt> pitti, you did, by suggesting that they be a Unity lens.
<pitti> I'm in favor of (1) being able to write settings bits in Python or other languages, and keep our stuff, as it also provides KDE frontends
<mpt> yep
<pitti> and (2) still being able to get a consoliated view of all settings apps
<mpt> yep*2
<pitti> but if upstream g-c- doesn't want us to add our own stuff, and we have this wonderful unity thing anyway, why not make a lens which shows all available settings things
<pitti> pretty much like the old system -> prefs menu did
<pitti> and get rid of the c-c shell window
<pitti> which sticks out like a sore thumb from the session menu anyway
<pitti> that doesn't require any reimplementation -- it's just showing all desktop files with a "Settings" category
<mpt> pitti, because that would be punishing users (by making them open and close more windows) because of an implementation detail
<pitti> how so?
<tkamppeter> pitti, mpt, I also do not like to have "System Settings" in the "Off-Button" menu. As it moved to there I needed a certain time to find it and nearly reported a bug about disappeared System Settings, that about usability.
<pitti> whether you open it through a lens or the shell, it's the same number of clicks?
<pitti> my train station is coming up, back in ~ 30 mins
<tkamppeter> pitti, mpt, what is a unity lens>
<tkamppeter> ?
<mpt> tkamppeter, it's a black overlay that covers most of the screen and presents things to search or launch
<mpt> The things that appear if you click "Applications" or "Files & Folders" in the launcher are examples of lenses.
<mpt> pitti, simple example. Every time you disconnect from AC power, the screen dims. You want to turn that off. You open the lens and choose "Power", but it isn't there. Eventually you figure out that it's in "Screen" instead.
<mpt> pitti, with a lens, that would be : (1) open lens, (2) open Power, (3) close Power, (4) reopen lens, (5) open Screen, (6) close Screen.
<mpt> pitti, with g-c-c, it's: (1) open g-c-c, (2) open Power, (3) click "All Settings", (4) open Screen, (5) close g-c-c.
<tkamppeter> mpt, thanks. Such a thing, with a decent icon, not the standard magnifier, would make the system settings much easier to find.
<mpt> pitti, the more settings you want to change at once, the greater the savings.
<mpt> (It was even worse for the Preferences and Administration menus: partly because there were two of them, increasing the probability of errors, and partly because they were both submenus, increasing the cost of each error.)
<tkamppeter> mpt, are the bug reports still needed? Or will we go away from this over-rigid System Settings on the Off button to a lens which let us continue to use any application?
<mpt> tkamppeter, this has nothing to do with the Off button and nothing to do with lenses.
<mpt> tkamppeter, yes, please report the bugs.
<tkamppeter> mpt, if we switch to a lens, we should patch away the System Settings entry in the Off menu or let this entry also open the lens to avoid that users use inferior duplicates of the config tools.
<cr3> barry: out of curiosity, have you heard about any problems importing psycopg2 on oneiric? ImportError: can't import mx.DateTime module
<mpt> Somebody, please, give me something to bash my head against
<cr3> barry: I'm about to try to reproduce myself, just curious beforehand
<mpt> tkamppeter, this has nothing to do with the Off button and nothing to do with lenses.
<pitti> mpt: actually, it's not totally unrelated to lenses
<mpt> The g-c-c developers do not care about Unity at all, let alone lenses in particular.
<pitti> mpt: as with a lens, we can easily have s-c-p itself instead of waiting for it to be NIHed in c-c
<tkamppeter> mpt, I was only thinking about how in Ubuntu Linux system settings are presented the bnest way, easy to find and conserving the know-how which has made it into the tools in all the years ...
<tkamppeter> mpt, NIHed?
<mpt> tkamppeter, I am not involved in the design of Unity. I can explain (and just did explain) why settings shouldn't be in the Dash, but I can't guarantee they won't ever be there.
<cjwatson> mvo: have you noticed bug 807715?
<ubottu> Launchpad bug 807715 in update-manager (Ubuntu Oneiric) "Missing dependency on gir1.2-gconf-2.0" [High,Triaged] https://launchpad.net/bugs/807715
<mvo> cjwatson: I have a look
<tkamppeter> mpt, sorry, who is the right one to discuss with about the design decision of how System Settings tools are made available in Ubuntu?
<Laibsch> Are all packages that FTBFS due to missing packages listed in http://qa.ubuntuwire.org/ftbfs/? I just tried to build isdnutils and oneiric is missing tcl8.3-dev
<mpt> tkamppeter, JohnLea
<pitti> mvo: did you see the question to you in bug 806559?
<ubottu> Launchpad bug 806559 in lightdm (Ubuntu Oneiric) "debconf prompt about DM to use during natty->oneiric" [Medium,Triaged] https://launchpad.net/bugs/806559
<pitti> mvo: I started discussing this with Robert, but I'd appreciate your input which solution is better
<mvo> pitti: sure, I have a look
<Riddell> packaging guide reviewers:  https://code.launchpad.net/~jr/ubuntu-packaging-guide/fixes/+merge/67951 https://code.launchpad.net/~jr/ubuntu-packaging-guide/02-udd-introduction/+merge/68078 https://code.launchpad.net/~jr/ubuntu-packaging-guide/03-packaging-from-scratch/+merge/68099
<nemo> I do wish archive.canonical.com was accessible over https...
<nemo> Over here, I have 2 options for updating the ubuntu machines.  ftp protocol for mirrors that support, http for mirror.anl.gov that I fought to get websense whitelisted, or https.
<nemo> unfortunately, none of those work for sun java which is only available from archive.canonical.com
<nemo> hmmm. maybe archive.canonical.com supports ftp!
 * nemo tests
<nemo> nope :(
 * nemo sighs and copies the file over manually
<jdstrand> dholbach: ok, wrote fixing-a-bug-security.rst and proposed the merge just now
<nemo> s/2 options/3 options/
<dholbach> jdstrand, you rock - will have a look in a bit
<jdstrand> dholbach: thanks! :)
<cr3> barry: so, I can confirm there's a problem with python-psycopg2 on oneiric when importing mx.DateTime. I tried bzr branch lp:ubuntu/psycopg2; debuild; dpkg -i ../*.deb and that worked. trying pbuilder in case it builds the package differently
<barry> cr3: interesting.  have you filed a bug yet?
<cr3> barry: not yet, bugs.launchpad.net/ubuntu/+source/psycopg2 seemed sparse, so I'm waiting to gather more info to report
<cr3> cyphermox: is there still a problem with pbuilder create for generating an oneiric tarball on oneiric?
<highvoltage> 1/win 20
 * cr3 doesn't have the patience to setup an sbuild environment :(
<cyphermox> cr3: I haven't tried lately. like I said, I switched to using sbuild following mdeslaur's advice ;)
<cr3> cyphermox: security > usability, I guess :)
<cyphermox> no, it's not that. It's just as simple as pbuilder, really
<cr3> cyphermox: have you read that wiki page? I feel asleep part of the way through :(
<cyphermox> like I told you, don't bother with the umt script thing, just the first part of the wiki page; there's something like 2-3 files to modify/create and then you run the commands to build the chroots
<cr3> cyphermox: can you remind me of the wiki page url again? google is returning this but this but I vaguely recall the page being different: https://help.ubuntu.com/community/SbuildLVMHowto
<cyphermox> https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment
<brendand> where do i find extra gobject typelibs?
<brendand> looking for GUdev, it's not in /usr/lib/girepository-1.0
<brendand> not sure about the package name
<cyphermox> brendand: gir1.2-gudev-1.0 maybe
<barry> cyphermox, cr3 i use sbuild almost exclusively too, though occasionally pbuilder.  that security team page rocks
<dholbach> Last day of UDW (https://wiki.ubuntu.com/UbuntuDeveloperWeek) starting in 15 minutes in #ubuntu-classroom
<brendand> cyphermox - in general is it gir1.2-*?
<cyphermox> it is
<cr3> barry: I'll give sbuild a try once again and I reported bug #811115 for now
<ubottu> Launchpad bug 811115 in psycopg2 (Ubuntu) "[oneiric] ImportError: can't import mx.DateTime module" [Undecided,New] https://launchpad.net/bugs/811115
<pitti> cjwatson: ah, seems I misread the original numbers: the old ibus-pinyin didn't take 15 MB, but just 1.5; apt-get install ibus-pinyin additionally pulls in pinyin-database (14 MB), but that wasn't on the CDs
<pitti> so moving to sunpinyin actually caused a 17 MB increase, not 4
<barry> cr3: i'll take a look after lunch
<cjwatson> pit	ah, wow
<cjwatson> pitti: ^-
<pitti> cjwatson: so I guess we'll go back to pinyin for the standard CDs if we need to retain Chinese support there, and only use sunpinyin for the Chinese Edition/check-language-support
<cjwatson> that seems the only practical choice, from what you've said, yes
<cjwatson> (of course note that the installer uses check-language-support ...)
<pitti> cjwatson: it seems fine for downloading if you are online
<pitti> but ibus-pinyin with ibus-pinyin-db-open-phrase at least provides a reasonable offline fallback
<cr3> barry: I'm hoping to have more information or suggest a patch once I get my sbuild environment running
<pitti> good night everyone
<bdrung> jamespage: eclipse ping
<SpamapS> Copyright: 1979-2007, MySQL AB
<SpamapS> Whoa.. how long have they actually existed?! :-P
<slangasek> SpamapS: heh
<SpamapS> thats on a one line shell script.. :-P
<SpamapS> one line, 684 chars long :-P
<slangasek> clearly someone is confused about copyright :)
<SpamapS> heh, I think maybe by now they can drop it.. 'msql2mysql.sh'
<SpamapS> Heh.. I'm not so sure licensecheck2dep5 is helping here.. :-P
<SpamapS> I think its accurate.. but.. a 3000+ line copyright file is probably a bit too detailed.
<slangasek> licensecheck2dep5?
<slangasek> where's that from?
<SpamapS> slangasek: its in cdbs.. scheduled for appearance in devscripts at some point
<slangasek> in cdbs!
<broder> licensecheck2dep5> whoaaaaa
<broder> that's awesome
<hyperair> that thing should go into devscripts
<slangasek> no, it clearly isn't, it should do something more sensible than generating a 3000+ line copyright file :)
<SpamapS> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=472199
<ubottu> Debian bug 472199 in devscripts "[licensecheck] Generate machine readable copyright file" [Wishlist,Open]
<hyperair> slangasek: it does a great job at summarizing stuff.
<SpamapS> MySQL *is* extremely detailed in their files
<hyperair> i usually start from licensecheck2dep5, and then trim stuff down
<hyperair> manually
<SpamapS> 3781 ../copyright
<SpamapS> hyperair: I think it MIGHT be a little bit crackheaded in this case. ;)
<slangasek> is it 3000+ lines of copyright holder names, or is it 3000+ lines of silly per-file statements because it doesn't use sensible heuristics for aggregation?
<SpamapS> Per file
<SpamapS> There are only 2 or 3 copyright holders.. since MySQL has a CLA
<hyperair> SpamapS: i'd rather start from the licensecheck2dep5 output than from licensecheck's raw output
<SpamapS> Sun, FSF, MySQL AB, Oracle, and Innobase
<slangasek> SpamapS: right; so I consider that a significant bug in the tool
<hyperair> CLA?
<SpamapS> Oh and NetBSD since they embed libedit.. how lovely
<slangasek> because it does exactly what the dep5 critics say they don't want to have to deal with on their packages :)
<SpamapS> hyperair: Contributor Licensing Agreement.
<hyperair> ah i see
<SpamapS> Actually I think its simpler, they just require assignment.
<hyperair> that's just CA
<bdmurray> cjwatson: I'd rather not do this but I think memtest could use a source package hook refiling some bugs about grub
<hyperair> copyright assignment, is it not?
<hyperair> similar to canonical's
<SpamapS> slangasek: agreed, it should be able to look at the massive chunk of files and use globbing.. and year heuristics
<slangasek> yes
 * SpamapS hacks a bit on it
<slangasek> there's probably enough information there to pick a "default" copyright statement for the upstream source
<SpamapS> slangasek: the most common gets the * .. ;)
<slangasek> SpamapS: already?
<slangasek> yuck
<SpamapS> slangasek: no, I was thinking of doing that
<slangasek> ah, yes
<broder> how much of the variation is from differences in the exact copyright statement, as opposed to the license?
<broder> (i.e. differences in year or something)
<SpamapS> broder: a lot
<kenvandine> @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:
<barry> cr3: bug 811193
<ubottu> Launchpad bug 811193 in psycopg2 (Ubuntu) "Sync psycopg2 2.4.2-1 (main) from Debian unstable (main)" [Wishlist,Confirmed] https://launchpad.net/bugs/811193
<cr3> barry: noticed the email, I really like the dh_python2 for free part :)
<barry> cr3: indeed! :)
<vikapi> using kubuntu11.04..my rkonq is crashing quite frequently.
<micahg> vikapi: you probably want #kubuntu
<vikapi> micahg: thought wud report to developers.
<micahg> vikapi: then you probably want #kubuntu-devel
<SpamapS>   3781 ../copyright
<SpamapS>   2567 ../new.copyright
<SpamapS> Heh.. progress
 * SpamapS plods on
<bdmurray> Is there somebody who wouldn't mind sponsoring openssh for me?  I just made a change to the apport package hook.
<bdmurray> http://people.canonical.com/~brian/tmp/openssh_5.8p1-4ubuntu2.debdiff
<infinity> bdmurray: Sure.
<infinity> bdmurray: Sufficiently tested and such, I hope? :)
<sladen> bdmurray: simple un-intent?  What if statement was it originally under?
<infinity> sladen: un-indent plus a newline!
<infinity> (putting it outside the if)
<sladen> infinity: yeah, wondering what the if statement was/is
<bdmurray> there is a ui.yesno regarding sensitive info in /etc/ssh/ssh_config
<bdmurray> and asking whether or not you want to include it
<infinity> bdmurray: Have you tested this?
<infinity> bdmurray: It looks to me like these lines might just exit straight out:
<infinity>     if response == None: # user cancelled
<infinity>         raise StopIteration
<bdmurray> yes that's true
<infinity> bdmurray: Which means your code will never get run.
<bdmurray> no, if the dialog box is closed by clicking X and you don't choose yes or no that happens
<infinity> Ahh.  Fair enough.  I don't speak apport, so wasn't sure what the dialog responses would be.
<infinity> So, None = cancel and back out, True = include private stuff, False = include only non-private stuff?
<bdmurray> that's correct
<infinity> Mmkay.  Signing and uploading.
<bdmurray> thanks
<nigelb> tumbleweed: ping
<tumbleweed> nigelb: hi
<nigelb> tumbleweed: lightning talks start in 3 mins, can you join #ubuntu-classroom-backstage? :)
<SpamapS> slangasek: well I'm down from 3781 lines to 2305 ... :)
<slangasek> progress!
<SpamapS> I've managed to get each "owner" line down to one.
<SpamapS> and directories in which all files fall into the same owner are *'d ..
<SpamapS> There's a merge operation now that needs to happen..
<SpamapS> actually I'm not even convinced thats true..
<SpamapS> mysql files are all single copyright holder from what I can see.
<SpamapS> hrm.. licensecheck seems to be broken when a copyright spans multiple lines.
<SpamapS>    Copyright (C) 1984, 1989, 1990, 2000, 2001, 2002, 2003, 2004, 2005, 2006
<SpamapS>    Free Software Foundation, Inc.
<SpamapS> That produces an empty copyright holder
<cjwatson> infinity: openssh is maintained in lp:ubuntu/openssh, and the importer is having trouble with openssh at the moment.  Could you please commit the changes you sponsored there?
<infinity> cjwatson: Can do.
<infinity> cjwatson: Done.
<cjwatson> ta
<Daviey> SpamapS: Is this mysql 5.5 or the current package in Debian?
<mikewhatever> !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
<mikewhatever> The 2.6.32-33.70 kernel update introduced some Elantech touchpad related changes.
<mikewhatever> Relevant bug #780588.
<ubottu> Launchpad bug 780588 in linux (Ubuntu Lucid) "Lucid update to v2.6.32.40.17 stable release" [Undecided,Fix released] https://launchpad.net/bugs/780588
<mikewhatever> The touchpad on my Dell Mini 10 is now unusable - its dimentiones are wrong, right click is jumpy, etc.
<bryceh> mikewhatever, did you boot to the earlier kernel and verify it is the kernel update?
<mikewhatever> quit
<micahg> any AAs who know how to copy stuff still around?
<slangasek> micahg: there are only two of us in Pacific Time, you could poke us by name ;)
<micahg> slangasek: I could, but I didn't want to bother you if you we busy with something
<slangasek> micahg: what do you have?
<micahg> slangasek: could you please copy thunderbird from security to updates for maverick and natty only, *NO LUCID* :)
<slangasek> ack, looking
<slangasek> micahg: done
<micahg> slangasek: thanks!, have a great weekend
<slangasek> micahg: you too :)
<SpamapS> Daviey: 5.5
#ubuntu-devel 2011-07-16
 * Kreative` is away: Away
<broder> !away > Kreative`
<ubottu> Kreative`, please see my private message
<bluefoxicy> is start-stop-daemon broken?
<bluefoxicy> bluefox@icebox:~$ sudo /etc/init.d/privoxy restart
<bluefoxicy>  * Restarting filtering proxy server privoxy
<bluefoxicy> Warning: Fake start-stop-daemon called, doing nothing.
<cjwatson> no, but your installation is
<bluefoxicy> I just installed it.
<bluefoxicy> er, just installed privoxy
<cjwatson> one way in which that can happen is if debootstrap crashed midway through and didn't undo its temporary start-stop-daemon shsim
<cjwatson> *shim
<bluefoxicy> hmm....
<cjwatson> I expect you have /sbin/initctl.REAL and /sbin/start-stop-daemon.REAL ...
<bluefoxicy> yep.
<bluefoxicy> which package do I reinstall?
<cjwatson> you don't, move those files back over the non-.REAL variants
<cjwatson> I further expect that /debootstrap/debootstrap.log or /var/log/bootstrap.log will exist and have some complaints
<cjwatson> did you debootstrap by hand?
<cjwatson> I have no idea how broken that installation might be in other ways
<bluefoxicy> no
<bluefoxicy> what's debootstrap?  For building debian from scratch?
<cjwatson> man debootstrap
<cjwatson> sorry, I'm doing other things and won't have time to walk through things that are documented
<bluefoxicy> k
<bluefoxicy> this is a new install from a month or two ago so I dunno what happen.  Oh well.
<cousteau> it would be nice that apt-get had a "--queue" option to queue actions to the package manager while it's running
<pdtpatr1ck> Question -- why is it when u use cat the directories would put a space after each word? whereas if u use cd .. it would do a directory walk adding / at the end as it should?
<Ampelbein> pdtpatr1ck: what?
<pdtpatr1ck>  What i'm asking is .. if for instance i want to do cat /etc/network/interfaces .. if i type cat /et and tab complete - it would add a space instead of doing /etc/ to continue. Whereas cd does it automatically. Just wondering why it does that in ubuntu.
<cjwatson> sounds like a bug in bash-completion
<pdtpatr1ck> yeah thats what i thought
<Ampelbein> pdtpatr1ck: I can't reproduce in oneiric though
<cjwatson> it doesn't do that for me
<pdtpatr1ck> im on 11.04
<pdtpatr1ck> u guys on 11.10 ?
<abhinav-> I can't produce it on Natty
<pdtpatr1ck> type cat /etc
<pdtpatr1ck> and tab
<pdtpatr1ck> does it put a space?
<cjwatson> n
<cjwatson> no
<cjwatson> (11.10)
<abhinav-> No, it puts a slash on hitting tab after 'cat /etc'
<pdtpatr1ck> ur on 11.10 right?
<abhinav-> I am on 11.04
<pdtpatr1ck> i've tried it on many boxes with 11.04 and it does it each time.
<abhinav-> hm. well I have only one system running :)
<cjwatson> I can't reproduce it in my 11.04 chroot either.  But I've seen this kind of thing in the past, so I expect the required circumstances are just a bit more specific than what version of Ubuntu you're running.
<cjwatson> I don't know bash-completion well enough to be able to guess what those circumstances might be.
<Ampelbein> thinking about it, isn't filename completion a bash internal function and not at all related to the package bash-completion?
<pdtpatr1ck> im going to look at the bash_completion code and see what its doing maybe that might help me
<cjwatson> Ampelbein: yes, though bash-completion very often overrides it for individual commands
<cjwatson> if 'complete -r cat' makes the problem go away, then it's due to bash-completion
<pdtpatr1ck> from what im seeing . looks like the directory commands such as cd are will see the directories whereas commands like cat sees the files. Ehh not a big deal.. will look at it more and customize it my liking if i have to
<cjwatson> I do not think that explanation matches how it actually works, no
<cjwatson> or at least not how it's supposed to work
<cjwatson> cd is told to complete *only* over directories, it's true; but that shouldn't influence the suffix placed when some other command such as cat *does* complete a directory
<cjwatson> you might check whether you've turned the mark-directories readline option off in ~/.inputrc (if you've never heard of it, you haven't)
<cjwatson> although that wouldn't cause an extra space, it would just remove the slash ...
<pdtpatr1ck> is there a manual for complete? or is that some function in bash_complete? I don't see where it was created but i've seen it used many times with different options.
<cjwatson> it's a bash builtin
<cjwatson> it's documented in 'man bash'
<pdtpatr1ck> thanks cj
<puttaraju> hi,
<puttaraju> QUESTION: im following development setup given in link,  http://people.canonical.com/~dholbach/packaging-guide/html/getting-set-up.html#get-set-up-to-work-with-launchpad
<puttaraju> its taking  more than 2  hours  for  this  command :   pbuilder-dist <release> create
<puttaraju> can anyone tell me  what this might be doing ?
<cjwatson> it does have to download quite a lot (as that page says)
<puttaraju> anyidea how much?
<bryceh> varies on your internet connection / computer
<cjwatson> should be on the general order of 100MB (but I don't use pbuilder so I don't know exactly)
<puttaraju> cjwatson: thanks for the info
<puttaraju> will wait and see for 1 more hour then
<rww> Hello! (and apologies if this is the wrong place). What's the separation between "Ubuntu Server" and "Ubuntu Desktop" as far as EOL on LTS goes? Is there a list of packages that are supported for 5 years and the rest are supported for 3 or something?
<directhex> rww: yes
<rww> directhex: Thanks. Is there a copy of the list for hardy online somewhere?
<directhex> good question
<rww> http://people.canonical.com/~ubuntu-security/dapper/supported.txt seems to be the one for Dapper, but the obvious URL substitution doesn't yield one for Hardy, and the Desktop EOL announcement doesn't have one.
<directhex> it's somewhere in http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.hardy/ afaik
<directhex> there's also a script, ubuntu-maintenance-check or similar
<rww> okay, I'll look through that script and see what it's checking against, thanks :)
<rww> I assume that no universe and multiverse packages are 5-year packages anyway, just main and restricted?
<broder> rww: the 3-year/5-year thing doesn't apply to universe/multiverse in the first place
<broder> as i understand it, the extended support periods are a commitment from canonical
<cjwatson> on lucid, you can do 'apt-cache show' and get the support period from the Supported: field; I forget how you were supposed to do that on hardy
<qb89dragon> I'm making a deb package and need to force dependencies to install silently (without presenting the user with configuration choices), any idea how to modify my control file to do this?
<slangasek> qb89dragon: a) packages should in general install silently by default so if they don't, you should consider reporting this as a bug; b) if they prompt for configuration, there's no way to override this from a depending package.
<rww> broder: That's what I thought. Thanks :)
<pdtpatrick1> Is there some problem with bridge networking in ubuntu?
<pdtpatrick1> http://pastebin.com/Yz4bJF8e
<slangasek> pdtpatrick1: as the output says, the interface you're using is deprecated.  Is there a particular problem you were trying to fix by using /etc/init.d/networking restart?
<slangasek> (but I'm afraid I'm headed afk now, so can't help further with this - but I would expect 'ifup br0' to be what you want)
<pdtpatrick1> slangasek, it turns out it was supposed to be bridge_ports instead of bridge_port .. that was fix
#ubuntu-devel 2011-07-17
<pdtpatrick_> Question -- why is it when u use static IP. /etc/resolv.conf keeps going blank after reboot? Is network manager still controlling that file?
<broder> !support | pdtpatrick_
<ubottu> pdtpatrick_: The official ubuntu support channel is #ubuntu. Please be aware that this channel is for development only.
<pdtpatrick_> because i've asked that question many times in the other rooms and no one seems to know .. thought i'd ask the developers instead
<cjwatson> pdtpatrick_: you can try http://askubuntu.com/ if IRC support channels don't know the answer; we would still prefer that this channel not become overspill from #ubuntu, because it will get very hard for us to use it for development in that case
<cjwatson> (I know it's quiet over the weekend)
<melodie_> hi, I have met with an issue that is reported at launchpad, related to the gmixer program. As the program and package have been developed at Ubuntu, I thought I would ask about the development of this package. It has not been continued since 2009, and has a bug reported by many persons of different distros. What could be done about it ?
<melodie_> https://bugs.launchpad.net/gmixer/+bug/416292
<ubottu> Ubuntu bug 416292 in gmixer "gmixer fails to launch" [Undecided,New]
<melodie_> here is the link
<melodie_> if someone has answers to this... the dev seems not to answer, I had wrote to him a few weeks ago to offer to improve the translation to French : since then, no answer. :/
<melodie_> hi EagleScreen
<melodie_> I am looking for an information : is there a place where someone in charge of following the development of some given packages can be found ?
<EagleScreen> melodie_: I think there are several places
<melodie_> EagleScreen, if I repeat the full info about the issue I meet with will it help you to advise me better ?
<EagleScreen> melodie_: may be..
<melodie_>  I have met with an issue that is reported at launchpad, related to the gmixer program.
<melodie_> https://bugs.launchpad.net/gmixer/+bug/416292
<ubottu> Ubuntu bug 416292 in gmixer "gmixer fails to launch" [Undecided,New]
<melodie_> I didn't post there because I can't reproduce it since the beginning unless I install it to a new Linux install.
<melodie_> but I noticed some time ago that the program has not had updates since 2009
<melodie_> so I was wondering if there is a place where I could point to it. We don't have many valuable gtk2 mixers at linux distros actually. gnome-alsamixer is not updated anymore, and gmixer same does not seem active. other mixers are not so good looking, or may be heavy or attached to a desktop environment
<penguin42> melodie_: Well these days people are expected to do everything via pulse
<melodie_> hi penguin42 how is that ?
<melodie_> what if you want a leightweight system without pulse ?
<penguin42> melodie_: Yes I understand; Is that true of one of xubuntu or lubuntu?
<melodie_> I don't understand "is that true of one... " ?
<melodie_> lubuntu is light, crunchbang used to be build on ubuntu, with the Openbox wm as unique environment. I also use a distro with Openbox standalone... and a few tweaks in to make it easy to use daily.
<penguin42> I meant do any of lubuntu or xubuntu ship without pa ?
<melodie_> such as this one :p â http://mimasgpc.free.fr/openbox-menu_en.html
<melodie_> penguin42, I have no idea, haven't used them
<melodie_> pa : is pulse ?
<penguin42> yeh
<melodie_> pulse audio ?
<melodie_> ok
<melodie_> :)
<melodie_> penguin42, so what about gmixer ?
<penguin42> melodie_: I don't know; it doesn't look like it's ever been in an Ubuntu package
<melodie_> is it going to be abandonned as pulse audio is supposed to be used as a mixer ? (is that possible ?)
<melodie_> oh yes it is
<melodie_> wait a sec
<melodie_> https://launchpad.net/gmixer
<melodie_> isn't launchpad a Ubuntu place ? Or I understood nothing about it ?
<penguin42> melodie_: Not all the projects on launchpad are ubuntu packages
<melodie_> ok
<melodie_> therefore theses gtk2 mixers are poor orphans
<melodie_> thanks for the infos...
<penguin42> melodie_: To me it looks like a project someone created and then didn't do much with
<EagleScreen> melodie_: it is better to try to contact with upstream author if you are interested in gmixer
<melodie_> EagleScreen, sure... that's what I did first : I wrote to the author several weeks ago and I never got an answer
<melodie_> I think alsamixer-gnome and gmixer should find devs to adopt them. they are good programs
<melodie_> and none approaches them for the quality.
<EagleScreen> melodie_: the software applications born and die, like the humans, they are not alive forever...
<penguin42> melodie_: So what are you doing in your spare time?
<melodie_> in their range of action of course
<EagleScreen> if you were good in gtk programming, you could adopt them
<melodie_> I do this and this and this : http://melodie.tyruiop.eu/ http://citrotux.org/ and this : Bonsai : http://tyruiop.eu/~melodie/Downloads/ISOS/PCLinuxOS_cli_iso_and_children
<penguin42> melodie_: You might want to look at xfce4-mixer or gamix
<melodie_> I looked at gamix, was not convinced. xfce4-mixer brings in Xfce apps : I need agnostic apps
<melodie_> as much as possible
 * penguin42 segfaults gamix
<melodie_> http://meets.free.fr/images/pclinuxos-bonsai-2011.png
<melodie_> this is the last test version uploaded. I have redone it completely last night, and will now install it to a machine for more tests
<melodie_> the looks is that one.
<melodie_> I don't program : I take pieces and put them together in a way that other people have not thought about before.
<melodie_> with the help of a few persons
<EagleScreen> melodie_: you may take a look to veromix
<melodie_> EagleScreen, I look, thanks
<melodie_> it's a plasma widget ? :o
<EagleScreen> not sure
<melodie_> that's what I find while googling
<melodie_> it's a kde app
<melodie_> :|
<EagleScreen> a kde app would be bad, but it is a plasma-widget, so only runs in kde4
<melodie_> EagleScreen, ok. so it's not the subject
<EagleScreen> yes, i see
<melodie_> I'll try to find people looking for apps to continue
<melodie_> :)
<melodie_> and developing in python mostly
<EagleScreen> but dont forget you have alsamixer in console mode
<melodie_> what desktop do you use ? gnome ?
<melodie_> EagleScreen, I don't forget. that's what I configured for volumeicon on the "bonsai" version
<EagleScreen> I use mostly KDE, but also others
<melodie_> :)
<jykae> Dev week in Finland: http://jykae.blogspot.com/2011/07/ubuntu-developer-week.html
 * penguin42 guesses they'll got a lot of stuff finished off
<penguin42> jykae: It's hard organising things like that
<jykae> penguin42: yep, learned a lot for next time
<jykae> Those Qt meetings will be a good place to present news from Ubuntu for Qt developers
<jykae> quite many of those Qt devs didn't know that Natty is QML
<penguin42> QML?
<jykae> penguin42: start here http://doc.qt.nokia.com/4.7/qdeclarativeintroduction.html
<penguin42> ah - yet another GUI programming language
<jykae> penguin42: different approach, descriptive language for UI, programming can be done with the language of your choice, eg. C++ or Python
<penguin42> jykae: Nod, I'm fairly sure there are others with similar ideas that I've come across before
<penguin42> jykae: I mean it's not that different from teh files generated by glade
<bdrung> hi, someone here with a maverick i386 system who can testbuild a package?
<melodie_> bye, thanks for all !
<h3Ld3r> hi all
<h3Ld3r> need a bit of help on customizing an ubutnu CD from shell
<h3Ld3r> any one here to help me. plzzzzzzzz
<micahg> I have lm-sensors which is replacing lm-sensors-3, should I -v to the last lm-sensors upload or the last lm-sensors-3 upload?
<slangasek> ok, who changed what that caused *all* of my initramfses to be overwritten on upgrade?
<slangasek> they are now all broken
<slangasek> hmm, from a bootchart update
<slangasek> well, this will make it fun to figure out what regressed to break plymouth text display in the initramfs :(
<dupondje> [11150.306893] type=1400 audit(1310939778.399:16): apparmor="DENIED" operation="mkdir" parent=930 profile="/usr/sbin/cupsd" name="/run/samba/" pid=4148 comm="smb" requested_mask="c" denied_mask="c" fsuid=7 ouid=7
<dupondje> mmm
<dupondje> https://bugs.launchpad.net/ubuntu/+source/cups/+bug/812035
<ubottu> Ubuntu bug 812035 in cups (Ubuntu) "Cups needs access to /run/samba/" [Undecided,New]
#ubuntu-devel 2012-07-09
<pitti> Good morning
<pitti> OdyX: pyppd license change> no problem at all for Ubuntu, thanks!
<larsduesing> cjwatson: oh.. I think I get the picture... -proposed has to be related -security, -updates, -release; -release has to be related to -security, -release; updates - aehmm... getting complicated, yes...
<dholbach> good morning
<didrocks> bonjour dholbach
<dholbach> salut didrocks
<dholbach> comment Ã§a va?
<didrocks> dholbach: Ã§a va bien, et toi?
<dholbach> oui, Ã§a va - mais j'ai besoin d'un autre tasse de cafÃ© :)
<didrocks> dÃ©jÃ  fait ici ;)
<sil2100> huh?
<apw> mvo, ok so in that squid-deb-proxy branch is an updated fix which uses the same criteria that apt does in selecting which IP addresses it can use, which should eliminate the 'something wierd' errors: https://code.launchpad.net/~apw/ubuntu/quantal/squid-deb-proxy/lp1021298
<apw> mvo, it does involve a switch of language for the client script there, so i am slightly unsure if we need a dep there
<apw> i believe it is Essential: so we don't, but best to check
<robotex> Hello
<robotex> I created application for Ubuntu Showdown, but I can't create deb package
<robotex> please, somebody help me
<dpm> hi robotex, can you be a bit more specific? What is not working for you?
<robotex> I created PPA and signed it with PGP. Now I go to the my app source directory and trying it: http://developer.ubuntu.com/packaging/html/packaging-new-software.html But in this step I have next problems:
<robotex> 1. Checking the program. In this section tells about downloading and building sources, but I create my own sources. So, I thought I can go to the next step.
<robotex> so, I tar my sources to archive and go to step 'Starting a package'
<robotex> and first command:
<robotex> so, step 'Starting a package'
<robotex> robotex@robotex-laptop:~/workspace$ bzr dh-make mirrorcam 1.0 mirrorcam-1.0.tar-gz
<robotex> bzr: ERROR: Either run the command from an existing branch of upstream, or move mirrorcam aside and a new branch will be created there.
<robotex> What's wrong?
<mvo> apw: thanks, I have a look
<robotex> dpm, where can I read fully step by step instruction how to build deb package from pure source code
<dpm> robotex, would you mind moving over to the #ubuntu-app-devel channel to help you with your app showdown submission?
<robotex> ok, I'll go there
<ev> mpt: presumably we shouldn't show the "send an error report to help fix this problem" checkbox on debconf progress windows, right?
<mpt> ev, I didn't know there was such a thing as a debconf progress window
<mpt> Can you take a screenshot?
<ev> mpt: http://people.canonical.com/~evand/tmp/Screen%20shot%202012-07-09%20at%2010.22.42.png
<cjwatson> I don't think anything other than the installer uses the debconf progress type in practice (and the installer turns it into a rather better UI)
<ev> cjwatson: true. Somewhat relatedly, I think I'm going to ignore SETBLOCK
<ev> I can't see the rationale for "lets stuff a bunch of questions all on the same page", other than d-i
<cjwatson> nearly everything else does :-)
<ev> :)
<cjwatson> Oh, there's reasonable rationale for it in general, in that there may well be questions that are actually related; it's just not widely used
<cjwatson> For example, your MySQL username and password
<ev> ah, interesting
<cjwatson> Actually, mysql-server-* installation doesn't ask for a username, as it happens, it's asking for the DB root password.  But you get the idea
<ev> yeah, it's a reasonable example regardless
<cjwatson> Nobody uses it much because the dialog frontend doesn't implement it; although it would perhaps be interesting to grep the archive for uses of it, if you can be bothered
<cjwatson> Anyway, it'll always contain some other question which presumably you aren't ignoring
<cjwatson> (I assume you mean BEGINBLOCK/ENDBLOCK)
<cjwatson> You should ignore STOP too, if we're talking about intercepting the debconf protocol
<cjwatson> And VERSION, CAPB, probably SETTITLE/TITLE ... basically anything other than a GO that actually asks some questions, I suppose
<cjwatson> Definitely shouldn't error on any INPUT, because many of those won't be presented
<seb128> cjwatson, ev, hey, do you know if somebody in the foundation team looked at the recent daily iso testing issues: https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_default/60/
<cjwatson> Not again :-(
<cjwatson> I guess I'll look today
<mpt> ev, yowsers. Do you have any idea how often that appears between steps, and how often just by itself?
<mpt> ("Yowsers"? I meant "Gadzooks", of course.)
<seb128> cjwatson, it seems random, like i386 worked on saturday and not on sunday, and amd64 the opposite way
<seb128> cjwatson, I wonder if there is an issue with the jenkins setup...
<mpt> ev, it should be easy to imagine how SETBLOCK would be laid out -- you'd need to apply a sanity check to ensure the alert never gets taller than the screen, but you should be doing that anyway ;-)
<cjwatson> seb128: Well, there's an actual crash there
<seb128> cjwatson, ok, I'm not sure how to read those log, the i386 logs for #59 and #60 are quite different, like they would not test the same things...
<ev> mpt: what does the sanity check do when it fails? :) Split across pages?
<ev> for what it's worth, it does already work and its layout falls out of the UI code I've written
<mpt> ev, for multiple questions, yes. If even a single question is too tall, I guess you'd have to ellipsize it
<ev> good point
<ev> I suspect I can coerce the toolkit do to the latter automatically
<ev> I hope
<ev> this is GTK+ after all
<mpt> And remember, this text you're receiving is untrusted. Check what happens when someone gives you an EOF or a RTL direction change marker
<mpt> or 138 LF characters
<ev> sounds like we need a test harness
<robotex> robotex@robotex-laptop:~/workspace/mirrorcam-1.0$ fakeroot debian/rules clean debian/rules:13: *** missing separator (did you mean TAB instead of 8 spaces?).  Stop.
<robotex>  what's wrong?
<robotex> there is no tabs in this file
<cjwatson> robotex: sounds like you read the error message backwards; command lines in a Makefile (which debian/rules is) *must* start with a tab character
<robotex> oh
<robotex> tab or spaces
<robotex> ?
<cjwatson> tab
<mpt> ev, I dont have time to design that progress window now, but I can tackle it on Thursday
<cjwatson> it's a syntactic requirement, not subject to personal preferences
<ev> mpt: that's fine
<ev> I'll leave the one we have in place for now
<rbasak> Is the ubuntu-devel lists.u.c moderation queue monitored? I'd like to email it.
<robotex> <cjwatson>, thanks
<robotex> It's compiling!
<robotex> Yahoo!
<robotex> Done!
<robotex> my first deb package in a life ^_^
<Chipzz> cjwatson: I have wondered about that in teh past (debconf grouping); I suspect it is because a lot of front-ends ignore it (all the text-based ones do)
<Chipzz> that and people probably don't know about it
<cjwatson> rbasak: occasionally
<robotex> What?! Why package is empty? 0_o
<cjwatson> Could you ask this kind of thing on #ubuntu-app-devel, please?
<cjwatson> They're better suited to this kind of question
 * rbasak emails ubuntu-devel
<shakaran1> Could somebody sponsor this bug? https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1012602 It is very reproducible (with duplicates) and it contains a successful path. It only needs apply and release it
<ubottu> Launchpad bug 1012602 in software-properties (Ubuntu) "add-apt-repository crashed with UnicodeDecodeError in __main__: 'ascii' codec can't decode byte 0xc5 in position 3: ordinal not in range(128)" [Undecided,Confirmed]
<shakaran1> s/path/patch/
<ev> is it just me or is ./test_debconf.pl broken? The "call to abstract method CopyDBTestSetup::name" error isn't particularly helpful either.
<ev> ah, I get it now. Nevermind
<ev> still looking a bit bit-rotten though
<jamespage> if I do a seed update for packages which are not yet in main will it break everything todo with that seed?  or will it pull in the new packages anyway and stuff appears in component mismatches?
<jamespage> (context tomcat6 -> tomcat7 transition)
<cjwatson> jamespage: typically the latter but if it needs an MIR then please don't leave the MIR too long
<jamespage> cjwatson, MIR is already raised - still pending review and approval
<rbasak> shakaran1: it should enter the sponsorship queue automatically if you attach a debdiff. Do you know how to make one?
<shakaran1> rbasak: I don't know how to do it. Some useful tutorial?
<rbasak> shakaran1: https://wiki.ubuntu.com/PackagingGuide/Recipes/Debdiff, and also see https://wiki.ubuntu.com/SponsorshipProcess. Using UDD may be easier.
<shakaran1> rbasak: thanks I gonna read it just now ;)
<rbasak> shakaran1: note that you don't have to do this, since the reviewers team will work to get there from your patch, which is appreciated. But submitting something directly in the form that a sponsor can use speeds things up :)
<shakaran1> rbasak: it is not my patch. It is from another person. I am just a user affected with another duplicate. So if I just can save some time and speed up the process it is ok ;)
<shakaran1> rbasak: also I like learn new things ;)
<cjwatson> A debdiff is no faster for me than any other kind of patch.
<cjwatson> This is an odd myth.  You run patch over it either way, and chances are you'll probably have to edit or at least review the changelog, integration with the patch system, and such either way.  In fact sometimes it can take longer if somebody's tried to integrate it into the local patch system and got it wrong.
<shakaran1> cjwatson: the patch is only a string cast with utf8 function on python. But the bug has weeks and the patch 3 days. So if nobody can ship it until now I try to speed up the process. I just want the fix released soon.
<rbasak> cjwatson: ah, OK. The thing is, attaching a patch automatically subscribes ubuntu-reviewers, but attaching a debdiff automatically subscribers ubuntu-sponsors
<rbasak> cjwatson: is it OK to subscribe ubuntu-sponsors (since I seem to have permission to do that) with just a patch and no debdiff?
<mvo> apw: I'm looking at the squid-deb-proxy branch now, looks great, I assume you considered something like REACHABLE=$(cat /dev/null|nc $addrform $port) to be less good as it adds additional traffic to squid?
<apw> mvo, i was trying to avoid additional traffic, but if you think thats acceptable i can go that route
<mvo> apw: I think python is acceptable too :) was just wondering
<apw> as the key think is finding out what answers getaddrinfo(..., AI_ADDRCONFIG) will return
<cjwatson> rbasak: sure, I don't see why not
<cjwatson> rbasak: if you think it's actually something that somebody is trying to have uploaded
<apw> and i wanted a language which was _all capable so as to not need a binary package
<mvo> apw: yeah, just read about this in the manpage, haven't crossed that one yet
<apw> mvo, it was a new one on me too, i was all confused as to why a fe80 addr wouldn't not lookup but my 2001: ones would.  seems they don't count as a configured address to libc
<mvo> apw: so +1 for python and I'm happy to merge it, I will do some tiny bits of python changes during the merge if you don't mind. if yu do mind I'm happy to branch from your branch and you can review (will be tiny stylistic things)
<apw> which kinda makes sense.  though when looking up an fe80: having an fe80: should work imo, but thats an eglibc 'bug' in that case
<rbasak> cjwatson: ok, I'll do that, thanks
<apw> mvo, heh no please hack away on it, i would love to know what you prefer in python, its not a native language for me yet
<apw> mvo, so i can get it right next time :)
<mvo> apw: cool, once I'm done I will show you the diff (meh, phonecall)
<rbasak> shakaran1: I subscribed ubuntu-sponsors for you, so it should be in the sponsorship queue shortly. You can see its progress at: http://reports.qa.ubuntu.com/reports/sponsoring/index.html
<shakaran1> rbasak: thanks
<stgraber> @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: stgraber, infinity
<shakaran1> There are some specific channel for ubuntu webkit related stuff?
<mvo> apw: thanks a bunch, merged to trunk, it would be great if you would remerge and double check that i did not do something silly during the merge
<mvo> apw: if it looks good, I can upload (or you can, either way is fine with me)
<apw> mvo, its cirtainly prettier :)  i'll retest the new construction on my systems here and let you know
<mvo> apw: awsome, thanks a lot (plus a big THANKS for the fix itself of course)
<seb128> cjwatson, is you or anyone else looking at the ubiquity,daily iso test issues? can we help in some way?
<cjwatson> seb128: I'm looking at it
<cjwatson> Not sure how you could help apart from also attempting to work it out from scratch ;)
<cjwatson> I can reproduce it
<seb128> cjwatson, ok, thanks, I will let you handle it then ;-)
<seb128> cjwatson, sorry for being nagging about it, I'm trying to make sure we keep rick happy ;-)
<cjwatson> Yeah, I know, that's among the reasons I'm looking ;-)
<cjwatson> Looks like it was triggered by usb-storage becoming modular (I'm guessing), but it's a ubiquity bug anyway
<cjwatson> Or maybe a hw-detect bug, but it smells like ubiquity to me
<cjwatson> It's peculiar; the debconf debug trace doesn't make a lot of sense.  I might have to reboot and set -x it
<cjwatson> GO returns 0 and then it seems to bail out
<cjwatson> And my previous guess at the trigger is wrong because usb-storage was modular in precise too
<seb128> cjwatson, :-(
<seb128> ScottK, hey
<ScottK> Hello seb128.
<seb128> ScottK, those libreoffice SRU issues are a bit confusing, do you know what update is breaking what exactly? does lo 3.5.4 with the old menubar works fine or is that creating issues?
<seb128> ScottK, or is the menubar update creating the bug?
<seb128> or both together?
<ScottK> seb128: It's not clear to me either.
<seb128> ok :-(
<ScottK> One thing I was sure of on Friday though was leaving the new menubar in updates over the weekend with no one around was not the right answer.
<seb128> right, good call, thanks for getting that sorted ;-)
<ScottK> I use LO for $WORK every day, so I'm not going to experiment myself.
<seb128> ScottK, is there anyone around who is,was having the issue and could help figuring the combinaison of versions leading to the bug?
<ScottK> I don't know anything more than is in the bug, so not that I know of.
<Daviey> smoser: mterry just uploaded cloud-init ftbfs fix.
<seb128> ScottK, ok, I will follow up on the bug, thanks
<smoser> yeah. :-(
<smoser> i should have marked in progress
<smoser> suck
<ScottK> I don't think anyone what tried to contact the original reporter with specific test requests.
<cjwatson> You know what really annoys me?  rsyslog deciding to rate-limit my debugging output
<cjwatson> NO YOU STUPID PROGRAM I WANTED IT ALL
<smoser> YOU STUPID HUMAN I AM SMARTER THAN YOU
 * smoser has sworn at that rsyslog feature more than once.
<stgraber> seb128: what's the bug# for the libreoffice issue you mentioned earlier? I noticed that on my laptop I no longer have global menu integration (I have lo-menubar installed)
<stgraber> seb128: and that's on precise without -proposed enabled (LO 3.5.3-0ubuntu1 + lo-menubar 0.1.1-0ubuntu0.1)
<micahg> stgraber: and you had integration before the lo-menubar update>
<stgraber> micahg: yes
<seb128> micahg, stgraber: integration being broken is a known issue, but we decided it was less of an issue (cosmetic) than having libreoffice segfaulting on print preview and making you loose work
<seb128> stgraber, bug #754562  is the lo-menubar SRU, it documents that bug
<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
<seb128> stgraber, https://bugs.launchpad.net/bugs/1021946 is the "new" bug
<ubottu> Launchpad bug 1021946 in lo-menubar (Ubuntu Precise) "lo-menubar 0.1.1 from updates repositories makes plasma-desktop to crash" [High,Triaged]
<micahg> well, the integration issue isn't listed under regression potential in the lo-menubar SRU bug
<micahg> ah, I see it's mentioned in comment 38, I wonder if that was noticed
<micahg> so, it effectively disabled the lo-menubar anyways
 * micahg guesses we have to wait for RAOF to come online to find out if that was noticed or not when accepting :)
 * cjwatson syncs tiff and tiff3 now that jbigkit is in main
<mdeslaur> cjwatson: thanks
<micahg> that should clear a few depwaits :)
<cjwatson> mdeslaur: And I did check your recent upload was covered
<hallyn> so is libudisks2-dev meant to be a full drop-in replacement for libgdu-dev, i wonder
<cyphermox> hallyn: not without some porting
<hallyn> drat
<hallyn> cyphermox: so what would be the right thing to do wrt unity?  Do the porting for them, or open a bug?
<cyphermox> hallyn: unity was supposed to be taken care of by the unity developers; I think they already know about it
<cyphermox> didrocks: ^ ?
<hallyn> cool, thanks.
<didrocks> cyphermox: yeah, I sent that to popey
<didrocks> he's the team tracking the dep changes
<didrocks> hallyn: please open a bug, I'm sure there is already one
<hallyn> that seems contradictory :)
<hallyn> filed
<hallyn> mterry: amarok has NBS against liblastfm-0 which is replaced by liblastfm-1.  however it has build-dep against liblastfm-dev.  Do I understand right tha ta simple rebuild will fix it then?
<mterry> hallyn, very likely
<hallyn> mterry: is there a button one can click to make that happen?
<mterry> hallyn, no, you'll still need to do a new source upload.  If it was a ftbfs, you can click a button to rebuild it.  But for NBS kinds of things, you need a new source (otherwise you couldn't tell old binaries from the new ones)
<mterry> hallyn, so a "dch -R" will get you the right version number, then a simple comment like "no change rebuild for ..."
<hallyn> mterry: ok, thanks
<mterry> hallyn, but definitely test-build in a chroot first
<hallyn> yup
<mterry> it's possible other problems have cropped up since the last time it was built
<hallyn> will do, thanks.
<hallyn> (then i'll have to bug you/someone again to upload :)
<debfx> hallyn: afaik rebuilding amarok won't work as the API changed, apachelogger was working on it
<hallyn> debfx: yeah, i already ran into kdemultimedia-dev no longer existing, too.  thanks, i'll leave it to apachelogger then! :)
<stgraber> dupondje: hey there, I'm going through the sponsoring queue and noticed that bug 1015753 is waiting on a reply from you. Just wanted to make sure you're aware of it so we're not stuck there.
<ubottu> Launchpad bug 1015753 in cryptsetup (Ubuntu) "Sync cryptsetup 2:1.4.3-2 (main) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1015753
<xnox> stgraber: me looks at it just in case ;-)
<apw> mvo, ok seems to work in all three of the cases i can easily test here
<dupondje> stgraber: it needs to be merged indeed. Cause upstart files changed name.
<stgraber> dupondje: will you take care of this? from my understanding, it should just be a matter of adding a .maintscript file to transition the two conf files
<dupondje> stgraber: should be enough indeed. Need to check that out when having a bit time
<stgraber> dupondje: cool, thanks
<dupondje> or if somebody else feels to take it :) xnox? :)
<mvo> apw: very nice, want me to upload it? or do you want to upload yourself, either way is fine for me
<apw> mvo, /me can't upload it :)
<xnox> dupondje: I may look at it. i don't think I ever did conf file name transition.
<dupondje> me neither :)
<mvo> apw: thats fine, uploading in a sec
<stgraber> xnox: add .maintscript file containing "mv_conffile <source> <destination> <last version with source> <binary package name>", you'll need to pre-depends on dpkg >= 1.15.7.2 (man dpkg-maintscript-helper)
<xnox> stgraber: awesome, thanks. And keep it until 14.04....
<dupondje> stgraber: or is there another way in dh_installinit to have different named upstart files then .init files?
<stgraber> dupondje: I don't know dh_installinit that well, it's certainly possible with some hacks but I'd think it'd just end up being more confusing. Adding the .maintscript is the easiest (it'll generate a preinst entry moving the old conffile to the new path before dpkg unpacks, so you'll get the usual conffile prompt if it's different)
<doko> cjwatson, Daviey: is the python3.3 udeb needed in the forseeable future?
<Daviey> doko: very unlucky
<Daviey> unlikely
 * cjwatson denies knowledge
<cjwatson> seb128: argh, I can't get the blasted thing to fail under any decent level of debugging
<doko> chrisccoulson, ogasawara, Sweetshark: the ubuntu-toolchain-r/test ppa has a binutils snapshot. please could you do a kernel/firefox/lo test build with it?
<ogasawara> doko: sure
<OdyX> pitti: thanks.
<micahg> doko: which release is this for?
<doko> micahg, q
<doko> micahg, so yes, a chromium build would be nice too
<micahg> doko: I'm not looking really looking after q ATM
<seb128> cjwatson, :-(
<seb128> cjwatson, is there any update which was likely to have caused the issue that we could revert while we debug? (asking because rick already hinted that after several days of test not working we should have reverted the problematic update)
<cjwatson> seb128: I have absolutely no idea what to revert or else I would have already done so.
<micahg> doko: chrisccoulson is a bit busy right now, I'll kick off a Firefox build for you
<cjwatson> seb128: And previous test failures were different ...
<seb128> cjwatson, ok...
<seb128> cjwatson, previous ones on the same iso, or you mean until you fixed the other bug on friday?
<cjwatson> the latter
<seb128> cjwatson, what is weird is that some of the builds success
<cjwatson> It seems to be racy, but I haven't worked out why
<seb128> so seems racy as a bug
<cjwatson> Friday> so what I mean is that I'm not prepared to take responsibility for not fixing any failures that arose over the weekend :-P
<seb128> hehe, fair enough
<seb128> in your defense the first build on saturday was green ;-)
<stgraber> @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: infinity
<cjwatson> seb128: I don't suppose you know if there's any way to get ubiquity --debug output from https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_default/60/ ?
<cjwatson> Hm, it doesn't run with --debug at the moment by the looks of things
<micahg> doko: I"ll have to do it later, apparently the package that allowed adding PPAs from the cli has changed in quantal and it's breaking my local scripts, someone from the desktop team will have to help you
<seb128> cjwatson, sorry I don't know, we would need jibel there...
<cjwatson> seb128: I'm not getting anywhere and have apparently stopped being able to reproduce it.  Giving up for today.
<seb128> cjwatson, ok
<seb128> cjwatson, have a good evening
<seb128> the iso tests are at least not all red for days so while we are still on the hook we might get away with it ;-)
<cjwatson> If it recurs then maybe it will come with some kind of clue on reproducing it more reliably.
<hallyn> does anyone see why python-support has not been built for anything but i386?
<hallyn> doesn't look like it failed...
<hallyn> just didn't try
<Laney> because it's arch:all. the same binary package can be used on any architecture.
<pitti> hallyn: it's arch:all
<SpamapS> all together now
<SpamapS> its arch:all!
<SpamapS> this is how musical numbers start
<hallyn> so the python-greenlet build failure should be resolved if we just hit re-build?
<hallyn> (it failed bc of python-support being unavailable)
<jtaylor> no
<jtaylor> python-support is removed from main, it needs to be transition to dh_python2
<Laney> smells like a component mismatch
<hallyn> python-support needs to be transitioned to dh_python2 so it can go back into main?
<jtaylor> no greenlet
<jtaylor> python-support and dh_python2 are both packaging helpers, the former is deprecated
<hallyn> gotcha
<hallyn> thanks
<Laney> there's a dh_python2 patch on the bts
<Laney> you can probably use that, assuming Daviey has clue :P
<hallyn> Daviey: ^ do you think we should push your debdiff into python-greenlet for q, or wait for debian to accept it?
<jtaylor> debian won't accept it till wheezy +1
<pitti> FYI, Debian is in freeze now; I wouldn't depend on Debian to accept anything non-urgent right now
<hallyn> ok thanks
<Daviey> hallyn: yeah, i had hoped it would have got in.. it's been there for ages.. feel free to sponsor it in, or i'll do it tomorrow
<Daviey> thanks for asking
<Daviey> Laney: the clue i had, i lost long ago
<Laney> I think I sold it, soz for that
<Daviey> hallyn: debian bug 673244
<ubottu> Debian bug 673244 in python-greenlet "python-greenlet: Please consider converting to dh_python2" [Normal,Open] http://bugs.debian.org/673244
<hallyn> Daviey: yup, already test-building, thanks
<Daviey> I really wish installing language-pack-en didn't bring in firefox-locale-en.. it urks me
<hallyn> that's not how you spell irk :)
<ScottK> Maybe it is in en-GB.
<hallyn> Daviey: you never opened an ubuntu bug for that one right?  (about to create one)
<Daviey> hallyn: i did not..  i often think it's not worth opening a bug just to close it again a few mins later.
<Daviey> but does increase street cred via karma i suppose :)
<hallyn> OTOH it gives something to reference in changelog...  <shrug>
<soren> At one point I had a script that did all of that for me. I'd just do "whatever.py 'Title' 'Description'". It'd file a bug with the relevant title and description and add a changelog entry saying 'Fixed "$TITLE" (LP: #XXX)'
<soren> I wonder where that went..
<hallyn> you've since re-written it in go, and posted it at code.google
<Daviey> soren: why not just write a while true: open-pointless-bug(title=rand()) done ?
<soren> I think it was back in the day when we had to do weekly activity reports. This way, I had a paper trail.
<Daviey> eww
<soren> "eww paper trail" or "eww activity reports"?
<hallyn> i dunno, i still like the idea, especially for figuring out, while doing a big merge, wtf person x was thinking 10 commits ago
<Daviey> soren: both.
<Laney> Most stuff can be adequately dealt with by being a bit more verbose in your changelogs.
<infinity> hallyn / Daviey: Unless it's for an SRU (where we want to bugs for verification-tracking and such), I'm not sure I see the point in clogging up the bug database just to have something to close in a changelog.
<infinity> hallyn / Daviey: Given that, in the short window between opening and closing it, the only person reading it will be you, it seems entirely pointless.
<hallyn> infinity: so assuming that there is an open debian bug, and we don't want to (i assume) put 'Closes: XXX' in the ubuntu changelog, isn't the ubuntu bug (with debian bug linked) useful in the changelog?
<hallyn> ok, less work, i'm on board
<infinity> hallyn: I put close: 1234 in Ubuntu changelogs all the time.
<infinity> hallyn: closes*
<hallyn> when it hasn't gone in through debian?
<infinity> hallyn: A reference to a bug is handy, if the bug has traffic, a reference to a bug you artificially created to have a reference is silly, you should just have better changelogs.
<hallyn> my changelogs reads like a first rate novel
<infinity> hallyn: If it hasn't been uploaded to Debian, it's still not a lie that your change *would* closes: 1234. :P
<tumbleweed> there's no point in copying a bug to LP just so we can link to it from the changelog. Closes on debian bugs ++
<infinity> (I'd also argue that, freeze or not, if the dh_python2 conversion is clean, it would be perfectly acceptable to upload to Debian)
<infinity> python-support dying is, unfortunately, not a release goal, but it's still awful and needs to die.
<Laney> I'm not sure the release team would accept that argumentation
<ScottK> Wheezy +1.  Both -support and -central should die.
<Laney> what about The Morph Factor?
<jtaylor> opinions on -support vary greatly in debian
<jtaylor> you won't get a dh_python2 patch through jwilk or morph until support is removed
<ScottK> jwilk is making suggestions now.
<tumbleweed> jwilk has sponsored dh_python2 packgaes (although not often)
<tumbleweed> (I think)
<ScottK> I think he's coming around and in Wheezy +1 POX can work to satisfy his concerns.
<ScottK> Someone's going to have to fix an RC bug in python-support before release.
<infinity> Laney: Well, I don't maintain any python junk, so I can give random advice without it actually affecting me. ;)
<Laney> Me neither. I just know that the freeze guidelines rule out random packaging changes
<infinity> Laney: Sure, though this is, arguably, not a "random change", but fixing a bug.
<Laney> but you're there, so can convince folk over $cheese and $wine.
<infinity> The bug being "oh god, python-support".
<jtaylor> jcristau recenty said dh_python2 does not get an exception
<jtaylor> as long as support does not cause issues
<infinity> jtaylor: Ahh, shame.
<doko> sometimes you have to "convince" jcristeau
<jtaylor> change it just because it makes ubuntu delta smaller will probably not be convincing
<infinity> doko: I know how you tend to "convince" me.
 * Laney blushes
<jtaylor> doko: do we need the mpich2 delta?
<jtaylor> to my knowledge blcr does not work anyway
<jtaylor> brcl
<doko> jtaylor, then fix brcl
<jtaylor> doko: upstream fails at that, why should I succeed?
<jtaylor> mpch2 is semi-broken in precise and quantal, a sync would fix it, I don'T feel like merging for no reason
<jtaylor> the newest kernel upstream supports is 2.6.38
<dobey> infinity: hey
<dobey> infinity: test-building re-packing of ubuntuone-client right now. do i need to upload it as 0ubuntu1.1 now, or is 0ubuntu1 still fine since it hasn't been accepted?
<psusi> cjwatson, the documentation on the ubuntu wiki says to reinstall grub from the livecd, you should use --boot-directory=/mnt/boot.  AFAICS, this is dead wrong.  That switch changes the /boot directory, but grub-install needs to know --root-directory=/mnt, otherwise it assumes the root of the livecd is the root, however, --root-directory is also not mentioned in the man page, and the script comments say it is accepted for backward compatibility.  Am I mi
<psusi> ssing something?
<RAOF> micahg: I didn't notice comments posted after I accepted lo-menubar into -proposed when I accepted lo-menubar into -proposed, no âº. slangasek would appear to be the person who accepted it into -updates; I don't know whether he noticed the "it doesn't actually work" comments.
<ScottK> RAOF: I think they were added after once someone noticed the other bug.
<psusi> cjwatson, nevermind
<RAOF> ScottK: They seemed to be directly above slangasek's verification-done tagging; maybe this was a race, though.
<ScottK> Not sure.
<ScottK> That was my impression on Friday, anyway.
<cjwatson> psusi: the chroot method on the wiki is the only one I endorse or recommend; I didn't write that page and have not had the time it would take to edit it into complete sanity
#ubuntu-devel 2012-07-10
<infinity> dobey: Same version is fine.
<infinity> dobey: I'll reject your old one now.
<infinity> dobey: If I can remember why I was making you re-do it...
<infinity> dobey: Oh, right, cause you missed integrating old changelog entries.  Yeah, I'll just reject your old one, feel free to re-use the version.
<micahg> RAOF: wait, so, you weren't aware the integration was broken or you were? comment 38 says no integration but no crash, comment 43 is when it was accepted
<BenC> zul: Any reason things like glance are i386 only?
<zul> BenC: no
<zul> BenC: please open up a bug about it
<BenC> zul: Any pushback to me just uploading with powerpc,amd64 added?
<zul> BenC:  yeah can you do a merge prop against lp:~ubuntu-server-dev/glance/folsom please
<BenC> Err, but it is then :)
<BenC> *bug
<StevenK> BenC: As a thought, have you checked P-a-s?
<BenC> p-a-s?
<StevenK> BenC: Packages-arch-specific
<BenC> What is that?
<BenC> StevenK: I at least know that glance works on powerpc
<micahg> not on p-a-s
<StevenK> BenC: http://bazaar.launchpad.net/~ubuntu-core-dev/packages-arch-specific/ubuntu/view/head:/Packages-arch-specific
<BenC> Excellent, keystone, glance and node-* isn't on there
<micahg> infinity: I take it you didn't see bug 1022475?
<ubottu> Launchpad bug 1022475 in packagekit (Ubuntu) "Sync packagekit 0.7.5-2 (main) from Debian unstable (main)" [Wishlist,New] https://launchpad.net/bugs/1022475
<BenC> zul: here's a bit of infoâ¦it only builds on i386 because it's Arch: all
<BenC> silly me
<StevenK> Haha
<micahg> BenC: not everything is like Firefox/Thunderbird and makes arch:all stuff arch:any for almost no reason :)
<RAOF> micahg: Ah, you're right. I don't recall parsing comment 38 to mean âno integrationâ. If I had, I would have asked whether it could be fixed.
<pitti> Good morning
<RAOF> This is an SRU team PSA: uploading your source to lucid-proposed twice does not make it faster to accept. Thank you âº
<ScottK> Grumpy new SRU guy adds: "If it causes me to be confused, I'll probably just reject them both and let you sort it out."
<elky> + "Thank you. Come again." ?
<nigelb> we really need bash.ubuntu.org.
<StevenK> nigelb: You still want a bash for #launchpad-dev
<nigelb> StevenK: I do.
<nigelb> StevenK: If my server could take the load, I'd install chirpy on it.
<TheMuso> Where as apt-add-repository gone? If its been completely removed, what should I be using to add PPAs on the command-line instead? THis is on quantal.
<StevenK> TheMuso: add-apt-repository
 * TheMuso slaps himself. Of course, I had things the wrong way around, thanks StevenK.
<pitti> the fun thing is that software-properties even provided a symlink for apt-add-repository, but apparently stopped doing so
<lifeless> doooh
<dholbach> good morning
<TheMuso> pitti: Ah so I may have been correct in the first place, and I didn't even think of checking to see if there were other forms like add-apt-repository.
 * RAOF has always used add-apt-repository
<lifeless> IIRC add-appt-repository was first and I and others filed bugs pointing out that apt-add-repository was more consistent
<jamespage> Q: is it acceptable for package a to stop and disable a daemon from package b? package a needs the binary but takes direct control of it
<jamespage> I could do a split and have a -common and -daemon package but I'd like to keep compatible with 12.04
<maxb> It sounds more than a bit odd, but I don't recall reading an explicit prohibition, so I guess it would fall under general rules of good judgement... what packages, ooi?
<jamespage> maxb, I'm packaging a network emulator called mininet that makes use of the openvswitch controller
<jamespage> however it takes direct control of the binary rather than using the controller that gets automatically started on install of openvswitch-controller
<maxb> sounds a bit evil :-)
<maxb> unfortunately I've not used either, or anything similar, so I can't usefully comment further
<Roj> hi when i use quickly sabmitubuntu package send to lanchpade but bulder.py and helper.py and window.py in my project file not attache to it and get error in build http://pastebin.com/7dCut96j
<cjwatson> pitti: oh, I might have removed that symlink by accident
<cjwatson> Yeah, totally my fault, sorry, I'll put that back
<pitti> ah, thanks :)
<cjwatson> It turns out that "usr/bin/add-apt-repository usr/bin/apt-add-repository" is actually really hard to parse by eye
<pitti> I guess that's also the reason why the symlink exists in the first place
 * pitti mutters "udev-udeb"
<cjwatson> OTOH "usr/share/man/man1/add-apt-repository.1.gz usr/share/man/man1/add-apt-repository.1.gz" was wrong ...
<pitti> cjwatson: ^ consider it consolation that you aren't the only one :)
<Daviey> Is someone looking at bug 1020229 .. looks like a Breaks/Replaces issue.
<ubottu> Launchpad bug 1020229 in ubuntu-release-upgrader (Ubuntu) "package python3-distupgrade (not installed) failed to install/upgrade: trying to overwrite '/usr/lib/python3/dist-packages/DistUpgrade/__init__.py', which is also in package python3-update-manager 1:0.164" [Undecided,Confirmed] https://launchpad.net/bugs/1020229
<cjwatson> Daviey: on it
<Daviey> cjwatson: super.
<cjwatson> Daviey: uploaded now
<Daviey> \o/
<brendand> does anyone know the minimum set of packages needed to play a flash video in firefox?
<brendand> in a basic precise install i add flashplugin-installer
<brendand> but then when i try to open a flash video in firefox it complains about sorenson spark codec
<micahg> infinity: sorry, just realized, you just did the AA copy for packagekit, so disregard
<micahg> mterry: is there a reason why you're switching some things to have a new diff with Debian on libtiff5-dev?
<barry> pitti: have you looked at all at upgrading dbus to 1.6.2-2?  we're quite behind.  i spend a little time on it yesterday (in between all the tech issues i was having ;) and the merge is not straightforward.  i could fix various issues in debian/ but the upstart integration patches are more problematic.  i was going to ping jodh to see what he thought, but he's not around right now.  i'm not eager to spend a ton of time on that right now,
<barry> but might make it a background task, if we think it's worth it
<mterry> micahg, just switching main packages to libtiff5 rather than libtiff4
<micahg> mterry: are we actually planning to drop libtiff4 from main for quantal then?
<mterry> micahg, I think it would be nice to
<micahg> mterry: ok, thanks
<mterry> And obviously, I'm passing the tiny patches on to Debian, hopefully the delta is a one cycle thing
 * Laney thinks micahg would be interested in hanging out in #ubuntu+1-maint
<micahg> Laney: there's a channel?  I was told last cycle there wasn't one :-/
<Laney> pretty sure it was there last cycle
<micahg> Laney: thanks
<seb128> there was on last cycle for pretty sure, I remember asking if there was really enough discussions to justify taking it of #ubuntu-devel
<ScottK> barry: Is system-config-printer on the python3 porting list?
<barry> ScottK: yep, but afaict not yet started
<ScottK> barry: system-config-printer-kde is a separate source.  It probably needs to be ported in tandem.
<barry> ScottK: is it dependent on system-config-printer-{udev,common,gnome}?
<ScottK> Yes (common)
<ScottK> that or the port needs to work with both 2.7 and 3.2 unmodified as system-config-printer-kde uses symlinks to code in common to run.
 * barry nods
<ScottK> When the time comes, I'm willing to help with that.
<ScottK> Just let me know.
<barry> ScottK: great, thanks
<zul> is there someone on the MIR team around?
<pitti> barry: I have a dbus 1.5.x merge with Debian in my PPA
<pitti> barry: but it breaked indicators the last time I looked
<pitti> barry: I just dropped the integration patches; they were never sent upstream apparently, and we don't use them at all
<barry> pitti: oh?  that would make my 1.6.2 branch much easier to drop the upstart stuff.  i wonder if 1.6.x would have any better effect on indicators?
<pitti> barry: worth a try for sure :)
<pitti> barry: https://launchpad.net/~pitti/+archive/ppa/+sourcepub/2434004/+listing-archive-extra FYI
<barry> pitti: indeed. :)  i'll continue working on it in the background, and submit a mp for your review if i get something decent
<pitti> barry: there aren't too many changes left, and they are quite simple
<barry> yep.  very nice to be able to drop many patches
<barry> it would be awesome to eventually get in sync :)
<pitti> I forgot about this thing TBH
<vibhav> Do we really need to mention the update-manager changes in an ubuntu delta?
<vibhav> update-maintainer*
<micahg> vibhav: no
<vibhav> micahg: So should I drop that part while doing a merge?
<micahg> vibhav: drop what?
<vibhav> the part saying "Set Ubuntu maintainer"
<micahg> vibhav: drop from where?
<vibhav> d/changelog
<micahg> you don't change an old changelog entry
<Daviey> vibhav: 'Policy' (meh) specifically states not to mention it.
<Daviey> micahg: i think he means copy and pasting the old entry to a new stanza, and should he remove that line
<micahg> if ^^ is the case, then yes :)
<vibhav> micahg: https://launchpad.net/ubuntu/+source/efibootmgr/0.5.4-2ubuntu1
<vibhav> have a look at the changelog
<micahg> vibhav: that can be sync'd most likely as lpia is gone
<Daviey> vibhav: that tastes like a sync to me
<vibhav> yup
<cjwatson> agreed
<vibhav> I took as an example though
<micahg> vibhav: so, you wouldn't include it in a new changelog, but shouldn't modify old ones
<vibhav> micahg: thanks
<stokachu> hi, could i get someone to have a look at the following bugs for sponsorship: http://pad.lv/977959 http://pad.lv/977947
<ubottu> Launchpad bug 977959 in libgnome (Ubuntu Precise) "Please transition libgnome to multi-arch" [Medium,Confirmed]
<ubottu> Launchpad bug 977947 in libbonobo (Ubuntu Quantal) "Please transition libbonobo to multi-arch" [Medium,Triaged]
<stokachu> err
<stokachu> http://pad.lv/977952 http://pad.lv/977947
<ubottu> Launchpad bug 977952 in libbonoboui (Ubuntu Precise) "Please transition libbonoboui to multi-arch" [Medium,Triaged]
<stokachu> libonobo*
<ubottu> Launchpad bug 977947 in libbonobo (Ubuntu Quantal) "Please transition libbonobo to multi-arch" [Medium,Triaged]
<vibhav> stokachu: Did you attach a debdiff?
<stokachu> 977952 has SRU/merge proposal
<vibhav> stokachu: ah
<stokachu> 977947 has SRU/debdiff
<smoser> RAOF, around?
<seb128> smoser, it's middle of the night in .au, I doubt he will be around before some hours
<smoser> right. thanks.
<slangasek> RAOF: bug #754562: the comments from people saying "it doesn't work" after it was in -proposed were apparently speaking about something quite different from the original bug, which was "the program crashes"
<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
<slangasek> RAOF: did I miss something?
<micahg> slangasek: the SRU fixed the crash, but broke lo-menubar
<slangasek> micahg: ok; that was not my reading of the comments, I interpreted them as a subset of "didn't fix it for me"
<slangasek> sorry for misunderstanding
<micahg> the problem is, breaking lo-menubar was in comment #38 before it was accepted, so the whole mess is confusing
<micahg> i.e. it was known at the time of upload
<slangasek> ah
<stokachu> cjwatson, barry : would you guys happen to know what commit contained fix wrt http://pad.lv/979661 comment #21
<ubottu> Launchpad bug 979661 in update-manager (Ubuntu Precise) "oneiric to precise: debconf: unable to initialize frontend: Gnome and falls back to Dialog" [Critical,Triaged]
<dobey> infinity: re-uploaded ubuntuone-client last night; if we could get it and ubuntuone-storage-protocol accepted, that would be awesome
<barry> stokachu: i don't, sorry
<cjwatson> stokachu: bug 993190, lp:update-manager r2391.1.3, I think
<ubottu> Error: Launchpad bug 993190 could not be found
<stokachu> cjwatson: thanks ill look into that
<cjwatson> (might need some bug cleanup ...)
<stokachu> cjwatson: this is going to be hectic since the switch to python 3 i assume
<cjwatson> stokachu: shouldn't think so, since that change was originally on a precise-proposed branch
<stokachu> cjwatson: ah didnt realize 993190 was a private bug
<stokachu> thats referenced in the -proposed changelog
<cjwatson> Yeah, I think it's a private counterpart of the public bug you referred to
<stokachu> cjwatson: so 979661 should be fixed in precise but hasn't been set to fix released?
<stokachu> i also thought the changelog was supposed to only reference public lp bugs
<cjwatson> Yes, it is; this was a screwup
<cjwatson> Looks like it should indeed be fixed in precise-updates, though some verification wouldn't hurt
<stokachu> cjwatson: so ill add a verification-needed tag? and either myself or gema can test this
<stokachu> cjwatson: also should i just create a merge proposal to alter the changelog to represent the public lp?
<stokachu> or is that a quick fix from a different route
<cjwatson> I'm not sure there's any point to the verification-needed/verification-done system here, since it's already in -updates
<gema> stokachu: what can I test?
<gema> stokachu: or should I test?
<stokachu> cjwatson: ok, as far as getting this issue in the proper state what can i do?
<cjwatson> I've amended the changelog now, although it's pretty academic
<stokachu> ok
<cjwatson> check that it's fixed and close the bug if it is :-)
<cjwatson> that's about it
<stokachu> ok, will the janitor pick up this issue and do its thing?
<cjwatson> no
<cjwatson> there is no automation to help
<stokachu> ok so ill just manually set to fix released if tests pass
<cjwatson> yep
<stokachu> cjwatson: cool thanks man
<stokachu> gema: was hoping to get http://pad.lv/979661 closed
<ubottu> Launchpad bug 979661 in update-manager (Ubuntu Precise) "oneiric to precise: debconf: unable to initialize frontend: Gnome and falls back to Dialog" [Critical,Triaged]
<cjwatson> right, best you can do
<gema> stokachu: ack, I had already forgotten about it
<stokachu> gema: so we're good i can set to closed?
<gema> stokachu: if you have verified it and are happy, yes
<stokachu> gema: i havent done any verification yet :(
<gema> stokachu: then you cannot close it, if you don't get to it today, I will try to do that tomorrow
<gema> stokachu: can you send me an email with the details if you need me to do it? I am already off
<gema> even though still finishing off some stuff
<stokachu> thats ok ill do it
<stokachu> seb128: wrt #7 for http://pad.lv/977940, is the 3rd point necessary since libgnomevfs2-common already conflicts libgnomvfs2-extra is is depended by libgnomevfs2-0?
<ubottu> Launchpad bug 977940 in gnome-vfs (Ubuntu Precise) "Please transition gnome-vfs to multi-arch" [Medium,In progress]
<seb128> stokachu, what conflicts libgnomevfs2-extra?
<seb128> stokachu, libgnomevfs2-extra (<< 1:2.16.3-6) you mean? that's an old version
<stokachu> seb128: should we bump the version then or do you think we need a conflict added to libgnomevfs2-0
<seb128> stokachu, either way works, just anything which forces you to upgrade both ;-)
<stokachu> seb128: ok cool thanks :D i modified the other changes you mentioned and verified it according to the debian policy
<seb128> stokachu, great, thanks
<stokachu> seb128: hopefully the next update will have it sorted
<stokachu> seb128: for clarification would you look at this commit bit.ly/NeGXwi
<stokachu> seb128: i just told libgnomevfs2-0 to replace libgnomevfs2-common if they exist below the latest precise release
<micahg> stokachu: you probably want a breaks with that as well, see http://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces
<stokachu> micahg: ah nice catch ill add that now
<stokachu> looks like the depends are already taken care of libgnomevfs2-common (>= ${gnome:Version}),
<alazare619> where can i find the list of minimal and standard packagelist for ubuntu
<alazare619> ive tried search http://people.canonical.com/~ubuntu-archive/seeds/
<alazare619> livecd-rootfs im tried to take the default ubuntu one and modify it to my use but its confusing me as to where minimal and standard task are
<micahg> alazare619: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.quantal/
<alazare619> thank you micahg
<alazare619> one last question do you know what method ubuntu uses or script to build the iso after the chroot is squashed?
<micahg> nope
<alazare619> dang
<jtaylor> mterry: imagemagick really got a dependency on fftw?
<jtaylor> thats long obsolete?
<mterry> jtaylor, yeah, just a typo.  Debian is correcting it already
<jtaylor> k
<infinity> jamespage: Naughty.  No manpage for thrift.
<phoenix_firebrd> what is the advantage of signing the ubuntu code of conduct?
<micahg> well, it's a requirement for membership
<tumbleweed> also required to have PPAs, IIRC
<phoenix_firebrd> tumbleweed: dev or normal?
<tumbleweed> what does that mean?
<phoenix_firebrd> you meant membership , do you mean a developer access membership or for any type of membership?
<tumbleweed> I was saying that you need to sign the CoC if you want to be able to have/contribute to PPAs
<phoenix_firebrd> ok do you have a sysadmin channel, i have some issues getting the gpg fingerprint
<phoenix_firebrd> tumbleweed: ^
<tumbleweed> #ubuntu?
<phoenix_firebrd> tumbleweed: ty
<RAOF> smoser: Around now!
<RAOF> slangasek: Yeah, sorry. I missed the original âthis won't actually have global menus, but won't crashâ bit.
#ubuntu-devel 2012-07-11
<BenC> Can anyone give ghc a priority bump on the ppc buildd please?
<StevenK> BenC: Link the build to me?
<BenC> StevenK: https://launchpad.net/ubuntu/+source/ghc/7.4.1-4ubuntu1/+build/3646882
<StevenK> BenC: Rescored.
<BenC> StevenK: thanks!
<StevenK> It dropped from 60 minutes to 26.
<BenC> StevenK: quicker than expected, it started already
<BenC> StevenK: if all goes well, this should clear out a huge chunk of FTBFS and dep-waits on ppc
<StevenK> \o/
<BenC> StevenK: any chance of an easy way to kick off rebuilds of all FTBFS on ppc matching .*haskell.* (once this is done)?
<StevenK> A lot of clicking on LP? :-)
 * BenC prepares his rebuild-clicker thingy
<lifeless> api scripts should be able to, no?
<hupahuper> Hello all! I had a quick question, I received an email back from submitting an app to the app showdown, and it said he made some changes and then "
<hupahuper> I'll submit it for vote for inclusion in Ubuntu Extras."
<hupahuper> I would assume this means I should take no action? However, the email also said, as part of the standard template, that I should make the changes and resubmit the application.
<hupahuper> also, my status on myapps is Needs information. He said he posted the revised edition on a ppa which he linked, so should I resubmit and point to that ppa? Or merge, then resubmit with new ppa?
<RAOF> hupahuper: I'm not familiar with the myapps process, and I suspect that most of the people in this channel aren't, either. As /topic says, I think you'll be better off in #ubuntu-app-devel
<hupahuper> ah, sorry. Thanks!
<RAOF> No problem!
<pitti> Good morning
<thinkndev> good evening
<BenC> Good morning pitti
<BenC> StevenK: Do builds automatically get accepted or is there some handling occurring on that end?
<StevenK> BenC: It may be in NEW
<BenC> StevenK: shouldn't be, nothing new in the package and it's accepted on i386 and amd64, but powerpc seems to be slow on the uptake
<BenC> s/accepted/processed/
<BenC> It's accepted for powerpc, just not published
<StevenK> BenC: Ah, the publisher is blocked by generate-contents-files
<BenC> Ah, thanks
<Debolaz> Is wayland really going into 12.10?
<Debolaz> Or was that just some wild rumor being passed around by the ignorant masses? :)
 * Debolaz gets excited every time wayland is mentioned.
<ScottK> Debolaz: The last two releases have had wayland.
 * ScottK is sure the next one won't be any different.
<Debolaz> ScottK: Let me rephrase it: Actually used in 12.10.
<ScottK> By default, no.
<RAOF> Actually, TBD.
<RAOF> Still aiming for it, yes.
<RAOF> Debolaz: See https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-system-compositor
<RAOF> That's not user- or developer-visible wayland, of course.
<dholbach> good morning
<Laney> http://paste.ubuntu.com/1085796/
<Laney> should apt/dpkg be able to recover from this, or do I need to --reinstall?
<jamespage> cjwatson, around? my seed change broken the tomcat server task - not sure I understand why based on our conversation on Monday
<tvoss> doko, ping
<pitti> hallyn: FYI, I reverted your libtiff5-dev cups change; that's not the right way; if we want to switch to libtiff5 by default, the "Provides: libtiff-dev" needs to be moved from 4 to 5 instead
<cjwatson> jamespage: broke how?
<jamespage> cjwatson, so I can see that germinate picked up the seed change OK
<jamespage> but the ISO image build can't locate the tomcat7 packages
<cjwatson> jamespage: oh, it's still in component-mismatches
<jamespage> cjwatson, so the packages have to be in main before the ISO build will pick them up?
<cjwatson> now, I don't particularly think it needs an MIR since it's just a new version; but you filed one and it is as yet unapproved
<cjwatson> yes
<jamespage> cjwatson, right - I misunderstood then
<cjwatson> I'm a bit confused by your comment in the bug
<cjwatson> "Jamie - When do you think you will be able to complete this review?"
<cjwatson> but Jamie acked tomcat7 once tomcat6 is demoted
<jamespage> cjwatson, jdstrand did give an initial approval for tomcat7 on the MIR - but I added an extra dependency to enable the test suites which has not been acked
<cjwatson> ah
<cjwatson> so, I can act on the movements to main as soon as the MIR bits are ready, but I can't process the MIR for you
<jamespage> cjwatson, OK - I'll see what jdstrand says when he gets online but I expect the QA team will want this fixed
<jamespage> so I will probably back out my seed change later today
<xclaesse> hello,
<xclaesse> does ubuntu installer support partitions on encrypted LVM nowadays? or should I still use the text-based installer?
<xclaesse> also, will it do the partition alignment for SSD disks?
<cjwatson> xclaesse: encrypted LVM> not yet; it's on the roadmap for 12.10, hopefully
<cjwatson> xclaesse: SSD alignment should work in 12.04, except for GPT (known bug, fixed in 12.10, will hopefully be fixed in 12.04.1 or failing that 12.04.2)
<xclaesse> cjwatson, and if I use the alternate installer to have encrypted LVM, will it align as well?
<cjwatson> I think so, though there are a lot of layers in that case :-)
<xclaesse> yeah luks, lvm, ext4 :)
<xclaesse> googling, and it seems it's possible to do with ubuntu
<xclaesse> thanks :)
<seb128> cjwatson, hey, is there any progress on the ubiquity,daily iso test issues?
<cjwatson> seb128: no, I tried reproducing them again yesterday and failed to reproduce even once
<seb128> :-(
<seb128> cjwatson, so what would help at this point? having the test setup to run ubiquity under --debug or something?
<cjwatson> a way to improve the probability of reproducing it locally
<cjwatson> I need further modifications beyond --debug
<cjwatson> I mean I can keep randomly trying but it's not a very efficient use of time :-P
<seb128> right
<seb128> but we need to figure out something before rick kill us all :p
<cjwatson> I'll have another go, but I don't really know what to say
<cjwatson> when it's this hard to reproduce manually it seems like the priority ought to be adjusted down from OMGDROPEVERYTHING a bit
<seb128> cjwatson, right, I agree with that, I just think rick or jason are going to come back at some point asking where we stand and what's the plan to get the issues resolved so I'm trying to figure what the answers to those questions are...
<seb128> cjwatson, do we have any idea that is a real issue for users out of the test setup?
<seb128> or we just don't have enough tracking,feedback to know that?
<cjwatson> not really aside from errors.ubuntu.com and such
<jasoncwarner_> hey cjwatson and seb128 , just catching up. can we at least revert the change(s) that are causing it until we have a way to reproduce it ?
<cjwatson> jasoncwarner_: no
<cjwatson> jasoncwarner_: there is no change I can identify as causing it
<jasoncwarner_> cjwatson: ok....hmmm...when you say "hard to reproduce manually", are you saying you can't reproduce, or that it is a challenge to reproduce it?
<cjwatson> none of the recent installer changes have been AFAICS remotely related, and most of them fixed other bugs that also showed up in QA so reversion would not be an improvment
<cjwatson> *improvement
<cjwatson> jasoncwarner_: I have been able to reproduce maybe twice out of about a dozen attempts
<cjwatson> jasoncwarner_: unfortunately neither of those were with sufficient debugging enabled
<cjwatson> so, I mean, if the answer is that I just sit here mindlessly retrying I can do that
<cjwatson> but based on experience so far I won't be able to give a timeline with any degree of confidence
<jasoncwarner_> cjwatson: or perhaps we can bring in some reinforcements? get more eyes on it?
<cjwatson> well, feel free, although I'm not sure who else would be able to help
<cjwatson> what I'm trying to do is to get logs with 'set -x' inserted just before the bit in /bin/hw-detect that asks the hw-detect/select_modules question
<cjwatson> since that appears to be what's mysteriously bailing out
<jasoncwarner_> cjwatson: would it be quick to document the steps so someone else could give it a go? seb128 would you be able to take a look if that were the case? and perhaps we can grab ev and maybe pitti if they can spare a few minutes?
<cjwatson> I just documented the steps above :-)
<cjwatson> oh, and run with 'ubiquity -d' as well
<jasoncwarner_> cjwatson: always one step ahead ;)
<cjwatson> I think it's kind of misdirected effort TBH, but well
<seb128> cjwatson, it seems like the easiest way would be to get a package hacked to get whatever info we need and got it on an iso for the jenksys setup to run?
<jasoncwarner_> cjwatson: why so? I'm generally uneasy about something that you can only sometimes reproduce.
<cjwatson> it's not a failure that's showing up on errors.u.c, or one I can find any other reports of from actual people
<cjwatson> so, sure, it's a bug and we should definitely fix it to clear our automatic reports, but I feel OMG-fix-now importance for it is overinflated
<cjwatson> and I definitely feel any more than two people on it is distracting attention from more important things that are actually affecting humans
<cjwatson> 
<cjwatson> (grr)
<jasoncwarner_> cjwatson: though, it is breaking out builds right now as well, which is bad for the daily quality stuff, though, I do agree that if we put too many people on it, that takes away from other things (the careful balance ;) )
<cjwatson> it's not breaking our builds, it's breaking our jenkins tests, surely
<cjwatson> not really the same
<jasoncwarner_> cjwatson: ack on the mispeak
<jasoncwarner_> cjwatson: do you suspect it might be tooling (aka the jenkins tests? )
<cjwatson> it can't be solely that because I did manage to reproduce it albeit rarely
<jasoncwarner_> (asking b/c you mention it isn't on errors etc)
<jasoncwarner_> cjwatson: hmmm...what is the issue exactly anyway (probably should have asked that earlier ;) )
<cjwatson> https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-amd64_default/79/
<cjwatson> bug 1023036
<ubottu> Launchpad bug 1023036 in ubiquity (Ubuntu Quantal) "Error on /usr/share/ubiquity/plugininstall.py", line 1687, affecting desktop images (preseeded install)" [Critical,Triaged] https://launchpad.net/bugs/1023036
<cjwatson> ah, well, I can find one other report of it from a linux mint install in 2010 with a bunch of other errors before it
<cjwatson> unlikely to be the same thing ...
<jamespage> doko, I've raised MP's for both icedtea-web and openjdk-7 to delete/recreate the alternatives with a higher priority that openjdk-6; and to switch the Dependencies for icedtea-web to openjdk-7 where appropriate.
<jamespage> would appreciate your review before I upload
<jasoncwarner_> cjwatson: I guess its puzzling (or troubling might be a better word for it) that only 2/8 manual tests have produced it, but it seems the auto tests can reproduce it quite regularly?
<cjwatson> somewhat regularly; it's not consistent even in autotests
<cjwatson> would only be a small change in the probability of some race or other to produce such a result, I gues
<cjwatson> s
<jasoncwarner_> cjwatson: ok, so aside from adding more people looking at it, is there anything we can do for you at the moment?
<jasoncwarner_> would you like one minion or so to try and reproduce with you?  ;)
<cjwatson> I don't have any suggestions at the moment
<cjwatson> I wish I did
<seb128> cjwatson, what about what I said? if we get a package of an hacked ubiquity with logs details that could be useful and get it on an iso to throw to the jenkis?
<cjwatson> seb128: that's a fair bit of work in itself, and it's not entirely clear to me that it will be useful because I don't know whether the logging I can think of so far will be sufficient
<cjwatson> it's certainly a fallback measure, but I would prefer to continue manual reproduction attempts first
<cjwatson> if we were going to do that I'd probably just upload extra debugging to quantal rather than bothering with building a separate iso :)
<seb128> cjwatson, ok, is there anything special to do during the install, like is that specific to some options selected?
<cjwatson> 10:50 <cjwatson> what I'm trying to do is to get logs with 'set -x' inserted just before the bit in /bin/hw-detect that asks the hw-detect/select_modules question
<cjwatson> 10:51 <cjwatson> oh, and run with 'ubiquity -d' as well
<cjwatson> the two times I reproduced it it was with all default options
<seb128> cjwatson, right, I read that, I was just wondering if doing a standard full disk install with autologin is good
<seb128> ok
<seb128> I will try to fire a few vm installs and see if I can get it
<cjwatson> ta, won't hurt
<cjwatson> (that's what I've been doing since we started this conversation, too)
<cjwatson> seb128,jasoncwarner_: well, I've uploaded a ubiquity version to quantal-proposed that adds a tiny bit more debugging, which will hopefully help
<cjwatson> maybe
<seb128> cjwatson, ok, I'm just done syncing isos, I will get that one in my vm and start test installs
<seb128> cjwatson, thanks
<cjwatson> I'll push through an updated CD build once that's all built and copied to quantal and published
<cjwatson> IIRC jenkins automatically notices new image builds
<seb128> it seems to do yes
<seb128> it picked up the .1 isos yesterday
<tvoss> doko, ping
<tvoss> seb128, ping
<seb128> tvoss, hey
<seb128> tvoss, it's about bug #1006860? do you know if that patch got forwarded upstream?
<ubottu> Launchpad bug 1006860 in gdb (Ubuntu) "gdb crashes when loading core files (in is_ctor_or_dtor)" [High,Confirmed] https://launchpad.net/bugs/1006860
<seb128> cjwatson, there is something weird with that ubiquity update, it doesn't start for me (I downloaded ubiquity ubiquity-ubuntu-artwork ubiquity-frontend-gtk and did dpkg -i those)
<cjwatson> seb128: ENOTENOUGHDATA
<tvoss> seb128, no, I do not know. There was a comment on the bug saying that the ubuntu-reviewers team has been subscribed
<cjwatson> seb128: Anyway I wasn't suggesting that you install those; it would be much quicker to edit /bin/hw-detect by hand ...
<seb128> cjwatson, right, well I wanted to try those, will do that now
<seb128> $ ubiquity -d
<seb128> < 3 seconds wait>
<seb128> $
<cjwatson> /var/log/syslog /var/log/installer/debug
<seb128> not sure what datas would be useful
<seb128> cjwatson, http://pastebin.ubuntu.com/1086028/ syslog
<seb128> cjwatson, http://pastebin.ubuntu.com/1086029/ debug
<cjwatson> No sign of an attempt to start ubiquity 2.11.11 there
<seb128> hum
<cjwatson> I think the debconf db is in some kind of broken state.  Try from a fresh boot
<cjwatson> In general running ubiquity multiple times without rebooting is not particularly well supported
<cjwatson> Don't try it unless you're attempting to fix that :)
<seb128> cjwatson, well sudo apt-get install ubiquity/quantal ... etc for the 3 binaries and it works again
<seb128> but anyway I will downgrade and just hack the file by hand for the set -x
<cjwatson> I'll worry about it if it happens to a fresh ISO built with that version
<seb128> ok, fair enough, I prefered to mention it in case
<cjwatson> Sure
<seb128> tvoss, right, usually patches should be sent upstream as well if possible
<tvoss> seb128, okay. So I reach out to the gdb guys, referencing the bug report and proposing the patch, right?
<seb128> tvoss, correct
<seb128> tvoss, thanks
<tvoss> seb128, np
<tvoss> seb128, hmmm, gdb points people back to the distribution
<seb128> tvoss, why? our version is patched?
<tvoss> seb128, that's the argument, right
<seb128> tvoss, ok, thanks, I was just trying to be good upstream citizen, I will check out with doko when he's online or sponsor the patch later if he doesn't reply (not sure how much he's around or if he's a debconf this week)
<tvoss> seb128, awesome, thanks. I will announce the patch together with a link to the bug report on gdb-patches, though
<seb128> tvoss, thanks
<mdeslaur> @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: mdeslaur, infinity
<larsduesing> Ohm...
<larsduesing> is in SRU queue, but doesn't show up in http://people.canonical.com/~ubuntu-archive/pending-sru.html
<larsduesing> https://bugs.launchpad.net/ubuntu/precise/+source/aiccu/+bug/1007408
<ubottu> Launchpad bug 1007408 in aiccu (Ubuntu Precise) "aiccu.conf does not need server directive, while upstart script wants it" [High,In progress]
<seb128> larsduesing, https://launchpad.net/ubuntu/precise/+queue?queue_state=1
<seb128> larsduesing, the sru page only shows accepted SRUs
<larsduesing> oh, ok..
<seb128> larsduesing, the one you mention is waiting for review to be accepted
<larsduesing> yes... I see...
<larsduesing> thanks...
<hallyn> pitti: mterry did ask cjwatson why libtiff-dev was on 4 instead of 5, I forget what the answer was
<hallyn> pitti: are you saying all of the changes we've been making for libtiff4-dev->libtiff5-dev are wrong, or cups is special?
<cjwatson> If I got that question I didn't understand it
<cjwatson> If we're switching to libtiff5-dev I tend to think we probably ought to switch the Provides
<hallyn> cjwatson: two days ago you added 'Provides: libtiff-dev' to tiff3 right?  perhaps i misunderstood
<apw> do we not expect update-manager -d to allow upgrades yet ?
<hallyn> pitti: oh, i see.  the ones which were 'libtiff-dev' should not be changed.
<Laney> Well, they will be changed if you switch the provides.
<cjwatson> hallyn: I didn't do anything
<cjwatson> hallyn: All I did was sync both tiff and tiff3 directly from Debian; I made no Ubuntu-specific changes whatsoever
<cjwatson> hallyn: tiff3 previously didn't exist; syncing it took over the libtiff4-dev binary package (and others) from what was previously built by the tiff source package
<cjwatson> hallyn: So as far as the Provides goes, it was status quo
<cjwatson> Changing libtiff-dev to libtiff5-dev, if anyone's been doing that, is certainly incorrect
<hallyn> cjwatson: i see.  thanks
<cjwatson> Changing libtiff4-dev to libtiff5-dev is merely arguable; it's probably better to make that libtiff-dev and switch the default
<hallyn> cjwatson: i guess the nbs reports (which have since been removed) made me think that switching to libtiff5-dev was more urgent
<hallyn> makes sense then, thanks
<cjwatson> Those were only ever temporary; I'm sorry I didn't warn you, but I didn't expect the timing to be such that they'd show up on NBS at all
<mvo> apw: generally yes
<apw> mvo, didn't work for me, had to do it by hand
<pitti> hallyn: "no change for libtiff-dev"> right
<seb128> cjwatson, ubiquity refuses to bug for me as well, 5 installs, no error :-(
<jdstrand> jamespage: bug #1009579 ACK'd
<ubottu> Launchpad bug 1009579 in tomcat7 (Ubuntu) "[MIR] tomcat7 (replaces tomcat6)" [High,Fix committed] https://launchpad.net/bugs/1009579
<jdstrand> jamespage: do not my comments int he bug though :)
<jdstrand> err
<jdstrand> jamespage: do note my comments in the bug though
<jamespage> jdstrand, thanks for the ack; I will feed back the delta to Debian (I'm the maintainer of that package anyway)
 * jdstrand nods
<jamespage> cjwatson, please can you dig me out of my tomcat-server seed change hole ^^
<jdstrand> I can do that
<jamespage> jdstrand, yes please
<jdstrand> jamespage: you need an AA to promote jakarata-taglibs-standard?
<cjwatson> And tomcat7
<jamespage> jdstrand, both packages I think
<mvo> apw: oohhh, the default is to do only lts -> lts at this point, need to look how to fix that via -d
<jdstrand> cjwatson: I'm on it
<apw> mvo, ahh that'd expalin a few things ...
<jdstrand> jamespage: so, does this mean I can demote tomcat6?
<jamespage> jdstrand, almost - I just need to complete the transition for packages which use libservlet2.5-java to libservlet3.0-java which should free it up
<herton> @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: herton, mdeslaur, infinity
<jamespage> its packaging only so should not take to long
<jamespage> (i.e. I will have it done this week)
<jdstrand> jamespage: is there a bug filed on it?
<jamespage> jdstrand, not yet
 * jamespage add its to the list for this week
<jdstrand> I'll file one real quick
<jamespage> ah - thanks
<ScottK> Is the apport retracer running?  https://bugs.launchpad.net/ubuntu/+bugs?field.tag=need-i386-retrace&orderby=-id&start=0 has shown the same 16 bugs for at least the last 12 hours.
<dobey> for multiarch packages, does the -dev need to Pre-Depends on multiarch-support as well as the lib package?
<seb128> ScottK, shrug, log is "2012-07-03 08:18 i386.txt"
<seb128> ScottK, so I guess it's down for a week
<seb128> pitti, ^ should I just remove the lock and see how it goes? there is no obvious error in the log
<jdstrand> jamespage: fyi, bug #1023405. I assigned it to you but didn't milestone it or anything
<ubottu> Launchpad bug 1023405 in tomcat6 (Ubuntu) "please demote tomcat6 source and binaries to universe" [High,Triaged] https://launchpad.net/bugs/1023405
<seb128> ScottK, thanks for pointing it
<jamespage> jdstrand, thanks
<pitti> seb128: uh, sure; I thought I restarted it yesterday or so
<pitti> seb128: if it's something permanent, it'll just fail again and then we can investigate
<seb128> pitti, hum, that log is from 2012-07-03, i.e over a week untouched
<seb128> pitti, if you restarted it yesterday do I overlook something?
<pitti> seb128: apparently I just misremember then
<seb128> pitti, ok, let me try to rm it
<pitti> seb128: it looks like it just hung in the middle of retracing
<mterry> Is there a part of dh_python3 or dh_python2 that mangles the shebang line at the top of scripts dropped in /usr/bin?
<pitti> seb128: ah, the process is still running
<pitti> seb128: I'll kill it
<seb128> pitti, doh, I rm-ed the log by error
<seb128> pitti, well it was only a log
<seb128> pitti, thanks
<pitti> seb128: ah, now I know -- I looked yesterday, saw the lock, checked ps, and saw that it was running
<pitti> but I didn't look at the date
<seb128> pitti, ev: does it affect errors.ubuntu.com stats in any way where a retracer is down for a week like that?
<seb128> pitti, ev: if it does we should probably make sure we notice earlier when a retracer is stucked
<pitti> seb128: no, errors.u.c. has its own set of retracers
<seb128> ok, good
<seb128> I hope they don't have similar issues ;-)
<dobey> mterry: python3 setup.py install should change #!/usr/bin/python to be #!/usr/bin/python3 i think
<dobey> mterry: but if you have "#!/usr/bin/env python" that breaks
<mterry> dobey, I have env python3
<ScottK> mterry: For dh_python3 in quantal as of yesterday.  I don't think anyone's merged python-defaults, so not yet.
<mterry> And setup.py seems to be called with python3
<mterry> ScottK, sorry, I don't follow
<ScottK> If "#!/usr/bin/env python" is pointing to a python3 version, that's not right.
<ScottK> The shebang rewriting is a new feature in dh_python2/3.
<seb128> mterry, see changelog in http://packages.qa.debian.org/p/python-defaults/news/20120630T185419Z.html
<ScottK> I sync'ed python3-defaults ~yesterday, so that's in quantal.
<seb128> "- rewrite shebangs by default (disable via --no-shebang-rewrite),
<seb128>        examples:
<seb128>         + "/usr/bin/env python*" â "/usr/bin/python*""
<ScottK> No one merged python-defaults yet (AFAIK), so I don't think dh_python2 does that.
<seb128> ScottK, makes sense, mterry's case is a python3 one
<ScottK> barry should do that merge though.
<mterry> seb128, ScottK: I'm looking at update-manager, which during a build got translated from python3 to python, thus breaking it
<seb128> ScottK, mterry: revelant upload is https://launchpad.net/ubuntu/+source/python3-defaults/3.2.3-1 for python3 then?
<ScottK> seb128: Yes.
<jdstrand> ScottK: just to be clear-- /usr/bin/python shouldn't ever be python3 (unless maybe all of the world is changed). Is that accurate?
<ScottK> jdstrand: Something like that.
<jdstrand> ok, that is what I thought
<ScottK> Or you're Arch, but they're just crazy.
<ScottK> mterry: Build log?
<jdstrand> heh, it is a good thing I ported ufw then ;)
<mterry> ScottK, https://launchpadlibrarian.net/109741274/buildlog_ubuntu-quantal-i386.update-manager_1%3A0.166_BUILDING.txt.gz
<dobey> anyone have an answer to my multiarch question?
<ScottK> dobey: No, it doesn't.
<ScottK> mterry: And the problem is that there's a shebang re-written to /usr/bin/python?  Where?
<mterry> ScottK, in /usr/bin/update-manager
<dobey> thanks
<mterry> ScottK, in the source, it is "#!/usr/bin/python3"
<mterry> but becomes "#! /usr/bin/python"
<ScottK> I agree that's unfortunate.
<mterry> I'm testing with  --no-shebang-rewrite now
<mterry> It looks like it's using python3 throughout, calling setup.py with python3 and all that
<ScottK> Agreed.
<mterry> ScottK, even with --no-shebang-rewrite, I still get the bug.  Do you know which code is responsible for the build log line "copying and adjusting update-manager -> build/scripts-3.2" ?
<ScottK> I'm looking into it now.
<cjwatson> gema: how long should it take jenkins to pick up the Ubuntu desktop 20120711.2 image build I did?
<gema> cjwatson: not much, let me check
<gema> cjwatson: are we talking quantal?
<cjwatson> Yeah
 * gema goes check
<cjwatson> I figured I'd ask after an hour
<gema> cjwatson: I am going to run the jobs manually, they don't seem to have started automatically
<cjwatson> Right, thanks
<gema> np, will keep you posted
<ScottK> mterry: If you can try a build locally with a modified dh_python3, what happens if you change python to python3 in the SHEBANG_RE ... line (32) of debpython/tools.py?
<mterry> ScottK, ok
<ScottK> That RE is unchanged between dh_python2 and dh_python3, so I'm suspicious.
<ScottK> Also there's a log message in the relevant function (fix_shebang), so using verbose might be helpful.
<mterry> ScottK, that changed the shebang line to "#!/usr/bin/python" (still python but now no space after the shebang?)
<ScottK> OK.  I'm still looking at it.
<ScottK> Did you build with --verbose and did that yield anymore clues?
<mterry> not yet, about to now
<mterry> ScottK, http://pastebin.ubuntu.com/1086226/
<mterry> ScottK, that is *without* the RE change
<ScottK> OK
<mterry> I'll make one with
<apw> are we aware of a collision between ifupdown and netbase on /etc/init.d/networking ?
<apw> (this is an upgrade P -> Q)
<mterry> ScottK, http://pastebin.ubuntu.com/1086239/ is *with* the RE change, if it illuminates anything
<mterry> Don't see the "replacing shebang" log line in either
<ev> seb128: we don't have great failure notification on the errors.ubuntu.com retracers just yet, but webops tends to notice them going away.
<ev> at some point soon I'll get them wired up to nagios
<Laney> bah, just got hit by bug #1019999 again
<ubottu> Launchpad bug 1019999 in moreutils (Ubuntu) "package moreutils 0.46 failed to install/upgrade: trying to overwrite '/usr/share/man/man1/errno.1.gz', which is also in package errno 1.3-0ubuntu1" [Undecided,New] https://launchpad.net/bugs/1019999
<Laney> remove errno? it seems subsumed.
<ScottK> mterry: I'm not sure now what's doing it.
<seb128> mterry, did you try to downgrade python3-defaults to see if that's coming from it?
<mterry> ScottK, it seems python3 and dh_python3 both have shebang mangling code?
<mterry> seb128, no, let me try that
<ScottK> dh_python3 is part of python3.
<apw> stgraber, hey .. i seem to have some fallout from the netbase/ifupdown breaks: stuff you did, seems to not be working right on upgrade ...
<ScottK> mterry: I have a minimal test case.  fix_shebang in tools.py is definitely wrong.
<mterry> ScottK, right.  But there seem to be two bits.  one in build_scripts.py and one in dh_python3
<mterry> ScottK, ok, well that's good then
<ScottK> But let's make sure we got the right thing.
<stgraber> apw: ah? test upgrades worked fine here, though I had one bug report of someone with a bad mirror (missing one of the two packages)
<apw> stgraber, i get this on upgrade direct from P to Q(today)
<apw> dpkg: error processing /var/cache/apt/archives/ifupdown_0.7.1ubuntu1_i386.deb (--unpack):
<apw>  trying to overwrite '/etc/init.d/networking', which is also in package netbase 5.0ubuntu1
<seb128> cjwatson, did you read the discussion between ScottK and mterry?
<seb128> --- 10/usr/lib/ubiquity/bin/ubiquity    2012-07-09 20:06:45.000000000 +0200
<seb128> +++ 11/usr/lib/ubiquity/bin/ubiquity    2012-07-11 12:54:45.000000000 +0200
<seb128> @@ -1,4 +1,4 @@
<seb128> -#!/usr/bin/python3
<seb128> +#! /usr/bin/python
<udevbot> Error: "@" is not a valid command.
<seb128> cjwatson, that's ubiquity 2.11.10 -> 2.11.11
<seb128> cjwatson, I'm pretty sure that's why the update was busted for me
<stgraber> apw: hmm, I guess ifupdown could use a Breaks statement... I just followed what Debian did (changing the version numbers to match), but just having Replaces: netbase (<< 4.00) seems wrong indeed
<seb128> ScottK, mterry: ^ btw
<mterry> hm
<stgraber> apw: can you file a bug against ifupdown?
<apw> stgraber, ack
<apw> stgraber, so does that mean i should be upgrading netcore first, or removing it
<stgraber> apw: you should be upgrading netbase first indeed, that'll make /etc/init.d/networking go away, then ifupdown can unpack and take that file over
<mterry> seb128, ScottK: Downgrading python-defaults to 3.2.3-0ubuntu1 didn't help
<cjwatson> seb128: oh, hah, thanks
<seb128> cjwatson, yw
<cjwatson> gema: ^- so that jenkins test will not be very useful - sigh
<apw> stgraber, bug #1023437
<ubottu> Launchpad bug 1023437 in ifupdown (Ubuntu) "ifupdown conflicts with netcore both of which own /etc/init.d/networking" [Undecided,New] https://launchpad.net/bugs/1023437
<gema> cjwatson: sorry!
<stgraber> apw: netbase :) but thanks for the report, will look at it once I'm dong fighting with iscsi and meetings :)
<cjwatson> gema: not your fault :)
<ScottK> mterry: OK.  Then it's not the new rewriting feature.
<gema> cjwatson: let me know whenever you want another run, the one ongoing will finish anyway
<ScottK> I suspect it's the python3 distutils one.
<apw> stgraber, fixed :)  if i try and install netbase it says it cant cause of the breaks
<cjwatson> I assume there's no point in me debugging this from the ubiquity point of view?
<ScottK> mterry: clearly debhelper thinks this is a python package and I think it's running the wrong distutils.  Something needs overriding.
<mterry> ScottK, is there a known change in that code recently, that I can downgrade?
<ScottK> that was the only one I knew of.
<stgraber> apw: fun ;) can you try "apt-get install netbase ifupdown"? not sure if that'd be enough to give a hint to apt about the required ordering.
<seb128> cjwatson, mterry ran into it with update-manager
<seb128> cjwatson, I just though of ubiquity after, so no, I doubt ubiquity debugging is needed
<mterry> seb128, well, technically cjwatson ran into it with update-manager.  He uploaded that one too.  ;)
<seb128> cjwatson, it's likely to affect any package using python3
<mterry> seb128, maybe if we downgrade cjwatson?
<seb128> mterry, downgrade what source,binary?
<stgraber> apw: I'm also quite surprised that this didn't show up in any of the automated upgrade tests or in my own upgrade tests, always fun to have bug depend on apt ordering (though this one at least is pretty obvious)
<mterry> :)
<apw> stgraber, nope the same.  if i am reading the errors right here, ifupdown _has_ to be upgraded first cause the new netcore breaks it, but ifupdown can't install cause netcore won't upgrade
<apw> stgraber, ie it tries to update ifupdown first on its own and that fails
<stgraber> apw: should be the other way around, ifupdown is now shipping a file that used to be in netbase, so netbase should unpack without configuring, then ifupdown should install, then netbase should configure
<apw> stgraber, i guess i need to remove one or other, upgrade the other and reinstall it
<cjwatson> mterry: update-manager?  Bah, I missed that
<cjwatson> Has anyone looked at whether we'll need to scan the archive for this bug
<mterry> cjwatson, it only is visible if you install the built binaries
<cjwatson> ?
<stgraber> apw: can't you downgrade to the precise versions of them? hopefully this bug will be fixed in a few hours
<apw> stgraber, hmm, if netbase breaks ifupdown < 0.7 then it has to update ifupdown to >= 0.7 before it can install netbase ... right ?
<cjwatson> apw: Before it can configure netbase
<seb128> cjwatson, not yet, still trying to figure what update created the issue
<cjwatson> Breaks allows unpacking the new netbase first, but not configuring it
<seb128> cjwatson, I guess once we have it we need to figure what python3 packages got rebuilt
<apw> stgraber, i can happily leave the machine as it is until its sorted
<stgraber> apw: I can probably upload you a new ifupdown in a PPA based on what "should" be the fix, so if you can then test that, it'd save me some time trying to replicate the failure and testing the fix
<apw> stgraber, sure the machine is bust as it is :)
<ScottK> mterry: What happens if you override override_dh_buildsystems: to an empty value?
<apw> stgraber, poke me when you get it done, no huge rush
<mterry> ScottK, no help
<ScottK> mterry: What's the log look like for that?
<ScottK> (verbose)
<stgraber> apw: uploaded to ppa:stgraber/foundation-build, add that PPA and test the upgrade again once it's done building. If that works I'll push to the archive.
<apw> stgraber, ack
<mterry> ScottK, http://pastebin.ubuntu.com/1086279/
<mterry> ScottK, it should be easy enough to reproduce yourself.  apt-get source update-manager, then a debuild
<mterry> ScottK, (I'm still looking, I'm just saying, for faster feedback)
<ScottK> Sure.
<ScottK> I'm trying to get some $WORK done here too though.
<ScottK> BTW, that did make the log a lot better.  It's no longer trying to use python-support, for example.
<ScottK> So that's a good change, regardless.
<ScottK> Oh, nevermind.
<ScottK> I can't read.
<apw> stgraber, that version you uploaded is older than the archive it seems
<mterry> In the logs, I see "py3versions: Command not found"
<mterry> And then it installs files in 2.7 locations....
<stgraber> apw: indeed...
<ScottK> mterry: I had it a bit wrong.  It's override_dh_buildsystem:
<ScottK> That yields some interesting errors.
<mterry> ScottK, ah ok
<stgraber> apw: it'd help if I used the quantal source instead of the precise source :)
<Laney> dh_buildsystem is a thing?
<cjwatson> It's new to me ...
<Laney> I thought it was dh $@ --buildsystem=â¦
<cjwatson> AOL
<ScottK> Laney: That works too.
<ScottK> I just wasn't sure if that'd work to unset it.
<ScottK> Debhepler is picking python distutils (not python3 distutils) with it's buildsystem selection.
<ScottK> auto_build, auto_clean, and auto_install are too.
<ScottK> However, fixing all that, doesn't fix the shebang problem.
<BenC> Today is the day powerpc becomes top dog on the ftbfs listâ¦fear powerpc
<Laney> I don't see a python3 thing in /usr/share/perl5/Debian/Debhelper/Buildsystem/
<Laney> BenC: !!!
<Laney> I saw your ghc fix. Can it be?
<Laney> (did Erik confirm it?)
<BenC> Laney: erikd says it didn't work on his G5, but I have a feeling he is hitting another bugâ¦all my tests worked (and the G5 buildd's seem to like it)
<tsdgeos> didrocks: can i make more noise about my libopenjpeg MIR?
<didrocks> tsdgeos: talk to doko or jdstrand about it? I'm not involved at all into that MIR and don't really have the time to deal with it, sorry
<didrocks> look at who is "assigned to"
<tsdgeos> didrocks: oh, i thought you were, sorry
<ScottK> mterry: It's the python3.2 distutils/command/build_scripts.py  that's triggering.  No idea why now.
<tsdgeos> jdstrand: ping, can i make more noise about the openjepg MIR?
<mterry> ScottK, hmm, doing this locally is picking up my python2 installation, so I'm getting a different log than on the buildd, where only python3 is installed
 * mterry goes into a chroot
<ScottK> mterry: "copying and adjusting update-manager" is where this shows up in the log.
<mterry> yup
<mterry> locally, that's being run by python2.7 build_scripts.py.  but on the buildd, it's python3.2's  (which still gets it wrong)
<ScottK> mterry: You'll need to comment out the calls to dh_auto_build/install (not needed anyway, AFAICT) and add this:
<ScottK> copying and adjusting update-manager
<ScottK> Oops
<ScottK> override_dh_auto_clean:
<ScottK>         python3 setup.py clean -a
<ScottK> Then you'll get a complete python3 build (that's in addition to the buildsystem change)
<ScottK> It'll stil be busted though.
<mterry> oh  :)
<ScottK> It at least builds all the way through with only python3 though.
<ScottK> My suspicions are shifting back to dh_python3 though.
<ScottK> The update-manager in build/scripts-3.2 has the right shebang.
<stgraber> apw: wow, looks like I was looking at an old debian/control all along, looking at what's actually in quantal, I'm not completely sure what's wrong. (ifupdown properly breaks/replaces the old netbase)
<mterry> ScottK, ah good
<apw> stgraber, anything else i can get you from the machine, or access to it or something
<mterry> I see that too.  And working in a chroot, I get only python3 as well
<ScottK> And, in fact, right before dh_python3 runs, it's still python3.
<ScottK> And right after it runs, it's not.
<stgraber> apw: reproduced here
<apw> stgraber, this is an oddy as the error says "which is also in package netbase 5.0ubuntu1" but if i look at the .deb for that its not actually in there ...
<stgraber> apw: yeah, conffiles are weird like that
<seb128> ScottK, mterry: do you have a bug for the issue? some users are abusing bug #1013276 for the problems with the recent update-manager rebuild
<ubottu> Launchpad bug 1013276 in update-manager (Ubuntu) "update-manager crashed with ImportError in __main__: No module named UpdateManager.UpdateManager" [High,Confirmed] https://launchpad.net/bugs/1013276
<ScottK> I don't.
<mterry> seb128, no not yet.  didn't know which component to file it against yet  :)
<stgraber> apw: I found an old e-mail from cjwatson to debian-devel covering what had to be done for ssh (similar moving conffiles around between packages). Though as we're moving to an upstart job, it's really quite unlikely that there's anything for the user to keep in there, so I might just end up checking the md5sum in netbase's new preinst, if it matches remove it, if it doesn't, move it to .dpkg-old
<cjwatson> stgraber: the stuff in ssh was a workaround for a dpkg bug long since fixed
<cjwatson> nowadays Replaces is supposed to be enough
<cjwatson> if it's not I think we should be questioning whether something in dpkg has regressed
<mterry> OK, it is fix_shebang
<mterry> as you suspected
<stgraber> cjwatson: right, just noticed that it's supposed to be fixed in dpkg...
<stgraber> cjwatson: I'm not crazy in thinking that versioned (<< new-version-without-the-conffile) Breaks + Replaces should take care of it fine?
<stgraber> cjwatson: (anyway, can talk post-meeting)
<cjwatson> stgraber: I think that should; it's been a while since I attempted a conffile move
<cjwatson> stgraber: I vaguely recall noticing some other problem recently which suggested something was wonky in this area in dpkg, but unfortunately I don't remember the details
<stgraber> cjwatson: one trick is that the conffile is getting replaced by a symlink to /lib/init/upstart-job, not sure if that'd confuse dpkg somehow
<cjwatson> Certainly possible
<ScottK> mterry: Fixing the RE solves it.
<ScottK> I think it was a mix of using python/python3 in the build and this error.
<mterry> ScottK, yup, just reached that same conclusion
<ScottK> I'll fix python3-defaults
<ScottK> seb128 or mterry: Is there a bug number?
<mterry> ScottK, awesome.  Uh, not yet.  I can file one real quick
<mterry> ScottK, simple bug here: 1023474
<mterry> bug 1023474
<ubottu> Launchpad bug 1023474 in python-defaults (Ubuntu) "dh_python3 mangles shebangs to use Python 2" [Undecided,New] https://launchpad.net/bugs/1023474
<mterry> seb128, ^
<seb128> mterry, ScottK: bug #1022994
<ubottu> Launchpad bug 1022994 in update-manager (Ubuntu) "update-manager crashed with ImportError in __main__: No module named UpdateManager.UpdateManager" [Undecided,Confirmed] https://launchpad.net/bugs/1022994
<mterry> guh ok
<mterry> seb128, I thought you said that was the wrong bug
<ScottK> mterry: Should be python3-defaults anyway.
 * ScottK will use mterry's bug.
<seb128> mterry, no, that one has been opened yesterday
<seb128> mterry, the one I pointed was an older one
<seb128> *pointed earlier
<mterry> seb128, ok.  Well, if ScottK is using my bug, we can mark those as dups
<ScottK> Both update-manager and python3-defaults need fixing.
<seb128> mterry, right
<mterry> ScottK, true, u-m and ubiquity need re-builds
<ScottK> I suspect you'll find it's more than rebuilds.
<ScottK> You need to make sure debhelper isn't helping you use python instead of python3.
<seb128> ScottK, hum, what other sources need those special checks?
<cjwatson> Pretty sure those two will just be rebuilds.  I was fairly careful.
<mterry> ScottK, well, for update-manager at least, when it builds, it only has python3 installed
<ScottK> OK.
<ScottK> cjwatson: It may just be an artifact of not totally miminal chroots.
<ScottK> uploaded in any case.
<seb128> ScottK, what do you mean "artifact of not totally miminal chroots", building on a non minimal chroot shouldn't result in a buggy package for sure?
<ScottK> If the debhelper auto buildsystem thing detects python distutils it'll use it.
<ScottK> (not phython3)
<ScottK> So if you don't override buildsystem, it'll build differently in python is installed.
<seb128> hum
<stgraber> cjwatson: one side effect of /etc/init.d/networking being a symlink is that it's not listed as a conffile in ifupdown...
<seb128> that doesn't seem something reliable
<ScottK> Agreed.
<ScottK> Unfortunately no one has fixed the autobuild system thing to know about python3.
<ScottK> There's a GSoC project to deal with building for all the python versions, but it's not done yet.
<ScottK> (I think it's GSoC)
<jdstrand> tsdgeos: it is on my todo list, I've replied in the bug
<tsdgeos> jdstrand: not sure if your comment is "good" or "bad"
<jdstrand> it is a statement of fact. there is a security history. a full review is pending, but likely not to happen super soon
<tsdgeos> ok
<mterry> ScottK, hah, funny that I got python-defaults vs python3-defaults wrong for this bug
<tsdgeos> i understnad that''s a different way of saying no :d
<ScottK> I fixed it.
<mterry> yar
<jdstrand> tsdgeos: it is not a NAK. as for the review, like I said, it is on my todo, just not at the top
<tsdgeos> jdstrand: sure, i understand
 * jdstrand nods
<ScottK> FWIW, fixed in Debian too.
<ScottK> mterry: My upload made the last publisher run, so you should be good to upload in ~20 minutes.
<mterry> ScottK, awesome.  thanks for helping with this!
<mdeslaur> @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: herton, infinity
<dobey> does multiarch not work with cmake? i'm trying to set up a package for multiarch that uses cmake, but the libs still just go to /usr/lib in debian/tmp/
<ScottK> dobey: phonon has been multiarched.  I think it uses cmake.  You might see what was done there.
<dobey> ScottK: ok, thanks. i'll check it out
<Laney> you'll probably have to prod some variables
<dobey> yeah, looks like it adds -DLIB_SUFFIX=/$(DEB_HOST_MULTIARCH) to the cmake command
<Laney> I don't think it's standard though, so you'll have to check out the cmake files in your project
<dobey> ah, indeed. :-/
<bdmurray> mterry: could you have a look at bug 1019650?
<ubottu> Launchpad bug 1019650 in update-manager (Ubuntu) "update-manager crashed with IOError in getListFromFile(): [Errno 2] No such file or directory: '/usr/share/update-manager/removal_blacklist.cfg'" [High,Triaged] https://launchpad.net/bugs/1019650
<ScottK> Retracer is doing stuff now.  Thanks seb128 and pitti.
<seb128> ScottK, thanks for pointing the issue, it was hanging for a week but nothing check for hanging processes, we just get emails when it hits an error
<ScottK> Sounds suboptimal.
<seb128> yes
<mterry> bdmurray, I believe that is already fixed.  let me comment in bug
<bdmurray> mterry: I ran into that bug with the lastest version of update-manager 0.166
<mterry> bdmurray, ...  OK...  But that code doesn't even exist anymore
<mterry> :(
<mterry> bdmurray, actually, I'm suspicious.  Since 0.166 doesn't even run
<bdmurray> mterry: okay it looks to me like it was an issue with update-manager being updated and the version number not matching what had been running
<bdmurray> mterry: there is an apport bug about that
<stgraber> cjwatson: apparently hardcoding /etc/init.d/networking in ifupdown.conffiles makes dpkg DTRT. Upgrading from precise to quantal with a clean /etc/init.d/networking leads to it being a symlink to /lib/init/upstart-job. Doing the same with an updated file triggers the conffile prompt, if the user chooses to keep their changes, then /etc/init.d/networking is kept as a regular file.
<stgraber> cjwatson: I was a bit worried dpkg would somehow mangle /lib/init/upstart-job in that case but apparently it doesn't. Can you see anything else that could go wrong with this approach?
<primepie> I installed gnu lib readline  ... and I noticed it got installed in /usr/lib/x86_64-linux-gnu  .. I wrote a simple program that calls using_history() and tried to compile it with -lreadline -lhistory but it still says undefined reference to `using_history'
<jtaylor> primepie: likely an ordering issue, libraries must be after objects needing them
<jtaylor> primepie: e.g. gcc object.c -lreadline, not gcc -lreadline object.c
<primepie> jtaylor: didn't make a different
<primepie> difference
<primepie> jtaylor: http://pastebin.com/LFKqkFQM this is the program
<primepie> it compiles on ubuntu 10 but not on 12
<jtaylor> then its an ordering issue
<jtaylor> whats the commandline your are using to compile?
<primepie> gcc test.c -lreadline -o test
<jtaylor> I can'T reproduce it
<primepie> jtaylor: nm .. it is.. the Makefile in the 2 machines are different
<primepie> my fault
<mterry> pitti, did you mean to overwrite the tiff5 change in cups, or shall I put that back?
<mterry> (assuming you were the one that sync'd it)
<Laney> 11/07 09:49:48 <pitti> hallyn: FYI, I reverted your libtiff5-dev cups change; that's not the right way; if we want to switch to libtiff5 by  default, the "Provides: libtiff-dev" needs to be moved from 4 to 5 instead
<mterry> guh, hmm
<Laney> It does seem like that's what you're trying to achieve (changing the default)
<Laney> so you should probably just do that
<mterry> yeah, but I figured the set of changes was small enough to just do it manually, since a lot of them specifically mentioned tiff4 anyway
<mterry> we were only targetting main
<mterry> that way we could avoid a delta on the tiff packages (albeit adopting a delta on some others0
<Laney> Pretty sure Debian will switch after wheezy anyway
<mterry> they will
<mterry> guh, so close, only a few packages left to do.  but I'll defer to pitti here
 * mterry looks into moving the Provides
<hallyn> mterry: (mind you the revert was demotivating but) for the sake of what we're doing, is it worth moving the provides ourselves?
<hallyn> or are we mainly just wanting to make sure that anything explicitly depending on libtiff4-dev gets fixed?
<hallyn> i suppose changing it now will help catch any potential errors that would otherwise happen whenever tiff3 was removed
<mterry> hallyn, my goal was to be able to move to only having the stable version of tiff in main
<Laney> I just pushed a transition tracker file
<mterry> hallyn, so if pitti is requesting that we not patch libtiff-dev -> libtiff5-dev, we can move the Provides and still fix the ones that specifically mention libtiff4-dev (probably to just libtiff-dev now, instead of libtiff5-dev)
<hallyn> mterry: i see
<Laney> you should get to see how a proper transition would look next time it generates
<hallyn> mterry: yup
 * hallyn doesn't now what a transition tracker file is
<mterry> Laney, thanks.  I still don't know the magic behind those transition reports
<hallyn> is it like a little robot-bug that gets inserted through your stomach?
<Laney> https://bazaar.launchpad.net/~ubuntu-transition-trackers/+junk/transition-tracker/view/head:/ubuntu/monitor/tiff.ben
<hallyn> cool
<scientes> how do i restart udev?
<scientes> after i trashed my /dev
<cjwatson> stgraber: cool, that sounds plausible enough then ...
<mterry> Laney, can you add http://pastebin.ubuntu.com/1086827/ to the transition tracker for me?
<Laney> oui
<mterry> danke!
<Laney> did you mean to miss armhf out?
<mterry> Laney, oh hah, no.  I still forget about armhf
<Laney> tsk tsk
<Laney> mterry: there you go, should be there next run
<mterry> Laney, thanks!
<herton> @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: infinity
<stgraber> apw: uploaded a new ifupdown to the archive, it looks like it's working fine here but I'm not particularly happy with the hack. Let me know if it works/doesn't for you.
<apw> stgraber, thanks will do
<apw> stgraber, appreciate your efforts fixing it
<stgraber> apw: np. it's the kind of thing I prefer to fix now than see show up on some QA report a week before release ;)
<apw> stgraber, now there is that for sure
<stgraber> stokachu: could you link the merge proposal with bug 977947? it's not trivial to find it from that bug :)
<ubottu> Launchpad bug 977947 in libbonobo (Ubuntu Quantal) "Please transition libbonobo to multi-arch" [Medium,Triaged] https://launchpad.net/bugs/977947
<infinity> stgraber: Oh, I didn't even stop to think that it's a symlink in Ubuntu.
<infinity> stgraber: That kinda explains the bug entirely.
<stgraber> infinity: yeah, apparently that confuses dpkg a bit ;)
<infinity> stgraber: That *might* be a dpkg bug.  Maybe.
<infinity> stgraber: But it's a pretty odd corner case.
<stgraber> I'm just wondering there won't be a weird side effect of my fix I didn't think of, was kind of scared of a side effect like dpkg writing to /lib/init/upstart-job, putting the old networking script content in there or something (though testing showed that it seems safe)
<stgraber> s/wondering/hoping/
<infinity> There could be weird side effects, but not that level of weird.
<stgraber> infinity: opened a task against dpkg so we don't loose track of it
<infinity> stgraber: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421344
<ubottu> Debian bug 421344 in dpkg "dpkg: does not gracefully handle symlink conffiles" [Normal,Open]
<infinity> stgraber: You may trip on this.
<infinity> stgraber: And if THAT bug has been accidentally fixed along the way, some mention of that would be nice. ;)
<infinity> stgraber: Though, I suspect that if your hack is working for you, the only reason is because it's also part of a Replaces file migration, which then skips some of the normal conffile handling.
<infinity> stgraber: *hand wavy too lazy to trace the code right now response*
<stgraber> infinity: sounds like http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=421346 is about implementing my "hack" automatically in debhelper (considering symlinks in /etc as being conffiles)
<ubottu> Debian bug 421346 in debhelper "debhelper: should automatically mark symlinks in /etc as conffiles" [Normal,Open]
<infinity> stgraber: Yes, but it's blocked by the dpkg bug.
<stgraber> but yeah, sounds like dpkg doesn't handle them terribly well at the moment, though I suppose I'm fine as long as we don't move /etc/init.d/networking to another symlink pointing somewhere else (which I'm certainly not planning to do :))
<apw> stgraber, hey, the new ubuntu2 version seems to let me continue the upgrade
<stgraber> apw: cool
<BenC> StevenK: Can you bump this for me, please: https://launchpad.net/ubuntu/+source/ghc/7.4.1-4ubuntu2/+build/3649402
<BenC> It's gone from 40 minutes to an hour
<BenC> err, 2 hours
<StevenK> BenC: Haha, needs more fixing? Now 6 minutes.
<BenC> The last fix worked partially, needed one more to make it perfect
<BenC> StevenK: thanks
 * BenC wishes for Build score powers
<unixpro1970> Where is linux-vdso-so located?
<RAOF> unixpro1970: It's not; it's a virtual shared object (which is what the âvâ stands for).
<unixpro1970> Then how can I generate it?
<RAOF> It's provided by the kernel
<unixpro1970> Or use it?
<unixpro1970> Thanks ROAF, must I use a command line parameter when compiling to make it work.
<RAOF> AFAIK it's an entirely transparent optimisation. If it *isn't* entirely transparent, it's only used in libc.
<unixpro1970> So is the solution include libc?
<geofft> http://www.trilithium.com/johan/2005/08/linux-gate/
<unixpro1970> to include
<unixpro1970> okay,thanks guys.
#ubuntu-devel 2012-07-12
<ScottK> pitti: Did the retracer die again?
<micahg> BenC:  you might want to chat with Laney about the potential for ghc 7.4.2 in quantal before rebuilding the world again
<BenC> micahg: I'm speaking with erikd about the fixes so far
<BenC> This last build is final for me
<micahg> BenC: I was referring to the no change rebuilds you uploaded (as any ghc update will require them to happen again)
<ScottK> Laney's not top uploader for Quantal yet, so I'm sure he wouldn't mind rebuilding the world a few times.
<BenC> micahg: Ah, well, it was only an ABI rebuild for ppc, but yeah, I'm trying to handle the buildX uploads gently
<micahg> well, queue seems to be empty anyways, I thought he had the fix for armel as well which would mean we could do a full rebuild across the board
<micahg> ah, it's being worked on elsewhere I see :)
<scientes> does -dev package multi-arch work in quantal?
<scientes> cause i want to do this type of stuff https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/FirefoxCrossCompile
<scientes> make my package support it
<RAOF> scientes: Yes, as long as your -dev package is consistent across architectures.
<scientes> but not in precise?
<scientes> i tried to install the build-deps and i couldn't even install libc6:armhf
<RAOF> Not all -dev packages are multiarchable.
<scientes> yeah, my package is multi-arch
<scientes> but i want it to be cross-buildable the multi-arch way
<scientes> https://wiki.linaro.org/Platform/DevPlatform/CrossCompile/FirefoxCrossCompile
<RAOF> Installing libc6:armhf will require you to have the ability to execute armhf code.
<scientes> only if you want to run it
<scientes> but besides that i have qemu-user-static
<scientes> just using it to link against with the cross-toolchain included in ubuntu is a perfectly reasonable use-case
<RAOF> No, the dpkg triggers will run armhf code.
<RAOF> ie: installing it will attempt to execute armhf code.
<RAOF> If you've got qemu-user-static that should work, though.
<scientes> oh, well i do have qemu-user-static installed
<scientes> its failing on tzdata:armhf not installable
<RAOF> I'm not sure why that's the case.
<RAOF> libc6 is certainly multiarch in Precise.
<RAOF> And I've tested libc6:amd64 + libc5:i386; there's no obvious reason why libc6:armhf would be different.
<RAOF> Except for arm being crack, of course :)
<scientes> libc5!
<scientes>  libc6:armhf : Depends: tzdata:armhf but it is not installable
<RAOF> Heh. libc6:amd64 + libc6:i386 :)
<scientes>  libc6:armel : Depends: tzdata:armel but it is not installable
<StevenK> But tzdata is arch all?
<scientes> exactly
<scientes> oh
<scientes> maybe I need [arch=i386,amd64,all]
<scientes> ?
<micahg> hrm, tzdata is marked multiarch foreign, at least in precise
<TheMuso> Same in quantal.
<micahg> this sounds familiar
<scientes> i can't test "cross-compiling" to i386 either, cause there is no seperate compiler
<scientes> but anyways, i guess i can fix it to work, instead of not working
<scientes> even though few care
<scientes> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613584
<ubottu> Debian bug 613584 in apt "apt-get not handling Multi-Arch: foreign, Arch: all packages correctly" [Important,Fixed]
<OdyX> pitti: thanks for the pyppd sync: letting uploads arrive "first" in Debian is very appreciated, really.!
<pitti> ScottK: yes, it did; restarted again, need to see what's upsetting gdb now
<pitti> OdyX: makes things easier and better for everyone :)
<ScottK> pitti: Thanks
<OdyX> pitti: ^5!
<pitti> :)
<OdyX> I should really put more time into making sure tkamppeter has the proper rights to do his foomatic-* uploads in Debian first; I'm yet to convince him.
<ScottK> pitti: Can you perhaps prioritize what gets retraced next?  1023231 may relate to newly released hardware and I'd like to let upstream know about it ASAP if it does.
<pitti> ScottK: there are only some 30 bugs to retrace, that ought to finish in half an hour or less
<pitti> but it seems the core dump in bug 1019781 makes gdb hang forever
<ubottu> Error: Launchpad bug 1019781 could not be found
<ScottK> pitti: ok.  It got through 6 of the i386 ones yesterday before it died again, so I wasn't optimistic.
 * pitti untags and restarts
<pitti> 07/12/12 04:32:04: retracing #1019781 (left in pool: 54)
<pitti> ok, 54
<ScottK> At least you've got a reliable test case now.
<pitti> untagged that bug and restarted; /me locally runs apport-retrace -S system -sv 1019781
<pitti> ah, won't work, i386
<pitti> anyway, I'll look into it
<StevenK> pitti: You'll have to blow the dust off your i386 chroot?
<pitti> StevenK: I don't have one; fortunately apport-retrace makes it quite a bit easier to retrace an i386 bug on amd64 :)
<pitti> ScottK: oh, it caught up on i386 now
<ScottK> Yeah.
<ScottK> Trying to make sense of the backtrace now.
<jussi> morning all
<jussi> was there a decision taken to not make alternate cd's anymore ?
<pitti> jussi: as soon as Ubiquity gets taught to handle LVM and encrypted partitions
<jussi> pitti: ahh, good, that woul have been my objection to dropping it :)
<dholbach> good morning
<pitti> bdmurray: would it still be possible to set up http://reports.qa.ubuntu.com/reports/bug-fixing/quantal-fixes-report.html ? I. e. can it scan the quantal-changes@ archives, or does it need to be subscribed from day 1?
<apw> i see gpg/ssh key timeout options have gone in quanta (are those from seahorse?), are they reenablable ?  security is going to be grumpy
<seb128> apw, bug #987167 ?
<ubottu> Launchpad bug 987167 in gnome-keyring (Ubuntu) "unable to set gpg key timeout" [Low,Confirmed] https://launchpad.net/bugs/987167
<mpt> ev, fixed examples of "[Invalid UTF-8]" include bug 837246 and bug 874194; open examples include bug 874755, bug 841821, and bug 823649.
<ubottu> Launchpad bug 837246 in Unity Foundations "User name shown as [Invalid UTF-8] in live session" [High,Fix released] https://launchpad.net/bugs/837246
<ubottu> Launchpad bug 874194 in indicator-session (Ubuntu Oneiric) "indicator-session shows name as "[Invalid UTF-8]" for some users" [High,Fix released] https://launchpad.net/bugs/874194
<ubottu> Launchpad bug 874755 in Ubuntu Translations "calendar "[Invalid UTF-8]" (encoding problem)" [High,Triaged] https://launchpad.net/bugs/874755
<ubottu> Launchpad bug 841821 in gnome-control-center (Ubuntu) "Color manager shows [invalid UTF-8]" [Low,Triaged] https://launchpad.net/bugs/841821
<ubottu> Launchpad bug 823649 in Ubuntu One Client "continuous "Invalid UTF-8" notifications" [Medium,Triaged] https://launchpad.net/bugs/823649
<ev> mpt: thanks! I'll have a look
<seb128> how do the copies from quantal-proposed to quantal happen?
<seb128> like unity in proposed seems ready to be copied
<seb128> will that happen automatically? or should we ask for the copy? or just do the copy?
<cjwatson> seb128: It's all manual right now.  What set of packages need to be moved?
<cjwatson> And is the set that's on pending-sru complete and coinstallable
<cjwatson> ?
<seb128> cjwatson, the set is "nux unity unity-2d unity-lens*"
<seb128> cjwatson, it's at the bottom of the pending-sru, it's supposed to be complete if we didn't overlook something
<seb128> cjwatson, what do you mean "coinstallable"?
<cjwatson> Installable at once
<seb128> yes
<cjwatson> Won't break upgrades, that kind of thing
<cjwatson> I have no easy way to verify because we don't have tools :)
<pitti> http://people.canonical.com/~ubuntu-archive/testing/quantal-proposed_probs.html should give some good hints, though
<seb128> ok, I was unsure how far the tool writing went so far
<pitti> that says unity is uninstallable
<pitti> which it isn't in quantal
<cjwatson> no, those are just NBS binaries
<cjwatson> check the version
<seb128> pitti, "unity 5.12-0ubuntu4 produces uninstallable binaries: "
<seb128> let me try in a vm to be sure
<pitti> ah, I see
 * seb128 fires virtualbox
<cjwatson> fires or fires up? :-)
<seb128> fires up :p
<cjwatson> English is such a wonderfully ambiguous language sometimes
<seb128> @english: yeah ;-)
<udevbot> Error: "english:" is not a valid command.
<seb128> cjwatson, pitti: ok, I booted yesterday's daily iso, enabled quantal-proposed, apt-get update && dist-upgrade goes well, everything is going to be upgraded, only libunity-core-5.0-5  is to be uninstalled
<seb128> which is normal, everything got transitioned to the new soname
<seb128> and the old lib doesn't work with the new unity
<seb128> cjwatson, can we get the set copied to quantal? ;-)
<pitti> seb128: sru-release -r quantal unity otherpkg ...
<cjwatson> In progress now
<cjwatson> done
<pitti> erk, /me notices a typo in --help
<pitti> "Copy to release pocket instead of -proposed"
<pitti> that should be -updates, fixing
<cjwatson> Er, no!
<cjwatson> Oh, sorry, yes, you're right
<didrocks> thanks cjwatson :)
<pitti> done
<cjwatson> (Sorry, my wife was talking to me at the same time, cognitive leakage)
<seb128> cjwatson, thanks
<pitti> cjwatson: no worries :)
<pitti> "Copy to release pocket instead of -updates", that's better
<seb128> cjwatson, btw I did half a dozen test installs yesterday I never hit the ubiquity bug :-(
<cjwatson> Makes two of us.  Let's see what jenkins says today, I guess
<seb128> yeah, once we get an iso ;-)
 * apw wonders if we are aware gvfs-mount -u has stopped working
<seb128> apw, not that I know about
 * apw files a bug
<seb128> is that quantal?
<seb128> what error do you get?
<apw> seb128, quantal yes: "Error finding enclosing mount: Containing mount does not exist"
<seb128> what do you try to unmount?
<apw> a usb stick
<seb128> can you umount it?
<seb128> or does that fail as well?
<apw> i can unmount it from nautilus
<seb128> hum, ok
<seb128> could be an udisks2 fallout..
 * apw is suspicious its /run/media/ fallout
<seb128> apw, how do you try to umount it? gvfs-mount -u /dev... or /mountpoint ?
<apw> seb128, -u mountpoint
<seb128> ok, that works on precise
<apw> yep it worked on this machine before updating too indeed, and still does on my other box ->
<seb128> I'm still on precise and I can't really test that in my vm, the usb stick mounts on the real box, not in the vm
<seb128> ok
<seb128> I guess it's a bug for pitti ;-)
<apw> seb128, pitti, bug #1023815
<ubottu> Launchpad bug 1023815 in gvfs (Ubuntu) "gvfs-mount -u <mountpoint> fails: Error finding enclosing mount: Containing mount does not exist " [Undecided,New] https://launchpad.net/bugs/1023815
<seb128> apw, thanks
<pitti> apw: thanks, will have a look at it
<seb128> pitti, danke
<pitti> seb128: FYI, the i386 retracer hung again this morning, I untagged the bad bug and it caught up now
<pitti> seb128: I can reproduce the gdb hang
<seb128> pitti, thanks, do you know what in the bug lead to the hang?
<seb128> oh, gdb bug, great...
<pitti> gdb is spinning with 100% CPU when calling it on the core dump
<pitti> it's not even doing the bt yet
<pitti> _llseek(10, 135168, [135168], SEEK_SET) = 0
<pitti> ad infinitum
<apw> are we aware of some quantal indicator menus having back colours ?
<seb128> apw, bug #1015488
<ubottu> Launchpad bug 1015488 in indicator-messages (Ubuntu Quantal) "Wrong theme of indicators menu" [Undecided,Incomplete] https://launchpad.net/bugs/1015488
 * apw idly wonders how seb128 keeps all these bug numbers in his head
<apw> (and thanks once again)
<seb128> apw, I don't but the firefox awesome bar is called "awesome" for a reason ;-)
<apw> heh that is awsome
<pitti> seb128, ScottK: FYI, bug 1023835
<ubottu> Launchpad bug 1023835 in gdb (Ubuntu) "gdb hangs eternally when opening with upowerd core file" [Undecided,New] https://launchpad.net/bugs/1023835
<seb128> pitti, thanks
<pitti> ev: ^ this might actually affect "your" retracers as well
<ev> pitti: ah, yikes
<apw> cjwatson or pitti, can you recall what consumes the modules.*map files that depmod makes?
<cjwatson> apw: used to be hotplug stuff; depmod(8) says they're "largely deprecated"
<cjwatson> though I wouldn't want to risk removing them without a thorough audit
<apw> cjwatson, well kmod no longer makes them
<apw> and htey have been off by default in debian since forever, as we carry a patch to turn them back on
 * apw removed them from his system and reboots, lets find out
<cjwatson> I suspect it's probably OK
<apw> well my fairly 'standard' machine boots fine without them
<apw> most annoying to have this wrinkle else i'd be happy to say lets follow debian and switch
 * apw will do some wider testing next week with his team
<pitti> apw: I'm not aware of anything that still uses them
<apw> no i can't find anything in udev using them which would be my primary expectation
<pitti> apw: there are now binary maps which greatly speed up dependency calculation, AFAIR
 * pitti needs to leave for some two hours, bbl
<apw> pitti, yeah i suspect its done a differnet way now
<pitti> apw: modules.dep.bin, presumably
<apw> pitti, yeah that one i presume
<apw> pitti, i assume hal used to use them
<apw> cjwatson, any suggestions as to how one might review this?
<cjwatson> Not sure really.  I note that modules.*map here have atimes of 26 June
<cjwatson> Which is a bit after their mtimes, but I think that corresponds to the time of my nightly backups shortly after they were created
<cjwatson> So that suggests to me that they're unused here at least
<cjwatson> (And in particular those atimes are considerably earlier than my last reboot)
<apw> cjwatson, my *map atimes files on precise are all the same as the mtimes
<apw> cjwatson, same on another box
<cjwatson> gema: No jenkins run with 20120712?
<cjwatson> (Ubuntu desktop)
<gema> cjwatson: babyface told me the images were late
<gema> cjwatson: we have a problem with jenkins, it does not start jobs automatically
<gema> cjwatson: if the images are ready I will start them manually
<gema> cjwatson: on their way
<cjwatson> Yeah, they are, finished about an hour and a half ago
<gema> cjwatson: ack, we will be starting things manually until we figure out why jenkins is not triggering the jobs
<gema> cjwatson: if you see any obvious misses, just let us know
<pitti> apw: not sure what hal would have done with them, but if so, it couldn't be important
<BenC> Any chance some one could process haskell-resourcet NEW for me, please?
<BenC> Lots of stuff dep-waits on that
<Laney> BenC: I advise you not to rebuild very much; 7.4.2 will be brought over soon.
<Laney> once Erik commits a version of your patch, in fact.
<BenC> Laney: I'm not rebuilding anything, just pushing the FTBFS queue
<Laney> well, that too
<Laney> it'll all have to be rebuilt anyway
<BenC> Well, this NEW will need to be processed sooner or later
<Laney> sure
<BenC> best now before you crush a rebuild of everything, so nothing waits on it :)
<BenC> Same for haskell-configurator
<cjwatson> BenC: Done
<cjwatson> (both)
<cjwatson> It's arguable which is best, since powerpc build time is a bit contended
<cjwatson> But I would have done it at some point anyway if I hadn't seen this conversation, so :)
<BenC> cjwatson: thanks
<dholbach> mterry, could you join us in #ubuntu-arb? :)
<Laney> someone else already did an uncoordinated rebuild bonanza anyway, so it probably doesn't matter that much
<BenC> Laney: I'm going to leave haskell in your capable hands nowâ¦my goal of getting ghci working on ppc and having things build without errors is now complete
<BenC> So hopefully when you do 7.4.2, powerpc will be able to keep in sync
<Laney> \o/
<Laney> did it get upstream?
<Laney> I note hackage is down â¦
<BenC> I gave it to erik, I haven't sent it upstream...
<Laney> k
<dobey> can someone please accept ubuntuone-storage-protocol and ubuntuone-client into precise-proposed?
<bdmurray> pitti: oh, whoa sorry about that fixing now.
<pitti> bdmurray: great, thanks!
<mterry> @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, mterry
<mterry> infinity, heyo!  What pilot stuff are you working on?  (So I can avoid dup work)
<stgraber> mterry: he's been piloting for days ;)
<mterry> stgraber, ah, OK.  Poor man
<pitti> probably just forgot to remove himself
<pitti> /nick infinity Amelia_Earhardt ?
<mterry> mvo, I'm guessing https://code.launchpad.net/~evfool/synaptic/ancientfixes/+merge/93134 is fine now?  (You had requested fixes, they were made, but no re-review yet)
<hallyn> anyone else having trouble getting quantal apt-get update to finish this morning?
<jamespage> hallyn, i *might* have seen something like that but I could not rule out flakey broadband
<hallyn> jamespage: i thought i couldn't rule it out, but at this point it's getting ridiculous
<mvo> mterry: yes, its on my todo since forever :(
<mterry> mvo, OK.  :)  no worries, it's just the first item on the sponsoring report, so I thought I'd check it out
<mvo> mterry: i know :( I need to send evfool (and the synaptic users) a box of chocolate for leaving this idle for *so* long
<mterry> mvo, I didn't realize you/Ubuntu had so much of a hand in synaptic upstream
<seb128> mvo, hey, aptdaemo... oh, you did that, sorry I just got used to it :p
<mterry> mvo, thought that was someone else's baby
<mterry> mvo, you just love apt  :)
<mvo> mterry: I do :)
<seb128> mterry, mvo is well famous for synaptic, he was a rockstar before Ubuntu even existed ;-)
<mvo> seb128: haha
<mvo> seb128: playing in front of a rather small audience, but still!
<seb128> mvo, ;-)
<jamespage> Sweetshark, what currency do you take bribes in?  I need to get a couple of changes into libreoffice for quantal...
<Sweetshark> jamespage: currency base unit is a removed C++11 ABI symbol in quantal ....
<jamespage> Sweetshark, oh joy
<jamespage> does that mean we can't change it?
<seb128> bdmurray, hey, is there anything special in bug #927515 that you assign it to us?
<ubottu> Launchpad bug 927515 in thunderbird (Ubuntu) "thunderbird uses excessive cpu power" [High,Confirmed] https://launchpad.net/bugs/927515
<Sweetshark> jamespage: na, just kidding (although there _are_ still issues with gcc4.7/C++11 stuff). what changes would you need?
<jamespage> Sweetshark, specifically bug 1023405 to support demoting tomcat6 to universe
<ubottu> Launchpad bug 1023405 in tomcat6 (Ubuntu) "please transition libservlet2.5-java -> libservlet3.0-java and then demote tomcat6 source and binaries to universe" [High,Triaged] https://launchpad.net/bugs/1023405
<jamespage> Sweetshark, and switching from openjdk-6 to openjdk-7 - I believe Debian has this in experimental ATM
<bdmurray> seb128: its a regression in a -updates package as I understand it
<Sweetshark> jamespage: I think both of it is already done, the package is just not in quantal because of the failing tests ...
 * Sweetshark checks
<seb128> bdmurray, well, it's "some people seem to have some performance" issues, which was really never confirmed as a regression, and it was reported in february on tb10 and we are at tb13
<bdmurray> seb128: if its not confirmed as a regression then maybe the tag should be removed?
<seb128> bdmurray, it might be a regression
<Sweetshark> jamespage: please verify with the package in https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/
<seb128> bdmurray, sorry, let's reboot that discussion, I meant to ask "did you assign the bug because the issue increased recently and is urgent, or did you just want to make it visible to us"?
<jamespage> Sweetshark, will do
<Sweetshark> jamespage: I see no openjdk, but fault-jdk, default-jdk (>= 1:1.7-48) [ia64]
<bdmurray> seb128: as a part of the SRU team I've subscribed to reression-update and regression-proposed bug reports.  So now I get email about comments on those bugs.  So somebody commented on it recently and I wanted to make it visible to you as there is no comment from the desktop team about it.
<Sweetshark> jamespage: hmm, but there is still libservlet2.5-java. I can give it a try with 3.0 though -- if that 'Just works(tm)' there is no issue.
<jamespage> Sweetshark, it should - there is no API change - I did take a look and it appears to parse stuff from commons-logging?
<seb128> bdmurray, ok, thanks, I just wanted to make sure I don't overlook something when descoping that, it's there since february and hitting some users but it's a normal bug
<seb128> bdmurray, I will untag
<jamespage> Sweetshark, I think the openjdk-7/default-jdk stuff looks OK - I will take a more thorough look tommorow
<jamespage> servlet transition should be a no-change transition, i.e. packaging only
<bdmurray> seb128: is empathy applying for a micro release exception? bug 1018784
<ubottu> Launchpad bug 1018784 in empathy (Ubuntu Precise) "[SRU Precise] update to 3.4.2.3" [Wishlist,In progress] https://launchpad.net/bugs/1018784
<seb128> bdmurray, empathy is part of GNOME
<seb128> bdmurray, which has one ;-)
<ScottK> How is "GNOME" defined?
<stgraber> ScottK: the DMB has a definition for "GNOME" IIRC, I can try to dig that out
<ScottK> I'm curious if it matches the MRE definition.
<stgraber> ScottK: http://git.gnome.org/browse/jhbuild/tree/modulesets that's what we're using
<stgraber> for example for desktop-extra we used:
<stgraber> Create desktop-extra packageset with description "Every package that is NOT
<stgraber>   in ubuntu-desktop, desktop-core or core, but needed for a vanilla GNOME.
<stgraber>   Vanilla GNOME is defined by upstream in gnome-suites-core,
<stgraber>   gnome-suites-core-deps, and gnome-apps:
<stgraber>   http://git.gnome.org/browse/jhbuild/tree/modulesets"
<ScottK> Interesting.
<stgraber> I don't think the MRE is nearly as clear but I suppose it could be updated to use the same source of modules list
<ScottK> Probably not a bad thing for when SRU team people like me run into a question.
<ScottK> For KDE it's https://projects.kde.org/projects/kde and websvn.kde.org/trunk/KDE/ (since not everything's in Git yet)
<infinity> mterry: It's entirely possible that I've been piloting for a week.
<infinity> @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: mterry
<mterry> infinity, :)
<SpamapS> bdmurray: FYI, I missed my SRU shift yesterday, so I'm going to work backwards (hardy -> precise, newest -> oldest) for a couple of hours to try and avoid colliding with you :)
<cjwatson> gema: Would there be any chance of adding /var/log/installer/debug to the jenkins test results for ISO testing jobs, when it exists?  I'll need that to debug bug 1023036 further.
<ubottu> Launchpad bug 1023036 in ubiquity (Ubuntu Quantal) "Error on /usr/share/ubiquity/plugininstall.py", line 1687, affecting desktop images (preseeded install)" [Critical,In progress] https://launchpad.net/bugs/1023036
<gema> cjwatson: we'll look into it
<cjwatson> Thanks.  I assume it's a fairly small change somewhere ...
<gema> cjwatson: I am about to leave, but I will leave hggdh on the case
<cjwatson> Thanks.  If possible it would be helpful if it could be done before the run that's going to start soon for the images I'm building right now :-)
<cjwatson> Only just occurred to me.
<bdmurray> SpamapS: bug 979661 was overridden by a security upload I believe
<ubottu> Launchpad bug 979661 in update-manager (Ubuntu Quantal) "oneiric to precise: debconf: unable to initialize frontend: Gnome and falls back to Dialog" [Critical,Fix released] https://launchpad.net/bugs/979661
<ScottK> SpamapS: There was a push for precise SRUs lookiing at 12.04.1, so you might want to start from one end of those.
<SpamapS> ScottK: indeed, I will, there's only a few in the older buckets anyway
<gema> cjwatson: if not, we'll rerun them jobs, hggdh is on the case
<hggdh> cjwatson: looking at it now, should have something in a few. I understand you would like the desktop jobs re-run ASAP with the debug log, correct?
<cjwatson> hggdh: Only if they've already picked up the build I just finished
<cjwatson> 20120712.2
<hggdh> cjwatson: ack
<mterry> The latest python3 upgrade seems broken.  Is that a known issue?
<mterry> "py3clean: error: only one action is allowed at the same time" breaks the python rtupdate hook
<toabctl> charles, i'm trying to use dbus 1.6 on ubuntu 12.10 but the indicators are not shown (see #1014850). how can i debug the indicator stuff?
<dobey> is python3 3.2.3-2 failing to install for everyone else on quantal?
<charles> toabctl: none of the indicators are shown?
<toabctl> charles, i see some (datetime, message, sound)
<toabctl> and also "system" (i don't know the name). the one with the username (but my username is not shown. the user name is "User Name")
<charles> fun fun
<toabctl> charles, i tried to run: /usr/lib/libindicator/indicator-loader3 /usr/lib/indicators3/7/libpower.so
<toabctl> charles, then i get:
<toabctl> http://paste.ubuntu.com/1088487/
<toabctl> charles, and the indicator is visible in a window :)
<stokachu> seb128: dbus-test-runner failing to build, looks like it needs a build-depends on dbus as well
<stokachu> since the test cases require dbus running
<seb128> stokachu, thanks
<stokachu> seb128: sure thing, i was gonna do a mergeproposal if you'd like
<seb128> stokachu, your call, I'm happy to just do it, it's not like it was hard work ;-)
<stokachu> seb128: ill do it an re-test then give you a ping when its done
<stokachu> helps me keep track of +1 stuff anyway
<seb128> stokachu, ok
<seb128> stokachu, thanks
<charles> toabctl: the accessible description + atk-bridge lines aren't relevant to this...
<charles> ...but the "/bin/dbus-daemon: no such file or directory" sounds suspicious given what you're trying to do
<charles> toabctl: what are the relevant changes in dbus between 1.4.18 and 1.6?
<toabctl> charles, good question. i don't know
<toabctl> charles, http://permalink.gmane.org/gmane.comp.freedesktop.dbus/14740
<toabctl> charles, btw: the global menu is not shown, too
<charles> toabctl: hooray! :/
<stokachu> seb128: lol you went ahead and did it?
<stokachu> to fast for me
<charles> toabctl: do you have a repo for 1.6?
<stokachu> seb128: oh nm thats just depends
<stokachu> bah been staring out build outputs to long
<seb128> stokachu, yeah, I was going to ask
<toabctl> charles, no
<seb128> stokachu, I did add the depends because libindicate ftbfs
<stokachu> seb128: ah ok
<stokachu> seb128: i created the merge which explains what i did if you want to take a look
<stokachu> nothing major
<seb128> stokachu, sure
<stokachu> cool thanks man
<toabctl> charles, i used the version from debian with some small modifications (copied upstart script, removed systemd build-dep)
<seb128> stokachu, url?
<stokachu> seb128: https://code.launchpad.net/~adam-stokes/ubuntu/quantal/dbus-test-runner/build-depends-dbus/+merge/114704
<stokachu> seb128: and... if you got time i fixed aces3 build as well
<stokachu> https://code.launchpad.net/~adam-stokes/ubuntu/quantal/aces3/build-fix/+merge/114675
<seb128> stokachu, url? ;-)
<seb128> stokachu, ok
<stokachu> sweet thanks a lot, ttyl
<seb128> stokachu, small comment on the dbus-test-runner one, .1 is for SRUs, we just bump the number on dev series, i.e ubuntu1 -> ubuntu2
<seb128> stokachu, don't worry about fixing it, I'm doing that
<stokachu> seb128: ah ok ill remember that
<stgraber> BenC: I'm running a test build of libguestfs on powerpc, if it passes I'll upload the fix for bug 1002991
<stokachu> seb128: i kinda figured but wasn't sure
<ubottu> Launchpad bug 1002991 in libguestfs (Ubuntu Quantal) "Should be built on powerpc as well" [Undecided,New] https://launchpad.net/bugs/1002991
<BenC> stgraber: Thanks, let me know if I can do anything
<stgraber> BenC: should that change also be applied to Debian? looks like we're in sync on libguestfs and I don't see a bug report on the Debian BTS
<BenC> Yeah, I'm bad about pushing bugs that deep
<BenC> I'll do that today
<stgraber> thanks
<cr3> what might be the reason for lintian to complain about missing-dependency-on-python-support for a python3 project which already specifies ${python3:Depends}?
<dobey> cr3: the debian/rules is using dh_pysupport probably
<hallyn> roaksoax: hi, bug 799858 really wants to be SRUd, but i think it's been held up bc i haven't had the rights to upload the proposed fix to -proposed
<ubottu> Launchpad bug 799858 in procps (Ubuntu Lucid) "package qemu-kvm-extras-static 0.12.3+noroms-0ubuntu9.9 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Confirmed] https://launchpad.net/bugs/799858
<roaksoax> hallyn: give me a sec and I'll upload it :)
<hallyn> roaksoax: would you mind taking a look at http://people.canonical.com/~serge/procps-e.debdiff and sponsoring it ifi t looks ok to you?
<hallyn> roaksoax: thanks
<hallyn> i was sure someone had done that for me in march.  but don't know where it went
<roaksoax> hallyn: looks good to me
<hallyn> roaksoax: hm, wait
<hallyn> roaksoax: i see it in the Rejected queue
<hallyn> don't know why it was rejected
<cr3> dobey: debian/rules seems clean, dh "$@" --with translations,python3
<roaksoax> hallyn: "The fix itself looks ok, but I think the changelog entry needs work - specifically, it doesn't actually describe the problem it fixes at all. I've rejected it from the queue; please upload again with an expanded changelog entry (something like âfixes failure to install when $STUFFâ)."
<roaksoax> hallyn: just update the description on the changelog and that should be it
<hallyn> meh
<dobey> cr3: postinstall script or something? check the build log to see if dh_pysupport is being run anywhere?
<hallyn> roaksoax: where did you see that msg?
<roaksoax> hallyn: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/799858/comments/22
<mterry> @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:
<ubottu> Launchpad bug 799858 in procps (Ubuntu Lucid) "package qemu-kvm-extras-static 0.12.3+noroms-0ubuntu9.9 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1" [Medium,Confirmed]
<hallyn> roaksoax: oh that's right, that's why i uploaded a new one to the bug.  guess that got lost
<roaksoax> hallyn: could you ellaborate more the fix on the changelog so it doens;t get rejected again please :)?
<hallyn> roaksoax: i'm going to claim that i already did that in the bug and it was ignored, but hold on, i don't like that one and am doing a new one
<cr3> dobey: the postinst script uses #DEBHELPER# which is being replaced with something that contains: # Automatically added by dh_pysupport
<hallyn> roaksoax: http://people.canonical.com/~serge/procps-e2.debdiff
<cr3> dobey: and, the generated debian/*debhelper.log contains dh_pysuppport; not sure where it's coming from though
<dobey> cr3: is there a debian/pyversions file?
<ScottK> cr3: Dehelper's automatic buildsystem selection
<cr3> dobey: not sure if it matters, but I'm running debuild on precise rather than quantal
<cr3> dobey: no, just debian/pycompat containing: 2
<ScottK> It doesn't know about dh_python3.
<dobey> ah
<ScottK> I suspect if you add --with python2 (even if there's no python in it) that will go away).
<dobey> cr3: you should probably remove that file if you're using dh_python2/3
<cr3> ScottK: really? I do have /usr/bin/dh_python3 and I'm using --with translations,python3
<dobey> also what ScottK said
<ScottK> cr3: That doensn't say anything about how to deal with python code.
<ScottK> bdmurray: There are a number of bugs like Bug #1024016  where the offending package is wrongly selected as python3-defaults.  Is there some way that could be automated based on the error message?
<ubottu> Launchpad bug 1024016 in ubuntu-drivers-common (Ubuntu) "package python3 3.2.3-2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 4" [Undecided,Confirmed] https://launchpad.net/bugs/1024016
<cr3> ScottK: will that ultimately mean that I'll also need to add ${python:Depends} in addition to ${python3:Depends} to my requires line?
<ScottK> No.
<roaksoax> hallyn: done!
<cr3> ScottK: cool, I'll give that a try then. thanks!
<ScottK> dh_python2 just won't do anything.
<ScottK> I think, I didn't actually try this.
<dobey> ScottK: is there a way to workaround that bug? my quantal laptop is hosed at the moment with python3 failing to configure :-/
<ScottK> Dunno.  remove ubuntu-common-drivers and the apt-get -f install?
<cr3> ScottK: when I changed --with python3 to python2, lintian returns lots of python-script-but-no-python-dep
<ScottK> cr3: I didn't say change it, I said add it.
<cr3> ScottK: heh, my mistake. trying again then :)
<cr3> ScottK: now I get: missing-build-dependency-for-dh-addon python2 => python | python-all | python-dev | python-all-dev
<ScottK> Right.
<ScottK> didn't think about that.
<hallyn> roaksoax: thanks!
<ScottK> Avoiding having any python installed at all will also solve it.
<cr3> ScottK: I'll revert to the previous missing-dependency-on-python-support lintian error and try to document the problem; it's the only remaining warning/error returned by lintian, so doesn't seem that bad
<ScottK> No.  It's not.
<stgraber> BenC: test build failed on the porter box. one of the tests failed. (when doing a test build of the precise version of libguestfs)
<dobey> ScottK: would "--buildsystem python3" not work on precise to fix cr3's issue?
<ScottK> I don't think so, but it might.
<ScottK> overriding dh_auto_build definitely would.
<toabctl> charles, i added dbus 1.6 to my testing ppa: https://launchpad.net/~toabctl/+archive/testing
<cr3> dobey, ScottK: I tried keeping --with python2,python3,translations and adding python, python3, python-distutils-extras, python3-distutils-extras, etc. in the Build-Depends; no more warnings
<tumbleweed> there is a python3 buildsystem in dh?
<toabctl> tumbleweed, there is dh_python3
<cr3> ScottK: I already had an override for dh_auto_build: set -ex; for python in $(shell py3versions -r); do $$python setup.py build; done;
<tumbleweed> toabctl: they are totally different things
<ScottK> Maybe it's auto_configure that needs the overrid.
<ScottK> cr3: Did you also run auto_build before or after that snippet?
<cr3> ScottK: nope, but I've noticed apport call dh_auto_build and then python3 setup.py build
<ScottK> You don't need them both, as a rule.
<cr3> ScottK: ok, that's reassuring. what do you think about having both python and python3 in build-depends though? seems to quiet lintian :)
<ScottK> I think it's the wrong way to solve the problem.
<ScottK> You need to override debhelper's auto magic so it's not trying to build for python.
<cjohnston> slangasek: ping
<stgraber> tkamppeter: what's the status of bug 998156? you targeted it to the point release but I don't see any activity on it. Will it be fixed in the next few days and make it to the point release?
<ubottu> Launchpad bug 998156 in gtk+3.0 (Ubuntu) "GTK Print dialog sends broken custom page size attribute: "PageSize=Custom.Custom.<width>x<length>"" [High,Confirmed] https://launchpad.net/bugs/998156
<xnox> stgraber: stop spamming me =)
<xnox> stgraber: I know that time is ticking away
<stgraber> xnox: ;)
<highvoltage> stgraber: keep spamming him, maybe he'll be less noisy
 * xnox punches highvoltage
<stgraber> don't worry I'm spamming everyone just as much, except for these that already have all their SRUs uploaded :P
<xnox> =))))))))))))))))))))))))))))
<highvoltage> he nearly smacked me with that might beast of a laptop he has!
<highvoltage> *mighty
<xnox> stgraber: me tumbleweed and highvoltage are all sitting next to each other ;-)
<Laney> i heard it's raining over there
<tumbleweed> just a little
<tumbleweed> we're all taking shelter in the xen talk
<infinity> It's not raining, it just sounds like it is.
<infinity> We're going to send xnox outside to prove this theory.
<xnox> infinity: you will get my toe in your face in 3, 2, 1
 * xnox infinity says:"that's terrifying"
<infinity> I'm going to be scarred for life.
 * stgraber spams xnox some more
<xnox> stgraber: lp is slow, didn't get the email yet
 * xnox waits
<highvoltage> hmm, it should be pretty easy to port most "yo mamma" jokes to "launchpad" jokes.
 * highvoltage feels a new twitter account in the making
<infinity> highvoltage: Yo' webapp so fat, it gots its own datacenter?
<stgraber> xnox: I have that feeling that whenever mdadm lands in -updates we'll suddenly see a quarter of the 12.04.1 bugs be closed at once ;)
<xnox> infinity: LOL
<highvoltage> infinity: yo launchpad is so big that the long double numeric variable type in C++ is insufficient to express its weight
<BenC> stgraber: Are the tests built-in to the package?
<BenC> I'll attempt to get it running from my box
<stgraber> BenC: yeah, all I did was run debuild
<cr3> hi folks, how could we go about removing hwdb-client from universe since it's been deprecated for quite a while now
<stgraber> ScottK: Can I assign bug 991754 to you and mark fix commited? I believe it's part of that postfix SRU that got in this morning.
<ubottu> Launchpad bug 991754 in postfix (Ubuntu Precise) "Add support to turn off the TLSv1.1 and TLSv1.2 protocols" [High,Triaged] https://launchpad.net/bugs/991754
<ScottK> stgraber: Sure (and it is)
<hggdh> cjwatson: I know it is late, but are you still there? I cannot see how to save the Ubiquity debug log you asked for (at least 'd-i early-command httpd' seems to fail with "sh: httpd not found"
<hggdh> and all I can find on it suggests one has to manually copy over the /var/log/installer/*
<ScottK> Those python3-defaults fails to configure bugs are python3-defaults after all.
<ScottK> I just uploaded half the fix.  Waiting to here from POX on the rest.
<ScottK> The affected packages are going to have to be rebuilt.
<slangasek> cjohnston: hi there
<cjwatson> hggdh: that seems like kind of a d-i-ish approach; live filesystems don't have apache2 installed ...
<hggdh> cjwatson: how to save it, then? It was indeed a d-i-ish approach :-)
<hggdh> the only one I knew how to do, and the Ubiquity docs do not clearly state as, ah, wrong
<cjwatson> hggdh: I guess maybe you could apt-get install apache2 instead?  it should automatically start then
<cjwatson> though you'd have to configure a site that let you download stuff from /var/log
<hggdh> heh
<hggdh> cjwatson: I will see this one (although is starting to get more complex, and may cause spurious errors); I will also try SSH
<cjwatson> the latter might be easier, yeah
<hggdh> cjwatson: thanks, and sorry to bother
<cjwatson> can't you use the same approach that works for /var/log/syslog?
<cjwatson> Or is that via some kind of magic one-use-only channel?
<hggdh> cjwatson: /var/log/installer/syslog is tied to the serial console; perhaps I could open a second serial
<hggdh> then yeah, it would be quite simple
<cjwatson> worst case, it wouldn't be awful to conflate the two logs just for the time being
<cjwatson> although it would be better to have something that could be used permanently
<hggdh> indeed. But you need it ASAP, so I will see if a second serial is easily set, otherwise I will just conflate them
<cjohnston> slangasek: you still around?
<slangasek> cjohnston: ish
<cjohnston> slangasek: two things.. have you come up with some sort of wording for the 'required' stuff in LP/Summit... and.. We need someone who is good with writing algorithms to help us write one for scheduling to take into account certain things like we discussed... any suggestions on anyone who may be able to help?
#ubuntu-devel 2012-07-13
<BenC> stgraber: how do I check the test results?
<stgraber> BenC: no idea, in my case the build died right after the failure. If you actually get debuild to succeed, then it didn't fail for you
<BenC> stgraber: it failed in the tests, but I'm trying to find the output of those failures and it isn't very easy
<bretth> how do i make an "applet" that runs in the ubuntu "system-tray" ?
<TheMuso> bretth: YOu want to create an indicator. Best you ask on #ubuntu-app-devel, I am pretty sure someone in there can point you to indicator documentation.
<bretth> TheMuso, thanks!
<Diopter> Is there an easier way to add a custom .udeb to an initrd.gz than rebuilding the debian-installer?
<bretth> what's the best way from python for my script to know that it is running in Ubuntu with Unity?
<bretth> (my script needs to support multiple desktops, Gnome3, Cinnamon, etc)
<bretth> i was thinking that "try: import appindicator" is one way, but kind of looks like a hack.
<TheMuso> bretth: I believe jockey does something similar to check environment. Check the jockey source package from Ubuntu, quantal should do, but precise would be a better option, as jockey has changed somewhat so far as I understand things...
<TheMuso> bretth: Jockey also has multiple frontends for GTK and KDE.
<RAOF> @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: RAOF
<bretth> TheMuso, thanks, another question, how long will Ubuntu support pygtk (gtk2)? is it safe to write my app using pygtk?
<TheMuso> bretth: If you are supporting precise or later, I strongly suggest you use Gtk2 via GObject introspection.
<TheMuso> Or even better, use GTK3.
<bretth> i need to also support Ubuntu 10.10
<TheMuso> Pygtk2 is not supported upstream really, so far as I know, if anything, they want it gone.
<TheMuso> Ah ok, then I think pygtk2 is your best bet then.
<micahg> bretth: Ubuntu 10.10 is no longer supported, why would you want to support it?
<bretth> micahg, its not my decision
<micahg> bretth: 10.04 is supported on the desktop for another 9 months
<bretth> 10.04 is Unity?
<micahg> bretth: no, it's pre unity, but even in precise, you don't have to use Unity, there are many other desktop environments
<bretth> micahg, seems that must use Unity for appindicator.
<JontheEchidna> gnome2 had indicator-applet, iirc
<infinity> And indicators are used in other DEs as well.
<micahg> bretth: no, I don't think that's true, there are indicators in xubntu
<infinity> They're there by default on Xubuntu.
<micahg> *Xubuntu
<infinity> Kubuntu may also do something with them, but I don't remember.
<bretth> oh good, that makes it easier to support Xubuntu.
<JontheEchidna> the KDE panel tray supports anything conforming to the indicator spec
<bretth> i already have a applet designed for KDE
<JontheEchidna> oh yeah, you were in #kde-devel last night I think
<bretth> yep, that was me.
<bretth> so is Wayland making it into the next Ubuntu?
<JontheEchidna> I don't think that'll happen for a while. *Maybe* there will be a tech demo available for installation in the archives for the next Ubuntu.
<bretth> i have python wrappers for wayland working
<bretth> works with Python2, Python3, and PyPy
<bretth> http://code.google.com/p/rpythonic/source/browse/examples/wayland-server-eventloop.py
<bretth> http://code.google.com/p/rpythonic/source/browse/examples/wayland_server/__init__.py
<JontheEchidna> !info weston quantal
<ubottu> weston (source: weston): reference implementation of a wayland compositor. In component universe, is optional. Version 0.85.0-1build1 (quantal), package size 178 kB, installed size 437 kB (Only available for linux-any)
<scientes> JontheEchidna, does it work with gtk now?
<bretth> scientes, i saw some screen shots of gtk on wayland.
<scientes> yes yes i've used it myself
<scientes> but i mean in ubuntu
<scientes> without building anything
<vibhav> cjwatson: ping
<pitti> Good morning
<ScottK> Good morning pitti.
<ScottK> pitti: Just so someone else other than me knows the status: We've had Bug #1024016  and a fair number of duplicates pile up yesterday and tonight.  I think I just uploaded the final bit of fixing it.
<ubottu> Launchpad bug 1024016 in python3-defaults (Ubuntu) "package python3 3.2.3-2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 4" [Critical,Fix released] https://launchpad.net/bugs/1024016
<ScottK> Made the publisher run by a few seconds, so we should see goodness in half an hour.
<ScottK> I grabbed the .debs from LP and confirmed it's really, really fixed now.
<pitti> ah, seems I just ran into this during daily dist-upgrade; thanks!
<ScottK> You can either grab the new versions of whatever you have installed from python3-defaults or wait a bit I guess.
<dholbach> good morning
<RAOF> @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:
 * dholbach hugs RAOF
<dholbach> hum, is anyone else having an issue with python3-minimal installation in quantal?
<RAOF> Morning dholbach :)
<dholbach> hey :)
<RAOF> dholbach: That should be fixed in python3 3.2.3-3ubuntu1
<RAOF> You're seeing bug #1024016
<ubottu> Launchpad bug 1024016 in python3-defaults (Ubuntu) "package python3 3.2.3-2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 4" [Critical,Fix released] https://launchpad.net/bugs/1024016
<dholbach> ok, manually downloading the packages and installing them with dpkg -i fixed it
<dholbach> but apt-get install -f didn't
<jamespage> any perl guru's around? I need some help with bug 1022385 - seen this a few times now and not really sure what it points to
<ubottu> Launchpad bug 1022385 in samba (Ubuntu) "package samba 2:3.6.3-2ubuntu2.3 failed to install/upgrade: subprocess installed post-installation script returned error exit status 128" [Undecided,New] https://launchpad.net/bugs/1022385
<cjwatson> the exit code may be unrelated to the noise from debconf, since none of that noise ought to be fatal
<cjwatson> 128 is an unlikely exit code for a debconf-related problem; but you can try with DEBCONF_DEBUG=developer to establish that more certainly
<cjwatson> I think that noise basically means that the user disconnected from debconf, maybe by closing a dialog box or something
<rbasak> Thanks. I'd left the bug there because I wondered if anyone else knew what was going on
<jamespage> rbasak, I found another 128 code with bacula with similar symptoms hence my question - cjwatson - OK I'll get the reported to try that then
<jamespage> ta
<jamespage> cjwatson, does exit code 128 have any specific meaning?
<jamespage> (and where would I look for that sort of thing)
<cjwatson> There's no single place you can look.  Exit codes are very application-specific.
<cjwatson> I can't think of any specific meaning for 128 that might have broad applicability.
<cjwatson> hggdh: Don't suppose you had any luck getting me that debug output?
<cjwatson> hggdh: There seems to be some in https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_default/69/, but it doesn't contain the bits I expected ...
<gema> cjwatson: I am executing another job, on a particular node and will connect to the VM whenever it's done installing
<gema> cjwatson: I should be able to get you some logs out of it
<cjwatson> OK, let's hope it actually fails
<gema> cjwatson: indeed
<cjwatson> Currently uploading ubiquity 2.11.14 with an utter-guesswork possible fix (I think it's a long shot but you never know)
<gema> cjwatson: will I be able to connect to the VM if it never finishes installing?
<cjwatson> I don't know
<cjwatson> That all sounds rather specific to your test environment, and I'm not familiar with it
<gema> cjwatson: I am learnin as I go, but the installer just said that it installed successfully :/
<cjwatson> Try again
<gema> ack
<cjwatson> It's racy - even on jenkins, which seems to reproduce this more frequently than any other environment (maybe just because it does lots of runs), it only happens sometimes
<gema> ok
<cjwatson> I think only one of last night's runs failed
<cjwatson> https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_encryptedhome/46/artifact/46/test-results/d-i-debug.log exists but is empty :-(
<gema> cjwatson: do you know roughly at which point in the installation this happens?
<cjwatson> hggdh: Whatever you did in https://jenkins.qa.ubuntu.com/view/Quantal/view/ISO%20Testing%20Dashboard/job/quantal-desktop-i386_encryptedhome/46/ seems to have made the d-i-syslog useless too
<cjwatson> gema: "Configuring hardware"
<cjwatson> Fairly near the end
<cjwatson> hggdh: That seems to be more like casper.log or something ...
<gema> cjwatson: I tried on one of my test machines the other day and it got stuck on the camera screen to never come back
<cjwatson> gema: Whatever that is (a gstreamer bug, I guess), it's unrelated
<gema> cjwatson: ack
<dholbach> didrocks, can you join #ubuntu-arb again? :-D
<didrocks> dholbach: yeah, coming. Should really adjust my autojoin :)
<dholbach> :)
<toabctl> i have a dependency problem with python3 on quantal: http://paste.ubuntu.com/1089585/
<seb128> could somebody set https://code.launchpad.net/~lars.duesing/ubuntu/precise/aiccu/aiccu-upstart-server-patch-precise/+merge/111610 as merged?
<seb128> the fix got uploaded but the merge request was targetting precise and not precise-proposed
<pitti> seb128: done
<seb128> pitti, danke
<hggdh> cjwatson: all I did was pass to the kernel debug-ubiquity
<hggdh> cjwatson: and the debug log seems to be empty. I tried /var/log/debug as I was told, and /var/log/installer/debug, as the wiki says
<pitti> there, StacktraceSource.txt is being produced again: http://launchpadlibrarian.net/110026354/StacktraceSource.txt
<seb128> cjwatson, green jenkins on both amd64 and i386, either we got lucky or you fixed the bug ;-)
<cjwatson> seb128: we got lucky
<cjwatson> I suspect
<cjwatson> seb128: oh, do you mean with .14?
<cjwatson> seb128: there've not been any tests with the latest build yet, so really can't say anything
<seb128> cjwatson, no, 13.1 for both
<cjwatson> hggdh: I did tell you /var/log/installer/debug, not /var/log/debug (which would be wrong)
<seb128> cjwatson, I though .1 was your recent upload
<seb128> cjwatson, .14 is tomorrow ;-)
<seb128> cjwatson, well, anyway, let's see
<pitti> seb128: retracers (hopefully) fixed again, after the two recent cron mails
<seb128> pitti, thanks
<seb128> pitti, what was the issue on those?
<pitti> seb128: the first one was a bug when a source file had non-ascii characters, the retracer is running under C locale
<pitti> seb128: the second just me picking the wrong cache dir when running apport-retrace manually
<seb128> did I say how much I hate encodings? ;-)
<pitti> seb128: it got exposed because StacktraceSource.txt is back on now
<seb128> nice to see those back, thanks for that
<pitti> seb128: yeah; one of these years, C and all other non-UTF-8 encodings just belong abolished..
<seb128> it's handy to have them
<cjwatson> seb128: yeah, everyone should speak ASCII-only languages
<cjwatson> (shame English doesn't qualify ...)
<seb128> english is not ascii only?
<cjwatson> "naÃ¯ve"
<pitti> yeah, http://launchpadlibrarian.net/110026354/StacktraceSource.txt looks quite nice
<seb128> you stole that to us, didn't you? ;-)
<cjwatson> "fÃªte" - various odds and ends like that
<pitti> ("from"?)
<cjwatson> and yeah, mostly French imports :)
<cjwatson> actually these days it's mostly legit to drop the diacritics but anyway
<pitti> cjwatson: don't forget about the âº
 * pitti imagines Kanji or Mandarin in ASCII art
<seb128> pitti, á¹²ÃÏá¾â¥Ï
<seb128> pitti, http://fsymbols.com/generators/encool/ does that sort of stuff ;-)
<seb128> you type ascii chars and it gives you a fancy similar looking one made from unicode chars
<pitti> Â¡ÊuunÉ sÊoo× ÊÉÉ¥Ê
<seb128> âÎµâ­â¤Î±Î·
<pitti> oops, /me turns his monitor back up
<seb128> lol
<pitti> . o O { clearly Friday afternoon.. }
<seb128> pitti, how did you do that? ;-)
<pitti> seb128: I turned my monitor upside down
<seb128> hehe
<pitti> nah, http://www.sevenwires.com/play/UpsideDownLetters.html
<seb128> ok, we just traded fun websites then :p
<seb128> â¥â@ââá¹§ Î·á¸¯Â¢Îµ
<seb128> it's friday indeed ;-)
<ev> mpt: looking at the several week view of "average crashes per day." Rather unsurprisingly, theres a bump on the weekends.
<zul> didrocks: ping
<didrocks> zul: pong
<mpt> ev, which isn't what we want ... You shouldn't be able to improve the stats by making Ubuntu so that people don't want to use it
<zul> didrocks: can you have a look at the python-quantumclient MIR (LP: #1021822)
<didrocks> zul: what is depending on it?
<zul> didrocks: new nova build depends
<didrocks> zul: can you please state that in the MIR?
<ev> mpt: hmm? In that because it doesn't factor in the total usage it's skewed on the weekends? Thus if we make people use Ubuntu for shorter periods of times the graph will look better, but the experience will still be poor?
<zul> didrocks: done
<didrocks> zul: all build-deps are not in main
<didrocks> zul: python-nosexcover is not for instance
<zul> didrocks: crap
<didrocks> zul: can you please check it again? the stenza in the MIR is not just for copy and paste :)
<didrocks> zul: please reassign once sorted out :)
<mdeslaur> barry: is there a bug open for the uninstallable python 3 in quantal?
<cjwatson> can't be entirely uninstallable, livefs builds haven't broken
<cjwatson> (I haven't looked at it at all mind you and won't, enough on my plate)
<ogasawara> @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: ogasawara
<mdeslaur> dobey: did you figure out your python3 install issue? is there a bug open?
<dobey> mdeslaur: i haven't figured it out, no. there is a bug with many dupes afaik. let me see if i can find the #
<dobey> mdeslaur: https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1024016 i think
<ubottu> Launchpad bug 1024016 in python3-defaults (Ubuntu) "package python3 3.2.3-2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 4" [Critical,Fix released]
<mdeslaur> dobey: ah, yes, that's the one...thanks
<mdeslaur> dobey: ah, manually upgrading python3 as suggested at the end just worked for me
<dobey> yeah i just had to manually install the 3ubuntu1 version, then do -f install
<pitti> mvo: hey Michael, how are you?
<seb128> mvo, aptdaemon SRU veri^W forget about that you did it :p
<seb128> ;-)
<mvo> hey pitti, good, thanks! how are you (phonecall though right now)
<pitti> mvo: good, thanks! currently investigating some auto-upgrade-tester failures
<cr3> ogra_: hi there, roadmr and I need your assistance to close bug #245488 by removing the ol' hwdb-client package from universe :)
<ubottu> Launchpad bug 245488 in hwtest (Ubuntu) "please add proper replaces for hwdb-client to hwtest " [Medium,Invalid] https://launchpad.net/bugs/245488
<mvo> pitti: aha, precise->quantal? or lucid->precise?
<pitti> mvo: lucid->precise, but both really
<ogra_> cr3, yeah, i saw the bugmail, why the heck is that still there ?
<pitti> mvo: WDYT about http://paste.ubuntu.com/1089849/ ?
<cr3> ogra_: no clue but, instead of just marking the bug as invalid, we'd like to take this opportunity to clean the archive a bit
<ogra_> cr3, and that bug is obviously invalid now
<ogra_> ah
<cr3> ogra_: I'm using the bug as a nagging reminder to do things right :)
<ogra_> https://wiki.ubuntu.com/UbuntuDevelopment/PackageArchive#Removing_Packages
<pitti> mvo: I added a reproducer and analysis to bug 1024346 and verified that it works fine now
<ubottu> Launchpad bug 1024346 in auto-upgrade-testing (Ubuntu) "python import test fails on modules which need $DISPLAY" [High,In progress] https://launchpad.net/bugs/1024346
<cr3> ogra_, roadmr: 23 bugs for hwdb-client in ubuntu: https://bugs.launchpad.net/ubuntu/+source/hwdb-client
<cr3> ogra_: thanks for the link, we'll follow the process
<ogra_> cr3, just doing so
<cr3> ogra_: sweet, thanks!
<cjwatson> cr3: does checkbox still have any file overlaps with hwdb-client?
<roadmr> cr3: I got rid of all the hwtest bugs, didn't touch hwdb-client
<cr3> cjwatson: nope, hwdb-client was there such a long time ago, it was even renamed to hwtest before being finally renamed to checkbox
<ogra_> right
<cr3> ogra_: the good ol' days :)
<cjwatson> cr3: since it is still in the archive, if there were any file overlaps then they can't be excused by intermediate renamings
<cjwatson> so is the answer yes or no? :)
<ogra_> cjwatson, i changed the bug above into a removal bug for hwdb.-client
<cjwatson> I know, but that doesn't answer my question either
<cr3> roadmr: when did we remove the transitional package for hwtest -> checkbox? is it still in precise?
<roadmr> cr3: nope, last release it shows for is oneiric
<ogra_> how could there be file overlaps if one is in universe and the other is in main
<cjwatson> ogra_: that said, I'm confused, hwdb-client is not in quantal
<ogra_> even shipped on the cd
<cjwatson> ogra_: overlaps in their *contents*
<roadmr> cr3: removed since 2012-02-01
<cjwatson> universe/main> totally irrelevant
<cjwatson> right, I removed hwdb-client from intrepid in 2008.  I don't know why you're asking for it to be removed now :)
<cjwatson> https://launchpad.net/ubuntu/+source/hwdb-client/+publishinghistory
 * ogra_ doesnt get that, if checkbox works standalone without hwdb-client installed, where should be file overlaps ? 
<cjwatson> sigh
<cjwatson> you know what replaces: is for, right?
<ogra_> yes
<cjwatson> among other things, it's for when a package ships a file previously shipped by another package
<roadmr> I looked for hwdb-client and I found it in universe: http://archive.ubuntu.com/ubuntu/pool/universe/h/hwdb-client/
<ogra_> yes
<cr3> cjwatson: I just checked the packages in the archive and there are no overlaps with any files in checkbox
<ogra_> roadmr, thats old stuff
<cjwatson> if checkbox had shipped a file that hwdb-client previously shipped, then it ought to have had a Replaces header, despite hwtest coming in between
<ogra_> cjwatson, i still dont get how that would be relevant for the removal of hwdb-client
<cr3> ogra_: it might've been possible that both hwdb-client and checkbox installed /usr/bin/foo, for example. I think that's what we're looking for
<cjwatson> it's not particularly, it's just that sometimes people think that removing the old package is good enough in such cases, and it isn't
<roadmr> oh, foo
<cjwatson> I was checking that due diligence had been done
<ogra_> ah, ok
<cr3> cjwatson: hwtest, that followed hwdb-client, had a Replaces header
<cr3> cjwatson: err, checkbox has a Replaces header for hwtest, that followed hwdb-client
<cjwatson> understood but not relevant :)
<hggdh> cjwatson: were you talking (when you said the ubiquity syslog was useless) about the 'not copying..." etc?
<cjwatson> in general we cannot assume that users have traced through every step in our package renamings
<cjwatson> anyway, this is moot, because hwdb-client was gone in intrepid and you've said that there are no file overlaps
<cjwatson> hggdh: in the URL I gave, it's not even a ubiquity syslog.  it stops at the end of casper.
<ev> mpt: ah, excellent. That's much better than dealing with it off a subpage
<pitti> gema, mvo: do you know whether the jenkins upgrade tests use the branch or the package for auto-upgrade-testing?
<pitti> gema, mvo: i. e. I hope we don't need to SRU the latest changes just to fix the tests
<gema> pitti: I don't really know
<hggdh> cjwatson: yes, this build failed -- we got an error relating to hardware, and the install got stuck on a pop-up, and was eventually canceled on timeout
<mvo> pitti: I'm pretty sure it uses the package
<pitti> mvo: gah
<pitti> mvo: anyway, do you think the xvfb-run patch is appropriate?
<cjwatson> hggdh: ok
<pitti> ScottK: thanks for fixing the py3 mess!
<mvo> pitti: yeah, I think that is a excellent idea
<pitti> mvo: ok, thanks; committing that and uplaoding to quantal, so that at least teh precise->quantal tests should have this fixed
<ScottK> pitti: Thanks.  It was my sync that caused it, so I think it was mine to fix.
<mvo> pitti: cool, thanks
<jono> seb128, are you aware of compiz constantly restarting when using Libreoffice?
<seb128> jono, no
<seb128> jono, seems like a segfault, what Ubuntu version, is apport triggering?
<jono> seb128, I have been working on a presentation and it keeps restarting for me
<jono> apport isnt triggering
<jono> I am on Quantal
<seb128> jono, tail /var/log/apport.log?
<jono> seb128, no output
<seb128> jono, dmesg | grep compiz ?
<jono> seb128, [73664.275452] compiz[1828]: segfault at 64 ip b45b0677 sp bfac8f90 error 4 in libunityshell.so (deleted)[b4401000+307000]
<seb128> jono, there you go
<seb128> jono, sudo service apport start force_start=1
<seb128> jono, get the issue
<seb128> jono, report the bug
<jono> start: Job is already running: apport
<seb128> jono, ok, not sure why apport is not working then
<seb128> jono, nothing in /var/crash ?
<jono> seb128, bunch of things in there
<seb128> jono, compiz one?
<seb128> jono, you might want to wipe them all, trigger the bug and see if a compiz one gets written
<seb128> doko, hey, is https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1006860 good to upload or do you want to review,handle it?
<ubottu> Launchpad bug 1006860 in gdb (Ubuntu) "gdb crashes when loading core files (in is_ctor_or_dtor)" [High,Confirmed]
<doko> seb128, won't have time for it. a NULL check doesn't sound bad. please could you keep the report open?
<seb128> doko, is it fine if I upload? it's blocking the dx guys in some of the debugging they do
<doko> chrisccoulson, ping
<seb128> doko, probably leave some context, he's off for 2 weeks on paternity leave
<seb128> doko, he might look at IRC every now and then but is not working
<jono> seb128, just retriggered the bug, no apport crash
<jono> seb128, sorry for the delay, was on a call
<seb128> jono, nothing in /var/log/apport.log?
<jono> seb128, nope
<seb128> jono, do you have a ~/.apport-ignore.xml?
<jono> seb128, yep
<seb128> jono, does it contain something saying to ignore compiz issues?
<jono>  <ignore mtime="1340068323" program="/usr/share/accomplishments/scripts/ubuntu-community/infrastructure/canonical-contributor.py"/>
<jono> nope
<seb128> :-(
<seb128> you would need pitti then, not sure why apport doesn't work
<seb128> but he called it a week already I think
<jono> thanks seb128
<seb128> jono, I get you are down to "use gdb"
<seb128> if you want a stacktrace
<jono> I will see if this is still happening
<jono> seb128, if you open LO and edit a presentation, does the bug occur for you?
<seb128> jono, wb, do you think I'm crazy enough to run quantal yet? :p
<jono> seb128, are you serious? lol
<jono> seb128, I thought you would need to be running it
<jono> :-)
<seb128> jono, I'm part of the LTS .1 team in fact so for once I'm staying on stable for some time ;-)
<didrocks> jono: I see no crash in that case. However, the top unity panel becomes transparent, which is an interesting case on itself :)
<didrocks> when you double click to select something
<didrocks> well, not everytime
<didrocks> but common enough
<seb128> jono, it would help to get a stacktrace of the issue, do you know how to do that?
<jono> seb128, nope
<jono> I just rebooted and I can't reproduce
<seb128> hum, k
<jono> maybe this was fixed in an update
<jono> just trying to trigger it now
<seb128> could be
<jono> didrocks, hah!
<didrocks> well, there is transparent panel to get fixed :)
<jono> aha
<jono> it just happened
<jono> how do I get a trace seb128?
<seb128> didrocks, why do you hate the bling? ;-)
<didrocks> jono: if you get something similar, try to hover the panel
<didrocks> see if it's a crash
<didrocks> or something like I experience
<didrocks> seb128: well, I think we just created the <blink /> tag in unity :)
<seb128> jono, apport is still not logging any compiz file in /var/crash even after reboot?
<jono> didrocks, I see Unity seemingly restart and LAuncher vanishes and then returns
<jono> seb128, nope
<didrocks> jono: so maybe it's the same bug, it's not crashing, it's just blinking
<didrocks> that's why you don't get a crash file :)
<seb128> jono, basically, go to a vt, sudo gdb -p $(pidof compiz), on the compiz prompt:
<seb128> set logging on
<seb128> c
<didrocks> tsss
<seb128> return to your session
<seb128> get the bug
<didrocks> unity --advanced-debug in a vt
<didrocks> why do I work for otherwise? :)
<seb128> jono, ^ what didrocks says
<seb128> didrocks, does that log into a file?
<seb128> didrocks, or do you need to add --log?
<didrocks> seb128: I'm looking, I have a fish memory on what I did :)
<seb128> jono, key point is to run those commands from a vt or another session since when compiz will segfault you will not be able to access your session to go to gdb if you run it there
<jono> hmm switching VTs seems to restart compiz too
<jono> ok I ran --advanced-debug in a bt
<jono> vt
<seb128> jono, good, get the bug now ;-)
<jono> so just trigger it?
<seb128> yes
<seb128> that will freeze your xorg session
<seb128> got to the vt
<seb128> type "bt"
<seb128> and quit gdb
<seb128> that will restore your graphical session
<jono> ok triggered
<didrocks> yeah, it should log
<jono> bt says "no stack"
<didrocks> yeah, so I'm sure you have the same thing than I have
<didrocks> not a crash
<didrocks> just the launcher/panel blinking
<seb128> oh
<jono> ahhh gotcha
<jono> seb128, you should upgrade to see it ;-)
<didrocks> jono: want to open a bug or me to do it?
<jono> didrocks, would you as you can probably add more detail
<jono> all I can say is that it blinks
<didrocks> jono: sure
<jono> I will add the details of LO triggering it though
<jono> thanks didrocks!
<seb128> jono, I will put quantal on my netbook, I want to play with the system compositor stuff from robert_ancell anyway ;-)
<jono> thanks for the help seb128
<didrocks> jono: I will write it in French to punish the upstream team :)
<jono> didrocks, lol
<seb128> jono, yw, that also explain why apport didn't work ;-)
<jono> seb128, indeed
<jono> :-)
<jono> brb
<didrocks> (if only launchpad would let me file a bug)
<didrocks> seb128: does https://bugs.launchpad.net/unity/+filebug works for you?
<seb128> didrocks, it loads
<didrocks> not for me :/
<seb128> didrocks, do you want me to try to submit?
<didrocks> ok, ubuntu-bug unity FTW
<didrocks> seb128: that's fine, I workaround it :)
<didrocks> thanks!
<seb128> ok
<seb128> np ;-)
<didrocks> jono: if you want to track it, bug #1024459
<ubottu> Launchpad bug 1024459 in unity (Ubuntu) "panel and launcher blinks when using libreoffice spreadsheet" [High,Confirmed] https://launchpad.net/bugs/1024459
<jono> thanks didrocks
<didrocks> yw :)
<jono> didrocks, did you notice this with the spreadsheet?
<jono> it affects me in presenter
<didrocks> jono: yeah, I did in spreadsheet and presenter
<didrocks> I guess it's a general libreoffice issue
<didrocks> seems related to the menu, maybe a bad export or something
<didrocks> but unity should be stronger against those cases
<didrocks> jono: added that it affects also presenter
<jono> thanks didrocks
<Sargun_Screen> Anyone have any ideas about bug 957494?
<ubottu> Launchpad bug 957494 in mdadm (Ubuntu Precise) "Missing added utility 'mdmon'" [Medium,Triaged] https://launchpad.net/bugs/957494
<ev> mpt: yay foresight. I already have the data to hand for the per-problem graphs. This should be super easy.
<mpt> \o/
<Sargun_Screen> Is there a bzr branch for precise I can use the build the mdadm / mdmon package needed
<seb128> could somebody reject https://code.launchpad.net/~nik90/ubuntu/precise/totem/add_keywords_new/+merge/101209 ?
<stgraber> seb128: done
<seb128> thanks
<phoenix_firebrd> in the debian control file what should i put for section  for kmix?
<toabctl> phoenix_firebrd, imho "sound"
<ScottK> phoenix_firebrd: You shouldn't change what's already there.
<phoenix_firebrd> ScottK: "unknown" was in the section, so the package got rejected
<phoenix_firebrd> ScottK: sound works
<ScottK> phoenix_firebrd: We already have a package for kmix, so you don't need to make your own.
<toabctl> phoenix_firebrd, and "sound" is already in the debian/ubuntu package
<phoenix_firebrd> i am learning to package, so i have to learn a lot
<phoenix_firebrd> "File kmix_4.1-1.diff.gz already exists in Kde multimedia, but uploaded version has different contents" what does this mean?
<shadeslayer> hi! seems like opencv build depends on libtiff4 whereas libsane-dev will drag in libtiff5 which conflicts with libtiff4
<shadeslayer> could somone who has the appropriate upload rights fix this if s/he's around?
<xnox> mterry hallyn ^^^^
<xnox> shadeslayer: it's in progress http://people.canonical.com/~ubuntu-archive/transitions/tiff.html
<shadeslayer> awesome
<shadeslayer> a heads up on the Ubuntu Devel ML would have been nice though ;)
<cr3> if I have a package which contained a directory with files that was now changed to a symlink, it looks like upgrading the package is keeping the directory which is now empty :(
<dobey> cr3: i think you need to add a Breaks/Replaces, to fix that
<cr3> dobey: interesting, thanks!
<dobey> switching files between dir/file/link is hard. i /think/ breaks/replaces of the older version will fix it, but not totally sure
<cjwatson> no, dpkg will not switch between directory and link no matter what metadata you provide, quite deliberatelt.
<cjwatson> *deliberately
<cjwatson> you have to remove the old directory in the preinst.  for bonus points, handle rollback correctly.  I think there's an example in one of my packages somewhere - maybe groff or groff-base?
<seb128> those things are harder than they should be ;-)
<seb128> or aka "don't do that" ;-)
<seb128> (that being replacing a symlink with a dir with the same name)
<cjwatson> should be - matter of opinion.  the design decision in dpkg was that doing this automatically was too dangerous.
<seb128> (or the other way around rather)
<cjwatson> either
<alazare619_> anyone here have knowledge of why i cant get ubiquity-frontend-debconf to run from terminal?
<ogasawara> @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:
<mdeslaur> FYI, I'm going to attempt to get ruby-rspec-core merged with the insane circular build depends
<mterry> reportbug.debian.org is down  :(
<mterry> or at least not accepting my SMTP requests...
<hippiehacker> Is there a way to seed a ubuntu install in oem-mode to not download the language packs? If I disconnect the network, the install is great/fast, but if I leave it connected to the network, I have to wait while it downloads language packs I don't want/need
<phoenix_firebrd> i am getting build errors for a package in ppa
<phoenix_firebrd> https://launchpadlibrarian.net/110060774/buildlog_ubuntu-precise-i386.kmix_4.1-1_FAILEDTOBUILD.txt.gz
<JontheEchidna> the build-dependencies are pretty incomplete
<phoenix_firebrd> JontheEchidna: it builds locally
<JontheEchidna> you'd have the build-depends installed locally
<phoenix_firebrd> JontheEchidna: ya
<phoenix_firebrd> JontheEchidna: so what should i do next?
<cjwatson> hippiehacker: Preseed pkgsel/language-packs to the empty string.
<JontheEchidna> add the proper build-depends until it builds
<hippiehacker> cjwatson: thanks
<phoenix_firebrd> JontheEchidna: where?
<JontheEchidna> debian/control, in the Build-Depends field
<phoenix_firebrd> JontheEchidna: ok
<JontheEchidna> you could check the quantal package for kmix and check the build-depends there
<phoenix_firebrd> JontheEchidna: thats a good idea
<micahg> phoenix_firebrd: you can try backportpackage and see if that works as well
<phoenix_firebrd> micahg: ok
<hippiehacker> cjwatson: that worked, thanks => https://github.com/sputnik/sputnik-oem/commit/1152348e606154daf77409f227a1ae66d7736754
<hippiehacker> I take that back, it's downloading language packs still, is there something else in my config that would cause them to download?
<ScottK> mterry: Word is barry fixed it.
<cjwatson> hippiehacker: not sure at this time of night, sorry
<cjwatson> base-config/install-language-support <- question name obsolete for something like the last seven years.  Perhaps that should be pkgsel/install-language-support
<cjwatson> (and owner "d-i" not "base-config")
<cjwatson> other than that I guess I'd need a full debug log
<hippiehacker> cjwatson: I'll give it another go and try that
<alazare619_> im trying to build a ubuntu based distro from scratch im having 2 issues
<alazare619_> 1 i cant dd it to a jump drive the iso and 2 when its booting it stalls on waiting for network configuration anyone have any ideas?
<cjwatson> 1 sounds like you need to run isohybrid over the image
<cjwatson> 2 casper.log may help, if you can extract it
<cjwatson> and perhaps extract your initrd and the stock one and diff -ru them
<cjwatson> make sure you can explain all the differences
<alazare619_> also for some reason it wont boot straight to the live
<alazare619_> i have to enter in the ubuntu user name without a password
<alazare619_> any idea on that?
<cjwatson> not without logs :)
<cjwatson> but that stuff is configured by casper in the initrd, so perhaps caused by the same underlying mis-setup as 2
<alazare619_> ok well i have each step all documented i did
<alazare619_> theres not really any logs i did it all via debootstrap
<alazare619_> then cp over the resolv  conf
<alazare619_> chrooted in ran all the installs
<alazare619_> exited after removing resolv.conf and the tmp folder
<cjwatson> casper always writes a log as it boots
<cjwatson> Sounds like you haven't set up a proper live-capable initramfs; it's necessary to install casper and run update-initramfs in the chroot to generate one
<cjwatson> Although much easier to do it via livecd-rootfs + live-build
<cjwatson> (Or even just live-build on its own)
<alazare619_> cjwatson,  i keep having an issue with livecd-rootfs
<alazare619_> basically it just keeps failing to build the chroot
<alazare619_> without any modification it fails
<alazare619_> it trys to gzip intrid
<alazare619_> ok so i have to update-initramfs after casper and lupin-casper are installed?
<cjwatson> I can probably help with livecd-rootfs, but only if you give me a full transcript of exactly what you're doing and the exact text of the error messages
<cjwatson> I cannot help given only paraphrased summaries
<cjwatson> I would rather help with livecd-rootfs than help with doing all the same kinds of things by hand
<cjwatson> The latter will get very tedious very quickly
<alazare619_> http://pastebin.com/1rNNKkzS
<alazare619_> thats every command ive issued
<alazare619_> so maybe you can track it down
<alazare619_> ive tried doing it from scratch
<alazare619_> but i suppose i can reattempt livecd-rootfs
<alazare619_> only problem is i cant figure out how to make my own distro with it based on the fact it pulls in webseeds
<alazare619_> im working on a qt based respin of ubuntu
<cjwatson> I don't think I'm prepared to debug that enormous pile of stuff, sorry - it's not worth it
<cjwatson> You can always use live-build directly; it doesn't have any seed-specific logic in it
<alazare619_> live build fails on 12.04
<cjwatson> I don't believe that, as we built 12.04 images using live-build on 12.04
<cjwatson> live-build *with your configuration* fails on 12.04 :-)
<alazare619_> do you have a auto config build clean setup that i can use with a custom package list?
<cjwatson> That's kind of what livecd-rootfs is
<cjwatson> You can copy it and hack it if you like
<alazare619_> well i dont understand there "seed" files
<alazare619_> there not packagelists
<cjwatson> You don't need to
<cjwatson> The only stuff that pulls in Ubuntu seeds there (at least ignoring the preinstalled-pool stuff which is basically only used on ARM) is the stuff that calls add_task
<cjwatson> So just make that be add_package instead
<cjwatson> And disregard anything that refers to PREINSTALLED or similar
<cjwatson> add_package builds up a package-list for live-build
<cjwatson> If the first argument to it is install, it adds to the set of packages that are installed in the livefs and will be copied to the target system; if the first argument is live, it adds to the set of packages that are installed in the livefs but will be removed from the target system
<cjwatson> (target => on installation)
<alazare619_> ok so if i want to do a livecd-roofs build
<alazare619_> the first command would be export PROJECT=ubuntu SUITE=precise ARCH=i386 BINARYFORMAT=iso-hybrid
<alazare619_> but that then pulls in everything that is ubuntu
<cjwatson> You can just copy its auto/config script and edit it
<cjwatson> You don't have to symlink it
<cjwatson> That way it just gives you a starting point
<alazare619_> yea im working on it
<barry> ScottK, hippiehacker what did I fix? :)
<ScottK> barry: reportbug.  mterry was whining about it earlier.
<barry> ah, no it was a temporary outage.  bzed said they were moving the server.  but it's back now (though i have not gotten the email response to a bug i filed a couple of hours ago)
<alazare619_> http://pastebin.com/ET9JdtP8
<alazare619_> cjwatson,
<alazare619_> thats the area i modified
<alazare619_> seems about right
#ubuntu-devel 2012-07-14
<cjwatson> alazare619_: You're missing an "install" or "live" as the first argument to add_package.
<cjwatson> alazare619_: See my explanation above.
<cjwatson> The rest looks OK.
<alazare619_> so live add_package install then the rest?
<alazare619_> ok im running a test
<alazare619_> but i know its going to fail eventually
<cjwatson> Just "add_package install", not "live add_package install"
<alazare619_> yea thats what i figured
<alazare619_> refrenced xubuntu's setup
<cjwatson> Like the way it's "add_task install ..." just above
<alazare619_> yea
<alazare619_> now how can i pass a extra repository over with the auto?
<cjwatson> Write a file to config/archives/<some name>.chroot.list, and also to config/archives/<some name>.binary.list if you want it in the running live environment as well as during the build
<cjwatson> sources.list format
<phoenix_firebrd> the package was successfully built thank you JontheEchidna  and micahg
<micahg> phoenix_firebrd: if it works unchanged, you can request an official backport with requestbackport
<phoenix_firebrd> micahg: i changed the dependencies
<phoenix_firebrd> micahg: i am new to ppa, just learning and testing
<micahg> phoenix_firebrd: ah, it's part of the KDE release, I thought it was just a leaf app
<phoenix_firebrd> micahg: ya
<alazare619_> is there a way cjwatson  to add that to the auto script?
<alazare619_> for config
<cjwatson> alazare619_: Sure, just use echo or cat - there's at least one example in the existing script I think
 * cjwatson -> bed
<alazare619_> ok i was thinking an end of script style but just basic shell works?
<alazare619_> hey cjwatson building fails with livecd-rootfs
<alazare619_> when i use precise
<alazare619_> it fails at
<alazare619_> P: Begin installing syslinux...
<alazare619_> cp: cannot stat `/usr/share/syslinux/themes/ubuntu-oneiric/isolinux-live/*': No such file or directory
<alazare619_> syslinux doesnt even install there
<alazare619_> cjwatson, you around these parts still?
<alazare619_> guess not
<alazare619> http://pastebin.com/1LrKbNuP
<alazare619> live build seems to fail with livecd-rootfs
<alazare619> at a line saying initrid is not in gzip when its set to lzma mode
<alazare619> im using the newest live-build and its not creating binary/isolinux
<cjwatson> alazare619: install syslinux-themes-ubuntu-oneiric
<cjwatson> alazare619: that's a bug in live-build when you use both --initramfs-compression lzma and --binary-images iso/iso-hybrid/usb; I suggest you just drop --initramfs-compression lzma for now, as the extra space saving probably isn't critical for you
<cjwatson> definitely something we should fix though
<bashed> How does ubuntu recommend you the name of the uninstalled package that you are trying to run a binary off?
<penguin42> bashed: It's the command-not-found package
<penguin42> bashed: There is a bit of magic at the end of /etc/bash.bashrc that seems to glue it in
<bashed> penguin42: Thanks a lot, thats what I needed to know.
<alazare619> hey cjwatson ok well i dropped the initramfs compression lzma and im still having an issue with failure to lzcat
<alazare619> cjwatson, i change compression to none should it just be empty instead?
<hippiehacker> alazare619: what commands are you issuing to create the image? are you starting with an empty directory?
<hippiehacker> https://answers.launchpad.net/ubuntu/+source/live-build/+question/200206
<hippiehacker> particularly the bit about https://gist.github.com/2978542 where I quickfix the compression in initrd. But I was still unable to get it to work
<cjwatson> alazare619: Just don't pass that option at all.
<hippiehacker> cjwatson: could you take a look at https://answers.launchpad.net/ubuntu/+source/live-build/+question/200206 ... I've tried using the bzr branches you mentioned, but http://bazaar.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu/view/head:/debian/changelog has errors when I try to run dpkg-buildpackage against it
<cjwatson> hippiehacker: I wouldn't expect dpkg-buildpackage to work
<cjwatson> We just run it straight from the bzr branch
<cjwatson> Afraid I don't have time for anything more detailed right now ...
<hippiehacker> cjwatson: no prob
<hippiehacker> I was just not sure what to do with the repos and guessed
<alazare619> cjwatson, u around?
<infinity> bdrung: Dangit, you're going to make me upgrade all my development machines to quantal now? :P
<infinity> bdrung: (Or I back out that devscripts change locally...)
<slangasek> yerp
 * infinity also notes that he entirely missed that bug being assigned to him.
<infinity> My bugmail filters might need twiddling.
<infinity> slangasek: How was the trip home?
<slangasek> infinity: it's quite nice
<slangasek> Internet at 30,000 feet is the only way to travel
<infinity> Well, aren't we fancy?
<infinity> I travel over land so infrequently that I don't get to do such things often.
<slangasek> welcome to the future :)
 * slangasek nods
<cjwatson> phew, the jenkins desktop tests this morning seem to have come through unscathed
 * cjwatson utters a cautious and muted yay
<infinity> Well, that's firefox and thunderbird fixed on armel.  That seems like enough work for a Saturday.
<penguin42> what was up with them?
<tumbleweed> infinity: was it rolled into the new upstream firefox releases that appeared minutes later?
<infinity> penguin42: Generating armv7 code for an armv5 target.
<Laney> that old chestnut
<penguin42> infinity: What in?
<infinity> tumbleweed: Hrm?
<tumbleweed> https://launchpad.net/ubuntu/+source/firefox/14.0.1+build1-0ubuntu1
<infinity> penguin42: skia.
<infinity> tumbleweed: Oh, bah.
<infinity> tumbleweed: So, uhm.  No. :P
<tumbleweed> so, fixed for 5 minutes :)
 * penguin42 assumes my ARMv7 specific patch has been removed from the ubuntu libc
 * infinity fixes that, and pokes chrisccoulson
<infinity> penguin42: ?
<penguin42> infinity: I had an optimised one of the string routines (can't remember which) that landed in the ubuntu packages before being upstreamed
<penguin42> infinity: It wasn't ARMv5 safe at the time it went into the ubuntu package, but was by the time it went upstream
<infinity> penguin42: Oh, I fixed that, yeah.
<chrisccoulson> huh?
<infinity> penguin42: :
<infinity>   * arm/local-linaro-cortex-strings.diff: instead of sysdeps/arm, apply
<infinity>     to sysdeps/arm/eabi/armv6t2, as it implements routines that aren't
<infinity>     supported on old CPUs, and drop memchr.S half of the patch, in
<infinity>     favour of the version that's been submitted and accepted upstream.
<infinity>   * Make the strchr.S implementation above stop forcing armv7-a, since
<infinity>     it works on armv6t2, and moving the path enforces this during build.
<infinity> chrisccoulson: Oh, we just collided.  I uploaded armel fixes for tbird/ffox minutes before you uploaded a new upstream. ;)
<penguin42> infinity: Ah good
<penguin42> infinity: I don't envy the job of getting stuff to work on v5 again  - you're going to end up tripping over Qt, and loads of stuff
<infinity> penguin42: Most of it's reasonably happy right now.
<infinity> penguin42: Though, to be fair, I haven't done any runtime tests on v5 hardware or full-archive instruction scans to see what breakage is leaking through unnoticed.
<infinity> One step at a time, though.
<chrisccoulson> seriously? i need to review those. in addition to that, they need to be in bzr (and committed first to the nightly branch, else i have a serious headache keeping track of which of the 24 packaging branches we have for firefox and thunderbird that particular fixes are in)
<chrisccoulson> especially this week, when we're in the middle of rebasing all of the branches for the next 6 week release cycle
<chrisccoulson> well, we -> I
<infinity> chrisccoulson: Do I have commit access to these mystical branches?
<infinity> chrisccoulson: Or do you just want to review and apply my two ubuntu1->ubuntu2 diffs and go from there?
<infinity> chrisccoulson: (I'm happy to reupload them right now, and you can do with them as you please after that)
<infinity> chrisccoulson: Both are appropriate for backporting all the way to lucid, so no patches/series magic mangling required.
<chrisccoulson> infinity, they need to go to lp:firefox first (assuming they're not already fixed in mozilla-central), and then i can cherry pick patches to older branches (such as the one that quantal is based off) if they're needed
<infinity> chrisccoulson: lp:firefox doesn't seem to contain tbird, unless I'm blind.
<chrisccoulson> this week, lp:firefox/aurora will be rebased on lp:firefox, lp:firefox/beta will be rebased on lp:firefox/aurora and then lp:firefox/beta will be uploaded to quantal
 * infinity assumes there's an lp:thunderbird, and checks.
<chrisccoulson> so anything committed inbetween is likely to get lost along the way ;)
<chrisccoulson> infinity, yeah, there is a lp:thunderbird
<infinity> chrisccoulson: Alright, and the origs that match those are in the PPA?
<infinity> Hrm, or not.
<infinity> Or, rather, not in the daily ppa...
<infinity> chrisccoulson: Where do I find the orig to match these bzr debian directories?
<chrisccoulson> infinity, you can use that branch with the tarballs in the daily PPA if you just update the version number in the changelog
<infinity> Oh, I guess the firefox one is close to matching anyway, just not the tbird one.
<infinity> But making sure my patches still apply against 16ish is handy, I guess.
<infinity> For the record, your workflow is pretty contribution-hostile. :P
<chrisccoulson> my workflow is more aligned with the upstream release process
<chrisccoulson> and complicated by the fact that there are 24 packaging branches to juggle fixes between ;)
<chrisccoulson> infinity, so, https://bugzilla.mozilla.org/show_bug.cgi?id=751814 is already fixed upstream in what will be the next upload to quantal
<ubottu> Mozilla bug 751814 in Graphics "[Skia] Fixes for ARMv6+ and ARMv4T" [Normal,Resolved: fixed]
<infinity> chrisccoulson: Mmkay.  I'd still like to fix it now in the 14 version, unless the new upstream is "right nowish".
 * Debolaz gets all giddy every time he looks at the plans for wayland.
<chrisccoulson> infinity, the first 15.0 beta is next week
<infinity> chrisccoulson: The no_neon patch still applies, so I'll commit that to bzr.
<chrisccoulson> infinity, what's the upstream bug number for that?
<infinity> Haven't filed one yet, since that "fix" is clearly wrong for upstream.
<infinity> Just right for us.
<chrisccoulson> hmmm, i don't like the sound of that at all
<infinity> *sigh*
<infinity> We don't enable NEON by default, ever.
<infinity> Upstream has a test for it.  Which is also wrong.  It should be a configure option, like all their other optimisations.
<infinity> But, for us, it was simple to just remove the check for it, which DTRT.
<chrisccoulson> so, this is effectively going to become a permanent patch?
<infinity> No, I'll work with Mike on upstreaming something more suitable.
<infinity> Just not Right Now(tm).
<chrisccoulson> hmmm, ok. IME, people commit patches, forget about them and then we end up carrying them for years ;)
<jtaylor> I don'T know the context but you have neon enabled fftw3 in quantal now though its runtime detected
<infinity> Well, if that happens, this isn't exactly an onerous patch to maintain.
<infinity> But bug me about it if I forget and it annoys you.
<jtaylor> I guess thats fine?
<infinity> jtaylor: runtime detection is lovely.
<infinity> jtaylor: compile-time is broken.
<infinity> jtaylor: (No different from the situation for, say, SSE on i386)
<chrisccoulson> infinity, ok. i'll just add it to the nightly and aurora branches now then, and it will be in the next quantal upload
<infinity> chrisccoulson: Oh, I was just about to commit. :P
<chrisccoulson> did it need any changes?
<chrisccoulson> oh
<infinity> chrisccoulson: (After testing it still applied and maybe jiggering for offsets, cause I'm anal)
<chrisccoulson> i'm not sure core-dev can commit to that branch. i was going to fix that at some point
<infinity> I guess I'll find out. :)
<infinity> You could add me to the team that can, though. :P
<chrisccoulson> 1 second, daughter number 1 seems to be waking
<chrisccoulson> ah, this is going to be a fun night
<chrisccoulson> infinity, ok, added ;)
<chrisccoulson> infinity, if you just commit to lp:firefox and lp:thunderbird then, i will merge that changeset to lp:firefox/aurora and lp:thunderbird/aurora
<chrisccoulson> (unless you want to do that)
<infinity> chrisccoulson: Alright, committed to both.  Other than buildd resources (which tends to be my complaint about you, not the inverse), do you have any issues with me also doing an out-of-band upload of 14.x to quantal to fix things right now?
<infinity> chrisccoulson: You can do the merging magic to aurora, I assume that workflow's muscle memory for you. :)
<chrisccoulson> infinity, in general, i avoid out-of-band uploads with fixes for non-primary architectures for a couple of reasons in addition to buildd resources. the first one is update fatigue, and the second one is that the build triggers a reupload of our breakpad symbols to mozilla's server
<chrisccoulson> which means we use additional storage on their server
<alazare619> cjwatson, you around
<infinity> chrisccoulson: I assume they have garbage collection of some sort...
<infinity> chrisccoulson: (That's a pretty weak argument for keeping things broken)
<alazare619> http://pastebin.com/2LLw1PuE
<alazare619> im trying to edit the live-build script so it copys the initird and vmlinuz to the name vmlinuz and initrd.lz
<alazare619> any idea what i have wrong
<alazare619> its returning target is not a directory
<chrisccoulson> infinity, well, i don't consider update fatigue to be a weak argument. it's basically a 400MB update for people like me with debug symbols installed, and that's pretty hefty for an update which doesn't fix anything on the architecture i'm using (or any of the primary architectures) ;)
<infinity> chrisccoulson: No, I suppose not, but two uploads in rapid succession should mean that most people never see the one in the middle, unless they update every hour.
 * infinity shrugs.
<chrisccoulson> i don't mind, but i generally try to keep the number of uploads to a minimum :)
<infinity> chrisccoulson: To be fair, this *does* fix something on a supported arch as well (armhf also shouldn't have NEON on), if you want to pull the supported/primary card.
<chrisccoulson> ah, ok
<chrisccoulson> i didn't realize thats
<chrisccoulson> **that
<chrisccoulson> so, feel free then ;)
<alazare619> could anyone refrence the pastebin please and offer some guidance i copied the 3 lines that involve copying from the chroot the init and placing a copy in /binary/casper/
<alazare619> but i cant rename that file
<infinity> chrisccoulson: Right, uploaded.
<alazare619> gives me directory does not exist when doing the mv command
<chrisccoulson> thanks
#ubuntu-devel 2012-07-15
<Debolaz> If I want to set aside a few hours each week contributing to Ubuntu, which areas are in the most need of help? I know most technical things to an acceptable level and don't mind learning.
<alazare619> http://pastebin.com/2LLw1PuE
<bretth> is libwebkitgtk-3.0.so on Ubuntu12.04 not built with wegGL support?
<alazare619> how do you call a chroot-hack from livecd-rootfs scripts?
<micahg> bretth: no, it's not
<bretth> micahg, too bad, it would be better to have webgl by default.
<Cleitus> i'm a guy with interest in programming and love to develop for linux or android platforms can anyone give me suggestions
<DktrKranz> infinity: re your r-base_2.15.1-1ubuntu1 upload, do you know whether the POSIX estended breakage on ARM is tracked somewhere (bug reports, mailing lists, whatever) ?
<cousteau> fact 1:  Flash is going to stop being supported for Linux
<cousteau> fact 2:  the only way to use newer Flash versions on Linux will be using Chrome
<cousteau> fact 3:  Firefox is the default browser in Ubuntu (and even if it weren't, the user should be able to use whatever browser they want, not a specific one only because of this sort of things)
<cousteau> fact 4:  my own experience tells me that Flash runs better on Wine than natively (at least older versions; not sure now)
<cousteau> idea:  would it be possible to develop a Wine-based wrapper for Adobe Flash (and maybe Shockwave)?  This would not only provide an alternative for those who want to use Flash but also work better than the native one.
<cousteau> (as far as I know Google does this sort of things with Google Earth and similar)
<infinity> DktrKranz: I haven't filed bugs yet, I was planning to work on it at some point.  But maybe I should just file a Debian bug when I get home, so I don't forget.
<ramona> does any one have any problems with javaws in ubuntu 12? Java applets runs terribly slow on my machine
<ramona> they run fine in windows
<cousteau> maybe because of openjdk/oracle differences
<ramona> cousteau, I tried both openjdk and oracle
<cousteau> maybe video card or graphic acceleration issues?  (no idea what else could be...  then again I'm no expert)
<ramona> cousteau, It used to run fine on 10.04
<bencer> quick question, i'm preparing a SRU, LP doesn't allow me to upload a package with target precise-proposed, how should i proceed with that?
<Laney> in what way does it not allow this?
<bencer> Laney: LP rejects the target
<bencer> Laney: when uploading to my PPA
<Laney> not sure proposed exists for PPAs
<bencer> Laney: should i upload with precise target and thats it?
<Laney> bencer: yeah. if you need extra build-dependencies from proposed then you can configure the ppa to give those
<bencer> not really, okey
<bencer> thx
<bdrung> infinity: yes. eat your own dogfood! ;)
<bdrung> infinity: you can backport the latest devscripts version and still get an unchange default distribution. :P
<bdrung> infinity: was it okay that i stole your bug task?
#ubuntu-devel 2013-07-08
<siretart> mdeslaur: FYI: I've released libav 0.8.8 and libav 9.8 yesterday night
<glitchd_> hello all
<dholbach> good morning
<mwhudson> turning a pile of .deb files into something i can point apt-get at means apt-ftparchive, right?
<rbasak> mwhudson: right
<dholbach> hey mvo, do you think you could take a look at lp:~evfool/update-manager/lp1079136?
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: dholbach
<mwhudson> rbasak: i even made it work!
<mwhudson> unfortunately the packages i built are for raring and i'm trying to install them on quantal...
<rbasak> mwhudson: sbuild is your friend :)
<dholbach> can somebody please reject https://code.launchpad.net/~malizor/ubuntu/saucy/ubuntu-wallpapers/fix-for-1177260/+merge/171911?
<mvo> dholbach: sure!
<dholbach> thanks mvo
<dholbach> mvo, lp:~dylanmccall/update-manager/dialogs-refactor too please :)
<seb128> dholbach, mvo: good morning my german friends, how are you?
<dholbach> doing well - how about you?
<seb128> I'm good thanks, summer finally arrived!
<mvo> hey seb128! I'm good, how are you?
<seb128> mvo, I'm good thanks ;-)
<seb128> mvo, do you have months of holidays for summer break like student? ;-)
<seb128> mvo, oh, the internet says it's not summer break in germany yet ... that just started in France
<Laney> haha, for staff at universities that is when the real work happens
<seb128> I see :p
<seb128> dholbach, that gconf sync request is buggy, you can invalid it
<dholbach> seb128, it could be changed to be a merge(?)
<seb128> yes
<dholbach> not sure if obounaim is up for that though
<seb128> though I wouldn't trust somebody who overlooked most of the work to do this merge correctly...
<seb128> I will review it if he does it
<seb128> let's see ;-)
<dholbach> done
<mvo> seb128: yeah, no holidays for me :(
<seb128> mvo, :-(
<devinceble>  Does qtdeclarative5-hud1.0 library present on 13.04 or 13.10 only?
<Noskcaj> what do i do for a needs packaging bug that already has a .deb file automatically made
<smb> Are the problems with the time&date and privacy (at least) settings dialogues in S already known? Those seem to be unusable right now.
<marga> ev, I'm having issues with whoopsie in precise, which is getting re-installed even though I had previously removed it, likely due to a new ubuntu-desktop release.  The issue is that both installing and removing the package crash my X session.  I've narrowed it down to the user adding/deleting, and I suspect this is due to the /var/crash handling.
<marga> ev,  I checked the bugs, expecting this to be reported, but it's not, so I'm unsure if it's something specific to my setup, or so recent that nobody else has seen it/identified it yet.
<marga> Just adding the user with the command line in the postinst script crashes my session...
<ev> marga: that sounds like something is demonstrably broken in your setup. Calling adduser shouldn't bring down your X session.
<ev> And if it does, the bug definitely isn't in whoopsie.
<yofel> hi, is there someone that knows why gdk_x_error() is fatal?
<yofel> Context: bug 1195007 is a nasty SRU regression in raring for KDE applications running under Unity/Gnome caused by the fix for bug 1180067
<yofel> I'm kinda lost on what the proper way to resolve this would be.
<ubottu> bug 1195007 in kile (Ubuntu) "kile crashes when click on "file new + save"" [Medium,Confirmed] https://launchpad.net/bugs/1195007
<ubottu> bug 1180067 in qt4-x11 (Ubuntu Raring) "No icons on buttons" [High,Fix released] https://launchpad.net/bugs/1180067
<marga> ev, you are right.  I just tried it and adding or removing any users kills my X.  So it's not whoopsie.  Sorry for the false ping.
<ev> no worries
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
 * ogra_ hugs dholbach 
 * dholbach hugs ogra_ back :)
 * smb is grumpy finding Saucy's workspace moving keybindings gone random this morning
<cjwatson> yay, glatzor is some kind of superstar.  (example patch for packagekit click backend; will need work but it's a lot easier to iterate on a patch)
<dholbach> that's awesome :)
<cjwatson> and reminds me that I need to ask for a new mime type
<mdeslaur> siretart: great, thanks!
<hallyn_> SpamapS: could you please accept https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=qemu-kvm ?
<xnox> cjwatson: apachelogger reports that SRU bug 1180067 has caused a regression in raring, see last comment on that bug report.
<ubottu> bug 1180067 in qt4-x11 (Ubuntu Raring) "No icons on buttons" [High,Fix released] https://launchpad.net/bugs/1180067
<Riddell> !regression-alert
<cjwatson> xnox: OK, not sure I can do a whole lot just at the moment, needs somebody who knows more about it to assess it
<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
<Riddell> mitya about?
<Riddell> xnox: do you know when he's normally on?
<ScottK> Riddell: he's on vacation this week, IIRC.
<Riddell> ah
<Riddell> I think I'll just upload it with the patch reverted and let mitya fix it when he's back
<Riddell> fix isn't super important but regression is
<xnox> Riddell: it might be a one-liner fix: http://lists.freedesktop.org/archives/libreoffice/attachments/20120618/582fd1dd/attachment-0001.obj
<xnox> this should cause gtk/gdk to ignore all X errors.
<xnox> Riddell: but then again, we need to fix it in saucy as well.
<ScottK> xnox: I think the SRU regression is more important for the moment.
<xnox> Riddell: apachelogger: ScottK: Looking at other uses of gtk_init in qt4, shows that Xerror handler is stored before calling gtk_init, and reset back after. Thus the patch to fix the regression is something like this:
<xnox> http://paste.ubuntu.com/5855413/
<xnox> not tested yet, building.
<apachelogger> xnox: makes sense
<Riddell> ScottK: I uploaded qt without the patch to revert bug 1180067 , you could let it through now if you have a moment and we could delete it if xnox gets his patch to work
<ubottu> bug 1180067 in qt4-x11 (Ubuntu Raring) "No icons on buttons" [High,Fix released] https://launchpad.net/bugs/1180067
<seb128> Riddell, ScottK, xnox: if any of you feels like doing some qt sponsoring, Mirv was looking for someone to sponsor the saucy qtdeclarative waiting in the sponsoring queue
<Riddell> seb128: ok can look
<seb128> Riddell, thanks
<xnox> Riddell: ScottK: i think raring-updates revert should be published, and my fix should be tested/bake in saucy and can go through as a normal SRU for raring.
<ScottK> Sounds reasonable.
<ScottK> I just accepted the revert.
<xnox> I'm using bug #1195007 as the regression report of bug #1180067
<ubottu> bug 1195007 in qt4-x11 (Ubuntu) "kile crashes when click on "file new + save"" [High,Confirmed] https://launchpad.net/bugs/1195007
<ubottu> bug 1180067 in qt4-x11 (Ubuntu Raring) "No icons on buttons" [High,Fix released] https://launchpad.net/bugs/1180067
<ScottK> OK.
<xnox> ev: bdmurray: did / would have errors noticed above regression ^ sru released on 1st of july of qt4-x11, causing rdepends to crash a lot.
<bdmurray> xnox: I'll have a look
<SpamapS> hallyn_: done
<hallyn_> SpamapS: lol!  i had actually *just* decided to re-upload with another fix in it.  But cool, will wait for this one to clear - thanks!
<SpamapS> hallyn_: You LOSE. You get NOTHING. GOOD DAY SIR.
<hallyn_> SpamapS: ?
<SpamapS> hallyn_: not a wonka fan eh?
<hallyn_> sorry, haven't seen it.
<hallyn_> might have to one of these days.
<infinity> rbasak: Hrm.  Someone's going to want to backport this golang 1.1 to older releases, aren't they? :/
<infinity> rbasak: Which means I either need to backport my dpkg patch, or make golang *also* add the arch tags.  Bother.
<SpamapS> hallyn_: oops, I forgot to actually hit "accept" on qemu-kvm .. so it is just now going through ;)
<plars> cjwatson: you mentioned to me a while back that you had a patch to apt to give better debugging of the "something wicked happened" errors, that hasn't made it into saucy yet?
<cjwatson> plars: It's in Debian unstable, I think pending a merge
<cjwatson> Don't know what mvo's plans are there
<ricotz> infinity, hi :)
<ricotz> infinity, it is worth you simply retry https://launchpad.net/ubuntu/+source/llvm-toolchain-3.3/1:3.3-3 or would you expect it to fail again?
<infinity> ricotz: It'll fail again.
<Sarvatt> ^ builds fine on raring, gcc-4.8 fun?
<ricotz> it builds on raring without gold though
<infinity> So, stop using gold.  We don't use it for 3.2
<Sarvatt> ah right, just noticed that
<ricotz> infinity, debian introduced it for speed matters
<infinity> ricotz: Sure, and we unintroduced it.  I just haven't gotten to 3.3 yet.
<infinity> ricotz: Is there some urgency in making 3.3 happy?
<ricotz> infinity, alright
<ricotz> we want to use it in xedger's mesa
<Sarvatt> just mesa git snapshots in a ppa but we can just shove an updated llvm-3.3 in that
<infinity> Ugh.
<infinity> Does mesa require 3.3? :/
<Sarvatt> yep!
<infinity> How lovely.
<Sarvatt> hell, it'll probably require 3.4 by release in august and we'll have to disable features or add git crap to llvm again like what happened with 3.2..
<ricotz> Sarvatt, llvm-3.4 is in saucy too ;)
<infinity> Oh, hrm.  That PPC failure is curious, given that it worked on Debian.
<infinity> Where did my atomics go in gcc-4.8 on PPC?
<infinity> doko: ^
<smartboyhw> When does patch pilots go on duty? (Just asking)
<smartboyhw> s/does/do
<infinity> smartboyhw: When they feel like it.
<smartboyhw> infinity, :O
<infinity> smartboyhw: We're scheduled by day, ish, but each pilot only puts in a 4h shift (again, ish), and not at a specific time.
<doko> infinity, ?
<infinity> doko: https://launchpadlibrarian.net/143949118/buildlog_ubuntu-saucy-powerpc.llvm-toolchain-3.3_1%3A3.3-3_FAILEDTOBUILD.txt.gz
<infinity> doko: That doesn't happen in Debian.
<infinity> doko: Did g++-4.8 do something vile to PPC atomics?
<doko> not that I do know. the atomics lib shouldn't be needed on ppc
<bdmurray> barry: did you see the regression autocomment in bug 1058884?  It seems unrelated to me.
<ubottu> bug 1058884 in python3.3 (Ubuntu Raring) "Race condition in py_compile corrupts pyc files" [High,Fix committed] https://launchpad.net/bugs/1058884
<barry> bdmurray: looking
<barry> bdmurray: it could be related
<ricotz> infinity, btw, llvm-3.3 is missing the symlinks added in llvm-toolchain-3.2 (1:3.2repack-7) too :\
<xnox> infinity: building android with modern gcc & glibc results in: http://paste.ubuntu.com/5855986/
<sarnold> xnox: in my x86_64-linux-gnu/sys/ucontext.h the REG_EBP is protected by #ifdef __USE_GNU
<xnox> sarnold: yeah, defined, just before including ucontext.h.
<sarnold> xnox: ah :/ good luck :)
<xnox> sarnold: infinity: http://paste.ubuntu.com/5856022/
<xnox> what's wrong? =)))
<tvoss> slangasek, ping
<mdz> cjwatson, kees, pitti, soren, stgraber: TB in 2 minutes?
<cjwatson> yep
<stgraber> yep
<soren> mdz: Absolutely.
<cjwatson> have small child in lap, will see what I can manage
<cjwatson> but he seems to have just gone to sleep ...
<mdz> looks like we'll manage a quorum
<cjwatson> no sign of Rick to talk about the series alias thing though
<xnox> sarnold: "Adding the #define before stdio.h does not help, as stdio.h includes features.h which undef __USE_GNU" stckoverflow win =) will apply the fix tomorrow, enough of this for today. So the answer is #include <stdio.h> \n #define __USE_GNU
<cjwatson> huh?
<cjwatson> no
<cjwatson> #define _GNU_SOURCE
<cjwatson> you're not meant to define __USE_GNU directly - define _GNU_SOURCE instead and you should be fine
<cjwatson> and do so at the very top of the file, before any other preprocessor tokens
<cjwatson> stackoverflow is wrong in this case :)
<xnox> cjwatson: well that doesn't work.
<cjwatson> I've used _GNU_SOURCE a lot, it certainly works in general.
<xnox> never mind, it does with "-m32"
<xnox> cjwatson: now I wonder, why android went for __USE_GNU instead of _GNU_SOURCE.
<sarnold> xnox: oh! excellent :)
<xnox> sarnold: but, moving the guards to the beginning of the file and #defining _GNU_SOURCE as per cjwatson works better.
<xnox> Quote of the day: "Don't ever define __USE_GNU directly" From: Jakub Jelinek
<sarnold> ooh
<sarnold> that sounds like a good one to remember. :)
<xnox> http://gcc.gnu.org/ml/fortran/2005-10/msg00365.html
<ubottu> gcc.gnu.org bug 2005 in c++ "loop in gcc when function has const additional" [Normal,Resolved: fixed]
<manish> ev: ping. please check your mail
<slangasek> tvoss: pong
<slangasek> bdmurray: what's the best data source nowadays for information about whether users (as a whole) are using binary vs. free drivers?
<bdmurray> slangasek: I'm not sure off the top of my head
<slangasek> bdmurray: well, what are our options?  The information is in bug reports, right, but I guess that's heavy to query in aggregate... and there's also Ubuntu Friendly which would have something
<olli> bdmurray, I assume (would have to do an install myself to verify) that we don't collect HW information during install?
<bdmurray> olli: right we do not
<olli> bdmurray, oki
<olli> do you know whether we can create some insight when looking at the archive & mirrors? might be too cluttered as well I suppose
<bdmurray> olli: what is the question you are trying to answer?
<olli> bdmurray, :)
<cjwatson> you could ask IS for relative stats of some selected package; I don't know how helpful they'll be since installed doesn't say much about whether it's in use
<cjwatson> *packages
<cjwatson> and indeed we often end up installing more hardware support than is used on a given machine
<cjwatson> while it's a sort of odd application, this could be minable from errors.u.c, which would be easier to query in aggregate than bug reports
<cjwatson> sounds like an interesting use case for ev's "let developers write hadoop jobs" thing
<cjwatson> of course that's skewed, it only tells you what *broken machines* use
<slangasek> in the case of the binary drivers, they definitely don't get installed unless selected for use
<bdmurray> I'm not certain that errors has the right apport data for that either
<cjwatson> right - but you can switch back to something else later and I don't think they get uninstalled
<slangasek> they do
<cjwatson> oh, all of them?  I thought that was just the gl driver
<slangasek> well, we're only talking in the context of X drivers, sorry if that wasn't clear
<cjwatson> but ok, if so then IS *might* be able to get something off mirrors
<slangasek> X/gl/video
<bdmurray> oh, I guess errors has NonfreeKernelModules which may help
 * slangasek nods
<olli> sorry, didn't see the last comment and http://irclogs.ubuntu.com/2013/07/08/%23ubuntu-devel.txt isn't up to date
<olli> major brownout here
<slangasek> olli: 14:10 < bdmurray> oh, I guess errors has NonfreeKernelModules which may help
<olli> ah
<olli> cool
<bdmurray> well, looking further something is awry
<bdmurray> http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/saucy/apport/saucy/view/head:/apport/report.py#L312
<bdmurray> I don't see it in precise either...
<slangasek> bdmurray: the conspicuous absence of the bit that sets the field?
<bdmurray> slangasek: right
<olli> :)
<slangasek> I'm sure I've seen that recently in bug reports, though
<slangasek> bdmurray: data/general-hooks/generic.py
<slangasek> add_info() ?
<bdmurray> ah, great
<Selling_FDhypno_> superaffordable erotic hypnosis anyone? :)
#ubuntu-devel 2013-07-09
<psusi> bug #1198846 complains that if you have both the dvd and usb installation media present, the system mounts the usb instead of the dvd when you ask the bios to boot the dvd.  my first instinct was to close this as not a bug but it has "OEM Priority Project" tasks.  what exactly does that mean?  someone is paying Canonical to do something about this?  so should I leave it alone then?
<ubottu> bug 1198846 in grub2 (Ubuntu) "[efi boot to unexpected media] plug in live usb and DVD at the same time, try to boot from DVD but it comes to usb" [Undecided,New] https://launchpad.net/bugs/1198846
<ScottK> psusi: All it means, AIUI, is that it affects something Canonical OEM services is doing.  Hard to say exactly what.
<ScottK> I don't think you should triage the Ubuntu bug task any differently than you normally would.
<slangasek> agreed; if it needs to get escalated within Canonical to fix it, that's not something you should need to worry about
<slangasek> and in the first instance, if the community devs think it's a wontfix issue, you shouldn't hesitate to mark it as such
<psusi> cool
<Noskcaj> roaksoax, kirkland: ping (
<Noskcaj> Logan_, about bug 1185765 ...
<ubottu> bug 1185765 in Ubuntu "[needs-packaging] multibootusb" [Wishlist,Fix released] https://launchpad.net/bugs/1185765
<roaksoax> Noskcaj: pong
<Noskcaj> roaksoax, a few thing: 1. the description of testdrive is very outdated on the lp page. 2. It seems installing testdrive from source doesn't work. 3. Find some time for a testdrive hackfest, please.
<Noskcaj> mostly number 1
<smartboyhw> roaksoax, and plz, do give us a wiki page or something to teach people how to hack on Testdrive.
<Noskcaj> +1 to that.
<Noskcaj> that's pretty much my goal for a hackfest day
<Noskcaj> he ran away again, didn't he.
<smartboyhw> Noskcaj, where the hell is multibootusb in Ubuntu/
<smartboyhw> ?
<Noskcaj> "apt-cache search multibootusb" gives the result: multibootusb - Multiple live linux on USB.
<smartboyhw> Noskcaj, hah?
<smartboyhw> I don't get it here
<smartboyhw> * can't
<Noskcaj> dam, it's just a broken repo on my PC
<smartboyhw> Noskcaj, can you please confirm if you enabled https://launchpad.net/~upubuntu-com/+archive/ppa ?
<smartboyhw> Noskcaj, so, it doesn't exist, please package it
<smartboyhw> :P
<Noskcaj> yeah, that's what it was. i'm working on it now
<smartboyhw> Noskcaj, great:)
<smartboyhw> Shouldn't be very difficult I hope:)
<Noskcaj> what do i do is a program i'm trying to package already has a .deb?
<Noskcaj> roaksoax, one other thing. the testdrive .dsc file isn
<smartboyhw> Noskcaj, well, you still have to package it even if it has a deb
<Noskcaj> 't lintian clean
<smartboyhw> Noskcaj, lintian clean is rather difficult you know:P
<smartboyhw> We try to make it lintian clean
<Noskcaj> all i know is an error appeared
<smartboyhw> Noskcaj, what's the lintian message?
<Noskcaj> W: testdrive source: out-of-date-standards-version 3.9.3 (current is 3.9.4)
<Noskcaj> looking at the lintian website, it looks like a fairly easy fix
<smartboyhw> Noskcaj, ah, simple
<smartboyhw> Noskcaj, wait till the next feature upload will be better
<Noskcaj> ok
<roaksoax> Noskcaj: lintian clean doesnt mean theres no lintisn warnings or stuff
<Noskcaj> ok, i'm new to this
<roaksoax> Noskcaj: no worries. you will gain more experience with prsctice.
<roaksoax> yhe error of testdrive 3.20 is because of pygobject
<roaksoax> idk whether its upstream or testdrive issue
<roaksoax> but it hsppenend sfter tje upgrade of libraries
<roaksoax> Noskcaj: could you please file bugs thatd easier for me to track
<Noskcaj> roaksoax, ok.
<smartboyhw> Noskcaj, I'm thinking of the multibootusb package, how will you filll in the copyright file?
<smartboyhw> Looks like it's very difficult:P
<Noskcaj> smartboyhw, i've pretty much given up on that one, since it's my first package
<Noskcaj> i've contacted the guy who makes it and am awaiting reply
<smartboyhw> Noskcaj, copyrights are VERY important (as I learnt in Kubuntu packaging)
<smartboyhw> I got rejects solely because of that file
<Noskcaj> roaksoax, bug 1199235
<ubottu> bug 1199235 in TestDrive "Testdrive-gtk crashes when installed from 3.20" [Undecided,New] https://launchpad.net/bugs/1199235
<dholbach> good morning
<xnox> @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: xnox
<m4n1sh> ev: ping. can you have a look at the mail I sent you a few days back related to LP 1197974
<ubottu> Launchpad bug 1197974 in Activity Log Manager "Error setting crash reporting: GDBus.Error:org.freedesktop.DBus.Error.AuthFailed: Not authorized." [Medium,Confirmed] https://launchpad.net/bugs/1197974
<m4n1sh> whenever you are free
<ev> m4n1sh: yup, will do. For what it's worth, it's a harmless error
<ev> it just means that the code tried to reflect the UI state in the configuration file, but the user hadn't pressed the "unlock" button yet
<m4n1sh> ev: well, i don't know much about that component, so referred it to you. reported by jbicha
<ev> sure thing
<ev> is there a trick to getting qtcreator to set LD_* correctly? I'm trying to build and run ubuntu-system-settings locally, but it fails with 'libSystemSettings.so.1: cannot open shared object file: No such file or directory'
<Laney> I've just been building the package :(
<ev> seb128: ^ any idea?
<seb128> ev, Laney: no idea, I don't run it from qtcreator either
<ev> seb128: thanks all the same
<seb128> but mardy_ can maybe help there...
<mardy_> ev: I don't use qtcreator either, but I know you can change the environment variables used when running your app
<seb128> mardy, hey, welcome back ;-)
<mardy> seb128: thanks :-)
<seb128> mardy, I'm looking at a system setting translation issue ... do you have a preference on translating displayName in the backend or in the UI?
<ev> thanks
<seb128> mardy, I'm not sure if I should add the tr() call to the item-model.cpp code or in the UI
<mardy> seb128: I'd probably do that in the UI, but IMHO both are fine
<seb128> mardy, ok, I found how to do it in the UI (I was just missing the gettext domain), merge request coming in a bit
<seb128> mardy, https://code.launchpad.net/~seb128/ubuntu-system-settings/storage-bar-border/+merge/173672 ... did you mean to change the mr status as well?
<seb128> mardy, I've no strong opinion on the anchors, I just tend to try to go for "less lines of code"
<seb128> ;-)
<mardy> seb128: no, it's fine, I just wanted to wait for your reply. I've approved it now :-)
<seb128> mardy, ok ;-)
<seb128> mardy, is there any difference in behaviour/performance between both ways?
<seb128> mardy, or is it just that you find it easier to read when declared with left/right/...
<seb128> mardy, oh, and thanks for the review ;-)
<cjwatson> tjaalton: Could you please look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707064 ?  If you need help I can try to come up with something
<ubottu> Debian bug 707064 in libapache2-mod-nss "libapache2-mod-nss: sourceful transition towards Apache 2.4" [Serious,Open]
<tjaalton> cjwatson: yeah I should sync with upstream first, fedora has done the transition earlier this year iirc
<tjaalton> well, they just patched upstream
<mlankhorst> sforshee: did you try the macbook yet on 3.11 pre rc?
<valavanisalex> Hi All, can anyone point me to example source packages that use the new elegant "dh" debhelper syntax to build multiple binaries using different configuration options.  I looked at the vim and mpb packages but both of these use the old semi-manual dh_* syntax in the rules file.  In fact, is this even possible using dh?
<zyga> cjwatson: ping
<tjaalton> cjwatson: ok I have the source sorted out, now need to migrate the packaging
<zyga> cjwatson: I'm looking for some advice, what it the current best way to test dbus services? spawn a separate bus and test on that?
<zyga> cjwatson: mock the hell out of dbus? (feels wrong though)
<zyga> cjwatson: or something else?
<zyga> cjwatson: the service is written in python3
<cjwatson> zyga: pitti has a dbusmock library or something along those lines
<cjwatson> tjaalton: cool, thanks
<zyga> cjwatson: oh, I'll have a look
<zyga> cjwatson: thanks!
<cjwatson> tjaalton: http://wiki.debian.org/Apache/PackagingFor24 is fairly easy to follow
<tjaalton> k thanks
<cjwatson> valavanisalex: you can do anything with dh; it may just require lots of overrides.  openssh builds two variants of itself for instance
<zyga> cjwatson: that looks awesome, thanks!
<cjwatson> valavanisalex: or grub2 but that is Complex
<cjwatson> (and actually grub2 is a slightly strange mix of styles so perhaps not the best example)
<cjwatson> valavanisalex: the main important thing to realise is that you can override dh_auto_* to run each of your relevant build passes
<cjwatson> valavanisalex: for instance Python packages (*searches for random example* e.g. germinate) tend to run a build pass for each version of Python they're building for
<cjwatson> zyga: thank pitti, but yes :)
<cjwatson> one of these days maybe I should convert ubiquity to use that
<xnox> valavanisalex: cjwatson: with debhelper 9, one can define "build:" target and just do all the building there as compex, as needed. dh, will notice and run those commands instead of dh_auto_* stuff.
<xnox> cjwatson: for ubiquity build, i'd love to somehow multiplex and build included packages in-parallel, but with sane/sorted build-log.
<cjwatson> xnox,valavanisalex: You can do that.  It can have some surprising effects, and I've generally found it better to use overrides.
<cjwatson> xnox: Yes
<tjaalton> cjwatson: is apache 2.4 in saucy-proposed yet?
<cjwatson> tjaalton: Yes
<cjwatson> tjaalton: But better to do the transition in unstable and let it autosync, where possible
<tjaalton> sure
<cjwatson> tjaalton: (I guess you'll need a manual sync in this case)
<tjaalton> I'll test the builds against sid anyway
<tjaalton> but need someone to sponsor it
<cjwatson> I can do that
<sforshee> mlankhorst: I haven't tried 3.11 yet on any macbooks
<jdstrand> gema_: hi! should I use the qa-daily-testing tag on a bug for smoke testing failures? ie, I want bug #1199351 to show up for the failures for http://reports.qa.ubuntu.com/smokeng/saucy/image/2900/ and http://reports.qa.ubuntu.com/smokeng/saucy/image/2899/
<ubottu> bug 1199351 in linux-manta (Ubuntu) "/usr/share/ufw/check-requirements -f fails on Nexus 4 and Nexus 10" [Undecided,New] https://launchpad.net/bugs/1199351
<gema_> jdstrand: it's not a tag in the lp sense, if you want them to show in the dashboard, the bug number needs to be added to jenkins
<gema_> jdstrand: we can do that, or you can do it if you have access to the lab
<jdstrand> gema_: how do I do that?
<jdstrand> I think I do. I'd like to try, so I can do it in the future
<gema_> ack
<gema_> so connect to the vpn
<gema_> I will tell you how to find the right job
 * jdstrand is connected
<gema_> ok
<gema_> so this is the job that you want tagged: https://jenkins.qa.ubuntu.com/job/saucy-touch-mako-smoke-security/15/?
<gema_> all we need to find it's equivalent in the internal jenkins
<jdstrand> yes
<mlankhorst> sforshee: did anything land in 3.11 related to macbook though? like the pci crap perhaps
<sforshee> mlankhorst: not that I'm aware of, but I haven't been monitoring it closely
<mlankhorst> hm then again nfs seems to be dying again now too, maybe it is related to that..
<tjaalton> cjwatson: hm, seems to otherwise work, but somehow dh_strip doesn't strip the module as it used to
<stgraber> barry: system-image meeting in #ubuntu-meeting
<tjaalton> cjwatson: oh I know, guess dh_apache2 copies an unstripped version there, this doesn't use dh yet
<tjaalton> so I just added dh_apache2 after dh_install
<ev> mpt: any idea who I need to talk to about getting an icon made up for "diagnostics" in ubuntu-system-settings, or are you already on it?
<seb128> ev: talk to tiheum from design about icons
<ev> seb128: what good fortune. I'm facing him.
<ev> will do, thanks
<seb128> ev: yw ;-)
<blitzkrieg3> you mean
<seb128> ev: let me forward you an email with the icons he sent us
<ev> thank you
<seb128> ev: there is the one you want in there
<seb128> ev: email sent
<ev> perfect! thanks seb128!
<seb128> ev: yw!
<Laney> seb128: what about the colour editing thingy you told me to do?
<Laney> or did that get fixed?
<seb128> colour editing... me tries to remember
<seb128> Laney, oh, I included that in the email
<Laney> aha
<seb128> it's cccccc -> 808080 in the svg
<Laney> thought that extra detail might have been left out
<Laney> nm
<tjaalton> cjwatson: ok it's fixed
<seb128> Laney, thanks for checking ;-)
<cjwatson> tjaalton: Lovely, thanks
<tjaalton> cjwatson: pushed the source to http://kernel.ubuntu.com/~tjaalton/tmp/
<mpt> ev, wait, you have the stethoscope icon?
<ev> I have a heartbeat monitor icon
<ev> you can see it if you come over here :)
<mpt> oh cool
<mpt> But that involves walking, like, six steps
<ogra_> use a hangout !
<ev> hahaha
<mpt> Five minutes to set up the hangout, five more minutes to figure out the screen sharing feature
<ogra_> but you dont have to walk
<cjwatson> tjaalton: your .dsc has a different .orig.tar.gz size from the one in Debian unstable - I guess I'm safe to ignore that?
<tjaalton> cjwatson: oh.. yes please do. I'll fix mine
<cjwatson> tjaalton: Oh, it's different in unstable vs. saucy
<tjaalton> duh
<cjwatson> tjaalton: That sucks, it'll have to be a fakesync
<tjaalton> can't remember why it was originally
<cjwatson> tjaalton: They're identical file contents, but packed independently from different top-level directory names
<cjwatson> Ah well
<cjwatson> Get it right next upstream release ;-)
<tjaalton> yeah, I'll poke upstream (@redhat) to actually release a new version and not just patch the package all the time
<smartboyhw> SRU team members: Can you try to review Bug 1189083 and Bug 1189085's SRU patch into Raring, I want to test it today or tomorrow as I'm leaving tomorrow afternoon (UTC time).
<ubottu> bug 1189083 in ibus-cangjie (Ubuntu Raring) "Make "Preferences" button work in "IBus Preferences"" [Undecided,Confirmed] https://launchpad.net/bugs/1189083
<ubottu> bug 1189085 in ibus-cangjie (Ubuntu Raring) "ibus-cangjie missing dependency gir1.2-ibus-1.0" [Undecided,Confirmed] https://launchpad.net/bugs/1189085
<smartboyhw> And upload, ofc:P
<smartboyhw> Nobody help? ^
<seb128> barry, hey
<barry> seb128: hi
<seb128> barry, is that known that your python-configglue updates broke ubuntuone-syncdaemon on saucy?
<barry> seb128: no, but add it to the list :(
<barry> it also broke software-center and virtualenv
<seb128> barry, can you try running /usr/lib/ubuntuone-client/ubuntuone-syncdaemon
<seb128> ?
<barry> not python-configglue directly, but its new dependence on python-configparser
<seb128> barry, seems like we need autopkgtests in python-configglue to make sure it doesn't break all our softwares when updated ;-)
<barry> the latter which seems to break a lot of stuff
<barry> seb128: yeah, i need to untangle all of that.  i may have to talk to pindonga about dropping that dep so we can kill -configparser out of the archive
<cjwatson> seb128: you need tests in the packages that depend on python-configglue, you mean :)
<seb128> cjwatson, right ;-)
<barry> configglue is fine, configparser is killing us
<seb128> dobey, ^ would be nice to have in s-c and u1-syncdaemon
<barry> (well, fine module its dependence on the latter ;)
<dobey> seb128: software-center is fixed already
<barry> *modulo
<seb128> barry, well, downgrading configglue makes u1 work again
<seb128> but yeah
<barry> yeah
<dobey> well, i fixed the crash that was caused by configparser
<barry> i don't have time to look right now, but i suspect configglue doesn't *really* need configparser (iow, it can be written against ConfigParser for py2)
<dobey> almost certainly
<barry> i'm trying to decide whether it's better/possible to fix configparser or kill it off
<barry> (or at least relegate it to universe)
<dobey> kill kill kill
<barry> anyway, it's third on my todo list for today :)
<dobey> "backports" of python3 modules onto python2 are evil, and tend to break things in weird ways
<dobey> particularly things that have to work on both versions and do things like try: import configparser except ImportError: import ConfigParser
<barry> seb128: is there a bug for the syncdaemon breakage?  if not, please file one, i need ammo :)
<barry> dobey: right.  it would be much better to be named something that doesn't overlap with a py3 stdlib package name
<seb128> barry, dobey: https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/1198480
<ubottu> Launchpad bug 1198480 in ubuntuone-client (Ubuntu) "ubuntuone-syncdaemon crashed with AssertionError in expand_user()" [Undecided,Confirmed]
<dobey> barry: the problem is people write code for py3, and then someone says "i must run this on py2" and so they just take the py3 core module and make it "work" on py2, and ship it as is
<barry> dobey: that is a problem
<dobey> it wouldn't be so bad if they were all namespaced into a "py3backports" package or something
<dobey> at least then they wouldn't break things that aren't intentionally using them
<barry> cjwatson: btw, today's updates broke x.org for me too :/
<barry> well, at least the greeter doesn't start
<smartboyhw> Hmm, sounds like nobody noticed my request or something:(
<wookey> libjpeg-dev in raring is not MA:same (and is arch:all so things which build-dep on it end up getting the wrong-arch version of libjpeg-turbo-dev installed
 * barry thanks his disk snapshots
<cjwatson> barry: all I know about it is what I saw in proposed-migration, which isn't very relevant for this :)
<barry> cjwatson: yeah
<cjwatson> wookey: raring is what it is with regard to multiarch - I suggest getting it fixed in saucy :)
<wookey> cjwatson: yeah. I know - I just discoered it there helping someone build his stuff
<wookey> and was checking that we agree this is wrong - I know there is a load of complexity around the 'two different libjpegs' fight
<sil2100> Wellark: hi!
<cjwatson> I don't agree it's "wrong" in that we haven't yet said it's a bug for -dev packages not to be multiarch, but it sounds as though it could be improved
<cjwatson> I'm not totally sure of the intended semantics of <Architecture: all> Depends: <Multi-Arch: same>
<sil2100> Wellark: I saw you are working on unity-action-api - how does the status look like currently?
<wookey> cjwatson: it's always wrong SFAIK
<cjwatson> slangasek probably knows
<wookey> which is why we fixed it in libdb-dev
<cjwatson> wookey: arguably; but in this case it seems kind of reasonable
<cjwatson> I mean, it's wrong by assertion rather than by obviousness, I feel :)
<wookey> although we have a much bigger problem with that sort of things outside C-library world
<wookey> (e.g perl modules)
<cjwatson> that said, the current setup means that you can't do B-D: libjpeg-dev, libjpeg-dev:native and have it work
<cjwatson> so that rather suggests that libjpeg-dev Arch: any M-A: same would be more correct
<Wellark> sil2100: timp is working on integrating it directly to the UITK
<slangasek> the defined semantics are that the dep of an Arch: all package on an M-A: same package can only be satisfied by the package of the primary arch; if you need something more complex the package needs to be changed to no longer be Arch: all
<Wellark> sil2100: it should be ready to be used next week
<sil2100> Wellark: ok, so no daily-releasing for now until that's done?
<sil2100> Wellark: or will the package be removed completely and integrated into UITK somehow?
<Wellark> sil2100: the package will be in main. If you are using UITK then you will have it already set up if you use MainView and Page
<Wellark> sil2100: but if you develop an application that does not use UITK then you can use the direct QML API
<sil2100> Wellark: ok, all clear - then I'll ping you back again next week, thanks!
<Wellark> sil2100: np :)
<xnox> wookey: uploaded libjpeg8-empty to fix that.
<xnox> @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:
 * xnox => lunch
<wookey> xnox: chers very much![D[D[D[D[D[D[D[D[D[D[D[D[De
<wookey> why would libtwin be in raring and previous 4 releases, but not saucy?
<Sarvatt> its in saucy..?
<Sarvatt> https://launchpad.net/ubuntu/+source/libtwin
<wookey> hmm. but it doesn;t appear in http://packages.ubuntu.com/search?suite=saucy&section=all&arch=any&keywords=libtwin-dev&searchon=names
<wookey> that's what confused me
<Sarvatt> doesnt look like anything on saucy is on there
<cjwatson> wookey: packages.u.c is out of date I think; don't trust it
<cjwatson> tjaalton: uploaded, sorry for the delay
<cjwatson> tjaalton: can you deal with the fakesync into Ubuntu or want me to?  (syncpackage -F deals with that easily these days)
<tjaalton> cjwatson: woot, thanks.. i can handle that part
<rbasak> Should I normally have to explicitly specify -sa to debuild when preparing a merge? I just got a rejection because I didn't upload the orig tarball. I can do it again with -sa, but just want to make sure that it's expected and I haven't done something else wrong.
<cjwatson> rbasak: Yes
<rbasak> OK, thanks!
<tumbleweed> err, if you use -v, doesn't wit work out if it needs -sa or not?
<xnox> rbasak: also correct -v is nice as well.
<xnox> tumbleweed: not really, it only incudes tarball for -1 -0ubuntu1, but not like for -3ubuntu1
<valavanisalex> cjwatson: Sorry for the slow reply; thanks very much for the help.  I'll take a look at those packages for inspiration.
<seb128> jibel, hey, I just got an email about "Jenkins Failure - saucy-adt-libproxy 42" pointing to https://jenkins.qa.ubuntu.com/job/saucy-adt-libproxy/42/?
<seb128> jibel, which has "no test"
<seb128> jibel, do you know what's going on there?
<jibel> seb128, mkdir: cannot create directory `/dev/shm/adt': Permission denied, it is a problem on the testing node
<jibel> seb128, I'll look into this
<seb128> jibel, where do you see that?
<seb128> jibel, thanks
<seb128> jibel, just got a similar one for poppler
<jibel> seb128, https://jenkins.qa.ubuntu.com/job/saucy-adt-libproxy/42/ARCH=amd64,label=adt/console
<Laney> amd64 -> console output
<seb128> thanks
<seb128> I was just looking at the "no test" empty page :p
<seb128> I didn't think about clicking on the side
<seb128> the jenkins UI is not the most obvious thing
<jibel> there is no better UI than jenkins ;)
<Laney> It's like mpt himself designed it
<jibel> seb128, fixed, now I'm wondering how it could lose this mount point
<jibel> seb128, I'll re-run poppler and libproxy
<seb128> jibel, 'ci
<Laney> jibel: glib2.0 too please
<jibel> Laney, done too, I re-triggered all the tests that failed
<Laney> ah OK, it didn't sound like you had a complete list
<Laney> thanks
<mpt> seb128, jibel: You may have realized this, but it's easy for "the jenkins UI is not the most obvious thing" and "there is no better UI than jenkins" to be true at the same time. :-)
<seb128> mpt, is it?
<infinity> If you qualify the second statement with "for the task at hand", perhaps.
<mpt> Sure, if the state of the art is terrible
<infinity> I could probably vomit a better UI than Jenkins.
<slangasek> infinity: but if you do, you should seek medical attention
<cjwatson> mdeslaur: Could you please either merge php5 or tell me I can?  It's important for the Apache 2.4 transition in progress.
<infinity> cjwatson: Robie was going to look at php5.
<infinity> rbasak: ^
<unixabg> Greetings, is there a way to stack on a read only persistent layer when booting live cd? Say like casper-ro?
<unixabg> I ask since I would like to deploy live image with some additions and make them act more like a firmware install.
<sarnold> unixabg: perhaps overlayfs can get you there
<unixabg> sarnold: First thank you for the response, can I do this with a defalut official ubuntu live iso?
<unixabg> I am trying to avoid remastering so I can stay with current releases.
<sarnold> unixabg: if you have a live image booted, check /proc/filesystems for overlayfs
<unixabg> sarnold: booting one now, one moment..
<unixabg> sarnold: ok booted, and cat /proc/filesystems lists :   nodev    overlayfs
<dobey> barry: the big problem seems to just be that configglue now returns unicode() for lots of things on py2 where it used to return byte strings as str()
<dobey> barry: at least, as far as configglue/configparser relates to breaking ubuntuone-syncdaemon
<unixabg> sarnold: I am not sure how to utilize to achieve ro persistence with default iso. I can configure entries in grub if this helps.
<barry> dobey: let me see if i can get pindonga in on the conversation
<barry> pindonga: hi
<pindonga> hi
<barry> <dobey> barry: the big problem seems to just be that configglue now returns
<barry>         unicode() for lots of things on py2 where it used to return byte
<barry>         strings as str()
<barry> <dobey> barry: at least, as far as configglue/configparser relates to breaking
<barry>         ubuntuone-syncdaemon
<barry> blah, ugly paste
<dobey> right. it's probably the result of configglue returning unicode() instead of bytes
<dobey> err
<barry> pindonga: so, python-configparser broke software center, is breaking syncdaemon and virtualenv too
<dobey> configparser returning them, that is
<pindonga> barry, well, python-configparser is a backport of the py3 configparser, yes?
<pindonga> which is backwards incompatible with py2's ConfigParser
<dobey> which of course breaks everything
<dobey> pindonga: it's backwards-incompatibile with the fact that python2 doesn't use unicode by default
<dobey> at least, that's why it is breaking ubuntuione-syncdaemon
<pindonga> so, what's the issue here? why is python-configparser needed?
<dobey> pindonga: configglue is depending on it, and thus pulling it in
<barry> pindonga: it's a dependency on -configglue now afaict
<pindonga> ie, if we're not packaging the latest configglue it should be no problem yes?
<pindonga> right, why do we need the latest configglue then?
<barry> pindonga: we're packaging it now :)
<dobey> 1.1.0 is in sauncy
<pindonga> 1.0.3 should work fine with py2
<dobey> err saucy
<pindonga> 1.1.0 and 1.1.1 are py3 compat
<barry> pindonga: for py3 in saucy
<dobey> yes, but it breaks compat with py2
<dobey> because things that were str() in python2 are now unicode()
<pindonga> ok, what do you suggest?
<barry> pindonga: how difficult would it be for py2 configglue to just use stdlib ConfigParser instead of python-configparser?
<pindonga> why don't we ship 1.0.3 ?
<pindonga> barry, the main problem is that it won't work with py3
<dobey> pindonga: try: except: like everyone else that supports both versions?
<pindonga> well, if we want to support both versions, maybe ;-)
<barry> pindonga: sure, but configglue is now py2 and py3.  so you could use `from ConfigParser import ConfigParser` for py2 and wrap that in a try/except
<pindonga> I can give it a try
<barry> with the except being `from configparser import ConfigParser`
<dobey> pindonga: well, "want" is a strong word. we have to support both versions :)
<pindonga> I can't guarantee it'll work, but I'll let you know if I manage to
<dobey> or we have to ship two different versions of configglue
<pindonga> there are many changes between py2 and py3 in ConfigParser
<pindonga> too many
<barry> pindonga: do the py2 import in the try
<pindonga> barry, the main problem is the api changed
<pindonga> so it's not just like changing the import
<barry> pindonga: do you use the new api?
<dobey> pindonga: are you actually using the new API?
<pindonga> afaik there is only one api
<pindonga> as said... will give it a go and see what happens
<pindonga> my initial attempts were'nt successfull
<pindonga> hence I opted for the backported configparser
<dobey> barry: do we even ship any applications that use configglue on python3?
<barry> pindonga: thanks for giving it a shot.  i can help out more later today
<dobey> i don't think we do
<barry> dobey: not yet, but it's a dep for porting other things we need to get off of py2
<barry> dobey: e.g., yeah you guessed it: ubuntuone-client
<dobey> ubuntuone-client is the only thing that uses configglue at all, really
<dobey> unless you plan to port django as well :)
<barry> really, i think python-configparser is quite ill-advised and i am going to contact upstream about "the problem"
<barry> doesn't django already support py3?  maybe not packaged yet, but that's a SMoE
<barry> :)
<dobey> i'm just saying, it's ubuntuone and a module for django to use configglue in a django app. those are the only things in ubuntu that use configglue; and now they're both broken :)
<barry> dobey: yeah :(
<sarnold> unixabg: I'm not entirely sure how you'd use it either, but it -is- a mechanism to overlay one FS on top of another
<unixabg> sarnold: I took a quick look at casper and that is where the casper-rw things occur.
<unixabg> I may just have to remaster and script in mounting overlayfs as read only in the iso. I will have to think about what
<unixabg> the path of least work would be to stack on stock images.
<ximion> cjwatson: hi! from the discussion about the Ubuntu app-installer, are you planning to use PackageKit (the daemon) in Ubuntu?
<dobey> kenvandine: btw, what's supposed to start friends-service on login?
<robru> dobey, launching friends-app will start friends-service if it's not already running
<dobey> robru: i don't have friends-app installed. and i don't want it (nor do i want to have to run it every time i log in). it seems like friends-service should be started on login, like gwibber-service used to be, even without the app running/installed
<robru> dobey, it might be, I'm not sure. ken wrote most of friends-service so it's all his fault ;-)
<dobey> i just want the notifications when someone sends me a DM or @mention
<kenvandine> the lens does
<dobey> bah
<dobey> that doesn't work very well if there is no lens :)
<kenvandine> indeed
<kenvandine> but we always have the lens :)
<dobey> why doesn't friends-service just have an autostart file?
<dobey> kenvandine: gnome-shell doesn't have lenses
<kenvandine> i'd take a patch adding autostart based on a gsettings key
<dobey> why gsettings?
<kenvandine> gwibber used to do that
<kenvandine> we don't want it to always start
<kenvandine> only for people that want it
<dobey> people who don't want it can apt-get remove it :)
<kenvandine> AutostartCondition=GSettings org.gwibber.preferences autostart
<kenvandine> X-GNOME-Autostart-Delay=30
<kenvandine> is what we had before
<slangasek> not if it's installed by default in a read-only phone image, they can't
<slangasek> (is it?  I don't know whether it is, but I'm assuming it would be)
<dobey> slangasek: doesn't the phone UI even do xdg autostart?
<dobey> err, does even
<slangasek> that's not the point
<slangasek> oh
<slangasek> sorry, the inversion makes the difference ;)
<dobey> right :)
<slangasek> I don't know that it *currently* does xdg autostart, but I wouldn't assume that it won't do so in the future
<kenvandine> the phone autostarts it differently anyway
<kenvandine> but regardless, it is kind of nice to provide an easy way to disable it
<dobey> i didn't know AutostartCondition existed though. when did that get added?
<kenvandine> forever ago :)
<dobey> and how does it work?
<kenvandine> it only autostarts if the condition is true
<pindonga> dobey, barry I think I have an MP ready for review that get's rid of the backported configparser
<dobey> kenvandine: so it's a Exec style line? because "GSettings" isn't a command :)
<kenvandine> right
<kenvandine> it doesn't run a command
<kenvandine> GSettings is one of the supported sources
<barry> pindonga: assign me to review it and i'll look asap
<barry> pindonga: and thanks!
<dobey> kenvandine: and there is no AutostartCondition mentioned in the spec
<dobey> kenvandine: so where is it documented?
<kenvandine> i swear i've seen it in the spec before
<dobey> kenvandine: i just looked at the -latest.html on stadnards.freedesktop.org for both autostart and desktop file specs, and no mention in either one :)
<kenvandine> dobey, maybe it's gnome specific then
<kenvandine> but no X-GNOME
<kenvandine> AutostartCondition is an extension of the Desktop Application Autostart Specification proposed by Dan Winship: http://lists.freedesktop.org/archives/xdg/2007-January/007436.html
<kenvandine> dobey, that's from https://wiki.gnome.org/SessionManagement/GnomeSession
<dobey> ugh
<kenvandine> proposed 6 years ago... love how fast xdg moves :)
<dobey> well it just means that things not using gnome-session will just ignore the key, or fail to do anything because the file has an invalid key
<dobey> yay collaboration!
<kenvandine> kde might have implemented it too
<kenvandine> someone from trolltech +1'd it :)
<pindonga> barry, https://code.launchpad.net/~ricardokirkner/configglue/from-future-remove-configparser/+merge/173806
<slangasek> kenvandine: the problem is, this proposed change doesn't require introducing a new system-level directory with semantics that no one understands; figure out how to make this use a new directory and it'll go right into xdg ;)
<barry> pindonga: tabbed up :)
<kenvandine> slangasek, :-D
<smoser> hey...
<smoser> can someone tell me if i'm just doing something wrong
<smoser> i put a file '/etc/init/walinuxagent.conf.override'
<smoser> and in it 'manual'
<smoser> but it seems to be starting
<smoser> is that right?
<sarnold> smoser: looks like walinuxagent.override: http://upstart.ubuntu.com/cookbook/#override-files
<smoser> ah.
<smoser> thank you.
<smoser> sarnold, that worked. thanks.
<sarnold> smoser: woot :)
<jtaylor> why doesn't launchpad pick up charybdis from unstable? (try  syncpackage --force charybdis)
<jtaylor> it isn't listed as importer failure
<cjwatson> ximion: I have no control of or stake either way in what we use in the rest of Ubuntu; we're not using either PK or aptdaemon in Ubuntu Touch right now, so I'm free to choose either for the moment.  It'll be at least a few months before what I'm doing matters for Ubuntu desktop
<cjwatson> jtaylor: which importer?
<ajmitch> jtaylor: looks like LP may not have seen the updated debian version of charybdis, for whatever reason.
<cjwatson> jtaylor: (package-import.ubuntu.com has nothing to do with what syncpackage looks at)
<ajmitch> does syncpackage still use what's shown on launchpad.net/debian/+source/charybdis ?
<jdstrand> tedg: hey, so I tried initctl, and desktop-exec dumped core
<cjwatson> ajmitch: yes
<cjwatson> http://paste.ubuntu.com/5859584/
<tedg> jdstrand, Hah, oops.  That's a bug :-)
<cjwatson> ^- import failure for that package
<jdstrand> tedg: I then tried launching using what /var/crash told me: /usr/lib/x86_64-linux-gnu/upstart-app-launch//desktop-exec ubuntu-calendar-app
<jdstrand> same result
<tedg> jdstrand, Can you send me your modified desktop file?
<jdstrand> I then removed XCanonicalAppArmorProfile. same thing
<cjwatson> the oops just has that same traceback
<cjwatson> dpkg-source: warning: diff `charybdis-3.4.2/debian/patches/gnutls30' patches file charybdis-3.4.2/libratbox/configure.ac twice
<cjwatson> may not be helping
<jdstrand> tedg: yeah
<cjwatson> I suspect the version of dpkg-dev on iron barfs on that
<cjwatson> dpkg-source: error: diff `charybdis-3.4.2/debian/patches/gnutls30' patches file charybdis-3.4.2/libratbox/configure.ac twice
<cjwatson> [cjwatson@amber(lucid-i386) ~]$
<cjwatson> jtaylor: ^- reason
<jtaylor> thx
<jtaylor> how to fix, ask debian maintainer to fix it?
<cjwatson> yes
<slangasek> is that debian/patches/series.ubuntu? :P
<jdstrand> tedg: http://paste.ubuntu.com/5859591/
<cjwatson> since it's a warning even in Debian
<cjwatson> slangasek: nope
<slangasek> huh, ok
<cjwatson> although that's another common-ish cause of this kind of thing
 * jtaylor filing bug
<jdstrand> tedg: I can help you setup what you need to test apparmor (though it is in my last two emails)
<cjwatson> jtaylor: harder approach: backport the changes that turned that from an error to a warning to lucid
<jdstrand> tedg: that said-- is there an expectation that XCanonicalAppArmorProfile will be available for the demo?
<jtaylor> or update that machine to precise? :)
<tedg> jdstrand, No apparmor needed there as that only parses the file.
<cjwatson> or wait for the wheels to grind slowly for LP to be upgraded to precise
<cjwatson> but it's not remotely trivial
<cjwatson> (it is in progress - slowly)
<jdstrand> tedg: otherwise, I should move to something else and stop bothering you about an interim solution :)
<tedg> jdstrand, Not sure, I can't clear a clean answer on what the demo will include.  Sounds like it...
<tedg> jdstrand, I was told putting Unity 8 under Upstart was "trivial" but yet it's not done.
<cjwatson> backporting the dpkg change isn't necessarily a dreadful idea, but it would be quicker to get the Debian package fixed, I'm sure
<jdstrand> ricmm_: ^ thoughts?
<jdstrand> tedg: I heard today it will include the SDK building a click package
<tedg> jdstrand, Cool, I can't wait to see this demo :-)
<jdstrand> tedg: which implies things should work without hacks (to me anyway). though hacking the sdk to do soemthing to launch under confinement is still possible of course
<jdstrand> it keeps expanding :)
<jdstrand> tedg: I was trying hard to keep application lifecycle out of it
<jdstrand> but click, lifecycle and sdk are so closely related
<jdstrand> anyhoo
<jdstrand> we can resort to a hack in the sdk in its build click package part
<tedg> jdstrand, Hmm, that doesn't crash for me :-(
<tedg> It's wrong, but no core.
<tedg> jdstrand, Can you pastebin the stacktrace?
<tedg> jdstrand, You're doing desktop-exec ubuntu-calendar-app, right?
<jdstrand> tedg: fyi, this is on amd64
<jdstrand> this is from the command line: http://paste.ubuntu.com/5859629/
<tedg> jdstrand, Ah, that's just a g_error abort stacktrace.
<tedg> jdstrand, Where did you put ubuntu-calendar-app.desktop ?
 * jdstrand is working on the other
<jdstrand> tedg: I installed ubuntu-calendar-app via the coreapps ppa (http://ppa.launchpad.net/ubuntu-touch-coreapps-drivers/daily/ubuntu)
<jdstrand> tedg: it is in /usr/share/applications
<jdstrand> /usr/share/applications/ubuntu-calculator-app.desktop
<tedg> jdstrand, calculator or calendar?
<dobey> hrmm, i wonder what the quickest way to become a debian maintainer for a package is.
<tedg> dobey, run your car engine to speed up the heat death of the universe ;-)
<dobey> tedg: just one of them, or all of them?
<tedg> dobey, As many as you can afford.
<ximion> cjwatson: okay... because the current direction does look a bit confusing...
<dobey> that would only burn the earth anyway, not the whole universe; which will most likely actually freeze to death
<slangasek> dobey: pick a package no one else cares about? :)
<ximion> a PK backend cannot be used by Aptdaemon
<dobey> slangasek: i thought i did, but someone merged it into debian from ubuntu, so now i guess i need to get privs to upload it to debian, and then sync it over
<slangasek> well, you don't *have* to ;)
<dobey> true
<slangasek> if you were already maintaining it in Ubuntu, you can continue to do so
<ximion> cjwatson: also, there can only be one PK backend at a time. For Listaller, we developed a plugin API (was very time-consuming...) to make it possible to integrate LI into PK. To get full integration, Ubuntu might want to look at this API (we created a multi-purpose API for almost any needs)
<dobey> but merging and updating can be pain :)
<slangasek> becoming the maintainer in Debian just so you can sync it to Ubuntu seems a bit odd
<dobey> slangasek: well, isn't the preferred way to do things, to update them in debian and sync, if they are in debian, and we have no need to maintain a diff from what is in debian?
<slangasek> dobey: yes, but the trade-off is the inconvenience of someone who already has upload rights in Ubuntu now having to get upload rights to Debian to continue maintaining it
<dobey> indeed
<slangasek> generally speaking, it's a good thing to have as much of the maintenance happen as possible in Debian, but there *are* tradeoffs
<jdstrand> tedg: ok, apparently I am an idiot wrt to the crash
<jdstrand> tedg: I did mistype as calendar somewhere along the way
<tedg> jdstrand, Ah good :-)  /me wipes brow
<tedg> jdstrand, It looks like the output ends on qmlscene, which is a bug and fixed on a branch.  I need to find a reviewer for it.
<jdstrand> tedg: tedg well, I think there might still be an issue? initctl emit application-start APP_ID=ubuntu-calendar-app does crash
<tedg> jdstrand, Yeah, I probably should change the error reporting to report a recoverable error.
<jdstrand> ah, /usr/share/applications/ubuntu-calendar-app.desktop does not exist
<jdstrand> heh, ubuntu-calendar-app is essentially an empty package
<jdstrand> tedg: so, there is a bug for you :)
<tedg> Wonder if I can trace who sent the upstart event and blame them? /me schemes
<jdstrand> tedg: now that all that is straightened out. initctl emit application-start APP_ID=ubuntu-calculator-app does launch the calculator (yea!)
<jdstrand> tedg: but does not launch under confinement
<tedg> jdstrand, What does the desktop-exec return with the calculator?
<tedg> jdstrand, It should have the aa-exec line.
<jdstrand> yeah, it does
<jdstrand> $ /usr/lib/x86_64-linux-gnu/upstart-app-launch/desktop-exec ubuntu-calculator-app
<jdstrand> aa-exec -p "ubuntu-calculator-app" -- qmlscene
<tedg> Hah, then it's an apparmor issue ;-)
<jdstrand> tedg: should that be qmlscene <qml file>?
<tedg> jdstrand, Yeah, that's fixed in lp:~ted/upstart-app-launch/uris, but hasn't been reviewed yet.
<jdstrand> tedg: so, maybe that is why. if I use aa-exec -p "ubuntu-calculator-app" -- qmlscene /usr/share/ubuntu-calculator-app/ubuntu-calculator-app.qml, it works
<jdstrand> tedg: so it is an upstart-app-launch problem :)
<jdstrand> tedg: I have finger guns too
<tedg> jdstrand, Ah, okay.  Yes, I'd expect that to be the issue then.  If you want to grab that branch you can verify.
<tedg> jdstrand, It's inline packaged so it's just a bzr bd to build it.
<jdstrand> tedg: ack thanks. I'll respond to the thread in a bit. thanks :)
<tedg> jdstrand, I did verify on the desktop file that you sent me that it added the QML file though.
<tedg> jdstrand, So I'm pretty confident that branch fixes it.
<jdstrand> rocking
<jdstrand> once that is there, then all that's left is desktop-exec being used in the demo
<jdstrand> (for this part)
<tedg> jdstrand, Yeah, I haven't pushed the Unity guys there because today they'd have to shell out to initctl, while in a few days they'll be able to use libupstart, which is much better.
<jdstrand> that's fine. I'm not pushing anything either, just trying to stay on top of the various threads :)
<jdstrand> tedg: thanks for the help
<tedg> np
<dobey> does "Tests-Directory: ." in debian/tests/control work (and do what I think it should do)?
<tedg> slangasek, Can an upstart event have multiple values for the same property?
<tedg> slangasek, i.e.  foo-event BAR=fu BAR=foo, so then the listener could trigger on one value, either one.
<dobey> is there a way to get autopkgtests run in pbuilder when it builds the package?
<jtaylor> dobey: I have a script to run adt in pbuilder, should not be hard to adapt it to do it automatically
<dobey> maybe i can just do it locally
<jtaylor> its still horrendous bad code but I jut can't find the time to cleanit up and release it proper :/
<jtaylor> http://paste.ubuntu.com/5859759/
<jtaylor> wait I probably already gave that to you didn't I? I should stop pushing my aweful stuf :(
<jtaylor> (it does work well though)
<dobey> i haven't seen it before, no
<dobey> oh nice
<dobey> NameError: global name 'atmostone' is not defined
<dobey> :-/
<jtaylor> there is also sadt.py by jwilk, but it does not deal with dependencies or pbuilder (last I checked): https://bitbucket.org/jwilk/debian-misc/
<jtaylor> but it might be a better starting point
<dobey> i can't even run adt-run locally
<dobey> i am surprised it works at all anywhere :-/
<jtaylor> works for me, but its to heavy for practical use
<dobey> i must be using something nobody else uses then, because this code is definitely broken :)
<dobey> anyway, after fixing the brokenness there, it seems to work now
<dobey> and it does what i expected (aside from the not working part), so yay!
<slangasek> tedg: multiple values for the same property> AFAIK the answer is no
#ubuntu-devel 2013-07-10
<pitti> Good morning
<Noskcaj> what do i need to do to package bug 1199017 ? the dsc, debian folder and tarball ar all provided?
<ubottu> bug 1199017 in Ubuntu "[needs-packaging] ubuntuone-credentials" [Wishlist,New] https://launchpad.net/bugs/1199017
<Noskcaj> *are
<ajmitch> Noskcaj: the bug is there so that a sponsor can look at it & upload it, there's nothing you need to do if you're not able to upload it
<Noskcaj> ok
<dholbach> good morning
<mwhudson> pitti: hello
<pitti> hello mwhudson
<mwhudson> pitti: did you see https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1196440?  would you know anything about it?
<ubottu> Launchpad bug 1196440 in apache2 (Ubuntu) "apache2-mpm-worker-dbgsym is uninstallable" [Undecided,New]
<mwhudson> (i found your fingers on dbgsym stuff :))
<pitti> hmm, apache2's debian/control does have apache2-dbg; I wonder where it went
<pitti> ooh
<pitti> we explicitly don't build it on ubuntu
<pitti> that delta can be dropped now
<pitti> mwhudson: doing a test build now
<mwhudson> pitti: ta
<zyga_> pitti: hey
<mwhudson> ... in the mean time, how do i lie to apt and pretend apache2-dbg is installed?
<zyga> mwhudson: you want to build something that depends on the -dbg package?
<pitti> hey zyga
<zyga> pitti: hey, I've started looking at and experimenting with your dbusmock project
<pitti> mwhudson: won't help you in this case, the -dbgsym is empty
<zyga> pitti: I wanted to say *thank you* it's really awesome
<mwhudson> pitti: oh ok
 * mwhudson rummages around for his unstripped apache build
<pitti> zyga: nice :)
<zyga> pitti: I'm still in the early stages here, I wanted to ask if you think that dbusmock is applicable for testing server code somehow? like putting upower on a fake bus (and mocking stuff internally) to ensure that the actual implementation does what is expected
<zyga> pitti: from what I read so far it seems to be more client focused, where you put a fake server on a spare bus and have real clients talk to it
<ev> m4n1sh: apologies for not getting to that bug yesterday. Going to try to fit it in today
<pitti> mwhudson: fix uploaded
<mwhudson> pitti: :)
<mwhudson> pitti: thanks
<pitti> zyga: not quite, it's not meant for that; it's primary purpose is to test desktop-side/UI code
<pitti> zyga: like, indicators or gnome-settings-daemon
<pitti> zyga: for testing upower itself I use an umockdev approach, i. e. fake the sysfs/uevent side and test that upowerd reacts as intended
<pitti> zyga: i. e. the intention is to have the mock mirror what the real daemon does, so it's rather pointless to test the other way round
 * smb wonders whether there is a compelling reason to have "move workspace left+right" on ctrl+alt+<left/right> but "move workspace up+down" on super+<up/down>
<zyga> pitti: I see, how do you test upower's dbus interface itself then?
<smb> (actually super and page up/down
<pitti> zyga: the test suite calls the "upower" CLI tool
<pitti> zyga: but you can just talk to the d-bus interface directly in tests, of course
<zyga> pitti: oh
<zyga> pitti: do you put upower on a some kind of special, standalone, test bus/
<pitti> zyga: yes, I do; otherwise you couldn't run the tests in "make check"/during package build
<zyga> pitti: I need to look at upower then, I think the solution I'm after is just putting my code on a bus does not interfere with rest of the system and see what happens when I (really) call methods over dbus, that I can mock (the actions of) internally in the test code
<pitti> zyga: you can do that with dbus-launch <program>, and setting DBUS_SYSTEM_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS
<pitti> zyga: (and then clean up the bus after you've done)
<pitti> there are some convenience libraries around that, but that's the gist of it
<zyga> pitti: my app runs on the session bus normally
<zyga> pitti: is it appropriate to just use that during tests/
<pitti> zyga: ah, then you only need the dbus-launch
<zyga> ok
<pitti> zyga: if your test suite is in Python, you can also use Gio.TestDBus, which is very convenient (and cleans up after itself)
<zyga> pitti: indeed it is
<pitti> zyga: yes, sure; tests shouldn't assume an existing session bus
<zyga> pitti: thanks, I need to look stuff up then :)
<pitti> zyga: http://cgit.freedesktop.org/upower/tree/src/linux/integration-test uses Gio.TestDBus
<zyga> pitti: that looks like exactly what I wanted!
<zyga> pitti: awesome, thanks
<pitti> zyga: you wouldn't use lines 75 and 76 for a session bus
<pitti> zyga: and of course Gio.BusType.SYSTEM â .SESSION
<seb128> barry, slangasek: ubuntuone and software-center are broken in saucy for a week now due to the python-configglue update ... should we think about reverting the update?
<seb128> it's getting really annoying for those of us that use u1...
<pitti> seb128: is that the UnicodeDecodeError crash that pops up multiple times every day?
 * pitti tried to report it, but had outdated packages
<seb128> pitti, no, it's bug #1198480
<ubottu> bug 1198480 in ubuntuone-client (Ubuntu) "ubuntuone-syncdaemon crashed with AssertionError in expand_user()" [Undecided,Confirmed] https://launchpad.net/bugs/1198480
<pitti> ah, it just crashed again, reporting now
<seb128> pitti, ubuntuone-syncdaemon doesn't start for me
<seb128> pitti, does it work for you?
<pitti> indeed not
<pitti> 0:00 /usr/lib/x86_64-linux-gnu/indicator-sync/indicator-sync-service
<pitti> unless this replaced it somehow
<pitti> but no ubuntuone-syncdaemon process or similar
<seb128> pitti, no, can you try running manually ubuntuone-syncdaemon ?
<seb128> pitti, /usr/lib/ubuntuone-client/ubuntuone-syncdaemon
<pitti> yep, AssertionError
<seb128> righht
<seb128> it's broken for a week, since barry updated python-configglue
<seb128> what happened to the "revert broken updates in the day if we don't come with a fix"? ;-)
 * pitti gets bug 1199659
<ubottu> bug 1199659 in software-center (Ubuntu) "software-center-dbus crashed with UnicodeDecodeError in parse_applications_menu(): 'ascii' codec can't decode byte 0xc3 in position 5: ordinal not in range(128)" [Undecided,New] https://launchpad.net/bugs/1199659
<pitti> seb128: well, we should
<pitti> mwhudson: argh, my upload was rejected, there is a -2.4 stuck in -proposed
<pitti> mwhudson: I'm afraid I can't fix this quickly then
<seb128> pitti, Laney and dobey were discussing s-c but I don't know if that's this bug
<Laney> no I was just fixing the tests
<cjwatson> pitti: you could fix it in -proposed if the version there has the same problem
<cjwatson> pitti: we're working on getting that transition landed
 * pitti re-fixes his apt sources to add deb-src saucy-proposed again
<cjwatson> pitti: pull-lp-source is your friend
<pitti> cjwatson: ah, the -proposed version already drops teh ubuntu specific -dbg handling, so much the better
<seb128> cjwatson, Laney, pitti: do you have any opinion on reverting the python-configglue update to fix u1? I'm pondering doing it ... or maybe I should just wait for barry to wake up to check with him first
<pitti> +1 for reverting
<cjwatson> seb128: I think by now it can wait for barry to wake up ...
<Laney> I'm not massively up to speed with the problem, sorry
<cjwatson> I don't have much of a personal opinion beyond observing that the update added python3 support (afaik) and thus reverting it at this late stage would require checking whether anything's been built on top of that since
<seb128> right, I pinged him yesterday already but nothing happened
<seb128> but yeah, it has been broken for a week, it can be broken for a few extra hours
<pitti> seb128: hm, http://launchpadlibrarian.net/144486841/python-configglue_1.1.0-0ubuntu1_1.1.1-0ubuntu1.diff.gz doesn't seem to have ConfigParser changes?
<pitti> seb128: ah, I guess it wasn't the latest upload, but 1.1.0-0ubuntu1 instead?
<seb128> pitti, the issue started with 1.1.0 not 1.1.1
<pitti> that looks harder to revert
<seb128> yeah :/
<pitti> python3-configglue has zero rdepends, tohugh
<Laney> I think the problem is that the update brings in configparser which causes conflicts or something
<Laney> https://code.launchpad.net/~ricardokirkner/configglue/from-future-remove-configparser/+merge/173806 was posted yesterday
<infinity> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: infinity
 * dholbach hugs infinity
<caribou> I'm working on a patch that requires a modification to configure.ac that comes from upstream
<infinity> caribou: Nothing wrong with that.
<caribou> I suppose that this means that debian/rules needs to run autoreconf but for some reason, it fails on me
<caribou> infinity: well, just changing configure.ac breaks the build :-/
<caribou> infinity: let me paste the error...
<infinity> caribou: One can either use one of the dh autoreconf thingees to sort that out, or your patch can hit configure.ac, configure.in, and configure all at once.
<caribou> infinity: http://paste.ubuntu.com/5861074/
<caribou> infinity: that's what I did : I added an override to dh_auto_configure to run autoreconf before continueing
<infinity> That's not really a helpful error without knowing what it's complainign about, or what your patch is.
<caribou> infinity: just adding /bin/*/libc.so.* to a subshell search with 'ls'
<seb128> caribou, you should better use dh-autoreconf and --with autoreconf
<seb128> caribou, rather overwriting
<seb128> rather *than* overwriting
<infinity> caribou: s/bin/lib/ I assume, though any autoconf check for libc is probably broken by design.
<seb128> (though that will probably not fix your issue if autoreconf fails there)
<infinity> caribou: As seb says, dh_autoreconf is the way to do this, but I'm curious as to what your patch is and why it's needed in the first place.
<caribou> oh, btw if I rm acinclude.m4 & rerun autoreconf --force --install in the schroot it works
<caribou> infinity: let me paste it...
<caribou> infinity: http://paste.ubuntu.com/5861086/
<caribou> seb128: ok, I'll do that
<infinity> caribou: I think what I was driving at is *why* does it do that?  Nothing should need to know the path to libc.
<cjwatson> Yeah, dh-autoreconf is the way, the truth, and the life
<seb128> caribou, hum, for that patch you might want to try to make the change the configure manually as well and avoid autoreconfing at all
<caribou> infinity: well danted fails to start because it cannot find the lib. I'm just following pitti's advice on the bug; let me dig it
<cjwatson> seb128: ugh
<cjwatson> patching autogenerated files is a timebomb
<caribou> 557918
<infinity> caribou: I don't doubt that the patch is necessary in the current incarnation of whatever crazy thing the package is doing, I'm just arguing that fixing it to DTRT is better than perpetuating hacks, especially if it's going to be upstreamed.
<seb128> cjwatson, well, patching both configure.ac and configure should be fine ... but yeah, better to autoreconf when you can
<infinity> cjwatson: I do it all the time (patching the source *and* the generated file, never just the latter)
<seb128> cjwatson, sometime you can get away with patching the autogenerated ones though
<cjwatson> sounds like you need to find the bug in acinclude.m4 and patch that so that autoreconf works
<cjwatson> infinity: For "timebomb", I meant just the latter.  But the more I work with dh-autoreconf the more I find it night-and-day from previous "patch both files" approaches.
<caribou> infinity: here's the bug : https://bugs.launchpad.net/ubuntu/+source/dante/+bug/1124048
<ubottu> Launchpad bug 816153 in dante (Ubuntu Precise) "duplicate for #1124048 dante-server using the wrong libc.so" [Medium,Triaged]
<caribou> sorry I pasted the Dupe : https://bugs.launchpad.net/ubuntu/+source/dante/+bug/816153
<ubottu> Launchpad bug 816153 in dante (Ubuntu Precise) "dante-server using the wrong libc.so" [Medium,Triaged]
<caribou> btw, I had the same build failure before adding the autoreconf bit
<caribou> well, this was last night, need to test it again
<infinity> dlopening libc makes me a sad panda.  But fixing that looks like it would be a massive patch.
<infinity> caribou: You could just add --with-libc=libc.so.6 to configure.
<caribou> infinity: isn't that hardcoding the version ? not that it should change much
<infinity> caribou: It is, and it's wrong for Debian (since it's not always 6)
<infinity> caribou: Meh, I guess fixing their weird search works.
<infinity> Fixing their dlopens would be better, but that looks painful.
<caribou> ok FYI, just patching configure.ac & rebuilding w/o autoreconf yield to the same error
<caribou> full build error : http://paste.ubuntu.com/5861110/
<caribou> well doesn't look like there is an easy answer to that; sorry to bring that noise
 * Laney hears Public Enemy
<infinity> caribou: That just looks like a missing build-dep.
 * infinity tests here.
<cjwatson> patching configure.ac and rebuilding without autoreconf is always wrong
<caribou> infinity: I added automake1.9 but it didn't change a thing
<cjwatson> and the failure is strictly less interesting than what you get from autoreconf
<caribou> cjwatson: yeah, I know I figured out the autoreconf afterward (I'm an autotool noob)
<cjwatson> don't add automake1.9, that entire path is unreliable and not worth debugging
<caribou> cjwatson: but I seem to get the same failure with & without the autoreconf
<infinity> I wish I hadn't read that debian/rules.
<cjwatson> caribou: that's as may be, but without autoreconf you get a weirder set of failures appended that you really do not want to debug
<cjwatson> take my word for that :)
<cjwatson> that's one reason I prefer the dh-autoreconf approach, because it makes us make things easier for other people modifying the source
<caribou> cjwatson: I can add that in my patch, since it won't build without. Or a separate quilt patch ?
<infinity> Yeah, I wouldn't argue against the m4 being fixed regardless.
<cjwatson> i.e. if somebody had converted this to dh-autoreconf before, then we'd have seen this as a build failure at the very least and you wouldn't have been dragged into this
<cjwatson> caribou: I'd do it in a separate patch but I don't think it's that important
<cjwatson> however:
<cjwatson> once you patch a .m4 file, you'll probably find that the maintainer-mode rules evidently in use here will try to rebuild Makefile.in files and such
<infinity> Besides, my patch could get you into timestamp skews and force and autoreconf which would hit build failures anyway. :P
<cjwatson> so I don't think fixing acinclude.m4 is compatible with infinity's patch-the-generated-file-as-well approach
<infinity> s/and/an/
<infinity> caribou: Just fix it all and autoreconf.  Being in maintainer-mode makes this a bit of a nondeterministic rabbit hole if you don't.
<cjwatson> so I would: (a) add a patch adding a blank line to the end of acinclude.m4 (b) add a patch for the configure.ac fix you were trying to apply in the first place (c) make the package b-d on dh-autoreconf and use it
<cjwatson> should be safest all round
<caribou> cjwatson: ok, will do that & let you know that comes out
<caribou> it will have to be sponsored anyway
<caribou> cjwatson: infinity thanks for the valuable help & learning experience :)
<zyga> pitti: quick question, your upower test code uses Gio.DBuxProxy, is there any advantage over using python-dbus proxy objects?
<pitti> zyga: not much except avoiding yet another dependency
<pitti> I already need GI there anyway, so I'm using the GI bindings instead of python-dbus
<zyga> ok, thanks for the explanation
<pitti> zyga: but they are both roughly equivalent in terms of comfort and functinoality
<zyga> I was just looking for hidden dependencies
<ev> pitti: do you have any time today to discuss whether https://code.launchpad.net/~ev/apport/automatic-reporting/+merge/173553 is the correct approach?
<pitti> hey ev
<pitti> ev: still catchign up with stuff after my short holidays; I haven't yet looked at it, but will do this afternoon
<ev> pitti: awesome, thank you. And welcome back :)
<pitti> ev: reviewed, I left some commentary in the MP
<ev> pitti: thanks!
<apachelogger> cjwatson, Riddell: https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1199731
<ubottu> Launchpad bug 1199731 in grub2 (Ubuntu) "config script thinks grub.d contains all variables" [Low,Triaged]
<ev> manish: also, I'm going to split the dbus service out of activity-log-manager as I need it available for the mobile platform settings
<ev> the WhoopsiePreferences service, that is
<cjwatson> apachelogger: thanks, fixed in Debian bzr now: http://paste.ubuntu.com/5861279/
<apachelogger> weeh
<apachelogger> cjwatson: will that land in saucy?
<cjwatson> Yeah
<cjwatson> I'll probably roll up an unstable upload this weekend, and merge it
<cjwatson> if that's OK
<apachelogger> cjwatson: awesome :)
<apachelogger> Riddell: ^ we'll have plymouth again ;)
<Riddell> apachelogger: ooh exciting
<mlankhorst> sforshee: bisected
<mlankhorst> I hate guessing correctly
<mlankhorst> 1acba98f810a14b1255e34bc620594f83de37e36
<mlankhorst> breaks my macbook efi boot
<mdeslaur> cjwatson: did rbasak get back to you regarding the php5 merge?
<cjwatson> mdeslaur: Not as yet
<zyga> pitti: I cannot import Gio.TestDBus, is that available on precise?
<halfie> during the process of building packages, is accessing internet OK or is it forbidden?
<ogra_> forbidden ...
<cjwatson> accessing internet resources other than the archive itself (for build-deps and the like) is a recipe for unreliability anyway
<pitti> zyga: ah, it was added in glib 2.33, so no
<pitti> zyga: OOI, why do you need this on precise?
<halfie> cjwatson, agreed. I was wondering how you guys are able to build scala without internet access
<halfie> while building scala, ant does some dependency resolution and downloading
<zyga> pitti: welcome to the PES area, everything we do needs to be on precise
<zyga> pitti: I started running precise not to get used to all the shiny good stuff added later
<pitti> well, that's why we call it a development release :)
<zyga> pitti: can I somehow spawn dbus as non-root and use it to register my service there
<zyga> pitti: well, 12.04 is quite older than 12.10 and 13.04
<pitti> zyga: so you won't have umockdev either; if you need this, I'll need to jump through some hoops
<zyga> pitti: it's not about saucy sadly :/
<pitti> zyga: sure, all of this (like upower's test suite) runs as normal user
<zyga> ok
<zyga> thanks!
 * ogra_ hopes pitti at least takes a video for us when doing that :)
<pitti> zyga: dbus-launch just starts a session bus
<pitti> ogra_: tried, but broke the camera during jumping!
<ogra_> haha
<caribou> infinity: cjwatson: Does that look like a decent use of dh_autoreconf : http://paste.ubuntu.com/5861491/
<caribou> I patched acinclude.m4 so I no longer have the aclocal failure
<caribou> but it now fails at compilation :-/
 * caribou is wondering if those kind of questions would be better suited for  #ubuntu-app-devel
<smoser> not a big deal, and i'm just going to not upgrade right now
<smoser> but
<smoser> http://paste.ubuntu.com/5861525/
<roaksoax> smoser: don't dist-upgrade :)
<smoser> (alpine and firefox are specifrically held) but the xserver stuff is odd and rmoving ubuntu-desktop didn't seem right.
<smoser> specifrically .
<roaksoax> smoser: yeah someone reported something similar over the the ML
<roaksoax> smoser: but i have the latest upgrades and have not seen any issues
<smoser> odd.
<roaksoax> but better to hold off
<roaksoax> smoser: do you have -proposed enabled? maybe that's it?
<smoser> doesn't look like it.
<rbasak> cjwatson, mdeslaur: sorry, I'm working on it (php merge)
<mdeslaur> rbasak: thanks
<dobey> if i add autopkgtest support to a package, and upload it, how long before i see those tests happening on jenkins?
<jibel> dobey, when binaries are in -proposed
<dobey> jibel: and if i don't see the tests on jenkins, even after the binaries are in release?
<jibel> dobey, which package?
<dobey> jibel: dirspec
 * jibel looks
<rbasak_> Is there any need to prefer libpng12-dev when a package in main depends on libpng-dev, and the only thing that provides libpng-dev is libpng12-dev in main?
<rbasak_> I presume not, unless we do something to avoid future breakage or something. But if the buildd doesn't include universe, I don't see that it would break.
<dobey> jibel: i take it you didn't find it either? :)
<jibel> dobey, still looking, but right I didn't find why yet
<jibel> cjwatson, I cannot see why dirspec tests have not been requested, would you know? I can see it for the first time in 2013-07-09/22:09:33.log but there has never been any test request
<cjwatson> halfie: I don't know specifically about scala.  Usually Java packages build-depend on packaged versions of the things they need and I think there's some scheme to stop ant going off to the network
<cjwatson> caribou: Fine as far as it goes, but you need to call dh_autoreconf_clean immediately before dh_clean too
<caribou> cjwatson: ok, will  do that. unfortunately, right now, this breaks compilation later on
<cjwatson> rbasak_: You need to explicitly prefer libpng12-dev so that germinate knows which to prefer
<rbasak_> OK, thanks
<cjwatson> rbasak_: However, are there any other providers of libpng-dev in universe, even?
<rbasak_> cjwatson: not that I can see
<cjwatson> rbasak_: I don't see any - which means it's unambiguous and you can just Build-Depends: libpng-dev
<rbasak_> OK
<cjwatson> rbasak_: It's just that "only one in main" isn't enough
<rbasak_> Right. Useful to know - thanks.
<rbasak_> Two more issues. Is there a standard answer for a build depends on "locales-all | language-pack-de"? I don't see any locales-all package.
<cjwatson> jibel: Unfortunately I don't have any more data than what's in that log :(
<cjwatson> rbasak_: locales-all is in Debian
<rbasak_> And there's a Suggests on php5-json, which we don't seem to have imported. I could drop that entirely, but I wonder why we're not importing it at least into universe?
<cjwatson> rbasak_: So that looks like a build-depends constructed to do the right thing on both distros
<rbasak_> s/Suggests/Recommends
<rbasak_> OK - great.
<cjwatson> rbasak_: php-json has source in the archive but is waiting for a json-c merge before it can build.  https://launchpad.net/ubuntu/+source/php-json/0~git~1+c05ebf+dfsg-2/+build/4638791
<cjwatson> Which should be on jodh`'s list by default, I believe, since he touched it last
<cjwatson> rbasak_: You should leave the Recommends in place anyway, IMO
<cjwatson> Unsatisfied Recommends are maybe unsightly but don't cause a problem, and in this sort of case where they're expected to turn up eventually, better to leave them there
<rbasak_> I'm a bit confused. In Debian, php5-json's source package is php5-json, which is why I couldn't find it in Debian. You've pointed me to php-json, whose source is in saucy-proposed but the source is in universe.
<rbasak_> why I couldn't find it in Ubuntu
<rbasak_> OK, it looks like my chdist cache was out of date. But if I keep php5-json, I still need to drop it to a Suggests since php5-json wont be in main when it's built, right?
<cjwatson> Well, it's arguable; perhaps it should be promoted?  I don't know, up to you
<cjwatson> rbasak_: And no, in Debian, php5-json's source package is still php-json.
<rbasak_> OK, got it. Thanks for going through this with me.
<ev> anyone know how we're handling policykit on mobile?
<cjwatson> jibel: It kind of looks as though adt-jenkins didn't think it had an XS-Autopkgtest header at the time p-m was processing it, but it's meant to be looking at guaranteed up-to-date Sources files ...
<jibel> cjwatson, it seems that test requests are submitted only on dependency change but not the first time a package is uploaded.
<jibel> for example plv8 yesterday
<cjwatson> jibel: Hmm, it shouldn't make any difference to the code on my side
<jibel> there test as been submitted only when libgcc1 has been uploaded
<dobey> cjwatson: isn't the header XS-Testsuite: ?
<cjwatson> dobey: Sorry, yeah
<cjwatson> Braino
<jibel> dobey, the header is okay, it is a bug in the interface, I'm trying to find where
<jibel> dobey, here you go https://jenkins.qa.ubuntu.com/job/saucy-adt-dirspec/1 and it broke adt-run BTW :/
<dobey> jibel: adt-run was already broken :)
<caribou> cjwatson: any reason why the dh_autoreconf would create a configure script that is sensibly smaller than the one in the tarball ?
<cjwatson> caribou: IIRC autoconf started making use of shell functions to make things more compact
<caribou> cjwatson: it also comes up with many more warnings like "configure: WARNING: unknown option 'enable_dependency_tracking', ignoring ..."
<caribou> cjwatson: ok, I suspected that the newly created configure script was wrong
<cjwatson> caribou: I wouldn't recommend this line of investigation; the odds of success are slim
<cjwatson> caribou: Investigate the compilation failure directly instead.  If it leads you to a bug in the generated configure script, fine
<cjwatson> caribou: The warning you quote is entirely harmless
<caribou> cjwatson: good advice,thanks
<unixabg_> cjwatson: greetings, I have persued the boot iso from hard drive a bit and I would like to ask your thoughts on adding a
<unixabg_> persistent option which could be used as a read only stack against defalut iso images?
<unixabg_> I have read throught the casper code and not sure it is the best thing to offer. But I am not sure how to inject changes
<cjwatson> unixabg_: Sorry, I don't think I can help
<unixabg_> against defalut iso images. Oh ok.
<cjwatson> I only work on casper when I need to fix something specific
<cjwatson> Feel free to send a patch - in this case I suspect you'll have difficulty getting design advice in advance, though, sorry
<unixabg_> Is there a way to inject on boot changes like knoppix or live-boot does with hooks?
<cjwatson> I normally just extract the image by hand and repack
<cjwatson> Or, for small things, break=top and edit it on the fly (although tools are limited)
<unixabg_> Ok I appreciate your assistance and dialog.
<infinity> rbasak: locales-all is a Debian thing, though we may grow it here after I have a talk with pitti.
<jibel> pitti, could you review https://code.launchpad.net/~jibel/ubuntu/saucy/autopkgtest/fix_atmostone/+merge/173965 when you have a second.
<jibel> pitti, do I need to forward it to Debian too or you can fix it in git directly?
<pitti> jibel: I can apply it directly in Debian
<pitti> jibel: is there some existing bug associated with this? (doesn't need one, just checking)
<dobey> barry: can you please review pindonga's configglue branch asap?
<barry> dobey: yes, although right now i'm in a meeting and then i have two other high priority bug fixes to land.  i will definitely get to configglue today
<dobey> barry: ok. i need to make a release of ubuntuone-client, and this is blocking it, as almost all the tests fail as a result :)
<barry> dobey: :(  it's definitely the third top thing on my list ;)
<Sarvatt> barry: updated your bug if you wouldn't mind giving the x-x-v-vmware update a shot, it should fix it and i'll try to get it sponsored if so
<barry> Sarvatt: fantastic, thanks.  it will be a little while before i can test this, but hopefully today if nothing else comes up ;)
<seb128> barry, hey, did you see my ping earlier about reverting python-configglue to unbreak u1?
<barry> seb128: sorry, i did not.  but pindonga has a new version in mp that eliminates the dep.  i plan to review it as soon as my other two higher priority bug fixes have landed ;)
<seb128> barry, just curious, what is higher priority than unbreaking u1 not working at all?
<barry> seb128: phone stuff i have to land
<seb128> barry, hum, k, good luck, I hope you get to the u1 fix today
<barry> seb128: and the meeting i'm in right now ;)
<barry> seb128: i shall not sleep or eat until then :)
<jdstrand> tedg: responding to your email here-- are you implementing the "simple change"?
<jdstrand> tedg: and hi! :)
<tedg> jdstrand, Uhm, sure.  It should be easy.
<tedg> mdeslaur, Did you change it so that the apparmor line in the upstart job can be the null string?
<jdstrand> tedg: well, I wasn't sure what you had in mind
<tedg> jdstrand, I'd like to start using libupstart there, but we can put a quick hack in to call initctl
<jdstrand> tedg: so, short term, what I said, slightly longer term, libupstart?
<tvoss_> slangasek, ping
<tedg> jdstrand, Yeah, I was hoping that we could use the apparmor line in the upstart job instead of calling aa-exec
<tedg> jdstrand, But that doesn't mater too much.
<jdstrand> tedg: right, we will soon, but can't today
<jdstrand> tedg: we still need to know the profile name though and export that as an env var, right?
<tedg> jdstrand, Yup
<jdstrand> tedg: ok, so that part was what I thought you were saying was the simple change, and I was curious how you were going to do it without calling desktop-exec twice
<jibel> pitti, there is no bug associated with this.
<tedg> jdstrand, Flip it so that desktop-exec calls initctl directly.
<jdstrand> ah yes
<jdstrand> tedg: fyi, once that kernel bug is fixed, we can simply do:
<jdstrand> apparmor switch $APP_EXEC_POLICY
<jdstrand> exec $APP_EXEC
<jdstrand> assuming apparmor switch won't barf if APP_EXEC_POLICY is not defined
<jdstrand> mdeslaur: ^
<jdstrand> I wonder if we could do:
<jdstrand> script
<jdstrand>   if [ -n "$APP_EXEC_POLICY" ]; then
<jdstrand>     apparmor switch $APP_EXEC_POLICY
<jdstrand>   fi
<jdstrand>   exec $APP_EXEC
<jdstrand> end script
<jdstrand> I don't know how 'script' works in upstart jobs though...
<tedg> jdstrand, I think that could work, but I thought there was a profile command in the upstart job syntax that mdeslaur added.  We should probably just use that.
<jdstrand> tedg: 'apparmor switch' is the profile command
<jdstrand> tedg: 'man 5 init'
<slangasek> tvoss_: hi
<tedg> jdstrand, Ah, I see.  I don't think that can be used in the script area.  I think that's in the body of the job.
<jdstrand> that is what I kinda figured. so:
<jdstrand> apparmor switch $APP_EXEC_POLICY
<jdstrand> exec $APP_EXEC
<jdstrand> is what we would want, assuming upstart can handle that when $APP_EXEC_POLICY is not defined
<cjwatson> jdstrand: I'm not convinced it will, from the code ...
<jdstrand> well, we can fix that
<tedg> It's just a simple mater of programing.  :-)
<pedronis> Sarvatt: hi, barry pointed me to you about https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-vmware/+bug/1199403, I tried the ppa, it fixed the broken vm I had around, X starts, get greeter, dash looks working
<ubottu> Launchpad bug 1199403 in xserver-xorg-video-vmware (Ubuntu) "Xorg crash" [Critical,Triaged]
<Sarvatt> pedronis: thanks a ton, finding a sponsor now :)
<Sarvatt> going to just do a version update instead since we needed to and it was only 2 commits (both of which would be backported..), just waiting on test builds of http://sarvatt.com/downloads/merges/vmware-saucy/
<seb128> Cimi, ^ is that the issue you are having?
<Cimi> seb128, could be
<Cimi> seb128, you know how I stop the greeter to respawn?
<Cimi> seb128, I can't switch TTY cause it gets back
<seb128> Cimi, boot in recovery mode?
<Cimi> can't
<Cimi> I don't have grub options here :-\
<seb128> Cimi, it's in the grub menu
<seb128> that should give you a text console
<mdeslaur> jdstrand, tedg: that's not what we decided on
<tedg> mdeslaur, For click, yes.  This would be for legacy.
<mdeslaur> jdstrand, tedg: we decided that since desktop-exec needs to spawn a new upstart job anyway, we'd have two different upstart jobs, one for legacy, and one of click
<cjwatson> debs aren't legacy, they're just a different audience
<mdeslaur> ok, wrong terminology
<tedg> I think for user-facing applications they are, no?
<cjwatson> Depends how simple the application is.
<cjwatson> click is quite deliberately not trying to solve all problems.
<mdeslaur> jdstrand, tedg: since desktop-exec knows if a job is click w/apparmor, or a regular app, it simply uses the appropriate upstart job
<tedg> Certainly.  But I can't think of a user application that has those problems.  Almost all are leafs even in a deb repo.
<mdeslaur> jdstrand, tedg: we really shouldn't be running a zillion processes each time a user wants to start something
<tedg> mdeslaur, Yes, the question is about if the non-click application defines an app-armor profile in it's desktop file.
<mdeslaur> tedg: we don't support that
<cjwatson> Plenty of user applications don't fall within the limited set of frameworks permissible in click packages, or have non-trivial additional dependencies.
<cjwatson> They're just not the sort of thing you'd generally run on a phone.
<mdeslaur> tedg: they can use path based attachment for that
<jdstrand> mdeslaur: well, why can't we support it?
<tedg> Apps packaged with Click aren't only for phones.  And I may also use my phone connected to a monitor and keyboard.
<Cimi> Sarvatt, works for me too with vmware ^^
<jdstrand> mdeslaur: it is already implemented in upstart-app-launch
<mdeslaur> jdstrand: because we don't care?
<Sarvatt> its uploaded so that nightmare will be over soon :)
<jdstrand> sure we do
<mdeslaur> jdstrand: of course not
<jdstrand> traditional packaging isn't going to magically disappear
<tedg> mdeslaur, I think we care as a migration strategy.
<jdstrand> it isn't difficult, ted already implemented it
<mdeslaur> ok, so implement a third upstart job for regular apps that specify an apparmor profile
<mdeslaur> no biggie
 * jdstrand -> phone
<mdeslaur> but much better than spawning a zillion processes and mangling environment variables
<mdeslaur> tedg: where's the upstream tree reside now?
<tedg> mdeslaur, We only increase the number of processes by one if they've defined a profile, otherwise it's a wash.
<tedg> jdstrand, Can you try: lp:~ted/upstart-app-launch/split-profile
<tedg> mdeslaur, lp:upstart-app-launch
<mdeslaur> tedg: ok, now I fail to understand all the stuff that's in upstart-app-launch
<jdstrand> mdeslaur: to echo tedg's comment, it is very lightweight right now
<mdeslaur> jdstrand: I disagree...we're spawning helpers, shells, etc.
<mdeslaur> far from lightweight if you ask me
<jdstrand> its one process
<jdstrand> desktop-exec
<mdeslaur> jdstrand: but you've got "script" stanzas all over
<mdeslaur> jdstrand: which spawns shells
<jdstrand> it is launched for click, we can also launch it for legacy/traditional
<jdstrand> aiui, that isn't for the apparmor bits, that is for application lifecycle tracking
<jdstrand> (the post ones that is, the pre is the one I am referring to
<jdstrand> )
<mdeslaur> jdstrand, tedg: ok, I'm going to leave you two figure it out, as I'm getting dizzy just thinking of how complex this has gotten
 * jdstrand doesn't see how it is so complex
<jdstrand> it is an upstart job that calls desktop-exec to in a pre-script to set two env vars
<jdstrand> (well, atm it is just one, but we want two)
<jdstrand> desktop-exec is needed to handle parsing the manifest file
<jdstrand> tedg just made it able to parse a desktop file too
<jdstrand> (and honor XCanonicalAppArmorProfile=<profile> if it is set)
<jdstrand> people can of course continue to use path-based attachment, but that doesn't always work fantastic with interpreted programs, like we've seen with qmlssene
<mdeslaur> so you have 1- an upstart job, which spawns 2- a shell, which spawns 3- another upstart job, which spawns 4- another shell, which spawns 5- desktop-exec, which opens 6- the manifest file, and opens 7- the desktop file, which spawns initctl to set the variable and then finally spawns the calculator
<cjwatson> tedg: And click isn't for all apps, just the common case that is sufficiently simple.
<cjwatson> tedg: I have absolutely no intention of perpetrating second-system-effect by making the mistake of scoping them too widely.
<jdstrand> note, I was speaking only of application-legacy.conf, not the whole scheme of determining if something is legacy or not
<tedg> mdeslaur, If we could have the apparmor switch command handle the NULL case we could probably just drop the sub jobs.
<jdstrand> tedg: is your thinking that desktop-exec would look at the manifest, then if it didn't exist, look at the desktop file?
<tedg> jdstrand, Uhm, not sure exactly what would do it.  But something like that.
 * jdstrand nods
<tedg> I don't think it could be called "desktop-exec" anymore :-)
<jdstrand> heh, yeah
<tedg> I think we could have one *something* in pre-start and that would set the vars for the job.
<jdstrand> tedg: yep
<mdeslaur> tedg, jdstrand: ok, if that will simplify it, let me fix upstart to skip stanzas that are null
<mdeslaur> s/stanzas/switch stanzas/
<mdeslaur> tedg: what uses lsapp?
<tedg> mdeslaur, Nothing, just me to debug
<tedg> mdeslaur, Doesn't work with the split right now though.  Should work if we can reunify.
<mdeslaur> tedg: is that the code that will send a message if the app is already running?
<tedg> mdeslaur, I haven't written that code yet.
<tedg> mdeslaur, It's just a utility to list instances in a sane way.
<mdeslaur> oh! my mistake
<mdeslaur> tedg: so how is the message code going to be run?
<mdeslaur> tedg: I think we need to start a diagram or something :P
<tedg> mdeslaur, Hmm, good point.  I was going to do that in the application job.  Still might have to have two layers.
<tedg> mdeslaur, initctl2dot  ;-)
<mdeslaur> oh. wow. :)
<infinity> tedg: I thought you were joking.  initctl2dot(1) convinced me otherwise.
<tedg> Ha, I never joke about visualizations :-)
<mdeslaur> tedg: got a few minutes to mumble/hangout?
<mdeslaur> tedg: I have a few random thoughts to throw at you
<tedg> mdeslaur, Back from lunch, anytime.
<mdeslaur> tedg: want to start a hangout?
<tedg> mdeslaur, Uhm, no, you start it.  /me can never figure it out :-)
<mdeslaur> tedg: https://plus.google.com/hangouts/_/62f0f0f42b1b8fc854906922474629e2c7556059?authuser=1&hl=en
<mdeslaur> wow, I can't believe I managed
<xnox> interesting on doing android build I'm getting zero ccache hits
<cjwatson> tjaalton: reminder to fakesync/merge (as appropriate) libapache2-mod-nss ...
#ubuntu-devel 2013-07-11
<pitti> Good morning
<ajmitch> morning pitti
<tjaalton> cjwatson: right, it didn't work yet the other night
<tjaalton> cjwatson: went fine this time
<vipzrx> how can I found the gcc search path for include<XXXX.h> ?
<ScottK> Any reason canonical-qt5-edgers PPA is building 5.0.1 when both 5.0.2 and 5.1 are out?
<vipzrx> ScottK:  hello
<vipzrx> I want to know the location of some header files in a .c file , how can I di it ?
<pitti> vipzrx: check the output of e. g. echo '#include <stdio.h>' | gcc -E -
<vipzrx> thank you pitti
<vipzrx> I am raeding the android source code with emacs+cedet
<vipzrx> when I am reading the source code , the cecet tells me that it can not find some header files location . Now I must tell the cedet where are these header files /
<pitti> vipzrx: http://stackoverflow.com/questions/344317/where-does-gcc-look-for-c-and-c-header-files
<vipzrx> On the other hand ,the source of android is builded with export TARGET_TOOLS_PREFIX=prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8-linaro/bin/arm-linux-androideabi-
<vipzrx> it is not the native gcc
<vipzrx> http://gcc.gnu.org/onlinedocs/gcc/Directory-Options.html  I have read this ,but I have no idea.sorry
<vipzrx> pitti:  ?
<vipzrx> I am using a cross toolchain for arm
<vipzrx> export TARGET_TOOLS_PREFIX=prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8-linaro/bin/arm-linux-androideabi-
<pitti> vipzrx: I gave you the link to stackoverflow; just call the cross gcc instead of just "gcc"
<vipzrx> I got a error
<vipzrx> http://paste.ubuntu.com/5864027/
<vipzrx> http://paste.ubuntu.com/5864030/
<vipzrx> zai
<pitti> well, obviously you didn't install the header files
<vipzrx> I have got the linaro android source
<vipzrx> /home/jb/Documents/soft/soft_src/panda-linaro/system/core/init/init.c
<vipzrx> http://snapshots.linaro.org/android/~linaro-android-member-ti/panda-linaro/347/linaro_android_build_cmds.sh
<vipzrx> linaro does not ask to isntall the header , I think
<vipzrx> linaro_android_build_cmds.sh is the autorun script to download the source and build the android
<dholbach> good morning
<seb128> slangasek, thanks for uploading the configglue revert
<infinity> @pilot out
<infinity> *cough*
<infinity> Hrm, the bot seems to have died.
<mlankhorst> so it would seem :o
<mwhudson> doko: hi, i have a python test suite hang on armhf ig you want a look
<doko> mwhudson, not really this week ...
<mwhudson> :)
<mwhudson> doko: i'll file a bug when i've figured something out
<sil2100> Wellark_: ping!
<mwhudson> doko: the hanging test case is in a class called SignalsTest which makes me unhappy
<cjwatson> tjaalton: Thanks
<xnox> cjwatson: is http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ch-archive.html#s-multiverse authoritative ? Since http://www.ubuntu.com/about/about-ubuntu/licensing doesn't say multiverse requirements.
<cjwatson> xnox: Yes
<xnox> thanks.
<cjwatson> Once upon a time there was something useful elsewhere about that, I think, but in any case that was common understanding among archive admins when I wrote it
<xnox> cjwatson: i think there are packages in multiverse that discriminate against persons, groups or against fields of endeavour. Is that ok?
<cjwatson> xnox: Yes
<xnox> ok.
<cjwatson> xnox: (as explicitly stated in the link you gave)
<xnox> cjwatson: =))))
<xnox> ah, need more coffee.
<caribou> cjwatson: infinity: I'm still having issues with my dante/autotool issue you helped with yesterday. where should I go to ask for help ?J
<caribou> not sure #ubuntu-devel is the appropriate place
<cjwatson> caribou: pastebin the failure
<cjwatson> (and your current working patch)
<caribou> cjwatson: ok, I'll reproduce again as I'm working on two options
<caribou> cjwatson: http://paste.ubuntu.com/5864483/
<caribou> cjwatson: as you suggested yesterday, I investigated the source of the compilation failure
<caribou> cjwatson: which seems to be caused by a missing HAVE_EXTRA_OSF_SYMBOLS which has nothing to do with us
<cjwatson> caribou: It may not be relevant but given that clean rule you should drop your dh_override_clean and instead call dh_autoreconf_clean just before the two dh_clean calls
<cjwatson> Indeed you can also drop "cp /usr/share/misc/config.guess /usr/share/misc/config.sub ." and drop the "config.guess config.sub" arguments from dh_clean, since dh_autoreconf[_clean] will take care of those
<cjwatson> now let's look at the actual failure ...
<cjwatson> Those are configure-generated type names so I can certainly see why that might be related
<cjwatson> caribou: You really ought to be doing this work in saucy first, BTW.  Just trying to build it now
<caribou> cjwatson: indeed
<caribou> cjwatson: I'm pondering if just going with changing configure.ac & configure would be less of a waste of time
<cjwatson> caribou: Let me have a look first
<cjwatson> The problem is, it might be slightly less of a waste of time for you, but it's leaving a problem for future developers
<cjwatson> We should try to avoid generated scripts in the archive that break when regenerated
<cjwatson> The difference is because new versions of Autoconf cause AC_AIX to be equivalent to AC_USE_SYSTEM_EXTENSIONS, but dante's very strange generation of sockaddr argument types apparently can't cope with the way glibc declares things when _GNU_SOURCE is in effect.  The most pragmatic fix appears to be to add a patch commenting out "AC_AIX" in configure.ac, since we clearly don't care about that.
<cjwatson> caribou: ^
<cjwatson> caribou: But OMG, somebody has *already* left a timebomb in dante: look at debian/patches/03-configure.patch
<cjwatson> That's a horrifyingly bad patch
<cjwatson> caribou: So maybe your best alternative is to go with the flow and patch both configure.ac and configure after all :-(
<cjwatson> Given that the Debian maintainer has been either negligent or incompetent in this case
<cjwatson> (You might patch out the "sleep 10" while you're at it so that configure is less annoying about options it doesn't recognise ...)
<caribou> cjwatson: hmm ok I'll take your advice on that
<cjwatson> The alternative is taking on the tech debt of refactoring 03-configure.patch as a proper patch to the source files, or calling configure in a different way, or whatever
<caribou> cjwatson: If I may ask, can you add a task for saucy to the LP bug so I can go back to SRU logic ?
<caribou> https://bugs.launchpad.net/ubuntu/+source/dante/+bug/816153
<ubottu> Launchpad bug 816153 in dante (Ubuntu Precise) "dante-server using the wrong libc.so" [Medium,In progress]
<cjwatson> caribou: the task without a series is implicitly for saucy.
<cjwatson> no need to create an explicit saucy task.
<caribou> cjwatson: ah, ok, wasn't sure
<cjwatson> I'm going to file a Debian bug about that patch to a generated file
 * caribou must review the wiki again before sending the email to be added to UbuntuBugControl
<caribou> cjwatson: once again thanks for the help & advice
<infinity> Note that there's probably a semi-valid reason the current patch only touches configure and not configure.ac
<infinity> Patching both appears to trip maintainer mode and try to regen.  Yay abuse of autotools.
<infinity> (But yes, the right thing to do in Debian would be to make dh_autoreconf work with the package)
<cjwatson> But hence dh-autoreconf.
<cjwatson> I'll send a bug with detailed advice.
<infinity> The above was just my hinting that caribou's path of least resistance (especially for an SRU) would be to patch *only* congfigure, as wrong and ugly as that sounds.
<cjwatson> You may, sadly, be right.
<caribou> infinity: I would prefer to go the dh-autoreconf way as well, if it was not so time consuming for a package that seems rather 'dormant'
<infinity> caribou: Well, dh-autoreconf is the right thing to suggest in Debian and try to get fixed.
<infinity> caribou: For an SRU, the minimally invasive 1-line patch directly to configure will get the job done, though.
<infinity> (And has precedence in the current broken packaging)(
 * infinity notes that the Debian patch to configure is also incorrect for other reasons...
<infinity> Hardcoded path to libdl that no longer lives there.
<infinity> Whee.
<caribou> infinity: out of curiosity, can quilt touch the same file with to separate patches ? I mean my patch will come on top of this 03- one, right ?
<infinity> Yeah, you can patch the same file as many times as you want.
<infinity> They just have to stack.
<caribou> infinity: ok, thanks
<caribou> I'll get the debdiffs in after lunch
<caribou> I will also try to summarize our discussions in the bug to leave a trace of the analysis
<shadeslayer> Laney: question, account-plugin-groupwise depends on empathy, any reason why? aren't each of the account-plugins designed to work with the Telepathy framework? or do they only work specifically with empathy?
<cjwatson> caribou: You might need to fix the libdl path too, for much the same reason.  I noticed it mentioned in another bug
<shadeslayer> Laney: the other account plugins depend on empathy as well
<caribou> cjwatson: ok, will do
<Laney> shadeslayer: Not sure - I guess it was like that before I touched the package
<Laney> shadeslayer: Ask kenvandine maybe
<shadeslayer> Laney: same thing with unity-asset-pool
<caribou> cjwatson: https://bugs.launchpad.net/ubuntu/+source/dante/+bug/890887 ?
<ubottu> Launchpad bug 890887 in dante (Ubuntu) "socksify try to LD_PRELOAD a missing library" [Undecided,Confirmed]
<shadeslayer> not quite sure why it's there in Depends, imho unity should depend on that, and not the account plugins
<shadeslayer> ( and unity already does )
<shadeslayer> will ask kenvandine when he comes online
<Laney> presumably it uses icons only provided there?
<infinity> caribou: In fixing the libdl path, revert the Debian patch that hardcodes it and go back to fixing the detection code like you did for libc.
<infinity> caribou: Cause hardcoding won't work in a multiarch world, obviously.
<caribou> infinity: indeed. ok, I'll work on that & come back here so you can review the changes if you don't mind
<caribou> though that will be part of the sponsoring phase anyway
<infinity> caribou: *nod*
<infinity> caribou: I can sponsor all the uploads once we're happy with them.
<cjwatson> caribou: Yes, though I only skim-read it
<caribou> good. lunchtime now
<shadeslayer> Laney: not sure, I see some icons in the source
<shadeslayer> Laney: ./data/icons/hicolor_apps_48x48_im-facebook.png
<cjwatson> caribou: FYI, I filed Debian #716681
<ubottu> Debian bug 716681 in dante "dante: patches generated configure file without corresponding patches to true source; incredibly confusing build system" [Normal,Open] http://bugs.debian.org/716681
<sil2100> Wellark_: hi! Are you around right now?
<caribou> cjwatson: looking at the bug; now that I'm at it, would be be too much work to try to fix this myself (with some help from charitable  souls) ?
<cjwatson> caribou: Don't know, depends how much you fancy diving into the deeper corners of the autotools
<cjwatson> caribou: The fix will probably wind up being too complex for precise, at least ...
<caribou> cjwatson: hmm, I think I have better use of my current cycles; PlusOne being one of them
<caribou> cjwatson: ok, will go for the easy way out
<smoser> @pilot in
<smoser> @pilot-in
<udevbot_> Error: "pilot-in" is not a valid command.
<ev> pitti: apologies for the delay. I've fixed the problems pointed out in https://code.launchpad.net/~ev/apport/automatic-reporting/+merge/173553
<smoser> udevbot_, doesn't want to pilot-in me.
<udevbot_> Error: "doesn't" is not a valid command.
<ogra_> your first command was ok ...
<ogra_> not sure why it didnt pick it up
<seb128> ogra_, smoser: should the bot be op to be able to change the topic?
<ogra_> seems infinity had issues with it too (when signing off from it)
<seb128> dholbach, ^ do you know?
<ogra_> oh, since when is the topic not changeable anymore
<ogra_> thats crap
<pitti> ev: splendid, thanks! I responded with two final nitpicks
<infinity> Probably since services exploded yesterday.
<infinity> Could use a channel op to fix it.
<geser> so you are the pilot till it gets fixed? :)
<infinity> geser: Apparently. :P
<ev> pitti: will fix and merge! Thanks!
<ev> exciting!
<infinity> @pilot out
* udevbot_ changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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:
<infinity> cjwatson: Thanks.
<cjwatson> np
<cjwatson> Though udevbot was supposed to have +t anyway.
<ev> We're getting quite close with the mobile crash reporting stuff. If only I could get system-settings (QML) to not produce a solid black window since upgrading virtualbox.
<cjwatson> I bet it isn't identified.
<seb128> no fun, I was looking forward having infinity being sponsor every day :p
<smoser> @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: smoser
<dholbach> seb128, :)
<seb128> dholbach, unping ;-)
<caribou> can someone explain the use of $QUILT_STAMPFN in debian/rules ?
<caribou> or point to where  I can find info
<infinity> caribou: See /usr/share/quilt/quilt.make
<caribou> infinity: thanks
<shadeslayer> kenvandine: hi, I was wondering why each of the account-plugin packages made from empathy ( the source ) depend on empathy ( the binary )
<kenvandine> because they depend on a private lib empathy ships
<kenvandine> empathy upstream maintains that
<kenvandine> it is far from ideal
<slangasek> seb128: configglue revert> sure thing - did that fix all the problems you were seeing?
<seb128> slangasek, yes, u1 works correctly again (file syncing, sharing, control panel, indicator)
<dholbach> barry, are you planning to upload some of the downloader changes to saucy soon?
<barry> dholbach: do you mean the new download service, or the client updater?
<dholbach> barry, I think the former
<barry> dholbach: check with mandel; he was working on a packaging branch
<caribou> if I touch configure.ac & configure from upstream tarball, what do I need to do to have them appear as pristine ?
<dholbach> barry, I was just wondering if it'd make sense to get it on the images soon, so stuff can start using it, even if it's not 100% there yet
<caribou> right now, I must touch aclocal.m4 & Makefile.in to have it build
<caribou> so I suppose that there is a cleaner way of doing this
<barry> dholbach: yes, i think it is worth doing, even though the upgrader client doesn't use it yet.  i'm not sure whether the click infrastructure uses it yet, but my guess is no
<barry> dholbach: i don't see mandel online atm
<infinity> caribou: Is patching configure alone not enough?  Given that the package already does this, it would seem like it would be.
<caribou> infinity: just wanted to follow previous advices & touch them both. I guess it's useless given the current nature of the package
<caribou> infinity: I would still be curious to know how it's done
<infinity> caribou: Yeah, your path of least resistance here is just to do what the maintainer's already done, as wrong as it is.  Half-assing an in between solution isn't worth the effort.
<caribou> infinity: well other than dh-autoreconf which *is* the proper way
<caribou> infinity: true
<caribou> infinity: but is there a way to do that, if it was the correct way ?
<caribou> infinity: I was a bit surprized as I tried your patch of  yesterday and got the same result. Maybe I'm using quilt the wrong way
<infinity> caribou: There are ways to touch all the right files in the right order to fool it, but it's not worth the effort.  The autotools-dev README used to have an in-depth explanation that they've now replaced with "use dh_autoreconf".
<infinity> caribou: My patch will still trip maintainer mode.  If you drop the change to configure.ac, it should be fine.
<caribou> infinity: ok. what's maintainer mode btw ?
<infinity> caribou: It's autotools' way of saying "I'm the upstream maintainer of this project, and when I change files, I want you to regenerate everything".
<caribou> infinity: ah; ok
<infinity> caribou: Generally meant to be turned off in make dist when generating a tarball for distribution, but not everyone does.
<cjwatson> caribou: Having to touch individual files is only a problem if you aren't using autoreconf.
<cjwatson> caribou: But we've already established that you can't do that here, sadly.
<cjwatson> There isn't a correct way to do it because you're in incorrect land.
<caribou> cjwatson: indeed. I'll follow infinity's advice & only touch configure
<Laney> zul: your recent python-coverage upload took away /usr/bin/python-coverage
<zul> Laney:  crap ill fix it
<Laney> zul: also I think you installed a load of python3 files into python-coverage by mistake
<Laney> e.g. try to install both packages at the same time
<zul> Laney:  k
<doko> infinity, where are you?
<infinity> doko: Upstairs, where the wired internet doesn't suck. :P
<infinity> doko: What's up?
<pindonga> hi barry dobey
<pindonga> just wanted to let you know I've updated the configglue mp
<pindonga> after your reviews
<doko> xnox, could you merge lvm2 again, or update the config.* for arm64?
<doko> dannf`, ^^^
<doko> away in a few minutes
<dobey> pindonga: hi. i saw. thanks
<pindonga> dobey, ty
<doko> https://launchpad.net/ubuntu/+source/apr/1.4.8-1ubuntu1
<ahasenack> hi, I don't know if somebody can help with a silly issue with an upstart job
<ahasenack> I can't get "console output" to actually allow my job to print out anything
<ahasenack> lemme pastebin
<ahasenack> http://pastebin.ubuntu.com/5865682/
<ahasenack> what am I missing?
<ahasenack> the real job is something else. It's failing to start and printing the reason to stderr, but I don't see it when I start it, and I'm debugging why
<ahasenack> this on precise, upstart 1.5
<smoser> console output is /dev/console
<smoser> ahasenack,
<smoser> i thikn you rpbably want 'console owner'
<ahasenack> so, physical screen
<ahasenack> console owner didn't change a thing
<smoser> well, /dev/console. (that could be ttyS0 or a vga device, which might have gotten re-tied up to console-9 or something)
<smoser> oh.
<ahasenack> and exit status is 0
<smoser> well hten i'm not sure.
<smoser> if you just want to see the output
<smoser> then upstart stores that for you in /var/log/upstart
<ahasenack> yeah, with console log
<ahasenack> not the other options
<ahasenack> I get exit status 1 if I add "task" to the config
<ahasenack> since this isn't a daemon
<smoser> well that makes sense.
<smoser> i swear that console owner used to do whtat you want.
<smoser> but i dont know.
<smoser> and the documentation disagrees with my memory
<ahasenack> even the 6.4.3.1 example doesn't work 100% like it says there, I get the msg in /var/log/syslog, but nothing in my "console" (ssh)
<ahasenack> slangasek: hi, around? Do you know what's missing to get the "echo" output in my terminal in this paste? http://pastebin.ubuntu.com/5865727/
<dobey> it *is* ok to have a package which is in universe, listed in the Depends section of debian/tests/control for a package that is in main, right?
<slangasek> ahasenack: the output never goes to the terminal; 'console output' goes to /dev/console
<ahasenack> slangasek: is there a way for it to go to the terminal?
<slangasek> ahasenack: no
<slangasek> ahasenack: unless you want to wrap things to dump /var/log/upstart/$job
<ahasenack> slangasek: so if I'm deploying something remotely, I can't see the errors I would if this were a normal sysv initscript? Like
<ahasenack> ssh server service foo restart
<ahasenack> I will have to check that /var/log/upstart/$job file and use "console log"?
<smoser> console log is the deafult.
<smoser> when i'm debugging i often wrap any scripts in
<smoser> { } >/tmp/my.log 2>&1
<ahasenack> well, it's not debugging, the service is reporting why it doesn't start, but it's lost
<ahasenack> the caller has to check another log file to try to find out, and even make sure the lines in that log file are recent
<ahasenack> meh
<smoser> yeah.
<ahasenack> all because go doesn't work
<ahasenack> fork
<ahasenack> not work
<ahasenack> so I was switching to upstart, so I wouldn't have to use start-stop-daemon's -b (background), where I can't check if the service startup worked or not
<slangasek> ahasenack: right - so arguably, this is a feature enhancement we should consider for the 'service' command, to have it tail the log file for the job
<ahasenack> slangasek: is the upstart log for the job overwritten in each invocation?
<slangasek> ahasenack: no, it's appended
<ahasenack> ok, so it's not just tail the last line, there could be old stuff in there
<slangasek> yeah; you'd want service to do something like: if [ -e /var/log/upstart/$job.log ]; then tail -n 0 -f /var/log/upstart/ssh.log &; tail_pid=$!; fi; start $job; if [ -n "$tail_pid" ]; then kill $tail_pid; else cat /var/log/upstart/$job.log; fi
<dobey> slangasek: can you answer my question? just want to clarify that autopkgtests for packages in main can depend on packages in universe, before i dput it :)
<slangasek> dobey: I don't know of any reason they couldn't
<slangasek> jibel: ^^ can you confirm that autopkgtests can use deps from universe?
<dobey> right, i just wanted to confirm the restrictions weren't the same as build-depends for the package itself not being able to use packages from universe
<Laney> It's fine - I've done it with glib's autopkgtests
<Laney> I didn't even think of that to be honest ...
<dobey> ok
<dobey> great
<Laney> Tell me this is a fixed software-center :-)
<dobey> no, this is me adding autopkgtest support to ubuntuone-client :)
<jbicha> dobey: speaking of software-center could you take another look at bug 1163886 some time?
<ubottu> bug 1163886 in software-center (Ubuntu) "software-center crashed with signal 5 with WebKit 2.0+" [High,Confirmed] https://launchpad.net/bugs/1163886
<dobey> jbicha: is that the weird badmatch thing?
<jbicha> yeah, baddrawable
<dobey> no this is different, not the gtk+ thing
<dobey> yay javascript. thank you for suddenly making my pgup/pgdn keys not work on this page :(
<dobey> or maybe just a weird keynav bug in firefox :-/
<dobey> jbicha: actually, i have not seen the gtk+ one at all on saucy, even though it already has gtk+ 3.8
<jibel> dobey, I confirm there is no such restriction
<dobey> jibel: cool, thanks
<dobey> jbicha: what is the ppa url for the gnome3 ppa?
<jbicha> ppa:gnome3-team/gnome3
<dobey> the atmostone() issue in adt-run, yes
<dobey> aka TestDirectory: not working at all
<jibel> right, I fixed it when you discovered it, and pitti merged it yesterday
<jibel> you're the first using this directive since it exists apparently :)
<smoser> @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:
<dobey> jibel: ah, great. yeah, kind of disappointing the test runner doesn't have tests, though :)
<dobey> (among other things. that code is somewhat disturbing)
<dobey> now gotta fix ubuntu-meta
* holmes.freenode.net changed the topic of #ubuntu-devel to: Ubuntu 13.04 released | Archive: open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of 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: smoser
<xnox> doko: dannf`:  "xnox, could you merge lvm2 again, or update the config.* for arm64?" lvm2 2.02.98-1ubuntu2 (Accepted)
<dobey> wow, networking is really poor inside virtualbox (or maybe it's saucy, haven't tried other versions lately)
<xnox> dobey_: ev had all sorts of interesting troubles with virtualbox lately =)
<dobey> xnox: on raring host?
<xnox> dobey: on mac os x host
<dobey> xnox: i'm on raring host, so nothing there has changed really. lots have changed in saucy though. so not sure if it's just stuff broken in saucy when running in vbox, or what.
<barry> slangasek: okay, so i have a new python-configglue 1.1.2 which un-reverts your change, updates to the new upstream, and removes the Build-Dep on python-configparser.  seems to work locally for me.  fingers crossed.
<slangasek> barry: tested with ubuntuone-syncdaemon? :)
<barry> slangasek: i installed it on a vm, rebooted, and u1 file sync still seems happy
<slangasek> cool
<slangasek> +1
<barry> slangasek: hopefully you won't have to revert my unrevert of your revert again tonight after my eod :)
<slangasek> hah
<slangasek> fortunately the fix is a new upstream version, so the ugly version number goes away :)
<barry> yep :)
<stokachu> bazaar.launchpad.net down for anyone else?
<sarnold> stokachu: I was redirected to https://launchpad.net/
<stokachu> hmm what about this link https://bazaar.launchpad.net/~charmers/charms/precise/python-moinmoin/trunk/view/head:/hooks/install
<sarnold> stokachu: .. and bzr up in a tree ran without issue
<sarnold> stokachu: 503
<stokachu> ok i need to check if anyone's reported it yet
<sarnold> stokachu: thanks, under investigation now :)
<stokachu> sarnold: ah oops i just posted in #launchpad so dis-regard that one :D
<dobey> Laney: am sure you're gone now, but there's an issue with the branch import of software-center in saucy, which i've pinged wgrant about already so hopefully he'll fix it. i'll get a new software-center uploaded in the morning (hopefully without having to do it the old-school annoying way of apt-get source and modify things).
<asac> 01:50 < asac> ouch ... i think it really happened... i lost core dev unnoticed once and for all (as i dont really have a reason get it back):)
<asac> 01:50 < asac> i am not even an ubuntu member anymore
<asac> 01:50 < asac> thats brutal :)
<asac>  well... guess expiring without me noticing is reason enough to justify at least loosing dev :)
#ubuntu-devel 2013-07-12
<micahg> asac: I can give you dev membership without upload rights if you want
<BenC> Any reason why packages.ubuntu.com contents search isn't working for saucy?
<ScottK> Hasn't been set up yet.
<ScottK> Rhonda handles it both for Ubuntu and Debian.  Not sure what's blocking it.
<pitti> xnox: erk, your update-manager merge (common dialogs) broke quite a lot -- got the tests mostly fixed again, but this dropped UpdateManager/UpdateProgress.py which was still being included
<dylan-m> pitti: Eep, I thought I had those tests passing.
<pitti> dylan-m: the pep-8 and pyflakes errors were simple, I got these committed
<pitti> dylan-m: it looks like I'd replace UpdateProgress(main) with something like get_backend(self, InstallBackend.ACTION_UPDATE) ?
<pitti> in ./tests/test_update_error.py
<dylan-m> pitti: I'll be happy to work through these tomorrow, if you'd like :)
<dylan-m> pitti: Hang on, just going to jog my memory on that one, but I think that's right. The Update / Install backends were stuck together, if I remember correctly.
<pitti> dylan-m: hm, I'm afraid I can't figure it out without truly understanding what's going on there :/
<dylan-m> Hm, action-done isn't a signal any more, either, so that'll need to be changed to just call the hidden method _action_done. Should take the same arguments.
<pitti> dylan-m: ok, in bzr I now fixed all failures except this one
<dylan-m> Hm, are there some existing failures trying to import DistUpgrade.DistUpgradeCache, or is that just me?
<pitti> not with "env -u LANGUAGE LANG=C nosetests3" here
<dylan-m> Ah, yes, using the right version of nosetests helps :)
<dylan-m> pitti: Okay, that one is fixed! https://code.launchpad.net/~dylanmccall/update-manager/test_update_error-fix
<pitti> dylan-m: ah, nice header_markup() fix, I changed that differently in trunk but I'll take your version
<pitti> dylan-m: thanks!
<dylan-m> pitti: I thought about just using get_text instead of get_label, but some translations could add Pango markup for some reason (not sure if they should, though), so that could cause some unusual failures
<pitti> ah, overlong line again
 * pitti fixes
<pitti> yay, all pass now
<pitti> time for another "real life" test, and then I'll upload
<dylan-m> pitti: d'oh! This is what happens when I use the wrong text editor.
<pitti> dylan-m: pep8 test was failng
<pitti> xnox: unping, all good now
<dylan-m> pitti: Yay! Sorry about the trouble :) I really appreciate good unit tests, and I'm really glad you're keeping on top of them! I really need to fix my ugly habit where I always forgetting to run them when they're there.
<pitti> dylan-m: heh, thanks for the fast fix
<pitti> dylan-m: all I did was to drop the obsolete threads_init() call, and that got me into some more work :)
<dylan-m> Oh, right, I was brushing my teeth. Err, good night, then! :)
<pitti> dylan-m: night!
<dholbach> good morning
<tvoss> pitti, ping
<pitti> hey tvoss
<Laney> dobey: well, those changes alone aren't enough to make the autopkgtests pass
<Laney> I'll give you what I have atm but it's unfortunately still not enough - it seems to block forever at some point even though they were passing when I ran them manually
<Laney> kind of annoying that adt-run buffers output so you don't get it at all if you have to ctrl-c :/
<pitti> Laney: you can tail -f the stdout/stderr files in the tmp dir
<Laney> pitti: oh really? let me try this
<Laney> I was playing with --output-dir and --log-file
<pitti> Laney: that works as well in run-adt-test, you can ssh into the VM and tail -f the files in /tmp/adtmp/...
<pitti> ssh -p 54323 ubuntu@localhost
<pitti> (get the precise port from the initial output or from the qemu command line)
<dholbach> we're at 62 sponsoring items - does anyone have a bit of time today to go through a few?
<xnox> pitti: cool, thanks. sorry about that.
<cjwatson> pitti: Please could you merge subversion?
<pitti> ugh, did I make the error of touching it?
<pitti> ah, a no-change rebuild
<cjwatson> Yeah :)  Or I can do the merge if you like
<pitti> cjwatson: I'll have a look
<pitti> I don't even see it on MoM, perhaps it's still catching up
<xnox> barry: i think i got broken icon in emacs24, it was a combination of having a server on the tty and launching a new gui instance.... it turned into a "?"
<cjwatson> MoM got stuck.  I've poked it
<cjwatson> Should catch up within an hour or so I hope
<cjwatson> Is there a good example package anywhere which uses both the autotools and setup.py?  I need/want to use the autotools for C parts of this project, but I already have setup.py in place for the Python parts ...
<pitti> cjwatson: merged, test sbuild running now
<pitti> http://bazaar.launchpad.net/~ubuntu-branches/debian/sid/subversion/sid/revision/22 FTW :)
<mpt> ev, how do you track bugs that, when fixed, will alter the apparent error rate but not the actual error rate? For example bug 1196740.
<ubottu> bug 1196740 in software-center (Ubuntu) "not all package install failures generate a crash report" [High,Confirmed] https://launchpad.net/bugs/1196740
<ev> mpt: we don't at present
<ev> didn't we come up with a plan for that at the January sprint?
<mpt> ev, if so, it isn't mentioned in https://wiki.ubuntu.com/ErrorTracker#Cross-release_comparisons
<ev> mpt: https://docs.google.com/a/canonical.com/document/d/1BWOIRdJvUueJa4cWV68UEY3nlmHgAVJY6aNGo6YSCQg/edit# - "How do we handle anticipating more errors?"
<ev> there's no implementation for this yet though
<mpt> aha, DetectedSince, DetectedUntil
<mpt> but there's no field for that in the database?
<ev> mpt: not yet, no
<ev> my priority at the moment is getting error reporting working on mobile and server, while working through this datacenter move (then back population jobs, woo) and testing acunu analytics for possible use. Detected{Since,Until} is just not something I'll have time for in the near future
<ev> dpm: you're my hero for the workaround in https://bugreports.qt-project.org/browse/QTBUG-32225
<dpm> ev, no worries, Wellark is the person to credit, he suggested it to me :)
<ev> thanks to the both of you then :)
<seb128> hum
<dpm> :-)
<seb128> update-manager is hanging on a " [debconf-communi] <defunct>"
<ev> seb128: do you know what the plan is for mobile with respect to dbus services that currently require authentication via policykit? Are we going to start shipping 10-vendor.d configs setting ResultActive=yes for the phablet group?
<ev> the background for this being that we currently have com.ubuntu.WhoopsiePreferences which controls access to /etc/default/whoopsie. On the desktop, it requires an admin user to enter their password via polkit to call the dbus methods. My understanding is that we don't want to ask the user to reauthenticate when changing system settings on the phone.
<seb128> ev: no, I don't know, it's on my list of things to check with the sdk/security teams, the previous times I asked people didn't really know/think about it yet
<seb128> ev: I'm not sure we even have polkit on the touch image atm (the UI is GTK as well which is an issue)
<pitti> cjwatson: ah, it finally finished building, uploaded svn
<ev> seb128: *nods* thank you
<seb128> ev: yw ... I'm going to try resume discussions about that and I will include you
<ev> very much appreciated, thanks
<capdenuca> anyone over here?
<cjwatson> Just ask - don't ask to ask
<capdenuca> do u know how to get a mirc user?
<cjwatson> I'm not sure how a Windows IRC client is relevant to this channel?
<capdenuca> cuz i m new on this...
<cjwatson> I think you're confused and want some other channel.  I'm not sure which.
<cjwatson> This channel is for development of Ubuntu.
<quadrispro> hello everybody
<ev> mpt: got a second?
<ev> mpt: so it's not going to centre, because the toolkit defaults to left-aligned for captions and does not expose that property: http://bazaar.launchpad.net/~ubuntu-sdk-team/ubuntu-ui-toolkit/trunk/view/head:/modules/Ubuntu/Components/ListItems/Caption.qml#L57
<ev> think I should file a bug for that?
<mpt> ev, no, that's fine, all captions should line up the same.
 * ev nods
<seb128> ev: what are you trying to do?
<ev> seb128: https://wiki.ubuntu.com/ErrorTracker#Privacy_settings (righthand mockup)
<seb128> ev: you can do http://paste.ubuntu.com/5867801/
<seb128> ev: but please open a bug on the toolkit asking them to allow changing the alignement
<ev> seb128: sure, but I'm more keen on staying consistent
<seb128> ev: consistant with what?
<ev> the rest of the interface
<seb128> ev: caption will not do what you want anyway
<ev> it's going to look weird if we have some captions left aligned and some centred
<ev> as mpt also seemed to suggest
<seb128> ev: ok, well still caption is going to be weird, they have colored background
<seb128> ev: cf. https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1194513
<xnox> ev: file:///usr/share/ubuntu-ui-toolkit/doc/html/qml-ubuntu-components-listitems0-standard.html
<ubottu> Launchpad bug 1194513 in Ubuntu UI Toolkit "[ListItem] Should be possible to wrap text in list items" [Undecided,In progress]
<seb128> xnox, you can't wrap in standard, see ^
<xnox> ev: List Items -> progression. It's a left aligned text with progress arrow on the right. I would have used that standard element.
<xnox> seb128: yeah, sucks =)
<ev> xnox: I'm already using progression - we're talking about the caption item
<xnox> oh, isee.
<xnox> I got ubuntu-sdk guru answer a question on centered wrapping for me here: http://askubuntu.com/questions/308088/how-to-make-a-centred-wrapped-and-padded-container-of-elements-in-qml
<xnox> which does work in a Column.
<seb128> xnox, http://paste.ubuntu.com/5867801/ works
<seb128> xnox, but ev doesn't want to use non standard elements
<xnox> seb128: ok. I don't think I've done inheritance yet.
<seb128> xnox, the system settings are mostly listitems
<seb128> see e.g the about settings
<seb128> we have random alignments and hacking there ;-)
<xnox> seb128: ok. i think i've asked yesterday, but is anybody working on porting chewieui / indicators-client / wifi portion into the system settings?
<seb128> xnox, ted
<seb128> xnox, well, he's working on the indicator
<seb128> but the idea is that the indicator is gmenu based code sent to unity which renders it through a qmenumodel/unitymenumodel
<seb128> we plan to reuse the model in system settings
<seb128> since most of the items/actions will be shared
<xnox> seb128: but there is slight differences in design, the system settings has more options.
<seb128> right
<seb128> the indicators services will have several "profiles"
<seb128> e.g different layouts they export
<seb128> one for desktop
<seb128> one for greeter
<seb128> one for phone
<seb128> one for settings
<seb128> the service basically has all the items that will be used and actions
<seb128> then you build models with the layout/actions you need
<xnox> seb128: what should I do for oobe then, cause i also need "connect to network" step.
<seb128> talk to ted
<xnox> ted, talk to me =)
<seb128> but it should be "hit the menu/action though unitymenumodel", I'm not sure how that works though
<seb128> it's a bit early for ted
<xnox> yeah, and not idling via irc proxy. Right. will poke him in late afternoon.
<ev> xnox, seb128: if you have some free time: https://code.launchpad.net/~ev/ubuntu-system-settings/diagnostics/+merge/174385
<seb128> ev: thanks, I will try to review/comment today
<seb128> ev: could you or mpt update the design on https://wiki.ubuntu.com/SystemSettings to list that panel because it's not there at the moment? (should it really be a main category item in rather rather than a subpanel in security&privacy for example)?
<seb128> ev: oh, it's in https://wiki.ubuntu.com/SecurityAndPrivacySettings#Phone
<mpt> Ugh, why did I think it was top level?
<mpt> Sorry, ev
<mpt> Memory malfunction
<ev> mpt: so it should be accessible from "Security & Privacy"?
<mpt> ev, yes
 * ev nods
<ev> I'll fix that in the MP
 * Laney pauses reviewing :P
<ev> oh boo :)
<ev> do feel free to pick apart the rest of it
<Laney> just saw some from seb anyway
<seb128> Laney, I did a quick one before lunch, it would still be good if you would review/comment
<Laney> I'll take Round Two after those are addressed
<seb128> especially on the cpp code, I glanced to that one only
<seb128> thanks
<obounaim> Hi everybody
<obounaim> Is there a way in Ubuntu to get the number of users of a given package
<geser> not really, you could look at the popcon data but it's only a *very* rough estimate
<obounaim> Ok thanks
<obounaim> but where can I find this popcon data?
<pitti> cjwatson: libapache2-svn is NBS now, removing
<cjwatson> I already did
<pitti> or, someone already did that
<cjwatson> Thanks
<geser> obounaim: http://popcon.ubuntu.com/
<obounaim> thanks
<obounaim> is popularity-contest installed by default in Ubuntu?
<debfx> obounaim: yes, but submission is opt-in
<obounaim> so it sends data about installed packages by defaults right?
<debfx> obounaim: no, only when you configure it to do so (I think the installer has a checkbox that is disabled by default)
<obounaim> ok
<obounaim> so what did you mean by "opt-in"?
<geser> exactly that, the user has actively to enable it during installation (opt-in) otherwise no data gets send
<obounaim> ok thanks
<caribou> when a submitted debdiff fixes two existing bugs, should it be uploaded to both bugs or only one ?
<caribou> sorry to bug you about this here but didn't get an answer in #ubuntu-bug
<infinity> caribou: It should mention both bugs in the changelog.  Don't really care where the diffs go, best to just find a sponsor and get it sorted.
<caribou> infinity: well that's the danted fixes we talked about yesterday. Both bugs are outlined in the changelog
<infinity> caribou: Toss me a diff, and I'll look at sponsoring it.
<caribou> infinity: I completed the SRU template  & subscribed the appropriate teams.
<caribou> infinity: they're attached here : https://bugs.launchpad.net/ubuntu/+source/dante/+bug/816153
<ubottu> Launchpad bug 816153 in dante (Ubuntu Precise) "dante-server using the wrong libc.so" [Medium,In progress]
<caribou> I can send them over by mail if you want; both precise & saucy
<caribou> infinity: I added the search snippet you suggested yesterday
<caribou> infinity: both tested on saucy & precise, 32 & 64 bit
<infinity> caribou: I'll look at the bug(s) in a second.
<caribou> infinity: no rush,I'm almost done for the week
<dobey> who is it again that is most appropriate to ping about busted bzr imports of package uploads? wgrant and who else? i pinged wgrant last night before i left, but unfortunately didn't get a reply :-/
<infinity> dobey: I think xnox has been looking into import issues.
<dobey> xnox: have you? :)
<xnox> dobey: what package?
<xnox> dobey: yeah, i have access to the imported and _some_ experience in it.
<dobey> xnox: software-center failed
<dobey> http://package-import.ubuntu.com/status/software-center.html#2013-07-05%2021:56:29.968306 is the error
<dobey> seems to be a common problem though, those missing revisions from james_w :-/
<dpb1> slangasek: Hi -- upstart question.  I have a non-forking daemon that is early exiting (log file permissions are wrong).  Is there a way to catch this error so the "start daemon" command fails?  Or is that not something to worry about?
<tedg> cjwatson, Do you expect the $(pkgdir)/.click/$(pkgname)/manifest path to remain constant?
<tedg> cjwatson, At least in the near term.
<stgraber> dpb1: so it's not exiting non-null before it's done double-forking? otherwise I'd expect upstart to notice the failure and make the start call fail
<dpb1> stgraber: this is a non-forking daemon (running in foreground)
<stgraber> hmm, not sure that's possible for a non-task to return a failure to start when it's not forking
<dpb1> :( ok  I thought post-start could be helpful, but it seems to ignore exit codes from therewq
<slangasek> dpb1: so you have no 'expect' stanza; which means upstart believes the job is successfully started as soon as it has exec'ed the program.  I'd say you want to change it so upstart can know that it's failed, if you care about 'start' not returning success when the startup hasn't succeeded.
<cjwatson> tedg: Yes.
<tedg> cjwatson, cool, thanks!
<cjwatson> tedg: Though it's actually $(pkgdir)/.click/info/$(pkgname).manifest ...
<stgraber> slangasek: but how would you do that with a non-forking service (as seems to be the case here)?
<tedg> cjwatson, Ah, sorry, I wrote from memory instead of cut-and-paste.  I was planning to look again :-)
<dpb1> slangasek: hmm.  So, adding a post-start "sleep 5" for instance prints the "daemon stop/waiting", but I still get a 0 exit code from the service command.  And I get 0 exit from status as well, which doesn't seem right?  Unless I'm missing something.
<dpb1> (which is likely)
<slangasek> stgraber: 'expect stop' is the least intrusive
<slangasek> dpb1: 'sleep 5' just means that upstart thinks that a) the main program started successfully, b) the post-start script exits successfully, so 'service' (or 'start') returns success.
<dpb1> slangasek: http://paste.ubuntu.com/5868569/ -- I worked up a paste that demonstrates what I'm talking about.  Hopefully it makes more sense than my prose.  How do I get non-zero exit status when the daemon is not running?
<jbicha> mardy: could you approve https://code.launchpad.net/~jbicha/gnome-control-center-signon/fix-build-with-control-center too?
<slangasek> dpb1: sorry, I understood already exactly what you were asking for, it must be my answers which were unclear. :)  The easiest way for upstart to reliably know whether your non-daemon process has launched successfully is to use 'expect stop', and modify your program to raise SIGSTOP when it considers itself successfully started
<slangasek> dpb1: (probably something that you want to have as a commandline option to the program, since raising SIGSTOP isn't normally something you'd do when run from the commandline)
<dpb1> slangasek: intersting.  I'm looking into that now, thanks.
<slangasek> dpb1: documentation in init(5), though that doesn't add much over what I've already said
<dpb1> slangasek: OK, thanks.  I'm still curious though why service status is not showing an error when the daemon is not running (and upstart knows it is not).  If I switch over to SIGSTOP, that will suddenly start working, I hope? :)
<dpb1> by error, I mean, exit status
<slangasek> dpb1: that seems like a bug in the service command
<dpb1> Tracing, it's just a pass-through to status, which is a call to initctl, which also shows the same behavior.  I'll look for a bug.
<dobey> xnox: hey. were you able to get software-center branch import fixed up?
<slangasek> dpb1: it's not a bug in initctl, whose exit codes are defined to represent success/failure of the dbus calls, not anything about the service status
<slangasek> dpb1: it may be a bug in the service command, I'm not sure
<dpb1> slangasek: not this? https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/552786  seems the same?
<ubottu> Launchpad bug 552786 in upstart "initctl: lacks proper exit codes" [Medium,Triaged]
<slangasek> dpb1: comment #11 - this is about return codes from upstart-job, which is deprecated
<slangasek> dpb1: is this on saucy? precise?
<xnox> dobey: i did requeue it...
<dpb1> slangasek: precise
<xnox> dobey: $ bzr branch lp:ubuntu/software-center
<xnox> Most recent Ubuntu version: 13.05-0ubuntu2
<xnox> Packaging branch status: CURRENT
<slangasek> dpb1: ok - then yes, that version of service may be affected by that bug in upstart-job
<xnox> yes.
<dobey> xnox: ah cool, thanks! :)
<dpb1> slangasek: ah, gotcha.  initctl also shows this behavior though.  Is there a way to poll the service status more reliably on precise?
<slangasek> dpb1: initctl is *supposed* to behave that way
<slangasek> things that want a different exit code for running/not-running need to parse the initctl output and do their own mapping to error codes
<slangasek> this is what 'service' is meant to do
<slangasek> (or upstart-job, depending on which iteration)
<dpb1> slangasek: ok, thanks.  that helps.
 * dpb1 stops sucking up all of slangasek's time now
<slangasek> fwiw, it looks like this issue is still present in the saucy version of service
<dpb1> slangasek: yes, I'm seeing that, thanks.  I wonder what puppet has done to workaround it.  probably parse I guess
<slangasek> I believe so
<ev> mardy: so I tried your suggestion of subclassing QDBusInterface, but I'm running into a segfault deep in the bowels of the generated code: http://paste.ubuntu.com/5868715/ (diff against lp:~ev/ubuntu-system-settings/diagnostics) and http://paste.ubuntu.com/5868718/
<ev> I can't seem to figure out what's going on here
<Snow-Man> hrmmm, ipv6 for the systems behind us.archive.ubuntu.com appears to be non-functional this afternoon. :(
<dobey> anyone care to sponsor https://code.launchpad.net/~dobey/ubuntu/saucy/ubuntu-meta/drop-u1-gnome/+merge/174471 please? :)
<infinity> dobey: If by "sponsor", you mean update the seeds, maybe...
<dobey> infinity: i guess that's what it means. i just want to get ubuntuone-client-gnome gone :)
<dobey> (anyway, i'm gone now. thanks.)
<infinity> dobey: Uploaded.
<cjwatson> barry: Hum.  Does ./run-tests in lp:click fail for you (you'll need to "./configure && make" first, nowadays)?
<cjwatson> barry: I get an outstandingly weird failure: http://paste.ubuntu.com/5869503/
<barry> cjwatson: `apt-get purge python-configparser` and try again ;)
<slangasek> hah
<barry> slangasek: yeah ;)
 * slangasek punches configparser in the exception handler
<barry> slangasek, cjwatson i had a long chat today with upstream.  most of the failures we saw really are bugs in the code that uses configparser, not in configparser itself.  configglue, but virtue of using configparser broke its api which caused the cascading problems.  virtualenv is at fault here (and it's really insane anyway) but upstream has promised to make configparser more bullet proof
<cjwatson> Right - but why am I seeing '/usr/bin/python3.3', '/usr/lib/python2.7/dist-packages/virtualenv.py' ... there?
<cjwatson> It's true that purging python-configparser fixes it; I was just put off by what appeared to be attempts to run Python 2 code in Python3
<barry> cjwatson: that's virtualenv's insanity.  it re-invokes itself with the version of python its creating the venv for but does it in a python 2 context.  yes, it's fscking nuts, but that's the way it works!  the bullet proofing i mentioned is to make configparser python 3 compatible for exactly this reason, even though it isn't intended to run under python 3 normally (because py3 has the real configparser)
<barry> iow, venv will execute some py2 code under py3
 * barry boggled
<cjwatson> owwwwwwwwwwww
<cjwatson> gotcha.  I think. :)
<barry> don't ask me *why* it does that ;)
<cjwatson> argh freaking python-debian out of sync in pip
<cjwatson> barry: remind me how you got click's tests working in python3.2 despite the cheeseshop version of python-debian being confused?
<cjwatson> I remember you talking about this but not the resolution ...
<barry> virtualenv --system-site-packages ...
<barry> ignores pypi for anything you already have installed
<cjwatson> ah.  can tox pass that along?
<barry> errr, yeahhh.  let me look that up
<cjwatson> or do I just need to make the virtualenv by hand first?
<barry> cjwatson: http://testrun.org/tox/latest//config.html#confval-sitepackages=True|False
<cjwatson> Hm, sitepackages=True already in tox.ini
<cjwatson> Oh, maybe this is because my python3.2 build has the wrong site-packages
<cjwatson> Much better, woo
<cjwatson> Thanks
<barry> np!
<cjwatson> beuno: Do we have anything anywhere yet about what the click app download arrangements are going to be - URLs etc.?
<cjwatson> beuno: ... never mind, just found it on https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex
#ubuntu-devel 2013-07-13
<Noskcaj> mfisch, ping
<beuno> cjwatson, FWIW, uploads/downloads are working in our staging environment, it's slightly tricky to manually test since the requests need to be signed for downloads, but not that tricky  :)
<Noskcaj> can someone help me with setting up sbuild? It seems something is wrong with step 4 on https://wiki.ubuntu.com/SimpleSbuild
<cjwatson> Noskcaj: What's wrong with it?
<Noskcaj> cjwatson, I've got it working now. The issue was it was very hard to differentiate between the code for "sbuildrc" and the next instruction
<cjwatson> Noskcaj: um, ok.  I don't see how the formatting could be improved; it looks fairly clear to me
<Noskcaj> I'd missed the second half of part 4.
<cjwatson> Noskcaj: I've split that into two numbered steps; better?
<Noskcaj> thanks. i hope it helps someone other than me
<Snow-Man> yay, ipv6 is working again for us.archive.ubuntu.com
<Snow-Man> oh, err, for *some of the systems its working again... :(
<Snow-Man> ::13 is working, but ::14 isn't..
<Snow-Man> argh, no, that's not it.  The systems behind *security.ubuntu.com* that aren't the same ones behind us.archive are working
<Snow-Man> sooo, no improvement.
<Snow-Man> blah.
<gotwig> where is the channel for ubuntu app development
<cjwatson> gotwig: #ubuntu-app-devel, as mentioned in the topic of this channel.
<gotwig> cjwatson: yeah.. thanks for not ignoring me
<cjwatson> It's a weekend; quick replies would be unusual.
#ubuntu-devel 2013-07-14
<ArcticLight> Um... Hi. This is going to sound like a very odd question, but is it possible to get or make a build of the Ubuntu MAAS PXE files that don't have impi support built in?
<jdthood> stgraber: ping
<infinity> rbasak: *php nudge*
<ion> Thatâs evil.
#ubuntu-devel 2014-07-07
<RAOF> mwhudson: You could add that amd64 as a foreign arch to dpkg?
<RAOF> mwhudson: I think?
<mwhudson> RAOF: how do i do that again?
<mwhudson> oh dpkg add-architecture
<mwhudson> but no
<mwhudson> W: Failed to fetch http://www.apache.org/dist/cassandra/debian/dists/20x/InRelease  Unable to find expected entry 'main/binary-arm64/Packages' in Release file (Wrong sources.list entry or malformed file)
<tarpman> mwhudson: you can arch-qualify the sources.list entry... I think [amd64] is the syntax, forget where it goes :)
<mwhudson> deb arch=amd64 i think maybe?
<mwhudson> er
<mwhudson> deb [arch=amd64] http://www.apache.org/dist/cassandra/debian 20x main
<mwhudson> apparently
<mwhudson> tarpman: thanks :)
<pitti> Good morning
<dholbach> good morning
<mvo> hey dholbach
<dholbach> hey mvo
<michagogo> Hey, any SRU team members (other than cjwa tson) around?
<xnox> pitti: on http://dep.debian.net/deps/dep8/ "current specification" link is 404.
<xnox> pitti: can you update it to point to the right place? And what is the right place these days?
<pitti> xnox: indeed, should be http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests.rst;hb=HEAD
<pitti> xnox: I renamed the files to *.rst
<pitti> xnox: I can't update it myself, but I'll find out who can
<xnox> pitti: ok. Are you setting up read-the-docs for autopkgtest? it could process rst to make it look all dandy and stuff.
<pitti> xnox: the package builds nice *.html files from those now and ships them in /usr/share/doc/
<xnox> pitti: ah, cool.
<pitti> xnox: I haven't felt a strong urge to put them elsewhere, but if there's demand why not
<xnox> pitti: hm, i think dep8 website can parse RST as well, no? Would be nice if that was the thing directly.
<pitti> oh, http://dep.debian.net/recentchanges/ looks like some svn
<pitti> xnox: I'll check out http://dep.debian.net/depdn-howto/ after I'm done with my current multi-thread unwrangling (sorry, too much brain state)
<xnox> =))))
<ogra_> xnox, do you happen to know if anyone in foundations works on bug 1323732 (did you discuss it in a meeting perhaps) ?
<ubottu> bug 1323732 in adduser (Ubuntu) "adduser should support managing additional password/shadow/group files from libnss-extrausers" [High,Confirmed] https://launchpad.net/bugs/1323732
<ogra_> (see my last mail to ubuntu-phone)
<ogra_> steve asked me to initially assign it to hi so he could hand it to someone after malta ... looks a bit like it was forgotten
<ogra_> *him
<xnox> ogra_: there is no confirmation that slangasek has recovered after 4th of july yet. Since it is still assigned to Steve, I believe you should be poking him.
<xnox> ogra_: typically he changes assignee when he hands stuff over.
<ogra_> xnox, right, just wanted to know if it came up in some team discussion or so
<ogra_> thanks
<pitti> xnox: so I committed http://lists.alioth.debian.org/pipermail/dep-commits/2014-July/000316.html but I guess it'll take a bit to propagate to the website
<pitti> mvo: FYI, $USER is now set for root tests in CI
<mvo> pitti: thanks !
<mino_core> hello :)
<mino_core> is there a way to install the grub deb in a none interactive way, he is askin "Continue without installing GRUB?" and i want to answer with yes
<mlankhorst> setting question priority lower
<mino_core> i need that for an automated build of ubuntu, but havent found yet a solution for it
<mlankhorst> maybe apt-get -qq ?
<geser> shouldn't setting the debconf frontend to non-interactive help?
<mlankhorst> oh that one :-)
<ogra_> Laney, hmm, did you see my latest meta upload ? seems desktop-next inhertis some stuff from somewhere that touch doesnt have ...
<ogra_> (i added all the entries equally to touch and desktop ... but only tcptraceroute was pulled into desktop)
<Laney> link?
<ogra_> Laney, https://launchpad.net/ubuntu/utopic/+source/ubuntu-touch-meta/1.162
<ogra_> Laney, bah, ignore me ... i'm blind
<Laney> right... was wondering :)
<ogra_> (somehow the evolution formatting made me miss "desktop" in all these lines)
<slangasek> xnox: I suppose we /can/ keep startpar disabled, but is there a specific reason you want to?  I hadn't heard about any problems in this regard
<michagogo> slangasek: hey, you're SRU team, right?
<michagogo> Just wanted to make sure you saw my email to the ubuntu-devel mailing list
<michagogo> It would be very much appreciated if you could comment, do whatever is needed to move this along
<xnox> slangasek: reasons to keep startpar disabled are as follows -> generally unreliable startpar-bridge integration. (a) task jobs hanging boot/shutdown (b) jobs set to manual (e.g. via override file) hanging boot/shutdown (c) little interim gain in resolution of a/b, taking away time to better support systemd (d) startpar is not used under systemd
<Shock> pitti: hi, any idea of a time frame on LP: #1247584 ?
<ubottu> Launchpad bug 1247584 in systemd (Ubuntu) "[keymap] Since upgrade to Ubuntu 13.10, udev doesn't map middle mouse button." [Undecided,In progress] https://launchpad.net/bugs/1247584
<Shock> I'm unable to find a branch in LP that contains the release of package systemd (204-5ubuntu20.3). Am I not searching where I should, or was that package generated outside of LP/bzr?
<Shock> distro is trusty
<doko> jamespage, is this server-team stuff? https://jenkins.qa.ubuntu.com/view/Utopic/view/AutoPkgTest/job/utopic-adt-mongodb/lastBuild/? blocks gcc-4-9, although it is not used
<xnox> Shock: there is no branch for it, the upload is here however https://launchpad.net/ubuntu/+source/systemd/204-5ubuntu20.3 which also has links to build-records (and thus debs) and a diff against previous upload (20.2)
<xnox> Shock: it's been released to updates pocket last thursday.
<Shock> xnox: thanks, is there a way to create a daily build if there's no branch for it?
<dobey> xnox, Shock: looks like there's a branch for it to me
<Shock> dobey: how did you find the branch?
<dobey> oh, i guess it didn't import
<dobey> Shock: why would you want to create a daily build for a specific version anyway?
<Shock> dobey: I want to build udev automatically (with a patch) whenever a new version is released
<dobey> Shock: in general, or only to trusty-updates?
<dobey> in general, i don't see why you wouldn't use lp:ubuntu/systemd to do that
<Shock> dobey: I'm not sure what that means; I'm only interested in trusty atm
<dobey> though i don't know how you plan on adding the additional patch exactly
<Shock> dobey: I couldn't find the changes that were in https://launchpad.net/ubuntu/+source/systemd/204-5ubuntu20.3 in lp:ubuntu/systemd
<Shock> dobey: I plan to use build recipes in launchpad
<dobey> yeah i'm not sure why they aren't in utopic there
<dobey> stgraber: ^^ why is that? :)
<dobey> Shock: i don't see how you will add another patch though
<Shock> dobey: merge from a personal branch?
<dobey> Shock: you're going to have to manually resolve conflicts every time there's an update, most likely
<stgraber> dobey: probably because the importer is broken somehow, that happens.
<stgraber> dobey: IIRC the Ubuntu systemd packaging is maintained in a git branch on alioth, so I usually just upload to the archive and let pitti deal with the VCS
<Shock> dobey: the only conflict would be in debian/patches/series
<dobey> stgraber: i mean, why are those changes from the trusty update, not in utopic?
<Shock> dobey: and I'm pretty sure I can avoid the conflict by putting my patch as the first line in the series
<stgraber> dobey: they are in utopic
<dobey> stgraber: hmm, Shock said he couldn't find them in the utopic package.
<stgraber> those fixes were uploaded in 204-10ubuntu9 or earlier
<dobey> ah ok
<stgraber> the whole point of the SRU to trusty was to get all the fixes of utopic in there so the cgmanager integration patch is now identical in both
<dobey> Shock: what does your additional patch do exactly, anyway? why not just get it into debian/ubuntu?
<Shock> dobey: it makes my mouse work :). it's taking too long to get it in ubuntu/upstream LP: #1247584
<ubottu> Launchpad bug 1247584 in systemd (Ubuntu) "[keymap] Since upgrade to Ubuntu 13.10, udev doesn't map middle mouse button." [Undecided,In progress] https://launchpad.net/bugs/1247584
<dobey> pitti: ^^ get that in already. :)
<Shock> dobey: in any case, knowing how to build a package with changes wrt official package would help me in other situations
<Shock> dobey: I'd rather not go through the whole manual ordeal every time the package is updated in the oficial repos
<dobey> Shock: i'd suggest doing it against trying to build against lp:ubuntu/systemd then
<Shock> dobey: is there a way I can target the trusty version in a lp build recipe?
<doko> directhex, mono ping
<xnox> Shock: in the recipe config you specify target distributions to build against....
<dobey> Shock: you mean build it on trusty, or you mean patch against the trusty version?
<xnox> Shock: hence yes, you control which distribution(s) a given recipe will be build.
<Shock> dobey: patch against the trusty version
<dobey> Shock: use the trusty branch, but i don't see why you need to use that specific branch, versus just using the actual newest version
<dobey> unless the utopic version outright fails to build on trusty or causes it to explode or something
<xnox> Shock: lp:ubuntu/* branches are never guaranteed to be up-to-date, as the archive is authoritative source, not the bzr branches. Thus e.g. kubuntu folks maintain automated rebuilds outside of bzr branches & recipes.
<dobey> import failures are pretty common too
<Shock> dobey: I had planned to build against lp:ubuntu/trusty/systemd but I couldn't find the latest changes in there
<xnox> Shock: instead they automate $ pull-lp-sources; wget -O /tmp/my.patch ....; quilt import /tmp/my.patch; debuild -S; dput ppa:....
<dobey> Shock: no, they should appear in trusty-updates and trusty-proposed, once imported
<dobey> assuming a successful import
<xnox> Shock: once trusty is released, it's release pocket is frozen. Thus lp:ubuntu/trusty/systemd will never update.
<Shock> xnox: hmm, that would work. thanks
<xnox> Shock: the pockets which are updated are trusty-updates, trusty-proposed and trusty-security, iff the import succeeds.
<Shock> xnox: the latest udev release was in the trusty pocket
<xnox> Shock: it's been attempted to fully automate merging builds, but it ultimately fails. Just because your patch still applies, doesn't mean that it will build, or if it builds, it doesn't mean it will be operating correctly.
<Shock> I also looked at lp:ubuntu/trusty-proposed/systemd
<xnox> Shock: branches are not up to date....
<xnox> $ rmadison -S systemd | grep source
<xnox>  systemd                | 204-0ubuntu18     | saucy                                | source
<xnox>  systemd                | 204-0ubuntu19.2   | saucy-updates                        | source
<xnox>  systemd                | 204-5ubuntu20     | trusty                               | source
<xnox>  systemd                | 204-5ubuntu20.3   | trusty-updates                       | source
<xnox>  systemd                | 204-12ubuntu1     | utopic                               | source, amd64, arm64, armhf, i386, powerpc, ppc64el
<Shock> it seems I'm misunderstanding something :(
<xnox> $ bzr branch lp:ubuntu/trusty-proposed/systemd
<xnox> Most recent Ubuntu Utopic version: 204-12ubuntu1
<xnox> Packaging branch version: 204-10ubuntu1
<xnox> Packaging branch status: OUT-OF-DATE
<Shock> are the packages in trusty generated from lp:ubuntu/systemd? it seems not
<xnox> Shock: Manual source builds are uploaded and published into the archive, once published binaries are build, after that importer walks the archive trying to create bzr branches lp:ubuntu/* if it manages to sucseed.
<xnox> Shock: no, ubuntu is not build from bzr branches.
<Shock> xnox: ok, that clears up a lot
<xnox> Shock: pull-lp-source systemd trusty -> will fetch the latest trusty sources (including security, updates and proposed-updates)
<xnox> Shock: if you want at most security -> specify trusty-security; for at most released updates -> specify trusty-updates
<hallyn> infinity: hey, we're having the grooviest of times looking at the SRU for docker.io.  Looking at rmadison output for golang-context-dev, the source pkg version is older than the package version...  i'm confused.
<hallyn> xnox: ^  or you probably know offhand what's going on :)
<xnox> hallyn: looking. infinity is on hooligans.
<xnox> * holidays
<Shock> xnox: ok, that helps. There's no equivalent for "pull-lp-source systemd trusty" in a build recipe, correct?
<xnox> Shock: no
<hallyn> xnox: ah, thanks :)
<xnox> Shock: not, inside launchpad that is.
<xnox> hallyn: yeah, that looks very very odd.
<xnox> hallyn: i'm guessying there was a partial / timed-out copy, and or partial delete/removal.
 * hallyn quickly checks the others i'll be depending on,
<directhex> doko, pong
<xnox> hallyn: which release are you enquiring about? utopic?
<hallyn> xnox: golang-pty-dev too
<directhex> doko, although i'm about to go to the supermarket
<hallyn> xnox: yeah, utopic, we'll need those SRUd to trusty <cringe>
<doko> directhex, could you upload a mono version using my pretty printers patch?
<xnox> hallyn: golang-context-dev in utopic looks insane. ditto golang-pyt-dev
<hallyn> xnox: AND golang-mus-dev too
<hallyn> golang-mux-dev that is
<directhex> doko, where is that patch? LP?
<hallyn> xnox: so what, we grab the .dsc from lp and re-push with a 'b1' version extension?
<doko> directhex, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752661
<ubottu> Debian bug 752661 in src:mono "make the -gdb.py file compatible with python3" [Normal,Open]
<Shock> xnox, dobey: thanks
<directhex> oh fuck me, i totally forgot about that one
<hallyn> changelog "rebulid bc solar flares" ?
<directhex> doko, yes, totally will do that later today
<doko> directhex, I would appreciate it if you could do a trusty SRU too
<xnox> cjohnston: wgrant: slangasek: looking at $ rmadison -S golang-context-dev -> and then inspecting launchpad looks crazy inconsistent. http://archive.ubuntu.com/ubuntu/pool/universe/g/golang-context/golang-context-dev_0.0~git20140522.1.1f3e8a4-2_all.deb is Available to download, yet launchpad has no idea about such a source version number, nor binary version number.
<xnox> cjwatson: ^
<doko> cjohnston seems to be a problem ;-P
<xnox> hallyn: it looks beyond my powers. I believe you need people with powers as above, sans s/cjohnston/cjwatson/ (thanks doko ;-PPPPP it's not like i didn't notice ;-) )
<jdstrand> mdeslaur, pitti (and tyhicks): https://code.launchpad.net/~ubuntu-core-dev/apparmor/master being out of date is just an oversight
<xnox> doko: or e.g. do you have special launchpad powers?
<jdstrand> mdeslaur, pitti (and tyhicks): lp:~apparmor-dev/apparmor/apparmor-ubuntu-citrain is an experiment
<mdeslaur> jdstrand: oh, hrm, ok
<jdstrand> mdeslaur: we talked about this before with your last upload
<hallyn> xnox: thanks :)
<mdeslaur> well, my memory of that talk was that we were switching to the other one :P
<jdstrand> we don't have a resolution yet cause we haven't done enough experimenting yet
<xnox> hallyn: so the source and binary are in the archive, as seen here http://archive.ubuntu.com/ubuntu/pool/universe/g/golang-context/ yet launchpad has no recollection of building of publishing that.
<jdstrand> my resolution was you said that you wanted to always use https://code.launchpad.net/~ubuntu-core-dev/apparmor/master
<Shock> xnox: would pull-lp-source, patch locally then bzr push to personal branch that has build recipe work?
<hallyn> xnox: and same with the other two i assume?
<jdstrand> s/resolution/recollection/
<mdeslaur> jdstrand: heh :)
<hallyn> Shock: no, pull-lp-source won't grab it
<mdeslaur> jdstrand: I'll update it, thanks
<jdstrand> and that I said, "well, it isn't important enough to be distracted by it now, so let's wait"
<hallyn> (which was why i suggested dget on the .dsc)
<jdstrand> s/that/then/
<Shock> hallyn: pull-lp-source to get archive version of package
<hallyn> Shock: it will grab the old version
<jdstrand> mdeslaur: you had reservations about all the apparmor devs having commit access. I think that is a valid concern worth discussing
<desrt> jdstrand: mdeslaur, hallyn: now that i have you all in one place: libvirt + qemu + apparmor was giving me quite some grief yesterday
<mdeslaur> desrt: how so?
<desrt> it seems that adding custom commandline arguments to a libvirt vm config is a really great way of triggering apparmor violations
<xnox> Shock: it may. pull-lp-source gives you an unpacked debian source package. It's not a branch. You can e.g. bzr init; bzr commit; bzr push as you wish, etc.
<jdstrand> yes, I would think it would be
<desrt> which i responded to in the usual way: uninstall apparmor
 * jdstrand shakes head
<mdeslaur> desrt: yes, if you customize configs, you need to customize the profile
<desrt> but once you do this, libvirt can no longer start qemu instances at all
<jdstrand> why not just update the profile?
<desrt> because i don't know how
<jdstrand> so, you should be able to uninstall apparmor and have it work, but you need to restart it
<mdeslaur> desrt: so you're looking for a link to the documentation? :)
<desrt> uninstalling apparmor shouldn't cause libvirt to stop working in any case...
<hallyn> desrt: if libvirt thinks it should be able to confine the vm and now it can't, it'd be unsafe for it to do so
<desrt> jdstrand: restart libvirt?  i did try that.... didn't help.
<hallyn> desrt: but here, #ubuntu-hardened ,and #ubuntu-servrer are good places to ask how to update the profile :)  do you have DENIED messages in syslog?
<xnox> hallyn: how do you know about those uploads and binaries? and where are they actually coming from? Since those version numbers do not exist in debian and are mysteriously published
<xnox> hallyn: who/where/what uploaded them?
<hallyn> xnox: i looked at the dpkg-checkbuilddeps for docker.io
<desrt> hallyn: yes.  finally figured out why my disk image which was owned by the right person (and set 666 out of desperation) was getting me "Permission denied" errors when i checked dmesg
<hallyn> xnox: i have no idea.  lemme try one thing,
<jdstrand> you can also adjust /etc/libvirt/qemu.conf to have: security_driver = "none"
<desrt> after an hour and a half of wasting my time...
<desrt> jdstrand: great advice.  thanks!
<xnox> hallyn: scary they happened on 13th of June. I'm not supersticious but still.
<hallyn> sacre bleu!
 * desrt will try that tonight once home again
<hallyn> xnox: wow, i see.  i figured 'full publishing history' on lp would show the 2014 version
<hallyn> xnox: do you know who synced docker.io?
<hallyn> i would bet that person at least knows who did golang-context-dev
<jdstrand> desrt: I maintain adjusting the policy is the safest option. also, libvirtd should be able to run with apparmor uninstalled. I can't really debug what happened over the weekend, but uninstalling apparmor may have left the profile loaded in the kernel. if you uninstalled and rebooted and it didn't start, then there is a bug (it used to work)
<desrt> fwiw, i think i discovered a big part of what makes me hate on apparmor so much, and it would not be too hard to fix it:
<desrt> returning EACCES on apparmor errors is extremely user-unfriendly
<jdstrand> it is EACCES and not EPERM?
<desrt> some new ESECURITY with corresponding "access denied by security framework" or so would mean i don't spend so long pulling my hair out
<desrt> may have been EPERM.
<jdstrand> that isn't how the kernel LSM works aiui. perhaps jjohansen could comment
<xnox> hallyn: no. actually everything is fine.
<desrt> no... it was EACCES -- "Permission denied" (i remember the error message)
<desrt> EPERM would have been "Operation not permitted"
<hallyn> xnox: oh?
<xnox> hallyn: golang-context-dev source package got renamed to golang-context in utopic
<xnox> hallyn: rmadison -S golang-context
<xnox> hallyn: rmadison -S golang-context-dev
<xnox> hallyn: and read sanity from that =)
<hallyn> oh for pete's sake
<jjohansen> jdstrand, desrt: yep mostly we return EACCES that is there error the security frame work is supposed to use
<hallyn> so same with the others i assume;  checking
<jjohansen> yes
<xnox> hallyn: yes.
<desrt> seems weird to mix "error that happens under normal circumstances" with "error that should only fire if something very very bad has happened"
<mdeslaur> desrt: yeah, more info would be nice...Dan Walsh wanted to do that at some point: http://thread.gmane.org/gmane.comp.lib.glibc.alpha/28239
 * desrt assumes apparmor is in place here to mitigate (for example) the VM guest attacking one of the device drivers in qemu and breaking out of isolation
<xnox> cjwatson: wgrant: slangasek: never mind. hallyn and I got confused about golang-*-dev source packages renamed to golang-* whilst keeping all binary names same.
<hallyn> xnox: and yet not for golang-gocapability-dev :)
<xnox> hallyn: for SRU, you'd need to rename them back I believe. as in golang-mux SRU will be for golang-mux-dev, cause it's insane to rename source packages in stable releases =)
<hallyn> xnox: thanks :)
 * xnox goes out for dinner
<desrt> mdeslaur: big +1 on this email from me....
<hallyn> xnox: that's gonna hurt - but thanks
<jdstrand> desrt: it is about protecting vms from each other and vms having various resources on the host. it doesn't do anything for hypervisor (which are in kernel)
<desrt> his words about "lucky enough or skilled enough to know where to look..." is completely true.... (not to mention adding on "connects the dots and remembers....")
<desrt> jdstrand: ya... but the various device drivers are implemented in the qemu binary... if you figured out a way to buffer-overflow one of those (for example) then you could run code as the qemu binary
<desrt> and for example, open files on the host and pass their contents into the guest...
<mdeslaur> yes, the qemu device drivers are an attack vector
<jdstrand> desrt: the qemu binary is run under confinement. what you describe is one thing apparmor protects
<desrt> i've noticed that libvirt goes out of its way to pass most things into qemu via file descriptors.... that's nice.
<jdstrand> yeah
<desrt> seems like a good usecase for seccomp :)
<mdeslaur> yep
<tyhicks> that has been something qemu upstream has wanted for quite a while
<tyhicks> looks like they do utilize seccomp nowadays, but the syscall whitelist is pretty large
 * desrt waits until capsicum is completely reimplemented
<hallyn> package versioning question :)  from trusty to utopic, source package was renamed from golang-pty-dev to golang-pty.
<hallyn> to sru that back to trusty, we need to change the source name back.  what to call the version number?
<hallyn> in utopic, it's now 0.0~git20140315.1.67e2db2-1
<hallyn> should we call it 0.0~git20140315.1.67e2db2-1ubuntu1.14.04.1 ?
<mdeslaur> hopefully someone will fix LSM stacking before capsicum gets implemented
<hallyn> mdeslaur: har har
<mdeslaur> yeah, exactly :)
<slangasek> michagogo: yes, I did see that mail and it's in my queue to answer
<michagogo> slangasek: Great, thanks.
<michagogo> (I just want to avoid it stagnating again)
<slangasek> xnox: so if we don't enable startpar, what happens to an init script that has a dependency on a script that shadows an upstart job?  Are we force-starting the upstart job from the init script hooks, ignoring the upstart job's own dependency declarations?  Or are we letting the dependent init script start without its dependencies guaranteed to be satisfied?  Or are we assuming this case is negligible?
<xnox> slangasek: it must source /lib/lsb/init-functions and if there is matching /etc/init/foo.conf and we are running under upstart it gets short-cirtuited in favor of upstart.
<slangasek> what does "short circuited" mean in this context?  pass-through, or no-op?
<xnox> (this is not present in debian, where instead startpar & startpar-bridge is envofrced)
<slangasek> because both have implications for reverse-dep init scripts
<xnox> slangasek: if called as /etc/rc?.d/[KS]??* -> no-op. If called as /etc/init.d/$foo -> pass through.
<xnox> slangasek: imho we should be removing init.d scripts where both systemd unit & upstart jobs exist.
<slangasek> xnox: "we" being Ubuntu, I guess, since that's a non-starter for Debian?  That implies more divergence where we would like less
<xnox> slangasek: and all "key dependency" init.d scripts -> are either no-op upstart jobs on some arbitrary events (always satisfied before going into a particular runlevel) or symlinked to /dev/null on systemd side.
<xnox> slangasek: yes, "we" being Ubuntu.
<slangasek> well, what's a key dependency here?
<xnox> slangasek: non-LSB defined dependencies currently used by debian scripts.  "umountroot checkfs unmountfs" etc.
<xnox> mountall
<xnox> slangasek: does startpar enforce dependencies? apart from ordering based on dependencies?
<slangasek> xnox: what I mean is, have you reviewed all such dependencies provided by packages that also ship an upstart job and confirmed that only ones in /etc/rcS.d matter?
<directhex> doko, building, for sid. SRU will take longer
<xnox> slangasek: i have not. But isn't my fastest path to systemd by default to (a) write systemd units for packages that have upstart jobs only (b) keep init.d scripts as they are, or if they need event ordering replace them by systemd units
<xnox> thus all non-trivial init.d scripts, and upstart-only should get systemd treatment and job's done.
<xnox> non-trivial init.d scripts are those that e.g. currently depend on upstart-tasks.
<xnox> or are in rcS etc.
<xnox> slangasek: we have insserv enabled today, without startpar. And that's enough for correct behaviour under systemd, and is correct enough under upstart with our lsb-initfunctions.d hook.
<slangasek> xnox: fastest path> we definitely have to have the boot working correctly for our users under either of upstart or systemd for 14.10; it sounds like you're proposing to sacrifice correctness under upstart in order to speed up the transition
<slangasek> I'm not convinced of the "correct enough" without seeing the data to back this up
<xnox> slangasek: enabling startpar will regress boot under upstart for user in 14.10. I would like to avoid regressions under upstart (e.g. boot hangs for whatever reason, and didn't previously)
<slangasek> xnox: my doubt is whether reintroducing the init scripts (which were previously stripped from Ubuntu packages) is enough on its own to regress boot for some overlapping set of users
<xnox> introducing init.d scripts, as we have to this point, is also regressing boot under upstart.
<xnox> true.
<slangasek> yes
<xnox> but we do want inserv support, given that there are packages in debian today that don't support non-inservv installation.
<xnox> that's necessary.
<slangasek> where insserv gives us the symlink ordering on disk, but does not do the dependency-based boot of init.d
<xnox> so, if I do a diff of sid vs utopic: if an init.d script is missing in utopic, but present in sid, it must have both upstart+systemd jobs in utopic.
<xnox> slangasek: well, insserv gives us on-disk correct ordering - same as we have to date with upstart, and it works well enough. (no regression)
<slangasek> if we're not using startpar, and the initscript is a no-op at boot, I don't see any reason to remove the init script in Ubuntu
<xnox> slangasek: and systemd parses lsb-headers itself and can do dependencies without startpar et.al.
<xnox> slangasek: true.
<xnox> slangasek: it's just we need to identify them correctly.
<slangasek> identify them for what purpose?
<xnox> for removal in ubuntu =)
<xnox> we re-introduced a bunch of them by now.
<xnox> *we have re-introduced a bunch of them by now.
<slangasek> but removing them doesn't improve anything
<slangasek> so we should just not remove them, in which case we also don't need to identify them
<xnox> =))))
<slangasek> the one impact this *will* have is on boot speed under upstart
<slangasek> which was part of what startpar was meant to address
<slangasek> the fork+exec+source for each reinstated init script will be non-negligible
<xnox> slangasek: true, boot speed will regress under upstart. And we will no longer have fair comparison against systemd to spot regressions.
<xnox> slangasek: how do I make startpar bridge reliable for real? one suggestion, is to make upstart-startpar-bridge instances write out files in /run, which startpar can inspect to get complete cold-boot picture, in addition to interractive notifications.
<xnox> (b) how to properly "pass" init.d scripts that bailed-out in pre-start
<xnox> (c) how to properly "pass" init.d scripts for which upstart job got "manual"-ed
<xnox> (a) above was, how to get correct state from before startpar is executed (i.e. catch tasks)
<slangasek> xnox: "reliable for real"> so requiring all upstart jobs that map to existing init scripts be non-task non-instance jobs was insufficient to make it reliable?
<slangasek> the /run trick wouldn't help for c)
<xnox> slangasek: that resolves (a). It doesn't resolve (b) nor (c). And doesn't help to resolve (a) for sysadmin/3-rd party vendor installed system upstart job & init.d script  (e.g. plex server)
<xnox> i.e. making upstart jobs non-task/non-instance in distro, only resolves it in distro.
<slangasek> xnox: plex server both has a task/instance upstart job, and reverse-dependencies of its init script?
<slangasek> bearing in mind that otherwise, the failure scenario here should be "startpar never finishes", not "system hangs on boot"
<xnox> slangasek: [and reverse-dependencies] is redundant.
<slangasek> no
<slangasek> because nothing else should care if startpar hangs waiting for a single job that will never finish
<xnox> slangasek: starpar hangs on instance/tasks that are in TARGETS = without any reverse-depends.
<slangasek> yes, but "startpar hangs" doesn't break the system, it just leaves an annoying startpar process running
<slangasek> unless this has changed?
<xnox> hanging startpar => fail to reach runlevel 2 => fail to run tty1 => fail to start startpar for shutdown.
<slangasek> no
<slangasek> startpar is run twice, once for rcS and once for rc2
<xnox> that's what pitti and I have seen.
<slangasek> we need startpar for rcS to be reliable, if it's used
<slangasek> but there should be no third-party init scripts in rcS
<xnox> ok.
<slangasek> and for rc2, startpar is called *after* the runlevel event is emitted; and nothing else cares if startpar finishes
<xnox> slangasek: i beg to differ.
<slangasek> the 'rc' job will never finish, until another 'runlevel' event is sent
<slangasek> xnox: for runlevel 2, the runlevel event is emitted by rc-sysinit; startpar is invoked from rc
<xnox> slangasek: tty1.conf is start on stopped runlevel [2345], hanging rc runlevel 2 job, prevents tty1.conf from running.
<xnox> sorry
<xnox> tty1.conf is start on stopped *rc RUNLEVEL=[2345]*
<slangasek> right, tty1 is a special case
<slangasek> specifically because we want the prompt to wait until all our startup jobs have finished outputting
<xnox> and not-starting tty1 imho is a critical regression.
<slangasek> hmm, I don't agree
<slangasek> anyone who cares about the prompt on tty1 should certainly also know how to switch VTs to log in on tty2
<slangasek> and everyone who doesn't care about the prompt on tty1 is looking at lightdm anyway, which has no such dependency
<xnox> clouds don't know how to switch ttys =)
<xnox> you just broke cloud-init
<slangasek> the cloud's console isn't on tty1 either, is it?
<xnox> some of them are
<xnox> I have used crappy clouds though =)
<slangasek> hmm
 * xnox being Latvian and all that shady torrent-boxes of mine
<slangasek> I know there was talk about supporting consoles in the cloud images, but I thought they were serial console
<slangasek> smoser: ^^ can you set me straight here?
<utlemming> slangasek: it depends on the cloud. There are clouds with all sorts of console. OpenStack clouds tend to offer consoles.
<slangasek> utlemming: a console in the form of tty1 with no VT switching?
<xnox> slangasek: easier than that. "cloud-final is start on (stopped rc RUNLEVEL=[2345] and stopped cloud-config)
<xnox> "
<slangasek> man
<xnox> slangasek: thus without a complete rc, we don't have complete cloud-init, thus all instances stuck in initialising states.
<utlemming> slangasek: yeah, you don't get a VT to switch between
<xnox> slangasek: which kind of brings us to another point. How do I see us supporting systemd for cloud images? Install systemd & reboot? publish a (limited) image flavour which boots with systemd?
<xnox> slangasek: hanging rc, means hanging startpar, and two startpars don't like to run in-parallel to each other. Which is what pitti found out, but i didn't reproduce/investigate yet.
<slangasek> xnox: so that brings us back to /run; that addresses your a), but doesn't seem to address either b) or c).  But the alternative to making startpar reliable is just to not enable it at all
<slangasek> "don't like to run in parallel" - doesn't the previous one die when the rc job dies on 'stop on runlevel [!$RUNLEVEL]'?
<xnox> slangasek: it should. Hence I say, didn't investigate yet.
<slangasek> ok
<xnox> slangasek: would you agree, that things that have no reverse depends in .depends.* files, and are listed in TARGETS, should be simply skipped without any notifications from starting, if they happen to have an equivalent upstart job?
<smoser> xnox, for 15.04, or whenver we fully cut over
<smoser> it will just be /sbin/init and work as expected
<smoser> prior to that, my goal was to create a cloud-config syntax that cloud-init would see
<xnox> smoser: ok. and before that, we test/develop it however we need/like/can.
<smoser> and then would change the init system of the image and reboot
<xnox> smoser: ack.
<smoser> thats why I asked about dpkg-divert
<xnox> smoser: i'm sure slangasek would cringe over dpkg-diverting /sbin/init =)))
<smoser> it is orders of magnitude easier if i can switch the init system by simply replacing /sbin/init
<slangasek> wut
<slangasek> you do not need to dpkg-divert anything.  You install systemd-sysv and remove upstart.
<slangasek> if you need to tinker locally prior to that, you can either pass init=/lib/systemd/systemd on the kernel commandline, or you can dpkg-divert *locally*; but please don't distribute images that use dpkg-divert
<smoser> it would be locally.
<smoser> we're not distributing different images.
<slangasek> ok
<smoser> i'm fairly adverse to that.
<slangasek> then that's fine, feel free to trash your local filesystem any which way ;)
<xnox> slangasek: $ apt-cache show systemd-sysv
<xnox> NikTh: Can't select versions from package 'systemd-sysv' as it is purely virtual
<xnox> hm...?
<smoser> what i was saying was that you create an lxc cloud iamge container or cloud image via kvm
<smoser> by passing cloud-config like:
<smoser>  http://paste.ubuntu.com/7762188/
<xnox> NikTh: unping -> stupid xchat expanding "N:" in the paste.
<smoser> the init system that is already present (upstart) would run to the point where cloud-init got that data.
<NikTh> haha, no worries xnox :)
<smoser> cloud-init would replace init (however that is supposed to happen) and reboot
<slangasek> xnox: yes, until that package is introduced in Ubuntu, nobody should be building any images defaulting to systemd ;)
<smoser> and replacing init via:
<smoser>  dpkg --divert ... i dont remember syntax /sbin/init /lib/system/systemd
<smoser> is much easier than
<smoser>  sed /etc/grub/ && update-grub
<slangasek> smoser: maybe you just want 'cp -a /lib/systemd/systemd /sbin/init'
<smoser> (which wouldn't work on lxc anyway)
<smoser> i'm not opposed to that.
<slangasek> since, ah, you would need to do that part *anyway* in addition to the dpkg-divert
<slangasek> (all the dpkg-divert does is let the change persist across upgrades of the upstart package)
<xnox> slangasek: what do you think about https://code.launchpad.net/~xnox/ubuntu-seeds/platform-init/+merge/225850 ? cause currently systemd is not available everywhere.
<slangasek> xnox: why does it need to be available everywhere?  People can apt-get install it for experimentation, and the thing we ultimately want seeded is systemd-sysv in place of upstart
<xnox> slangasek: ok.
<xnox> slangasek: can we go ahead and merge new sysvinit with split startpar, at this current state of affairs?
<xnox> slangasek: (aka pitti's prepared merge of doom)
<slangasek> xnox: hum.  I had asked to review that merge before it was uploaded, and I haven't seen an MP or anything for this yet?
<xnox> slangasek: it has not been uploaded. I thought there is an MP for it. Let me check.
<xnox> slangasek: thought it would be in https://launchpad.net/~pitti/+archive/systemd, but it isn't.
<smoser> slangasek, why would i need that part too ?
<xnox> slangasek: will poke pitti tomorrow.
<slangasek> xnox: yes please :)
<smoser> oh. i see. yeah, i was going to just link it.
<slangasek> smoser: yeah, you would need cp or ln, the dpkg-divert is only relevant for the upgrades and is probably not worth futzing with here :)
<slangasek> xnox: there's a lot of history in the terribleness of the Debian sysvinit package, it's really best if I review this before it gets uploaded
 * xnox goes for a cup of tea and biscuits.
<jtaylor> doko: you merged blt to utopic will you also take care of its now broken rdepends?
<slangasek> mterry: I'm puzzled by your response on ubuntu-phone
<mterry> slangasek, oh how?
<slangasek> mterry: specifically: why should the lock screen behavior be tied to whether the user account has a password set?
<mterry> slangasek, why wouldn't it be?  Would you use nopasswdlogin group membership to determing swiping of lock screen, or would you use an out-of-PAM method of storing the lock screen passphrase?
<slangasek> mterry: the choice of authentication method is a separate thing from whether the user has a password
<slangasek> mterry: as in my example, I want to require a password for risky things like getting root privs over adb, but that doesn't mean I want to be typing a password on an OSK every time I unlock my phone
<mterry> slangasek, design doesn't want to have a user set 'just swipe to unlock' and then also have to remember a password
<slangasek> why does this hypothetical user have to remember a password at all?
<mterry> At least that's how mpt designed it
<mterry> slangasek, well who is setting the root privs password then?
<slangasek> erm
<slangasek> the user
<slangasek> I understood that you wouldn't have sudo *unless* you set a password
<mterry> slangasek, so he does have to remember a password
<slangasek> only the user who wants to allow sudo access over adb!
<sarnold> .. or the local Terminal app, right?
<mterry> sarnold, right
<slangasek> ok, and?
<slangasek> a normal user doesn't need root privs at all
<slangasek> this is a developer-only feature
<mterry> slangasek, so you want to set a password in the UI.  Then also say only swipe?  And have it remember the password you entered before?
<mterry> The UI doesn't allow that, which is by design
<slangasek> if I don't set a password, what happens when I type 'sudo -s'?
<slangasek> if I do set a password, what happens when I lock my phone and then want to unlock it?
<slangasek> if the answer is that I have to type a password on the OSK each time, there's some table-flippin' on the horizon
<mterry> slangasek, if you don't set a password, sudo only authenticates you if your tty is listed in /etc/securetty
<slangasek> and which ttys are we listing there?
<mterry> slangasek, if you do set a password, you enter your password on the OSK
<mterry> slangasek, Touch doesn't customize it.  But nothing with pts/* is in it (i.e. nothing remote, nothing in X/Mir)
<slangasek> and the security team was happy with this design?
<mterry> This is long-standing behavior
<slangasek> the long-standing behavior is broken, we're supposed to be making adb secure :)
<slangasek> but it also needs to remain usable
<mterry> those two are always at odds  :)
<slangasek> no, they aren't
<sarnold> slangasek: working with mterry on a reasonable sudo strategy in the face of no pin is on my todo for this week :)
<slangasek> design may have said to do it this way, but I don't understand why the security team would have signed off on a design that gives people a false dichotomy between "always type a password everywhere" and "no sudo for you"
<slangasek> sarnold: ok
<sarnold> I don't immediately see any problems with allowing a blank passwd at sudo if that was configured for login, too
<sarnold> it could be that the securetty PAM module we're using needs to be extended or replaced to allow local logins via Mir-originated applications, or something similar
<sarnold> slangasek: what's the goal with "make adb secure"?
<slangasek> I'm not sure "let Mir apps get in without a password" is an interesting security model
<slangasek> sarnold: AIUI the goal is to not let a rogue USB host adb in and screw around with things without the user's awareness - which I think implies: "non-root by default", "no adb when screen is locked", "adb disabled by default"
<mterry> slangasek, do you envision an exception for terminal-app or just not allowing sudo in Terminal?
<mterry> But you do want to make an exception for adb
<slangasek> sarnold: however, I'm not driving this - I thought this was all mdeslaur's design, which is why my question on the list was addressed to him :)
<slangasek> mterry: I think we're talking past each other here
<slangasek> mterry: passwordless sudo is uninteresting to me as a dogfooding developer; I prefer that root access come with a password prompt
<slangasek> mterry: but I do not want "require password for root access" to translate to "require password to unlock my phone"
<slangasek> because I expect the security requirements for a password that gives you root access to dramatically differ from the security requirements for an unlock "password" that I will use on a routine basis
<slangasek> (PIN vs. password)
<mterry> slangasek, my apologies, right.  Well for that, I can only say that the last time I spoke to mpt about it, he didn't want a separate password beyond the one set in the UI for locking the screen
<slangasek> ok, so who's the security team's stakeholder for this design :-)
<slangasek> I'll route through them
<sarnold> slangasek: probably mdeslaur would be best. I had hoped to handle this one myself but I'm obviously missing too much context to provide reasonable answers :)
<slangasek> ok :)
#ubuntu-devel 2014-07-08
<xnox> mterry: device password to e.g. change sim card on an android phone != pattern to unlock the home screen. Ditto PIN, PUK numbers, and google account password.
<sarnold> PUK?
<xnox> and i do understand why mpt would hate multiple passwords, but we also do not expect users to use sudo.
<xnox> sarnold: PUK unlocks PIN if it's locked out after 3 unsuccesful tries.
<sarnold> xnox: ah :) thanks
<xnox> sarnold: typically PUK is 10-12 characters.
<xnox> sarnold: and one typically needs PIN2 to change PIN1, and PUK2 to change PUK1. Not sure how PIN2 can be changed, or PUK2.
<sarnold> *snort*
<xnox> sarnold: most current operators though disable PIN1 and/or set it to 0000.
<mterry> sarnold, well if mdeslaur and you have opinions on whether the lock screen can/should be distinct from the sudo password, let me know
<xnox> mterry: well, it is separate on our current desktops. One can auto-login, but that doesn't e.g. unlock keyring, nor requires one to type your password. I think that's what slangasek means here.
<mterry> xnox, right but the next time you lock your screen, you do have to enter your password
<xnox> mterry: it's only one password, it is sufficient to unlock lock screen, but it's not required to unlock the screen.
<mterry> xnox, Desktop allows a one-time boot unlock without a password.  We could certainly do that on phone, but not useful
<xnox> mterry: depending on how lock screen is setup. I have udev rules to token unlock my lock-screen without a password.
<xnox> (though less common)
<mterry> xnox, that's neat  :)
<xnox> mterry: only on my desktop at home though =) not on my laptop.
<mterry> xnox, we can do all sorts of things.  I've just been told by security that the unlock password should go through PAM.  And I've been told by design that we should only have one password
<mterry> I'm happy to change either one
<xnox> mterry: taking those two constraints, we can devise pam rules for lock screen to have a toggle wether pam should be letting one through based on physical access to screen alone, or password prompt as well.
<mterry> xnox, well I meant that design wanted swipe-to-unlock == no password
<xnox> mterry: all of it should go to pam - such that pam decides if "swipe from mir" is enough to unlock or not, for a given account.
<xnox> mterry: design wanted swipe-to-unlock == "users sees it's homescreen / last app" =)))) i'm sure they don't care whether behind the scenes greeter send swipe/login attempt to pam and pam based on local presense authenticated user transparentely without requiring to type in password.
<mterry> xnox, mpt said "the ability to use sudo is nowhere near
<mterry> justification for asking every swipe-to-unlock user to choose a password that most of them will never use."
<xnox> cause i should be able to ssh in, change to require password, and then swipe to unlock returns does login attempt and pam denies that, quering password, and lock screen on swipe presents me with a password prompt.
<xnox> if password is empty, let through.
<xnox> pam is a series of commands: so we will just need to configure it right -> if no password, let through.
<xnox> if password, and local user/display access, let through.
<xnox> otherwise password authentication is required/mandatory.
<xnox> but it will allow people to e.g. configure NFC yubikey tokens to do e.g. 2fa screen unlock if they so require. password + nfc tap on the back.
<xnox> or just one or the other...
<xnox> similar how on iphone one can do touchid or password. Or on android face-unlock or password.
<xnox> greeter shouldn't care less, just do authentication atempt to pam, and handle queries & errors from pam if there are any. And off-load security to sarnold & mdslaur =)
<mterry> xnox, sure.  I'd have to look into how to branch on local swipe
<sarnold> hehe I just hope we ccan have some nice GUIs in front it, I don't like doing /etc/pam.d/ by hand, surely most of our users won't like it either :)
<mterry> xnox, using PAM is certainly the current plan
<xnox> sarnold: have you not seen systemd-logindpam yet?
<sarnold> xnox: I can't tell if that's a joke or not at this point..
<xnox> sarnold: and the nice kdbus APIs with QML UI in ubuntu-system-settings for it?
<xnox> sarnold: it's 1:34AM here ;-)
<xnox> good night all! =)
<sarnold> xnox: good night :)
<mterry> xnox, u-s-s has UI for PAM?
<mterry> I've seen the UI, but not the underpinnings that talk to PAM
<mterry> xnox, goodnight
<sarnold> mterry: I think he's getting giddy :)
<mterry> sarnold, another thing -- I assume if we're using PAM for the phone passwords, we want to disable the 'obscure' option to pam_unix, in order to disable the password-strength checks it employs?  PIN and I imagine most user's passphrases would probably not pass muster
<sarnold> mterry: hah, yes, that's probably true
<mdeslaur> slangasek, xnox, mterry, sarnold: if there are requirements to have more than one user password, such as a PIN to unlock the current session, but a password to login to decrypt the home directory, etc, we should have a meeting and talk about it
<mdeslaur> I'm not sure what the exact requirements are
<mdeslaur> but having different passwords depending on the service appears quite odd to me
<sarnold> I can definitely see a short pin for unlocking the interface but a good password for e.g. ssh or sudo or ecryptfs..
<mdeslaur> sarnold: so you boot, get a screen that asks for your password...at that screen, you enter your long password, but then if you press power and power back on, you need to enter a pin?
<mdeslaur> how is that not completely incomprehensible to users?
<sarnold> mdeslaur: heh I do that with my laptop now -- two passwords, one for each hard drive, then a login password that also unlocks the session
<mdeslaur> sarnold: I don't think you're our target market :)
<sarnold> mdeslaur: I can see your point but I also see slangasek's point that it'd be nice to only allow sudo after seomthing better than just a four or six digit pin..
<sarnold> mdeslaur: that's what worries me :) lol
<sarnold> mdeslaur: but that's the best part about PAM, us oddballs can configure what we want.
<mdeslaur> sarnold: so you're ok with having 100% of your personal data be available with a 4 digit pin, but then have sudo, which gains an attacker NOTHING else require a stronger password?
<sarnold> mdeslaur: yes; the sudo access would let someone e.g. capture keystrokes used for unlocking passwords in a password storage app or the password for my bank. they'd be hard pressed to pull that stunt with just a login pin.
<mdeslaur> sarnold: nonsense, they can do that just fine with your user account access
<mdeslaur> it's all running under your user session
<slangasek> mdeslaur: right, my point is that anyone who wants to use sudo on the device is not a target "market" at all, so we shouldn't constrain the design of our root access interface by what works in the market :)
<slangasek> I wouldn't expect a PIN-based unlock screen to use the user password at all
<slangasek> i.e., that's an alternate authentication mechanism, not a password
<mdeslaur> slangasek: so in your use case of power users, can't they figure out by themselves how to do 'sudo passwd" like they currently do on the desktop?
<slangasek> mdeslaur: how are they supposed to do that?  Are you suggesting that 'sudo' should work passwordless by default?
<mdeslaur> no, sudo only works once you've set a PIN or a password
<mdeslaur> for your lock screen
<slangasek> ok
<slangasek> and if I type 'sudo passwd' and change the password, what happens?
<slangasek> I change root's password?
<slangasek> but sudo access is still available with just a weak PIN?
<mdeslaur> same as on desktop, you've now set a password for the root account, at which point you can remove your sudo access
<sarnold> heh, and watch juju blow up in a million little pieces..
<mdeslaur> slangasek: so...if the PIN is only for the lock screen, what is used to unlock the keyring password?
<mdeslaur> what about ecryptfs?
<mdeslaur> yes, a 4 character PIN is crummy...but the whole point is that if the screen is locked, you can't use sudo in the first place
<slangasek> mdeslaur: ah; I didn't follow that to its logical progression, I didn't understand that "sudo passwd" was followed by "and remove yourself from sudoers" since I never do that :-)
<mdeslaur> well, I don't either, but then again I don't want to use two different passwords :)
<slangasek> I don't either
<slangasek> I want to use a password vs. a PIN ;)
<mdeslaur> so PIN is just for the lock screen?
<slangasek> PIN is for phoney things
<slangasek> sudo is not a phoney thing :)
<mdeslaur> you always use the strong password at first boot, and then only PIN for the second time your phone locks?
<mdeslaur> or do you _only_ want the user to set a strong password for sudo, but all the rest uses the PIN?
<slangasek> you ask good questions
<mdeslaur> like, I can use pkexec with only the PIN, but sudo requires a strong password
<slangasek> what I do know is that as a power user I would be very surprised to find that setting a PIN on my phone means that this PIN can be used to grant *additional* (i.e., root) access
<slangasek> vs. having the phone unlocked
<mdeslaur> hrm, perhaps...but the PIN grants access to 100% of your personal data
<sarnold> but 0% of the user data of the other users on the system..
<mdeslaur> even if we disabled sudo by default, or set a new password for it...there's pkexec, and a whole bunch of other ways with policykit to gain root access
<sarnold> well. okay, more than 0%, but still..
<mdeslaur> sarnold: not if you're not an administrative user
<mdeslaur> I do see the point, but short of asking the users for two passwords, I'm not sure how to solve this
<slangasek> mdeslaur: is there any reason to enable sudo use without asking the user for the second password? possibly in a more obscure part of the UI?
<mdeslaur> we can easily disable sudo, but all the policykit stuff still either requires a strong password, or will default to the 4 digit PIN
<mdeslaur> if we really want to do this, we need to remove the user from the admin group by default
<slangasek> hmm
<slangasek> not sure of the knock-on effects there
<slangasek> anyway
<mdeslaur> well, there's possibly quite a bit
<slangasek> sorry for upsetting the cart :)
<slangasek> but now I'm going to run off to dinner
<mdeslaur> that's fine, we can talk about this again tomorrow
<mdeslaur> others are apparently upset that users can access application data too
<mdeslaur> which is part of the same problem
<robert_ancell> I'm trying to do a SRU for accountsservice in trusty and I'm getting: "Rejected:
<robert_ancell> Unable to find accountsservice_0.6.35.orig.tar.gz in upload or distribution.
<robert_ancell> Files specified in DSC are broken or missing, skipping package unpack verification"
<robert_ancell> that should be in trusty right? The current trusty version 0.6.35-0ubuntu7
<robert_ancell> I'm very hesitant to upload the .orig again if LP is confused...
<tarpman> robert_ancell: looks like a .orig.tar.xz was uploaded originally
<tarpman> https://launchpad.net/ubuntu/trusty/+source/accountsservice/0.6.35-0ubuntu7
<robert_ancell> yeah, that's what I though
<robert_ancell> t
<pitti> good morning
<pitti> meh, freenode is broken through my proxy, lost over-night scrollback
<dholbach> good morning
<sil2100> pitti: hello!
<pitti> hey sil2100, how are you?
<sil2100> pitti: fine, thank you - how about you?
<pitti> sil2100: quite fine, thanks! having fun with click tests
<sil2100> :)
<bzoltan> ping pitti
<sil2100> pitti: I wanted to poke you for some advice, as one of our upstreams seems to have problems with autopkgtests failing, where the tests seem to be fine when ran locally on the device
<sil2100> pitti: bzoltan exactly ^
<sil2100> ;)
<sil2100> pitti: a new release of the UITK seems to have caused ubuntu-system-settings-online-accounts to fail, but bzoltan has problems reproducing it - so maybe there are some specifics to how autopkgtests are being ran?
<pitti> sil2100: ah, that race again; I already retried it like 5 times, doesn't seem to be so easy to evade now :/
<sil2100> pitti: is that some known race condition..?
<pitti> sil2100: it's running exactly like in http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test (except for trusty -> utopic, of course)
<bzoltan> pitti: have you rebooted the test device before running that test?
<pitti> bzoltan: no, the dist-upgrade didn't seem to affect anything boot relevant, so it didn't reboot after dist-upgrade
<pitti> bzoltan: did you run with -proposed enabled? there are a bunch of new packages in -proposed which may have broken it?
<bzoltan> pitti:  I run the tests after a clean proposed image flash
<pitti> bzoltan: oh, this is not a test on the phone, but an autopkgtest of the debian package in QEMU
<pitti> timings there are slightly differetn
<pitti> it doesn't find header = self.window.select_single('Header', visible=True)
<bzoltan> pitti: and I run it on the device with phablet-test-run online_accounts_ui
<pitti> is that at a point where the header is guaranteed to exist? it may need a wait_select_single()?
<bzoltan> pitti: Maybe, I am not familiar with all the AP tests of each app.
<bzoltan> pitti:  but in a different environment a race condition can mess up things for sure
 * pitti runs it locally
<pitti> passed here, but again my machine is pretty fast; yay timing issues
<pitti> bzoltan: ah, haha!
<pitti>     def test_title(self):
<pitti>         # On the phone, this fails because of https://bugs.launchpad.net/bugs/1252294
<pitti>         if model() != 'Desktop':
<ubottu> Ubuntu bug 1252294 in unity-mir "Application window appears in the background" [High,Confirmed]
<pitti>             return
<pitti> bzoltan: but with QEMU this would actually be "Desktop"
<bzoltan> pitti:  ARGHHHH :D :D
<sil2100> Oh ;)
<pitti> so that means that after self.window.visible is true, the Header isn't immediately visible
 * sil2100 knew that pitti would identify the problem
<pitti> but that != "Desktop" might just hide the race condition when running on the phone
<pitti> there's a bunch of those in those tsets, including in setUp()
<pitti> bzoltan: btw, it's better to @unittest.skipUnless() those instead of returning, to make it more obvious in logs
<pitti> (or skipIf())
<pitti> so in summary, ISTM that wait_select_single() is correct there, to avoid the assumption that opening the app makes the header bar appear instantaneously
<xnox> pitti: so last night steve and I chatted about startpar & inits. It seems we can be merging new sysvinit/startpar as you wanted, but steve still wants to review that merge (i didn't find it on the spot, but i thought you may have had it prepared somewhere). Reasons to fix startpar for real, are regressed bootspeed under upstart at the moment due to each no-op init.d script that we introduce.
<pitti> xnox: ah, thanks; I still have my old merge, but after all the changes since then it basically needs re-doing
<pitti> (but should also be simpler)
<bzoltan> pitti: sorry I lost my net
<pitti> bzoltan: recent backscroll: http://paste.ubuntu.com/7764422/
<bzoltan> pitti: thanks ... so what should I do now?
<pitti> bzoltan: as I said, I think the right solution is to use wait_select_single(); I have no idea about whether the tests should be re-enabled on the phone
<bzoltan> pitti: So it seems that there is an MR https://code.launchpad.net/~elopio/ubuntu-system-settings-online-accounts/clean_tests/+merge/225437 to address this problem. Is there a way to unblock the UITK landing?
<pitti> bzoltan: yes, the release team can ignore particular failures
<pitti> (#ubuntu-release)
<bzoltan> pitti: thanks, I just did.
<cjwatson> pitti: I tried to run http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test on utopic to test stuff for bzoltan, and got http://paste.ubuntu.com/7764968/ while installing build-deps (and a bunch of follow-up failures); am I doing something wrong or is that an autopkgtest bug?
<pitti> cjwatson: uh, that was fixed many weeks ago -- this might be trusty's autopkgtest?
<pitti> cjwatson: it was a missing LSB header in the VM setup script for autopkgtest, yes; this only appeared when moving to insserv
<cjwatson> My host is trusty
<cjwatson> Don't see why the guest should be though ...
<cjwatson> It thinks it's utopic for everything else
<pitti> cjwatson: so you need at least the current version of http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob;f=tools/adt-buildvm-ubuntu-cloud;hb=HEAD
<pitti> cjwatson: if you want to build utopic guest VMs
<cjwatson> pitti: Ah.  Is there something I can do to my current VM to fix it, so I don't have to download all this again?
<pitti> cjwatson: yes, you can boot it in kvm (kvm -m 2000 -drive file=adt-utopic.img,if=virtio)
<pitti> cjwatson: then add the LSB header like in above script
<pitti> phone, brb
<cjwatson> OK, brilliant, thanks
<pitti> cjwatson: http://paste.ubuntu.com/7765010/
<cjwatson> pitti: yep, got it, thanks
<mvo_> stgraber, pitti: is lxc in utopic ready for systemd? I get errors from lxc-start that lxcbr0 is not ready, which indicate that lxc-net is not running (and indeed I just see a upstart.conf file in the package no sysvinit or systemd afaict) - known issue?
<mvo_> pitti: aha, I see bug #1312532
<ubottu> bug 1312532 in lxc (Ubuntu) "[systemd] Factorize lxcbr0 setup and use it for all init systems" [Low,Confirmed] https://launchpad.net/bugs/1312532
<xnox> mvo_: the terms are upstart job, init script, and systemd unit =))))))) ( i cringe over upstart.conf, cause in fact upstart does inotify watch for /etc/upstart.conf which must be empty or non-existant =)))) )
<mvo_> xnox: *cough* sorry, I will remember that
<xnox> mvo_: meh, pointless details =) don't worry about it.
<mvo_> xnox: and I know that in theory, in practice I was too annoyed to pay attention ;)
<xnox> mvo_: yeap. We don't have systemd support for lxc, cloud-init and openstack at the moment.
<xnox> ( or well, last time I have checked)
<mvo_> xnox: ok, not a big deal, it looks like its pretty simple for lxc to add though, is someone on it already or should I give it a shoot?
<xnox> mvo_: unless stgraber has, i don't think anyone looked into it. Debian has some integration, but it's different from ours.
<pitti> mvo_: right
<pitti> mvo_: I also ran into something else, hang on
<xnox> mvo_: and no idea if we can do unpriviledged lxc under systemd, the way we can under upstart.
<mvo_> pitti: the apparmor issue?
<pitti> mvo_: bug 1325468
<ubottu> bug 1325468 in lxc (Ubuntu) "[systemd] container startup fails with AppArmor" [High,Triaged] https://launchpad.net/bugs/1325468
<pitti> mvo_: there's a proposed fix in there
<mvo_> nice, I haven't seen that
<stgraber> mvo_: lxc itself works fine with systemd but the systemd unit doesn't do the same thing that our upstart job does
<stgraber> mvo_: which means, no network configuration
<pitti> or rather, it doesn't have systemd units at all :)
<stgraber> mvo_: all the init scripts (sysvinit, upstart, systemd) are upstream and I think it'd make a lot of sense to have all of them do the same thing. It's something I'm aware of but hasn't been a priority so far.
<stgraber> pitti: oh, right, that's because we haven't turned on the systemd unit for Ubuntu in the upstream branch (configure.ac has a mapping of what needs to be built for what distro)
<stgraber> pitti: though there's not much point turning that on until we get the same experience with sysvinit, upstart and systemd, so might as well do both at once
<pitti> and I suppose that one bit in the  apparmor policy needs to be fixed
<pitti> stgraber: well, we don't care much about sysvinit, but the Debian packages certainly do
<pitti> although they are completely different (and honestly, quite a mess)
<stgraber> pitti: right, I'm talking as LXC usptream here. I'm tired of Debian users never managing to get the network right, so I'd much rather we split all those setup bits into a separate tool and have all the various init scripts call that for a nice consistent behaviour.
<pitti> stgraber: exactly, that's pretty much what I proposed in that bug, I just call "~/lxc-net start" whenever I need it :)
<stgraber> pitti: what's the apparmor issue again? (sorry, not good at remembering bug reports :))
<pitti> stgraber: bug 1325468
<ubottu> bug 1325468 in lxc (Ubuntu) "[systemd] container startup fails with AppArmor" [High,Triaged] https://launchpad.net/bugs/1325468
<pitti> it needs an additional "mount options in (rw, slave) -> /,"
<stgraber> pitti: hmm, so systemd doesn't support read-only / ?
<stgraber> pitti: the risk with adding that rule is that if /var/lib/lxc is read-only on purpose, starting the container will remount it read-write both in and outside the container
<stgraber> (we had a similar problem with the shutdown scripts remounting / read-only on shutdown which would remount the whole partition read-only on the host. We had to block that with apparmor)
<pitti> stgraber: hm, shouldn't "slave" only apply to one direction, not both?
<stgraber> pitti: I think that's right for slave, but your suggest line also allows "mount -o remount,rw /"
<stgraber> or maybe not
<pitti> stgraber: ah, because of the "in"
<pitti> yeah, maybe there's a way to say "AND" there
<stgraber> "mount options=(rw, slave) -> /,"
<sil2100> hm, where does the pending-sru document take the list of bugs from that require verification for a given SRU?
<stgraber> sil2100: the .changes (or its parsed version)
<sil2100> hm, strange then... ah, or maybe indeed
<pitti> jdstrand: ah, many thanks for your hint how to speed up aa-clickhook!
<jdstrand> yeah, I hadn't thought of that before :) I am updating the man page so others can benefit
<sil2100> stgraber: anyway, thanks!
<kdeuser56> suppose I have kernel version. Where do I find ubuntus config file for that kernel version?
<kdeuser56> (when the kernel is not installed)
<rbasak> kdeuser56: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=tree;f=debian.master/config;hb=HEAD
<rbasak> (that's for Trusty obv.)
<rbasak> And the git tags there map the version numbers
<kdeuser56> rbasak: I have a script that handles the kernel version over a variable ... now I want a wget command that fetches the configuration of that kernel for me ... any more generic idea (otherwise I would have to guess versions etc.)
<kdeuser56> rbasak: is there a central archive that has all .config for all kernels?
<rbasak> kdeuser56: download the deb into /tmp, extract it manually there and look for the config?
<rbasak> kdeuser56: the central archive *is* the git repo, AIUI.
<rbasak> kdeuser56: all the information you need is in the git repository as far as I understand. You just need to extract it.
<rbasak> kdeuser56: you don't need to guess versions. They're all in the git repo as tags.
<rbasak> kdeuser56: if you want to know what version of a package is in a particular release, you can either use the rmadison tool or parse Packages.gz with grep-dctrl or something directly.
<rbasak> kdeuser56: also try #ubuntu-kernel to speak to real Ubuntu kernel folks who might know more.
<kdeuser56> rbasak: could you give me an example command to fetch the a version for extraction?
<kdeuser56> rbasak: (I do not have the necessary experience with git :-()
<kdeuser56> rbasak: I could simply use wget for http://kernel.ubuntu.com/~kernel-ppa/mainline/ ... the annoying thing is the ubuntu release name appended at the end ...
<jdstrand> cjwatson: hey, can you think of any reason why adding override files to /var/lib/apparmor/clicks would trip up click (I would take care of the click-apparmor hook). eg, /var/lib/apparmor/clicks/foo.json.override alongside /var/lib/apparmor/clicks/foo.json
<jdstrand> I could just create another directory
<cjwatson> jdstrand: should be fine as long as it doesn't match your Pattern
<jdstrand> cool, thanks
<kdeuser56> rbasak: ok thanks anyway for your help
<pitti> slangasek, infinity, kees: TB meeting in 2 mins
<pitti> mdeslaur: ^
 * slangasek nods
<mdeslaur> ack
<mdeslaur> pitti: what's the channel name again?
<mdeslaur> pitti: nm, found it
<pitti> #ubuntu-meeting-2
<bdmurray> pitti: Do you know why the libmad0 dbgsym packages are so out of date? http://ddebs.ubuntu.com/pool/main/libm/libmad/
<dholbach> seb128, it's installable now :)
<seb128> dholbach, yeah, it migrated to release, well done!
<dholbach> seb128, well, it was just last 5 metres I had to walk :)
<seb128> dholbach, ;-)
<ari-tczew> cjwatson: M-o-M is broken
 * ari-tczew has no read backlog, maybe it's already confirmed
<cjwatson> ari-tczew: fixed the latest problem.  at some point this will show up at a time when I have enough time to make it more robust rather than fixing the symptoms ...
<ari-tczew> cjwatson: I guess how it's annoying. thanks for your engagement!
<xnox_> GOOOOOOAL!
<xnox_> OMG! =)
<juliank> Yeah, Eisbrecher_xnox
<juliank> I can't write in every channel at the same time
<smoser> bdmurray, could you look at https://code.launchpad.net/~smoser/ubuntu-reports/cloud-tools-next/+merge/226047
<bdmurray> smoser: merged
<smoser> thanks, bdmurray
#ubuntu-devel 2014-07-09
<pepee> hi. I'm copy/pasting my question:
<pepee> in debian/ubuntu, if some package or group of packages is being built/uploaded, the inconsistencies can cause apt to report problems with dependencies. well, why isn't there a "temporary repo" or some kind of config file to indicates that packages are still being updated, so that those inconsistencies are minimized or totally avoided? even more... why don't ubuntu/debian upload packages at night? (I know night in the west means day in the east...
<pepee> well, have some sort of control that uses timezone or something data)
<pepee> not sure if this is the right channel, though
<ScottK> Most people get packages through mirrors so there's no way to control exactly when things get updated.
<pepee> and that's another thing, mirrors could be synchronized, and packages copied through bittorrent!
<pepee> I wonder if that would work
<RAOF> pepee: We actually do that now? Everything goes to foo-proposed, and when it's installable it gets migrated to foo. Likewise, Debian testing.
<pepee> ahh, I didn't know. but I guess that's why I haven't had a broken update/upgrade lately :P
<pepee> and by "lately" I mean, I can't even remember...
<pitti> Good mo-hoorning!
<dholbach> good morning
<Noskcaj> kenvandine, Could you please fix bug 1194211 some time soon? It's the only reverse-depend of valc-0.18 now
<ubottu> bug 1194211 in libfriends (Ubuntu) "Build-depend on valac instead of valac-0.18" [Undecided,New] https://launchpad.net/bugs/1194211
<Mirv> might I get a packaging changes ack from a core-dev for unity8-desktop-session changes? https://ci-train.ubuntu.com/job/landing-002-2-publish/28/artifact/packaging_changes_unity8-desktop-session_1.0.11+14.10.20140709-0ubuntu1.diff
<Mirv> I digged about that added Conflicts, the commit message says "added Conflicts with ubuntu-desktop-mir because that package installs lightdm configs that cause Unity 8 to fail to start"
<flexiondotorg> cjwatson, I've got a tiny merge proposal for ubiquity I'd like to submit. Having never gone through the process before can you check that I am about to proceed in the correct way?
<cjwatson> flexiondotorg: maybe :)
<cjwatson> Mirv: acked
<cjwatson> Mirv: (and publishing)
<Mirv> cjwatson: thanks
<flexiondotorg> cjwatson, here is the diff - http://bazaar.launchpad.net/~ubuntu-mate-dev/ubiquity/ubiquity-marco/revision/6195?start_revid=6195
<flexiondotorg> Should I just go ahead a create a merge proposal and describe why this is required in that proposal. I would you prefer I raise a bug first?
<Eisbrecher_xnox> flexiondotorg: looks ok. Is it "marco" similar to metacity?
<flexiondotorg> marco was forked from metacity.
<Eisbrecher_xnox> flexiondotorg: in that case ubiquity-dm will need modifications to use marco, if present. Otherwise you would need to ship both metacity and marco.
<flexiondotorg> It is compatible with metacity themes/settings etc.
<cjwatson> flexiondotorg: should be fine for a merge proposal, but please do raise a bug so that we have tracking
<Eisbrecher_xnox> flexiondotorg: bzr grep metacity
<cjwatson> and yeah, what Eisbrecher_xnox said
<flexiondotorg> Eisbrecher_xnox, Thanks. Taking a look now.
<Eisbrecher_xnox> flexiondotorg: it should be a simple copy&paste of the metacity cases but "marco" and appropriate key settings. Are you using gnome-settings-daemon / gconf? if that's forked/renamed as well, further adjustments will be needed to accomodate those as well.
<flexiondotorg> Eisbrecher_xnox, some background for you.
<flexiondotorg> I'm working on Ubuntu MATE Remix.
<flexiondotorg> MATE has been fully migrated to dconf/gsettings.
<Eisbrecher_xnox> cool.
<Eisbrecher_xnox> flexiondotorg: if marco is better than metacity, it might make sense to switch unity7 and openjdk to use that instead.
<Eisbrecher_xnox> and finally drop metacity from the archive, cause, as far as I can see, it's not developed.
 * Eisbrecher_xnox checks
<flexiondotorg> Well, my opinion would be biased ð
<flexiondotorg> But yes. Marco is an evolution of metacity.
<Eisbrecher_xnox> wait there is fresh release of metacity....
<Eisbrecher_xnox> Laney: *blink* there was metacity release =) are we gonna take it
<flexiondotorg> Eisbrecher_xnox, does ubiquity require a compositor? I see that ubiquity-dm set org.gnome.metacity compositing-manager to true. I can do the same for marco, but it is actually required?
<Laney> no idea!
<Eisbrecher_xnox> flexiondotorg: not required, but highly desired. please set it.
<Eisbrecher_xnox> Laney: i'll try it out. release notes look harmless-ish https://mail.gnome.org/archives/ftp-release-list/2014-June/msg00019.html
<flexiondotorg> Sure
<Eisbrecher_xnox> mostly
<Laney> Alberts is Ubuntu-ish AFAIK, he might have some plans there
<flexiondotorg> Eisbrecher_xnox, most of what is new in metacity 3.12 is already implemented in marco.
<flexiondotorg> They are pretty much equivalent now.
<Eisbrecher_xnox> Laney: hm. looking at upstream release and our metacity packaging we have practically everything applied as patches by now.
<Eisbrecher_xnox> flexiondotorg: yeah, it still feels weird to me that all components were forked and renamed, instead of keeping existing names and/or continue maintaining them.
<flexiondotorg> Eisbrecher_xnox, The rename was required so that MATE and GNOME (applications and libraries) could be installed side by side.
<flexiondotorg> That was done years ago by the original MATE developer.
<flexiondotorg> The fork was massive, and in many cases, unnecessary.
<flexiondotorg> The MATE Team (i'm a dev) have to aligning with GNOME libraries and in almost all case use the GNOME libraries now.
<flexiondotorg> But, the application rename is still required so that user can have GNOME3 and MATE installed on the same system or just pick and mix the applications.
<flexiondotorg> cjwatson, Eisbrecher_xnox Thanks for your help - I trust this is OK? https://code.launchpad.net/~ubuntu-mate-dev/ubiquity/ubiquity-marco/+merge/226114
<kenvandine> Noskcaj, will do
<hallyn> desrt: hey - so logind when sending the StartTransientUnit sends a "sd_bus_message_append(m, "a(sa(sv))", 0)", without which the sending fails bc of mismatched params.
<hallyn> desrt: that fix (just adding that line) was added after drastic change in how the dbus msgs were formed, and i'm trying to figure out how to build it manually with things like opencontainer
<hallyn> desrt: my quesiton is, what the heck is the point of that?  is it not supposed to be an array containing a string and another array, which in turn contains sv?  but it's not sending any actual values.
<hallyn> anyway i'll go ahead and try just adding them as null values and assume i should ignore them in systemd
<hallyn> oh, wait, i'm going about it wrong
<desrt> dbus is strongly typed
<desrt> even if you have an empty array you need to give an empty array of the correct type
<hallyn> since systemd 208 is waht is in experimental, and it is NOT sending those, i should just not require them in systemd-shim
<hallyn> desrt: ah, gotcha - thanks.  so it's opening the container but not adding any values, sending an empty array
<desrt> yes.  it needs to open the container with the specific type to ensure the array has the correct type
<hallyn> desrt: sorry for the noise, thanks :)
<desrt> in fact, if it didn't do that, it wouldn't even be able to construct the array
<desrt> since "empty array" doesn't exist without more information
<desrt> must be "empty array of ...."
<desrt> this is something that causes a lot of pain :)
<desrt> consider binding to languages like python, for example.....
 * hallyn grasps his side - "tell me about it"
<desrt> pretty easy to guess what is the appropriate type for [1,2,3] or ['a', 'b', 'c']... but you see [] and it's like .... hmm... uhh...
<desrt> (even [1,2,3] is a bit hard since those might be _unsigned_ ints, which is again a different type)
<hallyn> desrt: but the "correct" set of paramaters, or the expected set - that comes from the .xml file in the server end?
<desrt> yes
<desrt> those files are also typically installed in /usr/share/dbus-1/interfaces, fyi
<desrt> and you might find the 'gdbus introspect' command to be helpful
<desrt> there is also a GUI tool called d-feet which is.... not excellent... but certainly very useful
<hallyn> oh yeah i used that a few years ago.  all right, let's see if i can get another half step further this way :)  thx
<desrt> keep poking as you need help... no sense in you spinning your wheels for an hour if i can answer more questions :)
<hallyn> stgraber: slangasek: i'm not gonna like the answer, but i'll ask anyway - does systemd-shim need to also support non-cgmanager cgroup setup?
<hallyn> heh, cgamanger isn't packaged for debian yet, is it, bc it relies on upstart
<stgraber> hallyn: I'd be fine with just requiring cgmanager, cgmanager is in Debian, not sure about how usable it is though...
<hallyn> if i write sysvinit scripts and package for debian can i skip the cgfs bit?
<hallyn> yay
<hallyn> all right i think i may be at the point where i can do something useful.
<stgraber> but I think it'd be entirely fine to have systemd-shim work in Ubuntu with cgmanager, then just tell Debian to get cgmanager in working shape (if it's not)
<slangasek> hallyn: I don't understand the question - are you asking whether systemd-shim needs to run on... systemd?
<hallyn> slangasek: no, sysvinit
<slangasek> ah
<slangasek> no man, who cares about sysvinit :)
<stgraber> slangasek: no, he's asking if systemd-shim should be able to work without cgmanager by doing direct fs callss
<stgraber> *calls
<hallyn> right
<hallyn> smoser: digitalocean is very nice in some ways, but their archive mirrors/proxies seem to really mess things up sometimes.  pull-lp-source frequently does the wrong thing there.
 * hallyn uses pull-debian-source tow ork around that :)
<slangasek> hallyn: so in what sense does cgmanager rely on upstart, though?  Because actually, we do need systemd-shim to work in Debian on upgrade from wheezy to jessie
<slangasek> but I would expect that to be systemd-shim + cgmanager + sysvinit, not systemd-shim + internal cgroup allocation + sysvinit
<hallyn> slangasek: cgmanager doesn't depend on it, it's just that we only ever worked out the cgmanager-cgproxy interactions for upstart jobs
<hallyn> really, the sysv should be easier, as we'll just do one script to run either/both, probably
<stgraber> hallyn: sysvinit should be trivial, just use two pid files with a single init script launching both of them in the right conditions
<slangasek> ok
<stgraber> hallyn: systemd unit may be trickier but we don't have to care about that just yet
<hallyn> stgraber: yup
<hallyn> stgraber: all right well i guess i may have to talk to you about how to do the sysv after i get this bit done.  i'm just creating a clean git tree so i can properly track my changes now that i'm making progress
<stgraber> hallyn: might also be worth checking if dba didn't make an init script already (and if he did, whether it's correct and covers all the crazy cases we do with upstart)
<hallyn> stgraber: rmadison -u debian cgmanager doesnt' show any results
<stgraber> hallyn: looks like it's still in new
<stgraber> hallyn: no init script listed there so I guess he didn't write one
<hjd> Looks like a package rebuild would fix bug 1247219. How would one request that, create a merge proposal where only the changelog has been edited?
<ubottu> bug 1247219 in xaralx (Ubuntu) "XaraLX does not start" [High,Confirmed] https://launchpad.net/bugs/1247219
<dobey> hjd: yes
<hjd> dobey: Ok, great :) Slightly busy right now, but will create one later. Thanks.
<mdeslaur> cyphermox_: any idea why network-manager is failing the jenkins tests?
<rbasak> If a package is removed from testing in Debian due to an RC bug/CVE, will we sync that removal in any way in Utopic?
<rbasak> I presume not because I presume we're syncing from unstable?
<rbasak> This is https://packages.qa.debian.org/p/percona-xtrabackup.html, Debian bug 751377.
<ubottu> Debian bug 751377 in percona-xtrabackup "percona-xtrabackup: talks home without asking" [Grave,Open] http://bugs.debian.org/751377
<rbasak> Upstream say that they will have a fix soon, but will miss the Debian autoremoval deadline.
<rbasak> So I'd like to hold it in Utopic to give them time to give me a patch, if instead it would get removed.
<hallyn> pitti: stgraber: do i understand correctly that user@1000.service refers to systemd user jobs, akin to upstart user jobs?
<hallyn> (i.e. i should be able to ignore those)
<stgraber> I'll let pitti answer that one as I've got unfortunately no clue
<hallyn> ok . the three things i'm seeing are startunit for user-1000.slice, start-unit for user@1000.service, and starttransientunit for session-3.scope
<hallyn> (not yet found a definitive way to tie a transient unit to a uid, unfortunately, though a pid is passed so i guess i can always deduce it myself)
<infinity> rbasak: We don't follow testing autoremoval, no, as Debian may remove for reasons we don't need to (like incomplete transitions, etc).
<hallyn> oh maybe i should get that from the slice string
<cyphermox_> mdeslaur: no. it hasn't changed
<mdeslaur> hrm
<mdeslaur> weird...it's blocking dbus
<mdeslaur> and modemmanager
<barry> pitti: well, we might finally be making progress with the zope stack :)
<cyphermox_> mdeslaur: could the settings for ipv6 privacy extension have changed?
<mdeslaur> cyphermox_: oh, maybe...I seem to recall stgraber mentioning something about that
<cyphermox_> ah?
<cyphermox_> I know the way it displays in ip addr is different, but we already do account for that
<mdeslaur> someone wanted the default changed on server only...not sure what came of that discussion though
<cyphermox_> oh, right
<cyphermox_> yes, I remember. We do this testing on server
<rbasak> infinity: OK - thanks, that's useful for me in this case.
<cyphermox_> I'll look into it
<stgraber> I didn't do any change but it was indeed mentioned that maybe we would want to change that on servers
<cyphermox_> nah I think it's just a timing issue
<cyphermox_> the other test with IPv6 passed
<robru> kenvandine, hey, I got libfriends built in silo 17, can you help me test it?
<kenvandine> sure
<kenvandine> if i can remember what we can do to test :)
<kenvandine> oh, i guess friends-app is a good test
<robru> kenvandine, yeah, basically, just make sure it doesn't break the phone or the desktop real quick. it built ok, so that's a good start ;-)
<kenvandine> :)
<kenvandine> sure
<robru> kenvandine, thanks
<cyphermox_> mdeslaur: stgraber: I'm tempted to just remove that check in the tests, privacy extensions might not be enabled in the test environment, I'd rather write a new test later to check only privacy extensions
<cyphermox_> or you know, run stgraber's IPv6 tests, and get a clear picture of what's what
 * mdeslaur shrugs
<rbasak> cyphermox_: could you maybe have the test check the sysctl knob? Or have two tests, each with a skip if the sysctl knob is the wrong way?
<cyphermox_> rbasak: well, that test is doing wpa and dhclient... I think it's a good idea, but I'll come up with a test for just the IPv6 settings
<rbasak> cyphermox_: ah, OK
<cyphermox_> right now there's testing and retesting of the same things again and again in slightly different ways, in many scripts
<cyphermox_> we also check for the state of privacy extensions for the ipv6 tests with NM running, so it's still covered
<kenvandine> robru, libfriends looks good
<robru> kenvandine, sweet
#ubuntu-devel 2014-07-10
<hallyn> desrt: hey - do you know of any other sample code that would show how to deconstruct a dbus msg as gvariant which has a(sv)?  I don't seem able to pull it off successfully, and most tutorials seem to stick to 'as'
<hallyn> (i'm trying with http://paste.ubuntu.com/7772700/ )
 * hallyn suspects desrt is in a currently-asleep tz :)
<desrt> hallyn: a(sv) or a{sv}?
<hallyn> desrt: a(sv)
<desrt> weird!
<desrt> what is this?
<desrt> like, what data is in there?
<desrt> one does not typically see the a(sv) type....
<hallyn> desrt: it's the StartTransientUnit from systemd.  Each element of the array has s for the description, then v is just an s with the value
<hallyn> seemed rather silly to me, suppose it's meant to be future-proof
<desrt> typically you use a{sv} unless you really care about the order
<desrt> which is difficult to imagine in this situation...
<desrt> anyway... did you figure it out?
<hallyn>      "<arg name='properties' type='a(sv)' direction='in'/>"
<hallyn> nope
<hallyn> i mean i get a valid list, but the n_elements is always 0
<desrt> so what do you have there?
<desrt> you're implementing this inside the shim?
<hallyn> yeah
<hallyn> http://paste.ubuntu.com/7773201/
<desrt> so you have name mode properties aux
<hallyn> that's the chunk i'm using right now
<desrt> so typically you whack out all the parameters at once
<desrt> something like so:
<desrt> const gchar *name, *mode;  GVariantIter *properties, *aux;
<desrt> g_variant_get (parameters, "(&s&sa(sv)a(s(a(sv)))", &name, &mode, &properties, &aux);
<hallyn> then properties will be an iter?
<desrt> yes
<desrt>   while (g_variant_iter_loop(iter, "(s@v)", &str1, &v)) {
<desrt> this is weird
<hallyn> i dumped aux actually bc systemd in 208 wasn't yet sendin git
<desrt> if you do that then the "v" will contain a value of type 'v'
<desrt> you want only to have "(sv)" or even better "(&sv)" with a const gchar *str1
<hallyn> ok i'll try that, thx.  (stuff going on so will take a few mins)
<desrt> g_variant_iter_n_children() yuck
<desrt> i can't believe i let chpe convince me into adding that API :p
<desrt> i guess it helps in your case, at least...
<hallyn> introspection ftw :)
<hallyn> will i still need to use g_variant_iter_free?  i assume so
<desrt> yes
<desrt> it's not possible to use stack-allocated iter here because something needs to keep alive the value that you are iterating over
<desrt> which was itself only extracted from the parent
<hallyn> desrt: yay, i get contents, thanks!
<hallyn> desrt: and, yay, it has the info i need to connect the TransientUnit to the owner, so i should be able to do the proper cgroup config (tomorrow :)
<desrt> hallyn: i'll probably take a look over the dbus-specific parts of this patch and may clean them up a bit
<desrt> just make sure the cgroup stuff is solid... i don't know a thing about it, and i don't want to start learning :)
<hallyn> desrt: I get to the point where my nonexistant cgroup code says: cgmanager_create_all: called for /user/1000.user/c11.session
<hallyn> \o/
<desrt> btw: i'm going on vacation pretty much immediately after work on friday... i'll be gone for a week
<hallyn> desrt: so yeah, i'll hook in cgmanager code (which uses nih-dbus, boy thsi will be a beautiful frankenstein :), then toss you a git tree so you can sob at waht i've done and fix up the glib dbus parts :)
<hallyn> desrt: oh, hm.  well i'll try to get this done tomorrowmorning - at least enough for you to look at the glib-dbus part
<desrt> sure thing... otherwise, i guess no big deal if it takes an extra week?
<hallyn> desrt: well debian-devel is crying already, so it may be a big deeal to them :)
<desrt> okay
<desrt> what's your TZ, btw?
<hallyn> desrt: so yeah i'll toss you a git tree in the morning (in about 14 hours)
<hallyn> US central
<hallyn> its' 22:45 here
<desrt> cool.  toronto time here.
<hallyn> oh!  i thought you were in nl for some reason
<desrt> nope
<desrt> although toronto and amsterdam have a bit in common :)
<hallyn> oh?
<hallyn> not something i'd ever heard
<desrt> ya... just similar feel
<desrt> ultra-progressive, etc
<hallyn> nice - i only ever went into nl as a kid when we went shopping there (from be).  i need to go spend some time there
<hallyn> anyway!  tty i nthe morning, thx again for your help
<desrt> sleep well
<hallyn> desrt: well, i went ahead and pushed it to github.com/hallyn/systemd-shim #cgm.1
 * hallyn out
<pitti> Good morning
<pitti> infinity: did you happen to see the glibc autopkgtest failure? It fails to build on "../include/stap-probe.h:24:22: fatal error: sys/sdt.h: No such file or directory"
<pitti> infinity: obviously that didn't happen on the real buildds, do you have an idea why that could be?
<slangasek> pitti: Debian bug #748694?
<ubottu> Debian bug 748694 in systemtap "sys/sdt.h is architecture specific, and causing issues on unsupported architectures" [Serious,Fixed] http://bugs.debian.org/748694
<pitti> slangasek: ah, thanks; we don't seem to have that in Ubuntu yet (at least not in the changelog)
<pitti> https://launchpad.net/ubuntu/+source/systemtap/2.3-2ubuntu1 sounds related though
<pitti> but isn't, glibc just failed again
<infinity> pitti: It's entirely possible the 'fixes' broke glibc's build.  I can look tomorrow.
<pitti> oh, that way around
<pitti> infinity: thanks; not urgent, I was just wondering why it fails on this build but not the other
<pitti> infinity: it counts as "always failed" now, so doesn't block anything
<pitti> (due to the package rename)
<infinity> pitti: Oh, ugh.  Yeah, we should get it fixed at least once so it stops behaving that way.
<infinity> pitti: I'll look tomorrow after I knock off a few more urgent items.
<infinity> pitti: Test build started now, so I have something to play with in the morning.
 * infinity says, as it fails 5 seconds in...
<infinity> pitti: Oh, failure is obvious.
<infinity> pitti: Fix testbuilding, will upload in the morning if it's all good here.
<dholbach> good morning
<mvo_> @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: mvo_
<Noskcaj> mlankhorst, Has libxi had it's breaks long enough that we can sync again?
<mlankhorst> Noskcaj: sure, it was just needed until the lts
<mvo_> pitti: could you please apply http://paste.ubuntu.com/7775018/ to the pm-utils git repo its a trivial typo? reference is bug 1299975
<ubottu> bug 1299975 in pm-utils (Ubuntu) "wireless script checks wrong sys file" [Undecided,Confirmed] https://launchpad.net/bugs/1299975
<pitti> mvo_: will apply in Debian; I don't have upstream commit
<mvo_> pitti: ok, there is a debdiff in the bug if thats easier
<pitti> right, that's the one I'm looking at
<mvo_> pitti: ok, I will do a trusty SRU for that then and we get utopic via the next debian sync :)
<pitti> mvo_: thanks!
<mvo_> pitti: thank you! I assume forwarding this to upstream via their bts make sense (I assume they are responsive)?
<pitti> mvo_: no, it's been dead upstream for ages, so don't bother
<mvo_> pitti: ok, good to know
<pitti> mvo_: I think mbiebl_ has commit rights, but he can also pick them from the debian package
<pitti> mvo_: I'll add a DEP-3 header
<mvo_> pitti: \o/ thanks!
 * mvo_ writes the test case etc stuff in the meantime
<pitti> mvo_: I'll do a Debian upload now, so that it'll be fixed in utopic soon
<desrt> hallyn: why the conditionals?
<desrt> (in configure)
<pitti> mvo_: (done)
<mvo_> thanks pitti
<LocutusOfBorg1> wow! MoM seems broken again
<LocutusOfBorg1> cjwatson, ;)
<LocutusOfBorg1> sil2100, did you see upstream for lucene? they fixed the gtest stuff
<LocutusOfBorg1> I asked for a new release
<cjwatson> LocutusOfBorg1: sigh.  hopefully fixed
<hallyn> desrt: yeah i was undecided on that.  at first i was going to not have them and make it depend on cgmanager
<hallyn> i suppose i should do it that way
<hallyn> bc also supporting cgfs would be very complicating and not nearly as safe
<LocutusOfBorg1> cjwatson, thanks as usual :)
<LocutusOfBorg1> I would like to do some merge, can I send to somebody the debdiffs instead of opening a bug, wait for somebody and so on?
<LocutusOfBorg1> like gccxml, gambas3, wxwidg
<LocutusOfBorg1> they are all trivial to sync
<LocutusOfBorg1> s/sync/merge
<LocutusOfBorg1> curl
<cjwatson> wxwidgets3.0 can't be synced so I'm not sure I believe you :)
<cjwatson> Nor can gccxml
<cjwatson> Oh, merges, right, don't have time for that right now sorry ...
<cjwatson> Reviewing merges is generally harder work than just doing them
<cjwatson> LocutusOfBorg1: You should always talk to the person who uploaded the package last in the first instance, anyway; please don't just steal other people's merges
<LocutusOfBorg1> cjwatson, I mean wx2.8
<LocutusOfBorg1> not 3.0
<LocutusOfBorg1> and s/sync/merge
<LocutusOfBorg1> cjwatson, ok
<LocutusOfBorg1> just sometimes is bad to see ubuntu so much behind debian
<LocutusOfBorg1> I hope to see merges done when freeze approaches :)
<LocutusOfBorg1> I will offer my help again at that time :D
<cjwatson> LocutusOfBorg1: Like I say, help may be welcome but please talk to the people who touched it last rather than just firing diffs at people
<cjwatson> LocutusOfBorg1: Sometimes they're working on it, or sometimes there's a reason not to move forward that you're not aware of
<LocutusOfBorg1> yes of course
<cjwatson> Or sometimes it's just not important :)
<LocutusOfBorg1> I'm wondering about some programs like gambas
<LocutusOfBorg1> the rebuild against llvm 3.2 in debian failed on all archs because of a cmake problem
<LocutusOfBorg1> why the ubuntu rebuild did not fail? llvm 3.4 is in ubuntu since trusty
<LocutusOfBorg1> s/3.2/3.4
<LocutusOfBorg1> anyway not a problem :)
<mvo_> xnox: what is your opinion about lp:~zctgbhu/plymouth/bug-1339954 ? it seems for Chinese we need a better font than the current dejavu and the suggested fonts-droid would add 4.4mb uncompressed into the initrd
<popey> xnox: is lp:~ubuntu-mate-dev/ubiquity/ubiquity-marco sane enough for merging to our ubiquity?
<hallyn> slangasek: stgraber: infinity: do i recall correctly y'all said the tp x240 kbd sucks?
<xnox> popey: need to test and merge. Can't remember if it's safe to set keys which are not universal in all flavours.
<stgraber> hallyn: I'm not so concerned by the keyboard as it's mostly similar to the x230 except for the lack of an insert key. The one with the terrible keyboard is the X1 carbon.
<stgraber> hallyn: the main problem I've got with the x240 is the very low amount of RAM and no possible upgrade there. You either get 4GB or 8GB, that's it.
<hallyn> stgraber: ah, ok.  x240 has much longer batt life and is slightly cheaper, so it's catching my eye right now
<xnox> mvo_: i'd rather include it conditionally. We are including ubuntu font i think, is that pretty in chinese or not?
<hallyn> (though i do like thinness.  i'm vain)
<hallyn> i'm used to netbooks, so 8G will suffice if i' not spending too much
<stgraber> hallyn: so far, the least sucky haswell range thinkpad I'm aware of is the t440s which is a bit bigger (14" instead of 12.6") but comes with a keyboard with an insert key and has one so-dimm slot so you can upgrade it to 12GB if you want to.
<hallyn> but that display resolution!
<hallyn> hm, yeah.  i *do* need an insert key
<hallyn> t440.  will look, thx
<stgraber> hallyn: also, the x240 isn't so cheap once you switch to a reasonable screen, IIRC the low price is with the 1366x768 non-IPS display. It's an extra $150 for 1366x768 IPS or an extra $300 for 1920x1080 IPS display.
<hallyn> waht is that like 12lb?
<hallyn> t440 also has the low-res though.  sad
<stgraber> t440s is around 3.5lbs I believe, surprisingly light when I was checking out wgrant's at the last sprint
<stgraber> hallyn: note, there's a big difference in quality between the t440 and t440s, so make sure you look at the latter
<hallyn> wgrant: any experience to tell me whether t440 screen is reasonable outdoors?
<hallyn> stgraber: ok
<stgraber> hallyn: also, when offered, take the IPS screen option, otherwise you get a TN display and those usually look bad. If the IPS is similar to that on my x230, you can read it fine outside, it's pretty bright.
<hallyn> 3 cell battery?  is that a joke?
<pitti> ev_, bdmurray: do you still remember why ubuntu-bug needs to check /etc/apport/autoreport and exec whoopsie-upload-all if it exists?
<stgraber> hallyn: no, there are two 3 cell batteries
<hallyn> stgraber: wrote that down, thx
<hallyn> oh, ok :)
<pitti> ev_, bdmurray: cause that doesn't make sense at all when you try and actually use it (bug 1339663)
<ubottu> bug 1339663 in apport (Ubuntu) "ubuntu-bug fails with "whoopsie-upload-all: error: unrecognized arguments" when /var/lib/apport/autoreport exists" [Medium,Triaged] https://launchpad.net/bugs/1339663
<stgraber> hallyn: so you can swap one while you are on battery if needed
<hallyn> so hopefully at least 5 hrs batt lfie
<pitti> ev_, bdmurray: this completely breaks reporting bugs, and crashes should be uploaded automatically anyway; at most, ubuntu-bug could check if /etc/apport/autoreport is on and then point that out instead of processing a .crash file
<pitti> (that's a bit hackish though)
<stgraber> hallyn: it's got a front 3cell battery and a back battery that can be 3 or 6 cell. Haswell should be better at power management than Ivy Bridge and my x230 (ivy bridge) with a 9-cell battery lasts 7-8 hours on wifi (like at sprints) and up to 12 without wifi (when traveling)
<pitti> ev_, bdmurray: oh, that's for adding the extra apport info to .crash files and creating the whoopsie stamp
<stgraber> hallyn: oh, and not sure if that matters to you, but all the new thinkpads no longer have physical mouse buttons, so if you were used to the trackpoint + physical mouse buttons with the touchpad disabled, it's going to be a bit trickier...
<pitti> ev_, bdmurray: but that's a totally different operation than reporting a bug or uploading a single .crash file, so I think if you want to do that you shoudl just call whopsie-upload-all?
<pitti> (or we even cron that)
<hallyn> stgraber: it'll annoy me, but every laptop is a compromise these days
<hallyn> stgraber: so with 9 cell batt and IPS display i'm around $1300.  compared to $300 for chromebook.  but much nicer, and hopefully useful otuside.  will think a bit.  thanks :)
<hallyn> maybe is hould buy a used x230 :)
<stgraber> hallyn: yeah... I need to change laptop by October and so far I'm pretty disappointed, they all suck in different ways...
<stgraber> hallyn: that's what slangasek ended up doing earlier this year :)
<stgraber> hallyn: well, not used, but an x230 rather than current gen thinkpad
<hallyn> "need to change by october" ?
<hallyn> heh, amazon still sells x230
<stgraber> hallyn: yeah, a family member already bought my current laptop and we agreed I'd give it to her in October ;)
<mvo_> xnox: apparently not, eog https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/1339954/+attachment/4149207/+files/UK14.04 show some missing chars
<ubottu> Ubuntu bug 1339954 in plymouth (Ubuntu) "Unable to display Chinese in Plymouth-lable" [Undecided,New]
<hallyn> stgraber: lol
<stgraber> hallyn: I've not ruled out buying another x230 though, I'd like to have an haswell laptop, but I also would really like to keep trackpoint with physical mouse buttons...
<hallyn> course i don't use mouse all that much, and could get a mini-mouse for when i need it, i guess
<hallyn> stgraber: would the default x230 screen compare to the IPS screen on t440s i wonder
<stgraber> hallyn: the only downside of the x230 is that you can only find it with the 1366x768 IPS display, the variant with the 1920x1080 IPS display is pretty much impossible to find. So it's a bit lowres (like most laptops...) but the display quality is very good.
<hallyn> again, especially for outdoors
<hallyn> ok - i care more about visibility outdoors than i do resolution
<mvo_> @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:
<stgraber> right, so I believe the x230 was only sold with IPS, so then that's the same I've got here which is pretty bright and fine outdoors
<hallyn> hm, nice
<stgraber> I once had some problem reading it in direct sunlight but that day was very very bright, it was the early afternoon, no shade whatsoever, the laptop got pretty hot and I got sunburnt, so that may have been a sign that I shouldn't have been staying there :)
<hallyn> but being stubborn you stayed out an extra 30 mins just to tell the sun off :)
<stgraber> well, I ended up staying there for maybe 2 hours, my dark terminals were a problem to read but firefox (or anything with a bright background) was fine
<barry> mdeslaur: do you have any particular interest in merging file 5.19 from debian to fix LP: #1340212 ?  i ask since you did the last merge.
<ubottu> Launchpad bug 1340212 in file (Ubuntu) "file 5.18 incorrectly identifies mime type of zip files" [Undecided,New] https://launchpad.net/bugs/1340212
<mdeslaur> barry: I was just looking at file security updates. Are you volunteering?
<mdeslaur> :)
<mdeslaur> barry: else, yes, I will do 5.19
<barry> mdeslaur: well, it's moderately blocking me, but i think i can work around it :)
<barry> mdeslaur: but hey, that sounds like you volunteer :)
<mdeslaur> barry: hehe, I'll do it this afternoon
<barry> mdeslaur: awesome, thanks
<slangasek> hallyn: yes, the x240 keyboard sucks :)
<stgraber> slangasek: not nearly as much as the new X1 carbon's (not sure if you ever saw that one, it's the weird one with split keys and where they shuffled stuff around quite a bit too just for fun)
<ev_> pitti: that sounds reasonable to me, but I think bdmurray wrote that code, so let's see what he thinks.
<ev_> all I care about is that the phones automatically send crash reports
<ev_> not that ubuntu-bug does anything fancy :)
<pitti> ev_: you wrote the initial one in apport-bug with the apport-noui backend, but that behaved much more like the others; whoopsie-upload-all doesn't do at all
<pitti> ev_: I'm not sure what /etc/apport/autoreport should mean -- i. e. automatically upload all crashes unreviewed, or something else
<pitti> if so, it should have something like a cron job which calls whoopsie-upload-all if that flag exists
<ev_> oops :)
<ev_> autoreport should mean automatically send all crashes
<ev_> there's no reviewing on the phone
<ev_> you either send them or you don't
<pitti> if it has another semantics which involves ack'ing crashes by the user, then we need some interactivity and ubuntu-bug integration
<pitti> ok, thanksk
<pitti> so that means that it doesn't really belong into ubuntu-bug, which you have to call manually (and then for different reasons)
<ev_> yeah, indeed
<ev_> I don't know why I did it, but I admit it was wrong
<ev_> and apologies to bdmurray for thinking it was his code
<pitti> ev_: well, it was quite right back then with apport-noui
<pitti> it just got mashed up with moving to whoopsie-upload-all in r2686
<ev_> oh
<ev_> yay, not a complete muppet
<pitti> ev_: ok, so ISTM that we should kick that out of ubuntu-bug, and we instead need a cron job/upstart hook/whoopsie integration/etc. to call w-u-all if that flag exists?
<pitti> cron runs on the phone, so in theory we could just use that
<ev_> isn't that what the apport-noui job does?
<pitti> oh!
<pitti> ev_: yes, that very
<ev_> :)
<pitti> ev_: so that fix is simple then: remove 4 lines of shell, done :)
<ev_> high five!
<pitti> ev_: thanks for the heads-up, wanted to make sure I understand how these bits are working
<ev_> if only our jobs were always so easy
<pitti> delete code, upload, drink beer
<ev_> I'm just going to sit around and delete code all day
<pitti> (and watch soccer)
<ev_> lol
<ev_> you forget that there are ou's in my words now. You can safely call it football around me. ;)
<pitti> but after next Sunday, that madness is over at least
 * pitti hugs ev_
<ev_> :D
<bdmurray> pitti: I don't think cron runs on the phone
<pitti> bdmurray: it does (I just checked), but that file-triggered apport-noui.conf upstart job is better indeed
<pitti> bdmurray: so it's all good now
<bdmurray> pitti: okay, while you are here I noticed a call to apt.apt_pkg.SourceRecords() in backends/packaging-apt-dpkg.py and it seems to me that isn't in the sandbox cache
<bdmurray> pitti: so if source package contents change between releases there will be an issue
<pitti> bdmurray: oh, you mean that doesn't use the rootdir= ?
<pitti> ouch, yes
<bdmurray> it looks to me like SourceRecords doesn't take any arguments
<bdmurray> so we can't pass the cache
<pitti> mvo_: is there some way of getting the SourceRecords from an apt.Cache(rootdir=) object, isntead of apt.apt_pkg.SourceRecords()?
<hallyn> stgraber: heh, i think both gaughen and rharper have the x1, it *looks* sleek from a distance
<gaughen> hallyn, yes I have the x1 carbon. I love it.
<mvo_> pitti: it should setup all the config so that happens automatically after you create the binary cache, is that not the case for you?
<gaughen> hallyn, and we know people who could get us corporate discounts on said laptop
<pitti> mvo_: I haven't tried myself, bdmurray just pointed it out
<pitti> mvo_: ah, so the intent is that once you instantiate a Cache(rootdir=), everything else uses that config?
<hallyn> gaughen: oh, they could do same on a t440s?
<hallyn> who are these mythical creatures?  (msot ppl i knew have fled :)
<gaughen> hallyn,  I still have people. let me know and I shall get you a serial #
<gaughen> hallyn, Nivedita for one
<mvo_> pitti: yeah
<pitti> mvo_: ok, thanks
<pitti> bdmurray: did you actually see that  break?
<mvo_> pitti: it should be this way, if not, please let me know
<pitti> mvo_: danke
<mvo_> yw
<hallyn> gaughen: can i also use that for hotel discount?  :-)
<hallyn> gaughen: ok i may have to take you up on that!  i really need a new laptop
 * hallyn hopes smoser will keep his mouth shut
<gaughen> hallyn, I have just gone around with confidence and pretended I deserve the corporate rate and it has worked
<bdmurray> pitti: I thought it might be the cause of bug 1336062
<ubottu> bug 1336062 in apport (Ubuntu) "apport-retrace on precise confused by source package name changing" [Undecided,New] https://launchpad.net/bugs/1336062
<pitti> bdmurray: ok, thanks; I opened that in a tab, will look at it
<pitti> just need to run out for a bit now
<mvo_> bdmurray: in a meeting right now, I check once its finished
<mdeslaur> barry: merged and uploaded
<barry> mdeslaur: you rock, thanks
<hallyn> stgraber: for systemd-shim.  i want to depend on apiversion >= 5, so the shim can just use controller "all" instead of enumerating the controllers.  Trusty doesn't yet have that version.  Preference?
<hallyn> should I SRU apiversion 5, or have extra code ins ystems-shim to list all the controlelrs?
<stgraber> hallyn: we don't need systemd-shim for trusty do we?
<hallyn> stgraber: good point
<hallyn> feh.  wishing i had done remove_on_empty for group controllers
<hallyn> stgraber: yay, shim is putting me into cgroups
<stgraber> nice!
<hallyn> would be nice if they sometimes got removed (i'
<hallyn> m on c27.session now :)
<hallyn> if i could only remember why i decided not to do autremove for "all" controllers
<hallyn> really can't think of a good rason.  'get_value' and 'set_value' make sense
 * hallyn goes to think about it
<hallyn> all right i'll just implement it then <shrug>
<hallyn> and, yay, we have autoremove.
<hallyn> desrt: let me wrap this up into a clean commit and push it to git so you can yell at m^W^W^Wreview
<desrt> :)
<hallyn> desrt: github.com/hallyn/systemd-shim cgm.1   (to work it requires an update to cgmanager which i'll push shortly)
<hallyn> desrt: and apologies for dumping this so late when i know you're leaving in a few hours
<desrt> hallyn: i'm still here until tomorrow
<hallyn> oh!  i thought you were out tomorrow :)  ok then i can relax a bit :)
<hallyn> all right, going out for a walk, bbl
<desrt> hallyn: i notice you still take a conditional depend on the cgroups stuff...
<desrt> +AM_CONDITIONAL([ENABLE_CGMANAGER], [test "x$enable_cgmanager" = "xyes"])
<desrt> ...even if you never actually use the conditional
<desrt> i guess i'd be happier if you just took the pkg-config depend like usual
<hallyn> desrt: do i ?  i thought i removed that
<hallyn> oh huh
<desrt> also: your inclusion of nih/nih-dbus/dbus is not required
<hallyn> why?
<desrt> the pkg-config on libcgmanager will pull them in automatically
<desrt> oh.  you copy-paste a big chunk of code here that actually uses this stuff.....
<desrt> i thought you were only going to make calls to libcgmanager...
<hallyn> desrt: ok, i pushed the trivial drop of that AM_CONDITIONAL;
<desrt> i'd definitely prefer that you rewrite this rather small use of nih dbus into gdbus
<hallyn> no, i'm using the autogenerated cgmanager-client library code
<desrt> but i guess i can do that for you
<hallyn> desrt: that would *rock*
<hallyn> pretty sure that woudl take me days
<desrt> okay
<desrt> i'll look into that this afternoon
<desrt> just send me the cgmanager update....
<hallyn> desrt: but let me say in favor of keepign it as is, that it then uses the same client library code that upstart, lxc, and the older logind are using
<hallyn> desrt: cgmanager update is building in utopic
<hallyn> (and is applied in git://github.com/cgmangaer/cgmanager)
<desrt> ah.  nice.
<desrt> so the issue is that cgmanager_get_api_version_sync() wants to take a nih dbus connection?
<desrt> a proxy, i guess, rather...
<desrt> this is some very bad API :(
<hallyn> desrt: well you should be able to just get the API version using dbus without a proxy - you can do it with dbus-send
<hallyn> desrt: the API is designed to do things that simple dbus cannot :)
<desrt> so this entire client library is just codegen'd dbus client calls?
<hallyn> desrt: in particular, if you want to weep, look at how the *_scm work
<desrt> i notice "scm" does not appear in your patch
<hallyn> desrt: yes.  which uses half of the acutal dbus calls
<hallyn> right
<desrt> so will you depend on the non-dbus-call parts of the library?
<desrt> or could i just rewrite it all to straight dbus calls?
<hallyn> not from systemd-shim, no.
<hallyn> go for it
<desrt> k.  i prefer to do that, then
<hallyn> wait, hm.
<hallyn> trying to think if you need to pass any fds...  but i guess not, no. so yeah that should be fine
<desrt> gdbus does fd passing just fine...
<hallyn> (yea but not SCM passing :)
<hallyn> yeah but the issue i had was that if you didn't FORCE fd passing early enough, the call woudl fail
<hallyn> but i don't think that is an issue here
<desrt> so are we on the same page?  i rewrite everything in straight-up dbus and drop the nih/libcgmanager deps?
<hallyn> desrt: yup
<desrt> cool.
<hallyn> desrt: thanks!
<desrt> hopefully i can have that for you by tomorrow morning
<hallyn> perhaps in the meantime i should be looking at cgmanager for debian,
<hallyn> slangasek: ^  we're just about there
<hallyn> stgraber: I'm going for that walk now, but may have some sysv questions for you when i get back
<stgraber> hallyn: do we care about scm from systemd-shim? I mean we should only talk to either the host cgmanager or to a proxy, never to host cgmanager directly from a container
<stgraber> hallyn: so in theory it's all standard dbus, none of our weird fd + creds fancy thing
<hallyn> stgraber: right,
<hallyn> stgraber: i was just defending the "that's bad API" :)
<hallyn> but we dont' need that at all for systemd-shim
<slangasek> hallyn: just about where? :)
<hallyn> slangasek: i've got systemd-shim doing cgroup setup for me
<slangasek> sweet
<hallyn> (well, cgroup creation and putting me in it;  not configuration of cpusets and such)
<hallyn> slangasek: do we really only care about this with upstart, or do we care about sysv people?
<slangasek> hallyn: well, as I figured out yesterday only after you ask, we do care in Debian about it for sysv because of the wheezy->jessie upgrade case
<slangasek> hallyn: but it's also ok to say "here's the code, Debian, please wire up the sysvinit scripts"
<hallyn> slangasek: ok thanks.  (the stuff's not un-subtle wrt starting up proxy and manager, so may be better to provide the scripts)
 * hallyn out
<hallyn> (well, back later, of course)
<rharper> stgraber: I really enjoy my x1, but it's the older model with dedicated mouse buttons.  the new keyboard is rather strange; not sure if I could adapt to that one.
<stgraber> right, the older x1 was pretty nice, it's the new one that's just weird :)
<mhall119> stgraber: I send an email to the DMB that's stuck in moderation, can you let that through?
<stgraber> mhall119: sure
<mhall119> thanks
<bdmurray> pitti: I've noticed that libmirclientplatform-android-dbgsym is missing from Packages for main and universe on ddebs.ubuntu.com but the package is there
<bdmurray> pitti: Could you look into that?
<mhall119> stgraber: got another one in moderation
<stgraber> mhall119: processed
<mhall119> thanks again
<nxvl> doko: is there a roadmap for what's missing for replacing python2 with python3?
<nxvl> doko: or, who can i talk to to help on this?
<nxvl> barry: ^^
<barry> nxvl: that's a pretty general question :)  can you narrow that down a bit?
<nxvl> what's the work that needs to be done to get rid of python2, and get python3 by default
<nxvl> i want to help getting that done
<nxvl> and see python3 in 14.10
<nxvl> so, basically, what can i do to help?
<jtaylor> what do you mean with by default?
<jtaylor> it already is default on the iso or?
<barry> jtaylor: not for desktop
<jtaylor> oh, whats missing?
<nxvl> jtaylor: according to https://wiki.ubuntu.com/Python/3 it's not
<slangasek> it is "the default" :)
<barry> one thing to start with is to review https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AiT4gOXSkmapdGdFejk0MjFydUlNMDVoMXNRdGdkbFE&pli=1#gid=0
<barry> to see if that's still accurate
<barry> another thing is to work on getting python3 as default in debian, which is blocked on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732644
<ubottu> Debian bug 732644 in python-debianbts "python-debianbts: Port to Python 3" [Normal,Open]
<barry> it's been a few months since i reviewed status, but it should be true today that python2 is banished from touch, removed from default server iso or very nearly so, and still has a ways to go on desktop (hopefully not too far, but there may be big blockers)
<nxvl> who might know better?
<barry> nxvl: nobody ;)
<nxvl> ohhh, it's good to be back :D
<barry> nxvl: it's just a matter of continually reviewing status and updating the relevant docs, etc.  things change quickly!  e.g. i have been uploading a *ton* of stuff to debian and syncing to ubuntu to improve py3 library support where upstream supports it
<barry> nxvl: good to have you back, and really glad you want to help!
<nxvl> ok, i'll review the doc and update it
<barry> nxvl: cool, thanks.  e.g. it would be good to know what the current state of upstream twisted is.  i haven't seen any announcements, but that doesn't mean stuff isn't available
<barry> now
<barry> nxvl: e.g.x2: i'm hoping that once zope.untrustedpython clears new and lands, that will unblock a bunch of the ztk stack from proposed
<barry> (dep8 tests are all passing for me locally, but depend on python-zope.untrustedpython which was split out from the zope.security source package & upstream)
<barry> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
<nxvl> just reading "update excuses" on the url makes me not want to open the link
<nxvl> :P
<barry> :)
<nxvl> (did i already mention how i missed this open source chaos?)
<barry> nxvl: how's the real world? :)
<nxvl> barry: booooooooooring
<bdmurray> wgrant: Would you have any idea about Packages files being incomplete on ddebs.ubuntu.com?
<jtaylor> is it just my system or does valgrind not have a apport exception for segfaults?
<jtaylor> everytime my app crashes as expected in valgrind the ubuntu bug reporter pops up :(
<hallyn> stgraber: thanks for the help with sysv scripts.  Not yet tested, but I' pushed what I have to github.com/hallyn/cgmanager initscripts.1 .  bbl
<bdmurray> pitti: I've submitted a merge proposal for bug 1336062
<ubottu> bug 1336062 in apport (Ubuntu) "apport-retrace uses system package lists which may return a different source package for a binary" [High,In progress] https://launchpad.net/bugs/1336062
<wgrant> bdmurray: Afraid not, that's all pitti AFAIK.
<bdmurray> wgrant: okay, slangasek thought you might have an idea
<wgrant> hallyn: My T440s has the 1080p touch screen because it was cheaper than the non-touch version, and it's a bit glossy but still very usable outside. AIUI the non-touch version is matte. It's by no means a classic ThinkPad, but it's very good and still the best option AFAIK.
<hallyn> wgrant: matte should be easier to read outside ?
<wgrant> hallyn: Right.
<hallyn> k :)
<wgrant> The screen is lovely, the keyboard is great except for the lack of dedicated media buttons and the weird Print Screen location, and the touchpad/trackpoint aren't as bad as I initially thought, very usable once correctly configured.
<hallyn> wgrant: which batteries do you have?
<hallyn> i think i'm sold, tbh
<wgrant> hallyn: I have the external 3-cell and 6-cell. I normally run with the 3-cell, as the 6-cell is fairly hefty.
<hallyn> will probably get an ssd and memory on amazon as stgraber had suggested
<wgrant> But nothing compared to the old 9-cell that sticks out the back.
<wgrant> Yeah, I stuck an 8GiB SODIMM in mine as soon as I got it.
<hallyn> wgrant: so you bought both? i may get3 cell in back and both 3 and 6 cell for back
<hallyn> wgrant: for the lazy and disaster-prone, do you have the model # somewhere for the simm you got? :)
<wgrant> halfie: Afraid not, but I think it was Crucial.
<wgrant> Opening the case can be a bit challenging. Make sure you watch the videos and have some plastic phone opening tools around.
<hallyn> can't be worse than the vostro i recently did surgery on :)
<hallyn> thanks wgrant.
<desrt> hallyn: hey... what's the purpose of all this work?
<desrt> you said it's so debian can land the new systemd version, right?
<hallyn> desrt: right
<desrt> but aren't they also landing systemd-as-pid-1?
<desrt> or do they keep some sysv backcompat option for the time being?
<hallyn> desrt: slangasek says we promised to provide what is needed for running upstart
<hallyn> yes, i think so
<desrt> so i'm helping people to run upstart on debian?
<desrt> how perverse :)
<hallyn> desrt: perverse?  what is your preference i wonder? :)
<desrt> i can state it in two non-words: systemd asap
<hallyn> but also sysv
<desrt> i wonder how we ended up holding this particular bag...
<desrt> seems like the systemd advocates should have had to do the work there......
<hallyn> side effect of arguments and promises made during the debian vote
<desrt> ...which we lost :/
<hallyn> yup
<desrt> i won't pretend to understand :)
<hallyn> but you prefer systemd anyway
<desrt> ya.... i'm just wondering how we lose the right _and_ have to do the extra work :p
<hallyn> desrt: bc we're good folks and we want to support people who still want choice
<hallyn> hm, my debian sid system doesn't want to mount a memory cgroup.  what on earth...
<desrt> that strikes me as a good enough reason
<desrt> hallyn: sure it's not mounted anywhere else?
<hallyn> yup
<hallyn> custom kernel courtesy of rackspace, maybe it's wonky
<desrt> hallyn: so far you only use create_all and remove_all... i guess you will expand this soonish?
<hallyn> desrt: create_all also moves the tasks in there.  But yes, the intent is to also respond to requests to set memory and cpu limits
<hallyn> if that's what you mean
<desrt> i don't really grok how all of this works... but do you have a race here?
<desrt> specifically, what if some process fork() after you collect unit->pid but before you cgm_enter() the list of pids?
<hallyn> desrt: logind won't do that
<hallyn> what you describe is a race in how libcgroup does it (bc it detects 'firefox is running', grabs the pid, and reclassifies it - which can't be done in non-racy wya.  which is why libcgroup is dead)
<hallyn> but logind will take the pids, ask us to setup, and only after that proceed to let the user login
<hallyn> i'm processing the 'array of pids' but it is always only one pid,
<hallyn> for ssh it's the root-owned sshd which becomes parent of the user's sshd and shell
<desrt> the use of a(sv) here is really deeply annoying.... prevents use of all of the nice convenient APIs we have :(
<hallyn> in the StartTransientUnit you mean?
<desrt> btw: for types like "au" we have g_variant_get_fixed_array() that returns a guint*
<desrt> ya...
<desrt> this is a very strange dbus api...
<hallyn> well it only gets worse :)
<hallyn> in later systemd we'll have to add the processing of the
<hallyn> 'aux'
<desrt> another btw: g_object_new() doesn't fail
<hallyn> oh, good :)
<desrt> another minor btw: doing initialisation of the object after g_object_new() returns is considered bad form
<hallyn> stgraber: have you ever seen /proc/cgroups have 'num_cgroups 0' ?
<hallyn> http://paste.ubuntu.com/7777549/
<hallyn> i think i'll just have to try elsewhere bc ihave no idea what's going on
<desrt> another: g_free() on a GObject is a no-no :)
<Unit193> hallyn: "with 204-14 being the first version where libpam-systemd will pull in systemd-sysv , I figured a few more days to wait to see how the dust settles wouldn't be so bad"  So will this by chance be completed soon enough for the Debian changes?
<hallyn> Unit193: i'm hoping so
<Unit193> hallyn: Great, if you happen to be on OFTC, heads up in -systemd might be handy, no?
 * Unit193 goes back to lurking now. :)
<hallyn> Unit193: debian-systemd?
<Unit193> Mhm.
<hallyn> or just #systemd?
<Unit193> 10:OFTC/#debian-systemd
<Unit193> hallyn: Thanks and sorry for the bother. :)
<hallyn> Unit193: thx for the pointer
<Unit193> Sure.
<Unit193> hallyn: I have 213 in a utopic VM, I presume there's no testing I can help with?
<hallyn> Unit193: I suspect 213 will need  a 1-line patch to the systemd-shim patch actually
 * desrt is mid-rewrite :)
<hallyn> desrt: look at systemd.git commit 86b8d289717bad2800342efca0a5023aa8374e9c
<hallyn> adds 3 lines which do
<hallyn> +        r = sd_bus_message_append(m, "a(sa(sv))", 0);
<hallyn> +        if (r < 0)
<hallyn> +                return r;
<hallyn> adding something which the listener didnt' want anyway
<hallyn> ok this is a general debian thing.  any sid image, i can't mount memory cgroup.  'mount -t cgroup cgroup /mnt' mounts everythign but memory.  what on earth?
<hallyn> huh, GRUB_CMDLINE_LINUX="cgroup_enable=memory swapaccount=1"
<hallyn>  helped
<desrt> cgroups!  what do they do?  why are they here?  have i lost my mind?!
<desrt> nobody knows...
#ubuntu-devel 2014-07-11
<hallyn> desrt: they're like the NSA, they track you
<desrt> ya... i get the general gist of the thing... but i have no idea why it has to be so complicated
<desrt> with different cgroups for all different things plus this pseudofs to track it all...
<stgraber> hallyn: you mean enabled == 0 right? the paste you gave me shows num_cgroups == 1 for all of them
<hallyn> yeah
<hallyn> desrt: ack
<hallyn> stgraber: http://paste.ubuntu.com/7778221/   if a package installs real init and upstart scripts, upstart will DTRT and ignore the sysv scripts, rigth?  (seems to be working here)  I usually see sysvinit *wrapper*s cripts and had expected the package to only install the upstart scripts...
<hallyn> but I guess qemu-system-x86 also has a real sysv script, so must be ok
<hallyn> anyway i'm thinking of pushing that to utopic so if you see any problems with that pls shout
<desrt> hallyn: one more big btw: g_error() terminates the calling process :)
<desrt> it's quite strange to see free() calls after this :)
<stgraber> hallyn: yes, it'll do the right thing
<hallyn> cool, thx, will probabablyh push to utopic tonight then
<hallyn> desrt: wtf?  g_critical terminating the process makes sense.  g_error?  it's just an error...  so waht's the recommended way to just log something?
<hallyn> all tests still pass both on host and in container.  pushing
<desrt> hallyn: g_warning
<desrt> hallyn: btw... UserUnit has slice_path (char*), which it passes to cgmanager_create_all, which is expecting a ScopeUnit*
<hallyn> desrt: i could be mixing the terms up in my head, but i swear when i looked at a gnome page this morning it said g_critical and g_warning could both end the program
<desrt> that's obviously not right... but it's also not clear what is the correct thing to do here
<desrt> hallyn: they can, but typically don't
<hallyn> hm, that sounds like something i fixed this morning
<desrt> you can set G_DEBUG=fatal-criticals or fatal-warnings
<hallyn> (the ScopeUnit pasing)
 * hallyn checks
<desrt> but in general: g_error > g_critical > g_warning > g_message > d_debug
<desrt> g_error = fatal, always
<desrt> g_critical = you made a programmer error and it's somewhat likely that your internal state was compromised
<desrt> g_warning = something bad happened, but it may not have been the programmer's fault
<hallyn> desrt: oh, the .h file doesnt' match the .c, that's all :)
<desrt> g_message = fyi
<hallyn> i had updated cgmanager.c and scope-unit.c
<desrt> hallyn: awesome...
<hallyn> i wont' fix it now since i assume you ahve a buttload of other fixes
<desrt> scope-unit has the wrong code, though....
<hallyn> and wouldnt' want to merge those
<hallyn> why?
<hallyn>   cgmanager_create_all(pu);
<desrt> sorry... user-unit
<desrt> my eyes are starting to cross from the scope/service/slice terms :)
<hallyn> oh.  feh.
<desrt> most importantly: what pids would i pass here?
<desrt> none?
<hallyn> in cgmanager_create_all?
<desrt> yes
<desrt> this API looks a bit different now...
<hallyn> the pids which we pulled out of the StartTransientUnit msg, i.e. what logind sent us
<hallyn> came as a a(sv) where v was a ai
<hallyn> uh, au
<hallyn> each u is a pid to be moved;  but again there's only ever 1 afaict
<desrt> okay
<desrt> so the properties handling should be done for both types of units, then
<desrt> right now you're only doing it for the one...
<hallyn> regarding naming - blah i completely agree, i was trying ot make sense of the names being used by systemd, but still don't fully understand
<hallyn> i guess a scope limits all of a user's sessions;
<hallyn> a session describes a sesssion, and there' sa slice for each session;  a service is i think something that doesn't make sense for non-systemd to do
<hallyn> right, i'm doing it for the one pid
<hallyn> so, the user-unit proably should just do something different, or nothing at all
<hallyn> it depends on whether a scope will soemtimes come with a slice;  if so, then we'll need another function in cgmanager.c to create the cgroups for it (and pass it the UserUnit)
<desrt> fwiw, here's how things are shaping up: http://ur1.ca/hq27o
<desrt> i'm not exactly sure how you want the error handling to look here....
<desrt> like, if we fail to move one pid, do we fail the entire operation?
<desrt> do we try to do back-out?
<desrt> or do we just assume that the rest will be OK and continue?
<hallyn> i think we log and continue
<hallyn> then at least user has a chance to see that something went wrong
<desrt> k.  that's what i'm doing.
<desrt> it also speeds things up: we can issue all the async calls pipelined
<desrt> no need to wait for the replies
<hallyn> cool
<hallyn> where are you intending to open the connection to cgmanager?  around each create_all/remove_all?
<desrt> no.  only once ever.
<hallyn> (actually we should probably just drop remove_all)
<desrt> i store it in a static
<hallyn> if cgmanger restarts, will the connection auto-reestablish?
<desrt> see the (buggy) 'initialised' code
<desrt> no.
<desrt> that can probably be fixed
<desrt> but it raises an interesting question: what if we try to connect to it for the first time while it is mid-restart?
<hallyn> oh, i see now, i glossed over the _call before
<desrt> should we keep trying each time we get a new request and spam on g_warning() each time?
<desrt> the idea that this thing could restart under us is slightly horrifying....
 * desrt <- hates races, no matter how theoretical
<hallyn> true.  if it were going to stick aroudn longer term we might consider re-exec upstart-style
<hallyn> but i do hope cgmanger becomes a relic soon.  meaning systemd starts to offer what we need.
<desrt> well the good news is that systemd-shim auto-exits...
<hallyn> oh, to answer, yeah;  i thin krestart and spam warnings
<hallyn> nothing wrong with spam warnings, if bad things are in fact happening
<hallyn> auto-exits?
<desrt> ya
<desrt> after a period of inactivity
<desrt> it's stateless
<desrt> so why hang around?
<hallyn> oh, good.  and how the heck does it get started!
<desrt> dbus activation
<hallyn> i think you mean, magic
<desrt> :)
<desrt> dbus activation is really very nice.... arguably the best part about dbus, in fact
<desrt> you just send a message to the service...
<desrt> if it's there... great
<desrt> if not -- it will be :)
<desrt> and it's all race-free
<sarnold> ahhh, memories of inetd <3
<desrt> ya.  more or less...
<hallyn> you say race-free,
<desrt> well, actually
<desrt> there's one teensy tiny race
<desrt> but i'm the only one who ever noticed it.....
<desrt> and nobody else seems to care
<hallyn> i say 'threading with nih-dbus seems to break'
<desrt> but it is fixed with kdbus, at least
<desrt> libdus-1 is a single-thread library as far as i'm concerned...
<desrt> there are some nominal attempts at thread safety inside of it, but they didn't make it far enough .... and no real testing
<hallyn> yeah, i read some of the history on it :(
<desrt> gdbus on the other hand is a multithread monster
<desrt> this is some seriously awesome example of how to handle threading properly
<desrt> ....and the trouble that you can get naive programmers into when you do so
<desrt> turns out because of it's "threads are awesome" approach, there are some things that 'just work' in dbus-1 that are much harder in gdbus :(
<desrt> classic example is registering object paths after successfully acquiring a bus name
<desrt> in dbus-1 world this is perfectly logical, and there is no race: you don't return to the mainloop to process the incoming message queue until after the object is already registered from the same thread
<desrt> in gdbus you have trouble: another thread is already processing the incoming messages before you have a chance to register your objects
<desrt> sometimes stupid is better......
<hallyn> complexity is complex
 * hallyn wonders how long until we're talkign about capabilities, esp since sarnold is around
<desrt> linux style "capabilities" are evil :(
<hallyn> itym POSIX :)
<desrt> nope
<desrt> fortunately, there was never agreement about this stuff at POSIX
<sarnold> itym posix-draft  :)
<desrt> (not for lack of trying....)
<hallyn> eh
<hallyn> well, as maintainer of capabilitiesin the kernel, when something appropriate comes along i'll ack the patch removing posix caps :)
<hallyn> we'll see when that happens
<desrt> give me seccomp or give me death :)
<hallyn> peopel are always trying.  but the alternative is always worse
 * hallyn points to lxc  WE GOT SECCOMP :)
 * desrt <3 capsicum
<hallyn> ah, but it attaches capabilities to fds :)
<hallyn> but yes i'm attracted to capsicum
<desrt> i wonder if you've seen memfd ;)
<sarnold> hallyn: man who did you upset to get stuck with maintaining caps in the kernel? :)
<hallyn> sarnold: amorgan
<desrt> we have these new things called "seals" that you can apply to fds now, via fcntl
<desrt> introduce a few more seals, mix in some seccomp, and we more or less have capsicum :)
<hallyn> yeah there are presentations coming on capsicum in linux, i'm hopeful
<desrt> that would be such a win
<hallyn> well, we'll see whether people end up able to use them properly.  but again i'm hopeful
<hallyn> slangasek: ok so i just pushed a new cgmanager (_0.26-0ubuntu6) to utopic which has the sysvinit scripts so should be usable for debian.  There is an existing ITP with an old version by dba with very different packaging.  Is there a protocol for, i dunno, replacing/updating the ITP with the utopic version or something close to it, for jessie?
<slangasek> hallyn: the protocol is that you ask me to upload it; ITPs are advisory locks only
<desrt> hallyn: so did that file look OK to you?
<desrt> fwiw, i'm having trouble telling the difference between scope unit and user unit if they both take the same transient parameters
<desrt> seems that they only used a different scheme for cooking up the path....
<desrt> /user/%d.user/c%d.session vs. /user/%d.user
<desrt> which raises another question: can we create the session one without having first created the user one?
<hallyn> slangasek: oh - in that case i'll do a bunch more testing and get back to you thx :)
<hallyn> desrt: so yes, we *can* (and do bc of the bug you found in the user_scope) create teh session one without the user one,
<desrt> what happens if we come along and create the other one later?
<hallyn> desrt: and since we currently don't do actual cgroup configuration, it'll be no different for now;
<desrt> retroactive containment?
<hallyn> nothing;  it' sjust an mkdir in the cgroupfs returning EEXIST
<hallyn> but i think it's possible for the /usr/%d.user one to have some basic containment,
<hallyn> which all sessions shoudl be subject to.
<hallyn> so at some point we'll want to have both properly handled;
<hallyn> but i've mainly looked at the session code so i'm guessing;  lemme look at the logind code for the user scopes
<hallyn> that is, the /user/%d.user cgroups
<hallyn> ok, i dont' see any code in systemd doing anything like it though
<hallyn> desrt: so if you wanted to just remove the user-unit.c altogether (for now) it might be just as well
<desrt> well
<hallyn> if systemd/logind every does slice configuration of /usr/%d.user then we can add it
<desrt> i think that maybe we should have a new type of cgroup unit or something
<desrt> since these two different types are really very similar
<desrt> the only annoying bit is the way the Slice property is handled...
<hallyn> really i'm in no way attached to how i structured any of it - it fell out from how i discovered what the logidn protocol was doing
<hallyn> what's wrong with how the Slice property is handled?
<hallyn> slangasek: all right if we're going for itp then perhaps a new upstream cgmanager release is in order
<slangasek> as you wish :)
 * desrt tries sleep for a bit
<desrt> hopefully i will be better equipped to figure out some better way of dealing with *.scope and *.slice without special cases in the morning :)
<pitti> Good morning
<pitti> bdmurray: yes, I'll have a look
<pitti> bdmurray: MP> cool, thanks!
<pitti> stgraber: hm, that lxc autopkgtest regression looks "real" (deluser: The user `usernic-user' does not exist.), but the same version succeeded before
<pitti> stgraber: could that be due to the new cgmanager?
<pitti> (that's at least what britney is holding back)
<pitti> ah, cgmanager itself is failing, too
<hallyn> cgmanager tests are passing for me locally;  where is it failing?  also 'deluser usernic-user' should only happen at end of tests, after we've purposely created it...
<pitti> hallyn: you shold have gotten a mail about it, didn't you?
<pitti> https://jenkins.qa.ubuntu.com/job/utopic-adt-cgmanager/25/ARCH=i386,label=adt/console
<pitti> test 14 failed
<pitti> it's not very verbose why it fails unfortunately
<hallyn> pitti: do those tests not get run in ppas?
<pitti> hallyn: we have one or two manual autopkgtest jobs for PPAs (firefox), but not in general, no
<hallyn> pitti: can you re-fire the tests somehow?
<pitti> hallyn: yes, I can, if that was a transient failure
<pitti> hallyn: running
<hallyn> i'm hoping - bc liek i say i can't reproduce locally.  i coudl also just push the 0.27-0ubuntu1 version (which is basically identical and i was going to push anyway)...
<hallyn> i'm testing both on vm and in container in same vm...
<pitti> I also restarted LXC, just to confirm
<hallyn> i did at one point notice a weird error msg (an hour or two ago) about apport failing to upgrade, bad sysvinit script;
<hallyn> pitti: i'm still afraid i may have done something bad with the sysvinit scripts for cgmanager...  would you mind taking a quick look at debian/*init and debian/rules (which i did not chnage) in the failed cgmanager version?
<hallyn> oh, here:
<hallyn> update-rc.d: warning: default stop runlevel arguments (0 1 6) do not match apport Default-Stop values (none)
<pitti> err, apport? curious
<hallyn> oh, is that complaining about the upstart.vs.sysvinit stop values?
<hallyn> it's stop on runlevel [!2345] in upstart, no stop values in sysv
<pitti> hallyn: no, that's usually a complaint that your init.d LSB header has different stop levels than the update-rc.d call in postinst
<hallyn> oh
<pitti> hallyn: which init.d script is that?
<hallyn> /etc/init.d/apport ?
<pitti> hallyn: ah, I thought we are still talking about cgmanager (as you wanted me to have a look there)
<hallyn> heh, sorry.  yeah it's just coincidence
<hallyn> well i suppose it caught my eye bc it came up while i was tryign out the cgmanager sysvinit script patch
<pitti> hallyn: right, thanks; I'll fix that
<hallyn> cool
<pitti> (it's just a warning though)
<pitti> hallyn: cgmanager failed again
<hallyn> hm.  and lxc?
<pitti> still running
<pitti> FAIL: lxc-tests: /usr/bin/lxc-test-unpriv
<pitti> ---
<pitti> /usr/sbin/deluser: The user `lxcunpriv' does not exist.
<pitti> hallyn: but it's already past that, so will fail again
<pitti> so, same error
<pitti> that doesn't sound like cgmanager, but it also doesn't look like a flaky test
<hallyn> what is the testbed here?
<pitti> but there's a lot of stuff in -proposed
<hallyn> runs in a container?
<pitti> hallyn: QEMU
<pitti> (http://packaging.ubuntu.com/html/auto-pkg-test.html#executing-the-test)
 * pitti runs cgmanager locally
 * hallyn sets up an environment
<hallyn> bah - 'booting vm to run cloud-init' :)
<pitti> hallyn: well, yes -- anything wrong with that?
<pitti> these VMs use the cloud images, so they might as well use its setup machinery
<hallyn> pitti: only that they're not using lxc for the basic setup :)  i'm on a rather slow temp laptop
<pitti> hallyn: oh, you can of course also run them in LXC
<hallyn> yeah but i don't want any delta from what's ahppening in archive
<hallyn> so i'll take the hit
<pitti> hallyn: so it succeeded locally here
<hallyn> with proposed enabled?
<pitti> the test 14 doesn't say what it failed on, so hard to say
<pitti> yes
<hallyn> hm.
<pitti> adt-run --apt-pocket=proposed -U cgmanager --- qemu /home/martin-scratch/adt-utopic-amd64-cloud.img
<hallyn> well i coudl push a version with more verbosity in test 14
<hallyn> could the base test image be bad on the tester?
<pitti> so this could be dependent on system load, or time zone, or whatever
<hallyn> system load is plausible
<pitti> hallyn: it's working fairly well for other tests, and it failed the same way 4 times now (on different machines)
<hallyn> but do those machines use shared (ceph) storage to store the canonical image?
<pitti> no, it's just a normal local ext4
<hallyn> well scratch that idea then
<pitti> hallyn: do you have VPN set up?
<hallyn> no
<hallyn> halp - the OS a chance to collect more entropy! (Need 187 more bytes)
<pitti> hm, we install haveged into the VMs, where do you see this?
<hallyn> running adt-run on my laptop
<hallyn> finally got past it
<pitti> oh, for adt-run key creation
<pitti> I should fix that to only run if you want to run local binaries
<hallyn> hm, fails on
<hallyn> Errors were encountered while processing: rsync
<pitti> hallyn: sorry, missed your reply; rsync where? on package install?
<hallyn> right, during setup i guess
<hallyn> i was doing adt-run --apt-pocket=proposed -U cgmanager --- qemu ~/adt-utopic-amd64-cloud.img
<hallyn> pitti: so it never got to actual cgmanager test running
<pitti> i. e. the rsync package failed to install? (do you have a log?)
<pitti> that worked here
<pitti> hallyn: so if you tell me how to squeeze more info out of test14, I'm happy to run it on the CI machine
<pitti> (set -x or something?)
<hallyn> pitti: no, sorry i killed the term
<hallyn> pitti: oh i was just going to add some echos to show which 'exit 1' was happening
<pitti> or that; set -x is quite nice for tests which don't use shunit or something else with verbose failures
<hallyn> i've got a hunch that it's exiting bc Remove xxx is succeeding when xxx/b exists, and it shouldn't
<hallyn> except if that happens there it hsould happen for us
<hallyn> pitti: there's not some weird environment where the test run with -e right?  (exiting on command failure?)
<pitti> hallyn: your test script determines that
<hallyn> pitti: ok my test script doesnt' set it
<pitti> hallyn: i. e. if it's doing set -e or #!/bin/sh -e
<pitti> TBH I consider set -e pretty much a must for every shell script
<pitti> hallyn: but anyway, if your debian/tests/foo doesn't use it, it won't be implied from anywhere; there's on magic /bin/sh in the testbed
<pitti> hallyn: so if your autopkgtest has allow-stderr, it's probably simplest to just add set -x
<hallyn> pitti: yeah if you can run with -x that'd be great
<hallyn> allow-stderr?  dunno stgraber hooked that up,
 * hallyn checks
<hallyn> yeah it's set
<pitti> hallyn: oh, debian/tests/exercise does have set -eu
<pitti> so it's well behaved
<pitti> hallyn: so runtests.sh is indeed run under dash and -e
<pitti> as debian/tests/exercise sources it, not execute
<hallyn> pitti: oh.  well then i don't see how it ever passed.  bc it does things like
<hallyn> cmd \n  if [ $? -eq 0 ]; then fail; fi
<pitti> hallyn: hm, I don't think we are looking at the same script
<pitti> grep eq tests/runtests.sh -> no hit
<pitti> oh, that's running test/*.sh
<hallyn> dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.Remove string:'memory' string:"xxx" int32:0 > /dev/null 2>&1
<hallyn> if [ $? -eq 0 ]; then exit 1
<pitti> hallyn: right, ok; so runtests.sh runs with set -e, but it execs tests/test*.sh which don't
<hallyn> oh, ok
<hallyn> phew.  not that running with -e woudl bother me, but i just wouldn't have understood hwo it ever passed before
<hallyn> so if you could just run with -x maybe we can figure it out
<hallyn> though i'm about to head to bed
<pitti> hallyn: yes, doing now
<pitti> hallyn: I can mail you the output
<pitti> hallyn: I'll reply to the jenkins failure mail
<hallyn> pitti: thanks!
<pitti> hallyn: sent
<hallyn> pitti: just reproduced it on jessie container.  looks like it's a real bug
<hallyn> but i don't undestand it.  well, hopefully tomorrow - gnight
<hallyn> oh ffs.  no.  NO!  ti stopped reproducing.  this is ridiculous
<pitti> hallyn: could perhaps be because the DC is running trusty's qemu?
<FourDollars> Hi, who is willing to sponsor my patch for https://bugs.launchpad.net/gnome-desktop/+bug/1340544?
<ubottu> Ubuntu bug 1340544 in gnome-desktop3 (Ubuntu) "gnome-rr: The minimum brightness can not be 0." [Undecided,New]
<doko> seb128, Laney: do you know http://www.infinality.net/blog/infinality-freetype-patches/ ?
<seb128> doko, no, why?
<seb128> doko, but slangasek is the freetype maintainer
<doko> heh
<Whoopie> pitti: Hi, thanks for applying my patch for LP 1299975? Can you also sponsor the upload to trusty?
<ubottu> Launchpad bug 1299975 in pm-utils (Ubuntu Trusty) "wireless script checks wrong sys file" [Undecided,Fix committed] https://launchpad.net/bugs/1299975
<Whoopie> pitti: sorry, found it in https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text=
<Whoopie> pitti: Thanks!!!
<Saviq> xnox, hey, should a Architecture: all package have Multi-Arch: foreign? like suru-icon-theme?
<pitti> Whoopie: yw; mvo sponsored it to trusty yesterday
<xnox> Saviq: yes, see e.g. ttf-ubuntu-font-family
<xnox> Saviq: there is an open dpkg feature request to treat transitive arch:all packages as m-a:foreign but there are concerns if that's actually always correct to do.
<Saviq> xnox, mhm, got it
<Saviq> xnox, can you please have a look at https://code.launchpad.net/~saviq/ubuntu-themes/fix-multiarch/+merge/226418
<xnox> Saviq: i wonder if I should try silo release that straight away.
<Saviq> xnox, you mean bypassing silos? be my guest
<xnox> Saviq: nah, as in me assigning the silo and doing it.
<Saviq> xnox, yeah lets
<Saviq> '
<Saviq> xnox, lemme add a line
<Saviq> ugh if only gdocs wouldn't log me out all the time
<seb128> Saviq, wait
<Saviq> oupf
 * Saviq waiting
<seb128> Saviq, if you do a themes landing, we might want to include some bugfixes ... can you give me some minutes to check that?
<Saviq> seb128, sure
<seb128> Saviq, or do you prefer to do separate landings?
<Saviq> seb128, is fine
<Saviq> seb128, lemme know
<xnox> seb128: i'd prefer separate. It's a packaging change only, which unblocks cross-building.
<xnox> seb128: no theme changes at all, thus not blocked on testing that =)
<Saviq> should be a quick one, too
<Saviq> you guys decide :)
<seb128> xnox, it's not like theme bugfixes need lot of testing
<seb128> xnox, that's gtk themes, so desktop only
<xnox> seb128: hm, there are a bunch approved. It's not desktop only, there are suru icons as well.
<seb128> xnox, we don't need to list them all
<xnox> ~mhr3/ubuntu-themes/fix-suru-inheritance looks simple
<Saviq> and we should land it, yeah
<seb128> that would be nice to get yes
<xnox> ~sil2100/ubuntu-themes/osk_design_icon_association_change
<xnox> looks sensible as well (needs osk testing)
<seb128> https://code.launchpad.net/~larsu/ubuntu-themes/three-twelve/+merge/225982
<seb128> would be nice to get as well
<xnox> ~larsu/ubuntu-themes/three-twelve
<xnox> yeap.
 * xnox goes to adjust the landing line
<seb128> thanks
<Saviq> how about https://code.launchpad.net/~tiheum/ubuntu-themes/suru-icons/+merge/226325 ?
<Saviq> well, it's waiting for Jouni's ACK, so let's maybe let it wait...
<xnox> seb128: Saviq: huh, i don't have powers to change spreadsheet.... but have acls to assign silos.
<cjwatson> We're pretty low on silos right now
<Saviq> xnox, are you logged in? google logs me out all the time recently
<xnox> Saviq: I can't review ~tiheum branch above. I'd wait on it.
<Saviq> yeah
<xnox> cjwatson: did notice, only one was free. probably best to wait for a few to clear out.
<seb128> Saviq, xnox: I added the inherit and the gtk 3.12 ones ... anything else?
<Saviq> seb128, looks fine to me
<didrocks> xnox: granted
 * didrocks shares ownership at the same time
<didrocks> sil2100: you owne the spreadsheet now, congrats!
<didrocks> (we can only have one owner)
<xnox> seb128: tweaked tests and description
<sil2100> didrocks: uh oh, I do?!
<sil2100> didrocks: thank you ;p?
<xnox> didrocks: only one owner -> webscale bus factor =)
<didrocks> sil2100: yw
<didrocks> xnox: isn't it? ;)
<xnox> didrocks: i'm lovin it!
<didrocks> I guess the domain owner can reclaim ownership though
<didrocks> well, at least, I hope :)
<seb128> xnox, thanks
<didrocks> other you fork it and create a "new new spreadsheet"
<didrocks> sil2100: btw, reminder that I guess you can rename the spreadsheet now to remove the new :)
<xnox> didrocks: yeah, i'd think so too. I think on my googleapps as an admin i can revoke an app permission and thus transfer ownership of everything elsewhere.
<didrocks> I think nobody is using the old dead one
<xnox> didrocks: and then reactivate app for that user.
<didrocks> yeah, would make sense
<Laney> my awesomebar still remembers the old one
<Laney> and I reinforce that by always picking it first :(
 * didrocks looks if we can delete the old one
<didrocks> one sec
<Laney> been trying to go to wiki/citrain lately
<didrocks> Laney: nuked
<Laney> nice
 * xnox thinks there is something wrong with libtool
<xnox> current=3, age=1, revision=0 yet soname 2.1.0
<pitti> current-age == 2
<pitti> xnox: don't try to think about these numbers too hard; it'll melt your brain
<xnox> pitti: yes, yes, i remember that now.
<xnox> pitti: so upstream broke abi but didn't bump the numbers.
<pitti> I think the resulting version number is (current-age).age.revision or so
 * xnox runs git log -p on configure.ac to verify
<pitti> xnox: ordinarily that's done in Makefile.am
<pitti> xnox: grep for -version-info
<pitti> (and yay for not using GNU option syntax, but meh)
<xnox> pitti: well, in their case, they use variables in -version-info which are set in configure.ac as constants.
<pitti> xnox: ah ok, osrry
<xnox> pitti: last abi bump was by slangasek .... who is not upstream, so yeah upstream have no clue.
<xnox> seems weird -> i should bump current by one and reset age to 0
<xnox> but that makes it jump from 2.1.0 to 4.0.0
<pitti> I had a nice page which explained all that the other day, but apparently I lost the bookmark
<xnox> well, last time steve bumped both current and age by +1
<xnox> i'll do the same here.
<pitti> xnox: https://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
<pitti> xnox: I thought you'd just set age to 0 on changed/removed API?
<pitti> but meh, this might be wrong too; I wish libtool wasn't trying to be "helpful" and let one just specify the soname :)
<xnox> seems odd though. If interfaces are added, then next time age is bumped (4.0.0 -> 3.1.0), then one more adds happen (3.1.0 -> 2.1.0) ?!
<xnox> ah, no, cause current will have to be bumped as well.
<xnox> nevermind me.
<xnox> pitti: any advice as to which abi version number to use between upstream fixing it and me packaging it?
 * xnox tries to use 2a
<xnox> libtool hates that.
<rbasak> Is https://bugs.launchpad.net/ubuntu/+source/libsdl1.2/+bug/1340294 an actual problem? It means that binaries linked against libsdl in the archive will actually be under the terms of the GPL, but that would still be DFSG-free, right?
<ubottu> Ubuntu bug 1340294 in libsdl1.2 (Ubuntu) "Library linking leads to incompatible licenses." [Undecided,New]
 * rbasak doesn't see an actual incompatibility here
<xnox> rbasak: the problem is, that everything that links libsdl1.2 now needs to be GPL compatible, instead of just LGPL. It's the same bug that prevented migration to e.g. the new gnutls.
<xnox> rbasak: e.g. anything that links to openssl, cannot also link to libsdl1.2 anymore, since transitively GPL code would be linked to OpenSSL which are incompatible.
<xnox> previously that was not a problem. (i'm assuming there is no openssl exception in libcaca)
<xnox> s/libcaca/libslang/
<smb> hallyn, It does not seem like anybody wants to be helpful on bug 1321365. Would you think that this version of libvirt could go into updates anyway? Then my follow up might be accepted into trusty-proposed...
<ubottu> bug 1321365 in libvirt (Ubuntu Trusty) " virsh (ppc) fails with "missing /proc/device-tree/cpu "" [Critical,Fix committed] https://launchpad.net/bugs/1321365
<debfx> imho that bug should be moved to libcaca which can disable the slang backend.
<pitti> xnox: I don't even know which package you talk about :)
<xnox> pitti: plymouth made an upstream release 0.9.0
<xnox> pitti: debian doesn't package shared libraries, but we do. Cause casper and mountall use them.
<pitti> xnox: oh, I was about to ask whether we can at least coordinate that with debian
<xnox> pitti: the APIs they use, have not changed, but others have been removed. And upstream forgot to bump abis.
<pitti> xnox: so if it only affects ubuntu, then I guess the shlib name doesn't matter, so appending an 'a' sounds fine to me
<pitti> xnox: do we use any of the removed API?
<xnox> pitti: do you know any past examples where that was done?
<xnox> pitti: no, we do not use any of the removed APIs
<pitti> xnox: I don't remember; we usually avoid changing soname downstream at all costs
<pitti> we rather just ported stuff and added strict dependencies
<MacSlow> anybody seen something like this with recent updates pulled on utopic -> https://bugs.launchpad.net/ubuntu/+bug/1340710
<ubottu> Ubuntu bug 1340710 in Ubuntu "/var/log/kern.log gets spammed with rfkill messages" [Undecided,New]
<xnox> cyphermox_: ^
<cyphermox_> xnox: thanks
<stgraber> hallyn: allow-stderr was probably a copy/paste from lxc where we have harmless messages going to stderr
<stgraber> pitti: the deluser message would indicate that the test failed before it created the user. We have a cleanup hook which attempts to kill the test container, remove the user, ... so I suspect that error message comes from the cleanup hook and is a sign of a problem earlier on
<pitti> stgraber: ah, thanks
<hallyn> BenC: hi, you do ppc stuff right?  would you be able to (have someone) verify the fix for bug 1321365 ?  Othewise as smb said we should probably just promote anyway
<ubottu> bug 1321365 in libvirt (Ubuntu Trusty) " virsh (ppc) fails with "missing /proc/device-tree/cpu "" [Critical,Fix committed] https://launchpad.net/bugs/1321365
<BenC> hallyn: Already verified
<hallyn> BenC: oh!  could you set the verificatin-done tag?
<hallyn> pitti: why would trusty
<hallyn> trusty's qemu be the problem?
<pitti> hallyn: no particular reason, it's just one obvious difference to running locally
<BenC> hallyn: How do I add that tag?
<hallyn> oh.  no, this laptop here is trusty too.  (my utopic one is the one that died)
<pitti> hallyn: another is that in the CI lab there is a pretty heavy network firewalling
<hallyn> BenC: at bottom of description is the lsit of tags - edit it to change verification-needed to verification-done
<pitti> hallyn: ah, good; I sent you the set -x output, but I suppose you'll need some more logs
<hallyn> or just make a note in the bug and i'll change it
<pitti> hallyn: nothign in dmesg btw (not sure whether I wrote that)
<BenC> hallyn: Done
<hallyn> pitti: like i say i had a 30 sec window where i could reproduce it on my fast precise(+utopic kernel) host in a jessie container...  so there' sdefinately *something* real to it
<hallyn> BenC: thanks!
<BenC> hallyn: And thank you
<pitti> hallyn: ah, so it is a race condition of some sort, which is just very persistant on that machine
<pitti> hallyn: FYI, these machines are pretty beefy (gazillion CPUs and GB of RAM), and the overlay runs on tmpfs
<desrt> hallyn: hey... tearing down cgroups won't work
<desrt> hallyn: due to the transient nature of the shim we can't "remember" the slice that a particular unit was located within
<desrt> so for the /user/%d.user/c%d.session case we'll have forgotten the uid by the time the Stop call comes
<desrt> and we will not be able to instruct cgmanager on which group to remove
<hallyn> desrt: that's ok, we set autoremove ont he cgroups
<hallyn> desrt: so they'll go away when the user logs out automatically
<desrt> that logic seems a bit backwards
<hallyn> at least, it worked on my tests
<desrt> isn't the point of all of this cgroup stuff to allow systemd to forcably clean up a user session on logout?
 * hallyn grumbles something he problably shouldn't ...
<hallyn> desrt: we're not yet handling the StopUnit are we?
<desrt> i just checked.... systemctl stop session-37.scope for example kills all the processes in that scope
<desrt> hallyn: no... we're not, and i think that maybe we can't :/
<hallyn> desrt: won't the dbus message for StopUnit list the both the session and slice?
<desrt> no
<hallyn> then how would systemd itself know?
<desrt> it lists the session but the slice was given to the StartTransient only
<desrt> systemd doesn't get restarted.....
<hallyn> but session-2.scope is ambiguous
<desrt> no.  systemd is stateful.
<desrt> it remembers what session-2.scope is
<desrt> (and more importantly, where it is)
<hallyn> uids 1000 and 2000 can both have session-2.scope
<desrt> no... that's not possible
<desrt> sessions are unique
<hallyn> huh
<desrt> by that token i guess we could spider the cgroups tree looking for the matching one
<hallyn> well, there are ways to fix that (keep state somewhere) and I would claim that's somethign to worry about later
<desrt> but ... yick
<hallyn> if at all
<desrt> so don't worry about stop?
<hallyn> right - or rather, punt on stop for now
<desrt> okay.  you're the boss :)
<hallyn> desrt: systemd may claims that "killing all tasks on logout" is the main feature,
<hallyn> desrt: but the main feature for me is granting delegated cgroups for the user to use
<hallyn> for unprivileged container use
<desrt> this is why we chown...
<hallyn> right
<desrt> okay
<desrt> so the code is shrinking :)
<hallyn> desrt: love it :)
<hallyn> desrt: feh, right you are.  I really thought that the sessoins were per-user unique only
<hallyn> of course that means we can more easily fix this if/when we want,
<desrt> right -- we can walk the cgroup tree :/
<hallyn> or keep state in /var/run  <shrug>  if that doesnt' make you cry
<desrt> i'd prefer to just use the state already in the kernel rather than make a copy of it
<desrt> worth noting that also logind already does this...
<hallyn> doesn't bother me :)
<desrt> if you cat /run/systemd/sessions/1 for example you see UID=1000 in there
<hallyn> pitti: oh your email clarifies what I missed last night - it's not failing the way i thought
<hallyn> it
<desrt> not sure if we can rely on that at the point that logind is already trying to tear the session down, though
<hallyn> desrt: does logind walk the tasks list and kill them all?  or does it now expect systemd-dbus to do it?
<hallyn> pitti: i thought it was failing when it did 'rmdir xxx' (non-recursively) when xxx/b exists (which should fail).  but it's actually failing on the recursive rmdir.  that's more hopeful for being sane
<desrt> hallyn: systemd does it, pretty sure
<hallyn> k
<desrt> hallyn: so our cgroup hierarchy is different from the systemd one, i guess?
<desrt> we seem to call it like user/1000.user/42.session
<hallyn> yes, we do.  what does systemd do?
<desrt> instead of user/user-1000.slice/session-42.scope ?
<desrt> systemd names the cgroups after the requested names
<hallyn> i'm just sticking with the terms stgraber had used in the earlier logind patches
<hallyn> desrt: maybe systemd changed that after v204?
<desrt> maybe?
<hallyn> stgraber: ^ done on purpose?
<hallyn> (I don't really care either way)
<desrt> extracting the uid out of the unit name is ... interesting
<desrt> because it's impure from the standpoint of what is happening here
<desrt> i guess systemd doesn't do this :)
<slangasek> doko: my position on the infinality patches is that freetype behavior changes give me enough problems without me diverging from mainline :)
<desrt> unless it has some similar magic
<desrt> hallyn: can you remind me again what the issue was about the JobRemoved business?
<hallyn> stgraber: to be absolutely sure, the jenkins autotest runs are all done in their own private qemu, right?  not in lxc?
<desrt> and also what this get_state() thing is about?
<desrt> you seem to try to pass "static" into a (o) parameter... which is not good :(
<hallyn> desrt: I had no idea what get_state was :)  I didn't add it
<hallyn> I just cut-pasted from other units for that,
<desrt> g_dbus_method_invocation_return_value (invocation, g_variant_new ("(o)", unit_get_state(unit))); <- you added this
<hallyn> oh yeah.  I wasn't sure if I should return the path of the cgroup to systemd or not
<desrt> definitely not
<hallyn> and never got around to reconsidering.
<hallyn> ok
<desrt> it may not be a valid dbus object path
<hallyn> so systemd doesn't care?
<desrt> in fact, certainly isn't...
<hallyn> ok
<desrt> since you can't have '-' in those
<hallyn> always passing
<hallyn> '/' just seemed weird
<hallyn> (i'm missing a key so i keep accidentally hitting enter :( )
<desrt> it is :)
<hallyn> desrt: what do you mean by JobRemoved business?
<desrt> you conditionalise it not to run for 'user' units
<desrt> slices, i guess?
<hallyn> oh, yeah - what would it mean to remove that job?
<desrt> i dunno
<desrt> i think we added this code for the power units, as i mentioned...
<hallyn> I was afraid it would mean systmed would log you out.
<hallyn> I.e. it woudl see it as the slice beign removed
<desrt> no idea :)
<desrt> i guess we should only do this for power units, to be honest
<hallyn> right, you did that to not re-suspend right?
<desrt> although i think JobRemoved might actually mean "the process of starting this thing is now done"
 * desrt checks that theory
<desrt> yup.  it's true
<desrt> /org/freedesktop/systemd1: org.freedesktop.systemd1.Manager.JobNew (uint32 14405, objectpath '/org/freedesktop/systemd1/job/14405', 'abc.slice')
<desrt> /org/freedesktop/systemd1: org.freedesktop.systemd1.Manager.JobRemoved (uint32 14405, objectpath '/org/freedesktop/systemd1/job/14405', 'abc.slice', 'done')
<hallyn> oh then it hsouldn't be conditional :)
<desrt> maybe we should try harder to make up some decent-looking job names :)
<hallyn> what are you showing there?
<desrt> this is what real systemd says in response to me creating abc.slice
<hallyn> oh
<desrt> (gdbus monitor --system --dest org.freedesktop.systemd1)
<cyphermox_> pitti: hey, I'm asking you because you're apparently the last who touched acpi-support. is there a reason to still keep this?
<stokachu> @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: stokachu
<desrt> hallyn: hey... trying to test this stuff now
<desrt> where do i get the updated cgmanager?
 * desrt needs to start moving toward the airport soonish....
<hallyn> desrt: utopic-proposed
<hallyn> or ppa:serge-hallyn/virt has it too
<desrt> hmm
<desrt> i have proposed
<hallyn> you have 0.26-0ubuntu6?
<hallyn> that should suffice
<desrt> yes
<desrt> hm.  problem seems to be with my code ;)
 * desrt was treating api_version as unsigned (not signed) int
<desrt> so... it's not creating the cgroups i ask for
<desrt> or i am misunderstanding something
<hallyn> if cat /proc/self/cgroups doesn't show your /user/$uid.user/c-$session.session, then it's not working :(
<hallyn> desrt: you can put "cgmanager_opts="--debug"" in /etc/default/cgmanager and look in /var/log/upstart/cgmanager.log to see if it's getting requests at all
 * hallyn changing locale for a mtg, bbiab
<desrt> hallyn: i'm getting a failure of MovePid
<desrt> MovePid: Client fd is: 6 (pid=4054, uid=0, gid=0)
<desrt> cgmanager:per_ctrl_move_pid_main: victim's cgroup is not under proxy's (p.uid 0)
<stgraber> hallyn: correct
<desrt> hallyn: in any case, i've pushed https://github.com/desrt/systemd-shim/tree/cgm.1
<desrt> i think it's mostly right... please take a look
<desrt> it doesn't currently attempt to deal with cgmanager restarts
<hallyn> desrt: thanks, i plan to look in 1.5 hrs
<desrt> hallyn: i probably won't get too much more of a chance to look at this
<desrt> but i think any required fixes should be relatively minor at this point
<hallyn> desrt: ok, i'll hack on it until it works,
<hallyn> desrt: you're gone next week?
<desrt> ya
<desrt> i guess you guys can carry a patch until i return?
<hallyn> desrt: hwo shoudl we proceed - should i take wahtever works and try to push to unstable?
<desrt> alternatively, you could deal with pitti
<hallyn> ah, ok, i'll ask pitti for guidance - thanks desrt !
<desrt> he knows his way around dbus/gobject and he has commit access to systemd-shim
<desrt> pitti: might be nice if you review my code anyway.... i wrote it in a hurry :p
<hallyn> desrt: you're probably gone;  but i'm using yoru s ystemd-shim and it seems to be working
<hallyn> d'oh
<hallyn> nm.  i'm an idiot
<hallyn> didn't built jessie's systemd on this box (thought i'd done that)
<hallyn> stgraber: https://jenkins.qa.ubuntu.com/job/utopic-adt-cgmanager/29/ARCH=amd64,label=adt/console   fascinating.  apparently readdir(/run/cgmanager/memory/xxx) is not listing /run/cgmanager/memory/xxx/bbb, which does exist...  i don't know if this is a new cgfs race, or what.  guess i'll add a sleep in the testcase and see
<stgraber> weird
<hallyn> actually no a sleep won't help,
<hallyn> bc the testcase already does a
<hallyn> + dbus-send --print-reply --address=unix:path=/sys/fs/cgroup/cgmanager/sock --type=method_call /org/linuxcontainers/cgmanager org.linuxcontainers.cgmanager0_0.ListChildren string:memory string:xxx
<hallyn> + grep -q bbb
<hallyn> after the Create, so obviously the fs is settled by now
<desrt> hallyn: at the airport
<desrt> hallyn: got a bit of time if there's anything you need to tell me :)
<hallyn> desrt: nah, unfortunately i'd forgotten to save away the systemd-208 changes i had to make to use it with the new shim;  so i'm having to re-create those ona  new test vm
<desrt> OK
<desrt> good luck :)
<hallyn> thanks - have a good vacation!
<hallyn> or trip or whatever it is :)
<desrt> this crazy thing: http://ses.ikso.net/2014/sk/
<hallyn> wow
<desrt> ya.... in retrospect, i'm not entirely sure why i'm doing it...
<hallyn> desrt: exactly how did you test the shim?  did you send your own dbus messages, or use logind?
<desrt> sent my own messages
<desrt> everything seemed to work except that MovePid gave that error i mentioned earlier
<hallyn> dbus-send?
<desrt> gdbus...
<hallyn> did you run it as root?
<desrt> yes
<hallyn> ok.
<desrt> is there some weird authentication step i need to take?
<desrt> or does cgmanager know that i am root?
<hallyn> it knows
<hallyn> desrt: ok, took some finagling of logind (the packaging for systemd-208 will need work) and there was a several-seconds hang, but i *did* get cgroups,
<hallyn> 6:devices:/user.slice/user-1000.slice/session-7.scope
<desrt> hallyn: did the MovePid work?
<hallyn> desrt: yup
<desrt> oh.  nice.
<desrt> all good then, i guess
<hallyn> stgraber: https://jenkins.qa.ubuntu.com/job/utopic-adt-cgmanager/30/ARCH=amd64,label=adt/console  oh, so it looks like there is a race so that after we rmdir xxx/bbb, xxx cant' be immediately freed.  kernel bug it seems like.
<hallyn> i'm afraid i'm out for the weekend - back sunday night hopefully - \o
<desrt> hallyn: have a good one
<hallyn> apw: ^  i may end up bugging you about the kernel bug
<hallyn> desrt: you too :)
<hallyn> apw: (assuming it is a kernel bug)
<Saviq> Laney, FYI, welcome wizard is totally b0rked in the latest system-settings release :|
#ubuntu-devel 2014-07-12
<darkxst> pitti, is there some way to make tests work when they want their own dbus interface?
<darkxst> (/Â«PKGBUILDDIRÂ»/tests/libtracker-miner/.libs/lt-tracker-file-notifier-test:5956): Tracker-CRITICAL **: Could not get SPARQL connection: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Tracker1 was not provided by any .service files
<Laney> Saviq: oh?
<Laney> Saviq: your MP fixes that?
<Laney> can you get kenvandine to look?
<Laney> I wasn't involved with the libqofono MPs so I don't really know about it yet
#ubuntu-devel 2014-07-13
<ari-tczew> M-o-M has been not refreshed since 1 week :-/ "Generated at 2014-07-06 03:45:43 UTC."
<loa> Hello. Why bootdegraded=true option was deleted from ubuntu 14.04?
<bekks> loa: Because a degraded RAID will still boot. :)
<loa> bekks, it is not.
<loa> boot only one time *
<loa> if reboot again i always droped into initramfs
<bekks> So whats the exact error when it isnt booting? And lets take this to #ubuntu
<loa> bekks, it boots only one, if i reboot again i recieve this https://dl.dropboxusercontent.com/u/25725476/screenshot-2014.07.13-15%3A42%3A50.png
<loa> bekks, i don't uderstand for what reason this done.
<loa> maybe for possibility to do last backups...
<loa> i found this https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1279741
<ubottu> Ubuntu bug 1279741 in mdadm (Ubuntu) "Degraded array check, may not do what it says it's doing" [Undecided,Fix released]
<loa> not i if to be true) another man from ubuntu.
<bekks> loa: If you dont have backups at that point, its too late most likely ;)
<loa> bekks, my point to do gateway wchich will work as far as possible)
<bekks> I didnt get that sentence.
<loa> data is not what i am worring about.
<loa> i want degraded raid to boot ok.
<loa> i don't want that initramfs thing.
<loa> Under 12.04 all work as expected, that what i am talking about.
<bekks> The device is busy, as the message states. So better use rootdelay=
<loa> it even asking me at install "Do you want to boot degraded raid?"
<loa> bekks, what rootdelay exectly do?
<loa> i need to pass number of seconds to it?
<loa> bekks, https://dl.dropboxusercontent.com/u/25725476/screenshot-2014.07.13-15%3A49%3A46.png
<loa> bekks, do you read this? https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1279741
<ubottu> Ubuntu bug 1279741 in mdadm (Ubuntu) "Degraded array check, may not do what it says it's doing" [Undecided,Fix released]
<loa> i am about this part: We should attempt starting arrays with --no-degraded a few times, and after a timeout assemble them with --run, and if we don't have enough drives to start the array only then fall through to initramfs recovery shell.
<mapreri> pitti: I'm wondering if we should bother ourself with a merge like this: http://paste.debian.net/109461/ or it's better to sync it (I think the letter)
<xnox> loa: it was removed, because it was generating false positive, e.g. a non-degraded array was marked randomly as degraded even if it wasn't.
<xnox> loa: we do start them with no-degraded via udev scan/trigger, and if that fails start degraded, or else fall to udev.
<loa> xnox, can't understand what problem that array get marked as degraded.
<xnox> loa: if there is something not working as expected, please open a new bug.
<loa> xnox, i can't understnad if it is expacted or not.
<loa> xnox, can i describe again what i do and what happened?
<xnox> loa: e.g. in 12.04, with RAID1 with both drives always present, a few boots would come up into initramfs and fail to boot claiming that a drive is missing.... even though it isn't.
<xnox> which is a big problem for remote machines with no console access.
<loa> xnox, strange now i recieve totally another results.
<loa> for example i have ubuntu 14.04
<loa> i create raid 1 and remove one drive.
<xnox> it will boot degraded.
<loa> only one time.
<loa> if i reboot again it fallbacks to initramfs busybox
<loa> is it as expected?
<xnox> that's wrong, can you please open a bug report against mdadm about that?
<xnox> with $ ubuntu-bug mdadm
<xnox> if possible?
<loa> i will try.
<loa> xnox, problem that i am emulating this situation using virtualbox
<loa> maybe it is problem.
<loa> i will recieve real hardware on next week.
<loa> xnox, now i see that it is unstable. Sometimes it boots ok, but sometimes it drops into initramfs
<loa> maybe it is problem of virtualbox not ubuntu.
<michagogo> .whois bdmurray bdmurray
<michagogo> gah, wrong key -_-
<loa> xnox, https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/1341312
<ubottu> Ubuntu bug 1341312 in mdadm (Ubuntu) "System couldn't boot from degraded raid 1" [Undecided,New]
#ubuntu-devel 2015-07-06
<mwhudson> hmm
<mwhudson> are the gcc cross compilers built for all arches?
<mwhudson> e.g. can i install arm-linux-gnueabihf-gcc on arm64?
<wgrant> mwhudson: gcc-*-cross arm64 builds produce an arm-linux-gnueabi cross-compiler, yes.
<wgrant> (not all arches, though. powerpc has no cross-compilers, and ppc64el only has powerpc)
<mwhudson> wgrant: oh hm
<mwhudson> wgrant: E: Unable to locate package arm-linux-gnueabihf-gcc
<wgrant> mwhudson: You mean gcc-arm-linux-gnueabihf?
<wgrant> The binary and package names are not quite the same.
<mwhudson> wgrant: bah
<mwhudson> :-)
<mwhudson> hmm
<mwhudson> so which packages do i need to install to run armhf stuff on arm64
<lifeless> qemu-user ?
<lifeless> or possibly qemu-user-static
<lifeless> plus you'll need the userspace libraries etc if you're not running a full VM
<mwhudson> lifeless: err
<mwhudson> no, the cpu supports the 32 bit arm insns
<mwhudson> this is more like running ia32 on amd64
<lifeless> mwhudson: oh sorry, I read 'arm64' as 'amd64'
<lifeless> mwhudson: total fritzout
<mwhudson> :)
<mwhudson> so very easily done
<lifeless> so yeah in that case add the right multiarch
<lifeless> apt-get update
<mwhudson> (about the best argument that people should have used aarch64 like arm wanted)
<lifeless> and then install the thing you want
<lifeless> *I think*
<mwhudson> lifeless: seems plausible
<infinity> mwhudson: Shouldn't need to install anything at all, if you're doing it in an armhf chroot.  If not then, yes, you'd need to add armhf as a secondary arch and install whatever bits you want.
<mwhudson> hm porter-arm64 has a wily-armhf chroot but no vivid one
<mwhudson> guess that works
<mwhudson> infinity: thanks for the cluebat to look for that :)
<mwhudson> (wily-armhf)mwh@rugby:~/go/src$ ./trivial
<mwhudson> Segmentation fault (core dumped)
<mwhudson> progress!
<infinity> Sort of. :)
<infinity> libruntime,sync-atomic,math,runtime-cgo,sync.so
<infinity> That's quite the library name.
<mwhudson> shush you
<infinity> THAT'S QUITE THE LIBRARY NAME.
<pitti> Good morning
<pitti> infinity: config is /etc/systemd/timesyncd.conf
<mwhudson> uh huh does -Bsymbolic-functions on armhf only work with gold or something?
<pitti> infinity: see man timesyncd.conf
<pitti> infinity: merges> cool, thanks
* Noskcaj changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> vivid| #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
* Noskcaj changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -> vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<dholbach> good morning
<dholbach> @pilot in
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -> vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: dholbach
<ari-tczew> is it possible to get extra PPA or something with supported archs like ppc64el and arm64?
<ari-tczew> it would be much useful for patch testing
<cjwatson> ari-tczew: arm64 is possible, but only via qemu-user-static, which doesn't work on that well for a lot of things.  But we hope to be able to fix this very soon - a POWER-based builder cloud is almost working, and we have the hardware installed to do the same for ARM shortly afterwards
<ari-tczew> cjwatson: ok, assuming: no at this moment.
<cjwatson> indeed, unfortunately.  but there is hope.
<ari-tczew> that's already something
<cjwatson> I expect that within a small number of months both Ubuntu and (virtualised) PPAs will be building on the same infrastructure, and then it's easy.
<ari-tczew> cjwatson: will be arm64/ppc64el available for all PPA users or only for extra ask?
<cjwatson> ari-tczew: Initially, available on request.  Once we're confident in it we'll probably make the architecture selection self-service.
<cjwatson> Building just for x86 probably remains a reasonable default.
<ari-tczew> cjwatson: ok, thanks for the info
<hjd> Anyone have an idea what could cause the difference between Debian and Ubuntu, regarding bug 1471741?
<ubottu> bug 1471741 in frosted (Ubuntu) "frosted FTBFS ImportError: No module named builtins" [Undecided,New] https://launchpad.net/bugs/1471741
<jamespage> zyga, around? I'm debugging a test failure in django-testscenarios with new python-testtools in wily and the failures have me scratching my head
<jamespage> zyga, for context - https://jenkins.qa.ubuntu.com/job/wily-adt-django-testscenarios/lastBuild/ARCH=amd64,label=adt/console
<zyga> jamespage: re
<zyga> jamespage: yes
<zyga> jamespage: looking
<zyga> jamespage: that looks like assertions on how django manages transactions
<zyga> jamespage: perhaps new django has changed behavior there
<jamespage> zyga, well it was new testtools which triggers the failure - confirmed that
<zyga> jamespage: ah
<zyga> jamespage: ok, let me look again then
<jamespage> zyga, other problems I've seen where caused by testtools always using unittest2 as its base now
<jamespage> zyga, thankyou - much appreciated
<zyga> jamespage: how is that causing problems?
<jamespage> zyga, we had one issue where using unittest.skipTest was not working
<jamespage> zyga, that's probably not related to this
<zyga> jamespage: mm
<zyga> jamespage: unittest.skipTest or unittest2.skipTest?
<jamespage> zyga, https://bugs.launchpad.net/bugs/1467558
<ubottu> Ubuntu bug 1467558 in testtools "testtools.skip decorator not functional with unittest.TestCase as base class" [Undecided,New]
<jamespage> that's the bug
<zyga> ah
<zyga> I'm not using testtools anymore so I'm not up to date, let me see django-testscenarios first
<zyga> jamespage: hmm, so whatever is causing this
<zyga> jamespage: the tests fail because django constraints on how transaction tests are started don't work
<zyga> jamespage: that might be testscenarios or testscenarios + django-testscenarios
<zyga> jamespage: or all that + new django
<zyga> jamespage: how can I reproduce that?
<zyga> jamespage: wily?
<dholbach> @pilot out
* udevbot changed the topic of #ubuntu-devel to: Archive: wily open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of precise -> vivid | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
<doko> pitti, https://launchpadlibrarian.net/210709148/buildlog_ubuntu-trusty-amd64.python-apt_0.9.3.5ubuntu1_BUILDING.txt.gz  again changed proxy setup?
<pitti> doko: buildds are cjwatson and wgrant's domains, but I suppose it could be related to moving builds to scalingstack?
<pitti> doko: that certainly looks like a bad/missing $no_proxy
<jamespage> zyga, yeah - wily with testtools from proposed
<xpheres> hello
<xpheres> anyone has a ubuntu tablet or phone?
<xpheres> if so, please test my app https://uappexplorer.com/app/analyticaltranslatordemo.xpheresdev
<xpheres> there's no way I can make the emulator work
<cyphermox> good morning!
<cjwatson> pitti: that build isn't in scalingstack
<cjwatson> doko: there are no proxy-related environment variables set by the builder (see the "User Environment" section), so anything here must be set by the build itself
<mitya57> sil2100, hi, can I land appmenu-qt5 myself?
<sil2100> mitya57: hey! There's one more fix I want to target, but I'm not entirely done yet
<mitya57> Ok, no problem
<xpheres> does anyone knows if there are people working to fix the emulator?
<teward> xpheres: 'emulator'?
<xpheres> yes for ubuntu touch
<xpheres> I'm developing an app
<xpheres> but I have to do it blind
<xpheres> or asking for help to people who have ubuntu mobiles
<davmor2> xpheres: known issue it is being looked at but it is pretty low level stuff so might take a while to fix completely, ref emulator
<xpheres> a pitty
<xpheres> I won't work anymore with ubuntu apps till is fixed, I can not see the results and many weird stuff appears in the guy
<xpheres> gui sorry
<xpheres> and I can not afford an ubuntu phone right now
<cjwatson> pitti: still around?  we could use a ~techboard member to create a "15.04" series for us in ubuntu-rtm, status "Future" (won't be used for publishing, just for bug tracking)
<cjwatson> well, bugs and translations
<slangasek> cjwatson: I'm around fwiw
<cjwatson> slangasek: ah, you want to do the honours then?  should be straightforward on https://launchpad.net/ubuntu-rtm/+addseries if you agree with this work, we don't need the complex derived series initialisation here
<slangasek> cjwatson, pitti: https://launchpad.net/ubuntu-rtm/15.04 - status is currently 'future'
<slangasek> cjwatson: er, I mean 'experimental'
<cjwatson> I think either of those statuses is fine
<cjwatson> slangasek: could you do the same on qastaging?
<cjwatson> https://code.launchpad.net/~cjwatson/launchpad/phone-overlay-translations/+merge/263819 is the immediate driver for this FWIW
<slangasek> cjwatson: also done
<cjwatson> slangasek: thanks
<pitti> cjwatson: sorted now, right?
<cjwatson> pitti: Yep, thanks
<pitti> slangasek: do you have some minutes today to re-review https://code.launchpad.net/~pitti/britney/britney2-ubuntu-amqp/+merge/263679 ?
<pitti> slangasek: I have another branch with teh corresponding results collection, I did a run on britney with that
<pitti> this triggered 430 tests which the poor underpowered scalingstack is grinding through now, but that's a nice smoketest :)
<pitti> (I'll submit that MP after landing the AMQP bits)
 * pitti waves good night
<slangasek> pitti: yes, re-reviewed and merged.
<slangasek> pitti: are you ready for this to be rolled out to production, or do you want to be around for that?
<pitti> slangasek: thanks for reviewing!
<pitti> slangasek: should be fine, with the actual config files it should be a no-op
<pitti> slangasek: but please don't roll it out yet, as the current backlog is huge (see above)
<pitti> slangasek: I'd like to give it a day or two to settle down
<pitti> queues are at 340, from 430 from ~ 4 hours ago
<pitti> slangasek: err, sorry -- of course you can roll it out, it won't actually do requests until we set the amqp config option
<pitti> (but there's no hurry to do so)
<pitti> I'll get the swift MP ready tomorrow
<slangasek> pitti: ok; I'll roll it out all the same just so it's done
<ogra_> cjwatson, hmm, do seeds know about multiarch ?
 * ogra_ needs to seed libc:i386 into the amd64 snappy images somehow 
<ogra_> (or infinity ^^)
<cjwatson> ogra_: No
<ogra_> hmpf, k ...
<cjwatson> That is Hard (TM)
<ogra_> yeah ...
<cjwatson> Probably better to just force it in from livecd-rootfs
<ogra_> and i guess add-apt-package in live-build wont handle it either
<cjwatson> Or whatever
<cjwatson> Not sure, experiment :)
<cjwatson> (locally!)
<ogra_> haha
<ogra_> worst case i can make a metapackage that depends on it ... but i'd rather not
<gordon_> Hello! I initially came here to look for hire to get involved page but I guess I've found nice link in topic. https://wiki.ubuntu.com/HelpingWithBugs I will give something to fix and then ask again :)
<mterry> happyaron, hello!  I am looking at fcitx-unikey for main inclusion, and I happened to notice a small typo.  in debian/copyright, the first copyright stanza description should mention GPL 3 instead of GPL 2.  That's all!
<soee> hi, what kernel version is planned to be shipped with Wily ?
<sarnold> soee: looks like 4.0 or 4.1 https://lists.ubuntu.com/archives/ubuntu-devel/2015-May/038770.html
<soee> sarnold: ok, thank you for the information
<infinity> soee: I think 4.2 was the plan, actually.
<infinity> sarnold: ^
<sarnold> infinity: man I feel old
<soee> ;]
<cyphermox> zul: are you aware that tgt you merged a month ago is still in -proposed? I'd like to fix the test so it works properly, since it blocks other stuff, but I don't have anything to run proper testing of the pacakge
<mwhudson> hm, so i've gotten as far as installing enough bits on my arm64 system that i can run exectuables
<mwhudson> but how can i debug them?
<mwhudson> gdb says unhelpful things like
<mwhudson> warning: Selected architecture arm is not compatible with reported target architecture aarch64
<mwhudson> i guess i can just make a chroot
<zul> cyphermox: be my guest
<zul> cyphermox: ill take a look though
<infinity> adt-run [21:55:24]: test daemon: [-----------------------
<infinity> ERROR: tgtd IS NOT RUNNING
<infinity> adt-run [21:55:25]: test daemon: -----------------------]
<infinity> I can't think that needs much of a special setup to test why it's broken. :P
<infinity> And, indeed, installing tgt doesn't start it.
#ubuntu-devel 2015-07-07
<cyphermox> infinity: I know this isn't hard to verify or fix, but I want  to make sure it's actually doing something useful
<infinity> cyphermox: It's definitely finding a bug.
<cyphermox> tgtd's purpose is to find bugs?
<infinity> cyphermox: The daemon should be starting on install (and, indeed, can start manually), but isn't.
<cyphermox> I know
<infinity> cyphermox: No, autopkgtest's purpose is to find bugs. :P
<cyphermox> ;)
<infinity> Might be a bug in init-system-helpers or something.
<infinity> The postinst looks pretty boilerplate.
<cyphermox> looks like it might be that, yes
<infinity> Except we've had that same init-system-helpers code since vivid.
<infinity> (The merge, after the fixups, was a no-op)
<cyphermox> what changed is that now systemd
<infinity> Doesn't finish its sentences?
<pitti> Good morning
<pitti> slangasek: thanks; seems she is still doing her job
<gordon_> hmmm
<gordon_> wanted to fix some bugs
<gordon_> but seems like all of them are either not consistent
<gordon_> or from old versions / translations
<snkt> hiii
<snkt> can anyone help me how to remove all the packages from ubuntu 10.04.3 or else from where I can download ubuntu-core 10.04.3
<Noskcaj> snkt, The isos are at http://old-releases.ubuntu.com/releases/10.04.3/ if that's what you want
<snkt> Noskcaj, i want a minimal ubuntu of 10.04.3 without any application installed
<Noskcaj> I assume you could just mark everything for uninstallation in synaptic then unmark the stuff that comes with the ubuntu-desktop metapackage.
<Noskcaj> You could also use the mini iso then just install what you want from that
<TJ-> snkt: You can build such a configuration using deboostrap
<snkt> Noskcaj, TJ- , Thanks for your response...
<dholbach> good morning
<seb128> hey dholbach
<seb128> wgrant, hey, how is the wily translation opening going?
<wgrant> seb128: Need to schedule exports with pitti.
<seb128> pitti, ^
<pitti> wgrant: I suppose we can stop utopic cronjobs
<wgrant> pitti: Given that it dies in three weeks, quite possibly.
<pitti> wgrant: disabled on my end
<wgrant> pitti: Will switch them over on mine.
<wgrant> pitti: Do you recall the wiki page?
<pitti> wgrant: I curently run vivid on Tue, and trusty on Fri
<pitti> wgrant: https://dev.launchpad.net/Translations/LanguagePackSchedule
<pitti> oh dear, that's severely outdated
<wgrant> Hm, well that looks totally out of date
<wgrant> Yeha
<pitti> wgrant: so, drop all but trusty and vivid, add wily, and then I'll adjust my cronjobs accordingly?
<pitti> I need to do the first build manually, but I'll do that once it's on https://translations.launchpad.net/ubuntu/wily/+language-packs
<wgrant> pitti: Are we considering 14.09 dead?
<pitti> wgrant: AFAIK we completely updated to vivid+PPA
<wgrant> Great.
<pitti> and will probably move to rtm/15.04 for translations
<wgrant> We may need to add the new 15.04 series later, but we can get there.
<wgrant> Yep
<wgrant> pitti: I might stick wily in the precise slot, to avoid the weekend.
<pitti> wgrant: for releases, doing wily on Monday would be good
<wgrant> Ah, true.
<pitti> although..
<pitti> last time infinity wanted the langpacks done the week before already, i. e. Thu/Fri export would be better indeed
<pitti> and for the alphas it doesn't matter really
<pitti> wgrant: sorry about the confusion -- so wily on Thu sounds better
<pitti> (so that I can build on Fri)
<wgrant> http://paste.ubuntu.com/11834712/ -> http://paste.ubuntu.com/11834720/
<wgrant> diff: http://paste.ubuntu.com/11834721/
<wgrant> Looks sane?
<wgrant> trusty moves a day earlier.
<pitti> wgrant: ITYM "wily" in teh last line
<wgrant> Er yeah
<mardy> pitti: I guess that python-dbusmock cannot be used to mock methods which are implemented in the dbus daemon itself, right? (like "GetConnectionAppArmorSecurityContext")
<tjaalton> do trusty daily images get some sort of testing?
<pitti> mardy: I've never tried that; my gut feeling is "no", but maybe dbus/python-dbus do allow it
<pitti> wgrant: so, what's the final crontab now?
<mardy> pitti: ok, I might try then, thanks
<pitti> wgrant: nevermind, thanks for updating the wiki
<ricotz> mdeslaur, hi, there are new releases of nss/nspr which could get in to wily
<mdeslaur> ricotz: yes, there are
<ogra_> xnox, yo ... you didnt answer my question on bug 1323732
<ubottu> bug 1323732 in adduser (Ubuntu) "adduser should support managing additional password/shadow/group files from libnss-extrausers" [High,In progress] https://launchpad.net/bugs/1323732
<Unit193> https://bugs.debian.org/791661
<ubottu> Debian bug 791661 in shadow "support for alternative passwd location (i.e. libnss-extrausers)" [Wishlist,Open]
<ogra_> Unit193, hah, thanks ... that crazy mvo guy
<ogra_> (though that still doesnt answer my question if xnox' suggestion would work for us :) )
<Unit193> :)
<ChrisTownsend> pitti: Hey!  Any idea when the fix for https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1470060 will land in Wily?
<ubottu> Ubuntu bug 1470060 in systemd (Ubuntu) "[wily] unprivileged containers don't work any more due to missing cgroup permissions" [High,Fix committed]
<seb128> ChrisTownsend, is that the cause of your "can't start applications" issue?
<pitti> ChrisTownsend: upstream said they were going to release 222 today
<pitti> ChrisTownsend: I'm ready to package it (I have pkgs for current git snapshot)
<pitti> ChrisTownsend: so, hopefully today
<pitti> ChrisTownsend: if you need some working packages right now, please feel free to use https://launchpad.net/~pitti/+archive/ubuntu/systemd
<ChrisTownsend> seb128: It *might* be the issue for that, but it's also blocking some work I'm doing for the Lagacy X app support project I'm working on.
<ChrisTownsend> pitti: Cool, thanks!
<seb128> ChrisTownsend, was your issue from yesterday under a system using the lxc contained version of unity8?
<ChrisTownsend> seb128: No, it's the non LXC version on Wily.
<seb128> k, that doesn't explain that issue then
<ChrisTownsend> seb128: This is what is printed out in syslog when trying to start an app:
<ChrisTownsend> Jul  6 08:54:07 Slave1 cgmanager[802]: cgmanager:do_create_main: pid 3150 (uid 1000 gid 1000) may not create under /run/cgmanager/fs/freezer/user.slice
<ChrisTownsend> Jul  6 08:54:07 Slave1 cgmanager[802]: cgmanager:do_create_main: pid 3151 (uid 1000 gid 1000) may not create under /run/cgmanager/fs/freezer/user.slice
<ChrisTownsend> seb128: It seems it might be related, but I don't know these things, so I'm just guessing.
<seb128> yeah, unsure why other systems don't have the same issue
<ChrisTownsend> seb128: Right.  I'll try pitti's package and see what happens.
<pitti> ChrisTownsend: probably won't help; cgmanager is independent of sytsemd
<pitti> ChrisTownsend: oh, maybe it will, nevermind
<pitti> ChrisTownsend: if that's an unpriv LXC container that you are trying to trun
<pitti> run
<soee> can someone confirm if after (probably) kernel upgrade to 4.0 we can't now switch gpu on hybrid machine (intel + nvidia)?
<ChrisTownsend> pitti: Yeah, was just taking a stab in the dark.  I'm not very hopeful:)
<ChrisTownsend> seb128: \o/ It fixed my that issue!
<seb128> weird
<ChrisTownsend> seb128: It's weird that I'm the only one seeing that and that this fixes it.
<seb128> right
 * ChrisTownsend Shrugs
<seb128> unsure what triggers the issue/what is different in your config
<pitti> ChrisTownsend: "it" being the new version? or what?
<ChrisTownsend> seb128: No clue.
<ChrisTownsend> pitti: So the issue I had was that apps in Unity 8 dekstop wouldn't start due to the error I pasted above.
<ChrisTownsend> pitti: You systemd PPA fixes this issue for me.
<ChrisTownsend> pitti: No LXC's invlolved.
<pitti> ChrisTownsend: nice! so it's the same cgroup issue then, cgmanager wants to create sub-cgroups for your session as your user
<seb128> pitti, what is weird is that others don't hit that issue
<pitti> yeah, it's a race condition
<seb128> oh, ok
<pitti> cat /proc/self/cgroup
<ChrisTownsend> Oh...my computer is blazing fast I guess:)
<pitti> if they all end with session-XX.scope, it's correct, but you might have some controllers which are just in the top-level (or some intermediate) hierarchy
<ChrisTownsend> pitti: And to confirm, my unprivileged lxc's now start.
<ChrisTownsend> pitti: Thanks!
<pitti> yw!
<pitti> I wrote an autopkgtest now, so hopefully we'll stop breaking the unpriv lxc support
<pitti> it's a distro patch, so it needs to be adjusted to behaviour changes in upstream
<ChrisTownsend> pitti: That will be a very welcome test:)
<ChrisTownsend> pitti: Hey again.  Seems Reboot/Shutdown from the power indicator are no longer working w/ the systemd from your PPA.  Is this known?
<ChrisTownsend> pitti: This is Unity7.
<pitti> ChrisTownsend: not known, no; let me try
<ChrisTownsend> pitti: Ok.
<ChrisTownsend> pitti: Hmm, in my syslog, gnome-session is complaining about needing interactive authentication for those operations.
<pitti> ChrisTownsend: works fine here
<pitti> ChrisTownsend: so it probably means you don't have a "local" logind session
<pitti> ChrisTownsend: do you mind filing a bug with "loginctl" and "loginctl show-session $XDG_SESSION_ID" outputs?
<ChrisTownsend> pitti: Hmm, wonder how I got into that state.
<ChrisTownsend> pitti: Sure, I can file the bug.
<ChrisTownsend> pitti: That bug should be filed against the systemd package, right?
<pitti> ChrisTownsend: yes
<ChrisTownsend> pitti: ack
<ChrisTownsend> pitti: Ok, filed bug #1472259.  Let me know if you need any other info.
<ubottu> bug 1472259 in systemd (Ubuntu) "Quirky session behavior w/ systemd from ppa:pitti/systemd" [Undecided,New] https://launchpad.net/bugs/1472259
<pitti> ChrisTownsend: just to be sure, that's from a clean boot?
<ChrisTownsend> pitti: Yes
<pitti> State=closing
<pitti> so, odd indeed
<ChrisTownsend> pitti: Shall I purge your PPA just to be sure?
<pitti> ChrisTownsend: oh, is that *after* you requested a shutdown?
<ChrisTownsend> pitti: Oh, right, I requested it.
<pitti> ChrisTownsend: that would explain the "closing"
<pitti> ChrisTownsend: ok, so that part is right; it seems some process is hanging in your session then
<pitti> ChrisTownsend: does it shut down after 90s?
<ChrisTownsend> pitti: No, it doesn't.
<pitti> ChrisTownsend: can you please attach the output of "journalctl" there too, for completeness?
<ChrisTownsend> pitti: I can reboot and get those outputs before issuing any shutdown or reboot.
<ChrisTownsend> pitti: Sure.
<pitti> ChrisTownsend: after issuing shutdown is fine
<pitti> ChrisTownsend: and even necessary -- as that's when the bug happens
<ChrisTownsend> pitti: Ok, attached the output of journalctl.
<pitti> ChrisTownsend: I suppose "loginctl terminate-session $XDG_SESSION_ID" also doesn't do anything?
<ChrisTownsend> pitti: Says "Failed to issue method call: Access denied"
<pitti> ChrisTownsend: right, sorry, with sudo
<ChrisTownsend> pitti: I should have known that:)
<ChrisTownsend> pitti: Nothing happens
<pitti> ChrisTownsend: hm, no immediate idea yet, I'm afraid; could you reboot with "debug" in the kernel command line, (try to) shut down again, and again attach "journalctl"?
<ChrisTownsend> pitti: Yep, will do.
<pitti> ChrisTownsend: I'm assuming that you only upgraded systemd, nothing else?
<pitti> ChrisTownsend: thanks
<pitti> slangasek: will we have a TB today, or do we cancel it (as agreed last meeting, when there are no topics)?
<ChrisTownsend> pitti: A couple of other packages that don't look relevant were upgraded too.  However, the new 4.0 kernel was installed, and the first reboot I tried after running the 4.0 kernel was after I installed systemd.  After I get this output, I'll purge your ppa and see what happens.
<pitti> ChrisTownsend: cheers
<ChrisTownsend> pitti: After purging your PPA, I can reboot/shutdown again.
<pitti> ChrisTownsend: ok; let's see whether the debug log reveals anything
<ChrisTownsend> pitti: Ok.  I attached it to the bug.
<pitti> Jul 07 09:28:32 Slave1 gnome-session[1850]: gnome-session[1850]: WARNING: Shutdown failed: GDBus.Error:org.freedesktop.DBus.Error.InteractiveAuthorizationRequired: Interactive authentication required.
<pitti> ok, that again
<pitti> ChrisTownsend: err, wait, this looks *seriously* wrong:
<pitti>         c1 110 lightdm seat0
<pitti>          1 1000 townsend
<ChrisTownsend> pitti: Yeah, I thought that didn't look right.
<pitti> ChrisTownsend: that means lightdm has the "foreground" session, and your XDG_SESSION_ID is c1
<pitti> and "your" session is a remote one "1"
<pitti> ChrisTownsend: does that also look like that if you boot with wily's systemd?
<ChrisTownsend> pitti: Nope, it only lists my user as c2 and seat0.
<pitti> that sounds correct then
<pitti> ChrisTownsend: hm, need to think about thsi
<ChrisTownsend> pitti: Sure.  Let me know if I can gather any more data or anything else to try.
<ChrisTownsend> pitti: Thanks!
<seb128> stgraber, hey, http://iso.qa.ubuntu.com/ is down/503, known issue?
<teward> seb128: there was a 'downtime' notice email earlier today
<teward> it went out over the -quality mailing list
<teward> https://lists.ubuntu.com/archives/ubuntu-quality/2015-July/006051.html
<seb128> teward, thanks
<teward> you're welcoem
<smoser> cyphermox, https://bugs.launchpad.net/maas/+bug/1402042
<ubottu> Ubuntu bug 1402042 in MAAS trunk "console= parameters need to be added before -- on kernel cmdline" [High,Triaged]
<smoser> will that be sru'd to trusty ?
<smoser> if not, any suggestions on how maas should know which token to use (--- or --) would be appreciated.
<smoser> also would have to sru to precise installers.
<smoser> :-(
<cyphermox> the token change is already in the releases it should be. do you need to completely rewrite a command-line or can you append to it?
<cyphermox> appending should be safe, things *should* (but it would be best to verify) already have the trailing separator
<smoser> cyphermox, well, the problem is that maas now needs to behave differently based on the release it is installing
<smoser> which it previoulsy did not do.
<smoser> so i'd like to be able to throw '---' at everything and have the installers dtrt
<cyphermox> I think it will, but I'm not certain
<cyphermox> ie. --- on a -- release, you'll just get an extra token that preseed doesn't understand, and it shouldn't make it give up
<cjwatson> the worst case there is that it won't be appended to the boot config in the installed system
<smoser> right. thats what i care about.
<smoser> i need it copied over to the installed system. otherwise i'd not be putting a '--' there at all.
<cjwatson> but actually, I don't think even that's a problem
<cyphermox> t just depends what debconf key it is
<smoser> i dont care about debconf keys
<smoser> i care about kernel command line args
<smoser> ie if i boot installer as:
<cyphermox> hum, then I think you do need to have the separator
<smoser>   somearg root=someplace arg2 -- foo=bar zee wark
<cyphermox> yeah
<smoser> i need 'foo=bar zee wark' copied over to install system
<cyphermox> smoser: give me a minute I'll look at preseed and whatnot
<cjwatson> ah, right, yeah, valid separator is required.  but it should be fine as long as you're definitely picking up SRUed installers
<smoser> so the installars have been sru'd then ?
<cjwatson> hm, checking
<cjwatson> doesn't look like it, in fact.  they really ought to be, because kernel backports
<smoser> right.
<cjwatson> affects anything from 3.15 on
<smoser> right.
<cjwatson> so IMO we should SRU debian-installer-utils to precise/trusty/utopic, then that'd be picked up by the next d-i SRU
<cjwatson> the patch accepts either separator so is safe
<smoser> right.
<smoser> so i'll just make bug 1402042 affects debian-installer-utils ?
<ubottu> bug 1402042 in MAAS trunk "console= parameters need to be added before -- on kernel cmdline" [High,Triaged] https://launchpad.net/bugs/1402042
<smoser> maybe change the bug title.. or i can file another.
<smoser> cjwatson, what package to affect ?
<mdeslaur> stgraber: do we have a tech board meeting today?
<smoser> got it. (was confused when apt-cache didn't know about debian-installer-utils)
<stgraber> mdeslaur: not sure, I was planning on joining the channel and see if people were there :) according to the wiki it's slangasek's time to chair
<mdeslaur> stgraber: oh! I misread the wiki and though it was you
<slangasek> ah, well I'm planning to be there :)
<slangasek> infinity kees pitti: TB meeting in 7 minutes :)
<pitti> slangasek: ack
<cjwatson> smoser: yeah, apt-cache show won't tell you about udebs, but apt-cache showsrc would have done
<cjwatson> debian-installer-utils, indeed
<hjd> Hm... sqlalchemy in Wily-proposed failed to build on amd64 because it didn't find python-zzzeeksphinx (https://launchpad.net/ubuntu/+source/sqlalchemy/1.0.6+ds1-1/+build/7577027). But sqlalchemy built successful on all other architectures (https://launchpad.net/ubuntu/+source/sqlalchemy) even though zzzeek-sphinx is only available on amd64 (https://launchpad.net/ubuntu/+source/zzzeeksphinx).
<snow_ru> hi
<hjd> I'm confused why it would fail on one architecture, but not the others. Am I missing something here?
<snow_ru> hi all
<snow_ru> i don't know if this bug is fixed
<snow_ru> so I come here
<cjwatson> hjd: your premises are wrong in two ways :-)
<snow_ru> sudo apt-get install python-pip
<snow_ru> The following packages have unmet dependencies:
<snow_ru>  python-pip : Depends: python-pip-whl (= 1.5.4-1ubuntu3) but it is not going to be installed
<snow_ru> Recommends: python-dev-all (>= 2.6) but it is not installable
<cjwatson> hjd: firstly, python-zzzeeksphinx is available on all architectures - it's just only built on amd64, because it's architecture-independent
<snow_ru> Recommends: python-wheel but it is not installable E: Unable to correct problems, you have held broken packages.
<snow_ru> thanks !
<cjwatson> hjd: secondly, the reason this only failed on amd64 is that it's listed in Build-Depends-Indep, which is only considered on amd64 (as of vivid)
<snow_ru> I saw on lauchpad that htis bug has been fixed a couple of weeks ago, but it stll happens on my machine
<cjwatson> hjd: finally, the reason it failed at all is that sqlalchemy is in main, but python-zzzeeksphinx is in universe
<cjwatson> it requires a main inclusion report for zzzeeksphinx if that build-dep is going to stay there
<pitti> . o O { can we reject MIRs on the grounds of "silly/unpronouncible package name"? }
<hjd> cjwatson: Ah, ok. "python-zzzeeksphinx is available on all architectures" That makes sense, I should probably have guessed/checked that since it's a python package.
<hjd> cjwatson: Didn't check main vs universe though.
<hjd> cjwatson: I'm reading about Build-Depends-Indep, but I'm not sure if I understood it correctly. They are dependencies which are used to create architecture independent packages (https://wiki.debian.org/Build-Depends-Indep), but they are only fetched for a particular architecture? Is it simply that the architecture independent binary packages are built once (because once for each arch would simply create duplicates) and the architecture
<hjd> where they are built happen to be amd64?
<cjwatson> hjd: as you say.
<hjd> ok :)
<cjwatson> though not "happens", it's specifically configured that way.
<cjwatson> used to be i386, but amd64 is a better default nowadays, so that's what's used from vivid on.
<pitti> ChrisTownsend: ah, nice! http://lists.freedesktop.org/archives/systemd-devel/2015-July/033464.html
<snow_ru> ok.
<snow_ru> wgrant, ?
<snow_ru> wgrant, https://bugs.launchpad.net/ubuntu/+source/python-pip/+bug/1468155
<ubottu> Ubuntu bug 1468155 in python-pip (Ubuntu) "unable to install python-pip (1.5.4-1ubuntu3). python-dev-all not installable" [Critical,Fix released]
<arges> is there a bug for fixing /etc/network/interfaces to somehow match the interface name that systemd sets up in wily?
<pitti> arges: no, and we don't plan on doing this on upgrades; upgrades won't use the new names
<pitti> arges: it's not just /e/n/i, it's also firewall configs and an unknown amont of other places where admins might rely on the old names, so this is essentially not upgradeable automatically
<arges> pitti: so here's my problem. I install wily using the daily iso. When I boot the machine /etc/network/interfaces doesn't match what ifconfig -a shows me
<pitti> there's a manual procedure in /usr/share/doc/udev/README.Debian
<arges> so i don't have networking until I type in the name manually into /etc/network/interfaces
<arges> (this is server only obviously)
<pitti> arges: ah, so apparently you found a case where the installer hardcodes eth0, or there's something wrong with the udev-udeb
<pitti> arges: would you mind filing a bug with the details how you installed, your /e/n/i, and the installer logs?
<arges> pitti: the testcase is: install wily ubuntu-server
<arges> pitti: what does /e/n/i mean?
<pitti> arges: against systemd should do for now, I can reassign it to d-i or wherever appropriate
<pitti> arges: /etc/network/interfaces
<arges> pitti: ah! make sense
<arges> pitti: yup, I figured I'd check if this was a 'known issue' first
<arges> i'Ll file the bug
<pitti> arges: not that I know of
<pitti> arges: cheers!
<pitti> ChrisTownsend: I asked for another log in the bug, if you have time
<teward> pitti: can I pick your brain for a moment?  NOt sure if I did before.
<teward> when you have a minute :)
<nemo> So we have pretty good maintainers of the ubuntu packages these days for Hedgewars.  Locutus is very diligent w/ backports
<nemo> and even obscurish stuff like arm and testing our C cross-compile...
<nemo> the issue is that ubuntu does not make upgrading to backports terribly discoverable for users
<nemo> today 'cause I was a bit more attentive, I ran into 3 users over the course of 2 hours on our server using 0.9.20 - the version released in 2014
<nemo> none of them could play other users, so were just a bit frustrated at the lack of rooms.
 * ogra_ lols about "obscurish stuff like arm" ... 
<nemo> ogra_: heh. well... if we actually had a functioning mobile port
<ogra_> nemo, we sell phones with ubuntu on it
<nemo> ogra_: there aren't a ton of arm desktops. chromebook, but unfortunately graphics accel on chromebook sucks
<ogra_> what arch do you think they are ;)
<nemo> ogra_: I know... I keep meaning to try ubuntu mobile on my nexus 5
<nemo> ogra_: just noting our phone situation isn't great
<ogra_> its young ...
<nemo> ogra_: not totally sure the touch integration is even compiled in that package
<nemo> so from our perspective, arm is kind of obscure âº
<nemo> anyway...
<nemo> so.. I get why backports is not so discoverable for users. you don't want people accidentally breaking key system packages
<nemo> but... hedgewars is pretty much the opposite of that. broken without upgrading, and not a key package, in fact, pretty isolated.
<nemo> is there, by any chance, some flag to request "auto upgrade" for a package? that is, recommend upgrade if backports is enabled?
<gordon_> Wish to try Ubuntu touch on nexus 6
<nemo> gordon_: is that directed at me? don't have a nexus 6, don't plan to ever buy one
<gordon_> No, not to you
<nemo> seems barely worth the price now after the price cut, and pissed off at lack of replaceable battery or minisd
<nemo> ok
<gordon_> I have nexus 6 ;)
<nemo> *microsd
<gordon_> And can day that it's nice
<nemo> if there is such a flag, I could ask locutus to enable it on our package, to cut down on this annoying fact that 6 months after latest release we still get a steady stream of confused ubuntu users
<nemo> well. more like a trickle. windows *is* the dominant platform :-/
<nemo> and OSX isn't a problem w/ upgrading
<cjwatson> nemo: no such server-side flag for backports.  If it's broken without upgrading, though, then it should probably be updated as an SRU, in -updates; this fits the same kind of conditions as https://lists.ubuntu.com/archives/ubuntu-devel-announce/2009-March/000550.html
<nemo> cjwatson: I'd be all for that
<nemo> we had some success w/ that in the past I think
<nemo> but it has been very hit or miss
<cjwatson> backports isn't meant to be a way to deal with a package that's just outright broken in the release pocket due to external changes
<nemo> cjwatson: the issue is that it isn't *broken* just online play won't work against the official release version
<nemo> cjwatson: since we are using a similar approach to, oh, Spring
<cjwatson> well, that's an important piece of broken functionality
<nemo> that is deterministic lockstep gaming
<slangasek> pitti: cyphermox just brought to my attention a previously unknown (to me) corner case in proposed-migration: multipath-tools is blocked in -proposed by a buggy test in lava-dispatcher, and it looks to me that this test is buggy in the version of l-d in -proposed but not in wily.  Could p-m somehow handle this case automatically?
<nemo> cjwatson: alright. I'll talk to locutus to see if he can switch to that approach in the future
<cjwatson> I appreciate that going through the SRU process can take a while, but it's the best thing to do here
<nemo> cjwatson: definitely getting tired of explaining this to ubuntu users âº
<nemo> cjwatson: well. I wouldn't be the one doing it ð
<nemo> cjwatson: deterministic lockstep isn't unusual in open source gaming. helps cut down on cheating, nice lightweight network communication.. I wonder if other games have a similar issue
<nemo> even if they aren't doing that, can be missing key resources and such
<nemo> cjwatson: it'd be nice if you guys could carve out a category for games
<nemo> they are almost always not system critical, and usually people want to be on the latest hotness
<nemo> only issue is dependencies ofc.
<cjwatson> You could reasonably bring that to the techboard (which no longer includes me) as a suggestion, I imagine
<nemo> ah
<cjwatson> hedgewars in particular may be non-trivial because it's Haskell, and Haskell updates can be exciting
<nemo> well. if #ubuntu-devel has such folks, consider it brought up ð
<cjwatson> I don't know how much updates to hedgewars require updates to the libraries it uses
<nemo> cjwatson: wellll you guys could drop the server piece for all I care âº
<cjwatson> I expect that would be a harder sell
<cjwatson> Dropping functionality in SRUs usually involves a whole lot more discussion
<cjwatson> Anyway, it doesn't seem to have particularly tightly versioned libghc-*-dev build-deps, so that part is probably not a problem
<nemo> agreed on haskell thing tho.  but luckily unc0rr doesn't add new haskell dependencies as often anymore
<nemo> he's been kinda burned out w/ being a dad, like me âº
<cjwatson> It's only a problem for things that like to force latest version of everything
<nemo> ogra_: hm... do you have an ubuntu phone?
<ogra_> nemo, several :)
<ogra_> (i used to work on the phone team(
<nemo> ogra_: are you guys by any chance building hedgewars for the phone w/ MOBILE enabled?
<ogra_> nemo, the phone community hides in #ubuntu-touch btw
<nemo> ogra_: I think we have the phone-friendly UI and touch events hidden behind that flag
<nemo> ah
<nemo> might have to drop by
<nemo> ogra_: our android and iOS ports have languished
<ogra_> well, we dont rebuild any packages usually ...
<nemo> but the MOBILE stuff is still in the source, and I'm curious if it is turned on/functioning
<nemo> could ask someone to test it
<nemo> ogra_: ah... I guess no then
<ogra_> so yeah, test it ... but it would likely need some packaging work to not break the desktop version of the package
<nemo> ogra_: definitely mobile UI is totally different from desktop
<ogra_> right ...
<nemo> but the android/iOS guys put fair amount of effort into it years ago, and in a platform generic fashion
<nemo> if someone over there was willing to try a test build of an ubuntu mobile package, we might finally have a functioning mobile port again âº
<nemo> might be as easy as taking existing ubuntu package and enabling that build flag. maybe.
<nemo> well. the frontend would not be as mobile friendly, but that's less critical than gameplay
<snow_ru> hi MasterPiece
<snow_ru> how areyou ?
#ubuntu-devel 2015-07-08
<maslen> Hey, I'm a new maintainer for aircrack-ng, and want to try 'baking in' support for as many of the hardening features as possible.  Right now I'm working on squashing some bugs, but I was thinking about making an option for a 'hardened' build in the makefile and an apparmor profile. Are there any guides on best how to do that?
<sarnold> maslen: the hardening-includes package includes a hardening-check tool that you could use to see if aircrack-ng is already hardened by the toolchain
<sarnold> maslen: for an apparmor profile, you can use dh_apparmor to help install a profile; I think the mysql-5.6 source package includes an example, probably cups does as well
<maslen> Is there any standard place to put it?
<maslen> (or way to name it?)
<sarnold> the apparmor profile should wind up in e.g. /etc/apparmor.d/usr.bin.aircrack-ng if you're confident that it will work for most users
<maslen> got it. I wasn't sure if there was some other way to do it, that would take advantage of a custom installpath
<maslen> just creating a directory called 'apparmor' should be sufficient?
<sarnold> sorry, I've never added dh_apparmor to a package myself, I'm not sure what the details are
<cjwatson> barry: Is it a bug that "from lazr.delegates import Passthrough" stopped working as of the Python 3 port you did, even under Python 2?  lazr.restful was using that, but apparently now has to use "from lazr.delegates._passthrough import Passthrough" (which seems wrong) or port to something else.  I'm wondering if it would make more sense to export that directly from lazr.delegates again.
<cjwatson> barry: Noticed when finding that "pip install lazr.restful" (don't ask why, I'm multiple levels deep in yak-shaving) gives me a thing I can't import.
<cjwatson> barry: Or is this internal machinery that lazr.restful has no business meddling in?
<barry> cjwatson: gosh, i haven't looked at that in a long while.  looking at the usage.rst, i'm not sure that l.d.Passthrough was ever considered a public api, though i guess if lazr.restful was using it, that was maybe just an omission.  if it was a byproduct of the py3 port, i suppose we should say it's a bug
<barry> cjwatson: ah
<cjwatson> I don't really understand this layer well enough to have a strong opinion on which direction the fix should go in, I just know it's busted :)
<cjwatson> (somewhere)
<barry> cjwatson: so i think this was a byproduct of lazr.delegates._passthrough.Passthrough being imported by lazr/delegates/delegates.py and l/d/__init__.py doing a `from lazr.delegates._delegates import *`
<barry> which did get lost in the py3 port
<barry> so it probably worked accidentally
<cjwatson> Yes.
<barry> probably best to just explicitly import it in the __init__.py
<cjwatson> That was my thought, if you think it's reasonable to effectively make it quasi-public again.
<barry> i guess if l.restful uses it, we should restore its undocumented queasy, er, quasi nature.  can you file a bug?  i can probably turn this around and release + upload a new version tomorrow
<barry> cjwatson: okay if it's just to unstable/wily? or do we need an sru to some earlier release?
<infinity> barry: How far back was it broken like this?
<cjwatson> barry: https://bugs.launchpad.net/lazr.delegates/+bug/1472456
<ubottu> Ubuntu bug 1472456 in lazr.delegates "lazr.delegates no longer exports Passthrough" [Undecided,New]
 * barry looks
<infinity> If a public interface is going to disappear and reappear, I'd rather it reappear everywhere we support.
<cjwatson> barry: I hadn't even looked at the packaged version, I was just going from pip
<cjwatson> barry: lazr.restful isn't packaged so my care factor is limited in that regard
<cjwatson> oh wait, it is
<infinity> Of course it is.
<cjwatson> So I don't personally care because LP deploys it in other ways, but the package is probably broken
<infinity> And installed on many, many machines.
<cjwatson> infinity: That's lazr.restfulclient.
<cjwatson> lazr.restful is the server sied.
<infinity> Oh.
<cjwatson> *side
<infinity> dpkg -l handily cut it off at just the right point to make me look silly. ;)
<cjwatson> I'm rather surprised it's packaged, and probably nothing uses it, but ...
<barry> probably broke in upstream version 2.0 (2013-01-10) which introduced the py3 port.  and the first debian version is 2.0.1 so it's probably been broken in debian/ubuntu forever
<cjwatson> Indeed.
<infinity> barry: Oh, if it was always "broken" in Debian/Ubuntu, then there's no regression.  You win!
<barry> \o/
<cjwatson> Well, just Ubuntu.  lazr.restful isn't in Debian at all.
<barry> tbh, i don't really care about much of the lazr stuff, except lazr.smtptest
<barry> oh, and lazr.config
<infinity> Err, I'm super confused.
<infinity> Is lazr.restful in the archive not the same thing?
<infinity> Cause those versions don't align at all with what you said. :P
<barry> infinity: above was for lazr.delegates
<barry> lazr.restful is just a client of that
<infinity> Oh.
<infinity> I'm not awake enough to do things like read.
<barry> where's sinzui when you need him?
<infinity> barry: Though, you're still wrong about the "first Ubuntu version", then.
<infinity>  lazr.delegates | 1.1.0-0ubuntu2 | precise/universe | source
<infinity>  lazr.delegates | 1.2.0-0ubuntu3 | trusty/universe  | source
<infinity>  lazr.delegates | 2.0.1-1        | utopic/universe  | source
<infinity> Which implies this would have regressed in >= utopic.
<barry> oh hahaha.  i was looking at the svn repo for the debian package
<barry> infinity: do people still use utopic? <wink>
<infinity> And given that restful is packages all the way back to precise, I assume it regressed in >= U.
<infinity> Of course, if no one's noticed, that's also telling.
<barry> indeed
<barry> i think cjwatson is the only one using it
<infinity> barry: Dunno, but U and V ship the same version, so SRU to U and I'll copy-with-binaries to V.
<barry> should be easy enough
<barry> anyway, eod
<pitti> Good morning
<pitti> teward: here now
<pitti> slangasek: yes, I think we can handle that much more easily with the new code, now that I understand it
<pitti> slangasek: right now we indeed require that all tests succeed in unstable (in britney terms, i. e. in -proposed)
<pitti> slangasek: we would mostly need to set up a VM with apt pinning so that when it runs the multipath-tools induced tests with the non-proposed lava-dispatcher
<pitti> and specify that "version constraint" in the AMQP request and re-run the test after it regressed in proposed
<pitti> slangasek: still a lot of work, but at least possible
<infinity> rbasak: Around yet?
<infinity> pitti: Running test for both testing and unstable would complicate britney a fair bit.
<infinity> pitti: Since, yes, if we're migrating only A, we don't care if B in unstable is failing, but if we're migrating both, we sure do.
<pitti> right
<infinity> pitti: And our test against tests comes before we know what will and won't migrate together.
<pitti> infinity: it helps that we don't just "run test foo-1", we track that we test foo-1 *for* bar-2
<infinity> pitti: Perhaps that's the solution (and has other nice side effects), which is that we should be testing autopkgtest state between the installibility/hint phase and the final SUCCESS/copy.
<pitti> infinity: so if bar-2 is failing, but bar-1 succeeds, we cuold still promote foo-2 if that succeeds against bar-1, but we'd hold back bar-2
<infinity> pitti: That has the nice side effect that a busted test wouldn't hide progress of a transition or a large block hint, like it does today.
<pitti> infinity: oh, I thought it would already run that after the installable test
<pitti> at least we don't even trigger tests any more if the package isn't even installable
<infinity> pitti: autopkgtest happens in the update_exuses stage, which is before all the cool stuff in update_output happens.
<pitti> ah, this one
<infinity> pitti: There are two installable checks. :P
<infinity> pitti: One for individual packages, one for migrated state.
<infinity> pitti: So, *triggering* the tests when we do is right and shouldn't change, but *checking* state should probably actually happen very last, right before we'd pass/fail on promoting.
<pitti> so we wouldn't even start running tests until a transition is completed
<pitti> and only then learn about regressions -- not exactly ideal either
<pitti> ah, I see
<infinity> pitti: Nah, re-read.
<infinity> Yeah. :)
<infinity> We can still have the output on excuses for nice vivisibility and parsing, but not actually act on it there.
<infinity> We'd act when we're about to commit a complete run, so we can see what's moving together, and use the right tuples.
<infinity> foo_1 against bar_4, etc.
<infinity> But this does mean running every test twice. :/
<infinity> And a lot of failures on the "test against testing" test, when a transition is in play.
<infinity> No ideal.
<pitti> against testing? that's the bit I didn't get
<pitti> I thought we'd continue to run everything against unstable
<pitti> we'd re-trigger reverse depends as usual if you upload another piece of a transition
<infinity> pitti: Well, no, we'd want to test everything twice, right?
<pitti> do we?
<infinity> pitti: Okay, well, look at Steve's complaint.  foo_2 and bar_2 both get uploaded.  bar_2 doesn't work right, but foo_2 works fine in the context of testing.
<infinity> pitti: We can only know that if both are tested in isolation against testing, and then testing against full unstable.
<infinity> s/testing/tested/
<pitti> ah, for that
<infinity> Err, where that belongs.
<pitti> so that's unrelated to moving the evaluation of results until after the second install check stage
<infinity> So, yeah.  It explodes the test matrix a bit, and makes britney's promotion decision a bit harder.
<pitti> and it might cause a lot of failed tests due to uninstallablility if you can't install teh new source's binaries in isolation, but that'd be okay
<infinity> pitti: Well, they relate because once we have both sets of results, the only place we can reliably use them is in the last britney stage.
<infinity> pitti: Since I don't know which result I care about until I'm there.
<infinity> ie: if I intend to promote one package, I care how it works with testing, while if I intend to promote 3 packages, I care how they work with each other.
<infinity> (if they interdepend)
<infinity> pitti: It makes the bold assumption that if an rdep failure is isolated to unstable, it's the rdep's fault, not the new dep.
<infinity> pitti: Which is probably 99% true, but not always.
<infinity> pitti: I dunno.  I think it's something we could do better, but I think human intervention is sort of working for now, and this sound painful to do perfectly.
<pitti> well, in some cases it's part of a transition, and then it's fine to keep it in unstable
<pitti> infinity: I read a lot of the current britney code recently; mostly the bits that directly interact with autopkgtest, I'm not yet familiar with the installability checks
<pitti> infinity: anyway, I think I'll be more happy to think about this once we finish simplifying the autopkgtest stuff and moving it to the cloud
<infinity> pitti: The installability checks are, actually, pretty simple, by necessity, since they're super duper quadratic and can't be complex. :P
<infinity> pitti: Basically, attempt to promote source package, check if there are more or fewer uninstallable packages in testing as a result, if fewer win, if more, fail.  And then the autohinter that tries to match up things with deps on each other to batch attempt, and same check.
 * pitti currently looks at a first excuses.html that contains both the old and the cloud test results, after a day of running 500 autopkgtests; looks fairly ok
<pitti> I'm surprised that the machinery survived these 500 tests without much hiccup :)
 * pitti pats scalingstack
<infinity> Which region?
<pitti> RegionOne
<pitti> (lcy01)
<pitti> I haven't tried lgw01 yet (uh, this is also called "RegionOne")
<pitti> infinity: how do you usually handle britney merges? https://code.launchpad.net/~pitti/britney/britney2-ubuntu-amqp/+merge/264047 is a followup of the first amqp MP (Steve reviewed/merged that)
<pitti> infinity: i. e. is it generally okay to push such followup merges myself, or better to do a four-eyes principle?
<infinity> pitti: To be fair, until very recently, we've never really had merges to handle, so I dunno how we handle them. :P
<infinity> pitti: Colin and I sort of just committed directly for most of our stuff.
<pitti> oh? there were a fair bunch for the original adt-britney ones, then boottest, etc.
<infinity> pitti: If you're willing to babysit the logs and make sure your stuff is happy, direct committing is fine.  If you're relying on the infra to fail gracefully and planning to commit and run, then please no.  And if you just want a review because you think it's a good idea (or because the change is largeish), a review would be good.
<infinity> pitti: Yeah, true, there were for adt and boottest, Colin did all of those, and I assume it was all reviewed and merged by him, since the other parties wouldn't have had commit.
<pitti> infinity: nah, I have a checkout of my branch on snakefruit to run britney there (partial copy of data/), no hit'n'run :)
<pitti> infinity: so, my gut feeling is that the initial MP was good for four-eyes, I shoudl push these followup fixes directly, and do an MP again for the "get results from swift" bits
<infinity> pitti: Sure.  I have no issues with direct commits if they come with commitment.
<pitti> right now it's all a practical no-op as AMQP isn't yet enabled in the production checkout
<pitti> infinity: of course; okay, thanks
<infinity> pitti: Worst case scenario, you notice it explodes and you revert.  *shrug*
<pitti> right
<infinity> pitti: Thankfully, I've never met a britney failure mode where it screws everything up and then decides to promote everything.
<pitti> infinity: or it promotes everythign in -proposed :)
<pitti> hah
<infinity> Oh, except when we open a new series and intentionally disable adt for a few days. :P
<infinity> Hopefully with your new setup, we can fix that lag.
<pitti> we now have an infinitely large cloud to do that!
<pitti> *cough*
<infinity> pitti: It's not the workers that were the lag, it was the setting up all the jenkins jobs, etc.
 * pitti defines 10 == â
<pitti> infinity: oh dear, I want that stuff to die
<infinity> pitti: Hoping the new setup makes it more of an "add new release to a config file and watch it function" thing.
<pitti> infinity: well, it's still some manual work as we don't have cloud images from day 1
<infinity> Well, and "hack in temp cloud image".
<pitti> right
<pitti> but that's pretty much it
<infinity> Sure, but a vivid cloud image with fixed sources.list is a wily cloud image. :)
<infinity> (same story for buildd chroots)
<infinity> Actually, buildd chroots are even easier, since lp-buildd writes sources.list at runtime, so it can literally be the same tarball.
<pitti> yeah, except that this should get dist-upgraded every day to not explode the dist-upgrade/reboot time, but details
<pitti> infinity: right, and I could provide that with a --setup-commands
<infinity> pitti: Sure, sure.  Lots of maintenance and tweaking, my point is just series opening lag time.
<infinity> If it's "fix a conffile and copy some cloud images", that's cake.
<infinity> And yay.
<pitti> so adding a 'change release in apt sources" setup command script would make this literally an "add new config file" process
<pitti> (more and more inefficient over time, but working)
<pitti> but that'll be the time when I'll sit down to create a new daily job to provide a current image :)
<infinity> :)
<infinity> Yeah, I'm waiting for *stack on all 6 arches, so I can move my chroot tarballs to some sort of cloud buildy thingee.
<infinity> Y'know, I guess I could build them as livefses.
<infinity> Hrm.  Why have I not been doing that?
<infinity> Something to do later this week, I think.
<dholbach> good morning
<opiwahn> where would I have to place an initram-script if I want to have it executed as early as possible: http://snag.gy/KCkcM.jpg
<pitti> opiwahn: init-top/asomething
<opiwahn> pitti: thank you pitti . I will try it
<opiwahn> pitti: and script inside there is executed before touching any harddisks?
<pitti> opiwahn: yes
<pitti> opiwahn: see "Subdirectories" in man initramfs-tools(8)
<opiwahn> pitti: thank you very much :-)
<jamespage> if there are any archive admins with a few spare minutes I'd appreciate a review of networking-odl in the wily NEW queue - thankyou!
<infinity> jamespage: Is that a thing that has intent to also exist in Debian?
<jamespage> infinity, yeah - the repo is created, but its not been testing in Debian yet
<jamespage> infinity, I also have a python-os-brick in the queue - also in the NEW queue for experimental
<jamespage> I just need to unblock our liberty milestone1 testing in wily
<jamespage> as Debian is not targetting liberty just yet, we're leading on some of this stuff (doing more through experimental tho)
<infinity> jamespage: Check.  The followup question would be if the maintainer in Debian is you, or if you're working with the planned maintainer to make sure the packaging is the same.
<jamespage> infinity, it will be done under the pkg-openstack team - might be me...
<infinity> jamespage: With a second followup of "wtf, no python3?" ... I thought all new openstack stuff was dual-stack.
<jamespage> infinity, not core projects just yet - working towards that
<jamespage> networking-odl is a split out vendor driver from neutron
<jamespage> python-os-brick does have py3 support tho - I had to fix that up (submitted upstream)
<opiwahn> pitti: about the init-script: do I have to write my script to this file "ORDER" ? http://pastebin.com/4pbZ4nGu
<pitti> opiwahn: I've never heard about ORDER, shouldn't be necessary; might be something that initramfs-tools builds/uses internally
<pitti> adding the script and "sudo update-initramfs -u" shoudl suffice
<opiwahn> ok.. so I just put a (shell) script to folder init-top and update-initramfs -lk all should work?
<opiwahn> pitti: my issue is that the script does not appear in the live-system.. when searching in /usr/share/initramfs-tools/scripts/   all the scripts are in there.. except mine
<pitti> opiwahn: not sure what -l is (that doesn't exist), I suppose you want -u
<jamespage> infinity, thankyou!
<pitti> opiwahn: err, live system?
<opiwahn> pitti: i use -k all
<opiwahn> yes.. I am doing a remastering... and I want to add an early script to initrd.lz
<pitti> opiwahn: ah, that might be where this ORDER things comes from? (no idea about remastering, sorry)
<highvoltage> #Ã# Ã-#Ã-/win 24
<infinity> pitti: The ORDER files are generated by update-initramfs.
<infinity> But yeah, if one was hacking the initrd manually instead of generating it properly, you'd need to hack those bits too.
<opiwahn> this is how I generate it in my remaster-script: http://pastebin.com/LiNmSJJU
<opiwahn> before that I unpack initrd.lz... put my script in there.. repack it..
<infinity> opiwahn: Unpacking and repacking it isn't sane.
<opiwahn> I used these lines to pack/unpack: http://pastebin.com/0cCsewNb
<opiwahn> isnt that ok?
<infinity> opiwahn: You want to put your script in /usr/share/initramfs-tools/scripts/init-top/ and the update-initramfs -u and use the result.
<opiwahn> infinity: so you mean just putting while remastering the file in there, executing update-initramfs .... without modifying any initrd.lz ??
<infinity> opiwahn: Use the tools available, instead of trying to hack around them. :)
<opiwahn> so I can execute an init-script without hacking the initrd.lz ??
<infinity> opiwahn: Your goal is to add a script to the initrd in init-top, yes?  So, put it in your chroot at chroot/usr/share/initamfs-tools/scripts/init-top/ and then "chroot chroot/ update-initramfs -u -k$(version)" and copy the result from chroot/boot/initrd-$(uname)
<infinity> opiwahn: You *can* unpack and repack the initrd, but that means you need to know how initramfs-tools builds it, which is not knowledge worth having, really. :P
<opiwahn> infinity: I really WANT to do the simple way :-)
<infinity> opiwahn: Yes, the simple way is also the right way.
<infinity> opiwahn: Two lines.  Copy your file, run update-initramfs.
<infinity> No unpack, repack, understanding inner workings, etc.
<opiwahn> infinity: is this "double chroot" right?   chroot chroot/ update-initramfs -u -k$(version)
<pitti> all that in the chroot of the live image, I figure
<infinity> opiwahn: Well, "chroot/" was the directory.  In your case "chroot ${WORK}/new/ update-initramfs -u -k 3.19.0-15-generic"
<infinity> opiwahn: THe trick is that BEFORE that, you do "cp myscript ${WORK}/new/usr/share/initramfs-tools/scripts/init-top/"
<infinity> And just those two lines (plus copying out the finished initrd) should get you what you want.
<opiwahn> doing it at the moment and looking forward :-)
<infinity> I'm assuming here that ${WORK}/new/ has you live filesystem in it. :P
<infinity> s/you/your/
<infinity> Hopefully writable.
<opiwahn> the variable -k$(version) works on any kernel then ??
<infinity> Err, no.
<infinity> That was shorthand for "-k the-kernel-version-you-use"
<opiwahn> ah ok
<infinity> 3.19.0-15-generic", for instance.
<opiwahn> good that I asked :-)
<infinity> The kernel version on the livecd and installed in the chroot, of course.
<infinity> Not the one you're running on your build system. ;)
<mardy> pitti, pete-woods: I'm trying to use libqtdbus{test,mock} in my tests (successfully), but they fail when they are run as part of dpkg-buildpackage; do you know any tricks to run dbus-daemon as part of the package building process?
<pitti> mardy: it's always better if your test starts/uses its own private dbus server
<opiwahn> infinity: the remastering runs.. I tell about the result ;-)
<pitti> mardy: you should never muck around with the "real" session or system bus
<pete-woods> mardy: you shouldn't have to change anything. I've used libqtdbustest in all my packaging
<pete-woods> pitti: libqtdbustest does exactly that (I wrote it)
<pitti> mardy: and yes, you can use dbus-launch, but really, don't
<pitti> pete-woods: ah, ok
<pete-woods> pitti: and libqtdbusmock uses your dbusmock internally
<mardy> pete-woods: wait, I'll post the output
<pitti>  dbusmock also has a convenience API to start a "private" session bus (or system)
<pitti> but that only works in python
<pitti> for C/C++ you have to start the bus yourself, which I suppose is what pete-woods does in libqtdbusmock
<infinity> It's never the starting that's a problem anyway, it's the 30 times people have reinvented the stopping wheel and failed.
<pete-woods> mardy: I've likely point the finger at paths / resources are different on your dpkg build that in your local source build
<pitti> infinity: ?
<pitti> infinity: dbus-launch --exit-with-session ?
<mardy> pete-woods: http://paste.ubuntu.com/11840275/
<infinity> pitti: Oh, just whining about all the people who fail to stop processes they start in testsuites. :P
<mardy> pete-woods: I tried both with and without xvfb, same errors
<pitti> that does look like you have a bus, it's just your service doesn't seem to attach to it
<pete-woods> infinity: if it makes you feel better, the test processes are managed by libqtdbustest and terminated when your test binary exits :)
<pete-woods> even if you segfault
<infinity> pete-woods: It makes me feel warm and fuzzy.
<mardy> pete-woods: when I run the tests from the terminal, they work
<infinity> So very fuzzy.
<mardy> pete-woods: I even unset the DBUS_SESSION_ADDRESS variable, and they still run (on the console)
<pete-woods> mardy: as they should
<mardy> pete-woods, pitti: does dpkg-buildpackage run the tests in a chroot? maybe some directory (/var/lib/dbus/) is not available there?
<infinity> mardy: dpkg-buildpackage doesn't, no.  Unless you're invoking it via something like sbuild.
<mardy> (I found this, that's why I ask: https://bugzilla.redhat.com/show_bug.cgi?id=460574 )
<ubottu> bugzilla.redhat.com bug 460574 in mock "dbus can't start in chroot" [Medium,Closed: currentrelease]
<pitti> mardy: no, it doesn't; you have to provide that yourself with sbuild/pbuilder/etc/
<mardy> ok
<pitti> mardy: err, /var/lib/dbus? that's the session bus
<pitti> mardy: you aren't allowed to attach to that as user
<pitti> mardy: I mean, that's teh *system* bus
<infinity> mardy: dpkg-buildpackage does the following: "fakeroot debian/rules clean && debian/rules build && fakeroot debian/rules binary"
<infinity> mardy: No magic.
<mardy> pitti: ok, nevermind that then :-)
<pitti> mardy: do you test a system or session service?
<mardy> pitti: session
<pete-woods> pitti: FYI, libqtdbus test starts a private system and session bus
<pete-woods> and sets all the relevant environment variables
<mardy> infinity: thanks; is there a command to run the tests only? that might be easier to debug
<mardy> infinity: maybe "debian/rules test" or something like that?
<infinity> mardy: Depends on how you're invoking them, I didn't write your debian/rules.
<pete-woods> mardy: I would suggest adding some debugging to your test code, and perhaps paring it right back
<pitti> mardy: I suggest you build it once, and then just do "make check"
<pete-woods> so just start one test, that prints the bus address
<pete-woods> something like that
<pitti> mardy: or whatever your debian/rules does to run the tests
<pete-woods> just to check it's not all gone crazy
<mardy> infinity: %: dh $@ --with python3
<pitti> mardy: then call fakeroot dh_auto_test
<pete-woods> as I'm pretty confident about the libs - as mentioned before they are used in a number of projects for testing
 * mardy tries
<infinity> mardy: Without the fakeroot.
<infinity> pitti: auto_test is part of the build sequence, not the binary sequence.
<mardy> pitti, infinity: so, if I just run dh_auto_test, it works; if I run "fakeroot dh_auto_test", it fails with the same errors
<pitti> jamespage, smoser: do you know how  cloud-init's userdata could set up apt sources, with referring to "apt_mirror:"? http://cloudinit.readthedocs.org/en/latest/topics/examples.html#add-apt-repositories doesn't really say
<infinity> mardy: It shouldn't be run with fakeroot, generally.
<pitti> I need to enable multiverse in the instance, but I don't see what's the preferred way of doing this other than hardcoding the mirror
<infinity> mardy: Do you have a full build log instead of the short failure snippet?
<pitti> mardy: so I suppose you are trying to talk to the real session bus
<pitti> mardy: does it also fail with env -u DBUS_SESSION_BUS_ADDRESS dh_auto_test ?
<mardy> pitti: with "env -u DBUS_SESSION_BUS_ADDRESS dh_auto_test" it works
<pitti> ok, so I suppose there's a fakeroot *somewhere*?
<infinity> mardy: At this point, I'm thinking the full source might be more helpful than people guessing.
<mardy> infinity, pitti: the full build logs: http://paste.ubuntu.com/11840315/
<mardy> pete-woods: I also added a line to print the session address, I cannot see anything wrong in it ^
<mardy> infinity: let me push the latest commits...
<infinity> Err, WTF?
<infinity> Why is the whole build happening in the binary sequence?
<infinity> mardy: Do you have a "build" rule in your rules file or something?
<infinity> mardy: Seeing the source would be very helpful here. :P
<infinity>  debian/rules build
<infinity> make: 'build' is up to date.
<infinity> That's why it's going downhill.
<opiwahn> inifity: did not work, but I think I did not understand it right.. it now just copied my script to "scripts" in the chroot and did update-initramfs.... but thats not all, right?
<mardy> infinity: lp:~mardy/online-accounts-api/service
<infinity> opiwahn: And then copy out the new initrd from /boot in the chroot to wherever it should live on your remaster...
<mardy> infinity: ah! I created a local directory called "build", could that confuse make?
 * mardy tries removing that...
<infinity> mardy: It could indeed. :P
<infinity> mardy: If you need that directory, you could .PHONY build.
<opiwahn> infinity: can I also copy initrd from the running live-system?
<infinity> opiwahn: ...?
<infinity> opiwahn: Once it's running seems a bit late, since you need it to boot.
<opiwahn> infinity.. ahm ok.. I try it.. sorry for not-so-good-skills
<opiwahn> infinity: so this line has to be added, right?
<opiwahn> infinity: sudo mv ${WORK}/new/initrd.lz ${WORK}/ubuntu-livecd/casper/
<mardy> infinity, pitti, pete-woods: so, indeed, having a directory called "build" in the source tree breaks everything :-) Now the tests run just fine :-)
<infinity> opiwahn: I'm going to assume it's ${WORK}/new/boot/initrd-$(version) or something, but yes.
<infinity> opiwahn: Look for it after you do the update-initramfs and see what it is.
<mardy> infinity: thanks for spotting the issue! :-)
<infinity> mardy: NP.
<infinity> mardy: Welcome to make? :)
<opiwahn> infinity: it isnt just called initrd.lz ?
<infinity> opiwahn: No, update-initramfs generates it as /boot/initrd-$(uname -r) (look at /boot/ on your running system, if you use Ubuntu).
<infinity> initrd.img-$(uname -r) even.
<infinity> opiwahn: When we master CDs, we copy that out to "initrd.lz" on the ISO, so our CD bootloader can be stupid and not know about versions.
<infinity> rbasak: Wake up.  I'm tired and want to yell at you about docker before I go to bed.
<pete-woods> mardy: that's good to know :)
<opiwahn> infinity: thank you infinity for so great background information.. would like to let u know that I am very very thankful
<opiwahn> infinity: I located the initrd.img-3.19.0-15-generic in chroot/boot :-)        and I am doing WHAT with it?? :-)
<opiwahn> infinity: because I will need initrd.lz not initrd.img-3.19.0-15-generic ?
<opiwahn> I have build a initrd.img-$(version) in the chroot of my remastering process. where do I have to put this file so that it "overrides" initrd.lz from original ubuntu-cd ?
<infinity> opiwahn: Yeah, just copy it to foo/bar/initrd.lz (where foo/bar is the path the original initrd.lz is in on the ISO layout).
<infinity> ie: copy it over the thing you were previously unpacking and repackging.
<ekarlso> Hi, is there a reason for network-manager-strongswan not supporting PSK
<ekarlso> as in https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1457078
<ubottu> Ubuntu bug 1457078 in network-manager-strongswan (Ubuntu) "L2TP client support for PSK removed from 15.04" [Undecided,Confirmed]
<opiwahn> infinity: so e.g. to "casper" folder where I find the original initrd.lz ?  should I delete initrd.lz or is this system-immanent?
<infinity> opiwahn: Copy it over initrd.lz
<opiwahn> infinity: do you mean renaming and overriding initrd.lz, no?
<infinity> opiwahn: As in "cp path/to/boot/initrd.img-3.19.0-15-generic path/to/casper/initrd.lz"
<opiwahn> infinity: yes.. you meant that
<infinity> rbasak: On second though, I'll sleep.  Please fix the golang-pty thing I rejected, and we'll talk docker itself when I wake up.
<opiwahn> infinity: before you go to bed.. let me thank you again for such great help, patience..
<rbasak> infinity: o/
<rbasak> infinity: OK, looking
 * rbasak looks at 47 new emails!
<infinity> rbasak: Oh, sure, now you show up.
<rbasak> :)
<infinity> rbasak: Have 5 minutes for a quick mumble... In 5 minutes?
<rbasak> infinity: sure
<infinity> rbasak: Should be able to clear this all up and be happy by morning.
<infinity> rbasak: Alright.  I'm going to grab the nightcap I was planning on putting myself to sleep with, then you can sing me a lullabye on mumble.
<ekarlso> noone that knows why https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1457078 < isn't fixed ?
<ubottu> Ubuntu bug 1457078 in network-manager-strongswan (Ubuntu) "L2TP client support for PSK removed from 15.04" [Undecided,Confirmed]
<ekarlso> I can't use my VPN at all atm
 * rbasak mumbles
<rbasak> infinity: https://git.launchpad.net/~ubuntu-server/+git/docker-backport-tools/tree/all
<ekarlso> noone in this chan that knows the nm stuff ?
<pitti> rbasak: could I hand the apache2 merge back to you?
<rbasak> pitti: I actually did it already. It's stuck in proposed.
<rbasak> (I'll sort that out when I get a chance)
<pitti> rbasak: ah great; I had a faint recall that we talked about this before
<pitti>    * amd64: ltsp-cluster-control
<rbasak> Yeah it's Ubuntu only and just needs its dependencies fixing
<pitti> rbasak: ah, does the new version finally drop the apache2-mpm-* transitionals?
<rbasak> Yes
<pitti> ah ok, that sounds simple enough then
<opiwahn> did this change from 14.04 to 15.04?  I customized an ubuntu-live-cd..  an entry in my "isolinux.cfg" boots with parameter "text" the text-only mode... remastering 15.04 this entry still boots gui... something changed here??
<pitti> opiwahn: ah yes, our lightdm.service doesn't check for "text"
<pitti> bug report appreciated
<opiwahn> what can I do?
<pitti> in /lib/systemd/system/lightdm.service, add ConditionKernelCommandLine=!text to the [Unit] section
<opiwahn> ok. I'll try and give you feedback
<pragomer> opiwahn: hello
<opiwahn> pitti: I added this line to lightdm.service... after rebuild with boot-option "text" the system hangs on "rc-local.service"
<opiwahn> pitti: this is my file: http://pastebin.com/C05ZEfnL
<opiwahn> although I added ConditionKernelCommandLine=!text    to lightdm.service boot-option "text" does not work anymore
<seb128> budgets for?
<opiwahn> I added this line to lightdm.service... after rebuild with boot-option "text" the system hangs on "rc-local.service"    it says "A start job is running for Wait for ...en to Quit"
<opiwahn> built a initramfs script that should block harddisks (blockdev --setro /dev/sd*).... but it says /dev/sd* not found.. is it possible that a this stage of boot /dev/sda etc.. are not yet ready??
<pitti> opiwahn: please boot with systemd.debug-shell, then ctrl+alt+F9 when it hangs, and check systemctl status rc-local.service -- do you do anything funky in there?
<pitti> opiwahn: yes, they very likely are not yet
<pitti> not in init-top/
<opiwahn> pitti: ah.. ok.. what would be the right place to put the script in to block these devices?
<opiwahn> pitti: you mean if I edited rc-local.service? nope
<opiwahn> pitti: where to put such a script? http://snag.gy/4WtQp.jpg
<opiwahn> how do I boot with systemd.debug-shell ?
<pitti> same place as "text"
<pitti> i. e. kernel command line
<opiwahn> ok I try
<opiwahn> pitti: found out the right place would be local-premount :-)
<mardy> pitti: sorry to bother you again :-) is there a way to get my unique connection name with dbus-python, or do I have to manually call "Hello"?
<teward> pitti: got a question for you with regards to apport hooks, 'cause i'm a little lost.  Can apport hooks grab the output for a given command (not a log file!) for a package post installation failure, so when the bug is filed in 15.04 and up, we can get usable output and information rather than nothing useful from the existing apport handling for a package?
<teward> (everyone says you're the person to poke on it)
<mardy> pitti: actually, I cannot even call Hello myself: "dbus.exceptions.DBusException: org.freedesktop.DBus.Error.Failed: Already handled an Hello message"
<mardy> pitti: nevermind found it by using the source (bus.get_unique_name() -- looks like it's undocumented)
<opiwahn> at what stage of initrd script: http://snag.gy/4WtQp.jpg   are devices /dev/sda e.g. ready to use ?
<pitti> mardy: I don't know, I'm afraid; nothing in http://dbus.freedesktop.org/doc/dbus-python/api/ ?
<pitti> mardy: ah, great!
<pitti> teward: sure, hooks can run arbitrary stuff; there's even an apport.hookutils convenience wrapper for it
<pitti> teward: apport.hookutils.command_output()
<pstolowski> hi! i need to access an arm64 box to debug an issue with unit tests of unity-scopes-api, can somebody help me with getting an access?
<cjwatson> pstolowski: you want #is, ask for access to the porter boxes
<pstolowski> cjwatson, k, thanks!
<cjwatson> (#is internal that is)
<cjwatson> pstolowski: https://wiki.canonical.com/InformationInfrastructure/ISO/BuildInfrastructure/PorterBoxes
<pstolowski> ack
<smoser> pitti, http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt
<smoser> http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/examples/cloud-config.txt#L107
<pitti> smoser: ah, nice! thank you
<teward> pitti: i'm horribly new to the apport hooks stuff, and embarrasingly so.  Do you have syntax documented anywhere for that, and potentially a general example of that in use currently somewhere?
<teward> Next question is testing the apport hook, and that's the next question.  Final question is how do you include the apport hook inside of a package for inclusion in the repositories?
<pitti> teward: "grep -r command_output /usr/share/apport/package-hooks/" has plenty of examples
<teward> pitti: and the last part, about including in the packaging, I didn't find clear documentation on that, though I was hunting it last night when really tired
<pitti> teward: or look at this for the API docs: python3 -c 'import apport.hookutils; help(apport.hookutils)'
<teward> about when micahg poked me in -motu
<pitti> teward: /usr/share/doc/apport/package-hooks.txt.gz is the first documentation you should read
<teward> thanks, i'mma read all that.  sorry for picking your brain on this :/
<pitti> teward: test> put it into /usr/share/apport/package-hooks/, and run "apport-bug yourbinarypackage"
<pitti> teward: then you see the details of collected information in the window; just don't send it then
<mdeslaur> The nss package has "libnss3-tools:native (>= 2:3.19-1-1~) <cross>" in Build-Depends, but the upload to Ubuntu fails with "invalid Build-Depends field; cannot be parsed by apt: Problem Parsing Dependency"
<mdeslaur> I've never seen that format before, is that supported in Ubuntu?
<pitti> teward: packaging> either use dh_apport (man dh_apport, in the dh-apport package), or just normal dh_install and put the file into the right place/name
<pitti> mdeslaur: it's a realatively new debian thing called "build profiles"
<pitti> mdeslaur: https://wiki.debian.org/BuildProfileSpec
<mdeslaur> pitti: ah! thanks for the searchable term
<pitti> mdeslaur: most probably Launchpad doesn't yet know about it
<pitti> it's a kind of "make doko happier" feature :)
<mdeslaur> oh, wow, I didn't know doko could be made happy :)
<teward> pitti: thanks again.  and sorry for buggin you for documentation links and such.  At least I have a start point now, thanks!
<pitti> teward: no worries, that's what IRC is for :)
<pitti> teward: please let me know if you run into difficulties
<teward> pitti: i likely will, python is NOT my forte
<teward> i have a general understanding of it, enough to interpret semi-intelligible scripts and such, but ehh
<pitti> teward: then I guess looking at the existing hooks and adapting them to your need is best
<pitti> teward: most hooks should be simple, like collecting an extra log file or command output or two
<teward> pitti: exactly, although the headache is that it's a post-installation failure - some have been ApacheAlreadyBindingTo80 issues, some have been failed configurations by the end users (i.e. something odd and nonstandard)
<teward> and since systemd it's been even less diagnosable
<teward> it used to spit errors out nicely.  now it just 'fails' with no usable error data in apt logs
<teward> pitti: i assume in the documentation there's a selective-case for the hooks such that if it's a package install/postinstall/upgrade/postupgrade failure during apt, it will only trigger then?
<teward> we don't need `journalctl -xe` or `systemctl status nginx.service` for other bugs yet...
<teward> (and I assume that's documented as well)
<teward> (so I should just start reading xD)
<pitti> teward: the hook can look at report['ProblemType']
<pitti> teward: that's "Crash", "Bug", or for your case "Package"
<pitti> teward: the hook will always be called when you report something against that package, it can conditionally do/evaluate stuff based on ProblemType and the keys it has in the report object
<barry> cjwatson: well, it looks like i must have released lazr.delegates 2.0.2 back in january and yet somehow managed to not check any of that into bzr or tag it.  can't find it on any machine.  must have been my evil twin, so now i'm going to unfutz that and try to get a 2.0.3 out in a bit
<teward> pitti: right, i knew the hook would always get called, hence wanting to do some different things per problemtype
<teward> pitti: thanks again
<cjwatson> barry: Yikes.  OK ...
<barry> cjwatson: at least i have the tarball and it wasn't much
<teward> um... general question, but would an SRU to add in an apport hook for a package even be considered?  I only ask because with Vivid, we currently have a bunch of ambiguous bugs all for the same version all for failed-to-install, and nobody's providing additional info when we ask for it except maybe one guy on one bug.
<teward> and adding an apport hook would solve that ambiguity problem.
<teward> ('cause we can't diagnose bugs, even, in the current state of things)
<teward> (for nginx)
<barry> cjwatson: okay, 2.0.3 tagged and pushed.  if you want to give it a quick look/test i can wait a bit before spinning the release
<barry> gonna make some tea
<doko> jamespage, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=778058 -std=gnu99 should help
<ubottu> Debian bug 778058 in src:percona-xtradb-cluster-galera-2.x "percona-xtradb-cluster-galera-2.x: ftbfs with GCC-5" [Serious,Open]
<cjwatson> barry: looks fine by eye, I expect you can just push that
<barry> cjwatson: thanks. releasing
<barry> cjwatson: done
<cjwatson> thanks
<cjwatson> will poke again at lazr.restful in a bit then :)
<pitti> mvo: is there a python-apt'ish way of getting a list/iterator of all apt sources?
<pitti> mvo: I mean the "deb[-src] ..." lines in sources.list and sources.list.d/
<mvo> pitti: yes, some high level stuff even "pydoc aptsource"
<pitti> mvo: oh, nice! So I create an aptsources.sourceslist.SourcesList() and then what?
<pitti> mvo: oh, it's an iterator, nice!
<mvo> pitti: there should be some example code and even some documentation
<mvo> pitti: https://apt.alioth.debian.org/python-apt-doc/library/aptsources.sourceslist.html
<mvo> pitti: https://apt.alioth.debian.org/python-apt-doc/library/aptsources.distro.html might also be interessting
<pitti> mvo: perfekt, danke sehr!
<doko> xnox, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+packages ftbfs on ppc64el and arm64 :-/
<doko> no, everywhere
<xnox> doko: boost1.55 is 98abi only, boost1.57+ is c++11 abi.
<xnox> doko: you want 1.57 from experimental.
<xnox> doko: boost1.55 fixed build failures, for reverse-deps, that compile with gcc5 & 98abi.
<doko> xnox, still no 1.58?
<xnox> not yet, no.
<xnox> didn't have time to do it yet. I guess I should work on that and other build failures asap.
<xnox> doko: did you poke icu futher to determine if it will require transition or not?
<doko> xnox, feel free to upload to the ppa mentioned above
<xnox> i hope it doesn't, but who knows.
<doko> xnox, no, just rebuilt with GCC 5
<doko> in the same ppa
<xnox> doko: ok. let me check if I have upload rights there.
<xnox> yes i do. good.
<teward> pitti: what does one do if there's an AssertionError on the thing
<teward> (for apport hooks)
<teward> oop nevermind
<ogra_> lol ... so debian goes back to ffmpeg ?
 * ogra_ just saw the news, thats funny
<hich-em> hey sabdfl
<hich-em> Neo31,
<hich-em> hak lehna
<hich-em> Neo31,
<smoser> anyone able to validate my vague memory that at one point apt was not checking the checksum of Translation-* files
<TJ-> smoser: That sounds familiar; I was dealing with a lot of bugs like that due to captive portals a while ago
<teward> did pitty leave until tomorrow?
<teward> pitti*
 * teward hates autocorrect
<teward> so, i have one issue - I'm prompting the user in my apport hooks as to whether to include certain files.
<teward> Problem is: Apport asks the same set of questions twice
<teward> not sure whether it's my code or what
<teward> other than pitti, is there anyone here who knows enough about apport hooks to try and diagnose the issue i'm seeing with my apport hook for a specific package?
<teward> is there a way to determine whether upstart or systemd are actually in use on a given system?  (Some people use Upstart, some use SystemD, on their 15.04 systems...)
<teward> like some file or some python that can be used as part of an apport hook
<tarpman> teward: reportbug contains a snippet that tries to guess the active init system, I'd copy that
<teward> so there's no easy way then
<sarnold> teward: readlink /proc/1/exe might get you there
<teward> sarnold: that worked for systemd on 15.04, didn't work 14.04
<teward> with upstart
<teward> i know one guy who has upstart on 15.04 instead, because they're odd but eh
<sarnold> teward: oh? I didn't realize 14.04 could boot with systemd well enough to use..
<teward> sarnold: it's a three pronged test
<teward> sysvinit, systemd, or upstart
<teward> sarnold: trying to make a 'global' apport hook :/
<sarnold> ahh
<teward> such that it can NOT run the systemd gathering commands if systemd isn't present
<teward> (because it will blow up in our face if we try)
<teward> what I need is pitti to be here but I missed em a while ago for a followup
<teward> sarnold: is it safe to assume that for 15.04 and up it's likely Upstart handling things?
<teward> s/upstart/systemd/
<teward> god I am tired
<sarnold> teward: it is the official; I think that makes sense.
<teward> ok.
<teward> because upstart and sysvinit, stderr is caught in the dpkg terminal log apparently
<teward> but systemd, it holds it internal
<teward> and just says "There is a problem"
<teward> it's the nginx-bugs-not-having-sufficient-details problem that i'm finally attacking with the whole of my brain
<sarnold> woo :)
<teward> and thanks to pitti, i've got the bare minimum in apport hooks to diagnose the postinstallation scripts failed problem
<teward> but me being the person i am, tryin to expand it - ask if the user wants to include the error.log, nginx.conf, and enabled site configs, which could contain sensitive info, with the report, for Crash and Bug type bugs
<teward> those ones are easy
<teward> but making the part to gather the stuff systemd doesn't put out to the logs is a systemd only thing, so i'll have to use that in the interim until pitti's back to spotcheck my code and give insights
<teward> BEFORE putting in for SRU consideration for Vivid, and before uploading to Vivid
<teward> s/Vivid/Wily/
<teward> ehh, whatever, too tired
<sarnold> don't forget to exclude ssl keys and passwords :)
<teward> sarnold: mmm, well, i was considering that if those are included forcing the sensitivity to Private
<teward> but then i realized, ehhhh, that'd be annoying to me
<teward> so i may leave that out
<teward> the key important log file is error.log though
<teward> that has IP addrs
<teward> sarnold: how much do you know about apport hooks?
<teward> tarpman: ^ same q
<sarnold> teward: nothing; I just see the collected data in launchpad
<teward> 'cause I get an erroneus "Error: COmmand exited with stats 3" error with command_output
<teward> i really need pitti here :/
<tarpman> teward: no idea apport apport stuff, just your mention of init-detection caught my eye
<teward> tarpman: yeah, that's something I'd love to incorporate into the apport hooks to NOT have systemd commands if upstart is present but eh
<teward> i guess i'll stop by tomorrow morning and see if pitti is around
<tarpman> teward: specifically, http://sources.debian.net/src/reportbug/6.6.3/reportbug/utils.py/#L1230
<tarpman> pretty easy
<teward> tarpman: how accurate is it in Debian?
<teward> fairly accurate?
<tarpman> teward: haven't heard of any false results. the systemd one is definitely the supported way of detecting systemd, at least
<teward> mmm, indeed
<teward> sarnold: i'm definitely glad though i know have a baseline for the 'ambiguous bugs' problem now, with these TWO LINES we get all the information we need for systemd and postinst fails
<teward> baseline fix*
<sarnold> teward: sweet :) there's certainlu enough 'postinst returns 1' errors..
<sarnold> teward: knocking off the nginx errors would be a nice start :)
<teward> sarnold: the start point there: get USABLE debug info
<teward> 'cause currently it's horridly unuseful **** there now
<teward> -server even agreed when i went on a minirant last night
<mwhudson_> hm
<mwhudson_> when i do
<mwhudson_> sudo dpkg --add-architecture armhf
<mwhudson_> on my laptop, apt-get update complains
<mwhudson_> because the armhf stuff is on ports.ubuntu.com, not archive
<teward> stupid question: why're you adding armhf arch?
<mwhudson_> oh, i guess i need to put [arch=] in sources.list a bunch
<mwhudson_> teward: hoping to be able to run stuff with qemu-arm-static
<mwhudson_> maybe that's silly
<mwhudson_> perhaps i should just make a chroot instead
<teward> mwhudson_: eheheh... FWIW I have a pi coming in for when I need to run arm stuff.  And I have an sbuild enviro to local-build armhf stuff, although that sometimes asplodes just like the ppa builders do
<mwhudson_> well i have a dragonboard too
<mwhudson_> but sometimes i just have my laptop
<mwhudson_> (which has arm64 installed on it, but the armhf chroot on there doesn't require qemu games)
<teward> mmm, stupid question, how does one use dh_installapport / dh_apport in the package?  Is it automated or is there something i have to drop into the rules file?
<teward> i'm a little confused on implementation/use of dh_apport is all
<teward> (to work with the apport hooks for a given package)
<infinity> teward: Manpages tend to explain these things.
<teward> infinity: i didn't glean anything special from the manpage, but then again, i'm fairly tired having bashed my head against python all day
<teward> and i am an idiot, it explains it perfectly
 * teward facedesks
#ubuntu-devel 2015-07-09
<cjwatson> teward: The canonical way to determine whether systemd is pid 1 is os.path.isdir("/run/systemd/system") or per-language equivalent
<cjwatson> teward: For Upstart, you want the init_is_upstart function from /lib/lsb/init-functions (or, again, per-language equivalent)
<teward> cjwatson: i really only need the systemd test/check - the apport hooks i'm writing for nginx (because of the appalling bug helpfulness quality since 15.04 and systemd) i'm trying to make sure is catchable.  plans were to only land it in 15.04 and up, and since I know someone has a wildly custom setup where they got rid of systemd... *shrugs*
<teward> cjwatson: thanks thoug
<cjwatson> Sure
<cjwatson> At least the systemd check is pretty trivial
<teward> i'm more concerned with why when i try and get the apport hooks to request whether hte user wants to include certain files or not it then asks TWICE before doing anything
<teward> three questions coded, six questions asked (the three questions, 1 2 3, then again, 1 2 3)
 * teward shrugs
<cjwatson> You want pitti or bdmurray for that kind of thing
<teward> indeed
<teward> i'm going to poke pitti tomorrow
<teward> bare minimum is to get the systemd check
<teward> (tomorrow my time, as in the morning about 10 - 12 hours from now)
<teward> cjwatson: given only a day, though, thanks to pitti's guidance this morning my time, i've already got the gist of what i need to have done down, at the very least to fix  the reason that sarnold and I want to smack the nginx package around in 15.o4
<teward> 15.04*
<teward> so a big thanks to pitti is definitely due :)
<psusi> is 15.10 going to switch to systemd either in the initramfs or user session?
<teward> cjwatson: follow-up: thanks for the guidance.  Finding systemd was easy.  I had to essentially write an init_is_upstart function in python, using init-functions's init_is_upstart as a partial guide for what to do.  And I've replicated the command set to check if it's upstart or sysvinit (the old one)
<teward> s/for what to do/for what to do to check if upstart/
<hich-em_> sabdfl,
<pitti> Good morning
<pitti> teward: asks twice> at this point I'd need to see your hook and what you do exactly to test/call it; normaly it's run once
<pitti> teward: os.path.isdir('/run/systemd/system/') -> running systemd
<pitti> teward: detecting upstart is harder, but on Ubuntu you can assume that it's upstart if it's not systemd
<pitti> nah, don't readlink  /proc/1/exe, that's wrong
<pitti> tarpman: ^ FYI
<sarnold> hey pitti :) teward said he'd like something that can work with debian sysvinit too
<infinity> I think he cargo-culted from init-functions and got what he wanted.
<infinity> At least, backscroll with cjwatson seems to imply that.
<pitti> "initctl --system list" should work under upstart, but I'm not sure whether it needs root
<pitti> it fails under systemd with "Name "com.ubuntu.Upstart" does not exist" as expected
<pitti> teward: global hook> you mean general-hooks/, not a package specific one? you can do that too, yes
<infinity> pitti: The is_upstart function from init-functions is the canonical way.
<pitti> teward: logs> rsyslog's logs have everything too, so in general you can get it there; but filtering stuff that you are interested in from the journal is magnitudes easier than fishing it out of syslog
<pitti> teward: no, hooks must never collect private/sensitive stuff,  please obfuscate that with post-processing
<pitti> teward: ok, I think I've caught up with your questions, but at this point just show me the hook for review?
<opiwahn> I still need help creating an initram script while a remastering process.  This is the way I put my "script" to initram: http://pastebin.com/RmNivmvX   The script simply should do "blockdev --setro /dev/sd*"   on the live-system I can find the script under /usr/share/initramfs/scripts/local-top/ but it did not have any effect. running it manually blocks the harddisk. someone could help me?
<sarnold> why two sudo calls per line?
<sarnold> opiwahn: I think I'd remove every 'sudo' from this script, and run this script via sudo manually
<opiwahn> sarnold: hi.. you mean the "sudo" before the blockdev, right? not from my remastering-part, right?
<sarnold> opiwahn: well... lets take this line here:
<sarnold> sudo chroot "${WORK}/new" sudo chmod +x usr/share/initramfs-tools/scripts/local-top/initramblockdev
<opiwahn> the 2nd sudo I need to chmod or not?
<sarnold> opiwahn: that'll execute the system's sudo, then the system's chroot, then the usr/bin/sudo from within the chroot, then the bin/chmod executable from inside the chroot
<sarnold> opiwahn: the entire thing could be replaced with sudo chmod +x ${WORK}/new/usr/share/initramfs-tools/scripts/local-top/initramblockdev
<sarnold> opiwahn: .. that'd remove the dependency on a sudo and chmod from inside the chroot...
<opiwahn> ok I understand
<opiwahn> do you think thats the problem? because .. the script IS on the live medium.. executable.. and works when executing it manually after boot...   while the remaster process stout say me "blockdev: /dev/sd*" device not found.. could be the problem but I dont know why
<pitti> opiwahn: you already asked that yesterday -- apparently you are calling it too early and /dev/sd* does not exist yet
<opiwahn> ok.. I tried to put it on every subdirectory.. according to "man initramfs-tools"...
<opiwahn> I also tried "Init-bottom" what is, according to manpage, the last scripts that are executed.. even here it was the same error message
<pitti> /usr/share/initramfs-tools/scripts/local waits for the root file system to appear
<pitti> opiwahn: perhaps you simply don't have any /dev/sd* then? maybe it's /dev/vd* from QEMU or whatnt
<pitti> whatnot
<opiwahn> no, its really sda and sdb from virtualbox
<opiwahn> am I right that putting it in init-bottom.. just for testing.. is the latest possibility to put the script in.. and so that /dev/sd* should already exist?
<opiwahn> or could it be possible that - at this stage - the "*" could not work??
<pitti> it's still not guaranteed to work, but I'd say in most cases it should
<pitti> the only way to reliably wait for a device to appear is with an udev rule
<pitti> if it's a shell script, the * works
<opiwahn> I also put a udev role on the live system.. this works.. for the "late stage" and plugging new devices.. but there is this "early stage"... e.g. told me ubuntu "unsafe ntfs filesystem.. fixing" . This is only one example why I want to prevent the live system from writing to the disks via a init script
<opiwahn> ok.. I am sorry :-)  but my question again.. is "init-bottom" the "latest stage" where I can sure /dev/sd* should be ready??
<pitti> opiwahn: as I said, you can *never* be sure in the initramfs that all devices got detected
<pitti> opiwahn: you can certainly try and applying it  for those that are already there, with the /dev/sd* globbing, but it might be that new devices are detected later on
<opiwahn> pitti: just detected.. that I use #!/bin/bash in my script... should this be "sh" instead of "bash" *shame*
<pitti> opiwahn: /bin/sh is faster, otherwise it makes not much difference
<opiwahn> pitti: oh.. hoped this was the problem. thanks pitti..
<opiwahn> pitti: pitti.. how would YOU solve this? generally like I am trying it?
<pitti> opiwahn: it seems to me you just want something like
<pitti> KERNEL="sd*", RUN+="/sbin/blockdev --setro $devnode"
<pitti> put that into /lib/udev/rules.d/50-block-ro.rules and copy it into the initramfs
<pitti> opiwahn: oh, another thing -- does /sbin/blockdev really exist in your initramfs? I wonder if your error message from above was really correct
<pitti> if it says "device not found" that suggests that blockdev exists, but if it says "file not found" it might very well be that blockdev itself is missing
<pitti> $ lsinitramfs /initrd.img |grep blockdev
<pitti> sbin/blockdev
<pitti> seems alright
<opiwahn> pitti: are you german?
<pitti> yes, does my writing have an accent too? :-)
<pitti> zat is ze problem!
<opiwahn> pitti: sure.. is it "allowed" to write in not-english in privat messages like this?
<pitti> sure, just talk English on the public channels; what happens in priv messages stays in priv messages
<opiwahn> pitti: ok.. na denn. mein remastering script lÃ¤uft gerade durch, ist aber gleich fertig, dann geb ich dir nochmal den genauen wortlaut der fehlermeldung.. wobei mich schon wundert, dass das beim remastern im stdout erscheint.. da wird ja nix ausgefÃ¼hrt hinsichtlich des block-dev-scriptes..
<pitti> opiwahn: err, this is *not* a private message, it's the channel
<opiwahn> pitti: ups.. I am really new to irc chats.. sorry..
<pitti> opiwahn: yeah, during remastering there shouldn't be a run of blockdev
<opiwahn> pitti: thats my error message: http://pastebin.com/TCpUSZRk
<opiwahn> pitti: dont understand why this appears in the remastering-stdout
<pitti> opiwahn: what's the script right now?
<opiwahn> pitti: you mean the init-script?
<pitti> opiwahn: your remastering script
 * pitti restarted IRC some minutes ago, I don't have earlier scrollback
<opiwahn> pitti: oh... thats big.. :-)    or do you just want the part where I copy the script and the initram-part?
<pitti> yes
<pitti> where it shows that error message
<pitti> I suspect you have some missing quoting there
<opiwahn> pitti: http://pastebin.com/PT6Ymb8y
<pitti> so that it expands /dev/sd* while you run the script, not while you boot the image
<pitti> sudo chroot "${WORK}/new" sudo update-initramfs -u -k all
<opiwahn> pitti: this is the initram-part.. but dont know if this causes it
<pitti> ah, this probably runs it
<pitti> and please drop all those sudos
<pitti> not sure why update-initramfs would run scripts/
<opiwahn> pitti: really ALL sudos? need them to chmod and update-initramfs or not?
<pitti> opiwahn: you ought to run the remastering script as root; it's never good to call sudo in scripts
<pitti> but nevermind, different issue
<pitti> opiwahn: did you run your script with -x to confirm where that error message comes from?
<pitti> I'm not sure it's from http://pastebin.com/PT6Ymb8y
<pitti> anyway, sorry, I really need to get to do something else, bbl
<opiwahn> pitti: ok I drop all sudos at the beginning of these lines...
<opiwahn> pitti: no problem.. what do u mean by running with -x ?
<pitti> nevermind the sudos now, those are not *that* bug; they are just utterly wrong
<pitti> opiwahn: bash -x yourremasteringscript
<opiwahn> pitti: ok..trying bash-x   thank you pitti.. sorry for taking you so much time.. but I am a little closer to the solution
<opiwahn> pitti: really one last beginners question: how can I complete write the output of bash -x myscript also to text-file?
<pitti> command 2>&1 | tee output.txt
<opiwahn> pitti: thank you. really. thank you very much. and have a really good day
<pitti> good luck!
<opiwahn> pitti: thanks
<opiwahn> if I start a bashscript as root/su is another script that is invoked by the first also automatically run as root, or not?
<sarnold> they all run as root
<sarnold> which is why you can remove every 'sudo' from the script and run it as root :)
<opiwahn> thats why my question :-)  thank you guys !
<dholbach> good morning
<pitti> Laney: can you please remove your upstart test override? bug 1429756 is fixed in wily's kernel now
<ubottu> bug 1429756 in linux (Ubuntu Vivid) "FTBFS: upstart test_job_process fails in majority of cases / Kernel returning unexpected EIO at end of file" [High,Confirmed] https://launchpad.net/bugs/1429756
<pitti> http://d-jenkins.ubuntu-ci:8080/view/Wily/view/AutoPkgTest/job/wily-adt-upstart/ succeeded, I restarted it to see that it survives two runs in a row
<Laney> pitti: yay!
<pitti> Laney: yep, survived four tests in a row
<doko> Laney, could you merge pcre3?
<Laney> doko: hmmmmm, I guess so
<pitti> wow, we have a delta in prce?
<Laney> stupid delta
<Laney> will fwd it if it's not already
<pitti> hm, unmangled C++ symbols?
<seb128> wgrant, cjwatson, do you know why templates on e.g https://translations.launchpad.net/ubuntu/wily/+source/dialer-app/+imports are "approved" but not "imported"?
<pitti> I mean "mangled", i. e. "not demangled"
<doko> Laney, and then upload a follow-up version to the ci-train 16 PPA?
<pitti> I thought they'd cause more trouble than they would help
<wgrant> seb128: Translation imports have not yet been activated for wily.
<Laney> pitti: are you doing this merge? :)
<seb128> wgrant, thanks
<seb128> wgrant, when is that planned?
<pitti> Laney: no, I was just curious what we could possibly have changed in pcr3
<wgrant> seb128: Someone Ubuntuy (pitti?) would enable them at https://translations.launchpad.net/ubuntu/wily/+translations-admin once the state of the series was verified.
<seb128> wgrant, it sort of created a fail for ota5 touch langpack updates
<Laney> they have only exported the right symbols
<Laney> sanity
<wgrant> seb128: ... OTA5 is based on wily?
<pitti> wgrant: this currently has "hide" and "defer" enabled, is that intended?
<seb128> wgrant, no, but ppas don't have translation template, so they copied the wily .po over
<seb128> wgrant, assuming that the strings would be the same in their overlay and wily since they dual land
<pitti> wgrant: (sorry, never saw that page)
<wgrant> pitti: Oh, we don't normally enable those, so I assumed you did.
<wgrant> There's nothing blocking it.
<pitti> wgrant: no, certainly not; maybe that's just the default state until we actually get wily translations?
<Laney> doko: no-change rebuild?
<pitti> wgrant: so want me to uncheck these two?
<wgrant> pitti: Oh, I mean having those two checked is the default, and I assume you normally unchecked them.
<wgrant> (yay for having negative checkboxes...)
<wgrant> Yep, I see no reason not to.
<doko> Laney, yes, but with higher version number
<pitti> wgrant: I suppose so far it was done by you or cjwatson or possibly dpm?
<pitti> wgrant: done
<wgrant> pitti: dpm makes sense, maybe.
<pitti> https://translations.launchpad.net/ubuntu/wily/+imports is full of stars now
<Laney> doko: are you going to dump all of the no-change rebuilds into the silo as they can be done?
<Laney> would be good to have a transition tracker which looks at that too I guess ...
<sil2100> pitti: does this mean we can have an another export with updated translations soonish?
<doko> Laney, transition tracker for a ppa doesn't yet exist. but infinity is supposed to work on this ...
<pitti> seb128: ah, the one on https://translations.launchpad.net/ubuntu/wily/+language-packs is no good because of the above?
<pitti> I mean sil2100 ^
<doko> for now, I just upload things what need to fix bugs
<seb128> pitti, well, template imports didn't work
<pitti> right
<seb128> so the templates are outdated
<seb128> so the langpack content doesn't match the current code
<seb128> so strings are missing
<pitti> seb128, sil2100, wgrant: so I guess we have to wait until https://translations.launchpad.net/ubuntu/wily/+imports clears up, and then do another full export?
<seb128> yes
<seb128> but that's going to take days righT?
<pitti>  14190 templates to import AFAICS
<seb128> which might be too much for the ota update
<wgrant> Yes, the translation importer is slow beyond belief.
<wgrant> We can, er, expedite certain templates, though, with a bit of hackery.
<wgrant> That is, unapprove all of the imports that are boring.
<sil2100> wgrant: would that require a lot of work?
<sil2100> Since I suppose if we could get properly updated touch translations imported and then do an export, that would be sweet
<pitti> wgrant: how long would that take roughly? poking 14000 strings into a DB doesn't sound like a lot?
<wgrant> sil2100, pitti: I would probably just use SQL to set all Approved import queue entries in wily to Needs Information. Then you can approve interesting ones as necessary.
<wgrant> And once the deadline has passed we can set them all back to Approved.
<cjwatson> seb128: We'll have proper translations for the overlay PPA soon, BTW.
<cjwatson> (Not OTA5 soon, but soon)
<seb128> cjwatson, ah, that's good news ;-)
<sil2100> wgrant: that could work... although my experience with handling LP translations is a bit weak
<sil2100> wgrant: so I would need some help with that probably
<sil2100> pitti: could you help me out here?
<pitti> sil2100: err, we are supposed to manually set several hundred templates to "approved"?
<pitti> can't we do this with SQL again?
<seb128> I guess it's just a matter of going to https://translations.launchpad.net/ubuntu/wily/+source/<template>/+imports and change the status to approved, for every package that needs an update template
<pitti> set all of them to needsinfo, then set the ones from touch packages back to approved?
<seb128> but yeah, need to have a list of those that need an update
<pitti> it's a hilarious amount of work to change the status of 50 projects times 5 arches on the web UI
<sil2100> I don't know how that works - wouldn't it be like simply approving the top most version of the .po file?
<sil2100> Indeed, 65 .po files are in our langpacks...
<pitti> sil2100: sounds okay; it *should* be enough to approve it on one architecture only (but I'm not sure)
<seb128> those are not by arch afaik
<pitti> hm, I thought they were
<pitti> but even if not, 65 projects times 50~is languages is still "OMGlots" for a human
<seb128> https://translations.launchpad.net/ubuntu/wily/+source/nautilus/+imports
<sil2100> http://paste.ubuntu.com/11847166/
<seb128> we are speaking about templates no?
<Laney> is it not scriptable via the API?
<pitti> NB you need the po files too, not just the pots
<seb128> not languages
<pitti> ah, po files get auto-approved then?
<sil2100> We have .po's for these packages
<dpm> Laney, there is no API
<dpm> for translations
<pitti> ah, so it's not the 14000 files from https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED
<doko> mvo, please could you merge snappy, and then do a follow-up upload to the ci-train 16 PPA ?
<dpm> actually, there is a bit for templates
<seb128> well, outdated ones, since they are based on the outdate templates
<pitti> but just the 425 from https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED&field.filter_extension=pot
 * dpm reads scrollback
<pitti> sil2100, seb128: I'm confused -- if you already have the .po's, what's blocking you?
<pitti> the *.po are all we care about in langpacks/exports
<seb128> pitti, the po they have are outdated as just written
<pitti> the *.pot is "just" for LP itself to know which strings to put into *.po files and to translate the strings
<pitti> seb128: so we *do* need the po files, not just the pots
<seb128> they are based on wrong templates
<sil2100> pitti: I don't know too much about that, but those .po files haven't been updated with new translations, which didn't get imported
<pitti> right
<sil2100> pitti: but we'll get the .po files from the export
<seb128> well I expect once the template are updated things are good
<pitti> so I misinterpreted
<pitti> sil2100 | We have .po's for these packages
<seb128> the translations are shared with trunk
<pitti> seb128 | we are speaking about templates no?
<sil2100> pitti: I said for the list above
<pitti> we *do* need LP to import all *.pot *and* *.po files from wily then
<sil2100> pitti: I pasted http://paste.ubuntu.com/11847166/ and said that these are the apps we have in the langpack
<pitti> ok
<pitti> sorry for the confusion
<seb128> pitti, I'm unsure the .po *import* are needed
<sil2100> I think I caused some confusion here ;)
<seb128> the strings come from trunk
<pitti> seb128: how could they not be needed?
<seb128> ^
<pitti> if the current po files are outdated, we need to import the current ones
<seb128> because translation sharing with trunk is active
<pitti> ah
<mvo> doko: you mean upload the latest snappy into ppa-16? sure, I can do that
<mvo> doko: I guess a PPA copy with rebuild is also ok?
<mvo> doko: from our daily build snappy ppa?
<pitti> 3 templates out of 425 imported in teh last 3 minutes
<doko> mvo, but first merge it to wily. I'm talking about https://tracker.debian.org/pkg/snappy
<doko> mvo, no, different upload with a higher version number
<pitti> from that we could estimate that it imports all 425 in ~ 8 h?
<mvo> doko: oh, that snappy, sorry, I was confused
<pitti> seb128, sil2100, wgrant: so did I get this right: we don't care (right now) about the 14000 *.po imports, just the 425 *.pot -> thus we could set all *.po to "needsinfo", and just let it import the pot
<pitti> and once that's done, put the *.po back to approved to import them too?
<seb128> wfm
<pitti> and let message sharing take care of actually providing translations for wily?
<sil2100> If you guys think that would work, +1 from me ;)
<pitti> it's a theory based on what I learned in the last 5 minutes, don't take it for granted -- it needs to be wgranted
 * pitti chips in 5 bucks into the "bad pun" cash savings box
<seb128> :-)
<dpm> assuming message sharing works as we expect, yes, it should work
<sil2100> I just want the latest strings imported to the translations for wily so I can request an export and get properly updated .po files ;)
<sil2100> pitti: ;)
<sil2100> wgrant: what do you think about pitti's idea ^ ? :)
<dpm> i.e. the templates would be up-to-date in LP once imported, and the export would put the translations from the DB into the final .po files, without needing to wait for the *.po import
<pitti> it should import 400 pots in the course of minutes, based on the progress on seb128 | we are speaking about templates no?
<pitti> eww, x c&p buffer!
<pitti> ... on the progress on https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED
<pitti> X c&p is seriously broken from firefox
<dpm> actually, wgrant, do the PO imports need to be set to Needs Review at all? I.e. if the export is not blocking on the po imports, we can just trigger an export after the 425 templates have been imported, without further action
<pitti> right, but we need to do the pots first, not 100 po files in between each pot
<pitti> apparently it' just one big shuffled blob right now, the *.pot don't get prioritized
<dpm> pitti, I think templates are imported first, but we'd need confirmation from the LP guys
<pitti> dpm: no, demonstrably not
<pitti> dpm: it imported several hundred *.po files but only 3 pot files during this talk
<pitti> dpm: compare progress on https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED with https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED&field.filter_extension=pot
<dpm> were the imported .po files corresponding to the 3 pot templates?
 * dpm looks
<pitti> importing pot first -> few minutes; import everything in that semi-random order: -> 8 hours
<mvo> doko: snappy is uplaoded
<wgrant> sil2100, pitti, dpm: Sorry, was eating. I think that POT-only approach sounds reasonable.
<doko> mvo, hmm, ok, but that version number looks odd when copied to the archive
<sil2100> pitti, wgrant, dpm: who can do this magic then?
<dpm> wgrant, pitti, seb128, one thing to bear in mind is that not all templates are set up to message share with upstream trunk, but I think we might be able to assume that most if not all the packages for the phone are set up this way
<seb128> dpm, we basically think we need update to dialer/messaging/browser
<mvo> doko: uh, sorry, let me remove and upload again
<seb128> so I think it should be ok
<dpm> seb128, in that case, yes, these should be set up like that, but let me check
<seb128> k
<seb128> thanks
<sil2100> And ubuntu-system-settings too
<dpm> seb128, ok, I can confirm those 3 from https://translations.launchpad.net/ubuntu/vivid/+templates (the wily page is not yet up while templates are being imported, but the sharing configuration is copied over)
<seb128> dpm, thanks
<seb128> dpm, u-s-s as well?
<dpm> sil2100, that one is sharing with trunk too, confirmed
<sil2100> And unity8 I suppose?
<dpm> lol
<sil2100> ;)
 * dpm checks
 * sil2100 looks at the list before saying anything more
<doko> siretart, ping on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777781
<ubottu> Debian bug 777781 in src:aspectc++ "aspectc++: ftbfs with GCC-5" [Serious,Open]
<dpm> sil2100, unity8 shares translations with trunk too
<sil2100> dpm: could you also check address-book-app, indicator-network, indicator-sound, indicator-bluetooth, indicator-transfer, indicator-messages and mediaplayer-app?
<sil2100> Not sure if we had any changes in the indicators, besides the network one...
 * dpm checks
<dpm> indicator-transfer and indicator-display are not set up for sharing
<dpm> indicator-network and indicator-location are set up for sharing, but I'm not sure if with the right branch (they're using indicator-network/14.10 and indicator-location/14.04)
<dpm> seb128, sil2100 ^
<dpm> sil2100, seb128, in summary, it seems some of the indicators need to be set up for sharing: http://pastebin.ubuntu.com/11847330/
<dpm> the problem is that for some of them translations are not enabled on the upstream project :/
<sil2100> dpm: ok, but if that's the case, then it didn't have that in the past as well...
<wgrant> dpm: We can use the API to approve the POs selectively relatively easily.
<wgrant> (there is an API for one part of Translations: the import queue)
<dpm> aha!
<wgrant> To start, I intend to set all non-POT Approved wily imports to Blocked.
<wgrant> The POTs will import relatively quickly, and we can import POs as required.
<wgrant> When things are sorted out, we can re-approve the rest.
<wgrant> Any objections, or shall I carry out the first step?
<pitti> sounds good to me
<pitti> importing the pots should only be a few minutes
<dpm> great
<hjd> Laney: Hi, I saw the discussion above. If you do end up merging pcre3, could you leave a comment at and/or close bug 1457964? :) It should be fixed in Debian, so I believe it's simply waiting for a merge.
<ubottu> bug 1457964 in pcre3 (Ubuntu) "pcre3: enable jit again on ppc64el" [Low,Confirmed] https://launchpad.net/bugs/1457964
<Laney> hjd: hi, ok
<hjd> Thank you :)
<sil2100> dpm, pitti, wgrant: is anyone doing all the dirty work for that? :)
<pitti> I thought it required SQL? can't do that
<wgrant> sil2100: Yep, waiting for sysadmins.
<doko> mvo, snappy failed to upload
<sil2100> wgrant: thank you!
<sil2100> seb128: so in the meantime I won't be reverting the langpacks that I uploaded since we're not having another image now anyway... QA can test translations later, once we have proper .po files
<sil2100> seb128: I'll prepare then once we have the right export
<sil2100> seb128: thanks for bringing this up and sorry for the mess-up, seems I didn't have enough data about the state of the translations
<smb> pitti, I think I found some explanation for bug 1466790. Not sure my "fix" is reasonable or makes systemd people run away screaming...
<ubottu> bug 1466790 in ifupdown (Ubuntu) "dhclient does not remain running on boot" [Undecided,New] https://launchpad.net/bugs/1466790
<dpm> seb128, howcome we're grabbing translations from wily for ota5?
<pitti> smb: looking in a bit; still having infinite fun with more broken swap partitions and ecryptfs-setup-swap..
<pitti> kirkland, cyphermox: did we ever start a discussion on some "official" place (blueprint/bug) about stopping configuring swap partitions in the installer?
<dpm> seb128, ah, I get it, messaging-app & co are .debs and depend on newer templates on vivid, right?
<sil2100> dpm: since we don't have the infra set-up for overlay translations yet
<sil2100> dpm: but since we're using dual landing for most packages, wily and vivid have the same sources
<smb> pitti, sounds like a tar pit of fun...
<pitti> err, WTF
<pitti> $ dpkg -L libecryptfs0
<sil2100> So temporarily, as a quick workaround, we're using the wily ones
<pitti> /usr/lib/libecryptfs.so.1
<pitti> kirkland, tyhicks: ^ noooo
<sil2100> dpm: as this is the only thing we can do this time
<dpm> thanks sil2100
<dpm> sil2100, once the overlay is set up, where will translations be done?
<sil2100> dpm: the proposed solution is to use the ubuntu-rtm distro for those
<mvo> doko: yeah, I'm fixing, thanks
<dpm> sil2100, oh I see, so should we then point translators to https://translations.launchpad.net/ubuntu-rtm once it's all set up?
<sil2100> dpm: yes, I suppose that's how it'll look like - there will be a proper announcement once that happens
<dpm> sil2100, ok, thanks. Another question: are there going to be series too, or will basically ubuntu-rtm be used effectively as rolling?
<wgrant> dpm: https://launchpad.net/ubuntu-rtm/15.04/+imports
<wgrant> Not active yet, so don't try to poke anything.
<wgrant> But translations from the vivid overlay PPA go there.
<dpm> wgrant, ah, cool, that answers it then, thanks!
<sil2100> :)
<pitti> smb: ah, are you using open-iscsi or something?
<pitti> smb: there are only two things that bring up /e/n/interfaces normally: /etc/init.d/networking and ifup@.service via udev
<pitti> smb: open-iscsi kind of hooks into that
<smb> pitti, Not really. I think MAAS deployments may include it. Oh... for bare-metal... yeah I may have installed open-iscsi to try something else
<smb> for reasons usually long forgotten because those were... err last week
<pitti> smb: so it could be that I don't see it because in my case init.d/networking already brought up everything, and thus ifup@eth0.service didn't really do anything ("interfacae is already up")
<Mirv> what's up with armhf builders btw? builds taking roughly double the time compared to June.
<Mirv> so qtbase takes 8+ hours instead of <=4
<smb> pitti, Right. Same with normal desktop as there network manager handles things
<mvo> doko: should be good now
<opiwahn> I have still no luck in booting in text mode in 15.04
<sil2100> pitti: hey! Do you know if there's any progress regarding translations?
<pitti> sil2100: apparently so - https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED is becoming smaller and just has POTs now
<sil2100> \o/
<cjwatson> Yeah, admins did the DB change for us
<sil2100> So once this queue gets empty, I can request a new export with the proper translations, right?
<pitti> I already requested a full export on https://translations.launchpad.net/ubuntu/wily/+language-packs
<teward> pitti: can I pick your brain again when you're a little less busy?
<pitti> so once the POTs are imported, the wily langpack cronjob needs to be restarted (by wgrant or cjwatson), then we should have an export after some hours
<pitti> teward: just ask, there's no better or worse time :)
<teward> pitti: so, three things.  First, i've got working apport hooks, plus code-checking to verify that the init system is actually systemd and not upstart (sicne I know someone who uses Upstart and not SystemD on a highly irregular 15.04 box).  There's two issues, though.
<teward> pitti: firstly, when pulling `systemctl -l status nginx-service` it says "Error: Exited with code 3" which is the error code systemd returns from the command - which in turn makes its way into the output file
<teward> secondly, i'd like to expand it to prompt the user for certain report types (Crash, Bug) if they want to include the error.log, nginx.conf file, and enabled site configs.
<teward> AFAICT those work fine, but the prompts run twice
<teward> such that P1 P2 P3 are asked, then it repeats the cycle
<teward> before going and finishing collection
<pitti> teward: that's from the command_output() wrapper; if you call a program which is expected to fail, then I suggest calling subprocess.getstatusoutput() directly
<teward> pitti: ok.  that's what I thought, i was hoping there was an easier method but ehh.
<pitti> teward: as I wrote this morning, I'd need to see the hook and where you put it
<pitti> teward: how could it be easier?
<teward> pitti: i didn't see that, sorry, my scrollback is limited on my bouncer :/
<pitti> teward: out = subprocess.getstatusoutput('meh')[1]
<teward> wow, i need coffee, I thougth i'd have to import another module, forgot I had to import subprocess for another function >.<
<pitti> quite possibly you only want to know whether it's running, then just check the return code instead
<teward> i hate mornings sometimes :P
<teward> pitti: actually the opposite - we want the information from `systemctl status nginx.service` because it actually spits the errors into there
<pitti> teward: ah
<teward> rather than "Is It Running" we need to know "Why Did It Fail To Start"
<teward> i'm hesitant to include the error.log because that could have sensitive information.  but the systemd status logs *would* tell us what happened
<teward> (whereas `journalctl -xe --unit=nginx.service` doesn't always show it)
<teward> i'm content to let it keep the "Error code 3" stuff in the message, since nginx *did* fail to start or isn't running.  but if there's a way to remove it that'd be even better
<teward> I have the two variant scripts stored in a VM, give me 3 seconds to pull them off there
<teward> (since my primary system is Trusty)
<pitti> teward: well, command_output()'s sole reason to exist is to provide exactly that functinoality; if you don't want it, just call getstatusoutput directly()
<teward> pitti: ack.  i'll use getstatusoutput in place of it
<teward> assuming the VM wants to actually start
 * teward hates VMs sometimes
<pitti> teward: actually, even easier: out = subprocess.getoutput('your command')
<pitti> (if you don't care about the exit code)
<cjwatson> check_output if you do
<cjwatson> subprocess.getoutput doesn't exist anyway :)
<pitti> not in this case, don't want to fail on exit code 3 (which is expected)
<pitti> cjwatson: err, what?
<teward> cjwatson: it works fine in python 3
<cjwatson> oh right
<cjwatson> stuck in the past
<pitti> I know, shell and all, but *shrug*, it's just a static commannd
<cjwatson> marked as legacy though :)
<teward> http://paste.ubuntu.com/11848412/  <--
<teward> cjwatson: 'tis fine :)
<cjwatson> I usually prefer subprocess.Popen([...], stdout=subprocess.PIPE).communicate()[0]
<cjwatson> or try: subprocess.check_output() except subprocess.CalledProcessException: re-raise anything with an unexpected exit code
<pitti> cjwatson: yeah, I feel that's a rather big omission in the subprocess API
<cjwatson> latter could be wrapped up easily
<pitti> that there's no argv method for "give me the output of a program which is allowed to exit non-zero"
<pitti> except for the complicated one you mentioned
<pitti> anyway, bikeshed â green
<cjwatson> something like http://paste.ubuntu.com/11848429/
<teward> pitti: if you had a choice, would you use the Popen method or the getoutput method?
<cjwatson> untested, literally just typed into pastebin
<teward> i.e. which is less likely to explode in our faces five python revisions down the road :P
<cjwatson> I'd use the thing I just pasted :)
<pitti> cjwatson: does that actually give you the output on failure?
<pitti> teward: I usually use Popen()...communciate()[0]
<cjwatson> pitti: "The CalledProcessError object will have the return code in the returncode attribute and any output in the output attribute."
<pitti> cjwatson: ok, that's too contrived for my taste; I'm with communicate() :)
<cjwatson> pitti: ah, sorry, should also have a return e.output in the else case there
<pitti> barry: please just give us a subprocess.get_output(). love, pitti
<pitti> :)
<teward> heh
<barry> pitti: what's up? :)
<pitti> barry: bikeshedding above -- pythonic way to get the output of a program which is expected to return nonzero
<pitti> barry: i. e. the non-exceptionary variant of check_output()
<pitti> barry: nvm, it was just meant as a joke, but the API is oddly asymmetrical there
<pitti> teward: anyway, all this probably confused you more than it helped :/
<pitti> teward: cjwatson | I usually prefer subprocess.Popen([...], stdout=subprocess.PIPE).communicate()[0]
<pitti> teward: that'll do fine
<teward> i was going to use that anyways
<teward> i'm just currently debugging why sftp is blowing up in my face
<barry> pitti: ah :) i see you suggest Popen() directly, and yeah i'd agree.  i see what you mean, but non-zero exits are probably not handled because they *are* exceptional :)
<pitti> barry: right, it's just that subprocess.getoutput() is so darn convenient, if it wasn't for the shell/no argv
<barry> pitti: ah, yeah.  those are legacy apis after all
<teward> pitti: in that command you just stated, where [...] exists, that's the same syntax as command_output(['array','of','command','and','args']) ?
<teward> (i.e. just drop in the [ ] array?)
<pitti> teward: right, it's an argv
<teward> ack
<barry> of course 'array of command and arg'.split() works too
<Daviey> Be careful if using Popen.wait() for checking return codes, the logic was changed in 2.7 which can cause unexpected exit codes.. (due to the fix in http://bugs.python.org/issue14396)
<cjwatson> I basically think any non-argv process execution mechanism is a timebomb, if not due to underlying library changes, then a timebomb for future developers
<teward> pitti: and whoever else wants to spotcheck me: This is the bare minimum that should be in the hooks for now:  https://github.com/teward/nginx-apport-hooks/blob/master/no-config-prompts/source_nginx.py
<teward> and yes it's at github because version tracking is nice so I know what i did xD
<teward> and it's a bad thing i make a lot of helper functions, yes.  that's how i was taught coding though :/
 * teward needs to break that habit
<cjwatson> "github because version tracking is nice" -> logic does not follow :P
<barry> zyga: you're a "checkbox" guy right?  have a few moments for some questions?
<pitti> teward: the init system check is a bit broken -- it won't work right after you switch init systems, like after a dist-upgrade
<Daviey> teward: pep8! screen width isn't free you know!
<pitti> teward: os.path.isdir('/run/systemd/system') is the only tried and true, foolproof, and simple way to assert that
<cjwatson> teward: seriously, os.path.isdir("/run/systemd/system")
<cjwatson> I gave you that code last night :)
<pitti> teward: also, procps doesn't need to be installed
<cjwatson> and it's *shorter* than what you're doing
<cjwatson> teward: it's also the algorithm recommended in http://www.freedesktop.org/software/systemd/man/sd_booted.html
<cjwatson> ("A simple check like this can also ..." etc.)
<pitti> teward: if it's not systemd, it's upstart, no need to check for that
<teward> ok
<teward> cjwatson: i'm tired, my logic is slightly borked.
<pitti> teward: I'd eliminate the two def _systemd_*() and just fold them into add_info(), but that's a matter of taste; looks good aside from the init system check
<teward> got called to a 6AM "Emergency Fix It" thing :/
<teward> and i only had 3 hours sleep >.<
<teward> i shouldn't be awake
<pitti> (there's lots of other style issues, but I'll try to restrain myself :) )
<teward> :P
<pitti> i. e. the whole thing should be 5 lines tops
<teward> pitti: heh, yeah i tend to be overly verbose
<cjwatson> I don't think you should apologise for helper functions if they're well structured
<teward> Daviey: yes, i wanted something functional before making it look pretty
<Daviey> teward: fair enough :)
<zyga> barry: yes
<zyga> barry: absolutely
<zyga> barry: hangout or locally?
<pitti> cjwatson: right, I meant the True/False returns, nested ifs, and overly split single-use functions; but *argh* restrain myself harder *argh*
<barry> zyga: shouldn't take long, i'll pvtmsg you
<zyga> barry: thanks
<pitti> if report['ProblemType'] == 'Package' and os.path.exists('/run/systemd/system'):
<pitti>    <call journalctl and systemctl>
<pitti> that's really all it is
<teward> so then you want something like this then:  https://github.com/teward/nginx-apport-hooks/blob/master/no-config-prompts/source_nginx.py  (this is updated)
<rbasak> bdmurray: looking at the samba phasing stop with rharper, I don't really understand how to interpret the page your notice linked to.
<teward> pitti: ^
<rbasak> bdmurray: I can't see the data that suggests the error rate has increased
<rbasak> bdmurray: it looks like a constant stream of errors that has always been present. Is there a graph that'll actually show me the increase please?
<pitti> teward: heh, yes; os.path.isdir() would be a bit "more correct", but good enough like that
<teward> pitti: mmm yep i remembered that just now, lemme fix, then this is 'done' for now
<pitti> sil2100, cjwatson: https://translations.launchpad.net/ubuntu/wily/+imports?field.filter_status=APPROVED&field.filter_extension=all -> done!
<pitti> wgrant: so we can now revert that SQL magic and let the other po files get imported
<pitti> cjwatson: as wgrant is probably/hopefully asleep now, could you start the wily langpack export cronjob?
<cjwatson> pitti: I really have to go out for a bit, can it wait an hour?
<pitti> cjwatson: sure, I'm not waiting for it; sil2100 is
<cjwatson> pitti: is the langpack export useful without the po import?
<pitti> cjwatson: wgrant/seb128 believed so, due to translation sharing with trunks
<teward> pitti: cjwatson: Daviey: thanks to all of you for your help :)
<teward> i'll circle back later when i start stabbing the 'prompt to include other files' stuff
<sil2100> \o/
 * sil2100 needs the updated .po files
<kirkland> pitti: well, I filed a blueprint about it, in like...jaunty?
<kirkland> pitti: does that count?
<pitti> kirkland: apparently it wasn't implemented :)
<kirkland> pitti: :-)  let's get rid of it, and promote swapspace package to main
<kirkland> pitti: with some sane defaults
<pitti> kirkland: anyway, I piled up two patches for ecryptfs-setup-swap (second patch from today in wily), and some postinst (not sure if that is also in the upstream trunk)
<kirkland> pitti: interesting, I'll have a look
<kirkland> pitti: I have a flight tomorrow, I'll check it out
<kirkland> pitti: have you played with swapspace yet?
<kirkland> pitti: maybe try it out on your machine
<pitti> kirkland: no, I haven't yet; it's been ages since I wanted/needed swap
<kirkland> pitti: before I added 16GB of mem to my x250, I ran with 8GB and swapspace for a few weeks
<kirkland> pitti: agreed--me either, but I decided to give it a try
<kirkland> pitti: byobu monitors swap usage
<kirkland> pitti: it seemed to do the right thing
<kirkland> pitti: on a related note, G+ Hangouts are MEMORY HOGS
<teward> um... i forgot, so if someone would be willing to refresh my memory... if two releases of Ubuntu have the same package version number, and I need to fix in Wily and also in Vivid, what do I do with the version strings?
<sil2100> cjwatson: I can wait a bit if needed, just hope the export won't take as long as previously
<pitti> teward: normal increment for devel series (wily), and add 0.1 for SRUs
<kirkland> pitti: but I agree -- swap in general is as bad as subprime mortgages
<pitti> teward: that has been a common pattern for a long time; or just the wily version and append ~vivid1
<kirkland> pitti: you're loaning someone something that's ultimately going to make their life worse
<pitti> kirkland: hah, good one
<kirkland> pitti: I gotta go, customer meetings
<pitti> kirkland: yeah, I've now spent too many hours cleaning up after ecryptfs-setup-swap and we've shipped broken systems for years
<kirkland> pitti: could you drop me an email with a pointer to the patches?
<pitti> kirkland: o/
<teward> pitti: given that this is, of course, the nginx package and we have a pending plan of action (provided TB approves, once we send in), it won't remain the case going forward, but I think i'll do the .1 method
<pitti> kirkland: sure
<teward> pitti: i thought that was the case but I wasn't sure, thanks for confirming :)
<pitti> kirkland: mailed
<sil2100> cjwatson: could you simply give me a poke once the new, perfect and flawless LP translation export is ready? :)
<sil2100> Would be grateful
<om26er> pitti, Hi!
<om26er> pitti, is there a way to run a command *after* adt-run executes the tests ?
<pitti> om26er: a counterpart of --setup-commands? not right now
<om26er> pitti, yes and :/
<om26er> pitti, I kind of apt-mark hold a few packages and would like to unhold them after tests run
<pitti> om26er: it never came up yet
<pitti> om26er: hm, for most testbeds (ephemeral) that's pointless, and for non-ephemeral testbeds you can just do that after the adt-run call?
<om26er> pitti, hmm, I could change my test runner script to unhold packages after adt-run hmm.
<teward> anyone able to provide any insight to why an sbuild run would be 'attempted' but fail?
<teward> if i provide sbuild logs that is
<teward> (assuming it fails again)
<om26er> thanks pitti, let me see how far I can get with that.
<om26er> pitti, you might want to consider that feature for future releases, though.
<teward> (brb thoug ha moment)
<om26er> pitti, at what stage does adt-run installs dependencies ? I am looking inside run-system-tests script and can't see where it actually installs the debs.
<teward> I'm either blind or can't figure it out, anyone know why this is failing?  http://paste.ubuntu.com/11849975/
<teward> (it's an sbuild log)
<zyga> barry: hey, how can I build against python3.5?
<zyga> barry: can I add a PPA to my wily schroot?
<zyga> barry: or should I use sid?
<zyga> barry: I have a patch that test builds in both places but I'm unsure if that's with 3.5 now
<barry> zyga: easiest right now is to add the pythoneers/py35asdefault ppa
<barry> zyga: or
<zyga> deb http://ppa.launchpad.net/pythoneers/py35asdefault/ubuntu wily main  ?
<barry> zyga: that should work.  i always use add-apt-repository from software-properties-common
<zyga> ah
<barry> add-apt-repository ppa:pythoneers/py35asdefault should do it
<barry> (there's also a purge-ppa which mostly undoes that)
<teward> barry: what do you know about diagnosing sbuild failures, if anything
<teward> sorry, i'm just kinda scratchin my head here tryin to solve this 'fail'
<barry> teward: a bit.  i use sbuild all the time
<teward> barry: http://paste.ubuntu.com/11849975/  <-- can't wrap my head around this
 * zyga tries with 
<teward> it shows 'attempted'
<zyga> sbuild -d wily --chroot-setup-commands='apt-key adv --keyserver keyserver.ubuntu.com --recv-key 224D9D15EE176F89' --extra-repository 'deb http://ppa.launchpad.net/pythoneers/py35asdefault/ubuntu wily main' --extra-repository 'deb http://archive.ubuntu.com/ubuntu wily universe'
<teward> but it's not a code break, barry
<teward> at least not afaict
<barry> teward: is the build failure on line 4074 you're wondering about or something else?
<teward> barry: that's the only failure i can find
<teward> so it goes 'attempted' not 'failed'
<teward> but it's equivalent
<zyga> barry: hmmm, I'm doing something wrong because...
<zyga> I see this:
<teward> barry: same package doesn't have the problem in vivid
<teward> (vivid and wily have the same code, and the same changes except for debian/changelog entires, with my sbuild runs today)
<barry> teward: that's some problem with the package's d/rules i guess.  but the nice thing is you can now do `schroot -u root -rc <session-id>` and then drop into the chroot and poke around at the errors, retry the build, etc
<zyga> http://pastebin.ubuntu.com/11850070/
<barry> teward: sbuild is great at giving you a debuggable environment when the builds fail
<teward> barry: i'm not sure where to check next :/
<barry> teward: sorry, i can't help much with that right now; i don't know much about the nginx packaging
<barry> zyga: hang on, i have a script that helps
 * teward grumbles
<zyga> barry: why doesn't it see all those deps? are they not in wily now (they must be, they were in vivid)
<teward> this is a pain, it builds FINE in Vivid, fails in Wily
<barry> teward: likely toolchain or dependents differences
<teward> then how the heck did the thing build :/
 * teward grumbles
<zyga> barry: and this is the patch I'm test-building http://paste.ubuntu.com/11850085/
<barry> teward: if there have been no changes since vivid, it probably hasn't been rebuilt since then
<barry> zyga: bzr branch lp:~barry/+junk/repotools
<barry> then:
<barry> sbuild ... --chroot-setup-commands="/repo/sbuildppa.sh" ....dcs
<barry> *dsc
<barry> zyga: but also look at: https://wiki.ubuntu.com/SimpleSbuild#Local_packages
<barry> zyga: anyway, that's the recipe i use
<zyga> thanks
<teward> i should probably try the merge from debian then locally and see if THAT builds
<teward> because if it doesn't i fear the package will fall out of the repos
<barry> teward: take a look at the upload history.  maybe there's another dev around that has more immediate experince w/nginx
<teward> barry: mmm... that'd be me
<teward> :/
<barry> teward: oh ;)
<teward> i've never seen this type of failure
<barry> teward: looks to me like debian/tmp/use is nonexistent in the chroot
<teward> barry: what would even cause that to be created though... I've grep'd everywhere and there's no reference to it, the only thing I can think of is the build process has been changed
<teward> and if it has, i need documentation on that to try and debug
<barry> teward: maybe a debhelper change?
 * barry is just guessing tho
<teward> barry: i'm guessing too
<teward> who's in charge of the debhelper changes if any
<barry> that's mostly inherited from debian
<teward> so I should go to #debian and throw things at them, then... *shrugs*
<barry> tho i'm sure there are ubuntu deltas, i doubt this is the cause of your pain
<teward> well then i'm going to have to stab rbasak and get him to priority 1 the TB email
<teward> since my GUESS is that there's changes between 1.6.x to 1.9.x which fix the build fails
<tarpman> no stabbing rbasak. i might still need him alive
<teward> and any merge to Wily is dependent on an X-series TB exemption approval
<zyga> barry: weird
<zyga>  sbuild -d wily --chroot-setup-commands='apt-key adv --keyserver keyserver.ubuntu.com --recv-key 224D9D15EE176F89' --extra-repository 'deb http://ppa.launchpad.net/pythoneers/py35asdefault/ubuntu wily main' --extra-repository 'deb http://archive.ubuntu.com/ubuntu wily main universe'
<zyga> this builds for me
<zyga> so I had to add wily into the ... wily schroot?
<teward> god I hate my computer
<zyga> teward: hey, want to see mine ;)
<teward> zyga: can i light it aflame out of spite?
<teward> (loljk)
<teward> sorry i've been bashing my head against nginx for too long the past 3 days
<zyga> teward: GPU burned, keyboard stopped working on the left side, got new GPU, won't fit case, got new case, wont ship for a week (holidays)
 * teward mumbles something about apport hooks
<teward> heheheh
<zyga> now I'm computing with all the guts out, on the desk
<zyga> oh and today morning I had to take out 3 ram sticks or it would not boot
<zyga> I guess summer isn't healthy for hardware
<teward> and three hours sleep isn't healthy for maintainers
 * teward grumbles
<zyga> barry: built and tested fine, I'll commit to debian and ask for upload
<barry> zyga: +1
<pitti> om26er: you see it in the logs; it opens testbed, runs --setup-command / apt-get upgrade, copies the test into the testbed, reads test deps there, and installs them, then runs the test
<zyga> barry: sent, CCd
 * zyga -> off
<barry> zyga: thanks
<teward> when using udd / bzr to merge from Debian, how would one resolve this caused by Debian removing the file?  Contents conflict in debian/index.html
<teward> nevermind
<teward> barry: how can i drop into the failing schroot
<barry> teward: grab the id of the schroot from the sbuild output at the bottom and: schroot -u root -rc <id>
<teward> thanks
<teward> who here knows the most about how debhelper and package building has changed for Wily
<teward> (i.e. debhelper, etc.)
<teward> barry: you wouldn't happen to have any scripts lying around that would take in a list of releases and sequentially build multiple arch's schroots for sbuild, would you?  Just curious, if not i'll write one
<sarnold> teward: there's a little tiny copypaste on https://wiki.ubuntu.com/SecurityTeam/BuildEnvironment -- search for "finally"
<teward> aha!
<teward> sarnold: thank you kindly :)
<barry> teward: glad sarnold pointed you to the script.  i have a bunch of little doodads in lp:~barry/+junk/repotools
<teward> barry: i might steal xD
<teward> or borrow :)
<barry> teward: enjoy! :)
<mwhudson> so um er is the powerpc64le abi documented anywhere? <- infinity you'll know this?
<mwhudson> nm, found it
<teward> so, new question.  For installing .apport files, the package needs to build-dep on dh-apport right?  And do I need to call dh_installapport in the debian/rules ?
<teward> wait i think i figured it out...
<teward> mmm... nope
<teward> anyone got any guidance on actually getting the .apport files installed with the given binary package?
<teward> (E: No Documentation)
#ubuntu-devel 2015-07-10
<cyphermox> teward: I think most packages instead ship the file using their install files
<teward> cyphermox: infinity said dh_apport / dh_installapport so eh
<teward> cyphermox: i'm trying to ship inside the .install files but apparently it's not included in the .deb
<teward> unpacking the binaries yields the file not being present
<cyphermox> ie. usb-creator ships source_usb-creator.py to usr/share/apport/package-hooks
<cyphermox> my info may be outdated, or most packages may need to be updated :)
<teward> cyphermox: would that be doable on a per-binary basis, i.e. if the source package produces 5 primary binaries, of which only 4 need the apport hooks, there's a package.py for each of those?
<cyphermox> or you could ship just one for the source package
<cyphermox> either way works, but having just one is probably better if it turns out to be the same file for each binary
<teward> ... true... but then i run into the -dbg packages getting it, and the -common package getting it
<teward> cyphermox: this is for the nginx package, and it contains hooks for Package class bugs/failures, because those bug reports currently suck to a level I can't safely say here, due to systemd hiding the 'error' output from the 'start' task
<cyphermox> in this case what I've seen was the -common package shipping it for the source, and you probably don't need a -dbg since we create them
 * teward shrugs
<cyphermox> how's your rules?
<infinity> teward: I never said anything about dh_apport, I only pointed you to the manpage when you asked how it worked. :P
<teward> ahhh
<teward> infinity: okay, then i misunderstood
<infinity> teward: It's perfectly reasonable to install it by hand, either with dh_install or cp. :P
<teward> heh
<teward> infinity: then i misunderstood you, I apologize
<infinity> teward: And I'd agree with the crowd that having one hook for the source package and installing it to (only) -common makes the most sense.
<teward> infinity: and apport will understand source_nginx.py applies for nginx*?
<teward> or rather, automatically know it refers to all binaries?
<teward> or am I gonna have to postinst script it for -common?
<teward> (for symlinks anyways)
<infinity> teward: apport knows to map binary->source in some fashion.  I forget what that fashion is. :P
<teward> heh
<teward> i know i have it working for Vivid to cp the .py into where it needs to go...
<infinity> Oh, it's just source_$package.py ... That's simple enough.
<teward> ... but I'm having a hard time figuring out why the same codechanges don't work in WIly
<teward> and it's one of those headscratcher moments
<teward> 'cause i've been beating it all day
<infinity> teward: Yeah, just source_nginx.py should do it.  Apport will do the dpkg lookup for the binary->source mapping, then run the source hook (if there's no binary hook, which there shouldn't be in this scheme)
<teward> infinity: any special consideration with regards to debian/rules and the package itself, other than the install of the .py ?
<infinity> teward: I'm not an apport expert, but I'm pretty sure you just drop the hook in the right directory, and you're done.
<infinity> teward: So, just put it in nginx-common.install or whatever.
<teward> ack
<teward> i'll poke at this tomorrow
<teward> i'm waaay too tired to test things xD
<teward> but thanks for clarification and more insights :)
<teward> cyphermox: FWIW, the rules here're from Debian, the last time they were revised was for enabling PIE and other hardening flags, and even then this channel was more than helpful in fixing a failure somewhere along the lines :)
<teward> actually... was that you, infinity, who helped solve that, or was it someone else?
<teward> I forget, i interact with so many people xD
<infinity> Sounds like something I'd do.
<teward> well, in either case, those changes made their way into debian
<cyphermox> good
<teward> so the SRU and direct upload for... I think it was trusty/utopic/vivid at the time... had the PIE and other missing hardening flags put in
<teward> i forget... DAMN now I want to dig into the changelogs
<teward> hmm, maybe it was just Vivid...
<teward> yep, SRU'd to vivid... *shrugs*
<teward> anyways, thanks for the direction points to look at, infinity and cyphermox.
<cyphermox> no worries
<teward> and as always, thanks again to all who help out with these things :)
<teward> because i think i'd have thrown the nginx package into oblivion by now xD
<cyphermox> teward: we all eventually break things, trick is to know, accept it, and fix it :)
<teward> cyphermox: and acknowledge that when you aren't sure how to fix, you and and likely should ask for help XD
<teward> cyphermox: at least i'm not some newbie who uploads to a PPA 50 times and taxes canonical's infrastructure with all their fails
<teward> i try and stick to my local sbuild for that xD
<teward> although I sure remember when I was one of those newbies xD
<cyphermox> some things are really hard to properly stage without a PPA
<teward> or sbuild and a local VM
<teward> which is what i've been doing all day XD
<cyphermox> (or, I should say, without a PPA if you don't want to spend hours setting up infra)
<cyphermox> yeah, I noticed
<teward> building, testing, building, testing, shredding, building, testing xD
<cyphermox> fwiw, sbuild-launchpad-chroot is pretty cool to get you nice up-to-date chroots quickly
<teward> cyphermox: FWIW this is the one thign I hate about systemd: job start errors aren't grabbed by apport anymore during a postinst fail
<teward> it just says "Job failed, refer to [two other commands] for details."
<teward> for service failed to start problems
<teward> and with nginx Vivid, we had... *pulls list*
<teward> ... at least six or seven... bugs that are ambiguous as all hell since there's no usable debug info
<teward> hence my getting up off my butt, deprioritizing the nginx Wily merge prep, and working on this apport hook stuff :/
<teward> which in turn as soon as I get working and provably so with test cases i'm going to upload... cause i'm tired of ambiguous nginx postinstallation failed bugs.  So's sarnold and rbasak.
<teward> anyways, i'm off, good night
<pitti> Good morning
<pitti> teward: it's dh_apport, but yes
<pitti> teward: man dh_apport
<pitti> teward: either ship a source_<srcpkgname>.py which applies to all binaries, or a <binarypkg>.py and perhaps symlinks for the other packages
<pitti> teward: it's all in /usr/share/doc/apport/package-hooks.txt.gz
<pitti> teward: we never grabbed job start errors in apport
<pitti> only indirectly via package install failures, but their logs didn't contain syslog or upstart logs by default either
<pitti> makes sense for a package to include theirs, of course
<pitti> that's why we have apport hooks
<tjaalton> why aren't packages like libuid-wrapper synced from debian to wily?
<tjaalton> hmm nevermind
<tjaalton> realized that it's probably in universe instead
<tjaalton> and in vivid too :)
<tjaalton> so sssd needs it in main
<tjaalton> libnss-wrapper too
<tjaalton> when are we going to get rid of main/universe split again?
<Noskcaj> tjaalton, once we MIR every package?
<tjaalton> no
<tjaalton> there's an old blueprint about it
<Noskcaj> huh
<tjaalton> https://blueprints.launchpad.net/ubuntu/+spec/foundations-r-finish-archive-reorg
<tjaalton> cjwatson: is this ^ again in the horizon now that lp is getting more love these days?
<dholbach> good morning
<sil2100> pitti: piiing
<pitti> hey sil2100
<sil2100> pitti: hey, again me and again regarding translations (as I'm assuming you have more knowledge than I do here) ;)
<sil2100> pitti: a strange thing happened
<sil2100> Around the beginning of the week we had an ubuntu-system-settings released to vivid and wily with a string change
<sil2100> It changed "Install & Restart" to "Restart & Install"
<sil2100> https://translations.launchpad.net/ubuntu/wily/+source/ubuntu-system-settings/+pots/ubuntu-system-settings/fr/347/+translate <- but the LP template still has the old one
<sil2100> Didn't we import all the new strings to templates yesterday?
<seb128> https://translations.launchpad.net/ubuntu/wily/+source/ubuntu-system-settings/+imports indicates there are not be template import for the recent builds
<pitti> oh right, latest from May
<seb128> pitti, ?
<seb128> " Uploaded by Steve Langasek on 2015-07-02 19:35:20 CEST "
<seb128> pitti, weird thing is that the most recent package build
<seb128> https://launchpadlibrarian.net/210643779/buildlog_ubuntu-wily-amd64.ubuntu-system-settings_0.3%2B15.10.20150703-0ubuntu1_BUILDING.txt.gz
<seb128> has
<seb128> " 69979f587d60fac3711adab7320a0700ceac2ac7 1655913 ubuntu-system-settings_0.3+15.10.20150703-0ubuntu1_amd64_translations.tar.gz"
<seb128> sorry, https://launchpadlibrarian.net/211136452/buildlog_ubuntu-wily-amd64.ubuntu-system-settings_0.3%2B15.10.20150708-0ubuntu1_BUILDING.txt.gz
<seb128> but launchpad doesn't have it
<seb128> pitti, http://paste.ubuntu.com/11854869/
<pitti> hmm
<seb128> works on 0.3+15.10.20150622-0ubuntu2 though
<pitti> wgrant: do these imports only happen from the time on when these magic check boxes get unchecked?
<seb128> so it's like launchpad didn't get the translations tarball
<pitti> yesterday I got asked to fiddle with https://translations.launchpad.net/ubuntu/wily/+translations-admin , maybe that did the trick?
<wgrant> pitti: No, those checkboxes only delay Approved entries from being imported.
<sil2100> hmmm
<cjwatson> tjaalton: not currently scheduled
<tjaalton> cjwatson: ok
<seb128> wgrant, any idea why the most recent ubuntu-system-settings builds don't have their translations tarball in launchpad?
<seb128> wgrant, cf what I just copied in backlog, the pastebin a small lp-shell log showing the data seems to not be there
<seb128> where it's there for the older uploads
<cjwatson> tjaalton: (and it's Hard, so would need a significant slot of time)
<cjwatson> seb128: perhaps related to it being in universe?
<seb128> cjwatson, it always was in universe
<cjwatson> this may be irrelevant, it's hot and I'm really not very awake
<wgrant> universe hasn't been relevant since oneiric.
<seb128> https://translations.launchpad.net/ubuntu/wily/+source/ubuntu-system-settings/+imports has recent imports
<seb128> since it stopped importing for a week or so
<tjaalton> cjwatson: understood
<wgrant> seb128, pitti: Ah, got it.
<wgrant> seb128, pitti: The new tarball ended up in the 2015-06-25 queue item
<seb128> ?
<wgrant> That's correct.
<seb128> how come
<wgrant> Also correct.
<wgrant> For reasons I've never been able to fathom, Translations will attempt to update an existing import queue entry if it can, rather than creating a new one.
<wgrant> In this case, it apparently decided that updating the third newest one was a grand idea.
<wgrant> So the newest one, which wasn't updated, got imported over the top of the actual new template.
<wgrant> Copying the package back in may fix it, but I forget in which scenarios the custom copier hack applies.
<cjwatson> All copies, pretty much.
<wgrant> Even a copy that actually does nothing because it already exists?
<cjwatson> Think so, let me check
<wgrant> Good lord.
<cjwatson> Yeah, the copier doesn't bail out early or anything, that would be clever.
<wgrant> Perhaps this is a good time to dig through history to discover why somebody thought it would be a good idea to update an existing queue item rather than adding a new one.
<wgrant> sigh
<cjwatson> But handy in this case :)
<wgrant> Oh yes, certainly.
<cjwatson> Batshit *and* useful.
<wgrant> The best kind of batshit insanity.
<cjwatson> (I can say that since I'm reasonably sure it was my fault.)
<wgrant> I've actively ignored the custom upload copier since long before you came onto the scene.
<wgrant> But indeed the packagecopier integration was at your hand.
<wgrant> seb128: So indeed it seems that copying the package over itself will fix it.
<wgrant> Ohhhhh
<wgrant> It chose that entry because it matches on the importer.
<wgrant> That is the second most stupid thing I've seen today.
<wgrant> After the custom upload copier :)
<wgrant> cjwatson: Do you have any idea why Translations attempts to update existing entries?
<wgrant> It goes back more than nine and a half years, so I doubt it, but you have the benefit of a heat-addled brain.
<cjwatson> wgrant: None whatsoever, I tried as hard as I could to ignore Translations for many years
<wgrant> Heh, yes...
<cjwatson> (Which often wasn't very well, but the extent to which I touched it was entirely client-side)
<cjwatson> Speaking of Translations, I think I can turn on ubuntu-rtm/15.04 imports now, if that's OK with you.
<wgrant> I let in a big batch of wily imports just before this incident came to light, so they won't process for at least several hours.
<wgrant> Given that that would push the first hacked import well into Saturday morning, I'm tempted to reblock those wily imports.
<JuNuKN_> Can someone point me in a direction how to prevent from a black screen, while ubuntu switches from plymouth to the unity desktop?
<cjwatson> wgrant: Are you suggesting that I'd be better off not unblocking ubuntu-rtm/15.04 just yet to avoid slowing down wily too much?
<JuNuKN_> On our system it needs 12 seconds, till the desktop is up and our fullscreen app is visible.
<wgrant> cjwatson: No, I just don't want the first import to happen as the US sysadmins disappear for the week.
<wgrant> cjwatson: For that reason I'm half way through reblocking the wily templates that I had unblocked.
<cjwatson> wgrant: Oh, right.  15.04 should be much quicker, so I might go ahead with at least one of those.
<cjwatson> Actually, there are only nine templates here, how bad can it be.
<wgrant> cjwatson: Yep, but they wouldn't have processed until tomorrow morning wile whily had translations approved.
<cjwatson> Yeah
<wgrant> My only concern is that the first overlay import not occur while we have nobody around to fix any explosions.
<JuNuKN_> Can someone point me in a direction how to prevent from a black screen, while ubuntu switches from plymouth to the unity desktop? On our system it needs 12 seconds, till the desktop is up and our fullscreen app is visible.  I wan't to prevent the user sit in front of a black screen,- better would be to still let the splash screen up, till I quit plymouth my self with our app
<Laney> doko: looks like pcre3 needs some work, std::basic_string in exported symbols
<doko> Laney, you mean, in the ppa?
<Laney> I did a test build against the ppa
<doko> Laney, just upload it then in the ppa, I'll leave a comment in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791236
<ubottu> Debian bug 791236 in src:pcre3 "pcre3: library transition may be needed when GCC 5 is the default" [Important,Open]
<Laney> sure
<Laney> I will use a non archive version then though
<doko> no, we will copy it to the archive
<Laney> not if it fails to build
<Laney> ?!?!
<doko> well, upload a version to the ppa that does build =)
<Laney> you probably want the maintainer to decide what to do
<Laney> http://paste.debian.net/281022
<Laney> they don't have the symbols file in debian btw
<doko> can you leave a comment in the report?
<Laney> ok
<Mirv> if anyone is interested, there's a hung armhf builder that failed to finish and also failing to cancel at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+build/7638685
<cjwatson> Mirv: Curious.  Will look once I get logs extracted via webops.
<cjwatson> Looks like it failed to build but then hung when trying to retrieve files.  No sign of a cancel actually being processed at the buildd-manager level.
<Mirv> cjwatson: hmm, this amd64 build is also hung, and I'd want to cancel and rebuild it properly (without reuploading)
<Mirv> this = https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+build/7638376
<cjwatson> Mirv: there's lots of firewall-level trouble at the moment.
<cjwatson> Mirv: but you can try a cancel there and cross your fingers
<infinity> Mirv: I see no indication that build is hung.
<infinity> However, if there are network issues, buildd-manager might have "lost" the buildd, and might need a restart.
<Mirv> cjwatson: ok. well I can also see if it at some point finishes by itself
<Mirv> infinity: it usually takes 2h for that to build so I assume it has stayed at that point for the last 4 hours.
<infinity> Mirv: Yeah, I'm fairly sure the build itself is complete (on the buildd), it's that LP is failing to care.
<infinity> Mirv: And it seems there are larger issues afoot relating to that, so I'll let wgrant/cjwatson put out their fires.
<cjwatson> Right, I would suggest leaving things well alone at the moment.
<cjwatson> Our slave DB server is rather suspiciously doing nothing at all.
<infinity> Mirv: The reason I immediately called "nah, it's not hung", is because the last bit in the log tail is the part where sbuild lists all the contents of the debs... After a successful build.
<infinity> Mirv: So, all that's left to do is for the master to suck up the results and do things with them.
<cjwatson> And at least some connections to it are crashing.
<Mirv> infinity: yeah, leaving it alone seems right in case LP then gets back to business of getting the results
<rbasak> pitti: just one catch with that [trusted=yes]. I wonder if it is available in Precise?
<infinity> rbasak: trusted=yes works in precise (just tested)
<rbasak> infinity: oh, great. Should be no issue then. Thanks.
<rbasak> pitti: could you please take a look at bug 1455097? Alleged potential issues since systemd no longer uses /etc/pm/sleep.d/ but packages put stuff in there. Do we have the functionality we need provided for the systemd mechanisms also?
<ubottu> bug 1455097 in pm-utils (Ubuntu) "pm-suspend no longer run since upgrade to vivid" [Medium,Confirmed] https://launchpad.net/bugs/1455097
<pitti> rbasak: yes, I checked precise's apt-sources manpage, seems to be there
<pitti> rbasak: there is, one can put stuff into /lib/systemd/system-sleep/, but we don't actually want all the old pm-suspend quirks any more
<pitti> rbasak: so we could check which of the bits are really still needed, and link them from there
<cjwatson> wgrant: How does one set import_into using the translations import queue API?  https://translations.launchpad.net/ubuntu-rtm/15.04/+imports?field.filter_status=NEEDS_REVIEW&field.filter_extension=all is all "No import target selected yet", so setStatus(new_status="Approved") doesn't work
<cjwatson> Or is this suspicious on the grounds that it should have been preselected?
<teward> pitti: hate to ask, but in a source_package.py apport hook, is there a way to evaluate which package was filed against, so that i can exclude certain packages from the hook?
<teward> (the case of nginx-common failing its postinstall is different than nginx-* binary installs and doesn't need the same data)
<wgrant> cjwatson: Oh, hm, I guess auto-approval won't work without the templates already existing.
<pitti> teward: report['Package'].split()[0] (to cut off the version number)
<teward> thank you kindly :)
<pitti> teward: note that it's mostly just a dictionary, so you can do stuff like print(report) in your hook (or print(report.keys()) or so)
<cjwatson> I manually approved the unity-scope-click template to see if it would import, and it did,.
<wgrant> Yeah, that won't be a problem.
<wgrant> I forget if the POs will be automatically approved into the right place once the template is.
<teward> pitti: ack
<wgrant> cjwatson: There may be few enough (interesting?) templates in the overlay that it's reasonable to manually approve them. It's not currently possible to do so using the API, as potemplate etc. aren't exported.
 * pitti waves bye and good weekend!
<Laney> bye pitti!
<teward> see ya pitty!
<teward> pitti*
<teward> i hate autocorrect
<cjwatson> wgrant: Not too bad if it's just templates, although as yet nothing has auto-approved the POs.
<wgrant> cjwatson: They may not be autoapproved, though the gardener is slow and runs infrequently.
<wgrant> If it ends up being a problem, trivial exports of IPOFile and IPOTemplate are not intractable.
<cjwatson> Yeah.  I'll approve the templates and see what happens.
<cjwatson> Just opening the import form and hitting save DTRT, annoyingly
<wgrant> cjwatson: fsvo trt
<wgrant> cjwatson: Templates only share if the name is the same on both ends, but hopefully nobody's done anything weird in Ubuntu.
<cjwatson> Perish the thought.
<cjwatson> wgrant: With only POTs imported, a few spot checks are at least showing a respectable amount of green.
<cjwatson> I'll check in tomorrow or something to see if the gardener did anything.
<hjd> Hi all. The two packages https://launchpad.net/ubuntu/+source/modello-maven-plugin and https://launchpad.net/ubuntu/+source/sisu-plexus failed to build in Wily. Though it looks like they were simply synced before their dependencies had time to build. I've built both successfully on my Wily vm, so I believe that if anyone could poke them for a rerun that should resolve the build failures.
<cjwatson> hjd: Yes, those should have been dependency waits but were bitten by a known launchpad-buildd bug.  Both retried.
<hjd> cjwatson: Thanks :)
<Ionic> I think I just accendentally uploaded a package to upload.ubuntu.com (although I'm not sure how that even succeeded anonymously)
<Ionic> how can I remove that again?
<cjwatson> Ionic: What package name?
<cjwatson> Ionic: It will almost certainly just be harmlessly rejected, but let's check.
<cjwatson> dput anonymous uploads are fine; it's the signature that matters, and that's checked later.
<Ionic> cjwatson: cups-x2go
<Ionic> trusty
<Ionic> the signature is probably known
<cjwatson> Known to Launchpad doesn't necessarily mean it'll be accepted for an Ubuntu upload :)
<Ionic> I hope so
<cjwatson> 2015-07-10 16:30:11 INFO    Failed to parse changes file '/srv/launchpad.net/ubuntu-queue/incoming/upload-ftp-20150710-162910-014065/cups-x2go_3.0.1.3-0~135~ubuntu14.04.1_ppc64el.changes': Signing key 1AD23D1B8F087A35AB74BDE9F4A7678C9C6B0B
<cjwatson> 2B not registered in launchpad.
<cjwatson> And a binaryful upload would have been rejected later anyway.
<cjwatson> So you're fine
<Ionic> great! thanks
<Ionic> although it's weird that the key wasn't accepted
<cjwatson> Doesn't seem to be on keyserver.ubuntu.com
<cjwatson> And it would have to be specifically associated with a Launchpad user as well
<Ionic> not sure what the project has as a key
<Ionic> normally Ubuntu packages are being built in launchpad anyway, but maybe with a special key
<cjwatson> OK, but that's presumably for a PPA or something anyway
<Ionic> yep
<teward> where should I drop a wily udev naming algorithms question (for network interfaces)
<teward> here or -quality?
<teward> or #ubuntu+1
<melodie> hello
<melodie> xnox are you here?
<melodie> xnox I have posted a comment on bug #1326412 to your attention:
<ubottu> bug 1326412 in ubuntu-release-upgrader (Ubuntu) "can't do dist-upgrade due to systemd" [Undecided,Fix released] https://launchpad.net/bugs/1326412
<melodie> https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1326412/comments/5
<melodie> as this bug was at that moment considered not important to fix in Trusty and I just hit it now in 14.04.2: Trusty is a LTS ...
<melodie> no solution here except maybe lock the packages, which is what I am now testing.
<xnox> melodie: let me just check to make sure everything.
<xnox> melodie: in trusty, this works correctly when booted with upstart.
<xnox> melodie: are you booted with upstart or systemd?
<xnox> (e.g. systemctl is-system-running vs initctl version) will tell you.
<xnox> initctl --system version; to be more correct.
<melodie> xnox I don't know how I can boot to upstart, and even worse, in a chrooted environment
<xnox> melodie: if you have a bug with
<xnox> melodie: if you see a bug in a chroot, this is a different bug then!
<xnox> melodie: although probably looks like this one =)
<melodie> xnox I can understand the "upgrade to next version" thing, idea, but with a LTS? seriously?
<xnox> pelase file a new bug with $ ubuntu-bug against well i guess ubuntu-release-upgrader and describe what you are seeing.
<melodie> wait
<xnox> melodie: all upgrades must work from Trusty, when trusty is booted with upstart.
<xnox> melodie: and we believe they do.
<melodie> I don't do upgrade I do dist-upgrade
<melodie> how do we get it to boot with upstart?
<xnox> melodie: if your host is trusty, and booted with systemd, that is entirely unsupported.
<xnox> melodie: first check what you are booted with.
<xnox> melodie: on the host, do $ initctl --system version
<xnox> if that says upstart, you are booted with upstart.
<melodie> I'll do
<xnox> melodie: to boot with upstart, you need to specify init=/sbin/upstart or remove systemd-sysv package.
<melodie> as soon as the actual update ends (I redid the environment)
<melodie> remove systemd-sysv ? that's all it takes?
<xnox> melodie: on upgrade to 15.10 or later, e.g. next lts. We upgrade systems to supported systemd config and reboot after upgrade gets one systemd.
<xnox> melodie: yes. and do note systemd is not supported on 14.04 LTS, the first LTS with systemd support will be 16.04 LTS
<melodie> xnox how is the setup done in the officiel Trusty versions?
<xnox> melodie: if you install trusty, you get upstart as pid 1, yet there are pieces of systemd daemons running.
<melodie> it seems that the systemd packages are installed there, aren't they?
<xnox> e.g. udev & logind are daemons provided by systemd package.
<melodie> yes they are :)
<xnox> melodie: systemd is a lot of daemons. In trusty, only udev & logind are used by default.
<melodie> I'll check to remove systemd-sysv once synaptic (chrooted synaptic) will have finished.
<xnox> the bug #1326412 is specifically about somebody changing trusty into a non-supportable configuration, or e.g. booting with init=/lib/systemd/systemd kernel command line.
<ubottu> bug 1326412 in ubuntu-release-upgrader (Ubuntu) "can't do dist-upgrade due to systemd" [Undecided,Fix released] https://launchpad.net/bugs/1326412
<xnox> and then doing upgrades with systemd as pid 1.
<melodie> well here there is systemd-services installed and if I try to remove it, half of the system is going away
<melodie> with it
<xnox> melodie: anyway $ initctl --system version -> will definately tell you pid1 is upstart. Then we can talk / file bugs troubleshoot more whatever you are seeing odd happening.
<xnox> melodie: do not remove systemd-services.
<melodie> I'll do initctl --system version as soon as synaptic finishes
<xnox> melodie: yeap. if that says upstart open a new bug report. If that errors out like so:
<xnox> $ initctl --system version
<xnox> initctl: Name "com.ubuntu.Upstart" does not exist
<xnox> then you are booted with systemd as pid1, and you really want to get off that on 14.04 LTS.
<melodie> initctl: Unable to connect to system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
<melodie> this is what it says
<xnox> your dbus seems to be dead....
<melodie> I'll try to start it manually
<xnox> melodie: you can check unix domain sockets with e.g.:
<xnox> $ netstat -n | grep upstart
<xnox> there should be one for system upstart.
<melodie> prompts comes back silent
<melodie> # service dbus start
<melodie> initctl: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
<melodie> also
<xnox> =(
<xnox> do you have $ ls /run/systemd/system ?
<xnox> if that folder exists, you have pid1 as systemd. and should get off it.
<xnox> cat /proc/cmdline might be a clue as well.
<melodie> looking
<xnox> (not having system dbus sounds like a really broken system, FYI)
<melodie> # ls /run/systemd/system
<melodie> ls: cannot access /run/systemd/system: No such file or directory
<xnox> i'd be tempted to say your machine is hosed.
<xnox> and i wonder if it will reboot.
<melodie> # cat /proc/cmdline
<melodie> root=/dev/sda3 resume=/dev/sda5 vga=775 ro
<melodie> well this is a chroot
<melodie> it won't reboot, it's not meant to reboot
<xnox> ....
<xnox> melodie: then please open a new bug against a package that failed to upgrade with your dist-upgrade log.
<xnox> melodie: bug you commented on, has nothing to do with a chroot upgrade problem.
<melodie> ah
<xnox> melodie: but if your host is running systemd, the chroot is unsupportable.
<xnox> melodie: i need to make sure the host is not running systemd.
<xnox> as pid 1 that is.
<melodie> I think I can check for systemd-sysv and remove it if it exists
<xnox> it doesn't matter what is installed in the chroot...
<melodie> how is that?
<melodie> I mean, I'll make eventually an iso
<melodie> then, if systemd-sysv is not installed it's better for the further use?
<xnox> you lost me.
<infinity> melodie: If you're having problems upgrading a chroot, systemd-sysv is irrelevant.
<infinity> melodie: But, sure, if that chroot is meant to become a live filesystem later, it shouldn't have systemd-sysv installed.
<infinity> melodie: But I doubt it does.
<melodie> hi infinity
<melodie> I just checked, not only it's not installed but it's not even in the packages list in Synaptic
<infinity> melodie: Okay, so I saw  your comment on the end of LP: #1325142
<ubottu> Launchpad bug 1325142 in systemd (Ubuntu Trusty) "failure to update libpam-systemd in 14.04 due to missing logind init script" [Undecided,Triaged] https://launchpad.net/bugs/1325142
<infinity> melodie: That has nothing to do with any packaging bug, it's that you're in a chroot environment.
<xnox> melodie: bug 1326412 only affects upgrades of certain packages, when pid 1 is unsupported systemd on unsupported releases (e.g. 14.04 LTS) in that case invoke-rc.d and friends fail to detect when stuff is in chroots and whether stuff should be started or stopped and fails to execute those things, hence making all sorts of problems...............
<ubottu> bug 1326412 in ubuntu-release-upgrader (Ubuntu) "can't do dist-upgrade due to systemd" [Undecided,Fix released] https://launchpad.net/bugs/1326412
<infinity> melodie: And your chroot should have a policy-rc.d to prevent invoke-rc.d from running at all.
<xnox> melodie: why are you in a chroot? and why don't you start out with a good chroot e.g. $ mk-sbuild trusty; schroot -u root -c source:trusty-amd64
<xnox> (or whatever arch you are on)
 * xnox got to run. melodie feel free to drop email to my irc nickname @ubuntu.com
<infinity> xnox: It's a chroot because they're building a new root filesystem.
<infinity> melodie: http://paste.ubuntu.com/11857389/
<melodie> xnox infinity I tell you everything about it : I am running my custom version in Vivid, and building a new custom version of that recipe based on Trusty. up to now it was working.
<infinity> melodie: (stolen from mk-sbuild)
<melodie> infinity thanks!
<infinity> melodie: Toss that in your chroot at the beginning of your build process.  Delete it at the end.
<infinity> melodie: Any installs/upgrades during your build will then be no-ops.
<melodie> infinity I see the content, that's nice!
<melodie> I might put it in the chroot/tmp directory
<infinity> melodie: As a general rule, you want something like that in all chroots where you'll be installing/removing daemons that you don't actually want running.
<xnox> didn't think of vivid host, trusty chroot.
<melodie> so I don't need to remove it at the end (or I might forget)
<infinity> melodie: Err, it needs to be /usr/sbin/policy-rc.d or it won't work.
<infinity> melodie: And it needs to be removed before you ship, or your final system won't work. :P
<infinity> melodie: Note what that snippet actually does (writes a new file to /usr/sbin/policy-rc.d)
<melodie> I use Ubuntu Builder which has some cleanser started prior to launching the build process
<melodie> yes: "sudo bash -c "cat >> $MNT/usr/sbin/policy-rc.d" <<EOM"
<infinity> xnox: host and chroot don't really matter anyway.  Expecting invoke-rc.d to work in a chroot is almost always a failing prospect.
<TJ-> Wily server amd64 ISO, in UEFI mode, fails base-installer/kernel due to a missing pool/main/l/linux/linux-headers-signed-generic*  - is this known?
<xnox> infinity: wouldn't a world be a better place if policy-rc.d by default would do nothing inside a chroot, unless something magic is specified to force do stuff?!
<melodie> I don't know if anyone can be interested, but I have pulled out to light what Ubuntu Builder does and how (transcripted from the original tutorial). I hope some day someone adopts this project.
<infinity> xnox: No.
<xnox> meh
<melodie> http://linuxvillage.org/en/2015/07/ubuntu-builder-original-tutorial/
<infinity> xnox: People use chroots for lots of different reasons.  They just fail miserably in the "install a full OS that I intend to boot later" mode.  Sometimes.  But not always.
<infinity> TJ-: That's not a package that should exist...
<infinity> TJ-: So, err... Fun.  I'll look when I get back from lunch.
<TJ-> infinity: I thought that too... but that's what I'm seeing right now (KVM+UEFI boot)
<infinity> TJ-: Yeah, I know what would cause that, but I want to diagnose a bit first, so I'll give it a spin.
<infinity> TJ-: (basically, is the kernel guessing bit somehow stupidly decides the flavour you want is called "signed", that's what the result would be, but I need to debug a bit to see why it got that stupid idea. :P)
<infinity> s/is the/if the/
<TJ-> infinity: I wonder if it was caused because d-i asked me if I wished to 'force' the installation to be UEFI?
<TJ-> infinity: apologies for the screenshot but its in a VM http://imgur.com/bQyRfq1
<melodie> infinity after I used your script:
<melodie> http://pastebin.fr/40427
<melodie> seems to work!
<TJ-> infinity: the syslog:  https://iam.tj/projects/misc/syslog
<infinity> TJ-: so... It's also not helpful that you ENOSPCed during that install.
<infinity> TJ-: Can you try again with a larger disk? :P
<TJ-> infinity: it did? it didn't tell me that!
<infinity> Jul 10 18:38:44 in-target: dpkg: error processing archive /media/cdrom//pool/main/l/linux/linux-image-extra-4.0.0-4-generic_4.0.0-4.6_amd64.deb (--unpack):^M
<infinity> Jul 10 18:38:44 in-target:  cannot copy extracted data for './lib/modules/4.0.0-4-generic/kernel/drivers/bcma/bcma.ko' to '/lib/modules/4.0.0-4-generic/kernel/drivers/bcma/bcma.ko.dpkg-new': failed to write (No space left on device)^M
<infinity> Jul 10 18:38:44 in-target: dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
<TJ-> infinity: shouldn't the install pre-warn about that, I'm sure I've seen it do so before
<infinity> TJ-: The headers bug may still happen anyway and, like I said, I'll look after lunch, but yeah.  Might not hurt to also have enough disk  to test.
<TJ-> 2GB should be enough for a base install !
<smoser> pitti, you still around ?
<smoser>  anyone have ideas on
<smoser>  https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1473527
<ubottu> Ubuntu bug 1473527 in cloud-init (Ubuntu) "module ssh-authkey-fingerprints fails Input/output error: /dev/console" [Undecided,New]
<infinity> TJ-: Except that if that disk was 2G, your / was less than 1.2G.
<infinity> TJ-: At least, based on the 831484k swap ...
<smoser> cloud-init writes to /dev/console directly, and sometimes that just fails. when it is functional. it feels to me like systemd is involved.
<TJ-> infinity: I let it do guided LVM and choose everything itself, I didn't even look (since I was doing this to test another bug)
<TJ-> infinity: "Partition disks" ==> "This machine's firmware has started the installer in UEFI mode... continue to install Debian..." <<<<<
<TJ-> infinity: the updated syslog:  https://iam.tj/projects/misc/syslog.1
<infinity> TJ-: Still ENOSPC...
<TJ-> infinity: grrr, same issue, with 4GB
<TJ-> is it using some artificially low LVM LV size ?
<teward> during the install what generates /etc/network/interfaces and installs it to disk?
<TJ-> I just noticed : PV /dev/vda3   VG ubuntu-vg   lvm2 [1.26 GiB / 0    free]
<infinity> teward: "The installer", which could be any number of packages, depending on how you installed.
<teward> infinity: i should stop crossposting... balloons just gave me the answer in -quality (I install via the daily ISO in VMware, so Ubiquity)
<cyphermox> teward: ubiquity when you install in graphical, netcfg otherwise.
<teward> cyphermox: ack, i'll repoint the bug
<infinity> teward: What's the bug?
<teward> infinity: upon install, systemd uses the systemd naming algo.  but the interfaces file is built for the kernel style eth##, not systemd naming algo, so networking fails to come up after reboot/install
<teward> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1473542
<ubottu> Ubuntu bug 1473542 in ubiquity (Ubuntu) "ubuntu-server daily iso - Upon installation, /etc/network/interfaces not populated with correct network interface names, so networking fails to start" [High,New]
<teward> and balloons guided the bug
<infinity> teward: Ahh.  pitti was meant to be on top of that when he decided to switch. :P
<teward> balloons suggested ubiquity and systemd
<teward> infinity: so we can blame pitti
<teward> and I can throw fire at pitti now?
<infinity> teward: Pretty much
<teward> infinity: note i'm using the 9th's iso and i'm going to double confirm with the 10ths as soon as i can zsync it down
<balloons> he'll probably have it fixed before infinity starts on Monday ;p
<teward> infinity: balloons: and this is the ubuntu-server iso
<infinity> teward: If it's the server ISO, it's netcfg.
<teward> ack
<infinity> Ubiquity won't have the same bug pretty much by accident
<balloons> teward, ohh.. then yea, that was my question about using the debian installer or not
<teward> done
<infinity> Cause it boots with systemd, so it'll have the systemd names.
<teward> balloons: you confused me :P
<teward> infinity: so not a systemd bug (Invalid against that), but Confirmed Known against netcfg?
<infinity> COuld be a systemd bug too.
<infinity> In that it might need to ship things for d-i to mangle in netcfg.
<infinity> So, keep both tasks.
<teward> ack
<teward> infinity: should it be left at "New" or "Confirmed"
<teward> since you said this was supposed to be done
<infinity> Don't care.
<teward> ok
<cyphermox> I'm leaning towards a systemd bug
<infinity> cyphermox: Well, both.
<cyphermox> I'm wondering if it's not a file missing in a udeb
<infinity> cyphermox: netcfg is going to need to invoke the systemd interface renaming magic before it presents the selector UI.
<infinity> cyphermox: So we get the mangled names.
<cyphermox> yes
<infinity> cyphermox: Then everything after that will be smooth.
<cyphermox> indeed
<cyphermox> isn't the renaming done by systemd itself in udev somewhere?
<infinity> cyphermox: But fair point, if it's just a udev hook or something, it could just be a missing file.
<cyphermox> we shouldn't have to call something
<cyphermox> pitti: how does the interface naming logic work?
<teward> FWIW there was no udev
<teward> and i had to write an override with my template rules to force it to eth0,eth1 temporarily
<sarnold> cyphermox: maybe a udevadm settle to make sure that systems with a few thousand drives have finished handling their nics before starting?
<teward> (to get net up)
<infinity> teward: Of course there was a udev...
<cyphermox> I'm pretty sure there was :)
<teward> infinity: i meant a persistent rul
<teward> rule*
<teward> my apologies :)
<cyphermox> no, that's what's been changed
<infinity> teward: Right, the installer doesn't write the persistent rule, it's written on first boot.  And this new scheme doesn't use it anymore.
<cyphermox> (AIUI)
<teward> ok
<infinity> (Though, if you have one, it wins)
<teward> infinity: yeah, i wrote one temporarily
<teward> because i needed networking to come up :P
<cyphermox> on the installed system you mean?
<infinity> cyphermox: According to pitti's mail, it's /lib/udev/rules.d/80-net-setup-link.rules
<infinity> cyphermox: So maybe that's missing from the udeb.
<infinity> cyphermox: And, looking at the .install file, it sure seems to be missing.
<teward> cyphermox: correct.
<cyphermox> teward: ok
<teward> cyphermox: networking worked fine on the installer
<teward> it's the generated /etc/network/interfaces where it fails
<teward> and i either have to rename the interfaces or edit the file
<teward> and i needed consistency for testing, so i just copied in the template i have on my wily VM too
<cyphermox> yup
<teward> s/wily VM/vivid VM/
<cyphermox> teward: so you got the newest images from pending?
<teward> infinity: so it's a missing udev rules?
<teward> cyphermox: zsyncing now
<teward> (slowwwwwwwww)
<infinity> Yeah, looks like it's missing in the udeb.
<cyphermox> well, I don't think it's going to be fixed right now now
<cyphermox> infinity: you do the magic?
<infinity> (And even if it wasn't, it would be missing in d-i)
<infinity> cyphermox: I can do the fixing, but testing beforehand would be smart.
<cyphermox> yes
<teward> cyphermox: infinity: as long as it's on the radar and scheduled to be fixed "soon" i can just edit things to make it work
 * infinity tears apart a d-i initrd to add the rule.
<teward> rather than pester you all for an instant fix
<cyphermox> infinity: or i'll do the systemd fix and upload to my magical d-i testing PPA
<infinity> cyphermox: That's way longer tunraround. :P
<cyphermox> pfff
<cyphermox> infinity: but it's magic
<infinity> cyphermox: How is it any more magic than my PPA? :P
<cyphermox> fwiw, I'm starting to like that overlay trick :)
<teward> also, is there a reason i can do `shutdown -h now` without sudo now in wily?
<teward> that seems like a DoS vector IMO
<cyphermox> were you root?
<teward> (if someone gains access to an unprivileged account)
<teward> cyphermox: no, the user that the installer prompted me for the username for
<teward> let me reinstall and test again
<infinity> teward: Were you logged in on the console?
<teward> infinity: yeah, tty1, is that why?
<infinity> teward: Yeah.
<infinity> teward: That's no more of an attack vector than you being able to shut down from X locally.
<teward> i'm going to install openssh on here, SSH locally, and then test again...
<teward> ack
<teward> i'm curious if it spills over to SSH at all (and i'mma test)
<teward> and if it does then THAT'S a bad thing
<cyphermox> ah, policykit
<teward> infinity: i do know that it's immediately going to require me to dhclient the thing
<teward> since the pending iso has the same mismatch in netcfg stuff
<teward> but that's an easy to test/fix thing
<teward> now that i know to look for it xD
<cyphermox> teward: guess you didn't need to pick things from pending, the isos for properly promoted (finally)
<teward> heh
<infinity> Hrm.  Still eth0
<teward> infinity: at least, with 20150710
<teward> but meh
<teward> infinity: remind me again since it's been a while - when uploading something to the repositories (including devel release) it's RELEASE-proposed right?
<teward> been a while since i've made a merge/upload xD
<teward> (I should really NOT forget things >.<)
<infinity> teward: Just $release
<cjwatson> te	RELEASE is fine, it gets automatically redirected.
<cjwatson> (sigh, lag)
<teward> heheh two responses
<teward> infinity: cjwatson: ack, i wasn't sure, last one i have appeared to have -proposed :/
<infinity> teward: -proposed will go to the right place, it's just unnecessary.
<infinity> teward: As a bare SERIES will always be rewritten to SERIES-proposed
<teward> right, i'll be glad to chop it off when i do uploads and such xD
<teward> ack
<yofel> cjwatson: could you please refresh the kubuntu packageset? thanks!
<cjwatson> yofel: I haven't had permission to do that in quite some time
<infinity> cyphermox: Hrm.  So, adding that udev rule isn't enough to make it happy.
<yofel> oh ok, who should I ask?
<cjwatson> yofel: ask somebody in IIRC ~developer-membership-board
<yofel> ok, thanks
<cyphermox> really?
 * cyphermox pulls the relevant stuff
 * infinity experiments.
<cyphermox> yofel: I can learn to do it now, will have to eventually
<teward> infinity: if an SRU upload is solely adding apport hooks, does it need a corresponding SRU bug?
<cyphermox> infinity: 99-systemd ?
<infinity> cyphermox: Yeah, probably, but I doubt we want the whole thing...
<cyphermox> I don't know
<yofel> cjwatson: that would be great if you have time :)
<yofel> erm
<yofel> cyphermox: ^
<cyphermox> yofel: I'm reading the README and apt-getting germinate
 * infinity tries:
<infinity> grep 'SUBSYSTEM=="net"' /lib/udev/rules.d/99-systemd.rules > lib/udev/rules.d/99-systemd.rules
<infinity> Nope.
<infinity> teward: Yes, it needs a bug.
<teward> OK cause there already is one on this
<infinity> Oh, might need the binary that calls...
<cyphermox> systemd-sysctl?
<infinity> Yeah.  That didn't solve it for me either.  La la.
<cyphermox> I don't think that's what renames the devices?
<cyphermox> net.ifnames
<infinity> Yeah, that's enabled by default in the new systemd (which I'm using).
<infinity> If it wasn't, we wouldn't have a bug report. :P
<cyphermox> is it?
<infinity> Yes.
<infinity> The patch disabling it was reverted.
<cyphermox> ok.
<cyphermox> I'm grepping and not finding anything that seems to set it to 1
<infinity> Because 1 is the default...
<cyphermox> but grep also doesn't return much
<cyphermox> infinity: do you have a /etc/udev/rules.d/80-net-setup-link.rules on the filesystem?
<infinity> cyphermox: Yes.
<cyphermox> hmm
<infinity> cyphermox: Bingo.
<infinity> cyphermox: Got it working, now I need to figure out how much of this I can delete again. :P
<cyphermox> cool
<cyphermox> what was it?
<infinity> 75-net-description for sure
<infinity> And maybe other bits.
<infinity> Deleting one by one until I break it.
<infinity> 99-systemd was useless, thankfully.
<infinity> cyphermox: http://paste.ubuntu.com/11858147/ is my final initrd diff.  Running through a full install now to make sure the installed system has the same names as d-i.
<infinity> cyphermox: Then I'll upload systemd and then d-i.
<cyphermox> looks about right
<cyphermox> I didn't know we had files there for systemd
<infinity> We didn't until just now. :P
<cyphermox> well, I mean on the installed system :)
<cyphermox> didn't remember about the links
<infinity> cyphermox: The systemd/network stuff defines the naming policy.
<cyphermox> yeah
<infinity> Why it's in lib/systemd instead of lib/udev, I don't know.
<infinity> But yay for merging the projects. :(
<cyphermox> ah, that's because it's some magical systemd config rather than magical udev config
<cyphermox> :)
<infinity> cyphermox: Sure, the syntax is systemdish, but it's read by udevd.
<infinity> (Clearly, since we don't have systemd in the initrd)
<infinity> Oh, hrm, probably want to fix this for the initramfs hook too.
<infinity> cyphermox: http://paste.ubuntu.com/11858246/ <-- Look sane?
<cyphermox> yeah, looks sane
<infinity> smoser: Is cloud-init a systemd service?
<infinity> smoser: If so, it's probably missing some magic to let it attach to a console.
<smoser> infinity, yes, it is a service.
<smoser> and has
<smoser> StandardOutput=journal+console
<infinity> smoser: Are you opening /dev/console to read or write?
<smoser> that is in cloud-final.service .  and that service runs, and then explicitly opens /dev/console and writes to it.
<infinity> (And why not just use stdio?)
<sarnold> why /dev/console instead of e.g. /dev/tty?
<smoser> well
<infinity> Not /dev/anything, ideally, just trusty that stdout is the right place.
<smoser> a.) thats not a bad argument
<smoser> b.) but it doesn't explain "sometimes"
<infinity> If you're telling system to redirect your stdout to console, then...
<infinity> s/trusty/trust/
<infinity> That release ruined me.
<smoser> c.) writes to stdout of a service like that get prefixed with systemd job status
<smoser> which is undesireable
<smoser> if it failed everytime, then i'd absolutely agree with you
<teward> cyphermox: infinity: thank you both for looking at it :)
<teward> (the systemd, network interface naming algorithms not matching thing)
<infinity> teward: https://launchpad.net/ubuntu/+source/systemd/222-1ubuntu2
<teward> i saw the fix committed messages go out :)
<teward> *looks*
<infinity> Oh, FFS.  FTBFS.  Maybe I should have tested.
<teward> failed on arm64
<cyphermox> there will be more explosions.
<teward> infinity: cyphermox: And this, my friends, is why I don't mess with the core packages much xD
<cyphermox> teward: it's not just going to fail on arm64
<teward> cyphermox: indeed
<teward> cyphermox: it was loading the other images was all
<teward> you're right though
<teward> even so, thank you, cyphermox and infinity, for taking a look at it so rapidly
<cyphermox> ah. it's from debian/extra
<teward> infinity: unrelated: how long does it take for an SRU to show up in the sponsoring list
<teward> or rather on any lists
<teward> (i forgot since i have upload it goes right past 'sponsorship' xD)
<infinity> teward: You get an email.  But <= 5 minutes.
<teward> infinity: no, i meant once it lands in the uploads queue
<teward> i already got the "awaiting accept"
<infinity> teward: Well, that is "the list".
<teward> (in other news, the wily package with the nginx apport hooks is there, so now I can relax with regards to Wily coming forward)
<infinity> teward: From there, a human needs to get around to reviewing it.
<teward> infinity: right, i was curious what average wait was on that, if only to stop getting crap vivid 'postinstall failed' bugs
<teward> but that's not as big an issue, i can wait :)
<cyphermox> teward: isn't it good already?
<cyphermox> https://launchpad.net/ubuntu/+source/nginx/1.6.2-5ubuntu4
<teward> cyphermox: -5ubuntu4 is wily
<infinity> cyphermox: He SRUed it too.
<teward> cyphermox: switch to Vivid - -5ubuntu3.1
<cyphermox> sorry, I misread
<teward> cyphermox: that's why i said it's there for wily.  it's awaiting review for Vivid
<teward> no problem :)
#ubuntu-devel 2015-07-11
<sarnold> infinity: normally we just review the packages we're actually shipping, or going to ship, but Vasant suggests reviewing upstream trees, and this time around I'm somewhat inclined to review the git trees. What do you think? https://bugs.launchpad.net/ubuntu/+source/ppc64-diag/+bug/1417608/comments/7
<ubottu> Ubuntu bug 1417608 in servicelog (Ubuntu) "[MIR] ppc64-diag needed in minimal for hotplug capabilities" [Undecided,New]
<infinity> sarnold: If the git trees represent something we can backport as HWE SRUs without too much hand-waving, then I think it's fine to review them (and ask for new upstream release tarballs to be cut when you're satisfied with the state)
<infinity> sarnold: We're less than a month from the point release where we were hoping to ship all of this, so coming to some positive conclusion would be nice.
<sarnold> evening infinity :) I didn't expect you to still be around.. thanks :)
<infinity> sarnold: Am I ever not around?
<sarnold> man time flies..
<sarnold> infinity: well..
<sarnold> infinity: good point.
<infinity> sarnold: While not part of that bug, since they were grandfathered into main years ago, I suspect you'd find the same classes of bugs in librtas and powerpc-ibm-utils too, if you're feeling like being helpful to IBM upstream. :P
<sarnold> infinity: oof. on the one hand it feels like a productive use of time.. on the other hand, I don't directly own IBM stock..
<infinity> Heh.
<infinity> sarnold: I feel guilty about what a burden this has been.  When I handed the MIR off to you because "oh look, root daemons", I had assumed it would be a "yeah, it looks alrightish, here's some nitpicks" review, not you educating them on modern C.
<infinity> sarnold: OTOH, it's been productive.
<sarnold> infinity: just between you and me, I think I'd rather be reading these than openstack packages.. heh.
<infinity> sarnold: I don't think I'd know insecure (or secure) python if it hit me in the face.
<infinity> sarnold: I mean, except for really obviously scary things like caching passwords or forking unescaped sadness to a shell (ie: the sort of evil that looks the same in any language).
<sarnold> infinity: hehe, yeah, most of my python knowledge is a good dozen years out of date at this point too...
<infinity> pitti: Can you commit the systemd delta from -1ubuntu1 to -1ubuntu3 back to Debian (obviously don't need the -1ubuntu3 changelog entry) for me?
<hjd> Hi all. A new version of maven was just packaged in Debian, and I'm trying to get that into Wily. I have a couple of questions, but first some background: Yesterday it failed to build due to some missing dependencies, but I got some help poking two of them for a rebuild and the third eventually synced. With everything in place, I tried to build the package locally.
<hjd> And it failed with the following error message http://paste.ubuntu.com/11860099/ :( However, I saw the following part "Plugin org.apache.maven.plugins:maven-compiler-plugin:3.2 or one of its dependencies could not be resolved: The following artifacts could not be resolved: org.codehaus.plexus:plexus-compiler-api:jar:2.x" which indicated where the problem might lie. This is where it gets interesting.
<hjd> https://packages.debian.org/sid/libmaven-compiler-plugin-java has a dependency on libplexus-compiler-java but is also a virtual package provided by libplexus-compiler-1.0-java.  Based on the name, the latter is presumably the 1.x jars, so I looked at https://launchpad.net/ubuntu/+source/plexus-compiler where the 2.x versions reside. After installing libplexus-compiler-java manually from -proposed the package built without any issues.
<hjd> I don't remember if the build slaves have -proposed enabled, though they might. However, I wonder why https://launchpad.net/ubuntu/+source/plexus-compiler hasn't migrated from -proposed to -release. It looks like it's been there for a while, and I don't see any obvious signs like a proposed-block bug. Is it part of a transition or something?
<hjd> I was also slightly confused how resolving dependencies worked between libplexus-compiler-java and libplexus-compiler-1.0-java, but it looks like maven-compiler-plugin 3.2-4 (https://tracker.debian.org/media/packages/m/maven-compiler-plugin/changelog-3.2-4) adds an explicit version number which only the former would satisfy, so I guess that'll sort things out.
<pitti> infinity: thanks for sorting out ifnames in udev-udeb
<pitti> teward: yes, every SRU needs a corresponding bug
<pitti> infinity: I committed the delta a few minutes ago after seeing your bug
<cjwatson> hjd: New uploads to Ubuntu always go into -proposed, and everything in -proposed is itself built against -proposed.  Upgrading plexus-compiler currently makes things uninstallable: see http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt and search for "Trying easy from autohinter: plexus-compiler"
<cjwatson>     * amd64: antlr3-gunit-maven-plugin, antlr3-maven-plugin
<infinity> pitti: Ta.
<infinity> pitti: The initramfs bit was untested (as in, I didn't bother to reboot my laptop break=bottom and check what interfaces I had), but it seemed obviously correct.
<infinity> pitti: The udeb bit is tested, though.
<hjd> cjwatson: Thank you. I suspected something was blocking it, but I couldn't figure out what. *bookmarks link*
<hjd> I suspect this boils down to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791487
<ubottu> Debian bug 791487 in src:antlr3 "antlr3: Depends on obsolete packages" [Serious,Open]
<cjwatson> Looks likely.
<hjd> Any systemd people who could take a look at bug 1448164? It looks like runit still believe it's using upstart on 15.04 and Wily.
<ubottu> bug 1448164 in runit (Ubuntu) "runit cannot be installed (Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused)" [Undecided,Confirmed] https://launchpad.net/bugs/1448164
#ubuntu-devel 2015-07-12
<xpheres> hello
<xpheres> any idea of when is it going to work the ubuntu touch emulator?
<siretart> doko: i checked with upstream on aspectc++, it needs porting to gcc5
<doko> siretart, thanks, although I'm wondering why people only check *after* a package is removed from testing ;-P
<siretart> doko: i checked with him already a couple of weeks ago, actually
<teward> pitti: (response to yesterday's ping) yes, that was already answered by infinity - so late on the response.  In any case, that issue was resolved, and hopefully the ifnames issue affecting the server ISOs won't be happening again.  I know it was on your radar (thanks to inifnity and cyphermox) but I guess I just came in complaining and it got a slight bump in expediency-of-fixing xD
<infinity> teward: Feel free to double-check the server ISO ifnames thing with today's daily, but my fix should be working (I didn't actually test the ISO, though, just tested artificially locally).
<teward> infinity: i'm going to test when I get home
<teward> because i'm on the bus and mobile broadband is a piece of [censored]
<teward> so in a few hours i'll test :/
<teward> infinity: and if it doesn't work i'll bother you about it :)
<infinity> teward: Fair enough. :)
<teward> god i hate laptops
<codepython777> What laptop do the majority of the ubuntu developers use for working / developing ubuntu - does anyone here know?
<teward> codepython777: as I said in #ubuntu there is no one majority-used laptop or hardware
<teward> also !crosspost
<teward> bah forgot wrong channel
<teward> but still
#ubuntu-devel 2016-07-11
<pitti> Good morning
<dholbach> @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: dholbach
<xnox> 3 months in, and my irc stopped working, because let's encrypt certificate did not renew *sigh*
<cpaelzer> Hi, sorry to ask, but I never touched this before - I'm trying to fix an issue with the GCC& build as reported by https://lists.ubuntu.com/archives/ubuntu-devel/2016-July/039448.html
<cpaelzer> what is the "right" way to locally reproduce this with e.g. sbuild?
<cpaelzer> I've seen the test added http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu
<cpaelzer> so should I do like https://wiki.ubuntu.com/SimpleSbuild#Temporarily_adding_PPAs ?
<cpaelzer> or is there another preferred method
<cpaelzer> it is working, so it can't be too wrong :-)
<dholbach> hey seb128 - can you or anyone in your team take a look at https://code.launchpad.net/~jbicha/indicator-session/lp1600502-fix-icon-install/+merge/299625?
<seb128> dholbach, hey, I guess I can try having a look, though my cmake foo is weak, might be one rather for charles or ted
<seb128> I can try to nag them though
<dholbach> thanks a lot
<seb128> yw
<mwhudson> cpaelzer: you might also be able to use --extra-package pointing at an appropriate gcc-defaults package
<cpaelzer> mwhudson: thanks, will try that next time
<cpaelzer> would not affect the actual chroot which is nice
<infinity> cpaelzer: --extra-repository=spec --extra-repository-key=file.asc
<infinity> cpaelzer: Adds the PPA on the CLI instead of in the chroot, so only affects that build.
<infinity> cpaelzer: (See sbuild(1))
<cpaelzer> infinity: I searched for ppa in there and the web but you never know how it is called ina  given context in advance - of course it is repository not ppa as it is the more generic term
<cpaelzer> infinity: thanks a lot!
<cpaelzer> as always if you would know before, what you know after doing/realizing sometihng it would have been much easier :-)
<cpaelzer> I think I should try to mention that in https://wiki.ubuntu.com/SimpleSbuild#Temporarily_adding_PPAs to not mislead the next
 * cpaelzer is checking if he can edit there ...
<infinity> cpaelzer: Yeah, the advice to mangle the chroot is certainly not ideal, since one can easily end up with a dirty base chroot and have to start over.
<infinity> cpaelzer: +1 for replacing that section with --extra-repo* bits.
<infinity> cpaelzer: With a derp-friendly blurb on how to find the public sig for repo.asc, I guess.
<infinity> s/sig/key/
<mwhudson> infinity: does that actually work? i couldn't make --extra-repository-key behave
<mwhudson> but i was probably holding it wrong
<mwhudson> also mk-sbuild is pretty fast, i have a collection with various different ppas enabled
<infinity> mwhudson: Works for me.
<cpaelzer> infinity: mwhudson: I replaced the modding of the chroot with the sbuild options, my gpg key foo was good enough to get them to work - but surely not perfect. If one has a sequence that works without ever touching the local keyreing please feel free to let me know or modify in place https://wiki.ubuntu.com/SimpleSbuild#Temporarily_adding_PPAs
<mwhudson> cpaelzer: i have a horrible feeling that involves GNUPGHOME=`mktemp -d` or some such horror
<mwhudson> but i'm not really sure :)
<cpaelzer> mwhudson: no need for Horror on a Monday :-) what I have written works and is surely less damaging than what the wiki page said before
<cpaelzer> just wanted to leave the chance open if one knows an even better way
<cpaelzer> if with "horror" it might not be that much better
<dholbach> @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:
<coreycb> infinity, hi, would you be able to review keystone and pythonkeystoneauth1 in the xenial review queue?
<LocutusOfBorg> hi folks, quick question
<LocutusOfBorg> "what's the file system mounted at /tmp?" <-- buildd/armhf system
<LocutusOfBorg> if you want the whole picture: https://github.com/borgbackup/borg/issues/1310
<teward> LocutusOfBorg: /tmp/ should be a tmpfs in RAM, is it a qemu-static armhf schroot or a native armhf build env.?
<LocutusOfBorg> teward, official buildds
<teward> ah, then you'll have to wait for the buildd maintainers to answer that more effectively.
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/borgbackup/1.0.5-1
<LocutusOfBorg> this is the build
<LocutusOfBorg> kishi04 seems owned by infinity
<LocutusOfBorg> but it might be a general issue/configuration I think
<LocutusOfBorg> they are also asking the result of getconf PAGE_SIZE
<ddellav> pitti when you get a second, can you or someone else on the SRU team take a look at https://bugs.launchpad.net/ubuntu/+source/keystone/+bug/1592865? It's good to go
<ubottu> Launchpad bug 1592865 in keystone (Ubuntu Xenial) "[SRU] mitaka point releases" [Undecided,Incomplete]
<ddellav> coreycb ^
<bregma> hey folks, is there a formal way to file a remove request for a package in Yakkety?
<LocutusOfBorg> bregma, open a bug and subscribe ubuntu-archive
<LocutusOfBorg> e.g. 1595485
<LocutusOfBorg> LP: #1595485
<ubottu> Launchpad bug 1595485 in singular (Ubuntu) "packages to remove from yakkety" [Undecided,New] https://launchpad.net/bugs/1595485
<bregma> LocutusOfBorg, a bug against Ubuntu or a bug against the particular package?
<LocutusOfBorg> the second one
<bregma> k thanks
 * bregma likes easy
<LocutusOfBorg> well, if the package disappears in Debian, it is semi-automatically removed from ubuntu too
<LocutusOfBorg> unless there are rdeps that needs fixing
<bregma> it's a Ubuntu-only package
<LocutusOfBorg> so, if you don't want to make things difficult to both you and archive team (like I did in the above bug)
<LocutusOfBorg> reverse-depends -r yakkety src:foo; reverse-depends -r yakkety -b src:foo
<LocutusOfBorg> and reverse-depends -r yakkety -b libfoo-dev
<coreycb> ddellav, I pinged infinity in here a little while ago about keystone and keystoneauth1 since he has Mondays for the sru team:  https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<cjwatson> LocutusOfBorg: the log of https://launchpad.net/ubuntu/+source/procenv/0.43-2/+build/8361172 should answer your questions
<LocutusOfBorg> cjwatson, can I assume it didn't change in the last months then?
<LocutusOfBorg> I don't see any mounts:
<LocutusOfBorg>   /tmp:
<LocutusOfBorg> so I presume it is under "/" mount
<cjwatson> indeed, and yes, you can so assume
<LocutusOfBorg> thanks! I'm a little bit confused about a non tmpfs tmp :)
<LocutusOfBorg> but I can understand the rationale for that indeed
<LocutusOfBorg> thanks!
 * LocutusOfBorg leaves
<cjwatson> /tmp is an FHS-mandated directory regardless of what filesystem it's on, and on buildds I think it makes sense to leave the memory for compilers to use
<Odd_Bloke> slangasek: infinity: https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305 <-- this fixes some major pain points with using Vagrant images (for xenial and later), which we'd like to (a) fix in yakkety, and (b) SRU to xenial
<Odd_Bloke> If you could cast your eyes over it, it would be much appreciated.
<semiosis> \o/
<semiosis> Odd_Bloke: want to talk about the bash -u option now?  or are you OK with it being removed?
<Odd_Bloke> semiosis: I'm happy with it being removed; we need to do some clean-up there (to, for example, switch away from bash), so it's a more pervasive change than makes sense for this.
<semiosis> Odd_Bloke: sounds good.  curious, what would you use instead of bash?
<slangasek> POSIX sh
<semiosis> that makes sense.
<rharper> slangasek: smoser and I are starting a curtin SRU,  do you prefer a single SRU bug, or can we just use the individual bugs (we've four of them) in the changelog/debdiff ?
<slangasek> rharper: if there's been discussion about SRU exception process for curtin, it's not captured on https://wiki.ubuntu.com/StableReleaseUpdates; individual bugs are probably best here
<semiosis> slangasek: working on your feedback in https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305
<slangasek> semiosis: great :)
<semiosis> slangasek: can you explain a bit more what you mean in your comment re manage_etc_hosts: localhost... i dont understand
<semiosis> "The bug reference for this makes sense in terms of why this is wanted; but why is this a vagrant-specific change? I'm skeptical of this being a delta vs. 999-cpc-fixes.chroot."
<slangasek> semiosis: so, you're adding this into a cloud-init userdata that's specific to the vagrant image. the 999-cpc-fixes.chroot hook also creates cloud-image userdata for the generic cloud image
<slangasek> semiosis: is there some reason that this change should be made *only* for vagrant, which is the effect of the current change?
<semiosis> slangasek: well I'm not an expert on that subject.  not sure if it's generally useful to other cloud images (although I can imagine how it would be!)
<slangasek> semiosis: hostname setting and resolution seem applicable for other environments than vagrant, AFAICS
<slangasek> maybe Odd_Bloke has a comment here
<semiosis> slangasek: however, since the vagrant builder combines the cloud-init stuff into an ISO which gets bundled in the vagrant box, we do need to generate cloud-init config in the vagrant builder.  unless you'd suggest going back and modifying the vagrant box in the 999 step
<slangasek> semiosis: I'm saying that if this is a bug affecting multiple images, we shouldn't fix it in just one of the images and close the bug
<slangasek> but should fix it in both places
<semiosis> slangasek: that makes sense.  but i dont see how that matters for my merge request... even if that change were needed elsewhere, it is still needed in the vagrant builder, no?
<slangasek> semiosis: your merge request has a changelog entry which closes that bug ;)
<semiosis> OH!
<slangasek> and regardless, before merging I would want to be sure we either have a reason not to apply it to the other userdata, or apply it equally in both places
<slangasek> so that does probably need Odd_Bloke's expertise
<slangasek> or maybe rcj is more likely to be around
<semiosis> sounds good.  i can ping Odd_Bloke tomorrow morning if he doesn't get to it first
<semiosis> slangasek: i have a xenial ec2 instance and i get the same unable to resolve host there, which supports your idea
<semiosis> i had not noticed that on the ec2 instance before so i just checked
#ubuntu-devel 2016-07-12
<cpaelzer> good morning
<pitti> Good morning
<flexiondotorg> pitti, If at all possible can you cast an eye over the SRUs we discussed last week? I'd really like to see them included in 16.04.1
<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,Fix committed]
<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]
<pitti> flexiondotorg: so mate-settings looks good and is verified, and can land in 3 days
<flexiondotorg> Great.
<pitti> flexiondotorg: and it seems nobody accepted mate-artwork from the queue
<pitti> flexiondotorg: I assume bug 1052936 is fixed in yakkety? please mark accordingly
<pitti> this is still open in y
<ubottu> bug 1052936 in One Hundred Papercuts "Progress bar in "Progress" section has a hole in it" [Medium,Triaged] https://launchpad.net/bugs/1052936
<pitti> flexiondotorg: accepted m-artwork for xenial (but needs updating this ^)
<flexiondotorg> If it.
<flexiondotorg> And marked now.
<pitti> danke
<flexiondotorg> No, thank you :-)
<tsimonq2> greetings, I have a bug fix attached to bug 1423326 but I don't have upload permissions and it needs a sponsor. Could somebody please take a loog?
<ubottu> bug 1423326 in lxsession (Ubuntu) "lxsession should depend on lxsession-logout" [Undecided,In progress] https://launchpad.net/bugs/1423326
<tsimonq2> *look
<jtaylor> hm there might be a problem in the xenial docker update
<jtaylor> can someone test something for me to confirm? just build a container from: FROM centos:6\n RUN echo test
<jtaylor> I get /bin/sh not found, also from ubuntu base images, I'm pretty sure it worked before the update
<jtaylor> hm nevermind seems to have been an artifact of not restarting the daemon probably
<jtaylor> maybe a NEWS entry would be good
 * jtaylor adds that to the bug
<flexiondotorg> pitti, I've just tested the ubuntu-mate-artwork update in a clean VM built from todays Xenial daily
<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]
<caribou> pitti: Are packages synced from Debian have their autopkgtest run when pulled in ?
<pitti> caribou: yes
<caribou> pitti: thought so
<mwhudson> jtaylor: thanks for the comment, i'll see about adding a note indeed, it's a bit of a footgun
<Laney> pitti: britney merge> yay!
<pitti> Laney: what a pain :)
<LocutusOfBorg> hi, do anybody have any idea for expat and python3.5/python2.7 testsuite failure?
<LocutusOfBorg> I admit I don't know how to debug it
<LocutusOfBorg> seems really a bug in expat
<pitti> LocutusOfBorg: right, it seems the new expat changed/fixed the line counting, and now the expected error message changed
<pitti> LocutusOfBorg: so looking at the python test to see whether it *should* be line 13 (as before) or 14 (as of now) should tell :)
<pitti> i. e. whether it's an expat fix (then python tests need an update) or an expat regression
<LocutusOfBorg> pitti, I already did that
<LocutusOfBorg> and to me it seems an expat regression
<LocutusOfBorg> https://sources.debian.net/src/python2.7/2.7.12-1/Lib/test/test_pyexpat.py/#L611
<LocutusOfBorg> it seems really 14 to me
<LocutusOfBorg> also here https://sources.debian.net/src/python3.5/3.5.2-2/Lib/test/test_pyexpat.py/#L657
<LocutusOfBorg> this is why I would like to send an upstream bug to expat folks
<LocutusOfBorg> OOPS https://bugs.python.org/file43515/0001-Fix-Python-3.x.x-tests-for-Expat-2.2.0.patch
<LocutusOfBorg> so, I'll ping doko about updating the teststuite :(
<LocutusOfBorg> pitti, question: I asked doko to fix the testsuite, but since the testsuite is broken, and upstream is aware, what about ignoring tests for this time and let it migrate? :)
<LocutusOfBorg> the only test failing is that one
<LocutusOfBorg> oops they didn't have applied the patch yet on the branch
<pitti> LocutusOfBorg: which bugs.python.org # does that belong to? (for the comment)
<pitti> LocutusOfBorg: is expat blocking anything else?
<LocutusOfBorg> https://bugs.python.org/issue27369
<LocutusOfBorg> seems really a Python fault, according to the bug
<pitti> thanks
<pitti> LocutusOfBorg: yes, seems fine; note that doko is on vacation
<LocutusOfBorg> I honestly don't know what is blocking, but it is in main, and I like to see my things migrating :p
<pitti> LocutusOfBorg: right, I'm mostly just concerned about a lot of things now failing due to an apparent python regression; i. e. would be better to actually fix python right away
<LocutusOfBorg> I can't, I should wait for doko :(
<pitti> LocutusOfBorg: happy to sponsor
<LocutusOfBorg> but meh, I'm not worried for that expat anymore now :)
<LocutusOfBorg> oh... ubuntu delta?
<LocutusOfBorg> right, hold on
<pitti> just really busy ATM, so I'm afraid I don't have time to update this myself
<pitti> LocutusOfBorg: it's temporary only, so it's ok
<LocutusOfBorg> yes, I can agree
<LocutusOfBorg> pitti, I sent debdiffs by email
<pitti> LocutusOfBorg: perfect, thanks! please let me know once your build finishes, then I'll upload this
<LocutusOfBorg> ack
<LocutusOfBorg> FWIW you can also grab debdiffs from the ppa lol :)
<LocutusOfBorg> pitti, fine https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa/+build/10454431
<pitti> LocutusOfBorg: yay, thanks!
<LocutusOfBorg> thanks to you :) and don't forget to run testsuite against proposed :p
<pitti> I will, once it built/published
<LocutusOfBorg> I see the same testsuite runs in dh_auto_test
<LocutusOfBorg> so I can presume we are good
<pitti> right, and builds happen against -proposed; the build log should tell you the expat version
<pitti> oh, your PPA might not enable -proposed
<LocutusOfBorg> exactly
<pitti> LocutusOfBorg: uploaded, thanks!
<LocutusOfBorg> IIRC it has it enabled
<LocutusOfBorg> Get:81 http://ftpmaster.internal/ubuntu yakkety-proposed/main arm64 libexpat1-dev arm64 2.2.0-1 [104 kB]
<LocutusOfBorg> confirmed
<smoser> anyone know why i see this when using eatmydata for atpg-et install
<smoser> ERROR: ld.so: object 'libeatmydata.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
<rbasak> smoser: I've seen that, but I presumed that LD_PRELOAD got passed into a container or something where libeatmydata.so no longer existed in that filesystem namespace.
<smoser> but it most certainly does exist.
<rbasak> What does $LD_PRELOAD say? And ldd that?
<smoser> well, heres a recreate:
<smoser> lxc launch xenial x1
<smoser> lxc exec x1 -- eatmydata apt-get install --assume-yes libvirt-bin
<dobey> cjwatson, mvo_: hey, does click unpack stuff to /tmp and then mv to destination? or do something else with /tmp?
<cjwatson> dobey: it's been a long time, but that would be a weird and surprising thing for it to do given that it's potentially a different filesystem and might cause atomicity headaches; I don't think I would have done that
<cjwatson> dobey: "click verify" will unpack the package to a tmpdir, and there may be other paths that do that kind of thing
<dobey> cjwatson: ok, just wanted to check. got a few complaints about /tmp filling up when installing a very large .click package, and trying to figure out what's going on exactly
<cjwatson> dobey: not sure what that would be, unless something is explicitly calling verify first
<cjwatson> which seems unlikely
<dobey> yeah, we don't do that in the click scope i'm pretty sure. we just do "pkcon install-local foo.click"
<cjwatson> probably an strace job to figure that out
<dobey> yeah
<cjwatson> I think dpkg-deb extracts the control area to a temporary directory, but that shouldn't be large
<mvo_> dobey: iirc debsig-verify will unpack the signed bits into /tmp to verify them
<cjwatson> ah, that could do it ...
<dobey> oh
<dobey> maybe we need to make /tmp not be tmpfs on the phone images then
<rbasak> flexiondotorg: mate-hud> do you have a link to our previous discussion please?
<flexiondotorg> rbasak, Maybe. I'll go hunting...
<rbasak> flexiondotorg: sorry I don't remember it. I believe that we discussed it, but I'd like to remind myself of any context.
<flexiondotorg> rbasak, My question: https://irclogs.ubuntu.com/2016/07/01/%23ubuntu-devel.html#t08:24
<flexiondotorg> rbasak, You're reply - https://irclogs.ubuntu.com/2016/07/01/%23ubuntu-devel.html#t10:18
<rbasak> flexiondotorg: thanks!
<flexiondotorg> Or Your reply even.
<mvo_> dobey: yeah, or use /var/tmp just for debsig-verify (if that is on a real FS)
<dobey> mvo_: /var/tmp is in the read-only partition
<LocutusOfBorg> pitti, I was wondering, python should migrate anyway, regardless of expat, so I guess there is no need to retry them against proposed, but just see python migrate and retry them
<LocutusOfBorg> am I correct?
<pitti> LocutusOfBorg: correct
<rbasak> flexiondotorg: looks like I don't know what I'm doing, sorry :-/
<rbasak> flexiondotorg: I thought MATE was a set automatically generated from the seed, but it's not in https://bitbucket.org/ubuntu-mate/mate-hud
<rbasak> Uh, not in http://bazaar.launchpad.net/~developer-membership-board/+junk/packageset/view/head:/packageset-report
<flexiondotorg> Yeah, I saw that. Derived from the seeds.
<rbasak> flexiondotorg: I need to run, but I'll try and look again later and ask around for help. If I drop the ball, please ping me, or if you add it to the agenda before Monday's meeting, we can give someone an action to take care of it so we don't forget.
<flexiondotorg> rbasak, OK. Thanks.
<rbasak> flexiondotorg: +1 from me to add mate-hud to the MATE packageset, as it's obviously MATE only. So you don't need any more approval - I just don't know how to do it right now exactly.
<rbasak> flexiondotorg: I'm also not sure what to do give it doesn't exist yet. You might need it sponsoring in so that it exists, then a seed change sponsored to seed it, and then the packagesets regenerated or something.
<rbasak> *given
<flexiondotorg> Understood.
<rbasak> flexiondotorg: I'm stuck for time today, but I'd be happy to sponsor it for you tomorrow regardless of what we do about permissions in order to unblock you if that would be helpful.
<flexiondotorg> Thanks!
<Laney> rbasak: That looks like https://code.launchpad.net/~laney/+junk/packageset didn't get merged
<rbasak> Laney: thanks, I'll look later
<michael-vb> sladen: so looks like that "low graphics mode" problem was my bug after all.  Sorry for the noise.
<sladen> michael-vb: what's important is that it gets tracked down and fixed.
<sladen> michael-vb: could you write a full-debrief on the bug report of your present understanding how what is happening/where it needs fixing
<michael-vb> Will do that, but the fix will be entirely in VirtualBox.
<sladen> michael-vb: then this can all be tracked when new releases/patches are available and people can be pointed to the right versions,
<michael-vb> Sure, will do that.
<sladen> michael-vb: I did have a quick look this morning for libEGL/RTR3InitDll() etc and didn't immediately spot the cause, although there were a couple of possibilities, eg. around the env("DISPLAY") checking about server vs. client and the corresponding #ifdefs (from memory)
<michael-vb> https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/common/crOpenGL/egl.c#L136
<michael-vb> Our local tree now has another check for the DISPLAY variable before that.  Very hack-ish I know, and Debian and Ubuntu would have a better solution, but I prefer an ugly solution that works everywhere to individual solutions for everyone.
<michael-vb> Basically we provide client-side but not server-side OpenGL, and have to prevent the server from loading the library.
<michael-vb> Like NVIDIA do.
<michael-vb> But they have a few more people working on it and probably a cleaner solution.
<michael-vb> Maybe.
<LocutusOfBorg> I'm studying right now a solution like nvidia does, more debian and ubuntu friendly
<LocutusOfBorg> I'm reading nvidia-graphic-drivers/debian/*.postinst
<LocutusOfBorg> I still have to implement that in vbox, but I'll do eventually :)
<michael-vb> For the Debian Additions package you can use the official Debian method which is nice and clean.
<michael-vb> Can't immediately remember what it was, but of course I did look at it.
<LocutusOfBorg> michael-vb,
<LocutusOfBorg> update-alternatives --force \
<LocutusOfBorg>             --install /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf x86_64-linux-gnu_gl_conf /usr/lib/nvidia-361/ld.so.conf 8604 \
<LocutusOfBorg> this is what nvidia does
<LocutusOfBorg> I have to do mostly the same
<LocutusOfBorg> install two .conf files with the vbox directories
<LocutusOfBorg> and update the default
<michael-vb> Right, sounds nice and Debian-ish.
<LocutusOfBorg> :)
<LocutusOfBorg> the problem is to install the conf file, to update alternatives again on prerm, to check dkms module
<semiosis> Odd_Bloke: if you're around, can you spare a moment to look at the conversation slangasek and I had yesterday about 'manage_etc_hosts: localhost' in the ubuntu-cpc images?  https://irclogs.ubuntu.com/2016/07/11/%23ubuntu-devel.html#t22:14
<LocutusOfBorg> and most important *test everything* before uploading
<LocutusOfBorg> and... ENOTIME :)
<LocutusOfBorg> but I want to have the change for debian stretch
<pitti> RAOF, arges: could you please review systemd/xenial? I uploaded it, so I can't self-review. thanks!
<arges> pitti: ok i'll take a look in a bit
<Laney> pitti: bos01 woes?
<caribou> xnox: Is s390-tools still expected to set crashkernel= in /etc/zipl.conf ?
<pitti> Laney: what, again?
<pitti> arges: cheers!
<Laney> pitti: 5 minutes ago or so
<pitti> Laney: ah, I know: http://autopkgtest.ubuntu.com/running.shtml#queue-ubuntu-yakkety-ppc64el
<pitti> this is bogus
<pitti> this looks like using some outdated retry-autopkgtest-regressions script
<pitti> Laney: cleaned these two and restarted
<Laney> pitti: hmm
<Laney> why did that kill it?
<pitti> Laney: "autopkgtest exit with 1" is a Should Not HappenTM
 * pitti tosses a lost compose key in there
<pitti> Laney: "foo/1.2.3" is not a valid test spec, autopkgtest can't decipher what that means and exits with a CLI error
<pitti> this could possibly be made more robust by ignoring/consuming and tossing away invalid test requests, but that would just  silently paper over problems somewhere else
<pitti> not sure what to do with bogus queue entries..
<coreycb> arges, bdmurray: hi, we have the following openstack SRUs in the queue if you have some time to chip away at them: http://paste.ubuntu.com/19187967/
<Laney> Doesn't feel that valuable to me to kill the workers in this case
<pitti> but this is what an outdated retry-autopkgtest-regressions would produce, so I'm betting on that
<pitti> Laney: I like to immediately kill a worker on exit code 1, as that's a "Should Not Happen"; i. e. the worker itself could check the package argument for sanity and presumably basic_reject() it
<pitti> then it'd stay in the queue forever until someone looks and cleans up
<pitti> that could be a better failure mode
<pitti> but much less visible
<Laney> pitti: For malformed input you know it's not going to work, so an option is to remove it from the queue and display this somewhere or mail it to us, or something
<Laney> This rogue person is probably going to run r-a-r again at some point
<pitti> Laney: yes, remove + mail sounds good
<xnox> caribou, no. you said you are taking that into the other package that provides crashing functionality
<xnox> i think I will need to remove that from installer & s390-tools to migrate over to crashdump package.
<caribou> xnox: yes I did, I just thought I had to remove it from s390-tools so everything is fine
<xnox> caribou, i can handle removal from s390-tools and installer.
<xnox> caribou, is it in yakkety & xenial now? or just yakkety for now?
<caribou> xnox: fine, the version in Yakkety will set it if it is absent & I'm about to SRU the same to Xenial
<xnox> cool.
<caribou> xnox: with the cio_ignore fix & a few other things
<caribou> xnox: to xenial, it's already in Y
<cpaelzer> is there a trivial way to send something into apport handling to test an apport hook of an upload?
<cpaelzer> I thought sending a SIGSEGV, but thats not kicking in as I hoped
<cpaelzer> maybe I just need to enable something, but if there is a common sequence let me know
<cpaelzer> hmm, actually I think it would be enough to call apport-bug without a crash - consider it solved
<pitti> cpaelzer: yes, report a bug and save it or look at the data in the expander, or SIGKILL the program if your hook is specific to a crash
<seb128> sil2100, shrug, so you ignored my NEW review for repowerd and landed it despite the blocker issue I gave you and bypassed NEW? :-(
<pitti> Laney: meh, next mass-killing; I guess I'll actually teach the workers to verify the test argument now..
<pitti> oh, seems it's britney itself which does those -- http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#libtemplates-parser
<pitti> nevermind, I was just reading this wrong
<pitti> Laney: done
<bdmurray> coreycb: Did you get anybody to look at those SRUs?
<coreycb> bdmurray, hey, not yet
<bdmurray> coreycb: Do you know why bug 1592865 was tagged v-done?
<ubottu> bug 1592865 in keystone (Ubuntu Xenial) "[SRU] mitaka point releases" [Undecided,Incomplete] https://launchpad.net/bugs/1592865
<coreycb> bdmurray, that's a mistake, I updated the bug
<coreycb> ddellav, ^
<ddellav> coreycb ack
<bdmurray> coreycb: could you add some comment about how you'll test stuff in bug 1501854
<ubottu> bug 1501854 in uwsgi (Ubuntu) "mod_proxy_uwsgi doesn't work with unix domain sockets" [Undecided,Confirmed] https://launchpad.net/bugs/1501854
<bdmurray> er 1601854
 * kees has his eyes cross reading the gcc-5-cross debian/rules
<bdmurray> coreycb: The ceilometer version would be greater than the one in yakkety...
<coreycb> bdmurray, ok that's updated with test process
<coreycb> bdmurray, hmm
<coreycb> bdmurray, ok we need to fix that up then
<bdmurray> coreycb: should I keep looking then or wait for ceilometer to be sorted?
<coreycb> bdmurray, I could either drop ceilometer from that bug or else that bug is blocked by me until I situate ceilometer
<coreycb> bdmurray, probably might as well leave ceilometer in that bug and I'll fix it up tomorrow
#ubuntu-devel 2016-07-13
<cpaelzer> good morning
<pitti> Good morning
<tsimonq2> o/ pitti, verification-done on bug 1575460 as of 1 min ago :)
<ubottu> bug 1575460 in lubuntu-meta (Ubuntu Xenial) "Intel video driver not installed by default on Lubuntu 16.04 fresh install" [Undecided,Fix committed] https://launchpad.net/bugs/1575460
<tsimonq2> pitti: how are you? :)
<pitti> a bit tired, but quite fine, thanks! how about yourself?
<tsimonq2> great :)
<ginggs> Logan: hi, please send your fix-isnan.patch for leocad to Debian bug #818819
<ubottu> Debian bug 818819 in leocad "leocad: FTBFS with libc 2.23: 'isnan' was not declared in this scope" [Serious,Open] http://bugs.debian.org/818819
<Markus23> Dear FOSS developers! Please fully fill out our survey at http://elektra.limequery.org/625192 and a donation will go to FOSS projects. The survey is carefully crafted and helps research! Thank you! If you have any questions you can ask me.
<mwhudson> can someone explain to me how to use livecd-rootfs?
<mwhudson> or point me to some documentation
<pitti> ogra perhaps ^ ?
<mwhudson> pitti: hi :-)
<mwhudson> pitti: steve and i were talking about https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1599799 a little today
<ubottu> Launchpad bug 1599799 in snapd (Ubuntu) "snapd > 2.0.2 fails on yakkety" [High,Triaged]
<mwhudson> pitti: given that snapcraft failure you posted was with snapd 2.0.2, it seems that this is some problem that's caused by, or maybe revealed by, some change in yakkety, not snapd
<mwhudson> pitti: obvious candidate would be systemd, i think?
<pitti> mwhudson: yes, it's certainly a change in some underlying thing (kernel/systemd/util-linux/whatever)
<mwhudson> pitti: do you have any ideas on how to figure out what?
<mwhudson> i was idly wondering if you could reproduce it by booting a yakkety vm and just installing and uninstalling a snap in a loop
<pitti> mwhudson: I don't know what snapd is trying to do there, but the bug reproduces perfectly locally, so it should be quite simple to look what exactly fails there
<pitti> quite obviously it's setting up some loop device, and apparently that fails
<mwhudson> yeah
<mwhudson> i don't really see how that could fail though...
<pitti> well, watch it live and see what happens :)
<pitti> there's only so much you can learn from that tiny log
<mwhudson> is it as bad as snapd just not working at all in yakkety?
<mwhudson> i guess i can find that out easily enough
<pitti> mwhudson: y-proposed only, 2.0.2 in yakkety still works
<pitti> (well, the tests pass, so I guess it works well enough)
<mwhudson> pitti: not all the time, according to that snapcraft failure
<mwhudson> but yeah true, not completely broken
<pitti> actually, 2.0.2 started to fail now as well,  for a different reason
<mwhudson> oh good
<pitti> it last succeeded on June 9 (2.0.2)
<mwhudson> wait no, the other thing
<pitti> ... value *exec.Error = &exec.Error{Name:"hello-world.echo", Err:(*errors.errorString)(0xc82000e670)} ("exec: \"hello-world.echo\": executable file not found in $PATH")
<pitti> maybe hello-world changed in the store?
<mwhudson> sounds like a great test, in that case
<mwhudson> pitti: it's passed on xenial reasonably recently though
<mwhudson> oh no, not that recently
 * pitti runs locally on x and y
<mwhudson> heh yep looks like the hello-word snap no longer provides hello-world.echo
<ogra> mwhudson, it is really badly documented ...  livecd-rootfs is onlÃ¶y a bunch of config files for live-build
<mwhudson> ogra: well i guess i'm glad that i didn't miss the docs then...
<pitti> mwhudson: xenial has 2.0.10 already (breaking the SRU rules), so that also introduces some jitter
<mwhudson> ogra: i notice that some of the config has hard-coded paths in /usr
<ogra> mwhudson, this and https://lists.ubuntu.com/archives/ubuntu-devel/2011-June/033458.html and http://bazaar.launchpad.net/~ogra/project-rootstock-ng/trunk/files might be the best hints you can get
<mwhudson> ogra: so i guess if someone tells me to "use lp:livecd-rootfs" i check it out, dpkg-buildpackage & dpkg -i, then run lb config $whatever?
<tsdgeos> anyone knows who do i have to "complain" because compiz-core-dbgsym in yakkety ddbs is too old?
<ogra> mwhudson, it isnt that easy, but essentially, yes ... (you need to have the right ENV setup and to mimic the builds proper you need to have a stack of chroots
<ogra> )
<mwhudson> ogra: to be less mysterious, i'm trying to follow http://people.canonical.com/~mtrudel/console-conf/README
<ogra> see the links above, they should explain it
<mwhudson> which i think covers the ENV part
<mwhudson> ok, /me reads
<ogra> from rootstock specifically http://bazaar.launchpad.net/~ogra/project-rootstock-ng/trunk/view/head:/rootstock-touch
<mwhudson> i don't think i've used live-build since 2011 or so, almost long enough
<ogra> it s awful and painful ...
<mwhudson> and shell
<mwhudson> that's about the limit of my memories
<pitti> mwhudson: ah, 2.0.10 dropped that HelloWorld test
<mwhudson> pitti: oh ok
<ogra> mwhudson, well, livecd-rootfs used to be a single shell script ... despite being spaghetti code it was a million times easier to maintain and use
<mwhudson> ubuntu-image will save us all
<mwhudson> right?
<ogra> hah
<ogra> (for now i'd be happy if ubuntu-image saved just snappy :P )
<mwhudson> ogra: http://bazaar.launchpad.net/~ogra/project-rootstock-ng/trunk/view/head:/rootstock-touch is fairly terrifying
<ogra> lol, sorry :)
<ogra> it describes the build process pretty well though ... :)
<mwhudson> ogra: why does it run lb inside the chroot? isolation?
<ogra> it comes from a time before lxd :) ... but yes, clean build env ... and you dont really want to taint your PC with build scripts
<ogra> effectively it mimics a live builder
<ogra> (it is just doing the same as the launchpad live builders did by that time)
<mwhudson> fair enough
<cjwatson> and still do, because we want to run lb in a chroot of the appropriate Ubuntu series rather than whatever the host's base system is
<ogra> cjwatson, good to know ... i really didnt look anymore since the switch to launchpad buildd
<mwhudson> uh why the heck would lb build fail with 'E: Unable to locate package zsync'
<ogra> sounds like a missing dependency
<mwhudson> or missing universe?
<ogra> oh, right, not in main
<ogra> given that we run all our images through it on cdimage, someone should probably MIR it eventually :)
<mwhudson> um i seem to have created a precise chroot somehow
<mwhudson> seems unlikely to be what i wanted...
<ogra> did you set the right env vars ?
<mwhudson> i ran PROJECT=ubuntu-core SUBPROJECT=system-image EXTRA_PPAS=snappy-dev/image SUITE=xenial ARCH=amd64 lb config
<mwhudson> which looks plausible to me...
<mwhudson> oh
<mwhudson> but i put the sudo on the wrong side of the env :(
<ogra> EXTRA_PPAS="snappy-dev/image snappy-dev/edge" ... but yeah, the rest looks ok
 * mwhudson swigs more beer
<ogra> if you buuild core you definitely need universe btw
<mwhudson> nope still deboostrapping precise
<ogra> did you properly link the /usr/share/livecd-rootfs/live-build/auto scripts `
<ogra> ?
<mwhudson> ogra: no, just figured that out myself
<ogra> :)
<mwhudson> ok that looks better
<mwhudson> deboostrap is still running with --components=main,restricted but we'll see if that matters in the long run
<ogra> we fixed a lot of the universe deps on our way to xenial ... but i'm not sure everything is gone ... the images definitely still have universe enabled
<mwhudson> well that looks moderately successful
<mwhudson> still exited with status 1 mind
<ogra> heh
<ogra> did it spit out two snaps ?
<mwhudson> 99zz-check-uid-gid.chroot had a sad it seems
<mwhudson> ogra: i don't think so, where would they be?
<ogra> in $PWD
<mwhudson> then no
<ogra> then it didnt finish
<mwhudson> ogra: http://paste.ubuntu.com/19262524/
<ogra> paste the error ... todays xenial builds definitekly worked on the buildds... 99zz-check-uid-gid.chroot usually indicates that a system user was added
<ogra> hmm, the uuidd group was added by something
<mwhudson> the uuidd package, i assume
<ogra> well, i dont get how you get it there ... it isnt like the seed changed in xenial
<mwhudson> pulled in by lupin-casper apparently
<ogra> uh
<ogra> nothing you want really
<ogra> you still use PROJECT=ubuntu-core SUBPROJECT=system-image ?
<mwhudson> ys
<ogra> that shouldnt pull in such stuff ... weird
<mwhudson> it's only excluded for "ubuntu-server|ubuntu-touch|ubuntu-touch-custom)" apparently
<ogra> well, and for all images that dont use an initrd or kernel at all :)
<ogra> like all system-image ones should
<mwhudson> i see
<ogra> (we build a kernel snap during the ubuntu-core build, but thats a separate hack, not using live-build mechanisms )
<ogra> try adding IMAGEFORMAT="plain"
<ogra> and PREINSTALLED="true"
<ogra> (wild guess though)
<mwhudson> ok one more try and then bed :)
<flexiondotorg> rbasak, I've seen you comments on my mate-hud sponsoring package.
<flexiondotorg> I've corrected the license.
<flexiondotorg> I've updated to adhere to Debian Python Policy.
<flexiondotorg> I can make the package quilt too. But so far all the Ubuntu MATE specific packages in the Ubuntu archive are native.
<flexiondotorg> So, is this simply a case of splitting the debian packaging from the source?
<mwhudson> i have a snap!
<ogra> yay
<ogra> you shoudl have two :)
<ogra> a kernel and an os snap
<mwhudson> it's not finished yet :)
<ogra> ah
<mwhudson> although i have livecd.ubuntu-core.os.snap  ubuntu-core_16.04+20160713.23-17_amd64.snap
<mwhudson>  so far
<ogra> right, it creates a clean new chroot and in there creates a kernel snap
<mwhudson> ah ok
<ogra> so that takes a bit
<mwhudson> yeah, it's getting kernel packages now, which seems consistent with making a kernel snap
<ogra> yup
<mwhudson> for next time is there an easy way to make it use the same proxy apt is configured to use?
<ogra> shzould be done soon then ... it just installs them, creates an initrd and calls snapcraft snap
<ogra> you can use MIRROR= and point to a local packageproxy
<ogra> iirc
<ogra> (see rootstock :) )
 * ogra notes it is late at your place :)
<ogra> (by the snap version :) )
<rbasak> flexiondotorg: if you think the package should definitely be native, I'm happy for you to make that case. As long as it makes sense and wasn't a mistake.
<flexiondotorg> OK. I'll push the changes and update the bug in a bit :-)
<rbasak> flexiondotorg: I'd expect it to be quilt format though, because that more easily allows Debian/Ubuntu to patch on top of upstream releases if necessary. For the existing Ubuntu MATE specific packages, do "upstreams" exist?
<rbasak> flexiondotorg: in this case, for example, what if Fedora wanted MATE with HUD support or something? It doesn't feel distro-specific to me.
<flexiondotorg> rbasak, Those MATE packages in Debian and Ubuntu are all quilt.
<flexiondotorg> Those specific to Ubuntu MATE, and only in the Ubuntu archive, are currently all native.
<rbasak> flexiondotorg: note that debian/patches/ exists in the version I reviewed, which AFAIK doesn't make sense for a native package.
<flexiondotorg> mate-hud can only work on Ubuntu.
<flexiondotorg> Not other distro I've checked carries the required libraries.
<rbasak> OK, but that's because of missing dependencies, which isn't fundamental.
<flexiondotorg> rbasak, I'll drop debian/patches it is leftover from my skeleton.
<rbasak> As an exmaple, unity, unity8 and mir are all non-native packages.
<mwhudson> ogra: heh yes indeed
 * mwhudson zzz
<flexiondotorg> rbasak, So I am perfectly happy to make it non-native.
<rbasak> OTOH, dpkg is native because it would make no sense for dpkg to be a separate upstream to Debian.
<rbasak> flexiondotorg: I don't want you to break consistency just because of one reviewers opinion.
<flexiondotorg> I can split the packaging from the "upstream".
<rbasak> So sorry, I'm not sure what my opinion is. If you have a good reason, perhaps document in the bug and we'll leave it to the archive admins to decide?
<flexiondotorg> rbasak, Things are the way they are because that was how the very first Ubuntu MATE packages were introduced.
<flexiondotorg> I quite happy to do "the right thing" :-)
<flexiondotorg> I'll make it non-native.
<rbasak> flexiondotorg: would you mind asking on the ubuntu-devel ML or something? I'd appreciate other opinions, and then the thread will be archived and you can have consistency. That's "the right thing", IMHO. Or if you wish, I'm happy to upload and leave it to the archive admins on NEW review if you wish, since it appears to be debateable.
<flexiondotorg> rbasak, I will make it non-native. It does seem the sensible choice and no effort.
<rbasak> flexiondotorg: OK, thanks.
<flexiondotorg> rbasak, I've update the open posting of the bug and added a comment - https://bugs.launchpad.net/ubuntu/+bug/1602270
<ubottu> Launchpad bug 1602270 in Ubuntu "[needs-packaging] mate-hud" [Wishlist,New]
<flexiondotorg> Rebuilt and tested.
<rbasak> flexiondotorg: thanks. I reviewed from your .dsc before. Should I be using your git repo on bitbucket now? When I reviewed, there was no postinst. On bitbucket, there is a postinst that calls glib-compile-schemas. Should this not use a dpkg trigger? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587661 suggests that a suitable trigger is available. Finally, for an upload, I'll need an orig tarball
<ubottu> Debian bug 587661 in glib2.0 "should install glib-compile-schemas in libglib2.0-bin" [Wishlist,Fixed]
<rbasak> from somewhere. Should I just be using uscan?
<flexiondotorg> rbasak, I update the .dsc link in the opening post too :-)
<flexiondotorg> So if the dget of that .dsc is OK. Then drop the ~yakkety1.2 suffix and upload please.
<flexiondotorg> rbasak, https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/crazy-mate/+files/mate-hud_16.10.0-1~yakkety1.2.dsc
<rbasak> pitti: I have the known mysql-5.7 dep8 failure on ppc64el holding up proposed migration again. Can we override it to treat as "always failed"?
<pitti> rbasak: yep, bumped the hint'
<rbasak> Thanks!
<tseliot> pitti: you rejected u-d-c in xenial because it's not yet in yakkety. The truth is u-d-c in yakkety keeps failing because of this: The following packages have unmet dependencies:  sbuild-build-depends-ubuntu-drivers-common-dummy : Depends: python3-aptdaemon.pkcompat but it is not going to be installed
<tseliot> https://launchpadlibrarian.net/272774340/buildlog_ubuntu-yakkety-amd64.ubuntu-drivers-common_1%3A0.4.19_BUILDING.txt.gz
<arges> cking: bug 1599219 1599221 1599259 did these get fixed in yakkety?
<ubottu> bug 1599219 in spl-linux (Ubuntu Xenial) "SRU: spl-linux: xenial: apply fix Fix do_div() types in condvar:timeout" [Medium,In progress] https://launchpad.net/bugs/1599219
<arges> well the first two relaly
<cking> arges, 1599219 says it's been fixed in spl 0.6.5.7 (in Yakkety),  1599221 says it's in yakkety and needed to be backported, so if spl 0.6.5.7-0ubuntu4 is released then yes
<arges> cking: ok i'll fixup those tasks in the bug, it makes review a bit easier for me than having to parse through version numbers and released versions etc
<slangasek> cking: is stress-ng autopkgtest failing on armhf because the tests are broken, or because the kernel is broken? :)
<cking> slangasek, got a link to that so I can figure it out?
 * cking found it, just a sec
<slangasek> cking: http://autopkgtest.ubuntu.com/packages/s/stress-ng/yakkety/armhf/
<slangasek> k
<cking> slangasek, looks like the semantics on arm are different from x86 when it comes write prot on the text segment, which is not what I expected, but why this didn't happen previously I don't know as I'm sure that's passed before
<slangasek> :)
<cking> hrm, it passed on the dragonboard too when I tested it, most bizzare
<slangasek> dragonboard being an arm64 host kernel, I imagine?
<smoser> hey. in a container, i'm seeing -.mount fail occasionally
<smoser> what seems odd is that it ever succeeds.
<smoser> as when it fails, systemctl status -- -.mount
<smoser> shows:
<smoser> ExecMount=/bin/mount /dev/disk/by-label/cloudimg-rootfs / -t ext4
<jderose> tyhicks: so in terms of getting the ecryptfs-utils fixes into 16.04.1, will a new upstream 112 release be made or will 111-0ubuntu1 just be patched?
<tyhicks> jderose: 111-0ubuntu1 will be patched
<tyhicks> jderose: they'll go through the security pocket and I'll release them by tomorrow
<jderose> tyhicks: do you have patched yet, or would be helpful for me to attach an updated patch to lp:1597154
<jderose> er, have a patch yet...
<tyhicks> jderose: I have debdiffs prepared but haven't tested
<tyhicks> jderose: I'll upload them to the ubuntu-security-proposed ppa shortly and point you there so you can test
<jderose> tyhicks: awesome, thanks. yeah, i'll help test them as so as there are builds
<cking> slangasek, yep, arm64 dragonboard it works fine, so I wonder what the kernel is on that arm64 test environment is
<tyhicks> jderose: wily and xenial updates are building in https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa
<slangasek> cking: autopkgtest [23:32:03]: testbed running kernel: Linux 4.4.0-28-generic #47-Ubuntu SMP Fri Jun 24 10:13:13 UTC 2016
<cking> slangasek, ok, I'll get access to a box later tonight or tomorrow and figure out what the root cause is
<cking> ta
<slangasek> cking: of course, that doesn't tell you if it's an arm64 or armhf host
<jderose> tyhicks: thanks!
<slangasek> (and I don't recall which it is)
<cking> no probs, I can dig into it from now
<tyhicks> jderose: thanks for offering to test! (note that I haven't staretd my testing of those security updates just yet)
<jderose> tyhicks: no problem, System76 is always happy to help with testing :)
<tyhicks>  \o/
<semiosis> slangasek: whats the next step for my merge request?  i haven't seen Odd_Bloke around in a couple days to ask about the localhost thing.  thoughts?
<semiosis> https://code.launchpad.net/~semiosis/livecd-rootfs/fix-for-1565985/+merge/298305
<smoser> slangasek, or someone else systemd boot knowledgable.. care to read bug https://bugs.launchpad.net/juju-core/+bug/1602192 .
<ubottu> Launchpad bug 1602192 in juju-core "deploy 30 nodes on lxd, machines never leave pending" [Critical,In progress]
<smoser> my last two comments i think are the crux of the issue.
<smoser> i ping you by name because other people i know that could answer this are typically europe time zone
<smoser> (pitti and xnox )
<slangasek> smoser: the job output notes that this is from systemd-fstab-generator.  Does /etc/fstab have different contents on the successful vs. failed containers?
<smoser> no
<slangasek> semiosis: we do really need the input from the cloud team regarding correctness of the hostname resolution change (and whether to make it in both places or neither).  If Odd_Bloke is unavailable, perhaps rcj or gaughen can help
<slangasek> smoser: ok. what are the contents there?
<smoser> # cat /etc/fstab
<smoser> LABEL=cloudimg-rootfs   /        ext4   defaults        0 0
<slangasek> alright
<slangasek> so has udev/systemd failed to resolve that label to a device?
<slangasek> (is /dev/disk/by-label/cloudimg-rootfs present?)
<smoser> never in a container.
<smoser> no udev
<smoser> so that is strictly wrong. but in most cases (probably > 90% of the time) something addresses that.
<semiosis> slangasek: fwiw, as far as correctness goes, Odd_Bloke already had me change from installing libnss-myhostname (as was done in pre-xenial vagrant boxes) to using this cloud-init method.
<semiosis> slangasek: you also had concerns about the virtualbox packages not being in main.  if that's a blocker for you, what direction would you suggest taking?  i'd be happy to start down that path
<semiosis> ...if necessary
<slangasek> semiosis: I've been talking with gaughen already about a path forward on virtualbox.  We can probably land this change and deal with the MIR for virtualbox later, provided we agree that's the direction to go
<semiosis> slangasek: that sounds great to me.  thanks for your time.  let me know if there's anything else I can do to help move things forward.
<jderose> tyhicks: finished testing ecryptfs-utils packages from https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages everything seem solid, no issues found. i tested both ecryptfs-setup-swap and ecryptfs-utils.postinst
<gaughen> slangasek, semiosis I'm reading the scrollback
<tyhicks> jderose: thank you for reporting back :)
<tyhicks> jderose: did you only test on GPT partitioned devices that were affected by the bug?
<jderose> tyhicks: thus far yes. still need to check for regressions on non-GPT partitioned drives
<jderose> we'll keep testing though
<tyhicks> jderose: ok - I'll be testing that situation, as well
<tyhicks> jderose: I just wanted to make sure I understood what testing you've already done
<jderose> tyhicks: ah, gotcha. on a UEFI system with an NVMe drive and an oem install, i first tested that ecryptfs-setup-swap correctly worked when going through oem-firstrun and choosing encrypted home directory. then i unset bit 63 and ran `sudo apt-get install --reinstall ecryptfs-utils` to make sure ecryptfs-utils.postinst would correctly re-set bit 63. both worked fine.
<jderose> tyhicks: okay, i finished tested on an non-NVMe SSD, in both UEFI (GPT partitioning) and BIOS (msdos partitioning)... no issues found, everything seems shiny.
<tyhicks> jderose: thanks again :)
<jderose> also, i made sure that the new ecryptfs-utils.postinst script would re-set bit 63 okay even when on a standard SSD (non-NVMe)
<jderose> np :)
<jderose> tyhicks: oh, i've only been testing xenial so far, haven't tested wily at all. need help testing wily?
<tyhicks> jderose: no, I can handle wily
<jderose> tyhicks: cool, thanks!
<nacc> mdeslaur: ping re: python-django 1.8.7-1ubuntu2; i'm trying to merge to yakkety, and it seems like our xenial CVE fix ended upnot being the one taken upstream (the patch's commit sha doesn't match anything on github or anonscm and there's no dep3 url in the patch)
<nacc> mdeslaur: the merge is fine, in that upstream has the right CVE fix, just wanted to bring to your attention, in case xenial needs a corrected fix
#ubuntu-devel 2016-07-14
<mdeslaur> nacc: ah, interesting...I'll take a look....they're the ones that usually give us the patches
<mdeslaur> nacc: which CVE is this? did you take the regression patch into consideration?
<nacc> mdeslaur: yeah it's the other one
<nacc> debian/patches/CVE-2016-2513.patch
<ubottu> The password hasher in contrib/auth/hashers.py in Django before 1.8.10 and 1.9.x before 1.9.3 allows remote attackers to enumerate users via a timing attack involving login requests. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-2513)
<nacc> fancy!
<nacc> mdeslaur: the patch in our package doesn't match https://github.com/django/django/commit/67b46ba7016da2d259c1ecc7d666d11f5e1cfaab
<nacc> mdeslaur: oh i'm really sorry!
<nacc> mdeslaur: i was looking at the master commit, not the stable-1.8.x commit
<nacc> https://github.com/django/django/commit/f4e6e02f7713a6924d16540be279909ff4091eb6
<nacc> still a different sha, though?
<mdeslaur> ah! ok
<mdeslaur> well, a different sha happens often when we get prerelease patches
<nacc> makes sense
<nacc> i will try and verify the upstream patch is identical to what we took
<mdeslaur> I just looked at the diff between the two, there are a few doc changes, but nothing important
<nacc> mdeslaur: ok, thanks!
<nacc> and sorry again for the noise!
<mdeslaur> nacc: np! I'd rather we double check than to have a broken patch we didn't notice, so thanks!
<nacc> mdeslaur: np, good side-effect of our merge process :)
<cpaelzer> good morning
<dnl> hi, can somebody please close https://bugs.launchpad.net/ubuntu/+source/lzlib/+bug/598691
<ubottu> Launchpad bug 598691 in lzlib (Ubuntu) "Incorrect symbolic link" [Undecided,New]
<dnl> this has been fixed years ago already
<cpaelzer> dnl: sure, I'll look at it - thanks for reporting
<dnl> great, thanks :)
<dnl> cpaelzer: thanks
<pitti> Good morning
<tsimonq2> o/ pitti, how are you? :)
<pitti> slangasek: nova/s390x holds up too many things; I went back to force-badtesting it, but this time only for the current version in y; so it won't apply to new nova uploads
<pitti> (just a FYI)
<flexiondotorg> pitti, If you are able can you cast an eye over this SRU please - 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> I've completed the testing and tagged appropriately.
<pitti> flexiondotorg: we normally let SRUs mature for 7 days before we release them; are you absolutely sure that this does not break anything?
<flexiondotorg> pitti, Yes, I am. I've been running that packages for a couple of months now.
<pitti> okay
<flexiondotorg> And some of the fixes originated from the Ubuntu MATE and are already SRUd in the Ubuntu themes ;-)
<pitti> released
<flexiondotorg> Many thanks!
<bluesabre> Hello everyone! Seeking sponsorship to -proposed for this xserver-xorg-video-intel xenial SRU, https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1568604
<ubottu> Launchpad bug 1568604 in X.Org X server "Mouse cursor lost when unlocking with Intel graphics" [Medium,Confirmed]
<rbasak> tjaalton: ^
<rbasak> I think I've seen the mouse cursor disappearing too, FWIW, so it would be nice to have this fixed. A wholesale new upstream snapshot in a package that is critical for maybe 50% of Ubuntu users doesn't exactly seem "Regression potential here seems minimal." though.
<tseliot> rbasak, bluesabre: I suspect tjaalton is on holiday. Can you bisect the driver to see what commit solves the problem, please? That would make the SRU much more self-contained.
<bluesabre> tseliot: Yes, I'll work with others to try to find the fix(es)
<tseliot> bluesabre: when you're done with that, I'll sponsor the upload. Thanks
<cjwatson> All new ARM builds (armel, armhf, arm64) created as of 10:59 UTC today will be dispatched to arm64 VMs on scalingstack.
<cjwatson> Just in case this causes any issues (hopefully not).
<flexiondotorg> rbasak, Can you cast an eye over https://bugs.launchpad.net/ubuntu/+bug/1602270 please
<ubottu> Launchpad bug 1602270 in Ubuntu "[needs-packaging] mate-hud" [Wishlist,New]
<flexiondotorg> rbasak, Here is the new .dsc - https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/crazy-mate/+files/mate-hud_16.10.0-1~yakkety1.2.dsc
<cjwatson> Also this means building armhf on 4.2 kernels rather than 3.2.
<jtaylor> hm the xenial binutils update broke linux perf
<jtaylor> though maybe that will fix itself when the new linux comes out of proposed
<jtaylor> how did binutils make it out of proposed without a complete transition?
<jtaylor> in particular the libbfd soname change
<smoser> pitti, around?
<smoser> pitti, i'd really appreciate your thoguhts at https://bugs.launchpad.net/juju-core/+bug/1602192 . systemd's -.mount job (mount /) is behaving odd sometimes.
<ubottu> Launchpad bug 1602192 in juju-core "deploy 30 nodes on lxd, machines never leave pending" [Critical,In progress]
<pitti> smoser: hey
<pitti> smoser: queueing (team meeting in a few minutes)
<smoser> thanks
<smoser> pitti, you want me to try to get you a system to look at ?
<smoser> my script fairly easily reproduces and cleans up after itself. you just need lxd
<pitti> smoser: reproduction script sounds perfect
<pitti> smoser: is zfs relevant at all?
<pitti> I have lxd set up on my laptop (but on my normal btrfs file system)
<smoser> zfs possibly is relavant.
<smoser> i can get you an instance where i set it up if you want.
<pitti> smoser: I started the script on my laptop
<smoser> yeah, i ran to 134 on my laptop or something
<pitti> if it doesn't reproduce that way, I'll try a vm with a zfs pool
<smoser> i think it ended up exhausting IP addresses on the range.
<pitti> smoser: sure, if that's easy for you that can never hurt
<smoser> do you know if you have access to server stack ?
<pitti> smoser: oh, you mean it doesn't create them serially, but all 134 were running in parallel?
<smoser> thats the easiest thing for me
<pitti> smoser: I've heard about a lot of *Stack, but not this one; example IP?
<smoser>  10.245.162.60
<smoser> see if you can reacn that over vpn
<pitti> semiosis: yes, I do
<pitti> err, smoser
<smoser> i can try on canonistack if you can't get there, just everything slow on canonistack
<pitti> smoser: no, seems fine
<smoser> k. i'll get you in tehre then
<pitti> x-013 failed to boot. keeping x-013.
<pitti> â -.mount                       loaded failed failed /
<pitti> smoser: so, yep, can reproduce, unrelated to zfs
<slangasek> pitti: nova> ack
<pitti> smoser: I left some initial notes in the bug
<pitti> needs some research
<smoser> pitti, htanks
<pitti> Jul 14 15:47:42 x-013 systemd[1]: inotify_init1() failed: Too many open files
<pitti> smoser: haha
<pitti> smoser: curiously with plain LXC it *also* fails in the 13th container
<GunnarHj> pitti: Yakkety isn't open for translation yet. Is that intentional?
<pitti> GunnarHj: only in the sense of "known", not "desirable"
<smoser> pitti, 13 is an unlucky number.
<pitti> for sure
<smoser> it is very odd taht 13 is so common
<pitti> but I have some handles on that
<pitti> smoser: you mean it fails on the 13th for other people too?
<pitti> if we have a "1024 open files" limit somewhere and every container opens some 80 files, then it would be quite plausible
<pitti> anyway, testing the other stuff first, the inotify errors might be a red herring
<smoser> it did once fail for me on 13th.
<smoser> but locally i made it to like 123
<smoser> or something.
<GunnarHj> pitti: Are there any obstacles, or is it just about finding the time to do it?
<smoser> but yeah, open file handles could be possible.
<smoser> the original bug opener said 13 and i have definitely seen 13
<pitti> GunnarHj: TBH I'm not very familiar with the process; that's still somewhere between wgrant and dpm
<GunnarHj> pitti: Ok, then I'd better ping them about it. Thanks!
<smoser> pitti, rharper suggests libvirt serivce file does something to stop limits on processes and such
<smoser> rharper, /lib/systemd/system/lxd.service has similar to /lib/systemd/system/libvirt-bin.service
<rharper> smoser: ok, there is a LimitNOFILE=65535 that can be set
<smoser> yeah, lxd.service has that at infinity
 * smoser laughs at pinging someone by saying that.
<rharper> haha
<teward> heh
<jderose> tyhicks: much thanks for getting the fixed ecryptfs-utils out so quickly! i'm very happy this is making it onto the 16.04.1 ISO
<tyhicks> jderose: and a big thanks to you for the patch :)
<jderose> tyhicks: well, i should have followed up long ago when i first encountered this, just got too busy with other stuff. better late than never though :)
<nacc> rbasak: so it's not so trivial as adding the needs-root restriction, as only one specific test needs root (and other tests fail if they have root)
<rbasak> nacc: :-(
<rbasak> nacc: there's an example in the juju-core dep8 test of how to drop root, if that helps.
<nacc> rbasak: ok, i'll take a look
<rbasak> (IIRC there were a couple of gotchas)
<rbasak> I'm not sure what the current state of the Juju packaging is. It should be in juju-core in Trusty I think. If not, Wily.
<GunnarHj> rbasak: Hi Robie, any news on the language packageset?
<phillw> Yes, I know I'm not allowed on here and will immediately leave. But, this is an error ..
<phillw> 2 not fully installed or removed.
<phillw> After this operation, 0 B of additional disk space will be used.
<phillw> Setting up mysql-server-5.7 (5.7.13-0ubuntu3) ...
<phillw> Renaming removed key_buffer and myisam-recover options (if present)
<phillw> sed: can't read /etc/mysql/my.cnf.migrated: No such file or directory
<phillw> dpkg: error processing package mysql-server-5.7 (--configure):
<phillw>  subprocess installed post-installation script returned error exit status 2
<phillw> dpkg: dependency problems prevent configuration of mysql-server:
<phillw>  mysql-server depends on mysql-server-5.7; however:
<phillw>   Package mysql-server-5.7 is not configured yet.
<phillw> dpkg: error processing package mysql-server (--configure):
<phillw>  dependency problems - leaving unconfigured
<phillw> No apport report written because the error message indicates it's a follow-up error from a previous failure.
<nacc> strange.
<nacc> that seems to be a 16.10 issue ( rbasak --^ )
<rbasak> He's gone
<rbasak> That was an oversight. It's now fixed in ubuntu4.
<rbasak> (probably not in the release pocket yet)
<nacc> rbasak: yeah, the 'strange.' was more indicated at the showing up to pastebomb the channel and then to leave
<rbasak> Ah
<SpamapS> Hey old friends. I am having issues downloading from cloud-images.ubuntu.com ... anybody know a place to ping the admins on IRC?
<nacc> smoser: --^ did you say it was having issues?
<SpamapS> from traceroutes around the net.. looks to be saturated
<SpamapS> 16  SOURCE-MANA.edge5.London1.Level3.net (2001:1900:5:2:2::131a)  164.646 ms  166.219 ms  164.621 ms
<SpamapS> 17  cloud-images-ubuntu-com.sawo.canonical.com (2001:67c:1360:8001:ffff:ffff:ffff:fffe)  530.27 ms  584.155 ms  667.539 ms
<nacc> SpamapS: yeah, that's hwat i've heard, it's just bogged down right now (not 100% on it)
<nacc> SpamapS: i believe the right folks have been notified
<SpamapS> I wonder if that's due to the fact that it's hosting all the vagrant boxes now
<SpamapS> so many laptops :)
<smoser> SpamapS, i opened an rt.
<smoser> yeah, i think its just saturated.
<SpamapS> smoser: k, thanks
<smoser> SpamapS, can you easily check from europe
<smoser> i dont have a system there that i can test easily
<smoser> i wondered if its just the link over the ocean
<SpamapS> smoser: yeah I can actually spin up a vm in london.. hang on
<smoser> from lcy01 (same datacenter) i get 40M/s
<smoser> :)
<SpamapS> I don't think softlayer's london DC is the same one.. but it might be
<SpamapS> oh here, I have Amsterdam too
 * SpamapS spins that up
<SpamapS> smoser: from a London VM...
<SpamapS> 12  canonical-3.edge1.lon003.pnap.net (212.118.242.74)  9.896 ms  8.517 ms  7.827 ms
<SpamapS> 13  cloud-images-ubuntu-com.sawo.canonical.com (91.189.88.141)  7.915 ms  9.270 ms *
<SpamapS> so yeah, probably just the edge router that's saturated
 * SpamapS trying AMS
<smoser> wget ?
<smoser> wget http://cloud-images.ubuntu.com/daily/server/xenial/current/xenial-server-cloudimg-amd64-root.tar.xz -O /dev/null
<SpamapS> smoser: same, 40MB/s
<SpamapS> it's possible that's the same DC
<SpamapS> actually, funny story
<SpamapS> it bounces through amsterdam
<SpamapS> so not same DC
<SpamapS> http://paste.ubuntu.com/19393128/
<smoser> its that little pond that sits between us and london
<smoser> wonder if its related to brexit
<SpamapS> haha
<SpamapS> London exits the EU, and the internet
<smoser> SpamapS, i'm getting 6M/s now here.
<SpamapS> 100%[==========================================================================================================================================================================>] 147,791,640 27.9MB/s   in 6.5s
<smoser> definitely improved.
<SpamapS> smoser: oh actually yes
<SpamapS> mine sped up and finished
<SpamapS> overall it was 144kB/s.. but that's 1 hour of 15kB/s averaged in
<slangasek> jamespage: hi, looking at ceph in the NEW queue... why are we generating -dbg packages in the archive for this?
<slangasek> jamespage: also, some lintian errors; not sure if these are regressions, but they're problematic: E: ceph-mon: package-installs-python-bytecode usr/lib/python2.7/dist-packages/ceph_rest_api.pyo
<slangasek> jamespage: have checked, and the python errors are a regression.  not a blocker for NEW because it doesn't impact your binary splitting, but a pretty bad bug that ought to be fixed
<slangasek> jamespage: and accepted, including the -dbg packages, which we really do not need any more of in the archive
<sarnold> heh aren't those things a gig each?
<sarnold> my local mirror has nine gigs of ceph *dbg* packages.. it would be nice to get that back :)
 * smoser left mirror long ago due to such things. caching proxy now just keeps what it needs.
<slangasek> caching proxy always has the tradeoff that a cache miss is slow
<jamespage> slangasek, ack - thanks for the feedback
<jamespage> I'd not spotted the pyo
<rbasak> GunnarHj: sorry. I'll try and sort it out tomorrow as a priority.
<GunnarHj> rbasak: Great. No urgency, really, just wondered.
#ubuntu-devel 2016-07-15
<pitti> Good morning
<tsimonq2> o/ pitti, how are you?
<pitti> quite fine, thanks! how about you?
<tsimonq2> great :)
<pitti> stgraber: is there some way to pass extra parameters to pid 1 with lxd? (just for testing locally -- something utterly hackish is totally okay)
<pitti> stgraber: alternatively, passing env variables (SYTEMD_LOG_TARGET and friends) would work as well
<sarnold> pitti: environment.* may work https://github.com/lxc/lxd/blob/master/doc/configuration.md
<pitti> sarnold: oh, useful! thanks
<sarnold> I could have sworn i'd seen the "command line" there somewhere but perhaps I imagined it..
<pitti> you can set profile key/vals on the "launch" command line, I haven't seen config yet
<pitti> anyway, will try in a few mins
<LocutusOfBorg> can anybody with some mesa/GL/dpkg-update-alternatives knowledge help me a few seconds?
<Saviq> pitti, morning, for some reason these excuses have no results for unity8, any idea? https://requests.ci-train.ubuntu.com/static/britney/ticket-1525/landing-076-xenial/excuses.html
<pitti> Saviq: I'm afraid not; this needs a verbose britney log from robru to see what happens
<pitti> smoser, stgraber: I think I found something in bug 1602192
<ubottu> bug 1602192 in lxd (Ubuntu) "when starting many LXD containers, they start failing to boot with "Too many open files"" [Undecided,Confirmed] https://launchpad.net/bugs/1602192
<flexiondotorg> rbasak, If you're able can you look at the mate-hud sponsoring request please - https://bugs.launchpad.net/ubuntu/+bug/1602270
<ubottu> Launchpad bug 1602270 in Ubuntu "[needs-packaging] mate-hud" [Wishlist,New]
<pitti> apw: do we have someone in the kernel team who is reasonably familiar with inotify, for bug 1602192?
<ubottu> bug 1602192 in lxd (Ubuntu) "when starting many LXD containers, they start failing to boot with "Too many open files"" [Undecided,Confirmed] https://launchpad.net/bugs/1602192
<rbasak> flexiondotorg: I'll try to do it today. I'm just going to work on stuff for other people today - DMB, sponsoring, etc. But my queue is pretty big :-(
<flexiondotorg> rbasak, Understood.
<Odd_Bloke> I'm packaging up something for which upstream have provided systemd .service files, which I want to use.  Pretty much all of the documentation I've found assumes that I'll be writing my own service files in 'debian/*.service' but in this case I want to use 'init/systemd/named.service'; how should I go about doing that?
<cjwatson> Odd_Bloke: binfmt-support does exactly this if you want an example
<apw> pitti, i guess i'll have a look in the first instance
<cjwatson> you basically just need to install the files (or let upstream's makefiles do it) and then the usual debhelper stuff will pick things up from there
<apw> pitti, oh i will prolly poke seth
<Odd_Bloke> cjwatson: Excellent, thanks!
<rbasak> pitti: mysql-5.7 dep8 ppc64el force again please.
<michael-vb> Trevinho: are you around?  And would you have time for a question regarding global appmenus?
<alexbligh1> I have a bog standard install of trusty I can't upgrade due to http://pastebin.ubuntu.com/19489188/ - apparently missing a kernel image. I'd put this down to a 'mirror update in progress' issue except the last update was 27 June and I've waited and retried, but it does the same thing. Am I missing something?
<rbasak> lamont: you seem to have forked yourself in https://code.launchpad.net/~laney/+junk/packageset :-/
<rbasak> From rev 194
<rbasak> Sorry, Laney
<pitti> rbasak: I don't see it on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html, did someone already do it?
<pitti> ... and of course now I do!
<rbasak> :)
<pitti> TGIF -- done!
<rbasak> Thanks!
<rbasak> Laney: looks like they should merge OK. I'll just pull everything in.
<Laney> rbasak: I probably forgot to pull - ta
<rbasak> flexiondotorg: around?
<smoser> pitti, yikes.
<flexiondotorg> rbasak, o/
<lamont> rbasak: whew
<rbasak> lamont: sorry!
<rbasak> flexiondotorg: your fixes look good, thanks.
<lamont> np.  I was worred I'd forked there
<rbasak> flexiondotorg: did you look into the dpkg trigger about glib-compile-schemas?
<flexiondotorg> I didn't, I must have missed the request to look at that.
<lamont> :(){:&:};:  <-- gotta love that one
<rbasak> flexiondotorg: also some really minor comments: 1) I'd expect the version to be <upstream>-0ubuntu1 or something. What's your intention there? 2) Drop the "Closes" from changelog unless you want to refer to a Debian ITP or something; 3) debian/watch is missing a terminating \n, so catting it is annoying; 4) debain/ubuntu-mate/hud is empty - should this be there?
<rbasak> flexiondotorg: there are some lintian warnings. The two file-without-copyright-information should probably be fixed. A catch-all for GPL-2+ might be suitable here.
<flexiondotorg> rbasak, This will not be upload to Debian, they don't carry the required libraries. But I can change the version if required.
<rbasak> flexiondotorg: right, so drop the "Closes" - "LP: #XXXX" is sufficient.
<flexiondotorg> OK
<rbasak> flexiondotorg: and the version would be <upstream>-0ubuntu1, no?
<flexiondotorg> rbasak, debian/changelog corrected.
<flexiondotorg> rbasak, debian/watch corrected.
<flexiondotorg> rbasak, debian/ubuntu-mate-hud removed.
<flexiondotorg> rbasak, As for the lintian warning I have conflicting feedback about what to do about COPYING in the past.
<rbasak> flexiondotorg: I'm happy to leave it as-is in that case.
<flexiondotorg> The last DD I spoke with said just let lintian warn.
<rbasak> flexiondotorg: I'm not seeing mate-hud or mate-hud-service byte-compiling anywhere. I'm not sure if I'm missing something here. May I refer this to someone else?
<rbasak> barry maybe?
<flexiondotorg> OK
<rbasak> barry: for context, I'm reviewing https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/crazy-mate/+files/mate-hud_16.10.0-1~yakkety1.2.dsc for upload to Ubuntu for flexiondotorg
<flexiondotorg> I'm uploading a build to a PPA with the fixes we've just discussed
<rbasak> flexiondotorg is dropping a couple of Python programs into /usr/lib/mate-hud/. Should these be being byte-compiled, and/or is this done right?
<rbasak> Thanks
 * barry waves
<barry> rbasak, flexiondotorg generally this is done on install correctly, as long as you are using dh_python2 and/or dh_python3 (some older helpers do it right too, but you should be using those, e.g. python-support or even older python-central)
<barry> rbasak, flexiondotorg in fact, it *has* to be done on package install, because at package build-time there's no way to know which pythons are on the user's system
<rbasak> barry: is there any way to verify this? Where should I look on an installed system?
<flexiondotorg> I am using dh_python3 but these scripts are not in a python module.
<barry> rbasak: it will always be "near" the source py files.  the exact path depends on py2 or py3, but e.g. for py3, it will always create __pycache__/*.pyc files
<flexiondotorg> So they are not being automatically byte compiled.
<rbasak> I don't think it's working then :-(
<barry> flexiondotorg: scripts  generally won't get byte compiled because they are just invoking the interpreter via shebangs.  that's another reason why scripts should be super simple, either auto-generated by entry_points, or a very simple hand-crafted script that imports some other module and runs that
<flexiondotorg> I'm happy to add this, but I'm not going to have anytime to work on this for 2 weeks.
<rbasak> flexiondotorg: I don't want to block you. Let's go ahead without, but please file a bug and fix when you can.
<flexiondotorg> So is it possible the slightly fixed version that is building now can be accepted and I'll adjust the next upload to be a python module with byte compiling.
<barry> e.g. /usr/bin/lsb_release shebangs /usr/bin/python3.  lsb_release itself won't get byte compiled
<flexiondotorg> I'd really like to land this so the testers can start getting feedback preapred for alpha 2.
<flexiondotorg> barry, rbasak I know what is required to make the package a complete module with byte compiling :-)
<flexiondotorg> I'll fix this either just before or just after alpha 2.
<rbasak> I didn't, so thank barry :)
<rbasak> *thanks
<barry> np!
<flexiondotorg> rbasak, barry In the meantime here is the revised .dsc - https://launchpad.net/~ubuntu-mate-dev/+archive/ubuntu/ppa/+files/mate-hud_16.10.0-0ubuntu1~yakkety1.0.dsc
<flexiondotorg> Which includes several fixes discussed a little earlier.
<barry> flexiondotorg: i'm sorry, i don't have time right now to sponsor.  meetings^2 :)
<rbasak> Looking.
<flexiondotorg> rbasak, ty
<rbasak> flexiondotorg: for the version, I mean that I expect <upstream>-0ubuntu1 only, with no ~yakkety1.0 suffix. What's the reason for the suffix?
<flexiondotorg> I only added the usffix for the purposed of upload to a PPA.
<flexiondotorg> I realised it should be removed.
<rbasak> Oh, OK.
<rbasak> I can drop when uploading, no problem.
<flexiondotorg> Thanks.
<rbasak> I appreciate you fixing the debian/watch file, but you have an extra blank line at the end now. Never mind :)
<flexiondotorg> Nuts.
<rbasak> flexiondotorg: uploaded. After archive admin acceptance, please file yourself two bugs: 1) use dpkg trigger instead of calling from mate-hud.postinst; 2) move Python code to module and use byte compilation.
<flexiondotorg> rbasak, Thanks for your help.
<flexiondotorg> Task add to Trello for filling/fixing bugs.
<rbasak> flexiondotorg: np. Also, after it's accepted as a source package, we'll need to seed it and then regenerate the packageset.
<flexiondotorg> Thanks. Also have a task for that :-)
<Trevinho> michael-vb: hey, here I am
<michael-vb> Great!
<flexiondotorg> rbasak, Thanks for your time and patience. I also appreciate the education on best practice.
<michael-vb> I have a bit of a problem with VirtualBox, two screen (i.e. two window) machines and the global menu.
<michael-vb> When the second screen is active, the top-level menu entries are there in the global menu, but the menus themselves are empty.
<michael-vb> If we are doing something wrong I would love to know what, otherwise it would be good to know that we are not.
<michael-vb> And in the second case, if there is an easy work-around that would be good to know too.
<michael-vb> No idea if you are the right person to ask, or even if you know who is...
<brendand> pitti, would there be any issue with running ntp on a vm created by adt-virt-qemu? i'm recalling that clock-skew issue you showed me the patch for a while back and wondering if that might be related?
<michael-vb> Trevinho: any ideas?
<Trevinho> michael-vb: you mean there are no menu entries in there?
<michael-vb> Right, just a long thin downward-stretching bar.
<michael-vb> If I switch to a Firefox window now and click on a menu I see a bar like that for a moment too before it is populated.
<Trevinho> Mh, not something that is handled by unity itself.... Is something apps do, via indicator-appmenu and - depending on the toolkit - via various libs
<Trevinho> is that for any kind of app?
<michael-vb> This is specifically for VirtualBox, which depends indirectly on libdbusmenu-qt5 on Ubuntu.
<michael-vb> It was like that with the previous Qt4 version too.
<michael-vb> Nick Dedekind who seems to be the person who knows most about libdbusmenu-qt suggested I ask you.
<mitya57> michael-vb, I think it's a bug in appmenu-qt5 rather than libdbusmenu-qt
<mitya57> Bad news is that appmenu-qt5 is no longer developed and changes to get it fixed are very low.
<michael-vb> That was Nick's thought too I believe.
<mitya57> Good news is that Qt â¥ 5.7 has its own D-Bus menu implementation (written by me :)) which might not have this bug.
<michael-vb> Getting it fixed would be wonderful of course, but just establishing that it is not our bug so that we can send people elsewhere when they report it to use would be good.
<michael-vb> to us
<mitya57> If you or someone could try with Qt 5.7 and without appmenu-qt5 installed, it would be nice.
<michael-vb> Do you know if there is anyone with the knowledge of appmenu-qt5 to at least give me clues to debug this?
<michael-vb> mitya57: or Trevinho: ^^^
<mitya57> michael-vb, I'm afraid I can't help you with thisâ¦
<mitya57> Even though I was contributing to appmenu-qt5, its code is a mess and has too many hacks
<mitya57> Any of them can be buggy
<pitti> brendand: no, ntp ought to work as expected in a VM; it's not really needed unless you have particular requirements (as timesyncd is running by default), but timesyncd will not start if ntp is installed
<michael-vb> mitya57: thanks then.
<michael-vb> Trevinho: I will take no answer as "don't know either".  Thanks.
<brendand> pitti, that's good to know, thanks
<dobey> cjwatson, mvo: hi. so i tried setting TMPDIR to a different path, but that doesn't seem to keep the memory usage down. even pointing that at persistent storage, i only see a socket file getting created, and then later destroyed when click is done, but memory usage seems to grow incredibly while dpkg/dpkg-deb is being run, and memory usage still seems to grow to almost the size of the package itself
<cjwatson> entschuldigung, ich weiss nicht
<Trevinho> michael-vb: but the problem happens in the host or in the guest? Since having it in the quest would be weird
<Trevinho> guest*
<michael-vb> On the host.
<mitya57> michael-vb, can you show me the log from dbus-monitor when this bug appears, please?
<michael-vb> Any instructions or just improvise?
<mitya57> dbus-monitor 2>log.txt, reproduce the bug, kill dbus-monitor
<michael-vb> Where can I send the file?
<mitya57> Send it to mitya57@u.c.
<mvo> dobey: I just checked the source and it is using mkstemp() for the temp file.
<mvo> dobey: it should honor TMDIR :/
<michael-vb> mitya57: sent.
<mitya57> got it
 * mitya57 looks
<dobey> mvo: it does honor TMPDIR, it's just not extracting anything to it
<dobey> afaict, anyway
<mitya57> michael-vb, not really useful, but at least it looks like virtualbox is returning an empty array in response to GetLayout call
<mitya57> michael-vb, can you check if the same happens with other Qt 5 apps, i.e. Qt Assistant?
<michael-vb> Does that have two windows with independant menus?
<michael-vb> independent
<michael-vb> English used to be my first language...
<mitya57> Hm, no, it doesn't
<michael-vb> I suppose historically it will always be my first...
<michael-vb> mitya57: even if you can't tell me any more you have got me further.  I saw "GetLayout" in the libdbusmenu-qt source.
<mvo> dobey: uh, you guys are using version 0.13, is that correct (15.04)? because that is actually hardcoding /tmp/debsig-verify.XXXXXX
<mitya57> michael-vb, so does virtualbox have two windows with different menus?
<michael-vb> Actually they should be identical, but yes they are two different objects.
<dobey> mvo: i guess, i didn't notice my /tmp size increasing though.
<michael-vb> And yes, I see something worth trying there...
<dobey> mvo: 0.13 is what i have installed. should we backport something else to the phone overlay?
<michael-vb> If our Qt person thinks it is doable.
<dobey> mvo: should it be 0.14 or 0.15?
<mvo> dobey: worth testing with 0.14, let me double check what changed in 0.15
<mvo> dobey: 0.15 is probably a bit of a hassle to backport as it needs a relatievely new dpkg
<dobey> ok
<dobey> 0.14 doesn't need the new dpkg from xenial?
<mitya57> michael-vb, my last try to figure out what's happening: are any warnings printed into stderr?
<mitya57> appmenu-qt5 should print them if it fails to i.e. register window with the registrar
<michael-vb> During the whole application lifetime you mean or when the error occurs?
<mitya57> At any time
<mitya57> Or maybe when the second window is created
<michael-vb> Just a moment...
<michael-vb> Each of these is repeated many times:
<michael-vb> Qt WARNING: void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
<michael-vb> Qt WARNING: uint DBusMenuExporterDBus::GetLayout(int, int, const QStringList&, DBusMenuLayoutItem&): Condition failed: menu
<michael-vb> Qt WARNING: void DBusMenuExporterPrivate::fillLayoutItem(DBusMenuLayoutItem*, QMenu*, int, int, const QStringList&): No id for action
<michael-vb> (Another series.)
<mitya57> Hmm, this is from dbusmenu, not from appmenu-qt5
<mitya57> The first warning means that DBusMenuExporterPrivate::addAction was never called
<mitya57> michael-vb, I would suggest you to check two things:
<bdmurray> barry: Could you have a look at bug 1603436?
<ubottu> bug 1603436 in python2.7 (Ubuntu) "Regression in python2.7 SRU breaks python-cassandra" [High,Confirmed] https://launchpad.net/bugs/1603436
<bdmurray> barry: I've recreated the issue.
<mitya57> michael-vb, 1) Break in DBusMenuConstructor and check if the menu passed is really *your* menu (and not an empty one)
<barry> bdmurray: i don't have much time right now to review it, but i will keep the tab open ;)
<mitya57> michael-vb, 2) If it's yours, break in DBusMenuExporter::doUpdateActions and check if all actions are processed
<bdmurray> barry: I'm asking you as doko is out for a week or so.
<michael-vb> Not empty as in not NULL, or is there some subtle way of telling?
<barry> bdmurray: i can look in upstream changelog and source, but it will have to be later (today, hopefully)
<michael-vb> Definitely not NULL, I am now in the second call.
<mitya57> michael-vb, not empty in sense that menu->actions() is a non-empty list
<mitya57> If it's something else, then probably window->findChild<QMenuBar *> from appmenu-qt5 returns something else
<michael-vb> (gdb) p menu->actions()
<michael-vb> $8 = {<QListSpecialMethods<QAction*>> = {<No data fields>}, {p = {
<michael-vb>       static shared_null = {ref = {atomic = {_q_value = -1}}, alloc = 0,
<michael-vb>         begin = 0, end = 0, array = {0x0}}, d = 0x187d520}, d = 0x187d520}}
<mitya57> What about menu->actions().size()?
<mitya57> Oh, it's inline, gdb won't tell it
<michael-vb> (gdb) p menu->actions().size()
<michael-vb> $9 = 6
<mitya57> Good :)
<mitya57> But is it the first call to DBusMenuExporter or the broken one?
<michael-vb> The second.  But I can restart and check both.
<michael-vb> DBusMenu::DBusMenu
<mitya57> And the number of submenus in the second window is 6?
<michael-vb> Sounds about right.
<michael-vb> The window is not visible just now, I would need to find a screen shot...
<mitya57> you can check with UBUNTU_MENUPROXY=0
<mitya57> this disables the global menu
<mitya57> though, you say that top-level submenus show correctly in the Unity panel, right?
<mitya57> So the issue happens only when recursing?
<michael-vb> Due to another bug the menus are visible both in the global menu and embedded in the windows.  The embedded ones are correct.
<michael-vb> libdbusmenu-qt5 or one of its dependencies can't handle setVisibility().
<mitya57> Qt should set visibility to false if a platform menu is available
<michael-vb> I went over that with other people, the answer was "hopefully Qt 5.7 will fix this".
<mitya57> 5.7 is released so you can already test ;)
<michael-vb> We still have to work out the licence situation, and since we do fancy things upgrading to a new Qt version is non-trivial.
<michael-vb> It is scheduled for some time.
<michael-vb> Will float the idea past our Qt person actually.
<michael-vb> Said Qt person would also like to know if there is a way to tell that the Unity global menu is in use.
<mitya57> Qt *should* ignore setVisible(true) calls if there are any, but according to the code it only does so on macOS.
<mitya57> Unfortunately I have to go now. If it still happens with 5.7, please file a bug on bugreports.qt.io and it'll make its way to me or Shawn Rutledge.
<michael-vb> I was just typing the same thing - I also have an appointment away from work and the computer.
<sladen> michael-vb: can you file a minimal bug report in Launchpad so we have somewhere to track/point at this IRC log from
<michael-vb> Will do that.  Thanks all.  Will also stay logged in for a while.
<sladen> michael-vb: (PS. thank you to tying off the previous Launchpad bug with the summary + link to upstream committed fix)
<michael-vb> Oh right, sorry for tying you up with that one.
<michael-vb> Will still update it if there are more updates though for the interest of anyone following.
<nacc> rbasak: should mysql-server upgrade from 14.04 -> 16.04? in a simple lxd container (only had bacula-director-mysql + deps installed), it just failed :/
<rbasak> :-(
<rbasak> What was the error?
<rbasak> I have an SRU I'm trying to land that fixes a bunch of upgrade issues, but I don't think they should fail in the default case.
<nacc> package mysql-server-5.7 5.7.12-0ubuntu1.1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
<nacc> is the reason it said it failed
<nacc> but then i "I"-d it and it eventually finished?
<nacc> looking through the log
<nacc> "Column count of performance_schema.events_waits_current is wrong. Expected 19, found 16. Created with MySQL 50549, now running 50712. Please use mysql_upgrade to fix this error."
<nacc> ?
<rbasak> That's a known race condition. Bug 1577712, and the fix is in my SRU pending upload. Sorry, I was mistaken. that's one case that does fail in the default case.
<ubottu> bug 1577712 in mysql-5.7 (Ubuntu Xenial) "mysql_upgrade is called twice concurrently on upgrade from 14.04" [High,In progress] https://launchpad.net/bugs/1577712
<nacc> rbasak: http://paste.ubuntu.com/19507773/ is the whole thing
<nacc> ok
<nacc> yeah, it looks like a race :)
<robru> pitti: sil2100: guys, for the record, you shouldn't have to wait for me when you want verbose britney logs: http://bazaar.launchpad.net/~cupstream2distro-maintainers/bileto/trunk/revision/584#britney/fetch-indexes
<robru> pitti: don't go anywhere, I'll need you to look at a verbose britney log in 30 minutes or so
<robru> pitti: https://requests.ci-train.ubuntu.com/static/britney/log_20160715_161001.txt this mean anything to you? It's claiming NBS which is absurd, maybe the index is corrupt?
<nacc> elbrus: around?
<elbrus> nacc: yes
<nacc> elbrus: really appreciated your mysql 5.7 help earlier; hitting another bacula issue with that, as while the scripts that manipulate the databases are now correct, the run-time usage by bacula itself fails with: "ERR=Incorrect datetime value: '0000-00-00 00:00:00' for column 'StartTime' at row 1"
<nacc> elbrus: i'll google around and read themanuals, but if you had any idea of how that is supposed to be updated to handle mysql5.7, i'd appreciate any insight
<elbrus> nacc: I think I tried to tell you that last time as well
<elbrus> in cacti, I change the sql_mode PER SESSION
<nacc> ah alwyas?
<elbrus> please have a renewed look at the patch I already pointed out to you
<nacc> ok, so i'll need to figure out where/if bacula does that in their c mysql wrapper
<elbrus> yes
<elbrus> and yes
 * elbrus did that for cacti
<nacc> elbrus: ok, sorry for my misunderstanding earlier, appreciate the pointer!
<elbrus> nacc: I am not surprised you missed that earlier
<elbrus> typically you only appreciate this kind of advice after you struggled :)
<nacc> heh
<coreycb> bdmurray, I just uploaded a new ceilometer version to yakkety so the sru for bug 1601854 should be ready to go
<ubottu> bug 1601854 in ceilometer (Ubuntu) "[SRU] mitaka point releases for trove, nova, and ceilometer" [Undecided,Triaged] https://launchpad.net/bugs/1601854
<juliank> I think there's a regression in the gcc 5.3->5.4 xenial update: apt on xenial FTBFS in the PPA, with the compiler segfaulting :(
<juliank> https://launchpad.net/~deity/+archive/ubuntu/apt-1.2/+build/10472777
<juliank> Meh, now I reported a gcc bug with an attached .gz log file, and now launchpad produces nonsense
<juliank> and now the retry worked. life sucks.
<sarnold> wgrant: ^^^ juliank reported compiler ICEs on a ppc64el builder that worked on a subsequent retry
<juliank> on bos01-ppc64el-021
<juliank> full log of failed build is in https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1603588
<ubottu> Launchpad bug 1603588 in gcc-5 (Ubuntu) "gcc 5.4 on ppc64el: segmentation fault compiling apt" [Undecided,New]
<slangasek> oh, on ppc64el; phew
<slangasek> ;)
<juliank> "Weird" architectures and their bugs...
#ubuntu-devel 2016-07-16
<cjwatson> juliank: That's not a GCC bug; the ppc64el builders have known occasional guest memory corruption.
<cjwatson> It's just occasional enough that we can live with it.
<infinity> cjwatson: I have high hopes that when they're xenial-on-xenial, that'll go away.
<infinity> (but I'm not holding my breath)
<cjwatson> Nor am I.  What's the host right now, wily?
<cjwatson> The guests are xenial now.
<infinity> trusty + wily + cloud archive qemu, I think.
<infinity> Something like that.
<cjwatson> Ah yes, that assembly.
<infinity> Maybe trusty + vivid + cloud.
<cjwatson> I think it's a slightly-patched backport of the cloud qemu.
<infinity> cjwatson: The bit that irks me is that it doesn't happen on my ancient Frobisher-based builders.
<infinity> cjwatson: So either it's a qemu/kernel regression, or some patch in that build never made it upstream.
<infinity> juliank: Either way, it's so hard to reproduce that debugging it seems like a fantasy.
<infinity> Err.
<infinity> cjwatson: ^
<infinity> (Or, I suppose it could be POWER8-specific, but that seems far-fetched)
<cjwatson> Yup.
<cjwatson> I've never bothered to collect actual figures, but IIRC it's something like one build in a hundren.
<cjwatson> *hundred
<cjwatson> Could be load-dependent for all I know.
<masterchef> hey gang!  I am interested in getting started in Ubuntu packaging and wanted to know if there were any good resources to consult
<tsimonq2> masterchef: http://packaging.ubuntu.com/html/
<tsimonq2> it would also be worth looking at the archive processes
<tsimonq2> so like SRUs and Proposed Migration
<tsimonq2> if you know the archive, you know where you can solve problems
<stgraber> pitti: "lxc config set container environment.KEY value" will cause it to be set in init's environment
<stgraber> pitti: for arguments you could do "lxc config set container raw.lxc 'lxc.init_cmd=/sbin/init --debug'"
#ubuntu-devel 2016-07-17
<showaz> "ModSecurity not secure": http://insights.ubuntu.com/2016/07/15/notice-of-security-breach-on-ubuntu-forums/
<showaz> Protection from SQL Injection Attacks https://mariadb.com/products/mariadb-maxscale/mariadb-maxscale-security
<vooze> anyone good with gpg for uploading to ppas? I have uploaded with dput but nothing happens on lauchpad. I suspect it might have something to do with my gpg-keys.. The thing is: if I use gpg --list-secret-keys they are indentical to gpg -
<vooze> gpg --list-public-keys *
<LocutusOfBorg> vooze, you need to upload the gpg public key on your ppa
 * LocutusOfBorg leaves
<LocutusOfBorg> s/ppa/launchpad account
<vooze> LocutusOfBorg, I have done that. https://launchpad.net/~joakimkoed
<LocutusOfBorg> please try debsign -k1FEB1CAF sourcepackage_version_source.changes
<LocutusOfBorg> after you generated that file with dpkg-buildpackage -S -sa -d
<LocutusOfBorg> to be honest, "-S" means sign
<LocutusOfBorg> but maybe you are signing it with a different key, so re-running debsign might fix the issue
<LocutusOfBorg> I have in my ~/.devscripts the following DEBSIGN_KEYID="myfullkeyid"
<infinity> LocutusOfBorg: -S means source, not sign.
<infinity> That said, dpkg-buildpackage will sign by default without -uc
<vooze> I will try that :) will report after
<vooze> What I did before was:
<vooze> 1) debuild -S -sa -k1FEB1CAF
<vooze> 2) dput ppa:joakimkoed/infinality something.sources.changes
<vooze> Was that wrong?
<vooze> Still nothing :/ strange
<andrewsh> hi everyone
<andrewsh> is there any way to debug ubuntu-software/gnome-software?
<andrewsh> it just hangs here and does nothing
<andrewsh> and it's mostly a freshly installed system
<vooze> andrewsh, did you apt-get update & upgrade?
<andrewsh> vooze: well, I have the latest version of the packages installed
<andrewsh> the only way to proceed I see it to remove it completely and install software-center
<andrewsh> which actually works
<vooze> andrewsh, start it from terminal then, and see if some errors comes up
<andrewsh> vooze: it wouldn't show anything; if I run it with --verbose, it would show initialises plugins, adds keywords and so on,
<andrewsh> the last message is As-DEBUG: run GsPlugin::apt(gs_plugin_refine)
<andrewsh> and nothing follows
<andrewsh> strace showed it hangs somewhere in some futex, but that's not really useful, I know
<vooze> andrewsh, not sure then :/ I personally have removed it and are just using gdebi for .debs and terminal for the rest
<andrewsh> vooze: well, this system is meant to be used by a non-technical user
<vooze> andrewsh, ah I see. Well, I know there was alot of problems with it in the beginning but they all should be solved now. Anyway, maybe try again in like a week when 16.04.1 comes out?
<vooze> 21th I think
<LocutusOfBorg> infinity, you right :)
#ubuntu-devel 2017-07-10
<mwhudson>  python3-alembic : Depends: python3-sqlalchemy (< 1.1) but 1.1.9+ds1-0ubuntu2 is to be installed
<mwhudson> rrrrrrrrrrrrrrrrrrage
<mwhudson> oh openstack goo, i guess that means i can offload the problem
<tsimonq2> clivejo: Still need help with that?
<tsimonq2> Could someone please nominate bug 1703307 for Zesty and Artful?
<ubottu> bug 1703307 in lxterminal (Ubuntu) "Unable to rename tabs" [Undecided,New] https://launchpad.net/bugs/1703307
<ginggs> tsimonq2: there you go
<tsimonq2> ginggs: Thank you :)
<tsimonq2> Could someone also please nominate bug 1693893 for Trusty?
<ubottu> bug 1693893 in vlc (Ubuntu Artful) "Fix out-of-bounds read, potential heap buffer overflow, and other CVEs" [Undecided,In progress] https://launchpad.net/bugs/1693893
<ginggs> tsimonq2: done
<tsimonq2> ginggs: Thanks again :)
<sil2100> xnox: hey! Did you have time to set up that new calendar for patch piloting?
<tsimonq2> sil2100: Wait... patch pilot? <3
<tsimonq2> I found that to be super useful.
<xnox> sil2100, nope. i guess i should add a card to the backlog about it.
<bdrung_work> Trevinho, can we have the fix for #1671432 in zesty?
<Trevinho> bdrung_work: I had already the branches ready... https://bileto.ubuntu.com/#/ticket/2718
<Trevinho> needs to rebuild and prepare the SRU templates in bugs
<Trevinho> bdrung_work: if you can help in this last part it would be appreciated
<Trevinho> bdrung_work: also thesting that ppa would help
<bdrung_work> Trevinho, i am happy to test the SRU
<Trevinho> bdrung_work: thanks
<bdrung_work> Trevinho, i am using this PPA since some weeks. the menu works fine, but i got a new issue. when selecting text/etc with the mouse, the pressed mouse click is released (without me lifting my finger)
<Trevinho> bdrung_work: do you have a screencast of the issue? I can't reproduce it here...mhmh
<bdrung_work> just open a terminal and try to mark some lines
<Trevinho> bdrung_work: mh, I don't think this is related...
<Trevinho> there's none in the code for taht
<bdrung_work> hm, how can i exclude that this is a hardware fault?
<Trevinho> bdrung_work: try to use xev
<Trevinho> bdrung_work: like xev -event mouse
<Trevinho> then check the terminal to see what happens, pretending you're selecting something
<bdrung_work> Trevinho, i did: http://paste.debian.net/975714/
<bdrung_work> i clicked once, moved the mouse a lot and the released the button
<bdrung_work> but you can see two events in this log snipped
<Trevinho> bdrung_work: i see... I don't think this has much to do with compiz, did  you try to run metacity? or somethnig else?
<bdrung_work> no
<bdrung_work> haven't tried to run metacity instead
<LocutusOfBorg> whats up with ppc64el builders?
<cjwatson> LocutusOfBorg: they probably got eaten by the recent outage on our US link
<cjwatson> checking to see if they'll come back up now
<LocutusOfBorg> oh thanks
<LocutusOfBorg> this answers why my haskell arm* builds have failed and have been retried
<cjwatson> yeah, same datacentre
<cjwatson> bringing them all back up now
<LocutusOfBorg> thanks^2
<abeato> sil2100, I'm seeing this error for ubuntu-image in zesty: http://paste.ubuntu.com/25061684/ , any idea on what might be happening?
<sil2100> abeato: could you run that in an english locale? But I guess it says that some option in mkfs is invalid, right?
<abeato> sil2100, ups, had not noticed that :)
<abeato> sil2100, yes, no valid option for the file system, that is what it says
<abeato> sil2100, happens with the snap and with the deb
<sil2100> oh?
<sil2100> With the snap as well?
<sil2100> hmmm
<abeato> yes... the key must be this is zesty
<sil2100> The snap should have the correct deps installed
<sil2100> abeato: could you fill in a bug with all the details?
<sil2100> I'll look into that a bit later
<abeato> sil2100, sure
<abeato> sil2100, it is a classic snap, so maybe the dependendy is no there
<sil2100> abeato: this one should be installed and used from the snap, since it's from the e2fsprogs dependency
<abeato> hm, ok
<abeato> sil2100, it was already reported: https://bugs.launchpad.net/ubuntu-image/+bug/1644131
<ubottu> Launchpad bug 1644131 in Ubuntu Image "ubuntu-image fails with: mkfs.ext4 - Invalid filesystem option set: has_journal,extent,huge_file,flex_bg,metadata_csum,64bit,dir_nlink,extra_isize" [High,Fix released]
<sil2100> oh, wow, old bug
<abeato> hmm, but still happening
<sil2100> I'll look into that tomorrow, possibly the snap is built on a xenial system (on LP)
<sil2100> Anyway, let me add that to my TODO for tomorrow
<sil2100> Still, it works fine for me on xenial
<abeato> sil2100, awesome, thanks
<sil2100> Strange
<abeato> yeah, it must be zesty specific
<mwhudson> i never thought subscribing to artful-changes would get me so much email about haskell
<NickTux> Hello. Any help on this? https://launchpadlibrarian.net/327891117/buildlog_ubuntu-xenial-amd64.linux_4.9.0-360.201707092056_BUILDING.txt.gz
<NickTux> Not the same, but similar to this I guess: https://lkml.org/lkml/2016/8/23/577
<NickTux> Oh ! I'm searching from yesterday and I just found it. It's upstream: https://lkml.org/lkml/2017/7/5/537 . Sorry for any inconvenience.
#ubuntu-devel 2017-07-11
<tsimonq2> Could a MOTU please take a look at bug 1703307 and upload the package to zesty-proposed to start the SRU process?
<ubottu> bug 1703307 in lxterminal (Ubuntu Zesty) "[SRU] Unable to rename tabs" [Undecided,In progress] https://launchpad.net/bugs/1703307
<tsimonq2> Could someone also nominate bug 1690416 for Xenial and Trusty please?
<ubottu> bug 1690416 in lxterminal (Ubuntu Artful) "[CVE] socket can be blocked by another user" [Undecided,Fix released] https://launchpad.net/bugs/1690416
<infinity> juliank: Can you gimme a poke when you're around?
<infinity> juliank: Also, is it an intentional change that repositories without Release files are now considered invalid?  That's a pretty major behaviour change.
<juliank> infinity: As the news said, apt-get now also requires explictly setting allow-insecure-repositories
<juliank> Then they work just fine
<juliank> (with warnings)
<infinity> juliank: Ahh.  Yeah, looks like [trusted=yes] works (I think suggesting people set the apt.conf option is irresponsible, as that allows ALL sources to be insecure, not just the one I know I trust)
<juliank> All other apt frontends already worked that way for some time, it's just the switch now being toggled around for apt-get to
<juliank> s/to/too/
<infinity> juliank: To be fair, applying that policy to file:/ and copy:/ URIs (which is where I just had to add a trusted=yes to fix d-i) seems a bit busted.
<infinity> juliank: I mean, sure, someone could hack my local filesystem and all, but I feel like I have bigger problems if I can't trust a local repo.
<juliank> Well, maybe you use some partial mirroring tool, or it's on an NFS share, or whatever
<infinity> Yeah, I suppose.
<juliank> infinity: (re poke) Is there something else you wanted to discuss, or just that? I'm a bit slow right now, as I basically just woke up (brain is about to get carbs any minute now) :)
 * juliank woke up figuring out if he actually wanted to get up or not, and then saw the messages and decided to actually get up.
<infinity> juliank: That was it.  Just being grumpy because you made me do work. ;)
<juliank> Ah, OK; the 'also' made me think it might be two separate things :)
<juliank> infinity: You are not the first one, we also broke siduction's ISO building, or whatever
<LocutusOfBorg> hello Adri2000 seems that _rene_ wants to team upload libfilezilla (see #debian-release channel)
<Adri2000> LocutusOfBorg: thanks for the notice, that's ok if he has an upload ready, I don't have much time to do it myself now :/
<LocutusOfBorg> I will do it, and upgrade to the latest release
<Adri2000> thanks
<ricotz> hello, are there plans to pick up boost 1.64 for artful?
<LocutusOfBorg> ricotz, maybe you need to talk with xnox :)
<xnox> ricotz, is there a need for 1.64?
<xnox> i'd rather not go ahead of debian.
<xnox> 62 is currently default, with 63 available
<ricotz> xnox, not yet, I guess, currently libreoffice internally defaults to 1.63, but with 1.64 already available seems better to push for that
<ricotz> so avoiding to do two transitions
<ricotz> of course debian should update to 1.64 too
<ricotz> xnox, I guess you are the right person to ask for a MIR of libboost-locale-dev
<xnox> ricotz, it doesn't need an mir.
<xnox> ricotz, you should simply poke archive admin to promote that binary if something needs it. E.g. ask infinity.
<ricotz> ah, than just an component switch of those binaries
<xnox> yes, boost itself is in main.
<xnox> unfortunately.
<ricotz> I see, libreoffice 5.4.0 will require it
<xnox> so when that is uploaded, it will be highlighted in components missmatches, and then we promote things.
<ricotz> I see
<xnox> boost binaries move between main-universe a lot, depending on what we end up shipping in the distro.
<xnox> ricotz, also if libboost-locale-dev is headers only, it needs not any promotion. can't remember if locale-dev is or isn't header/template only.
<xnox> however things should be declaring built-using, but whatever.
<ricotz> it has a library too
<xnox> ack, so it will be a normal promotion of that library package to main.
<xnox> debian might go with with 1.65 transition and just skip 1.64 to be honest.
<seb128> cyphermox_, xnox, slangasek, hey, any news about the nplan/n-m issue?
<ricotz> xnox, ok, I guess this mean artful will stay with 1.62
<bdrung_work> Trevinho, regarding the mouse click event: i am currently testing the system with a different mouse. no issues so far.
<xnox> Laney, is transition tracker ok? e.g. from http://people.canonical.com/~ubuntu-archive/transitions/html/html/ocaml.html ocaml-melt and ocamlviz are not installable on amd64, but they seem like they are to me.
<xnox> or maybe i am missing something.
<LocutusOfBorg> xnox, they are both green here
<LocutusOfBorg> cache?
<xnox> LocutusOfBorg, ah, that! thanks
<xnox> problem between the keyboard and chair
<xnox> symptoms to be fixed with coffee
<Laney> ._.
<LocutusOfBorg> xnox, I'm doing a photo shot of my current t-shirt
<LocutusOfBorg> http://imgur.com/e8GUJer
<LocutusOfBorg> xnox, ^^ :)
<Zta77> Hi. I'm having trouble building a package from source, perhaps someone could help, please?  I'm doing the build inside a docker container so my system isn't soiled with all sorts of weird dependencies. Here's a self-contained Dockerfile: https://pastebin.com/wutSLrWq And this is how to test it, ie. make it build (and fail): docker build -t aseprite .   Not that this builds fine when invoken the plain cmake/make commands (also specified in Dockerfile)
<Zta77> 2 minutes and I'll post the error message =) ..
<Zta77> https://pastebin.com/zatpVKhN
<cjwatson> Zta77: You should really regard the packaging as (at least mostly) source code, rather than something you generate with dh_make; dh_make is usually at best only useful as a guideline.
<cjwatson> Zta77: Anyway, I think the actual error is above what you cut off in that paste.
<Zta77> I'm rebuilding now; I'll paste a complete error code if possible.  Perhaps there's more info further up in the scroll buffer.
<Zta77> I basically want to git clone some source and build a .deb that I can install later.  I will start from scratch when I want to build an updated version (i.e. start a new docker container).
<Zta77> cjwatson: There's more here: https://pastebin.com/VBicjBHa
<cjwatson> Zta77: Looks like missing Build-Depends: pkg-config
<cjwatson> Possibly others
<Zta77> Thanks, I'll try adding them and rebuild.
<cjwatson> (Also slightly odd that you're installing sbuild in your container but not actually using it, so with what you have at the moment you'd also need to specify additional build-dependencies in the Dockerfile)
<cjwatson> Oh, and that error about -DCMAKE_BUILD_TYPE=None looks suspicious
<cjwatson> Hm, no, that's debhelper's default
<cjwatson> You might need to add -DCMAKE_BUILD_TYPE=Release or something like that
<cjwatson> Which would go in override_dh_auto_configure
<Zta77> (I think sbuild is a left over from another experiment where I was building locally on my own machine)
<Zta77> Right.  What was the first Build-Depends you mentioned? I lost my history..
<cjwatson> pkg-config
<cjwatson> That's not the actual fatal error in this case (the fatal error appears to be about CMAKE_BUILD_TYPE), but I expect you'll run into it later anyway
<Zta77> Isn't it weird that the build succeeds if run with plain cmake/make but fails when invoked though dpkg-buildpackage ?
<cjwatson> Zta77: Not particularly, because debhelper (used via debian/rules) supplies a bunch of cmake defaults
<cjwatson> Zta77: One of those is -DCMAKE_BUILD_TYPE=None, which apparently the embedded libarchive doesn't like
<cjwatson> Zta77: See /usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm
<cjwatson> Zta77: Like I say you can override that by adding parameters after "dh_auto_configure --"
<cjwatson> (I think -DCMAKE_BUILD_TYPE=RelWithDebInfo is actually a better override)
<cjwatson> See https://bugs.debian.org/701233 for the history here
<ubottu> Debian bug 701233 in debhelper "debhelper: Add -DCMAKE_BUILD_TYPE=RelWithDebInfo to standard set of cmake flags" [Important,Fixed]
<Zta77> Now I'm getting somewhere! It's building.
<Zta77> Using RelWithDebInfo
<Zta77> cjwatson: So the build actually completes .. and then it fails =) Any idea what could be going on here? https://pastebin.com/Ngs7FABP
<cjwatson> Zta77: Packages shouldn't install stuff into /usr/local
<cjwatson> Zta77: You should be using /usr as the prefix
<cjwatson> Zta77: If you reeeeeeeeeeally don't want to comply with that, you should (a) reconsider (b) if you still don't want to, override dh_usrlocal to do nothing
<Zta77> Oh, I was just about to ask if this could be related to my custom prefix
<Zta77> how do I override dh_usrlocal ?
<Zta77> I'd like to be able to install my package side-by-side with the official package.
<cjwatson> I don't really want to teach you the details because I think you are on a mistaken route
<cjwatson> But if you really want to you can read "man dh" (which gives general advice on how to override debhelper commands)
<cjwatson> There's a "Here is a way to prevent dh from running several commands that you don't want it to run" section
<cjwatson> It's worth learning how overrides work anyway: it's easy and regular
<Zta77> This whole project is a mistaken route.
<cjwatson> :)
<Zta77> But I'm learning docker, learning a but about .deb, learning how to populate a repository, and getting the latest build of aseprite. So it's not all bad.
<coreycb> apw: hello, if you have some cycles, could you review a few openstack SRU uploads for me?  In the queue I have libvirt for zesty/xenial, and python-cinderclient/python-openstackclient for xenial.
<apw> coreycb, are these two identicle in the zesty queue ?
<apw> coreycb, and the same question for xenial
<coreycb> apw: for libvirt there should be 2 uploads for zesty and 2 for xenial, of which the older ones can be rejected
<apw> coreycb, there is already a libvirt in zesty-proposed
<apw> are we replacing that ?
<cpaelzer> coreycb: is that the update to have both rules?
<coreycb> cpaelzer: yes
<cpaelzer> coreycb: did you change the changelog - since I prefeched that into my merge and want history to be correct
<coreycb> apw: checking
<coreycb> cpaelzer: here's the zesty upload - http://launchpadlibrarian.net/327345846/libvirt_2.5.0-3ubuntu5.2_2.5.0-3ubuntu5.3.diff.gz
<cpaelzer> ok thats the odl message - I'm good then
<coreycb> cpaelzer: you probably want to release 5.2 rather than having the 5.3 version replace it, right?
<coreycb> cpaelzer: in zesty-proposed
<cpaelzer> coreycb: yeah 5.2 is in proposed quite a while now
<cpaelzer> I'd prefer to not restart its amturing cycle
<coreycb> apw: it looks like 5.2 is verified, perhaps we can release that to updates and accept 5.3 into proposed?
<coreycb> cpaelzer: ^
<apw> coreycb, ok its not marked verified according to the reports, i think they may have used the wrong tag form
<cpaelzer> verification-zesty-done since 22. June
<cpaelzer> there was the global change by sil2100 - maybe affected by that in some way
<cpaelzer> apw: ^^
<apw> i think the form is verification-done-zesty ...
<sil2100> Yeah, it's verification-done-zesty as apw says ;)
<cpaelzer> well I added the wrong way before you added it :-)
<apw> cpaelzer, if you could flip that (too dangerous to overlap with you)
<apw> then we can indeed release this one
<coreycb> apw: cpaelzer: thanks
<cpaelzer> apw: I corrected the tag
<apw> cpaelzer, coreycb, ok that one released
<cpaelzer> thanks apw
<coreycb> apw: thanks
<apw> i'll come back to the new one once the world notices
<willcooke> mbiebl_, hi.  I copied  (more or less)  your patch for disabling bluetooth audio in gdm for Ubuntu, I wondering if it's likely to land in Debian soon, or did you decide that the a11y impact was too great?
<willcooke> rdiff in question: https://paste.debian.net/975780/
<seb128> cyphermox_, slangasek, xnox, hey again, sorry to nag but is annoying working on unblock that n-m update?
<cyphermox_> yes, annoying is working on unblocking that
<cyphermox_> fwiw, I told jbicha two weeks ago that it was a NM regression
<cyphermox_> I think I can work around it in nplan, working on that right now
<dmj_s76> Given the recent discovery of skylake/kabylake hyperthreading problems, could we get the latest intel-microcode backported to xenial?  That should fix the issue on a sizeable percentage of systems.
<nacc> dmj_s76: LP: #1700373
<ubottu> Launchpad bug 1700373 in intel-microcode (Ubuntu Yakkety) "intel-microcode is out of date, version 20170511 fixes errata on 6th and 7th generation platforms" [Undecided,Confirmed] https://launchpad.net/bugs/1700373
<dmj_s76> nacc: Thanks
<nacc> dmj_s76: yw
<bdrung_work> Trevinho, after one day use, i can say that the unwanted click events were caused by broken hardware
<juliank> Seems like seviper's smtp does not speak TLS? gmail shows annoying red crossed-out locks for ubuntu-devel mails :(
<Trevinho> bdrung_work: sad to hear for you, but also good for us :-D
#ubuntu-devel 2017-07-12
<cjwatson> slangasek: debconf 1.5.63 finally implements joeyh's compromise suggestion from Debian #501767, so hopefully we can sync that once it's available
<ubottu> Debian bug 501767 in debconf "[patch] hide cancel and close in the gnome frontend" [Normal,Open] http://bugs.debian.org/501767
<blahdeblah> cpaelzer: When you get in, could you spare a few minutes for a chat about lp:1593907 & lp:1577596 ?
<blahdeblah> cpaelzer: I'm in UTC+10, so the earlier in your day, the better for me; non-urgent, but would like to be confident of some near future changes I'm planning for the ntp juju charm.
<cpaelzer> hi blahdeblah, reading ...
<blahdeblah> thanks cpaelzer
<cpaelzer> blahdeblah: ok I'm context switched in - how can I help
<cpaelzer> blahdeblah: those bugs are in the SRU queue "just" need sponsoring for Trusty (as I can't up there) and SRU acceptance
<cpaelzer> blahdeblah: but since I'm through the discussion with infinity already I think they are good for sponsoring&acceptance to proposed as soon as the RU team gets to it
<blahdeblah> cpaelzer: So both bugs seem to be targeted at the same symptom, which is that installing ntpdate stops ntp from starting.  Yet the one is won't fix and the other is just waiting for SRU.
<cpaelzer> blahdeblah: the won't fix is "from another time"
<cpaelzer> thanks for the note, probably right to retriage that one
<blahdeblah> cpaelzer: So that fix should get included in the same/a similar SRU?
<slangasek> cjwatson: nice!
<blahdeblah> cpaelzer: I have a need in the ntp charm to do (on trusty & xenial) the one thing that ntpdate is still useful for, which is testing a remote NTP server without setting the local clock, and I'd like to be able to install ntpdate knowing that it won't break startup of ntpd.
<blahdeblah> cpaelzer: So that's a long intro to the actual question: can I have that confidence once these SRUs are complete, and is there anything I can do to add my +1 to them being needed?
<cpaelzer> blahdeblah: the SRU that is in queue should fix the other bug as well, as it was a side effect of the ntpdate ifup hook stop/starting the ntpd server
<cpaelzer> blahdeblah: I say should because I didn't test explicitly
<blahdeblah> cool
<cpaelzer> One should retest 1577596 once 1593907 is fixed
<blahdeblah> (obviously I won't release this charm change without testing that)
<blahdeblah> cpaelzer: And for the 2nd part of the question? :-)
<cpaelzer> blahdeblah: and for the help, once 1593907 goes into proposed help to verify it
<cpaelzer> blahdeblah: let me test a few bit here, probably ~30 minutes and I'll come back
<cpaelzer> blahdeblah: are you still there then?
<blahdeblah> Yep - another couple hours
<blahdeblah> cpaelzer: I'm not familiar with the processes around entry to -proposed; is it just a matter of someone getting the time to do it, or are there further approvals needed?
<cpaelzer> blahdeblah: yes right now it is down to time of the SRU team, all other steps are passed
<blahdeblah> OK - thanks
<cpaelzer> blahdeblah: ha I knew there was something around the logs
<cpaelzer> to bad I needed 7 minutes to re-find it
<cpaelzer> # ll /var/lock
<cpaelzer> lrwxrwxrwx 1 root root 9 Apr 25 09:51 /var/lock -> /run/lock/
<cpaelzer> so while ugly in the sense of not makeing sense :-)
<cpaelzer> the difference in the locks is not the problem
<blahdeblah> That's been there for quite a while, hasn't it?
<blahdeblah> I wondered why anyone cared about that
<cpaelzer>  /run/lock/ntpdate  vs /var/lock/ntpdate
<cpaelzer> blahdeblah: because it is a rare case that needs to race on startup and I think it needs a very slow or even a backgrounding ntp task to block it
<cpaelzer> while I can't prove that the disentanglement of service and the hook will fix it - it will surely close parts of that racing
<cpaelzer> blahdeblah: so I stay at "please retest once the other SRUed"
<cpaelzer> but I'll update the bug to make people aware
<blahdeblah> cool - thanks very much
<cpaelzer> I wonder thou, we can even dup it now (with a good comment) and undup it if needed still
<cpaelzer> but that way people get updates accordingly on the SRU
<blahdeblah> makes sense to me, but some people tend to get rather agitated in bugs about rather silly little things
<cpaelzer> if you care about something, you care about it - and it is hard to understand why others don't (that much) - that is the source of the agitation
<blahdeblah> Maybe just a comment saying: watch this other bug for SRU please?
<cpaelzer> I'm rather open and talkative in bugs
<cpaelzer> blahdeblah:  were you able to reproduce 1577596 or do you just know abotu it via LP?
<blahdeblah> cpaelzer: I don't know what the underlying cause is, but when my laptop was on xenial I definitely experienced the symptoms.
<cpaelzer> this issue had way more symptoms
<cpaelzer> what I like most was the HW switch for NTP on my old laptop
<blahdeblah> wat?
<cpaelzer> blahdeblah: stop ntp and disable the service - you'd think this stays off right?
<cpaelzer> blahdeblah: unplug the network cable, replug it, hook runs and ntp gets started unconditionally
<cpaelzer> I hate this so much ....
<cpaelzer> better one step at a time
<blahdeblah> nasty
<cpaelzer> we are lucky that it is wednesday
<cpaelzer> rbasak: if you could look at 1593907 (sponsor T, and check for SRU acceptance in T to Z) that would be great
<cpaelzer> rbasak: and if there are any questions let me know - I thought I handled all with infinity, but you might have new ones
<blahdeblah> Would it be worth submitting a patch to Debian to switch it from sysv to systemd?
<cpaelzer> blahdeblah: did you read the comments why we set won't fix ?
<blahdeblah> because of minimising diff with Debian, AIUI
<cpaelzer> kind of but not all of it
<cpaelzer> blahdeblah: I have like 7 open ntp bugs all of them idling without response
<blahdeblah> cpaelzer: with Debian?
<cpaelzer> blahdeblah: yes
<blahdeblah> :-\
<cpaelzer> and they would fix issue like these - ability to disable conf, avoid races, ...
<cpaelzer> merges got harder and harder as the Delta grew
<cpaelzer> and OTOH ntpdate - which unfortunately is most often the reason - is actually deprecated
<blahdeblah> yeah, but we also don't ship its replacement :-)
<cpaelzer> blahdeblah: for which use case - asking the time without updating it?
<cpaelzer> that is the case I understoo d you had
<blahdeblah> yeah, but ntpdate is supposed to be a generic SNTP client, which sntp is supposed to replace
<cpaelzer> and we ship sntp starting with artful if that helps
<blahdeblah> yeah - I've been watching that bug too
<blahdeblah> Doesn't really help with charms, which basically only target LTS
<cpaelzer> I feel tracked :-)
<cpaelzer> blahdeblah: I assume timedatectl doesn't give you what you need?
<blahdeblah> cpaelzer: TBH, I haven't looked.
 * blahdeblah makes a note to do that
<cpaelzer> that is the client ntp portion in the systemd age
<blahdeblah> so timedatectl is to systemd.timesyncd as ntpdate/sntp is to ntpd?
<cpaelzer> now matter how modern systemd is - it makes me feel mainframy again - one thing to do everything
 * blahdeblah has never felt remotely mainframy
<cpaelzer> blahdeblah: timedatectl is the control entry to systemd.timesyncd the analogism to ntpdate<->ntpd doesn't hold true
<blahdeblah> ah, right
<cpaelzer> but the most general use case - sync my time - can be done with it
<cpaelzer> and even the ntpd client side of - and keep it synce - it will do for you
<blahdeblah> I'll have a read of it, but keep in mind this is all in support of controlling ntpd config within the charm, so we don't really want systemd.timesyncd doing anything.
<cpaelzer> By default is disables itself once a real ntp is around
<cpaelzer> but for that timedatectl is the tool to check
<blahdeblah> yep
<cpaelzer> so read about it
<blahdeblah> will do
<juliank> doko: I'm confused by apt's gcc 7 failure. It's essentially doing std::floor(0.9 * 10), and the result seems to be 8 rather than 9
<LocutusOfBorg> slangasek, can I steal erlang?
<LocutusOfBorg> hello btw
<LocutusOfBorg> juliank, seems a big value of eight :)
<juliank> Smaller sample code: https://paste.debian.net/976058/
 * juliank extracted the tested function here, which only removes a __builtin_expect macro call
<juliank> I don't have an artful chroot, so I can't test there, but it works just fine in unstable
<LocutusOfBorg> I'm testing both artful and sid
<juliank> Hmm, is 0.9 representable in float?
 * juliank just noticed it's float, not double
<cpaelzer> precision should be enough for one digit I'd hope
<juliank> cpaelzer: Well, I think 0.9 is not accurately representable in binary floating point
<juliank> It's something like 0.89999997615814208984375
<cpaelzer> yep
<juliank> And then std::floor rounds that stuff to 0.8 now instead of 0.9 as it did before
<juliank> But maybe only on i386
<cpaelzer> actually it could even avoid the inaccuracy since by moving the mantisse+1 and just store a 9 inestead of .9
<cpaelzer> isn't float/double just non fraction numbers plus mantisse
<cpaelzer> so it could store it accruately
 * cpaelzer needs to check his memory on ieee spec on floats
<LocutusOfBorg> juliank, can''t repro on amd64
<juliank> No, the exponent is 2^something
<juliank> not 10^something
<juliank> So 0.9 is stored as 1.7999999523162842 * 2^-1
<juliank> I guess we could just make it add 0.1 to the result before flooring it
<juliank> But it's odd that this worked with gcc 6
<juliank> and that it works fine on amd64
<cpaelzer> juliank: the paste you linked gives me 9x# + . on artful gcc-7 and xenial gcc-5
<LocutusOfBorg> g++-7 asd.cpp && ./a.out
<LocutusOfBorg> [#########.]
<LocutusOfBorg> same here
<cpaelzer> juliank: do you get 8# ?
<cpaelzer> g++-7 test.cpp -o test; ./test
<cpaelzer> [#########.]
<juliank> cpaelzer: I don't, doko's gcc 7 test rebuild on i386 got it: https://launchpadlibrarian.net/327296659/buildlog_ubuntu-artful-i386.apt_1.5~beta1_BUILDING.txt.gz
<LocutusOfBorg> on sid i386 sid amd64, artful i386, artful amd64, and both gcc-6 and gcc-7
<cpaelzer> maybe some of the simplification of the test is too simple?
<juliank> Maybe
<juliank> Well, it's the same function, so if it does not happen here, it's the optimizer causing trouble
<juliank> The only thing I changed is remove an unlikely() in the if()
<juliank> and unlikely expands to __builtin_expect(...)
<LocutusOfBorg> juliank, maybe we should use O3 or similar?
<juliank> No, the test rebuild used -O2
<juliank> I'm going to do a full build of APT with gcc 7, let's see if that does something
<juliank> It looks weird
<Unit193> mdeslaur: Have you prepped the Irssi fixes?
<juliank> Tons of shit again, like this:
<juliank>  /home/jak/Projects/Debian/apt/apt-pkg/statechanges.cc:103:26: warning: missed loop optimization, the loop counter may overflow [-Wunsafe-loop-optimizations]                                            for (auto const &V: makeDpkgAvailable)
<juliank> I don't maintain any counter, gcc
<juliank> gcc is hardly usable anymore, if it spits out one or two warnings per file about overflowing loop counters.
<juliank> And that's getting worse with each gcc release
<juliank> DonKult than usually rewrites them *somehow*, usually with std::find and friends to just shut the compiler up, but that's not really sustainable, nor does it make the code any clearer
<juliank> I think we should just give up and pass -Wno-unsafe-loop-optimization
<juliank> Look at that tiny loop in that tiny function: http://paste.ubuntu.com/25073979/ - it gets a loop counter may overflow function
<juliank> There is *nothing* in there that could overflow
<Unit193> mdeslaur: Well, just in case you didn't: https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/8039406/+listing-archive-extra
<juliank> Yay, that example causes the issue even when minimalized
<juliank> This minimal example causes loop warnings with g++7, but not with g++6: http://paste.ubuntu.com/25073998/
<juliank> Compile with g++ -c -O2 -Wunsafe-loop-optimizations
<cpaelzer> when doing that on an older compile you need -std=gnu++11 btw to allow the loop style
<LocutusOfBorg> slangasek, I'm uploading it, it seems to make the whole erlang stuck
<LocutusOfBorg> please forgive me
<juliank> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81408
<ubottu> gcc.gnu.org bug 81408 in c++ "Lots of new -Wunsafe-loop-optimizations warnings with 7 compared to 6" [Normal,Unconfirmed]
<mwhudson> hmm new chromium is segfaulting for me
<mwhudson> oSoMoN: hi
<mwhudson> oh maybe that's fixed already
<oSoMoN> mwhudson, yes, thatâs fixed already (unless youâre on yakkety)
<oSoMoN> hopefully youâre not
<juliank> infinity: do the build chroots still work now that they run on apt's new https method (did you remove the apt-transport-https yet? It's not used anymore!)
<juliank> Hmm, I should follow up on the email
<juliank> Ah, I did
<mwhudson> oSoMoN: nah xenial
<rbasak> cpaelzer: I don't see anything in Z to reject - just one ubuntu1.2 in the queue. Is that expected?
<juliank> The next round of APT SRUs will get proper tracking bugs again, I'm about to finalize 1.4.7 any time. It goes stretch->zesty, so it needs debian-release approval and they are a bit picky about the changelog :)
<cpaelzer> rbasak: in regard to what are you asking about the reject?
<rbasak> cpaelzer: right - I've rejected the burned versions from X and Y but I see nothing for Z except the unburned one. Thought I'd double check with you that I've got the right versions of everything before I start reviewing.
<cpaelzer> rbasak: ntp_4.2.8p9+dfsg-2ubuntu1.2 is the new one that I hope you can accept
<cpaelzer> rbasak: there was a ntp_4.2.8p9+dfsg-2ubuntu1.1 that got superseded by the security upload
<cpaelzer> https://launchpad.net/ubuntu/+source/ntp/1:4.2.8p9+dfsg-2ubuntu1.1
<cpaelzer> ok, the old one is no more in the queue
<rbasak> I found it in the rejected queu
<cpaelzer> please don't ask me why rbasak - it was there just as the others
<rbasak> I guess someone else rejected it?
<rbasak> Or else I missed it.
<rbasak> Never mind, thanks.
<cpaelzer> yw, good to clear before looking at the actual SRU review
<cpaelzer> rbasak: please do realize that the trusty needs sponsoring on top of the SRU upload
<cpaelzer> since trusty's ntp was not yet server-dev permissions
<rbasak> cpaelzer: understood. I've done it already, wearing my DMB hat
<cpaelzer> thanks a lot
<rbasak> As it should be in ubuntu-server-dev.
<rbasak> (and thus shouldn't need sponsorship)
<cpaelzer> rbasak: ok, please ping me in case there is anything you need to know on this SRU
<rbasak> ack
<juliank> Hmm, does 30 hosts sound like a sensible upper limit for the usual number of hosts in sources.list.(d)? I'm thinking about the wait-online helper I want to write for APT, and the timing.
<juliank> My idea now that systemd is stupid, is to allow it to exponentially back off attempts.
<juliank> So, it would call connect() for a host, add it to the select() set, and then call select with a 500ms() timeout
<juliank> for the final host() it would call select with a (TIMEOUT - passedtime) as a timeout
<juliank> Where TIMEOUT is 15s, 30s, 1m, 2m, 4m, 8m, 16m
<juliank> This means that optimally, on a reasonably fast network we only do one connect() + select(), as the first host responds in 500ms
<juliank> on slower networks, it would eventually respond in a later select with more fds
<juliank> And with a 15s initial overall time out, that means we can wait 500ms 30 times, so we can pack 30 hosts into that time frame. If you have more, it takes longer until we retry connect() again with the first host
<juliank> I guess we'll loop for about 10 hours or so
<juliank> after that we fail and the service is restarted by the "12 hours later" run
<Zta77> cjwatson: I forgot to say thank you for the help yesterday: Thank you =). It helped me finally finish this little project of mine which was really nice.
<juliank> OK, maybe we wait for less, not sure how the timers get delayed
<cjwatson> Zta77: ah good!
<juliank> Hmm, I forgot about multiple IPs per host
<juliank> Hmm, that's too annoying, I might just wait 10s per host
<juliank> but not really sure
<juliank> I'd have to extract the getaddrinfo() stuff from the methods/connect.cc stuff
<juliank> Or copy it :D
<rbasak> cpaelzer: ntpdate isn't installed by default >=Xenial, right?
<rbasak> So for the broken cases you list, isn't "dpkg -P ntpdate" an option?
<cpaelzer> rbasak: back from lunch
<cpaelzer> rbasak: yes it can be removed
<cpaelzer> rbasak: it isn't an option for those who want to use it
<cpaelzer> like for example blahdeblah who talked with me this morning, he is using it to check external ntp servers
<cpaelzer> for that he needs to install it
<cpaelzer> at the same time he doesn#t want to affect ntpd
<rbasak> cpaelzer: you're modifying a conffile though, right? So he could remove the conffile himself, and packaging will maintain his choice?
<cpaelzer> rbasak: also there are other packages which depend or recommend ntpdate
<cpaelzer> rbasak: yes the script is in /etc and therby autp-conffile
<cpaelzer> rbasak: yet the issues are too nasty to let more people debug it to eventually find it there
<cpaelzer> rbasak: I'd say I know about 5 people that went to modify it on the related bugs
<cpaelzer> rbasak: but I'd expect at least 5 times that much (or way more) affected without ever realizing what their problem really is
<rbasak> But ntpdate shouldn't appear on a system by default I don't think.
<rbasak> Except for Trusty.
<rbasak> How is it that these affected users ended up with ntpdate installed in the first place?
<cpaelzer> given that those bugs have like 30+ affected users reported
<cpaelzer> I can't tell you why, I can only say it seems to be more than the most cornerful-cornercase
<rbasak> I appreciate that it's a trade-off between people affected and risking regression to people not affected. I'm just trying to decide where I sit on that balance.
<rbasak> I suspect an upgrade from Trusty to Xenial might leave ntpdate in place.
<cpaelzer> it will
<cpaelzer> that is where most might come from indeed
 * cpaelzer checking
<cpaelzer> one of the thre bugs explicitly states upgrading as the way to get there
<cpaelzer> the other two didn't go into details on why they installed it initially
<cpaelzer> rbasak: just came to my mind - the change is in ntpdate as well
<cpaelzer> rbasak: so if your concern - and I appreciate that you try to tihnk of issues - is to regress the majroity because they don't have ntpdate
<cpaelzer> that is not an issue
<cpaelzer> as the change is in ntpdate as well
<cpaelzer> so we don't know if many or few have ntpdate installed
<rbasak> the change is in ntpdate as well as where?
<cpaelzer> but those who have it installed are affected and get the fix
<cpaelzer> and those who have not will not feel anything
<cpaelzer> rbasak: yes the change is to the hook that is part of the ntpdate package
<cpaelzer> so we "affect" just the right subset of users
<rbasak> Right. So this bug affects only users with the ntpdate package installed, and the SRU cannot regress any user who does not have the ntpdate package installed.
<cpaelzer> yes
<cpaelzer> that was my point
<cpaelzer> sorry to get to that "argument" so late but it just crossed my mind now - didn't prepare for it :-)
<rbasak> What proportion of users have the ntpdate package installed and are relying (whether they realise it or not) on its functionality?
<rbasak> ...who aren't affected by this bug?
<cpaelzer> I have no idea, but with systemd timesync around probably not much - the "upgraders" are the interesting subset to consider
<rbasak> Right
<cpaelzer> but it is not that we would drop the syncing that ntpdate does, just the stop/start of the service around it
<rbasak> That's a good point.
<rbasak> If ntpdate bumps the time more than a few hours, doesn't that cause ntpd to exit (by default)?
<rbasak> The service restart works around that I think.
<cpaelzer> no it does not, but you are in good party with infinity with that theory
<cpaelzer> I think I explained in the bug a few comments above
 * rbasak reads again
<cpaelzer> the default config of ntp is to allow to time warp once on start - so if you warp via ntpdate before the service is up it can adjust and drift from there
<cpaelzer> vice versa if ntp is running the ntpdate will fail to set anything
<cpaelzer> both cases ok
<cpaelzer> actually much more ok than before if you had differing ntpdate/ntpd configurations - there without the SRU you warped one way with ntpdate and then then the other way with ntpd restarting
<rbasak> How about this sequence of events: system boots with dead RTC battery, ntpd starts; ppp0 goes up; ntpd stopped; ntpdate fixes the clock; ntpd starts and keeps the clock fixed.
<rbasak> Wouldn't the proposed SRU leave the clock broken in that case, if there's a gap before ppp0 is brought up?
<cpaelzer> could be - I'm not sure if the ntpd would realize it can now reach new places to sync from via the ppp0
<cpaelzer> we certainly fix more cases than might be affected - but I know SRU review is about the second half
<cpaelzer> need to test something
<rbasak> I think I'm holding a higher bar on this because a fix is available without the SRU.
<cpaelzer> please say workaround - fix is too good to call it that way
<rbasak> And it feels like the fix isn't even a workaround. Unless we consider there to be a bug "ntpdate is not removed on release upgrade".
<cpaelzer> there is a bug just like that
<cpaelzer> https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1649729
<ubottu> Launchpad bug 1593907 in ntp (Ubuntu Zesty) "duplicate for #1649729 ntpdate startup routine prevents ntp service from launching up on Ubuntu 16.04 server on system boot; manually starting ntp service works: [FIX in DESCRIPTION], just need to apply it and release a new version" [Undecided,In progress]
<rbasak> Perhaps it is a workaround, but in that case I don't think this SRU would fix the bug that we're working around, IFSWIM.
<cpaelzer> but he essentally complains about the issues caused by ntpdate/ntp not working well together
<cpaelzer> so it is s dup to the SRU actually
<sil2100> abeato: hey!
<rbasak> cpaelzer: I'm torn but I'll accept I think, if you're confident?
<sil2100> abeato: could you do snap remove ubuntu-image and then snap install it from the beta channel?
<sil2100> abeato: I fixed the issues with the snap, this time I expect no more problems
<sil2100> ogra___: ^
<ogra___> sil2100: will do later today
<abeato> sil2100, sure, will try
<cpaelzer> rbasak: I'm rather confident on this, but to be clear - I really appreciate you concerns and want to overcome them with facts more than by convincing
<cpaelzer> and I realized this is a higher bar sicne we wouldn't have any SRUs otherwise :-P
<cpaelzer> rbasak: I think we are good because of http://paste.ubuntu.com/25074802/
<cpaelzer> rbasak: that is a log of the following sequence: stop ntp, disable network, start ntp (fails to connect at 11:43:35); start network later; it starts to contact the servers
<cpaelzer> rbasak: it is not a perfect test, but I think that means it would re-pick-up synchronization in the case you outlined before
<cpaelzer> the env I made this in was broken due to other tests, I'll redo this on a clean environment to be "more" sure
<cpaelzer> rbasak: I'll ping you then in a bit
<cpaelzer> snyc image and apt install is probably the longest part of this test - so not too long
<rbasak> cpaelzer: I was about to accept! :)
<cpaelzer> rbasak: yeah - but I want you to like to accept it when you hit enter :-)
<rbasak> Accept the package into -proposed? [yN]
 * rbasak waits :-)
<abeato> sil2100, now beta works fine in zesty for me. The only issue as that I see this warning when running it: "-o/--output is deprecated; use -O/--output-dir instead", not sure if the same happens in xenial
<cpaelzer> rbasak: confirmed a ntp started without net will pick up once net is available (takea about 20 seconds)
<cpaelzer> rbasak: so please press yes
<cpaelzer> checking an error before it is one is always better
<sil2100> abeato: yes, it's normal
<sil2100> abeato: -o is deprecated, -O is the 'right way' ;)
<abeato> sil2100, ok, besides that it works well :)
<sil2100> \o/
<sil2100> Finally!
<rbasak> cpaelzer: may I have your opinion on https://bugs.launchpad.net/ubuntu/+source/libzen/+bug/1693850 please? Specifically my large file ABI question.
<ubottu> Launchpad bug 1693850 in libzen (Ubuntu Zesty) "libzen wasn't compiled with large file support" [Undecided,Triaged]
<cpaelzer> rbasak:  reading ...
<cpaelzer> rbasak: it has a symbols file
<cpaelzer> rbasak: if the ABI would be hit it would pop up at build time
<cpaelzer> I compare Xenial to artful, there are updates to the symbols file - albeit not a lot
<cpaelzer> but if the change of the options would affect symbols it should show up there
<rbasak> cpaelzer: thanks!
<cpaelzer> rbasak: the only thing left is behavioural change behind same symbols - but trusting the reports a bit I'd tihnk it is either a no-op or improving (for the reported issue)
<cpaelzer> rbasak: do you want me to make an update to the bug statng about the symbols file?
<rbasak> cpaelzer: that'd be useful. Thanks!
<gQuigs> before I retest with the minor debian
<gQuigs> update, is there anything else I should do to move this bug along - https://bugs.launchpad.net/ubuntu/+source/ldap-auth-client/+bug/1646954 ?
<ubottu> Launchpad bug 1646954 in ldap-auth-client (Ubuntu) "Sync to Debian for -ldap, drop Ubuntu's -auth-client" [Wishlist,New]
<gQuigs> might be an archive admin question ^
<jbicha> LocutusOfBorg: hi, when you do merges from Debian, could you try to remember to use the -v option (from dpkg-genchanges)
<jbicha> so that those who read the Ubuntu changelogs know what changed in the Debian versions
<LocutusOfBorg> jbicha, why can't we have a tool for that? :(
<LocutusOfBorg> having to look at which version and pass the switch requires more time than the merge itself probably
<jbicha> and writing a tool to do that may take more time than just passing -v when you do the merges ;)
<LocutusOfBorg> but will last forever
<jbicha> go ahead and write the tool then :)
<LocutusOfBorg> I'm not able to write code, seriously
<jbicha> then use -v like I (try to) do :)
<rbasak> wolsen: around? You need a sponsor for bug 1683076 I think?
<ubottu> bug 1683076 in swift (Ubuntu Xenial) "Swift-storage dies if rsyslog is stopped" [Critical,New] https://launchpad.net/bugs/1683076
<rbasak> wolsen: I suggest three minor changes to your trusty debdiff: https://git.launchpad.net/~racb/ubuntu/+source/swift/log/?h=lp1683076-trusty
<rbasak> The dep3 changes apply to your xenial debdiff too I think. But I'll accept without if you wish.
<wolsen> rbasak: ah so origin, bug, and white space?
<rbasak> wolsen: yeah so just metadata, nothing functional.
<wolsen> rbasak: I'm happy to make those changes
<rbasak> wolsen: since you've rewritten the Trusty patch I don't feel that I can accept it myself as the SRU reviewer - it needs another sponsor +1.
<wolsen> rbasak: appreciate the feedback!
<rbasak> wolsen: but I'm online for the next couple of hours and am happy to work the SRU queue to get everything through as you want it if you can find a sponsor. I've already reviewed my end.
<wolsen> rbasak: ok - I'm still having breakfast with the family so I'll get on that when I start the day (about an hour)
<rbasak> No problem. Thanks!
<wolsen> thank you!
<rbasak> cyphermox: around? About bug 1646585.
<ubottu> bug 1646585 in ubiquity (Ubuntu Xenial) "oem-config replaces /etc/resolv.conf symlink with a hard file" [Medium,Triaged] https://launchpad.net/bugs/1646585
<rbasak> AFAICT this is waiting on a stacked xenial update from unapproved.
<rbasak> Is this what you're expecting?
<rbasak> I suppose you uploaded it, so I'll assume that it is.
<cyphermox> rbasak: yes?
<wolsen> rbasak: I just updated the debdiff for the xenial patch for bug 1683076 with your feedback. Is it possible to get the xenial one going while I get an additional sponsor for the trusty patch?
<ubottu> bug 1683076 in swift (Ubuntu Xenial) "Swift-storage dies if rsyslog is stopped" [Critical,New] https://launchpad.net/bugs/1683076
<rbasak> wolsen: it'd be nice to do both at once. Saves SRU review time.
<wolsen> rbasak: that works for me
<rbasak> Thanks
<rbasak> wolsen: ping me when you have it sponsored and I'll sort it.
<wolsen> rbasak: coreycb was kind enough to review and sponsor/upload
<rbasak> Ah, thanks!
<seb128> cyphermox, slangasek, xnox, hey, not sure if you saw my ping yesterday (I missed your reply if there was any, sorry if that's the case), is any of you going to manage to look at that nplan/n-m issue this week you think?
<slangasek> seb128: per cyphermox, this is a confirmed regression in NM that he had flagged before he left on vacation.  AIUI he is working on working around it from the nplan side, but I guess fixing the regression would also be welcome
<seb128> slangasek, cyphermox, could you file a bug about the regression with the info you have (ideally upstream but launchpad at least would be nice)?
<seb128> slangasek, cyphermox, telling us that you looked at it enough to figure out it's a regression but giving no detail on why you think so or what you tested/how/what you think the issue is forces us basically to restart from 0
<slangasek> seb128: I'm relaying what cyphermox said here yesterday already in response to your question
<seb128> ah ok, I didn't see the reply
<seb128> slangasek, thanks
<slangasek> 11-07-2017 08:57:53 <cyphermox> yes, annoying is working on unblocking that
<slangasek> 11-07-2017 08:58:09 <cyphermox> fwiw, I told jbicha two weeks ago that it was a NM regression
<slangasek> seb128: I don't have the context of why he relayed this info to jbicha
<seb128> right, that info should be on the corresponding launchpad bug :p
<seb128> but thanks!
<seb128> let's wait for cyphermox to be around
<jbicha> oh, he marked LP: #1699371 as fix committed a few minutes ago
<ubottu> Launchpad bug 1699371 in nplan (Ubuntu) "nplan autopkgtests are failing in artful (NM 1.8?)" [High,Fix committed] https://launchpad.net/bugs/1699371
<jbicha> he told me because I did the NM update but I don't understand nplan or nm well enough to do much
<seb128> jbicha, https://git.launchpad.net/netplan/commit/?id=dfe290e6 it looks like
<seb128> that doesn't make it clear why it's a n-m bug though
<seb128> or why we workaround it there rather than upstreaming the n-m issue and getting that resolved if that's a regression
<pdeee> rbasak, thanks for moving the SRU forward
<pdeee> nacc let me know if there's any way we can help with the review
<nacc> pdeee: ack, thanks -- sorry have been heads down on other stuff, will look at it now
<cyphermox> seb128, jbicha: that is because NM used to not manage bridges it didn't create itself, and it seems it maybe regressed in that sense. that said, it is wrong for the test to not clean up after itself anyway; and that behavior in NM might in fact be wanted given that it *did* initially manage all bridges/bonds etc, and they changed the behavior after we chimed in to say it was a problem. They could have
<cyphermox> gone back on their decision
<cyphermox> I don't know, I'm not really involved in NM anymore
<cyphermox> now, it doesn't take much work to see what happens though; just running the autopkgtest locally and loading a shell to see what's up with the test; when it's failing it's still trying to deal with a stray br0 device
<cyphermox> jbicha: for next time, if this happens, you can run the autopkgtest locally and use the -s switch to get a shell in the test environment, then use that to rerun the tests and look at nmcli or whatever, get logs, etc.
<slangasek> cyphermox: fwiw I could not reproduce this issue with the autopkgtests because I could not get a clean run of the tests; they kept trashing the host network and causing all following tests to fai
<slangasek> l
<cyphermox> slangasek: works for me fine with a vm as a test environment
<cyphermox> you definitely should not run network tests like that directly on your system
<slangasek> cyphermox: this was a VM
<cyphermox> err
<slangasek> it was a VM whose network was configured through netplan
<cyphermox> it definitely worked here, I ran it a couple dozen times to figure it out and test the fix
<slangasek> and contents of /etc/netplan were disappearing when the tests ran
<cyphermox> ok, I suppse I mean a vm ran using qemu straight from autopkgtest
<cyphermox> maybe this should be breaks-testbed
<slangasek> ah
<slangasek> yeah, that sounds likely
<cyphermox> otherwise yeah, the tests wipe out /etc/netplan, etc.
#ubuntu-devel 2017-07-13
<marco25> are you guys getting any reports of any issues with the current 3 series for tor network or even tor broswer with zesty and yes I did try to look at bug reports
<marco25> zesty is complete shitware if it all these issues i have had are a result of zesty
<marco25> this is my post from #ubuntu
<marco25> <marco25> in ubuntu 17.04 my pc randomly freezed for like 2 months finally fixed and hundreds of comments from people with same issue...tor series 3 is having problems in zesty seems to work for a lot of other people..tor browswer is crashing again..seems to be working for a lot of other people..and now chromium is not working....should i just go back to ubuntu 16.04 can i take a poll?
<marco25> <marco25> i also had a issue with ubuntu going into a login loop as well
<tsimonq2> Got a bug number?
<marco25> which part
<marco25> the first thing i said
<tsimonq2> All of them if possible :P
<marco25> that freezing that was fixed?
<tsimonq2> If it's fixed, a bug report isn't needed
<marco25> there is one for that and the rest i dont
<marco25> the rest are new and i have looked
<marco25> the first i have and had hundreds of comments
<marco25> and like 20 duplicated
<marco25> duplicates
<marco25> your right but i wanted to say how many issues i had
<tsimonq2> Ok.
<marco25> but i did state it was fixed :P
<tsimonq2> Alright :P
<tsimonq2> Well to be fair, this isn't necessarily the place for this sort of thing. Two places I can think of are #ubuntu-bugs and #ubuntu. :)
<marco25> someone from tor is supposed to try to replicate the issue i had later with zesty
<marco25> they may issue a ticket depending on if he can replicate it
<tsimonq2> But thanks for helping to make Ubuntu better by letting us know. :)
<marco25> why dont you call no lts beta? cause thats basically what it is
<marco25> non lts
<marco25> call non lts beta that is more accurate dont you think?
<tsimonq2> Because I think the fact that it's not a Long Term Support version sort of articulates that. :P
<marco25> no THE WORDS BETA would articulate it :P
<tsimonq2> That's subjective. :P
<marco25> obviously thats the reason ubuntu chose NOT to use those words right?
<marco25> i call a cookie a cookie what about you?
<tsimonq2> Anyways, like I said before, if you have bug numbers (it makes things easier to track), please do let us know in #ubuntu or #ubuntu-bugs :)
<marco25> just about everyone knows what beta means..so choosing not to call it that...seems to be a motive for NOT wanting people to know that
<tsimonq2> Regardless of the terminology, if you'd like to help us better test releases before they come out, I highly suggest you join the Ubuntu QA Team. :)
<marco25> well that tor bug is probably coming cause when the tor guys runs 3 series in zesta its not going to work..bug report probably incoming *wink*
<tsimonq2> Apologies, but I have to go get something to eat. Again, thanks for bringing this to our attention, and I hope we can get this issue solved. :)
<marco25> seems like im on the QA team right now with all these bugs ive dealt with
<tsimonq2> :P
<marco25> I hope so too..what you plan on eating?
<marco25> im just curious if you call your food by its name or just make up an entirely new name :P
<tsimonq2> marco25: Just ate some chicken nuggets :P
<marco25> well maybe we can make up an entirely new name for the same thing? what you think? it could be something personal between me and you :P
<tsimonq2> :P
<Adri2000> stgraber: hello, isn't https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1699010 a bug in lxc/lxcfs rather than lxd? I think I've hit it with xenial/lxc, do you know the status of SRUing the fix for xenial?
<ubottu> Launchpad bug 1699010 in lxd (Ubuntu) "process start times offset by host uptime" [Undecided,Fix released]
<sil2100> jamespage: hey! Any luck on getting LP: #1649616 verified for keystone? I'd like to release the ocata stable releases SRU for zesty sooner or later
<ubottu> Launchpad bug 1649616 in keystone (Ubuntu) "Keystone Token Flush job does not complete in HA deployed environment" [High,In progress] https://launchpad.net/bugs/1649616
<jamespage> sil2100: funnily enough I was just thinking about that
<seb128> willcooke, awe_, https://bugzilla.gnome.org/show_bug.cgi?id=737362
<ubottu> Gnome bug 737362 in Privacy "Privacy panel is missing switch to disable captive portal detection" [Normal,New]
<willcooke> thanks seb128
<jbicha> bdmurray: hi, see LP: #1701943 (in case you missed it)
<ubottu> Launchpad bug 1701943 in ubuntu-release-upgrader (Ubuntu) "ubuntu-release-upgrader's autopkgtest fails due to stricter pep8 test" [High,New] https://launchpad.net/bugs/1701943
<bdmurray> jbicha: will look, thanks
<jbicha> bdmurray: could you review gnome-software/zesty from unapproved when you work on SRUs (today?) ?
<jbicha> becuase gnome-software/zesty has been stuck in phased-updates for months for various reasons :(
<stgraber> Adri2000: the sru has been released two days ago
<seb128> wgrant, I feel like I've hit that issue before and asked some previous cycle, but any idea why the evolution-data-server artful .po files from the package build aren't getting listed on https://translations.launchpad.net/ubuntu/artful/+source/evolution-data-server/+imports ?
<Adri2000> stgraber: ah nice! :) https://bugs.launchpad.net/ubuntu/+source/lxcfs/+bug/1654310 then. thanks
<ubottu> Launchpad bug 1654310 in lxcfs (Ubuntu Xenial) "lxcfs: update the 'btime' field in /proc/stat to reflect guest boot time not host " [High,Fix released]
<stgraber> Adri2000: yup
<zyga> seb128: hey
<zyga> seb128: how can I quickly contribute a two-character fix to /usr/bin/gvfs-trash
<zyga> seb128: the shell script uses == instead of = for comparison and doesn't actually work in ubuntu/debian
<zyga> seb128: (on artful)
<jbicha> zyga: I guess short answer is attach a patch to https://bugzilla.gnome.org/enter_bug.cgi?product=gvfs
<bdmurray> jbicha: Im going to reject the gnome-session SRU because of bug 1700485 and to avoid any accident acceptances.
<ubottu> bug 1700485 in gnome-session (Ubuntu) "Second login always fails. I have to reboot between logins" [High,Confirmed] https://launchpad.net/bugs/1700485
<jbicha> ok
<jbicha> bdmurray: is it fine if I put the bug status back to Triaged though?
<bdmurray> jbicha: the gnome-session task? sure
 * hallyn looks for mvo
<hallyn> cpaelzer: hi, so i think mvo, slangasek, and stgraber may be of help wrt sandbox-upgrader and auto-upgrade-tester
<hallyn> and whether they are active or should also be pulled
<hallyn> (re bug 1260062)
<ubottu> bug 1260062 in vm-builder (Ubuntu) "Please remove vmbuilder from the archive in 14.04" [High,Confirmed] https://launchpad.net/bugs/1260062
<stgraber> I'm not running an auto-upgrade-tester setup anymore. Not sure if someone else is
<slangasek> I am surely not
<slangasek> bdmurray or jibel might know if this code is in use
<bdmurray> jibel: would know best
<bdmurray> I actually hadn't heard of sandbox-upgrader. ;-)
<nacc> hallyn: thanks for brining that up -- i'll follow up on it
<hallyn> bitrot :)
<hallyn> cool - thanks - \o
<mwhudson> Laney: wtf that session-migration thing we cooked up fails on !amd64
<mwhudson> Laney: https://bugs.launchpad.net/ubuntu/+source/session-migration/+bug/1704238
<ubottu> Launchpad bug 1704238 in session-migration (Ubuntu) "ftbfs on non-amd64" [Undecided,New]
#ubuntu-devel 2017-07-14
<mwhudson> $ dpkg-deb -c python-txaio_2.8.0-0ubuntu1_all.deb  | grep LICENSE
<mwhudson> -rw-r--r-- root/root      1091 2016-11-07 08:23 ./usr/LICENSE
<mwhudson> how did I do /that/?
<Unit193> mwhudson: I'll match yours, and raise you a dpkg -L gnome-system-tools
<mwhudson> partly by not reading lintian output i guess
<mwhudson> Unit193: lol
<mwhudson> running install_data
<mwhudson> copying LICENSE -> /<<PKGBUILDDIR>>/debian/python-txaio/usr/.
<Unit193> dh_auto_install -X LICENSE
<Unit193> /usr/@DATADIRNAME@/locale/es/LC_MESSAGES :3
<mwhudson> Unit193: yeah i saw that, a good trick
<mwhudson> Unit193: is it FHS compliant? :)
<Unit193> mwhudson: Mostly seen it with *.la files though.
<mwhudson> anyway time for me to EOW
<Unit193> G'night.
<pitti> Laney: can you please prune/stop all running and queued systemd-upstream tests on i386 and amd64? the "eternal retry loop" issue is back
<pitti> Laney: if you could fish out some binaries for local examination that'd be great; but at least we should stop pounding the infra unnecessarily
<pitti> Laney: I disabled the i386/amd64 webhooks (s390x is fine)
<zyga> good morning! :)
 * tsimonq2 waves at zyga 
<Laney> mwhudson: yes I saw of course, I get mailed about build failures
<Laney> or does filing the bug mean you're fixing it?
<Laney> pitti: ok, thanks!
<pitti> Laney: heh - "thanks for breaking our infra"? :-)
<pitti> Laney: thanks for cleaning up
<Laney> thank you for your valued custom
<Laney> or something :P
<pitti> haha
 * pitti hands Laney the queue hammer, size C
<Laney> apparently lgw01 should be back too, /me checks that
<pitti> ooh, nice
<pitti> glad that we don't have a ber01 :-P
<Laney> oh, evidence that IS have been in the machine
<Laney> broken glass, wine bottles everywhere
<Laney> pitti: I randomly picked the binaries from https://github.com/systemd/systemd/pull/6354 if that's ok
<Laney> was this another try at meson?
<pitti> Laney: yes; now that 234 is released, the downstream packaging master branch switched
<pitti> so it kinda sorta happened
<pitti> Laney: yep, that one should be fine
<Laney> ok, think I got them, one second
 * pitti listens to the splatter noise
<Laney> pitti: http://people.canonical.com/~laney/weird-things/systemd-pr-6354.tar.xz
<xnox> doko, dannf is there something weird on arm64 with pic/pie and the gcc-6.4 compiler, vs gcc-6.3 compiler?
<xnox> or maybe something else in artful-proposed vs artful?
<xnox> i can build ocaml with pic on arm64 in artful, but not artful-proposed.
<infinity> xnox: binutils, maybe?
<infinity> xnox: proposed has a shiny snapshot that has some ARM changes that broke glibc (turned out to be bugs in glibc, ish, but still, code generation for ARM and ARM64 changed)
<xnox> infinity, could be that too. Let me quickly try artful + cherrypick binutils to see if that's the badger
<xnox> infinity, i do not discount mistakes in ocaml too, as they did refactor the flambda stuff upstream and fixed bugs, but that's in snapshot / rc releases of 4.05, and i am on 4.04 at the moment =/
<infinity> xnox: Do you have a build log?
<xnox> yes.
<xnox> but that's all of artful-proposed, rather than just with binuitls
<xnox> let me get the urls
<infinity> xnox: Sure, was just going to look for suspicious messages.
<xnox> https://launchpadlibrarian.net/326748605/buildlog_ubuntu-artful-arm64.ocaml_4.04.0-2ubuntu5_BUILDING.txt.gz
<infinity> Yup.  It's binutils.
<infinity> xnox: grep that log for "relocation".
<infinity> xnox: And compare with https://sourceware.org/ml/binutils/2017-06/msg00226.html
<ubottu> sourceware.org bug 2017 in general "merge all PKG_CHECK_MODULES calls" [Normal,Resolved: fixed]
<infinity> xnox: The bug is certainly in ocaml, but the new binutils exposes it.
<xnox> infinity, ok - can you nuke that binutils from artful-proposed, such that i can finish ocaml transition?
<xnox> horum
<xnox> i guess i need to check if upstream fixed it?
<infinity> xnox: Unless upstream cares deeply about snapshot binutils *and* Aarch64 (both seems unlikely), I doubt they're even aware of it yet.
<xnox> also reading that message.... is like reading egyptian, given that i have never done assembly.
<xnox> let me imploy my carbon-based life-form AI pattern matching skills against ocaml code
<infinity> xnox: it's only a few symbols (over and over and over...) though, so it might be pretty easy to fix if you read and make sense of the glibc fix above.  It'll be the same issue.
<xnox> granted arch specific assembly is very little in ocaml
<infinity> xnox: Yeah, the ocaml bug is probably not in ASM.
<xnox> well. the native ocaml compiler generates assembly from ocaml for stuff
<infinity> xnox: But it'll be basically the same issue.  A symbol that should be tagged hidden but isn't, or vice versa.
<xnox> so given it has asm generator.....
<infinity> xnox: OTOH, you could just report it upstream, point to the binutils/glibc thing above as a hint, and wait for someone who knows the codebase to respond.
<infinity> xnox: I kinda feel like the build log's obvious vomit and an understanding of the issue should translate into a "5-minute fix" for someone who also knows ocaml.
<infinity> xnox: Which isn't either of us. :)
<LocutusOfBorg> mwhudson, sorry for staling your python-txaio package
<LocutusOfBorg> s/staling/stealing
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/python-txaio/2.8.0-0ubuntu2
<LocutusOfBorg> bit mistake, they are not coinstallable because they share the same LICENSE file in usr? I removed it, this should fix python-autobahn build
<jamespage> sil2100: hey - verification chased and completed on https://launchpad.net/bugs/1649616
<ubottu> Launchpad bug 1649616 in keystone (Ubuntu) "Keystone Token Flush job does not complete in HA deployed environment" [High,In progress]
<jamespage> sil2100: but its friday now :-)
<hjd> How long is it "normal" for packages to be stuck in pending publication? https://launchpad.net/ubuntu/+source/node-sshpk seems to have waited for about a day now. Anywhere I can see some more info on the current status? :)
<LocutusOfBorg> Artful: [FULLYBUILT] amd64 (New)
<LocutusOfBorg> hjd, until an archive admin approves/reject them I would say https://launchpad.net/ubuntu/artful/+queue?queue_state=0&queue_text=
<hjd> Oh, is that because it is a new package?
<cjwatson> hjd: accepted
<LocutusOfBorg> that one, yes :)
<LocutusOfBorg> new source, and new binary, so double new queue
<xnox> infinity, https://caml.inria.fr/mantis/view.php?id=7585 ocaml upstream bug report
<xnox> they use github for code, but this thing for bugs
<cjwatson> not actually in the sourceful case, since auto-imports from Debian bypass the NEW queue
<LocutusOfBorg> and they end up in universe? or you have to put them in universe in the bin-new step?
<LocutusOfBorg> or everything goes in universe by default and a MIR moves it?
<cjwatson> the latter
<sil2100> jamespage: excellent! Yeah, I'll release it on Monday ;)
<LocutusOfBorg> wonderful
<cjwatson> well modulo source packages that are already in main, but mostly
<LocutusOfBorg> kudos for you :D
<hjd> Ok, I see. Thanks for the help :)
<tsimonq2> Sooo when does patch pilot come back? :D
<tsimonq2> I have like... 6(?) things sitting in the sponsorship queue atm...
<LocutusOfBorg> mwhudson, seems python-autobahn is fixed now
<tsimonq2> Ok, just looked, 7 to be exact...
<LocutusOfBorg> tsimonq2, I saw them tonight, maybe I can have a look
<LocutusOfBorg> link please? too lazy to find it
<tsimonq2> http://reqorts.qa.ubuntu.com/reports/sponsoring/
<tsimonq2> bug 1702858 bug 1704031 bug 1704036 bug 1704055 bug 1704061 bug 1704257 bug 1704258
<tsimonq2> :)
<ubottu> bug 1702858 in afterstep (Ubuntu) "Merge 2.2.12-10 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1702858
<ubottu> bug 1704031 in eccodes (Ubuntu) "Merge 2.4.0-2 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1704031
<LocutusOfBorg> ok thanks
<ubottu> bug 1704036 in icon (Ubuntu) "Merge 9.4.3-6 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1704036
<ubottu> bug 1704055 in lasi (Ubuntu) "Merge 1.1.0-2 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1704055
<ubottu> bug 1704061 in openmama (Ubuntu) "Merge 2.2.2.1-11.1 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1704061
<tsimonq2> aaah bug bot
<tsimonq2> I felt bad for giving my usual sponsor all 7 of these things to review... :P
<Laney> mwhudson: phixed phor you
<LocutusOfBorg> tsimonq2, they should be all in
<tsimonq2> LocutusOfBorg: omg what?
<tsimonq2> LocutusOfBorg: Every. Single. One. Of. Them?
<tsimonq2> :D
<LocutusOfBorg> wild guess, yes
<tsimonq2> :D
<LocutusOfBorg> modulo the one I can't force sync because sync is having some troubles
<LocutusOfBorg> and something I might have forgotten, please doublecheck
<tsimonq2> Ok, I absolutely will. Thank you!
<tsimonq2> LocutusOfBorg: bug 1704258
<ubottu> bug 1704258 in cg3 (Ubuntu) "Merge 1.0.0~r12254-1 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1704258
<LocutusOfBorg> tsimonq2, it is ok, just forgot to update the bug
<LocutusOfBorg> new queue
<tsimonq2> LocutusOfBorg: ...way
<tsimonq2> *wat
<LocutusOfBorg> I won't touch LP: #1690491
<ubottu> Launchpad bug 1690491 in lxqt-session (Ubuntu) "Merge 0.11.1-2 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1690491
<LocutusOfBorg> and please update LP: #1699426
<ubottu> Launchpad bug 1699426 in python-tornado (Ubuntu) "Merge 4.5.1-2 from Debian Sid" [Undecided,In progress] https://launchpad.net/bugs/1699426
<tsimonq2> LocutusOfBorg: lxqt-session will just be force synced once Qt 5.9.1 lands
<tsimonq2> LocutusOfBorg: And with python-tornado, afaict Corey's patch can be dropped, and the only other patch is disabling tests...
<LocutusOfBorg> so if you want prepare a new debdiff
<tsimonq2> LocutusOfBorg: I would even go as far as to say we can force sync and see if the tests still fail, but I can't test if they do anyways because I don't have an armhf box (and I'm not a Canonical employee or a DD so I don't have access to a porterbox...)
<tsimonq2> LocutusOfBorg: I guess I can prepare a debdiff disabling the tests as a just-in-case thing
<tsimonq2> LocutusOfBorg: And you may just want to upload that to be safe :P
<LocutusOfBorg> you can test in a ppa?
<tsimonq2> Isn't that typically ran by autopkgtest infra?
<tsimonq2> If it isn't, I'll go ahead and test in a PPA.
<LocutusOfBorg> mmm you can request autopkgtest from ppa
<tsimonq2> ...since when?
<tsimonq2> I was not aware of this :D
<LocutusOfBorg> who remembers? :)
<LocutusOfBorg> I remember Laney telling me about how to do it...
<LocutusOfBorg> on #ubuntu-release
<tsimonq2> LocutusOfBorg: Can you relay that info to me? :) :)
<LocutusOfBorg> I'm looking
<tsimonq2> That would be super useful.
<tsimonq2> Ok
<LocutusOfBorg> mapreri, ^^^
<LocutusOfBorg> please do your grep powers
<tsimonq2> mapreri has grep powers? :D
<mapreri> oh, text
<mapreri> LocutusOfBorg: where should I start to read?
<Laney> https://wiki.ubuntu.com/ProposedMigration/#Testing_against_a_PPA
<LocutusOfBorg> <3
<tsimonq2> oooOOOooo
<LocutusOfBorg> tsimonq2, so, you should now be able to test and tell me if force-sync or merge
<LocutusOfBorg> :)
<tsimonq2> LocutusOfBorg: Alright, I'll let you know in a little bit :)
<LocutusOfBorg> thanks
<mapreri> tsimonq2, LocutusOfBorg: is there anything for me here or why did you highlighted me? :P
<LocutusOfBorg> mapreri, because I know it bothers you? :)
<LocutusOfBorg> I remember you have highlights also for some other words, but I don't remember exactly
<mapreri> And here I was, hoping to find some gift or something ^^
<mapreri> LocutusOfBorg: irc_extra_hilight = Mattia Rizzolo,jerea,jenkins,reproducible,pbuilder,SOURCE_DATE_EPOCH,MIA
<tsimonq2> You have a highlight on pbuilder? XD
<tsimonq2> That's epic
<mapreri> heh
<tsimonq2> mapreri: You must get pinged a lot :P
<mapreri> not so much, tbh
<LocutusOfBorg> except by me
<LocutusOfBorg> and pbuilder users
<LocutusOfBorg> or even MIA team mates
<LocutusOfBorg> and for people having issues with reproducible patches
<mapreri> but I like to chime in when somebody has troubles with pbuilder, and prove that everything is awesome
<LocutusOfBorg> jerea, what is that?
<mapreri> jerea.debian.org == jenkins.debian.org  (in an hopeful future)
<LocutusOfBorg> ack
<mwhudson> Laney: awesome, i just filed the bug because i'd debugged a little
<mwhudson> LocutusOfBorg: no worries, steal anything python 3.6 related you want/can :)
<Laney> mwhudson: how's the 3.6 business going?
<mwhudson> Laney: ok https://docs.google.com/spreadsheets/d/1Y8dy5cyu8DrmTvT4CNSaVSP2ZZT79sYhT_rAQ19bFUQ/edit#gid=0
<mwhudson> Laney: environment variables are evil
<mwhudson> (re the session migration breakage)
<tsimonq2> LocutusOfBorg: You submitted an invalid request: You are not allowed to upload python-tornado or python-tornado to Ubuntu, thus you are not allowed to use this service.
<tsimonq2> *sigh*
<LocutusOfBorg> tsimonq2, give me the link?
<tsimonq2> LocutusOfBorg: https://autopkgtest.ubuntu.com/request.cgi?release=artful&arch=ppc64el&package=python-tornado&ppa=tsimonq2/universe-upload-testing&trigger=python-tornado/4.5.1-2
<tsimonq2> LocutusOfBorg: But I build the packages in my PPA for all releases that I can as a non-Canonicaler
<tsimonq2> LocutusOfBorg: So ideally I can have it triggered for amd64, i386, armhf, and arm64 as well.
<LocutusOfBorg> arm64 no, but the others yes
<tsimonq2> Why not?
<LocutusOfBorg> because there is no infra in ubuntu (yet) for arm64
<tsimonq2> Ah ok
<tsimonq2> fair
<LocutusOfBorg> probably somebody is enabling it, right now
<LocutusOfBorg> mwhudson, python-3to2 has been removed in unstable, so probably pinging an AA can make it disappear and fix the line on the spreadsheet
<tsimonq2> LocutusOfBorg: Ok, so where will the results be once it's done?
<LocutusOfBorg> I'm reading right now the wiki
<LocutusOfBorg> it is written, but you have to create the link
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-=tsimonq2-universe-upload-testing/?format=plain
<LocutusOfBorg> soemthing like that I would say
<tsimonq2> Unauthorized
<tsimonq2> This server could not verify that you are authorized to access the document you requested.
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-RELEASE-LPUSER-PPA/?format=plain
<LocutusOfBorg> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful-tsimonq2-universe-upload-testing/?format=plain
<LocutusOfBorg> this one is good
<tsimonq2> Ok
<tsimonq2> So then what are these filenames for?
<LocutusOfBorg> read the wiki :p
<tsimonq2> Oh
<tsimonq2> nvm
<LocutusOfBorg> remove ?format=plain and put that stuff
<tsimonq2> Yeah
<tsimonq2> Figured that out :)
<tsimonq2> *sigh* so I just realized something LocutusOfBorg
<tsimonq2> LocutusOfBorg: So I just ran copy-package to my PPA from Debian
<tsimonq2> LocutusOfBorg: But since you already uploaded a delta, it pulled that in
<tsimonq2> LocutusOfBorg: So these should all pass because it pulls in the version with the patch disabling them... :/
<tsimonq2> LocutusOfBorg: If you give me one minute, I can upload a version to my PPA that will be greater than the Ubuntu one, if you could please retry them?
<pitti> Laney: did you put the binaries and log somewhere I can access it?
<tsimonq2> LocutusOfBorg: If you (or anyone else with upload access to Universe) could retry those tests, that would be great :)
<tsimonq2> er, wait 10-15 mins for it to build and publish...
<Laney> pitti: 14/07 09:29:07 <Laney> pitti: http://people.canonical.com/~laney/weird-things/systemd-pr-6354.tar.xz
<Laney> :-)
<pitti> Laney: odd, I didn't get that the first time; thanks!
<teward> for autopkgtests, is there a way to get `systemctl status -l nginx.service` to see the actual errors?  (https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/armhf/n/nginx/20170714_103942_95833@/log.gz - armhf 'regression' but I can't see the error messages)
<mitya57> Mirv, hi! Do you know if qtcreator can be synced, or we still need some of the delta?
<tsimonq2> ohai mitya57 :)
<mitya57> Hi :)
<mitya57> Trying to take care of migration of your qbs upload :)
<tsimonq2> \o/
<ahasenack> hi, could someone please sponsor https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1677329 ? I attached a debdiff in parallel to the existing MP
<ubottu> Launchpad bug 1677329 in samba (Ubuntu Zesty) "libpam-winbind: unable to dlopen" [High,In progress]
<ahasenack> it's a zesty sru
<LocutusOfBorg> tsimonq2, hold on, I need to create the link
<tsimonq2> LocutusOfBorg: Ok, thanks
<LocutusOfBorg> + is %2B
<LocutusOfBorg> done
<tsimonq2> ack
<tsimonq2> LocutusOfBorg: Please go ahead and force sync python-tornado :)
<tsimonq2> LocutusOfBorg: It all lgtm
<LocutusOfBorg> we need a new release to force sync
<LocutusOfBorg> or I can call it 2.1~build1
<LocutusOfBorg> to make it auto-syncable on next upload
<tsimonq2> LocutusOfBorg: wfm
<LocutusOfBorg> .
<tsimonq2> :)
<LocutusOfBorg> tsimonq2, if you have time, you might help investigating gdal transition failures :p
<tsimonq2> LocutusOfBorg: Link me?
<tsimonq2> Sounds fun :P
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/openscenegraph-3.4/3.4.0+dfsg1-4build2
<LocutusOfBorg> failing armhf, not in Debian
<LocutusOfBorg> this one should be the same https://launchpad.net/ubuntu/+source/openscenegraph/3.2.3+dfsg1-2ubuntu4
<LocutusOfBorg> this one is being debugged by me https://launchpad.net/ubuntu/+source/otb/6.0.0+dfsg-2build1
<tsimonq2> LocutusOfBorg: Got a transition tracker somewhere?
<LocutusOfBorg> nope, but fixing the above three failures should be enough
<LocutusOfBorg> I'll look at britney
<tsimonq2> Ok
<LocutusOfBorg> adding a tracker now
<LocutusOfBorg> http://people.canonical.com/~ubuntu-archive/transitions/html/gdal.html
<tsimonq2> That does look fun
<LocutusOfBorg> wait for it appear
<tsimonq2> I was just looking at the individual failure
<tsimonq2> LocutusOfBorg: What's the usual ETA on this sort of thing? :)
<LocutusOfBorg> don't know :) there are a lot of missing autopkgtests, so I guess it won't sort out before some days
<tsimonq2> I mean on the thing appearing :P
<LocutusOfBorg> you can diff the build dependencies looking at debian/ubuntu logs as start
<LocutusOfBorg> meh, one hour or so
<tsimonq2> Ok
<LocutusOfBorg> osgearth is bad on armhf because of that above failure
<LocutusOfBorg> saga is getting fixed right now after opencv rebuild
<LocutusOfBorg> so, otb and openscenegraph-* are the last blocker
<tsimonq2> I'll look and see if I can wrap my head around openscenegraph-3.4
<LocutusOfBorg> nice otb fails in debian too
<LocutusOfBorg> so, don't care
<tsimonq2> LocutusOfBorg: So from what I can gather in this build log for openscenegraph, I need to get a quilt patch that patches CMakeLists.txt to add `cmake_policy(SET CMP0056 NEW)` and `cmake_policy(SET CMP0066 NEW)`. Then that might fix things, right?
<LocutusOfBorg> not sure :D
<LocutusOfBorg> why only armhf?
<tsimonq2> Very good question...
<tsimonq2> Let me just try that and upload that to my test PPA, see what breaks :D
<LocutusOfBorg> "pbuilder-dist artful armhf create"
<tsimonq2> Oh
<tsimonq2> Well I use sbuild, although there *are* commands for that...
 * tsimonq2 gets a cup of coffee
<tsimonq2> Coffee attained :P
<hjd> Anyone who could retrigger a couple of builds in artful? :) Looks like several Java packages build succesfully with the newer version of surefire. The list of packages is:  cdi-api jansi-native jglobus plexus-compiler voms-api-java voms-clients-java
<hjd> I've only tried a couple of them on my artful VM, but they all had similar build failures and the ones I tried built successfully now :)
<cjwatson> hjd: done
<hjd> thanks :)
<LocutusOfBorg> hjd, you should thank him twice, one for fixing surefire dependencies (a bootstrap was needed), and one for retrying them :P
<hjd> Oh, it needed a boostrap. That certainly explains how the surefire build suddenly became green :p Thanks again :)
 * hjd is afk for a while
<LocutusOfBorg> slangasek, do you have any clue for openscenegraph and armhf failure? it is the really old gles2 failure
<LocutusOfBorg> I'm really tempted to ask for a removal on that architecture
<LocutusOfBorg> that stuff can't run on armhf, and IIRC gles2 was broken there
<pdeee> nacc, rbasak, bmw woohoo!
<pdeee> any further steps before an upload?
<rbasak> pdeee: I just need to sort the paperwork
<rbasak> A task for next week I think.
<rbasak> But almost there now :)
#ubuntu-devel 2017-07-15
<Mirv> mitya57: hi! I think transitional package would be needed until 18.04 LTS, other changes can be dropped probably, including the SDK migration note.
 * tsimonq2 waves to Mirv :)
<mitya57> Mirv, thanks, preparing the merge in silo 2866 and will publish if it builds everywhere.
<mapreri> jbicha: I'm looking at the abiword repository in collab-maint, and I notice that 1) the upstream branch is completely empty 2) despite being upstream files in master I fail to see a commit that updates them for the new upstream that you prepared 3) no pristine-tar branch.  Now, what kind of repository is that?  /cc tsimonq2
<jbicha> mapreri: it is a packaging-only branch
<jbicha> and it's also not my fault
<mapreri> oh, debcheckout tricked me by dumping the upstream files there
<jbicha> I don't have write permissions to overwrite stuff
<mapreri> what do you want to do?
<jbicha> I'd like for someone to run
<jbicha> chown -R :collab-maint /git/collab-maint/abiword.git
<mapreri> only formorer can do thatâ¦
<mapreri> and you don't want that
<mapreri> what you want is scm_collab-maint
<jbicha> ok, that
<mapreri> but.. why?
<mapreri> what do you want to overwrite?
<mapreri> objects/ and refs/ seems entirely writable, isn't it?
<jbicha> well I can't change any of the hooksâ¦
<mapreri> that's the point
<mapreri> don't you follow debian-devel-announce?
<mapreri> https://lists.debian.org/debian-devel-announce/2015/08/msg00008.html
<mapreri> [07:44:32 PM] <mapreri> what do you want to do?
<jbicha> mmm, that's less open than I thought collab-maint would be, but ok
<mapreri> collab-maint is a security nightmare
<Unit193> â
<jbicha> I don't even run abiword which is part of why I don't want to be its maintainer
<jbicha> I don't remember now what I wanted to change
<mapreri> non-DDs could add hooks that DDs could then execute, with the potential to do disasters.  or even if you don't consider DDs, but "people with write permissions in a lot of teams"â¦
<jbicha> couldn't you say that about membership in any large Debian team though?
<jbicha> mapreri: do you use abiword?
<mapreri> yes, so let's say "alioth is a security nightmare"
<mapreri> and no, I don't use it
 * Mirv waves to tsimonq2 
<Unit193> Though collab-maint just happens to be the biggest.
<jbicha> mapreri: ok, I deleted the useless upstream branch
<mapreri> acl
<mapreri> ack*
<Son_Goku> :/
<Unit193> LocutusOfBorg: If you want to fix the wine-development ftbfs, you could push https://launchpad.net/~unit193/+archive/ubuntu/staging/+sourcepub/8037657/+listing-archive-extra (trimming the last changelog of course.)
<LocutusOfBorg> Unit193, let me see
<LocutusOfBorg> I did sponsor, changing devel to artful
<LocutusOfBorg> I know this is not a problem, but my dput is picky
#ubuntu-devel 2017-07-16
<Unit193> LocutusOfBorg: Thanks.
<LocutusOfBorg> yw
<EleanorEllis> Why are the download links for ubuntu and all the other flavours http, rather than https? I know you provide additional information to verify the downloads but not everybody who downloads ubuntu would know to look for that information. I understand that https is probably not enough on it's own, but it would be a step in the right direction and would give users more confidence. The current situation also means that users of th
<EleanorEllis> results" can't connect to the downloads.
<tgm4883> EleanorEllis: https would be up to the cd mirror provider I would think, some of which do provide https links
<EleanorEllis> tgm4883: But the main one, http://cdimage.ubuntu.com is not https
<tgm4883> EleanorEllis: TBF, the main one would be https://www.ubuntu.com/download but I see what you mean
<EleanorEllis> tgm4883: I imagine some users ,ogj
<EleanorEllis> might think they were safe, simply because the iso they receive has been verified by their bittorrent client, but they would be incorrect since there is no secure way, even to download the torrent file
<tgm4883> HTTPS shouldn't be used as confidence that you're getting the correct ISO, however you're correct that there doesn't seem to be an HTTPS way to get either the SHA or bittorrent files
<EleanorEllis> tgm4883: I realise that, but surely we ought to provide this basic minimum, especially to inexperienced users
<tgm4883> EleanorEllis: for cdimages.u.c and releases.u.c yes, but I supposed it can give a false sense of confidence for any of the mirrors. I'll defer to someone else that can control the websites, I tried finding where bug reports are for those sites but neither are listed on https://github.com/canonical-websites
<maswan> we provide https for almost all vhosts for our releases mirror, except the se.releases.u.c name
<maswan> due to u.c policy
<maswan> but then, there is no hard vetting on mirrors other than volunteers that seem to be serving the right content most of the time
<tgm4883> maswan: what about releases.ubuntu.com and cdimage.ubuntu.com ?
<tgm4883> neither appear to work with https
<tgm4883> Both of which I think are the main concern, since both the torrents and sha sums are found there
<Unit193> maswan: If you get the hashes from the main host, but the iso from the mirror you should be pretty set.  Using gpg to verify the hashes is another layer.
<EleanorEllis> maswan: tgm4883: I am just looking for the SHA files for Ubuntu Budgie and going about it how a new user might do it. There is nothing in the installation guide about verifying the download, it just goes straight into making a bootable medium. https://ubuntubudgie.org/downloads
<maswan> yeah, tbh, I'd like to see a rework of cdimage.u.c
<Unit193> Currently, the only way I see to download the hashes over a TLS connection is using the wiki, which "anyone" can edit.
<maswan> but I guess it is only live daily builds these days, so it's pretty much mirrorable these days
<cjwatson> actually that page is locked much more than usual wiki pages, though I agree it's past time for cdimage to be https really
<cjwatson> (of course it's easy for me to agree since I don't really work on it any more ...)
<maswan> yeah, even our computer club could cough up the new cpus to handle https, 55xx -> 56xx series. :)
<maswan> I think they cost 3 or 5 eur each
<maswan> I've always hesitated to do a full mirror of it due to directories named -daily with a few gigs of isos, but if it is just one a blacklist (or just suck it up and mirror it anyway) is doable
<maswan> a download page for all the other ubuntus that live on cdimage.u.c, on https, with a mirrorbits to redirect to cdimage.u.c or mirrors as appropriate would be neat though?
<EleanorEllis> Should I raise this as a bug somewhere so it doesn't get forgotten about?
<tomreyn> EleanorEllis: did you actually chek the link i posted (which explains in 5 steps how to verify the download in a cryptographically secure manner) when you asked this question in #ubuntu ?
<tomreyn> <tomreyn> EleanorEllis: https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify-ubuntu#0
<EleanorEllis> tomreyn: Yes I did, but someone else in #ubuntu asked me to raise this with ubuntu-devs
<tomreyn> well, it's not a bug
<tomreyn> a link to the above page is available at https://www.ubuntu.com/download/desktop/thank-you?country=DE&version=16.04.2&architecture=amd64 (the page you would start an LTS download from)
<tomreyn> it's not obvious enough IMO, but it's not exactly wrong.
<EleanorEllis> OK. I will rephrase the question. Since several people seem interested in this topic, should I ask this question on a web-page somewhere so that it doesn't get forgotten about? If so, where?
<tomreyn> surely, https transfers would be a nice addition, but i agree one needs to prevent a false sense of security.
<EleanorEllis> tomreyn: I think the main issue is that someone downloading ubuntu for the first time might be an inexperienced user, and naive about security, like I was and still am.
<tomreyn> that's what this guide is for. but maybe that's still too complex?
<tomreyn> you could raise your concerns in #canonical-sysadmin, i assume they'll be able to tell where this should be discussed further.
<tomreyn> they also have a request tracker there (address on topic) but i'd check with them first (handler on duty is on topic as well)
<tomreyn> ...not during the weeknd though
<tomreyn> (and i'm not affiliated with canonical)
<EleanorEllis> tomreyn: OK. Put yourself in the shoes of an inexperienced user and go to ubuntu.com and follow through the links to download and install. If you go for Ubuntu Budgie for example, there is no mention of verification on the Downloads page, and I only managed to find the SHA files by copying, pasting and editing one of the links on the download button
<tomreyn> EleanorEllis: you mean downloading it from here? https://ubuntubudgie.org/downloads (i ended up there by searching "ubuntu budgie download" on google) - then i have to agree, information on how to access and verify the checksums and the gpg signature over that need to be added to the ubuntu budgie website.
<tomreyn> this issue is not present for ubuntu proper IMO, or not as much. but then, too, i agree it would be good to make it as easy as possible for new users to verify authenticity of downloads.
<EleanorEllis> tomreyn: Yes, that is the page. How is a new user not to know that Budgie is not ubuntu proper since it is linked from https://www.ubuntu.com/download/ubuntu-flavours
<EleanorEllis> ?
<tomreyn> EleanorEllis: by 'ubuntu proper' i mean ubuntu with unity, the primary ubuntu blend. but budgie is actually an official blend these days, IIRC.
<tomreyn> so there's no need to know anything there.
<tomreyn> (but the website wshould be improved)
<EleanorEllis> tomreyn: So my point is that there is nothing there about verification, and if you follow the trail of webpages from a download link, it is not obvious that this needs to be done. On http://lubuntu.me/downloads/ for example there is a small note about verification but it is in very small type, much smaller than the download buttons. Surely it is worth making this stuff very clear indeed, or impossible to miss in the interest 
<tomreyn> EleanorEllis: what you wrote was probably cut off after "in the interest". with the rest, i agree.
<EleanorEllis> in the interest of new users.
<tomreyn> i do not know what's the best way to pass this on to the maintainers of these websites.
<tomreyn> maybe if you join the blend specific channels you'll find out.
<tomreyn> it's also someting you could discuss with the security team in #ubuntu-hardened to see whether they want to start a concerted effort to handle this.
<mwhudson> whoa http://people.canonical.com/~ubuntu-archive/proposed-migration/artful/update_excuses.html#pytest looks super unhappy
#ubuntu-devel 2018-07-09
<acheronuk> ricotz: a user reports that FF 62.0~b6 from the PPA disables all extensions and they can't be re-enabled. are you aware of any issue?
<sil2100> rbasak: hey! Did you see my last-week's ping about letsencrypt in xenial?
<acheronuk> LP: #1780793
<ubottu> Launchpad bug 1780793 in firefox (Ubuntu) "All extensions disabled in Firefox 62.0b6 on Ubuntu 18.04 LTS" [Undecided,New] https://launchpad.net/bugs/1780793
<acheronuk> so I got a report on IRC for that, and found that bug report, and they are not the same reporter
<rbasak> sil2100: yeah. I need to reply there. The packages need more work. Just needs somebody to do them. Unfortunately it's a disproportionately large amount of work because of the number of source packages, releases and package renames involved.
<rbasak> So I ran out of time multiple times on that already
<rbasak> I have successfully made a classic snap of certbot instead, which was far less work.
<rbasak> So I'm trying to see if that'll be a better approach for users.
<rbasak> In the meantime, the SRU can either make progress or not. I don't have the ~2 days I think it'll take to drive it through to spare right now :(
<bdmurray> Laney: Could you explain to me how to call Vte.Terminal.feed_child() in vte2.91 version 0.52.2? It seems to have changed between 0.52.2 and 0.52.1. Bug 1780501
<ubottu> bug 1780501 in ubuntu-release-upgrader (Ubuntu) "Traceback calling Vte.Terminal.feed_child()" [High,Triaged] https://launchpad.net/bugs/1780501
<Caspy7> Howdy. I help a bunch with firefox support and we're seeing several reports that Ubuntu users using the beta build of firefox (not downloaded from Mozilla) are having all their addons disabled
<Caspy7> does anyone have more info on this situation or an update?
<Caspy7> (is there a bug filed perhaps?)
<Laney> bdmurray: Omit the last argument I guess. Maybe we shouldn't have changed that in an SRU.
<bdmurray> Laney: That still doesn't work. TypeError: Item 0: Must be number, not str
<acheronuk> Caspy7: I linked LP: #1780793 a short while back
<ubottu> Launchpad bug 1780793 in firefox (Ubuntu) "All extensions disabled in Firefox 62.0b6 on Ubuntu 18.04 LTS" [Undecided,New] https://launchpad.net/bugs/1780793
<Caspy7> thanks
<acheronuk> and pinged ricotz who is the uploader
<Caspy7> cool cool
<acheronuk> will have to see if he is around later
<Laney> bdmurray: I'm busy at a conference I'm afraid; try asking ricotz who wrote this particular change.
<seb128> willcooke, chrisccoulson, ^ could be something worth keeping an eye on
<ricotz> might be a fallout of https://bugzilla.mozilla.org/show_bug.cgi?id=1464766
<ubottu> Mozilla bug 1464766 in Add-ons Manager "Allow to relax the signature requirements" [Normal,New]
<bdmurray> ricotz: Do you have any ideas about "Vte.Terminal.feed_child()"?
<ricotz> bdmurray, 0.52.1 included an unwanted api change compared to upstream while it reverted g-i annotations
<ricotz> bdmurray, so it is a proper array parameter now https://launchpadlibrarian.net/365758293/vte2.91_0.52.1-1ubuntu1_0.52.1-1ubuntu2.diff.gz
<bdmurray> ricotz: So how would I call it?
<ricotz> bdmurray, doesnt string provide some kind of instance field
<ricotz> bdmurray, I guess: feed_child(list("\n\n"))
<bdmurray> ----> 1 term.feed_child(list("n\n"))
<bdmurray> TypeError: Item 0: Must be number, not str
<ricotz> bdmurray, or assign the string to a local var first and pass it to list
<bdmurray> like words = "n\n" and then feed_child(list(words))? I don't think that would change anything.
<ricotz> feed_child(words.to_utf8()) ?
<ricotz> ah no
<ricotz> bdmurray, you did try simple omitting the -1?
<bdmurray> ricotz: yes ----> 1 term.feed_child("n\n")
<bdmurray> TypeError: Item 0: Must be number, not str
<bdmurray> ricotz: Isn't this supposed to fix it? https://launchpadlibrarian.net/366367148/vte2.91_0.52.1-1ubuntu1_0.52.1-1ubuntu2.diff
<ricotz> bdmurray, try to find someone who know more about the python types -- https://sources.debian.org/src/sugar-pippy-activity/71~dfsg-1/pippy_app.py/?hl=540#L540
#ubuntu-devel 2018-07-10
<tsimonq2> rbasak: It seems you had a discussion about this back in March, but ~ubuntu-sponsors has been subscribed: bug 1758196
<ubottu> bug 1758196 in fdroidserver (Ubuntu) "SRU fdroidserver 1.0.8-3 (universe) to bionic from cosmic or Debian/testing (main)" [Undecided,Confirmed] https://launchpad.net/bugs/1758196
<tsimonq2> It would be great if you could take a look when you have a second.
<ricotz> acheronuk, the firefox 62 beta7 build will fix the problem
<acheronuk> ricotz: great. thanks. :)
<rbasak> tsimonq2: I commented on the bug
<mdeslaur> juliank: hi! do you have a libgcrypt merge planned soon?
<juliank> mdeslaur: no, but I can do that now
<mdeslaur> juliank: awesome, thanks!
<bdmurray> juliank: Thank for opening bug 1780996, to work on it I should assign a package task to myself and then see what release it has an await trigger in correct?
<ubottu> bug 1780996 in libreoffice (Ubuntu Xenial) "Convert triggers to noawait" [Undecided,Triaged] https://launchpad.net/bugs/1780996
<juliank> bdmurray: I think that works
<juliank> JFTR for everyone else: This is a huge meta bug tracking the conversion of triggers to noawait in a ton of packages
<juliank> In the hope to make xenial -> bionic upgrades more successful
<juliank> People are welcome to join
<juliank> :D
<bdmurray> Its important to look and see if there are other changes needed in addition to just flipping the trigger though.
<juliank> yes
<juliank> We either need to flip it, or if it really needs to be await we need to add dependencies to all packages triggering
<juliank> it
 * juliank is bad at line breaks, apparently
<juliank> File triggers should generally be the most safe to convert, except for gsettings schema and some friends.
<juliank> Basically ask yourself the question: If this trigger does not get run, is the package unusable?
<juliank> or well, does not get run before the package is being configured.
<juliank> Because you do want the package to be usable when configured.
<juliank> The rule for triggering packages is: Either depend on what you're triggering or do not wait for it.
<juliank> We might not catch all of the packages triggering file triggers
<juliank> um
<Laney> Would appreciate you forwarding any changes you find back to Debian.
<Laney> at least for desktop stuff
<bdmurray> Laney: we searched for things that had already converted from await to noawait since xenial
<bdmurray> so they are presumably already fixed in Debian
<juliank> Hmm
<juliank> I think I also added some packages that are not fixed in cosmic yet
<juliank> best to check cosmic, bionic, and xenial for each package
<juliank> and mark the task as fix released or triaged accordingly
<juliank> like I did for appstream
<juliank> and libreoffice
<juliank> I'm _not_ going to do libreoffice, my bandwidth is not high enough for that
<bdmurray> Right, so looking at xpdf its the same version in bionic and cosmic and has changed to noawait so I'll set those to Fix Released.
<juliank> bdmurray: I'm using  dch -i "Convert triggers to noawait (LP: #1780996)"  for the changelog
<ubottu> Launchpad bug 1780996 in appstream (Ubuntu Xenial) "Convert triggers to noawait" [Undecided,In progress] https://launchpad.net/bugs/1780996
<juliank> and then dch -r and distro fixing
<ricotz> juliank, bdmurray, you can forward the noawait problem of libreoffice to debian too
<juliank> bdmurray: Hmm, we could also mark the already fixed ones as invalid; and then have a way to distinguish "really fixed" vs "already fixed" for forwarding purposes? Not sure.
<juliank> ricotz: it's fixed in cosmic/bionic already, so I don't think we're going to check if that's a local change or not
<juliank> especially as libreoffice is a -0ubuntu
<juliank> I think the rule is: If it's not fixed in cosmic yet, we check and forward it
<juliank> otherwise it gets annoying
<LocutusOfBorg> [16:55:59] <LocutusOfBorg> can anybody please give me an hint about libunistring and libidn build failures? they seems to be a regression in release, not happening in debian, glib related, but I can't see toolchain changes there
<smoser> bdmurray: your review of https://code.launchpad.net/~smoser/software-properties/trunk.lp-1779302-retry-recv-keys/+merge/349213 would be appreciated or *someone* to review that.
<smoser> bug 1779302
<ubottu> bug 1779302 in software-properties (Ubuntu) "should retry reading key from keyserver (in _recv_key)" [Undecided,Confirmed] https://launchpad.net/bugs/1779302
<bdmurray> smoser: I'll have a look in a bit
<bdmurray> mitya57: Do you plan on fixing sphinx for xenial?
<ricotz> juliank, you mean it is not an issue in libreoffice 6.0.3-0ubuntu1 ?
<juliank> ricotz: yes
<ricotz> so "interest-noawait" is fine?
<juliank> yes
<ricotz> ah I see
<ricotz> good
<juliank> bad are interest and interest-await, and activate, and activate-await
<juliank> well, the -await ones are explicit, so they are likely really needed.
<juliank> the ones without a suffix are await for legacy reasons
<mitya57> bdmurray: I donât have much time so if you want to fix it yourself, please do
<smoser> bdmurray: i certainlyi would not be opposed to review of https://code.launchpad.net/~smoser/ubuntu-archive-tools/package-sets/+merge/348334 also.
<mitya57> bdmurray: the relevant commit is https://salsa.debian.org/python-team/modules/sphinx/commit/e65ad395b01708fda2367030c54ef4e702d28a3b
<bdmurray> mitya57: Cool, I'll take it. There were no other changes needed?
<mitya57> bdmurray: no other changes, just changing the type worked fine
<tsimonq2> rbasak: Thank you.
#ubuntu-devel 2018-07-11
<velho> Good morning! Trying to get Gnome-Shell to build from the package manager but JHBuild wants to pull newest dependencies. How can I just build the one package with the dependencies it requries?
<velho> From package manager means apt source..
<sarnold> if you want to build it locally then something like sbuild or pbuilder is worth doing
<tsimonq2> https://wiki.ubuntu.com/SimpleSbuild
<sarnold> apt-get build-dep gnome-shell ought to install everything needed for building gnome-shell, though, i fyou just don't care about the clean reproducable thing and just want to build :)
<tsimonq2> s/apt-get/apt/ ;)
<sarnold> I've been typing apt-get for ~20 years now.. I'm not sure that habit is possible to break at this point
<tsimonq2> hehe
<velho> I'll get an error message due to libtasn1-3-bin not available, replaced by libtasn1-bin:i386 libtasn1-bin
<velho> Is it not gnome-shell what is running as defualt in Ubuntu nowdays ?
<velho> Screwing around
<velho> It was meson build
<velho> Lol
<velho> IDE / Editor choices?
<tsimonq2> Vim :P
<apw> i have just tried a cosmic dist-upgrade and am getting errors for the libperl5.26 changelog
<apw> anyone seen this ?  i am guessing it is because i have :amd64 and :i386 installed and it would need to upgrade _both_ together
<LocutusOfBorg> apw, nice
<LocutusOfBorg> you remember me this bug https://bugs.launchpad.net/ubuntu/+source/libpng1.6/+bug/1737309
<ubottu> Launchpad bug 1737309 in libpng1.6 (Ubuntu) "package libpng16-16 1.6.20-2 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libpng16-16/ANNOUNCE', which is different from other instances of package libpng16-16:amd64" [Undecided,Incomplete]
<LocutusOfBorg> that announce file changes on each release
<LocutusOfBorg> juliank, ^^ does this ring a bell?
<juliank> LocutusOfBorg: well, artful seems fine
<juliank> But there's a bug somewhere
<juliank> I mean, he had libpng16-16:i386 in 1.6.34-1 installed with libpng16-16:amd64 in 1.6.20-2 according to the log
<juliank> Probably dpkg --force-$something  -i it
<LocutusOfBorg> so should I reassign the bug too.... dpkg?
<LocutusOfBorg> I was going to stop shipping that file :)
<juliank> I don't think there is a bug, but user going crazy
<juliank> LocutusOfBorg: the file is fine
<juliank> LocutusOfBorg: I basically think he ran dpkg --force-depends -i libpng16-16 from xenial
<juliank> Because he's running apt-get install -f
<juliank> so he messed something up
<juliank> And that's not in the log, so he ran dpkg himself
<juliank> The first mention in the log of libpng16-16 is libpng16-16:i386 (1.6.34-1, automatic) being installed
<juliank> then a few transactions later it's Upgrade: libpng16-16:amd64 (1.6.20-2, 1.6.34-1)
<juliank> which is not possible, as apt would not allow amd64 1.6.20-2 to be co-installed with i386 1.6.34-1
<apw> juliank, i cirtainly didn't do that for my perl case
<juliank> apw: perl changelog is compressed non-reproducibly, that's a different problem
<juliank> apw: And it's committed to be fixed
<juliank> apw: Um, it's a symlink on i386, and a file on amd64
<juliank> apw: Just keep an eye on bug https://bugs.launchpad.net/ubuntu/+source/perl/+bug/1574351
<ubottu> Launchpad bug 1574351 in perl (Ubuntu) "package libperl5.22 5.22.1-9 failed to install/upgrade: trying to overwrite shared '/usr/share/doc/libperl5.22/changelog.Debian.gz', which is different from other instances of package libperl5.22:i386" [High,Triaged]
<LocutusOfBorg> dpkg: error processing package libpng16-16:i386 (--install):
<LocutusOfBorg>  package libpng16-16:i386 1.6.20-2 cannot be configured because libpng16-16:amd64 is at a different version (1.6.34-2)
<LocutusOfBorg> juliank, ^^ I confirm thanks
<juliank> LocutusOfBorg: I really like bug reports from users who do low-level dpkg stuff and then write bug reports if stuff fails with "i don't know any shit"
<LocutusOfBorg> looooooooooooool
<LocutusOfBorg> I didn't even think about that possibility
<juliank> I've seen quite a few of these cases.
<apw> juliank, so what does someone with that installed now do
<apw> as it is broken early enough i can't ask to get rid of it
<apw> and now i can't complete an update because it is broken
<juliank> apw: I don't really know
<juliank> apw: Perhaps you can install one of them with dpkg --path-exclude=/usr/share/doc/libperl5.26/changelog.Debian.gz?
<juliank> apw: or deleting the file seems to "work"
<apw> juliank, will give that a go, ta
<rbasak> juliank: what's the regression risk on your python-apt data changes? Have you done this without an SRU tracking bug before?
<juliank> rbasak: There is none. CI changes don't affect us at all, it's purely upstream; and fixing the Vcs URIs to be correct or the debian/gbp.conf to have the correct branch name in it is needed for tools to work properly.
<rbasak> juliank: what about changes to data/templates/Debian.mirrors etc?
<juliank> rbasak: These are automated, and just keep the mirror list up to date
<rbasak> What's the regression risk of changing the mirror list on users?
<rbasak> eg. could a user be behind a firewall with explicit rules, and now we're hitting somewhere else?
<juliank> rbasak: If you look at xenial-updates, the last upload did just that change without any tracking bug at all
<rbasak> That only answers half my question.
<juliank> rbasak: It just shows them a different list of mirrors in software-properties that reflects the reality
<rbasak> juliank: will it cause any functional runtime change without user interaction in choosing a new mirror?
<juliank> There were previous SRUs of python-apt like 1.6.1 that also updated mirror lists, but did not mention it in the changelog.
<juliank> rbasak: no
<rbasak> That sounds fine then, t hanks
<rbasak> Your choice not to use a tracking bug. But that's information that isn't obvious!
<juliank> rbasak: Well, good you asked :)
<juliank> rbasak: BTW, you probably want to ignore uploads in the queues mentioning bug trigger conversion 1780996 atm, the SRU bug likely needs a few more detaisl
<juliank> It's a stupid ~30 package SRU
<rbasak> OK, so you want me to leave them for now? IIRC I've accepted a few from you in the past, so have some background.
<juliank> rbasak: Well, if you feel that they are self-explanatory enough. There was some concern that the bug does not show how safe the conversions are
<rbasak> I get the impression that each one needs reviewing individually to make sure that await isn't actually needed.
<juliank> Which is what we do when uploading, but I have not recorded the reasoning so far
<juliank> It's a bit unusual since there's no verification that can be done here and it's highly unlikely that someone discovers a regression while in proposed
<juliank> that said, regression potential in practice is really low IMO
<juliank> There is the theoretical regression
<juliank> where your package is configured, but not usabl
<juliank> e
<rbasak> I'm interested in you documenting the reason if you're reasoning is something beyond "I looked and didn't see any reason for package A; I looked and didn't see any reason for package B, ..." :)
<juliank> But then you have apt that tells you your system is not configured yet
<rbasak> if your reasoning
<rbasak> But otherwise a general reasoning and "I looked and didn't see any reason for all these packages" is fine I think.
<juliank> qUm, appstream went wrong
<juliank> it only has the changelog entry, but not the change
<juliank> odd
<juliank> rbasak: So for glib2.0, the reason would be: "schemas" needs to be -await because tools might crash otherwise; but modules don't have to be, because they provide optional "filesystems"
<juliank> I think stuff like +interest-noawait /usr/share/icons/hicolor is obvious
<rbasak> That sort of thing would be useful to document in the bug please
<rbasak> /usr/share/icons/hicolor - agreed. Don't bother with those apart from "here's the list I reviewed that I think are obvious"
<juliank> Actually, modules would be fine to keep await
<juliank> Since modules for gio link against glib, you always get correct ordering, so converting those to noawait is not neccessary
<juliank> I think it's just a performance optimization there, as it avoids some caching runs
<rbasak> juliank: data/templates/Ubuntu.mirrors is different between your python-apt uploads in Trusty and Xenial. Intentional?
<juliank> rbasak: I think trusty is a day newer
<juliank> And one mirror went away in that time and a new one popped up at utexas
<juliank> The mirror list always reflects what launchpad reports at the time the package was uploaded
<rbasak> OK. So happy to leave as-is?
<juliank> yeah
<rbasak> juliank: nearly there :-/
<rbasak> juliank: in Xenial, "python/tag.cc: Fix invalid read in TagFileNext" and I see the corresponding diff hunk. Shouldn't that have a separate SRU tracking bug?
<rbasak> (and get SRU verification, etc)
<juliank> rbasak: It probably should have had one, but I did not have anything to verify :/
<juliank> We just saw some weird crash reports in the error tracker some time ago
<juliank> but it's not really reprodubible
<rbasak> I think that's OK, but should be documented.
<rbasak> Maybe just put that explanation in the one bug we have for this time, please?
<juliank> rbasak: yes
<juliank> rbasak: Added
<rbasak> Thanks!
<rbasak> LocutusOfBorg: around? Your virtualbox upload seems unreviewable (huge diff) and doesn't appear to meet the criteria under https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
<LocutusOfBorg> rbasak, I already did the microreleases 4 times for vbox, should I copy-paste the same?
<LocutusOfBorg> we upgraded from 5.0 to 5.1, the diff was around 10MB :D
<rbasak> LocutusOfBorg: looks like you run into this every time? Eg. https://bugs.launchpad.net/ubuntu/+source/virtualbox/+bug/1746316/comments/5
<ubottu> Launchpad bug 1746316 in virtualbox-guest-additions-iso (Ubuntu Artful) "[SRU] VirtualBox needs Security Patches" [Undecided,Fix released]
<rbasak> LocutusOfBorg: what we expect is all the SRU information already in the bug before you upload.
<rbasak> LocutusOfBorg: and sure, copying and pasting it is fine.
<LocutusOfBorg> ack wilco
<LocutusOfBorg> done I guess, I have many people reporting that the version in unapproved fixes the issue
<LocutusOfBorg> even if the diff looks big, it is really a couple of changes and lots of autogenerated stuff :)
<rbasak> LocutusOfBorg: was this a previous SRU regression?
<rbasak> LocutusOfBorg: I'm still not seeing "The upstream QA process must be documented/demonstrated and linked from the SRU tracking bug" from https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases
<rbasak> If you want to push this as a wholesale microrelease update then please review that part of the policy.
<LocutusOfBorg> rbasak, yes, probably an SRU regression due to the new feature being enabled incorrectly
<LocutusOfBorg> unfortunately it fixed lots but not all the issues
<LocutusOfBorg> (the enabling of the feature was to fix the 3d guest, due to the new mesa drivers -hwe, something I have been forced to enabled because of new mesa)
<LocutusOfBorg> so, a regression due to somebody else I would say :p
<mapreri> hey, I've tried to trigger an autopkgtest against my own PPA, with request.cgi/?release=cosmic&arch=amd64&package=dgit&ppa=mapreri%2Fppa&trigger=dgit%2F5.8%2B0ppa0 - but now the result url keeps returning me 401, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic-mapreri-ppa/?format=plain - The test finished nearly 2 hours ago, so I guess everything ought to be already updated
<mapreri> what am I doing wrong?
<mapreri> (feel free to redirect me to any better fora if there are any)
<velho> Who
<velho> is responsible for gnome-shell dev for ubuntu?
<rbasak> velho: I suggest you ask your real question as nobody is going to volunteer for you like that. Also try #ubuntu-desktop depending on what your question is.
<velho> rbasak: Yea was too lazy to open launchpad
<rbasak> LocutusOfBorg: please sort out the SRU information according to https://wiki.ubuntu.com/StableReleaseUpdates#New_upstream_microreleases. Separately, what in the SRU verification process do we need to change to catch this kind of regression in future?
<LocutusOfBorg> rbasak, changes were done by mesa folks, and one other incompatibility was in kernel hwe
<LocutusOfBorg> my suggestion is: add virtualbox and vagrant to the list of stuff that needs testing when new kernel or mesa are -hwe added
<LocutusOfBorg> see e.g. LP: #1736116
<ubottu> Launchpad bug 1736116 in virtualbox-guest-additions-iso (Ubuntu Artful) "[SRU] Host with kernel 4.13 freezes when starting a VM with VirtualBox" [High,Fix released] https://launchpad.net/bugs/1736116
<seb128> cjwatson, wgrant, is cosmic open for translations yet? I can see the strings/translate them but some other translators apparently get a msg telling them that the serie is not open
<cjwatson> seb128: We should probably do the rest of https://wiki.canonical.com/Launchpad/Translations/UbuntuOpenings, yes
<seb128> cjwatson, I guess that means the opening is not fully done yet and I see the UI because I'm part of a team that has early access?
<cjwatson> You're a translation admin
<seb128> k, I didn't know that had an impact on the UI
<seb128> cjwatson, thanks
<cjwatson> Let me see if I can at least sort out the cron schedule ...
<seb128> thx
<LocutusOfBorg> rbasak, I think I updated it
<cjwatson> seb128: langpack cron job exists now and is 30 10 * * 2 for cosmic (i.e. previously the zesty schedule).  The next step on the checklist says that you (i.e. ~ubuntu-langpack) should adjust the langpack build scripts crontab to match
<seb128> cjwatson, k, I can do that, thx
<seb128> cjwatson, done
<cjwatson> seb128: Thanks.  Now I think we wait until early next week for the first export to happen, and if it looks sensible we can open translations
<seb128> cjwatson, sounds good, thx
<bdmurray> juliank: I ran another search for cosmic triggers and noticed bumblebee changed from its activate update-initramfs to activate-noawait. Is that worth fixing too?
<juliank> bdmurray: Yes, I think sdo
<bdmurray> juliank: Okay, doing so.
<bdmurray> Hrm, I've added a bumble task but there are no distro-series tasks.
<juliank> Launchpad bug!
<bdmurray> Looking at bug 1750465 there should be a budgie-artwork xenial task too but there isn't.
<ubottu> bug 1750465 in ubuntu-mate-artwork (Ubuntu Xenial) "upgrade attempting to process triggers out of order (package plymouth-theme-ubuntu-text 0.9.2-3ubuntu17 failed to install/upgrade: dependency problems - leaving triggers unprocessed)" [High,Confirmed] https://launchpad.net/bugs/1750465
<juliank> cjwatson: ^ 1780996 is missing tasks for xenial, bionic
<juliank> for bumblebee
<juliank> bug in launchpad?
<juliank> and that other thing
<cjwatson> bdmurray: Not sure, did you add this using the API?
<cjwatson> Can't really look right now, but these sorts of giant bugs affecting a bazillion packages are usually a bad idea
<bdmurray> cjwatson: No, I just added the bumblebee task via the web interface.
<juliank> bdmurray: in the other bug, the xenial task was removed by fossfreedom
<juliank> no longer affects: budgie-artwork (Ubuntu Xenial)
<bdmurray> Ah, that package doesn't exist in Xenial - okay.
#ubuntu-devel 2018-07-12
<tsimonq2> rbasak: How was that importer/snap store deployment coming along? :)
<juliank> Trying to db_subst a multi-line string into a template, any ideas?
<juliank> db_capb escape apparently
<LocutusOfBorg> ginggs, ^^ see above for the perl issue
<rbasak> tsimonq2: deployed now and I think your lubuntu list might be up to date.
<rbasak> tsimonq2: I'm not sure if there were errors though. If there are any seemingly missing, please could you let me know?
<rbasak> We still have some classes of import errors. I have bugs for all the ones I know about (tagged import-edge-case).
<rbasak> cyphermox: could you review the latest patch in bug 1661629 please? It seems reasonable to me, but I'm not confident enough in this area to drive it directly.
<ubottu> bug 1661629 in initramfs-tools (Ubuntu) "upgrade of kernel fails with mkinitramfs: failed to determine device for /" [Undecided,Confirmed] https://launchpad.net/bugs/1661629
<rbasak> It might be that you're willing to upload it.
<cyphermox> ok
<adriano1816> Hello everyone
<adriano1816> Could someone help me to compile a driver?
* bryanostergaard changed the topic of #ubuntu-devel to: Hey, I think you guys might enjoy my new blog post https://bryanostergaard.com/blog/2018/07/09/donald-trump-and-the-darkies/
* cjwatson changed the topic of #ubuntu-devel to: Archive: open (Cosmic Cuttlefish) | 18.04 released | Devel of Ubuntu (not support) | Build failures: http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of Trusty-Bionic
<smoser> bdmurray: i followed up to https://code.launchpad.net/~smoser/software-properties/trunk.lp-1779302-retry-recv-keys/+merge/349213 . when you get a chance might be nice.
<bdmurray> smoser: I saw but am heading out for a long weekend. Can it wait until Monday?
<smoser> yeah. have a nice weekend.
<bdmurray> smoser: thanks, you too!
<tsimonq2> rbasak: Thanks.
#ubuntu-devel 2018-07-13
<ahasenack> hi, I'm trying to bring a package to standards version 4.1.5 (it's at 4.1.4), and one of the changes is the FHS version, which went from 2.3 to 3.0
<ahasenack> I couldn't find a list of changes in the fhs corresponding to that version dump, so it's hard to see if I'm affected or not
<ahasenack> any tips?
<cjwatson> ahasenack: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787816 has a link (some way down) to https://web.archive.org/web/20160624022300/wiki.linuxfoundation.org/en/FHSReleaseNotes30
<ubottu> Debian bug 787816 in debian-policy "Replace FHS 2.3 by FHS 3.0 in the Policy." [Normal,Fixed]
<ahasenack> thanks cjwatson
<cjwatson> you may find other useful things in that Debian bug
<ahasenack> will check, thanks
<LocutusOfBorg> nobody wants to help me understanding the "libunistring" failure? also libidn has similar issues
<LocutusOfBorg> same version was building good in artful
<LocutusOfBorg> and is now FTBFS in bionic
<doko> oSoMoN: any idea why python3-uno cannot be installed ? let's the lo autopkg tests fail
<oSoMoN> doko, looking
<oSoMoN> doko, not sure what happened, the dependency error doesn't make much sense, I've triggered a re-run
<oSoMoN> doko, the same autopkgtest on arm64 failed again, but with a different error, suggesting that the testbed is out of date
<oSoMoN> I suppose waiting for a few hours and re-running will make the issue go away
<sarnold> slangasek: (since bdmurray's out today) https://bugs.launchpad.net/ubuntu/+bug/1781663 -- looks like the python3-minimal bug that caused my upgrade to go so poorly :/
<ubottu> Launchpad bug 1781663 in Ubuntu "Can't use keyboard on "what would you like to do" "Run Ubuntu in low-graphics mode for just one session" menu " [Undecided,New]
<Unit193> Wouldn't LP #1636666 be holding up https://ftp-master.debian.org/new/php7.3_7.3.0~alpha3-1.html now? :)
<ubottu> Launchpad bug 1636666 in pcre2 (Ubuntu) "[MIR] pcre2" [Undecided,Incomplete] https://launchpad.net/bugs/1636666
<sarnold> pcre2 :(
<Unit193> Eh, better than the alternative of breaking vte.
<Unit193> ...And qt bundling it anyway.
<sarnold> I'm just .. grumpy / bitter / dissapointed that we have libraries like the rust regex crate or the re2 engine in go that are memory safe and fast and don't suffer from exponential catastrophe when someone searches for aaaaa*b ..
<sarnold> .. and instead we've got pcre2 with a steady stream of heap overflows and so on for *years* ..
<Unit193> Ah, understandable but that only helps rust and golang.  (I completely understand being bitter, I'm at that state with vte and pcre right now too.  At this point I'd prefer to sync vte and drop it from main.)
<sarnold> I wonder.. how much effort it'd be to expose rust's regex via C.
<sarnold> of course it doesn't do backreferences so it's not a perfect replacement for every use -- that's how they avoid exponential blowup
<slangasek> sarnold: I am also out today; if the python3-minimal fix was released yesterday, that could be the same bug but hit due to race condition with mirrors
<sarnold> slangasek: ah! my apologies, thanks for giving it a look
#ubuntu-devel 2018-07-15
<fooctrl> are there any news when kernel will be updated in Cosmic to i.e: 4.18?? it's still on 4.15
<tsimonq2> fooctrl: Perhaps asking in #ubuntu-kernel (and waiting for a response) would be a good idea.
<fooctrl> tsimonq2, thanks, will do
<tsimonq2> fooctrl: Looks like 4.17 is in the works right now.
<tsimonq2> fooctrl: https://launchpad.net/ubuntu/+source/linux%2Dmeta
<tsimonq2> fooctrl: But ofc they'll have more info than I do. :)
<fooctrl> tsimonq2, great thanks this was already very useful :)
<tsimonq2> :D
<Bluefoxicy> are there any plans at all to upgrade to the latest Monodevelop (7.5 is out; the version from 14.04 is STILL in 18.04)
<Bluefoxicy> like, ever?
<Bluefoxicy> or is C#/.NET basically abandoned in Ubuntu
#ubuntu-devel 2019-07-08
<oSoMoN> can someone with upload rights for kopano-webapp trigger an autopkgtest run for eoan/amd64 ? I'd like to verify that my chromium snap patch fixed bug #1834052 indeed
<ubottu> bug 1834052 in chromium-browser (Ubuntu) "autopkgtest failures: Chromium-Related in Tests" [Medium,Fix released] https://launchpad.net/bugs/1834052
<seb128> LocutusOfBorg, hey, did you see that your iputils upload has a autopkgtest issue?
<Unit193> Debian 931491
<ubottu> Debian bug 931491 in src:iputils "iputils: FTBFS in sid (missing dependency on setcap)" [Serious,Fixed] http://bugs.debian.org/931491
<seb128> Unit193, was that supposed to in reply to what I wrote?
<Unit193> seb128: Sorry, not precisely.  It was referenced in the Debian changelog, that's the remaining delta in Ubuntu.
<seb128> Unit193, I'm unsure what you are trying to tell me there?
<Unit193> seb128: Heh, don't mind it.  It's only loosely related.
<seb128> Unit193, I was pointing out the iputils entry on https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses_by_team.html#desktop-packages
<seb128>     newpid/10: amd64 (log, history), armhf (log, history), i386 (log, history), ppc64el (log, history), s390x (log, history)
<seb128> Unit193, our upload didn't fail to build/doesn't have that Debian FTBFS and I don't know about the delta with Debian :)
<seb128> but thx for the info still? :)
<Unit193> G'morning, anyway. :)
<seb128> indeed! :)
<Gargoyle> Mornin'
<Gargoyle> Laney: Can I DM you sometime today re the Desktop Software Engineer role?
<Laney> Gargoyle: Yes, but don't hang around too long
<LocutusOfBorg> to answer seb128, I'm in contact with upstream wrt iputils, since some days :D
<Unit193> You can't answer him, he left.
<LocutusOfBorg> hopefully he might read backlog anyway :)
<LocutusOfBorg> or I can just repaste once he is back
<Unit193> seb128: < LocutusOfBorg> to answer seb128, I'm in contact with upstream wrt iputils, since some days :D
<LocutusOfBorg> that one :) that was the reason lol
<LocutusOfBorg> seb128, I don't want to "just update the test with "ping:" before the other expected result, because such changes easily break userspace applications when they are parsing tools' outputs
<LocutusOfBorg> so, better ask upstream before uploading
<LocutusOfBorg> same for postgresql-11 ppc64el and s390x test failures
<LocutusOfBorg> stgraber, hello, there is a question on #release channel for you... wrt docker.io and i386 test failure
<seb128> LocutusOfBorg, right, I was just checking you saw it since those don't trigger notifcations (out of the 'is for <n> days in proposed')
<LocutusOfBorg> seb128, thanks, I usually open a browser tab when I upload, so I don't miss them, but sometimes they require some more time :)
<LocutusOfBorg> seb128, thanks, I usually open a browser tab when I upload, so I don't miss them, but sometimes they require some more time :)
<LocutusOfBorg> I usually miss them in SRUs :)
<LocutusOfBorg> but thanks for the ping, it is always appreciated!
<seb128> yw! thx for follow up with upstream on the issue :)
<oSoMoN> xnox, would you mind triggering again http://autopkgtest.ubuntu.com/packages/kopano-webapp/eoan/amd64 ? I'd like to make sure my chromium snap fix did the trick
<LocutusOfBorg> oSoMoN, I did it :)
<oSoMoN> oh, thanks!
<Laney> oSoMoN: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/k/kopano-webapp/20190708_085852_354bf@/log.gz \o\ /o/
<oSoMoN> \o/
<oSoMoN> thanks Laney
<Laney> well done
<oSoMoN> Laney, can you revert https://bazaar.launchpad.net/~ubuntu-release/britney/hints-ubuntu/revision/3744 ?
<Laney> yes!
<Laney> (how do you revert in bzr?)
<oSoMoN> bzr merge . -r 3744..3743 IIRC
<oSoMoN> or something like that
<Laney> bzr merge . -r3744..3743
<Laney> works
<oSoMoN>  cheers
<ricotz> sil2100, hi, debian/control wasn't updated in rustc - 1.35.0+dfsg0.1+llvm-0ubuntu1~ppa1
<sil2100> ricotz: I know, just re-uploaded
<ricotz> good
<ddstreet> juliank any chance you had time to start review on https://code.launchpad.net/~ddstreet/software-properties/+git/software-properties/+merge/367276
<ddstreet> let me know if you have any feedback
<juliank> ddstreet: Not yet, I forgot about it, I added a trello card to keep track of it now
<ddstreet> thanks
<jackpot51> The new AMD Ryzen 3000 series processors are out, and there are serious issues on Ubuntu versions newer than 18.04: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1835809
<ubottu> Launchpad bug 1835809 in systemd (Ubuntu) "AMD Ryzen 3000 series fails to boot" [Undecided,New]
<sumitcn> where is the .css file where I can change the purple color of ubuntu to black
<sumitcn> anyone ?
<tfgbd_> Why does Ubuntu crash on my PC
<tomreyn> also the wrong place, see /topic
<CarlFK> tomreyn: -Disco needs updating ;
<tfgbd_> I'm using mint now
<tomreyn> CarlFK: why?
<cjwatson> That range has classically been the currently-supported versions, as opposed to the in-development version (which at least used to be directed to #ubuntu+1), so -Disco seems correct
<tomreyn> and surprisingly there's no topic protection on this channel
<cjwatson> Sometimes we +t if there's an active problem, otherwise wiki-style lets people be useful
<cjwatson> It's mostly not a big deal
<tomreyn> i like it (as long as it's not getting abused)
<kyrofa> Hey cjwatson, how often do you folks typically go through the proposed unapproved queue? We have a no-change rebuild to python-pygraphviz that we've very much like to get in
<cjwatson> kyrofa: I don't at all, it hasn't been adjacent to my duties for over four years
<cjwatson> Ask somebody else :)
<cjwatson> (I'm still in ~ubuntu-sru for vestigial tool maintenance reasons but don't actually do SRU processing)
<kyrofa> Ah, okay
<kyrofa> Just curious if there's some sort of established process for this, I guess
<kyrofa> Some of those have been there a while
<cjwatson> There may well be, I know there's been some kind of recently instituted regular team meeting to try to get through things, but honestly I'm pretty out of the loop
<cjwatson> Sometimes process or no process there just isn't enough time ...
<CarlFK> tomreyn: opps, my bad.  I thought Eoan was released.  never mind
<kyrofa> Darn, I hate annoying people :(
<kyrofa> vorlon, can you help me get insight to how the unapproved queue is handled? We have a no-change rebuild to python-pygraphviz queued up for bionic
<vorlon> kyrofa: it is roughly FIFO, with no particular SLA on time to review, and if you have something urgent you should ping the SRU team member du jour listed on https://wiki.ubuntu.com/StableReleaseUpdates#Publishing
<kyrofa> vorlon, ah excellent, I thought that was only once it was verified, missed that it also covered unapproved, thank you
#ubuntu-devel 2019-07-09
<seb128> vorlon, retrying n-m autopkgtests isn't going to work, the log is having those kernels errors that seem the issue/a fallout from the new gcc
<seb128>  error: â-mindirect-branchâ and â-fcf-protectionâ are not compatible
<seb128> (e.g https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/i386/n/network-manager/20190708_231002_6fa4a@/log.gz)
<seb128> also dkms/nvidia drivers seem broken now, would be good to have some autopkgtest to prevent gcc migrating if it breaks drivers next time maybe?
<seb128> doko, ^
<seb128> vorlon, the n-m warnings look like bug #1835764
<ubottu> bug 1835764 in virtualbox (Ubuntu) "Multiple DKMS kernel drivers fail to build with gcc-9 [error: â-mindirect-branchâ and â-fcf-protectionâ are not compatible]" [Critical,Confirmed] https://launchpad.net/bugs/1835764
<doko> seb128: please see the announcement from amurray and contact the security team for the hardening changes
<seb128> doko, what announcement de amurray?
<seb128> from*
<amurray> seb128: https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040741.html
<seb128> amurray, ah, thanks, that's some week old and scrolled out from my first page
<seb128> doko, would have been nice to include a reminder to that one in your gcc transition email, maybe a tip for next time :)
<seb128> since that only got active with the gcc change
<amurray> the best fix for this would be to update the eoan kernel to add -fcf-protection=none I think
<amurray> seb128: it *should* have been in gcc-8 already
<seb128> amurray, doko, it seems a bit backward to have landed the changes before fixing the kernel
<seb128> now we are in a situation were drivers are broken on eoan archive
<seb128> nothing even blocked that breakage to limit it to proposed :-/
<doko> dude, the kernel team is just binary copying kernels to eoan, and yes, they know about that
<amurray> seb128: apologies, it slipped off my radar with some embargoed security stuff which just went out the door
<seb128> what has how they upload to do with that?
<seb128> amurray, no worry, I just wodner if we need some sort of autopkgtest to avoid having $things  migrated when dkms gets screwed next time
<amurray> doko: oh well that fixes my mental model then - I was wondering why the eoan kernel builds weren't failing as well but if they are being done on disco gcc that would make sense
 * amurray will look at cooking up something for the eoan kernel and will discuss with kernel-team
<doko> ta
<seb128> amurray, thx
 * seb128 brb, need to change location for a meeting
 * amurray dinner etc - back later
<seb128> cyphermox, hey, what's the status of the grub2 buildfix for eoan? any chance that lands this week?
<sladen> bout time
<Unit193> Hrm, it seems to me when you select a compressor in /etc/initramfs-tools/initramfs.conf, mkinitramfs shouldn't silently bail if the compressor is missing.
<Unit193> Something like http://paste.openstack.org/show/M6SOlCnADce7eUXS1W4c
<seb128> powersj, hey, unsure if you are the right person to ping about that but do you know if daily ISO utah test env is having issue? seems like bionic/eoan test are bailing out on an error 7
<rbasak> Could someone review https://code.launchpad.net/~racb/ubuntu-transition-tracker/mysql-8/+merge/369878 please? I've not done this before, and I can't figure out how to test locally (seems that ben can't download from Ubuntu and the go script is a workaround but not suitable for use outside the machine it runs on)
<rbasak> paride: see seb128's question from about an hour ago please - can you help? ^
<paride> seb128, oh yes jibel and me were looking at the issue
<paride> seb128, error 7 is defined as a command line parsing error, but it seems that what's actually happen is that a URLChecker method is failing, probably because of networking issues
<paride> and the error is deceptive
<paride> (thanks rbasak for the ping)
<seb128> rbasak, paride, thx! do you know what needs to be done?
<paride> seb128, looks like it's back to normal, but let me re-launch another couple of jobs manually
<seb128> paride, thx
<seb128> paride, I'm curious but what part of the log hinted out that it was an infra issue? just the knowledge of what is behind error7 ? (can you point me to where those are defined?)
<paride> seb128, the log wasn't really useful. We observed a couple of things: (1) nothing was changed on venonat, utah, or the job definitions (2) the build didn't always fail, but they were very flaky (3) utah took a long time to parse its arguments, hinting it was trying to do something over the network (4) there is this URLChecker class which the parser
<paride>  uses to check if the URL which are passed to UTAH are valid, but which actually makes things more difficult to debug
<paride> and so that's what we're blaming and why
<seb128> paride, k, thx for the details, let's see how the retries goes then!
<paride> seb128, if you want to have a look, `git clone lp:utah`, grep URLChecker and follow it back
<seb128> k
<seb128> thx!
<paride> yw!
<seb128> paride, seems it worked, I got 'back to normal' emails for bionic and eoan now ;-)
<seb128> and the pending ISO migrated to be current
<paride> excellent :)
<rbasak> Could someone review https://code.launchpad.net/~racb/ubuntu-transition-tracker/mysql-8/+merge/369878 please? I've not done this before, and I can't figure out how to test locally (seems that ben can't download from Ubuntu and the go script is a workaround but not suitable for use outside the machine it runs on)
<Laney> rbasak: it looks reasonable, I suggest just committing it and seeing what happens
<rbasak> Laney: thanks!
<cyphermox> seb128: I have the fix staged, I'm finishing up on testing the new grub post-merge
<seb128> cyphermox, ok, so likely this week?
<cyphermox> yes, likely
<seb128> ups
<seb128> cyphermox, great :)
<seb128> cyphermox, oh, also what's the status for the plymouth patches upstreaming/new version update from your side? I had it on my june backlog but failed to got to it, I plan to try again this month!
<kenvandine> vorlon: can you please promote xdg-desktop-portals and xdg-desktop-portals-gtk in bionic per bug 1750069 and bug 1749672
<ubottu> bug 1750069 in xdg-desktop-portal-gtk (Ubuntu Bionic) "[MIR] xdg-desktop-portal-gtk" [Undecided,Triaged] https://launchpad.net/bugs/1750069
<ubottu> bug 1749672 in xdg-desktop-portal (Ubuntu Bionic) "[MIR] xdg-desktop-portal" [High,Triaged] https://launchpad.net/bugs/1749672
<kenvandine> vorlon: i'm trying to update the seed now, but Laney said i need them promoted first
<cyphermox> seb128: I have not yet had time to look at plymouth this cycle
<seb128> cyphermox, do you think you are going to be able to squeeze some time for that in the next weeks?
<seb128> cyphermox, I will try to have a go at that update since we would like to see the new version in but let me know if you start poking as well so we don't dup work
<LocutusOfBorg> xnox, hello, your dh-cargo merge il blocking a bunch of rust packages...
<ahasenack> doko: dealing with some gcc9 fallout,
<ahasenack> doko: stuff like this: https://pastebin.ubuntu.com/p/nSBdGN3xy4/ and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780
<ubottu> gcc.gnu.org bug 88780 in middle-end "[8/9/10 Regression] bogus -Wstringop-truncation for copying as many bytes from a string as its length" [Normal,Assigned]
<ahasenack> doko: googling brought up https://bugs.squid-cache.org/show_bug.cgi?id=4969, is that a thing for gcc9?
<ahasenack> er, switch the bugs, "is that a thing" is the gcc bug
<ahasenack> let me refrase
<ahasenack> doko: stuff like this: https://pastebin.ubuntu.com/p/nSBdGN3xy4/ and https://bugs.squid-cache.org/show_bug.cgi?id=4969
<ahasenack> doko: googling brought up https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88780, is that a thing for gcc9?
<ubottu> gcc.gnu.org bug 88780 in middle-end "[8/9/10 Regression] bogus -Wstringop-truncation for copying as many bytes from a string as its length" [Normal,Assigned]
<doko> ahasenack: are you seeing this with GCC 9 only? according to the report it should be in 8 as well
<ahasenack> yeah, the squid build works with gcc8
<ahasenack> the gcc 9 release notes say that this stringop-truncation check was expanded a bit
<ahasenack> I'm still digging, for example, it only happened with -O2 or higher
<doko> well, -Wno-error=stringop-truncation is your friend ...
<ahasenack> with just -Wall -Werror -Wstringop-truncation it works, but if I add -O2 then it fails
<vorlon> seb128: hopefully the new kernel in eoan-proposed has fixed this - I'm retrying those nm tests with --all-proposed to see
<vorlon> kenvandine: bionic only, or both bionic and xenial?
<kenvandine> please promote both
<kenvandine> vorlon: i haven't prepared the seed for xenial yet, but i will be this week
<vorlon> kenvandine: also, it is normally the case that we add things to seeds /first/ and then change the archive, so that we can use component-mismatches as a guide for what needs promoting; we don't generate c-m reports for !devel, but I'm not sure why it should be promoted before the seed change anyway
<kenvandine> the update script won't find it
<vorlon> update script?
<kenvandine> Laney said we need to promote it first
<kenvandine> in ubuntu-meta
<vorlon> oh, you do need to promote it before reuploading ubuntu-meta, yes
<kenvandine> yes
<vorlon> but the ordering is (normally) seed change -> archive promotion -> ubuntu-meta upload
<kenvandine> right, for devel
<seb128> vorlon, thx
<vorlon> kenvandine: the xdg-desktop-portal dependencies look a bit strange on xenial; Depends: default-dbus-session-bus | dbus-session-bus | dbus-x11 but only the third of these exists in the release
<kenvandine> yeah
<kenvandine> there are other packages in xenial that followed that pattern as well
<kenvandine> so the packaging matched debian, for example
<vorlon> mm
<kenvandine> i can change it
<vorlon> anyway, promotions done on both series
<kenvandine> thanks
<GunnarHj> bdmurray: Just replied to your question at bug #1834406. Any other idea how to reach out to CJK users willing to help out?
<ubottu> bug 1834406 in fonts-noto-cjk (Debian) "Upgrade Noto Sans CJK fonts to version 2.001" [Unknown,New] https://launchpad.net/bugs/1834406
<bdmurray> GunnarHj: I think the ubuntu-quality list used to be used for calls for testing but I'm not sure how active that list is now
<GunnarHj> bdmurray: I don't know either, but that's an idea. Do you think the statements so far are insufficient, so I should try that way? (Personally, and unlike my last dubious SRU proposal, I feel this is a safe one.)
<bdmurray> GunnarHj: I was following along with sil2100's comment.
<bdmurray> https://bugs.launchpad.net/ubuntu/+source/fonts-noto-cjk/+bug/1834406/comments/4
<ubottu> Launchpad bug 1834406 in fonts-noto-cjk (Debian) "Upgrade Noto Sans CJK fonts to version 2.001" [Unknown,New]
<GunnarHj> bdmurray: Right, and that's the reason for the efforts so far.
<bdmurray> GunnarHj: Okay, I'd asked about the call for testing because I wasn't sure what calls had been made.
<bdmurray> GunnarHj: Either way let's give it a bit more time to age though.
<GunnarHj> bdmurray: Sure, no problem. The new era started May 1, so it's late anyway.. TBH I would have expected some Japanese users to act as drivers to have it tested, so I'm a bit disappointed.
<GunnarHj> bdmurray: Maybe it would help if you added a comment to the bug about the decision to wait a bit due to few test reports?
<Unit193> LocutusOfBorg: Ah, you already commented on the opensips report, was just about to do that now.  Very well then.
#ubuntu-devel 2019-07-10
<LocutusOfBorg> Unit193, yes, because I want to do the debian transition asap
<Unit193> Heh, it was on the TODO for today, but thanks!  (I closed a couple other Debian bugs in the meantime, so all's good)
<LocutusOfBorg> doko, https://launchpadlibrarian.net/432385023/buildlog_ubuntu-eoan-armhf.sbcl_2%3A1.5.4-1_BUILDING.txt.gz
<LocutusOfBorg> cc: error: unrecognized -march target: armv5
<LocutusOfBorg> cc: note: valid arguments are: armv4 armv4t armv5t armv5te armv5tej armv6 armv6j armv6k armv6z armv6kz armv6zk armv6t2 armv6-m armv6s-m armv7 armv7-a armv7ve armv7-r armv7-m armv7e-m armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a armv8.5-a armv8-m.base armv8-m.main armv8-r iwmmxt iwmmxt2 native; did you mean 'armv4'?
<LocutusOfBorg> is that normal?
<LocutusOfBorg> looks like it is https://www.phoronix.com/scan.php?page=news_item&px=GCC-9-Dropping-Older-ARM
<LocutusOfBorg> maybe armv7 is the correct replacement?
<doko> LocutusOfBorg: armhf is armv7 both in Debian/Ubuntu
<doko> amurray, apw, infinity: https://bugs.launchpad.net/ubuntu/+source/gcc-9-cross/+bug/1836045  I haven't figured out the root cause yet. for now just rebuilding the c-t-b packages
<ubottu> Launchpad bug 1836045 in gcc-9-cross (Ubuntu) "ftbfs: gnat cross targeting powerpc" [High,Confirmed]
<doko> infinity, apw: also https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1836064
<ubottu> Launchpad bug 1836064 in linux (Ubuntu) "linux-5.2 (?) breaks the c-t-b builds" [Undecided,New]
<apw> sforshee, ^
<sforshee> doko: I reponded on bug 1836064, looks like glibc has a fix upstream for that
<ubottu> bug 1836064 in linux (Ubuntu) "linux-5.2 (?) breaks the c-t-b builds" [Undecided,New] https://launchpad.net/bugs/1836064
<sforshee> doko, infinity, amurray: while on the topic of kernel headers changes breaking glibc, I had also filed bug 1830044 a while back
<ubottu> bug 1830044 in glibc (Ubuntu) "glibc 2.29-0ubuntu2 ADT test failure with linux 5.2.0-0.1" [Undecided,New] https://launchpad.net/bugs/1830044
<doko> sforshee: any idea about the powerpc constants?
<sforshee> doko: looking
<Laney> what's up with this dkms breakage? e.g. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan/eoan/amd64/o/oss4/20190708_225935_da9bd@/log.gz which is https://paste.ubuntu.com/p/QXfgjvDDnM/
<doko> Laney: duflu asked about that yesterday ...
<Laney> doko: unfortunately we aren't the same person :(
<doko> well, it was on #u-d: https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040741.html
<doko> -desktop even
<Laney> I've seen the announcement
<Laney> is it expected that it breaks builds?
<doko> yes
<doko> anything that is not user space
<Laney> might it be worth calling this out?
<Laney> I see oss4-dkms and fwts-efi-runtime-dkms so far looking at the glib2.0 autopkgtest regressions
<doko> don't call me, I'm neither security nor kernel
<Laney> & are we expected to fix this or turn the flag off? if the latter, could dkms do that for us?
<Laney> https://launchpadlibrarian.net/432423025/nvidia-graphics-drivers-430_430.26-0ubuntu2_430.26-0ubuntu3.diff.gz I see that tseliot1 turned it off there
<Laney> amurray: ^---
<tseliot> I don't know if my message showed up, so I am going to write it again
<tseliot> doko: did you notify the kernel team before making that change?
<doko> tseliot: not my area, please ask security
<doko> amurray: ^^^
<doko> tseliot: did the kernel team notify ubuntu-devel before uploading 5.2?
<tseliot> doko: I don't deal with kernel releases. I only fix the nvidia dkms packages when they fail to build against a new kernel (usually, either in our PPA or in -proposed)
<tseliot> doko: also, I don't see the point of that question, since I can reproduce the problem with Linux 5.0
<sforshee> tseliot: the kernel in -proposed add -fcf-protection=none to the kernel's retpoline flags to fix the issue, I've sent a patch upstream too
<doko> tseliot: and I don't see the point why you are asking me ...
<tseliot> sforshee: ok, that's good. Is that only for 5.2? (just so I know when I shouldn't apply my patch)
<doko> something broken, must be doko ...
<tseliot> doko: because of your name in the changelog? https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1830961/comments/14
<ubottu> Launchpad bug 1830961 in virtualbox (Ubuntu) "Kernels & kernel drivers fail to build with gcc-9 [error: â-mindirect-branchâ and â-fcf-protectionâ are not compatible]" [Critical,Confirmed]
<sforshee> tseliot: so far it's only applied to 5.2, I'm not sure there's a reason to apply it to 5.0 now that 5.2 is in eoan-proposed
<doko> tseliot: please read amurray's email about the hardening flags
<Laney> sforshee: oho, so it should fix itself when that migrates?
<sforshee> Laney: yes
<Laney> nice
<tseliot> sforshee: ok, I'll drop the patch when that is in then, thanks
<tseliot> doko: I saw his email now. I imagine our testing framework caught the dkms failures with the new gcc, maybe when it was already in. Anyway, I'm glad it will be fixed soon.
<doko> sforshee: do a fgrep -r SO_RCVTIMEO, for the 5.0 and 5.2 sources. It looks like all archs except powerpc were updated ...
<seb128> bdmurray, hey, on bug #1551623 the submitter replied to your comment pointing to a dpkg fix for triggers, maybe that would make sense to get instead (and SRU), can you get that one on the foundations agenda to discuss?
<ubottu> bug 1551623 in gconf (Ubuntu) "[SRU] package gconf2 3.2.6-3ubuntu6 failed to install/upgrade: dependency problems - leaving triggers unprocessed" [Critical,Triaged] https://launchpad.net/bugs/1551623
<bdmurray> seb128: Will do, thanks!
<seb128> bdmurray, thx!
<seb128> xnox, bug #1835968 claims to be a regression from your openssl 1.1 patch/SRU
<ubottu> bug 1835968 in ruby2.5 (Ubuntu) "Regression in backported patch for openssl 1.1" [Undecided,New] https://launchpad.net/bugs/1835968
<seb128> bdmurray, I never know, what's the best way to flag SRU regressions?
<seb128> just tagging the bug?
<seb128> that doesn't ping the SRU team members though right? e.g doesn't lead to have the bug reviewed in priority to decide what's the next action needed?
<bdmurray> seb128: I think vorlon and I are both subscribed to regression-update tagged bug reports.
<seb128> ah ok, I didn't even know you could subscribe to a tag
<seb128> good to know, thx :)
<vorlon> yep
<bdmurray> lol, that's old
<bdmurray> well my +subscriptions page is timing out
<seb128> same here :-/
<rbasak> TIL
<tsimonq2> I often wonder if that timeout threshold should be raised.
<tsimonq2> Some pages I expect to take some time to load.
<Unit193> doko: Re: dwz on compressed sections.  I had found https://sourceware.org/bugzilla/show_bug.cgi?id=24725 upstream and presumed that sufficed, or did you specifically want one reported in Ubuntu(/Debian)?
<ubottu> sourceware.org bug 24725 in default "[dwz] Support compressed debug sections" [Enhancement,New]
<doko> Unit193: yep, but not much we can do downstream. There is discussion elsewhere if and when error codes should just be ignored
<Unit193> Indeed not, that's why I figured that was the best option.  Some of the ruby team members were wondering if it'd be better to wait for dwz to be fixed, or fix it in ruby2.5.
<doko> Unit193: does ruby compress debug sections by default?
<Unit193> doko: As noted in the other channel, for some odd reason yeah it's an upstream default.
#ubuntu-devel 2019-07-11
<amurray> doko:
<amurray> doko: thanks for the heads up on those bugs but they don't look related to the hardening changes, plus looks like sforshee is on top of it :)
<Unit193> bryce: Re: ruby2.5/openssl bug.  This is my nick on IRC if you want to poke here as well.
<bryce> Unit193, oh heya :-)
<bryce> Unit193, I was just doing a triaging pass through yesterday's bug activity, but feel free to ping me on that bug.
<bryce> I'm at EOD now, but will check back tomorrow
<doko> sforshee: so the powerpc cross succeeds, with linux-libc-dev-powerpc-cross built from the 5.2 sources. I'm not that that keen to further investigate, as we only need the powerpc cross compiler to build some firmware for ppc64el
<doko> sforshee: so once gcc-8-cross and gcc-9-cross migrate, you should have cross compilers again, matching the native compilers
<doko> and the alpha fix was the only thing needed
<cpaelzer> rbasak: (and other SRU folks) thanks for having a discussion on the 1829823 case
<Unit193> (LP 1829823)
<ubottu> Launchpad bug 1829823 in Ubuntu Cloud Archive mitaka "libvirt-bin: during shutdown libvirt-bin is stopped before libvirt-guests causing hang" [High,In progress] https://launchpad.net/bugs/1829823
<cpaelzer> rbasak: I know it is not a common case, but if at the end of this we can come up with a clear guideline how to handle those that will benefit all of us
<doko> sforshee: all cross compilers now in the release pocket
<seb128> paride, hey, I just got an email about the eoan/desktop iso job failing with that error
<seb128>   File "/usr/lib/python2.7/dist-packages/libvirt.py", line 1035, in create
<seb128>     if ret == -1: raise libvirtError ('virDomainCreate() failed', dom=self)
<seb128> libvirtError: unsupported configuration: append not supported in this QEMU binary
<seb128> paride, is that a known issue on the utah side?
<paride> seb128, I just updated utah on venonat, in part because it was due time, in part to allow mwhudson's last changes to land
<cpaelzer> not sure what it is worth, but qemu-system-* in eoan still has the -append parameter
<paride> seb128, I knew it would probably explode, and it did :(
<paride> seb128, trying to fix it now, anyway I backed up the old packages, so if it turns out more complex than expected I should be able to downgrade it again
<rbasak> cpaelzer: I added to the agenda of our next meeting. We have been talking about staging SRUs that we don't think are worth the cost of landing, so this can add to that discussion.
<paride> cpaelzer, seb128, I think I found it: https://bugs.launchpad.net/utah/+bug/1548499
<ubottu> Launchpad bug 1548499 in UTAH "Newer qemu versions define a serial append capability but do not yet support it" [Undecided,New]
 * paride fingers crossed
<seb128> paride, thx for looking at it!
<paride> seb128, seems to be working again. if you notice anything unusual do not hesitate to ping me
<seb128> paride, wiil do, thx for responding and for fixing it!
<LocutusOfBorg> tjaalton, FYI https://launchpad.net/ubuntu/+source/intel-compute-runtime/19.13.12717-0ubuntu2 :)
<LocutusOfBorg> I did that because intel new driver transition was stuck...
<LocutusOfBorg> and now a build failure, probably due to new intel, or new gcc or whatever... can you help?
<LocutusOfBorg> I don't want to upload intel-graphics-compiler to new releases....
<LocutusOfBorg> better force gcc-8 and leave the update to you if you agree
<DanyC> hi, i'm new around and so please accept my apologise for a silly q: i'm trying to understand how the ubuntu cloudimg ova image is being built? I'm trying to understand the mechanics done around the cloud-init and the user-data PropertyMapping present in the ova spec file. Any help much appreciated
<tjaalton> LocutusOfBorg: i don't have time for that until next month, most likely
<LocutusOfBorg> tjaalton, it migrated, so on the next upload you will probably want to drop the hack
<LocutusOfBorg> https://launchpad.net/ubuntu/+source/intel-compute-runtime/19.13.12717-0ubuntu3
<tjaalton> next one should be to sid
<tjaalton> assuming the deps go through NEW some year
<seb128> cpaelzer, hey, the Debian maintainer pointed out for usbguard that the lib is private/shipped in a subdir and that upstream consider it non-stable so it doesn't make much sense to have a .symbols, I commented back on https://bugs.launchpad.net/ubuntu/+source/usbguard/+bug/1816548 , would be nice if you have a +1/-1 about that point as a follow up since you did raise the issue in your review
<ubottu> Launchpad bug 1816548 in usbguard (Ubuntu) "[MIR] usbguard" [Undecided,Incomplete]
<Unit193> ...So where exactly *is* casper's vcs? https://code.launchpad.net/~ubuntu-core-dev/casper/trunk points to a dead url and nothing else I'm finding is right.
<Unit193> ...Having Vcs-Browser would most certainly help here.
#ubuntu-devel 2019-07-12
<mwhudson> Unit193: i use the package import git for casper
<Unit193> The only thing I found current just had imported dscs, not development commits. :/
<mwhudson> Unit193: well yes
<Unit193> mwhudson: I'm trying to narrow down why certain ISOs I'm playing with drop me in the initramfs, d/changelog and Launchpad diffs are nice but sometimes actual commits have more reasoning and much more narrow changes.  The importer is just as good as reviewing d/changelog and diffs. :/
<mwhudson> Unit193: yeah, it's exactly as good as that
<mwhudson> Unit193: i don't know of anything more finegrained though
<Unit193> Eg https://git.launchpad.net/ubiquity/log/ is quite useful.  Ah, OK.  Well as long as it's "It doesn't exist" rather than "I can't find it", that'll do.  Thanks, mwhudson.
<seb128> hum, https://people.canonical.com/~ubuntu-archive/pending-sru.html hasn't been updated for more than a day ... who is the right person to ping about that?
<Laney> I can look at that
<Laney> this happened last week too...
<Laney> yeah, stuck process
<rbasak> Does it use lots of launchpadlib? git-ubuntu tends to hang when Launchpad is struggling. I never got to the bottom of it.
<seb128> Laney, thx
<Laney> rbasak: Yeah, it's doing more or less what you'd expect to get a list of published packages in -proposed, check they've built, things like that - a lot of API usage
<Laney> I can't see what it was doing
<Laney> Not ideal that there's no monitoring
<Laney> Maybe it could be run through 'timeout' at least
<Laney> vorlon or tobikoch (found you in 'git log'): can you please comment on https://code.launchpad.net/~ken-vandine/ubuntu-seeds/+git/ubuntu/+merge/370062 ? (cc kenvandine)
<Laney> I thought that livecd-rootfs was supposed to be able to figure this out (hence sil2100 removing that entry), BICPW
<Laney> BW*
<Laney> possibly something around this area https://git.launchpad.net/livecd-rootfs/tree/live-build/functions#n485
<tobikoch> Laney: the functionality is missing from livecd-rootfs in Xenial, afaict.
<Laney> tobikoch: kenvandin_e said it was broken for eoan too (that MP is for the eoan seeds)
<tobikoch> Laney: It should work in eoan.
<vorlon> Laney, tobikoch: does mvo's livecd-rootfs MP fix this? https://code.launchpad.net/~mvo/livecd-rootfs/+git/livecd-rootfs/+merge/370065  It seems to only add validation, so maybe that just turns the runtime failure into a debuggable build failure
<Laney> vorlon: we should get that in I think
<vorlon> Laney: k. I'm off today, feel free to merge & upload or get someone from Foundations to do it
<Laney> kenvandine is saying (#ubuntu-desktop) that core is always needed - snapd is saying "cannot proceed without seeding "core"" which certainly sounds fairly definitive
<Laney> ('core' is missing from seed.yaml)
<kenvandine> livecd-rootfs is added snapd if core isn't seeded
 * Laney is off, please talk amongst yourselves :)
<kenvandine> and according to the snapd folks, we still need core for the classic case
<kenvandine> vorlon: ^^
<kenvandine> vorlon: mvo's MP only adds a check to prevent us from getting broken images
<vorlon> right, so we have to add core back into livecd-rootfs's handling to work around snapd not being ready for a core-free system (and now enforcing this at seed time instead of failing later)
<kenvandine> yeah
<kenvandine> might be better to seed core explicitly, which livecd-rootfs will see and not add snapd?
<kenvandine> then we don't need to touch livecd-rootfs when we can have a core free system
<kenvandine> just by changing the seeds
<kenvandine> this way we can control this in the seed
 * kenvandine prefers to be explicit 
<vorlon> I think that's inconsisent with the design principle of seeds, which is generally that you declare the top level / leaf packages that you care about and expect the machinery to spit out the right result
<kenvandine> yeah, but without a dependency system
<vorlon> we *don't* want the core snap as part of the definition of Ubuntu 19.10, but we have to pull it in because ugs
<vorlon> bugs
<vorlon> so I think the machinery should handle this, and not declare it in the seed
<kenvandine> ok
<kenvandine> mvo suggested they should really provide a tool for us to use in livecd-rootfs that takes the seed and figures out what needs to be added to pass validation
<kenvandine> instead of having the logic in livecd-rootfs itself
<kenvandine> that doesn't exist today, but would be nice to have in the future
<kenvandine> vorlon: go back to enjoying your time off and I'll handle this
<kenvandine> vorlon: thanks for your feedback
 * vorlon waves :)
<kenvandine>  /query tobijk
#ubuntu-devel 2020-07-06
<mwhudson> we could clean up excuses a lot by removing all packages implemented in haskell, go or rust
<Unit193> Ooooh, shiny!
<ginggs> mwhudson: from the archive, or from excuses?
<ricotz> LocutusOfBorg, hi :), looks like dav1d needs i386 builds now https://launchpad.net/ubuntu/+source/ffmpeg/7:4.3-3ubuntu1/+build/19552226
<ricotz> LocutusOfBorg, ah, I missed you message in -release ;)
<LocutusOfBorg> :)
<LocutusOfBorg> coreycb, any idea for this failure? http://autopkgtest.ubuntu.com/packages/p/python-oslo.messaging/groovy/amd64
<LocutusOfBorg> looks like oslo.messaging can't start or something similar
<rafaeldtinoco> good morning o/
<coreycb> LocutusOfBorg: I'm not sure off the top of my head, I'll take a look
<LocutusOfBorg> thanks!
<LocutusOfBorg> xnox, hello, FYI I syncd src:less. The Debian approach seems a little bit different according to the diff https://launchpad.net/ubuntu/+source/less/551-2
<LocutusOfBorg> but the bug closed is the same
<xnox> LocutusOfBorg:  past singe upgrade it shouldn't matter =)
<LocutusOfBorg> rbalint, FYI I uploaded a "fix" for ulfius, it was always returning a curl error message that was not meingful
<LocutusOfBorg> at least now the autopkgtest will return the real error
<LocutusOfBorg> https://github.com/babelouest/ulfius/pull/168/files
<LocutusOfBorg> basically they were printing the "res" variable value, but that value was initialized at the function begin and never changed :)
<rbalint> LocutusOfBorg, thanks!
<rbalint> seb128, i'm hinting the systemd/s390x failure for glib2.0 in https://code.launchpad.net/~rbalint/britney/hints-ubuntu/+merge/386878
<seb128> rbalint, ah, thanks
<LocutusOfBorg> btw <BTS> Opened #964384 (serious) in src:ulfius 2.6.7-4 by Gianfranco Costamagna (locutusofborg) Â«ulfius: FTBFS with recent libmicrohttpdÂ». https://bugs.debian.org/964384
<ubottu> Debian bug 964384 in src:ulfius "ulfius: FTBFS with recent libmicrohttpd" [Serious,Open]
<coreycb> LocutusOfBorg: I'm uploading python-oslo.messaging 12.2.0-0ubuntu2 which should fix that autopkgtest failure
<Odd_Bloke> mwhudson: Our life would be much simpler if we just shipped busybox configured to bootstrap a Gentoo system IMO.
<LocutusOfBorg> coreycb, thanks!
<mwhudson> ginggs: i meant proposed but why stop there!
<mwhudson> Odd_Bloke: windows 95
<xnox> mwhudson:  vorlon: about ghc, why did we take ghc from unstable, when it's unmigratable there? can we not sync from testing?
<xnox> it used to have a long delay, but now they do run some autopkgtests, and do reduce migrations to like 2 days, it makes no sense to take haskell in, ahead of debian, does it?
 * xnox ponders if ghc should be on the blacklist
<xnox> as in the ftparchive auto-sync blocklist
<mwhudson> certainly it's not going to migrate in debian terribly soon
<mwhudson> vorlon: https://bugs.launchpad.net/ubuntu/+source/haskell-yi-language/+bug/1886591
<ubottu> Launchpad bug 1886591 in haskell-yi-language (Ubuntu) "please remove package and rdeps from release" [Undecided,New]
<xnox> mwhudson:  i wanted to say, it looks like yi is dead, and has not been updating their deps for years now, should i try to fix them, or purge them?
<xnox> mwhudson:  fixed yi-language.... your welcome? http://launchpadlibrarian.net/487457086/haskell-yi-language_0.18.0-1build2_0.18.0-1ubuntu1.diff.gz
<xnox> looks like it is building fine.
 * xnox ponders if i should have uploaded it as build3, to ensure that if anything gets uploaded to debian, it gets synced over.
#ubuntu-devel 2020-07-07
<mwhudson> xnox: heh well i was leaning more towards purging but i guess fixing requires lower privileges
<mwhudson> now, agda
<mwhudson> needs an upstream update i think
<mwhudson> hm present in git, why is it not uploaded
<rbasak> waveform: o/ someone in #ubuntu-bugs is asking what package bug 1886581 should be moved to. I don't know the answer!
<ubottu> bug 1886581 in Ubuntu "Ubuntu 18.04 64-bit RasPi 3 and 4 image fails to boot on RasPi 4B" [Undecided,New] https://launchpad.net/bugs/1886581
<rbasak> https://ubuntu.com/download/raspberry-pi suggests that it should work
<mwhudson> [289 of 369] Compiling Agda.TypeChecking.Errors ( src/full/Agda/TypeChecking/Errors.hs, dist-ghc/build/Agda/TypeChecking/Errors.o )
<mwhudson> LLVM ERROR: out of memory
<mwhudson> yay haskell
<waveform> rbasak, should be linux-firmware-raspi2
<GunnarHj> bluesabre: Hi Sean, can you please consider the suggestion here:
<GunnarHj> https://discourse.ubuntu.com/t/default-im-config-configuration/17136
<GunnarHj> and add your view. (didn't find you in discourse.u.c)
<RikMills> The following packages have unmet dependencies:
<RikMills>  python3-distutils : Depends: python3 (>= 3.8.3-1~) but 3.8.2-0ubuntu2 is to be installed
<RikMills>                      Depends: python3-lib2to3 (>= 3.6.4) but it is not going to be installed
<RikMills> E: Unable to correct problems, you have held broken packages.
<RikMills> doko ^
<bdmurray> Laney, jibel: Do you know if the "Reproducing tests in the cloud" instructions here are correct? https://wiki.ubuntu.com/ProposedMigration
<Laney> bdmurray: I didn't write that, but it looks ok-ish
<Laney> you need to find the right image of course
<bdmurray> I'm getting a Traceback in the autopkgtest code
<bdmurray> I also gather that the nova command is replaced by openstack so wonder if that is part of the issue.
<Laney> let me have a go
<jibel> bdmurray, these instructions may need a refresh
<coreycb> RikMills: i'm hitting that as well
<RikMills> coreycb: see #ubuntu-release
<RikMills> hopefully a removal from proposed will help
<coreycb> RikMills: thanks
<Laney> bdmurray: the cloud is giving error 503 to me most of the time so I can't get a reliable test (:
<Laney> :(*
<Laney> SAD. NOT HAPPY.
<bdmurray> Well yes that is sad.
<Laney> autopkgtest --setup-commands setup-testbed -o temp/gzip gzip --apt-upgrade --shell-fail -- ssh -s nova -- --flavor m1.small --image ubuntu/ubuntu-focal-daily-s390x-server-20200706-disk1.img --keyname nightingale
<Laney> this is the command I'm trying to use
<bdmurray> https://pastebin.ubuntu.com/p/rXvmr3Pm4d/
<Laney> is that after it does the dist-upgrade / reboot dance?
<bdmurray> This was the only output I saw
<bdmurray> No UUID given. Instance won't be deleted!
<bdmurray> Unexpected error:
<bdmurray> or lines 1 and 2 of my paste
<bdmurray> which I guess I hadn't looked at closely ;-)
<Laney> put some --debug in
<bdmurray> in which part?
<Laney> autopkgtest --debug <autopkgtest params> -- ssh --debug <more params>
<bdmurray> all the parts then!
<Laney> perhaps you're just getting what I am
<bdmurray> I suspect this is going to take a while to timeout
<bdmurray> Laney: some debug output https://pastebin.ubuntu.com/p/h2cn5nQ5YF/
<Laney> bdmurray: I had to try like 5 times but it eventually worked; the other times the cloud failed to make machines
<Laney> I suppose the output should be better in that case
<Laney> I think that's probably what you're seeing
<bdmurray> Laney: alright, thanks for looking I'll try a bit more
<Laney> Maybe try it without autopkgtest and if you see flakiness it might be good to take that up with IS
<Laney> something probably needs kicking
<bdmurray> yeah, will do
<amurray> ddstreet: hey I was going to prepare a backport of that possible fix that jdstrand identified for LP #1886115 - but I see you assigned it to yourself - so just wanted to sync on what the status was
<ubottu> Launchpad bug 1886115 in systemd (Ubuntu Bionic) "libseccomp 2.4.3-1ubuntu3.18.04.2 causes systemd to segfault on boot" [Medium,In progress] https://launchpad.net/bugs/1886115
<amurray> ddstreet: I am happy to do it but if you are already looking at it then I don't want to repeat the work :)
<ddstreet> amurray yeah, i've got a few more that i'm uploading for systemd today, so figured i'd toss it in
<amurray> ddstreet: awesome - thanks :)
<vorlon> xnox: why were you fixing haskell-yi-language ftbfs instead of letting it be removed? :)
<vorlon> (it's removed now, regardless)
<vorlon> mwhudson: ^^
<mwhudson> vorlon: hurrah
<mwhudson> does whoever is on +1 duty today want to cherry-pick https://github.com/gophercloud/gophercloud/commit/0183d6ad325843c27bd9497b9dca1f0259ffadb8
<mwhudson> actually i should probably do that in debian
<mwhudson> (i did it in debian)
#ubuntu-devel 2020-07-08
<mwhudson> where did libburnia upstream go?
<mwhudson> oh the git bits are still around
<icey> is there any way I can re-poke something that's marked ftbfs in proposed (Groovy)? It failed yesterday but I think it's not an issue with my package (Depends: python3 (>= 3.8.3-1~) but 3.8.2-0ubuntu2 is to be installed)
<RikMills> icey: what package? If you have upload rights, there will be a retry button on the build
<icey> RikMills: I don't have upload rights, https://launchpad.net/ubuntu/+source/python-os-traits/2.4.0-0ubuntu1/ is the package that failed to build
<icey> RikMills: I do suppose I'll be working to get upload rights for the OpenStack packages sometime soon
<RikMills> icey: ok. that is in main, so I can't do it. so you need a core dev to poke, unless as you say it in another set
<RikMills> FYI the reason for that dep wait 'should' be fixed
<icey> RikMills: yeah - I can't reproduce the failure locally this morning, and I heard some conversation about it yesterday :)
<RikMills> jibel: this is still happening with ubiquity 20.10.8 https://i.imgur.com/4LTUds6.png
<RikMills> icey: looks like it got poked ;) thanks LocutusOfBorg
<icey> thanks LocutusOfBorg
<icey> and RikMills: Where are you seeing who poked it?
<RikMills> icey: You can't, which is a lack in launchpad. I know because I asked in another chat if someone could poke
<jibel> RikMills, yeah, I saw the comment on the bug report.
<jibel> looking at Mate now
<RikMills> jibel: thanks. obviously I confirmed in a VM from that screenshot
<icey> RikMills: well, now I'm wondering where else I should be :-D
<icey> RikMills: any chance you could ask about getting neutron-vpnaas poked as well, seems to be the same failure :)
 * icey goes back to hiding in the corner
<Unit193> It's a pretty fun place to be, lurking the corner in the shadows. :3
<icey> :-D
<RikMills> icey: here is just fine. it was a not public telegram thing. there are plenty of core devs in here, but IRC lacks being able to see who is online (or recently so)
<icey> RikMills: indeed it does lack that :)
<LocutusOfBorg> icey, done
<icey> thanks again LocutusOfBorg
<Unit193> Closest you have is /wii $name, which shows you idle time.
<LocutusOfBorg> I'm also mass retrying the last 69 packages in excuses age
<juliank> trying to bisect make but shit this is though
<juliank> There's all sorts of weird incarnations you have to do to bootstrap the build environment
<juliank> e.g. po/ is empty
<juliank> and then it complains about missing .po files
<juliank> And doing this over SSH in a cloud on a different continent is not exactly fun
<cjwatson> Doesn't ./bootstrap do the job?
<juliank> cjwatson: In 4.3, yes, if you have git:// access
<juliank> cjwatson: It's not there in 4.2, and I'm bisecting between those two
<cjwatson> Ah
<juliank> Now it's trying to rsync from translationproject.org - ugh
<juliank> this ain't going to work
<juliank> I can only do http*
<juliank> If I do make make, it does nice things but ultimately fails with
<juliank> /usr/bin/ld: /tmp/make/glob/glob.c:1342: undefined reference to `__alloca'
<juliank> why can't people have decent build systems?
<juliank> it's done
<juliank> xnox: So, I finished bisecting make on s390x for the flatpak-builder/s390x issue. The cause of the issue was a change to make it use posix_spawn() instead of fork()/exec().
<juliank> xnox: I'm not sure if there's an issue with posix_spawn() on s390x, or make's use of it, but I did upload a make 4.3-4ubuntu1 that passes --disable-posix-spawn to configure to make it work again
<juliank> I also forwarded that change to Debian
<juliank> This is the offending commit: https://paste.ubuntu.com/p/tYhbJFKN76/
<juliank> Maybe there's undefined behavior in there and we compile s390x at -O3, could also be the reason, who knows
<juliank> debian doesn't test s390x
<juliank> debian bug 964541
<ubottu> Debian bug 964541 in make-dfsg "make: Regression on s390x, echo EPERM, caused by posix_spawn change" [Serious,Open] http://bugs.debian.org/964541
<xnox> juliank:  we should be compiling s390x at -O2, we only use -O3 for ppc64el by default
<juliank> xnox: ah ok
<xnox> juliank:  is there a launchpad bug about this too? we could try to escalate it to IBM
<juliank> xnox: I don't think so
<xnox> juliank:  ok, i can open a new one.
 * xnox learns word heisenbug
<seb128> bah, I don't understand the util-linux build failure in groovy :(
<seb128> debian/bsdextrautils.install has
<seb128> +#!/usr/bin/dh-exec --with=install
<seb128> +usr/bin/write => usr/bin/write.ul
<seb128> (well, that's the diff, the actual file doesn't have the +)
<seb128> and the build fails on
<seb128> dh_install: warning: Cannot find (any matches for) "=>" (tried in ., debian/tmp)
<seb128> debian/tmp/usr/bin/write does exist
<seb128> and the same .install / rules work in Debian (unless I overlooked a diff/change)
<seb128> hum, it's just the error being misleading
<Unit193> Silly question, but I presume that install file has +x?
<ahasenack> I haven't seen --with=install in the sheban line before
<seb128> Unit193, not silly at all, thanks a lot for pointing that out
<ahasenack> was that it?
<mdeslaur> TELL US WHAT IT WAS!!!
<mdeslaur> WE WANT TO KNOW!!!
<seb128> lol
<Unit193> Uh oh, someone appears to have made mdeslaur's coffee too strong.
<seb128> build is ongoing, ut it was missing a +x yes
<Unit193> Happy to have been of help.
<mdeslaur> Unit193: perhaps I didn't put enough rum in it
<seb128> will teach me to merge by just applying the debdiff :p
<Unit193> If the diff is generated correctly (eg, git) `patch` can understand to set the correct permissions.
<seb128> right, well it wasn't in this case because I wrongly assumed it was a simple diff and doing complicated things wasn't needed :p
<seb128> the error is really unhelpful though
<seb128> 'dh_install: warning: Cannot find (any matches for) "=>" (tried in ., debian/tmp)'
<seb128> it doesn't even tell you the item it tries to match
<Unit193> It tried to install, literally, '=>'
<seb128> not to mention the permission, feels like something could warn about a dh-exec script not being +x
<seb128> ahasenack, but yeah, that was the issue :/
<ahasenack> good to know
<seb128> indeed
<seb128> Unit193, thank you again!
<Unit193> Sure thing.
<ahasenack> it's in the same category of weird errors when you try to run a shell script what has windows line endings
<seb128> right, 'fun ones" :)
<Unit193> Or the error when pkg-config is missingg..
<realtime-neil> How does one build the various artifacts listed here? https://releases.ubuntu.com/20.04/
<sarnold> realtime-neil: I think this is the starting point https://code.launchpad.net/ubuntu-cdimage
<realtime-neil> sarnold: much thanks
<mwhudson> it's pretty hard to get going on your own machine unfortunately
<ahasenack> hi +1 maintenance team, I'm looking over the nginx and python-certbot/python-acme migrations
<ahasenack> is there a highlight word for this team, btw?
<ahasenack> I'm noticing a larger than usual delay between a dep8 run disappearing from the /running url, and its result showing up in autopkgtest.u.c, anyone else wondering?
<ahasenack> so much that earlier today I kicked another run, thinking "didn't I trigger this before?", and an hour later both results came back
<ahasenack> specifically, I'm waiting for a result on http://autopkgtest.ubuntu.com/packages/p/python-certbot-apache/groovy/armhf
<mwhudson> vorlon: should we seed shim-signed and grub-pc on all bootable amd64 images? some flavours currently end up with grub-efi-amd64 to satisfy shim-signed's alternate dep and then install fails
#ubuntu-devel 2020-07-09
<seb128> hum, quite some desktop i386 autopkgtest unhappy due to
<seb128> Processing triggers for libc-bin (2.31-0ubuntu10) ...
<seb128> E: Could not configure 'libc6:i386'.
<seb128> E: Could not perform immediate configuration on 'libgcc-s1:i386'. Please see man 5 apt.conf under APT::Immediate-Configure for details. (2)
<seb128> is that a known issue/something being worked on?
<seb128> doko, ^ you might know?
<Unit193> Silly seb, i386 doesn't exist!
 * Unit193 ducks.
<seb128> oh, of course! :p
<Unit193> Sorry, I'm only useful every other day. :)
<seb128> that's fine, I will queue a question for tomorrow then :p
<xnox> seb128:  although one is installing special packages, they are of the other arch, thus shouldn't actually try to require immediate configuration.
<ahasenack> good morning
<ahasenack> hm, so excuses for python-certbot 1.6.0-1 is saying "missing build" (https://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#python-certbot), but 1.6.0-1 built just fine 15h ago: https://launchpad.net/ubuntu/+source/python-certbot/1.6.0-1/+build/19561482
<ahasenack> oh
<ahasenack> it helps when I reload the excuses page
<seb128> xnox, shouldn't, but yet https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/i386/a/at-spi2-atk/20200709_021603_3c926@/log.gz (and the other glib rdepends on the team report)
<oSoMoN> can a MOTU please retry the node-body-parser tests with the correct triggers?
<oSoMoN> http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=node-body-parser&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=arm64&package=node-body-parser&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=armhf&package=node-body-parser&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=ppc64el&package=node-body-parser&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=s390x&package=node-body-parser&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<kanashiro> hey, what would be the correct version string for a bionic SRU if in bionic we have 1.4.9-1build3 and in focal 1.4.9-1build5?
<rafaeldtinoco> oSoMoN: doing
<oSoMoN> thanks!
<rafaeldtinoco> all done ;) you're welcome
<ahasenack> rbasak: hi, ok to import a new package manually following those instructions?
<ahasenack> on the usual host?
<rbasak> ahasenack: yes. I intend to move to the new host very soon (today or tomorrow maybe) but working on something else right now
<ahasenack> k
<ahasenack> oh, turns out this one is already imported, I typoed when checking
<oSoMoN> I fixed the node-buffer-shims failing autopkgtests at https://salsa.debian.org/js-team/node-buffer-shims/-/merge_requests/1, can a MOTU please sponsor https://people.canonical.com/~osomon/+1maintenance/node-buffer-shims.debdiff in the meantime?
<oSoMoN> also, can someone please retry http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=ppc64el&package=node-chokidar&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1 ? it looks flaky to me
<oSoMoN> similarly for http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=arm64&package=node-clean-css&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1
<oSoMoN> the node-client-sessions tests are failing because they need a node-iconv rebuilt against the new nodejs, can someone trigger these tests with the additional trigger:
<oSoMoN> http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=node-client-sessions&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=arm64&package=node-client-sessions&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=ppc64el&package=node-client-sessions&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=s390x&package=node-client-sessions&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> (sorry for spamming with these requests, it's only the beginning, as there are many test failures in nodejs rdepsâ¦)
<oSoMoN> node-concat-map/armhf needs triggering again: http://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=armhf&package=node-concat-map&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1
<oSoMoN> here we go again, node-cors needs an additional node-iconv trigger:
<oSoMoN> https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=amd64&package=node-cors&trigger=nodejs%2F12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=arm64&package=node-cors&trigger=nodejs%2F12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=armhf&package=node-cors&trigger=nodejs%2F12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=ppc64el&package=node-cors&trigger=nodejs%2F12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<oSoMoN> https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=s390x&package=node-cors&trigger=nodejs%2F12.18.1%7Edfsg-1ubuntu1&trigger=node-iconv/2.3.5-4
<Laney> oSoMoN: let me do those
<oSoMoN> thanks!
<Laney> for me a pastebin would be easier, then I can act on them all more quickly
<oSoMoN> Laney, sure thing, let me pastebin them
<oSoMoN> Laney, https://paste.ubuntu.com/p/8GSpKXVZ4z/
<Laney> merci
<Laney> all done
<vorlon> mwhudson: yes, anywhere that shim-signed is seeded should probably also have grub-pc seeded at this point, to avoid grub-efi-amd64 being wrongly pulled in; although that doesn't explain the kubuntu thing anyway given that neither kubuntu nor ubuntu have grub-pc seeded in the same place as shim-signed currently
<vorlon> mwhudson: also Ubuntu has shim-signed seeded in live, Kubuntu does not
<vorlon> and I frankly still don't understand the kubuntu build log output
<RikMills> xnox: what is the potential fix that landed for #1885414
<RikMills> LP: #1885414
<ubottu> Launchpad bug 1885414 in ubiquity (Ubuntu Groovy) "on flavours ubiquity: bootloader failed on /dev/vda" [Critical,Triaged] https://launchpad.net/bugs/1885414
<xnox> RikMills:  debian-cd images were fixed to correctly boot; followed by 20.10.8 ubiquity landing. It unbroke ubuntu flavour images, and should improve, if not fix, other ubiquity-using flavours.
<xnox> RikMills:  so we had a period of completely toast images; and those that had borked ubiquity
<xnox> RikMills:  but flavour seeds may need further fixes.
<RikMills> xnox: thanks. just going to test today's kubuntu ISO in legacy mode then
<xnox> RikMills:  yes, thanks! It matters if one booting as CDROm or Disk/USB, legacy of uefi, which flavour, which image buildid.
<RikMills> can only do Vbox right away, but I know that was broken yesterday
<RikMills> if that is bust, maybe I will do some seed changes and hit the respin buttons
<RikMills> 20200709 is borked
<ahasenack> hi all, just a fyi that I'm working on the certbot.* migration
<RikMills> vorlon mwhudson : even with grub-pc seeded in live, grub-efi-amd64 was still pulled in
<vorlon> RikMills: some of these changes might require time to propagate to the archive (task fields); do you know if the Task: kubuntu-live was dropped from grub-efi-amd64 before you tried rebuilding?
<RikMills> vorlon: I don't k
<RikMills> *know where to check that
<vorlon> RikMills: 'apt show grub-efi-amd64' on groovy, but you would've had to have checked it before the build since it'll change over time
<vorlon> RikMills: anyway the field has updated now so I think we should try another rebuild
<vorlon> (doing)
<RikMills> I just did another
<vorlon> ah ok
<RikMills> I fiddled with blacklisting which I am 99% would not work, but respun anyway
<cjwatson> RikMills: At the risk of being a broken record, the only legitimate purpose I know of for "blacklisting" in seeds (hm, I should probably rename that) is to cause builds to fail if a blacklisted package is present.  Trying to use it for any other purpose is likely to cause more problems than it solves.
<RikMills> ok
<cjwatson> RikMills: (as in - I think in this case it may happen to have worked, but is likely to cause other problems so it's still worth finding another answer)
<RikMills> cjwatson: I suspect the other seed changes now propagated are more likely to be the cause for it 'working'. I will test later removing it
 * RikMills tries installing the new iso
<cjwatson> RikMills: Yeah, a manual run locally with the most recent kubuntu.groovy seed commit reverted doesn't seem to have grub-efi-amd64 in live
<cjwatson> RikMills: Very likely just slow propagation of the explicit addition of grub-pc
 * RikMills nods
<RikMills> vorlon cjwatson et al. ok, Kubuntu now installs ok in legacy mode for me (in a VM)
#ubuntu-devel 2020-07-10
<mwhudson> RikMills: yay
<vicamo> hi, need sponsor for https://launchpad.net/~vicamo/+archive/ubuntu/ppa-1886911, anyone has some time to help review/landing to bionic?
<mwhudson> kanashiro: thanks for https://launchpad.net/ubuntu/+source/golang-github-hashicorp-memberlist/0.1.7-1ubuntu1
<seb128> shrug, autopkgtest retry needs a dup request filter :/
<seb128> LocutusOfBorg, http://autopkgtest.ubuntu.com/packages/u/util-linux/groovy/armhf we managed to trigger three time the same thing there :/
<Laney> there's a merge proposal from tsimonq2 for that!
<seb128> way to go :)
<tsimonq2> Laney: You mean the one that still needs review?
<Laney> yeah
<tsimonq2> I started it when my Python skills were terrible and refactored recently.
<tsimonq2> (I'm not calling myself great it at but I'm much better now.)
<Laney> :>
<tsimonq2> I *think* the last thing left there were tests. I'll get to that...
<tsimonq2> :P
<Laney> I did try to ping Åukasz about it but he's not here atm
<Laney> (since he reviewed before)
<tsimonq2> No worries.
<LocutusOfBorg> seb128, yes, it sucks sometimes, I discovered it too :/
<tsimonq2> Laney: That reminds me, I spent a solid amount of time digging re: making index.html on autopkgtest.u.c faster. It came up mostly fruitless, unfortunately.
<tsimonq2> I couldn't tell whether the bottleneck was from cold-connecting to the SQLite DB every time, since it's a CGI script triggered by Apache (from what I remember), or from SELECT taking so long.
<tsimonq2> (Actually activating the connection shouldn't be the issue, it's that it can't really be cached effectively without writing to an external file.)
<tsimonq2> Any insight you're able to provide would be appreciated, since seeing that puzzle solved would be cool.
<Laney> It might be locking on the database with multiple concurrent clients accessing it
<Laney> I reckon it might be worth thinking about switching to a proper database server - you could then also avoid some of the other annoying stuff like having to download the results out of swift
<Laney> but that's obviously a medium sized project
<tsimonq2> At the very minimum that would require knowledge about what is considered the best "proper database server" from an administrative standpoint.
<tsimonq2> The downside would be that users could no longer just download the database as a single file, unless we really wanted to go through the effort of providing a publicly-accessible dump every so often (or at least a clone that ~ubuntu-dev could access, I'm thinking along the same lines as what DDs can do).
<tsimonq2> Those aren't really questions I can answer or Just Decide, even if I volunteered to do the work.
<tsimonq2> (I would start a thread on ubuntu-release/devel but I certainly don't want to start a DB flamewar.)
<Laney> I think the maintainers could just decide :-)
<Laney> but yes, if that's a valuable thing for people to use, you'd need to replace it with an API or something
<tsimonq2> I don't consider myself a maintainer until I have commit access. :P
<tsimonq2> I will however volunteer to put some work towards it.
<tsimonq2> Feel free to loop me in once the maintainers decide. ;)
<oSoMoN> if there are MOTUs around, this trivial patch could use sponsoring: https://people.canonical.com/~osomon/+1maintenance/node-buffer-shims.debdiff
<LocutusOfBorg> oSoMoN, I do if you provide the patch to the Debian bug
<LocutusOfBorg> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963457
<ubottu> Debian bug 963457 in src:node-buffer-shims "node-buffer-shims: FTBFS: dh_auto_test: error: /bin/sh -ex debian/tests/pkg-js/test returned exit code 1" [Serious,Open]
<oSoMoN> LocutusOfBorg, oh IÂ already submitted it to salsa (https://salsa.debian.org/js-team/node-buffer-shims/-/merge_requests/1), but I didn't think of checking whether there was a bug report for it
<LocutusOfBorg> oh, even better
<oSoMoN> I'll share the link to the merge request in the bug
<oSoMoN> LocutusOfBorg, FYI I filed and am looking into bug #1887144
<ubottu> bug 1887144 in node-sha.js (Ubuntu) "autopkgtest failures on ppc64el with nodejs 12.18.1" [Undecided,New] https://launchpad.net/bugs/1887144
<LocutusOfBorg> oSoMoN, please update the merge request with "Closes: #963457" if that fix is for that RC bug
<LocutusOfBorg> and I'll merge it
<oSoMoN> doing that now
<oSoMoN> LocutusOfBorg, done
<AsciiWolf> kenvandine, hi, I have sent MR to fix the Snap Store name in Czech translation in two remaining active branches: https://gitlab.gnome.org/Community/Ubuntu/gnome-software/-/merge_requests - feel free to merge :) thanks!
<kenvandine> AsciiWolf: thanks, I have it on my list to look at.
<AsciiWolf> kenvandine, nice! thanks :)
<kanashiro> yw mwhudson
<kanashiro> now I am trying to figure out why nomad is FTBFS on arm{64,hf}, every time I try to build it I got a different error
<kanashiro> vorlon: I am reviewing a fix for ruby-ncurses in bionic and I have a question: what would be the correct version string for a bionic SRU if in bionic we have 1.4.9-1build3 and in focal 1.4.9-1build5?
<kanashiro> in bionic it was built against ruby 2.5 and it does not work, but in focal where it was built against ruby 2.7 it works fine
<oSoMoN> Laney, would you mind retrying https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=armhf&package=node-depd&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1 for me?
<oSoMoN> (looks flaky)
<kanashiro> oSoMoN: I can do it if you want ^
<oSoMoN> kanashiro, please
<kanashiro> done
<oSoMoN> cheers
<oSoMoN> Laney, excuse my pinging you directly, IÂ should have asked MOTUs in general before asking my favourite retrier
<vorlon> kanashiro: the problem I see with having the package in bionic with a version higher than the focal version, then, is that on upgrade from bionic to focal, the system will fail to upgrade to a ruby2.7 version of the package
<vorlon> kanashiro: it's ugly, but how about 1.4.9-1build3ubuntu0.18.04.1?
<oSoMoN> LocutusOfBorg, I attached a debdiff to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=963063, can you sponsor that one?
<ubottu> Debian bug 963063 in src:nodejs, src:node-diff "nodejs breaks node-diff autopkgtest: Failed test: 41" [Serious,Open]
<oSoMoN> (the version in salsa and experimental is much newer, it probably doesn't suffer from this bug, and the patch doesn't apply, which is why I didn't submit a MR)
<oSoMoN> LocutusOfBorg, if we'd rather apply the patch in Ubuntu only (considering the new upstream version in experimental), here's the corresponding debdiff: https://people.canonical.com/~osomon/+1maintenance/node-diff-ubuntu.debdiff
<kanashiro> vorlon: I was thinking about something on this line, that will avoid upgrade issues
<kanashiro> rbasak: FYI ^
<rbasak> vorlon: good point - thanks. I agree it's ugly which is why I wasn't sure, but that does seem like the best option.
<oSoMoN> can a MOTU please retry https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=armhf&package=node-editor&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1 ?
<oSoMoN> also, the node-encoding tests need to be retried with an additional trigger on the new node-iconv: https://paste.ubuntu.com/p/7p6zbxcw7R/
<oSoMoN> same for node-expat: https://paste.ubuntu.com/p/fYxyk2jF6y/
<oSoMoN> and node-express, too: https://paste.ubuntu.com/p/NdvvgYtgxp/
<oSoMoN> Laney, I love the new proposed-migration report where passing tests are hidden, that's much easier to read
<oSoMoN> node-form-data/armhf needs to be retried: https://autopkgtest.ubuntu.com/request.cgi?release=groovy&arch=armhf&package=node-form-data&trigger=nodejs/12.18.1%7Edfsg-1ubuntu1
<Laney> oSoMoN: yeah, nicer isn't it
<Laney> where's all the green gone?!?!?!?!
<Laney> that made me suspicious when I first saw it
<Laney> did your retry
<oSoMoN> thanks
<oSoMoN> Laney, there's a series of other retries that need triggering, in the lines just above (pastebin links)
<oSoMoN> if you don't mind
<Laney> oSoMoN: Going out for a walk now, will look later if nobody else does
<oSoMoN> thanks, enjoy the walk
<Eickmeyer[m]> xnox: Where did we land with the Ubuntu Studio Focal FTBFS?
<xnox> Eickmeyer[m]:  we have not
<Eickmeyer[m]> xnox: Ok, I'm just getting a little concerned with 20.04.1 being about a month away.
<LocutusOfBorg> ahasenack, I did merge the new zoneminder version
<LocutusOfBorg> I had to add a patch because of some missing stuff https://github.com/ZoneMinder/zoneminder/pull/2975
<LocutusOfBorg> can you please ping me in case something bad happens (or fix it :) ) ?
<ahasenack> zoneminder, I have to check my cold storage to remember what I did with it :)
<ahasenack> ah, my_bool stuff
<ahasenack> and reserved keywords
<ahasenack> ok
#ubuntu-devel 2020-07-11
<bdmurray> Laney, jibel: I spent some more time playing with autopkgtest, ssh, and canonistack and now it fails with "autopkgtest: DBG: TestbedFailure sent `open', got `login=ubuntu', expected `ok...'"
<Heewa_B> I'm trying to fill out the header fields in a patch to a deb (from `quilt header -e --dep3`) as best as I can, but I'm new to this. What's "Forwarded"? And What's "Applied-Upstream"? (is it referring to an upstream location within ubuntu, or is upstream the same as "vendor" in this case?)
<Heewa_B> Also, for a field like "Reviewed-by" that I'm not going to fill out (since it hasn't been reviewed), do I leave the part after the colon blank, or just remove the line?
<shachaf> vorlon: Hi -- https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1808508 cites IRC discussion -- was it logged?
<ubottu> Launchpad bug 1808508 in valgrind (Ubuntu) "Valgrind doesn't work in disco [Fatal error at startup: a function redirection which is mandatory for this platform-tool combination cannot be set up.]" [Critical,Fix released]
<shachaf> The comments say that the bug is no longer monitored, but the conclusion really doesn't look right to me. Debug symbols are supposed to be available for a lot of software, not just gdb/valgrind/libunwind.
<shachaf> perf worked around it, sort of, by adding special-case "mixed up Ubuntu" handling: https://github.com/torvalds/linux/commit/85afd35575a3c1a3a905722dde5ee70b49282e70
<shachaf> But there are many other programs that look for debug symbols, and they all have to individually work around the path being wrong now.
<kanashiro> Heewa_B: this might help you with DEP-3 headers: https://dep-team.pages.debian.net/deps/dep3/
<kanashiro> and you do not need to use all the fields, you can remove the ones you do not want to use
<Unit193> Basically, author and description are the most important, forwarded and others are good too though.
<Heewa_B> Thanks, that's very helpful! I already submitted to Debian (to trickle down to Ubuntu, per some guide I followed), but I'll bookmark this for next time.
#ubuntu-devel 2020-07-12
<mwhudson>  python3-secretstorage : Depends: python3-jeepney but it is not installable
<mwhudson> wut
<mwhudson> j'accuse cloud-init, without really thinking about it very much
