=== dendrobates is now known as dendro-afk
[01:23] <cnd> doko, how can I easily test gcc 4.7 in precise, so I can fix an FTBFS in debian when compiled with 4.7?
[01:25] <cnd> perhaps I just need to create a sid or wheezy chroot?
[01:29] <cjwatson> cnd: creating a sid chroot is easy with mk-sbuild (say), and I'd recommend having one available if you need to test builds on Debian
[01:29] <cnd> ok
[01:29] <cnd> I'll try it out
[01:31] <cjwatson> in my setup, I can type 'sbuild -Asd unstable' and the source package tree I'm in gets built in an unstable chroot and produces a .changes that's suitable for upload to Debian
[01:32] <cjwatson> or 'sbuild -Ad unstable /path/to/foo.dsc' in a temporary directory to test-build a .dsc
[01:44] <thestormsedge> hello all :)
[01:52] <thestormsedge> I want to get invovled with Ubuntu development (preferrably on a Python or PSQL project) and how do I do that?
[01:54] <sconklin> @pilot out
=== udevbot changed the topic of #ubuntu-devel to: 12.04 Beta 2 Released! Precise: UI and feature freeze | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> oneiric | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots:
[01:54] <RAOF> thestormsedge: Is there anything particular that you want to do?  One of the problems with people asking about getting involved is that the possible answers are huge.
[01:55] <thestormsedge> mostly simple things, probably just edits in application source code first or Ubuntu websites
[01:55] <thestormsedge> though I don't know much C++, I would probably have to tackle some Python issue
[02:03] <thestormsedge> I guess my biggest question is how exactly does the contribution process works, lets just say I have I figure out how to do a simple patch on my own
[02:04] <thestormsedge> do I just haphazardly start figuring out how to code, then start submitting things, or is there a more formal process?
[02:04] <RAOF> Pretty much the former.
[02:05] <RAOF> The other thing to realise is that *almost all* of the work that goes into Ubuntu isn't done by us, and we aren't really the gatekeepers for it.
[02:05] <RAOF> It's done by the various “upstream” projects.
[02:06] <thestormsedge> oh ok thanks the advice RAOF. I've always wanted to work on some FOSS project and was sort of confused on how all the Wikis, intros, et al. were organized
[02:06] <RAOF> So one of the possible endpoints of contributing to Ubuntu is to find a project that you care about and start fixing things there.
[02:07] <thestormsedge> basically I just take the tutorials, begin coding on something of my interest, and then see if it gets accepted via Launchpad, Github etc?
[02:07] <RAOF> We do have some process around being something of a central place for contributions - you *can* attach patches to Ubuntu bugs on Launchpad, and we'll check them out.  Much of the time we'll then prod you to submit them to the upstream project, though.
[02:09] <thestormsedge> kk thanks for the explanations ^-^ I have been super confused about FOSS development for the longest time
[02:10] <RAOF> There are a wide variety of ways that upstreams like to receive contributions, but one common thread is that the (almost!) always have some form of mailing list for discussion, and reading the mailing list archives should give you a reasonable idea of how to submit code and what people think need fixing.
[02:12] <thestormsedge> kk cool :)
=== poolie_ is now known as poolie
[05:50] <pitti> Good morning
[07:03] <dholbach> good morning
[07:27] <bkerensa> cjwatson: ping
=== smb` is now known as smb
[08:01] <sabdfl_> how does one run a shell script so that it echoes what it's doing?
[08:01] <geser> sh -x the_script
[08:02] <geser> or bash -x if it's a bash script
[08:03] <sabdfl_> thanks geser
[08:03] <sabdfl_> geser, is there a way to turn that on inside the script?
[08:04] <geser> add "set -x" near the top of the script (adding -x to the shebang line should work too)
[08:07] <pitti> sabdfl_: you can surround the part that you want to debug with set -x and set +x
[08:08] <pitti> sabdfl_: if you want to write the output into a file, put a "exec 2>/tmp/log" in front of it
[08:08] <sabdfl_> pitti, geser, thanks much
=== sabdfl_ is now known as sabdfl
[08:50] <sabdfl> pitti, morning, quick question re live cd image
[08:50] <sabdfl> can the filesystem on that have a UUID?
[08:58] <pitti> sabdfl: the squashfs you mean?
[08:58] <sabdfl> pitti, hmm, no i meant the iso9660 one
[08:59] <sabdfl> i have a peculiar interest in mounting it over iscsi
[08:59] <pitti> I don't think it can; blkid at least doesn't give an UUID for it
[08:59] <sabdfl> yeah, question is whether that's intrinsic to the fs, or just something we didn't turn on when we made it
[09:00] <pitti> there do seem to be approaches to generate one, like in grub (http://www.mail-archive.com/grub-devel@gnu.org/msg07924.html)
[09:00]  * pitti RTFS util-linux
[09:01] <pitti> above grub patch makes one up from the timestamp
[09:03] <pitti> confirmed, no UUID support in libblkid/src/superblocks/iso9660.c
[09:03] <pitti> that doesn't necessarily mean that iscsi doesn't support it, of course
[09:03] <pitti> blkid is just what udev etc. use
[09:25] <cjwatson> bkerensa: hi - yep, got your mail
[09:27] <cjwatson> sabdfl: squashfs doesn't have a UUID itself as far as I know, but we hack around that by putting a file matching .disk/casper-uuid* on the filesystem
[09:28] <cjwatson> sabdfl: that doesn't help directly with mounting remotely - casper mounts, checks whether that file matches its own notion of what the UUID should be, unmounts if it doesn't and tries again
[09:28] <cjwatson> oh, I should have read all of scrollback :-)
[09:28] <sabdfl> ah, ok, that might help
[09:29] <cjwatson> oh actually .disk/casper-uuid* is on the ISO9660 filesystem not the squashfs, so even better
[09:38] <doko> pitti, no, no, no for your mpfr4 upload ...
[09:38] <doko> just use -O2 for that one file
[09:39] <pitti> doko: as I said on the bug report, it's not just one file
[09:39] <pitti> I stopped after it crashed on the 7th
[09:39] <pitti> (selectively building with -O2)
[09:39] <doko> bah
[09:42] <pitti> doko: shoudl I try it with gcc-4.5, and -O3?
[09:43] <doko> pitti: no, not anymore in main
[09:44] <pitti> gcc-4.5 | 4.5.3-12ubuntu1 |       precise | source, amd64, armel, armhf, i386, powerpc
[09:44] <pitti> doko: it's still in main; is it planned to drop it still?
[09:44] <doko> looking ...
[09:46] <doko> pitti: mysql-5.5, u-boot-linaro still using it
=== astraljava1 is now known as astraljava
=== hrww is now known as hrw
[10:43] <bdrung> doko: bug #966570 (gccgo seems to need something from the gcc-4.7 package
[10:43] <ubottu> Launchpad bug 966570 in gccgo-4.7 (Ubuntu) "/usr/bin/ld: cannot find -lgcc_s" [Undecided,New] https://launchpad.net/bugs/966570
[10:44] <doko> bdrung, expected, use -static-libgcc
[10:57] <azeem> can you get a newer openjdk6 than 6b20 to run on lucid, like 6b23 or 6b24?
[10:57] <azeem> (are there any backports?)
=== MacSlow is now known as MacSlow|lunch
[11:10] <nailora> once again a request to make a bug public: bug #937249
[11:10] <ubottu> Error: Launchpad bug 937249 could not be found
[11:11] <nailora> thanks in advance
[11:35] <penguin42> cjwatson: I pushed an update to my procps fix that also fixed bug 432861
[11:35] <ubottu> Launchpad bug 432861 in procps (Ubuntu) "kill -s crashed with SIGSEGV" [Medium,Triaged] https://launchpad.net/bugs/432861
=== _salem is now known as salem_
=== ZarroBoogs is now known as Pici
=== MacSlow|lunch is now known as MacSlow
=== Guest31547 is now known as tobin
=== ogra is now known as Guest67850
=== imbrandon is now known as bholtsclaw
=== ogra_ is now known as ogry
=== ogry is now known as ogra_
=== vibhav_ is now known as vibhav
[12:52] <apw> cjwatson, slangasek, either of you seen reports of the boot splash being ok,
[12:53] <apw> but the shutdown splash being all odd colours ?
[13:01] <doko> pitti: https://bugs.launchpad.net/ubuntu/+source/pygtk/+bug/955898   these issues are again accumulating for the interpreter package :-(
[13:01] <ubottu> Launchpad bug 955898 in pygtk (Ubuntu) "python2.7 crashed with SIGABRT in raise()" [Undecided,New]
[13:05] <dobey> hey all. what's the best way to install extra files into /usr/share/doc/$package? i have override_dh_installdocs, which seems to get run, but the files aren't in the resulting binary packages it seems
[13:07] <janimo> dobey, adding them in debian/docs ?
[13:07] <janimo> or debian/binary-name.docs ?
[13:36] <dobey> janimo: eww. those are ugly. discovered dh_installdocs -A though, which seems to do it. was looking at another package for example that was apparently last updated in 2009, which didn't use -A, so maybe that changed at some point, or that package has always been broken. :)
[13:39] <janimo> dobey, I always thought d/docs is better as it is declarative, i.e less chances of messing up cp/install invocations, and keeps rules file cleaner. I do not know what the recommended way is though or whether the docs way is discouraged
[13:40] <dobey> janimo: well, having N .docs files which all list the same things seems bad to me. for things which should only go in the -dev package or such, i would agree those should be done with the docs files
[13:41] <janimo> dobey, listing the same things? One package installs the docs and the other binaries should symlink only but I admit I don't know if that is handled by declaring them in docs
[13:42] <cjwatson> if you want to install the same docs into lots of packages, you should consider using dh_installdocs --link-doc=some-appropriate-common-package
[13:42] <cjwatson> you may need some preinst code to deal with upgrades, as dpkg deliberately never replaces a directory with a symlink of its own accord
[13:43] <dobey> well they are just license files
[13:44] <dobey> it seems those get copied to all packages by default?
[13:44] <cjwatson> licensing information should go in the copyright file rather than being installed as separate files
[13:45] <dobey> the copyright file is also installed
[13:45] <cjwatson> licensing information should not be installed as separate files
[13:45] <cjwatson> if everything necessary to understand the licensing of the package isn't in copyright, that's a bug
[13:45] <cjwatson> once you've done that, you don't need any other files
[13:46] <dobey> for the GPL+OpenSSL exception case where the OpenSSL license is included in the source, but openssl itself is not?
[13:47] <cjwatson> my statements apply regardless of the details :)
[13:50] <dobey> what is the "proper recommended way" to do this then? the package (hpoj) i was looking at as an example, and which was mentioned in http://lists.debian.org/debian-legal/2004/05/msg00595.html seems to install the extra files
=== Darxus_ is now known as Darxus
[13:51] <cjwatson> copy necessary information into the copyright file
[13:52] <cjwatson> (preferably in the new machine-readable format, although that isn't yet mandatory)
[13:53] <cjwatson> eventually we want to be able to automatically scan copyright files for problems, and it won't fly to have to go hunting around other files as well
[13:53] <cjwatson> the copyright file must have everything
[13:54] <dobey> what is "necessary" here? it's not entirely clear
[13:54] <cjwatson> if it isn't necessary, you don't need to install it :-P
[13:55] <cjwatson> perhaps http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ will help, to have a fixed format
[13:55] <cjwatson> necessary: the package must include its copyright information and a copy of the licensing terms under which it's distributed
[13:56] <cjwatson> so if something's part of its licensing terms, it's necessary, if not, it isn't
[13:57] <dobey> ok
[14:10] <seb128> doko, I wonder if all those segfault in __find_specmb() are not a libc issue
[14:11] <seb128> doko, like we got a bunch of those in C softwares as well, i.e bug #966446
[14:11] <ubottu> Launchpad bug 966446 in gnome-control-center (Ubuntu) "[soundnua]: gnome-control-center crashed with SIGSEGV in __find_specmb()" [Medium,In progress] https://launchpad.net/bugs/966446
[14:11] <doko> seb128, but there pygobject is involved too. do you see one unrelated to python?
[14:11] <seb128> doko, the one I just pointed
[14:12] <doko> ahh, control-center ...
=== SpamapS_ is now known as SpamapS
[14:12] <cjwatson> seb128: __find_specmb calls strchrnul on the format string provided, so it will segfault in the same way that strchrnul will segfault on invalid data
[14:13] <cjwatson> i.e. my guess is that this is an application bug for providing a non-null-terminated format string, or a pointer into invalid memory as the format string
[14:13] <cjwatson> libc's entitled to segfault when you do that
[14:13] <seb128> cjwatson, could well be yes
[14:13] <seb128> cjwatson, doko just reassigned a bunch of such bugs to pygobject, so I pointed we got some similar non python bugs as well
[14:14] <cjwatson> valgrind should find it
[14:14] <seb128> but yeah, they could well be different issues
[14:15] <doko> yeah, that was my best guess, but maybe pygtk would be the common denominator then?
[14:16] <seb128> doko, it would be a bug in pygobject yes, I will let pitti check, I will try to get a valgrind log for the gnome-control-center one
[14:16] <seb128> cjwatson, doko: thanks
=== dholbach_ is now known as dholbach
[14:25] <doko> slangasek, 954609, no, I'll add the python2 symlink to python-defaults, now that the pep is accepted
[14:39] <Sweetshark> do I need to fear someone syncing neon27? because of http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667043 that would cause trouble.
[14:39] <ubottu> Debian bug 667043 in libneon27-gnutls "libneon27-gnutls: Breaks bzr-svn (via subvertpy): undefined symbol ne_ssl_context_get_flag" [Serious,Open]
[14:41] <Sweetshark> or to put the question differently: where can I put a big fat yellow signpost saying: "If you sync neon27-0.29.6-2 you will need to fix bzr-svn, libreoffice and likely a few other!!!1!" to make sure it meets the right audience?
[14:58] <nessita> hello all! quick question, if an upstream code is released under the AGPL license, shall the ubuntu packaging distribute the AGPL license? I'm asking since I don't have the AGPL text in /usr/share/common-licenses/
=== emma is now known as em
[15:01] <cjwatson> nessita: yes, it must
[15:01] <nessita> cjwatson: any reason why the AGPL is not already in the common-licenses folder?
[15:02] <stgraber> nessita: http://dep.debian.net/deps/dep5 describes that case (the full license needs to go in debian/copyright if not in common-licenses)
[15:04] <cjwatson> nessita: it's insufficiently common
[15:04] <nessita> stgraber: right, thanks
[15:04] <nessita> cjwatson: ack :-)
[15:31] <ochosi> kenvandine: hi again, quickly wanted to follow up on Bug #956147.
[15:31] <ubottu> Launchpad bug 956147 in Messaging Menu "thunderbird message indicator icons" [Medium,Confirmed] https://launchpad.net/bugs/956147
[15:32] <kenvandine> ochosi, it's on my list of bugs to nag tedg about :)
[15:32] <ochosi> kenvandine: ok thanks! :)
[15:32] <kenvandine> tedg, or should that be larsu that i nag for that one?
[15:33] <larsu> kenvandine, it's larsu :(
[15:33] <larsu> kenvandine, ochosi, sitting on it right now, expect a patch in a bit
[15:33]  * tedg hears that larsu loves GTK2
[15:33] <kenvandine> larsu, i assigned it to you :)
[15:33] <ochosi> larsu: sweet! if i can help you test it let me know
[15:33] <ochosi> larsu: i'll be around for ~another hour or so
[15:34] <larsu> ochosi, cool thanks!
[15:34] <larsu> tedg, can't decide if I'll hack a fix into messaging-menu or fix it correctly in libdbusmenu
[15:35] <larsu> tedg, gtk2 ftw!
[15:35] <ochosi> +1 (as long as xfce isn't ported yet)
[15:36] <kenvandine> larsu, if you get a patch that is confirmed to work, ping me and i can distro patch until we get around to doing a release
[15:38] <larsu> kenvandine, cool thanks, but I think I've just decided to fix this in i-messages and get that patch into the release charles is doing today
[15:38] <kenvandine> ok
[15:48] <bdrung> doko: can you give the eclipse-* package a retry for the test rebuild?
[15:50] <doko> bdrung, done
[15:50] <bdrung> thanks
[16:00] <larsu> kenvandine, ochosi, no matter what I do, I always break something else in that menu. Are you okay with me ifdef'ing a line that'll break the alignment of "Compose New Messsage" and "Contacts" for gtk2
[16:01] <ochosi> larsu: define "break the alignment"
[16:01] <larsu> ochosi, they'd be left-aligned instead of with the label of the app, as in the gtk3 version
[16:01] <larsu> ochosi, i.e. the label floats to the left, were the broken icon is now
[16:02] <ochosi> larsu: humm, well it's not ideal, but it's better than the broken icon
[16:03] <ochosi> larsu: how is the alignment done atm?
[16:04] <larsu> ochosi, setting an empty icon. For some reason, gtk2 interprets that as broken...
[16:05] <ochosi> larsu: yeah, i was mostly wondering because this kind of alignment is nothing special in gtk2 menus, i actually thought it is default behavior...
[16:08] <larsu> ochosi, indicator-messages is not using the standard menu items, because it adds all kinds of stuff. If I remove the icon completely, the labels float left in gtk3 and gtk2
=== lool- is now known as lool
[16:09] <ochosi> larsu: hmm, i guess i'd have to look at the indicator-messages code myself to understand the problem for real
=== deryck is now known as deryck[lunch]
[16:12] <ochosi> larsu: if you have a screenshot or something to test for me, i guess that would help in giving a real opinion. but if you say it's not fixable in any other way atm then go ahead
[16:16] <larsu> ochosi, http://imgur.com/H9Ope (note the left-aligned labels under Polly and Thunderbird)
[16:17] <ochosi> larsu: yeah, it's not unreadable or anything, there are still separators and appicons to help with the structure of the menu. i'm ok with that
[16:19] <larsu> ochosi, cool. Sorry, I'd have rather fixed it the right way, but i-messages has gotten quite complex (especially since it contains both the gtk2 and 3 version in the same source)
[16:19] <ochosi> larsu: thanks for fixing this so quickly! :) yeah, i'm wondering how long will you maintain the gtk2 version?
[16:21] <ochosi> larsu: one more thing: i assume that you also positioned those menuitems with empty images when thunderbird or $application wasn't running, i wonder why the bug only occurs when thunderbird is open (the action-items "compose" and "addressbook" are there before as well)
[16:22] <larsu> ochosi, I'm not the maintainer of i-messages, but I'm pretty sure we'll drop gtk2 support next cycle
[16:23] <larsu> ochosi, the empty icon is only set when thunderbird is running. That's a different bug which also affects the gtk3 version :-/
[16:24] <ochosi> larsu: ah ok
=== infinity1 is now known as infinity
[16:45]  * micahg would like to know how much work the gtk2 support is for the indicators, Xfce is stuck with GTK2 until at least 13.04
[16:47] <ochosi> micahg: +1
=== dendro-afk is now known as dendrobates
[17:00] <dobey> ok, can someone tell me what the heck is going on here? http://paste.ubuntu.com/914786/
[17:00] <dobey> why is bzr bd not using the changes i just imported/committed, correctly?
[17:07] <dobey> james_w: ^^ any ideas on that?
[17:09] <james_w> dobey, would you pastebin "bzr diff -c -1" please?
[17:12] <dobey> james_w: http://paste.ubuntu.com/914804/
[17:15] <james_w> dobey, find /home/dobey/Projects/canonical/ubuntu/ -name "rhythmbox-ubuntuone_2.99.92.orig.tar.gz"
[17:15] <hallyn> drat - can't reproduce the libvirt race in fedora.  nor do the fedora out-of-tree patches help our package.
[17:15] <james_w> I wonder if there is a rogue copy of that file around that isn't what we think it is
[17:17] <dobey> james_w: indeed there was a tarball that had the old version in it. how the heck would that have happened?
[17:17] <dobey> inside build-area
[17:18] <james_w> dobey, I don't know. It can happen if you have some tags messed up
[17:18] <james_w> dobey, but if that log was all your interactions with this version then I've no idea how it happened
[17:18] <james_w> like, if you accidentally pass it the wrong tarball once it can be hard to make it forget it
[17:19] <james_w> but it shouldn't just decide that a tarball is actually called something different
[17:19] <dobey> yeah. well i've tried the same thing like 10 times it wouldn't stop doing that
[17:19] <dobey> but all the same commands
[17:19] <dobey> same commands i've used a million times to update all the other packages i work with :-/
[17:20] <dobey> weird
=== dendrobates is now known as dendro-afk
[17:29] <apw> slangasek, about?  i think you are the closest to an expert on plymouth splash ... i have a radeon which is showing very odd colouring during shutdown splash particularly, and when configured 'right' i think is also wrong during boot
[17:29] <apw> slangasek, seen anything like that, and any ideas how to debug this puppy ?
=== dendro-afk is now known as dendrobates
[17:30] <slangasek> apw: what sort of "very odd colouring"?  Like, 16-bit framebuffer where you'd really rather have a 32-bit one?
=== deryck[lunch] is now known as deryck
[17:31] <apw> slangasek, like the colourmap is wrong i think the bitcount is good
[17:31] <slangasek> apw: right, the colormap is wrong because you *have* a colormap ;)
[17:31] <apw> so purpleish background, but a green spray where it should be fading into the background (it == UBUNTU)
[17:31] <slangasek> apw: plymouth only actually supports truecolor, and VGA
[17:32] <slangasek> so if your video card gives you a 16-bit framebuffer, this is what you get
[17:32] <slangasek> (there's a bug open on the plymouth package; I can hunt the bug # if you like)
[17:32] <apw> slangasek, so if i see it on shutdown, seeing it on startup means my startup _isn't_ wrong :)
[17:32] <slangasek> yes... :)
[17:32] <apw> slangasek, this is in the context of the handoff bug, in fixing it, i have exposed this on my test box
[17:33] <apw> slangasek, and that lets me say ... i think its ok then
[17:33] <slangasek> apw: bug #564471
[17:33] <ubottu> Launchpad bug 564471 in plymouth (Ubuntu Natty) "Lucid: garbled video at boot on radeon cards: bad color map due to 16-bit fb" [High,Triaged] https://launchpad.net/bugs/564471
[17:33] <slangasek> OTOH, I don't know what bit-depth the fb is supposed to be when grub hands it off to the kernel... :P
[17:34] <slangasek> though the drm driver is probably inclined to reconfigure that regardless
[17:34] <apw> slangasek, heh well this is in the "we are not handing off" mode.  in handing off mode it happens to work ... presumably because grub didi the right thing
[17:34] <slangasek> right, ok
[17:35] <apw> so for me, fixing this handoff=true breaks things bug will regress boot on my radeon, by making it look poor like it already does on shutdown :)
[17:35] <slangasek> heh
[17:35] <apw> slangasek, did you have an affected machine ?  i forget now ?
[17:36] <slangasek> how exactly are you "fixing" the handoff though?
[17:36] <apw> slangasek, the theory here is to pass over a handoff enable flag as well based on the gfxpayload setting
[17:37] <apw> slangasek, this has all sorts of niceties ... one its only enabled when grub says it did it, two if you change gfxpayload=xxx to =text the right thing happens
[17:38] <apw> slangasek, basically i am doing this in grub: adding 'vt.handoff_enable=$gfxpayload' to the default command line
[17:38] <slangasek> apw: I have a radeon machine for testing, I don't know if it's able to reproduce this particular bug
[17:38] <slangasek> apw: aha, that sounds perfect
[17:38] <apw> slangasek, of course we still need to tell grub that its got no hope of doing graphics when you are on encrypted disk
[17:38] <apw> slangasek, any suggestions as to the best way to figure that out
[17:39] <slangasek> apw: would it be simpler to overload vt.handoff itself, not passing it at all when gfxpayload != keep?
[17:40] <slangasek> sorry, what do you mean "no hope of doing graphics when you are on encrypted disk"?
[17:40] <charles> larsu, wrt bug #956147, can you walk me through that proposed merge?
[17:40] <apw> slangasek, to do that we'd need something clever in grub ... here i am literally making the bit that grub includes in the command line 'vt.ha
[17:40] <ubottu> Launchpad bug 956147 in Messaging Menu "thunderbird message indicator icons" [Medium,Confirmed] https://launchpad.net/bugs/956147
[17:40] <apw> slangasek, to do that we'd need something clever in grub ... here i am literally making the bit that grub includes in the command line 'vt.handoff=7 vt.handoff_enable=$gfxpayload'
[17:40] <charles> larsu: in short I guess I don't understand what http://bazaar.launchpad.net/~indicator-applet-developers/indicator-messages/trunk.0.6/revision/252.2.2 was for
[17:40] <apw> slangasek, as grub fills that in with 'text' or 'keep' and i use those as special cases of true and false
[17:41] <slangasek> apw: doesn't require too much cleverness, I think we could easily toggle the vt.handoff=7 in grub
[17:41] <apw> slangasek, appearenetly the grub device drivers for graphics are in the encrypted disk
[17:41] <apw> slangasek, at least that was what i thought i was being told
[17:41] <slangasek> that makes no sense to me :)
[17:42] <slangasek>  /boot always has to be unencrypted
[17:42] <apw> slangasek, that is a good point ... hrm ... i am sure thats what cjwatson was saying
[17:42] <slangasek> I'm using cryptsetup, I have no problems with video here
[17:43] <apw> yeah now i am flummoxed as to what the heck i am doing
[17:43] <slangasek> :)
[17:43] <apw> the underlying issue is that nouveau and psb drivers are not always happy when we handoff to them, if grub puts us in text mode, but we claim handoff so the kernel does not reset things
[17:44] <apw> so that if grub is set for text, we don't want to enable handoff, so thats really what i am aiming to fix
[17:44] <slangasek> right
[17:44] <apw> as you would do that if its broken
[17:44] <slangasek> so there are two cases you'll get text instead of keep, on any system
[17:44] <slangasek> - the recovery boot option
[17:44] <slangasek> - when the previous boot didn't complete successfully
[17:45] <apw> in recovery we don't add the handoff at all so its not relevant i think
[17:45] <apw> but for the second one we must hit the issue yes
[17:47] <apw> slangasek, now if we can not put on handoff that is fine, i was under the impression it wasn't easy as string mangling was hard.  i have the patches to use this new enable just testing the cleaned up kernel bit now
[17:47] <apw> and the patch for grub is very small as its only 10_linux that changes
[17:50] <slangasek> apw: splitting strings is hard, concatenating them is easy... we'd just move the vt.handoff=7 bit out of the pre-generated string and append it dynamically, I think
[17:51] <slangasek> should still only change 10_linux
[17:51] <apw> does that make it harder to debug should you not want it
[17:51] <apw> should you want to test without it
[17:51] <slangasek> I don't think so
[17:52] <apw> http://people.canonical.com/~apw/vt-handoff-grub-precise/0001-TEST.patch
[17:52] <apw> bah not that one
[17:52] <apw> http://people.canonical.com/~apw/vt-handoff-grub-precise/grub-10_linux.diff
[17:52] <apw> slangasek, ^^ that is the grub change i am using
[17:52]  * slangasek nods
[17:53] <apw> slangasek, ok ... wahts the right thing to do here.  not specificying the handoff at all will work fine kernel side
[17:53] <slangasek> apw: on a call now; give me about an hour to cook a patch for grub the way I think it should be, that won't require any extra kernel options?
[17:54] <apw> slangasek, ok .. will check back later
[18:07] <L3mce> Hello. In an attempt to run our script in init.d prior to the other S99's, but after the S98's our project has always named that script beginning with a 0. I have rewritten the way this script functions and as a result noticed that it was running twice, whereas the old method masked this behavior. Throwing a $1 confirms two starts were sent, pstree indicated that rc was issuing both calls, so I read rc, and it turns out that it is
[18:07] <L3mce> very clever in attempting to figure out runlevel, however as a result, any scripts updated there with a digit are run from rc5.d as (in our case) 99 and again as 90. Would it be appropriate for me to write a patch which counts digits and changes the nomenclature of the symlinks created?
=== dendrobates is now known as dendro-afk
[18:14] <L3mce> I guess it would be smarter to make rc count digits
[18:16] <apw> L3mce, can't you use _ or something similar ?  instead of 0, and avoid the issuue?
[18:16] <L3mce> I have renamed it a0start_avwizard I just thought that in the future if rc was not confused by digits it would be better for the product.
[18:18] <L3mce> I am solved. I just didn't know whether to file a bug and a fix.
[18:19] <L3mce> or which version to attach it to
=== beuno is now known as beuno-lunch
=== bladernr_ is now known as bladernr_afk
[19:00] <sabdfl> what tool builds the iso? i have a squashfs from live-build and would like to make a small live iso from it
=== beuno-lunch is now known as beuno
[19:12] <penguin42> would you expect fortify to throw if you tried to snprintf into a 64byte buffer, a 40 character string, but the length you told snprintf the buffer was was 128 ?
[19:16] <penguin42> I guess snprintf might 0 term the last byte or something
[19:23] <slangasek> sabdfl: the "last mile" of ISO generation is done with ubuntu-cdimage and an internally-maintained debian-cd; both of these are private branches on nusakan
[19:25] <kees> what does whoopsie-daisy do that apport doesn't?
[19:25] <JanC> slangasek: why private?
[19:25] <slangasek> JanC: because, er, sabdfl didn't let cjwatson release it ;)
[19:26] <slangasek> (or something like that)
[19:26] <sabdfl> yeah yeah
[19:26] <slangasek> kees: it's the crash-database client
[19:27] <slangasek> kees: so it reports to the crash database with its nosql magic data aggregation, rather than LP
[19:27] <kees> ah-ha
[19:28] <kees> so it took over some of the crash reporting stuff that apport was doing?
[19:28] <L3mce> sabdfl: take a look at ubiquity/casper
[19:28] <sabdfl> thanks slangasek
[19:28] <slangasek> sabdfl: sure :)
[19:29] <slangasek> kees: yes; the plan is that pre-release, it'll be reported to *both* LP and the crashdb, and post-release we'll only report to the crashdb - so not asking users difficult bug-reporting questions
[19:30] <kees> slangasek: excellent.
[19:43] <hallyn> FINALLY!
[19:44] <hallyn> apparmor is to blame!  but, only indirectly :)
[19:52] <L3mce> mountall?
[19:57] <stgraber> hallyn: still balming apparmor? ;)
[19:57] <stgraber> hallyn: btw, if you want to blame it some more, it looks like "ro, remount" still doesn't match (or stopped matching again, one of the two). Got some apparmor DENIED when rebooting a container today
[19:57] <hallyn> stgraber: see final comment in bug 961217
[19:57] <ubottu> Launchpad bug 961217 in libvirt (Ubuntu) "virsh start domain sometimes fail in oneiric" [High,Confirmed] https://launchpad.net/bugs/961217
[19:58] <hallyn> stgraber: hm, interesting - but the noise is ok with me so long as we're refusing the remount :)
[19:59] <stgraber> hallyn: yeah, at least that part works ;)
[20:02] <stgraber> jjohansen: ^ :) not urgent but "deny mount options=(ro, remount) -> /," still doesn't match... (call "halt" in a container and look at dmesg to reproduce)
[20:03] <jjohansen> stgraber: yep, still working on part 3 of the fix, it should hopefully land friday
=== vibhav is now known as Guest6358
[20:06] <stgraber> jjohansen: hehe, ok :)
[20:26] <slangasek> apw: untested: http://paste.ubuntu.com/915139/
[20:27] <quadrispro> hi all
[20:32] <slangasek> apw: do you have a master bug # for this, btw?
=== dendro-afk is now known as dendrobates
[21:10] <slangasek> N: 1020 tags overridden (1020 errors)
[21:10]  * slangasek fears
[21:22] <seb128> slangasek, hey
[21:22] <slangasek> seb128: hey there
[21:22] <slangasek> freetype? :)
[21:22] <seb128> slangasek, are you subscribed to the freetype mailing list?
[21:22] <slangasek> yeah
[21:22] <slangasek> seb128: isn't Werner wrong about default dpi?
[21:22] <seb128> slangasek, I think they picked up the space discussion from my email, not the gtk underline issue
[21:22] <slangasek> my X server says 96
[21:22] <slangasek> not 72
[21:22] <slangasek> right
[21:22] <seb128> slangasek, 96 is default yes
[21:22] <slangasek> maybe if we get the code right, both issues are fixed?
[21:23] <slangasek> I don't know though
[21:23] <seb128> and I'm pretty sure things in the stack hardcode 96 nowadays
[21:23] <seb128> slangasek, well, reverting fixes both
[21:23] <seb128> slangasek, but upstream doesn't seem to think it's the way forward :p
[21:23] <slangasek> yeah
[21:24] <slangasek> but upstream may just be mistaken about what the defaults are
[21:24] <slangasek> I was going to follow up later today and point that out
[21:25] <slangasek> though perhaps the conclusion there is still that gtk is using the wrong API call?  I don't know
[21:26] <slangasek> the discussion is a bit too deep for me :){
[21:27] <seb128> slangasek, yeah, I didn't understand everything either but I'm pretty sure GTK enforce 96 dpi and doesn't use the xorg returned value
[21:27] <slangasek> well, and X is spitting out 96 anyway regardless of physical dpi
[21:27] <seb128> slangasek, http://git.gnome.org/browse/gnome-settings-daemon/commit/?id=a49af89751057649034a42c511d2330d63bbfa6e
[21:27] <slangasek> for reasons that have been well-trodden :)
[21:27] <seb128> slangasek, right
[21:28] <seb128> slangasek, well in any case I was pinging because I'm unsure their discussion is covering at all the gtk underlining issue, I don't understand why that has to do with the spacing
[21:29] <slangasek> I don't either...
[21:30] <slangasek> perhaps it's because gtk calculates the bounding box with an off-by-one error compared with what freetype returns, and the underline gets clobbered by the glyph?
[21:33] <seb128> slangasek, I pointed it to the gtk guys, behdad (pango's upstream) said he would have a look
[21:34] <seb128> <Company> it's either clipping (though we don't do that for labels)
[21:34] <seb128>  or a pango bug
[21:34] <seb128> slangasek, that's basically the replies I got, but I think I will have news tomorrow from their side
[21:34] <seb128> slangasek, I will keep you updated
[21:34] <slangasek> ok
=== dendrobates is now known as dendro-afk
=== dendro-afk is now known as dendrobates
[21:44] <bdrung> jdstrand: re distro-info MIR, in your last comment, did "upstream is volatile" refer to liblist-compare-perl?
[21:45] <jdstrand> bdrung: no, it referred to the fact that the package is constantly being rewritten
[21:45] <bdrung> jdstrand: see my comment. it won't be rewritten again.
[21:45] <jdstrand> well, constantly is probably strong
[21:45] <jdstrand> but this is the 3rd time
[21:45] <jdstrand> :)
[21:46] <bdrung> jdstrand: the third rewrite wasn't necessary, but i was curious about the result
[21:47] <jdstrand> bdrung: ok. that seems reasonable I guess, but poke smoser about commenting on it
[21:48] <bdrung> tumbleweed: can you comment bug #964008 regarding liblist-compare-perl?
[21:48] <ubottu> Launchpad bug 964008 in distro-info (Ubuntu) "[MIR] distro-info, distro-info-data, and shunit2" [Undecided,In progress] https://launchpad.net/bugs/964008
[21:51] <apw> slangasek, been using this one: https://launchpad.net/bugs/942846
[21:51] <ubottu> Launchpad bug 942846 in linux (Ubuntu Precise) "encrypted install fails to boot as long as vt.handoff=7 is used" [High,In progress]
[21:51] <apw> slangasek, if you have something that needs testing let me know ;)
[21:54] <slangasek> apw: did you see the pastebinned patch?  I can push a bzr branch for it
[21:55] <slangasek> my own testing here is waiting for the test system to be upgraded from oneiric
[21:55] <slangasek> (I don't boot it very often :P)
[21:58] <slangasek> apw: lp:~vorlon/ubuntu/precise/grub2/lp.942846
[22:01] <slangasek> apw: though actually, I'm wondering why the reporter's machine should have ended up with =text... that should only happen if 1) the previous boot failed, 2) the 'hwmatch' command failed in grub, or 3) the card was in the blacklist, and the last should not be the case since he's using nouveau?
[22:01] <slangasek> I think you're absolutely right that there's a bug here in our vt.handoff usage, I'm just not convinced fixing it will help this bug submitter
[22:03] <slangasek> oh, maybe he has GRUB_GFXPAYLOAD_LINUX=text in his /e/defaults/grub
[22:04] <slangasek> which means I have a bug in my patch as well, let's fix that
=== dendrobates is now known as dendro-afk
=== yofel_ is now known as yofel
=== bladernr_afk is now known as bladernr_
=== salem_ is now known as _salem
[23:31] <slangasek> stgraber: how do graphics work/not work in containers?
[23:32] <slangasek> stgraber: I'm considering /etc/init/udevtrigger.conf at the moment, which moved from an 'exec' to a 'script' for container support... and I'm pondering whether it can be switched back by dropping the 'container' condition, but want to be sure I understand the knock-on effects for other services
[23:33] <slangasek> stgraber: we could make udev-fallback-graphics start immediately on 'container', or we could make it not run at all when in a container... I don't know which would be better
[23:36] <infinity> roaksoax: Where's my feature freeze request for that maas upload with all the new features? :P
[23:38] <infinity> roaksoax: (Your standing freeze exception was until Beta 2, and we're well past that now)
[23:38] <roaksoax> infinity: heh, well i was told I have until FinalFreeze :)
[23:39] <stgraber> slangasek: right, so the problem is that we don't have a separate device namespace yet, so the reason why we prevented udevtrigger from starting in a container is that if run, it'd re-trigger everything in all containers and outside the container, which we certainly don't want
[23:39] <infinity> https://bugs.launchpad.net/ubuntu/+source/maas/+bug/937121 disagrees
[23:39] <ubottu> Launchpad bug 937121 in maas (Ubuntu) "Standing feature freeze exception for maas in Precise" [Undecided,Triaged]
[23:39] <stgraber> slangasek: but to answer your question, a container usually doesn't have direct access to graphic hardware
[23:39] <infinity> roaksoax: And even if the bug didn't disagree, common sense probably does. :P
[23:40] <roaksoax> infinity: well, could you please raise this issue with Daviey
[23:41] <infinity> roaksoax: ...?
[23:41] <roaksoax> infinity: the FFe only standing to Beta2
[23:42] <infinity> It's right there...
[23:42] <infinity> Agreed to by Francis even.
[23:42] <roaksoax> infinity: yes I know, that's why I'm saying. Could you please raise it to Daviey ? Because, Daviey himself I can freely upload until Final Freeze
[23:43] <slangasek> stgraber: so the bits that chain off of udevtrigger currently are udev-fallback-graphics, networking, cryptsetup, and, er, cups.  cups almost certainly needs fixed in that case to be 'or container' (or to just drop it completely).  Do you think we can generalize about the right thing to do with the others?
[23:45] <stgraber> slangasek: in general 'or container' should be safe for these
[23:45] <slangasek> stgraber: safe yes, but is it *correct*?  I don't want to change all of them if I don't have to :)
[23:46] <stgraber> slangasek: it's unlikely we'll ever need udev-fallback-graphics or cryptsetup in a container but at the same time, if I want, I can make you a container using these, so it's not impossible someone would actually need these for something useful
[23:47] <slangasek> stgraber: you would 'modprobe vesafb' in a container?
[23:48] <slangasek> hmm, what's 'netscript-2.4-upstart'?
[23:48] <slangasek> (archive-grepping)
[23:49] <stgraber> slangasek: you can get 'modprobe vesafb' to work in a container but I really don't see a case where you'd want that job to trigger and where it'd be useful (didn't trigger outside of the container first)
[23:50] <slangasek> right
[23:50] <stgraber> slangasek: so you can probably keep that one as it's
[23:51] <slangasek> stgraber: well, I guess the reason to *try* to run u-f-t in a container is that the DMs have a start condition that's udev-fallback-graphics, ORed with drm-device-added... and that's a udev event so would never be seen in the container, right?
[23:53] <stgraber> currently containers see all events, so I could in theory allow a container access to a displaylink device, then plug it post-boot and the container will get that event and the container's udev will react on it
[23:53] <stgraber> but as we don't re-trigger existing events, that only applies to devices appearing post-boot and only if the container is then allowed to access it (device cgroup restrictions)
[23:54] <slangasek> and if the video device you're plugging in comes up as card0, which is not likely
[23:54] <stgraber> indeed
[23:54] <slangasek> ok, so I think u-f-g should be 'or container'
[23:55] <stgraber> yeah, I think it's best to consistently have 'or container' so these weird people copy/pasting without reading will get it for sure and we won't get stuff not starting in container in later releases because of bad copy/paste :)