| luv | pitti: yo! can you please give me a shout when online? It's regarding https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1063617 (I see you raised it originally) | 00:06 |
|---|---|---|
| ubottu | Launchpad bug 1063617 in compiz (Ubuntu) "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,Confirmed] | 00:06 |
| luv | I already found two bugs in the compizconfig related to it. Doing more tests now. I will post a patch later this week. | 00:07 |
| === sz0 is now known as sz0` | ||
| === sz0` is now known as sz0 | ||
| === sz0 is now known as sz0` | ||
| === wgrant changed the topic of #ubuntu-devel to: Launchpad offline 06:00 - 06:30 UTC | Trusty Final released! | Archive: Open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| zyga | hello | 05:37 |
| zyga | I have a .crash file, how can I add it to a launchpad bug report so that the various useful bots do their thing? | 05:38 |
| zyga | I don't have access to the original machine anymore | 05:38 |
| TheMuso | zyga: Perhaps unpack the crash file and upload the components as separate files manually? | 05:51 |
| infinity | zyga: You can pass a .crash file as an argument to ubuntu-bug(1). | 05:57 |
| wgrant | Or apport-collect, if the bug already exists. | 05:57 |
| pitti | Good morning | 05:57 |
| pitti | mapreri: right, that sounds urgent, will upload | 05:58 |
| pitti | luv: *shout* :) | 05:58 |
| zyga | thanks | 05:59 |
| zyga | It looks like Qt5 crash on some deep internals | 05:59 |
| zyga | hmm | 05:59 |
| zyga | apport-collect rejects any action as I'm not the one who filed the bug | 06:00 |
| zyga | TheMuso: can the .crash file be unpacked with any tool or is that a manual process? | 06:01 |
| TheMuso | zyga: apport-unpack | 06:04 |
| zyga | thanks! | 06:06 |
| RAOF | Oh, arse. No autopkgtest for Debian experimental, I guess. | 06:07 |
| zyga | so if I got that unpacked now, how can I get apport retracer to recover symbols and everything? | 06:08 |
| RAOF | Also, boo, argyll is orphaned. | 06:08 |
| zyga | though I already see symbols I'd like to see more details | 06:08 |
| RAOF | zyga: Install apport-retrace, and it'll download the debugging symbols for you and give you a gdb session on the core. | 06:09 |
| zyga | thanks | 06:09 |
| zyga | RAOF: hmm, it borks on the bug (1318584) not having standard description format | 06:11 |
| zyga | RAOF: would it help if I were to upload all the unpacked crash files to the bug report? | 06:12 |
| zyga | (as attachments) | 06:12 |
| pitti | infinity: hey Adam | 06:28 |
| infinity | pitti: Yes dear? | 06:29 |
| pitti | infinity: could you put http://people.canonical.com/~pitti/tmp/eglibc.faster-autopkgtest.debdiff into eglibc's VCS? | 06:29 |
| pitti | infinity: that'd be lovely, honey | 06:29 |
| * pitti will do the same for the kernel now, which should shave off some 30 to 45 minutes from the test | 06:29 | |
| infinity | pitti: I can do that, sure. | 06:29 |
| === wgrant changed the topic of #ubuntu-devel to: Trusty Final released! | Archive: Open | Devel of Ubuntu (not support or app devel) | build failures -> http://qa.ubuntuwire.com/ftbfs/ | #ubuntu for support and discussion of lucid -> trusty | #ubuntu-app-devel for app development on Ubuntu http://wiki.ubuntu.com/UbuntuDevelopment | See #ubuntu-bugs for http://bit.ly/lv8soi | Patch Pilots: | ||
| pitti | apw: I have an updated autopkgtest for linux which makes the thing go 30 to 45 mins faster: http://people.canonical.com/~pitti/tmp/linux-autopkgtest/ | 06:39 |
| pitti | apw: I tried a debdiff, but debclean seems to have eaten my debian/changelog entry, so this just has the updated debian/tests dir and a proposed changelog entry | 06:40 |
| mitya57 | Mirv: When can I go ahead with qtwebkit update? | 06:48 |
| infinity | pitti: The changelog entry goes in debian.master/changelog, not debian/changelog. | 06:54 |
| infinity | pitti: Because the kernel is super special. | 06:55 |
| zyga | ara: hey | 06:59 |
| ara | zyga, good morning | 07:00 |
| === mbiebl_ is now known as mbiebl | ||
| === lubko is now known as goatlord | ||
| infinity | pitti: Does @builddeps@ work for Debian too? | 07:15 |
| hyperair | huh this is weird | 07:19 |
| hyperair | raring is EOL? | 07:19 |
| hyperair | launchpad was rejecting my uploads to raring | 07:19 |
| hyperair | in a PPA | 07:19 |
| hyperair | but quantal went through | 07:19 |
| hyperair | O_o | 07:19 |
| hyperair | i don't recall quantal being an LTS release | 07:19 |
| Unit193 | That's where they changed down to 9 months, Quantal just went EOL now too. | 07:20 |
| hyperair | oh right | 07:20 |
| infinity | hyperair: quantal will start rejecting soon. | 07:20 |
| hyperair | okay | 07:20 |
| infinity | hyperair: It was officially EOL on the 16th, but I haven't closed it in LP yet for reasons. | 07:20 |
| hyperair | i see | 07:21 |
| infinity | pitti: Taking your silence as a "yes" and committing. :P | 07:24 |
| Mirv | dbarth: mitya57 ^ asked about when he can upload qtwebkit 5.2 to utopic. can you think of a timeline at the moment when enough has migrated to oxide? | 07:27 |
| pitti | infinity: sorry, was OTP (meeting with the guys in Malta) | 07:27 |
| pitti | infinity: yes, autopkgtest has been in sync for ages, @builddeps@ works everywhere (also in ci.d.n) | 07:28 |
| infinity | pitti: Kay, cool. Committed upstream, then. We'll filter that down to Ubuntu after the next experimental upload and merge (which should be this week). | 07:30 |
| pitti | infinity: nice, thanks (it's not urgent) | 07:30 |
| pitti | the kernel seems to hit the copy timeouts way more often than eglibc | 07:30 |
| infinity | pitti: Yeah, I'm torn about all those tests. I like the rebuild tests for glibc/kernel/gcc/binutils because I'm intensely paranoid about any one of those breaking the others, but they're also crappy tests to be triggered by anything BUT the toolchain. | 07:31 |
| infinity | pitti: We were discussing in Austin that we'd really like a test stanza called "Triggers-By" or something, where these rebuild tests could be limited to specific packages instead of all rdeps. | 07:32 |
| pitti | yeah; at the moment the test doesn't know why it was triggered | 07:32 |
| pitti | passing that will get a lot easier in the AMQP based system | 07:32 |
| infinity | pitti: Which also has the added bonus that this wouldn't have to work by accident (ie: there's no reason any of these packages actually are rdeps of each other, since they're all build-essential, it's just a fluke that there happen to be enough versioned deps to make it work) | 07:33 |
| pitti | but not with our shoestring/rsync/jenkins machine | 07:33 |
| pitti | infinity: yeah, I think we introduced some technically unnecessary linux-libc-dev build dep (or similar) to trigger the reverse dep check | 07:33 |
| infinity | pitti: Oh, erk, I see the timeout you're talking about is why the current eglibc/amd64 failed. :/ | 07:40 |
| infinity | pitti: How likely is that to fail again if I retry? | 07:40 |
| pitti | infinity: I already retried an hour or so ago | 07:40 |
| infinity | I suppose I should just skiptest the thing(s) waiting on it, since I can read the log and see that it's fine. | 07:40 |
| pitti | infinity: rather unlikely | 07:40 |
| infinity | pitti: Oh, or you could retry. :P | 07:40 |
| infinity | Nothing's waiting on it but the kernel, and that build was fine, so I think I'll skiptest the kernel for now. | 07:41 |
| pitti | 1 hour 18 mins ago, to be precise (run #19) | 07:41 |
| pitti | the full run takes ~ 4 hours | 07:41 |
| infinity | Yeah, skipping. I want to see the britney results before I sleep. :P | 07:42 |
| pitti | infinity: yes, it's indeed the copying between VM and host which occasionally kills it (there's a timeout of 1 hour, and if the boxes are busy that might take that lnog) | 07:42 |
| pitti | and 9p is really crappy :( | 07:42 |
| infinity | I guess something like NFS is out of the question? | 07:42 |
| pitti | infinity: I'm afraid so; it has a lot of assumptions on the VM (working and unchanged networking, daemons running) and would also need root on the host side, doesn't it? | 07:43 |
| pitti | not sure if one can run an NFS server as user | 07:43 |
| infinity | pitti: Oh, yeah, you want root on the host to make it go, I suppose. | 07:44 |
| pitti | -ECANTHAVEROOT | 07:44 |
| pitti | if I had root on the host I could use nbd | 07:44 |
| pitti | and just mount the qemu imae | 07:45 |
| pitti | image | 07:45 |
| pitti | infinity: so at the moment 9p is still the bit which needs almost zero assumptions on the testbed and is still reasonably fast for most things | 07:46 |
| pitti | i. e. I'd like to be able to run autopkgtests against someone's production VM image (all in snapshotting mode of course), or the Ubuntu live system, or what not | 07:46 |
| michagogo | 10:21:11 <infinity> hyperair: It was officially EOL on the 16th, but I haven't closed it in LP yet for reasons. <--- How long do you expect that to be the case? Long enough to sneak in a fix for bug #1314616 ? | 07:47 |
| ubottu | bug 1314616 in bitcoin (Ubuntu) "[SRU] bitcoin to be maintained upstream in PPA: Replace distro archive "bitcoin" bitcoin with an empty dummy package" [Undecided,New] https://launchpad.net/bugs/1314616 | 07:47 |
| infinity | michagogo: Is there any point? it's EOL anyway. | 07:49 |
| infinity | michagogo: I assume the same bug existed in raring, and we're not fixing that either. | 07:49 |
| hyperair | michagogo: you can always upload to precise and have people in the intermediate releases use the precise PPA | 07:50 |
| michagogo | infinity: is it known (are there metrics or something) on how many users don't upgrade? | 07:50 |
| infinity | michagogo: If users don't upgrade, there's not much we can do for them. | 07:51 |
| michagogo | Actually, guessing not because I don't think I've noticed an option for it | 07:51 |
| michagogo | infinity: sure, but it would be interesting to know if there is actually a significant set of users running old unsupported releases | 07:52 |
| infinity | michagogo: There are people still running all sorts of weird old releases, yeap. | 07:53 |
| infinity | michagogo: I hear from time to time of people running maverick, natty, and oneiric, at least. But, like I said, not much we can do for people who ignore EOL notices and don't seem to care. | 07:53 |
| michagogo | infinity: I'm sure. I was more wondering, how many? | 07:53 |
| apw | pitti, like the sounds of that | 08:07 |
| pitti | apw: is the above enough, or do you need it in a different format? | 08:15 |
| apw | pitti, that is sufficient indeed thanks. your changelog woes are our layered debian thing, debian.<branch>/changelog ftw | 08:17 |
| zyga | anyone interested in what is apparently a Qt5 bug? | 08:18 |
| zyga | crash on 2nd monitor disconnect/reconnect | 08:18 |
| === doko_ is now known as doko | ||
| doko | infinity, before you merge eglibc the next time, please remove the systemtap b-d for ppc64el, nice surprises like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61231 | 08:49 |
| ubottu | gcc.gnu.org bug 61231 in target "[4.9/4.10 Regression] bootstrap comparision failure on powerpc64le-linux-gnu" [Normal,Unconfirmed] | 08:49 |
| apw | pitti, ok applied, will be in the next utopic upload | 08:53 |
| pitti | apw: very nice, thank you! | 08:53 |
| === sz0` is now known as sz0 | ||
| === locutus_ is now known as LocutusOfBorg1 | ||
| === goatlord is now known as stara_krava | ||
| zyga | cjwatson: do you know of any bugs on upstart leaking memory? | 09:04 |
| zyga | 3102 zyga 20 0 3129116 2,852g 1404 S 13,7 18,6 198:29.19 init | 09:04 |
| zyga | 3GB for upstart? | 09:04 |
| apw | zyga, what release is that ... | 09:04 |
| zyga | jodh: ^^ | 09:04 |
| cjwatson | zyga: -> jodh | 09:04 |
| apw | jodh, ^ | 09:04 |
| zyga | apw: utopic | 09:04 |
| zyga | one day uptime | 09:05 |
| cjwatson | zyga: (I haven't heard of such a thing though) | 09:06 |
| cjwatson | zyga: Oh, there's bug 1235649 | 09:06 |
| ubottu | bug 1235649 in unity (Ubuntu Saucy) "uevent spam causes libdbus client code in session upstart to consume massive amounts of memory on Ubuntu Touch" [Undecided,Confirmed] https://launchpad.net/bugs/1235649 | 09:06 |
| cjwatson | But that should be fixed in the packages | 09:06 |
| zyga | seems like something new then | 09:07 |
| === vrruiz_ is now known as rvr | ||
| apw | zyga, its not systemic, i have a uptopic here with 7 days uptime and both system and user init are under 10M | 09:10 |
| zyga | oh | 09:11 |
| zyga | I have media-hub-server crashing all the time | 09:11 |
| zyga | like a few times a second | 09:11 |
| zyga | perhaps that's why | 09:11 |
| zyga | some process-exit leak? | 09:11 |
| zyga | https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/1321204 and https://bugs.launchpad.net/ubuntu/+source/media-hub/+bug/1321203 | 09:16 |
| ubottu | Launchpad bug 1321204 in upstart (Ubuntu) "upstart (session) consumes almost 3GB of memory after 24 hours of uptime" [Undecided,New] | 09:16 |
| ubottu | Launchpad bug 1321203 in media-hub (Ubuntu) "media-hub-server constantly crashes" [Undecided,New] | 09:16 |
| ogra_ | cjwatson, that was graphics driver specific ... only happened on the old galaxy nexus due to the driver calling vsync several times a second | 09:22 |
| * ogra_ wonders if media-hub is actually supposed to be on desktop at all yet | 09:22 | |
| ogra_ | zyga, you should talk to jhodapp (he's at the sprint so should be around in i.e. #ubuntu-touch) | 09:23 |
| zyga | ogra_: thanks | 09:30 |
| dbarth | Mirv: sorry (meetings) | 09:34 |
| dbarth | Mirv: that's about updating qtwebkit for bugfixes? i'm not sure i have the right context | 09:35 |
| === sz0 is now known as sz0` | ||
| jodh | apw: ack - awaiting zyga's response to my questions on the bug. | 09:51 |
| Mirv | dbarth: yes, updating qtwebkit for other users besides phone. we did try 5.2 qtwebkit already before, and the only problem we had was OpenGL games. but it's even safer if we're satisfied with the amount of Oxide migrations done, so I'm wondering if we could give mitya57 some idea when the 5.2 could be allowed to go in. | 09:53 |
| pmcgowan | cjwatson, hi can you approve my reply to ubuntu-devel list | 09:57 |
| cjwatson | pmcgowan: done | 09:59 |
| pitti | mbiebl: *sniff* Bug#747662: Removed package(s) from unstable :) | 10:00 |
| pitti | (hal) | 10:00 |
| pitti | and it only took like 5 years :) | 10:00 |
| mlankhorst | infinity: ping? | 10:07 |
| === jono is now known as Guest73754 | ||
| luv | pitti: hi .... you saw my message? | 10:34 |
| pitti | 07:58:17 pitti | luv: *shout* :) | 10:35 |
| pitti | luv: hi :) yes, I did, ^ | 10:35 |
| luv | haha :-) | 10:35 |
| luv | should get my znc settings sorted out :-) | 10:36 |
| luv | anyway, when I test on my other 14.04 box and I can confirm it fixes the issue (for me), I will attach patch to the issue. Or is here more to do? | 10:39 |
| pitti | luv: that sounds good; the compiz devs can then turn it into a merge proposal etc. | 10:44 |
| pitti | luv: I still get the issue occasionally, although I don't notice that much because my "start session" script has a bunch of gsettings calls to fix stuff | 10:45 |
| luv | cheers | 10:46 |
| pitti | seb128: are you aware that your e-d-s upload a week ago is stuck? friend's test started failing a week ago | 10:49 |
| pitti | Soup.MemoryUse.COPY, data, len(data)) | 10:49 |
| pitti | TypeError: set_request() takes exactly 4 arguments (5 given) | 10:49 |
| pitti | seb128: could be because of your e-d-s upload or perhaps a change in soup? | 10:49 |
| pitti | seb128: ah, https://launchpad.net/ubuntu/+source/libsoup2.4/2.46.0-2ubuntu1 landed on May 12, so probably it's that what broke friends | 10:50 |
| mlankhorst | can someone review the NEW queue of precise? there's a xorg-lts-trusty stack there waiting to be accepted :-) | 10:52 |
| === MacSlow_ is now known as MacSlow|lunch | ||
| michagogo | infinity: btw, which version is in quantal? | 11:18 |
| michagogo | (it's gone from the packages page...) | 11:18 |
| cjwatson | Still in +publishinghistory | 11:18 |
| cjwatson | Top right | 11:19 |
| michagogo | infinity: never mind, found it on https://launchpad.net/ubuntu/+source/bitcoin | 11:22 |
| seb128 | pitti, no, I was not aware, some days I wish we had email notifications for such things, thanks! | 11:23 |
| seb128 | pitti, likely libsoup yes | 11:24 |
| seb128 | pitti, I can try to have a look in a bit | 11:24 |
| pitti | seb128: sorry that the pitti notificator has quite some lag | 11:24 |
| pitti | seb128: at least it now expects one parameter less, so just pick which one to drop :-P | 11:25 |
| ogra_ | you need to work on that, seriously ... | 11:25 |
| seb128 | lol | 11:25 |
| ogra_ | also localized notifications please :) | 11:25 |
| pitti | ogra_: richtig! | 11:25 |
| pitti | seb128: le paquet "amis" est malade | 11:25 |
| stgraber | :) | 11:25 |
| seb128 | heh | 11:25 |
| mlankhorst | o.O | 11:26 |
| pitti | le nouveau version de potage à le cassé | 11:26 |
| mlankhorst | french is still not the default language pack, pitti! | 11:26 |
| stgraber | I'm sure you could get google translate to give you "vos amis sont malades", that'd be slightly confusing ;) | 11:26 |
| seb128 | pitti, version est féminin | 11:26 |
| pitti | seb128: ah, merci :) | 11:27 |
| seb128 | de rien ;-) | 11:27 |
| pitti | mlankhorst: seb128 thinks otherwise | 11:27 |
| mlankhorst | yeah we patch his copy of ubuntu | 11:28 |
| ogra_ | i'm wondering if someone has an explanation for the pm-utils/powermgmt-base dropping in http://people.canonical.com/~ogra/touch-image-stats/29.changes ... i went through all packages in that change-set, nothing dropped a dependency on these two ... there was no seed change either | 11:45 |
| ogra_ | (and since it is touch, there are no recommends in use, i can see no reason why they would/could be dropped) | 11:47 |
| zyga | hmm, qtbase-opensource-src seems to FTBFS on utopic | 11:48 |
| zyga | I was going to file a bug on that, adding libboost-regex-dev fixed it for me (on utopic) | 11:49 |
| zyga | I tried to reproduce the failure in sbuild but I got a test failure instead | 11:49 |
| zyga | wtf? | 11:49 |
| zyga | can anyone more experienced than me just run a test build of qtbase-opensource-src on utopic and tell me if I'm seeing things? | 11:49 |
| ogra_ | zyga, there was an upload a few mins ago ... you could just watch it ;) | 11:50 |
| brendand | zyga, what do you see? | 11:51 |
| zyga | brendand: I saw | 11:52 |
| zyga | FAIL! : tst_qstandardpaths::testRuntimeDirectory() '!runtimeDir.isEmpty()' returned FALSE. () Loc: [tst_qstandardpaths.cpp(414)] | 11:52 |
| zyga | ogra_: oh, thanks | 11:52 |
| * zyga looks at the changelog | 11:52 | |
| zyga | brendand: and before I was seeing a missing linkage dependency on some test tool | 11:52 |
| === sz0` is now known as sz0 | ||
| === MacSlow|lunch is now known as MacSlow | ||
| mterry | pitti, hello! Do you know if it's possible to fake having a sim that needs to be unlocked for my mako device? | 13:21 |
| === sz0 is now known as sz0` | ||
| pitti | mterry: yes, it is | 13:25 |
| mterry | yay! | 13:25 |
| pitti | mterry: for that you need to start ofono-phonesim with a different xml | 13:25 |
| * pitti looks | 13:25 | |
| pancakes9 | hey guys, I'm a new contributor | 13:25 |
| pitti | - Modify default.xml: Set PINNAME from "READY" to "SIM PIN", set SC from 0 to 1, run phonesim with that | 13:25 |
| pitti | - can be unlocked with /usr/share/ofono/scripts/enter-pin pin XXXX | 13:25 |
| pitti | mterry: ^ | 13:25 |
| pancakes9 | Am I in the right channel for asking for help on how to get started? | 13:25 |
| pitti | mterry: you should talk to Wellark, I think he already set this up for some app | 13:26 |
| mterry | pitti, thank you so much! I'll try it out and bug Wellark if needed :)( | 13:26 |
| pitti | mterry: oh, and obviously PINVALUE (defaults to 2468, but you can change it of course) | 13:27 |
| ogra_ | pancakes9, probably #ubuntu-motu is better | 13:31 |
| pancakes9 | ogra_: thanks | 13:31 |
| lool | would someone mind giving a quick look at: http://paste.ubuntu.com/7492987/ ? sicne it's fakeroot I'd like another pair of eyes on it; I've tested that it fixes the issue and have done a test build with it (hello-debhelper) | 13:36 |
| pitti | sil2100: do you know who landed unity-scopes-api? it apparently broke the unity-scopes-click test | 13:44 |
| pitti | sil2100: with the autolanding we don't have proper uploaders and thus the usual autopkgtest notification mails don't work | 13:44 |
| pitti | sil2100: i. e. unity-scopes-api is held back in -proposed due to that | 13:44 |
| pitti | and the new unity8 too | 13:44 |
| seb128 | Mirv, ^ | 13:45 |
| seb128 | ogra_, ^ | 13:45 |
| ogra_ | pitti, Mirv | 13:46 |
| seb128 | (they were just discussing unity8 in ci-eng) | 13:46 |
| pitti | Mirv: hello :) so please consider you notified | 13:46 |
| Mirv | I did not land tha tone | 13:46 |
| Mirv | so the scopes were landed by mhr3 | 13:46 |
| seb128 | Mirv, but you were asking about unity8 not migrating | 13:46 |
| Mirv | and I landed unity8 separately | 13:47 |
| ogra_ | oh, that was sil2100 actually | 13:47 |
| pitti | jibel: seems I must gradually abolish my first "retry the test" reflex, except for the linux and eglibc timeouts I haven't seen an infrastructure failure since the apt-get race fix \o/ | 13:47 |
| ogra_ | (-scopes-api) | 13:47 |
| Mirv | seb128: yes, it seems we have the culprit then | 13:47 |
| pitti | sil2100, Mirv: you guys know about http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html ? (in case you wonder where your landings are stuck) | 13:48 |
| didrocks | pitti: you have sil2100 as the guy publishing it :) | 13:48 |
| Mirv | pitti: yes, I was just not first assuming it's a real error since there have been various autopkgtest problems earlier last week and so | 13:48 |
| didrocks | but we'll need to come to the discussion in Malta about showing off the guy clicking the package publishing or the lander :) | 13:49 |
| pitti | Mirv: right, my usual first assumption is "broken infrastructure" too due to long training, so I still review every single failure :) | 13:49 |
| Mirv | so is there an option of rejecting the scopes-api so that unity8 can pass? | 13:49 |
| pitti | and then play pitti-notification-bot | 13:49 |
| pitti | Mirv: we can remove bad packages from -proposed | 13:49 |
| pitti | that might lead to bzr branches getting out of sync, though | 13:49 |
| cjwatson | pitti: Autolandings should now have an at least somewhat useful sponsored field, FYI | 13:49 |
| Mirv | yes I've noticed a lot of magic happening "automatically" (by you or colin) | 13:50 |
| pitti | although you only really merge after it propagated, right? | 13:50 |
| cjwatson | So it should be possible for autopkgtest to scrape that out | 13:50 |
| pitti | hmm, https://launchpad.net/ubuntu/+source/unity-scopes-api/0.4.6+14.10.20140519-0ubuntu1 still only shows "buntu daily release <ps-jenkins@lists.canonical.com> | 13:50 |
| pitti | oh, from https://launchpad.net/ubuntu/utopic/+source/unity-scopes-api/0.4.6+14.10.20140519-0ubuntu1 | 13:50 |
| Mirv | pitti: yes the merge & clean is only done after it's in release pocket | 13:50 |
| pitti | Copied from ubuntu utopic in Landing PPA 011 by Łukasz Zemczak | 13:50 |
| sil2100 | I'm back | 13:51 |
| sil2100 | pitti: thanks for the info! uh! | 13:51 |
| seb128 | mhr3, hey | 13:51 |
| pitti | Mirv: so yes, we can (and often have) remove stuff from -proposed when it introduced regressions; the version number will be "burned" then, and potentially the status needs to be updated in MPs/landings/etc. | 13:51 |
| seb128 | pitti, do you have a link to the test errors for mhr3? | 13:51 |
| pitti | hey sil2100 | 13:51 |
| pitti | it's linked from excuses | 13:52 |
| seb128 | pitti, Mirv, sil2100: let's see if we can sort it out rather than deleting | 13:52 |
| pitti | https://jenkins.qa.ubuntu.com/job/utopic-adt-unity-scope-click/40/ARCH=i386,label=adt/console | 13:52 |
| seb128 | mhr3, ^ | 13:52 |
| seb128 | pitti, danke | 13:52 |
| pitti | although there seems to be more than one problem there | 13:52 |
| cjwatson | Mirv: Well. I try to reduce the amount of stuff running from cron.cjwatson where I can ;-) | 13:52 |
| pitti | Failed to get D-Bus connection (Cannot autolaunch D-Bus without X11 $DISPLAY) | 13:52 |
| pitti | -> missing xvfb-run? | 13:53 |
| pitti | the "g_signal_handlers_disconnect_matched: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed | 13:53 |
| pitti | and several test failures | 13:53 |
| * sil2100 still reads the logs for the failure | 13:54 | |
| === roadmr is now known as roadmr_afk | ||
| mhr3 | the click failures are hardly caused by -api | 13:54 |
| pitti | sil2100: that autopkgtest just builds the package, so it's FTBFS | 13:54 |
| sil2100 | pitti: that is strange, as it built fine in the PPA | 13:55 |
| sil2100 | Otherwise it wouldn't be publishable | 13:55 |
| sil2100 | hmm | 13:55 |
| pitti | sil2100: was unity-scope-click built against the new unity-scopes-api? | 13:55 |
| pitti | sil2100: by the time of the upload to Ubuntu it seems the last build happened against a previous scopes-api | 13:56 |
| sil2100 | Ah, crap, indeed, it was just scopes-api and scopes-shell | 13:56 |
| pitti | anyway | 13:56 |
| pitti | I'm really happy that this britney/adt stuff works fairly reliably now | 13:56 |
| sil2100 | Miss-checked that one, strange stuff | 13:56 |
| pitti | turning "OMGwebroketheimage" into "let's take time and fix it properly without rush" | 13:56 |
| dobey | hmm | 13:56 |
| === sz0` is now known as sz0 | ||
| === sz0 is now known as sz0` | ||
| sil2100 | Let me poke upstream about that one first thing | 13:58 |
| === roadmr_afk is now known as roadmr | ||
| sil2100 | pitti: thanks for letting us know about this! The unity-scope guys already got informed and know of a possible fix | 14:02 |
| pitti | nice! | 14:02 |
| === sz0` is now known as sz0 | ||
| mhr3 | pitti, so in this case there was an issue in -click's tests, and that now prevents -api to be published, not sure if such a failure should be automatically considered something fatal | 14:28 |
| pitti | mhr3: we consider it fatal if a package's tests succeeded, and started failing if one of its dependencies got updated | 14:29 |
| pitti | then we hold back that dependency | 14:29 |
| pitti | there are certainly situations where it fails for a different reason, but the probability is quite high that this dependency update was the culprit | 14:30 |
| pitti | mhr3: so if clicks' tests now fail due to something different, the release team can override that to let -api pass | 14:30 |
| ScottK | pitti: seems to me the larger issue is non-devlopers having upload access to the archive via autolanding. | 14:30 |
| ogra_ | ScottK, only after a core-dev reviewed thee packaging changes | 14:31 |
| ScottK | So? | 14:31 |
| ogra_ | (and an upstream dev had to cross review the upstream changes first) | 14:31 |
| ogra_ | thats not much different to sponsoring | 14:31 |
| ScottK | Except for no Ubuntu devs look at it. | 14:32 |
| mhr3 | pitti, well, no, the system is right that the updated -api caused the -click's tests to fail, but they were doing something wrong in the first place | 14:32 |
| seb128 | mhr3, that still points to an issue somewhere (the tests in that case), and you can't know the reason is advance, so blocking is the right thing to do | 14:33 |
| mhr3 | pitti, it just feels that library developers are suddenly responsible for all rdeps | 14:33 |
| seb128 | mhr3, they are to make sure they don't create any bugs in their rdeps yes | 14:33 |
| ogra_ | ScottK, hmm ? you mean a core-dev isnt an ubuntu dev ? the landing cant go in unless a core-dev had nodded it off ... the only diifference to actual sponsoring is that the landing is done in piecemeal | 14:33 |
| pitti | mhr3: of course not, if the -click test is wrong then the -click author should fix it | 14:34 |
| pitti | but we can't just let in any uplaod which breaks a dependency, then the whole thing woudl be pointless | 14:34 |
| ogra_ | ScottK, so the core-dev never sees the full picture ... only the packaging changes ... which can cause issues like above | 14:34 |
| mhr3 | pitti, sure, but until that happens, others are blocked from using the new lib | 14:34 |
| ScottK | oct | 14:34 |
| pitti | mhr3: yes, intentionally (if it causes a regression or API change then it should not land yet) | 14:35 |
| ScottK | Oops | 14:35 |
| mhr3 | pitti, don't get me wrong, it's good that we get notified about it, i'm just questioning the concept of auto-block | 14:35 |
| pitti | mhr3: NB, I'm not saying that this did cause an API change, but the failure/holding back in -proposed would look exactly like that | 14:35 |
| ogra_ | nov :) | 14:35 |
| pitti | mhr3: what would be the alternative? | 14:35 |
| pitti | mhr3: it gets blocked, we investigate it, we might decide it's wrong and override it; or it's right and we need to fix something | 14:36 |
| mhr3 | pitti, guess it would have to be assessed on a case-by-case basis | 14:36 |
| pitti | right, it is | 14:36 |
| mhr3 | alright, so there is the ignore button somewhere? :) | 14:36 |
| cjwatson | mhr3: We fail safe and can assess and override case-by-case. I don't see the problem | 14:36 |
| mhr3 | good to know | 14:36 |
| pitti | mhr3: yes, as I said the release team can override it (it's a bzr commit) | 14:36 |
| mhr3 | k, then all is fine i guess | 14:37 |
| cjwatson | Though generally in this kind of case I'd still prefer to see the rdep passing, to make sure that a test suite problem isn't masking something else | 14:37 |
| ScottK | ogra: For sponsorship, an Ubuntu dev has the whole upload. For uploads with no packaging changes, who reviews that? | 14:39 |
| ogra_ | ScottK, upstream | 14:39 |
| ogra_ | the owning team of the upstream branch | 14:39 |
| === Ursinha is now known as Ursinha-afk | ||
| ScottK | Right. As I said, non-Ubuntu developers have upload rights. | 14:40 |
| ScottK | Which violates the trust model of the distro. | 14:40 |
| ogra_ | well, with a lot more hurdles to take than dputting :) they are not actually uploading to the archive | 14:41 |
| ogra_ | and the change goes through the landing team first (which consist of devs and non devs admittedly) | 14:41 |
| dobey | mhr3, pitti, cjwatson: well, it's clear why the test is failing, and the failure isn't masking an issue in the runtime click scope code. i think it's fine to "ignore" the failure in the click scope autopkgtest and push the scopes-api landing through, in this case, as long as click-scope is the only thing with broken tests | 14:43 |
| ogra_ | after all such a landing gets a significant amount more review than a core-dev doing a dput ... i wouldnt see the trust model violated but rather improved by this | 14:43 |
| dobey | mhr3, pitti, cjwatson: so are we going to push scopes-api landing through despite the click-scope failure (which is a bug i can fix today), or do i need to propose a branch now and get click-scope in the same silo? | 14:48 |
| cjwatson | dobey: Is there a branch somewhere that fixes the bug? | 14:48 |
| sergiusens | cjwatson: is there an ETA for adding the click 14.10 framework? | 14:48 |
| cjwatson | If it's fixable today, I'd honestly be more comfortable if we did that | 14:48 |
| cjwatson | sergiusens: no | 14:48 |
| sergiusens | cjwatson: there are breaking changes in the clicks, reason why I ask | 14:49 |
| cjwatson | sergiusens: do you mean breaking changes in the platform? | 14:49 |
| sergiusens | cjwatson: yes, in the content-hub | 14:49 |
| cjwatson | ok, so that would be a good reason to do it | 14:49 |
| cjwatson | lool: ^- any objection to me adding ubuntu-sdk-14.10-dev1 et al? | 14:49 |
| dobey | cjwatson: nearly; i think fixing it directly in click scope trunk will result in a conflict with a branch that we landed in our devel yesterday, so i'd prefer to avoid that and merge into devel then merge devel into trunk (which has more changes than just this fix). | 14:50 |
| sergiusens | cjwatson: does beuno need to do anything for this? | 14:50 |
| cjwatson | sergiusens: I'm afraid I don't know | 14:50 |
| mhr3 | dobey, the fix is pretty tiny, no? if it can be done in <15minutes let's just do it | 14:50 |
| dobey | sergiusens: yes i think the store db has to be updated with the new frameworks | 14:50 |
| mhr3 | dobey, then even the conflict will be tiny :) | 14:50 |
| dobey | mhr3: yes the fix is tiny | 14:50 |
| cjwatson | dobey: we should get the test failure fixed before landing further changes, IMO | 14:51 |
| dobey | mhr3: i just switched away from my workspace where i have the code open, back to irce, and saw you discussing it with pitit here | 14:51 |
| dobey | mhr3: so i didn't want to waste time making an MP and all, if it was just going to get ignored for the moment :) | 14:51 |
| mhr3 | dobey, it won't be ignored, the silo is waiting for it | 14:52 |
| ogra_ | ... and unity8 ... and the anticipated image build ... | 14:53 |
| lool | cjwatson: not at all, I had it locally actually but waited for the new security permission implementation to land | 14:53 |
| dobey | mhr3: https://code.launchpad.net/~dobey/unity-scope-click/fix-query-tests/+merge/220280 should fix it | 14:53 |
| sergiusens | dobey: so there's no need to update anything in the click scope for a new framework | 14:54 |
| mhr3 | sil2100, got the fix, can you reconf 011? | 14:54 |
| cjwatson | lool: ah, I don't know whether jdstrand is ready for it | 14:54 |
| sil2100 | mhr3: on it | 14:54 |
| dobey | sergiusens: not in the scope itself, no. we read the frameworks from the system. the server db needs updated though, so people can actually upload clicks that use the new framework, iirc | 14:54 |
| lool | cjwatson: ah actually motivation for the change is to pick up an ABI breakage, so discussing this here | 14:56 |
| lool | ABI addition is ok, but not ABI breakage | 14:56 |
| sil2100 | mhr3: reconfigured | 14:56 |
| sil2100 | mhr3: you can build o/ | 14:56 |
| mhr3 | sil2100, enough to build click itself? | 14:56 |
| sil2100 | mhr3: yes, I guess mentionin only u-s-c is what we would like | 14:57 |
| cjwatson | mhr3: Hm? I already have another silo containing click itself | 14:57 |
| mhr3 | cjwatson, sorry, i'm talking about click scope | 14:58 |
| cjwatson | So you mean "enough to build unity-scope-click itself"? | 14:58 |
| mhr3 | yes | 14:58 |
| cjwatson | OK | 14:58 |
| === Ursinha-afk is now known as Ursinha | ||
| lool | cjwatson: bottom line is that we're reverting the content-hub and corresponding browser changes to revert the ABI breakage | 15:08 |
| cjwatson | OK | 15:09 |
| cjwatson | mvo_: your click change to disable apps when their framework goes away works beautifully on my device | 15:10 |
| cjwatson | I'm sure you knew that, but just for the record :) | 15:10 |
| lool | cjwatson: mind looking at the debdiff I've put in LP #1290069 ? | 15:13 |
| ubottu | Launchpad bug 1290069 in fakeroot (Ubuntu) "Bad identification of getopt in /usr/bin/fakeroot-sysv with some translations" [Undecided,In progress] https://launchpad.net/bugs/1290069 | 15:13 |
| cjwatson | lool: Maybe a bit later this afternoon | 15:14 |
| cjwatson | (meetings etc.) | 15:14 |
| lool | ok | 15:14 |
| lool | pitti: would you by change have a minute to look at the debdiff in LP #1290069 ? | 15:15 |
| ubottu | Launchpad bug 1290069 in fakeroot (Ubuntu) "Bad identification of getopt in /usr/bin/fakeroot-sysv with some translations" [Undecided,In progress] https://launchpad.net/bugs/1290069 | 15:15 |
| beuno | sergiusens, cjwatson, yes, I need to add it to the store so we can accept apps. Just say when. | 15:15 |
| mvo_ | cjwatson: \o/ thanks for confirming | 15:15 |
| === seb128_ is now known as seb128 | ||
| tarpman | luv: did you see the recent comments on bug 1063617? even if your patch isn't fully tested yet, might be worth posting your WIP to the bug (btw thanks for working on it!) | 15:37 |
| ubottu | bug 1063617 in Compiz "1:0.9.8+bzr3319-0ubuntu1 regression: keeps setting gsettings keys to wrong values" [High,In progress] https://launchpad.net/bugs/1063617 | 15:37 |
| luv | tarpman: cool ... I will post my findings and the patch this evening to save the guy the countless hours in gdb :-) | 15:39 |
| tarpman | luv: thanks! | 15:39 |
| luv | no probs :-) | 15:39 |
| luv | just got so annoyed (and it has been in for almost two years! :-( ) so I just had to fix it | 15:40 |
| Elv1313 | Hi, can someone upload the patch for bug 1316612? | 15:56 |
| ubottu | bug 1316612 in sflphone (Ubuntu) "SFLPhone-KDE will freeze if an Akonadi request deadlock" [Undecided,Confirmed] https://launchpad.net/bugs/1316612 | 15:56 |
| Elv1313 | it is already confirmed and tested by 2 users, it probably affect ~40% of all sflphone-kde users, so I it would be nice if the process could be speeded up a little | 15:56 |
| Riddell | Elv1313: I'm about to leave but if you e-mail me I can look at it tomorrow | 15:58 |
| rbasak | Elv1313: you want to get that into the sponsorship queue. Attaching a debdiff suitable for applying to Utopic should do this automatically for you. | 15:58 |
| rbasak | I was about to say that you could try poking a patch pilot on here when one appears in the channel topic, but it sounds like Riddell will help. | 15:59 |
| Elv1313 | Riddell: ok | 15:59 |
| pitti | lool: sorry, was out for errands; looks good to me (and also upstreamable) | 16:01 |
| lool | pitti: thanks | 16:04 |
| Elv1313 | rbasak: Thanks, pulling "bzr branch lp:sflphone" only give me the tranlations, is there a repository where I can pull/push patches or "debian/" scrips changes? | 16:06 |
| rbasak | Elv1313: try "bzr branch lp:ubuntu/sflphone". | 16:07 |
| rbasak | Elv1313: I tend to use debdiffs directly without bzr. For that, "pull-lp-source sflphone" will give you the current Utopic unpacked source package. | 16:07 |
| rbasak | Elv1313: you'll want to add the patch to debian/patches, with dep3 headers so that future developers can trace the origin. | 16:08 |
| Elv1313 | rbasak: is it possible to also add them to trusty? | 16:09 |
| rbasak | Elv1313: when you're done, you can submit a bzr merge proposal on Launchpad, or just attach the debdiff to the bug. For the latter, I think a bot will come along and subscribe ~ubuntu-sponsors to the bug, or you can do that directly. | 16:09 |
| rbasak | Elv1313: you can see the sponsorship queue at http://reqorts.qa.ubuntu.com/reports/sponsoring/index.html... | 16:09 |
| rbasak | Elv1313: https://wiki.ubuntu.com/StableReleaseUpdates#Procedure for the process for updating Trusty. | 16:10 |
| rbasak | Elv1313: in general Utopic needs to be fixed first, and backported fixes need to be high-impact or otherwise meet the criteria defined higher up on that page. | 16:10 |
| rbasak | Elv1313: HTH. | 16:10 |
| Elv1313 | rbasak: So far errors.ubuntu.com found ~15 segfault of critical asserts for the gnome (sflphone) client and 2 deadlocks for the kde client. We have patches for ~5 of them so far, but most are stuck in unconfirmed launchpad bug reports. I think crashes are critical enough to get backported. | 16:16 |
| rbasak | Elv1313: that sounds reasonable. The SRU team usually makes the decision based on the bug description after upload. | 16:18 |
| rbasak | Elv1313: so just be sure to justify it in the bug, and you should be OK. It's mainly the trade-off between the bug impact and the regression risk that matters. | 16:19 |
| Elv1313 | we will have a new release in time for Utopic, so there is little point to push those fixes into 14.10 | 16:19 |
| rbasak | The risk is that it won't make Utopic, and then Utopic will regress the fixes pushed back to Trusty. I think that's the reason that it's generally required to be fixed in Utopic first. | 16:20 |
| rbasak | So I guess you can wait on the new release in Utopic before fixing Trusty, or fix Utopic with the patches now, or get an exception from the SRU team. | 16:20 |
| Elv1313 | ok, thanks | 16:22 |
| === roadmr is now known as roadmr_afk | ||
| === roadmr_afk is now known as roadmr | ||
| === roadmr is now known as roadmr_afk | ||
| sl33k_ | I want to volunteer contributing code, triage bugs. Would I be able to help with less relevant experience? | 16:39 |
| Elv1313 | sl33k_: helping getting bug fixed faster if the most helpful thing there is | 16:41 |
| rbasak | sl33k_: there are a ton of bugs with a "please provide a patch" type status. Help with these would be most welcome. | 16:48 |
| Elv1313 | sometime, simply getting in contact with an upstream dev is enough. They may not be aware fo the issue or it might already have been fixed, but never backported | 17:00 |
| === roadmr_afk is now known as roadmr | ||
| === timrc is now known as timrc-afk | ||
| === timrc-afk is now known as timrc | ||
| mapreri | pitti: thanks :) (even if I'm wondering which hours you work: I did not image you work during "office hours"...) | 18:54 |
| xnox | mapreri: it is office hours =) just without timezone defined ;-) | 19:45 |
| zyga | hmm, is python-virtualenv just broken now on utopic or did I mess up my system somehow? | 19:51 |
| dobey | is there anyone i can beg to accept some SRU packages to their appropriate -proposed channels? | 19:51 |
| zyga | http://pastebin.ubuntu.com/7494459/ | 19:51 |
| dobey | zyga: not a useful or definite answer, but i only want to reply with "yes" :) | 19:51 |
| zyga | barry: ^^ ? | 19:51 |
| zyga | dobey: well, less strict parsing may be needed ;) | 19:52 |
| zyga | barry: is that wheel related by any chance? | 19:52 |
| dobey | zyga: why are you running python3 code in a 2.7 virtualenv? | 19:52 |
| zyga | dobey: I | 19:52 |
| zyga | dobey: I'm running what used to work: virtualenv -p python3 /some/path | 19:53 |
| zyga | dobey: worked from 12.04 till yesterday | 19:53 |
| dobey | huh | 19:54 |
| zyga | dobey: that's *the* way to get a useful python3 virtualenv AFAIK | 19:54 |
| Unit193 | pitti: On initramfs-tools? I'd think busybox as zz-busybox runs before busybox. | 19:57 |
| barry | zyga: not that i know of. none of the wheels stuff has landed in debian yet (in progress). it won't affect virtualenv anyway, just pyvenv | 19:57 |
| Unit193 | (I put a dep from the one on the other, fixed.) | 19:57 |
| barry | zyga: seems to work for me | 19:58 |
| zyga | barry: can you check if that's broken on your (utopic) box by any chance? | 19:58 |
| zyga | hmmm | 19:58 |
| dobey | sigh. why are simple SRUs so hard to do? | 19:58 |
| zyga | dobey: I feel your pain | 19:58 |
| barry | zyga: virtualenv -p python3 /tmp/pp | 19:58 |
| barry | source /tmp/pp/bin/activate | 19:58 |
| barry | pip install nose2 | 19:58 |
| barry | all seems happy | 19:58 |
| zyga | barry: it crashes for me as linked above | 19:59 |
| zyga | python-virtualenv changelog is old so nothing new landed lately | 19:59 |
| * zyga has installed python-configparser lately though, let's see if removing it helps | 20:03 | |
| dobey | that could certainly result in what you are seeing | 20:03 |
| zyga | dobey: yeah | 20:04 |
| zyga | confirmed | 20:04 |
| zyga | removing python-configparser fixes it | 20:04 |
| dobey | is that some "let's backport the new python3 module to python2" thing? | 20:05 |
| zyga | barry: yeah | 20:05 |
| zyga | barry: can you install and check it happens on your copy too | 20:05 |
| zyga | oh, it's probably being imported | 20:05 |
| zyga | and the code doesn't fall back to 2.7 imports | 20:05 |
| zyga | or equivalent stuff | 20:06 |
| zyga | sounds plausible | 20:06 |
| zyga | yeah, exactly | 20:06 |
| zyga | damn :) I need that package and working virtualenv | 20:06 |
| zyga | :-) | 20:06 |
| * zyga wonders what to do | 20:06 | |
| dobey | why do you need that package? | 20:06 |
| zyga | dobey: checkbox-support needs it to work on python2.7 which is a new requirement for us so we just have to have it :/ | 20:07 |
| zyga | dobey: (it's 3.2+ right now) | 20:07 |
| zyga | dobey: well, 101 patches make it 2.7+ compatible though | 20:07 |
| dobey | zyga: can't you just do the appropriate try/except in checkbox directly? | 20:07 |
| zyga | https://code.launchpad.net/~zkrynicki/checkbox/fix-1319767/+merge/220318 | 20:07 |
| zyga | dobey: that's a virtualenv problem though | 20:07 |
| zyga | dobey: oh, you mean to use the old import name | 20:08 |
| zyga | hmm | 20:08 |
| zyga | maybe | 20:08 |
| dobey | yes, that's what we did in u1 stuff | 20:08 |
| zyga | good idea, I will probably do just that | 20:08 |
| dobey | i generally try to avoid those "py2.7 compat versions of py3 modules" things because they tend to cause more problems than not (like the one you're having now) :) | 20:09 |
| zyga | still that package is broken | 20:09 |
| zyga | dobey: well, I tend to avoid 2.7 entirely ;) | 20:09 |
| zyga | they should always have different import name | 20:09 |
| dobey | well i guess there's a reason it's not in corelib | 20:09 |
| zyga | I mean, come on | 20:09 |
| zyga | dobey: configparser? | 20:09 |
| zyga | dobey: it is in python3 | 20:10 |
| dobey | well whatever package that is, yes | 20:10 |
| zyga | dobey: corelib I assume that's python stdlib? | 20:10 |
| zyga | (or am I mistaken and you meant something else) | 20:10 |
| dobey | yeah i meant std lib | 20:10 |
| dobey | configparser is in python2.7 and ConfigParser is in python3. | 20:11 |
| dobey | so there shouldn't be any need to install a "python-configparser" | 20:11 |
| dobey | especially one that breaks things | 20:11 |
| zyga | ah, I understand your comment now then | 20:11 |
| zyga | yeah, I didn't check, I just assumed it's not in 2.7 and there's a 3 backport | 20:12 |
| zyga | I'll get rid of it | 20:12 |
| dobey | python-configparser is a package that is the result of someone trying to be clever, but actually being stupid :) | 20:12 |
| dobey | some of those are literally just someone ripping the code straight out of py3, adding a setup.py to install it in 2.7, and calling it a day. no tests or guarantee that it works or anything | 20:13 |
| barry | zyga: sorry, got stuck on the phone | 20:13 |
| zyga | barry: no worries, I think a debian bug is in order on python-configparser, I'll try to sort that out | 20:14 |
| dobey | ugh, someone packaged it in debian? even worse :) | 20:14 |
| barry | zyga: LP: #1156704 | 20:14 |
| ubottu | Launchpad bug 1156704 in python-virtualenv (Ubuntu) "Virtualenv breaks if python-configparser is installed" [Undecided,Confirmed] https://launchpad.net/bugs/1156704 | 20:14 |
| zyga | barry: it's quite old! | 20:15 |
| barry | zyga: yeah. i'll see if i can spend some time on it | 20:15 |
| barry | it's been on my backburner for a while ;) | 20:15 |
| dobey | rm /pool/p/python-configparser* | 20:15 |
| dobey | problem solved! | 20:16 |
| zyga | oh yeah | 20:16 |
| zyga | please | 20:16 |
| zyga | unless the backport has some new code that has merit | 20:16 |
| barry | it would be for bilingual code | 20:17 |
| dobey | not really | 20:17 |
| zyga | barry: if the 3 rewrite and backport has any extra features, otherwise virtualenv, which is bi-lingual just chokes on the code | 20:18 |
| dobey | bilingual code would do the right thing and "try: import ConfigParser except ImportError: import configparser as ConfigParser" or similar | 20:19 |
| barry | actually, it looks like there are few revdeps on python-configparser, and configglue isn't one of them any more | 20:19 |
| zyga | yeah, there are three | 20:19 |
| dobey | taking the code from py3 stdlib and shoving it in py2 doesn't make code "bilingual" | 20:19 |
| barry | zyga: so "apt-get purge python-configparser" ? :) | 20:19 |
| dobey | yeah, i think i complained loudly about configglue doing that at some point | 20:20 |
| zyga | barry: yeah, already did that | 20:20 |
| barry | \o/ | 20:20 |
| === broder_ is now known as broder | ||
| === _salem` is now known as _salem | ||
| mikey85 | I was banned from like every Ubuntu because of ikonia throwing false statements at me | 22:05 |
| mikey85 | I have proof | 22:05 |
| mikey85 | http://irclogs.ubuntu.com/2014/05/20/%23ubuntu.txt | 22:06 |
| sarnold | mikey85: try #ubuntu-irc or #ubuntu-ops | 22:06 |
| mikey85 | I've been banned in both | 22:06 |
| sarnold | mikey85: it would be better to bring your own logs, because the irclogs don't include your hostmasks. | 22:06 |
| mikey85 | ikonia has been wreeking havoc on me | 22:06 |
| Corey | mikey85: You're rapidly becoming a cross-channel problem. Please desist. | 22:06 |
| mikey85 | no corey | 22:06 |
| mikey85 | you guys have been accusing me falsely | 22:06 |
| sarnold | mikey85: note though that even though it does appear someone was impersonating you, you did not appear to take advice well. | 22:07 |
| Corey | mikey85: There's a process to appealing op decisions within Ubuntu; this isn't it. | 22:07 |
| mikey85 | But still, they can atleast hear me | 22:07 |
| mikey85 | she's going to get me banned on every Ubuntu chan and I can't let that happen | 22:07 |
| Corey | mikey85: You're doing it to yourself at this point. Please desist. | 22:08 |
| mikey85 | corey leave me alone please | 22:08 |
| sarnold | s/did not/do not/ ... sigh. thanks Corey. | 22:09 |
| roasted | hello | 22:15 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!