[00:00] <ogra> simply by restarting all the dowwnloads and deleting everything before
[00:00] <ion_> You should have uninstalled the RIAA plugin.
[00:00] <ogra> i cant belive we ship that
[00:00] <ion_> (That was a (poor attempt at) a joke.)
[00:00]  * jdong looks
[00:01] <jdong> ogra: what did you click to cause that to happen?
[00:01] <ogra> so i have a ton of torrents that already were downloaded startig to DL again and wiping my folders
[00:01] <jdong> (not trying to imply PEBKAC, just trying to understand what happened)
[00:01] <ogra> jdong, i added another torrent without wiping the list *indisde* of transmission (the .torrent files were long gone)
[00:02] <jdong> ogra: oh did that other torrent contain same files or something?
[00:02] <ogra> jdong, well, might be PEBKAC that i didnt wipe the list in tranmission
[00:02] <ogra> nope
[00:02] <ogra> that one was a short movie
[00:02] <jdong> ogra: that's weird
[00:02] <ogra> i simply didnt use trasmission since the last DLs
[00:02]  * jdong hasn't seen that happen yet
[00:02] <jdong> and I've used transmission pretty regularly.
[00:02] <jdong> hmm...
[00:03] <jdong> if you can reproduce the workflow that causes this to happen, that'd be awesome
[00:03] <jdong> it sounds like a pretty nasty bug
[00:03] <ogra> yup
[00:03] <ogra> 'm quite shocked
[00:03] <jdong> or "usability unfeature"
[00:03] <wgrant> I've never seen it delete anything.
[00:03] <ogra> heh
[00:03] <Nafallo> god thing you have backup :-)
[00:03] <Nafallo> good even
[00:03] <jdong> hardlinks, man. hardlinks.
[00:03] <ogra> Nafallo, i copied them all to my server
[00:03] <jdong> they sound sexy and prevent bad things from happening :)
[00:04] <ogra> but the actual dirs were emptied
[00:04] <JohnPhys> I haven't seen it delete anything either, though I've never gone through those steps.
[00:04] <jdong> ogra: so you simply added a torrent and data disappeared?
[00:06] <ogra> well, step 1 download someting to your desktop ... step 2 dont touch transmission for two or three weeks after DL has finished ... step 3 delete the .torrent files step 4 DL a new torrent, notice that transmission has all the old ones listed, note it starts over with the old ones as well, find the dire empty just being refilled with some kb
[00:06] <ogra> *dirs
[00:07] <ogra> its no harm. i copied all the old stuff, but its still quite weird
[00:07] <jdong> ogra: odd... I swear I do that all the time and don't witness data loss
[00:07] <ogra> do the torrents get listed in tranmission after they finished for you ?
[00:07] <Nafallo> that sounds like logic :-)
[00:08] <jdong> yes
[00:08] <wgrant> ogra: You sure you haven't previously removed those folders?
[00:08] <ogra> yes
[00:08] <jdong> ok I've attempted to reproduce it
[00:08] <jdong> minus step 2 of course
[00:08] <jdong> nothing seems to have happened
[00:08] <ogra> heh
[00:08] <Nafallo> no torrent files == empty torrent files == no files :-P
[00:08] <ogra> Nafallo, hmm
[00:09] <jdong> this sounds like a REALLY nasty bug and I'm interested in finding it
[00:09] <jdong> perhaps talk to charles next time he appears
[00:10] <JohnPhys> jdong:  Not to distract you, but you mentioned I could remind you to take a look at bug #195052 once hardy was released.  So...here's a reminder :)
[00:11] <jdong> JohnPhys: yes, thanks for the reminder.
[00:12] <JohnPhys> jdong:  No problem, thanks!  I believe a debdiff has been attached to that bug report lately to take care of the issue.
[00:12] <ogra> jdong, well, i didnt lose anything since i copied to my mediaserver yet and its 1am here and i have a conf call in the morning, i'll try to investigate that tomorrow later
[00:12] <jdong> ogra: thank you
[00:12] <jdong> JohnPhys: I commented on the bug... the debdiff is only slightly incorrect for an update
[00:13] <jdong> JohnPhys: I assume the person who prepared the debdiff would like upload credit for it, so I've asked him on the bug to update his debdiff to reflect stable versioning policies
[00:14] <JohnPhys> jdong:  Thanks!  It's much appreciated!
[00:14] <jdong> JohnPhys: sure thing :)
[03:59] <TheMuso> crimsun: I'm creating ~ubuntu-core-dev/pulseaudio/hardy for hardy pulseaudio development, so that intrepid development can occur concurrently with fixing issues in hardy.
[04:33] <crimsun> TheMuso: ok.  So "trunk" can have revs 20-24 reverted.
[04:47] <kimbrel> Does anyone know if anything’s being done about the IO/scheduling problem?
[05:07] <TheMuso> crimsun: Ok.
[05:21] <jdong> kees: do you know if Gutsy is vulnerable to CVE-2008-0007?
[05:21] <jdong> i.e. git http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=f5871b9016c0ebce8acc58f7a230adcb9bd89577
[05:23] <jdong> kees: i.e. bug 187275; looks like it's still open :-/
[05:24] <kees> jdong: yeah, still open -- we've been planning a kernel update for this coming week, which will include that fix.
[05:40] <jdong> kees: Ok, cheers :)
[06:37] <dholbach> good morning
[06:41] <LaserJock> morning
[06:41] <LaserJock> just the man I wanted to see
[06:42] <dholbach> hi LaserJock
[06:42]  * jdong wonders the thoughts going through dholbach's mind...
[06:43] <dholbach> jdong: hm?
[06:43] <jdong> 01:41 < LaserJock> just the man I wanted to see
[06:43] <jdong> that should trigger the fight-or-flight thing ;-)
[06:43] <dholbach> jdong: oh... I'm sure it's going to be fine :)
[06:50] <dholbach> bdmurray: do you know about recent pylpbugs breakage?
[06:50] <dholbach>   File "/usr/lib/python2.5/site-packages/launchpadbugs/tasksbase.py", line 283, in get_current
[06:50] <dholbach>     raise AttributeError, "There is no row of the info-table linked to this bugreport (%s)" %self._url
[06:50] <dholbach> AttributeError: There is no row of the info-table linked to this bugreport (https://launchpad.net/bugs/123456/+text)
[07:05] <warp10> Good morning
[07:14] <dholbach> bdmurray: I think it'd make sense to get the fix for bug 215043 SRUed - it fixed the breakage above too
[07:18] <dholbach> bdmurray: nevermind what I just said
[07:18] <dholbach> bdmurray: it's just a very weird bug happening - check out http://paste.ubuntu.com/10161
[07:19] <dholbach> no, it's not weird - please just ignore what I said
[07:19]  * dholbach gets more coffee
[07:38] <pitti> Good morning
[07:41] <warp10> good morning pitti
[07:42] <dholbach> hi pitti
[07:42] <dholbach> hi Tonio_
[07:42] <Tonio_> hey dholbach :)
[07:44] <geser> Hi pitti
[07:53] <jscinoz> hmm
[07:54] <jscinoz> Teeworlds still hasnt shown up in the new queue yet >_<
[07:55] <jscinoz> Been in unstable for a while now
[08:25] <soren> Any particular reason why perl's priority was dropped to standard?
[08:30] <soren> Hmm... Maybe debconf's lack of Depends: perl is the actual culprit.
[08:33] <pitti> hi soren
[08:33] <pitti> soren: btw, do you plan to merge dpkg again?
[08:33] <soren> pitti: cjwatson's doing it this time.
[08:33] <pitti> soren: Guillem Jover offered to help with this
[08:33] <pitti> soren: ah, ok; just wanted to make sure you knew about Guillem's offer
[08:34] <soren> Oh, sure.
[08:35] <soren> pitti: So... about perl. IIUIC, changing packages' priority is a manual process, correct?
[08:36] <StevenK> pitti: Stupid question, how do I list sessions for polkit?
[08:36] <pitti> soren: yes, I think so; but it has been standard in hardy already
[08:36] <pitti> StevenK: ck-list-sessions
[08:36] <pitti> StevenK: (it's ConsoleKit)
[08:36] <soren> pitti: Hmm.. You're right. apt-cache show here shows it as important. That's odd.
[08:37] <soren> *
[08:37] <soren> *very* odd indeed.
[08:38] <StevenK> pitti: Oh, duh. That would explain why I couldn't find it. :-/
[08:39] <soren> Perhaps the package itself says it's important, but it's overridden in the archive's Packages file..
[08:39] <soren> No, that says standard, too.
[08:39] <soren> What on earth could make "apt-cache show perl" say "priority: important"?
[08:41] <StevenK> perl-base is Essential: yes, I didn't think perl was
[08:41] <soren> The problem is that debootstrapping Intrepid fails right now, because libc6's postinst ends up failing due to lack of Utils/Hash.pm.
[08:42] <soren> (it uses debconf)
[08:43] <soren> Oh!
[08:43] <soren> perl-base contains fields.pm, which seems to need Utils::Hash.
[08:43] <soren> and the latter is in perl-modules.
[08:43] <pitti> that's a bug in perl packaging itself then
[08:44] <soren> Indeed.
[08:44] <soren> man debootstrap
[08:44] <soren> doh...
[08:55] <StevenK> pitti: I'm trying to determine why USB keys don't automount on UME -- can you just spit out a few hints for me to check?
[08:56] <pitti> StevenK: do you use nautilus on those beasts?
[08:56] <pitti> StevenK: in hardy, nautilus now does the automounting, not g-v-m any more
[08:56] <StevenK> pitti: Ahhhh. No nautilus.
[08:57] <pitti> StevenK: can you mount them manually? with gnome-mount?
[08:59] <StevenK> pitti: gnome-mount -m /dev/sdb doesn't mount it
[08:59] <pitti> StevenK: try gnome-mount -vbd /dev/sdb
[08:59] <StevenK> Right. -m is the wrong option.
[09:00] <StevenK> gnome-mount -d /dev/sdb does work
[09:00] <pitti> ok, so it's really just the lack of an automounter
[09:02] <StevenK> pitti: So UME should use g-v-m?
[09:03] <pitti> StevenK: well, that's the problem; automounting was disabled in gvm, since it conflicts to nautlus
[09:03] <pitti> StevenK: I think you might want to take a look at ivman
[09:03] <StevenK> pitti: Ah, we could enable it specifically for lpia?
[09:04] <pitti> StevenK: either that, or you guys are happy with ivman; drops a few gnome dependencies, too
[09:04] <lool> pitti: MSG people moved back to gvm
[09:04] <lool> They reenabled it
[09:04] <lool> And they fixed it for the new HAL :)
[09:04] <pitti> ah, I see
[09:04] <pitti> lool: how do you mean? current version should work fine with 0.5.11?
[09:05] <lool> It does not; let me grab their changes
[09:10] <lool> pitti: http://people.ubuntu.com/~lool/96_fix_for_new_hal.patch
[09:12] <pitti> lool: hm, that looks like basically reverting 00_disable_media_handling.patch ?
[09:13] <pitti> there are no hal specific changes in that patch
[09:13] <pitti> lool: btw, the latest upstream version  has this 'disabling' patch applied already
[09:16] <pitti> meh, intltool/libxml-parser-perl dependency issue in intrepid seems to cause FTBFS all over the place
[09:17] <tkamppeter> pitti, hi
[09:17] <pitti> hi tkamppeter
[09:18] <tkamppeter> pitti, can you upload system-config-printer and foo2zjs for me (see your mail)/
[09:18] <pitti> tkamppeter: yes, I'll do it
[09:18] <tkamppeter> thanks
[09:19] <lool> pitti: Yes, it reverts the disabling and fixes a couple of things
[09:19] <lool> pitti: They should have used two patches instead of one
[09:19] <lool> And I also said to remove patches they want to disable instead of adding a reverted patch IIRC
[09:20] <lool> pitti: I think this part is the relevant one:
[09:20] <lool> -       { "block",                 block_device_added        },
[09:20] <lool> +       { "volume",                 block_device_added        },
[09:21] <lool> I think they sent that upstream now
[09:21] <lool> In fact we did it with Michael while I was sitting next to him
[09:21] <lool> Hmm no, we sent the hal changes not the gvm ones
[09:23] <lool> pitti: Anyway, StevenK tried ivman out and it worked for him; we're likely to stick to that if we're happy with it
[09:23] <lool> pitti: You can check with Michael Frey if you want more details on what they changed in gvm for the new hal
[09:24] <pitti> lool: ah, thanks for the heads-up
[09:25] <StevenK> ivman looks lighter than gvm.
[09:25] <StevenK> It's what to do about unmounting that escapes me
[09:25] <lool> Good point
[09:26] <pitti> StevenK: but g-v-m doesn't do that either
[09:26] <lool> In all cases we need some UI that will call pmount/gnome-mount to umount devices
[09:26] <pitti> unmounting needs to happen manually
[09:26] <StevenK> Right, exactly. We have no UI.
[09:26] <lool> \o/
[09:27] <lool> StevenK: MSG has been evaluating pcmanfm and rox (rox-filer); we should poke them on the topic, perhaps it's related
[09:27] <StevenK> lool: Okay.
[09:28] <lool> pcmanfm has "# Built-in volume management (mount/umount/eject through HAL)"
[09:29] <lool> Rox doesn't look like it has that
[09:40] <cjwatson> soren: depends: perl from debconf is *wrong*; please don't do that. This is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=479202.
[09:40] <soren> cjwatson: Oh, I wasn't going to :)
[09:41] <cjwatson> pitti: yeah, I know about Guillem's offer, though in the event I didn't need it (I found Ian and got him to explain a couple of obscure triggers bits)
[09:41] <cjwatson> anyway, bank holiday today, so ...
[09:41] <pitti> cjwatson: ah, thanks; enjoy!
[09:41] <pitti> cjwatson: I thought triggers were in sid now?
[09:41] <cjwatson> pitti: they are, but I had to verify the merge as it wasn't byte-for-byte
[09:42] <cjwatson> and in fact I did find one or two things left out, which I'll be forwarding to Guillem
[09:43] <ogra> cjwatson, go away ! its your free day
[09:43] <cjwatson> don't worry, I'm going to be not at home for much of the day :)
[09:43] <ogra> :)
[10:08] <pitti> tkamppeter: new s-c-p> yay, that looks much cleaner now!
[10:15] <norsetto> pitti: about bug 221399: even though only 3 days have elapsed, we have 5 acks and it is just a rebuilt; can we shove it already to -updates?
[10:23] <pitti> norsetto: yes, that's fine
[10:23] <norsetto> pitti: thanks!
[10:29] <\sh> pitti, do you have any paperwork why pybaz was removed in hardy?
[10:31] <pitti> norsetto: does Debian have a new version
[10:31] <pitti> ?
[10:31] <norsetto> pitti: yes
[10:32] <pitti>     rkward |   0.4.9a-1 | intrepid/universe | source, lpia
[10:32] <pitti> norsetto: ah, so that should be fixed in intrepid, too (once it actually builds, that is)
[10:33] <\sh> argl...
[10:33] <norsetto> pitti: ok, I'll open a new task and verify that it builds correctly
[10:33] <norsetto> pitti: even though its a different issue, for Intrepid we have R 2.7
[10:35]  * \sh blames people just filing removal reports, without having a proper notification in the real source package
[10:36] <pitti> norsetto: it already had an intrepid task, I closed it
[10:37] <norsetto> pitti: ah, I guess LaserJock opened it
[10:37] <pitti> \sh: bah, I wonder where soyuz stores/displays the removal log
[10:37] <\sh> pitti, is it possible to improve canonicals remove package script from archive to let it search for reverse-build-deps, and warn even before removal of a package? ;)
[10:37] <\sh> pitti, https://bugs.edge.launchpad.net/ubuntu/+source/bazaar/+bug/214955 <- here
[10:38] <pitti> \sh: neither bigjools nor cprov are online ATM :/
[10:38] <\sh> pitti, I found it via google
[10:38] <pitti> \sh: we often do search for reverse dependencies
[10:38] <pitti> it's not integrated into the actual soyuz script, though
[10:39] <\sh> pitti, it would be good to do so ... and to resolve those buggers before the actual removal ;)
[10:39] <pitti> agreed
[10:43] <wgrant> pitti: Do you want http://people.ubuntu.com/~ubuntu-archive/removals.txt, or is there another one?
[10:44] <pitti> wgrant, \sh: ^ that's the one that was used up to a few months ago
[10:44] <wgrant> There's something there from two weeks ago...
[10:44] <wgrant> I thought they made it log there again after that feature was removed a couple of months back.
[10:46] <\sh> wgrant, it's not correct this file ;)
[10:50] <crimsun> asac: I recommend for hardy-proposed that we build nspluginwrapper on i386 and readd its libflashsupport dependency.  That seems to be the least invasive change.
[10:52] <asac> crimsun: tough decision
[10:52] <berzerka> hi there ubuntu-devs. nice work you are doing ;)
[10:52] <asac> i agree that we want nspluginwrapper for i386 though.
[10:52] <asac> but for -proposed :/
[10:53] <berzerka> i am trying to rebuild the libusb-0.1.12 source package using dpkg-buildpackage. i installed all build deps (especially jade), but get a lot of jade errors of "undefined elements". what is going on here? might the build dependancies of the package be wrong? any idea how to fix it? (asked on #ubuntu some minutes ago, but no answer as expected)
[10:53] <crimsun> asac: well, we could go with -backports, then
[10:55] <berzerka> (please just tell me if this is not the right place to ask..)
[10:55] <pitti> berzerka: does the package actually stop building, or does it just spit out the errors?
[10:56] <berzerka> pitti: it aborts. dpkg-buildpackage: failure: debian/rules build gave error exit status 2
[10:56] <emgent> morning
[10:56] <pitti> berzerka: eww, that sounds like a genuine bug then
[10:56] <berzerka> the errors are of the kind: jade:../../doc/manual.sgml:12:17:E: element "BOOK" undefined
[10:57] <berzerka> for a huge bunch of elements (he stops after 200 since this is the maximum numbers of jade errors reported)
[10:57] <asac> berzerka: is that hardy?
[10:57] <berzerka> i think there is some jade-module build-dep missing..
[10:57] <pitti> berzerka: weird, though, it built just fine in intrepid some days ago: https://edge.launchpad.net/ubuntu/+source/libusb/2:0.1.12-10
[10:57] <berzerka> asac, yes
[10:58] <pitti> and it built fine in hardy as well
[10:58] <wgrant> pitti: It's not unheard of for packages to go crazy with a dirty build environment...
[10:58] <pitti> but last time it was built on hardy was 2007-11-23
[10:58] <pitti> right
[10:58] <berzerka> pitti: hmm maybe you have (pre-)installed the dep i am missing?
[10:58] <pitti> might be a missing build-conflicts: perhaps
[10:58] <pitti> berzerka: the buildds just install Build-Depends: (and Build-Depends-Indep:), nothing else
[10:59] <berzerka> build-deps were either jade or openjade, tried both with the same result
[10:59] <berzerka> pitti: i don't get you, you mean the automated build bots?
[10:59] <pitti> berzerka: yes
[11:00] <berzerka> i see..
[11:00] <berzerka> strange, then
[11:00] <berzerka> can i confirm wether i have an up-to-date, "clean" hardy install here?
[11:01] <asac> berzerka: you could try to build using pbuilder to be sure
[11:01] <berzerka> asac: never heard of it. i will read up...
[11:04] <berzerka> i have only "hardy" references in sources.list, lsb_release tells me 8.04 hardy and aptitude full-upgrade returns nothing, so i conclude i have an up-to-date hardy installation.
[11:09] <berzerka> what's going on? i did pbuilder --create, and he began installing a hube bunch of system-packages? err... the man-page said nothing about that. well hopefully the required deps are installed at least.
[11:10] <berzerka> ah i see, this is for the chroot environment, right? they are not installed on my system but in the base.tgz chroot-environment..
[11:10] <pitti> berzerka: it just creates a tarball for a chroot environment
[11:10] <pitti> berzerka: exactly
[11:13] <ogra> is a virtualbox module rebuild planned for the kernel in -proposed ?
[11:13] <ogra> (assuming that has to go through SRU as well etc)
[11:15] <norsetto> hmmm, anyone understand what the problem is here: http://launchpadlibrarian.net/14215953/buildlog_ubuntu-intrepid-amd64.gnomeradio_1.7-5ubuntu1_FAILEDTOBUILD.txt.gz
[11:18] <norsetto> I built before uploading and it was fine. I rebuilt now and its fine, those deps all install ok in my pbuilder intrepid chroot
[11:18] <jpatrick> norsetto: I think intltool or one of its dependencies cannot be installed
[11:19] <pitti> norsetto: intltool/libperl-blabla? yes, that seems to hit pretty much every intrepid upload ATM
[11:19] <Hobbsee> tasty, because i just uploaded dput.
[11:19] <norsetto> pitti: arghhh
[11:19] <Hobbsee> pitti: what's hte problem with them?
[11:19] <pitti> I haven't checked
[11:19]  * pitti is on hardy and will stay for another 3 montsh
[11:20] <norsetto> pitti: lucky you :-)
[11:20] <Hobbsee> pitti: wuss :P
[11:20] <Hobbsee> pitti: where's your sense of adventure?
[11:21] <soren> Yeah. Intrepid's fun.
[11:21] <pitti> Hobbsee: I am on the 'fix hardy harder until 8.04.1' team :)
[11:21] <Hobbsee> pitti: oh yeah, that's right.  i guess you're exempt, then....
[11:22]  * pitti spends about two hours on the SRU queue per day these days...
[11:22] <Hobbsee> ouch!
[11:22] <pitti> well, that includes sponsoring, etc.
[11:22] <megabyte405> FYI - the new AbiWord package is up
[11:23] <megabyte405> assuming nobody sees further problems, it should be ready for hardy and intrepid
[11:23] <wgrant> intrepid and hardy-backports?
[11:24] <ogra> likely
[11:24] <wgrant> Or is there some evil plot to do huge version bumps in -updates?
[11:24] <pitti> hardy-backports is a good choice at first, and after some time we should discuss moving to hardy-updates
[11:25] <pitti> wgrant: well, this case is a bit spethial; it didn't get finished in time for hardy final
[11:25] <ogra> pitti, please only with enough testing
[11:25] <megabyte405> Before hardy it was discussed 8.04.1
[11:25] <ogra> pitti, the classmate ships it by default
[11:25] <pitti> ogra: absolutely
[11:25] <wgrant> pitti: So I saw.
[11:25] <wgrant> It was happening sos close to the end :(
[11:25] <ogra> and it shouldnt add deps different des as well
[11:25] <ogra> *deps
[11:25] <pitti> ogra: not without your consent then :)
[11:26] <ogra> gracias :)
[11:26] <berzerka> using pbuilder the package builds successfully! (but i am unable to locate the resulting .deb files)
[11:27] <ogra> look in /var/cache /pbuilder/result
[11:27] <ogra> (without space indeed)
[11:27] <berzerka> how can this be? is my base install broken?
[11:28] <pitti> berzerka: /var/cache/pbuilder/result -> .debs
[11:28] <pitti> berzerka: you probably have a lot more packages installed, teh build might conflict with one
[11:28] <berzerka> this was a gutsy install which i upgraded to hardy.
[11:29] <berzerka> but shouldn't dpkg-buildpackage have told me so when checking the build-deps?
[11:29] <pitti> berzerka: yes; packages can create Build-Conflicts:, but apparently this one does't
[11:30] <broonie> berzerka: Build conflicts are moderately unlikely to get noticed; many people always build in a chroot and even if they don't they may never run into the issue.
[11:31] <berzerka> pitti: soo, this seems to really be a (minor) bug in the package.. i guess you guys would like it fixed. now i got to find out what the difference between my install and the chroot base system is..
[11:31] <pitti> berzerka: thank you!
[11:32] <berzerka> how can i check which version of jade has been installed in the base.tgz?
[11:32] <pitti> berzerka: there's probably a lot, but not so many java related ones
[11:32] <pitti> berzerka: the versions are probably identical, but your normal system has a lot more packages installed
[11:33] <pitti> berzerka: you can 'pbuilder login' and play in the chroot
[11:33] <pitti> berzerka: (changes won't be preserved by default)
[11:33] <berzerka> pitti: nice, thanks
[11:35] <berzerka> pitti: inside the pbuilder shell, where do i find my source-package directory?
[11:35] <berzerka> pitti: i want to try to dpkg-buildpackage from in here, first.
[11:35] <pitti> berzerka: normally it's not there; you can apt-get source it again, or use some mount --bind tricks
[11:35] <berzerka> pitti: alright
[11:36] <pitti> berzerka: it's not a very comfortable chroot for interactive working; pbuilder is mainly designed to build packages automatically
[11:36] <tkamppeter> pitti, thank you for uploading, but it seems that the buildds is currently not able to build s-c-p due to one of the dependencies not getting installed:
[11:36] <tkamppeter> The following packages have unmet dependencies:
[11:36] <tkamppeter>   libxml-parser-perl: Depends: libwww-perl but it is not going to be installed
[11:36] <tkamppeter>                       Depends: perlapi-5.8.8 but it is not installable
[11:37]  * norsetto wonders where he did see that already ....
[11:37] <norsetto> tkamppeter: [12:19] <pitti> norsetto: intltool/libperl-blabla? yes, that seems to hit pretty much every intrepid upload ATM
[11:38] <pitti> tkamppeter's looks slightly differnet, but it might be related to the perl issue
[11:38]  * pitti cnat' tpye toady
[11:41] <\sh> we have also other issues ... tried to upgrade from hardy to intrepid chroot..and it fails for libpam-foosomething and other stuff
[11:42] <berzerka> pitti: if i try to dpkg-buildpackage, i get unresolved build dependancies in the chroot env. dpkg -l doesn't list them too... Unmet build dependencies: debhelper (>= 5.0.22) autotools-dev pkg-config docbook-dsssl jade | openjade. those are about the same deps i was missing in my install.
[11:42] <pitti> berzerka: yes, you need to do apt-get build-dep <sourcepackagename>
[11:42] <berzerka> ah i see
[11:43] <pitti> berzerka: the pbuilder chroot only has the minimal package set (essential and required)
[11:46] <pitti> ScottK: http://launchpadlibrarian.net/14092249/unison_2.27.57-1~hardy1_source.changes -- (1) new unison is in intrepid now, (2) the bug number is wrong, and I can't find a matching one, (3) if hardy final's version is totally broken, this should be an SRU, not a backport
[11:46] <pitti> ScottK: I rejected the package for now
[11:50] <norsetto> I guess we will have kde4 only in intrepid?
[11:51] <\sh> will kde4.1 will be released in time?
[12:17] <berzerka> pitti: i resolved it...
[12:17] <berzerka> pitti: as i see it, docbook has to be added as an explicit build dependancy.
[12:18] <ScottK> \sh: That's the plan.
[12:19] <berzerka> pitti: i had docbook not installed. libusb has only docbook-dsssl as build-dependancy. docbook-dsssl depends on docbook | docbook-xml. since i had docbook-xml installed (don't know why), docbook hasn't been installed transitively.
[12:19] <ScottK> pitti: It's not a question of unison being broken as incompatible.  With what's in the repositories, you can sync among Dapper through Hardy machines, but not with any boxes with the current version.
[12:19] <ScottK> unison has a history of incompatible on the wire protocol changes.
[12:20] <pitti> ScottK: ah, I see; but shouldn't it be an automated backport still?
[12:20] <berzerka> pitti: after installing docbook, it works now. does one of you take care of adding docbook to the build-deps of libusb or should i file a bug for it? or do you see another problem/solution? :)
[12:20] <ScottK> pitti: Now yes, but last week we didn't have it yet.
[12:20] <pitti> berzerka: I don't know exactly, but IIRC there was some weird problem with the docbook dependencies; asac, do you remember?
[12:21] <ScottK> pitti: If you could do an automated backport of unison Intrepid -> Hardy that would be great.
[12:21] <pitti> ScottK: 2.27.57-1~hardy1 ?
[12:22] <pitti> ScottK: done
[12:33] <ScottK> pitti: Thanks.
[13:04] <tkamppeter> pitti, slangasek, about bug 219999
[13:05] <ScottK> tkamppeter: Did you see Debian Bug 479397
[13:05] <ScottK> I thought you might be interested.
[13:07] <tkamppeter> pitti, slangasek, is it needed to have this fixed in Intrepid before it get an SRU for Hardy? I am thinking about replacing the current foomatic-filters already by version 4.0 which is written in C and not in Perl (and also fixes the bug). So it will take some time to the next foomatic-filters package.
[13:07] <\sh> ScottK, or the wish ;)
[13:08] <ScottK> Someone ought to pick it up it seems and the more print stuff is managed in common between Debian/Ubuntu the better off both distros will be, IMO.
[13:12] <tkamppeter> ScottK, thenkas for the info. I am not an official Debian Developer, so I cannot upload directly into Debian. What I can do is to have the packaging managed in a common SVN repo where I make the Ubuntu packages from and someone of Debian only takes snapshots from there to have Debian packages. This way it works with HPLIP currently. The rpos are hosted at Debian.
[13:13] <ScottK> tkamppeter: You don't need to be a DD to maintain stuff in Debian (I maintain several packages there).
[13:13] <ScottK> That sounds sane though.
[13:39] <berzerka> pitti: will you take care of the bug or shall i commit a report for now?
[13:41] <berzerka> pitti: i mean, docbook seems to be definitely required, so i don't see why one shouldn't just add it as an explicit build dependancy.
[13:41] <berzerka> hm maybe i'll just wait for asac to respond....
[13:48] <pitti> berzerka: re (sorry, was at lunch)
[13:48] <pitti> berzerka: the most effective place to report that would be a Debian bug IMHO
[13:50] <pitti> tkamppeter: well, the package is already in hardy-proposed, so that should be answer enough :)
[13:50] <pitti> tkamppeter: ideally the patch would be uploaded to intrepid right now, then that bug is done, and doesn't block on the rewrite
[13:50] <pitti> tkamppeter: but for #219999 the important blocker is now to collect testing feedback
[13:51] <pitti> tkamppeter: there is none at all so far, so we cannot move it to -updates
[13:52] <berzerka> pitti: i am really not confident with reporting a bug which i encounter in ubuntu to the debian devs. does ubuntu completely mirror the debian repositories, or are versions/dependancies managed on its own? if yes, this is a ubuntu bug i would say. one could check wether the same problem exists in the debian repositories, then there would, by chance, exist the same bug in debian as in ubuntu.
[13:53] <norsetto> berzerka: for what you said the bug is not the missing build-dep on dokbook, is the alternative build-deps that doesn't work
[13:55] <berzerka> norsetto: docbook-dsssl depends on docbook | docbook-xml. you mean the error is the dependancy on docbook-xml? (since the package doesn't seem to fully supply what is required..)
[13:55] <norsetto> berzerka: yes, note also that our libusb and docbook-dsssl are unchanged from Debian
[13:57] <berzerka> okay the error seems to exist in debian unstable, too..
[13:58] <berzerka> docbook-xml only suggests docbook and not requires it, but (falsely) satisfies the build-dependancy of libusb.
[13:59] <norsetto> berzerka: yes, if it is really required for dokbook to be a build-depends, than yes, it should be added as an explicit dependency and not to be relied upon being dragged in as a secondary one
[13:59] <berzerka> okay then. i will report a bug at bugs.debian.org. i hope they won't recognize that this error actually stems from a ubuntu system, cause i fear to (rightly) get flamed in that case...
[14:00] <norsetto> berzerka: why should you? We even have usertags for that
[14:00] <jdong> you're unlikely to be flamed for reporting a Ubuntu bug to Debian
[14:00]  * berzerka doesn't know about usertags
[14:00] <berzerka> but okay, if you say so.
[14:01] <berzerka> thank you all very much, i'm glad this issue is resolved, and i can go on debugging libusb :)
[14:01] <norsetto> berzerka: https://wiki.ubuntu.com/Bugs/Debian/Usertagging
[14:02] <berzerka> norsetto: thanks. so i should tag with origin-ubuntu and hardy?
[14:03] <pitti> berzerka: thanks a lot for your effort!
[14:03] <berzerka> hardy doesn't seem to be really relevant here..
[14:03] <pitti> (right)
[14:03] <pitti> berzerka: the packages are mostly straight imported from Debian
[14:03] <pitti> docbook-* and jade*, that is
[14:07] <asac> hmm ... whats the problem? building libusb* still?
[14:07] <berzerka> alright. very helpful you are in here. next time i have a real, distro-related problem i will check back here, #ubuntu is not that helpful in those respects, busy with explaining the user interface..
[14:07] <berzerka> asac: everything resolved, i guess.
[14:08] <tkamppeter> pitti, thanks for the info, testing is so far based only on my daily printing which does not show any regression (I use the patched Hardy package currently and not foomatic-rip 4.0).
[14:08] <pitti> tkamppeter: there must be someone else who also has an affected printer?
[14:08] <asac> berzerka: ok thanks.
[14:08] <berzerka> asac: problem was: i had docbook-xml installed. docbook-dsssl is a build-dep, which depends on docbook OR docbook-xml. but docbook seems to be actually required (and is only suggested by docbook-xml). i will file a bug at debian, the problem exists also in sid.
[14:08] <pitti> tkamppeter: anyway, if you are using the actual binaries from hardy-proposed, please state your own test results in the bug
[14:08] <pitti> tkamppeter: (thanks)
[14:10] <tkamppeter> pitti, I do not have a printer which is affected, I have tested the fix itself by printing into a file when I did the fix for upstream and also when I tested whether the patch has applied correctly to the Ubuntu packages.
[14:10] <pitti> tkamppeter: I guess we'll just wait for the bug reporters then?
[14:11] <tkamppeter> My daily printing is a regression test and shows up to now that the patch does not break anything else in the printing workflow.
[14:11] <pitti> tkamppeter: if none of them answers, the problem can hardly be so pressing
[14:11] <pitti> tkamppeter: ah, that's a good data point to have, though; can you mention this in the bug, please?
[14:11] <pitti> tkamppeter: I mean the regression testing on other modesl
[14:12] <tkamppeter> The original reporter is George Liu from Ricoh (the author of the affected PPD files).
[14:13] <tkamppeter> I have sent mail to him asking to test, but he did not answer yet.
[14:26] <alex-weej> i used ubuntu-bug -p hal
[14:26] <alex-weej> and it didn't attach a device tree dump or anything
[14:27] <alex-weej> who do i nag to fix that?
[14:47]  * soren kicks apt-cacher
[14:48] <soren> It seems to be racy somewhere. I use it to maintain a partial, local mirror, and apt fails with "E: Method http has died unexpectedly!" almost every time if the cache is hot. If there are just a few cache misses in there, or if I strace it (which slows it down a bit), it works great.
[14:50] <pitti> \sh: FYI, we can sync emacs21 next time; libungif4-dev is a transitional package to libgif-dev
[14:50] <pitti> \sh: it should be fixed in Debian (did you report a bug?), but that's not worth keeping a delta for
[15:01] <e-gandalf> hi all. I'm looking for someone who could help me with my plans for UDS in Prague. I'm a local community manager in mozilla, and wanted to meet you and learn from your example. :)
[15:02] <dholbach> e-gandalf: https://wiki.ubuntu.com/UDS-Intrepid has more information on how to get there and when it is, etc
[15:03] <e-gandalf> dholbach: I went through it. What I miss is a schedule (what's on day 1, what's on day 2)
[15:03] <e-gandalf> to choose when it's best for me to be there
[15:04] <dholbach> e-gandalf: the schedule is not up yet but will be generated from the topics that are handed in on LP
[15:04] <dholbach> https://wiki.ubuntu.com/FeatureSpecifications
[15:04] <dholbach> https://wiki.ubuntu.com/TimeBasedReleases
[15:08] <e-gandalf> dholbach: :( Hard to say if I prefer to be on Mon-Wed or Wed-Fri without it :(
[15:08] <dholbach> e-gandalf: I understand
[15:09] <dholbach> maybe you're interested in http://fosscamp.org/ - it will happen before UDS
[15:09] <e-gandalf> could you suggest me? I want to see how you're operating in the community/localization/internationalization field
[15:12] <asac> e-gandalf: i think monday and tuesday will be most active mozilla related discussion.
[15:13] <asac> e-gandalf: actually most upstream related discussion ... we will have more mozilla related discussion the other days too
[15:13] <e-gandalf> asac: unfortunately I can't stay the whole week :(
[15:14] <asac> e-gandalf: ok. i think mon-wed are the better days then. but maybe prod me in a few days, then i can tell you for sure
[15:15] <e-gandalf> asac: great! Thank you. Can you give me your email so that I can poke you? :)
[15:15] <asac> e-gandalf: at best ping me here online.
[15:15] <e-gandalf> ok
[15:15] <asac> e-gandalf: otherwise asac@ubuntu.com
[15:16] <asac> i hopefully will know by wed (day after tomorrow)
[15:16] <asac> cool
[15:16] <e-gandalf> thanks for help. I will :)
[15:36] <\sh> pitti, ahhh....
[15:36] <\sh> pitti, sry well, actually there are only security NMUs somehow, but noted for the next rev: "emacs21 to be synced" :)
[15:37]  * \sh is more annoyed of removing some functionality from config-manager, pybaz removed means no real "bazaar/baz" support
[16:11] <ogra> mvo, do you have any reports about compiz emitting a second keypress on changig workspaces ? its really hard for me to get to the even numbered ones, it always skips one here
[16:13] <mvo> ogra: I can't remember that, but I'm behind the compiz bugs
[16:13] <mvo> ogra: what card is that?
[16:13] <ogra> intel
[16:13] <ogra> ogra@osiris:~/Devel/packages$ lspci|grep -i vga
[16:13] <ogra> 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 03)
[16:14] <ogra> i see it switching to number two in the workspace applet and then see it skip a millisecond later to switch to number three
[16:14]  * soren just had a thought (you heard it here first)
[16:15] <soren> Why the need to subscribe ubuntu-sru to bugs? When the bugs are uploaded to -proposed, they should have the same bug numbers referenced, so it seems a bit redundant.
[16:15] <ogra> looks like a second keypress but thats definately not happening according to xev
[16:20] <seb128> soren: because the sru team doesn't get upload notifications?
[16:21] <soren> seb128: Ah, right. ubuntu-release != ubuntu-sru.
[16:21] <soren> seb128: Good point :)
[16:21] <Hobbsee> correct.  (thank goodness)
[16:22] <seb128> soren: u-r doesn't get mail notification for upload either
[16:22] <seb128> soren: somebody needs to look at the queue to know what is there
[16:24] <soren> But... Hm... So if someone's in ubuntu-sru, but not ubuntu-release, how do they do the SRU thing? They tell someone from u-r to move stuff from -proposed to -updates?
[16:24] <StevenK> soren: u-a
[16:25] <StevenK> soren: -archive does the actual moving
[16:25] <Hobbsee> u-a + canonical employees.  But yeah.
[16:25] <soren> Hobbsee: Eh?
[16:25] <Hobbsee> soren: the subset of ubuntu-archive and canonical employees.
[16:25] <Hobbsee> (as in, don't ask me, i can't do it)
[16:26] <soren> Ah, the intersectin between the two sets?
[16:26] <Hobbsee> er, yes, that.
[16:26] <soren> Ok, I though you meant the union.
[16:26] <soren> I got confused :)
[16:26]  * Hobbsee doesn't have that symbol of her keyboard
[16:26] <Hobbsee> no :)
[16:28] <seb128> soren: the archive tasks are processed regularly usually, there is no need to send notifications
[16:28] <seb128> soren: the sru team benefit from being notified though
[16:29]  * soren goes to subscribe ubuntu-sru to a stack of bugs, then.
[16:30] <seb128> soren: no need to subscribe it to all the bugs, one by upload is enough
[16:34] <calc> seb128: bug 221834
[16:36] <seb128> calc: ?
[16:36] <calc> seb128: you work on dbus right? i was pointing you to that bug that someone brought to my attention :)
[16:36] <seb128> calc: no
[16:36] <calc> oh sorry
[16:36] <seb128> calc: pitti does work on dbus usually
[16:36] <calc> ah, thanks! :)
[16:37]  * calc should read changelog before annoying other devs ;-)
[16:37] <calc> pitti: ping
[16:54] <pitti> hi calc
[16:56] <calc> pitti: bug 221834 :)
[16:57] <calc> pitti: someone from synce team was asking me about that bug earlier today
[16:58] <pitti> calc: oh, sure, we can fix that
[16:58] <calc> pitti: ok
[16:58] <ogra> pitti, could we add vitrualbox-ose-modules to the auto exception for rebuild uploads for SRUs ?
[16:58] <pitti> calc: I'll assign it to me and to the hardy SRU stuff
[16:58] <calc> pitti: ok thanks :)
[16:58] <pitti> ogra: sure, that's sort of implicit for kernel ABI bumps :)
[16:59] <ogra> seems silly to have all the paperwork every time the kaernel changes
[16:59] <ScottK> We do the same thing every time the flash-nonfree md5sum changes.
[16:59] <ogra> pitti, seems blueyed has something ready
[16:59] <seb128> ogra: hey, can you confirm bug #220564?
[17:00]  * ogra checks
[17:00] <ogra> seb128, yes, i dont have anything in my context menu :)
[17:00] <seb128> ogra: can you comment on the bug then?
[17:00] <ogra> i could even check if i had vbox modules for the unning kernel :P
[17:01] <ogra> commented
[17:24] <LaserJock> pitti: are you the one that cleared -proposed?
[17:26] <pitti> LaserJock: define 'cleared'?
[17:26] <pitti> I process the queue every day, yes
[17:26] <pitti> and copy stuff to -updates once it's verified
[17:27] <LaserJock> yeah, but all of a sudden there's nothing for Universe at http://people.ubuntu.com/~ubuntu-archive/pending-sru.html
[17:29] <LaserJock> maybe the update script isn't done running :-)
[17:31] <LaserJock> yep, that's what happened
[17:31] <LaserJock> anyway
[17:32]  * LaserJock hugs pitti for rocking the SRU processing
[17:43] <pjoul> hi! where we store settings of gnome-appearance-properties's desktop effects? thank
[17:44] <Artemis_Fowl> LaserJock: you around?
[17:44] <LaserJock> I am
[17:45] <Artemis_Fowl> LaserJock: good. nixternal told me the other day that he told you about KGRUBEditor
[17:45] <Artemis_Fowl> hmm my syntax sounds strange
[17:46] <Artemis_Fowl> LaserJock: anyway. has there been any process concerning a GNOME counterpart?
[17:47] <LaserJock> well, I mentored a Google Summer of Code project on a Bootloader Manager
[17:48] <LaserJock> https://launchpad.net/ubuntu-bootloader-manager/
[17:48] <LaserJock> there is a bzr branch for it there
[17:48] <LaserJock> I'm not sure how similar it is to KGRUBEditor
[17:49]  * Artemis_Fowl is checking out
[17:50] <LaserJock> I would say it's still pretty alpha-stage
[17:50] <LaserJock> but I thought it showed a lot of promise if development get fired up
[17:50] <LaserJock> *gets
[17:59] <LaserJock> pitti: SRU archive admining question. Do you have a 7-day "aging" requirement?
[18:00] <DktrKranz2> but if a fix is good, it can be
[18:00] <DktrKranz2> (sorry....)
[18:24] <pitti> LaserJock: ah, right, seems you just caught the page update then
[18:24] <pitti> LaserJock: yes, 7 days is the normal maturing period
[18:24] <pitti> LaserJock: for high-urgency bugs, and well-tested packages we shortened it, though
[19:07] <LaserJock> pitti: the SRU policy does not require 7 days though, just 2 positive acks and no negative ones
[19:07] <LaserJock> pitti: we should resolve that discrepency
[19:10] <pitti> LaserJock: it's documented on the linked page: https://wiki.ubuntu.com/ArchiveAdministration#head-1f27dc12ab1558ec21b31ac44e4c86a87a4cd053
[19:11] <ogra> hmm, intresting, running update-manager through ssh -X omits the embedded terminal window option ...
[19:12] <LaserJock> pitti: yes, it's documented there but not on StableReleaseUpdates
[19:12] <LaserJock> I would assume StableReleaseUpdates is the canonical source of SRU policy
[19:16] <pitti> what's the KDE GUI way to edit something as root?
[19:17] <Arby> pitti: kdesu kate or kdesudo kate
[19:17] <pitti> Arby: right, that's what I proposed, but it's far from discoverable
[19:18] <Arby> fair point
[19:22] <infinity> pitti: There's a discoverable way to do it in GNOME?
[19:24] <pitti> infinity: there is nautilus-gksu, if only it wouldn't be broken in hardy final :/ (SRU is in progress)
[19:25] <infinity> pitti: Not installed by default, mind you, which isn't all that "discoverable". :)
[19:25] <pitti> right
[19:25] <infinity> pitti: Looks cool, though.  I mean, assuming I didn't live in a shell/ls/vim world, and liked to click on stuff.
[19:26] <pitti> yeah, it's only at the time when you try to explain "how to configure dual-head under Kubuntu" to an absolute Linux beginner over ICQ
[19:26] <pitti> my great experience with KDE at large, and GUI configuration tools in particular are a great help here
[19:26] <pitti> *cough*
[19:26] <infinity> I'm thinking "how to edit the text file" would be the least of your worries there...
[19:27] <pitti> it requires you to modify xorg.conf (virtual screen size)
[19:27] <infinity> Yeah, it also has the potential for aspoloding X to the point where they might never connect to ICQ again. :)
[19:27] <infinity> (Unless they're on another machine...)
[19:28] <infinity> Does nautilus-gksu just append gksu to any "open" action?  (ie: I could "open as root" an image in /usr/share with The GIMP to mangle my icons directly?)
[19:29] <infinity> Cause the potential for user stupidity every time they get "you don't have permission to edit that" to then just "open as root" and try again would make it a poor candidate for inclusion in -desktop.
[19:29] <infinity> s/append/prepend/
[19:30] <infinity> Gets dangerously close to the Windows "everyone just runs as Administrator, cause it's easier" way of life.
[19:30] <pitti> not sure
[19:35] <ogra> infinity, well, calling the default user root and not setting a password would save us three questions (at least !!) in the installer
[19:35] <infinity> ogra: :P
[20:03] <pitti> infinity: btw, any idea about the intltool/perl issue that causes tons of FTBFS?
[20:05] <pitti> mjg59: for intrepid's pm-utils, at this stage, I'd like to drop 98-unload_network_modules.patch
[20:06] <pitti> mjg59: to give people a chance to report bugs early and get them fixed properly in the kernel; ok with you?
[20:06] <infinity> pitti: Nope!  Example log?
[20:07] <infinity> pitti: (I've been pretty much completely ignoring FTBFSes, as I tend to do during a merge, while things "shake out"...)
[20:07] <pitti> so we just need to give-back packages occarionally?
[20:07] <infinity> pitti: When the queues approach 0, I'll do a mass-give-back.
[20:09] <jeromeg> jdong, ScottK : it seems that during the glest backport to Gutsy glest-data was forgotten which makes this package uninstallable at the moment
[20:09] <jeromeg> could one of you two give an ack if I file a backport request for it ,
[20:09] <jeromeg> ?
[20:10] <ScottK> jeromeg: What's the original backports bug for glest?
[20:10] <jeromeg> ScottK: just a second, I'll find ity
[20:10] <jeromeg> *it
[20:11] <jeromeg> ScottK: or maybe glest-data is still sitting in NEW
[20:11] <jeromeg> ScottK: bug 201182
[20:11] <jeromeg> looks like only glest was backported
[20:11] <gnomefreak> whats with the backport everything the past few days
[20:12] <gnomefreak> omg i see more backport this than anything
[20:12] <jeromeg> gnomefreak: everything ?
[20:12] <gnomefreak> jeromeg: your name has been attached to most of them
[20:12] <gnomefreak> maybe 10 or so a day
[20:12] <jeromeg> gnomefreak: 10 ?
[20:13] <RainCT> gnomefreak: well, backports are cool :)
[20:13] <jeromeg> mmm maybe because there is a gutsy and a hardy bug task
[20:13] <gnomefreak> give or take unless you are telling them its not in intrepid yet more than once per bug
[20:13] <gnomefreak> ah good point
[20:14] <jeromeg> gnomefreak: i'm just contributing to backports because i don't like to see links to getdeb and funky ppa packages in most ubuntu releated websites
[20:14] <ScottK> jeromeg: Lookst like glest-data was not asked for.
[20:14] <ScottK> jeromeg: And it's appreciated.
[20:15] <jeromeg> ScottK: shall I open a new bug report ?
[20:15] <gnomefreak> jeromeg: i dont blame you im just wondering why having the latest is so needed
[20:15] <ScottK> jeromeg: Yes.  Also would you please get in touch with the original reporter and explain about what went wrong so they know better in the future.
[20:16] <jeromeg> ScottK: ok thank you
[20:17] <ScottK> gnomefreak: The why isn't (I think) so important beyond users want it.  I'd rather we support them in official repositories with -backports than they go elsewhere.
[20:17] <jeromeg> gnomefreak: i personnally don't need them and will not use those backports most of the time
[20:17] <jeromeg> ScottK: +1
[20:18]  * gnomefreak thinks some are ok but if you backport too many packages from unreleased/unstable it brings bugs into stable (some that have security mixed with new features i could understand
[20:19] <gnomefreak> im assuming we still dont "support" in any way backports
[20:19] <ScottK> gnomefreak: I can see that, but then what's too many?
[20:19] <ScottK> gnomefreak: It's as unsupported as Universe.
[20:19] <gnomefreak> ScottK: anything that cant fit into SRU do to a couple of new feature
[20:19] <gnomefreak> s
[20:19] <gnomefreak> ummm universe is supported
[20:19] <ScottK> gnomefreak: Not by Canonical.
[20:20] <gnomefreak> right
[20:20] <ScottK> Backports is not supported the same way Universe is not supported.
[20:20] <ScottK> i.e. supported by the community on a best effort basis.
[20:31] <jeromeg> ScottK: i got to go, the package is building at the moment, i'll fill the bug tomorrow
[20:31] <ScottK> OK.
[20:31] <jeromeg> see you
[20:32] <Caesar> tjaalton: (wrt to #113679) can you try a build with the patch I've attached?
[21:00] <hwilde> !seen Keybuk
[21:03] <Company> [21:39] <-- Keybuk has quit (Read error: 104 (Connection reset by peer))
[21:04] <tjaalton> Caesar: I don't have a dapper machine to test on, but maybe my PPA would do
[21:05] <tjaalton> Caesar: thanks for the fix btw, I've just been too busy to do anything with it
[21:21] <jpatrick> hwilde: /msg SeenServ help
[21:23] <hwilde> jpatrick, cool.   i thought ubottu did that too
[21:33] <tjaalton> does a give-back mean that a FTBFS'd package is allowed to get fixed and re-use the FTBFS'd version?
[21:34] <RainCT> tjaalton: only if re-building it without changes to the source will fix the FTBFS
[21:34] <RainCT> (ie, because it was a problem with the buildd, the archive, or something)
[21:34] <tjaalton> RainCT: ah right
[21:34] <tjaalton> thanks
[21:34] <tjaalton> makes sense
[22:11] <mjg59> pitti: Sure
[22:19] <emgent> There is a big problem with requestsync script SMTP server
[22:20] <jpatrick> emgent: worked fine for me today, what's wrong with it?
[22:21] <emgent> i dont know, script print to me "Sync request mailed" but dont work fine.
[22:21] <emgent> i cant see in launchpad bug.
[22:21] <jpatrick> just filed?
[22:22] <cjwatson> (a) there's probably a delay in mail processing (b) if you want to post over HTTPS then use the --lp option
[22:22] <emgent> no, script say "done", but i dont see this sync request in launchpad.
[22:22] <jpatrick> Wait a while, I had to wait about 10 minutes for my bug to show up
[22:22] <emgent> jpatrick: i know, but i was request it some hours ago.
[22:23] <jpatrick> emgent: Which package?
[22:23] <emgent> sympa
[22:26] <emgent> From: emgent@emanuele-gentili.com
[22:26] <emgent> To: new@bugs.launchpad.net
[22:26] <emgent> Subject: Please sync sympa 5.3.4-5 (universe) from Debian unstable (main).
[22:27] <emgent> ..snip..
[22:27] <emgent> Sync request mailed.
[22:27] <emgent> emgent@amnistia:~$
[22:28] <emgent> argh, dont work..
[22:28] <emgent> anyway i go to sleep now, i will try tomorrow
[22:28] <emgent> night peaople
[22:29] <emgent> s/peaople/people/
[22:29] <jpatrick> night emgent
[22:43] <hwilde> any acpi experts ?
[22:45] <mjg59> hwilde: in what respect?
[22:46] <hwilde> what would cause phantom power button pressed messages?
[22:46] <hwilde> system randomly just reboots itself
[22:47] <mjg59> reboots?
[22:47] <hwilde> yep.  it invokes /etc/acpi/powerbtn.sh
[22:48] <hwilde> it says "Power button pressed"  and it reboots
[22:48] <hwilde> i blame the hardware... some type of electrical issue... but the EE people have commented out /etc/acpi/powerbtn.sh and it no longer reboots, so they blame the OS :(
[22:49] <hwilde> but I think it's just going to lock up on them and then they won't be able to turn it off at all
[22:49] <mjg59> Some hardware will do it if it thinks that a thermal trip has occured
[22:50] <hwilde> it seems to be related to usb devices... strange as that sounds
[22:51] <hwilde> plug in a logitech rumblepad controller and the thing reboots repeatedly...
[22:51] <calc> http://blogs.zdnet.com/BTL/?p=8703 <- title of article is funny
[22:52]  * calc would rather spend eternity using windows than one day of solaris (again)
[22:52] <hwilde> careful what you wish for :/
[22:52] <calc> hwilde: i've had the misfortune of having to manage solaris machines before, it was beyond horrid
[22:53] <hwilde> lol it calls opensolaris "an enterprise-class UNIX desktop and server with an Ubuntu-like flavor"
[22:54] <hwilde> i've tried it, it does not taste like ubuntu whatsoever.
[22:54]  * calc wonders if solaris has gotten useful programs like... top, yet
[22:54] <calc> when i last used it (which was a while ago) it had nothing useful installed even with a full install
[22:55] <hwilde> I don't think it's intended to be used....   much more stable that way.
[22:56] <hwilde> but this random rebooting issue has seriously slowed down my development.   uninstall acpi and it's fine...  do I really need acpi ?
[22:56] <rockets> Out of curiosity, and I'm not sure if this is the right place to ask, so I apologize in advance if it isn't, is there any chance of the firefox/flash/youtube crash bug being fixed on "our" side, or is something Adobe has to take care of?
[22:57] <hwilde> do you have a bug #
[22:57] <rockets> hwilde, are you referring to me?
[22:57] <hwilde> i'll take that as a no
[22:58] <rockets> hwilde, actually, I think I do.
[22:58] <crimsun> 192888, probably.
[22:58] <hwilde> thnx i've hit my google quota for the day...
[22:58] <crimsun> and the answer is most likely, look for some nspluginwrapper love from -backports.
[22:59] <rockets> 209442, and a similar bug I think would be 81212
[23:00] <hwilde> wow that's an old one
[23:00] <rockets> hwilde, either way, its pretty widely known that firefox randomly crashes on youtube using the nonfree flash plugin
[23:00] <calc> the nonfree flash plugin doesn't even work well on windows
[23:00] <rockets> calc, speak for yourself.
[23:00] <calc> it constantly is screwing up on my wifes computer
[23:00] <hwilde> sorry I was busy working :/
[23:01] <rockets> calc, It "works for me TM"
[23:01] <calc> she has to restart firefox every few days to get flash working again
[23:01] <mtaylor> is there a wiki page somewhere about the process for proposing something for hardy-updates?
[23:01] <rockets> calc, Anyway, I wasn't complaining. I was just curious.
[23:01] <ScottK> !SRU | mtaylor
[23:01] <mtaylor> ScottK: thanks
[23:01] <crimsun> rockets: please see 192888.
[23:01] <calc> i looked at her computer yesterday and asked her why she was using IE, and it was because flash stopped working again, and she didn't want to have to restart firefox
[23:01] <ScottK> No problem.
[23:01] <rockets> thanks crimsun
[23:02] <calc> hopefully the docs adobe released are good enough to implement a free non-buggy oss flash plugin :)
[23:02] <rockets> calc, thats what im hoping too.
[23:02] <rockets> calc, gnash plays youtube videos just fine without crashing, but not much else.
[23:02] <calc> yea
[23:03] <rockets> crimsun, i see it says a fix was released? hope to see that soon.
[23:03] <ajmitch> running plugins in the same process would tend to be slightly unsafe for that reason
[23:03] <ScottK> Work with YouTube and not for ads would be a feature in my book.
[23:03] <crimsun> rockets: for /which/ source package?  :-)
[23:03] <rockets> flashplugin-nonfree, which doesnt seem possible lol
[23:03] <rockets> since we have no access to the source for that
[23:04] <crimsun> rockets: no, that's correct.  It no longer depends on libflashsupport, which apparently caused more harm than good.
[23:04] <rockets> ahhh
[23:04] <rockets> thats not a fix hehe
[23:05] <rockets> crimsun, it may not depend on it, but at least on my system, WITHOUT libflash support, after a flash movie plays with sound, no other apps can play sound even if i close firefox.
[23:05] <crimsun> rockets: I know full well and addressed that.
[23:05] <rockets> so libflashsupport is somewhat vital, as far as im concerned.
[23:05] <mtaylor> ScottK: I've got a fix on the way for a package which has a regression from gutsy to hardy because of a patch applied in the debian upstream package... I'm not sure if it qualifies as a "severe regression" - but it is a loss of functionality
[23:05] <crimsun> unfortunately, my workaround is a bit too zealous.
[23:05] <mtaylor> ScottK: should I go through the whole process - or is there a way to quickly vet whether or not I'd be wasting tons of people's time?
[23:05] <rockets> crimsun, addressed that as in a fix was released and an update was pushed out? or addressed it as in something is in the works but not done yet.
[23:06] <ScottK> mtaylor: Is the package Main or Universe?
[23:06] <mtaylor> Universe
[23:06] <crimsun> rockets: the latter.  There are two approaches: change pulseaudio's default config, or build an i386 nspluginwrapper package.
[23:06] <rockets> ah
[23:07] <rockets> crimsun, by the way, thank you. of all the ubuntu devs ive spoken to, i think over the last year youve been willing to spend far more time answering my inane questions then was really necessary
[23:07] <ScottK> mtaylor: Then I'd suggest head over to #ubuntu-motu and ask if there is someone from motu-sru who is available to give you an opinion.
[23:07] <mtaylor> ScottK: great. thanks again
[23:07] <rockets> crimsun, and i appreciate it
[23:07] <crimsun> rockets: thanks, but you need not thank me.
[23:08] <rockets> crimsun, i remember you said you maintain alsa for ubuntu, do you maintain pulseaudio as well?
[23:08] <rockets> or you just work closely with them because its obviously a highly related package
[23:09] <crimsun> rockets: no, I no longer maintain them, but I poke once in a while.
[23:09] <rockets> ah.
[23:54] <Pupeno> Hello.
[23:54] <Pupeno> How do I get the same package built for other versions of Ubuntu on PPA?