[00:54] <bemagri> hello
[00:55] <bemagri> anyone?
[00:59] <RAOF> !ask > bemagri
[01:06] <bemagri> I don't have any questions for now... I'm just looking for an open source project to join
[01:08] <RAOF> Ok; but you presumably have a question, even if it's “how do I join the Ubuntu project” :)
[01:10] <bemagri> oh well... you got a point there!
[01:10] <bemagri> so, how do I join the Ubuntu project?
[01:14] <penguin42> bemagri: http://www.ubuntu.com/community  has some pointers depending what you want to do
[01:16] <bemagri> i wan't to start a new project, so I wanted to know what kind of applications do you guys miss in ubuntu?
[01:18] <penguin42> bemagri: Obviously there are lots of bugs in bugs.launchpad.net, there are also some larger scale designs on https://blueprints.launchpad.net/ubuntu many of which some people have already started
[01:20] <bemagri> penguin42, i will take a look, thanks
[01:20] <penguin42> bemagri: However, it's normally best if you ask what _you_ miss!
[01:23] <bemagri> penguin42, it's harder to ask that question! :)
[01:47] <smoser> slangasek, aroun d?
[01:48] <smoser> bug 937352, maybe someone else has thoughts.
[01:49] <smoser> it would appear there, that, in initramfs:
[01:49] <smoser>  mount /dev/sda1
[01:49] <smoser>  umount /dev/sda1
[01:51] <smoser>  sfdisk ... (to grow /dev/sda1 to fill extra unallocated space)
[01:52] <smoser>   but there, "BLKRRPART: Device or resource busy"
[01:53] <smoser> the only thing i can think of that would have the resource busy would be the 'mount', but clearly the umount did finish and returned succesfully.
[02:11] <penguin42> something like ureadahead or udisks ?
[02:40] <psusi> smoser, it sounds like the resize patches may hit mainline soon and hopefully can get applied to the precise kernel
[02:41] <smoser> psusi, well, that'd be good.. but i dont know that i'd likely pick up user space changes for that.
[02:41] <smoser> i really do appreciate your help on it, but just think it would be a 12.10 thing at this point.
[02:41] <psusi> that would be a shame
[02:42] <psusi> 12.04 will be around for a long time
[02:43] <smoser> what all do i need from user space ? are there utilities i can use ? ie, can i do this in the same amount or less code than i already have doing it?
[02:43] <smoser> moving it out of initramfs is nice
[02:44] <psusi> smoser, you can either switch from sfdisk to parted, or ignore the BLKRRPART error, and run partx -u to update the in kernel tables
[02:45] <psusi> or sfdisk could be patched to use the BLKPG ioctl instead of BLKRRPART the way I did to parted, but that would be a bit more involved
[02:46] <psusi> easiest thing is probably just to ignore the error and run partx -u
[02:47] <smoser> partx -u requires update to parted?
[02:47] <psusi> no... requires a patch to partx that I wrote a few months ago ;)
[02:48] <smoser> right.
[02:48] <smoser> did you get it upstream ?
[02:48] <smoser> i remember you tried
[02:48] <psusi> I submitted it, they said it looked good but wanted to wait for the kernel patch to hit mainline
[02:48] <smoser> ah
[02:49] <psusi> hopefully that will happen here soon and then it can be applied to util-linux and hopefully both backported to ubuntu... I've had a bug filed to apply the patch to the ubuntu kernel for months without any comment... hopefully if it gets merged mainline the right person can be poked to apply it to precise
[02:50] <psusi> then a sponsor can merge the util-linux branch that has been waiting in the wings, and you're good to fix the cloud package to run partx -u
[02:51] <psusi> hopefully by 12.10 I'll have gparted taking advantage of it
[02:57] <psusi> I'm even kicking around the idea of btrfs being able to relocate the start of the partition on the fly ;)
[03:00] <psusi> smoser, by the way, why don't the cloud images just not use a partition table at all?
[03:01] <smoser> grub complains about being installed onto a disk without a partition table.
[03:01] <smoser> but i suppose it is perhaps not a real requirement
[03:02] <psusi> well, you don't need it for pv domUs
[03:02] <psusi> but if you're doing full hardware virtualization then I guess you do
[03:04] <smoser> well.. .we make availalbe 2 types of images.
[03:04] <smoser> one is "raw partition" (ie, no partition table).  that is what is used on EC2, where pv-grub loads the kernel from inside the image without being installed.
[03:05] <smoser> (without being installed anywhere in the image at all)
[03:05] <smoser> the other is "full disk". which is what we recommend to use on full virt (kvm) and has grub installed in the MBR.
[03:05] <smoser> its much more traditional disk
[03:15] <psusi> smoser, have you seen the recent discard option to e2fsck?  I found a bug in it today while playing with it, but seems like it would be useful for virtual machines to be able to trim the unused space from the virtual images
[03:15] <smoser> i did not know e2fsck had trim support. that is awesome.
[03:16] <smoser> i dont know if it is in the qcow kvm driver though
[03:16] <smoser> do you?
[03:16] <smoser> i knew ext4 had trim support but i'm assuming you mean i can run 'e2fsck' with '--trim' or some such and it will make the trim calls at that point. that would be useful.
[03:16] <psusi> smoser, not sure if it does it via TRIM, but you can now run e2fsck on a sparse raw disk image and it will use fallocate() to punch holes in it returning the unused sectors to sparse
[03:17] <psusi> e2fsck -E discard, yea
[03:18] <psusi> e2image also can now create a qcow2 image from a raw block device or sparse image and vice versa..
[03:19] <psusi> and I submitted a patch the other day to add a switch allowing it to actually include all of the data blocks instead of only the metadata for debugging
[03:31] <smoser> psusi, given e2image writing qcow2...
[03:32] <smoser> i could use qemu-nbd for a qcow disk, point e2image at /dev/nbd0 and make a re-sparsified qcow image
[03:32] <smoser> which is useful.
[05:20] <william1234> h
[06:15] <micahg> @pilot in
[06:22] <nigelb> "Morning" micahg
[06:23] <micahg> nigelb: it *is* morning for me :)
[06:23] <nigelb> Wait, where are you today?
[06:24] <micahg> nigelb: it's after midnight :)
[06:25] <nigelb> See, I did have in my mind that you were in Chicago and its horribly late there :)
[06:25] <micahg> nigelb: yes :)
[06:25]  * micahg will brb
[06:26] <nigelb> :)
[06:42] <micahg> can I get a TB member to set this to merged: https://code.launchpad.net/~l3on/ubuntu/natty/gdevilspie/fix-for-783568/+merge/89717
[07:02] <pitti> Good morning
[07:04] <ajmitch> morning pitti
[07:04] <micahg> hi pitti, can you set the above merge to merged?
[07:05] <pitti> micahg: done
[07:05] <micahg> thanks
[07:05] <nigelb> Morning pitti!
[07:05] <nigelb> evening ajmitch :)
[07:06] <ajmitch> hi nigelb :)
[07:53] <dholbach> good morning
[07:58] <micahg> pitti: with https://launchpad.net/ubuntu/+source/packagekit/0.7.2-2ubuntu3, did you mean to drop the packagekit recommends as well and not just the aptd alternative?
[07:59] <pitti> micahg: yes, I did; libraries should not usually depend on a daemon
[07:59] <pitti> I explained some details in the recent PK sync request
[07:59] <pitti> we can reintroduce the alternative depends if we explicitly seed aptdaemon-pkcompat
[08:01] <micahg> ah, haha, sorry, didn't scroll down far enough apparently :-/
[08:05] <micahg> pitti: so, the new version has all the ubuntu patches, should I go ahead and seed the pkcompat alternative and if so where specifically?
[08:06] <pitti> micahg: yes, please; in the ubuntu "desktop" seed
[08:07] <micahg> ok, will do
[08:07] <pitti> cheers
[08:09] <GunnarHj> micahg: Hi Micah! Could you please merge https://code.launchpad.net/~gunnarhj/gnome-settings-daemon/patch43/+merge/91210 ? It ought to be harmless, since it's just a description update. :)
[08:10] <micahg> GunnarHj: sure, I can have a look when I'm done with packagekit
[08:11] <GunnarHj> micahg: Great, thanks.
[08:11] <micahg> pitti: is a recommends in the seed enough or do we need a depends?
[08:12] <pitti> micahg: recommends is fine
[08:14] <micahg> pitti: I assume I need a meta upload before I can sync packagekit?
[08:15] <pitti> micahg: it should actually work without it these days
[08:15] <micahg> ok, are we worried about packagekit being pulled into desktops?
[08:15] <pitti> micahg: the metapackage is just for upgrades, I think livefses are built out of the seed bzr branches
[08:15] <pitti> micahg: yes, we don't want PK, we want aptdaemon-pkcompat
[08:16] <micahg> oh, right, desktops will already have the alternative fulfilled :)
[08:16] <pitti> PK is slow, doesn't work with debconf etc., and the aptcc backend doesn't support plugins, etc.
[08:16] <micahg> I was worried about it being pulled in on upgrade, but that shouldn't happen
[08:23] <pitti> micahg: well, we do need a -meta upload at some point of course
[08:24] <micahg> pitti: the apt backend is enabled in Debian now, do we want this?  I guess this needs an FFe as well
[08:25] <pitti> micahg: yes, we want this
[08:25] <micahg> pitti: can I take that as an FFe as well :)
[08:25] <pitti> it has tests and is the more active one
[08:25] <micahg> pitti: also, do we need your apt_fixes patch now?
[08:25] <pitti> micahg: and again, we don't even install it by default, so fine for me
[08:26] <pitti> micahg: it would make sense now, but I don't depend on it
[08:26] <pitti> I think it's fine to wait for a new upstream release to get the fixes
[08:26] <pitti> until then, plugins will only work with aptdaemon
[08:26] <pitti> micahg: the only patch that we need is the backport for the LANGUAGE_SUPPORT enum
[08:26] <micahg> yep, that one is there
[08:27] <micahg> ok, syncing
[08:50] <jokerdino> here i am
[08:50] <micahg> jokerdino: are you familiar with bzr at all?
[08:51] <jokerdino> the problem is my network blocks the bzr port
[08:51] <micahg> you can do bzr over ssh
[08:51] <jokerdino> guide me please.
[08:51]  * micahg thought the default was bzr+ssh
[08:51] <micahg> bzr branch lp:software-center
[08:52] <jokerdino> i branched it and edited the file there.
[08:53] <micahg> jokerdino: you're most of the way done then, just bzr push lp:~yourusername/software-center/nameyourbranchhere
[08:54] <jokerdino> ssh: connect to host bazaar.launchpad.net port 22: Connection refused
[08:54] <jokerdino> ConnectionReset reading response for 'BzrDir.open_2.1', retrying
[08:55] <micahg> after that you should be able to bzr lp-open and propose a merge the gui way or bzr lp-propose should let you skip a step
[08:55] <jokerdino> The network is blocking the port, i think
[08:55] <micahg> ah, let me see if I can find out what to do about that
[08:58] <astraljava> screwcork?
[08:59] <astraljava> err... corkscrew :D
[08:59] <micahg> jokerdino: unfortunately, launchpad doesn't have a workaround for your issue at the moment, but now you can make a proper diff, (bzr diff -c-1) and attach that to the bug
[09:00] <jokerdino> i see. thanks!
[09:01] <astraljava> jokerdino: If you can install corkscrew, it can be easily configured so it reroutes ssh protocol through http port (80) proxy, which is what I'd presume your network utilizes (when they're blocking port 22 anyway).
[09:01] <jokerdino> yeah it only allows port 80
[09:02] <jokerdino> what parameters should I pass for corkscrew to work?
[09:03] <astraljava> It needs a conf file. Let me find a link that explains how you configure it.
[09:05] <astraljava> jokerdino: http://wiki.linuxquestions.org/wiki/Corkscrew  -- Actually, you configure your ssh to tunnel through that, sorry. Have a go, if you like. But be aware, that this might be against your information management policies. :-/
[09:21] <jokerdino> astraljava: i tried but i get this error.
[09:21] <jokerdino> Couldn't establish connection to proxy: Network is unreachable
[09:21] <jokerdino> ssh_exchange_identification: Connection closed by remote host
[09:22] <astraljava> jokerdino: Did you find out your proxy server and port?
[09:23] <jokerdino> oh, ooops. i put the wrong one.
[09:23] <jokerdino> where do i find the proxy server and the port?
[09:29] <sveinse> For development: Does anyone know what the apt.config option is for setting options to dpkg? --force-confnew to be specific?
[09:35] <astraljava> jokerdino: I don't know, do you have browser auto-configuration maybe? It might have that information somewhere in the settings.
[09:35] <astraljava> jokerdino: Otherwise, maybe see the hops when you're tracing them to a website or something.
[09:37] <jokerdino> astraljava: i don't seem to make much progress here. i am just going to heave a sigh of frustration and leave it aside. :/
[09:39] <astraljava> jokerdino: Yeah, just go with the patch route micahg suggested. That was a long shot, anyway.
[09:40] <astraljava> It works in some networks, but not nearly all of them, and I have no idea why.
[09:40] <jokerdino> yeah, touch luck here.
[09:41] <jokerdino> anyway, i appreciate your help
[09:43] <astraljava> No worries. It's just a handy tool, if you get it working.
[10:07] <micahg> @pilot out
[10:15] <Whoopie> Hi, I would like to get 2 patches pushed for the remmina package. It's bug report #926619 and #931336. The patches are two usability patches to re-add the desktop file and tray icon (appindicator) support.
[10:17] <tumbleweed> !sponsorship | Whoopie
[10:18] <mainerror> Stupid question incoming. What does "PTS BTS" mean on the build failures site?
[10:18] <tumbleweed> PTS = package tracking system. BTS = bug tracking system
[10:18] <tumbleweed> (they're both Debian systems)
[10:18] <mainerror> Oh, I see. Thanks. :)
[10:24] <Whoopie> tumbleweed: ok, both bug reports already have ubuntu-sponsors subscribed as a debdiff was attached. But how long should I wait to get feddback from a sponsors member? Because I don't want to be impolite or impatient.
[10:25] <tumbleweed> normally, a couple of days
[10:25] <tumbleweed> You could ask Ubuntu desktop people to look at it, the missing .desktop file is fairly important
[10:26] <tumbleweed> the package currently doesn't deviate from Debian, so it would be nice if those changes could be included in Debian (eventually)
[10:32] <seb128> Whoopie, tumbleweed: I will try to get the patch reviewed today
[10:33] <ryao> Are all packages in Ubuntu Precise being compiled with GCC 4.6.2?
[10:35] <ryao> I am specifically interested in knowing how grub is being compiled: http://packages.ubuntu.com/precise/grub
[10:35] <ryao> Nevermind. I will ask in the kernel team channel.
[10:39] <ryao> I am back here because cking asked me to ask my GCC question in this channel.
[10:40] <Whoopie> seb128: thanks!
[10:43] <cnd> didrocks, are you an archive admin who can approve NEW packages?
[10:43] <pitti> cking: FYI, http://www.piware.de/2012/02/power-usage-report-find-power-drain-causes/
[10:43] <didrocks> cnd: yes
[10:44] <cnd> didrocks, do you have time to review xorg-gtest (and hopefully approve)?
[10:44] <cnd> it was uploaded right before feature freeze :)
[10:44] <didrocks> cnd: will have a look, sure :)
[10:44] <cnd> thanks!
[10:48] <evfool> jibel, when you'll have the time, please my synaptic merge proposal at lp:~evfool/synaptic/ancientfixes
[10:48] <evfool> ^*please review
[10:49] <ryao> cjwatson: Do you know if the grub package in 12.04 is being compiled with GCC 4.6 or who would know?
[10:50] <ajmitch> ryao: the build logs are linked from the launchpad page - from the log, it appears that gcc 4.6.2 is used
[10:51] <ryao> ajmitch: How do I view that?
[10:52] <ajmitch> ryao: from https://launchpad.net/ubuntu/+source/grub, you can see the version in precise, the build logs are on the amd64 or i386 links in that section
[10:52] <ryao> Cool. Thanks. :)
[11:01] <cking> pitti, I'll spread the word too
[11:45] <pitti> Daviey, zul: will there be some kind of formal regression testing on the oneiric-proposed nova upload? (It's been in -proposed for two months now)
[11:57] <GunnarHj> micahg: Added a comment to https://code.launchpad.net/~gunnarhj/gnome-settings-daemon/patch43/+merge/91210. I think the description is ok, after all.
[14:40] <jdstrand> doko: hi. fyi, I just filed bug #937825. I am not blocked but thought I would at least file the bug as it might affect others.
[14:41] <beuno> pitti, this new awesome power usage tool, I installed it and it seems to want a specific version of powertop not in Precise: powertop-1.13 not found, please install it.
[14:42] <pitti> beuno: sudo apt-get install powertop-1.13
[14:42] <pitti> beuno: unfortunately the current powertop doesn't provide what we need any more
[14:42] <beuno> pitti, ah! :)  thanks
[14:42] <beuno> should it be a dependency of fatrace?
[14:43] <pitti> beuno: well, admittedly fatrace is not the most appropriate place for the script
[14:43] <pitti> but I didn't think of a better one
[14:44] <pitti> fatrace itself has nothing to do with powertop
[14:44] <pitti> it started out as just a script somewhere, but it seemed useful to put it into the distro
[14:44] <jdstrand> barry: hi!, you may be interested in ^ as well
[14:45] <beuno> pitti, 1.13 seems to have a problem installing: https://pastebin.canonical.com/60652/  (and apport hit MaxReports again somehow!)
[14:46] <pitti> powertop-1 1.13-0ubuntu1~dooz1
[14:46] <pitti> beuno: ^ that's not ubuntu's fault
[14:46] <pitti> seems you previously activated some PPA or so
[14:46] <beuno> ah
[14:46] <barry> jdstrand: looking
[14:48] <jdstrand> I'm not sure what we want to do as the bug says that './' is incorrect usage, however, it seems people will hit this issue
[14:49] <doko> **ck ... third X crash today :-(((
[14:53] <Whoopie> seb128: Would you prefer 1 debdiff with all patches included for remmina? I could prepare it.
[14:53] <seb128> Whoopie, that would be better, but wasn't one of the debdiff including both fixes? just had a quick glance to the comments
[14:54] <seb128> Whoopie, btw did you test that indicator works? pitti said he tried to enable it but nothing was displaying under unity
[14:54] <Whoopie> seb128: no, both debdiffs include 1 fix. I prepare one.
[14:54] <pitti> Whoopie: I just enabled the build time option and added the build dep, it's in ubuntu-desktop
[14:54] <pitti> but I coudln't make it work
[14:54] <seb128> Whoopie, he didn't use your version, just compiled with it enabled (the build log shows it's using it)
[14:55] <Whoopie> seb128: regarding unity, I need to check. running gnome-session-fallback here.
[14:55] <seb128> Whoopie, did you try with indicator-applet on gnome-session?
[14:55] <Whoopie> seb128: yes, working fine.
[14:56] <Whoopie> seb128: ah, I ran Unity by accident some days ago, and the remmina tray icon was shown.
[14:56] <seb128> Whoopie, ok, don't worry then, I will test in a bit and let you know if I have issues
[14:56] <Whoopie> seb128: preparing the debdiff right now.
[14:57] <pitti> janimo`: are you going to upload a new linux-meta-ac100 soon?
[14:57] <pitti> janimo`: for 3.0.19-1
[15:00] <m4n1sh> ev: I still get undefined symbol  whoopsie_daisy_preferences_new
[15:00] <m4n1sh> full log here
[15:00] <m4n1sh> https://code.launchpad.net/~ev/activity-log-manager/whoopsie/+merge/93899
[15:01] <ev> m4n1sh: I'll have a look in a bit - buried in something else at the moment
[15:01] <m4n1sh> sure
[15:01] <m4n1sh> just informed you. take your time. Will release it tomorrow same time
[15:02] <ev> sure thing
[15:02] <ev> cheers!
[15:05] <Whoopie> seb128: I attached the all-in-one debdiff to bug report #931336.
[15:05] <janimo`> pitti, yes planning to, just making sure noone had a regerssion
[15:05] <janimo`> is it holding up something/confusing some tools?
[15:05] <seb128> Whoopie, thanks
[15:05] <pitti> janimo`: it's preventing the removal of the old binaries (http://people.canonical.com/~ubuntu-archive/nbs.html)
[15:06] <pitti> janimo`: that's how I noticed
[15:06] <janimo`> pitti, ok. I was trying to be conservative and letting people test the package but not autoupgrade yet, thanks for the prod though
[15:06] <pitti> janimo`: ah, ok; it's not that urgent, just wanted to ensure it's known and handled; thanks!
[15:07] <janimo`> pitti, yes, known and soon handled :)
[15:09] <pitti> cjwatson, barry, SpamapS, infinity: FYI, I updated britney to have armhf on http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html now, and armel on http://people.canonical.com/~ubuntu-archive/testing-ports/precise_probs.html
[15:09] <pitti> (with the next run)
[15:10] <pitti> and then we need some more hamster food to make LibO finish building on armhf :)
[15:14] <moustafa> ping ubuntu-devel
[15:15] <moustafa> Is there any documentation as to what's installed (or not installed) when a user selects the free software only option from the installation disc?
[15:19] <jml> I appear to have a broken apt: http://paste.ubuntu.com/851468/
[15:19] <jml> "E: Internal Error, No file name for libc6"
[15:22] <doko> hallyn, please could you add a reproducer to bug #933045?
[15:40] <doko> pitti: looking at /etc/init/lightdm.conf ... is there a preferred why how to look for the currently running/active login manager?
[15:40] <doko> seb128, mterry: ^^^
[15:40] <seb128> not that I know about
[15:41] <seb128> doko, /etc/X11/default-display-manager has the default login manager
[15:41] <seb128> but nothing garante you it's the running one
[15:41] <seb128> i.e you can sudo stop lightdm and sudo start gdm
[15:41] <mterry> not that I know of either
[15:42] <mterry> doko, for active, you could try various dbus addresses to probe for which is active
[15:42] <doko> mterry, do you have a shell snippet to do that?
[15:43] <doko> and: should lightdm restarted on NSS updates, like gdm was?
[15:44] <mterry> doko, no...  but I believe gdm registers org.gnome.DisplayManager and lightdm does org.freedesktop.DisplayManager.  Not sure about kdm
[15:46] <cyphermox> moustafa: to answer your question, I believe all it changes is whether restricted and multiverse are enabled (and thus whether packages like ubuntu-restricted-* are installed, or drivers such as the nvidia ones)
[15:46] <chrisccoulson> doko - mozilla bug 694594 wasn't a compiler bug after all ;)
[15:47] <chrisccoulson> or, at least i don't think it is
[15:47] <moustafa> cyphermox, So, little to no info?
[15:47] <cyphermox> moustafa: what do you mean?
[15:48] <moustafa> cyphermox, The person asking is looking for a list.  No mention of how specific that list should be
[15:49] <cyphermox> moustafa: I guess from there you could easily grep through Packages for multiverse and restricted to generate that list, if it's indeed the only different
[15:50] <doko> chrisccoulson, heh, interesting investigation, I assume ...
[15:50] <chrisccoulson> yeah ;)
[15:50] <moustafa> cyphermox, Good point
[15:51] <cyphermox> moustafa: also keep in mind that there's probably a very small list if what you're worried about is just what would get installed by default
[15:52] <cyphermox> moustafa: fwiw I checked by looking at the code in ubiquity. it would be worth looking at d-i as well maybe
[16:28] <Whoopie> seb128, pitti: I know why pitti's compiled version didn't work. Mine works because I wrote a patch to re-add trayicon support. The -i option was missing. Just FYI.
[16:28] <pitti> Whoopie: right, I didn't have that patch
[16:28] <seb128> Whoopie, yours doesn't work for me, just looking at it
[16:28] <pitti> Whoopie: but there's a configuration tab to enable applet support, nobody will explicitly specify it on the command line?
[16:29] <Whoopie> pitti: true, but the -i option is used when you tick the option in the applet.
[16:29] <pitti> aah
[16:30] <Whoopie> seb128: strange. Do you have the remmina-applet.desktop in ~/.config/autostart ?
[16:31] <seb128> Whoopie, I didn't restart my session, but there is no remmina-applet installed here
[16:31] <seb128> $ find remmina-1.0.0 -name remmina-applet*
[16:31] <seb128> $
[16:31] <Whoopie> seb128: did you enable the option in the applet. It should write the desktop file then.
[16:32] <seb128> Whoopie, what applet? I apt-get sourced the precise version, applied your patch, debuild, dpkg -i *.deb and I'm running remmina now
[16:33] <Whoopie> seb128: there's no remmina-applet installed. It's still the remmina binary which got appindicator support. Please enable Settings -> Applet -> Start tray icon automatically.
[16:34] <Whoopie> seb128: Then check if the desktop file is written under ~/.config/autostart
[16:34] <seb128> Whoopie, my build is buggy, hate quilt ;-)
[16:34] <seb128> Whoopie, rebuilding
[16:34] <Whoopie> seb128: and if you run remmina, you should see the appindicator icon.
[16:34] <Whoopie> seb128: ok
[16:35] <seb128> Whoopie, apt-get source unpackaged and applied the patches, patch -p0 < debdiff applied the diff but debuild built without applying the new patches
[16:35] <seb128> i.e I had an half serie applied
[16:35] <seb128> Whoopie, ok, it works now ;-)
[16:35] <seb128> the menu starts by a separator but otherwise it works ;-)
[16:36] <pitti> seb128: nice!
[16:36] <Whoopie> seb128: uff, great. ;-)
[16:36] <seb128> Whoopie, I don't like that "create an autostart for me though"
[16:36] <seb128> what I want is an indicator when I run remmina
[16:36] <seb128> not remmina to start with every session when I need it once a week
[16:37] <seb128> it's eating my boot time for no good reason this way :-(
[16:37] <Whoopie> seb128: right, but if you tick that option, you need that -i option. Otherwise, remmina isn't started.
[16:37] <Whoopie> seb128: you don't need to enable the option to have an appindicator. It's independent.
[16:39] <seb128> Whoopie, ok, that seems to work fine, I clicked that option for the same reason than pitti, to try to get an icon when it was buggy
[16:40] <seb128> Whoopie, I will sponsor that in a bit, thanks for the work!
[16:40] <Whoopie> seb128: thanks! and very welcome!
[16:43] <pitti> doko, infinity: looks like armhf needs a bootstrap of gnat-4.6; is that planned, or sohuld we just ignore the depwaits/failures for this on armhf?
[16:44] <Whoopie> pitti: regarding report #937548, does it mean that we wait until vpnc hits testing? Or can it be synced "right now"?
[16:45] <pitti> Whoopie: technically it can be synced right now
[16:45] <pitti> Whoopie: do you know if anyone actually tested the new version with our network-manager plugin etc.?
[16:45] <Whoopie> pitti: I did. :-)
[16:45] <pitti> nice
[16:46] <Whoopie> pitti: that's why I wanted to get it synced. I tested a build in my PPA.
[16:47] <pitti> Whoopie: synced, thanks
[16:49] <Whoopie> pitti: awesome, thanks!
[16:52] <moustafa> cyphermox, Why did I just see your Ubiquity response:?
[16:52]  * moustafa slaps self
[16:52] <cyphermox> err, I don't know. bad IRC? :)
[17:08] <dholbach> barry, could it be that sphinx is waiting on python-whoosh to go to main?
[17:09] <dholbach> seems it's needed for the test-suite
[17:15] <dholbach> barry, it seems if you just drop python-whoosh the tests using it are skipped (not many AFAICS)
[17:15] <dholbach> but I'll leave the decision to you
[18:18] <SpamapS> dpkg experts.. anybody have ideas about this one:
[18:18] <SpamapS> http://paste.ubuntu.com/851662/
[18:18] <SpamapS> Never seen 'E: Internal Error, No file name for libc6'
[18:20] <m_3> SpamapS: googling for related bugs seemed to hint at multiarch
[18:20] <m_3> SpamapS: and a purge, then reinstall all avail archs worked for them
[18:21] <m_3> SpamapS: but on libc6...
[18:21]  * m_3 sad
[18:49] <jdstrand> stgraber: fyi, I tested your isc-dhcp packages (client). the apparmor bits seem to be working fine
[18:54] <stgraber> jdstrand: thanks
[19:36] <barry> @pilot in
[19:49] <micahg> barry: if you get a chance, can you merge claws-mail-extra-plugins from Debian (one of the last things holding clutter-gtk-0.10 in precise)
[19:49] <jtaylor> barry: is sphinx shill going to get sorted out? I can'f find a mir for it
[19:50] <jtaylor> the numpy transition is done btw
[19:50] <barry> jtaylor: i'm doing a test build right now to drop whoosh dep (after consultation with upstream maintainer).  will upload when local build completes
[19:50] <barry> jtaylor: yay on numpy!
[19:50] <barry> micahg: yep, will do
[19:50] <micahg> thanks
[20:01] <barry> micahg: hmm. i think we'd need to upgrade both claws-mail and claws-mail-extra-plugins to 3.8.0.  we currently have 3.7.10.  i'm a claws users so i do care and will continue to watch it closely, but i think we're going to need an ffe for this.  what do you think?
[20:01] <barry> micahg: fwiw, i'd be in favor of moving to 3.8.0
[20:02] <micahg> barry: probably needs an FFe
[20:02] <barry> micahg: yeah.  i'll get that started
[20:13] <barry> aarg, the bongos are back!
[20:25] <ska> Can someone test TexLive's envlab ? I think i found a problem and fixed it but need confirmation.
[20:25] <ska> I'll provide the letter.tex file to test with.
[20:29] <ska> should I contact the maintainer directly?
[21:01] <barry> ScottK: thanks!
[21:01] <ScottK> barry: I knew you'd watch after it.
[21:02] <barry> yep :)
[21:08] <dobey> ScottK, Riddell: i attached .debian.tar.gz and .dsc for pyqt4 splitting work to bug #934270
[21:09] <ScottK> dobey: Could you attach a debdiff from the current package.
[21:10] <dobey> ScottK: is there an easy way to generate a debdiff, from the bzr branch?
[21:11] <ScottK> No idea.
[21:12] <ScottK> But if you've got the .dsc it's easy enough to do.
[21:12] <ScottK> Where's the bzr branch?
[21:12] <ScottK> I should be able to look at that diff (same content as the debdiff, I hope)
[21:14] <TheMuso> barry: Just mute audio in unity-greeter, problem solved.
[21:15] <barry> TheMuso: if that only mutes the greeter and doesn't mute the session, then that would be fine
[21:16] <TheMuso> barry: I think at the moment it does, or it did. I know there are plans to sync the user's audio settings with their logged in session.
[21:17] <barry> TheMuso: that would be ideal.
[21:28] <dobey> ScottK: lp:~dobey/ubuntu/precise/python-qt4/split-work
[21:33] <ScottK> dobey: That's going to break any package that depends on python-qt4 and uses the extensions you've now split out.
[21:35] <dobey> ScottK: yes, well. eggs omelette. that is obvious, and i don't knkow what packages those are. and we can't just Recommends: the spllit packages, because they'd then also end up on the CD which would defeat the whole purpose of splitting them out
[21:36] <ScottK> I understand.
[21:36] <ScottK> So that means there needs to be some way to figure it out and fix the relevant packages.
[21:36] <ScottK> We're post Feature Freeze, so "Meh, we'll sort it out later" isn't going to cut it.
[21:37] <broder> dobey: wait, why can't you recommends the split packages?
[21:37] <dobey> well it should be easy to sort out, if a tiny bit tedious
[21:37] <ScottK> I'd also need to sort it out before I could accept it in Debian, so it still needs to be sorted.
[21:37] <broder> i haven't looked at the work, but why not split it out into python-qt4-{core,gui,etc} then only depend on what you need?
[21:37] <dobey> broder: because recommends would get pulled onto CD if we stick it on the CD
[21:37] <broder> then python-qt4 is a compatibility package that pulls everything in
[21:37] <ScottK> broder: What about the existing packages that depend on python-qt4 and need some of all those?
[21:38] <ScottK> Right, something like that might work.
[21:38] <dobey> broder: yes, that's basically what i'm doing, except "core" is still python-qt4
[21:38] <broder> dobey: so why not split it out as well?
[21:39] <ScottK> Although if you're making all new packages, you ought to follow python policy and make them python-pyqt4.core, etc.
[21:39] <dobey> broder: because i was trying to minimize the change set, and only add split packages; not re-do the whole package
[21:39] <ScottK> I don't think it's avoidable.
[21:42] <dobey> meh, there's quite a bit of stuff that depends python-qt4 too :-/
[21:43] <ScottK> Yes.  Yes there is.
[21:44] <ScottK> So if you can make python-qt4 a dependency package that ends up with exactly the same stuff installed, you can avoid yourself a lot of work.
[21:44] <ScottK> Then you can depend on exactly the bits you need.
[21:46] <dobey> though if we're not going to find space on the CD for what we need anyway, i think i'd rather avoid making the change in precise, and just do it in quetzel
[21:47] <infinity> No, split now.
[21:47] <infinity> And make python-qt4 depend on the split bits.
[21:47] <infinity> Having that established in an LTS will get people used to the new world order.
[21:48] <infinity> Worst case, nothing changes at all.
[21:48] <infinity> Best case, you shuffle around deps on a lot of packages and potentially slim down install footprint here and there.
[21:53] <dobey> well, except i don't want to spend a lot of time doing that work, when it doesn't gain my team anything in the release, when i could be spending my time fixing bugs and doing stuff we need to get done, instead :)
[21:54] <ScottK> By the time Precise is released, Debian freeze for Wheezy will be close.
[21:55] <ScottK> I wouldn't support doing this split as an Ubuntu only change.
[21:55] <ScottK> Better do it now if you think you want it for questionable.
[22:10] <barry> jbicha, Riddell ping
[22:11] <barry> or ping anyone else on ~ubuntu-core-doc
[22:19] <barry> so here's my question: this merge proposal is obviously correct and i can easily sponsor it: https://code.launchpad.net/~dpolehn-gmail/kubuntu-docs/fix-818500/+merge/90239
[22:20] <barry> but it's a native package and i can't commit to lp:kubuntu-docs.  i'm leery of uploading the package w/o committing to trunk since they'll skew.  maybe i should just not sponsor it?
[22:21] <ScottK> barry: Can you ping Darkwing on #kubuntu-devel about it?
[22:21] <barry> ScottK: yep, thanks
[22:25] <stgraber> slangasek: GrueMaster tells me our live-build images now have /etc/resolvconf/resolv.conf.d/tail containing Canonical DC information ;)
[22:26] <slangasek> hmmmm
[22:26] <slangasek> I guess we should fix that!
[22:27] <infinity> If this is the new world order (and I suppost resolvconf's postinst makes some sense), maybe the solution is just to whack /etc/resolvconf/resolv.conf.d/tail in the cleanup phase in live-build.
[22:27] <infinity> And /etc/resolvconf/resolv.conf.d/original
[22:27] <infinity> Or, really, the entire contents of /etc/resolvconf/resolv.conf.d/ :P
[22:28] <stgraber> base and head should be safe, the rest shouldn't be there indeed
[22:28] <infinity> Mmkay, I shall apply that hammer, then.
[22:28] <infinity> Seems less fiddly than worrying about it either in resolveconf.postinst or in various installers.
[22:29] <stgraber> there's really no good reason to have DC dns data on the system anyway, so we probably should a rm -f of tail and original sounds good
[22:29] <slangasek> infinity: yes, I certainly wasn't looking at resolvconf for the fix
[22:30] <slangasek> live-build cleanup seems like a good place to whack it
[22:30] <slangasek> infinity: are you taking care of this then?
[22:30] <infinity> stgraber: Yeah, live-build used to already delete resolv.conf in the cleanup phase, so we just need to do the new equivalent of the same.
[22:30] <infinity> slangasek: Sure.
[22:30] <slangasek> ta
[22:30] <stgraber> infinity: I already have a live-build patch for resolvconf, so we'd need to update it and forward the change to Debian (where the previous patch was recently merged)
[22:31] <infinity> stgraber: Righto.
[22:31] <GrueMaster> So for now I can just wipe the tail and reboot?
[22:32] <stgraber> GrueMaster: removing tail and running "resolvconf -m" should do trick
[22:32] <slangasek> or wipe the tail and run service resolvconf restart
[22:32]  * slangasek nods
[22:32] <stgraber> *resolvconf -u
[22:35] <GrueMaster> Still have an issue where it is only looking to 127.0.0.1 for nameserver.
[22:35] <GrueMaster> Doesn't seem to matter though.
[22:36]  * GrueMaster is lost & confused.
[22:38] <infinity> Are installing dnsmasq or something by default now too?
[22:38] <infinity> That would explain the 127.0.0.1
[22:39] <slangasek> yes
[22:39] <slangasek> nm pulls in dnsmasq-base and runs it by default
[22:39] <slangasek> provides better responsiveness in the case of unreachable servers, and enables better split-dns handling with vpns
[22:40] <infinity> Makes resolvconf feel vaguely redundant, if it's all being managed by dnsmasq anyway.
[22:41] <slangasek> dnsmasq is only on the desktop :)
[22:41] <slangasek> resolvconf also fixes some server-side issues
[22:41] <slangasek> like dhclient trying to write to /etc before it's rw
[22:41]  * infinity nods.
[22:42] <infinity> Seems like, in that case, you coud replace the whole resolvconf mechanic with a simple early-run init job that just does mkdir /run/resolvconf && ln -s /run/resolvconf/resolv.conf /etc/resolv.conf
[22:43] <slangasek> what creates /run/resolvconf/resolv.conf?
[22:43] <infinity> Well, dhclient happily writes its own.
[22:43] <infinity> Perhaps a touch would be required.
[22:43] <slangasek> nah, it writes it to /etc/resolv.conf
[22:43] <infinity> Yes, hence the link.
[22:44]  * slangasek looks puzzled
[22:44] <slangasek> oh, you mean let dhclient write through the link?
[22:44] <infinity> Yeah.
[22:44] <slangasek> haven't tested that it'll do that
[22:44] <slangasek> don't really want to, because it's ridiculous to have 10 different code paths for updating resolv.conf
[22:44]  * Chipzz wonders where the time went linux was simple
[22:45] <Chipzz> this all sounds like a bunch of crack tbh
[22:45] <slangasek> it was never simple, it just failed in a familiar way
[22:45] <infinity> *shrug*... If the whole world works with resolvconf eventually, I don't much care.  I just have so many horrible memories. :P
[22:45] <GrueMaster> Chipzz: We released the 2.0 kernel.
[22:45] <Chipzz> exactly how many *daemons* do you want running on a desmtop system?
[22:45] <slangasek> infinity: yes; foundations has taken ownership of resolvconf though, and I've been pruning ;)
[22:46]  * Chipzz shakes his head in disbelief
[22:46] <infinity> slangasek: I guess I was just driving at the idea that "pruning" could have just been a question of providing a link and making sure other things correctly wrote through a link. ;)
[22:46] <slangasek> yeah, I know
[22:47] <slangasek> but that leaves corner cases unaddressed
[22:47] <slangasek> which means you'd still have *two* ways to manage /etc/resolv.conf, and have therefore not actually simplified ;)
[22:48] <Chipzz> seriously, maybe some things should just fail in a natural way?
[22:48] <Chipzz> what's next? installing quagga becuase your ISP's routing might be broken?
[22:49]  * infinity won't admit to doing that.
[22:49] <Chipzz> is it really ubuntu's job to account for broken DNS servers?
[22:49] <broder> Chipzz: absolutely. no question
[22:49] <broder> every other major os does this
[22:49] <broder> and broken DNS is responsible for a significant percentage of perceived connectivity problems
[22:50] <Chipzz> yes, and people should complain to their ISPs
[22:50] <Chipzz> your fixing symptoms, not problems
[22:50] <Chipzz> *you're
[22:50] <infinity> Hrm.
[22:51] <infinity> slangasek: Nothing breaks if a proper /etc/resolv.conf exists, right?
[22:51] <RAOF> And sometimes fixing the symptom is the best you can do.
[22:51]  * infinity is just wondering is perhaps resolvconf should be added to the ubuntu-core packageset.
[22:52] <Chipzz> I'm not convinced at all that the problem should be fixed, really?
[22:52] <slangasek> infinity: define "proper"?  on install and by default (debconfable), resolvconf moves aside any static /etc/resolv.conf
[22:52] <Chipzz> you're not fixing a problem inherint to ubuntu
[22:53] <Chipzz> *inherent
[22:53] <infinity> slangasek: Right, but if resolvconf isn't on the system at all, life goes on for all the bits that (used to?) write to /etc/resolv.conf?
[22:53] <Chipzz> you're not even fixing symptoms inherent of/caused by ubuntu
[22:53] <slangasek> infinity: right, pretty much
[22:53] <infinity> slangasek: Or have we made it so that resolvconf pretty much must exist.
[22:53] <infinity> ?
[22:53] <slangasek> infinity: it's a dependency of ubuntu-minimal, so ;)
[22:54] <slangasek> (so yes, it should be in ubuntu-core)
[22:54] <infinity> slangasek: Yes, but minimal isn't guaranteed to be installed.
[22:54] <slangasek> really?
[22:54] <infinity> slangasek: (And minimal isn't in core)
[22:54] <slangasek> ubuntu-core subsets minimal?
[22:54] <infinity> Yeah.
[22:54] <slangasek> that's interesting; I wasn't aware of that decision
[22:54] <infinity> By a lot.
[22:54] <infinity> The core definition is basically "what you need to run apt".
[22:54] <slangasek> previously, the view was "if you don't have the dependencies of ubuntu-minimal installed, you get to keep all 6 pieces"
[22:54] <slangasek> ok
[22:55] <slangasek> so I think it would be a good idea to have resolvconf in core
[22:55] <RAOF> Chipzz: No, you're fixing a problem in the environment surrounding Ubuntu.  You wouldn't say that a kernel fix to not use an instruction known to provoke hardware bugs on certain CPUs isn't a fix; this is similar.
[22:55] <slangasek> but perhaps you'd prefer to Wait and See ;)
[22:55] <Chipzz> RAOF: this is not similar in any way
[22:55] <infinity> slangasek: If we're to the point of saying your system is broken without resolvconf, we should just mark it Essential.
[22:55] <infinity> slangasek: At which point, core gets it for free.
[22:55] <Chipzz> RAOF: hardware cpu bugs are still *local*
[22:55] <Chipzz> they're caused by the setup ubuntu runs on
[22:55] <slangasek> infinity: that would be a serious abuse of the Essential flag
[22:55] <infinity> slangasek: If it's not actually Essential, we need to make sure the world works without it.
[22:55] <slangasek> we don't even have the upstart dep chain Essential :P
[22:56] <slangasek> nah, alternatively we could make it non-essential-but-a-dependency
[22:56] <infinity> slangasek: Well, that still makes it essential.
[22:56] <infinity> slangasek: Hair-splitting.
[22:56] <slangasek> moi?
[22:56] <Chipzz> broken DNS is, again, an external problem. meanwhile you're bloating the desktop, installing daemons that have no place on there whatsoever
[22:56] <slangasek> jamais
[22:56] <infinity> slangasek: Toi.
[22:57] <Chipzz> this is madness.
[22:57] <RAOF> Chipzz: I don't understand why that's an interesting distinction.  If the user can't connect to the internet unless we frob $FOO; why isn't not frobbing $FOO a bug?  If the CPU will hang unless we frob $FOO, even if it's not in the spec, you agree not frobbing $FOO is a bug.
[22:57] <slangasek> #ubuntu-sparta
[22:57] <Chipzz> slangasek: yeah ^^ :)
[22:57] <infinity> slangasek: My argument isn't so much about the flag itself but rather that is we're at a point where our networking has an undeclared dep on resolvconf to function, we need it to land in essential one way or the other.  Or fix that undeclared dep to no longer be true.
[22:58] <infinity> s/that is/that if/
[22:58] <slangasek> infinity: right.  nothing currently has an undeclared dep on it; and if we were to gut other packages such that they no longer work without it, I would add the dep
[22:58] <Chipzz> RAOF: technically he *can* connect to the internet
[22:58] <slangasek> but I'd rather talk to Debian first before that, since otherwise we pick up a delta for no good reason
[22:58] <infinity> slangasek: Okay, that was the initial question.  So, not having resolvconf isn't a problem, per se, and core can go on living life as it does.
[22:58] <slangasek> ok
[22:59] <RAOF> Chipzz: And I'm sure that they're *super* pleased that, technically, they can connect to the internet.  They just need to manually frob some stuff in order for it to be useful at all.
[23:00] <infinity> Chipzz: The internet without DNS is only the internet to a pretty tiny subset of users.
[23:00] <TheMuso> @pilot in
[23:01] <Chipzz> infinity: please tell me, exactly how many external problems do you intend to work around?
[23:01] <infinity> Seven.
[23:01] <barry> @pilot out
[23:02] <Chipzz> IMO there's a distinction between diagnosing a real problem, and bloating the desktop for everyone in order to avoid a problem that MAY exist for some users
[23:02] <broder> Chipzz: why *shouldn't* we do as many things as we possibly can that make clear improvements to the user experience?
[23:02] <broder> there's no may here. shitty dns servers are a real problem
[23:02] <Chipzz> seriously?
[23:02] <broder> without question
[23:02] <broder> i've run into them
[23:02] <Chipzz> I've been on several ISPs. not even once have I had the kind of dns problems you describe
[23:02] <slangasek> would you know if you had?
[23:02] <Chipzz> I would
[23:03] <slangasek> or would you just have had slower DNS resolution for a bit?
[23:04] <Chipzz> there are alternatives to trying to fix the problems IMO. a *much* saner alternative would be to provide a diagnostics tool that says: "Hi, your ISPs DNS is broken. Please contact your ISP with the following information, or use nameserver x.y.z.w"
[23:05] <stgraber> even in the perfect world where all the ISPs know how to run their DNS servers, they'll still advertise more than one so that you have a fallback in case of failure
[23:05] <stgraber> that's all nice but the libc doesn't do that fallback in a very pleasant way
[23:05] <stgraber> as in, you have to wait 3s every time you do a DNS query for the fallback to kick in
[23:06] <stgraber> instead, having a local resolver will fix that as the daemon can keep state (that a library obviously can't) and so won't cause the delay every single time
[23:06] <Chipzz> meanwhile what you ARE doing is diverting from existing standards, and make things a lot more opaque, for, what exactly?
[23:06] <stgraber> instead you'll see a 500ms second delay the first time, then the daemon will try and reach the server in the background and use it again when it's back
[23:07] <stgraber> please point me to the standard saying that OS shouldn't run a local resolver, because if such standard exists, well, pretty much nobody respects it
[23:07] <infinity> Chipzz: To be fair, the subest of people who care about opacity of /etc/resolv.conf are the same tiny subset of people who also know how to use the internet without DNS resolution.
[23:07] <infinity> Chipzz: We're trying to fix things for the other 99% of users.
[23:07] <Chipzz> infinity: I know how /e/r.c works. doesn't mean I know the IP of facebook by heart and telnet to it on port 80 :)
[23:08] <infinity> Chipzz: No, but you understand what "DNS" means.
[23:08] <infinity> Chipzz: Ask my mom if she does.
[23:08] <barry> of course, that even assumes the isp knows how to fix the problem, or that you can even find a person on tech support that knows what "DNS" stands for
[23:08] <infinity> Chipzz: And the part where you know what /etc/resolv.conf is either means (A) you got copy and paste instructions from a forum (those are so useful to follow!), or (B) you understand what it's for.
[23:08] <Chipzz> so you're much happier with a status-quo of broken ISP DNS servers then?
[23:08] <infinity> Chipzz: If you're in the latter camp, I'd contend that you can sort out why it might not be working.
[23:09] <TheMuso> c
[23:09] <TheMuso> whoops
[23:09] <Chipzz> infinity: and I would be puzzled why in the name of f*ck localhost is in my resolve.conf
[23:09] <Chipzz> stgraber: what's wrong with nscd?
[23:10] <Chipzz> if you insist of giving the libc example
[23:10] <Chipzz> *on
[23:10] <Chipzz> infinity: next thing I would do is take a very deep breath, sigh, wonder where the world has gone to and install debian
[23:12] <stgraber> Chipzz: no split DNS support, only caching nss entries so no particular DNS protocol awareness, does unwanted negative caching and that's before looking at the current stability issues and bugs
[23:12] <stgraber> Chipzz: though it indeed as some nice feature like per-user caches and the integration in the nss stack is interesting, we actually have these mentioned in the DNS spec for Precise
[23:12] <slangasek> oh man, to list all the things wrong with nscd
[23:18] <Chipzz> maybe the next step should be to install squid on the desktop too
[23:18] <Chipzz> you know, in case facebook goes down, people can still get a locally cached page
[23:18] <slangasek> I liked the quagga idea better
[23:18] <Chipzz> except that probably won't work :P
[23:19] <Chipzz> but IMO you seriously need to ask yourself the question where you draw the line
[23:19] <Chipzz> and IMO this is crossing the line
[23:20] <infinity> stgraber: Your patch confuses me.
[23:20] <infinity> stgraber: The goal was to have it not Truncate if resolv.conf was a symlink, right?
[23:20] <stgraber> infinity: right
[23:21] <infinity> stgraber: Oh, or only if it's a dangling link, I guess.
[23:21] <infinity> stgraber: Cause if it's not dangling, [ -e ] is still true.
[23:21] <stgraber> infinity: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657640
[23:22] <bdmurray> slangasek: where does /etc/apt/sources.list come from on a live cd?  I've a strange line in mine on the latest daily build
[23:23] <infinity> bdmurray: How strange?
[23:23] <stgraber> infinity: that was for when resolv.conf was an absolute symlinks to /run/resolvconf/resolv.conf, now we made it a relative symlink, so that code probably no longer does much (as -e will indeed succeed)
[23:23] <bdmurray> infinity: cdrom:... dists/precise/main/binary-i386/
[23:24] <bdmurray> infinity: whoops not that one
[23:24] <bdmurray> cdrom:... precise main restricted
[23:24] <infinity> stgraber: Well, yeah. ;)
[23:25] <infinity> bdmurray: Depending on the contents of [...], that might be just fine.
[23:25] <slangasek> bdmurray: these days I believe it's live-build
[23:25] <stgraber> slangasek: if it was only for my setup and not the 99.9% of the other users, I'd definitely +1 quagga by default ;)
[23:26] <bdmurray> cdrom:[Ubuntu 12.04 LTS _Precise Pangolin_ - Alpha amd64 (20120221)]/ precise main restricted
[23:26] <stgraber> oh, well, then I'd also need strongswan though, because everybody needs BGP over IPSEC over IPv6 ;)
[23:27] <bkerensa> stgraber: How can I set a different default pastebinit url? :)
[23:28] <infinity> bdmurray: Does apt not like that?  It seems like a reasonable CD URI.
[23:28] <stgraber> bkerensa: you'll need to use the ugly ~/.pastebinit.xml file for that
[23:28] <stgraber> bkerensa: there's an example in the manpage
[23:28] <infinity> stgraber: I'm not sure if I should be entertained or a bit annoyed that Debian took your patch wholesale without refactoring it. :P
[23:29] <infinity> stgraber: Anyhow, whatever.  It DTRT on both dangling and not, I'll just add my own kludge on top.
[23:29] <slangasek> infinity: oh, it embeds the CD .info, right; in that case, how is the apt repo set up?  casper?
[23:29] <slangasek> apt sources.list I mean
[23:29] <infinity> slangasek: On the installed system, or the livecd?
[23:29] <slangasek> livecd
[23:29] <stgraber> infinity: hehe, the biggest issue is that we changed resolvconf's behaviour twice since that patch was merged in Debian ;) at some point we were back to a regular file until first boot, then went with relative symlink
[23:30] <slangasek> because the livefs itself can't know the CD's .info ahead of time
[23:30] <bdmurray> infinity: no it didn't like it.  there are 2 lines in sources.list with cdrom in them and it liked 'dists/precise/main/' and did not like 'precise main restricted'
[23:30] <stgraber> infinity: AFAIK Debian's resolvocnf still uses the absolute symlink, so I guess the check for the dangling symlink still makes sense for them :)
[23:30] <infinity> slangasek: May well be some casper hackery there.
[23:30] <bkerensa> stgraber: Is there anyway to make pastebinit prompt for a password for pastebin.com when sending to it?
[23:30] <bkerensa> :D
[23:31] <stgraber> bkerensa: no, authentication on pastebin.com doesn't work, the only pastebin supporting authentication in pastebinit is the KDE pastebin
[23:31] <infinity> stgraber: Oh, I'm not even complaining about the dangling bit (it's a useful test), I'm whining a bit that it now has the "mv foo foo.orig" call twice.  I would have refactored it. ;)
[23:32] <broder> slangasek, infinity: /usr/share/initramfs-tools/scripts/casper-bottom/41apt_cdrom
[23:32] <bkerensa> stgraber: Oh :( ok then might as well leave it to paste.ubuntu.com  thanks for your time
[23:32] <stgraber> bkerensa: pastebin.com's authentication would require a lot of scrapping or for it to be exposed on their API (which pastebinit doesn't support yet)
[23:32] <broder> "chroot /root apt-cdrom -o Acquire::cdrom::mount=/cdrom -o Dir::Media::MountPath=/cdrom -o Acquire::cdrom::AutoDetect=false -m add"
[23:32] <slangasek> righty-o
[23:32] <stgraber> bkerensa: I'm expecting authentication to be much better supported once I get around to rewritting pastebinit entirely and having some XML/JSON RPC support in the core...
[23:35] <bkerensa> :D
[23:36] <stgraber> infinity: yeah, I guess the diff would have been a bit more confusing if I did that, though the Debian maintainer indeed could have done it ;) I'm guessing it'd be just as long though as you'd need to move the Truncate call into an if statement so it only applies to the non-dangling case (or, really, test -f)
[23:36] <bkerensa> stgraber: It is still a nice script :)
[23:36] <infinity> stgraber: Yeahp, just being anal about organisation, I guess.  Runtime wouldn't change at all.
[23:37] <stgraber> bkerensa: yep, it does the job and did for a while now, so I'm a bit scared of the rewrite as it's indeed needed (looking at the feature requests I'm getting recently) but has a pretty high potential for breakage
[23:37] <stgraber> unless we leave in that perfect world where people don't change their APIs
[23:38] <stgraber> though so far for pastebins, I've noticed screen scrapping and filling web forms seems to be a lot more reliable than using their "well defined" APIs ;)
[23:38] <infinity> stgraber: Look sane? http://lucifer.0c3.net/~adconrad/live-build.diff
[23:38]  * infinity notes that needs another linefeed to match the live-build coding style.
[23:40] <infinity> Some day, I'll stop editing diffs by hand.
[23:40] <stgraber> infinity: yep, that should do the trick. Might be worth running a grep -r of the DC DNS server in the resulting live image just to make sure we didn't miss anything ;)
[23:40] <stgraber> infinity: use quilt :P
[23:40] <infinity> stgraber: Hand-editing is faster.
[23:40] <infinity> If you speak fluent diff...
[23:41] <stgraber> yeah, I end up doing the same quite often, then fight with quilt telling me the patches were already applied and now obviously don't match ;)
[23:42] <infinity> Oh, I just patch -R, edit the patch, and re-apply.
[23:43]  * infinity double-checks an image to make sure there's no more DC DNS leakage.