[00:00] merry christmas, bye [00:02] running 8.10 now spash screen comes up.. bar moves see a bunch of test on starting then screen goes blank. and i hear the drums [00:04] *text === dendrobates is now known as dendro-afk [00:38] I want to file a bug against the gnome shutdown thingy (the countdown timer or something), which package is that? [00:39] It's a feature suggestion, I think that if someone clicks on shutdown on the session indicator and then closes the lid of the laptop the system should shutdown, not (insert closing lid action) [00:39] Now that I think about it I'm guessing it's the session indicator... [00:40] funkyHat - yes, that's the session indicator, but it's more complicated than that [00:40] the session indicator has no way of knowing if your lid is closed [00:40] Yes I imagined that would be the case [00:40] I still think it's a valid bug though [00:41] yes, but i don't know which package it should go against [00:41] the changes required in the session indicator to do that would be non-trivial [00:41] Do you know which package the session indicator is in? [00:41] indicator-session? [00:41] that would be my guess :) [00:41] Ah, thanks :) [00:42] I suppose it could inhibit gdm and poll for a laptop lid status somehow [00:42] I don't know the ins and outs of it but it doesn't seem that complex. Unless inhibiting only applies to shutting down, not suspending [00:43] inhibiting and checking the status of the lid button are 2 completely different concepts though [00:43] and gdm has nothing to do with laptop lids either [00:43] thats gnome-power-manager [00:44] That's what I meant :) [00:44] I don't see why inhibiting and checking lid status need to be related concepts [00:44] they're not, but i got the impression that you thought they were [00:45] I'm a bit perplexed why I received the e-mail for the sync request and an immediately subsequent rejection [00:45] Ah, no I just figured those were the two things that would need to be done to achieve this [00:45] anyway, it should be opened against indicator-session for now. indicator-session would need to get the lid button info from dk-power [00:45] [ubuntu/lucid] haskell-src-exts 1.3.0-1 (Accepted) ... haskell-src-exts_1.3.0-1_source.changes rejected [00:46] Oh here it's already filed. bug 462318 [00:46] Launchpad bug 462318 in indicator-session "New action when pressing "Shutdown" and closing the laptop screen " [Wishlist,Confirmed] https://launchpad.net/bugs/462318 [00:49] Thanks chrisccoulson [00:52] crimsun: 21/12 23:06:33 the flush seemed to reject all the packages, I'm not sure why [00:52] don't know where that leaves such packages [00:52] Laney: thanks [00:53] on the ftpmaster [00:53] didn't you get an accept as well? [00:53] oh, yeah [00:53] it seems like it tried to accept twice [00:53] crimsun: heading towards new xmonad? [00:53] Laney: would be nice but is fairly low on my priority list; feel free [00:53] siretart` - i have gnome-screensaver inhibiting working with VLC again \o/ [00:54] good stuff. I wrote some UDD queries to get the state of the union earlier [00:55] good god, I haven't uploaded anything in almost a month [00:56] bad me [01:02] Laney - yes, bad you - you must be slacking :P [02:01] hmm, looks like latest initramfs-tools and that mountall upload broke a lot of things (as in, not being able to debootstrap ;)). initramfs-tools conflicts with current mountall and the new mountall is stuck in depwait due to libplymouth-dev being in universe [02:02] I guess I'll have to wait till tomorrow to get my LTSP server working ;) [02:05] * slangasek promotes plymouth to main [02:06] oh, ok, that'll will the issue of course ;) [02:15] hey guys [02:16] having a issue with apache2 pkg on 9.10 [02:16] it installed a blank httpd.conf === asac_ is now known as asac [02:36] UnixDawg: that's expected behavior; please see #ubuntu for support === dendro-afk is now known as dendrobates === nhandler is now known as Guest15323 === micahg1 is now known as micahg === dous__ is now known as dous === micahg1 is now known as micahg [06:42] * StevenK blinks at how the base system is no longer debootstrapable [06:42] I believe that should be fixed with the latest mountall build [06:42] scream if it's not [06:42] (mountall 2.0) [06:44] My debootstrap a little while ago was still pulling down 1.1 [07:06] Hmm, not sure if my question went through before the disconnection, so... [07:06] Is the 3.0 quilt format enabled in Ubuntu yet? [07:07] LucidFox, yes. Since a couple of days [07:08] Whee! [07:08] Time to migrate my packages. [07:14] what are the changes required to make a package use the 3.0 quilt format? [07:18] hyperair, http://wiki.debian.org/Projects/DebSrc3.0 [07:49] good morning [07:53] hey dholbach! [07:54] hey mvo [08:12] Wmm, what about orig.tar.bz2? Is it supported now? [08:14] part and parcel of v3, yes [08:15] Good morning [08:15] ScottK: rescore> sorry, was off for the night; still need any rescoring? [08:15] yay 3.0 source support \o/ [08:43] has anyone succeeded in using git-buildpackage with pristine-tar and multiple orig tarballs? [08:48] part and parcel of v3, yes [08:48] And lzma? It's disabled in Debian, as I read, but what about Ubuntu? [09:12] pitti: could you bump build score on https://launchpad.net/ubuntu/+source/eucalyptus/1.6.2~bzr1103-0ubuntu4/+build/1410724 so that it has a chance to make it on the daily CD run ? [09:13] ttx: done [09:13] anyone knows why the amd64 builders are so crowded ? [09:13] pitti: thx! [09:13] ttx: i blame Freemasonry [09:13] pitti: yesterday the build started around 10:30pm CET [09:13] mneptok: that always works. [09:14] mneptok: that's Openmasonry to you [09:15] * mneptok gives slangasek the secret handshake [09:35] slangasek: Okay, verified that mountall 2.0 fixes the base system, thanks. [09:36] Could an archive admin retry this build? https://edge.launchpad.net/ubuntu/+source/qt4-x11/4:4.6.0-1ubuntu5/+build/1407295 [09:36] I wonder why ld of all things segfaulted, though. [09:37] LucidFox: You don't need to be an archive admin, just a core-dev [09:37] Ah. [09:40] and that build shouldn't be retried [09:40] Yeah, I didn't think so either, reading the log [09:40] it's a known problem; someone who speaks qmake needs to figure out how to disable -Wl,--gc-sections on powerpc [09:41] slangasek: Wow, --gc-sections causes ld to SEGV on ppc? [09:41] StevenK: bug #498631 [09:41] Launchpad bug 498631 in binutils "ld segfaults with --gc-sections on powerpc" [Undecided,New] https://launchpad.net/bugs/498631 [09:42] slangasek: Ouch [09:43] Why does Qt try to build with -Wl,--gc-sections in the first place? [09:44] It's not standard qmake behavior, so upstream must have specifically enabled this. [09:45] LucidFox: It probably is because upstream told it to do so. === tkamppeter_ is now known as tkamppeter [09:48] * LucidFox apt-get sources [09:49] pull-lp-source [09:50] cjwatson: hi, any news on that glibc backport we talked about? [09:55] hi, dois the ubuntu archive support the 3.0 version of debian pkg with bz2 compression? [09:55] does* [10:01] bigon> Yes [10:01] Now it does [10:01] REVU doesn't support the 3.0 format, though. :/ [10:01] Well, it uploads, but can't unpack. [10:02] LucidFox: thx [10:34] ttx: thanks for this quick review [10:34] geser: no pb, it was a pleasure :) [10:35] anyone interested in sponsoring a perl merge (bug #496556)? (sorry, it can't be currently merged with bzr) [10:35] Launchpad bug 496556 in perl "Merge perl 5.10.1-8 from Debian testing" [Undecided,New] https://launchpad.net/bugs/496556 [11:00] pitti: 1.6.2~bzr1103-0ubuntu4 was published too late for the server ISO daily run to pick it up... i'll need a respin :/ [11:01] ttx: no problem, they are cheap to build [11:02] pitti: cool then. btw if it's also cheap to give me power to trigger respin, then I'd stop bothering the release team for that [11:04] is there an easy way to obtain x backtraces? here, x is crashing horribly because of xsplash, but no core is generated (Process 3029(Xorg) has RLIMIT_CORE set to 0)… [11:06] that requires an RT at least (you need a cdimage ssh accunt and some group permissions) [11:06] but it's not that much work, don't worry [11:06] yesterday's X should have enabled apport again [11:06] but the current kernel doesn't work with apport right now [11:06] due to bug 498525 [11:06] and I don't know a good way how to circumvent this [11:06] Launchpad bug 498525 in linux "[lucid] breaks apport: core dumps get aborted even if core_pattern is a pipe" [High,In progress] https://launchpad.net/bugs/498525 [11:07] pitti: it's not so much the work, it's more about the interrupt :) But OK, I'll keep bothering one of you guys :) [11:07] pitti: you already restarted it ? [11:08] ttx: ah, can do now (didn't interpret it as "please do now") [11:08] pitti: that's why I doublecheck :) [11:08] running [11:08] ETA 10 mins [11:08] pitti: thanks ! [11:18] ttx: done [11:18] pitti: ok [11:34] ttx: how functional is the latest eucalyptus? [11:34] ttx: is it worth testing it? === einalex_ is now known as einalex [12:16] hm, let's get this over with, then [12:16] which archive admins are about on his fine morn? [12:16] well, it's gone noon, but you get the idea [12:18] directhex: https://wiki.ubuntu.com/ArchiveAdministration#Archive%20days [12:19] jpds, i'm more soliciting opinion than asking for action to be taken, so i didn't really think the day's hat-wearer mattered much [12:25] mathiaz: good question. The current daily (20091222.1) should start alright, I've yet to try to run an instance, though :) [12:25] mathiaz: you should have a more precise answer in 30 minutes [12:27] * Laney sprays directhex with asbestos [12:31] ttx: I'm actually testing from packages, rather than from iso [12:32] Laney, mmm cancerous fibres! [12:32] mathiaz: ok [12:33] ttx: have you also noticed issues in trying to restart eucalyptus-cloud? [12:34] ttx: starting eucalyptus-cloud is already slow [12:34] ttx: restart eucalyptus-cloud doesn't always work [12:34] mathiaz: yes, sometimes a process is left around [12:34] mathiaz: I hit that a few times [12:45] Heh, http://www.kdedevelopers.org/node/2736 has a perfect metaphor for grumbles about autotools to cmake migration. [12:45] "Them new shiny tools you are using ain't looking like my trusty old sledgehammer!" [12:47] LucidFox: except the point of the blog is that sentence isn't true [12:48] I never claimed it was. I hate autohell. [12:49] I just don't like autotools adherents who are wary of cmake just because it's different. [12:49] it always amazes me that there are people who still use it [12:50] LucidFox, there's a reason for en.wikipedia.org/wiki/Autohell [12:52] Yesterday, I wrote a fully feature-equal cmake replacement for gtkpod's build system, and committed it to git master. While one of the other developers argued for it, the reaction of the other one was, "Is it really worth it? What does it do better except Windows builds, which I don't care about anyway?" [12:53] So I wrote a long email explaining it. Think I should reproduce it on Planet Ubuntu. === dktrkranz is now known as DktrKranz === NCommander is now known as bjf === bjf is now known as NCommander === xomas is now known as xomas_ === xomas_ is now known as xomas [14:18] slangasek: since you are the last one who has touched cryptsetup: I've did a testinstall with today's alternate install daily with encrypted lvm. I ended up with an bootable system, but /boot does not contain any kernels, but /boot/grub [14:18] slangasek: now I'm seriously confused what's going on here. how did that setup managed to work? and is this an installer or cryptsetup problem? [14:18] s/work/boot/ [14:20] slangasek: oh, mystery solved. /boot was not mounted, and the root filesystem contains /boot/grub that is shadowed by the /boot mount [14:21] still, not mounting /boot during startup seems pretty critical to me.. hmm. [14:22] Get:35 http://fi.archive.ubuntu.com lucid/universe nexuiz-textures 2.5.2-3 [521MB] [14:22] apt-sync would be nice right about here, especially since it’s just a packaging change. :-) [14:23] ion: I think you've just found the largest package in the archive :-) [14:24] hm. the missing /boot does not seem to be even deterministic. the 2nd boot went just fine... hmm [14:30] LucidFox: I very very very much doubt cmake gets all the cornercases right which autotools do get right [14:30] and quite frankly, replacing the build system of a project you don't own is IMO highly inappropriate [14:36] cjwatson, mdz, kees: [14:37] cjwatson, mdz, kees: will you be at the DMB? I'm afraid with the holiday season we won't have quorum today, so we might just skip this one [14:37] tseliot: are you here today? [14:37] pitti: sure, I'm here [14:37] (your core-dev app is the only topic anyway) [14:37] pitti, I have another meeting at the same time, but I think it is unlikely to make quorum, so I expect to be able to join DMB a bit late [14:37] oh [14:38] pitti, the other topic is the upcoming election, but I sent an email update to the list already [14:38] right, I noted that down as an "in progress" action point on https://wiki.ubuntu.com/DeveloperMembershipBoard/Agenda [14:39] mdz: hm, is quorum == or > (number_of_team_members/2) ? [14:39] IOW, do we need 3 or 4 people? [14:40] pitti, 3 is sufficient IMO [14:41] mdz: I'll just wait for you and kees then [14:46] why does network mangler hate my eth0? [14:47] pitti: If you get a quorum would you discuss the per-package uploader question please (for kubuntu-dev) [14:47] ScottK: please see my email response; I think it's already handled now, and in the unlikely event that some other DMB member objects, they can followup by mail [14:47] pitti: OK. Thanks. [14:48] ScottK: I updated the wiki page accordingly, so in the future we can just apply the privs for kubuntu-dev approved per-package uploaders [14:48] (it was really just a process inconsistency) [14:48] pitti: OK. Sounds good. === BenC1 is now known as BenC [14:52] pitti: maybe Keybuk can join the DMB meeting? [14:56] Keybuk: how can I reproduce the plymouth bug (other than on boot)? What shall I do after I kill gdm and X? [14:56] tseliot: you can just stop gdm, then start plymouth from tty1 [14:57] you'll note that Alt+F7 and Alt+F1 don't do what you'd expect [14:57] pitti: isn't hald supposed to go away in lucid? [14:57] though I debugged it with upstream late last night [14:57] and we worked out it [14:57] mathiaz: yes, mostly; it's currently not installed by default [14:57] Keybuk: what did you find out? [14:57] tseliot: plymouth uses /dev/tty0 rather than /dev/tty7 to do most of its setup [14:57] (KD_GRAPHICS, VT_PROCESS, etc.) [14:58] but doesn't wait for the VT switch [14:58] right, I noticed that [14:58] pitti: hm ok. The lucid UEC image has a bunch of hald-related processes around [14:58] no? [14:58] so it ends up in a screwy situation [14:58] pitti: http://paste.ubuntu.com/344753/ <- these are supposed to go away in lucid right? [14:58] mathiaz: maybe it was an upgrade from a very early lucid snapshot? [14:59] Keybuk: are you saying that it should use VT_WAITACTIVE instead? [14:59] Keybuk: Is it possible something in the new mountall breaks LTSP boot ? [14:59] tseliot: a lot of things need to change [14:59] pitti: I don't think so - they're generated daily with vmbuilder [14:59] to:-/ [14:59] tseliot: needs to use the terminal decide rather than the console device for the setup [14:59] mathiaz: is that a server or desktop install? [14:59] needs to wait for the vt to be active [14:59] the drm renderer needs to not default to is_active = TRUE :p [15:00] pitti: server. ha - it's required by landscape-client [15:00] mathiaz: right, I discussed that with the landscape guys at UDS [15:00] pitti: http://paste.ubuntu.com/344757/ [15:00] Keybuk: are you or upstream going to work on it? [15:00] it's not used for any automatic data collection right now, just to have it [15:00] mathiaz: so it can effortlessly be replaced by an udev dump and DMI data [15:01] tseliot: I think halflife is going to do it [15:01] halfline even [15:01] pitti: ok - so the landscape knows what needs to be done [15:01] Keybuk: yes, halflife is a game ;) [15:05] tseliot: http://bugs.freedesktop.org/show_bug.cgi?id=25749 [15:05] Freedesktop bug 25749 in plymouth general "plymouth doesn't work well when run from another vt" [Normal,New] [15:09] Keybuk: it's good to see that finally we know what's going on [15:12] tseliot: a quick fix would obviously be just to run plymouth and X on tty1 :p [15:13] oh, I'd love to kill that hackish gdm patch to run X on vt7 [15:14] pitti: we're actually not using it [15:14] well, sorry [15:14] we're using it if you don't have plymouth [15:14] which I guess is the default right now [15:14] but when you do have plymouth we're using a different patch [15:15] which starts X "on the current vt" [15:15] Keybuk: maybe we could use a spambot who can change the documentation regular expressiond and tell everyone not to to use ctrl+alt+f1 anymore to get to the command line :-P [15:15] expressions [15:17] Keybuk: and the current vt happens to be vt7 right? [15:17] tseliot: well, ish ;) [15:18] ok, let's not be too specific: tty0 [15:18] ;) [15:20] lol [15:26] Keybuk: for mountall weirdness debugging (as in LTSP), you still need: mountall --debug ? [15:28] yes [15:29] Keybuk: http://pastebin.com/f1aabfe37 [15:30] Keybuk: line 311 might be interesting btw [15:32] stgraber: don't suppose you can install the previous mountall on there and get me --debug output to compare? [15:33] How nice, the apt update broke aptitude. :-) [15:33] Keybuk: btw, I just started with mountall as --debug (but still in daemon and called by upstart), I now get that "Assertion failed" at the end and then "mountall main process (390) killed by ABRT signal" [15:33] and I'm stuck there [15:34] I'll get the old mountall from LP and install it, won't be long [15:39] cjwatson: about usb network adapters support in installer, again -- Apparently most hardware now uses the asix minimodule. The ones I bought for UEC testing are "0b95:1780 ASIX Electronics Corp. AX88178" and don't appear to be supported right now [15:39] cjwatson: do you think it's an option to also support the asix minimodule ? [15:40] ttx: I suspect cjwatson is deep into the early christmas cheer, and you'll have more luck next year :p [15:40] bah [15:40] Keybuk: thanks for the tip [15:40] :-) [15:40] Keybuk: http://pastebin.com/f7949c1a9 [15:41] that must be what they all call "holidays" [15:41] stgraber: great! *hauls our mentaldiff* [15:45] stgraber: oh, that's interesting [15:49] aptitude broke down, apt-get works: http://pastey.net/130533-1p4p [15:49] Keybuk: btw, I just had to revert initramfs-tools too as otherwise it'd still hang even with the older mountall === robbiew_ is now known as robbiew === dendrobates is now known as dendro-afk === kirkland` is now known as kirkland [16:16] tseliot, felicitazioni! [16:16] ara: grazie :-) [16:24] Riddell: if you accept approved SRUs, can you please use sru-accept.py from ubuntu-archive-tools? If you use the queuediff tool (also there), this will spit out the exact command line for this, too (package name, bug #s, etc.) [16:24] sru-accept.py takes care of the tags, subscriptions, and the call for testing with some useful links [16:25] pitti: can do, I don't think I knew about that, is it on ArchiveAdministration? [16:25] Riddell: no, it's not right now (it's not a general archive admin task) [16:31] persia: ping [16:31] * ScottK waves to LaserJock [16:31] hi ScottK [16:32] LaserJock: ? [16:32] pitti: I didn't know about queuediff giving you the sru-accept command. That's nice. [16:34] persia: just reading the DMB email, there was an item (I think yours) about naming for the specialist teams [16:34] persia: in the email it says also MOTU, but is MOTU considered a specialist team now? [16:34] LaserJock: Well, except that "specialist" and "MOTU" don't quite match for most sane semantic matrices. [16:35] So it was suggested to use "Ubuntu Developer (delegated teams)" to cover both cases. [16:35] Err, "Ubuntu Developer (from delegated team)". Oops. [16:37] stgraber: still about? [16:39] persia: why is the distinction needed? [16:39] just plain Ubuntu Developer doesn't work? [16:40] Because there are also other classes of "Ubuntu Developer", like "per-package uploader", "contributing developer", "prospective developer". [16:41] It doesn't actually mean much outside the context of the version of the page I'm drafting :) [16:41] * persia will try to pubish RSN, to reduce overall confusion [16:44] ok [16:44] I just wondered if MOTU was considered a specialist team [16:45] I certainly don't think that makes sense, which is part of why I asked the question. [16:45] since that seems like the opposite of my understanding of the meaning [16:45] Indeed :) [16:45] i see i'm very popular here [16:45] dmb: Overlap with "Developer Membership Board" [16:45] :P [16:47] i still think i'm quite popular :) === dholbach_ is now known as dholbach [16:48] * Keybuk remembers when we had someone on the channel called "spec" :) [17:03] pitti: before leaving, could you trigger a server ISO respin ? === dendro-afk is now known as dendrobates [17:04] or slangasek ^ [17:05] asac: is NM still expected to not-manage any interfaces that are configured in /etc/network/interfaces? [17:07] maco: yes [17:07] Keybuk, i was wondering how out-of-date is the merges.ubuntu.com/universe.html is? [17:07] maco: if you run it with managed=false that is [17:08] in /etc/NetworkManager/nm-system-settings.conf [17:08] asac: so its not *just* dependent upon the interfaces file, then? [17:09] maco: not sure what you mean [17:10] if you have an iface configured in interfaces ... and have NM in managed=false mode [17:10] then its not managed [17:10] asac: ok then i had it wrong :) [17:10] thanks [17:10] maco: managed=true is good :) [17:10] if it has bugs, file them ;) [17:10] and yes, odd stuff isnt supported yet. [17:11] nah, i thought i only had to change the interfaces file to change whether nm would let me ifup or not [17:11] RoAkSoAx: weeks [17:11] asac: well wstephenson says i should show you line 11 of http://paste.ubuntu.com/344828/ [17:12] RoAkSoAx: it's an evil plan to move everyone to bzr merge-package [17:12] asac: trying to figure out why knm thinks a connection that worked fine before is now an invalid connection [17:12] maco: how does interfaces look like (remove the password) [17:12] Keybuk, is it going to be updated anytime soon? [17:13] maco: Dec 20 16:52:40 betty NetworkManager: SCPluginIfupdown: management mode: unmanaged [17:13] so you hvae managed=false [17:13] RoAkSoAx: no [17:14] Keybuk, ok thanks :) bzr merge-package it is then :) [17:14] (MoM is having major issues with v3 format Debian source packages [17:14] particuarly those that use quilt [17:14] and nobody has any time to work on it) [17:15] asac: ok. ooooooo wait now i think i get what youre saying. if that is managed=true THEN "is it configured in /etc/network/interfaces?" becomes relevant, but if its false, then itll *always* manage the devices? [17:15] maco: almost correct ;) ... [17:15] if managed=false -> any iface mentioned in interfaces is blacklisted, e.g. not managed [17:16] ok thats not what its doing [17:16] if managed=true -> configuration is parsed from interfaces and used as a system connection [17:16] maco: i need to see the interfaces. [17:16] managed=false but its still managing wlan0 such that i cannot ifup until i stop network-manager [17:16] could be its choking because it has bad formatted parts or something [17:16] does it dislike comments? [17:17] maybe [17:17] could be a bug [17:17] Keybuk: are there any bugs filed? [17:17] highvoltage: how would that help? [17:17] maco: play around. it should support wpa-supplicant configs quite well ... [17:17] or paste your interfaces ;) [17:17] how about i email you my interfaces? :P [17:17] maco: i guess you dont have key-mgmt [17:18] ? [17:18] or do you have that? [17:18] i dont know what key-mgmt is, so im gonna guess no [17:18] heh [17:18] maco: try to add wpa-key-mgmt WPA-PSK [17:19] where? [17:19] maco: you have a wpa-psk line? and a wpa-ssid? [17:19] yes [17:19] just below one of those [17:19] or above ;) [17:19] Keybuk: just interested to see what the issues are [17:19] highvoltage: I don't know what the issues are [17:20] not having time to work on it includes not having time to investigate [17:20] ouch [17:22] maco: so now it works? ;) [17:22] lemme restart nm and see what happens [17:22] yeah. the error should go away [17:22] Keybuk: was the status of MoM announced on -devel or -devel-announce at some point? [17:23] its arguably a bug that the blacklisting fails if the config is not complete enough [17:24] LaserJock: probably not [17:24] I've been pointing people to MoM when they ask about how to help with merges :( [17:25] asac: yep, that works. i can ifup without killing nm now [17:27] LaserJock: you should have been pointing them to james_w's work [17:27] rmcbride, are you intending to use the "metadata" tag for other Ubuntu One bug reports? [17:27] bzr merge-package is much easier [17:28] mpt: we had been using it to track issues where we felt that metadata corruption or versioning might be an issue. Is this a problem? [17:28] well, i don't know how to use james_w's stuff yet so I wasn't going to put it on others [17:28] rmcbride, I ask because I was using it for package metadata problems: https://bugs.launchpad.net/ubuntu/+bugs?field.tag=metadata [17:28] Keybuk: We'd need an associated list of things needing merging too. [17:28] I *thought* MoM was the "official" source for merging [17:28] mpt: OK. We can discontinue using it for that purpose. Perhaps u1meta or something. I'll bring it up to the team and get a concensus for a different tag [17:29] LaserJock: how to use it *has* been sent to -devel or -devel-announce ;) [17:29] rmcbride, thank you, and sorry for the bother [17:29] mpt: no bother at all. [17:29] ScottK: such a thing should be based on the bzr imports though [17:29] basically it's a "for PACKAGE in *; do bzr missing" no ? [17:29] maco: maybe file a bug ;) "blacklisting of ifupdown interfaces with incomplete config broken" ... [17:30] :P [17:30] sorry! [17:30] Keybuk: right, there was some info that I could never get to work [17:30] thanks for the help [17:30] maco: you can even switch to managed=true ;) [17:30] and then NM honours those settings [17:30] Keybuk: but perhaps the TB should make some announcement or something if MoM is going to be official deprecated [17:31] LaserJock: what has the TB got to do with anything? [17:31] well, I just assumed that they would be a good body to say "heah, we're not going to use MoM anymore" [17:31] maco: enjoy [17:31] asac: am a bit confused as to why wpa-key-mgmt doesnt appear in the interfaces or wpa_supplicant manpages [17:31] Keybuk: Certainly a list should be based on the bzr imports, but in order to switch to this work flow, we'd need that. [17:32] It's a bit undiscoverable otherwise. [17:32] bzr co lp:ubuntu/$PKG; cd $PKG; bzr missing --theirs-only lp:debian/$PKG [17:32] ;) [17:32] ScottK: so get to it! :p [17:32] LaserJock: the TB never said to use MoM in the first place [17:32] maco: not sure if the man pages show any config. checkout /usr/share/doc/wpasupplicant/README.modes.gz [17:32] Keybuk: I certainly don't have enough familiarity with the new tools to work it out. [17:32] I suppose, but it's definately become the canonical source for merges [17:33] asac: ok thanks [17:33]