| vibhav | micahg: You there? | 04:04 |
|---|---|---|
| micahg | vibhav: yes | 04:04 |
| vibhav | 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 |
| ubottu | Launchpad bug 1011177 in libjpeg6b (Ubuntu) "Please merge libjpeg6b 6b1-3 from Debian Unstable" [Undecided,Incomplete] | 04:07 |
| vibhav | (I think its the multi-arch support) | 04:07 |
| vibhav | But is there something more to be removed? | 04:07 |
| micahg | vibhav: it's part of the multiarch stuff in debian/rules, also take a look at debian/control | 04:08 |
| vibhav | sure, let me take a look | 04:10 |
| vibhav | micahg: Could a sync work? | 04:11 |
| micahg | vibhav: I don't think so, let me take another look | 04:11 |
| micahg | vibhav: no | 04:12 |
| vibhav | fine, let me prepare a merge | 04:13 |
| * micahg wonders where the -Bsymbolic-functions change went | 04:17 | |
| larsduesing | Good morning | 04:57 |
| vibhav | micahg: Pre-Depends: multiarch-support in debian but Pre-Depends: ${misc:Pre-Depends} in ubuntu , what should I do? | 05:03 |
| larsduesing | Could anybody have a look over https://code.launchpad.net/~lars.duesing/ubuntu/quantal/aiccu/aiccu-apport-fix please? | 05:06 |
| micahg | vibhav: the Ubuntu version is correct with the proper debhelper build dep | 05:06 |
| siretart | apachelogger: oh, seems that I touched the wrong bug. I need to apologize | 05:09 |
| === dpb__ is now known as Guest73293 | ||
| didrocks | hey doko_, can I get your opinion on https://lists.ubuntu.com/archives/ubuntu-devel/2012-June/035310.html ? | 06:16 |
| didrocks | infinity: I experience g-s-d exiting, I wonder if it's not due to the rebuild with the gnome-desktop ABI breakage | 06:22 |
| dholbach | good morning | 06:24 |
| didrocks | guten morgen dholbach :) | 06:24 |
| === kInOzAwA- is now known as kInOzAwA | ||
| dholbach | salut didrocks | 06:25 |
| === kInOzAwA is now known as osX64 | ||
| tsdgeos | what's the process to get openjpeg 1.5 into quantal instead of old 1.3 ? | 07:13 |
| RAOF | 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 |
| RAOF | An insufficiently lazy person might also upload it direct to Quantal, but they'd be being inefficient ☺ | 07:15 |
| tsdgeos | RAOF: it's in debian experimental, i guess that's not enough? | 07:16 |
| RAOF | Ah, the other option. | 07:16 |
| RAOF | That means it's a sync away, if it's appropriate. | 07:17 |
| micahg | needs a transition, not sure if it's API compatible | 07:17 |
| RAOF | 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:17 |
| tsdgeos | my other question is: how much work it takes for it to go to main so poppler can use it? | 07:18 |
| tsdgeos | it = openjpeg | 07:21 |
| RAOF | That somewhat depends; https://wiki.ubuntu.com/MainInclusionProcess is the process. | 07:21 |
| RAOF | 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 |
| tsdgeos | sure | 07:22 |
| tsdgeos | that's why we need 1.5 | 07:22 |
| tsdgeos | so it doesn't crash :D | 07:22 |
| RAOF | But openjpeg's not in main yet, right? | 07:23 |
| tsdgeos | nope | 07:23 |
| tsdgeos | what you get now is the "worse" poppler jpeg2000 decoder | 07:23 |
| tsdgeos | that has its fair share of problems | 07:23 |
| RAOF | Aah. | 07:23 |
| tsdgeos | and obviously noone wants to touch given openjpeg is there | 07:23 |
| RAOF | That should make it reasonably easy, then. | 07:24 |
| tsdgeos | 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:24 | |
| tsdgeos | micahg: so you're going to maintin poppler's jpeg2000 decoder instead? | 07:32 |
| tsdgeos | the rationale is kind of wird | 07:32 |
| tsdgeos | because main has poppler | 07:32 |
| tsdgeos | and poppler has a worse jpeg2000 decoder | 07:32 |
| tsdgeos | so not including openjpeg it just means bigger holes are there | 07:33 |
| larsduesing | 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 |
| ubottu | Launchpad bug 1001432 in aiccu (Ubuntu) "apport doesn't deliver aiccu.log but sensitive information with bug reports" [Undecided,Fix committed] | 07:37 |
| larsduesing | (and yes, I know, it is atm not in quantal, but in state of proposal for that...) | 07:40 |
| larsduesing | (just preparing for the next steps) | 07:40 |
| micahg | tsdgeos: I don't do the security reviews, so idk which is better :) | 07:43 |
| tsdgeos | micahg: i do | 07:43 |
| micahg | tsdgeos: well, just make sure you include the pertinent info if you end up filing the Main Inclusion Request | 07:44 |
| RAOF | Is this understanding of arm madness correct: armv5 code will run on armv6 & armv7, but (obviously) not visa versa. | 07:46 |
| === tkamppeter_ is now known as tkamppeter | ||
| === Guest95641 is now known as Adri2000 | ||
| cjwatson | ev: heh, speaking of doubling up I'd just started on apt-clone ;-) | 08:20 |
| cjwatson | ev: happy to give it up - want my branch? | 08:20 |
| ev | sure, I'll take it off your hands | 08:20 |
| cjwatson | ev: lp:~cjwatson/apt-clone/py3, have fun | 08:21 |
| ev | cjwatson: cheers! | 08:21 |
| cjwatson | only ten minutes' worth of work | 08:21 |
| jodh | cjwatson: morning - what would you like me to look at? | 08:25 |
| cjwatson | jodh: fancy figuring out what's involved with producing a python3-newt? | 08:26 |
| jodh | cjwatson: I'll give it a shot :) | 08:26 |
| cjwatson | ... glad it's not just me who read 9 UTC and assumed 9am | 08:27 |
| === zyga is now known as zyga-afk | ||
| * jodh is coffee-deprived yet keen. | 08:31 | |
| vibhav | What is the difference between Pre-Depends: ${misc:Pre-Depends} and Pre-Depends: multiarch-support while building a package for multiarch? | 08:35 |
| cjwatson | vibhav: The former is what should be written in source packages, and is expanded to the latter in binary packages | 08:39 |
| cjwatson | man dh_makeshlibs | 08:39 |
| cjwatson | jodh: please add yourself to https://wiki.canonical.com/UbuntuEngineering/Foundations/Python3PortingSprint if you're taking that bit | 08:43 |
| jodh | cjwatson: done. | 08:44 |
| vibhav | 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:46 |
| cjwatson | vibhav: While the latter is normally preferable, there's no point keeping an Ubuntu delta for it | 08:47 |
| cjwatson | So just use the Debian side | 08:47 |
| vibhav | cjwatson: Why was "-Bsymbolic-functions" from LDFLAGS removed from the ubuntu build then? | 08:48 |
| vibhav | (there is a delta for it too) | 08:48 |
| cjwatson | If you don't understand it, pick something else | 08:48 |
| cjwatson | Merges aren't actually an easy introductory task | 08:48 |
| vibhav | Not that hard though | 08:48 |
| cjwatson | They can be | 08:48 |
| vibhav | cjwatson: see https://merges.ubuntu.com/libj/libjpeg6b/libjpeg6b_6b1-2ubuntu1.patch | 08:49 |
| cjwatson | Why don't you try building the Debian version and see what happens? | 08:49 |
| cjwatson | Also, there's a note in the changelog about why that was removed | 08:49 |
| cjwatson | + * debian/rules: Remove "-Bsymbolic-functions" from LDFLAGS, as this flag | 08:49 |
| cjwatson | + breaks the libjpeg use by HPLIP and pxljr, in both cases for printing | 08:49 |
| cjwatson | Did you not see that bit? | 08:49 |
| cjwatson | + on the HP Color LaserJet 3500/3550/3600 (LP: #777670). | 08:49 |
| vibhav | ah yes | 08:49 |
| vibhav | So should we still have a delta for it? | 08:50 |
| cjwatson | Why would we not? | 08:50 |
| cjwatson | You must have an active reason to discard a delta | 08:50 |
| vibhav | SO, Ill remove the multiarch stuff from the merge? | 08:51 |
| cjwatson | Probably; I haven't looked at it in any detail | 08:51 |
| vibhav | libjpeg6b (6b1-3) unstable; urgency=low | 08:51 |
| vibhav | * Add multiarch support (similar to libjpeg8). closes: #642079 | 08:51 |
| cjwatson | 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:51 |
| cjwatson | So Debian would probably not have seen the need to remove it | 08:52 |
| cjwatson | mvo: http://changelogs.ubuntu.com/meta-release-development looks a bit malformed - "Name: Quantal Quetzal'" | 09:30 |
| cjwatson | (trailing apostrophe) | 09:30 |
| cjwatson | mvo: And ReleaseNotesHtml isn't HTML for lucid and maverick there - is that deliberate? | 09:31 |
| cjwatson | mvo: Seems to cause trouble running the tests | 09:31 |
| cjwatson | mvo: Generally I seem to find it rather hard to get the u-m test suite to consistently pass on my machine :-/ | 09:42 |
| mvo | cjwatson: right, what tests are failing for you currently? happy to have a look | 09:44 |
| === zyga-afk is now known as zyga | ||
| jamespage | vibhav, pong (but I think I know why...) | 09:53 |
| cjwatson | mvo: test_private_ppa_transition and test_html_uri_real - http://paste.ubuntu.com/1035212/ | 10:00 |
| mvo | cjwatson: thanks, looking now | 10:03 |
| === doko_ is now known as doko | ||
| apachelogger | 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:46 |
| apachelogger | pitti: could you have a look at bug 1011310 to check whether what apport did was behavior as expected | 10:47 |
| ubottu | 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:47 |
| siretart | apachelogger: I didn't check too closely either | 10:57 |
| === MacSlow is now known as MacSlow|lunch | ||
| apachelogger | siretart: k :) | 11:16 |
| pitti | apachelogger: not really the right thing in this case, of course | 11:39 |
| pitti | I think apt takes the first failure and uses that as the identifying one | 11:39 |
| pitti | because very often, the failures below it are just a consequence of the first one, and not really bugs of their own | 11:40 |
| apachelogger | 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:42 |
| pitti | right, not always, but often enough | 11:43 |
| apachelogger | otherwise valid data on a valid bug other than the first choice duplicate might get lost unless someone manually follows the bot | 11:43 |
| pitti | it's imperfect no matter how you do it :( | 11:43 |
| pitti | so yes, I don't mind changing this, but it will lead to a lot of unidentified/unclosed real dupes then | 11:44 |
| apachelogger | *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" | 11:46 |
| vibhav | dholbach: thanks for sponsering my upload! | 12:27 |
| vibhav | sponsoring* | 12:27 |
| vibhav | 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 |
| jamespage | vibhav, yeah - I spotted - no problemo | 12:30 |
| === _salem is now known as salem_ | ||
| mterry | 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 |
| ubottu | Launchpad bug 510212 in update-manager (Ubuntu) "update-manager: no branding. Is it legit?" [Medium,Triaged] https://launchpad.net/bugs/510212 | 12:58 |
| mpt | mterry, well spotted | 12:58 |
| mpt | I had forgotten about that one | 12:58 |
| mterry | mpt, thank Timothy Arceri, who added it to the blueprint | 12:59 |
| mpt | 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 |
| mpt | mterry, what do you think? | 13:04 |
| mterry | 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:05 |
| mpt | mterry, Windows Update uses a Windows retail case with a halo around it, but not prominently. <http://en.wikipedia.org/wiki/File:Windows_Update.png> OS X has a distinct application icon. <http://www.maclife.com/article/howtos/disabling_specific_software_updates> | 13:11 |
| vibhav | the halo looks more like a revolving planet | 13:12 |
| === MacSlow|lunch is now known as MacSlow | ||
| mterry | 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 |
| mterry | d | 13:14 |
| vibhav | mterry, mpt: We could improvise the Update Manager logo by putting a ubuntu logo on the "box" | 13:14 |
| mterry | But I've never heard of people being confused or not trusting that dialog (though not sure I would hear...) | 13:14 |
| vibhav | s/improvise/improve (or "legitize")/ | 13:15 |
| mpt | vibhav, yeah, we need a new logo anyway, the current logo is rather boring | 13:15 |
| mpt | (where I am awkwardly using "we need" to mean "I would really like to see") | 13:16 |
| vibhav | mpt: What about a ubuntu logo with a plus above? | 13:17 |
| mpt | or something like that | 13:18 |
| vibhav | hmm | 13:19 |
| mpt | an Ubuntu logo with arrows on it, or a magic wand over it, or a cloth and washbucket, or... | 13:19 |
| vibhav | What about some typography? | 13:19 |
| mpt | 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 |
| vibhav | 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:20 |
| vibhav | circle* | 13:21 |
| mterry | mpt, cool | 13:21 |
| mpt | mterry, but I suspect the answer will be something like what vibhav suggests | 13:21 |
| mpt | Adding the Ubuntu logo to the application icon in some way | 13:22 |
| * mterry eagerly awaits new art assets | 13:22 | |
| vibhav | And the apport icon could look like a Ubuntu Logo bandages on it | 13:22 |
| mpt | vibhav, we may remove the Ubuntu logo from the error alerts altogether, for reasons described in <http://uxmag.com/articles/your-logo-is-making-me-sick> | 13:25 |
| === salem_ is now known as _salem | ||
| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| infinity | didrocks: Could be. Or couls be entirely unrelated. :P | 13:38 |
| === _salem is now known as salem_ | ||
| didrocks | infinity: it was ;) I fixed it this morning | 13:38 |
| infinity | didrocks: Shiny. | 13:38 |
| infinity | didrocks: Fixed in which package? | 13:39 |
| didrocks | infinity: gnome-desktop itself, it was not related to the ABI itself, but was part of the same migration/upgrade | 13:39 |
| infinity | Ahh. | 13:40 |
| vibhav | What is the difference between gettext and gettext:any ? | 13:41 |
| vibhav | I was merging a package in which the change in ubuntu had been incorporated into debian too | 13:42 |
| vibhav | (Which was adding gettext to build-depends) | 13:42 |
| infinity | vibhav: The latter is a hack to hint at apt that gettext from any arch can satisfy the build-dep. | 13:42 |
| vibhav | infinity: That is what the ubuntu delta has, while the debian version has just gettext , Should I file a syncrequest | 13:43 |
| vibhav | Since thats the only change | 13:43 |
| vibhav | The packge I am talking about is attr | 13:44 |
| infinity | 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 |
| infinity | cjwatson / slangasek: ^-- ? | 13:45 |
| vibhav | https://merges.ubuntu.com/a/attr/ | 13:45 |
| infinity | s/of/off/ | 13:45 |
| cjwatson | infinity: We do. | 13:46 |
| cjwatson | vibhav: Do not drop changes if you don't understand them. | 13:47 |
| cjwatson | I cannot stress this too much! | 13:47 |
| cjwatson | You should NOT file a sync request in this case. Doing so will obstruct our progress towards cross-building Ubuntu. | 13:47 |
| vibhav | cjwatson: Actually, I havent dropped them | 13:47 |
| vibhav | I was abit confused | 13:47 |
| cjwatson | You just proposed doing so | 13:47 |
| cjwatson | Unfortunately, we cannot push these changes back to Debian yet, since Debian's buildds don't support them. | 13:47 |
| cjwatson | So we have to carry them as deltas. | 13:48 |
| vibhav | cjwatson: So, I am going to prepare a merge, right? | 13:48 |
| infinity | cjwatson: Curious that Debian's don't and ours do, given that ours do nothing special here. | 13:48 |
| cjwatson | vibhav: Have you talked to the person who touched it last, to ensure that you aren't duplicating work? | 13:48 |
| cjwatson | infinity: They're running apt on an older base system, I think. | 13:48 |
| infinity | cjwatson: Or do you mean it trips up wanna-build's auto-dep-wait magic? | 13:48 |
| infinity | Oh, right. | 13:48 |
| cjwatson | Or maybe w-b, yes, not sure. | 13:48 |
| infinity | No, it's probably apt. | 13:48 |
| cjwatson | Steve was going to look nto it. | 13:48 |
| vibhav | or wait, the only change is adding gettext as a dependency | 13:49 |
| infinity | I ditched the whole "external apt" thing ages ago, cause it drove me nuts. | 13:49 |
| vibhav | So, No merge | 13:49 |
| infinity | vibhav: It could be a no-nop merge that just merges the changelog, to keep us from having MoM bug us. | 13:49 |
| vibhav | infinity: How does one do that? | 13:49 |
| cjwatson | One does a merge. | 13:50 |
| vibhav | Also, http://packages.debian.org/changelogs/pool/main/a/attr/attr_2.4.46-7/changelog | 13:50 |
| vibhav | cjwatson: Yeah, but what do I write in the changelog? | 13:50 |
| cjwatson | The same as you would for any other merge. | 13:50 |
| infinity | Same thing as always. | 13:50 |
| cjwatson | We have changes we have to retain, and you would list them. | 13:50 |
| vibhav | ah, got it \m/ | 13:50 |
| infinity | "Remaining changes: s/gettext/gettext:any/, made package better, added cheese, sprinkled paprika on top, etc" | 13:51 |
| cjwatson | 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 |
| cjwatson | slangasek: ^- Did vibhav talk with you about this merge in advance? | 13:51 |
| vibhav | nope | 13:51 |
| vibhav | I was going to ask him | 13:52 |
| slangasek | 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:53 |
| infinity | It was mother's day recently; keeping MoM happy is a good thing. | 13:54 |
| yolanda | hi, have this package in queue: https://launchpad.net/ubuntu/quantal/+queue?queue_state=0&queue_text=underscore | 13:58 |
| yolanda | i wanted to ask an archive admin to take care of it and review it | 13:59 |
| vibhav | slangasek: Have you seen the 2011 section http://packages.debian.org/changelogs/pool/main/a/attr/attr_2.4.46-7/changelog ? | 14:01 |
| slangasek | vibhav: yes | 14:04 |
| slangasek | vibhav: the maintainer merged the Ubuntu changes then reverted them again in Debian. We should not be reverting them in Ubuntu. | 14:04 |
| vibhav | Ah , I was wondering why a ubuntu distroseries was there in a debian changelog | 14:05 |
| vibhav | Should I add a "Makes MoM happy" to the changelog? | 14:06 |
| slangasek | I wouldn't | 14:07 |
| vibhav | :P | 14:08 |
| === vibhav_ is now known as vibhav | ||
| vibhav | slangasek: Done: https://bugs.launchpad.net/ubuntu/+source/attr/+bug/1011639 | 14:16 |
| ubottu | Launchpad bug 1011639 in attr (Ubuntu) "Please merge attr 1:2.4.46-7 from Debian Unstable" [Undecided,New] | 14:16 |
| doko | 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:24 |
| larsduesing | pitti: Short question, do you know since which release apport in ubuntu is enabled by default? | 14:25 |
| pitti | larsduesing: since 12.04 LTS | 14:25 |
| pitti | I'm lobbying for turning it off for 12.04.1, though | 14:25 |
| larsduesing | oh | 14:25 |
| pitti | 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 |
| larsduesing | ok | 14:26 |
| larsduesing | so there is no sense in adding apport-hooks for versions before 12.04 ? | 14:26 |
| larsduesing | (even for a security-update?) | 14:27 |
| pitti | very little, unless they make sense for manual bug reports | 14:27 |
| larsduesing | it sends login-data to launchpad-bugreports if a run of "apt* install" fails... | 14:29 |
| larsduesing | so it happens only on automated reports | 14:29 |
| larsduesing | thanks | 14:29 |
| jbicha | pitti: yes, please turn it off :) | 14:39 |
| jbicha | I've read "reviews" where people think precise is more buggy than previous releases because of the annoying popups | 14:39 |
| jbicha | 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 |
| hippiehacker | 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 |
| Sweetshark | 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:42 |
| mterry | 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 |
| ubottu | Error: Launchpad bug 1011293 could not be found | 14:43 |
| Sweetshark | pitti: fixed my bzr launchpad problem. It was an id-10-T issue. | 14:43 |
| pitti | mterry: none that I'm aware of; I am able to make them public | 14:43 |
| jbicha | Sweetshark: then everyone will run the LTS's instead which may not be a bad thing :) | 14:43 |
| pitti | Sweetshark: nice to hear; whatever an id-10-T issue is :) | 14:44 |
| jbicha | lol | 14:44 |
| mterry | pitti, hmm. I wonder what team is doing that for you. Is there a way to find out? | 14:44 |
| pitti | mterry: the $1M question! | 14:44 |
| === jokerdino_ is now known as jokerdino | ||
| mterry | pitti, similarly, there was a question on the mailing list about who gets to see the data from errors.ubuntu.com | 14:44 |
| pitti | I'm sure thousands of people have wondered about things like that | 14:44 |
| pitti | mterry: I'm not entirely sure; I guess ~ubuntu-crashes-universe? ev? | 14:45 |
| ogra_ | that looks like a (bad) news headline | 14:45 |
| ev | jbicha: /etc/default/whoopsie | 14:45 |
| ogra_ | universe collapsing, ubuntu is at fault !!! | 14:45 |
| awe | so dramatic ogra_! ;) | 14:46 |
| ogra_ | :) | 14:46 |
| highvoltage | no the universe is ever expanding! | 14:46 |
| pitti | highvoltage: that's still not proven :) | 14:47 |
| slangasek | vibhav: thanks, I'll have a look at that a little later today | 14:47 |
| ev | pitti, mterry: ~canonical + ~ubuntu-bug-control | 14:47 |
| pitti | ah, thanks | 14:47 |
| ogra_ | highvoltage, dont trust news headlines ! | 14:48 |
| seb128 | mterry, what happens when you try to put that bug public? | 14:48 |
| mterry | ev, do you happen to know why I wouldn't be able to adjust the privacy of a bug? | 14:48 |
| mterry | seb128, I don't even see the 'edit' icon to change the privacy | 14:48 |
| mterry | seb128, it just says it's private | 14:49 |
| ev | mterry: no idea - definitely not a change that I've introduced | 14:49 |
| ev | mterry: ask in #launchpad-dev? | 14:49 |
| mterry | k | 14:49 |
| pitti | seb128: can you see the edit button? | 14:49 |
| seb128 | 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 |
| seb128 | pitti, ^ | 14:49 |
| seb128 | click on it | 14:49 |
| seb128 | you should get a list | 14:49 |
| pitti | from my part it might be anything between ~ubuntu-core-dev or ~techboard | 14:49 |
| seb128 | it's the new merge of security & private status | 14:50 |
| seb128 | pitti, mterry: http://blog.launchpad.net/general/how-bug-information-types-work-with-privacy | 14:50 |
| mterry | seb128, no I don't see it | 14:50 |
| seb128 | mterry, the one one those screenshots? | 14:50 |
| seb128 | mterry, ok, I see it, maybe you are lacking privileges or something but that seems weird | 14:50 |
| pitti | mterry: are you in ~ubuntu-bug-control? | 14:51 |
| * mterry is ~canonical and ~core-dev, what more do I need | 14:51 | |
| seb128 | pitti, do you have the ui? | 14:51 |
| pitti | seb128: yes, I do | 14:51 |
| pitti | mterry: that should suffice | 14:51 |
| mterry | OK, so sounds like a bug maybe. I've asked in #launchpad-dev, will report back | 14:52 |
| seb128 | mterry, you should ask on #launchpad I guess | 14:52 |
| seb128 | mterry, cool | 14:52 |
| seb128 | mterry, bug #1007588 btw is your issue | 14:53 |
| ubottu | 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 |
| seb128 | 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 |
| mterry | seb128, that looks like the same trace, but I'm just on my laptop. No external monitor | 14:54 |
| mterry | seb128, I've had it for a while, really annoying, so I started looking into it :) | 14:55 |
| mterry | 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 |
| seb128 | 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 |
| mterry | seb128, ah, makes sense | 14:56 |
| mterry | seb128, guess I'll mark the other one as a dup | 14:57 |
| seb128 | mterry, yeah, I blame the toolchain, I don't think the GNOME stack changed | 14:57 |
| seb128 | mterry, I just did that | 14:57 |
| mterry | kthx | 14:57 |
| mterry | Well, a simple rebuild didn't fix it (and g-s-d has been rebuilt already in quantal anyway). | 14:58 |
| mterry | doko, do you know much about "@plt" (procedure linkage table)? | 14:59 |
| seb128 | slangasek, pitti: could somebody accepted my mail from today to the tb list? | 15:03 |
| pitti | seb128: can do | 15:03 |
| seb128 | pitti, danke | 15:03 |
| doko | mterry, we have a new expert for glibc and dynamic loading ;) /me waves at infinity | 15:03 |
| mterry | infinity, hi! When you have a few moments, can you help me with bug 1007588? | 15:04 |
| ubottu | 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:04 |
| doko | didrocks, how ready is oneconf for Python3? | 15:05 |
| didrocks | doko: well, I'll need to do the porting at the same time than software-center | 15:06 |
| didrocks | doko: as it's imported from it | 15:06 |
| didrocks | doko: will be quite easy, few days | 15:06 |
| didrocks | doko: btw, I asked you a question this morning here | 15:06 |
| didrocks | doko: it was about chris email on ubuntu-devel for sigc++ | 15:06 |
| chrisccoulson | doko, thanks | 15:07 |
| chrisccoulson | did you mean to direct that at didrocks too? | 15:07 |
| chrisccoulson | seems it went to the wrong person :) | 15:07 |
| didrocks | I didn't receive anything if something was sent :) | 15:08 |
| chrisccoulson | didrocks, ah, you were offline | 15:08 |
| chrisccoulson | <doko> 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 |
| didrocks | chrisccoulson: my internet connection dropped for 5 minutes, yeah | 15:08 |
| chrisccoulson | ^didrocks | 15:08 |
| didrocks | thanks :) | 15:08 |
| doko | 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 |
| didrocks | doko: ok, we are totally in that case (the first one of the new M_size member) | 15:09 |
| didrocks | doko: oh, and we ship both? | 15:10 |
| doko | no, it's in the same shared object | 15:10 |
| arges | 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 |
| didrocks | doko: oh nice, is there a recipe to ensure to take the right functions then, can you give some links? | 15:10 |
| doko | didrocks, no I don't have any :-/ | 15:11 |
| didrocks | I think we'll need a way for sigc++ for this | 15:11 |
| cjwatson | arges: usually a transparent proxy getting in the way - find appropriate Release/Release.gpg/Packages URLs and wget --no-cache them | 15:12 |
| didrocks | doko: do you think you will have some time allocated for looking at this? it seems you are the most knowledgeable for this | 15:12 |
| arges | cjwatson, ok i'll try that | 15:13 |
| hippiehacker | 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 |
| doko | didrocks, will do after our virtual Python3 sprint (which ends Wed). | 15:13 |
| didrocks | doko: thanks :) | 15:14 |
| hippiehacker | more specifically I'd love to find the ppa / live-build config that created http://hwe.ubuntu.com/uds-q/dellxps/ | 15:16 |
| infinity | 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:18 |
| mterry | 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:19 |
| hippiehacker | 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:24 |
| superm1 | vanhoof: ^ | 15:26 |
| hippiehacker | superm1: thanks, I'll reach out to him | 15:28 |
| superm1 | sure | 15:28 |
| === fenris is now known as Guest99220 | ||
| infinity | mterry: Where's this u-m branch of yours without a-u-t? | 15:32 |
| mterry | infinity, https://code.launchpad.net/~mterry/update-manager/drop-auto-tester | 15:32 |
| infinity | mterry: Danke. | 15:32 |
| === Guest99220 is now known as ejat | ||
| mvo | mterry, infinity: stgraber was asking about this earlier too, please sync to ensure to not dupe work :) | 15:45 |
| mterry | mvo, about the auto-tester stuff? Or the crasher in @plt? | 15:46 |
| mvo | mterry: the auto-tester | 15:47 |
| mvo | mterry: not sure I know about the crasher | 15:48 |
| mterry | mvo, yar no biggie, it was just something infinity and I talked about a few minutes ago. | 15:48 |
| mterry | mvo, OK. stgraber: I've got a branch already to drop auto-tester, if you were looking into that. Same for release-upgrader | 15:48 |
| mterry | mvo, I've got branches for your review, man! | 15:49 |
| mterry | They're piling up | 15:49 |
| stgraber | 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 |
| mterry | stgraber, ah awesome. I was under the impression that lp:auto-upgrade-testing was more-up-to-date. Thanks for the catch | 15:50 |
| stgraber | mterry: it partly was, which made the merge "interesting" :) | 15:51 |
| * cjwatson whines idly about the practice of splitting things off without finishing the job :) | 15:53 | |
| infinity | 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 |
| infinity | mterry: What's this about release-upgrader getting the same treatment? :P | 15:54 |
| cjwatson | Not finishing the job there is especially irritating since I've been piling up the commits there pretty rapidly. | 15:54 |
| cjwatson | I mean, I vaguely knew about the split, but I had to pick one side or the other to commit on ... | 15:55 |
| stgraber | 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:58 |
| infinity | 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 |
| infinity | stgraber: (Well, everything up to the commit where I removed it all) | 15:59 |
| stgraber | infinity: yes | 16:02 |
| cjwatson | 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:02 |
| mterry | infinity, https://code.launchpad.net/~mterry/update-manager/split-release-upgrader | 16:04 |
| mvo | 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:04 |
| mvo | cjwatson: so that its not a API change | 16:05 |
| mvo | cjwatson: but I guess you are not the right perosn to ask this question :) | 16:05 |
| mvo | pitti: ---^ ? | 16:05 |
| infinity | mterry: Check, found it. Do we already have a new project and source package for release-upgrader? | 16:05 |
| mterry | infinity, (paired with https://code.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/split) | 16:05 |
| mterry | infinity, I was waiting on review before pushing to ubuntu | 16:05 |
| ScottK | 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:05 |
| mvo | 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 |
| pitti | mvo: that actually was (and still is) the plan indeed | 16:06 |
| pitti | mvo: I wasn't aware that anyone actually uses this | 16:06 |
| pitti | it seemed like a very unusual thing to use from Python | 16:06 |
| cjwatson | mvo: I agree and I whined in the upstream bug | 16:06 |
| cjwatson | mvo: But we might as well avoid it anyway | 16:07 |
| mvo | fair enough | 16:07 |
| infinity | 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:07 |
| * pitti waves good night | 16:08 | |
| mterry | infinity, yeah, the release upgrader split is more complicated | 16:08 |
| infinity | mterry: Looks like, yeah. | 16:11 |
| larsduesing | good night, pitti :-) | 16:14 |
| slangasek | 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 |
| slangasek | mvo: I know you mentioned a while ago that you had staged the merge, but it still seems not to be uploaded to quantal :) | 16:26 |
| === smb` is now known as smb | ||
| maca | Hola | 16:32 |
| maca | 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:34 |
| infinity | 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 |
| vibhav | maca: Realmente podría ayudar si usted puede hablar en Inglés :) | 16:36 |
| maca | ok, I thought that channel was Spanish | 16:37 |
| maca | Let see | 16:37 |
| slangasek | you're in #ubuntu-devel, English is the common language here :) | 16:37 |
| slangasek | infinity: you're just fishing for a reason for the dpkg merge to be on topic for the python3 sprint, aren't you ;) | 16:37 |
| infinity | slangasek: Maaaaaybe. | 16:38 |
| vibhav | Could anybody have a look at https://bugs.launchpad.net/ubuntu/+source/audit/+bug/1011693 ? | 16:38 |
| ubottu | Launchpad bug 1011693 in audit (Ubuntu) "Please merge audit 1:1.7.18-1.1 (universe) from Debian sid (main)" [Undecided,New] | 16:38 |
| maca | I would like to contribute fixing bugs, but I don't have experiences on programming. And I don't know how to start. So, I wondered if you can give me a way to learn fixing bugs... | 16:38 |
| infinity | slangasek: Actually, I was thinking it may depend on dpkg --assert-multi-arch (which it does), but I forgot that our dpkg has that bit. | 16:42 |
| slangasek | infinity: right | 16:42 |
| infinity | I see no other obvious "new dpkg" dependencies in the new apt, so I withdraw my previous guesses. | 16:42 |
| slangasek | mvo: btw, the prepare-release script throws an xmllint usage error in lp:~ubuntu-core-dev/apt/ubuntu/ because there are no translated xml files present, only .po files... am I doing something wrong? | 16:47 |
| === fenris is now known as Guest94326 | ||
| === Guest94326 is now known as ejat | ||
| slangasek | mvo: oh, perhaps the prepare-release hook assumes that I'm not doing a -S build ;) ok, ignoring | 16:53 |
| Daviey | ScottK: Yeah, i spoke before i read -devel.. I haven't responded.. but have been thinking about it.. I can't see that server product requires it.. and without another flavour requiring it; if the delta is cheaper to maintain than cpython (i'm betting it is).. i think diverge | 16:55 |
| Daviey | ScottK: what do you think? | 16:56 |
| ScottK | The downside is you end up not regenerating the generated sources and you may discover later you need an SRU/security fix and you can't do it. | 16:56 |
| ScottK | IIRC it's used in the cloud images, so it's serverish. | 16:57 |
| === zyga is now known as zyga-afk | ||
| Daviey | ScottK: It's currently blocking (dep-waiting) something else IIRC.. so perhaps we sould diverge until we define if we need it? | 17:03 |
| ScottK | By the time we know, it'll be too late if it's after release. | 17:05 |
| Daviey | ScottK: Maybe i am being dumb.. but what does it bring to the table? | 17:07 |
| ScottK | Which? | 17:07 |
| Daviey | ScottK: using cpython with this package | 17:08 |
| Daviey | (you know this package far more than i do :) | 17:08 |
| ScottK | The file ext/_yaml.c is generated from _yaml.pxd and _yaml.pyx. | 17:11 |
| ScottK | Or one of them. | 17:11 |
| ScottK | In any case, when you patch one of those files you need to regenerate _yaml.c. | 17:11 |
| ScottK | You need cython to to that. | 17:11 |
| ScottK | If you don't regenerate it each time you build it, then you really have no idea if you can or not. | 17:12 |
| ScottK | So you can end up in a situation where it's very difficult to fix any issues that come up post release (you end up patching generated source). | 17:12 |
| Daviey | ScottK: Hmm, i know with eucalyptus there was a tool to generate some of the code.. and that was used outside of packaging.. | 17:13 |
| === yofel_ is now known as yofel | ||
| Daviey | So really, as a developer.. i can have cpyton on my machine.. regenerate _yaml.c... and upload, with a new patch? | 17:13 |
| ScottK | Also if you haven't generated the _yaml.c that you're shipping the in the binary then there's freeness questions related to distributing the preferred form of modification. | 17:13 |
| ScottK | If it works with the current cython, yes. | 17:14 |
| ScottK | When it's in the package build you find out each time you do an archive rebuild. | 17:14 |
| Daviey | I think generating a file on a workstation vs. generating in the archive, using the same tools eradicates the licencing questioning IMO | 17:14 |
| ScottK | As long as you can. | 17:15 |
| Daviey | (IANAL, etc) | 17:15 |
| ScottK | Although I'm an Ubuntu developer, I'm really much more like in the position of a normal Debian developer here. I don't know how pyyaml gets used in Ubuntu, so it's hard to advise. | 17:15 |
| Daviey | ScottK: In any case, i'd be able to do an SRU/Sec upload.. by /somehow/ generating a new file on my workstation, rather than archive.. right? | 17:16 |
| ScottK | The technically correct answer is promote cython. Now someone has to decide. | 17:16 |
| ScottK | If it was possible to generate it with the cython version in the archive. Until you tried, you'd have no idea. | 17:16 |
| Daviey | ScottK: and generating it from one outside of the archive? | 17:18 |
| ScottK | I guess. | 17:18 |
| Daviey | ScottK: I'm really not keen to advocate a MIR that we can avoid, as we have already put too much burden on Security team for the last few cycles as is. | 17:19 |
| Daviey | That said, if there is another flavour wanting it.. then i'm all for it. | 17:20 |
| slangasek | there was the discussion @ UDS regarding archive reorg where we said that ideally we would stop having to do MIRs for things that are just build-dependencies | 17:20 |
| Daviey | The question remains to me, is what is best use of time.. maintaining a delta and the risk of some tomfoolery to do uploads.. or maintaining something i'm not sure we need. | 17:20 |
| slangasek | but that requires new tooling as a prereq | 17:20 |
| Daviey | slangasek: the moment you said, archive-reorg, that added 2 years to the blueprint... you should have left that string out. | 17:21 |
| ScottK | Daviey: If someone else wants to maintain a diff, I don't object, but I think it's not technically the best answer. | 17:21 |
| slangasek | um | 17:21 |
| jtaylor | somewhat related, is it a good idea to build two packages from the same source? one in main one in universe, context is fftw3 which now adds mpi | 17:26 |
| Daviey | jtaylor: good idea? if you are using the same src upload, you can have some binaries in main, and others in universe.. but the whole build-dep list still needs to be in main... but i guess you knew that. | 17:27 |
| Daviey | jtaylor: I think you'll need two src uploads to do what you want. | 17:27 |
| jtaylor | thats the issue | 17:27 |
| jtaylor | it has a build dep on mpi | 17:28 |
| Daviey | slangasek: Do you have thoughts on this pyyaml issue? | 17:28 |
| slangasek | jtaylor: we've been stripping mpi support out for years to avoid pulling it into main, fwiw | 17:29 |
| slangasek | Daviey: only that I wish archive reorg was farther along so we could sidestep it | 17:29 |
| slangasek | I don't think cython should be a major support version in any case | 17:29 |
| jtaylor | striping out is one option | 17:29 |
| jtaylor | but I'd like to over it | 17:29 |
| jtaylor | (providing that mpich2 gets fixed in quantal) | 17:30 |
| slangasek | Daviey: so would tend to prefer keeping the cython build-dep in and promoting to main | 17:30 |
| slangasek | but that's for the MIR team to decide... | 17:30 |
| Daviey | slangasek: right, but the MIR team will surely want an advocating team to take on bug subscriptions.. | 17:30 |
| Daviey | and i'm trying to work out if my team want to advocate it :) | 17:31 |
| slangasek | I don't think that's true | 17:31 |
| slangasek | I've had many an MIR approved where I said "we aren't looking at bugs on this, we're in sync with Debian" | 17:31 |
| Daviey | slangasek: ok, fair enough.. It seemed to me that having a team care for a package had turned into almost mandated criteria. | 17:32 |
| slangasek | well, some team would have to "own" it being in main, but that doesn't actually translate to doing anything with it, in many cases | 17:33 |
| slangasek | I suppose you have to decide how you feel cython showing up under the server team's name given that pyyaml is yours, yes :) | 17:34 |
| Daviey | slangasek: well this is what i am saying?! | 17:34 |
| slangasek | no, you said something about bug subscriptions | 17:34 |
| Daviey | own == advocate .. | 17:34 |
| slangasek | "own" == "you're the go-to people if there's a problem" | 17:34 |
| slangasek | but if you think there'll never be a problem? | 17:35 |
| Daviey | Yes.. and this is what i am trying to convey. | 17:35 |
| === smoser` is now known as smoser | ||
| ScottK | jtaylor: Have a look at boost1.49 and boost-mpi-source1.49 to see what fun you can have due to MPI | 17:37 |
| === dendrobates is now known as dendro-afk | ||
| jtaylor | ScottK: you mean that as just an example or negative example why not do do it? | 17:40 |
| ScottK | It's an example. | 17:41 |
| ScottK | You may look and run screaming or decide "meh, I can do that". | 17:41 |
| jtaylor | k, I'll probably do that then | 17:41 |
| jtaylor | fftw3 is no 46mb source package :) | 17:41 |
| jtaylor | though that means that its probably me who has to fix mpich2 ._. | 17:42 |
| micahg | jtaylor: libav and libav-extra is another example | 17:44 |
| jtaylor | libav has mpi bindings o_O | 17:45 |
| Daviey | ScottK, slangasek: I'm going to open a MIR tracking bug, although i'm not strongly advocating it.. but we should have it referenced there. | 17:58 |
| Daviey | mdeslaur: I'd like the security teams input on there aswell, to give the MIR team as much info as possible to decide. | 17:58 |
| ScottK | Daviey: It would, in theory, be possible to briefly promote cython to Main to get past the depwait and then demote it again. Then you get past the block and there's no diff. | 17:59 |
| mdeslaur | Daviey: sure | 17:59 |
| Daviey | ScottK: ooo, good point.. but doing that dance for SRU/Security sounds REALLY nasty :) | 18:00 |
| ScottK | Daviey: Agreed. I was just thinking about getting past the current blockage while the MIR is decided. | 18:01 |
| Daviey | *sigh*.. MIR team are going to hate me.. I already have 10 pending MIR's | 18:01 |
| Daviey | Oh, ffs.. this issue is academic.. it already has an approved MIR .. bug 299870 | 18:03 |
| ubottu | Launchpad bug 299870 in cython (Ubuntu) "MIR for cython" [Undecided,Fix released] https://launchpad.net/bugs/299870 | 18:03 |
| Daviey | 2008.. but i assume it still holds true.. | 18:03 |
| ScottK | If it was in Main before it can be repromoted, no problem. | 18:04 |
| Daviey | mterry/doko: you agree | 18:05 |
| Daviey | ? | 18:05 |
| infinity | I have no issues promoting it if it was in main previously. | 18:05 |
| * mterry reads back | 18:05 | |
| * micahg would think it would depend if the code was totally rewritten or not (possible new security concerns) (has been in universe since at least lucid) | 18:05 | |
| Daviey | mterry: Approved MIR from 2008, fell out of Main.. happy for it to be repromoted based on that? | 18:06 |
| infinity | Looks like it's just incremental versions from way back when. | 18:06 |
| mterry | Daviey, yeah sure. 2008 is quite a while ago, so it's possible it could have gotten worse maintained... but we're in sync with Debian, seems fine | 18:07 |
| Daviey | super, thanks | 18:07 |
| mterry | No crazy bugs in Debian that I can see | 18:08 |
| lifeless | fwiw | 18:10 |
| lifeless | bzr uses pyrex/cython | 18:10 |
| lifeless | so having cython in main could be quite nice | 18:10 |
| * infinity makes it so. | 18:13 | |
| cousteau | interesting, didn't know | 18:14 |
| * cousteau should take Cython again | 18:14 | |
| micahg | infinity: problem is that cython needs python-support, someone needs to remove that before it can be promoted | 18:16 |
| Daviey | infinity: you just promoted ? | 18:16 |
| * micahg took a look at it, but got stuck over the weekend | 18:17 | |
| infinity | micahg: Oh, well. Pls fix. ;) | 18:17 |
| micahg | ScottK: ^^ can you fix? | 18:17 |
| xnox | Daviey: what is pyyaml used in again? and didn't like pyyaml was on the way out of server responsibility due to "don’t use yaml to marshall data in and out of zookeeper" | 18:17 |
| micahg | ScottK: or are you just the pyyaml person? | 18:17 |
| xnox | from the juju scaling excercise | 18:17 |
| ScottK | micahg: Just the pyyaml person. | 18:18 |
| ScottK | I think jtaylor should fix that and push it upstream. | 18:18 |
| micahg | sounds good to me :) | 18:18 |
| micahg | jtaylor: I have a starter debdiff if you like | 18:18 |
| * infinity hovers over the "demote again" button. | 18:18 | |
| * Nafallo hovers over infinity | 18:19 | |
| micahg | infinity: well, if you only promoted cython and not python-support, it's fine, the first person who wants to build it has to fix it :) | 18:19 |
| infinity | micahg: s/build/install/ | 18:20 |
| micahg | infinity: hrm, that too :(, I guess it doesn't work | 18:20 |
| infinity | micahg: It's going to pop python-support on component-mismatches, so there'll be plenty of yelling about that. :P | 18:20 |
| Daviey | xnox: blame smoser. | 18:20 |
| * micahg takes another quick look | 18:21 | |
| Daviey | xnox: cloud-init is at least one consumer that jumps out at me. | 18:21 |
| ScottK | Actually I bet barry might fix cython. | 18:21 |
| xnox | Daviey: ok | 18:22 |
| smoser | well, clearly anything that fell out of favor in juju should be stricken from the universe. | 18:22 |
| micahg | well, one of the issues is that it doesn't seem dh_python2 ready (installs in site-packages still) | 18:22 |
| * cousteau doesn't know what Cython is used for, other than Sage, Bazaar, and, well, his own bachelor thesis | 18:23 | |
| micahg | cousteau: http://paste.ubuntu.com/1035926/ | 18:24 |
| cousteau | wow... that kinda sums all up | 18:25 |
| micahg | cousteau: reverse-depends src:cython -b (from ubuntu-dev-tools) | 18:25 |
| cousteau | anyway, I don't see any project I know about there, other than bzr | 18:26 |
| cousteau | (and maybe compizconfig) | 18:26 |
| arges | pitti, hello. I have a debian patch for pyppd that fixes a ftbfs build issue with python3. http://people.canonical.com/~arges/plusone/pyppd_python3_build_fix.debdiff . Let me know if you'd like to see changes or have questions. thanks | 18:49 |
| Laney | doko: Would you be overly unhappy if I switched mono to gcc-4.6 to fix the armel ftbfs? | 19:21 |
| Laney | "fix" | 19:22 |
| * micahg wonders if infinity made any progress on that ^^ | 19:22 | |
| Laney | Also, I want to look at dropping a .la file. Is there any better than manual way of checking rdeps? | 19:25 |
| micahg | Laney: lintian lab grep? | 19:25 |
| Laney | don't you need binaries? | 19:25 |
| slangasek | mterry: ping | 19:26 |
| * micahg thought the lintian lab had the binaries as well | 19:26 | |
| Laney | maybe it does | 19:26 |
| Laney | broder: does it? If so, can I have access please? :-) | 19:26 |
| infinity | Laney: Does switching to 4.6 magically make it happy? | 19:27 |
| slangasek | mterry: xnox has pointed out that libconfig in Ubuntu carries a delta to Debian for a .symbols file, apparently as a result of https://bugs.launchpad.net/ubuntu/+source/libconfig/+bug/730760/comments/2 | 19:27 |
| ubottu | Launchpad bug 730760 in libconfig (Ubuntu Natty) "[MIR] b-d for libffado" [High,Fix released] | 19:27 |
| Laney | infinity: The test build is in progress, so we will see | 19:27 |
| Laney | but it has progressed past the previous point of failure | 19:28 |
| infinity | Laney: If it does, I'm okay with that as a temporary solution. It also gives me a bit of a pointer as to where to look later for what's gone wrong. | 19:28 |
| slangasek | mterry: can you clarify where this requirement comes from? I don't find .symbols files mentioned in the MIR wiki pages, and although I'm a staunch advocate of .symbols files as part of responsible library maintenance, I think this is a silly thing for us to carry a delta from Debian over | 19:28 |
| Laney | we'll be able to compare the test suite summaries too | 19:28 |
| micahg | oh wait, infinity was looking at ghc, not mono :) | 19:28 |
| infinity | micahg: I'm looking at neither right now, but both are on my "to be grumpy about" list. | 19:29 |
| doko | Laney, what was the context? | 19:30 |
| mterry | slangasek, sorry, was afk. reading | 19:30 |
| micahg | infinity: well, the whole haskell stack is not installable at the moment in quantal, is there someone else with a shorter to be grumpy about list that can poke at ghc? | 19:30 |
| Laney | doko: That mono fails with 4.7 on armel but looks to be OK using 4.6 | 19:30 |
| Laney | I thought you might be interested in knowing. | 19:31 |
| doko | ugh, and works on armhf? | 19:31 |
| infinity | micahg: That's only on armel. | 19:31 |
| Laney | builds at least. | 19:31 |
| Laney | apparently it is busted in some important ways, but I am not sure that is related to the compiler | 19:31 |
| micahg | infinity: yes, but as you'll need a rebuild anyways to fix armel, any rebuilds now is just a waste | 19:31 |
| Laney | the new GHC which is going to experimental soon is supposed to work properly on arm | 19:32 |
| Laney | I don't know if that extends to the failures we're seeing | 19:32 |
| micahg | Laney: is it close enough to just wait? | 19:32 |
| infinity | Laney: The failure we're seeing doesn't directly relate to GHC, I suspect. | 19:32 |
| Laney | indeed | 19:32 |
| mterry | slangasek, I usually block a MIR on either a .symbols file or argument-less -V to dh_makeshlibs. On the theory that it makes less trouble for main as a whole vs the delta effort (and usually we don't end up carrying such a delta for long -- Debian likes such patches) | 19:32 |
| infinity | Laney: I just need a few spare cycles to look at it. :/ | 19:33 |
| Laney | I was also going to try the 4.6 trick there | 19:33 |
| mterry | slangasek, that's standard MIR practice as far as I know. Though it may not be written in the Requirements bit | 19:33 |
| Laney | but the FTBFS looks like something that an ARM-head would be able to make something of | 19:33 |
| slangasek | mterry: if it's not written in the requirements, I don't think it's standard ;) And I don't think this requirement is grounded in Ubuntu best practices... | 19:33 |
| slangasek | like I said, .symbols are the right thing to do, but they should be done upstream in Debian | 19:34 |
| slangasek | it's not worth a delta over | 19:34 |
| infinity | Laney: The FTBFS for ghc in Ubuntu is very much Ubuntu-specific. I just haven't had time to figure out why. | 19:34 |
| Laney | OK | 19:34 |
| Laney | we previously had to have it prod different options into llvm | 19:35 |
| mterry | slangasek, I didn't make the practice up. Can't remember who I got it from. If it's a matter of the Debian maintainer refusing the patch and it being the only delta, I'd tend to agree. But there's no harm in carrying the delta for a while until Debian does | 19:35 |
| slangasek | mterry: I'm confused as to what problems you expect to be solved by .symbols/dh_makeshlibs in practice | 19:35 |
| infinity | Laney: Wait, does Debian's ghc package know about Ubuntu? | 19:36 |
| infinity | Laney: As in, is it guessing that ubuntu/armel is armv7 and then doing Very Bad Things? If so, the failure is obvious. | 19:36 |
| slangasek | mterry: well, I think whoever you got it from should've been responsible for adding it to the MIR Process wiki pages! :-) | 19:36 |
| infinity | Laney: I hadn't looked that far yet, I just scratched my head over the same source working in Debian/armel but not Ubuntu/armel. | 19:36 |
| Laney | infinity: nope | 19:38 |
| Laney | http://anonscm.debian.org/cgi-bin/darcsweb.cgi?r=pkg-haskell/ghc;a=headblob;f=/rules (what is up with that syntax highlighting?) | 19:38 |
| mterry | slangasek, well, you must know some of the problems they solve, since you say they are a good idea, but in my words, it's good for people updating the package to ACK API additions (and more importantly drops!), and it's good for users upgrading packages because having maintainers manually handle the correct versions is prone to failure. And possibly some other benefits I'm not entirely aware of at an archive-admin level | 19:39 |
| infinity | Laney: Where is the "use llvm instead of gcc" decision made? I don't see that in rules... | 19:40 |
| mterry | slangasek, and it's in general a symptom of a well-maintained package, which is always a signal the MIR team likes to see (and if we add it, whether Debian maintainers accept it is a good signal) | 19:40 |
| slangasek | mterry: right, presence of symbols --> well-maintained, but the converse does not follow :) In this case we have a delta only for the .symbols file; and the ABI is being well-maintained upstream (in fact, it's an ABI transition due to a new soname) | 19:42 |
| slangasek | mterry: what do you advise in this case? | 19:42 |
| mterry | slangasek, (right, but as I said, if Debian accepts our patch in good order, that's a hindsight-verification of good maintainership) :) I haven't looked at this specific case yet. (will do so in a sec) Have we passed the patch to Debian? | 19:43 |
| slangasek | mterry: the patch has been sent to Debian but not integrated | 19:43 |
| Laney | infinity: AFAIK LLVM support is built if you have opt/llc when building GHC, and is the default backend on arm | 19:43 |
| slangasek | I think we're better off dropping the delta for now, since that makes busywork for us, and taking the discussion about .symbols to Debian | 19:44 |
| Laney | so all Joachim did was add it as a build-dep | 19:44 |
| infinity | Laney: Ahh, it's just autodetected if it's in the chroot. I see. | 19:44 |
| infinity | Laney: (In that case, you should build-conflict llvm on !arm) | 19:44 |
| Laney | Why? We want the LLVM backend to be available there. | 19:45 |
| infinity | Laney: While I'm all for hunting this down and fixing it soonish, was there a reason to switch from a compiler that doesn't suck to llvm for only one arch? :P | 19:45 |
| Laney | it only changes the default on ARM | 19:45 |
| infinity | Laney: Eh? Only arm build-deps on llvm, that means you want !arm to not have it, or it'll use that by default. | 19:45 |
| Laney | on other arches you get an extra backend, selected by -fllvm | 19:46 |
| infinity | Oh. I guess I've not found where that's happening. | 19:46 |
| infinity | Laney: Oh, ffs. | 19:48 |
| infinity | Laney: I think it's as simple as the package doing detection based on uname. | 19:48 |
| infinity | Laney: All our buildds are armv7. The Debian armel buildds are armv5. | 19:48 |
| * infinity head->desks. | 19:48 | |
| infinity | That should be simple enough to hunt and fix. | 19:48 |
| mterry | slangasek, we also tend not to require them for C++ just because that adds to the burden, not diminishes it. I see this is at least partly C++. And if we might to waive the requirement for one of the bindings, seems even less reasonable to make the C-bindings do it. Sure, sync it up. | 19:51 |
| infinity | Laney: Or maybe not. *scratch head* | 19:51 |
| infinity | Laney: I dunno, I'll look at it a bit later. | 19:52 |
| mterry | slangasek, I'm not convinced it's a bad idea in general though to carry a delta for symbols | 19:52 |
| mterry | slangasek, I believe the last time the MIR team talked about it at a UDS, it was considered an appropriate thing to require | 19:52 |
| slangasek | mterry: well, it doesn't seem to have ever made it into the documentation and been subjected to wider scrutiny as an enforced requirement... I'd definitely like us to be able to fix that | 19:53 |
| slangasek | mterry: who should I pester into leading a public discussion about that? | 19:53 |
| Laney | infinity: I'll leave it in your capable hands :P | 19:53 |
| slangasek | xnox: ^^ regardless, mterry seems to be saying here that a sync is ok for libconfig | 19:54 |
| infinity | Laney: My hands appreciate your vote of confidence. The rest of me, not so much. | 19:54 |
| infinity | slangasek, xnox: synced. ;) | 19:54 |
| Daviey | slangasek: it's something we've done numerous times for MIR. | 19:57 |
| mterry | slangasek, let me ask the rest of the MIR team to double-confirm that I'm not off the rails here. :) If it is an undocumented nigh-requirement, I can email ubuntu-devel and raise your concern that it be vetted | 19:57 |
| Daviey | i seem to remember debian always taking it tho | 19:57 |
| mterry | Yeah, usually they love it. Who wouldn't | 19:57 |
| mterry | slangasek, I would just add it to the wiki, but you seem like you feel it's an unreasonable ask? | 19:58 |
| Daviey | mterry: pls give us a mir-review script :) | 19:58 |
| slangasek | Daviey, mterry: I'm perfectly fine with an MIR requirement that we push a patch to Debian for the .symbols... I just don't think we should be carrying a delta for this as an MIR requirement | 19:58 |
| slangasek | mterry: yes, I want a public discussion so that I can have it on record why I think this isn't a good thing ;) | 19:59 |
| mterry | Daviey, I did just create a wiki page for MIR team members to help unify practices. It might be useful to know the kind of things we look at: https://wiki.ubuntu.com/MIRTeam | 19:59 |
| * Daviey dusts off his soap box and passes it to slangasek | 19:59 | |
| slangasek | though we're also rapidly approaching the point of diminishing returns by discussing it ;) | 20:00 |
| infinity | doko: Want to reactivate me in ~ubuntu-mir, and I'll totally sort them out. :) | 20:02 |
| === chu_ is now known as chu | ||
| === salem_ is now known as _salem | ||
| === dendro-afk is now known as dendrobates | ||
| === cmagina-lunch is now known as cmagina | ||
| === myrtti is now known as Myrtti | ||
| === BenC_ is now known as BenC | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
