[00:01] works for me too 11.10 [00:01] it doesn't seem true for /proc/1/cmdline here though (not null terminated) [00:03] 1 is rather special... [00:03] on Debian, it's very null-terminated :P http://paste.ubuntu.com/830783/ [00:04] ;) [00:16] http://paste.ubuntu.com/830791/ [00:16] from man proc: The command-line arguments appear in this file as a set of strings separated by null bytes ('\0') [00:17] Is there a better forum for this question? [00:17] I'm new to working with the procfs, for sure. [00:21] It is supposed to contain nulls, not just end with them? [00:29] I assume that's the result of chrome modifying argv itself for cosmetic reasons, and not null-terminating, but that's a whild guess [00:47] cargo23_: http://paste.ubuntu.com/830815/ is an example of how to mess with cmdline taken from rdesktop's code, this specific example only overwrites the value passed after -p but you can certainly mess with the whole cmdline if you want [00:48] oh, ignore that printf, was there for debugging purpose ;) === dendrobates is now known as dendro-afk [03:56] the lpupdate was [04:58] Good morning [05:39] doko: well, this is why MIR bugs are supposed to be left open until an archive admin reconciles it against component-mismatches :) === kees_ is now known as kees === yofel_ is now known as yofel === warp11 is now known as warp10 [07:53] good morning === smb` is now known as smb === agateau_ is now known as agateau [08:31] hallo devs! are there any way to have this patch included with precises xserver? https://bugs.freedesktop.org/show_bug.cgi?id=41115 [08:31] Freedesktop bug 41115 in Server/General "Please add option to avoid forcing of 96dpi" [Enhancement,New: ] [08:56] fishor: Maybe. Can you please file a launchpad bug to track that? [08:57] RAOF, there is one long standing bug report here: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/589485 [08:57] Ubuntu bug 589485 in xorg-server (Ubuntu) "Ignores physical display size and calculates based on 96DPI" [Low,Confirmed] [08:57] Oh, yeah. That's right. [08:57] Sorry. [08:58] no problem. i can thest the patch with precise xorg, but i wont te be sure it will be added to the package [08:59] i never had problems with my old lcd screen, but with new laptop it is really bad [08:59] What's actually looking at that DPI value, anyway? [08:59] (IIRC both GNOME and KDE ignore it, as does Firefox) [09:01] RAOF, it is probably just part of the problem. i just started to digg in issue. first i found is xorg and xdpyinfo show different sizes. [09:02] You can make GNOME use the right DPI in gnome-tweak-tool (fonts). [09:03] As you go up the stack, you'll continue to hit the same reasons that Xorg has - physical DPI isn't actually the number that you're after; you actually want a number based on physical DPI and the distance you are from the screen. [09:04] how about other issue. for example libreoffice show page in 100% size double as small as it should be [09:05] If libreoffice wants to show at the correct size it should be getting the per-output numbers (which are, and have always been, correct and available through xrandr). [09:06] Because otherwise it'll break in not-too-uncommon circumstances anyway, like having two monitors. [09:06] * RAOF - [09:06] * RAOF → dinner [09:07] yea... i have two monitores .. the external has physical dpi ~96, the internal is about 138dpi [09:07] i should probably give this laptop to some dev who argumenting against it :) he should burn his eyes [09:13] jibel: thanks for the apt verification in lucid! I'm not quite sure whether that tested the release-upgrader-apt "special" package or the general apt [09:19] pitti: jenkins tests the release-upgrader-* packages, effectively [09:20] cjwatson: thanks, what I thought; for apt itself we'd need to check apt-get dist-upgrade supposedly? [09:20] cjwatson: I'm fine with moving r-u-apt to -updates now, unless you want to wait for the full 7 days [09:25] yes, and makes sense [09:25] jibel: nice to see that the post-upgrade conf tests all succeed nwo [09:25] now [09:25] blueyed, Happy Birthday! :) [09:56] Riddell, ScottK, debfx: okular was removed in Debian, "superseeded by kdegraphics/experimental"; should we follow suit? [09:57] umm no [09:57] tsdgeos: ^^ eh? [09:57] lol [09:57] kdegraphics/experimental? [09:57] * pitti keeps gwenview as well, got repackaged in Debian [09:57] what's that? [09:58] we don't even have a proper kdegraphics package anymore [09:58] pitti: got a bug number or other reference? [09:59] debian bug 515827 [09:59] Debian bug 515827 in ftp.debian.org "RM: okular -- RoM; superseeded by kdegraphics/experimental" [Normal,Open] http://bugs.debian.org/515827 [09:59] I figure we just have a different packaging [09:59] it's nothing urgent at all, it just came up in process-removals [09:59] 2009 ? [09:59] pitti: "Date: Tue, 17 Feb 2009 21:22:59 +0100" [10:00] it will have reappeared in process-removals because "okular" source package reappeared [10:00] blacklist it from process-removals [10:00] I'll just ignore it then, together with the other KDEish packages [10:00] seems it's all right then [10:03] pitti, the conf test is still failing for desktop but hidden. Currently the upgrade testing system doesn't have the granularity to run a test with different settings depending on the profile. [10:03] but I'll find a way to fix that [10:04] jibel: oh? I looked at the lucid->precise desktop upgrade log, and they all succeeded [10:05] pitti, they do but this prompt https://jenkins.qa.ubuntu.com/job/precise-upgrade-lucid-desktop/ARCH=amd64,LTS=lts,PROFILE=ubuntu,label=upgrade-test/18/artifact/lts-ubuntu-amd64/debconf.log shouldn't be there [10:06] jibel: aah [10:06] jibel: so it's not the lts-{user,system}.py stuff that's failing, but a debconf question [10:06] pitti, right [10:07] what is the expected behavior of the upgrader when a package is upgraded from lucid/main to precise/universe ? keep at the same version, upgrade, something else ? [10:07] mvo, ^ [10:09] mvo: if you have universe enabled, upgrade [10:09] if not, the package will behave as it disappeared entirely, so it shuold be kept [10:09] but usually we should keep the transitional packages in main [10:09] we often don't [10:09] we need to seed them explicitly, otherwise they fall out [10:09] I guess we'd need an upgrade test with not enabling universe in lucid, and then dist-upgrading [10:11] TREllis: \o/ thanks for replying to the ESR thread :) [10:13] now how do I force-enable enigmail.. [10:13] tjaalton: no problem, not sure if there is an issue shipping it in universe [10:14] tjaalton: 12.04 thunderbird update knocked out your plugins? [10:14] TREllis: yep, enigmail, lightning and mail redirect [10:15] tjaalton: same story for me :) [10:25] TREllis: "disable compatibility check" addon [10:26] tjaalton: ah-ha! [10:26] I saw that enigmail should work with 11 just fine === sgnb`` is now known as sgnb [10:39] infinity: ping? [10:40] infinity: https://launchpadlibrarian.net/90605123/buildlog_ubuntu-precise-amd64.libreoffice_1%3A3.5.0~rc1-0ubuntu1~ppa2_FAILEDTOBUILD.txt.gz <- I need more discspace on PPA builders for LibreOffice, please. [10:41] TREllis: meh, doesn't seem to work [10:41] enigmail 1.3.5 that is [10:45] tjaalton: yeah fails for me too on lightning, I can probably grab the latest builds manually, but slightly annoying [10:48] TREllis: trying enigmail nightly, something weird with that also [10:48] doesn't find /usr/bin/gpg for starters [10:50] and lightning fails too yes [10:50] was nice using them for a week or two :) [10:53] oh nice, I have tbird 10 packages on the hd [10:53] * tjaalton downgrades === rickspencer3_ is now known as rickspencer3 [11:15] slangasek: openssl098 was removed in Debian, and I guess for LTS we want the same; the only rdepends is ia32-libs-multiarch, I figure we can drop it there? [11:16] pitti: hmm [11:17] pitti: I thought it would be a good idea to keep it as it's a common thing found in linkage of third-party binaries [11:17] seems like a likely audience for ia32-libs too ... [11:18] it's in universe, so by the letter we aren't committed to security support [11:18] but in practice I guess we'll have to anyway [11:18] if programs are actually using it still [11:18] I don't know that for sure, but given the sheer number of things we had to port to 1.0.0 in Debian/Ubuntu proper, I'd be surprised if there were none outside [11:19] http://people.canonical.com/~ubuntu-archive/transitions/openssl.html [11:23] dholbach, hi! [11:23] hi diwic [11:24] dholbach, the wiki page https://help.ubuntu.com/community/SoundTroubleshootingProcedure is completely crazy and you're more likely to destroy your sound stack than to fix it if you use the instructions. [11:24] dholbach, yet someone seems to maintain it [11:24] dholbach, what is the suggested course of action? [11:24] diwic, it might be worth talking to the folks in #ubuntu-doc [11:25] AFAIK they take care of help.u.c [11:26] dholbach, hmm, I'll try asking the same question there [11:27] pitti, I think dist-upgrader in Precise must be updated to the right version of libapt-inst and libapt-pkg in Lucid [11:28] mvo: ^ ? [11:28] jibel: hmm? [11:29] when I run a do-release-upgrade in lucid I get [11:29] ImportError: libapt-pkg.so.4.12: cannot open shared object file: No such file or directory [11:29] uh, I don't [11:29] isn't that what we just promoted to lucid-updates? [11:30] unless you mean [11:30] DistUpgrade/DistUpgrade.cfg.lucid:Packages=libapt-pkg4.11,libapt-inst1.3,release-upgrader-python-apt [11:30] I don't know how much difference that makes since release-upgrader-python-apt should pull in the right versions by dependencies anyway [11:31] hm, it does make a difference for the CD though, at least - I'll update that [11:33] maybe that's just a matter of waiting. I'll retry in a bit. [11:35] jibel: hello, it should pick out the latest version of the release-upgrader-backport packages, but I missed some context so I'm not sure if that is a reasonable answer [11:37] jibel: I will read scrollback, on my way to lunch [11:47] tjaalton: hmmm yeah, after a fresh restart the plugins would start but issues all over the place with them... so leaving disabled for now === Quintasan_ is now known as Quintasan [11:49] TREllis: you can grab the old one here https://launchpad.net/ubuntu/+source/thunderbird/10.0+build1-0ubuntu1 [11:50] tjaalton: ty [11:56] tjaalton: yep, that worked like a charm. I wish we could link the thunderbird builds to the xul plugins :) [12:03] jibel: well, I've uploaded a new u-m now which will hopefully help [12:17] Sweetshark: Not my area anymore, you want lamont. [12:19] lamont: https://launchpadlibrarian.net/90605123/buildlog_ubuntu-precise-amd64.libreoffice_1%3A3.5.0~rc1-0ubuntu1~ppa2_FAILEDTOBUILD.txt.gz <- I need more discspace on PPA builders for LibreOffice, please. [12:21] Sweetshark, whats the ppa ? [12:22] gnuoy: https://launchpad.net/~libreoffice/+archive/ppa [12:23] Sweetshark, how much additional space are you after? [12:24] gnuoy: dunno :( -- enough to build LO. [12:24] 3TB ? [12:24] :) [12:25] gnuoy: it is failing rather late, so it shouldnt be too much additional space. [12:25] wow, 26 GB aren't enough to build LO? [12:26] * ogra_ hopes geser gets that he wasnt serious :) [12:26] you need 3TB RAM though :P [12:27] now I know why disk space steadily increases and cpus get faster: to keep be able to build LO [12:27] Sweetshark, I've increased the limit from 10Gb to 15Gb [12:28] gnuoy: I doubt he meant the PPA space but the buildd disk space used by PPA builders [12:29] most likely (if lamont is involved) [12:29] but that would probably still be needed soon [12:29] geser, ah, ok [12:29] jibel: oh, its a new ABI - in this case this needs updating, but I saw that colin did it already (thanks for that) [12:30] gnuoy: from the build log: "Build needed 09:28:17, 25995940k disk space" and it died with "IO error: write error during copy : No space left on device" [12:32] gnuoy: Yeah, this one requires the actual PPA Xen images being rebootstrapped. It might actually be a Spads thing, not a lamont thing, but I've lost track of who does what since I left IS. [12:32] (Well, it's possible one could fudge it by just expanding the image on a few machines) [12:32] infinity, ok, let me find out [12:32] increasing that disk space is going to be somewhat problematic, I suspect. When the kernel smacked into it a while back, they taught their build to remove intermediate copies of things [12:33] lamont: Do we actually still have PPAs with disks that small? Seems unlikely. I imagine the airlock could just have the limit bumped. [12:33] 72GB drive yields about 26GB of usable space for the ppa builder [12:33] And we still have some 72G ones? Fair enough. [12:33] many [12:33] Shame. [12:34] Oh, wait. But the airlock didn't use set sizes, did it, it did percentages? [12:34] So, one could manually throw LibO at a machine with more disk. [12:34] Pain in the butt, but doable. [12:34] * lamont notes that allspice, one of the newest in the fleet, has a 72GB drive === MacSlow is now known as MacSlow|lunch [12:53] mvo: have you had any further thoughts on https://lists.ubuntu.com/archives/ubuntu-devel/2012-February/034694.html ? Would you like me to try to construct a non-ABI-breaking backport? (Not sure I know how immediately, but ...) [12:58] pitti, hi, can you or other archive admin copy linux-meta 2.6.35.32.42 and linux-backports-modules-3.0.0 3.0.0-16.9 from ckt-ppa to -proposed? We detected 2 bugs which we would like to address in current SRU cycle. [13:01] gnuoy: thx, retriggering the builds [13:05] cjwatson: sorry, on the phone right now [13:08] cjohnston, u-m update fixed the problem. thanks [13:12] jibel: excellent [13:21] jibel: the ordering bug from last week? [13:22] cjwatson: I will attack that right after the call [13:32] herton: done [13:34] pitti, thanks [13:40] mvo: great, thanks [13:54] jibel: hm, I can't find a bug report for the qdbus <-> libqt4-dbus cyclic dependency; does that ring a bell for you (i. e. I'm too dense to search), or shall I report it? [13:54] jibel: (lucid->precise universe upgrade failure) === Guest81619 is now known as Zic [14:03] pitti, I didn't file a bug for this issue and haven't found one on LP [14:04] jibel: thanks; doing now [14:05] pitti, lucid -> precise main is interesting, the test passes but actually the system is not really upgraded [14:05] pitti, most packages are removed or kept at the same version [14:05] https://jenkins.qa.ubuntu.com/job/precise-upgrade-lucid-main/ARCH=amd64,LTS=lts,PROFILE=main-all,label=upgrade-test/13/artifact/lts-main-all-amd64/main.log [14:10] jibel: eww -- that might be an apt regression? [14:10] mvo: ^ did you ever see this? === MacSlow|lunch is now known as MacSlow === Tonio__ is now known as Tonio_ [14:15] cjwatson: is http://people.canonical.com/~cjwatson/ubuntu-policy/policy.html/ still the most up to date version of the ubuntu policy manual? === jdstrand_ is now known as jdstrand [14:16] cjwatson: hello btw :) [14:23] Riddell, debfx: are you ok with me doing an upload for bug 927637? [14:23] Launchpad bug 927637 in qt4-x11 (Ubuntu Precise) "upgrade failure: qdbus and libqt4-dbus cyclic dependency" [High,Triaged] https://launchpad.net/bugs/927637 [14:23] i. e. dropping libqt4-dbus' Depends: qdbus === bladernr_afk is now known as bladernr_ [14:24] ... turning it into a recommends, I mean === dduffey_afk is now known as dduffey [14:26] jibel: FYI, filed as bug 927637 (if you want to apply some extra magic tags) [14:27] Launchpad bug 927637 in qt4-x11 (Ubuntu Precise) "upgrade failure: qdbus and libqt4-dbus cyclic dependency" [High,Fix committed] https://launchpad.net/bugs/927637 [14:27] pitti: hang on [14:27] pitti: I have another change, can you commit somewhere and I'll do the other bit? [14:27] Riddell: sure; I pushed it into the packaging branch [14:28] pitti: ta, I'll get onto it in a bit [14:28] Riddell: it's certainly not _that_ urgent, but would be good if we can get this in in the next days to get to the next failure :) [14:28] Riddell: ok, cheers! [14:28] Riddell: nice that the branch ownership is set so that core-devs can commit [14:42] jdstrand: yes, it needs me to get round to merging from debian-policy really [14:43] cjwatson: ok. I noticed that 5.6.21 was different which prompted me to check [14:46] jibel: hm, are you sure? It spends 40 minutes (between 20:14:33 and 20:54:44) apparently at least trying to upgrade a lot of stuff, although I agree that there's no hint of it in apt-term.log [14:47] jibel: but I wonder if this is just a logging bug ... [14:48] jibel: it's a shame we don't save dpkg.log [14:50] I have something I want to express in my packaging that I'm not sure how to do: This module isn't required, but if it is installed I need it to be a version greater than X. [14:50] Is there a way to do that? [14:51] tedg: Breaks: packagename (<< X) [14:52] cjwatson, main.log says packages are upgraded but apt-term only show removals. and after the upgrade the new kernel is not installed. [14:52] cjwatson, I'll add dpkg.log [14:52] cjwatson, Ah, okay. I thought that meant "I break them" but that can also mean "I break if" ... cool, thanks! [14:52] jibel: mm, the kernel might be a special case, I wonder about something simple listed in the toupgrade list [14:54] tedg: well, that's the prose description in policy, but the formal semantics are "may not be unpacked while package (<< X) is configured" [14:55] cjwatson, Thanks again, that makes it much more clear. [15:09] pitti, jibel: yet another call, but I have a look now at the upgrade log [15:14] cjwatson: hi [15:14] jibel, pitti: the apt resolver log for this is 245mb big, that is in itself pretty scary [15:45] bug 915253 [15:45] Launchpad bug 915253 in Unity Greeter "Synchronise mute and volume between lightdm and respective user sessions" [Medium,Triaged] https://launchpad.net/bugs/915253 [16:00] cjwatson: I put a first stab of the backport work to lp:~mvo/apt/oneiric-dpkgpm-backport === bfox_afk is now known as bfox [16:05] cjwatson: I will need to carefully go over that, but I think its good, it does not include your algorithm.cc fixes yet, but that should be straightforward [16:06] I put the algorithm.cc fixes in oneiric-proposed already [16:10] awsome, thanks a bunch [16:27] pitti: no, openssl098 is here specifically *for* ia32-libs-multiarch [16:27] slangasek: ack; cjwatson already explained [16:27] ok :) [16:27] slangasek: I was a little worried of it being a security burden, but seems we need to keep it [16:27] *shrug* universe [16:43] pitti, do you know why bug 882030 is in the list of pending SRUs? this is a security update. [16:43] Launchpad bug 882030 in python-httplib2 (Ubuntu Oneiric) "python-httplib2 < 0.7.0 doesn't validate server certificates" [High,Confirmed] https://launchpad.net/bugs/882030 === beuno is now known as beuno-lunch === beuno-lunch is now known as beuno [16:44] jibel: I can answer that-- it is a security update, but mdeslaur wanted wider testing [16:44] we do that from time to time [16:45] pitti: around still ? [16:46] lifeless: yes, for another 10 mins [16:46] pitti: cool. Is there a separate library for backtrace/core signature generation? If not, how would you feel about having one? I want to make a clean interface for generating signatures, for reuse/plugability. [16:47] lifeless: it's in python-apport; does it need to be "more" separate? [16:47] pitti: with a medium term goal of being able to have a webservice that takes an oops dict | apport dict and returns a signature [16:47] it doesn't do anything by itself, so it should be quite harmless to install [16:48] pitti: yeah, it needs to be abstract - I don't want to be changing python-apport to change the logic for signature generation in launchpad, or SSO, or <...> [16:48] and it has the full API [16:48] I'll have a refresher look at the python-apport code [16:52] jibel, jdstrand, pitti: sorry, I'll update the bug to make it clear it's not an SRU === kalosaurusrex is now known as albrigha [16:55] jdstrand, mdeslaur , ta [17:03] Wow.. RPM still doesn't have Requires: x | y [17:07] SpamapS: and you are surprised ? :P [17:08] ev: hey there [17:08] lifeless: hiya! [17:08] ev: we should have another touch-base I think; I landed your patch, but I'm sure there is more :) [17:08] absolutely [17:08] when works for you? [17:09] is your google calendar reasonably accurate? I will poke at it.. [17:10] lifeless: reasonably so [17:15] lifeless: I keep a CentOS box around just to keep an eye on what the other people are doing.. [17:16] lifeless: I just finished packaging up byobu 5.7 for it as an exercise in curiosity. Can't say Requires: screen | tmux .. have to have a virtual provides on both of them. [17:16] amazing [17:23] SpamapS: curious, I thought byobu was in the CentOS repos? [17:23] SpamapS: just not a new enough version? [17:24] SpamapS: different mindset for solving the problems [17:25] tedg: lennart? [17:26] kirkland: yeah, its 4.something [17:26] kirkland: and it wasn't in my yum automatically with CentOS 6.2 [17:27] kirkland: its in Fedora for sure, but doesn't seem to have found its way into EPEL 6 [17:27] kirkland: I'll submit the 5.7 packaging updates I did to Fedora if I find some time next weekend. :) [17:28] kirkland: btw, Ctrl-A A doesn't send Ctrl-A in tmux mode in this one for some reason (works fine on the Ubuntu version) [17:33] * micahg wonders where doko is [17:34] micahg: lost on the way back from FOSDEM? [17:37] SpamapS: ah, interesting; okay, cool, thanks for the update [17:37] Sweetshark: could be [17:37] SpamapS: btw, I stumbled on your juju byobu-classroom multi branch [17:38] SpamapS: I didn't look closely at it, but what's the goal? [17:40] lifeless, Heh, no GSettings is my issue right now. But that's a good one too. [17:42] kirkland: infinite scalability for a single ajaxterm session :) [17:42] SpamapS: oh? yeah, I found ajaxterm kinda sucky, in reality :-( [17:42] SpamapS: is it working well? [17:42] kirkland: its just heavy on CPU because it has a high polling interval.. can't get around that on the web [17:42] kirkland: I had it working in PoC .. very simple really [17:43] SpamapS: neat [17:43] kirkland: just ssh's to the "main" node instead of locally [17:43] SpamapS: I used a cc2_8xlarge for my dev week session last week :-) [17:43] SpamapS: 32x cpus :-) [17:43] kirkland: yeah thats the simple choice. I want to see if we can do a big class on 8 m1.smalls [17:44] SpamapS: neat [17:44] kirkland: have to setup haproxy to do session persistence too.. but thats fairly easy [17:47] mvo: there? [17:48] SpamapS: neat, really glad to see you thinking about this === mpt_ is now known as mpt === mpt_ is now known as mpt [18:08] mvo: are you open to using dh_autoreconf in synaptic? [18:11] micahg: absolutely [18:11] micahg: let me quickly check if that isn't in trunk already [18:12] micahg: (lp:synaptic) [18:12] ok, because it FTBFS in precise [18:12] micahg: aha, ok. I will upload a new version to debian that we can sync than [18:12] mvo: ok, do you need a patch or do you have it already or not need it? [18:13] micahg: in trunk its using dh-autoreconf already, I did that last weekend [18:13] cool, thanks [18:14] micahg: thank you for raising it, slipped my attention :/ [18:21] pitti: What do you think about having the retracer not remove dependencies.txt? [18:28] micahg: I uploaded to experimental now that should hopefully fix the issue (once its there and be be synced) [18:28] mvo: be be synced? did you want me to do that? [18:29] micahg: well, I can do it too, no problem [18:29] ok, thanks, was just wondering if I need to do anything here :) [18:30] micahg: :) all good, I made a note to sync it when I get up tomorrow morning [18:30] mvo: thank you :) [18:36] seb128: Hi - did the automake distdir.test fail on the buildds without eCryptfs? [18:36] seb128: or does it only fail inside of eCryptfs mounts? [18:37] tyhicks: hi [18:37] tyhicks: the buildd fail on another test later on, I hit that one when trying to debug the issue locally [18:37] tyhicks: the same test works fine on the buildd on in a directory out of ecryptfs there [18:38] seb128: Ok, that's all I needed to know [18:38] seb128: I'm trying to get it triaged [18:38] seb128: thanks! [18:38] tyhicks: thank you for looking to the issue! [18:38] np === _salem` is now known as _salem === _salem is now known as salem_ === kalosaurusrex is now known as albrigha [19:14] stgraber: should ltsp-client migrate to using fonts-nanum instead of ttf-unfonts-core? [19:15] micahg: probably [19:15] want a bug? [19:15] or an upload :) [19:16] micahg: nope, added to my todo, I'm doing PPA builds of the new LTSP anyway, so will just include the change in there [19:16] thanks === pp7_ is now known as malkauns [19:32] slangasek: So, I was thinking I'd add a 'nowait' class to /etc/network/interfaces which is used to subtract interfaces from the ones waited on. Thoughts? [19:32] stgraber: ^^ you too [19:33] slangasek: there seem to be a number of users who are willing to RTFM and figure out how to do what used to be easy, which is, have interfaces brought up at boot time that are not waited for. [19:33] SpamapS: how is that different from the existing 'hotplug' class except in name? [19:33] oh there is already one like that? [19:33] yes [19:33] as for "what used to be easy" - it was only ever easy because of bugs, AFAICS [19:34] hotplug isn't mentioned in /etc/init/network-interface.conf or /etc/init/networking.conf ... [19:34] SpamapS: yes, but it's mentioned at the top of interfaces(5) as an example, and it's a class that Debian has historically implemented - if we need to reintroduce it, we should use the same name [19:35] slangasek: seems like a good idea.. though its kind of hard to resolve, logically, the difference between 'auto' and 'hotplug' in my head. [19:35] yes :) [19:36] y'know, I'd really like it if /etc/init/networking's ifup -a were going away this cycle [19:36] You could always alias nowait to hotplug, just to the lulz. :P [19:36] s/to the/for the/ [19:36] slangasek: we all would :) [19:37] infinity: how can you alias ifupdown "allow" classes? [19:37] slangasek: at this point, what network interface appears w/o a net-device-added event ? [19:37] slangasek: I meant in the code. As in, make them mean the same thing. [19:37] infinity: yuck :P [19:37] slangasek: ;) [19:38] SpamapS: well, if stgraber caught all the bugs, /etc/init/networking.conf is at best a redundant no-op now, and at worst tries to bring up interfaces before they're ready :) [19:38] stgraber: ^^ have you tried pulling /etc/init/networking.conf off your test systems to confirm that it's no longer needed? [19:39] slangasek: well, there are interfaces that will never be brought up by events [19:39] still? [19:39] tunnel interfaces, bridges with no physical interface in them, loopback device in containers, ... [19:39] ah [19:39] * slangasek shakes his fist [19:39] anything that's not linked to a physical device won't be brought up by the udev magic [19:39] yep [19:39] I'll note that I have several such interfaces on my machine. :P [19:39] which means, unfortunately, that /etc/init/networking.conf continues to risk bringing devices up out of order [19:39] Please no break. [19:40] slangasek: perhaps we should instrument this... if we have ifup -a log every interface that it thinks should be up, and have net-device-added events recorded.. we could have development-minded folks feed that data back to us and we'd get a picture of what is still missing net-device-added events [19:40] well, I hope I've added enough "please wait for a minute" code in the pre-up scripts to prevent much of the damage that ifup -a would cause but yeah, it's still a risk [19:40] SpamapS: Some devices just plain can't ever have those events. [19:41] Couldn't we, in theory, fire net-device-added events for soft-controlled interfaces? [19:41] why would we do that? [19:41] that's unnecessary indirection [19:41] SpamapS: Chicken and egg, surely, since you want that event to bring up an if... [19:41] Probably [19:41] synthesizing an event for your configured soft interfaces just so you can bring up those interfaces [19:42] We could extend interfaces(5) to allow defining triggering events. [19:42] (ie: bring up tun0 if eth0 up) [19:42] so perhaps what would be better would be an enhancement to ifup to only bring up software interfaces .. ifup -a --soft-only [19:42] I would like it if networking.conf were explicitly *only* used for known soft interfaces... but that again would require another class [19:42] and would then require admins to migrate to its use [19:42] so this just dropped several notches on my priority list [19:43] slangasek: unless ifupdown could detect whether or not an interface is hardware or software... much like mountall decides whether or not a filesystem is local or remote [19:43] it can't and shouldn't [19:44] making ifupdown introspect bridge devices to decide whether they have physical interfaces or not would just be wrong [19:45] * SpamapS ponders [19:49] * infinity curses at rhythmbox-ubuntuone's uninstallability. [19:52] hmm, that should've have been allowed in the archive yet without gir1.2-ubuntuont-3.0, I wonder who let that in :P [19:52] s/should've/shouldn've/ [19:52] gah, can't type today [19:53] in any event, dobey should fix ^^ [19:53] micahg: I think it's just a typo/thinko? [19:54] micahg: The gir package was renamed to ubuntuoneui to match the library. [19:54] yeah [19:54] looks like it [19:54] I have a question about dpkg. I am looking for a way to share a list of executable files between rules/postinst/prerm. [19:56] doh [19:56] micahg, infinity: is there a bug # filed? [19:56] dobey: I just noticed it right now while doing livefs builds, so no. [19:57] * SpamapS wonders if he has somehow failed his Plus1 maintenance duties by not noticing this earlier [19:57] SpamapS: Yes. :P [19:57] infinity: ok [19:57] SpamapS: It's been broken for days, I assume. [19:57] I was searching for the list of tasks this morning.. and got distracted. :p [19:57] nah, was just uploaded [19:57] SpamapS: (At least, based on when these uploads were made) [19:57] Yeah since Friday [19:57] oh, changelog says Friday [19:57] Build logs say Friday too. [19:57] pitti approved it today [19:57] accepted 3 hours ago :) [19:57] The libubuntuone change, that is. [19:58] oh, yeah, that was last week :) [19:58] I guess it's rhtyhmbox-ubuntuone that's broken, though,. [19:58] So, okay. 3 hours. [19:58] Grr. [19:58] yes; anyway, i'm fixing it right now [19:58] I missed my window for a hassle-free live build. ;) [19:58] just wanted to make sure if there was a bug # i need to put in changelog [19:59] http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html [19:59] Listed indeed.. :-P [20:00] * micahg wanted to discuss the icedtea-web one with doko [20:02] hm [20:02] its working fine for me [20:03] I can install icedtea-6-plugin .. it removes icedtea-plugin as I'd expect it to [20:03]