[00:12] <happyface> anyone else experiencing screen flickering in the beta?
=== yofel_ is now known as yofel
[01:03] <infinity> ScottK: How is that different than the situation's been for the last month? :)
[02:07] <happyface> anyone else experiencing screen flickering in the beta?
[02:28] <micahg> ScottK: have you tried build qtwebkit with -Wl,--no-keep-memory?  that worked for webkitgtk
[03:07] <infinity> micahg: Ooo, I wasn't aware of that linker flag.
[03:07] <infinity> micahg: I'm betting that would do it.
[03:08]  * infinity headdesks.
[03:09] <infinity> And the upload that updated the symbols for armel didn't add armhf at the same time.
[03:10] <infinity> That's easy enough to fix, at least.
[03:10] <infinity> ScottK: I'll try micahg's suggestion on my Panda.
[03:10] <infinity> ... after I find an SD that actually has an OS on it.
[03:56] <infinity> shadeslayer: Don't worry about qtwebkit-source on armhf, I have a testbuild going right now, and will upload in the morning, I suspect.
[03:56] <infinity> micahg: So, looking at the actual packaging for this might have been helpful, instead of people blaming toolchains and kernels.
[03:57] <infinity> micahg: My guess is that armel being built with -gstabs, and armhf being built with -g might relate (testing that theory now).
[03:57] <micahg> infinity: heh, we just made the change recently
[03:58] <infinity> micahg: Your suggestion is probably also a valid an reasonable one, given the borderline memory usage issues of all things webkit.
[03:58] <infinity> micahg: But I'm betting that "make armhf build the same way as armel" will magically fix it.
[03:58]  * infinity really needs to rgrep for armel in debian/rules across an entire lintian lab. :/
[03:58]  * micahg isn't sure what -gstabs does
[03:59] <infinity> micahg: Different debugging format.
[04:00] <infinity> Aside from being less verbose than DWARF2 (which could explain the difference in memory usage), it's also apparently causing other issues on some platforms with qtwebkit, which was why it was swapped.
[04:00] <infinity> I dunno.
[04:00] <infinity> Not my package.
[04:00] <infinity> But if this fix works, I'll be kicking myself for not just looking at debian/rules 2 months ago.
[04:02] <micahg> infinity: I did the same thing with chromium except it was something in debian/control that was the final fix
[04:02] <infinity> Just needed an s/armel/armel armhf/ ?
[04:02] <micahg> infinity: yep :)
[04:03] <infinity> Yeah, I suspect there are a lot of those left in the archive in some form or another.
[04:03] <infinity> Hence the lintian lab mention.
[04:03] <micahg> infinity: talk to broder, he might be able to help
[04:04] <bkerensa> Getting a weird error when trying to bzr branch bash
[04:04] <bkerensa> bzr: ERROR: Revision {steve.langasek@canonical.com-20111106190907-jzcpeo7ol1yuyip3} not present in "Graph(StackedParentsProvider(bzrlib.repository._LazyListJoin(([CachingParentsProvider(None)], []))))".
[04:04] <bkerensa> <bkerensa> "
[04:04] <infinity> Pretty.
[04:06] <bkerensa> indeed
[04:06] <bkerensa> :P
[04:06] <infinity> If at first you don't succeed, screw it and work on the source package directly? ;)
[04:31] <ScottK> micahg and infinity: thanls.
[04:35]  * infinity wonders how all those builders landed in ABORTED...
[07:33] <AnAnt> Hello, would someone sponsor: LP 946660
[07:33] <ubottu> Launchpad bug 946660 in fuse (Ubuntu) "Remove loop-aes-utils from Conflicts" [Undecided,Confirmed] https://launchpad.net/bugs/946660
[11:59] <verwilst> SpamapS, hello, wrt https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-php54,is php 5.4 still on track for precise inclusion?
=== yofel_ is now known as yofel
[13:40] <geser> pitti: re your comment on bug #871907: sorry for causing you trouble with this change. As it also causes problems with colorscheme I'm undoing it. Have you time to sponsor the debdiff from bug #951440?
[13:40] <ubottu> Launchpad bug 871907 in vim (Ubuntu) "vim should have "set bg=dark" by default" [Wishlist,Fix released] https://launchpad.net/bugs/871907
[13:40] <ubottu> Launchpad bug 951440 in vim (Ubuntu) "vim-gnome ignores colorscheme setting from vimrc" [Undecided,Confirmed] https://launchpad.net/bugs/951440
[14:29] <mikecb> ScottK: have you tried with -no-keep-memory, --hash-size, or --reduce-memory-overhead?
[16:20] <dupondje> pitti: I have some work in progress to split up cryptsetup in a bin package. Would it be on time to get in Precise? Or to late anyway?
[16:25] <geser> dupondje: how confident are you that you don't break anything (e.g. upgrades)? as there isn't much time left to test it thoroughly
[16:32] <dupondje> geser: maby cryptsetup could provide cryptsetup-bin, and just copy the bins to a new package 'cryptsetup-bin' to make it safer ?
[16:39] <geser> dupondje: what issue are you trying to fix?
[16:40] <dupondje> geser: if you connect a crypted device to an ubuntu pc without cryptsetup, it asks a password, but can't open it, because its missing cryptsetup.
[16:41] <dupondje> installing cryptsetup as a whole is not an option, because it contains some initramfs scripts etc, which are not needed in this case
[16:41] <geser> so you plan to move the binaries into an own package and let cryptsetup depend on it?
[16:42] <dupondje> https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/343363
[16:42] <ubottu> Launchpad bug 343363 in udisks (Ubuntu) "gnome functional depends on cryptsetup, but not in package management " [Low,Triaged]
[16:44] <geser> sounds like it should be safe to not break existing cryptsetup installs
[16:46] <geser> dupondje: not sure about the timing, don't have enough expierence with judging such changes that late in the release cycle, luckily there is #ubuntu-release :)
[16:47] <dupondje> the critical in cryptsetup is also fixed in the next upload in debian :)
=== Claudinux_ is now known as Claudinux
=== jalcine is now known as webjadmin_
=== webjadmin_ is now known as jalcine
[19:14] <tiagoscd> hi
[19:16] <tiagoscd> I tried to create a package from lp:ubiquity, but when I use "debuild -us -uc" I have this error: http://paste.ubuntu.com/879353/
[19:16] <tiagoscd> Can anyone help me?
[19:20] <infinity> tiagoscd: debian/rules update
[19:23] <tiagoscd> infinity, thanks. could you tell me why I need to update the rules? (sorry, starting with devel)
[19:35] <alexbligh1> A wierd one: can I make debian/rules produce not only the normal example.deb, but a second example2.deb which contains example.deb (in /foo/bar/baz/example.deb). Or has rules stopped before the final .deb is generated?
[19:44] <infinity> alexbligh1: It's conceivably possible to wrap a deb in a deb from the same source package, but the better question is "why"?
[19:51] <alexbligh1> infinity, I have nodes that tftpboot an ubuntu distribution, and then suck various other .debs over http. I want to put those .debs themselves (which are only installed on the nodes) in a package installed on the server. I'm currently manually doing this (i.e. copying the built .debs into the source repository) which is error prone, so I already have .debs in .debs
[19:51] <alexbligh1> What I want to do is when I build the inner .deb, make an outer .deb too, and make the package on the server depend upon that.
[19:52] <alexbligh1> (I bet you wish you never asked)
[19:53] <infinity> alexbligh1: It's certainly not how I'd do it, but to each their own.  If this monstrosity is for local use, not for the archive. :P
[19:54] <alexbligh1> infinity, no, not for the archive. I should explain the nodes are diskless, and the server acts like a sort of real time repository. That might help it make more sense.
[19:54] <alexbligh1> um, boot time repository
[19:55] <infinity> alexbligh1: But the short answer is that you could just mv inner.deb into debian/outer/usr/share/outer/inner.deb between dh_builddeb -pinner and dh_buildder -pouter
[19:55] <infinity> And perhaps some tricker to remove the original deb from list.
[19:55] <alexbligh1> Ah, so dh_builddeb is actually called from rules, and that's (the -pinner bit) what makes the .deb
[19:56] <infinity> alexbligh1: Yeah, I realise what you're doing.  I'd just publish it all in one repo, however, rather than making debs contain mini repositories.
[19:58] <alexbligh1> infinity, thanks - I'll have a think
[21:18] <ScottK> mikecb: No.  I haven't tried with any of those.  Since I don't have direct access to an Ubuntu armhf box, I hope infinity will try out some of those options and see if it helps.
[21:20] <ScottK> infinity: Would you also please take a look at nihal.  The kdevelop build has been stuck at fully built for over half a day.
[21:34] <infinity> ScottK: Was the response to mikecb about qtwekbit-source?  If so, I've uploaded a package that should build fine.
[21:36] <infinity> ScottK: As for nihal, has it been stuck at that "purging chroot" step?
[21:38] <infinity> ScottK: If so, I'll have to poke people about it tomorrow, I haven't had direct access to buildds for years.
[21:51] <dupondje> slangasek: there atm ?
[21:58] <ScottK> infinity: It was and it is, so thanks on both counts.
[22:02] <infinity> ScottK: Yeah, I feel a bit dumb about qtwebkit-source.  We spent so long hunting kernel (and there was a kernel bug) and toolchain issues, that I didn't even stop to look at debian/rules and apply the s/armel/armel armhf/ fix. :P
[22:02] <ScottK> infinity: I'm glad you finally got it sorted. I didn't either, so don't feel bad.
[22:19] <apw> i think one of our builds may have gotten stuck: https://launchpad.net/ubuntu/+source/linux/3.2.0-18.29/+build/3272981 ... i wonder if a buildd admin could check up on it
[22:20] <infinity> apw: I think there was a network hiccup that confused the crap out of a bunch of buildds.
[22:20] <infinity> apw: Can't do much about it until the relevant people are at work on Monday.
[22:21] <apw> infinity, ok ... thanks for looking ...
[22:36] <scientes> can i install systemd on ubuntu?
[22:36] <scientes> on precise
[22:36] <scientes> I want the udev device enumeration for multiseat stuff
[22:42] <Darxus> Update Manager just hung on me.  Running Oneric.  About half way through applying changes.  Details only says "/tmp/tmprAyyZx" which seems pretty wrong.
[22:42] <Darxus> That file contains a list of what the updates are.
[22:43] <Darxus> Is this some incompatability with update manager and that annoying thing that tells me the details of the upgrade?  What is that?
[22:44] <Darxus> Cancel button is greyed out.
[22:45] <Darxus> Wow, the details is actually an interactive console?  Neat.
[22:45] <infinity> Darxus: Expand it a bit, and scroll back with Shift-PgUp.
[22:46] <infinity> Darxus: If I had to guess, I'd say you have apt-listchanges installed, and it's patiently waiting for you to 'q' out of less, and say "yes" to the upgrade.
[22:46] <Darxus> It's gone, sorry.
[22:46] <infinity> Darxus: apt-listchanges and update-manager don't play well together. :/
[22:46] <Darxus> Yep, I agree.
[22:46] <Darxus> Yeah.
[22:46] <infinity> I really should look at fixing that.  My solution was just to uninstall it from GUI systems and only use it on servers.
[22:46] <Darxus> You don't think that qualifies as a bug?
[22:46] <Darxus> Heh, yeah.
[22:47] <infinity> But I swear it used to do sane things (ie: pop a GTK dialog instead of a pager in the terminal window)
[22:47] <Darxus> Heh.
[22:47] <infinity> Darxus: There's a bug open, don't recall the number.  Just that no one's made it a priority.
[22:47] <Darxus> I just uninstalled it.
[22:47] <Darxus> Okay, thanks.
[22:48] <Darxus> The bug is https://bugs.launchpad.net/ubuntu/+source/apt-listchanges/+bug/787802
[22:48] <ubottu> Launchpad bug 787802 in apt-listchanges (Ubuntu) "Update Manager hangs waiting for response to apt-listchanges hidden under Details" [Undecided,Confirmed]
[22:48] <infinity> Yeah.  There may also be an update-manager bug.
[22:49] <infinity> Anyhow, I might see about making time for it.  It's annoyed me for a long time.
[22:49] <infinity> But "uninstall apt-listchanges on GUI systems" is a fair workaround.
[22:49] <infinity> Since you can see changelogs in the u-m window anyway.
[22:49] <Darxus> Yeah.
[22:50] <Darxus> Honestly, that thing has caused me more grief than anything.  By making it one step easier to forget to confirm an upgrade.
[22:51] <Darxus> "update-manager used to invoke the GTK frontend of apt-listchanges"
[22:56] <infinity> Yeah.  Maybe this is the cycle where it annoys me enough to figure out why it's broken.
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
[23:51] <Darxus> infinity: Neat :)