[01:56] <kees> hrm, can't usb-creator-gtk use an ext4 for the main filesystem (since it boots syslinux?)
[02:01] <kees> (or rather, can't we switch to extlinux?)
[03:03] <slangasek> stokachu, micahg: hmm, TTBOMK :any is possible in precise; I can't think of any reason why it wouldn't be
[03:03] <slangasek> stokachu, micahg: and in practice we're not talking about having any packages *in* precise depending on gdb:any
[03:55] <Bluefoxicy> http://lists.gnu.org/archive/html/grub-devel/2009-04/msg00367.html
[03:56] <Bluefoxicy> This should be standard reboot fare.  shutdown should kexec -e grub2whatever
[03:57] <Bluefoxicy> (too bad it's unclear if this actually works yet)
[04:10] <Bluefoxicy> that's interesting
[04:10] <Bluefoxicy> you can't open an MTP device with a hell of a lot of stuff on it.  Nautilus complains DBUS timeout/failure
[04:10] <Bluefoxicy> PTP it, remove a ton of images, swap back, it works again.
[04:10] <Bluefoxicy> </google nexus>
[05:19] <micahg> slangasek: ISTR some hoohah when wine wanted to depend on something :any, I think we were waiting for precise+1 so that there wasn't a problem with dpkg on upgrade
[05:19] <micahg> in precise it was only used for build dependencies IIRC
[05:20] <pp7> 12.04 why does my global menu stop working all of a sudden and go back to menu's per window?  How can i restart global menu?
[06:56] <mvo> hm, whats up with the PPA builders? https://launchpad.net/~mvo/+archive/freeglut-multiarch tells me on amd64 the build will start next monday and i386 does not even tell me when it will try :/
[06:56] <ScottK> mvo: data center move.
[06:56] <lifeless> mvo: DC move.
[06:56] <mvo> oh, of course!
[06:57] <mvo> thanks
[07:02] <shadeslayer> wheeee
[07:02] <shadeslayer> cjwatson: image is unbootable xD
[07:03] <shadeslayer> probably because of one of the patches I skipped
[07:07] <shadeslayer> ( kvm says 'Booting from DVD/CD... )
[07:09] <dholbach> good morning
[07:09] <shadeslayer> morning dholbach
[07:10] <didrocks> good morning Mr Holbach :)
[07:10] <dholbach> hi shadeslayer, salut didrocks
[07:13]  * shadeslayer ponders why the data center is being moved
[07:13] <RAOF> Aligators.
[07:14] <shadeslayer> what if the new place has worse animals?
[07:15] <shadeslayer> like ... you know ... penguins and such :P
[07:15] <RAOF> We'll import the alligators from the last place as a biological control.
[07:15] <didrocks> they are moving it to australia, it's known to be a safe place with only friendly animals :)
[07:16] <shadeslayer> ah .. animals and humans running a data center together, sounds like fun
[07:16] <shadeslayer> "We got a bug in our system ... we'll patch it! ... no I meant literally a bug in the system!!"
[07:22] <dholbach> shadeslayer, we'll have patch monkeys in there
[07:23] <shadeslayer> :D
[07:31] <rmk_> morning jodh
[07:32] <jodh> rmk_: hi
[07:33] <rmk_> just wondering if you saw my comments about your script?
[07:33] <MCR1> haha
[07:33] <rmk_> for tty-serial
[07:33] <rmk_> specifically, IFS stuff
[07:34] <jodh> rmk_: I was out yesterday, so no.
[07:34] <rmk_> it was a few days ago
[07:34] <rmk_> I found the problem
[07:35] <rmk_> when you call getty you need to restore the IFS back otherwise you won't get the word splitting you expect
[07:35] <jodh> rmk_: there are no new comments on bug 702574..?
[07:35] <rmk_> because you leave it set to ',', getty gets "-8 115200 ttyS0" all as one argument
[07:36] <jodh> rmk_: please could you just add your comments to that bug so they don't get lost? ;)
[07:37] <rmk_> eventually... it seems not to be elinks compatible
[07:38] <rmk_> iow,when I'm on the machine with firefox :)
[08:05] <SpamapS> ok I'm going totally bonkers here
[08:05] <SpamapS> I'm chrooted into a filesystem
[08:06] <SpamapS> file has permissions for reading..
[08:06] <SpamapS> no apparmor in effect
[08:06] <SpamapS> but getting access denied
[08:07] <SpamapS> but only when *sudo* tries to access (/etc/sudoers)
[08:08] <SpamapS> hm or is it possible apparmor *is* doing something but not logging it properly?
[09:28] <ev> mpt: am I remembering correctly that we're doing away with the Ubuntu logo in the error dialogs?
[09:30] <mpt> ev, yes, I have an artwork request for a new icon. Do the error alerts show up in the Launcher? I forget.
[09:30] <mpt> If so, the icon inside the alert should be the same as for the Launcher.
[09:31] <ev> yes
[09:31] <ev> one second
[09:32] <ev> mpt: http://people.canonical.com/~evand/tmp/Screen%20Shot%202012-08-17%20at%2010.31.43.png
[09:34] <mpt> Oh, yeah, that thing
[09:39] <xnox> =)))
[10:38] <ev> mpt: I'm wondering if the spinner over the treeview is the best place for it, now that we can have multiple reports potentially loading at different times. Maybe a band that appears at the top of the treeview and says "Loading" with the spinner next to it?
[10:58] <mpt> ev, how long apart are the sections likely to populate?
[10:59] <ev> mpt: hard to say. That's entirely dependent on how frequent different crashes are occurring
[11:01] <mpt> ev, and waiting for the last would be bad?
[11:04] <ev> mpt: they can come in at any time. Lets say for argument's sake that you have the error report dialog up, with the show details pane expanded
[11:04] <ev> another crash occurs
[11:04] <ev> what should happen?
[11:04] <mpt> ohhhh
[11:04] <mpt> I was thinking just of the case where you already had all of them
[11:05] <ev> ah
[11:05] <mpt> you just hadn't analyzed them yet
[11:05] <mpt> I'm tempted to say that showing the details pane should prevent aggregation of any later ones
[11:06] <mpt> otherwise, even if you're concerned about exactly what the report contains, you may hit "Continue" just as a bunch of private stuff gets added to it.
[11:06] <mpt> But that conflicts a bit with the idea of persisting expanded state of the details pane.
[11:08] <mpt> (That could be prevented by making "Continue" insensitive for a few seconds after each problem, but in a diabolical case that might mean it never becomes sensitive.)
[11:10] <ev> so it's possible to do that, but that would make determining which dialog to send subsequent error reports to difficult in the case where you've expanded the pane, a new report comes in and opens a new dialog, you collapse the pane and then a new report comes in.
[11:11] <ev> unless the solution is to never aggregate to the existing dialog after the user has clicked show details, even if they then hit hide details
[13:05] <xnox> as a point of interest / survey can I ask you to run:
[13:05] <xnox> $ ls /boot/grub/unicode.pf2
[13:05] <xnox> and tell me if you have it or not?
[13:13] <geser> -rw-r--r-- 1 root root 2560080 Aug 10 11:41 /boot/grub/unicode.pf2
[13:18] <xnox> geser: thanks.
[13:26]  * ev headdesk
[13:27] <ev> mpt: I'm glad I'm writing this state of the error tracker email
[13:27] <ev> as it's getting me to think about some of these problems from a different angle
[13:28] <ev> like how all the work I did on teaching crash-digger (the thing that links apport bug reports together) to use daisy.ubuntu.com for its brain so we could have just one mapping crash signatures to bug reports
[13:29] <ev> this so we can have launchpad bugs on errors.ubuntu.com for the issues without them, and to lay the groundwork for crash signatures -> bugs -> uploaded source -> fixed binary packages stuff
[13:29] <mpt> Standard therapist procedure: Communicating your problems helps solve them. :-)
[13:29] <ev> I've realised that we can probably just leave crash-digger well alone, and just dup the crash-digger found bug against the daisy.ubuntu.com created one
[13:29] <ev> mpt: I need a teddy bear
[13:30] <cjwatson> pot plants work too
[13:31] <ev> haha
[13:38] <dholbach> tumbleweed, happy birthday! :)
[13:40] <jocarter> happy birthday tumbleweed!
[13:54] <xnox> ev: the 80cm Wenlocks are on sale
[13:55] <ev> xnox: I have a rule. If I don't know what it *is*, I don't buy it in plush form.
[13:55] <xnox> ev: it's a blob of metal =)
[13:55] <ev> :)
[14:01] <slangasek> micahg: ah right, lucid dpkg+apt would fail to parse that dep
[14:06] <jdstrand> mterry: hey-- I don't remember the bug, but saw you were waiting on bin-deNEW of pycurl. it is done
[14:06] <mterry> jdstrand, ah yes; awesome, thanks
[14:07] <jdstrand> np
[14:10] <barry> mterry, jdstrand \o/
[14:12] <dholbach> anyone up for taking the last 1h slot on https://wiki.ubuntu.com/UbuntuDeveloperWeek/Timetable?
[14:23] <tumbleweed> dholbach, jocarter: thanks
[14:25] <dholbach> :)
[14:54] <MacSlow> How do I best report this kernel-crash, which isn't picked up by ubuntu-bug/apport at all -> http://pastebin.ubuntu.com/1152750 (extracted manually from /var/log/syslog)
[15:05] <smoser> stgraber, what is the "right" target of the symlink in /etc/resolv.conf ?
[15:06] <stgraber> smoser: ../run/resolvconf/resolv.conf
[15:07] <stgraber> it's relative to avoid problems when dealing with chroots
[15:07] <smoser> stgraber, ok. good.
[15:07] <smoser> for some reason my local system has absolute
[15:08] <smoser> but i assume some result of me for that.
[15:08] <smoser> the cloud images have relative, so i questioned the difference.
[15:08] <stgraber> some early versions were creating an absolute symlink, so maybe you still have it from that time
[15:09] <stgraber> I don't expect any problem on regular systems, the problem was mostly showing up with live-build/schroot/...
[15:39] <BenC> infinity: Any idea what the 1 day backup is on the powerpc buildd's?
[15:40] <stgraber> BenC: builders were moved between DCs yesterday, ppc only got back online an hour ago
[15:40] <BenC> Ah, gotcha
[15:41] <xnox> mpt: So no repeats on the alarms? =))) I'm guessing it's not a wake-up alarm then.
[15:41] <xnox> mpt: should it boot the computer up as well?
[15:42] <mpt> xnox, don't know if you went to the page or just read the diff, but the sketch shows "Repeat: (*) No  ( ) Daily"
[15:42] <xnox> mpt: what I meant, is multiple alarms. I always set two alarms 7am & 7:30am
[15:42] <xnox> cause I will snooze/ignore the first one
[15:43] <mpt> xnox, if Ubuntu was smart enough to have timed startup and shutdown, I think it should first go in the Power settings. We could add it here later.
[15:43] <xnox> mpt: Ok.
[15:44] <mpt> xnox, baby steps. A single alarm for now. :-) Maybe a list of them later.
[15:44] <xnox> mpt: the sketches look good =)
[15:44] <xnox> mpt: there is a new installer design item similar with 'ubuntu one' integration, but landscape this time around =)
[15:45] <mpt> joy
[15:51] <mpt> cjwatson, hi, did bdmurray send you any of the statistics yet on how people edit their /etc/default/grub ?
[15:52] <mpt> (for <https://blueprints.launchpad.net/ubuntu/+spec/foundations-q-fix-grub-config-errors>)
[15:53] <cjwatson> ah, I have an outstanding mail from him on that that I need to reply to
[15:54] <ev> surely there's such a thing in gtk as a hseparator cell renderer
[16:00] <ev> mpt: so to be clear on this before I go off writing custom cell renderers and come back with a beard and even more of a planet-sized hatred for GTK
[16:00] <ev> individual report data with the expanders
[16:00] <ev> separated by just a horizontal line
[16:01] <ev> nothing fancier?
[16:01] <mpt> nothing fancier
[16:29] <cjwatson> Laney: looks like libpst could be synced?
[17:04] <bdmurray> @pilot in
[17:05] <infinity> bdmurray: Didn't you just pilot a few days ago, or am I going insane?
[17:06] <infinity> bdmurray: (The answer can be "both", FWIW)
[17:06] <bdmurray> infinity: I was supposed to a few days ago but was working on an error tracker / apport thing
[17:06] <infinity> Ahh.
[19:10] <dpb___> Hi all -- is there is a policy on removing init scripts from a new version of a package?  Is an rm -f good policy, or is there something better?
[19:17] <infinity> dpb___: Init scripts tend to be conffiles, so you might want rm_conffile
[19:17] <infinity> dpb___: See the manpage for dpkg-maintscript-helper
[19:17] <infinity> dpb___: Requires a pre-dep on dpkg (>= 1.15.7.2)
[19:18] <shadeslayer> cjwatson: so I made everything work with the old lb build ( the on in the archives right now ), but it still doesn't boot 0.o
[19:19] <shadeslayer> gives me a code 0003
[19:21] <shadeslayer> maybe a bug in qemu
[19:22] <mhall119> where can I get a list of packages in Precise's backports archive?
[19:23] <tumbleweed> in the Packages list?
[19:23] <mhall119> and where is that?
[19:23] <mhall119> I don't see backports in http://archive.ubuntu.com/ubuntu/dists/precise/
[19:23] <tumbleweed> precise-backports
[19:23] <tumbleweed> e.g. http://archive.ubuntu.com/ubuntu/dists/precise-backports/main/binary-i386/Packages.bz2
[19:25] <tumbleweed> mhall119: even easier: http://packages.ubuntu.com/precise-backports/allpackages
[19:25] <mhall119> thanks tumbleweed
[20:07] <tedg> slangasek, Hey, do you know of a good way to build unit tests for pam modules?  There seems to be ideas out there, but I don't see anything authoritative.
[20:07] <slangasek> tedg: I'm not aware of one, sorry.  Linux-PAM upstream has an "xtest" framework, which requires root access to run
[20:10] <tedg> slangasek, Hmm, okay.  This seems to be the best I've found: http://git.eyrie.org/?p=kerberos/pam-krb5.git;a=blob;f=tests/fakepam/README;h=b0f23abcc75fabcd85206bc1a3d8e3fede5e61d8;hb=HEAD
[20:10] <slangasek> tedg: anything in pam-krb5 upstream is probably a good starting point
[20:11] <bdmurray> tumbleweed: can you explain http://bazaar.launchpad.net/~ubuntu-dev/ubuntu-dev-tools/trunk/view/head:/ubuntutools/sponsor_patch/sponsor_patch.py#L184 to me?
[20:11] <bdmurray> tumbleweed: particularly line 205
[20:12] <bdmurray> I'm at an ubuntu bug with 2 tasks, really 3 tasks, but just for different releases and sponsor-patch is assert'ing on me there
[20:16] <tumbleweed> bdmurray: the assertion is because we need to find the single task that matches the branch
[20:17] <tumbleweed> line 203 should pick the right release
[20:17] <bdmurray> tumbleweed: right and this bug has 2 quantal tasks for the same source package
[20:17] <bdmurray> ipdb> [t.get_series() for t in tasks]
[20:17] <bdmurray> [u'quantal', u'quantal']
[20:17] <tumbleweed> never seen that before
[20:17] <tumbleweed> bug number?
[20:17] <bdmurray> bug 959795
[20:18] <bdmurray> all 3 don't show up in the web interface but in the API and probably +text
[20:18] <bdmurray> I believe it happens when you target a bug to the development release
[20:19] <tumbleweed> that makes sense
[20:19] <tumbleweed> how do we pick the right one?
[20:20] <bdmurray> they seem to be the same series so does it matter?
[20:22] <tumbleweed> actually, probably not. It only changes the state of tasks for old-style sync-acking
[20:23] <tumbleweed> so, I'd be ok with asserting 0<x<2, with a comment explaining that oddity
[20:38] <dpb___> infinity: thanks, will look
[20:44] <tumbleweed> bdmurray: fix committed
[20:44] <bdmurray> tumbleweed: ah, thanks!
[20:45] <tumbleweed> bugtask was being too clever, and filling in quantal for the task that didn't have a series
[20:46] <bdmurray> tumbleweed: well that makes sense if there are no series tasks
[20:46] <tumbleweed> yeah
[21:15] <bdmurray> @pilot out
[21:24] <silverarrow> anyone clever with handeling packages here?
[21:26] <silverarrow> anyone here at all=
[21:26] <silverarrow> :-)
[21:29] <micahg> silverarrow: if it's not related to stuff in the archive, you probably want #ubuntu-packaging
[21:29] <silverarrow> it`s amazing what channel devision can conjure up these days
[21:30] <silverarrow> micahg: can you take a look at this http://imagebin.org/224932
[21:32] <micahg> silverarrow: will follow up in -packaging
[22:33] <plasmasolutions>  Good evening guys...I've got a brand new intuos 5 under ubuntu here and need really your help. As far as I can see the pen /eraser is working properly but when I lay my finger at on of the left tablet buttons or move it in a straight row from top to bottom the pointer moves for a very short timespan to 0|0 (causing the exposee feature under gnome3 to happen)
[22:33] <plasmasolutions> When I set the panel to left handed, the pointer moves to the lower right for a tiny period of time
[22:34] <plasmasolutions>  I installed under my ubuntu 12.04 this package-archive: ppa:lekensteyn/wacom-tablet
[22:34] <plasmasolutions> and the wacom-dkms package, it's this archive: https://launchpad.net/~lekensteyn/+archive/wacom-tablet
[22:35] <plasmasolutions> Could someone lead me to the path where we can find if this is a bug or a misconfiguration? Didn't change anything by hand...
[22:39] <plasmasolutions> no idea, anyone?
[23:37] <failedassertion> I have a bug but I don't know where to file it. Using the "fsprotect" package in universe doesn't work on /var with samba installed, because samba starts writing to files in /var/log before fsprotect can move the rw-mounted /var out of the way. Is this a bug in fsprotect, or is it a packaging bug in Ubuntu?
[23:38] <failedassertion> i.e. I think it's something specific to upstart trying to parallelize things
[23:39] <cjwatson> I would be inclined to file that against the Ubuntu fsprotect package
[23:40] <cjwatson> It probably needs to be converted to an Upstart job itself so that it can start at the appropriate time and block samba startup, or something
[23:40] <cjwatson> Without having looked at the details or anything
[23:43] <failedassertion> cjwatson: Alright. Sounds good. I'll write it up and file it. Thanks.
[23:43] <slangasek> sounds non-trivial to fix in the general case however, since /var may or may not be a mount point
[23:43] <cjwatson> Also samba may or may not be installed
[23:44] <slangasek> and there's no consistent way to block everything that wants to start once the filesystem is up
[23:44] <cjwatson> I'm not certain that fsprotect is the right place for the bug; it's just where I'd start with it
[23:44] <cjwatson> It's possible fsprotect would need to be integrated into mountall to work properly
[23:45] <failedassertion> i was afraid of that :-\
[23:45] <cjwatson> There *might* be some hack involving starting on the various mounted events
[23:46] <slangasek> actually, it seems like an upstart job that's 'start on mounted / instance MOUNTPOINT' would probably be what you want
[23:46] <cjwatson> Yeah
[23:46] <cjwatson> That would block local-filesystems until it's complete, which would block samba
[23:49] <failedassertion> slangasek: cjwatson: that's a good thought... I've got basically no knowledge of upstart, but when I look at this tomorrow I'll dig a little deeper. I've gotta run now, but thanks again