[00:03] <mterry> Hey, desktop folks, do ya'll use pbuilder or sbuild?
[00:07] <RAOF> sbuild
[00:07] <TheMuso`> sbuild
[00:08] <TheMuso`> Thanks to RAOF, sbuild + tmpfs in RAM for most packages == bliss.
[00:08] <RAOF> It's amazing how much faster disc access is when you're not accessing the disc :)
[00:08] <TheMuso`> I.e a tmpfs is used as an overlay, so installing packages is faaaaaaast. Doesn't impact building much, its mostly to get the chroot set up quickly.
[00:09] <TheMuso`> Hell yeah.
[00:12] <bryceh> mterry, pbuilder.  old timer here.
[00:12] <mterry> bryceh, you and me both apparently
[00:12] <mterry> Was just wondering if I should bother learn sbuild
[00:13] <mterry> I have this set of pbuilder helper scripts that I'm pretty mental-muscle-invested in
[00:13] <TheMuso`> mterry: How do they help you exactly?
[00:14] <mbiebl> TheMuso`: I found eatmydata to be a great alternative to using a tmpfs
[00:14] <RAOF> That closes the performance delta significantly, yeah.
[00:14] <TheMuso`> mbiebl: Yeaht athw rks too, but I have the RAM to throw at tmpfs building so...
[00:15]  * TheMuso` pats thinkpad which was purchased with 40% off, so managed to get it maxed out and still pay under $2K AUD.
[00:15] <mbiebl> TheMuso`: yeah, I have "only" 4 GB of RAM...
[00:16] <mterry> TheMuso`, uh I find normal pbuilder to be quite verbose on the command line.  So I have scripts that do things like "build" or "apt-get source" or "update" for various pbuilder chroots
[00:16] <mterry> TheMuso`, the PES group uses them too, actually
[00:16] <RAOF> mterry: Nice thing about sbuild?  “sudo schroot --all-source-chroots -u root -- apt-get --no-install-recommends --assume-yes dist-upgrade”
[00:16] <TheMuso`> mterry: Right, updating several chroots at once does require a script agreed, but for fetching a source package from a release other than the one you are in, a simple "schroot -c $dist -- apt-get source packagename" works just as easily.
[00:17] <TheMuso`> RAOF: oh wow, thats even better. :)
[00:17] <RAOF> TheMuso`: That's not strictly speaking true; schroot has the --all-source-chroots option which'll apply your command in all your chroots!
[00:17]  * TheMuso` has not read the schroot manpage nearly enough it seems. :)
[00:17] <TheMuso`> Yeah just saw your reply.
[00:18] <bryceh> meh
[00:18] <bryceh>   1 0-23/2  *   *   *    update_pbuilder.cron
[00:18] <mterry> Such long commands!  :)
[00:19] <TheMuso`> Oh sbuild also dumps a build log in the current directory without you needing to specify any arguments.
[00:19] <RAOF> I also like that I have a single chroot for $distro-$arch, and have 4 different configs for it - {standard, build-against-previous-builds}-{standard, tmpfs}
[00:19] <TheMuso`> Anyway, to each their own.
[00:19] <mterry> The PES guys have suggested I make my scripts more widely public, but not sure how much interest there is, if sbuild is viewed as the way forward?
[00:20]  * mterry will have to sit down and learn it at Uds
[00:20] <bryceh> yeah
[00:20] <TheMuso`> I don't think either will die, its a matter of personal preference and what you are used to.
[00:20] <RAOF> I don't think there's anything wrong with pbuilder
[00:20] <TheMuso`> Me neither.
[00:20] <bryceh> TheMuso`, well it'd be nice if there was Just One Way To Fucking Do It
[00:21] <lifeless> we use sbuild in LP, though its a bit mangled
[00:21] <RAOF> Although sbuild, building on schroot, will probably end up winning; it's got more sensible ways of doing things.
[00:21] <TheMuso`> Its open source. There is almost always more than one way to skin a cat.
[00:21] <bryceh> but then I guess we'd all lose geek creds if we were all doing it the same way
[00:21] <lifeless> so sbuild for anyone targeting Ubuntu is a good idea
[00:22] <RAOF> I've not used pbuilder for a while, but when I *last* used it, sbuild was faster too (at the obvious cost of space) as it didn't need to unpack the chroot.
[00:23] <RAOF> For fast builds, the pbuilder setup/teardown was a substantial overhead.
[00:23] <bryceh> RAOF, I'd say that's still true
[00:24] <bryceh> guess I've generally adapted my workflow around that.  e.g. "go get a coffee"
[00:24] <bryceh> mmm coffee
[00:25] <RAOF> That reminds me: my espresso machine will have achieved operating pressure.  Let the pressurised steam be forced through ground coffee!
[00:25] <TheMuso`> The joy of tmpfs building is if its a small package, and most of what I maintain are small in terms of build time, no sooner do I start it off and do something else, than its done building.
[00:26] <jbicha_> I use sbuild, but my lintian has been broken with it for 2 months bug 940410
[00:26] <ubot2> Launchpad bug 940410 in sbuild "lintian doesn't work as of sbuild 0.62.6-1ubuntu2" [Undecided,New] https://launchpad.net/bugs/940410
[00:28] <RAOF> jbicha_: Huh?  Works for me?
[00:31] <jbicha_> here's a little more info: http://paste.ubuntu.com/961379/
[00:33] <jbicha_> I just did a clean install this week too so there shouldn't really be anything non-standard with the system configs
[00:33] <RAOF> Hmmm.
[00:34] <RAOF> That makes it look like your build area's not mounted when lintian gets called.
[00:38] <bryceh> RAOF, do you think it's more beneficial that you and I build things the same way, or different ways?
[00:38] <jbicha_> here's a recent full build log http://paste.ubuntu.com/961385/
[00:38] <RAOF> bryceh: Honestly I don't think it matters.  The build environment is so rarely an issue.
[00:39] <TheMuso`> I think I ended up looking at sbuild because a package that I was working on didn't build properly on the buildds due to tomeouts, so I wanted to try and reproduce locally if possible. Anyway, I've stuck with it since.
[00:39] <TheMuso`> timeouts even
[00:40] <jbicha_> sbuild seemed simpler to set up, mostly http://wiki.debian.org/sbuild and then enabling universe in sources.list
[00:41] <RAOF> They're both pretty trivial to set up, especially with pbuilder-dist in ubuntu-dev-tools.
[00:41] <RAOF> jbicha_: It seems from your setup that you don't have an explicit build output directory set?
[00:43] <RAOF> I *do* have an explicit output directory (so I can build packages against it); maybe that'd avoid whatever broken codepath you're hitting?
[01:04] <jbicha_> RAOF: this upload broke lintian in sbuild for me: http://launchpadlibrarian.net/93727213/sbuild_0.62.6-1ubuntu1_0.62.6-1ubuntu2.diff.gz
[01:08] <RAOF> jbicha_: Hm.  It may well *not* have your .changes file there, then.
[02:22] <psusi> what program/package provides "user accounts" in system settings, or better yet, how do you figure out what program provides a given system settings applet?
[02:35] <jbicha_> psusi: gnome-control-center provides all of the default applets (ie those you would see on any non-Ubuntu-derived distro)
[02:37] <psusi> jbicha_, there seems to be a more functional user management tool in the gnome-system-tools package... the default user management tool used to provide the ability to add/remove users to specific groups, but now it only has options for regular user or administrator... I'm trying to figure out what the inferior component is
[02:38] <jbicha_> inferior's a bit dramatic
[02:38] <psusi> actually, iirc, it used to list specific abilities that were tied to certain group memberships
[02:38] <psusi> like the ability to mount external media, access sound devices, etc
[02:39] <jbicha_> http://git.gnome.org/browse/gnome-control-center/tree/panels/user-accounts is the new GNOME3 default
[02:39] <RAOF> Yeah, but most of those were actually lies.
[02:39] <psusi> RAOF, howso?
[02:40] <RAOF> I don't think anything actually checed those groups anymore; not after ConsoleKit
[02:40] <RAOF> So you could tick or untick those boxes, but it wouldn't change the system behaviour in the ways you expected.
[02:40] <psusi> ahhh
[02:41] <psusi> so instead of updating the tool to configure ConsoleKit settings, the functionality was just removed?
[02:42] <jbicha_> psusi: what's your use case? I think standard/administrator is far more useful than the old complicated dialog
[02:42] <RAOF> I'm not sure ConsoleKit actually *has* any of those settings, and I don't think systemd does.
[02:42] <psusi> jbicha_, depends... iirc, it used to have standard/administrator too, but if you wanted more fine grained control, it was there
[02:43] <jbicha_> I think real sysadmins would use visudo if they need to have more control over that or something similar
[02:43] <jbicha_> home users don't need the complexity
[02:44] <psusi> RAOF, I thought that was one of the driving functions of CK?  but it seems the decisions of say, whether people can auto mount external media and whether they have to authenticate to do so is just burried in distribution provided rules files now instead of being configurable in the gui
[02:44] <RAOF> psusi: I was under the impression that it was basically “are you at a local console?”
[02:44] <jbicha_> or sysadmins could use policykit rules
[02:45] <psusi> sure, but it seems a loss of functionality to go from being able to tweak those rules with the gui to having to understand a complex system and edit config files by hand
[02:46] <psusi> group policy editor seems to be rather popular on windows to do this sort of thing even though you always could edit the registry by hand
[02:47] <psusi> it is nice that now the default policy can be set to "are you on a local console" instead of assigning static group memberships, but changing that default policy seems out of reach for "mere mortals"
[02:47] <jbicha_> that's not really the same thing at all
[02:47] <jbicha_> sysadmins don't edit the Windows registry by hand
[02:47] <psusi> yea, because they have GPO
[02:51] <psusi> at any rate, how can one figure out which program is responsible for a given system settings applet?
[02:56] <jbicha_> psusi: the default ones are http://git.gnome.org/browse/gnome-control-center/tree/panels
[02:57] <psusi> jbicha_, that doesn't really answer the question... is there a way to figure out which executable implements a given one, other than obviously reading through the source code for all of them?
[02:57] <jbicha_> for the others you could find their .desktop in /usr/share/applications and run dpkg -S nameof.desktop
[02:58] <TheMuso`> Hrm, I really think Unity should have the option of showing network mounted filesystem in the launcher, sure maybe not by default, but have the option at least.
[02:58] <jbicha_> that git list is helpful though, run gnome-control-center info to get the Details panel for instance, gnome-control-center user-accounts, etc.
[02:58] <TheMuso`> I often mount network filesystems in GNOME, and have to dig up the computer window just to unmount them again.
[02:59] <psusi> hrm... so the control panel just shows applications with a .desktop file registering them in the X-GNOME-Settings panel?
[03:00] <TheMuso`> I often mount network filesystems in GNOME, and have to dig up the computer window just to unmount them again.~/c~
[03:00] <TheMuso`> grrr
[03:00] <jbicha_> well the app has to be compiled against gnome-control-center but yeah, something like that
[03:02] <psusi> so they are like a shared lib that runs in the context of gnome-control-center?
[03:04] <RAOF> Yes
[05:10] <pitti> Good morning
[05:23] <TheMuso`> Morning pitti.
[05:45] <pitti> RAOF: do you have some time for an SRU round?
[05:45] <pitti> RAOF: we have a kernel bumping ABI now, and I'd like to try whether overriding on the +queue page works
[05:45] <pitti> if not, I can fix the overrides on cocoplum
[05:46] <pitti> RAOF: I can look at the "normal" SRUs now, perhaps you can do the kernel ones?
[05:46] <RAOF> Ok.
[05:48] <RAOF> There's no difference in the procedure for the various arm kernels, is there.
[05:48] <pitti> RAOF: indeed, thehre is not
[05:57] <pitti> RAOF: ah, there are again some kernels which don't go to -security?
[05:57] <pitti> ah, nevermind, these are copies to -proposed
[06:00] <RAOF> Yup.  Everything's going to proposed.
[06:02] <RAOF> https://bugs.launchpad.net/kernel-sru-workflow/promote-to-proposed/+bug/987281 has a prepare-meta task, but no linux-meta-ti-omap4 shows up as needing to be copied on pending-srus.  I presume this is because there's an existing -meta with the same abi in proposed already.
[06:02] <ubot2> Launchpad bug 987281 in linux "linux: 2.6.38-15.59 -proposed tracker" [Medium,In progress]
[06:03] <RAOF> No, that's the wrong one!
[06:03] <RAOF> https://bugs.launchpad.net/kernel-sru-workflow/promote-to-proposed/+bug/985999 is the one I was talking about.
[06:03] <ubot2> Launchpad bug 985999 in linux-ti-omap4 "linux-ti-omap4: 3.0.0-1209.21 -proposed tracker" [Medium,In progress]
[06:03] <pitti> RAOF: right
[06:06]  * pitti OTP, will take a bit
[06:08] <RAOF> Hm.  I may have run into a bug in copy-proposed-kernel
[06:10] <RAOF> Ahem.  No, PEBCAK
[07:07] <mlankhorst> morning :)
[07:16]  * TheMuso` feels squeemish after looking at brltty's cross-platform design.
[07:37] <BigWhale> Good Morning.
[08:10] <pitti> RAOF: ah, you copied the natty-backports kernel? did the main promotion on +queue work?
[08:12] <pitti> RAOF: ah, apparently not: https://launchpad.net/ubuntu/lucid/amd64/linux-image-2.6.38-15-server/2.6.38-15.59~lucid1
[08:13] <pitti> RAOF: ah, the bot reopened bug 990208
[08:13] <ubot2> Launchpad bug 990208 in linux-lts-backport-natty "linux-lts-backport-natty: 2.6.38-15.59~lucid1 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/990208
[09:46] <RAOF> pitti: Everything *looked* good from the queue page.
[09:49] <pitti> RAOF: I filed that as bug 993120
[09:49] <ubot2> Launchpad bug 993120 in launchpad "Copy from PPA with binaries evades NEW and puts new packages into universe" [High,Triaged] https://launchpad.net/bugs/993120
[10:32] <Sweetshark> pitti: have a minute?
[10:32] <Sweetshark> (now or later)
[10:38] <pitti> Sweetshark: sure, what's up? (debugging something ATM, but we can talk in parallel)
[10:42] <chrisccoulson> good morning pitti, Sweetshark
[10:44] <pitti> hey chrisccoulson, how are you?
[10:44] <pitti> chrisccoulson: are you already in Oakland?
[10:44] <chrisccoulson> pitti - not yet, are you? i arrive on saturday
[10:46] <pitti> chrisccoulson: no, me too
[10:46] <pitti> chrisccoulson: just seemed rather late to say "good morning"
[10:47] <chrisccoulson> pitti - yeah, i had to look after my daughter for a bit this morning
[10:50] <pogromca>  does anybody know why phpstorm on dualscreen nvidia twin view config, shows code completion box on wrong screen?
[11:08] <Sweetshark> so what to do with a bug that is fixed in -proposed, but the original reporter doesnt have the bug scenario anymore? https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/818761/comments/10
[11:08] <ubot2> Launchpad bug 818761 in libreoffice "soffice.bin crashed with SIGSEGV in XkbUseExtension()" [Medium,Fix committed]
[11:49] <pitti> Sweetshark: as long as the other bugs are verified, and we are sufficiently convinced that it doesn't regress, it's fine
[12:04] <Sweetshark> pitti: yes, backported and reviewed upstream -- mostly zombie code removal.
[12:30] <Sweetshark> pitti: uploading 3.5.3 to chinstrap, (also still building locally) ...
[12:31] <pitti> Sweetshark: cool; did you build with -v to include the two previous -proposed changelogs?
[12:33] <Sweetshark> pitti: yes
[12:36] <pitti> cyphermox: can I leave the wireless-tools merge to you? I touched it last for a no-change rebuild, but I think you are much more qualified for this
[12:45] <Sweetshark> foolish me started an release build on battery power :(
[12:46] <ogra_> time for bigger batteries :)
[12:52]  * Sweetshark needs nucular batteries ...
[12:53]  * ogra_ wondres what the TSA would say about that :)
[12:54] <Sweetshark> The "I am a LibreOffice maintainer"-excuse got me pretty far up until now ...
[12:55] <pitti> backup for plane engines running out of Kerosin?
[12:55] <chrisccoulson> wtf, we have an explosion in firefox crashes in all releases, with traces that all have flash running in the main process :/
[12:56] <pitti> reminds me of those Enterprise episodes "LaForge, re-route life support energy to the warp coils"
[12:56] <pitti> "... and the energy for that green emergency exit light, too!"
[12:56] <ogra_> heh
[13:05] <Sweetshark> pitti: ETA for the local build to finish: 14:30UTC, prepare to upload by then please (I really want to blog about a same day release)
[13:06] <pitti> Sweetshark: I can upload it now, and then just press the accept button on the -proposed queue
[13:06] <Sweetshark> pitti: that would be great!
[13:10] <pitti> Sweetshark: any chance you could fix the "lp#1234" to "LP: #1234" so that they get picked up by the changelog scanner, call for testing, and pending-sru.html?
[13:13] <pitti> Sweetshark: if these are not that important, we at least have one new bug to report results to
[13:38] <xclaesse> any reason valadoc  version is 0.2+git20110728-2 and not 0.3.2 as in debian ?
[13:38] <xclaesse> folks needs 0.3 to generate its doc
[13:38] <pitti> the source is 0.3.2, but apparently it didn't build
[13:39] <pitti> https://launchpad.net/ubuntu/+source/valadoc/0.3.2~git20120227-1
[13:39] <xclaesse> I would love having -doc packages for folks
[13:39] <xclaesse> it needs build with --enable-docs
[13:39] <pitti> so, it's built on i386/amd64, still needs building on the other arches
[13:39] <ricotz> xclaesse, pitti, the vala-team ppa contains a build
[13:40] <xclaesse> I guess it's totally too late for precise?
[13:40] <pitti> yes, this is quantal
[13:40] <xclaesse> what are the backport policy? it will just not happen?
[13:41] <pitti> xclaesse: for precise-backports its' rather easy to do
[13:41] <pitti> for a stable update, there needs to be proof that it doesn't break any of the existing packages
[13:47] <dobey> pitti: when will quantal daily ISOs start building?
[13:47] <ogra_> dobey, usually around alpha1 time
[13:47] <dobey> oh
[13:47] <ogra_> (should be noted on the release schedule)
[13:48] <dobey> ogra_: alpha1 is there, but doesn't say anything about images
[13:48] <dobey> anyway
[13:48] <ogra_> well, we start building them shortly before A1
[13:48] <dobey> what's the best way to get a quantal vm before that?
[13:49] <pitti> dobey: still too early right now, archive is pretty shaky due to the autosyncs, merges, etc.
[13:49] <pitti> dobey: install precise, and dist-upgrade
[13:49] <ogra_> debootstrap and a chroot i would say
[13:49] <pitti> (... carefully)
[13:49] <ogra_> or what pitti said
[13:49] <xclaesse> pitti, ok so quantal, can folks be build with --enable-docs ?
[13:49] <xclaesse> please
[13:49] <pitti> yes, of course you should debootstrap, or at least install into a VM; don't try it on real iron just yet :)
[13:49]  * xclaesse copies quantal packages into my ppa for backports :)
[13:50] <pitti> xclaesse: sure
[13:51] <ricotz> xclaesse, it might not work since folks requires vala 0.16 and the quantal vala-doc package doesnt build the 0.16 driver
[13:51] <ricotz> the valadoc package needs to get a libvala-0.16-dev b-d for that
[13:52] <dobey> ricotz: well, quantal should have 0.18 as the 'default' vala no?
[13:52] <ricotz> probably, but valadoc treats all libvala versions separately
[13:52] <dobey> ah
[13:53] <xclaesse> ricotz, any reason quantal package does not build for vala 0.16 then?
[13:53] <ricotz> i havent tested it, but it might not work in the current state
[13:53] <ricotz> xclaesse, no, it just misses the b-d
[13:53] <xclaesse> I though everything was 0.16 in precise already
[13:53] <ricotz> xclaesse, please try it first
[13:54] <ricotz> xclaesse, if it isnt working try the valadoc package in vala-team ppa
[13:58] <pitti> Sweetshark: can you please copy libreoffice_3.5.3.orig-src.tar.gz to chinstrap, too?
[14:29] <cyphermox> pitti: yes, I'll look at it this afternoon
[14:29] <cyphermox> (re: wireless-tools merge)
[14:29] <pitti> cyphermox: good morning
[14:29] <pitti> cyphermox: thanks
[14:29] <cyphermox> good morning -- sorry, in a UOW session right now, and technically off today
[14:36] <Sweetshark> pitti: that sleazy tarball is still .tar.gz not tar.xz, dodging my glob.
[14:36] <Sweetshark> uploading ...
[14:36] <Sweetshark> ... done
[14:38] <pitti> no, I'm not envious of your upload bandwith ... no I'm not envious -- I am really not!!
[15:04] <Sweetshark> pitti: as for the lp# reference: we backported that fix already to an earlier release, so it is actually good that they are not firing up any patternmatching.
[15:08] <Sweetshark> pitti: local build finished -- go for it.
[15:29] <pitti> Sweetshark: yay, will do
[15:29]  * pitti bbl
[16:02]  * pitti waves good night
[17:47] <JohnLea> https://docs.google.com/a/canonical.com/document/d/1Bln1VInMg4QvrZsyQpO6XLMWCCQ2UzAkYTwtxOnnczg/edit
[17:48] <JohnLea> https://docs.google.com/a/canonical.com/document/d/1Bln1VInMg4QvrZsyQpO6XLMWCCQ2UzAkYTwtxOnnczg/edit
[21:11] <TonyP> Hi Guys, can you help me with some problems I am having.  These may be because my update to 12.04 was interrupted when my desktop PC crashed.  I recovered from that and have a pretty good 12.04 (at least it doesn't crash frequently like 11.10 did).  One problem is that the login screen doesn't use my wallpaper like it should do.  The other problem is that occasionally I lose the window decoration until I reboot.
[21:17] <desrt> TonyP: 1) sounds like a well-known issue if you're not using one of the system-provided wallpapers
[21:17] <desrt> TonyP: 2) sounds like a compiz bug
[21:20] <TonyP> 1) True, I'm using my own picture.  But I have a netbook that is OK with that.  Does it depend on screen resolution or geometry?
[21:23] <TonyP> 2) Should I re-install compiz?  It might have been corrupted by the upgrade crash.  If yes, what is the package called.  Just compiz?
[21:29] <sil2100> TonyP: presumably a reinstall of compiz-gnome woould suffice
[21:29] <sil2100> TonyP: but you can also reinstall compiz too
[21:30] <sil2100> TonyP: but I'm not sure if that would help - if it won't, it would be nice if you could fill out a apport bug on compiz launchpad
[21:30] <sil2100> TonyP: if you loose decorations, you can always restart them by using, for instance: gtk-window-decorator --replace &
[21:33] <TonyP> Thanks.  If necessary, I'll post a bug.
[21:34] <sil2100> TonyP: thanks