[04:04] micahg: You there? [04:04] vibhav: yes [04:07] micahg: Firstly thanks for reviewing my debdiff. Could you please tell me the unnecessary changes for the debidiff in https://bugs.launchpad.net/ubuntu/+source/libjpeg6b/+bug/1011177 ? [04:07] Launchpad bug 1011177 in libjpeg6b (Ubuntu) "Please merge libjpeg6b 6b1-3 from Debian Unstable" [Undecided,Incomplete] [04:07] (I think its the multi-arch support) [04:07] But is there something more to be removed? [04:08] vibhav: it's part of the multiarch stuff in debian/rules, also take a look at debian/control [04:10] sure, let me take a look [04:11] micahg: Could a sync work? [04:11] vibhav: I don't think so, let me take another look [04:12] vibhav: no [04:13] fine, let me prepare a merge [04:17] * micahg wonders where the -Bsymbolic-functions change went [04:57] Good morning [05:03] micahg: Pre-Depends: multiarch-support in debian but Pre-Depends: ${misc:Pre-Depends} in ubuntu , what should I do? [05:06] Could anybody have a look over https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-apport-fix please? [05:06] vibhav: the Ubuntu version is correct with the proper debhelper build dep [05:09] apachelogger: oh, seems that I touched the wrong bug. I need to apologize === dpb__ is now known as Guest73293 [06:16] hey doko_, can I get your opinion on https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035310.html ? [06:22] infinity: I experience g-s-d exiting, I wonder if it's not due to the rebuild with the gnome-desktop ABI breakage [06:24] good morning [06:24] guten morgen dholbach :) === kInOzAwA- is now known as kInOzAwA [06:25] salut didrocks === kInOzAwA is now known as osX64 [07:13] what's the process to get openjpeg 1.5 into quantal instead of old 1.3 ? [07:15] tsdgeos: Looks like that's a sync from Debian; if Debian has 1.5 then we'll get that in the next autosync. If Debian *doesn't* have 1.5 then that's the best way to get it into quantal at this point. [07:15] An insufficiently lazy person might also upload it direct to Quantal, but they'd be being inefficient ☺ [07:16] RAOF: it's in debian experimental, i guess that's not enough? [07:16] Ah, the other option. [07:17] That means it's a sync away, if it's appropriate. [07:17] needs a transition, not sure if it's API compatible [07:17] ie: if it's in experimental because it's crack we might not want it. If it's in experimental because Debian's about to freeze and they didn't want to play the rdepends game, that's ok :)\ [07:18] my other question is: how much work it takes for it to go to main so poppler can use it? [07:21] it = openjpeg [07:21] That somewhat depends; https://wiki.ubuntu.com/MainInclusionProcess is the process. [07:22] By and large it shouldn't be too arduous for a library. Although you probably need to be more security concious than normal, given it's playing with untrusted data. [07:22] sure [07:22] that's why we need 1.5 [07:22] so it doesn't crash :D [07:23] But openjpeg's not in main yet, right? [07:23] nope [07:23] what you get now is the "worse" poppler jpeg2000 decoder [07:23] that has its fair share of problems [07:23] Aah. [07:23] and obviously noone wants to touch given openjpeg is there [07:24] That should make it reasonably easy, then. [07:24] maintained and done by people that actually understand what it does [07:24] * micahg doubts openjpeg would be allowed in main, it's not even popular enough with browsers [07:32] micahg: so you're going to maintin poppler's jpeg2000 decoder instead? [07:32] the rationale is kind of wird [07:32] because main has poppler [07:32] and poppler has a worse jpeg2000 decoder [07:33] so not including openjpeg it just means bigger holes are there [07:37] Hmm, would be https://bugs.launchpad.net/ubuntu/+source/aiccu/+bug/1001432 a SRU-Candidate or even Security-Update-Candidate? (It is no "bug", but loss of confidentiality and integrity) [07:37] Launchpad bug 1001432 in aiccu (Ubuntu) "apport doesn't deliver aiccu.log but sensitive information with bug reports" [Undecided,Fix committed] [07:40] (and yes, I know, it is atm not in quantal, but in state of proposal for that...) [07:40] (just preparing for the next steps) [07:43] tsdgeos: I don't do the security reviews, so idk which is better :) [07:43] micahg: i do [07:44] tsdgeos: well, just make sure you include the pertinent info if you end up filing the Main Inclusion Request [07:46] Is this understanding of arm madness correct: armv5 code will run on armv6 & armv7, but (obviously) not visa versa. === tkamppeter_ is now known as tkamppeter === Guest95641 is now known as Adri2000 [08:20] ev: heh, speaking of doubling up I'd just started on apt-clone ;-) [08:20] ev: happy to give it up - want my branch? [08:20] sure, I'll take it off your hands [08:21] ev: lp:~cjwatson/apt-clone/py3, have fun [08:21] cjwatson: cheers! [08:21] only ten minutes' worth of work [08:25] cjwatson: morning - what would you like me to look at? [08:26] jodh: fancy figuring out what's involved with producing a python3-newt? [08:26] cjwatson: I'll give it a shot :) [08:27] ... glad it's not just me who read 9 UTC and assumed 9am === zyga is now known as zyga-afk [08:31] * jodh is coffee-deprived yet keen. [08:35] What is the difference between Pre-Depends: ${misc:Pre-Depends} and Pre-Depends: multiarch-support while building a package for multiarch? [08:39] vibhav: The former is what should be written in source packages, and is expanded to the latter in binary packages [08:39] man dh_makeshlibs [08:43] jodh: please add yourself to https://wiki.canonical.com/UbuntuEngineering/Foundations/Python3PortingSprint if you're taking that bit [08:44] cjwatson: done. [08:46] cjwatson: Im merging libjpeg6b from sid, the orignal control says "Pre-Depends: multiarch-support" while the ubuntu control says "Pre-Depends: ${misc:Pre-Depends}" (while both are built for multiarch) what should I do? [08:47] vibhav: While the latter is normally preferable, there's no point keeping an Ubuntu delta for it [08:47] So just use the Debian side [08:48] cjwatson: Why was "-Bsymbolic-functions" from LDFLAGS removed from the ubuntu build then? [08:48] (there is a delta for it too) [08:48] If you don't understand it, pick something else [08:48] Merges aren't actually an easy introductory task [08:48] Not that hard though [08:48] They can be [08:49] cjwatson: see https://merges.ubuntu.com/libj/libjpeg6b/libjpeg6b_6b1-2ubuntu1.patch [08:49] Why don't you try building the Debian version and see what happens? [08:49] Also, there's a note in the changelog about why that was removed [08:49] + * debian/rules: Remove "-Bsymbolic-functions" from LDFLAGS, as this flag [08:49] + breaks the libjpeg use by HPLIP and pxljr, in both cases for printing [08:49] Did you not see that bit? [08:49] + on the HP Color LaserJet 3500/3550/3600 (LP: #777670). [08:49] ah yes [08:50] So should we still have a delta for it? [08:50] Why would we not? [08:50] You must have an active reason to discard a delta [08:51] SO, Ill remove the multiarch stuff from the merge? [08:51] Probably; I haven't looked at it in any detail [08:51] libjpeg6b (6b1-3) unstable; urgency=low [08:51] * Add multiarch support (similar to libjpeg8). closes: #642079 [08:51] The reason the -Bsymbolic-functions change might not be in Debian is that having -Bsymbolic-functions in LDFLAGS by default is specific to Ubuntu's packaging toolchain [08:52] So Debian would probably not have seen the need to remove it [09:30] mvo: http://changelogs.ubuntu.com/meta-release-development looks a bit malformed - "Name: Quantal Quetzal'" [09:30] (trailing apostrophe) [09:31] mvo: And ReleaseNotesHtml isn't HTML for lucid and maverick there - is that deliberate? [09:31] mvo: Seems to cause trouble running the tests [09:42] mvo: Generally I seem to find it rather hard to get the u-m test suite to consistently pass on my machine :-/ [09:44] cjwatson: right, what tests are failing for you currently? happy to have a look === zyga-afk is now known as zyga [09:53] vibhav, pong (but I think I know why...) [10:00] mvo: test_private_ppa_transition and test_html_uri_real - http://paste.ubuntu.com/1035212/ [10:03] cjwatson: thanks, looking now === doko_ is now known as doko [10:46] siretart: I am not sure, seems to me apport didn't really know what to do with 2 errors in the same log and marked it duplicate of libav, while there is also a bug regarding kdegames [10:47] pitti: could you have a look at bug 1011310 to check whether what apport did was behavior as expected [10:47] Launchpad bug 1011310 in kdegames (Ubuntu) "package kdegames-card-data-extra 4:4.8.3-0ubuntu0.1 failed to install/upgrade: trying to overwrite '/usr/share/kde4/apps/carddecks/svg-oxygen-air/11.png', which is also in package kdegames-card-data 4:4.8.3-0ubuntu0.1" [Undecided,New] https://launchpad.net/bugs/1011310 [10:57] apachelogger: I didn't check too closely either === MacSlow is now known as MacSlow|lunch [11:16] siretart: k :) [11:39] apachelogger: not really the right thing in this case, of course [11:39] I think apt takes the first failure and uses that as the identifying one [11:40] because very often, the failures below it are just a consequence of the first one, and not really bugs of their own [11:42] pitti: not always though, so I wonder if the apport bot shouldn't just add a comment and hint that the bug might be a duplicate of #123 instead of marking it ... for logs that exhibit multiple errors anyway [11:43] right, not always, but often enough [11:43] otherwise valid data on a valid bug other than the first choice duplicate might get lost unless someone manually follows the bot [11:43] it's imperfect no matter how you do it :( [11:44] so yes, I don't mind changing this, but it will lead to a lot of unidentified/unclosed real dupes then [11:46] *shrug* marking them is a bit of a gamble as the now burried bug might get reported invidually and compensate for the lost information, or it might not... since I don't have data on how well the gamble works out I couldn't not say anything but "not burrying data > burring data" [12:27] dholbach: thanks for sponsering my upload! [12:27] sponsoring* [12:30] jamespage: Nevermind, I just wanted to ask wether I could prepare a merge for jffi since you were the last guy to touch it in Ubuntu [12:30] vibhav, yeah - I spotted - no problemo === _salem is now known as salem_ [12:58] mpt, hello! A few weeks ago you mentioned that the icon in Software Updater windows should all be the updater application icon. But there's also bug 510212 in which (a while ago) you suggest it should be the Ubuntu icon. Was there a change of heart and we should close that bug? [12:58] Launchpad bug 510212 in update-manager (Ubuntu) "update-manager: no branding. Is it legit?" [Medium,Triaged] https://launchpad.net/bugs/510212 [12:58] mterry, well spotted [12:58] I had forgotten about that one [12:59] mpt, thank Timothy Arceri, who added it to the blueprint [13:04] mterry, I really don't know. On one hand there's the rationale described in that bug report. On the other hand, it's maybe not so good for the Ubuntu logo to be associated with administrative work. [13:04] mterry, what do you think? [13:05] mpt, I don't think it would bother me to use the Ubuntu logo. What do other platforms do? I'm assuming Windows splashes its logo all over Windows Update. What about Mac? [13:11] mterry, Windows Update uses a Windows retail case with a halo around it, but not prominently. OS X has a distinct application icon. [13:12] the halo looks more like a revolving planet === MacSlow|lunch is now known as MacSlow [13:14] mpt, well, Windows Update at least has the brand name in there. But the Mac one only says Software Update and also doesn't have any other Mac branding. So I'd assume they'd have the same considerations in that bug that we woul [13:14] d [13:14] mterry, mpt: We could improvise the Update Manager logo by putting a ubuntu logo on the "box" [13:14] But I've never heard of people being confused or not trusting that dialog (though not sure I would hear...) [13:15] s/improvise/improve (or "legitize")/ [13:15] vibhav, yeah, we need a new logo anyway, the current logo is rather boring [13:16] (where I am awkwardly using "we need" to mean "I would really like to see") [13:17] mpt: What about a ubuntu logo with a plus above? [13:18] or something like that [13:19] hmm [13:19] an Ubuntu logo with arrows on it, or a magic wand over it, or a cloth and washbucket, or... [13:19] What about some typography? [13:20] mterry, I will discuss this with ivanka tomorrow, because she raised a similar issue with me earlier (the use of an Ubuntu logo in the whoopsie error alerts) [13:20] What about http://icondrawer.com/img/Mac-update-icon.jpg (Replacing the M with the Ubuntu Logo in which the arrow is attached with the corcle of friends) [13:21] circle* [13:21] mpt, cool [13:21] mterry, but I suspect the answer will be something like what vibhav suggests [13:22] Adding the Ubuntu logo to the application icon in some way [13:22] * mterry eagerly awaits new art assets [13:22] And the apport icon could look like a Ubuntu Logo bandages on it [13:25] vibhav, we may remove the Ubuntu logo from the error alerts altogether, for reasons described in === salem_ is now known as _salem === _salem is now known as salem_ === salem_ is now known as _salem [13:38] didrocks: Could be. Or couls be entirely unrelated. :P === _salem is now known as salem_ [13:38] infinity: it was ;) I fixed it this morning [13:38] didrocks: Shiny. [13:39] didrocks: Fixed in which package? [13:39] infinity: gnome-desktop itself, it was not related to the ABI itself, but was part of the same migration/upgrade [13:40] Ahh. [13:41] What is the difference between gettext and gettext:any ? [13:42] I was merging a package in which the change in ubuntu had been incorporated into debian too [13:42] (Which was adding gettext to build-depends) [13:42] vibhav: The latter is a hack to hint at apt that gettext from any arch can satisfy the build-dep. [13:43] infinity: That is what the ubuntu delta has, while the debian version has just gettext , Should I file a syncrequest [13:43] Since thats the only change [13:44] The packge I am talking about is attr [13:45] vibhav: We added all the :any intentionally last cycle. I don't recall, of the top of my head, if we still need them. [13:45] cjwatson / slangasek: ^-- ? [13:45] https://merges.ubuntu.com/a/attr/ [13:45] s/of/off/ [13:46] infinity: We do. [13:47] vibhav: Do not drop changes if you don't understand them. [13:47] I cannot stress this too much! [13:47] You should NOT file a sync request in this case. Doing so will obstruct our progress towards cross-building Ubuntu. [13:47] cjwatson: Actually, I havent dropped them [13:47] I was abit confused [13:47] You just proposed doing so [13:47] Unfortunately, we cannot push these changes back to Debian yet, since Debian's buildds don't support them. [13:48] So we have to carry them as deltas. [13:48] cjwatson: So, I am going to prepare a merge, right? [13:48] cjwatson: Curious that Debian's don't and ours do, given that ours do nothing special here. [13:48] vibhav: Have you talked to the person who touched it last, to ensure that you aren't duplicating work? [13:48] infinity: They're running apt on an older base system, I think. [13:48] cjwatson: Or do you mean it trips up wanna-build's auto-dep-wait magic? [13:48] Oh, right. [13:48] Or maybe w-b, yes, not sure. [13:48] No, it's probably apt. [13:48] Steve was going to look nto it. [13:49] or wait, the only change is adding gettext as a dependency [13:49] I ditched the whole "external apt" thing ages ago, cause it drove me nuts. [13:49] So, No merge [13:49] vibhav: It could be a no-nop merge that just merges the changelog, to keep us from having MoM bug us. [13:49] infinity: How does one do that? [13:50] One does a merge. [13:50] Also, http://packages.debian.org/changelogs/pool/main/a/attr/attr_2.4.46-7/changelog [13:50] cjwatson: Yeah, but what do I write in the changelog? [13:50] The same as you would for any other merge. [13:50] Same thing as always. [13:50] We have changes we have to retain, and you would list them. [13:50] ah, got it \m/ [13:51] "Remaining changes: s/gettext/gettext:any/, made package better, added cheese, sprinkled paprika on top, etc" [13:51] The 1:2.4.46-7 changelog is Debian reverting the change we sent them because it broke on Debian buildds. But that doesn't mean it would be correct to drop that change from Ubuntu. [13:51] slangasek: ^- Did vibhav talk with you about this merge in advance? [13:51] nope [13:52] I was going to ask him [13:53] vibhav: I have no objection to you taking it; I hadn't been bothering because there's nothing new to merge from Debian, it would just be to make MoM happy, but as long as the changes aren't dropped, I don't mind :) [13:54] It was mother's day recently; keeping MoM happy is a good thing. [13:58] hi, have this package in queue: https://launchpad.net/ubuntu/quantal/+queue?queue_state=0&queue_text=underscore [13:59] i wanted to ask an archive admin to take care of it and review it [14:01] slangasek: Have you seen the 2011 section http://packages.debian.org/changelogs/pool/main/a/attr/attr_2.4.46-7/changelog ? [14:04] vibhav: yes [14:04] vibhav: the maintainer merged the Ubuntu changes then reverted them again in Debian. We should not be reverting them in Ubuntu. [14:05] Ah , I was wondering why a ubuntu distroseries was there in a debian changelog [14:06] Should I add a "Makes MoM happy" to the changelog? [14:07] I wouldn't [14:08] :P === vibhav_ is now known as vibhav [14:16] slangasek: Done: https://bugs.launchpad.net/ubuntu/+source/attr/+bug/1011639 [14:16] Launchpad bug 1011639 in attr (Ubuntu) "Please merge attr 1:2.4.46-7 from Debian Unstable" [Undecided,New] [14:24] directhex, chrisccoulson: http://gcc.gnu.org/wiki/Cxx11AbiCompatibility don't know what the best thing is. build libsig++ twice? I agree that it will be pain to find all these libraries [14:25] pitti: Short question, do you know since which release apport in ubuntu is enabled by default? [14:25] larsduesing: since 12.04 LTS [14:25] I'm lobbying for turning it off for 12.04.1, though [14:25] oh [14:26] the precise (and even current) version are still getting in the way very often, and I've heard a lot of angry complaints from users [14:26] ok [14:26] so there is no sense in adding apport-hooks for versions before 12.04 ? [14:27] (even for a security-update?) [14:27] very little, unless they make sense for manual bug reports [14:29] it sends login-data to launchpad-bugreports if a run of "apt* install" fails... [14:29] so it happens only on automated reports [14:29] thanks [14:39] pitti: yes, please turn it off :) [14:39] I've read "reviews" where people think precise is more buggy than previous releases because of the annoying popups [14:42] I would have thought that System Settings>Privacy>Diagnostics>Send error reports to Canonical would have done the same thing as editing /etc/default/apport but it doesn't work that way [14:42] What process is used to create the official 12.04 images? Is it livecd-rootfs + live-build, if so what versions and configs? [14:42] jbicha: then we should enable apport only in the pre-LTS release and make it generate some fake reports. LTS will then be perceived as rock-solid. [14:43] pitti, speaking of automated reports, some bugs like bug 1011293 (a crash in gnome-settings-daemon) are private and I can't make them public. Is this a new policy for automated bugs? [14:43] Error: Launchpad bug 1011293 could not be found [14:43] pitti: fixed my bzr launchpad problem. It was an id-10-T issue. [14:43] mterry: none that I'm aware of; I am able to make them public [14:43] Sweetshark: then everyone will run the LTS's instead which may not be a bad thing :) [14:44] Sweetshark: nice to hear; whatever an id-10-T issue is :) [14:44] lol [14:44] pitti, hmm. I wonder what team is doing that for you. Is there a way to find out? [14:44] mterry: the $1M question! === jokerdino_ is now known as jokerdino [14:44] pitti, similarly, there was a question on the mailing list about who gets to see the data from errors.ubuntu.com [14:44] I'm sure thousands of people have wondered about things like that [14:45] mterry: I'm not entirely sure; I guess ~ubuntu-crashes-universe? ev? [14:45] that looks like a (bad) news headline [14:45] jbicha: /etc/default/whoopsie [14:45] universe collapsing, ubuntu is at fault !!! [14:46] so dramatic ogra_! ;) [14:46] :) [14:46] no the universe is ever expanding! [14:47] highvoltage: that's still not proven :) [14:47] vibhav: thanks, I'll have a look at that a little later today [14:47] pitti, mterry: ~canonical + ~ubuntu-bug-control [14:47] ah, thanks [14:48] highvoltage, dont trust news headlines ! [14:48] mterry, what happens when you try to put that bug public? [14:48] ev, do you happen to know why I wouldn't be able to adjust the privacy of a bug? [14:48] seb128, I don't even see the 'edit' icon to change the privacy [14:49] seb128, it just says it's private [14:49] mterry: no idea - definitely not a change that I've introduced [14:49] mterry: ask in #launchpad-dev? [14:49] k [14:49] seb128: can you see the edit button? [14:49] mterry, you don't have a label "This report contains User Data information" on the top right followed by a yellow round icon? [14:49] pitti, ^ [14:49] click on it [14:49] you should get a list [14:49] from my part it might be anything between ~ubuntu-core-dev or ~techboard [14:50] it's the new merge of security & private status [14:50] pitti, mterry: http://blog.launchpad.net/general/how-bug-information-types-work-with-privacy [14:50] seb128, no I don't see it [14:50] mterry, the one one those screenshots? [14:50] mterry, ok, I see it, maybe you are lacking privileges or something but that seems weird [14:51] mterry: are you in ~ubuntu-bug-control? [14:51] * mterry is ~canonical and ~core-dev, what more do I need [14:51] pitti, do you have the ui? [14:51] seb128: yes, I do [14:51] mterry: that should suffice [14:52] OK, so sounds like a bug maybe. I've asked in #launchpad-dev, will report back [14:52] mterry, you should ask on #launchpad I guess [14:52] mterry, cool [14:53] mterry, bug #1007588 btw is your issue [14:54] Launchpad bug 1007588 in gnome-settings-daemon (Ubuntu) "cannot set displays on dual monitor: No such interface `org.gnome.SettingsDaemon.XRANDR_2" [High,Confirmed] https://launchpad.net/bugs/1007588 [14:54] mterry, and it's quite "popular" recently on quantal, bonus point if you figure it out, g-s-d didn't change afaik, nor did gtk [14:54] seb128, that looks like the same trace, but I'm just on my laptop. No external monitor [14:55] seb128, I've had it for a while, really annoying, so I started looking into it :) [14:56] The weird thing is that it's crashing in @plt, which is a weird technical detail of shared libraries. It's not even hitting libgdk [14:56] mterry, right, the title was confusing, I just changed it, it turned out that the underlining reason for the xrandr error was "g-s-d is not running" [14:56] seb128, ah, makes sense [14:57] seb128, guess I'll mark the other one as a dup [14:57] mterry, yeah, I blame the toolchain, I don't think the GNOME stack changed [14:57] mterry, I just did that [14:57] kthx [14:58] Well, a simple rebuild didn't fix it (and g-s-d has been rebuilt already in quantal anyway). [14:59] doko, do you know much about "@plt" (procedure linkage table)? [15:03] slangasek, pitti: could somebody accepted my mail from today to the tb list? [15:03] seb128: can do [15:03] pitti, danke [15:03] mterry, we have a new expert for glibc and dynamic loading ;) /me waves at infinity [15:04] infinity, hi! When you have a few moments, can you help me with bug 1007588? [15:04] Launchpad bug 1007588 in gnome-settings-daemon (Ubuntu) "[mouse]: gnome-settings-daemon SIGSEGV in gdk_device_manager_list_devices@plt()" [High,Confirmed] https://launchpad.net/bugs/1007588 [15:05] didrocks, how ready is oneconf for Python3? [15:06] doko: well, I'll need to do the porting at the same time than software-center [15:06] doko: as it's imported from it [15:06] doko: will be quite easy, few days [15:06] doko: btw, I asked you a question this morning here [15:06] doko: it was about chris email on ubuntu-devel for sigc++ [15:07] doko, thanks [15:07] did you mean to direct that at didrocks too? [15:07] seems it went to the wrong person :) [15:08] I didn't receive anything if something was sent :) [15:08] didrocks, ah, you were offline [15:08] directhex, chrisccoulson: http://gcc.gnu.org/wiki/Cxx11AbiCompatibility don't know what the best thing is. build libsig++ twice? I agree that it will be pain to find all these libraries [15:08] chrisccoulson: my internet connection dropped for 5 minutes, yeah [15:08] ^didrocks [15:08] thanks :) [15:09] answering on the list. libstdc++ builds code for c++98 and c++11 in the same library. not sure if this is possible for other libs as well. [15:09] doko: ok, we are totally in that case (the first one of the new M_size member) [15:10] doko: oh, and we ship both? [15:10] no, it's in the same shared object [15:10] Are other people getting a lot of 'Hash Sum mismatch' messages on precise amd64 when installing packages? I've updated/upgraded, but still am getting them. Any suggestions? [15:10] doko: oh nice, is there a recipe to ensure to take the right functions then, can you give some links? [15:11] didrocks, no I don't have any :-/ [15:11] I think we'll need a way for sigc++ for this [15:12] arges: usually a transparent proxy getting in the way - find appropriate Release/Release.gpg/Packages URLs and wget --no-cache them [15:12] doko: do you think you will have some time allocated for looking at this? it seems you are the most knowledgeable for this [15:13] cjwatson, ok i'll try that [15:13] http://blog.init.hr/?p=183 # at the bottom they describe building the cloud-live iso from a launchpad branch... is there a similar launchpad branch for the 12.04 desktop isos? [15:13] didrocks, will do after our virtual Python3 sprint (which ends Wed). [15:14] doko: thanks :) [15:16] more specifically I'd love to find the ppa / live-build config that created http://hwe.ubuntu.com/uds-q/dellxps/ [15:18] mterry: I'm in the middle of a sprint right now, but I can help look at it in a couple of days, if you're still stuck. [15:19] infinity, more likely I can just wait. :) I'm at the limit of my domain knowledge here, not productive to spin cycles without a pointer. But there's no rush [15:24] I'm trying to create a custom iso for the xps13/sputnik project... does anyone know if there is a bzr/git repo for the live-build config that generated the http://hwe.ubuntu.com/uds-q/dellxps/ isos ? [15:26] vanhoof: ^ [15:28] superm1: thanks, I'll reach out to him [15:28] sure === fenris is now known as Guest99220 [15:32] mterry: Where's this u-m branch of yours without a-u-t? [15:32] infinity, https://code.launchpad.net/~mterry/update-manager/drop-auto-tester [15:32] mterry: Danke. === Guest99220 is now known as ejat [15:45] mterry, infinity: stgraber was asking about this earlier too, please sync to ensure to not dupe work :) [15:46] mvo, about the auto-tester stuff? Or the crasher in @plt? [15:47] mterry: the auto-tester [15:48] mterry: not sure I know about the crasher [15:48] mvo, yar no biggie, it was just something infinity and I talked about a few minutes ago. [15:48] mvo, OK. stgraber: I've got a branch already to drop auto-tester, if you were looking into that. Same for release-upgrader [15:49] mvo, I've got branches for your review, man! [15:49] They're piling up [15:50] mterry: yeah, I've just gone through all the remaining changes in the u-m branch and merge them into auto-upgrade-testing as we certainly don't want to loose these [15:50] stgraber, ah awesome. I was under the impression that lp:auto-upgrade-testing was more-up-to-date. Thanks for the catch [15:51] mterry: it partly was, which made the merge "interesting" :) [15:53] * cjwatson whines idly about the practice of splitting things off without finishing the job :) [15:54] mterry: Alright. stgraber's merged u-m into a-u-t, and I've merged dropping a-u-t back into our py3 u-m branch, so that should all be tidied now. [15:54] mterry: What's this about release-upgrader getting the same treatment? :P [15:54] Not finishing the job there is especially irritating since I've been piling up the commits there pretty rapidly. [15:55] I mean, I vaguely knew about the split, but I had to pick one side or the other to commit on ... [15:58] yeah, I somehow assumed that it was dropped from u-m when split to auto-upgrade-testing, so commited my own changes to lp:auto-upgrade-testing for the past few weeks (though not in a python3 compatible way, fixing that now... );) [15:59] stgraber: But I'm correct in assuming that you've merged whatever changed we had in the py3 branch back to lp:auto-upgrade-testing? [15:59] stgraber: (Well, everything up to the commit where I removed it all) [16:02] infinity: yes [16:02] mvo: Does http://paste.ubuntu.com/1035684/ look right? Fixes tests for quantal per http://www.piware.de/2012/05/pygobject-3-3-1-released/ [16:04] infinity, https://code.launchpad.net/~mterry/update-manager/split-release-upgrader [16:04] cjwatson: it is, and yet I can't say I'm impressed by this upstream decision, if it should be bound to python object attributes, why is that not done in the python-gi wrapper? [16:05] cjwatson: so that its not a API change [16:05] cjwatson: but I guess you are not the right perosn to ask this question :) [16:05] pitti: ---^ ? [16:05] mterry: Check, found it. Do we already have a new project and source package for release-upgrader? [16:05] infinity, (paired with https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/split) [16:05] infinity, I was waiting on review before pushing to ubuntu [16:05] Daviey: re pyyaml - I gave my thoughts in the mail, but I think it's up to someone @canonical.com to decide if the will take cython in Main. [16:06] cjwatson: except for this its fine, I think that will break more of my stuff as I use get_data/set_data quite a bit in various of my projects :/ [16:06] mvo: that actually was (and still is) the plan indeed [16:06] mvo: I wasn't aware that anyone actually uses this [16:06] it seemed like a very unusual thing to use from Python [16:06] mvo: I agree and I whined in the upstream bug [16:07] mvo: But we might as well avoid it anyway [16:07] fair enough [16:07] mterry: Kay. Well, the whole thing depends on the other branch I just merged out-of-band, so we'll wait until we merge our py3 stuff back into the mainline branch, and them I might look at your release-upgrader split. [16:08] * pitti waves good night [16:08] infinity, yeah, the release upgrader split is more complicated [16:11] mterry: Looks like, yeah. [16:14] good night, pitti :-) [16:26] mvo: hi, where do we sit now as far as an apt update for quantal? I understand that aptdaemon's python3 support requires a fix to apt-key; is there anything that should block me from doing an apt upload? [16:26] mvo: I know you mentioned a while ago that you had staged the merge, but it still seems not to be uploaded to quantal :) === smb` is now known as smb [16:32] Hola [16:34] Me gustaría colaborar arreglando bugs. No tengo experiencia en programación. Y no sé por donde empezar. Me gustaría que vosotros me orientaran [16:36] slangasek: It's possible that the apt merge depends on my dpkg merge. (I don't know this to be true, but it seems plausible) [16:36] maca: Realmente podría ayudar si usted puede hablar en Inglés :) [16:37] ok, I thought that channel was Spanish [16:37] Let see [16:37] you're in #ubuntu-devel, English is the common language here :) [16:37] infinity: you're just fishing for a reason for the dpkg merge to be on topic for the python3 sprint, aren't you ;) [16:38]