[00:18] superm1: do you recall how it is that mythbuntu liveCD builds get their task lists? [00:18] I don't seem to be able to persuade the buildds to put grub-pc in the livefs === lizthegrey is now known as lizf === lizf is now known as lizthegrey === Guest55641 is now known as Jonb_ === Jonb_ is now known as Jonbo_ [00:58] cjwatson: are you subscribed to partman-auto-raid bugs? [00:59] https://bugs.launchpad.net/ubuntu/+source/partman-auto-raid/+bug/385754 -> "also notified" -- nope [00:59] Launchpad bug 385754 in partman-auto-raid "Can't have a partition outside the disk! error on a preseeded i386 install" [Undecided,New] [01:01] slangasek: right - so I don't think cjwatson is notified [01:01] appears not [01:18] slangasek, they were via meta packages i thought [01:19] is grub-pc not working in just mythbuntu disks, or all? [01:19] we're the only one that does meta packages though, tasks pulled in too much because of the order of dependency resolution [01:19] superm1: it was missing from all the disks; now I've got it included everywhere but mythbuntu [01:19] slangasek, interesting... [01:19] it should come as a recommend to ubiquity [01:20] I guess it's possible that mythbuntu is only getting grub at all because it's a Recommends: of linux-image, and that's being resolved first and satisfies ubiquity's recommends [01:21] why is grub still a recommends of the kernel anyway though? [01:21] is that just some legacy thing? [01:22] can someone point me to documentation on what is different about lpia vs. i386? Ie if I want to compile a package for it, its just extra gcc flags right? === asac_ is now known as asac [01:24] UNR looks to be built the same way as mythbuntu - without a task but instead a meta. is it having the same problems? [01:26] superm1: no, UNR is fine [01:27] superm1: the bootloader is a recommends of a kernel because that's the correct relationship; the wrong bootloader is recommended because we didn't even notice until today that grub-pc wasn't on the CD at all... :) [01:27] (it was working for people, but only with network available at install time) [01:27] hmm i see [01:28] considering the kernel is installed before ubiquity for the cases, i'm perplexed how any of the other builds dtrt then [01:30] oh - it looks like for some reason in the standard ubuntu build grub actually gets removed in favor of grub-pc though http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/ubuntu/20090610.1/livecd-20090610.1-i386.out [01:30] superm1: because grub-pc is explicitly part of the task [01:31] hrmm, removed? so grub-pc does conflict with grub now? [01:31] it always has [01:31] hmm, ok [01:31] which task is it explicitly part of for standard? I looked through ubuntu.karmic's seeds, and didn't see it mentioned in anything but dvd [01:32] pitti: I'm sure you'll see this in your highly efficient email processing anyway :), but I've followed up to bug #201114 - I basically can't reproduce the problem at this point [01:32] Launchpad bug 201114 in openoffice.org-l10n "-help packages need alternate language-support- dependencies" [High,Fix released] https://launchpad.net/bugs/201114 [01:32] superm1: platform.karmic [01:32] superm1: the boot seed [01:33] ah. i wonder if by using meta's for mythbuntu we don't properly inherit things from the boot seed then even though we have an include platform.karmic [01:35] I'm not sure, but I definitely don't see any mythbuntu metapackages that depend on grub, which was already part of said seed [01:35] so there is a disconnect somewhere [01:49] slangasek, i'm rather perplexed on where the disconnect is myself, but i suspect that it's probably something related to us not using tasks. for now, would adding it to ship-live do the trick? [01:49] and as a long term plan, try to get things switched to using tasks so weird disconnects like this don't happen [01:50] if you want to add it to ship-live, that would do it, yes [01:54] asac: Ok, bluetooth audio with pulse for the most part works. I have a headset that can do stereo playback, or headset/microphone mode, i.e the 2 different audio profiles. With the gnome-volume-control-pulse applet, I can't switch between the profiles yet, but I can move a stream to the headset. [01:54] asac: I still have to use pavucontrol to adjust the profile for the bluetooth headset, but its only a matter of fixing up the gnome volume pulse applet UI to deal with profiles, which afaik is coming anyway. [01:55] asac: SO there is in fact not much to do in this area. [01:57] slangasek, okay so i've added it to ship-live, so i'd expect Next build to be OKish [01:58] superm1: that'll be mythbuntu-meta 0.39? [01:58] slangasek, i dont think i need to do a new meta to adjust ship-live [01:58] isn't that part pulled in by ubuntu-cdimage? [01:59] superm1: nope, it's pulled in via livecd-rootfs, which is what pulls in the meta packages :) [02:00] well are we talking about the same thing though? i'm not saying the live seed which is used to build mythbuntu-live meta package, i'm saying the ship-live cd that builds the on-cd-repo [02:00] oh [02:00] you're putting it on the CD but not in the livefs, right [02:00] right at least for now, until i can sort out the tasks problem [02:01] that can work [02:01] we've got the space for it still at least [02:01] in that case, building now [02:01] cool thx === mathiaz_ is now known as mathiaz [02:13] superm1: ah, nope, doesn't work because germinate sees grub-pc already in the live seed, so thinks it doesn't need to duplicate it in ship-live :) [02:13] superm1: so it'd need a meta respin here [02:14] okay, i'll fire up the machine with the meta source and respin [03:01] quick question with this whole paper cut idea and the CDROM eject stuff. In GNU/Linux we mount and unmount volumes .. it isn't really tech speak.. its what we do, wouldn't trying to make it operate more like windows just confuse the crap out of people more.. "I can't eject my CDROM" .. "Well have can you unmount the volume in the command line?" "WTF is mount what.. you sicko!" [03:02] If you right click on the CD icon on the desktop there's a Eject item? [03:02] StevenK: Thats the proposal.. and to create a resource wasting icon in the notification area like you get on windows.. [03:03] Proposal? It already works like that. [03:03] StevenK: Yes, but you also get "unmount" which is correct, apparently this is confusing people [03:06] slangasek, okay 0.39 is in and should have it [03:06] GNUix, Well, there exist cases where one wishes to unmount without ejecting. Should we make this deliberately hard? [03:09] persia: Let me clarify.. I think the way things work right now are fine. What I don't want it all the terminology being changed on my desktop because some people are confused by mount/unmount [03:10] Don't forget that if nothing is accessing the CD/DVD drive, you can press the button on the drive and the disk will eject. [03:11] GNUix, You don't have an "eject" option? [03:11] Or perhaps I misunderstand. Where is this proposal? [03:12] persia: nevermind.. I was refering to a blog post that mentioned this idea of 'paper cut' type bugs to fix small stuff supported by the big C .. one of the ideas is to remove the unmount option from removable media because 'umount' is tech speak.. [03:13] Oh, just in a blog post. Probably better to note use cases that break this in a comment in the post. [03:14] persia: well its not just a blog post, its 'officially' supported and there are bugs in launchpad for this stuff. [03:15] Commenting in the bugs is the best way to present reasons why something oughtn't be done for those things where there are bugs filed. I'm unsure what you mean by "officially supported". [03:19] 100 paper cuts is a spec for Karmic. [03:20] Are each of the paper cuts being identified in the spec? [03:20] I don't believe so [03:21] I'm not sure I understand the point of having a spec in that case, but OK. [03:21] I don't think unmount actually meets the definition of a paper cut, either [03:21] Anyway, I still maintain that if there are bugs being filed about changes that would break some use cases, it's a good idea to identify the use cases to be broken in those bugs. [03:27] pitti: I have ported apport-qt to apport-kde for better integration into the Kubuntu desktop - I have pushed it to lp:~nixternal/apport/apport-kde [03:27] nixternal, i think generally a merge request is better than an IRC ping so it's not easily overlooked :) [03:27] that is there as well [03:28] okay, cool [04:07] I have a query about newer kernels being added to the 8.04 repositories [05:14] hi all... has anyone used the e4defrag? === ScriptRipper_ is now known as ScriptRipper === MooKow is now known as LordKow [06:22] slangasek, looking at http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/karmic/mythbuntu/ it seems that the livefs wasn't even attempted since the new ISO was made. is the livefs still on autopilot, or does it need the magic prod that only slangasek can provide :)? [06:34] good morning === mneptok is now known as mnepton === mnepton is now known as mneptok === tkamppeter_ is now known as tkamppeter [07:15] w00t, tied in apport-qt and easily changeable with apport-kde in all KDE ... Help->Report Bug... menus...hold on to your socks LP, the bug reports will be a coming :) [07:15] KDE will be a bit happier that people aren't filing Kubuntu bugs on KDE Bugzilla now :) [07:17] nixternal, So you can now do the "report a problem" menu items? [07:17] persia: yes [07:17] Excellent :) [07:17] superm1: we're in the "manual builds only" milestone zone, sorry - building one now [07:17] all KDE apps will be able to do that now :) [07:17] as long as they are utiling the KHelpMenu class [07:17] which everything in kde* for us does [07:18] superm1: though I'm far from the only person who can trigger the builds; the release team set has more than one member :) [07:19] what's the procedure for recruiting people to test backports and/or declaring a backport sufficiently tested to go into backports? [07:22] lizthegrey, There's no set procedure. If the bug doesn't get enough, posting to one's blog, adding a request in the forums, trolling in #ubuntu, microblogging, etc. may work. [07:23] persia: don't forget PayPal [07:23] Extra points if you can help extend the team of backport testers to test all the backport candidates. [07:23] slangasek: ITYM, -cdimage ? [07:23] mneptok, PayPal is for *after* you have identified the potential recruits. Payment before presentation of the request is underhanded at best. [07:24] StevenK: well, perhaps - I wasn't presuming that -cdimage members who aren't on the release team would feel comfortable respinning on their own :) [07:24] persia: hah. okay :) [07:24] slangasek: Hehe [07:24] is it customary to provide binary packages for testers to install or to point them at prevu? I'm worried about asking too much of people to Just Trust Me (tm)? [07:24] the package in question is sudo, so... [07:25] I'm not on the backports team, but my memory of the answer to the question in the past is that the intiial backport testers are encouraged to use prevu (or similar tools) for testing. [07:26] yeah, I built my packages using prevu :) [07:26] I suspect that's more an attempt to limit testing to people who can recover after breaking their system than an actual requirement, but I don't know the actual policy. [07:27] ah. [07:28] Good morning [07:28] I'll gpg sign the binaries, so since I'm relatively plugged into the WOT people can go after me with pitchforks should things not be on the up and up :) [07:28] Morning pitti [07:29] bug in question is https://bugs.launchpad.net/hardy-backports/+bug/384100 in case one is curious :) - I'm trying to get sudo 1.7.0 from karmic backported to dapper and hardy since being able to #include a sudoers file fragment is a lot easier/more scalable than mangling the sudoers file programatically :) [07:29] Launchpad bug 384100 in hardy-backports "Please backport sudo 1.7.0-1ubuntu1" [Undecided,Confirmed] [07:30] nixternal: oh, nice! will take a look at it [07:31] hey StevenK [07:31] slangasek: right, saw your reply; nice to hear [07:32] pitti: well - have I reached the right conclusion? :) [07:32] maybe there's still a bug but we've misdiagnosed? [07:32] slangasek: I'll check it in a minute, when I get to that mail [07:32] okie [07:39] Does anyone have any idea about this error when trying to setup texlive-base - dpkg-trigger: dpkg-trigger must be called from a maintainer script (or with a --by-package option) [07:39] Using dpkg-reconfigure? [07:40] slytherin: ^ [07:40] soren: the problem is occurring on powerpc buildd. I haven't tried local build yet. [07:41] If so, it's bug 198421 [07:41] Launchpad bug 198421 in debconf "DPKG_MAINTSCRIPT_PACKAGE not set by dpkg-reconfigure causing dpkg-trigger to fail" [Medium,In progress] https://launchpad.net/bugs/198421 [07:41] slytherin: Ah. Then I don't know. [07:42] perhaps kees has any idea. He is the latest uploader of texlive-base. [07:42] slytherin: I think that bug was fixed. I retried a build the other day that had something similar, and the build worked, so I'd suggest try to update. [07:43] TheMuso: The bug is with latest package as well AFAIK. I will still try rebuild and report back. [07:51] TheMuso: build still failing with same error. The package in question is tuxguitar. [07:52] slytherin: hrm ok hang on a sec. [07:52] slytherin: is this on the buildds? [07:54] TheMuso: yes, powerpc buildd. I didn't find time to try a local build. [07:54] ok [08:07] slytherin: This is very weird, as its building for me locally. I guess since my local mirror hasn't been updated, there is no new breakage... [08:08] TheMuso: I will try building locally time with fully updated karmic chroot and report back. [08:08] ok [08:09] slangasek: nack, apt-get install language-support-de still pulls in openoffice.org-common openoffice.org-core [08:10] * pitti investigates [08:13] slangasek: ah, it's -thesaurus [08:16] slangasek: bug updated [08:57] evand1: hm, does usb-creator work for you? I just wrote the current karmic desktop amd64, and when booting it just drops me into initramfs, with lots of "cannot find image on /dev/sr0" [08:57] pitti: yikes, checking now [08:58] * pitti tests in kvm [09:11] evand1: .iso works in kvm, so I think it's not generally broken [09:15] okay === cjwatson_ is now known as cjwatson [09:32] geser: argh, seems that the recent pkg-create-dbgsym whitespace fix broke things: http://launchpadlibrarian.net/27762179/buildlog_ubuntu-karmic-i386.dictd_1.11.1%2Bdfsg-2_FAILEDTOBUILD.txt.gz [09:37] geser: I'll write test cases for bug 384597 and the new breakage [09:37] Launchpad bug 384597 in pkg-create-dbgsym "pkg_create_dbgsym doesn't cope with multi-line Depends, Suggests, etc." [Medium,Fix released] https://launchpad.net/bugs/384597 [09:38] slytherin: that's been on my list to look at, but it's completely non-obvious ... [09:39] slytherin: it's unlikely to be texlive-base's fault, and the code in dpkg *looks* ok [09:43] cjwatson: right. Unfortunately I didn't find time since we last discussed this issue. I will try to find time sometime this week. === ziroday is now known as zeroday === zeroday is now known as ziroday` === ziroday` is now known as ziroday [10:16] tkamppeter: hm, seems I can't find your patch on http://bugs.debian.org/cgi-bin/pkgreport.cgi?src=poppler, which bug was that? [10:22] pitti: what patch are you looking for? I sponsored some poppler changes a week ago [10:22] ie bug #335397 [10:22] Launchpad bug 335397 in poppler "Poppler's pdftops fails to convert a PDF file to PostScript" [Medium,Fix released] https://launchpad.net/bugs/335397 [10:22] bug #382379 [10:22] Launchpad bug 382379 in cups "pdftops CUPS filter has several problems" [High,Fix committed] https://launchpad.net/bugs/382379 [10:22] pitti: ^ [10:23] seb128: I know, I thought Till already created a Debian bug for it [10:23] ok ignore me then that was in case the information was useful ;-) [10:23] but nevermind, it's fixed upstream; it'll land there eventually, and until then I do a small hack in cups [10:23] * pitti hugs seb128, merci [10:23] * seb128 hugs pitti [10:30] cjwatson: you remember I was asking how to declare an extern array in a header file? [10:30] I remember why I didn't think that was correct, now [10:30] tests/com.netsplit.Nih.Test_object.h:23: error: array ‘my_interfaces’ assumed to have one element [10:33] looks like it has to be explicitly extern [10:34] Keybuk: explicitly extern is what I said, I think [10:36] yeah it was [10:36] sorry, I was attempting to confirm what you said in a strange way :p [10:36] ah :) [10:43] lool: any chance to upload current poppler 0.11.0 to Debian? Otherwise I have to jump through some hoops in cups [10:44] tkamppeter: ^ you bumped libpoppler-dev to >= 0.11 for the new pdf filter [10:46] pitti, he's travelling this week, i doubt he has much time for package maintenance work [10:46] oh, ok [10:46] (or much connection) [10:58] cjwatson: I'd assumed since it was in an extern "C" { ... } block, that'd be enough [10:58] but, of course, that's C++ :p === BenC1 is now known as BenC [11:08] pitti, I did this for the addition of the pdftoopvp filter which I did last week. [11:09] pitti: ^ the libpoppler-dev >= 0.11 dependency [11:10] tkamppeter: I know [11:10] I'll mail you shortly with some details [11:11] pitti, is lool the Debian maintainer of Poppler? [11:11] tkamppeter: yes (one of them) [11:11] debian doesn't track unstable series though [11:12] ie they don't use 0.11 [11:12] not sure if that makes a different for what you want to do [11:13] oh, I see [11:13] tkamppeter: how urgent is it to get the pdftoopvp filter? [11:16] pitti, I simply got the filter from the upstream developer Koji Otani from OpenPrinting Japan. Japanese printer manufacturers, like Canon for example, want to have this filter. [11:16] tkamppeter: so if 0.12 doesn't get released soon, we have to do another dynamic check at build time [11:16] but for now I just disable it, in order to get the fixed cups to debian/ubuntu ASAP [11:17] Poppler 0.11.0 has API additions developed by Otani to make the pdftoopvp filter possible [11:17] So 0.11 is a development series, like an odd-numbered kernel? [11:18] similar to GNOME naming scheme [11:18] pitti, can we perhaps make this filter Ubuntu-only for the case that 0.12 does not make it into Debian before our FF? [11:19] tkamppeter: yes, see above [11:19] but I'd really like to upload -3 right now [11:19] tkamppeter: you have mail now [11:21] OK. Thanks. [11:21] Is lool on vacation? [11:21] pitti: new poppler stable will be in one month apparently [11:21] or that's the schedule they work on [11:21] tkamppeter, Earlier backscroll said he was travelling, but didn't specify purpose. [11:21] cool, that should fit [11:22] tkamppeter: no, but he's in the US this week I think === nenolod_ is now known as nenolod [11:31] asac, about bug 385325, will TB beta be in karmic in time ? [11:31] Launchpad bug 385325 in thunderbird "[armel] thunderbird-bin crashed with SIGSEGVI" [Medium,Confirmed] https://launchpad.net/bugs/385325 [11:31] s/beta/3/ === azeem_ is now known as azeem [11:36] ogra: we had this discussion with NCommander in #ubuntu-mozillateam [11:36] ogra: i wouldn't count on it. upstreawm has no strict commitment [11:36] ogra: so i told him how to do a proper debug build and we can check what we can do for tbird 2. but most likely its more than one patch [11:38] cjwatson: what was the tool again to display X.org resource usage? (for memleaks, etc.) [11:39] xrestop ? [11:46] cjwatson: hi. now that gpsd is built on sparc, could you retry the viking build at https://edge.launchpad.net/ubuntu/+source/viking/0.9.8-2/+build/1068859 ? thanks. [11:48] pitti, Otani has also provided two patches for Poppler 0.10.x to make it supporting pdftoopvp. [11:49] pitti: One is to make Poppler build. It is simple, around 10 lines. The other is to add color management support. Could be an alternative approach for Debian. [11:49] tkamppeter: right, let's talk to lool when he's back [11:55] pitti: xrestop was indeed the one I mentioned a while back [11:55] seb128: ^ might help you to check memleak [11:55] cjwatson: thanks! [11:56] ok [11:56] Ampelbein: done [11:56] brb [12:23] http://git.gnome.org/cgit/evolution-data-server/commit/?id=d17494da8ebaba8673a581f256efc8a1d41e1e40 [12:23] *grin* [12:36] Chipzz: lol [13:07] how are you supposed to update debian/applied-patches/ when doing a merge? [13:08] james_w: patch -p < change? [13:08] seb128: apply them again? [13:08] again? [13:09] the idea is to have the patches in the debian directory for things not using a patch system, ie having changes in the diff.gz [13:09] it makes easier to know the changesets [13:09] yeah [13:09] or rather a copy of the patches applied to the diff.gz [13:09] but now I've just merged with Debian [13:09] so the patches there are out of date [13:10] well update those with the changes you applied [13:10] yes [13:10] but how? [13:10] or clean those if some are not applied in the new version [13:10] diff -u file.debian file.ubuntu? [13:10] that assumes they are separated by file though [13:10] no, that assume you have a logical order [13:10] you start from debian [13:10] reapply a changeset [13:11] diff and put that in a patch [13:11] copy the dir and reiterate [13:11] ie [13:11] source [13:12] cp -R source source.debian, work in source to apply the first changeset you work on, diff -Nur source.debian source, copy the patch [13:12] and iterate that way for each successive change? [13:12] well, I'd rather have 3-way merge, and not have to do all that by hand, so I think I'll just delete them all [13:13] *shrug* [13:13] which means next time we have no idea of the logical changesets [13:13] well, the aim would be that next time there are no changes [13:14] and I'll make bzr branches anyway [13:15] I think the best strategy here depends on the class of package. For those packages where we *always* carry a change (e.g. branding, menu cleanup, launchpad integration) it makes sense to logically differentiate the patches, even if this makes merging different, because that way we can easily reapply the stuff that always needs to be applied. [13:16] For those packages where we *can* be in sync with Debian, keeping track of all that is just overhead, because we ought to get the right stuff into Debian anyway. [13:16] liw: So... :-) [13:16] ion_, still digging, but I'm seeing light at the end of the tunnel already [13:16] :-) [13:17] Already got the amulet of Yendor from the bottom? [13:17] james_w: so where can i find your latest daily build tools? [13:17] that would be a reference to the game I played for an hour without realizing it had more than one level [13:17] asac: bzr-builder on launchpad [13:17] * asac checks that [13:17] thx [13:18] Heh [13:35] sbeattie: I can't manage to reproduce bug 250400; simply unsetting HOME and running make-ssl-cert in the same way as ssl-cert.postinst runs it doesn't seem to be sufficient. Obviously this is holding me up from uploading a fix. I don't suppose you might have a moment to see if you can reproduce it? [13:35] Launchpad bug 250400 in ssl-cert "make-ssl-cert fails if HOME is unset or empty" [High,Fix released] https://launchpad.net/bugs/250400 [13:44] * macvr wonders if any dev is working on a gui for sound the equalizer ... === thekorn_ is now known as thekorn === dendrobates-afk is now known as dendrobates [15:03] still many problems with the RT-kernel [15:05] Indeed. It doesn't even boot properly. Of course, if I didn't already know that, your report wouldn't be helpful in that format, but you've already left :) [15:06] heh [15:06] he does that once a week [15:06] i wonder if its a script :P [15:08] Hard to say. I suspect -rt would be more likely to work if there had been more communication earlier. [15:09] or at all :) [15:09] beyond a guy joining here once a week, saying a sentence and signing off .... post-release :) [15:10] Oh, that was about jaunty? I thought it was about karmic. The jaunty -rt worked the last time I tried it (although that may have been a late alpha, rather than a beta). [15:11] well, the last times i saw him here he complained about jaunty rt [15:11] always signing off immediately after that :) [15:11] slangasek: OK, so I'm going to look into getting rid of acpi-support's ac.d and battery.d unless you cry foul [15:11] Right. Internet Relay Microblogging. [15:11] heh [15:16] slangasek, i'm still frazzled, that meta package now explicitly calls out grub-pc, but the livefs still came out with grub and grub-common [15:17] slangasek, oh wait, nvm, grub-common is there and grub-pc is, not normal grub. so it's right this time [15:26] james_w: ping [15:26] hey robbiew [15:27] james_w: are u still waiting on feedback on the kerneloops stuff? [15:27] robbiew: yeah, I'm interested if my idea is the right way to go about it [15:28] well, firstly if indirecting through apport is the right thing to do [15:28] and then if that's the right way to do it [15:28] james_w: FWIW, I think so, but cjwatson is probably a better person to ask :P [15:28] technically speaking [15:28] there's no real rush though [15:28] okay [15:28] it's open in my browser, in my queue of stuff to review [15:28] james:w: just didn't want you blocked on a response from me [15:29] thanks [15:29] heh...my browser queue got so long, firefox crashed...that is when I had to split the blueprints based on priority :P [15:29] I'm just trying to get my own specs written before reviewing everyone else's, plank in one's own eye etc. :-) [15:29] heh [15:40] about 3 nights ago Apport did some serious email spammage removing coredumps from bug reports -- anyone know what that was all about? [15:40] actually it was 2 nights ago [15:42] alex-weej: it was about removding coredumps from duplicates [15:42] alex-weej: they take space and can contain sensible informations [15:44] ah ok [15:44] (you mean sensitive btw :P) [15:55] alex-weej, both! [15:55] ;) === herb__ is now known as herb [16:24] seb128, about bug 258421 [16:24] Launchpad bug 258421 in gtk+2.0 "GTK apps should send PDF to CUPS when printing" [Medium,Fix released] https://launchpad.net/bugs/258421 [16:25] seb128, saw your last comment now, thanks. [16:27] whoa. vte corrupted "N" (upper-case n) [16:34] cjwatson: re bug 250400 I have a vague recollection of being unable to reproduce it as well. [16:34] Launchpad bug 250400 in ssl-cert "make-ssl-cert fails if HOME is unset or empty" [High,Fix released] https://launchpad.net/bugs/250400 [16:34] but I'll give it another go. === dashua__ is now known as dashua === robbiew is now known as robbiew-afk === yofel_ is now known as yofel === rmcbride_ is now known as rmcbride [17:45] cking: can you get us anything more on bug 385916? we can't do anything with it as it stands. If you can reproduce it, the files we actually need from the running installer are /var/log/syslog and /var/log/partman [17:45] Launchpad bug 385916 in ubiquity "ubiquity install failure, auto-resize, karmic alpha " [Undecided,New] https://launchpad.net/bugs/385916 [17:47] cjwatson: I will reproduce it and attach the appropriate logs [17:47] thanks [17:48] it's kind of hard to know what to attach. Maybe next time I tar up all of /var/log.. [17:48] in general, for installer bugs we only need /var/log/syslog /var/log/partman and possibly /var/log/installer/debug [17:48] everything else is duplicated or useless [17:49] to a first approximation anyway [17:49] OK. Will note that down. [17:49] shame apport failed, could be the filesystem is a bit busted [17:49] I'm worried it's due to re-sizing an already existing ext4 fs [17:54] cking: you said it was near the end though, wouldn't that be after partitioning? [17:55] or was that not what you meant? [17:55] oh yes. I didn't think that through [17:56] well, depends what you meant by "end" I guess :) [17:56] could be 385995 although I'm surprised at that causing ubiquity to blow up like that rather than display a "help me" dialog [17:57] oh, actually it might [18:10] ..reproducing this is taking sometime.. hopefully done in 10 more mins === rickspencer3 is now known as rickspencer3-afk [18:19] bother.. did not reproduce it that time. Trying again. [18:35] cjwatson: tuxguitar builds fine locally. So the texlive-base issue that causes FTBFS for tuxguitar is surely powerpc buildd problem. [19:00] apw: Can you give me some pointers on how pm-powersave is supposed to be called with our new devicekit-power overlords? I gather it used to be called by gnome-power-manager? [19:03] mterry, i though pre devicekit that gnome-power-manager sends out dbus requests, which hal picks up and runs the pm-* stuff [19:03] not sure how that is changed by devicekit [19:03] apw: Correct [19:04] apw: OK. Current g-p-m seems to no longer call anything similar. Trying to trace it down. [19:04] apw: I'm assuming that pm-utils still has a place in this new scheme? [19:05] as i understand things it is still called to suspend stuff, right now devkit isn't passing in the quirks i believe [19:10] apw: Yeah, OK. There are analogous Suspend and Hibernate calls in dk-p that call pm-suspend and pm-hibernate. Just seems that SetPowerSave is missing. I'll ask upstream what the intention is [19:10] The open source driver for my new laptop’s WLAN adapter doesn’t support this model, but is still able to upload the firmware to it. The proprietary driver “works”, but seems unable to upload the firmware. rc.local: modprobe (free driver), modprobe -r (free driver), modprobe (evil driver), and i can has networking. :-D [19:13] * hyperair claps. now, did we really need to know that? [19:21] cjwatson: commented on bug 250400, I managed to reproduce manually. [19:21] Launchpad bug 250400 in ssl-cert "make-ssl-cert fails if HOME is unset or empty" [High,Fix released] https://launchpad.net/bugs/250400 [19:25] cjwatson: log files attached to bug report === robbiew-afk is now known as robbiew === DrKranz is now known as DktrKranz [19:56] slangasek: ping about power management when you get the chance. I'm curious if pm-utils is an accepted part of the new world order, or if we want to move all of its power.d scripts to be some part of udev [19:56] mterry: yes, pm-utils isn't supposed to go away [19:57] pitti, can you have a look at bug 385606? [19:57] Launchpad bug 385606 in ubuntu-meta "Print test page gives an error message "unsupported format: application/postscript"" [High,Triaged] https://launchpad.net/bugs/385606 [19:57] pitti, seems that ghostscript-cups needs to be added to one of the seeds, so that it gets pulled into updates of both desktop and server. [19:57] slangasek: OK, cool. So, do you happen to know much about devicekit-power and its lack of calling pm-powersave? It's not in the dbus API. Thinking we'll have to call pm-powersave in acpi-support now [19:58] mterry: we definitely shouldn't be calling it in acpi-support, which is slated for execution. You might want to check with pitti about where it's supposed to wind up [19:59] slangasek: Well. OK. Where are the bits of acpi-support that are 'methods of last resort' when a power-manager isn't running slated to end up? [20:00] mterry: when we get to the point that those are the only thing left, we should be able to unseed acpid and acpi-support from the desktop [20:00] arguably there should be some console-friendly power manager to replace them, that also hooks in via devicekit [20:00] but I don't know that anyone's working on this [20:00] slangasek: Agree, but I'm not writing it. :) [20:01] mterry: hm, sounds worth an upstream bug report, I think [20:01] mterry: it sounds like something dk-power could handle, but I'm not 100% sure [20:02] pitti: Yeah. I was going to ask the mailing list. There's the fear that it might be intentional and dk-p won't do it. I need upstream clarification [20:02] mterry: devkit-devel@ is a great place to ask, too [20:02] mterry: I'm not a DK guru yet myself, I'm afraid [20:03] * pitti -> off again [20:03] slangasek: We can drop it from the seed once the user is never left w/o a manager. I assume that means when we switch to new GDM? [20:03] mterry: yeah, I suppose so [20:04] (right, GDM, argh) [20:04] pitti, you are aware that if you make cups depending on ghostscript-cups, you create a circular dependency? [20:05] tkamppeter: eww, why does ghostscript-cups depend on cups? that sounds backwards [20:05] pitti: Because it's useless without it, I'd assume? [20:06] *shrug* /me demotes to Recommends [20:06] ghostscript-cups provides PPD files, so it updates PPDs of existing queues. For updating PPDs of existing queues cups and cups-client are required. [20:06] pitti: Not that circular deps in such low priority packages are a huge deal. dpkg will just randomly unroll the loop. [20:07] yeah, but still.. [20:08] I still think it's more logical for cups depends: ghostscript-cups and ghostscript-cups recommends: cups [20:08] pitti: If it actually calls cups bits, it kinda needs to be a dependency, policy-wise. [20:09] pitti, but what happens than on a distro upgrade (or any update where both cups and ghostscript-cups get updated)? Will the CUPS daemon be running when the postinst script of ghostscript-cups is run? [20:10] Oh eww, if they need to be configured in a specific order, then you can't have a loop. :/ [20:10] tkamppeter: yes, with the dependencies being this way around [20:11] pitti: Which way around? [20:11] g-cups depends: cups [20:11] and cups recommends: g-cups [20:11] pitti: Ahh, you wrote it the other way above. [20:11] cups' postinst doesn't do anything magic wrt. detection, so that should be fine [20:11] infinity: right, it would seem more logical the other way round [20:11] pitti, CUPS itself does not need ghostscript-cups, if you have only PostScript printers and/or printers using Foomatic, you do not need ghostscript-cups. [20:12] but the other drivers also use this order [20:12] tkamppeter: okay, so recommends makes sense [20:12] similar to cups-driver-gutenprint [20:13] So I would then rather add a "Depends: ghostscript-cups" to all CUPS Raster drivers, currently splix, gutenprint, and hplip-cups. [20:14] The reporter of bug 385606 most probably uses splix, and so the dependency in splix wiull pull ghostscript-cups for him. [20:14] Launchpad bug 385606 in ubuntu-meta "Print test page gives an error message "unsupported format: application/postscript"" [High,Triaged] https://launchpad.net/bugs/385606 [20:14] pitti, so put a Recommends: into cups, leave ghostscript-cups alone, and I add a Depends: to the CUPS raster drivers. [20:17] pitti, for updates the default-installed CUPS Raster drivers will pull ghostscript-cups then ... [20:29]