[02:17] lifeless: Will do. [02:21] lifeless: https://answers.launchpad.net/launchpad/+question/200735 [02:22] thanks === BenC__ is now known as BenC [04:09] how long after a package is accepted in Debian unstable must I wait before running syncpackage? [04:09] "A while". [04:09] I don't recall how often the syncy stuff runs. Plus, it obviously can't run until after dinstall. [04:10] * SpamapS resolves to just wait till morning [04:19] 'published' [04:30] good morning [04:48] Good morning [04:49] ev: the "upgrade after process start" is also fixed in -proposed, BTW; currently waiting for verification [04:50] slangasek: RT 52633> ok, thanks; I'll kill another arch or so then [07:01] good morning [07:10] hey dholbach, wie gehts? [07:12] hey pitti [07:12] sehr gut - wie gehts dir? [07:14] dholbach: prima, danke! [07:15] a bit tired, we went to bed rather late (we watched the game in a Biergarten :) ) [07:15] ah nice :) [07:15] I'm a bit tired as well - I only had about an hour's sleep on Sat→Sun [07:15] but life's good :) [09:17] larsduesing: soyuz> I don't think you'd learn desperately much by doing that, compared to the effort involved; I do a good deal of archive infrastructure work and even I've never felt the need for a local soyuz instance (as opposed to running bits of soyuz via the LP test suite when making changes) [09:25] When I first wanted to do some LP development I tried to get Soyuz working too, but it's pretty nontrivial so now I also just tend to rely on the testsuite. [09:34] pitti: are you the language pack expert? [09:37] Riddell: I guess I am [09:37] pitti: where's the magic script to make them? I want to change it so the kde ones are simple meta packages [09:38] Riddell: it's in https://code.launchpad.net/~ubuntu-langpack/langpack-o-matic/main === mcclurmc_ is now known as mcclurmc [09:54] cyphermox: can you guys have a look at bug 983583 ? [09:54] Launchpad bug 983583 in network-manager (Ubuntu) "nm-applet does not show VPN submenu on login" [Undecided,Confirmed] https://launchpad.net/bugs/983583 [09:55] cyphermox: the QA team cannot really use network manager to connect to our VPN because it is a pain atm === paulliu is now known as paulliu-dinner [10:09] bilal, about bug #1012505: are the dbus patches sent upstream? i can not find any mail on the dbus list about upstart integration for dbus. [10:09] Launchpad bug 1012505 in DBus Test Runner "tests hang in pbuilder environment" [Undecided,Incomplete] https://launchpad.net/bugs/1012505 [10:13] does anyone know an option for pexpect in python3? [10:13] is there any conversion happening or an alternative? [10:15] brendand: "Pexpect-U is unicode-aware, and compatible with Python 3 (using distribute to run 2to3 during setup). It requires Python 2.6 or above." [10:15] http://pypi.python.org/pypi/pexpect-u [10:15] xnox, is there an ubuntu package? [10:16] brendand: no, but since it's pure python you could use pypi-install [10:16] which should make a package for you [10:21] pitti, are there any reasons why ubuntu does not send the dbus patches upstream? there is already some code for systemd upstream, but nothing for dbus. i ask because i want to use dbus-test_runner on debian but the package needs a patched dbus version. [10:21] nothing for upstart, i mean. [10:21] toabctl: the only patches I'm aware of that are not sent upstream are the ones for upstart activation [10:22] pitti, yes. that's the question why theses patches are not send upstream. [10:22] I actually dropped them from my 1.5 merge in https://launchpad.net/~pitti/+archive/ppa/+packages [10:22] toabctl: I don't know; these are rather old, we don't use them, and I didn't feel like porting them [10:22] dbus 1.5 causes some trouble with the indicators, so it wasn't uploaded yet [10:23] pitti, so ubuntu should also work with a upstream dbus version without theses patches? [10:24] pitti, then maybe comment https://bugs.launchpad.net/dbus-test-runner/+bug/1012505/comments/2 is wrong? [10:24] yes, absolutely [10:24] Launchpad bug 1012505 in DBus Test Runner "tests hang in pbuilder environment" [Undecided,Incomplete] [10:25] toabctl: I followed up there [10:26] so we are down to two simple config change patches [10:29] pitti, ok. thanks [10:38] cjwatson: Ok - thanks :) [10:50] SpamapS, slangasek, bdmurray, RAOF: the SRU queue is still around 25 items, some being there for 3 weeks, is there anything we can do to help that moving? === ximion is now known as ximion-afk [11:12] seb128: When I last went through the queue the bottom items were all waiting on information/comment/action from the uploader; I'll do a sweep tomorrow and I'll reject those things waiting more than a two weeks for uploader action. [11:13] If the uploader provides what we're after we can always fish the package out of the rejected queue. === ximion-afk is now known as ximion [11:20] RAOF, ok, thanks [11:21] RAOF, lo-menubar has a rational on why we need the new version, it's basically "it would be as much diff to backport the fix only" and the package is just broken atm and in universe so the update can only be a win === MacSlow is now known as MacSlow|lunch [11:53] xnox: howdy, did you hear anything about emacs24? [11:53] Laney: I didn't get around about enquiring =( [11:54] * xnox it's at the bottom of my todo list [11:55] Laney: I'm using ppa:cassou/emacs and am generally happy about it. Apart from bamf/unity dash integration which I fixed up locally. [11:55] but that's emacs-snapshot and it will move on quickly =( [11:57] How Do I configure dch and requestsync to use emacs? [11:58] vibhav: they should just use the EDITOR or VISUAL environment variables I think [11:59] lemme see [11:59] mdeslaur: ping [11:59] vibhav: yes? [12:01] mdeslaur: Firstly, thanks for sponsoring my uploads [12:01] vibhav: yw [12:01] Also, I am applying for universe-contributors, could you write an endorsement at https://wiki.ubuntu.com/VibhavPant/UniverseContributorApplication ? [12:02] vibhav: remind me which uploads I sponsored for you? [12:03] vibhav: ah, I see them on your page, never mind [12:13] vibhav: if you remove newlines between the table lines, it will render as one table, instead of a table per line. [12:15] xnox: thanks! === ximion is now known as ximion-afk [12:25] mdeslaur: done? [12:26] vibhav: I don't have time to do that now...I'll get to it eventually, when are you applying? [12:26] 2nd July [12:27] vibhav: I'm not sure I've sponsored enough to actually write an endorsement in any case [12:27] vibhav: one was a trivial merge, and the other was a SRU that I had to correct a number of things in the debdiff...not exactly enough material for me to form an opinion on your work === ximion-afk is now known as ximion === ximion is now known as ximion-afk === MacSlow|lunch is now known as MacSlow === paulliu-dinner is now known as paulliu [12:40] jodh: I'm plowing through eventbased initramfs specs/etherpads/braindups since like forever. I have currently fleshed out https://wiki.ubuntu.com/Initramfs with slightly more uptodate info (stealing from eventbased spec previously written ;-) ) [12:40] please check it out =) [12:41] xnox: will do, thanks. [12:48] @pilot in === udevbot changed the topic of #ubuntu-devel to: Archive: open | Dev' of Ubuntu (not support or app devel) | build failures -> http://bit.ly/HaWdtw | #ubuntu for support and general discussion for hardy -> precise | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: pitti [12:48] * vibhav hugs pitti === _salem is now known as salem_ === ximion-afk is now known as ximion [13:03] cyphermox: handing the network-manager task in bug 1013171 to you, as I cannot push to the Vcs-Bzr: (that ought to be fixed, perhaps?) [13:03] Launchpad bug 1013171 in network-manager (Ubuntu Quantal) "Many package hooks not ported to python3" [Undecided,In progress] https://launchpad.net/bugs/1013171 [13:03] cyphermox: it's got a patch [13:14] pitti: ok, thanks! [13:15] pitti: are you busy? [13:15] I'm always busy :) [13:16] pitti: If you get some free time, could you have a look at https://bugs.launchpad.net/ubuntu/+source/fische/+bug/1014637 ? [13:16] Launchpad bug 1014637 in fische (Ubuntu) "Please merge fische 3.2.2-3 from Debian Unstable" [Undecided,In progress] [13:16] vibhav: yes, I can do that; I'm on patch pilot shift, after all [13:16] I just finished sponsoring #1013171, so going to the next one now [13:18] vibhav: has it actually been confirmed that this patch is still needed? [13:18] vibhav: if so, it would be good to send to upstream/Debian [13:18] yeah [13:18] otherwise we'll carry such stupid patches forever [13:19] * vibhav nods [13:19] vibhav: so, how about I sync fische first, and if it fails on armel still, we apply this? [13:19] sure! [13:21] pitti: You are going to do that in a PPA, right? [13:21] no, I synced it into quantal [13:21] we don't have publicly accessible arm PPAs [13:22] ah fine [13:27] vibhav: followed up to bug 1014317; do you know how to submit a Debian bug? [13:27] Launchpad bug 1014317 in gjiten (Ubuntu) "Please merge gjiten 2.6-2.2 (main) from Debian Unstable" [Wishlist,New] https://launchpad.net/bugs/1014317 [13:27] yup [13:27] lemme do that === ximion is now known as ximion-afk [13:31] vibhav: fische built fine === ximion-afk is now known as ximion [13:32] vibhav: your qof merge says "for a first build", but quof is already built on armhf; so this looks obsolete as well? [13:32] same story, /me syncs first === Ursinha` is now known as Ursinha === ximion is now known as ximion-afk === ximion-afk is now known as ximion === ximion is now known as ximion-afk [13:37] pitti: SO Ill set the fische merge request to invalid? [13:37] I already closed it [13:38] doko__, hello. i was told you would be the person to ask about armel compilation problems? === zyga is now known as zyga-food [13:46] Any idea why debuild -S -sa fails in rbot with http://paste.ubuntu.com/1047313/ ? [13:46] vibhav: looks like a missing build dep on some ruby tools [13:47] Well, I did build-dep rbot [13:47] Looks like thats not enough [13:48] you need gem2deb [13:48] (and it should be listed in Build-Depends) [13:48] I was going to say that [13:49] * vibhav does that [13:51] then , as per me logic, rbot should FTBFS in debian sid too [13:53] infinity, OK if I steal the hsqldb merge from you? it has a Java 7 fix and I need to update it for the tomcat7 transition as well.... [13:54] jamespage: You busy? [13:55] jamespage: i'd think infinity is still asleep =)))) am I sure he wouldn't mind ;-) [13:55] * pitti notes that "are you busy" is a trick question which you should avoid; just ask your actual question [13:55] vibhav, yes :-) [13:56] vibhav, hey - wassup - missed your ping yesterday [13:57] jamespage: Well, If you get some free time, could you add an endorsement on https://wiki.ubuntu.com/VibhavPant/UniverseContributorApplication ? [13:57] vibhav, on my TODO list already [13:57] thanks! [13:57] pitti: thanks for sponsoring [14:00] xnox, I'm sure he won't - but its good etiquette to ask first! [14:00] ;-) [14:04] vibhav: btw, merges need a justification why the current delta is still applicable; it would be easier if you could do that research before spending your (and also your sponsor's) time on merges which can just be syncs [14:06] cyphermox, hey have a question about nm. pad.lv/872824 is a bug about strongswan vpn not being compatible with NM. I see some patches on this bug, and am wondering what approach would make sense in getting this functionality working. thanks [14:06] pitti: sure, thanks for the info though [14:07] arges: it would take extensive porting of the strongswan plugin to the new API; IIRC [14:08] I'll look at the patches again [14:08] cyphermox, ok thanks. yea i'd like to know what the approach is === doko__ is now known as doko [14:23] arges, anything more specific? [14:30] pitti, bug #984944, I can't verify it still [14:30] Launchpad bug 984944 in apport (Ubuntu Precise) "Reject crashes that happen right after upgrade" [Medium,Fix committed] https://launchpad.net/bugs/984944 [14:30] pitti, doing the package update steps I get a [14:30] File "/usr/lib/python2.7/dist-packages/apport/report.py", line 439, in add_proc_info [14:30] assert os.path.exists(self['ExecutablePath']) [14:30] in the log [14:31] pitti, are we expecting a cups to sync through or should be we be patching it in ubuntu ? [14:36] doko, yes. looking at the build for witty: https://launchpad.net/ubuntu/+source/witty/3.2.1-2/+build/3572681 [14:36] seems to build fine on other archs + armhf, didn't know if this was a known issue, or I should follow through with a bug [14:40] infinity, a few for review in http://people.canonical.com/~apw/plusone/ [14:40] xnox: you can certainly continue to use UDD for merges if it works for you; I was just pointing out that in general debdiffs are faster on the sponsor side, but I'll deal with UDD :) [14:40] xnox: concerning https://wiki.ubuntu.com/Initramfs : "All these files are collected in a temporary directory and then they are cpio archived and then gunziped." -> I think you mean gzipped instead of gunzipped there [14:41] seb128: hmm, I only tested it in quantal; I'll need to have a closer look at this then, in a precise environment [14:41] apw: we generally keep cups in sync; there's another (two) RC bugs I'd like to fix in Debian before an upload, if only I'd ever get to it [14:41] pitti, ok, no hurry but I can't confirm the fix, feel free to grab me if you need debug infos [14:42] pitti: ok. to be honest doing $ bzr diff -rtag:1.0-1 > merge.debdiff && open lp bug && attach is easy enough. And is comparable to $ bzr push lp:~/ubuntu/quantal/package/merge && bzr lp-propose-merge [14:42] pitti: one spams branches/merge proposals; the other spams bug reports [14:43] xnox: also you have some typo's: "calls run-init to run the real init in yoru reall roofs kept in /root." [14:43] pitti: I'm up for coredev this evening, so maybe soon I will be on the sponsorship side fighting with UDD ;-) [14:43] xnox: if it works for you, great; I just find that UDD forces me to spend a rather inordinate amount of time fiddling with patches and rejectinos [14:43] pitti: =((( sad times [14:44] Chipzz: I didn't write any of it =)))) I refactored it out of out-of-date spec. And this type of information was more suitable on the Initramfs page [14:44] Chipzz: fixes welcome =))))) [14:44] xnox: ah kk, nm then :) [14:45] Chipzz: nm = nanometer? [14:45] * xnox is confused [14:45] xnox: don't think I have an account to edit that [14:45] xnox: nm = nevermind === zyga-food is now known as zyga [14:47] Chipzz: if you don't have an account, I will pick up your questions above and factor them in. It only needs a launchpad account to login?! [14:47] ah k I have a lp account [14:47] wasn't sure what was needed for it [14:48] xnox: hrrrm, but it says "Immutable Page" [14:48] wouldn't that restrict things mortals like me can do? [14:49] That sounds like you're not actually logged into the wiki [14:49] * xnox is a mere mortal with a lp account [14:49] cjwatson: prolly. trying to remember credentials :) [14:50] found it [14:58] pitti: ping, got a few minutes for language pack updating? [14:58] http://irclogs.ubuntu.com/2012/06/15/%23ubuntu-devel.html#t14:27 === yofel_ is now known as yofel [14:58] kelemengabor: I have a meeting in 1 minute, sorry [14:58] okay, maybe later :) === mterry is now known as mterry_two === mterry_ is now known as mterry [14:59] kelemengabor: you need copying PPA -> -proposed? [14:59] kelemengabor: I can do that, yes [14:59] cjwatson, could you comment on bug 1014695? i think i talked to you at UDS about this request, and i think you at least implied you'd be open to it. [14:59] Launchpad bug 1014695 in grub2 (Ubuntu) "need some mechanism to support /boot/grub/menu.lst and pv-grub" [Undecided,New] https://launchpad.net/bugs/1014695 [15:00] pitti: yes, thanks in advance [15:01] xnox: fixed (including several other typos) [15:01] Chipzz: thank you a lot! [15:01] np, 5min work :) [15:02] * Chipzz wonders when spell-checking, should technical terms be added to the dictionary, or should it be left alone? [15:03] I simply left it alone this time [15:04] smoser: I would be open to it as long as it's in a separate source package I don't need to have anything to do with :-) [15:04] smoser: With it in a separate source package, there should be no need to gate on me for anything [15:04] hmm... i thought you had implied it'd be ok to be in grub source package. [15:05] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672104 [15:05] Debian bug 672104 in wnpp "ITP: pv-grub-menu.lst -- " [Wishlist,Open] [15:05] kelemengabor: seems there isn't any newer version in the PPA, it still has 0508 [15:06] smoser: Well, it kind of would, but it's not really connected to it. I think it would be better to have it separate. [15:06] And I don't see why it can't be? [15:06] cjwatson, right. and i was reading the debian bug too. [15:06] cjwatson, the other thing you were going to do for me was just create pv-grub2 [15:06] :) [15:06] pitti: argh indeed, the crontab seems to be disabled :( [15:06] precise-updates at 10:00 on Tue: disabled [15:06] *I* sure wasn't [15:06] jamespage: I have no attachment to hsqldb, all yours. [15:06] I don't even slightly have time [15:07] Upstream has done some work on this, whose status I'm not up to date with [15:07] kelemengabor: reenabled [15:07] thanks! [15:07] kelemengabor: so I guess we'll wait a few days for the PPA to update [15:07] So if that arrives for free with 2.00, great - but otherwise ... [15:07] cjwatson, i'm just kidding. i did think at one time i thought i had you near thinking "hm... that does sound kind of neat, maybe i'll just stay up all night and do that" (regarding grub-pc) [15:07] er... regarding pv-grub2 [15:07] Yeah, but infinite work [15:08] pitti: right, sorry for not checking that before [15:08] kelemengabor: no problem [15:08] Anyway, if it sucks too badly to have it outside grub, feel free to merge the grub-legacy-ec2 stuff into grub (not grub2) in as noninvasive a way as you can manage [15:08] I'd review a patch, but am unlikely to be able to help otherwise, I'm afraid [15:09] It *really* doesn't belong in grub2 [15:09] cjwatson, i think i [15:09] But maybe it could be conditionals in the code in grub (legacy [15:09] ) [15:10] i think it'd be better outside of grub than inside it. [15:10] so if i'm going to split it out of cloud-init, i think i'd go to new package rather than grub [15:10] but thanks. [15:11] infinity, marvellous [15:11] * jamespage goes to sync it [15:14] stgraber: well, if you have some time for this at any point :) https://code.launchpad.net/~jonathan/ubuntu-seeds/edubuntu.quantal/+merge/110841 [15:24] highvoltage: hey, not sure if you're on the lxc-devel m-l, but i'd be interested if you had any opinions on http://sourceforge.net/mailarchive/forum.php?thread_name=20120615221638.GA6236%40sergelap&forum_name=lxc-devel [15:25] hallyn: I'm only on lxc-users but stgraber mentioned something about lxc-devel last week and I've been meaning to subscribe [15:25] highvoltage: :) i tried to convince people to merge the two lists, but they wouldn't go for it :) [15:26] highvoltage: looks good, merging. I'll refresh edubuntu-meta a bit later [15:27] stgraber: thanks! [15:41] kenvandine: so i think the good news is that libpeas *already* supports py3. e.g. PYTHON=python3 ./configure --enable-python passes all its tests. i scanned the code and found only very minor issues (which i'll open upstream bugs on) but none of which afaict should affect py3. i think the tricky part will be building 1.4.0 in ubuntu such that an app can either enable py2 or py3 plugins (but obviously not both) [15:42] cool [15:46] barry: since libpeas is compile time, make two python2/3 libpeas dev packages and make them conflict each other. None of the reverse-build-dependencies of libpeas will be able to enable both of them.... unless there is a fallacy in my argument. [15:46] barry: provides, conflicts dance thingy as done for e.g. virtual mta package [15:47] xnox: my thinking too [15:47] =) [15:47] lunch first :) [15:49] jamespage: Hrm, two things about that sync. One, you dropped the default-jre-headless dep (maybe that's okay?), and two, the arch line seems to confuse lp-buildd's sbuild. Not sure if it should or not, that may need investigating and fixing on the buildds. [15:50] infinity, yeah - I'm looking at that ATM [15:50] the drop on the dependency is OK [15:50] but the architecture check in sbuild is doing something cranky [15:50] jamespage: You could "fix" it by just letting that package build on "any" again, but perhaps the current arch list is perfectly legal and we're just not handling it correctly, due to the fact that we've never run into a package that was "all something-not-i386" before. :P [15:51] infinity, OR I could just drop the bits that are being retained for kfreebsd-* [15:51] or we could fix sbuild [15:51] I think its a valid combination [15:51] Dropping those bits would be a quick and simple hack, yeah. [15:52] that would get me out of jail now [15:52] Filing a bug on launchpad-buildd and assigning it to me for the issue would be nice. [15:52] infinity, sure - I just tested something locally with sbuild which I think resolves it [15:52] But dropping the freebsd-only package seems like a quick fix. I don't have the time to fix lp-buildd right now. [15:52] infinity, ack [15:52] * jamespage goes to file a bug [15:54] SpamapS, pitti: where do we stand wrt nova getting an MRE? It looks like the upload to oneiric-proposed has still not progressed, and there's another package that's been uploaded to precise-proposed queue [15:56] Hello, who should be subscribed to LP #1014705, ubuntu-sponsors or someone else ? [15:56] Launchpad bug 1014705 in skype (Ubuntu) "Candidate revision skype 4.0.0.7-0precise1" [Undecided,Confirmed] https://launchpad.net/bugs/1014705 [15:56] slangasek: The original precise one was superseeded by security upload [15:56] barry: you sound like movie the Mask: "But first..." [15:57] slangasek: which just dropped the proposed package dead in the water [15:58] seb128: the lo-menubar SRU is not at all clear; comment #11 from pitti on bug #754562 claims that this bug is *invalid* for lo-menubar in precise, and I don't see which bit here is supposed to supersede this. [15:58] Launchpad bug 754562 in LibreOffice Menubar Extension "soffice.bin crashed with SIGSEGV in g_hash_table_lookup() (Libreoffice with lo-menubar crash from page preview)" [Undecided,In progress] https://launchpad.net/bugs/754562 [15:59] Daviey: which "original" precise one are you referring to? I don't see that there's ever been a nova SRU accepted for precise [16:00] Daviey: and the one in the queue is stalled not because of a security update but because it doesn't appear to fit the SRU policy [16:01] slangasek: we were discussing this in #ubuntu-server about an hr ago. [16:02] jamespage: what's the bug number? [16:02] xnox, just writing it now [16:02] slangasek: We are intentionally doing SRU's that don't normally fit the SRU policy [16:02] jamespage: surely the lucid buildds have no clue what kfreebsd-* is what's so ever [16:02] slangasek: bdmurray has been trying to dig into it. [16:02] Context: https://lists.ubuntu.com/archives/technical-board/2011-December/001155.html [16:02] Daviey: I went through and read more of the tech board emails [16:03] Daviey: it's because of bdmurray's digging that I'm pinging SpamapS and pitti for the MRE status [16:03] Daviey: and it seems like the tech board wants to see a history of successful micro releases being SRU'ed but that is explictily stated anywhere [16:03] xnox, bug 1014722 [16:03] Launchpad bug 1014722 in launchpad-buildd "Unable to build hsqldb 1.8.0.10-12 directly from Debian" [Undecided,New] https://launchpad.net/bugs/1014722 [16:03] Daviey: and MREs are part of the SRU policy - I mean that this SRU neither has an MRE nor is verifiable using the more traditional route [16:03] bdmurray: this is the test candidate to 'see how it goes' to be granted MRE, no? [16:04] the test candidate was one uploaded to *oneiric* [16:04] which has stalled 6 months, and now there's another upload to precise [16:04] slangasek: yes, the test candidate from oneiric is the one that failed due to security superseeding [16:04] ok [16:05] which is why we are super keen to get this progressing to minimise the chance of it happening again [16:06] jamespage: commented ;-) [16:06] Daviey: getting it to progress is going to require having some plan for how the SRU is going to be verified, which is what I'm asking for [16:07] accepting it into -proposed only to have it stall there because no one will verify it is a waste of everyone's time [16:07] slangasek: Right.. So.. We are doing unit testing at package build time.. functional testing in the CI lab, and extended validation by putting it into production in a real cloud (canonistack) [16:08] (canonistack will test the -proposed package, when it lands there) [16:08] well it also seems like pitti is for an alternate verification process, one where each bug isn't necessarily verification-done [16:08] and this testing would be done for any nova SRU, or just the ones for precise because canonistack happens to be running precise? [16:09] and what should happen with the oneiric nova SRU that's still sitting there? [16:09] Daviey: https://lists.ubuntu.com/archives/technical-board/2011-December/001153.html - here chuck says the package won't FTBFS if the testsuite failed [16:09] Daviey: has that changed? [16:10] bdmurray: yeah its been like that for a while now [16:10] bdmurray: was that a typo? they DO ftbfs if unit tests fail, no? [16:10] zul: ^ [16:10] they do [16:11] slangasek: I don't have a good answer for Oneiric.. We can do extended validation ourselves, but not in a proper cloud. [16:11] Daviey: not a typo [16:11] slangasek: We are closely involved with upstream stable tress.. zul and myself are both reviewers. The idea is to keep upstream ubuntu regression free (which is why we've invested in so much CI) [16:12] * Daviey has to go now.. but will be back later. [16:14] slangasek: AFAIK, nova has no MRE, and the decision was stalled on "lets try a pretend one" where we don't verify all bugs but show a lot of regression testing. [16:14] * SpamapS responds and *then* reads and realizes this is still under discussion [16:17] Daviey: well, that doesn't sound like you're *committing* to do that validation though? Either somebody should commit to following through on the oneiric SRU (including updating it for whatever security fixes make the current one invalid), or we should kick it out of -proposed instead of leaving it sitting there [16:18] Daviey: in any case, if the one currently in -proposed is non-promotable because it's missing security fixes, we should remove that one from -proposed... is that the current state? [16:20] slangasek: imho we should kick oneiric out from -proposed [16:22] * xnox was under impression that heavy testing is done *before* uploading to -proposed, not after. as suggested above by Daviey "(canonistack will test the -proposed package, when it lands there)" [16:22] * vibhav hugs xnox [16:23] xnox: thanks for the comment! [16:23] xnox: we prefer that as much testing as possible happen with the real live package in -proposed, to avoid any mistakes with misbuilt binaries [16:24] slangasek: ok I see your point. Simply other things, e.g. kernel, X-org edgers, KDE have beefy PPAs for pre testing before upload to -proposed. [16:25] slangasek: yet one more unwritten "de-facto" policy [16:25] xnox: the kernel ppa is a special case, we *copy* those binaries from the ppa into the archive [16:25] Ampelbein: ping [16:25] xnox: in cases where we don't do a package copy, I do not consider ppa testing a substitute for SRU testing [16:26] xnox: perhaps de-facto, but I think also pretty obvious as to why. [16:26] * xnox noted, ok [16:26] zul, SpamapS: nova removed from oneiric-proposed [16:26] zul, SpamapS, Daviey: nova removed from oneiric-proposed [16:27] slangasek: cool [16:43] How can I debuild -S -sa msv without installing maven? [16:43] http://paste.ubuntu.com/1047590/ [16:44] vibhav: -nc [16:44] tumbleweed: thanks! [16:44] but you can only do that when it is already clean [16:44] yeah, done that [16:53] slangasek, I didn't read the full bug history to be honest so I'm not sure about the old comments, the bottom line is that the precise version segfault when you try to print preview with lo-menubar installed [16:54] slangasek, which is happening to lot of users who read on the internet to install lo-menubar to get menus integrated, hud working, etc [16:57] xnox: We also have a pre-proposed PPA, where testing happens. [16:57] ok [16:57] xnox: We also regress test as much as we currently can per-commit, upstream [17:00] slangasek, bdmurray: if you have questions about the lo-menubar can you maybe grab directly kenvandine on IRC to sort them? that might work better than bug pingpong to figure what details you guys need [17:01] any idea when emacs24 might hit quantal? [17:02] jml, when it's ready (tm) ;-) [17:02] heh [17:02] jml: currently no. there are a lot of emacs users from ubuntu core devs. and we all want it =) [17:02] this reminds me of Laney doing a ping on me this morning to ping emacs maintainer about it....... [17:03] ping me to ping you to ping him [17:03] jml, Laney: I'm using ppa:cassou/emacs and am generally happy about it. [17:03] pitti, hi. I have a work item for the installer, "add '3-D graphics' to the installer's third-party software text (ubiquity can detect whether nvidia card is in the system)". But ev just told me he thought the plan is to remove the Nvidia driver from that software bundle. Do you know which is right? [17:03] jml, read earlier on this channel, in case that's of any use to you [17:04] seb128: ah yes, thanks. [17:04] * barry also wants emacs 24.1 :) [17:04] I'll go back to waiting patiently then. I'm not in a rush to use a snapshot. [17:09] mpt: pitti: ev: I think I saw bugs about not being able to install nvidia proprietary driver, while running in Live-CD / during installation. It succeeds only after first boot. [17:10] xnox: right, we never installed it in the live cd session [17:10] on in the target system [17:10] only* [17:12] mpt: ^^ i think you have your answer =) [17:12] xnox, no, the paragraph isn't about the live session [17:13] it's about installing Flash, MP3 codecs, etc on the installed system [17:13] mpt: which will not ever include nvidia drivers [17:13] xnox, how do you know? [17:14] mpt: nvidia drivers where previously comming from the jockey. In the future they will be offered/installed by ubuntu-drivers-common and/or software-centre based on modlines [17:14] xnox, I don't know what a modline is, so I don't know what that has to do with the installer. [17:14] * xnox modlines ?! well the hardware graphics card identifier line in packages, [17:14] xnox, by "the installer" I mean Ubiquity [17:15] mpt: Ubiquity currently does not install nvidia. There are no plans to make it do so. [17:16] mpt: nvidia graphics drivers require adding kernel modules and regenerating initramfs, which currently is not possible to do onto the target hard-drive. [17:16] So, I wonder why someone put it as a work item in the session [17:16] [albertomilone] ensure that installing nvidia/fglrx driver package also updates the alternatives symlinks and updates initramfs for the changed blacklists: DONE [17:17] I guess that means Alberto has done the impossible? :-) [17:17] mpt: http://paste.ubuntu.com/1047658/ [17:17] mpt: 'installing' != 'ubiquity', installing as in on the machine, not during the installation. [17:18] I see [17:20] Well, that's annoying. [17:20] mpt: the paste lists depends & the packages, which I think are dynamically downloaded and installed from the internetz [17:21] mpt: yes it is annoying. That even if you choose to install updates & restricted stuff during the installation, you still will have to install stuff on the first reboot. [17:21] mpt: but there is little we can currently do about it. Maybe in two-three releases something will change and we will be able to fix that. [17:21] Heh, true, but I meant annoying only for me. :-) [17:22] Oh, I see =))) workitems =)))) [17:23] mpt: the text you did for ubiquity is fine. Another text maybe needed for the ubuntu-drivers-common, not sure. [17:23] xnox, it's not fine if it says it might install graphics drivers when it never does. [17:23] * xnox hides [17:29] Sorry, didn't mean that to sound anvil-droppy. :-) [17:32] mpt: this got me thinking about this a bit. there is a support to run a post-first-boot-script which we can tell to install the package. [17:32] and if we detected which nvidia drivers to install [17:32] we can make it install automatically without user intervention [17:32] (and pre-download the package during the installation and stick it into (target)/var/cache/apt/archives) [17:33] mpt: this will result in (1) install (2) reboot (3) notification - your system needs a restart to complete upgrades [17:33] =/ [17:35] heh [17:35] I guess pitti will tell us tomorrow [17:35] thanks xnox [17:44] kenvandine: ping re: bug #754562 [17:44] Launchpad bug 754562 in LibreOffice Menubar Extension "soffice.bin crashed with SIGSEGV in g_hash_table_lookup() (Libreoffice with lo-menubar crash from page preview)" [Undecided,In progress] https://launchpad.net/bugs/754562 [17:44] slangasek, pong [17:44] xnox, kenvandine: i don't think it's quite as easy to adjust the packaging to include py3 support in libpeas. first, it doesn't package up a separate python loader, so you can't just add a python3-foo package. you end up with /usr/lib/libpeas-1.0/loaders/libpythonloader.so. so i guess you could just do a second build of just the py3 loader and name it libpython3loader.so and include it in the libpeas-1.0-0 package (w/corresponding [17:44] changes for the debug version). [17:45] xnox, kenvandine of course it's also cdbs, so ouch :/ [17:45] xnox, kenvandine or maybe we should just do a binary package split of the python2 and python3 loaders [17:46] barry, i think that makes sense [17:46] xnox, kenvandine since i don't use libpeas, i don't know what the right thing to do is. suggestions welcome [17:46] i've never used it before... so not much help there [17:47] barry: i don't use libpeas, I use apps that use libpeas. Have you talked to upstream on GIMPNet as to what the best way to support both? [17:47] kenvandine: hi, can you fill out the bug description with the information required per https://wiki.ubuntu.com/StableReleaseUpdates#Procedure ? The bug history is very fuzzy, we need authoritative information about what is being fixed here and why. The bug history shows pitti saying the code isn't even in lo-menubar past natty. [17:47] slangasek, i can try... it is a bit fuzzy to me too [17:47] it has been merged into upstream LO [17:47] but never enabled [17:48] the changes in this version is actually from upstream LO [17:48] xnox: i haven't. upstream may not be the most appropriate place though since as far as upstream's concerned, they support py3. i think it's more a packaging issue, so i think i'll contact the debian maintainer (pkg-gnome-maintainers) and cc debian-python === zyga is now known as zyga-afk [17:48] barry: two thumbs up [17:49] slangasek, as best we can tell the only real fix included in this version is for this bug... the rest was refactoring for upstream [17:49] s/upstream/LO [17:49] slangasek, however upstream for lo-menubar tried to backport just the fix for this bug and gave up... said it would be just as big of a change and more work than it was worth [17:50] kenvandine: ok. when updating the bug, can you include that information, and also comment on why it's safe to take the refactoring changes instead of doing that backport? [17:50] sure [17:52] ta === ximion-afk is now known as ximion [17:53] kenvandine: fwiw I've just done a naive test; I can't crash lowriter on amd64 with a page preview, when lo-menubar is installed [17:54] so the test case definitely needs to cover how to reproduce the original bug... [17:54]