[01:16] <slangasek> crimsun: AFAICS you're not currently subscribed to bugs for pulseaudio; but perhaps you could take a look at bug #187469 since you're the last uploader?
[01:16] <ubotu> Launchpad bug 187469 in pulseaudio "pulseaudio should have versioned dependency on sysv-rc for use of update-rc.d multiuser" [Medium,Confirmed] https://launchpad.net/bugs/187469
[01:17]  * TheMuso checks whether he is on the audio team, but doesn't think so.
[01:19] <TheMuso> Ok, the kernel team is a member of the audio team, but crimsun deactivated himself a while ago.
[01:19] <slangasek> right; that didn't stop him from uploading the package 5 days ago ;)
[01:20] <TheMuso> I know, I think he just tracks debian and upstream.
[01:20] <TheMuso> And has a look at the buglist from time to time.
[01:20] <TheMuso> But I'm only guessing here.
[01:20] <slangasek> if you're saying you'd rather take care of the bug yourself, be my guest :-)
[01:21] <TheMuso> No, I'm just saying that unless he's around now, he may not get to it for another day or so, so I'll take a peak, since I intend to get more involved with audio work in Ubuntu anyway.
[01:23] <TheMuso> slangasek: I'd do it, however it may be quicker for a core-dev to do it, as I don't yet have core-dev membership.
[01:23] <TheMuso> Since its only a small change.
[01:24]  * ScottK2 wonders when the Tech Board will get to processing applications....
[01:24] <TheMuso> ScottK: I was supposed to be on Tuesday, but only mdz was around, so it was a no go.
[01:25] <ScottK2> So it's in two weeks then ...
[01:25]  * ScottK2 hopes more people get added to the agenda.
[01:25] <TheMuso> DOn't know. mdz said he'd contact the others and see what could be sorted.
[01:26] <TheMuso> ScottK: Have you been emailed to ask if you can attend a meeting?
[01:26] <TheMuso> I don't remember seeing one.
[01:26] <TheMuso> If it was CCd to the mc list.
[01:26] <ScottK2> TheMuso: No.  I haven't.  I'm waiting on that still.
[01:26] <ScottK2> IIRC I was the next applicant after you, so I was expecting to hear something maybe after your meeting.
[01:29] <IntuitiveNipple> Is there a way to remove unnecessary binary files from a source package?
[01:30] <IntuitiveNipple> The diff doesn't cover it; seems like it'd need a new source archive.
[01:30] <Mithrandir> IntuitiveNipple: rm it in the rules file
[01:31] <IntuitiveNipple> Mithrandir: but how would that change what's in the original tgz ?
[01:31] <Mithrandir> IntuitiveNipple: it wouldn't
[01:31] <Mithrandir> but why is that important?
[01:31] <ScottK2> For that you need to repack the tarball.
[01:32] <IntuitiveNipple> I discovered in fixing these bugs in the mysql-query-browser package that it has been shipped with the .lo and .o 32-bit binaries in the gtksourceview sub-package
[01:32] <IntuitiveNipple> Well, it's a lot of space for one, not good practice for two, and the 32-bit static stuff was causing various SIGSEGVs for amd64 and once those were fixed, causing failed 32-bit builds!
[01:33] <IntuitiveNipple> I'll push the debdiff for now but it'd make sense to clean it up, although I'm not sure how to go about and I've wasted a day on this already
[01:33] <Mithrandir> sure, tell upstream to fix it
[01:33] <crimsun> slangasek: / TheMuso: on it, I'll upload a new one with a couple other bug fixes.
[01:34] <TheMuso> crimsun: Ok.
[01:34] <IntuitiveNipple> upstream would be... debian, or mysql?
[01:34]  * TheMuso needs to get onto pulse's lists and bug tracker. :)
[01:34] <Mithrandir> IntuitiveNipple: mysql, I'd say.
[01:34] <IntuitiveNipple> Hmmm, that'll be fun :)
[01:35] <IntuitiveNipple> I've built 32 & 64 bit here now, I'm just confirming it on my PPA before I publish the debdiff
[02:12]  * TheMuso -> getting lunch.
[07:15] <dholbach> good morning
[07:19] <stgraber> moin
[07:19] <dholbach> hi stgraber
[07:20] <pitti> Good morning
[07:24] <TheMuso> Morning pitti.
[07:26] <pitti> hey TheMuso
[07:30] <pitti> soren: oh, oops; libvirt is in main, but needs xen; xen-3.1 is in universe, and the newer xen-3.2, too
[07:30] <pitti> soren: since I understood that we only want to support kvm in hardy
[07:31] <pitti> soren: any idea what to do about this?
[07:31] <pitti> soren: (and libvirt still uses xen 3.1)
[07:35] <stgraber> pitti: When will the first Alpha4 candidates be released ?
[07:36] <pitti> stgraber: I don't know, that's slangasek's now
[07:36] <pitti> stgraber: the current live images are out of date
[07:36] <pitti> maybe because of the gnome-control-center and gnome-settings-daemon file conflict, I haven't checked yet
[07:37] <warp10> Good morning
[07:45] <soren> pitti: libxen3.1 at least used to be in main?
[07:45] <pitti> soren: yes, it was
[07:45] <pitti> hi warp10
[07:45] <soren> pitti: It was needed for libvirt which in turn was needed by redhat-cluster-suite.
[07:46] <warp10> hey pitti!
[07:46] <dholbach> bdmurray: do you plan to get new versions of py-lp-bugs and bughelper uploaded soon?
[07:46] <soren> pitti: What changed?
[07:46] <pitti> soren: if the server team is really ready to support and endorse xen-3.2, I can promote it again
[07:46] <pitti> soren: changed> first, we got xen-3.2, and second I was told by mdz that we should have never really had xen in main in the first place
[07:46] <soren> pitti: Well, afaik, we were never ready to support and endorse xen-3.1, which is why most of it stayed in universe. Only libxen was in main.
[07:46] <pitti> soren: and thirdly someone told me that 'kvm it is!' for hardy
[07:47] <pitti> soren: ok, I see
[07:47] <soren> pitti: I see.
[07:47] <soren> pitti: Erm..
[07:47] <pitti> soren: so, is it possible to build libvirt against xen-3.2?
[07:47] <pitti> soren: then I'll promote the client libs to main and leave the rest in universe
[07:47] <soren> pitti: I'll try.
[07:52] <soren> pitti: Er... It's still stuck in NEW.
[08:47] <soren> mvo: What CPU do you have in that KVM-able AMD machine?
[08:51] <pitti> soren: what exactly?
[08:51] <soren> pitti: xen 3.2
[08:53] <pitti> soren: hm, it only built on i386 so far
[08:53] <soren> pitti: Yeah. I'll poke zul about it this afternoon, when he shows up.
[08:54] <soren> pitti: It seems to fail because the binary-arch target assumes latex is present, but texlive is int b-d-i.
[08:54] <pecisk> gnome-settings-daemon broken in last updates
[08:57] <mvo> soren: a am2 X2 (model 107, stepping 2) - let me know if you need the full /proc/cpuinfo output
[08:58] <soren> mvo: Hm... I'm looking at a AMD Athlon 64 X2 5600+
[08:59] <soren> mvo: That wouldn't happen to be the same, would it?
[09:01] <mvo> soren: no, mine is just a 4400+ :)
[09:01] <mvo> soren: are you looking into buying one?
[09:01] <soren> mvo: I'm strongly considering renting one.
[09:02] <coyctecm> Is Jono Bacon here?
[09:03] <mvo> I'm very happy with mine, upgrade testing runs nice and smooth now
[09:05] <soren> Awesome.
[09:07] <soren> There. Ordered.
[09:11] <cjwatson> coyctecm: sometimes, though not right now
[09:15] <coyctecm> cjwatson, ok
[09:15] <cjwatson> pitti: FYI, I edited Bugs/HowToFilter to add locking to the rules that deliver mail to actual folders rather than /dev/null, as otherwise you can corrupt folders if you're unlucky
[09:16] <pitti> cjwatson: oh, is that the final : in :0: ?
[09:17] <pitti> cjwatson: thanks, I wasn't aware of that actually
[09:17] <cjwatson> yeah, it is
[09:18] <pitti> cjwatson: wow, I hadn't expected procmail to be dangerous by default
[09:19]  * pitti fixes his local .procmailrc then
[09:20] <TheMuso> pitti: What exactly needs fixing? Mine seems to work fine.
[09:20] <pitti> so does mine; TBH I'm not sure what can go wrong
[09:23] <cjwatson> if two procmails try to deliver to the same folder concurrently and you haven't specified a lockfile (just putting ':' at the end of the rule header uses a default folder-specific lockfile) then you can get the usual corruption you might expect from two programs trying to write the same file at the same time
[09:24] <cjwatson> probably lost mail, but if you're really unlucky I suppose interleaved mail is just about possible
[09:24] <soren> Maildir ftw!
[09:24] <cjwatson> (I'm not sure exactly how procmail opens files)
[09:24] <cjwatson> soren: a lockfile's hardly rocket science :)
[09:25] <soren> cjwatson: True that.
[09:25] <soren> Nevertheles.... Maildir ftw!
[09:26] <pitti> I prefer maildir on my desktop/laptop, too, but on the server mbox is nicer for backup
[09:27]  * TheMuso never runs more than one procmail at a time here, well at least doesn't think so, with using fethcmail.
[09:27] <soren> pitti: You think?
[09:28] <pitti> soren: ten files, one for each folder, is much easier to handle/check/move around than a million subdirectories
[09:28] <soren> pitti: I found that having to back up a multi-GB mbox just because one mail was edited was quite annoying.
[09:28] <pitti> soren: yeah, huge mboxes are painful; I don't have them, though
[09:29] <soren> pitti: Well, I used to host mail for quite a few people. I couldn't just tell them to "please don't use large folders" :)
[09:29] <soren> WEll, I could, but they wouldn't listen.
[09:29] <pitti> heh
[09:29] <TheMuso> soren: lol
[09:34] <dholbach> pitti: thanks for checking the apport mail (attachments being patches)
[09:34] <pitti> dholbach: gern geschehen
[09:43] <SlimG> Will Alpha 4 be released today?
[09:51] <stgraber> SlimG: yep
[09:52] <cjwatson> TheMuso: on my system, fetchmail delivers to exim, which can process multiple mails concurrently
[09:52] <cjwatson> (sorry, pinged out, you may have got that twice)
[09:53] <TheMuso> cjwatson: No I didn't, and I understand what you're getting at.
[09:53] <SlimG> stgraber: Any knowhow on when? 1 hour? 5 hours or 11 hours from now? :)
[09:55] <stgraber> SlimG: well, the release manager is in the US timezone + we haven't really done any important testing yet (ISO aren't even on the tracker)
[09:55] <stgraber> SlimG: so it'll likely be late today
[09:56] <SlimG> mkay, thanks for the info stgraber, I apprechiate it
[10:09] <pitti> way cool. fully noninteractive self tests of the jockey GTK interface
[10:12] <TheMuso> Is synaptic ever likely to use policykit for hardy?
[10:14] <mvo> TheMuso: no, very unlikely
[10:14] <mvo> pitti: with dogtail?
[10:14] <pitti> mvo: no, just with using .response() for dialogs and .emit('clicked') etc. for buttons
[10:15] <pitti> mvo: it's not 100% functionality coverage, but it runs through all widgets and dialogs at least
[10:15] <pitti> mvo: since the GTK UI implementation does not have any logic, just an implementation of AbstractUI (which does have the logic and has its own full test suite), that's enough for my purposes
[10:16]  * mvo nods
[10:17] <TheMuso> mvo: Ok thanks. What about gnome-app-install?
[10:18] <mvo> TheMuso: it uses synaptic as its backend (for all the operations that require root)
[10:18] <TheMuso> mvo: Oh ok then.,
[10:19] <mvo> TheMuso: any specific reason that you ask? I haven't looked what it would take yet
[10:20] <TheMuso> mvo: Just wanting to know so that I can 1) recommend a tool for people to use for package installation who use assistive technology, and 2) be able to target testing for gnome-app-install to find any accessibliity bugs relating to the use of assistive technology.
[10:29] <cjwatson> ooh, I nearly have vim omnicompletion for Launchpad bugs working
[10:32] <pitti> seb128: did you notice the gnome-settings-daemon vs. gnome-control-center file conflict for /usr/bin/gnome-settings-daemon?
[10:32] <seb128> pitti: yes, I'll upload a fixed version
[10:32] <pitti> seb128: awesome, thanks; so I won't report it
[10:33] <seb128> pitti: that's just an upgrade issue, new g-c-c doesn't contain this one
[10:33] <seb128> apt or dpkg could handle that better
[10:41] <cjwatson> http://people.ubuntu.com/~cjwatson/tmp/lp-omnicomplete.png
[10:41] <pitti> cjwatson: cool!
[10:47] <soren> cjwatson: Awesome!
[10:47]  * soren drools uncontrollably
[10:48] <Hobbsee> hi soren
[10:48] <soren> Hello.
[10:48] <soren> 'zup?
[10:49] <Hobbsee> soren: taking over the world.  pondering what to do, if anything, about MOTU.
[11:53] <warp10> Hi all!
[12:42] <cjwatson> Riddell: fancy some support for non-ASCII manual pages in konqueror?
[12:43] <Riddell> cjwatson: in the man:/ ioslave?
[12:43] <cjwatson> yeah
[12:43] <Riddell> cjwatson: could do, what needs changed?
[12:43] <cjwatson> about to attach a patch to bug 44548, just wanted to know if you cared :)
[12:43] <ubotu> Launchpad bug 44548 in kdebase "Problems with accentuated characters in man pages" [Medium,Confirmed] https://launchpad.net/bugs/44548
[12:46] <Riddell> cool
[13:03] <jwendell> Hi, seb128. Did pidgin crashed today with you? (I guess it's glib related)
[13:04] <seb128> jwendell: it does crash on one of my boxes but not on the one I'm using right now
[13:04] <ogra> seb128, is g-s-d wanting to overwrite /usr/bin/gnome-settings-daemon in g-c-c known ?
[13:05] <ogra> (upgrade error here)
[13:05] <jwendell> seb128, I've got a trace, gonna fill a bug
[13:05] <seb128> ogra: yes and the fix has been uploaded some hours ago
[13:05] <seb128> jwendell: where?
[13:05] <jwendell> seb128, launchpad? :)
[13:05] <seb128> jwendell: I doubt anybody reads piding bugs on launchpad, in case you want to file there
[13:05] <ogra> seb128, thanks
[13:05] <jwendell> :(
[13:05] <seb128> jwendell: k, feel free, don't expect a quick reply though
[13:06] <seb128> jwendell: and I doubt it's a pidgin issue, it didn't change for weeks now
[13:06] <jwendell> seb128, my guess is glib
[13:07] <jwendell> seb128, look at the crash line:
[13:07] <jwendell> IA__g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_CRITICAL, format=0xb77b0cd4 "%s: assertion `%s' failed", args1=0xbfe9cd8c "?G\216·\nÃ\215·PÜô·\027") at /build/buildd/glib2.0-2.15.4/glib/gmessages.c:503
[13:07] <jwendell> 503	/build/buildd/glib2.0-2.15.4/glib/gmessages.c: No such file or directory.
[13:07] <jwendell> 	in /build/buildd/glib2.0-2.15.4/glib/gmessages.c
[13:07] <seb128> that usually means it hits an assert
[13:08] <jwendell> seb128, maybe that define in glib being deprecated?
[13:08] <seb128> what do you mean?
[13:09] <jwendell> seb128, G_GNUC_[PRETTY_]FUNCTION ?
[13:10] <seb128> why would that create a crash?
[13:10] <seb128> that's a build time thing
[13:10] <jwendell> seb128, ok, I'm sorry
[13:10] <seb128> no need to be sorry
[13:10] <seb128> but I don't think it's due to that ;-)
[13:14] <seb128> jwendell: looks like there is no bug on launchpad about that yet, maybe use apport to send it?
[13:15] <jwendell> seb128, apport is ignoring the pidgin crash
[13:15] <seb128> what do you mean?
[13:15] <jwendell> seb128, does it ignore a crash after three times hitting 'don't send the bug' button?
[13:15] <seb128> yes
[13:15] <jwendell> hehe
[13:16] <jwendell> seb128, anyway I got a backtrace with gdb
[13:16] <jwendell> seb128, just filled the bug upstream
[13:16] <seb128> you can still send the crash using apport
[13:16] <seb128> ok
[13:16] <seb128> just go to /var/crash
[13:17] <seb128> and double click in nautilus on the crash you want to report
[13:17] <jwendell> nice
[13:17] <seb128> or use apport-cli or apport-gtk
[13:18] <jwendell> seb128, the backtrace contains my password. Is there any way to hide it after the bug is filled?
[13:19] <seb128> apport bugs are marked private by default
[13:19] <seb128> and you can edit the description after sending it
[13:19] <seb128> the coredump is removed when the bug is retraced
[13:19] <jwendell> seb128, but can't edit an attachment :(
[13:20] <seb128> hum, right
[13:20] <seb128> did you send it already?
[13:20] <jwendell> seb128, nope
[13:20] <seb128> you can remove an attachment though
[13:20] <seb128> don't send it if you don't like that
[13:20] <jwendell> seb128, sent *edited" backtrace to upstream
[13:20] <seb128> ok
[13:21] <soren> Wow... a debhelper-less package. That's something you don't see every day.
[13:22] <seb128> soren: I've plenty of cdbs packages ;-)
[13:22] <soren> seb128: cdbs uses debhelper, too. This one is *actually* debhelper-less.
[13:23] <Seveas> soren, which one?
[13:23] <seb128> heh, is that something still maintained?
[13:23] <soren> Seveas: dnsmasq
[13:23] <soren> Seveas: Oh, yes.
[13:23] <soren> Er..
[13:23] <seb128> soren: I wrote a debian/rules without debhelper once, not again ;-)
[13:23] <soren> seb128: Oh, yes.
[13:24] <Riddell> pitti: I've uploaded the konqueror flash SRUs ready for your next archive day
[13:25] <Riddell> pitti: I can't work out what the status of the flashplugin-nonfree SRUs is
[13:26] <jwendell> ohhhh
[13:27] <jwendell> i just did a 'rm *' on my $HOME. is there an 'undelete'?
[13:30] <persia> jwendell: Restore from backups
[13:30] <cjwatson> jwendell: no, sorry
[13:30] <cjwatson> there are some low-level methods for doing it on some filesystems but they are much less likely to work on ext3
[13:30]  * persia notes that there are data recovery tools, but they are not easy to use, and installing them can cause data corruption
[13:31] <cjwatson> if you want to try, you should remount the filesystem read-only immediately
[13:31] <ogra> if you want to use them though i'd suggest hitting the power button immediately
[13:31] <ogra> oh, right
[13:31] <jwendell> fortunately I have a backup, from last week. And, for my luck, I didn't '-rf'
[13:31] <ogra> colins suggestion is better :)
[13:32]  * ogra did that recovery thing once ... massively painful
[13:48] <Riddell> asac: I think we should just do a quick SRU for
[13:48] <Riddell> flashplugin-nonfree now
[13:50] <persia> Riddell: Even if it breaks konqueror (or did that get fixed)?
[13:52] <Riddell> persia: that's been fixed noew
[13:52] <asac> Riddell: how?
[13:52] <Riddell> now
[13:52]  * persia agrees with Riddell that's it's time for the SRU
[13:52] <Riddell> asac: update the md5sum and whatever else needs done
[13:52] <asac> where? by adobe or konqueror?
[13:53] <Riddell> asac: konqueror has a workaround for adobe's changes
[13:55] <asac> Riddell: could you do it this time? ... i am completely swamped because moz has changed sec release date from "in two weeks" to "now"
[13:56] <asac> i could do it tonight ... or tomorrow
[13:56] <Riddell> asac: I can probably do it, but is it just the md5sum that needs changed?
[13:57] <Riddell> brandon did an upload previously but I can't see any debdiffs from him
[13:57] <Riddell> imbrando1: alive?
[14:00] <asac> ok lets wait a bit ... if he isn't avail we can talk about plan B :)
[14:01] <asac> have to go for lunch anyway now
[14:27] <cjwatson> seb128: do you know the internals of yelp much?
[14:27] <seb128> cjwatson: no, why?
[14:27] <cjwatson> seb128: I'm trying to make it support UTF-8 manual pages by calling out to 'man --recode UTF-8'
[14:27] <cjwatson> err, support any non-ASCII manual pages that is
[14:28] <cjwatson> seb128: but weirdly, with my patch it says it can't find the file and then displays it anyway :)
[14:28] <seb128> cjwatson: maybe attach the patch upstream and mention the issue? they are usually quite responsive
[14:29] <cjwatson> it's not an upstreamable patch unfortunately
[14:29] <cjwatson> as in it depends on man-db which is distro-specific
[14:29] <seb128> ah, ok
[14:30] <cjwatson> whom would I be best off talking to?
[14:30] <mitsuhiko> hi all
[14:30] <mitsuhiko> completely offtopic question but hopefully answers :)
[14:30] <seb128> cjwatson: maybe ask mdke when he's around, he's often in contact with DonS who is upstream
[14:30] <mitsuhiko> say you want to develop a gpl application which uses tango icons which are licenses under the cc-sa
[14:30] <mitsuhiko> and the application is a web application and the icons used as part of the theme
[14:31] <mitsuhiko> is that possible?
[14:31] <seb128> cjwatson: open a bug in launchpad with the patch so it's easy to point upstream to it
[14:34] <cjwatson> I'll attach it to bug 154829, which is the relevant one
[14:34] <ubotu> Launchpad bug 154829 in yelp "Yelp uses wrong encoding for localized manpages" [Low,Triaged] https://launchpad.net/bugs/154829
[14:34] <cjwatson> thanks
[14:35] <seb128> thank you
[14:40] <jwendell> seb128, definately it' a glib bug. I got exactly same backtrace for a crash in evolution
[14:41] <seb128> jwendell: do you have the backtrace online somewhere?
[14:41] <seb128> jwendell: what do you do to crash evolution?
[14:42] <jwendell> seb128, I was about to create a filter based on mailing list
[14:42] <jwendell> seb128, wow, there are similar bugs
[14:43] <jwendell> bug #187603
[14:43] <ubotu> Bug 187603 on http://launchpad.net/bugs/187603 is private
[14:43] <jwendell> bug #187637
[14:43] <ubotu> Bug 187637 on http://launchpad.net/bugs/187637 is private
[14:45] <seb128> jwendell: those are totally different backtraces
[14:45] <jwendell> seb128, but the title is the same :)
[14:46] <jwendell> seb128, Bug #187667
[14:46] <ubotu> Bug 187667 on http://launchpad.net/bugs/187667 is private
[14:46] <jwendell> seb128,  this is mine
[14:46] <seb128> jwendell: right, which means that a g_return_if_fail_warning() condition has been hit
[14:46] <jwendell> seb128, exactly
[14:46] <seb128> jwendell: but any program or library can use g_return_if_fail_warning() on any condition
[14:46] <seb128> that doesn't mean it's a glib bug or that they are similar
[14:47] <jwendell> seb128, indeed, but it's a bit weird to have various programs crashing *today* with this same assert
[14:48] <seb128> dholbach: is pidgin crashing on your hardy box where evolution doesn't work?
[14:53] <pochu> jwendell: and your liferea crash too, bug 187622
[14:53] <ubotu> Launchpad bug 187622 in liferea "liferea-bin crashed with signal 5 in IA__g_return_if_fail_warning()" [Medium,New] https://launchpad.net/bugs/187622
[14:53] <seb128> jwendell: can you try if downgrading glib fix your issue?
[14:54] <jwendell> pochu, yes
[14:54] <seb128> ah
[14:54] <jwendell> seb128, sure, if you tell me how :)
[14:54] <seb128> let me try something
[14:54]  * jwendell thinks seb128 found the problem :)
[14:55] <seb128> jwendell: how to trigger the evolution crash?
[14:55] <seb128> jwendell: not really
[14:56] <jwendell> seb128, right click on a message, create an rule->based on mailing list
[14:56] <seb128> jwendell: does opening the properties dialog work correctly?
[14:57] <jwendell> seb128, what properties? you mean preferences window?
[14:57] <seb128> jwendell: yes
[14:57] <jwendell> seb128, oops, crash again
[14:58] <Lutin> pitti: can you give-back rtfm please ?
[14:58] <pitti> Lutin: done
[14:59] <Lutin> pitti: thanks
[15:00] <\sh> hmmm
[15:01] <\sh> pitti, did you have any problems with gtk+2.0 sources fetching with ia32-libs/fetch-and-build?
[15:01] <pitti> \sh: if source/binaries are out of sync, that happens
[15:02] <\sh> pitti, hmm..let me update my local system...apt-get source gtk+2.0 works for me until now ;)
[15:02]  * jwendell wonders if seb128 has 2 machines, one for daily use and other for tests and crashes :0
[15:02] <jwendell> :)
[15:02] <\sh> pitti, na, it will fetch a nwe version, yes but works
[15:02] <\sh> ah i386
[15:03] <seb128> jwendell: no, not due to the new gtk
[15:03] <seb128> jwendell: what architecture do you use?
[15:03] <jwendell> seb128, i386
[15:04] <ion_> Btw, has anyone considered making dpkg use a faster database than plaintext sequential files?
[15:04] <Riddell> asac, pitti: flashplugin-nonfree updates uploaded for gutsy and feisty, edgy and dapper are harder to do
[15:05] <\sh> nope i386 works as well
[15:05] <seb128> jwendell: https://launchpad.net/ubuntu/+source/glib2.0/2.15.3-0ubuntu1/+build/496254
[15:05] <seb128> jwendell: you can get binaries from there, download those you need and sudo dpkg -i *.deb
[15:10] <Lutin> pitti: why don't the buildds install the build-depends-indep (or at least seem not to) ?
[15:10] <jwendell> seb128, same thing. (must i reboot?)
[15:11] <seb128> jwendell: no need to reboot, just restart the application
[15:11] <seb128> jwendell: or try to start pidgin
[15:11] <pitti> Lutin: the i386 one does; other arches don't (they just do dpkg-buildpackage -B)
[15:11] <jwendell> seb128, same crashes in pidgin and evolution
[15:11] <seb128> jwendell: ok, so that's not glib
[15:12] <seb128> jwendell: want to try downgrading gtk? https://launchpad.net/ubuntu/+source/gtk+2.0/2.12.5-1/+build/495133
[15:15] <Lutin> pitti: what's the reason for this ?
[15:16] <pitti> Lutin: Arch: all should be built just once, not 5 times in vain
[15:16] <pitti> Lutin: so in Ubuntu, the i386 buildds build Arch: all packages, and the other arches do -B
[15:16] <pitti> Lutin: that's why we have one more i386 buildd
[15:19] <jwendell> seb128, I quit, same crashes
[15:19] <seb128> jwendell: that is weird
[15:20] <cjwatson> pitti: is anyone working on adding consolekit support to login?
[15:20] <Lutin> pitti: eek, I was looking at the wrong build log. got it, thanks
[15:20] <cjwatson> I'm a bit surprised that isn't there
[15:23] <pitti> cjwatson: not to my knowledge ATM; there is a PAM integration package for CK, but I never tested it; do we need it?
[15:28] <jdong> are there any archive admins online that can shove transmission 1.00-1~gutsy1 through binary NEW?
[15:28] <jdong> it's causing repo breakage for backports users (bug 187526)
[15:28] <ubotu> Launchpad bug 187526 in transmission "can't install/upgrade package in gusty if gusty-backports is enabled" [Undecided,New] https://launchpad.net/bugs/187526
[15:28] <asac> Riddell: why?
[15:29] <asac> Riddell: konqueror not updated yet? (thanks btw)
[15:39] <mpt> dholbach, remind me, how do you tell whether a bug is in the sponsoring queue?
[15:39] <dholbach> seb128: yes :)
[15:39] <dholbach> mpt: if ubuntu-{universe,main}-sponsors is subscribed
[15:39] <jdong> dholbach: can you handle the archive issue I mentioned above?
[15:39] <mpt> dholbach, excellent, thanks
[15:40] <dholbach> jdong: no, I'm afraid I'm not an archive admin
[15:40] <dholbach> (which is probably a good thing)
[15:40] <jdong> dholbach: oh, I could've sworn you were! oops :)
[15:40] <seb128> jdong: I'm one, what do you need?
[15:40] <jdong> seb128: it seems like i386 gutsy-backports transmission is stuck in binary NEW while everything else went through
[15:41] <jdong> bug 187526
[15:41] <ubotu> Launchpad bug 187526 in transmission "can't install/upgrade package in gusty if gusty-backports is enabled" [Undecided,New] https://launchpad.net/bugs/187526
[15:42] <seb128> jdong: everything else had no need binaries likely?
[15:43] <Riddell> asac: edgy and dapper are harder to do because they need updating from flash 7 and there's debconf stuff.  it didn't work when I tried at any rate, probably I just missed somehting
[15:43] <jdong> seb128: yeah, that's what I'm guessing. the transmission metapackage seems new
[15:43] <jdong> seb128: though it's really odd it seems like only i386 had the problem?
[15:43] <seb128> jdong: no, what is new is the transmission-common
[15:43] <jdong> ah
[15:43] <mpt> dholbach, would it make sense for the sponsoring queue to be handled more explicitly by Launchpad, rather than by subscribing/unsubscribing a particular team?
[15:43] <seb128> jdong: only i386 build arch all
[15:44] <jdong> well that explains that too :)
[15:44] <dholbach> mpt: how do you think that should happen?
[15:44] <seb128> jdong: accepted
[15:45] <mpt> dholbach, I don't know -- I'm sure you or someone has explained to me how the queue works at some stage, but I've forgotten
[15:45] <mpt> but Launchpad should make easy the process of getting stuff fixed
[15:45] <dholbach> mpt: in the perfect world we'd have NoMoreSourcePackages and everything would be in one or the other bzr branch :-)
[15:45] <jdong> seb128: thanks :)
[15:45] <seb128> you are welcome
[15:46] <mpt> dholbach, ah, so sponsoring would be replaced by merging?
[15:46] <dholbach> mpt: yes
[15:46] <mpt> ok
[15:46] <mpt> Is NoMoreSourcePackages likely to happen in the next, say, 3 years?
[15:47]  * jdong gives mpt the optimism award of the day
[15:47] <cjwatson> mpt: maaaaaybe
[15:48] <mpt> jdong, no no, I'm being pessimistic, that's about how long it would take to implement anything sponsorship-queue-specific in LP ;-)
[15:48] <\sh> pitti, requestsync is broken ;) There is no project named 'distros' registered in Launchpad. ;)
[15:49] <ogra> if we all work towards it it should be achievable ...
[15:49] <\sh> pitti, forget it, I'm using an old one
[15:49] <jdong> it's a lot of infrastructure change, but I can't wait for it to happen :)
[15:49] <pitti> \sh: it's in ubuntu-dev-tools nowadays
[15:50] <\sh> pitti, yepp..I just had the old one still in my all the time in svn ~/bin/ dir ;)
[15:52] <sistpoty|work> mvo: can you sponsor me nvidia-settings again? bug #178255 (though I must admit, that I didn't test-build it since I added the debdiff)
[15:52] <ubotu> Launchpad bug 178255 in nvidia-settings "NVCtrl.h and NVCtrlLib.h should be installed in /usr/include/NVCtrl not /usr/include" [Undecided,Confirmed] https://launchpad.net/bugs/178255
[15:53]  * ogra kicks evo in the guts  .... with run-up 
[15:53] <ogra> evil thing ...
[15:54] <Hobbsee> mpt: ah yes, but how long for it to be fixed, after it being *broken* in LP?
[15:54] <Hobbsee> :)
[15:54] <mpt> eh?
[15:55] <Hobbsee> mpt: first implementations are often wrong :)
[15:55] <seb128> ogra: what did it do?
[15:55]  * ogra cries ... why does my mailer have to be so mean to me *sniff*
[15:56] <ogra> seb128, it decided to collapse all threads after the last crash
[15:56] <mpt> because no-one's implemented a good one yet? :-)
[15:56] <ogra> and obviously the 2exapnd all threads" function always only expands one level
[15:56] <seb128> ogra: ctrl-T
[15:56] <ogra> i'm clicking my ass off to get to the last (new) message in a thread here
[15:57] <ogra> seb128, yay, now all collapsed again
[15:57] <ogra> ctrl-t wasnt such a good idea
[15:57] <seb128> do it again
[15:57] <ogra> it switches threading off/on but doesnt expand the threads
[15:58] <Hobbsee> does * do anything?
[15:58] <ogra> actually if i expand one it collapses it again
[15:58] <ogra> i'll just click my way through
[15:59] <ogra> oh, another restart helped :)
[16:00] <\sh> ogra, use claws ,-)
[16:01] <ogra> \sh, or balsa :)
[16:02] <seb128> evolution is good
[16:02] <\sh> ogra, hmm..balsa...tested it only once....I like claws now ;) it works ;)
[16:03] <ogra> balsa doesnt have much overhead ... thats what i like about it
[16:04] <ogra> claws ... to many options i'll never need ...
[16:05]  * ogra remembers times where mail clients were 300k big :)
[16:05] <\sh> cjwatson, how do I tell your new "show LP bugs" addon to sort for importance e.g.? :)
[16:05] <ogra> which gui mail client comes with less than a meg nowadays .... ?
[16:06] <\sh> ogra, these days all mail clients were named mail, elm, pine (or mutt) ;)
[16:06] <stgraber> ogra: telnet is 90k here :)
[16:06] <ogra> stgraber, gui :)
[16:07] <\sh> ogra, gnome-terminal -e telnet <your mailserver> 110|143 is gui ,-)
[16:07] <ogra> :P
[16:07] <cjwatson> \sh: you edit it
[16:08] <pochu> \sh: gnome-terminal -e is broken :P
[16:08] <cjwatson> it ought to be possible to make the sorting cleverer; I didn't because I had already spent too much time on it
[16:09] <\sh> cjwatson, and when I'm on it, I could add a "stop adding bugnumbers when hitting ESC"
[16:09] <\sh> cjwatson, but cool stuff, I have to say...thx for that :)
[16:09] <bdmurray> dholbach: today or tomorrow
[16:09] <dholbach> bdmurray: rock and roll
[16:10] <\sh> pochu, gnome-terminal -e "telnet whereever 143" works for me :)
[16:10] <cjwatson> \sh: yeah, it's not interruptible at the moment
[16:11] <cjwatson> I'd be entirely happy for somebody to take it on and improve it
[16:11] <cjwatson> ':help complete-functions' has some advice on making completion functions interruptible
[16:11] <\sh> cjwatson, I'll have a look :)
[16:12] <cjwatson> cheers
[16:15] <jwendell> seb128, can it be possible that glib or similar package was built with fatal asserts flag on?
[16:15] <jwendell> seb128, so, instead of just a warning, it crashs?
[16:16] <pedro_> jwendell: may you check the G_DEBUG environment variable?
[16:17] <pitti> seb128: hm, did you notice that nautilus recently started to create icons for internal drives/mounts? that can also be seen on the live CD
[16:17] <jwendell> pedro_, fatal_criticals
[16:17] <jwendell> pedro_, is that?????
[16:17] <pedro_> aham!!
[16:17] <pedro_> tha's the guilty!
[16:17] <jwendell> putz
[16:17] <pitti> seb128: I've got it on my desktop, too, and ogra had a similar problem on edubuntu last week
[16:17] <jwendell> pedro_, where the hell did I put this???
[16:17] <pedro_> yeah that's it
[16:17] <pedro_> i don't know!
[16:17] <pedro_> just found that a few minutes ago
[16:17] <pitti> seb128: I'll have a look into this next week, but I might have some questions
[16:17] <pedro_> got the same crashes and i just looked in case of
[16:18] <pedro_> but don't know what package defined it recently
[16:18] <pedro_> it shouldn't be
[16:18] <pedro_> i mean not for normal users
[16:18] <jwendell> pedro_, yeah
[16:19] <pedro_> gotta run now, my food is waiting me
[16:20] <jwendell> pedro_, thanks
[16:24] <seb128> pitti: right, nautilus started using gvfs instead of gnome-vfs
[16:24] <seb128> pitti: and I didn't port the patch to ignore mnt mounts for example
[16:25] <pitti> seb128: ah, so I guess our previous patches to adopt the showd mounts doesn't work any more
[16:25] <jwendell> seb128, found the problem
[16:25] <jwendell> G_DEBUG variable
[16:25] <seb128> jwendell: ah?
[16:25] <jwendell> seb128, where is it being set?
[16:25] <seb128> jwendell: ah, gnome-session
[16:26] <jwendell> seb128, hard-coded?
[16:26] <seb128> jwendell: they set it during unstable branch to get bugs about critical warning, we usually patch it out but I didn't look at that when I did the update
[16:26] <jwendell> seb128, hehe
[16:26] <\sh> cjwatson, CTRL+E is just that what it needs to end completion :) I wonder how to map it to esc in this case
[16:26] <pochu> jwendell: will you close your liferea bug or shall I?
[16:27] <jwendell> pochu, let me do it
[16:27] <pochu> jwendell: thanks
[16:27] <seb128> jwendell: unset G_DEBUG
[16:27] <seb128> jwendell: then run your application
[16:27] <seb128> dholbach: ^
[16:27] <cjwatson> \sh: I think the completion function needs to call complete_check occasionally
[16:27] <jwendell> seb128, yes, I did this ;)
[16:27] <seb128> jwendell: I'll fix it now
[16:27] <jwendell> seb128, thanks
[16:28] <seb128> jwendell: thank you for the work there
[16:28] <dholbach> seb128: all "good" again
[16:28] <dholbach> :-)
[16:28] <seb128> so those are not new bug
[16:28] <seb128> but what GNOME looks like when warning are crashers ;-)
[16:28] <seb128> and that's why I do patch this out usually
[16:28] <jwendell> seb128, I've got a headache, really :)
[16:32] <jwendell> seb128, I'm going to open a bug against gnome-session and mark all these kind of bugs as dupe
[16:32] <seb128> jwendell: they are not, they are valid bugs
[16:32] <seb128> jwendell: they are just warning, not crashers
[16:33] <jwendell> seb128, well, those kind of bugs should be forwarded upstream btw
[16:33] <seb128> jwendell: that's just that nobody bother about those usually, that's why GNOME guys make gnome-session set G_DEBUG during unstable cycle
[16:36] <cjwatson> ogra: sigh, I see what mccann means about privsep causing issues - PAM is just called too early
[16:36] <slangasek> stgraber: hardy alpha 4 candidates for ubuntu are up, finally; sorry for the delays
[16:37] <cjwatson> no way am I changing that though
[16:38] <stgraber> slangasek: ok, how long do we have for testing ?
[16:38] <slangasek> stgraber: uh, as long as necessary; if the milestone release has to be pushed back until tomorrow, then that's what it'll be
[16:41] <seb128> ok everybody, gnome-session was setting G_DEBUG to make application crash on warnings since yesterday, that's something upstream do during unstable serie and that we don't usually
[16:42] <seb128> so if you received crashers in g_return_if_fail_warning(), those are warnings
[16:42] <slangasek> seb128: er. that means this is on the CDs, I guess?  Will that cause problems in practice?
[16:42] <slangasek> i.e., how much is crashing with this?
[16:42] <dholbach> evolution and pidgin are for me
[16:42] <seb128> slangasek: well, pidgin and evolution were crashing for some people here
[16:43] <slangasek> sigh
[16:43] <seb128> slangasek: but that doesn't seem to happen to everybody, might be config dependent
[16:43] <slangasek> see, /now/ you're in trouble for uploading this during the alpha freeze ;)
[16:43]  * seb128 hides
[16:43] <slangasek> well, it is what it is.  I guess the fixed gnome-session will be available from the archive soon after?
[16:44] <seb128> slangasek: yeah, sorry about that, fixed version has just been uploaded, that should not be too bad for the CD
[16:44] <slangasek> ok
[16:44] <slangasek> release notes then
[16:44] <pitti> evand: btw, any idea why ubiquity's icon on the live CD is broken?
[16:44] <seb128> slangasek: thanks
[16:45] <evand> pitti: off the top of my head, no.  It and the installation method for it haven't changed, so I imagine I need to update it with respect to changes in GNOME.
[16:48] <pitti> soren: virt-manager just offers me xen and qemu as hypervisors; do I choose qemu for kvm?
[16:48] <soren> pitti: Yeah, libvirt consider them sort of the same.
[16:49]  * pitti sees it complain about a missing virtd and scratches head
[16:54] <soren> pitti: Eh?
[16:54] <soren> pitti: What's the exact error message?
[16:56] <pitti> soren: "Unable to open connection to hypervisor URI 'qemu:///session':
[16:56] <pitti> soren: then some backtrace
[16:57] <doko> seb128: are gnome-terminal / gnome-vfs build failures known to you?
[16:57] <pitti> then 'libvirtError: virConnectOpenReadOnly() failed'
[16:57] <doko> gnome-vfs-mime-handlers.c: In function 'gnome_vfs_mime_application_get_desktop_id':
[16:57] <doko> gnome-vfs-mime-handlers.c:1601: error: 'G_GNUC_FUNCTION' undeclared (first use in this function)
[16:57] <seb128> doko: yes, there is new tarballs available upstream
[16:57] <seb128> doko: G_GNUC_* have been deprecated
[16:57] <doko> ok, not filing any reports about those
[16:58] <soren> pitti: If you're connecting to qemu:///session, libvirt is supposed to start a libvirtd for you. I'm not sure what could cause that to fail.
[16:58] <pitti> soren: do I need to start virt-manager as root? (the .desktop file doesn't)
[16:58] <soren> pitti: No, not at all.
[16:58] <soren> pitti: I recommend you connect to the system-wide libvirtd, though.
[16:59] <soren> It allows you to set up all the interesting networking options.
[16:59] <soren> Namely brigded and virtual networks rather than just usermode networking.
[16:59] <pitti> it doesn't seem to ask me which virtd to connect to
[16:59] <soren> That's what you tell it with the uri.
[17:00] <soren> qemu:///system is the system wide one.
[17:00] <pitti> ah, -c qemu:///system ?
[17:00] <soren> Yes.
[17:00] <pitti> same error message, though
[17:00] <shaya> does anyone know what broke pidgin in hardy?
[17:00] <soren> Are you a member of libvirtd?
[17:01] <pitti> soren: no, I'm not
[17:01] <soren> pitti: Then you won't be allowed to connect to qemu:///system
[17:01]  * pitti sings "KVM is not enough" ♪
[17:01] <soren> qemu:///session should still be fine, though.
[17:01] <pitti> soren: that group doesn't exist
[17:01] <soren> Then you don't have libvirt-bin installed.
[17:02] <soren> ...and that explains the other problems as well.
[17:02] <pitti> . o O { dependency? }
[17:02] <soren> I'm considering iit.
[17:02] <pitti> soren: ok, thanks a lot for your support
[17:02] <pitti> ah, there goes the daemon
[17:02] <soren> It's perfectly reasonable to use virt-manager to only connect to xen or remote qemu instances.
[17:02] <pitti> true
[17:03] <soren> So a hard dependency seems wrong.
[17:03] <soren> I'd like to add a meta package for this, though.
[17:04] <soren> So there'd be an ubuntu-virtualisation-node and ubuntu-virtualisation-admin or -manager or something.
[17:05] <soren> The former depending on libvirt-bin and kvm, the latter depending on virt-manager, openssh-client, etc.
[17:05] <elmo> how big is libvirt-bin?
[17:05] <pitti> soren: for 80 kB?
[17:06] <elmo> yeah, what pitti said
[17:06] <soren> It's 380 kb installed.
[17:06] <elmo> just add the dep
[17:06] <soren> I didn't think the appropriateness of hard dependencies had much to do with the size of the dependencies.
[17:07] <elmo> sure it does
[17:07] <elmo> adding new packages isn't free
[17:07] <elmo> which seems to be your proposed solution
[17:07] <elmo> trying to avoid adding a dep on an 80Kb package with nothing but binaries isn't overly sane
[17:08] <soren> It could also just be a task.
[17:08] <elmo> (given the other context)
[17:08] <elmo> soren: apt-get install should DTRT
[17:08] <soren> apt-get install my-task-name^  :P
[17:09] <cjwatson> libvirt-bin actually ships an init script and such, but I would be inclined to agree that it'd be a lot more straightforward to just depend on it
[17:09] <cjwatson> once apt installs recommends by default, it could reasonably be downgraded to a recommends
[17:09] <elmo> cjwatson: oh, ok - I assumed from the name that it wouldn't do such things, my bad
[17:09] <cjwatson> it's rather unconventional naming
[17:11] <cjwatson> struct _CkConnecter;
[17:11] <cjwatson> typedef struct _CkConnector CkConnector;
[17:11] <cjwatson> go consolekit
[17:11] <soren> Well, I'll probably be adding those tasks anyway. We want at least the stuff that's needed to function as a virtualisation node to be selectable in the server installer.
[17:11] <jdong> cjwatson: it's an abstraction layer ;-)
[17:12] <slangasek> cjwatson: xubuntu dailies seem to have failed today; germinate issue?
[17:12] <cjwatson> jdong: complete with misspelling?
[17:12] <cjwatson> slangasek: which daily?
[17:13] <slangasek> cjwatson: 20080131, daily and daily-live, both archs
[17:13] <cjwatson> Failed to fetch file:/srv/cdimage.ubuntu.com/ftp-universe/dists/hardy/main/binary-amd64/Packages.bz2  MD5Sum mismatch
[17:13] <cjwatson> odd ...
[17:14] <slangasek> I can retry it shortly if you think it's likely transient
[17:14] <pitti> soren: virt-manager looks great!
[17:15] <cjwatson> the universe mirror seems rather out of date, and none of the rsync logs mention it
[17:16] <soren> elmo, cjwatson: libvirt-bin contains a daemon and a single cli tool (virsh) that exposes most of libvirt's functionality. What would be the conventional way to name it? "libvirtd" and keep the virsh in there even though it's essentially unrelated to the daemon? "libvirtd" and move virsh to a new package called libvirt-bin (yay, new binary)? Or "libvirtd" and move virsh to libvirt0 (erk)?
[17:16] <cjwatson> out of date> except for the way I apparently don't know what date it is. er.
[17:17] <cjwatson> slangasek: hard to say, but I think there's a decent chance it's transient; give it another try?
[17:17] <soren> pitti: Yeah, once it gets going, it's pretty neat. :)
[17:17] <cjwatson> I updated germinate for good measure, but I don't think that'll matter
[17:17] <mr_pouit> there's something weird on http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/hardy/xubuntu/latest/livecd-20080131-i386.out: the seeds have been updated to libgoffice-gtk-0-5
[17:17] <mr_pouit> *g*
[17:17] <mr_pouit> the seeds have been updated to libgoffice-gtk-0-6 long ago
[17:17] <cjwatson> mr_pouit: as we told you guys last time this happened, you need to update livecd-rootfs too
[17:18] <cjwatson> I'll go and do that now
[17:18] <Hobbsee> mr_pouit: did you upgrade the other one?
[17:18] <Hobbsee> bah.  too slow
[17:18] <cjwatson> it has a special hardcoded bit for libgoffice due to apt craziness of some kind that we should probably revisit
[17:20] <cjwatson> mr_pouit: fixed livecd-rootfs uploaded; may take up to a day to propagate without admin help though
[17:21] <cjwatson> mr_pouit: it's even in a comment in the seed
[17:21] <cjwatson>  * (libgoffice-gtk-0-6)   # explicitely seed this for abiword and gnumeric gnomeless variants
[17:21] <cjwatson>                           # any changes here need to be done in the livefs build script, too, ping infinity about this/send an RT
[17:22] <cjwatson> though the action described is wrong now and I'll update it
[17:22] <shaya> is there a way to get gdb to tell you what lib an unresolved symbol (in a backtrace) is coming from?
[17:23] <seb128> shaya: look at the address and what lib is using it, not sure if gdb can do the matching for you though
[17:23] <seb128> shaya: apport crashes have those informations
[17:24] <shaya> seb128: apport isn't catching pidgin crash
[17:24] <seb128> why not?
[17:24] <shaya> anyway I can run pidgin under apport?
[17:24] <shaya> have no clue
[17:24] <shaya> it catches many other things
[17:24] <seb128> are you sure?
[17:24] <shaya> pretty
[17:24] <seb128> ls /var/crash
[17:24] <seb128> shaya: does piding crash on startup on hardy for you?
[17:24] <shaya> yes
[17:24] <shaya> just started today
[17:24] <seb128> shaya: try to unset G_DEBUG and run it
[17:25] <shaya> no crash
[17:25] <Kano> hi, why is stil no casper update online?
[17:25] <seb128> good
[17:25] <shaya> what happened?
[17:25] <mr_pouit> cjwatson: thanks (never heard of livecd-rootfs before, but that'll be ok now)
[17:25] <seb128> shaya: gnome-session set warning to crasher in unstable series
[17:25] <shaya> hmph
[17:26] <seb128> shaya: we disable that in ubuntu usually but the patch was not listed in the series
[17:26] <shaya> ah
[17:26] <seb128> shaya: I've uploaded a new version fixing that some time ago
[17:26] <shaya> ok, thanks
[17:26] <seb128> you are welcome
[17:29] <Kano> https://bugs.launchpad.net/ubuntu/+source/casper/+bug/187259
[17:29] <ubotu> Launchpad bug 187259 in casper "Add support for Aufs" [Undecided,New]
[17:32] <Kano> maybe it is not needed to change the default to aufs
[17:32] <Kano> as you can use it like unionfs=aufs too
[17:33] <Kano> differnt to that patch
[17:35] <Kano> hmm that patch sees a bit wrong, not the one i wrote
[17:36] <Kano> that fallback is at a stupid position
[17:36] <slangasek> cjwatson: xubuntu daily looks good this time
[17:37] <Kano> juliank: you may not add the fallback in the unionfs=... case, thats stupid
[17:37] <Kano> juliank: as it would require a unionfs option!
[17:37] <slangasek> and xubuntu daily-live failing for the reason just identified, so
[17:37] <Kano> look at my patch
[17:37] <slangasek> cjwatson: how many pulses does it take before the livecd-rootfs changes will be visible to xubuntu daily-live?
[17:37] <Kano> juliank: it has to be outside of case
[17:42] <\sh> pitti, libfaad (faad2) when was it moved from multiverse to universe?
[17:48] <berto-> hi everyone, no one in #ubuntu seems to know, so i hope you don't mind me asking here.  after booting into a Xen kernel, my Quantum DLT-V4 SATA tape drive stopped working.  the kernel has the st and sg modules, but dmesg doesn't show it.  any idea what module i'm missing _or_ if ubuntu adds patches to get SATA tape working?
[17:48] <berto-> i compiled the 3.0.4 xen kernel, btw.
[17:53] <geser> \sh: according to LP on 2007-11-16 18:33:22 CET
[17:54] <\sh> geser, oh wow
[17:57] <soren> pitti: I'd love to hear more about your kvm+ISO testing woes. It works fine for me.
[18:09] <cjwatson> slangasek: if you want it guaranteed, I'd get #is on irc.c.c to update it
[18:09] <cjwatson> slangasek: I think it's a (real) daily cron job but I don't know for sure
[18:14] <slangasek> cjwatson: ok
[18:30] <berto-> anyone know where to get linux kernel support ?  the kernel not recognizing my tape drive is getting to me.
[18:40] <slangasek> stgraber: all ISOs should be posted now for testing, with the exception of xubuntu live which is waiting for livecd-rootfs propagation
[18:41] <stgraber> slangasek: cool, thanks
[18:44] <_MMA_> slangasek: I see nothing for Ubuntu Studio. Is it still in-process?
[18:47] <slangasek> _MMA_: http://iso.qa.ubuntu.com/qatracker/build/ubuntustudio/all ?
[18:48] <slangasek> hmm, download link seems broken.  stgraber?
[18:48] <_MMA_> Hmm... http://cdimage.ubuntu.com/ubuntustudio/releases/hardy
[18:49] <slangasek> _MMA_: the images are built, in any case, and available for download directly via http://cdimage.ubuntu.com/ubuntustudio/daily/
[18:49] <slangasek> _MMA_: releases/hardy is only updated when the alpha is released, not during the ISO vetting
[18:49] <_MMA_> Sure. Wasnt that today?
[18:50] <stgraber> slangasek: yes, it's broken for UbuntuStudio, known issue ...
[18:50] <slangasek> _MMA_: not unless you've seen a u-d-a mail and a topic update ;)
[18:50] <_MMA_> I have not.
[18:50] <_MMA_> stgraber: Can you link me to something showing its broken?
[18:51] <slangasek> it may still be today if the ISO testing goes well (and quickly), otherwise the alpha will be pushed tomorrow
[18:51] <stgraber> slangasek: I'm waiting on bug #148944 to have a working download info page
[18:51] <ubotu> Launchpad bug 148944 in ubuntu-cdimage "File list on cdimage for the Ubuntu QA Tracker" [Undecided,Confirmed] https://launchpad.net/bugs/148944
[18:52] <Riddell> siretart: any plans for xine 1.1.10?
[18:52] <geser> has an archive admin time to move aspectwerkz2 from universe to multiverse as it build-depends on sun-java6-jdk?
[18:53] <_MMA_> stgraber: Can you link me to something showing its broken?
[18:54] <Mithrandir> geser: done
[18:54] <stgraber> _MMA_: http://iso.qa.ubuntu.com/qatracker/info/1259
[18:54] <slangasek> stgraber: ah. :)  Ok, I have some plans in that area; ultimately, I want a manifest that declares the current set of testing candidates, that I can also use as input to the release publishing
[18:55] <geser> Mithrandir: thanks.
[18:55] <slangasek> stgraber: so then not only would you not have to poll for images, we wouldn't have to update the list of test targets by hand through the website either :)
[18:55] <stgraber> slangasek: having a manifest file on cdimage.u.c would make possible to have a well working download info page + builds automatically added on the tracker
[18:55] <_MMA_> stgraber: That doesnt really tell me anything. :( cjwatson: Can you shed some light on the Ubuntu Studio disks being broken?
[18:56] <stgraber> _MMA_: what's broken is the info page pointing on your ISOs, because I haven't hardcoded the path to those (I was waiting on a full rewrite of that part of the tracker)
[18:57] <slangasek> _MMA_: that's not about the disks being broken.  we don't know if the disks are broken, y'all need to test them and tell us. >;)
[18:57] <_MMA_> stgraber: No, no. Im talking about why theres no: http://cdimage.ubuntu.com/ubuntustudio/releases/hardy/alpha-4
[18:57] <_MMA_> Yeah
[18:58] <cjwatson> _MMA_: err - I wouldn't expect there to be a releases/hardy/alpha-4 for anything yet!
[18:58] <slangasek> _MMA_: um, I just said that alpha4 hasn't happened yet
[18:59] <cjwatson> _MMA_: as I read stgraber's comment, the thing which is broken is the ISO test tracker, not the disks
[18:59] <stgraber> _MMA_: read slangasek comment above
[18:59] <_MMA_> Damn. I misread the page. Man, I gotta stop looking at these screens. Gonna make my vision worse.
[18:59] <cjwatson> slangasek: assigning 148944 to you, since you seem most on top of it
[18:59] <slangasek> cjwatson: cheers
[19:02] <_MMA_> slangasek: Yeah. I saw the testing page was miffed. I got that. I misread the releases webpage for Ubuntu. Figured if there was one there I shoulda.
[19:03] <_MMA_> Though I swear I saw it with so odd "Updating" message at the top of the page. :P
[19:03] <_MMA_> s/so/some
[19:04] <slangasek> hmm, ok :)
[20:03] <Riddell> tjaalton, bryce: I'm still being hit by bug 133192 testing alpha 4 candidates
[20:03] <ubotu> Launchpad bug 133192 in xserver-xorg-video-ati "Blank screen or distorted image because of wrong default AGPMode value" [High,Confirmed] https://launchpad.net/bugs/133192
[20:03] <Riddell> reading your last comment thought there might not be a fix for everyone, nasty
[20:04] <bryce> Riddell: I'll put it on my todo list, but I'm completely swamped so may be a while before I can look into it
[20:14] <tjaalton> Riddell: that's because upstream tried to be clever, but seems that they reverted the behaviour back to what it was
[20:14] <tjaalton> ..two days ago
[20:15] <tjaalton> unfortunately it went unnoticed, so alpha4 still has that bug
[20:18] <paran> why are the repositories for -dbgsym packages on ddebs.ubuntu.com not gpg-signed?
[20:18] <seb128> because nobody created the key, etc yet
[20:19] <Riddell> tjaalton: that sounds like there's hope on the horizon
[20:19] <paran> seb128: ok. what is wrong with the normal archive key? the debug packages would have to be built at the same time as the normal ones.
[20:20] <slangasek> paran: the normal archive key sits on a different server in a different security context
[20:24] <tjaalton> Riddell: well, then those who benefited from the current version are going to be pissed :P
[20:24] <tjaalton> but they just need to play with bios settings
[20:25] <Riddell> hmm, "just"
[20:26] <tjaalton> yes.. there's no way to do this work automatically for all users
[20:26] <tjaalton> *make it work
[20:32] <bryce> tjaalton: should the bug be closed as won't fix then?
[20:36] <tjaalton> bryce: no, that bug will get fixed, but others probably reopened :)
[20:37] <tjaalton> ..which then could be marked as won't fix
[20:38] <bryce> ok
[20:39] <bryce> let me know if there's anything I should look at with any of it... de-todo'ing it for now
[20:39] <tjaalton> we'll get the fix when a new release is out
[20:40] <tjaalton> although I have no idea when that'll be
[20:45] <paran> slangasek: couldn't the "master version" of the dbgsym-packages repository be created on that same server and context, then synced to ddebs.ubuntu.com?
[20:46] <slangasek> paran: many things "could" be; I don't think that's the right way to do it though, and I don't think that's the solution the archive admins are going to work on
[20:46] <Mithrandir> paran: no, since the master mirror doesn't have the space for it.
[20:47] <slangasek> (having it signed on the master archive server is the wrong answer because the master archive has no other reason to see the ddebs at all)
[20:49] <paran> slangasek: well, I find it quite strange that the dbgsym packages are not in the normal archive to begin with... but I guess that is because of disk space issues on mirrors? :)
[20:52] <seb128> paran: package index pollution, not interesting for most users, the mirror usage, etc
[20:55] <paran> seb128: you could put them in components like main-dbgsym for main which solves the first two points
[20:56] <seb128> that's not much different than having a different source
[20:58] <luisbg> hey ompaul
[20:59] <ompaul> luisbg, hi there
[20:59] <luisbg> :)
[20:59] <paran> seb128: maybe not, but it would at least be easier to find. had to search a while to find ddebs.ubuntu.com
[21:15] <slangasek> stgraber: how does one map reporter names on iso.qa.ubuntu.com to launchpad IDs (or something else that would let me request more info)?  http://iso.qa.ubuntu.com/qatracker/result/1258/54 is reporting a bug that is marked fix released, and I want to confirm that the tester was using the current image
[21:20] <berto-> are there any ubuntu kernel channels on IRC?
[21:20] <kylem> yes. #ubuntu-kernel.
[21:33] <stgraber> slangasek: this user hasn't filed his profile and we don't have the LP integration (yet)
[21:33] <stgraber> slangasek: let me see if I can get you an email
[21:34] <slangasek> ok, thanks
[21:34] <stgraber> slangasek: https://edge.launchpad.net/~svenboden
[21:35] <stgraber> (same e-mail addi)
[21:35] <slangasek> aha
[21:35] <slangasek> sorry, same email as what?
[21:35] <stgraber> LP account and tracker account
[21:36] <slangasek> I don't see any email addresses listed for him under LP?
[21:36] <stgraber> no, but you the search function seems to work if you enter the e-mail addi
[21:38] <slangasek> uhm, I don't understand. what e-mail address am I to enter where?
[21:42] <stgraber> slangasek: I entered the e-mail address I found in his profile on the tracker in the search field. Do you have access to the admin part of the QA Tracker ? (You should have an Admin link next to the Welcome ... in the top-right corner)
[21:43] <slangasek> stgraber: oh, no, I don't have any admin link there
[21:47] <musther_> Hello,  I'm hoping to discuss the fsck problem (periodic boot checks), and possibly find a dev willing to help me implement a solution.
[21:48] <stgraber> slangasek: you should now have the right to access user profiles
[21:51] <slangasek> stgraber: I still don't see any 'admin' links; could you /msg me the email address in question, for the immediate issue?
[21:53] <stgraber> slangasek: sent
[21:55] <slangasek> stgraber: received, thanks
[21:57] <stgraber> slangasek: Access rights to user profiles seem to be a difficult thing to set on Drupal, it'll be better once we'll have our own implementation of user profiles (ideally linked to LP and containing some usefull information for the RM/admins)
[21:57]  * slangasek nods
[22:01] <TheMuso> stgraber: Have you looked at all the various user access modules that are available?
[22:10] <bdmurray> Anybody running an alpha 4 Live CD at the moment?
[22:10] <siretart> Riddell: sure. c.f. bug #181949
[22:10] <ubotu> Launchpad bug 181949 in xine-lib "Please sync xine-lib (main) from Debian unstable (main)" [Undecided,Confirmed] https://launchpad.net/bugs/181949
[22:11] <slangasek> bdmurray: I have one to hand that I can test with?
[22:12]  * TheMuso is burning images now for testing.
[22:12] <bdmurray> I was trying to "unlock" the gnome network settings and the application just quit on me
[22:17] <bdmurray> I haven't seen anything like this before - it ends with "Trace/breakpoint trap" and I'm uncertain how to track it down
[22:18] <FrankQ> bdmurray, a lot of people are reporting bugs like that today
[22:18] <FrankQ> https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2008-January/003193.html
[22:21] <slangasek> bdmurray: oh, that sounds like the gnome-session G_DEBUG bug, then
[22:21] <slangasek> bdmurray: can you upgrade gnome-session in the liveCD, log out and log back in, and see if it goes away?
[22:22] <seb128> or just unset G_DEBUG on a command line and run the software
[22:25] <bdmurray> slangasek: okay, upgrading the package fixed it
[22:26] <FrankQ> I'm not on LiveCD but I'm on the latest versions and it's still there
[22:27] <bdmurray> FrankQ: and which version of gnome-session do you have installed?
[22:27] <slangasek> FrankQ: have you logged out and logged in since upgrading gnome-session?
[22:27] <slangasek> gnome-session sets the environment variable for your *whole* session, so upgrading the package is not enough to clear it
[22:28] <bdmurray> slangasek: is there a master bug for that issue?
[22:29] <slangasek> bdmurray: none that I'm aware of, seb128 handled the bug + upload via IRC
[22:30] <seb128> bdmurray: that's technically not a bug ;-)
[22:31] <bdmurray> seb128: How is that?
[22:31] <seb128> the G_DEBUG things make the software crash on warning to get those reported as bug
[22:31] <slangasek> ehm, I would certainly say that causing the desktop environment to suddenly treat all warnings as fatal errors is a bug
[22:31] <seb128> so technically all the crash are applications bug, they just don't usually lead to a crash
[22:32] <slangasek> hence, "warning"
[22:32] <seb128> anyway no there is no bug about that, it has been handled by IRC
[22:32] <seb128> and closing those crashers are duplicates would be wrong
[22:32] <seb128> they are bug on the concerned applications
[22:33] <slangasek> if gcc suddenly enabled -Wall -Werror by default, I would call that a toolchain bug. :)
[22:33] <cjwatson> somebody might need to add comments on those bugs to indicate that even though the applications no longer crash the bug is that they emit a critical warning
[22:33] <cjwatson> s/the bug/the real bug/
[22:34] <cjwatson> otherwise somebody will probably come along and close them sooner or later ...
[22:34] <seb128> cjwatson: I did comment on some this afternoon
[22:34] <cjwatson> good stuff
[22:34] <FrankQ> sorry, back. 2.21.90-0ubuntu1
[22:34] <seb128> FrankQ: that's not the new version
[22:35] <FrankQ> hmm, weird.
[22:36] <bdmurray> slangasek: will edubuntu be rebuilt?
[22:36] <FrankQ> Yeah, getting a new one now. Wasn't when I asked. apologies
[22:36] <slangasek> bdmurray: for this issue, you mean? I wasn't planning to, I intended to release note it
[22:37] <bdmurray> Wouldn't apport automatically submit them though?
[22:38] <seb128> automatically submit what?
[22:38] <seb128> the crashers due to G_DEBUG?
[22:38] <slangasek> I didn't think apport ever submitted anything automatically?  Also, these processes are dying with the wrong signal so apport doesn't trap them
[22:39] <seb128> slangasek: I think it does
[22:39] <bdmurray> Okay, perhaps I'm not understanding the issue
[22:40] <seb128> the issue is that gnome-session set G_DEBUG which makes applications crash when they usually display a critical warning
[22:40] <bdmurray> There seem to be a lot of apport reported bugs with crashed with signal 5 though
[22:40] <seb128> how much is a lot?
[22:41] <slangasek> seb128: apport handles SIGSEGV, SIGFPE, SIGABRT, SIGPIPE, SIGBUS, SIGILL; according to the email just cited, G_DEBUG is triggering a SIGTRAP
[22:41] <slangasek> hrm, no; that's apport's own signal handler, ignore me
[22:41] <seb128> slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/synaptic/+bug/187875
[22:42] <seb128> one example
[22:43] <bdmurray> seb128: 79 by querying on return_if_fail_warning
[22:43] <FrankQ> Apport definitely didn't fire up with these crashes, for me.
[22:43] <seb128> looking at launchpad there has been one every hour or so today
[22:44] <seb128> and I expect most people run hardy and not CDs and will get the update gnome-session
[22:44] <slangasek> ok, I can see that having everyone filing automatic crash reports between now and alpha5 would be a bad thing...
[22:44] <seb128> bdmurray: you count duplicates?
[22:44] <seb128> I really think that's not an issue
[22:44] <bdmurray> seb128: maybe my launchpad query isn't the best
[22:44] <seb128> there is not so many people using alpha for something else than testing
[22:44] <seb128> and installation will be updated
[22:45] <seb128> installations
[22:45] <bdmurray> but if somebody has a statically configured network what will happen?
[22:45] <seb128> what do you mean?
[22:46] <seb128> you mean if somebody uses the alpha CD to do an install?
[22:46] <bdmurray> Right
[22:46] <seb128> and needs to configure the network then?
[22:46] <bdmurray> yep
[22:46] <seb128> well, I don't think many people rely on alpha CDs
[22:46] <seb128> and you can unset G_DEBUG and run the software
[22:46] <seb128> which will be in the notes
[22:47] <seb128> and an easy enough workaround
[22:47] <seb128> I think that's really a corner case and users running alpha CD should be able to understand how to unset an environment variable
[22:47] <cjwatson> my worry is just that we'll get less good feedback, really
[22:47] <slangasek> bdmurray: do you have a feeling for how effective the release notes are at preventing duplicate bug reports, particularly where apport is involved?
[22:47] <bdmurray> I see your point but personally I would rather err on the side of less bug reports
[22:47] <cjwatson> depends on the amount of work involved in respinning really
[22:48] <seb128> cjwatson: feedback from who?
[22:48] <seb128> bdmurray: I really doubt we will get that many bugs which will not be autoduped
[22:49] <seb128> there is not so many critical warnings around
[22:50] <slangasek> there's at least enough to take out evolution, pidgin, and gnome network settings
[22:51] <FrankQ>  and gnome-settings-daemon, I think
[22:51] <slangasek> anyway, we're already pushed back to Friday for the alpha release at this point, so I'd also rather err on the side of caution
[22:51] <bdmurray> slangasek: I'm of the opinion that the release notes are not widely read but don't recall the specifc bug that makes me think this
[22:53] <bdmurray> slangasek: actually it's bug 145382 from gutsy development
[22:53] <ubotu> Launchpad bug 145382 in busybox "[Gutsy] broken 70-persistent-net.rules" [Undecided,Fix released] https://launchpad.net/bugs/145382
[22:53] <slangasek> ah, that bug looks familiar :)
[22:54] <bdmurray> I seem to recall it getting a lot of dups even after the bug was mentioned in the release notes
[22:54] <stgraber> indeed :)
[22:54] <TheMuso> Do the release notes get announced anywhere besides -devel-announce?
[22:54] <slangasek> not by me; where else should they be released?
[22:54] <slangasek> (are the alphas announced somewhere else?)
[22:55] <TheMuso> I don't know. bdmurray's point about people not reading them could have something to do with that though.
[22:55] <mathiaz>  /bye bbl
[22:55] <TheMuso> I believe they are announced on the fridge, but can't remember whether the release notes are linked to or not.
[22:55] <bdmurray> Maybe if we reorganize http://www.ubuntu.com/testing/hardy/alpha3
[22:55] <bdmurray> so Caveats comes before download
[22:55] <FrankQ> if you look at the forums/#hardy+1 not much people read anything at all, even alpha testers
[22:56] <bdmurray> It is probably wishful thinking but isn't much work
[22:57] <cjwatson> seb128: the purpose of the alpha releases is to get feedback from testers on how we're doing
[22:57] <cjwatson> seb128: if the testers all just say "well, lots of GNOME applications crash" and give up at that point, that could be a net loss
[22:58]  * Gnine nods
[23:01] <seb128> cjwatson: right, without the crashs would be nicer